A core network failure is not always caused by a lack of processing power. Very often, the real problem is state. If a network function crashes but the user context still exists somewhere reliable, another function may continue the service. If the context disappears with the failed node, recovery becomes much harder. This is the logic behind one of the important design ideas in 5GC: separating compute resources from storage resources.
In a mobile core network, user context can include registration status, mobility information, temporary identities, session-related data, location references and other service state. These values help the network know who the UE is, where it is, which session it is using and how later signaling should be handled. When such context is tightly bound to one local network function instance, that instance becomes more than a processing node. It becomes a single point of service continuity risk.
5GC addresses this risk by supporting more stateless network functions. The idea is not that a network function never uses state during operation. Instead, the key point is that long-lived or recoverable state should not be trapped inside one local compute instance. By allowing unstructured data such as UE context to be stored and retrieved through UDSF, 5GC gives AMF and other network functions a more flexible recovery model.
Why Local State Becomes Risky
The 4G MME example makes the problem easy to understand. In an LTE/EPC network, after a UE completes attach through MME1, that MME creates and stores UE context locally. The context may include mobility management and session management information such as UE location, GUTI and UE IP-related parameters.
If MME1 fails unexpectedly, MME2 may still be physically available inside the MME pool. However, availability of another MME does not automatically mean service continuity. If UE context exists only on MME1, MME2 does not have enough information to continue serving the UE smoothly. The user may need to power cycle the device or attach again before service is restored. From a user-experience perspective, this is a poor recovery model.
One traditional workaround is an MME cluster with active-standby synchronization. In this design, UE context is synchronized between the active and standby MME in real time. If the active MME fails, the standby node can take over with the synchronized context. This approach can reduce service interruption, but it also has limitations. It may depend on vendor-specific implementation, lack broad standard support, add cost and reduce portability across different system environments.
The deeper issue is that local state creates a tight relationship between a service instance and its data. Once the compute node becomes the only practical holder of user context, failover becomes more complex. 5GC moves toward a cleaner model by putting recoverable state into a separate storage function that can be accessed by authorized network functions.
What UDSF Changes
UDSF stands for Unstructured Data Storage Function. It allows any 5GC network function to store and retrieve its unstructured data, including data such as UE context. In this model, the AMF or another NF can process signaling as the compute function, while UDSF provides an independent place to keep selected state information.
This is similar in concept to a diskless workstation. A diskless workstation has CPU, memory, network interface and other execution hardware, but it does not keep its working data on a local hard disk. It boots and obtains data from a network server. The workstation performs computation, while storage is separated. In 5GC, network functions can be designed in a comparable way: the NF performs signaling and service logic, while context data can be stored outside the local instance.
The value of UDSF is not simply that it acts like a database. Its architectural value is that it supports stateless NF design, AMF recovery and more flexible cloud-native deployment. When state is accessible through UDSF, an AMF instance can fail without necessarily causing permanent loss of UE context. A newly selected AMF can retrieve the needed context and continue processing when the next transaction occurs.
UDSF also fits the broader direction of virtualized and cloud-native core networks. In a cloud deployment, network function instances may scale out, scale in, restart or move across infrastructure. If every instance tightly owns its local state, automation becomes difficult. Decoupling compute and storage makes scaling and recovery more manageable.
How Data Types Differ
To understand UDSF correctly, it is important to distinguish structured data from unstructured data. In 5GC terminology, structured data refers to data whose structure is defined by 3GPP specifications. Subscription data is a typical example because its resource structure and access model are clearly described.
Unstructured data refers to data whose internal structure is not defined by 3GPP specifications. UE context is a typical example. It is critical for service continuity, but the exact internal organization of that context is not standardized in the same way as subscription data. This makes it suitable for storage through UDSF.
This difference affects engineering design. Structured data can be managed through standardized data services with defined resource models. Unstructured data is usually produced and interpreted by the network function that owns the service logic. UDSF gives that network function a place to save and retrieve the data without forcing the entire internal format into a standardized data tree.
For deployment planning, engineers should not treat all 5GC data as the same category. Subscription data, policy data, session state, temporary user context and recovery-related information may have different access frequency, latency sensitivity, structure, ownership and recovery requirements. UDSF focuses mainly on storing unstructured state that network functions need for resilience and continuity.
How AMF Recovery Works
A typical AMF recovery process with UDSF follows a clear sequence. First, a 5G UE registers through AMF1. AMF1 creates the UE context needed for access and mobility management. After that, AMF1 stores the UE context in UDSF. At this point, the user state is no longer trapped only inside the local AMF instance.
If AMF1 fails, the 5G access network or peer control-plane functions detect the failure. The failed AMF is no longer considered for selection. When the network needs to choose another AMF from the same AMF set, it can select AMF2. This is where UDSF changes the recovery behavior.
AMF2 does not need to treat the UE as a completely unknown device. When a transaction with the UE occurs, AMF2 can retrieve the UE context from UDSF. The retrieval can use identifiers such as SUPI, 5G-GUTI or AMF UE NGAP ID. After obtaining the context, AMF2 can process the UE message and update the 5G-GUTI toward the UE if necessary.
The practical result is better service continuity. The network still needs correct failure detection, AMF reselection and context retrieval logic, but the recovery foundation is stronger than a model where all user context is stored only inside the failed node. From the user side, the ideal result is a recovery process that does not require device restart, manual reattachment or noticeable service interruption.
Engineering Value And Limits
The main engineering value of compute and storage decoupling is resilience. If an AMF instance fails, the service state can still be available through UDSF. This reduces dependence on local node state and helps the network recover with less impact. It also supports elastic scaling because new network function instances can be introduced without needing all historical state to be locally synchronized in advance.
The second value is architectural portability. Compared with vendor-specific active-standby synchronization, UDSF is part of the 5GC architecture and aligns better with standardized cloud-native core network design. It supports a more open way to think about state storage and recovery instead of locking high availability into a private cluster mechanism.
However, UDSF does not remove all complexity. It becomes a critical component in the recovery chain. If UDSF is slow, unavailable, inconsistent or poorly protected, it can become a new bottleneck. Therefore, UDSF itself must be designed with high availability, fast read/write performance, reliable replication, secure access control and disaster recovery capability.
Database selection also matters. Relational and non-relational databases can both appear in UDSF-related designs, depending on vendor implementation and system requirements. The key question is not only which database type is used, but whether the overall storage layer can meet telecom-grade latency, reliability, consistency and recovery requirements.
For engineers, the most important checks include whether UE context is written to UDSF at the right time, whether the newly selected AMF can retrieve it correctly, whether AMF set selection works as expected, whether identifiers are handled consistently, and whether failover is actually invisible or nearly invisible to the user. Decoupling is valuable only when the full recovery path is tested end to end.
FAQ
Is UDSF used only by AMF?
No. UDSF is designed for any network function that needs to store and retrieve unstructured data. AMF recovery with UE context is simply one of the clearest examples.
Why is UE context treated as unstructured data?
UE context is important, but its internal structure is not fully defined as a standardized 3GPP data structure. This makes it suitable for storage as unstructured data.
Does UDSF replace all local state inside network functions?
Not completely. Network functions may still use temporary local state during processing. UDSF is mainly used to preserve recoverable unstructured data that should not be lost with one compute instance.
Can UDSF guarantee zero service interruption?
Not by itself. It improves the recovery foundation, but actual continuity also depends on failure detection, AMF reselection, data freshness, signaling behavior and UDSF availability.
What should be tested before deploying UDSF in production?
Tests should cover context write timing, context retrieval, AMF failure detection, AMF set reselection, database failover, read/write latency, access security and real UE experience during recovery.
5GC compute and storage decoupling is more than a database adjustment. It changes how the core network thinks about state, failure and recovery. By using UDSF to store unstructured data such as UE context, network functions can become less dependent on local storage and more suitable for resilient cloud-native deployment. The essential idea is simple: compute instances may fail or change, but user state should remain recoverable.
