UDSF — Unstructured Data Storage Function¶
Learning objectives¶
- Understand that the UDSF is the storage layer for "unstructured data" in the 5GC—a back end for offloading an NF's internal state/context externally.
- Explain that the UDSF is an optional NF that underpins making NFs stateless (externalizing state).
- Organize the difference in role from the UDR, which handles structured data (structured vs. unstructured).
Prerequisites¶
- The storage layer for structured data → UDR
- 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 UDSF is needed) → What (what the UDSF is) → How (how it is used). In this chapter in particular, we delve into, as the theme, offloading the "unstructured data (internal state/context)" an NF holds internally to shared external storage so as to bring the NF closer to stateless. The division of labor with the UDR, which handles structured data, is the key to understanding.
Why — why it's needed¶
If each NF keeps its own internal state (such as session context) only within itself, then when that NF instance goes down its state is lost too and cannot be handed over to another instance. If, instead, 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. The UDSF is the common place to deposit state that makes this "externalization of state" possible.
Analogy: The UDSF is a "coin locker." If each NF (a user) deposits its baggage (internal state) in the coin locker, it can move around light, and even at another counter (another instance) it can retrieve the deposited baggage and continue. If you keep carrying the baggage yourself (the NF holds state internally), it is lost together with the person when they disappear; but if it is deposited in the common locker, it is not lost.
Overview¶
The UDSF is an optionally deployed data-storage NF by which any NF stores and retrieves unstructured data. A consuming NF reads and writes data to the UDSF through the Nudsf service. Here, "unstructured" refers to data whose structure 3GPP does not standardize (such as the internal state/context of each NF); the interpretation of its contents is left to the NF that deposited it. The UDSF itself holds no decision logic; it acts strictly as a storage layer that provides storage, retrieval, update, deletion, and subscribe/notify.
The basic division is that the UDR handles structured data and the UDSF handles unstructured data (the detailed division of roles and data types is to be confirmed).
Basic Concept¶
The UDSF is a "warehouse for keeping an NF's internal state outside." Normally an NF holds the progress of its processing and information about the peer it is connected to (context) within itself. If this is deposited in an external UDSF, that NF comes closer to being a "stateless component," and even if you increase the number of instances or replace a broken instance with another one, it can retrieve the deposited state and continue.
Whereas the UDR is a warehouse for "data with a fixed structure that is shared by everyone, like subscriber data," the UDSF is a warehouse for "data that each NF uses internally, whose structure is not standardized"—that is the difference.
Network Function details¶
| Item | Content |
|---|---|
| Role | Storage layer for unstructured data (NF internal state/context, etc.). An optionally deployed back end. Holds no functional logic. |
| Information held | Unstructured data deposited by each NF (its structure is not standardized by 3GPP; interpretation is left to the depositing NF). |
| Main APIs used | Basically the accessed side (called by other NFs). |
| APIs provided | Nudsf (storage, retrieval, update, deletion, subscribe/notify). TS 29.598 (section number to be confirmed). |
| Related interfaces | N18 (NF⇔UDSF, defined in the reference-point representation of TS 23.501; the Figure/section sub-number is to be confirmed), SBI (Nudsf). |
| Optionality of deployment | The UDSF is not mandatory; it is optionally deployed in configurations that aim to realize stateless NFs (implementation/deployment dependent). |
| Impact on failure | In configurations that deposit state in the UDSF, inability to retrieve it affects an NF's state restoration. The scope of impact is configuration dependent. |
Architecture¶
flowchart TD
NF1["NF (e.g. AMF/SMF, etc.)"] -->|N18 / Nudsf| UDSF["UDSF (unstructured data storage)"]
NF2["another instance / another NF"] -->|N18 / Nudsf| UDSF
UDSF --- STORE["unstructured data (NF internal state/context)"]
UDR["UDR (structured data)"] --- STORE2["structured data (subscriber/policy, etc.)"]
How to read the diagram: Any NF deposits its own unstructured data (internal state/context) into the UDSF via the Nudsf service (reference point N18). By externalizing state, another instance or another NF can retrieve the state from the same UDSF, bringing NFs closer to stateless. The UDR shown alongside on the right is the storage layer for structured data; it is a separate NF whose data has a different nature from the UDSF (unstructured). The two are similar in being a "common storage layer," but their roles are split by structured vs. unstructured.
Interface¶
| Interface | Connection | Role |
|---|---|---|
| N18 | NF ⇔ UDSF | Access to unstructured data (defined in the reference-point representation of TS 23.501; the sub-number is to be confirmed) |
| SBI (Nudsf) | each NF ⇔ UDSF | Data operations (storage, retrieval, update, deletion, subscribe/notify) |
For details, see the Interface dictionary.
Appearance in procedures¶
The UDSF is not the protagonist of a specific standardized procedure; it appears behind the scenes, supporting stateless NF implementations, in the phases of depositing and retrieving state. Which NF deposits which unstructured data in the UDSF is implementation/deployment dependent and is not fixed as a 3GPP procedure (to be confirmed).
Comparison with the EPC¶
The 4G (EPC) does not define a direct equivalent standard NF that externalizes unstructured data to common storage. As 5G aims for the SBA and stateless NFs, the division of storage layers—structured data = UDR / unstructured data = UDSF—was organized.
| Generation | External storage of unstructured data |
|---|---|
| 4G (EPC) | No equivalent NF as a standard (to be confirmed) |
| 5G (5GC) | The UDSF (optionally deployed) stores unstructured data |
Release differences¶
- Rel-15: The UDSF was defined as an optional NF for unstructured data storage.
- Rel-16 / Rel-17: Functional extensions may have been made (the specific extensions are to be confirmed).
3GPP Specification¶
- TS 23.501: Functional definition of the UDSF (§6.2 series) and definition of the reference point N18 (NF⇔UDSF) (the Figure/section sub-number of the reference-point representation is to be confirmed).
- TS 29.598: Definition of the Nudsf (Unstructured Data Storage) service (the section number is to be confirmed).
Summary¶
- The UDSF is the storage layer for unstructured data (NF internal state/context, etc.) in the 5GC, and it is an optionally deployed back end.
- A consuming NF deposits state in the UDSF via the Nudsf service and can make NFs stateless (easing instance addition, swap, and failure recovery).
- The basic division is structured data → UDR, unstructured data → UDSF (the detailed split of data types is to be confirmed).
- The 4G has no equivalent standard NF; it was organized as a division of storage layers amid 5G's SBA orientation.
Next Step¶
- UDR — the storage layer for structured data (contrast with the UDSF)
- N18 — the NF⇔UDSF reference point (Nudsf)
- UDM — the front end that handles subscriber data
- NF dictionary
- Interface dictionary