ES2561161T3 - Procedimiento de transmisión/recepción en tiempo real de datos por paquetes entre un servidor y un terminal cliente, servidor y terminal correspondientes - Google Patents

Abstract

Procedimiento de transmisión/recepción en tiempo real de datos por paquetes en red IP entre un servidor y un terminal cliente, caracterizado por que consiste al menos en, en el lado del servidor: - asignar (A) a cada paquete a transmitir un índice de continuidad de emisión; - transmitir (B) sucesivamente cada uno de los paquetes según el protocolo UDP y su índice de continuidad según el protocolo DCP hacia dicho terminal cliente; y, en el lado del terminal cliente: - detectar (G) cualquier ruptura de continuidad del flujo de paquetes recibidos a partir de los índices de continuidad asociados a cada paquete recibido; y, tras la detección de una discontinuidad del flujo, - transmitir (L) desde el terminal cliente al servidor al menos una solicitud de reemisión de al menos un paquete faltante, en tanto que dicho al menos un paquete faltante no haya sido recibido por dicho terminal cliente.

Description

5

10

15

20

25

30

35

40

45

50

55

60

65

DESCRIPCION

Procedimiento de transmision/recepcion en tiempo real de datos por paquetes entre un servidor y un terminal cliente, servidor y terminal correspondientes

La invencion se refiere a un procedimiento de transmision/recepcion en tiempo real de datos por paquetes, entre un servidor y un terminal cliente, un servidor y un terminal correspondientes.

La transferencia de los flujos de datos en tiempo real, flujos isocronos de tipo audio o video, es cada vez mas frecuentemente efectuada utilizando unos flujos, particularmente flujos IP por Internet Protocol en ingles, mediante fibra optica, satelite, o enlace ADSL por ejemplo.

La presente invencion tiene por objeto hacer mas fiable la transferencia de datos sobre unos enlaces por paquete, principalmente de tipo IP, en el caso de una transmision esencialmente en tiempo real, cuando la velocidad de transmision es impuesta por el servidor de la aplicacion, aplicacion tal como radio, video por ejemplo.

Los protocolos actualmente utilizables para el encaminamiento de los datos en tiempo real son de dos tipos:

Los protocolos en modo conectado, de tipo TCP por Transmission Control Protocol en ingles, y en modo no conectado, de tipo UDP por User Datagram Protocol en ingles.

En modo conectado, el protocolo TCP preve un acuse de recibo de cada recepcion de paquetes de datos. Este protocolo ha sido el objeto de una descripcion detallada en el documento “TCP: Transmission Control Protocol” RFC 793, septiembre de 1981.

Ademas, el protocolo DCP por Distribution and Communications Protocol en ingles, se ha definido en el marco del proyecto DRM por Digital Radio Mondial, proyectos de digitalizacion de las ondas largas, medias y cortas. DCP ha sido el objeto de una descripcion detallada en la norma ETSI, European Telecommunications Standards Institute en ingles, referenciada como TS 102821.

En modo no conectado, el protocolo UDP no permite mas que el dimensionamiento de unos paquetes. Ha sido el objeto de una descripcion detallada en el documento titulado “User Datagram Protocol, RDC 768”, agosto de 1980.

El protocolo DCP sobre UDP posee unos Indices de continuidad del flujo, que permiten detectar las perdidas de paquetes de datos. Este protocolo ha sido el objeto de una descripcion detallada en el documento titulado Distribution and Communication Protocol igualmente referenciado ETSI, TS 102821. Definido en el marco del proyecto DRM, permite proteger, de manera opcional, los datos transmitidos mediante una fragmentacion asociada a un codigo de Reed Solomon.

El protocolo RTP por Real-time Transport Protocol en ingles, es un protocolo de transmision continuo que implementa un contador de continuidad que permite detectar los paquetes de datos perdidos. Implementado en asociacion con el protocolo RTCP por Real Time Control Protocol en ingles, permite igualmente estimar la calidad del enlace.

Los protocolos antes mencionados se definen en los documentos citados a continuacion:

- “RTP: A Transport Protocol for Real Time Applications”, STD 64, RFC 3550, julio de 2003;

- “RTP: A Transport Protocol for Real-Time Applications”, RFC 1889, enero de 1996.

A tltulo de ejemplo, la solicitud de patente JP 2004 186737 describe un sistema de comunicacion que se basa unicamente en el protocolo RTP, en el que se requiere la retransmision de paquetes RTP, en el lado del receptor, en funcion del numero de secuencia insertado en el paquete RTP.

La solicitud EP 1 211 856, por su parte, describe un procedimiento que utiliza igualmente la insercion de un numero de secuencia en unos paquetes transmitidos, con el fin de detectar unos paquetes perdidos y enviar eventualmente una solicitud de retransmision del paquete en caso de detection de paquetes perdidos.

Los protocolos de la tecnica anterior mencionados anteriormente presentan unos inconvenientes.

En modo conectado, el principal inconveniente es que estos protocolos necesitan un enlace bidireccional rapido, con el fin de acusar recibo de cada uno de los paquetes de datos recibido. Esta limitation es incompatible con unos enlaces monodireccionales, tales como enlaces de satelite o de fibra optica.

En particular, el transporte de un flujo en tiempo real mediante el protocolo TCP presenta varios inconvenientes durante un corte del enlace:

5

10

15

20

25

30

35

40

45

50

55

60

65

- un corte superior al retardo de espera de la red, designado “timeout” en ingles, necesita un elevado tiempo de reconexion;

- el tiempo de reconstitucion de la memoria tampon para varias tramas de paquetes de datos, utilizado por el terminal cliente para compensar la perturbacion de la red, se adiciona al tiempo de corte;

- durante el reinicio de la conexion, si no se ha sobrepasado el “timeout”, el servidor envla todos los datos que no ha podido transmitir, comprendidos en ellos los datos obsoletos, lo que retarda el reinicio de la transmision util.

El protocolo antes mencionado necesita una conexion y una replicacion del flujo para cada terminal cliente, porque no permite la difusion el modelo multidifusion. Necesita por lo tanto unos grandes recursos tanto a nivel del servidor como al nivel de la red.

En modo conectado, el protocolo UDP no garantiza la entrega de los paquetes y no posee ningun modo de proteccion contra los errores.

El protocolo DCP/UDP, protocolo DCP asociado al protocolo UDP, asegura con un contaje de continuidad una proteccion contra los errores. Sin embargo, esta proteccion continua siendo muy debil, porque permite corregir un maximo del 20 % de los paquetes transmitidos. Estando constituida esta proteccion por una fragmentacion de los paquetes transmitidos, asociada a un codigo de Reed Solomon.

El protocolo RTP, aunque permite detectar los paquetes perdidos y estimar la calidad del enlace, no permite recuperar los datos perdidos.

La presente invencion tiene por objeto hacer mas fiable la transmision de datos en tiempo real transportados por cualquier flujo IP, solucionando los inconvenientes de los protocolos conocidos en el estado de la tecnica, mediante la correccion de los cortes del enlace mas largos que para el protocolo DCP/UDP, en ausencia de los inconvenientes del protocolo TCP.

En particular, la invencion tiene por objeto un procedimiento de transmision en tiempo real de datos por paquetes entre un servidor y un terminal cliente en el que la longitud, en duracion, de las rupturas del enlace susceptibles de ser corregidas es funcion, por un lado, del tamano de la memoria utilizada como memoria tampon, tanto en el lado del servidor de la aplicacion como en el lado del terminal cliente, y, por otro lado, del tiempo de enlace entre el servidor y el terminal.

Otro objetivo de la presente invencion es, ademas, la implementacion de un procedimiento de transmision/recepcion en tiempo real de datos por paquetes, que incluye una funcion de repeticion de los paquetes emitidos, siendo observada solo una ruptura de la transmision mas larga en duracion que la capacidad o duracion de repeticion en el nivel del terminal cliente, apareciendo entonces esta ruptura igual a la longitud en duracion del corte del enlace, disminuida por la capacidad de repeticion.

Finalmente, otro objeto de la presente invencion es la implementacion de un procedimiento de transmision/recepcion en tiempo real de datos por paquetes entre servidor y terminal cliente, que permita conservar un flujo compatible con unos equipos de recepcion clientes que no generen la solicitud de repeticion de los paquetes.

El procedimiento de transmision/recepcion en tiempo real de datos por paquetes en una red IP entre un servidor y un terminal cliente, objeto de la invencion, es notable porque consiste al menos, en el lado del servidor, en adjudicar a cada paquete a transmitir un Indice de continuidad de emision, transmitir sucesivamente cada uno de los paquetes segun el protocolo UDP y su Indice de continuidad segun el protocolo DCP hacia el terminal cliente, y, en el lado del terminal cliente, detectar cualquier ruptura del flujo de paquetes recibidos a partir de los Indices de continuidad asociados a cada paquete recibido, y, tras la deteccion de una discontinuidad del flujo, transmitir desde el terminal cliente al servidor al menos una solicitud de reemision de al menos un paquete que falte, mientras que al menos un paquete faltante no haya sido recibido por este terminal cliente.

El procedimiento objeto de la invencion es notable, ademas, porque consiste, tanto en el lado del servidor como en el lado del terminal cliente, en memorizar de modo continuo una misma pluralidad de paquetes sucesivos, con la excepcion acerca de los paquetes no recibidos en el lado del terminal cliente, siendo memorizado cada paquete y acompanado de su Indice de continuidad.

El procedimiento objeto de la invencion es igualmente notable porque la etapa de deteccion de cualquier ruptura de continuidad se efectua mediante analisis del unico flujo DCP.

El procedimiento de la invencion es, ademas, notable porque la etapa que consiste en memorizar de modo continuo, consiste en memorizar cada paquete de la pluralidad de paquetes sucesivos en una memoria, por ejemplo una memoria tampon de tipo FIFO.

Segun otro aspecto notable del procedimiento, objeto de la invencion, el tamano de la memoria antes mencionada en numero de paquetes es funcion de los parametros de transmision de la red de transmision de los paquetes.

5

10

15

20

25

30

35

40

45

50

55

60

65

Segun otro aspecto notable del procedimiento, objeto de la invencion, el tamano de la memoria antes mencionado es adaptativo, lo que permite optimizar la compensacion de rupturas de transmision, al tiempo de ida y vuelta cercano, entre el terminal cliente y el servidor.

El procedimiento, objeto de la invencion, es igualmente notable porque la transmision de las informaciones, necesaria en el cliente para efectuar unas peticiones de repetition, se efectua mediante la transmision de information que incluye al menos la direction de destino de cualquier solicitud de reemision de paquetes, el tamano de memoria de la memoria de la pluralidad de paquetes sucesivos.

El procedimiento objeto de la invencion es notable, ademas, porque la etapa que consiste en transmitir desde el terminal cliente al servidor una solicitud de reemision de al menos un paquete se ejecuta segun el protocolo UDP/IP.

Segun otro aspecto notable del procedimiento, objeto de la invencion, cada solicitud de reemision incluye al menos la identification y la direccion de destino del paquete o de los paquetes a reemitir.

El procedimiento, objeto de la invencion, es notable finalmente porque la etapa que consiste en transmitir sucesivamente cada uno de los paquetes se efectua mediante la transmision en modo unidifusion o multidifusion.

El servidor de transmision/recepcion de datos por paquetes en red IP entre este servidor y un terminal cliente, objeto de la invencion, es notable porque incluye al menos, ademas de los recursos de emision de paquetes de datos constitutivos de al menos un flujo de emision segun el protocolo UDP, un modulo generador y de transmision de datos de serialization de continuidad de los paquetes de datos emitidos, un modulo de memorization de una sucesion de un numero de paquetes de datos sucesivos enviados para al menos un flujo de datos transmitidos y un modulo de reception y de tratamiento de solicitudes de reemision de paquetes de datos aun presentes en el modulo de memorizacion de la sucesion de un numero de paquetes de datos sucesivos, controlando el modulo de recepcion y de tratamiento de las solicitudes de repeticion el modulo de memorizacion y de emision el modo unidifusion o multidifusion y dichos medios generadores y de transmision de datos de senalizacion en modo DCP.

El terminal cliente adaptado para la recepcion del flujo de datos por paquetes en red IP segun el protocolo UDP, acompanados de datos de senalizacion de continuidad del flujo segun el protocolo DCP, objeto de la presente invencion, es notable porque incluye, ademas, un modulo de detection de las rupturas del flujo mediante analisis de los datos de senalizacion de continuidad, un modulo de memorizacion de una sucesion de un numero de paquetes de datos sucesivos recibidos para al menos un flujo de datos, un modulo de transmision de solicitudes de reemision de datos a una direccion especlfica, operando dichos medios de transmision de solicitudes de reemision segun el protocolo UDP/IP y un modulo de reordenacion de los paquetes recibidos en el modulo de memorizacion de una sucesion de un numero de paquetes de datos sucesivos recibidos, teniendo en cuenta unos paquetes transmitidos en reemision.

La presente invencion se refiere igualmente a un mensaje de informacion para la transmision de datos por paquetes en red IP entre un servidor y un terminal cliente, estando formado este mensaje de informacion por una etiqueta DCP, que incluye al menos un numero de puerto UDP en el que transmitir las solicitudes de reemision de paquetes cuya discontinuidad de transmision ha sido revelada, una direccion IP a la que transmitir la solicitud de reemision de paquetes y el tamano de la memoria en numero de tramas/paquetes memorizados sucesivamente transmitidos.

La presente invencion se refiere por otro lado a una solicitud de reemision de paquetes transmitidos por un terminal cliente hacia un servidor de transmision de datos por paquetes en red IP, conteniendo esta solicitud al menos una identificacion del o de los paquetes de datos a reemitir y la direccion a la que se debe reenviar dicho o dichos paquetes.

La presente se refiere ademas a un programa informatico memorizado en un soporte de memorizacion de un ordenador o de un aparato dedicado constitutivo de un servidor de transmision/recepcion de datos por paquetes en red IP entre este servidor y un terminal cliente, y de modo que, durante la ejecucion de sus instrucciones, dicho programa informatico ejecuta las etapas de asignacion a cada paquete a transmitir de un Indice de continuidad de emision y la transmision sucesiva de cada uno de los paquetes segun el protocolo UDP y de su Indice de continuidad segun el protocolo DCP hacia ese terminal cliente segun el procedimiento de transmision/recepcion descrito en el presente documento anteriormente.

La presente se refiere igualmente a un programa informatico memorizado en un soporte de memorizacion de un ordenador constitutivo de un terminal cliente de transmision/recepcion de datos por paquetes en red IP transmitidos segun el protocolo UDP entre este terminal cliente y el servidor, y de modo que, durante su ejecucion, dicho programa informatico ejecuta las etapas de deteccion de cualquier ruptura de continuidad del flujo de paquetes recibidos a partir de su Indice de continuidad recibido segun el protocolo DCP y, tras la deteccion de una discontinuidad del flujo, la transmision desde el terminal cliente a dicho servidor de al menos una solicitud de reemision de al menos un paquete faltante, mientras que este o estos paquetes faltantes no se hayan recibido por este terminal cliente.

5

10

15

20

25

30

35

40

45

50

55

60

65

Estos diferentes objetos se comprenderan mejor con la lectura de la descripcion y la observacion de los dibujos a continuacion en los que:

- la figura 1 representa, a tltulo ilustrativo, un organigrama general de las etapas de implementacion del procedimiento de transmision/recepcion en tiempo real de datos por paquetes entre un servidor y un terminal cliente, objeto de la presente invencion;

- la figura 2a representa, a tltulo ilustrativo, un esquema funcional de la arquitectura de un servidor de transmision/recepcion de datos por paquetes en red IP de acuerdo con el objeto de la presente invencion;

- la figura 2b representa, a tltulo ilustrativo, un esquema funcional del modo operativo del servidor objeto de la invencion, tal como se ha representado en la figura 2a;

- la figura 3a representa, a tltulo ilustrativo, un esquema funcional de la arquitectura de un terminal cliente adaptada para la recepcion/transmision de datos por paquetes en red IP de acuerdo con el objeto de la invencion;

- la figura 3b representa, a tltulo ilustrativo, un esquema funcional del modo operativo del terminal cliente objeto de la invencion, representado en la figura 3a;

la figura 4a representa, a tltulo ilustrativo, la estructura de un mensaje de informacion para la transmision de datos por paquetes en red IP utilizando el protocolo DCP entre un servidor y un terminal cliente, de acuerdo con el objeto de la invencion;

- la figura 4b representa, a tltulo ilustrativo, la estructura de un mensaje de solicitud de reemision de paquetes transmitidos, utilizando el protocolo DCP, por un terminal cliente representado en la figura 3a, 3b hacia el servidor tal como el representado en la figura 2a, 2b, de acuerdo con el objeto de la invencion.

Se hara ahora una descripcion mas detallada del procedimiento de transmision en tiempo real de datos por paquetes en red IP entre un servidor S y un terminal cliente CT, de acuerdo con el objeto de la presente invencion, en relacion a la figura 1 y las figuras siguientes.

De una manera general, se considera que el servidor S es accesible por medio de la red IP mediante su direccion @S as! como el terminal cliente CT por medio de su direccion @CT.

El procedimiento, segun la invencion, consiste al menos, en el lado del servidor S, en asignar en una etapa 1, para cada paquete a transmitir, un Indice de continuidad de emision indicado por Ck.

La operation es indicada en la etapa A de la figura 1 por la relacion

Pk ® Ck, Pk.

En esta relacion Ck indica el Indice de continuidad de emision atribuido al paquete de datos a transmitir Pk.

De una manera mas especlfica, se indica que el Indice de continuidad Ck atribuido a cada paquete de datos Pk puede estar constituido por un valor numerico creciente, en funcion de la position del paquete emitido, y constituido de ese modo por una sucesion de datos de serialization de continuidad de los paquetes de datos emitidos.

A tltulo de ejemplo no limitativo, se indica que cada valor del Indice de continuidad Ck se puede calcular a partir de una funcion monotona creciente de la posicion de cada paquete por ejemplo. Este tipo de operacion es conocido en el estado de la tecnica y por esta razon no se describira en detalle.

La etapa A es seguida por dos etapas simultaneas B y C. La etapa B consiste en transmitir sucesivamente cada uno de los paquetes Pk y su Indice de continuidad Ck hacia el terminal cliente CT por intermedio de la direccion @CT de este ultimo. La etapa C consiste en memorizar cada uno de los paquetes Pk y sus Indices de continuidad Ck en la memoria del terminal servidor S.

En la etapa B de la figura 1, la operacion de transmision se indica mediante:

S DCP( CP ) , UDP( Pk) ® CT

En la relacion precedente:

- DCP(Ck) designa la transmision de cada Indice de continuidad Ck preferentemente, pero de manera no limitativa, segun el protocolo DCP; y

- UDP(Pk) designa la transmision de cada paquete Pk de manera preferente, pero no limitativa, segun el protocolo UDP.

- Cada paquete Pk se puede transmitir con su Indice de continuidad Ck o bien separadamente de este.

En la etapa C, la operacion de memorization, se representa por la relacion:

5

10

15

20

25

30

35

40

45

50

55

60

65

Memorizacion {PkCken la que N-X y N-1 designan las posiciones de los paquetes sucesivos y los valores de Indice de continuidad correspondientes memorizados al nivel del terminal servidor S.

Segun un modo de implementacion preferible no limitativo del procedimiento objeto de la invencion, la etapa de memorizacion representada en la etapa C en el lado del servidor S se puede ejecutar ventajosamente por medio de una memoria, por ejemplo una memoria tampon de tipo FIFO o una memoria cache, cuyo tamano esta adaptado a la memorizacion de los paquetes sucesivos Pk transmitidos en el lado del servidor S as! como unos Indices de continuidad Ck que se le han asociado durante la etapa A.

A continuacion de las etapas A, B y C de la figura 1 ejecutadas en el servidor S, el procedimiento, objeto de la invencion, consiste en el lado del terminal cliente CT en ejecutar dos etapas simultaneas G y J. Consistiendo la etapa G en detectar cualquier ruptura de continuidad del flujo de paquetes recibidos Pk a partir de los Indices de continuidad asociados a cada paquete recibido as! como en asegurar que el paquete recibido Pk no es un paquete reemitido con el fin de no tener en cuenta la ruptura de continuidad generada por la recepcion de paquetes repetidos.

En la etapa G, la operation que consiste en detectar cualquier ruptura de continuidad del flujo de paquetes recibidos esta indicada de manera simbolica:

^Ck + 1 ^ Ck+1?

Mediante esta notation, se comprende que la operacion de detection consiste, a partir de la funcion monotona inversa a por ejemplo la utilizada en la emision, en verificar que el Indice de continuidad de la position k+1 indicada por Ck+1 se ha recibido despues de la recepcion del valor del Indice de continuidad Ck y por tanto inmediatamente despues del paquete Pk, siendo denotada la indication de inmediatez posterior de la recepcion por Ck + 1.

Se comprende de ese modo que la etapa G ejecutada en el lado del terminal cliente CT, de deteccion de cualquier ruptura de continuidad se efectua mediante analisis del unico flujo DCP que permite la transmision de los Indices de continuidad al nivel del terminal cliente CT.

En la etapa G, la operacion que consiste en verificar que el paquete recibido es un paquete reemitido bajo demanda es indicada de manera simbolica:

Ck e (CPk \ CRk)

Mediante esta notacion, se comprende que la operacion de verification consiste en verificar que el Indice de continuidad del paquete recibido Ck no pertenece al conjunto de los identificadores de los paquetes perdidos durante la transmision. Este conjunto se define como el conjunto de los paquetes emitidos por el terminal servidor CPk menos el conjunto de los Indices de continuidad de los paquetes ya presentes en la memoria del terminal cliente CT: CRk.

Tras la deteccion de una discontinuidad del flujo real, es decir cuando se verifican las condiciones comprobadas en la etapa G, entonces existe tras la recepcion del Indice de continuidad Ck, designado Indice de continuidad de ruptura Ckr, una discontinuidad del flujo. La discontinuidad del flujo puede afectar a varios paquetes recibidos, de valor de Indice de continuidad indicado por {Ck+1, ..., Ck+p} por ejemplo. El procedimiento de la invencion consiste en una etapa H para transmitir desde el terminal cliente CT al servidor S, por medio del retorno representado en llnea de puntos en la etapa I, una solicitud de reemision indicada en la etapa H:

RR (Ckr, @CT) hacia el servidor S es decir a la direction @S de este ultimo.

Esta operacion de retorno en la etapa I y de transmision de la solicitud antes mencionada se efectua en tanto que el o los paquetes faltantes Ck+1, Ck+p no haya o no hayan sido recibidos por el terminal cliente CT y en tanto que el o los paquetes faltantes Ck+1, Ck+p no esten obsoletos, es decir que el Indice de continuidad Ckr del paquete a reemitir este comprendido entre Cn-1 y Cn-x, los Indices de continuidad que acotan los Indices de continuidad de los paquetes presentes en la memoria del terminal cliente.

La tapa de retorno I simbolizada por la flecha de puntos se convierte en la etapa D al nivel del servidor S.

La etapa J del terminal cliente, simultanea con la etapa G, consiste en analizar la continuidad del paquete recibido Ck con el fin de detectar los paquetes recibidos y memorizados as! como los paquetes no obsoletos.

En la etapa J las operaciones que consisten en verificar la validez de los paquetes recibidos son indicadas de manera simbolica:

(Ck < Cn-x) v (Ck e CRk)

5

10

15

20

25

30

35

40

45

50

55

60

65

Mediante esta notacion, se comprende que un paquete es considerado como inutil si su Indice de continuidad Ck es mas antiguo que el Indice de continuidad del paquete mas antiguo memorizado en el lado del terminal cliente Cn-x o si el Indice de continuidad del paquete recibido pertenece ya al conjunto CRk de los Indices de continuidad de los paquetes ya memorizados en el lado del terminal cliente.

Tras una respuesta positiva a las comprobaciones de la etapa J el paquete inutil se destruira en la etapa K.

Por supuesto, tras una respuesta negativa a las comprobaciones de la etapa J de la figura 1, el procedimiento objeto de la invencion consiste en una etapa E de ordenacion y posteriormente de memorization del paquete de datos Rk recibido.

La operation de memorizacion correspondiente se representa mediante la relation:

Memorizacion {RkCk}en la que N-X y N-1 designan las posiciones de los paquetes sucesivos y los valores de Indice de continuidad correspondientes memorizados al nivel del terminal cliente CT.

Segun un modo de implementation preferido no limitativo del procedimiento objeto de la invencion, la etapa de memorizacion representada en la etapa E en el lado del terminal cliente CT puede ejecutarse ventajosamente por medio de una memoria, por ejemplo una memoria tampon de tipo FIFO o una memoria cache, cuyo tamano esta adaptado a la memorizacion de los paquetes sucesivos Rk recibidos en el lado del terminal cliente y de unos Indices de continuidad Ck que le corresponden.

Terminada la etapa E, es decir que el paquete ha salido de la memoria, por ejemplo de tipo FIFO, utilizada en la etapa E, el paquete prosigue el proceso de tratamiento simbolizado por la etapa F.

La etapa D en el lado del terminal servidor corresponde al analisis de la solicitud de petition de repetition enviada por el terminal cliente CT al terminal servidor S. La etapa D consiste en detectar si el o los paquetes identificados en la solicitud de reemision estan aun presentes en la memoria del servidor. Esta detection se puede indicar de manera simbolica:

Cn-1 > Ck > Cn-x

Mediante esta notacion, se comprende que la operacion consiste en verificar que el Indice de continuidad de position k que designa el paquete a repetir debe estar comprendido entre el Indice de continuidad Cn del ultimo paquete anadido a la FIFO y el Indice de continuidad Cn-x del paquete mas antiguo anadido a la FIFO.

Tras una respuesta negativa de la prueba de la etapa D de la figura 1, el procedimiento objeto de la invencion consiste en ignorar la solicitud enviada por el cliente CT al terminal servidor S.

Tras una respuesta positiva a la prueba de la etapa D de la figura 1, el procedimiento objeto de la invencion consiste en una etapa L de reemision de los paquetes designados en la solicitud transmitida durante la etapa I por el terminal cliente CT al terminal servidor S. Segun un modo de implementacion preferido no limitativo del procedimiento objeto de la invencion, la etapa de reemision representada en la etapa L del lado del servidor S puede ejecutarse ventajosamente mediante la busqueda de los paquetes a reemitir en la memoria utilizada en la etapa C y posteriormente en retransmitir estos mismos paquetes por medio de la etapa B del terminal cliente CT.

Con el fin de permitir la ejecucion fluida de la implementacion del procedimiento objeto de la invencion esta consiste, tal como se ha representado en la figura 1 en el lado del terminal cliente CT, por un lado, y en el lado del servidor S, por otro lado, en memorizar de modo continuo una misma pluralidad de paquetes sucesivos a transmitir, respectivamente recibidos, acompanados de su Indice de continuidad.

Las operaciones correspondientes se representan en la etapa C a nivel del servidor S, respectivamente en la etapa E a nivel del terminal cliente CT.

El funcionamiento general y el modo operativo del procedimiento objeto de la invencion, tal como se ha representado en la figura 1 es entonces el siguiente, cuando se utilizan el protocolo UDP que permite la transmision de los paquetes sucesivos Pk y el protocolo DCP que permite la transmision de los Indices de continuidad Ck.

Una de las vlas encamina el flujo en tiempo real desde el servidor S hacia el terminal cliente CT mediante el protocolo UDP y la otra via permite al terminal cliente CT enviar al servidor S especificado en el flujo de la solicitud la de reemision de paquetes por medio del protocolo UDP.

Los Indices de continuidad contenidos por el flujo transmitido por el protocolo DCP son utilizados para detectar las rupturas del flujo en el lado del terminal cliente CT.

5

10

15

20

25

30

35

40

45

50

55

60

65

Cuando este ultimo detecta una ruptura de continuidad de transmision de los paquetes Pk, solicita entonces la reemision de los paquetes no recibidos enviando una solicitud al servidor S, la solicitud RR (Ckr, @CT) anteriormente mencionada en la etapa H de la figura 1. El servidor S retransmite entonces los paquetes faltantes.

Con el objetivo de conservar la continuidad del flujo en tiempo real, la memorizacion de los datos recibidos en el lado del terminal cliente CT en la espera de la recepcion de los paquetes perdidos, as! como la memorizacion de los datos transmitidos en el lado del servidor S, permite obtener la continuidad antes mencionada.

Esta operacion se ejecuta gracias a la implementacion de memorias, por ejemplo de memorias tampon de tipo FIFO, tanto en el lado del servidor S como en el lado del terminal cliente CT.

Segun una caracterlstica del procedimiento objeto de la invencion, la memoria utilizada, tanto en el lado del servidor S como en el lado del terminal cliente CT, se puede definir desde el punto de vista de su tamano en numero de paquetes y funcion de los parametros de transmision de la red de transmision de los paquetes considerados.

De una manera mas especlfica, el tamano de la memoria utilizada, en el lado del servidor S y en el lado del cliente CT, puede convertirse entonces en adaptativa con el objetivo particularmente ventajoso de optimizar la compensation de ruptura de transmision de paquetes de datos sucesivos, al tiempo de la transmision de ida y vuelta cercano entre el terminal cliente CT y el servidor S, tal como se describira posteriormente en la description.

Se indica sin embargo que la election del tamano de la memoria utilizada en el lado del terminal cliente influye en el tiempo de retardo introducido en la recepcion.

A tltulo de ejemplo no limitativo, el tamano de la memoria se puede determinar en funcion del tiempo de transmision de ida y vuelta antes mencionado entre el servidor S y el terminal cliente CT y el tamano maximo de las rupturas de transmision que se desea poder corregir. El tiempo de transmision de ida y vuelta entre el terminal cliente y el terminal servidor puede medirse mediante unas operaciones clasicas en el lado del servidor por ejemplo, mediante la emision de las ordenes apropiadas, lo que no se describira con mas detalle por esta razon.

De una manera mas especlfica, se indica que la transmision de las informaciones, necesaria al cliente para efectuar las solicitudes de repetition, entre el servidor S y el terminal cliente CT se efectua mediante la transmision de una etiqueta DCP de information. Esta etiqueta puede incluir al menos la direction de destino de cualquier solicitud de reemision de paquetes, es decir la direccion @S del servidor S, el tamano de memoria de la memoria de memorizacion de la pluralidad de paquetes sucesivos.

Tal como se ha mencionado anteriormente en la descripcion, este tamano de memoria se puede determinar a nivel del servidor S de manera adaptativa y posteriormente configurarse a nivel del terminal cliente considerado CT.

Finalmente, en lo que se refiere a la transmision desde el terminal cliente al servidor S de una solicitud de revision de al menos un paquete, esta operacion representada en la etapa I de la figura 1, se ejecuta ventajosamente segun el protocolo UDP/IP.

Por supuesto, cada solicitud de reemision incluye el identificador del primer paquete a reemitir, es decir el Indice de continuidad Ckr para el que se ha detectado la ruptura, el numero de paquetes a reemitir, as! como la direccion de destino del o de los paquetes a reemitir, es decir la direccion @CT del terminal cliente CT.

En lo que se refiere a la etapa que consiste en transmitir sucesivamente cada uno de los paquetes Pk, esta se puede efectuar ventajosamente mediante la transmision en modo unidifusion o incluso en modo multidifusion.

Se realizara ahora una descripcion mas detallada del servidor de transmision de datos por paquetes en red IP en un terminal cliente que permite la implementacion del procedimiento objeto de la presente invencion, en relation con las figuras 2a y 2b, respectivamente 3a y 3b.

Con referencia a la figura 2a, se indica que el servidor de transmision de datos por paquetes en red IP objeto de la invencion, servidor S, entre este servidor y un terminal cliente CT, incluye de manera clasica unos organos de entrada/salida indicados I/O, una unidad central de proceso CPU, un modulo de control de acceso AC un servidor que permite gestionar cualquier solicitud desde el punto de vista del acceso y seguridad a un servicio o aplicacion transmitida por este servidor S.

El conjunto es gestionado por un modulo de programas M0 que permite particularmente asegurar la funcion servidor para una o varias aplicaciones consideradas. El modulo de programas M0 permite, particularmente, gestionar la transmision de paquetes de datos Pk constitutiva de al menos un flujo de emision para una aplicacion considerada.

Ademas de los elementos de tipo clasico antes mencionados, el servidor de transmision de datos por paquetes en red IP objeto de la invencion, incluye un modulo M1 generador de transmision de datos de serialization de continuidad de los paquetes de datos Pk emitidos.

5

10

15

20

25

30

35

40

45

50

55

60

65

El modulo Mi antes mencionado puede estar constituido por un modulo de software que ejecute por ejemplo la funcion monotona creciente que permite calcular los valores sucesivos del Indice de continuidad Ck de cada uno de los paquetes Pk emitidos.

Ademas, tal como se ha representado en la figura 2a, incluye un modulo de memorizacion M2X de una sucesion de un numero de paquetes de datos sucesivos enviados para al menos un flujo de datos transmitidos, siendo ejecutada la memorizacion preferentemente mediante la memorizacion de los paquetes Pk en un numero X de paquetes segun la relacion representada en la etapa C de la figura 1.

Finalmente, el servidor S objeto de la invencion, comprende un modulo M3 de recepcion y de procesamiento de solicitudes de reemision de paquetes de datos Pk aun presentes en el modulo de memorizacion M2X de la sucesion de un numero de paquetes de datos sucesivos Pk.

El modulo de memorizacion M2X esta constituido preferentemente por una memoria, por ejemplo una memoria tampon de tipo FIFO, cuyo tamano define la capacidad de reemision del servidor S en numero de paquetes de datos, y, por supuesto, en duracion de la reemision.

El modulo M3 de recepcion y de procesamiento de las solicitudes antes mencionado esta constituido ventajosamente por un modulo de software que permite procesar el mensaje de solicitud anteriormente descrito en la descripcion. El modulo de recepcion y de procesamiento M3 controla los recursos de emision de paquetes y el modulo M2X que contiene los paquetes necesarios para la reemision.

Ademas, tal como se ha mencionado anteriormente en la descripcion, el modulo M3, de recepcion y de procesamiento de las solicitudes, controla el modulo de emision de los paquetes Pk sucesivos que deben reemitirse, o bien en modo unidifusion, o bien en modo multidifusion.

El modo operativo del servidor S objeto de la invencion representado en la figura 2a, se describira ahora en relacion con la figura 2b.

El servidor S tiene como papel:

- insertar en el flujo de los datos de senalizacion que el terminal cliente CT utiliza para transmitir unas solicitudes de reemision de paquetes Pk;

- conservar en la memoria tampon, memoria FIFO, una parte del flujo ya enviado. Se observa de manera particularmente ventajosa que es necesaria una unica memoria por flujo emitido por el servidor y, esto cualquiera que sea el numero de terminales clientes CT que reciben el flujo considerado;

El tamano de la memoria M2X determina de hecho la capacidad de reemision del servidor S. Cuanto mas grande sea la memoria en tamano mas rupturas del enlace que pueden corregirse y son entonces mayores.

A tltulo de ejemplo no limitativo, si el servidor S y el terminal cliente CT almacena por ejemplo 10 segundos de flujos de paquetes de datos transmitidos y el enlace ida + retorno entre el terminal cliente CT y el servidor S necesita 2 segundos, entonces es posible corregir sin perdida unas rupturas de transmision que lleguen hasta 8 segundos;

- tratar las demandas de reemision de paquetes Pk enviados por los terminales clientes CT y reemitir unos paquetes aun presentes en la memoria situada en el terminal servidor.

En el caso de una emision multidifusion, de los paquetes aun presentes en la memoria tampon, si varios terminales CT vuelven a solicitar el mismo paquete, el servidor puede reemitir los datos en modo multidifusion en lugar de reemitirlos para cada terminal cliente CT.

El modo operativo antes mencionado y representado en la figura 2b en la que M3 representa al modulo de recepcion y de procesamiento de las solicitudes de reemision de paquetes de datos, constituido en un gestor de repeticion de los paquetes bajo la forma de un software adaptado. El modulo M3 antes mencionado controla en particular la memoria M2X para lectura del Indice o Indices de continuidad de los paquetes o, llegado el caso, unos paquetes en si mismos a reemitir y controla igualmente el modulo de reemision de los paquetes M0.

Se dara ahora una descripcion mas detallada de un terminal cliente de acuerdo con el objeto de la invencion y adaptado para la recepcion de flujos de datos por paquetes en red IP acompanados de datos de senalizacion de continuidad del flujo emitidos por un servidor S tal como el representado en las figuras 2a y 2b, en relacion con las figuras 3a y 3b.

De ese modo y tal como se ha representado en la figura 3a, el terminal cliente CT objeto de la invencion, incluye de manera clasica una unidad de entrada/salida I/O conectada a una unidad central de proceso CPU que controla una memoria de programas M'0 que permite gestionar los intercambios de datos entre cualquier terminal cliente CT y cualquier terminal o servidor conectado a la red IP.

5

10

15

20

25

30

35

40

45

50

55

60

65

El terminal CT objeto de la invencion, incluye ademas de manera particularmente ventajosa, un modulo M'i de deteccion de las rupturas del flujo mediante analisis de los datos de senalizacion de continuidad, operando el modulo M'i antes mencionado, tal como se ha descrito anteriormente en la descripcion, en relacion con la figura 1 en las etapas G y J. Este modulo puede estar constituido por un modulo de software ejecutado por la unidad central CPU.

Incluye ademas un modulo M'2x de memorizacion de una sucesion de un numero de paquetes de datos sucesivos recibidos para al menos un flujo de datos determinado. El modulo M'2x constituye la memoria anteriormente descrita en la descripcion e implementada en la etapa E de la figura 1.

Incluye igualmente tal como se ha representado en la misma figura 3a un modulo M'3 de transmision de solicitudes de reemision de paquetes de datos a una direccion especlfica a la direccion del servidor @S anteriormente descrita en la descripcion. El modulo M'3 permite construir los mensajes de solicitud de reemision RR (Ckr, @CT) anteriormente descritos en relacion con la figura 1.

Finalmente, el terminal cliente CT objeto de la invencion, incluye un modulo M'4 de reordenacion de los paquetes recibidos en el modulo de memorizacion M'2x de la sucesion del numero de paquetes de datos sucesivos recibidos, teniendo en cuenta unos paquetes transmitidos en reemision.

Segun un aspecto notable del terminal cliente CT objeto de la invencion, el modulo M'3 de transmision de solicitudes de reemision opera segun el protocolo UDP/IP para asegurar la transmision de las solicitudes de reemision antes mencionadas.

El modo operativo del terminal cliente CT se describira ahora en relacion con la figura 3b.

El terminal cliente CT tiene por objeto:

- detectar una rupturas en el flujo analizando los Indices de continuidad tal como se ha descrito en relacion con la figura 1 en la etapa G;

- enviar unas solicitudes de repeticion a la direccion especificada en el flujo, es decir a la direccion @S anteriormente descrita en relacion con la figura 1. Estas solicitudes de repeticion utilizan ventajosamente el protocolo UDP/IP, al no asegurar este protocolo la buena recepcion de las solicitudes, estas ultimas deben repetirse hasta la recepcion de los paquetes solicitados o la obsolescencia de los datos faltantes. La frecuencia de repeticion de las solicitudes de reemision puede determinarse entonces en funcion del tipo de red y de las cualidades intrlnsecas de esta ultima;

- memorizar en la memoria los datos es decir los paquetes sucesivos Rk recibidos por el terminal cliente y sus Indices de continuidad con el fin de asegurar la continuidad del flujo en tiempo real. Despues de la ruptura de la transmision del flujo de datos, la memoria utilizada a nivel del terminal cliente CT se reconstituye rapidamente, con una velocidad muy superior a la estrictamente util para encaminar los paquetes de datos sin error;

- reordenar los paquetes recibidos en la memoria porque los paquetes repetidos son recibidos con retardo. En caso de repeticiones multiples, el terminal CT debe suprimir ademas los paquetes ya recibidos.

Se representa en la figura 3b un diagrama que representa el modo operativo del terminal cliente CT, en la que los modulos M'i y M'4 constituidos por unos modulos de software permiten asegurar el analisis de la continuidad del flujo. Los modulos antes mencionados permiten reorganizar la sucesion de los paquetes memorizados en el modulo de memorizacion M'2x y por supuesto controlar las solicitudes de repeticion por medio del modulo M'3.

Para la implementacion del procedimiento del servidor S y del terminal cliente CT, objetos de la presente invencion, tal como los descritos anteriormente en la descripcion, se indica que estos ultimos son tanto mas eficaces en cuanto la red de transmision de tipo IP soporte unas velocidades superiores, al menos momentaneamente, a las velocidades utilizadas para el transporte de los paquetes de datos Pk esto con el objetivo de retransmitir los paquetes perdidos antes de que la memoria del terminal cliente CT este vacla.

Ademas, el retardo inducido por la implementacion de la memoria, en el servidor S y en el terminal cliente CT, se une con el retardo de la memoria utilizada para absorber la perturbacion de la red de transmision IP.

Si el tamano de la memoria del servidor S se especifica en el flujo de transmision de datos lo que, de acuerdo con el objeto de la invencion, se realiza y, en particular, de manera adaptativa, el terminal cliente CT esta entonces en condiciones de adaptar el tamano de su memoria a un tamano sensiblemente identico, o llegado el caso ligeramente inferior, con el fin de tener en cuenta el retardo de reemision de los paquetes de datos no recibidos.

El terminal cliente CT puede entonces adaptarse automaticamente a los tipos de flujos de datos recibidos. Detectando en el flujo de paquetes de datos transmitidos unas informaciones que identifican la fuente de repeticion, es decir el servidor S por ejemplo, el terminal cliente CT antes mencionado activa automaticamente la accion de repeticion de los paquetes perdidos. Si no, en el caso contrario, este ultimo adopta entonces el funcionamiento que utiliza el protocolo dCp estandar.

5

10

15

20

25

30

35

40

45

50

55

60

65

Se realizara ahora en relacion con la figura 4a, una descripcion mas detallada del mensaje de informacion para la transmision de datos por paquetes en red IP entre el servidor S y un terminal CT anteriormente descritos en la descri pcion.

Con referencia a la figura 4a antes mencionada, se indica que el mensaje de informacion que permite la transmision de los datos de informacion de continuidad del flujo esta formado por una etiqueta DCP tal como la representada en la figura 4a por ejemplo.

La etiqueta antes mencionada incluye al menos un nombre de etiqueta segun un campo que debe estar codificado en 4 octetos “AUDP” por ejemplo, correspondiendo este nombre a un campo obligatorio de la norma DCP.

La etiqueta DCP debe incluir ademas, tal como se ha representado en los dibujos de la figura 4a, un campo de longitud de etiqueta que da la longitud de la etiqueta en bits. La etiqueta tiene una longitud constante de 64 bits segun el campo obligatorio de la norma DCP antes citada.

Ademas, la etiqueta incluye igualmente un numero de puerto UDP en el que transmitir las solicitudes de reemision de paquetes cuya discontinuidad de transmision ha sido revelada. Este numero de puerto designado PORT en la figura 4a puede estar codificado en 16 bits por ejemplo.

La etiqueta incluye ademas un campo de direccion IP al que transmitir las solicitudes de reemision de paquetes. Esta direccion designada IP servidor puede estar codificada en 32 bits y corresponde a la direccion IP a la que enviar las solicitudes de reemision de paquetes. Esta direccion puede ser diferente de la del servidor S del que proceden los flujos.

Finalmente, tal como se ha representado en la figura 4a, la etiqueta antes mencionada incluye un campo codificado sobre 16 bits que representa el tamano de la memoria. El tamano de la memoria se puede definir en numero de tramas disponibles. El tipo de tramas puede ser PFT o AF en funcion del modo de transmision elegido, de acuerdo con las disposiciones de la norma DCP.

La utilizacion de una etiqueta DCP permite convertir el flujo de datos transmitido en compatible con unos terminales cliente CT que no se hacen cargo de la solicitud de reemision de los paquetes perdidos.

Con el fin de incrementar la eficacia de la implementacion del procedimiento, por supuesto del servidor S y de cualquier terminal CT de acuerdo con el objeto de la invencion, la senalizacion en el flujo puede contener ventajosamente el tamano de memoria de la memoria utilizada en el lado del servidor S. Esto permite evitar las solicitudes de repetition de datos que ya no estan presentes en la memoria. Se comprende, en particular, que a partir de un tamano de memoria sustancialmente identico en una y otra de las memorias que implementan las etapas C y E del procedimiento tal como se ha representado en la figura 1, es posible tambien discriminar los paquetes Pk y por supuesto su Indice de continuidad que no estan presentes en la memoria.

Finalmente, con el fin de limitar la velocidad de datos necesaria para la implementacion del procedimiento objeto de la invencion, estas informaciones pueden no estar presentes en cada paquete del flujo. Sin embargo, y de acuerdo con un aspecto notable del procedimiento objeto de la invencion, esos datos estan entonces presentes con una frecuencia suficiente para que el terminal cliente CT pueda utilizarlos rapidamente.

En una variante de implementacion, el mismo proceso se puede aplicar al protocolo RTP/IP. Las informaciones enviadas por el servidor para permitir a los clientes efectuar unas solicitudes de repeticion estaran incluidas en los encabezados RTP en el formato previsto por este protocolo. Las informaciones a incluir son:

- la direccion IP y el puerto al que dirigir las solicitudes de repeticiones

- el tamano de la FIFO en el lado del servidor

El Indice de continuidad utilizado en el lado del cliente para detectar las rupturas es el campo “sequence number” en 16 bits, del encabezado RTP como esta previsto en la norma.

La identification de los paquetes a repetir se efectua utilizando el campo “sequence number” del encabezado RTP. Los mensajes de solicitud de repeticion dirigidos desde el terminal cliente al terminal servidor contienen entonces por tanto los datos siguientes:

- la direccion IP y el puerto al que deberan enviarse los paquetes a repetir

- el identificador del primer paquete de la ruptura: valor en 16 bis del campo “sequence number”.

- el numero de paquetes perdidos en la ruptura (codificado en 16 bits)

Igualmente, se realizara ahora en relacion con la figura 4b una descripcion mas detallada de una solicitud de reemision de paquetes RR (Ckr, @CT).

5

10

15

20

25

30

35

40

45

50

55

60

Con referenda a la figura antes mencionada, cualquier solicitud de reemision de paquetes transmitida por un terminal cliente CT hacia un servidor de transmision S de datos por paquetes en red IP de acuerdo con el objeto de la invention, es notable porque una solicitud de ese tipo contiene al menos una identification del o de los paquetes de datos a reemitir, en particular el Indice de continuidad del primer paquete perdido, cuando, en particular, este Indice se calcula a partir de la funcion monotona creciente precedentemente mencionada en la description, el numero de paquetes a repetir a partir de este Indice y, por supuesto, la direction a la que debe reenviarse el o los paquetes considerados, es decir la direccion CT del terminal cliente que solicita la repetition.

Sin embargo, se entiende por supuesto que los campos anteriormente mencionados de la solicitud de reemision no son los unicos, el procedimiento, servidor S y el terminal cliente CT objetos de la presente invencion, pueden implementarse de manera particularmente ventajosa en las condiciones indicadas en el presente documento a continuation.

En efecto, la fuente de reemision de paquetes puede ser diferente al servidor S inicial.

Por ejemplo, en el caso de una difusion monodireccional del flujo, tal como la realizada por un satelite u otros por ejemplo, es posible especificar la direccion de un servidor secundario en la red, el cual esta encargado entonces de distribuir las tramas perdidas por ejemplo a traves de un enlace por red telefonica conmutada RTC, red digital de servicios integrados RDSI o finalmente cualquier tipo de red por ejemplo.

El terminal cliente CT, cuando este ultimo ha detectado la perdida de uno o varios paquetes Pkr, debe reenviar entonces una solicitud de repeticion al servidor S.

Esta petition o solicitud de repeticion debe contener entonces al menos los dos tipos de information antes mencionados y el paquete puede estar estructurado de la manera indicada a continuacion:

- paquete o etiqueta: nombre de la etiqueta, nombre de la etiqueta codificado en 4 octetos por ejemplo y en el caso de la figura 4b, AREP a tltulo de ejemplo no limitativo;

- longitud del paquete: el paquete tiene una longitud variable de 80, 104 o 132 bits en funcion del modo de transmision elegido;

- PORT: codificado en 16 bits, numero del puerto al que debera efectuarse la repeticion;

- IP cliente: codificado en 32 bits, numero IP al que debera efectuarse la repeticion, es decir en definitiva la

direccion @CT del terminal cliente;

- PFT: campo codificado en 1 bits, marcador utilizado para realizar que se utiliza el modo PFT con fragmentation y que el campo F Indice esta por lo tanto presente;

- campo de direccion Adr: codificado en 1 bit, marcador utilizado para senalizar que la direccion se utiliza y que el

campo PFT destinatario y PFT Dest estan presentes. Esta option no es utilizable mas que si el campo PFT es

valido, valor del marcador PFT=1 estando vinculada la direccion al PFT;

- campo del numero de fragmentos NbFrag codificado en 14 bits AF o PF en funcion del modo a repetir a partir del Indice de continuidad definido por los campos SEQ y Findex. Por ejemplo, si el numero de fragmentos NbFrag = 3 y si PsEQ = 50 los paquetes Pk de position k = 50, 51 a 52 deben repetirse;

- campo SEQ codificado en 16 bits, este campo corresponde al campo SEQ del paquete AF a repetir si el campo PFT es de valor 0. Si el campo PFT tiene el valor 1, el campo SEQ corresponde al campo PSEQ del paquete Pf a repetir. El campo SEQ es por tanto una parte utilizada para la identificacion del flujo que contiene los paquetes a repetir;

- campo Findex: campo codificado en 24 bits. Este campo es opcional. No esta presente mas que si el campo PFT es de valor 1. Este campo contiene el valor del campo Findex del paquete PF a repetir. Se utiliza para la identificacion del primer paquete a repetir;

- PFT Dest: campo codificado en 16 bits. Este campo es igualmente opcional. No esta presente mas que si el campo Adr es igual a 1. El campo PFT Dest contiene el valor del campo Dest de la direccion PFT del paquete a repetir. Este campo se utiliza para la identificacion del primer paquete repetir;

- campo PFT Src codificado en 16 bits. Este campo es opcional. No esta presente mas que si el campo Adr es de valor 1. El campo PFT Src contiene el valor del campo Src de la direccion PFT del paquete a repetir. Este campo se utiliza para la identificacion del primer paquete a repetir.

Finalmente, la invencion cubre un programa informatico codificado de manera monolltica o modular y memorizado en un soporte de memorization de un ordenador o de un aparato dedicado constitutivo de un servidor de transmision/recepcion de datos por paquetes en red IP entre este servidor y un terminal cliente.

El programa informatico objeto de la invencion, es notable porque, durante su ejecucion este programa informatico ejecuta las etapas de asignacion a cada paquete a transmitir de un Indice de continuidad de emision, y de transmision sucesiva de cada uno de los paquetes y de su Indice de continuidad hacia el terminal cliente, tal como se ha descrito anteriormente en la descripcion en relation con la figura 1.

La invencion cubre igualmente un programa informatico codificado de manera monolltica o modular y memorizado en un soporte de memorizacion de un ordenador constitutivo de un terminal cliente de transmision/recepcion de datos por paquetes en red IP entre este terminal cliente y un servidor.

5 Este programa informatico es notable porque, durante su ejecucion, este programa informatico ejecuta las etapas de deteccion de cualquier ruptura de continuidad del flujo de paquetes recibidos a partir de los Indices de continuidad asociados a cada paquete recibido, y, tras la deteccion de una discontinuidad del flujo, la transmision desde el terminal cliente al servidor antes mencionado de al menos una solicitud de reemision de al menos un paquete faltante, en tanto que este o estos paquetes faltantes no sean recibidos por el terminal cliente.

10

Claims (14)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   55

   60

   65

   REIVINDICACIONES

   1. Procedimiento de transmision/recepcion en tiempo real de datos por paquetes en red IP entre un servidor y un terminal cliente, caracterizado por que consiste al menos en,

   en el lado del servidor:

   - asignar (A) a cada paquete a transmitir un Indice de continuidad de emision;

   - transmitir (B) sucesivamente cada uno de los paquetes segun el protocolo UDP y su Indice de continuidad segun el protocolo DCP hacia dicho terminal cliente; y,

   en el lado del terminal cliente:

   - detectar (G) cualquier ruptura de continuidad del flujo de paquetes recibidos a partir de los Indices de continuidad asociados a cada paquete recibido; y, tras la detection de una discontinuidad del flujo,

   - transmitir (L) desde el terminal cliente al servidor al menos una solicitud de reemision de al menos un paquete faltante, en tanto que dicho al menos un paquete faltante no haya sido recibido por dicho terminal cliente.
2. 2. Procedimiento segun la reivindicacion 1, caracterizado por que consiste ademas, en el lado del terminal cliente y del servidor en memorizar (C) continuamente una misma pluralidad de paquetes sucesivos a transmitir, respectivamente recibidos, acompanados de su Indice de continuidad.
3. 3. Procedimiento segun la reivindicacion 1 o 2, caracterizado por que la etapa de deteccion de cualquier ruptura de continuidad se efectua mediante analisis del unico flujo DCP.
4. 4. Procedimiento segun una de las reivindicaciones 2 a 3, caracterizado por que dicha etapa que consiste en memorizar continuamente, consiste en memorizar cada paquete de dicha pluralidad de paquetes sucesivos en una memoria.
5. 5. Procedimiento segun la reivindicacion 4, caracterizado por que el tamano de dicha memoria en numero de paquetes es funcion de los parametros de transmision de la red de transmision de los paquetes.
6. 6. Procedimiento segun la reivindicacion 5, caracterizado por que el tamano de dicha memoria es adaptativo, lo que permite optimizar la compensation de las rupturas de transmision al tiempo de transmision de ida y vuelta cercano entre el terminal cliente y el servidor.
7. 7. Procedimiento segun una de las reivindicaciones 1 a 6, caracterizado por que la transmision de dichos Indices de continuidad se efectua mediante la transmision a intervalos determinados de una etiqueta DCP, que contiene unas informaciones que incluyen al menos la direction de destino de cualquier solicitud de reemision de paquetes, el tamano de la memoria de memorization de dicha pluralidad de paquetes sucesivos.
8. 8. Procedimiento segun una de las reivindicaciones 1 a 7, caracterizado por que dicha etapa que consiste en transmitir desde el terminal cliente al servidor una solicitud de reemision de al menos un paquete se ejecuta segun el protocolo UDP/IP.
9. 9. Procedimiento segun la reivindicacion 8, caracterizado por que cada solicitud de reemision incluye al menos:

   - el identificador del o de los paquetes a reemitir;

   - la direccion de destino del o de los paquetes a reemitir.
10. 10. Procedimiento segun una de las reivindicaciones 1 a 9, caracterizado por que la etapa que consiste en transmitir sucesivamente cada uno de los paquetes se efectua mediante la transmision en modo unidifusion o multidifusion.
11. 11. Servidor de transmision/recepcion de datos por paquetes en red IP entre este servidor y un terminal cliente, caracterizado por que dicho servidor incluye al menos, ademas de los medios de emision de paquetes de datos constitutivos de al menos un flujo de emision segun el protocolo UDP,

    - unos medios (M1) generadores y de transmision de un Indice de continuidad de emision para cada paquete a emitir;

    - unos medios de memorizacion (M2x) de una sucesion de un numero de paquetes de datos sucesivos enviados para al menos un flujo de datos transmitidos, estando constituidos dichos medios de memorizacion por una memoria cuyo tamano define la capacidad de reemision del servidor en numero de paquetes de datos y en duration de la reemision;

    - unos medios de reception y de procesamiento (M3) de las solicitudes de reemision de paquetes de datos aun presentes en los medios de memorizacion de la sucesion de un numero de paquetes de datos sucesivos, controlando dichos medios de recepcion y de procesamiento a dichos medios de emision en modo unidifusion o multidifusion y a dichos medios generadores y de transmision de los Indices de continuidad en modo DCP.

    5

    10

    15

    20

    25
12. 12. Terminal cliente adaptado para la transmision/recepcion de flujos de datos por paquetes en red IP segun el protocolo UDP, acompanados del Indice de continuidad del flujo segun el protocolo DCP, emitidos por un servidor, caracterizado por que dicho terminal cliente incluye ademas:

    - unos medios de deteccion (M'i) de las rupturas de flujos mediante analisis de los Indices de continuidad;

    - unos medios de memorizacion (M'2x) de una sucesion de un numero de paquetes de datos sucesivos recibidos por al menos un flujo de datos;

    - unos medios de transmision (M'3) de solicitudes de reemision de paquetes de datos a una direccion especlfica, operando dichos medios de transmision de solicitudes de reemision segun el protocolo UDP/IP;

    - unos medios de reordenacion (M'4) de los paquetes recibidos en dichos medios de memorizacion de una sucesion de un numero de paquetes de datos sucesivos recibidos, teniendo en cuenta unos paquetes transmitidos en reemision.
13. 13. Programa informatico memorizado en un soporte de memorizacion de un ordenador o de un aparato dedicado constitutivo de un servidor de transmision/recepcion de datos por paquetes en red IP entre este servidor y un terminal cliente caracterizado por que, durante la ejecucion de sus instrucciones, dicho programa informatico ejecuta las etapas de asignacion a cada paquete a transmitir de un Indice de continuidad de emision y de transmision sucesiva de cada uno de los paquetes segun el protocolo UDP y de su Indice de continuidad segun el protocolo DCP hacia este terminal cliente segun una de las reivindicaciones 1 a 10.
14. 14. Programa informatico memorizado en un soporte de memorizacion de un ordenador constitutivo de un terminal cliente de transmision/recepcion de datos por paquetes en red IP transmitidos segun el protocolo UDP entre este terminal cliente y un servidor, caracterizado por que, durante su ejecucion, dicho programa informatico ejecuta las etapas de deteccion de cualquier ruptura de continuidad del flujo de paquetes recibidos a partir de su Indice de continuidad recibido segun el protocolo de DCP, y, tras la deteccion de una discontinuidad del flujo, la transmision desde el terminal cliente a dicho servidor de al menos una solicitud de reemision de al menos un paquete faltante, en tanto que este o estos paquetes faltantes no sean recibidos por el terminal cliente.