DOI: 10.5281/zenodo.7348969
title: FI, Remote Driving, Remote driving in a redundant network environment

description: Use Case Category: <strong>Remote Driving</strong><br> User Story: <strong>Remote driving in a redundant network environment</strong><br> Location: Finnish (FI) trial site According to 3GPP TS 22.186 R16, Remote Driving “enables a remote driver or a V2X application to operate a remote vehicle for those passengers who cannot drive themselves or a remote vehicle located in dangerous environments. For a case where variation is limited, and routes are predictable, such as public transportation, driving based on cloud computing can be used. In addition, access to cloud-based back-end service platform can be considered for this use case group”. User Story: <strong>Remote driving in a redundant network environment</strong> The remote driving of an SAE L4 vehicle is enabled by a V2N connection between the vehicular Onboard Unit (OBU) and a remote server hosting V2N applications, in this case the remote driving application is used by the remote human operator. The V2N connection transfers the sensor data feed (high resolution perception data) from the vehicle to the remote human operator (in the uplink direction). The sensor data provides the human operator a “driver’s view” allows the human operator to send appropriate command messages (e.g. command trajectories) back to the L4 vehicle (in the downlink direction). The remote control/driving of vehicle presents stringent requirements on connection between the vehicle and the Remote Operations Centre (ROC). These requirements include the need to ensure that human operator always maintains connectivity to the vehicle they control, the latency minimized to ensure timeliness of the downlink control messages from the human operator; and the uplink capacity is guaranteed for the transmission of the sensor data feeds from the vehicle. The whole control loop needs to keep tight. The accumulated delay from: sensor reading, sensor data processing, uplink, data visualization, manual control, control signal reading, downlink, and control signal processing to control must be kept low for direct control (depending on speed and dynamics of the vehicle). Furthermore, the vehicle should be aware of any latency issues, so that the operational speed could be adjusted accordingly. Remote driving (and other V2X use cases) will occur in multi-operator scenarios in legacy 4G [3GPP TR 36.885]4 and future 5G [3GPP 38.885]5 contexts, whereby, the L4 vehicle trajectory is an area covered by multiple public land mobile networks (PLMNs) or transitions between two PLMN coverage areas. The remote driving user story also underlines safety aspects and need for the L4 vehicle to maintain reliable/uninterrupted V2N connectivity. In practice, a vehicle’s home PLMN (original serving network) may have locations with poor or non-existent coverage, or then experience V2N connection degradation or failure due to overloading, network failure etc. To guarantee availability V2N connectivity for critical L4 vehicle services (such as, remote driving), the possibility of the vehicle to seamlessly switch to (or simultaneously utilise) a visited PLMN ensures safer operation of the vehicle regardless of instantaneous network conditions.