ES2512444T3 - Sistema y método para detectar y comunicar pérdida y retención de sincronización en un esquema de transferencia de datos en tiempo real - Google Patents

Sistema y método para detectar y comunicar pérdida y retención de sincronización en un esquema de transferencia de datos en tiempo real Download PDF

Info

Publication number
ES2512444T3
ES2512444T3 ES11773245.3T ES11773245T ES2512444T3 ES 2512444 T3 ES2512444 T3 ES 2512444T3 ES 11773245 T ES11773245 T ES 11773245T ES 2512444 T3 ES2512444 T3 ES 2512444T3
Authority
ES
Spain
Prior art keywords
message
destination node
data frame
data
received
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
ES11773245.3T
Other languages
English (en)
Inventor
Bipin Balakrishnan
Andrei Radulescu
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.)
Ericsson Modems SA
Original Assignee
Ericsson Modems SA
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 Ericsson Modems SA filed Critical Ericsson Modems SA
Application granted granted Critical
Publication of ES2512444T3 publication Critical patent/ES2512444T3/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
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • H04L7/0016—Arrangements for synchronising receiver with transmitter correction of synchronization errors
    • H04L7/002—Arrangements for synchronising receiver with transmitter correction of synchronization errors correction by interpolation
    • H04L7/0029—Arrangements for synchronising receiver with transmitter correction of synchronization errors correction by interpolation interpolation of received data signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0083—Formatting with frames or packets; Protocol or part of protocol for error control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0078—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0091—Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location arrangements specific to receivers, e.g. format detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/08—Arrangements for detecting or preventing errors in the information received by repeating transmission, e.g. Verdan system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
    • H04L1/1678—Details of the supervisory signal the supervisory signal being transmitted together with control information where the control information is for timing, e.g. time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • H04L7/0079—Receiver details
    • H04L7/0083—Receiver details taking measures against momentary loss of synchronisation, e.g. inhibiting the synchronisation, using idle words or using redundant clocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • H04L7/04—Speed or phase control by synchronisation signals
    • H04L7/10—Arrangements for initial synchronisation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un método para manejar una pérdida de límite de mensaje en una transmisión de datos en tiempo real sobre una interconexión, que comprende: recibir sobre la interconexión (10) y por un nodo de destino (14) una pluralidad de mensajes (22), en donde cada mensaje (22) incluye una o más tramas de datos (24), y cada trama de datos (24) de cada mensaje (22) incluye una marca de fin de mensaje (30) y un número de secuencia de mensaje (28), y la marca de fin de mensaje (30) se fija cuando la trama de datos (24) es la última trama de datos (24) en un mensaje particular (22), y el número de secuencia de mensaje (28) es diferente para mensajes diferentes (22); caracterizado por: determinar la pérdida de límite de mensaje por uno de un primer mensaje (22) y un segundo mensaje (22) a ser recibido sobre la interconexión detectando que o bien: (a) se ha recibido al menos una trama de datos que pertenece al primer mensaje, y se ha recibido una trama de datos (24) que pertenece al segundo mensaje (22) diferente del primer mensaje antes que de que se haya recibido una trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, o bien (b) se ha recibido una trama de datos que pertenece a un tercer mensaje (22) que tiene un número de secuencia que es al menos dos veces mayor que un número de secuencia asociado con el primer mensaje después de que se haya recibido la trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, y no se haya recibido ninguna trama de datos que pertenece al segundo mensaje que tiene un número de secuencia mayor que el número de secuencia del primer mensaje y menor que el número de secuencia del tercer mensaje.

Description

5
10
15
20
25
30
35
40
45
50
55
E11773245
06-10-2014
DESCRIPCIÓN
Sistema y método para detectar y comunicar pérdida y retención de sincronización en un esquema de transferencia de datos en tiempo real
Campo técnico
La presente invención se refiere a transporte de datos en tiempo real sobre una interconexión punto a punto o basada en red, y específicamente a un protocolo para detectar y notificar pérdidas de datos, por ejemplo, en una arquitectura de dispositivo móvil basada en interconexión.
Antecedentes
El transporte de datos sobre enlaces propensos a error podría conducir a daños y/o pérdida ocasional de datos a menos que se lleve a cabo una retransmisión de los datos recibidos con error o los datos que no se reciben en absoluto. Dado que para datos en tiempo real, tales retransmisiones obstaculizan la entrega puntual de datos, normalmente los datos con requisitos de tiempo real se entregan con errores y/o algunas veces con huecos (pérdida de datos) a la aplicación en tiempo real. La mayoría de las aplicaciones en tiempo real pueden tolerar los huecos en los datos siempre que no hayan perdido algunos puntos de sincronización (tales como límites de mensaje). Tras las pérdidas de sincronización, las aplicaciones en tiempo real necesitan un mecanismo fiable para volver a la sincronización. Este mecanismo también debería funcionar para esquemas de transporte de datos bidireccionales que no permiten o pueden no permitir retransmisiones de datos. Además, las aplicaciones en tiempo real pueden intercambiar mensajes de tamaño variable compuestos de tramas de datos de tamaño variable o podrían intercalar mensajes de tamaño fijo con los de tamaño variable, lo cual hace la detección de pérdidas de sincronización más desafiante que el caso donde las aplicaciones intercambian mensajes de tamaño fijo o tramas de datos de tamaño fijo o ambos.
En la Alianza de Interfaz de Procesador Industrial Móvil (MIPI), se están desarrollando varios estándares de interfaz hardware a fin de permitir hacer de interfaz sin discontinuidad entre procesadores y otros circuitos integrados de aplicaciones específicas (ASIC) en una plataforma móvil. El Protocolo Unificado (UniPro), que es un estándar de interfaz hardware tal, permite el intercambio de datos a altas velocidades entre diferentes componentes en un sistema móvil sobre redes pastilla a pastilla construidas de enlaces serie de alta velocidad. Es un protocolo genérico, fuertemente estratificado basado en una pila de protocolo de referencia OSI que proporciona manejo de errores (a través de retransmisiones basadas en Comprobaciones de Redundancia Cíclica (CRC)), control de flujo, encaminamiento y garantías de Calidad de Servicio (QoS). Algunas de las aplicaciones soportadas por UniPro pertenecen a la categoría de tiempo real. Las aplicaciones en tiempo real generan flujos de datos que requieren una entrega puntual. En otras palabras, si los datos no se entregan antes de un tiempo límite particular, no sirve de nada. Un ejemplo de tal aplicación es el vídeo en bruto donde los datos no están comprimidos y el requisito de ancho de banda es alrededor de 500 Mbps. Para tales aplicaciones, el manejo de errores a través de retransmisiones dificulta una entrega puntual.
Por lo tanto es mejor entregar datos con errores. La mayoría del tiempo, los receptores pueden tolerar pérdidas de datos pero la pérdida de información de sincronización puede ser un problema. Por ejemplo, generalmente hay dos tipos de señales de sincronización en vídeo: sincronismo horizontal, y sincronismo vertical. De una manera muy simplificada, las señales de sincronismo horizontal dicen al procesador cuándo mover la señal de vídeo a la siguiente línea inferior a través de la pantalla y la señal de sincronismo vertical dice al procesador cuándo empezar de nuevo desde la parte superior de la pantalla. La pérdida de cualquiera de las dos o ambas de estas señales podría afectar severamente la calidad del vídeo visualizado.
Por lo tanto, hay una necesidad de un protocolo para detectar una pérdida de información de sincronización en el receptor y comunicarla al transmisor. Un requisito adicional para este protocolo es que debería ser simple (es decir, ser fácilmente integrado en protocolos de transporte de datos existentes o emergentes tales como UniPro) y también no debería depender de ningún modo fiable de comunicación. Por consiguiente, sería deseable proporcionar métodos, modos y sistemas para detección y comunicación de pérdida de sincronización y recuperación de sincronización en un esquema de transferencia de datos en tiempo real que se integre fácilmente y sea fiable.
El documento de patente WO9509504 describe un método y aparato para detectar condiciones fuera de sincronismo en un flujo recibido. Cada paquete recibido transporta una cabecera que indica el número de trama al que pertenece el paquete y si el paquete es el primero o el último en la trama.
Compendio
Es por lo tanto un aspecto general de la invención proporcionar un protocolo de comunicaciones de datos que obviará o minimizará los problemas del tipo descrito previamente. Las realizaciones ejemplares abordan el transporte de datos en tiempo real sobre interconexiones punto a punto o basadas en red y específicamente a un protocolo para detectar y notificar pérdidas de sincronización en tal esquema de transferencia de datos. Una transmisión de datos en tiempo real requiere una entrega puntual y por lo tanto podría tener cero o un número fijo de retransmisiones que provocan errores o huecos en los datos que se entregan. Tal transmisión de datos en tiempo
10
15
20
25
30
35
40
45
50
55
60
E11773245
06-10-2014
real consta de una transmisión de un flujo de datos como múltiples mensajes, que a su vez se componen de tramas de datos de tamaño más pequeño. Estas tramas de datos incluyen un campo de desplazamiento, que indica el número de bytes de datos transmitidos hasta el momento desde la aplicación en tiempo real particular, en cada una de las tramas de datos transmitidas desde el origen al destino. También cada una de las tramas de datos transporta un número de secuencia de mensaje para identificar a qué mensaje pertenece. El final de un mensaje se señala explícitamente por una marca de Fin de Mensaje (EoM) en la última trama de datos del mensaje, y se entiende implícitamente a partir del cambio de número de secuencia de mensaje.
Para aplicaciones que son sensibles a una pérdida de límites de mensaje, el receptor se configura para enviar una indicación de pérdida de sincronización cuando se detecta tal evento. A fin de proteger la indicación de pérdida de sincronización y/o la respuesta posterior, para volver al sincronismo, desde el transmisor que se pierde, se usa un primer temporizador (Temporizador Principal) en el receptor cuyo valor es al menos la suma del retardo de ida y vuelta y el retardo de procesamiento en el transmisor. Si la respuesta no se recibe antes de que el temporizador expire, la indicación de pérdida de sincronización se reenvía después de reiniciar el temporizador principal. Un segundo temporizador (Temporizador auxiliar (aux.)) en el receptor se usa para proteger en el caso que la trama de datos que transporta el fin de la marca de mensaje se pierda y no lleguen tramas de datos adicionales. El temporizador aux. se inicia al comienzo de un nuevo mensaje (por ejemplo, el mensaje #1) y se reinicia cuando se recibe una trama de datos que pertenece a ese mensaje. El temporizador aux. se detiene cuando la marca de EoM se fija para ese mensaje (es decir, la última trama de datos se recibe con respecto al mensaje #1). El valor de expiración del temporizador aux. se negocia durante la configuración de conexión en base a las características de la aplicación. En caso de que expire el temporizador aux., el receptor envía un mensaje de consulta de estado al transmisor para comprender si un error causó la ausencia de datos. Este mensaje de consulta de estado también se protege por el primer temporizador con un retardo de ida y vuelta como su valor.
Según un primer aspecto de la presente invención, un método para manejar una pérdida de límite de mensaje en transmisión de datos en tiempo real sobre una interconexión incluye los pasos de recibir sobre la interconexión y por un nodo de destino una pluralidad de mensajes, en donde cada mensaje incluye una o más tramas de datos, y cada trama de datos de cada mensaje incluye una marca de fin de mensaje y un número de secuencia de mensaje, y la marca de fin de mensaje se fija cuando la trama de datos es la última trama de datos en un mensaje particular, y el número de secuencia de mensaje es diferente para mensajes diferentes; y determinar la pérdida de límite de mensaje para uno de un primer mensaje y un segundo mensaje a ser recibidos sobre la interconexión detectando que o bien: (a) se ha recibido al menos una trama de datos que pertenece al primer mensaje, y se ha recibido una trama de datos que pertenece al segundo mensaje diferente del primer mensaje antes de que se haya recibido una trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, o bien (b) se haya recibido una trama de datos que pertenece a un tercer mensaje que tiene un número de secuencia que es al menos dos veces mayor que un número de secuencia asociado con el primer mensaje después de que se ha recibido la trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, y no se haya recibido ninguna trama de datos que pertenece al segundo mensaje que tiene un número de secuencia mayor que el número de secuencia del primer mensaje y menor que el número de secuencia del tercer mensaje.
Según un segundo aspecto, un aparato para manejar una pérdida de límite de mensaje en una transmisión de datos de tiempo real, incluye un transceptor del nodo de destino configurado para recibir mensajes sobre una interconexión, en donde cada mensaje incluye una o más tramas de datos, y cada trama de datos de cada mensaje incluye una marca de fin de mensaje y un número de secuencia de mensaje, la marca de fin de mensaje fijada cuando la trama de datos es la última trama de datos en un mensaje particular, y el número de secuencia de mensaje es diferente para mensajes diferentes; y un procesador de nodo de destino configurado para determinar la pérdida de límite de mensaje para uno de un primer mensaje y un segundo mensaje a ser recibido sobre la interconexión detectando que o bien: (a) se ha recibido al menos una trama de datos que pertenece al primer mensaje, y se ha recibido una trama de datos que pertenece al segundo mensaje diferente del primer mensaje antes de que se haya recibido una trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, o bien (b) se ha recibido una trama de datos que pertenece a un tercer mensaje que tiene un número de secuencia que es al menos dos veces mayor que un número de secuencia asociado con el primer mensaje después de que se haya recibido la trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, y no se haya recibido ninguna trama de datos que pertenece al segundo mensaje que tiene un número de secuencia mayor que el número de secuencia del primer mensaje y menor que el número de secuencia del tercer mensaje.
Según un tercer aspecto, un medio legible por ordenador no transitorio de instrucciones para corregir una pérdida de límite de mensaje en una transmisión de datos en tiempo real sobre una interconexión incluye un primer juego de instrucciones adaptadas para recibir, sobre la interconexión y en un nodo de destino, uno o más mensajes, en donde cada mensaje incluye una o más tramas de datos, y cada trama de datos de cada mensaje incluye una marca de fin de mensaje y un número de secuencia de mensaje, la marca de fin de mensaje fijada cuando la trama de datos es la última trama de datos en un mensaje particular, y el número de secuencia de mensaje es diferente para mensajes diferentes; y un segundo juego de instrucciones adaptado para determinar la pérdida de límite de mensaje para uno de un primer mensaje y un segundo mensaje a ser recibidos sobre la interconexión detectando que o bien: (a) se ha recibido al menos una trama de datos que pertenece al primer mensaje, y se ha recibido una trama de datos que pertenece al segundo mensaje diferente del primer mensaje antes de que se haya recibido una trama de datos que
15
25
35
45
E11773245
06-10-2014
tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, o bien (b) se ha recibido una trama de datos que pertenece a un tercer mensaje que tiene un número de secuencia que es al menos dos veces mayor que un número de secuencia asociado con el primer mensaje después de que se haya recibido la trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, y no se haya recibido ninguna trama de datos que pertenece al segundo mensaje que tiene un número de secuencia mayor que el número de secuencia del primer mensaje y menor que el número de secuencia del tercer mensaje, un tercer juego de instrucciones adaptado para transmitir por el nodo de destino un mensaje de pérdida de sincronización, un cuarto juego de instrucciones adaptado para recibir un mensaje de informe de estado por el nodo de destino en respuesta al mensaje de pérdida de sincronización; y un quinto juego de instrucciones adaptado para sincronizar datos de mensaje recibidos de manera que se pueda determinar un límite de mensaje previo según el mensaje de informe de estado.
Breve descripción de los dibujos
El anterior y otros objetos y rasgos del presente concepto inventivo general llegarán a ser evidente y más fácilmente apreciados a partir de la siguiente descripción de las realizaciones con referencia a las siguientes figuras, en donde números de referencia iguales se refieren a partes iguales en todas las diversas figuras a menos que se especifique de otro modo, y en donde:
La FIG. 1 es un diagrama de bloques de alto nivel que representa dos dispositivos que comunican a través de una interconexión y que pueden usar protocolos de detección de pérdida de límite de mensaje según las realizaciones ejemplares para recuperar los límites de fin de mensaje y corregir la transferencia de datos entre los mismos;
La FIG. 2 es un diagrama de bloques de un par transmisor-receptor (o nodo de origen-destino) dentro de un dispositivo que ilustra los mensajes transmitidos entre los mismos y la composición de los mensajes para incluir tramas de datos según una realización ejemplar;
La FIG. 3 ilustra una secuencia de transmisión de mensaje ejemplar de una aplicación en tiempo real;
La FIG. 4 ilustra campos de una trama de datos que se pueden incluir en una cabecera de paquete de un mensaje transmitido por una aplicación en tiempo real según las realizaciones ejemplares;
La FIG. 5 representa un mensaje de Consulta de Estado/Pérdida de Sincronismo enviado por un nodo de origen a un nodo de destino según las realizaciones ejemplares;
La FIG. 6 representa un mensaje de informe de estado según las realizaciones ejemplares;
La FIG. 7 ilustra el funcionamiento del protocolo de detección de pérdida de límite de mensaje cuando no hay errores en ningún enlace entre los nodos de origen y de destino según las realizaciones ejemplares;
La FIG. 8 ilustra el funcionamiento del protocolo de detección de pérdida de límite de mensaje cuando hay errores en uno o más de los enlaces entre los nodos de origen y de destino según las realizaciones ejemplares;
La FIG. 9 ilustra el funcionamiento del protocolo de detección de pérdida de límite de mensaje cuando hay errores en uno o más enlaces entre los nodos de origen y de destino, y cuando ocurre una recuperación de un límite de mensaje anterior a la recepción de un mensaje de informe de estado esperado según las realizaciones ejemplares;
La FIG. 10 ilustra el funcionamiento del protocolo de detección de pérdida de límite de mensaje para protección de pérdida de sincronismo y mensajes de estado según una realización ejemplar;
La FIG. 11 es un diagrama de flujo que ilustra una operación del nodo de destino cuando se incorpora el protocolo de pérdida de límite de mensaje según las realizaciones ejemplares; y
La FIG. 12 es un diagrama de flujo que ilustra una operación del nodo de origen cuando se incorpora el protocolo de pérdida de límite de mensaje según las realizaciones ejemplares.
Descripción detallada
El concepto inventivo se describe más plenamente en lo sucesivo con referencia a los dibujos anexos, en los que se muestran realizaciones del concepto inventivo. En los dibujos, el tamaño y los tamaños relativos de las capas, y regiones pueden estar exagerados por claridad. Números iguales se refieren a elementos iguales en todas partes. Este concepto inventivo, no obstante, se puede incorporar de muchas formas diferentes y no se debería interpretar como limitado a las realizaciones expuestas en la presente memoria. En su lugar, estas realizaciones se proporcionan de manera que esta descripción será minuciosa y completa, y trasladará completamente el alcance del concepto inventivo a los expertos en la técnica. Por lo tanto, el alcance de la invención se define por las reivindicaciones adjuntas.
Las realizaciones ejemplares del concepto inventivo general utilizan tramas de datos, que pertenecen a algún protocolo de transporte de datos, y que transportan un campo de desplazamiento que indica el número de bytes que se ha transmitido hasta el momento por la aplicación y también el número de secuencia de mensaje del mensaje al
15
25
35
45
55
E11773245
06-10-2014
que pertenece esta trama de datos. Hay una marca en la trama de datos que se fija cuando esa trama de datos particular transporta los datos finales del mensaje. La combinación del número de secuencia de mensaje y la marca de fin de de mensaje se usa para identificar el límite de un mensaje particular. Estos límites de mensaje a su vez actúan como puntos de sincronización para el receptor ya que cada mensaje corresponde a una unidad de datos que se debería procesar como una entidad única. En el caso de que ocurra una pérdida de límite de mensaje, se envía una notificación de pérdida de sincronismo al transmisor (o nodo de origen) cuya respuesta se protege por un temporizador en el receptor (o nodo de destino). La pérdida de límite de mensaje (o pérdida de sincronismo) se detecta si una trama de datos final de un mensaje se pierde y se recibe una trama de datos que pertenece a un nuevo mensaje. Además, cualquier transmisión de mensaje en curso conocida en el receptor se protege de que su límite se pierda a través de un segundo temporizador y por lo tanto es independiente del tiempo de recepción del mensaje posterior. Finalmente, la solución puede ser una parte de un protocolo de intercambio de datos en el que no es posible una fiabilidad mejorada a través de retransmisiones.
A fin de proporcionar algún contexto para la discusión de las realizaciones ejemplares, se proporciona primero alguna información acerca de protocolos UniPro y sistemas en los que se pueden usar estas realizaciones ejemplares. No obstante se entenderá por los expertos en la técnica que las realizaciones ejemplares de la presente invención incluyen, pero no se limitan a, el uso en sistemas estandarizados UniPro.
Como se muestra de manera general en la FIG. 1, una interconexión (o canal principal o interfaz) UniPro 10, por ejemplo, se puede usar para conectar grupos, (por ejemplo, pares u otros múltiplos hasta 128) de dispositivos (por ejemplo, la primera pastilla 12 (es decir, un circuito integrado, o “pastilla”)) y la segunda pastilla 14) dentro del dispositivo o sistema compuesto 16, tal como un teléfono móvil usado en un sistema de telefonía celular. Los dispositivos o primera y segunda pastillas 12 y 14 pueden incluir varios tipos de pastillas que transfieren datos sobre una interconexión, por ejemplo, pastillas en banda base, procesadores de aplicaciones, pastillas gráficas, etc. Los paquetes de datos que se trasladan sobre la interconexión o enlace 10 desde, por ejemplo, la primera pastilla 12 a la segunda pastilla 14, se pueden encaminar posteriormente a otras pastillas o módulos de destino dentro del dispositivo compuesto 16 usando un conmutador UniPro (no mostrado en la FIG. 1). La primera y segunda pastillas 12 y 14 cada una puede incluir, en esta realización ejemplar, una interfaz UniPro + M-PHY 18 y 20 (la interfaz 18, 20 también se puede conocer como una interfaz “UniPort-M” 18, 20), y la interconexión 10 se puede implementar usando un enlace simplex dual bidireccional, es decir, un enlace que tiene uno o más carriles PHY unidireccionales en ambas direcciones. Las interfaces UniPort-M 18 y 20 permiten hasta cuatro carriles por dirección, con cada carril en una única dirección que tiene las mismas capacidades de potencia y velocidad; no obstante, las dos direcciones del enlace también pueden tener diferentes capacidades. En este contexto, un “carril” se puede considerar que es un enlace punto a punto, serie que opera en una dirección de transmisión.
Entre otras cosas, las interfaces UniPort-M 18 y 20 difieren de las interfaces de interconexión existentes con respecto a, entre otras cosas, la flexibilidad que permiten en la creación y configuración de un enlace 10. Por ejemplo, las interfaces UniPort-M 18 y 20 soportan enlaces asimétricos, a diferencia de otros tipos de interfaces, tales como PCI Express, RapidIO e HyperTransport, todos de los cuales requieren que las dos direcciones del enlace sean completamente simétricas (es decir, ambas direcciones del enlace tienen el mismo número de carriles). Las interfaces UniPort-M 18, 20 también pueden permitir que solamente algunos de sus carriles estén conectados, y no hay restricciones sobre cómo se conectan los carriles, dado que los carriles se vuelven a numerar durante la puesta en marcha del enlace como se describirá más adelante. En este contexto, el término “conectado”, que se refiere a los carriles, significa conectado físicamente. Por ejemplo, supongamos que la primera pastilla 12 es una pastilla que ofrece una interfaz UniPort-M 18 con cuatro carriles, pero se usa en el sistema 16 en el que la segunda pastilla 14 está unida a la primera pastilla 12 que tiene una conectividad más limitada, por ejemplo, que tiene solamente dos carriles de recepción. Como resultado, dos de los carriles disponibles para la primera pastilla 12 se dejan intencionadamente físicamente desconectados. Los carriles también se pueden desconectar accidentalmente debido a errores físicos entre las pastillas (por ejemplo, el circuito discurre “abierto” en la placa de circuito o lámina flexible). Las interfaces UniPort-M 18 y 20 también soportan enlaces configurados asimétricamente (por ejemplo, las dos direcciones de los enlaces se pueden fijar en diferentes modos de potencia), a diferencia de otras interfaces, tales como, por ejemplo, PCI Express, RapidIO e HyperTransport, todas de las cuales requieren que las dos direcciones del enlace estén en el mismo modo de potencia.
El protocolo para detectar y comunicar una pérdida de límites de mensaje según las realizaciones ejemplares puede pertenecer, por ejemplo, a la capa 4 (capa de transporte) de la pila de protocolo de referencia ISO-OSI y cabría en los protocolos de transporte de datos tales como UniPro. La capa de transporte proporciona una interfaz a las aplicaciones, que son los clientes del protocolo de transferencia de datos, con datos extremo a extremo e intercambio de información de control junto con las garantías de servicio (QoS) necesarias.
La FIG. 2 es un diagrama de bloques de un par de nodos de origen-destino 12, 14 dentro de un dispositivo 16 que ilustra un mensaje transmitido entre los mismos y la composición de los mensajes para incluir tramas de datos según una realización ejemplar. Los mensajes 22 son unidades de datos de protocolo de la capa de aplicaciones y contienen normalmente datos de aplicaciones que se procesan como una única entidad. Los mensajes pueden ser de tamaño variable o de tamaño fijo dependiendo de la aplicación, y según las realizaciones ejemplares del concepto inventivo general, el tamaño del mensaje es inmaterial. La capa de transporte puede proporcionar un mecanismo de transporte de datos orientado a conexión o un mecanismo de transporte de datos sin conexión a la
15
25
35
45
55
E11773245
06-10-2014
aplicación. Las realizaciones ejemplares funcionan tanto para mecanismos de transporte orientados a conexión como sin conexión. Los mensajes 22 se segmentan en unidades de tamaño más pequeño (tramas de datos 24) y presentan a la capa de red en la capa de transporte del transmisor, y en la capa de transporte del receptor estos segmentos de tamaño más pequeño (tramas de datos 24) se ensamblan de nuevo en un mensaje completo. Los paquetes, que son unidades de datos de protocolo de la capa de red (Capa 3), pueden ser de tamaño variable también con un límite mínimo y máximo en los tamaños. Según las realizaciones ejemplares, el tamaño de los mensajes o paquetes (tramas de datos 24) no es material. Un primer ejemplo de una aplicación en tiempo real (por ejemplo “seguimiento”) puede generar mensajes 22 de tamaño variable compuestos de tramas de datos de tamaño variable 24, mientras que un segundo ejemplo de una aplicación en tiempo real (tal como vídeo en bruto) puede provocar mensajes 22 de tamaño fijo e incluso tramas de datos 24 de tamaño fijo. La FIG. 3 ilustra una secuencia de transmisión de mensaje ejemplar, que incluye datos y mensajes de control, de una aplicación de tiempo real, tal como vídeo en bruto.
Según realizaciones ejemplares adicionales, las tramas de datos 24, que comprenden los mensajes 22, pueden depender de capacidades de transferencia de datos fiables o no fiables de la Capa de Enlace de Datos (DLL o “Capa 2”). Las retransmisiones que implican transferencia de datos fiable impedirían el límite ajustado en la fluctuación requerida por los datos en tiempo real mientras que implicar una corrección de error sin canal de retorno rara vez funciona para errores de ráfaga. Por lo tanto los paquetes de datos en tiempo real usan las capacidades de transferencia de datos no fiables de Capa 2 y las realizaciones ejemplares del concepto inventivo general se diseñan para funcionar en un esquema de transferencia de datos poco fiable.
La FIG. 4 ilustra los campos que se pueden incluir o bien en una cabecera o bien en una cola de la trama de datos 24 transmitida por un protocolo de transmisión de datos en tiempo real según las realizaciones ejemplares. Los campos mostrados en la FIG. 4 se pueden incorporar fácilmente en una parte de cabecera (o parte de cola) de capa de transporte de cualquier paquete de protocolo de transferencia de datos con el compromiso de un ligero aumento en la sobrecarga. El campo de desplazamiento 26 es el índice absoluto que hace el seguimiento del número de bytes transmitidos desde una aplicación. La Capa 4 normalmente mantiene un contador para hacer el seguimiento de la cantidad de datos transmitidos y este contador dará la vuelta cuando alcance su valor terminal y continuará. Típicamente estos contadores incluirán 12 bits de manera que se pueden contar hasta 4 KB de datos antes de que el contador dé la vuelta. Según una realización ejemplar, se puede aumentar o disminuir el número de bits dependiendo del formato de paquete del protocolo de transferencia de datos y también de los requisitos de las aplicaciones que son los clientes del protocolo de transferencia de datos. Por lo tanto el tamaño del campo de desplazamiento 26 mostrado en la FIG. 4 es solamente ilustrativo y no restrictivo.
El campo de número de secuencia de mensaje (msg. seq. #) 28 únicamente identifica el mensaje al cual pertenece la trama de datos 24. El número de secuencia se aumenta en cada límite de mensaje. Según una realización ejemplar, el número de secuencia de mensaje puede ser de 3 bits, de manera que se pueden identificar hasta 8 mensajes diferentes. Generalmente, ser capaz de diferenciar entre 8 mensajes es suficiente para la mayoría de las aplicaciones. Como con el tamaño del campo de desplazamiento, el tamaño del campo msg. seq. # 28 es ilustrativo y no restrictivo.
La marca de fin de mensaje (EoM) 30 se usa para indicar la última trama de datos 24 en un mensaje 22. Según una realización ejemplar, la marca de EoM 30 se fija (normalmente fija a un valor lógico de “1”) en la última trama de datos 24 en un mensaje 22, y se reinicia (fija a un valor lógico “0”) para todas las otras tramas de datos 24 en el mensaje 22.
Además de los campos tratados con respecto a la FIG. 4, según las realizaciones ejemplares, hay dos temporizadores usados en un nodo de destino 14. Hay una posibilidad de que una notificación de pérdida de sincronismo y/o su respuesta pudiera estar dañada por errores. El primero, o temporizador principal 32, se usa para proteger este escenario. El valor de expiración del temporizador principal 32 se fija a al menos el retardo de ida y vuelta de una trama de datos que transporta el mensaje de notificación y su respuesta. Según realizaciones ejemplares adicionales, también es posible que las tramas de datos 24 del mensaje 22 se pudieran perder debido a errores. Si la transmisión de las tramas de datos 24 de un primer mensaje conocido 22a se conocía en el receptor (a través de la trama de datos 24 que transporta un número de secuencia de mensaje 28), entonces el límite de mensaje del mensaje 22a necesita ser protegido. Según una realización ejemplar, un segundo temporizador o auxiliar (aux.) 34 protege el límite de mensaje de llegar a ser perdido ayudando a identificar huecos más largos de lo normal en la llegada de datos, que podrían ser debidos a un error de enlace que causa una pérdida de datos que puede conducir a huecos o pausas temporales en la transmisión de datos desde el transmisor. El valor de expiración del temporizador aux. 34 es programable y negociado antes de que la transmisión de datos comience en base a las características de transmisión de datos (por ejemplo periódica, aperiódica etc.) de la aplicación. Según una realización ejemplar del concepto inventivo general, los temporizadores principal y aux. 32, 34 funcionan mutuamente exclusivamente. Es decir, nunca se ejecutan al mismo tiempo. Por lo tanto, en una implementación se pueden combinar en un único temporizador con diferentes valores de reinicio. Los temporizadores principal y aux. 32, 34 se muestran como realizaciones independientes en las figuras a fin de mejorar la claridad en la presentación del concepto inventivo y por lo tanto no se restringen de ser combinados. Una discusión detallada del funcionamiento de los temporizadores principal y aux. 32, 34 se presenta más adelante con la ayuda de los diagramas de secuencia de mensaje (FIG. 7-10). No obstante, anterior a discutir los diagramas de secuencia de
10
15
20
25
30
35
40
45
50
55
60
E11773245
06-10-2014
mensaje en las FIG. 7-10, los mensajes 24 usados por el protocolo ejemplar para comunicar entre los nodos de origen y de destino 12, 14, se presentan primero en las FIG. 5 y 6.
La FIG. 5 representa un mensaje de Consulta de Estado/Pérdida de Sincronismo 36 enviado por el nodo de origen 12 al nodo de destino 14 según una realización ejemplar. El mensaje 36 mostrado en la FIG. 5 se llama mensaje de pérdida de sincronismo 36a cuando se fija la marca de “Pérdida de Sincronismo” (SL), y cuando no se fija la marca de pérdida de sincronismo, entonces el mensaje 36 se puede conocer como el mensaje de consulta de estado 36b. Los campos restantes en el mensaje 36 son el último número de secuencia de mensaje 28 recibido transportado en la última trama de datos 24 recibida correctamente y el valor de desplazamiento 26 correspondiente.
Siempre que el nodo de origen 12 recibe un mensaje de consulta de estado 36a, o un mensaje de pérdida de sincronismo 36b desde el nodo de destino 14, el nodo de origen 12 responde con el mensaje de informe de estado 38, mostrado en la FIG. 6. El mensaje de informe de estado 38 transporta el número de secuencia de mensaje del mensaje previo y su correspondiente desplazamiento final además del número de secuencia de mensaje actual y su valor de desplazamiento. Para el mensaje actual, se añade una marca de EoM 30 para distinguir si la transmisión de datos para este mensaje está en curso o también ha finalizado. Los valores de desplazamiento (es decir, el número total de bytes transmitidos por la aplicación) del mensaje previo y actual se mantienen en el transmisor (Origen de Datos). Según una realización ejemplar, es posible eliminar uno de los números de secuencia de mensaje. Si se conoce el valor del número de secuencia de mensaje previo, entonces el número de secuencia de mensaje actual en el nodo de destino 14 se puede calcular muy fácilmente, y si se conoce el número de secuencia de mensaje actual, entonces se puede determinar fácilmente el número de secuencia de mensaje previo. Todos de tales medios alternativos de determinación o conocimiento de los números de secuencia de mensaje están dentro de las realizaciones ejemplares del concepto inventivo general. En la FIG. 6 se muestran tanto los números de secuencia de mensaje actual como previo a fin de transmitir explícitamente el concepto, pero se entiende que éste no es restrictivo con respecto a las diversas realizaciones ejemplares. Según realizaciones ejemplares adicionales, el número de bits usado para representar el valor de desplazamiento y el número de secuencia de mensaje debería ser el mismo que aquél usado para una cabecera de Capa 4 como se muestra en la FIG. 4. Según una realización ejemplar adicional, el campo de número de secuencia de mensaje previo, en la FIG. 6 fijado a 3 bits, puede representar al menos el número de secuencia de mensaje previo inmediato, o un conjunto de mensajes previos. Por ejemplo, en el primer caso, si el número de mensaje actual es 8, el número de mensaje previo debería ser 7. El valor de desplazamiento del mensaje actual indicará la cantidad de datos en el mensaje actual, y el valor de desplazamiento del mensaje previo indicará la cantidad de datos transmitidos en el mensaje 7. No obstante, si está en el último caso, el número de mensaje previo indicaba un conjunto de los mensajes transmitidos previamente, por ejemplo, tres, entonces el mensaje actual es 8, y el valor de desplazamiento del mensaje actual indicará la cantidad de datos en el mensaje actual, pero el valor de desplazamiento del mensaje previo indicará la cantidad de datos en los mensajes 7, 6, y 5, el conjunto de los tres últimos mensajes. En este caso, el mensaje de informe de estado 38 puede mostrar una cantidad contigua de datos transmitidos, sin tener en cuenta los límites de mensaje.
La FIG. 7 ilustra el funcionamiento del protocolo de detección de límite de mensaje cuando no hay errores en ningún enlace según las realizaciones ejemplares. El sistema representado consta del nodo de origen 12 que envía datos en tiempo real al nodo de destino 14 a través de tres nodos intermedios 40a, b, c. El protocolo de detección de límite de mensaje funciona para cualquier número de nodos intermedios 40 incluyendo cero nodos intermedios según las realizaciones ejemplares. La probabilidad de pérdidas de datos aumenta con el aumento del número de enlaces de datos (entre los nodos) ya que cada uno de ellos es propenso a errores. Dado que el protocolo de detección de límite de mensaje pertenece a la capa de transporte, las capas por debajo no se muestran en los diagramas de mensaje por el propósito doble de claridad y brevedad. Los temporizadores principal y aux. 32, 34 se sitúan en el nodo de destino 14, que es la capa de transporte del nodo de destino. Aunque no se muestra explícitamente en los diagramas de mensaje, hay máquinas de estado, que implementan el protocolo, en el nodo de origen 12 y el nodo de destino 14. Los diagramas de flujo que pertenecen al funcionamiento de estas máquinas de estado se tratan en mayor detalle más adelante. Como pueden apreciar los expertos en la técnica, las máquinas de estado pueden incluir ordenadores, procesadores, ASIC, FPGA, entre otros tipos de dispositivos, y se explicarán en mayor detalle más adelante.
Según una realización ejemplar, la aplicación dentro del dispositivo 16 se permite que proporcione datos como mensajes de tamaño arbitrario a la capa de transporte del nodo de origen 12 que divide el mensaje en segmentos de tamaño manejable. Los segmentos son Unidades de Datos de Protocolo (PDU) de la capa de transporte. Los segmentos se encapsulan con las cabeceras y/o colas necesarias para crear paquetes por la capa de red. Los paquetes, después de la encapsulación con las cabeceras y/o colas de la Capa 2, se transmiten como tramas de datos 24 por la capa de enlace de datos usando los servicios de la capa física en la pila de protocolo. La FIG. 7 no muestra las capas de red, enlace de datos y física, sino que las tramas de datos 24 individuales que pertenecen al mismo mensaje 22 se muestran pasando los enlaces de datos físicos entre los nodos 40. Cada una de esas tramas de datos 24 transporta el campo de secuencia de mensaje 28, que contiene la secuencia de mensaje (msg. seq.) #. Por ejemplo, el primer mensaje que se transmite desde el origen 12 se divide en tres tramas de datos 24 y cada una transporta el msg. seq. #1. Cuando los últimos datos de un mensaje 22 se traspasan por la aplicación a la capa de transporte, indica esto a través de alguna señalización. Según las realizaciones ejemplares, la señalización se representa por una marca de EoM 30. La capa de transporte inserta una marca de EoM 30 en la trama de datos 24 que contiene el último segmento de datos en el mensaje 22. En la FIG. 7 esto se indica en la trama de datos 24 con
10
15
20
25
30
35
40
45
50
55
60
E11773245
06-10-2014
el “EoM” junto con el msg. seq. #1.
Las tramas de datos 24 se reenvían por los nodos intermedios 40a, b, c, que pueden ser conmutadores o concentradores, al nodo de destino correcto 14 a través de un protocolo de encaminamiento. Según una realización ejemplar del concepto inventivo general, se puede usar cualquier protocolo de encaminamiento particular. Los nodos intermedios 40a, b, c no hacen ninguna modificación a los campos insertados por la capa de transporte ya que estos nodos 40a, b, c implementan solamente capas desde la capa física a la capa de red.
El nodo de destino 14, al detectar una trama de datos 24 que pertenece a un nuevo mensaje 22, inicia un temporizador aux. 34. El valor de expiración del temporizador aux. 34 se fija de manera que cubre el retardo del caso peor al recibir una trama de datos 24 posterior (que sigue a la transmisión de la trama de datos 24 previa) que pertenece al mismo mensaje 22. Según una realización ejemplar, el valor de expiración del temporizador aux. 34 se fija a tal valor debido a que las tramas de datos 24 se podrían perder debido a errores, y si la trama de datos 24 que se pierde transportaba la marca de EoM 30, entonces la información de la marca de EoM 30 también se perdería. El temporizador aux. 34 se reinicia cada vez que se recibe una trama de datos 24. Por ejemplo, con referencia a la FIG. 7, en el tiempo t1, el temporizador aux. 34 se inicia cuando la trama de datos 24a se recibe en el destino 14. El temporizador aux. 34 procede a contar mientras que la trama de datos 24b se transmite en el tiempo t2. Señalar que no hay una relación fija entre los tiempos t1 y t2. El temporizador aux. 34 detiene la cuenta cuando se recibe la trama de datos 24b. El temporizador aux. 34 no alcanzó su tiempo máximo, de cuenta, el “valor de expiración”, debido a que el retardo desde el tiempo t2 al tiempo t3 fue menor que el tiempo de expiración. De manera similar, el temporizador aux. 34 reinicia la cuenta cuando se recibe la trama de datos 24b, y de nuevo no alcanza su tiempo de expiración cuando se recibe la trama de datos 24c. No obstante, el temporizador aux. 34 se detiene y no se reinicia debido a que la trama de datos 24c contiene una marca de EoM 30, ya que es la trama de datos 24 fin del mensaje
22. Cuando se recibe una marca de EoM 30, en el tiempo t4, el protocolo de detección de límite de mensaje indica a la aplicación que se detecta el límite de mensaje. El temporizador aux. 34 entonces se reinicia e inicia de nuevo en la detección de un nuevo mensaje 22 con un número de secuencia de mensaje 28 aumentado. Cada vez que se reciben las tramas de datos 24 por la capa de transporte, los datos se pasan sobre la capa de aplicaciones.
Como se muestra en la FIG. 7, los mensajes 1 y 2 se reciben completamente y con éxito por el nodo de destino 14. En el tiempo t5, no obstante, se recibe una primera trama de datos 24 para el mensaje #3 y el temporizador aux. 34 comienza a contar. Pero en el tiempo t6 ocurre que no ha llegado ninguna otra trama de datos 24, y por lo tanto expira el temporizador aux. 34. Una vez que el temporizador aux. 34 expira, el nodo de destino 14 envía un mensaje de consulta de estado 36a al nodo de origen 12. El mensaje de consulta de estado 36a contiene el “Último Número de Secuencia de Mensaje Recibido” y los valores de “desplazamiento de datos” (ver la FIG. 5) que indican el estado de recepción de datos en el nodo de destino 14. Después de que el nodo de origen 12 recibe un mensaje de consulta de estado 36a en el tiempo t7 desde el nodo de destino 14, envía el mensaje de informe de estado 38 de vuelta al nodo de destino 14. El mensaje de informe de estado 38 contiene al menos el desplazamiento final del mensaje previo con el número de secuencia de mensaje correspondiente y el último desplazamiento de datos del mensaje actual. También puede transportar una marca de EoM 30 si ha terminado el mensaje actual. Esta información se mantiene en la memoria de estado del nodo de origen 12 y se actualiza con cada transmisión de datos. Existe una posibilidad de que el desplazamiento de datos transportado por el mensaje de consulta de estado 36a para el mensaje actual sea diferente del último desplazamiento de datos en el nodo de origen 12 debido al hecho de que el nodo de origen 12 podría haber enviado más datos después de que el mensaje de consulta de estado 36a se inició por el nodo de destino 14.
Con referencia de nuevo a la FIG. 7, y las transmisiones entre los tiempos t5 hasta t8, se puede ver que ocurre una toma de contacto según las realizaciones ejemplares entre el nodo de destino 14 y el nodo de origen 12. Además, se puede ver que el mensaje de consulta de estado 36a transporta el número de mensaje “3” como el mensaje actual. El valor de desplazamiento 26 no se muestra en el mensaje de consulta de estado 36a aunque está contenido en él. En respuesta, el nodo de origen 12 envía el mensaje de informe de estado 38 que se compone del número de mensaje previo como mensaje #2 y su desplazamiento de datos final (el desplazamiento no se muestra en la FIG. 7) y el mensaje actual como mensaje #3. La marca de EoM 30 no fijada (EoM=´0`como mensaje #3 no está terminado aún) y su desplazamiento (el desplazamiento no se muestra en la FIG. 7; no obstante, ver la FIG. 6 para una ilustración del mensaje de informe de estado 38). En el ejemplo mostrado en la FIG. 7, el desplazamiento de datos actual del mensaje #3 en el mensaje de informe de estado 38 es el mismo que en el mensaje de consulta de estado 36a ya que no ocurrió ninguna transmisión de datos después de que fue creado el mensaje de consulta de estado 36a en el nodo de destino 14. Según las realizaciones ejemplares, el valor de desplazamiento de datos es contiguo y es agnóstico de los límites del mensaje. Es decir, el valor de desplazamiento de datos continúa aumentando sin tener en cuenta los límites de mensaje, ya que no se define como bytes por mensaje, sino bytes enviados por la aplicación. Por tanto, continúa aumentando, incluso a través de los límites de mensaje, hasta que alcanza su valor terminal, y entonces comienza de nuevo. Además, los datos contenidos en las tramas de datos 24 se aceptan mientras que el nodo de destino 14 está esperando respuesta a su mensaje de consulta de estado 36a. Tras la recepción del mensaje de informe de estado 38, el nodo de destino 14 se da cuenta de que está todavía en el medio del mensaje #3 (ya que EoM=´0`) y reinicia el temporizador aux. 34. El temporizador aux. 34 se detiene cuando se recibe la siguiente trama de datos que transporta la marca de EoM 30. Según las realizaciones ejemplares, el desplazamiento de datos se pasa a la aplicación cada vez que el mensaje de informe de estado 38 se recibe por el nodo de destino 14. Aunque el temporizador principal 32 se muestra en la FIG. 7, su efecto en la operación del
10
15
20
25
30
35
40
45
50
55
60
E11773245
06-10-2014
protocolo de detección de pérdida de límite de mensaje, no se ha tratado ya que no se introdujeron errores en el escenario mostrado en la FIG. 7.
La FIG. 8 ilustra el funcionamiento del protocolo de detección de pérdida de límite de mensaje cuando hay errores en uno o más de los enlaces entre los nodos de origen y destino según las realizaciones ejemplares. Estos errores pueden hacer que lleguen a perderse datos, y si los límites de mensaje se pierden, esto conduciría a una pérdida de sincronización. Si el error daña los datos dentro de un mensaje pero no afecta a los límites de mensaje, entonces el nodo de destino 14 no envía un mensaje de pérdida de sincronización (pérdida de sincronismo) 36b al nodo de origen 12; este es el escenario que se mostró y trató en referencia a la FIG. 7, y mensaje #3. Como se trató anteriormente, el temporizados aux. 34 se inicia desde el reinicio cuando se detecta la primera trama de datos 24 del mensaje #1. La pérdida de tramas de datos intermedias, en caso de que ocurra, no se detecta en el nodo de destino 14 hasta que se recibe la última trama de datos que pertenece a un mensaje (con una marca de EoM 30 fijada, para mostrar el fin de mensaje). Dado que la capa de transporte del nodo de destino pasa el desplazamiento de datos a la capa de aplicaciones siempre que se recibe la trama de datos 24 o el mensaje de informe de estado 38, la aplicación puede saber aproximadamente la cantidad de datos que se perdieron, comparando los valores de desplazamiento. Cuando se recibe la trama de datos 24 con una marca de EoM 30 fijada para el mensaje #1, la capa de transporte indica a la aplicación el límite de mensaje y también el desplazamiento de datos recibido. Dado que no se perdió el límite de mensaje para el mensaje #1, la aplicación puede calcular la cantidad de datos perdidos a partir de los valores de desplazamiento proporcionados. Según una realización ejemplar adicional, los datos perdidos, especialmente en relación a los datos de video perdidos, se pueden compensar bastante a través del uso de algoritmos de interpolación de datos de video. Tanto el uso de, como el funcionamiento de, los algoritmos de interpolación de datos de video está más allá del alcance de esta discusión, y no es necesario a fin de entender las realizaciones ejemplares descritas en la presente memoria, y por tanto se ha omitido una discusión detallada de los mismos por propósitos de claridad y brevedad.
No obstante, si los errores causan la pérdida de la trama de datos 24 que transporta una marca de EoM 30, entonces se detecta la pérdida de límite de mensaje a partir de la trama de datos 24 de un nuevo mensaje. Esto conduce a una pérdida de sincronización y el nodo de destino 14 transmite un mensaje de pérdida de sincronismo 36b al nodo de origen 12 con el último número de secuencia de mensaje recibido correctamente y el valor de desplazamiento de datos después de iniciar el temporizador principal 32. Cuando el origen 12 detecta el mensaje de pérdida de sincronismo 36b, envía un mensaje de informe de estado 38 similar al enviado cuando se recibe un mensaje de consulta de estado 36a. El nodo de origen 12 también puede señalar opcionalmente a la aplicación que se ejecuta en nodo de origen 12 que ha ocurrido una pérdida de sincronismo en el nodo de destino 14. Con referencia ahora a la FIG. 8, el mensaje #2 pierde la trama de datos 24 que transporta una marca de EoM 30 en el tiempo t0 (la “X” en la figura significa que el mensaje no se recibió adecuadamente), además de una o más tramas de datos 24 intermedias (para el mensaje #2). La primera trama de datos 24 del siguiente mensaje (mensaje #3) también se pierde. El nodo de destino 14, al recibir la segunda trama de datos 24 del mensaje #3 en el tiempo t1 detecta una pérdida de límite de mensaje (es decir, la falta de la marca de EoM 30 para el mensaje #2). El nodo de destino 14 entonces realiza varias acciones según las realizaciones ejemplares del concepto inventivo general. En el tiempo t1 el nodo de destino 14 transmite el mensaje de pérdida de sincronismo 36b al origen 12 indicando que el nodo de destino 14 perdió el final del mensaje #2. El nodo de origen 12, tras la recepción del mensaje de pérdida de sincronismo 36b en el tiempo t2, envía un mensaje de informe de estado 38 actual que contiene el desplazamiento de datos de fin de mensaje para el mensaje #2 (debido a que el mensaje #2 es el mensaje previo). En una realización alternativa, el mensaje 38 puede contener desplazamientos de datos de fin de mensaje para los N últimos mensajes transmitidos, donde N es una constante mayor que 1. El mensaje de informe de estado 38, enviado en el tiempo t2, indica el mensaje actual como mensaje #3 y proporciona el valor de desplazamiento 26 de los datos transmitidos hasta el momento. Según las realizaciones ejemplares del concepto inventivo general, el nodo de destino 14 vuelve a sincronización debido a que determina que no ha recibido el final del límite de mensaje y, usando los valores de desplazamiento en el mensaje de informe de estado 38, determina dónde debería haber estado el final del mensaje previo, y entonces determina desde allí cuándo debería haber iniciado el nuevo mensaje, y organiza sus datos adecuadamente. El nodo de destino 14 puede volver a la sincronización tras recibir de manera fiable el mensaje de informe de estado 38. Tras recuperar la sincronización, el temporizador aux. 34 se inicia desde el reinicio ya que la transmisión del mensaje #3 está en curso y el nodo de destino 14 necesita monitorizar los mensajes de datos recibidos para cuidar la situación en la que se pierde el límite de mensaje del mensaje #3. En caso de que no haya ningún mensaje en curso, lo que significa que el mensaje actual tiene una marca de EoM 30 fijada en el mensaje de informe de estado 38 después de recuperar la sincronización, entonces se detiene el temporizador aux. 34.
Según una realización ejemplar adicional, se puede determinar una pérdida de sincronización al menos de otra manera. Una situación de pérdida de límite de mensaje en un mensaje previo se puede determinar además si se recibe una nueva trama de datos 24 y la diferencia en los números de secuencia de mensaje entre la nueva trama de datos y la trama de datos previa es al menos dos o más sin tener en cuenta si la última trama de datos recibida tiene su marca de EoM fijada o no, por ejemplo, cuando se ha perdido un mensaje entero digno de tramas de datos. En este escenario, el nodo de destino 14 enviará un mensaje de pérdida de sincronización 36b, e intentará recuperar la sincronización como se trató anteriormente.
La atención se dirige a la FIG. 9. La FIG. 9 ilustra el funcionamiento del protocolo de detección de pérdida de límite
15
25
35
45
55
E11773245
06-10-2014
de mensaje cuando hay errores en uno o más enlaces entre los nodos de origen y destino 12, 14, y cuando la recuperación de un límite de mensaje ocurre anterior a la recepción de un mensaje de informe de estado esperado según las realizaciones ejemplares. En el tiempo t0, el nodo de destino 14 deja de recibir el mensaje #2 de trama de datos 24 con la marca de EoM 30 fijada, lo que significa que el nodo de destino 14 deja de reconocer el límite de mensaje del mensaje #2. Como se trató anteriormente, cuando el nodo de destino 14 reconoce, en el tiempo t1, que no ha recibido el indicador de límite de mensaje, el nodo de destino 14 enviará un mensaje de pérdida de sincronismo 36b, que lo hace. Según realizaciones ejemplares adicionales, existe la posibilidad de que mientras el nodo de destino 14 está esperando la respuesta a su mensaje de pérdida de sincronismo 36b enviado en el tiempo t1 (es decir, la respuesta esperada que es el mensaje de informe de estado 38), el nodo de destino 14 recibirá el límite de mensaje del mensaje en curso. En el tiempo t2, el nodo de destino 14 recibe, para el mensaje #3, la trama de datos 24 con la marca de EoM 30 fijada, que es anterior a la recepción del mensaje de informe de estado 38 para el mensaje #2 en el tiempo t4. La recepción de la trama de datos 24 con la marca de EoM 30 fijada permite al nodo de destino 14 recuperar la sincronización anterior a la recepción del mensaje de informe de estado 38 que se protege por el temporizador principal 32. Una vez que se recupera la sincronización por el nodo de destino 14, el nodo de destino 14 detiene el temporizador principal 32. El temporizador aux. 34 se reinicia cuando se recibe una trama de datos que pertenece al siguiente número de secuencia de mensaje.
En la FIG. 9, la trama de datos 24 que transporta la marca de EoM 30 para el mensaje #3 ayuda al receptor a entrar en sincronización en el tiempo t2. La capa de transporte indica a la aplicación que la sincronización se recupera además de indicar el límite de mensaje y desplazamiento de datos. El temporizador aux. 34 se reinicia en la recepción de la trama de datos 24 que pertenece al mensaje #4. Finalmente, se ignora el mensaje de informe de estado 38 (recibido en el tiempo t4) ya que sus contenidos ya se conocen en el nodo de destino 14. Opcionalmente, el valor de desplazamiento del mensaje previo se puede pasar a la aplicación para permitir el cálculo de tamaño del mensaje.
La FIG. 10 ilustra el funcionamiento del protocolo de detección de pérdida de límite de mensaje para la protección de pérdida de sincronismo y mensajes de estado según una realización ejemplar. En la FIG. 9, se trató cómo el temporizador principal 32 proporcionó protección para la situación en que se recibió una indicación de fin de mensaje para un mensaje posterior, después de que se hizo una notificación de pérdida de sincronismo para un mensaje previo. El temporizador principal 32 también protege la pérdida de mensaje de consulta de estado 36a de una manera similar. El temporizador principal 32 se inicia cuando se envía o bien el mensaje de pérdida de sincronismo 36b o bien el mensaje de consulta de estado 36a por el nodo de destino 14. En la FIG.10, el mensaje de pérdida de sincronismo 36b se transmite por el nodo de origen 12 en el tiempo t0, pero este mensaje de pérdida de sincronismo 36b se pierde entre los nodos intermedios 40b y 40a. Dado que no se recibe ningún mensaje de informe de estado 38 dentro de la expiración del temporizador principal 32, el primer mensaje de pérdida de sincronismo 36b se considera perdido, y se reenvía otro mensaje de pérdida de sincronismo 36b en el tiempo t1. En un segundo escenario, después de que se envía un segundo mensaje de pérdida de sincronismo 36b por el nodo de destino 14, mensaje de informe de estado 38, transmitido por el nodo de origen 12 en el tiempo t2, no se recibe antes de que el temporizador principal 32 expire (t3). Ahora el nodo de destino 14 reenvía un mensaje de pérdida de sincronismo 36b en el tiempo t3, y se reinicia el temporizador principal 32. En este caso, no obstante, el nodo de origen 12 recibe un mensaje de pérdida de sincronismo 36a (en el tiempo t4), y el nodo de origen 12 transmite un mensaje de informe de estado 38. En resumen, según las realizaciones ejemplares adicionales, se envía un mensaje de pérdida de sincronismo o mensaje de consulta de estado 36a, b hasta que se reconocen cualquiera de los dos o ambos con los mensajes de informe de estado 38 y el temporizador principal 32 hace el seguimiento temporal de esta toma de contacto.
Las FIG. 11 y 12 son diagramas de flujo que ilustran la operación del nodo de destino 14 y del nodo de origen 12 cuando se incorpora el protocolo de pérdida de límite de mensaje según las realizaciones ejemplares del concepto inventivo general. Según realizaciones ejemplares adicionales, aunque el temporizador principal 32 y el temporizador aux. 34 se muestran y tratan como que son elementos separados, su funcionalidad se puede combinar en un único temporizador ya que su funcionamiento es mutuamente exclusivo, lo que significa que el temporizador aux. 34 y temporizador principal 32 no operan al mismo tiempo.
La FIG. 11 representa un diagrama de flujo de un método 1100 que controla la operación del nodo de destino 14 cuando se incorpora el protocolo de pérdida de límite de mensaje según una realización ejemplar del concepto inventivo general. La máquina de estado del nodo de destino 14 tiene cuatro estados – (1) estado inactivo, (2) estado de trama de datos/mensaje de estado recibido, (3) estado de temporizador auxiliar y (4) estado de temporizador principal. Como pueden apreciar los expertos en la técnica, la implementación particular de los estados es una realización representativa, y se pueden formar diferentes estados para satisfacer la funcionalidad del protocolo de pérdida de límite de mensaje según realizaciones ejemplares adicionales. Es decir, pueden existir otras implementaciones posibles y están dentro de las realizaciones ejemplares del concepto inventivo general.
El nodo de destino 14 está en su estado inactivo (1) en el paso S10. Típicamente este es el estado de operación normal del nodo de origen y destino 12, 14 cuando no están ocurriendo transmisiones. El nodo de destino 14 sale del estado inactivo (paso 10) tan pronto como se recibe una primera trama de datos 24, como se muestra en el paso de decisión S20, para entrar en el estado de trama de datos/mensaje estado (2) en el paso S30, en cuyo momento el nodo de destino 14 procesa la información en la trama de datos 24 recibida. Mientras que está en el estado de
15
25
35
45
55
E11773245
06-10-2014
trama de datos/mensaje de estado (2) después de extraer e indicar el valor de desplazamiento 26 a la aplicación (S40), se hace una determinación en el paso de decisión S50 para determinar si el número de secuencia de mensaje 28 recibido es igual que el que se espera. Esto se hace para determinar si se puede determinar una pérdida de límite de mensaje a partir del cambio en el número de secuencia de mensaje 28. Si el número de secuencia de mensaje 28 recién obtenido no es el que se espera (camino “No” del paso de decisión S50), entonces el método 1100 pasa a indicar una pérdida de sincronismo a la aplicación en el paso S160, fija la marca de pérdida de sincronismo en el paso S170 de manera que el nodo de destino 14 se da cuenta de que tiene que enviar un mensaje de pérdida de sincronismo 36b mientras que el nodo de destino 14 está en el estado de temporizador principal (4) y entonces entra en el estado de temporizador principal (4) en el paso S180 para enviar físicamente el mensaje de pérdida de sincronismo 36b. Si, no obstante, el número de secuencia de mensaje actual es el esperado (camino “Si” del paso de decisión S50), entonces se realiza una comprobación en el paso de decisión S60 para determinar si la trama de datos 24 transportaba un marcador de EoM 30 que indica un límite de mensaje. Si se recibe la marca de EoM 30 (camino “Si” del paso de decisión S60), entonces el número de secuencia esperado se aumenta (S70) y se da una indicación de fin de mensaje y una información de tamaño de mensaje a la aplicación en el paso S80. El nodo de destino 14 entonces vuelve al estado inactivo (1) en el paso S10 para esperar tramas de datos 24 adicionales que pertenecen a un nuevo mensaje. En el caso que la trama de datos 24 no transporte un marcador de EoM 30 (camino “No” del paso de decisión S60), entonces es posible que se pudieran recibir tramas de datos 24 adicionales en el mensaje. Por lo tanto, el temporizador aux. 34 tiene que ser iniciado para proteger el caso de que no se pierda una trama de datos 24 que transporta un marcador de EoM 30. El nodo de destino 14 entra en el estado de temporizador auxiliar (3) en el paso S90 para proteger contra la aparición de un marcador de EoM 30 perdido. En el estado de temporizador auxiliar (3), el temporizador aux. 34 se reinicia en el paso S100. Entonces, se hace una determinación para ver si cualquier trama de datos 24 adicional se ha recibido en el paso de decisión S110. Si se recibe una trama de datos 24 (camino “Si” del paso de decisión S110), entonces el nodo de destino 14 detiene el temporizador aux. 34 en el paso S120, y vuelve al estado de trama de datos/mensaje de estado (2) en el paso S30. Si no se recibe ninguna trama de datos 24 (camino “No” del paso de decisión S110), entonces el temporizador aux. 34 se aumenta (S130) y entonces se hace una determinación en cuanto a si el temporizador aux. 34 ha alcanzado su valor de expiración en el paso de decisión S140. Si el temporizador aux. 34 no ha alcanzado su valor de expiración (camino “No” del paso de decisión S140), entonces el nodo de destino 14 vuelve a comprobar si se recibe la trama de datos 24 en el paso de decisión S110 y el método 1100 repite los pasos de determinación si se ha recibido la trama de datos 24, aumentando el temporizador aux. 34, y determinando si ha expirado el temporizador aux. 34. En el caso cuando el temporizador aux. 34 expira (camino “Si” del paso de decisión S140), entonces no se ha recibido ninguna trama de datos 24 en el intervalo de tiempo entre tramas de datos 24 esperado y el mensaje de consulta de estado 38 tiene que ser enviado al nodo de origen 12. El nodo de destino 14 detiene el temporizador aux. 34 (S150) y entra en el estado de temporizador principal (4) en el paso S180 para enviar el mensaje de consulta de estado 36a. El método 1100 entonces pasa al paso S180.
Después de entrar en el estado de temporizador principal (4) en el paso S180, el nodo de destino 14 primero reinicia el temporizador principal 32 en el paso S190, entonces se hace una determinación en cuanto a si el nodo de destino 14 ha entrado en el estado de temporizador principal (4) para proteger contra una pérdida de o bien mensaje de pérdida de sincronismo 36b o bien mensaje de consulta de estado 36a (la situación que se ha tratado anteriormente con respecto a la FIG. 10). El nodo de destino 14, en el método 1100, determina si y qué tipo de mensaje se ha perdido mirando el estado de la marca de pérdida de sincronismo (SL) en el paso de decisión S200. En el caso de que el nodo de destino 14 entre en el estado de temporizador principal (4) para la recuperación o protección contra una pérdida de mensaje de consulta de estado 36a (camino “No” del paso de decisión S200, es decir, no se ha perdido el mensaje de pérdida de sincronismo 36b), la marca de SL se reiniciará y el nodo de destino 14 envía un mensaje de consulta de estado 36a en el paso S210. Entonces, el nodo de destino 14 busca la recepción del mensaje de informe de estado 38 desde el nodo de origen 12 en el paso S220. Si el mensaje de informe de estado 38 no se ha recibido (camino “No” del paso de decisión S220), entonces el nodo de destino 14 determina si se ha recibido una trama de datos 24 en el paso de decisión S230. Si se ha recibido una trama de datos 24, entonces el nodo de destino 14 abandona el estado de temporizador principal (4), detiene el temporizador principal 32 en el paso S270, y vuelve al estado de trama de datos/Rx de Msg. de estado (2). También, si se ha recibido el mensaje de informe de estado 38 (camino “Si” del paso de decisión S220), entonces el nodo de destino 14 abandona el estado de temporizador principal (4), detiene el temporizador principal 32 en el paso S270, y vuelve al estado de trama de datos/Rx de Msg. de estado (2) donde se realiza un procesamiento adicional como se describió anteriormente. Anterior a abandonar el estado de temporizador principal (4) que sigue al paso de decisión S220, cuando se ha recibido el mensaje de informe de estado 38, el método 1100 actualiza el número de secuencia de mensaje esperado al número de secuencia de mensaje actual contenido en el mensaje de informe de estado 38 en el paso S260. En la situación en la que tanto el mensaje de informe de estado 38 no se ha recibido, como la trama de datos 24 tampoco se ha recibido, (camino “No” de ambos pasos de decisión S220 y S230), entonces el temporizador principal 32 se aumenta (S240) y en el paso de decisión S250 se hace una determinación en cuanto a si ha expirado
o no el temporizador principal 32. Si no ha expirado el temporizador principal 32 (camino “No” del paso de decisión S250), entonces el método 1100 vuelve al paso de decisión S220. Si el temporizador principal 32 expira sin satisfacer ninguna de las condiciones determinadas en los pasos de decisión S220 y S230, entonces se reinicia de nuevo el temporizador principal 32 en el paso S190, y se repite el paso de decisión 200 para comprobar el estado de la marca de SL.
15
25
35
45
55
E11773245
06-10-2014
Volviendo a la decisión S50, es posible que la trama de datos 24 que se recibe tenga una secuencia de mensaje # que es diferente de la secuencia de mensaje # esperada (camino “No” del paso de decisión S50). Si ese es el caso, entonces ocurre una pérdida de sincronización y el nodo de destino 14 necesita enviar el mensaje de pérdida de sincronismo 36b al nodo de origen 12. El nodo de destino 14 indica una pérdida de sincronismo a la aplicación en el nodo de destino en el paso S160, y fija la marca de pérdida de sincronismo (SL) en el paso S170, y entra en el estado de temporización principal (4) en el paso S180. En el paso S190, se reinicia el temporizador principal 32, y entonces se hace una comprobación para verificar que la marca de SL se fija en el paso de decisión S200. Como se trató anteriormente, necesita ser hecha una determinación en cuanto a si el método 1100 y el nodo de destino 14 necesitan protegerse contra una pérdida de mensaje de consulta de estado 36a o mensaje de pérdida de sincronismo 36b. En este caso, dado que es el mensaje de pérdida de sincronismo 36b el que se ha perdido (ver, decisión del paso de decisión S50), se encuentra que está fijada la marca de SL. Por lo tanto, el nodo de destino 14 envía el mensaje de pérdida de sincronismo 36a al nodo de origen 12 en el paso S280. Después del paso S280, el nodo de destino 14 verifica si se ha recibido un mensaje de informe de estado 38 en el paso de decisión S290. Si no se recibió ningún mensaje de informe de estado 38, entonces el nodo de destino 14 busca una trama de datos con una marca de EoM fijada (S300), lo cual es otra alternativa para entrar en sincronización. Si no se han recibido tales tramas de datos 24, entonces el temporizador principal 32 se aumenta (S310) y se hace una comprobación para determinar si ha expirado (S320) el temporizador principal 32. Si ha expirado el temporizador principal 32 (camino “Si” del paso de decisión S320), entonces el temporizador principal 32 se reinicia (S190) y el nodo de destino pasa de nuevo a comprobar para determinar si la marca de pérdida de sincronismo (SL) está fijada. Si no ha expirado el temporizador principal 32 (camino “No” del paso de decisión S320), entonces el nodo de destino 14 y el método 1100 vuelven al paso de decisión S290 para determinar si se ha recibido el mensaje de informe de estado 38. En caso negativo, entonces el nodo de destino 14 intenta volver a la sincronización determinando si se ha recibido o no una trama de datos 24 en el paso de decisión S300. Si ocurre cualquiera de las posibilidades para volver a la sincronización (es decir, si se ha recibido un mensaje de informe de estado 38 o una trama de datos 24 con una marca de EoM 30), entonces el nodo de destino 14 reinicia la marca de SL (S330) e indica la sincronización recuperada a la aplicación de recepción (S340). Entonces el nodo de destino 14 actualiza el número de secuencia de mensaje esperado al número de secuencia de mensaje actual transportado en el mensaje de informe de estado 38 o la trama de datos 24 antes de detener el temporizador principal 32 en el paso S270 e ir al estado de trama de datos/mensaje de estado (2) en el paso S30.
La FIG. 12 es un diagrama de flujo que ilustra la operación del nodo de origen 12 cuando se incorpora el protocolo de pérdida de límite de mensaje según las realizaciones ejemplares. El nodo de origen 12 permanece en el estado inactivo (S500), a menos que necesite ser hecha una transmisión, o se reciba un mensaje. En el primer caso, una transmisión puede ser de datos o de mensaje de informe de estado 38; no obstante, el mensaje de informe de estado 38 generalmente ocurre después de que ya se ha iniciado una transmisión de datos, y por lo tanto el nodo de origen 12 ya está en el estado de transmisión cuando transmite el mensaje de informe de estado 38. En el segundo caso, los mensajes recibidos pueden incluir cualquiera de un mensaje de consulta de estado 36a o un mensaje de pérdida de sincronismo 36b. Si hay datos o mensaje de informe de estado 38 a transmitir, entonces el nodo de origen 12 entra en el estado de transmisión (S510). En el estado de transmisión, el nodo de origen 12 primero determina qué le hizo entrar en el estado de transmisión: hace esto determinando si hay datos a transmitir en el paso de decisión S520. El nodo de origen 12 hace esto de manera que pueda incluir la última información en el mensaje de informe de estado 38 enviado en respuesta a cualquiera del mensaje de consulta de estado 36a o el mensaje de pérdida de sincronismo 36b. Si hay datos a transmitir (camino “Si” del paso de decisión S520), entonces después de transmitir la trama de datos 24 en el paso S530, se hace una determinación en cuanto a si la marca de EoM 30 está fijada en la aplicación con estos datos en el paso de decisión S540. Si la trama de datos 24 incluye la marca de EoM 30 (camino “Si” del paso de decisión S540), entonces se calcula el desplazamiento de los datos finales y almacena como el valor de desplazamiento del mensaje previo (S550) y el número de secuencia de mensaje 28 se aumenta (S560). En el paso S570, el método 1200 fija el valor inicial del desplazamiento de mensaje actual al mismo valor al que fue actualizado en el paso S550. El valor del desplazamiento de mensaje se actualizará más tarde cuando se transmitan datos adicionales para otros mensajes nuevos.
Si, no obstante, no hay ninguna indicación de EoM 30 (camino “No” del paso de decisión S540), entonces el nodo de origen 12 actualiza el valor de desplazamiento de datos para el mensaje actual en el paso S570. El nodo de origen 12 entonces determina si se ha recibido el mensaje de consulta de estado 36a o el mensaje de pérdida de sincronismo 36b en el paso de decisión S580, ya que es posible que cualquiera de ellos pudiera haber sido recibido desde el nodo de destino 14 simultáneamente con la petición de datos a transmitir desde la aplicación. Esta comprobación también se hace si falla la prueba para datos a transmitir (camino “No” del paso de decisión S520). Si no hay ningún mensaje de consulta de estado 36a o mensaje de pérdida de sincronismo 36b a ser enviado (camino “No” del paso de decisión S580), entonces el nodo de origen 12 vuelve al estado inactivo (S500). De otro modo, si hay cualquiera de un mensaje de consulta de estado 36a o un mensaje de pérdida de sincronismo 36b a ser transmitido (camino “Sí” del paso de decisión S580) el nodo de origen 12 obtiene los desplazamientos del mensaje previo y el mensaje actual de la memoria (S590) y los incluye en el mensaje de informe de estado 38 que se envía en el paso S600 a lado de los números de secuencia de mensaje correspondientes y el estado de mensaje (marca de EoM 30) del mensaje actual. Una vez que se envía el mensaje de informe de estado 38, el nodo de origen 12 vuelve al estado inactivo y espera nuevos datos o una petición para enviar otro mensaje de informe de estado 38.
10
15
20
25
30
35
40
45
50
55
60
E11773245
06-10-2014
Según las realizaciones ejemplares, el protocolo de detección de pérdida de límite de mensaje tratado en detalle en la presente memoria proporciona un sistema y un método de transmisión de datos en tiempo real como múltiples mensajes sobre una interconexión donde cada mensaje representa una unidad de datos que se puede procesar como una entidad y por lo tanto los límites de cada mensaje pueden actuar como puntos de sincronización en el nodo de destino 14. Cada mensaje 22 se puede transmitir como una o más subunidades llamadas segmentos (unidades de datos de la Capa 4) que se encapsulan como tramas de datos (unidades de datos de la Capa 2) 24. La(s) trama(s) de datos 24 que pertenecen al mensaje 22 se identifican por un número de secuencia de mensaje.
Según realizaciones ejemplares adicionales, cada límite de mensaje se identifica por una marca de Fin de Mensaje (EoM) 30 transportada en la última trama de datos 24 que pertenece a un mensaje 22 particular. La pérdida de límites de mensaje se detecta en el nodo de destino 14 cuando hay un cambio en el número de secuencia de mensaje 28 entre mensajes sin recibir una marca de EoM 30 para el mensaje previo. La pérdida de límites de mensaje se comunica al nodo de origen 12 a través de mensajes de pérdida de sincronismo 36a enviados por el nodo de origen 12. El nodo de origen 12 envía mensajes de informe de estado 38 en respuesta a un mensaje de pérdida de sincronismo 36a para permitir al nodo de destino 14 volver a la sincronización. Según realizaciones ejemplares adicionales, los mensajes de pérdida de sincronismo 36a y los mensajes de consulta de estado 36b enviados por el nodo de destino 14 se protegen por uno o más temporizadores (temporizador principal 32 y temporizador aux. 34) en el nodo de destino 14 de que se pierdan.
Según las realizaciones ejemplares, el sistema y método descritos en la presente memoria protegen la pérdida de límite de mensaje de una transmisión de mensaje que se ha detectado en el nodo de destino a través del temporizador aux. 34. El temporizador aux. 34 se inicia a la recepción de la trama de datos 24 que pertenece a un mensaje 22 sin la marca de EoM 30 fijada. El temporizador aux. 34 se reinicia cuando las tramas de datos 24 posteriores que pertenecen al mismo mensaje 22 se reciben sin la marca de EoM 30 fijada. El temporizador aux. 34 se detiene cuando se recibe la trama de datos 24 que pertenece al mismo mensaje 22 con la marca de EoM 30 fijada.
Según realizaciones ejemplares adicionales, el temporizador aux. 34 expira eventualmente si no se recibe ninguna trama de datos 24 adicional que pertenece al mismo mensaje 22 que desencadenó el temporizador aux. 34. El nodo de destino 34 indica tal escenario al nodo de origen 12 enviando el mensaje de consulta de estado 36a. En respuesta, el nodo de origen 12 envía el mensaje de informe de estado 38 para informar al nodo de destino 14 acerca del estado de la transmisión de mensaje.
El mensaje de consulta de estado 36a y los mensajes de informe de estado 38 se protegen por el temporizador principal 32 que también protege el mensaje de pérdida de sincronismo 36b. Según realizaciones ejemplares adicionales, el valor de expiración del temporizador aux. 34 se negocia al comienzo de la transferencia de datos entre el nodo de origen 12 y el nodo de destino 14.
Para cada uno de los métodos descritos anteriormente, los correspondientes dispositivos (por ejemplo, interconexiones o interfaces), sistemas y software que operan según los métodos/protocolos descritos anteriormente también se incluyen en diversas realizaciones ejemplares del concepto inventivo general.
Según una realización ejemplar, la implementación de los métodos 1100 y 1200, como se muestran con respecto a las FIG. 11 y 12 puede darse en un procesador dedicado (no mostrado en cualquiera de las FIG. 4 o 5), o a través de los diversos bloques funcionales mostrados en las FIG. 1 y 2 tal como el nodo de origen 12 y el nodo de destino
14. Los expertos en la técnica del concepto inventivo general pueden apreciar que tal funcionalidad se puede diseñar en diversos tipos de circuitería, incluyendo, pero no limitado a estructuras de disposición de puertas programables en campo (FGPA), circuitos integrados de aplicaciones específicas (ASIC), sistemas basados en microprocesador, entre otros tipos. Una discusión detallada de los diversos tipos de implementaciones físicas no ayuda sustancialmente en la comprensión de los conceptos inventivos generales, y por tanto se ha omitido por el propósito doble de brevedad y claridad. No obstante, como es bien conocido por los expertos en la técnica, los sistemas y métodos tratados en la presente memoria se pueden implementar como se trató, y además pueden incluir dispositivos programables.
Considerando el primer, segundo y tercer mensajes que van a ser recibidos sobre una interconexión, y a partir de la discusión precedente, se apreciará que la pérdida de límite de mensaje según algunas realizaciones puede implicar, por ejemplo, detectar o bien (a) que se ha recibido al menos una trama de datos que pertenece al primer mensaje, y se ha recibido una trama de datos que pertenece al segundo mensaje diferente del primer mensaje antes de que se haya recibido una trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, es decir, a partir del cual se puede deducir la pérdida del primer límite de mensaje, o bien (b) que se ha recibido una trama de datos que pertenece a un tercer mensaje que tiene un número de secuencia que es al menos dos veces mayor que un número de secuencia asociado con el primer mensaje después de que se haya recibido la trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, y no se haya recibido ninguna trama de datos que pertenece al segundo mensaje que tiene un número de secuencia mayor que el número de secuencia del primer mensaje y menor que el número de secuencia del tercer mensaje, es decir, a partir del cual se puede deducir la pérdida del segundo límite de mensaje. Estas dos pruebas de pérdida de límite de mensaje (a) y
(b) se pueden usar juntas o independientemente una de otra.
E11773245
06-10-2014
Como se mencionó anteriormente, cuando se detecta una pérdida de límite de mensaje, se puede transmitir una pérdida de mensaje de sincronización (mensaje de pérdida de límite de mensaje) por el nodo de destino, en respuesta a lo cual el nodo de destino puede recibir un informe de estado de sincronización a partir del cual se puede restablecer la sincronización. Se proporciona más adelante un ejemplo puramente ilustrativo.
Notación: “←” significa trama recibida, “→” trama transmitida
←
DataFrame(MSG#1,EoM=0,offset=1A)
←
DataFrame(MSG#1,EoM=1,offset=1B)
←
DataFrame(MSG#2,EoM=0,offset=2A)
x DataFrame(MSG#2,EoM=1,offset=2B) // perdida
x DataFrame(MSG#3,EoM=1,offset=3A) // perdida
x DataFrame(MSG#4,EoM=0;offset=4A) // perdida
x DataFrame(MSG#4,EoM=1,offset=4B) // perdida
x DataFrame(MSG#5, EoM=0,offset=5A) // perdida
←
DataFrame(MSG#5,EoM=0,offset=5B) // Fin de MSG#2, MSG#3, MSG#4, y (opcionalmente) el inicio de MSG#5 se perdieron
→
SyncLoss(MSG#5,offset=5A)
Un simple informe de estado indica la posición de EoM del mensaje previo y el estado de mensaje actual:
←
Status(MSG#4, offset=4B,
EoM=0,MSG#5, offset=5A)
Un informe de estado complejo indica la posición de EoM de los N últimos mensajes previos y el estado de mensaje actual. Para N = 4:
← Status (MSG#1, offset=1B,
MSG#2, offset=2B,
MSG#3, offset=3A,
MSG#4, offset=4B,
EoM=0,MSG,#5, offset=5A)
Tales dispositivos programables y/u otros tipos de circuitos como se trató previamente pueden incluir una unidad de procesamiento, un sistema de memoria, y un canal principal del sistema que acopla diversos componentes del sistema incluyendo la memoria del sistema a la unidad de procesamiento. El canal principal del sistema puede ser cualquiera de diversos tipos de estructuras de canal principal incluyendo un canal principal de memoria o un controlador de memoria, un canal principal periférico, y un canal principal local cualquiera de una variedad de arquitecturas de canal principal. Además, se pueden usar diversos tipos de medios legibles por ordenador para almacenar instrucciones programables. Medios legibles por ordenador pueden ser cualesquiera medios disponibles a los que se puede acceder por la unidad de procesamiento. A modo de ejemplo, y no de limitación, medios legibles por ordenador pueden comprender medios de almacenamiento en ordenador y medios de comunicación. Medios de almacenamiento en ordenador incluyen medios volátiles y no volátiles así como extraíbles y no extraíbles implementados en cualquier método o tecnología para almacenamiento de información tal como instrucciones legibles por ordenador, estructuras de datos, módulos de programa u otros datos. Medios de almacenamiento en ordenador incluyen, pero no se limitan a, RAM, ROM, EEPROM, memoria instantánea u otra tecnología de memoria, CDROM, discos versátiles digitales (DVD) u otro almacenamiento de disco óptico, casetes magnéticos, cinta magnética, almacenamiento en disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que se pueda usar para almacenar la información deseada y al que se pueda acceder por la unidad de procesamiento. Los medios de comunicación pueden incorporar instrucciones legibles por ordenador, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada tal como una onda portadora u otro mecanismo de transporte y puede incluir cualquier medio de entrega de información adecuado.
La memoria del sistema puede incluir medios de almacenamiento en ordenador en forma de memoria volátil y/o no volátil tal como memoria solamente de lectura (ROM) y/u memoria de acceso aleatorio (RAM). Un sistema de entrada/salida básico (BIOS), que contiene las rutinas básicas que ayudan a transferir información entre elementos
10
15
20
25
30
35
E11773245
06-10-2014
conectados a y entre el procesador, tal como durante la puesta en marcha, se pueden almacenar en memoria. La memoria también puede contener módulos de datos y/o de programa que son accesibles inmediatamente para y/o actualmente que son operados por la unidad de procesamiento. A modo de ejemplo no limitativo, la memoria también puede incluir un sistema operativo, programas de aplicaciones, otros módulos de programa, y datos de programa.
El procesador también puede incluir otros medios de almacenamiento en ordenador extraíbles/no extraíbles y volátiles/no volátiles. Por ejemplo, el procesador puede acceder a una unidad de disco duro que lee de o escribe en medios magnéticos no extraíbles, no volátiles, una unidad de disco duro magnético que lee de o escribe en un disco magnético extraíble, no volátil, y/o una unidad de disco duro óptico que lee de o escribe en un disco óptico extraíble, no volátil, tal como un CD-ROM u otros medios ópticos. Otros medios de almacenamiento en ordenador extraíbles/no extraíbles, volátiles/no volátiles que se pueden usar en el entorno de operación ejemplar incluyen, pero no están limitados a, casetes de cinta magnética, tarjetas de memoria instantánea, discos versátiles digitales, cinta de vídeo digital, RAM de estado sólido, ROM de estado sólido y similares. Una unidad de disco duro se puede conectar al canal principal del sistema a través de una interfaz de memoria no extraíble tal como una interfaz, y una unidad de disco magnético o unidad de disco óptico se puede conectar al canal principal del sistema mediante una interfaz de memoria extraíble, tal como una interfaz.
El presente concepto inventivo general también se puede incorporar como códigos legibles por ordenador en un medio legible por ordenador. El medio legible por ordenador puede incluir un medio de grabación legible por ordenador y un medio de transmisión legible por ordenador. El medio de grabación legible por ordenador es cualquier dispositivo de almacenamiento de datos que pueda almacenar datos que se pueden leer a partir de entonces por un sistema informático. Ejemplos del medio de grabación legible por ordenador incluyen una memoria solamente de lectura (ROM), una memoria de acceso aleatorio (RAM), CD-ROM, cintas magnéticas, discos flexibles, y dispositivos de almacenamiento de datos ópticos. El medio de grabación legible por ordenador también se puede distribuir sobre una red acoplada a sistemas informáticos de manera que el código legible por ordenador se almacena y ejecuta de una forma distribuida. El medio de transmisión legible por ordenador puede transmitir ondas portadoras o señales (por ejemplo, transmisión de datos cableada o inalámbrica a través de Internet). También, programas funcionales, códigos, y segmentos de código para consumar el presente concepto inventivo general se pueden interpretar fácilmente por programadores expertos en la técnica a la que pertenece el presente concepto inventivo general.
Las realizaciones ejemplares descritas anteriormente se pretende que sean ilustrativas en todos los aspectos, más que restrictivas, de la presente invención. De esta manera la presente invención es capaz de muchas variaciones en la implementación detallada que se pueden derivar de la descripción contenida en la presente memoria por un experto en la técnica. Ningún elemento, acto, o instrucción usado en la descripción de la presente solicitud se debería interpretar como crítico o esencial para la invención a menos que se describa explícitamente como tal. También, como se usa en la presente memoria, el artículo “un” se pretende que incluya uno o más elementos.

Claims (28)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    E11773245
    06-10-2014
    REIVINDICACIONES
    1. Un método para manejar una pérdida de límite de mensaje en una transmisión de datos en tiempo real sobre una interconexión, que comprende:
    recibir sobre la interconexión (10) y por un nodo de destino (14) una pluralidad de mensajes (22), en donde
    cada mensaje (22) incluye una o más tramas de datos (24), y cada trama de datos (24) de cada mensaje (22) incluye una marca de fin de mensaje (30) y un número de secuencia de mensaje (28), y la marca de fin de mensaje
    (30)
    se fija cuando la trama de datos (24) es la última trama de datos (24) en un mensaje particular (22), y el número de secuencia de mensaje (28) es diferente para mensajes diferentes (22); caracterizado por:
    determinar la pérdida de límite de mensaje por uno de un primer mensaje (22) y un segundo mensaje (22) a ser recibido sobre la interconexión detectando que o bien:
    (a)
    se ha recibido al menos una trama de datos que pertenece al primer mensaje, y se ha recibido una trama de datos (24) que pertenece al segundo mensaje (22) diferente del primer mensaje antes que de que se haya recibido una trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, o bien
    (b)
    se ha recibido una trama de datos que pertenece a un tercer mensaje (22) que tiene un número de secuencia que es al menos dos veces mayor que un número de secuencia asociado con el primer mensaje después de que se haya recibido la trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, y no se haya recibido ninguna trama de datos que pertenece al segundo mensaje que tiene un número de secuencia mayor que el número de secuencia del primer mensaje y menor que el número de secuencia del tercer mensaje.
  2. 2. El método según la reivindicación 1, que además comprende:
    transmitir por el nodo de destino que se ha determinado un mensaje de pérdida de sincronización en respuesta a la pérdida de límite de mensaje;
    recibir por el nodo de destino un mensaje de informe de estado en respuesta a transmitir el mensaje de pérdida de sincronización; y
    sincronizar los datos de mensaje recibidos de manera que al menos un límite de mensaje previo se pueda determinar según el mensaje de informe de estado.
  3. 3. El método según la reivindicación 2, en donde
    el mensaje de informe de estado incluye una marca de fin de mensaje para al menos un mensaje actual que se puede fijar cuando se ha enviado completamente un mensaje actual, y en donde
    el informe de estado incluye al menos un número de secuencia de mensaje previo así como el número de secuencia de mensaje actual, y el al menos un número de mensaje previo puede referirse o bien a un mensaje previo particular
    o bien a un conjunto de mensajes previos, y en donde
    el mensaje de informe de estado además incluye al menos un valor de desplazamiento de mensaje previo que corresponde a al menos uno de un número total de bytes transmitidos en el mensaje previo y un número total de bytes transmitidos en un conjunto previo de mensajes, y
    en donde el mensaje de informe de estado además incluye un valor de desplazamiento de mensaje actual que corresponde a un número total de bytes transmitidos en el mensaje actual.
  4. 4. El método según la reivindicación 2, que además comprende:
    iniciar un temporizador principal con un primer periodo de expiración tras la transmisión del mensaje de pérdida de sincronización; y
    retransmitir el mensaje de pérdida de sincronización por el nodo de destino tras la expiración del temporizador principal.
  5. 5.
    El método según la reivindicación 4, que además comprende: determinar el primer periodo de expiración anterior a la recepción de un primer mensaje por el nodo de destino.
  6. 6.
    El método según la reivindicación 5, en donde el paso de determinación comprende:
    medir un tiempo de transmisión de ida y vuelta entre el nodo de destino y el nodo de origen e incluir un tiempo de procesamiento en el nodo de origen.
  7. 7.
    El método según la reivindicación 1, que además comprende:
    E11773245
    06-10-2014
    iniciar un temporizador auxiliar con un segundo periodo de expiración tras la recepción de cada trama de datos en la que no está fijada la marca de fin de mensaje; y
    transmitir por el nodo de destino un mensaje de consulta de estado tras la expiración del segundo periodo de expiración del temporizador auxiliar, en donde el mensaje de consulta de estado incluye un número de secuencia de mensaje actual, y un valor de desplazamiento de mensaje actual que corresponde a un número total de bytes recibidos por el nodo de destino para el mensaje actual.
  8. 8.
    El método según la reivindicación 7, que además comprende:
    determinar el segundo periodo de expiración anterior a la recepción de un primer mensaje por el nodo de destino.
  9. 9.
    El método según la reivindicación 7, que además comprende:
    recibir por el nodo de destino un mensaje de informe de estado en respuesta al mensaje de consulta de estado, en donde el mensaje de informe de estado incluye un valor de desplazamiento de mensaje previo que corresponde a un número total de bytes transmitido en el mensaje previo, un valor de desplazamiento de mensaje actual que corresponde a un número total de bytes transmitidos en el mensaje actual, y una marca de fin de mensaje fijada si se ha transmitido completamente el mensaje actual; y
    determinar que si no está fijada una marca de fin de mensaje, entonces no se ha enviado completamente el mensaje actual y que se esperan tramas de datos adicionales para el mensaje actual, y además determinar que si se ha fijado la marca de fin de mensaje que el mensaje actual es completo y determinar el límite de mensaje a partir del valor de desplazamiento de mensaje actual recibido en el mensaje de informe de estado.
  10. 10. El método según la reivindicación 9, que además comprende:
    determinar que si no se ha completado el mensaje actual que se han perdido las tramas de datos del mensaje actual a partir de una comparación del valor de desplazamiento actual en el mensaje de informe de estado y el valor de desplazamiento actual transmitido por el nodo de destino en el informe de consulta de estado; e
    interpolar los datos que faltan a partir de datos previos según un algoritmo.
  11. 11.
    El método según la reivindicación 10, en donde el algoritmo de interpolación pertenece a un algoritmo de interpolación de datos de vídeo para compensar las tramas de datos de vídeo pérdidas.
  12. 12.
    El método según la reivindicación 7, que además comprende:
    iniciar un temporizador principal tras la transmisión del mensaje de consulta de estado con un segundo valor de expiración; y
    retransmitir el mensaje de consulta de estado por el nodo de destino tras la expiración del temporizador principal.
  13. 13. El método según la reivindicación 1, que además comprende:
    transmitir por el nodo de destino un mensaje de pérdida de sincronización tras la determinación de la pérdida de límite de mensaje;
    recibir por el nodo de destino una nueva trama de datos para un nuevo mensaje anterior a recibir una respuesta al mensaje de pérdida de sincronización transmitido, en donde la nueva trama de datos incluye una marca de fin de mensaje fijada; y
    sincronizar los datos de mensaje recibidos previamente de manera que un límite de mensaje previo se pueda determinar según la nueva trama de datos.
  14. 14. Un aparato para manejar una pérdida de límite de mensaje en una transmisión de datos en tiempo real, que comprende:
    un transceptor del nodo de destino (18) configurado para recibir mensajes (24) sobre una interconexión (10), en donde cada mensaje (22) incluye una o más tramas de datos (24), y cada trama de datos (24) de cada mensaje (22) incluye una marca de fin de mensaje (30) y un número de secuencia de mensaje (28), la marca de fin de mensaje
    (30)
    fijada cuando la trama de datos (24) es la última trama de datos (24) en un mensaje particular (22), y el número de secuencia de mensaje (28) es diferente para mensajes diferentes (22); caracterizado por:
    un procesador de nodo de destino configurado para determinar la pérdida de límite de mensaje para uno de un primer mensaje (22) y un segundo mensaje (22) a ser recibido sobre la interconexión detectando que o bien:
    (a)
    se ha recibido al menos una trama de datos que pertenece al primer mensaje, y se ha recibido una trama de datos (24) que pertenece al segundo mensaje (22) diferente del primer mensaje antes que se haya recibido una trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, o bien
    5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    E11773245
    06-10-2014
    (b) se ha recibido una trama de datos que pertenece a un tercer mensaje (22) que tiene un número de secuencia que es al menos dos veces mayor que un número de secuencia asociado con el primer mensaje después de que se haya recibido la trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, y no se haya recibido ninguna trama de datos que pertenece al segundo mensaje que tiene un número de secuencia mayor que el número de secuencia del primer mensaje y menor que el número de secuencia del tercer mensaje.
  15. 15. El aparato según la reivindicación 14, en donde el transceptor del nodo de destino está configurado para transmitir un mensaje de pérdida de sincronización tras la determinación de la pérdida de límite de mensaje, y en donde
    el transceptor del nodo de destino además está configurado para recibir un mensaje de informe de estado en respuesta al mensaje de pérdida de sincronización transmitido, y además en donde
    el procesador del nodo de destino además está configurado para sincronizar datos de mensaje recibidos previamente de manera que un límite de mensaje previo se pueda determinar según el mensaje de informe de estado.
  16. 16. El aparato según la reivindicación 15, en donde el mensaje de informe de estado incluye
    una marca de fin de mensaje para al menos un mensaje actual que se puede fijar cuando se ha enviado completamente un mensaje actual, y en donde
    el informe de estado incluye al menos un número de secuencia de mensaje previo así como el número de secuencia de mensaje actual, y el al menos un número de mensaje previo se puede referir o bien a un mensaje previo particular o bien a un conjunto de mensaje previos, y en donde
    el mensaje de informe de estado además incluye al menos un valor de desplazamiento de mensaje previo que corresponde a al menos uno de un número total de bytes transmitidos en el mensaje previo y un número total de bytes transmitidos en un conjunto previo de mensajes, y
    en donde el mensaje de informe de estado además incluye un valor de desplazamiento de mensaje actual que corresponde a un número total de bytes transmitido en el mensaje actual.
  17. 17. El aparato según la reivindicación 15, que además comprende:
    un temporizador principal con un primer periodo de expiración configurado para comenzar la cuenta tras la transmisión del mensaje de pérdida de sincronización, y en donde
    el transceptor de destino además se configura para retransmitir el mensaje de pérdida de sincronización tras la expiración del temporizador principal.
  18. 18.
    El aparato según la reivindicación 17, en donde el primer periodo de expiración se determina anterior a la recepción de un primer mensaje por el nodo de destino.
  19. 19.
    El aparato según la reivindicación 18, en donde el primer periodo de expiración comprende una medición de un tiempo de transmisión de ida y vuelta entre el nodo de destino y un nodo de origen e incluye un tiempo de procesamiento en el nodo de origen.
  20. 20.
    El aparato según la reivindicación 14, que además comprende:
    un temporizador auxiliar con un segundo periodo de expiración configurado para comenzar la cuenta tras la recepción de cada trama de datos en la que no está fija la marca de fin de mensaje; y en donde
    el transceptor del nodo de destino está configurado para transmitir un mensaje de consulta de estado tras la expiración del segundo periodo de expiración del temporizador auxiliar, en donde el mensaje de consulta de estado incluye un número de secuencia de mensaje actual, y un valor de desplazamiento de mensaje actual que corresponde a un número total de bytes recibidos por el nodo de destino para el mensaje actual.
  21. 21.
    El aparato según la reivindicación 20, en donde además el segundo periodo de expiración se determina anterior a la recepción de un primer mensaje por el nodo de destino.
  22. 22.
    El aparato según la reivindicación 20, en donde el transceptor del nodo de destino está configurado para recibir un mensaje de informe de estado, en donde el informe de mensaje de estado incluye el valor de desplazamiento de mensaje previo que corresponde a un número total de bytes transmitidos en el mensaje previo, un valor de desplazamiento de mensaje actual que corresponde a un número total de bytes transmitidos en el mensaje actual, y una marca de fin de mensaje fijada si se ha transmitido completamente el mensaje actual, y además en donde el procesador del nodo de destino se configura para determinar que si no está fijada una marca de fin de mensaje, entonces no se ha enviado completamente el mensaje actual y que se esperan tramas de datos adicionales para el mensaje actual, y el procesador del nodo de destino se configura además para determinar que si se ha fijado la
    5
    10
    15
    20
    25
    30
    35
    40
    45
    E11773245
    06-10-2014
    marca de fin de mensaje que el mensaje actual está completo y además puede determinar el límite de mensaje a partir del valor de desplazamiento de mensaje actual en el mensaje de informe de estado.
  23. 23.
    El aparato según la reivindicación 22, en donde el procesador del nodo de destino además está configurado para determinar que si no se ha completado el mensaje actual que se han perdido tramas de datos del mensaje actual a partir de una comparación del valor de desplazamiento actual recibido por el nodo de destino en el mensaje de informe de estado y el valor de desplazamiento actual transmitido por el nodo de destino, y además en donde el nodo de destino está configurado además para interpolar los datos que faltan a partir de datos previos según un algoritmo.
  24. 24.
    El aparato según la reivindicación 23, en donde el algoritmo de interpolación comprende un algoritmo de interpolación de datos de vídeo.
  25. 25.
    El aparato según la reivindicación 20, que además comprende:
    un temporizador principal con un segundo valor de expiración configurado para comenzar una cuenta atrás tras la transmisión del mensaje de consulta de estado, y en donde el transceptor del nodo de destino está configurado para retransmitir el mensaje de consulta de estado tras la expiración del segundo temporizador.
  26. 26.
    El aparato según la reivindicación 14, en donde
    el transceptor del nodo de destino se configura además para transmitir un mensaje de pérdida de sincronización tras la determinación de la pérdida de límite de mensaje, y
    el nodo de destino se configura además para recibir una nueva trama de datos para un nuevo mensaje anterior a recibir una respuesta al mensaje de pérdida de sincronización transmitido, en donde la nueva trama de datos incluye una marca de fin de mensaje fijada, un mensaje de informe de estado, y en donde
    el procesador del nodo de destino se configura para sincronizar los datos de mensaje recibidos previamente de manera que un límite de mensaje previo se puede determinar según la nueva trama de datos.
  27. 27.
    El aparato según la reivindicación 14, en donde el aparato es un teléfono celular.
  28. 28.
    Un medio legible por ordenador no transitorio de instrucciones para corregir una pérdida de límite de mensaje en una transmisión de datos en tiempo real sobre una interconexión (10), que comprende:
    un primer juego de instrucciones adaptado para recibir, sobre la interconexión (10) y en un nodo de destino (14), uno
    o más mensajes (22), en donde
    cada mensaje (22) incluye una o más tramas de datos (24), y cada trama de datos (24) de cada mensaje (22) incluye una marca de fin de mensaje (30) y un número de secuencia de mensaje (28), la marca de fin de mensaje
    (30)
    se fija cuando la trama de datos (24) es la última trama de datos (24) en un mensaje particular (22), y el número de secuencia de mensaje (28) es diferente para mensajes diferentes (22); caracterizado por:
    un segundo juego de instrucciones adaptado para determinar la pérdida de límite de mensaje para uno de un primer mensaje (22) y un segundo mensaje (22) a ser recibido sobre la interconexión detectando que o bien:
    (a)
    se ha recibido al menos una trama de datos que pertenece al primer mensaje, y se ha recibido una trama de datos (24) que pertenece al segundo mensaje (22) diferente del primer mensaje antes que se haya recibido una trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, o bien
    (b)
    se ha recibido una trama de datos que pertenece a un tercer mensaje (22) que tiene un número de secuencia que es al menos dos veces mayor que un número de secuencia asociado con el primer mensaje después de que se haya recibido la trama de datos que tiene su marca de fin de mensaje fijada y que pertenece al primer mensaje, y no se haya recibido ninguna trama de datos que pertenece al segundo mensaje que tiene un número de secuencia mayor que el número de secuencia del primer mensaje y menor que el número de secuencia del tercer mensaje;
    un tercer juego de instrucciones adaptadas para transmitir por el nodo de destino (14) un mensaje de pérdida de sincronización (36b);
    un cuarto juego de instrucciones adaptadas para recibir un mensaje de informe de estado (38) por el nodo de destino (14) en respuesta al mensaje de pérdida de sincronización (36b); y
    un quinto juego de instrucciones adaptadas para sincronizar los datos de mensaje recibidos de manera que se pueda determinar un límite de mensaje previo según el mensaje de informe de estado (38).
ES11773245.3T 2010-10-18 2011-10-18 Sistema y método para detectar y comunicar pérdida y retención de sincronización en un esquema de transferencia de datos en tiempo real Active ES2512444T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US39407010P 2010-10-18 2010-10-18
US394070P 2010-10-18
PCT/EP2011/068204 WO2012052450A1 (en) 2010-10-18 2011-10-18 System and method to detect and communicate loss and retention of synchronization in a real-time data transfer scheme

Publications (1)

Publication Number Publication Date
ES2512444T3 true ES2512444T3 (es) 2014-10-24

Family

ID=44862977

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11773245.3T Active ES2512444T3 (es) 2010-10-18 2011-10-18 Sistema y método para detectar y comunicar pérdida y retención de sincronización en un esquema de transferencia de datos en tiempo real

Country Status (6)

Country Link
US (1) US9148274B2 (es)
EP (1) EP2630743B1 (es)
CN (1) CN103329467B (es)
ES (1) ES2512444T3 (es)
PL (1) PL2630743T3 (es)
WO (1) WO2012052450A1 (es)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104104475B (zh) * 2013-04-02 2018-05-29 安凯(广州)微电子技术有限公司 一种应答信号的生成方法、接收方法与装置
CN105051706B (zh) 2013-04-17 2018-07-24 英特尔公司 用于具有pcie协议栈的低功率phy的操作的设备、方法和系统
FR3020543A1 (fr) * 2014-04-28 2015-10-30 St Microelectronics Grenoble 2 Procede de gestion de la communication entre deux dispositifs mutuellement connectes par un lien serie, par exemple un protocole d'interface serie point a point
US9992088B1 (en) 2014-11-07 2018-06-05 Speedy Packets, Inc. Packet coding based network communication
US10530700B2 (en) * 2015-07-07 2020-01-07 Strong Force Iot Portfolio 2016, Llc Message reordering timers
US10999012B2 (en) 2014-11-07 2021-05-04 Strong Force Iot Portfolio 2016, Llc Packet coding based network communication
US9825733B1 (en) 2014-11-07 2017-11-21 Speedy Packets, Inc. Packet coding based network communication
US9942866B2 (en) * 2015-09-11 2018-04-10 Nxp Usa, Inc. Method for determining and recovering from loss of synchronization, communication units and integrated circuits therefor
CN105610566A (zh) * 2016-01-06 2016-05-25 烽火通信科技股份有限公司 主备节点间数据实时同步的方法及系统
CN107124288B (zh) * 2016-02-24 2021-01-29 大唐移动通信设备有限公司 一种消息处理方法和装置
CN105812099B (zh) * 2016-04-13 2019-03-05 飞天诚信科技股份有限公司 一种通过同步机制保证大数据通信稳定的方法及装置
CN106789862B (zh) * 2016-04-25 2021-05-07 新华三技术有限公司 一种数据同步方法及装置
US10742390B2 (en) * 2016-07-13 2020-08-11 Novatek Microelectronics Corp. Method of improving clock recovery and related device
CN107888341B (zh) * 2016-09-29 2022-09-16 大唐移动通信设备有限公司 一种数据传输方法及装置
US10863322B2 (en) 2018-08-13 2020-12-08 Ademco Inc. Wireless communication with replay attack protection for low power building control applications
US11144535B2 (en) * 2018-11-30 2021-10-12 The Boeing Company On-board vehicle recorder system monitor
CN112583570A (zh) * 2019-09-27 2021-03-30 华为技术有限公司 一种序列号同步的方法及装置
CN113163197B (zh) * 2021-04-26 2023-02-21 北京欧铼德微电子技术有限公司 数据传输方法、电路、装置、设备及存储介质
CN113726468B (zh) * 2021-08-31 2022-05-13 四川九洲电器集团有限责任公司 基于导航定位设备的时间同步方法、设备、终端、介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5039980A (en) * 1990-01-26 1991-08-13 Honeywell Inc. Multi-nodal communication network with coordinated responsibility for global functions by the nodes
US5444709A (en) 1993-09-30 1995-08-22 Apple Computer, Inc. Protocol for transporting real time data
US6718425B1 (en) * 2000-05-31 2004-04-06 Cummins Engine Company, Inc. Handheld computer based system for collection, display and analysis of engine/vehicle data
CA2674710C (en) 2007-01-09 2016-02-23 Vidyo, Inc. Improved systems and methods for error resilience in video communication systems
US7684407B2 (en) * 2007-10-01 2010-03-23 Motorola, Inc. Status report method in a wireless communication system

Also Published As

Publication number Publication date
CN103329467A (zh) 2013-09-25
EP2630743A1 (en) 2013-08-28
US20140310566A1 (en) 2014-10-16
PL2630743T3 (pl) 2015-02-27
WO2012052450A1 (en) 2012-04-26
CN103329467B (zh) 2016-01-20
US9148274B2 (en) 2015-09-29
EP2630743B1 (en) 2014-07-30

Similar Documents

Publication Publication Date Title
ES2512444T3 (es) Sistema y método para detectar y comunicar pérdida y retención de sincronización en un esquema de transferencia de datos en tiempo real
ES2272350T3 (es) Metodo para realizar una transmision de datos mas eficaz y protocolo de transmision de datos.
US10924745B2 (en) Image processing method and device
ES2316361T3 (es) Notificacion de descarte de paquete para protocolo de retransmision semifiable.
ES2239721T3 (es) Metodo y receptor para la transferencia mejorada de paquetes de datos en un protocolo de transmision con peticiones de repeticion.
ES2245935T3 (es) Protocolo de control flexible de radioenlace.
ES2639585T3 (es) Método y dispositivo para la transmisión de datos en serie con una tasa de datos conmutable
ES2272691T3 (es) Reubicacion de la informacion de contexto en la compresion de encabezamientos.
ES2361426T3 (es) Evitación de condiciones dilatorias y de ambigüedad del número de secuencia en un protocolo de petición de repetición automática.
ES2531856T3 (es) Método y unidad de transmisión para reducir un riesgo de estancamiento de una transmisión
ES2608807T3 (es) Transmisión de datos basada en paquetes
ES2299868T3 (es) Terminal de comunicacion y metodo para temporizar la deteccion de caracteristicas de comunicacion.
ES2830732T3 (es) Comunicación de múltiples canales
ES2669718T3 (es) Método y aparato para desencadenar informe de estado de acuse de recibo en sistema de comunicaciones inalámbricas
ES2741582T3 (es) Mecanismo predictivo de retroalimentación de acuse de recibo
KR101453182B1 (ko) 프레임 전송의 적어도 부분적인 중단
BR112012029332B1 (pt) Dispositivo de comunicação sem fio móvel, método, e meio legível por computador não transitório
CN102461043B (zh) 使用可变计时器来发送出错报告
TW201004181A (en) Adding hybrid ARQ to WLAN protocols with MAC based feedback
KR20140056239A (ko) 유연한 메시지 크기 및 가변 비트 길이로 직렬 데이터 전송을 하기 위한 방법 및 장치
EP2241044B1 (en) Method of communication, in particular with capability of frame abortion or retransmission indication, between a transmitter and a receiver based on frames, and corresponding communication node
US20220006564A1 (en) User station for a serial bus system, and method for communicating in a serial bus system
RU2455770C2 (ru) Способ и устройство для передачи блока данных
ES2905355T3 (es) Dispositivo de usuario y estación base
ES2283255T3 (es) Procedimiento para mejorar la eficiencia de una red de tiempo compartido.