title: N8 — AMF ⇔ UDM (Nudm: UECM / SDM reference point) description: The N8 interface connecting AMF and UDM. Unlike N2/N4, it is an SBI (Service Based Interface), and its substance is the Nudm service (UECM/SDM) provided by UDM. Over HTTP/2 + JSON over TLS, the AMF registers the serving AMF (UECM) and retrieves subscriber data (SDM) — explained in a Why→What→How structure. keywords: - N8 - Nudm - UECM - SDM - UDM - AMF - HTTP2 - SBI - 加入者データ - TS 29.503 tags: - Interface - Data - Rel-15 category: Interface

N8 — AMF ⇔ UDM (Nudm: UECM / SDM reference point)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N8 is an SBI (Service Based Interface), and that its Protocol/Transport is fundamentally different from N2 (NGAP/SCTP) and N4 (PFCP/UDP).
• Explain that the substance of N8 is the service Nudm (UECM: UE Context Management / SDM: Subscriber Data Management, TS 29.503) provided by UDM.
• Explain the flow in which the AMF registers itself as the serving AMF with the UDM (UECM) and retrieves subscriber data (SDM).
• Explain that "reference point N8" and "service Nudm" are two views of the same thing.
• Explain the correspondence with the subscriber-data-retrieval and location-registration parts of 4G (EPC) S6a (MME ⇔ HSS, Diameter).

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 N8 → AMF / UDM
• The procedure where subscriber-data retrieval and serving-AMF registration are used → Registration
• The concept of interfaces and reference points → Interface dictionary

Why — why it is needed¶

The AMF handles UE registration and mobility management, but it does not itself hold subscriber information such as "which slices does this UE subscribe to?" or "to which areas is movement permitted/restricted?". These are held by UDM, the master keeper of subscriber data. Therefore the AMF needs a path to query subscriber data from the UDM.

Furthermore, once a UE starts communicating somewhere, it must be possible for other NFs (e.g., SMS delivery for terminating traffic, or UDM-initiated processing) to later learn "which AMF is currently taking care of this UE." So the AMF registers with the UDM, saying "I am the serving AMF for this UE". The reference point that carries this subscriber-data query and serving-AMF registration is N8. Without N8, the AMF cannot handle the UE without knowing subscribed slices or mobility restrictions, and the UDM side cannot grasp the current serving AMF.

An analogy: AMF = the floor reception desk, UDM = the head office member registry (master DB). N8 is the hotline by which the desk queries the head-office registry ("what is this customer's contract?") and at the same time registers "the desk in charge of this customer is here (me)".

Overview¶

N8 is the reference point connecting AMF ⇔ UDM. However, the key point is that N8 is an SBI (Service Based Interface), which is decisively different from N2 (NGAP/SCTP) and N4 (PFCP/UDP). An SBI is a mechanism where NFs call each other's services via Web APIs (HTTP), using HTTP/2 + JSON (RESTful) over TLS as the common transport.

The substance of N8 is the service Nudm (TS 29.503) provided by UDM. Nudm has two main facets.

• UECM (UE Context Management): the AMF registers/deregisters itself as the serving AMF with the UDM.
• SDM (Subscriber Data Management): the AMF retrieves access & mobility subscription data (allowed slices = Subscribed S-NSSAI, RFSP index, mobility restrictions, etc.) and subscribes to change notifications for them.

Basic Concept — explanation for beginners¶

We liken N8 to the exchange between a reception desk and the head-office member registry.

When you try to register with the network (Registration), the AMF at the reception desk goes to work. Since the AMF does not itself know your contract details (which slices you can use, how far you may move), it queries the UDM, the head-office member registry (SDM_Get = subscriber-data retrieval). At the same time the AMF writes into the registry "the desk in charge of this customer is me (this AMF)" (UECM_Registration = serving-AMF registration). So that it will be notified later if the contract changes, it also asks "please notify me if there is any change" (SDM_Subscribe).

This query to the UDM 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). Both requests and responses are exchanged in the human-readable format called JSON. Giving each operation target (resources such as subscription data or AMF registration) an "address (URI)" and throwing HTTP operations at it to retrieve, create, and subscribe is called RESTful.

Protocol / Transport¶

Architecture¶

This shows the context in which N8 connects AMF and UDM, the UDM retrieves subscription data from UDR behind the scenes, and on the authentication side AUSF works with UDM over N13.

flowchart LR
  AMF["AMF"]
  UDM["UDM"]
  UDR[("UDR (subscription data)")]
  AUSF["AUSF"]

  AMF == "N8 (Nudm: UECM / SDM / HTTP2)" ==> UDM
  UDM -- "Nudr (subscription data retrieval)" --> UDR
  AUSF -. "N13 (Nudm_UEAuthentication)" .-> UDM

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

How to read the diagram: the thick line (==>), N8, is the AMF⇔UDM interaction (SBI/HTTP2), where the AMF performs serving-AMF registration (UECM) and subscriber-data retrieval (SDM). The UDM does not hold the data itself but retrieves subscription data from the UDR behind it via Nudr (in some implementations UDM and UDR are combined). The dashed N13 is the AUSF⇔UDM interaction for authentication, a role distinct from N8's subscriber-data retrieval. Note the distinction: N8 is "registration and subscriber-data retrieval," N13 is "authentication information (authentication vectors)."

Procedures used¶

N8 is used within Registration when the AMF registers the serving AMF with the UDM and retrieves subscriber data.

• UECM_Registration (serving-AMF registration): at UE registration, the AMF registers "I am the serving AMF for this UE" with the UDM.
• SDM_Get (subscription-data retrieval): the AMF retrieves access & mobility subscription data (allowed slices = Subscribed S-NSSAI, RFSP, mobility restrictions, etc.).
• SDM_Subscribe (change-notification subscription): subscribes so that the UDM will notify it when subscription data changes. Thereafter, on any change, the UDM notifies the AMF via SDM_Notify.
• On De-registration: when UE registration is released, the AMF cancels the serving-AMF registration with UECM_Deregistration.

The details of their execution conditions, ordering, IEs, etc. depend on the Release and configuration, so they are to be confirmed. The detailed procedure flow (message sequences, conditions) is consolidated in Registration. Refer there for the procedure details.

Main Messages¶

Since N8 is an SBI, messages take the form of HTTP method + resource operation (RESTful operations, not a procedureCode like NGAP). Representative service operations are as follows.

The HTTP-operation mapping is a conceptual organization: the "HTTP operation" column above is a mapping for understanding; the exact method, resource URI, and invocation direction of each operation follow the OpenAPI definitions of TS 29.503. Strict method assignments are to be confirmed. For the details of each message, see the Message dictionary.

Packet Analysis (Wireshark)¶

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

Decode highlights:

• N8 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 = GET/PUT/POST, etc., resource paths whose :path contains .../nudm-uecm/... or .../nudm-sdm/...).
• The body is JSON (subscription data, allowed slices, mobility restrictions, AMF registration info, etc.), stored in a human-readable structure.
• Unlike N2's NGAP (binary, over SCTP), the key point of observing N8 is that it is Web-like (HTTP/JSON). Do not use SCTP-specific filters (e.g., sctp.port).

Comparison with EPC¶

• In 4G: subscriber-data retrieval and location registration (registering which UE an MME serves) were done over the S6a interface between MME ⇔ HSS (Diameter-based, TS 29.272). The HSS held the subscriber master data, and the MME performed subscriber-data retrieval and location update (Update Location) over S6a.
• In 5G: the HSS's subscriber-data-management role was taken over by UDM (with UDR behind it), and the subscriber-data-retrieval and location-registration (serving-AMF registration) parts of the S6a-equivalent were turned into SBI as N8 (Nudm: UECM / SDM). Diameter was replaced by HTTP/2 + JSON (SBI) (TS 29.503).

Part of S6a went to N13: in addition to subscriber-data retrieval and location registration, S6a also handled retrieval of authentication vectors. In 5G that authentication part was carved out to the N13 (AUSF ⇔ UDM, Nudm_UEAuthentication) side, so its role is separate from N8 (subscription-data retrieval and registration).

3GPP Specification¶

• 3GPP TS 29.503 — Nudm service (UECM: UE Context Management / SDM: Subscriber Data Management, N8). Individual clause numbers are to be confirmed
• 3GPP TS 29.500 / TS 29.501 — SBI framework (technical spec / design principles · OpenAPI). Individual clause numbers are to be confirmed
• 3GPP TS 23.501 §4 — system architecture and reference points (the definition of N8)
• 3GPP TS 23.502 — procedures (use of N8 in the Registration procedure). 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 N8 is Nudm (UECM/SDM, TS 29.503), that the common SBI framework is the TS 29.500/29.501 family, and that reference point N8 and service Nudm are two views of the same interaction are the general 3GPP-architecture organization. The detailed clause numbers, exact resource URIs, and HTTP-method assignments of each service operation differ by Release, so each is individually to be confirmed.

Summary¶

• N8 is the reference point connecting AMF ⇔ UDM, but the fact that it is an SBI (Service Based Interface) is fundamentally different from N2 (NGAP/SCTP) and N4 (PFCP/UDP).
• The Protocol is HTTP/2 + JSON (RESTful) over TLS, and its substance is the UDM service Nudm (UECM / SDM, TS 29.503).
• The AMF registers itself as the serving AMF with the UDM via UECM, and via SDM retrieves subscriber data (allowed slices, mobility restrictions, etc.) and subscribes to changes.
• Reference point N8 = service Nudm are two views of the same AMF⇔UDM interaction (the reference-point view / the service view).
• It corresponds to the subscriber-data-retrieval and location-registration parts of 4G S6a (MME ⇔ HSS, Diameter, TS 29.272), and in 5G it was turned into SBI (TS 29.503) (with the authentication part separated to N13).

Next Step¶

• UDM — the peer side of N8. The hub of subscriber-data management
• AMF — the NF that uses N8 to perform serving-AMF registration and subscriber-data retrieval
• Registration — the procedure where UECM registration and SDM retrieval take place (details)
• N10 — SMF⇔UDM (the SMF likewise retrieves subscription data via Nudm)
• N13 — AUSF⇔UDM (authentication-information retrieval; equivalent to the authentication part of S6a)
• Interface dictionary — checking reference points