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. 