ES2423585T3 - Método para la comunicación entre nodos en una red inalámbrica - Google Patents

Abstract

Un método para la comunicación entre nodos en una red inalámbrica, en particular en una red inalámbrica ad hoco de malla, en el que se proporcionan múltiples canales inalámbricos con diferentes bandas de frecuencia y en elque dichos nodos están habilitados para funcionar sobre dichos canales diferentes, en el que cada uno de dichosnodos tiene asignado un canal local en el que reside habitualmente, caracterizado por que un nodo que deja sucanal local y conmuta a otro de dichos múltiples canales - canal de operación temporal - proporciona informaciónacerca de dicho canal temporal de operación sobre dicho canal local del nodo.

Description

Método para la comunicación entre nodos en una red inalámbrica

La presente invención se refiere a un método para la comunicación entre nodos en una red inalámbrica, en particular en una red inalámbrica ad hoc o una red de malla, en las que se proporcionan múltiples canales inalámbricos con diferentes bandas de frecuencia y en las que dichos nodos están habilitados para operar sobre dichos canales diferentes.

En los últimos años, las redes ad hoc y las redes de malla inalámbricas (WMN) han emergido como una nueva tecnología que se puede usar para instalar una infraestructura inalámbrica en áreas residenciales, campus, comunidades e incluso áreas metropolitanas. Para las redes ad hoc y WMN, IEEE 802.11 es una tecnología inalámbrica interesante porque es madura, barata y está ampliamente disponible. Muchas nuevas aplicaciones son posibles con el modo ad hoc de IEEE 802.11, como por ejemplo para la conexión en una red de malla, la conexión en red de futuros hogares, la comunicación de automóvil a automóvil y de automóvil a infraestructura, etc. Un problema importante en las redes ad hoc y WMN basadas en IEEE 802.11 es que su capacidad de red está más bien limitada porque todos los nodos operan sobre un canal único. Consecuentemente, la capacidad de la red ad hoc está limitada a la capacidad del canal.

En general, hay dos enfoques para la mejora de la capacidad explotando múltiples bandas de frecuencia en las redes ad hoc y WMN: la extensión de MAC (Control de Acceso al Medio) y la extensión del enrutamiento. Las extensiones de enrutamiento (como se describen por ejemplo en el documento de R. Draves y otros: Routing in Multi-Radio, Multi-Hop, Wireless Mesh Networks, en ACM MobiCom'04, septiembre de 2004, y en el documento de A.Raniwala y otros: Architecture and Algorithms for an IEEE 802.11 - Based MultiChannel Wireless Mesh Network, en IEEE Infocom 2005, marzo de 2005) usualmente requiere que los nodos tengan múltiples interfaces inalámbricas de red con diferentes NIC (Tarjeta de Interfaz de Red) sintonizadas a los diferentes canales.

Por otra parte, la extensión de MAC habitualmente requiere solo una interfaz de red y de este modo es más atractiva. La extensión de MAC, tal como los protocolos MAC multi-canal, han llamado considerablemente la atención recientemente ya que posibilita que los nodos operen en una red inalámbrica ad hoc sobre múltiples canales inalámbricos. Los principales retos de MAC multicanal son la necesidad de permitir que los nodos operen en diferentes canales para evitar las posibles interferencias y conseguir la coordinación entre los nodos que posiblemente operan sobre diferentes canales. Recientemente se han propuesto varios protocolos MAC multicanal, que se dirigen al reto de la coordinación entre los nodos en diferentes modos:

1.

El protocolo de Asignación de Canales Dinámica (DCA), por ejemplo, usa dos interfaces de radio por nodo para operar sobre un canal de control y múltiples canales de datos (véase el documento de Wu y otros, A new multichannel MAC protocol with on-demand channel assignment for multi-hop mobile ad hoc netwroks, ISPAN'00, diciembre de 2000). En la DCA, se sintoniza una interfaz de radio al canal de control y se llama la interfaz de control. La otra interfaz de radio se llama la interfaz de datos y se conmuta dinámicamente a uno de los canales de datos para transmitir paquetes de datos y confirmaciones. Cada nodo en la DCA mantiene una lista de uso de canales CUL para todos los canales de datos. Los nodos actualizan su CUL en base a las tramas de control que oyen sobre el canal de control. Además, cada nodo también mantiene una lista de canales libres FCL que calcula dinámicamente a partir de su CUL. La DCA usa tres tipos de tramas de control sobre el canal de control para la reserva de canal: petición de transmisión (RTS), preparado para enviar (RTS), y reserva (RES). Cuando el ordenador A quiere enviar datos al ordenador B, el ordenador A inserta su FCL dentro de una trama RTS y envía la trama al ordenador B. El ordenador B compagina la FCL de A con su propia FCL para seleccionar un canal de datos disponible (si lo hay) y envía una trama CTS de vuelta al ordenador A. El ordenador A envía a continuación una trama RES para evitar que sus vecinos usen el canal de datos seleccionado durante un intervalo específico. Los vecinos del ordenador A y el ordenador B pueden actualizar sus CUL en base a las tramas CTS y RES que oyen sobre el canal de control.

2.

El protocolo MAC Multi-Canal (MMAC) usa sólo una interfaz de radio para funcionar sobre múltiples canales de datos (como se describe en el documento de J. So y otros: Multi-channel MAC for ad hoc networks: Handling multichannel hidden terminals using a single transceiver, en ACM MobiHoc'04, mayo de 2004). MMAC requiere la sincronización del tiempo entre nodos y divide el tiempo en intervalos de baliza. Cada intervalo de baliza comienza con una pequeña ventana llamada Ventana ATIM. El MMAC toma prestado el término "ATIM"(Mensaje de Indicación del Tráfico Ad hoc) desde el Modo de Ahorro de Energía de la IEEE 802.11, pero se usa ATIM en MMAC para un propósito diferente. Cada nodo en MMAC mantiene una estructura de datos llamada Lista de Canales Preferibles (PCL) que mantiene la pista del uso de canales dentro de la vecindad de un nodo. En MMAC, un canal en un nodo puede tener tres estados, de preferencia alta, media, y baja. Una alta preferencia indica que el nodo ya ha seleccionado este canal para el intervalo de baliza actual y debe continuar para elegir este canal hasta el siguiente intervalo de baliza. Una preferencia media significa que este canal no se ha tomado por ningún vecino dentro del intervalo de transmisión del nodo. Una baja preferencia indica que este canal ya está tomado por al menos un vecino dentro del intervalo de transmisión del nodo. Los nodos también mantienen contadores por canal para registrar el uso de cada canal en un intervalo de baliza. Estos contadores permiten a los nodos equilibrar la carga del canal.

Durante una ventana de ATIM, todos los nodos conmutan a un canal por defecto para intercambiar balizas y tramas ATIM (también se puede usar el canal por defecto para el intercambio de datos fuera de las ventanas de ATIM). Cuando el ordenador A quiere enviar datos al ordenador B, el ordenador A inserta su PCL dentro de una trama ATIM y la envía al ordenador B. El ordenador B compara la PCL de A con su propia PCL para seleccionar un canal y transmite una trama ATIM-ACK de vuelta al ordenador A. Si el ordenador A no puede seleccionar el canal especificado por el ordenador B porque ya ha elegido otro canal, debe esperar hasta el siguiente intervalo de baliza. De lo contrario, el ordenador A envía una trama ATIM-RES con el canal seleccionado de modo que los vecinos dentro de su intervalo de transmisión pueden actualizar su PCL. Después de la ventana de ATIM, el ordenador A y el ordenador B conmutan al canal seleccionado para intercambiar datos.

3.

Salto de Canal Sembrado Ranurado (SSCH) usa solo una interfaz de radio para operar sobre múltiples canales de datos (descrito en el documento de P. Bahi y otros: SSCH: Slotted seeded cannel hopping for capaciy improvement in IEEE 802.11 ad-hoc wireless network, en ACM MobiCom'04, septiembre de 2004). El SSCH requiere la sincronización en el tiempo entre los nodos y divide el tiempo en ranuras. En el SSCH, cada nodo mantiene una programación de canales que contiene una lista de canales a los que el nodo planea conmutar en las ranuras posteriores. Una programación de canal del nodo se representa de forma compacta como un canal actual y un conjunto de normas para la actualización de canal. El SSCH sugiere que el conjunto de normas se representa como un conjunto de 4 pares (canal, semilla). Cada nodo itera a través de su conjunto de 4 pares (canal, semilla) en cada ranura y realiza la siguiente actualización de canal:

Canali - (canali + semillai) módulo N

donde i está entre 0 y 3, y N es el número de canales ortogonales disponible, por ejemplo, N es 3 para IEEE 802.11b y 13 para IEEE 802.11a. En SSCH cada nodo difunde frecuentemente su programación de canales y hace el seguimiento de las otras programaciones de canales de los nodos. Cuando el ordenador A quiere enviar datos al ordenador B, el ordenador A puede seguir al ordenador B adoptando la programación de canal del ordenador B.

4. El Protocolo de Coordinación Multicanal Asíncrono (AMCP) requiere solo una interfaz de radio por nodo y no necesita la sincronización en el tiempo entre los nodos para operar en N canales de datos (véase el documento J.Shi y otros: Starvation mitigation through multi-channel coordination in CSMA based wireless networks, en ACM MobiHoc'06, mayo de 2006). Sin embargo, el AMCP usa un canal de control dedicado sobre el cual los nodos intercambian tramas de control para negociar la reserva del canal. En AMCP, cada uno de los nodos mantiene una tabla de canales con N entradas correspondientes a los N canales de datos. Cada entrada indica si hay disponible un canal o cuando tiempo se está usando el canal por los otros nodos dentro de un intervalo de transmisión. Además, cada nodo mantiene una variable preferencia que puede tomar valores desde 0 hasta N. Si es distingo de cero, preferencia contiene el índice a un canal de datos que prefiere el nodo. Si es cero, preferencia indica que el nodo no tiene preferencias.

Cuando el ordenador A quiere enviar un paquete de datos al ordenador B, en primer lugar selecciona un canal de datos por el que competirá. Si la variable preferencia del ordenador A es distinta de cero y este canal está disponible, el ordenador A seleccionará este canal. En otro caso, el ordenador A selecciona aleatoriamente uno de sus canales de datos disponibles. El ordenador A inserta el índice para el canal de datos seleccionado dentro de una trama RTS y la envía al ordenador B. Cuando el ordenador B recibe la trama RTS, el ordenador B puede enviar un CTS de Confirmación con el índice al canal de datos seleccionado si ese canal está disponible para el ordenador B. En otro caso, el ordenador B envía un CTS de Rechazo con una lista de canales de datos disponibles. Una vez recibido un CTS de confirmación, el ordenador A conmuta al canal seleccionado y transmite un paquete de datos al ordenador B. De otro modo el ordenador A selecciona un canal disponible tanto para el ordenador A como el ordenador B y envía una nueva trama RTS al ordenador B. Otros ordenadores dentro del intervalo de transmisión del ordenador A y el ordenador B pueden oír las tramas RTS y CTS y actualizar sus tablas de canales para la disponibilidad de canales en consecuencia.

Incluso aunque con MAC multicanal los nodos pueden explotar la diversidad de frecuencia y la capacidad de una red inalámbrica ad hoc ya no está limitada a la de un único canal, se observará que los protocolos mencionados anteriormente se basan en dos suposiciones más bien poco prácticas: baja latencia de conmutación de canal y sincronización de reloj de grano fino entre los nodos. Los problemas con estas suposiciones son como sigue. En primer lugar, aunque es posible, conseguir la sincronización de reloj de grano fino es más bien difícil y requiere unos gastos de implementación considerables que tienen un impacto sobre la escalabilidad de la red ad hoc. En segundo lugar, la sincronización que usan los dispositivos GPS aumenta los costes de producción y la complejidad de implementación, y no se puede usar en un despliegue en el interior de edificios. En tercer lugar como se indica en los estudios de mediciones, la latencia de conmutación de canal sobre un hardware de IEEE 802.11 existente es significativamente más alta que los valores supuestos usados en las soluciones MAC multicanal existentes. Por ejemplo, los valores supuestos están habitualmente en el intervalo de decenas a cientos de microsegundos mientras que las mediciones mostraron que la latencia de conmutación del canal era de varios milisegundos en Linux y Windows (por ejemplo, descrito en el documento de A.Raniwala y otros, Architecture and Algorithme for an IEEE

802.11 - Based Multi-Channel Wireless Mesh Network, IEEE Infocom 2005, marzo de 2005, o en el documento de H.Wu y otros, Proactive Scan: Fast Handoff With Smart Triggers for 802.11 Wireless LAN, IEEE Infocom 2007, mayo

de 2007). Por estas tres razones, los protocolos MAC multicanal propuestos no funcionan bien bajo las limitaciones prácticas actuales.

A partir del documento de S. Chaudhurl, R. Kumar, A. Saha: "A MAC Protocol for Multi Frecuency Physical Layer", Informe técnico del 23 de Enero de 2003, Universidad de Rice, Texas, el protocolo MAC está disponible para su uso en una red ad hoc de nodos móviles que usan un sistema LAN inalámbrico que define múltiples canales de frecuencia independientes. Cada nodo puede conmutar rápidamente desde un canal a otro pero solo puede operar sobre un canal al mismo tiempo. Cada estación está asociada con un canal particular, en el que la estación se mantiene a la escucha sobre ese canal asociado cada vez que la estación está libre. El mapeo entre la estación y la ID del canal asociado se conoce para cada estación. Cada vez que una estación quiere transmitir datos a alguna otra estación, averigua el canal en el cual estaría oyendo el destino, y conmuta por sí mismo temporalmente a ese canal. Por consiguiente, ambas estaciones fuente y de destino están en el mismo canal y listas para usar el protocolo de la sub capa de IEEE 802.11 para acceder al canal común, e intercambiar datos.

Por lo tanto, es un objeto de la presente invención mejorar y desarrollar adicionalmente un método para la comunicación entre nodos en una red inalámbrica del tipo inicialmente descrito de tal modo que las suposiciones poco prácticas mencionadas anteriormente no se requieran. Además, el método será práctico en el sentido de que es posible una implementación sobre un hardware de IEEE 802.11 existente.

De acuerdo con la invención, el objeto mencionado anteriormente se logra por un método que comprende las características de la reivindicación 1. De acuerdo con esta reivindicación tal método está caracterizado por que cada uno de dichos nodos tiene asignado un canal local donde reside habitualmente, en el que un nodo que deja su canal local y conmuta a otro de dichos múltiples canales - canal de funcionamiento temporal - proporciona información acerca de dicho canal de funcionamiento temporal sobre dicho canal local del nodo.

De acuerdo con la invención se ha reconocido que se puede conseguir un método práctico para la comunicación entre nodos (por ejemplo, móviles) en una red inalámbrica por medio de saltos de canal múltiples asíncronos. Asíncrono significa que los nodos operan asíncronamente, es decir que no se requiere una sincronización en el tiempo. La presente invención propone la asignación de un canal local para cada nodo junto con un mecanismo de información en el caso de que un modo deje su canal local. Más específicamente, un nodo que deja su canal local y conmuta a otro canal, denominado como canal de operación temporal, proporciona información acerca del canal de operación temporal sobre su canal local de modo que se puede encontrar de forma fácil y eficaz por los otros nodos. Como consecuencia de la provisión eficiente de información concerniente a los canales de operación temporal de los nodos, se pueden explotar múltiples bandas de frecuencia mejorando significativamente por lo tanto la capacidad de la red basada en IEEE 802.11. Además, el método de acuerdo con la invención requiere sólo una interfaz de red por nodo de red, lo que posibilita que los nodos de red conmuten entre canales de operación diferentes.

De acuerdo con una realización preferida se puede prever que un nodo tenga un estado operativo de "reposo o recepción" y un estado operativo de "envío", en donde un nodo permanece en su canal local cuando está en el estado operativo de "reposo o recepción". El estado operativo de "reposo o recepción" significa que un nodo está en este estado cuando no tiene ningún paquete que enviar, es decir, el nodo está en reposo o está recibiendo paquetes. Por otra parte, un nodo está en el estado de "envío" cuando tiene paquetes pendientes para otro nodo. Consecuentemente, cuando un nodo tiene paquetes pendientes para otro nodo, realiza una transición desde el estado de "reposo o recepción" al estado de "envío".

Ventajosamente, la coordinación entre un nodo de envío y un nodo de recepción se hace una vez al comienzo de una conexión. Tal implementación de MAC multicanal no descansa en la sincronización de reloj y es de este modo atractiva ya que tiene una menor complejidad de implementación, es más robusta y más efectiva en costes.

En el caso de que un nodo - nodo de envío - tenga paquetes pendientes para otro nodo - nodo de recepción - que tiene el mismo canal local que el nodo de envío, se puede prever que el nodo de envío difunda una petición de sincronización sobre su canal local. Cuando el nodo de recepción recibe la petición de sincronización, que es posible ya que opera (es decir, transmite y recibe) sobre el mismo canal (local), puede responder con una respuesta de sincronización correspondiente, después de esta secuencia de puesta en contacto, los dos nodos pueden comenzar el intercambio de datos.

De acuerdo con una realización preferida particularmente los canales seleccionados se proporcionan con canales de encuentro que sirven como puntos de contacto para nodos que residen sobre canales diferentes. Los canales de encuentro son solo canales normales de IEEE 802.11 que de este modo se pueden usar convencionalmente, para intercambiar datos. Sin embargo, también sirven como puntos de contacto inicial entre dos nodos arbitrarios en el caso de que no se encuentren entre sí sobre sus canales locales. La lista de canales de encuentro se puede especificar a priori por un administrador de la red o pueden ser simplemente un subconjunto de canales disponibles en un cierto orden.

En el caso de que un nodo - nodo de envío - tenga paquetes pendientes para otro nodo - nodo de recepción - que tiene otro canal local distinto que el nodo de envío, el nodo de envío tendrá que dejar su canal local temporalmente y tendrá que intentar encontrar y alcanzar el nodo de recepción sobre otro canal. En tal caso se puede prever que el nodo de envío, antes de dejar su canal local difunda un mensaje de redirección de canal sobre su canal local. El mensaje de redirección de canal puede indicar el nuevo canal al que conmuta el nodo de envío, de modo que los otros nodos que residen sobre el canal local del nodo de envío se informan de dónde encontrar el nodo de envío. Con respecto a una política de información más comprensible, se puede prever que el nodo de envío difunda también sucesivamente el mensaje de redirección de canal sobre los canales de encuentro. Para tener en cuenta las colisiones y los errores de bits, el nodo de envío puede retransmitir su mensaje de redirección de canal unas pocas veces sobre cada uno de los canales mencionados anteriormente.

Con respecto al proceso de descubrimiento de un nodo de recepción que tiene otro canal local distinto del canal de envío, se pueden distinguir dos casos: en el caso de que el nodo de envío conozca el canal local del nodo de recepción, puede solo conmutar a ese canal e intentar contactar con el nodo de recepción difundiendo una petición de sincronización sobre ese canal. El nodo de recepción, en el caso de que esté sobre su canal local, puede responder a continuación a la petición de sincronización con una respuesta de sincronización. Como ya se ha mencionado anteriormente, después de tal secuencia de puesta en contacto, puede comenzar el intercambio de datos. Por otra parte, en el caso de que el nodo de recepción no esté (temporalmente) sobre su propio canal local, otros nodos sobre el canal local del nodo de recepción que tienen conocimiento acerca del canal actual del nodo de recepción pueden responder al nodo de envío con un mensaje de redirección de canal "gratuito". El conocimiento al respecto puede resultar del hecho de que el nodo de recepción, antes de haya dejado su canal local, también ha difundido un mensaje de redirección del canal sobre su propio canal local, indicando a otros nodos sobre ese canal, el nuevo canal de operación (temporal) del nodo de recepción.

En caso de no obtener respuesta sobre el canal local del nodo de recepción (ni por el propio nodo de recepción, ni por ningún otro nodo sobre ese canal) y/o en el caso de no conocer dicho canal local del nodo de recepción, se puede prever que el nodo de envío busque al nodo de recepción sucesivamente a través de la lista de canales de encuentro. La razón para esto es que si el nodo de recepción esté ausente de su canal local, el nodo de recepción puede haber proporcionado indicios acerca de su canal actual sobre los canales de encuentro (como se ha explicado anteriormente). Más específicamente, se puede prever que el nodo de envío intente buscar el nodo de recepción a través de la lista de canales de encuentro, si no recibe una respuesta de sincronización o un mensaje de redirección de canal después de un número predefinido de peticiones de sincronización transmitidas.

En el caso de que el transmisor no reciba una respuesta de sincronización o un mensaje de redirección de canal sobre cualquiera de los canales de encuentro, se puede prever además que el nodo de envío proceda a buscar el nodo de recepción sobre el resto de canales de datos. Sin embargo, debido a la provisión de información por un nodo que deja su canal local de acuerdo con la presente invención este caso debería ocurrir raramente y solo se entiende como un último recurso para proporcionar una solución a prueba de fallos.

Con respecto a la determinación o asignación fiable de un canal local, se puede prever que cada nodo elija inicialmente su canal local en base a su identificador de nodo, por ejemplo, la dirección de MAC. Sin embargo, cuando un nodo detecta que su canal local actual está congestionado, el nodo puede elegir aleatoriamente otro canal local.

También en este caso se puede prever que el nodo difunda un mensaje de redirección de canal respectivo sobre su canal local antiguo, y como puede ser el caso, que adicionalmente anuncie sobre los canales de encuentro su nuevo canal local. Para evitar inestabilidad, un nodo puede usar su nuevo canal local durante un intervalo mínimo de tiempo mínimo antes de elegir otro nuevo canal local si detecta que su nuevo canal local está también congestionado.

De acuerdo con una realización preferida la implementación de dicha comunicación multicanal se basa en hardware de acuerdo con la normativa IEEE 802.11. El protocolo para el salto multicanal asíncrono propuesto se puede implementar como una extensión para el protocolo MAC de IEEE 802.11. En esta conexión es importante observar que aunque se introducen tres nuevas tramas de control (petición de sincronización, respuesta de sincronización y mensaje de redirección de canal), es posible implementarlas dentro de la estructura de la normativa de IEEE 802.11. Por ejemplo, estas tramas se pueden codificar como elementos de información incorporados en las tramas de acción de IEEE 802.11. Este enfoque permite que el método propuesto sea compatible con los nodos IEEE 802.11 heredados ya que estos pueden ignorar los elementos de información que codifican mensajes de control relacionados con la presente invención, aunque opera con nodos que implementan la presente invención usando el MAC de IEEE 802.11.

Hay varios modos sobre cómo diseñar y desarrollar adicionalmente las enseñanzas de la presente invención en un modo ventajoso. Para este fin, se hace referencia a las reivindicaciones de la patente, subordinadas a la reivindicación de patente 1 por una parte, y a la siguiente explicación de un ejemplo preferido de una realización de la invención ilustrada por los dibujos por otra parte. En conexión con la explicación del ejemplo preferido de una realización de la invención con la ayuda de los dibujos, se explicarán de forma general realizaciones preferidas y desarrollos adicionales de las enseñanzas. En los dibujos

La Fig. 1 ilustra esquemáticamente una primera realización de un método de acuerdo con la presente invención en un escenario de aplicación básica.

La Fig. 2 ilustra esquemáticamente una segunda realización de un método de acuerdo con la presente invención con redirección de canal a través de canales locales, y

La Fig. 3 ilustra esquemáticamente una tercera realización de un método de acuerdo con la presente invención con redirección de canal a través de canales de encuentro.

Básicamente, el método de acuerdo con la presente invención se puede denominar como un protocolo de salto multicanal asíncrono (denominado AMHP en lo siguiente). Un aspecto importante de la invención es que el AMHP permite que nodos que pertenecen a la misma red inalámbrica estén localizados sobre canales diferentes y proporciona un mecanismo distribuido para que los mismos se encuentren entre sí. Por este medio se puede obtener una mejora significativa de la capacidad de las redes inalámbricas.

En lo siguiente se proporcionan en primer lugar los requisitos para un MAC multicanal práctico y las motivaciones para estos requisitos. Las principales motivaciones son:

1) Equilibrio de carga a través de los canales:

El objetivo global del MAC multicanal es mejorar la capacidad de una red ad hoc distribuyendo los flujos que competen a cada uno de los otros sobre los diferentes canales ortogonales. De este modo, es importante que el MAC multicanal consiga el equilibrio de carga a través de todos los canales disponibles y evite un cuello de botella sobre cualquier canal individual.

2) Facilitar la coordinación entre nodos:

Otro objetivo importante del MAC multicanal es conseguir la coordinación entre nodos que posiblemente operan sobre diferentes canales. Por esta razón, un MAC multicanal tiene que proporcionar mecanismos eficientes para que los nodos se encuentren entre sí de forma rápida y fácil.

3) Ninguna sincronización de reloj:

Varios protocolos MAC multicanal requieren una sincronización de reloj de grano fino para conseguir la coordinación entre los nodos que posiblemente operan sobre diferentes canales. Como la sincronización de reloj es más bien compleja de realizar, un MAC multicanal que no se basa en la sincronización de reloj es más atractivo porque tiene una menor complejidad de implementación, y es más robusto y eficaz en costes.

4). Amortización de la sobrecarga de conmutación de canal:

Varios protocolos MAC multicanal existentes asumen que el retardo de conmutación de canal es más bien pequeño (decenas o centenas de microsegundos). Con esta suposición, la conmutación de canal frecuente incurre solo en una pequeña sobrecarga de funcionamiento y se puede usar para conseguir la coordinación entre los nodos. Sin embargo, las mediciones prácticas mostraron que el retardo de conmutación de canal sobre un hardware de IEEE

802.11 existente es más bien grande (varios milisegundos). Dada esta limitación práctica, es importante diseñar un protocolo MAC multicanal que evite la conmutación frecuente de canal.

El AMHP cumple con el requisito 1) permitiendo a los nodos operar sobre los diferentes canales inalámbricos. Además, el AMHP consigue un equilibrio de cargas permitiendo a un nodo seleccionar un canal de operación diferente cuando detecta que su canal de operación actual está sobrecargado.

Para cumplir el requisito 2), el AMHP facilita una coordinación eficiente entre nodos empleando dos mecanismos distribuidos para que los nodos se encuentren entre sí. En primer lugar, cada nodo tiene un canal local donde reside habitualmente de modo que los otros nodos le pueden encontrar fácilmente. En segundo lugar cuando un nodo deja su canal local, proporciona información acerca de su canal temporal.

El AMHP satisface el requisito 3) permitiendo a los nodos operar asíncronamente.

Para cumplir con el requisito 4), el AMHP incurre en una sobrecarga de conmutación inicial solo una vez al comienzo de una conexión. Esta sobrecarga de conmutación se amortiza sobre la duración de la conexión ya que después no se requiere ninguna conmutación adicional. En lugar de trabajar en base a un paquete o realizando conmutaciones periódicas de canal, el AMHP opera en base a una conexión o en una escala de tiempos relativamente larga (cientos de milisegundos). En esta escala de tiempos, el AMHP intenta conseguir el equilibrio de cargas distribuyendo los nodos a través de los diferentes canales. Si múltiples nodos comparten un canal, el AMHP se basa en el MAC de

802.11 para el control de acceso al medio en una corta escala de tiempo (decenas o centenas de microsegundos).

En AMHP, un nodo tiene dos estados operativos: reposo o recepción y envío. Un nodo está en el estado de reposo o recepción cuando no tiene ningún paquete para enviar. Un nodo está en el estado de envío cuando tiene paquetes pendientes para otro nodo.

1) Estado de reposo o recepción: en AMHP, cada nodo tiene un canal local. Un nodo permanece en su canal local cuando está en el estado de reposo o recepción. Cada nodo elige inicialmente su canal local en base a su dirección MAC. Sin embargo, cuando un nodo detecta que su canal local actual está congestionado, puede elegir aleatoriamente otro canal local y difundir una redirección de canal de AMHP sobre los canales de encuentro para anunciar su nuevo canal local. Para evitar la inestabilidad, un nodo usa su nuevo canal local durante un intervalo de tiempo mínimo antes de elegir otro nuevo canal local.

2) Estado de envío: cuando un nodo tiene paquetes pendientes para otro nodo, realiza una transición desde el estado de reposo o recepción al estado de envío. Si el transmisor y el receptor tienen el mismo canal local, el transmisor puede enviar una petición de sincronización de AMHP (petición de sincronización) y el receptor puede contestar con una respuesta de sincronización de AMHP (respuesta de sincronización). Después de esta secuencia de puesta en contacto, los dos nodos pueden comenzar el intercambio de datos. Si el transmisor no conoce el canal local del receptor o los dos nodos comparten diferentes canales locales, el transmisor realizará dos etapas: creación de una redirección de canal y encuentro del receptor

Etapa 1: Creación de una redirección de canal: Como el transmisor tiene que dejar su canal local temporalmente para buscar al receptor en otro canal, el transmisor informa a los otros nodos acerca de su canal temporal. Para este fin el transmisor difunde en primer lugar una redirección del canal de AMHP sobre su canal local y a continuación sobre una lista de canales seleccionados (canales de encuentro). Los canales de encuentro son solo canales normales de IEEE 802.11 que se pueden usar para el intercambio de datos. Sin embargo, también sirven como puntos de contacto inicial entre dos nodos arbitrarios en el caso de que no se encuentren entre sí sobre sus canales locales. Esta lista de canales de encuentro se puede especificar a priori por el administrador de la red o simplemente un subconjunto de canales disponibles en un cierto orden.

Etapa 2: Encontrar el nodo de recepción: si el transmisor conoce el canal local del receptor, el transmisor conmuta a ese canal e intenta contactar con el receptor difundiendo una petición de sincronización de AMHP. Si el receptor está en su canal local, contesta con una respuesta de sincronización de AMHP y los dos nodos pueden comenzar a intercambiar datos. Si el receptor está en otro canal, otros nodos sobre su canal local que tienen conocimiento acerca del canal temporal del receptor pueden responder al transmisor con una redirección de canal de AMHP gratuita. Si el transmisor no recibe una respuesta de sincronización de AMHP o una redirección de canal de AMHP después de transmitidas varias peticiones de sincronización de AMHP, intenta buscar el receptor sucesivamente sobre los canales de encuentro.

Aunque la etapa 1 y la etapa 2 se han descrito separadamente en favor de la claridad, es posible combinarlas. En este caso, un nodo difunde una petición de sincronización de AMHP y una redirección de canal de AMHP sucesivamente sobre los canales de encuentro para reducir la sobrecarga de conmutación de canal.

Cuando el transmisor no conoce el canal actual del receptor, busca sucesivamente el receptor sobre los canales de encuentro. La razón para esto es que el receptor esté ausente sobre su canal local. También se proporcionan indicios acerca de su canal actual sobre los canales de encuentro (como se ha explicado anteriormente). En caso de que el transmisor no reciba una respuesta de sincronización de AMHP o una redirección de canal de AMHP sobre cualquiera de los canales de encuentro, procede a buscar el receptor sobre los canales de datos restantes. Este caso debería ocurrir raramente y es solo significativo como el último recurso para proporcionar una solución a prueba de fallos.

Cuando el transmisor encuentra el receptor, el transmisor puede comenzar el intercambio de datos con el receptor. Después del intercambio de datos, el transmisor conmuta sucesivamente a los canales de encuentro y difunde una redirección de canal de AMHP para informar a los otros nodos de que ahora vuelve a su canal local.

En lugar de extender el MAC de IEEE 802.11 y operar en base a un paquete, el AMHP puede operar sobre una escala de tiempo diferente que el MAC de IEEE 802.11. De este modo, el AMHP y el MAC de IEEE 802.11 se complementan entre sí para conseguir el equilibrio de carga sobre múltiples canales en dos escalas de tiempos diferentes. Con la elección del diseño de AMHP, un nodo es capaz de intercambiar datos con múltiples nodos en un intervalo de tiempo. En otros protocolos MAC multicanal, un nodo solo puede intercambiar datos con otro nodo exclusivamente en un intervalo de tiempo.

Se ilustra una visión general operativa del AMHP en los siguientes tres escenarios.

En el escenario básico representado en la Fig. 1, los nodos A, B y C permanecen en su canal local respectivo cuando están en el estado operativo de "reposo o recepción", es decir, en el caso de que no tengan ningún paquete para enviar. Si el nodo A quiere intercambiar datos con el nodo C por ejemplo, el nodo A conmuta al canal local de C y comienza el intercambio de datos con C. Sin embargo, antes de que el nodo A conmute al nodo C, de acuerdo con la presente invención el nodo A deja información acerca de su canal operativo temporal - el canal local del nodo C - sobre su canal local. Más específicamente, el nodo A difunde un mensaje de redirección de canal respectivo sobre su canal local antes de conmutar al canal local del nodo C. Por lo tanto, los otros nodos residentes en el canal local del nodo A están informados de donde se encuentra el nodo A.

Después de haber realizado la transición desde el estado de "reposo o recepción" al estado de "envío" y después de haber conmutado al canal local del nodo C, el nodo A envía una petición de sincronización "petición de sincronización de AMHP" (no mostrada) y el nodo de recepción C responde con una respuesta de sincronización "respuesta de sincronización de AMHP" (no mostrada tampoco). Una vez realizada esta secuencia de puesta en contacto, se puede comenzar el intercambio de datos. Después de que se termine el intercambio de datos, el nodo A conmuta de vuelta a su canal local.

Un ejemplo de redirección de canal a través del canal local se ilustra en la Fig. 2. En este escenario, los nodos A, B, C y D permanecen en primer lugar sobre sus canales locales respectivos, en donde el nodo A y el nodo D comparten el mismo canal local. Cuando el nodo A quiere intercambiar datos con el nodo C por ejemplo, de nuevo difunde en primer lugar un mensaje de redirección de canal y a continuación conmuta al canal local de C. Después de realizar una secuencia de puesta en contacto entre los nodos A y C sobre el canal local del nodo C (por ejemplo, por medio de una "petición de sincronización de AMHP" y una "respuesta de sincronización de AMHP"), los dos nodos pueden comenzar a intercambiar datos.

Además, de acuerdo con el escenario ilustrado en la Fig. 2, el nodo B quiere intercambiar datos con el nodo A y de este modo conmuta al canal local del nodo A. Sin embargo, el nodo A temporalmente no opera sobre su canal local, sino sobre el canal local del nodo C. En consecuencia, el nodo B recibe una redirección de canal desde el nodo D, que ha recibido anteriormente el mensaje de redirección de canal desde el nodo A y que de este modo está informado acerca del canal operativo temporal del nodo A. En base a esta notificación, el nodo B puede conmutar al canal del nodo C para comunicar con el nodo A. Después de realizar la secuencia de puesta en contacto con el nodo A sobre el canal local del nodo C, el nodo B y el nodo A pueden comenzar a intercambiar datos. Se observará que los nodos A, B y C pueden compartir un canal común usando el protocolo MAC de IEEE 802.11 original.

Un ejemplo de redirección de canal a través de un canal de encuentro se ilustra en la Fig. 3. Aunque en favor de la claridad solo se representa un canal de encuentro en la Fig. 3, se entenderá que en escenarios de aplicación real se pueden implementar varios canales diferentes de encuentro. En el escenario de la Fig. 3, los nodos A, B, C y D en primer lugar permanecen en sus canales locales respectivos. Cuando el nodo A quiere intercambiar datos con el nodo C, difunde un mensaje de redirección de canal sobre su canal local y sobre el canal de encuentro. (En el caso de que haya más de un canal de encuentro el mensaje de redirección de canal se puede difundir sobre cada uno de los diferentes canales de encuentro). Posteriormente, el nodo A conmuta al canal local del nodo C y comienza el intercambio de datos con el nodo C.

El nodo B quiere intercambiar datos con el nodo A y conmuta al canal local del nodo A. Difunde una "petición de sincronización de AMHP" pero no recibe ninguna respuesta ya que el nodo A está temporalmente operando sobre el canal local del nodo C y de este modo no recibe la "petición de sincronización de AMHP" del nodo B sobre su propio canal local. El nodo B, como no recibe ninguna respuesta a la "petición de sincronización de AMHP", conmuta al canal de encuentro (o sucesivamente a los diferentes canales de encuentro en el caso de más de un canal de encuentro) y recibe una redirección de canal del nodo D. El nodo D está informado acerca del canal de operación actual del nodo A debido al mensaje de redirección difundido por el canal del nodo A sobre el canal de encuentro. Una vez recibida la redirección de canal desde el nodo D, el nodo B conmuta al canal local del nodo C y comienza el intercambio de datos con el nodo A. En esta conexión se observará que los nodos A, B, C y D pueden compartir un canal común usando el protocolo MAC de IEEE 802.11 original.

Muchas modificaciones y otras realizaciones de la invención mostrada en este documento vendrán a la mente de los expertos en técnica a la que pertenece la invención que tienen el beneficio de las enseñanzas presentadas en la descripción anterior y los dibujos asociados. Por lo tanto, se entenderá que la invención no está limitada a las realizaciones específicas reveladas y que las modificaciones y otras realizaciones se pretende que estén incluidas dentro del alcance de las reivindicaciones adjuntas. Aunque se emplean términos específicos en este documento, se usan en un sentido genérico y no para propósitos de limitación.

Claims (15)

1. REIVINDICACIONES

   1. Un método para la comunicación entre nodos en una red inalámbrica, en particular en una red inalámbrica ad hoc

   o de malla, en el que se proporcionan múltiples canales inalámbricos con diferentes bandas de frecuencia y en el que dichos nodos están habilitados para funcionar sobre dichos canales diferentes, en el que cada uno de dichos nodos tiene asignado un canal local en el que reside habitualmente, caracterizado por que un nodo que deja su canal local y conmuta a otro de dichos múltiples canales - canal de operación temporal - proporciona información acerca de dicho canal temporal de operación sobre dicho canal local del nodo.

2. 2.

   El método de acuerdo con la reivindicación 1, en el que un nodo tiene un estado operativo de "reposo o recepción" y un estado operativo de "envío", y en el que un nodo permanece en su canal local cuando está en el estado operativo de "reposo o recepción".

3. 3.

   El método de acuerdo con la reivindicación 1 o 2, en el que la coordinación entre un nodo de envío y un nodo de recepción se realiza una vez al comienzo de una conexión.

4. 4.

   El método de acuerdo con cualquiera de las reivindicaciones 1 a 3, en el que el nodo de envío difunde una petición de sincronización sobre su canal local en caso de que tenga paquetes pendientes para un nodo de recepción que tiene el mismo canal local, en el que el intercambio de datos entre dicho nodo de envío y dicho nodo de recepción se puede comenzar una vez que dicho nodo de recepción ha difundido una respuesta de sincronización.

5. 5.

   El método de acuerdo con cualquiera de las reivindicaciones 1 a 4, en el que los canales seleccionados se proporcionan como canales de encuentro que sirven como puntos de contacto inicial para los nodos que residen sobre canales diferentes, en el que dichos canales de encuentro se pueden especificar a priori por el administrador de la red.

6. 6.

   El método de acuerdo con cualquiera de las reivindicaciones 1 a 5, en el que el nodo de envío difunde un mensaje de redirección de canal sobre su canal local en el caso de que tenga paquetes pendientes para un nodo de recepción que tiene otro canal local.

7. 7.

   El método de acuerdo con la reivindicación 6, en el que dicho nodo difunde sucesivamente dicho mensaje de redirección de canal sobre dichos canales de encuentro.

8. 8.

   El método de acuerdo con la reivindicación 6 o 7, en el que dicho nodo de envío, en caso de que conozca dicho canal local del nodo de recepción, conmuta a ese canal y difunde una petición de sincronización sobre ese canal.

9. 9.

   El método de acuerdo con la reivindicación 8, en el que dicho nodo de recepción, en caso de que esté sobre su canal local, responde a dicho nodo de envío con una respuesta de sincronización.

10. 10.

    El método de acuerdo con la reivindicación 8, en el que, en caso de que dicho nodo de recepción no esté sobre su canal local, otros nodos sobre dicho canal local del nodo de recepción responden a dicho nodo de envío con un mensaje de redirección de canal.

11. 11.

    El método de acuerdo con cualquiera de las reivindicaciones 6 a 10, en el que dicho nodo de envío, en caso de no recibir ninguna respuesta y/o en el caso de no conocer dicho canal local del nodo de recepción, busca dicho nodo de recepción sucesivamente a través de la lista de canales de encuentro, en el que dicho nodo de envío, en caso de que no encuentre dicho nodo de recepción sobre cualquiera de dichos canales de encuentro, puede proceder a buscar el receptor sobre los canales de datos restantes.

12. 12.

    El método de acuerdo con cualquiera de las reivindicaciones 1 a 11, en el que se especifica un canal local del nodo sobre la base de dicho identificador del nodo.

13. 13.

    El método de acuerdo con cualquiera de las reivindicaciones 1 a 12, en el que un nodo, en caso de que detecte que dicho canal local - canal local actual -está congestionado, elije aleatoriamente otro canal local - nuevo canal local - .

14. 14.

    El método de acuerdo con cualquiera de las reivindicaciones 1 a 13, en el que un nodo, en caso de que elija un nuevo canal local, anuncia su nuevo canal local por medio de la difusión de un mensaje de redirección de canal.

15. 15.

    El método de acuerdo con cualquiera de las reivindicaciones 1 a 14, en el que la implementación de dicha comunicación multicanal se basa en hardware de acuerdo con la normativa de IEEE 802.11.