ES2366373T3 - Selección de ruta en redes inalámbricas. - Google Patents

Selección de ruta en redes inalámbricas. Download PDF

Info

Publication number
ES2366373T3
ES2366373T3 ES05824653T ES05824653T ES2366373T3 ES 2366373 T3 ES2366373 T3 ES 2366373T3 ES 05824653 T ES05824653 T ES 05824653T ES 05824653 T ES05824653 T ES 05824653T ES 2366373 T3 ES2366373 T3 ES 2366373T3
Authority
ES
Spain
Prior art keywords
route
node
rreq
message
destination
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES05824653T
Other languages
English (en)
Inventor
Hang Liu
Original Assignee
Thomson Licensing SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Application granted granted Critical
Publication of ES2366373T3 publication Critical patent/ES2366373T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/26—Route discovery packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/32—Flooding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/023—Limited or focused flooding to selected areas of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/248—Connectivity information update
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/28—Connectivity information management, e.g. connectivity discovery or connectivity update for reactive routing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Alarm Systems (AREA)
  • Input Circuits Of Receivers And Coupling Of Receivers And Audio Equipment (AREA)
  • Radar Systems Or Details Thereof (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Método para localizar una ruta entre un nodo de origen (A) y un nodo de destino (E) en una red inalámbrica, comprendiendo dicho método: La diseminación a través de dicha red inalámbrica de un mensaje de petición de ruta (RREQ) por parte de dicho nodo de origen (A); y La recepción de un mensaje de respuesta de ruta (RREP) a dicho mensaje de petición de ruta (RREQ) procedente de un primer nodo intermedio (B) que tiene una ruta válida hacia dicho nodo de destino (E) caracterizado porque dicho primer nodo intermedio (B) responde a dicho mensaje de petición de ruta (RREQ) cuando se establece una bandera (IR) en dicho mensaje de petición de ruta (RREQ) y porque dicho primer nodo intermedio (B) disemina de nuevo en dicha red inalámbrica dicho mensaje de petición de ruta (RREQ) con dicha bandea (IR) reinicializada.

Description

CAMPO DE LA INVENCIÓN
La presente invención se refiere a redes inalámbricas, y más concretamente, a las redes en malla. Más concretamente, la presente invención se refiere al procesamiento de mensajes de petición de ruta en protocolos de asignación de ruta previa petición.
ANTECEDENTES DE LA INVENCIÓN
Los protocolos de asignación de ruta previa petición, como por ejemplo, el protocolo ad hoc de asignación de ruta de Vector de Distancia previa petición (AODV) definido por el grupo de trabajo MANET del IETF utilizan un mecanismo de Petición de ruta y de Respuesta de Ruta para el establecimiento de rutas entre dos nodos, en redes inalámbricas en malla ad hoc. Cuando un nodo de origen desea enviar paquetes/tramas de datos a un nodo de destino, el nodo de origen descubre la ruta hacia el destino mediante la dispersión de un mensaje de petición de Ruta (RREQ) a través de la red si el nodo de origen carece y necesita una ruta válida hacia el nodo de destino. Los nodos de la red crean una ruta inversa de retorno al origen a medida que reciben y remiten el RREQ. Cuando un nodo recibe un RREQ, el nodo receptor responde a esta solicitud generando un mensaje de respuesta de ruta (RREP) si se da cualquiera de las siguientes situaciones: (1) el propio nodo receptor es el de destino, o (2) el nodo receptor dispone de una ruta válida hacia el destino, y la bandera de “solo destino” (“D”) del RREQ NO0 se encuentra activada. El RREP se envía en modo unidifusión al nodo de origen a través de la ruta inversa establecida y de una ruta directa al destino en los nodos intermedios, y eventualmente, se crea en el nodo de origen. Las rutas establecidas expiran en el caso de que no utilizarse dentro de un período de vida útil de la ruta determinado.
En el protocolo AODV, la bandera de “sólo destino” del mensaje RREQ es fijada por el nodo origen, y no se ve alterada por los nodos intermedios. Si el nodo origen ha fijado en el RREQ la bandera de “sólo destino”, el nodo intermedio no responde al RREQ con un mensaje RREP, aun cuando el nodo intermedio/receptor disponga de una ruta válida hacia el nodo de destino. En cambio, reenvía/difunde el RREQ entre los nodos adyacentes. Tan sólo el nodo de destino responde a este RREQ. En este modo de funcionamiento, la latencia de descubrimiento de la ruta puede ser amplia, aunque eventualmente se descubra en el transcurso del proceso la mejor ruta encontrada hasta el momento entre el nodo de origen y el nodo de destino. Una latencia baja resulta muy importante para las aplicaciones en tiempo real, como las comunicaciones de voz y vídeo.
Si el nodo de origen no ha seleccionado la bandera de “sólo destino”, cualquier nodo intermedio con una ruta válida hacia el nodo de destino responderá al RREQ con un mensaje RREP. El mensaje RREP se devolverá al nodo de origen en modo unidifusión y establecerá una ruta de avance hacia el nodo de destino. Si se fija la bandera “RREP gratuito” (“G”) en el RREQ, este nodo intermedio también transmite en unidifusión un RREP gratuito al nodo de destino, de forma que el nodo de destino aprenda las rutas hacia el nodo de origen. No obstante, en el AODV, si un nodo intermedio no genera un RREP (debido a que el nodo intermedio carece de una ruta válida hacia el nodo de destino) el nodo intermedio descartará entonces el RREQ. Mediante este método, el nodo de origen puede descubrir una ruta hacia el nodo de destino con mayor rapidez, debido a que el nodo de origen no precisa esperar la respuesta del nodo de destino. No obstante, la mejor ruta de extremo a extremo podría no llegar descubrirse, ya que la ruta captada en el nodo intermedio podría no ser la mejor ruta hacia el nodo de destino. Las métricas podrían haber cambiado a causa de la dinámica de las redes inalámbricas, haciendo que la ruta captada resulte menos deseable. Es decir, que debido a los cambios en la topología de la red, la métrica de asignación de ruta, etc. Es posible que la ruta captada en el nodo intermedio pueda ser peor, o que puedan aparecer otras rutas con una mejor métrica de extremo a extremo, haciendo que otras rutas resulten más deseables.
Perkins et al., en el documento “Ad-hoc On-Demand Vector Routing” (en PROCEEDINGS WMCSA, 25 de febrero de 1999, XP002173721) describen un algoritmo de asignación de ruta ad hoc del vector previa petición (AODV) para la operación de asignación de ruta en una red inalámbrica sin un punto de acceso centralizado. Este algoritmo se basa en entradas de tabla de establecimiento dinámico de la ruta en los nodos intermedios, y utiliza un mecanismo de Petición de ruta (RREQ) y de respuesta de ruta (RREQ). Este algoritmo reduce la demora en el hallazgo de una ruta hacia el nodo del destino, pero sin embargo, a diferencia del mecanismo de asignación de rutas de extremo a extremo en origen, el sistema no resulta adecuado para descubrir la mejor ruta (es decir, la que tiene la métrica más baja) de extremo a extremo. Dado que el mensaje RREQ no se propaga al nodo de destino cuando se encuentra una ruta válida en un nodo intermedio, la métrica de la ruta de extremo a extremo no se comunica sistemáticamente en mensajes RREP al nodo de origen, y la ruta válida captada en el nodo intermedio puede no ser la mejor ruta hacia el nodo de destino.
El documento WO 01/41375 describe un algoritmo para protocolos de asignación de rutas ad hoc, bien basado en la asignación de rutas en origen o la asignación de vector de distancia. De acuerdo con WO 01/41375, se diseminan por la red solicitudes ordinarias de asignación de rutas en origen o mensajes actualizados de solicitud de asignación de ruta, identificados mediante una bandera, cuando se produce un evento predeterminado, como la expiración de un contador, un enlace roto …. Sin embargo, WO 01/41375 no consigue revelar un sistema adecuado para descubrir con rapidez una ruta entre un nodo de origen y un nodo de destino y descubrir la mejor ruta entre un nodo de origen y un nodo de destino en respuesta a una petición del origen, limitando al mismo tiempo los mensajes de petición/respuesta de la red.
El documento EP1467524 describe un algoritmo para el protocolo ad-hoc de asignación de rutas de red adecuado en materia de calidad del servicio, comprendiendo las demoras y el ancho de banda de comunicaciones. De acuerdo con el documento EP1467524, además del menor coste del enlace, y del número de secuencia se tienen en cuenta otros criterios, tal como el ancho de banda del enlace, a la hora de establecer la mejor ruta entre nodos. No obstante, en lo que respecta a la técnica anterior citada, EP1467524 no describe un sistema adecuado para descubrir con rapidez una ruta entre un nodo de origen y un nodo de destino y para descubrir la mejor ruta entre un nodo de origen y un nodo de destino.
El problema que resuelve la presente invención es cómo utilizar el mecanismo RREQ y RREP para descubrir con rapidez la mejor ruta entre un nodo de origen y uno o más nodos de destino.
SUMARIO DE LA INVENCIÓN
La presente invención describe un método y un sistema para procesar y enviar mensajes de petición de ruta (RREQ) y para la generación de mensajes de respuesta de ruta (RREP) en protocolos de asignación de ruta previa petición, de los cuales constituye un ejemplo el AODV, de forma que se pueda descubrir la mejor ruta sin incurrir en demoras/latencia importantes en el descubrimiento de la ruta en redes inalámbricas en malla/ad hoc. Concretamente, cuando un nodo de origen desea descubrir la ruta hacia un nodo de destino, el nodo de origen disemina a través de la red un mensaje RREQ con el nodo de destino especificado en la lista de destinos y el campo correspondiente a la métrica inicializado a 0. El mensaje RREQ contiene una nueva bandera “respuesta Intermedia” (IR)” para cada nodo de destino. El nodo de origen establece la bandera correspondiente al modo de destino en el RREQ cuando inicia la diseminación del RREQ para descubrir una ruta hacia el nodo de destino. Durante la diseminación del RREQ, el primer nodo intermedio con una ruta válida hacia el nodo de destino responde al RREQ con un mensaje RREP. El mensaje RREP se envía en modo unidifusión hacia el nodo de origen, y por tanto, establece con rapidez una ruta temporal de envío hacia el destino. De este modo, el nodo de origen puede utilizar esta ruta de envío provisional para el envío de paquetes/tramas de datos con una baja latencia/demora en el descubrimiento de la ruta. El primer nodo intermedio reinicializa/borra la bandera “IR” en el mensaje RREQ y envía el mensaje RREQ actualizado hacia el nodo de destino. Teniendo en cuenta que la bandera “IR” del RREQ se ha reinicializado, los nodos intermedios posteriores no responderían a este RREQ y sólo lo propagarían si los nodos intermedios posteriores cuentan con una ruta válida hacia los nodos de destino. Los RREQs alcanzan eventualmente el nodo de destino. Los nodos de destino pueden seleccionar la mejor ruta/trayectoria en función de la métrica de extremo a extremo y enviar un nuevo RREP de vuelta al nodo de origen, a fin de establecer la mejor ruta entre el nodo de origen y este nodo de destino. En el caso de que la mejor trayectoria sea diferente de la vía de envío provisional establecida a través del RREP desde el nodo intermedio, el nodo de origen conmutará a la mejor trayectoria, una vez que se haya establecido dicha mejor trayectoria.
En el presente documento se describen un sistema y un método para el descubrimiento de una ruta entre un nodo de origen y un nodo de destino en una red inalámbrica, comprendiendo el establecimiento de una bandera de respuesta intermedia de un mensaje de petición de ruta por parte del nodo de origen, la diseminación a través de la red inalámbrica del mensaje de petición de ruta y la respuesta al mensaje de petición de ruta con un mensaje de respuesta de ruta por parte de un primer nodo intermedio que cuente con una ruta válida hacia el nodo de destino. El sistema y el método actualizan entonces el mensaje de petición de ruta y vuelven a diseminar el mensaje de petición de ruta a través de la red inalámbrica. La respuesta establece una ruta de envío provisional entre el nodo de origen y el nodo de destino de la red inalámbrica.
También se describen un sistema y un método para el descubrimiento de la mejor ruta, en cuyo caso el mensaje de respuesta de ruta se convierte en un primer mensaje de respuesta de ruta. El sistema y el método para el descubrimiento de una mejor ruta incluyen la selección por parte del nodo de destino de la mejor ruta entre sí mismo y el nodo de origen, en función de la métrica acumulada recibida en los mensajes de petición de ruta recibidos por el nodo de destino, creando un mensaje adicional de respuesta de ruta y el envío mediante unidifusión del mensaje adicional de respuesta de ruta al nodo de origen. Si la ruta de envío provisional es la mejor ruta, el mensaje adicional de respuesta de ruta sirve de confirmación, y si la ruta de envío provisional no es la mejor ruta, el mensaje adicional de respuesta de ruta sirve para establecer la mejor ruta cuando el nodo de origen reciba el mensaje adicional de respuesta de ruta.
BREVE DESCRIPCIÓN DE LAS DIBUJOS
La presente invención se entenderá mejor gracias a la siguiente descripción detallada, leída conjuntamente con las figuras adjuntas. Los dibujos incluyen las siguientes figuras, que se describen brevemente a continuación:
La figura 1 es un ejemplo de formato de mensaje RREQ.
La figura 2 es una vista esquemática de una red inalámbrica mallada de acuerdo con los principios de la presente invención.
La figura 3 es un diagrama esquemático de una red inalámbrica mallada de acuerdo con los principios de la presente invención.
La figura 4 es un diagrama de flujo de un protocolo de asignación de ruta previa petición en el que se muestra el uso de la presente invención.
La figura 5 es un diagrama de flujo del método de la presente invención.
La figura 6 es un diagrama de bloques de un nodo acorde con los principios de la presente invención.
DESCRIPCIÓN DETALLADA DE LAS REALIZACIONES PREFERIDAS
Cuando un punto de origen de nodo/malla desea enviar paquetes/tramas de datos a algún nodo de destino, busca una ruta en su tabla de asignación de rutas. Si existe una ruta válida, transmite los paquetes/tramas al siguiente salto especificado en la tabla de asignación de rutas para este nodo de destino. Si no existe una ruta válida, el nodo de origen inicia el descubrimiento de la ruta diseminando un mensaje de petición de ruta (RREQ) a través de la red inalámbrica mallada/ad hoc. Los paquetes/tramas de datos pueden haberse originado en/con el nodo o desde estaciones asociadas al nodo, en el caso de que el nodo sea un punto de acceso inalámbrico. Es posible que un nodo de origen precise descubrir rutas/trayectorias hacia múltiples puntos de destino. El nodo de origen puede diseminar un mensaje RREQ para cada destino o, para reducir la carga de la asignación de ruta, diseminar a través de la red un solo mensaje RREQ que contenga una relación de múltiples direcciones de nodo de destino incorporadas al mismo.
La figura 1 es un ejemplo de formato de mensaje RREQ, siendo posibles otros formatos. El mensaje RREQ contiene, por ejemplo, la dirección del nodo de origen/fuente, el número de secuencia del originador, la dirección del nodo de destino y el número de secuencia del destino (o el número de destinos y la relación de direcciones de destino y sus números de secuencia), la ID del RREQ, la ID del mensaje, la longitud del mensaje, la duración efectiva (TTL), el recuento de saltos, la métrica de asignación de ruta, las banderas y otras informaciones. Además de las banderas “sólo destino” (“D”) y “RREP gratuito (“G”), el mensaje RREQ contiene una nueva bandera, denominada en este documento bandera de “respuesta Intermedia” (IR). Las banderas “D” y “G” se transportan como herencia del AODV convencional. Estas dos banderas no son fijadas ni utilizadas por el nodo de origen y son ignoradas por los nodos intermedio y de destino. Una realización alternativa es que el mensaje RREQ no contenga en absoluto las banderas “D” y “G”. Si el mensaje RREQ incluye una lista de direcciones de destino, se incluirán múltiples banderas de “respuesta Intermedia” en el mensaje RREQ, y cada una de ellas corresponde a una dirección de destino. Cuando el nodo de origen desea descubrir una ruta hacia una o más direcciones de destino, establece la banderas “respuesta Intermedia” (IR) correspondientes a las direcciones de destino. Debe observarse que las direcciones del nodo de destino pueden ser direcciones del protocolo de Internet (IP) o direcciones de la capa 2 (control de acceso al medio - MAC). Para adaptarse a los cambios en las condiciones de red y mantener la mejor ruta de métrica entre nodos, cada nodo de origen activo puede diseminar opcionalmente en la red inalámbrica mallada/ad hoc un mensaje periódico RREQ (RREQ de mantenimiento) para las direcciones de destino con las que se está comunicando. No se fija la bandera “IR” del RREQ de mantenimiento. Los nodos intermedio y de destino procesan el RREQ de mantenimiento siguiendo las mismas reglas utilizadas para procesar un RREQ que no sea de mantenimiento en la fase de descubrimiento.
De este modo, puede apreciarse que la diseminación de mensajes RREQ de mantenimiento y de no mantenimiento en una red inalámbrica mallada/ad hoc tiene como resultado el establecimiento/actualización de una ruta inversa hacia el originador (nodo de origen) del RREQ en los nodos intermedios y los nodos de destino. La diseminación de mensajes RREQ que no sean de mantenimiento también inicia el envío de mensajes RREP desde los nodos de destino, y probablemente, desde los nodos intermedios. La diseminación de mensajes RREQ de mantenimiento también inicia el envío de mensajes RREP desde los nodos de destino. Cuando un nodo intermedio o de destino recibe un mensaje RREQ, crea una ruta inversa hacia el nodo de origen o actualiza su actual ruta inversa si el mensaje RREQ se ha hecho pasar a través de una ruta/trayectoria que ofrecía una métrica superior a la de la ruta inversa actual hacia el nodo de origen. Debe observarse que cada nodo puede recibir múltiples copias del mismo mensaje RREQ (con origen en el mismo nodo de origen y con la misma ID de RREQ), cada mensaje RREQ que recorra una trayectoria diferente desde el nodo de origen hacia el nodo receptor/intermedio/de destino. Si se crea o se modifica una ruta inversa o se trata de la “primera copia” de un mensaje RREQ, el mensaje RREQ se retransmitirá (re-diseminará). En este documento se utiliza el término “primera copia” para indicar que esta copia de este mensaje RREQ es la primera copia o es la primera vez que este nodo receptor/intermedio/de destino ha recibido o visto este mensaje RREQ específico identificado por la dirección de su originador y la ID del RREQ. Cuando un nodo intermedio envía un mensaje RREQ, el campo de métrica del mensaje RREQ se actualiza para reflejar la métrica acumulada de la ruta hacia el nodo de origen RREQ desde el nodo intermedio. Además, si se fija la bandera “IR” para un nodo de destino de la lista de nodos de destino del mensaje RREQ recibido y el nodo intermedio cuenta con una ruta válida hacia el nodo de destino, el nodo intermedio responde al mensaje RREQ con un mensaje de respuesta de ruta RREP. Este mensaje de respuesta de ruta se envía al nodo de origen en formato unidifusión y establece una trayectoria de envío hacia el nodo de destino. El nodo de origen puede entonces utilizar esta ruta para el envío inmediato de tramas/paquetes de datos hacia el nodo de destino. Si el nodo intermedio responde al mensaje RREQ con un mensaje RREP para un nodo de destino de la lista de nodos de destino RREQ, reinicializa/borra la bandera “IR” correspondiente a este nodo de destino en el mensaje RREQ antes de volver a diseminar en la red el mensaje RREQ actualizado. El motivo de la reinicialización de la bandera “IR” después del envío de un mensaje RREP es suprimir cualquier mensaje RREP procedente de los nodos intermedios posteriores. Tan sólo el primer nodo intermedio con una ruta válida hacia el nodo de destino a lo largo de la ruta atravesada por la diseminación de mensajes RREQ responde con un mensaje RREP correspondiente a este nodo de destino. Si la bandera “IR” correspondiente a un destino se reinicializa/borra en el mensaje RREQ, un nodo intermedio no debería responder con un mensaje RREP aun cuando disponga de una ruta válida hacia el nodo de destino.
Después de crear/establecer o actualizar una ruta inversa hacia el nodo de origen, el nodo de destino envía de vuelta un mensaje RREP en modo unidifusión al nodo de origen. Los nodos intermedios crean rutas de envío hacia los nodos de destino cuando se recibe el mensaje RREP, y también envían el mensaje RREP hacia el nodo de origen. Cuando el nodo de origen recibe el mensaje RREP, crea una ruta de envío hacia el nodo de destino. Si el nodo de destino recibe otros mensajes RREQ con una métrica más adecuada, el nodo de destino actualiza su ruta hacia el nodo de origen de acuerdo con la nueva ruta, y también envía un nuevo mensaje RREP hacia el nodo de origen a lo largo de la ruta actualizada. El nuevo mensaje RREP establece una ruta de envío mejor (actualizada) desde el nodo de origen hacia el nodo de destino en los nodos intermedios, y eventualmente en el nodo de origen. Una vez establecida esta mejor ruta de envío, el nodo de origen la utiliza para el envío de los datos. Eventualmente, se establece una mejor ruta bidireccional de métrica de extremo a extremo entre el nodo de origen y el nodo de destino. Utilizando este método, el nodo de origen puede obtener rápidamente una ruta hacia el nodo de destino establecido con el mensaje RREP con el que ha respondido el nodo intermedio con una ruta válida hacia el nodo de destino. Si esta ruta no es la mejor ruta métrica de extremo a extremo entre el nodo de origen y el nodo de destino, la ruta se actualiza posteriormente de acuerdo con la mejor ruta.
Haciendo ahora referencia a la figura 2, que muestra la diseminación del mensaje de petición de ruta (RREQ) por la red inalámbrica mallada/ad hoc y la respuesta del nodo intermedio B, con una ruta válida hacia el nodo de destino E, en respuesta al mensaje RREQ mediante un mensaje RREP. Consideremos un ejemplo en el que el nodo de origen A trata de descubrir una ruta hacia el nodo de destino E. El nodo de origen A disemina mensajes de petición de ruta (RREQ) con la bandera “IR” fijada en la red inalámbrica mallada/ad hoc. Supongamos que el nodo intermedio B ya cuenta con una ruta válida B-C-D-E hacia el nodo de destino E. Cuando el nodo intermedio B recibe el mensaje RREQ, crea una ruta inversa hacia el nodo de origen desde el que recibe el RREQ como el siguiente salto (nodo de origen A) de la ruta/trayectoria inversa. El nodo intermedio B responde al RREQ mediante un RREP en modo unidifusión debido a que tiene una ruta válida hacia el destino E y se fija la bandera “IR” en el RREQ.
El RREP establece una ruta de envío al nodo de destino E en el nodo de origen A. Tan pronto como el nodo de origen A crea la ruta/trayectoria hacia el nodo de destino E con el RREP procedente del nodo intermedio B, el nodo de origen A puede comenzar a enviar paquetes/tramas de datos al nodo de destino E a través de la ruta A-B-C-D-E. El nodo intermedio B reinicializa la bandera “IR” del mensaje RREQ y la vuelve a enviar. El motivo de reinicializar la bandera “IR” consiste en limitar las respuestas a la diseminación del RREQ a tan sólo el primer nodo intermedio con una ruta válida hacia el nodo de destino. Los otros nodos intermedios situados más allá, es decir, C y D, no necesitan responder a este RREQ con un RREP, ya que la bandera “IR” no se ha fijado. Supongamos que los nodos intermedios F, G y H carecen de rutas válidas al nodo de destino E. Cuando los nodos intermedios F, G y H reciben los mensajes RREQ diseminados crean la ruta inversa al nodo de origen A con el nodo desde el que cada uno de los nodos intermedios F, G y H recibe el RREQ como el siguiente salto de la ruta inversa. Cada uno de los nodos intermedios F, G y H vuelve a remitir los mensajes RREQ.
En este ejemplo, el nodo de destino E recibe dos copias de este RREQ, y cada una de ellas atraviesa una ruta diferente: A-B-C-D-E, A-F-G-H-E. Asumiendo que los dos RREQ alcancen el nodo de destino E en el orden siguiente: A-B-C-D-E y después A-F-G-H-E, el nodo de destino E crea en primer lugar una ruta hacia el nodo de origen A a través del nodo intermedio D tan pronto como el nodo de destino E recibe el RREQ a lo largo de la ruta/trayectoria A-B-C-D-E. En este punto, la ruta inversa al nodo de origen A se ha establecido en los nodos intermedios B, C y D. El nodo de destino E envía un RREP a lo largo de la ruta E-D-C-B-A. El RREP se limita a actualizar la ruta A-B-C-D-E. Si hay cualquier otro nodo de destino en la lista de destinos, por ejemplo, el nodo I, el nodo de destino E se borra a sí mismo de la lista de destinos y envía de nuevo el mensaje RREQ (por ejemplo, al nodo I). Si no hay más nodos de destino en la lista de destinos del RREQ, no se enviará el mensaje RREQ.
Haciendo ahora referencia a la figura 3, que muestra una red inalámbrica mallada de área local que muestra que el nodo de destino E responde con un RREP (1) al recibir el RREQ a través de A-B-C-D-E y envía un nuevo RREP (2) para establecer una mejor ruta /trayectoria de envío después de recibir el RREQ a través de A-F-G-H-E. Cuando el nodo de destino E recibe el RREQ procedente de A-F-G-H-E, el nodo de destino E determina que este RREQ vino a través de una ruta con una métrica mejor para A que la ruta/trayectoria de envío provisional A-B-C-D-E. Por lo tanto, el nodo de destino E modifica/actualiza el siguiente salto desde el nodo intermedio D al nodo intermedio H y actualiza la métrica. A continuación, el nodo de destino E envía de nuevo un RREP en modo unidifusión al nodo de origen A a través del nodo intermedio H, además de actualizar y enviar el RREQ si hay uno o más nodos de destino adicionales en la lista de destinos RREQ. El RREP establece la ruta hacia el nodo de origen A a través de los nodos intermedios H. G y F. Cuando el nodo de origen A recibe este RREP, modifica/actualiza el siguiente salto para el nodo de destino E desde el nodo intermedio B al nodo intermedio F. La ruta hacia el nodo de destino E se modifica a A-F-G-H-E.
Haremos ahora referencia a la figura 4, que es un diagrama de flujo del procesamiento de un mensaje RREQ. Cuando un nodo recibe un mensaje RREQ, en primer lugar crea/establece o actualiza una ruta inversa al salto anterior desde el que el nodo recibió el mensaje RREQ, si fuese necesario, en el punto 410. El nodo intermedio/receptor puede crear o actualizar la ruta inversa al originador del RREQ de la forma siguiente: Si no existe una ruta inversa hacia el originador del mensaje RREQ en la tabla de asignación de rutas, o es inválida en 415 y 420, se crea o actualiza. El siguiente salto en la tabla de asignación de rutas correspondiente a la ruta inversa del originador del RREQ se convierte en el salto anterior (el nodo desde el que se recibió el mensaje RREQ). Si existe una ruta inversa válida hacia el originador del RREQ, el número de secuencia de origen del mensaje RREQ se compara con el número de secuencia de la entrada correspondiente a la ruta existente en la tabla de rutas en 425 para la ruta inversa. I el número de secuencia del mensaje RREQ es más antiguo, se elimina y no se lleva a cabo ningún procesamiento adicional en 445. De lo contrario, la actual ruta inversa al originador se modifica si la nueva métrica es mejor que la métrica de la ruta actual al originador en la tabla de asignación de rutas en 430. La nueva métrica se define como la métrica en el mensaje RREQ más la métrica de enlace entre el nodo desde el que recibió el mensaje RREQ y él mismo. Si la nueva métrica no es mejor que la métrica de la actual ruta inversa de la entrada de la tabla de rutas, pero el número de secuencia de origen del RREQ es mayor (más nuevo) que el número de secuencia de la tabla de rutas correspondiente a la ruta inversa en 435, el nodo intermedio comprueba si las funciones opcionales de procesamiento de histéresis y captación del mejor candidato a la ruta están soportadas por la red mallada en 450. Si estas funciones opcionales de procesamiento no están soportadas, se actualiza la ruta inversa al originador del RREQ en 455. Cuando se crea o se modifica una ruta inversa, el número de secuencia de la tabla de rutas correspondiente a la ruta inversa se establece como el número de secuencia de origen en el mensaje RREQ, el siguiente salto pasa a ser el nodo desde el que se recibió el mensaje RREQ, la métrica se establece como la nueva métrica y el recuento de saltos es establece en uno más que el recuento de saltos del mensaje RREQ.
Si se hubiese creado o modificado una ruta inversa al nodo de origen, o si el mensaje RREQ fuese la primera copia de un nuevo mensaje RREQ (la ID del RREQ no se vio anteriormente desde el origen) en 420 y 440, la rutina de envío del RREQ y de generación del RREP descrita en este documento se ejecuta a través de un nodo. Por ejemplo, en alguno de los métodos de captación de candidatos a la mejor ruta, los mensajes RREQ pueden almacenarse en una cola de espera con un contador durante la captación de la ruta candidata. Cuando finaliza el contador de la cola de espera, se ejecuta la rutina de envío del RREQ y de generación del RREP.
El nodo de origen puede enviar mensajes períodos de mantenimiento RREQ para actualizar sus rutas directa e inversa activas. Cada vez que el origen envía un mensaje de mantenimiento RREQ, se denomina una ronda de actualización de rutas. Es posible que los nodos que ya tienen la mejor ruta inversa hacia el nodo de origen reciban un mensaje RREQ con un número de secuencia más nuevo pero con una peor métrica en la ruta hacia el nodo de origen antes de recibir el mensaje RREQ a través de la ruta actual con una mejor métrica. Adicionalmente, la copia del mensaje RREQ propagada a lo largo de la ruta actual con la mejor métrica puede perderse durante la diseminación. Estos eventos pueden tener como consecuencia un solapamiento de rutas. Para reducir el solapamiento de rutas y seleccionar la mejor ruta durante cada ronda de actualización de rutas, puede utilizarse un tipo de histéresis y un mecanismo de captación de la ruta candidata. Si se determina en 450 que la opción de histéresis y captación de mejor ruta candidata se implementa a través de una red mallada, un nodo intermedio actualiza la tabla de rutas y modifica la ruta inversa si el número de secuencia de origen del mensaje RREQ es superior (más reciente) que el número de secuencia de la entrada de la tabla de rutas por un valor superior a un umbral. De lo contrario, la ruta inversa puede captarse como un candidato a una posible ruta alternativa en 465.
Si el nodo descubre posteriormente que la ruta inversa actual se ha degradado y es peor que la ruta inversa candidata, podrá cambiarse a la ruta candidata aprendida anteriormente en la misma ronda de actualización. La presente invención describe un método y un sistema para enviar un mensaje RREQ y generar un mensaje RREP para descubrir la mejor ruta sin incurrir en una prolongada demora/latencia en el descubrimiento de la ruta por parte de las redes en malla inalámbricas. El método de la presente invención funciona con o sin histéresis y captación de la mejor ruta candidata/alternativa.
Haciendo ahora referencia a la figura 5, que es un diagrama de flujo que muestra el método de envío de RREQ y de generación de RREP de la presente invención, un nodo determina si se trata de un nodo de destino, es decir, si una
o más direcciones del modo (self_addr) coincide con las direcciones de destino solicitadas en la lista de destinos del mensaje RREQ rreq.dest en 505. Debe observarse que el propio nodo puede tener múltiples direcciones o puede actuar como servidor mandatario (proxy) del resto de los nodos. Por ejemplo, un nodo puede ser un punto de acceso y genera/gestionar mensajes de asignación de rutas en nombre de estaciones heredadas asociadas con él (servidor mandatario de las estaciones). La funcionalidad de este caso es similar a la situación en la que un nodo tiene múltiples direcciones. Las direcciones de destino de las estaciones asociadas pueden considerarse como direcciones alias del punto de acceso. Un nodo es un nodo de destino si una o más de las direcciones especificadas en la lista de destinos del mensaje RREQ le pertenece, o si pertenece a uno de los nodos que lo utilizan como servidor mandatario. Cuando un nodo recibe un mensaje RREQ en el que el nodo de destino es el nodo del que ejerce como servidor mandatario, debería procesar el mensaje RREQ como si la dirección del nodo de destino fuese su propia dirección. Asimismo, un nodo puede ser un nodo de destino para una dirección solicitada en la lista de destinos del mensaje RREQ, pero ser el nodo intermedio para otra dirección solicitada en la lista de destinos del mensaje RREQ.
Si una o más direcciones del nodo coincide con las direcciones de destino solicitadas en la lista de destinos del mensaje RREQ, el nodo genera y envía un mensaje unidifusión RREP al originador del mensaje RREQ correspondiente a estas direcciones de destino coincidentes en 510. Un nodo de destino elimina sus direcciones propias/servidor mandatario de la lista de destinos del mensaje RREQ en 515. Después, si no quedan direcciones solicitadas en la lista de destinos del mensaje RREQ en 520, el mensaje RREQ se descarta en 525. Si el nodo no es un nodo de destino de cualquier dirección solicitada en al lista de destinos del mensaje RREQ (505) o existen otras direcciones de destino solicitadas en la lista de destinos del mensaje RREQ además de las direcciones del nodo, es decir, que el nodo es un nodo intermedio para una o más direcciones del la lista de destinos del mensaje RREQ, el nodo comprueba el resto de direcciones de la lista de destinos del mensaje RREQ de la forma siguiente: Supongamos que rreq.dest[i] representa la dirección (i+1)ésima de la lista de destinos de mensajes RREQ. El nodo inicializa un índice (por ejemplo, i) en 545 y verifica rreq.dest[i], es decir, la primera dirección de la lista de destinos del mensaje RREQ para determinar si existe una ruta directa activa hacia el nodo de destino representado por rreq.dest[i] en 550. Si un nodo intermedio cuenta con una ruta activa hacia su destino, la ruta hacia el nodo de destino es válida (555, el número de secuencia es al menos tan grande como el indicado en el mensaje original RREQ (560) y se establece la bandera “respuesta Intermedia (IR)” (570), el nodo intermedio genera un mensaje RREP para esta dirección de destino solicitada en 575 y envía el mensaje RREP generado en formato unidifusión al originador del mensaje RREQ a lo largo de la actual ruta inversa. La bandera “IR” correspondiente a este destino solicitado en el mensaje RREQ se reinicializa en 580. El nodo aumenta el índice (por ejemplo, en una unidad) y comprueba si existen direcciones adicionales en la lista de destinos del mensaje RREQ en 590. Si existiesen direcciones adicionales en la lista de destinos del mensaje RREQ se repetirá la ejecución del bucle descrito anteriormente, comenzando en 550. Es decir, el bucle se repite si debe enviarse un mensaje RREP para el siguiente destino solicitado. El bucle se repite hasta que se han verificado todas las direcciones de la lista de destinos del mensaje RREQ.
El mensaje de entrada original RREQ se comprueba para determinar si el valor de la duración efectiva (TTL) es mayor que 1 en 350. Si el valor TTL es superior a uno, se actualiza la información del mensaje original RREQ, comprendiendo la reducción del valor TTL del mensaje RREQ saliente, por ejemplo, en una unidad, en 535. El número de secuencia de origen, la métrica y el recuento de saltos también se fijan de acuerdo con la información correspondiente que figura en la entrada actualizada de la ruta correspondiente al origen en 535. El mensaje RREQ actualizado se envía en 540.
Debe observarse que un nodo de destino puede poseer o actuar como servidor mandatario de una o más direcciones y un nodo intermedio puede disponer de rutas válidas hacia una o más direcciones de destino. Un mensaje RREQ puede llevar una o más direcciones de destino en su lista de direcciones de destino. Un nodo de procesamiento/intermedio/de destino puede cumplir dichas condiciones y enviar un mensaje RREP a múltiples direcciones solicitadas en la lista de destinos del mensaje RREQ. Si un nodo envía un mensaje RREP dirigido a múltiples destinos, puede enviar múltiples mensajes RREP, uno para cada destino, o puede enviar un único mensaje agregado RREP con múltiples direcciones de destino en la lista de direcciones.
La figura 6 es un diagrama de bloques que muestra los detalles de un nodo 600 de la presente invención. El nodo incluye un módulo de calidad del enlace y medida de la carga 605, un módulo de cálculo de la métrica de asignación de ruta 610, un módulo de selección de ruta 615 y un módulo de comunicaciones 620. El módulo de medida de la calidad del enlace y la carga 605 garantiza la calidad y la carga del enlace/canal en relación con los adyacentes. Debe observarse que un nodo puede tener múltiples nodos adyacentes, múltiples interfaces de radio y múltiples canales/enlaces físicos/lógicos. Todos ellos deben medirse. El módulo de cálculo de la métrica de ruta 610 de cada nodo utiliza las medidas efectuadas por el módulo de medida de la calidad del enlace y la carga, así como otras informaciones, para calcular la métrica de la ruta correspondiente a cada nodo con el que se comunica. La métrica de asignación de ruta se actualiza periódicamente. El módulo de selección de ruta 615 determina/selecciona una ruta/trayectoria para enviar/comunicar datos a un nodo de destino en función de la métrica de asignación de ruta calculada. El módulo de selección de ruta 615 intercambia los mensajes y datos de control de asignación de la ruta con otros nodos de la red mallada a través del módulo de comunicaciones 620. Cabe señalar que un nodo puede tener uno o más interfaces de comunicación por radio y otros interfaces de comunicaciones. Se entiende que el módulo de selección de ruta puede realmente estar formado por varias unidades más pequeñas o combinarse con otros de los módulos que aquí se describen. También debe entenderse que los procesos descritos en este documento (especialmente en lo que respecta a las figuras 3 y 4) pueden consistir en software, hardware, firmware
o cualquier combinación de los mismos ejecutada en o por el módulo de selección de ruta.
Debe entenderse que la presente invención puede llevarse a cabo mediante diversas formas de software, hardware, firmware, procesadores especiales o una combinación de los mismos, por ejemplo, en un terminal móvil, punto de acceso o red celular. Preferiblemente, la presente invención se realiza como una combinación de hardware y 5 software. Además, el software se ejecuta preferiblemente como una aplicación informática incorporada de forma tangible en un dispositivo de almacenamiento de programas. La aplicación informática puede descargarse y ejecutarse en una máquina que comprenda cualquier arquitectura adecuada. Preferiblemente, la máquina se implementa en una plataforma informática que disponga de hardware, como una o más unidades centrales de procesamiento (CPU) una memoria de acceso aleatorio (RAM) e interfaces de entrada/salida (I/O): la plataforma
10 informática también incluye un sistema operativo y un código de microinstrucciones. Los diversos procesos y funciones que se describen en el presente documento pueden formar parte del código de la microinstrucción o ser parte de la aplicación informática (o una combinación de ambos) que se ejecuta a través del sistema operativo. Además, pueden conectarse otros dispositivos periféricos a la plataforma informática, como un dispositivo adicional de almacenamiento de datos y un dispositivo de impresión.
15 También debe entenderse que, debido al hecho de que algunos de los componentes que constituyen el sistema y las fases del método que se describen en las figuras adjuntas se llevan a cabo preferiblemente mediante software, y las conexiones reales entre los componentes del sistema (o las fases del proceso) pueden diferir en función de la forma en que se programe la presente invención. Teniendo en cuenta cuanto se ha descrito en este documento,
20 cualquier persona medianamente versada en la materia será capaz de contemplar estas y otras realizaciones o configuraciones similares de la presente invención.
REFERENCIAS CITADAS EN LA DESCRIPCIÓN
La lista de referencias citada por el solicitante lo es solamente para utilidad del lector, no formando parte de los documentos de patente europeos. Aún cuando las referencias han sido cuidadosamente recopiladas, no pueden 5 excluirse errores u omisiones y la OEP rechaza toda responsabilidad a este respecto.
Documentos de patente citado en la descripción
• WO 0141375 A [0005] • EP 1467524 A [0005] 10 Bibliografía de patentes citada en la descripción
• Perkins et al. Ad-hoc On-Demand Vector Routing. PROCEEDINGS WMCSA, 25 February 1999 [0005]

Claims (16)

  1. REIVINDICACIONES
    1.
    Método para localizar una ruta entre un nodo de origen (A) y un nodo de destino (E) en una red inalámbrica, comprendiendo dicho método: La diseminación a través de dicha red inalámbrica de un mensaje de petición de ruta (RREQ) por parte de dicho nodo de origen (A); y La recepción de un mensaje de respuesta de ruta (RREP) a dicho mensaje de petición de ruta (RREQ) procedente de un primer nodo intermedio (B) que tiene una ruta válida hacia dicho nodo de destino (E) caracterizado porque dicho primer nodo intermedio (B) responde a dicho mensaje de petición de ruta (RREQ) cuando se establece una bandera (IR) en dicho mensaje de petición de ruta (RREQ) y porque dicho primer nodo intermedio (B) disemina de nuevo en dicha red inalámbrica dicho mensaje de petición de ruta (RREQ) con dicha bandea (IR) reinicializada.
  2. 2.
    Método según la reivindicación 1, caracterizado porque dicha etapa de recepción establece una ruta temporal entre dicho nodo de origen (A) y dicho nodo de destino (E) de dicha red inalámbrica.
  3. 3.
    Método según la reivindicación 1, caracterizado porque dicho mensaje de respuesta de ruta (RREP) de dicha etapa de recepción se envía en modo unidifusión a dicho nodo de origen (A).
  4. 4.
    Método según la reivindicación 1, que comprende adicionalmente la diseminación a través de dicha red inalámbrica de un mensaje de petición de ruta de mantenimiento a fin de mantener una ruta correspondiente a la métrica de extremo a extremo entre nodos y se adapte a cambios de condiciones de red.
  5. 5.
    Método según la reivindicación 4, que también comprende la recepción de una respuesta a dicho mensaje de petición de ruta de mantenimiento como si fuese dicho mensaje de petición de ruta (RREQ).
  6. 6.
    Método según la reivindicación 1, que comprende adicionalmente: La recepción en modo unidifusión de un mensaje adicional de respuesta de ruta (RREP (1), RREP (2)) procedente de dicho nodo de destino (E), comprendiendo dicho mensaje adicional de respuesta de ruta (RREP (1), RREP (2)) una ruta correspondiente a la métrica de extremo a extremo seleccionada por dicho nodo de destino (E), en el que dicha métrica de extremo a extremo se recibe en los mensajes de petición de ruta (RREQ) recibidos por dicho nodo de destino (E).
  7. 7.
    Método según la reivindicación 6, caracterizado porque cuando dicha ruta temporal es dicha ruta de respuesta a la métrica de extremo a extremo, dicho mensaje adicional de respuesta de ruta (RREP (1)) sirve como confirmación, y si dicha ruta temporal no es la ruta de respuesta a la métrica de extremo a extremo, dicho mensaje adicional de respuesta de ruta (RREP (2)) sirve para establecer dicha ruta correspondiente a la métrica de extremo a extremo, cuando dicho nodo de origen (A) recibe dicho mensaje adicional de respuesta de ruta.
  8. 8.
    Método para localizar una ruta entre un nodo de origen (A) y un nodo de destino (E) en una red inalámbrica, comprendiendo dicho método: Recibir un mensaje de petición de ruta (RREQ) procedente de dicho nodo de origen (A); y Responder a dicho mensaje de petición de ruta (RREQ) mediante un mensaje de respuesta de ruta (RREP) procedente de un primer nodo intermedio (B) que tiene una ruta válida hacia dicho nodo de destino (E) caracterizado porque dicho nodo intermedio (B) responde a dicho mensaje de petición de ruta (RREQ) cuando se establece una bandera (IR) en dicho mensaje de petición de ruta (RREQ) y porque dicho primer nodo intermedio (B) disemina de nuevo en dicha red inalámbrica dicho mensaje de petición de ruta (RREQ) con dicha bandera (IR) reinicializada.
  9. 9.
    Método según la reivindicación 8, que comprende asimismo: Actualizar dicho mensaje de petición de ruta (RREQ); y Diseminar a través de dicha red inalámbrica dicho mensaje de petición de ruta (RREQ).
  10. 10.
    Método de acuerdo con la reivindicación 8, caracterizado porque dicha etapa de respuesta establece una ruta temporal entre dicho nodo de origen (A) y dicho nodo de destino (E) de dicha red inalámbrica.
  11. 11.
    Método de acuerdo con la reivindicación 9, caracterizado porque dicha fase de actualización comprende asimismo actualizar una métrica (METRIC) en dicho mensaje de petición de ruta (RREQ) con una métrica acumulada de dicha ruta entre dicho nodo de origen (A) y dicho nodo intermedio (B).
  12. 12.
    Método de acuerdo con cualquiera de las reivindicaciones 1 a 11, caracterizado porque dicha red inalámbrica es una red inalámbrica mallada.
  13. 13.
    Método de acuerdo con la reivindicación 8, caracterizado porque dicho mensaje de respuesta de ruta (RREP) de dicha etapa de respuesta se envía mediante unidifusión a dicho nodo de origen (A).
  14. 14.
    Método de acuerdo con cualquiera de las reivindicaciones 1 a 11, caracterizado porque una dirección de dicho nodo de destino (E) es una dirección del protocolo de Internet y una dirección de control de acceso al soporte.
  15. 15.
    Método de acuerdo con cualquiera de las reivindicaciones 1 a 11, caracterizado porque dicho nodo de destino
    (E) incluye nodos de destino asociados a un servidor mandatario y a un punto de acceso.
    5 16. Método de acuerdo con la reivindicación 8, que comprende igualmente la respuesta a un mensaje de petición de ruta de mantenimiento como si fuese dicho mensaje de petición de ruta (RREQ).
  16. 17. Método según la reivindicación 2 a 10, caracterizado porque dicha ruta temporal está disponible para la
    transmisión de datos al recibir dicho mensaje de respuesta de ruta (RREP) remitido por dicho nodo de origen (A). 10
ES05824653T 2005-11-09 2005-11-09 Selección de ruta en redes inalámbricas. Active ES2366373T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2005/040699 WO2007055689A1 (en) 2005-11-09 2005-11-09 Route selection in wireless networks

Publications (1)

Publication Number Publication Date
ES2366373T3 true ES2366373T3 (es) 2011-10-19

Family

ID=35884996

Family Applications (3)

Application Number Title Priority Date Filing Date
ES10189229.7T Active ES2472691T3 (es) 2005-11-09 2005-11-09 Selección de ruta en redes inalámbricas
ES10189237T Active ES2413433T3 (es) 2005-11-09 2005-11-09 Selección de ruta en redes inalámbricas
ES05824653T Active ES2366373T3 (es) 2005-11-09 2005-11-09 Selección de ruta en redes inalámbricas.

Family Applications Before (2)

Application Number Title Priority Date Filing Date
ES10189229.7T Active ES2472691T3 (es) 2005-11-09 2005-11-09 Selección de ruta en redes inalámbricas
ES10189237T Active ES2413433T3 (es) 2005-11-09 2005-11-09 Selección de ruta en redes inalámbricas

Country Status (17)

Country Link
US (2) US8064416B2 (es)
EP (3) EP2296326B1 (es)
JP (1) JP4939544B2 (es)
KR (3) KR101192937B1 (es)
CN (1) CN101305559B (es)
AT (1) ATE509448T1 (es)
AU (3) AU2005338057B2 (es)
BR (3) BRPI0520670B1 (es)
CA (1) CA2627432C (es)
ES (3) ES2472691T3 (es)
HK (1) HK1120963A1 (es)
PH (1) PH12012502208A1 (es)
PL (3) PL2296325T3 (es)
PT (2) PT2296325E (es)
RU (4) RU2544985C2 (es)
TW (3) TWI357242B (es)
WO (1) WO2007055689A1 (es)

Families Citing this family (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8787350B2 (en) * 2005-12-07 2014-07-22 Meshnetworks, Inc. System and method to facilitate the use of multiple radios to increase the capacity of a wireless communication network
US7796511B2 (en) * 2006-04-06 2010-09-14 Wood Samuel F Self-routed layer 4 packet network system and method
US9542642B2 (en) 2006-04-06 2017-01-10 Samuel F. Wood Packet data neural network system and method
US8738013B2 (en) * 2006-04-24 2014-05-27 Marvell World Trade Ltd. 802.11 mesh architecture
TWI462530B (zh) * 2006-05-01 2014-11-21 Koninkl Philips Electronics Nv 在分散式無線通信網路發現至少具有一最小組可用資源的一經請求即直接連接的距離向量路由之方法
JP4904396B2 (ja) * 2006-07-14 2012-03-28 シーメンス アクチエンゲゼルシヤフト ルート発見プロシージャのための拡張ルート要求メッセージの発生方法および拡張ルート応答メッセージの発生方法
DE102007031341A1 (de) * 2006-11-13 2008-05-15 Siemens Ag Verfahren zum Einrichten bidirektionaler Datenübertragungspfade in einem drahtlosen vermaschten Kommunikationsnetzwerk
US8451807B2 (en) * 2006-12-20 2013-05-28 Honeywell International Inc. Configuration aware packet routing in an ad-hoc network
US8254348B2 (en) * 2006-12-20 2012-08-28 Honeywell International Inc. Voice-over-internet protocol intra-vehicle communications
JP2008193543A (ja) * 2007-02-07 2008-08-21 Fujitsu Ltd アドホックネットワークの経路を制御する装置および方法
US8233905B2 (en) 2007-06-15 2012-07-31 Silver Spring Networks, Inc. Load management in wireless mesh communications networks
US20090003356A1 (en) * 2007-06-15 2009-01-01 Silver Spring Networks, Inc. Node discovery and culling in wireless mesh communications networks
DE102007029120B4 (de) * 2007-06-25 2010-06-17 Siemens Ag Verfahren zum Betreiben eines drahtlosen, vermaschten Datennetzes mit einer Mehrzahl an Netzknoten
ES2390184T3 (es) * 2007-09-06 2012-11-07 Siemens Aktiengesellschaft Procedimiento y nodo de red para establecer una ruta sin bucles en una red ad-hoc reactiva
EP2063584A1 (en) * 2007-11-22 2009-05-27 Thomson Licensing Method for routing and load balancing in mesh networks
US9128202B2 (en) 2008-04-22 2015-09-08 Srd Innovations Inc. Wireless data acquisition network and operating methods
JP4941397B2 (ja) * 2008-04-22 2012-05-30 富士通株式会社 経路情報中継方法および無線端末
WO2009147585A1 (en) 2008-06-04 2009-12-10 Philips Intellectual Property & Standards Gmbh A network interface unit for a node in a wireless multi-hop network, and a method of establishing a network path between nodes in a wireless multi-hop network.
WO2009148410A1 (en) * 2008-06-06 2009-12-10 Agency For Science, Technology And Research Communication devices and methods for scheduling and allocating of radio resources and communication devices and methods for routing in a communication network
KR100970385B1 (ko) * 2008-06-09 2010-07-15 한국전자통신연구원 무선 네트워크의 경로 설정 방법 및 장치
EP2321983B1 (en) * 2008-09-04 2018-05-09 Trilliant Networks, Inc. Method for implementing mesh network communications using a mesh network protocol
US8457134B2 (en) * 2008-09-22 2013-06-04 International Business Machines Corporation Method for dynamic routing using tunneling
US8982908B1 (en) * 2008-12-01 2015-03-17 Marvell International Ltd. Extension of path reply message to encode multiple route information in a mesh network
EP2230803A1 (en) * 2009-03-16 2010-09-22 BRITISH TELECOMMUNICATIONS public limited company Path characterisation in networks
ES2423989T3 (es) * 2009-03-30 2013-09-26 The Boeing Company Red AD HOC móvil
EP2237614B1 (en) 2009-03-30 2014-06-04 The Boeing Company Mobile ad hoc network
JP5293452B2 (ja) * 2009-06-24 2013-09-18 富士通株式会社 制御方法、制御装置及び記憶媒体
JP5246060B2 (ja) * 2009-06-24 2013-07-24 富士通株式会社 制御方法、制御装置及び記憶媒体
US8861398B2 (en) * 2009-06-30 2014-10-14 Mitsubishi Electric Research Laboratories, Inc. Method for discovering multiple routes in sensor networks
CN101990270B (zh) 2009-08-06 2014-05-21 华为技术有限公司 建立按需路由的方法、设备及系统
US20110170443A1 (en) * 2010-01-13 2011-07-14 Ronald Gerald Murias Link sensitive aodv for wireless data transfer
US8782237B2 (en) 2010-01-28 2014-07-15 Intel Corporation Audio/video streaming in a topology of devices
CN101883048B (zh) * 2010-06-25 2012-10-10 陶洋 多维网络的路由方法
WO2012009849A1 (en) * 2010-07-20 2012-01-26 Nokia Corporation A routing scheme for wireless sensor networks
WO2012025781A1 (en) * 2010-08-26 2012-03-01 West Bengal University Of Technology Systems and methods for determining routes in networks
KR20120067883A (ko) * 2010-12-16 2012-06-26 한국전자통신연구원 멀티홉 라우팅 장치 및 라우팅 방법
US9231851B2 (en) * 2011-01-31 2016-01-05 Futurewei Technologies, Inc. System and method for computing point-to-point label switched path crossing multiple domains
JP5732963B2 (ja) * 2011-03-28 2015-06-10 富士通株式会社 無線通信端末および経路構築方法
US8599759B2 (en) 2011-04-29 2013-12-03 Cooper Technologies Company Multi-path radio transmission input/output devices, network, systems and methods with on demand, prioritized routing protocol
JP5705030B2 (ja) * 2011-05-30 2015-04-22 矢崎総業株式会社 通信システム
EP2733894B1 (en) * 2011-07-12 2020-09-09 Furukawa Electric Co., Ltd. Communication system, communication route control method, and communication apparatus
EP2767050A1 (en) * 2011-10-13 2014-08-20 Interdigital Patent Holdings, Inc. Method and apparatus for providing interfacing between content delivery networks
US9350814B2 (en) 2012-02-21 2016-05-24 Qualcomm Incorporated Internet protocol connectivity over a service-oriented architecture bus
US9621458B2 (en) * 2012-02-21 2017-04-11 Qualcomm Incorporated Internet routing over a service-oriented architecture bus
CN104221433B (zh) * 2012-03-02 2018-01-30 富士通株式会社 通信设备搜索方法、通信设备、通信设备搜索程序以及自组织网络系统
WO2013129671A1 (ja) * 2012-03-02 2013-09-06 富士通株式会社 アドホックネットワークシステム及び経路選択方法
CN102769888B (zh) * 2012-06-04 2015-03-11 上海交通大学 用于车载Ad Hoc网络基于改进AODV协议的方法
CN102904804B (zh) * 2012-10-22 2015-07-29 华为技术有限公司 路由转发信息添加方法、报文转发方法及装置、网络设备
EP2725751B1 (en) * 2012-10-24 2014-12-10 Nxp B.V. Routing table updating
US9277439B2 (en) * 2013-06-28 2016-03-01 Intel Corporation Device-to-device contention management scheme for mobile broadband networks
CN105706496B (zh) 2013-11-26 2019-05-03 松下知识产权经营株式会社 无线通信系统
WO2015139026A2 (en) 2014-03-14 2015-09-17 Go Tenna Inc. System and method for digital communication between computing devices
KR102145943B1 (ko) * 2014-11-21 2020-08-19 에스케이텔레콤 주식회사 백홀시스템과, 이에 적용되는 단말장치 및 단말장치의 동작 방법
GB2537657A (en) * 2015-04-22 2016-10-26 Ge Oil & Gas Uk Ltd Subsea control system communication network
EP3320721A4 (en) * 2015-07-06 2018-08-01 Telefonaktiebolaget LM Ericsson (publ) Apparatus and method for forwarding messages
US9967909B2 (en) 2015-11-04 2018-05-08 Motorola Mobility Llc Wireless ad hoc network assembly using network coding
US9936052B2 (en) 2015-11-04 2018-04-03 Motorola Mobility Llc Wireless ad hoc network assembly using network coding
US9942934B2 (en) 2015-11-04 2018-04-10 Motorola Mobility Llc Wireless ad hoc network assembly using network coding
CN108476417B (zh) * 2015-12-15 2021-12-07 昕诺飞控股有限公司 用于管理邻居表的方法和适用于管理邻居表的通信设备
US10111160B2 (en) * 2016-03-24 2018-10-23 Qualcomm Incorporated NAN data link multi-hop topology
US10680939B2 (en) * 2016-07-05 2020-06-09 Mediatek Inc. Hybrid flood-relaying and routing mesh networks
US20180026933A1 (en) * 2016-07-22 2018-01-25 Cisco Technology, Inc. Service aware label address resolution protocol switched path instantiation
US10193795B2 (en) * 2016-12-21 2019-01-29 Sony Corporation Robust data routing in wireless networks with directional transmissions
CN106888493B (zh) * 2017-02-13 2020-10-16 深圳市联骋科技有限公司 一种无线网状mesh网络的路由方法和装置
US10673736B2 (en) * 2017-04-25 2020-06-02 Cisco Technology, Inc. Traffic reduction in data center fabrics
US10757011B2 (en) * 2017-05-25 2020-08-25 Zycada Networks, Inc. Context-aware path computation and selection
FI127371B (en) * 2017-05-31 2018-04-30 Robotonchip Oy Passive routing on a mesh network
US20190141616A1 (en) * 2017-11-08 2019-05-09 Carrier Corporation Mesh networking using peer to peer messages
US10944669B1 (en) 2018-02-09 2021-03-09 GoTenna, Inc. System and method for efficient network-wide broadcast in a multi-hop wireless network using packet echos
PL3525517T3 (pl) * 2018-02-12 2021-06-14 Curvalux Uk Limited Wysokowydajna sieć wieloskokowa z kształtowaniem wiązek
JP6738851B2 (ja) * 2018-03-30 2020-08-12 古河電気工業株式会社 ネットワークシステム、ネットワークシステムの経路切換方法、および、通信装置
EP3831021A1 (en) 2018-07-27 2021-06-09 Gotenna Inc. VINEtm ZERO-CONTROL ROUTING USING DATA PACKET INSPECTION FOR WIRELESS MESH NETWORKS
US11659447B2 (en) * 2018-08-08 2023-05-23 Telefonaktiebolaget Lm Ericsson (Publ) Flow control for integrated access backhaul (IAB) networks
CN112534782B (zh) 2018-08-17 2022-08-05 瑞典爱立信有限公司 针对蓝牙网的独立冗余路径发现
CN113170375B (zh) 2018-09-10 2024-03-26 瑞典爱立信有限公司 检测蓝牙网格网络中的关键链路
US10869256B2 (en) * 2018-12-18 2020-12-15 Sony Corporation Multi-hop routing protocol with backup routes in WLAN networks
FR3095913B1 (fr) 2019-05-06 2023-10-27 Bull Sas Procédé d’identification d’un objet connecté dans une infrastructure réseau
EP3675463B1 (fr) 2018-12-31 2023-12-06 Bull SAS Procédé d'identification d'un objet connecté dans une infrastructure réseau
KR102333814B1 (ko) * 2019-10-17 2021-12-01 한국전자기술연구원 원거리 웨이크업을 수행하는 에너지 하베스팅 시스템, 장치 및 방법
KR102342348B1 (ko) * 2019-10-17 2021-12-22 한국전자기술연구원 원거리 위치 추정을 수행하는 에너지 하베스팅 시스템, 장치 및 방법
US11770324B1 (en) * 2019-12-02 2023-09-26 Lutron Technology Company Llc Processing advertisement messages in a mesh network
CN111065095A (zh) * 2020-01-08 2020-04-24 方楚持 一种无线量子通信信息传递方法
CN112533262B (zh) * 2020-10-15 2022-12-30 广州大学 一种可充电无线传感器网络的多路径按需路由方法
CN112867091B (zh) * 2021-01-14 2022-11-08 湖南智领通信科技有限公司 一种基于主动式路由协议的mesh网关选择方法和装置

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5544154A (en) * 1995-03-09 1996-08-06 Telefonaktiebolaget Lm Ericsson Method for determining the load induced by a routing verification test on a network
US5987011A (en) 1996-08-30 1999-11-16 Chai-Keong Toh Routing method for Ad-Hoc mobile networks
US6421731B1 (en) * 1996-10-29 2002-07-16 Telxon Corporation Dynamic next hop routing protocol
US6446125B1 (en) * 1997-03-28 2002-09-03 Honeywell International Inc. Ripple scheduling for end-to-end global resource management
MXPA02002935A (es) 1999-09-15 2003-09-25 Datawire Comm Networks Inc Sistema y metodo para realizar transacciones seguras sobre una red.
WO2001041378A1 (en) * 1999-12-06 2001-06-07 Telefonaktiebolaget L M Ericsson (Publ) Broadcast as a triggering mechanism for route discovery
US6535498B1 (en) * 1999-12-06 2003-03-18 Telefonaktiebolaget Lm Ericsson (Publ) Route updating in ad-hoc networks
JP4756143B2 (ja) 2000-06-07 2011-08-24 インテル コーポレイション 多経路の動的経路指定アルゴリズム
FI112152B (fi) * 2000-09-29 2003-10-31 Nokia Corp Osoitteistus ja reititys ad hoc-liikkuvuusverkoissa
US6807165B2 (en) * 2000-11-08 2004-10-19 Meshnetworks, Inc. Time division protocol for an ad-hoc, peer-to-peer radio network having coordinating channel access to shared parallel data channels with separate reservation channel
JP3947370B2 (ja) 2001-06-20 2007-07-18 日本無線株式会社 無線通信システム
RU2273098C2 (ru) 2001-07-10 2006-03-27 Сименс Акциенгезелльшафт СПОСОБ ДЛЯ ВЫПОЛНЕНИЯ ОРИЕНТИРОВАННОГО НА КАЧЕСТВО УСЛУГ (QoS) ПЕРЕХОДА МЕЖДУ ПЕРВЫМ И ВТОРЫМ ОСНОВАННЫМ НА ПРОТОКОЛЕ IP, В ЧАСТНОСТИ НА МОБИЛЬНОМ ПРОТОКОЛЕ IPv6, МАРШРУТОМ СВЯЗИ МЕЖДУ МОБИЛЬНЫМ УЗЛОМ СЕТИ (MN)
EP1467524A4 (en) * 2001-12-28 2005-03-30 Nokia Corp ROUTING PROCEDURE FOR A MOBILE AD HOC NETWORK
US7177295B1 (en) * 2002-03-08 2007-02-13 Scientific Research Corporation Wireless routing protocol for ad-hoc networks
US20040167988A1 (en) * 2002-12-23 2004-08-26 Johan Rune Bridging between a Bluetooth scatternet and an Ethernet LAN
US20040156318A1 (en) * 2002-12-23 2004-08-12 Johan Rune Bridging between a Bluetooth scatternet and an Ethernet LAN
US20040141511A1 (en) * 2002-12-23 2004-07-22 Johan Rune Bridging between a bluetooth scatternet and an ethernet LAN
ATE515856T1 (de) * 2003-01-13 2011-07-15 Meshnetworks Inc System und verfahren zur erzielung kontinuierlicherkonnektivität mit einem zugangspunkt oder gateway in einem drahtlosennetzwerk
JP2006525694A (ja) 2003-05-06 2006-11-09 サムスン エレクトロニクス カンパニー リミテッド モバイルアドホックネットワークにおける経路検索装置及び方法
US7061925B2 (en) * 2003-06-06 2006-06-13 Meshnetworks, Inc. System and method for decreasing latency in locating routes between nodes in a wireless communication network
US7706282B2 (en) 2003-06-25 2010-04-27 Leping Huang Bluetooth personal area network routing protocol optimization using connectivity metric
US20040264372A1 (en) 2003-06-27 2004-12-30 Nokia Corporation Quality of service (QoS) routing for Bluetooth personal area network (PAN) with inter-layer optimization
JP4023681B2 (ja) 2003-07-14 2007-12-19 Ｋｄｄｉ株式会社 マルチホップ無線通信システムおよびその経路選択方法
JP4605428B2 (ja) 2003-08-08 2011-01-05 ソニー株式会社 通信システム、通信端末装置、通信方法及びプログラム
US7415019B2 (en) 2003-08-22 2008-08-19 Samsung Electronics Co., Ltd. Apparatus and method for collecting active route topology information in a mobile ad hoc network
JP4029833B2 (ja) 2003-12-24 2008-01-09 Ｋｄｄｉ株式会社 グループ管理方法、移動通信装置及びそのプログラム
US7269155B2 (en) * 2004-01-13 2007-09-11 Meshnetworks, Inc. System and method for achieving continuous connectivity to an access point or gateway in a wireless network following an on-demand routing protocol, and to perform smooth handoff of mobile terminals between fixed terminals in the network
JP4392789B2 (ja) 2004-03-05 2010-01-06 Ｋｄｄｉ株式会社 アドホック無線ネットワークの経路再確立方法および無線端末
JP4569328B2 (ja) 2004-03-18 2010-10-27 パナソニック株式会社 無線通信装置および経路探索方法
KR100898680B1 (ko) * 2004-09-07 2009-05-22 메시네트웍스, 인코포레이티드 무선 네트워크에서 데이터를 라우팅하기 위해 무선네트워크에서 상이한 유형들의 노드들을 액세스 포인트노드들과 연관짓기 위한 시스템 및 방법
JP5199061B2 (ja) * 2005-03-10 2013-05-15 トムソン ライセンシング ハイブリッド型メッシュ・ルーティング・プロトコル
US7570628B2 (en) * 2005-05-06 2009-08-04 Intel Corporation Methods and apparatus for providing a dynamic on-demand routing protocol
US20070070959A1 (en) * 2005-09-23 2007-03-29 Almeroth Kevin C Infrastructure mesh networks
DE102006055662B3 (de) 2006-11-23 2008-06-26 Gfe Metalle Und Materialien Gmbh Beschichtungswerkstoff auf Basis einer Kupfer-Indium-Gallium-Legierung, insbesondere zur Herstellung von Sputtertargets, Rohrkathoden und dergleichen
EP2321983B1 (en) * 2008-09-04 2018-05-09 Trilliant Networks, Inc. Method for implementing mesh network communications using a mesh network protocol

Also Published As

Publication number Publication date
EP2296325A2 (en) 2011-03-16
TWI430619B (zh) 2014-03-11
EP2296326B1 (en) 2013-05-01
CA2627432C (en) 2014-11-04
KR20080074876A (ko) 2008-08-13
RU2010120573A (ru) 2011-11-27
TW201123770A (en) 2011-07-01
RU2017116747A3 (es) 2018-11-15
RU2550151C2 (ru) 2015-05-10
AU2010202493B2 (en) 2013-06-20
PL1952588T3 (pl) 2011-12-30
HK1120963A1 (en) 2009-04-09
US20090135824A1 (en) 2009-05-28
KR101225274B1 (ko) 2013-01-22
CA2627432A1 (en) 2007-05-18
WO2007055689A1 (en) 2007-05-18
PT2296325E (pt) 2014-06-24
RU2017116747A (ru) 2018-11-15
CN101305559B (zh) 2011-11-30
PL2296326T3 (pl) 2013-08-30
KR20090116808A (ko) 2009-11-11
US8064416B2 (en) 2011-11-22
TW200729836A (en) 2007-08-01
RU2010120572A (ru) 2011-11-27
EP1952588B1 (en) 2011-05-11
BRPI0520670B1 (pt) 2018-11-27
EP1952588A1 (en) 2008-08-06
AU2005338057A1 (en) 2007-05-18
CN101305559A (zh) 2008-11-12
ES2413433T3 (es) 2013-07-16
PH12012502208B1 (en) 2015-06-01
EP2296326A1 (en) 2011-03-16
BRPI0520873B1 (pt) 2018-11-27
EP2296325B1 (en) 2014-04-30
JP4939544B2 (ja) 2012-05-30
KR101192937B1 (ko) 2012-10-18
AU2005338057B2 (en) 2011-04-21
TWI357242B (en) 2012-01-21
PH12012502208A1 (en) 2015-06-01
EP2296325A3 (en) 2011-05-25
KR20100103678A (ko) 2010-09-27
RU2013151444A (ru) 2015-05-27
AU2009212921B2 (en) 2011-09-22
RU2682930C2 (ru) 2019-03-22
ES2472691T3 (es) 2014-07-02
AU2010202493A1 (en) 2010-07-22
JP2009515473A (ja) 2009-04-09
RU2628334C2 (ru) 2017-08-16
AU2009212921A1 (en) 2009-10-01
BRPI0520882B1 (pt) 2018-11-27
PT1952588E (pt) 2011-08-25
ATE509448T1 (de) 2011-05-15
RU2544985C2 (ru) 2015-03-20
BRPI0520670A2 (pt) 2009-05-19
TW201001989A (en) 2010-01-01
US20110255479A1 (en) 2011-10-20
PL2296325T3 (pl) 2014-08-29
KR101183342B1 (ko) 2012-09-14

Similar Documents

Publication Publication Date Title
ES2366373T3 (es) Selección de ruta en redes inalámbricas.
JP5311889B2 (ja) 通信システム、移動通信装置、ホームエージェントおよび通信方法
JP4951695B2 (ja) 無線ネットワークにおける経路選択
JP4939579B2 (ja) 無線ネットワークにおける経路選択
CA2896911C (en) Route selection in wireless networks
CA2817659C (en) Route selection in wireless networks
RU2405282C2 (ru) Выбор маршрута в беспроводных сетях