title: N10 — SMF ⇔ UDM (Nudm_SDM: SM subscription-data retrieval reference point) description: The N10 interface connecting SMF and UDM. Unlike N4 (PFCP), it is an SBI (Service Based Interface), and its substance is the Nudm service (SDM: Subscriber Data Management) provided by UDM. Over HTTP/2 + JSON over TLS, the SMF retrieves session-management subscription data (allowed DNN, default QoS, etc.) and uses it in the decision to establish a PDU session — explained in a Why→What→How structure. keywords: - N10 - Nudm - SDM - UDM - SMF - HTTP2 - SBI - SM加入データ - DNN - TS 29.503 tags: - Interface - Data - Rel-15 category: Interface

N10 — SMF ⇔ UDM (Nudm_SDM: SM subscription-data retrieval reference point)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N10 is an SBI (Service Based Interface), and that its Protocol/Transport is fundamentally different from N4 (PFCP/UDP).
• Explain that the substance of N10 is the service Nudm_SDM (Subscriber Data Management, TS 29.503) provided by UDM.
• Explain the flow in which the SMF retrieves session-management subscription data (Session Management Subscription Data / allowed DNN, default QoS, etc.) from the UDM and uses it in the decision to establish a PDU session.
• Explain that "reference point N10" and "service Nudm_SDM" are two views of the same thing.
• Explain the correspondence with the SM-related subscriber-profile retrieval of 4G (EPC) S6a/Gr (MME/SGSN ⇔ HSS, Diameter/MAP).

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 N10 → SMF / UDM
• How subscription data is used in PDU session establishment → PDU Session
• The concept of interfaces and reference points → Interface dictionary

Why — why it is needed¶

When establishing a PDU session, the SMF must know "which DNN (the 4G APN equivalent) can this UE use?", "what are the default QoS (5QI/ARP) and Session-AMBR of that DNN?", and "is the contract one that assigns a static IP?". But these are per-subscriber contract information, which the SMF does not itself hold. They reside in UDM, the master keeper of the operator's subscriber profiles (with the actual data in the UDR behind it).

Therefore the SMF needs a path to query the UDM, "give me this UE's session-management subscription data." This is N10. The SMF retrieves the SM subscription data from the UDM over N10, and based on it decides the allowed DNN, default QoS, AMBR, etc., to assemble the session. Without N10, the SMF cannot perform session control aligned with each subscriber's contract.

An analogy: N10 is the hotline by which the session desk (SMF) queries the head-office member registry (UDM) for the contract plan. The desk queries "which plan (allowed DNN) is this customer on, and what is the default quality (QoS/AMBR)?" over a dedicated line, and sets up the connection according to the reply. If the query desk for the mobility desk (AMF) is N8, then the query desk for the session desk (SMF) is N10.

Overview¶

N10 is the reference point connecting SMF ⇔ UDM. However, the key point is that N10 is an SBI (Service Based Interface), which is decisively different from 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 N10 is the service Nudm_SDM (Subscriber Data Management, TS 29.503) provided by UDM. The SMF calls this service to retrieve session-management subscription data (Session Management Subscription Data). Furthermore, via SDM_Subscribe/Notify it can subscribe to change notifications for the case where that subscription data changes.

Basic Concept — explanation for beginners¶

We liken N10 to the contract-plan inquiry between the session desk and the member registry.

When your phone tries to start data communication (a PDU session), the SMF at the session desk goes to work. Since the SMF does not itself hold "which DNN (destination) this customer may use, and what the default quality (QoS) and speed cap (AMBR) are," it queries the UDM member registry. The UDM returns the contract information (subscription data in the UDR behind it). The SMF then builds the session with the allowed DNN and default QoS just as this contract information dictates.

This query is not over a dedicated telephone line (a dedicated protocol like 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.

In this Web API, the subscription data (a resource) is given an "address (URI)," and HTTP operations such as GET are thrown at it to retrieve it. Furthermore, if you register a subscription (Subscribe) saying "tell me if this subscription data changes," change notifications (Notify) come flying from the UDM side. This convention is called RESTful.

Protocol / Transport¶

Architecture¶

This shows the context in which N10 connects SMF and UDM, the UDM retrieves actual data from the UDR (Nudr) behind it, and the SMF also works with PCF over N7 and with UPF over N4.

flowchart LR
  SMF["SMF"]
  UDM["UDM"]
  PCF["PCF"]
  UPF["UPF (forwarding)"]
  UDR[("UDR (subscription data)")]

  SMF == "N10 (Nudm_SDM / HTTP2)" ==> UDM
  UDM -- "Nudr (subscription data retrieval)" --> UDR
  SMF -. "N7 (Npcf_SMPolicyControl)" .-> PCF
  SMF == "N4 (PFCP)" ==> UPF

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

How to read the diagram: the thick line (==>), N10, is the SMF⇔UDM SM-subscription-data retrieval (SBI/HTTP2). The UDM does not hold the data itself but retrieves subscription data from the UDR behind it via Nudr. Using the allowed DNN, default QoS, etc. obtained over N10 as decision inputs, the SMF queries the PCF for policy over N7 (Npcf) if necessary, and reflects forwarding rules into the UPF over N4 (PFCP) (the thick line on the right). Note that N10 is positioned as "retrieving the contract information needed to set up a session."

Procedures used¶

N10 is used within PDU Session Establishment when the SMF retrieves SM subscription data from the UDM.

• SM subscription-data retrieval (Nudm_SDM_Get): at PDU Session establishment, the SMF queries the UDM and retrieves session-management subscription data (list of allowed DNNs, default 5QI/ARP per DNN, Session-AMBR, whether a static IP is assigned, UE-AMBR, etc.).
• Change-notification subscription (Nudm_SDM_Subscribe): as needed, the SMF subscribes to change notifications (Notify) for the case where that subscription data changes. Thereafter, whenever the subscription data changes on the UDM side, a notification flies out.
• Decision and subsequent interaction: based on the retrieved allowed DNN and default QoS, the SMF decides whether to admit/build the session, and if necessary interacts for policy with the PCF over N7 (Npcf) and sets forwarding rules into the UPF over N4 (PFCP).

The detailed procedure flow (message sequences, conditions, IEs, etc.) is consolidated in PDU Session. Refer there for the procedure details. The exact methods, URIs, and invocation order of each operation are to be confirmed.

Main Messages¶

Since N10 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 N10 is an SBI, it is observed on the capture as HTTP/2 (no L4-dedicated protocols such as PFCP/SCTP appear).

Decode highlights:

• N10 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, etc., resource paths whose :path contains .../nudm-sdm/...).
• The body is JSON (SM subscription data, DNN configuration, QoS/AMBR information, etc.), stored in a human-readable structure.
• Unlike N4's PFCP (binary, over UDP), the key point of observing N10 is that it is Web-like (HTTP/JSON). Do not use SCTP/PFCP-specific filters.

Comparison with EPC¶

• In 4G: SM-related subscriber profiles (APN contract, default QoS per APN, AMBR, etc.) were held by the HSS (Home Subscriber Server), and the MME/SGSN retrieved them over S6a/Gr (S6a being Diameter-based, TS 29.272). That is, the mobility-management node retrieved the subscriber profile in bulk, and the SM-related subscription information was included within it.
• In 5G: the HSS's role was taken over by UDM (with the actual data in UDR), and the retrieval of SM subscription data was turned into SBI into a form where the session desk, the SMF, does it directly over N10 (Nudm_SDM). While the idea of retrieving subscription data continues, Diameter was replaced by HTTP/2 + JSON (SBI) (TS 29.503).

Authentication-vector (AKA) retrieval is a separate lineage from SM subscription data; in 5G that is a matter of the N13 (UDM⇔AUSF, Nudm_UEAU) side. N10 is positioned purely for retrieving SM subscription data (allowed DNN, QoS, etc.).

3GPP Specification¶

• 3GPP TS 29.503 — Nudm service group (Nudm_SDM: Subscriber Data Management, N10). 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 N10)
• 3GPP TS 23.502 — the use of N10 (Nudm_SDM) in procedures such as PDU session establishment
• 3GPP TS 33.501 — SBI security (TLS, etc.). Individual clause numbers are to be confirmed

Note (to be confirmed): that the substance of N10 is Nudm_SDM (TS 29.503), that the common SBI framework is the TS 29.500/29.501 family, and that reference point N10 and service Nudm are two views of the same interaction are the general 3GPP-architecture organization. The detailed clause numbers and exact resource URIs of each service operation, and the concrete values included in the SM subscription data (5QI/AMBR, etc.), differ by Release, so each is individually to be confirmed.

Summary¶

• N10 is the reference point connecting SMF ⇔ UDM, but the fact that it is an SBI (Service Based Interface) is fundamentally different from N4 (PFCP/UDP).
• The Protocol is HTTP/2 + JSON (RESTful) over TLS, and its substance is the UDM service Nudm_SDM (Subscriber Data Management, TS 29.503).
• The SMF retrieves session-management subscription data (allowed DNN, default QoS/AMBR per DNN, etc.) over N10 and uses it in the decision to establish a PDU session. Change notifications are subscribed via SDM_Subscribe/Notify.
• Reference point N10 = service Nudm_SDM are two views of the same SMF⇔UDM interaction (the reference-point/service duality of this site → UDM).
• It corresponds to the SM subscription part of 4G S6a/Gr (MME/SGSN ⇔ HSS, Diameter, TS 29.272), and in 5G it was turned into SBI (TS 29.503).

Next Step¶

• UDM — the peer side of N10. The hub of subscription-data management (actual data in UDR)
• SMF — the NF that retrieves SM subscription data over N10 and builds the PDU session
• PDU Session — the PDU session establishment procedure that uses SM subscription data (details)
• N8 — AMF⇔UDM. Subscriber-data retrieval for the mobility desk (paired with N10)
• N7 — SMF⇔PCF. Policy interaction informed by the retrieved subscription information
• Interface dictionary — checking reference points including N11/N13