Mission Critical services (MCx) enable public safety officers, agents and first responders to use the 5G broadband wireless network to setup voice calls, including broadcast and group calls, to stream high definition videos and to send data, e.g., maps, locations, messages and other relevant information. Such information is paramount to create situational awareness, that is, the digital re-construction of the interaction between individuals, objects and the environment within a limited geographical perimeter, while adhering to often strict security requirements in terms of isolating the network resources being used. This tool is instrumental for PPDR forces to plan and engage action in a precise and timely manner, two aspects that are crucial to minimize error margins when it comes to save lives. This use case employs custom MCx slices, enabled by FUDGE-5G, such as Mission Critical Push-to-talk; Mission Critical Video and Mission Critical Data, albeit realized as service applications over a pure 5GLAN, each one having its own requirements in terms of performance, security, and reliability. 

The availability of broadband wireless coverage at the intervention site is a crucial aspect for PPDR use cases. In general, the following key scenarios may occur: i) connectivity is provided by a mobile network infrastructure owned by the public safety entity itself, ii) by the deployment of an ad-hoc connectivity bubble, iii) by an MNO, and iv) by a combination of the previous, including different radio access technologies, such as 4G+5G. Orchestrating a service that accounts for this heterogeneous characteristic of the network infrastructure is a challenge. Especially for what concerns the connectivity bubble (also known as tactical bubble) which shall be portable, easy-to-deploy, and able to work in stand-alone mode, i.e., in absence of any backhaul link (creating a local and private 5G system). It is expected for connectivity bubbles based on 5G to have the capability to be deployed at a temporary camp, in a mid-size vehicle such as a van, or even embedded in a rucksack worn by agents, being integrated into the overall vertical use case as a mere network function. For this reason, they are all-in-one systems, as they shall contain all network elements and applications to support fundamental operations for the use case, such as subscriber authentication, session management, multicast/broadcast communications, traffic prioritization based on dedicated QoS Class Identifiers (QCI), delivery of the desired voice and data services to the subscribers. Optionally, the solution may support mobility, whereas charging is usually not used. Because of the constraints on deployability and configurability associated to a portable solution, the subscribers’ database is usually carefully dimensioned, and, especially for the most compact solutions, it may not be able to contain all the potential subscribers. Hence, modularization and decomposability of the network functions in order to adjust to the limitations of deployment is a real challenge here, e.g., with the ability to quickly (re-)provision the subscribers’ database in a simple and secure way. The solution shall be able to connect to a provisioning system that fulfils such requirements. 

To fulfil the requirements above, the 5GC in the PPDR scenario shall be deployed in a compact, all-in-one fashion. A compact solution poses limitation on the hardware to be used, so that a potentially critical KPI can be the battery capacity required to run for a given interval and maximum number of attached subscribers. For this reason, energy-saving hardware may be preferred over high-end, hence the network functions and other software modules need to be carefully designed in order to have the smallest footprint as possible. In addition, other key aspects are related to the ability of connecting to public mobile networks when available, selecting the most appropriate service instances when in connected/standalone mode (e.g., the most appropriate subscribers’ database service instance), creating pools of connected 5G systems on the fly, and providing service to support forces that join the action but do not belong to the same entity that administers and operates the network via the formation of a coalition. This is typically the case of a joint action between teams from different forces, e.g., a police squad and a fire brigade. Moreover, when several user-plane applications are mapped onto different super slices, it should be possible to offer different levels of security for each application leveraging the flexibility of the 5GC deployed on top of an eSBA platform. For instance, offering a stronger encryption for a drone command and control service or a powerful authentication service for streaming cameras will rely on different super slices and the importance of their dedicated services. 

Activity 1:
This activity focuses on the high-level scenarios under test, the basic architecture of the demonstration, the key objectives of the use case, and the methodology for validation activities.

Activity 2:
The goal here is to provision and integrate the autonomous edge platform at the Rygge Airport site. This include the provisioning and installation of the HW platform components on the van; the installation and configuration of the VIM (MS Azure or OpenStack); the installation and interconnection of the RAN on the van; testing and troubleshooting activities.

Activity 3:
The objective of this activity is to provision the selected cloud applications to the edge platform at the Rygge airport and to test their well-functioning and available connectivity via local testing. Enabling and testing end-devices connectivity via the RAN.

Activity 4:
Enables the integration of the Autonomous Edge into a remote cloud, from the 5G-VINNI project testbed, to enable remote connectivity. Provision the selected cloud applications to the remote site and test connectivity.

Activity 5:
The goal here is to integrate the FUDGE-5G core over the SCP component and the integration of the core functions at the autonomous edge, so that vertical applications can already make use of the functionalities of the FUDGE-5G platform.

Activity 6:
Incorporate the vertical application orchestrator and the secure slice orchestrator. First iteration focus on the autonomous edge. Second iteration focus on the remote cloud and the interoperation of the deployed orchestrators.

Activity 7:
Here the goal is to create a protocol for the execution of the demonstrations (e.g., actions to execute), the identification of the technical means to collect the relevant KPIs, the allocation of responsibilities, the identification of environmental and external factors that could affect the results.

Activity 8:
The activity deals with the on-site test execution and the collection of tests results.

Activity 9:
Analysis and elaboration of results, compilation of reports.