When it comes to the cars of the future, autonomy will hardly translate to self-sufficiency. Vehicles will indeed be able to drive by themselves, but the vision for future of mobility is far from a set of independent automated entities. Rather, all the involved actors (including cars, public transports, pedestrians, and connected objects) will greatly benefit from being connected to each other and to the network. Continuous information exchange is in fact be the key to extending the perception of each vehicle beyond the range of their on board sensors, and to a larger scale to cooperatively improve traffic safety and efficiency.
The 5GCAR project aims specifically at researching the tools, protocols, and techniques to support Vehicle-to-Everything connectivity, based on 5G networks. In this article, we present the work activities on the V2X system and architecture, which is the result of the cooperation of a group of researchers working for prestigious universities, as wells as for larger corporations and smaller enterprises.
As illustrated below, the system architecture work package in 5GCAR overarches and builds on top of the connectivity solutions designed by the radio interface work package, by including management of traffic flows, multi Radio Access Technology (RAT) connectivity and inter-operator communications. Plus, core networks aspects are studied, including the management of links via Software Defined Networking (SDN), the placement of virtualized network functions, and network slicing. In addition, security and privacy matters, both involving direct and network supported communications, are studied.
The research on the V2X system and architecture revolves around 5 major areas of action, notably “network orchestration and management”, “network security”, “multi-connectivity cooperation”, “edge computing enhancements”, and “network procedures”.
Network orchestration and management
Network orchestration and management includes all of the operations necessary for the efficient deployment and automation of network functions necessary to support V2X communications. 5GCAR identified the Infrastructure as a Service (IaaS) as a key concept for effective network orchestration, using Software Defined Networking (SDN) and Network Function Virtualization (NFV) technologies to allow dynamic deployment of ITS services according to the geographical area where the car is.
Network security
Security breaches can have potentially harmful repercussions on vehicular applications, hence they are a subject of careful study in 5GCAR. Two different solutions are envisaged for the security and integrity check of vehicular messages, respectively applying the security checks in the UE (at application layer), and exploiting the presence of the network. The former approach is capable of working in a distributed manner, whereas the latter exploits the presence of the network to provide robust security.
Multi-connectivity cooperation
Vehicular services are expected to exploit infrastructure-based (Uu) links as well as direct Vehicle-to-Vehicle (sidelink) links. These two links have different characteristics and consequently are associated to different features. For instance, the sidelink is expected to provide better resource efficiency, lower latency, and out-of-coverage support. On the other hand, Uu is expected to offer higher reliability and higher data rates. 5GCAR identified that the exploitation of only one communication link might not be sufficient to meet the requirements of complex V2X applications. In addition, environments with the availability of multiple RATs are considered, thus extending the aforementioned challenges, considering that each RAT has its own distinctive features.
Edge computing enhancements
Availability of computing capabilities at the edge of the network, also known as Multi-access Edge Computing, is critical to support vehicular use cases. In order to take fully advantage of edge computing, enhancements are needed, both from a core network, and radio access network perspective.
5GCAR proposes enhancements to the management of jobs running on edge computing servers for highly mobile vehicular UEs. Specifically, when a vehicle is predicted to hand over from a base station connected to one MEC server to a new base station connected to a different MEC server, the pending jobs are pre-emptively transferred to the new one, with the purpose of minimizing any job interruption caused by the handover. 5GCAR also considered approaches where edge computing capabilities are jointly used with millimeter waves (mmWave) capabilities to allow the optimization of radio access resources, and simultaneously taking into consideration the offload of computing tasks.
Network procedures
The delivery of services in a mobile network involves a multitude of network procedures, spanning from connectivity establishment, to mobility management, and user plane management, just to mention a few. Such procedures impact the effectiveness of service delivery (e.g., some procedures might introduce latency) and such issues are exacerbated in vehicular environments. 5GCAR identified challenges that are not only limited to vehicle mobility, but also related to roaming, localized traffic and exchange of service requirements which extend legacy Quality of Service (QoS) parameters.
In total, fourteen technical components were presented across the five areas. In the effort to integrate them, and to support a potential implementer in choosing the right technical component to support a specific V2X use case, a study of their impact on the architecture was performed.
From the illustration above, one can determine which network functions and entities are involved by any given WP4 technical component.
Network slicing
Network slicing is a key enabler for supporting with a single infrastructure the multitude of diverse classes of automotive services, which are offered by different actors. This diversity implies that in 5GCAR, vehicular UEs will be connected at all time to several network slices, each serving a specific use case, offered by a certain tenant. The illustration below provides an example of this, including three different actors, and depicting the three main geographical locations wherein network functions will be deployed, notably the Radio Access Network, the Edge cloud, and the central cloud.
In this example, three tenants are involved: the telecom operator, the road operator, and the automaker, all of which offer different services to the vehicle and to the passengers it carries.
The operator, in fact, sets up a eMBB (evolved Mobile Broad Band) slices, which is meant to carry infotainment traffic and in general the best-effort on board connectivity. The road operator, on the hand, focuses on safety-critical services, which require one uRLLC (ultra-Reliable Low Latency Communications) slice, wherein the network functions are located on the edge cloud, in order to shorten the data path and reduce latency to a minimum. Finally, the automaker is assumed to offer two very different types of service, i.e. remote maintenance, and remote driving, which require the definition of two separate slices. Remote driving is a resource intensive and time critical application, that needs to simultaneously support a real-time video or sensor data flow in uplink, and a reliable real-time delivery of vehicle trajectories on the downlink. For this reason, one uRLLC-type slice is required. On the other hand, remote maintenance is about collecting data about usage from vehicles’ component, in order to arrange the maintenance of fleets of vehicles. This type of traffic consists mainly of sporadic transmission of small packets from large number of UEs, and due to their confidentiality they need to be separated from other traffic flows.