Las redes 5G se han definido alrededor de diversas tecnologías de virtualización que proporcionan a los operadores de red la capacidad de gestionar su infraestructura de una forma más ágil y programable. Mediante la aplicación de soluciones basadas en Multi-Access Edge Computig (MEC) y Network Slicing, los operadores de red pueden proporcionar a los proveedores de los servicios de conducción remota los niveles de calidad de servicio (fiabilidad, latencia y ancho de banda) que estos servicios demandan.
5G Automotive Association (5GAA) es un consorcio compuesto por tecnologías del sector del transporte y las telecomunicaciones cuyo objetivo es definir soluciones para la movilidad automática, cooperativa y conectada (Connected Cooperative and Automated Mobility o CCAM). En el seno del 5GAA se han realizado estudios para medir los requisitos de QoS que tienen los servicios de conducción remota. El caudal necesario para mandar al puesto de control los cuatro flujos de vídeo que se capturan en el vehículo remoto (frontal, laterales y trasera) es de 32 Mbps, considerando el uso del codec H.264. Según estos estudios, la transmisión de los flujos multimedia debe realizarse con un nivel de fiabilidad del 99%. Los comandos que se transmiten desde el puesto de control para manejar el vehículo remoto requieren un nivel de fiabilidad todavía mayor, un 99.99%.
Según los estudios realizados por el 5GAA la latencia es otro factor clave. Los comandos que se transmiten desde el puesto de control para manejar el vehículo remoto deben transmitirse en tiempo real, con una latencia inferior a los 20 ms. Aunque el requisito para transmitir los flujos multimedia es algo menos restrictivo (100 ms) se trata de un parámetro que afecta a la toma de decisiones del conductor remoto. Para satisfacer los requisitos de latencia hay que tener en cuenta que el tráfico de la aplicación sufre una cadena de retardos variables. Por ejemplo, la señal de video capturada en el vehículo remoto debe comprimirse, codificarse y transmitirse sobre la red hasta llegar al puesto de control remoto. Además, los procesos de traspaso o handover que se producen por la movilidad del vehículo pueden añadir retardos adicionales. Por tanto, se debe reducir el retardo de cada uno de los componentes de la cadena para que los requisitos de latencia del servicio se satisfagan.
Sin embargo, existen situaciones donde no es posible mantener los niveles de calidad de servicio que demandan los servicios de conducción remota. Por ejemplo, si se produce congestión en la red, la fiabilidad puede verse comprometida por el descarte de paquetes en los nodos de conmutación. Además, todos los flujos de tráfico reciben, por defecto, el mismo tratamiento. Sin embargo, el tráfico asociado a los comandos de control del vehículo debe conmutarse con mayor prioridad que el tráfico asociado a LHE, dado que los requisitos de latencia y fiabilidad son más restrictivos en el primer caso. Para realizar un tratamiento diferenciado de los flujos de tráfico del servicio Remote Driver, el proyecto analizará la aplicación de mecanismos de QoS basados en redes definidas por software (SDN).
Los procedimientos de traspaso, las interferencias o la falta de cobertura plantean escenarios donde el servicio puede sufrir degradaciones incluso si se aplican los mecanismos de QoS anteriores. Si el vehículo circula por trayectos donde hay una mala QoS, el conductor remoto debe reducir la velocidad para mantener un tiempo de reacción razonable, es decir, para que sea posible tomar decisiones en la carretera con suficiente antelación. En este caso, la duración del tiempo de viaje será mayor que si el vehículo circula por una ruta con una distancia más larga, pero donde la QoS de la red permite una velocidad de conducción mayor. Existe un caso extremo donde la conducción debe interrumpirse debido a que los niveles de QoS no permiten ofrecer el servicio. En este proyecto se propondrá un navegador que guíe al conductor por una ruta que minimice el tiempo en llegar al destino teniendo en cuenta la velocidad restringida por la vía y las condiciones de QoS de la red.
Los mecanismos propuestos deberán combinarse con soluciones de Network Slicing. Network Slicing es una técnica de virtualización de red que permite dedicar recursos de una infraestructura de red física y común a una red virtual. Las redes virtuales o slices que se crean sobre la infraestructura compartida están aisladas entre sí y satisfacen unos requisitos de QoS predeterminados. Si el tráfico del servicio Remote Driver compite con el tráfico de otras aplicaciones por los recursos de la red, se pueden producir congestiones que afecten al rendimiento del servicio. La creación de una slice de red para el servicio Remote Driver permitirá aislar el tráfico de esta aplicación del resto de tráfico que atraviese la red (multimedia, web, descarga de ficheros).
Para diseñar esta slice de red, otro factor que se debe tener en cuenta es el tamaño de la flota de vehículos tele-operados. Cuanto mayor sea el volumen de la flota mayor será la cantidad de recursos de red que haya que asignar a la slice del servicio. Un aumento en la demanda del servicio podría agotar los recursos de red que se han dedicado a la slice. En este caso, se incumplirían los requisitos de QoS que se han especificado anteriormente. A este respecto, existen varias soluciones: (1) sobredimensionar los recursos asignados a la slice para que se puedan absorber los picos de demanda. (2) implementar un mecanismo de asignación dinámica de recursos que tenga en cuenta la carga del servicio. El sobredimensionamiento, además de ser ineficiente, supone un mayor coste para el proveedor del servicio, por lo que se considerará la solución (2).
El sistema de navegación que se propuso anteriormente también puede influir en el mecanismo de asignación de recursos de las slice de red. El navegador podría avisar a la red del camino que se va a seguir, con lo que la red podría reservar recursos para el trayecto seleccionado por el navegador e incluso redirigir parte del tráfico vehicular a otro camino porque no es posible reservar recursos de la red en ese trayecto. Así, una de las actividades que se abordarán en este paquete de trabajo consiste en diseñar los mecanismos de despliegue y operación de la slice de red, teniendo en cuenta la demanda del servicio y las rutas seleccionadas por los sistemas de navegación. Se considerará la posibilidad de desplegar funciones de red virtualizadas (VNF) y aplicaciones en el borde de la red en la slice de red para reducir el volumen de tráfico que se intercambia entre el puesto de control y los vehículos remotos.