N35 — UDM ⇔ UDR (persistent access to subscription data)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N35 is an SBI (Service Based Interface) by which the UDM (function layer) reads and writes subscriber data to/from the UDR (data layer).
• Explain that in 5G, function and data are separated into UDM (logic) + UDR (persistence), and that the actual data the UDM shows to external NFs over N8/N10/N13 resides in the UDR.
• Explain that the actual form of N35 is the service Nudr_DataRepository (TS 29.504 / 29.505) provided by the UDR.
• Explain the evolutionary correspondence from 4G (EPC) HSS (holding function and data together) to the 5G UDM + UDR separation.
• Explain that N35 (UDM) / N36 (PCF) / N37 (NEF) are all access to the same Nudr_DataRepository, differing only in the using NF and the kind of stored data.

Prerequisites¶

Understanding the following first will make this smoother:

• The positioning of SBA / SBI and HTTP/2・TLS → Protocol dictionary
• The NFs at both ends of N35 → UDM / UDR
• The interfaces by which the UDM shows data to external NFs → N8 / N10 / N13
• The concept of interfaces and reference points → Interface dictionary

Why — Why it is needed¶

The UDM passes subscription information to the AMF (N8), session subscription data to the SMF (N10), and authentication data to the AUSF (N13). However, if the UDM itself held all this subscriber data, the functional logic (how data is interpreted and provided) and the storage of data would be fused together, and whenever you wanted to make the data redundant, extensible, or shareable, you would have to rebuild the entire UDM.

Therefore, in 5G, a dedicated container for storing the actual subscriber data — the UDR (Unified Data Repository) — was carved out, and the UDM was designed to handle only functional logic. The real subscriber data the UDM shows to the outside is persisted in the UDR, and the UDM retrieves and stores it from/to the UDR when needed. This data-access path between the UDM and the UDR is N35. Without N35, the UDM would have to keep data in its own storage, and the "separation of function and data" that 5G aimed for would not hold.

Analogy: N35 is the conveyance path connecting the desk clerk (UDM) and the archive room (UDR). The clerk handles users (N8/N10/N13), but the actual documents are kept in the archive room (UDR), and the clerk retrieves and returns documents from/to the archive (N35) to serve requests.

Overview¶

N35 is the reference point connecting UDM ⇔ UDR, and it is an SBI (Service Based Interface). SBI is a mechanism in which NFs invoke services from each other via web APIs (HTTP), using HTTP/2 + JSON (RESTful) over TLS as the common transport.

The actual form of N35 is the service Nudr_DataRepository (TS 29.504 / TS 29.505) provided by the UDR. The UDM calls this service and reads/writes subscriber data such as authentication data, access & mobility subscription, and SM subscription as resources on the UDR via Query (read) / Create / Update / Delete, plus Subscribe for change notifications. The role division — the UDM is the functional-logic layer and the UDR is the data-storage layer — is the essence of N35.

Basic Concept — Beginner-friendly explanation¶

Let us liken N35 to the conveyance between a desk clerk (UDM) and an archive room (UDR).

When your smartphone tries to register with and connect to the network, the desk clerk (UDM) that provides subscription information goes to work. The clerk serves the AMF, SMF, and AUSF (the users) with statements like "this subscriber has this contract and these authentication credentials" (N8/N10/N13). But the clerk does not keep the actual documents on their own desk. Because the documents (the actual subscriber data) are kept in the archive room (UDR), whenever a request comes in the clerk goes to the archive and says "pull this subscriber's documents" (Query), and when the content changes, replaces the archive's documents (Update). This conveyance path between the clerk and the archive is N35.

This conveyance is not over a dedicated telephone line (a dedicated protocol like N2 or N4); rather, it is like submitting requests and receiving answers over an internal web system (HTTP). This is the mechanism of SBI (Service Based Interface) = NFs conversing via web APIs (HTTP/2). Both requests and responses are exchanged in the human-readable JSON format. Each operation target (a subscriber-data record) is given an "address (URI)," and GET/PUT/PATCH/DELETE and so on are issued against it to read and write.

The key point is that function (UDM) and data (UDR) were separated. The clerk can concentrate on the logic of "how to serve," while the archive can concentrate on "how to store large volumes safely."

Protocol / Transport¶

Architecture¶

This shows the context in which N35 connects the UDM (function layer) and the UDR (data layer), the UDM serves the AMF/SMF over N8/N10, and the UDR provides the same Nudr_DataRepository to the PCF/NEF over N36/N37 as well.

flowchart LR
  AMF["AMF"]
  SMF["SMF"]
  UDM["UDM (function layer)"]
  UDR[("UDR (data layer)")]
  PCF["PCF"]
  NEF["NEF"]

  AMF -."N8".- UDM
  SMF -."N10".- UDM
  UDM =="N35 (Nudr: DataRepository)"==> UDR
  PCF -."N36".- UDR
  NEF -."N37".- UDR

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

How to read the diagram: The thick line (==>), N35, is the UDM⇔UDR data access (SBI/HTTP2). The UDM serves external requests such as N8 (AMF) and N10 (SMF) on the left, but the actual subscriber data resides in the UDR, and the UDM retrieves and stores it over N35. At the lower right, the same Nudr_DataRepository provided by the UDR is used by the PCF over N36 (policy data) and by the NEF over N37 (structured data). Note the role division: the UDM is the "serving function," and the UDR is the "stored data."

Usage Procedure¶

N35 is used with the UDR behind the scenes as the UDM processes data requests from external NFs.

• Data read (Query): When the UDM receives an external request such as an SDM Get over N8, it internally uses N35 to Query the relevant subscriber data (authentication data / access & mobility subscription / SM subscription, etc.) from the UDR, and the UDM processes and responds.
• Data creation/update (Create / Update): When registration or modification of subscriber data occurs, the UDM performs Create / Update on the UDR record over N35 and persists it.
• Change-notification subscription (Subscribe / Notify): When the UDM wants to continuously track data changes in the UDR, it subscribes and receives change notifications (Notify).

The exact methods, resource URIs, and invocation directions of each operation, as well as the details of the above mappings, are to be confirmed (they follow the OpenAPI definitions of TS 29.504 / 29.505). For the UDM's role in the overall procedure, see UDM.

Main Messages¶

Because N35 is SBI, messages take the form of HTTP method + resource operation. The representative operations of the UDR's service Nudr_DataRepository (all conceptual examples; details to be confirmed) are as follows.

The operation mapping is a conceptual arrangement: The operation names and granularity in the table above are conceptual examples for understanding; the exact operation names, methods, and resource URIs follow the OpenAPI definitions of TS 29.504 / 29.505. Strict assignments are to be confirmed. For details of each message, see the Message dictionary.

Packet Analysis (Wireshark)¶

Because N35 is SBI, it is observed in captures as HTTP/2 (L4-dedicated protocols like NGAP/SCTP do not appear).

Points to watch when decoding:

• N35 is encrypted with TLS. To see the contents (HTTP/2 headers and JSON body), a decryption key (TLS session key, etc.) is required. Without the key, it appears only as an encrypted tls payload.
• Once decrypted, you can identify operations by the HTTP/2 headers (:method; :path containing a Nudr_DataRepository resource path).
• The body is JSON (subscriber data, authentication data, subscription profiles, etc.), laid out in a human-readable structure.
• Unlike NGAP on N2 (binary, over SCTP), the key to observing N35 is that it is web-like (HTTP/JSON). SCTP-specific filters (sctp.port, etc.) are not used.

Comparison with EPC¶

• In 4G: Subscriber data management was handled by the HSS (Home Subscriber Server), which held function (the data-provision logic) and data (the actual storage) together. The data-storage layer inside the HSS was not exposed as a standardized external interface, and function and data were not separated.
• In 5G: The HSS's role was separated into UDM (function layer) + UDR (data layer), and the internal interface connecting them was turned into an SBI as N35 (Nudr_DataRepository). The actual data is persisted in the UDR, and the UDM concentrates on functional logic.

The 4G HSS configuration that held function and data together is, in 5G, separated into UDM (function) + UDR (data), with N35 connecting them. This enables redundancy and sharing of data (the same UDR is also used by the PCF/NEF over N36/N37).

3GPP Specification¶

• 3GPP TS 29.504 — Nudr_DataRepository service (the common UDR data-access framework, shared by N35/N36/N37). Specific clause numbers are to be confirmed
• 3GPP TS 29.505 — Data model for subscription data (the structure of subscriber data stored in the UDR). Specific clause numbers are to be confirmed
• 3GPP TS 29.500 / TS 29.501 — SBI framework (technical specification / design principles and OpenAPI). Specific clause numbers are to be confirmed
• 3GPP TS 23.501 §6.2.7 (UDM) / §6.2.11 (UDR) — NF definitions and roles
• 3GPP TS 33.501 — SBI security (TLS, etc.). Specific clause numbers are to be confirmed

Note (to be confirmed): That the actual form of N35 is Nudr_DataRepository (TS 29.504 / data model in TS 29.505), that the same service is used in common by N35/N36/N37, and that the reference point N35 and the service Nudr are two views of the same interworking are general characterizations of the 3GPP architecture. Because the operation names, resource URIs, and detailed clause numbers of the logical partitioning of data differ by Release, they are individually to be confirmed.

Summary¶

• N35 is an SBI (Service Based Interface) connecting UDM ⇔ UDR, with the Protocol HTTP/2 + JSON over TLS.
• In 5G, function and data are separated into UDM (functional-logic layer) + UDR (data-storage layer), and the subscriber data the UDM shows to external NFs over N8/N10/N13 is persisted in the UDR.
• The actual form of N35 is the UDR-provided service Nudr_DataRepository (TS 29.504 / data model TS 29.505), by which the UDM performs Query/Create/Update/Delete/Subscribe on subscription data (details to be confirmed).
• The 4G HSS (function + data integrated) is, in 5G, split into UDM + UDR, and the internal IF between them is N35.
• N35 (UDM) / N36 (PCF) / N37 (NEF) are access to the same Nudr_DataRepository, differing only in the using NF and the kind of stored data.

Next Step¶

• UDM — The function-layer side of N35. The hub of the logic that provides subscriber data to external NFs
• UDR — The data-layer side of N35. Persists subscriber data and provides Nudr_DataRepository
• N36 — PCF⇔UDR. Accesses policy data via the same Nudr_DataRepository
• N37 — NEF⇔UDR. Accesses structured data via the same Nudr_DataRepository
• Interface dictionary — Confirming reference points such as N8/N10/N13 and others