title: N18 — NF ⇔ UDSF (Nudsf: the reference point for unstructured data storage) description: The N18 interface connecting any NF and the UDSF. Unlike N2/N4 it is an SBI (Service Based Interface), and its substance is the Nudsf service provided by the UDSF. Over HTTP/2 + JSON over TLS, it explains—Why→What→How—the mechanism by which an NF stores/retrieves its internal state (unstructured data) in the UDSF to become stateless. keywords: - N18 - Nudsf - UDSF - unstructured data - stateless NF - HTTP2 - SBI - TS 29.598 tags: - Interface - Data - Rel-15 category: Interface

N18 — NF ⇔ UDSF (Nudsf: the reference point for unstructured data storage)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N18 is an SBI (Service Based Interface) and that its Protocol/Transport is fundamentally different from N2 (NGAP/SCTP) and N4 (PFCP/UDP).
• Explain that the substance of N18 is the service Nudsf (Unstructured Data Storage, TS 29.598) provided by the UDSF.
• Explain the flow by which any NF stores/retrieves its internal state (unstructured data) in the UDSF and becomes stateless.
• Explain that "reference point N18" and "service Nudsf" are two views of the same thing.
• Explain the division from N35/N36/N37 (the UDR side) for structured data (structured vs. unstructured).

Prerequisites¶

It goes smoothly if you understand the following first:

• The positioning of SBA / SBI and HTTP/2·TLS → Protocol dictionary
• The peer NF of N18 and the contrasting structured-data layer → UDSF / UDR
• The idea of interfaces and reference points → Interface dictionary

Why — why it's needed¶

If each NF keeps its own internal state (such as in-progress context) only within itself, then the moment that NF instance goes down its state is lost too and cannot be handed over to another instance. So if you offload internal state to shared external storage (the UDSF), NF instances can be built to be closer to stateless (holding no state), making it easier to add, swap, and recover instances.

N18 is the path for "depositing/retrieving an NF's internal state (unstructured data) to/from the external UDSF." Without N18, an NF has no choice but to hold state within itself, making a stateless design hard to adopt.

Analogy: The NF is a person moving around carrying baggage, and the UDSF is a coin locker. N18 is the route of exchange by which that person deposits baggage (internal state) into the locker and retrieves it. Having deposited it, they can move around light, and even at another counter (another instance) they can retrieve it from the same locker and continue.

Overview¶

N18 is the reference point connecting any NF ⇔ UDSF. However, N18 is an SBI (Service Based Interface), which is decisively different from N2 (NGAP/SCTP) and N4 (PFCP/UDP). SBI is a mechanism by which NFs call each other's services over a Web API (HTTP), using HTTP/2 + JSON (RESTful) over TLS as the common transport.

The substance of N18 is the service Nudsf (TS 29.598) provided by the UDSF. A consuming NF uses Nudsf to store, retrieve, update, delete, and subscribe/notify unstructured data (the internal state/context of each NF, etc.). Here, "unstructured" refers to data whose structure 3GPP does not standardize; the interpretation of its contents is left to the depositing NF.

Basic Concept¶

Let us liken N18 to the exchange between a person and a coin locker.

Suppose an NF holds the progress of its processing or information about the peer it is connected to (context). If it keeps this only within itself, the information is lost together the moment that NF breaks. So the NF deposits state in the UDSF, the common locker (store). At another instance or in another situation, it can retrieve the state from the same locker (get) and continue. When the state changes it can rewrite it (update), and when it is no longer needed it can clear it away (delete).

This depositing/retrieving to/from the UDSF is not a dedicated phone line (a dedicated protocol like N2 or N4); rather, picture throwing a request at an in-house web system (HTTP) and getting a reply. This is SBI (Service Based Interface)—the mechanism by which NFs converse via a Web API (HTTP/2).

Protocol / Transport¶

Architecture¶

The diagram shows how N18 connects any NF to the UDSF and stores unstructured data, in contrast with the structured-data side (the UDR: N35/N36/N37).

flowchart LR
  NF1["NF (e.g. AMF/SMF, etc.)"]
  NF2["another instance / another NF"]
  UDSF["UDSF"]
  UDR["UDR"]

  NF1 == "N18 (Nudsf / HTTP2)" ==> UDSF
  NF2 == "N18 (Nudsf / HTTP2)" ==> UDSF
  UDM["UDM/PCF/NEF"] -- "N35/N36/N37 (Nudr)" --> UDR

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

How to read the diagram: The thick lines (==>) are N18, the interaction between any NF (AMF/SMF, etc.) and the UDSF (SBI/HTTP2), where the NF deposits its unstructured data (internal state/context). By externalizing state, another instance or another NF can retrieve it from the same UDSF. Shown below for contrast is the structured-data side, where UDM/PCF/NEF access the UDR over N35/N36/N37 (Nudr). Note the division: N18 = unstructured (UDSF) / N35–37 = structured (UDR).

Appearance in procedures¶

N18 is not the protagonist of a specific standardized procedure; it is used behind the scenes, supporting stateless NF implementations, in the phases of storing/retrieving state.

• Store (Create/Update): An NF writes/updates its unstructured data (context, etc.) to the UDSF.
• Retrieve (Query/Get): At another instance or in another situation, it reads the deposited state from the UDSF.
• Delete: It clears away state that is no longer needed.
• Subscribe/Notify: It subscribes to notifications of state changes and is notified upon change.

Which NF deposits which unstructured data in the UDSF, and its execution conditions, order, and data contents, are implementation/deployment dependent and are not fixed as a 3GPP procedure (to be confirmed). For the overall positioning of the UDSF, see UDSF.

Main messages¶

Because N18 is an SBI, messages take the form of HTTP methods + resource operations (RESTful operations, not a procedureCode like NGAP). Representative operations are as follows.

The HTTP-operation mapping is a conceptual arrangement: The "HTTP operation" in the table above is a mapping for understanding; the exact method, resource URI, and call direction of each operation follow the OpenAPI definitions of TS 29.598. The strict method assignment is to be confirmed.

Packet Analysis (Wireshark)¶

Because N18 is an SBI, it is observed on capture as HTTP/2 (L4-dedicated protocols like NGAP/SCTP or PFCP/UDP do not appear).

Decode highlights:

• N18 is encrypted with TLS. To see the contents (HTTP/2 headers or the JSON body) you need a decryption key (TLS session key, etc.). Without the key it appears only as the encrypted payload of tls.
• Once decrypted, you can identify operations by the HTTP/2 headers (:method = GET/PUT/POST/DELETE, etc.; a resource path whose :path contains .../nudsf/...).
• The body is carried as JSON, but note that the unstructured data inside is specific to each NF and 3GPP does not standardize its structure (interpretation depends on the depositing NF).
• Unlike N2's NGAP (binary, over SCTP), the key to observing N18 is that it is Web-like (HTTP/JSON). Do not use SCTP-specific filters (sctp.port, etc.).

Comparison with the EPC¶

The 4G (EPC) does not define a standard interface directly equivalent to N18 as a reference point for externalizing an NF's internal state (unstructured data) to common storage (to be confirmed). This is because making NFs stateless by externally storing unstructured data is a concept organized amid 5G's SBA orientation. On the structured-data side, it pairs with the flow in which the 4G HSS (subscriber master) was separated into UDM + UDR in 5G, and N35/N36/N37 were defined as the reference points on the UDR side.

3GPP Specification¶

• 3GPP TS 29.598 — the Nudsf (Unstructured Data Storage) service (the substance of N18). The specific section number is to be confirmed
• 3GPP TS 29.500 / TS 29.501 — the SBI framework (technical rules / design principles·OpenAPI). The specific section numbers are to be confirmed
• 3GPP TS 23.501 §4.2 — the reference-point representation of the system architecture (the definition of N18 = NF⇔UDSF; the Figure/sub-number is to be confirmed). Note: the functional definition of the UDSF itself is in the §6.2 series (see UDSF)
• 3GPP TS 33.501 — SBI security (TLS, etc.). The specific section number is to be confirmed

Note (to be confirmed): That N18 is the UDSF's reference point, that its substance is Nudsf (TS 29.598), and that the common SBI framework is the TS 29.500/29.501 series are general arrangements of the 3GPP architecture. The detailed section numbers, exact resource URIs, and HTTP method assignments of each operation differ by Release and are individually to be confirmed. Which NF deposits which unstructured data is implementation/deployment dependent.

Summary¶

• N18 is the reference point connecting any NF ⇔ UDSF, but the fact that it is an SBI (Service Based Interface) makes it fundamentally different from N2 (NGAP/SCTP) and N4 (PFCP/UDP).
• Its Protocol is HTTP/2 + JSON (RESTful) over TLS, and its substance is the UDSF's service Nudsf (TS 29.598).
• An NF stores/retrieves unstructured data (internal state/context) to/from the UDSF via N18 to pursue statelessness.
• Reference point N18 = service Nudsf are two views of the same NF⇔UDSF interaction (the reference-point view / the service view).
• The division is N18 = unstructured data (UDSF) / N35–37 = structured data (UDR). Which data is deposited is implementation/deployment dependent (to be confirmed).

Next Step¶

• UDSF — the peer side of N18. The unstructured-data storage NF
• UDR — the structured-data storage layer (contrast with the N35/N36/N37 side)
• N35 — UDM⇔UDR (a reference point on the structured-data side)
• Interface dictionary — check the reference points