MX2014010243A - Metodo y servidor para enviar un flujo de datos a un cliente y metodo y cliente para recibir un flujo de datos de un servidor. - Google Patents

Abstract

Se provee un método, en un servidor, operativamente conectable a un cliente a través de una conexión de datos, un método de envío de un flujo de datos al cliente. El método comprende recibir del cliente, una petición para datos, la petición comprendiendo un identificador de comunicación, obtener una primera parte del flujo de datos de la fuente del flujo para enviar al cliente y enviar, al cliente, un mensaje de datos del flujo. El mensaje de datos del flujo comprende: la primera parte; el identificador de comunicación; y un indicador de flujo, que indica que un segundo mensaje de datos puede seguir, que comprende una segunda parte del flujo de datos. El método no comprende el reenvío del mensaje de datos del flujo si no se ha recibido acuse de recibo del cliente. También se provee un método en un cliente, así como el servidor y el cliente.

Description

MÉTODO Y SERVIDOR PARA ENVIAR UN FLUJO DE DATOS A UN CLIENTE Y MÉTODO Y CLIENTE PARA RECIBIR UN FLUJO DE DATOS DE UN SERVIDOR Campo técnico de la invención La invención se refiere a comunicación de datos y a comunicación de un flujo de datos en una conexión entre un servidor y un cliente, en donde uno o más de la conexión, servidor y cliente tienen recursos limitados.

Antecedentes de la invención CoAP - Protocolo de Aplicación para Recursos Limitados - es un protocolo de comunicación de datos para nodos y redes de recursos limitados. Una de las principales metas del CoAP es diseñar un protocolo de web genérico para los requerimientos especiales de este ambiente de recursos limitados, especialmente considerando energía, automatización de edificio y aplicaciones de M2M - máquina a máquina. El estado de un recurso en un servidor de CoAP puede cambiar con el tiempo. CoAP provee una extensión para observar dichos cambios. Un cliente se registra con un recurso al realizar una petición de GET que incluye una opción de observar. Cuando un servidor recibe dicha petición, sirve la petición como una petición de GET y, si la respuesta resultante indica éxito, establece una relación de observación entre el cliente y el recurso objetivo.

La publicación de solicitud de patente WO 2011/159985 describe un método de intercambiar información entre nodos de inactividad sobre CoAP.

Sumario de la invención Se prefiere disponer de métodos y dispositivos para la transferencia eficiente de flujos continuos de datos entre dichos dispositivos, en donde dichos dispositivos y/o una conexión entre ellos está limitada con respecto a recursos.

Un primer aspecto provee en un servidor, operativamente conectable a un cliente a través de una conexión de datos, un método de envío de un flujo de datos al cliente. El método comprende recibir del cliente una petición para datos, la petición comprendiendo un identificador de comunicación, obteniendo una primera parte del flujo de datos de una fuente de flujo para enviar al cliente y enviando, al cliente, un mensaje de datos del flujo. El mensaje de datos del flujo comprende: la primera parte; el identificador de comunicación; e indicador de flujo, indicando que un segundo mensaje de datos puede seguir, que comprende una segunda parte del flujó de datos.. El método no comprende el reenvío del mensaje de datos del flujo si no se ha recibido acuse de recibo del cliente.

Al no reenviar el mensaje de datos del flujo si no se ha recibido acuse de recibo del cliente, el ancho de banda es guardado y tanto la arquitectura del cliente como del servidor se pueden simplificar. Por otra parte, aún es posible transferir un flujo de datos. En particular si el flujo de datos comprende datos pertinentes en tiempo real, como datos audiovisuales de un sistema de vigilancia, es usualmente más importante tener datos a tiempo de una manera eficiente, en vez de recibir los datos 100% correctos, sin por ejemplo artefactos de compresión/descompresión debido a integridad de datos reducida.

Una modalidad del método de conformidad con el primer aspecto comprende recibir, del cliente, una petición del formato de datos; y enviar, en respuesta a la recepción de la petición de recurso de datos, al cliente un mensaje de formato de datos que comprende información en por lo menos un primer formato en el cual el flujo de datos está disponible. En esta modalidad, la petición para datos comprende un formato preferido comprendido por el mensaje de formato de datos; y la primera parte del flujo es formateado de acuerdo con el formato preferido.

Al proveer una opción para escoger un formato de datos especifico, como una especificación de codee (codificación/decodificación) especifica, el cliente puede ser provisto con menos opciones con respecto a formatos de datos que puede manejar. También es posible que el cliente escoja un formato que el cliente pueda manejar en la forma más eficiente tomando en cuenta recursos, como potencia de batería disponible.

Otra modalidad del primer aspecto comprende enviar el mensaje de datos del flujo al cliente si se cumple por lo menos una de las siguientes condiciones: una cantidad de datos obtenidos de la fuente de flujo es igual a carga máxima predeterminada del mensaje de datos del flujo; o una cantidad predeterminada de tiempo ha transcurrido desde que el último mensaje de datos del flujo ha sido enviado al cliente.

Esta modalidad evita que sean enviados bloques de datos grandes - que pueden dar origen a ciertos problemas si la red está limitada con respecto a la calidad. Además, al tomar en cuenta ambas opciones, los mensajes de datos son enviados con relativa frecuencia, por lo que el cliente recibe con relativa frecuencia una señal de vida del servidor, en cualquier caso dentro de la cantidad de tiempo predeterminada.

Una modalidad adicional del primer aspecto comprende no recibir más datos de la fuente de flujo; incorporar en el mensaje de datos del flujo un fin de indicador de flujo; y enviar el mensaje de datos del flujo al cliente .

Esto permite al cliente diferenciar entre una conexión terminada correctamente y una conexión terminada debido a un error.

En otra modalidad, más del primer aspecto, el mensaje de datos del flujo es enviado de acuerdo con una especificación de protocolo de comunicación, la especificación proveyendo: enviar mensajes que requieren ser confirmados al ser recibidos; y terminar mensajes que no han de ser confirmados al ser recibidos. En esta modalidad, el mensaje de datos del flujo es enviado como un mensaje que no ha de ser confirmado al ser recibido.

Al enviar mensajes que no necesitan ser confirmados, ninguna confirmación ha sido enviada al recibir el mensaje de datos. Esto reduce el ancho de banda general usado sobre la conexión y permite la simplificación de la arquitectura de red.

Un segundo aspecto provee, en un cliente, operativamente conectable a un servidor a través de una conexión de datos, un método para recibir un flujo de datos del servidor. El método comprende obtener un identificador de comunicación, enviar al servidor una petición para datos, la petición comprendi ndo el identificador de comunicación y recibir del servidor un mensaje de datos del flujo. El mensaje de datos comprende una primera parte del flujo de datos; el identificador de comunicación; y un indicador de flujo, indicando que un segundo mensaje de datos puede seguir, que comprende una segunda parte del flujo de datos.

El método además comprende procesar el mensaje de datos del flujo sin enviar un acuse de recibo al servidor.

Igual que con el método de conformidad con el primer aspecto, este permite una transferencia eficiente de un flujo de datos y provee una opción para arquitectura de sistema simplificada.

En una modalidad del segundo aspecto, el mensaje de datos del flujo comprende una marca de tiempo que tiene un valor de marca de tiempo. El método de esta modalidad comprende extraer la marca de tiempo del mensaje de datos del flujo; almacenar el mensaje de datos del flujo en una memoria intermedia; y procesar el mensaje de datos del flujo junto con otros mensajes de datos de flujo almacenados en la memoria intermedia en un orden indicado por los valores de las indicaciones de tiempo correspondientes a cada mensaje de datos del flujo.

Los mensajes de datos no llegan en el mismo orden ya que pueden tomar diferentes rutas del servidor al cliente. Este es por ejemplo el caso con redes basadas en IP. Esta modalidad permite el ordenamiento apropiado para procesamiento posterior.

Una modalidad adicional del segundo aspecto comprende recibir un mensaje de datos del flujo adicional que comprende una marca de tiempo adicional con . un valor adicional; y desechar el mensaje de datos del flujo adicional si el mensaje de datos del flujo ya ha sido procesado y el valor adicional de la marca de tiempo adicional corresponde a un tiempo anterior que el valor de la marca de tiempo del mensaje de datos del flujo.

Con esta modalidad, a las restricciones de tiempo real se da prioridad sobre restricciones de integridad de datos. En particular en ambientes de seguridad, las demandas de tiempo real son usualmente más importantes que las restricciones de integridad de datos.

Un tercer aspecto provee un servidor para enviar un flujo de datos a un cliente a través de una conexión de datos, que comprende: una unidad receptora de flujo dispuesta para obtener una primera parte del flujo de datos de una fuente de flujo para enviar al cliente. El servidor además comprende una unidad de procesamiento dispuesta para generar mensajes de datos, una unidad de recepción dispuesta para recibir del cliente una petición para datos, la petición comprendiendo un identificador de comunicación; una unidad de envío dispuesta para enviar los mensajes de datos al cliente. La unidad de procesamiento está dispuesta para generar un mensaje de datos del flujo que comprende: la primera parte; el identificador de comunicación; y un indicador de flujo, que indica que un segundo mensaje de datos puede seguir, que comprende una segunda parte del flujo de datos. El procesamiento está dispuesto además para no instruir a la unidad de envío a reenviar el mensaje de datos del flujo si no se ha recibido acuse de recibo del cliente.

Un cuarto aspecto provee un cliente para recibir un flujo de datos de un servidor a través de una conexión de datos, que comprende: una unidad de procesamiento dispuesta para obtener un identificador de comunicación; una unidad de envío dispuesta para enviar al servidor una petición de datos, la petición comprendiendo el identificador de comunicación y una unidad de recepción. La unidad de recepción está dispuesta para recibir, del servidor, un mensaje de datos del flujo que comprende: una primera parte del flujo de datos; el identificador de comunicación; y un indicador de flujo, que indica que un segundo mensaje de datos puede fluir, que comprende una segunda parte del flujo de datos. La unidad de procesamiento está dispuesta para procesar el mensaje de datos del flujo sin enviar un acuse de recibo al servidor.

Breve descripción de los dibujos Los diversos aspectos y modalidades de los mismos se describirán ahora con mayor detalle junto con las figuras. En las figuras, figura 1: muestra un sistema de comunicación; figura 2: muestra un servidor; figura 3: muestra un cliente; figura 4: muestra un diagrama de protocolo; figura 5: muestra un procedimiento de servidor; y figura 6: muestra un procedimiento de cliente.

Descripción detallada de la invención La figura 1 muestra un sistema de comunicación 100 que comprende un módulo de vigilancia remoto 110 y un teléfono móvil 120. El módulo de vigilancia remoto 110 comprende una cámara 112, un micrófono 118, un servidor 200 y un modulador/desmodulador del servidor 114. Se supone que la cámara 112 adquiere datos para crear un flujo de datos audiovisuales. Esta puede estar en una forma continua, pero también en una forma discontinua. En el último caso, la cámara 112 puede ser activada por sensor de movimiento o una instrucción remota o local. El modulador/desmodulador del servidor 114 modula datos del servidor para transmisión en una conexión de datos 150 y desmodula datos recibidos. La modulación puede comprender modulación de señal de una señal de datos en una onda portadora para transmisión alámbrica o inalámbrica, modulación de datos para enviar de acuerdo con un protocolo de transmisión de datos como TCP/IP u otro.

El teléfono móvil 120 comprende un modulador/desmodulador de cliente 124, un cliente 300, una pantalla 126 para presentar datos visuales,, una bocina 128 para presentar datos audibles, un teclado 130 para entrada de recepción de datos y una unidad de procesamiento 122 para controlar la operación de las diversas partes del teléfono móvil 120. La pantalla 126 puede ser una pantalla de tacto para recibir entrada de datos.

El módulo de vigilancia remoto 110 y el teléfono móvil 120 son conectados a través de la conexión de datos 150. La conexión de datos 150 puede ser una conexión alámbrica, una conexión inalámbrica o una combinación de las mismas. Además, la conexión puede ser .una conexión directa o una conexión a través de una red más grande, incluyendo, pero sin limitarse a, una red celular, una red de IP, otra, o una combinación de las mismas. Un experto en la técnica apreciará que la conexión de datos 150 no es necesariamente una conexión fija y física y también puede ser una conexión lógica. El formato preferido para comunicación entre el cliente 300 y el servidor 200 es CoAP, que es una abreviatura de protocolo de aplicación para recursos limitados.

La figura 2 muestra el servidor 200 con más detalle. El servidor 200 comprende un circuito de procesamiento de flujo del servidor 202 para recibir y procesar un flujo, una memoria intermedia de servidor 204 para guardar en memoria el flujo recibido, un circuito de envío del servidor 206 para enviar datos del flujo recibido, un circuito de procesamiento del servidor 210 para controlar la operación de los componentes del servidor 200, una memoria del servidor 208, un circuito de recepción del servidor 212 para recibir datos, un multiplexor/desmultiplexor del servidor 214 para separar datos que han de ser enviados y datos recibidos a través del modulador del servidor 114 y una unidad de reloj 216. La memoria del servidor 208 está dispuesta para almacenar instrucciones para programar el circuito de procesamiento del servidor 210, para almacenar datos recibidos por medio del circuito de. recepción del servidor 212 y para almacenar otros datos relacionados con la operación del servidor 200.

La figura 3 muestra al cliente 300 con más detalle. El cliente 300 comprende un mult iplexor/desmult iplexor del cliente 314 para separar datos que han de ser enviados y datos recibidos a través del modulador/desmodulador del servidor 114, un circuito de recepción del cliente 312 par recibir datos que comprenden datos de flujo, una memoria intermedia del cliente 304, un decodificador del cliente 302, un circuito de procesamiento de flujo del cliente 316, un circuito de envío del cliente 306 para enviar mensajes de datos, un circuito de procesamiento del cliente 310 para controlar la operación de los componentes del cliente 300, una memoria del cliente 308 y un circuito de generación del identificador 318 para generar un identificador de comunicación. La memoria del cliente 308 está dispuesta para almacenar instrucciones para programación de circuito de procesamiento del cliente 310, para almacenar datos recibidos por medio del circuito de recepción del cliente 312 y para almacenar otros datos relacionados con la operación del cliente 300.

La operación del sistema de comunicación 100 que comprende el módulo de vigilancia remoto 110 y el teléfono móvil 120 se describirá ahora junto con la figura 4 que muestra un diagrama de protocolo 400, la figura 5 que muestra un procedimiento de servidor 500 y la figura 6 que muestra un procedimiento de cliente 600.

La figura 4 ilustra, en el diagrama de protocolo 400, en el lado izquierdo el cliente 300 y en el lado derecho el servidor 200. La transferencia de datos relacionados con un flujo de . datos empieza con una petición de formato de datos opcional 402 emitida por el cliente 300 en el paso 604 - ejecutada después de iniciar el procedimiento del cliente 600 en un punto de inicio del cliente 602. La petición de formato de datos 402 es recibida por el servidor 200 en el paso 504 - ejecutada después de iniciar el procedimiento de servidor 500 en un punto de inicio de servidor 502. Con la petición del formato de datos 402, el cliente 300 pregunta al servidor 200 en qué formatos se puede proveer el flujo de datos audiovisuales. En sintaxis de CoAP, la petición de formato de datos puede ser GET/videocámara/codecs En el paso 506, el servidor 200 envía un mensaje de información de formato de datos 404 al cliente 300 que recibe el mensaje de información de formato de datos en el paso 606. El mensaje de información de formato de datos 404 comprende en una modalidad preferida codees (protocolos de codificación/decodificación) . y en particular codees para compresión y descompresión de datos audiovisuales como varias especificaciones de estándar de MPEG, DivX, AVI, 3GP y otros. En otra modalidad, los codees en los cuales la información es comprimida por el mensaje de información de formato de datos 404 son codees de cifrado/descifrado. Otros tipos de formatos pueden ser comunicados también, en formatos relacionados con la capa de aplicación, pero también en formatos relacionados con capas inferiores.

En sintaxis de CoAP, el mensaje de información de formato de datos 404 puede ser como sigue: 2.05 Contenido </videocámara/MPEG> ; rt="videocámara" </videocámara/AVI>; rt="videocámara" Con el mensaje de información de formato de datos 404 , el servidor 200 informa al cliente 300 que el flujo de datos audiovisuales obtenido por medio de la cámara 112 se puede proveer en un formato comprimido, comprimido de acuerdo con una especificación de compresión de MPEG o una especificación de compresión de AVI.

Habiendo recibido la información en los formatos en los cuales el flujo de datos - en este caso un flujo que comprende datos audiovisuales - está disponible, el cliente 300 prepara una petición para datos. En el paso 608, el cliente 300 obtiene un identificador para una sesión de comunicación con el servidor 200. En esta modalidad, el circuito de generación del identificador 318 genera un identificador de sesión aleatorio o token. Alternativamente, la memoria del cliente 308 tiene una tabla con identificadores almacenados en la misma y el circuito de procesamiento de cliente 310 selecciona uno de esos identificadores de la tabla.

El identificador obtenido es incorporado en un mensaje de petición de datos 406, por el cual el cliente 300 pide al servidor 200 datos del flujo de datos generado por la cámara 112 y/o el micrófono 118. El mensaje de petición de datos 406 es compilado por el circuito de procesamiento de cliente 310. El mensaje de petición de datos 406 es enviado por el cliente 300 en el paso 610 por medio del circuito de envío de cliente 306 y canalizado al modulador/desmodulador de cliente 124 a través del multiplexor/desmultiplexor del cliente 314, así como otros datos enviados por el cliente 300. El mensaje de petición de datos 406 es recibido por el servidor 200 en el paso 508 a través del modulador/desmodulador del servidor 114 y canalizado al circuito de procesamiento del servidor 210 a través del multiplexor/demultiplexor del servidor 214, como con otros datos recibidos por el servidor 200.

En sintaxis de CoAP, el mensaje de petición de datos 406 puede ser como sigue: GET/videocámara/MPEG Observar: 0 Token: 0x4a Al recibir el mensaje de petición de datos 406, el servidor obtiene en un paso 510 datos generados por la cámara 112 y/o l micrófono 118 como un flujo de datos. Los datos se obtienen por el servidor a través del circuito de procesamiento de flujo del servidor 202. El circuito de procesamiento de flujo del servidor 202 puede actuar como una pasarela pasante. Alternativamente, el circuito de procesamiento de flujo del servidor 202 es o puede actuar como una unidad de compresión de datos, una unidad de cifrado de datos, una unidad que procesa el flujo de datos de otra forma, o una combinación de las mismas. Dicho procesamiento preferiblemente se hace de acuerdo con la especificación de formato como se requiere en el mensaje de petición de datos 406. En una modalidad preferida, el circuito de procesamiento de flujo del servidor traduce los datos en el flujo de datos, ya sea procesados o no, a datos de texto planos especificados como "text/plain; charset = utf-8".

En otra modalidad, los datos son enviados en un formato predeterminado, sin negociaciones adicionales entre el cliente 300 y el servidor 200 con anticipación. En esa modalidad, la opción para requerir formatos de datos no está disponible. En otra modalidad, si no es requerido un formato de datos especifico por el cliente 300 o si no se ha expedido petición de formato de datos, el servidor 200 envía datos en el formato por omisión.

Los datos obtenidos y opcionalmente procesados son provistos a la memoria intermedia del servidor 204. El circuito de procesamiento del servidor 210 verifica en una decisión 512 si los datos para un paquete de datos completo están listos para enviar un tramo de datos de flujo al cliente 300. Un paquete se. considera completo si la cantidad de datos del flujo de datos en la memoria intermedia es igual y preferiblemente no excede una cantidad predeterminada de datos. La cantidad predeterminada de datos puede ser definida por una especificación estándar, por negociación entre el cliente 300 y el servidor 200, otra, o una combinación de las mismas. En una modalidad preferida la cantidad predeterminada es 1280 bytes.

Si el paquete no está completo, el circuito de procesamiento del servidor 210 opcionalmente verifica en una decisión 514 si una cantidad predeterminada de tiempo ha transcurrido desde que el último mensaje de petición de datos 406 ha sido recibido. La cantidad predeterminada de tiempo puede ser definida por una especificación estándar, por negociación entre el cliente 300 y el servidor 200, otra, o una combinación de las mismas. Finalmente, esto puede dar por resultado el envío de un paquete de datos sin carga. Sin embargo, asegura que el cliente 300 reciba una señal de vida del servidor 200.

Si los datos en la memoria intermedia del servidor 204 satisfacen uno de los criterios predeterminados en cantidad de datos y tiempo descrito anteriormente, un primer tramo de datos 408 - que puede ser igual a cero, como se explicó - es enviado en un paso 516 por el servidor 200 desde la memoria intermedia del servidor 204 a través del circuito de envío del servidor 206 y el multiplexor/desmultiplexor del servidor 214 al cliente 300 en la conexión de datos 150. El tramo de datos 408 es enviado en un mensaje de datos que puede tener la siguiente estructura en sintaxis de CoAP : 2.05 Contenido Observar: 1 Token: 0x4a Flujo: en tramo Carga: primer tramo En esta modalidad, el parámetro de flujo indicado anteriormente provee información de que los datos de carga son parte de una entidad de datos más grande y, en esta modalidad, un flujo en particular. Por la indicación de que la carga es un tramo de una entidad más grande, el cliente 300 reconoce que siguen más datos. En otras modalidades, ya sea aún dentro del protocolo de CoAP u otro protocolo, otro parámetro y el valor del mismo se pueden usar para indicar que el flujo de datos audiovisuales - u otra entidad de datos más grande - es separado en tramos de datos.

El mensaje de datos completo con el primer tramo de datos 408 es enviado al cliente en un paso 516. El mensaje de datos completo de esta modalidad como se detalló anteriormente por lo tanto comprende una marca de tiempo "Observar", un identificador de sesión aleatorio o token "0x4a", un parámetro de codificación "en tramo" y carga. Un valor para la marca de tiempo se puede obtener a partir de la unidad de reloj 216. El mensaje de datos completo también puede comprender datos adicionales como ruta o datos en dirección. Preferiblemente, mensajes de datos consecutivos se proveen con marcas de tiempo en una forma consecutiva y continua: un primer mensaje de datos o paquete tiene un valor 1 de "Observar", un segundo mensaje de datos tiene un valor 2 de "Observar", etc.

El mensaje de datos es recibido por el cliente 300 en el paso 612 a través del modulador/desmodulador del cliente 124, el multiplexor/desmultiplexor del cliente 314 enviando el mensaje de datos y el circuito de recepción del cliente 312 para recibir el mensaje de datos. El circuito de recepción del cliente 312 lleva la carga del mensaje de datos, el primer tramo de datos 408 y envía el primer tramo de datos 408 a la memoria intermedia de cliente 304 en un paso 614.

La memoria intermedia del cliente 304 provee datos al decodificador del cliente 302 para decodificar el primer tramo de datos 408 en el paso 614 también. La decodificación puede ser descompresión, descifrado, otra o una combinación de las mismas. Los datos decodificados son provistos posteriormente al circuito de procesamiento de flujo del cliente 316 para proveer los datos decodificados para reproducción por la pantalla 126 y/o la bocina 128 en un formato consumible por una persona. La reproducción puede ser controlada por un usuario por medio de teclado 130 y/o la pantalla 126 en caso disponible como una pantalla de tacto.

Con ciertos protocolos de comunicación de datos, como UDP (Protocolo de Datagram de usuario), mensajes de datos o paquetes pueden ser recibidos en un orden diferente de un orden en el cual los mensajes de datos han sido enviados. Por medio de la marca de tiempo descrita anteriormente, los mensajes de datos pueden ser recuperados de la memoria intermedia del cliente 304 en un orden correcto, es decir, el orden en el cual han sido enviados. Esto permite que el cliente 300 verifique si ningún mensaje de datos con tramos de flujo de datos se ha perdido o retrasado .

En dichos protocolos de comunicación de datos, el tiempo de transmisión de mensajes de datos del servidor 200 al cliente 300 puede variar. En un caso particular, el tiempo de transmisión puede variar de tal manera que el mensaje de datos con marca de tiempo 10 no ha llegado en un momento en que los mensajes de datos con marcas de tiempo 11 y 12 ya han llegado y otro mensaje de datos con marca de tiempo 9 ya ha sido recuperado de la memoria intermedia del cliente 304 y procesado.

En particular en casos en donde el procesamiento oportuno de datos es más importante que la integridad de datos, los datos en los mensajes de datos posteriores con marcas de tiempo 11 y 12 son procesados después de que los datos del otro mensaje de datos con marca de tiempo 9 y el mensaje de datos con marca de tiempo 10 es descartado al llegar. Alternativamente, el procesamiento de datos en los mensajes de datos posteriores con marcas de tiempo 11 y 12 es suspendido hasta que los datos del mensaje de datos con marca de tiempo 10 han llegado y han sido procesados. En otra alternativa, nuevamente, los datos en los mensajes de datos posteriores con marcas de tiempo 11 y 12 son procesados, seguidos por el procesamiento de datos comprendidos por el mensaje de datos con la marca de tiempo 10.

La recepción del mensaje de datos no es acusada por el cliente 300. Esto es para reducir el uso de ancho de banda, haciendo tanto ancho de banda de la conexión de datos 150 como es posible disponible para transmisión de los datos reales del flujo de información audiovisual. En una modalidad relaciona con CoAP, el servidor 200 tiene una opción de enviar tramos de datos ya sea en mensajes confirmables o no confirmables . Para reducir anchos de banda como se indica, tramos de datos del flujo de datos son enviados por el servidor 200 al enviar datos en tramos por medio de mensajes no confirmables.

El procedimiento del servidor 500 continúa con otro paso que ha enviado el mensaje de datos, sin esperar acuse de recibo del mensaje de datos del cliente 300. Una razón es hacer, como ya se indicó, tanto ancho de banda disponible como es posible. Otra razón es que con datos audiovisuales y audiovisual "en vivo" en particular, es más importante que los datos estén en el lugar correcto en el tiempo, en vez de que todos los datos estén en el lugar correcto en buena forma, pero con un retraso significativo. Y en algunos escenarios limitados, la calidad de la conexión de datos 150 puede ser una limitación - en cuyo caso el reenvió de datos para obtener los datos con 100% de integridad con el cliente 300 puede implicar muchas veces obstrucción de la conexión limitada.

Habiendo . enviado el primer tramo de datos 408 en el paso 516, el procedimiento del servidor 500 continúa a una decisión 518 en la cual es verificado si el cliente 300 ha reiniciado la sesión de comunicación con el servidor 200 al enviar un mensaje de reinicio 414 o no. Si el cliente 300 ha reiniciado la sesión de comunicación con el servidor 200, no más datos necesitan ser enviados al cliente 300. En el caso de que un mensaje de reenvió ha sido recibido por el servidor 200, el procedimiento del servidor termina en un terminador 524.

Si en la decisión 518 se detecta que ningún mensaje reiniciado 414 ha sido recibido por el servidor 200, el procedimiento del continúa al verificar si más datos del flujo de datos está disponible. Si no más datos están disponibles, por ejemplo cuando la cámara 112 y/o el micrófono 118 ya no están activos, el servidor envía un fin del mensaje de archivo 412 en un paso 522. Dicho fin de mensaje de archivo 412 permite o por lo menos ayuda al cliente 300 a diferenciar entre la conexión terminada como resultado de un error y una corrección es terminada correctamente. En la sintaxis de CoAP, el fin del mensaje del archivo 404 puede ser como sigue: 2.05 Contenido Observar: 44 Token: 0x4a Flujo: EOF Carga: último tramo Habiendo enviado el fin del mensaje de archivo, el servidor 200 continúa el procedimiento del servidor 500 a un terminador 524, terminando el procedimiento del servidor 500.

Si en la decisión 520 se detecta que los datos aún están disponibles y son presentados por la cámara 112 y/o el micrófono 118, el procedimiento del servidor 500 salta de nuevo al paso 510 para obtener datos adicionales del flujo, y envia un segundo tramo de datos 410 en el paso 516, siguiendo también pasos y decisiones opcionales entre los mismos. Este bucle se continúa hasta que el procedimiento del servidor 500 se ramifica al terminador 524, ya sea directamente o a través de pasos y decisiones intermedios opcionales.

En cuanto al procedimiento del cliente 600, habiendo procesado el tramo de datos recibido, el cliente 300 verifica en una decisión 616 si más datos han sido recibidos de o está siendo ofrecido por el servidor 200. Esto puede ser verificado por el circuito de recepción del cliente 312, el multiplexor/desmultiplexor del cliente 314, el circuito de procesamiento del cliente 310, otro componente del cliente 300 o una combinación de los mismos. Si ningún dato ha sido recibido, el procedimiento del cliente 600 continúa a un terminador 618, terminando el procedimiento del cliente 600. Alternativamente, si el último mensaje de datos recibido del servidor 200 lleva el identificador "fin de archivo", el procedimiento del cliente 600 se ramifica al terminador 618 también. Si se detecta en la decisión 616 que datos adicionales ha sido recibidos o han de ser recibidos por el cliente 300 del servidor 200, el procedimiento del cliente 600 se ramifica de nuevo al paso 612.

Las diversas modalidades asi ilustradas, descritas y discutidas son particularmente ventajosas como una extensión del protocolo de CoAP. Y, como lo apreciará un experto en la técnica, estas modalidades y equivalentes de las mismas, ya sea con o sin pequeñas variaciones, se pueden utilizar en otros protocolos de comunicación de datos también sin apartarse del alcance de la invención.

En las modalidades presentadas hasta ahora, el servidor 200 ha sido implementado en el módulo de vigilancia remoto 110 y el cliente 300 ha sido implementado en el teléfono móvil 120. Estas son modalidades simplemente ilustrativas; el servidor 200 también puede ser implementado en un módulo de medición de laboratorio, que provee una alimentación continua o semicontinua de datos medidos. En dicho escenario, el cliente 300 puede ser implementado en el teléfono móvil 120. En otra alternativa, el servidor 200 es implementado en un módulo de monitoreo de tráfico y el cliente 300 es implementado en un módulo de control de tráfico, que controla señales de caminos adaptativas.

Expresiones tales como "comprende", "incluye", "incorpora", "contiene", "es" y "tiene" han de ser consideradas de una manera no exclusiva al interpretar la descripción y sus reivindicaciones asociadas, a saber consideradas para permitir otros elementos o componentes que no son explícitamente definidos también para estar presentes. Referencia al singular también debe considerarse una referencia al plural y viceversa. Cuando los datos están siendo referidos como datos audiovisuales, pueden representar únicamente audio, únicamente video o sólo imágenes fijas o una combinación de los mismos, a menos que se indique específicamente otra cosa en la descripción de las modalidades .

En la descripción anterior, se entenderá que cuando un elemento tal como capa, región o sustrato referida como estando "en", "sobre" o "conectada a" otro elemento, el elemento es ya sea directamente en o conectado al otro elemento, o elementos intermedios también pueden estar presentes .

Además, la invención también puede ser representada con menos componentes de los que se proveen en las modalidades descritas aquí, en donde un componente porta múltiples funciones. También la invención puede ser representada usando más elementos que los que se ilustran en la figura 1, en donde las funciones llevadas a cabo por un componente en la modalidad provista son distribuidas en múltiples componentes.

Un experto en la técnica apreciará fácilmente que varios parámetros descritos en la descripción pueden ser representados y que varias modalidades descritas' y/o reivindicadas pueden ser combinadas sin apartarse del alcance de la invención.

Se estipula que los signos de referencia en las reivindicaciones no limitan el alcance de las reivindicaciones, sino que son insertados simplemente para mejorar la legibilidad de las reivindicaciones.

Claims (17)

REIVINDICACIONES

1. En un servidor (200), operativamente conectable a un cliente (300) a través de una conexión de datos (150), un método (500) de enviar un flujo de datos al cliente, comprende : - recibir (402, 504), del cliente, una petición de formato de datos; y enviar (506, 404), en respuesta a la recepción de la petición de recurso de datos, al cliente un mensaje de formato de datos que comprende información sobre por lo menos un primer formato en el cual el flujo de datos está disponible; recibir (406, 508) del cliente, una petición para datos, la petición comprendiendo un identificador de comunicación; obtener (510) una primera parte del flujo de datos de una fuente de flujo (112, 118) para enviar al cliente; enviar (408, 516) al cliente, un mensaje de datos del flujo que comprende: - la primera parte; - el identificador de comunicación; y - un indicador de flujo, que indica que un segundo mensaje de datos puede seguir, que comprende una segunda ' parte del flujo de datos; y - no reenviar el mensaje de datos del flujo si no se ha recibido acuse de recibo del cliente; en donde : la petición para datos comprende un formato preferido comprendido por el mensaje de formato de datos; la primera parte del flujo es formateada de acuerdo con el formato preferido.

2. El método de conformidad con la reivindicación 1, que comprende enviar el mensaje de datos del flujo al cliente si por lo menos se cumple una de las siguientes condiciones: - una cantidad de datos obtenidos a partir de la fuente de flujo es igual a una carga máxima predeterminada del mensaje de datos del flujo; o - una cantidad predeterminada de tiempo ha transcurrido desde que se ha enviado el último mensaje de datos del flujo al cliente.

3. El método de conformidad con cualquiera de las reivindicaciones 1 a 2, que además comprende: - recibir (414, 518), del cliente, un mensaje de no más datos; y - detener (524) el envío de datos al cliente.

4. El método de conformidad con con cualquiera, de las reivindicaciones 1 a 3, que además comprende: - no recibir más datos de la fuente del flujo; incorporar (522) en el mensaje de datos del flujo un fin de indicador de flujo; y - enviar (412, 522) el mensaje de datos del flujo al cliente.

. El método de conformidad con cualquiera de las reivindicaciones 1 a 4, en donde el flujo de datos comprende datos audiovisuales.

6. El método de conformidad con cualquiera de las reivindicaciones 1 a 5, en donde el mensaje de datos del flujo es enviado de acuerdo con una especificación de protocolo de comunicación, la especificación proveyendo: - enviar mensajes que requieren ser confirmados al ser recibidos; y - enviar mensajes que no han de ser confirmados al ser recibidos; y en donde el mensaje de datos del flujo es enviado como un mensaje que no ha de ser confirmado al ser recibido.

7. El método de conformidad con cualquiera de las reivindicaciones 1 a 6, que además comprende: - obtener una marca de tiempo correspondiente a un tiempo del sistema del servidor; e insertar la marca de tiempo en el mensaje de datos del flujo.

8. El método de conformidad con cualquiera de las reivindicaciones 1 a 1, en donde la petición para datos y el mensaje de datos del flujo son provistos de acuerdo con el protocolo de CoAP .

9. En un cliente (300), operativamente conectable a un servidor (200) a través de una conexión de datos (150), un método (600) de recepción de un flujo de datos del servidor, que comprende: - enviar (604) una petición de formato de datos al servidor; y recibir (606), del servidor, un mensaje de formato de datos que comprende información sobre por lo menos un primer formato en el cual el flujo de datos está disponible ; - obtener (608) un identificador de comunicación; - enviar (406, 610), al servidor, una petición para datos, la petición comprendiendo el identificador de comunicación ; - recibir (408, 612) del servidor un mensaje de datos del flujo que comprende: - una primera parte del flujo de datos; - el identificador de comunicación; y - un indicador de flujo, que indica que un segundo mensaje de datos puede seguir, que comprende una segunda parte del flujo de datos; y - procesar (614) el mensaje de datos del flujo sin enviar un acuse de recibo al servidor, en donde: - la petición para datos comprende un formato preferido comprendido por el mensaje de formato de datos; y la primera parte del flujo es formateada de acuerdo con el formato preferido.

10. El método de conformidad con la reivindicación 9, en donde el mensaje de datos del flujo comprende una marca de tiempo que tiene un valor de marca de tiempo y el método además comprende: - extraer la marca de tiempo del mensaje de datos del flujo; - almacenar el mensaje de datos del flujo en una memoria intermedia; y - procesar el mensaje de datos del flujo junto con otros mensajes de datos de flujo almacenados en la memoria intermedia en un orden indicado por los valores de las marcas de tiempo correspondientes a cada mensaje de datos del flujo.

11. El método de conformidad con la reivindicación 10, que además comprende: - recibir un mensaje de datos del flujo adicional que comprende una marca de tiempo adicional con un valor adicional; y - descartar el mensaje de datos del flujo adicional si el mensaje de datos del flujo ya ha sido procesado y el valor adicional de la marca de tiempo adicional corresponde a un tiempo anterior que el valor de la marca de tiempo del mensaje de datos del flujo.

12. Un servidor (200) para enviar un flujo de datos a un cliente (300) a través de una conexión de datos (150), que comprende: - una unidad de recepción de flujo (202) dispuesta para : - recibir, del cliente, una petición de formato de datos ; - enviar, en respuesta a la recepción de la petición de recurso de datos, al cliente un mensaje de formato de datos que comprende información sobre por lo menos un primer formato en el cual el flujo de datos está disponible; y -obtener una primera parte del flujo de datos de una fuente de flujo para enviar al cliente; - una unidad de procesamiento (210) dispuesta para generar mensajes de datos; una unidad de recepción (212) dispuesta para recibir, del cliente, una petición para datos, la petición comprendiendo un identificador de comunicación; - una unidad de envió (206) dispuesta para enviar los mensajes de datos al cliente; en donde: - la unidad de procesamiento está dispuesta para generar un mensaje de datos del flujo que comprende: - la primera parte; - el identificador de comunicación; y - un indicador de flujo, que indica que un segundo mensaje de datos puede seguir, que comprende una segunda parte del flujo de datos; y - la unidad de procesamiento está dispuesta no para instruir la unidad de envió a reenviar el mensaje de datos del flujo si no se ha recibido acuse de recibo del cliente. - la petición para datos comprende un formato preferido comprendido por el mensaje de formato de datos; la primera parte del flujo es formateada de acuerdo con el formato preferido.

13. Un cliente (300) para recibir un flujo de datos de un servidor a través de una conexión de datos (150), que comprende : - una unidad de procesamiento (310) dispuesta para obtener un identificador de comunicación; - una unidad de envió (306) dispuesta para - enviar, al servidor, una petición de formato de datos; y - enviar al servidor una petición para datos, la petición comprendiendo el identificador de comunicación; - una unidad de recepción (312), dispuesta para: - recibir, del servidor, un mensaje de formato de datos que comprende información sobre por lo menos un primer formato en el cual el flujo de datos está disponible; - recibir, del servidor, un mensaje de datos del flujo que comprende: - una primera parte del flujo de datos; - el identificador de comunicación; y - un indicador de flujo, que indica que un segundo mensaje de datos puede seguir, que comprende una segunda parte del flujo de datos; y en donde - la unidad de procesamiento está dispuesta para procesar el mensaje de datos del flujo sin enviar un acuse de recibo del servidor; la petición para datos comprende un formato preferido comprendido por el mensaje de formato de datos; y la primera 'parte de flujo es formateada de acuerdo con el formato preferido.

14. El cliente de conformidad con la reivindicación 13, que . además comprende una unidad generadora de identificador de comunicación, en donde la unidad de procesamiento está dispuesta para obtener el identificador de comunicación de la unidad generadora del identi ficador de comunicación (318) .

15. Un teléfono móvil (120) que comprende el cliente de conformidad con la reivindicación 13 y en donde el flujo comprende datos audiovisuales, el teléfono móvil además comprende por lo menos una unidad de reproducción audiovisual para hacer los datos procesados comprendidos por el flujo.

16. El teléfono móvil (120) de conformidad con la reivindicación 15, en donde por lo menos la unidad de reproducción audiovisual comprende por lo menos uno de los siguientes : - una bocina (128); y - una pantalla (126) .

17. Un sistema de comunicación (100) que comprende: - el servidor de conformidad con reivindicación 12; - el cliente de conformidad con reivindicación 13; y - una conexión de datos (150) . RESUMEN DE LA INVENCIÓN Se provee un método, en un servidor, operativamente conectable a un cliente a través de una conexión de datos, un método de envío de un flujo de datos al cliente. El método comprende recibir del cliente, una petición para datos, la petición comprendiendo un identificador de comunicación, obtener una primera parte del flujo de datos de la fuente del flujo para enviar al cliente y enviar, al cliente, un mensaje de datos del flujo. El mensaje de datos del flujo comprende: la primera parte; el identificador de comunicación; y un indicador de flujo, que indica que un segundo mensaje de datos puede seguir, que comprende una segunda parte del flujo de datos. El método no comprende el reenvío del mensaje de datos del flujo si no se ha recibido acuse de recibo del cliente. También se provee un método en un cliente, así como el servidor y el cliente.