Both the telecom and the automotive industries are going through profound transformations [1
]. The development of emerging 5G technologies is a clear exemplification of this new revolutionary trend [2
]. The telecom industry is moving beyond voice and mobile broadband, the two core services that have powered the industry until today. The two novel opportunities for future telecom services focus on the “massive” connection of machine-type objects as well as on “ultra-reliable and low-latency” connectivity services. This new service provision entails a transition from a “horizontal” service delivery model, where services have been defined independently from their consumers, towards a “vertical” delivery model, where the services provided are tailored to specific needs of industry sectors and verticals. 5G is regarded as the key technology that will empower this transition [3
In its turn, the automotive industry is evolving towards a vision where cars are becoming more and more automated and wirelessly connected to cooperate with each other for safer and more efficient driving. Today, the majority of safety and efficiency features in vehicles are supported by the on-board sensors, which are limited to visual line-of-sight. Connectivity offers a good complement to the on-board sensors by extending vision and detection ranges even when visual line-of-sight is not available. In addition, connectivity is key to cooperative functions. Both would be required to achieve higher automated driving (AD) levels. Moreover, the business models for the automotive industry are drastically changing in the coming years and the real revolution is about to arrive. For the success of such a revolution, it is necessary that both the telecom and the automotive industry cooperate to shape the future by addressing all the challenges that connected, cooperative and automated mobility (CCAM) poses for the innovation arena.
Europe is playing a pivotal role in this revolution. As dictated in its 5G strategic action plan [4
], 5G aims at becoming a reality by the end of this decade, ensuring large-scale commercialization by the end of his decade at the latest. One of the objectives of this action plan is to promote pan-European multi-stake holder trials to act as catalysts to turn technological innovation into business potentials. This becomes particularly interesting, and indeed necessary, when it comes to testing 5G technologies for CCAM, especially when cross-border operation needs to be guaranteed. CCAM can offer a variety of services that can have a profound impact into economy and society. It will lead to higher road safety and thus fewer fatalities or serious injuries, more traffic efficiency and less environmental pollution. New business opportunities can evolve in areas such as logistics, thus enabling economic growth and sustainability of well-being. Among others, the possibility to enable automated transportation paths along highways crossing a continent is of high interest. However, ensuring that vehicle-to-everything (V2X) services, i.e., those enabled by communication between vehicles to anything (X), can operate along different countries, when crossing borders, is challenging.
When operating in cross-border settings, services based on V2X communications have some unique properties, which pose a challenge and specific new requirements in the design and deployment of the information and communications technology (ICT) infrastructure. A first unique property is that many V2X applications have a limited area of interest. Information is often only needed close to the source where it was generated; for example, an alert of a traffic jam or accident may be needed to be informed only to the other vehicles close to the location of the event. For a typical mobile radio network offering services like voice and data communication, it does not matter that peering points between mobile network operators (MNOs), vehicular clouds, and public data networks are located far from the “edge”. In a V2X architecture featuring mobile edge computing (MEC), this problem should be solved, and the solution cannot be to have just one MEC provider. The second unique property is the existence of the multi-OEM (original equipment manufacturer), multi-MNO (mobile network operator), and multi-vendor interoperability challenge [5
]. For example, some CCAM services may require real-time response and ultra-high reliability when vehicles, having been manufactured by different OEMs, drive through various national borders and need to roam between different MNOs operated by different companies and under different regulations and also using telco equipment provided by different vendors. Even in these scenarios, service continuity must be guaranteed, and the quality of services must not be degraded when crossing borders [6
]. If degraded, it is important to anticipate this degradation so that countermeasures can be taken; e.g., reduce the level of driving automation with enough anticipation or simply stop a driverless vehicle until connectivity quality is resumed and allows for safe operation. The third unique property is the role of the road authority as another source and sink of information [7
]. This comes with often closed, sometimes even proprietary, information technology (IT) systems needing integration in a MEC-enabled distributed computing V2X network architecture. A particular challenge arising from this is that crossing national, in some cases also regional, borders results in a new road authority with own IT infrastructure becoming responsible. The fourth unique property is the availability of information about the mobility of the vehicle which can be obtained from its navigation system. Many past and present research activities, e.g., [8
] focus on exploiting position and route information to improve quality of services (QoS) or, at least, make delivering a guaranteed QoS less challenging. In practice, most of those approaches fail due to the lack of precise routing information. While this is technically feasible [10
] in a vehicular context, security, particularly privacy, and architecture challenges need to be solved.
For all these reasons, and in order to be able to meet the objectives set out by the strategy defined in the 5G action plan, there is a need to trial and validate 5G technologies at large scale in cross-border settings with the mission to reduce uncertainties before CCAM services running on top of 5G communication infrastructures can be offered to the market.
In this context, the European Commission is partially funding innovation actions, which are working to deploy 5G-enabled CCAM cross-border large scale trials. They are 5GCroCo (5G Cross Border Control) [11
], 5G-CARMEN (5G for Connected and Automated Road Mobility in the European unioN) [13
], and 5G-MOBIX (5G for cooperative & connected automated MOBIility on X-border corridors) [14
], and belong to the family of projects under the umbrella of the 5G-PPP (5G public private partnership) [15
]. These three projects gather effort from key European partners from both the telco and automotive industries to contribute to the definition of a successful path towards CCAM services in cross-border scenarios and to reduce the uncertainties of a real 5G cross-border deployment. These projects not only aim at deploying the trials, but also at identifying business opportunities and defining new business models for disruptive CCAM services, which can be possible thanks to 5G technology, as well as ensuring the appropriate impact upon relevant standardization bodies both from the telco and automotive sectors.
In this paper, the focus is on the 5GCroCo project to describe its motivation, key objectives, and initial achievements and findings. First, the aim is to describe the cross-border challenges that have been identified by 5GCroCo in Section 2
, and then describe the use cases that have been selected to conduct the trials in Section 3
. The requirements for each of the use cases are described and quantified also in Section 3
. The three use cases are Tele-operated driving, generation and distribution of dynamic high definition maps, and anticipated cooperative collision avoidance. The technical solutions that are being developed in 5GCroCo, to provide solutions to the identified cross-border challenges, are described in Section 4
. Finally, Section 5
concludes the paper and describes the roadmap of the trials to be completed until the end of 2021.
2. Challenges for Cross-Border Operation
One of the challenges of CCAM services is that they should be provided along different countries when vehicles drive across national borders. Service continuity must be guaranteed, and the quality of services cannot be jeopardized when crossing borders. The situation is particularly challenging when considering the multi-country, multi-operator, multi-telco-vendor, and multi-car-manufacturer scenario that cross-border deployments imply, both from the technical cross-border connectivity perspective as well as business and legal challenges.
While the specification of 5G technologies has progressed a lot in the last years, so far only a few actions have been taken to guarantee that a high QoS wireless connectivity, and indirectly, the support of the services on top of it, can be kept when a vehicle is moving across national borders. Therefore, there are some uncertainties associated with the deployment of 5G networks for the provision of CCAM services in cross-border settings that require dedicated innovation efforts.
A first set of potential gaps and challenges has been identified already, and it is also expected that some further technical cross-border challenges will be identified along the deployment of a real network in the trials.
Cross-border means, first of all, a handover from one operator to another. A first challenge concerns the radio handover. Indeed, the data connection has to be handed over from one operator to another. For now, data handovers do not consider any key performance indicators (KPIs). Even if basic QoS requirements can be done with current mobile networks, the challenge is to provide a more detailed service-level agreement (SLA) handover, guaranteeing that SLAs are maintained. SLAs are application specific. Thus, each application (or service) running on a mobile device has its own requirements. Generally speaking, each application has its own 5G slice, which must be handed over from one MNO to another in the way that the minimum requirements are fulfilled. The exact metrics (e.g., min throughput, max latency, etc.) have to be defined. These metrics have to be communicated in some way during the handover procedure, allowing the visited network operator to do a decision on the 5G slice to be established. This handover must work independently of the equipment used by the operator (i.e., cross-vendor). There should be also a network feedback on the success or failure to provide those minimum requirements, allowing the application to react if they cannot be provided (e.g., change from autonomous assisted driving to manual mode, etc.).
The ultra-low latency and reliability requirements imposed by automotive services, which are a complex issue as explained in [16
], could be met through an extensive usage of edge resources, deploying components of the end-to-end services closer to the network edges. This approach reduces the delay between the generation and the elaboration of the application data, enabling faster processing and timely reactions at the service level. Network slices and virtual services in 5GCroCo are thus characterized by a strong presence of edge applications that, in cross-border scenarios, need to be deployed in multiple domains, characterized by different geographical positions, administrative operations and technological solutions.
Moreover, each MNO will have a different 5G architecture in general, and specifically a different MEC architecture. Indeed, an MEC can be implemented at different hierarchical levels in an operator network: the highest level would be near or in the core network, being the most cost-effective solution but the worst from latency perspective. Alternatively, MEC may be at regional point-of-presence (POP) level, at local POP or at the radio cell level. Other intermediate levels are also possible. However, it is clear that a MEC at radio cell-level provides the lowest technical possible latency, but the highest amount of investment. Each operator will have his own strategy on MEC realization and may have furthermore different MEC architectures in different regions. These different MEC realizations impact the decision where the service data is broken out and treated.
Third-party applications may run on a MEC architecture allowing the third-party service provider to profit from e.g., a very low and guaranteed latency. In such a case, the handover at the border must not only manage the radio handover, but also provide some exchange between the application(s) running inside the home operator network (including MEC) and the same applications running inside the visited operator network (having a different architecture), otherwise there is no service continuity. Of course, service continuity assumes that the service is present in both networks. The exact means of communication between the two networks (i.e., a generalized inter-MEC communication) has to be defined. There should be also a network feedback on the success or failure to provide service continuity. This can be communicated to the service application, allowing the application to react and carry out appropriate steps (e.g., go from autonomous assisted driving to manual mode, etc.). Alternatively, the service may as well be run on servers beyond the operator network (i.e., service overlay). In such a case, no SLAs are usually given and especially not on latency. Such overlay services are not well suited for real time traffic exchange.
Finally, there should be standardized services allowing cross-OEM, cross-vendor and cross-MNO realizations. If services are not standardized or are not using standardized APIs, we are faced with vendor/service specific realizations that will exist, but which cannot be rolled out across countries, providers and vendors.
3. Selected Use Cases
In this section, the selected use cases, executed within 5GCroCo, are described in detail by analyzing the automotive and communication requirements as well as the role of 5G for the realization of the 5GCroCo use cases, with a special focus on the cross-border challenges.
3.1. Tele-Operated Driving
Current automated driving vehicle prototypes prove the feasibility of truly driverless cars. Tele-operated driving (ToD) can be leveraged as an enabling technology to smooth this transition, as edge cases remain which necessitate falling back on human operators. The overall architecture of ToD considered is shown in Figure 1
. For ToD, an interface over the mobile 5G network is created that allows a human to remotely control a vehicle. Through such an interface, sensor and vehicle data, e.g., video feeds and velocity, are transmitted from the vehicle to the vehicle control center. There, the data are displayed to the human operator who generates control commands, e.g., desired steering wheel angle or velocity. These are then transmitted back to the vehicle for execution. Tele-operated driving technology faces a number of challenges that need to be overcome. A system design for teleoperated road vehicles is presented in [17
], providing a reference for ToD hardware and software designs.
Reduced situational awareness poses one of the greatest challenges for ToD, as the teleoperator is not physically located in the vehicle. Additional mental effort is required to compensate for distortions and recreate missing information from the sensor data [18
]. This is supported by the tele-operated driving study presented in [19
]. Therein, the use of head-mounted displayed is analyzed and compared with conventional computer screens, so as to gauge the effect on situational awareness of different visual interfaces for the human teleoperator.
The transmission of signals over mobile networks introduces latency, which can be critical if the vehicle is remotely controlled at stabilization level, i.e., the teleoperator produces direct steering commands. If the latency is too large, different control concepts may be applied, such as the trajectory-based control scheme proposed in [20
]. However, with 5G technology, nowadays limitations posed by network latency are subject to change. In the remainder of this chapter, the challenges of tele-operated driving from a general, technical perspective and when crossing country borders will be identified in terms of the automotive and telco requirements.
3.1.1. Automotive Requirements
The requirements for tele-operated driving from an automotive perspective are demanding. As the vehicle is controlled remotely, it is of great that the sensor suite provides sufficient information to enable safe tele-operation and overcome above challenges of reduced situational awareness. A minimal requirement is 360° coverage of the vehicle’s surroundings with camera images. An additional hardware requirement is drive-by-wire functionality to execute the control commands that are generated remotely. ToD is meant to be a fallback procedure for automated driving. Thus, it is only applicable for vehicles with AD functionality. Although the automation is not running during the tele-operation, a safety concept such as an emergency braking system needs to be active, e.g., to safeguard the case of loss of the mobile data connection. As indicated above, another great challenge for ToD technology is latency. It creates a requirement for each component. For instance, times for processing sensor data and video compression algorithms, or actuation delay needs to be kept as small as possible in order to provide information with minimum possible age to the tele-operator.
3.1.2. Telco Requirements
The mobile network plays a critical role in the functionality of tele-operated driving technology. In summary, there are three key requirements. In the first place, the mobile must provide enough bandwidth that the required amount of information can be exchanged between the vehicle and the vehicle control center. An objective measure for this is the situational awareness of the tele-operator who must be comfortable controlling the vehicle remotely. Second, the information that gets exchanged must be up-to-date when it is received. Thus, in addition to the aforementioned minimal delays in the vehicle, a minimal network latency forms another demanding requirement. At last, network reliability (Reliability in a broad sense as e.g., described under “dependability” [IEC60050] and “functional safety” [IEC61508, ISO26262]) plays a great role for functional ToD. To enable full control of the vehicle for the tele-operator, it has to be ensured that loss of critical information, such as key frames in the encoded video feeds, is kept at a minimum. All above key requirements may suffer if the vehicle is crossing a country border. Ideally, the handover from one MNO to another is not or only minimally perceived by the teleoperator. If this requirement cannot be met, the vehicle may need to come to a standstill such that the MNO handover can take place safely.
3.1.3. What Are the Benefits of 5G Compared to 4G for Tele-Operated Driving (ToD)?
ToD has demanding requirements with respect to functional safety as errors generated by the automated vehicle system might cause injuries to passengers and other road users. Today’s concepts for functional safety, like the one specified mainly in the ISO26262 standard, are not considering the case that vital parts of the system are developed without considering the rules specified in the ISO26262. To keep the possibility to provide functional, safe ToD, concepts have to be developed that allow the existence of system elements that are not developed according to ISO26262 while still maintaining functional safety under full control (this could be but is not limited to a safe control of the respective system elements). Functional safety and reliable end-to-end (E2E) QoS communication requirements are key needs. Cross-border operations impose additional, significant challenges for lag-free data transmission when handing over between MNOs.
Furthermore, a high quality of the information provided to the tele-operator, e.g., from cameras in the vehicle, is necessary to allow safe tele-operation. Camera information, together with data from other sensors, must be provided to the tele-operator with shortest possible latency, high quality and update rates. Latency of the 4G/LTE mobile networks can be inconsistent and may peak up to multiple hundreds of milliseconds. Thus, in order to avoid jitter in video streams, it is necessary to introduce a buffer. This adds to the age of the information that is displayed to the tele-operator. As will be discussed in Section 4.1
, the application of 5G solutions, such as QoS prediction or network slicing, contribute to improved functionality of the ToD technology.
3.2. High-Definition Mapping
One of the cornerstones of autonomous driving is an accurate, actual, and seamless high definition map. The basic functionality is to determine the vehicle’s position—which road and which lane it is in—but also information about traffic rules like speed limitations, or more dynamic conditions like road closures or construction areas. High-definition (HD) map users expect a continuous availability of the map content, even in cross-border scenarios. Autonomous cars, however, require the map to be constantly up-to-date, and thus when reality changes, the map needs to be updated. Regular map updates by the map provider, typically done a few times a year by driving mapping vans along the roads, are not at all sufficient. To ensure a high reliability of autonomous cars, the map needs to be updated constantly, by as many contributing cars as possible. Broadly speaking, the cars collect information about their surroundings using their on-board sensors, and then use their connectivity to send this sensor data to some backend in the cloud. Here, the received data is compared to the existing map, and if differences are found, the map can be updated. The data might even come from sources other than cars, e.g., road side cameras. The HD map can also be used as the base upon which more dynamic information can be stored, for example accidents. All these procedures have to work seamlessly across borders. For example, map updates from cars on one side of a border have to be distributed also to cars on the other side, served by a different operator with the backend running on a different MEC architecture.
A schematic overview of the use case is shown in Figure 2
: A first vehicle detects a lane that is closed because of construction work. It sends its sensor data to a backend in the cloud, where the new information is incorporated into the map. The updated map is then sent back to all connected vehicles in the vicinity.
3.2.1. Automotive Requirements
A basic requirement for this use case is that a vehicle needs to be able to accurately determine its position. It also needs to be equipped with sensors (e.g., cameras or lidar) that can identify objects, road signs, etc. Finally, the vehicle needs connectivity to transmit the collected information to the map service provider. On the automotive side, the requirements for this use case are thus rather modest. All the needed functionality is anyway required for autonomous cars, and systems realizing some parts of it—for example traffic-sign recognition—have been commercially available for almost a decade.
3.2.2. Telco Requirements
Since autonomous vehicles require the high-definition map to be always available, and always include the latest updates, it is streamed to the car, where it is stored in a local cache. This requires ubiquitous and seamless connectivity. An additional challenge arises from the requirement that the availability of autonomous driving must not end at country or operator borders. Thus, seamless connectivity is required even when the car is traversing a national border and/or switching between different network operators. In addition, sensor data gathered at both sides of the border must be available to the respective other side in a fast, efficient, and uninterrupted way. If the map service backend uses the network operator’s MEC instead of third-party servers, communication between potentially different MEC architectures on both sides of the border must be possible.
Depending on the sensor type, the data to be transferred from the car to the map service backend can be quite heavy and require large bandwidth. In other cases, a low latency is required, so that changes can be made available to other cars as quickly as possible.
Another requirement is the need for accurate prediction of periods of time lacking the required communication quality. In the basic approach, the map is downloaded to the vehicle as it moves, i.e., for the next few kilometers ahead. However, in some situations it might be more sensible to download a larger part of the map well in advance. For example, a network might be highly utilized in a city, but have a lot of free capacity in the rural areas around the city. A car moving towards that city should thus download the whole map of the city while it is still in the rural areas offering a high quality of service and be finished with the download before it enters the areas with the most congested network. This requires the network to accurately predict the quality of service the vehicle will encounter in the near future.
Finally, in particular in densely populated areas, the network needs to support a high number of communication devices both in uplink and in downlink.
3.2.3. What Are the Benefits of 5G Compared to 4G for High-Definition (HD) Mapping?
Seamless availability of the autonomous and automated driving functionality is key for acceptance of such functionality. This is especially true in a fully autonomous car, where outages of the functionality would cause passengers incapable of driving the car themselves to be stuck. In order to get such seamless availability, it is important to have accurate maps—in particular the dynamic, fast changing parts like accidents, road closures, etc.—available anytime and everywhere. Such an order of magnitude of availability cannot be achieved with today’s communication networks that are lacking full area coverage. Similarly, seamless connectivity across country or operator borders is far from available in today’s networks.
Smarter and optimized techniques are provided by 5G for managing its resources. For example, a reliable prediction of the availability of connectivity is another feature missing from today’s networks. A function like Quality of Service Prediction that is currently discussed for 5G is essential to allow the aforementioned availability always and everywhere.
Future traffic scenarios might involve a very high density of autonomous vehicles (e.g., in urban areas or on highways), and high definition map updates might have to be provided for many vehicles at once. This leads to new requirements for high-capacity or novel data distribution capabilities in downlink (e.g., efficient multicast) which are not available in 4G and below.
Furthermore, the quality—in the sense of being both geographically accurate and up-to-date—of the HD map is highly correlated with the number of sensing vehicles that participate in the map generation. This means that, even though the amount of data for individual cars might be small enough to be covered by 4G networks, the number of contributing communication units likely causes data traffic that goes beyond the capacity of today’s networks.
3.3. Anticipated Cooperative Collision Avoidance (ACCA)
Towards the autonomous vehicles, car manufacturers are adopting and developing sensors that allow vehicles to sense their environment and control the vehicles. Driving automation systems rely on a variety of sensors like cameras, radar, lidar, etc. Despite the increasing number of in-vehicle sensors, the environmental perception of the vehicle remains limited. In certain situations, typical stand-alone sensing systems will not be able to detect and localize dangerous events on the road with sufficient level of anticipations. In such situations, too late detection of a dangerous event will trigger a hard braking or a dangerous maneuver or potentially lead to a collision.
The anticipated cooperative collision avoidance (ACCA) use case relates to the possibility to anticipate certain potentially critical events in order to reduce the probability of collisions in situations when typical sensors will have no visibility or a short detection range (a few 100 m) [21
]. The aim of the ACCA use case is to induce smoother and more homogeneous vehicle reactions by facilitating the anticipated detection and localization of temporarily static events such as traffic jams, high deceleration, emergency braking or unexpected maneuvers of vehicles in front, etc. An example of a typical scenario of the ACCA use case is depicted in Figure 3
3.3.1. Automotive Requirements
The ACCA use case is mainly based on the exchange of data between vehicles in order to anticipate dangerous situations that occur at positions that are not covered by the on-board sensors of each vehicle individually.
In order to implement the ACCA use case, vehicles must be equipped with a set of sensors (e.g., radars, cameras, lidars, etc.) that are able to detect and recognize dangerous events in their proximity, an on-board unit (OBU) for V2X communications, and an advanced driver-assistance system (ADAS). The ADAS includes several components to assist the driver and improve safety, e.g., electronic stability control, anti-lock brakes, lane departure warning, adaptive cruise control and traction control, human–machine interface (HMI), etc.
Vehicles exchange data via vehicle-to-network (V2N) with a geoservice that runs in a network server located in the V2X infrastructure. Vehicles send information to the geoservice about detected dangerous situations or about their general sensing, using standard-compliant European Telecommunications Standards Institute (ETSI) Intelligent Transport Systems (ITS) messages, e.g., decentralized environmental notification messages (DENM) or cooperative perception messages (CPM), encapsulated in IP datagrams. The network server extracts, aggregates, processes and reflects all information related to road events in a certain coverage area, and it provides the requested information to those vehicles that have interested knowledge about dangerous situations in this geographical area. The location of dangerous events is shown on a local dynamic map (LDM) at the HMI, as if it was received directly by V2V communications.
Besides detection of dangerous situations by on-board sensors, vehicles can combine information received from the geoserver, in order to apply decision policies in the ADAS systems, e.g., warning the driver about dangerous situation and/or automatically activating brake system if needed.
3.3.2. Telco Requirements
The telecommunications operator infrastructure is required to provide MEC functionalities, making possible the execution of standardized ITS geo-positioning and signaling services with direct connection to the base station. In addition, the infrastructure must provide service guarantees to a cloud-based ITS system, provided by a third party such as a road or infrastructure operator. Such interfacing is required to coordinate and distribute detected hazards across different MEC located geoservers. Functionalities such as slicing should be used to guarantee the interconnection between the cloud infrastructure at the ITS provider, so that the delay and reliability requirements are met. These slices should consider cross-border infrastructures through internet exchange points.
The MEC capability should support virtualization in order to enable extension and coexistence of different geoservice solutions without implying any change to the operator infrastructure.
In a cross-border situation, where partial information is handled by the geoservices running at the different MECs hosted by different MNOs, it is crucial to enable efficient information distribution and exchange. In this case, the 5G network infrastructure plays a fundamental role in order to handle interconnection between MNOs.
3.3.3. Other Player Requirements
Road operators and traffic management authorities play a fundamental role in the use case as coordination services will depend to the capability of the infrastructure to distribute the geographical information to the different MEC hosted services. Roaming and cross-operator information needs to be brokered by an external cloud service which may be provided by ITS management platforms.
3.3.4. What Are the Benefits of 5G Compared to 4G for ACCA?
As defined in the previous subsections, there are certain requirements and functionalities that depend on the network infrastructure and need to be provided by the telco operator. A main requirement is the capability of the infrastructure to respond in “real time”, being able to collect events signaled by vehicles, process them and signal them back to other vehicles in the geographic position. This capability requires bounded latency and reliability guarantees that cannot be provided by current 4G infrastructures, and 5G support for URLLC (Ultra-Reliable Low-Latency Communications) traffic is expected to be critical.
Additionally, considering that critical geoservices need to be processed as close as possible to the vehicles and potential dangers, it is key to enable a 5G MEC capability in order to support:
the need of high and guaranteed reliability of the connectivity between the vehicle and the off-board geoservice, which is distributed in the cloud edge;
the need of low and guaranteed latency of the connectivity between the vehicle and the off-board geoservice, which is distributed in the cloud edge;
the need of backend interconnection between the central cloud and the distributed edge cloud to guarantee a seamless service connectivity under roaming or handover conditions.
4. 5GCroCo Solutions
Considering the requirements of the use cases presented above and summarized in Table 1
, 5GCroCo has identified a set of key 5G technologies, which will become enablers for CCAM. Many of them have been thoroughly evaluated in previous and ongoing research and innovation projects. Some of them are even commercially deployed already. The motivation of 5GCroCo is to evolve them to also fulfill their purpose and role in overall QoS fulfillment in cross-border, cross-MNO, cross-vendor, and cross-OEM deployments. Service continuity is a particular goal in this context. The key identified technologies are:
MEC-enabled distributed computing;
E2E QoS with network slicing;
Mobile network-supported precise localization;
The V2X services that will be studied and trialed in 5GCroCo for the use cases described in the previous section have unique characteristics which make the use of these technologies particularly interesting. First, a limited area of interest. Information is often only needed close to the source where it was generated. This is true for many, but not all applications. It applies in particular to the use cases of HD maps generation and ACCA. Direct communication omitting the cellular network and MEC-enabled cellular networks must, therefore, be part of the V2X architecture. The second unique property is the multi-OEM and multi-MNO challenge. This one is tightly coupled with the first one. For typical mobile radio network services like voice and data communication, it does not matter that peering points between MNOs, vehicular clouds and public data networks are located far from the “edge”. In a MEC-enabled V2X architecture this problem must be solved, and the solution cannot be to have just one MEC provider. The third unique property is the role of the road authority as another source and sink of information. This comes with often closed, sometimes even proprietary, IT-systems needing integration in a MEC-enabled distributed computing V2X network architecture. A particular challenge arising from this is that crossing national, in some cases also regional, borders results in a new road authority with its own IT infrastructure becoming responsible. With these technologies, 5GCroCo will address the gap of existing cellular V2X technologies (such as LTE Release 14) by enhancing a number of KPIs in the 5G network, such as latency, reliability, packet error rate, etc., even under cross-country, cross-MNO, cross-OEM and cross-vendor operations.
In the following sub-sections, it will be further elaborated on how these solutions will find application in the use cases presented in the previous chapter.
The telco requirements for tele-operated driving can only be met by the new 5G uplink capacity, latency and reliability capabilities. Furthermore, 5G solutions will find application in the deployment of the technology.
For ToD, a vast amount of data is continuously transmitted between the vehicle and the vehicle control center. With the 5G solution of QoS prediction, it is enabled to predict the available bandwidth. In the first place, if predictions are provided minutes in advance, they can be used to select a route for the vehicle along which a sufficient bandwidth is expected. At prediction times of several seconds, a reaction of the tele-operator, if a lower available bandwidth is predicted, would be to slow down the vehicle. If the time horizon of the predictions is even shorter, it is assumed that an automation can take actions, e.g., adapting the video compression rates and/or the resolution of the images, to ensure a jitter-free video stream displayed in the vehicle control center.
A QoS prediction scheme, as shown in Figure 4
, targets the assessment of the experienced quality of service for each client and the timely notification. It monitors different parameters of the network and environment from present and past to obtain a prediction. Furthermore, prediction algorithms can learn from past decisions to improve their accuracy or be trained.
A notification is provided to the system in case the minimum required QoS cannot be met, in terms of specific KPIs, such as data rate, packet loss and end-to-end (E2E) delay. Minimum required QoS—in this context—is the minimum acceptable quality of the provided vehicular network’s resources in order to address the respective V2X service and application requirements sufficiently. A QoS prediction mechanism needs to identify the different parts, which comprise the end-to-end communication path. In the context of cross-border scenarios, the QoS prediction may be of crucial value as well. As coverage of multiple MNOs overlaps in border areas, the point at which the handover occurs can be optimized.
A second 5G solution, namely network slicing, is applicable for ToD. Instantiating a virtual network for the data transmission, it facilitates sufficient and predictable bandwidth, and thus enabling improved safety during the tele-operation. Furthermore, it is part of ongoing research, if and which computations can be carried in MEC application servers in order to reduce the data volume transmitted from the vehicle to the vehicle control center.
4.2. HD Mapping
MEC application servers can be used as caches to reduce the download time between the map content provider and the vehicle. The MEC application servers can cache map tiles requested earlier that were downloaded from the map content provider backend in the public cloud. When another vehicle requests the same map tile, the MEC already has it cached and serves the request. This will reduce the data traffic between the MNO backend and the map content provider backend, since data do not have to be transmitted all the way from the public Internet to the vehicle. It is also possible to distribute map tiles from the map content provider backend to the MEC beforehand, given that the MEC is only serving map tiles for a specific area, but it must be ensured that updates are consistent in the MEC and map content provider backend.
Map changes detected and uploaded by a car will be fused at a geographically close MEC host and then uploaded to the map content provider backend. The most urgent intended receivers for these changes are vehicles close by, and they are likely connected to the same MEC host that received the update. This also allows to quickly verify a local HD map content update, where multiple vehicles update a detected change to the MEC Application Server. The server optionally fuses the information from these different vehicles to more precisely define what has changed.
The QoS prediction mechanism, as discussed above in Section 4.1
and shown in Figure 4
, can be used to enable planning ahead for the best time or place to download a larger part of the HD map, e.g., according to cell utilization in certain areas.
4.3. Anticipated Cooperative Collision Avoidance (ACCA)
The ACCA use case will be materialized by the integration of different services hosted at the MEC and at the cloud with the ability to deal with different critical situations as depicted on Figure 3
. The MEC-hosted geoservices will provide near real time situation handling. State synchronization between MEC geoservices hosted by different MNOs will be handled by a cloud-hosted traffic management system, who will handle regions of interest and distribute information among the MECs in those regions (Figure 5
One MEC-based geoserver shall include all perceived objects and events in its region of interest, regardless of the MNO, the brand of the car, or even the road operator. One clear challenge will, therefore, be data interoperability and privacy between countries, MNOs, and automotive industries.
Vehicles will be connected to the geoservices hosted at the MEC, and can receive information with different priority levels. Critical warnings, e.g., those warning about hazards close by, receive priority over non-critical ones. Finally, Vehicle-to-Network (V2N) Cooperative ITS (C-ITS) can be complemented by direct V2V communication to ensure a hybrid communication solution.
The solution will also ensure optimized usage of valuable radio spectrum resources by fusing information relating to the same event in the MEC. Figure 6
a shows the approach without fusion, where all messages are sent to all other vehicles within a certain area while Figure 6
b shows how the amount of downlink messages is reduced if:
Information about the same event is not just forwarded but fused to a single downlink message;
Information from multiple different events is contained in a single message and, therefore, packet header information is only transmitted once.
5. Conclusions and Next Steps
This paper presents the main challenges for CCAM services in a cross-border and multi-MNO environment as they have been studied and identified by the 5GCroCo project. ToD, HD mapping, and ACCA have been used as examples of use cases to describe in detail the automotive and communication requirements as well as the role of 5G in order to address the identified challenges. Service continuity, low latency, high reliability, high data rate, and guaranteed QoS during the transition from one operator to the other are some of the key technical issues in the context of a cross-border and multi-domain environment. Enhancement of roaming schemes to reduce roaming latency, inter-MEC communication, multi-domain orchestration, enhancements on network slices selection as well as QoS prediction are identified solutions discussed in this paper that could be used to address the cross-border challenges.
The 5GCroCo project aims at validating 5G technologies in the Metz–Merzig–Luxembourg cross-border corridor, for three key CCAM services (ToD, HD mapping, and ACCA) at the borders between France, Germany and Luxembourg. While the actual trials and validations in 5GCroCo will be focused on these particular use cases with envisioned high potential market opportunities, the activities of 5GCroCo aim at deriving recommendations and insights that can be valid for a wider set of CCAM use cases.