N36 — PCF ⇔ UDR (persistent access to policy data)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N36 is an SBI (Service Based Interface) connecting the PCF (policy-decision layer) and the UDR (data-storage layer).
• Explain that the per-subscriber policy / PCC base data the PCF references when making policy decisions over N7/N15/N5 actually resides in the UDR.
• Explain that the actual form of N36 is the service Nudr_DataRepository (TS 29.504 / the policy data model is TS 29.519) provided by the UDR.
• 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 the correspondence with 4G (EPC) SPR/UDR (data for the PCRF).

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 N36 → PCF / UDR
• The reference points the PCF uses for policy decisions → N7 / N15
• The sibling interfaces that use the same Nudr_DataRepository → N35 / N37
• The concept of interfaces and reference points → Interface dictionary

Why — Why it is needed¶

The PCF is the NF that decides the policy of "how to treat this subscriber and this session." However, if the PCF itself kept holding onto the data that serves as the basis for that decision — per-subscriber policy, PCC base data, usage-monitoring thresholds, etc. — problems arise. If the PCFs scale out to multiple instances or restart, it becomes unclear which PCF holds the latest subscriber data, and data consistency breaks down.

Therefore, 5GC separated the "logic" of policy decision from the "data" that serves as its material. Persistence (storage) of the data is handled by a dedicated storage layer, the UDR, and the PCF retrieves it from the UDR when needed to make decisions. This "path by which the PCF reads and writes policy data to/from the UDR" is N36. Without N36, the PCF could not persistently share per-subscriber policies and could not behave as a stateless decision layer.

Analogy: N36 is the passage connecting the policy-maker (PCF) and the reference room (UDR). The PCF, which decides the policy, does not hoard its decision material (per-subscriber policy) on its own desk; it retrieves it from the reference room (UDR) whenever needed (N36). The role division is: the PCF decides, and the UDR stores.

Overview¶

N36 is the reference point connecting PCF ⇔ UDR, and it is an SBI (Service Based Interface). It therefore uses HTTP/2 + JSON (RESTful) over TLS as its common transport.

The actual form of N36 is the service Nudr_DataRepository provided by the UDR. The UDR is "a general-purpose storage layer that provides data-persistence services to any using NF," and the PCF uses that Nudr_DataRepository to Query (reference), Create, Update, Delete, and Subscribe (subscribe to change notifications) policy data (per-subscriber policy, PCC base data, usage-monitoring thresholds, etc.). The common framework for policy data is defined in TS 29.504, and the data model for policy data in TS 29.519 (clause numbers are to be confirmed).

Basic Concept — Beginner-friendly explanation¶

Let us liken N36 to a policy-maker and a reference room.

When your smartphone starts data communication, the "rules department," the PCF, decides the policy of "with what quality, charging, and priority to treat this customer." But the PCF does not hoard the member roster or rulebook (per-subscriber policy, PCC base data) it uses for that decision on its own desk. Whenever needed, it goes to fetch them from the reference room (UDR). This is N36.

The reference room (UDR) is a shared archive that lends materials not only to the policy-deciding department (PCF) but also to the department managing subscriber information (UDM) and the app-interworking department (NEF), all in the same way. The passage the PCF uses is N36, the passage the UDM uses is N35, and the passage the NEF uses is N37 — but the archive itself (Nudr_DataRepository) is the same.

Fetching this material is not over a dedicated telephone line; 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), where both requests and responses are exchanged in human-readable JSON. If you Subscribe to changes such as threshold modifications ("notify me when there is an update"), changes on the UDR side are notified to the PCF.

Protocol / Transport¶

Architecture¶

This shows the context in which N36 connects the PCF (decision layer) and the UDR (data layer), the PCF makes policy decisions over N7/N15, while the UDR provides the same Nudr_DataRepository over N35/N37 as well.

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

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

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

How to read the diagram: The thick line (==>), N36, is the "fetching of policy data" connecting the decision-layer PCF and the data-layer UDR. The PCF receives policy requests over N7 (SMF) and N15 (AMF), and retrieves its decision material from the UDR over N36. The UDR provides the same Nudr_DataRepository to the UDM as N35 and to the NEF as N37 (dotted lines). Note the separation of "the deciding PCF" and "the storing UDR," and that N35/N36/N37 are different entrances to the same archive (Nudr).

Usage Procedure¶

N36 is used when the PCF reads and writes policy data to/from the UDR during the lifecycle of making policy decisions.

• Policy-data retrieval (Query): When the PCF receives a policy request over N7 (SM Policy) or N15 (AM Policy), it internally uses N36 to Query the relevant per-subscriber policy / PCC base data from the UDR and reflects it in the policy decision.
• Policy-data update (Update) + change notification (Subscribe): When usage-monitoring thresholds or per-subscriber policies change, the PCF performs Update over N36 and also Subscribes to changes in related data to receive notifications.
• Create/Delete: As needed, it Creates/Deletes policy-data-related resources.

The exact methods, resource URIs, invocation directions, and detailed conditions of each operation are to be confirmed. The PCF's policy-decision procedure itself is consolidated on the N7 / N15 side; N36 is the "data-fetching" path used internally within it.

Main Messages¶

Because N36 is SBI, messages take the form of HTTP method + resource operation. Representative service operations are as follows (all conceptual examples, to be confirmed).

The operation names and mappings are a conceptual arrangement: The operation divisions in the table above are conceptual examples for understanding; the exact operation names, methods, resource URIs, and invocation directions follow the OpenAPI definitions of TS 29.504 / TS 29.519. Because the details differ by Release, they are to be confirmed. For details of each message, see the Message dictionary.

Packet Analysis (Wireshark)¶

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

Points to watch when decoding:

• N36 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 (the policy data model, TS 29.519), laid out in a human-readable structure.
• Because it is the same Nudr_DataRepository as N35/N37, on the packet level it appears as the same kind of HTTP/2. You distinguish the context by the using NF (PCF) and the kind of data (policy data). SCTP-specific filters (sctp.port, etc.) are not used.

Comparison with EPC¶

• In 4G: Subscriber policy data for the PCRF was stored in the SPR (Subscription Profile Repository) or its successor UDR, and interworked with the PCRF over Sp (PCRF⇔SPR) or Ud (⇔UDR) (the protocols differed by implementation, such as Diameter/LDAP families).
• In 5G: The PCF inherits the PCRF's role, its policy data storage is consolidated into the shared UDR, and the PCF⇔UDR interworking was turned into an SBI as N36 (Nudr_DataRepository). The data model is defined in TS 29.519.

The 4G SPR/UDR (data for the PCRF) becomes UDR+N36 in 5G: In 4G, storage of subscriber policy data existed as SPR/UDR; in 5G it is consolidated into the shared UDR, and access from the PCF is turned into an SBI as N36. This correspondence is a conceptual arrangement, and the details are to be confirmed.

3GPP Specification¶

• 3GPP TS 29.504 — Nudr_DataRepository service (the common UDR data-access framework). Specific clause numbers are to be confirmed
• 3GPP TS 29.519 — Data for policy and charging control (the data model for policy data, the data handled over N36). Specific clause numbers are to be confirmed
• 3GPP TS 23.501 §6.2.4 (PCF) / §6.2.11 (UDR) — NF definitions and roles
• 3GPP TS 23.503 — Policy and charging control framework (PCC framework)
• 3GPP TS 29.500 / TS 29.501 — SBI framework (technical specification / design principles and OpenAPI). Specific clause numbers 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 N36 is Nudr_DataRepository (TS 29.504, with the policy data model in TS 29.519), that N35/N36/N37 are the same Nudr_DataRepository differing only in the using NF, and that the reference point N36 and the service Nudr are two views of the same interworking are general characterizations of the 3GPP architecture. Because the operation details, exact resource URIs, and the logical-division names of policy data differ by Release, they are individually to be confirmed.

Summary¶

• N36 is an SBI (Service Based Interface) connecting PCF ⇔ UDR, with the Protocol HTTP/2 + JSON over TLS.
• The PCF is the policy-decision logic layer, and the UDR is the data-storage layer; the per-subscriber policy / PCC base data the PCF uses for decisions is persisted in the UDR (separation of decision layer / data layer).
• The actual form of N36 is the UDR's service Nudr_DataRepository (common framework TS 29.504 / policy data model TS 29.519).
• N35 (UDM) / N36 (PCF) / N37 (NEF) are the same Nudr_DataRepository, differing only in the using NF and the kind of stored data.
• It corresponds to 4G SPR/UDR (data for the PCRF), and in 5G it was consolidated into the UDR and PCF access was turned into an SBI as N36.

Next Step¶

• PCF — The using side of N36. The hub of policy decision (decision layer)
• UDR — The peer side of N36. The storage layer that persists policy data
• N7 — The reference point the PCF uses for SM policy decisions (reflecting data fetched over N36)
• N35 — The reference point by which the UDM uses the same Nudr_DataRepository
• Interface dictionary — Confirming reference points such as N37 and others