Log In Sign Up

Mission-Critical Public Safety Networking: An Intent-Driven Service Orchestration Perspective

by   Kashif Mehmood, et al.

Intent-based networking (IBN) provides a promising approach for managing networks and orchestrating services in beyond 5G (B5G) deployments using modern service-based architectures. Public safety (PS) services form the basis of keeping society functional, owing to the responsiveness and availability throughout the network. The provisioning of these services requires efficient and agile network management techniques with low-overhead and embedded intelligence. IBN incorporates the service subscribers in a model-driven approach to provision different user-centric services. However, it requires domain-specific and contextual processing of intents for abstracted management of network functions. This work proposes an intent definition for PS and mission critical (MC) services in beyond B5G networks, as well as a processing and orchestration architecture on top of MC push-to-talk (PTT) use case. The simulation results show that MC PTT services adhere to the key performance indicators of access time and mouth-to-ear latency bounded by approximately 250 and 150 milliseconds, respectively, with an additional overhead experienced during the intent processing in the range of 20- 40 milliseconds. This validates the premise of IBN in providing flexible and scalable management and service orchestration solution for PS next generation networks.


page 1

page 2

page 5


Intent-driven Autonomous Network and Service Management in Future Networks: A Structured Literature Review

Intent driven networks are an essential stepping stone in the evolution ...

Intent-based Network Management and Orchestration for Smart Distribution Grids

5G technology complements the enabling of communication services for dif...

Deployable Networks for Public Safety in 5G and Beyond: A Coverage and Interference Study

Deployable networks are foreseen to be one of the key technologies for p...

Cross-stakeholder service orchestration for B5G through capability provisioning

Cross-stakeholder service orchestration is a generalization of 5G networ...

KCN: Knowledge Centric Networking

The advent of multi-domain and multi-requirement digital services requir...

Demonstration of latency-aware 5G network slicing on optical metro networks

The H2020 METRO-HAUL European project has architected a latency-aware, c...

Constraint programming for flexible Service Function Chaining deployment

Network Function Virtualization (NFV) and Software Defined Networking (S...

I Introduction

ibn has been extensively studied in recent years focusing on achieving a policy-based high-level control of networked devices using input from subscribers, service providers and network operators [1], [2]. ibn provides a mapping model for user-centric configuration management of coexisting services in communication networks. In addition, ibn provides a path towards reducing human administration during the service lifecycle management by directly mapping user requests to service profiles and deployment using standard network functions [3, 4]

. This closed-loop orchestration and management of services and network functions opens a deeper discussion towards the automation of lifecycle using, for example, machine learning methods 


The ibn relevance has increased with the softwarization and open implementations of different network functions and service models [6]. European Telecommunications Standards Institute launched initiatives highlighting the role of ibn including Zero Touch Service and Network Management  [7] and Experiential Network Intelligence  [8]. They concluded that intents can embody the user needs in an abstract manner, and that translation helps in mapping the requirements into different data models to be interpreted by service orchestrators and network controllers.

ps networks can benefit from the diverse service-based architecture and ecosystem in b5g networks [9]. However, the diversity in service and vertical environments poses a coexistence challenge for ps communication [10]. These verticals coupled with a diverse set of internal use cases and kpi require focused efforts in provisioning and management by the network operators [11].

The cost of keeping a dedicated network infrastructure like tetra [12] for the ps communication is no longer viable due to competitive services offered by commercial cellular networks. Hence, this assimilation of ps services offers mutual benefits for providers and subscribers. These services encompass multiple scenarios, such as ptt, video and data, location tracking, remote control, monitoring of device and on-body sensors.

The utilization of ibn as a disruptive network management and service orchestration technology is still being explored [13], with ps communication as a particularly challenging vertical in next generation networks. Volk et. al [10] studied the feasibility of 5g for migratory integration of ps communication services from the tetra infrastructure with experimental validation that 5g networks can support these services. Suomalainen et. al [11] focused on secure communication within ps, exploring the impact on potential military and highly-sensitive use cases.

However, there is a gap between service orchestration and management of network functions and the utilization of user input in an effective manner with user centric high-level policies in ps scenarios. This paper explores this gap by analyzing the impact of intents over the lifecycle management of ptt services in a user-centric orchestration deployment.

Fig. 1: (a) Proposed Intent-based network architecture (for ptt use case), (b) Intent recognition and translation pipeline.

We propose the intent-based network management framework, where intents can be generated by a service provider and by a subscriber. Intents are processed and translated into a data model consumed by the network controller through device-level configurations. Resource provisioning is handled through a closed-feedback loop from the underlying LTE infrastructure. The proposed ibn framework takes directly user input by using a cnl model, extracting key information related to the service, end points, dependencies, and instructing the service orchestrator to deploy the required resources. A ptt scenario is designed to validate the proposed framework through an extensive performance evaluation of kpi. The experimental results indicate the ability of different stakeholders to influence the performance of ps service in distinct communication scenarios encountered by the subscribers.

The rest of the paper is organized in the following manner. Section II presents the proposed framework for intent-driven network management and service orchestration of ps network. The simulation design methodology and experimental results for the ptt communication scenario are presented in Section III, along with a discussion of key findings. Finally, Section IV concludes this paper.

Ii Proposed Intent-Based Network Management Framework for PS networks

ps communication encompasses an ideal scenario for deterministic networking with guaranteed performance for different use cases. ptt is one such use case for rescue operations performed by different health and safety authorities [14]. This consists of assisting different public safety authorities in communicating with low-latency and high reliability guarantees. It also supports different users with strict connection setup and latency requirements (Sec-IIB) in order to coordinate an evolving rescue operation. In other words, ptt falls under the umbrella of ultra-reliable and low latency communication services making it a challenging service to be provisioned to subscribers using traditional resource allocation methods.

’establish’, ’connect’, ’reconnect’,
’provide’, ’enable’
’disconnect’, ’terminate’,
’disable’, ’tear down’
’mc server’, ’mc user’, ’ptt server’,
’ptt user’
Service ’voice’ ’video’ ’signaling’
TABLE I: CNL based intent translation and mapping logistics.

Exposure of system-level information and methods towards service subscribers for different communication services is critical towards designing user-centric service and network orchestration policies. However, the unavailability of contextual information (e.g., sla, network control policies) for service subscribers poses a challenge. Instead, subscriber intents can be incorporated into the decision making and orchestration of different services and network infrastructure. This is accomplished through an intricate expression and recognition of subscriber input followed by the decomposition, contextual mapping and deployment of user-centric policies.

The management flow starts with intent sources, i.e. ps service subscribers and providers, acting as the intent generators and specifying high-level abstract policies. The mapping, validation and conversion of intents to low-level service profiles is done and presented to the network controller for deployment. This intent processing pipeline has been labelled as steps 1 to 5 in Fig. 1. The underlying physical network infrastructure consists of ptt service deployed through a dedicated ps service infrastructure provider.

The service subscriber generates an intent, that is processed with input from the network and service provider resulting in a set of services, connection endpoints and required networking capabilities. The service environment adapts based on the changes in the active service flows as per different intents in the network. For example, a rescue team can prompt the initiation of a group conversation, localized and tracked user monitoring or, in case of going out-of-coverage, a relay connectivity solution for some team members.

Ii-a IBN Model

The network infrastructure is based on LTE deployment for this study and ps service is provided through a service provider with various service offerings. Intents provide a critical integration tool to handle different types of service requests with minimum overhead ensuring reliable service delivery. The declarative definition of intents shields the service subscribers and providers from resource as well as infrastructure level-state of the network. The onus of understanding these high-level policies falls upon the network operator requiring the need for a dedicated intent-processing and translation component.

Ii-A1 Intent definition and processing

Recent studies in ibn have focused on a contextual intent description model or a domain-specific language (DSL) model to represent intents [13]. This approach provides domain specific intent processing lacking generalization of the intent processing pipeline. In contrast, we specify that intents are defined using a set of cnl instructions with the core components shown in Fig. 1(b) step 1. The service subscriber utilizes a simple CNL model with keywords specified in the Table I to express the desired connection and service in a declarative manner. Intents can be generated using the combination of keywords with desired endpoints and services from Table-I. In this paper, the proposed framework utilizes the generation of natural language based intent expression model followed by conversational mapping of the required service requirements and orchestration by the orchestrator. The type of intent is specified by the vocabulary of the noun phrases used in intent expression. Moreover, the knowledge of available services offered by the service provider gives the required scope of the intent expression. The network level knowledge database consists of sla, offered services, service providers and network resource capabilities expressed in coordination with infrastructure and deployment information.

Ii-A2 Intent decomposition, recognition, and deployment

The recognition of the core elements forming the intents provides an initial step towards developing an understanding and eventual mapping operations. The mapping of high-level declarative policies into an orchestrator agnostic template is the prime objective of the intent processing module. The translation is accomplished in close coordination with the network operator, considering the available data sources in the knowledge database (step 2). The relevant service keyword is identified from the intent and mapped onto a supported service profile from the available set of service offerings in the network (step 3). The mapped service is prepared for deployment through the construction of service descriptors with information extracted from the underlying service provider infrastructure to create service deployment templates (step 4). A network controller then constructs the LTE bearer configuration template using SLOs to be deployed in the network infrastructure completing the orchestration of recognized services (step 5).

Ii-A3 Validation and Assurance

The validation and feasibility analysis of the intent is performed with the help of telemetry data from the network devices. A dialogue can be sought with the intent user in case of failure to verify the sufficiency of resources, possible conflicts with deployed intents or lack of required subscription with the service provider. The orchestration is initiated upon successful completion of the intent validation. Moreover, deployed intent performance is monitored through collected network data and compliance with sla is ensured through the intent processing modules.

Fig. 2: (a) ptt kpi, (b) Key events during simulated intent-based ptt scenario.

Ii-B PS Network Infrastructure

Ii-B1 ps Network Model

In this paper, we consider an LTE network environment where the intent based ptt service orchestration is performed. Three different teams with varying number of user devices are coordinating a rescue operation inside a building and devices in a team can connect to one or multiple devices simultaneously based on the nature of the rescue operation. The radio access network supports on-network, off-network (d2d) and ue relays in order to maintain connection amongst different rescue teams based on enb coverage. The orchestrated ptt service provides the user devices in different teams to choose from the available modes of connectivity throughout the course of the rescue operation.

Ii-B2 ps Service Use Case

ptt, video and data connections form the basis of the considered system model, however it can be extended if needed, given that the ibn model uses an abstract policy definition with mapping of kpi. ps services have stringent qos constraints made specified by the 3gpp from Release-12 up til Release-17 [15].

ptt supports one-to-one, group calls, and emergency calls, where the caller first requests the resources, and the grant is provided by the network in coordination with the ptt service provider, followed by call termination. The connection is established in a sequence of events:

  • A user requests the floor to access the network in order to utilize the ptt service (access request in Fig. 2(a)).

  • The network operator grants the floor to the requesting user based on resource availability.

  • Afterwards, the user can initiate the data transfer to one or multiple receivers (media transmission in Fig. 2(a)).

Ii-B3 Pss kpi

ptt is a typical use case of ps service. 3gpp considers several components of access and communication delay coupled with propagation delays through the access and core infrastructure to model the following kpi [14]:

  • [noitemsep,topsep=2pt,parsep=0pt,partopsep=0pt]

  • at: It is the time between user request and grant of permission to speak.

  • m2e latency: It is the time between an instance when sender speaks and the instance when receiver hears the transmission.

The timeline for the measurement of these kpi as well as the performance requirements specified by 3GPP Release 16 [15], are shown in Fig. 2(a).

Iii Performance Evaluation

In this section, we describe the simulation design for the validation of the proposed framework for an intent-based provisioning of ps services. We evaluate the performance of a ptt scenario, with the help of at and m2e latency as relevant kpi. The simulation setup is designed to mimic the behavior of a ptt provides the base infrastructure for deployment and assurance of intents through relevant service requirements [12].

Key simulation parameters are provided in Table II for the ptt scenario in Fig. 2 (b). The figure describes the sequence of events for different teams in the simulation environment in order to produce a varied performance behavior. This enables quantification of performance of a ptt scenario once the deployment has been done using IBN framework.

Simulation Parameters
# of simulation runs 20
Network Mode
On (Team 1), Off (Team 2)
Relay (Team 3)
# of users\team [4, 8, 12, 16]
Distance eNB<->Ue 400 m
Ue<->building 10 m
Ue<->Ue 5 m
PTT floor queueing [on, off]
Transmit Power Ue [23, 25, 27] dBm
eNB [30, 32, 34] dBm
Pathloss Models Outdoor Hata, COST231
Indoor ITU-R P.1411 , ITU-R P.1238
LTE Sidelink MCS 15
# of RBs per UE 5
Scheduler MinProb
RSRP Threshold (Relaying) -124 dBm
TABLE II: A list of simulation parameters.
Fig. 3: A timeline of KPI performance with simulation time.
Fig. 4: Access Time (AT) performance with respect to number of users per team and communication modes for 20 runs.

Iii-a Experimental Setup

The simulation involves two parts – intent processing and service orchestration. Intents are processed through a cnl model in Python interacting with the service orchestrator implemented using ns-3 [16] . The simulation scenario along with the sequence of events triggered by the intents is shown in Fig. 2 (b). The connection intents are generated by the users when the network simulation starts at instant A for service orchestration by the orchestrator followed up by necessary resource allocation.

The ptt network consists of a single enb connected to an LTE enhanced packet core (EPC). A total of three rescue teams consisting of varying number of ue are available in the scenario for utilizing the ptt service. One ue amongst each team acts as an anchor point with no mobility, while, multiple UEs within a team move inside the building to their respective locations.

The simulation can essentially be divided into three parts consisting of on-network, off-network and relay mode for different ue.The following events occur as shown in the timeline in Fig. 3: Team 1 is provided on-network access through the enb and starts a call at instant B. Team 2 stops its in-network access upon reaching the building (instant C) and starts a group-call in off-network mode using d2d connection. Team 3 connects normally to the enb, starts a call at instant B, but switches to its stationary anchor ue for relaying as soon as the received power from the enb falls below a threshold. The users continue to move inside the building while connected to their respective network modes until instant E is reached.

Fig. 5: M2E Latency performance with respect to number of users per team and communication modes for 20 runs.

Iii-B Experimental Results and Discussion

The simulations provide a contextual overview of the ptt use case with varying levels of traffic load and the need for adaptive network connectivity during a ps operation. We analyze the performance of the ptt scenario based on access time (at) and m2e latency.

Iii-B1 ibn performance

The cnl model decomposes and maps the intent components to service profiles and simulation parameters to be utilized by ns-3. The service type, end points and dependencies are translated into specific data models for the given service. For example, the ptt service provider has some mappings for the servers handling the information related to the ptt requests such as emergency call, group call, and one-to-one call, which are given in the form of service profiles to the intent processing model. The intent translation time varies between 20ms and 40ms depending on the type of intent defined during the processing phase, regardless of the service-specific parameters. This is orders of magnitude lower than the values observed for the access time for the ptt service.

Iii-B2 ps network and service performance

The simulation architecture provides the device and resource level exposure for the orchestration of ptt services to different rescue teams. After the ptt users generate the connectivity intent, the ps service provider now acts as an intent user and forwards the connectivity intent to acquire provisioning resources for different teams. The established connection provides the ability to switch amongst different network modes for providing the required access to all the teams in the network. Access time and m2e latency are measured for different users as they connect to the network using different modes with results depicted in Fig. 4 and Fig. 5, respectively.

Access time performance is visualized for different network modes and varying ptt user densities per team in Fig. 4

(a) with accompanying cumulative distribution function (CDF) in Fig.


(b). It is observed that on-network mode for team 1 performs the best, followed by the users from team 2 switching to off-network d2d mode as they move inside the building. Relaying-based access available to team 3 users performs the worst due to the bottleneck at the relaying UE causing significant variance. The performance of the off-network and relaying mode is also impacted by the change network mode. Fig.

4 (b) shows that 99 percent of users have an access latency bound of approximately 250ms and rare violations above it. The deviation from the observed range of at values increases with the density of ptt users per team due to queuing before the floor is granted.

m2e latency is observed to be within the range of the threshold defined by 3GPP [15] as shown in Fig. 5 (a). It is observed that on- and off-network M2E latency is stable with little deviations mainly attributed to the varying simulation attributes. In addition, the observed performance in relaying mode is mainly due to the transmission bottleneck from team 3 anchor node and the increased user density in the access network. Fig. 5 (b) shows that 90 percent of ptt users experience M2E latencies of 100ms or less and very few exceptions above 200ms. The saturation observed in M2E latency values for a higher number of users is directly proportional to the communication mode and the available resources in the simulation environment.


This paper studied the potential application of ibn in a ps ptt scenario resulting in provisioning and modification of services during the service lifecycle. ibn provides the basis for a flexible, scalable and service agnostic design of a network management solution. The service subscribers and providers define high-level abstract connectivity and reconnection intents, that are processed by the proposed framework. The service information is extracted from the intents and mapped onto low-level configurations deployed through a network controller to a public safety network. Simulation results show the possibility of incorporating user intents in the orchestration of services in coordination with different stakeholders with minimum impact on the access and M2E latency.


  • [1] A. Clemm, L. Ciavaglia, L. Z. Granville, and J. Tantsura, “Intent-Based Networking - Concepts and Definitions,” Internet-Draft draft-irtf-nmrg-ibn-concepts-definitions-02, Internet Engineering Task Force, sep 2020. Work in Progress.
  • [2] Y. Wei, M. Peng, and Y. Liu, “Intent-based networks for 6g: Insights and challenges,” Digital Communications and Networks, vol. 6, no. 3, pp. 270–280, 2020.
  • [3] K. Mehmood, H. V. Kalpanie Mendis, K. Kralevska, and P. E. Heegaard, “Intent-based network management and orchestration for smart distribution grids,” in 28th International Conference on Telecommunications (ICT), pp. 1–6, 2021.
  • [4] K. Mehmood, K. Kralevska, and D. Palma, “Intent-driven autonomous network and service management in future networks: A structured literature review,” arXiv preprint arXiv:2105.05594, 2021.
  • [5] K. Abbas, T. A. Khan, M. Afaq, and W.-C. Song, “Network slice lifecycle management for 5g mobile networks: An intent-based networking approach,” IEEE Access, vol. 9, pp. 80128–80146, 2021.
  • [6] 3GPP, “Telecommunication management; study on management aspects of communication services.” Available at (Accessed: 2021/10/20).
  • [7] ETSI, “Zero touch network and service management (zsm).” Available at (Accessed: 2021/10/20).
  • [8] ETSI, “Experiential networked intelligence (eni).” Available at (Accessed: 2021/10/20), 2020.
  • [9] R. Solozabal, A. Sanchoyerto, E. Atxutegi, B. Blanco, J. O. Fajardo, and F. Liberal, “Exploitation of Mobile Edge Computing in 5G Distributed Mission-Critical Push-to-Talk Service Deployment,” IEEE Access, vol. 6, pp. 37665–37675, 2018.
  • [10] M. Volk and J. Sterle, “5G Experimentation for Public Safety: Technologies, Facilities and Use Cases,” IEEE Access, vol. 9, pp. 41184–41217, 2021.
  • [11] J. Suomalainen, J. Julku, M. Vehkaperä, and H. Posti, “Securing public safety communications on commercial and tactical 5g networks: A survey and future research directions,” IEEE Open Journal of the Communications Society, vol. 2, pp. 1590–1615, 2021.
  • [12] “Technical committee (tc) terrestrial trunked radio and critical communications evolution (tcce),” 2020. Last accessed 15 Oct 2021.
  • [13] M. Bezahaf, E. Davies, C. Rotsos, and N. Race, “To all intents and purposes: Towards flexible intent expression,” in IEEE 7th Int. Conference on Network Softwarization (NetSoft), pp. 31–37, 2021.
  • [14] “3GPP TS 22.179 version 16.5.0: LTE;5G;Mission Critical Push to Talk (MCPTT);Stage 1,” 2020. Last accessed 11 Dec 2021.
  • [15] 3GPP Technical Specification 23.501 Release 16, “System architecture for the 5g system (5gs),” 2020. Last accessed 15 Oct 2021.
  • [16] T. R. Henderson, “Network simulations with the ns-3 simulator,” 2008.