Embed Size (px)
Citation preview
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
31
Capítulo 3 TECNOLOGÍA UPNP
Una de las tendencias tecnológicas para el futuro próximo es que los dispositivos
del hogar permitirán conectarse fácilmente entre sí. La necesidad de
interconexión entre los dispositivos de electrónica de consumo y facilitar su uso
a los usuarios es un campo de trabajo con mucha proyección actualmente.
Dentro de una red domótica se pueden separar tres redes con fines distintos:
La red de control, que está destinada al control de sensores, actuadores y
electrodomésticos inteligentes.
La red de datos, destinada a la conexión de ordenadores entre sí y con
sus periféricos.
La red multimedia, una red de alta capacidad utilizada para los aparatos
electrónicos inteligentes para compartir grandes volúmenes de
información.
Las tres arquitecturas más relevantes para la red multimedia son HAVi12, Jini13 y
UPnP, que presentan básicamente las mismas características pero están
apoyadas por diferentes compañías del sector.
UPnP es un conjunto de protocolos o arquitectura muy extendida, propuesta por
Microsoft y promulgada por el UPnP Forum [13] que permite que varios
dispositivos de red se configuren por sí mismos. Las objetivos de UPnP son
permitir a los dispositivos comunicarse entre sí y simplificar la implementación
de redes en el hogar (intercambio de datos, comunicaciones y entretenimiento) y
entornos corporativos. Es una arquitectura abierta y distribuida basada en
protocolos y especificaciones preexistentes, tales como UDP, SSDP, SOAP, XML,
además se apoya sobre la pila de protocolos TCP/IP de Internet que, de forma
12 Home Audio Video Interoperability.
13 http://www.jini.org
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
32
independiente al fabricante, sistema operativo y lenguaje de programación
permite a las aplicaciones de los dispositivos conectados a una red controlar,
negociar e intercambiar información y datos de forma sencilla y transparente al
usuario, evitando así que tenga que ser un experto en la configuración de redes,
dispositivos o sistemas operativos. Además, la tecnología UPnP es independiente
del medio físico, pudiendo trabajar sobre la línea telefónica, red eléctrica de baja
tensión, Ethernet, radiofrecuencia e IEEE 1394.
La principal característica de la arquitectura UPnP es que es capaz de detectar
cuando se conecta un nuevo equipo o dispositivo a la red, asignándole una
dirección IP, un nombre lógico, informando a los demás de sus funciones y
capacidad de procesamiento, e informarle, a su vez, de las funciones y
prestaciones de los demás. De esta forma, se alivia al usuario de la configuración
de la red y de los dispositivos. UPnP se encarga de todos estos procesos cada vez
que se conecta o se desconecta un equipo.
El hogar digital basado en UPnP prevé abarcar redes cableadas e inalámbricas,
dispositivos de entretenimiento, equipos telefónicos, control del hogar, y
muchos dispositivos más, uniendo varias redes domésticas en una única red
lógica de dispositivos programables (Figura 3-1).
Figura 3-1: Integración UPnP
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
33
3.1 DESCRIPCIÓN DE LA TECNOLOGÍA UPNP
La arquitectura UPnP es un conjunto de estándares abiertos y tecnologías para
conectar de forma transparente los aparatos, equipos y servicios, ampliando el
concepto de Plug and Play para soportar descubrimiento, configuración y
control. El UPnP Forum está comprometido con la interoperabilidad de los
dispositivos en muchos ámbitos y ha establecido grupos de trabajo para:
automatización del hogar y seguridad, pasarelas de Internet, imagen e
impresión, audio/vídeo, dispositivos móviles y electrodomésticos.
UPnP se construye sobre protocolos y tecnologías existentes. UPnP usa
protocolos como TCP/IP, UDP/IP, HTTP como base. Sobre estos, se hace uso de
otros protocolos para implementar las distintas fases o procedimientos de la red
UPnP.
La Figura 3-2 se muestra la pila de protocolos usada por la arquitectura UPnP.
Figura 3-2: Arquitectura de UPnP
La arquitectura UPnP utiliza el modelo de “protocolo de Internet abierto”. En
esta arquitectura los proveedores de dispositivos no están obligados a aplicar la
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
34
tecnología de un único fabricante, ya que se intenta garantizar el correcto
funcionamiento de los dispositivos con productos de diversos fabricantes.
Las ventajas para los desarrolladores son obvias, la elección del lenguaje y del
sistema operativo les da flexibilidad para elegir la mejor plataforma para su
dispositivo a la vez que, en principio, sus productos serán capaces de interactuar
con otros dispositivos que también sigan el estándar UPnP.
3.1.1 PROTOCOLOS
A continuación se describen, de forma breve, cada uno de los protocolos que
están presentes en la pila de protocolos UPnP.
3.1.1.1 TCP/IP
TCP/IP (Transmission Control Protocol/Internet Protocol) es la base sobre la cual
se desarrolla el resto de protocolos de UPnP. TCP/IP es un conjunto de
protocolos que permite abarcar distintos medios físicos y proporcionar
compatibilidad entre múltiples fabricantes. Se basa en la noción de dirección IP,
esto es, en la idea de brindar una etiqueta numérica a cada equipo que se
conecta a la red. TCP es un protocolo del nivel de transporte orientado a
conexión y fiable.
3.1.1.2 UDP/IP
UDP (User Datagram Protocol) es la base sobre la que se sustenta el envío de
mensajes HTTPU y HTTPMU, ya que permite el envío de datagramas sin que haya
establecida una comunicación previa.
3.1.1.3 HTTP, HTTPU, HTTPMU
HTTPU y HTTPMU son variantes de HTTP, en concreto, HTTP unicast y HTTP
multicast respectivamente. Estas variantes son utilizadas para la entrega de
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
35
mensajes sobre UDP/IP en los casos en los que se use multicast o no sea
necesario establecer una conexión.
3.1.1.4 SSDP
El Protocolo de Descubrimiento Sencillo de Servicios (Simple Service Discovery
Protocol) es un protocolo que permite la búsqueda de dispositivos UPnP en una
red. Detecta dispositivos y servicios en red que usan el protocolo de detección
SSDP, como los dispositivos UPnP. También anuncia dispositivos y servicios SSDP
que se ejecutan en el equipo local.
3.1.1.5 GENA
La Arquitectura de Notificación de Eventos Generales (Generic Event Notification
Architecture) permite enviar y recibir notificaciones usando HTTP sobre TCP/IP y
HTTPMU sobre UDP/IP. El multicast UDP es útil puesto que permite que una
misma notificación se distribuya a un grupo potencialmente numeroso de
receptores utilizando una sola petición. GENA define los conceptos de suscriptor
y publicador de notificaciones que posibilitan el mecanismo de eventos, usado
por UPnP para avisar de cambios en el estado de los servicios. Cuando se
produce una suscripción a un servicio, éste envía mensajes de eventos
notificando de cambios en el estado del dispositivo. Estos mensajes de eventos
tienen formato XML. Además de esto, GENA también se utiliza para crear
mensajes de anuncio de presencia para ser enviados mediante SSDP.
3.1.1.6 SOAP
El Protocolo de Acceso Sencillo a Objetos (Simple Object Acces Protocol)
proporciona un mecanismo estándar para empaquetar mensajes. Define cómo
dos objetos en diferentes procesos pueden comunicarse por medio de
intercambio de datos XML. De esta forma, en UPnP se hace uso de XML y HTTP
para ejecutar llamadas a procedimientos remotos (RPC), enviando mensajes de
control a dispositivos y recogiendo los resultados o los errores en cada caso.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
36
Cada petición de control es un mensaje SOAP que contiene la acción invocada y
el conjunto de parámetros necesarios, y su respuesta es otro mensaje del mismo
tipo con el estado o resultado de la acción del dispositivo al que se le solicitó la
petición. Aunque existen multitud de protocolos creados para facilitar la
comunicación entre aplicaciones (RPC de Sun, DCE de Microsoft, RMI de Java y
ORPC de CORBA) SOAP se está convirtiendo en el estándar para la comunicación
basada en RPC por Internet. Entre sus ventajas podemos citar: no está asociado
con ningún lenguaje, no se encuentra fuertemente asociado a ningún de
transporte, no está atado a ninguna infraestructura de objeto distribuido,
aprovecha los estándares existentes en la industria y permite la interoperabilidad
entre múltiples entornos.
3.1.1.7 XML
El Lenguaje de Etiquetado Extensible (Extensible Markup Language) juega un
papel fundamental en el intercambio de datos. Es un lenguaje muy similar a
HTML pero su función principal es describir datos y no mostrarlos como es el
caso de HTML. XML es un formato que permite la lectura de datos a través de
diferentes aplicaciones, concretamente permite estructurar, almacenar e
intercambiar información. En UPnP se usa para las descripciones de dispositivos
y servicios, mensajes de control y eventos.
3.1.2 COMPONENTES DE UNA RED UPNP
Una red UPnP define varios tipos de componentes. Estos componentes incluyen
puntos de control, dispositivos y servicios. A continuación se describen estos
elementos.
3.1.2.1 Dispositivos
Los dispositivos UPnP (Figura 3-3) son contenedores lógicos para un servicio o
conjunto de servicios, y en ocasiones para otros dispositivos (dispositivos
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
37
integrados). Los dispositivos embebidos pueden ser descubiertos y usados
independientemente del dispositivo contenedor principal. Cada dispositivo UPnP
puede ofrecer cualquier cantidad de servicios. Por sí mismo, un dispositivo no
hace más que proporcionar una descripción propia de su información, tal como
el fabricante, el nombre del modelo, y número de serie. Los servicios del
dispositivo son los que proporcionan la funcionalidad real.
Figura 3-3: Diagrama UML de dispositivo UPnP
Existen diferentes categorías de dispositivos UPnP, estandarizados en función del
conjunto de servicios que proporciona el dispositivo. Esta información, junto con
las propiedades como las que se hizo referencia anteriormente, se guarda en un
documento XML de descripción que el dispositivo debe alojar para enviarlo
cuando sea necesario.
3.1.2.2 Servicios
Cada servicio (Figura 3-4) en un dispositivo UPnP puede contener cualquier
número de acciones, una acción tiene un nombre, un conjunto de parámetros de
entrada y un valor de retorno opcional. Cada argumento tiene un nombre, un
valor y una dirección. La dirección puede ser de entrada o de salida,
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
38
dependiendo de si el argumento es pasado a la acción o si es devuelto desde la
acción como resultado.
Un servicio posee un identificador de servicio (URI) que lo identifica, de forma
unívoca, de entre el conjunto de servicios presentes. Puede mantener las
variables que representan el estado actual de ese servicio. Estas variables de
estado tienen un nombre, un tipo, un valor por defecto y un valor actual, y
presentan un rango de valores admisibles. Si una variable dispara un evento para
indicar un estado, esa variable es denomina de notificación de evento (evented).
Un servicio consiste en una tabla de estado, un servidor de control y un servidor
de notificación de eventos. La tabla de estado contiene las variables que se
actualizan cuando ocurre algún cambio en el estado del servicio. El servidor de
control recibe solicitudes de acción, las lleva a cabo, actualiza la tabla de estado y
devuelve el resultado. El servidor de notificación de eventos publica
actualizaciones de los cambios en el estado del servicio.
Figura 3-4: Diagrama UML de servicio UPnP
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
39
3.1.2.3 Punto de control
Un punto de control es una entidad de red que invoca la funcionalidad de un
dispositivo (Figura 3-5). Es capaz de descubrir y controlar a otros dispositivos y en
términos de cliente-servidor en una red UPnP, el punto de control se considera el
cliente y la función de servidor se refleja en el dispositivo.
Figura 3-5: Punto de control invoca acción
Una vez que el punto de control encuentra el dispositivo es capaz de:
Conseguir la descripción del dispositivo y la lista de servicios asociados.
Conseguir las descripciones de los servicios en los que está interesado.
Invocar acciones para controlar el servicio.
Suscribirse a los eventos del servicio. Siempre que cambie el estado del servicio, el servidor de notificación de eventos enviará un evento al punto de control.
En definitiva, un punto de control descubre los dispositivos, invoca las acciones
relativas a sus servicios y se suscribe a las notificaciones de eventos. Por el
contrario, un dispositivo responde a las acciones invocadas por el punto de
control y envía los eventos cuando las variables cambian de estado.
3.2 FUNCIONAMIENTO DE UPNP
Para describir el funcionamiento de UPnP vamos a basarnos en el desarrollo de
seis pasos o etapas básicas: Direccionamiento, Descubrimiento, Descripción,
Control, Notificación de Eventos y Presentación.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
40
3.2.1 DIRECCIONAMIENTO
Debido a que todas las comunicaciones de UPnP se apoyan sobre el famoso
Protocolo de Internet (IP), un dispositivo debe obtener una dirección IP antes de
que pueda unirse a una red compatible con UPnP. En esto precisamente consiste
el primer paso, también conocido como fase cero, conseguir una dirección para
los dispositivos y puntos de control conectados a la red. Todos los razonamientos
que se exponen en esta fase son válidos tanto para los dispositivos como para los
puntos de control.
El direccionamiento es el proceso por el cual un dispositivo adquiere
automáticamente una dirección IP. Permite a un dispositivo unirse a la red y
prepararse para establecer comunicaciones con otros dispositivos y puntos de
control. Los protocolos de direccionamiento implementados en los dispositivos
UPnP permiten que estos puedan unirse a una red IP dinámicamente y adquirir
una dirección sin necesidad de configuración por parte del usuario.
Los dispositivos UPnP pueden utilizar el protocolo DHCP14, basado en UDP, para
recuperar una dirección IP de un servidor DHCP. Para ello tanto dispositivos
como puntos de control deben disponer de un cliente DHCP. Al ser conectados a
la red, lo primero que deben hacer es buscar un servidor DHCP que les
proporcione una dirección. Si existe este servidor en la red, deben utilizar la
dirección que les sea asignada.
Si la red no dispone de un servidor DHCP, se debe usar el direccionamiento IP
automático (Auto-IP) para obtener la dirección IP. Mediante este mecanismo, el
dispositivo toma una dirección de forma aleatoria dentro del rango 169.254/16,
minimizando así posibles colisiones con otros dispositivos. Este rango es
14 Dynamic Host Configuration Protocol.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
41
establecido por la ICANN15 para la auto-configuración de IP en redes privadas.
Una vez asignada la dirección IP mediante Auto-IP, se debe comprobar que no
está siendo usada por ningún otro elemento dentro de la red mediante el uso de
ARP16. Cada dispositivo debe verificar periódicamente la existencia de un
servidor DHCP en la red, para gestionar el procedimiento de direccionamiento.
En tal caso, se descarta la IP asignada de forma automática y se procede con la
asignación dinámica haciendo uso del servidor DHCP.
En principio, un dispositivo o punto de control intenta ponerse en contacto con
un servidor DHCP para obtener una dirección IP. Si no consigue localizar al
servidor, el dispositivo hace uso de Auto-IP, lo que permite a los dispositivos
seleccionar direcciones sin que se encuentre presente un servidor que las asigne.
Puede resultar necesaria la resolución de nombres a direcciones IP debido a que
los dispositivos pueden implementar capas de protocolo superiores a UPnP. Para
poder disponer de esta funcionalidad los dispositivos deben incorporar un cliente
DNS y soportar el registro dinámico de DNS.
3.2.2 DESCUBRIMIENTO
La fase de descubrimiento (Figura 3-6) define como un dispositivo anuncia su
presencia y de que forma los puntos de control lo descubren. Un dispositivo
UPnP es un elemento de la red que puede ser descubierto y controlado por un
punto de control. El proceso de descubrimiento permite a los puntos de control
encontrar los dispositivos y servicios de interés y obtener información acerca de
ellos. Los dispositivos utilizan SSDP para anunciar sus servicios a los puntos de
control, y los puntos de control lo utilizan para buscar dispositivos.
15 Internet Corporation for Assigned Names and Numbers.
16 Address Resolution Protocol.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
42
Figura 3-6: Protocolos. Fase de Descubrimiento
Una vez que un dispositivo ha adquirido una dirección IP, el protocolo SSDP
permite dar a conocer sus servicios a los puntos de control de la red. Del mismo
modo, cuando se agrega un punto de control a la red, el protocolo SSDP permite
la búsqueda de los dispositivos de interés en la red. Estos contestarán en caso de
que exista coincidencia con el criterio del mensaje de búsqueda. El mensaje que
se intercambian en ambos casos es un mensaje de descubrimiento que contiene
detalles esenciales acerca del dispositivo o sus servicios, tales como el tipo de
dispositivo, el identificador, y un puntero a una información más detallada.
En la Figura 3-7 se representa el proceso en el que un nuevo dispositivo anuncia
su presencia, proporciona sus descripciones y ejecuta las acciones invocadas por
un punto de control.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
43
Figura 3-7: Descubrimiento
Se debe tener en cuenta que cuando un dispositivo o punto de control se
inicializa y se une a la red, debe esperar un tiempo aleatorio de entre 300 y 3000
milisegundos antes de mandar ningún mensaje de descubrimiento. Estos rangos
se han fijado así para evitar problemas cuando muchos dispositivos se conectan
a la red al mismo tiempo (300 ms) y para minimizar retrasos en la recuperación
de una red (3000 ms).
Cada dispositivo en sus respuestas de anuncio y descubrimiento incluye una URL
de su documento XML de descripción de dispositivo, a través de la cual, se
proporciona a los puntos de control la información necesaria para recuperar las
descripciones de los dispositivos y sus servicios.
Todos los servicios contenidos en un dispositivo presentan tres direcciones URL,
que proporcionan la información necesaria para que los puntos de control se
comuniquen con ellos:
La URL de Control es donde el punto de control envía peticiones para
controlar el servicio. Los fabricantes de dispositivos UPnP especifican una
para cada dispositivo.
La URL de Suscripción a Eventos, como su propio nombre indica, es donde
los puntos de control envían solicitudes para suscribirse a eventos. Hay
una URL de este tipo por servicio dentro de cada dispositivo. Si un
servicio no tiene variables de eventos (variables evented), y por tanto no
tiene notificación de eventos, el elemento URL de Suscripción a Eventos
debe aparecer, pero estará vacío.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
44
La URL de descripción indica a los puntos de control la localización desde
la que recuperar el documento de descripción de servicio. El documento
de descripción de servicios es devuelto a través de una petición HTTP de
tipo GET.
Un punto de control tiene dos posibilidades en cuanto a la búsqueda de
dispositivos, por un lado puede recoger un mensaje de anuncio enviado por un
dispositivo, y por otro, puede solicitar la respuesta del dispositivo utilizando un
mensaje de descubrimiento enviado por el propio punto de control.
Los dispositivos deben refrescar sus mensajes de anuncio cada cierto tiempo, ya
que tienen un tiempo de vida limitado. Por este motivo no están obligados a
cancelar los mensajes que mandaron previamente anunciando sus capacidades
al desconectarse de la red.
3.2.2.1 Anuncio
Una vez que un dispositivo se une a la red, anuncia sus dispositivos embebidos y
servicios a los puntos de control mediante mensajes NOTIFY definidos por GENA
de tipo multicast y usando el protocolo SSDP. Estos mensajes se envían a la
dirección y puerto (239.255.255.250:1900) por defecto, indicados por ICANN
para uso con el protocolo SSDP. Los puntos de control se dedican a escuchar por
este puerto los mensajes que llegan, conociendo así las capacidades de las que
se disponen en la red. Estos mensajes no requieren de respuesta alguna. Un
detalle a tener en cuenta respecto a los mensajes de anuncio es el tiempo de
validez del mismo, que indica el periodo en que el dispositivo se encuentra
disponible. Tras concluir ese periodo sin reenviar un mensaje de anuncio con la
nueva duración, el dispositivo dejará de estar disponible en la red.
Durante el proceso de anuncio, y considerando que un dispositivo raíz tiene d
dispositivos integrados y ofrece k tipos de servicios distintos, se envían un total
de 3+2d+k mensajes de anuncios a la red. Esto se puede deducir, suponiendo
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
45
dispositivos distintos, interpretando el número de mensajes que debe enviar un
dispositivo:
Un mensaje por cada tipo de servicio con NT = tipo de servicio.
Un mensaje por cada tipo de dispositivo (raíz o integrado) con NT = tipo
de dispositivo.
Un mensaje por cada dispositivo (raíz o integrado) con NT = UUID del
dispositivo.
Un mensaje referente al dispositivo raíz con NT = upnp:rootdevice.
Tras conectarse un dispositivo a la red, éste envía un mensaje de anuncio, que es
una petición multicast con el método NOTIFY. Para estos mensajes no es
necesario el envío de respuesta alguna.
Cuando un dispositivo va a dejar de estar disponible en la red, puede enviar un
mensaje, con el método NOTIFY poniendo la directiva ssdp:byebye en la
cabecera NTS, por cada mensaje enviado previamente con ssdp:alive en el NTS.
Estos mensajes con el campo ssdp:byebye no son obligatorios y en caso de no
enviarlos los puntos de control borrarán de la caché toda la información recogida
anteriormente de los mensajes ssdp:alive tras expirar el tiempo indicado por
max-age. En este mensaje de anuncio de desconexión se eliminan algunas
cabeceras innecesarias para el aviso de desconexión y salvo una de ellas, las
demás presentan las mismas características que las explicadas en el mensaje de
anuncio de conexión. En este caso la cabecera NTS presenta la notificación SSDP
con la forma ssdp:byebye.
Tanto para el mensaje de anuncio de conexión como para el de desconexión, en
caso de no indicar el número de puerto en la cabecera HOST, el receptor asumirá
que el puerto SSDP por defecto es el 1900.
3.2.2.2 Búsqueda
Este procedimiento se pone en marcha cuando existe un punto de control que
requiere un tipo de dispositivo o de servicio determinado. Es entonces, cuando el
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
46
punto de control envía un mensaje multicast a la dirección y puerto
especificados en el apartado anterior, 239.255.255.250:1900.
En este caso, al contrario que en el método de anuncio, sí se precisan respuestas,
que serán enviadas por los dispositivos que satisfagan las especificaciones
definidas por el punto de control. Este mensaje de búsqueda es una petición
multicast con el método MSEARCH.
Debido a que los mensajes se envían sobre UDP, que no garantiza la entrega, un
punto de control debe enviar varios mensaje M-SEARCH.
Cuando un dispositivo recibe un mensaje de búsqueda que contiene en la
cabecera ST el campo ssdp:all, upnp:rootdevice, un UUID que coincida con el de
cualquier servicio o dispositivo integrado, o una petición de tipo de dispositivo o
servicio que se corresponde con lo que él ofrece, responde con un mensaje al
punto de control que envió el mensaje M-SEARCH.
El mensaje de respuesta es un mensaje parecido al de anuncio, pero en este caso
es un mensaje unicast, ya que se dispone de un puerto y una dirección conocida
desde donde se mandó el mensaje de búsqueda.
Un punto de control recibirá múltiples mensajes, algunos de ellos serán
respuestas duplicadas. Para filtrar las respuestas, el punto de control utiliza la
cabecera USN que proporciona un identificador único para búsqueda de
respuestas.
3.2.3 DESCRIPCIÓN
La descripción permite a un dispositivo listar las funcionalidades que
proporciona. Las descripciones de los dispositivos y sus servicios se encuentran
almacenados en documentos XML. Un documento de descripción del dispositivo
contiene información tal como: el fabricante, la marca, el modelo y número de
serie, un listado con los servicios prestados por el dispositivo, además de una
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
47
lista con sus dispositivos integrados. Mientras que un documento de descripción
del servicio contiene información detallada acerca del servicio de un dispositivo,
las acciones que el servicio proporciona, los parámetros y el valor devuelto por el
servicio. La pila de protocolos involucrada en la fase de descripción se muestra
en la Figura 3-8.
Figura 3-8: Protocolos. Fase de Descripción
Las respuestas que recibe un punto de control a los mensajes de búsqueda
contienen URLs que proporcionan descripciones de las capacidades del
dispositivo. Los puntos de control utilizan estos documentos de descripción para
obtener más información de los dispositivos, para así conocer sus características
e interactuar con ellos.
La descripción UPnP de un dispositivo se compone de dos partes: la descripción
de dispositivo que hace referencia al contenedor físico y lógico y, por otra parte,
la descripción de servicio que hace referencia a las capacidades que ofrece el
dispositivo. Ambas descripciones son confeccionadas por el fabricante y están
escritas en lenguaje XML. En la Figura 3-9 se muestra un esquema de los
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
48
documentos XML que proporcionan las descripciones del dispositivo y de los
servicios disponibles.
Figura 3-9: Documentos XML descriptivos (dispositivo y servicios)
Los dispositivos además de servicios pueden contener otros dispositivos lógicos.
El documento de descripción UPnP incluye una lista de los dispositivos
integrados y una descripción de los servicios disponibles. Para cada servicio, su
descripción incluye una lista de las acciones a las que el servicio responde y los
argumentos para cada acción.
La descripción de un servicio también incluye una lista de variables que reflejan
el estado del dispositivo. Estas variables son descritas en términos de su tipo de
dato, rango y evento característico.
Para recuperar la descripción de un dispositivo, el punto de control manda una
petición HTTP con el método GET a la URL contenida en el mensaje de
descubrimiento que previamente ha recibido del dispositivo. Cuando éste recibe
la petición responde con un mensaje HTTP que contiene la descripción del
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
49
dispositivo en el cuerpo del mensaje (el esquema de esta fase de descripción de
representa en la Figura 3-10). En esta descripción se incluyen las URLs de la
descripción de los servicios que contiene el dispositivo. La información contenida
en la descripción de dispositivo consiste en:
Un documento XML que contiene las características del dispositivo en
concreto.
Definiciones de todos los dispositivos anidados.
Una lista de todos los servicios soportados por el dispositivo, incluyendo
variables de estado y acciones.
El punto de control puede mandar otra petición HTTP con las URLs de
descripción de servicios para obtener las descripciones de servicio.
Figura 3-10: Descripción
Si en la cabecera HOST del mensaje de petición no viene definido el número de
puerto, se tomará por defecto el 80.
Por cada servicio que contenga un dispositivo, su descripción contendrá, además
de lo ya expuesto lo siguiente: el nombre y tipo del servicio, URL de descripción
del servicio, URL para control y URL para notificación de eventos. Por último, la
descripción de dispositivo también presenta una descripción de todos los
dispositivos anidados y una URL para presentación.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
50
Se recuerda que el contenido de una descripción de servicio incluye una lista de
acciones y parámetros para las mismas, una lista de variables que indican el
estado del servicio y se fija el rango, tipo de dato y si tienen capacidad de
notificar eventos.
3.2.4 CONTROL
Control es la fase de UPnP en la que los puntos de control invocan acciones a los
servicios de los dispositivos. Una vez que un punto de control dispone de toda la
información acerca de un dispositivo y uno de sus servicios mediante sus
descripciones, será capaz de controlar dicho servicio invocando acciones. La pila
de protocolos sobre la que se sustenta la fase de control en el funcionamiento de
UPnP se muestra en la Figura 3-11.
Figura 3-11: Protocolos. Fase de Control
Para el control de dispositivo, UPnP se basa en el protocolo SOAP, que hace uso
de XML y HTTP para proporcionar mensajería web y llamadas a procedimientos
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
51
remotos. XML expresa el contenido del mensaje y HTTP envía mensajes a su
destino. SOAP consta de cuatro partes:
Sobre extensible obligatorio para encapsular los datos. El sobre SOAP
define un mensaje SOAP y es la unidad básica de intercambio entre los
procesadores de mensajes SOAP. Ésta es la única parte obligatoria de la
especificación.
Reglas opcionales de codificación de datos para representar tipos de
datos definidos por la aplicación.
Enlace entre SOAP y HTTP. Esta parte también es opcional, ya que se
puede utilizar SOAP en combinación con cualquier protocolo de
transporte o mecanismo que pueda transportar el sobre SOAP.
Modelo de intercambio de mensajes RPC (solicitud/respuesta). Es una
convención para representar llamadas a procedimiento remoto y sus
respuestas.
Para invocar una acción, el punto de control envía un mensaje a la URL de
control que conoce de la fase de descripción estudiada en el apartado anterior.
El dispositivo responderá con el resultado o los errores de ejecutar la acción del
servicio (Figura 3-12). Además esta acción puede alterar el estado del servicio y
por tanto producir un cambio en alguna de sus variables.
Figura 3-12: Fase de Control
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
52
Para invocar una acción específica el punto de control debe enviar una petición
SOAP con el método POST al servicio de dispositivo. Este mensaje de control
contiene información específica del fabricante, nombre de la acción, nombres de
los argumentos, y variables que son definidas por el UPnP Forum. La información
viene expresada en formato XML y entre las etiquetas envelope y body, definidas
por SOAP para la llamada a procedimientos remotos, se incluyen el nombre de la
acción invocada y los argumentos que sean necesarios.
En caso de que el envío del mensaje anterior sea rechazado con el código 405
(Method Not Allowed), el punto de control deberá realizar otra petición, pero
esta vez la petición SOAP utilizará el método M-POST, dejando el cuerpo del
mensaje igual al de la anterior petición.
Tras recoger este mensaje, el servicio replicará con una respuesta HTTP. Si la
petición puede ser completada en 30 segundos, incluyendo el tiempo esperado
de transmisión, la respuesta contendrá el resultado de la acción. En caso
contrario, el dispositivo enviará una respuesta sin datos completos y
posteriormente lanzará un evento cuando la petición esté terminada.
Si la ejecución de la acción se desarrolla de manera adecuada el dispositivo
responderá con un mensaje HTTP con el método 200 OK. En cambio, si se
produce algún error se responderá con alguno de los códigos de error recogidos
en la Tabla 3-1.
CÓDIGO DE ERROR ERROR DESCRIPCIÓN DEL ERROR
401 Invalid Action No existe dicha acción
402 Invalid Args Argumentos insuficientes, demasiados argumentos, ningún argumento con ese nombre o tipo de argumento no válido
501 Action Failed Fallo al invocar la acción
600 Argument Value Invalid
El valor del argumento no es válido
601 Argument Value Out of Range
El valor del argumento está fuera del rango permitido o no está en la lista de valores permitidos
602 Optional Action Not La acción que se solicita es opcional y no
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
53
Implemented está implementada en el servicio
603 Out of Memory El dispositivo no tiene suficiente memoria para completar la acción
604 Human Intervention Required
El dispositivo ha encontrado una condición que necesita de la intervención del usuario
605 String Argument Too Long
La cadena del argumento es demasiado larga para ser manejada
606 Action not authorized La acción solicitada necesita autorización y el punto de control no la tiene
607 Signature failure Fallo al verificar la firma del solicitante
608 Signature missing La acción solicitada requiere firma digital que no ha sido proporcionada
609 Not encrypted La acción requiere confidencialidad y no ha sido cifrada
610 Invalid Sequence La secuencia proporcionada no es válida
611 Invalid control URL La URL de control no es válida
612 No such session No existe la sesión
600-699 TBD Errores comunes. Definido por los Comités Técnicos del UPnP Forum
700-799 TBD Errores específicos para acciones estándar. Definido por los Comités de Trabajo del UPnP Forum
800-899 TBD Errores específicos para acciones no estándar. Definido por el fabricante
Tabla 3-1: Códigos de errores
Las peticiones de las variables de estado están contempladas en UPnP, pero esta
forma de proceder ha sido desechada por el UPnP Forum y no debe ser usado
por los puntos de control. En su lugar, los Comités de Trabajo y los fabricantes
definen acciones que devuelvan el valor de la variable deseada y que puedan ser
invocadas por los puntos de control.
3.2.5 NOTIFICACIÓN DE EVENTOS
Mediante la notificación de eventos, en UPnP se ofrece la posibilidad de avisar a
un punto de control cuando cambia el estado de un dispositivo.
La pila de protocolos que se usa en esta fase se muestra en la Figura 3-13.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
54
Figura 3-13: Protocolos. Fase de Notificación de Eventos
Como se ha explicado anteriormente, una descripción de servicio contiene una
lista de variables que modelan el estado del servicio. Si alguna de estas variables
es susceptible de ser notificada como evento, variable de estado tipo evented, el
servicio publica actualizaciones cuando se modifican estas variables.
UPnP emplea un sistema de notificación de eventos usando un modelo
publicador/suscriptor en el que los puntos de control pueden suscribirse a
eventos enviados por un servicio, y los servicios publican notificaciones de
eventos a los suscriptores (Figura 3-14).
Figura 3-14: Suscripción y notificación de eventos (1)
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
55
Un evento es un mensaje enviado desde un servicio a los puntos de control
suscritos. Los eventos mantienen informados a los puntos de control interesados
de los cambios de estado asociados al servicio.
Un punto de control que desea recibir notificaciones de cambios en las variables
de estado se suscribe a un origen de eventos mediante el envío de una solicitud
de suscripción a la URL de eventos contenida en la descripción del dispositivo
correspondiente. Esta solicitud de suscripción debe incluir el servicio al que se
quiere suscribir, una URL a la que enviar los eventos y un tiempo de suscripción.
Si un servicio acepta la solicitud de suscripción, responde con un identificador
único de suscripción (SID) y la duración de la suscripción, que indica el tiempo de
validez de la misma. El identificador único permite al punto de control referirse a
la suscripción en sucesivas solicitudes del servicio, tales como la renovación o la
cancelación de la suscripción.
Los mensajes de eventos se envían a todos los suscriptores independientemente
del motivo del cambio de las variables de estado. Estos mensajes contienen
información expresada en lenguaje XML con los nombres y valores de aquellas
variables de estado que estén configuradas en el servicio como variables de
eventos. El protocolo de notificación de eventos es GENA y el uso de TCP
garantiza la entrega del mensaje al suscriptor. Cuando la suscripción caduca, el
identificador de suscripción deja de ser válido, y el servicio deja de enviar
mensajes de eventos al punto de control correspondiente. Si en este momento
ese punto de control intenta enviar cualquier mensaje (renovación o
cancelación) que no sea el de suscripción, el servicio lo rechaza debido a que el
identificador ya no es válido. En la Figura 3-15 se representan los procesos de
envío de mensajes correspondientes a esta fase del funcionamiento de UPnP.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
56
Figura 3-15: Suscripción y notificación de eventos (2)
Para que el punto de control reciba los eventos de un servicio, enviará un
mensaje de suscripción a la URL del servicio deseado. Este mensaje utiliza el
método SUBSCRIBE definido por GENA.
Al recibir este mensaje el servicio confecciona una lista de suscriptores con la
siguiente información para cada uno de ellos: identificador único de la
suscripción (SID), URL de entrega de los mensajes de eventos, contador de
eventos y duración de la suscripción.
Si se acepta la suscripción, el servicio envía un mensaje con el identificador de la
suscripción y el tiempo de validez. Después de este mensaje se debe enviar el
primer mensaje de notificación de eventos, que contendrá los nombres de las
variables y sus valores actuales en lenguaje XML. Además, cada vez que una de
estas variables que están configuradas como evento cambie, el servicio debe
enviar un mensaje de eventos a todos los puntos de control suscritos. Estos
mensajes de notificación de eventos, con el fin de detectar errores, se
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
57
encuentran etiquetados con una clave que es distinta para cada suscriptor. En
cada punto de control, en el mensaje inicial de eventos se inicia esta clave a 0 y
se incrementa con cada mensaje de notificación posterior. Así, si el suscriptor
recibe una notificación con una clave incorrecta, contesta al servicio con un
mensaje de error.
El mensaje de notificación de eventos usa el método NOTIFY definido por GENA.
Se debe responder antes de 30 segundos confirmando la correcta recepción del
mensaje. Si esta confirmación no llega, el servicio desechará esta notificación,
pero seguirá manteniendo la suscripción activa para futuros eventos. La
respuesta del punto de control será simplemente un mensaje HTTP indicando
que se ha recibido de forma adecuada con el método 200 OK.
En caso de que se produzca algún error en el mensaje de eventos, el suscriptor
debe enviar el correspondiente mensaje indicándolo para que el servicio reenvíe
el mensaje. Todas las suscripciones se deben renovar periódicamente para que
los puntos de control sigan recibiendo notificaciones. Para mantener una
suscripción activa, el punto de control debe enviar un mensaje de renovación
antes de que expire el tiempo de suscripción.
El mensaje de renovación se envía a la misma URL que el mensaje original de
suscripción, pero esta vez no se incluye la URL de entrega de los mensajes de
eventos. En su lugar, el mensaje de renovación incluye el identificador de
suscripción recibido en el mensaje inicial de confirmación de la suscripción. La
respuesta a este mensaje es exactamente igual a la respuesta del mensaje de
suscripción.
Cuando un punto de control no quiere recibir más eventos de un servicio, puede
cancelar su suscripción. Esto se hará enviando un mensaje de cancelación HTTP
con el método UNSUBSCRIBE. La respuesta del servicio a este mensaje es, como
en el caso anterior, una confirmación HTTP.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
58
Si el punto de control se desconecta de la red de forma abrupta sin enviar el
mensaje de cancelación de la suscripción, el servicio seguirá enviándole
notificaciones hasta que expire el tiempo de suscripción.
3.2.6 PRESENTACIÓN
En una red UPnP, un punto de control puede controlar un dispositivo o
comprobar su estado a través de la presentación de una página HTML. Una
página de presentación puede ser cargada por el punto de control en un
explorador y permite a los usuarios ver y controlar al dispositivo.
La pila de protocolos involucrada aparece en la Figura 3-16.
Figura 3-16: Protocolos. Fase de Presentación
Las páginas de presentación no son necesarias. Si un dispositivo no tiene página
de presentación, puede ser controlado a través del control estándar de
mensajes. Si el dispositivo permite página de presentación, su documento de
descripción contiene el URL para la página de presentación en la etiqueta
<presentationURL>. Esta etiqueta debe estar presente siempre, si el dispositivo
no tiene página de presentación, la etiqueta estará vacía.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
59
En la fase de presentación el punto de control envía una petición HTTP con el
método GET a la URL de presentación (disponible en la descripción de
dispositivo) y el dispositivo devuelve la página de presentación. Tras cargar la
página en el navegador, el punto de control puede controlar el dispositivo o
comprobar sus variables. Este proceso se representa en la Figura 3-17.
Figura 3-17: Presentación
El mensaje de petición de presentación incluye el campo ACCEPT-LANGUAGE y el
lenguaje de la página de presentación vendrá definido por el campo
CONTENTLANGUAGE definido en el dispositivo.
Un componente adicional de la red UPnP es la capa de aplicación. Las
capacidades de un dispositivo son definidas por el propio dispositivo y los
modelos de servicios que proporcionan el marco para la red de componentes,
descripción, control y eventos. Un fabricante de dispositivos puede preparar esos
modelos por sí mismo, o trabajar con otros fabricantes dentro del UPnP Forum
para preparar el estándar del dispositivo y los modelos de servicio. Actualmente
el comité de trabajo de UPnP ha elaborado definiciones de modelos estándar
que pueden ser adoptados por los fabricantes.
CONTROL E INTEGRACIÓN DE ROVIO BAJO UPNP Tecnología UPnP
60
3.3 CONCLUSIONES: VENTAJAS E INCONVENIENTES
La arquitectura de dispositivos UPnP proporciona un marco común donde los
dispositivos pueden interactuar y construir servicios. La tecnología UPnP es la
base para lograr mayores niveles de automatización e integración.
Las características de la arquitectura de dispositivos UPnP que animan al uso de
esta tecnología en el hogar digital son las siguientes:
No tiene necesidad de configuración previa de los dispositivos, lo que
permite una instalación rápida y un uso fácil para el hogar.
Se basa en protocolos, no en APIs, permitiendo ser verdaderamente
independiente de los medios y la plataforma.
La independencia de medios y dispositivos permiten extender su
funcionamiento sobre cualquier red incluyendo líneas telefónicas, red
eléctrica, WiFi, Ethernet, etc.
La independencia de plataformas, permite usar cualquier lenguaje de
programación o sistema operativo para el desarrollo de productos.
Tecnologías basadas en Internet, está desarrollada sobre IP, TCP, UDP,
HTTP y XML entre otras, de las cuales existe un amplio conocimiento y
son fácilmente integrables.
Aunque está basado en estándares, es flexible y puede satisfacer las
necesidades de los dispositivos que operan en las redes de hoy y del
futuro.
No obstante, esta tecnología también tiene sus inconvenientes:
El uso de UDP en la fase de descubrimiento, con la consiguiente pérdida
de información. Esto queda minimizado en cierta medida con el reenvío
periódico de los mensajes, con lo que se consigue la correcta detección
de los dispositivos a costa de introducir cierto retardo y carga en la red.
La principal desventaja es la seguridad. La falta de un protocolo de
autenticación o de seguridad, posibilita el riesgo de intrusión o infección
de los dispositivos.
![UPnP & Konnex · Das UPnP Forum [UPnP-Forum]ist ein Zusammenschluss führender Hersteller aus der Unterhaltungs- und Computerindustrie. Es wurde im Juni 1999 gegründet und zählt](https://img.pdfslide.tips/doc/110x75/5e1bff200e2a4a15a230d247/upnp-das-upnp-forum-upnp-forumist-ein-zusammenschluss-fhrender-hersteller.jpg)
