ES2428356T3 - Protocolo de establecimiento y gestión de red - Google Patents

Protocolo de establecimiento y gestión de red Download PDF

Info

Publication number
ES2428356T3
ES2428356T3 ES03784356T ES03784356T ES2428356T3 ES 2428356 T3 ES2428356 T3 ES 2428356T3 ES 03784356 T ES03784356 T ES 03784356T ES 03784356 T ES03784356 T ES 03784356T ES 2428356 T3 ES2428356 T3 ES 2428356T3
Authority
ES
Spain
Prior art keywords
type
description
message
devices
extended
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.)
Expired - Lifetime
Application number
ES03784356T
Other languages
English (en)
Inventor
Robin A. Blackwell
Neil A. Hankin
Peter J. Lanigan
Nicoll B. Shepherd
Philip A. Rudland
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.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips NV
Koninklijke Philips Electronics NV
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
Priority claimed from GBGB0218174.1A external-priority patent/GB0218174D0/en
Application filed by Koninklijke Philips NV, Koninklijke Philips Electronics NV filed Critical Koninklijke Philips NV
Application granted granted Critical
Publication of ES2428356T3 publication Critical patent/ES2428356T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/143—Markup, e.g. Standard Generalized Markup Language [SGML] or Document Type Definition [DTD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • G06F40/146—Coding or compression of tree-structured data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Artificial Intelligence (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Selective Calling Equipment (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

Método de funcionamiento de un dispositivo de red en una red que tiene al menos otro dispositivo, incluyendo el método: enviar (104) un mensaje de consulta de descripción de dispositivo sencilla a al menos otro dispositivo solicitando una descripción de dispositivo sencilla; y recibir (106) desde el otro dispositivo un mensaje de descripción de dispositivo sencilla de longitud definida que incluye un valor de tipo de dispositivo que representa el tipo del otro dispositivo y un campo que indica si está disponible una descripción de dispositivo extendida; estando el método caracterizado por: someter a prueba el mensaje de descripción de dispositivo sencilla para determinar si está disponible una descripción de dispositivo extendida; enviar (108) un mensaje de consulta de descripción de dispositivo extendida al otro dispositivo solicitando una descripción de dispositivo extendida al otro dispositivo; y recibir (110) desde el otro dispositivo una descripción de dispositivo extendida de longitud variable si está disponible la descripción de dispositivo extendida.

Description

Protocolo de establecimiento y gestión de red
Esta invención se refiere a un protocolo de red, y en particular a implementaciones del protocolo.
Un protocolo de la técnica anterior para gestión de red es un plug and play universal (UPnP), que es muy útil para aplicaciones de Internet en las que el ancho de banda, el consumo de batería y, hasta cierto punto, el coste, no son un problema. Existen implementaciones del protocolo en electrónica de consumo (CE), tal como por ejemplo se dan a conocer en la solicitud de patente estadounidense n.º US 2002/029256 A1, pero debido a la extensión del protocolo, tales implementaciones imponen una carga pesada especialmente en los dispositivos más sencillos, que de lo contrario requerirían sólo una capacidad de procesamiento mínima.
La solicitud de patente PCT n.º WO99/57837 A2 da a conocer un método y un sistema para realizar un servicio en una red doméstica.
Por tanto, existe la necesidad de un protocolo adecuado para su incorporación en dispositivos sencillos tales como luces, termostatos y equipo de CE (mando a distancia para TV, DVD y PVR), que sea sencillo y económico de implementar, requiera el mínimo de ancho de banda, pero que sea escalable en una variedad de dispositivos con capacidades variables.
Esta necesidad no se limita a una aplicación inalámbrica, sino que se extiende a aplicaciones por cable.
Según un primer aspecto de la invención se proporciona un sistema, que comprende: una pluralidad de dispositivos de red que tienen cada uno un transceptor para enviar y recibir mensajes de red; al menos un dispositivo de red dispuesto para enviar un mensaje de consulta de dispositivo sencilla a otros dispositivos y para recibir e interpretar mensajes de descripción de dispositivo sencilla recibidos posteriormente desde los otros dispositivos; al menos un dispositivo de red dispuesto para enviar un mensaje de consulta de dispositivo extendida a otros dispositivos y para recibir e interpretar mensajes de descripción de dispositivo extendida recibidos posteriormente desde los otros dispositivos; estando cada uno de los dispositivos de red dispuesto para responder a un mensaje de consulta de dispositivo sencilla entrante desde otro de los dispositivos enviando un mensaje de descripción de dispositivo sencilla de longitud definida que incluye un valor de tipo de dispositivo que representa el tipo del dispositivo; y al menos uno de los dispositivos de red está dispuesto para responder a un mensaje de consulta de dispositivo extendida entrante desde otro de los dispositivos enviando un mensaje de descripción de dispositivo extendida.
Un sistema de este tipo implementa el protocolo que es el objeto de esta solicitud de patente. El protocolo en sí se denominará lenguaje de control uniforme doméstico (HUCL).
En comparación, los sistemas de la técnica anterior de los que los inventores tienen conocimiento implementan sólo un único mensaje y respuesta de descripción de dispositivo. Proporcionando una descripción de dispositivo sencilla de longitud definida y una descripción de dispositivo extendida de longitud variable, la invención hace posible combinar, usando el protocolo HUCL, dispositivos sencillos de que funcionan sólo usando los mensajes sencillos y dispositivos complejos que hacen uso de la mayor funcionalidad disponible a partir de la descripción de dispositivo extendida de longitud variable. Los dispositivos sencillos pueden ignorar simplemente consultas de descripción de dispositivo extendida.
La descripción de dispositivo sencilla incluye un número pequeño o moderado de campos predeterminados, teniendo cada campo una longitud fija. En general se usarán los mismos campos para cada mensaje, aunque puede haber alguna variación. Por ejemplo, un dispositivo compuesto puede incluir un campo de número entero adicional que incluye el número de subdispositivos, tal como se explica más adelante.
Preferiblemente, el mensaje de descripción de dispositivo sencilla es en forma de mensaje comprimido en testigo, comprimido a partir de un formato de mensaje legible por humanos, incluyendo el mensaje un valor de tipo de dispositivo que representa el tipo del otro dispositivo; seleccionándose el valor de tipo de dispositivo a partir de una jerarquía de tipos de dispositivos que tiene elementos de nivel superior predeterminados que incluyen un tipo de dispositivo controlador y un tipo de dispositivo básico, y al menos un nivel adicional de tipos de dispositivos subsidiarios que dependen del tipo de dispositivo básico y que heredan propiedades de los tipos de dispositivos de nivel superior de los que depende el tipo de dispositivo subsidiario, pero sin incluir ningún nivel adicional de tipos de dispositivos subsidiarios que dependen del tipo de dispositivo controlador.
Según la implementación preferida del protocolo HUCL, el formato de mensaje subyacente es un formato legible por humanos, tal como XML. Sin embargo, para ahorrar ancho de banda, los mensajes se pasan entre dispositivos de red en forma comprimida. Sin embargo, un dispositivo de red puede procesar tales mensajes comprimidos, porque el método de compresión usado es la compresión en testigo, que sustituye cadenas comunes por testigos. Por tanto, el dispositivo de red puede reconocer los testigos comprimidos sin descompresión, al menos lo suficiente para reconocer una consulta que requiere una respuesta de una descripción de dispositivo sencilla, y luego responder con una descripción de dispositivo sencilla. Por tanto, un dispositivo de red puede implementarse con poca sobrecarga.
Una manera adecuada de codificación en testigo se describe en “wap binary XML content format” del 24 de junio de 1999, disponible en el momento de redacción en http://www.w3.org/TR/ wbxml.
Se indicará que aunque hay preferiblemente al menos una jerarquía que depende de un tipo de dispositivo básico, es decir una jerarquía de dispositivos controlados, no hay jerarquía correspondiente de dispositivos controladores. Esto es para mantener los mensajes de descripción de dispositivo sencilla tan cortos y sencillos como sea posible; muchos controladores, tales como un mando a distancia universal, pueden controlar varios tipos de dispositivos diferentes.
Preferiblemente, la pluralidad de dispositivos de red incluye al menos un dispositivo sencillo sin la capacidad de descomprimir mensajes y que por consiguiente interpreta directamente mensajes comprimidos y al menos un dispositivo complejo que incluye una disposición de descompresión de mensajes para descomprimir los mensajes y un intérprete de mensajes para interpretar los mensajes descomprimidos.
En otro aspecto, la invención se refiere a un dispositivo de red individual que puede responder tanto al mensaje de consulta de descripción de dispositivo sencilla como extendida.
Por consiguiente, en un segundo aspecto, se proporciona un dispositivo de red que incluye:
un transceptor para enviar y recibir mensajes; y
un gestor de mensajes dispuesto para llevar a cabo las etapas de:
al recibir un mensaje de consulta de descripción de dispositivo sencilla desde uno de los otros dispositivos, enviar al otro dispositivo un mensaje de descripción de dispositivo sencilla de longitud definida que incluye un valor de tipo de dispositivo que representa el tipo del dispositivo de red; y
al recibir un mensaje de consulta de descripción de dispositivo extendida desde otro dispositivo, enviar al otro dispositivo una descripción de dispositivo extendida de longitud variable.
Además de a dispositivos de red que pueden responder a tales mensajes de consulta de dispositivo, la invención también se refiere a dispositivos que generan mensajes de consulta de dispositivo y que procesan los resultados.
Por consiguiente, en un tercer aspecto se proporciona un dispositivo de red, que incluye un transceptor para enviar y recibir mensajes:
un gestor de mensajes dispuesto para llevar a cabo las etapas de:
establecer la dirección de al menos otro dispositivo;
enviar un mensaje de consulta de descripción de dispositivo sencilla a otro dispositivo solicitando una descripción de dispositivo sencilla;
recibir desde el otro dispositivo un mensaje de descripción de dispositivo sencilla de longitud fija que incluye un valor de tipo de dispositivo que representa el tipo del otro dispositivo y un campo que indica si está disponible una descripción de dispositivo extendida;
y además dispuesto para llevar a cabo opcionalmente las etapas de:
someter a prueba el mensaje de descripción de dispositivo sencilla para determinar si está disponible una descripción de dispositivo extendida;
enviar un mensaje de consulta de descripción de dispositivo extendida al otro dispositivo solicitando una descripción de dispositivo extendida al otro dispositivo; y
recibir desde el otro dispositivo una descripción de dispositivo extendida de longitud variable.
La invención también se refiere a los métodos de funcionamiento de los dispositivos de los aspectos segundo y tercero.
Por consiguiente, en un cuarto aspecto, la invención se refiere a un método de funcionamiento de un dispositivo de red, que incluye: enviar un mensaje de consulta de descripción de dispositivo sencilla a uno de los otros dispositivos solicitando una descripción de dispositivo sencilla; recibir desde el otro dispositivo un mensaje de descripción de dispositivo sencilla de longitud definida que incluye un valor de tipo de dispositivo que representa el tipo del otro dispositivo y un campo que indica si está disponible una descripción de dispositivo extendida; someter a prueba el mensaje de descripción de dispositivo sencilla para determinar si está disponible una descripción de dispositivo extendida, y si es así enviar un mensaje de consulta de descripción de dispositivo extendida al otro dispositivo solicitando una descripción de dispositivo extendida al otro dispositivo; y recibir desde el otro dispositivo una descripción de dispositivo extendida de longitud variable.
En un quinto aspecto, la invención se refiere a un método de funcionamiento de un dispositivo de red, que incluye:
recibir un mensaje de consulta de descripción de dispositivo sencilla desde uno de los otros dispositivos solicitando una descripción de dispositivo sencilla;
enviar al otro dispositivo un mensaje de descripción de dispositivo sencilla de longitud definida que incluye un valor de tipo de dispositivo que representa el tipo del dispositivo de red;
recibir un mensaje de consulta de descripción de dispositivo extendida desde el otro dispositivo solicitando una descripción de dispositivo extendida al dispositivo de red; y
enviar al otro dispositivo una descripción de dispositivo extendida de longitud variable.
Tal como se mencionó anteriormente, el valor de tipo de dispositivo puede seleccionarse a partir de una jerarquía de tipos de dispositivos que tiene elementos de nivel superior predeterminados que incluyen un tipo de dispositivo controlador y un tipo de dispositivo básico, y al menos un nivel adicional de tipos de dispositivos subsidiarios que dependen del tipo de dispositivo básico y que heredan propiedades de los tipos de dispositivos de nivel superior de los que depende el tipo de dispositivo subsidiario, pero sin incluir ningún nivel adicional de tipos de dispositivos subsidiarios que dependen del tipo de dispositivo controlador.
Un dispositivo controlador según la invención preferiblemente incluye una entrada de control, y controla otros dispositivos basándose en señales recibidas en la entrada de control. Además, el dispositivo controlador puede implementar una o más maneras de determinar qué dispositivos puede controlar el controlador.
Un enfoque para afrontar la falta de información cuando un dispositivo es un tipo de dispositivo controlador es que el dispositivo controlador tenga la funcionalidad responder a un mensaje de consulta de controlador entrante que consulta si el controlador puede controlar un tipo de dispositivo predeterminado respondiendo con el nivel más bajo de tipo de dispositivo en la lista de tipos de dispositivos que pueden controlarse por el dispositivo de red que o bien es el tipo de dispositivo predeterminado o bien es un tipo de dispositivo de nivel superior del que depende el tipo de dispositivo predeterminado. El dispositivo controlador puede enviar entonces señales de control seleccionadas a partir de una lista predeterminada de señales de control a otros dispositivos según señales recibidas en la entrada de control.
En lugar de ser un dispositivo controlador, el dispositivo puede ser un dispositivo controlado que tiene un tipo de dispositivo del tipo de dispositivo básico o un tipo de dispositivo que depende del tipo de dispositivo básico; teniendo el dispositivo de red la capacidad de responder a instrucciones de dispositivo básicas enviadas por un controlador, incluyendo las instrucciones al menos un conjunto de instrucciones de base predeterminadas.
Con el fin de tratar dispositivos multifuncionales, los elementos de nivel superior predeterminados pueden incluir un tipo de dispositivo compuesto con la funcionalidad de un número predeterminado de otros tipos de dispositivos, y dispuesto para responder a un mensaje de consulta de dispositivo entrante que requiere una descripción de dispositivo sencilla enviando una descripción de dispositivo sencilla que incluye el tipo de dispositivo como dispositivo compuesto y el número instantáneo de otros tipos de dispositivos.
El dispositivo de red puede incluir una memoria que almacena un mensaje de descripción de dispositivo sencilla predeterminado, en el que el mensaje de descripción es un mensaje comprimido previamente a partir de un mensaje en forma legible por humanos que incluye un tipo de dispositivo; indicando una bandera si el dispositivo emisor tiene una descripción de dispositivo extendida disponible; e identificando un número predeterminado de banderas adicionales un número predeterminado de configuraciones de estado adicionales. Por tanto, en lugar de generar un mensaje de descripción de dispositivo sencilla internamente, se almacena previamente un mensaje adecuado y se emite cuando se requiere.
La invención también se refiere a un programa informático para controlar un dispositivo de red.
El sistema puede incluir varios dispositivos sencillos, con funcionalidad sencilla y sin capacidad de descomprimir mensajes, y dispositivos más complejos que descomprimen mensajes para interpretarlos y funcionar sobre la base de los mismos. Los dispositivos más complejos pueden tener una funcionalidad mucho más compleja, a expensas de una mayor sobrecarga y un mayor requisito de potencia de procesador.
Para un mejor entendimiento de la invención, ahora se describirán realizaciones meramente a modo de ejemplo, con referencia a los dibujos adjuntos en los que:
la figura 1 muestra un par de dispositivos que se comunican usando una realización según la invención;
la figura 2 muestra una vista esquemática del software en un dispositivo;
la figura 3 es un diagrama de flujo del proceso de descubrimiento de dispositivos;
la figura 4 es una vista esquemática de la jerarquía de tipos de dispositivos;
la figura 5 muestra las etapas que un controlador lleva a cabo para informar a un dispositivo controlado acerca de su capacidad de control de ese dispositivo;
la figura 6 muestra las etapas que un controlador lleva a cabo para determinar su capacidad de control de un dispositivo controlado;
la figura 7 es un diagrama de flujo del proceso de descubrimiento de dispositivos para un dispositivo compuesto;
la figura 8 ilustra una realización de un dispositivo compuesto;
la figura 9 ilustra otra realización de un dispositivo compuesto;
la figura 10 muestra la estructura del software;
la figura 11 ilustra el protocolo HUCL; y
la figura 12 ilustra un mensaje de descripción de dispositivo sencilla.
El protocolo HUCL es un protocolo de control ligero y de ancho de banda bajo, diseñado principalmente para sistemas inalámbricos. El formato de mensajería se basa en XML, y los mensajes se comprimen antes de la transmisión. El uso de XML proporciona una solución extensible y escalable al reducir la compresión los datos enviados, reduciendo de ese modo la cantidad de tiempo que el transmisor está encendido y consumiendo potencia.
Los principios generales del protocolo HUCL y cómo funcionaría en un dispositivo se comentarán ahora con referencia a un ejemplo sencillo.
Haciendo referencia a la figura 1, se proporcionan un interruptor 2 de luz y una luminaria 4. El interruptor 2 de luz tiene un interruptor 6 basculante físico manejado por el usuario, junto con un transceptor 8 de RF y una batería 10, junto con un conjunto 12 de circuitos y una memoria 14. La luminaria también tiene un transceptor 8 de RF y una memoria 14, pero recibe energía de la red eléctrica y tiene el conjunto 20 de circuitos para aplicar potencia a la bombilla 22. Por tanto, el interruptor 2 de luz es un ejemplo de un controlador que tiene una entrada 6 de control (el interruptor), mientras que la luminaria es un ejemplo de un dispositivo 4 controlado. La memoria 14 en el controlador incluye una lista 24 de tipos de dispositivos que el controlador puede controlar, y las funciones de control que corresponden a los tipos de dispositivos. La memoria 14 en los dispositivos tanto controlado 4 como controlador 2 también contiene código 26 para hacer que el conjunto de circuitos lleve a cabo los métodos que se describirán en más detalle a continuación.
La figura 2 muestra una representación del software que reside en cada uno de los dispositivos en la memoria 14. La aplicación 30 de control se comunica con la pila 32 de software de HUCL cuando se producen determinados eventos.
De una manera similar, la pila 32 de software de HUCL se comunica con la pila 34 de software de RF, y la pila 34 de software de RF se comunicará de vuelta con la pila 32 de software de HUCL cuando se producen determinados eventos, por ejemplo en la recepción de datos.
Se envían y se reciben mensajes 36. Los mensajes pueden ser de varios tipos, incluyendo un mensaje de consulta de descripción de dispositivo sencilla, o cualquiera de varios otros tipos de mensajes.
El funcionamiento de los dispositivos se describirá ahora con referencia a la figura 3. La primera fase en el funcionamiento de este par de dispositivos es que el interruptor descubra la dirección de la luminaria. Esto se conoce como descubrimiento de dispositivos, y es un requisito de la pila de transportes de RF subyacente que o bien se proporcione el descubrimiento de dispositivos (en la pila de software de RF), o bien que sea posible implementar el descubrimiento de dispositivos encima de la pila de transporte (en la capa inferior de la pila de software de HUCL).
El proceso de descubrimiento se inicia 100 mediante la aplicación de control (posiblemente como resultado de alguna interacción de usuario) realizando una llamada a la pila de software de HUCL solicitando en primer lugar el número de dispositivos conocidos, y luego las direcciones de red de esos dispositivos. Se devuelven esas direcciones de dispositivo.
Dependiendo del protocolo de RF subyacente, las direcciones de red pueden establecerse de alguna otra manera.
El resultado final de la fase de descubrimiento de dispositivos es que se suministra 102 a la aplicación de control una lista de direcciones de todos los dispositivos conocidos por la pila de RF. En este punto en el proceso, la aplicación de control no conoce nada más acerca de cada uno de los otros dispositivos aparte de su dirección.
La segunda fase en el proceso de emparejamiento es que la aplicación de control recopile información sobre los dispositivos para los que tiene direcciones. Esta información se denomina descripción de dispositivo. La aplicación de control hace esto realizando una llamada a la pila de software de HUCL, pasando la dirección del dispositivo del que solicita la descripción de dispositivo.
La solicitud de la descripción de dispositivo sencilla se pasa 104 entonces a través del enlace de RF al dispositivo de destino, de modo que en el ejemplo de interruptor/luminaria descrito anteriormente la solicitud se transmite desde el interruptor a la luminaria. Al recibir la solicitud, la pila de software de HUCL en el dispositivo de destino realiza una llamada a la aplicación de control solicitando la descripción de dispositivo. El formato de la descripción está definido. Si no está ya en una forma comprimida, la descripción se comprime antes de transmitirse de vuelta al emisor de la solicitud.
Cuando la pila de software de HUCL en el dispositivo solicitante recibe 106 la descripción de dispositivo, se pasa a la aplicación de control. En este punto la aplicación tiene cierta información básica acerca del dispositivo y puede tomar la decisión de si desea comunicarse adicionalmente con este dispositivo.
Un objetivo de diseño de HUCL es que sea adecuado para funcionar en dispositivos muy sencillos, sin embargo la información necesaria para describir completamente un dispositivo es potencialmente bastante compleja. La lista a continuación muestra la clase de información que un dispositivo podría desear proporcionar como parte de su descripción.
Tipo de dispositivo, por ejemplo DVD
Nombre del fabricante, por ejemplo Philips
Número de modelo, por ejemplo DVD1010/002
Número de serie, por ejemplo AH06848032345
URL de fabricante, por ejemplo www.philips.com
Para los dispositivos de control más sencillos, tales como el interruptor usado en el ejemplo en esta sección, gran parte de esta información es probablemente redundante. Sin embargo, sería útil que un mando a distancia de tipo “PDA” de gama alta con una pantalla en la que puede presentarse visualmente tal información al usuario.
El procesamiento de tales descripciones en dispositivos de gama baja puede presentar un problema, puesto que sería potencialmente necesario que el almacenamiento (RAM) almacene en caché el mensaje completo cuando se recibe. El problema es peor de lo que podría parecer a primera vista, puesto que el tamaño global de los datos de descripción mostrados anteriormente es indeterminado, gran parte de la información es “texto libre”; el nombre del fabricante podría ser muy largo, el URL podría especificar una página exacta quizás incluso con parámetros, por ejemplo http://www.consumer.philips.com/global/b2c/ce/catalog/subcategory.jhtml?groupld=VIDEO&divId=0&cat-Id=DVD&subCatId=DVDPLAYER
La manera en la que esto se supera en HUCL es que la descripción de dispositivo se divide en dos capas de información. La primera capa en una descripción simplista del dispositivo pero que identifica si hay disponible información adicional. No contiene ningún campo de texto libre de modo que la longitud global de la misma es determinística. La segunda capa de información extendida es opcional pero proporciona información adicional.
Haciendo referencia a la figura 12, el mensaje 230 de descripción de dispositivo sencilla incluye como campos el tipo 232 de dispositivo, un campo 238 para indicar si está disponible descripción de dispositivo extendida y otros campos 236 que identifican información clave, por ejemplo una bandera para indicar si está disponible la suscripción a eventos. Un campo 234 de número entero opcional representa el número de subdispositivos de un dispositivo compuesto. El experto apreciará que el mensaje 230 también puede incluir una cabecera y una cola que se omiten por simplicidad. El mensaje incluirá testigos de XML comprimidos que se omiten de la misma manera por claridad. Todos los campos de la descripción de dispositivo sencilla tienen una longitud fija, de modo que pueden tratarse rápidamente sin descompresión.
Después de recibir 106 (figura 3) la descripción 230 de dispositivo sencilla, la descripción 230 de dispositivo sencilla se pasa de vuelta a la pila de HUCL.
Si está disponible la descripción de dispositivo extendida y el dispositivo controlador la requiere, la aplicación de control del dispositivo controlador puede emitir una solicitud 108 de “ConseguirDescripciónExtendida” de vuelta al dispositivo.
La pila de HUCL en el dispositivo que recibe esta solicitud realiza una llamada de conseguir descripción extendida a la aplicación de control que solicita la descripción de dispositivo extendida.
La descripción de dispositivo extendida se pasa de vuelta a la pila de HUCL, y vuelve a la aplicación de control en el dispositivo que la solicitó. La descripción extendida se devuelve 110 entonces al dispositivo solicitante.
Si una consulta de conseguir descripción extendida se recibe en un dispositivo que no proporciona una descripción de dispositivo extendida, la solicitud simplemente se ignora.
Volviendo de nuevo al ejemplo de interruptor/luminaria usado en esta sección, desde el punto en el que el interruptor conoce sólo la dirección de la luminaria, el interruptor solicita a la luminaria su descripción de dispositivo sencilla. Al recibirla, proporciona suficiente información de manera que el interruptor sabe que está comunicándose con una luminaria que ajusta al conjunto de instrucciones de luminaria convencional, también sabe que (por ejemplo) la luminaria no puede proporcionar ninguna descripción de dispositivo extendida.
Es obligatorio que una aplicación de dispositivo proporcione una descripción de dispositivo sencilla a la pila de HUCL cuando se solicita. Un dispositivo que no proporciona ninguna descripción de dispositivo extendida puede ignorar cualquier solicitud que reciba de tal información.
Incluido en la descripción de dispositivo sencilla devuelta por un dispositivo (cuando se solicita) está el campo 232 de tipo de dispositivo que identifica el tipo del dispositivo, por ejemplo TV, DVD, luminaria, etc. El campo 232 de tipo de dispositivo identificará en el controlador (que solicita la descripción de dispositivo sencilla) el conjunto de instrucciones a las que se ajusta el dispositivo. Los dispositivos de HUCL se identifican a sí mismo simplemente por su identificador de tipo, luego no continúan enviando mensajes para describir cómo se controlan; no hay concepto de descripción de servicio de “tiempo de ejecución” en HUCL. Si un dispositivo se identifica a sí mismo como luminaria, entonces el conjunto de instrucciones que puede llamarse en este dispositivo se identifica en la especificación de HUCL para un dispositivo de tipo luminaria.
Haciendo referencia a la figura 4, todos los tipos de dispositivos dependen de un tipo 50 de dispositivo de base. Elementos 58 de nivel superior incluyen en este ejemplo el tipo 52 de dispositivo controlador, un tipo 54 de dispositivo básico para dispositivos controlados y un tipo 56 de dispositivo de alarma.
Tipos 68 de dispositivos subsidiarios dependen del tipo de dispositivo básico. En el ejemplo, estos incluyen un tipo 64 de dispositivo de TV, un tipo 62 de dispositivo de luz atenuable y un dispositivo 60 de PVR.
La clasificación de tipos de dispositivos es para producir un sistema destinado a permitir que un controlador sencillo identifique si puede controlar un dispositivo en la medida de las capacidades de los controladores.
Un interruptor sencillo podría estar emparejado con una luminaria para encender y apagar una luz, pero podría argumentarse que la funcionalidad de control del interruptor, es decir su capacidad de encender o apagar un dispositivo, debe ser aplicable a cualquier dispositivo que pueda aceptar un concepto de encendido/apagado, por ejemplo una TV, un calefactor, una impresora.
Una manera en la que esto podría implementarse es que el interruptor tenga una lista de todos los dispositivos que sabe cómo controlar (encender o apagar), de modo que cuando solicita la descripción de dispositivo sencilla para un dispositivo, puede mirar en el campo de tipo de dispositivo en la descripción devuelta y determinar si está dentro de su lista de tipos de dispositivos que sabe cómo controlar.
Hay dos inconvenientes significativos de este enfoque. En primer lugar, el interruptor es un dispositivo muy sencillo y no es deseable que la aplicación dentro del mismo tenga que mantener una lista de todos los posibles dispositivos que podría controlar, que sería bastante grande; en segundo lugar si se crea un tipo nuevo de dispositivo después de la producción del interruptor (que pueda aceptar una funcionalidad de encendido/apagado sencilla), entonces el interruptor no tendrá este tipo de dispositivo nuevo en su lista, y no creerá que puede controlarlo, es decir no es extensible.
HUCL clasifica dispositivos de manera jerárquica, mostrada en la figura 4. El campo 232 de tipo de dispositivo (figura 15) identifica el dispositivo dentro de la jerarquía y entonces incluso si se crearan dispositivos nuevos, siempre que se derive de un punto apropiado dentro de la jerarquía, un interruptor sencillo todavía sabría que puede controlarlo en cierta medida.
Dispositivos que se sitúan en la parte inferior en el árbol heredan la funcionalidad de tipos de dispositivos situados por encima. Puede ser necesario añadir cierta interpretación a las instrucciones cuando se aplican a dispositivos inferiores en el árbol, por ejemplo la instrucción de encendido/apagado cuando se envía a una luz de manera bastante obvia la encenderá y apagará, pero las mismas instrucciones cuando se envían a una TV la pondrían dentro y fuera de un modo de espera.
El beneficio clave de la jerarquía de tipos de dispositivos es que incluso aunque el controlador no tenga conocimiento del propio tipo de dispositivo específico, puede determinar el dispositivo a partir del cual se deriva, del que puede tener cierto conocimiento y por tanto puede controlar el dispositivo en una medida algo menor (desde la perspectiva del dispositivo).
Por ejemplo, se considera el caso en el que un interruptor de luz obtiene la dirección de un dispositivo, le solicita a este dispositivo la descripción de dispositivo sencilla; el campo de tipo de dispositivo identifica el dispositivo como TV, pero el interruptor no reconoce esto como dispositivo que conoce. Sin embargo, el interruptor también puede establecer a partir de la descripción que es un derivado del “dispositivo básico”, que conoce. El resultado neto es que el interruptor puede controlar la TV, en la medida de las capacidades de los controladores, es decir encendido y apagado, a pesar de no conocer nada acerca del dispositivo en sí. El dispositivo podría ser una categoría totalmente nueva de dispositivo denominada “XYZ” inventado mucho después que se fabricara el interruptor, pero siempre que se derive de un dispositivo básico el interruptor todavía puede controlarlo en cierta medida.
Aunque la jerarquía de tipos de dispositivos puede tener sólo dos capas, y el controlador y los elementos de nivel superior de dispositivo básico, puede desearse al menos una capa adicional y/o elemento de nivel superior. Esto está concebido para dispositivos que no cumplirían con la funcionalidad mostrada anteriormente en el dispositivo básico, es decir dispositivos que no tienen una funcionalidad de “encendido” – “apagado” básica, por ejemplo una alarma. Para fines ilustrativos, un dispositivo 56 de tipo “alarma” se ha mostrado en la figura 4 y naturalmente este dispositivo de “alarma” no desea implementar las funciones de encendido/apagado normales que los dispositivos que se derivan del dispositivo básico deben tener; por tanto se sitúa en el mismo nivel 58 superior en la jerarquía que el propio dispositivo 54 básico.
Una segunda extensión de la jerarquía también se muestra en la figura 4, es decir el dispositivo 66 de TV mejorada por debajo del dispositivo 64 de TV normal. En este caso, el dispositivo de TV mejorada hereda toda la funcionalidad tanto del dispositivo 54 básico como del dispositivo 64 de TV, pero también incluye cierta funcionalidad extendida que no está presente en una TV normal. Un mando a distancia de TV convencional diseñado para hacer funcionar un dispositivo de TV normal puede hacer funcionar el dispositivo de TV mejorada hasta el nivel de una funcionalidad de dispositivo de TV normal, pero no puede controlar la funcionalidad extendida.
El protocolo HUCL por consiguiente proporciona un mecanismo extensible para describir el tipo de dispositivo y los dispositivos por encima del mimo de los que hereda funcionalidad. Mientras que la idea de una jerarquía de muchas capas podría parecer atractiva, extenderlas más allá de tres o cuatro niveles empezará a tener un impacto en el tamaño de la descripción de dispositivo sencilla.
Dentro de HUCL es posible solicitar una descripción de dispositivo a un controlador así como un dispositivo controlable. Cuando un dispositivo envía la “Conseguir Descripción Sencilla” a un dispositivo controlador (por ejemplo un interruptor) se devuelve una descripción de dispositivo sencilla que contiene un tipo de dispositivo de “controlador”. El dispositivo controlador también puede poner a disposición una descripción de dispositivo extendida que proporciona información adicional tal como el fabricante, número de modelo, etc.
Es importante observar que el tipo de dispositivo devuelto por un dispositivo controlador es simplemente “controlador” 52; no hay jerarquía de dispositivos de tipo de controlador diferentes definidos en el árbol de tipos de dispositivos. El motivo de esto es intentar de nuevo mantener el protocolo y tamaños de mensajes pequeños y sencillos. Podría considerarse que sería posible tener diferentes tipos de controlador derivados del controlador básico tal como un interruptor, un mando a distancia de TV, un mando a distancia de PVR, etc. Sin embargo, podría producirse un problema con controladores inteligentes tales como mandos a distancia universales que pueden controlar una amplia variedad de dispositivos. Incluir todos los tipos de controladores posibles en una descripción de dispositivo sencilla daría como resultado un mensaje potencialmente grande, lo que se opone al ideal de intentar hacer que la descripción de dispositivo sencilla inicial sea sencilla. Para determinar las capacidades exactas de un dispositivo controlador se emplean mecanismos diferentes.
El primer medio para determinar las capacidades de un dispositivo controlador es mediante la descripción de dispositivo extendida que se permite en un dispositivo controlador y puede contener información tal como el nombre de dispositivo por ejemplo “mando a distancia universal” y aunque esta información es textual y no es directamente interpretable mediante el software de aplicación, puede presentarse al usuario para ayudar a hacer una elección informada acerca de un controlador.
El segundo medio para que un dispositivo determine más acerca de un controlador es mediante consulta al mismo.
El uso de una consulta es un mecanismo potente para proporcionar gradualmente información acerca de un dispositivo que, de lo contrario, si se suministra en masa, sobrecargaría al solicitante.
Cada tipo de dispositivo controlador proporciona un medio para que otros dispositivos consulten 120 si pueden controlar un tipo de dispositivo específico (figura 5). El tipo de dispositivo pasado en la consulta es el mismo campo que se usa en la descripción de dispositivo sencilla, es decir tal como se define en la jerarquía de tipos de dispositivos. El controlador devuelve 122 el nivel hasta el que puede controlar el dispositivo, devolviendo el tipo de dispositivo más bajo en una lista almacenada en la memoria 14 del controlador que es el tipo de dispositivo pasado en la consulta o del que depende ese tipo de dispositivo. Por ejemplo, se consulta a un interruptor sencillo si puede controlar un dispositivo de TV mejorada. Basándose en la jerarquía ilustrada en la figura 4 anterior, la respuesta es que puede controlarlo hasta el nivel de dispositivo básico. El interruptor en sí no conocerá normalmente nada acerca de un tipo de dispositivo de dispositivo de TV mejorada, pero puesto que el tipo de dispositivo también incluye los dispositivos heredados, podrá identificar el dispositivo básico y devolverlo como tipo de dispositivo superior jerárquicamente más bajo que puede controlar.
El controlador también implementa un algoritmo para determinar si el interruptor puede controlar un tipo de dispositivo que se devuelve al mismo en una descripción de dispositivo sencilla (figura 6). Cuando un interruptor descubre la dirección de un dispositivo, pregunta 124 al dispositivo su descripción de dispositivo sencilla, al recibir esta información 126 e interruptor somete a prueba 128 si puede controlar un dispositivo de este tipo en algún grado, que es la misma pregunta que tiene que responder como resultado del proceso de consulta 120. El resultado es que los procesos de consulta 120, 122, 124, 126, 128 no contribuyen demasiado a la complejidad del dispositivo interruptor sencillo. Lo mismo se aplica a otros dispositivos sencillos.
Puede preverse que habrá casos en los que un dispositivo puede ser una composición de varios dispositivos discretos a los que se accede a través de la misma dirección física, por ejemplo coubicados todos en un único transceptor de RF.
Ejemplos de este tipo de dispositivo son una serie de luces que pueden conmutarse individualmente controladas a través de un único transceptor de RF, o una TV con reloj de alarma integrado en el que ambos componentes pueden controlarse remotamente de nuevo a través del mismo transceptor.
La figura 7 ilustra el proceso de descubrimiento. El interruptor obtiene inicialmente las direcciones de todos los dispositivos conocidos por el medio de transporte subyacente, esto incluye la dirección única de las cuatro luces que pueden controlarse individualmente. El interruptor emite 140 una instrucción de conseguir descripción sencilla a la serie de luces, y la pregunta que surge es ¿cuál debe ser la respuesta?. Si se devuelven cuatro descripciones de dispositivo entonces esto sería cuatro veces la cantidad de datos que el interruptor esperaría recibir. La devolución de múltiples descripciones de dispositivo sencillas no es muy escalable, y, por ejemplo, ocasionaría problemas si hubiera 20 luces en la serie de luces.
La solución para esto proporcionada por HUCL es un tipo de dispositivo específico para dispositivos compuestos.
El dispositivo compuesto devuelve 142 su descripción de dispositivo sencilla que incluye en el campo 232 de tipo de dispositivo su tipo de dispositivo como “dispositivo compuesto”. La descripción de dispositivo sencilla también identifica en el campo 234 que hay, en este ejemplo, cuatro dispositivos integrados dentro de este único dispositivo.
La siguiente fase, una vez que el controlador ha identificado que está comunicándose con un dispositivo compuesto, es que establezca qué dispositivos están incorporados dentro del mismo. El controlador realiza 144 solicitudes de conseguir descripción sencilla adicionales al dispositivo compuesto pero dirigiendo las solicitudes a los dispositivos incorporados específicos. Los dispositivos incorporados devuelven 146 sus descripciones de dispositivo.
Una vez que el controlador decide que va a controlar uno de los dispositivos incorporados, todas las instrucciones de control se dirigen al dispositivo incorporado específico incluyendo un ID de dispositivo incorporado con cada instrucción. Una vez que el concepto del dispositivo compuesto se ha establecido, abre la posibilidad de varias combinaciones de dispositivos interesantes que serían beneficiosas, algunas de éstas se comentarán a continuación.
Un ejemplo es un único dispositivo que consiste en una lámpara con un interruptor integrado, en la que la funcionalidad del interruptor está expuesta para poder controlar otros dispositivos. Este dispositivo, cuando se le solicita su descripción de dispositivo sencilla se presenta a sí mismo como dispositivo compuesto, pero cuando se le consulta adicionalmente, se descubrirá que un dispositivo incorporado es un controlador, y el otro es un dispositivo controlable, es decir de iluminación. Varios de tales dispositivos podrían configurarse de tal manera que al operar el interruptor en uno cualquiera de los dispositivos se hace que las luces se enciendan/apaguen en todos los dispositivos, por ejemplo al encendiendo cualquier lámpara de mesa en la sala se hace que todas las lámparas de mesa en la sala se enciendan.
Otras posibles combinaciones de dispositivo compuesto dentro del dominio de CE incluyen por ejemplo una TV + grabador de videocasete (VCR) o DVD y VCR. En caso necesario, cada uno de estos podría describirse como un compuesto de dos dispositivos.
Conceptualmente, un dispositivo consiste en el dispositivo núcleo más cero o más subcomponentes, por ejemplo un dispositivo 60 de TV puede consistir por ejemplo en el propio dispositivo 60 de TV más los subcomponentes de sintonizador 64, audio 66 y pantalla 68 (véase la figura 8).
También puede concebirse que un único dispositivo pueda tener más de una instancia de subcomponente por ejemplo un dispositivo combinado de TV / VCR puede tener dos sintonizadores 62, 64, uno para la TV y uno para el VCR (véase la figura 9), así como componentes de audio 66 y pantalla 68.
Podría considerarse que el uso de XML y su compresión y descompresión en los dispositivos más sencillos es un poco pesado. El uso de XML para describir el protocolo proporciona una solución que es fácilmente extensible para futuras mejoras, relativamente simple de describir y entender, puede gestionar fácilmente información estructurada y es compatible de manera instantánea con el “dominio de Internet”.
El uso de una técnica de compresión etiquetada en XML (definido dentro de HUCL) reduce el tamaño del protocolo relativamente detallado hasta el de un protocolo binario puro tradicional, con cierta sobrecarga adicional para mantener la estructura de contenido.
Si se nos presenta la instrucción en su forma comprimida, ésta puede leerse de manera similar a como se leería cualquier otro protocolo binario, usando información sobre la estructura de instrucción y una tabla de definiciones para valores de datos. La única indicación de que los datos binarios pueden haberse originado de una anotación basada en XML sería la presencia de datos para representar la estructura.
La especificación de HUCL define que los mensajes siempre se transmiten a través del medio de transporte en su forma comprimida. Sin embargo, en un dispositivo sencillo la aplicación puede funcionar directamente con mensajes comprimidos, de modo que se elimina la necesidad en ese dispositivo de la presencia de software de compresión / descompresión dentro de la pila de software de HUCL. En este caso, la aplicación almacenaría (como parte de la imagen de aplicación en ROM) la descripción de dispositivo sencilla en su forma comprimida previamente, tendría un analizador sintáctico para los mensajes de protocolo comprimidos que recibe, lo que sería de naturaleza similar a cualquier otro analizador sintáctico de protocolo binario; también sería necesario almacenar cualquier mensaje de respuesta en su forma comprimida.
Usando este enfoque, los dispositivos más sencillos tales como el ejemplo del interruptor de luz y la luminaria usado en esta sección pueden implementarse con una pila de software reducida, y dado que el número de instrucciones que un dispositivo sencillo tendría que entender y enviar es relativamente pequeño (encender la luz, apagar la luz, bascular, conseguir estado actual, conseguir descripción de dispositivo, etc.) la sobrecarga en el software de aplicación es mínima.
Esto ofrece una solución escalable para dispositivos, cuando es práctico implementar la aplicación para operar en datos comprimidos, esto puede realizarse, pero cuando el dispositivo se hace más complejo habrá un punto en el que resultará más fácil incluir la funcionalidad de compresión / descompresión en la pila y hacer que la aplicación use los mensajes de protocolo en su anotación de XML completa. Este punto de corte puede determinarlo completamente el diseñador de dispositivo y no se define ni se dicta por HUCL en absoluto.
La figura 10 ilustra cómo los componentes que constituyen HUCL se ajustan entre sí. Se apreciará que los componentes son componentes de software grabados en la memoria.
Las siguientes secciones comentan en más detalle las capas que forman la pila 32 de software de HUCL y la funcionalidad que proporcionan.
Tal como se mencionó anteriormente, HUCL no se basa en un protocolo de transporte específico (a diferencia de por ejemplo TCP/IP) sino que en cambio se sitúa directamente encima de una pila 34 de transporte. Diferentes pilas 34 de transporte ofrecerán por su naturaleza servicios diferentes a aplicaciones y a través de API diferentes; la capa 180 de adaptación de transporte de HUCL actúa como memoria intermedia con respecto a la capa de transporte específica.
La capa 180 de adaptación de transporte proporciona a las capas superiores en la pila de HUCL un conjunto de servicios independiente del transporte acorde. Los requisitos de esta capa se definen en detalle en la especificación del protocolo.
La capa 182 de mensajería proporciona la mayor parte de la funcionalidad de la pila de software de HUCL. Las aplicaciones se comunican con esta capa a través de API de HUCL y realizará las llamadas de vuelta a la aplicación cuando sea necesario (por ejemplo cuando se reciban datos).
La capa 182 de mensajería también gestiona cualquier informe de error inicial y si es necesario acuses de recibo. Los ID de mensajes y los ID de transacción usados para verificar mensajes que faltan y para acoplar mensajes a repuestas también se gestionan completamente por esta capa.
La capa 182 de mensajería también usa los servicios 184 de compresión / descompresión cuando es necesario comprimir o descomprimir un mensaje. Tal como se comentó anteriormente, una aplicación trata exclusivamente mensajes en su forma comprimida, no se realizan llamadas a estos servicios y pueden retirarse de la pila de tiempo de ejecución.
De una manera bastante sencilla, los servicios de compresión y descompresión proporcionan a la capa de mensaje los medios para convertir los mensajes de HUCL entre sus formas comprimida y descomprimida. Es posible que este componente del sistema esté ausente en dispositivos de gama baja en los que todos los intercambios de datos con la aplicación se realizan con mensajes comprimidos.
La interfaz 186 de programación de aplicaciones API es la interfaz a través de la cual todas las aplicaciones se comunican con la pila de software de HUCL. La comunicación es bidireccional porque la pila de HUCL realizará llamadas asíncronas de vuelta a la aplicación como resultado de determinados eventos que se producen en las capas inferiores, por ejemplo, mensaje recibido a través de la pila de transporte.
HUCL es una pila 34 de transporte independiente, y lo que esto significa es que el protocolo de mensajería de HUCL puede construirse encima de una variedad de pilas de transporte, tanto por cable como inalámbricas.
Puesto que HUCL se diseña como un protocolo ligero, por tanto es adecuado principalmente para pilas de transporte ligeras también, tal como la norma Zigbee (802.15.4) emergente, pero puede situarse igual de bien encima de TCP & UDP /IP lo que abre una amplia variedad de otros protocolos, tanto por cable (por ejemplo Ethernet) como inalámbricos (por ejemplo 802.11 b).
Para implementar HUCL en una pila 34 de transporte debe ser posible proporcionar varios servicios a la capa de mensajería de la pila de HUCL. Esto significa que estos servicios pueden o bien estar presentes en la propia pila de transporte o bien debe ser posible implementar cualquier servicio que falte en la capa de abstracción de transporte de la pila de HUCL. Estos servicios pueden cubrir aspectos tales como direccionamiento, entrega de mensajes y descubrimiento de dispositivos (por ejemplo descubriendo las direcciones de otros dispositivos en la red).
El propio protocolo es un documento grabado en un medio 214, que incluye la siguiente información tal como se muestra en la figura 11:
un formato 200 de mensaje de HUCL genérico que define el formato al que se ajustan todos los mensajes de HUCL;
definiciones 202 de mensaje que definen los mensajes específicos que forman el protocolo de control;
requisitos 204 de secuenciación de mensajes que definen qué mensajes se envían cuándo, y los requisitos de la aplicación al recibir un mensaje;
la definición 206 de API de HUCL que define la interfaz bidireccional entre HUCL y la aplicación que la usa;
los requisitos y funcionalidad 208 del sistema de mensajería de la pila de software de HUCL;
un algoritmo 210 de comprensión que define el mecanismo para la compresión de los mensajes de HUCL, y
una definición 212 de capa de adaptación de transporte que define cómo se interconecta la pila de software de HUCL con un sistema de transporte (por ejemplo una pila de RF).
Por consiguiente, HUCL no es simplemente una definición de formato de mensaje sino que también encapsula un intercambio y compresión de mensajes. Los últimos cuatro ítems en la lista anterior forman la pila de software de HUCL que estarían presentes en un dispositivo, los primeros tres ítems definen los requisitos a los que deben ajustarse la pila y la aplicación.
A partir de la lectura de la presente descripción, otras variaciones y modificaciones resultarán evidentes para los expertos en la técnica. Tales variaciones y modificaciones pueden implicar características equivalentes y adicionales que ya se conocen en el diseño, fabricación y uso de redes y que pueden usarse además de o en lugar de características descritas en el presente documento. Aunque se han formulado reivindicaciones en esta solicitud con respecto a combinaciones particulares de características, debe entenderse que el alcance de la descripción también incluye cualquier característica novedosa o cualquier combinación novedosa de características dadas a conocer en el presente documento o bien de manera explícita o bien de manera implícita o cualquier generalización de las mismas, independientemente de que palie o no cualquiera de o todos los mismos problemas técnicos que la presente invención. Los solicitantes por la presente informan de que pueden formularse reivindicaciones nuevas para cualquiera de tales características y/o combinaciones de tales características durante la tramitación de la presente solicitud o de cualquier solicitud adicional derivada de la misma.
En particular, los nombres de subrutinas específicas usados en los ejemplos pueden variarse sin problemas. El
5 programa informático que controla los dispositivos se muestra como grabado en la memoria 14 pero el experto se dará cuenta de que podría grabarse en muchos otros tipos de soporte de grabación tales como un CD, un disco flexible, etc.
Además, se observará que anteriormente se ha descrito exhaustivamente un ejemplo muy sencillo de luminaria e 10 interruptor de luz. El experto apreciará que también son posibles escenarios de control mucho más complejos.

Claims (19)

  1. REIVINDICACIONES
    1. Método de funcionamiento de un dispositivo de red en una red que tiene al menos otro dispositivo, incluyendo el método:
    enviar (104) un mensaje de consulta de descripción de dispositivo sencilla a al menos otro dispositivo solicitando una descripción de dispositivo sencilla; y
    recibir (106) desde el otro dispositivo un mensaje de descripción de dispositivo sencilla de longitud definida que incluye un valor de tipo de dispositivo que representa el tipo del otro dispositivo y un campo que indica si está disponible una descripción de dispositivo extendida;
    estando el método caracterizado por:
    someter a prueba el mensaje de descripción de dispositivo sencilla para determinar si está disponible una descripción de dispositivo extendida;
    enviar (108) un mensaje de consulta de descripción de dispositivo extendida al otro dispositivo solicitando una descripción de dispositivo extendida al otro dispositivo; y
    recibir (110) desde el otro dispositivo una descripción de dispositivo extendida de longitud variable si está disponible la descripción de dispositivo extendida.
  2. 2.
    Método según la reivindicación 1, que incluye además establecer (102) la dirección de red de otro dispositivo u otros dispositivos antes de la etapa de enviar (104) una descripción de dispositivo sencilla a al menos otro dispositivo.
  3. 3.
    Método según la reivindicación 1 ó 2, en el que el mensaje (230) de descripción de dispositivo sencilla es en forma de mensaje comprimido en un testigo, comprimido a partir de un formato de mensaje legible por humanos, incluyendo el mensaje un valor (232) de tipo de dispositivo que representa el tipo del otro dispositivo; seleccionándose el valor de tipo de dispositivo a partir de una jerarquía de tipos de dispositivos que tiene elementos de nivel superior predeterminados que incluyen un tipo (52) de dispositivo controlador y un tipo (54) de dispositivo básico, y al menos un nivel adicional de tipos de dispositivos subsidiarios que dependen del tipo de dispositivo básico y que heredan propiedades de los tipos de dispositivos de nivel superior de los que depende el tipo de dispositivo subsidiario, pero sin incluir ningún nivel adicional de tipos de dispositivos subsidiarios que dependen del tipo de dispositivo controlador.
  4. 4.
    Método según la reivindicación 3, en el que el dispositivo de red es un dispositivo (2) de controlador que comprende una lista (24) de tipos de dispositivos que el controlador puede controlar.
  5. 5.
    Método según la reivindicación 4, incluyendo además el método determinar si el dispositivo de red puede controlar otro dispositivo:
    determinando el nivel más bajo de tipo de dispositivo que o bien es el tipo de dispositivo del otro dispositivo
    o bien es un tipo de dispositivo de nivel superior del que depende el tipo de dispositivo del otro dispositivo, en la lista de tipos de dispositivos que pueden controlarse por el controlador, para determinar en qué medida el dispositivo de red puede controlar el otro dispositivo.
  6. 6. Método según la reivindicación 5, que incluye además:
    recibir un mensaje de consulta de controlador desde otro dispositivo que incluye un valor de tipo de dispositivo solicitado para solicitar si el controlador puede controlar un dispositivo del tipo de dispositivo solicitado; y
    responder con un mensaje de respuesta de controlador que incluye un valor de tipo de dispositivo que representa el nivel más bajo de tipo de dispositivo en la lista de tipos de dispositivos que o bien es el tipo de dispositivo solicitado o bien es un tipo de dispositivo de nivel superior del que depende el tipo de dispositivo solicitado.
  7. 7. Método según la reivindicación 2, en el que los elementos de nivel superior predeterminados en el jerarquía de tipos de dispositivos incluyen además un tipo de dispositivo compuesto, y el dispositivo de red es del tipo de dispositivo compuesto que tiene la funcionalidad de un número entero de otros dispositivos, comprendiendo además el método:
    responder a un mensaje de consulta de descripción de dispositivo sencilla recibido enviando un mensaje
    (230) de descripción de dispositivo sencilla que incluye el valor (232) de tipo de dispositivo que representa el dispositivo como dispositivo compuesto y además un número entero de subdispositivos que es el número
    (234) de otros dispositivos.
  8. 8. Método de funcionamiento de un dispositivo de red, que incluye:
    recibir (104) un mensaje de consulta de descripción de dispositivo sencilla desde uno de los otros dispositivos solicitando una descripción de dispositivo sencilla;
    enviar (106) al otro dispositivo un mensaje de descripción de dispositivo sencilla de longitud definida que incluye un valor de tipo de dispositivo que representa el tipo del dispositivo de red y un campo que indica si está disponible una descripción de dispositivo extendida;
    recibir (108) un mensaje de consulta de descripción de dispositivo extendida desde el otro dispositivo solicitando una descripción de dispositivo extendida al dispositivo de red; y
    enviar (110) al otro dispositivo una descripción de dispositivo extendida de longitud variable si está disponible la descripción de dispositivo extendida.
  9. 9. Dispositivo de red, que incluye:
    un transceptor (8) para enviar y recibir mensajes: y
    un gestor (26, 182) de mensajes dispuesto para llevar a cabo las etapas de:
    al recibir (104) un mensaje de consulta de descripción de dispositivo sencilla desde uno de los otros dispositivos, enviar (106) al otro dispositivo un mensaje de descripción de dispositivo sencilla de longitud definida que incluye un valor de tipo de dispositivo que representa el tipo del dispositivo de red y un campo que indica si está disponible una descripción de dispositivo extendida; estando caracterizado por:
    al recibir (108) un mensaje de consulta de descripción de dispositivo extendida desde otro dispositivo, enviar (110) al otro dispositivo una descripción de dispositivo extendida de longitud variable si está disponible la descripción de dispositivo extendida.
  10. 10.
    Dispositivo de red según la reivindicación 9, en el que el mensaje (230) de descripción de dispositivo sencilla es en forma de mensaje comprimido en testigo, comprimido a partir de un formato de mensaje legible por humanos, incluyendo el mensaje un valor (232) de tipo de dispositivo que representa el tipo del otro dispositivo; seleccionándose el valor de tipo de dispositivo a partir de una jerarquía de tipos de dispositivos que tiene elementos de nivel superior predeterminados que incluyen un tipo (52) de dispositivo controlador y un tipo (54) de dispositivo básico, y al menos un nivel adicional de tipos de dispositivos subsidiarios que dependen del tipo de dispositivo básico y que heredan propiedades de los tipos de dispositivos de nivel superior de los que depende el tipo de dispositivo subsidiario, pero sin incluir ningún nivel adicional de tipos de dispositivos subsidiarios que dependen del tipo de dispositivo controlador.
  11. 11.
    Dispositivo de red, que incluye:
    un transceptor (8) para enviar y recibir mensajes:
    un gestor (26, 182) de mensajes dispuesto para llevar a cabo las etapas de:
    enviar un mensaje de consulta de descripción de dispositivo sencilla a otro dispositivo solicitando una descripción de dispositivo sencilla; y
    recibir desde el otro dispositivo un mensaje de descripción de dispositivo sencilla de longitud fija que incluye un valor de tipo de dispositivo que representa el tipo del otro dispositivo y un campo que indica si está disponible una descripción de dispositivo extendida;
    y caracterizado porque está además dispuesto para llevar a cabo las etapas de:
    someter a prueba el mensaje de descripción de dispositivo sencilla para determinar si está disponible una descripción de dispositivo extendida;
    enviar un mensaje de consulta de descripción de dispositivo extendida al otro dispositivo solicitando una descripción de dispositivo extendida al otro dispositivo; y
    recibir desde el otro dispositivo una descripción de dispositivo extendida de longitud variable, si está disponible la descripción de dispositivo extendida.
  12. 12.
    Dispositivo de red según la reivindicación 11, en el que el mensaje (230) de descripción de dispositivo sencilla es en forma de mensaje comprimido en testigo, comprimido a partir de un formato de mensaje legible por humanos, incluyendo el mensaje un valor (232) de tipo de dispositivo que representa el tipo del otro dispositivo; seleccionándose el valor de tipo de dispositivo a partir de una jerarquía de tipos de dispositivos que tiene elementos de nivel superior predeterminados que incluyen un tipo (52) de dispositivo controlador y un tipo (54) de dispositivo básico, y al menos un nivel adicional de tipos de dispositivos subsidiarios que dependen del tipo de dispositivo básico y que heredan propiedades de los tipos de dispositivos de nivel superior de los que depende el tipo de dispositivo subsidiario, pero sin incluir ningún nivel adicional de tipos de dispositivos subsidiarios que dependen del tipo de dispositivo controlador.
  13. 13.
    Dispositivo de red según la reivindicación 12, teniendo el dispositivo de red el tipo de dispositivo controlador,
    comprendiendo el dispositivo de red una lista de tipos de dispositivos que pueden controlarse por el dispositivo de red, de modo que el dispositivo de red puede determinar en qué medida el dispositivo de red puede controlar otro dispositivo determinando el nivel más bajo de tipo de dispositivo que o bien es el tipo de dispositivo del otro dispositivo o bien es un tipo de dispositivo de nivel superior del que depende el tipo de dispositivo del otro dispositivo, en la lista de tipos de dispositivos que pueden controlarse por el controlador.
  14. 14.
    Dispositivo de red según la reivindicación 13, en el que el gestor de mensajes está dispuesto para:
    recibir un mensaje de consulta de controlador desde otro dispositivo que incluye un valor de tipo de dispositivo solicitado para solicitar si el controlador puede controlar un dispositivo del tipo de dispositivo solicitado; y
    responder con un mensaje de respuesta de controlador que incluye un valor de tipo de dispositivo que representa el nivel más bajo de tipo de dispositivo en la lista de tipos de dispositivos que o bien es el tipo de dispositivo solicitado o bien es un tipo de dispositivo de nivel superior del que depende el tipo de dispositivo solicitado.
  15. 15.
    Sistema, que comprende un dispositivo de red según la reivindicación 9 y un dispositivo de red según la reivindicación 11.
  16. 16.
    Sistema según la reivindicación 15, en el que la pluralidad de dispositivos de red incluyen al menos un dispositivo sencillo sin la capacidad de descomprimir mensajes e interpretar directamente mensajes comprimidos y al menos un dispositivo complejo que incluye una disposición (184) de descompresión de mensajes para descomprimir los mensajes y un intérprete de mensajes para interpretar los mensajes descomprimidos.
  17. 17.
    Sistema según la reivindicación 15 ó 16, en el que los elementos de nivel superior predeterminados incluyen además un tipo de dispositivo compuesto;
    incluyendo el sistema al menos un dispositivo de red del tipo de dispositivo compuesto que tiene la funcionalidad de un número predeterminado de otros dispositivos, siendo el número predeterminado un número entero mayor que o igual a 2; y
    cada uno del al menos un dispositivo de red del tipo de dispositivo compuesto responde a un mensaje de consulta de dispositivo entrante que requiere una descripción de dispositivo sencilla enviando una descripción (230) de dispositivo sencilla que incluye el tipo (232) de dispositivo como dispositivo compuesto y un número (234) de subdispositivo que representa el número predeterminado de otros dispositivos.
  18. 18.
    Programa informático para controlar un dispositivo de red, estando el programa informático dispuesto para hacer que el dispositivo de red lleve a cabo las etapas de un método según cualquiera de las reivindicaciones 1 a 8.
  19. 19.
    Programa informático según la reivindicación 18, grabado en un soporte (14) de datos.
ES03784356T 2002-08-06 2003-07-24 Protocolo de establecimiento y gestión de red Expired - Lifetime ES2428356T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GB0218174 2002-08-06
GBGB0218174.1A GB0218174D0 (en) 2002-08-06 2002-08-06 A network establishment and management protocol
GB0309401 2003-04-25
GB0309401 2003-04-25
PCT/IB2003/003307 WO2004015956A2 (en) 2002-08-06 2003-07-24 A network establishment and management protocol

Publications (1)

Publication Number Publication Date
ES2428356T3 true ES2428356T3 (es) 2013-11-07

Family

ID=31716913

Family Applications (1)

Application Number Title Priority Date Filing Date
ES03784356T Expired - Lifetime ES2428356T3 (es) 2002-08-06 2003-07-24 Protocolo de establecimiento y gestión de red

Country Status (9)

Country Link
US (2) US8078742B2 (es)
EP (1) EP1529379B1 (es)
JP (1) JP2005535247A (es)
KR (1) KR101058065B1 (es)
CN (1) CN100525223C (es)
AU (1) AU2003249528A1 (es)
DK (1) DK1529379T3 (es)
ES (1) ES2428356T3 (es)
WO (1) WO2004015956A2 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0411528D0 (en) * 2004-05-24 2004-06-23 Koninkl Philips Electronics Nv Device abstraction layer for local networking system
KR100702516B1 (ko) * 2006-04-07 2007-04-02 삼성전자주식회사 디.엘.엔.에이 네트워크를 이용한 데이터 저장 방법 및 그장치
US20120311070A1 (en) * 2011-05-31 2012-12-06 Fanhattan Llc Intelligent application adapted to multiple devices
CN105264924B (zh) 2012-11-12 2019-04-02 埃姆皮公司 用于电刺激的无线配对和通信的系统及方法
US10313831B2 (en) 2014-05-09 2019-06-04 Futurewei Technologies, Inc. Extensible solution for device to device discovery message size
US10623244B2 (en) 2014-12-19 2020-04-14 Emerson Process Management Lllp Data transfer on an industrial process network
KR102442428B1 (ko) * 2015-09-24 2022-09-14 삼성전자주식회사 다바이스의 액세스 토큰 발급 방법 및 이를 지원하는 장치
CN111061207A (zh) * 2019-12-25 2020-04-24 湖南舞龙软件开发有限公司 一种基于数据驱动的设备描述方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002505060A (ja) * 1997-06-16 2002-02-12 テレフオンアクチーボラゲツト エル エム エリクソン 電気通信性能管理システム
US5991713A (en) * 1997-11-26 1999-11-23 International Business Machines Corp. Efficient method for compressing, storing, searching and transmitting natural language text
AU758868B2 (en) 1998-05-07 2003-04-03 Samsung Electronics Co., Ltd. Method and apparatus for universally accessible command and control information in a network
WO2000068824A1 (en) * 1999-05-10 2000-11-16 3Com Corporation Method and system for network management
US6910068B2 (en) * 1999-06-11 2005-06-21 Microsoft Corporation XML-based template language for devices and services
US7171475B2 (en) * 2000-12-01 2007-01-30 Microsoft Corporation Peer networking host framework and hosting API
US6832273B2 (en) * 2000-12-21 2004-12-14 Microsoft Corporation System and method to specify extended configuration descriptor information in USB devices
WO2003021978A1 (en) * 2001-08-10 2003-03-13 Strix Systems, Inc. Virtual linking using a wireless device
US7299304B2 (en) * 2001-11-20 2007-11-20 Intel Corporation Method and architecture to support interaction between a host computer and remote devices
US7058734B2 (en) * 2002-02-25 2006-06-06 Hewlett-Packard Development Company, Lp. Variable-function or multi-function apparatus and methods
US6930958B2 (en) * 2002-04-02 2005-08-16 Nate Goergen Method and apparatus for synchronizing timekeeping devices
US8312132B2 (en) * 2004-08-20 2012-11-13 Core Wireless Licensing S.A.R.L. Context data in UPNP service information

Also Published As

Publication number Publication date
EP1529379B1 (en) 2013-07-17
KR101058065B1 (ko) 2011-08-22
JP2005535247A (ja) 2005-11-17
AU2003249528A1 (en) 2004-02-25
WO2004015956A2 (en) 2004-02-19
WO2004015956A3 (en) 2004-09-16
KR20050084796A (ko) 2005-08-29
US20120059898A1 (en) 2012-03-08
CN1675886A (zh) 2005-09-28
CN100525223C (zh) 2009-08-05
EP1529379A2 (en) 2005-05-11
US20060026291A1 (en) 2006-02-02
US8943213B2 (en) 2015-01-27
AU2003249528A8 (en) 2004-02-25
DK1529379T3 (da) 2013-10-14
US8078742B2 (en) 2011-12-13

Similar Documents

Publication Publication Date Title
US8943213B2 (en) Network establishment and management protocol
US8874689B2 (en) Network establishment and management protocol
US9215551B2 (en) Resource management in machine to machine networks
AU2013379634B2 (en) Operation trigger method and device for machine-to-machine communications
US20060031570A1 (en) Network establishment and management protocol
US20120296999A1 (en) Dynamic object management protocol
US20060072477A1 (en) Using configuration identifiers for communicating configuration descriptions
Moazzami et al. SPOT: A smartphone-based platform to tackle heterogeneity in smart-home IoT systems
WO2021244456A1 (zh) 反向地址解析方法及电子设备
Van den Bossche et al. Specifying an MQTT tree for a connected smart home
US20060031192A1 (en) Network establishment and management protocol
US10542585B2 (en) Gateway using resource directory
Antonopoulos et al. On developing a novel versatile framework for heterogeneous home monitoring WSN networks
KR20180025174A (ko) 사물인터넷 디바이스 연동 장치 및 방법
Herzog et al. A3ME—generic middleware for information exchange in heterogeneous environments
Russo Service discovery for ip-based wireless sensor networks
Barisic et al. Position paper submitted to Workshop “Interconnecting Smart Objects with the Internet”