As 5G technology is deployed in core networks, mobility between 4G and 5G networks will be necessary for UEs that only support single registration mode. IP address continuity is required in order for inter-system mobility to be as seamless as possible from the perspective of a connected UE — particularly for voice services. The N26 interface enables networks to achieve this continuity as it enables networks to exchange the UE Mobility Management (MM) and Session Management (SM) states. The 4G-5G mobility procedures are derived from the 4G S1-based handover with Mobility Management Entity (MME) and Serving Gateway (SGW) relocations.
dsTest supports the N26 connected-mode handover procedures briefly described below as well as the handover cancel procedure.
5G to 4G Mobility
When an AMF receives notification from a gNodeB that a handover to EPS is required, and the UE’s subscription permits, it first selects the target MME and then requests the UE’s PDU session context from the SMF via the Nsmf_PDUSession service. The AMF includes the capabilities of the MME in the request and the SMF determines, based on the that information, whether any PDU sessions cannot be transferred. The SMF maps the transferable PDU sessions to EPS bearer contexts and returns the PDU session context.
Next, the AMF sends a Forward Relocation Request to the target MME over the N26 interface to initiate the handover procedure. The target MME prepares for the relocation, interacting with the target SGW and target eNodeB, and then responds to the request. When indicated, the MME includes the address of the target SGW and TEIDs for indirect data forwarding in its response. In this scenario, the AMF again utilizes the Nsmf_PDUSession service to update the UE’s PDU session context with this information. The UPF forwards downlink data to the E-UTRAN while the handover is in progress.
Finally, the AMF issues a Handover Command to the gNodeB over the N1/N2 interface, which will in turn instruct the UE to connect to the target cell in the E-UTRAN. The UE notifies the target eNodeB that the handover is complete. At this point the UE will receive any buffered downlink data and can send uplink data. When the MME receives a notification from the eNodeB that the handover is complete it informs the AMF, which will initiate the release of any remaining resources associated with the UE.
4G to 5G Mobility
When an MME receives notification from an eNodeB that a handover to 5GS is required, and the UE’s subscription permits, it selects a target AMF and sends it a Forward Relocation Request. This request contains the UE’s EPS MM context which the AMF then converts into a 5GS MM context, including the security context and the EPS bearer contexts. The AMF determines which Nsmf producer should manage each PDN connection by querying the network-level NRF for the N11 interface of the PGW-C+SMF associated with that connection.
Next, the AMF requests that the SMF(s) create(s) SM contexts for the prospective PDU sessions while also indicating that a handover is in progress. This indication prevents the UP switch until the handover is executed while still allowing the SMF to prepare and provision the UPFs involved. In its response to the AMF, the SMF includes N2 information destined for the target gNodeB, which the AMF conveys in a Handover Request message. The target gNodeB acknowledges this request and includes QoS and UP tunnel information that the AMF then communicates to the SMF in the form of an SM context update, which may cause the SMF to perform an N4 session modification.
Now that the 5GS is prepared for the handover, the AMF responds to the MME’s Forward Relocation Request, triggering the MME to initiate downlink data forwarding and issue the Handover Command to the eNodeB which then instructs the UE to connect to the target cell in the NG RAN. When the connection is established the UE notifies the target gNodeB and can then receive any buffered downlink data. The target gNodeB notifies the AMF that the handover is complete, causing the AMF to send a Forward Relocation Complete Notification to the MME, triggering resource clean up in the EPS.
Finally, the AMF notifies the SMF that the handover is complete through another SM context update, indicating that downlink data can be routed directly to the UE. The SMF may request a policy decision from the PCF at this time and may, if it hasn’t already done so, register with the UDM (Nudm_UECM) that it is serving the UE’s PDU session. The UE completes the handover process by registering with the 5GS.
Use dsTest’s array of 4G and 5G node emulators to test the conformance, capacity, and performance of your N26 peer.
- Initiate EPS to 5GS handovers with our MME node.
- Verify N1/N2 signalling and simulate the relocation complete transaction with our gNodeB emulator.
- Validate Nsmf_PDUSession utilization with our SMF emulator and, optionally, our REST dictionary.
- Provide subscription, authentication, and policy services to your AMF with our Nudm, Nausf, and Npcf service emulators.
- Initiate 5GS to EPS handovers with our AMF node.
- Verify S1-MME signalling and simulate the relocation complete transaction with our eNodeB emulator.
- Verify S11 signalling with our SGW emulator.
- Support UE authentication and authorization with our HSS emulator.
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.
REST Dictionary — Add conformance testing to your performance or functional test with our REST Dictionary. You can validate message types and JSON structures by simply including our base dictionary. In addition, you can build custom dictionaries to explicitly define required parameter and property values and selectively include the dictionary to be used for a particular test.
dsTest provides rich sets of measurements for the XX 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