UDR — Unified Data Repository¶

Learning objectives¶

• Understand that the UDR is the "data storage layer (persistence layer)" in the 5GC, and that it is a back end that itself holds no functional logic.
• Explain the front/back division of labor in which UDM/PCF/NEF, as "front ends," access the UDR's data.
• Organize the types of data the UDR stores (subscriber data, policy data, structured data, application data, authentication data, etc.).
• Understand the significance of the evolution whereby, whereas the 4G HSS held function and data together, in 5G they were separated into the UDM (function) and the UDR (data storage).

Prerequisites¶

• Basics of UDM/PCF → UDM / PCF
• The ideas of SBA (Service Based Architecture) / SBI (Service Based Interface) → Curriculum
• The naming and roles of inter-NF interfaces → Interface dictionary

What you'll learn in this chapter¶

We learn in the order Why (why the UDR is needed) → What (what the UDR is) → How (how it is used). In this chapter in particular, we delve into, as the theme, the division of labor between the "functional logic (UDM/PCF/NEF)" that handles subscriber and policy data and the "persistence layer (UDR)" that actually stores that data. This very division of labor is the key to understanding the UDR.

Why — why it's needed¶

If you separate the "functional logic that handles" subscriber data and policy data from the "layer that persistently stores" it, you can share the storage layer across multiple functions while scaling and commonizing the functional side independently. By consolidating the owner of the data in one place, you can avoid duplication and inconsistency.

Analogy: The UDR is the "stacks" of a library. The ones handling users (other NFs) are the "librarians," corresponding to UDM/PCF/NEF (front ends), and the one that keeps the books themselves is the "stacks," which is the UDR (back end). The librarians concentrate on counter service, and the stacks concentrate on storing books. If there were no stacks and each librarian held books scattered at hand, duplication of the same book or discrepancies in editions (data inconsistency) would occur. The UDR plays the role of this "common stacks."

Overview¶

The UDR is the unified store of structured data in the 5GC. Each front end—the UDM handling subscriber data, the PCF handling policy data, and the NEF handling data for external exposure—accesses the UDR's data through the Nudr service. The UDR itself holds no decision logic; it acts strictly as a persistence layer that provides storage, retrieval, update, deletion, and subscribe/notify of data.

Note that while structured data is handled by the UDR, unstructured data is handled separately by the UDSF (Unstructured Data Storage Function) (the detailed division of roles is to be confirmed).

Basic Concept — explanation for beginners¶

In terms of "counter" and "warehouse," the UDR is the warehouse (back) side. Receiving inquiries from users and judging what to hand over according to conditions are the jobs of the counter staff (the front ends such as UDM/PCF/NEF), and the UDR, being behind them, silently stores data and takes it in and out exactly as asked.

By separating the counter (front) and the warehouse (back), even if you increase the number of counters or change their kinds, the warehouse can keep maintaining a single common inventory. This is the advantage of front/back separation.

Network Function details¶

Architecture¶

flowchart TD
    UDM["UDM (subscriber front)"] -->|N35 / Nudr| UDR["UDR (data store)"]
    PCF["PCF (policy front)"] -->|N36 / Nudr| UDR
    NEF["NEF (exposure data front)"] -->|N37 / Nudr| UDR
    UDR --- STORE["structured data (subscriber / policy / app / auth)"]

How to read the diagram: UDM, PCF, and NEF are each "front ends" with different roles, and all of them access the same back end, the UDR, via the Nudr service (N35/N36/N37). The UDM handles subscriber data, the PCF handles policy data, and the NEF handles exposure/app data—so the objects handled are divided by labor—but the actual data is all consolidated in the common store, the UDR. The key point is the "front end → back end" structure in which the front ends take on the functional logic and the UDR takes on persistent storage.

Interface¶

For details, see the Interface dictionary.

Appearance in procedures¶

The UDR does not appear directly on the front stage of procedures; it is involved as a "behind-the-scenes" player via front ends such as the UDM and PCF.

• At Registration / authentication: The UDM retrieves subscriber data (and authentication-related data) from the UDR. → Registration / Authentication
• At PDU session establishment: When obtaining SM Policy, the PCF retrieves policy data from the UDR.

In either case, the UDR itself does not appear as a direct protagonist of the procedure sequence; it is in the position of supplying data via the UDM/PCF.

Comparison with EPC¶

In 4G, the HSS (Home Subscriber Server) took on both the functional logic and data storage together. In 5G, this was separated, resulting in a configuration where the UDM takes on the functional logic and the UDR takes on data storage. Furthermore, unstructured data is shared by the UDSF.

Significance of the separation: While commonizing the data storage layer, the functional side (UDM/PCF/NEF) can be scaled and commonized independently, and it becomes easier to avoid duplication and inconsistency of data.

Release differences¶

• Rel-15: The UDM/UDR separation architecture was established, and the UDR was defined as the unified store of structured data.
• Rel-16 / Rel-17: Functional extensions have been made (the specific extension content is to be confirmed).

3GPP Specification¶

• TS 23.501 §6.2.11: Functional definition of the UDR.
• TS 29.504: Definition of the Nudr (DataRepository) service.
• TS 29.505: Definition of the data structures the UDR handles (individual section numbers to be confirmed).
• TS 23.502: Related procedures (the relevant parts to be confirmed).

Summary¶

• The UDR is the unified store of structured data (data storage layer / persistence layer) in the 5GC, a back end that holds no functional logic.
• It takes a division-of-labor structure in which UDM (subscriber) / PCF (policy) / NEF (exposure data), as front ends, access the data of the UDR (back end) via the Nudr service.
• The stored data includes subscriber data, policy data, structured data, application data, authentication data, etc., and unstructured data is handled separately by the UDSF (to be confirmed).
• Whereas in 4G function + data were together, in 5G the HSS was separated into the UDM (function) and the UDR (data storage), achieving both sharing and independent scaling.
• A UDR failure leads to an inability to retrieve subscriber and policy data, and severely affects a wide range of procedures such as registration, sessions, and charging.

Next Step¶

• UDM — the front end that handles subscriber data
• PCF — the front end that handles policy data
• NEF — the front end that handles external exposure/app data
• NF dictionary
• Interface dictionary