# High Mobility 5G Services for Vertical Industries – Network Operator's View

Lechoslaw Tomaszewski, Ioannis P. Chochliouros, Robert Kolakowski, Slawomir Kukliński, Michail-Alexandros Kourtis

► To cite this version:

Lechoslaw Tomaszewski, Ioannis P. Chochliouros, Robert Kolakowski, Slawomir Kukliński, Michail-Alexandros Kourtis. High Mobility 5G Services for Vertical Industries – Network Operator's View. 17th IFIP International Conference on Artificial Intelligence Applications and Innovations (AIAI), Jun 2021, Crete, Greece. pp.71-84, 10.1007/978-3-030-79157-5_7. hal-03789004

HAL Id: hal-03789004

https://inria.hal.science/hal-03789004

Submitted on 27 Sep 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
High mobility 5G services for vertical
industries – network operator's view*

Lechosław Tomaszewski¹, Ioannis P. Chochliouros²[0000-0002-4208-1676],
Robert Kołakowski¹,³, Sławomir Kukliński¹,³, and Michail-Alexandros Kourtis⁴

¹ Orange Polska S.A., ul. Obrzeżna 7, 02-691 Warszawa, Poland

² Hellenic Telecommunications Organization (OTE) S.A., 99 Kifissias Avenue, 15124 Maroussi-Athens, Greece

³ Warsaw University of Technology, ul. Nowowiejska 15/19, 00-665 Warszawa, Poland

⁴ Orion Innovations P.C., Ameinokleous 43, 11744 Athens, Greece
lechoslaw.tomaszewski@orange.com

**Abstract.** The 5G System (5GS) is regarded as a multi-faceted, universal communication platform that could address the increasingly stringent requirements of both modern industries and network end users. Several proposed mechanisms, such as network slicing or its control exposure, aimed to facilitate access to the network for the external stakeholders, enable the creation of one common ecosystem that could be exploited according to the specific service needs. With the recent advancements in the automotive and aviation sectors, the significant increase of interest regarding the current state of preparedness of the 5GS and its capabilities to support those services is observed. The paper presents the analysis of the 5G technology readiness in the context of high mobility vehicular scenarios, including automotive and unmanned aviation use cases. The significant features and key gaps and challenges have been outlined with the emphasis on the dynamics of business processes and interactions between automotive, aviation and 5G ecosystems.

**Keywords:** 5G System · MEC · Vertical services · V2X · UAV · UTM · RAN · slicing · management · provisioning · architecture

# 1 Introduction

Since the early visions, the 5G System (5GS) has been presented as a versatile platform, able to build individualized communication solutions responding to the needs of very diverse and demanding use cases. The well known IMT-2020 triangle of fundamental use profiles at the vertices: enhanced Mobile Broadband (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC) constitutes a map of various use cases, which shows conceptually their relation to these profiles [1]. Furthermore, the Key Performance Indicators (KPIs) characterising the “promised” 5GS in comparison to the previous generation show serious gaps to be filled (30-50× in E2E

* Supported by the Horizon 2020 projects: EU-China 5G-DRIVE (Grant Agreement No. 814956) and EU 5G!Drones (Grant Agreement No. 857031).
latency, 100× in individual connection data rate and served terminals per area unit, 1.5× in terminal velocity). Today, after 5 years and with more than 100 commercial implementations of 5GS all over the world, the first reality check can be performed to validate the 5G technology maturity vs. the excited expectations. A very important aspect, which goes beyond the internal features of 5GS, is the ability to be adopted operationally by the network operator and by the business processes of the wider ecosystem in which it will be embedded.

One of the flagship applications of 5G networks in vertical industries are automotive and unmanned aviation use cases, which are highly demanding in terms of data rate, latency, reliability and mobility as well as subject to strict regulations. In addition, the ongoing COVID-19 pandemic has exposed their socio-economic importance to be much greater than previously expected. For these use cases, 5GS should not only be a static, focused only on itself, element of the overall landscape, but it must actively participate in various multilateral business processes. Thanks to the EU trial projects 5G-DRIVE and 5G!Drones, it was possible to recognize the broad context and needs of these industries, which challenge the 5G network and its operator.

# 2 Overview of the vertical industries in focus

## 2.1 Automotive sector

The automotive sector is rapidly gaining popularity on the market with the projected annual growth of 44.2% and is expected to expand from the market value of 689 million USD in 2020 to 12,859 million USD in 2028 [2]. Currently, the automotive market is built atop two communication technologies: WLAN-based Dedicated Short-Range Communications and cellular (LTE, 5G). Mobile communication systems are considered as the main drive of acceleration of Vehicle-to-everything (V2X) ecosystem development, due to better performance in terms of cybersecurity and handling large numbers of messages in congested traffic environments – the features being inline with core motivations of V2X, i.e. improving road safety, traffic efficiency and energy saving. These motivations are planned to be achieved by building the extensive Intelligent Transport System (ITS) allowing road users to acquire, share and use the information to support individual actions, and optimizing the road traffic flows.

<figure><img src="image_3.png" /><figcaption>Fig. 1. V2X ecosystem</figcaption></figure>
The V2X ecosystem (cf. Fig. 1) involves interactions of vehicles with other objects: network (V2N), infrastructure (V2I), grids (V2G), road-side units (V2R), devices (V2D), pedestrians (V2P) and other vehicles (V2V), each being a part of the ITS ecosystem. Typically, the V2X use cases are categorized as it follows [3]: (i) *Safety*: mechanisms for safety improvement (emergency braking, collision warning, lane change assistance, etc.); (ii) *Society and Community*: use cases of interest to the society and public (vulnerable road user protection, traffic light priority, crash reporting, etc.); (iii) *Convenience*: facilitation for drivers (information, assisted and cooperative navigation, autonomous smart parking); (iv) *Autonomous Driving*: semi-, fully-automated and remote; (v) *Vehicle Platooning*: creating dynamic groups of vehicles to exchange information and coordinate operations (e.g. maintenance of inter-vehicle distance); (vi) *Traffic Efficiency and Environmental Friendliness*: enhancements for traffic optimization (e.g. green light optimal speed advisory, traffic jam information, Smart routing); (vii) *Vehicle Operations Management*: operational and management use cases benefiting vehicle manufacturers (sensors monitoring, remote support, etc.). Demand for handling diverse service data with different Quality of Service (QoS) requirements causes 5GS to be projected as a leading communication technology for V2X systems. In addition to connectivity, 5GS can facilitate automotive services by hosting these systems on the Mobile Network Operator's (MNO) infrastructure as an integrated part of the 5GS, especially close to the edge of the network.

## 2.2 Unmanned aviation sector

The vast expansion of Unmanned Aerial Vehicles (UAV) services' market is commonly expected in all regions of the world (15.5% annual market value growth between 2019 and 2025, from 19.3 to 45.8 billion USD) [4]) due to the huge variety of UAV use cases in multiple economic areas. Further market acceleration can be achieved by overcoming the "Visual Line of Sight" flights barrier with an omnipresent communication platform, optionally with aid of "First Person View" (FPV) – real time 360° video for pilot. Hence, the 5G services supporting UAV operations are potentially a huge business opportunity for MNOs.

The unmanned aviation is a highly regulated sector, primarily due to safety, in terms of flight and airspace management. It is commonly accepted that the UAV ecosystem will be built around the UAV Traffic Management (UTM) system [5], which in EU will be developed as U-space, i.e. a framework of services and procedures for management of massive UAV traffic in a common EU airspace, to be implemented in 4 phases (U1-U4), gradually introducing new obligatory services within a common EU regulation (U1 in force since January 1st, 2021).

The U-space ecosystem [6] (cf. Fig. 2) – composed of multiple actors and entities – is founded on the U-space Service Provider (USP), i.e. an operator of a UTM system. To induce competition, there may exist more than one USP in a specific area. The USP's role is to provide services essential for coordinated flight planning, execution and control, which may be categorized as: (i) *Identification and Tracking*: registration, e-identification, position reporting and surveillance;
<figure><img src="image_4.png" /><figcaption>Fig. 2. U-space ecosystem</figcaption></figure>

(ii) *Airspace Management and Geofencing*: automated airspace areas access control; (iii) *Mission Management*: operation plan preparation, optimisation and processing, risk analysis assistance and dynamic management of airspace capacity; (iv) *Conflict Management*: pre-/in-flight conflict resolution; (v) *Emergency Management*: incident, accident and violations reporting; (vi) *Monitoring*: infrastructure monitoring, traffic control and lawful recording of all U-space inputs; (vii) *Environment*: weather, geo-spatial positioning, electromagnetic interference, navigation and communication coverage, and population density. 5GS functionalities can actively contribute to various USP services, so 5GS can be perceived as a part of USP, and its services and capabilities as “added-value” U-space resources. To enable support of massive UAV traffic, deep integration of both aviation and 5G ecosystems, including business processes, is advisable.

Last but not least, the role of 5GS is to provide the connectivity between U-space entities and actors, especially the communication links both for non-payload (flight-related, i.e. for UAV control and traffic management) and payload exchange (use case-specific, e.g. real-time video, still photos, sensoric data, etc.), meeting the QoS requirements. Additionally, the UAV actors’ systems can be distributed and hosted by the MNO’s infrastructure (especially at the edge).

# 3 3GPP 5GS support of vertical industries in focus

## 3.1 Approach to the requirements

V2X/UAV service requirements for 5GS are defined in [7]/[8], respectively. QoS KPI targets have been specified for various communication links necessary for both vehicle classes. In case of V2X, there is a non-payload communication only, compared to payload/non-payload context differentiation used for UAV. The top targets are more challenging in case of V2X by one order of magnitude (e.g. latency of 3 ms for emergency alignment of car trajectory vs. 10 ms for approaching autonomous navigation infrastructure by a drone; data rate of 1 Gbps for low-distance V2V sensor information sharing vs. 120 Mbps for airborne 4×4K
Artificial Intelligence (AI) surveillance; reliability of 99.999% for remote car driving control vs. 99.99% for FPV aid for pilot). Such approach is motivated by much higher proximity of automotive vehicles and their higher maximum speed (250 km/h vs. 160 km/h). Merely, the required horizontal positioning accuracy is comparable (0.1 m); for UAV it is specified only for payload.

Apart from the above requirements related to the quality properties of communication links, both sectors impose added-value functional requirements:

**Group communication:** it is required to enable communication between V2X objects in proximity, which expose V2X applications to others, including their discovery, either directly or via 5GS, with integrity and confidentiality kept, also between different Public Land Mobile Networks (PLMNs). In case of UAVs, this feature addresses broadcasting of drone's presence (identifier, location, flight azimuth and velocity) for collision avoidance in a small radius (600 m).

**Connectivity sharing:** enabled by detection of other V2X User Equipment (UE); the on-board UE may obtain network access via another V2X UE, when unable to connect to the network directly, with necessary confidentiality and integrity protection. While the feature is not demanded for UAVs, it might be used for sustaining the connectivity in the areas of poor coverage.

**Service assurance and provisioning:** both sectors request the 3rd party (V2X application, UTM system, etc.) ability to receive service monitoring information on per-UE basis, including early notification about possible QoS fluctuations or potential connectivity stopping. It is also required that the 5GS shall expose the information about service status (availability, estimated QoS) in a certain geographical area at a certain time, which is of premium importance for remote driving planning as well as for legally required UAV flight plan approval procedures. Additionally, in case of V2X sector, the support of negotiation of spatial/temporal connectivity QoS between the 3rd party and 5GS is required. This feature might be also useful in case of necessary flight plan alterations for on-going flights.

**User Plane (UP) data augmenting:** requested for UAV services; here, UP data packets sent to UTM are demanded to be additionally “certified” by PLMN with e.g. UE/subscriber identifier or UE location.

**Joint authorization:** UTM (generally: 3rd party) can be involved in UAV UE authorization to operate, i.e. admission to the specific communication network.

**UE capability validation and problems detection:** 5GS is required to identify and validate if UE has the UAV-specific capabilities, especially supports interactions of UAV with UTM. Additionally, 5GS shall support detection, identification and reporting of problematic UAV system components with on-board UE to UTM, including their abnormal behavior, e.g. flight area violation.

**Control take-over:** there is a requirement of the 5GS ability to enable UTM (or other lawfully authorized entity) to take over the communication used for UAV control. This requirement is related to the public safety issue; a problematic UAV may be forced to land or steered to a safe crash area.

**Identity handling:** the approach to this issue is extremely different. While in the V2X sector the privacy protection is fundamental [9] to avoid vehicle
tracking by its UE identity (pseudonymization required), the continuous aircraft identification and tracking is fundamental in the aviation.

The area of possible synergy of both sectors' high-level requirements is large. Apart from that, there are disjoint requirements, which may contribute as added value to the complementary sector, however. Only the last issue is contradictory. Hence, shared components should be expected, for architectural and operational reasons (reusability and common know-how for operation/maintenance).

## 3.2 Implementation of requirements – architecture and mechanisms

The generic vision of the 5GS architectural framework [10] envisions functionalities and mechanisms to support basic V2X/UAV requirements, i.e. related to providing communication links with specific QoS targets. Moreover, its inherent functional upgradeability provides means for implementation of “added-value” requirements. The features of 5GS, fundamental for the V2X/UAV support, are:
**Control and User Plane Separation (CUPS)**, i.e. Control Plane (CP) functions may be independently placed in a centralized location, while UP can be implemented at the closest possible location to the user or UP-supported application (e.g. for latency minimization), which further enables independent scaling of both planes, more flexible design, deployment and dimensioning of the network, and dynamic optimization of UP traffic distribution.

**CP programmability**, additionally boosted by its **Service-Based Architecture** (SBA), where 5GS-native Network Functions (NFs) and specific Application Functions (AFs) expose services as their Producers or discover/consume them as Consumers, within the RESTful framework (API) based on JSON (serialization), HTTP/2 (application layer), and TCP (transport).

**UP programmability**, i.e. UP Function (UPF) flexibly composed as a chain of atomic functions to process the UP traffic (e.g. firewall, Deep Packet Inspection, selective marking or altering, encapsulation, classification, forwarding or redirection of user traffic, anti-virus protection, parental control, etc.).

**Network slicing (NS)**, i.e. split of handling of various communication services with mutually conflicting requirements among separated specialized subnetworks (to be built on flexibly shared common resources), which are customized according to service specificity. Efficient customization of these sub-networks is further enhanced by CUPS and SBA. Slice-specific CP functions may be flexibly integrated with 5GS CP, using separation mechanisms of the CP communication bus. Slice-specific UP data processing chain – as a service-customized UPF. As UE may use applications demanding various communication services, the UE multi-slice attachment ability has to be supported.

**Embedded analytics** is included as Network Data and Management Data Analytics Functions (NWDAF in CP and MDAF [11] in the management layer, respectively), which expose analytics services to other functions. Their functionality include NFs data collection, processing, analysis and metadata exposure, including notifications of data-driven events (e.g. threshold- or condition-based).

**Location Services (LCS)** [12] framework, as the 5GS CP extension, enables providing target UE location information (geographic location, velocity, or civic
location), considering the security aspects. To enable privacy control, several me-
chanisms have been introduced, including aliases for UE anonymity maintenance,
restricted access by codewords, LCS clients whitelisting etc. The LCS framework
supports both UE-assisted and network-based (upgraded RAN nodes) location.
**Network control/management capabilities exposure** for external systems
integration is based on Network Exposure Function (NEF) located in CP and
Exposure Governance Management Function (EGMF) [11] located in the mana-
gement layer. For standardization of supported integration mechanisms at the
5GS North Bound Interface (NBI), additional Common Application Program-
ming Intertface Framework (CAPIF) [13] and Service Enabler Architecture Layer
for Verticals (SEAL) [14] have been defined.

4 Key gaps and challenges

The 5GS readiness to handle the services for high mobility applications is cur-
rently limited in many aspects, discussed below. Due to the 3GPP standardi-
zation timeline, the majority of them is still under development (either from
scratch or being enhanced) as a part of the Release 17 scope (further indicated
as R17). Therefore, vendors' solutions will be available well after the half of 2022
when the freeze of the 3GPP Release 17 is scheduled.

## 4.1 Network Slicing

NS is a fundamental enabler of majority of 5G services for the high mobility
applications. It concerns especially the UAV sector, where multiple non-payload
and payload communications links with drastically different characteristics may
be required. However, there are currently two factors to detain implementation
of NS: the migration policy adopted by MNOs and the current status of the
3GPP standardization<sup>R17</sup>. In Europe, all MNOs have chosen to implement 5GS
according to the Non-Stand Alone architecture, with at least the overwhelming
majority of the Option 3/3a/3x (cf. [15],[16]), so NS is not supported there, in-
herently. This approach accelerated the 5G technology implementation in Radio
Access Network (RAN), especially as in some countries new 5G bands are still
unavailable. However, it may have further negative effect by delaying the imple-
mentation of 5G Stand Alone architecture. Until then, 5G networks in Europe
will remain “boosted LTE networks” (with just higher data rates) without full
5G functionality and services support.

## 4.2 RAN mechanisms

5GS is expected to bring several RAN solutions to address diverse and ele-
vated transmission requirements implored by robustness of served communica-
tion types. Several mechanisms have already been introduced to the New Radio
(NR) both at physical and procedural level. The intensive work on development
of NR features is a major part of the 3GPP Release 17 and subject to its timeline.
**RAN slicing<sup>R17</sup>:** a fundamental NR mechanism to ensure QoS levels of Procol Data Unit sessions and their isolation, by means of L1/L2 scheduling and per-slice Radio Resource Management (RRM) policies [17]. Its support is only in scope of the 3GPP Release 17.

**Proximity Services (ProSe)<sup>R17</sup>:** a basis for direct UE-UE communication. So far, the preliminary studies have been published, outlining i.a. the key issues as discovery of UEs, relay support and charging aspects [18]. The essentials of the ProSe core element, i.e. Sidelink (PC5 interface), have already been defined [17].

**Minimization of Drive Tests<sup>R17</sup>:** a mechanism of acquisition of radio measurement data, which are inherently taken by UEs. These data might be further used for 3D network coverage optimization or be exposed to the vertical industry.

**Beam management:** essential mechanisms for interference mitigation. Some of them (beamforming, beam sweeping etc.) have been described for NR in [19], but the technology is still not mature enough to support URLLC use cases [20].

**Radio Resource Allocation mechanisms:** grant-free access for the uplink and preemptive punctured scheduling for the downlink [17], which enable skipping resource allocation negotiation procedures and mitigation of the related delay, critical for URLLC transmission. Other mechanisms may be added during the studies on URLLC enhancements for Industrial Internet of Things<sup>R17</sup>.

**Applications impact on RAN:** the O-RAN concept that introduces RAN programmability is of premium importance for V2X and UAV services, due to enabling of external applications impact on RAN mechanisms. The example use cases include: context-based (e.g. velocity, path) dynamic handover management for V2X, flight path-based on-demand dynamic resource allocation for UAV or radio resource allocation for UAV applications on per UE-basis [21].

## 4.3 Specific architectural support of V2X/UAV use cases

In addition to generic 5GS mechanisms, 3GPP addresses some aspects of service support for high mobility use cases to specialized architectural and application-layer solutions, individually defined for each of the vertical sectors in focus.

The specific support of V2X services is partially standardized within the 3GPP Release 16 and covers SEAL-based application layer issues (dynamic grouping; group communication – via PC5 or mobile network; file and application message distribution; and cross-PLMN PC5 communication) [22] and relevant 5GS architecture-level mechanisms (V2X communication, including its authorization, provisioning and QoS; V2X application server discovery and subscription) [23]. Further enhancements are in progress<sup>R17</sup> and the studies both for layers of application (extended QoS specific for V2X use case category – cf. section 2.1 – and automation level; tele-operated driving; network slicing and multi-PLMN support; connection relaying; enhancements of group communication and management; vehicle tracking, multi-V2X service provider support) [24] and 5GS architecture (QoS-aware power efficiency of PC5 for pedestrian UEs) [25] have recently been finalized.

The UAV-specific support has not been provided within 5GS, yet. Its first standardization is currently underway<sup>R17</sup>. The study reports on UAV connecti-
vity, identification and tracking (UAV and its controller identification, authoriza-
tion for operation and connectivity to UTM – commonly with UTM, pairing and
tracking) [26] and SEAL-based application layer support for the UAV ecosystem
(mechanisms of direct and on-network broadcast communication; network ca-
pability exposure and management related to QoS provisioning, UAV real-time
monitoring/locating/trajectory deviation tracking, UAV command and control
communication modes switching, real-time media session monitoring; UAV sys-
tems pairing and identification; and alignment of UAV and edge enabler layers)
[27] have recently been closed.

Although the solutions of finalized studies in both vertical sectors are only
proposals for further selection and validation during the normative documents
development, there is a fundamental difference in the architectural approach. It
is assumed that V2X Application Servers will be integrated with 5GS individu-
ally via NEF as V2X-specific AFs to interact separately with 5G CP. In case of
UAV sector, it is proposed to implement specialized shared function(s) to expose
5GS CP services to the UAV environment actors: drone operator, UTM or third
party authorized entities. Such approach follows the idea of a UAV ecosystem
gateway function [28], which is not only a mediator to expose generalized UAV-
related mechanisms through an API commonly used by these actors. Its role
is also to coordinate all their interactions with 5GS CP, to exploit functional
similarities in various interactions and contexts for simplification of the overall
architecture and to avoid excessive signaling exchange caused by same, multi-
plied requests (e.g. continuous, real-time UAV tracking for reporting to UTM
and drone operator, for position broadcasting, for mechanism of early warning
about possible connection loss and for autonomic trajectory deviation detec-
tion). However, from a global point of view, the defined solution proposals in
both sectors do not fully use the capabilities of the 5GS architecture – due to the
use of a uniformized approach for both 4G and 5G networks. It also seems that
the opportunities for architectural synergy of both sectors will not be exploited.

While the LCS framework is not dedicated exclusively to the automotive
and aviation sectors, some significant features tightly associated with UAV/V2X
applications, including LCS continuity aspect, low latency and high accuracy
positioning, positioning service areas etc., are still under development R17.

## 4.4 Multi-Access Edge Computing

The UAV/V2X Application Plane is expected to operate at the edge of the net-
work, therefore usage of ETSI Multi-Access Edge Computing (MEC) framework
[29] capabilities is deemed as an enabler for latency reduction and transport
network offloading. Whilst the latter is an indisputable advantage, the foremost
is questionable due to properties of virtualization technologies. Studies [30, 31]
show that each Virtual Machine (VM) or container impose significant latency
overhead due to sharing of physical resources and extra processing layers for vir-
tualization (~150-300 µs for working alone and even a few ms in heavily loaded
clusters by concurrent bandwidth-demanding VMs). Moreover, the paradigm of
high modularization and distribution multiplies the effect above and in turn
nullifies the time gain on infrastructure placement close to RAN (each 6 µs of
delay is the equivalent of ~1 km of fiber). Hence, MEC can be treated as a way
to compensate the losses caused by virtualization. The 3GPP standardization
of 5GS and MEC integration has been recently started<sup>R17</sup>, but there are still
unsolved concerns about the overall integrated architecture [32].

## 4.5 Agile management and provisioning architecture

Considering high mobility and latency-critical UAV/V2X services, the need for
efficient mechanisms of management and orchestration becomes a fundamental
issue, especially when responsiveness to service and traffic demand changes in-
troduces safety risks. While NS enabled by softwarization and virtualization is a
widely adopted vision, the dynamic slicing [33] – i.e. the dynamic and continuous
metamorphoses of the network, following the needs in a timescale of seconds –
still remains an open challenge, thus the need for extensive research.

3GPP adopts the ETSI Management and Orchestration (MANO) framework
[34] and designs the vision of the 5GS management as complementary to MANO.
Its centralized operation fundamentally increases the overhead related to slice
modification such as resource reallocation, and also raises significant concerns in
terms of scalability and efficiency. In the case of multi-domain hierarchical and
recursive orchestration, reconfiguration of stitched sub-slices would incremen-
tally intensify the issue. In [35], the results of time needed for slice instantiation
and scaling-out (which is only the final, actuating step of the entire process of
adaptive network transformation) have been presented. In case of small slices,
the first process consumed from around 15 s to 50 s depending on the slice size
(number of VNFs). The latter proved to be executable in approximately 15 s,
which may not be sufficiently fast to satisfy the soaring UAV/V2X requirements.

The initial step of the network adaptation process requires the appropriate
mechanisms for obtaining relevant input data from CP. While the generic SBA-
based 5GS CP architecture allows for the potential implementation of any ana-
lytical functions as AFs, the “turnkey” mechanisms to support V2X/UAV use
cases are of premium importance for carrier-grade implementation. The recently
finalized study [36] proposes new 5GS automation enablers (as new services or
capabilities of NWDAF) for e.g. optimized radio access technology/frequency se-
lection, anomaly detection and aiding its cause analysis, UE dispersion analytics,
UE movement patterns and traffic analytics, predictive mobility management,
and real-time data collection and analytics. Further mechanisms for so called
“context awareness” will need to be developed in the future. The research on
AI-driven management algorithms is also only at the beginning of the way (seve-
ral initiated EU research projects). Automation and autonomization of network
management (“self-managing networks”) in the 5G era is becoming an inevitable
necessity. MNOs are under constant pressure to reduce operating costs, so the
increase in the number of managed communication networks (in particular as a
result of slicing) must take place with the same staff.

Finally, it should be noted that the scope of the 3GPP vision of network
management, and therefore also of the 5GS integration with the ecosystems of
vertical industries, is very limited compared to the comprehensive vision of the telecommunications operator's processes and related information systems map by TMF [37]. The integration of telecommunications and vertical industry sectors must also include the integration at the level of operational processes. For example, flight feasibility check request cannot be comprehensively answered based only on some momentary status of 5GS, read out from CP or real-time management system. Other support systems have to be involved, e.g. configuration management, change management, planning management, etc. In case of emergency flight route replanning, the dynamics of the end-to-end interaction (from changed route feasibility check request through answer validation and provisioning request to report of successful completion of network reconfiguration) will be extremely high and the timescale of tens of second may be demanded. Therefore, a comprehensive reference architecture for integrating the cooperating ecosystems must be thoroughly thought out.

# 5 Conclusions

The participation of telecommunications operators in European projects has resulted in the understanding of the broad context of the needs of industrial sectors that are addressed to the telecommunications network. This is all the more important as the wide adoption of network virtualization and slicing will bring serious market disruption in the long term. Therefore, operators must give a proactive response to these changes, looking for new business opportunities in ground and airborne vehicular vertical industries.

This paper presents the current progress of 5GS development in the context of offered support for the vertical industries in focus. The preparedness of the network to meet the expectations has been evaluated on the basis of mechanisms that could facilitate vehicular use cases and with respect to the requirements established by the 3GPP in preceding standardization activities. From the operator's point of view, the 3GPP support for UAV/V2X services is still very limited mostly due to lack of implementation of NS as well as mechanisms that enable addressing the requirements for URLLC transmission (RRM, adaptive coverage improvement etc.). Considering characteristics and dynamics of vehicular services, a substantial gap exists with relation to mechanisms for direct UE-UE communication. The opportunities for architectural synergy and reusability of solutions for both sectors will not be exploited, probably. Moreover, the approach to deployments of latency-critical services at the edge of the network needs redefinition to enable mitigation of the delay overhead induced by virtualization process.

The aforementioned standardization limitations will probably be overcome by 3GPP in the next 1.5 years. However, a significant challenge beyond the scope of 3GPP interests are the mechanisms necessary for highly dynamic automated 5G network management and orchestration, as well as, in particular, full integration of operational processes through the integration of a broader spectrum of information systems of both sectors in focus than in the 3GPP vision.
The 5G technology was invented and defined to enable the implementation of new services (in particular, to meet the full requirements of the V2X and UAV sectors) – it is a paradox that it does not currently support them. This means that there is still a lot of work to be done to make the carrier-grade implementation of these services feasible.

## References

1. ITU-R: IMT Vision – Framework and overall objectives of the future development of IMT for 2020 and beyond (M.2083, Feb 2015)

2. Markets and Markets: Automotive V2X Market, https://www.marketsandmarkets.com/Market-Reports/automotive-vehicle-to-everything-v2x-market-90013236.html. Last accessed 30 Apr 2021

3. 5GAA: C-V2X Use Cases Methodology, Examples and Service Level Requirements, https://5gaa.org/wp-content/uploads/2019/07/5GAA_191906_WP_CV2XOTS_v1-3-1.pdf. Last accessed 30 Apr 2021

4. Markets and Markets: Unmanned Aerial Vehicle (UAV) Market, https://www.marketsandmarkets.com/Market-Reports/unmanned-aerial-vehicles-uav-market-662.html. Last accessed 30 Apr 2021

5. Global UTM Association: UAS Traffic Management Architecture, https://www.gutma.org/docs/GlobalUTM_Architecture_V1.pdf. Last accessed 30 Apr 2021

6. GOF USPACE Project: SESAR 2020 GOF USPACE Summary, FIMS, Design and Architecture, https://www.sesarju.eu/node/3203. Last accessed 30 Apr 2021

7. 3GPP: Service requirements for enhanced V2X scenarios (TS 22.186 V16.2.0, Jun 2019)

8. 3GPP: Unmanned Aerial System (UAS) support in 3GPP scenarios (TS 22.125 V17.3.0, Apr 2021)

9. 3GPP: Service requirements for V2X services (TS 22.185 V16.0.0, Jul 2020)

10. 3GPP: System architecture for the 5G System (TS 23.501 V17.0.0, Mar 2021)

11. 3GPP: Management and orchestration; Architecture framework (TS 28.533 V16.7.0, Apr 2021)

12. 3GPP: 5G System (5GS) Location Services (LCS); Stage 2 (TS 23.273 V17.0.0, Mar 2021)

13. 3GPP: Common API Framework for 3GPP Northbound APIs (TS 23.222 V17.4.0, Apr 2021)

14. 3GPP: Service Enabler Architecture Layer for Verticals (SEAL); Functional architecture and information flows (TS 23.434 V17.1.0, Apr 2021)

15. 3GPP: Architecture configuration options for NR (RP-161249, Jun 2016)

16. 3GPP: Study on new radio access technology: Radio access architecture and interfaces (TR 38.801 V14.0.0, Apr 2017)

17. 3GPP: NR and NG-RAN Overall description; Stage-2 (TS 38.300 V16.5.0, Mar 2021)

18. 3GPP: Study on system enhancement for Proximity based Services (ProSe) in the 5G System (5GS) (TR 23.752 V17.0.0, Mar 2021)

19. 3GPP: NR; Medium Access Control (MAC) protocol specification, (TS 38.321 V16.4.0, Mar 2021)

20. Li, Y. R., Gao, B., Zhang, X., Huang, K.: Beam Management in Millimeter-Wave Communications for 5G and Beyond. IEEE Access 8, 13282–13293 (2020). https://doi.org/10.1109/ACCESS.2019.2963514
21. O-RAN Alliance: O-RAN: Towards an Open and Smart RAN (White Paper, Oct 2018)

22. 3GPP: Application layer support for Vehicle-to-Everything (V2X) services; Functional architecture and information flows (TS 23.286 V17.1.0, Apr 2021)

23. 3GPP: Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services (TS 23.287 V16.5.0, Dec 2020)

24. 3GPP: Study on enhancements to application layer support for V2X services (TR 23.764 V17.1.0, Dec 2020)

25. 3GPP: Study on architecture enhancements for 3GPP support of advanced Vehicle-to-Everything (V2X) services; Phase 2 (TR 23.776 V17.0.0, Mar 2021)

26. 3GPP: Study on supporting Unmanned Aerial Systems (UAS) connectivity, Identification and tracking (TR 23.754 V17.1.0, Mar 2021)

27. 3GPP: Study on application layer support for Unmanned Aerial Systems (UAS) (TR 23.755 V17.0.0, Apr 2021)

28. Tomaszewski, L., Kołakowski, R., Kukliński, S.: Integration of U-space and 5GS for UAV services. 2020 IFIP Networking Conference, pp. 767–772

29. ETSI: Multi-access Edge Computing (MEC); Framework and Reference Architecture (GS MEC 003 V2.2.1, Dec 2020)

30. Oljira, D. B., Brunstrom, A., Taheri, J., Grinnemo, K.: Analysis of Network Latency in Virtualized Environments. 2016 IEEE Global Communications Conference (GLOBECOM), pp. 1–6. https://doi.org/10.1109/GLOCOM.2016.7841603

31. Sollfrank, M., Loch, F., Denteneer, S. Vogel-Heuser, B.: Evaluating Docker for Lightweight Virtualization of Distributed and Time-Sensitive Applications in Industrial Automation. IEEE Transactions on Industrial Informatics 17(5), 3566–3576 (2021). https://doi.org/10.1109/TII.2020.3022843

32. Tomaszewski L., Kukliński S., Kołakowski R.: A New Approach to 5G and MEC Integration. In: Maglogiannis I., Iliadis L., Pimenidis E. (eds.) Artificial Intelligence Applications and Innovations. AIAI 2020 IFIP WG 12.5 International Workshops. AIAI 2020. IFIP Advances in Information and Communication Technology, vol 585. Springer, Cham (2020). https://doi.org/10.1007/978-3-030-49190-1_2

33. Chochliouros I. P., Spiliopoulou A. S., Lazaridis P., Dardamanis A., Zaharis Z., Kostopoulos A.: Dynamic Network Slicing: Challenges and Opportunities. In: Maglogiannis I., Iliadis L., Pimenidis E. (eds.) Artificial Intelligence Applications and Innovations. AIAI 2020 IFIP WG 12.5 International Workshops. AIAI 2020. IFIP Advances in Information and Communication Technology, vol 585. Springer, Cham (2020). https://doi.org/10.1007/978-3-030-49190-1_5

34. ETSI: Management and Orchestration (ETSI NFV MAN 001 V1.1.1, Dec 2014)

35. Trakadas, P. et al.: Comparison of Management and Orchestration Solutions for the 5G Era. Journal of Sensor and Actuator Networks. 9(1), 4 (2020). https://doi.org/10.3390/jsan9010004

36. 3GPP: Study on enablers for network automation for the 5G System (5GS); Phase 2 (TR 23.700-91, V17.0.0, Dec 2020)

37. TMF Homepage, https://www tmforum.org/opendigitalframework. Last accessed 30 Apr 2021