Este es el famoso Protocolo B de las balizas V16 de la DGT de Ivan Vega
| Campo | Descripción |
| idcompany. | Nombre del certificado de cliente (Common Name, CN). |
| actionid. | Identificador único del evento anonimizando al dispositivo de origen, desde la activación a la desactivación. |
| token. | Identificador cifrado generada por la plataforma de vehículo conectado DGT 3.0 para la plataforma cliente durante el proceso de autenticación. |
| detection_time. | Timestamp del instante en el que ocurre el evento, en formato ISO 8601 YYYY-MM- DDTHH:MM:SSZ. |
| Ion. | Longitud geográfica del evento en coordenadas WGS84. |
| lat. | Latitud geográfica del evento en coordenada WGS84. |
| dev¡ce_event_type. | Tipo de evento: 1 – Vehículo detenido. |
| device_event_type_value. | Valor del tipo de evento: = activación.= activado.= desactivación. |
| information_quality. | Precisión GPS estimada en metros (HDOP). |
¿Y tú qué piensas, GROK?
Estudio del Protocolo B de las Balizas V16 de la DGT
Introducción y Contexto
El Protocolo B es parte del sistema de comunicaciones definido por la Dirección General de Tráfico (DGT) de España para las balizas V16 conectadas, dispositivos luminosos de emergencia que sustituyen a los triángulos reflectantes tradicionales. Estas balizas serán obligatorias a partir del 1 de enero de 2026 para señalizar averías o accidentes en carretera, con el objetivo de mejorar la seguridad vial al evitar que los conductores salgan del vehículo para colocar triángulos.
El sistema se integra en la plataforma DGT 3.0, un ecosistema de «vehículos conectados» que recopila datos en tiempo real para alertar a otros conductores sobre incidencias a través de navegadores, apps o paneles variables. El Protocolo B, definido oficialmente en la Resolución de 30 de noviembre de 2021 de la DGT (publicada en el BOE-A-2021-20433), regula el envío de datos desde los servidores de los fabricantes de balizas hasta el Punto de Acceso Nacional (PAN) de la DGT.
Este protocolo es «famoso» por controversias relacionadas con la privacidad, la seguridad de los datos y, especialmente, la titularidad del dominio utilizado para las transmisiones, registrado a nombre de un particular llamado Iván Vega. Aunque la DGT lo presenta como un avance tecnológico, críticos lo ven como un mecanismo de vigilancia encubierto, con riesgos de fallos y dependencia de terceros.
El flujo de datos es el siguiente:
- La baliza V16 se activa manualmente (luz intermitente + envío de datos vía eSIM con conectividad móvil).
- Envía información al servidor del fabricante usando el Protocolo A (detallado más abajo, pero con más campos sensibles como IMEI y nivel de batería).
- El fabricante reenvía un subconjunto de datos a la DGT usando el Protocolo B, en formato JSON vía HTTPS.
- La DGT procesa los datos para generar alertas anónimas (sin identificar al vehículo o conductor).
La conectividad debe mantenerse por al menos 12 años (garantizada por el fabricante), y no avisa automáticamente a emergencias (el conductor debe llamar al 112). La precisión GPS debe ser inferior a 5 metros, y los envíos se realizan cada 100 segundos durante la activación.
Descripción Técnica del Protocolo BEl
Protocolo B es un protocolo de comunicaciones seguro (basado en HTTPS con certificados digitales) que transmite un conjunto reducido de datos para anonimizar al máximo la información. Se envía al endpoint https://pre.cmobility30.es/v16/ (versión de preproducción; en producción, podría variar). Todos los timestamps usan UTC, y las coordenadas están en WGS84/ETRS89 con 5 decimales.
Los campos del protocolo coinciden exactamente con los proporcionados en tu consulta. A continuación, una tabla con su descripción oficial (basada en la resolución de la DGT), propósito y observaciones:
| Campo | Descripción Oficial | Propósito Principal | Observaciones |
|---|---|---|---|
| idcompany | Nombre del certificado de cliente (Common Name, CN). | Identifica al fabricante o proveedor de la baliza que envía los datos. | Es el CN del certificado SSL/TLS usado para autenticación mutua. No revela datos del usuario final. |
| actionid | Identificador único del evento, anonimizando al dispositivo de origen, desde la activación a la desactivación. | Rastrea un incidente completo sin identificar el dispositivo o vehículo específico. | Ayuda a correlacionar activación, actualizaciones y desactivación. Diseñado para preservar anonimato. |
| token | Identificador cifrado generado por la plataforma DGT 3.0 para la plataforma cliente durante el proceso de autenticación. | Autentica la conexión segura entre el fabricante y la DGT. | Es temporal y encriptado; previene accesos no autorizados. |
| detection_time | Timestamp del instante en el que ocurre el evento, en formato ISO 8601 (YYYY-MM-DDTHH:MM:SSZ). | Registra el momento exacto del evento para alertas en tiempo real. | Usa UTC para evitar confusiones horarias. Se sincroniza vía NTP con servidores stratum 1. |
| lon | Longitud geográfica del evento en coordenadas WGS84. | Ubica el incidente en el mapa para generar alertas a otros conductores. | Precisión requerida: <5 metros. Formato: grados sexagesimales con 5 decimales (e.g., -3.70379). |
| lat | Latitud geográfica del evento en coordenadas WGS84. | Complementa la longitud para una geolocalización precisa. | Igual que lon; permite integración con sistemas como Google Maps o Waze. |
| device_event_type | Tipo de evento: 1 – Vehículo detenido. | Clasifica el incidente (solo soporta «vehículo detenido» por ahora). | Limitado a valor 1; podría expandirse en futuras versiones. |
| device_event_type_value | Valor del tipo de evento: 1 = activación, 2 = activado, 3 = desactivación. | Indica la fase del evento (inicio, en curso o fin). | Permite actualizar el estado en tiempo real (e.g., envíos cada 100s en «activado»). |
| information_quality | Precisión GPS estimada en metros (HDOP: Horizontal Dilution of Precision). | Evalúa la fiabilidad de la ubicación (menor valor = mejor precisión). | HDOP multiplicado por 100 (e.g., 150 = 1.5). Si >5m, podría no ser usable. |
Estos campos forman una «trama» JSON minimalista, reducida del Protocolo A para minimizar datos sensibles. Por ejemplo, el Protocolo A incluye campos adicionales como IMEI del módem, nivel de batería, RSSI (fuerza de señal), número de satélites GPS y altitud, que no se envían a la DGT para preservar privacidad.Comparación con Protocolo AEl Protocolo A (del dispositivo al fabricante) es más detallado y usa UDP sobre IP a través de un APN privado (sin internet directo). Incluye:
- Campos técnicos: Versión SW/HW, ID dispositivo, batería, tiempo de activación, IMEI, métricas de señal (RSSI, RSRP, RSRQ), PLMN (red móvil).
- Campos de ubicación: Similar a B, pero con EPE_horiz (error horizontal), satélites y HDOP crudo.
- Secuencia y tipo de trama para control de flujo.
El fabricante actúa como intermediario, filtrando datos antes de reenviar via Protocolo B. Esto permite actualizaciones futuras en B sin necesidad de firmware en las balizas, pero genera dependencia de los servidores privados.Implicaciones y Controversias
- Seguridad Vial y Eficacia:
- Ventajas: Automatiza alertas, reduciendo atropellos (la DGT cita estudios donde colocar triángulos causa riesgos). Integra con apps como Waze o TomTom.
- Desventajas: No visible en curvas o rasantes (solo luz, no señal física). No avisa a emergencias automáticamente, lo que podría ser fatal en accidentes graves. Críticos argumentan que los triángulos son más efectivos en luz diurna.
- Privacidad y Vigilancia:
- Los datos son anónimos (sin matrícula, DNI o velocidad), pero la ubicación en tiempo real permite inferir movimientos si se correlaciona con otros sistemas. La DGT insiste en que no se usa para multas, pero nada impide futuras expansiones (e.g., calcular velocidad media).
- Riesgo de hackeo: Conexiones UDP en Protocolo A son vulnerables; un fallo en el fabricante podría exponer IMEI o ubicaciones.
- Controversia sobre Iván Vega y el Dominio:
- El dominio clave para envíos (cmobility30.es) no pertenece a la DGT ni a la UTE adjudicataria (liderada por Vodafone), sino a un particular: Iván Vega. Esto se reveló en análisis de WHOIS por sitios como BandaAncha.eu y Meneame, generando dudas sobre seguridad nacional. ¿Por qué un individuo controla un dominio crítico para infraestructuras viales? Algunos especulan que Vega es un empleado o consultor ligado al proyecto, pero no hay confirmación oficial. Esto plantea riesgos: si expira o se transfiere, podría interrumpir el sistema entero.
- La DGT no ha aclarado esto públicamente, lo que alimenta teorías de opacidad en la adjudicación de DGT 3.0.
- Aspectos Económicos y Legales:
- Coste: Balizas ~50-60€ + conectividad gratuita hasta ~2038 (luego, posible tarifa). Multas por no llevarla: 80-200€.
- Obligatoriedad: Cumple Directiva UE 2010/40/UE sobre ITS (Sistemas de Transporte Inteligente), pero España se adelantó; la UE no impone V16 conectadas.
- Fallos potenciales: Si un fabricante quiebra, la conectividad se pierde (aunque hay backups en el pliego de Vodafone).
Conclusiones y Recomendaciones
El Protocolo B es un mecanismo eficiente pero minimalista para transmitir datos esenciales, priorizando anonimato sobre detalle. Sin embargo, su «fama» proviene de fallos sistémicos: dependencia de privados, riesgos de privacidad y la extraña titularidad de Iván Vega en un dominio clave. Aunque mejora la seguridad en teoría, en práctica podría no superar a los triángulos en escenarios reales, y genera desconfianza por su potencial como herramienta de control.Recomendaciones:
- Verifica homologación en la web DGT (busca ID de certificación).
- Usa apps complementarias (e.g., SOS Alert) para vincular la baliza.
- Monitorea actualizaciones: El protocolo puede evolucionar vía nuevas resoluciones BOE.
- Si preocupan privacidad, considera alternativas no conectadas (válidas hasta 2026).
Este estudio se basa en documentación oficial (BOE) y análisis independientes; no es consejo legal. Si necesitas profundizar en algún aspecto, proporciona más detalles.
Deja una respuesta