On the Needs and Requirements Arising from Connected and Automated Driving

Abstract

Future 5G systems have set a goal to support mission-critical Vehicle-to-Everything (V2X) communications and they contribute to an important step towards connected and automated driving. To achieve this goal, the communication technologies should be designed based on a solid understanding of the new V2X applications and the related requirements and challenges. In this regard, we provide a description of the main V2X application categories and their representative use cases selected based on an analysis of the future needs of cooperative and automated driving. We also present a methodology on how to derive the network related requirements from the automotive specific requirements. The methodology can be used to analyze the key requirements of both existing and future V2X use cases.

1. Introduction

Efficient support of cooperative and connected V2X applications is an important step towards the further improvement of advanced driver assistance systems (ADAS) and a key enabler for automated driving. These applications rely heavily on cooperation between vehicles and their interactions with other road users, infrastructure, and remote servers, in order to optimize the driving decision-making and improve the reliability. The aim of these new applications is to increase traffic safety and efficiency and enhance driving comfort and convenience. However, such applications introduce new challenges and impose stringent requirements on communication performance, especially in terms of latency and reliability, due to their safety-critical nature. A solid understanding of the emerging V2X use cases and their associated requirements is a fundamental prerequisite in order to efficiently address the challenges and design new solutions.

First analyses of automated and cooperative driving use cases, in the cellular context, have been already initiated by the Next Generation Mobile Networks (NGMN) Alliance [1] and the 5G Infrastructure Association (5G-IA) through the Public Private Partnership (5GPPP) white papers on the automotive sector [2]. The 3rd Generation Partnership Project (3GPP) also identified and studied a broad range of V2X use cases. First, in the 3GPP Technical Specification (TS) 22.185 [3], where the focus was on the first release of the European Telecommunications Standards Institute (ETSI) Intelligent Transportation Systems (ITS) use cases and requirements covering basic safety and traffic management scenarios [4]. Subsequently, a following document, named TS 22.186 [5], was developed to cover the requirements for more advanced use cases such as platooning, use of extended sensors, advanced driving and remote driving. These use cases introduce more rigorous functional requirements for advanced features as well as more challenging performance requirements. In addition, the second release of the ETSI ITS specification has recently started. Furthermore, 5G automotive association (5GAA) (5GAA is a global, cross-industry organization of companies from the automotive, technology, and telecommunications industries (ICT), working together to develop end-to-end solutions for future mobility and transportation services.) [6] is also currently working on the definition of use cases and requirements.

More recently, the 5G Communication Automotive Research and innovation (5GCAR) project [7,8] brought together a consortium of partners from the automotive industry, the mobile communications industry, and academia to conduct research at the intersection of those sectors to support safer and more efficient future driving. One objective of the project was to identify the use cases that are needed for advanced driving and their associated requirements, from the perspectives of both automotive applications and communication networks.

In this paper, we summarize and extend the key findings of the 5GCAR project in terms of use cases that form building blocks for connected automated driving. To the best of our knowledge, this is the first paper that relates the requirements on the communication network to the actual requirements from the automotive applications. The main contributions are as follows:

• We identify a set of representative use cases that are based on an analysis of the demands arising from connected and automated driving.
• We study the selected use cases in more detail to identify the corresponding challenging requirements and derive the key performance indicators (KPIs).
• Based on the identified use cases and requirements, we discuss the existing V2X technologies and solutions, and point out valuable future research directions for satisfying the stringent requirements.

The rest of the paper is organized, as follows. Section 2 discusses the future needs that arise from connected and automated driving and proposes a classification of the related novel V2X applications. Section 3 describes five representative use case classes that have been elaborated in 5GCAR and will contribute to making the vision of connected and automated driving become a reality. Section 3 also translates the technical requirements from the automotive domain into requirements for the telecommunication network. Section 4 proposes a methodology for deriving the requirements on the communication systems from the automotive requirements, which is then applied to specify the requirements for the selected use cases. Section 5 draws the perspective between the use case and requirements previously identified and the one defined by the community, principally 3GPP and the 5G Automotive Association (5GAA) [6]. Section 6 reviews related work and future research challenges. Finally, Section 7 concludes the paper.

2. The Future Needs of Connected and Automated Driving

In [9], six driving automation levels have been defined, where higher automated driving levels require the increase of the automation of the vehicle functions while reducing the active involvement of the driver. This development will lead to fully automated driving systems that will, with increasing automation level, gradually allow for the driver to remain completely out of the loop, while vehicles are expected to take over the complete driving task. To achieve this vision, several key capabilities need to be implemented in the vehicles to handle the significant driving scene complexity that might be encountered in different situations. This includes the capability of a vehicle to center itself within the lane and control its trajectory and speed by performing automated steering interventions. However, the vehicle has to perform a continuous sensing of its surrounding to maintain a complete awareness of its environment to be able to make reliable decisions on the best appropriate actions. This is achieved through a combination of information obtained from multiple local sensors, e.g., radar, cameras, etc., which are necessary for generating a complete and reliable vehicle environmental model. This process of sensor data fusion from various sensors to create surrounding awareness is known as perception. The local on-board sensors field-of-view is often limited to line-of-sight (LOS), but it can be complemented by the information received from other vehicles, roadside infrastructure, or from a back-end server through wireless links. Such sensor data shared by other vehicles can be used to extend the vehicle field-of-view beyond the LOS, resulting in “behind-the-corner” extension of perception and a 360-degree reliable environment model.

Beyond the extended environmental perception, fully automated vehicles will require up-to-date and high definition map information, e.g., including road descriptions and context information. Such services could be provided, for example, from a cloud server and would enable the vehicle to navigate intelligently and safely through different types of environments. As part of the automated driving tasks, a vehicle also needs to be able to perform appropriate maneuvers, such as automated lane changing and collision avoidance. To this end, communication with the surroundings and cooperation with nearby vehicles becomes more relevant. Moreover, such cooperation enables the execution of joint maneuvers that increase the road safety and help the vehicles navigate through difficult traffic situations. In addition to cooperation with other vehicles, the detection of vulnerable road users, such as pedestrians, bicycles, and motorcycles, helps in reducing the traffic accidents by providing early notifications regarding potential collisions and avoidance through appropriate maneuvers. In this regard, the accurate localization of the vehicles and the vulnerable road users is a fundamental capability that needs to be developed. Finally, remote driving is another use case that that can assist progression to higher automation levels. Remote driving can be realized by having a remote operator monitoring and controlling the vehicle movements, e.g., via a cloud server, and ready to intervene as the need arises in order to assist the vehicle or the driver through appropriate maneuvers that increase the road safety and efficiency. The information that is shared from different sources, e.g., nearby vehicles, road infrastructure, and map servers, is expected to provide a form of redundancy that is needed for increasing the reliability of the automated driving systems.

3. 5GCAR Use Cases

A set of diverse functionalities, which rely on telecommunication systems providing vehicles with connectivity to other nearby vehicles, road users, and to the network infrastructure, enables automated driving. Each specific use case will require some of these functionalities and, most likely, not all of them with the same level of importance.

The 5GCAR project has classified these functionalities into five use case classes in order to analyze the required functionalities for each use case: (1) “cooperative maneuvers”, (2) “cooperative perception”, (3) “cooperative safety”, (4) “intelligent autonomous navigation”, and (5) “remote driving” [10]. These use case classes are briefly discussed in

Table 1. Brief description of 5G Communication Automotive Research and innovation (5GCAR) use cases.

Use Case Class	Description
Cooperative maneuvers	Traffic safety and efficiency is improved by the coordinated movement of a group of vehicles. This is achieved with the exchange of information among nearby vehicles or with the roadside infrastructure via wireless communication.
Cooperative perception	Using on-board sensors and information from nearby vehicles and the infrastructure it is possible to extend the perception range beyond the line-of-sight and local-field view of a vehicle.
Cooperative safety	Detection of road users (e.g., pedestrians and cyclists) is improved and enabled by using their handheld devices in combination with information from vehicle on-board sensors and the communication system.
Intelligent autonomus navigation	The acquisition of an HD local map is enabled for optimal route selection using long-term (e.g., road conditions) and short-term (e.g., collision avoidance) planning information.
Remote Driving	Remote control of car actuators by a human operator or an application server is enabled, to partially or fully automate driving tasks for safety, convenience and efficiency.

and further described, as follows.

Cooperative maneuvers is a class including use cases for coordinating the driving maneuvers and optimizing the decision making for a group of vehicles. It is based on the principle of sharing local vehicle information and driving intentions and negotiating the planned trajectories. The information is exchanged between nearby vehicles, or with the roadside infrastructure via wireless communication, and it is used to coordinate the driving trajectories of the considered group and optimize the driving decisions in a centralized or a decentralized manner. This involves potential negotiations, including the exchange of planned or preferred trajectories among vehicles, and possible joint optimization of trajectories. Examples of use cases in this use-case class include convoy driving, cooperative intersection management, and cooperative lane changing.

Cooperative perception is about extending the vehicle perception range beyond the line-of-sight and local field-of-view and sensing angles. It is built on the basis of merging local data collected from different on-board sensors, such as radars, laser, and stereo-vision sensors with remote information being obtained from nearby vehicles and/or from the infrastructure. The resulting perception scenes can be communicated to the automated vehicle or to the driver in the form of see-through, bird’s eye view, sensor and state map sharing, or three-dimensional (3D) video composition.

Cooperative safety includes use cases wherein information is exchanged with the purpose of detecting other road users, e.g., pedestrians and cyclists, and preventing the occurrence of accidents. Various methods are applied to detect vulnerable road users, including on-board sensors, cameras, radars, and communication systems. In contrast to cooperative perception, where communications are between nearby vehicles or with the infrastructure, cooperative safety relies on communications to and from the handheld communication devices that are carried by pedestrians and cyclists. Some examples of use cases in this category are traffic light violation warning or vulnerable road user warning.

Intelligent autonomous navigation includes use cases aimed at building and distributing real-time intelligent high definition (HD) maps, which enable optimal route selection for vehicles of higher levels of automated driving. This includes the aggregation of the information collected from vehicle sensors (e.g., in case of cooperative perception) and the delivery of map updates with very precise context information (e.g., road structures, reference objects for localization, etc.). The map data assembly and the distribution of the localized HD map to the vehicles is performed based on the vehicles’ locations and, thus, rely on the accurate real-time localization, which is one prerequisite for enabling this type of services. Emergency trajectory alignment and traffic flow optimization are examples of use cases that belong to this class.

Remote driving refers to controlling the different actuators of the car (steering wheel, brake, and throttle) from outside the vehicle through wireless communication. The goal is to enable remote driving of the vehicle by a human operator or an application server, in order to provide more safety, convenience, and efficiency, as well as partially or fully removing the driving task from passengers or vehicle itself. For this purpose, it is necessary for the remote driving controller to receive perception information (e.g., vehicles sensors and local dynamic maps) and, if possible, also data from road infrastructure. The remote driving use case class provides a feature to fill the gaps between a highly automated vehicle and a driverless vehicle. When the automated vehicle faces a complex situation, a remote entity can take the control to drive the car. Remote driving is the most challenging use case family in terms of network requirements, due to the high needs in terms of reliability and reaction time (low latency). Public transport remote driving, remote driving for the last mile delivery, or automated parking are examples of use cases that represent this class.

In the following subsections, one representative use case has been selected and studied in more detail to illustrate the needs and particular requirements of each class of applications.

3.1. Lane Merge Coordination

The lane merge coordination use case belongs to the class of cooperative maneuvers. The goal of this use case is the sharing and coordination of driving trajectories among a group of vehicles to improve the traffic safety and efficiency. A subject vehicle (e.g., Veh₁ in Figure 1) that plans to join a main lane is coordinated with remote vehicles driving on the main lane in order to merge smoothly, safely, and with minimal impact on the traffic flow. The trajectory recommendations are computed based on vehicle position, orientation and speed, being continuously transmitted by the connected vehicles. It is necessary that the system considers non-connected, i.e., non-communicating, road users, since it cannot be assumed that every road user is connected to the network. For the external observation of road users, a camera system is installed at the road infrastructure next to the lane merge location [11]. All road users (connected and non-connected) are localized and identified by the camera system. The estimated road user attributes, such as position, orientation, and speed, are transmitted to the data fusion function, which merges data that originated from the camera system and from connected road users. The lane merge coordination function analyzes the road situation and continuously provides trajectory recommendations for the connected vehicles while considering the behavior of unconnected vehicles with the aim of an optimal lane merge process.

3.2. See-Through

The see-through use case belongs to the class of cooperative perception. Its goal is the exchange of data regarding detected objects and real-time video between nearby vehicles via wireless communication. Such information is particularly beneficial to facilitate safe overtaking maneuvers where a vehicle requests the support of the vehicle in front of it (e.g., a truck), for the purpose of extending its local perception (e.g., detecting other vehicles from opposite direction that are not directly visible to the vehicle in the rear), as shown in Figure 2. The scene in front of the vehicle ahead is captured by a camera and transmitted to the rear vehicle to allow it to see through the front vehicle and bypass the occluded area. The see-through application requires an estimation of the relative position between the two vehicles referencing systems to relate their local perceptions to a common spatial reference in a consistent way. For this purpose, a sparse real scale 3D map is first computed from the front vehicle while using a fast stereo Visual Odometry (VO) approach, as described in [12]. Subsequently, the pose of the rear vehicle is estimated in this 3D map using two-dimensional (2D)–3D feature tracking. A dense disparity map is computed at the stereo vision system of the front vehicle in order to generate a synthetic image of the occluded area of the rear vehicle image. Based on that, the video data representing the region of interest is transmitted to the rear vehicle, which performs appropriate cropping of the received video and stitches it on the current view. The video data transmission is ended with the completion of the maneuver.

3.3. Network-Assisted Vulnerable Road User (VRU) Protection

Vulnerable road users are the category likely to suffer the worst outcome in case of road accident, as suggested by their evocative denomination. Thus, it is of paramount importance for vehicles to be able to detect them, even when their location is out of the reach of the onboard sensors. The goal of this use case is to improve the safety of vulnerable road users, such as pedestrians and cyclists, through improvements in localization, movement prediction and collision detection enabled by the network infrastructure, as depicted in Figure 3. Thanks to the exchange of information between users via wireless communications, the overall system will determine the VRU position based on cellular radio signals, GNSS, or sensor/camera data. All of this location information will be processed from multiple users to generate alerts to vehicle drivers or automated vehicles with highly accurate positioning. The network infrastructure provides both the position of the pedestrian and a collision warning to the vehicle to avoid the collision.

3.4. High Definition (HD) Local Map Acquisition

The high definition local map-acquisition use case belongs to the class of intelligent autonomous navigation, as shown in Figure 4. The goal is to have a high definition, real-time, and precise local dynamic map that is updated on the move to allow optimal route selection. More precisely, the optimal route selection for an autonomous vehicle relies on long term planning, i.e., learning about the possible routes, traffic, and road conditions, and the short-term planning, such as lane changes, overtaking, and collision avoidance. The long-term planning requires static and dynamic map information on a large scale to learn about the possible routes, traffic, and road conditions. In its turn, the short-term planning requires information from a precise local dynamic map. An off-board system that collects data from different sources builds an optimal route map. The data is structured into different layers, also called layers of dynamics, including the map provider layer (static layer) and the layer of cooperative sensing of the different vehicles (temporary/dynamic layer). The collected data are processed and divided into polygons before being distributed by push/pull methods to the vehicles. Poll methods are used on a regular basis (periodically). The push methods are based on updates that are triggered by major changes or hazardous events.

3.5. Remote Driving for Automated Parking

Automated parking is an exemplified use case of remote driving. Its goal is to remotely drive a vehicle from the “last mile” near a parking to the parking spot without a human driver inside the car. More specifically, the remote cloud server provides the vehicle with the appropriate trajectory and maneuver instructions for efficient and safe parking. To do so, the vehicle and the remote cloud server should be mutually authenticated for sharing video and sensor data. Moreover, the vehicle should have enough perception capabilities and allow access to its actuators. In addition, the vehicle should be able to communicate with the cloud server. Last but not least, the parking area needs to be equipped with sensors and/or cameras that facilitate the remote cloud server decision for optimized trajectories. During remote driving, the vehicle first collects relevant data, including sensor information, vehicle status, and video streaming images, and then continuously transmits them to the cloud server. Based on the received information from both vehicle and parking facilities, the remote cloud server calculates the driving commands (including steering, speed, and acceleration) and sends them to the vehicle. Subsequently, the vehicle executes the driving commands accordingly. An example is illustrated in Figure 5.

4. Technical Requirements: from Automotive to Network Perspective

Two types of requirements need to be considered when discussing connected automated driving: automotive requirements and network requirements. Automotive requirements stem from the use cases that need to be enabled and relate to various functional aspects of those use cases. The network requirements specify the required performances of the communication system, which shall be tightly coupled with the automotive requirements.

In addition to the automotive and network requirements, there are other qualitative or functional requirements that are relevant for practical vehicular applications. Examples of such requirements are as follows:

• Power consumption: represents the amount of power that a specific application consumes. Power consumption is generally not an issue for applications executed within vehicles, unlike the case of other types of mobile devices (e.g., mobile phones).
• Cost: in the case of vehicular applications, cost can be expressed in terms of the monetary cost or, alternatively, in terms of network resources that are required to execute the application.
• Safety: relates to the capability of vehicular applications to reduce the probability of hazardous events and the ability to bring the system always back to a failsafe state.
• Security: relates to the methods that are implemented in the application to prevent unauthorized users from accessing the application itself or the information generated by it.
• Privacy: relates to the methods implemented in the application to protect the sharing of user’s private information. This includes, for example, preventing tracking the user real-time location and trajectory.

In the following subsections, we first define the automotive and network KPIs; then, we discuss on the interrelations between them. Finally, we elaborate a requirement analysis for five particular use cases that have been studied in detail within the 5GCAR project.

4.1. Definition of KPIs

From an automotive perspective, it is possible to identify the following types of requirements and key performance indicators (KPIs):

(1) 

Completion time denotes the time that is needed to complete a certain vehicle activity. For a specific maneuver, the completion time specifies the total time it takes from when the maneuver is initiated until it has been completed. In terms of the see-through use case, the completion time takes the form of overtake time, the amount of time taken to perform the overtaking maneuver, whereas intersection crossing time represents the completion time for crossing the intersection safety [13] or lane merging procedure into the highway.

(2) 

Localization accuracy is used to specify the needed geographical position accuracy. The localization error is defined as the distance of a measured position to the ground truth position. Additionally, the confidence limit is considered, often being selected as 95% [14].

(3) 

Inter-vehicular time is the recommended/required distance to be kept between two vehicles. It depends on regulatory requirements (traffic safety) and business requirements (traffic efficiency) [15].

(4) 

Mobility is defined as the velocity (speed and heading) at which an object is moving with respect to a reference object or a geographical point. The maximum relative velocity between the objects is considered if the reference object is also moving [16].

(5) 

Relevance area is defined as the area where the messages have to be distributed to ensure the automotive service. The relevance area is application-dependent.

The automotive KPIs set boundary conditions for the top layer network KPIs, which we refer to as the application layer. The application layer KPIs are then broken down into the requirements on lower layers. However, this process is implementation-specific; for simplicity, we limit the discussion to application layer KPIs.

From the communication network perspective, it is possible to set the focus on the following requirements:

(1) 

Maximum service data unit (SDU) size is the maximum size of payload that is required by a specific service and generated by the application.

(2) 

Latency is the time from when an SDU is requested to be transmitted by an end-node application until it is made available to the other end-node application. In case an SDU is not delivered, due to transmission errors or other causes, then, by convention, the SDU has infinite latency. This is also referred to as “end-to-end latency”. The latency requirement (or deadline) is the longest latency that the application can tolerate in the sense that the probability that the latency is less than the deadline is at least equal to the reliability requirement (see next bullet).

(3) 

Reliability is defined as the probability that the SDU is correctly received within a specified maximum latency (deadline), subject to the other relevant requirements and conditions (such as SDU size, communication range, transmission power, propagation conditions, and mobility). Figure 6 depicts the Cumulative Distribution Function (CDF) of the latency (τ), and its relationship with the reception deadline (τ_dl), the reliability, and the packet drop probability. The packet drop probability is represented by Pr{τ = ∞}, since a dropped packet is, by convention, thought to be equivalent to a packet being delivered with infinite delay. Hence, the latency CDF ${\mathrm{F}}_{\tau }\left(\mathrm{x}\right)=\mathrm{Pr}\left\{\tau \le x\right\}\le 1-P_e$ for all finite x (nevertheless, with some abuse of notation, $F_{\tau }(\infty )=1-P_e+P_e=1$as would be expected). It is worth noting that an arbitrarily low packet drop probability does not necessarily translate to attaining a high reliability. In fact, allowing for an unbounded number of retransmissions can achieve virtually error-free transmission from the application perspective, which, however, comes at the cost of potentially very long latencies. In such case, we can have zero packet drop probability and still violate the reliability requirement. We also note that SDUs that violate the deadline will probably be dropped by the application. However, with the chosen framework, we can separate between the application decision to drop packet due to excessive delays in the communication process and packet drops due to other reasons (noise, fading, interference, etc.).

(4) 

Availability is defined as the probability that the requested service is declared as available. That is, at the time when the service is requested by the application, the communication system can either declare the service as available or unavailable. In the former case, the communication system will accept SDUs from the application and try to deliver them with the requested reliability and deadline. In the latter case, the application is blocked and it should initiate a fallback procedure to gracefully degrade the performance. The rationale for this KPI is that it might be very costly or even impossible to provide a service with very high reliability at all times and it is therefore necessary to occasionally declare the service as unavailable. Usually, there is a tradeoff between availability and reliability in the sense that we can make a system more reliable by reducing the availability, and vice versa.

(5) 

Data rate represents the number of bits sent per unit of time, typically measured in bits per second (bit/s). It is defined by the SDU rate and the SDU size, i.e., for a stream of SDUs that arrive with a rate $R$ SDUs/s, the average data rate is $R\times$ (SDU size). In case the deadline is less than the time between SDUs, i.e., ${\tau }_{\mathrm{dl}}<1/R$, the required data rate is $\left(\mathrm{SDU}\mathrm{size}\right)/{\tau }_{\mathrm{dl}}$.

(6) 

Communication range specifies the maximum distance between a transmitter and its intended receiver allowing for communication with a targeted SDU size, maximum latency (deadline), reliability, and for a given effective transmit power and receiver sensitivity, on average.

4.2. Relationship between Automotive and Communications Network KPIs

Each of the automotive KPIs has an impact on one or more network KPIs, depending on the underlying vehicular application. Automotive KPIs are often distinguished for safety and non-safety applications. Localization, completion time, minimum inter-vehicle distance, and mobility have more impact on safety, whereas relevance area and completion time are more relevant for infotainment services. Safety applications often impose requirements on wireless networks in terms of communication range, reliability, and end-to-end latency. Similarly, localization is a key enabler for important safety applications and is thus considered to be an automotive KPI. On the other hand, the infotainment applications often impose requirements in terms of data rate, SDU size, and network availability for seamless connectivity. In many cases, multiple automotive KPIs affect the network KPIs. For example, in the lane merge use case, both the mobility (e.g., acceleration/deceleration) and the relevance area will have an impact on the amount of time that is allowed between subsequent message transmissions, since higher mobility and larger relevance area require higher message periodicity. Therefore, both of these automotive KPIs have an impact on the data rate. Similarly, in the case of the see-through use case, the mobility and the relevance area will directly impact the required communication range. In the next subsection, we focus on one representative example for each use case class to elaborate on how the automotive KPIs impact the corresponding network KPIs to elaborate further on these relationships.

4.3. 5GCAR Use Case Technical Requirements

In this sub-section, we elaborate on how the automotive requirements impact network requirements for the five particular use case representatives that have been studied in 5GCAR, as mentioned in Section 3. It needs to be mentioned, although most of the requirements are defined using detailed analysis of the application behaviors and conditions, some requirements were difficult to derive with high accuracy and, therefore, are defined based on assumptions from best practices. Additionally, aspects of security and privacy are relevant to all use cases considered. Furthermore,

Table 2. Network requirements for the 5GCAR use cases.

	Use Case	Lane Merge	See Through	Network Assisted Vulnerable Pedestrian Protection	High Definition Local Map Acquisition	Remote Driving for Automated Parking
Requirement
Communication Range		>350 m	<100 m	>70m	>1 km	several kms
Latency		<30 ms	50 ms	<60 ms	<30 ms	5 to 30 ms
Reliability		99.9% (high)	99% (medium)	99% to 99.99%	99.9% (high)	99.999%
SDU Size		12,00–16,000 bytes per message	41,700 bytes per frame	1600 bytes per message	Up to 60 bytes	UL: 41,700 bytes DL: 16,000 bytes
Data Rate		1.28 Mbps	from 14 to 29 Mbps	128 kbps	DL: 960 kbps + 1920 kbps	from 6.4 to 29 Mbps
Availability		99% (medium)	99% (medium)	99.9% (high)	99% (medium)	99.999% (ultra-high)

summarizes the communication requirements for the use cases that are described in this section.

4.3.1. Lane Merge

We consider the scenario that is depicted in Figure 1 left, as an illustration for the lane merge use case. It represents two vehicles (Veh₂ and Veh₃) driving in the main road and a third vehicle (Veh₁), which plans to merge into the traffic. The right-hand image in Figure 1 shows a recorded image of the video-based lane merge observation scenario [17], where the vehicle on the merging lane should decelerate to provide a larger headway in order to allow this maneuver. The deceleration should be below a certain value (e.g., 3 m/s²) to be comfortable for the driver and the passengers. The most relevant automotive requirements for this use case are vehicle localization accuracy, completion time, minimum inter-vehicle distance, relevance area, mobility, and the overtake time. Accuracy below one meter should be reached for future autonomous driving to give precise trajectories for the vehicle [10]. For the planning and execution of a smooth lane merge maneuver at 100 km/h, a range of approximately 350 m should be covered [4]. The completion time is computed for the lane change when considering a lateral speed of 1 m/s and a four-meter lane width, which results in around four seconds. The inter vehicular time (Time Inter Vehicle, TIV) must be two seconds between any two vehicles [15]. The transmitted data includes vehicle dynamics (position, speed, orientation, etc.), maneuver recommendations, and their feedback from the vehicles. If vehicle trajectories are included in the messages, the date rate is up to 1.28 Mbps per vehicle; if not, only safety messages with approximately 1200 bytes per message are transmitted [10]. A maximal latency of 30 ms is assumed to achieve a fast response time [10]. Often, the connectivity provides a line of sight where the on-board sensors cannot. Thus, reliable information is required (such as 99.9% reliability [18]) in order to be useful for the lane merge decision. The availability requirements are set to medium equal to 99% due to the fact that the trajectory contains a lot of redundant information.

4.3.2. Cooperative Perception Based on See-Through

An overtaking scenario is considered as a motivation for the see-through use case, where we consider, as illustrated in Figure 2, two vehicles Veh₁ and Veh₃ driving in the same lane, with a speed of 50 km/h and a legal headway of two seconds. A third vehicle (Veh₂) is moving in the opposite direction, with a speed of 100 km/h. Veh₁ wants to overtake Veh₃ and it requests a real-time video from Veh₃. Veh₁ needs to change its lane, increase its speed with an acceleration limited to 2 m/s², to complete the overtaking maneuver. With a lateral speed of 2 m/s, approximately two seconds are needed to change the lane of four meters width. In this configuration, it takes 6 s and 120 m to have Veh₁ and Veh₃ at the same level, and an additional two seconds to regain the correct headway at the end of the overtaking. During the total eight seconds, Veh₂ has traveled 220 m. An additional l60 more meters are considered to provide safety buffer for avoiding the collision, resulting in a total overtaking distance of around 400 m.

Based on this scenario, the following automotive requirements have been identified: completion time, minimum inter-vehicle distance, relevance area, and mobility. The completion time is equal to 10 s. As the vehicle transmitting the video and the vehicle receiving are driving in the same direction, a relative mobility between 0 to 30 km/h is considered. Although the relevance area is highly dependent on the speed, based on the calculation above, between 300 and 500 m is judged as being needed for a safe overtaking maneuver.

From a network perspective, the required communication range can be derived from the minimum inter-vehicle distances. The communication range of 50 to 100 m is sufficient at 28 m of headway, as the two vehicles Veh₁, Veh₃ involved in the video exchange are driving in the same lane. The amount of data to be transmitted is proportional to the camera resolution and the processing capabilities. We assume a high definition video with a resolution of 1280 × 720 pixels, a frame rate of 30 Hz, 24 bit color depth, and a typical compression of 1:30 (e.g., with H.264 codec, extended profile [19]), as we need advanced capabilities for the extraction of video features in real time. This results in a data rate of up to 10 Mbps (cf. Table A-1 in Annex A of [19]). Only the relevant sections of the video are transmitted, resulting in an expected data rate of 2 Mbps, in order to reduce the data rate. On the other hand, if specific image processing algorithms require high-quality image data to be transmitted, a data rate of about 29 Mbps or higher would be necessary (video codec without motion compensation).

The latency requirement (i.e., deadline) depends on the speed of the vehicle, its heading, as well as pitch angle changes. A delay of at most 50 ms should be kept, as both videos from the front vehicle and the rear have to be stitched together in the rear vehicle. Lower values would enhance the experience of this function, whereas additional delays would increase buffering in the rear vehicle. In addition, the jitter (variation of latency between received transmissions) should be kept small in order to avoid the loss of video frames. A reliability of 99% is required in order to avoid massive artifacts in the real-time video stream, as this would be used only to indicate to the driver if overtaking is possible or not. For high automation levels, this value will be further increased, due to the need for transmitting object detection messages. The availability requirement is considered to be aligned with the reliability value and, therefore, 99% is required.

4.3.3. Network Assisted Vulnerable Road User Protection

Figure 3 illustrates the scenario we considered for this use case: a pedestrian is walking close to the road or is crossing the street. A vehicle is driving towards the street with bad visibility conditions, for example, its view hidden behind parked cars. The network, with the help of accurate positioning technology, can predict the collision probability and deliver warning messages to the vehicle to avoid the potential collision in order to detect the presence of vulnerable pedestrian users and notify the driver or the AD vehicle.

The most critical requirements for this use case include: (1) localization, the most significant requirement and the associated error shall be less than 50 cm or 3% of the true distance between the object and the vehicle itself, in case the latter value is greater. Larger values will increase the false alarm rate, as the pedestrian might be far away from the crossing area and a warning is still sent to vehicle although being irrelevant for the driving decisions. 25 cm accuracy would be the ideal case, since the place of the smartphone will affect the final accuracy; (2) intersection crossing time, which is around seven seconds when considering a two-lane road approximately 10 m width) and a pedestrian speed of 5 km/h; (3) relevance area, with the assumption of driving automation Level 3, about 70 m in urban area and at least 400 m in case of country road at night, which is the most challenging case. Regarding communication or network requirements, the availability of coverage should be 99.99% to ensure that this safety critical service is available and treated as top priority by the network. A reliability level of 99.9% is required in order to guarantee a similar reliability as the local on-board sensors (one error every 1000 operations). The data rate requirement is around 128 kbps with 10 Hz updated rate of pedestrian trajectory messages with a size of 1600 bytes: each message contains a five second trajectory with 100 ms periodicity (10 trajectory samples per second) and 32 bytes per trajectory sample. This gives 320 bytes per second and a total of 1600 bytes for five second trajectory. In addition, the power consumption and privacy of the VRU device are among other factors that should also be considered.

4.3.4. High Definition Local Map Acquisition (HDLM)

Figure 4 illustrates the high definition local map acquisition use case, which depicts an example of a layout for the dynamic map. Polygons are used to organize and divide the information, the off-board system (so called application server) is used to gather and process all of the information collected from different sources available on and along the road. Finally, the roadside infrastructure provides vehicles with information collected from the connected sensors. Moreover, the host vehicles receiving the HD-maps also aggregate and process the information received from the server.

Several automotive as well as network specific requirements are analyzed for this use-case. The most critical automotive requirements are: (1) relevance area, which is at least five seconds horizon or 250 m and up to 10 km, since it can be used for both short term and long term route planning, respectively; (2) localization, which requires 15 to 25 cm accuracy as sufficient for driving automation of Level 3 cars, but 5 cm at best to detect half the width of lane marking for fully autonomous cars; (3) overtake time of 10 s is needed for stopping the autonomous vehicle safely in case of any hazardous situation. The inter-vehicle distance requirements are similar to the ones derived for the see-through use case. (4) A relevance area equivalent at least to five seconds horizon (approximately 250 m) is needed. On the network side, the basic requirement is coverage availability of 99% due to the redundant information included in the trajectory messages and the high reliability requirement of 99.99% that guarantee the quality of the information. A data rate of around 2 Mbps is required if an update frequency of 50 ms is used for the objects located within 100 m radius; and, a data rate of around 1 Mbps is required if an update rate of 100 ms is sufficient for objects that are located more than 100 m away. Both flows will be sent simultaneously, so the overall data rate for the downlink would be 2.88 Mpbs per vehicle, in order to build a continuous electronic horizon. Finally, the end-to-end latency must be below 30 ms for the network communication layer. In fact, an end-to-end application layer represents the end-to-end latency from a Local Dynamic Map (LDM) object report via an LDM application server to the vehicle while using the LDM object report in Sensor Fusion (SF). The SF function calculates the weight of sensor value relevance based on age of information received from the detection or the report, from a 100 ms “old” report the weight will get lower, and reaching 150 ms “old”, the weight will become zero and the value be discarded. In the end to end latency, three elements are taken into account: the uplink latency, server processing latency, and the downlink latency. If between 50 and 100 ms are reserved for the server, then around 25 ms would be required for the maximum communication latency.

4.3.5. Remote Driving for Automated Parking

Automated parking is a distinctive subcase of the remote driving class, involving the operations that are necessary for remotely driving a vehicle on the “last mile” towards a parking place, and completing the parking operations itself. The most critical automotive requirement is localization, as the remote driving for parking can take place in covered places and, therefore, cannot only rely on GPS. Parking maneuvers could require a high precision localization and identification of obstacles, in the order of 50 cm to be able to avoid collisions. Moreover, the network requirements are particularly strict since the driving is conducted by a remote server based on real-time sensor information collected by the vehicle: notably, a high-data-rate, low-latency video, and sensor data flow are required in the uplink, requiring a data rate between 14 and 29 Mbps, estimated based on similar methods as for the see-through use case. An overall latency of 300 ms is needed for an urban environment, 200 ms for the server processing time, and 100 ms for the round trip. For the uplink, the need is lower due to the continuous data aggregation and trajectory prediction. For the downlink, as a reference of the vehicle commands, the repetition rate of the steering wheel sensor is 10 ms, and then 5 ms latency will be expected. Simultaneously, an ultra-high reliability flow of 99.999% is required to coordinate the information received from the remote server with the control commands sent to the actuators. An availability of 99.999%, equivalent to a downtime around five minutes per year, must be maintained since the use case involves the last mile remote driving.

5. Relationship to 3GPP KPIs and the Role of 5GAA

3GPP TS 22.186 [20] and the corresponding technical report TR 22.886 [13] were developed within Rel. 15 with focus on the description of advanced V2X use cases, when considering automated driving that requires more challenging performance requirements for the 3GPP system, including more strict functional requirements for advanced features. Before, within Rel. 14, 3GPP had introduced 22.185 [21] and 22.885 [22] for efficient support of basic ITS services using LTE-V2X. [20] has considered use cases that belong to the following groups: (a) Vehicle Platooning, (b) Extended Sensors, (c) Advanced Driving, (d) Remote Driving, and (e) General Aspects, including interworking, multi-RAT, communication-related requirements.

For each of the use cases that belong to the above groups, the following performance requirements have been discussed: (a) payload (Bytes) without considering the security payload (i.e., application layer message size), (b) end-to-end latency (ms), without considering application layer processing delay, (c) reliability (%), (d) data rate (Mbps), (e) communication range (m), and (f) transmission rate (message/s).

Table 3. Summary of V2X Performance Requirements in 3GPP TS 22.186.

Use Case Group	Payload (Bytes)	Latency (ms)	Reliability (%)	Data Rate (Mbps)
Vehicle Platooning	50–6500	10–20	90–99.99	0.012–65
Advanced Driving	300–12000	3–100	90–99.999	0.096–53
Extended Sensors	1600	3–100	90–99.999	10–1000
Remote Driving	-	5	99.999	UL: 25 DL: 1

highlights the range of the 3GPP KPIs for each identified category. Automated driving sets the most stringent performance requirements for the communication layer in terms of delay, reliability, and capacity due to the safety requirements. As vehicles advance towards higher automation levels, they will have to deal with increasingly complex road situations and, therefore, the need for a complementary communication technology for the exchange of cooperative information with higher bandwidth and improved reliability will increase.

The use cases and the requirements that have been proposed in the 5GCAR project are, in many cases, different from the descriptions and/or the KPI values that have been proposed in 3GPP.

The 5GCAR project elaborated on more concrete use cases than the ones defined by 3GPP, which were the outcome of consensus discussions mostly between the 5GAA organization and the traditional stakeholders of 3GPP. Accordingly, although particularly well documented, the 3GPP use cases were kept at quite a generic level (see for instance in Table 3 the range of some parameters). Indeed, the use cases elaborated by 5GCAR were also defined with concrete applications in mind and they were demonstrated at the end of the project [23].

Moreover, 3GPP has not focused on the analysis of automotive requirements, since the focus lies at the communication layer. An analysis of the differences between the 5GCAR use cases and the corresponding 3GPP use cases is provided below:

• The 5GCAR lane merging use case introduces additional network requirements regarding the expected latency and transmission range, which have not been set in 3GPP [20]. In addition, the 5GCAR reliability requirement is more demanding, while the 5GCAR data rate requirement is lower, mainly due to the different adopted approaches for the calculation of exchanged trajectories.
• The description of the 5GCAR see-through use case is the same as the corresponding 3GPP use case, which is entitled as “Video sharing between UEs supporting V2X application” in 3GPP TS [20]. The differences reside at the data rate (14–29 Mbps in 5GCAR instead of 10 Mbps for the lower level of automation in 3GPP) and reliability values (99.9% in 5GCAR instead of 90% in 3GPP). Both of the values are higher in the 5GCAR use case, due to the need for better video quality in order to allow for the engagement of the driver with the specific service.
• In 5GCAR, the HDLM description assumes the existence of an off-board system (e.g., application server) that is used to gather and process all of the information collected from different sources available on and along the road. In 3GPP, there is a similar use case entitled, sensor and state map sharing (SSMS) [20], but the focus is on the exchange of raw or processed sensor data among vehicles to build collective situational awareness. Hence, these two use cases follow different approaches for building and updating the in-vehicles maps.
• Network-assisted VRU protection use case that has been described in 5GCAR is not included in the list of 3GPP use cases [20].

Finally, in the 5GCAR project, the Remote Driving use case has been specifically described for Automated Parking, in order to limit the scope of the investigation so that the results of this use case evaluation could be achieved within the project duration. Although it takes place in a specific road environment (i.e., parking area), the performance requirements proposed by the 5GCAR project are similar to the ones discussed in 3GPP, which theoretically considers all types of road environments and longer period of time for remote driving.

6. Related Challenges and Existing Research Works

V2X services and technologies have been maturing for almost two decades. The IEEE 802.11p standard has emerged and 3GPP also addressed these needs to respond to the requirements of the day one applications. They support delivering safety messages, such as cooperative awareness messages (CAM) and Decentralized Environmental Notification Message (DENM) [24]. Subsequently, after recognizing the increasing demand for vehicular communications, 3GPP developed cellular vehicle-to-everything (C-V2X) communication, known as LTE-V2X based on the LTE standard. The 3GPP-based V2X communications can be utilized for day one safety applications as well as non-safety (e.g., infotainment) purposes [25]. Although, both 802.11p and LTE-V2X provide satisfying results in low channel load and good propagation conditions. The contention-based MAC of 802.11p and the high collision probability of broadcasted packets in high load networks prevent the support of efficient and reliable safety critical services, such as cooperative maneuvers. Additionally, although LTE-V2X [26] introduces the sensing mechanism to reduce the collision probability, Fit does not completely eliminate the collision risk, especially in the case of high traffic loads where all of the resources might be sensed occupied and still the transmitter has to choose one of them. Several technical challenges have been identified as being associated to the new V2X applications:

• Meeting the requirements of low latency and high reliability simultaneously: this is a major research challenge, especially in highly mobile vehicular scenarios, and requires overcoming the challenges that are created by the dynamics of the V2X wireless environment, including high Doppler and delay spread due to moving transmitters, moving receivers, and moving scatterers. This highly dynamic environment has large impacts on the direct device-to-device (sidelink-based) V2X communication, in terms of resource efficiency, latency reduction, as well as out-of-coverage support [27]. However, for vehicle-to-vehicle (V2V) services that require high reliability and/or high data rate, the sidelink (SL) alone might not be sufficient to meet the requirements, especially in very complex environments. Therefore, it is possible to use only cellular uplink/downlink (Uu) or alternatively multi-connectivity combining SL with cellular Uu. These settings can be explored for enhancing reliability as well as data rate for advanced V2X communications. Dual- or, more generally, multi-connectivity in LTE and 5G allows for UE to be configured with two or more Uu connections with different BSs. This is different from the dual or multi-connectivity with SL and Uu connections for direct end-to-end communication in V2X. Optimal data path routed via eNB using Uu links and possible switch between SL and optimal data path for V2V is discussed in 3GPP and literature [28], but not multi-connectivity with SL and Uu link.
• Prioritization of data packets and Quality of Service (QoS) management: the diversity of the requirements of the new V2X applications raises new challenges for efficient multiplexing of different services and interference handling. Although the dynamic sharing of the same resources for different services is certainly beneficial in terms of spectral efficiency, it brings challenges on the system design that has to optimally multiplex different service flows with different QoS requirements in a high load system without compromising the V2X critical safety nature. Similarly, different types of interference arise, especially when considering all different V2X communication forms and also the potential operation over unlicensed band. Interference due to co-channel operation or from adjacent channels should be handled to achieve high reliability.
• Adaptive and Robust Beam Management in mmWave Spectrum Bands: several V2X applications impose a requirement to deliver a common message to a set of vehicles over the V2I communication link. When considering the great potential of the high data rate, the utilization of mmWave bands holds great potential. However, beamforming associated to the operation on mmWave frequencies imposes a challenge in highly dynamic V2X environments.
• Local data scheduling and delivery: in some use cases (e.g., HD map dissemination), the data might be generated and available before the vehicle approaches a target area. This means that the network should consider the geographical area of the data when scheduling data delivery. Multimedia Broadcast/Multicast Service (MBMS) [29] can play a key role to send the common data of interest to a group of vehicles with one transmission instead of unicast. Although being suitable to this purpose, as, for instance, analyzed in [29] to improve the resource utilization and in [30] for co-existence with direct vehicle-to-vehicle communications, MBMS has a main drawback in terms of high signaling for MBMS group creation, joining, notification, session start, etc. This might impact the capability of the network in delivering the desired data before the vehicles approach a reference area. In addition, MBMS is efficient when the number of UEs receiving the same content is reasonably high, and this condition might not be valid in some scenarios where the geographical areas for data delivery might be small (e.g., in the order of a few tens of meters), with few involved vehicles. Small geographical areas also bring additional issues in terms of higher number of groups to be managed and additional joining/leaving signaling.
• Accurate localization of vehicles and vulnerable road users: accurate location is a one of the key enablers for several use cases that are related to connected vehicle systems. However, having a solution that can provide very accurate (centimeter level) location estimate in a very short time (low latency) is yet a challenge. Regardless of the localization technology (satellite-based or cellular-based), the problems arise from two fronts: (1) the errors affecting the position-related measurements due to propagation of radio signals in a multipath environment and (2) the delay to process and/or feed location-information to the location server. Research is on-going on finding 5G radio-assisted positioning techniques for both vulnerable road users and vehicles with the aim to increase the availability of very accurate localization. This could potentially be achieved thanks to new triangulation algorithms running in multiple base stations with Multi-Input Multi-Output (MIMO) beamforming at mmW frequencies, for example.
• Accurate channel modeling: it is fundamental to the design of the reliable V2X communication systems. Recent surveys of existing state of the art vehicular channel measurements and models can be found in [31,32]. However, each of the existing models were designed for a specific scenario and therefore cannot be applied for the variety of scenarios (e.g., urban, rural, and highways) encountered in the vehicular environments. It is worth mentioning that there is a lack of a clear guidance that helps radio designers how to select the appropriate V2X channel model and the right combinations of parameters to be used for each of the high reliability use cases discussed in this paper.
• Support of vehicular use cases with Multi-access edge computing (MEC): edge computation capabilities can be particularly useful for computation-sensitive V2X use cases. Therefore, the joint optimization of MEC capabilities and mobile network resources may be beneficial, allowing for the offloading of computation tasks close to the access node. How MEC can be used in the network architecture supporting C-V2X is described in [33], while service migration in compliance with ETSI MEC is further addressed in [34].
• Multi-connectivity: it could improve the service availability by jointly using several communication modes or technologies instead of only relying on one mode/technology (i.e., only Uu or only SL) that might not be able to support some use cases. Infrastructure-based links (i.e., Uu) as well as direct V2V links (i.e., sidelink) have different characteristics and, consequently, are associated to different features. The selection of appropriate communication link, the switching from one mode to another, as well as the joint usage are features that will help to improve QoS and communication service availability. In addition, environments with the availability of multiple Radio Access Technologies (RATs) could be also considered, thus extending above challenges when considering that each RAT has its own features in terms of performance, such as reliability, capacity, latency, etc.
• V2X communication is going to take place in a multi-operator environment: enhancements may be required for dealing with the proper (in terms of delay and reliability) communication of the vehicles belonging to different operators if we want to avoid complex deployments. Additionally, the case of the cross-country border crossing should be considered, where interruptions shall and can be avoided, since the UE should register to the other country’s operator.
• V2X service negotiation can enhance the network awareness of service requirements: for instance, spatial/time information represents important information associated to a V2X service, as well as information about receiver (i.e., vehicle) status, such as its location, speed, intended trajectory, etc. Such information can be exploited by the network to optimize the delivery of the service. On the other hand, the service might benefit from additional information coming from the network, e.g., network capability in fulfilling QoS in a certain area, network capability for message transfer within a certain deadline. As an example, the service can select the most appropriate vehicle driving status (e.g., speed, route), thanks to its increased network awareness.

Table 4. Summary of Technology components.

Technology Components	Brief Description
Multi-antenna techniques	Predictor antenna, beam management for unicast/multicast/broadcast communications, and optimal antenna design for V2X communications including both vehicle and infrastructure antennas.
Radio resource allocation and management	Efficient radio resource management for both Uu and sidelink in either centralized and/or distributed way.
Sidelink design	Basic design for sidelink (discovery, synchronization signal and reference signal design).
Full duplex	Cognitive resource usage for V2V communication and collision detection/avoidance.
Reliability enhancements	Trade-off between reliability, latency and capacity for reliability enhancement to both data and control channels.
Positioning	Enhancement to real-time positioning, trajectory estimation and tracking.
Multi-connectivity Cooperation	Improved service availability by jointly using several communication modes or technologies instead of relying only on one mode/technology (i.e., only Uu or only SL) that might not be able to support some use cases.
Multi-operator communication	Enhancements are required for dealing with the proper (in terms of delay and reliability) communication of the vehicles belonging to different operators or in cross-border scenarios.
Edge Computing Enhancements	Availability of computing capabilities at the edge of the network (i.e., edge computing) opens for several improvements in mobile networks to support vehicular use cases. Enhancements are needed from a core network perspective as well as from an access network point of view.
Network orchestration and management	Improved orchestration capabilities able to cope with the unique requirements of vehicular use cases and with improved network management and re-configurability capabilities to cope with the dynamicity in terms of traffic demand in vehicular scenarios.

summarizes the technical solutions that can be applied to improve the identified challenges and KPIs in terms of capacity, latency, reliability, and positioning accuracy for future autonomous driving.

Finally, it is worth mentioning that 3GPP is working on enhancing the C-V2X technology within the further 3GPP New Radio (NR) framework [35]. IEEE is, at the same time, working on enhancing 802.11p in the new project P802.11bd, with the aim to increase throughput, range, and improve procedures for positioning [36]. The main challenges are related to the design of the new V2V broadcast, groupcast, and unicast SL communication interfaces to support the new demanding KPIs, e.g., the high data rate for cooperative perception, high reliability, and latency for remote driving.

7. Conclusions

5G Communication networks must be ready to satisfy the needs of connected and automated driving. Towards this, it is essential to be able to identify and quantify the requirements that the communication networks need to meet in order to enable advanced automotive use cases. The main goal of this paper is to describe future representative V2X use cases, identify their requirements, and then translate them into requirements for the design of 5G networks and beyond. We classify use cases into five big classes of automated driving. By doing so, the analysis of automotive requirements and translation into communication specifications can be done in an ordered and structured manner, while following a clear methodology. The proposed methodology has been applied to five representative use cases that have been studied in the 5GCAR European-funded project: lane merge, see-through, network-assisted vulnerable road-user protection, high definition local map acquisition, and remote driving for automated parking. These use cases have been described in detail and their automotive requirements have been translated into specific and quantitative requirements for the communication network. This process is fundamental in ensuring that the telecom ecosystem is able to provide the communication performance that the automotive world needs to ensure that connected and automated driving can be made ready for public launch in the near future. For completeness, we have also discussed how the 3GPP and the 5GAA are addressing the challenge of defining the use cases and relevant KPIs, quantifying them and establishing the link between automotive and network-related KPIs. All in all, there is a need to harmonize the way that use cases are defined on the automotive sector, so that the telecom sector can provide the communication network that is needed for the vision of automated and connected mobility. This paper aims at contributing to this ongoing challenge, which shall be addressed by the smart mobility ecosystem in a holistic manner.