PaperlayerView exact revision on arXiv

Source-linked AI summary

A Dynamic UPF Fault Recovery Mechanism for Enhanced Resilience in 5G Core Networks

Shirin Behnaminia, Pardis Yavari, Zeinab Zali, Mohammad Reza Heidarpour

arXiv:2610.03245v1cs.NI

TL;DR

UPF failures threaten service continuity in 5G, where preserving active session context is important. The paper modifies the SMF to restore sessions at the application layer and automates UPF recovery. Its tests report recovery in 14 seconds, with minimal packet loss and rapid service restoration across traffic and monitoring tests.

  • Problem

    UPF failures can disrupt user connectivity and performance, making fault tolerance important for 5G services.

    Source: §I · p. 1

  • Method

    The paper modifies the SMF for application-layer session restoration and automates UPF restart and recovery.

    Source: §I · p. 2, §VI · p. 9, 1) Detecting the Failure · p. 12

  • Results

    14 seconds: automated UPF recovery completed while maintaining session continuity, and tests reported minimal packet loss and rapid service recovery.

    Source: E. Summary · p. 9

  • Takeaways & Limitations

    The OpenAirInterface implementation combines session restoration with failure-aware UPF selection that favors nodes with fewer past failures and longer stable operation.

    Source: §VI · p. 9

Abstract

from arXiv · show

Ensuring fault tolerance in the User Plane Function is essential to maintain service continuity in 5G networks, particularly as latency-sensitive applications become more prevalent. This paper presents a novel mechanism for dynamic UPF failure detection and recovery within an OpenAirInterface-based 5G core environment. The approach introduces an application-layer session restoration mechanism to ensure service continuity and minimize disruptions during UPF failures. Experimental results demonstrate that the proposed mechanism reduces UPF downtime while maintaining low packet loss and enabling rapid service recovery. In tests with TCP and UDP traffic, connectivity was restored within a few seconds, minimizing service degradation. Furthermore, our failure-aware UPF selection mechanism improves long-term system resilience by considering recent failure history. The results highlight the effectiveness of our lightweight framework in improving the overall reliability of 5G networks, making it a valuable contribution to network robustness.

I. INTRODUCTION

The paper targets UPF failures that threaten session continuity in 5G, where infrastructure-level restarts do not preserve in-memory session context. It proposes application-layer restoration and positions this data-plane approach against prior work focused on prediction, control-plane recovery, or architectural mechanisms.

I. INTRODUCTION

  • UPF failures can disrupt latency-sensitive 5G services, while infrastructure restarts do not preserve the session context needed to maintain active connections.The UPF handles user traffic, and restarting it can lose PDU session state.Source: §I · p. 1
  • Prior Kubernetes and Docker recovery mechanisms provide restarts and stable networking, but the cited discussion says they do not preserve active connection state.Prior studies deploying 5G core components on Kubernetes focus largely on infrastructure concerns rather than preserving session state during failures.Source: §I · pp. 1–2
  • The paper proposes application-layer session restoration, transferring context from the SMF to the UPF during recovery to support continuity of data flows.The authors also describe the mechanism as lightweight and based on standard procedures.Source: §I · p. 2

II. RELATED WORK

  • Prior AI-based studies address failure detection or prediction, while the paper says they do not address post-fault recovery.A cited self-healing study evaluates its approach in a simulator rather than a real-world deployment.Source: §II · p. 2
  • Related architectural approaches include remote state storage and redundancy, with reported trade-offs including centralized bottlenecks, limited scope, and consistency risks.The reviewed works include a UDSF-based design with a single point of failure under high loads, a control-plane replication approach with asynchronous consistency, and a packet-replication design without practical evaluation.Source: §II · p. 3
  • The paper distinguishes its approach by restoring UPF state after restart through SMF-provided context, aiming for data-plane continuity with low signaling overhead.The authors contrast this with approaches focused on the control plane or relying on complex redundancy mechanisms.Source: §II · p. 3

III. BACKGROUND

The background describes the 5G Core as a service-based architecture with distinct control-plane and user-plane roles. It emphasizes that the SMF maintains session context while the UPF forwards user data.

A. 5G Network Overview

  • The 5G Core uses modular Network Functions that interact through standardized service-based interfaces.The paper describes this architecture as supporting modularity and reusability.Source: A. 5G Network Overview · p. 3, Figure 1 · p. 4
  • The Control Plane handles signaling and session control, while the UPF manages user-data forwarding.The SMF is identified as a control-plane function.Source: A. 5G Network Overview · p. 3
  • The SMF maintains PDU session context, while the UPF retains forwarding state and processes user-plane traffic under SMF instructions over N4 using PFCP.The paper links their coordination to session continuity and policy enforcement.Source: A. 5G Network Overview · pp. 3–4

B. PDU Session Establishment

A PDU session is established by aligning UE, slice, session, QoS, tunnel, and forwarding information across network functions. The paper’s recovery approach transfers context at the application layer so a restarted UPF can restore state without complex redundancy.

1) Context Exchange for Session Setup:

  • Session setup coordinates UE identity and slice information, session parameters, QoS flows, tunnel endpoints, and traffic-handling rules across network functions.The SMF constructs session context and selects a UPF; the UPF supplies an uplink tunnel endpoint, while the gNB supplies downlink tunnel information.Source: 1) Context Exchange for Session Setup · p. 4
  • The SMF installs forwarding rules at the UPF and updates it with the gNB’s downlink tunnel information to complete the session tunnel.PDRs classify incoming packets, and FARs specify forwarding, buffering, or dropping actions.Source: 1) Context Exchange for Session Setup · p. 4

2) PDU Session as a Logical Tunnel:

  • A PDU session combines UE identity, session parameters, QoS flows, tunnel endpoints, and forwarding rules into a data path between the UE and Data Network.Each QoS flow traverses an UP tunnel between the UPF and gNB and a DRB between the gNB and UE.Source: 2) PDU Session as a Logical Tunnel · p. 4

IV. PROPOSED METHOD

  • The paper uses application-layer context transfer to let a UPF restore state without complex redundancy schemes.The described infrastructure assumes static IP addresses and an automatic restart mechanism.Source: §IV · pp. 4–5

A. Fault Tolerance Procedure

The SMF detects a restarted UPF, identifies sessions affected by the failure, and reconstructs their context. It then uses standard SMF–UPF signaling to establish and finalize restored sessions.

A. Fault Tolerance Procedure

  • The SMF treats a starting UPF with a registered IP address as a restarted instance and initiates restoration rather than registering it as new.The paper states that this scenario indicates a failure before the restart.Source: A. Fault Tolerance Procedure · p. 5

1) Extracting Values from Previous Session:

  • After detecting failure, the SMF filters its maintained session context by UPF node ID and extracts information for the affected PDU sessions.The extracted information is grouped by its source, including UE, SMF, and AMF information.Source: 1) Extracting Values from Previous… · pp. 5–6

2) Executing the Fault-Tolerance Procedure:

  • The SMF restores context through sequential N4 establishment and modification messages with the UPF, using collected data without involving the AMF.The exchange establishes the uplink endpoint, installs session rules, identifies the gNB downlink endpoint, and finalizes the session.Source: 2) Executing the Fault-Tolerance… · p. 6

1) UPF Recovery Scenarios:

The paper selects a lower-complexity single-UPF restart recovery, initiated by the SMF, and adds UPF selection based on recent failure history. The evaluation uses an OAI network-slicing deployment to examine failure and recovery behavior.

1) UPF Recovery Scenarios:

  • The single-UPF restart scenario was selected for lower complexity, while active-standby recovery would add signaling overhead and require gNB support for dynamic tunnel reconfiguration.In the selected scenario, the failed UPF is restarted and its context transferred once operational.Source: 1) UPF Recovery Scenarios · p. 6

2) Starting Point:

  • The SMF was chosen to initiate recovery because it has the prior session context and real-time UPF status, minimizing signaling overhead and UE disruption.The alternatives considered were starting recovery at the UE or gNB.Source: 2) Starting Point · p. 6

3) Fault Detection:

  • The SMF monitors UPF availability with heartbeats or startup notifications, relying on startup notifications because a rapid restart can fall between heartbeat checks.A restarted UPF sends the SMF a message similar to a registration request.Source: 3) Fault Detection · p. 6

4) Failure-Aware UPF Selection Mechanism:

  • The failure-aware selector ranks UPFs by ascending failure count and descending time since last failure, then checks requested slice, DNN, and N3/N6 compatibility.It tracks failure counts and timing and prioritizes UPFs with fewer recent failures.Source: 4) Failure-Aware UPF Selection Mechanism · p. 7

V. EXPERIMENTAL RESULTS: UPF FAILURE AND RECOVERY ANALYSIS

  • The evaluation examines network behavior during UPF downtime and restored connectivity, using OAI 5G Core v1.5.0 with UE and gNB simulators.The environment used Ubuntu 20.04, Docker, and Docker Compose.Source: §V · p. 7

1) Network Architecture and Modules:

2) Custom SMF implementation:

The implementation modifies the SMF for session restoration and evaluates TCP and UDP traffic during UPF failure and recovery. TCP connectivity returned in about two seconds, while UDP testing showed stable bandwidth alongside some recovery-phase packet loss.

2) Custom SMF implementation:

  • Only the SMF module was modified; tests simulated failure by stopping and restarting the UPF container under an automatic-restart assumption.A final test also assessed recovery when infrastructure instantiated a new UPF with the same IP address.Source: 2) Custom SMF implementation · pp. 7–8

A. Session Restoration after UPF Failure

  • 2 seconds was the reported TCP connection recovery time after the UPF interruption, with only a brief pause in data transfer.TCP bandwidth began at approximately 1.05 Mbps, dropped to zero at second 8, rose to over 4 Mbps after recovery, and stabilized around 1.05 Mbps.Source: A. Session Restoration after UPF Failure · p. 8, Figure 5 · p. 8

B. Packet Loss and Connectivity Analysis

  • Approximately 1.05 Mbps UDP bandwidth remained stable, but a slight packet loss occurred during recovery without major downtime.The passage attributes the challenge of maintaining consistent UDP delivery during recovery to the protocol’s connectionless nature.Source: B. Packet Loss and Connectivity Analysis · p. 8, Figure 6 · p. 8

C. Download Traffic

The download tests show partial disruption with packet loss but comparatively stable latency, while scripted replacement restores connectivity in about 14 seconds. The conclusion extends the work with failure-aware UPF selection and identifies different-IP standby as a future extension.

C. Download Traffic

  • 16.2% packet loss occurred during the brief UPF outage; RTT was 3.0 ms minimum, 6.0 ms average, and 10.3 ms maximum, with 1.7 ms jitter.The arriving packets had delays comparable to steady-state operation, without large recovery-related latency spikes.Source: C. Download Traffic · p. 8
  • The outage caused partial rather than total connectivity loss, and longer TCP flows could continue because TCP retransmits lost data after the path returns.Ping exposed missing packets, while the surviving packets had stable latency.Source: C. Download Traffic · p. 8

D. Automated Recovery via UPF Replacement using a monitoring script

  • The monitoring script detects an unhealthy active UPF, starts a replacement with the same IP, and waits for connectivity to return; recovery took about 14 seconds.The measured duration includes container startup, IP assignment, and time for the replacement UPF to begin forwarding packets.Source: D. Automated Recovery via UPF… · pp. 8–9, Figure 8 · p. 9

E. Summary

  • Across TCP, UDP, ICMP, and monitoring tests, the mechanism maintained connectivity through UPF failures, with stable UDP throughput and automated recovery in 14 seconds.The TCP results showed a brief post-recovery bandwidth peak, while ping indicated low latency despite packet loss.Source: E. Summary · p. 9

VI. CONCLUSION & FUTURE WORK

  • The work modifies the SMF for application-layer session restoration and adds monitoring-based UPF restart and recovery, evaluated on the OpenAirInterface codebase.The authors characterize the implementation as practical for real-world deployments.Source: §VI · p. 9
  • Failure-aware UPF selection prioritizes nodes with fewer past failures and longer stable operation, while different-IP active-standby replacement would require gNB tunnel modification.The authors identify refinement of ranking criteria and integration of load and latency awareness as future work.Source: §VI · p. 9

APPENDIX A OAI SMF CODE BASE

The appendix narrows its codebase overview to the SMF, the module central to the paper's work. It outlines SMF architecture, its threads, and the tasks coordinated by the application.

APPENDIX A OAI SMF CODE BASE

  • The appendix focuses on the OAI SMF module because it is central to the work within a large codebase.It introduces the software architecture and component interactions before examining their implementation.Source: Appendix A · p. 9, A. Structure · p. 9

1) Software Architecture:

  • The SMF architecture includes an HTTP server for requests to other network modules and an SMF Application that executes procedures and generates responses.The primary components are illustrated in Fig. 9.Source: 1) Software Architecture · p. 9, Figure 9 · p. 9
  • After startup, the SMF Application coordinates three tasks: N4 handles PFCP messages, SBI handles HTTP requests, and APP processes mini-tasks through a queue and handler.The section also presents the overall software architecture in Fig. 10.Source: 1) Software Architecture · pp. 9–10, Figure 10 · p. 10

B. Inter-Task Communication

The SMF's Inter-Task Interface queues mini-tasks for sequential processing and enables responses between the SMF-App and other tasks. The appendix then describes the SMF-App, context, and procedure layers that manage session state and implement session operations.

B. Inter-Task Communication

  • The Inter-Task Interface (ITTI) sends mini-tasks from other tasks to the SMF-App queue for sequential processing and carries messages back to those tasks.This provides bidirectional communication among the tasks.Source: B. Inter-Task Communication · p. 10

C. Classes

  • The SMF-App is organized into hierarchical layers, including the SMF APP, SMF Context, and SMF Procedure layers.The SMF APP coordinates session management and recovery, while context and procedure layers handle session data and underlying operations.Source: C. Classes · p. 10, 1) SMF APP · p. 10, 2) SMF Context · p. 10

1) SMF APP:

  • The smf app class manages PDU-session establishment, modification, and release, tracks session identifiers, and monitors node status to trigger recovery actions.The smf context ref class stores identifiers such as SUPI and PDU session ID for user-specific session handling.Source: 1) SMF APP · p. 10

2) SMF Context:

  • The SMF Context layer stores PDU-session data such as DNN, SNSSAI, IP address, and QoS flows, and maintains the sessions associated with each UE.The smf pdu session class can get, set, or update QoS flows.Source: 2) SMF Context · p. 10

3) SMF Procedure:

  • The SMF Procedure layer implements session operations through procedures that process ITTI messages; its base class tracks transactions and provides a framework for responses.Specialized procedures create, update, or release SM contexts, including updates to QoS parameters or IP addresses.Source: 3) SMF Procedure · pp. 10–11

4) SMF PFCP Association:

The UPF layer represents associations between UPFs and sessions and models UPF connectivity with adjacency-list graphs. The implementation targets rapid recovery and records failure details for future UPF selection.

4) SMF PFCP Association:

APPENDIX B IMPLEMENTATION

  • The implementation combines rapid response to UPF failures with detailed failure-event records intended for future UPF selection.Source: Appendix B · p. 11
  • The implementation is publicly available.Source: Appendix B · p. 11

A. Fault Tolerance Mechanism

The mechanism extracts tunnel context from an existing PDU session and uses sequential SMF procedures to restore that context on the UPF. Establishment restores uplink context, and modification restores downlink context.

A. Fault Tolerance Mechanism

1) Executing the Fault-Tolerance Procedures:

B. Failure-Aware UPF Selection Mechanism

UPF status notifications trigger failure detection, and restart registration can pass the failed node ID to failure recording. The selection procedure uses failure scores and slice/DNN interface compatibility to choose a UPF.

1) Detecting the Failure:

  • Status notifications trigger handle_nf_status_notification, which identifies a failed UPF and initiates recovery actions or failure logging.Source: 1) Detecting the Failure · p. 12
  • When a registering UPF is already listed in smf_cfg.upfs, indicating a restart, the system forwards its node ID to record_failure.Source: 1) Detecting the Failure · p. 12

2) Updating Failure Information for the UPF node:

  • UpfNodeInfo records each UPF’s cumulative failure count and latest failure time; the timestamp supports analysis of failure intervals and restoration after repeated failures within a timeframe.Source: 2) Updating Failure Information for… · p. 12

3) Selecting a New UPF Based on the Criteria:

Loading 2610.03245v1…