QPP-Aware MCX over Tactical Edge 3D Networks in Public-Safety Communications

Received XX Month, XXXX; revised XX Month, XXXX; accepted XX Month, XXXX; Date of publication XX Month, XXXX; date of current version 18 June, 2026. Digital Object Identifier 10.1109/OJCOMS.XXXX.XXXXXX

QPP-Aware MCX over Tactical Edge 3D Networks in Public-Safety Communications José Oliveira12 , Pedro Valente12 , Tiago Mendes12 , André Vasconcelos12 , Tiago Fernandes12 , Rhyan Matos12 , Duarte Raposo1 , Pedro Rito12 , Marco Araújo13 , Susana Sargento12

arXiv:2611.05165v1 [cs.NI] 3 Nov 2026

1

3

Instituto de Telecomunicacoes, Aveiro, 3810-193, Portugal 2 Universidade de Aveiro, Aveiro, 3810-193, Portugal Faculdade de Engenharia da Universidade do Porto, Porto, 4200-465, Portugal CORRESPONDING AUTHOR: oliveira.jose@ua.pt.

ABSTRACT

During disasters, public mobile networks may become unavailable, congested, or degraded, requiring deployable communication systems to support emergency operations. This article proposes a missioncritical communications system supporting Mission Critical Push-to-Talk (MCPTT), Mission Critical Video (MCVideo), and Mission Critical Data (MCData) over a private 5G standalone network with Non-Terrestrial Networks (NTN) connectivity. A context-aware Quality, Priority, and Pre-emption (QPP) mechanism is proposed to dynamically adapt network resource allocation according to the operational state of Mission Critical Services (MCX). Extensions to the Open5GS Policy Control Function (PCF) and Session Management Function (SMF) enable priority and pre-emption updates for existing flows without session re-establishment. The architecture supports tactical edge deployment of service and media functions while retaining centralized service control. Experimental evaluation considers three configurations: terrestrial backhaul with centralized media processing, satellite backhaul with centralized media processing, and satellite backhaul with edge media processing. Results show that tactical edge processing reduces communication delay and packet loss. Under satellite backhaul, edge processing reduced the 95th-percentile MCPTT audio transport delay by 60.03 ms and packet loss by 9.42 percentage points, while achieving a 95th-percentile MCPTT access time of 184.52 ms. These findings demonstrate the benefits of tactical edge media processing and provide an experimental foundation for context-aware priority mechanisms in public-safety networks integrating terrestrial and non-terrestrial components. INDEX TERMS MCX, MCPTT, MCVideo, MCData, QPP, public safety, private 5G, tactical edge, 3D

networks, UAV, NTN.

I. Introduction

The increasing frequency and intensity of weather and climate-related disasters are placing growing pressure on public safety and emergency response systems worldwide [1]. Large-scale events, such as floods, wildfires, and severe storms, can simultaneously increase demand for emergency services, damage terrestrial communication infrastructure, and disrupt coordination between response agencies [2], [3]. These conditions motivate resilient communication systems that can be rapidly deployed, provide controlled service quality for mission-critical applications, and remain

operational when conventional infrastructure is degraded or unavailable. Historically, public safety communications have relied on Land Mobile Radios (LMRs), including technologies such as Terrestrial Trunked Radio (TETRA), Project 25 (P25), and Digital Mobile Radio (DMR). Designed primarily for mission-critical voice, these systems provide essential capabilities such as group communication, direct-mode operation, and push-to-talk, but offer limited support for broadband data and multimedia services [4]. Consequently, they are poorly suited to emerging robotic operations involving Unmanned Aerial Vehicles (UAVs) and ground rovers, which require

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ VOLUME ,

1

Oliveira et al.:

reliable exchange of high-rate sensor data, real-time video, telemetry, and control information. These requirements motivate the transition toward broadband public safety networks based on 5G and future 6G technologies. Within this transition, the 3rd Generation Partnership Project (3GPP) MCX framework standardizes missioncritical voice, video, and data services over cellular networks. MCPTT provides individual and group voice communication with priority and floor control, while MCVideo and MCData support real-time video, situational awareness, messaging, positioning, and telemetry [5]. Supporting these services concurrently requires differentiated network treatment, as latency-sensitive voice and signaling must coexist with highrate video and background traffic. In 5G, Quality of Service (QoS) flows and policy control mechanisms across the 5G Core (5GC) and New Radio (NR) enable service differentiation according to communication requirements and operational priority, here referred to as Quality, Priority, and Pre-emption (QPP) [6]. Together with capabilities for group communication, extended coverage, and positioning, these mechanisms make 5G NR a key enabler for broadband mission-critical communications [7]. During large-scale disasters, terrestrial communication infrastructure may become damaged, congested, or unavailable, limiting network coverage and capacity when communication demand is high. Deployable 5G networks can restore local connectivity through portable infrastructure and aerial radio nodes, while NTN links can provide backhaul when terrestrial connectivity is disrupted [8], [9]. In this work, the integration of terrestrial, aerial, and NTN components is referred to as a 3D public-safety network. The heterogeneous latency and capacity of these links make function placement an important architectural consideration. Deploying latency-sensitive user plane and MCX media functions at the edge can keep local traffic within the deployable network, reducing dependence on remote backhaul while maintaining connectivity to external services when backhaul resources permit [10]. Despite these advances, end-to-end integration of missioncritical services with deployable 5G architectures remains insufficiently explored. In particular, a gap persists between MCX service priorities and their dynamic enforcement through Quality, Priority, and Pre-emption (QPP) mechanisms across the 5GC and Radio Access Network (RAN) [6]. Furthermore, the impact of edge function placement on MCX signaling and media traffic over constrained NTN backhaul remains insufficiently characterized in experimental deployments. This work investigates the dynamic translation of MCX service priorities into QPP enforcement across the 5GC and RAN, and evaluates how MCX function placement affects signaling and media traffic over constrained NTN backhaul. The main contributions of this work are: • A deployable multi-service MCX architecture integrating MCPTT, MCVideo, and MCData over a private 2

5G Standalone (SA) and IP Multimedia Subsystem (IMS) infrastructure. The architecture combines common MCX support functions, service specific Session Initiation Protocol (SIP) Application Server (AS) modules, edge capable media processing, tactical UAV endpoints and NTN backhaul within a common experimental platform. • A cross-layer QPP model for MCX that maps service and operational priorities to 5G network treatment. 5G QoS Identifier (5QI) defines service level forwarding requirements, while dynamic operational priority determines Allocation and Retention Priority (ARP)-based admission and preemption, complementing applicationlevel MCPTT floor control. • Dynamic QPP enforcement for active MCX communications. Extensions upstream to Open5GS map the N5 resPrio attribute to configurable ARP parameters, and dynamically update the priority and preemption treatment of established QoS flows. This enables operational transitions, such as emergency MCPTT, without session re-establishment or modification of the baseline 5QI. • A persistent unicast media architecture for MCPTT and MCVideo. The design maintains stable perparticipant signaling and media state, and allows MCPTT floor transitions to modify media forwarding without reconstructing the underlying session or network treatment. • An end-to-end experimental evaluation across service, network, and deployment conditions. Measurements across the MCX, SIP/IMS, media, 5G Core, and RAN layers are correlated under concurrent service load, resource scarcity and dynamic priority transitions. The evaluation further investigates an aerial edge deployment in which the Next-Generation NodeB (gNB), User Plane Function (UPF) and RTP engine are placed at the UAV edge during NTN backhaul, allowing local mission-critical media to remain at the edge while signaling goes through the non-terrestrial backhaul.

The remainder of this article is organized as follows. Section II reviews related work on mission-critical communications and enabling 5G, edge, aerial, and non-terrestrial technologies. Section III presents representative Public Protection and Disaster Relief (PPDR) scenarios, and derives the corresponding system requirements. Section IV introduces the proposed cross-layer MCX service and QoS model for dynamic network priority control. Section V describes the proposed architecture and its implementation across the MCX, IMS, 5G, edge, and non-terrestrial domains. Section VI presents the experimental methodology and evaluates service performance, dynamic priority, edge placement, and NTN backhaul. Section VII concludes the article and outlines future work. VOLUME ,

II. Background and Related Work

This section reviews the foundations and evolution of 3GPP MCX toward 5G-Advanced and 6G enabled public-safety communication systems. It first summarizes the main architectural principles of standardized mission-critical services, and reviews experimental MCX implementations addressing service performance, scalability, and network QoS. It then discusses enabling technologies for future mission-critical systems, including edge computing, network slicing, intelligent orchestration, UAVs, and terrestrial and non-terrestrial networks. A. 3GPP Mission-Critical Services and Implementations

A broader perspective on the role of 5G NR in public safety communications is provided in [7]. The authors identify requirements including ubiquitous connectivity, efficient group communication, extended coverage, accurate positioning, sidelink operation, support for isolated or deployable networks and prioritization of mission-critical traffic. Their work positions 5G NR as an important technological basis for complementing traditional LMRs and extending publicsafety communication toward broadband multimedia services. Research on mission-critical communications has progressively moved from standardized architectures and analytical studies toward experimental platforms capable of evaluating service behavior over broadband cellular networks. The authors in [11] extend the MCOP framework with a NextGeneration MCPTT architecture that exposes packetized voice streams directly to the application layer. This enables mechanisms such as store-and-replay, asynchronous Push-toTalk (PTT) concurrent conversations, application-level message prioritization, speech-to-text and text-to-speech processing, and device-to-device store and forward communication. Rather than focusing exclusively on conventional MCPTT access or mouth-to-ear latency, the work investigates how additional application-level control over voice streams can improve responder interaction. However, the approach remains primarily centered on MCPTT and application layer voice manipulation, without integrating the broader MCX service set or coordinating application-level operational state with 5G Core and RAN QoS mechanisms. The work in [12] investigates the use of Long-Term Evolution (LTE) and MCPTT as a converged communication infrastructure for airport operations, and proposes an interworking function between MCPTT and ED-137-based air-traffic-control radio systems. The proposed approach exploits MCPTT floor priority and Floor Revoke procedures to preserve the precedence of air-traffic-control communications, while LTE dedicated bearers and policy control mechanisms provide differentiated network treatment. The work illustrates the importance of coordinating service level communication priority with broadband network QoS. However, its scope is restricted to a specific aviation interworking scenario based on LTE, and it does not investigate the VOLUME ,

dynamic modification of 5G QoS-Flow priority in response to operational state transitions within an already established mission-critical session. Device-to-device (D2D) communication has also been investigated as a mechanism for maintaining mission-critical connectivity when conventional cellular infrastructure is unavailable. The work in [13] analyzes several networkcontrolled and device-controlled D2D configurations for MCPTT, and compares direct and cellular transmission under fading, path loss, and co-channel interference. The study is primarily focused on radio-link behavior rather than on the integration of off-network operation into a complete MCX architecture. The impact of the evolution from LTE toward 5G architectures on MCPTT performance is analyzed in [14]. The authors examine MCPTT signaling and media procedures, and decompose the contribution of different network segments to 3GPP-defined Key Performance Indicators (KPIs). LTE, Multi-access Edge Computing (MEC)-assisted LTE, and 5G Non-Standalone (NSA) architectures are compared, showing that edge placement can improve latency-sensitive performance, particularly mouth-to-ear delay. The results also indicate that satisfying strict MCPTT requirements remains challenging when the standardized service chain is considered end to end, reinforcing the importance of service placement and transport-network design. Capacity and scalability aspects are further investigated in [15], where the authors evaluate radio-access limitations for mission-critical group voice over LTE and 5G. Their analysis demonstrates that large group communication can remain constrained by RAN capacity and by protocol mechanisms involved in scheduling and identifying downlink traffic. This is particularly relevant in public-safety incidents where many responders may simultaneously participate in the same operational group. The study provides a more detailed capacity characterization than estimations based only on peak cell throughput, but does not investigate how group-control logic, media distribution, and network-resource management interact in an end-to-end MCX implementation. Several works move beyond analytical evaluation toward practical MCX experimentation. The proof-of-concept implementation in [16] integrates open-source components and an MCPTT Application Server to realize MCPTT services over a private 5G network. The platform is evaluated using 3GPP oriented metrics including MCPTT access time, endto-end access time, and mouth-to-ear latency, demonstrating both the feasibility and current performance limitations of open MCPTT implementations. However, the implementation primarily targets MCPTT, and its evaluation focuses on service functionality and end-to-end performance rather than on dynamically modifying the network treatment of an active communication in response to changes in MCX operational state. Open-source Voice Over New Radio (VoNR) prototypes have additionally demonstrated interoperable IMS-based

3

Oliveira et al.:

voice operation over open 5G SA networks using architectural components relevant to MCX deployments [17]. However, conventional conversational voice does not provide mission-critical group communication, floor control, service level priority, or emergency preemption procedures. Field experimentation with MCX is addressed in [18], where mission-critical services are evaluated in the context of the Future Railway Mobile Communication System (FRMCS). The authors report early field trials over 5G including MCPTT point-to-point and group calls, emergency calls, MCData/IPConn services, and QoS measurements under stationary and mobility conditions. The contribution demonstrates the importance of evaluating mission-critical communication under realistic operational conditions, including mobility, handover, and end-to-end service establishment. Importantly, the authors identify traffic steering, decentralized media-plane operation, and the analysis of QoS parameters and their dependencies across protocol layers as relevant directions for future investigation. These directions are closely related to the questions addressed in this work, particularly the dynamic association between mission-critical operational state, network treatment and the placement of media functions closer to the access network. Collectively, these works demonstrate substantial progress in MCX implementation, performance characterization, and the use of differentiated mobile-network QoS. However, experimental platforms remain predominantly focused on individual services, particularly MCPTT, and different levels of application–network integration should be distinguished. Configuring dedicated bearers or QoS profiles for missioncritical traffic establishes service-aware treatment, while policy-authorization mechanisms can additionally allow an application function to request network resources. Comparatively less attention has been given to dynamic transitions occurring within an already active MCX communication, where changes in application state must modify network priority without reconstructing the service session or its QoS Flow.

B. 5G-Advanced and 6G Enablers for Mission-Critical Communications

The evolution toward 5G-Advanced and 6G introduces additional mechanisms that may improve the flexibility, resilience, and autonomy of mission-critical communication systems. Relevant directions include advanced network slicing, edge and cloud-native service deployment, AI-assisted network management, integrated terrestrial and non-terrestrial connectivity, and increasingly dynamic placement of communication and computing resources [19], [20]. For deployable public-safety networks, edge computing and NTN integration are particularly relevant because they can reduce dependence on remote infrastructure while extending connectivity beyond the coverage of surviving terrestrial networks. 4

A network-slicing architecture for mission-critical communications is presented in [21]. The authors deploy a commercial mission-critical services product in a fully virtualized, multi-domain network-slicing environment compliant with ETSI NFV-MANO. The platform demonstrates automated deployment, slice isolation, differentiated performance, and management flexibility, illustrating how virtualization and network slicing can provide dedicated network resources for mission-critical services. The resulting differentiation is primarily established through slice-level resource allocation and isolation. In contrast, the problem addressed in this work concerns differentiation among individual mission-critical communications within the available network resources. Service-specific 5QI profiles define their baseline forwarding characteristics, while ARP and its preemption attributes are dynamically modified according to the operational state of an active MCX communication. The two approaches therefore operate at complementary levels, network slicing provides broader resource isolation, whereas QoS Flow-level policy control enables dynamic priority and preemption among concurrent communications. The management of mission-critical services in Beyond 5G (B5G) networks is explored in [22], where the authors describe an architectural framework for cloud-native missioncritical service deployment, network slicing, edge placement, service scaling, migration, and machine learning assisted overload prediction. Evaluated scenarios include scaling resources under increasing service demand, creating dedicated slices for mission-critical applications, and migrating edgehosted services following failures or QoS degradation. In contrast, the cross-layer mechanism considered in this work operates at the granularity of an individual active MCX communication where changes in operational state can trigger modifications to its network-level priority and preemption treatment without scaling or migrating the service instance or reconstructing the communication session. At the deployment level, this work additionally evaluates the placement of user plane and media functions according to the resulting end-to-end traffic path, particularly whether mission-critical media can remain at the tactical edge while signaling and centralized control traverse a constrained NTN backhaul. A related closed-loop approach is proposed in [23], where an MCX server, Network Data Analytics Function (NWDAF), telemetry module, and orchestrator cooperate to detect and predict overload conditions. MCX-level metrics such as the number of registered users and active private or group calls are used to support proactive scaling decisions. This demonstrates the value of incorporating mission-critical application state into network-management decisions. The resulting control loop, however, primarily operates at the service-orchestration level, adapting the resources assigned to service instances. The problem considered in this work operates at a different granularity, in our case, operational changes within an active MCX communication are used to

VOLUME ,

trigger policy modifications affecting the treatment of its associated 5G QoS Flow. Resilience evaluation is addressed in [24], where the authors propose a framework for measuring 5G resilience in the context of mission-critical communications. Their approach identifies 3GPP-oriented KPIs, relates communicationsystem degradation to operational mission impact, and evaluates resilience improvements enabled by multi-access mechanisms such as Access Traffic Steering, Switching, and Splitting (ATSSS) and Multipath TCP (MPTCP). The work is particularly relevant because it treats resilience as a dynamic process involving degradation, adaptation, and recovery rather than evaluating only steady-state throughput or latency. Such an approach is well suited to public-safety systems that must continue providing critical functions while network conditions evolve during an incident. Overall, these studies demonstrate that future missioncritical platforms will increasingly require the Application Server to operate in coordination with mechanisms across the underlying network infrastructure. Network slicing, edge placement, telemetry, analytics, orchestration, and resilience mechanisms provide a foundation for adapting both service and network behavior to changing operational and network conditions.

C. UAV, NTN, and tactical edge 3D Public-Safety Networks

Deployable communication systems represent an important direction for public-safety operations because emergency incidents frequently occur where fixed infrastructure is unavailable, damaged, congested, or insufficient. Portable radio systems, mobile base stations, aerial platforms, and nonterrestrial backhaul can be used to rapidly establish temporary coverage and restore communication capabilities. The overview in [8] examines temporary 5G networks designed to provide coverage, capacity, or redundancy when conventional infrastructure cannot satisfy operational requirements. The authors discuss deployable base stations, cellson-wheels, aerial platforms, alternative architectural configurations, coexistence and performance constraints. This work establishes the broader architectural motivation for portable private 5G systems in public-safety scenarios and highlights the need to jointly consider radio access, backhaul, mobility, and service availability. UAV-assisted communication has been widely investigated as an enabler for rapidly deployable B5G and 6G networks, with aerial platforms acting as base stations, relays, backhaul nodes, and mobile edge-computing platforms [25]– [27]. The literature demonstrates their potential for restoring or extending coverage while identifying persistent challenges involving interference, mobility, energy, resource allocation, and backhaul reliability. However, these studies predominantly address the communication and computing infrastructure independently of the mission-critical service layer. VOLUME ,

Khan et al. [28] consider a UAV-assisted architecture for maintaining public-safety video services under degraded terrestrial coverage. The results demonstrate the potential of aerial relays and adaptive radio-resource allocation for emergency video delivery. However, video is modeled as a generic streaming service rather than as a complete MCVideo session, and the work does not consider MCX group management, service level priority, signaling procedures, or coordination with other mission-critical services. It therefore demonstrates the value of aerial video connectivity without addressing how standardized mission-critical service semantics interact with the underlying deployable network. The integration of terrestrial and non-terrestrial networks for mission-critical services is studied in [29]. The authors analyze TN–NTN architectural alternatives for MCX support and discuss mechanisms for vertical mobility between terrestrial and satellite domains. Such integration is highly relevant in disasters, maritime operations, and remote areas where terrestrial infrastructure may be absent or severely impaired. At the same time, NTN connectivity introduces characteristics such as increased propagation delay, variable capacity, intermittent availability, and heterogeneous mobility behavior that may affect signaling, media transport, and service continuity. These constraints motivate architectures in which critical MCX functions can operate locally and adapt their behavior to the availability and quality of external backhaul. However, architectural support for TN–NTN integration does not by itself determine which MCX control and media functions should remain local, nor quantify the service level impact of moving latency-sensitive media traffic across the non-terrestrial segment. This placement question is therefore explicitly evaluated in this work. Moving from architectural studies toward experimental systems, Figaro et al. [30] demonstrate the feasibility of mounting a Low Earth Orbit (LEO) satellite terminal on a UAV to restore backhaul connectivity in PPDR scenarios. Their prototype provides local Wi-Fi access and experimentally characterizes the performance of the aerial satellite link, showing that UAV-supported NTN connectivity can provide practical emergency backhaul. The system, however, does not incorporate 5G access or standardized mission-critical services. Extending this concept toward a more complete mobilenetwork architecture, Correia et al. [31] previously developed within our research group a deployable PPDR platform combining multi-UAV networking, aerial 5G access, edge user plane processing, and LEO satellite backhaul. The experimental results demonstrated the feasibility of integrating these components within a rapidly deployable emergency communication infrastructure. The present work builds upon this infrastructure and extends it from connectivity and network-service provision toward an end-to-end missioncritical service platform. In particular, standardized MCPTT, MCVideo, and MCData functionality is integrated with IMS, application-driven 5G policy control, and edge media pro-

5

Oliveira et al.:

cessing. This enables the underlying aerial 5G–NTN infrastructure to be evaluated from the perspective of missioncritical service behavior, including dynamic priority transitions and the placement of MCX media functions relative to the non-terrestrial backhaul. These studies demonstrate how terrestrial, aerial, and satellite components can be combined into emerging 3D public-safety networks. However, most UAV-NTN oriented research treats emergency applications as generic traffic sources and does not exploit the operational semantics available within standardized MCX services. Consequently, limited experimental evidence exists on how MCX signaling, group media, floor control, and application priority behave when control and media functions are distributed between the edge and remote infrastructure connected through NTN. In particular, the trade-off between centralized media anchoring and local edge media processing remains important when the external backhaul exhibits increased latency or constrained capacity. The reviewed literature reveals complementary advances across mission-critical service implementation, programmable 5G networking, and deployable aerial and nonterrestrial infrastructures. However, these capabilities are generally investigated independently or in subsets. Table 1 compares representative works according to the capabilities most directly related to the research questions addressed in this paper. The comparison emphasizes multi-service MCX operation, application-aware network priority, dynamic interaction between MCX state and 5G policy control, evaluation under resource contention, edge function placement and nonterrestrial connectivity. III. Use Cases and System Requirements

The proposed platform targets public-safety operations over constrained, deployable 3D communication infrastructures spanning terrestrial, aerial, and non-terrestrial network segments. A disaster affects an area where terrestrial communication infrastructure is unavailable or partially degraded. A deployable private 5G network provides local access, while aerial nodes extend coverage and an NTN link provides external backhaul, as demonstrated in Figure 1. Responders require group voice, location, operational data, and selected video streams. A large-scale incident may involve multiple responder teams and operational groups sharing the same radio and network resources while background traffic is also present. Within an individual MCPTT group, application-level floor control determines which affiliated member is authorized to transmit and allows a higher-priority participant to preempt the current floor holder. However, this mechanism does not establish a resource priority hierarchy across independent communications belonging to different groups. Under network congestion, flows associated with different groups may therefore compete for the same constrained resources despite having different operational importance. Moreover, 6

NTN Node

5G 5G

5G Vehicle

FIGURE 1. Disaster affected area supported by a private 5G network with aerial nodes to extend coverage via NTN.

this importance may change dynamically, for example when a participant in one group enters an emergency state. This scenario motivates mapping MCX operational context to network-level QoS and ARP, allowing priority and preemption to be enforced across competing communications independently of their group membership. The two scenarios lead to a set of requirements that directly influence the proposed architecture. • R1: Integrated multi-service MCX operation. The platform shall support concurrent MCPTT, MCVideo, and MCData operation together with the common user, group, location, and emergency context required to coordinate these services. • R2: Cross-layer priority and resource control. The platform shall distinguish application-level priority from network-level resource priority. Within an MCPTT group, the configured user priority and dynamic emergency state shall determine floor access and applicationlevel preemption according to the service policy. At the network layer, the service type shall determine the baseline 5QI, while the configured user priority and emergency state shall determine the applicable ARP policy. This mapping shall enable differentiated admission, retention, and preemption treatment among competing QoS Flows, including communications associated with different groups. Priority changes occurring during an active communication shall be applicable without reconstructing the corresponding service session or changing its service-specific 5QI. • R3: Edge-deployment. Latency-sensitive and operationally critical MCX functions shall be deployable within the tactical edge network so that local communication can continue with reduced dependence on external backhaul. • R4: Heterogeneous 3D connectivity and backhaul. The platform shall support deployable private 5G operation across terrestrial, aerial, and non-terrestrial network segments, forming a heterogeneous 3D public-safety network, and accommodate variations in backhaul delay, capacity, and availability. VOLUME ,

TABLE 1. Comparison of representative approaches related to the proposed MCX platform.

Reference

MCPTT + MCVideo + MCData

Experimental 5G

MCX-aware network QoS

Dynamic MCX state → 5GC policy

◦

[12] ◦

[14]

5G priority / preemption under contention

MCX edge / function placement

◦

◦

✓

◦

[15] [16]

✓

◦

[18]

◦

✓

✓

[21]

◦

✓

✓

[22]

◦

◦

◦

◦

[23]

◦

◦

◦

◦

[29]

◦

◦

◦

◦ ◦

◦

◦

✓ ◦ ◦

✓ ✓

[30] ✓

[31] This work

NTN integration

✓

✓

✓ ✓

✓

✓

✓

✓

✓: implemented or explicitly evaluated as a central mechanism; ◦: architecturally considered or indirectly evaluated without end-to-end implementation of the stated capability; blank: not addressed.

Table 2 summarizes how the requirements are reflected in the implemented platform. IV. Cross-layer QPP Model for MCX

The proposed model distinguishes between the communication requirements of an MCX service and the operational priority associated with the users participating in it. The former determines the baseline network treatment required by the service type, whereas the latter is derived from application-level information, including the configured user priority and the current emergency state. Operational priority determines the relative importance of a communication and is used to provide preferential treatment when multiple users or traffic flows compete for constrained resources. In the 5G system, service differentiation is applied through QoS Flows identified by a QoS Flow Identifier (QFI). The 5QI associated with each flow defines its baseline forwarding characteristics. In the considered platform, mission-critical signaling, MCPTT, MCVideo, and MCData are therefore associated with service-specific 5QI profiles, as summarized in Table 3 according to the standardized 5QI characteristics defined in 3GPP TS 23.501. These profiles remain associated with the service independently of the operational priority of the user generating the traffic. Operational priority is maintained by the MCX service layer. Each authenticated user is assigned a configured priority as part of the user profile, which establishes the user’s baseline application-level priority. This priority may change dynamically according to the operational state, most notably when the user activates an emergency condition. The VOLUME ,

resulting operational priority can then be applied at different layers of the system: within an MCPTT group, it influences floor control decisions, while at the network layer, it can be translated into differentiated admission, retention, and preemption treatment. A. Application-Level and Network-Level Preemption

Priority is enforced at two complementary levels. At the application layer, MCPTT floor control resolves competition between participants affiliated with the same group. When multiple users request permission to transmit, their configured priority and emergency state can be used by the SIP AS to determine floor ownership. A higher-priority request may therefore revoke the floor from the current participant and assign it to another member of the same group. Application-level floor preemption does not, however, resolve competition between independent groups. Consider two simultaneously active groups GA and GB . Floor control can determine which participant transmits within GA and which participant transmits within GB , but it does not determine how the corresponding media flows compete for shared 5G resources. Consequently, an emergency communication in GA may still compete at the network layer with routine communication from GB . The proposed mechanism addresses this second level of contention by translating MCX operational priority into network-level ARP treatment. Whereas floor preemption establishes a priority hierarchy among participants of the same group, ARP provides admission, retention, and preemption differentiation among competing QoS Flows independently 7

Oliveira et al.:

TABLE 2. Traceability between system requirements, platform mechanisms, and experimental validation.

Req.

Requirement

Platform mechanism

Experimental validation

R1

Integrated multi-service MCX

Functional validation

R2

Cross-layer priority and resource control

MCPTT, MCVideo, and MCData services sharing common user, group, location, and emergency context Service type and operational priority translated through the SIP AS and N5 into 5QI and ARP treatment

R3

Edge-local deployment

R4

Heterogeneous backhaul

access

and

Edge-deployable UPF, RTPengine, and MCX components

5QI differentiation, ARP admission/preemption, dynamic emergency priority, and reaction time Central/edge placement

Private 5G access, aerial deployment, and NTN backhaul

Terrestrial/NTN comparison

TABLE 3. MCX-relevant standardized 5QI values.

Service

5QI

Type

Priority

PDB

MC delay-sensitive signaling MCPTT voice MCVideo MCData

69 65 67 70

Non-GBR GBR GBR Non-GBR

5 7 15 55

60 ms 75 ms 100 ms 200 ms

TABLE 4. Proposed Application and network priority mapping.

Operational class

App. PL

ARP PL

PC

PV

Emergency Incident commander Team leader Responder

1 2 3 4

1 3 5 7

Yes Yes No No

No Yes Yes Yes

Low priority

5

9

No

Yes

of their group membership. The two mechanisms, therefore, provide complementary priority enforcement at the application and network layers. B. Cross-Layer Priority Mapping

The proposed model distinguishes between a user’s configured priority profile and its dynamic operational state. The network-level priority policy is represented by the three components of ARP, Pi = (P Li , P Ci , P Vi ) ,

(1)

where P Li denotes the ARP priority level, P Ci the preemption capability, and P Vi the preemption vulnerability. For implementation, five application-level priority classes are defined, with lower values representing higher operational priority. Levels 2–5 establish the configured hierarchy between users during normal operation, and are used by the MCX service layer for application-level decisions, including floor arbitration. Level 1 represents the highest application priority and is reserved for the emergency state. Each application priority level is additionally mapped to a corresponding network-level ARP policy. The mapping used in the experimental platform is summarized in Table 4. We refer to the combination of service class and operational resource policy as Quality, Priority, and Pre-emption 8

(QPP). Quality is represented by the service-specific 5QI; Priority by the ARP level P Li ; and preemption by P Ci and P Vi . The service type determines the 5QI, while the configured user priority and emergency state select Pi . An emergency transition can therefore update Pi on an existing flow while preserving its 5QI and QFI. Application priority level 1 is reached dynamically rather than assigned as the user’s normal configured priority. When an authorized user activates emergency mode, both its application-level priority and the corresponding networklevel priority policy are temporarily elevated. For example, a responder operating with application priority level 4 and the baseline network policy Pibase = (7, No, Yes)

(2)

transitions to application priority level 1 and the emergency network policy Piemergency = (1, Yes, No).

(3)

At the application layer, this transition gives the emergency user preferential treatment during floor arbitration, and enables floor preemption according to the configured service policy. At the network layer, the corresponding ARP transition provides preferential admission and retention treatment, and enables preemption of vulnerable lower-priority resources. Importantly, the transition modifies operational priority rather than the service class; the service-specific 5QI remains unchanged. Once the emergency state is cleared, both the application priority and the network-level ARP policy return to the baseline values associated with the user’s configured priority. C. Dynamic QPP Enforcement

To enforce the priority transition described above on an already established communication, the updated operational state is propagated from the MCX user to the SIP AS. The Application Server then coordinates the transition at both the application and network layers. At the application layer, it updates the user state maintained by the Configuration Management Service (CMS), allowing the new operational priority to be considered in subsequent service level decisions, including MCPTT floor arbitration and preemption. At the network layer, the Application Server acts as a VOLUME ,

CMS MCX User

AS/AF

N5

PCF

SMF

RAN

FIGURE 2. Cross-layer propagation of an MCX operational priority transition to the application and network layers.

trusted Application Function (AF) and requests the corresponding policy modification from the PCF through N5. The same operational transition is therefore reflected in both the application-level priority used by the MCX service logic, and the network level priority applied to the associated QoS Flow. To support this behavior, the Open5GS PCF and SMF were extended to dynamically modify the ARP associated with an existing QoS Flow through its N5 AppSession. The initial implementation was contributed to the Open5GS project, and subsequently incorporated upstream through Pull Request #47941 . The resulting implementation maps the N5 resPrio attribute to an operator-configurable ARP priority level, and independently applies preemptCap and preemptVuln. ARP-only updates are propagated through the existing QoS Flow modification procedures while preserving the established QFI, 5QI, and negotiated bit-rate parameters. The resulting cross-layer control path is illustrated in Figure 2. Upon an operational priority transition, the Application Server updates the corresponding user state in the CMS while, in parallel, requesting the network-policy modification through N5. Emergency deactivation follows the same control path in the opposite policy direction. The CMS restores the configured application-level priority associated with the user profile, while the N5 policy update restores the corresponding baseline ARP configuration of the active QoS Flow. This coordinated mechanism ensures that a change in operational priority is consistently reflected at both layers. Within an MCPTT group, the updated application-level priority affects floor arbitration and enables application-level preemption according to the service policy. Across independently active communications, the corresponding ARP update establishes differentiated admission, retention, and network level preemption treatment. Communications using the same service class, including simultaneous MCPTT sessions belonging to different groups, can therefore retain the same standardized 5QI while receiving different treatment according to their current operational priority. An ARP update should be distinguished from a packet forwarding priority update. The proposed transition changes the priority and preemption attributes of a given QoS flow; however, it will not affect the 5QI, packet delay budget, guaranteed bit rate, or the application layer media policy for the flow. Acceptance of an N5 request by the PCF confirms that the request was accepted, but not that the 1 https://github.com/open5gs/open5gs/pull/4794

VOLUME ,

resulting policy has been enforced by the RAN. Confirmation at the RAN provides an additional control plane indication. However, neither indication by itself would prove preferential packet scheduling, lower media latency, or preemptive treatment of another flow. These are items that can be tested through experimentation when resources are being utilized with measurements taken on the impacted flows. Group floor arbitration currently utilizes a custom SIP based procedure as defined in Section V.D; its behavior should therefore be distinguished from standardized MCPTT floor control, and interoperability should not be assumed. V. Proposed Architecture

This section presents the proposed QPP-aware MCX architecture for a tactical edge 3D public-safety network. The architecture integrates mission-critical service logic, IMS signaling, media processing, 5G policy control, terrestrial and aerial access, tactical edge processing, and non-terrestrial backhaul. A. System Overview

The platform follows a layered architecture comprising an MCX User Equipment Layer, an MCX Service Layer, and a Network Infrastructure Layer. This separation decouples user applications from mission-critical service logic and from the underlying 5G transport network, allowing each layer to evolve independently while remaining coordinated through common service state, signaling, media control, and network-level QoS mechanisms. A central design principle is the separation between control and user plane functions. Core control functions, including the Access and Mobility Management Function (AMF), SMF, PCF, Unified Data Management (UDM), and Authentication Server Function (AUSF) can remain at a central or tactical command location, while the UPF is deployable close to the RAN. This enables local breakout toward edge-hosted service and media functions and reduces the dependence of mission-critical user traffic on constrained or intermittent backhaul. The distinction is particularly relevant when NTN provides connectivity between the tactical network and central service infrastructure, where control signaling may traverse the non-terrestrial link while locally anchored user plane traffic can remain within the incident network. The media plane is decoupled from the signaling and service-control functions. The SIP AS maintains session and group state, validates membership, manages floor control, and coordinates media session negotiation through Session Description Protocol (SDP), while RTPengine provides the dedicated Real-time Transport Protocol (RTP) media-relay function. This separation allows media processing to be deployed independently of the AS and positioned closer to the UPF and RAN when required. In tactical deployments, RTPengine can therefore be placed at the edge so that local mission-critical media remains within the incident 9

Oliveira et al.:

network even when signaling and central service functions are reached through the NTN backhaul. The current implementation uses unicast media distribution with persistent media legs between RTPengine and affiliated participants. This allows explicit per-participant media state to be maintained, while the forwarding graph is dynamically modified according to floor ownership, without reconstructing the established media sessions. The resulting architecture provides both media control and a controlled baseline for evaluating the scalability and resource cost of unicast group communication. The implemented platform integrates the Android responder application, dispatcher, common MCX services, Kamailio-based IMS, the custom SIP Application Server, RTPengine, and an Open5GS-based private 5G SA network. Its modular design supports different deployment configurations, including disaggregated UPF and media-relay placement, aerial gNB deployment and NTN backhaul. The complete logical architecture is shown in Figure 3.

FIGURE 4. Android MCX Application screens, from left to right: Private and group messages; map with the location of each group’s member, and their current state in the application; and push to talk feature inside a group.

SIP AS MCPTT Server

MCVideo Server

MCData Server IMS Core I-CSCF

5G Core HSS

P-CSCF

MC Service UE

PCF Siganiling user agent UPF

CSC CMS

Mongo

GMS

IDMF

S-CSCF

RTP engine

SMF

HTTP client

LMS

FIGURE 3. Logical and deployment architecture of the proposed QPP-aware MCX platform across the tactical edge 3D network.

FIGURE 5. Dispatcher MCX screen: manages the existent groups and members, their priorities and states, and the position of each member in the map.

B. MCX User Equipment Layer and Dispatcher

The MCX User Equipment Layer comprises the responder application, dispatcher interface, and specialized endpoints associated with UAVs and Unmanned Ground Vehicles (UGVs). These endpoints provide access to the missioncritical services and expose operational context to the service layer, including user identity, group affiliation, configured priority, emergency state, location, and connectivity status. The responder endpoint is an Android application supporting authentication, SIP registration, group affiliation, MCPTT communication, MCVideo, direct and group MCData, location sharing, and emergency activation. Voice and video are encoded using Opus and H.264, respectively, and transported using RTP/UDP. Signaling and media state are maintained separately, allowing service control and media transport to evolve independently. Offline map support further reduces dependence on external Internet connectivity during degraded-infrastructure operation. The dispatcher provides a browser-based operational interface for incident, user, and group management and for realtime situational awareness. It exposes responder and tacticalasset locations, connectivity and emergency states, missioncritical video streams, and operational group information. Current and historical location data can additionally be used to reconstruct mobility during experiments and post incident 10

analysis, while live video streams are exposed through a lowlatency WebRTC interface. UAVs and UGVs can participate as specialized MCX endpoints or gateways, publishing location, video, telemetry, and connectivity information and being associated with operational groups and incidents through the same common service functions used by human operated endpoints. This allows tactical assets to participate in the missioncritical service environment rather than being treated as independent external sensors. Their communications can consequently be associated with the same service-specific QoS and operational-priority mechanisms applied to other MCX endpoints. Figures 4 and 5 show the responder and dispatcher interfaces, respectively. C. MCX Common Services Core

The MCX Common Services Core (CSC) provides the shared service state required by the responder clients, dispatcher, and service-specific Application Server functions. It separates identity, operational profiles, group membership, and location information from the session-control logic implemented in the SIP AS. This follows the general 3GPP MCX principle of sharing common capabilities across VOLUME ,

D. IMS/SIP signaling and Application Server Design

Kamailio provides the IMS/SIP signaling plane, including Proxy Call Session Control Function (P-CSCF), Interrogating Call Session Control Function (I-CSCF), and Serving Call Session Control Function (S-CSCF) functions for User Equipment (UE) registration and session routing. Initial Filter Criteria route the relevant mission-critical signaling toward the custom SIP Application Server, which implements the service logic for MCPTT, MCVideo, and MCData. The SIP Application Server is organized into servicespecific MCPTT, MCVideo, and MCData modules that share VOLUME ,

Identity Management Server

HTTP

SIP AS

Configuration Management Server

HTTP

Group Management Server

HTTP

Location Management Server

Mongo Express

MC User NGINX

multiple mission-critical services while maintaining servicespecific signaling and media functions. The Identity Management Function (IDMF) provides authentication and maintains the association between authenticated users and their MCX identities. Authentication is kept separate from the operational profiles and priority state used by the mission-critical service logic. The CMS maintains the operational configuration and user state shared by the MCX services. It stores user profiles, roles, configured operational priority, status, and the network identifiers required to associate an MCX user with the corresponding 5G communication context. The SIP AS uses this information to support MCPTT floor arbitration and determine the network-priority policy requested through N5. During emergency activation and deactivation, the SIP AS updates the user state maintained by the CMS, allowing the operational priority changes described in Section IV to inform both application-level decisions and network-policy requests. The Group Management Service (GMS) maintains operational groups and their membership, supporting both predefined and dynamically created groups. Group information is exposed to clients and service functions through backend interfaces, including an XCAP-compatible group representation. Before establishing a group communication, the SIP AS queries the GMS to validate the requested group and the membership of the initiating user, ensuring that session and floor control operations are applied only to affiliated participants. The Location Management Server (LMS) maintains current and historical location information for responders and tactical assets. Authenticated location reports are distributed according to group membership and made available to the responder and dispatcher interfaces, providing a common location context for situational awareness and mobility analysis. Together, these functions provide the shared identity, operational, group, and location context used by the servicespecific MCX functions, while session control, floor arbitration, and network-policy requests remain the responsibility of the SIP AS. Figure 6 illustrates the interaction between the MCX endpoints, the common service functions, and the SIP AS.

HTTP/WSS-MQTT

Dispatcher Web

HTTP Rest

Responder App

HTTP

HTTP

FIGURE 6. Common Services Core interaction with MCX users, backend services, and the SIP Application Server.

the common service functions described in Section C while maintaining independent service state and signaling logic. The MCPTT module manages group affiliation, floor control, priority, and group-media distribution; the MCVideo module manages publishers, listeners, and video forwarding; and the MCData module validates, persists, and distributes direct and group messages.

1) MCPTT Group Sessions and Floor Control

Each MCPTT group retains its affiliated members, a current floor holder, and a shared RTPengine call with one persistent bidirectional media participant and one N5 AppSession per member. Algorithm 1 describes affiliation through a SIP INVITE, and floor control through in-dialog floor messages. The CMS resolves user identity and supplies floor priorities, while the GMS verifies group membership. Priority comparisons use a lower numeric value for a higher priority. A brief description of the algorithm’s operation process is given below: • Lines 1–9 (affiliation). The server validates identity and membership, publishes a stable bidirectional RTPengine participant, and requires an initial downlink AppSession before accepting the INVITE. A late member is connected to the current talker without acquiring the floor. • Lines 10–16 (arbitration). A request during a floor change receives 486 Busy Here. When another member is talking, the server compares their CMS priorities. The requester preempts only if its priority is higher, represented by a lower numeric value; otherwise, the server replies 486 Busy Here. • Lines 17–29 (media switch). Under the group lock, the server rechecks floor ownership. If the previous talker has left, the floor can be granted directly; if another talker has taken over, the request is rejected. 11

Oliveira et al.:

For preemption, the server starts an asynchronous floor-revoked notification to the former talker, requests a downlink N5 update, and attempts to block its media. It then assigns the requester, requests an uplink update, unblocks its media, and connects it to each listener in turn. A failed RTPengine operation is logged and does not stop the remaining attempts. • Lines 30–35 (release). The request is acknowledged before the background task requests the downlink policy update, attempts to block the current talker, and clears the floor. Directional N5 PATCH completion and revocation delivery do not gate a floor reply. For a grant or preemption, 200 OK follows the attempted RTPengine operations; for release, it precedes them. The established participants and AppSessions are reused without SIP/SDP renegotiation. A SIP response alone confirms neither media reception nor downstream QoS enforcement.

2) MCVideo and MCData Services

The MCVideo module follows a publisher/listener model in which each stream is associated with a publishing MCX user and may be consumed by multiple authorized listeners. The Application Server validates the publisher, maintains the stream state, and coordinates RTPengine operations to distribute the media toward subscribed participants. An additional media leg can be created toward MediaMTX to expose selected streams as low-latency WebRTC feeds to the dispatcher. The core signaling logic governing this lifecycle is detailed in Algorithm 2. The first INVITE targeting a stream key instantiates the publisher and secures the necessary uplink network resources. Subsequent offerless INVITE requests initialize pending listeners, whose media state and downlink QoS are strictly established upon receiving the ACK, remaining stable without subsequent dialog renegotiation. Finally, the BYE method dictates the teardown scope: a listener leaving only releases its individual subscription, whereas a BYE from the publisher systematically dismantles the entire stream, gracefully terminating the dialogs of all active listeners. A brief description of the algorithm’s operation process is given below: • Lines 1–11 (stream initiation). When an INVITE targets a non-existent stream, the server verifies the publisher’s identity through the CMS. Upon authorization, it publishes the user at RTPengine, instantiates the stream, and replies 200 OK with the SDP answer. It then schedules an uplink N5 POST to secure network resources and optionally attaches a MediaMTX bridge for external access. • Lines 12–18 (listener subscription). If the stream is already active, the request is handled as a subscription. 12

Algorithm 1 MCPTT group affiliation and floor control. 1 On G ROUP I NVITE(u, g) 2 Verify u via CMS and membership via GMS 3 4 5 6 7

if denied then reject INVITE; return Publish u at RTPengine as bidirectional participant m if publish fails then reject; return if initial DL AppSession POST fails then Delete m; reject INVITE with 503; return

8 9

Reply 200 OK with SDP answer if talker active then queue connect to m

10 On F LOOR R EQUEST(u, g) 11 if u not affiliated then reply 481; return 12 if floor lock held then reply 486; return 13 14 15 16 17 18

t ← current talker if t ̸= ∅ and t ̸= u then Obtain pu , pt from CMS if pu ≥ pt then reply 486; return with group floor lock: h ← current talker

19 20 21 22 23 24

if h = u then reply 200; return if another talker replaced t then reply 486; return if h = t and t ̸= ∅ then Start asynchronous floor-revoked to t Schedule N5 PATCH: t → DL Attempt RTPengine block for t; clear floor

25 26 27 28 29

Set talker to u; schedule N5 PATCH: u → UL Attempt RTPengine unblock for u for each other affiliated member v: Attempt RTPengine connect from u to v Reply 200 OK

30 On F LOOR R ELEASE(u, g) 31 if u not talker then reply 200; return 32 Reply 200 OK 33 In background, under the group floor lock: 34 Schedule N5 PATCH: current talker → DL 35 Attempt RTPengine block; clear the floor

The server rejects INVITEs containing an SDP offer, validates the user’s identity, requests an RTPengine subscription, and registers the user as pending. It then replies 200 OK containing an SDP offer. • Lines 19–23 (listener activation). When a pending listener replies with an ACK containing the SDP answer, the server finalizes the RTPengine media subscription, schedules a downlink N5 POST to establish the listener’s QoS, and marks the user as an active listener. • Lines 24–38 (stream and subscription teardown). A BYE request initiates teardown procedures and is immediately acknowledged with a 200 OK. If the request comes from a listener, the server simply unsubscribes the user from RTPengine, schedules an N5 DELETE, and removes them from the stream. VOLUME ,

However, if the BYE comes from the publisher, the server systematically dismantles the entire stream: it disconnects the MediaMTX bridge, terminates all active listener dialogs (including their RTPengine and N5 sessions), removes the publisher’s resources, and deletes the stream instance.

Algorithm 2 MCVideo stream initiation and subscription. 1: On V IDEO I NVITE(u, k) 2: if stream k does not exist then if u ̸= k then reject 403; return Verify u via CMS if denied then reject I NVITE; return Publish u at RTPengine for stream k if publish fails then reject 503; return

3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:

▷ u invites stream k ▷ Publisher workflow

Create VideoStream k with u as publisher Reply 200 OK with SDP answer Schedule N5 POST: u → UL if MediaMTX enabled then attach bridge to stream k else ▷ Listener workflow if I NVITE has SDP then reject 400; return Verify u via CMS if denied then reject I NVITE; return Request RTPengine subscription for u to stream k Register u as pending listener Reply 200 OK with offer SDP

14: 15: 16: 17: 18:

19: On ACK(u, k) 20: if u is pending listener then 21: Answer RTPengine subscription with u’s answer SDP 22: Schedule N5 POST: k → DL for u 23: Mark u as active listener 24: On B YE(u, k) 25: Reply 200 OK 26: if u is publisher then 27: Detach MediaMTX bridge from stream k 28: for each listener v in stream k: Unsubscribe v at RTPengine Send B YE to v Schedule N5 DELETE for v Delete publisher session at RTPengine Schedule N5 DELETE for u Delete VideoStream k

29: 30: 31: 32: 33: 34: 35: 36: 37: 38:

else if u is listener then Unsubscribe u at RTPengine Schedule N5 DELETE for u Remove u from stream k

The MCData module supports direct and group messaging. The Application Server resolves the sender, validates group membership when required, persists the message, and distributes it to the intended recipient or affiliated group members. Unlike the media-oriented services, MCData does VOLUME ,

not maintain RTP state, allowing data-message handling to remain independent of the media relay.

3) Cross-Layer Service Control

The Application Server also acts as the service level decision point for cross-layer network control. The service type determines the baseline 5QI associated with the communication, while the configured user priority and dynamic emergency state determine the applicable network-priority policy. When an operational transition requires a change in network treatment, the Application Server acts as a trusted AF and requests the corresponding policy modification from the PCF through N5. This allows the ARP priority level, preemption capability, and preemption vulnerability of an active communication to be modified while preserving its service-specific 5QI. This network-level mechanism complements, rather than replaces, the floor control policy enforced by the MCPTT module. Floor preemption determines which participant may transmit within a group, whereas ARP-based control differentiates admission, retention, and preemption among competing QoS Flows, including communications associated with different operational groups. VI. Experimental Validation and Results

This section experimentally evaluates the proposed MCX platform from both functional and performance perspectives. The evaluation progresses from baseline validation of the individual MCX services to increasingly demanding scenarios involving concurrent service operation, resource contention, dynamic mission-critical priority and non-terrestrial backhaul. Particular attention is given to the impact of user plane and media-function placement when the tactical network is connected to the central infrastructure through NTN. Measurements are collected across the application, signaling, media, 5G Core, and radio domains to characterize both endto-end service performance and the contribution of individual system components. A. Testbed Description

The experimental platform consists of a tactical radio node and a central service node whose interconnection and function placement are varied according to the evaluated scenario. The tactical node is implemented using a Mini-PC running the Amarisoft 5G gNB software and connected to a USRP B210 software-defined radio. The radio operates in NR band n77 with a 40-MHz channel bandwidth. This platform is designed for integration on the aerial node used in the deployable configuration. The central node is implemented on a Minisforum platform and hosts the Open5GS 5G Core control functions, the Kamailio-based IMS, the MCX Common Services Core, and the custom SIP Application Server. Depending on the evaluated deployment, the UPF and RTPengine media relay 13

Oliveira et al.:

are either placed with these central functions or moved to the tactical node. This allows the user plane and media path to be modified without changing the mission-critical servicecontrol functions. Up to 64 5G UEs are simulated using an Amarisoft UE SimBox Series to provide a scalable and repeatable multiuser environment. The SimBox simulates the UE protocol stack and communicates with the gNB over the physical NR radio interface, such that the resulting traffic traverses the same RAN and 5G Core paths as that of a physical 5G terminal. For the scalability experiments, each simulated UE executes the same MCX signaling and media procedures generated by the responder application, including SIP registration and session control, floor control exchanges, RTP media transmission and reception, and MCData transactions, but without the graphical Android user interface. Consequently, the experiments preserve the application-level communication flows and network interactions of the implemented MCX client, while allowing up to 64 concurrent UEs to be exercised under controlled and repeatable conditions. The same UE environment and workload generation are used across the different deployment configurations to enable consistent comparison of signaling, media, radio, and network performance. B. Deployment Configurations

Three deployment configurations are considered to progressively introduce non-terrestrial backhaul and edge-local user plane and media processing. The mission-critical service logic remains hosted on the central node in all three configurations, while the location of the UPF and RTPengine is varied to determine which portions of the user and media paths must go through the external backhaul. The three defined deployment scenarios can be seen in Table 5. The first configuration provides the reference condition for the subsequent experiments, depicted as S1 in Figure 7. The Amarisoft gNB running on the tactical node is directly connected through Ethernet to the central node. The 5G Core, UPF, IMS, Common Services Core, SIP Application Server, and RTPengine are placed on the central command center. Consequently, both signaling and user plane traffic go through the local Ethernet connection without an NTN segment. This configuration is used for baseline functional and performance validation of MCPTT, MCVideo, and MCData, as well as for the initial evaluation of signaling latency, media performance, scalability, concurrent-service operation and cross-layer priority mechanisms.

The second configuration introduces the NTN backhaul while preserving the centralized placement of the network and service functions, depicted as S2 in Figure 8. The tactical gNB is connected through Starlink to the central node, where the UPF, RTPengine, 5G Core control functions, IMS, Common Services Core, and SIP Application Server remain deployed. In this configuration, both mission-critical signaling and user plane traffic depend on the non-terrestrial backhaul. In particular, media packets must traverse the Starlink path between the gNB and the centrally located UPF, and media relay before being forwarded toward their destination. This configuration, therefore, characterizes the performance penalty introduced when the complete missioncritical traffic path remains centrally anchored across the external backhaul.

FIGURE 8. Deployment Configuration S2.

The third configuration moves the UPF and RTPengine to the tactical node alongside the gNB, while the 5G Core control functions, IMS, Common Services Core, and SIP Application Server remain on the central node and are reached through Starlink, depicted as S3 in Figure 9. The tactical node, therefore, provides local user plane anchoring and media relay while retaining centralized session and service control. This placement separates the dependency of signaling from that of mission-critical media. Session establishment, service authorization, group management, and policy control signaling may traverse the NTN backhaul, whereas media exchanged between locally connected participants can remain within the tactical network after the required state has been established. Comparing this configuration with S2 quantifies the effect of moving latencysensitive user plane and media functions closer to the RAN, including its impact on MCPTT media delay, packet loss, jitter, MCVideo performance, and backhaul utilization.

Command Center 5G Core RTPEngine

UAV Ethernet

gNB

SIP AS CSC

FIGURE 7. Deployment Configuration S1.

14

FIGURE 9. Deployment Configuration S3.

5G OTA

Amarisoft UE Simbox

A photograph of the aerial platform and its integrated radio, computing, and non-terrestrial communication components is shown in Figure 10. VOLUME ,

TABLE 5. Backhaul and function-placement scenarios used in the MCPTT

TABLE 6. Operational priority profiles and associated network policies

evaluation.

(Table 4). Lower application and ARP levels indicate higher priority; Preemption Capability (PC) and Pre-emption Vulnerability (PV) denote pre-

Scenario

Backhaul

UPF

RTPengine

S1 S2

Terrestrial Starlink

Command Center Command Center

Command Center Command Center

S3

Starlink

Tactical edge (UAV)

Tactical edge (UAV)

emption capability and preemption vulnerability.

Profile Operational class U E4 U E3 U E2 U E1 U E0

Emergency Incident commander Team leader Responder Low priority

App. PL ARP PL PC PV 1 2 3 4 5

1 3 5 7 9

Yes No Yes Yes No Yes No Yes No Yes

events. Uplink UDP throughput was measured on N3 and classified as 5QI 65 or 5QI 9 using the corresponding QFI mappings. The resulting evidence pertains to network policy control; it does not establish the behavior of the complete MCX emergency activation path or application-level media delivery.

1) Experimental Sequence

FIGURE 10. Drone equipped with USRP B210 and a Mini PC running Amarisoft gNB, UPF and RTPengine.

C. QPP Enforcement under Mission-Critical Resource Contention

Three controlled experiments evaluated the network effect of operational priority changes under competing QoS requests: static normal priority, permanent emergency priority, and a normal → emergency → normal transition. Four simulated UEs generated uplink UDP traffic through the radio access network. Each UE offered 15 Mbps using iperf, and requested a dedicated 5QI 65 QoS flow with uplink Guaranteed Bit Rate (GBR)/Maximum Bit Rate (MBR), both set to 20 Mbps. The traffic rate and requested bit rates remained unchanged in all experiments. Table 6 defines five operational profiles. In the static experiments, U E1 – U E3 retain their respective profiles. The dynamic experiment instead uses U E1 and two distinct senders with the U E3 profile, denoted U E3−A and U E3−B . In all experiments, sender U E4 uses the U E0 low-priority profile in its normal state and the U E4 emergency profile when elevated. Application priority determines the operational class used by the service layer, including floor arbitration. At the network layer, the corresponding ARP level and PC/PV flags govern admission and preemption. A lower ARP level gives a request higher priority, but preempting an existing vulnerable flow also requires the new request to have PC enabled. To isolate network policy control from MCX service signaling, a dedicated test harness submitted N5 requests directly to the PCF. NG Application Protocol (NGAP) records were examined for dedicated-flow admission and preemption VOLUME ,

All experiments used competitor requests scheduled at 5, 45, and 90 s after sender U E4 started at 0 s. The static experiments used U E1 , U E2 , and U E3 , respectively. The dynamic experiment used U E1 , U E3−A , and U E3−B at the same times. The latter two are separate attached UEs with identical U E3 policies (ARP level 3, PC enabled, PV enabled), offered rates, and requested bit rates. The U E2 operational profile is not used in the dynamic run. This sequence tests a preemption-capable contender during emergency protection and another after normal priority is restored. Each initial policy request was submitted through an N5 POST, and session cleanup was scheduled at 120 s. These times are relative to the scenario start; the throughput plots use the first received traffic as their origin. Sender U E4 ’s assigned profile distinguished the experiments. It retained the U E0 profile (ARP level 9, PC disabled, PV enabled) in the static-normal experiment, and the U E4 profile (ARP level 1, PC enabled, PV disabled) in the permanent emergency experiment. In the dynamic experiment, U E4 changed between these two profiles during the run.

2) Static Normal Priority

U E4 ’s initial 20 Mbps GBR request was admitted with the U E0 profile. When U E1 and U E2 joined at 5 and 45 s, their N5 POSTs were accepted by the PCF, but the gNB rejected their dedicated flow additions with the NGAP cause radio-resources-not-available. The refusals therefore occurred during radio admission, after policy acceptance. Both contenders requested the same 20 Mbps GBR as U E4 and had PC disabled. Although their ARP levels ranked above U E4 ’s, neither could displace its already admitted, vulnerable flow to obtain resources. U E1 and U E2 continued transmitting over 5QI 9, as shown in Figure 11. 15

Oliveira et al.:

Their dedicated-flow refusals therefore concerned admission of the requested GBR resources, while their existing besteffort connectivity remained available. U E3 introduced a different admission outcome at 90 s. Its profile combined a higher ARP priority than U E4 ’s normal profile with PC enabled, allowing it to preempt U E4 ’s vulnerable flow. NGAP records explicitly identify U E4 ’s release as preemption, and the figure shows UE4’s dedicatedflow traffic ceasing as UE3 begins transmitting over its newly admitted 5QI 65 flow. This case illustrates why a higher priority level alone was insufficient for U E1 and U E2 : U E3 additionally had permission to preempt an eligible flow.

FIGURE 11. Static normal priority. U E1 and U E2 transmit over 5QI 9; U E3 obtains a 5QI 65 flow at approximately 90 s and preempts U E4 ’s 5QI 65 flow. Each panel identifies a traffic sender; line colors distinguish 5QI 9 from 5QI 65. Vertical dashed markers indicate the first received traffic for each sender. Time is measured from the first received traffic in the experiment.

U E4 ’s iperf sender remained active after preemption, but no positive 5QI 9 throughput was observed for U E4 . Continuity over the default flow was therefore not demonstrated2 .

3) Permanent Emergency Priority

With the U E4 emergency profile applied from the start, U E4 retained its dedicated flow throughout the experiment (Figure 12). The PCF accepted all four initial N5 requests, but the gNB rejected the dedicated-flow additions for U E1 , U E2 , and U E3 with radio-resources-not-available. 2 In this deployment, the Open5GS AMF logged ”Not implemented” for

the NGAP PDUSessionResourceNotify procedure used by the gNB to report the released QFI. Subsequent signaling attempted to re-establish that QFI and encountered a PDU-session resource setup failure. These observations limit conclusions about traffic continuity after RAN-initiated preemption.

16

As in the normal case, U E1 and U E2 could not preempt. U E3 had PC enabled, but U E4 now had both a higher ARP priority and PV disabled. Consequently, U E3 could not obtain its requested 20 Mbps GBR by replacing U E4 ’s flow, and no preemption was recorded. The competing UEs continued transmitting over 5QI 9. Compared with the normal case, the decisive difference occurs at U E3 ’s arrival: the same preemption-capable contender is unable to displace U E4 under the emergency profile. The observed outcome is retention of the established dedicated flow despite subsequent competing GBR requests.

FIGURE 12. Permanent emergency priority. U E4 retains its 5QI 65 flow after all competitor arrivals; U E1 –U E3 transmit over 5QI 9. Panels, line colors, and vertical dashed markers have the same meanings as in Figure 11.

4) Dynamic Emergency Priority

U E4 started with the U E0 profile; an N5 PATCH applied the emergency profile at 30 s, and a second PATCH restored normal priority at 75 s. Both updates modified the existing QoS flow while preserving 5QI 65 and the requested uplink GBR/MBR of 20/20 Mbps. U E4 ’s initial dedicated flow was admitted, while U E1 ’s request was rejected by the gNB for unavailable radio resources. At 45 s, U E3−A requested a dedicated flow with the U E3 profile. Although this profile had PC enabled, U E4 ’s emergency profile had higher priority and PV disabled. The gNB rejected the request with radio-resources-not-available, and U E3−A continued transmitting over 5QI 9 while U E4 retained its 5QI 65 flow. Restoring normal priority at 75 s made U E4 ’s flow vulnerable to preemption but did not release it. At 90 s, U E3−B requested a dedicated flow with the same profile as VOLUME ,

5QI 9

UE1 30 20

5QI 65

First RX

PATCH

POST · ARP 7 PC No · PV Yes GBR/MBR 20/20 Mbps

10 0

Measured RX throughput (Mbps)

30

UE3-A POST · ARP 3 PC Yes · PV Yes GBR/MBR 20/20 Mbps

20 10 0 30

UE3-B POST · ARP 3 PC Yes · PV Yes GBR/MBR 20/20 Mbps

20 10 0 30

UE4 POST · ARP 9 PC No · PV Yes

20 GBR/MBR 20/20 Mbps

PATCH · ARP 1 PC Yes · PV No GBR/MBR 20/20 Mbps

PATCH · ARP 9 PC No · PV Yes GBR/MBR 20/20 Mbps

10 00

20

40

60 80 Time since first RX traffic (s)

100

120

FIGURE 13. Dynamic emergency priority. U E3−A and U E3−B use the same U E3 profile. U E3−A remains on 5QI 9 while U E4 is protected; U E3−B obtains 5QI 65 and preempts U E4 after normal priority is restored.

U E3−A . Its 5QI 65 flow was admitted and preempted U E4 ’s flow, as confirmed by NGAP records and the traffic traces in Fig. 13. U E3−A remained on 5QI 9. The two requests therefore produced different admission outcomes before and after emergency protection was removed. Together, these runs show how the priority profiles affect admission and retention under competing GBR requests. U E3 preempted U E4 ’s normal flow in the static experiment, but could not displace its permanent emergency flow. The dynamic experiment showed the same distinction within one run: U E3−A was refused during emergency priority, whereas U E3−B was admitted after normal priority was restored. Each configuration was executed once, and ARP level, PC, and PV changed together; the experiments do not isolate each attribute’s contribution or establish admission probabilities.

All 1,000 operations per scenario matched successful NGAP responses, and PATCHes preserved QFI and 5QI. For initial flow setup, emergency request, and emergency release, respectively, S1 median latencies were 80.5, 61.7, and 61.8 ms, with P95 values of 98.8, 83.3, and 83.6 ms (Figure 14). In S3, the medians increased to 229.0, 182.6, and 181.7 ms, and P95 to 267.8, 211.7, and 212.6 ms (Figure 15). Initial flow setup took longer than updates to an existing flow, while emergency-request and emergencyrelease distributions nearly overlapped. Per-operation clockoffset calibration bounded the maximum retained interval width to 0.72 ms in S1 and 1.57 ms in S3. The higher S3 latencies are consistent with service and Core–gNB signaling continuing across Starlink despite edgelocal UPF and media functions; the comparison does not isolate backhaul delay from processing. All observations contribute to the reported statistics. These measurements quantify signaling completion, excluding registration, initial PDU-session establishment, and media delivery; they do not identify the precise instant of scheduler enforcement.

FIGURE 14. S1: UE SIP submission to the matching successful NGAP response. Initial flow setup is affiliation (N5 POST, n = 500); the plotted emergency request and release are floor request and release with prepared CMS priority (N5 PATCH, n = 250 each).

D. MCPTT Performance and Latency Analysis 5) UE-to-RAN QoS signaling Latency

This experiment measures the interval from UE SIP socket submission, through IMS, SIP AS, and N5/Core signaling, to the matching successful NGAP Protocol Data Unit (PDU) Session Resource Modify Response captured at the Core host. S1 and S3 each used one UE without competing flows or media traffic. In each scenario, 500 affiliation requests generated 500 N5 POSTs. A separate series of 250 floor-request/floor-release pairs generated 250 emergencyrequest PATCHes and 250 emergency-release PATCHes on an established QFI, yielding 1,000 measured operations per scenario. The emergency transitions were exercised through SIP floor operations with CMS priority prepared before timing; these PATCHes also changed direction and bit rates. VOLUME ,

This subsection characterizes the performance of the implemented MCPTT service, with particular emphasis on floor control latency, access time, and media transport. The measurements distinguish application-level floor decisions from the subsequent media path response, allowing the contribution of signaling and media transport to be evaluated separately across the considered deployment configurations.

1) Floor Control Performance

In half-duplex MCPTT, floor control determines which group member is authorized to transmit at a given time. The experiment evaluates floor acquisition, refusal, release, reacquisition and priority preemption. In S3, five affiliated 17

Oliveira et al.:

FIGURE 15. S3: the same UE-to-NGAP signaling interval and operations as in Figure 14. The displayed POST CDF omits four observations above 350 ms and is normalized over the remaining 496; the full-sample POST maximum is 1248.41 ms. All 500 POST observations are retained in the reported percentiles.

TABLE 7. Floor control latency by placement scenario. Values are in milliseconds. S1 Measurement

P50

P95

Initial acquisition Equal-priority refusal Reacquisition Priority preemption Revoke notification First new-talker RTP Lower-priority refusal Floor release

53.36 53.70 44.58 48.54 35.67 43.24 46.14 46.75 44.64 44.75 79.65 85.08 44.58 44.68 35.22 38.41

S2 P50

S3 P95

93.37 95.24 95.58 102.79 91.35 94.93 99.55 104.54 95.65 104.08 163.08 194.39 98.10 100.58 77.67 101.44

P50

P95

86.89 91.83 89.64 99.57 88.50 92.43 93.90 108.07 90.12 100.53 106.95 126.32 81.65 88.24 84.55 92.39

UEs participated: four used the U E3 (Incident Commander) profile, with application priority level 2, and one used the U E2 (Team Leader) profile, with application priority level 3. Lower values indicate higher priority. Floor control response latency is measured from the moment a UE sends a floor request until it receives the final SIP response. One participant with the U E3 profile is used to measure initial acquisition and reacquisition. Equal-priority refusal is measured when another U E3 profile participant requests the floor while the first holds it. For preemption, a higher-priority U E3 profile participant requests the floor while the U E2 profile participant holds it. A subsequent request from the U E2 profile participant is refused. Release latency is measured for both profiles. Two additional measurements begin with the U E3 profile participant’s preemption request. Revoke notification latency ends when the U E2 profile participant receives the floor revoked notification. First new-talker RTP latency ends when a listening U E3 profile participant receives the first RTP packet from the new talker. These measurements distinguish floor response, notification delivery, and media arrival. Table 7 reports the P50 and P95 values for the three placement scenarios. 18

FIGURE 16. Median UE-observed floor control latency by operation and placement scenario.

The S3 run completed all five rounds, and all 1,000 floor requests received their expected responses. No timeout or missing reply was observed. Figure 16 compares the median latencies. Relative to the Ethernet baseline S1, S2 increased every UE observed metric. In S2, the SIP Application Server, UPF, and RTPengine remained at the command center, so floor control signaling and media depended on the Starlink backhaul. The largest increase was for first new-talker RTP: 83.43 ms at P50 and 109.31 ms at P95 . In S3, the SIP response medians remained broadly similar to those in S2, consistent with the SIP Application Server remaining at the command center and being reached over Starlink in both scenarios. Five of the six medians were lower in S3, while the release median was 6.88 ms higher; the revoke notification median was 5.53 ms lower. First new-talker RTP fell from 163.08 to 106.95 ms at P50 and from 194.39 to 126.32 ms at P95 , reductions of 56.13 and 68.07 ms, respectively. This improvement is consistent with placing the UPF and RTPengine on the UAV, allowing media to be relayed locally instead of travelling to the command center and back. The interval still includes floor control signaling to the centralized SIP Application Server, which helps explain why S3 remains slower than S1. VOLUME ,

TABLE 9. MCPTT audio transport results pooled across listeners and

TABLE 8. Protocol-level MCPTT access time by placement scenario.

bursts.

Scenario S1 S2 S3

P50

P95

P99

Max

47.84 90.78 149.25

67.16 114.24 184.52

72.53 128.71 212.71

148.73 355.98 341.63

FIGURE 17. Protocol-level MCPTT access time by placement scenario, showing the median and 95th percentile.

2) MCPTT Access Time

3GPP defines MCPTT Access Time (KPI 1) as the interval between a user’s request to speak and the indication that transmission may begin. For an already established call, 3GPP TS 22.179 requires this interval to remain below 300 ms for 95% of MCPTT PTT requests [32]. In our evaluation, this protocol level interval was measured from transmission of the floor-request to reception of the final SIP response by 64 pre-affiliated simulated UEs following a relay pattern. Table 8 reports the resulting P50 , P95 , P99 , and maximum access times for the three deployment scenarios. No timeout or worker failure was observed in any of the three scenarios. Relative to the terrestrial baseline S1, introducing the Starlink backhaul with centralized service, user plane, and media functions in S2 increased the median access time from 47.84 ms to 90.78 ms and the P95 from 67.16 ms to 114.24 ms, corresponding to increases of 42.94 ms and 47.08 ms respectively. In S3, where the UPF and RTPengine were moved to the tactical edge while the SIP AS and other service control functions remained centralized, the access time P50 and P95 further increased to 149.25 ms and 184.52 ms, respectively. Despite these differences, the measured P95 remained below the 300 ms KPI1 reference in all three scenarios, as illustrated in Figure 17. Isolated observations above 300 ms occurred in S2 and S3, producing maxima of 355.98 ms and 341.63 ms respectively.

3) Audio Transport Performance

MCPTT audio transport was evaluated using 64 affiliated UEs, with one talker transmitting repeated five second RTP VOLUME ,

Scenario

P50

P95

P99

Loss

S1 S2

39.22 86.00

60.64 117.53

69.44 142.44

0.73% 9.78%

S3

39.19

57.50

62.62

0.36%

audio bursts to 63 listeners at 20 ms packet intervals. Transport delay was measured from submission of each packet at the sender socket to its reception callback at the listener, thereby capturing the communication path through the 5G network and media relay. Table 9 reports the resulting delay percentiles and packet loss pooled across listeners and transmitted bursts. All workers completed successfully, and every burst/listener measurement was valid in S1, S2, and S3. The delay percentiles are calculated from the raw received packet observations, whereas packet loss is calculated relative to the total number of packets expected across all listeners. Centralized media anchoring over the Starlink backhaul in S2 substantially degraded both metrics relative to the terrestrial baseline S1: the median transport delay increased from 39.22 ms to 86 ms, the P95 increased from 60.64 ms to 117.53 ms, and packet loss increased from 0.73% to 9.78%. Moving the media relay to the tactical edge in S3 substantially changed this behavior. The median delay decreased from 86 ms in S2 to 39.19 ms in S3, while the P95 decreased from 117.53 ms to 57.50 ms and packet loss from 9.78% to 0.36%. S3 therefore recovered transport performance comparable to, and in these runs slightly better than, the terrestrial S1 baseline despite retaining the nonterrestrial backhaul for centralized service functions. This contrast indicates that the degradation observed in S2 is primarily associated with carrying mission-critical media through the centralized Starlink path, whereas edge local media anchoring avoids this traversal for MCPTT traffic. Figure 18 highlights this effect by comparing the median and 95th-percentile transport delays across the three placement scenarios.

4) Central-host Processing Intervals

To assess whether the UE-observed delay arose within centralized signaling, we captured both SIP legs of the P-CSCF on the central-host with host timestamps and instrumented the SIP AS with monotonic timestamps. The SimBox separately measured the end-to-end floor control transaction time, from submission of a floor control request to reception of the corresponding final response, using a UE-side monotonic clock. The central-host analysis reassembled TCP streams and matched each request to its response using the SIP CallID, CSeq, and dialog tags. Table 10 reports P95 intervals for one representative operation per experiment: free-floor 19

Oliveira et al.:

TABLE 11. MCPTT packet delivery at the receiving UEs.

Setup

Loss

D50

D95

J95

Disc.

Rate

S1

0.73

S2

9.78

39.21

60.63

19.50

1097

59.56

85.99

117.51

17.85

7648

54.14

S3

0.36

39.19

57.50

20.16

261

59.79

Loss: missing UE deliveries (%); D50 /D95 : one-way delay percentiles (ms); J95 : RFC 3550 jitter percentile (ms); Disc.: nonconsecutive RTP sequence transitions; Rate: received Opus payload bitrate (kb/s), excluding headers.

FIGURE 18. MCPTT audio transport delay by placement scenario, showing the median and 95th percentile of received packets. TABLE 10. Central-host-observed P95 SIP signaling intervals by MCPTT experiment. Values in milliseconds. Observed interval

S1

S2

S3

Access time P-CSCF request forwarding SIP AS processing P-CSCF response forwarding SIP request–response at P-CSCF

0.57 4.85 0.30 5.66

0.56 6.07 0.25 6.93

0.59 8.05 0.25 8.96

Floor control P-CSCF request forwarding SIP AS processing P-CSCF response forwarding SIP request–response at P-CSCF

0.43 6.71 0.19 7.33

0.41 7.41 0.16 8.12

0.50 7.35 0.25 8.10

Audio transport P-CSCF request forwarding SIP AS processing P-CSCF response forwarding SIP request–response at P-CSCF

0.49 29.58 0.28 30.34

0.47 38.22 0.27 38.93

0.49 49.35 0.31 50.04

acquisition for access time and audio transport, and priority preemption for floor control. P-CSCF request forwarding runs from capture of the complete UE request to the first packet forwarded toward the AS; response forwarding runs from capture of the complete AS response to the first packet sent toward the UE. The complete P-CSCF request–response interval runs from the complete UE request to the complete outgoing response. SIP AS processing runs from the instrumented completion of request reading to completion of final response writing, including awaited work such as the CMS priority lookup during preemption. The AS and packet-capture intervals use separate clocks, and each P95 is calculated independently; these percentiles should not be added. Across S1–S3, each P-CSCF forwarding interval remained below 0.6 ms at P95 . For access time, the UE-observed P95 increased from 67.16 to 114.24 and 184.52 ms, whereas the P-CSCF request–response P95 increased only from 5.66 to 6.93 and 8.96 ms. For priority preemption, the UEobserved P95 rose from 46.75 ms in S1 to 104.54 ms in S2, while the P-CSCF interval changed from 7.33 to 8.12 ms. Thus, processing in the centralized node SIP path was not the dominant bottleneck for these UE-observed signaling delays or their increase across the compared scenarios. The 20

independently calculated percentiles cannot be subtracted to assign the remaining delay to a specific network segment. The floor control P-CSCF totals remained similar across all three scenarios (7.33–8.12 ms). In the audio-transport experiment, the floor-grant total increased from 30.34 to 38.93 and 50.04 ms, principally alongside SIP AS processing; these rows measure the grant before each burst, not RTP delivery. In the S1–S2 runs, background N5 direction reconciliation had P95 values of 11.35–12.51 ms. It was not awaited by the SIP response and confirms only PCF acceptance, not SMF, UPF, or RAN enforcement. E. MCPTT Audio Quality

MCPTT audio quality was evaluated using 63 receiving UEs over ten 5s Opus transmission bursts per scenario, with a 20 ms packetization interval and 157,500 expected packet deliveries. Packet-level measurements were obtained by correlating matched sender and receiver logs, allowing packet loss, one-way transport delay, interarrival jitter, and received payload bitrate to be characterized at the receiving UEs. The measured packet delivery conditions were subsequently used to derive receiver-side parametric Mean Opinion Score (MOS) estimates under different playout buffer assumptions. The analysis therefore first characterizes the observed RTP transport performance and then evaluates its expected impact on voice quality.

1) Packet-Level Voice Performance

Table 11 summarizes the packet-level measurements across the 63 receiving UEs. Packet loss represents the fraction of expected RTP packets that were not received, while D50 and D95 characterize the one-way transport delay. The J95 metric represents the 95th percentile of the RFC 3550 interarrival jitter estimate. The received Opus payload bitrate was calculated over 50 s of active transmission per listener. The centralized NTN configuration S2 exhibited the greatest packet-level degradation, with loss increasing to 9.78% and D95 reaching 117.51 ms, compared with 0.73% and 60.63ms in the terrestrial S1 baseline. RTP sequence discontinuities similarly increased from 1,097 to 7,648, while the received payload bitrate decreased from 59.56 to 54.14 kb/s. In contrast, S3 recovered packet-level performance to approximately the terrestrial baseline, with 0.36% loss, a D50 of 39.19 ms, a D95 of 57.50 ms, and a received payload VOLUME ,

bitrate of 59.79 kb/s. Interarrival jitter remained comparable across the three scenarios, with J95 ranging from 17.85 to 20.16 ms. These results are consistent with the placement of the UPF and RTPengine at the tactical edge in S3, which prevents local RTP traffic from traversing the satellite path used in S2.

TABLE 12. VoIPmonitor receiver-side parametric MOS estimates.

Metric

S1

S2

S3

Mean UE MOS estimate

4.40

2.28

4.49

5th-percentile UE MOS

4.21

1.80

4.41

Fixed 50-ms buffer (F1)

Fixed 200-ms buffer (F2)

2) Receiver-Side Parametric Quality Estimate

Mean UE MOS estimate

4.42

2.45

4.49

To complement the packet-level analysis in Table 11, receiver-side voice quality was estimated offline using VoIPmonitor. The analysis considers three jitter-buffer configurations: a fixed 50-ms buffer (F1), a fixed 200-ms buffer (F2), and an adaptive buffer with a maximum size of 500 ms. These configurations provide different tolerance to packet delay variation and therefore allow the impact of the measured transport conditions on the estimated voice quality to be examined. Voice quality was assessed considering the main networklevel factors affecting media delivery, including packet loss, end-to-end delay, jitter, and the resulting packet delivery behavior. The MOS is a long established measure of perceived voice quality, originally defined through subjective listening assessments. In this work, VoIPmonitor is used to obtain objective parametric MOS estimates from the observed RTP packet stream rather than from the decoded audio signal. Its calculation uses packet-loss probability and loss burstiness through a formulation derived from the ITUT G.107 E-model3 , which models the impact of transmission impairments on conversational quality. Since packet delay variation can cause packets to arrive too late for playout and therefore become effectively lost, VoIPmonitor evaluates the RTP streams using three simulated jitter-buffer configurations. MOS F1 uses a fixed 50ms jitter buffer and is therefore more sensitive to delay variation; MOS F2 uses a fixed 200ms buffer, tolerating greater delay variation before packets are considered too late for playout; and MOS Adapt uses an adaptive jitter buffer that can grow up to 500 ms. For the Opus traffic evaluated in this work, VoIPmonitor applies its G.711/PLC-oriented parametric model rather than an Opus-specific perceptual model. The resulting scores are therefore interpreted as estimates of transport related voice impairment and are considered together with the directly measured packet loss, delay, and jitter, rather than as perceptual measurements of the decoded Opus audio. As shown in Table 12, S3 produced the highest mean MOS estimate for all three buffer configurations, with a value of 4.49, while S1 remained between 4.34 and 4.42 and S2 between 2.28 and 2.45. The substantially lower estimates in S2 are consistent with the higher packet loss observed in Table 11, where 15,410 packet deliveries were missing compared with 1,153 in S1 and 565 in S3. Conversely, the

5th-percentile UE MOS

4.30

2.10

4.50

Mean UE MOS estimate

4.34

2.41

4.49

5th-percentile UE MOS

4.20

2.00

4.40

3 https://www.itu.int/rec/T-REC-G.107

VOLUME ,

Adaptive buffer (up to 500 ms)

similar estimates obtained for S1 and S3 are consistent with their comparatively low packet-loss rates. These results further indicate that relocating the media path to the tactical edge in S3 can preserve receiver-side transport conditions despite the use of the NTN backhaul for centralized functions. F. MCVideo Service

The MCVideo stream was encoded using H.264 at a target bitrate of 750 kbit/s. This operating point was chosen to strike an optimal balance between video quality and radio resource consumption within the bandwidth-constrained mobile testbed. Prior experimental evaluations of H.264 video have analyzed 480p encoding across a broad range of bitrates including levels around 700–800 kbit/s highlighting the inherent trade-offs between encoding bitrate, perceived quality, and bandwidth consumption [33]. Consequently, 750 kbit/s was adopted as a bandwidth-efficient baseline for these experiments, facilitating scalability testing with up to 64 UEs. As depicted in Figure 19, the aggregate

FIGURE 19. Total RX throughput as a function of the number of UEs.

receive throughput scales proportionally with the number of viewers. Meanwhile, Figures 20 and 21 reveal that, although overall performance remained stable, small but non-zero frame and RTP packet losses occurred in the NTN-backed 21

Oliveira et al.:

TABLE 13. MCVideo end-to-end performance under load (64 UEs, 1 publisher).

Evaluated Metric

FIGURE 20. Frame loss as a function of the number of UEs.

S1

S2

S3

1. Signaling Latency (ms) Stream-establishment (P50 )

45.28

88.78

214.86

Stream-establishment (mean) Viewer-attachment (P50 ) Viewer-attachment (mean)

45.28 125.58 140.25

70.09 204.94 203.20

90.97 221.11 214.04

2. Achieved Media Throughput Uplink throughput / publisher (Mbps) Total uplink throughput (Mbps) Downlink viewer (mean Mbps) Total downlink throughput (Mbps) Rx/Tx fan-out delivery ratio

0.81 0.81 0.81 50.85 100%

0.81 0.81 0.81 50.83 99.3%

0.81 0.81 0.81 50.95 99.3%

3. End-to-End Latency & Reliability RTP transport P50 (ms) RTP transport P95 (ms)

52.65 128.86

267.47 699.92

230.02 617.10

RTP transport P99 (ms) RTP packet loss Frame loss

155.66 0.00% 0.00%

810.45 0.22% 0.50%

712.30 0.00% 0.06%

FIGURE 21. RTP packet loss as a function of the number of UEs.

configurations across various load levels. The system’s endto-end performance under the maximum evaluated load of 64 UEs is characterized in detail in Table 13. G. MCData Service

MCData group messaging was evaluated with one sender and 63 recipients. In each payload run, the sender transmitted 1,000 messages at a rate of 1 Hz. The telemetry and short data messages had 256 B SIP MESSAGE bodies. The attachment runs used a 6 second, 57,577 B audio clip and a 15 second, 3,029,970 B video clip. For each attachment, the sender uploaded the file to the Data Content Server and sent its 32 B content identifier in a SIP MESSAGE. Figure 22 separates the DCS upload time from the time between upload initiation and receipt of the SIP notification. All 1000 uploads completed in each attachment run. At the 95th percentile, audio uploads took 226.48 ms and video uploads took 1,275.03 ms. The corresponding upload-tonotification times were 329.18 ms and 1,346.33 ms. These values characterize the tested reference workload, and do not include recipient download or playback. Figure 23 illustrates the telemetry message fan-out. The sender issued 1,000 SIP MESSAGE requests, which produced 63,000 recipient messages. Solid arrows show MESSAGE traffic and dashed arrows show SIP responses. During this exchange, the endpoints recorded 96,531,634 SIP bytes: 22

FIGURE 22. P95 DCS upload time and upload to SIP notification latency for audio and video attachments. UE downloads are excluded.

16,384,000 body bytes (16.97%) and 80,147,634 non-body SIP bytes (83.03%), including headers and responses. This byte accounting applies to the telemetry run and excludes TCP/IP framing, internal server traffic, and DCS transfers. To examine the effect of increasing the sending rate, a separate telemetry sweep test with 250 messages, at each of four rates, was conducted. Table 14 reports the resulting

FIGURE 23. Telemetry SIP fan-out and endpoint-observed byte accounting. Dashed arrows denote SIP responses. TCP/IP and internal server traffic are excluded.

VOLUME ,

TABLE 14. Telemetry rate-sweep campaign with 64 UEs and 1000 messages in total (250 per rate). Send and delivery rates are in messages/s; P99 is end-to-end delivery latency in ms.

Target 0.5 1.0 1.5 2.0

Send rate

Delivery rate

P99

Success %

0.50 1.00 1.50 2.00

31.50 63.00 94.50 126.00

67.14 67.54 75.05 79.07

100.00% 100.00% 100.00% 100.00%

recipient delivery rate, end-to-end 99th-percentile latency, and successful delivery ratio. All 63,000 expected recipient deliveries were observed across the sweep. As the sending rate rose from 0.5 to 2.0 messages/s, the delivery rate rose from 31.50 to 126.00 deliveries/s, while P99 latency increased from 67.14 to 79.07 ms. The 100% delivery ratio describes these measured runs.

remained fixed through the service-specific 5QI 65, while the Priority and Preemption components were varied through the corresponding ARP profiles. U E3 preempted U E4 ’s normal-priority dedicated flow, whereas U E4 retained its flow against the same contender under permanent emergency priority. In the dynamic run, two distinct senders with the same U E3 profile requested resources during and after emergency protection. The first was refused a dedicated flow while U E4 was protected; the second was admitted and preempted U E4 after normal priority was restored. Both policy updates modified the existing flow while preserving 5QI 65. A separate UE-to-RAN experiment measured completion of the MCX-initiated QPP control path through IMS, the AS, and the 5G Core. The two evaluations, therefore, provide complementary evidence of QPP operation: admission and preemption outcomes under contention, and signaling latency for service-triggered policy updates across terrestrial and satellite-backed deployments.

H. Discussion of Experimental Findings

The findings illustrate the utility of distinguishing missioncritical media delivery from service control across a tactical edge 3D network. While the UPF and RTPengine were centralized across the satellite backhaul (S2), the MCPTT audio transport delay P95 reached 117.53 ms, and packet loss reached 9.78%. However, by placing these functions at the tactical edge (S3), the corresponding values were reduced to 57.50 ms and 0.36%, respectively. In addition, audio delivery in S3 was close to that obtained over the terrestrial connection (S1), where the corresponding values were 60.64 ms and 0.73%. These results demonstrate the benefit of tactical edge function placement within a 3D public-safety network: latency-sensitive media can remain within the local tactical network, while satellite connectivity is used to reach centralized service and control functions. The platform also supported MCPTT service operation with up to 64 simulated UEs across all evaluated configurations. The protocol-level MCPTT access time P95 in S3 was 184.52 ms, remaining below the 300 ms reference for established calls. Furthermore, the higher access time in S3 compared with S2 illustrates that media placement and service access are affected by different components of the end-to-end path: the media relay was local to the tactical edge in S3, whereas IMS and service-control functions remained centralized and their signaling continued to traverse the NTN backhaul. The MCData experiments additionally demonstrated reliable SIP message distribution at the examined rates, with all 63,000 expected recipient deliveries observed in each reported payload run. These results reinforce the importance of evaluating the complete service chain across the distributed terrestrial, aerial, and non-terrestrial network segments with tactical edge processing rather than considering network transport in isolation. The controlled contention experiments provide evidence of the proposed QPP mechanism under constrained radio resources. In these experiments, the Quality component VOLUME ,

VII. Conclusions and Future Work

Resilient public-safety communications require network architectures that can adapt both to changing operational priorities and to the availability of communication infrastructure. This work addresses these requirements through an integrated MCX platform combining dynamic Quality, Priority, and Pre-emption (QPP) enforcement with distributed edge processing across terrestrial, aerial, and non-terrestrial 5G connectivity. The platform supports MCPTT, MCVideo, and MCData, while translating operational priority changes into dynamic ARP updates on active QoS flows without modifying the service-specific 5QI or disrupting established sessions. Through experimental evaluation with up to 64 simulated UEs, the proposed solution demonstrated the benefits of tactical-edge media processing under satellite backhaul. Compared with centralized media processing, edge placement reduced MCPTT audio transport delay P95 from 117.53 ms to 57.50 ms and packet loss from 9.78% to 0.36%, approaching the terrestrial baseline. The edge configuration further achieved an MCPTT access-time P95 of 184.52 ms and reliable MCData SIP delivery at the evaluated message rates. These results demonstrate that local media processing can preserve responsive mission-critical services while reducing their dependence on constrained non-terrestrial backhaul. Together, the QPP and tactical edge results provide an experimental foundation for context-aware MCX operation across 3D public-safety networks. The contention tests demonstrate profile-dependent admission and retention with unchanged service-specific 5QI, while the placement experiments show the benefit of keeping local MCPTT media at the tactical edge. Future work will extend the priority evaluation to repeated trials and a wider range of competing loads, and examine service recovery after backhaul interruption and MCVideo performance during aerial operation. 23

Oliveira et al.:

Acknowledgment

This work was supported by the European Regional Development Fund (ERDF), through the Centro Regional Programme (CENTRO 2030) of the Portugal 2030 framework [Project DAWN6G with Nr. 19219 (CENTRO2030FEDER-01672300)], and through the Innovation and Digital Transition Programme (COMPETE 2030) of the Portugal 2030 framework [Project ALBATROZ with Nr. 17775 (COMPETE2030-FEDER-01335900)]. REFERENCES [1] K. L. Ebi, J. Vanos, J. W. Baldwin, J. E. Bell, D. M. Hondula, N. A. Errett, K. Hayes, C. E. Reid, S. Saha, J. Spector, and P. Berry, “Extreme weather and climate change: Population health and health system implications,” Annual Review of Public Health, vol. 42, pp. 293–315, 2021. [2] K. Hazra, V. K. Shah, S. Silvestri, V. Aggarwal, S. K. Das, S. Nandi, and S. Saha, “Designing efficient communication infrastructure in post-disaster situations with limited availability of network resources,” Computer Communications, vol. 164, pp. 54–68, 2020. [3] M. Matracia, N. Saeed, M. A. Kishk, and M.-S. Alouini, “Postdisaster communications: Enabling technologies, architectures, and open challenges,” IEEE Open Journal of the Communications Society, vol. 3, pp. 1177–1205, 2022. [4] I. P. Chochliouros, A. S. Spiliopoulou, P. I. Lazaridis, Z. D. Zaharis, M.-R. Spada, J. Pérez-Romero, B. Blanco, H. Khalife, E. Ebrahimi Khaleghi, and M.-A. Kourtis, “5g for the support of public safety services,” Wireless Personal Communications, vol. 120, no. 3, pp. 2321–2348, 2021. [Online]. Available: https://doi.org/10.1007/s11277-021-08473-5 [5] 3GPP, “Mission critical services common requirements,” 3rd Generation Partnership Project, Tech. Rep. TS 22.280, 2026, release 19, Version 19.7.0. [6] The Critical Communications Association (TCCA), “Legal and regulatory aspects regarding the realisation of quality of service, priority and pre-emption (qpp) in commercial networks,” The Critical Communications Association (TCCA), White Paper, Sep. 2023, issued by the Legal and Regulatory Working Group (LRWG). [7] J. Li, K. K. Nagalapur, E. Stare, S. Dwivedi, S. A. Ashraf, P.-E. Eriksson, U. Engstrom, W.-H. Lee, and T. Lohmar, “5g new radio for public safety mission critical communications,” IEEE Communications Standards Magazine, vol. 6, no. 4, pp. 48–55, 2022. [8] J. Li, X. Lin, K. K. Nagalapur, Z. Qi, A. Lahuerta-Lavieja, T. Chapman, S. Agneessens, H. Sahlin, D. Guldbrand, and J. Akesson, “Toward providing connectivity when and where it counts: An overview of deployable 5g networks,” IEEE Communications Standards Magazine, vol. 6, no. 4, pp. 56–64, 2022. [9] E. Calvanese Strinati, S. Barbarossa, T. Choi, A. Pietrabissa, A. Giuseppi, E. De Santis, J. Vidal, Z. Becvar, T. Haustein, N. Cassiau, F. Costanzo, J. Kim, and I. Kim, “6g in the sky: On-demand intelligence at the edge of 3d networks (invited paper),” ETRI Journal, vol. 42, no. 5, pp. 643–657, Oct. 2020. [Online]. Available: http://dx.doi.org/10.4218/etrij.2020-0205 [10] O. Chukhno, N. Chukhno, A. Ometov, S. Pizzi, G. Araniti, and A. Molinaro, “Application-driven offloading of xr mission critical via integrated tn/ntn,” IEEE Network, vol. 40, no. 2, pp. 304–311, 2026. [11] J. Chen and K. K. Ramakrishnan, “Providing application access to voice streams: Enhancing ptt services for emergency response,” in 2022 Workshop on Cyber Physical Systems for Emergency Response (CPS-ER), 2022, pp. 24–29. [12] W. Kampichler, D. Eier, and F. Liberal, “Improvements in operational efficiency at airports using lte networks for communications,” in 2022 Integrated Communication, Navigation and Surveillance Conference (ICNS), 2022, pp. 1–9. [13] D. Makhija, “Performance of mission critical device to device communication in rayleigh fading channel,” in 2023 International Conference on Recent Advances in Electrical, Electronics & Digital Healthcare Technologies (REEDCON), 2023, pp. 600–604. [14] A. Sanchoyerto, R. Solozabal, B. Blanco, and F. Liberal, “Analysis of the impact of the evolution toward 5g architectures on mission critical

24

push-to-talk services,” IEEE Access, vol. 7, pp. 115 052–115 061, 2019. [15] A. Santiago, A. D. De Cerio, A. Sanchoyerto, and F. Liberal, “Analysis of mission critical services radio access network capacity limitations over 5g,” IEEE Access, vol. 12, pp. 6191–6203, 2024. [16] E. Kara, E.-R. Modroiu, M. Corici, and T. Magedanz, “Proof-ofconcept implementation of mission critical push-to-talk services in private 5g networks,” in Proceedings of the 1st Workshop on Open Research Infrastructures and Toolkits for 6G, ser. OpenRIT6G ’25. New York, NY, USA: Association for Computing Machinery, 2025, pp. 21–26. [Online]. Available: https://doi.org/10.1145/3750718.3750745 [17] E.-R. Modroiu, J. Mwangama, M. Corici, and T. Magedanz, “Integrating open-source vonr in 5g sa private networks: An experimental evaluation,” in 2024 International Conference on Software, Telecommunications and Computer Networks (SoftCOM), 2024, pp. 1–6. [18] F. Maier, S. Kendre, M. Tyrskyy, A. Weber, U. Geier, M. Taferner, P. Beicht, K. Wriston, E. Stefani, and J. Koecher, “Field evaluation of mcx implementations for the future railway mobile communication system,” in 2023 IEEE 97th Vehicular Technology Conference (VTC2023-Spring), 2023, pp. 1–6. [19] M. A. Habibi, B. Han, A. Fellan, W. Jiang, A. G. Sánchez, I. L. Pavon, A. Boubendir, and H. D. Schotten, “Toward an open, intelligent, and end-to-end architectural framework for network slicing in 6g communication systems,” IEEE Open Journal of the Communications Society, vol. 4, pp. 1615–1658, 2023. [20] C. T. Nguyen, Y. M. Saputra, N. V. Huynh, T. N. Nguyen, D. T. Hoang, D. N. Nguyen, V.-Q. Pham, M. Voznak, S. Chatzinotas, and D.-H. Tran, “Emerging technologies for 6g non-terrestrial-networks: From academia to industrial applications,” IEEE Open Journal of the Communications Society, vol. 5, pp. 3852–3885, 2024. [21] D. Borsatti, C. Grasselli, C. Contoli, L. Micciullo, L. Spinacci, M. Settembre, W. Cerroni, and F. Callegati, “Mission critical communications support with 5g and network slicing,” IEEE Transactions on Network and Service Management, vol. 20, no. 1, pp. 595–607, 2023. [22] S. T. Spantideas, A. E. Giannopoulos, and P. Trakadas, “Smart mission critical service management: Architecture, deployment options, and experimental results,” IEEE Transactions on Network and Service Management, vol. 22, no. 2, pp. 1108–1128, 2025. [23] S. Spantideas, A. Giannopoulos, M. A. Cambeiro, O. Trullols-Cruces, E. Atxutegi, and P. Trakadas, “Intelligent mission critical services over beyond 5g networks: Control loop and proactive overload detection,” in 2023 International Conference on Smart Applications, Communications and Networking (SmartNets), 2023, pp. 1–6. [24] D. White, Y. Bao, E. Ding, E. Fong, M. McGlynn, and S. Kowdley, “5g resilience evaluation for mission critical communications,” in 2025 IEEE World Forum on Public Safety Technology (WF-PST), 2025, pp. 104–111. [25] B. Li, Z. Fei, and Y. Zhang, “Uav communications for 5g and beyond: Recent advances and future trends,” IEEE Internet of Things Journal, vol. 6, no. 2, pp. 2241–2263, 2019. [26] M. K. Banafaa, O. Pepeoglu, I. Shayea, A. Alhammadi, Z. A. Shamsan, M. A. Razaz, M. Alsagabi, and S. Al-Sowayan, “A comprehensive survey on 5g-and-beyond networks with uavs: Applications, emerging technologies, regulatory aspects, research trends and challenges,” IEEE Access, vol. 12, pp. 7786–7826, 2024. [27] M. Mahbub, M. M. Saym, S. Jahan, A. K. Paul, A. Vahid, S. Hosseinalipour, B. Barua, H.-G. Yeh, R. M. Shubair, and T. Taleb, “A holistic survey of uav-assisted wireless communications in the transition from 5g to 6g: State-of-the-art intertwined innovations, challenges, and opportunities,” Journal of Network and Computer Applications, vol. 237, p. 104131, 2025. [Online]. Available: https: //www.sciencedirect.com/science/article/pii/S1084804525000281 [28] N. Khan, A. Ahmad, A. Wakeel, Z. Kaleem, B. Rashid, and W. Khalid, “Efficient uavs deployment and resource allocation in uav-relay assisted public safety networks for video transmission,” IEEE Access, vol. 12, pp. 4561–4574, 2024. [29] S. Nasirian, G. Giambene, S. Barrachina-Munoz, J. Mangues-Bafalluy, M. Hadji, M. A. Vazquez, L. Santilli, F. Foukalas, and H. Khalili, “Satellite-terrestrial integration: 5g architectures for the seamless support of mission critical services,” in 2025 12th Advanced Satellite Multimedia Systems Conference and the 18th Signal Processing for Space Communications Workshop (ASMS/SPSC), 2025, pp. 1–8. [30] M. Figaro, F. Rossato, A. Bonora, M. Giordani, G. Schembra, and M. Zorzi, “Experimental evaluation of a uav-mounted leo satellite

VOLUME ,

backhaul for emergency connectivity,” in 2026 International Conference on Computing, Networking and Communications (ICNC), 2026, pp. 1–6. [31] D. Correia, J. Su, R. Gomes, P. Valente, P. Rito, D. Raposo, and S. Sargento, “A multi-uav platform with 5g and ntn backhaul for ppdr scenarios,” in 2026 IEEE Wireless Communications and Networking Conference (WCNC), 2026, pp. 1–6. [32] 3GPP, “Mission critical push to talk (mcptt); stage 1,” 3rd Generation Partnership Project, Tech. Rep. TS 22.179, Jan. 2026, version 19.3.0, Release 19. [Online]. Available: https://www.etsi.org/deliver/etsi_TS/ 122100_122199/122179/19.03.00_60/ts_122179v190300p.pdf [33] J. Klink and S. Brachmański, “An impact of the encoding bitrate on the quality of streamed video presented on screens of different resolutions,” in 2022 International Conference on Software, Telecommunications and Computer Networks (SoftCOM), 2022, pp. 1–6.

VOLUME ,

25

Related documents

• We Were Lost in Our Country#1149159
• The Nexus of Voluntary Action and Humanitarian Imperative: A Comprehensive Analysis of Principled Service in Crisis Contexts#667053
• The Nexus of Voluntary Action and Humanitarian Imperative: A Comprehensive Analysis of Principled Service in Crisis Contexts#666963
• DisasterInsight: A Building-Centric Benchmark for Evaluating Vision--Language Models in Disaster Response#1335824
• Dynamics and Forecasting of Emergency Department Presentations: An Integrative Approach Based on Statistical Analysis and Time-Series Models.#785829