N26 — AMF ⇔ MME (mobility context transfer between 4G/5G)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N26 connects the 5GC's AMF ⇔ 4G/EPC's MME and is an interworking interface that transfers mobility context between 4G (EPS) ↔ 5G (5GS).
• Explain that N26 enables single-registration mode + Handover-based (connected mode) inter-system movement, supporting seamless 4G↔5G handover (and Handover-based EPS Fallback).
• Explain that N26 uses the EPC-family GTPv2-C (GTP-C), not an SBI (HTTP/2) like N14.
• Explain that the presence or absence of N26 is a network design choice, and that when absent it becomes single-registration without N26 (idle-mode redirection) or dual-registration mode.
• Explain the correspondence with 4G's S10 (MME ⇔ MME, GTP-C) / S3 (SGSN ⇔ MME, GTP-C) context transfer.

Prerequisites¶

The following are helpful to understand first:

• The context in which voice is established over 4G/5G interconnection (where N26 is used) → EPS Fallback
• The concept of inter-RAT / inter-system handover → Handover
• The 5G-side endpoint of N26 (the hub of mobility management) → AMF
• The concept of interfaces and reference points → Interface dictionary
• The entrance to the entire 4G/5G interworking procedure (the consolidation point of procedures) → Interworking

Why — why it is needed¶

A UE moves across the boundary of 4G and 5G. A UE that was communicating in 5G (NR/5GC) may move into a 4G (LTE/EPC) area, or vice versa (coverage boundaries, EPS Fallback in cells not supporting VoNR, etc.). At this time, the destination network does not know who that UE is, in what state, what bearers/sessions it had established, and with what security it was communicating.

If nothing were carried over, the UE would have to be handled from scratch every time it moves. Registration would be redone, in-progress EPS bearers/PDU sessions would be lost, and communication could be interrupted. This is a large burden on both the UE and the network and does not make for a seamless move.

Therefore, a route to carry over the mobility management context (UE state · EPS bearer/PDU session context · security context) between the 5GC's AMF and the 4G/EPC's MME is needed. This is N26. With N26, the UE can move seamlessly between 4G↔5G in single-registration mode + Handover-based (connected mode). Without N26, it is limited to single-registration without N26 (idle-mode redirection) or dual-registration mode idle-mode movement.

Analogy: N26 is the carry-over of immigration records when crossing a border. The set of the person's stay records (state · bearers · keys) held by the old country's (4G/MME) window is carried over as-is to the new country's (5G/AMF) window, so the person can smoothly cross the border without redoing immigration inspection from scratch. If N14 is "carry-over of the residence record between government offices of the same country (AMF⇔AMF)," then N26 is "a carry-over that crosses a border (4G⇔5G)."

Overview¶

N26 is a reference point connecting AMF (5GC) ⇔ MME (4G/EPC) and is an interworking interface that crosses the boundary of 4G (EPS) and 5G (5GS). Whereas many intra-5GC interfaces connect NFs within the 5GC, N26 is characteristic in that it spans the control-plane nodes of 4G and 5G (MME and AMF).

N26 is used when a UE moves across 4G↔5G. With N26, in single-registration mode, Handover-based (connected mode) inter-system movement (= a seamless handover that carries over state) becomes possible. What is transferred is the mobility management context such as UE state, EPS bearer/PDU session context, and security context.

Importantly, N26 is not an SBI (HTTP/2 + JSON) like N14. N26 uses the EPC-family control-plane protocol GTPv2-C (GTP-C v2). This is because it needs to collaborate with the 4G/EPC side (MME) using the same family of procedures and protocol.

Basic Concept — explanation for beginners¶

Let us compare N26 to the carry-over of immigration records when crossing a border.

When you move with your smartphone from a 4G area to a 5G area (or vice versa), the control-plane node in charge switches between MME (4G) and AMF (5G). However, the destination node does not know in what state you were until then, which bearers/sessions you had established, and with what security keys you were communicating.

Therefore, the source and destination windows (the MME and AMF) carry over your set of records (state · bearers/sessions · security) over a dedicated liaison route called N26. Thanks to carrying over the records, you can move without interrupting communication (seamlessly) even across the boundary. This is Handover-based (connected mode) movement.

The important thing here is that this 4G⇔5G exchange is not the Web API (SBI: HTTP/2 + JSON) that NFs within the 5GC use with each other. Because the counterpart is the 4G/EPC's MME, they converse over the 4G/EPC-family control-plane protocol (GTPv2-C). Keep in mind the difference: whereas N14 (AMF⇔AMF) was a Web-technology-based SBI, N26 uses EPC-inherited GTP-C.

Protocol / Transport¶

Architecture¶

This shows the context in which N26 connects AMF (5GC) and MME (4G/EPC), and the UE moves across the boundary of NG-RAN (NR) and eNB (LTE) (consistent with the Architecture of EPS Fallback).

graph LR
    UE["UE"] -- "N1(NAS)" --> AMF["AMF (5GC)"]
    UE -- "radio (NR↔LTE)" --> RAN["NG-RAN (gNB)"]
    RAN -- "N2" --> AMF
    AMF =="N26 (GTPv2-C)"==> MME["MME (4G/EPC)"]
    RAN -. "inter-system movement" .-> ENB["eNB (4G/LTE)"]
    MME --> ENB

    classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
    class AMF,MME ctrl;

How to read the diagram: The UE connects to the 5GC (AMF) via NG-RAN (gNB), or to the 4G/EPC (MME) via eNB. When the UE moves across the 4G↔5G boundary, the control-plane serving switches between MME (4G) ↔ AMF (5G). At this time, the thick-line (==>) N26 connects the AMF and MME over GTPv2-C and transfers the mobility management context (UE state · EPS bearer/PDU session · security). The dashed inter-system movement represents movement across NR and LTE on the radio side. With N26, this movement can be done seamlessly in Handover-based (connected mode). Note that N26 is strictly the collaboration of AMF ⇔ MME (the 4G/5G boundary).

Procedures used¶

N26 is used in scenes where a UE moves across the boundary of 4G (EPS) ↔ 5G (5GS). The three representative uses are as follows.

• (a) Inter-system Handover (connected mode) — the UE moves between 4G↔5G while still communicating (connected). Triggered by an NG-RAN/eNB handover, the AMF and MME carry over the context over N26 and move seamlessly while keeping state (single-registration + Handover-based).
• (b) Idle-mode inter-system movement — when the UE moves between 4G↔5G in idle, the destination node fetches the context from the source node over N26 within the TAU (4G side) / Registration (5G side) at the destination.
• (c) Handover-based EPS Fallback — when establishing a voice call in a cell not supporting VoNR, when moving the UE from 5GS→4G/EPS, the AMF⇔MME carry over the context over N26 and perform Inter-system Handover (see EPS Fallback).

The details of the procedures (message sequence, conditions, IEs, branches on success/failure, clause sub-numbers, etc.) are not repeated on this page. The entire interworking procedure is consolidated in Interworking, and the EPS-Fallback-specific flow in EPS Fallback. Refer there for the details of the procedure (operation names · invocation directions · clause numbers) (the details are to be confirmed).

Main Messages¶

Because N26 is GTPv2-C, messages take the form of GTP-C control messages (not HTTP method + resource operation like SBI). The GTP-C-family messages used in 4G/EPC handover / context transfer (illustrative · to be confirmed) are as follows.

The message names and IEs are to be confirmed: The message names in the table above (Forward Relocation Request/Response, Context Request/Response, etc.) are illustrations from the general GTP-C procedures of the EPC/S10 · S3 family; the exact message names, IEs, invocation directions, and clause numbers for N26 follow TS 29.274 (GTPv2-C) / TS 23.501 / 23.502 and differ by Release. Here we limit to illustration and leave the strict assignment to be confirmed. We do not assert N26-specific message names. For details of each message, refer to the Message dictionary.

Packet Analysis (Wireshark)¶

Because N26 is GTP-C (GTPv2-C), it is observed on capture as GTPv2 (SBI's HTTP/2, N4's PFCP, and N2's SCTP/NGAP do not appear).

Decode highlights:

• N26 is analyzed as GTPv2-C. Use the filter gtpv2.
• N26 is not an SBI. Therefore, http2 / json (SBI family), pfcp (N4), and sctp / NGAP (N2) filters are not used (they are irrelevant). This is a major difference from n14.
• The payload is displayed as GTP-C's message/IE structure (the group of IEs related to context transfer). The exact message type values and IE names are to be confirmed.

Comparison with EPC¶

• In 4G: When a UE moved to another control-plane node, it transferred the UE Context / mobility context over GTP-C-based interfaces (TS 29.274) such as S10 between MME ⇔ MME and S3 between SGSN ⇔ MME.
• In 5G: For context transfer that crosses the boundary of 4G and 5G, N26 (AMF ⇔ MME) was defined. Because the counterpart is the 4G/EPC's MME, N26 remains GTP-C (not turned into an SBI). This is the decisive difference from N14 (AMF⇔AMF, where the S10 equivalent was turned into an SBI).

Key point (frequently on exams): The role of context transfer of S10/S3 (GTP-C) is, in 5G, carried by N26 (AMF⇔MME) at the 4G/5G boundary. However, N26 remains GTP-C and is not turned into an SBI. On the other hand, the AMF⇔AMF N14, whose S10 equivalent was turned into an SBI (HTTP/2+JSON). Be sure to keep the contrast "N14 turned into an SBI / N26 remains GTP-C" firmly in mind.

3GPP Specification¶

• 3GPP TS 23.501 — 4G/5G interworking architecture, definition of N26 (AMF⇔MME). Positioning of single-registration/dual-registration · presence or absence of N26. Individual clause numbers are to be confirmed
• 3GPP TS 23.502 — Interworking procedures (Inter-system Handover / idle-mode movement / context fetch over N26). Individual clause numbers are to be confirmed
• 3GPP TS 29.274 — Specification of GTPv2-C (GTP-C v2) (the protocol used on N26, S10/S3-family messages). Individual clause numbers are to be confirmed
• 3GPP TS 23.501 §5.7.4 — Standardized 5QI table (5QI=1 ↔ QCI=1 conversational voice/GBR, 5QI=5 ↔ QCI=5 IMS signaling/Non-GBR). Used for reference to the 4G↔5G correspondence of bearers/QoS Flows

Note (to be confirmed): That N26 uses GTPv2-C, and that 4G/5G interworking is specified in TS 23.501/23.502, are general arrangements. N26-specific message names, IEs, exact ports, and clause sub-numbers differ by Release and implementation, so they are individually to be confirmed / implementation-dependent. The port UDP 2123 is limited to a mention as a conventional GTP-C value.

Summary¶

• N26 connects AMF (5GC) ⇔ MME (4G/EPC) and is an interworking interface that transfers the mobility management context (UE state · EPS bearer/PDU session · security) at the 4G (EPS) ↔ 5G (5GS) boundary.
• With N26, in single-registration mode + Handover-based (connected mode), seamless 4G↔5G handover is possible (Handover-based EPS Fallback also depends on this).
• N26 uses the EPC-family GTPv2-C (GTP-C), not an SBI (HTTP/2) like N14 (TS 29.274). The conventional port is said to be UDP 2123, but the exact specification is to be confirmed.
• The presence or absence of N26 is a network design choice. When absent, it becomes single-registration without N26 (idle redirection) or dual-registration mode.
• It corresponds to 4G's S10 (MME⇔MME) / S3 (SGSN⇔MME) GTP-C context transfer, but N26 remains GTP-C (not turned into an SBI) and characteristically spans AMF⇔MME. This contrasts with N14, which was turned into an SBI.

Next Step¶

• Interworking — the consolidation point of 4G/5G interconnection procedures (details of the N26 usage procedure)
• EPS Fallback — a concrete example of the role N26 plays in Handover-based migration
• AMF — the 5G-side endpoint of N26. The hub of mobility management
• Handover — details of Inter-system Handover (connected-mode movement)
• Interface dictionary — check the list of reference points · interfaces