ES2804875T3

ES2804875T3 - Nodo de enrutador, red y método para permitir el descubrimiento de servicios en una red

Info

Publication number: ES2804875T3
Application number: ES17205104T
Authority: ES
Inventors: Timothy Speight
Original assignee: Veea Systems Ltd
Current assignee: Veea Systems Ltd
Priority date: 2016-12-07
Filing date: 2017-12-04
Publication date: 2021-02-09
Anticipated expiration: 2037-12-04
Also published as: US20180159818A1; US10491562B2; EP3334126A1; GB201620798D0; EP3334126B1; GB2557329A

Abstract

Nodo de enrutador (500) para una red (400), en el que el nodo de enrutador (500) se caracteriza por: un transceptor (506, 522, 524); una interfaz (508) acoplada operativamente al transceptor (506, 522, 524) y configurada para comunicarse por medio de múltiples tecnologías, en el que la interfaz permite que se conecten a la red dispositivos externos a la red usando una primera tecnología y que se comuniquen con otros nodos en la red usando una segunda tecnología; y una caché (516); y un procesador de señales (528) acoplado operativamente a la cache (516) y la interfaz (508) y configurado para soportar un protocolo de consenso; en el que el procesador de señales (528) está configurado para: recibir registros de recursos por medio de la interfaz (508) usando la primera tecnología, almacenar los registros de recursos recibidos en la caché (516) y distribuir registros de recursos a otros nodos en la red (400) por medio de la interfaz usando la segunda tecnología; y recibir registros de recursos de al menos otro nodo en la red por medio de la interfaz (508) usando la segunda tecnología, almacenar los registros de recursos recibidos en la caché (516) y responder a una consulta de registro de recursos de un dispositivo externo conectado a la red (400) por medio de la primera tecnología.

Description

DESCRIPCIÓN

Nodo de enrutador, red y método para permitir el descubrimiento de servicios en una red

Campo técnico

El campo de esta invención se refiere generalmente a un nodo de enrutador, a redes pequeñas, tales como redes domésticas o de malla, y a un método para permitir el descubrimiento de servicios en estas redes. En particular, algunas realizaciones de ejemplo de la invención proporcionan un nodo de enrutador que está configurado para usar un protocolo de consenso para ser capaz de almacenar en caché registros de recursos de mDNS-SD.

Antecedentes

El descubrimiento de servicios es el mecanismo por el cual las máquinas anfitrionas pueden detectar automáticamente dispositivos y servicios ofrecidos por estos dispositivos en una red. La cuestión es importante tanto para el servicio orientado a seres humanos convencional como para las aplicaciones de internet de las cosas (IoT). El problema se ilustra en los siguientes ejemplos. En un primer ejemplo, un usuario doméstico compra una impresora de red para su red doméstica. Desean encender el dispositivo, conectarlo a su red y comenzar a imprimir sin experiencia específica en la gestión de redes. No desean forzarla a usar una dirección de IP estática y configurarla manualmente en su ordenador/tableta. En un segundo ejemplo, se supone que miles de dispositivos con sensores de IoT están conectados a una red y a cada uno se le asigna dinámicamente una dirección de IP. Una función de procesamiento desea ubicar los dispositivos para que pueda procesar los datos que proporcionan sin tener que configurar manualmente un gran número de direcciones de IP.

Se han propuesto varios protocolos de descubrimiento de servicios. Sin embargo, el descubrimiento de servicios basado en DNS es el más ampliamente usado en la actualidad y es capaz de proporcionar funcionalidad en toda la gama de casos de uso, desde el ejemplo del usuario doméstico hasta el caso de IoT. El sistema de nombres de dominio de multidifusión DNS (mDNS) junto con el descubrimiento de servicios basado en DNS (DNS-SD) proporciona un medio simple por el cual puede implementarse el descubrimiento de servicios con poco equipo dedicado o personal experimentado para gestionar la funcionalidad. Un DNS es un sistema de nombres descentralizado jerárquico para ordenadores, servicios o cualquier recurso conectado a internet o una red privada. Asocia varios elementos de información con nombres de dominio asignados a cada una de las entidades participantes.

Normalmente, un servidor de DNS convencional requiere la configuración manual de los archivos de zona. Esto sería posible, por ejemplo, en una red empresarial grande donde un profesional de TI configuraría, por ejemplo, registros de DNS para la impresora de oficina para permitir la impresión de archivos desde cualquier lugar de la oficina, incluso si los clientes no están en el mismo segmento LAN.

En el entorno familiar, este no es el caso. No puede esperarse que un usuario doméstico complete los registros de DNS o gestione los nombres de los dispositivos. Para este fin se desarrolló mDNS. Esto permite que la funcionalidad DNS funcione en el enlace local sin un servidor de DNS centralizado (es decir, dentro de un solo segmento LAN) usando transmisiones de multidifusión.

Definida en RFC 6762. La funcionalidad de mDNS puede describirse brevemente como: proporcionar la capacidad de realizar operaciones similares a DNS en ausencia de cualquier servidor de unidifusión convencional. Por tanto, el propósito principal de mDNS es potenciar la resolución de nombres en la red de área local.

Debido al hecho de que mDNS opera solo en el enlace local, los nombres no tienen la misma forma que la usada en el DNS convencional, donde se aplican estructuras de nombres de dominio jerárquicas típicas, tales como 'printer02.men67.virtuosys.com'. En su lugar, se define un nuevo dominio de nivel superior, '.local.'. Este nuevo espacio de nombres da como resultado nombres de máquinas anfitrionas tales como 'printer02.local'.

DNS-SD es un protocolo estandarizado para describir y resolver servicios usando registros de recursos de DNS. DNS-SD define cómo un cliente puede aprovechar consultas de DNS estándar para descubrir instancias de servicio usando registros de PTR, SRV, TXT y A/AAAA. La innovación clave en DNS-SD es el uso de indirección en la consulta de registros de PTR que permite que una máquina anfitriona busque una lista de servicios disponibles. Por tanto, en lugar de encontrar un servicio específico, una máquina anfitriona puede consultar las impresoras y obtener una respuesta, que indica una impresora de laboratorio, una impresora de oficina, una impresora de sala de reuniones, etc., de la cual la máquina anfitriona puede elegir la respuesta adecuada. DNS-SD define un esquema de nombres de instancia de servicio estructurado para permitir que esto se logre.

El grupo de redes domésticas de IETF (https://tools.ietf.org/wg/homenet/) ha estado trabajando en el problema de las redes domésticas modernas complejas que implican múltiples enlaces con múltiples conexiones externas posibles (por ejemplo, ISP para internet general y otro ISP para aplicaciones multimedia). Con la tecnología actual, en estos escenarios se requiere que el usuario doméstico realice la gestión de la red con el fin de garantizar el rendimiento en la red. Por ejemplo, con múltiples enlaces de capa 2, la funcionalidad de mDNS no funcionará en toda la red doméstica. También puede haber conflictos de direcciones de IP, etc. El grupo de redes domésticas ha producido RFC con el fin de definir la funcionalidad de autoconfiguración de las redes domésticas de modo que las redes se configuren por sí mismas óptimamente sin tener que realizar una gestión de red compleja. Los RFC que definen la funcionalidad de red doméstica incluyen los siguientes.

RFC 7368 ('Principios de arquitectura de redes domésticas IPv6 (HNAP)'), que proporciona los requisitos de arquitectura y diseño para una red doméstica.

RFC 7787 ('Protocolo de consenso de nodos distribuidos (DNCP)'). DNCP proporciona un marco para el mecanismo por el cual los nodos pares intercambian información de estado sobre ellos mismos de una manera eficiente (ya que es un protocolo de consenso que está optimizado de modo que requiere el mínimo de señalización cuando no hay cambio en la información). Permite que se usen varios perfiles sobre el marco proporcionado por DNCP.

RFC 7788 ('Protocolo de control de red doméstica (HNCP)'). HNCP es un protocolo de configuración extensible y un conjunto de requisitos para dispositivos de redes domésticas. HNCP se describe como un perfil y extensión del Protocolo de consenso de nodos distribuidos (DNCP). HNCP permite el descubrimiento de los límites de la red, la configuración automática de direcciones, la resolución de nombres y el uso de cualquier protocolo de enrutamiento que admita el enrutamiento basado en tanto la dirección de origen como de destino. HNCP es un perfil que se asienta encima de DNCP. Define parámetros que son importantes en el control de los nodos de HNCP dentro de una red doméstica, tales como prefijos y direcciones de IP, descubrimiento de servicios, qué nodos deben realizar DHCP para un enlace particular, etc.

RFC 7695 ('Algoritmo de asignación de prefijos distribuidos (DPAA)'). Este RFC define un algoritmo para elegir un prefijo que se usará en un enlace de un grupo de prefijos disponibles para evitar un conflicto. Además, un algoritmo de goteo (RFC 6206) define un modo en el que bajos volúmenes de datos se transfieren eficientemente durante períodos de reposo en la red.

El propósito principal de los algoritmos de HNCP/DNCP es permitir que los nodos conozcan el estado de la información en todos los demás nodos de HNCP/DNCP pares de la red.

HNCP define un número de tipo-longitud-valor (TLV), que describe parámetros tales como los prefijos que un nodo ha asignado a sus interfaces, la dirección de IP que el propio nodo está utilizando, información sobre la conexión externa de la red (solo asociada con nodos que son enrutadores de borde, que pueden denominarse nodo de borde de malla (MEN). Dentro de los protocolos de comunicación de datos, la información opcional puede codificarse como un elemento de TLV (algunas veces denominado etiqueta-longitud-valor) dentro de un protocolo. El tipo y la longitud son de tamaño fijo (normalmente de 1 a 4 bytes), y el campo de valor es de tamaño variable. Estos campos se usan tal como sigue: tipo: Un código binario, a menudo simplemente alfanumérico, que indica la clase de campo que esta parte del mensaje representa; longitud: el tamaño del campo de valor (normalmente en bytes); y valor: serie de bytes de tamaño variable que contiene datos para esta parte del mensaje.

El objetivo del algoritmo es garantizar que cada nodo conozca los TLV actuales de todos los demás nodos de HNCP en la red. Sin embargo, simplemente enviar estos TLV periódicamente es ineficiente. Por tanto, cada nodo calcula un hash de su propio conjunto de TLV y cada uno de los TLV para otros nodos pares, estos se denominan hashes de nodo. Obsérvese también que las ID de nodo se asignan a cada nodo para identificar el nodo individual apropiadamente. Entonces usa este conjunto de hashes de nodo para crear un hash de red. Esta funcionalidad hash jerárquica se ilustra en la figura 1.

En referencia ahora a la figura 1, se ilustra una visión general de una arquitectura conocida 100 de un árbol de hash. Cada nodo 130, 132, 134, 136 crea un hash basándose en la información que desea publicar en la red. Cada nodo 130, 132, 134, 136 opera un protocolo de consenso, tal como HNCP/DNCP, para garantizar que todos los nodos conocen toda la información, tal como su dirección de protocolo de internet (IP), un prefijo asignado y una indicación de las capacidades de nodo, etc. sobre sus pares. En la figura 1, el nodo 3134 se identifica como un enrutador de borde en la red (que puede denominarse nodo de borde de malla) ya que tiene una conexión de red de retorno a internet y puede identificarse además mediante información de enrutador de borde, tal como un prefijo delegado 135. La información de cada uno de los nodos de HNCP/DNCP 130, 132, 134, 136 se transfiere 122 a una función de hash de nodo 120 que codifica datos específicos de nodo, antes de transferir 112 toda la información de hash de nodo dentro de una red a una función de hash de red 110. Los nodos de HNCP/DNCP 130, 132, 134, 136 están dispuestos para multidifundir un hash de red 110 (a la dirección de multidifusión de todos los nodos de la red doméstica, ff02::11). Mientras que cada uno de los nodos de HNCP/DNCP 130, 132, 134, 136 transmite el mismo hash de red 110, un algoritmo de goteo garantiza que hay una actividad mínima en la red (la velocidad de transmisión se reduce lentamente a lo largo del tiempo hasta que se alcanza un nivel mínimo).

Cuando uno de los nodos de HNCP/DNCP 130, 132, 134, 136 tiene un cambio de información en sus TLV, entonces volverá a calcular su hash de nodo 120 dando como resultado una actualización de su hash de red 110. Este nuevo hash de red 110 se multidifundirá entonces a todos los demás nodos. Cuando un nodo vecino recibe este nuevo hash de red 110, detectará que es diferente de su propio hash de red 110 y usará la señalización de unidifusión para solicitar que el nodo envíe sus hashes de nodo 120. El nodo vecino inspeccionará entonces los hashes de nodo 120 y solicitará entonces los datos de nodo completos para la ID de nodo, que tiene un hash diferente al que ha almacenado.

Obsérvese que se usan números de secuencia de modo que se detecte el hash más nuevo. El nodo envía entonces los datos de nodo completos (usando unidifusión) para el nodo solicitado al nodo vecino.

Estos nuevos datos pueden entonces ondularse a través de la red de modo que todos los nodos 130, 132, 134, 136 conozcan los nuevos datos de TLV y, por tanto, todos los nodos 130, 132, 134, 136 tengan el mismo hash de red 110, que multidifundirán todos, es decir, se alcanza un nuevo estado estacionario en la red donde todos tienen la información actualizada.

Una vez que los nodos tienen la información actualizada sobre su grupo de pares, pueden tomar decisiones razonables por sí mismos sobre su propia configuración. Por ejemplo, cuando conocen los prefijos que los otros nodos están usando actualmente, pueden evitar por sí mismos asignar estos prefijos a sus propias interfaces.

Un problema conocido con tal funcionalidad de mDNS/DNS-SD es cómo operar eficientemente en una red de subredes múltiples pequeña. En la figura 2 se usa una red de malla inalámbrica 200 para ilustrar este problema, donde cada nodo actúa como enrutador y permite que se conecten dispositivos externos a la red usando conectividad inalámbrica. Aunque el problema se explica con respecto a una red que usa conectividad inalámbrica, podría aplicarse igualmente bien a un caso de red doméstica donde se usan dispositivos de enrutador que están conectados por tecnología alámbrica, tal como línea de potencia o Ethernet permitiendo nuevamente que un dispositivo externo se conecte mediante, por ejemplo, WiFi™ u otros medios. En estos escenarios de red restringida es apropiado mDNS, debido a su simplicidad. Sin embargo, no puede usarse mDNS ya que está diseñado para funcionar solo en el enlace local, es decir a través de una única subred.

La red de malla inalámbrica 200 incluye una conexión de red de retorno 212 que conecta un enrutador de borde (nodo de borde de malla (MEN)) 220 en la red a, por ejemplo, el internet 210. El MEN 220 está conectado 231 a un servidor de mensajería 230. La red de malla inalámbrica 200 incluye varios enrutadores internos (algunas veces denominados nodos de malla (MN)) que proporcionan funcionalidad de enrutamiento en la red de malla inalámbrica 200, pero no tienen una conexión de red de retorno. Los dispositivos de MN en la red de malla inalámbrica 200 tienen funcionalidad WiFi™ (u otra tecnología inalámbrica), separada de las interconexiones de malla, lo que permite que se conecten dispositivos externos a la red de malla inalámbrica 200. Por ejemplo, un primer MN#1 222 de una primera área de red 242 incluye un primer teléfono inteligente #1 252 y un altavoz habilitado para red 253 y está acoplado 235 al MEN 220. Un segundo m N#2228 de una segunda área de red 248 incluye una impresora habilitada para red 258 y también está acoplada 236 al MEN 220. El segundo MN#2 228 también está acoplado 233 a un servidor 232 de procesamiento de sensor de temperatura de internet de las cosas, dispuesto para procesar datos del sensor de temperatura. Un tercer MN#3 224 de una tercera área de red 244 incluye un sensor de temperatura 254 de internet de las cosas y está acoplado 237 al segundo MN#2 228. Un cuarto m N#4 226 de una cuarta área de red 246 incluye un segundo teléfono inteligente #2256 y también está acoplado 238 al segundo MN#2228.

Cada uno de los enrutadores internos/enrutadores de borde internos (MN/MEN) 220, 222, 224, 226, 228 incluye, por ejemplo, un punto de acceso (AP) 802.11 u 802.15.4 o Bluetooth™ habilitado para IPv6, etc., que permite que los dispositivos de máquina anfitriona externos se conecten al dispositivo.

En funcionamiento, el primer teléfono inteligente #1 252 desea usar el altavoz habilitado para red 253. El altavoz habilitado para red 253 está conectado al mismo punto de acceso (AP), concretamente el primer MN#1 222, que el primer teléfono inteligente #1 252. Por tanto, usan ambos el mismo enlace local. Por tanto, el primer teléfono inteligente #1 252 puede usar mDNS/DNS-SD convencional para descubrir este altavoz habilitado para red 253; puesto que mDNS solo funciona en el enlace local y no se requiere modificación en los nodos de enrutador ni en ninguno de los dispositivos del cliente.

Sin embargo, si el segundo teléfono inteligente #2 256 desea usar la impresora habilitada para red 258, es incapaz de usar mDNS/DNS-SD convencional. Esto se debe a que estos dos clientes están conectados a AP diferentes, es decir en el cuarto MN#4226 de la cuarta área de red 246 y en el segundo MN#2228 de la segunda área de red 248. Por tanto, están en enlaces locales diferentes y, por tanto, las consultas de DNS de multidifusión enviadas desde el segundo teléfono inteligente #2256 no se enrutarán al segundo MN#2228 y luego a la impresora habilitada para red 258.

Se requiere un mecanismo para permitir que las máquinas anfitrionas equipadas con mDNS se comuniquen entre sí en la malla, es decir, es necesario un mecanismo para encontrar la dirección de IP de la impresora habilitada para red 258 ubicada en otro AP.

Se produce un problema similar con el sensor de temperatura 254 de IoT, que necesita encontrar un servidor en el que puedan procesarse sus mediciones. El servidor de procesamiento de mediciones reside en o está acoplado a) el segundo MN#2 228, que no está en el mismo enlace local que el sensor de temperatura 254 de IoT. Es necesaria nuevamente una solución que use mDNS simple en el sensor de temperatura 254 de IoT.

Se produce un problema similar adicional cuando el primer teléfono inteligente #1 252 y el segundo teléfono inteligente #2 256 desean hablar entre sí por medio de un servidor de mensajería que está ubicado en el MEN 220. De nuevo, el problema para el primer teléfono inteligente #1 252 y el segundo teléfono inteligente #2256 es encontrar la dirección de Ip del servicio (por medio de un servidor de mensajes) que desean, aunque no esté en el mismo enlace local. Sin embargo, esta vez el servicio no reside en un dispositivo externo sino que está ubicado en (o acoplado a) un nodo de enrutador, concretamente MEN 220.

Por tanto, sería útil permitir que todos los dispositivos se comuniquen con todos los demás dispositivos dentro de la red y externos a la red, y para que cada uno de los dispositivos realice la misma funcionalidad que algunos de los demás dispositivos, se requiere un mecanismo para gestionar esta operación interfuncional compleja. También sería útil observar todos estos servicios a través de la malla completa (o red doméstica o cualquier otra red de salto múltiple restringida). Estos servicios no pueden observarse usando esta tecnología convencional, excepto si el servicio está ubicado en el enlace local soportado, por ejemplo, conectado al mismo AP.

Una solución conocida para este problema es usar un descubrimiento de servicios basado en DNS de unidifusión/multidifusión híbrido (por ejemplo tal como se describe en https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03). El descubrimiento de servicios basado en DNS de unidifusión/multidifusión híbrido se basa en una funcionalidad híbrida que reside en los nodos de HNCP (nodos de enrutador en una red de malla inalámbrica pequeña), con el fin de descubrir registros de DNS de multidifusión en su enlace local, y hacer que los registros de DNS correspondientes sean visibles en el espacio de nombres de DNS de unidifusión. Esta funcionalidad se ilustra en la arquitectura de malla 300 de la figura 3, que describe un DNS de unidifusión/multidifusión híbrido, tal como propone Cheshire en un RFC experimental.

La arquitectura de malla 300 incluye una conexión de red de retorno 312 que conecta un enrutador de borde (nodo de borde de malla (MEN)) 320 en la red con, por ejemplo, el internet 310. La arquitectura de malla 300 incluye varios enrutadores internos (algunas veces denominados nodos de malla (MN)) que proporcionan funcionalidad de enrutamiento en la arquitectura de malla 300, pero que no tienen una conexión de red de retorno. Por ejemplo, un primer MN#1 322 está acoplado 335 al MEN 320 y dispuesto para cubrir una primera área de red 342 (subred) que incluye un primer teléfono inteligente #1 352. Un segundo MN#2 324 está acoplado 336 al MEN 320 y dispuesto para cubrir una segunda área de red 344 (subred) que incluye una impresora habilitada para red 354.

En el descubrimiento de servicios basado en DNS de unidifusión/multidifusión híbrido de la figura 3, un (cliente) primer teléfono inteligente #1 352 envía una consulta de DNS de unidifusión 362 para impresoras en un dominio específico. Esta se envía a su servidor de DNS local (que es de hecho un sustituto híbrido) en el primer MN#1 322. Se usa una funcionalidad de DNS recursiva convencional de modo que la consulta se reenvía 372 hasta que alcanza el servidor de nombres autorizado delegado para el dominio apropiado, concretamente el sustituto híbrido en el segundo MN#2324.

El sustituto híbrido en el segundo MN#2324 puede consultar su caché de mDNS (no mostrado) para determinar si tiene un registro que es apropiado para responder a la consulta (al igual que un servidor de DNS convencional consultaría los registros de recursos (RR) para los que está autorizado). Sin embargo, en este caso, no hay información en caché apropiada. Por tanto, emite una consulta de mDNS donde traslada la consulta desde _printer._tcp.mn2.men8912.vmesh.com. 365 hasta _printer._tcp.local 364. Este mensaje de mDNS se multidifunde entonces en la subred asociada con el segundo MN#2324.

La impresora responde a esta solicitud de PTR respondiendo con su nombre 'impresora de laboratorio'. Esta respuesta de PTR se envía de nuevo usando DNS de multidifusión. El sustituto híbrido en el segundo MN#2 324 convierte entonces esto de nuevo en DNS de unidifusión (adjuntando su dominio delegado) y esto se envía de nuevo al teléfono inteligente, por medio de la función de DNS en el primer MN#1 322.

Tal como se comentó anteriormente, una pregunta obvia que surge es cómo el dispositivo de teléfono inteligente del cliente sabe que tiene que consultar el dominio 'mn2.men8912.vmesh.com'. La respuesta es la enumeración de dominios. Esta es una característica de DNS-SD tal como se describe en la sección 11 de la especificación de DNS-SD en RFC6763, que proporciona a los clientes recomendaciones sobre en qué dominios buscar el servicio. El cliente envía una consulta de PTR para nombres de registros definidos, estos incluyen lo siguiente: el dominio de navegador, que usa el PTR b._dns-sd._udp. Esta es una lista de dominios en los que buscar los servicios, es decir RR en el servidor de DNS con esta serie contendrían una lista de dominios.

El dominio por defecto, que usa el PTR db._dns-sd._udp. Este es un único dominio por defecto en el que buscar los servicios.

El dominio de búsqueda heredado - lb._dns-sd._udp. El sustituto híbrido responderá a las consultas enviadas al PTR con las series anteriores para tanto el caso de unidifusión como de multidifusión. En este ejemplo conocido, estos registros en el DNS (para el caso de multidifusión) podrían tener este aspecto:

b._dns-sd._udp. PTR mn1. men8912.vmesh.com

mn2. men8912.vmesh.com

db _dns-sd._udp. PTR mn1. men8912.vmesh.com

lb.__dns-sd._udp. PTR mn1. men8912.vmesh.com

Obsérvese que los clientes aprenden normalmente la ubicación de su dirección de servidor de DNS doméstico y nombre de dominio doméstico de DNS doméstico por medio de las opcionales de DHCP, véase RFC 2132 (código 6 = dirección de DNS, código 15 = nombre de dominio de DNS).

Los inventores han identificado que hay tres problemas principales con el mecanismo de sustituto híbrido de la figura 3, cuando se usa en una red de malla inalámbrica pequeña.

En primer lugar, existe la necesidad de asignar nombres de dominio a los enlaces. En redes domésticas y redes de malla inalámbrica pequeñas, realmente no debería ser necesario hacer esto; los nodos en estas redes pueden añadirse dinámicamente debido a nuevos dispositivos que aparecen o cambios en el entorno de radio, en el caso de redes de malla inalámbricas, tener que añadir dinámicamente nombres de dominio y gestionarlos de manera autónoma es problemático cuando no hay un beneficio real a obtener.

En segundo lugar, los clientes deben tener alguna imagen de la malla. Cuando se lleva a cabo la enumeración de dominios, al cliente se le presenta una lista de dominios en los que buscar, cuál debe elegirse no es obvio.

En tercer lugar, la arquitectura de redes domésticas y redes de malla inalámbricas pequeñas es tal que realmente no existe ninguna necesidad de tener dominios separados dentro de cualquiera de los enlaces en la malla. La propuesta significa que la funcionalidad es innecesariamente compleja.

El documento US2005/044355 describe una técnica para mensajes de multidifusión que se usan en una única subred para el descubrimiento de servicios. Se requiere por tanto una solución para permitir el descubrimiento de servicios usando mDNS para operar en redes de subredes múltiples pequeñas, tales como redes de malla inalámbricas.

Sumario de la invención

En un primer aspecto de la invención, se describe un nodo de enrutador para una red (tal como una red pequeña). El nodo de enrutador comprende: un transceptor; una interfaz acoplada operativamente al transceptor y configurada para comunicarse por medio de múltiples tecnologías, en el que la interfaz permite que se conecten a la red dispositivos externos usando una primera tecnología y que se comuniquen con otros nodos en la red usando una segunda tecnología; una caché y un procesador de señales acoplado operativamente a la caché y la interfaz y configurado para soportar un protocolo de consenso. El procesador de señales está configurado para recibir registros de recursos por medio de la interfaz usando la primera tecnología, almacenar los registros de recursos recibidos en la caché y distribuir registros de recursos a otros nodos en la red por medio de la interfaz usando la segunda tecnología; y recibir registros de recursos de al menos otro nodo en la red por medio de la interfaz usando la segunda tecnología, almacenar los registros de recursos recibidos en la caché y responder a una consulta de registro de recursos de un dispositivo externo conectado a la red por medio de la primera tecnología.

De esta manera, un uso de un protocolo de consenso por un nodo de enrutador permite que el nodo de enrutador distribuya registros de recursos a otros nodos en la red de malla por medio de la interfaz y almacene los registros de recursos en la caché con el fin de soportar el descubrimiento de servicios en redes de subredes múltiples pequeñas, tales como redes de malla inalámbricas.

En un ejemplo opcional de la invención, los registros de recursos almacenados en la caché pueden incluir información del sistema de nombres de dominio de multidifusión, mDNS, de nodo de enrutador. En un ejemplo opcional de la invención, el procesador de señales puede estar configurado para soportar un uso de descubrimiento de servicios de DNS, DNS-SD, para determinar un protocolo de internet, IP, la dirección de dispositivos y otros nodos de enrutador ubicados en la red. En algunos ejemplos, los registros de recursos pueden incluir un tipo-longitud-valor, TLV, que describe mDNS, información de caché de otros nodos en la red de malla.

En un ejemplo opcional de la invención, el protocolo de consenso puede ser un protocolo de consenso de nodos distribuidos, DNCP, y en algunos ejemplos puede usarse un perfil de protocolo de control de red doméstica, HNCP, como extensión del DNCP.

En un ejemplo opcional de la invención, el procesador de señales y el transceptor pueden estar configurados para publicar un registro de recursos siempre que se actualiza la caché. En algunos ejemplos, la caché puede actualizarse tras recibir un mensaje de anuncio de un nuevo servicio dentro de la red.

En un ejemplo opcional de la invención, el transceptor puede recibir una consulta de mDNS y el procesador de señales puede determinar si el servicio de mDNS consultado está contenido en la caché, y si el servicio consultado está contenido en la caché, el procesador de señales envía una respuesta a la consulta. En algunos ejemplos, el procesador de señales puede estar configurado además para determinar si los registros de DNS para el servicio consultado se han aprendido del protocolo de consenso, y el procesador de señales envía una respuesta a la consulta cuando el servicio consultado está contenido en la caché y el servicio consultado se ha aprendido del protocolo de consenso.

En un ejemplo opcional de la invención, el procesador de señales puede estar configurado para compartir la información de caché de mDNS del nodo de enrutador usando el protocolo de consenso con al menos otro nodo de enrutador en la red en una red pequeña de una de un grupo de: una red de malla, una red doméstica.

En un segundo aspecto de la invención, se describe un método para permitir el descubrimiento de servicios en una red (tal como una red pequeña) que comprende un nodo de enrutador acoplado a una caché. El método incluye, en el nodo de enrutador: soportar un protocolo de consenso; recibir un registro de recursos que identifica uno o más nodos o dispositivos diferentes contenidos en o acoplados a la red según el primer aspecto; almacenar el registro de recursos recibido en la caché; y distribuir registros de recursos desde la caché hasta otros nodos y dispositivos dentro de la red según el primer aspecto.

En un tercer aspecto de la invención, se describe una red (tal como una red pequeña) que comprende un nodo de enrutador según el primer aspecto. La red incluye una caché; al menos un nodo de enrutador acoplado a la caché y que comprende un transceptor; una interfaz acoplada operativamente al transceptor; y un procesador de señales acoplado operativamente al transceptor y configurado para soportar un protocolo de consenso. El procesador de señales está configurado para recibir y distribuir registros de recursos a otros nodos en la red por medio de la interfaz y almacenar los registros de recursos en la caché. El alcance de la invención se define mediante las reivindicaciones adjuntas.

Breve descripción de los dibujos

Se describirán detalles, aspectos y realizaciones adicionales de la invención, a modo de ejemplo solo, con referencia a los dibujos. En los dibujos, se usan números de referencia iguales para identificar elementos iguales o funcionalmente similares. Los elementos en las figuras se ilustran por simplicidad y claridad y no se han dibujado necesariamente a escala.

La figura 1 ilustra una visión general de una arquitectura conocida de un árbol de hash usado en HNCP/DNCP.

La figura 2 ilustra un conjunto de ejemplo conocido de dispositivos en una malla.

La figura 3 ilustra un ejemplo conocido de una disposición de DNS de unidifusión/multidifusión híbrido, tal como propone Cheshire en un RFC experimental.

La figura 4 ilustra un ejemplo simple de un descubrimiento de servicios de m-DNS propuesto en una red de malla inalámbrica pequeña según algunas realizaciones de ejemplo de la presente invención.

La figura 5 ilustra un ejemplo de un nodo de enrutador modificado, tal como un nodo de enrutador en una red (tal como una red pequeña), según algunas realizaciones de ejemplo de la presente invención.

La figura 6 ilustra un diagrama de flujo de ejemplo para el funcionamiento de un nodo de enrutador cuando se recibe un anuncio, según algunas realizaciones de ejemplo de la presente invención.

La figura 7 ilustra un diagrama de flujo de ejemplo que ilustra un diagrama de flujo de ejemplo para el funcionamiento de un nodo de enrutador cuando se recibe una consulta según algunas realizaciones de ejemplo de la presente invención.

Los expertos en la técnica apreciarán que los elementos en las figuras se ilustran por simplicidad y claridad y no se han dibujado necesariamente a escala. Por ejemplo, las dimensiones y/o el posicionamiento relativo de algunos de los elementos en las figuras pueden estar exagerados en relación con otros elementos para ayudar a mejorar la comprensión de diversas realizaciones de la presente invención. Además, elementos comunes pero bien entendidos que son útiles o necesarios en una realización comercialmente viable a menudo no se representan con el fin de facilitar una vista menos obstruida de estas diversas realizaciones de la presente invención. Se apreciará además que determinadas acciones y/o etapas pueden describirse o representarse en un orden de aparición particular mientras que los expertos en la técnica entenderán que tal especificidad con respecto a la secuencia no se requiere realmente. También se entenderá que los términos y expresiones usados en el presente documento tienen el significado técnico habitual acordado para tales términos y expresiones por los expertos en el campo técnico tal como se expuso anteriormente excepto cuando se hayan expuesto de otra forma significados específicos diferentes en el presente documento.

Descripción detallada

Se describen realizaciones de ejemplo de la presente invención con respecto a nodos de enrutador en redes de malla inalámbricas pequeñas, que se han modificado para soportar una característica de descubrimiento de servicios. En realizaciones de ejemplo, se configuran nodos de enrutador con la adición de un protocolo de consenso para distribuir registros de recursos alrededor de la red. Los ejemplos de la invención describen un mecanismo para uno o más nodos de enrutador para distribuir registros de recursos, por ejemplo compartir sus cachés de mDNS, usando un protocolo de consenso, por ejemplo TLV de HNCP, con al menos otro nodo de enrutador en la red. Por tanto, en este ejemplo, se usa un TLV para describir información de caché de mDNS empleada por nodos de enrutador dentro de las redes de malla inalámbricas. En algunos ejemplos, la distribución de registros de recursos puede usarse para servicios ubicados en el nodo de enrutador o para servicios ubicados en al menos un dispositivo externo. En algunos ejemplos, la distribución de registros de recursos puede enviarse a múltiples (y en algunos casos todos) nodos de enrutador diferentes en una red de malla. Ventajosamente, los nodos de enrutador modificados pueden usar formas no modificadas de mDNS. Se usa descubrimiento de servicios de mDNS exclusivamente. No se usa descubrimiento de servicios de DNS de unidifusión para descubrir servicios en un enlace diferente (como es el caso para la solución de sustituto híbrido).

De esta manera, uno o múltiples nodos de enrutador pueden enviar anuncios de mDNS que se almacenan en la caché en otros nodos de enrutador. De manera similar, uno o múltiples nodos de enrutador pueden actuar como respondedores de mDNS para consultas que están asociadas con clientes que están ubicados fuera del enlace local (usando los registros de recursos compartidos (por ejemplo información de caché de mDNS) obtenidos de otro nodo de enrutador).

Aunque una característica conocida clave de mDNS es que solo funciona en un enlace local, un uso de un nuevo TLV de HNCP permite que los nodos de enrutador dentro de una red pequeña, tal como una red de malla inalámbrica o red doméstica, resuelvan el problema de cómo gestionar qué dispositivo realiza determinadas funciones dentro de la red. Esta selección de qué dispositivo realiza determinadas funciones dentro de la red se resuelve compartiendo de manera inteligente información de dispositivos entre los nodos de enrutador dentro de la red de malla, usando, por ejemplo, un TLV para describir información de caché de mDNS empleada por nodos de enrutador dentro de las redes de malla inalámbricas.

La funcionalidad global es tal que desde una perspectiva de descubrimiento de servicios parece como si todos los clientes pertenecieran al mismo enlace (a pesar del hecho de que se emplea enrutamiento L3 en la malla).

En referencia ahora a la figura 4, se ilustra un ejemplo de una red de malla inalámbrica pequeña 400 configurada para soportar un protocolo de consenso, tal como funcionalidad de mDNS/DNS-SD, según algunas realizaciones de ejemplo de la invención. En este ejemplo, dispositivos del cliente incluyendo un teléfono inteligente simple y una impresora de red se ubican en la red de malla inalámbrica pequeña 400 de ejemplo. La red de malla inalámbrica pequeña 400 incluye una conexión de red de retorno 412 que conecta un enrutador de borde (algunas veces denominado enrutador de borde interno o nodo de borde de malla (MEN)) 420 en la red con, por ejemplo, el internet 410. La red de malla inalámbrica pequeña 400 incluye varios enrutadores internos (algunas veces denominados nodos de malla (MN)) que proporcionan funcionalidad de enrutamiento en la red de malla inalámbrica pequeña 400, pero no tienen una conexión de red de retorno. Por ejemplo, un primer MN#1 422 está acoplado 435 al m En 420 y dispuesto para cubrir una primera área de red 442 que incluye un primer teléfono inteligente #1 452. Un segundo MN#2 424 está acoplado 436 al MEN 420 y dispuesto para cubrir una segunda área de red 444 que incluye una impresora habilitada para red 454.

En este ejemplo de la red de malla inalámbrica pequeña 400 que soporta un protocolo de consenso, tal como funcionalidad de mDNS/DNS-SD, la impresora habilitada para red 454 usa un mensaje de sondeo conocido de consultas de mDNS para comprobar que el nombre de cliente elegido es único. El segundo MN#2 424 consulta su caché (no mostrado) para determinar si tenía una entrada almacenada para ese nombre de cliente. Si tiene una entrada almacenada, entonces el nombre que la impresora habilitada para red 454 había elegido no sería único y sería necesario que el segundo MN#2424 respondiera con el fin de defender este nombre. En este ejemplo de la figura 4, no aparece tal registro en la caché. Tras haberse enviado un mensaje de sondeo, y no recibirse respuesta, la impresora habilitada para red 454 sabe que su nombre elegido es único según el comportamiento convencional asociado con mDNS. La impresora habilitada para red 454 envía entonces un anuncio 464, que es una respuesta a la consulta que contiene todos los registros de recursos que desea usar o publicar, tal como se define en RFC 6762. El segundo MN#2 424 almacena entonces todos estos registros en su caché de mDNS (no mostrado).

Según realizaciones de ejemplo, siempre que se actualiza una caché de mDNS, esta información se publica usando un protocolo de consenso, tal como HNCP/DNCP, usando por ejemplo nuevos TLV que contienen información de caché de mDNS del nodo de enrutador. Este protocolo permite que la información se comparta entre todos los nodos de HNCP/DNCP (el protocolo de HNCP es otro perfil que se usa para permitir una política de asignación de prefijos de IP únicos y constantes). De este modo, todos los nodos tienen un conocimiento completo de la caché de mDNS de todos los demás enrutadores en la red. La señalización asociada con la compartición de protocolo de consenso de la información de caché de mDNS se ilustra en las comunicaciones 474 y 472. En un momento posterior, el primer teléfono inteligente #1 452 envía una consulta de PTR, que coincide con el registro de PTR para la impresora habilitada para red 454 (la información contenía el anuncio de 464).

Según realizaciones de ejemplo, el primer MN#1 422 ha obtenido la caché de mDNS contenida en el segundo MN#2 424 usando señalización de protocolo de consenso, tal como señalización de HNCP/DNCP, 474. Por tanto, puede responder directamente al primer teléfono inteligente #1 452, como si la impresora habilitada para red 454 estuviera en el enlace local del primer MN#1 422 (es decir, respondiendo con mDNS).

Según realizaciones de ejemplo, el primer MN#1 422 envía respuestas a la consulta al primer teléfono inteligente #1 452 con el fin de responder a las consultas enviadas desde el primer teléfono inteligente #1 452 como parte del proceso de descubrimiento de servicios.

En referencia ahora a la figura 5, se ilustra un ejemplo de un nodo de enrutador 500, tal como un nodo de enrutador en una red (tal como una red pequeña o de malla) modificado por la funcionalidad descrita en el presente documento, según algunas realizaciones de ejemplo de la presente invención. En realizaciones de ejemplo de la invención el nodo de enrutador 500 se ha modificado con la adición de un protocolo de consenso que permite que las cachés de mDNS se compartan alrededor de la red. En la práctica, meramente para los fines de explicar realizaciones de la invención, el nodo de enrutador 500 se describe en cuanto a tanto un dispositivo de comunicación inalámbrica como un dispositivo conectado por red alámbrica, tal como un ordenador, servidor de red, ordenador portátil, etc. En un sentido inalámbrico, el nodo de enrutador 500 contiene una o más antenas 502 para comunicarse por medio de diversas tecnologías inalámbricas. En un ejemplo, la una o más antenas 502 (acopladas por medio de una interfaz inalámbrica 508 con circuitos de transmisión y recepción asociados) están configuradas para radiar y recibir señales radiadas 532 en frecuencias de WiFi™ o frecuencias de bluetooth BT™ o frecuencias celulares, por ejemplo LTE™ a lo largo de una red celular (no mostrada).

En un ejemplo inalámbrico, la una o más antenas 502 están acopladas a un duplexor o interruptor de antena 504 que proporciona aislamiento entre las cadenas de recepción y transmisión dentro del nodo de enrutador 500, así como proporcionan aislamiento entre circuitos dirigidos a las tecnologías específicas que están soportándose, por ejemplo LTE™, WiFi™, BT™. Una o más cadenas de receptor, tal como se conoce en la técnica, incluyen circuitos de extremo frontal de receptor 506 (que proporcionan eficazmente recepción, filtración y conversión de frecuencia de banda intermedia o base). Los circuitos de extremo frontal de receptor 506 están acoplados a un procesador de señales 528 (generalmente realizado mediante un procesador de señales digitales (DSP)). Un experto en la técnica apreciará que el nivel de integración de componentes o circuitos de receptor puede ser, en algunos casos, dependiente de implementación. Un controlador 514 mantiene el control operativo global del nodo de enrutador 500. El controlador 514 también está acoplado a los circuitos de extremo frontal de receptor 506 y el procesador de señales 528. Un temporizador 518 está acoplado operativamente al controlador 514 para controlar la temporización de las operaciones (por ejemplo transmisión o recepción de señales dependientes del tiempo) dentro del nodo de enrutador 500.

En este ejemplo, el controlador 514 está conectado a un circuito/función 511 de protocolo de internet (IP), que está acoplado a una caché 516 y una o más tablas de enrutamiento de IP y/o software de protocolo de enrutamiento 512. En un sentido de red alámbrica, el controlador 514 puede estar acoplado operativamente a otros dispositivos y nodos por medio de una interfaz de red alámbrica 509 usando una conexión de red alámbrica 510, tal como Ethernet. En algunos ejemplos, el procesador de señales 528 del nodo de enrutador 500 puede abarcar mucha más funcionalidad que el circuito/función de IP 511 y tablas de enrutamiento de IP y/o software de protocolo de enrutamiento 512. En particular, en algunos ejemplos, se supone que el procesador de señales 528 puede manejar algo de o toda la funcionalidad de capa superior, tal como HNCp .

Hay varios enfoques diferentes que se prevé que pueden emplearse para el almacenamiento de servicios en el nodo de enrutador 500. Por tanto, en algunos ejemplos, el controlador 514 está acoplado a una caché 516 que almacena selectivamente registros de recursos de otros nodos y dispositivos, tanto internos como externos a la red de malla. En ejemplos de la invención, la caché 516 está configurada para almacenar servicios que son accesibles desde otros nodos de borde de malla o enrutadores internos en la red, por ejemplo nodo de borde de malla 420 o enrutadores internos 422, 424 en la figura 4. De esta manera, se registra un almacén de los registros de mDNS en la caché 516 en el nodo de enrutador 500, que puede leerse y actualizarse. En algunos ejemplos, puede usarse un nuevo perfil de DNCP para portar registros de mDNS (es decir, contenidos de caché de mDNS) entre nodos de enrutador, tales como el nodo de enrutador 500. De esta manera, se soporta la compartición de registros de mDNS alrededor de nodos de enrutador. En algunos ejemplos, tal compartición puede realizarse usando un HNCP, que es un protocolo (basado en consenso) que permite esta característica (es decir, compartir información alrededor de un grupo de dispositivos. En algunos ejemplos, el protocolo de HNCP puede incluir un nuevo TLV o cuando se añade un nuevo perfil completo al DNCP que se usa como protocolo base. En algunos ejemplos, los registros se obtienen del protocolo de DNCP nuevo/HNCP, que puede añadirse a los registros de recursos almacenados en la caché 516.

En algunos ejemplos, la caché 516 puede almacenar también regímenes operativos, tales como funciones de decodificación/codificación, patrones de sincronización, secuencias de código, y similares para ayudar a las comunicaciones inalámbricas. Con respecto a la cadena de transmisión, esta incluye esencialmente el procesador de señales 528 que está acoplado a través de uno o más circuitos de transmisor/modulación 522 y uno o más amplificadores de potencia 524 a una o más antenas 502, que pueden estar en forma de una serie de antenas, o una pluralidad de antenas. Los circuitos de transmisor/modulación 522 y los amplificadores de potencia 524 son sensibles operativamente al controlador 514.

Según realizaciones de ejemplo, el nodo de enrutador 500 y en particular el procesador de señales 528 del nodo de enrutador 500 se ha configurado para proporcionar anuncios a otros nodos de enrutador y dispositivos y responder a las consultas de la caché de mDNS 516. En algunos ejemplos, esto puede usar clasificaciones de registros de DNS, es decir registros nativos, donde puede permitirse que el nodo de enrutador 500 se responda a sí mismo e importe registros cuando la función de mDNS actualizada debe responderse a sí misma.

Además, el nodo de enrutador 500 y en particular el procesador de señales 528 del nodo de enrutador 500 se ha configurado para soportar una conexión inalámbrica y/o de red alámbrica tal como Ethernet. En algunos ejemplos, el procesador de señales 528 puede realizar todas las funciones requeridas del nodo de enrutador 500, o en otros ejemplos el procesador de señales 528 puede abarcar múltiples procesadores de señales, por ejemplo dedicados a las diversas tecnologías que están soportándose. En este sentido, el procesador de señales 528 que soporta una conexión inalámbrica puede implementarse de manera distinta de un procesador de señales que soporta una comunicación de Ethernet™. Alternativamente, puede usarse un único procesador para soportar cada tecnología. Claramente, los diversos componentes dentro del nodo de enrutador 500 pueden realizarse en forma de componentes diferenciados o integrados, con una estructura final que es por tanto una selección de diseño o específica de aplicación.

En referencia ahora a la figura 6, se ilustra un primer diagrama de flujo de ejemplo 600 de una operación de un nodo de enrutador con la adición de un protocolo de consenso que permite que se compartan cachés de mDNS alrededor de la red, tal como el nodo de enrutador 500 de la figura 5, según algunas realizaciones de ejemplo de la presente invención. El primer diagrama de flujo de ejemplo 600 describe una operación de nodo de enrutador cuando se recibe un 'anuncio'. En este caso, en 602, se hace una determinación de si se recibe un anuncio de mDNS de un nuevo servicio. Si no se recibe un anuncio de mDNS de un nuevo servicio, el diagrama de flujo regresa a 602. Si se recibe un anuncio de mDNS de un nuevo servicio, se actualiza la caché de mDNS, en 604. En 606, se usa el protocolo de consenso (por ejemplo extensión a HNCP) para enviar la caché actualizada a todos los nodos de enrutador en la red. Esto actualiza todas las cachés en la red añadiendo el nuevo servicio.

Se ilustra también un segundo diagrama de flujo de ejemplo 650 para el funcionamiento de un nodo de enrutador, tal como el nodo de enrutador 500 de la figura 5, cuando se recibe una consulta, según algunas realizaciones de ejemplo de la presente invención. En 652, se hace una determinación de si se recibe una consulta de mDNS. Si no se recibe una consulta de mDNS, el diagrama de flujo regresa a 652. Si se recibe una consulta de mDNS, se hace una determinación, por ejemplo mediante el procesador de señales 528 de la figura 5, de si el servicio consultado está contenido en una caché, en 654. Si el servicio consultado no está contenido en una caché, en 654, el diagrama de flujo regresa a 652. Si el servicio consultado está contenido en una caché, en 654, se envía una respuesta a la consulta desde una caché de servicio en 656.

En referencia ahora a la figura 7, se ilustra un tercer diagrama de flujo de ejemplo 700 de una operación de un nodo de enrutador con la adición de un protocolo de consenso que permite que se compartan cachés de mDNS alrededor de la red, tal como el nodo de enrutador 500 de la figura 5, según algunas realizaciones de ejemplo de la presente invención, cuando se recibe una consulta, se ilustra según algunas realizaciones de ejemplo de la presente invención. El tercer diagrama de flujo de ejemplo 700 describe una operación de nodo de enrutador cuando se recibe una consulta en el nodo de enrutador. En 702, se hace una determinación de si se recibe una consulta de mDNS. Si no se recibe una consulta de mDNS, el diagrama de flujo regresa a 702. Si se recibe una consulta de mDNS, se hace una determinación de si el servicio consultado está contenido en una caché, a 704. Si el servicio consultado no está contenido en una caché, en 704, el diagrama de flujo regresa a 702. Si el servicio consultado está contenido en una caché, en 704, se hace una determinación de si el servicio se ha aprendido directamente o del protocolo de consenso, en 706. Si el servicio se ha aprendido directamente en 706, el diagrama de flujo regresa a 702. Si el servicio se ha aprendido de un protocolo de consenso, en 706, se envía una respuesta a la consulta desde una caché de servicio en 708.

Se apreciará además que, por motivos de claridad, es posible que las realizaciones descritas de la invención con referencia a diferentes unidades funcionales y procesadores puedan modificarse o reconfigurarse con cualquier distribución adecuada de funcionalidad entre diferentes unidades funcionales o procesadores, sin restarle valor a la invención. Por ejemplo, la funcionalidad ilustrada que va a realizarse por procesadores o controladores separados puede realizarse por el mismo procesador o controlador. Por tanto, las referencias a unidades funcionales específicas solo deben considerarse como referencias a medios adecuados para proporcionar la funcionalidad descrita, en lugar de ser indicativas de una estructura u organización lógica o física estricta.

Los aspectos de la invención pueden implementarse en cualquier forma adecuada incluyendo hardware, software, firmware o cualquier combinación de estos. La invención puede implementarse opcionalmente, al menos en parte, como software informático que se ejecuta en uno o más procesadores de datos y/o procesadores de señales digitales. Por ejemplo, el software puede residir en un producto de programa informático no transitorio que comprende código de programa ejecutable para aumentar la cobertura en un sistema de comunicación inalámbrica.

Por tanto, los elementos y componentes de una realización de la invención pueden implementarse física, funcional y lógicamente de cualquier modo adecuado. De hecho, la funcionalidad puede implementarse en una sola unidad, en una pluralidad de unidades o como parte de otras unidades funcionales. Los expertos en la técnica reconocerán que los bloques funcionales y/o elementos lógicos descritos en el presente documento pueden implementarse en un circuito integrado para su incorporación en una o más de las unidades de comunicación.

Además, se pretende que los límites entre los bloques lógicos sean meramente ilustrativos y que realizaciones alternativas puedan fusionar bloques lógicos o elementos de circuito o imponer una composición alternativa de funcionalidad sobre varios bloques lógicos o elementos de circuito. Además, se pretende que las redes de malla inalámbricas pequeñas representadas en el presente documento sean meramente a modo de ejemplo, y que, de hecho, puedan implementarse muchas otras redes o arquitecturas de malla inalámbricas pequeñas que logren la misma funcionalidad.

Aunque la presente invención se ha descrito en relación con algunas realizaciones de ejemplo, no se pretende que se limite a la forma específica expuesta en el presente documento. Más bien, el alcance de la presente invención está limitado solo por las reivindicaciones adjuntas. Además, aunque puede parecer que una característica se describe en relación con realizaciones particulares, un experto en la técnica reconocería que diversas características de las realizaciones descritas pueden combinarse según la invención. En las reivindicaciones, el término “que comprende” no excluye la presencia de otros elementos o etapas.

Además, aunque se enumeran individualmente, pueden implementarse una pluralidad de medios, elementos o etapas de método, por ejemplo, mediante una sola unidad o procesador. Además, aunque pueden incluirse características individuales en diferentes reivindicaciones, estas posiblemente pueden combinarse ventajosamente, y la inclusión en diferentes reivindicaciones no implica que una combinación de características no sea viable y/o ventajosa. Además, la inclusión de una característica en una categoría de reivindicaciones no implica una limitación a esta categoría, sino que más bien indica que la característica es igualmente aplicable a otras categorías de reivindicaciones, tal como sea apropiado.

Además, el orden de las características en las reivindicaciones no implica ningún orden específico en el que deban realizarse las características y, en particular, el orden de las etapas individuales en una reivindicación de método no implica que las etapas deban realizarse en este orden. Más bien, las etapas pueden realizarse en cualquier orden adecuado. Además, las referencias en singular no excluyen una pluralidad. Por tanto, las referencias a 'un', 'una', 'primero', 'segundo', etc. no excluyen una pluralidad.

Claims

REIVINDICACIONES

1. Nodo de enrutador (500) para una red (400), en el que el nodo de enrutador (500) se caracteriza por:

un transceptor (506, 522, 524);

una interfaz (508) acoplada operativamente al transceptor (506, 522, 524) y configurada para comunicarse por medio de múltiples tecnologías, en el que la interfaz permite que se conecten a la red dispositivos externos a la red usando una primera tecnología y que se comuniquen con otros nodos en la red usando una segunda tecnología; y

una caché (516); y

un procesador de señales (528) acoplado operativamente a la cache (516) y la interfaz (508) y configurado para soportar un protocolo de consenso;

en el que el procesador de señales (528) está configurado para:

recibir registros de recursos por medio de la interfaz (508) usando la primera tecnología, almacenar los registros de recursos recibidos en la caché (516) y distribuir registros de recursos a otros nodos en la red (400) por medio de la interfaz usando la segunda tecnología; y

recibir registros de recursos de al menos otro nodo en la red por medio de la interfaz (508) usando la segunda tecnología, almacenar los registros de recursos recibidos en la caché (516) y responder a una consulta de registro de recursos de un dispositivo externo conectado a la red (400) por medio de la primera tecnología.

2. Nodo de enrutador (500) según la reivindicación 1, en el que los registros de recursos almacenados en la caché (516) comprenden información del sistema de nombres de dominio de multidifusión, mDNS, de nodo de enrutador.

3. Nodo de enrutador (500) según la reivindicación 2, en el que el procesador de señales está configurado para soportar un uso de descubrimiento de servicios de DNS, DNS-SD, para determinar una dirección de protocolo de internet, IP, de los dispositivos externos y de los otros nodos de enrutador ubicados en la red (400).

4. Nodo de enrutador (500) según cualquier reivindicación anterior, en el que los registros de recursos incluyen un tipolongitud-valor, TLV, que describe mDNS, información de caché de los otros nodos en la red.

5. Nodo de enrutador (500) según cualquier reivindicación anterior, en el que el protocolo de consenso es un protocolo de consenso de nodos distribuidos, DNCP.

6. Nodo de enrutador (500) según la reivindicación 5, en el que se usa un perfil de protocolo de control de red doméstica, HNCP, como extensión del DNCP.

7. Nodo de enrutador (500) según cualquier reivindicación anterior, en el que el procesador de señales (528) y el transceptor (506, 522, 524) están configurados para publicar un registro de recursos siempre que se actualiza la caché (516).

8. Nodo de enrutador (500) según la reivindicación 7, en el que la caché (516) se actualiza tras recibir un mensaje de anuncio de un nuevo servicio dentro de la red.

9. Nodo de enrutador (500) según cualquiera de las reivindicaciones anteriores 2 a 8, en el que el transceptor (506, 522, 524) recibe una consulta de mDNS y el procesador de señales determina si el servicio de mDNS consultado está contenido en la caché (516), y si el servicio consultado está contenido en la caché (516), el procesador de señales envía una respuesta a la consulta.

10. Nodo de enrutador (500) según la reivindicación 9, en el que el procesador de señales está configurado además para determinar si los registros de DNS para el servicio consultado se han aprendido del protocolo de consenso, y el procesador de señales envía una respuesta a la consulta cuando el servicio consultado está contenido en la caché (516) y el servicio consultado se ha aprendido del protocolo de consenso.

11. Nodo de enrutador (500) según cualquier reivindicación anterior, en el que el procesador de señales está configurado para compartir la información de caché de mDNS del nodo de enrutador usando el protocolo de consenso con al menos otro nodo de enrutador en una red pequeña de un grupo de: una red de malla, una red doméstica.

12. Método para permitir el descubrimiento de servicios en una red que comprende un nodo de enrutador (500) acoplado a una caché (516), comprendiendo el método, en el nodo de enrutador (500):

configurar una interfaz (508) para comunicarse por medio de múltiples tecnologías, en el que la interfaz permite que se conecten a la red dispositivos externos a la red usando una primera tecnología y que se comuniquen con otros nodos en la red usando una segunda tecnología;

soportar un protocolo de consenso;

recibir un registro de recursos que identifica uno o más nodos o dispositivos diferentes contenidos en o acoplados a la red por medio de la interfaz (508) usando la primera tecnología o segunda tecnología;

almacenar el registro de recursos recibido en la caché (516); y

distribuir registros de recursos de la caché (516) a o bien al menos otro nodo dentro de la red o bien un dispositivo externo conectado a la red usando la otra de la primera tecnología o segunda tecnología.

13. Método según la reivindicación 12, en el que los registros de recursos almacenados en la caché (516) comprenden información del sistema de nombres de dominio de multidifusión, mDNS, de nodo de enrutador.

14. Método según la reivindicación 13, que comprende además soportar un uso de descubrimiento de servicios de DNS, DNS-SD, para determinar una dirección de protocolo de internet, IP, de dispositivos y otros nodos de enrutador ubicados en la red.

15. Red (400) que comprende:

una caché (516);

al menos un nodo de enrutador (500) acoplado a la caché y que comprende:

un transceptor (506, 522, 524);

una interfaz (508) acoplada operativamente al transceptor (506, 522, 524) y configurada para comunicarse por medio de múltiples tecnologías, en el que la interfaz permite que se conecten a la red dispositivos externos a la red usando una primera tecnología y que se comuniquen con otros nodos en la red usando una segunda tecnología; y un procesador de señales acoplado operativamente a la caché (516) y la interfaz (508) y configurado para soportar un protocolo de consenso;

en el que el procesador de señales está configurado para recibir registros de recursos por medio de la interfaz (508) usando la primera tecnología o segunda tecnología y distribuir registros de recursos a o bien al menos otro nodo dentro de la red o bien un dispositivo externo conectado a la red por medio de la interfaz (508) usando la otra de la primera tecnología o segunda tecnología y almacenar los registros de recursos en la caché (516).