N14 — AMF ⇔ AMF (inter-AMF UE-context transfer)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N14 is an SBI (Service Based Interface) connecting same-NF-type peers (AMF).
• Explain that N14 is for transferring the UE context from the old AMF (source/old) to the new AMF (target/new) when a UE moves into an area served by a different AMF.
• Explain the contents of the transferred UE context (registration state, 5G security context (K_AMF, etc.), PDU session references, allowed NSSAI, etc.).
• Explain that the substance of N14 is the inter-AMF cooperation operations of the service Namf_Communication (TS 29.518) provided by AMF.
• Explain the correspondence with the UE Context transfer of 4G (EPC) S10 (MME ⇔ MME, GTP-C).

Prerequisites¶

Understanding the following first will make things smoother.

• The positioning of SBA / SBI and HTTP/2 · TLS → Protocol dictionary
• The NFs at both ends of N14 (the same AMF) → AMF
• The concept of UE context, 5G security context, and mobility → Registration / Security
• The concept of interfaces and reference points → Interface dictionary

Why — why it is needed¶

UEs move. A UE may move from the serving area of the AMF in charge of one region into the area another AMF is in charge of (mobility registration update, AMF reallocation, a change of target AMF at N2 handover, etc.). At this time, the newly serving AMF (the new AMF) does not know who that UE is, in what state, and with what security it was communicating.

If nothing were carried over, the new AMF would have to handle the UE from scratch all over again. It would redo authentication, rebuild the registration state, and might even lose the references to in-progress PDU sessions. This is a large burden on both the UE and the network.

So you need a path to carry over the UE context the old AMF (source/old) held, as-is, to the new AMF (target/new). This is N14. The new AMF requests the context from the old AMF over N14, and the old AMF returns the registration state, the 5G security context (K_AMF, etc.), PDU session references, allowed NSSAI, etc. Thereby the new AMF can smoothly take over the UE's procedures — for instance, it may be able to skip re-running authentication. Without N14, you would have to redo the procedures from the beginning every time a UE moves across AMFs.

An analogy: N14 is the handover of a resident record between government offices upon a move. Since a full set of the person's records is carried over from the old desk in charge (the old AMF) to the new desk in charge (the new AMF), you do not have to redo the procedures from scratch at the new desk.

Overview¶

N14 is the reference point connecting AMF ⇔ AMF, that is, same-NF-type peers (AMF). Whereas many other interfaces connect different NFs (e.g., SMF⇔PCF), N14 is characterized by connecting the same kind of NF, AMF and AMF. And N14 is an SBI (Service Based Interface), using HTTP/2 + JSON (RESTful) over TLS as the common transport.

N14 is used when a UE moves into an area served by a different AMF. The triggers are mainly mobility registration update, AMF reallocation, cases where the target AMF changes at N2 handover, etc. At this time the UE context is transferred in the direction old AMF (source/old) → new AMF (target/new). The transferred content includes the registration state, the 5G security context (K_AMF, etc.), PDU session references, allowed NSSAI, etc. By using the transferred context, the new AMF may be able to skip re-running authentication.

The substance of N14 is the operations corresponding to inter-AMF cooperation among the service Namf_Communication (TS 29.518) provided by AMF.

Basic Concept — explanation for beginners¶

We liken N14 to the handover of a resident record between government offices.

When you carry your phone and move to a different region, the AMF in charge of that area (the new AMF) newly starts serving. However, the new AMF does not know in what registration state, with what security keys, and which PDU sessions you had been set up until then. So the new AMF asks the old AMF that had been in charge until then, "give me a full set of this person's records." The old AMF hands over the registration state, the security context, references to in-progress sessions, and so on, all together. This is the UE-context transfer over N14.

Thanks to being able to carry over the records, the new AMF does not need to redo the procedures from scratch. In some cases it can skip identity verification (authentication), and you can continue communicating even after moving.

This exchange between AMFs is not over a dedicated telephone line (a dedicated protocol like N2 or N4), but rather like throwing a request over an internal Web system (HTTP) and getting a reply. This is SBI (Service Based Interface) = the mechanism where NFs converse via Web APIs (HTTP/2), with both requests and responses exchanged in the human-readable format called JSON.

Protocol / Transport¶

Architecture¶

This shows the context in which N14 connects the old AMF (source) and the new AMF (target), and the serving AMF switches over while the UE traverses N2 via the gNB.

flowchart LR
  UE["UE"]
  gNB["gNB"]
  oAMF["Old AMF (source)"]
  nAMF["New AMF (target)"]

  UE --> gNB
  oAMF =="N14 (Namf: UEContext transfer)"==> nAMF
  gNB -."N2".- nAMF

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

How to read the diagram: the UE connects to the network via the gNB. When the UE moves into a different AMF area, serving switches from the old AMF (source) → new AMF (target). At this time, over the thick line (==>) N14, the UE context is transferred from the old AMF to the new AMF (its substance is Namf_Communication operations). The dotted N2 is the control-plane reference point connecting the gNB and the (new) AMF. Note that N14 is, after all, cooperation between AMFs.

Procedures used¶

N14 is used in scenes where the serving AMF switches over due to mobility (UE movement). A representative example is mobility registration update.

• The UE moves into an area under the new AMF and sends a Registration Request (Mobility Registration Update) to the new AMF.
• Using the identifier the UE presents (including old-AMF information) as a clue, the new AMF requests the UE context from the old AMF over N14.
• The old AMF responds with the UE context including the registration state, the 5G security context (K_AMF, etc.), PDU session references, allowed NSSAI, etc.
• The new AMF completes the registration using the transferred context (it may be able to skip re-running authentication).

Besides this, N14 is also used for inter-AMF context cooperation in AMF reallocation and in cases where the target AMF changes at N2 handover.

The detailed procedure flow (message sequences, conditions, IEs, success/failure branches, etc.) is consolidated in Mobility Registration Update. Refer there for the procedure details (operation names, invocation directions, clause sub-numbers) (details are to be confirmed).

Main Messages¶

Since N14 is an SBI, messages take the form of HTTP method + resource operation (RESTful operations, not a procedureCode like NGAP). Their substance is operations of Namf_Communication. Representative ones (illustrative, to be confirmed) are as follows.

Operation names and method assignments are to be confirmed: the fine sub-operation names in the table above (UEContextTransfer / RegistrationStatusUpdate, etc.) and the exact HTTP methods, resource URIs, and invocation directions follow the OpenAPI definitions of Namf_Communication (TS 29.518), and differ by Release. Here they are kept illustrative, and strict assignments are to be confirmed. For the details of each message, see the Message dictionary.

Packet Analysis (Wireshark)¶

Since N14 is an SBI, it is observed on the capture as HTTP/2 (no L4-dedicated protocols such as NGAP/SCTP or PFCP appear).

Decode highlights:

• N14 is encrypted with TLS. To see the contents (HTTP/2 headers and JSON body) you need decryption keys (TLS session keys, etc.). Without keys, it appears only as an encrypted tls payload.
• Once decrypted, you can identify operations by the HTTP/2 headers (:method, resource paths whose :path contains .../namf-communication/...).
• The body is represented in JSON (UE context, security-context references, PDU session references, etc.).
• N14 is an SBI between AMFs. SCTP (NGAP) and PFCP (N4) are irrelevant, and sctp.port or pfcp-family filters are not used.

Comparison with EPC¶

• In 4G: when a UE moved into an area served by a different MME, the UE Context was transferred between MME ⇔ MME using the S10 interface (GTP-C-based, TS 29.274).
• In 5G: the MME's control-plane role was taken over by AMF, and the S10-equivalent inter-AMF UE-context transfer was turned into SBI as N14 (Namf_Communication). GTP-C was replaced by HTTP/2 + JSON (SBI) (TS 29.518).

4G's S10 (inter-MME UE-context transfer) corresponds to 5G's N14 (inter-AMF UE-context transfer). The main change is that the GTP-C-based dedicated IF was turned into SBI (HTTP/2+JSON).

3GPP Specification¶

• 3GPP TS 29.518 — Namf_Communication service (including inter-AMF UE-context transfer, N14). Individual clause numbers are to be confirmed
• 3GPP TS 23.502 §4.2.2 — inter-AMF procedures in mobility registration update (context cooperation on AMF change). Clause sub-numbers are to be confirmed
• 3GPP TS 23.501 §6.2.1 / §4 — the definition of AMF and system architecture · reference points (the definition of N14)
• 3GPP TS 29.500 / TS 29.501 — SBI framework (technical spec / design principles · OpenAPI). Individual clause numbers are to be confirmed
• 3GPP TS 33.501 — SBI security (TLS, etc.). Individual clause numbers are to be confirmed

Note (to be confirmed): that the substance of N14 is the inter-AMF cooperation of Namf_Communication (TS 29.518), and that reference point N14 and service Namf are two views of the same interaction, are the general 3GPP-architecture organization. The detailed clause numbers, exact resource URIs, and sub-operation names of each service operation differ by Release, so each is individually to be confirmed.

Summary¶

• N14 is an SBI (Service Based Interface) connecting AMF ⇔ AMF, that is, same-NF-type peers (AMF).
• Its use is the UE-context transfer from the old AMF to the new AMF when a UE moves into an area served by a different AMF (registration state, 5G security context (K_AMF, etc.), PDU session references, allowed NSSAI, etc.).
• The triggers are mobility registration update, AMF reallocation, an AMF change at N2 handover, etc. The new AMF may be able to skip re-running authentication with the transferred context.
• Its substance is the inter-AMF cooperation of the AMF service Namf_Communication (TS 29.518) (reference point N14 = the service Namf are two views → AMF).
• It corresponds to the UE Context transfer of 4G S10 (MME ⇔ MME, GTP-C, TS 29.274), and in 5G it was turned into SBI (TS 29.518).

Next Step¶

• AMF — both ends of N14. The hub of UE context and mobility management
• Mobility Registration Update — the procedure involving inter-AMF context transfer (details)
• Handover — the case where the target AMF changes at N2 handover
• N8 — the AMF⇔UDM reference point (registration and subscriber-data cooperation)
• Interface dictionary — checking the list of reference points and SBI