ES2382028T3 - Transporte de datos prioritarios en una red ad hoc - Google Patents

Abstract

Procedimiento para transportar unos datos en una red inalámbrica ad hoc, comprendiendo la red varios nodos en una configuración en un instante dado, un nodo de origen (1), un nodo de destino (3) y varios nodos intermedios (2i) caracterizado porque comprende en el nivel de cada uno de los nodos al menos las etapas siguientes: dividir el mensaje M a transmitir en N paquetes Pi, se proporciona un paquete Pi a las capas (C4, C5) de dicho nodo (2i), Mientras que queden paquetes Pi por transmitir: medir los parámetros que indican la calidad de los flujos en tiempo real en tránsito sobre dicho nodo (2i), autorizar o no la transmisión de dichos paquetes Pi comparando los valores de los parámetros medidos con unos valores de umbral (16, 17), Si la transmisión se autoriza, entonces transmitir uno de dichos paquetes Pi a la capa de Medium Access Control, abreviada en lo que sigue como MAC, o a la capa de red. Mientras que el paquete no haya sido enviado por la capa de la red hacia otro nodo que forme parte de la ruta elegida, para transmitir este paquete hacia el nodo de destino: medir los parámetros que indican la calidad de los flujos en tiempo real en tránsito sobre dicho nodo (2i), autorizar o no la transmisión comparando los valores de los parámetros medidos con unos valores de umbral (16, 17), Si la transmisión no se autoriza: retirar Pi de la cola de espera de la capa MAC (si es posible), volver al comienzo del bucle principal, es decir a la etapa en la que el procedimiento trata de transmitir de nuevo este paquete Pi, Verificar que dicho paquete Pi transmitido se ha recibido bien utilizando un mecanismo de indicación de la recepción y si el paquete ha sido recibido bien, pasar al paquete siguiente Pi+1.

Description

Transporte de datos prioritarios en una red ad hoc

La presente invención se refiere a un procedimiento y un sistema que permite transportar datos que no tengan limitaciones de retardos y también unos datos que puedan ser considerados como prioritarios en una red de radio ad hoc. Se utiliza para proteger los flujos en tiempo real o de prioridad elevada con relación a otros flujos de datos.

El procedimiento de transporte de acuerdo con la invención se puede adoptar en el marco de redes ad hoc o de infraestructuras domésticas con el fin de proteger la telefonía VoIP y los servicios de IPTV (televisión IP) cada vez más extendidos. Se puede aplicar en las redes de radio ad hoc móviles, las redes de radio en red más conocidas bajo la de dominación inglesa “mesh”.

Las redes ad hoc se pueden componer de entidades inalámbricas comunicantes tales como unos planificadores portátiles, teléfonos celulares o incluso captadores. Estas diferentes entidades constituyen los nodos de una red ad hoc, en la que la red observa la entrada y la salida de estas entidades. En estas redes, la comunicación no es posible, en general, más que entre los nodos en le alcance de radio. Un protocolo de enrutado (por ejemplo el protocolo OLSR (abreviación inglesa de protocolo Optimized Link State Routing) o AODV (abreviatura inglesa de Ad Hoc On Demand Vector) asegura entonces la conmutación de los paquetes IP para permitir la conectividad de punta a punta. Los nodos en la red pueden ser móviles o no. Un ejemplo se encuentra en LIN CAI et al. “A QOS aware AIMD protocol for time sensitive application in wired/wireless networks” INFOCOM 2005, PROCEEDINGS IEEE MIAMI FL, USA, 13-15 marzo de 2005, IEEE vol. 3 páginas 2008-20019; XP010829307, ISBN: 978-0-7803-8968-7.

Obtener unos buenos rendimientos en este tipo de red es frecuentemente difícil debido al hecho de la fuerte variabilidad y no predictibilidad de las condiciones de radio y al hecho de que todos los nodos comparten el mismo medio o soporte de la comunicación. En un contexto en el que la red ad hoc debe soportar prioritariamente tráfico en tiempo real como la voz sobre IP, lo que puede corresponder a una situación de intervención de urgencia o a una red táctica, el transporte de datos utilizando los protocolos usuales, por ejemplo, el protocolo TCP se manifiesta no eficaz ya que es perjudicial en relación a los flujos en tiempo real o prioritarios al añadirles un retardo y produciendo pérdidas de paquetes. En efecto, los servicios en tiempo real generan un tráfico generalmente poco tolerante a las pérdidas de datos o de paquetes y quedan fuertemente afectados por los niveles elevados de congestión IP o de competición por el acceso al medio de comunicación, que engendra la utilización de protocolos tales como el TCP.

Una de las problemáticas del transporte de datos en unas redes ad hoc o de flujos en tiempo real que deben ser protegidos, es proporcionar un procedimiento que permita a un dato o a un flujo de datos, ser transmitido desde un origen a un destino sin degradar los rendimientos de flujos críticos tales como los flujos de voz sobre IP o VoIP o de “streaming video”.

Las problemáticas ligadas a las redes ad hoc han sido estudiadas por el grupo de investigación de la IETF (abreviatura inglesa de Internet Engineering Task Force) denominado MANET (Mobile Ad Hoc NETworks) disponible en el sitio de Internet: www.ietf.org/htlm.charters/manetcharter.html. Se han propuesto unas soluciones que mejoran los rendimientos del TCP en los entornos ad hoc inalámbricos [ATCP - Ad hoc Transport Control Protocol] [SNOOP] [TCPF - Transport Control Protocol Feedback]. Estas soluciones, que operan frecuentemente solamente en el origen, permiten mejorar los rendimientos del transporte de datos en las redes móviles ad hoc, pero no protegen los flujos críticos como los resultantes de los servicios VoIP. Por otro lado, otros enfoques modifican el protocolo TCP utilizando los mecanismos de gestión de la congestión “salto a salto” o “enlace a enlace” (más conocido en inglés por “hop by hop”), escrito, por ejemplo, en la publicación de Y.Yi abd S.Shakkottai “Hop-by-Hop Congestion Control over a wireless Multi-hop Network” IEEE/ACM Transaction on Networking, junio de 2007. Los nodos intermedios vuelven a subir unas notificaciones con destino a los nodos precedentes en el camino recorrido por el mensaje. Estos enfoques permiten una adaptación del TCP más precisa y más rápida pero no se ocupan de la protección de los flujos en tiempo real. También, los mecanismos de retransmisión quedan como mecanismos de punta a punta. Por otro lado, los mecanismos de calidad de servicio QoS IP clásicos tales como planificación (en inglés scheduling)

o de formateo (shaping en el acrónimo inglés) no permiten responder al problema expuesto anteriormente. Estos mecanismos tienen una visión demasiado local del entorno. En efecto, un nodo no tiene conocimiento más que del estado de sus colas de espera. Los nodos no conocen con precisión el nivel de competición para transmitir unos flujos en el medio y la naturaleza del tráfico que circula en el medio.

Otras soluciones propuestas por la técnica anterior implementan un transporte de datos del tipo “almacenamiento y transmisión”. Cuando una entidad recibe un mensaje, lo conserva hasta que lo transmite a su vez a un nodo intermedio o al destino. La información se transmite de manera atomizada (se transmite completamente en cada enlace) y es, generalmente pero no necesariamente autosuficiente, lo que es el caso por ejemplo, para un correo, un video, un documento de texto. Los nodos intermedios tienen por tanto una gran cantidad de memoria a su disposición. Estos paradigmas de la comunicación son similares a los definidos en la arquitectura de la Internet que transporta los correos [SMTP] o en la arquitectura de comunicación destinada a las redes tolerantes a retardos [DTNRG]. En [OTT06], los presentes autores muestran el potencial de uno de tales transportes en el marco de las redes ad hoc móviles en términos de rendimientos cuando el transporte en cada salto se efectúa utilizando UDP (User Datagram Protocol) a tasa constante (CBR: Constant Bit Rate).

[OTT06] J. Ott, D. Kutscher y C. Dwertmann, “Integrating DTN and MANET routing”, en Proc. CHANTS, 2006.

[RFC821]-RFC 821:-Simple-Mail-Transfer Protocol (SMTP). J. Postel.

[SNOOP] Hari Balakrishnan, Srinivasan Seshan y Randy H. Katz, “Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks”, ACM Wireless Networks, 1995.

[TCPF] K. Chandran, S. Raghunathan, S. Venkatesan y R. Prakash, “A feedback based scheme for improving TCP performance in Ad-Hoc wireless networks”, en Proc. of the International Conference on Distributed ComputingSystems (ICDCS’98), Ámsterdam, Holanda, mayo de 1998.

[ATCP] J. Liu and S. Singh, “ATCP: TCP for mobile ad hoc networks”, IEEE JSAC, vol. 19, nº 7, págs. 1300-1315, julio de 2001.

El inconveniente por ejemplo, de la solución de transporte descrita en [OTT06] es que implica unas transferencias atomizadas “salto a salto” entre el origen y el destino y utiliza un transporte UDP CBR en cada salto. Por lo tanto se muestra demasiado agresiva para los flujos en tiempo real y no es robusta puesto que no se prevé ningún mecanismo de retransmisión.

El objetivo de la presente invención es implementar un nuevo enfoque en el que la información se transmite no en forma de paquetes sino en forma de mensajes que contienen la información que puede ser autosuficiente y que se transfiere de entidades en entidades de manera atomizada. La invención se refiere a un procedimiento para transportar unos datos en una red inalámbrica ad hoc, la red comprende varios nodos en su configuración en un momento dado, un nodo de origen, un nodo de destino y varios nodos intermedios caracterizada porque comprende en el nivel de cada uno de los nodos al menos las etapas siguientes:

dividir el mensaje M a transmitir en N paquetes Pi, proporcionar un paquete Pi a las capas (C4, C5) de dicho nodo, Mientras que queden paquetes Pi por transmitir, medir unos parámetros que indican la calidad de los flujos en tiempo real en tránsito en dicho nodo, autorizar o no la transmisión de dichos paquetes Pi comparando los valores de los parámetros medidos con unos valores de umbral,

Si la transmisión se autoriza, entonces transmitir el paquete Pi en la capa MAC o en la capa de red.

Mientras que el paquete no haya sido enviado por la capa de red hacia otro nodo que forme parte de la ruta elegida, para transmitir este paquete hacia el nodo de destino:

medir los parámetros que indican la calidad de los flujos en tiempo real en tránsito sobre dicho nodo, autorizar o no la transmisión comparando los valores de los parámetros medidos con unos valores de umbral.

Si la transmisión no se autoriza:

retirar Pi de la cola de espera de la capa MAC (si es posible), volver al comienzo del bucle principal, es decir a la etapa en la que el procedimiento trata de transmitir de nuevo este paquete Pi, verificar que el paquete transmitido se ha recibido bien utilizando un mecanismo de indicación de la recepción y si el paquete ha sido recibido bien pasar al paquete siguiente Pi+1.

Surgirán otras características y ventajas con la lectura de la descripción detallada dada a modo de ejemplo y no limitativa que se realiza con relación a los dibujos adjuntos que representan:

•

La figura 1, el principio del transporte de un mensaje en el seno de la arquitectura descrita en la figura 2, y

•

La figura 2, un ejemplo de estructura de los módulos que permite la ejecución del procedimiento de acuerdo con la invención.

Con el fin de comprender mejor el objetivo de la presente invención, el procedimiento se describe en el caso de una transmisión de mensajes que contienen la voz sobre IP considerada como un flujo de datos prioritario con relación a otros tipos de datos, tales como los datos de gestión o incluso de puesta al día de ciertas bases de datos en el sistema.

Para ilustrar el procedimiento, en el caso de una aplicación para una red táctica, es posible imaginar que el flujo prioritario será el de una llamada de socorro, comparada con otras informaciones.

El procedimiento se puede implementar en la forma de un programa en una pila de protocolos. Se puede implementar también en la forma de un programa embebido.

La red en la que se implementa el procedimiento de acuerdo con la invención, descrita en la figura 1, es una red ad hoc que comprende varios nodos móviles que forman parte en un instante dado de la red y que pueden salir de ella.

El procedimiento se descentraliza entonces, es decir que cada nodo que constituye la red en un instante dado incluye todos los medios que permiten la emisión del mensaje, la recepción de informaciones, tal como la indicación de la recepción de un mensaje recibido, así como los módulos detallados en la figura 2 que permiten la ejecución de las etapas del procedimiento de acuerdo con la invención. El procedimiento se ejecuta salto a salto, es decir que el o los mensajes se transmiten en el seno de la red mediante un mecanismo conocido bajo la expresión inglesa “hop by hop”. Las aplicaciones que deseen transportar unos datos de un origen a un destino transmiten en la pila de protocolos dada como ejemplo en los mensajes. Estos se transportan entonces salto a salto a lo largo de una ruta determinada por las tablas de enrutado y las tablas de vecinos contenidas en los nodos, como se explica a continuación.

En la figura 1, se representa la imagen de una red en un instante dado, incluyendo un nodo de origen 1, varios nodos intermedios 2i y un nodo de destino 3.

El nodo de origen 1 comprende una capa de aplicación C1, una capa en la que transitan los mensajes a transmitir C2, una capa de transporte C3, una capa de red C4, una capa de enlace C5 y una capa física C6. Estas capas son conocidas para el experto en la materia y no se detallarán en la presente descripción.

El nodo de destino 3 incluye el mismo número de capas que el nodo de origen 1.

Los nodos intermediarios, o nodos de conmutación, que forman parte del camino recorrido por un mensaje no incluyen la capa de aplicación, o al menos esta capa no se utiliza.

La figura 2 representa los diferentes módulos incluidos en un nodo de la red que permiten tratar los mensajes que no son considerados como unos mensajes prioritarios. El módulo 10 no genera más que unos mensajes no prioritarios. Los otros flujos de datos considerados en la aplicación como unos flujos prioritarios se generan por las otras aplicaciones y no se describirán porque no intervienen en las etapas implementadas por el procedimiento de acuerdo con la invención.

El módulo 10, aplicación DTN, se refiere a las aplicaciones situadas en el origen (nodo de origen en este ejemplo) y en el destino de los mensajes (nodo de destino). Un módulo 10 genera y recibe unos mensajes M que consisten en una información que puede ser autosuficiente, como unas imágenes o unos mensajes electrónicos, pero no necesariamente. Los mensajes M tienen potencialmente unos tamaños cualquiera. Estas aplicaciones no tienen limitaciones en tiempo real.

10.

Aplicación DTN: Aplicación que genera unos flujos de datos sin limitaciones en tiempo real.

11.

API: Las aplicaciones transmiten y reciben los mensajes por intermedio de esta API (Application Programming Interface – denominación inglesa de Interfaz de Programación).

12.

Base de datos de mensajes: Los nodos de la red que utilizan el procedimiento están provistos de una memoria que les permite almacenar los mensajes en tránsito, es decir que están destinados a ser vueltos a emitir hasta su nodo de destino. Esta base de datos se rellena o lee por las aplicaciones con la ayuda de la API precedente.

13.

Tabla de enrutado: Esta tabla contiene las rutas que indican qué nodo de conmutación elegir, para alcanzar tal o cual destino. Esta tabla se rellena por un protocolo de enrutado que puede ser del tipo unicast IP (por ejemplo OLSR) o del tipo DTN (por ejemplo, ProPhet – Probabilistic Routing Protocol using History of Encounters and Transitivity) [LIN04]. Estos mecanismos son conocidos por el experto en la materia en el dominio del enrutado y no se detallarán.

14.

Tabla de vecindad: Esta tabla contiene la lista de los nodos con los que el nodo actual está en contacto (por ejemplo, en enlace de radio). Igualmente, el procedimiento utiliza los mecanismos clásicos para la tabla de vecindad.

15.

Programación de las transferencias: Este módulo permite decidir qué mensaje debe en la actualidad ser transferido por el módulo de transferencia oportunista 16 descrito a continuación. Esta decisión se toma utilizando las informaciones suministradas por las tablas de enrutado y de vecindad así como por los mecanismos eventuales que generan las prioridades entre los mensajes. Un nodo no deberá estar implicado más que en una transferencia de mensajes a la vez, pero esta propiedad no es absoluta.

16.

Módulo de transmisión oportunista: Este módulo se encargará del transporte de los mensajes de un nodo a otro. Realiza una descomposición del mensaje a transmitir en paquetes (por ejemplo, puede dividir el mensaje en varios paquetes IP). Es el que toma la decisión en cada instante, de dar o no el próximo paquete en espera a la capa MAC en función de las informaciones devueltas por el módulo de medición 8. Este módulo comprende un contador 22 que permite seguir el número de paquetes Pi transmitidos.

17.

Módulo de medición: Este nodo devuelve al módulo de transmisión oportunista 16 los valores de los parámetros medidos localmente o en la vecindad. Por ejemplo, los parámetros medidos pueden ser la variación media y la tasa de pérdida media de los flujos en tiempo real en tránsito en la zona de cobertura por radio del nodo o cualquier otro parámetro que un experto en la materia considere que es útil para decidir sobre la transmisión de los datos. Así, el módulo de transmisión oportunista 16 está adaptado para evaluar si los envíos de paquetes que están a punto de generar van a engendrar una competición que pueda degradar los flujos en tiempo real. La decisión de enviar o no el próximo paquete por el módulo de transferencia oportunista 16 puede ser tomada por ejemplo utilizando unos umbrales sobre los valores de los parámetros

medidos por el presente módulo de medición 17.

De manera general, las mediciones que efectúa el módulo pueden integrar unas informaciones locales, por ejemplo unas estadísticas devueltas por el “driver” 21 que se refieren a las transmisiones que se han efectuado en un pasado próximo (informaciones que se refieren a los flujos en tiempo real en tránsito sobre el nodo actual) o que provienen de la vecindad (por ejemplo, los flujos en tiempo real intercambiados con la vecindad, estadísticas que se refieren a las interfaces por aire de los nodos vecinos obtenidos por un protocolo de “beaconing”). El módulo de medición se puede basar en el estado de atasco de las arterias de la red o de las arterias en enlace con el nodo considerado.

18.

CAC: Este módulo decide si el nodo actual tiene capacidad de aceptar una transferencia entrante de mensajes. Esta decisión se toma teniendo cuenta las informaciones que se refieren al tamaño de la base de datos 12, las eventuales transferencias que han sido programadas por 14 o unas informaciones que se refieren al estado del nodo (por ejemplo, energía).

19.

Módulo de recepción: Este módulo asegura la recepción de los mensajes de datos. Puede devolver o no unos acuses de recibo o en inglés “acknowledgements” al nodo emisor (por ejemplo ACK, SACK – Selective ACKnowledgement). Una vez recibido el mensaje completamente, este módulo de recepción lo almacena en la base de datos de mensajes 12.

20.

Control de la congestión: Este módulo opcional permite intercambiar unos mensajes entre los nodos que participan en las transferencias con el fin de asegurar un control de la congestión de punta a punta o de manera global en la red.

21.

Capa MAC: Este módulo representa la capa de acceso al medio. Esta capa se especifica en cada tipo de interfaz de radio. Es capaz de suministrar unas estadísticas al módulo de medición 17 y es capaz de transmitir y recibir unos paquetes sobre la interfaz por aire.

22.

Contador: Este módulo representa el contador utilizado durante la transmisión de un mensaje por el protocolo de transporte (16).

[LIN04] Lindgren A., Doria A., Schelén O. Probabilistic Routing in Intermittently Connected Networks. LNCS, Vol. 3126. 2004.

El procedimiento aplicado por la presente invención comprende, por ejemplo, las etapas siguientes:

La aplicación 10 ha generado un mensaje, este último se transmite a la aplicación 11 que sirve de interfaz con la base de datos 12 en la que los mensajes a transmitir se memorizan. Los mensajes se recuperan a continuación por el planificacor 15 que está a cargo de planificar su transferencia. Esta planificación se efectúa utilizando las informaciones que provienen de la tabla de enrutado 13 e indican la o las rutas disponibles para transmitir el o los mensajes y también unas informaciones que provienen de la tabla que contiene los nodos vecinos 14 que indican si el nodo siguiente en la ruta está disponible o no. El planificador puede recibir también un mensaje de indicación de la recepción o de buena recepción que proviene del módulo de recepción 19. Una vez recibido el mensaje de indicación de la recepción, el mensaje que se ha transmitido correctamente y por tanto remitido a su destinatario, puede ser eliminado de la base de datos.

Los mensajes que provienen del planificador 15 se transmiten en seguida hacia el módulo de transferencia oportunista 16 que se encarga de la transferencia del mensaje en el próximo salto. Para esto, utiliza las mediciones efectuadas por el módulo de medición 17 que tiene en cuenta unos parámetros medidos en la vecindad de radio que se refieren a los flujos en tiempo real que se desea proteger.

El algoritmo distribuido de decisión de envío de los mensajes en el marco del protocolo de transporte oportunista 16 comprende las etapas descritas a continuación. Se aplica en el nivel de cada nodo que constituye una red en un instante dado.

La ruta utilizada para transmitir un mensaje se determina a partir de las informaciones contenidas en la tabla de enrutado y en la tabla que da los vecinos más próximos utilizando un mecanismo o unas técnicas conocidas por el experto en la materia.

El mensaje generado por la aplicación 10 se pone en una cola de espera principal en el nivel de un nodo. Una primera etapa consiste en fraccionar el mensaje M en N paquetes Pi. El número N es inicialmente conocido. Es posible utilizar un contador inicializado a 0 o a N según se elija incrementar este contador o disminuirlo, cada vez que se transmite un paquete Pi.

Un paquete Pi se da a la capa de red o a la capa MAC (Medium Access Control designación inglesa del Control de Acceso al Medio).

Mientras queden paquetes Pi por transmitir:

Verificar si los parámetros devueltos por el módulo de medición 17 al módulo del protocolo oportunista 16 indican que se puede realizar una transferencia sin degradar los flujos en tiempo real próximos,

Si e así, entonces transmitir el paquete Pi a la capa MAC o a la capa de red,

Mientras que el paquete Pi no haya sido enviado por la capa MAC con la capa de red hacia otro nodo 2j que forma parte de la ruta elegida, para transmitir este paquete hacia el nodo de destino, Si el momento no es oportuno para una transmisión de datos (decisión tomada por el módulo de medición y transmitida al módulo de transporte oportunista que destaca unos parámetros que han evolucionado de manera desfavorable para la transmisión), entonces:

√ retirar el paquete Pi de la cola de espera de la capa MAC, √ activar un mecanismo adaptativo del tiempo de espera, por ejemplo un mecanismo de Back off (por ejemplo, AIMD – Additive Increase-Multiplicative Decrease), siendo esta etapa facultativa. √ volver al comienzo del bucle principal, es decir que el procedimiento trata de transmitir de nuevo este paquete Pi, verifica si el momento es oportuno para transmitir el paquete Pi,

Verificar que el paquete se ha recibido bien, esto puede hacerse utilizando las informaciones suministradas por la capa MAC o implementando un mecanismo de indicación de la recepción en el módulo de recepción de un nodo. Pueden ser utilizados otros mecanismos de indicación de la recepción como el mecanismo de acuse de recibo selectivo conocido bajo la abreviatura inglesa SACK (Selective ACKnowledgement). Si el paquete se ha recibido bien, se incrementa entonces un contador 22 asociado a Pi en 1, pasándose al paquete Pi+1.

Esperar un tiempo aleatorio, constante o calculado con otro mecanismo como AIMD por ejemplo, siendo esta etapa facultativa.

Para cada paquete Pi a transmitir, el protocolo de transferencia oportunista 16 espera a que el módulo de medición 17 le indique una buena oportunidad. Cuando las condiciones son favorables, el protocolo oportunista transmite el paquete a la capa MAC. En el caso de que el envío no se haya podido realizar por la capa MAC, el proceso se reitera, se trata de retransmitir el mismo paquete Pi antes de transmitir el paquete siguiente en la cola de espera Pi+1. Por otro lado, cuando el paquete se pone en espera en el nivel de la capa MAC y las condiciones de transmisión se convierten en desfavorables, se puede utilizar entonces un mecanismo de “Back off” para reiterar el intento de transmisión, por ejemplo, después de unos periodos de tiempo linealmente decrecientes. Para esto, es posible utilizar el algoritmo AIMD (Additive Increase Multiplicative Decrease) que presenta como particularidad conservar en la memoria el contexto, si hay un fracaso en la transmisión del paquete, se espera; en caso de éxito hay disminución del tiempo de espera. Es posible también aplicar cualquier otra solución conocida para el experto en la materia. Finalmente, después de cada éxito o fracaso, se puede aplicar un tiempo de espera constante.

El módulo de transferencia oportunista genera y decide los instantes de transmisión y las esperas.

El tiempo de espera puede ser aleatorio en el caso de que no haya coordinación entre los nodos. En otros casos, este tiempo es nulo y el intento de retransmisión de un paquete es casi inmediato.

La invención permite por tanto transportar una información almacenada en la forma de mensajes de un origen a un destino protegiendo además el tráfico en tiempo real como el resultante de la voz sobre IP.

Claims (8)

1. REIVINDICACIONES

   1. Procedimiento para transportar unos datos en una red inalámbrica ad hoc, comprendiendo la red varios nodos en una configuración en un instante dado, un nodo de origen (1), un nodo de destino (3) y varios nodos intermedios (2i) caracterizado porque comprende en el nivel de cada uno de los nodos al menos las etapas siguientes:

   dividir el mensaje M a transmitir en N paquetes Pi,

   se proporciona un paquete Pi a las capas (C4, C5) de dicho nodo (2i),

   Mientras que queden paquetes Pi por transmitir:

   medir los parámetros que indican la calidad de los flujos en tiempo real en tránsito sobre dicho nodo (2i), autorizar o no la transmisión de dichos paquetes Pi comparando los valores de los parámetros medidos con unos valores de umbral (16, 17),

   Si la transmisión se autoriza, entonces transmitir uno de dichos paquetes Pi a la capa de Medium Access Control, abreviada en lo que sigue como MAC, o a la capa de red.

   Mientras que el paquete no haya sido enviado por la capa de la red hacia otro nodo que forme parte de la ruta elegida, para transmitir este paquete hacia el nodo de destino:

   medir los parámetros que indican la calidad de los flujos en tiempo real en tránsito sobre dicho nodo (2i), autorizar o no la transmisión comparando los valores de los parámetros medidos con unos valores de umbral (16, 17),

   Si la transmisión no se autoriza:

   retirar Pi de la cola de espera de la capa MAC (si es posible), volver al comienzo del bucle principal, es decir a la etapa en la que el procedimiento trata de transmitir de nuevo este paquete Pi,

   Verificar que dicho paquete Pi transmitido se ha recibido bien utilizando un mecanismo de indicación de la recepción y si el paquete ha sido recibido bien, pasar al paquete siguiente Pi+1.

2. 2.

   Procedimiento de acuerdo con la reivindicación 1, caracterizado porque entre los dos intentos para transmitir un paquete Pi, el procedimiento aplica un retardo de espera constante o variable.

3. 3.

   Procedimiento de acuerdo con la reivindicación 1, caracterizado porque después de haber retirado el paquete de la cola de espera, el procedimiento activa un mecanismo de tiempo de espera.

4. 4.

   Procedimiento de acuerdo con la reivindicación 3, caracterizado porque el mecanismo de tiempo de espera es un mecanismo de Back off del tipo Additive Increase Multiplicative Decrease, AIMD.

5. 5.

   Dispositivo que permite transportar unos flujos de datos en una red que comprende varios nodos en una configuración dada en un instante dado y que dispone unos medios para ejecutar las etapas del procedimiento de acuerdo con una de las reivindicaciones 1 a 4, caracterizado porque comprende en combinación al menos los elementos siguientes:

   √ Una base de datos (12) que almacena el o los mensajes a transmitir, √ Un módulo de control de la congestión (20) ligado a dicha base de datos, √ Un planificador que tiene por entradas los mensajes almacenados en la base de datos, la ruta determinada para un mensaje por una tabla de enrutado (13) y una tabla de los nodos vecinos (14), y una información resultante de un módulo receptor (19), √ Un módulo que comprende un protocolo de transporte oportunista (16) que recibe las informaciones del planificador (15) y un módulo de medición (17), estando adaptado dicho protocolo de transporte oportunista para dividir un mensaje a transmitir en N paquetes Pi, y transmitir los dichos paquetes a la capa de red de dicho nodo, comprendiendo dicho módulo un contador (22), √ Un módulo (18) adaptado para decidir si el nodo actual está capacitado para aceptar una transferencia entrante de mensajes.

6. 6.

   Dispositivo de acuerdo con la reivindicación 5, caracterizado porque el módulo de medición (17) está adaptado para medir unos valores de parámetros medidos localmente y/o en la vecindad de un nodo.

7. 7.

   Dispositivo de acuerdo con la reivindicación 6, caracterizado porque los parámetros medidos son la variación media y la tasa de pérdida media de los flujos en tiempo real en tránsito en la zona de cobertura de dicho nodo.

8. 8.

   Dispositivo de acuerdo con la reivindicación 5, caracterizado porque la red es una red ad hoc.