ES2668216T3 - Método para determinar un canal operacional en una red de comunicación, dispositivo restringido en energía y dispositivo intermediario - Google Patents

Método para determinar un canal operacional en una red de comunicación, dispositivo restringido en energía y dispositivo intermediario Download PDF

Info

Publication number
ES2668216T3
ES2668216T3 ES11799316.2T ES11799316T ES2668216T3 ES 2668216 T3 ES2668216 T3 ES 2668216T3 ES 11799316 T ES11799316 T ES 11799316T ES 2668216 T3 ES2668216 T3 ES 2668216T3
Authority
ES
Spain
Prior art keywords
channel
beacon
zgpd
succm
listen
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES11799316.2T
Other languages
English (en)
Inventor
Ludovicus Marinus Gerardus Maria Tolhuizen
Bozena Erdmann
Armand Michel Marie Lelkens
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Signify Holding BV
Original Assignee
Philips Lighting Holding BV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Philips Lighting Holding BV filed Critical Philips Lighting Holding BV
Application granted granted Critical
Publication of ES2668216T3 publication Critical patent/ES2668216T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
    • H04W52/02—Power saving arrangements
    • H04W52/0209—Power saving arrangements in terminal devices
    • H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
    • H04W52/0229—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal where the received signal is a wanted signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/02—Selection of wireless resources by user or terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Método para determinar un canal de radio operacional de un conjunto C de canales de radio, de una red de comunicación, comprendiendo dicha red de comunicación al menos dos intermediarios potenciales (ZGPP1, ZGPP2) para que un dispositivo restringido en energía (ZGPD) se una a la red, estando dichos al menos dos intermediarios potenciales en modo de puesta en marcha, comprendiendo el método las siguientes etapas: - el dispositivo restringido en energía (ZGPD) intenta unirse a la red, en el que para cada intento i, - el dispositivo restringido en energía (ZGPD) transmite en difusión de MAC un mensaje de baliza (Baliza GPDF) en un canal ci del conjunto C, y conmuta a modo de recepción en el canal listen(ci), en el que listen es una función aritmética, de C a C, - en el que el siguiente canal en el que el dispositivo restringido en energía transmitirá el siguiente mensaje de baliza para el siguiente intento i+1 es ci+1>=succ(ci), en el que succ es la función aritmética, de C a C; - al menos uno de los intermediarios (ZGPP1, ZGPP2) recibe un primer mensaje de baliza (Baliza GPDF) enviado en el canal de radio operacional c_op, - aplicar un mecanismo para determinar un dispositivo maestro temporal (ZGPP1) entre los al menos dos intermediarios potenciales, - el dispositivo maestro temporal (ZGPP1) conmuta su receptor de radio al canal succm(c_op), siendo m un número entero positivo distinto de cero, en el que succm indica que la función succ se aplica m veces, de manera que succm(c) >= succ(succm-1(c)), - el dispositivo restringido en energía (ZGPD) transmite un mensaje de baliza adicional en el canal de radio succm(c_op) y conmuta al modo de recepción en el canal listen(succm(c_op)), - tras la recepción del mensaje de baliza adicional, el dispositivo maestro temporal transmite una respuesta (Baliza Rsp GPDF) en un canal listen( succm(c_op)), - el dispositivo restringido en energía (ZGPD) recibe la respuesta de baliza en un canal listen(succm(c_op)), determinando que c_op es el canal operacional.

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Método para determinar un canal operacional en una red de comunicación, dispositivo restringido en energía y dispositivo intermediario
Campo de la invención
La invención se refiere a la puesta en marcha de dispositivos restringidos en energía en una red. Específicamente, se refiere a la puesta en marcha de Dispositivos de Energía no Contaminante ZigBee (ZGPD) de acuerdo con la especificación de Energía no Contaminante ZigBee en una red de ZigBee que incluye dispositivos aptos para ZGP.
Más en general, la invención se refiere a la manera para que los dispositivos restringidos en energía determinen el canal operacional de la red de comunicación a la que se han de unir, por ejemplo una red de ZigBee.
Para la aplicación de la presente invención, un dispositivo de ZGPD es, por ejemplo, un conmutador inalámbrico sin baterías, que recoge energía a partir de empujar y/o soltar el balancín. Esta energía puede usarse para transmisión de datos de radio, recepción de datos de radio o ambas.
Otro ejemplo de ZGPD es un dispositivo de sensor con alimentación solar, tal como sensor de temperatura, sensor de presencia/ocupación/movimiento, sensor de humedad, sensor de CO, sensor de CO2, sensor de nivel de luz, o un sensor múltiple que es una combinación de un número se sensores.
Otro ejemplo más de ZGPD es un botón-pulsador o RC con potencia solar.
Otro ejemplo más es un contador de agua o gas alimentado por flujo, o un contador de potencia alimentado por la energía electromecánica por el cable en el que está colocado alrededor.
En general, la invención es aplicable a cualquier ZGPD que use recogida de energía (mecánica, solar, electromagnética, basada el flujo, etc.) con funcionalidad de detección, medición o control. Adicionalmente, la invención es también aplicable a otros dispositivos que implementan la especificación de ZGP en el papel de ZGPD, por ejemplo dispositivos operados con batería con tamaño de batería muy limitado y/o expectativa de tiempo de vida muy larga, por ejemplo un contador de flujo alimentado por batería. Adicionalmente, la invención también es aplicable a cualquier dispositivo restringido en energía implementado de acuerdo con cualquier tecnología inalámbrica que pueda soportar múltiples canales.
Dentro del significado de la presente memoria descriptiva, el término “intermediario” se usa cuando se hace referencia a un dispositivo que puede recibir señales desde un ZGPD/un dispositivo restringido en energía.
En caso del ZGPD de acuerdo con la especificación de ZGP, puede ser el ZGPP o ZGPT+ o ZGPC de acuerdo con la especificación de Energía no Contaminante de ZigBee. En caso de cualquier otra tecnología, es el receptor como se define por esta tecnología.
Antecedentes de la invención
En la fase de puesta en marcha, un ZGPD se ha de unir a una red de ZigBee. Una etapa esencial en la puesta en marcha, es obtener el canal de radio en el que está operando la red de ZGP, denominado el canal operacional.
En entornos de ZigBee de múltiples saltos dirigidos para el uso de ZGPD, el uso de un canal de puesta en marcha separado predefinido no es posible, puesto que conmutar toda la red de ZigBee al canal de puesta en marcha es propenso a errores, problemático e impactará negativamente a dispositivos finales de ZigBee en espera.
Es un requisito en el procedimiento de puesta en marcha tener una posibilidad de implicar dispositivos intermedios, puesto que el ZGPD puede ya estar instalado y estar fuera de rango de radio del dispositivo con y/o por el que se supone que está configurado y/o emparejado (es decir el dispositivo que controlará).
La exploración pasiva o activa para actividad de red (de acuerdo con procedimientos del IEEE 802.15.4) es también costosa en energía para el ZGPd.
Otros métodos de ajuste de canal, tal como escribiéndolo, introduciéndolo usando conmutador DIP en el ZGPD, etc., se consideran demasiado complicados para el usuario doméstico y requieren medios de interfaz de usuario y/o hardware especializados.
Por consiguiente, la presente invención describe un procedimiento para que un dispositivo restringido en energía que tiene recepción limitada obtenga el canal de red operacional. El aspecto principal es que la energía recogida se usa para enviar una solicitud de baliza y para recibir una respuesta. La respuesta, sin embargo, no es la respuesta a esta solicitud de baliza actual, sino a una solicitud de baliza anterior.
5
10
15
20
25
30
35
40
45
50
55
60
65
Sumario de la invención
Es un objeto de la invención proponer un método para determinar un canal operacional c_op de acuerdo con la reivindicación 1, un dispositivo restringido en energía de acuerdo con la reivindicación 13 y un dispositivo intermediario de acuerdo con la reivindicación 15.
En una realización específica del método, el dispositivo restringido en energía transmite mensajes de baliza posteriores hasta que se recibe respuesta de baliza, cada baliza i en el canal succ'(c) en difusión de MAC,
- en el que succ es una función aritmética, de C a C, i es un número entero no negativo, succ' indica que la función succ se aplica i veces, de manera que succm(c) = succ(succm-1(c)), y conmuta al modo de recepción en el canal listen(succ'(c)).
- los intermediarios que reciben el mensaje de baliza en el canal operacional c_op comunican en el canal c_op para determinar el dispositivo maestro temporal
- el dispositivo maestro temporal conmuta su receptor de radio al canal succm(c),
- tras la recepción de la baliza en succm(c), el dispositivo maestro temporal transmite la respuesta de baliza en un canal listen(succm(c)),
- el dispositivo restringido en energía recibe la respuesta de baliza en un canal listen(succm(c)), y determina el c_op.
En otra realización, las funciones listen y succ son de manera que existe un número entero d de manera que listen(succd(c)) = c
En otra realización, las funciones listen y succ y el número entero d son de manera que listen(succd(c)) = c, y el parámetro m está fijado a m=d de modo que el dispositivo restringido en energía recibe la respuesta de baliza en el canal operacional.
En otra realización, la función listen es de manera que listen(c) = c, de modo que el dispositivo restringido en energía-recursos no necesita conmutar a un canal de radio diferente para recibir señales.
En otra realización, la función listen es una función constante, de modo que el dispositivo restringido en energía siempre escucha al mismo canal.
En otra realización, la función succ está comprendida en el grupo que comprende: incrementar en uno y realizar envolvente en C, decrementar en uno y voltear en C, un conjunto ordenado (recurrente), cualquier otra función que comprende una característica de incremento o decremento en C, incrementar en parte de C y decrementar en otra parte de C, y una función no monotónica.
En otra realización, el dispositivo restringido en energía envía al menos canales, antes de escuchar.
En otra realización, las funciones succ y/o listen son conocidas tanto por el dispositivo restringido en energía como los intermediarios.
En otra realización, la función succ y/o listen no son conocidas por los intermediarios, y en el que la baliza transmitida por el dispositivo restringido en energía comprende información que permite que el intermediario determine las funciones pertinentes de succ y listen.
En otra realización, el parámetro m está fijado por especificación o en la producción de ZGPD.
En otra realización, el parámetro m puede elegirse, teniendo en cuenta fenómenos de interconexión en red que comprenden: carga de tráfico en el medio, carga de tráfico en el dispositivo, distancia en recuento de saltos, velocidad de procesamiento en el dispositivo.
En otra realización, la determinación del dispositivo maestro temporal se realiza de acuerdo con el procedimiento especificado en la especificación de Energía no Contaminante ZigBee, que implica un dispositivo sumidero, que se empareja al dispositivo restringido en energía.
En otra realización, la determinación del dispositivo maestro temporal se realiza de acuerdo con cualquier algoritmo distribuido o centralizado.
En otra realización, se designan N dispositivos maestros temporales adecuados durante el procedimiento de determinación, en el que N es un número entero mayor que 1 y cada uno de ellos escucha un canal diferente.
En otra realización, las tramas de baliza y de respuesta de baliza únicamente contienen información para hallar el canal operacional c_op, y en el que el intercambio de parámetros de configuración tiene lugar tras hallar el c_op.
5
10
15
20
25
30
35
40
45
50
55
60
65
En otra realización, las tramas de baliza y de respuesta de baliza contienen los parámetros de configuración requeridos y en el que tras hallar el c_op no se requiere intercambio de puesta en marcha adicional.
En otra realización, la energía usada para transmitir balizas, recibir respuestas de baliza y el procesamiento requerido se recoge en el dispositivo restringido en energía a partir de una acción mecánica realizada por un usuario en el dispositivo.
En otra realización, la energía usada para transmitir balizas, recibir respuestas de baliza y el procesamiento requerido se recoge en el dispositivo restringido en energía de manera autónoma.
La invención también se refiere a un dispositivo restringido en energía que comprende medios para llevar a cabo un método de acuerdo con la invención. Este dispositivo es, por ejemplo, un Dispositivo de Energía no Contaminante ZigBee.
La invención también se refiere a un dispositivo intermediario que comprende medios para llevar a cabo un método de acuerdo con la invención. El dispositivo intermediario es, por ejemplo, un dispositivo Intermediario de Energía no Contaminante Zig-Bee o un dispositivo Combinado de Energía no Contaminante ZigBee.
Estos y otros aspectos de la invención serán evidentes y se aclararán con referencia a las realizaciones descritas en lo sucesivo.
Descripción detallada de la invención
La invención tiene lugar en una red de comunicación que comprende al menos dos dispositivos intermediarios, que operan en el canal operacional. Se ha de añadir a la red al menos un dispositivo de Energía no Contaminante ZigBee (ZGPD), que puede operar en cualquier canal a partir de un conjunto de canales. Esto requiere hallar el canal operacional.
Para este fin, el ZGPD transmite varios mensajes de baliza (“Baliza”), en diferentes canales de radio y escucha una respuesta a su mensaje de baliza (“respuesta de baliza”).
Dependiendo del tipo de dispositivo de ZGPD y las capacidades, puede haber diferentes maneras para hacer que el ZGPD envíe la trama de baliza. Puede haber medios especiales para poner el dispositivo en el modo de puesta en marcha, por ejemplo un botón especializado, deslizador, puente, etc. Puede requerirse una acción especial, tal como un orden particular de etapas. Puede haber una combinación particular de medios individualmente usables en el modo de operación, por ejemplo presionar simultáneamente un número de teclas de RC o combinación de contactos en un conmutador que no puede usarse durante operación (por ejemplo ambos contactos bajo el mismo balancín).
La acción puede posibilitar el modo de puesta en marcha o que se requiera para cada envío de la baliza.
La acción puede combinarse con recogida de energía (por ejemplo a partir de que el conmutador que recoge la energía se presione) o puede ser independiente (por ejemplo para un dispositivo con alimentación solar). Puede ser una etapa explícita (como presionar el botón de puesta en marcha) o una etapa implícita (por ejemplo cuando se alimenta en primer lugar un dispositivo alimentado por batería).
Pueden haber diferentes enfoques para espaciar en el tiempo entre las transmisiones de baliza. Por ejemplo puede ser fijo, aleatorio, configurable, estar influenciado por limitaciones de dispositivo (tal como el tiempo requerido para conmutación de canal o conmutar entre modos de transmisión y recepción), por acción del usuario, por temporizador, por otra función por la cantidad de energía recogida, etc.
A medida que se envían mensajes de baliza en difusión de MAC, múltiples intermediarios pueden enviar una respuesta de baliza. Puesto que es posible que estos intermediarios estén por debajo de rango de radio entre sí, sus mensajes de respuesta pueden colisionar en el ZGPD, de modo que el ZGPD no reciba de manera apropiada una respuesta de baliza. El problema es conocido en la técnica como el problema del nodo oculto. Sin embargo, las soluciones conocidas en la técnica para este problema no son fácilmente aplicables al dispositivo restringido en energía, puesto que puede no tener la energía para reintentar varias veces o recibir transmisión muy retardada. Un mecanismo para asegurar que únicamente un intermediario envíe una respuesta al dispositivo de recogida de energía, y por lo tanto que ese mensaje de respuesta de baliza se reciba de manera apropiada, es conocido en la norma de ZGP [1, Sec. 6.3 y A.3.6.2.3]. El tiempo para ejecutar este mecanismo, sin embargo, es probable que sea mucho más largo que el tiempo durante el cual el ZGPD pueda almacenar energía recogida, de modo que el ZGPD no puede recibir de manera fiable una respuesta a una baliza con la misma presión de botón usada para transmitir esa baliza.
Es por lo tanto el objeto de la invención proporcionar un método para que el ZGPD determine c_op, el canal de radio en el que está operando realmente el canal.
Para describir la invención de manera precisa, introducimos la siguiente notación. El ZGPD puede transmitir y recibir en un conjunto finito C de canales de radio. El canal de radio en el que está realmente operando la red, indicado por c_op, está contenido preferentemente en C.
5
10
15
20
25
30
35
40
45
50
55
60
65
El conjunto de canales C puede ser un conjunto completo de canales soportado por una tecnología y banda y región dadas. Por ejemplo para que el ZGPD opere en la banda de 2,4 GHz, C podría incluir todos los canales de IEEE802.15.4 11 - 25 (26). Esto proporciona interoperabilidad total con los dispositivos de recepción que implementan esta tecnología particular, pero puede aumentar la longitud y complejidad (dependiendo de cómo se active el envío de la baliza) del procedimiento de puesta en marcha. El conjunto de canales C puede contener también un subconjunto seleccionado de todos los canales disponibles. Por ejemplo, la especificación de ZGP recomienda usar los siguientes 4 canales: 11, 15, 20, 25; los últimos tres están entre los canales no solapantes usados por la norma 802.11 que opera en la misma banda de 2,4 GHz; el canal 11 es el canal por defecto en muchas implementaciones de plataforma. Adicionalmente, el ZGPD conoce dos funciones, succ y listen, ambas desde C a C, que ambas funciones aceptan entradas desde C y producen salidas en C. La función succ describe el orden en el que el ZGPD pasa a través de los canales para transmitir sus balizas. Después de enviar en el canal c, el ZGPD enviará en el canal succ(c) en la siguiente presión de botón, o más en general, en el siguiente intento para hallar el canal operacional. Para el número entero no negativo m, indicamos por succm la función succ aplicada m veces. Por lo que succ0(c) = c, y para m>1, succm(c) = succ(succm~ 1(c)).
La función succ, que describe el orden en el que el ZGPD pasa a través de los canales para transmitir sus balizas, puede ser cualquier función: incrementar en uno con/sin realizar envolvente alrededor, decrementar en uno con/sin realizar envolvente alrededor, seguido de una función incremental diferente, aleatoria, función no monotónica, conjunto ordenado recurrente o no recurrente, etc. Pueden ordenarse adicionalmente de manera que el canal desde C es probable que sea el canal operacional que se intentó en primer lugar. Por ejemplo, el conjunto de canales completo puede ordenarse de manera que empieza con el conjunto de canales recomendado/preferido o desde el canal operacional anterior (si lo hubiera).
Los tres parámetros - el conjunto C así como las funciones succ y listen - pueden predeterminarse en una especificación y por lo tanto ser conocidos para todos los dispositivos en la red. Podría haber una definición incluida en la especificación, no requiriendo por lo tanto que el ZGPD incluya esta información explícitamente en la baliza o podría haber varias alternativas definidas en la especificación, codificarse en una bandera o un campo de enumeración (uno de los tres parámetros) o un número de 2-3 banderas/campos de enumeración para combinaciones de parámetro o cada parámetro de manera individual. Esto debería incluirse preferentemente a continuación en la baliza (comunicarse de otra manera, por ejemplo por una información de producto, requiriendo potencialmente interacción de usuario diferente o modo de puesta en marcha en el lado de la red).
La determinación del comportamiento de conmutación de canal de ZGPD puede estar fuera del alcance de la especificación y dejarse a los implementadores. A continuación, todo/algo/partes de los parámetros deberían transmitirse explícitamente en la baliza. Por ejemplo, el ZGPD puede incluir en la baliza la lista completa de canales C, o los siguientes N canales, donde N puede ser 1. El ZGPD puede incluir la fórmula de función para succ y listen. Cualquier combinación de lo anterior también es posible.
De acuerdo con la invención, para cada instancia de este intento de determinación del canal operacional (posteriormente denominado como “intento”) el ZGPD usa la energía disponible (por ejemplo recogida durante una presión de botón en el caso de conmutador de botón de presión electro-mecánico o, por ejemplo, en caso de conmutador con alimentación solar que queda después del primer intento y se ha recogido desde entonces) para realizar las etapas que comprenden:
• enviar una baliza a la red en el canal de radio c
• recibir, en el canal de radio listen(c), una respuesta a la baliza enviada durante cualquier intento anterior, si se envía cualquier respuesta de baliza de este tipo
• calcular la función succ
• almacenar información de estado relacionada con succ
El orden de las operaciones y el número de operaciones particulares en cada etapa puede variar. Se describen algunos ejemplos en las realizaciones a continuación.
Todos los intermediarios operan en el canal operacional y por lo tanto no reciben baliza si c t c_op. Si c = c_op, uno o más intermediarios reciben la baliza, y se aplica un mecanismo para seleccionar un “maestro temporal” único que enviará una respuesta de baliza, preferentemente se usará el mecanismo de ZGP descrito (como se describe en [1], sec 6.3 y A.3.6.2.3), que implica que se empareje el dispositivo con el ZGPD (el denominado Sumidero de Energía no Contaminante ZigBee (ZGPS) establecido en modo de puesta en marcha) en el proceso de elegir el maestro temporal con la distancia más corta al ZGPD. Como alternativa, puede aplicarse cualquier otro protocolo/mecanismo que permite seleccionar un dispositivo (si es posible: teniendo en cuenta criterio adicional, como distancia/intensidad de señal) para un grupo de dispositivos, si el mecanismo está distribuido o centralizado.
Este maestro temporal es responsable de enviar la respuesta de baliza al dispositivo restringido en energía. No transmite la respuesta de baliza de manera inmediata. En su lugar, el maestro temporal conmuta su receptor de radio al canal succm(c_op) (donde m es un número entero positivo), en canal en el que el ZGPD enviará (una de) su siguiente baliza o balizas. Cuando el maestro temporal escucha esta siguiente baliza en el canal succm(c_op), transmite la respuesta de baliza en el canal listen(succm(c_op)); obsérvese que este es el canal que escucha el
5
10
15
20
25
30
35
40
45
50
55
60
65
ZGPD mientras envía en el canal succm(c_op). La respuesta de baliza puede pre-calcularse y capturarse desde la memoria intermedia en la recepción del mensaje de baliza o puede calcularse en la recepción del mensaje de baliza. Obsérvese que el maestro temporal no necesita conocer m: debe conocer el valor de función suchm (c_op), y tiene conocimiento de que recibe la siguiente baliza en el canal x, tiene que enviar la respuesta de baliza en el canal listen(x). Teniendo el valor m relaja la restricción sobre el mínimo tiempo entre dos presiones de botón sucesivas, pero también hace más largo el tiempo para completar el procedimiento. Para algunas realizaciones, el parámetro m debe tener un valor fijo (igual a 1 o mayor que 1), definido por especificación o que se define y comunica por dispositivo de recogida de energía o; en otras realizaciones, m puede variar (por ejemplo dependiendo de la carga de tráfico, la distancia (por ejemplo en recuentos de salto) entre el ZGPD y el dispositivo al que está emparejado, la densidad de intermediarios, etc.). Si m puede variar, entonces puede elegirse como parte del procedimiento de elección de maestro temporal (en caso de la especificación de ZGP: por el ZGPS en modo de puesta en marcha); o por el mismo maestro temporal. Deberá ser evidente para el intermediario de maestro temporal (o ZGPS, si se usa el procedimiento de elección de maestro temporal de ZGP y el canal se prescribe como parte de eso) cuándo tiene libertad de elegir m y cuándo está fijada. Eso puede manejarse por especificación o caso por caso.
Preferentemente, el tiempo entre dos presiones de botón sucesivas es suficientemente largo para permitir la selección del maestro temporal, es decir m=1. Dependiendo del tipo de dispositivo, podría influenciarse estableciendo el parámetro interno del ZGPD y/u ordenando que el usuario adapte el intervalo de tiempo entre la acción de usuario (por ejemplo en el caso de conmutador de botón de presión electro-mecánico de recogida de energía).
En una primera y segunda realización, succ y listen son de manera que listen(succd(c))=c para toda c en C, mediante lo cual d es un número entero no negativo.
Para cada intento, el ZGPD por lo tanto transmite y recibe en diferentes canales de radio, a saber, canales de radio c y listen(c), respectivamente, mediante lo cual el canal que escucha es el canal que transmitió en el intento anterior. También, el maestro temporal envía en un canal de radio (a saber listen(succd(c_op))) que es diferente de en el que recibió el activador para enviar la respuesta (canal succd(c_op).
En la primera realización, el valor de m se fija por lo tanto a m=d, por el ZGPD o por especificación. La ventaja de esta realización es que el ZGPD recibe la respuesta de baliza en el canal operacional c_op y por lo tanto ya no necesita conmutar más entre canales, o puede informarse explícitamente acerca del valor de c_op. Si el dispositivo almacena el canal que escucha en cada intento dado, es igual al c_op, por lo que ya no necesita almacenarse más. Si el dispositivo almacena el canal en el que envía, puede calcular el c_op como una inversa de la función succ(c) y debe almacenarla. El valor de succm(c_op) debe conocerse para el maestro temporal, ya sea por la presencia del valor de succm(c) en la baliza enviada en el canal c, o por conocimiento de la función succ(c) en una especificación y conocimiento de m, o por conocimiento de la función succ(c) y la función listen(c), ya sea en una especificación o esté presente en la baliza. El maestro temporal también debe conocer que debe enviar en c_op, ya sea puesto que esto se prescribe en la especificación, o por conocimiento de la función listen, ya sea desde la especificación o de la presencia en la baliza.
En la segunda realización, el valor m puede variar. El maestro temporal por lo tanto escucha en cualquier canal succm(c_op) y tras recibir la baliza envía en el canal de radio listen(succm(c_op). A continuación, el canal operacional debe transmitirse en la respuesta de baliza y almacenarse por el ZGPD.
En una tercera, cuarta y quinta realización, listen(c) = c para toda c en C. En este caso, con la energía recogida desde una presión de botón, el ZGPD por lo tanto transmite y recibe en el mismo canal de radio, y el maestro temporal transmite en el canal en el que ha recibido el activador para enviar la respuesta de baliza (en concreto el canal succm(c_op)).
En la tercera realización, el valor de m está fijado, por el ZGPD o por especificación. El código de ZGPD para manejar los intentos es de manera que el ZGPD almacena el valor c del canal en el que se transmite el ZGPD en los m intentos anteriores (y no el valor a usarse en el intento actual succm(c). Por lo tanto, el ZGPD tiene los valores de c_op, succ(c_op), ...,succm-1(c_op) disponibles cuando recibe la respuesta de baliza y por lo tanto no necesitan almacenarse de nuevo o ser informados explícitamente acerca del valor de c_op. (El más antiguo de los m valores almacenados es el valor para tomar para c_op). Como alternativa, el maestro temporal aplica la inversa de la función sucesor m veces al canal en el que recibe la baliza.
En la cuarta realización, el ZGPD únicamente almacena el valor del valor actual de c, y el maestro temporal transmite la respuesta de baliza cada vez que el ZGPD transmite la baliza en c_op de nuevo.
En la quinta realización, el valor de m puede variar. En esta realización, el valor de c_op está incluido en el mensaje de respuesta de baliza. El ZGPD por lo tanto no necesita almacenar los m valores como en la segunda realización; incluso no necesita conocer el valor de m. Todo lo que se requiere es que el maestro temporal, después de recibir una segunda baliza, es decir en el canal x, transmita su respuesta de baliza en el canal listen(x).(= x en este caso).
En una sexta y séptima realización, el ZGPD siempre escucha en el mismo canal, es decir, listen(c) = k para toda c en C y alguna k fijada en C. El valor de k puede ser conocido ya que está fijado en una especificación, o puede incluirse en la baliza.
En la sexta realización el valor de m está fijado, por el ZGPD o por especificación. El ZGPD obtiene el valor de c_op desde su memoria (similar a la tercera realización).
En la séptima realización, el valor de m puede variar. En esta realización, el valor de c_op está incluido en el mensaje de respuesta de baliza, y por lo tanto no necesita recordarse por el ZGPD. Obsérvese que en la séptima realización, el ZGPD no necesita conocer el valor de m; todo lo que se requiere, es que el maestro temporal,
5
10
15
20
25
30
35
40
45
50
55
60
65
después de recibir una baliza, es decir en el canal x, transmita su respuesta de baliza en el canal listen(x) (=k en este caso)
Tras un intento satisfactorio, el ZGPD ya no deberá pasar más a través de los canales.
Podría implementarse, por ejemplo, tener una variable de estado que controla este comportamiento de etapa de canal. Puede ser, por ejemplo, un valor Booleano paso a canal (VERDADERO/FALSO), establecido cuando entra en el modo operacional y que se limpia en la recepción de la respuesta de baliza.
Después de eso, puede seguir un intercambio de puesta en marcha real. Como alternativa, todos los parámetros de configuración requeridos podrían entregarse al ZGPD en la respuesta de baliza.
En la 2a alternativa, los datos de configuración están incluidos en la respuesta de baliza, también - para permitir algunas comprobaciones iniciales en el lado de la red - alguna información acerca del ZGPD necesita incluirse en la baliza (por ejemplo, dispositivo único identificado (en ZGPD: SrcID), tipo de dispositivo (en ZGP: DeviceID), capacidades de seguridad, clave de seguridad, parámetros solicitados); mientras que en el caso del intercambio de puesta en marcha real, se requiere una etapa adicional para intercambiar datos de configuración (solicitud y/o recepción).
El 1er método tiene varias ventajas también, que lo hace la opción preferida: en primer lugar, con la 2a alternativa, el parámetro de configuración enviado por el ZGPD (que puede incluir sus credenciales de seguridad) se transmite en varios canales (en la etapa 1), aumentando enormemente por lo tanto la probabilidad de que se vean comprometidos;
en segundo lugar, los mensajes de baliza y de respuesta de baliza pueden ser mucho más cortos cuando se usa intercambio de puesta en marcha especializado después de hallar el canal operacional - que puede permitir el envío de múltiples mensajes de baliza con una presión de botón. A la inversa, con ciertos ZGPD, la cantidad de energía recogida puede ser también demasiado pequeña para enviar una baliza larga y recibir una respuesta de baliza larga.
El intercambio de puesta en marcha puede realizarse en el canal en el que el maestro temporal envía satisfactoriamente la respuesta de baliza (es decir, el canal listen( succm(c_op).) Preferentemente sin embargo, el intercambio de puesta en marcha tendrá lugar en el canal de operación real, para limitar el tiempo en el que el intermediario maestro temporal no está presente en el canal operacional (la ausencia prolongada de un dispositivo en el operacional puede forzar a que su ZED secundario busque un nuevo principal y que su encaminador vecino descarte las rutas que van mediante este dispositivo).
El intercambio de puesta en marcha - en caso de un dispositivo que requiere acción de usuario para cada acción del ZGPD (tal como conmutador de botón de presión electro-magnético de recogida de energía) - puede ser una acción diferente que para activar los intentos. Preferentemente, sin embargo, es la misma acción.
Una vez que se finalizan todos los intercambios relacionados con puesta en marcha, preferentemente se proporciona realimentación con éxito al usuario y el ZGPD puede entrar en el modo operacional (dispositivo específico, véase anteriormente la descripción de entrar en el modo de puesta en marcha).
Extensiones
Para aumentar la robustez en el proceso de unión en casos de problemas de propagación o interferencia. Pueden haber varios dispositivos intermediarios candidatos alrededor del ZGPD, puede designarse un número N>1 de intermediarios “maestros temporales”, cada uno en un canal diferente c_k, seleccionarse desde el conjunto de canales soportados por el ZGPD, C. Si el maestro temporal k (1<k <N) escucha una baliza en el canal c_k, envía una respuesta de baliza en el canal listen(c_k). Preferentemente, se seleccionan los canales c_1,...,c_n de manera que el ZGPD transmite en ellos pronto después de que los intermediarios reciben la (primera) baliza. Si la función succ es conocida, una elección preferida para el canal c_j es succi+s (c_op), donde s es un número entero fijado, por ejemplo s=0, y j=1,2,...,N (obsérvese que la baliza se recibió en c_op). El valor de c_op está incluido en la respuesta de baliza, es decir pueden usarse las realizaciones 2, 5 y 7. Para aplicación de la realización 7, se requiere que dos maestros no envíen simultáneamente, que es seguramente el caso de si cada maestro escucha en un canal diferente el ZGPD no transmite en diferentes canales c_i y c_j (con 1 < i < N, 1 < j < N) antes del mismo intento de escucha.
Debería quedar claro para cada uno de los múltiples maestros temporales que no pueden elegir el canal para escuchar libremente.
Obsérvese que algunos de los intermediarios maestros temporales señalados pueden ya no recibir ninguna baliza más. Deberían poder salir del modo de puesta en marcha, por ejemplo después de un tiempo de espera agotado, como es conocido en la técnica.
• El ZGPD puede recoger suficiente energía para enviar múltiples mensajes de baliza durante un intento. El mismo método anterior puede aplicarse, con modificaciones menores, como se describe en las siguientes realizaciones ejemplares:
5
10
15
20
25
30
35
40
45
50
55
60
65
o Para cada intento, el ZGPD realiza múltiples veces la secuencia de acciones: enviar en un canal c, conmutar a un modo de recepción, recibir en listen(c); en caso de que no se reciba respuesta de baliza: y repetir la secuencia. En algún lugar durante la secuencia, se determinará el siguiente canal en el que transmitir mediante succ(c) y alguna información de estado correspondiente almacenada; que puede hacerse antes de enviar, después de enviar, antes de entrar en modo de recepción, al determinar fallo de recepción (por ejemplo tiempo de espera agotado de recepción) o en cualquier otro momento, como será evidente para los expertos en la materia.
o Cuántas veces se realiza la secuencia puede variar. Por ejemplo, puede fijarse, por producto, tipo de dispositivo o especificación de ZGP, puede ser muy dependiente de la cantidad de energía disponible (recogida) o dependiente del tipo de interacción de usuario.
o Para cada intento, el ZGPD transmite en primer lugar la baliza en N canales, y a continuación escucha. Por lo tanto, para todos los canales transmitidos en cada intento particular, listen(c) tiene el mismo valor. Esto puede indicarse en la baliza o estar predefinido, como se ha descrito anteriormente.
En este caso, el maestro temporal puede escuchar una siguiente baliza en cualquiera de los canales en el siguiente intento (suponiendo m=1). Una elección sería que el maestro temporal escuche el canal final en el que la transmisión tiene lugar en el siguiente intento. Este canal puede incluirse en la baliza, o derivarse (mediante una versión modificada de la función succ conocida en la especificación) desde el canal c_op en el que se recibió la baliza.
Procedimiento de puesta en marcha completo ejemplar
Anteriormente, describimos un método para permitir que el ZGPD halle el canal operacional de la red de ZigBee, una etapa esencial en la puesta en marcha del ZGPD. A continuación, describimos dos maneras ejemplares de puesta en marcha usando el método anterior dentro del alcance de la especificación de ZGP [1], para el ZGPD y ZGPP y ZGPS como se define en ZG.
1er método de puesta en marcha: balizas cortas
1. ZGPS (el dispositivo a controlarse y emparejarse al ZGPD) se pone en modo de puesta en marcha por acción de usuario. Permanece en el canal operacional.
2. El ZGPS anuncia el modo de puesta en marcha a todos los dispositivos aptos para ZGP en la red de ZigBee. Entran en modo de puesta en marcha en el canal operacional.
3. El ZGPD envía una baliza corta, posiblemente incluso no llevando un identificador del ZGPD, aunque posiblemente conteniendo la información con respecto a su comportamiento de paso a canal futuro (si no se prescribe de manera única por la especificación de ZGP), en un canal c, y a continuación escucha en un canal listen(c).
4. El ZGPD transmite mensajes de baliza posteriores hasta que se recibe respuesta de baliza, cada baliza i en el canal succ'(c) y escucha en un canal listen(succ'(c)).
5. El intermediario informa la recepción en el canal operacional de la baliza (y sus contenidos) al ZGPS.
6. El ZGPS comprueba si está en modo de puesta en marcha y, en caso afirmativo, designa el maestro o maestros temporales para manejar la comunicación para este ZGPD durante la puesta en marcha (si hay varios, también indica en qué canal deberá transmitir qué intermediario).
7. El maestro o maestros temporales designados activan su receptor en (a) canal o canales seleccionados c en los que el ZGPD enviará en el futuro. (Si hay varios: como se indica por el ZGPS; si hay uno: si no se indica por el ZGPD y no se define por el perfil/ZGPD/método, entonces puede elegirse por el mismo maestro).
8. Un maestro temporal designado recibe la baliza en el canal c y envía la respuesta de baliza, que indica la recepción de la baliza, y opcionalmente (realizaciones 2, 5 y 7) que incluye el canal operacional c_op.
9. El ZGPD recibe la solicitud de baliza, opc., almacena el canal operacional y almacena la información de estado, que se ha hallado el canal operacional (En la figura, la función booleana paso a canal=FALSO).
10. El ZGPD y el maestro temporal vuelven al canal operacional (si c != c_op).
11. El ZGPD y el ZGPS intercambian (mediante (uno de) el maestro o maestros temporales los datos de configuración.
12. La puesta en marcha tiene éxito, ZGPS y ZGPP pueden salir del modo de puesta en marcha.
2° método de puesta en marcha, balizas largas.
1. ZGPS (el dispositivo a controlarse y emparejarse al ZGPD) se pone en modo de puesta en marcha por acción de usuario. Permanece en el canal operacional.
2. El ZGPS anuncia el modo de puesta en marcha a todos los dispositivos aptos para ZGP en la red de ZigBee. Entran en el modo de puesta en marcha en el canal operacional.
3. El ZGPD envía una baliza larga, que incluye el tipo de dispositivo (ZGPD DeviceID), nivel de seguridad soportado y otras capacidades de dispositivo, su identificador (ZGPD SrclD), opc., clave de seguridad, y opc., contador de trama de seguridad, y la información con respecto a su comportamiento de paso a canal futuro (si no se prescribe de manera única por la especificación de ZGP), en un canal c, y a continuación escucha en un canal listen(c).
10
15
4. El ZGPD transmite mensajes de baliza posteriores hasta que se recibe respuesta de baliza, cada baliza i en el canal succ'(c) y escucha en un canal listen(succi(c)).
5. El intermediario informa la recepción en el canal operacional de la baliza (y sus contenidos) al ZGPS.
6. El ZGPS comprueba si está en modo de puesta en marcha. En caso afirmativo, el ZGPS realiza funcionalidad, adaptación de nivel de seguridad, etc. Si todos los requisitos coinciden, el ZGPS designa el maestro o maestros temporales para entregar los parámetros de configuración requeridos al ZGPD.
7. El maestro o maestros temporales escuchan en un canal o canales (uno diferente) c, en el que el ZGPD enviará en el futuro.
8. Tras la recepción de la baliza en el canal c, el maestro temporal envía respuesta de baliza en el canal listen(c), que indica la recepción de la baliza, y que contiene los datos de configuración (si se requieren/solicitan) y opcionalmente (realizaciones 2, 5 y 7) el canal operacional.
9. El ZGPD recibe la solicitud de baliza, opc., almacena el canal operacional, almacena la información de estado, que el canal operacional ha hallado (en la figura, la función booleana pasar a canal=FALSO), y almacena los parámetros de configuración suministrados si los hubiera.
10. Éxito de puesta en marcha, el ZGPS y ZGPP pueden salir del modo de puesta en marcha.

Claims (15)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    REIVINDICACIONES
    1. Método para determinar un canal de radio operacional de un conjunto C de canales de radio, de una red de comunicación, comprendiendo dicha red de comunicación al menos dos intermediarios potenciales (ZGPP1, ZGPP2) para que un dispositivo restringido en energía (ZGPD) se una a la red, estando dichos al menos dos intermediarios potenciales en modo de puesta en marcha, comprendiendo el método las siguientes etapas:
    - el dispositivo restringido en energía (ZGPD) intenta unirse a la red, en el que para cada intento i,
    - el dispositivo restringido en energía (ZGPD) transmite en difusión de MAC un mensaje de baliza (Baliza GPDF) en un canal c¡ del conjunto C, y conmuta a modo de recepción en el canal listen(cl), en el que listen es una función aritmética, de C a C,
    - en el que el siguiente canal en el que el dispositivo restringido en energía transmitirá el siguiente mensaje de baliza para el siguiente intento i+1 es c¡+i=succ(c¡), en el que succ es la función aritmética, de C a C;
    - al menos uno de los intermediarios (ZGPP1, ZGPP2) recibe un primer mensaje de baliza (Baliza GPDF) enviado en el canal de radio operacional c_op,
    - aplicar un mecanismo para determinar un dispositivo maestro temporal (ZGPP1) entre los al menos dos intermediarios potenciales,
    - el dispositivo maestro temporal (ZGPP1) conmuta su receptor de radio al canal succm(c_op), siendo m un número entero positivo distinto de cero, en el que succm indica que la función succ se aplica m veces, de manera que succm(c) = succ(succm1(c)),
    - el dispositivo restringido en energía (ZGPD) transmite un mensaje de baliza adicional en el canal de radio succm(c_op) y conmuta al modo de recepción en el canal listen(succm(c_op)),
    - tras la recepción del mensaje de baliza adicional, el dispositivo maestro temporal transmite una respuesta (Baliza Rsp GPDF) en un canal listen( succm(c_op)),
    - el dispositivo restringido en energía (ZGPD) recibe la respuesta de baliza en un canal listen(succm(c_op)), determinando que c_op es el canal operacional.
  2. 2. Método de acuerdo con la reivindicación 1, en el que m equivale a 1.
  3. 3. Método de acuerdo con la reivindicación 1 o 2, en el que las funciones listen y succ son de manera que existe un número entero d de manera que listen(succd(c)) = c.
  4. 4. Método de acuerdo con la reivindicación 3, en el que el parámetro m está fijado a m=d de modo que el dispositivo restringido en energía (ZGPD) recibe la respuesta de baliza (Baliza Rsp GPDF) en el canal operacional.
  5. 5. Método de acuerdo con las reivindicaciones 1-4, en el que la función listen es de manera que listen(c) = c, de modo que el dispositivo restringido en energía (ZGPD) no necesita conmutar a un canal de radio diferente para recibir señales.
  6. 6. Método de acuerdo con la reivindicación 1, en el que la función listen es una función constante, de modo que el dispositivo restringido en energía (ZGPD) siempre escucha al mismo canal.
  7. 7. Método de acuerdo con una de las reivindicaciones anteriores, en el que la función succ está comprendida en el grupo que comprende: incrementar en uno y realizar envolvente en C, decrementar en uno y voltear en C, un conjunto ordenado recurrente, cualquier otra función que comprende una característica de incremento o decremento en C, incrementar en parte de C y decrementar en otra parte de C, y una función no monotónica.
  8. 8. Método de acuerdo con una de las reivindicaciones anteriores, en el que las funciones succ y/o listen son conocidas tanto por el dispositivo restringido en energía (ZGPD) como los intermediarios (ZGPP1, ZGPP2).
  9. 9. Método de acuerdo con cualquiera de las reivindicaciones 1 a 5, en el que la función succ y/o listen no son conocidas por los intermediarios (ZGPP1, ZGPP2), y en el que el mensaje de baliza (Baliza GPDF) transmitido por el dispositivo restringido en energía (ZGPD) comprende información que permite que los intermediarios (ZGPP1, ZGPP2) determinen las funciones pertinentes de succ y listen.
  10. 10. Método de acuerdo con cualquiera de las reivindicaciones anteriores, en el que el parámetro m está fijado por especificación o en la producción del dispositivo restringido en energía.
  11. 11. Método de acuerdo con cualquiera de las reivindicaciones anteriores, en el que el parámetro m puede elegirse, teniendo en cuenta fenómenos de interconexión en red que comprenden: carga de tráfico en el medio, carga de tráfico en el dispositivo, distancia en recuento de saltos, velocidad de procesamiento en el dispositivo.
    5
    10
    15
    20
    25
  12. 12. Método de acuerdo con cualquiera de las reivindicaciones anteriores, en el que se designan N dispositivos maestros temporales adecuados durante la etapa de determinación, en el que N es un número entero mayor que 1 y cada uno de los dispositivos maestros temporales adecuados escucha en un canal diferente respectivo.
  13. 13. Dispositivo restringido en energía que comprende medios para llevar a cabo un método de acuerdo con una de las reivindicaciones anteriores.
  14. 14. Dispositivo restringido en energía de acuerdo con la reivindicación 13, en el que el dispositivo restringido en energía (ZGPD) es un Dispositivo de Energía no Contaminante ZigBee.
  15. 15. Un dispositivo intermediario (ZGPP1) adaptado para operar en un canal de radio operacional c_op de un conjunto C de canales de radio en una red de comunicación, comprendiendo dicha red al menos un nodo intermediario (ZGPP2) para que un dispositivo restringido en energía (ZGPD) se una a la red, siendo el dispositivo intermediario (ZGPP1) y el al menos un nodo intermediario (ZGPP2) parte de al menos dos intermediarios potenciales,
    - el dispositivo intermediario (ZGPP1) comprende un receptor de radio para recibir un mensaje de baliza (Baliza GPDF) desde el dispositivo restringido en energía enviado en el canal c_op,
    - el dispositivo intermediario (ZGPP1) comprende medios para aplicar un mecanismo para determinar un dispositivo maestro temporal entre los al menos dos intermediarios potenciales tras la recepción de dicho mensaje de baliza y si el dispositivo intermediario está en modo de puesta en marcha; y
    - el dispositivo intermediario (ZGPP1) comprende medios para conmutar dicho receptor de radio al canal succm(c_op), en caso de que el dispositivo intermediario (ZGPP1) se seleccione como el dispositivo maestro temporal, siendo m un número entero positivo, en el que succm indica que la función succ se aplica m veces de manera que succ(succm-1(c))=succm(c), y el dispositivo intermediario está adaptado, después de que el receptor recibe el mensaje de baliza adicional en succm(c_op), para transmitir una respuesta (Baliza Rsp GPDF) en un canal listen(succm(c_op)) caso en el que el dispositivo intermediario se selecciona como el dispositivo maestro temporal.
ES11799316.2T 2010-11-26 2011-11-15 Método para determinar un canal operacional en una red de comunicación, dispositivo restringido en energía y dispositivo intermediario Active ES2668216T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP10192817 2010-11-26
EP10192817 2010-11-26
PCT/IB2011/055078 WO2012069956A1 (en) 2010-11-26 2011-11-15 Method for determining an operational channel in a communication network, energy -restricted device and proxy device

Publications (1)

Publication Number Publication Date
ES2668216T3 true ES2668216T3 (es) 2018-05-17

Family

ID=45375459

Family Applications (1)

Application Number Title Priority Date Filing Date
ES11799316.2T Active ES2668216T3 (es) 2010-11-26 2011-11-15 Método para determinar un canal operacional en una red de comunicación, dispositivo restringido en energía y dispositivo intermediario

Country Status (8)

Country Link
US (1) US9357485B2 (es)
EP (1) EP2644001B1 (es)
JP (2) JP5985497B2 (es)
CN (1) CN103222333B (es)
BR (1) BR112013012680A8 (es)
ES (1) ES2668216T3 (es)
RU (1) RU2582056C2 (es)
WO (1) WO2012069956A1 (es)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9736817B2 (en) 2012-06-19 2017-08-15 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for D2D discovery
WO2014030103A2 (en) 2012-08-22 2014-02-27 Koninklijke Philips N.V. Network discovery with touchlink option
EP2896263B1 (en) * 2012-09-17 2018-04-04 Telefonaktiebolaget LM Ericsson (publ) Method and arrangement for handling d2d communication
EP2898734A1 (en) 2012-09-18 2015-07-29 Telefonaktiebolaget L M Ericsson (Publ) A user equipment, a network node, and methods for device discovery in device-to-device (d2d) communications in a wireless telecommunications network
US9055611B2 (en) * 2012-12-21 2015-06-09 Broadcom Corporation Resilient peer network with 802.11 technology
JP6560693B2 (ja) * 2014-06-13 2019-08-14 シグニファイ ホールディング ビー ヴィ ＺｉｇＢｅｅ（登録商標） ＧＲＥＥＮ ＰＯＷＥＲデバイスの送信モード選択
CN106797331A (zh) * 2014-07-08 2017-05-31 飞利浦灯具控股公司 用于调试网络节点的方法
US9942628B2 (en) * 2014-12-31 2018-04-10 Honeywell International Inc. Wearable technology based apparatus and method for accelerated enrollment of parallel wireless sensors into their own network
FR3040573B1 (fr) * 2015-08-31 2018-10-19 Kerlink Architecture de station de base modulable pour reseau de capteurs sans-fil.
US10637684B2 (en) * 2015-10-27 2020-04-28 Signify Holding B.V. Mesh network connectivity
DE102018207659A1 (de) * 2018-05-16 2019-11-21 Bayerische Motoren Werke Aktiengesellschaft Master-Slave-System
WO2020002249A1 (en) * 2018-06-27 2020-01-02 Signify Holding B.V. Bi-directional commissioning for low-power wireless network devices
CN114422485B (zh) * 2022-01-27 2023-11-24 上海顺舟智能科技股份有限公司 一种Zigbee无线智能设备的固件更新方法及装置

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08163133A (ja) * 1994-11-29 1996-06-21 Canon Inc デジタル無線通信システム
US5978366A (en) * 1996-12-20 1999-11-02 Ericsson Inc. Methods and systems for reduced power operation of cellular mobile terminals
GB0114965D0 (en) * 2001-06-19 2001-08-08 Nokia Corp Radio resource management
JP2002368654A (ja) * 2001-06-11 2002-12-20 Sony Corp データ通信装置およびデータ通信システム
US7342896B2 (en) * 2003-03-03 2008-03-11 Sharp Laboratories Of America, Inc. Centralized network organization and topology discover in Ad-Hoc network with central controller
JP4285138B2 (ja) * 2003-07-24 2009-06-24 ソニー株式会社 無線通信システム、無線通信装置及び無線通信方法、並びにコンピュータ・プログラム
JP3848315B2 (ja) * 2003-10-24 2006-11-22 キヤノン株式会社 印刷処理方法、印刷処理装置および記録媒体
US8549646B2 (en) * 2005-10-20 2013-10-01 The Trustees Of Columbia University In The City Of New York Methods, media and systems for responding to a denial of service attack
CN100553254C (zh) * 2006-01-25 2009-10-21 北京六合万通微电子技术股份有限公司 无线互联中设备自动发现的方法
US20080195426A1 (en) * 2006-03-17 2008-08-14 Moore Barrett H Subscription-Based Mobile Shelter Method
CN101141413A (zh) * 2006-09-06 2008-03-12 同济大学 一种公交信息采集和信息传输的方法及其实现系统
US20080151856A1 (en) * 2006-12-21 2008-06-26 Motorola, Inc. Method and apparatus for cognitive radio policy change
TWI468047B (zh) * 2008-04-25 2015-01-01 Koninkl Philips Electronics Nv 多頻道無線網路之媒介存取控制協定
JP5277438B2 (ja) * 2008-11-10 2013-08-28 双葉電子工業株式会社 無線メッシュネットワークシステムおよびその制御方法ならびに無線装置
EP2396932B1 (en) * 2009-02-13 2012-05-30 Koninklijke Philips Electronics N.V. Method for communicating in a network comprising a batteryless zigbee device, network and device therefor

Also Published As

Publication number Publication date
EP2644001A1 (en) 2013-10-02
EP2644001B1 (en) 2018-03-21
JP2016197916A (ja) 2016-11-24
US9357485B2 (en) 2016-05-31
US20130242840A1 (en) 2013-09-19
CN103222333B (zh) 2017-04-05
RU2582056C2 (ru) 2016-04-20
JP2014504070A (ja) 2014-02-13
BR112013012680A8 (pt) 2017-07-11
JP5985497B2 (ja) 2016-09-06
BR112013012680A2 (pt) 2016-09-06
CN103222333A (zh) 2013-07-24
RU2013128969A (ru) 2015-01-10
WO2012069956A1 (en) 2012-05-31
JP6165304B2 (ja) 2017-07-19

Similar Documents

Publication Publication Date Title
ES2668216T3 (es) Método para determinar un canal operacional en una red de comunicación, dispositivo restringido en energía y dispositivo intermediario
ES2248382T3 (es) Sistema de comunicacion.
US8254290B2 (en) Method and apparatus for constructing synchronous sensor network
KR20050065389A (ko) 무선 통신 시스템, 무선 노드, 무선 통신 시스템의 구축방법 및 노드의 위치 측정 방법
Chang et al. Constructive interference in 802.15. 4: A tutorial
CN107409271A (zh) 基于周期性信标信号在无线传感器网络内提供通信的系统和方法
KR20090077569A (ko) 무선 센서 네트워크의 통신 단말기 및 그의 통신 방법
CA2635659A1 (en) Initialization of a wireless communication network
Hortelano et al. Reducing the energy consumption of the friendship mechanism in Bluetooth mesh
Ng et al. A novel overlay mesh with bluetooth low energy network
Woon et al. Performance evaluation of IEEE 802.15. 4 wireless multi-hop networks: simulation and testbed approach
Giovanelli et al. Dynamic group management with bluetooth low energy
Han et al. Extending bluetooth LE protocol for mutual discovery in massive and dynamic encounters
KR20070106097A (ko) 비콘 방식 무선통신 시스템에서의 저전력 통신 방법
Cohen et al. Secured data gathering protocol for IoT networks
Wang et al. A study on the cricket location-support system communication protocols
ES2806074T3 (es) Comunicación multicanal, multimodulación y multifrecuencia con un transceptor de radio
Nuvolone Stability analysis of the delays of the routing protocol over low power and lossy networks
GOLIN Implementation and evaluation of a Bluetooth low energy indoor navigation system with a passive scanning approach
Dian IoT Use Cases and Technologies
JP5969778B2 (ja) ネットワークシステム、ノード装置及び対応接続関係の特定方法
Kam et al. ConverSS: A hybrid MAC/routing solution for small-scale, convergecast wireless networks
CN117242747A (zh) 用于网络通信的时间划分物理层接入
Mobashir Dependable Low-Power Wireless Sensor Networks
Harms Long-Term Stable Communication in Centrally Scheduled Low-Power Wireless Networks