Handover¶

Learning objectives¶

After reading this page, you will be able to:

• Explain the Why (why handover is necessary) from the perspective of maintaining communication and preserving the session/IP during mobility.
• Contrast and explain the difference between Xn-based Handover and N2-based Handover (their applicability conditions and the degree of core involvement).
• Explain what Path Switch (the procedure that, after an Xn HO completes, re-points the N3 downlink path to the new gNB) does.
• Follow the flow of the N3 path switch in handover (updating the gNB-side TEID, the coordination of AMF→SMF→UPF).
• Explain, from the core's perspective, that the leading actors in handover are the AMF (N2 control) and the SMF/UPF (N3 path switch).
• Use Wireshark Display Filters to name the focal points for analyzing the NGAP Handover-family / Path Switch packets.
• Contrast the differences between 4G (EPC)'s X2-based HO / S1-based HO and 5G's Xn-based / N2-based HO.

Prerequisites¶

It will go more smoothly if you understand the following first. If you are not there yet, start from the Curriculum.

• Completion of Registration (the UE is registered = 5GMM-REGISTERED) → Initial Registration
• Establishment of a PDU Session (the user plane to be switched is set up) → PDU Session Establishment
• N2 / N3 (the gNB⇔AMF control path, and the gNB⇔UPF user-plane path) → N2 / N3
• The roles of the main NFs → AMF / SMF / UPF

What you'll learn in this chapter¶

This chapter focuses narrowly on Inter-gNB Handover (handover between base stations), and of that, it covers the two types Xn-based and N2-based. It is the procedure that switches a moving UE's connection from its current base station (Source gNB) to the next base station (Target gNB) without interrupting communication.

This chapter focuses on the involvement of the core (5GC). That is, it centers on:

• how the AMF mediates and controls handover with N2 control
• how the SMF/UPF switch the N3 user-plane path to the new gNB

The following are out of scope for this chapter (they are touched on, but not gone into in detail).

• The detailed radio (RRC) side procedures (handover execution via RRC Reconfiguration, the details of radio resource allocation)
• The details of the Measurement Report (the radio-side decision logic for how the UE measures neighbor cells and when it triggers the HO)
• Intra-gNB Handover (switching between cells within the same gNB), Inter-System Handover (between 5G and 4G), and the like are out of scope. Inter-System Handover is covered in 4G-5G Interworking.

These are topics on the radio access side (inside the gNB), and this chapter, which takes the core's perspective, keeps them at an overview level.

Why — why handover is necessary¶

Let's start from the Why (why it is needed). A UE (smartphone, etc.) moves. As it keeps communicating while walking or riding a train, the signal of the base station it is currently connected to (Source gNB) grows steadily weaker, while conversely the signal of another base station in the direction of travel (Target gNB) grows stronger.

If nothing were done here, sticking with the base station with the weak signal would cause calls to drop, videos to stall, and downloads to be interrupted. To prevent this, the connection must be switched over to a "base station with good signal" while communication continues. This switchover is Handover.

There are two things we want to preserve across a handover.

1. Session continuity — carry over the already-established PDU Session (the pipe for data communication) without re-establishing it.
2. IP address preservation — the UE's IP address as seen by the application does not change (so TCP connections and application sessions are not broken).

The purpose of handover is to switch only the radio segment and the core's user-plane path, as close to make-before-break (no interruption) as possible, while keeping these preserved.

Overview¶

The trigger for a handover is basically degradation of radio quality. Based on the UE's Measurement Report (the radio-side details are out of scope), the Source gNB judges "this should be moved to the Target gNB" and initiates the handover. The purpose is a make-before-break path switch that preserves the session/IP.

Inter-gNB Handover comes in two types, depending on whether there is an Xn interface between neighboring gNBs and whether core relocation is required.

(The applicability conditions and message names are based on the Handover procedures of TS 23.502. The finer details of individual message names/ordering are covered in Procedure, and some are marked to be confirmed.)

flowchart LR
    UE([UE]) -.move.-> UE2([UE])
    S["Source gNB"] -->|"Xn direct coordination
(Xn-based)"| T["Target gNB"]
    S -->|"coordination via N2
(N2-based)"| AMF[AMF]
    AMF --> T
    T -->|"Path Switch / N3 switch"| CORE{AMF→SMF→UPF}

Basic Concept — a beginner-friendly explanation¶

To understand handover, grasp three keywords.

1. What handover is (What)¶

Handover is the procedure that moves a UE's radio connection from Source gNB → Target gNB while communication continues. What is mainly moved is the following two things.

• UE context — the information about who that UE is, and what security and what PDU Session/QoS Flow it has. The Target gNB takes this over.
• User-plane path — the route over which the actual data flows. Both the radio segment (UE⇔gNB) and the core-side N3 (gNB⇔UPF) are switched toward the new gNB.

The switching of the radio segment (RRC Reconfiguration) is handled by the gNB and the UE, and its details are out of scope for this chapter. This chapter concentrates on the core-side (N3) switch.

2. How to choose between Xn-based and N2-based¶

• Xn-based — when there is an Xn interface (a link connecting gNBs directly) between the Source and Target gNB. The gNBs coordinate directly with XnAP — "get ready to accept this from now" / "preparation OK." The core (AMF) is not involved in the preparation and handles only the post-execution Path Switch. Its advantage is being light and fast.
• N2-based — when there is no Xn, or when AMF/UPF relocation is required. Since the gNBs cannot talk directly, the AMF mediates over N2. It becomes a three-party coordination of Source gNB → AMF → Target gNB, with the core involved from the preparation phase.

3. Path Switch and the N3 path switch¶

Even after the radio segment moves to the Target gNB in a handover, the delivery destination of the downlink data as seen from the core (UPF) is still the Source gNB. Unless this is re-pointed to the new gNB, downlink packets will arrive at the old base station.

• Path Switch — after an Xn-based HO completes, the Target gNB sends an NGAP Path Switch Request to the AMF, requesting "please point this UE's downlink path to me (the new gNB)." That is the procedure.
• N3 path switch — upon receiving this, the AMF passes it to the SMF, and the SMF updates the UPF's forwarding rule (the destination of the downlink FAR) to the new gNB's N3 TEID/address via N4 (PFCP). This makes the downlink N3 (GTP-U) flow to the new gNB.

In other words, think of Path Switch = "the new gNB notifies the core of its new address", and N3 path switch = "the UPF rewrites the downlink delivery destination to the new address." In an N2-based HO too, an equivalent N3 switch is performed within the Handover procedure.

Architecture¶

The elements involved in Inter-gNB Handover and the interfaces that connect them. The Xn path (direct between gNBs) and the N2 path (AMF-mediated) are drawn separately.

flowchart LR
    UE([UE])
    S["Source gNB"]
    T["Target gNB"]
    AMF[AMF]
    SMF[SMF]
    UPF[UPF]
    DN[(Data Network)]

    UE -. "move" .-> T
    UE -- "radio (RRC)" --> S
    S == "Xn (XnAP): HO preparation/execution (Xn-based)" ==> T
    S -- "N2 (NGAP): Handover Required, etc. (N2-based)" --> AMF
    AMF -- "N2 (NGAP): Handover Request/Command" --> T
    T -- "N2 (NGAP): Path Switch Request" --> AMF
    AMF -- "Nsmf (N11-equivalent)" --> SMF
    SMF -- "N4 (PFCP)" --> UPF
    S -. "N3 (old path)" .-> UPF
    T == "N3 (GTP-U new path)" ==> UPF
    UPF == "N6" ==> DN

The role of each element is as follows.

• UE — the moving terminal. It switches over to the Target gNB on the radio side (the RRC procedure is radio-side, out of scope). The session/IP is maintained.
• Source gNB (old base station) — the current connection source. It initiates the HO, and coordinates with the Target gNB over Xn in Xn-based, or via N2 (the AMF) in N2-based. After the switch it may forward residual data on the old N3 path (data forwarding).
• Target gNB (new base station) — the move destination. It accepts the UE context, and in Xn-based sends a Path Switch Request to the AMF after completion.
• AMF — the N2 command center. In N2-based it controls the preparation/execution of the Handover; in Xn-based it receives the Path Switch and bridges to the SMF.
• SMF — session management. Upon receiving the notification from the AMF, it updates the UPF's N3 downlink path to the new gNB via N4 (PFCP). It judges whether UPF relocation is needed.
• UPF — the actual user-plane forwarder. On the SMF's instruction, it rewrites the destination of the downlink N3 (the gNB-side TEID/address). If the anchor UPF is maintained, the IP is unchanged.
• Xn — the interface that directly connects neighboring gNBs (the protocol is XnAP).

For the details of the interfaces, see the Interface Dictionary.

Network Function (the NFs that appear)¶

The roles of the core-side NFs that appear in handover. The gNB is on the radio access side and is not a core NF (since the leading actors in this chapter are viewed from the core's perspective, the gNB is treated as radio-side).

(The HO preparation/execution between gNBs themselves is a role on the radio access side, and this table is limited to core NFs.)

Interface / Protocol¶

The interfaces and protocols used in this procedure.

For the details of protocols, see the Protocol Dictionary; for the list of interfaces, see the Interface Dictionary.

Procedure — Call Flow¶

This is the heart of this page. The main steps of Inter-gNB Handover, conforming to 3GPP TS 23.502 §4.9.1 (Handover procedures), are shown split into Xn-based and N2-based using Mermaid sequenceDiagrams.

Xn-based Handover¶

The case where there is an Xn between the Source and Target gNB and the gNBs coordinate directly. The core's involvement centers on the post-execution Path Switch (N3 downlink path switch).

sequenceDiagram
    autonumber
    participant UE
    participant S as Source gNB
    participant T as Target gNB
    participant AMF
    participant SMF
    participant UPF

    Note over UE,S: radio quality degradation → HO decision (Measurement Report, etc. / radio-side / out of scope)
    S->>T: Handover Request (XnAP)
    Note right of S: TS 38.423 (XnAP)
    T-->>S: Handover Request Acknowledge (XnAP)
    Note over S,T: Target prepares UE context/resources
    S->>UE: HO execution instruction (RRC Reconfiguration / outline / out of scope)
    Note over UE,T: UE radio-syncs and switches to the Target gNB
    UE->>T: HO complete (RRC Reconfiguration Complete / outline / out of scope)
    opt Data forwarding (optional)
        S-->>T: forward undelivered data over Xn
    end

    Note over T,AMF: from here, the core's Path Switch (N3 downlink path switch)
    T->>AMF: Path Switch Request (NGAP)
    Note right of T: notify the new gNB's N3 TEID/address
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (new gNB N3 info)
    SMF->>UPF: N4 Session Modification Request (PFCP)
(update downlink FAR to the new gNB N3 TEID)
    UPF-->>SMF: N4 Session Modification Response
    Note over T,UPF: downlink N3 (GTP-U) switched to the new gNB
    opt End Marker (a marker for the end of the old path)
        UPF-->>S: End Marker (indicates the end of the old N3 path)
    end
    SMF-->>AMF: UpdateSMContext Response
    AMF-->>T: Path Switch Request Acknowledge (NGAP)
    T->>S: UE Context Release (XnAP)
    Note over UE,UPF: switch complete / communication continues

N2-based Handover¶

The case where there is no Xn, or AMF/UPF relocation is required. The AMF mediates preparation/execution over N2.

sequenceDiagram
    autonumber
    participant UE
    participant S as Source gNB
    participant AMF
    participant SMF
    participant UPF
    participant T as Target gNB

    Note over UE,S: radio quality degradation → HO decision (radio-side / out of scope)
    S->>AMF: Handover Required (NGAP)
    Note right of S: specify the Target gNB / TS 23.502 §4.9.1.3

    Note over AMF,SMF: preparation phase (SMF judges UPF relocation if needed)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (HO preparation)
    SMF->>UPF: N4 Session Modification (prepare required resources)
    UPF-->>SMF: N4 Response
    SMF-->>AMF: UpdateSMContext Response

    AMF->>T: Handover Request (NGAP)
    T-->>AMF: Handover Request Acknowledge (NGAP)
    Note over AMF,T: Target prepares accept resources / N3 TEID

    AMF->>S: Handover Command (NGAP)
    S->>UE: HO execution instruction (RRC Reconfiguration / outline / out of scope)
    Note over UE,T: UE switches to the Target gNB
    UE->>T: HO complete (radio-side / out of scope)
    T->>AMF: Handover Notify (NGAP)

    Note over AMF,UPF: execution phase (finalize the N3 downlink path to the new gNB)
    AMF->>SMF: Nsmf_PDUSession_UpdateSMContext (HO completion notification)
    SMF->>UPF: N4 Session Modification Request (PFCP)
(update downlink FAR to the new gNB N3 TEID)
    UPF-->>SMF: N4 Session Modification Response
    opt End Marker
        UPF-->>S: End Marker (end of the old N3 path)
    end
    SMF-->>AMF: UpdateSMContext Response
    Note over AMF,S: release the old resources
    AMF->>S: UE Context Release Command (NGAP)
    Note over UE,UPF: switch complete / communication continues

Step-by-step explanation (numbers correspond to each diagram)¶

Xn-based (upper diagram)

1. S→T: Handover Request (XnAP). The Source gNB directly asks the Target gNB "please accept this UE" (TS 38.423).
2. T→S: Handover Request Acknowledge (XnAP). The Target prepares the UE context/radio resources and consents. 3-5. Radio-side HO execution (outline / out of scope): the Source instructs the UE to execute over RRC, and the UE syncs and switches to the Target gNB and completes. (Data forwarding is optional, forwarding undelivered data S→T.)
3. T→AMF: Path Switch Request (NGAP). The Target gNB requests the AMF "point the downlink path to me." It notifies the new gNB's N3 TEID/address.
4. AMF→SMF: conveys the new gNB's N3 info via Nsmf_PDUSession_UpdateSMContext.
5. SMF→UPF: updates the destination of the downlink FAR to the new gNB's N3 TEID via N4 Session Modification (PFCP). → the downlink N3 (GTP-U) is switched to the new gNB (an End Marker may be sent as a marker for the end of the old path).
6. AMF→T: Path Switch Request Acknowledge (NGAP).
7. T→S: UE Context Release (XnAP). Releases that UE's resources on the old gNB.

N2-based (lower diagram)

1. S→AMF: Handover Required (NGAP). Since Xn cannot be used, it asks the AMF to mediate. Specifies the Target gNB.
2. Preparation phase: AMF→SMF UpdateSMContext, SMF→UPF N4 Modification to arrange the required resources (if UPF relocation is needed, prepare the new UPF).
3. AMF→T: Handover Request (NGAP) / T→AMF Handover Request Acknowledge (NGAP). The Target prepares the accept resources and the N3 TEID.
4. AMF→S: Handover Command (NGAP). Instructs the Source "you may execute."
5. Radio-side HO execution (outline / out of scope) → the UE switches to the Target.
6. T→AMF: Handover Notify (NGAP). Notifies that the switch is complete on the Target side.
7. Execution phase: AMF→SMF UpdateSMContext (HO complete) → SMF→UPF N4 Modification to update the downlink FAR to the new gNB N3 TEID (an End Marker may be sent).
8. Release the old resources: AMF→S UE Context Release Command (NGAP).

Reference: TS 23.502 §4.9.1 (Handover procedures. Xn-based around §4.9.1.2, N2-based around §4.9.1.3. The fine-grained section numbers are to be confirmed), TS 38.413 (NGAP: Handover-family / Path Switch), TS 38.423 (XnAP: Handover-family).

Signal Flow¶

The key Messages / service operations organized in a table. The IEs are made consistent with the Message Dictionary.

For the detailed IEs and reference specs of each Message, see the Message Dictionary (the individual IE names of the Handover-family / Path Switch are version dependent and some are to be confirmed).

State Machine¶

The state picture during a handover is conceptualized from the perspective of the UE's connection (CM: Connection Management) and from the perspective of the progress of the N2 HO procedure (basis: TS 23.501 §5.3 (CM states) / TS 23.502 §4.9.1 (HO procedures). Some of the state names are conceptual expressions for understanding and are to be confirmed).

stateDiagram-v2
    [*] --> CONNECTED_SOURCE
    CONNECTED_SOURCE --> HO_PREPARATION: HO initiation (radio quality degradation)
    HO_PREPARATION --> HO_EXECUTION: Target preparation complete (Ack / Command)
    HO_EXECUTION --> PATH_SWITCHING: UE switch to Target complete
    PATH_SWITCHING --> CONNECTED_TARGET: N3 downlink path switch complete (Path Switch Ack / N4 update)
    HO_PREPARATION --> CONNECTED_SOURCE: preparation failure (HO abort)
    HO_EXECUTION --> CONNECTED_SOURCE: execution failure / fallback
    CONNECTED_TARGET --> [*]

• CONNECTED_SOURCE — connected to the Source gNB and in data communication (CM-CONNECTED).
• HO_PREPARATION — HO in preparation (Xn-based: Handover Request/Ack; N2-based: Handover Required→Request/Ack). Returns to Source on preparation failure.
• HO_EXECUTION — radio-side HO in execution (RRC switch. outline / out of scope). May fall back on failure.
• PATH_SWITCHING — core-side N3 downlink path switch in progress (Path Switch / N4 Modification).
• CONNECTED_TARGET — switch to the Target gNB complete. Communication continues.

Packet Analysis (Wireshark)¶

Because Inter-gNB Handover spans N2 (NGAP) / Xn (XnAP) / N3 (GTP-U), you use different filters per segment.

Key Display Filters¶

Points to note when decoding (key points)¶

• NGAP Handover-family procedureCode — Handover Required / Request / Command / Notify (N2-based). Identify the message type by the procedureCode name.
• NGAP Path Switch Request / Acknowledge — the key messages of the N3 downlink path switch that reach the core after an Xn-based completion.
• XnAP Handover procedure — the direct coordination between gNBs of Xn-based (Handover Request / Acknowledge). Observable only when you can capture the Xn segment.
• TEID changes — the way the destination TEID/address of the downlink tunnel of N3 (GTP-U) switches from Source gNB → Target gNB. Comparing gtp.teid just before and after the switch lets you observe the effect of the path switch. The End Marker also lets you confirm the end of the old path.

The structure in which information nests inside NGAP¶

The NGAP Handover-family messages carry UE context and PDU Session/QoS Flow information nested inside. In Path Switch, the new gNB's U-Plane (N3 TEID) information is included.

NGAP-PDU
 └─ HandoverRequired / PathSwitchRequest, etc.
     └─ PDU Session Resource (QoS Flow / N3 TEID info)
         └─ (the old and new gNB's U-Plane transport info)

Configuration¶

The structural-level key points of the configuration for making a handover work. Specific values and vendor-specific details (Cisco, etc.) are implementation dependent, and no fictitious values are written here. Much of the HO preparation, execution decision, and Xn neighbor relations are radio access side (gNB) configuration, and the core (5GC) side configuration is limited.

On the gNB side (radio access / out of scope, but key points only)¶

• Xn neighbor relations — with which neighboring gNBs to set up an Xn (the premise of Xn-based HO). For a counterpart with no Xn, it falls back to N2-based.
• Measurement / HO decision parameters — thresholds and hysteresis for neighbor cell measurements, etc. (radio-side, details out of scope).

On the core (AMF/SMF/UPF) side¶

• AMF — the N2 (NGAP) must be established, and it must be able to process the Handover-family / Path Switch procedures. It must accommodate multiple gNBs and hold the context of the target UE.
• SMF/UPF — the PDU Session must be established, the N4 (PFCP) association must be established, and the configuration must be able to update the destination of the downlink FAR (the gNB-side N3 TEID).
• UPF relocation (when needed in N2-based) — if switching to a new UPF, the SMF's UPF selection and the handling between the old and new UPF depend on the configuration.

Trouble Shooting¶

Isolating typical handover failures. For the details of Cause values, see the Cause Dictionary.

Comparison with EPC¶

A comparison so that those experienced with 4G (EPC) can bridge to 5G's handover. 4G also has two types — "direct between base stations" and "core-mediated" — and 5G is a design that maps these to Xn / N2.

Release differences¶

The main topics related to handover. Uncertain items are marked to be confirmed and not asserted.

• Rel-15 — the basics of 5GC's core handover (Xn-based / N2-based Inter-gNB HO, Path Switch, N3 path switch) were established.
• Rel-16 — said to be the generation in which mobility enhancements such as Conditional Handover (CHO) were introduced (the extent to which they were woven into the HO procedure itself / core involvement is to be confirmed). CHO is a mechanism that prepares multiple Target candidates in advance and has the UE execute autonomously when a condition is met, thereby reducing HO failures (call drops).
• Rel-17 / Rel-18 (5G-Advanced) — further extensions of mobility continue (the specific differences to the HO procedure are to be confirmed).

3GPP Specification¶

FAQ¶

Summary¶

• Handover is the procedure that switches a moving UE's connection from Source gNB → Target gNB, while preserving the session/IP, in a near-make-before-break manner. The trigger is degradation of radio quality.
• Inter-gNB HO comes in two types, depending on the presence of Xn and whether core relocation is required — Xn-based (direct between gNBs + Path Switch) and N2-based (AMF-mediated).
• From the core's perspective, the leading actors are the AMF (N2 control) and the SMF/UPF (N3 path switch). The radio (RRC) side details and the Measurement Report are out of scope for this chapter.
• Path Switch is the procedure by which, after an Xn-based completion, the Target gNB requests the AMF for a downlink path switch. AMF→SMF→UPF update the downlink FAR to the new gNB N3 TEID via N4 (PFCP) (the N3 path switch).
• If the anchor UPF is maintained, the IP is unchanged. Data forwarding / End Marker mitigate packet loss.
• Corresponding to 4G's X2-based / S1-based HO, 5G has Xn-based / N2-based. The idea of a Path Switch Request continues from 4G.
• The basis is TS 23.502 §4.9.1 / TS 38.413 (NGAP) / TS 38.423 (XnAP) / TS 38.300 / TS 23.501 (the fine-grained section numbers and some message ordering are to be confirmed).

Practice — comprehension check and exercises¶

Comprehension check¶

Exercises¶

Problem: Reorder the following main Xn-based Handover steps into the correct order.

A. Target gNB → AMF: Path Switch Request (NGAP)
B. Source gNB → Target gNB: Handover Request (XnAP)
C. SMF → UPF: N4 Session Modification (downlink FAR to the new gNB N3 TEID)
D. Target gNB → Source gNB: Handover Request Acknowledge (XnAP)
E. AMF → Target gNB: Path Switch Request Acknowledge (NGAP)
F. Radio-side HO execution (UE switches to the Target gNB / outline / out of scope)
G. AMF → SMF: Nsmf_PDUSession_UpdateSMContext

Next Step¶

The next steps to deepen your understanding.

• Paging chapter (calling a CM-IDLE UE — the other pillar of mobility)
• Service Request chapter (re-establishing the U-Plane on CM-IDLE→CM-CONNECTED)
• Prerequisites for the procedure: Initial Registration / PDU Session Establishment
• Related NFs: AMF / SMF / UPF
• Related Interfaces: N2 / N3 / Xn
• Dictionaries: Message Dictionary / Timer Dictionary / Cause Dictionary / Protocol Dictionary / NF Dictionary / Interface Dictionary