ES2590907T3

ES2590907T3 - Procedimiento para comprobar transacciones de peaje y componentes para ello

Info

Publication number: ES2590907T3
Application number: ES13187687.2T
Authority: ES
Inventors: Oliver Nagy; Robert Povolny
Original assignee: Kapsch TrafficCom AG
Current assignee: Kapsch TrafficCom AG
Priority date: 2013-10-08
Filing date: 2013-10-08
Publication date: 2016-11-24
Anticipated expiration: 2033-10-08
Also published as: DK2860703T3; CA2861470A1; PL2860703T3; US10055899B2; PT2860703T; US20150100394A1; AU2014218381A1; CA2861470C; US11335130B2; RU2014139918A; AU2014218381B2; EP2860703A1; SI2860703T1; EP2860703B1; US20180336739A1

Abstract

Procedimiento para comprobar transacciones de peaje que se generan a partir de avisos de posición de un teléfono móvil (20) que está conectado con un servidor de transacciones (14) por medio de una red de telefonía móvil (18), con ayuda de una red de balizas de peaje (7) distribuidas que pueden comunicarse con unidades de a bordo (15) de vehículos (5) que pasan a través de radio de corto alcance (9) y que están conectadas con el servidor de transacciones (14), que comprende: llevar un teléfono móvil (20) y una unidad de a bordo (15) en un vehículo (5); generar un indicativo de sesión (SID), intercambiar el indicativo de sesión (SID) entre el teléfono móvil (20) y la unidad de a bordo (15) y enviar el indicativo de sesión (SID) al servidor de transacciones (14); generar avisos de posición (posi) en el teléfono móvil (20) y enviar los avisos de posición (posi) bajo el indicativo de sesión (SID) al servidor de transacción (14) para generar transacciones de peaje (TR); cuando la unidad de a bordo (15) pasa por una baliza de peaje (7), protocolizar el paso en un protocolo de baliza (45, 47) bajo el indicativo de sesión (SID); y en el servidor de transacciones (14), contracomprobar las transacciones de peaje (TR), generadas para el indicativo de sesión (SID), con el protocolo de baliza (45, 47) establecido para el indicativo de sesión (SID).

Description

imagen1

DESCRIPCIÓN

Procedimiento para comprobar transacciones de peaje y componentes para ello

La presente invención concierne a un procedimiento para comprobar transacciones de peaje, así como a una disposición asistida por vehículo y a un servidor de transacciones para ello.

5 En el futuro servicio de peaje electrónico europeo (European Electronic Toll System, EETS), las unidades de a bordo (OBU) asistidas por vehículo deben ser interoperativas tanto con sistemas de peaje de carretera “ligados a infraestructura” como también sistemas de peaje “sin infraestructura”. Los sistemas de peaje de carretera ligados a infraestructura se basan en una red de balizas de peaje geográficamente distribuidas que comunican con OBU de vehículo que pasan por medio de radio de corto alcance para localizar éstas en el respectivo lugar de la baliza y

10 calcular así peaje por las utilizaciones del lugar. Los sistemas de peaje de carretera sin infraestructura se basan en OBU “autolocalizables” asistidas por satélite que envían avisos de posición o transacciones de peaje a una central por medio de una red de telefonía móvil. Por tanto, una OBU compatible con EETS debe presentar tanto un transceptor de corto alcance, por ejemplo según el estándar DSRC (dedicated short range communications – comunicaciones de corto alcance dedicadas), CEN-DSRC, UNI-DSRC, IEEE 802.11p o WAVE (wireless access for

15 vehicular environments – acceso inalámbrico para entorno vehiculares) o ITS-G5, para la comunicación con las balizas de peaje el sistema de baliza de carreteras ligado a infraestructura como también un receptor de navegación por satélite y un módulo de telefonía móvil para la comunicación con la red de telefonía móvil del sistema de peaje de carretera sin infraestructura. Por tanto, una OBU multifunción de este tipo está configurada de manera sumamente costosa y requiere también abundantes comprobaciones y certificaciones, para que cumpla los

20 requisitos de exactitud y seguridad del respectivo sistema de peaje de carretera, a fin de impedir errores de cálculo de peaje y fraudes de peaje.

La invención apunta al objetivo de crear una OBU multifunción para sistemas de peaje de carretera interoperativos que esté estructurada de manera sencilla y requiera menores costes de comprobación y certificación que los sistemas conocidos, sin minar la seguridad de cálculo del peaje y la seguridad contra fraudes de todo el sistema. Un

25 objetivo adicional de la invención es la creación de un procedimiento de comprobación para transacciones de peaje de tales OBU multifunción, así como balizas de peaje y un servidor de transacciones adecuados para ello.

En un primer aspecto, la invención crea para ello un procedimiento para comprobar transacciones de peaje que se generan a partir de avisos de posición de un teléfono móvil conectado con el servidor de transacciones a través de una red de telefonía móvil con ayuda de una red de balizas de peaje distribuidas que pueden comunicarse con

30 unidades de a bordo de vehículos que pasan por medio de radio de corto alcance y están conectadas con el servidor de transacciones, que comprende:

llevar un teléfono móvil y una unidad de a bordo en un vehículo;

generar un indicativo de sesión, intercambiar el indicativo de sesión entre el teléfono móvil y la unidad de a bordo y enviar el indicativo de sesión al servidor de transacciones;

35 generar avisos de posición en el teléfono móvil y enviar los avisos de posición bajo el indicativo de sesión al servidor de transacciones para generar transacciones de peaje;

cuando la unidad de a bordo pasa por una baliza de peaje, protocolizar el paso en un protocolo de baliza bajo el indicativo de sesión; y

en el servidor de transacciones, contracomprobar las transacciones de peaje generadas para el indicativo de sesión 40 con el protocolo de baliza ajustado para el indicativo de sesión.

Según la invención, una OBU multifunción interoperativa se compone de un teléfono móvil apto para GNSS (global navigation satellite system – sistema de navegación por satélite global), por un lado, y, por otro lado, una OBU apta para DSRC (dedicated short range communication – comunicación de corto alcance dedicada), que intercambian datos por medio de una interfaz común. Por medio de esta interfaz, puede intercambiarse un indicativo unívoco en el 45 sistema de peaje de carretera (al menos temporalmente), o sea, el indicativo de sesión, que forma un vínculo entre las funciones de cálculo de peaje sin infraestructura de la OBU multifunción, por un lado, y las funciones de cálculo de peaje ligadas a infraestructura de la OBU multifunción, por otro lado. Con ayuda del procedimiento de comprobación de la invención los datos de posicionamiento altamente seguros y precisos de balizas de peaje de un sistema de peaje de carretera ligado a infraestructura, que encuentra en su camino una OBU multifunción que

50 trabaja en servicio GNSS o sin infraestructura pueden aprovecharse para comprobar las transacciones de peaje basadas en GNSS, de modo que puedan apreciarse y penalizarse errores de peaje e intentos de fraude a los que se expone un sistema de peaje de carretera sin infraestructura. Por tanto, la invención crea un sistema de peaje de carretera interoperativo con elevada seguridad de cálculo de peaje y frente a fraudes sobre la base de pocos componentes baratos con un coste de certificación reducido.

55 Según una primera variante preferida de la invención, al pasar por una baliza de peaje se envía un indicativo de baliza desde la baliza de peaje a la unidad de a bordo y se almacena éste en la unidad de a bordo en un primer protocolo de baliza, y el primer protocolo de baliza se envía al servidor de transacciones con el indicativo de sesión por medio del teléfono móvil para su contracomprobación. El protocolo de baliza utilizado para la contracomprobación de los avisos de posición basados en GNSS se recoge así por cada OBU multifunción en el propio camino de la misma, lo que solamente requiere sólo pocas modificaciones en la red de balizas de peaje

imagen2

5 existente.

En una segunda variante de la invención ejecutable alternativa o adicionalmente a la primera variante, al pasar por una baliza de peaje se envía el indicativo de sesión desde la unidad de a bordo a la baliza de peaje y desde allí con un indicativo de baliza al servidor de transacciones, y en el servidor de transacciones, se almacenan todos los indicativos de baliza recibidos para el indicativo de sesión en un segundo protocolo de baliza. Aquí, la red de balizas

10 de peaje recoge los pasos por baliza de una OBU multifunción bajo un determinado indicativo de sesión, lo que libera de trabajo a la parte de OBU de la OBU multifunción, de modo que puede encontrarse un rendimiento suficiente con unas OBU más baratas de menor potencia de cálculo.

En una tercera variante, en la que tanto la baliza de peaje recoge tanto un primer protocolo de baliza en un OBU multifunción como un segundo protocolo de baliza, puede preverse adicionalmente que durante la 15 contracomprobación se contracompruebe también el segundo protocolo de baliza contra el primer protocolo de baliza. Esto establece una etapa de seguridad adicional en el sistema, ya que pueden aprovecharse para la comprobación no sólo los pasos por baliza recogidos por las OBU multifunción en su camino en forma del primer protocolo de baliza o los pasos por OBU recogidos por las balizas de peaje en forma del segundo protocolo de baliza, sino también ambos protocolos de baliza, concretamente tanto para la comprobación mutua como también

20 para la comprobación de los avisos de posición basados en GNSS.

Otra forma de realización ventajosa del procedimiento de la invención comprende las siguientes características:

al pasar por la baliza de peaje: registrar una característica del vehículo con un detector de la baliza de peaje y almacenar la característica del vehículo bajo el indicativo de sesión en la baliza de peaje; y

cuando la contracomprobación en el servidor de transacciones indica una divergencia, enviar la característica de 25 vehículo almacenada por la baliza de peaje al servidor de transacción.

Por tanto, las balizas de peaje pasadas por una OBU multifunción en funcionamiento GNSS se utilizan también simultáneamente para castigar delitos (“imposición de sanción”). A diferencia de soluciones DSRC conocidas, se registra como medida de precaución una característica de vehículo en cada por baliza de una OBU multifunción; si la contracomprobación posterior en el servidor de transacciones da como resultado que ha ocurrido un error de cálculo,

30 un delito de peaje o un intento de fraude en el servicio de peaje basado en GNSS, puede utilizarse la característica de vehículo registrada en la correspondiente baliza de peaje para la imposición de sanción porque se demuestra el paso por esta baliza.

El detector es preferiblemente una cámara y la característica del vehículo una característica de aspecto exterior del vehículo, de modo que, como prueba de imposición de sanción, por ejemplo, pueda utilizarse una imagen del

35 vehículo o de su matrícula.

Para asegurar la protección de los datos personales del usuario del vehículo – como matrícula o lugar de residencia del vehículo -, pueden encriptarse preferiblemente las características o imágenes del vehículo registradas con ayuda del indicativo de sesión para impedir una utilización abusiva. Si se ha comprobado una transacción de peaje y se ha encontrado que es correcta, se puede borrar el indicativo de sesión en el servidor de transacciones y, por tanto, ya

40 no es posible un desencriptamiento de características del vehículo o imágenes almacenadas encriptadas.

La contracomprobación de transacciones de peaje en el servidor de transacciones se realiza preferiblemente por medio de un cotejo de mapas (“map matching”) entre posiciones geográficas de balizas de peaje, almacenadas en el

o los protocolos de baliza con ayuda de sus indicativos, y los avisos de posición. Las posiciones geográficas de las balizas de peaje son previamente conocidas con elevada precisión, de modo que pueden utilizarse como referencia

45 para la comprobación geográfica de los datos de posición transmitidos en los avisos de posición de una OBU multifunción en servicio GNSS.

Para la interfaz en la OBU multifunción entre el teléfono móvil y la unidad de a bordo se utiliza preferiblemente un estándar de comunicación por radio de dominio cercano usual en el comercio, como WLAN, WiFi®, Bluetooth®, RFID (identificación de radiofrecuencia) o – de manera especialmente preferida – NFC (near field communication – 50 comunicación de campo cercano). Los teléfonos móviles aptos para NFC están cada vez más extendidos. La ventaja de NFC es su alcance extremadamente reducido, lo que requiere una aproximación inmediata (“swipe” – pase) del teléfono móvil a la unidad de a bordo para establecer una conexión NFC temporal. Por medio de pases (“swiping”pase) del teléfono móvil sobre la unidad de a bordo se puede provocar así la generación del indicativo de sesión y, por tanto, el inicio de sesiones en el teléfono móvil y en la unidad de a bordo; por medio de “pases” repetidos se

55 produce la conclusión de estas sesiones y el envío del primer protocolo de baliza desde la unidad de a bordo al servidor de transacciones a través del teléfono móvil.

imagen3

El primer protocolo de baliza se encripta criptográficamente en la unidad de a bordo y se envía en esta forma al teléfono móvil. Por tanto, puede impedirse que algunas aplicaciones del teléfono móvil lean o incluso manipulen el protocolo de baliza en su trayecto de transmisión al servidor de transacciones.

Opcionalmente, en al menos una de las etapas mencionadas del envío del indicativo de sesión puede enviarse

5 también un respectivo indicativo de unidad de a bordo. Por tanto, el servidor de transacciones puede realizar adicionalmente una asociación entre el indicativo de sesión y el indicativo de unidad de a bordo, lo que facilita la imposición de sanción.

En un segundo aspecto, la invención crea una OBU multifunción en forma de una disposición asistida por vehículo para el procedimiento presentado, que comprende:

10 un teléfono móvil con un receptor de satélite para la determinación de la posición y un módulo de telefonía móvil para el aviso de posición a través de una red de telefonía móvil a un servidor de transacciones, y

una unidad de a bordo con un transceptor de corto alcance para la comunicación por radio con una baliza de peaje,

en donde el teléfono móvil y la unidad de a bordo están configurados para intercambiar un indicativo de sesión por medio de una interfaz de radio común, el cual utiliza el teléfono móvil en un aviso de posición por medio de la red de

15 telefonía móvil y la unidad de a bordo en una comunicación por radio con una baliza de peaje.

Finalmente, la invención crea en un tercer aspecto un servidor de transacciones para el procedimiento mencionado, con una primera interfaz para una red de telefonía móvil y una segunda interfaz para una red de balizas de peaje geográficamente distribuidas, en donde el servidor de transacciones está configurado para contracomprobar avisos de posición de un teléfono móvil recibidos a través de la primera interfaz con protocolos de baliza recibidos por las

20 interfaces primera y/o segunda, en los que están indicadas las balizas de peaje pasadas por el teléfono móvil.

Otras características y ventajas del procedimiento, de la OBU multifunción y del servidor de transacciones de la invención se describen ahora con más detalle con ayuda de ejemplos de realización preferidos con referencia a los dibujos que se acompañan, en los cuales muestran:

La figura 1, un sistema de peaje de carretera con componentes según la invención esquemáticamente en una vista 25 general;

La figura 2, un diagrama de bloques de una disposición asistida por vehículos (“OBU multifunción”) del sistema de peaje de carretera de la figura 1;

Las figuras 3a y 3b, el procedimiento de la invención en forma de un diagrama de secuencia; y

Las figuras 4 a 6, protocolos de datos de posición y de baliza que intervienen en el procedimiento de la figura 3.

30 La figura 1 muestra en forma comprimida un sistema de peaje de carretera 1 que consta de una parte 2 ligada a infraestructura y una parte 3 sin infraestructura. En el sistema de peaje de carretera 1, un vehículo 5 se mueve a modo de ejemplo sobre una carretera 4 y lleva consigo una unidad de a bordo multifunción (OBU multifunción o MF) 6 interoperativa, es decir que puede funcionar con ambas partes 2, 3 designada también aquí como “disposición asistida por vehículo”.

35 La parte 2 ligada a infraestructura del sistema de peaje de carretera 1 comprende un gran número de balizas de peaje (roadside entities – entidades de carretera) 7 o RSE1, RSE2, …, RSEn en general, distribuidas por la red de carreteras 4, que presentan respectivamente un transceptor 8 de corto alcance para la comunicación por radio 9 con una MF-OBU 6 que pasa por la baliza 7, un detector 10 para registrar una característica del vehículo 5 que lleva la MF-OBU 6, por ejemplo una cámara para registrar un imagen del vehículo, así como una interfaz 11, cuyos

40 componentes 8, 10, 11 se controlan todos ellos por un procesador local 12 con memoria 13. Gracias a las interfaces 11, las balizas 7 están conectadas con uno o varios servidores de transacciones centrales 14 del sistema de peaje de carretera 1.

Debido al alcance limitado de la conexión por radio 9, un vehículo 5, concretamente su MF-OBU 6, puede localizarse en el respectivo lugar conocido Pn de una baliza 7 al pasar por dicha baliza 7 o RSEn y puede generarse a partir de

45 ello una transacción de peaje TR para el servidor de transacciones 14 que registra la utilización del lugar o calcula su peaje, bien generándola directamente en la baliza de peaje 7 y enviándola a ésta por medio de la interfaz 11, o bien generándola primero en el servidor de transacciones 14 en base a los datos obtenidos de la baliza de peaje 7.

El transceptor 8 y, por tanto, la conexión por radio 9 tienen un alcance de radio de como máximo algunos m, algunas decenas de m o algunas centenas de m, como se implementa, por ejemplo, por medio de los estándares DSRC 50 (dedicated short range communication – comunicación de corto alcance dedicada), CEN-DSRC, UNI-DSRC, IEEE 802.11p o WAVE (wireless access for vehicular environments – acceso inalámbrico para entornos vehiculares) o ITS-G5, incluidos WLAN y WiFi®, Bluetooth® o también tecnologías RFID activas y pasivas (radio frequency identification – identificación por radiofrecuencia). Todos estos estándares se compendian aquí por motivos de

imagen4

simplificación con el término “DSRC” y, por consiguiente, la parte 2 del sistema de peaje de carretera 1 se designa también como parte DSRC 2.

Para cooperar con la parte DSRC 2, la MF OBU 6 comprende según la figura 2 una parte DSRC 15 (también denominada “DSRC-OBU” o, brevemente, “OBU”) con un transceptor 16 de corto alcance para establecer la

5 conexión por radio 9 y un procesador 17 con memoria 18 que controla dicho transceptor. En la parte DSRC 2 del sistema de peaje de carretera 1, cada MF-OBU 6 está identificada por un indicativo OID de la OBU 15, y cada baliza de peaje 7 o RSEn por un indicativo de baliza BIDn.

La parte 3 sin infraestructura del sistema de peaje de carretera 1 no posee – como su propio nombre indica – ninguna infraestructura dedicada en el lado de la carretera, sino que utiliza una red de telefonía móvil existente 18 10 (de la que solamente se muestran como representantes algunas estaciones base) y una red existente de satélites de navegación 19 (se muestran algunos a modo de ejemplo). La red de telefonía móvil 18 (public land mobile network, PLMN – red pública móvil terrestre) puede ser de cualquier tipo conocido en la técnica, por ejemplo una red de telefonía móvil 3G, 4G o 5G según los estándares GSM, UMTS, LTE, etc. La red de satélites 19 puede ser cualquier GNSS conocido (global navigation satellite system – sistema global de navegación por satélite), por ejemplo una red

15 GPS, GLONASS o GALILEO. La parte 3 de la red de carreteras 1 se indica también como parte GNSS 3 por motivos de simplicidad.

Para cooperar con la parte GNSS 3 del sistema de peaje de carretera 1, la MF-OBU 6 posee una parte GNSS 20 que presenta un receptor de satélite 21 para la recepción 22 de señales de posición de la red de satélites 19, un módulo de telefonía móvil 23 para la comunicación 24 en la red de telefonía móvil 18, así como un procesador 25 20 con memoria 26 que controla los componentes 21, 23. Con ayuda del receptor de satélite 21 se determinan continuamente las posiciones geográficas del vehículo 5 o de la MF-OBU 6, se generan a partir de ellas datos de posición (“position fixes” – notas de posición) p1, p2, …, en general pi, y se envían estos al servidor de transacciones 14 como avisos de posición pos1, pos2, …., en general posi, a través del módulo de telefonía móvil 23 y la red de telefonía móvil 18. El servidor de transacciones 14 puede generar así, a partir de los avisos de posición obtenidos

25 posi, transacciones de peaje TR que registran las utilizaciones del lugar del vehículo 5 o calculan su peaje. Alternativamente, a partir de los datos de posición pi, el procesador 25 genera ya transacciones de peaje “terminadas” TR en la MF-OBU 6 y las envía en forma de los avisos de posición posi al servidor de transacciones 14, es decir, los avisos de posición posi pueden contener tanto datos de posición “brutos” pi como también transacciones de peaje TR “terminadas” ya procesadas.

30 Según la figura 2, la MF-OBU 6 está constituida para los fines discutidos al principio no como un componente de hardware único, sino como una disposición compuesta de dos componentes separadas que incorporan respectivamente la parte GNSS 20, por un lado, y la parte DSRC 15, por otro lado, que pueden comunicarse temporalmente uno con otro por medio de una interfaz 27.

La interfaz 27 es, por ejemplo, una interfaz de radio de corto alcance según los estándares discutidos para la interfaz

35 DSRC 9, como WLAN, WiFi®, Bluetooth® o RFID. No obstante, la interfaz 27 es preferiblemente una interfaz de radio de dominio cercano con un alcance de radio extremadamente corto, en particular según el estándar NFC (near field communication – comunicación de campo cercano). Una interfaz NFC 27 de este tipo está diseñada exclusivamente para el dominio cercano, es decir, limitada a algunos cm o a algunas decenas de cm, de modo que los componentes 20 y 15 de la MF-OBU 6 deban colocarse en la proximidad inmediata de uno a otro para establecer una conexión

40 NFC temporal 27 durante este intervalo de tiempo de aproximación. Una “colocación próxima” de este tipo se logra, por ejemplo, por medio de un pase (“Swiping”) de la parte GNSS 20 por encima de la parte DSRC 15 durante el breve intervalo de tiempo de pase por encima.

A este fin, los componentes 20, 15 comprenden respectivamente un módulo de comunicación 28, 29 de corto alcance, por ejemplo un módulo de comunicación NFC. En este caso, es posible que uno de los módulos 28, 29 esté 45 configurado como lector o solicitante y el otro respectivo módulo esté configurado como transpondedor o respondedor, por ejemplo el módulo 28 como lector RFID y el módulo 29 como transpondedor RFID (“tag” – etiqueta), o viceversa. Todas estas variantes se compendian aquí con los términos “conexión NFC” y “módulo NFC”. Los módulos NFC 28, 29 se controlan en los componentes 20, 15 por medio de los respectivos procesadores 25 o

17.

50 La parte GNSS 20 de la MF-OBU 6 puede materializarse, por ejemplo, por medio de un teléfono móvil programado de manera correspondiente y apto para NFC, RFID o Bluetooth. Bajo el término “teléfono móvil” cae en este caso cualquier tipo de aparato de comunicación que pueda comunicarse en la red de telefonía móvil 18 y esté equipado adicionalmente con un módulo de comunicación 28 de corto alcance, por ejemplo un radioteléfono, un teléfono inteligente, un notebook o tablet-PC, un asistente digital personal (PDA), etc. Un teléfono móvil de este tipo tiene en

55 general también un dispositivo de visualización y entrada 29 para el usuario, por ejemplo una pantalla con teclado o una pantalla táctil. La parte DSRC 15 de la MF-OBU 6 puede estar formada a su vez por una OBU “convencional” para un sistema de peaje de carretera DSRC, que se equipa adicionalmente con un módulo de comunicación 29 de corto alcance.

imagen5

Las figuras 3 a 6 muestran un procedimiento para comprobar transacciones de peaje en el sistema de peaje de carretera 1 utilizando los componentes mostrados en las figuras 1 y 2. El diagrama de secuencia de la figura 3 se ha distribuido, debido a su tamaño, en las figuras 3a y 3b; la figura 3b muestra la continuación de la figura 3a.

La sección (a) de la figura 3a muestra una fase del procedimiento en la que una MF-OBU 6 coopera primero – a la

5 manera de una DSRC-OBU convencional – solamente con la parte DSRC 2 del sistema de peaje de carretera 1. A modo de ejemplo están representadas dos transacciones DSRC a1, a2 con diferentes balizas de peaje 7 o RSE1, RSE2 en el trayecto del vehículo 5. En cada transacción DSRC a1, a2, una baliza de peaje 7 solicita una respuesta de la MF-OBU 6, más exactamente su parte DSRC 15, por medio de la interfaz de radio 9, por ejemplo con el mensaje DSRC “BST” (beacon service table – tabla de servicio de baliza) 31. La MF-OBU 6 responde seguidamente

10 – en una o varias comunicaciones de radio 9 – con su indicativo OID (paso 32, representado de manera simplificada), después de lo cual la baliza de peaje 7 genera una transacción de balizas TR y (inmediatamente o con posterioridad) la envía al servidor de transacciones 14 con su indicativo de baliza BIDn (paso 33). Opcionalmente, la baliza de peaje 7 puede reenviar su indicativo de baliza BIDn y/o la transacción de peaje TR a la MF-OBU 6 (paso 34).

15 La sección (b) de la figura 3 muestra una fase del procedimiento en la que la MF-OBU 6 hace de GNSS-OBU en la parte GNSS 3 del sistema de peaje de carretera 1, pero se controla o se contracomprueba por la parte DSRC 2 del sistema de peaje de carretera 1. Para ello, el usuario inicia en la parte GNSS 20, denominada en lo que sigue también “teléfono móvil” (HDY), una primera conexión NFC temporal 35 a través de la interfaz de radio 27 con la parte DSRC 15 de la MF-OBU 6, por ejemplo por medio de un “swiping” (pase) del teléfono móvil 20 sobre la OBU

20 15 (etapa 36). El pase 36 provoca la generación de un indicativo de sesión (“Session-ID”) SID unívoco en el sistema de peaje de carretera 1, por ejemplo un número aleatorio muy grande cuya aparición de nuevo en el sistema de peaje de carretera 1 es extremadamente improbable. El indicativo de sesión SID puede generarse en el teléfono móvil 20 y enviarse a la OBU 15 a través de la interfaz NFC 27, o generarse en la OBU 15 y enviarse al teléfono móvil 20 a través de la interfaz NFC 27; en cualquier caso, el indicativo de sesión SID se intercambia (etapa 37)

25 entre el teléfono móvil 20 y la OBU 15. Opcionalmente, la OBU 15 en la etapa 37 puede enviar también su indicativo OID al teléfono móvil 20.

Con el indicativo de sesión SID se inician ahora tanto en el teléfono móvil 20 como también en la OBU 15 una respectiva sesión 38 o 39. En el paso 40, el teléfono móvil 20 envía el indicativo de sesión SID (opcionalmente también el indicativo OID de la OBU, en caso de que se haya obtenido) al servidor de transacciones 14 a través de

30 la red de telefonía móvil 18, el cual seguidamente abre también una sesión 41 con el indicativo de sesión SID.

Las fases adicionales a modo de ejemplo b1, b3 y b5 en la figura 3 muestran ahora fases de cálculo de peaje en las que la MF-OBU 6 hace de GNSS-OBU y, con ayuda de su receptor de satélite 21, transfiere al servidor de transacciones 14 los avisos de posición generados posi a través de la red de telefonía móvil 18. En este caso, los datos de posición posi se envían junto con el respectivo indicativo de sesión SID al servidor de transacciones 14, de 35 modo que éste puede asociar todos los datos de posición recibidos posi del indicativo de sesión SID y almacenados en un protocolo de datos de posición posLog(SID) 42 (véase también la figura 4). Opcionalmente, en los avisos de posición posi pueden enviarse también el indicativo OID de la OBU y luego pueden inmediatamente asociarse al protocolo de datos de posición 42 en el servidor de transacciones 14. El protocolo de datos de posición 42 puede utilizarse entonces para generar transacciones de peaje TR “basadas en GNSS” en el servidor de transacciones 14,

40 o dicho protocolo contiene ya directamente estas transacciones de peaje -cuando los avisos de posición posi sean transacciones de peaje “terminadas” TR.

En las fases adicionales b2 y b4 del procedimiento representadas a modo de ejemplo, la MF-OBU 6, mientras esté en servicio de peaje (b) GNSS, se encuentra ahora en su camino con balizas de peaje adicionales 7, aquí las balizas de peaje RSEn y RSEn+1 a modo de ejemplo, que se utilizan para comprobar las transacciones de peaje TR basadas en

45 GNSS como sigue.

Cuando se invita a reaccionar a una MF-OBU 6 (paso 31) durante el paso por una baliza de peaje 7, entonces ésta contesta en las fases b2 y b4 no solo con su indicativo OID de OBU, sino también con un indicativo de sesión actual SID (paso 43). La baliza de peaje 7 sabe ahora que “en su segundo plano” se ejecuta un cálculo de peaje GNSS a través de la parte GNSS 3 (sesiones 38, 39, 41) y reacciona ahora de manera distinta a la de las fases a1 y a2, 50 donde no había obtenido ningún indicativo de sesión SID: reenvía ahora en el paso siguiente 44 su propio indicativo de baliza BIDn a la MF-OBU 6 que pasa, la cual recoge los indicativos de baliza BIDn así recibidos de todos los pasos por baliza en un primer protocolo de baliza BIDLog1(SID) 45. Alternativa o adicionalmente, la baliza de peaje 7, en un paso 46, puede enviar el indicativo OID de OBU y/o el indicativo de sesión SID de la MF-OBU 6 que pasa, junto con su indicativo de baliza BIDn, al servidor de transacciones 14, que recoge estas informaciones en un

55 segundo protocolo de baliza BIDLog2(SID) 47.

Adicionalmente, la baliza de peaje 7 registra con el detector 10 una característica del vehículo 5, por ejemplo una imagen PICn del vehículo 5, y almacena ésta en la memoria 13 de la baliza de peaje 7 bajo el indicativo de sesión SID, opcionalmente en una forma encriptada con ayuda del indicativo de sesión SID. El detector 10 de la baliza de peaje 7 puede registrar cualquier rasgo característico de un vehículo 5, por ejemplo la forma exterior o una parte de 60 ésta, como la carrocería del vehículo, el número de ejes, el tamaño, la anchura y/o la altura, el peso del vehículo,

imagen6

sus placa de identificación, por ejemplo una imagen de la matrícula del vehículo 5, sobre la que la placa del vehículo puede leerse por medio de un procedimiento de reconocimiento de imagen óptico (optical character recognition reconocimiento de caracteres óptico, OCR), etc. En este sentido, el detector 10 puede ser, por ejemplo, un escáner de láser o de radar que detecta la forma del vehículo, una o varias células fotoeléctricas, un sensor de peso y/o una

5 cámara de fotos o una cámara cinematográfica.

Por tanto, se recogen los indicativos de baliza BIDn de todas las balizas de peaje 7 por las que pasa el vehículo 5 durante la fase de cálculo de peaje GNSS (b), en el primer protocolo de baliza BIDLog1(SID) 45 de la MF-OBU 6 y/o en el segundo protocolo de baliza BIDLog2(SID) 47 del servidor de transacciones 14; las balizas de peaje pasadas 7 producen en este caso simultáneamente anotaciones PICn de características del vehículo 5 que pasa.

10 Para terminar la fase de cálculo de peaje GNSS (b), el usuario establece ahora una segunda conexión NFC temporal 48 a través de la interfaz NFC 27, por ejemplo por medio de un “pase” renovado del teléfono móvil 20 sobre la OBU 15 (paso 49). La OBU 15 envía ahora el primer protocolo de baliza acumulado BIDLog1(SID) 45 al teléfono móvil 20 (paso 50) y concluye o cierra la sesión 39. El teléfono móvil 20 envía al servidor de transacciones 14 el primer protocolo de baliza obtenido BIDLog1(SID) 45 en el paso 51 por medio de la red de telefonía móvil 18 y termina

15 también su sesión 38. Asimismo, en el servidor de transacciones 14 puede terminarse ahora la sesión 41 que se ejecuta bajo el indicativo de sesión SID; eventualmente, el indicativo de sesión SID se guarda aún más tiempo (véase el proceso 41’), como se describe todavía posteriormente.

El primer protocolo de baliza BIDLog1(SID) 45 puede encriptarse criptográficamente en la OBU 15 antes de que se le envíe al teléfono móvil 20 en el paso 50 para impedir que el teléfono móvil 20, una aplicación instalada en él o el 20 usuario pueda leer o manipular los datos del protocolo de baliza 45. Por ejemplo, el primer protocolo de baliza 45 puede estar provisto también de una firma criptográfica y/o una suma de verificación (valor hash) que pueda comprobarse después en el servidor de transacciones 14 en materia de autenticidad y/o integridad. El encriptamiento del primer protocolo de baliza 45 puede realizarse, por ejemplo, con ayuda de un procedimiento de clave pública/privada, cuya clave privada se utiliza en la OBU 15 para encriptar y su clave pública se utiliza en el

25 servidor de transacciones 14 para desencriptar.

Tras la finalización de la fase de cálculo de peaje GNSS (b) la MF-OBU 6 y posteriormente las balizas 7 pasadas por ésta retornan de nuevo al modo de cálculo de peaje DSRC (a); véase el paso por baliza an+2 a modo de ejemplo con los pasos 31 a 34.

En una fase de validación posterior (c) del procedimiento, el servidor de transacciones 14 dispone ahora tanto de las

30 transacciones de baliza TR generadas o producidas por una MF-OBU 6 en la fase de cálculo de peaje GNSS (b) en forma del protocolo de datos de posición posLog(SID)42, o sea que éste contiene datos de posición “brutos” pi o transacciones de peaje “terminadas” TF, como también del primer protocolo de baliza BIDLog1(SID) 45, que se han recogido por la MF-OBU 6 en esta fase sobre la base de los pasos por baliza b3, b4. Por tanto, en un paso de validación o contracomprobación 52, las transacciones de peaje TR generadas para un indicativo de sesión SID, o

35 posLog(SID), pueden contracomprobarse o compararse con el primer protocolo de baliza BIDLog1(SID) 45 recibido para el mismo indicativo de sesión SID, a fin de detectar divergencias. Una divergencia de este tipo puede radicar, por ejemplo, en que el trayecto del vehículo 5 indicado por el protocolo de datos de posición posLog(SID) 42 o las transacciones de baliza TR basadas en él o contenidas en él no coincide con los lugares Pn de las balizas de peaje 7 indicadas en el primer protocolo de baliza BIDLog1(SID) 45, o viceversa. Esto indica, por ejemplo, una función

40 errónea del sistema de peaje de carretera 1 o manipulaciones fraudulentas en la MF-OBU 6.

Alternativa o adicionalmente, puede realizarse una contracomprobación adicional con los pasos de MF-OBU comunicados por las balizas de peaje 7, que se recogen con relación al respectivo indicativo de sesión SID en forma del segundo protocolo de baliza BIDLog2(SID) 47. El segundo protocolo de baliza BIDLog2(SID) 47 puede contracomprobarse en este caso contra el primer protocolo de baliza BIDLog1(SID) 45 y/o el protocolo de datos de

45 posición posLog(SID) 42 o las transacciones de peaje TR.

El paso de contracomprobación 52 puede ser, por ejemplo, un cotejo de mapas (“map matching”) entre los trayectos del vehículo 5 indicados por los diferentes protocolos 42, 45, 47 en el sistema de peaje de carretera 1 con los lugares previamente conocidos Pn de las balizas de peaje 7 o RSEn, por ejemplo con ayuda de mapas de carretera digitales que contienen trayectos posibles para el vehículo 5 y los lugares Pn de la baliza de peaje 7.

50 Se entiende que los protocolos de baliza 45, 47 pueden contener también en cada caso solamente informaciones comprimidas de las balizas de peaje 7 pasadas, por ejemplo un valor hash de los indicativos de baliza BIDn de las balizas de peaje 7 pasadas. El servidor de transacciones 14 puede entonces calcular un valor hash de comparación a partir de los indicativos de baliza BIDn por él conocidos de aquellas balizas de peaje 7 que deberían haber pasado por la OBU multifunción 6 en su camino indicado según los datos de posición posLog(SID) 42, y puede compararlo

55 después con el valor o valores hash indicados en el o los protocolos de baliza 45, 47 para detectar divergencias. Los protocolos de baliza 45, 47 comprimidos (hash) de este tipo que ya no contienen los indicativos de baliza BIDn en texto claro, sino, por ejemplo, solamente en forma de un valor hash o una suma de verificación, caen también bajo los términos de “protocolos de baliza” aquí utilizados.

imagen7

En caso de una divergencia, el servidor de transacciones 14, en un paso 53 (opcional), puede solicitar de la correspondiente baliza de peaje 7 la característica PICn del vehículo registrada allí en la memoria 13 bajo el indicativo de sesión SID, por ejemplo una imagen del vehículo 5, y recuperarla (paso 54). Cuando la característica de vehículo PICn se ha encriptado con el indicativo de sesión SID, el indicativo de sesión SID debe guardarse hasta

5 este momento en el servidor de transacciones 14, véase el proceso 41’, para utilizarlo para desencriptar la característica de vehículo PICn. Los indicativos de sesión SID para transacciones de peaje TR, que se han encontrado en orden en el paso 52, pueden borrarse (también ya en el paso 52) para impedir un desencriptamiento adicional de las características almacenadas PICn de vehículos “correctos”.

En un paso 55 se elabora un conjunto de datos de imposición de sanción REC que contiene la divergencia

10 detectada en conexión con la característica de vehículo determinada PICn así como el indicativo de sesión SID y/o el indicativo OID de OBU (cuando se ha enviado también esta última y se la ha asociado al indicativo de sesión SID). Cuando el indicativo OID de OBU no está disponible en este lugar en el servidor de transacciones 14, el conjunto de datos de imposición de sanción REC puede contener también solamente el indicativo de sesión SID.

Se entiende que una MF-OBU 6, que envía avisos de posición posi al servidor de transacciones 14 a través de la red

15 de telefonía móvil 18 en la fase de cálculo de peaje GNSS (b), puede enviar también en este caso un respectivo indicativo de abonado (TID) del teléfono móvil 20 en la red de telefonía móvil 18, por ejemplo, una IMSI (international mobile subscriber identification – identificación de abonado móvil internacional), una TIMSI (temporary international mobile subscriber identification – identificación de abonado móvil internacional temporal), un IMEI (international mobile equipment identifier – indicativo de equipo móvil internacional) o similares, con ayuda del cual pueda

20 imputarse a una cuenta de facturación en la red de telefonía móvil 18 una transacción de peaje TR basada en GNSS. Por tanto, para solamente las transacciones de peaje TR basadas en GNSS, no es forzosamente necesaria la asociación del indicativo de sesión SID y/o del indicativo OID de OBU para el indicativo de abonado TID, sino que esto es opcional.

La invención no está limitada a las formas de realización representadas, sino que comprende todas las variantes y 25 modificaciones que caen en el ámbito de las reivindicaciones adjuntas.

Claims

imagen1

REIVINDICACIONES

1. Procedimiento para comprobar transacciones de peaje que se generan a partir de avisos de posición de un teléfono móvil (20) que está conectado con un servidor de transacciones (14) por medio de una red de telefonía móvil (18), con ayuda de una red de balizas de peaje (7) distribuidas que pueden comunicarse con unidades de a

5 bordo (15) de vehículos (5) que pasan a través de radio de corto alcance (9) y que están conectadas con el servidor de transacciones (14), que comprende:

llevar un teléfono móvil (20) y una unidad de a bordo (15) en un vehículo (5);

generar un indicativo de sesión (SID), intercambiar el indicativo de sesión (SID) entre el teléfono móvil (20) y la unidad de a bordo (15) y enviar el indicativo de sesión (SID) al servidor de transacciones (14);

10 generar avisos de posición (posi) en el teléfono móvil (20) y enviar los avisos de posición (posi) bajo el indicativo de sesión (SID) al servidor de transacción (14) para generar transacciones de peaje (TR);

cuando la unidad de a bordo (15) pasa por una baliza de peaje (7), protocolizar el paso en un protocolo de baliza (45, 47) bajo el indicativo de sesión (SID); y

en el servidor de transacciones (14), contracomprobar las transacciones de peaje (TR), generadas para el indicativo 15 de sesión (SID), con el protocolo de baliza (45, 47) establecido para el indicativo de sesión (SID).
2. Procedimiento según la reivindicación 1, caracterizado por que, al pasar por una baliza de peaje (7), se envía a la unidad de a bordo (15) un indicativo de baliza (BIDn) desde la baliza de peaje (7) y se le almacena en un primer protocolo de baliza (45) en la unidad de a bordo (15); y

por que el primer protocolo de baliza (45) con el indicativo de sesión (SID) se envía por medio del teléfono móvil 20 (20), para su contracomprobación al servidor de transacciones (14).
3. Procedimiento según la reivindicación 1 o 2, caracterizado por que, al pasar por una baliza de peaje (7), el indicativo de sesión (SID) se envía desde la unidad de a bordo (15) a la baliza de peaje (7) y desde allí se le envía con un indicativo de baliza (BIDn) al servidor de transacción (14); y

por que en el servidor de transacción (14) se almacenan en un segundo protocolo de baliza (47) todos los indicativos 25 de baliza (BIDn) recibidos para el indicativo de sesión (SID).
4.

Procedimiento según las reivindicaciones 2 y 3, caracterizado por que, durante la contracomprobación, se contracomprueba también el segundo protocolo de baliza (47) contra el protocolo de baliza (45).
5.

Procedimiento según una de las reivindicaciones 1 a 4, que comprende:

al pasar por la baliza de peaje (7): registrar una característica de vehículo (PICn) con un detector (10) de la baliza de 30 peaje (7) y almacenar la característica de vehículo (PICn) bajo el indicativo de sesión (SID) en la baliza de peaje (7); y

cuando la contracomprobación en el servidor de transacciones (14) indica una divergencia, enviar la característica de vehículo almacenada (PICn) desde la baliza de peaje (7) al servidor de transacciones (14).
6. Procedimiento según la reivindicación 5, caracterizado por que la característica de vehículo (PICn) se 35 almacena encriptada con ayuda del indicativo de sesión (SID).
7. Procedimiento según una de las reivindicaciones 1 a 6, caracterizado por que la contracomprobación se realiza por medio de un cotejo de mapas entre posiciones geográficas (Pn) de balizas de peaje (7), almacenadas en el protocolo o protocolos de baliza (45, 47) con ayuda de sus indicativos de baliza (BIDn), y los avisos de posición (posi).

40 8. Procedimiento según una de las reivindicaciones 1 a 7, caracterizado por que la generación del indicativo de sesión (SID) y el envío del primer protocolo de baliza (45) se provocan por medio de una respectiva conexión de dominio cercano temporal (27), preferiblemente una conexión NFC, entre el teléfono móvil (20) y la unidad de a bordo (15).
9.

Procedimiento según una de las reivindicaciones 2 a 8, caracterizado por que el primer protocolo de baliza 45 (45) se encripta criptográficamente en la unidad de a bordo (15) y se le envía en esta forma al teléfono móvil (20).
10. Procedimiento según una de las reivindicaciones 1 a 9, caracterizado por que en al menos uno de los pasos mencionados del envío del indicativo de sesión (SID) se envía también un indicativo respectivo (OID) de la unidad de a bordo (15).
11.

Disposición asistida por un vehículo para un procedimiento según una de las reivindicaciones 1 a 10, que 50 comprende:

9

imagen2

un teléfono móvil (20) con un receptor de satélite (21) para la determinación de la posición y un módulo de telefonía móvil (23) para el aviso de posición a través de una red de telefonía móvil (18) a un servidor de transacciones (14), y

una unidad de a bordo (15) con un transceptor de corto alcance (16) para la comunicación por radio con una baliza de peaje (7),

5 en donde el teléfono móvil (20) y la unidad de a bordo (15) están configurados para intercambiar un indicativo de sesión (SID) por medio de una interfaz de radio común (27), que el teléfono móvil (20) utiliza en un aviso de posición

(24)

por medio de la red de telefonía móvil (18) y que la unidad de a bordo (15) utiliza en una comunicación por radio

(9)

con una baliza de peaje (7).
12. Disposición asistida por un vehículo según la reivindicación 11, caracterizada por que la interfaz de radio (27) 10 es una interfaz NFC para conexiones NFC temporales.
13.

Disposición asistida por un vehículo según la reivindicación 11 o 12, caracterizada por que la unidad de a bordo (15) está configurada para recibir un indicativo de baliza (BIDn) de una baliza de peaje (7) y almacenarlo en un primer protocolo de baliza (45).
14.

Disposición asistida por un vehículo según la reivindicación 13, caracterizada por que la unidad de a bordo

15 (15) está configurada para enviar el primer protocolo de baliza (45) al teléfono móvil (20) a través de la interfaz de radio común (27), y por que el teléfono móvil (20) está configurado para enviar un primer protocolo recibido (45) al servidor de transacciones (14) a través de la red de telefonía móvil (18).
15. Servidor de transacciones para un procedimiento según una de las reivindicaciones 1 a 10, con una primera interfaz para una red de telefonía móvil (18) y una segunda interfaz para una red de balizas de peaje (7)

20 geográficamente distribuidas, en donde el servidor de transacciones (14) está configurado para contracomprobar avisos de posición (posi) de un teléfono móvil (20) recibidos por la primera interfaz con protocolos de baliza (45, 47) recibidos por las interfaces primera y/o segunda, en los que están indicadas balizas de peaje (7) pasadas por el teléfono móvil (20).
16. Servidor de transacciones según la reivindicación 15, caracterizado por que el servidor de transacción (14)

25 está configurado para solicitar por medio de la segunda interfaz, en caso de que surja una divergencia en la contracomprobación, una característica de vehículo (PICn) almacenada en una baliza de peaje (7).

10