In the blogpost on “Isolated Operations in 5G PPDR – 5G IOPS” we discussed the state-of-the-art of communications in Public Protection and Disaster Relief (PPDR) and our proposed approach to introducing resilience into commercial 5G mobile networks through the concept of Isolated Operations for Public Safety (IOPS). This technology is critical for protecting critical infrastructure, such as public mobile networks, ensuring the resilience and security of society, and maintaining the continuity of essential services during emergencies and disasters.
In this post, we will further discuss how we utilized 5GASP concepts to shorten the idea-to-market process by using a fully automated and self-service testbed assured by 5GASP. This approach has fostered rapid development and testing of our 5G Network Application, which was built using the 5G NFV-based reference architecture. By building on top of existing physical infrastructures, 5GASP provided us with software support tools for Continuous Integration and Continuous Deployment (CI/CD) of VNFs in a secure and trusted environment. This post will also present the practical results achieved so far.
While dealing with IOPS, there are two operational scenarios of the network:
- (1) day-to-day operations:
- (2) operations under disaster circumstances:
In fact, Isolated Operations take place in scenario 2, where disaster circumstances prevent backhaul connectivity between the core network site and (remote) cell site. Such a disaster situation would normally result in failure of all services provided by the network, while activation of isolated operations in case of disaster circumstances aims at preserving services availability, though at limited scale. Switching between day-to-day operations and isolated operations is controlled by a dedicated Network Application which in fact assures availability of dedicated 5G slice, i.e., 5G PPDR slice, within the 5G mobile network, either global or local only.
The concept of 5GASP environment with its mesh network, i.e., peer-to-peer connection between each testbed site, enables any testbed site to deploy a (remote) cell site node or/and core network node (however, the deployment of each certain node depends on specific hardware resources as well). Such connectivity may further allow for multiple 5G PPDR slices to be implemented at (remote) cell site node and at the same time not all being terminated at the same core network node. This way, although not part of original 5GASP scenario, multiple PPDR units can be hosted on the same (remote) cell site node (e.g., in case of emergency requiring multi-national teams’ intervention) and benefiting from isolated operations mode which is likely to occur during emergency situations.
During the development of the IOPS solution within 5GASP project, we have also developed test cases aimed at verifying and validating the functionality of the 5G IOPS Network Application and performances of the 5G PPDR slice provided by the Network Application. There were specific PPDR tests developed in order to test IOPS operation and UE connectivity over the PPDR IOPS slice, as well as the Network Application will be tested against selected PPDR vertical tests developed within 5GASP.
List of Network Application specific tests implemented includes IOPS components tests (IOPS gNB Component Readiness, IOPS Core Network Component Readiness), application layer connectivity tests (Web test, DNS test, Ping test) and performance tests (IP throughput download and upload tests, Packet loss).
PPDR vertical specific test implemented includes UE network connectivity tests, network/backhaul failure detection test (PPDR IOPS – failure detection and failure detection time), switchover from central core network to local core network (PPDR IOPS – switchover and switchover time), UE network connectivity in local network (PPDR IOPS – UE local IOPS network connectivity) and, finally, restoration from local to central core network (PPDR IOPS – restoration time).
Network Application functionality tests are implemented in robot/Jenkins framework, while performance tests use ININ’s qMON monitoring tool and are automated as well.