5G communications have permitted the automotive industry to develop and test new
applications not possible with previous wireless technologies. Remote driving is considered one
of such applications, due to the ultra-low latency, high reliability or the bandwidth needed. The
objective of 5G-IANA is to demonstrate the viability of remote driving on real scenarios and the
capabilities that 5G may bring.

The 5G-IANA platform will permit to reduce latency as well as improve reliability, reduce costs
and improve scalability. The remote driving application is based on a web platform where,
through 5G, users can control the vehicle located in any place, connected from a browser.
For a safety driving, the vehicle is equipped with a front and rear camera which provide realtime video. This video is also used to implement a deep learning algorithm in object detection
trained to provide the user warnings related with traffic rules or obstacles on the road. In
addition, to increase driving safety, the vehicle is equipped with a laser that indicates the
distance between the vehicle and the obstacles.

For instance, there are a couple of scenarios where remote driving is useful:

• Industrial control: The first scenario aims at having the possibility of control an AGV
  located on a manufacturing company via 5G connection. This will allow to avoid
  accidents between people and vehicles due to the controller will be placed out of the
  operation zone.
• Transport in long journeys: The second scenario is related mainly in material transport
  but is also useful for other use cases. In case of long journeys, drivers would not need to
  stop the vehicle to rest. The remote driving control would take over from one driver to
  another, thus improving their service time.

In summary, remote driving aims to provide greater comfort to people when performing certain
types of activities that do not require human presence, such as taking the car from one place to
another, picking up another person or delivering objects. This NetApp can cause a great impact
on the transport industry, since it can be adapted to large vehicles to transport material to sites
in dangerous areas, transport dangerous substances, transport goods to places that are far
away. Automotive industries enabling such a NetApp would safeguard the safety of the driver,
thus saving resources, and in the case of long journeys they would not need to stop the vehicle
for the driver to rest, but would simply be taken over by another operator, thus improving their
service times.

5G technologies are becoming of primary importance to boost the Automotive market segment, where new advanced 5G-powered services can be introduced by third parties/SMEs that would like to exploit network performances together with end-to-end automations for such services’ provisioning. Indeed, network slicing, Multi-access Edge Computing (MEC) and dynamic orchestration of resources are recognized as important platforms’ capabilities to enable the automated deployment of Vertical services on top of 5G-enabled infrastructure.

In particular, MEC is one of the most important technical aspects to be considered in Vehicle-to-Everything (V2X) use cases, especially concerning strict performance requirements in terms of low latency and high reliability. Through the adoption of MEC, computing and storage resources can be moved out of the remote cloud and closer to end-users and data sources to meet the desired QoS requirements. Indeed, V2X use cases may bring different requirements, e.g., vehicle movement and hazard notification services are usually latency demanding, while infotainment and AR/VR services require high Uplink (UL)/Downlink (DL) throughput. One of the major challenges consists in how services running in the MEC should be designed to achieve the expected performances. The functionalities of the target service that require processing at the edge should be identified to enable a near-real-time exchange of information with the User Equipment (UE). Moreover, V2X use cases highly influences edge computing architectures due to the complex nature of targeted scenarios, where multiple vehicles, from different manufacturers, and other devices (e.g., sensors, actuators, smartphones etc.) should coexist and connect to the same infrastructure.

With respect to previous architectures, edge computing introduces a shift towards three-tier deployments, where UEs (i.e., client-side components) are expected to communicate with Application and Network Functions (AFs/NFs), i.e., service components, potentially distributed across edge and central cloud locations. In beyond 5G networks, a further challenge that 5G-IANA aims to address consists in extending the deployment of AFs/NFs to the UE side, which in V2X use cases means the integration of orchestration-enabled On-Board Units (OBUs) and Road-Side Units (RSUs) (see Figure). According to ETSI MEC002 [], on one hand, the possibility of executing AFs/NFs on top of OBUs brings an enhanced contextual awareness by exploiting radio network, location, and/or other information relevant to the changing environment during journey time. On the other hand, the fluctuation of connectivity conditions together with its possibly limited compute resources (i.e., processing, memory and storage capabilities) may impact the efficient management and orchestration of such AFs/NFs.

Figure 1: Form a three-tier deployment (client-edge-remote cloud) towards the orchestration of AFs/NFs on the client side

The solution adopted in 5G-IANA foresees the integration of Kubernetes as lightweight orchestration framework on top of OBU/RSU hosts. The 5G-IANA Automotive Open Experimental Platform (AOEP) coordinates the Lifecycle Management (LCM) of AFs/NFs deployed at the OBU/RSU’s Kubernetes cluster, facilitating the deployment of more extensive service-chains across multiple edge and far-edge locations. With respect to the potential discontinuity of mobile connectivity, 5G-IANA investigates different mitigation solutions: i) the execution of graceful roll-back procedures in case of LCM operation failures due to a connectivity issue, ii) the forwarding of notifications through the vehicle Human Machine Interface (HMI) for taking over the control of the vehicle, e.g., in case of vehicle movement services, and iii) the design of distributed service-chain to have potentially independent sub-chains running on top of OBUs/RSUs, then for which is not mandatory to exchange data with service components running at the edge and/or central cloud. In addition, the AOEP executes a service-driven selection of OBUs and RSUs. The platform will provide a subscription functionality to create a data base of registered OBUs and RSUs that can be used to execute AFs/NFs. At the same time, a continuous resource discovery is applied to determine which OBUs are currently available in a given coverage area to perform LCM operations. The selection of OBUs and RSUs can be performed taking into account various parameters, including the ones specified by the Service Provider, e.g., the expected coverage area, for which the vehicle trajectory should be considered, and/or host-specific capabilities like the availability of data-sets for training/profiling, availability of connected sensors/actuators etc.

Author: Francesca Moscatelli.