ES2745105T3 - Un procedimiento de comunicación entre dos entidades de señalización de vías ferroviarias - Google Patents

Un procedimiento de comunicación entre dos entidades de señalización de vías ferroviarias Download PDF

Info

Publication number
ES2745105T3
ES2745105T3 ES17157789T ES17157789T ES2745105T3 ES 2745105 T3 ES2745105 T3 ES 2745105T3 ES 17157789 T ES17157789 T ES 17157789T ES 17157789 T ES17157789 T ES 17157789T ES 2745105 T3 ES2745105 T3 ES 2745105T3
Authority
ES
Spain
Prior art keywords
mcdata
mcdata data
data
client
signaling
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES17157789T
Other languages
English (en)
Inventor
Christophe Gruet
Peter Beicht
Karl Kernstock
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Kapsch CarrierCom AG
Original Assignee
Kapsch CarrierCom AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kapsch CarrierCom AG filed Critical Kapsch CarrierCom AG
Application granted granted Critical
Publication of ES2745105T3 publication Critical patent/ES2745105T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/26—Special purpose or proprietary protocols or architectures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un procedimiento de comunicación según protocolo de control de transmisión, TCP, protocolo de datagramas de usuario, UDP o protocolo de transmisión de control de flujos, SCTP, entre dos entidades de señalización de vías ferroviarias (6, 18) a través de una red inalámbrica (3) que proporciona servicios de datos críticos de misión, MCData, según un estándar LTE del 3GPP que proporciona dichos servicios de datos MCData, que comprende: configurar un primer cliente de datos MCData (15, 15a) para la primera entidad de señalización (6) y registrar el primer cliente de datos MCData (15, 15a) con un servidor de datos MCData (14, 14a) de la red inalámbrica (3) para transferencias de servicios de datos cortos, SDS, de datos MCData; configurar un segundo cliente de datos MCData (21, 21a) para la segunda entidad de señalización (18) y registrar el segundo cliente de datos MCData (21, 21a) con el servidor de datos MCData (14, 14a) para transferencias SDS de datos MCData; recibir un mensaje de señalización (19) transmitido según protocolo TCP, UDP o SCTP desde la primera entidad de señalización (6) en el primer cliente de datos MCData (15, 15a); en el primer cliente de datos MCData (15, 15a), empaquetar el mensaje de señalización (19) en un mensaje SDS de datos MCData (22, 22a); enviar el mensaje SDS de datos MCData (22, 22a) desde el primer cliente de datos MCData (15, 15a) al segundo cliente de datos MCData (21, 21a) a través del servidor de datos MCData (14, 14a); extraer el mensaje de señalización (19) del mensaje SDS de datos MCData (22, 22a) en el segundo cliente de datos MCData (21, 21a); y enviar el mensaje de señalización (19) a la segunda entidad de señalización (18).

Description

DESCRIPCIÓN
Un procedimiento de comunicación entre dos entidades de señalización de vías ferroviarias
La presente invención se refiere a un procedimiento de comunicación según protocolo TCP, UDP o SCTP entre dos entidades de señalización de vías ferroviarias en una red inalámbrica según un estándar de LTE del 3GPP.
Los sistemas de señalización de vías ferroviarias tales como CBTC (Communications Based Train Control: control de ferrocarriles basado en comunicaciones) o ETCS (European Train Control System: sistema europeo de control de ferrocarriles) se utilizan para señalización, control y protección de ferrocarriles y equipos junto a la vía ferroviaria. En el pasado, esos sistemas dependían de redes inalámbricas dedicadas tales como TETRA (Terrestrial Trunked Radio: radio terrestre troncalizada), GSM-R (Global System for Mobile Telecommunications - Rail: sistema global para telecomunicaciones móviles - vía ferroviaria) o WLAN (Wireless Local Area Networks: redes inalámbricas de área local), ya que la baja latencia y la alta disponibilidad son fundamentales para la seguridad e intereses de operabilidad.
Para explotar las capacidades de transmisión de datos de alta velocidad de estándares inalámbricos de banda ancha general modernos tales como LTE (Long Term Evolution: evolución a largo plazo) del estándar 3GPP (3rd Generation Partnership Project: proyecto asociación de tercera generación), se han hecho esfuerzos recientes para estandarizar los servicios de datos críticos de misión (MCData: Mission Critical Data), véase, por ejemplo, la especificación técnica del 3GPP (TS: Technical Specification) 23.282.
Los servicios de datos MCData utilizan la arquitectura funcional común definida en la especificación TS 23.280 del 3GPP para soportar servicios de misión crítica (MC) en LTE, y son uno de los tres servicios de MC definidos en el estándar LTE: MCPTT (MC push-to-talk: pulsar para hablar en misiones críticas) para comunicaciones de voz en misiones críticas, MCVideo para funciones de pull y push de video para misiones críticas, y MCData para servicios de datos en misiones críticas. Los servicios de datos MCData comprenden un conjunto de cuatro servicios: servicios de mensajería SDS (Short Data Service: servicio de datos cortos), servicios de FD (File Distribution: distribución de archivos), servicios de DS (Data streaming: transmisión de datos) y servicios de IC (IP connectivity: conectividad IP), véase la especificación TS 23.282 del 3GPP.
La Figura 1 muestra un ejemplo de cómo se utilizan actualmente los servicios de MC en un entorno de señalización de vías ferroviarias según el estado de la técnica. Los servicios MCPTT se utilizan para implementar comunicaciones de voz en misiones críticas entre, por ejemplo, un FRMCS (Future Railway Mobile Communication System: futuro sistema de comunicaciones móviles ferroviarias) 1 y una entidad de usuario del estándar LTE (UE) a bordo de un ferrocarril 2 a través de una red de acceso de radio (RAN: Radio Access Network) habilitada para MC del estándar LTE 3.
Unos servidores de señalización de vías ferroviarias ETCS o CBTC de ejemplo 4, 5 utilizan servicios de conectividad de protocolo de Internet (IP) proporcionados a través de la red inalámbrica 3 para comunicarse con un cliente de señalización 6 a bordo del ferrocarril 2. Esos servicios IP típicamente comprenden comunicaciones TCP (Transmission Control Protocol: protocolo de control de transmisión), UDP (User Datagram Protocol: protocolo de datagramas de usuario) o SCTP (Stream Control Transmission Protocol: protocolo de transmisión de control de flujos).
Como se muestra en la Figura 1, los servidores de señalización 4, 5 y los clientes 6 son sistemas autónomos, que comparten sólo la red inalámbrica 3 con la comunicación de voz MCPTT del sistema de comunicaciones 1 y el UE en el ferrocarril 2, mientras que tiene su propios núcleos de comunicación de servicios IP 7, 8, 9 para procesar la autenticación, la autorización, la seguridad y la configuración de sus entidades de señalización (aplicaciones) 10, 11, 12. Esto también se aplica a escenarios en los que se utilizan servicios IC de datos MCData estandarizados más recientemente de la red inalámbrica 3.
Es un objeto de la invención proporcionar un procedimiento más eficiente, también muy fiable y de baja latencia para comunicaciones IP, en particular, comunicaciones según protocolo TCP, UDP o SCTP, entre dos entidades de señalización de vías ferroviarias a través de una red inalámbrica.
Según la invención, este objetivo se consigue con un procedimiento según la reivindicación 1. Se definen otras formas de realización en las reivindicaciones dependientes.
En lugar de servicios de conectividad IP genéricos de la red inalámbrica LTE del 3GPP, el procedimiento de la invención hace uso del servicio SDS de datos MCData para comunicaciones IP tunelizadas en forma de mensajes de señalización según protocolo TCP, UDP o SCTP a través de mensajes SDS de datos MCData. Debido a la prioridad intrínseca de "misión crítica" de los mensajes SDS de datos MCData en la red inalámbrica LTE, la señalización de misión crítica entre las entidades de señalización de vías ferroviarias es rápida y eficiente. Para los mensajes SDS de datos MCData, el servidor de datos MSData y los clientes de datos MCData proporcionan todas las funciones de comunicación básicas, tales como autenticación, autorización, seguridad y configuración entre las partes de comunicación que intercambian mensajes SDS, de modo que las entidades de señalización de vías ferroviarias son liberadas de todas esas funciones. Las entidades de señalización de vías ferroviarias, es decir, los servidores y clientes de señalización de vías ferroviarias, se pueden reducir por lo tanto a “pequeñas” aplicaciones, que se basan en los protocolos básicos del servidor y clientes de SDS de datos MCData. Además, los clientes y servidores de señalización de vías ferroviarias se pueden agregar y/o readaptar fácilmente al sistema, sin la necesidad de implementar mecanismos adicionales de autenticación, autorización, seguridad y configuración en el lado del servidor ferroviario o de los clientes.
Para lograr una baja latencia, los mensajes SDS de datos MCData se envían preferiblemente en el modo de envío automático de datos MCData desde el cliente de datos MCData al servidor de datos MCData, y preferiblemente también en el modo de recepción automática de datos MCData desde el servidor de datos MCData al cliente o clientes de datos MCData. El "Envío automático" es un mecanismo de los servicios de datos MCData en el que los datos con origen en un cliente remitente de datos MCData se transmiten automáticamente al servidor de datos MCData sin solicitar permiso para su transmisión, y la "Recepción automática" es un mecanismo en el que los datos son entregados automáticamente al cliente receptor de datos MCData desde el servidor de datos MCData sin requerir aceptación para su entrega. Según se define en la especificación TS 23.282 del 3GPP, los modos de envío automático y de recepción automática son posibles para transmisiones de no más de 1000 bytes. Dado que los paquetes de datos según protocolo TCP, UDP o SCTP de entidades de señalización de vías ferroviarias suelen ser mucho más pequeños, este límite no afecta a la operación de baja latencia.
En una forma de realización preferida, el mensaje SDS de datos MCData es enviado en un modo de llamada privada desde un primer cliente de datos MCData a un segundo cliente de datos MCData. Alternativamente, el mensaje SDS de datos MCData también se podría enviar en un modo de llamada en grupo a una pluralidad de segundos clientes de datos MCData, si es necesario.
Con el procedimiento según la invención, se pueden implementar fácilmente estrategias de redundancia para sistemas de señalización de vías ferroviarias altamente a prueba de fallos. Con este fin, una primera forma de realización preferida del procedimiento de la invención comprende además:
configurar un primer cliente de datos MCData adicional para la primera entidad de señalización y registrar el primer cliente de datos MCData adicional con el servidor de datos MCData para transferencias SDS de datos MCData;
configurar un segundo cliente de datos MCData adicional para la segunda entidad de señalización y registrar el segundo cliente de datos MCData adicional con el servidor de datos MCData para transferencias s Ds de datos MCData;
recibir el mensaje de señalización procedente de la primera entidad de señalización también en el primer cliente de datos MCData adicional;
en el primer cliente de datos MCData adicional, empaquetar el mensaje de señalización en un mensaje SDS de datos MCData adicional;
enviar el mensaje SDS de datos MCData adicional desde el primer cliente de datos MCData adicional al segundo cliente de datos MCData adicional a través del servidor de datos MCData;
si para alguno de los dos mensajes SDS de datos MCData ha fallado su recepción en el respectivo segundo cliente de datos MCData, extraer el mensaje de señalización del mensaje SDS de datos MCData que no ha fallado (que ha sido recibido) para su envío a la segunda entidad de señalización.
La duplicación de la ruta de transmisión de mensajes para los mensajes SDS de datos MCData consigue una redundancia para compensar posibles fallos de transmisión a través de la red inalámbrica.
Mientras que esta primera forma de realización utiliza un servidor de datos MCData común, alternativamente también se pueden duplicar los servidores de datos MCData. Es decir, en una segunda forma de realización preferida, el procedimiento de la invención comprende:
configurar un primer cliente de datos MCData adicional para la primera entidad de señalización y registrar el primer cliente de datos MCData adicional con un servidor de datos MCData adicional para transferencias SDS de datos MCData;
configurar un segundo cliente de datos MCData adicional para la segunda entidad de señalización y registrar el segundo cliente de datos MCData adicional con el servidor de datos MCData adicional para transferencias SDS de datos MCData;
recibir el mensaje de señalización procedente de la primera entidad de señalización también en el primer cliente de datos MCData adicional;
en el primer cliente de datos MCData adicional, empaquetar el mensaje de señalización en un mensaje SDS de datos MCData adicional;
enviar el mensaje SDS de datos MCData adicional desde el primer cliente de datos MCData adicional al segundo cliente de datos MCData adicional a través del servidor de datos MCData adicional;
si para alguno de los dos mensajes SDS de datos MCData ha fallado su recepción en el respectivo segundo cliente de datos MCData, extraer el mensaje de señalización del mensaje SDS de datos MCData que no ha fallado (que ha sido recibido) para su envío a la segunda entidad de señalización.
En tanto la primera como la segunda forma de realización, el mensaje de señalización según protocolo TCP, UDP o SCTP para transmitir puede ser duplicado en la entidad de señalización remitente para su suministro a los dos primeros clientes de datos MCData. Para este fin, en el caso de un mensaje de señalización TCP, se puede duplicar el mensaje enviándolo como un mensaje TCP de múltiples rutas (MPTCP), en el caso de un mensaje UDP como un mensaje UDP de múltiples rutas (MPUDP), o en el caso de un mensaje SCDP como un mensaje SCTP de múltiples rutas (MPSCTP).
En una forma de realización alternativa adicional, la redundancia se puede implementar por medio de llamadas en grupo procesadas en el sistema de SDS de datos MCData. Para este fin, una tercera forma de realización preferida del procedimiento de la invención comprende:
configurar un primer cliente de datos MCData adicional para la primera entidad de señalización y registrar el primer cliente de datos MCData adicional con el servidor de datos MCData para transferencias SDS de datos MCData;
configurar un segundo cliente de datos MCData adicional para la segunda entidad de señalización y registrar el segundo cliente de datos MCData adicional con el servidor de datos MCData para transferencias s Ds de datos MCData;
definir un grupo que contenga los dos segundos clientes de datos MCData como miembros;
en el que el mensaje SDS de datos MCData es enviado en un modo de llamada en grupo a todos los miembros del grupo.
La redundancia se puede mejorar aún más cuando el grupo comprende adicionalmente los dos primeros clientes de datos MCData como miembros, de modo que, al recibir el mensaje SDS de datos MCData en el primer cliente de datos MCData adicional, el mensaje SDS de datos MCData es reenviado en un modo de llamada en grupo a todos los miembros del grupo.
En cualquiera de esos casos, cuando se reciben mensajes de señalización duplicados, se puede procesar la eliminación de duplicados a nivel de las entidades de señalización de vías ferroviarias que reciben dichos mensajes duplicados. Alternativamente, y preferiblemente, se pueden evitar duplicados innecesarios de mensajes SDS de datos MCData restringiendo ciertas rutas de mensajería en grupo entre los miembros del grupo en una llamada en grupo, de modo que principalmente se conservan las rutas de reenvío desde los dos clientes SDS de datos MCData remitentes a los dos clientes SDS de datos MCData receptores, según se explicará más adelante en detalle.
Las entidades de señalización en el procedimiento de la invención pueden ser de cualquier tipo, por ejemplo, dos controladores de ferrocarril a bordo que intercambian comunicaciones entre ferrocarriles, dos equipos junto a la vía ferroviaria, un equipo junto a la vía ferroviaria y un servidor de señalización central, etc. En formas de realización preferidas, la primera entidad de señalización es un controlador de ferrocarril a bordo y la segunda entidad de señalización es un servidor de señalización junto a la vía ferroviaria, o vice versa. En esos casos, solo la entidad de señalización móvil necesita comunicarse a través de la red inalámbrica con el servidor de datos MCData, mientras que la entidad de señalización estacionaria se puede comunicar directamente a través de un enlace de datos conectado por cable con el servidor de datos MCData.
Ahora se describirán con más detalle unas formas de realización de ejemplo en referencia a los dibujos adjuntos, en los que:
La Figura 1 es un diagrama general de un sistema y procedimiento de señalización de vías ferroviarias según el estado de la técnica;
La Figura 2 es un diagrama general de un sistema y procedimiento de señalización de vías ferroviarias según la invención;
La Figura 3 es un diagrama funcional del modelo de plano de aplicación del servicio SDS de datos MCData en LTE del 3GPP;
La Figura 4 es un diagrama de bloques de una primera forma de realización de un sistema y procedimiento de comunicación de señalización de vías ferroviarias según la invención.
La Figura 5 es un diagrama de datos que muestra la etapa de empaquetar un mensaje de señalización TCP en un mensaje SDS de datos MCData; y
Las Figuras 6, 7 y 8 son diagramas de bloques de formas de realización adicionales del sistema y procedimiento de señalización de vías ferroviarias de la invención.
En cuanto a la Figura 1, que describe el estado de la técnica, se ha hecho referencia a la misma en la introducción. La Figura 2, en la que los mismos números de referencia designan las mismas entidades que en la Figura 1, muestra el uso de un túnel SDS de datos MCData 13 para la señalización entre los servidores de señalización de vías ferroviarias 4, 5 y el ferrocarril de ejemplo 2 con su entidad de usuario UE a través de la red inalámbrica 3. Un servidor de datos MCData 14 para procesar servicios de datos MCData está conectado a la red inalámbrica 3. La red inalámbrica 3 es una red LTE del 3GPP que proporciona servicios SDS de datos MCData de acuerdo con la especificación TS 23.282 del 3GPP, cuyo modelo funcional de plano de aplicación básico está representado en la Figura 3 para el servidor de datos MCData 14 y un cliente de datos MCData 15 de ejemplo hospedado por la entidad de usuario UE.
Según se muestra en la Figura 3, de acuerdo con la sección 6.5.1-1 de la especificación TS 23.282 para el modelo funcional en la red, se utiliza el punto de referencia MCData-SDS-1 para transacciones de datos SDS de unidifusión (unicast) de enlace de subida y de bajada en el plano de control de señalización por la función de distribución SDS 16 del servidor de datos MCData 14 y la función SDS 17 del cliente de datos MCData 15. Este punto de referencia también se utiliza para la señalización de la aplicación de datos MCData durante el establecimiento de la sesión en soporte a la transferencia de datos SDS. El punto de referencia MCData-SDS-2 transporta datos SDS de unidifusión de enlace de subida y de bajada en el plano de medios entre la función de distribución SDS 16 del servidor de datos MCData 14 y la función SdS 17 del cliente de datos MCData 15. El punto de referencia MCData-SDS-3 transporta datos SDS de multidifusión de enlace de bajada en el plano de medios desde la función de distribución SDS 16 del servidor de datos MCData 14 a la función sDs 17 del cliente de datos MCData 15.
La función de distribución SDS 16 del servidor de datos MCData 14 es responsable de las transacciones de datos SDS a los participantes de la comunicación de datos MCData. La función de distribución SDS 16 proporciona la siguiente funcionalidad:
• recepción de transacciones de datos SDS de enlace de subida por medio del punto de referencia MCData-SDS-2;
• replicación de datos SDS según sea necesario para su distribución a aquellos participantes de la comunicación de datos MCData que utilizan transporte unidifusión;
• distribución de datos de enlace de bajada mediante transmisiones de unidifusión IP a aquellos participantes de la comunicación de datos MCData que utilizan transporte unidifusión por medio del punto de referencia MCData-SDS-2; y
• distribución de datos SDS de enlace de bajada utilizando transporte de enlace de bajada de multidifusión por medio del punto de referencia MCData-SDS-3.
El control de transmisión/recepción 16' es responsable del control de transmisión y recepción de las transacciones de datos SDS de MCData entre el cliente de datos MCData remitente, el servidor de datos MCData y el cliente de datos MCData receptor. Para la capacidad SDS, el control de transmisión/recepción 16' es "Envío automático" y "Recepción automática" según se ha descrito anteriormente.
Para las comunicaciones SDS de datos MCData, el servidor de datos MCData 14 proporciona de este modo todas las funciones básicas necesarias para la autenticación, autorización, seguridad, configuración e identidad de cualesquiera clientes de datos MCData 15 (o 15a, 15b, 21, 21a, 21b que se describen más adelante) conectados (registrados) con el mismo.
Esto se muestra en la Figura 4 con más detalle. La Figura 4 muestra un escenario de comunicación entre dos entidades de señalización de vías ferroviarias, en este caso un servidor de señalización de vías ferroviarias ETCS de ejemplo 4 y un cliente de señalización de vías ferroviarias de ejemplo 2. El servidor de señalización de vías ferroviarias 4 contiene una aplicación de señalización 18 que requiere conectividad IP con una aplicación de señalización 6 del cliente de señalización de vías ferroviarias 2. En particular, la comunicación IP entre las entidades de señalización de vías ferroviarias 6 y 18 se compone de mensajes de señalización 19 en forma de mensajes TCP (Protocolo de control de transmisión) de acuerdo con el estándar RFC 793 (o similar), mensajes UDP (protocolo de datagramas de usuario) según el estándar RFC 768 (o similar) y/o mensajes SCTP (Protocolo de transmisión de control de flujos) según el estándar RFC 4960 (o similar).
Se muestra un ejemplo de mensaje de señalización TCP 19 en la mitad izquierda de la Figura 5. El mensaje de señalización TCP 19 se compone de una cabecera TCP 21 y datos de carga útil 22. Para más detalles de la estructura TCP se hace referencia a la RFC 793, y a la RFC 768 y la RFC 4960, respectivamente, para estructuras UDP y SCTP comparables.
Volviendo a la Figura 4, para cada entidad de señalización, en este caso las aplicaciones 6, 18, un cliente de datos MCData 15, 21 está configurado y registrado con el servidor de datos MCData 14 del sistema de MC 13 de la red inalámbrica de LTE del 3GPP 3. El modelo de registro (plano de aplicación) de la configuración y el registro del respectivo cliente de datos MCData 15, 21 con el servidor de datos MCData 14 es según se muestra en la Figura 3. Los clientes de datos MCData 15, 21 y el servidor de datos MCData 14 están configurados cada uno para comunicaciones SDS de datos MCData para que puedan intercambiar mensajes SDS de datos MCData 22 entre sí a través del servidor de datos MCData 14.
Los clientes de datos MCData 15, 21 pueden cada uno formar parte de una entidad de usuario de MC (UE) 23, 24 que contiene todas las funciones básicas de LTE 25 necesarias para la comunicación LTE a través de la red inalámbrica 3, así como cualesquiera servicios de MC adicionales tales como un cliente de MCPTT de ejemplo 26 y un cliente de MCVideo de ejemplo 27, si es necesario. Por supuesto, los clientes de MCPTT y de MCVideo 26, 27 son opcionales y no son necesarios para la operación del procedimiento de comunicación descrito en este documento.
Para completar la configuración, el sistema de MC 13 de la red inalámbrica 3 comprende funciones básicas de LTE en el lado de la red 28, que incluyen una base de datos de usuario 29 para usuarios de datos MCData, así como (opcionalmente) un servidor de MCPTT 30 y un servidor de MCVideo 31.
Después de haber configurado y registrado los clientes de datos MCData 15, 21 con el servidor de datos MCData 14 para la transferencia SDS de datos MCData, una comunicación según protocolo TCP, UDP o SCTP de ejemplo entre una de las entidades de señalización de vías ferroviarias 6, 18 y la otra (o vice versa) es según se indica a continuación.
La entidad de señalización remitente, en este caso la aplicación de señalización 6 del cliente de señalización de vías ferroviarias 2, envía un mensaje de señalización 19, por ejemplo, un paquete de datos TCP (Figura 5), a su cliente de datos MCData 15. En el presente ejemplo, El cliente de datos MCData 15 es parte del usuario de MC 23 hospedado por la entidad de usuario UE dentro del ferrocarril 2.
El cliente de datos MCData 17 empaqueta el mensaje de señalización recibido 19 en un mensaje de datos MCData 22 se muestra en la mitad derecha de la Figura 5. La etapa de empaquetar el mensaje de señalización 19 dentro del mensaje SDS de datos MCData 22 está representada esquemáticamente por la flecha 27. Por supuesto, si el mensaje de señalización 19 está en formato UDP o SCTP, sería empaquetado de la misma manera dentro del mensaje SDS de datos MCData 22. Además, cualquiera de los mensajes de señal según protocolo TCP, UDP o SCTP 19 podría ser transportado en un paquete de datos IP envolvente y, como tal, ser empaquetado en el mensaje SDS de datos MCData 22.
En general, el mensaje de señalización 19 es insertado en una parte de carga útil 32 del mensaje SDS de datos MCData 22, complementado por una cabecera de SDS 33, es decir, una cabecera de SDS 33 y una parte de carga útil 32 que lleva el mensaje de señalización 19 que forma el mensaje SDS de datos MCData 22. Por supuesto, el mensaje de señalización 19 podría ser colocado en otro lugar dentro del mensaje SDS de datos MCData 22, dependiendo del formato de mensaje SDS de datos MCData real utilizado en la implementación LTE del 3GPP específica utilizada en la red inalámbrica 3.
Para permitir los modos de envío automático y de recepción automática en la transferencia SDS de acuerdo con la especificación TS 23.282, las longitudes del mensaje SDS de datos MCData 22 generalmente se mantienen por debajo de los 1000 bytes, que es suficiente para llevar mensajes de señalización 19 de sistemas de señalización de vías ferroviarias ETCS o CBTC desplegados actualmente.
Volviendo a la Figura 4, el mensaje SDS de datos MCData 22 que lleva (tuneliza) el mensaje de señalización según protocolo TCP, UDP o SCTP 19 es reenviado a continuación en un modo de llamada SDS privada (1:1) desde el cliente de datos MCData 15 a través de la red inalámbrica 3 y el servidor de datos MCData 14 al cliente de datos MCData 24 de la entidad de señalización de destino (receptora), en este caso, la aplicación de señalización 18 del servidor de señalización de vías ferroviarias ETCS 4.
En el cliente de datos MCData receptor 21 se extrae el mensaje de señalización 19 del mensaje SDS de datos MCData recibido 22. El mensaje de señalización extraído 19 es enviado a la entidad de señalización de destino final, en este caso, la aplicación de señalización 18.
Según se muestra en la Figura 4, el servidor de señalización de vías ferroviarias 4 y su usuario de MC 24 que comprende el cliente de datos MCData 21 puede tener una conexión permanente o alámbrica con el servidor de datos MCData 14 del sistema de MC 13, mientras que el cliente de datos MCData 17 del usuario de MC 23 del cliente de señalización de vías ferroviarias 2 está conectado a través de la red inalámbrica 3 al servidor de datos MCData 14. Por supuesto, también el cliente de datos MCData 21 podría estar conectado al servidor de datos MCData 14 a través de la red inalámbrica 3 u otra red inalámbrica, por ejemplo, cuando es parte de una entidad de señalización móvil o remota en el campo.
La Figura 6 muestra una forma de realización alternativa del procedimiento de las Figuras 4 y 5 utilizando una ruta de mensaje doble para fines de redundancia. En este caso, el mensaje de señalización 19 a enviar está duplicado en la aplicación de señalización remitente 6 y es enviado a dos clientes de datos MCData 15a y 15b que los dos han sido configurados y registrados con el servidor de datos MCData 14 del sistema de MC 13 para la transferencia SDS de datos MCData. De la misma manera, se han configurado dos clientes de datos MCData 21a y 21b para la entidad de señalización receptora 18 y se han registrado con el servidor de datos MCData 14 para la transferencia SDS de datos MCData.
En cada cliente de datos MCData 17a, 17b el mensaje de señalización recibido 19 es empaquetado (27) en un mensaje SDS de datos MCData separado 22a, 22b. Cada uno de los dos mensajes SDS de datos MCData 22a, 22b es enviado a través de la red inalámbrica 3 y el servidor de datos MCData 14 - en un modo de llamada privada - a uno de los clientes de datos MCData 21a, 21b. Es decir, el primer mensaje SDS de datos MCData 22a es enviado desde el un cliente de datos MCData 17a al un cliente de datos MCData 21a, y el mensaje SDS de datos MCData 22b es enviado desde el otro cliente de datos MCData 17a al otro cliente de datos MCData receptor 21b.
En cada uno de los clientes de datos MCData receptores 21a, 21b se extrae el mensaje de señalización según protocolo TCP, UDP o SCTP original 19 del mensaje SDS de datos MCData recibido 22a, 22b y es enviado a la entidad 18. Con fines de redundancia y corrección de errores, la entidad de señalización 18 puede realizar una verificación cruzada de los dos mensajes de señalización recibidos 19 entre sí o, en caso de un fallo en la comunicación de uno de los mensajes SDS de datos MCData 22a, 22b o uno de los mensajes de señalización 19, utilizar el mensaje de señalización que no ha fallado (sobreviviente) 19.
Aunque en la forma de realización de la Figura 6 se ha utilizado una red inalámbrica común 3 para transmitir los dos mensajes SDS de datos MCData 22a, 22b, también se podrían enviar a través de diferentes redes inalámbricas 3a, 3b, según se muestra en la forma de realización de la Figura 7.
De acuerdo con la Figura 7, no sólo de la red inalámbrica 3 puede estar separada en dos redes inalámbricas diferentes 3a, 3b, sino que también se puede duplicar el servidor de datos MCData 14 de manera que cada red inalámbrica 3a, 3b utiliza su propio servidor de datos MCData 14a, 14b. De esta manera, las rutas de mensaje para los dos mensajes SDS de datos MCData 22a, 22b están completamente separadas para la redundancia.
La Figura 8 muestra una forma de realización adicional que usa llamadas en grupo de datos MCData para establecer comunicaciones redundantes. De nuevo, para cada entidad de señalización 6, 18 se han configurado clientes de datos MCData duplicados 15a, 15b y 21a, 21b y registrado, respectivamente, con el servidor de datos MCData común 14 (o con servidores de datos MCData separados 14a, 14b) para transferencias SDS de datos MCData a través de la red inalámbrica 3 (o las redes inalámbricas 3a, 3b). Se inicia una duplicación de mensajes por parte del primer cliente de datos MCData 15a que recibe el mensaje de señalización 19 procedente de la entidad de señalización remitente 6 en que se establece una llamada en grupo (llamada 1:n) desde el cliente de datos MCData 15a a un grupo que comprende al menos los dos clientes de datos MCData receptores 21a, 21b.
Como en las llamadas en grupo la duplicación del mensaje SDS de datos MCData 22 en los mensajes SDS de datos MCData 22a, 22b suele producirse a nivel del servidor de datos MCData 14, la redundancia se puede mejorar aún más si el grupo de la llamada en grupo SDS de datos MCData también comprende uno de los o los dos primeros clientes de datos MCData 15a, 15b. De esta manera, el servidor de datos MCData 14 refleja un mensaje SDS de datos MCData recibido 22 de vuelta a uno de los o los dos primeros clientes de datos MCData 15a, 15b, véase el mensaje SDS 22c. Cualquier cliente de datos MCData, en este caso el cliente de datos MCData 15b que recibe dicho mensaje SDS de datos MCData 22c procedente del servidor de datos MCData 14, puede estar configurado para reenviar dicho mensaje SDS de datos MCData recibido 22c en una llamada en grupo adicional (1:n) a todos los demás miembros 15a, 15b, 21a, 21b del grupo, "desbordando" con ello el sistema con mensajes SDS de datos MCData redundantes.
Para evitar desbordamientos indebidos y tráfico innecesario, se pueden reconfigurar las llamadas en grupo en el sistema de MC de modo que se suprimen ciertas conexiones dentro de una llamada en grupo, tales como el envío de un mensaje SDS de datos MCData desde 15a a 15b, desde 15b a 15a, desde 21a a 21b, desde 21b a 21a, desde 15a a 21b, desde 21b a 15a, desde 21a a 15b y desde 15b a 21a. Por lo tanto, solo se retienen las rutas de comunicación dobles que son absolutamente necesarias para la redundancia.
En cualquiera de estas formas de realización, la entidad de señalización de destino, en este caso la aplicación de señalización 18, puede recibir uno o dos mensajes de señalización extraídos 19 procedentes de ya sea uno o los dos de clientes de datos MCData 21a, 21b, y realizar una verificación cruzada de los mismos y/o usar el que no ha fallado. Alternativamente, los clientes de datos MCData receptores 21a, 21bpueden estar vinculados entre sí y negociar cuál de los mensajes SDS de datos MCData recibidos 22a, 22b se utilizará para la extracción del mensaje de señalización 19. En caso de un fallo de comunicación en una de las rutas de comunicación duplicadas para los mensajes SDS de datos MCData 22, 22a, 22b, 22c, por supuesto, solo se utilizarán los mensajes SDS de datos MCData que no han fallado para la extracción de mensajes de señalización.
La invención no se limita a las formas de realización específicas descritas en el presente documento, sino que engloba todas las variantes, modificaciones y combinaciones de las mismas que caigan en el alcance de las reivindicaciones adjuntas.

Claims (12)

REIVINDICACIONES
1. Un procedimiento de comunicación según protocolo de control de transmisión, TCP, protocolo de datagramas de usuario, UDP o protocolo de transmisión de control de flujos, SCTP, entre dos entidades de señalización de vías ferroviarias (6, 18) a través de una red inalámbrica (3) que proporciona servicios de datos críticos de misión, MCData, según un estándar LTE del 3GPP que proporciona dichos servicios de datos MCData, que comprende: configurar un primer cliente de datos MCData (15, 15a) para la primera entidad de señalización (6) y registrar el primer cliente de datos MCData (15, 15a) con un servidor de datos MCData (14, 14a) de la red inalámbrica (3) para transferencias de servicios de datos cortos, SDS, de datos MCData;
configurar un segundo cliente de datos MCData (21, 21a) para la segunda entidad de señalización (18) y registrar el segundo cliente de datos MCData (21, 21a) con el servidor de datos MCData (14, 14a) para transferencias SDS de datos MCData;
recibir un mensaje de señalización (19) transmitido según protocolo TCP, UDP o SCTP desde la primera entidad de señalización (6) en el primer cliente de datos MCData (15, 15a);
en el primer cliente de datos MCData (15, 15a), empaquetar el mensaje de señalización (19) en un mensaje SDS de datos MCData (22, 22a);
enviar el mensaje SDS de datos MCData (22, 22a) desde el primer cliente de datos MCData (15, 15a) al segundo cliente de datos MCData (21, 21a) a través del servidor de datos MCData (14, 14a);
extraer el mensaje de señalización (19) del mensaje SDS de datos MCData (22, 22a) en el segundo cliente de datos MCData (21, 21a); y
enviar el mensaje de señalización (19) a la segunda entidad de señalización (18).
2. El procedimiento según la reivindicación 1, en el que el mensaje SDS de datos MCData (22) es enviado en modo de envío automático de datos MCData desde el primer cliente de datos MCData (15, 15a) al servidor de datos MCData (14, 14a).
3. El procedimiento según la reivindicación 1 o 2, en el que el mensaje SDS de datos MCData (22, 22a) es enviado en modo de recepción automática de datos MCData desde el servidor de datos MCData (14, 14a) al segundo cliente de datos MCData (21, 21a).
4. El procedimiento según una cualquiera de las reivindicaciones 1 a 3, en el que el mensaje SDS de datos MCData (22, 22a) es enviado en un modo de llamada privada.
5. El procedimiento según una cualquiera de las reivindicaciones 1 a 3, en el que el mensaje SDS de datos MCData (22) es enviado en un modo de llamada en grupo a una pluralidad de segundos clientes de datos MCData (21a, 21b).
6. El procedimiento según cualquiera de las reivindicaciones 1 a 4, que comprende:
configurar un primer cliente de datos MCData adicional (15b) para la primera entidad de señalización (6) y registrar el primer cliente de datos MCData adicional (15b) con el servidor de datos MCData (14) para transferencia SDS de datos MCData;
configurar un segundo cliente de datos MCData adicional (21b) para la segunda entidad de señalización (18) y registrar el segundo cliente de datos MCData adicional (21b) con el servidor de datos MCData (14) para transferencia SDS de datos MCData;
recibir el mensaje de señalización (19) procedente de la primera entidad de señalización (6) también en el primer cliente de datos MCData adicional (15b);
en el primer cliente de datos MCData adicional (15b), empaquetar el mensaje de señalización (19) en un mensaje SDS de datos MCData adicional (22b);
enviar el mensaje SDS de datos MCData adicional (22b) desde el primer cliente de datos MCData adicional (15b) al segundo cliente de datos MCData adicional (22b) a través del servidor de datos MCData (14);
si para alguno de los dos mensajes SDS de datos MCData (22a, 22b) ha fallado su recepción en el respectivo segundo cliente de datos MCData (21a, 21b), extraer el mensaje de señalización (19) del mensaje SDS de datos MCData que no ha fallado (22a, 22b) para su envío a la segunda entidad de señalización (21b).
7. El procedimiento según una cualquiera de las reivindicaciones 1 a 4, que comprende:
configurar un primer cliente de datos MCData adicional (15b) para la primera entidad de señalización (6) y registrar el primer cliente de datos MCData adicional (15b) con un servidor de datos MCData adicional (14b) para transferencia s Ds de datos MCData;
configurar un segundo cliente de datos MCData adicional (21b) para la segunda entidad de señalización (18) y registrar el segundo cliente de datos MCData adicional (21b) con el servidor de datos MCData adicional (14b) para transferencia SDS de datos MCData;
recibir el mensaje de señalización (19) procedente de la primera entidad de señalización (6) también en el primer cliente de datos MCData adicional (15b);
en el primer cliente de datos MCData adicional (15b), empaquetar el mensaje de señalización (19) en un mensaje SDS de datos MCData adicional (22b);
enviar el mensaje SDS de datos MCData adicional (22b) desde el primer cliente de datos MCData adicional (15b) al segundo cliente de datos MCData adicional (21b) a través del servidor de datos MCData adicional (14b);
si para alguno de los dos mensajes SDS de datos MCData (22a, 22b) ha fallado su recepción en el respectivo segundo cliente de datos MCData (21a, 21b), extraer el mensaje de señalización (19) del mensaje SDS de datos MCData que no ha fallado (22a, 22b) para su envío a la segunda entidad de señalización (18).
8. El procedimiento de la reivindicación 6 o 7, en el que el mensaje de señalización (19) es duplicado en la primera entidad de señalización (6) para su envío a los dos primeros clientes de datos MCData (15a, 15b).
9. El procedimiento de la reivindicación 8, en el que el mensaje de señalización según protocolo TCP, UDP o SCTP (19) es duplicado según un estándar MPTCP, MPUDP o MPSCTP, respectivamente.
10. El procedimiento según una cualquiera de las reivindicaciones 1 a 3, que comprende:
configurar un primer cliente de datos MCData adicional (15b) para la primera entidad de señalización (6) y registrar el primer cliente de datos MCData adicional (15b) con el servidor de datos MCData (14, 14b) para transferencia SDS de datos MCData;
configurar un segundo cliente de datos MCData adicional (21b) para la segunda entidad de señalización (18) y registrar el segundo cliente de datos MCData adicional (21b) con el servidor de datos MCData (14, 14b) para transferencia SDS de datos MCData;
definir un grupo que contiene a los dos segundos clientes de datos MCData (21a, 21b) como miembros;
en el que el mensaje SDS de datos MCData (22) es enviado en un modo de llamada en grupo a todos los miembros del grupo.
11. El procedimiento de la reivindicación 10, en el que el grupo también contiene a los dos primeros clientes de datos MCData (15a, 15b) como miembros y en el que, al recibir el mensaje SDS de datos MCData (22) en el primer cliente de datos MCData adicional (15b), el mensaje SDS de datos MCData (22) es reenviado en modo de llamada en grupo a todos los miembros del grupo.
12. El procedimiento de una cualquiera de las reivindicaciones 1 a 11, en el que la primera entidad de señalización (6) es un controlador de ferrocarril a bordo y la segunda entidad de señalización (18) es un servidor de señalización junto a la vía ferroviaria, o vice versa.
ES17157789T 2017-02-24 2017-02-24 Un procedimiento de comunicación entre dos entidades de señalización de vías ferroviarias Active ES2745105T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP17157789.3A EP3367625B1 (en) 2017-02-24 2017-02-24 A method of communication between two railway signalling entities

Publications (1)

Publication Number Publication Date
ES2745105T3 true ES2745105T3 (es) 2020-02-27

Family

ID=58185324

Family Applications (1)

Application Number Title Priority Date Filing Date
ES17157789T Active ES2745105T3 (es) 2017-02-24 2017-02-24 Un procedimiento de comunicación entre dos entidades de señalización de vías ferroviarias

Country Status (3)

Country Link
EP (1) EP3367625B1 (es)
ES (1) ES2745105T3 (es)
PL (1) PL3367625T3 (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115022825B (zh) * 2017-03-24 2024-02-09 三星电子株式会社 任务关键数据通信系统中管理短数据服务的方法和用户设备
CN112788549B (zh) * 2021-01-06 2022-04-19 武汉虹信科技发展有限责任公司 一种cbtc组播传输方法及系统

Also Published As

Publication number Publication date
EP3367625A1 (en) 2018-08-29
EP3367625B1 (en) 2019-06-12
PL3367625T3 (pl) 2019-10-31

Similar Documents

Publication Publication Date Title
ES2732075T3 (es) Método de transporte de un flujo multipunto en una red de área local y dispositivo para la conexión que implementa el método
ES2942038T3 (es) Procedimiento y aparato para admitir la comunicación de la retransmisión de UE a red en un sistema de comunicación inalámbrica
US8116230B2 (en) Establishing communication pathways between infrastructure devices in a group communication system implemented over a wide area network
ES2940896T3 (es) Procedimiento y aparato para admitir la comunicación de la retransmisión de UE a red en un sistema de comunicación inalámbrico
TWI345898B (en) Method, wireless communication system, tangible machine-readable medium, and communication apparatus for transmitting downlink hybrid automatic repeat request packets based on a multi-hop relay standard
JP4823359B2 (ja) マルチホップメッシュネットワークを介する管理トラフィックの送信
US9332428B2 (en) Method and device for managing encrypted group rekeying in a radio network link layer encryption system
CN102484656B (zh) 用于中继分组的方法和设备
CN110365470B (zh) 一种密钥生成方法和相关装置
TW201108674A (en) Method and apparatus for link aggregation in a heterogeneous communication system
ES2932964T3 (es) Procedimiento y aparato para solicitar recursos de transmisión de enlace lateral en un sistema de comunicación inalámbrica
ES2745105T3 (es) Un procedimiento de comunicación entre dos entidades de señalización de vías ferroviarias
US11343786B2 (en) Method for broadcast gateway signaling using cloud network and apparatus for the same
KR20150103734A (ko) Ue 들의 mtc 그룹에 대한 브로드캐스팅에서의 그룹 인증
ES2441448T3 (es) Procedimiento de transmisión de datos multimedia en redes de comunicación ad hoc
US8416727B2 (en) Communicating a group message packet over a wide area network
US9591550B2 (en) Method and apparatus for enhancing voice service performance in communication system
US10601602B2 (en) Hybrid data transport solution, in particular for satellite links
US9998205B2 (en) Transparent satellite communications in a cellular centric M2M network
US20230086337A1 (en) Methods, infrastructure equipment and wireless communications networks
US20130258942A1 (en) Independent signalling method for bearer management
CN112640511B (zh) 用于提供可靠无线通信的技术
US9432851B2 (en) Bearer signalling management
KR102593734B1 (ko) 클라우드 네트워크를 이용한 방송 게이트웨이 시그널링 방법 및 이를 위한 장치
JP2007274658A (ja) 移動制御ネットワークシステム、ルータ及び移動端末