Implementación del protocolo GeoNetworking en un software de comunicación V2X

UNIVERSIDAD DE VALLADOLID E.T.S.I. TELECOMUNICACIÓN TRABAJO FIN DE MÁSTER MÁSTER EN INGENIERÍA DE TELECOMUNICACIÓN Implementación del protocolo GeoNetworking en un software de comunicación V2X Autor: D. José Luis Santamaría Corrales Tutor: D. Juan Carlos Aguado Manzano Valladolid, 21 de julio de 2022 TÍTULO: Implementación del protocolo GeoNetworking en un software de comunicación V2X AUTOR: D. José Luis Santamaría Corrales TUTOR: D. Juan Carlos Aguado Manzano DEPARTAMENTO: Teoría de la Señal y Comunicaciones e Ingeniería Telemática TRIBUNAL PRESIDENTE: D. Ramón Durán Barroso VOCAL: D. Ramón de la Rosa Steinz SECRETARIO: D. Javier Aguiar Pérez FECHA: 21 de julio de 2022 CALIFICACIÓN: Resumen del TFM Los Sistemas Inteligentes de Transporte Cooperativos (C-ITS) buscan aumentar la eficiencia del tráfico y mejorar la seguridad vial. Una tecnología clave en los C-ITS es la comunicación V2X. El objetivo de este Trabajo Fin de Máster es la implementación del protocolo GeoNetworking, parte de la arquitectura ETSI C-ITS estandarizada en la Unión Europea, en el software de comunicación V2X OpenC2X desarrollado en el grupo CCS Labs de la Universidad de Paderborn, Alemania. Para ello se ha realizado un estudio detallado de la evolución de los C-ITS y su estandarización en la Unión Europea, para pasar a analizar con mayor profundidad el protocolo GeoNetworking y su integración con el resto de la arquitectura de comunicación. Por último, se ha llevado a cabo el desarrollo del software que integra GeoNetworking en OpenC2X. Aunque GeoNetworking es un protocolo complejo, que maneja una gran cantidad de estructuras de datos auxiliares, se ha conseguido el intercambio de los mensajes CAM y DENM cumpliendo el formato indicado por el estándar, a pesar de no ser una implementación completa del protocolo. Sin embargo, el proceso de implementación nos ha permitido una revisión completa de OpenC2X y se ha llevado a cabo la actualización de varios módulos que utilizaban versiones anteriores de los estándares ETSI. Palabras clave V2X, C-ITS, GeoNetworking, OpenC2X, CAM, DENM, ETSI-5G, LTE-V2X Abstract Cooperative Intelligent Transport Systems (C-ITS) aim to increase traffic efficiency and improve road safety. V2X communication is a key technology for C-ITS development. The main purpose of this project is the implementation of the GeoNetworking protocol, part of the ETSI C-ITS architecture standardized in the European Union (EU), in the V2X communication software OpenC2X developed by the CSS Labs group of the University of Paderborn, Germany. For this purpose, a comprehensive study of the evolution of C-ITS and its standardization in the EU has been carried out, to proceed to a more in-depth analysis of the GeoNetworking protocol and its integration within the complete communication architecture. Finally, the development of the software which integrates GeoNetworking in OpenC2X has been carried out. Although GeoNetworking is a complex protocol, which handles a lot of auxiliary data structures, the exchange of CAM and DENM messages has been achieved in compliance with the format indicated in the standard, despite not being a complete implementation of the protocol. However, the implementation process has allowed a complete revision of OpenC2X and the update of several modules that used outdated versions of the ETSI standards had been done. Keywords V2X, C-ITS, GeoNetworking, OpenC2X, CAM, DENM, ETSI-5G, LTE-V2X Agradecimientos Me gustaría agradecer en primer lugar a Juan Carlos Aguado Manzano, mi tutor de este TFM, por toda su ayuda y guía durante la realización de este trabajo y muy especialmente por su paciencia y saber adaptarse a mi ritmo, seguramente muy diferente al que está acostumbrado. Y por supuesto agradecerle a mi familia, especialmente a mis padres y Elisa, por su infinita paciencia y todo lo que han trabajado durante la realización de este TFM para allanarme el camino y que pudiera finalizarlo. Este trabajo ha sido financiado por la Consejería de Educación de la Junta de Castilla y León y el Fondo Europeo de Desarrollo Regional (proyecto VA231P20), y el Ministerio de Ciencia e Innovación y la Agencia Estatal de Investigación (proyecto PID2020- 112675RB-C42 financiado por MCIN/AEI/10.13039/501100011033) Índices i ÍNDICE 1 Introducción .............................................................................. 1 1.1 Motivación .......................................................................................................... 1 1.2 Objetivos ............................................................................................................. 6 1.3 Fases y Métodos ................................................................................................. 7 1.4 Medios utilizados en la realización del TFM...................................................... 8 1.5 Estructura de la Memoria del TFM..................................................................... 8 2 Estado del arte ........................................................................ 11 2.1 Evolución histórica de los C-ITS ...................................................................... 11 2.1.1 Primeros pasos .......................................................................................... 11 2.1.2 Desarrollo del conjunto de estándares C-ITS europeo. ............................ 12 2.1.3 Despliegue actual de sistemas C-ITS........................................................ 15 2.2 Tecnologías inalámbricas V2X ......................................................................... 19 2.2.1 Tecnologías WiFi basadas en el estándar 802.11 ..................................... 19 2.2.2 Tecnologías basadas en redes celulares .................................................... 25 2.3 Software de comunicación V2X ....................................................................... 33 3 El protocolo GeoNetworking ................................................. 36 3.1 Esquemas de reenvío del enrutamiento geográfico .......................................... 36 3.1.1 GeoUnicast ............................................................................................... 37 3.1.2 GeoBroadcast ............................................................................................ 38 3.1.3 Topologically-scoped broadcast ............................................................... 38 3.2 Capa de Red y Transporte ITS. ......................................................................... 39 3.3 Servicios proporcionados por el protocolo GeoNetworking ............................ 40 3.4 Seguridad y privacidad ..................................................................................... 41 3.5 Direccionamiento GeoNetworking ................................................................... 41 ii Índices 3.6 Vectores de posición ......................................................................................... 43 3.6.1 Long Position Vector (LPV) ..................................................................... 43 3.6.2 Short Position Vector (SPV) ..................................................................... 44 3.7 Estructuras de datos ........................................................................................... 45 3.7.1 Location Table (LocT) .............................................................................. 45 3.7.2 Ego Position Vector (EPV) ....................................................................... 46 3.7.3 Sequence Number ..................................................................................... 47 3.7.4 Location Service Packet Buffer................................................................. 47 3.7.5 Forwarding packet buffer .......................................................................... 48 3.8 Estructura y formatos de paquetes GeoNetworking .......................................... 49 3.8.1 Basic Header ............................................................................................. 50 3.8.2 Common Header ....................................................................................... 51 3.8.3 Estructura de paquete completa................................................................. 53 3.9 Tipos de cabecera de paquete GeoNetworking ................................................. 53 3.9.1 Cabecera GUC........................................................................................... 54 3.9.2 Cabecera TSB ............................................................................................ 54 3.9.3 Cabecera SHB ........................................................................................... 55 3.9.4 Cabecera GBC/GAC ................................................................................. 56 3.9.5 Cabecera Beacon ....................................................................................... 57 3.9.6 Cabeceras LS Request y LS Reply ............................................................ 58 3.10 Servicios de datos GeoNetworking ................................................................... 60 3.10.1 Primitiva GN-Data.request ........................................................................ 60 3.10.2 Primitiva GN-Data.confirm ....................................................................... 62 3.10.3 Primitiva GN-Data.indication ................................................................... 63 3.11 Funcionamiento del protocolo ........................................................................... 64 3.11.1 Tratamiento de los paquetes ...................................................................... 65 4 Instalación de Vanetza y comunicación con OpenC2X .......... 70 Índices iii 4.1 Instalación de Kernel 5.13.8 ............................................................................. 70 4.2 Instalación de Vanetza ...................................................................................... 72 4.2.1 Requisitos de Vanetza ............................................................................... 72 4.2.2 Compilación de Vanetza ........................................................................... 73 4.2.3 Socktap ..................................................................................................... 73 4.3 Comunicación entre Vanezta y OpenC2X ........................................................ 74 4.3.1 Actualización de versión de protocolos ITS en OpenC2X ....................... 76 4.3.2 Actualización de los ASN.1 de CAM y DEMN ....................................... 77 5 Implementación del protocolo GeoNetworking en OpenC2X 80 5.1 Integración del servicio GeoNetworking en la arquitectura de comunicación de OpenC2X ...................................................................................................................... 80 5.2 Implementación de las primitivas de servicios de datos ................................... 82 5.3 Configuración del servicio GeoNetworking ..................................................... 86 5.4 Clase GeoNetService ........................................................................................ 88 5.5 Direcciones GeoNetworking y vectores de posición ........................................ 90 5.6 Envío de paquetes usando GeoNetworking ...................................................... 94 5.6.1 Función fillBasicHeader ( ) ...................................................................... 95 5.6.2 Función fillCommonHeader ( ) ................................................................ 96 5.6.3 Envío de mensajes CAM .......................................................................... 98 5.6.4 Envío de mensajes DENM ...................................................................... 102 5.6.5 Cambios en el DCC ................................................................................ 105 5.7 Recepción de paquetes usando GeoNetworking ............................................. 107 5.7.1 Procesado de paquetes SHB ................................................................... 109 5.7.2 Procesado de paquetes GBC ................................................................... 111 5.7.3 Recepción de la PDU en BTP ................................................................. 112 5.8 Compilación de OpenC2X .............................................................................. 112 5.9 Pruebas de comunicación ............................................................................... 113 Índices 11 ÍNDICE DE TABLAS Tabla 1: Servicios del día 1 ............................................................................................. 13 Tabla 2: Servicios del día 1,5 .......................................................................................... 14 Tabla 3: Comparativa de los parámetros principales de la capa PHY entre 802.11a y 802.11p ............................................................................................................................ 19 Tabla 4: Clases de tráfico ITS-G5 ................................................................................... 21 Tabla 5: Beneficios de 802.11bd sobre 802.11p [35] ...................................................... 23 Tabla 6: Comparación entre LTE-V2X y NR V2X (Sidelink) a 5.9GHz [46] ................ 33 Tabla 7: Valores del campo Next Header (NH) de la Basic Header [50] ....................... 50 Tabla 8: Codificación del subcampo LTbase [50] ............................................................. 51 Tabla 9: Valores del campo Next Header(NH) de la Common Header [50] .................. 52 Tabla 10: Tipos y subtipos de cabeceras GeoNetworking [50] ....................................... 52 Tabla 11: Clases de tráfico para ITS-G5 y LTE-V2X y su codificación en el campo TC ID ..................................................................................................................................... 53 Tabla 12: Valores de la cabecera Basic Header .............................................................. 65 Tabla 13: Valores de la cabecera Common Header ........................................................ 66 Tabla 14: Parámetros de la primitiva GN-Data.indication a enviar a la capa de transporte (SHB) ............................................................................................................................... 67 Tabla 15: Campos de la cabecera extendida GBC .......................................................... 67 Tabla 16: Parámetros de la primitiva GN-Data.indication a enviar a la capa de transporte (GBC) .............................................................................................................................. 69 12 Índices Glosario de términos AC: Access Class ASN: Abstract Syntax Notation BC: BroadCast BTP: Basic Transport Protocol C-ITS: Cooperative Intelligent Transport Systems C-V2X: Cellular Vehicle to Everything CAM: Cooperative Awareness Message CBF: Contention-Based Forwarding DAD: Duplicate Address Detection DE: Destination DENM: Decentralized Environmental Message EPV: Ego Position Vector FIFO: First In First Out GAC: Geographically-Scoped Anycast GBC: Geographically-Scoped Broadcast GF: Greedy Forwarding GN: GeoNetworking GN_ADDR: GeoNetworking ADDRess GN-PDU: GeoNetworking Protocol Data Unit GN-SDU: GeoNetworking Service Data Unit GN6-SDU: GN6 Service Data Unit GN6ASL: GeoNetworking to IPv6 Adaptation Sub-Layer GUC: Geographically-Scoped Unicast HST: Header Sub-Type HT: Header Type ITS: Intelligent Transport Systems LocT: Location Table LocTE: Location Table Entry LPV: Local Position Vector LS: Location Service LT: LifeTime LTE: Long Term Evolution LTE-V2X: Long Term Evolution Vehicle to Everything MAC: Medium Access Control MHL: Maximum Hop Limit MIB: Management Information Base MID: MAC ID MTU: Maximum Transmit Unit NH: Next Header OBD: On Board Diagnostic OBU: On Board Unit OCB: Out of the Context of a BSS OSI: Open Systems Interconnection PAI: Position Accuracy Indicator PCI: Protocol Control Information PDR: Packet Data Rate PDU: Protocol Data Unit PL: Payload Length POS: POSition PV: Position Vector RHL: Remaining Hop Limit RSU: Road Side Unit SAE: Society of Automobile Engineers SCF: Store Carry & Forward SDU: Service Data Unit SE: SEnder SHB: Single Hop Broadcast SN: Sequence Number SO: SOurce SPV: Short Position Vector ST: Station Type T-SDU: Transport Service Data Unit TAI: Temps Atomique International (International Atomic Time) TC: Traffic Class TC ID: Traffic Class Identifier TSB: Topologically Scoped Broadcast TST: TimeSTamp UC: UniCast UTC: Universal Time Coordinated V2I: Vehicle to Infrastructure V2V: Vehicle to Vehicle V2X: Vehicle-to-Everything WGS: World Geodetic System Índices xiii Capitulo 1: Introducción 1 1 Introducción 1.1 Motivación Los sistemas de transporte se han enfrentado históricamente a varios retos entre los cuales los más importantes son el aumento de la seguridad, la mejora de la eficiencia y la reducción de los efectos en la conducción de los fenómenos medioambientales adversos. Aunque la tendencia en el número de muertes en accidentes de tráfico es a la baja, con una disminución del 23% entre los años 2010 y 2019 en el conjunto de la Unión Europea y un 31% en España, aproximadamente 28.000 personas fallecieron en accidentes de tráfico en 2019 en Europa (último año representativo debido a las restricciones de movilidad impuestas en los diferentes países debido a la COVID-19). Además, se calcula que por cada fallecido otras 5 personas sufren heridas de gravedad que afectan de manera importante a su calidad de vida, lo cual representa de manera habitual un coste mayor para la sociedad en concepto de rehabilitación y gastos médicos. [1] Por otro lado, el transporte por carretera sigue siendo responsable de la mayor parte de las emisiones del conjunto del transporte, en lo que se refiere a gases de efecto invernadero y a contaminantes del aire, representado más del 70% de las emisiones de gas de efecto invernadero originadas por el transporte, el 39% de los óxidos de nitrógeno (NOx) y el 13% de las emisiones de partículas. No menos importante, a diario los atascos en las carreteras suponen grandes costes a la economía de la UE, estimados en el 1% del PIB. [2] Es por todo ello por lo que durante los últimos años ha habido un creciente interés en el desarrollo de los Sistemas Inteligentes de Transporte. Los Sistemas Inteligentes de Implementación del protocolo GeoNetworking en un software de comunicación V2X 2 Transporte (ITS) representan la aplicación de las Tecnologías de la Información y la Comunicación (TIC) al sector del transporte. Estas tecnologías están cada vez más presentes tanto en los vehículos como en las infraestructuras de transporte tales como semáforos, señales de tráfico, paneles informativos o sistemas de peaje. Los vehículos modernos incorporan un número creciente de sensores, radares y cámaras que captan tanto información propia como del entorno y las utilizan para ofrecer al conductor información útil para mejorar su percepción a la hora de conducir y tomar decisiones. También permiten el desarrollo de aplicaciones activas que ayudan a una conducción más segura y eficiente, conocidas como ADAS (Advanced Driver-Assistance Systems: Sistemas Avanzados de Asistencia al Conductor) entre las cuales se incluyen los reguladores de velocidad adaptativos, la detección de vehículos en los ángulos muertos, la detección de obstáculos y peatones con frenado activo de emergencia, los sistemas de asistencia al aparcamiento, etc. La posibilidad de compartir toda esta información con otros vehículos o con la infraestructura de transporte da lugar a los Sistemas de Transporte Inteligente Cooperativos (C-ITS), los cuales pueden tener un impacto significativo en el incremento de la seguridad en el transporte. Además, pueden incrementar la eficiencia del sector del transporte (incluyendo la eficiencia energética) y reducir la congestión del tráfico. Resumiendo, conducen a una movilidad más segura, sostenible y más limpia. [3] Es este intercambio de información el que da a los C-ITS su carácter cooperativo. Dicho intercambio se hace a través de las tecnologías de comunicación conocidas como comunicación V2X (Vehicle to Everything), término que engloba múltiples tecnologías: • V2V: Comunicación Vehículo a Vehículo directa. • V2I: Comunicación Vehículo a Infraestructura. Se utiliza para el intercambio de información con las denominadas Road Side Units (RSU), como pueden ser sistemas de peaje, paneles informativos, semáforos, etc. • V2P: Comunicación Vehículo a Peatón. Se utiliza para el intercambio de información con peatones y otro tipo de usuarios como ciclistas o usuarios de patinetes eléctricos. • I2I: Comunicación entre RSUs. • Otras variantes como V2M (Vehículo a Motocicleta) o V2N (Vehículo a red). Capitulo 1: Introducción 3 Figura 1: Ejemplos de comunicación V2X Las aplicaciones de los C-ITS son amplias: desde aviso de incidencias como frenada de emergencia de vehículos precedentes, aproximación de vehículos de emergencia, estado del tráfico y posibles retenciones o eventos como accidentes, hasta implementación de sistemas como las caravanas de camiones (platooning) o, en un futuro a medio plazo, el vehículo autónomo. El gran impacto positivo que los C-ITS pueden ejercer en la seguridad, el incremento de la eficiencia del transporte, incluida la energética, así como la reducción de la congestión del tráfico, puede reportar beneficios a nivel económico al hacer para los inversores más atractivos países y regiones donde los niveles de congestión y contaminación sean menores. Por otro lado, los consumidores se benefician de una mayor seguridad, un menor gasto energético y una información del tráfico más fiable. No menos importante, los C-ITS representan una oportunidad de negocio para la industria del sector del transporte, en especial la automovilística, al presentar un valor añadido a sus productos, incrementando su competitividad [3]. Es por ello que desde las instituciones ha habido un gran interés en promover soluciones estandarizadas que garanticen objetivos de interoperabilidad e interconectividad entre diferentes sistemas y servicios. En Estados Unidos, el IEEE (Institute of Electrical and Electronics Engineers) y la SAE (Society of Automobile Engineers) definieron un conjunto de estándares denominados DSRC (Dedicated Short Range Communication), término que en ocasiones Implementación del protocolo GeoNetworking en un software de comunicación V2X 4 se usa de forma generalizada para las diferentes soluciones basadas en WiFi, y en Europa el ETSI y CEN crearon una arquitectura llamada C-ITS. En ambos casos la tecnología utilizada para la capa de acceso se basaba en el estándar WLAN IEEE 802.11, concretamente la enmienda 802.11p, desarrollada específicamente para la comunicación en entornos vehiculares y que más tarde fue integrada en el estándar en 2012. En Europa, el Comité Técnico de ITS del ETSI estandarizó una versión adaptada a la banda de frecuencias de 5875-5925MHz, la banda asignada en Europa para los ITS, denominada ITS-G5. Posteriormente el 3GPP (3rd Generation Partnership Project) desarrolló una alternativa basada en redes celulares, denominada LTE-V2X o C-V2X, cuya primera versión se publicó en la release 14 del 3GPP en 2016. Estas dos tecnologías de comunicación V2X luchan por ser la tecnología estándar preferente para los C-ITS y, en un futuro, el vehículo autónomo. Como veremos posteriormente en el capítulo dedicado al estado del arte, ambas tecnologías presentan ventajas e inconvenientes y actualmente muchos de los trabajos que se están realizando se centran en conseguir la coexistencia de las dos. Pero la arquitectura de comunicación C-ITS no solo define la capa de acceso, sino que plantea una pila de protocolos completa, que sigue los principios del modelo OSI de protocolos de comunicación en capas extendido para la inclusión de las aplicaciones ITS. [4] Figura 2: Pila de protocolos de una estación ITS [5] La pila de protocolos define 3 capas horizontales más otras 2 entidades verticales, las capas de Gestión y Seguridad, que dan servicio de manera transversal al resto de capas y aplicaciones ITS en la parte superior: Capitulo 1: Introducción 5 • Capa de Tecnologías de Acceso: cubre las capas física y de enlace de datos del modelo de referencia OSI. • Capa de Red y Transporte: compuesto por protocolos para la entrega de datos entre estaciones ITS y la red. Incluyen el enrutamiento de datos entre la fuente y el destino a través de nodos intermedios. Es posible usar varios protocolos de Red, como IPv6 con extensiones para movilidad (NEMO: Network Mobility), CALM (Communications Access for Land Mobiles) y varios protocolos de transporte como UDP y TCP. Pero también en la arquitectura C-ITS se crearon dos nuevos protocolos de red y transporte: GeoNetworking y BTP (Basic Transport Protocol). • Capa de Servicios (Facilities): contiene funcionalidades de las capas de aplicación, presentación (por ejemplo, codificación y decodificación ASN.1, encriptación) y sesión (comunicación inter-host) con añadidos para C-ITS. En esta capa se definen protocolos muy importantes para las comunicaciones V2X como el protocolo CAM (Cooperative Awareness Messages), que permite el intercambio periódico de mensajes con información de estado crítica para el soporte de aplicaciones de seguridad y eficiencia, de manera que los vehículos puedan seguir la posición y movimiento de otros vehículos [6] o DEMN (Decentralized Environmental Notification Messages) que son mensajes de información relacionada con un evento que tenga un impacto importante en la seguridad de las carreteras o las condiciones del tráfico. [7] • Aplicaciones ITS: las aplicaciones que implementan los casos de uso para seguridad vial, eficiencia del tráfico, infotainment y negocio. • Gestión ITS: responsable de la configuración de una estación ITS, intercambio de información entre las diferentes capas y otras tareas. • Seguridad ITS: proporcionan servicios de seguridad y privacidad, incluyendo mensajes seguros en diferentes capas de la pila de protocolo, gestión de identidades y credenciales de seguridad y aspectos para plataformas seguras como firewalls, gateway de seguridad, hardware a prueba de modificaciones (tamper-proof). La capa de acceso ha sido estudiada anteriormente en los Trabajos Fin de Máster de Javier Fernández Pastrana [8] y la capa de Facilities en los Trabajos Fin de Grado de María Pilar Sánchez Martín[9] y Alejandro Lobo González [10]. En dichos trabajos, así como en el Trabajo Fin de Máster de Roberto Herreras Babón [11], se utilizó el software de comunicación OpenC2X [12], desarrollado por el grupo de investigación de sistemas Implementación del protocolo GeoNetworking en un software de comunicación V2X 12 Posteriormente, a principios del siglo XXI, el avance de las Tecnologías de la Información y las Comunicación (TICs), con la aparición de tecnologías inalámbricas cada vez más eficientes, el desarrollo de los sistemas GPS y la miniaturización y abaratamiento de los sistemas embebidos, propició la aparición de una ola de nuevas actividades de investigación y desarrollo tanto a nivel académico como de la industria, con proyectos como SAFESPOT, GeoNet, SEVECOM, DRIVE C2X o SCORE@F [6]. 2.1.2 Desarrollo del conjunto de estándares C-ITS europeo. Debido a la importancia de los problemas a resolver y al gran impulso económico que representan los C-ITS, un requisito fundamental para el desarrollo de los sistemas de comunicación V2X son los estándares internacionales, que proporcionan especificaciones para asegurar la interconexión entre (sub-)sistemas y componentes V2X, así como interoperabilidad entre las implementaciones de diferentes fabricantes [15]. En el caso de la Unión Europea se hace también necesario asegurar la interoperabilidad de los sistemas en toda la Unión. En 2008, el Comité de Comunicaciones Electrónicas (ECC: Electronic Communications Commitee) de la Conferencia Europea de Administraciones de Correo y Telecomunicaciones (CEPT: Conférence Européenne des Administration des Postes et des Télécommunications) publicó la Decisión Armonizada para el uso de la banda de 5.9GHz para los Sistemas Inteligentes de Transporte. En dicha decisión, se establece el uso de la banda de frecuencia de 5875-5905 MHz por parte de los ITS relacionados con seguridad vial, con una posible ampliación de 20MHz hasta los 5925MHz. Esto sirvió de base para la Decisión 2008/671/EC del 5 de agosto de la Comisión Europea en la que designaba el uso de esa banda de frecuencia en todos los Estados Miembros. [16] Una vez decidido el espectro a utilizar, la Comisión Europea publicó su mandato m453 [3] a finales de 2009, en el cual instaba a las organizaciones europeas de estandarización ETSI (European Telecommunications Standards Institute) y CEN (Comité Européen de Normalisation) a crear un conjunto mínimo de estándares C-ITS para asegurar la interoperabilidad entre las comunicaciones V2V, V2I/I2V y I2I. Tanto ETSI como CEN aceptaron formalmente dicho mandato para elaborar dicho conjunto mínimo y consistente de estándares, cuya primera versión, denominada Release 1, vio la luz en 2013. Capitulo 2: Estado del arte 13 La tecnología de acceso designada para la capa de enlace en la primera versión de dicha Release 1 dentro de la arquitectura C-ITS es la denominada ITS-G5, una tecnología WLAN de corto alcance (DSRC) basada en la tecnología inalámbrica 802.11p, que es una evolución del estándar 802.11a adaptado a las redes vehiculares. En 2014 la Comisión Europea creó la Plataforma para el despliegue de los sistemas C-ITS en la Unión Europea (C-ITS platform), que ofrece un instrumento operativo para el diálogo, el intercambio de conocimientos técnicos y la cooperación entre la Comisión, las partes interesadas del sector público de los Estados Miembros, las autoridades locales o regionales y las partes interesadas del sector privado, como los fabricantes de coches (reunidos desde 2002 en el Car 2 Car Communication Consortium), los fabricantes de equipos, los operadores de las carreteras y las telecomunicaciones, y los proveedores de servicios. La primera fase de trabajos de dicha plataforma dio como resultado un informe de expertos [17] en el que, entre otras cuestiones, se identificaron una serie de servicios de implantación prioritaria debido a sus beneficios sociales y a la madurez de la tecnología. Estos servicios fueron denominados “servicios del día 1” (Day-1 services) y se muestran en la Tabla 1. Notificaciones de ubicación peligrosa: • avisos de circulación lenta o congestionada y avisos sobre el tráfico; • avisos de obras en la carretera; • condiciones meteorológicas; • luz de frenado de emergencia; • vehículo de emergencia aproximándose; • otros peligros. Aplicaciones de señalización: • señalización en el vehículo; • límites de velocidad en el vehículo; • incumplimiento de la señalización / seguridad en los cruces; • solicitud de señalización prioritaria por parte de los vehículos designados; • señal luminosa verde para la velocidad óptima recomendada; • datos compartidos por el vehículo; • amortiguador de movimientos sísmicos (forma parte de la categoría «advertencia de peligro local» del Instituto Europeo de Normas de Telecomunicación, ETSI) Tabla 1: Servicios del día 1 A estos servicios se le añadieron una serie de servicios que, aunque sus especificaciones o estándares podrían no estar listos aún, se consideraban maduros y con Implementación del protocolo GeoNetworking en un software de comunicación V2X 14 gran interés por parte del mercado. Estos servicios fueron los denominados “servicios del día 1,5” (1,5 Day services), y se muestran en la Tabla 2. • información sobre estaciones de repostaje y de recarga para los vehículos que utilicen combustibles alternativos; • protección de los usuarios vulnerables de la vía pública; • gestión e información de los aparcamientos en la vía pública; • información sobre los aparcamientos que no se encuentran en la vía pública; • información sobre aparcamientos disuasorios; • navegación conectada y cooperativa para entrar y salir de las ciudades (primer y último kilómetro, aparcamiento, consejos sobre la ruta, semáforos coordinados); • información sobre el tráfico y enrutamiento inteligente. Tabla 2: Servicios del día 1,5 En cuanto a la tecnología de comunicación a utilizar, la plataforma consideraba esencial asegurar que los mensajes C-ITS se pudieran transmitir independientemente de la tecnología de comunicaciones subyacente (agnosticismo de capa de enlace) cuando fuera posible. Recomendaba además usar la tecnología ETSI ITS-G5 (IEEE802.11p) para comunicaciones de rango corto en la banda de 5.9GHz debido a que era la más madura y cercana a su despliegue, aunque estudiando si fuera posible incrementar la cobertura de los servicios C-ITS mediante la infraestructura de comunicaciones celular. Por otro lado, el 3GPP (3rd Generation Partnership Project) estandarizó en 2016 en su release 14 su versión de tecnología de comunicación V2X basada en redes celulares, conocida como LTE-V2X o C-V2X (Cellular Vehicule to Everything). Este estándar incluye un modo de comunicación directo, denominado LTE sidelink, que presenta una alternativa a los estándares basados en 802.11p como el ETSI ITS-G5. Varias compañías del sector de la automoción y las telecomunicaciones se unieron para formar la 5GAA (5G Automotive Association), que promueve el uso de la tecnología LTE-V2X. Esto abrió el debate, vigente a día de hoy, sobre cuál debería ser la tecnología de comunicación de corto alcance estándar preferente para el vehículo conectado y, en un futuro, el vehículo autónomo. Del lado de LTE-V2X se encuentran marcas como BMW, Daimler, Ford, Huawei, Samsung, Qualcomm e Intel mientras que la tecnología WiFi es defendida por marcas como General Motors, NXP, Volkswagen, Volvo, Renault o Toyota. [18] Capitulo 2: Estado del arte 15 El 13 de marzo de 2019 la Comisión Europea publicó su esperada acta delegada, la cual se mostraba a favor de un enfoque de “comunicación híbrida” donde se utilizaría la tecnología ITS-G5 para comunicación de corto alcance entre vehículos debido a que se había desarrollado específicamente con ese fin, había alcanzado la madurez, se había sometido a ensayos y se había implantado [19]. Esta se vería complementada con tecnologías de mayor alcance existentes como 3G o 4G para los servicios V2I. También se contempla una cláusula de revisión para facilitar la integración de las tecnologías LTE-V2X en un plazo de antes de 3 años desde la entrada en vigor del reglamento. Sin embargo, en julio de 2019 el Consejo Europeo rechazó dicha acta, basado en la recomendación del comité de transportes del Parlamento Europeo, con 21 de los 28 estados miembro votando en contra de la misma, en una decisión que los defensores de la tecnología DSRC ven influenciada políticamente por el lobby de telecomunicaciones ETNO, cuyos miembros han gastado gran cantidad de dinero invirtiendo en tecnología 5G. Por este motivo la Comisión Europea, recién elegida en 2019, deberá redactar una nueva propuesta al Parlamento y al Consejo Europeo con un enfoque “neutral”, que todavía no ha sido presentada. Mientras tanto, el ETSI ha ido ampliando su conjunto de estándares para integrar LTE-V2X en la arquitectura C-ITS, tanto a nivel de la capa de acceso [20] como en capas superiores, como definiendo la parte dependiente del medio del protocolo GeoNetworking [21], por lo que todo parece apuntar a una coexistencia de ambas tecnologías, lo cual plantea no pocos retos a resolver, ya que no son interoperables a nivel de acceso radioeléctrico y pugnan por el mismo espectro. La ETSI ha publicado en 2021 dos informes técnicos para la definición y evaluación de mecanismos de coexistencia en el mismo canal y en canales adyacentes entre ITS-G5 y LTE-V2X [22] [23], entre los cuales se encuentra la asignación de prioridades de acceso a los diferentes canales para cada tecnología concreta. 2.1.3 Despliegue actual de sistemas C-ITS. Aunque se esperaba que el despliegue de los sistemas C-ITS que ofrecerán los servicios de día 1 y vehículos que integrarán esta tecnología deberían haber empezado a Implementación del protocolo GeoNetworking en un software de comunicación V2X 16 generalizarse en 2019, a día de hoy dicha implantación es mínima. La plataforma C-Roads, una iniciativa conjunta de los estados miembro europeos y los operadores de carreteras para ensayar e implementar los servicios C-ITS con vistas a la armonización y la interoperabilidad transfronteriza [24], integra numerosos proyectos en los estados de la Unión Europea, entre los cuales se encuentran: • SCOOP@F, que ha realizado el despliegue de tecnología V2X utilizando ITS-G5 a lo largo de 2000Km de carretera, repartidos en 5 áreas de Francia, y 3000 vehículos PSA y Renault. • El pasillo C-ITS Rotterdam-Frankfurt-Viena, que implementa los servicios de advertencia de obras en carretera y utilización de datos del vehículo para la gestión mejorada del tráfico en una ruta que atraviesa tres países (Países Bajos, Alemania y Austria), probando la interoperabilidad transfronteriza de los C-ITS. • InterCor (Interoperable Corridors: Pasillos Interoperables): Es un proyecto que intenta conectar las iniciativas anteriores, el pasillo británico Londres-Dover e iniciativas C-ITS en Bélgica con el objetivo de ofrecer una red de pasillos que proporcionen continuidad de servicios C-ITS y servir como plataforma de pruebas de desarrollos presentes y futuros en Europa. [25] Capitulo 2: Estado del arte 17 Figura 3: Mapa de estaciones C-ITS en Europa (En Verde) [26] En España, también dentro de la plataforma C-Roads, se están desarrollando 5 pilotos: [27] • DGT 3.0, ubicado a lo largo de toda la red de carreteras de España con una extensión aproximada de 12270 km. Se implementará utilizando tecnologías de comunicación celulares (3G y 4G / LTE). • SISCOGA Extended, comprendido en la extensión que abarca el ya existente test site localizado en la ciudad de Vigo y su área metropolitana preparado para probar tecnología de la comunicación ITS-G5. Tendrá una extensión de 150 km. • Madrid, ubicado a lo largo de la vía "Calle 30" en Madrid, con aproximadamente 32 km. Los servicios C-ITS se implementarán utilizando tecnologías de comunicación híbrida. • Cantábrico, desarrollado a lo largo de 75 km en la zona norte de España utilizando tecnologías de comunicación híbrida. • Mediterráneo, implementado a lo largo de 125 km en secciones de carretera seleccionadas de Cataluña y Andalucía utilizando tecnología híbrida. Implementación del protocolo GeoNetworking en un software de comunicación V2X 18 Figura 4: Los 5 pilotos españoles [27] Durante este tiempo también han ido apareciendo nuevas aplicaciones y casos de uso para las tecnologías V2X y los C-ITS. Estas aplicaciones son denominadas del día 2 y posteriores. Figura 5: Hoja de ruta de casos de uso y servicios [28] Muchas de esas aplicaciones van dirigidas al desarrollo del vehículo autónomo y requieren de unos requisitos más exigentes que las anteriores en cuanto a rendimiento de tasa de datos, latencia, fiabilidad, etc. La mayoría de las tecnologías actuales no son capaces de cumplir estos requisitos, por lo que se está trabajando en el desarrollo de la evolución de ambas. Así IEEE está trabajando en la enmienda 802.11bd como evolución Capitulo 2: Estado del arte 19 a 802.11p y 3GPP en la tecnología 5G NR (New Radio) V2X, que vienen suplir las carencias de sus antecesoras para las nuevas aplicaciones [29]. 2.2 Tecnologías inalámbricas V2X 2.2.1 Tecnologías WiFi basadas en el estándar 802.11 El IEEE publicó en 2010 en su enmienda 6, Wireless Access in Vehicular Environments (WAVE), el estándar 802.11p, una adaptación del estándar 802.11 para su uso en entornos vehiculares. 802.11p está basado en 802.11a y comparten muchas características. En la capa física se utiliza OFDM (Orthogonal Frecuency Division Multiplexing) con 52 subportadoras (48 de datos y 4 para pilotos), solo que en el caso de 802.11p se utiliza en el modo de operación half-clocked, usando canales con anchos de banda de 10MHz, en vez de 20MHz. Las posibles tasas de transferencia son de 3, 4.5, 6, 9, 12, 18, 24 y 27Mbit/s siendo obligatorio el soporte de 3 Mbit/s, 6 Mbit/s y 12 Mbit/s. Se muestra la diferencia de los parámetros principales entre 802.11a y 802.11p en la Tabla 3. Parámetro 802.11a 802.11p Diferencia Bit rate (Mbit/s) 6, 9, 12, 18, 24, 36, 48, 54 3, 4.5, 6, 9, 12, 18, 24, 27 La mitad Esquema de modulación BPSK, QPSK, 16-QAM, 64-QAM BPSK, QPSK, 16-QAM, 64-QAM Sin cambios Tasa de código 1/2, 2/3, 3/4 1/2, 2/3, 3/4 Sin cambios Número de subportadoras 52 52 Sin cambios Duración de símbolo (µs) 4 8 El doble Intervalo de guarda (µs) 0.8 1.6 El doble Periodo de FFT (µs) 3.2 6.4 El doble Preámbulo (µs) 16 32 El doble Separación de subportadora (MHz) 0.3125 0.15625 La mitad Tabla 3: Comparativa de los parámetros principales de la capa PHY entre 802.11a y 802.11p Una de las características más importantes de 802.11p es el denominado modo OCB (Out of the Context of a BSS). En este modo se desactivan varios procedimientos de gestión como el escaneo de canal, autenticación y asociación, que consumen tiempo y no permiten la comunicación con acceso rápido y baja latencia que requiere un entorno vehicular donde los nodos tienen gran movilidad. De esta forma las estaciones pueden transmitir mensajes de forma directa e inmediata sin los correspondientes retardos debidos al intercambio de información de control. Implementación del protocolo GeoNetworking en un software de comunicación V2X 20 En la arquitectura C-ITS europea se utiliza una versión de 802.11p llamada ITS- G5, en el cual la capa PHY está adaptada a las bandas de frecuencias designadas para ITS en Europa. La asignación de frecuencias de ITS-G5 se muestra en la Figura 6. Figura 6: Distribución de canales de ITS-G5 [30] El canal de control CCH y los canales de servicio SCH1 y SCH2 (ITS-G5A) están dedicados a aplicaciones y servicios ITS de seguridad vial, mientras que los canales SCH3 y SCH4 (ITS-G5B) se usan para aplicaciones no relacionadas con la seguridad vial (eficiencia del tráfico, anuncios de servicio, etc.) [31]. La banda ITS-G5D está prevista para aplicaciones futuras. La Comisión Europea amplió en 2020 hasta 5935MHz el espectro dedicado a ITS, reservando los últimos 10MHz para sistemas de ferrocarril urbano, que también tienen prioridad en el canal SCH6, mientras que el SCH5 está priorizado para los sistemas por carretera [32]. En cuanto al canal SCH7 (ITS-G5C) es una banda compartida con BRAN, LAN y WLAN (de 5470 MHz a 5725 MHz) y pueden ser canales de 10MHz o 20MHz. Debido a que comparten el espectro con otros servicios requieren el uso de DFS (Dynamic Frequency Selection) [33], no disponible cuando se trabaja en el modo OCB, y solo son aplicables a comunicaciones V2I con una RSU como maestro DFS. Actualmente no se han concretado casos de uso para esta banda de frecuencias, con lo que no está claro qué aplicaciones podrían usar este canal. Para el Control de Acceso al Medio (MAC) 802.11p utiliza EDCA (Enhaced Distributed Coordination Access), que está basado en CSMA/CA (Carrier Sense Multiple Access with Collision Advoidance), pero añadiendo atributos de QoS. En CSMA/CA un nodo “escucha” el canal durante un periodo predeterminado de tiempo y si lo percibe como libre puede empezar a transmitir directamente. Si el canal se ocupa durante el periodo de escucha el nodo realiza un procedimiento de backoff, en el que tiene que abstenerse de acceder al medio durante un periodo aleatorio de tiempo. EDCA asigna diferentes prioridades de acceso al canal dependiendo de la clase de tráfico. SCH4 SCH3 SCH1 SCH2 CCH SCH5 SCH6 5725 MHz ITS-G5B ITS-G5A ITS-G5D ITS-G5C SCH7 5470 MHz 5855 MHz 5875 MHz 5905 MHz 5925 MHz Capitulo 2: Estado del arte 21 Cada nodo mantiene 4 colas, denominadas Clases de Acceso (AC: Access Class) con diferentes valores para el tamaño de la Ventana de Contención (CW: Contention Window) y el Espacio Entre Tramas para arbitraje (AIFS: Arbitration InterFrame Space). De esta manera el tráfico con mayor prioridad tiene mayor probabilidad de acceder al canal que el de menor prioridad. [34] Las tramas ITS-G5 tienen la asignación de Clase de Tráfico (TC: Traffic Class) [35] mostrada en la Tabla 4. TC AC Uso 0 AC_VO DENM de alta prioridad 1 AC_VI DENM 2 AC_BE CAM 3 AC_BK DENM Multisalto, otro tipo de datos Tabla 4: Clases de tráfico ITS-G5 Los requisitos que se fijaron para el diseño de 802.11p fueron soportar una velocidad relativa de hasta 200Km/h, tiempos de respuesta cercanos a 100ms y un alcance de comunicación de 1000m. Estos requisitos deberían ser suficientes para soportar las aplicaciones del día 1. La tecnología ITS-G5 se lleva desarrollando, testando, validando, documentando y perfeccionando durante una década, por lo que se puede considerar una tecnología madura. Se ha utilizado en los proyectos indicados anteriormente como SCOOP@F, Madrid 30 o SISCOGA Extended y Volkswagen la ha incluido en la última generación de su modelo VW Golf [18], el primer modelo de automóvil europeo producido en masa que integra tecnología V2X. Este hecho le ha hecho obtener el galardón Advanced de la Euro NCAP en 2020 [36]. Sin embargo, aunque el desempeño de 802.11/ITS-G5 es adecuado para muchos de los casos de uso del día 1 y día 1,5 se prevé que sea insuficiente para las nuevas aplicaciones que han ido apareciendo (aplicaciones del día 2 y posteriores), por lo que en marzo de 2018 se formó un Grupo de Estudio del IEEE denominado Nueva Generación Vehicular (NGV: Next Generation Vehicular) para trabajar en una nueva enmienda del estándar que recogiera los avances de 802.11 producidos en los últimos años y los aplicara a la comunicación V2X. Se creó así a finales un grupo de trabajo para desarrollar 802.11bd, la evolución de 802.11p con mejoras en la eficiencia espectral, incremento de la fiabilidad y del rango manteniendo compatibilidad hacia atrás con la actual tecnología V2X [37]. Implementación del protocolo GeoNetworking en un software de comunicación V2X 28 LTE-V2X define dos modos de comunicación sidelink. En el modo 3 la selección de recursos de radio utilizados, los sub-canales a utilizar, es gestionada por la estación base (eNB), por lo que solo está disponible cuando se encuentra bajo cobertura de la red celular. El estándar no define un algoritmo de gestión de recursos, cada operador puede implementar el suyo, que entra dentro de una de las dos siguientes categorías: • Dynamic Scheduling: Los vehículos solicitan sub-canales para cada transmisión de un paquete. Incrementa la sobrecarga de la señalización en la red celular y retrasa el envío de los paquetes. • SPS (Semi-Persistent Scheduling): la estación base reserva recursos de forma semipersistente para las transmisiones periódicas de un vehículo y decide cuanto tiempo se mantiene dicha reserva. Para hacer esta reserva de manera apropiada los vehículos deben de informar a la eNB del tamaño, prioridad y frecuencia de transmisión de los paquetes. En el modo 4 los vehículos seleccionan sus recursos de red de manera autónoma, independientemente de si se encuentran bajo cobertura de la red celular o no. Cuando los vehículos se encuentran bajo la red celular la estación base decide la configuración del canal V2X e informa a los vehículos de diversos parámetros configurables entre los que se encuentran la frecuencia de portadora del canal V2X, el pool de recursos V2X (qué subtramas del canal se utilizan para V2X), el esquema de sub-canalización, el número de subcanales por sub-trama y el número de RBs por sub-trama. Cuando los vehículos no están bajo cobertura celular utilizan un conjunto pre-configurado de parámetros en lugar de los indicados por la estación base. El estándar incluye la opción de dividir el pool de recursos V2X en base a áreas geográficas (Zoning), de forma que los vehículos en un área geográfica concreta solo puedo utilizar el pool de recursos asignados a dicha área. [42] El mecanismo utilizado por los vehículos para la selección de recursos de radio se denomina Sensing-based Semi-Persistent Scheduling, algoritmo definido en detalle por el 3GPP y que funciona básicamente de la siguiente forma: En la capa MAC, los recursos (sub-canales) son seleccionados aleatoriamente entre el conjunto recibido por la capa física y se mantiene hasta que un contador denominado Reselection Counter, que se decrementa con cada transmisión y cuyo valor se establece de forma aleatoria entre 5 y 15, llegue a 0. Cuando esto ocurra se mantendrán los mismos Capitulo 2: Estado del arte 29 recursos durante otro intervalo aleatorio con una probabilidad P, y volverán a ser seleccionados o reservados en otro caso. [42, 44] P es configurado por cada vehículo y puede tomar cualquier valor entre 0 y 0.8 de manera que valores más altos permiten a los vehículos mantener sus reservas durante más tiempo. Sin embargo, un valor alto de P puede ser contraproducente debido a la movilidad de los vehículos; dos vehículos que reservaron sus recursos cuando estaban fuera de sus respectivos alcances pueden interferirse entre ellos al entrar dentro de dicho alcance y mantener más tiempo dicha interferencia que si el valor de P fuera bajo. [45] También deberá realizarse una nueva reserva cuando el paquete o paquetes a transmitir no encaje en los recursos reservados. [43] En la capa física, se monitorizan los recursos durante 1 segundo, comparando las medidas de potencia recibida con un umbral dado (dependiente de la prioridad del paquete, establecida por las capas superiores en función de la relevancia y urgencia de la aplicación [42]) y leyendo los mensajes SCI que indican reservas futuras. Entre los recursos que se asuma que no que vayan a utilizar en el próximo intervalo de paquete (o una porción del mismo), el 20% menos interferido son seleccionados y pasado como candidatos a la capa MAC. Si el número de recursos estimados como libres es menos del 20% el umbral se incrementa 3dB y se repite el proceso. [44] En 2020 ETSI publicó el estándar que integra la capa de acceso de la arquitectura C-ITS usando el interfaz PC5, o sidelink, de LTE-V2X [20] y en el cual se definen los parámetros de LTE-V2X que se deben en usar en la Unión Europea. Como en el caso de 802.11p, los requisitos impuestos para LTE-V2X son suficientes para la mayoría de las aplicaciones de día 1 y día 1.5, pero insuficientes para las de día 2 y posteriores. El 3GPP publicó en 2020 su Release 16, que incluye el primer estándar V2X basado en la tecnología 5G New Radio (NR). El 5G NR V2X ha sido diseñado para complementar a LTE-V2X. Mientras que LTE-V2X soporta casos de uso de seguridad activa y gestión del tráfico básicos, 5G NR V2X soporta casos de uso más avanzados y mayores niveles de automatización con requisitos más exigentes de ancho de banda, fiabilidad y baja latencia. Algunos de estos casos de uso incluyen las caravanas de vehículos, el intercambio de datos de sensores entre vehículos, RSUs y peatones, la conducción remota y la conducción autónoma. [46] Implementación del protocolo GeoNetworking en un software de comunicación V2X 30 De manera análoga a LTE-V2X, NR V2X define dos modos de comunicación sidelink. En el modo 1 (controlado), equivalente al modo 3 de LTE-V2X, es la estación base (denominada gNodeB) la que organiza los recursos sidelink usando la interfaz Uu. Dicho modo solo es posible bajo la cobertura de la red celular. En el modo 2 (autónomo) los vehículos determinan de manera autónoma el conjunto de recursos a utilizar entre aquellos (pre-)configurados por la gNodeB/eNodeB. Este modo puede ser utilizado bajo condiciones de cobertura o fuera de cobertura de forma similar al modo 4 de LTE-V2X. El modo 2 y modo 4 tienen, sin embargo, varias diferencias en el esquema de planificación. [47] Mientras que el modo 4 de LTE-V2X está diseñado principalmente para el tráfico periódico el modo 2 de NR V2X introduce ajustes enfocados a satisfacer la necesidad de acomodar también tráfico aperiódico, como los DEMNs generados asíncronamente ante la detección de eventos de peligro (como un frenado de emergencia) o incluso CAMs, los cuales no son necesariamente periódicos, ya que su generación depende de la movilidad del vehículo que los transmite. [47] Las especificaciones de NR V2X definen dos bandas de frecuencias, FR1 para la banda por debajo de los 6GHz y FR2 para la banda por encima de los 6GHz entre 28-52GHz, considerada banda de onda milimétrica (mmWave), que puede cubrir rangos pequeños con alto rendimiento. La longitud de trama de radio NR V2X es de 10ms, conteniendo 10 subramas en el dominio del tiempo y 12 subportadoras en el dominio de la frecuencia. Los recursos están distribuidos en un espacio bidimensional de tiempo y frecuencia llamado pool de recursos, como en el caso de LTE-V2X. La información de control, al contrario que en LTE-V2X, está dividida en 2 etapas, denominadas stage-I SCI y stage-II SCI. El stage-I SCI contiene la información que es útil para notificar a los vehículos vecinos sobre los recursos reservados y ocupados por la UE transmisora. El stage-II SCI contiene información útil para la decodificación del TB. [48] La transmisión en 2 etapas del SCI simplifica su decodificación; los vehículos que sondeen el canal para conocer la ocupación de recursos solo necesitan decodificar el stage-I SCI. [47] Capitulo 2: Estado del arte 31 La capa física de NR V2X utiliza CP-OFDM (Cyclic Prefix Orthogonal Frequency- Division Multiplexing), la cual tiene mayor eficiencia espectral, mayor rendimiento, menor complejidad de implementación y mejor compatibilidad con tecnologías multi-antena. CP-OFDM está bien localizada en el dominio del tiempo, lo cual es importante para aplicaciones donde la latencia es crítica y para implementaciones TDD (Time-Division Duplex). También es más robusta frente a ruido de fase del oscilador y desviaciones de frecuencia Doppler que otras formas de onda multi-portadora, lo cual es crucial para mmWaves y V2X. Los turbo códigos de LTE son reemplazados por códigos LDPC (Low-Density Parity-Check) en NR V2X. En la Release 15, se ha añadido 64-QAM a las modulaciones QPSK y 16-QAM de LTE-V2X, mientras que NR V2X soporta también 256-QAM con código binario reflejado Gray. Los nuevos formatos de modulación pueden ser utilizados cuando las condiciones del canal son particularmente favorables, proporcionando ganancia en términos de eficiencia espectral y rendimiento a expensas de rango de cobertura. [47] Como en el caso de 802.11bd, NR V2X hace uso de numerología, que juega un papel clave a la hora de mantener la QoS requerida. Soporta un espaciado entre subportadoras flexible de 15, 30, 60, 120 y 240 KHz en cada subtrama de 1ms. Cada subtrama tiene un número diferente de slot dependiendo de la numerología, y cada slot contiene 14 símbolos OFDM, como puede verse en la Figura 11 [48]. Un espaciado mayor entre subportadoras implica una duración de slot menor, reduciendo la latencia, ideal para aplicaciones de seguridad críticas, y ofreciendo mejor resistencia al efecto Doppler a altas velocidades vehiculares [47]. Implementación del protocolo GeoNetworking en un software de comunicación V2X 32 Figura 11: Ejemplo de numerologías y su correspondiente duración de slot [48] NR V2X añade soporte de unicast, broadcast y groupcast. Algunas aplicaciones permiten incluso el uso de varios modos simultáneos, como platooning, donde el líder de la caravana se puede comunicar con el resto de miembros de la misma mediante groupcast pero enviar mensajes, como CAMs o DEMNs, a otros usuarios no miembros usando broadcast como se puede ver en la Figura 12. [29] Figura 12: Tipos de comunicación NR V2X [29] Capitulo 2: Estado del arte 33 Un resumen de las diferencias entre LTE-V2X y NR V2X se puede ver en la Tabla 6: Aspecto LTE-V2X Sidelink NR V2X Sidelink Forma de onda SC-FDMA CP-OFDM Codificación del canal Turbo LDPC Modulación QSPK, 16-QAM, 64-QAM QPSK, 16-QAM, 64-QAM y 256-QAM Numerología Fija: subtramas de 1ms Flexible: subtramas de 0.25ms, 0.5ms ó 1 ms Señales de referencia DMRS 4 símbolos fijos en 1 ms Varios patrones, entre 12 y 24 subportadoras SCI 2 PRBs, adyacentes o no adyacentes SCI en dos etapas dentro del slot de transmisión Feedback - ACK y NACK posibles Tipo de transmisión Broadcast Unicast, Groupcast y Broadcast Modo controlado Modo 3 Modo 1 Modo autónomo Modo 4 Modo 2 HARQ 1 retransmisión ciega Hasta 32 retransmisiones, ciegas o basadas en feedback Ventana de detección Opción única: 1s Dos opciones: 0.1s y 1,1s Porcentaje de CCSRs entregados de la capa PHY a MAC en modo autónomo 20% Un mínimo de 20%, 35% ó 50% Re-evaluación y re-selección de recursos No posible Posible Pre-emption No posible Posible Tabla 6: Comparación entre LTE-V2X y NR V2X (Sidelink) a 5.9GHz [47] 2.3 Software de comunicación V2X En los Trabajos de Fin de Grado realizados por Pilar Sánchez Martín [9] y Alejandro Lobo González [10] se realizó el estudio e implementación de RSU y OBU. Dicho trabajo fue ampliado por el Trabajo Fin de Máster de Roberto Herreras Babón [11]. En dichos trabajos se buscaron alternativas de software de comunicación V2X de código abierto que implementaran la pila de protocolos de la arquitectura ETSI C-ITS y se encontraron 3 posibles alternativas: OpenC2X [12], Vanetza [49] y GeoNetworking [50]. Ninguna de las tres alternativas implementaba la pila completa de protocolos, pero se decidió en su momento que OpenC2X era la que mejor se adaptaba a los proyectos y pruebas a desarrollar en dichos Trabajos de Fin de Estudio. OpenC2X implementa los mensajes CAM y DENM, la base de datos LDM, el servicio de posicionamiento mediante GPS y lectura de datos del vehículo mediante OBD- 2, así como el control de congestión descentralizado (DCC). Sin embargo, no implementa una de las partes fundamentales de la arquitectura: la capa de red y transporte ITS. Los protocolos principales de esta capa son el BTP y GeoNetworking, que se encargan del Implementación del protocolo GeoNetworking en un software de comunicación V2X 34 multiplexado de los mensajes de la capa de facilities y del enrutado de los paquetes respectivamente. Actualmente los servicios de la capa facilites enviaban sus mensajes al DCC y éste los trataba de manera independiente, rellenando las cabeceras correspondientes a los protocolos BTP y GeoNetworking de manera manual con valores fijos y realizando el procesamiento de los paquetes entrantes de la interfaz de red descartando todos los campos excepto los campos Header type y Header subtype, que indican el tipo de servicio de la capa facilities al que corresponde el mensaje, y los enviaban al servicio CA o DEN según correspondiera. Por ello era necesario, si queríamos tener una estación ITS completa conforme a la arquitectura ETSI, implementar la capa de red y transporte. Pero antes se decidió, ya que los trabajos de Pilar, Alejandro y Roberto tienen ya cierto tiempo, revisar si había alguna novedad en los softwares analizados. Tanto Geonetworking como OpenC2X no se han actualizado desde entonces, pero Vanetza se sigue manteniendo actualmente y va recibiendo mejoras y actualizaciones. Actualmente Vanetza implementa BTP, GeoNetworking, la capa transversal de seguridad y DCC. Asimismo, ofrece soporte para mensajes basados en ASN.1 como CAM y DENM. Por ello se decidió instalarlo para ver si era factible, en vez de desarrollar los protocolos faltantes en OpenC2X, montar las estaciones existentes con Vanetza. Sin embargo, al contrario que OpenC2X, Vanetza implementa una serie de librerías para crear nuestra propia aplicación V2X sobre ella, pero no es una aplicación como tal. Aunque incluye una pequeña aplicación, llamada Socktap, ésta es muy básica y solo permite el envío y recepción de CAMs periódicos y de mensajes Beacon, que veremos en más detalle en el próximo capítulo. Por ello se decidió que, en vez de realizar una nueva aplicación sobre Vanetza, se implementarían los protocolos BTP y GeoNetworking sobre OpenC2X. La implementación de BTP ha sido realizada por Daniel Monje González en su TFG [13]. Dicho trabajo ha sido muy útil para entender como OpenC2X realiza el intercambio de la información entre los diferentes servicios y las limitaciones de la implementación del DCC del mismo. En el presente Trabajo Fin de Máster se realizará la implementación de GeoNetworking. Capitulo 2: Estado del arte 35 Sin embargo, también se ha aprovechado la instalación de Vanetza para hacer pruebas de comunicación entre ambos y así comprobar la interoperabilidad entre dichos softwares, lo que nos proporciona una buena visión del cumplimiento de los estándares de ambos. Todos los detalles sobre la implementación de GeoNetworking y la instalación de Vanezta los veremos en los siguientes capítulos. Implementación del protocolo GeoNetworking en un software de comunicación V2X 36 3 El protocolo GeoNetworking El protocolo GeoNetworking es un protocolo de capa de red que proporciona enrutamiento de paquetes en una red ad hoc haciendo uso de las posiciones geográficas para el transporte de paquetes. Soporta la comunicación entre estaciones ITS individuales, así como la distribución de paquetes en zonas geográficas. GeoNetworking puede ejecutarse sobre diferentes tecnologías de acceso inalámbricas de corto acceso como ITS-G5 o LTE-V2X. Para ello se han divido la especificación del estándar entre la parte de funcionalidades independientes del medio [51], que son comunes a todas las tecnologías de acceso y la parte de funcionalidades dependientes del medio, que extienden la funcionalidad del protocolo para una tecnología inalámbrica concreta, como ITS-G5 [35] y LTE-V2X [21]. GeoNetworking apropiado para nodos altamente móviles y cambios frecuentes en la topología de la red. Además, su flexibilidad soporta los requisitos de aplicaciones heterogéneas incluyendo aplicaciones para seguridad vial, eficiencia del tráfico e infotainment. Permite, de manera más específica, la transmisión periódica de mensajes de estado de seguridad a alta tasa, diseminación multisalto rápida de paquetes en regiones geográficas para alertas de emergencia y el transporte de paquetes unicast para aplicaciones de Internet. 3.1 Esquemas de reenvío del enrutamiento geográfico El protocolo GeoNetworking proporciona básicamente dos funciones básicamente acopladas: direccionamiento geográfico y reenvío (forwarding) geográfico. GeoNetworking puede enviar paquetes de datos a un nodo por su posición o a múltiples nodos dentro de un área geográfica. Para reenvío, GeoNetworking asume que cada nodo tiene una vista parcial de la topología de red en sus alrededores y que cada paquete lleva Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 37 una dirección geográfica, tal como la posición o área geográfica como destino. Cuando un nodo recibe un paquete de datos compara la geo-dirección en el paquete de datos y la vista del nodo de la topología de red y realiza una decisión autónoma de reenvío. Como resultado los paquetes son reenviados “al vuelo”, sin necesidad de configuración y mantenimiento de tablas de enrutamiento en los nodos. El método más innovador para la transmisión de datos que habilita el enrutamiento geográfico es dirigir paquetes de datos a áreas geográficas concretas. De esta manera un vehículo puede seleccionar y especificar un área geográfica bien delimitada en la cual deben de ser entregados los paquetes. Los vehículos intermedios tienen la función de enviar la información y únicamente los vehículos que se encuentren dentro del área de destino procesan el mensaje y lo envían a la aplicación correspondiente. De esta manera se consigue que únicamente los vehículos que realmente estén afectados por una situación de peligro o una notificación de tráfico sean notificados, mientras que los vehículos no afectados no serán notificados. [52] Un ejemplo de este tipo de transmisión de datos sería el caso de un vehículo de emergencias que se acerca a una intersección y no va a respetar el semáforo y/o la prioridad que le corresponde en dicha intersección. De esta manera puede enviar un mensaje y que solo los vehículos en un área definida en torno a dicha intersección lo procesen y avisen al conductor de dicha eventualidad. Con casi total seguridad dicho área geográfica no se cubra totalmente por la cobertura de la señal de radio del vehículo, por lo que habrá vehículos intermedios, en la dirección a dicho área, que reenviarán el paquete. GeoNetworking define los siguientes esquemas de reenvío: 3.1.1 GeoUnicast Este esquema define una comunicación punto a punto entre dos estaciones ITS. Para ello la estación de origen determina la posición del destino y después envía el paquete a un nodo en dirección al destino, quien reenvía el paquete a lo largo del camino usando los nodos intermedios necesarios hasta que el paquete alcanza su destino. Implementación del protocolo GeoNetworking en un software de comunicación V2X 44 Figura 21: Long Position Vector [51] Figura 22: Campos del LPV [51] 3.6.2 Short Position Vector (SPV) Es una estructura de 20 octetos en los que se prescinde de alguno de los campos del LPV, como se puede ver en la Figura 23. Figura 23: Short Position Vector [51] Los campos son equivalentes a los definidos en la Figura 22. ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)22 9.5.2 Long Position Vector 9.5.2.1 Structure The Long Position Vector (LPV) shall consist of the fields specified in figure 7. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 GN_ADDR TST Lat Long PAI S H Figure 7: Long Position Vector 9.5.2.2 Fields The Long Position Vector (LPV) shall consist of the fields as specified in table 2. Table 2: Fields of Long Position Vector Field # Field name Octet/bit position Type Unit Description First Last 1 GN_ADDR Octet 0 Octet 7 64 bit address n/a Network address for the GeoAdhoc router entity in the ITS-S 2 TST Octet 8 Octet 11 32 bit unsigned integer [ms] Expresses the time in milliseconds at which the latitude and longitude of the ITS-S were acquired by the GeoAdhoc router. The time is encoded as: 32 ()mod2 TSTTSTTAI= where TST(TAI) is the number of elapsed TAI milliseconds since 2004-01-01 00:00:00.000 UTC 3 Lat Octet 12 Octet 15 32 bit signed integer [1/10 microdegree] WGS 84 [i.6] latitude and longitude of the GeoAdhoc router reference position expressed in 1/10 micro degree 4 Long Octet 16 Octet 19 32 bit signed integer [1/10 microdegree] 5 PAI Octet 20 Bit 0 Octet 20 Bit 0 1 bit unsigned integer n/a Position accuracy indicator of the GeoAdhoc router reference position Set to 1 (i.e. True) if the semiMajorConfidence of the PosConfidenceEllipse as specified in ETSI TS 102 894-2 [11] is smaller than the GN protocol constant itsGnPaiInterval / 2 Set to 0 (i.e. False) otherwise 6 S Octet 20 Bit 1 Octet 21 15 bit signed integer [1/100 m/s] Speed of the GeoAdhoc router expressed in signed units of 0,01 metre per second 7 H Octet 22 Octet 23 16 bit unsigned integer [1/10 degrees] Heading of the GeoAdhoc router, expressed in unsigned units of 0,1 degree from North ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)22 9.5.2 Long Position Vector 9.5.2.1 Structure The Long Position Vector (LPV) shall consist of the fields specified in figure 7. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 GN_ADDR TST Lat Long PAI S H Figure 7: Long Position Vector 9.5.2.2 Fields The Long Position Vector (LPV) shall consist of the fields as specified in table 2. Table 2: Fields of Long Position Vector Field # Field name Octet/bit position Type Unit D escription First Last 1 GN_ADDR Octet 0 Octet 7 64 bit address n/a Network address for the GeoAdhoc router entity in the ITS-S 2 TST Octet 8 Octet 11 32 bit unsigned integer [ms] Expresses the time in milliseconds at which the latitude and longitude of the ITS-S were acquired by the GeoAdhoc router. The time is encoded as: 32 ()mod2 TSTTSTTAI= where TST(TAI) is the number of elapsed TAI milliseconds since 2004-01-01 00:00:00.000 UTC 3 Lat Octet 12 Octet 15 32 bit signed integer [1/10 microdegree] WGS 84 [i.6] latitude and longitude of the GeoAdhoc router reference position expressed in 1/10 micro degree 4 Long Octet 16 Octet 19 32 bit signed integer [1/10 microdegree] 5 PAI Octet 20 Bit 0 Octet 20 Bit 0 1 bit unsigned integer n/a Position accuracy indicator of the GeoAdhoc router reference position Set to 1 (i.e. True) if the semiMajorConfidence of the PosConfidenceEllipse as specified in ETSI TS 102 894-2 [11] is smaller than the GN protocol constant itsGnPaiInterval / 2 Set to 0 (i.e. False) otherwise 6 S Octet 20 Bit 1 Octet 21 15 bit signed integer [1/100 m/s] Speed of the GeoAdhoc router expressed in signed units of 0,01 metre per second 7 H Octet 22 Octet 23 16 bit unsigned integer [1/10 degrees] Heading of the GeoAdhoc router, expressed in unsigned units of 0,1 degree from North ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)23 9.5.3 Short Position Vector 9.5.3.1 Structure The Short Position Vector (SPV) shall consist of the fields specified in figure 8. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 GN_ADDR TST Lat Long Figure 8: Short Position Vector 9.5.3.2 Fields The Short Position Vector (SPV) shall consist of the fields as specified in table 3. Table 3: Fields of Short Position Vector Field # Field name Octet/bit position Type Unit Description First Last 1 GN_ADDR Octet 0 Octet 7 64 bit address n/a GN_ADDR field as specified in table 2 2 TST Octet 8 Octet 11 32 bit unsigned integer [ms] Timestamp TST field as specified in table 2 3 Lat Octet 12 Octet 15 32 bit signed integer [1/10 microdegree] Latitude ( Lat ) field as specified in table 2 4 Long Octet 16 Octet 19 32 bit signed integer [1/10 microdegree] Longitude ( Long ) field as specified in table 2 NOTE: The timestamp TST field indicates the time when the position (LAT, LONG) of the SPV was acquired. 9.6 Basic Header 9.6.1 Composition of the Basic Header The Basic Header shall be present in every GeoNetworking packet and consists of the fields as depicted in figure 9. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 Version NH Reserved LT RHL Figure 9: Basic Header format Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 45 3.7 Estructuras de datos Para su funcionamiento correcto, el protocolo GeoNetworking necesita mantener varias estructuras de datos, como la Location Table, el Ego Position Vector, Sequence number, el Location Service Packet Buffer y el Forwarding Packet Buffer. 3.7.1 Location Table (LocT) Es una estructura local de datos que debe almacenar cualquier GeoAdhoc router y que almacena información sobre otras estaciones ITS que ejecutan el protocolo GeoNetworking. Cada entrada de la tabla, denominada Location Table Entry (LocTE), debe almacenar al menos los siguientes elementos: • La dirección GeoNetworking de la estación ITS: GN_ADDR. • La dirección de la capa de acceso de la estación ITS: LL_ADDR. • Tipo de estación ITS (vehículo, roadside unit, etc.) • La versión del protocolo GeoNetworking usada por la estación ITS. • Vector de posición de la estación ITS, compuesto por: - Posición geográfica POS(GN_ADDR); - Velocidad S(GN_ADDR); - Heading H(GN_ADDR); - Sello temporal de la posición geográfica TST(POS, GN_ADDR); - Indicador de exactitud de la posición PAI(POS, GN_ADDR); • Flag LS_PENDING(GN_ADDR): flag que indica que el Servicio de Ubicación (LS) está en progreso. • Flag IS_NEIGHBOURG(GN_ADDR): flag que indica que el GeoAdhoc router está en un rango de comunicación directo, es decir, es un vecino. Implementación del protocolo GeoNetworking en un software de comunicación V2X 46 • DPL(GN_ADDR): lista de paquetes duplicada para la GN_ADDR de origen. • Tasa de datos de paquete PDR(GN_ADDR) expresada como la Media Móvil Exponencial (EMA). En el caso de utilizar ITS-G5 el estándar añade los siguientes campos a cada LocTE, denominadas Location Table Entry Extensions for ITS-G5 (LocTEX-G5), para vecinos GeoNetworking en interfaces ITS-G5 [35]: • Sello temporal (local to ego station) de la última actualización de la LocTEX-G5, TST_G5(GN_ADDR). • Sello temporal en el Vector de Posición de la cabecera del paquete SHB, TST_SO_PV_G5(GN_ADDR). • Potencia transmitida del paquete que actualizó la entrada LocTEX-G5, TX_POWER_G5(GN_ADDR). • RSSI del paquete que actualizó la entrada LocTEX-G5, RSSI_G5(GN_ADDR). • CBR local diseminado recibido de GN_ADDR, CBR_R_0_HOP(GN_ADDR). • CBR de un salto diseminado. Las entradas de la LocT se añaden con un tiempo de vida T(LocTE), que se toma del valor de la constante de protocolo itsGnLifetimeLocTE, y se eliminan cuando dicho tiempo de vida expira. El flag LS_PENDING(GN_ADDR) debe de ser puesto a 0 cuando el flag no es renovado dentro del tiempo de vida 3 x itsGnBeaconServiceRetransmitTimer. 3.7.2 Ego Position Vector (EPV) El Vector de Posición Propio es una estructura de datos que almacena información relacionada con la posición del GeoAdhoc router local. Debe contener al menos los siguientes elementos: • Posición geográfica POS_EPV. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 47 • Velocidad S_EPV. • Dirección H_EPV. • Sello temporal de cuando fue generada la posición geográfica, TST_EPV. • Precisión de la posición geográfica PAI_EPV. Al inicio, todos estos elementos toman el valor 0 para indicar un valor desconocido. El EPV se actualiza con una frecuencia determinada por el valor de la constante de protocolo itsGnMinUpdateFrecuencyEPV o mayor. En el caso de una estación ITS estacionaria, el sello temporal del EPV se actualiza con una frecuencia igual o mayor al valor de itsGnMinUpdateFrecuencyEPV. Los campos de velocidad y dirección deberán fijarse a 0. Mientras la estación esté estacionaria el valor del campo de posición no debe cambiar. 3.7.3 Sequence Number Cada GeoAdhoc router debe mantener un número de secuencia local que determina el campo Sequence Number (SN) del siguiente paquete GeoNetworking a transmitir. Debe de ser inicializado a 0 y ser incrementado para cada paquete GeoNetworking P siguiendo la Fórmula 2: 𝑆𝑁(𝑃)=(𝑆𝑁(𝑃)+ 1)𝑚𝑜𝑑 𝑆𝑁_𝑀𝐴𝑋 Fórmula 2: Sequence Number SN_MAX es el número de secuencia máximo posible. El valor obtenido debe incluirse en el paquete GeoNetworking. El SN solo se incrementa solo para paquetes GeoNetworking multi-salto, los paquetes de salto único (BEACON, SHB) no lleva un campo SN. 3.7.4 Location Service Packet Buffer El Location Service es un servicio que obtiene el vector de posición para una dirección destino determinada y que es invocada por el origen cuando tiene una SDU del protocolo de transporte que enviar y no tiene dicha información de posición. Implementación del protocolo GeoNetworking en un software de comunicación V2X 48 Cuando se ejecute el LS el GeoAdhoc router debe encolar un paquete en un LS packet buffer para el destino buscado hasta que se complete el LS. Los paquetes subsecuentes, que se procesan mientras el LS está en proceso, también deben almacenarse. El tamaño mínimo de este buffer se almacena en la constante de protocolo GN itsGnLocationServicePacketBufferSize. El funcionamiento es el siguiente: • Los paquetes que lleguen al LS packet buffer para un destino determinado (GN_ADDR de una estación ITS) se almacenan en la cola de la fila. • Cuando llega un paquete nuevo al buffer y excede su capacidad (buffer overflow), los paquetes de la cabeza de la fila se eliminan y el paquete nuevo se almacena en la cola (head drop). • Cuando el LS se completa, se envían todos paquetes del buffer usando un esquema FIFO. • Cuando el tiempo en cola del paquete en el buffer excede el tiempo de vida especificado en el campo LT de la cabecera básica del paquete, este se descarta. • Cuando un paquete almacenado se envía se reduce el valor del campo LT por el tiempo que ha estado en la cola y, preferiblemente, se actualiza el SO PV. • Si el LS no se completa, todos los paquetes almacenados deben de ser descartados. 3.7.5 Forwarding packet buffer Los GeoAdhoc router deben utilizar buffers de encaminamiento de paquete (forwarding packet buffers) para almacenar temporalmente los paquetes durante el proceso de reencaminamiento. Deberá mantener al menos los siguientes buffers: • UC forwarding packet buffer para almacenar los paquetes GUC por GN_ADDR. • BC forwarding packet buffer para almacenar los paquetes TSB, GBC y GAC. Además, si el encaminamiento basado en contienda (CBF) está activado: Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 49 • la constante de protocolo itsGnNonAreaForwardingAlgorithm tiene el valor 2 (CBF) • la constante de protocolo itsGnAreaForwardingAlgorithm tiene el valor 2 (CBF) ó 3 (ADVANCED) • el router deberá mantener un CBF packet buffer. El tamaño mínimo de los buffers UC, BC y CBF viene determinado por las constantes de protocolo itsGnXXForwardingPacketBufferSize (XX = Uc, Bc o Cbf). El funcionamiento es similar para los tres, en el caso de los UC y BC forwarding packet buffer: • Los paquetes GeoNetworking se almacenan al final de la cola. • Cuando un paquete GeoNetworking llega y excede la capacidad del buffer los paquetes de la cabeza de la fila se eliminan y el paquete nuevo se almacena en la cola (head drop). • Cuando el buffer se vacía, los paquetes almacenados se encaminan usando un esquema FIFO. • Cuando el tiempo en cola del paquete en el buffer excede el tiempo de vida especificado en el campo LT de la cabecera básica del paquete, este se descarta. • Cuando un paquete almacenado se envía se reduce el valor del campo LT por el tiempo que ha estado en la cola y, preferiblemente, se actualiza el SO PV. • En el caso del buffer CBF los paquetes tienen un temporizador asociado, cuyo valor es fijado por el algoritmo CBF que cuando expira se elimina de la cola y se envía. En este caso el SO PV debe ser actualizado. 3.8 Estructura y formatos de paquetes GeoNetworking La cabecera de GeoNetworking sigue la estructura mostrada en la Figura 24: Implementación del protocolo GeoNetworking en un software de comunicación V2X 50 Figura 24: Cabecera GeoNetworking [51] El formato de la Basic Header y la Common Header es igual para los paquetes de todos los tipos de transporte, mientras que Extended Header es diferente. 3.8.1 Basic Header La cabera básica está presente en todos los paquetes GeoNetworking y sigue la estructura mostrada en las Figura 25 y Figura 26: Figura 25: Basic Header [51] Figura 26: Campos de la Basic Header [51] La versión actual del protocolo GeoNetworking indicada en [51] es la 1. El campo Next Header nos indica si estamos usando los mecanismos de seguridad y, por tanto, a la cabecera le sigue una cabecera de tipo Common Header o un paquete protegido por los mecanismos de seguridad definidos en [55] [54] como encriptación, certificados y firmas digitales. Se codifica como se muestra en la Tabla 7. Next Header (NH) Codificación Descripción ANY 0 Sin especificar Common Header 1 Cabecera GeoNetworking Common Header Secured Packet 2 Paquete GeoNetworking Secured Packet Tabla 7: Valores del campo Next Header (NH) de la Basic Header [51] ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)21 9.2.3 Maximum Transmit Unit The Maximum Transmit Unit (MTU), which the GeoNetworking protocol supports via the GN_SAP, i.e. the MTU_GN depends on the MTU of the access layer technology (MTU_AL) over which the GeoNetworking packet is transported. In particular, MTU_GN shall be less or equal to MTU_AL reduced by the size of the largest GeoNetworking protocol header (GEO_MAX) including Basic Header, Common Header and Extended Header and security overhead: MAXGEOALMTUGNMTU ___ -£ GEO_MAX is set by the GN protocol constant itsGnMaxGeoNetworkingHeaderSize. 9.3 GeoNetworking header structure The GeoNetworking header shall be comprised of a Basic Header, Common Header and an optional Extended Header (figure 5). Basic Header Common Header Extend ed Header (optional) Figure 5: GeoNetworking header structure Basic Header, Common Header and Extended Header are specified in clause 9.6, clause 9.7 and clause 9.8. NOTE: The composition of the Basic Header and Common Header equals for all packet transport types and differs for the Extended Header. 9.4 GeoNetworking Secured Packet The overall packet structure may be protected by security services as specified in ETSI TS 102 723-8 [i.2] and ETSI TS 103 097 [10], i.e. by digital signatures and certificates and by encryption. With enabled security (GN protocol constant itsGnSecurity is set to ENABLED), the overall packet structure is depicted in figure 6. Security operations are executed by the security entity via the SAP Sec_GN_SAP (figure 1) and as specified in clause 10.3 and annex L. Access Layer Header GeoNetworking Basic Header GeoNetworking Secured Packet with GeoNetworking Common Header, Optional Extended Header and Optional Payload Figure 6: GeoNetworking packet structure (with security) 9.5 Position vectors 9.5.1 Overview For simplicity, a set of position-related fields of the GeoNetworking header are subsumed to a position vector (PV). Two types of PV are defined: 1) Long position vector as specified in clause 9.5.2. 2) Short position vector as specified in clause 9.5.3. ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)23 9.5.3 Short Position Vector 9.5.3.1 Structure The Short Position Vector (SPV) shall consist of the fields specified in figure 8. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 GN_ADDR TST Lat Long Figure 8: Short Position Vector 9.5.3.2 Fields The Short Position Vector (SPV) shall consist of the fields as specified in table 3. Table 3: Fields of Short Position Vector Field # Field name Octet/bit position Type Unit Description First Last 1 GN_ADDR Octet 0 Octet 7 64 bit address n/a GN_ADDR field as specified in table 2 2 TST Octet 8 Octet 11 32 bit unsigned integer [ms] Timestamp TST field as specified in table 2 3 Lat Octet 12 Octet 15 32 bit signed integer [1/10 microdegree] Latitude ( Lat ) field as specified in table 2 4 Long Octet 16 Octet 19 32 bit signed integer [1/10 microdegree] Longitude ( Long ) field as specified in table 2 NOTE: The timestamp TST field indicates the time when the position (LAT, LONG) of the SPV was acquired. 9.6 Basic Header 9.6.1 Composition of the Basic Header The Basic Header shall be present in every GeoNetworking packet and consists of the fields as depicted in figure 9. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 Version NH Reserved LT RHL Figure 9: Basic Header format ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)24 9.6.2 Fields of the Basic Header The Basic Header shall carry the fields as specified in table 4. Table 4: Fields of the Basic Header Field # Field name Octet/bit position Type Unit Description First Last 1 Version Octet 0 Bit 0 Octet 0 Bit 3 4 bit unsigned integer n/a Identifies the version of the GeoNetworking protocol 2 NH Octet 0 Bit 4 Octet 0 Bit 7 4 bit unsigned integer n/a Identifies the type of header immediately following the GeoNetworking Basic Header as specified in table 5 3 Reserved Octet 1 Octet 1 8-bit unsigned integer n/a Reserved Set to 0 4 LT Octet 2 Octet 2 8 bit unsigned integer n/a Lifetime field. Indicates the maximum tolerable time a packet may be buffered until it reaches its destination Bit 0 to Bit 5: LT sub-field Multiplier Bit 6 to Bit 7: LT sub-field Base Encoded as specified in clause 9.6.4 5 RHL Octet 3 Octet 3 8 bit unsigned integer [hops] Decremented by 1 by each GeoAdhoc router that forwards the packet The packet shall not be forwarded if RHL is decremented to zero 9.6.3 Encoding of the NH field in the Basic Header For the Next Header (NH) field in the Basic Header the values as specified in table 5 shall be used. Table 5: Next Header ( NH ) field in the GeoNetworking Basic Header Next Header (NH) Encoding Description ANY 0 Unspecified Common Header 1 GeoNetworking Common Header as specified in clause 9.7 Secured Packet 2 GeoNetworking Secured Packet as specified in ETSI TS 103 097 [10] NOTE: The Common Header also carries a NH field. 9.6.4 Encoding of the LT field The Lifetime (LT) field shall indicate the maximum tolerable time a packet may be buffered until it reaches its destination. NOTE 1: This parameter is relevant for safety and traffic efficiency information that do not have strict real-time requirements. In sparse network scenarios, this lifetime may also be used to avoid re-transmission and forwarding of outdated information. NOTE 2: When a GeoNetworking packet is buffered, the value of the Lifetime (LT) field is reduced by the queuing time in the packet buffer. The following method for encoding of the LT field uses a non-linear encoding, which provides a high resolution for low numbers and progressively lower resolution for higher numbers. The LT field shall be comprised of two sub-fields: a LTMultiplier sub-field (Multiplier) and a LTBase sub-field (Base) (figure 10) and shall be encoded as follows: BaseMultiplierdecoded TLTLifetime ´= The LTBase sub-field represents a two bit unsigned selector that chooses one out of four predefined values as specified in table 6. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 51 En cuanto al tiempo de vida, se utiliza una codificación no lineal mediante el uso de dos parámetros, una base y un multiplicador, para ofrecer una resolución adecuada a todos los valores. Se codifica según la Fórmula 3 y la base puede tomar los valores mostrados en la Tabla 8. 𝐿𝑖𝑓𝑒𝑡𝑖𝑚𝑒 = 𝐿𝑇𝑏𝑎𝑠𝑒 ∗𝐿𝑇𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑑𝑜𝑟 Fórmula 3: Codificación del Tiempo de vida [51] Valor LTbase 0 50ms 1 1s 2 10s 3 100s Tabla 8: Codificación del subcampo LTbase [51] El tiempo por defecto es determinado por la constante de protocolo itsGnDefaultPacketLifetime, que debe de ser menor siempre de 600s como indica la constante de protocolo itsGnMaxPacketLifetime. 3.8.2 Common Header Al igual que la Basic Header, la Common Header está en todos paquetes GeoNetworking y sigue la estructura mostrada en las Figura 27 y Figura 28: Figura 27: Common Header [51] Figura 28: Campos de la Common Header [51] ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)25 Table 6: Encoding of LT sub-field LT Base Value LT base 0 50 ms 1 1 s 2 10 s 3 100 s The LTMultiplier is a 6 bit unsigned integer, which represents a multiplier range from 0 to 26 - 1 = 63. The default value of the LT field is set to the GN protocol constant itsGnDefaultPacketLifetime. The value shall be smaller than the GN protocol constant itsGnMaxPacketLifetime. 0 1 2 3 4 5 6 7 Multiplier [0 to 63] Base: 50 ms, 1 s, 10 s, 100 s Figure 10: Composition of the LT field 9.7 Common Header 9.7.1 Composition of the Common Header The Common Header shall be present in every GeoNetworking packet and consists of the fields as depicted in figure 11. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 NH Reserved HT HST TC Flags PL MHL Reserved Figure 11: Common Header format 9.7.2 Fields of the Common Header The Common Header shall carry the fields as specified in table 7. Table 7: Fields of the Common Header Field # Field name Octet/bit position Type Unit Description First Last 1 NH Octet 0 Bit 0 Octet 0 Bit 3 4 bit unsigned integer n/a Identifies the type of header immediately following the GeoNetworking headers as specified in table 8 2 Reserved Octet 0 Bit 4 Octet 0 Bit 7 4 bit unsigned integer n/a Reserved Set to 0 3 HT Octet 1 Bit 0 Octet 1 Bit 3 4 bit unsigned integer n/a Identifies the type of the GeoNetworking header as specified in table 9 4 HST Octet 1 Bit 4 Octet 1 Bit 7 4 bit unsigned integer n/a Identifies the sub-type of the GeoNetworking header as specified in table 9 5 TC Octet 2 Octet 2 8 bit unsigned integer n/a Traffic class that represents Facility-layer requirements on packet transport. Encoding is specified in clause 9.7.5 6 Flags Octet 3 Octet 3 Bit field n/a Bit 0: Indicates whether the ITS-S is mobile or stationary (GN protocol constant itsGnIsMobile ) Bit 1 to Bit 7: Reserve, set to 0 ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)25 Table 6: Encoding of LT sub-field LT Base Value LT base 0 50 ms 1 1 s 2 10 s 3 100 s The LTMultiplier is a 6 bit unsigned integer, which represents a multiplier range from 0 to 26 - 1 = 63. The default value of the LT field is set to the GN protocol constant itsGnDefaultPacketLifetime. The value shall be smaller than the GN protocol constant itsGnMaxPacketLifetime. 0 1 2 3 4 5 6 7 Multiplier [0 to 63] Base: 50 ms, 1 s, 10 s, 100 s Figure 10: Composition of the LT field 9.7 Common Header 9.7.1 Composition of the Common Header The Common Header shall be present in every GeoNetworking packet and consists of the fields as depicted in figure 11. 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 NH Reserved HT HST TC Flags PL MHL Reserved Figure 11: Common Header format 9.7.2 Fields of the Common Header The Common Header shall carry the fields as specified in table 7. Table 7: Fields of the Common Header Field # Field name Octet/bit position Type Unit Description First Last 1 NH Octet 0 Bit 0 Octet 0 Bit 3 4 bit unsigned integer n/a Identifies the type of header immediately following the GeoNetworking headers as specified in table 8 2 Reserved Octet 0 Bit 4 Octet 0 Bit 7 4 bit unsigned integer n/a Reserved Set to 0 3 HT Octet 1 Bit 0 Octet 1 Bit 3 4 bit unsigned integer n/a Identifies the type of the GeoNetworking header as specified in table 9 4 HST Octet 1 Bit 4 Octet 1 Bit 7 4 bit unsigned integer n/a Identifies the sub-type of the GeoNetworking header as specified in table 9 5 TC Octet 2 Octet 2 8 bit unsigned integer n/a Traffic class that represents Facility-layer requirements on packet transport. Encoding is specified in clause 9.7.5 6 Flags Octet 3 Octet 3 Bit field n/a Bit 0: Indicates whether the ITS-S is mobile or stationary (GN protocol constant itsGnIsMobile ) Bit 1 to Bit 7: Reserve, set to 0 Implementación del protocolo GeoNetworking en un software de comunicación V2X 52 El campo Next Header tiene en este caso un significado diferente al campo de igual denominación de la Basic Header, indica el tipo de entidad de protocolo superior y puede tener los valores indicados en la Tabla 9: Next Header (NH) Codificación Descripción ANY 0 Sin especificar. Se usa en los paquetes Beacon. BTP-A 1 Protocolo de transporte BTP-A (interactivo) como se define en [55] BTP-B 2 Protocolo de transporte BTP-B (no interactivo) como se define en [55] IPv6 3 Cabecera IPv6 como se define en [53] Tabla 9: Valores del campo Next Header(NH) de la Common Header [51] Los campos HT y HST representan el tipo de cabecera GeoNetworking, si se usa el tipo de transporte GBC, GUC, etc. o si es un paquete tipo Beacon o de petición/repuesta del Location Service. En el caso de los servicios con destino un área geográfica (GBC/GAC), el campo HST indica la forma de dicha área definida según [56]. La codificación de los campos HT/HST se indica en la Tabla 10: Header type (HT) Header Subtype (HST) Tipo Subtipo Descripción 0 0 ANY Unspecified Sin especificar 1 0 Beacon Unspecified Beacon 2 0 GeoUnicast Unspecified GeoUnicast 3 0 Geographically-Scoped Anycast Circular Area GAC de área circular 3 1 Rectangular Area GAC de área Rectangular 3 2 Ellipsoidal Area GAC de área elipsoidal 4 0 Geographically-Scoped Broadcast Circular Area GBC de área circular 4 1 Rectangular Area GBC de área Rectangular 4 2 Ellipsoidal Area GBC de área elipsoidal 5 0 Topologically-Scoped Broadcast Single-hop TSB 5 1 Multi-hop SHB 6 0 Location Service Request Petición Location Service 6 1 Reply Respuesta Location Service Tabla 10: Tipos y subtipos de cabeceras GeoNetworking [51] El campo TC, mostrado en la Figura 29, contiene dos bits de flags: SCF (Store- Carry-Forward) indica si el paquete debe almacenarse en el buffer si no hay un vecino adecuado. El bit Channel Offload indica si el paquete puede ser asignado a otro canal diferente al asignado en el campo TC ID. El campo TC ID es específico para cada tecnología de acceso como se detalla en la Tabla 11: Figura 29: Campo TC de la Common Header Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 53 ITS-G5 [55] LTE-V2X [20] USO TC UP (802.1d) AC (802.11) PPPP 0 7 AC_VO 2 DENM alta prioridad 1 5 AC_VI 4 DENM de prioridad normal 2 3 AC_BE 5 CAM 3 1 AC_BK 7 DEMN reenviados y otros paquetes de baja prioridad Tabla 11: Clases de tráfico para ITS-G5 y LTE-V2X y su codificación en el campo TC ID 3.8.3 Estructura de paquete completa A partir de la cabecera GeoNetworking, una trama/paquete completo presentarían la estructura que se muestra en la Figura 30 para el caso de no usar mecanismos de seguridad, o la Figura 31 para el caso de usar los mecanismos de seguridad (si el valor de la constante de protocolo itsGnSecurity es ENABLED): Figura 30: Estructura de paquete completa (Sin seguridad) [51] Figura 31: Estructura de paquete completa (con seguridad) [51] La cabecera de la capa de enlace es específica de la tecnología de capa de enlace utilizada (ITS-G5, LTE-V2X, etc.) y el protocolo no se encarga de ella, aunque si indicará (dependiendo del tipo de transporte utilizado) la dirección de capa de enlace con el objeto de identificar el siguiente salto de un paquete GeoNetworking. La carga (Payload) la componen los datos recibidos de la entidad de capa superior, como BTP, con el objeto de ser enviados. No todos los tipos de paquete tienen este campo. 3.9 Tipos de cabecera de paquete GeoNetworking El protocolo establece varios tipos de cabecera de paquete, dependiendo del tipo de transporte (GeoUnicast, GeoBroadcast, Topologically Scooped, etc.) a utilizar o si son paquetes de asistencia al funcionamiento del protocolo como los Beacon o los correspondientes al Location Service. Todos estos tipos de cabecera comparten el mismo formato, como ya se ha indicado, de Basic Header y Common Header a las que se añade una Extended Header que es diferente para cada tipo. ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)20 3) Every GeoNetworking packet in the buffer is associated with a timer. When the timer expires the GeoNetworking packet is removed from the queue and sent. 4) When a stored GeoNetworking packet is sent: a) the LT field shall be reduced by the queuing time in the CBF packet buffer; NOTE 2: Due the encoding of the LT field (see clause 9.6.4) the reduction of the LT field by the queuing time may not have an effect. b) the SO PV in the sent packet should be updated. NOTE 3: When security is enabled, i.e. the GN protocol constant itsGnSecurity is set to ENABLED, and the local GeoAdhoc router is the source of the GeoNetworking packet, the signature may need to be updated. Signatures of forwarded packets are not updated. NOTE 4: The value of the timer is set by the CBF forwarding algorithm specified in clause E.3. 9 GeoNetworking packet structure and formats 9.1 Overview This clause specifies the structure and the format of the GeoNetworking packet. 9.2 Packet structure 9.2.1 General As specified in ETSI EN 302 636-3 [4], the GeoNetworking protocol shall either be used in the GeoNetworking protocol stack (see ETSI EN 302 636-3 [4], clause 7.3.2) or in the protocol stack that combines the GeoNetworking protocol and IPv6 (see ETSI EN 302 636-3 [4], clause 7.3.4). 9.2.2 Overall packet structure A GeoNetworking packet is part of the overall frame/packet structure depicted in figure 4 (without security) and figure 6 (with security), respectively: 1) The Access Layer header is the header of the specific ITS access layer technology with which the packet is transmitted. NOTE 1: The Access Layer header is not specified by the present document. However, the GeoNetworking protocol sets the MAC address, or more generally the link layer address, in order to define and identify the next hop of a GeoNetworking packet. 2) The GeoNetworking header is the header of the GeoNetworking packet as defined in the present document. 3) The optional payload represents the user data that are created by upper protocol entities, i.e. the T-SDU or GN6-SDU. It is passed to the GeoNetworking protocol for transmission. NOTE 2: Some GeoNetworking packets do not carry a payload, such as Beacon. Acce ss Layer Header GeoNetworking Header Payload (optional) Figure 4: GeoNetworking packet structure (without security) ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)21 9.2.3 Maximum Transmit Unit The Maximum Transmit Unit (MTU), which the GeoNetworking protocol supports via the GN_SAP, i.e. the MTU_GN depends on the MTU of the access layer technology (MTU_AL) over which the GeoNetworking packet is transported. In particular, MTU_GN shall be less or equal to MTU_AL reduced by the size of the largest GeoNetworking protocol header (GEO_MAX) including Basic Header, Common Header and Extended Header and security overhead: MAXGEOALMTUGNMTU ___ -£ GEO_MAX is set by the GN protocol constant itsGnMaxGeoNetworkingHeaderSize. 9.3 GeoNetworking header structure The GeoNetworking header shall be comprised of a Basic Header, Common Header and an optional Extended Header (figure 5). Basic Header Common Header Extended Header (optional) Figure 5: GeoNetworking header structure Basic Header, Common Header and Extended Header are specified in clause 9.6, clause 9.7 and clause 9.8. NOTE: The composition of the Basic Header and Common Header equals for all packet transport types and differs for the Extended Header. 9.4 GeoNetworking Secured Packet The overall packet structure may be protected by security services as specified in ETSI TS 102 723-8 [i.2] and ETSI TS 103 097 [10], i.e. by digital signatures and certificates and by encryption. With enabled security (GN protocol constant itsGnSecurity is set to ENABLED), the overall packet structure is depicted in figure 6. Security operations are executed by the security entity via the SAP Sec_GN_SAP (figure 1) and as specified in clause 10.3 and annex L. Access Layer Header GeoNetworking Basic Header GeoNetworking Secured Packet with GeoNetworking Common Header, Optional Extended Header and Optional Payload Figure 6: GeoNetworking packet structure (with security) 9.5 Position vectors 9.5.1 Overview For simplicity, a set of position-related fields of the GeoNetworking header are subsumed to a position vector (PV). Two types of PV are defined: 1) Long position vector as specified in clause 9.5.2. 2) Short position vector as specified in clause 9.5.3. Implementación del protocolo GeoNetworking en un software de comunicación V2X 60 En este proceso pueden intervenir nodos intermedios, que reenvían la información hasta llegar al destino, como muestra la Figura 48. Figura 48: Secuencia de funcionamiento del Location Service [51] 3.10 Servicios de datos GeoNetworking El estándar define varias primitivas de servicios de datos, que permiten a las entidades de protocolos de transporte ITS mandar y recibir PDUs a través del GN_SAP. 3.10.1 Primitiva GN-Data.request Es utilizada por la entidad de protocolo de transporte ITS para solicitar enviar un paquete GeoNetworking. Cuando el protocolo GeoNetworking recibe una primitiva de servicio GN-Data.request realiza las operaciones para crear y enviar el correspondiente paquete GeoNetworking a la capa de acceso. Los parámetros de la primitiva son los indicados en la Figura 49. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 61 Figura 49: Primitiva GN-Data.request [51] El estándar no especifica exactamente como deben de ser los parámetros de dicha primitiva, más allá de las unidades de alguno de ellos. Los campos más importantes para nuestra implementación son los siguientes: • Upper protocolo entity: indica si la petición la realiza un protocolo de transporte específico de ITS, como BTP, o la sub-capa de adaptación GeoNetworking a IPv6 (GN6ASL). • Packet transport type: indica el tipo de transporte del paquete (GUC, SHB, TSB, GBC o GAC). Los paquetes de tipo Beacon y LS request/reply son paquetes de gestión del funcionamiento del protocolo y son generados por la propia entidad GeoNetworking, por lo que no son solicitados por las capas superiores. • Destination: especifica la dirección GeoNetworking, u opcionalmente el campo MID de la misma con el resto de campos establecidos a 0, del destino para GeoUnicast o el área geográfica para GeoAnycast/GeoBroadcast. • Communication profile: indica el tipo de entidad de protocolo de capa de enlace (ITS-G5 o LTE-V2X). • Maximum lifetime: especifica el máximo tiempo tolerable (en s) que un paquete puede ser almacenado hasta que alcance el destino. Si no se usa se toma el valor de itsGnDefaultPacketLifetime. ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)92 Annex J (informative): GeoNetworking data services J.1 General The GN data service primitives allow entities of ITS transport protocols to send and receive PDUs via the GN_SAP. J.2 GN-DATA.request The service primitive GN-DATA.request is used by the ITS transport protocol entity to request sending a GeoNetworking packet. Upon reception of the service primitive GN-DATA.request, the GeoNetworking protocol delivers the GeoNetworking packet to the LL protocol entity via the IN_SAP. The parameters of the GN-DATA.request are as follows: GN-DATA.request ( Upper protocol entity, Packet transport type, Destination address, Communication profile, Security profile, (optional) ITS-AID length, (optional) ITS-AID, (optional) Security permissions length, (optional) Security permissions, (optional) Security context information, (optional) Security target ID list length, (optional) Security target ID list,(optional) Maximum packet lifetime, (optional) Repetition interval, (optional) Maximum repetition time, (optional) Maximum hop limit, (optional) Traffic class, Length, Data ) The Upper protocol entity parameter specifies whether the service primitive was triggered by an ITS Transport protocol (e.g. BTP) or by the GeoNetworking to IPv6 Adaptation Sub-Layer (GN6ASL). The Packet transport type parameter specifies the packet transport type (GUC, SHB, TSB, GBC, GAC). The Destination parameter specifies the destination address for GeoUnicast or the geographical area for GBC/GAC. The destinations address for GeoUnicast can optionally contain the MID field only; with the other fields set to 0 (see figure 3 and table 1). The Communication profile parameter determines the LL protocol entity. The Security profile parameter determines the security service to invoke. The ITS-AID length parameter specifies the length of the value provided in the ITS-AID parameter. The ITS-AID parameter specifies the ITS-AID for the payload to be sent. The Security permissions length parameter specifies the length of the value provided in the Security permissions parameter. The Security permissions parameter specifies the SSP associated with the ITS-AID. The Security context information parameter specifies information to be used to selecting properties of the security protocol. The Security target ID list length parameter specifies the length for the value of the SecurityTarget ID List parameter. Implementación del protocolo GeoNetworking en un software de comunicación V2X 62 • Repetition Interval: indica el tiempo entre dos transmisiones consecutivas del mismo paquete (en ms). Es opcional. • Maximum repetition time: especifica el tiempo (en ms) durante el cual un paquete será repetido si está establecido un intervalo de repetición. • Maximum Hop limit: número de saltos que puede tener un paquete en la red. • Traffic class: especifica la clase de tráfico del mensaje. • Length: especifica la longitud de los datos que se envían en el parámetro Data. • Data: representa la carga del paquete GeoNetworking a enviar, es decir, la SDU de BTP o GN6ASL(T-SDU/GN6-SDU). 3.10.2 Primitiva GN-Data.confirm Se utiliza para confirmar que el paquete GeoNetworking ha sido procesado con éxito en respuesta a una petición GN-Data.request. No se especifica qué debe hacer cuando la entidad de protocolo superior, como BTP, recibe esta primitiva. Los parámetros de la primitiva son los indicados en la Figura 50. Figura 50: Primitiva GN-Data.confirm [51] El código ResultCode indica si la primitiva GN-Data.request ha sido: 1. aceptada; 2. rechazada debido a que el tamaño de la T/GN6-PDU supera al indicado en la constante de protocolo itsGnMaxSduSize; 3. rechazada debido a que el tiempo de vida supera el valor máximo indicado en la constante de protocolo itsGnMaxPacketLifetime; 4. rechazada debido a que el intervalo de repetición es menor que el valor indicado en la constante de protocolo itsGnMinPacketRepetitionInterval; 5. rechazada debido a clase de tráfico no soportada; ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)93 The Security target ID list parameter specifies an unordered collection of target IDs used by the security entity, for specifying multiple recipients. The Maximum lifetime parameter specifies the maximum tolerable time in [s] a GeoNetworking packet can be buffered until it reaches its destination. The parameter is optional. If it is not used, the GN protocol constant itsGnDefaultPacketLifetime is used. The Repetition interval parameter specifies the duration between two consecutive transmissions of the same GeoNetworking packet during maximum repetition time of a packet in [ms]. The parameter is optional. If it is not used, the packet is not repeated. The Maximum repetition time parameter specifies the duration in [ms] for which the packet will be repeated if the Repetition interval is set. The parameter is optional; if the Repetition interval is not used, it is omitted. The Maximum Hop Limit specifies the number of hops a packet is allowed to have in the network, i.e. how often the packet is allowed to be forwarded. The Traffic class parameter specifies the traffic class for the message. The Length parameter indicates the length of the Data. The Data parameter represents the payload of the GeoNetworking packet to be sent, i.e. the T-SDU/GN6-SDU. J.3 GN-DATA.confirm The service primitive GN-DATA.confirm is used to confirm that the GeoNetworking packet was successfully processed in response to a GN-DATA.request. For the reception of the primitive, no behaviour is specified. The parameters of the service primitive are as follows: GN-DATA.confirm ( ResultCode ) The ResultCode parameter specifies whether the service primitive GN-DATA.request is: 1) accepted; 2) rejected due to maximum length exceeded if the size of the T/GN6-PDU exceeds the GN protocol constant itsGnMaxSduSize; 3) rejected due to maximum lifetime exceeded if the lifetime exceeds the maximum value of the GN protocol constant itsGnMaxPacketLifetime; 4) rejected due to repetition interval too small, if the repetition interval is smaller than the GN protocol constant itsGnMinPacketRepetitionInterval; 5) rejected due to unsupported traffic class; 6) rejected due to geographical area exceeds the maximum geographical area size in the GN protocol constant itsGnMaxGeoAreaSize; or 7) rejected for unspecified reasons if the service primitive GN-DATA.request cannot be accepted for any other reason. J.4 GN-DATA.indication The service primitive GN-DATA.indication indicates to an upper protocol entity that a GeoNetworking packet has been received. The service primitive is generated by the GeoNetworking protocol to deliver data contained in a received GeoNetworking packet to upper protocol entity. The data of the GeoNetworking packet are processed as determined by the receiving upper protocol entity. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 63 6. rechazada debido a que el tamaño del área geográfica excede el valor máximo indicado en la constate de protocolo itsGnMaxGeoAreaSize; o 7. rechazada sin motivo específico si la primitiva GN-Data.request no puede ser aceptada por cualquier otra razón. 3.10.3 Primitiva GN-Data.indication Indica a una entidad de protocolo superior que se ha recibido un paquete GeoNetworking. Es generada por el protocolo GeoNetworking para entregar los datos contenidos en un paquete GeoNetworking a la entidad de protocolo superior, que se encargará de procesar dicha información. Los parámetros de la primitiva se muestran en la Figura 51. Figura 51: Primitiva GN-Data.indication [51] Los campos más importantes para nuestra implementación son los siguientes: • Upper protocolo entity: determina la entidad de protocolo que procesa la primitiva de servicio (BTP o GN6). • Packet transport type: indica el tipo de transporte del paquete (GUC, SHB, TSB, GBC o GAC) del paquete recibido. • Destination: especifica la dirección GeoNetworking para GeoUnicast o el área geográfica para GeoAnycast/GeoBroadcast con la que se creó el paquete GeoNetworking en origen. • Source position vector: la posición geográfica del origen del paquete GeoNetworking recibido. ETSI ETSI EN 302 636-4-1 V1.4.1 (2020-01)94 The parameters of the service primitive GN-DATA.indication are as follows: GN-DATA.indication ( Upper protocol entity, Packet transport type, Destination, (optional) Source position vector, Security report, (optional) Certificate id, (optional) ITS-AID length, (optional) ITS-AID, (optional) Security permissions length, (optional) Security permissions, (optional) Traffic class, Remaining packet lifetime, (optional), Remaining hop limit, (optional) Length, Data -- T/GN6-PDU ) The Upper protocol entity parameter determines the protocol entity that processes the service primitive (BTP or GN6). The Packet transport type parameter is the packet transport type (GUC, SHB, TSB, GBC, GAC) of the received packet. The Destination parameter is the destination address for GeoUnicast or the geographical area for GeoBroadcast/GeoAnycast with which the GeoNetworking packet was generated by the source. The Source position vector parameter is the geographical position for the source of the received GeoNetworking packet. The Security report contains result information from the security operations for decryption and verification (parameter report in the service primitive SN-DECAP.confirm). The Certificate id contains the identification of source certificate, for example the certificate hash (parameter certificate_id in the service primitive SN-DECAP.confirm). The ITS-AID length parameter specifies the length of the value provided in the ITS-AID parameter (parameter its_aid_length in the service primitive SN-DECAP.confirm). The ITS-AID parameter specifies the ITS-AID for the received payload (parameter its_aid in the service primitive SN-DECAP.confirm). The Security permissions length parameter specifies the length of the value provided in the Security permissions parameter (parameter permissions_length in the service primitive SN-DECAP.confirm). The Security permissions parameter contains the sender permissions (parameter permissions in the service primitive SN-DECAP.confirm). The Traffic class parameter is the traffic class, with which the GeoNetworking packet was generated by the source. The Remaining packet lifetime parameter is the remaining lifetime of the packet. The Remaining hop limit parameter is the remaining hop limit of the packet. The Length parameter is the length of the Data parameter. The Data parameter is the payload of the received GeoNetworking packet, i.e. the T-PDU/GN6-PDU. Implementación del protocolo GeoNetworking en un software de comunicación V2X 64 • Traffic class: especifica la clase de tráfico del mensaje con la que se creó el paquete en el origen. • Remaining packet lifetime: tiempo de vida restante que le queda al paquete. • Remaining Hop limit: número de saltos restantes del paquete. • Length: especifica la longitud del parámetro Data. • Data: representa la carga del paquete GeoNetworking recibido, es decir, la SDU de BTP o GN6ASL(T-SDU/GN6-SDU). 3.11 Funcionamiento del protocolo El funcionamiento del protocolo se divide en dos funciones principales: gestión de la red y tratamiento de los paquetes. En el primer grupo se encuentra la configuración de la dirección GeoNetworking, la actualización del vector de posición local y tiempo, y el Location Service, ya vistos en los puntos 3.5, 3.7.2, y 3.7.4 respectivamente. Se incluye también la gestión de los beacons, o balizas, que como vimos en el punto 3.9.5 son mensajes que se envían periódicamente para anunciar a los nodos cercanos la ubicación y dirección GeoNetworking de la estación ITS. Estos mensajes se envían con una frecuencia definida en la constante de protocolo itsGnBeaconServiceRetransmitTimer, que indica cada cuánto tiempo se retransmite un beacon. Este temporizador, que tiene un valor por defecto de 3000ms, se resetea si antes de que caduque se envía otro paquete que incluya el vector de posición de origen, como un paquete SHB o GBC. En nuestra implementación no se han incluido los beacon, pero el envío continuo de CAM suple su función de anuncio. En el segundo grupo se distinguen procedimientos diferentes para el tratamiento de los paquetes tanto en el envío, recepción y reencaminamiento de los mismos en función del tipo de transporte: GUC, TSB, SHB, GBC o GAC. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 65 3.11.1 Tratamiento de los paquetes Cuando el router GeoAdhoc recibe una petición mediante la directiva GN-Data.request o un paquete GeoNetworking proveniente de otra estación ITS debe ejecutar varios pasos que dependen del tipo de paquete. Los casos de más interés en nuestro caso son los paquetes SHB y GBC, que son los tipos de transporte utilizados para los mensajes CAM y DENM respectivamente, por lo que serán los que analizaremos en cuestión. Algunas de los pasos a ejecutar son muy similares en ambos casos, como el procesado de las cabeceras Basic Header y Common Header. 3.11.1.1 Basic Header Cuando el router GeoAdhoc recibe una petición para enviar un paquete, el primer paso a ejecutar es rellenar la cabecera Basic Header (3.8.1) con los valores indicados en la Tabla 12. A la recepción de un paquete se comprueba si la versión del protocolo está soportada por nuestro router, en caso contrario se descarta. Campo Valor Versión Valor de la constante itsGnProtocolVersion NH Toma el valor 1 (unsecured) o 2 (secured) del campo Security profile de la primitiva GN-Data.request, si existe, o de la constante itsGnSecurity en caso contrario Reserved 0 LT Valor indicado en el campo Maximum packet lifetime de la primitiva GN-Data.request, si existe, o el valor de la constante itsGnDefaultPacketLifetime en caso contrario RHL 1 en el caso de los paquetes SHB o BEACON. Para el resto de paquetes el valor indicado en el campo Maximum Hop limit de la primitiva GN-Data.request, si existe, el valor de la constante itsGnDefaultHopLimit en caso contrario. Tabla 12: Valores de la cabecera Basic Header Si el paquete se va a reenviar será necesario decrementar el valor del campo RHL por uno y descontar del campo LT el tiempo que haya estado almacenado en el buffer. En nuestra implementación no se ha implementado el reenvío de los paquetes. 3.11.1.2 Common Header Cuando el router GeoAdhoc recibe una petición para enviar un paquete, el siguiente paso es rellenar la cabecera Common Header (3.8.2) con los valores indicados en la Tabla 13. Campo Valor Implementación del protocolo GeoNetworking en un software de comunicación V2X 66 NH Valor de la constante itsGnProtocolVersion Reserved 0 HT y HST Los valores correspondientes al tipo de paquete indicado en la primitiva GN-Data.request codificados según la tabla TC Traffic Class indicado en el campo Traffic class de la primitiva GN-Data.request, si existe, o el valor de la constante itsGnDefaultTrafficClass en caso contrario codificados como se indica en la Flags El bit 0 toma el valor de la constante itsGnIsMobile. El resto de bits a 0 PL El tamaño en octetos de la PDU de la capa de transporte recibida en la primitiva GN- Data.request. 0 si es un paquete BEACON. MHL 1 en el caso de los paquetes SHB o BEACON. Para el resto de paquetes el valor indicado en el campo Maximum Hop limit de la primitiva GN-Data.request, si existe, el valor de la constante itsGnDefaultHopLimit en caso contrario. Reserved 0 Tabla 13: Valores de la cabecera Common Header Cuando se recibe un paquete el GeoAdhoc router deberá comprobar si el valor del campo MHL es menor que el del campo RHL de la cabecera Basic Header, en cuyo caso se ha superado el número de saltos permitidos para dicho paquete y debe ser descartado. En caso contrario se comprueba el campo HT para ver qué tipo de paquete es y ejecutar los pasos correspondientes a dicho tipo. 3.11.1.3 Paquetes SHB Cuando la petición recibida es para enviar un paquete SHB, se rellena la cabecera SHB (3.9.3) con los datos del EGO Position Vector y, si la hubiera, información dependiente del medio como la mostrada en la Figura 38 para ITS-G5. A continuación, si el parámetro SCF del campo Traffic Class está activado, consulta en la LocT si existe algún nodo marcado como vecino. Si no existiera se almacenaría el paquete en el buffer de paquetes para ser procesado más tarde. En nuestro caso no está implementado aún ni la LocT ni el buffer de paquetes, por lo que todos los paquetes creados llevan el campo SCF deshabilitado y se envían inmediatamente mediante broadcast como indica el estándar para ese caso. A la recepción de un paquete el router GeoAdhoc procesará las cabeceras Basic Header y Common Header como se indicó en los puntos anteriores A continuación, si existe una entrada en la LocT para la dirección GeoNetworking del origen, se actualizarían los datos de ubicación y tasa de envío de paquetes en dicha entrada, marcándolo además como vecino en el flag IS_NEIGHBOUR. En caso de que no Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 67 existiera se añadiría una entrada nueva para dicho origen. Este paso en nuestra implementación no se ejecuta al no estar implementada la LocT. A continuación, se crea una primitiva GN-Data.indication con los datos mostrados en la Tabla 14 y se envía a la entidad de protocolo de nivel superior correspondiente. Parámetro Valor Upper protocol entity BTP-A, BTP-B o IPv6 como indica la Tabla 9 Packet transport type SHB Source Position Vector Los valores recibidos en el paquete Security report Valores relacionados con los mecanismos de seguridad. Son opcionales y no están implementados en nuestro software. Certificate ID ITS-AID length ITS-AID Security permissions length Security permissions Traffic class Valor de TC (Common Header) Remaining packet lifetime Valor de LT (Basic Header) Remaining hop limit Valor de RHL (Basic Header) Length Longitud de la PDU recibida (payload) Data PDU recibida (payload) Tabla 14: Parámetros de la primitiva GN-Data.indication a enviar a la capa de transporte (SHB) 3.11.1.4 Paquetes GBC Si la petición recibida es para enviar un paquete GBC, se rellena la cabecera GBC (3.9.4) con los datos de la Tabla 15. Parámetro Valor SN Valor actual del sequence number según lo visto en 3.7.3 Reserved 0 Source Position Vector Los valores del Ego PV GeoAreaPos Latitude El parámetro GeoAreaPos latitude recibido en la primitiva GN-Data.request GeoAreaPos Longitude El parámetro GeoAreaPos longitude recibido en la primitiva GN-Data.request Distance a El parámetro distance a recibido en la primitiva GN-Data.request Distance b El parámetro distance b recibido en la primitiva GN-Data.request Angle El parámetro angle recibido en la primitiva GN-Data.request Reserved 0 Tabla 15: Campos de la cabecera extendida GBC A continuación, si el parámetro SCF del campo Traffic Class está activado, consulta en la LocT si existe algún nodo marcado como vecino. Si no existiera se almacenaría el paquete en el buffer de paquetes para ser procesado más tarde y no se ejecutarían más pasos. El siguiente paso sería ejecutar el procedimiento de selección de encaminamiento de GeoNetworking, descrito en el Anexo D del estándar ETSI EN 302 636-4-1 [51]. Implementación del protocolo GeoNetworking en un software de comunicación V2X 68 Para ello utiliza la función F(x,y), especificada en el estándar ETSI EN 302 931 [56] para cada una de las formas geométricas soportadas (circular, rectangular y elíptica), la cual devuelve uno de los valores indicados en la Figura 52, para determinar si se encuentra dentro del área geográfica de destino o no. Figura 52: Determinación de la posición del router GeoAdhoc respecto al área de destino Si el resultado de esta función indica que el router GeoAdhoc se encuentra dentro o en el borde del área, ejecuta uno de los denominados algoritmos area forwarding, definidos en anexo F del estándar ETSI EN 302 636-4-1 [51]. De ellos el más sencillo simplemente envía mediante broadcast el paquete. Este es el método utilizado en nuestra implementación del protocolo. La selección del algoritmo a utilizar se realiza mediante la constante de protocolo itsGnAreaForwardingAlgorithm. Si el resultado de esta función indica que el router GeoAdhoc se encuentra fuera del área, ejecuta uno de los denominados algoritmos non-area forwarding, definidos en anexo E del estándar ETSI EN 302 636-4-1 [51]. Estos son el algoritmo Greedy Forwarding (GF), que selecciona al nodo vecino más cercano geográficamente al destino como el destinatario del paquete, y el algoritmo Contention-based Forwarding (CBF), que utiliza un mecanismo en el que se envía el paquete por broadcast y todos los vecinos que lo reciben lo almacenan iniciando un temporizador con un timeout proporcional a la diferencia entre la distancia del router origen y su propia distancia al destino. La selección del algoritmo a utilizar se realiza mediante la constante de protocolo itsGnNonAreaForwardingAlgorithm. Cuando se recibe un paquete GBC, deberán ejecutarse de nuevo estos algoritmos para reenviar el paquete en caso necesario y determinar si el paquete se pasa a la entidad de protocolo superior, en el caso de que se esté dentro o en el borde del área de destino, o no. En caso de encontrarse dentro del área de destino se crea una primitiva GN-Data.indication con los datos mostrados en la Tabla 16 y se envía a la entidad de protocolo de nivel superior correspondiente. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 69 Parámetro Valor Upper protocol entity BTP-A, BTP-B o IPv6 como indica la Tabla 9 Packet transport type GBC Destination Área geográfica indicada en el paquete (GeoPos, distance a, distance b, angle) Source Position Vector Los valores recibidos en el paquete Security report Valores relacionados con los mecanismos de seguridad. Son opcionales y no están implementados en nuestro software. Certificate ID ITS-AID length ITS-AID Security permissions length Security permissions Traffic class Valor de TC (Common Header) Remaining packet lifetime Valor de LT (Basic Header) Remaining hop limit Valor de RHL (Basic Header) Length Longitud de la PDU recibida (payload) Data PDU recibida (payload) Tabla 16: Parámetros de la primitiva GN-Data.indication a enviar a la capa de transporte (GBC) Implementación del protocolo GeoNetworking en un software de comunicación V2X 76 Para desactivar el envío de paquetes seguros debemos especificárselo a Vanetza cuando ejecutamos socktap añadiendo la opción --security none al comando: sudo socktap -i ocb0 -p static --security none --print-rx-cam 4.3.1 Actualización de versión de protocolos ITS en OpenC2X Una vez hecho esto, ejecutamos de nuevo socktap y el mensaje de error que obtuvimos fue otro: Enable application ‘ca’… received packet from 44:6d:57:11:3c:ad (99 bytes) Router dropped packet because of ITS_Protocol_Version (4) received packet from 44:6d:57:11:3c:ad (99 bytes) Router dropped packet because of ITS_Protocol_Version (4) received packet from 44:6d:57:11:3c:ad (99 bytes) Router dropped packet because of ITS_Protocol_Version (4) received packet from 44:6d:57:11:3c:ad (99 bytes) Lo primero que se comprobó es la versión del protocolo CAM ya que, dado que OpenC2X tiene varios años, es probable que hubiera cambiado. Tanto OpenC2X como Vanezta forman los mensajes a partir de los ASN.1 incluidos en el estándar ETSI EN 302 637-2. En el directorio OpenC2X/common/ASN.1 se encuentran los ASN.1 que utiliza OpenC2X. El ASN.1 utilizado es el correspondiente a la v1.3.2 del estándar, que especifica que el valor que debe tomar Protocol_Version es 1 [58]. La versión actual del estándar es la v1.4.1, que especifica el valor 2 [59]. Para hacer efectivo el cambio se modificó el fichero OpenC2X/common/ASN.1/its_facilities_pdu_all.asn que contiene los ASN.1 de los mensajes CAM y DENM, así como el Common Data Dictionary del que dependen ambos protocolos, como se muestra en la Figura 59. Figura 59: Modificación del fichero its_facilities_pdu_all.asn para actualizar versión de protocolo CAM y DEMN Capitulo 4: Instalación de Vanetza y comunicación con OpenC2X 77 Tras realizar los cambios y recompilar OpenC2X se comprobó que, aunque Wireshark ya detectaba los paquetes de OpenC2X como CAM en vez de CAMv1, Vanetza seguía dando el mismo error. Por ello se revisó el código de Vanezta para averiguar en que condición se daba dicho error. Dicho mensaje se genera en las líneas 405 y 406 del fichero vanetza/geonet/router.cpp (Figura 60), cuando se comprueba si la versión del protocolo GeoNetworking del paquete recibido es igual a la configurada en Vanetza: Figura 60: Comprobación de la versión del protocolo GeoNetworking en vanetza/geonet/router.cpp OpenC2X, al no tener implementado GeoNetworking, rellena las cabeceras de los paquetes con valores fijos en el método fillGeoNetBTPheaderForCam de la clase SendToHardwareViaMAC (fichero OpenC2X/dcc/src/SendToHardwareViaMAC.cpp). Se modificó el código para que el valor del campo Version de la cabecera Basic Header se correspondiera con el valor indicado en la versión actual del protocolo, que es 1 [51]. Este cambio fue únicamente necesario para la realización de las pruebas de comunicación entre ambos softwares, pues una vez implementado el protocolo esta función de relleno de cabeceras desaparece. 4.3.2 Actualización de los ASN.1 de CAM y DEMN Antes de conseguir una comunicación correcta entre Vanetza y OpenC2X ha sido necesario actualizar los ASN.1 de OpenC2X, ya que tanto Vanetza como OpenC2X eran incapaz de decodificar los mensajes del otro, como muestran las Figura 61 y Figura 62. Figura 61: Mensaje de error CAM de Vanetza recibido por OpenC2X Implementación del protocolo GeoNetworking en un software de comunicación V2X 78 Figura 62: Mensaje de error CAM de OpenC2X recibido por Vanetza Analizando los paquetes intercambiados en Wireshark se observa, en la Figura 63, que Wireshark muestra una advertencia en los mensajes enviados por OpenC2X que hace sospechar que el mensaje no se está formando correctamente. Figura 63: Captura de CAM de OpenC2X (izquierda) y Vanetza (derecha) Los valores de curvatureCalculationMode y yawRate no parecen tener valores muy coherentes con los que Wireshark decodificaba cuando no habíamos cambiado la versión de protocolo ITS a pesar de no haber cambiado el código de generación del CAM, como se puede ver en la Figura 64. Figura 64: CAMv1 decodificado por Wireshark Revisando de nuevo los módulos ASN.1 de CAM, DEMN y el Common Data Dictionary se comprobó que la codificación del parámetro curvatureCalculationMode ha cambiado, como muestra la Figura 65. Capitulo 4: Instalación de Vanetza y comunicación con OpenC2X 79 Figura 65: Cambio de codificación del parámetro curvatureCalculationMode Por ello se han cambiado los ASN.1 de OpenC2X a las últimas versiones de CAM (v1.4.1), DENM (v1.3.1) y CDD (v1.3.1) disponibles en el gitlab de ETSI [60]. De esta manera nos aseguramos de que los mensajes CAM y DENM se envían conforme a los estándares actuales. Tras realizar el cambio por fin Vanetza y OpenC2X realizan el intercambio de CAMs correctamente. Figura 66: Recepción correcta de CAM enviado por OpenC2X en Vanetza Figura 67: Recepción correcta de CAM enviado por Vanetza en OpenC2X Implementación del protocolo GeoNetworking en un software de comunicación V2X 80 5 Implementación del protocolo GeoNetworking en OpenC2X Una vez conseguida la comunicación entre ambos softwares V2X, lo que nos ha permitido ir introduciendo ya alguna mejora en OpenC2X, se procedió a la implementación final del protocolo GeoNetworking en OpenC2X. Se ha intentado respetar al máximo la filosofía de OpenC2X sobre cómo se realiza el intercambio de información entre las diferentes entidades, explicado con detalle en el Trabajo Fin de Grado de Daniel [13]. 5.1 Integración del servicio GeoNetworking en la arquitectura de comunicación de OpenC2X Como indica Pilar en su Trabajo Fin de Grado, OpenC2X implementa de manera independiente cada uno de los diferentes protocolos (CAM, DENM, BTP) y servicios como el GPS y OBD-II. Todos ellos tienen su propio directorio dentro de la estructura del proyecto, con el código fuente en el subdirectorio src y los ficheros de configuración en el subdirectorio config. [9] Siguiendo este esquema se ha creado un directorio dentro del directorio principal de OpenC2X, llamado geonetworking, que contiene los subdirectorios geonetworking/src, que contiene los ficheros de cabecera y código fuente de las diferentes clases que forman el servicio GeoNetworking implementado, y geonetworking/config, que contiene el fichero de configuración del servicio y los ficheros de configuración de los logs a generar durante la ejecución del mismo. La incorporación del servicio dentro de la arquitectura de comunicación se ha diseñado añadiendo el servicio entre los existentes de BTP y el DCC, de manera que los Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 81 mensajes que antes intercambiaban directamente entre ellos pasan ahora por el nuevo servicio. Además, el servicio de GeoNetworking necesita recibir datos del GPS y de OBD2, para obtener la ubicación y la velocidad de la estación ITS. Por ello ha hecho necesario cambiar la arquitectura de comunicación de OpenC2X, como se muestra en la Figura 68. Figura 68: Nueva arquitectura de comunicación OpenC2X También se han añadido dos nuevos puertos de comunicación para acomodar el servicio GeoNetworking, como se muestra en la Figura 69. Figura 69: Número de puerto de los sockets ZMQ antes y después de incluir GeoNetworking Implementación del protocolo GeoNetworking en un software de comunicación V2X 82 Ahora el BTP envía los datos al servicio de GeoNetworking al puerto 7788, no utilizado hasta ahora, y los sigue recibiendo por el 5555, pero ahora desde GeoNetworking y no directamente desde el módulo del DCC. El servicio GeoNetworking, a su vez envía al DCC sus datos al puerto 7777, y los recibe en el puerto 6655 desde dicho servicio. No se muestran el resto de los módulos por simplificación, pues mantienen el mismo esquema de puertos ya mostrado en el Trabajo fin de Grado de Daniel [13]. La única diferencia es que el servicio GeoNetworking escucha, al igual que el servicio de CAM y DENM, en los puertos 3333 y 2222 también para recibir los datos del GPS y el OBD2 como muestra la Figura 70. Figura 70: Puertos de los servicios GPS y OBD2 5.2 Implementación de las primitivas de servicios de datos Al igual que en la implementación del protocolo BTP realizada por Daniel, se optó por implementar las primitivas de servicios de datos GN-Data.request y GN-Data.indication utilizando la herramienta Protocol Buffers de Google [61]. Esta herramienta permite definir estructuras de datos personalizadas, en ficheros con extensión .proto, que se compilan en nuestro caso a clases C++ que permiten su manipulación y serialización en cadenas string que intercambiamos entre nuestros servicios dentro de OpenC2X mediante el uso de sockets ZMQ. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 83 Las primitivas GN-Data.request y GN-Data.indication se han implementado en los ficheros common/buffers/GnRequest.proto y common/buffers/GnRequest.proto, cuyo código se puede observar en la Figura 71. Figura 71: Ficheros common/buffers/GnRequest.proto y common/buffers/GnIndication.proto Aunque no está implementada la capa transversal de seguridad de la pila se optado por incluir, como opcionales, los parámetros de las primitivas relacionadas con ella: itsAid, itsAidLength, secPermissions, SecPermissionsLength, secContextInfo, SecTargetIdList secTargetIdListLength, secReport y certificateID. De esta manera las primitivas quedan preparadas para una posible futura implementación de la capa transversal de seguridad. Los campos geoAddress y geoArea describen la dirección GeoNetworking para el caso de los paquetes GUC o el área geográfica de destino en los paquetes GBC/GAC y el estándar los agrupa en un único parámetro llamado Destination de las primitivas, por lo que se ha usado el tipo de campo oneof de protobuffers que permite agrupar varios campos diferentes (tanto tipo como nombre) de los cuales como mucho se puede utilizar uno en cada mensaje. Para el campo geoArea se ha definido una estructura de datos, denominada mensaje en el lenguaje protocol buffers, en el fichero common/buffers/area.proto. Esta estructura Implementación del protocolo GeoNetworking en un software de comunicación V2X 84 agrupa todos los datos necesarios para definir el área de destino: forma geométrica, posición y dimensiones de esta. De esta manera se importa en los mensajes que generan las primitivas como un nuevo tipo de datos de manera similar a crear una struct o clase en C++ en un fichero de cabecera e incluirlo en un programa. El fichero common/buffers/area.proto puede consultarse en la Figura 72. Figura 72: Fichero common/buffers/area.proto Los parámetros Packet transport type y Traffic class se corresponden con los parámetros GN Packet Transport type y GN Traffic class de las primitivas del protocolo BTP, y son pasadas de forma transparente de la entidad de la capa facilities hasta GeoNetworking, por lo que se ha decidido definirlas junto a Upper Protocol Entity como enums el fichero common/buffers/enums.proto, Figura 73, e importar dicho fichero tanto en las primitivas de GeoNetworking como en las de BTP. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 85 Figura 73: Fichero common/buffers/enums.proto También se han definido un mensaje para el Source position vector de la primitiva GN-Data.indication, en el fichero common/buffers/PositionVector.proto, mostrado en la Figura 74. Figura 74: Fichero common/buffers/PositionVector.proto La SDU proveniente de BTP se sigue enviando dentro de la clase DATA ya definida en OpenC2X como se venía haciendo hasta ahora, aunque, como se verá más adelante, no se incluirán todos los parámetros de control destinados al DCC que se incluían hasta ahora, pues ya son parámetros que se pasan en otros campos de la primitiva GN-Data.request. La primitiva GN-Data.indication no usa la clase DATA y envía a BTP únicamente la SDU dentro del campo pduForTransportProtocol. No se ha implementado la primitiva GN-Data.confirm, por lo que no se devuelve ninguna confirmación de si la petición se ha procesado correctamente o no. Implementación del protocolo GeoNetworking en un software de comunicación V2X 92 Por otro lado, se han creado dos clases que representan tanto Long Position Vectors como Short Position Vectors. Su código se encuentra en el fichero de cabecera geonetworking/src/PositionVectors.h, con la declaración de los atributos y métodos de la clase, y el fichero geonetworking/src/PositionVectors.cpp, que contiene un único método llamado PAIspeed(), Figura 84, que devuelve un número de 16 bits con la codificación necesaria de los campos PAI y Speed de manera similar a como lo hacía paramsAsInt() en la clase GeoNetAddr. Figura 84: Método PAIspeed() El resto de métodos son getter y setter de los diferentes atributos de la clase, que se declaran y definen inline en el fichero de cabecera. Esta clase se usa también para almacenar el vector de posición local, o Ego Position Vector. Para la actualización del EGO Position Vector se utiliza el método updatePosition(), Figura 86, que obtiene los valores de latitud, longitud y heading (track) del GPS y la velocidad del OBD2. Para la generación del timestamp se ha creado una función en el fichero common/utility/Utils.cpp, Figura 85, la cual utiliza la librería Posix Time del paquete de librerías boost para crear dos objetos tipo Ptime que definen el instante de tiempo actual y el 1 de enero de 2004 fijado por el estándar como referencia inicial y el tiempo pasado entre ellos. Estas funciones trabajan con tiempo UTC y no TAI como indica el estándar, por lo que se añaden los 37 segundos que hay actualmente de diferencia entre ambos para obtener el timestamp en TAI. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 93 Figura 85: Función timestamp() El parámetro PAI es un indicador de la exactitud del posicionamiento y se obtiene de los parámetros de error del GPS, epx y epy: si el mayor de esos errores es menor que la constante de protocolo itsGnPaiInterval/2 PAI toma el valor true, caso contrario (o si el GPS no proporciona esos valores, como los nuestros), PAI toma el valor false (Figura 87). Figura 86: Método updatePosition Implementación del protocolo GeoNetworking en un software de comunicación V2X 94 Figura 87: Parámetro PAI 5.6 Envío de paquetes usando GeoNetworking La integración del protocolo GeoNetworking en la arquitectura OpenC2X ha implicado modificaciones de mayor o menor importancia en los módulos correspondientes a todas las capas de la arquitectura, tanto los módulos que implementan los servicios CAM y DENM, como el BTP y el DCC. Los mensajes CAM y DENM, que son los que permite enviar OpenC2X, utilizan los servicios de transporte SHB y GBC respectivamente. Por ese motivo, sólo se ha implementado el envío de esos dos tipos de paquetes en nuestro servicio GeoNetworking. El envío de paquetes GeoNetworking se implementa en la función receiveFromBtpSendToDcc() de la clase GeoNetService (Figura 88). Esta función recibe del módulo BTP, a través del socket ZMQ mReceiverFromBTP, una primitiva GN- Data.request que deserializa en un objeto protobuf, request, de tipo GN_REQUEST (líneas 118 a 123). Las cabeceras Basic Header y Common Header son comunes a cada tipo de paquete, y se han creado dos funciones para rellenar dichas cabeceras, fillBasicHeader( ) y fillCommonHeader ( ). Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 95 Figura 88: Función receiveFromBtpSendToDcc() - Recepción de primitiva GN-Data.request 5.6.1 Función fillBasicHeader ( ) La función fillBasicHeader( const GeoNetworking::GN_REQUEST& incomingRequest ) recibe como parámetro por referencia el objeto request (Figura 88, línea 129) que representa la primitiva GN-Data.requets deserializada como vimos en el anterior apartado. A continuación, completa los parámetros de la Basic Header con los parámetros indicados por el estándar. En el caso de los campos Next Header y Version, al ocupar 4 bits cada uno, almacena el valor de versión recibido, lo desplaza cuatro bits y añade el valor de Next Header. Actualmente Next Header siempre valdrá 1, indicando que el siguiente campo es la cabecera Common Header, al no estar implementada la entidad vertical de seguridad de la pila C-ITS. Implementación del protocolo GeoNetworking en un software de comunicación V2X 96 Figura 89: Función fillBasicHeader( ) 5.6.2 Función fillCommonHeader ( ) De manera similar a la función vista en el apartado anterior, la función fillCommonHeader( const GeoNetworking::GN_REQUEST& incomingRequest, uint16_t payload ) recibe como parámetro la primitiva GN-Data.requets deserializada y un entero con la longitud del payload de la petición, necesario para rellenar el correspondiente campo de la cabecera. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 97 Con los datos de la petición, y siguiendo lo marcado por el estándar, completa los campos de la cabecera Common Header. Los campos SCF y Channel Offload de momento no se usan y se ha dejado su valor a false, pero con una implementación más completa del protocolo podrían ser necesarios. La línea 359, Figura 90, agrupa estos dos campos, junto con el Traffic Class ID de longitud 6 bits, en el campo Traffic Class de 8 bits que se incluye finalmente en la cabecera. Figura 90: Función fillCommonHeader( ) 1/2 Los campos HT y HST se rellenan según los valores ya indicados en la Tabla 10. En el caso de los tipos de transporte GBC/GAC el campo HST vendrá indicado en el campo shape del objeto geoarea de la petición. La Figura 91 muestra cómo se rellenan estos campos. Implementación del protocolo GeoNetworking en un software de comunicación V2X 98 Figura 91: Función fillCommonHeader( ) 2/2 5.6.3 Envío de mensajes CAM Los mensajes CAM son generados por el correspondiente servicio de OpenC2X, implementado en el fichero cam/src/caservice.cpp. Este servicio envía el mensaje generado al BTP utilizando una primitiva BTP-Data.request la cual incluye un campo data que no sólo contiene el mensaje generado, como correspondería al estándar, sino que incluye campos de control para el DCC, debido Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 99 a la implementación parcial del DCC que realiza OpenC2X detallada en el Trabajo Fin de Grado de Daniel [13]. Los campos id y type indicaban al DCC que el mensaje era de tipo CAM, para que pudiera rellenar las cabeceras falsas de GeoNetworking. Con la implementación de GeoNetworking, el DCC no necesita saber esa información, únicamente a cuál de las colas debe asignar ese paquete, por lo que esa información ya no se envía como muestra la Figura 92 (líneas 342 y 343). Figura 92: Modificaciones realizadas en el fichero cam/src/caservice.cpp También se han añadido, como se puede comprobar de nuevo en la Figura 92, todos los campos relacionados con GeoNetworking de la primitiva que no se estaban completando hasta ahora. Entre ellos está el tipo de transporte, SHB, y el Traffic Class, AC_BE, que antes se incluía en el campo data (línea 344) y ya no es necesario. Una vez completada la primitiva, se serializa y envía como hasta ahora al servicio BTP. El BTP recibe la primitiva y rellena la cabecera BTP y la añade al mensaje CAM como antes pero en vez de encapsular esta PDU creada en un objeto data y enviarla al DCC, ahora crea un objeto de tipo GN_Request con los campos de la primitiva GN-Data.request correspondiente y lo envía al servicio GeoNetworking, como muestra la Figura 93. Implementación del protocolo GeoNetworking en un software de comunicación V2X 100 Figura 93: Creación de la primitiva GN-Data.request en el servicio BTP La clase GeoNetService, una vez creadas las cabeceras Basic Header y Common Header como hemos visto en las secciones anteriores, comprueba el tipo de servicio de transporte solicitado y, tras comprobar que es SHB, completa el resto de la cabecera GeoNetworking con los campos de la cabecera SHB que vimos en las Figura 36 y Figura 37, como muestra la Figura 94. Una vez se han rellenado los campos de la cabecera se crea el paquete completo añadiendo los datos recibidos del BTP a la cabecera GeoNetworking (líneas 223 y 225), y se crea la petición al DCC, que consiste en el paquete creado junto al parámetro Traffic Class, se serializa y se envía al DCC Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 101 Figura 94: Creación de la cabecera SHB en la clase GeoNetService Implementación del protocolo GeoNetworking en un software de comunicación V2X 108 A continuación, comprueba el campo Next Header para verificar si es un paquete en el que se han aplicado los mecanismos de seguridad o no. Como OpenC2X no incorpora ninguno de estos mecanismos, si el paquete recibido si ha sido cifrado, por ejemplo, este se descarta y se indica un error. Figura 102: Procesado de la cabecera Basic Header del paquete recibido A continuación, se extrae la cabecera Common Header para comprobar qué tipo de paquete es, como muestra la Figura 103. Como ya se indicó cuando se explicó el proceso de envío, sólo se han implementado los paquetes SHB y GBC, que se corresponden con un valor del campo HT/HST 0x50 para los paquetes SHB y 0x40, 0x41 y 0x42 (dependiendo de la forma del área de destino) para los paquetes GBC. Si el campo HT/HST indica otro tipo de paquete, o un valor que no se corresponde con ninguno de los indicados en la Tabla 10, se genera un mensaje de error indicando que el tratamiento de ese tipo de paquete no está aún implementado, o es un valor incorrecto. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 109 Figura 103: Procesado de la cabecera Common Header para obtener el tipo de paquete 5.7.1 Procesado de paquetes SHB Si el paquete recibido es de tipo SHB, la función receiveFromDcc() llama a la función processIncomingSHB(const std::string &receivedPDU), pasando una referencia al string que contiene el paquete entero. Lo primero que hace la función es extraer la cabecera GeoNetworking completa (línea 512) y analizar los campos para crear una primitiva de tipo GN-Data.indication (líneas 514 a 556) con los parámetros indicados en la Tabla 14, usando un mensaje protobuf de tipo GN_INDICATION, mostrado en la Figura 71. Por último, incluye en dicha primitiva la PDU de la capa transporte recibida y su longitud (558 a 561), serializa el mensaje (línea 564) y lo envía al BTP (líneas 566 y 567) para su tratamiento como se explica en la sección 5.7.3. Implementación del protocolo GeoNetworking en un software de comunicación V2X 110 Figura 104: Método processIncomingSHB() Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 111 5.7.2 Procesado de paquetes GBC De manera similar al caso anterior, si el paquete recibido es de tipo GBC, la función receiveFromDcc() llama a la función processIncomingGBC(const std::string &receivedPDU), pasando una referencia al string que contiene el paquete entero. Dicha función es prácticamente idéntica a la anterior, ya que por falta de tiempo ha sido imposible implementar alguno de los mecanismos del protocolo propios de este tipo de paquetes, como el reencaminamiento (que no existe en los paquetes SHB), o la comprobación del área de destino. Al igual que en el caso anterior se completa una primitiva GN-Data.indication con los parámetros indicados en la Tabla 16. La principal diferencia, mostrada en la Figura 105 es que en este caso hay que incluir el área de destino en dicha primitiva e indicar que el tipo de transporte utilizado por el paquete es GBC. Al igual que en el caso de los paquetes SHB, tras rellenar el objeto GN_INDICATION que representa a la primitiva, este se serializa y se envía al BTP para su tratamiento como se explica en la sección 5.7.3. Figura 105: Método processIncomingGBC() Implementación del protocolo GeoNetworking en un software de comunicación V2X 112 5.7.3 Recepción de la PDU en BTP Una vez que GeoNetworking ha enviado la primitiva GN-Data.indication, esta es recibida por el BTP. Anteriormente BTP recibía únicamente la PDU, la cual debía procesar según indica el estándar del protocolo BTP [55] y entregar al servicio CAM o DENM según correspondiera. Por ello ahora es necesario extraer la PDU del objeto GN_INDICATION, mediante una pequeña modificación de la función receiveFromDccSendToServices() del fichero btp/src/btp.cpp, renombrada a receiveFromGeoNetSendToServices() por mantener una coherencia con lo que realmente hace ahora, como se indica en la Figura 106 Figura 106: Modificación de la función receiveFromDccSendToServices() 5.8 Compilación de OpenC2X Para terminar de implementar el servicio de GeoNetworking es necesario recompilar OpenC2X con los nuevos módulos creados. Para ello hay que crear un fichero con las instrucciones para CMake, geonetworking/src/CMakeLists.txt, de manera que compile los ficheros de código fuente de las nuevas clases (Figura 107). Figura 107: Fichero geonetworking/src/CMakeLists.txt Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 113 También es necesario compilar de nuevo los ficheros Protocol Buffers para que creen las clases que implementan las primitivas GN-Data.request y GN-Data.indication. Para ello existe un script en el directorio common/buffers llamado generate.sh, en el que hay que incluir los nuevos ficheros a compilar (Figura 108)- Figura 108: Fichero common/buffers/generate.sh Una vez compilado el Proyecto como indican las instrucciones del fichero readme, sólo quedaría añadir las líneas mostradas en el script que lanza OpenC2X, scripts/runOpenC2X.sh, y ejecutarlo. tmux send-keys "cd $BUILD_DIR/geonetworking/src" C-m tmux send-keys "./geonetservice $GLOBAL_CONFIG \ $OPENC2X/geonetworking/$LOCAL_CONFIG_RELATIVE \ $OPENC2X/geonetworking/$LOGGING_CONF \ $OPENC2X/geonetworking/$STATISTICS_CONF" C-m tmux split-window -v Hay que tener en cuenta que, debido a que el script utiliza tmux para ejecutar y mostrar la salida de todos los módulos de OpenC2X en la misma pantalla, al añadir GeoNetworking no puede abrir todos en la misma pantalla si se ejecuta desde una ventana del cliente gráfico de terminal no maximizada. En ese caso se puede ejecutar el módulo en otra ventana ejecutando el script scripts/runGeoNetservice.sh. 5.9 Pruebas de comunicación Para probar el funcionamiento de GeoNetworking se ejecutó OpenC2X en dos de los equipos utilizados como estaciones ITS y se capturó con Wireshark el tráfico entre ambos para verificar que ambos enviaban y recibían correctamente los paquetes de la otra estación y que estos estaban formados cumpliendo lo indicado en el estándar ETSI EN 646- 4-1 [51]. La Figura 109 muestra la ventana de OpenC2X ejecutándose con el nuevo servicio ejecutándose en la parte superior derecha. Implementación del protocolo GeoNetworking en un software de comunicación V2X 114 Figura 109: OpenC2X ejecutándose con el nuevo módulo del servicio GeoNetworking Durante la ejecución del software el servicio GeoNetworking muestra, y almacena en sus ficheros de log, mensajes de aviso indicando cuando llega un mensaje un mensaje del BTP, cuando se envía al DCC y el proceso contrario: cuando llega un mensaje del DCC, información sobre él, y cuando se envía dicho mensaje al BTP. También muestra mensajes sobre las actualizaciones del EGO Position Vector, indicando la posición y velocidad adquiridas de los módulos del GPS y OBD2. Según marca el estándar, las actualizaciones de dicho vector se producen 1000 veces cada segundo por defecto. Para nuestras pruebas, con el fin de que los logs y la salida por pantalla no se saturasen de mensaje de actualización del EGO PV y dificultasen la lectura del resto de la información, se redujo la frecuencia de actualización a 10 veces por segundo. Cuando se utilice en casos reales, si se necesita que el EGO PV se actualice más frecuentemente (y el GPS y el OBD son capaces de proporcionar los datos a dicha velocidad) es conveniente deshabilitar el envío del mensaje para evitar que los ficheros de log y la salida por pantalla se saturen de mensajes de aviso de actualización. Tanto el servicio BTP como el DCC han visto retocados ligeramente sus mensajes también, como se aprecia en la Figura 110, para que sean coherentes con lo que realmente están haciendo. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 115 Figura 110: Detalle de los mensajes de GeoNetworking, DCC y BTP La Figura 111 muestra la interfaz web de OpenC2X, con la información de los mensajes CAM y DENM enviados y recibidos por nuestra estación. En nuestro caso la estación está recibiendo mensajes CAM de dos estaciones, la 1 y 111111111, la primera ejecutando Vanetza y la segunda OpenC2X, por lo que la interoperabilidad con Vanetza sigue manteniéndose después de implementar GeoNetworking, como era de esperar. Implementación del protocolo GeoNetworking en un software de comunicación V2X 116 Figura 111: Interfaz web de OpenC2X La Figura 112 muestra una captura de Wireshark de un paquete enviado por una de nuestras estaciones, conteniendo un mensaje CAM, donde se puede ver en detalle el contenido de las diferentes cabeceras de GeoNetworking. Como se puede ver en la cabecera Basic Header se indica el lifetime codificado como indica el estándar (3.8.1), con la división en base y multiplicador. En la cabecera Common Header se observa el tipo de transporte utilizado, SHB, la codificación del Traffic Class, y el número de saltos máximo, que en este caso es 1. También se ve en detalle la dirección GeoNetworking de la estación, formada a partir de la MAC (campo MID) y el tipo de estación, como parte del Long Position Vector de origen con los datos de posicionamiento y su correspondiente timestamp. Capitulo 5: Implementación del protocolo GeoNetworking en OpenC2X 117 Figura 112: Captura de Wireshark de un paquete GeoNetworking (CAM) De manera similar, la Figura 113 muestra la captura de un paquete que contiene un DENM. Las diferencias con el anterior más reseñables son el tipo de cabecera en la Common Header, que ahora indica un tipo de cabecera GBC con área de destino circular, el Traffic Class ID, que ahora indica una clase de acceso AC_VI, y el número de saltos, que en este caso se corresponde con la constante de protocolo ItsGnDefaultHopLimit. Por último, no presentes en el paquete SHB, están el sequence number y, por supuesto, el área de destino de paquete enviado. Implementación del protocolo GeoNetworking en un software de comunicación V2X 124 [19] Comisión Europea, Commision Delegated Regulation of 13.3.2019 supplementing Directive 2010/40/EU of the European Parliament and of the Council with regard to the deployment and operational use of cooperative intelligent transport systems. [20] ETSI, EN 303 613 V1.1.1: Intelligent Transport Systems (ITS); LTE-V2X Access layer specification for Intelligent Transport Systems operating in the 5 GHz frequency band, 2020. [21] ETSI, TS 102 636-4-3 V1.1.1: Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 3: Mediadependent, 2020. [22] ETSI, TR 103 667 V1.1.1: Intelligent Transport Systems (ITS); Study on Spectrum Sharing between ITS-G5 and LTE-V2X technologies in the 5 855 MHz - 5 925 MHz band, 2021. [23] ETSI, TR 103 766 V1.1.1: Intelligent Transport Systems (ITS); Pre-standardization study on co-channel co-existence between IEEE- and 3GPP- based ITS technologies in the 5 855 MHz - 5 925 MHz frequency band, 2021. [24] C-Roads, «About: C-Roads,» [En línea]. Available: https://www.croads.eu/platform/about/about.html. [Último acceso: 25 marzo 2021]. [25] InterCor, «About InterCor,» [En línea]. Available: https://intercorproject.eu/homepage/about-intercor/. [Último acceso: 13 abril 2021]. [26] Comisión Europea, [En línea]. Available: https://ec.europa.eu/transport/infrastructure/tentec/tentec-portal/map/maps.html. [Último acceso: 13 abril 2021]. [27] C-Roads Spain, «C-Roads Spain,» [En línea]. Available: https://www.c-roads.es/croads-spain. [Último acceso: 13 abril 2021]. Bibliografía 125 [28] Car 2 Car Communication Consortium, Guidance for day 2 and beyond roadmap, 2019. [29] G. Naik, B. Choudhury y J.-M. Park, «IEEE 802.11bd & 5G NR V2X: Evolution of Radio Access Technologies for V2X Communications,» IEEE Access, vol. 7, pp. 70169-70184, 2019. [30] ETSI, EN 302 663 V1.2.1: Intelligent Transport Systems (ITS); Access layer specification for Intelligent Transport Systems operating in the 5 GHz frequency band. [31] ETSI , TS 102 724 V1.1.1: Intelligent Transport Systems (ITS); Harmonized Channel Specifications for Intelligent Transport Systems operating in the 5 GHz frequency band, 2012. [32] Comisión Europea, Commission Decision 2020/1426 of 7 October 2020 on the harmonised use of radio spectrum in the 5 875-5 935 MHz frequency band for safetyrelated applications of intelligent transport systems (ITS) and repealing Decision 2008/671/EC, 2020. [33] ETSI, ES 202 663 V1.1.0: Intelligent Transport Systems (ITS); European profile standard for the physical and medium access control layer of Intelligent Transport Systems operating in the 5 GHz frequency band, 2010. [34] ETSI, EN 302 663 V1.3.1: Intelligent Transport Systems (ITS); ITS-G5 Access layer specification for Intelligent Transport Systems operating in the 5 GHz frequency band, 2020. [35] ETSI, TS 102 636-4-2 V1.1.1: Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 2: Mediadependent functionalities for, 2013. [36] Green Car Congress, «Volkswagen receives Advanced Award from Euro NCAP for traffic hazard alert Car2X function; based on Wi-Fi p - Green Car Congress,» 2020 Implementación del protocolo GeoNetworking en un software de comunicación V2X 126 marzo 20. [En línea]. Available: https://www.greencarcongress.com/2020/03/20200320-golf.html. [Último acceso: 2021 abril 13]. [37] B. Erdem, «IEEE 802.11bd – A seamless evolutionary access layer for ITS-G5 / DSRC,» CAR 2 CAR Journal, nº 23, pp. 21-27, 2019. [38] Á. Knapp, A. Wippelhauser, D. Magyar y G. Gódor, «An Overview of Current and Future Vehicular Communication Technologies,» Periodica Polytechnica Transportation Engineering, vol. 48, nº 4, p. 341–348, 2020. [39] B. Sun, IEEE 802.11-18/1323r2: NGV SG Use Cases (Next Generation V2X Study Group), 2018. [40] B. Sadeghi, IEEE 802.11-19/0497r7: 802.11bd Specification Framework Document, 2020. [41] S.-W. Ko, H. Chae, K. Han, S. Lee, D.-W. Seo y K. Huang, «V2X-Based Vehicular Positioning: Opportunities, Challenges, and Future Directions,» IEEE Wireless Communications, 2021. [42] R. Molina-Masegosa y J. Gozalvez, «LTE-V for Sidelink 5G V2X Vehicular Communications: A New 5G Technology for Short-Range Vehicle-to-Everything Communications,» IEEE Vehicular Technology Magazine, vol. 12, nº 4, pp. 30-39, 2017. [43] D. Sempere Garcia, «Redes 5G V2X Multi-modo y Escalables,» Revista Doctorado UMH, vol. 4, nº 2, p. 2, 2018. [44] A. Bazzi, G. Cecchini, M. Menarini, B. M. Masini y A. Zanella, «Survey and Perspectives of Vehicular Wi-Fi versus Sidelink Cellular-V2X in the 5G Era,» Future Internet, vol. 11, nº 6, p. 122, 2019. Bibliografía 127 [45] R. Molina-Masegosa, J. Gozalvez y M. Sepulcre, «Configuration of the C-V2X Mode 4 Sidelink PC5 Interface for Vehicular Communication,» de 14th International Conference on Mobile Ad-Hoc and Sensor Networks (MSN), 2018. [46] M. H. García Castañeda, A. Molina-Galán, M. Boban, J. Gozalvez, B. Coll-Perales, T. Sahin y A. Kousaridas, «A Tutorial on 5G NR V2X Communications,» IEEE Communications Surveys & Tutorials, pp. 1-1, 2021. [47] A. Bazzi, A. O. Berthet, C. Campolo, B. M. Masini, A. Molinaro y A. Zanella, «On the Design of Sidelink for Cellular V2X: A Literature Review and Outlook for Future,» IEEE Access, vol. 9, pp. 97953-97980, 2021. [48] M. M. Saad, M. T. R. Khan, S. H. A. Shah y D. Kim, «Advancements in Vehicular Communication Technologies: C-V2X and NR-V2X Comparison,» IEEE Communications Magazine, vol. 59, nº 8, pp. 107-113, 2021. [49] R. Riebl, «Vanetza - Your open-source ETSI C-ITS protocol stack,» Technische Hochschule Ingolstadt, [En línea]. Available: https://www.vanetza.org. [Último acceso: 24 junio 2022]. [50] A. Voronov, «Geonetworking,» [En línea]. Available: https://github.com/alexvoronov/geonetworking. [Último acceso: 24 junio 2022]. [51] ETSI, EN 302 636-4-1 V1.4.1: Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 1: Media- Independent Functionality, 2020. [52] ETSI, EN 302 636-1 V1.2.1: Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 1: Requirements, 2014. [53] ETSI, EN 302 636-6-1 V1.2.1: Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over GeoNetworking Protocols, 2014. Implementación del protocolo GeoNetworking en un software de comunicación V2X 128 [54] ETSI, TS 103 097 V2.1.1: Intelligent Transport Systems (ITS); Security; Security header and certificate formats., 2021. [55] ETSI, EN 302 636-5-1 V2.2.1: Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 5: Transport Protocols; Sub-part 1: Basic Transport Protocol, 2019. [56] ETSI, EN 302 931 V1.1.1: Intelligent Transport Systems (ITS); Vehicular Communications; Geographical Area Definition, 2011. [57] R. Rielb. [En línea]. Available: https://github.com/riebl/vanetza. [Último acceso: 21 06 2021]. [58] ETSI, EN 302 637-2 V1.3.2: Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service, 2014. [59] ETSI, EN 302 637-2 V1.4.1: Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service, 2019. [60] ETSI, «ITS - Intelligent Transport Systems - GitLab,» [En línea]. Available: https://forge.etsi.org/rep/ITS. [Último acceso: 21 mayo 2022]. [61] Google, «Protocol Buffers | Google Developers,» [En línea]. Available: https://developers.google.com/protocol-buffers. [Último acceso: 3 junio 2022]. [62] ETSI, TS 122 185 V14.3.0: LTE; Service requirements for V2X services (3GPP TS 22.185 version 14.3.0 Release 14), 2017.