Island-Ready Communication Networks: Connectivity Monitoring and State Synchronization for 5G Crisis Connectivity at the Edge

arXiv:2610.16284v1 [cs.NI] 12 Oct 2026

Island-Ready Communication Networks: Connectivity Monitoring and State Synchronization for 5G Crisis Connectivity at the Edge Leon Janzen* , Maria Koch* , Matthias Hollick*,† * Secure Mobile Networking Lab Technical University of Darmstadt Darmstadt, Germany {ljanzen,makoch,mhollick}@seemoo.tu-darmstadt.de † Secure Mobile Systems Group IMDEA Networks Institute Madrid, Spain matthias.hollick@networks.imdea.org October 14, 2026 Abstract Island-ready 5G deployments provide edge connectivity for isolated regions in crisis scenarios by switching to island operation when they are cut off from the global Internet. This work addresses open research challenges that hinder the practical realization of island readiness, with a focus on the required state synchronization and connectivity monitoring functionality. As a proof of concept and for performance evaluation, we integrate our solutions in open-source projects and emulate a country-wide 5G communication network with real-world cellular traffic. Our evaluation studies the switching latency of transitions to island operation, showing that most of the transition delay stems from the access network reconfiguration. We study the synchronization overhead of a highly distributed core network, finding that the synchronization traffic grows faster than linearly with the number of 5G cores, reaching peak synchronization data rates of 9.36 MB s−1 for a deployment of 50 cores.

1

Introduction

5G mobile networks are a complex system of systems, whose availability is taken for granted by the general public. However, the architecture of traditional 5G deployments, with only a few control-plane sites per country, results in long backhaul distances that 1

are susceptible to failure. On multiple occasions during recent crises, regions were cut off from the 5G network as a result of natural disasters or armed conflicts [14, 23, 17, 22, 15]. In the aftermath, survivors could not rely on 5G connectivity during crisis response. The concept of island readiness [25] aims to build resilience against such isolation incidents by distributing the 5G control plane across a high number of regions. While prior work demonstrates a minimal connectivity and synchronization proof of concept for 5G cores with focus on end-to-end connectivity and real smartphones [24], no largescale evaluation exists. In addition, open challenges remain around transitions between normal and island operation and the systematic integration of synchronization and connectivity functionality in the 5G control plane. Our first research question addresses the state synchronization and connectivity monitoring: RQ1. How can the state synchronization and connectivity monitoring of island-ready 5G cores benefit from failure detection and consensus protocols? Connectivity monitoring is necessary to detect isolation from global connectivity, triggering the activation of regional failover cores into island operation. In island operation, 5G connectivity is provided in a regional scope. This enables users to reach services hosted at the edge through the 5G access network, e. g., applications relevant for crisis response. Continuous state synchronization is necessary for two reasons: It enables distributed 5G cores to maintain a common global system view, and it enables failover cores to take over based on the most recent state. There exist numerous related works in the realms of failure detection and consensus protocols, which we review in Section 2 regarding their applicability to connectivity monitoring and state synchronization. Based on these, we introduce two novel 5G network functions in Section 3, the state synchronization function (SSF) and the connectivity monitoring function (CMF), that make state-of-the-art 5G deployments island-ready. We design and implement the SSF and CMF as custom network functions in the control plane of the popular opensource 5G core implementation Open5GS [40]. The concept of island readiness promises improved 5G connectivity, as it enables edge connectivity in isolated regions that would otherwise not be supported. However, it introduces overhead to the 5G system, as state synchronization and connectivity monitoring require additional resources. Our second research question is therefore concerned with the resource consumption of the novel SSF and CMF: RQ2. Which overhead do state synchronization and connectivity monitoring add to country-wide island-ready 5G deployments? Mobile network operators (MNOs) typically deploy country-wide 5G systems, which invites evaluation of island readiness in that setting. To this end, we derive a system model in Section 4 by generating topologies for country-wide 5G access and core networks with POBTOG [45]. We fine-tune parameters to align our system model with the real world and integrate the NetMob dataset [36] to simulate user uplink and downlink 2

traffic to application servers via the 5G user plane. Section 5 describes our 14-node Kubernetes cluster, on which we orchestrate an island-ready 5G control plane for France and simulate user plane connections of users in Paris and Lyon. Our large-scale simulation study allows evaluations of island readiness in a realistic setting. Section 6 covers our evaluation of the switching latency and synchronization overhead of the novel SSF and CMF. Our findings indicate that the synchronization overhead of island-ready communication networks grows faster than linearly with the number of 5G cores. In summary, we solve open challenges of island readiness by integrating SSF and CMF network functions in the 5G control plane (Sections 2 and 3). We conduct a largescale simulation study of country-wide communication networks (Sections 4 and 5) and evaluate the performance and resource overhead of island readiness (Section 6). With these contributions, we aim to accelerate the realization of island-ready 5G and beyond mobile networks. We publish the Ansible playbooks, Helm charts, Kubernetes manifest files, Docker images, and Go scripts to allow reproducing and extending our findings.

2

Background and Related Work

The centerpiece of 5G communication networks is the 5G core, which is separated into a control and a user plane [1]. With 5G-Advanced (5G-A), the user plane function (UPF) can be deployed in a distributed manner to guide user traffic to the data network more directly. Still, the initial connection establishment has to be routed through the remote control plane, e. g., to the access and mobility management function (AMF). Today’s typical 5G deployments are assumed to feature a handful of 5G control-plane locations per country that provide a high-availability backend, minimizing the probability that all 5G cores are unavailable at the same time [48]. However, the long backhaul distances between users and the closest 5G core remain a major weakness in 5G deployments. Recent events have shown that natural disasters and armed conflicts likely cause Internet outages as a side effect. As a result, crisis response is often hindered because survivors cannot use 5G connectivity to coordinate efforts.

2.1

Island Readiness

The concept of island connectivity [26] describes how users can benefit from regional connectivity when global connectivity breaks, for example, to maintain communication, navigation, and information services for survivors during crisis response. Stateof-the-art connectivity solutions for isolation scenarios include mobile 5G cores with integrated base stations that can be brought to affected regions [35]. However, setting up these solutions takes time, which can be crucial during crisis response, while island connectivity seamlessly maintains regional connectivity. The vision of island readiness [25] analyzes which actors play a role in making 5G networks island-ready, e. g., MNOs distributing the 5G control plane, application developers adapting regional-first server architectures, and cloud providers creating additional edge capacity to keep up with changing demands. Today’s 5G deployments can be made island-ready by adding connectivity and synchronization functionality to state-of-the-art 5G control planes, and related work demonstrates the basic functionality of these components in a minimal lab

3

setup [24]. This work aims to support the ongoing quest for island readiness by filling the following research gaps: Research Gap. First, there has been no extensive survey of failure detection and consensus protocols for the connectivity and synchronization functionality of island-ready 5G cores (RQ1). Second, there has been no extensive evaluation of the overhead introduced by technologies enabling island readiness (RQ2).

2.2

Related Work

Consensus Protocols Over the past few decades, a broad spectrum of distributed consensus algorithms has emerged under different failure assumptions. There are crash fault tolerance protocols, such as Paxos [31] and Raft [39], which evolved into Pirogue [41] and RaftOptima [29]. In addition, there are Byzantine fault tolerance protocols, such as PBFT [7], Tendermint [30], and HotStuff [53], which evolved into Bullshark [49] as well as Narwhal and Tusk [11]. Failure Detection Basic failure detection is often implemented using health-check protocols, where components regularly exchange short heartbeat-like messages [27]. Beyond that, Chandra et al. laid the basis for more advanced failure detectors [8], proving it impossible to design a failure detector that holds strong completeness and perfect accuracy in asynchronous environments. The 𝜙-accrual failure detector [20] offers high scalability through statistical analysis of individual links. It was extended into a protocol for large-scale distributed systems [33]. Gossip [47] introduced epidemic-style heartbeat checks with random subsets of neighbors, which influenced SWIM [12], Lifeguard [10], and memberlist [18] that is used in Serf [44] and Consul [19]. Falcon [34] aims to design a reliable failure detector by coordinating a network of spies monitoring different layers. Related 5G Simulation Studies Numerous papers describe experiments with cloudnative 5G deployments in Kubernetes [4, 52], some of which consider the regional aspects of multi-access edge computing (MEC) [51]. Others discuss the availability and resilience of 5G deployments [13, 42]. There are performance studies with large-scale 5G simulations [50]. CoreKube [32] presents a cloud-native resilient 5G core design that focuses on scalability instead of transitions to regional connectivity. Island-ready 5G deployments have only been simulated in minimal form, and this work presents the first large-scale simulation study of island-ready communication networks.

3

Design

We integrate state synchronization and connectivity monitoring into island-ready 5G cores by adding novel CMF and SSF network functions to the 5G control plane. Figure 1 visualizes the interplay of these network functions across multiple 5G cores.

4

connectivity monitoring

AMF

AUSF

BSF

NRF

PCF

CMF

CMF

CMF

SCP

SMF

UDM

UDR

UPF

SSF

SSF

SSF

state synchronization

Figure 1: Island-Ready 5G Control Plane. The boxes mark three 5G cores from different regions. We add novel CMF and SSF network functions to make 5G cores island-ready. The remaining network functions are explained in TS 23.501 [1]. Table 1: Consensus Protocol Survey. (◩), or not at all (□). Protocol SWIM [12] 𝜙 Accrual [20] Raft [39] Pirogue [41] RaftOptima [29] Falcon [34] Paxos [31] PBFT [7]

3.1

Protocols fulfill criteria fully (■), partially

Applicability Availability Consistency Recovery ■ ■ ■ ◩ ◩ □ □ □

■ ■ ■ □ □ ◩ □ □

□ □ ■ ■ ■ □ ■ ■

□ □ ■ ■ ■ □ ■ ■

Connectivity Monitoring Function (CMF)

The CMF monitors connectivity between 5G cores. This connection is typically preconfigured, e. g., for many regional failover cores monitoring the same active core, which drastically simplifies the task description. As a result, the benefits of advanced failure detection protocols do not apply, and the additional overhead they incur makes them undesirable to use. Instead, we implement the CMF with a heartbeat-based protocol that checks the liveness of other CMFs, triggering transitions between normal and island operation based on failure and recovery thresholds.

3.2

State Synchronization Function (SSF)

The SSF replicates the state of all 5G network functions between the cores. This enables failover cores to activate in island operation and serve users with island connec5

tivity based on the most recent state. In addition, the SSF must handle divergent states, e. g., when failover cores reconnect to the core network after an outage. For these tasks, suitable consensus protocols need to handle state consistency across the nationwide deployment. Table 1 summarizes our consensus protocol survey regarding these criteria, including the protocol’s applicability to island readiness and the availability of its source code. Raft [39] achieves consensus efficiently with a small subset of voting members that elect a primary for write operations.

4

System Model

Our system model covers end-to-end connections between users and application servers through the 5G network. Country-Wide 5G Deployments POBTOG [45] creates country-wide communication network topologies using population density as a proxy for the number of end users per area. POBTOG generates hierarchical networks of 𝑛 layers, requiring 𝑛 = 4 layers to model raft cores, active cores, failover cores, and base stations. The topology and node count per layer are configured through the parameters 𝑇 and 𝑁. The number of nodes of the lowest layer, 𝑁𝑛−1 , is automatically determined through parameter 𝑃 , as POBTOG iteratively divides the configured country into Voronoi cells until each cell holds no more than 𝑃 inhabitants. End-to-End Connectivity for Users and Applications In our model, applications are hosted on the Internet and accessed through 5G connectivity. The user equipment, i. e., the user’s smartphone, connects to a nearby base station, adding a star-topology access layer below the POBTOG network topology. Users send uplink traffic to the application servers, and receive downlink traffic in return. We model the application server deployment that maps each application to regions with local access after selecting two disjoint subsets of traditionally hosted and island-ready applications. In this context, a region means the area served by an active or failover 5G core, and island-ready applications feature servers in all regions. Single Snapshots vs. Dynamic Simulation The aforementioned notations enable modeling end-to-end connections between users and application servers via 5G for a single snapshot of the system. Modeling the system over time requires considering timeslots and the uplink and downlink traffic per timeslot.

4.1

Practical Considerations

We configure our system model parameters to simulate a realistic country-wide 5G deployment, combining available datasets as summarized in Table 2. Where applicable, we highlight the limitations of our design choices and mention alternative approaches. First of all, we choose to simulate a 5G deployment in France, which is mainly concentrated around Paris but also includes metropolitan areas, medium-sized cities, and rural areas. 6

Table 2: System Model. We model a 5G-based communication network (POBTOG) and emulate end-to-end connectivity to messenger applications with real-world cellular traffic (NetMob). System

Layer

Source

Topology

#Nodes

Data

Application deployments

NetMob [36]

Mesh

6

5G Core

Raft cores Active cores Failover cores

POBTOG [45]

Mesh Star Star

5 25 500

5G RAN

Base stations

POBTOG [45]

Ring

64 752

Users

User equipment

NetMob [36]

Star

876 593a

a One node corresponds to the users in one 100 × 100 m NetMob tile.

5G Core and Access Network Deployments Traditional deployments are expected to feature three to five 5G cores for countries the size of France. These cores are typically deployed in a high-availability setup spanning multiple regions. Since our consensus protocols survey suggests Raft-based synchronization, and Raft is designed for three, five, or seven voting members, we simulate 𝑁0 = 5 raft cores. Our work is motivated by the goal of increasing the end-to-end resilience of 5G deployments by adding active and failover cores to achieve higher geo-redundancy and enable more regions to provide island connectivity. Accordingly, we use Level 𝐿1 to model active cores, i. e., 5G cores that are operating non-stop in addition to the raft cores. Level 𝐿2 models failover cores, i. e., 5G cores that only activate when the region forms an island. Note that the total number of active and failover cores 𝑁1 + 𝑁2 determines the number of regions that can form an island upon isolation from the remaining 5G network. Related work suggests that failover cores can increase resource efficiency in regions where the permanent operation of an active core is undesirable. Base Stations POBTOG has a configuration parameter 𝑃 that sets the maximum number of users allowed in the cell around a base station. It iteratively divides the country into Voronoi cells until all cells contain 𝑃 or fewer users, thereby determining 𝑁3 . We test different values of 𝑃 and compare the resulting number of base stations with the actual number deployed in France. With 𝑃 = 1500, POBTOG generates 64 752 base stations, which closely resembles the real number of 63 936 base stations reported in [3]. Figure 2 depicts the POBTOG topology with 𝑁 = [5, 25, 500], 𝑇 = [mesh, star, ring, star], and 𝑃 = 1500, showing a France-wide view of the active and raft cores, a close-up of the failover cores in the city of Lyon, and a detailed view of the users of a single region. Real-World Cellular Traffic We aim to incorporate real-world cellular traffic data into our evaluation to achieve results that are grounded in reality. The NetMob dataset [36] contains such data for 20 metropolitan areas in France. It has a spatial resolution of 7

(a) Raft and Active Cores

(b) Failover Cores

(c) Base Stations and NetMob Tiles

Figure 2: Simulation Scope. We simulate five raft cores (⬣), one active core (◾), two failover cores (⦁), 310 base stations (▴), and the users of 1871 100 × 100 m NetMob tiles. 8

paris

central

Telegram

Telegram

WhatsApp

Telegram

10.10.45.21

10.10.45.23

10.10.45.33

10.10.45.22

10.45.0.0/17

934 UEs

lyon

176 gNBs

10.45.128.0/17 10.10.45.11

10.10.45.13

UPF

UPF

10.10.45.12

UPF 134 gNBs

937 UEs

Figure 3: Island-Ready 5G User Plane. In normal operation, the central UPF connects the /16 user equipment network to the global Internet. In island operation, the regional UPFs connect their regional /17 user equipment network to the regional Internet. 100 × 100 meter tiles, reporting the combined uplink and downlink traffic for users within that tile to protect the privacy of individual users. Therefore, we model users within a tile as a single entity and map them to the closest 𝐿3 base station. This mapping of NetMob tiles to POBTOG base stations connects both datasets in the geospatial dimension and extends our system model by a fifth layer. NetMob reports user traffic for 68 applications, six of which are messengers that a related study found to be a critical application category during island scenarios [26]. We opt to use messengers as example applications, and simulate a fictitious scenario with two of them: In our model, WhatsApp is a centrally hosted messenger app, and Telegram is a messenger with an island-ready application backend, causing WhatsApp servers being available in only one region, whereas Telegram servers are deployed across all regions. Feasible Scope for the Simulation The entire network topology includes more than 60 000 base stations and 530 cores, exceeding our available resources. To align our simulation scope to our goals, we identified two regions, Paris-650801 and Lyon-64876, totaling 1871 NetMob tiles connected to 310 base stations. We simulate the end-to-end connectivity between these regions and the WhatsApp and Telegram application servers via 5G.

9

5

Setup

5.1

Kubernetes Cluster

We host a Kubernetes cluster on 14 workstations (nodes) in a local network, each operating Ubuntu 24.04. We use kubeadm [28] to set up the cluster, containerd [9] as the container runtime, and Calico [6] as the container networking interface. As visualized in Figure 3, the application servers and UPFs share a separate data network deployed with the multus plugin [38]. User equipment have Internet Protocol (IP) addresses in a dedicated /16 network, split into two /17 networks for the Paris and Lyon regions. Calico only manages the IP host routes for the Kubernetes pod network, so we manually add IP routes between all user equipment and the data network to all cluster nodes. Our setup enforces physical separation by mapping central and remote deployments to specific nodes with labels. One node is a dedicated Kubernetes control plane node, one node maps to the central region, and six nodes each map to Paris and Lyon. We provision the NetMob traffic data on all nodes, so user equipment and application server pods can mount it as volumes. We fix the scheduling of SSF pods with node selectors, so that they persistently use the same volume across restarts.

5.2

Workloads

We use Helm [21] to manage the workloads deployed on the cluster. We base our deployments on the excellent Helm chart collections of Gradiant [16] and Bitnami [5]. We install cores based on Open5GS [40] with additional pods for our SSF and CMF, using custom Helm values for raft, active, and failover cores. We install base stations and user equipment using ueransim [2] with a custom ueransim-ues Docker image that injects our evaluation code into all user equipment pods. In addition, we develop custom Helm releases for our SSF and CMF network functions, application servers, and load balancers. Core Network In the central region, we deploy six active cores, five of which have Raft functionality (raft cores). Active cores operate all 5G network functions and use the SSF to replicate state across the country. Raft cores are the voting members of the Raft-based MongoDB replica set [37], while active and failover cores are non-voting members. We deploy two failover cores: The one in Lyon connects to one of the central raft cores, and the one in Paris connects to a central (non-raft) active core. The only network functions of failover cores operating non-stop are SSF and CMF. Connectivity Monitoring and State Synchronization The CMF of the core replicas can have one of two roles: active or passive. Active CMFs expose a /health endpoint to be probed by passive CMFs. They also expose a /state endpoint that regional application deployments can probe to monitor whether the region is in normal operation or island operation. In normal operation, the central UPF covers the traffic from all regions. Once the CMF detects that the configured active core is unavailable, it signals 1 65080 and 64876 are the POBTOG IDs of the 5G failover cores.

10

the transition to island operation via its /state endpoint. Then, the failover core activates as an island core that operates all 5G network functions based on the most recent state synchronized through the SSF. Finally, the regional UPFs take over managing the traffic from the regional /17 user equipment networks. Access Network We deploy 176 base stations in Paris and 134 base stations in Lyon based on ueransim-gnb. Each base station is configured to connect to an AMF via the N2 interface and to an UPF via the N3 interface. In normal operation, all base stations connect to the central active core, but upon transition into island operation, they reconnect to the regional AMF and UPF. We map each NetMob tile to its closest base station and combine the tiles mapped to the same base station in one ueransim-ues pod, resulting in a mean number of 6.02 tiles representing the users of 602 m2 per user equipment pod. The Paris region is denser than the Lyon region, so the cell size operated by one base station in Paris is smaller than in Lyon. Each user equipment pod has a custom network interface that tunnels user traffic through the base station to the 5G core, which then forwards it to the data network via the N6 interface. Large-Scale 5G Connectivity Simulation. We simulate a core network with eight 5G cores, an access network with 310 base stations and the users of a combined area of 18.71 km2 on a 14-node Kubernetes cluster. Our setup establishes IP connectivity between users and application servers via the 5G user-plane protocol stack. State-ofthe-art 5G cores become island-ready with our CMF and SSF. Our setup enables various 5G connectivity experiments, e. g., testing applicationlayer connections on top of IP connectivity between users and the simulated Internet.

6

Evaluation

We run experiments on the Kubernetes cluster to test practical aspects of our SSF and CMF implementation and answer RQ2 regarding the added overhead. Each experiment uses the traffic of one NetMob timeslot and simulates application traffic exchanged between users and application servers via the 5G user plane. NetMob has a temporal resolution of 15-minute timeslots, collected over 77 consecutive days, resulting in 7392 total timeslots. Since these timeslots contain an unbalanced mix of working and nonworking days, and we abstract from day-night differences, we randomly select timeslots for the simulation and leverage the large number of data points to run our experiments multiple times for higher data quality.

6.1

Implementation

Figure 4 depicts the uplink and downlink traffic flow based on the NetMob dataset. User equipment have a dedicated evaluation endpoint /downlink, on which they listen for traffic, and application servers have equivalent /uplink endpoints. Prometheus [46] monitors the Kubernetes cluster, allowing an exhaustive view of the system’s resource 11

ues1337.ue

telegram.app

$ curl messenger.app/uplink 200 OK $ cat netmob/uplink.csv timeslot,app,uplink 0,whatsapp,1337 0,telegram,4207 1,whatsapp,9696 1,whatsapp,7954 ...

/uplink

/downlink

$ cat netmob/downlink.csv timeslot,ue,downlink 0,ue0,1337 0,ue1,4207 ... 0,ue1870,9696 1,ue0,5431 ... $ curl ues1337.ue/downlink 200 OK

Figure 4: Evaluation application programming interface (API) Endpoints. User equipment and application servers exchange NetMob uplink and downlink traffic through 5G. Detect Activate Reconf 0

50

100 150 Time (mean) [s]

200

Figure 5: Switching Latency. Reconfiguring the access network accounts for more than half of the transition time. consumption during simulation. In the data network, we deploy WhatsApp and Telegram application servers implemented in Go that simulate WhatsApp with a central backend architecture (i. e., a single server in the central region) and Telegram with an island-ready backend architecture (i. e., servers in all regions). We put a load balancer in front of each application backend to make the architecture transparent for the user equipment.

6.2

Switching Latency

The CMF waits for 𝑇𝐹 failed heartbeats before signaling the transition to island operation. High switching thresholds lead to a high number of lost packets before connectivity is restored, while low thresholds risk false-positive transitions to island operation. Finding a suitable threshold is therefore crucial for a smooth operation. We simulate normal operation before isolating the Paris region from global connectivity at 𝑡0 . It takes three steps to transition from global to island connectivity: Detect 𝑇𝐹 failed heartbeats and start the transition, activate the regional island core, and reconfigure the regional access network. Choosing a small 𝑇𝐹 can lead to false switches, as we observe for 𝑇𝐹 ≤ 3. Next, we measure the transition time until island connectivity is established:

12

1e7

Sync traffic rate [B/s]

1.0 0.8

Number of 5G cores 10 25 40 15 30 45 20 35 50

UE and base station shutdown 5G core shutdown

Base station deployment UE deployment

0.6 0.4

5G core deployment

0.2 0.0

0

200

400

Time [s]

600

800

1000

Figure 6: Synchronization Overhead. The total synchronization traffic grows faster than linearly with the number of 5G cores. After the final reconfiguration step, island connectivity is established at 𝑡1 , and the total switching latency is 𝜆 = 𝑡1 − 𝑡0 . Figure 5 depicts the mean duration per transition step in a broken bar chart. The results indicate that the switching threshold 𝑇𝐹 has a limited impact on switching latency, as activating the island core and reconfiguring the access network account for most of the delay. Our findings suggest a conservative 𝑇𝐹 to avoid false-positive transitions, and to assess acceleration options for the activation and reconfiguration steps.

6.3

Synchronization Overhead

In this experiment, we aim to study the message overhead introduced by the SSF in the 5G core network. We deploy a MongoDB exporter [43] sidecar container to each SSF pod to record the overhead of the MongoDB replica set. Figure 6 depicts the total synchronization traffic rate in the cluster over time. In the experiment, we deploy the 5G cores at 𝑡0 = 0 s and let them run idle until, at 𝑡1 = 300 s, we deploy the 310 base stations of Paris and Lyon. This leads to the first traffic spike around 𝑡 = 260 s, followed by another idle period until 𝑡2 = 600 s. Then, we deploy the 310 user equipment, triggering subscriber state updates that must be synchronized cluster-wide, leading to the second peak at 𝑡 = 640 s. The third traffic peak stems from the shutdown of all user equipment and base stations, and the final peak from the shutdown of the 5G cores. Our results indicate that the mean synchronization traffic increases from 273 kB s−1 to 4.54 MB s−1 as the number of cores increases from 10 to 50 in a country-wide 5G deployment. For the 50-core deployment, the peak synchronization rate is 9.36 MB s−1 for 1871 subscribers. More generally, the measured synchronization overhead increases faster than linearly with the number of 5G cores, which is consistent with the additional replication and consensus traffic of the MongoDB replica set.

13

7

Discussion

Our goal was to integrate state synchronization and connectivity monitoring functionality into state-of-the-art 5G cores to make them island-ready. To this end, we studied two research questions concerned with the applicability of consensus and failure detection protocols to the SSF and CMF (RQ1) and the overhead added to the core network (RQ2). Answers to RQ1 and RQ2. Heartbeat-based failure detection and Raft-based consensus are ideal choices to implement connectivity monitoring in the CMF and state synchronization in the SSF. Our findings indicate that the total synchronization overhead to enable island readiness grows faster than linearly with the number of 5G cores.

7.1

POBTOG Topologies

We worked with a progressive 5G deployment regarding its island readiness with 𝑁0 + 𝑁1 = 30 cores in normal operation and 𝑁2 = 500 failover 5G cores for island operation. In particular, 𝑁2 determines the size of island-ready regions because the topology and users connected to the same failover core are part of the region, which the failover core can provide island connectivity to. Still, expecting MNOs to operate 500 failover cores per country is ambitious, and we encourage future work to study island readiness in settings with fewer larger island-ready regions. For instance, considering all infrastructure connected to the same active core would result in 𝑁1 = 25 regions for France around the green squares in Figure 2a.

7.2

NetMob Traffic Data

We integrated POBTOG topologies with the NetMob dataset, which was available through the NetMob challenge, for our evaluation. Alternatively, e. g., without a suitable traffic dataset at hand, future work could configure POBTOG to generate an additional layer 𝐿4 and choose a smaller 𝑃 suitable to let 𝑁4 match the number of cellular users per tile. Since NetMob reports normalized traffic and prohibits attempts to reverse the normalization, we used a scaling factor 𝑆 that multiplies the traffic values to determine the number of packets that users and application servers send through the network per 15-minute timeslot. Our intention is that a suitable 𝑆 can align our simulation with the real world: We assume the highest recorded traffic value to correspond to the capacity limit 𝐶real of the French cellular network, so NetMob data implicitly records the normalized real-world capacity limit 𝐶norm . Therefore, identifying an 𝑆 that satisfies 𝑆 ⋅𝐶norm ≈ 𝐶sim allows simulating realistic traffic workloads without compromising the privacy of the collected NetMob data. To this end, we test increasing traffic alignment factors 𝑆 until our cluster reaches its capacity limit. We found that the Radio Resource Control (RRC) connection between the user equipment and the base station is the first point of failure. This error occurs when a base station is overloaded by uplink requests

14

from the user equipment and discards the user equipment’s RRC setup request, assuming that the user equipment context already exists. As a result, user equipment cell selection fails, and the user equipment cannot connect to the data network. The results show that the base stations in our setup are overloaded for 𝑆 ≥ 0.03125, suggesting that 𝑆 = .001 aligns our setup with the real world. Further experiments are necessary to generalize this finding, which we encourage for future work.

8

Conclusion

The main contributions of this work are the introduction and evaluation of state synchronization and connectivity monitoring functionality for island-ready 5G cores. To this end, we integrate a Raft-based SSF and a heartbeat-based CMF to the 5G control plane (RQ1), ensuring island readiness. We generate a nationwide 5G network topology for France, on which we conduct a large-scale simulation study using a real-world cellular traffic dataset. We orchestrate an island-ready 5G core network with eight cores and an access network of 310 base stations on a 14-node Kubernetes cluster. Our setup enables IP connectivity between all 5G user equipment and the simulated data network. We conduct experiments to study the transition latency of the CMF and the synchronization overhead of the SSF (RQ2), finding that most transition delay stems from the reconfiguration of the access network, and that synchronization overhead grows more than linearly with the number of 5G cores. With our contributions, we hope to pave the way for the widespread realization of island readiness.

Acknowledgments This work was supported by the Federal Ministry of Research, Technology and Space of Germany in the project Open6GHub+ (grant number: 16KIS2407) and by the LOEWE initiative (Hesse, Germany) within the emergenCITY center [LOEWE/1/12/519/03/05.001(0016)/72]. Parts of our work used data made available by Orange within the Netmob 2023 Challenge [36].

References [1]

3rd Generation Partnership Project (3GPP). System Architecture for the 5G System (5GS). Technical Specification 3GPP TS 23.501. 3rd Generation Partnership Project (3GPP), 2025.

[2]

Ali Güngör. Ueransim. URL: https://github.com/aligungr/UERANSIM.

[3]

ANFR. Bienvenue Sur Le Portail Open Data De l’ANFR - ANFR Open Data. URL : https://data.anfr.fr/.

[4]

Sergio Barrachina-Muñoz, Miquel Payaró, and Josep Mangues-Bafalluy. “CloudNative 5G Experimental Platform With Over-the-Air Transmissions and Endto-End Monitoring”. In: International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP). 2022. 15

[5]

Bitnami. Helm Charts. URL: https://github.com/bitnami/charts.

[6]

Calico. About Calico - Calico Documentation. URL: https://docs.tigera.i o/calico/latest/about.

[7]

Miguel Castro and Barbara Liskov. “Practical Byzantine Fault Tolerance and Proactive Recovery”. In: ACM Transactions on Computer Systems (2002). DOI: 10.1145/571637.571640.

[8]

Tushar Deepak Chandra and Sam Toueg. “Unreliable Failure Detectors for Reliable Distributed Systems”. In: Journal of the ACM (1996). DOI: 10.1145/22 6643.226647.

[9]

Containerd. Containerd. URL: https://containerd.io.

[10]

Armon Dadgar, James Phillips, and Jon Currey. “Lifeguard: Local Health Awareness for More Accurate Failure Detection”. In: 2018 48th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSNW). 2018. DOI: 10.1109/DSN-W.2018.00017.

[11]

George Danezis et al. “Narwhal and Tusk: A Dag-Based Mempool and Efficient BFT Consensus”. In: Proceedings of the Seventeenth European Conference on Computer Systems. 2022.

[12]

A. Das, I. Gupta, and A. Motivala. “SWIM: Scalable Weakly-Consistent InfectionStyle Process Group Membership Protocol”. In: Proceedings of the International Conference on Dependable Systems and Networks. 2002. DOI: 10.1109/DSN.2 002.1028914.

[13]

Luigi De Simone et al. “Performance and Availability Challenges in Designing Resilient 5G Architectures”. In: IEEE Transactions on Network and Service Management (2024).

[14]

Alexander Fekete and Simone Sandholz. “Here Comes the Flood, but Not Failure? Lessons to Learn After the Heavy Rain and Pluvial Floods in Germany 2021”. In: Water (2021). DOI: 10.3390/w13213016.

[15]

Raquel González-Pozo. “Social Profiles and Response Patterns During the 2025 Iberian Peninsula Power Outage. The Case of Spain”. In: International Journal of Disaster Risk Reduction (2025). DOI: 10.1016/j.ijdrr.2025.105813.

[16]

Grafiant. 5G Helm Charts. URL: https://github.com/Gradiant/5g-char ts.

[17]

Douglas Guilfoyle, Tamsin Phillipa Paige, and Rob McLaughlin. “The Final Frontier of Cyberspace: The Seabed Beyond National Jurisdiction and the Protection of Submarine Cables”. In: International & Comparative Law Quarterly (2022). DOI: 10.1017/S0020589322000227.

[18]

HashiCorp. Memberlist. URL: https://github.com/hashicorp/memberli st.

[19]

HashiCorp Developers. Consul. URL: https://developer.hashicorp.com /consul.

16

[20]

N. Hayashibara et al. “The Phi Accrual Failure Detector”. In: Proceedings of the 23rd IEEE International Symposium on Reliable Distributed Systems. 2004. DOI: 10.1109/RELDIS.2004.1353004.

[21]

Helm. Helm. URL: https://helm.sh/.

[22]

Internet Society. 2024 West Africa Submarine Cable Outage Report. URL: http s://www.internetsociety.org/resources/doc/2024/2024-west-afr ica-submarine-cable-outage-report/.

[23]

Akshath Jain et al. “The Ukrainian Internet Under Attack: An NDT Perspective”. In: Proceedings of the 22nd ACM Internet Measurement Conference. 2022. DOI: 10.1145/3517745.3561449.

[24]

Leon Janzen, Bastian Bloessl, and Matthias Hollick. “Island-Ready 5G Deployments: Decentralized Core Networks Enabling Crisis Connectivity at the Edge”. In: Proceedings of the 2026 International Federation for Information Processing (IFIP) Networking Conference (NETWORKING 2026). 2026. DOI: 10.2391 9/IFIPNetworking70592.2026.11579031.

[25]

Leon Janzen and Matthias Hollick. “Making Cellular Networks Crisis-Proof: Towards Island-Ready, Resilient-by-Design 6G Communication Networks”. In: Computer Communications (2026). DOI: 10.1016/j.comcom.2025.108407.

[26]

Leon Janzen et al. “The User Perspective on Island-Ready 6G Communication: A Survey of Future Smartphone Usage in Crisis-Struck Areas With Local Cellular Connectivity”. In: Proceedings of the CHI Conference on Human Factors in Computing Systems. 2025. DOI: 10.1145/3706598.3714324.

[27]

Marcos Kawazoe Aguilera, Wei Chen, and Sam Toueg. “Heartbeat: A TimeoutFree Failure Detector for Quiescent Reliable Communication”. In: International Workshop on Distributed Algorithms. 1997.

[28]

Kubernetes. Kubeadm. URL: https://kubernetes.io/docs/reference/s etup-tools/kubeadm/.

[29]

Kiran Kumar Kondru and Saranya Rajiakodi. “RaftOptima: An Optimised Raft With Enhanced Fault Tolerance, and Increased Scalability With Low Latency”. In: IEEE Access (2024). DOI: 10.1109/ACCESS.2024.3435978.

[30]

Jae Kwon. Tendermint: Consensus Without Mining. Draft. 2014.

[31]

Leslie Lamport. “The Part-Time Parliament”. In: ACM Transactions on Computer Systems (1998). DOI: 10.1145/279227.279229.

[32]

Jon Larrea, Andrew E Ferguson, and Mahesh K Marina. “CoreKube: An Efficient, Autoscaling and Resilient Mobile Core System”. In: Proceedings of the International Conference on Mobile Computing and Networking. 2023.

[33]

Andrei Lavinia et al. “A Failure Detection System for Large Scale Distributed Systems”. In: 2010 International Conference on Complex, Intelligent and Software Intensive Systems. 2010. DOI: 10.1109/CISIS.2010.29.

[34]

Joshua B. Leners et al. “Detecting Failures in Distributed Systems With the Falcon Spy Network”. In: Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles. 2011. DOI: 10.1145/2043556.2043583. 17

[35]

Eridy Lukau, Jochen Schiller, and Ulrich Meissen. “Public Safety Campus Networks: Towards a Reference Architecture for Post-Disaster Edge-Computing and Crisis-Communication”. In: 2024 IEEE World Forum on Public Safety Technology (WFPST). 2024. DOI: 10.1109/WFPST58552.2024.00033.

[36]

Orlando E Martínez-Durive et al. The NetMob23 Dataset: A High-Resolution Multi-Region Service-Level Mobile Data Traffic Cartography. 2023. arXiv: 230 5.06933.

[37]

MongoDB, Inc. Deploy a Self-Managed Replica Set. URL: https://www.mong odb.com/docs/manual/tutorial/deploy-replica-set/.

[38]

Multus. Multus CNI. URL: https://github.com/k8snetworkplumbingwg /multus-cni.

[39]

Diego Ongaro and John Ousterhout. “In Search of an Understandable Consensus Algorithm”. In: 2014 USENIX Annual Technical Conference (USENIX ATC 14). 2014.

[40]

Open5GS. Open5GS. URL: https://open5gs.org.

[41]

Jehan-François Pâris and Darrell D. E. Long. “Pirogue, a Lighter Dynamic Version of the Raft Distributed Consensus Algorithm”. In: IEEE International Performance Computing and Communications Conference (IPCCC). 2015. DOI: 10 .1109/PCCC.2015.7410281.

[42]

Sourav Paul, Tanvi Keluskar, and Mythili Vutukuru. “A Scalable and FaultTolerant 5G Core on Kubernetes”. In: 2025 17th International Conference on Communication Systems and Networks (COMSNETS). 2025.

[43]

Percona. Mongodb Exporter. URL: https://github.com/percona/mongodb _exporter.

[44]

James Phillips. Serf 0.8. URL: https://www.hashicorp.com/en/blog/ser f-0-8.

[45]

Fabian Poignée et al. “POBTOG: A Population-Based Topology Generator for Country-Wide Communication Networks”. In: International Conference on Networked Systems (NetSys). 2025. DOI: 10.22032/dbt.67118.

[46]

Prometheus/Prometheus-Community. Kube-Prometheus-Stack 82.10.5. URL: ht tps://artifacthub.io/packages/helm/prometheus-community/kube -prometheus-stack.

[47]

Robbert van Renesse, Yaron Minsky, and Mark Hayden. “A Gossip-Style Failure Detection Service”. In: Proceedings of the International Conference on Distributed Systems Platforms and Open Distributed Processing. 2009.

[48]

John Paul Rula. “Adopting a Gateway Centric View for Cellular Network Content Delivery”. Doctoral Thesis. Northwestern University, 2017. DOI: 10.21985/N2 6Q44.

[49]

Alexander Spiegelman et al. “Bullshark: Dag BFT Protocols Made Practical”. In: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 2022.

18

[50]

Sooraj Subramanian, Madhan Raj Kanagarathinam, and Krishna M Sivalingam. “Performance Evaluation of 5G Core Network Control-Plane Using Open5GS and Kubernetes”. In: 2025 17th International Conference on Communication Systems and Networks (COMSNETS). 2025.

[51]

Oana-Mihaela Ungureanu, Călin Vlădeanu, and Robert Kooij. “Collaborative Cloud-Edge: A Declarative API Orchestration Model for the Nextgen 5G Core”. In: 2021 IEEE International Conference on Service-Oriented System Engineering (SOSE). 2021.

[52]

Thisura Wijesekera et al. “Kube5GC: Kubernetes-Native Orchestration for 5G Core Network”. In: 2025 IEEE 13th International Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications (IDAACS). 2025.

[53]

Maofan Yin et al. “HotStuff: BFT Consensus With Linearity and Responsiveness”. In: Proceedings of the ACM Symposium on Principles of Distributed Computing. 2019. DOI: 10.1145/3293611.3331591.

19

Related documents

• Island-Ready Communication Networks: Connectivity Monitoring and State Synchronization for 5G Crisis Connectivity at the Edge#1327874
• Towards a Connected Heterogeneous All-Medium Integrated Network (CHAIN) for Converged Connectivity Across Land, Sea, Air, and Space#1083504
• Towards a Connected Heterogeneous All-Medium Integrated Network (CHAIN) for Converged Connectivity Across Land, Sea, Air, and Space#919313
• Reconfigurable Intelligent Surfaces for 6G and Beyond: A Comprehensive Survey from Theory to Deployment#1186336
• Energy-Efficient Federated Learning and Migration in Digital Twin Edge Networks#1123923