ENVELOPE

In this use-case, it is assumed that one of the sensors of the autonomous vehicle fails (e.g., camera). After the sensor failure is detected, the autonomous vehicle executes an emergency manoeuvre and stops in the emergency lane or on the side of the road. During the emergency manoeuvre, the car is remotely monitored; however, after the emergency stop, the vehicle needs to be moved to a safe location (next bus stop in case of an autonomous shuttle or nearby garage in case of an autonomous driving (AD) vehicle) by a teleoperated driver.  To enable and realise safe teleoperated driving, the Digital Twin service collects data from other onboard sensors, roadside unit sensors or other vehicles to build a virtual representation of the environment, which allows the remote driver to manoeuvre the vehicle to a safe location).

Ultra-low-latency communication between the Digital Twin service, roadside unit sensors, and other onboard sensors or other vehicles is required to build a correct and real-time representation of the road environment. The communication channel must also be reliable and undisturbed by general-purpose traffic. One variation of this UC envisions edge reallocation to the location near the vehicle to better achieve the required low-latency communication.

The use case requires a large volume of data for a short period of time (e.g., less than 10 min.) with low data latency– the communication is time-critical and safety-critical.

In this use case, the Digital Twin service requests the underlying V2X communication services to contact the telecommunication operator (5G network) via newly designed APIs about the high bandwidth, low-latency connection needed. The network operator checks the possibility of allocating the necessary resources in time based on the available resources in nearby base stations. The Digital Twin and V2X communication services then inform the remote teleoperator using the Digital Twin about the reply received from the network (positive or negative reply).