N37 — NEF ⇔ UDR (storage access for structured data)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N37 is an SBI (Service Based Interface) connecting the NEF (capability-exposure gateway) and the UDR (data layer), used for storage access of structured data.
• Explain that the actual form of N37 is the service Nudr_DataRepository (TS 29.504) provided by the UDR.
• Explain the flow by which the NEF persists to the UDR the structured data (Application Data, external parameter provisioning, packet flow descriptions, etc.) it receives from / shows to external AFs.
• Explain that N35 (UDM) / N36 (PCF) / N37 (NEF) are the same Nudr_DataRepository, differing only in the using NF and the kind of stored data.
• Explain (including the "to be confirmed" caveats) the background in which there is little clear one-to-one correspondence in 4G (EPC), and the consolidation of capability-exposure data was organized into UDR+N37 in 5G.

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 N37 → NEF / UDR
• The concept of capability exposure (exposure to external AFs, provisioning from the outside) → N33
• Other SBIs sharing the UDR → N35 (UDM⇔UDR) / N36 (PCF⇔UDR)
• The concept of interfaces and reference points → Interface dictionary

Why — Why it is needed¶

The NEF (Network Exposure Function) is the gateway that safely exposes 5GC-internal capabilities to external AFs (Application Functions). Conversely, it also serves as the path by which external AFs configure (provision) the network. At this time, the values received from the outside or shown to the outside — for example, structured data such as Application Data, external parameter provisioning, and packet flow descriptions (Packet Flow Description) — must not disappear after one use. So that other NFs can reference them later or track their changes, they need to be persisted somewhere.

However, if the NEF itself held a database, data would scatter across the NFs, and consistency management would break down. Because 5GC adopts a design that consolidates the data layer into the UDR, the NEF does not hold data itself but uses a path to read and write structured data to/from the UDR. This is N37. Without N37, the NEF would have no common place to store data received from the outside, and the consistency and shareability of the data handled in capability exposure could not be ensured.

Analogy: N37 is the inbound/outbound route connecting the reception desk (NEF) and the warehouse (UDR). The reception does not hoard the goods (Application Data, etc.) received from external customers (AFs) at its own seat; it conveys them to the warehouse for storage (Create/Update) and retrieves them from the warehouse when needed (Query). The warehouse is a common warehouse used jointly by other desks (UDM/PCF) as well.

Overview¶

N37 is the reference point connecting NEF ⇔ 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 N37 is the service Nudr_DataRepository (TS 29.504) provided by the UDR. The NEF calls this service and performs CRUD-like operations on the structured data associated with capability exposure: storing it to the UDR (Create/Update), referencing it (Query), deleting it (Delete), and Subscribing to changes. In TS 29.504, data for this purpose is organized as "Structured Data for exposure".

Basic Concept — Beginner-friendly explanation¶

Let us liken N37 to the interaction between a reception desk and a common warehouse.

When an external application vendor (AF) brings in a configuration like "treat this flow of this subscriber this way," the reception, the NEF, receives it via N33. But the reception does not pile up documents at its own seat; it conveys them to the common warehouse, the UDR, for storage. This is N37. Conversely, when showing something to the outside, it retrieves it from the warehouse and hands it over.

This warehouse is not exclusive to the reception (NEF); the roster clerk (UDM) and the rules clerk (PCF) use the same warehouse as well. Only the shelf (data category) differs; the warehouse and the manner of retrieving/storing are the same — that is the meaning of "N35/N36/N37 are the same Nudr_DataRepository."

Retrieving from and storing to the warehouse is not over a dedicated telephone line (a dedicated protocol like N2 or N4); rather, it is like submitting requests and receiving results over an internal web system (HTTP). This is the mechanism of SBI (Service Based Interface) = NFs conversing via web APIs (HTTP/2), where the exchange is done in the human-readable JSON format. Giving the operation target (data) an "address (URI)" and creating, updating, and deleting it with HTTP operations such as POST/PUT/DELETE is called RESTful.

Protocol / Transport¶

Architecture¶

This shows the context in which N37 connects the NEF and the UDR, the NEF faces external AFs over N33, and the same UDR is shared by the UDM (N35) and PCF (N36) as well.

flowchart LR
  AF["AF (external app)"]
  NEF["NEF (exposure GW)"]
  UDR[("UDR (data layer)")]
  UDM["UDM"]
  PCF["PCF"]

  AF -. "N33" .- NEF
  NEF == "N37 (Nudr: DataRepository)" ==> UDR
  UDM -. "N35" .- UDR
  PCF -. "N36" .- UDR

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

How to read the diagram: The thick line (==>), N37, is the NEF⇔UDR structured-data storage access (SBI/HTTP2; actual form Nudr_DataRepository). The NEF faces external AFs over the dotted N33, and uses N37 for the internal storage of the data received there / shown to the outside. Note that the same UDR is shared by the UDM over N35 (subscriber data) and by the PCF over N36 (policy data). N35/N36/N37 are all the same Nudr_DataRepository, differing only in the kind of stored data.

Usage Procedure¶

N37 is used when the NEF reads and writes to the UDR in the context of persisting structured data associated with capability exposure (details are to be confirmed).

• Persistence of provisioning: When an external AF provisions data (external parameters, Application Data, etc.) to the NEF via N33, the NEF performs Create/Update to the UDR over N37 to persist it.
• Reference from other NFs: When other NFs reference the same data, they also access it via the UDR rather than asking the NEF directly (the UDR consolidates it as the data layer).
• Change notification (Subscribe/Notify): When data changes need to be notified to interested NFs, they Subscribe in advance and receive notifications when changes occur.

The exact invocation directions, conditions, and IEs of these operations, as well as the handling of each data category, depend on the details of the capability-exposure procedure. The details of the procedure (message sequences, clause numbers, etc.) are to be confirmed, and this page keeps to a conceptual positioning.

Main Messages¶

Because N37 is SBI, messages take the form of HTTP method + resource operation (RESTful operations rather than a procedureCode like NGAP). Representative service operations of Nudr_DataRepository are as follows (all conceptual examples. The exact methods, URIs, and category names are to be confirmed).

The operation and HTTP-operation mappings are a conceptual arrangement: The operation names, "HTTP operations," and data-category names (Application Data, etc.) in the table above are mappings for understanding; the exact methods, resource URIs, invocation directions, and category names follow the OpenAPI definitions of TS 29.504. Strict assignments are to be confirmed. For details of each message, see the Message dictionary.

Packet Analysis (Wireshark)¶

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

Points to watch when decoding:

• N37 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 path notation is to be confirmed).
• The body is JSON (structured data / Application Data, etc.), laid out in a human-readable structure.
• Unlike NGAP on N2 (binary, over SCTP), the key to observing N37 is that it is web-like (HTTP/JSON). SCTP-specific filters (sctp.port, etc.) are not used.

Comparison with EPC¶

• In 4G: The gateway for capability exposure (Exposure) was handled by the SCEF (Service Capability Exposure Function), but the positioning of a common data layer that standardly stores the data handled in capability exposure was weak, and there is no interface clearly corresponding one-to-one to NEF⇔UDR (N37). Capability exposure itself is a relatively new, more concept-leaning area whose organization advanced around Rel-15.
• In 5G: The NEF handles the capability-exposure gateway, the structured data it handles is consolidated into the data layer UDR, and reading/writing it was organized as N37 (Nudr_DataRepository, TS 29.504). The consistency and shareability of the data are ensured by the UDR consolidation.

Note (to be confirmed / no equivalent): On the 4G side, an interface clearly corresponding to N37 is hard to identify, so the honest arrangement is "no equivalent to be confirmed." The point is that in 4G, standard centralized storage of capability-exposure data was weak, whereas in 5G it was organized into UDR + N37. We avoid asserting individual correspondences.

3GPP Specification¶

• 3GPP TS 29.504 — Nudr_DataRepository service (Unified Data Repository Services, including "Structured Data for exposure". Shared by N35/N36/N37). 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.5 — Functional definition of the NEF (Network Exposure Function) (clause number is to be confirmed)
• 3GPP TS 23.501 §6.2.11 — Functional definition of the UDR (Unified Data Repository) (clause number is to be confirmed)
• 3GPP TS 23.502 — Capability-exposure / provisioning procedures (the clause numbers of the relevant procedures are to be confirmed)
• 3GPP TS 33.501 — SBI security (TLS, etc.). Specific clause numbers are to be confirmed

Note (to be confirmed): That the actual form of N37 is Nudr_DataRepository (TS 29.504), and that N35/N36/N37 are the same service with different using sides, are general characterizations of the 3GPP architecture. Because the exact methods, resource URIs, data-category names, and clause numbers of each operation differ by Release, they are individually to be confirmed.

Summary¶

• N37 is an SBI (Service Based Interface) connecting NEF ⇔ UDR, used for storage access of structured data associated with capability exposure. The Protocol is HTTP/2 + JSON over TLS.
• The actual form of N37 is the UDR's service Nudr_DataRepository (TS 29.504, Structured Data for exposure) = the reference point N37 and the service Nudr are two views of the same interworking.
• The NEF persists to the UDR the Application Data, external parameter provisioning, packet flow descriptions, etc. it receives from / shows to external AFs, via Create/Update/Query/Delete/Subscribe (details to be confirmed).
• N37 is the behind-the-scenes (internal data storage) of capability exposure in which the NEF faces external AFs over N33, and N35 (UDM) / N36 (PCF) / N37 (NEF) are the same Nudr_DataRepository, differing only in the kind of stored data.
• In 4G there is little clear one-to-one correspondence (no equivalent to be confirmed), and centralized storage of capability-exposure data was organized into UDR + N37 in 5G.

Next Step¶

• NEF — The using side of N37. The gateway for capability exposure toward external AFs
• UDR — The peer side of N37. The data layer that provides Nudr_DataRepository
• N33 — The capability-exposure interface by which the NEF faces external AFs (N37 is its behind-the-scenes)
• N35 — UDM⇔UDR. The same Nudr_DataRepository as N37 (subscriber data)
• Interface dictionary — Confirming the list of reference points and SBIs