# Dyna-5G: A Dynamic, Flexible, and Self-Organizing 5G Network for M2M
Ecosystems

Evangelos Bitsikas
<EMAIL_ADDRESS>
Northeastern University  Adam Belfki
<EMAIL_ADDRESS>
Northeastern University
Aanjhan Ranganathan
<EMAIL_ADDRESS>
Northeastern University

###### Abstract

In this work, we present Dyna-5G, a dynamic, self-organizing 5G New Radio
(5G-NR) network designed for massive Machine-to-Machine (M2M) networks.
Traditional 5G NR networks, characterized by their centralized architecture,
face challenges in supporting applications that require dynamic, decentralized
communication, such as autonomous vehicles and drone swarms for emergency
responses. These scenarios often suffer from the centralized model’s single
point of failure, undermining the reliability required in critical and fully
autonomous applications. Dyna-5G addresses these challenges by allowing each
device in the network to function as either part of the Radio Access Network
(RAN) and Core Network, or as User Equipment (UE), thus maintaining network
functionality even when conventional infrastructure components are
compromised. Dyna-5G has built-in mechanisms carefully designed specifically
for M2M networks, such as failure-recovery and ad-hoc entry and exit. We
demonstrate the performance and feasibility of Dyna-5G using a custom-built
testbed that simulates real-world missions, demonstrating our network’s
robustness, adaptability, and failure recovery capabilities. The results
indicate that our entire 5G network model can fully re-organize in 6 seconds
at maximum, without compromising the mission.

##  1 Introduction

Massive machine-to-machine (M2M) networks are crucial for the deployment of
self-driving cars, smart factories, warehouses, and the use of swarms of
drones in emergency rescue and law enforcement operations. These applications
demand not just large-scale connectivity but also a dynamic, mobile, and
flexible network architecture. For example, in the aftermath of natural
disasters, drones can swarm over large, inaccessible areas to locate
survivors, map safe and unsafe zones, and assess damage [55, 53]. These swarms
employ several algorithms [56, 17, 18, 38, 10, 14, 46, 44] ranging from basic
swarm intelligence to consensus and formation, to dynamically adjust to the
evolving situation e.g., leader and follower can interchange based on real-
time data and operational demands or to route information with low latency.

The design of current cellular networks, including 5G NR [4, 2], inherently
relies on a centralized model that necessitates all communications to pass
through a base station or core network. This architecture introduces a single
point of failure, which is particularly problematic in security-critical
applications such as autonomous vehicular networks or emergency response
systems. Moreover, the fixed structure of cellular networks hampers the
ability to dynamically assign or change leaders, further limiting the system’s
resilience and adaptability in the face of node failures or changing
operational conditions. Additionally, the robotics community has long been
developing algorithms [45, 28] that presuppose a decentralized or distributed
communication model where each node in the network can directly communicate
with others. Such assumptions clash with the centralized nature of cellular
networks, potentially reducing the effectiveness of these algorithms or
negating their decentralized features altogether.

In this work, we design and develop Dyna-5G, a dynamic, self-organizing
cellular network based on 5G-NR. To the best of our knowledge, Dyna-5G is the
first instance of a dynamic 5G standalone (SA) deployment tailored
specifically for M2M networks. Consider the scenario of a drone swarm used in
emergency response leveraging a conventional 5G cellular network to
coordinate. In the event that a base station is taken out of commission, the
swarm becomes nonoperational. However, Dyna-5G’s self-organizing capabilities
enable drone swarms to maintain operational continuity as there is no single
point-of-failure. The key feature of Dyna-5G lies in its unique capability
where every drone within the swarm can function either as part of the Radio
Access Network (RAN)and Core Network or as a User Equipment (UE). The required
management and reorganization of the 5G network in fully autonomous missions
is a challenging task, as it necessitates proper network routing management,
resource allocation, and interoperability of the cellular stack with the M2M
operations. Dyna-5G incorporates novel mechanisms that enable the network to
reconfigure itself, e.g., dynamically, drones reassign roles and adjust
communication paths on the fly, ensuring uninterrupted mission operation.
Should a single drone become unresponsive—for instance, due to a dead
battery—Dyna-5G incorporates built-in failure recovery mechanisms that
efficiently reconfigure the network with minimal overhead, ensuring continued
operation.

Specifically, we make the following contributions in this work:

  1. 1.

We introduce Dyna-5G, the first dynamic, self-organizing 5G-NR-based network
specifically designed for M2M applications. At the heart of Dyna-5G is a state
machine controller, which orchestrates every critical action, including
initialization, failure recovery, swarm entry and exit protocols, and leader
selection. This controller is fundamental to the network’s adaptability,
interacting seamlessly with other components to make informed decisions and
maintain network integrity.

  2. 2.

We identify key metrics and design mechanisms that enable efficient network
re-organization as needed without undermining the structural integrity of the
network. This integrity is actually the network’s ability to maintain its
functional topology, operational stability, and intended service quality. For
instance, reorganization is required when the leader does not possess adequate
performance capabilities to host the Core and the RAN for the mission. A key
feature of Dyna-5G is the built-in failure recovery mechanisms. These
mechanisms continuously monitor the health of the RAN/core network and employ
specific metrics to detect anomalies. Upon identifying deviations, the system
can autonomously reconfigure the network or, if required, force the exit of
any failing entity, thus preserving the network’s operational integrity.

  3. 3.

We validate the feasibility of Dyna-5G using a custom-built hardware-software
testbed. Our setup emulates complete missions with high fidelity to real-world
scenarios, with all communications implemented on USRPs and conducted over the
air.

  4. 4.

We experimented on two scenarios; Battery Drop and Deviant Leader, in which
immediate transition was required. Dyna-5G could reconfigure the network in
less than 6 seconds, with the missions concluding successfully.

##  2 Background and Motivation

###  2.1 Massive M2M Applications and 5G

Massive M2M networks, crucial for industrial automation, smart cities, and IoT
systems, benefit from 5G’s promised faster speeds, lower latency, flexible
design, and enhanced device connectivity, ensuring more reliable and scalable
deployments. The operation of autonomous vehicles, including cars, drones, and
unmanned aerial vehicles (UAVs), relies heavily on M2M communications [8].
Additionally, 5G M2M communication significantly impacts precision
agriculture, as drones and automated machinery can coordinate tasks such as
planting, watering, and harvesting based on this data, optimizing agricultural
productivity and sustainability [21, 54]. Moreover, for emergency services and
public safety, massive M2M networks could enable real-time data sharing among
first responders, automated emergency alerts to citizens, and coordination of
rescue operations using drones or other autonomous systems. Considering the
widespread impact, it is imperative to design network architectures capable of
fully supporting and enhancing next-generation applications, many of which are
crucial for safety and security.

###  2.2 Drone Swarms Leveraging 5G M2M

In this paper, we use a drone swarm as our running example to underscore the
limitations of current designs and motivate our research. As demonstrated by
various massive M2M applications, drones, and autonomous vehicles more
broadly, are set to play a vital role. When operated in a coordinated swarm,
drones can execute complex tasks more effectively than a single drone. These
tasks encompass extensive environmental monitoring, swift search and rescue
missions, security surveillance, particularly in areas difficult to access or
survey through conventional methods. The drone acts as the endpoint in the M2M
communication chain, designed for tasks like data collection, real-time
monitoring, and payload delivery.

In a typical M2M communication scenario with drones in a 5G network [30, 41],
the drone first connects with the nearest gNodeB. The gNodeB connects the
drone to the core network, facilitating communication between the drone and
the network infrastructure or other connected devices. The RAN, comprising the
gNodeBs and the connecting infrastructure, manages all radio communications
between mobile devices and the core network. The core network is the backbone
of the 5G network, providing data routing, authentication, session management,
and mobility management. Once connected, the drones can reach the online
Virtual Private Network (VPN) server, and communicate with each via the
established VPN tunnels. Sections A and B discuss more about the drone
connectivity and the 5G infrastructure.

###  2.3 Motivation

In the context of fully autonomous drone missions, a critical concern revolves
around the potential vulnerability posed by single points of failure within
the communication network. The reliance on a static network architecture,
particularly with the necessity for all communications to route through a
central base station, amplifies this risk. Such a setup not only slows down
the decision-making process but also diminishes the system’s overall
responsiveness. Moreover, it heightens the susceptibility to disruptions (e.
g., lack of signal coverage), significantly undermining the reliability and
robustness of the entire system.

Beyond this fundamental challenge lies the intricate interplay of algorithms
tailored for various operational needs, as in [43, 36, 29, 15, 42, 39, 34].
Leader-follower algorithms, for instance, orchestrate operations by
designating a leader to guide the group, ensuring efficient task execution.
Consensus algorithms facilitate agreement among participating nodes, fostering
coordinated behavior in a decentralized manner, while swarm intelligence
algorithms draw inspiration from collective behavior observed in nature to
solve complex problems through simple agents working towards a common goal.

However, the full potential of these diverse algorithms remains unrealized
within the current static network architecture. Rapidly changing operational
demands may necessitate dynamic adaptations, rendering a static setup
inadequate. Moreover, the need for fast, reliable communication to achieve
consensus among nodes underscores the urgency for a more agile network
infrastructure. Thus, there is an urgent need to develop a dynamic 5G network
architecture that fully harnesses the potential of massive M2M networks. Such
an architecture would not only mitigate the risks associated with single
points of failure but also enable seamless integration and optimization of
various algorithms, thereby enhancing the drone missions’ efficiency and
resilience in dynamic environments.

##  3 Design of Dyna-5G

This section elaborates on the design requirements, architectural components
and cellular stack integration.

###  3.1 Design Requirements

We identify four primary design requirements essential for crafting a dynamic,
self-organizing 5G network that is suitable for massive M2M networks, such as
drone swarms. Figure 1 illustrates a dynamic drone network undergoing
reorganization due to leader failure, where a new leader drone is promptly
selected. This exemplifies the network’s capacity for adaptive leadership and
effective communication, essential for maintaining operational integrity. As a
result, we define four primary design requirements.

Figure 1: The drones execute a mission (blue shows the trajectory), when the
leader fails unexpectedly. The network reorganizes with a new leader (#4) as
it reaches the destination. The golden star denotes the leader (5GC & RAN),
whereas silver star indicates the follower (UE).

UE-UE Communication: The network design must enable UEs to communicate
directly to exchange data with each other, a capability often lacking in
traditional networks without specific modifications. Typically, commercial
networks have restrictive policies, and cellular systems for drones usually
require connectivity to external servers or cloud services for managing
communications. To address this, the requirement is to establish a design that
is agnostic to machine types—such as drones and vehicles—allowing for direct
UE-to-UE communication via the Core Network. This approach should obviate any
extra routing and tunneling protocols (e. g., BGP, IKEv2/IPsec).

Dynamic Core & RAN Selection: The network must grant machines this autonomy,
enabling dynamic reconfiguration in response to fluctuating demands and
operational conditions. This requirement is critical for overcoming the
rigidity of traditional 5G deployments that typically feature fixed Core and
RAN roles. In our envisioned network, every device should have the potential
to perform as UE, Core, or RAN, fostering a versatile and responsive network
ecosystem. This capability is paramount, as it diverges from conventional
network structures that restrict UEs to passive roles, thus limiting their
service capabilities.

Autonomous Network Organization: Devices must be capable of autonomously
establishing a private 5G network that is independent of external operators
and networks, like the Internet. Additionally, devices should be self-reliant
for network coverage, avoiding the unreliability and constraints of
traditional network providers. As a requirement, devices such as drones must
have the flexibility to configure network settings tailored to specific
operational needs, including network slicing or Quality of Service, a level of
customization not typically afforded by conventional mobile operators.

Enhanced Network Resilience: A dynamic network must be designed with enhanced
resilience, moving beyond traditional reliance on singular core components and
centralized databases. It should include (1) integrated failure detection and
recovery mechanisms that facilitate a swift transition of roles among UEs,
Cores, and RANs, and (2) a decentralized approach to storing encrypted
credentials, mitigating the risk of single points of failure within the
network.

###  3.2 Overview

Figure 2 illustrates the system components within each machine, with
activation depending on the machine’s designated network role.

State Controller. The state controller contains the logic of every Finite
State Machine (FSM) action and it interacts with the other components to make
the proper decisions about the network. Specifically, the state controller
enables/disables these components, retrieves data from them related to the
cellular procedures, and controls the Non-Access Stratum (NAS) and Radio
Resource Control (RRC) transmissions.

UE Stack. To enable communication between machines akin to regular smartphone
devices, each machine is equipped with a comprehensive UE stack. This stack
empowers them to establish both control-plane and user-plane connections. It
allows each machine to obtain a user-plane IP address, essential for routing
data between devices.

Core and RAN Stacks. The selected network machine running the Core and RAN
stacks for a specific duration, provides the infrastructure necessary to
initiate and orchestrate the 5G Core and RAN functions to establish the 5G
network. These functionalities are utilized only by the network leader.

Application Layer Server/Client. This client and server component (could be
HTTP(S), Mavlink, etc.) is necessary for the exchange of application layer
messages between machines. These messages are specific to the dynamic
network’s management, organization, control, and potentially mission-related
instructions and information. This component can operate once the 5G medium
has been established and the messages are controlled by the state controller.
Generally, this component is transparent to the underlying cellular
infrastructure.

Dynamic Network Table. It is imperative for the network’s operation as it
contains the necessary information/status (e. g., Session IPs) for machine
identification, routing and reorganization. The controller retrieves
information and updates the table regularly to reflect the latest network
state.

Figure 2: Components placed at each machine. The leader enables the 5G Core
and RAN parts, while the follower the User Equipment. The Network table and
Application Server are always operational for communication and
(re)organization. The State Controller handles all the components and makes
the proper decision.

###  3.3 The State Controller

We define the Finite-State Machine (FSM) of the State Controller starting with
the set of machines as M = $\\{m_{1},m_{2},\dots,m_{N}\\}$, where $M$ is the
set of all $N$ machines in the network. Each machine can be in one of the
three states: Null, Leader, or Follower, i. e.,
$S(m_{i})\in\\{\text{Null},\text{Leader},\text{Follower}\\}$, where $S(m_{i})$
represents the state of machine $m_{i}$. The “Follower” state triggers the
machine to function as a UE, while the “Leader” state enables the machine to
take on the roles of both the Core and RAN. The “Null” state indicates that
the machine is currently not active in any role. Each machine also has an
associated performance score denoted by $S^{*}$. Specifically, $S^{*}(m_{i})$
is the score of machine $m_{i}$.

At the very beginning, all machines start in the Null state: $\forall m_{i}\in
M,S(m_{i})=\text{Null}$. At the Initialization Phase, one randomly transitions
to the Leader state (with individual probability $P(m_{i})=1/N$) and the rest
to the Follower state. We generally follow the rule that the machine with the
highest accepted 111An accepted score for assuming leadership should pass a
predefined threshold to avoid ping pong effects and inefficient handovers. See
Section 4.2. performance score becomes the leader, i. e.,
$S(m_{L})=\text{Leader}$, where  $m_{L}=\text{argmax}_{m_{i}\in
M}S^{*}(m_{i})=S^{*}_{max}$. Whereas, all other machines become followers
denoted as: $\forall m_{i}\in M\setminus\\{m_{L}\\},S(m_{i})=\text{Follower}$.

Machines exchange performance scores throughout the network’s lifetime (see
Section 4.2). These performance scores are used to identify the next most
capable leader. Therefore, for any subsequent leader selection process that
potentially entails transition from the current leader to the next (if the
next has achieved the best score), we define the next leader as
$m_{L^{\prime}}$ fulfilling the $S^{*}(m_{L^{\prime}})>S^{*}(m_{L})$ and
$S^{*}(m_{L^{\prime}})=S^{*}_{max}$. Consequently, the old leader becomes a
follower $S(m_{L})=\text{Follower}$, while also
$S(m_{L^{\prime}})=\text{Leader}$.

Additionally, when the current leader fails or exits, the machine with the
next best score becomes the leader immediately as
$S(m_{L^{\prime}})=\text{Leader}$, with
$m_{L^{\prime}}=\text{argmax}_{m_{i}\in M\setminus\\{m_{L}\\}}S^{*}(m_{i})$.
As a result, the old Leader $m_{L}$ becomes a follower if it reconnects to the
network again, $S(m_{L})=\text{Follower}$, otherwise it remains in the Null
state $S(m_{L})=\text{Null}$. Followers that exit or fail are handled
similarly. Furthermore, when either normally entering the network or as part
of the recovery process, the machine always joins as a follower
($S(m_{i})=\text{Follower}$) to not disrupt the network status. Table 1
displays the actions, conditions, events, and FSM transitions. Figure 3
depicts the FSM with network states and their connections.

Table 1: FSM Actions and Transitions

Action | Event Symbol | Fulfilled Condition | State Transition
---|---|---|---
Initialization | $E_{I}$ | $P_{L}(m_{i})=\frac{1}{N},P_{F}(m_{i})=\frac{N-1}{N}$ | $S(m_{i})\xrightarrow[E_{I}]{P(m_{i})}\text{Leader/Follower}$
Entering | $E_{E}$ |  $m_{i}$ sends Entry Notification | $S(m_{i})\xrightarrow[E_{E}]{}\text{Follower}$
Leader Selection | $E_{LS}$ | $m_{L}=\text{argmax}_{m_{i}\in M}S^{*}(m_{i})$ |  $S(m_{i})\xrightarrow[E_{LS}]{m_{i}=m_{L}}\text{Leader}$, $S(m_{i})\xrightarrow[E_{LS}]{m_{i}\neq m_{L}}\text{Follower}$
Exiting | $E_{X}$ |  $m_{i}$ sends Exit Notification | $S(m_{i})\xrightarrow[E_{X}]{}\text{Null}$
Failure | $E_{F}$ |  $m_{i}$ exits without Exit Notification | $S(m_{i})\xrightarrow[E_{F}]{}\text{Null}$
Recovery | $E_{R}$ |  $m_{i}$ sends Entry Notification 22footnotemark: 2 | $S(m_{i})\xrightarrow[E_{R}]{}\text{Follower}$

Figure 3: State diagram for all machines in the network. Arrows denote the
Event which triggers each state change.

###  3.4 Cellular Stack Integration

In 5G networks [4, 2, 5, 1], the RAN is responsible for wireless communication
with UEs and includes base stations that facilitate this connectivity. On the
other hand, the Core encompasses various network functions essential for
maintaining and managing the network’s operation. Key elements within the Core
include the Access and Mobility Management Function (AMF), which plays a
crucial role in access control and mobility management, and the User Plane
Function (UPF), responsible for handling user data.

Figure 4 provides an overview of the steps necessary to establish a network
connection, which applies to our dynamic network as well. It begins with the
UE receiving broadcasted Master Information Blocks (MIBs) and System
Information Blocks (SIBs). Subsequently, the UE initiates the RRC connection
setup with the base station. Following the RRC connection establishment, the
UE proceeds to send a NAS Registration Request, kickstarting the
Authentication and Key Agreement (AKA) procedure. This AKA process culminates
with the exchange of the Security Mode Command & Complete, which establishes
the NAS security context. The Security Mode Command & Complete is also
utilized (but in RRC) in the Access Stratum (AS) security establishment with
the base station. This interaction with the base station reaches its
conclusion with the RRC Reconfiguration. Lastly, the PDU Session Establishment
phase takes place, during which the UE establishes the user plane tunneling
and obtains IPv4/IPv6 addresses, enabling the transmission of data traffic.
The subsequent data traffic corresponds to the application-layer messages
exchanged between machines.

Figure 4: UE-Drone establishing connection with the network. The RAN and Core
are hosted by another drone, which has been selected as network leader.

Integration Requirements. In order to meet the needs of this dynamic M2M
network, the 5G functions must be adapted accordingly. For traffic routing,
the UPF needs to redirect traffic destined for the Data Network between UEs.
This entails a Quality of Service Flow Identifier (QFI) resolution mechanism
for IP flows, involving GPRS Tunneling Protocol for the User Plane (GTP-U), to
redirect traffic back to the network, specifically towards the target UE. The
UPF’s packet handling procedures must also support this routing paradigm
including decapsulation and re-encapsulation of received packets based on
their intended destination UE. Effectively acting as a traffic intermediary,
the UPF ensures that data packets are correctly routed to the appropriate UEs
within the network. Open-source software, like Open5GS [37], support these
functionalities with proper configurations only (without excessive
modifications). Additionally, the UPF should have the same IP address subnet
as the UEs to facilitate IP connectivity. The UPF is assigned the X.X.X.1
address, which is always assigned to the leader, enabling communication with
the UEs. Section 6 further explores the rationale behind selecting 5G as the
basis for this network, while Sections B and C provide additional details
about the 5G network and the session parametrization.

##  4 Phases of Network Operation

We divide the network operation into three primary phases: Network
Initialization, Network Self-Organization, and Failure Recovery Mechanisms. We
utilize new application-layer message types we devised to carry out these
operations successfully (See Section E). Each phase has several components,
which are discussed in the following sections.

###  4.1 Network Initialization

Step 1: Preparation. When machines are powered on, the network undergoes a
complete organizational setup from scratch. In addition to configuring the
application layer, each machine must establish and configure the cellular
infrastructure and determine its role within the network before any
communication can commence. In this network configuration, one machine must
serve as the leader at any given time while the remaining machines operate as
followers. At this early stage, there is no actual leader under mutual
”agreement”, and each machine may consider itself as a potential leader.
Therefore, a random selection process is employed during boot time based on
the configurations used to designate the initial leader.

Upon activation, each machine within the swarm seamlessly imports the
configurations, checking its ID and its initial performance score, which is
100% or less. Under this nuanced methodology, a singular machine is
methodically designated with an exact score of 100%, assuming leadership. In
contrast, the remainder of the machines are diligently marked as UEs. The
machine leader instantiates the 5G Core Network stack, followed by the Radio
Access Network (RAN) stack. Additionally, it checks that the interfaces
between the Core and RAN are correctly set up. The machines-followers
initialize only the UE stack, ensuring it is ready to connect to the network.
If the machine is a UE, it establishes connection with the 5G Core, i. e., it
the completes Radio Resource Control (RRC) Connection, Authentication and Key
Agreement (AKA), and Packet Data Unit (PDU) Session establishment. The machine
validates the PDU Session’s IP address, which will be used for communication
with other machines. On the flip side, the machine, anointed with the dual
role of the 5G Core and RAN, acquires its IP address during the User Plane
Function (UPF) initialization, obviating the need for additional actions in
this context. All machines are configured to be in the same IP subnet. Each
machine creates and maintains a network table and heartbeat records. At first,
each machine enters only its own details on these lists. Specifically, it adds
the Machine ID (obtained from the configurations), Device ID (which is the
IMEI from the configurations), IP address (from the previous step),
Coordinates (from GPS/Satellite), Role (either follower or leader), and the
Score (100 or less at this stage). Once the IP addresses are available and the
network tables are initialized, the machines set up one application-layer
Server and Client. Algorithm 1 briefly shows the above steps, which run on
every network machine.

1

2if  _performance_score == 100_ then

3 initiate_5G_core_stack(__) ;

4 wait(2000);

5 initiate_RAN_stack(__) ;

6 ip_address $\leftarrow$ get_upf_address(__) ;

7 role $\leftarrow$ 1;

8

9 end if

10else if  _performance_score $<$ 100_ then

11 wait(4000);

12 initiate_UE_stack(__) ;

13 wait(1000);

14 verify_connection_with_5G_Core(__) ;

15 ip_address $\leftarrow$ get_IP_address_of_PDU(__) ;

16 role $\leftarrow$ 0;

17

18 end if

19create_network_table(__) ;

20 add_entry_to_network_table(_machine_id, device_id, ip_address, coordinates,
role, performance_score_);

21 setup_server(_ip_address, 8080_);

22 setup_client(__) ;

23

Algorithm 1 Network Preparation (Concise)

Step 2: Discovery & Association. Once the follower connects to the network, it
immediately sends an Entry Notification message to the leader to fully
establish its participation in the M2M network and waits for the Entry
Notification Reply. This is a crucial initial step in order for all the
machines to get the current state of the network (machine information, network
timers, network events, etc.) and be synchronized. The follower extracts the
heartbeat, performance evaluation and leader selection timers, as well as the
information of already active machines in the network (e. g., their session IP
addressed and identifications) from this message. Then, the internal table is
updated with all the machine information accordingly. On the leader side, the
server always listens for Entry Notification messages. Once received, the
leader extract the network state information and sends the Entry Notification
Reply, while also forwarding the Entry Notification to the already-established
followers in the network in order to update their tables as well.

The process ends with the initialization of the threads in each machine that
correspond to the network’s vital tasks: Heartbeat, Performance Evaluation,
Leader Selection and Failure Recovery processes. At this point, all machines
have a clear comprehension of the network organization and all the functions
synchronously running. The leader is only temporary, though. Therefore, the
next evaluation cycle (based on the timers) will determine whether the network
requires another leader.

Step 3: Post-Association. All machines that have joined the network listen to
incoming broadcast and unicast messages. They should be able to receive all
notifications, update the records, and perform the scheduled organizational
procedures accordingly. The heartbeats, performance evaluations, leader
selections, and Failure Recovery should run continuously throughout their
machine’s lifetime in the network. They should also be able to communicate
with each other for mission-related procedures.

Machines entering the network post-initialization need to perform the
association phase to inform others in the network and learn about the current
network state. This also applies to machines attempting to re-enter at a later
point. However, these machines join the network solely as followers (based on
Table 1) with a zero score in the Entry Notification, ensuring temporary low
privileges and network integrity. This process allows machines to participate
in network procedures without disrupting the mission, with the opportunity to
become leaders in the next evaluation and selection cycles or in case of
failure. If a machine fails and reconnects, it sends an Entry Notification
with ”reconnection” as the cause.

Furthermore, machines also have the ability to exit the network. In order to
smoothly perform the exiting process, the Exit Notification is used to inform
all entities in the network so they can update the tables, remove the machine
from the organizational procedures, and terminate functionalities related to
the exiting machine (e. g., missions, leader selection). This way, the network
can retain its stability. Machines that do not send this message before
exiting are considered faulty, and thus failure detection and recovery
mechanisms are used to mitigate any issues. Failure detection and recovery
mechanisms also allow leaders to send an Exit Notification with cause ”failure
alert” to avoid failures in case of emergencies proactively.

Tables & Timers. The Network Table example presented in Table 2, is an
essential dynamic component of this network’s information system. This table
integrates diverse but interrelated data points for each machine within the
network. For every machine identified by its unique Machine ID, the table
lists the Device ID using the IMEI number, which ensures each drone can be
precisely correlated with its cellular module. The Session IP address denotes
the network connection point for data exchange as instructed by the PDU
Session Establishment. The (latest reported) GPS Coordinates provide real-time
spatial positioning, crucial for navigation, tracking and performance
evaluation purposes. The current Network Role clearly distinguishes between
the ’Leader’ and the ’Followers’. Lastly, the (latest reported) Performance
Score quantitatively measures each machine’s operational effectiveness. In
addition to the network table, each machine collects the timestamp of the
received heartbeats from others in dynamic Heartbeat records. Together, these
information constructs a comprehensive picture of the network’s functioning,
machine status, and collective performance.

Table 2: Network Table Example

Machine ID Device ID Session IP GPS Coords Role Score A1 900000000000009
10.45.0.1 $X_{1}/Y_{1}/Z_{1}$ 1 (Leader) 85.6 B2 900000000000008 10.45.0.2
$X_{2}/Y_{2}/Z_{2}$ 0 (Follower) 72.3 C3 900000000000007 10.45.0.3
$X_{3}/Y_{3}/Z_{3}$ 0 (Follower) 67.8 D4 900000000000006 10.45.0.4
$X_{4}/Y_{4}/Z_{4}$ 0 (Follower) 63.2

Furthermore, the network utilizes three specific timers: for the heartbeat,
the performance evaluation, and the leader selection. Each of them has a
different interval based on the network requirements and configuration. These
are known to each machine entering the network from the leader’s Entry
Notification Reply, along with the time remaining for the next cycle of each
process. The leader acquires them from the configurations. Each timer starts
at the association phase and remains functional as long as the network is
operational.

  1. 1.

Heartbeat Timer ($T_{heartbeat}$). This timer has the smallest interval,
reinforcing its role in rapid failure detection and the timely dissemination
of spatial updates. Therefore, it is imperative that $T_{heartbeat}$ triggers
its event more frequently than other timers.

  2. 2.

Performance Evaluation Timer ($T_{performance}$). Each machine performs a
self-diagnostic to compute and share a performance score with the other
machines after the interval passes. The shared score is integral to the leader
selection mechanism. Therefore, the frequency of this timer is moderated
ensuring it is less frequent than heartbeat checks but more regular than
leader elections, in order to also save resources.

  3. 3.

Leader Selection Timer ($T_{selection}$). This timer governs the interval at
which the network initiates a leader selection and reorganizes itself. To
mitigate instability, such as ’ping-pong’ effects, and ensure network
resilience, the leader selection is the least frequent event contingent upon
potential emergency conditions. In case of failure, the timer is bypassed to
reorganize the network immediately.

###  4.2 Network Self-Organization

The reorganization of the machine network is aimed at maintaining the dynamic
network’s proper structure, ensuring the uninterrupted performance of
application layer activities by the machines, and determining the most
’capable’ leader. Figure 5 illustrates two machines during a reorganization
phase, which consists of three key phases, executed simultaneously by the
machines:

Figure 5: Operations between two machines. Both machines exchange heartbeat
notifications (1), execute their performance evaluations (2a) and share the
performance reports (2b), and complete the leader selection process (3).

Heartbeat Process. The heartbeat process is executed every time the
$T_{heartbeat}$ expires. Each machine is responsible for sending and listening
for Heartbeat Notification messages. The message, containing essential
identification, current coordinates, status and timestamp data, to every other
active machine in the network. On the receptive end, machines persistently
listen for incoming heartbeat messages from their counterparts, updating the
”last seen” timestamp in the heartbeat records affiliated with each entity
upon receiving such messages, after the message validation. Next, the included
coordinates, a necessary part of the performance evaluation process, are also
updated in the network table.

Apart from containing vital information, heartbeats are also utilized to
monitor whether a machine is ’alive’ or not in the network. The timestamp
plays a pivotal role in the monitoring phase, wherein each entity oversees the
temporal gaps between the current time and the ”last seen” timestamp of every
other machine in the network. Failure recovery is triggered if this temporal
gap surpasses a specified timeout threshold, indicating a potential issue or
failure with the corresponding machine. Network entities update their network
records to exclude the faulty machine from all operations and communications
in case of a faulty follower. The network continues to remain functional
without any disruptions. Faulty leaders can either be identified via
missing/late heartbeats or potentially when there is no reception of messages
at all (indicating that routing and PDU sessions have failed). In such a
scenario, the handling mechanisms trigger the cellular verification procedures
to determine if leader selection is eventually required, thereby ensuring the
functionality of the network even amidst unforeseen operational issues.

Figure 6: Performance Evaluation & Leader Selection.

Performance Evaluation. The evaluation process is initiated by the expiration
of the $T_{performance}$ present in all machines. During this stage, each
machine individually assesses its performance, updates its network table, and
shares the calculated performance with the rest. Each machine informs all
network machines about its performance to ensure all tables remain updated by
disseminating Performance Report messages. Collecting performance reports from
other machines in the network eventually leads to updating each machine’s
network table. Figure 6 break down the components of the Performance
Evaluation.

Each machine in the network has unique attributes directly influencing its
capabilities and performance. These attributes encompass critical aspects like
processing power, memory capacity, battery life, communication range, etc. In
this network architecture, we consider the (1) Proximity to the Network’s
Center Mass, and (2) Computational/System Capacity, as the primary metrics for
scoring, which can be adapted based on the network requirements and scenarios.
The selected features and algorithms are presented as a proof-of-concept to
demonstrate the scoring methodology rather than the network’s design and
implementation (the paper’s focus). Our design approach provides flexibility
though, allowing for the integration of any algorithm and adjustment of
thresholds based on the specific mission and its requirements.

Spatial Proximity Score (Sp). This metric assesses a machine’s proximity to
the center of mass (COM) of all machines. Lower distances to the COM result in
higher scores. The concept is to favor machines closer to all, facilitating
effective communication with the leader. Machines at the network’s far edges
are unsuitable leaders due to inefficient communication. Each machine collects
the latest coordinates for calculation. Mathematically, the normalized formula
is represented as $Sp(i)=\frac{100}{1+a\cdot dist(P(i),COM_{x,y,z})}$, where
COM is the center of mass for each dimension (For example, for X, we have
$COM_{x}\&=\frac{1}{N}\sum_{k=1}^{N}X_{k}$), $dist(\cdot,\cdot)$ is the
Euclidean distance between the two input vectors for each dimension, $a$ is
the intensity factor ($0<a<1$), and $P(i)$ represents the machine $i$’s
position in the 3D space.

Computational Capacity Score (Cc). This metric evaluates the machine’s
hardware performance based on memory (M), battery (B), and processing power
(P). Since there must be at least a minimum amount of available resources to
carry out the Core and RAN responsibilities, this formula ensures that each
candidate machine meets the predefined operational standards or is above the
acceptable operational conditions. For instance, entities with optimal energy
reserves can effectively support the network, as power availability
significantly impacts one’s ability to perform duties. The formula is
represented as $Cc(i)=(M+B+P)/3,\text{iff }M>m_{\text{thres}}\text{,
}B>b_{\text{thres}},P>p_{\text{thres}}$. If the criteria are not satisfied,
then $Cc(i)=0$. ”M, B, P” are the percentages of machine’s available gigabytes
(Gb), watts (W), and gigahertz (GHz) for memory, battery, and processor
resources, respectively. The respective thresholds, denoted as
$m_{\text{threshold}},b_{\text{threshold}},p_{\text{threshold}}$, are set to
delineate a requisite minimum of resources.

Aggregated Performance Score. The score is calculated based on two factors:
$S(i)=(Sp(i)+Cc(i))/2$. After the process concludes, each machine updates its
value in the network table (the role remains constant until the leader
selection process is triggered or if the leader changes), and then sends the
score to the rest using the Performance Report message. Upon report’s receipt,
the machine conducts validation checks before updating the internal table.

Leader Selection. At the expiration of the timer $T_{selection}$ or in case of
an emergency, the machines identify the next leader (if any, passing
additional checks) by retrieving the scores from the updated and synchronized
network table, and performing $i^{*}=\arg\max_{i\in M}S(i)$, where each
machine $i\in M$ has a corresponding final score $S(i)$, and ($i^{*}$) is the
machine with the maximum score. Once the machine with the maximum performance
is identified, and as long as the the maximum score exceeds the predefined
threshold ($Score_{thres}$), all network tables are updated to reflect the
newly assigned roles. This threshold ensures that the top score $S(i^{*})$ is
significantly higher than the second-best score, warranting a reorganization
in non-emergency scenarios. In cases where the leader remains the same, there
is no need for change. Figure 6 displays the integral parts of the selection.

Next, the transition process starts with the candidate machine sending a
Transition Request to the current leader. The current leader verifies the
request to ensure: (1) its legitimacy, (2) the machine possesses the top
score, and (3) the smooth initiation of the leader selection. Once these
requirements are fulfilled, the current leader broadcasts the Transition Alert
to all machines initiating the transition process. Otherwise, it responds back
with Transition Failure, and the network continues as it is. Once the
Transition Alert is received, all followers disconnect, terminate all network
processes and suspend the application-layer. The leader becomes a follower
(UE), and the candidate becomes the leader (Core and RAN). The rest remain
followers, but reconnect to the new leader. All machines update their network
state and table, once they are connected again. Key elements such as security
context, temporary identifications, and resources (e. g., PDU IP address) are
released during the disconnection and subsequently renewed by the incoming
leader.

Figure 7: Leader transition process. After all the steps are complete, the
network reorganizes around Drone B2 as the new leader. The blue and black
arrows are the state-level and cellular-level procedures respectively.

###  4.3 Failure Recovery Mechanisms

The objective of these mechanisms is to rapidly detect any machines that have
become non-operational, placing particular emphasis on the identification of a
malfunctioning leaders. Upon such detection, the network’s entities engage in
recovery protocols. For non-leader (follower) machines, this entails their
removal from the network processes and tables. In the case of a leader
failure, it triggers the emergency leader selection process, bypassing the
timers. This step is crucial for the swift reorganization of the network and
ensuring that network records are promptly updated.

The initial detection phase relies on the heartbeats (Section 4.2). A
machine’s failure to meet the heartbeat protocol requirements indicates
operational failure, which may manifest as absent or significantly delayed
heartbeat signals. In scenarios where the leader is the failing entity,
network machines are required to execute cellular-level detection procedures
following a heartbeat anomaly. These supplementary procedures are designed to
glean insights into the cellular status of the leader, thereby assisting in
verifying whether the leader has entirely ceased functioning. The properties
and details of these mechanisms are succinctly outlined in Table 3.

Table 3: Comparison of Failure Detection Mechanisms Technique | Methodology | Type | Layer | Trigger Condition | Complexity
---|---|---|---|---|---
Heartbeats | Missing Heartbeats | Reactive | Application Layer | Continuous | Low
Health Monitoring | Vital Signs’ Thresholds | Proactive | System | Continuous | Low
RRC & NAS Layers | Missing/Faulty Connections | Reactive | Cellular | Failed Heartbeats | Low

Cellular-level Health Checks. These detection mechanisms are used to determine
if the RAN (base station) and Core are unavailable. In case where the checks
return a failure, then the leader selection process begins based on the latest
available records at each machine (the network tables are synchronized). The
next best candidate becomes the leader and the other machines reconnect to the
new one. It should also be mentioned that if the leader has not failed, then
the follower should be able to connect back if the 5G Synchronization Signal
(SS) is correctly identified and decoded 333In our work, the Core and RAN
configurations, such as the MNC and MCC, are the same for all machines..
Figure 8 shows the recovery process of a drone network. The leader selection
in this case is immediate and no actual transition is required (as in normal
scenarios), but a reconnection to a new leader, unlike Figure 7.

The checks consider feedback from the Core, RAN, and UE stacks at the NAS and
RRC levels. For example, if a UE attempts to establish an RRC connection but
repeatedly receives no setup response from the base station, this persistent
failure indicates an issue. Similarly, at the NAS layer, if procedures like
registration attempts and PDU Session Establishments receive no response or
acknowledgment, it points to potential Core failures. Therefore, we monitor
the stacks for RRC and NAS disconnections, as well as events related to radio
frequency overflow and underflow.

Figure 8: Drone failure recovery. Upon leader collapse (A1), drones detect
heartbeat failures and perform individual cellular-level checks to confirm
leader is not ’alive’. Leader selection is then initiated.

Proactive Measures. As an additional measure, continuous health monitoring of
the leader can be implemented. This proactive monitoring can include checking
the leader’s vital signs, such as processing power, memory usage, battery
life, cellular status and communication responsiveness. If any of these
metrics deviate significantly from normal values to cause failures or if the
leader tends to become unresponsive, the leader sends Exit Notification with
$cause$ ”failure alert” to trigger the leader selection and safely exit the
network. At the moment of the reception, all machines initiate the process of
assigning a new leader. Hence, this allows the network to avoid hard failure
and reorganize beforehand.

Handling Failed Message Deliveries. Devices in our network perform critical
checks to ensure the message reception before initiating essential processes
(at the timer expiration). Frequent dissemination of significant operational
messages (e.g., performance reports) minimizes the risk of missed updates.
Additionally, missing heartbeats are continuously detected and recorded, which
can be sent every couple of seconds and are sufficient for device updates. The
heartbeat thresholds can be adjusted based on mission conditions.

##  5 Evaluation and Results

Our experimentation is primarily focused on the dynamic aspects of network
management, particularly on leader selection, the process of transition, and
the network’s adaptive response to system changes during mission execution. We
investigate how these factors impact the overall success and efficiency of the
mission. We separate our experimentation into: (1) Controlled, and (2)
Mission-based.

###  5.1 Controlled Performance Experiments

The controlled experiments enable hundreds of runs without spatial
restrictions while manipulating the value of the performance score in order to
investigate various scenarios related to transition and failure recovery.
Additionally, it allows us to perform stress tests and leader failure
scenarios that are not feasible in a production environment. Our objective is
to meticulously monitor a range of network and system indicators to evaluate
performance and efficiency. Therefore, we ran a network on two and three
machines which was tasked to operate for an extended period of time.

In our work, we utilize the Open5GS [37] for the 5G core and the srsRAN [51]
for the 5G RAN. Our hardware setup includes three high-performance Ubuntu
Thinkpad laptops, each paired with an Ettus B210 USRP [22], representing the
communication system for the three actual M2M devices via 5G NR. We ensured
that only our program was operating during the experimentation while having
the USRPs running in a Faraday cage to eliminate interference. Based on the
srsRAN’s performance guidelines we tuned the CPU cores to work on Performance
Mode to avoid radio frequency overflows and underflows as much as possible.
More details on the configuration of the 5G network are presented in Section
D.

Figure 9: The time in seconds it approximately takes for each component to
become fully active in our setup.

Dynamic Network Times. Figure 9 shows the transition and failure recovery
times for our baseline experimentation. The overall time is mainly restricted
by the Core and RAN initialization (which includes the USRP initialization);
however, our design supports synchronized machines, so the transition happens
simultaneously without issues. The delays in the connection on the follower’s
side are larger in order to compensate for the Core and RAN initialization
time. The emergency transition 444In our failure recovery scenarios, the
leader fails completely, and the machines adjust their statuses accordingly.
takes slightly more time than the normal leader transition, as the machine
needs to shut down the current operations first. It should be noted that these
time durations can be reduced and adapted with Core, RAN, and UE component
optimization. Table 4 outlines the metrics and values from the controlled
experiments.

Network Performance. The goal is to demonstrate that the network can handle
high traffic loads even under baseline and constrained conditions. Hence, we
conducted iPerf tests, including Reverse Mode UDP Upload and Data Transmission
Reliability TCP Exchange, with 4 separate streams and 100 MBps bandwidth,
structured in approximately 10-second intervals, while the machines were
operating normally. In the upload test, the sender’s bitrate exhibited robust
performance, averaging approximately 18.1 Mbits/sec initially and escalating
to 21.2 Mbits/sec subsequently. Conversely, the receiver’s bitrate was
slightly lower, indicating a modest drop in transmission efficiency. In the
data transmission test, findings suggest somewhat conservative bitrate
utilization, with sender bitrates generally peaking at 1.05 Mbits/sec and
receiver bitrates averaging less than that. Nonetheless, occasional increases
in retransmissions were observed due to potential packet losses or network
congestion.

Table 4: Combined System and Network Performance Metrics Metric |  Value
---|---
Average Battery Consumption Increase |  25.47 Watts
Average User Mode CPU Time |  97.87%
Average System Mode CPU Time |  0.30%
Total CPU Utilization |  $<$ 98.17%
Virtual Memory Size |  1,063,768 KB
Resident Set Size |  4,992 KB
Percentage of Total Physical Memory |  0.02%
Packet Loss Rate |  $\approx$ 0.1%
C&C Throughput |  $\approx$ 0.147% of peak sender bitrate
Average Sender Bitrate (UDP Upload) |  18.1 Mbits/sec
Peak Sender Bitrate (UDP Upload) |  21.2 Mbits/sec
Peak Sender Bitrate (TCP Exchange) |  1.05 Mbits/sec
Average Receiver Bitrate (UDP Upload) |  15.3 Mbits/sec
Average Receiver Bitrate (TCP Exchange) |  $<$ 1.05 Mbits/sec

System Performance. Finally, our experiments in our baseline (unoptimized)
setup indicates that our network can run uninterrupted and continuously
without errors. According to Table 4, the average increase in battery
consumption while the program is active is approximately 25.47 Watts,
underscoring the program’s substantial but reasonable power usage given its
computational intensity. The program operates predominantly in user mode, with
an average of 97.87% CPU time spent in user mode compared to a minimal 0.30%
in system mode, indicating that the program is effectively utilizing the CPU
for its own processes rather than relying heavily on system calls. Moreover,
the program’s total CPU utilization stands at a maximum of 98.17%, showcasing
its ability to leverage computational resources to deliver its functionality
maximally. Nonetheless, this is an ubiquitous srsRAN requirement, and not a
mandatory condition of the Dyna-5G, meaning that another RAN software may
achieve a lower consumption. Despite this high CPU engagement, we expect 5G NR
to utilize features such as the discontinuous reception (DRX), wake-up signals
(WUS), and efficient resource allocation by the network, which significantly
reduce battery consumption. For distances greater than 100 meters, these
power-saving mechanisms are crucial in maintaining operational efficiency. The
program also maintains a low and stable memory footprint, as evidenced by a
Virtual Memory Size (VSZ) of 1,063,768 KB and a Resident Set Size (RSS) of
4,992 KB. Additionally, it utilizes merely 0.02% of the total physical memory,
further highlighting its efficiency.

###  5.2 Mission-based Experiments

In addition to our previous experiments, we developed a simulated environment
for more convoluted test cases, considering scenarios involving two or three
drones in a swarm mission. We utilized a simulation environment based on
Gazebo [25], operating on an Ubuntu desktop computer configured with Docker
containers for each drone. Figures 10 and 15 depict our network architecture
for the mission-based experiments and setup, respectively.

Figure 10: Our experimental setup which comprises the simulated and the
physical infrastructures.

Geospatial data, primarily the drone coordinates during the mission, were
accessible very frequently from the Monitor Server via WiFi/Ethernet. This
information is vital for each state controller, which relies on these
coordinates for proper network decision-making, i. e., networks transition and
failures. In our experimentation, we did not notice any significant latency
between the computer and the laptops. For all the experiments conducted, we
have set the heartbeat, performance evaluation and leader selection intervals
to be 3, 6 and 26 seconds, respectively. For transition demonstration
purposes, we also kept the score threshold ($Score_{thres}$) to a low value,
i. e. equal to 2. Although all scoring parameters exist in the experiments, we
mainly focus on a specific parameter in order to observe its influence in each
case, while the other remains negligible. In addition, we utilize conservative
values for the thresholds m_thres = 80, b_thres = 80, and p_thres = 80.
Generally, we assume that all drones have the same hardware configurations
from the same manufacturer.

Experiment 1: Battery Drop. For this non-failure recovery scenario, we closely
deploy a two drone swarm in a line formation with instructions to move forward
at the same constant speed for 40 seconds. At takeoff, the first drone
operates as leader with a score of 100 and the second drone acts as a follower
with a score of 0. After a few seconds, the leader drone had a (prearranged)
gradual battery depletion falling below 80%, causing its performance score to
drop to 15, while the second drone score rises to 18. The scheduled leader
selection is triggered to identify the latest suitable leader, electing the
second drone within 6 seconds of network reorganization.

Experiment 2: Deviant Leader. In this scenario, a swarm of three drones
$d_{2}$, $d_{1}$, and $d_{3}$ are in a straight line formation during their
pre-armed state. At takeoff, $d_{1}$ \- with a performance score of 62 - acts
as the leader of the network with $d_{2}$ and $d_{3}$ connecting as followers.
During the mission’s first phase, all drones are fly forward at constant
speed, maintaining the formation. $d_{1}$ is located at the center of the
formation line while $d_{2}$ and $d_{3}$ are both 15 m away. When Phase 2 is
entered, $d_{1}$ increases its speed and starts deviating at a slight angle
which causes it to overtake $d_{2}$ at the front. Ultimately $d_{2}$ moves
away from the center of the formation by an average distance of 11.50 m, while
one the other hand, $d_{2}$ is getting closer to it with an average distance
of 8.65m. Table 5 provides insights on the swarm drones’ spatial performance.
At Phase 3, all vehicles resume moving forward at the same constant speed
which maintains the formation from the last phase. During this final phase,
$d_{1}$ sees its performance score drop to 16 while $d_{2}$ holds a score of
35; the periodical leader selection is initiated and elects $d_{2}$ as the
most suitable drone to ensure network connectivity and relay traffic. This
mission scenario has a total duration of 38 s; Figure 11 visually summarizes
all the scenario’s phases, and we provide a video of the simulation experiment
555Demo Link: https://youtu.be/wCU8c-tu6Lk. This experiment demonstrates the
impact of individual vehicle positioning and the swarm’s formation on leader
selection for optimal network coverage.

Table 5: Avg Distance, Scores, and Leaders for Each Phase of Experiment 2. Drones | Phase 1 | Phase 2 | Phase 3
---|---|---|---
Distance / Score | Distance / Score | Distance / Score
$d_{1}$ | 0 m / 62 | 11.50 m / 16 | 22.99 m / 16
$d_{2}$ | 15 m / 22 | 8.65 m / 51 | 5.20 m / 35
$d_{3}$ | 15 m / 22 | 21.56 m / 7 | 26.21 m / 5
Leader | $d_{1}$ | $d_{1}$ | $d_{2}$

##  6 Discussion

5G Over WiFi/LTE-M/NB-IOT. 5G’s expansive coverage area provides a significant
advantage over WiFi, particularly for machines operating in diverse
landscapes, as WiFi’s range may be limited to about 100 meters in outdoor
environments. 5G’s Ultra Reliable Low Latency Communication (URLLC) feature
achieves latencies as low as 1 millisecond [6], crucial for real-time
operations like coordinating drone swarms. Additionally, 5G’s reliability and
Quality of Service (QoS) capabilities surpass those of WiFi, LTE-M, and NB-
IoT, and network slicing enables customized virtual networks for specific IoT
applications. In terms of mobility management, 5G supports high speeds up to
500 km/h [3], unlike WiFi and LTE-M/NB-IoT, and offers precise positioning
capabilities potentially within a few centimeters, outperforming LTE-M and NB-
IoT.

Moreover, 5G introduces the Massive Machine Type Communications (mMTC), which
can support a vast number of devices per square kilometer—up to one million
devices—far surpassing the capacity of WiFi, LTE-M, and NB-IoT. Additionally,
5G’s ability to utilize higher frequency bands, such as millimeter wave
(mmWave), allows for unprecedented data rates and capacity, making it ideal
for bandwidth-intensive applications. Furthermore, 5G supports carrier
aggregation, enabling the combination of multiple frequency bands to increase
data throughput and network capacity, ensuring high-speed connectivity even in
areas with high user density. Finally, the 5G Standalone implementation sets
the stage for future enhancements like ORAN [35] and Machine Learning.

Challenges & Limitations. During our experimentation, we encountered
challenges stemming from the inherent constraints of USRP hardware
capabilities and the dynamics of Open5GS and srsRAN/srsUE interoperability.
These include radio-related issues, hardware overflows/underflows, and
compatibility issues of srsRAN/srsUE with specific USRP B210 devices (further
complicated by clock synchronization, power management challenges, etc.).
These challenges may result in improper connections, disconnections, and
unfinished transitions. While our setup is flexible in adapting to alternative
software solutions and the issues are not related to our development, these
obstacles highlight critical areas for enhancement and future work. Finally,
our experimentation is limited by the number of machines we can include due to
equipment constraints. While our current setup provides a solid proof-of-
concept, expanding the number of machines in future experiments is essential
to comprehensively evaluate significantly larger and more complex network
environments.

Figure 11: Deviant Leader Scenario Timeline.

##  7 Related Work

There is a plethora of works that elaborate on improving the LTE/5G legacy
infrastructure [20, 19, 40, 11, 9, 31, 33, 24], such as the Core, Radio Access
Network decentralization and device to device communications. Additionally,
designing drone-assisted cellular network have been explored [50, 49, 12, 7,
47, 26] to enhance the cellular networks further, as well as specialized
testbeds for experimentation [27, 13]. Studies [57, 23] also exist that
discuss the current status of the vehicular and aerial devices with 5G.
Nonetheless, this expansion primarily concerns targeted improvements and
reliance on a fixed infrastructure.

More relevant to dynamic networks are works [48, 16, 32, 52] that explore
enhancing UAV networks for flexibility and adaptability, while also providing
LTE support. Specifically, SkyCore offers an Edge-EPC solution tailored for
multi-UAV LTE networks, bypassing traditional EPC constraints in UAV settings.
In parallel, SkyRAN provides dynamic network access via a UAV-based LTE Radio
Access Network, dynamically providing network access using drones. SkyHaul, on
the other hand, presents an autonomous UAV network with mmWave mesh backhaul,
designed for high-bandwidth and low-latency needs. Lastly, SkyLiTE focuses on
augmenting LTE connectivity in areas with sparse infrastructure. However,
these works are not directly comparable to Dyna-5G, as entities in Dyna-5G
have the capability to interchange roles dynamically, and provide an
autonomous and flexible network structure. Moreover, the operational
applications are fundamentally different, since Dyna-5G is not limited to a
cellular network providing access/coverage to terrestrial devices (e. g.,
missions related to search and rescue).

##  8 Conclusion

In this study, we have innovated a dynamic network specifically for 5G
Machine-to-Machine communications, allowing devices to self-configure, elect
leaders, and dynamically adapt roles based on real-time network demands. This
approach not only enhances efficiency and flexibility but also incorporates
advanced failure management techniques, ensuring robustness crucial for high-
stakes applications. Our demonstration of this network’s application to drone
swarms underscores its potential on critical mission executions, from disaster
relief to infrastructure monitoring.

##  Appendix A Conventional Drone Communication Over Cellular

Figure 12: Connection of a LTE/5G drone to the QGC via a commercial-private
cellular network [30].

In the realm of LTE/5G-enabled drones, communication between a QGroundControl
(QGC) station and a drone predominantly relies on cellular networks, a
practical methodology supported by Qualcomm and ModalAI [30, 41]. As depicted
in Figure 12, this setup enables drones to be remotely managed via the QGC,
facilitated by either private or commercial cellular providers. Initially,
both drone and QGC establish a connection to the 5G core network, where they
are assigned distinct session IP addresses (e. g., drone: 10.47.x.y, GCS:
10.47.x.z) for internet access.

Subsequently, to ensure secure communication, both entities connect to a
Virtual Private Network (VPN) server via their cellular links, receiving
additional IP addresses (drone: 10.8.0.y, GCS: 10.8.0.z) from the VPN, which
runs server software in the cloud and client software on both drone and GCS.
This arrangement facilitates direct communication between the drone and GCS,
leveraging unique VPN IP addresses assigned to each.

For consistent and secure connections, it is crucial that the drone and GCS
maintain static IP addresses upon each VPN connection. This is achieved by
allocating unique security certificates to each network endpoint, ensuring
that upon connection with its certificate, each device consistently receives
the same IP address. Eventually, the communication involves an IP packet
encapsulated, with the application-layer data, by another IP packet.

##  Appendix B 5G Standalone Network

Figure 13 presents the legacy 5G network, which consists of the following
entities, based on 3GPP [4, 2]:

  1. 1.

AMF (Access and Mobility Management Function): The AMF is a core network
function in 5G responsible for managing access and mobility aspects of users.
It handles registration, authentication, and session management of User
Equipment (UE), ensuring seamless connectivity and mobility within the
network.

  2. 2.

SMF (Session Management Function): The SMF manages and maintains session data
for 5G users. It is responsible for setting up and managing data sessions,
allocating network resources, and controlling the flow of data within the
network. The SMF interfaces with the User Plane Function (UPF) to route and
forward user data.

  3. 3.

UPF (User Plane Function): The UPF is a crucial component in the 5G core
network, handling the data forwarding and routing. It processes and directs
user data between the 5G network and external networks or services. The UPF
plays a key role in ensuring efficient data transmission and connectivity.

  4. 4.

gNodeB (Next Generation NodeB): gNodeB is the base station in 5G networks, and
part of the Radio Access Network (RAN). It communicates wirelessly with User
Equipment (UE) and connects to the 5G core network. The gNodeB is vital for
providing radio access and managing radio resources for connected devices.

  5. 5.

UE (User Equipment): In 5G, UE refers to any device that communicates with the
5G network, such as smartphones, tablets, and IoT devices. It interfaces with
the gNodeB for radio communication and can access various services and data
through the 5G network.

  6. 6.

Data Network: In 5G, the Data Network (also known as Data Network Name, DNN)
represents the external networks or services that UEs can access. It could be
the internet, a private corporate network, or any other service network. The
Data Network provides the content and services that users access through the
5G network.

Figure 13: A brief representation of the 5G network.

##  Appendix C PDU Session Configurations

Fundamental Operations. The anchor UPF plays a critical role in mapping each
downlink packet to a specific Quality of Service (QoS) Flow associated with a
PDU Session. Similarly, the Service Data Adaptation Protocol (SDAP) layer
within the UE is responsible for mapping each uplink QoS Flow to a particular
Data Radio Bearer (DRB). Likewise, the SDAP layer within the base station’s
Central Unit (CU) is tasked with mapping each QoS Flow to an appropriate DRB.
When a UE initially connects to the network, it is assigned a default bearer,
which remains configured as long as the UE remains connected. The default
bearer is designed to offer the best service to the subscriber during the
initial attachment. Each default bearer comes with an IP address assigned by
the SMF. Additionally, a UE can have multiple default bearers for different
types of services, each with its unique IP address. The default bearer serves
as a PDU connection and typically persists until one of the following
conditions is met: the UE becomes detached from the network, the UE explicitly
initiates a PDU disconnection, or the network forcibly releases the default
bearer due to policy control.

In the user plane, a PDU Session illustrates a scenario where the UE is
connected through three separate radio bearers, each one corresponding to a
different QoS flow within the same PDU Session. These QoS flows are
differentiated by their respective QoS Flow Identifiers (QFIs) when traversing
the N3 interface. The N3 transport connection employed for this setup utilizes
a single GPRS Tunneling Protocol for the User Plane (GTP-U) tunnel for the
entire PDU Session. In the context of this GTP-U tunnel, the Tunnel Endpoint
Identifier (TEID) serves as a crucial element when establishing the connection
between the base station and the UPF.

Key Parameters. Figure 14 shows the routing operations, but with a redirection
back to another UE (restricted in commercial networks). Open5GS is generally
permissive regarding the UE-UE communication, while Data Network access is not
required (in our case). Nonetheless, we identify the following configurations
as necessary:

  1. 1.

Network Slice Consistency: All devices should be on the same network slice.
This requires them to have matching Network Slice Selection Assistance
Information (NSSAI) and Slice/Service Type (SST).

  2. 2.

Internal Routing: The network should be capable of internal routing using the
UE IP addresses. This also involves properly correlating the TEIDs and QFIs.
The UPF IP address should be in the same subnet as the UEs’ IP addresses.

  3. 3.

Unified SMF Configuration: The SMF should be set up with a single, consistent
pair of IPv4/IPv6 addresses. This uniform configuration simplifies packet
routing and resource management throughout the network.

  4. 4.

’Always-On’ PDU Sessions: For PDU sessions, maintaining a constant connection
as requested in the PDU Session Establishment is essential. This ’always-on’
status ensures continuous connectivity, facilitating efficient data transfer
and reducing latency. This is particularly important for dynamic drone
networks where real-time communication is vital.

  5. 5.

Session and Service Continuity (SSC) Mode 1: Implementing SSC Mode 1 provides
stable and continuous network connectivity for UEs. It maintains a consistent
IP address (either IPv4 or IPv6) for the PDU session, ensuring reliable
communication.

  6. 6.

PFCP and Traffic Routing: PFCP (Packet Forwarding Control Protocol) is
essential for managing user plane behavior and traffic in 5G networks. Key
elements within PFCP include PDRs (Packet Detection Rules) and FARs
(Forwarding Action Rules). PDRs identify how data packets between UEs are
recognized, while FARs determine how these packets are forwarded to ensure
they reach the correct recipient UE. These rules should not cause UE-UE
routing issues in this case.

Figure 14: 5G architecture for UE to UE communication.

##  Appendix D 5G Testing Network Configurations

Figure 15: Experimental Setup

(1) srsUE Configurations. The following primary configurations are used for
the 5G User Equipment (UE):

    [rf]
    freq_offset = 0
    tx_gain = 60
    rx_gain = 50
    srate = 23.04e6
    nof_antennas = 1
    device_name = uhd
    device_args = clock=external
    time_adv_nsamples = 300
    [rat.nr]
    bands = 3
    nof_carriers = 1
    max_nof_prb = 106
    nof_prb = 106
    [usim]
    mode = soft
    algo = milenage
    opc  = 63BFA50EE6523365FF14C1F45F88737D
    k    = 00112233445566778899aabbccddeeff
    imsi = 001010123456780
    imei = 353490069873319
    [rrc]
    release = 15
    ue_category = 4
    [nas]
    apn = dronenet
    apn_protocol = ipv4

(2) srsRAN Configurations. The following primary configurations are used for
the 5G Radio Access Network (RAN):

    amf:
      addr: 10.53.1.2
      bind_addr: 10.53.1.1
    ru_sdr:
      device_driver: uhd
      device_args: type=b200
      sync: external
      srate: 23.04
      tx_gain: 80
      rx_gain: 50
    cell_cfg:
      dl_arfcn: 368500
      band: 3
      channel_bandwidth_MHz: 20
      common_scs: 15
      plmn: "00101"
      tac: 1
      pdcch:
        dedicated:
          ss2_type: common
          dci_format_0_1_and_1_1: false
        common:
          ss0_index: 0
          coreset0_index: 12
      prach:
        prach_config_index: 1

(3) Open5GS Configurations. The following primary configurations are used for
the 5G Core network:

    test:
      serving:
        - plmn_id:
            mcc: 001
            mnc: 01
      gummei:
        - plmn_id:
            mcc: 001
            mnc: 01
          mme_gid: 2
          mme_code: 1
      tai:
        - plmn_id:
            mcc: 001
            mnc: 01
          tac: 1
      security:
        integrity_order : [ EIA2, EIA1, EIA0 ]
        ciphering_order : [ EEA0, EEA1, EEA2 ]
      network_name:
        full: DroneNet
      time:
        t3412:
          value: 540
    amf:
      sbi:
        server:
          - address: 127.0.0.5
            port: 7777
        client:
          scp:
            - uri: http://127.0.0.200:7777
      ngap:
        server:
          - address: 127.0.0.5
      metrics:
        server:
          - address: 127.0.0.5
            port: 9090
      guami:
        - plmn_id:
            mcc: 001
            mnc: 01
          amf_id:
            region: 2
            set: 1
      tai:
        - plmn_id:
            mcc: 001
            mnc: 01
          tac: 1
      plmn_support:
        - plmn_id:
            mcc: 001
            mnc: 01
          s_nssai:
            - sst: 1
      security:
        integrity_order : [ NIA2, NIA1, NIA0 ]
        ciphering_order : [ NEA0, NEA1, NEA2 ]
      network_name:
        full: DroneNet
      amf_name: open5gs-amf0
      time:
        t3512:
          value: 540

(a) The figure shows the drone network at the start of the mission.

(b) The figure shows the drone network at a later stage of the mission, where
the leader follows a different path.

Figure 16: Different network stages during the ’Lost’ leader scenario. Figure
17: Executed functions in one drone during the ’Lost’ Leader scenario.

##  Appendix E C&C Message Types & Structures

The Entry Notification structure encapsulates:

  * •

source machine id and destination machine id: The IDs of the sender and
receiver of the message.

  * •

timestamp: The time at which the message was created.

  * •

imei: The unique identifier for the device.

  * •

role: The role of the sender within the network.

  * •

performance: The current performance metrics of the sender.

  * •

ip address: The network address of the source machine.

  * •

gps_x, gps_y, and gps_z: The geographical coordinates (latitude, longitude,
and altitude) of the sender at the time of the message.

  * •

cause: The reason or cause for the entry notification.

The Entry Notification Reply structure encapsulates:

  * •

source machine id and destination machine id: The IDs of the sender and
receiver of the message.

  * •

timestamp: The creation time of the message.

  * •

selection timer interval, heartbeat timer interval, and evaluation timer
interval: Timers for leader selection, heartbeat signals, and performance
evaluation.

  * •

estimated performance: The estimated time for the next performance evaluation
cycle.

  * •

estimated leader selection: The estimated time for the next leader selection
cycle.

  * •

network table entries: All entries of the network table representing the
current network topology.

The Exit Notification structure encapsulates:

  * •

source machine id and destination machine id: The IDs of the sender and
receiver of the message.

  * •

timestamp: The time at which the message was created.

  * •

role: The role of the sender within the network.

  * •

cause: The reason for the exit notification.

The Performance Report structure encapsulates:

  * •

source machine id and destination machine id: The IDs of the sender and
receiver of the message.

  * •

timestamp: The time at which the message was created.

  * •

performance score: The performance score of the machine.

The Heartbeat Notification structure encapsulates:

  * •

source machine id and destination machine id: The IDs of the sender and
receiver of the message.

  * •

timestamp: The time at which the message was created.

  * •

cellular status, vehicle type, autopilot, base mode, and system status:
Operational parameters including cellular status, type of vehicle, autopilot
settings, base mode, and system status.

  * •

Vn, Ve, and Vd: Velocities in the north, east, and down directions,
respectively.

  * •

X, Y, and Z: Location coordinates.

  * •

heading: The direction in which the vehicle is pointed.

The Transition Request structure encapsulates:

  * •

source machine id and destination machine id: The IDs of the sender and
receiver of the message.

  * •

timestamp: The time at which the message was created.

  * •

candidate score: The score indicating the machine’s candidacy for transition.

  * •

cause: The reason for issuing the transition notification.

  * •

network status and transition plan: The current network status and the
proposed steps for the transition.

The Transition Alert structure encapsulates:

  * •

source machine id and destination machine id: The IDs of the sender and
receiver of the message.

  * •

timestamp: The time when the message was created.

  * •

approved candidate id: The identifier of the approved candidate.

  * •

transition start time: The scheduled start time for the transition.

  * •

network configuration change: The adjustments to the network configuration.

The Transition Failure structure encapsulates:

  * •

source machine id and destination machine id: The IDs of the sender and
receiver of the message.

  * •

timestamp: The time when the message was created.

  * •

failure cause: The reason for the failure.

  * •

retry policy, suggestive action, and supporting data: Guidance on subsequent
steps, including retry policies, recommended actions, and any additional
supporting data.

## References

  * [1] 3GPP.  5g; ng-ran; architecture description.  Technical Report 38 401, 3rd Generation Partnership Project (3GPP), 02 2024.  Version 17.7.0.
  * [2] 3GPP.  5g; procedures for the 5g system (5gs).  Technical Report 23.502, 3rd Generation Partnership Project (3GPP), 01 2024.  Version 17.11.0.
  * [3] 3GPP.  5g; study on scenarios and requirements for next generation access technologies.  Technical Report 38 913, 3rd Generation Partnership Project (3GPP), 04 2024.  Version 18.0.0.
  * [4] 3GPP.  5g; system architecture for the 5g system (5gs).  Technical Report 23 501, 3rd Generation Partnership Project (3GPP), 01 2024.  Version 17.11.0.
  * [5] 3GPP.  Lte; 5g; 5gs; user equipment (ue) conformance specification;.  Technical Report 38 523, 3rd Generation Partnership Project (3GPP), 02 2024.  Version 17.5.1.
  * [6] 5G Americas.  New services & applications with 5g ultra-reliable low latency communications, 2024.  Accessed: 2024-06-05.
  * [7] Aly Sabri Abdalla and Vuk Marojevic.  Communications standards for unmanned aircraft systems: The 3gpp perspective and research drivers.  IEEE Communications Standards Magazine, 5(1):70–77, 2021.
  * [8] M. Nadeem Ahangar, Qasim Z. Ahmed, Fahd A. Khan, and Maryam Hafeez.  A survey of autonomous vehicles: Enabling communication technologies and challenges.  Sensors, 21(3), 2021.
  * [9] Mukhtiar Ahmad, Syed Muhammad Nawazish Ali, Muhammad Taimoor Tariq, Syed Usman Jafri, Adnan Abbas, Syeda Mashal Abbas Zaidi, Muhammad Basit Iqbal Awan, Zartash Afzal Uzmi, and Zafar Ayyub Qazi.  Neutrino: A fast and consistent edge-based cellular control plane.  IEEE/ACM Transactions on Networking, 31(2):754–769, 2023.
  * [10] Saeed Hamood Alsamhi, Alexey V. Shvetsov, Svetlana V. Shvetsova, Ammar Hawbani, Mohsen Guizani, Mohammed A. Alhartomi, and Ou Ma.  Blockchain-empowered security and energy efficiency of drone swarm consensus for environment exploration.  IEEE Transactions on Green Communications and Networking, 7(1):328–338, 2023.
  * [11] SVR Anand, Serhat Arslan, Rajat Chopra, Sachin Katti, Milind Kumar Vaddiraju, Ranvir Rana, Peiyao Sheng, Himanshu Tyagi, and Pramod Viswanath.  Trust-free service measurement and payments for decentralized cellular networks.  In Proceedings of the 21st ACM Workshop on Hot Topics in Networks, HotNets ’22, page 68–75, New York, NY, USA, 2022. Association for Computing Machinery.
  * [12] Oussama Bekkouche, Konstantinos Samdanis, Miloud Bagaa, and Tarik Taleb.  A service-based architecture for enabling uav enhanced network services.  IEEE Network, 34(4):328–335, 2020.
  * [13] Leonardo Bonati, Pedram Johari, Michele Polese, Salvatore D’Oro, Subhramoy Mohanti, Miead Tehrani-Moayyed, Davide Villa, Shweta Shrivastava, Chinenye Tassie, Kurt Yoder, Ajeet Bagga, Paresh Patel, Ventz Petkov, Michael Seltser, Francesco Restuccia, Abhimanyu Gosain, Kaushik R. Chowdhury, Stefano Basagni, and Tommaso Melodia.  Colosseum: Large-Scale Wireless Experimentation Through Hardware-in-the-Loop Network Emulation.  In Proc. of IEEE Intl. Symp. on Dynamic Spectrum Access Networks (DySPAN), Virtual Conference, December 2021.
  * [14] Mitchell Campion, Ranganathan Prakash, and Saleh Faruque.  Uav swarm communication and control architectures: A review.  Journal of Unmanned Vehicle Systems, 7, 11 2018.
  * [15] Weijun Cao, Jinhui Zhang, and Wei Ren.  Leader–follower consensus of linear multi-agent systems with unknown external disturbances.  Systems & Control Letters, 82:64–70, 2015.
  * [16] Ayon Chakraborty, Eugene Chai, Karthikeyan Sundaresan, Mohammad Ali Amir Khojastepour, and Sampath Rangarajan.  Skyran: a self-organizing lte ran in the sky.  Proceedings of the 14th International Conference on emerging Networking EXperiments and Technologies, 2018.
  * [17] Wu Chen, Jiajia Liu, and Hongzhi Guo.  Achieving robust and efficient consensus for large-scale drone swarm.  IEEE Transactions on Vehicular Technology, 69(12):15867–15879, 2020.
  * [18] Wu Chen, Jiayi Zhu, Jiajia Liu, and Hongzhi Guo.  A fast coordination approach for large-scale drone swarm.  Journal of Network and Computer Applications, 221:103769, 2024.
  * [19] Zheng Chen and Marios Kountouris.  Decentralized opportunistic access for D2D underlaid cellular networks.  CoRR, abs/1607.05543, 2016.
  * [20] Junguk Cho, Ryan Stutsman, and Jacobus Van der Merwe.  Mobilestream: a scalable, programmable and evolvable mobile core control plane platform.  In Proceedings of the 14th International Conference on Emerging Networking EXperiments and Technologies, CoNEXT ’18, page 293–306, New York, NY, USA, 2018. Association for Computing Machinery.
  * [21] Ericsson.  Making the 5g precision agriculture connection, 2022.  Accessed: 2022.
  * [22] Ettus Research.  Ettus b210, 2024.  Accessed: 2024.
  * [23] Saqib Hakak, Thippa Reddy Gadekallu, Swarna Priya Ramu, Parimala M, Praveen Kumar Reddy Maddikunta, Chamitha de Alwis, and Madhusanka Liyanage.  Autonomous vehicles in 5g and beyond: A survey, 2022.
  * [24] Xin Jin, Li Erran Li, Laurent Vanbever, and Jennifer Rexford.  Softcell: scalable and flexible cellular core network architecture.  In Proceedings of the Ninth ACM Conference on Emerging Networking Experiments and Technologies, CoNEXT ’13, page 163–174, New York, NY, USA, 2013. Association for Computing Machinery.
  * [25] Nathan Koenig and Andrew Howard.  Design and use paradigms for gazebo, an open-source multi-robot simulator.  In IEEE/RSJ International Conference on Intelligent Robots and Systems, pages 2149–2154, Sendai, Japan, Sep 2004.
  * [26] Harilaos Koumaras, George Makropoulos, Michael Batistatos, Stavros Kolometsos, Anastasios Gogos, George Xilouris, Athanasios Sarlas, and Michail-Alexandros Kourtis.  5g-enabled uavs with command and control software component at the edge for supporting energy efficient opportunistic networks.  Energies, 14(5), 2021.
  * [27] Vuk Marojevic, Ismail Guvenc, Rudra Dutta, Mihail Sichitiu, and Brian Floyd.  Advanced wireless for unmanned aerial systems: 5g standardization, research challenges, and aerpaw experimentation platform.  IEEE Vehicular Technology Magazine, PP, 04 2020.
  * [28] Sonia Martínez, Jorge Cortés, and Francesco Bullo.  Motion coordination with distributed information.  IEEE Control Systems Magazine, 27:75–88, 2007.
  * [29] Mehran Mesbahi and Magnus Egerstedt.  Graph theoretic methods in multiagent networks.  In Princeton Series in Applied Mathematics, 2010.
  * [30] ModalAI Inc.  5g modems, 2023.  Accessed: 2023.
  * [31] Mehrdad Moradi, Yikai Lin, Z. Morley Mao, Subhabrata Sen, and Oliver Spatscheck.  Softbox: A customizable, low-latency, and scalable 5g core network architecture.  IEEE Journal on Selected Areas in Communications, 36(3):438–456, 2018.
  * [32] Mehrdad Moradi, Karthikeyan Sundaresan, Eugene Chai, Sampath Rangarajan, and Z. Morley Mao.  Skycore: Moving core to the edge for untethered and reliable uav-based lte networks.  Proceedings of the 24th Annual International Conference on Mobile Computing and Networking, 2018.
  * [33] Mohammad Mozaffari, Walid Saad, Mehdi Bennis, and Mérouane Debbah.  Unmanned aerial vehicle with underlaid device-to-device communications: Performance and tradeoffs.  IEEE Transactions on Wireless Communications, 15(6):3949–3963, 2016.
  * [34] Wei Ni and Daizhan Cheng.  Leader-following consensus of multi-agent systems under fixed and switching topologies.  Systems & Control Letters, 59(3):209–217, 2010.
  * [35] O-RAN Alliance.  O-ran specifications, 2024.  Accessed: 2024.
  * [36] Reza Olfati-Saber, J. Alex Fax, and Richard M. Murray.  Consensus and cooperation in networked multi-agent systems.  Proceedings of the IEEE, 95(1):215–233, 2007.
  * [37] Open5GS.  Open5gs software, 2024.  Accessed: 2024.
  * [38] Muslum Ozgur Ozmen, Habiba Farrukh, Hyungsub Kim, Antonio Bianchi, and Z. Berkay Celik.  Short: Rethinking secure pairing in drone swarms.  Proceedings Inaugural International Symposium on Vehicle Security & Privacy, 2023.
  * [39] Lynne Parker, Alan Schultz, and Frank Schneider.  Multi-robot Systems: From Swarms to Intelligent Automata: Proceedings from the 2003 International Workshop on Multi-Robot Systems.  Springer Publishing Company, Incorporated, 01 2003.
  * [40] Dalia Popescu, Philippe Jacquet, and Bernard Mans.  Connecting flying backhauls of uavs to enhance vehicular networks with fixed 5g nr infrastructure, 2021.
  * [41] Qualcomm.  Flight rb5 5g platform, 2023.  Accessed: 2023.
  * [42] Wei Ren and Randal W. Beard.  Distributed Consensus in Multi-vehicle Cooperative Control: Theory and Applications.  Springer Publishing Company, Incorporated, 1st edition, 2007.
  * [43] Wei Ren, R.W. Beard, and E.M. Atkins.  A survey of consensus problems in multi-agent coordination.  In Proceedings of the 2005, American Control Conference, 2005., pages 1859–1864 vol. 3, 2005.
  * [44] Mac Schwager, Daniela Rus, and Jean-Jacques E. Slotine.  Unifying geometric, probabilistic, and potential field approaches to multi-robot deployment.  The International Journal of Robotics Research, 30:371 – 383, 2011.
  * [45] Mac Schwager, Jean-Jacques Slotine, and Daniela Rus.  Decentralized, adaptive control for coverage with networked robots.  In Proceedings 2007 IEEE International Conference on Robotics and Automation, pages 3289–3294, 2007.
  * [46] Mac Schwager, Jean-Jacques E. Slotine, and Daniela Rus.  Consensus learning for distributed coverage control.  2008 IEEE International Conference on Robotics and Automation, pages 1042–1048, 2008.
  * [47] Silvia Sekander, Hina Tabassum, and Ekram Hossain.  Multi-tier drone architecture for 5g/b5g cellular networks: Challenges, trends, and prospects.  IEEE Communications Magazine, 56(3):96–103, 2018.
  * [48] Ramanujan K Sheshadri, Eugene Chai, Karthikeyan Sundaresan, and Sampath Rangarajan.  Skyhaul: An autonomous gigabit network fabric in the sky, 2020.
  * [49] Chetna Singhal and B N Chandana.  Aerial-son: Uav-based self-organizing network for video streaming in dense urban scenario.  In 2021 International Conference on COMmunication Systems & NETworkS (COMSNETS), pages 7–12, 2021.
  * [50] Mohammad Javad Sobouti, Zahra Rahimi, Amir Hossein Mohajerzadeh, Seyed Amin Hosseini Seno, Reza Ghanbari, Johann M. Marquez-Barja, and Hamed Ahmadi.  Efficient deployment of small cell base stations mounted on unmanned aerial vehicles for the internet of things infrastructure.  IEEE Sensors Journal, 20(13):7460–7471, 2020.
  * [51] srsRAN.  srsran software, 2024.  Accessed: 2024.
  * [52] Karthikeyan Sundaresan, Eugene Chai, Ayon Chakraborty, and Sampath Rangarajan.  Skylite: End-to-end design of low-altitude uav networks for providing lte connectivity.  ArXiv, abs/1802.06042, 2018.
  * [53] United Nations.  Drones for assessment of disaster damage and impact - revolutionizing disaster response, 2023.  Accessed: 2023.
  * [54] Verizon.  5g in agriculture: How smart farming is transforming the oldest industry, 2022.  Accessed: 2022.
  * [55] Verizon.  The expanding roles of emergency drones for disaster management, 2024.  Accessed: 2024.
  * [56] Taiqi Wang, Shuaihe Zhao, Yuanqing Xia, Zhenhua Pan, and Hanwen Tian.  Consensus control of large-scale uav swarm based on multi-layer graph.  Drones, 6(12), 2022.
  * [57] Qingqing Wu, Jie Xu, Yong Zeng, Derrick Wing Kwan Ng, Naofal Al-Dhahir, Robert Schober, and A. Lee Swindlehurst.  A comprehensive overview on 5g-and-beyond networks with uavs: From communications to sensing and intelligence.  IEEE Journal on Selected Areas in Communications, 39(10):2912–2945, 2021.