In the 5G Core (5GC) network the N4 Interface is the bridge between the control plane and the user plane. As such, it is the conduit for PDU session management and traffic steering towards the UPF and PDU usage and event reporting towards the SMF. The SMF conveys the policy rules obtained from the PCF regarding packet handling, forwarding, and usage reporting to the UPF. In order for the UPF to recognize the user plane traffic that must be governed by a particular rule, it uses the Packet Flow Descriptions (PFDs) that are also supplied by an SMF. Finally, in some scenarios the SMF may buffer user plane traffic or forward user plane traffic towards the DN or the UE via the UPF.
dsTest supports the N4 procedures described below and specified by TS 23.502 and TS 29.244.
N4 node-level procedures are used to establish and manage the interface between an SMF and a UPF and for items that are not related to specific N4 sessions.
N4 Association Setup, Update, and Release Procedures
The setup and release procedures establish and terminate N4 interfaces. Either the SMF or the UPF may initiate a setup or an update procedure, while the release procedure is always initiated by the SMF. The update procedure informs the N4 peer of a change to the features supported by the network function. A UPF may also use the update procedure to inform the SMF about resource availability or to request that the SMF initiate a release procedure.
The PFD Management procedure is used by an SMF to provision, update, and remove PFDs in the UPF. The NEF/PFDF manages PFDs and provides them to an SMF on request (pull mode) or when indicated by the management function (push mode). An SMF provisions the UPF with a PFD that identifies the user plane traffic associated with at least one of the active packet detection rules in the UPF. An SMF may also use this procedure to update an active PFD in a UPF after receiving an updated PFD from an NEF/PFDF. When an SMF realizes that a PFD is no longer needed, because the associated rule is no longer active, the SMF notifies the UPF that the PFD should be removed.
A UPF uses this procedure to notify the SMF of information that is not related to a specific N4 session but which may affect all sessions, such as a user plane path failure with a remote GTP-U peer.
Load Control and Overload Control (Optional)
UPFs that support Load Control will periodically include the Load Control Information (LCI) IE in normal PFCP signalling to SMFs that likewise support this procedure. The IE includes a load metric that informs the recipient of the current load on the UPF as a percent of its total capacity. The receiving SMF(s) may, when indicated, take actions to regulate the load such as directing traffic to another UPF.
When a UPF that supports Overload Control realizes that its load has or is about to exceed its capacity it includes the Overload Control Information IE (OCI) in normal PFCP signaling to supportive SMFs. In this case the metric used indicates the percentage of reduction in traffic requested by the UPF. The receiving SMFs should attempt to mitigate the overload condition by reducing the requests sent to the UPF by the amount indicated and may take other actions that are implementation specific.
A PFCP node initiates the Heartbeat procedure — a simple request/response transaction — to determine whether a PFCP peer is still alive.
N4 Session Procedures
SMFs use the following procedures to manage N4 sessions associated with PDU sessions.
N4 Session Establishment, Modification, and Release
The SMF uses these procedures to manage N4 contexts in associated UPF(s). It uses the N4 Session Establishment to create a new PDU session in the UPF or to change the UPF for an existing PDU session. The information conveyed to the UPF includes the identifiers for the entities involved as well as policy rules that govern UPF behavior regarding that session. The SMF uses the N4 Session Modification procedure to update context information as needed. When an SMF determines that an N4 context should be removed from a UPF it initiates the N4 Session Release procedure. A UPF includes any reporting information not yet conveyed to the SMF in the release response message.
As mentioned above, policy rules provided by the SMF may govern the conduct of a UPF in managing a PDU session. Any of the following rules may be conveyed to a UPF:
- Packet Detection Rule (PDR)
- Forwarding Action Rule (FAR)
- QoS Enforcement Rule (QER)
- Usage Reporting Rule (URR)
- Buffering Action Rule (BAR)
N4 Session Report
During N4 session establishment an SMF instructs the UPF to periodically report certain N4 session-level events. The UPF, in turn, initiates an N4 Session Report when indicated. The report may include any of the following items:
- Usage report — transmits the usage data collected for charging purposes
- Start of traffic detection — triggered when traffic described by a PDR is first detected
- Stop of traffic detection — triggered when the end of traffic described by a PDR is detected
- Detection of first downlink data to UE in CM-IDLE state — triggered when a downlink packet is received but there is no N3 tunnel for downlink transmission
- PDU session inactivity — triggered when the inactivity timer specified by the SMF expires
Use our SMF emulator in your 5G testing to test the control plane capacity and performance of your UPF network element. With dsTest you can easily scale a test to simulate millions of subscribers that attempt to establish N4 sessions at the rate you choose. Push rules and PFDs to your UPF and modify those rules while the test is running to test its traffic detection, QoS enforcement, or reporting.
As with all dsTest products, the node configurations and test scenarios are easily defined and configured with XML files that are validated against a published XML Schema to avoid invalid definitions. With our dsClient Desktop application you can create, run, and archive tests; capture, graph and archive operational measurements; capture real-time data flows and subscriber events; and manage your dsTest platforms and testing scenarios with a standalone application that runs on your PC.
Advanced Testing Features
SmartEvents — Alter application behavior or coordinate multiple interface applications with SmartEvents — our programmable, subscriber-level state machine. All dsTest applications are event-driven, enabling you to easily alter subscribers’ activities. Use our visual composer to draw your state machine and to trace a single subscriber’s path through the state machine while the test is running. Define event handlers that affect a subscriber’s behavior in an application, or that trigger an event in another application. You can also configure event handlers to modify subscriber information during run-time, introduce timers, or randomize subscriber behavior based on configurable probabilities to name just a few of the many options in one of dsTest’s most powerful features.
SmartMessageElement — Insert, delete, or replace elements in Diameter, RADIUS, MAP, LDAP, GTP, REST, or SOAP messages with our SmartMessageElement feature. Define proprietary signaling or corrupt elements to facilitate negative testing. You can specify when your elements are used with SmartEvents.
Traffic Profile — Draw the shape of your test actions across time with Traffic Profile. You can define the rate for any action as a static rate or reference a Traffic Profile configuration, which also means that multiple Traffic Profiles can be running concurrently. Use Traffic Profile in conjunction with the randomizing features in SmartEvents to design a test that more truly simulates real-world network activity.
dsTest provides rich sets of measurements for the N4 interface:
- Transaction and transport layer attempts, successes, and failures
- Transaction duration, transactions-per-second, and round-trip delay
- Message and byte counters
- Errors encountered and error indications received in messages