Why This Scenario Exists

4G-to-5G interworking is not only a radio access problem. It is also a core network continuity problem. On the radio side, the access point changes from eNodeB to gNodeB. On the core side, the mobility anchor changes from MME to AMF. At the same time, some functions may remain logically continuous because they are deployed in combined forms. For example, HSS and UDM may be co-located, PGW-C and SMF may be combined, and PGW-U and UPF may be combined. This allows the network to reuse part of the existing 4G service context while moving the UE into the 5G system.

The procedure discussed here assumes single-registration mode with the N26 interface. N26 allows AMF and MME to exchange UE context. This is the main reason the 5G side does not need to rebuild everything from zero. Without this context exchange, the 5G registration would rely on a different interworking approach, and session continuity would be handled differently.

The “idle” part of the scenario is just as important as the “4G to 5G” part. The UE is not in an active connected-state handover. It has already gone into ECM-IDLE on the LTE/EPC side. Therefore, the main task is not to switch a live user-plane tunnel in real time. The main task is to migrate and interpret the UE context so that 5GC can continue managing the subscriber after the UE registers in 5G coverage.

What Changes in the Network

The most visible change is on the RAN side. The UE was originally served by an LTE eNodeB and later connects through a 5G gNodeB. The gNodeB receives the UE’s registration-related signaling and forwards it toward the selected AMF. This is the first step in moving the UE from the LTE/EPC access environment into the 5GS access environment.

The core-side change is more complex. In 4G, the MME holds mobility management information and has the UE’s MM and SM context after attachment and default bearer establishment. In 5G, the AMF becomes responsible for access and mobility management. During this procedure, the AMF needs to obtain the UE context from the MME so it can build the correct 5G-side mobility context.

The user-plane and session-control anchors may not change physically if PGW-C is combined with SMF and PGW-U is combined with UPF. This combined deployment makes the transition easier to understand: the UE changes access and mobility control domain, while the service anchor can remain logically continuous. The registration update helps the 5G core learn what already existed on the 4G side.

In practical terms, the network is not simply “logging the user into 5G.” It is translating a 4G mobility and bearer state into a 5G mobility and session-management framework. That is why the procedure includes GUTI mapping, context request, context response, UDM registration, policy retrieval, SM context creation, and final registration acceptance.

How Registration Actually Starts

Before the UE can register through 5G access, it needs an identity that the 5G network can understand. In this scenario, the UE maps the existing 4G-GUTI into a 5G-GUTI according to the interworking rules. This mapped identity is not the same as a native 5G-GUTI assigned in a previous 5G registration, but it gives the network enough information to locate the related 4G-side context.

The UE then sends a NAS Registration Request. The registration type is Mobility Registration Update. The request may include the mapped 5G-GUTI, UE status information, and an EPS NAS Message Container carrying a TAU Request. The UE status is meaningful because the device is not registered in N1 mode but is still registered in S1 mode. That tells the network this is not a clean standalone 5G start; it is an interworking case from the EPS side.

The gNodeB then forwards the registration request to an AMF. AMF selection depends on the identity information available in the RRC signaling. If the UE has a native 5G-GUTI, the gNodeB may route toward the related AMF based on the GUAMI. If the UE only provides a mapped identity from EPS, the gNodeB may select a new AMF based on the mapped GUAMI information.

This first part of the procedure sets the direction for everything that follows. The AMF must now understand where the UE came from, which MME may hold the 4G context, and how to request that context over the correct interface.

How Context Moves Through N26

After receiving the registration request, the AMF extracts information from the mapped 5G-GUTI. It can convert the GUAMI-related information into a form that helps identify the corresponding MME. The AMF then constructs the MME node FQDN and uses DNS to obtain the MME’s S10 interface address. This step is necessary because the AMF needs a transport path to request the UE context from the MME.

The AMF sends a GTPv2 Context Request to the MME. The request may include RAT Type set to NR, the mapped 4G-GUTI, the complete TAU request message copied from the Registration Request, and S10 addressing information such as IP address and TEID. This is where N26 becomes visible in the procedure. The AMF is not guessing the UE state; it is asking the MME for the context that already existed in EPC.

The MME uses the 4G security context to verify the TAU request and then looks up the UE context based on the UE identity. If the context is found and accepted, the MME returns a GTPv2 Context Response. This response can include the IMSI, MM context, security-related information, UE-AMBR, selected NAS integrity and ciphering algorithms, access restriction information, and PDN connection information.

The PDN connection information is especially useful because it links the 4G bearer world to the later 5G session-management steps. It may include APN, EBI, APN-AMBR, PGW-side S5-C information, bearer context, bearer QoS, and PGW-side S5-U information. The AMF can then transform the received EPS MM Context into a 5G MM Context.

There may also be an old AMF context transfer in some cases. If the UE had previously been in 5G, moved to 4G, and then returned to 5G, the registration request may carry an Additional GUTI. In that situation, the AMF may contact the old AMF to obtain UE context. But this is optional and does not appear in every 4G-to-5G idle mobility scenario.

How 5GC Completes the Update

Once the AMF has the needed context, the procedure starts to look closer to a normal 5G mobility registration process. The AMF interacts with UDM/HSS to complete 3GPP access registration, obtain access and mobility subscription data, retrieve SMF selection subscription data, and subscribe to future subscription-data changes. These steps ensure that the AMF has the correct subscriber information for 5G access management.

The AMF may also interact with the NRF to discover the correct network functions. For example, when the AMF needs UDM services, it can discover a UDM that supports the required service such as SDM or UECM. When it needs to work with the SMF, it can use information related to the PGW-C/SMF FQDN and discover the SMF’s N11 interface address through NRF-related procedures.

Policy control also appears in the procedure. If the AMF already received usable PCF information from the old AMF, it may continue using that PCF. Otherwise, it can select a PCF and obtain access and mobility policy control information. The policy response may include access restrictions such as areas or tracking areas where access is not allowed.

The SMF-related part converts the session side of the inherited EPS context into the 5G service framework. The AMF asks the PGW-C/SMF to create SM context using the EPS PDN connection information received from the MME. The request can carry EPS context, the list of PDU sessions to activate if present, and the EPS bearer context status reported by the UE. A response with an activating state indicates that user-plane resources such as the N3 tunnel are being prepared.

Finally, the old EPC registration is cleaned up. The HSS/UDM may trigger Cancel Location toward the MME, and the MME may notify the SGW to release related resources. Then the AMF sends Registration Accept to the UE. This message can include the new 5G-GUTI, allowed NSSAI, T3512, TA list, and EPS Bearer Status. The UE checks the received EPS Bearer Status and removes local QoS Flow rules or QoS parameters that are not associated with the indicated EPS bearer status. The UE then sends Registration Complete.

Why Idle Mobility Is Different

The key point in this procedure is that the UE was idle when it moved into 5G coverage. Because there is no active connected-state user-plane handover, the network does not need to perform a real-time tunnel switch for an ongoing data session in the same way it would during connected mobility. Instead, the focus is on context migration and registration update.

This explains why the procedure spends so much effort on identity mapping, DNS discovery, context request, MM context conversion, UDM registration, policy retrieval, and SM context creation. The network is reconstructing the UE’s 5G-side control-plane state from the 4G-side state. It is not simply forwarding an active radio connection from eNodeB to gNodeB.

For engineers studying signaling, this distinction helps avoid a common misunderstanding. Seeing 4G-to-5G mobility does not automatically mean handover. If the UE is idle, the procedure is more like controlled re-registration with inherited context. If the UE is connected and actively moving, the network must consider radio handover and real-time user-plane continuity in a different way.

This is also why a scenario-based explanation is often easier to understand than a single large standard diagram. A standards diagram may include many optional steps and combined scenarios. A practical explanation can narrow the view: a UE attached in 4G, entered idle state, moved into 5G coverage, and used N26 to transfer context from MME to AMF.

Final Notes

The 4G-to-5G idle mobility procedure is not just a simple coverage change. It is a structured interworking process that allows a UE previously attached in LTE/EPC to register in 5GS through Mobility Registration Update. The procedure depends heavily on N26 when the network wants to transfer UE context between MME and AMF.

The most important logic is context continuity. The UE maps 4G-GUTI to 5G-GUTI, the gNodeB forwards the registration request, the AMF discovers the MME, the MME returns EPS MM and SM context, and the AMF converts and continues the registration on the 5G side. UDM, NRF, PCF, and SMF interactions then complete subscription, discovery, policy, and session-context preparation.

For network learning, the practical lesson is clear: idle mobility from 4G to 5G mainly performs UE context migration from EPC to 5GC. It should not be confused with connected-state handover, where the real-time user-plane path must be switched while the UE remains active.

FAQ

What is the registration type in this scenario?

The registration type is Mobility Registration Update. It is different from initial registration because the UE already has 4G-side context from previous LTE/EPC attachment.

Why is the N26 interface important?

N26 allows AMF and MME to exchange UE context. This lets the 5G core obtain mobility and session-related information that was previously held in EPC.

What changes when the UE moves from 4G to 5G?

The access side changes from eNodeB to gNodeB, and the mobility management function changes from MME to AMF. Some combined core functions, such as HSS/UDM or PGW-C/SMF, may remain logically continuous.

Does idle mobility require real-time user-plane handover?

No. In this scenario, the UE is idle, so the main task is context migration and registration update rather than real-time user-plane tunnel switching.

What does the UE receive at the end?

The UE receives Registration Accept, which may include a new 5G-GUTI, allowed NSSAI, registration timer, tracking area list, and EPS Bearer Status. The UE then completes the procedure with Registration Complete.