Modelo Inter Tecnologías en Entornos Inteligentes Edición Única

Texto completo

(1)Instituto Tecnológico y de Estudios Superiores de Monterrey CAMPUS MONTERREY PROGRAMA DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES. TESIS. MODELO INTER-TECNOLOGÍAS EN ENTORNOS INTELIGENTES PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADÉMICO DE: MAESTRÍA EN CIENCIAS EN TECNOLOGÍAS DE LA INFORMACIÓN POR MARIA TERESA GONZALEZ DIAZ. MONTERREY, N.L.. JUNIO 2006.

(2) Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Monterrey Programa de Graduados en Electrónica, Computación, Información y Comunicaciones Los miembros del comité de tesis recomendamos que la presente propuesta de sea aceptada para desarrollar el proyecto de tesis que es requisito parcial para obtener el grado de Maestro en Ciencias de Tecnologı́a Informática.. Comité de Tesis. Dr. José Raúl Pérez Cázares Asesor Principal. Dr. Raúl V. Ramı́rez Velarde Sinodal. Ing. Pablo Daniel Dı́az López Sinodal. Dr. David A. Garza Salazar Director del Programa de Posgrado en Electrónica, Computación, Información y Comunicaciones Junio de 2006.

(3) MODELO INTER-TECNOLOGÍAS EN ENTORNOS INTELIGENTES. por MARIA TERESA GONZALEZ DIAZ. TESIS. Presentada al Programa de Graduados en Electrónica, Computación, Información y Comunicaciones. Este trabajo es requisito parcial para obtener el grado de Maestro en Ciencias en Tecnologı́a Informática. INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. JUNIO 2006.

(4) Dedicatoria A mis padres y hermanos, Gracias por enseñarme la persistencia y la pasión por buscar la excelencia.. A Salomón, Por mantener de pie este sueño.. Gracias A Dios y todos los que hicieron posible lograr esta meta..

(5) Resumen Los dispositivos móviles son una alternativa de comunicación que en los últimos años han tomado amplia popularidad. Los ambientes móviles representan aspectos de practicidad, comodidad y simplicidad en las soluciones inalámbricas. De la misma manera, las redes domóticas son espacios donde la tecnologı́a puede incursionar para ofrecer soluciones integrales de control, seguridad y comodidad a través de ambientes de comunicación versatiles y potenciales. Asi, ambas tendencias cooperan para formar ambientes inteligentes en los hogares modernos. En esta tesis, se presenta un modelo de integración de usuarios móviles con las aplicaciones en los hogares instaladas en una paserala residencial, denominado Modelo Intertecnologı́as. Se propone una solución integral bajo uno de los estándares más importantes y representativos, como lo es OSGi. Este estándar especifica un framework para instalar e interoperar aplicaciones desarrolladas en java. Sin embargo, no especifica un mecanismo de comunicar y administrar los dispositivos móviles, razón por la cual es necesario proponer un modelo de integración. El modelo propuesto es basado en componentes y orientado a servicios. El objetivo es satisfacer la integración de aplicaciones instaladas en el framework de OSGi y soluciones instaladas en usuarios móviles. El modelo representa una abstración de las caracterı́sticas de los ambientes móviles como lo son la adaptación al contexto y provisión de servicios de manera transparente entre los clientes y el servidor. Además, se define un esquema de interoperabilidad orientado a proveer interfaces genéricas encapsuladas en un WPA (Wireless Personal Access) Middleware de comunicación. El documento es organizado incluyendo un primer capı́tulo referente a la propuesta de investigación. Posteriormente, en el capı́tulo segundo y tercero, se incluyen los antecedentes sobre OSGi y tecnologı́as móviles. En el capı́tulo cuarto se incluye la definición del modelo propuesto y su descripción detallada. En el capı́tulo quinto se integran los resultados y las conclusiones basadas en la implementación de la prueba de concepto del modelo. Finalmente, se incluye la bibliografı́a de referencia que soporta el contenido de la tesis..

(6) Índice general 1. Introducción. 1. 1.1. Planteamiento del Problema . . . . . . . . . . . . . . . . . . .. 2. 1.1.1. Las Arquitecturas y Middleware en Redes Domóticas .. 3. 1.1.2. Integrando Ambientes Heterogéneos basados OSGi . .. 5. 1.2. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6. 1.3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . .. 6. 1.3.2. Objetivos Especı́ficos . . . . . . . . . . . . . . . . . . .. 7. 1.4. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 1.5. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 1.6. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 2. OSGi en las Redes Domóticas. 10. 2.1. Caracterı́sticas Generales de OSGi . . . . . . . . . . . . . . . . 11 2.2. La Especificación OSGi . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Los Modelos Arquitecturales para Soluciones basadas en OSGi 12 2.4. El Framework de OSGi . . . . . . . . . . . . . . . . . . . . . . 14 2.4.1. La Arquitectura del Framework . . . . . . . . . . . . . 14 2.4.2. Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.3. Objetos para los Servicios. . . . . . . . . . . . . . . . . 19. i.

(7) ÍNDICE GENERAL. ÍNDICE GENERAL. 2.4.4. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.5. Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.6. Especificación de Acceso a los Dispositivos . . . . . . . 20 2.4.7. Especificación de Servicios Jini . . . . . . . . . . . . . 22 2.4.8. Especificación UPnp con OSGi . . . . . . . . . . . . . 24 2.5. Implementaciones del Framework de OSGi . . . . . . . . . . . 26 2.5.1. Knopflerfish . . . . . . . . . . . . . . . . . . . . . . . . 27 2.5.2. Componentes del Framework Knopflerfish . . . . . . . 27 3. Ambientes Domóticos basados en Tecnologı́as Inalámbricas 29 3.1. Clasificación de las Redes Inalámbricas . . . . . . . . . . . . . 30 3.1.1. IrDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1.2. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.1.3. 802.15 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.1.4. Zigbee . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2. Principios de Diseño en Ambientes Móviles . . . . . . . . . . . 34 3.2.1. Complejidad de los Ambientes Móviles . . . . . . . . . 34 3.2.2. Requerimientos de los Ambientes Móviles . . . . . . . . 36 3.3. Arquitecturas orientadas a Ambientes Móviles . . . . . . . . . 37 3.3.1. Modelos basados en Cliente/Servidor . . . . . . . . . . 38 3.3.2. Modelos basados en Arquitecturas Orientadas a Servicios. . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3.3. Arquitecturas Móviles basadas en OSGi . . . . . . . . 42 4. Modelo Inter-tecnologı́as Propuesto. 44. 4.1. Definición de Requerimientos . . . . . . . . . . . . . . . . . . 45 4.2. Arquitectura del Modelo . . . . . . . . . . . . . . . . . . . . . 45 4.2.1. Esquema de Operación . . . . . . . . . . . . . . . . . . 46 4.2.2. Arquitectura basada en Componentes . . . . . . . . . . 47 ii.

(8) ÍNDICE GENERAL. ÍNDICE GENERAL. 4.3. Modelo Propuesto Detallado . . . . . . . . . . . . . . . . . . . 50 4.3.1. WPA Middleware en OSGi y en el cliente Móvil. . . . . 50 4.3.2. Service Manager . . . . . . . . . . . . . . . . . . . . . 54 4.3.3. Context Manager Manager . . . . . . . . . . . . . . . . 57 4.3.4. Mobile OSGi Manager . . . . . . . . . . . . . . . . . . 58 4.3.5. OSGi Application y la Mobile Application . . . . . . . 59 5. Conclusiones. 61. 5.1. Caracterı́sticas Generales del Modelo . . . . . . . . . . . . . . 61 5.2. Desarrollo de la Prueba de Concepto . . . . . . . . . . . . . . 63 5.2.1. Implementación de la Prueba de Concepto . . . . . . . 63 5.3. Resultados del Experimento . . . . . . . . . . . . . . . . . . . 65 5.3.1. Análisis del Número de Interfaces . . . . . . . . . . . . 67 5.3.2. Análisis Comparativo de los Resultados . . . . . . . . . 67 5.4. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.4.1. Extensión del Modelo para Arquitecturas Smart Client. 69. 5.4.2. Reconfiguración Dinámica de Servicios. . . . . . . . . . 69 5.4.3. Integración Adaptación al Contexto dentro del Usuario Móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.4.4. Aspectos de Seguridad De las Soluciones . . . . . . . . 70 6. Apéndices.. 71. 6.1. Instalación de Knopflerfish . . . . . . . . . . . . . . . . . . . . 71 6.2. Pasos para Construir una Aplicación en Knopflerfish . . . . . 72 6.3. Compilación de Aplicaciones en Knopflerfish . . . . . . . . . . 72. iii.

(9) Índice de figuras 2.1. Entorno Adaptable de Redes Domóticas en Pasarelas Residenciales. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Elementos de Modelos de Negocio basados en OSGi. . . . . . . 13 2.3. Arquitectura de Capas de OSGi. . . . . . . . . . . . . . . . . . 15 2.4. Diagrama de Clases del Framework de OSGi. . . . . . . . . . . 16 2.5. Servicios del Framework de OSGi. . . . . . . . . . . . . . . . . 17 2.6. Diagrama de Clases para la especificación Jini. . . . . . . . . . 23 2.7. Diagrama de Clases para la Especificación UPnp. . . . . . . . 25 3.1. Pila de Protocolos de Bluetooth. . . . . . . . . . . . . . . . . . 33 3.2. Pila de Protocolos de Zigbee y 802.15.4. . . . . . . . . . . . . 34 3.3. Ejemplo de Modelo Cliente-Servidor para Ambientes Móviles.. 38. 3.4. Ejemplo de Arquitectura Smart Client. . . . . . . . . . . . . . 39 3.5. Ejemplo de Arquitectura Thin Client. . . . . . . . . . . . . . . 39 4.1. Infraestructura General de una Red Domótica basada en OSGi. 46 4.2. Interacción de Aplicaciones Móviles con OSGi. (Diagrama de Instalación.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3. Arquitectura del Modelo de Integración de Ambientes Móviles a OSGi. (Diagrama de Componentes.) . . . . . . . . . . . . . 47 4.4. Diagrama de Clases para el Componente WPA Middleware en OSGi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51. iv.

(10) ÍNDICE DE FIGURAS. ÍNDICE DE FIGURAS. 4.5. Diagrama de Clases para el Componente WPA Middleware en el Dispositivo Móvil. . . . . . . . . . . . . . . . . . . . . . . . 52 4.6. Diagrama de Secuencia para el Protocolo de Comunicaión basado en WPA Middleware. . . . . . . . . . . . . . . . . . . . 53 4.7. Diagrama de Clases del Componente Service Manager. . . . . 55 4.8. Diagrama de Secuencia del Comportamiento del Service Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.9. Diagrama de Clases del Context Aware Manager . . . . . . . . 58 4.10. Diagrama de Secuencia del Context Aware Manager. . . . . . 59 4.11. Interfaces propuestas para el Mobile OSGi Manager. . . . . . . 59 4.12. Interfaces para la capa de aplicación. . . . . . . . . . . . . . . 59 4.13. Diagrama de Secuencia para la Capa de Aplicación de OSGi y en el Dispositivo Móvil. . . . . . . . . . . . . . . . . . . . . 60 5.1. Caso de Uso del Experimento Realizado en un Sensor y un Usuario Móvil. . . . . . . . . . . . . . . . . . . . . . . . . . . 65. v.

(11) Índice de cuadros 4.1. Descripción de los Mensajes del Protocolo. . . . . . . . . . . . 54 4.2. Descripción de los Mensajes del Protocolo para la Administración de los Servicios. . . . . . . . . . . . . . . . . . . . . . . 56 5.1. Descripción del Caso de Uso. Control de Temperatura en OSGi para Clientes Móviles . . . . . . . . . . . . . . . . . . . . . . . 64 5.2. Análisis Comparativo del Modelo Propuesto con las Arquitecturas Analizadas . . . . . . . . . . . . . . . . . . . . . . . . . 68. vi.

(12) Capı́tulo 1 Introducción Hoy en dı́a, una de las principales tendencias de la tecnologı́a es crear entornos inteligentes que proporcionen al hombre seguridad, comodidad y comunicación al instante desde cualquier parte. La explosión de tecnologı́as diferentes ha propiciado ambientes inter-operables independientemente de la ubicación y las plataformas. La definición de modelos y estándares para la integración de componentes y redes de comunicación han marcado el punto de partida para el crecimiento de estos entornos. Más allá de interconexión tradicional de computadoras, las redes domóticas surgen como una alternativa para la inte rconexión de los dispositivos cotidianos. Están orientadas a proveer servicios a través de pasarelas interconectadas a redes tradicionales [39]. Pensar en ambientes inteligentes donde se pueda usar el teléfono o la televisión para verificar que las puertas han sido cerradas o la cafetera está apagada, son simples ejemplos de los alcances logrados hasta el momento. Los hogares modernos se componen de un conjunto de dispositivos electrónicos de diferentes proveedores. Cuando son enlazados y ofrecen servicios integrados, proporcionan mayor versatilidad sobre sus aplicaciones dentro de la casa. Sin embargo, lograr un ambiente heterogéneo de sistemas, dispositivos y servicios interoperando dentro de las redes domóticas, es uno de los principales problemas que las investigaciones actuales están tratando de resolver [13]. La complejidad que expresa la heterogeneidad en las redes domóticas es directamente proporcional a las caracterı́sticas y objetivos que se desean 1.

(13) CAPÍTULO 1. INTRODUCCIÓN. ofrecer a los usuarios. Proporcionar transparencia y simplicidad de conexión, acceso y control, no es una tarea fácil [30]. Moon [24], especifica que si se tienen n diferentes tipos de dispositivos con m diferentes interfaces comunicándose contra otros k diferentes dispositivos, entonces la complejidad de comunicacion es de O(nmk). Obsérvese la alta proporción de interfaces resultantes con el crecimiento de dispositivos diferentes interconectados. Esto se traduce en una motivación para buscar nuevas y mejores soluciones que optimicen el número de interfaces entre los dispositivos integrados. Es decir, es necesario proponer arquitecturas que reduzcan integraciones y proporcionen la mayor transparencia posible. El mercado aún espera por soluciones que contribuyan a las tendencias de uno los entornos inteligentes con mayor potencial de crecimiento, tal como lo representan los ambientes domóticos [31]. Un ejemplo de las soluciones que se han ofrecido es OSGi(Open Source Gateway Iniciative). OSGi es un modelo de especificación estándar para proveer servicios orientados a redes domóticas [32]. El objetivo es promover los sistemas de interconexión abiertos. Se considera uno de los estándares con mayor futuro para satisfacer estas necesidades. Sin embargo, actualmente no ofrece interoperabilidad con redes inalámbricas, como Wifi o Bluetooth. La mayorı́a de los autores coinciden en que la integración de redes inalámbricas a OSGi significarı́a una contribución importante para ofrecer ventajas de flexibilidad y minimización de costos. Es por ello, que la presente propuesta de tesis tiene el objetivo de realizar una investigación detallada sobre las capacidades ofrecidas de OSGi y las caracterı́sticas de los ambientes móviles. Para obtener como resultado el desarollo de un modelo de integración de tecnologı́as móviles, basado en el framework OSGi dentro de una red domótica.. 1.1.. Planteamiento del Problema. Actualmente el uso de la tecnologı́a está abarcando otros ambientes que en el pasado no era posible. Esta ampliación es gracias a los avances en las comunicaciones, la miniaturización de hardware y la incorporación de frameworks de software; los cuales han propiciado ambientes como las redes domóticas. Hablar de redes o ambientes domóticos, es referirse a un sistema de tecnologı́a de información compuesto de productos utilizados en los hogares 2.

(14) CAPÍTULO 1. INTRODUCCIÓN. para ofrecer seguridad, comodidad, manejo y comunicación [10]. En [18] Jimeno, define que las redes domóticas son sistemas ubicuos integrados por dispositivos y recursos domóticos de acceso móvil y multimedia, servidores y medios de comunicación. Como parte de la lengua inglesa, también son conocidas como ”Home Networks” o Residential Network”. Los ambientes domóticos representan una área de automatización con alta aceptación y futuro, debido a la cantidad de productos domésticos que pueden ser integrados y manipulados por un sistema de tecnologı́a de información (TI). No obstante, debido al crecimiento de los clientes y proveedores de servicios, se hace necesario la definición de los estándares para operar en ambientes heterogéneos. Dentro de los estándares conocidos sobre ambientes de red, se pueden citar HAVi, Jini, Satulation, UPnP, X10, HomePlug, HomePNA, IEEE 1394, OSGi, entre otos más [30]. Mientras que en los estandáres para ambientes inalámbricos se encuentran: HomeRF2, 802.11b, 802.11a, 802.11g, 802.15.3 HiperLAn2, 5-Up, Irda, Bluetooth2 y Zigbee [40] . Obsérvese como la lista de estándares es amplia, por lo que la complejidad de integración aumenta en base al número de interfaces necesarias entre ellos para comunicarse y ofrecer servicios.. 1.1.1.. Las Arquitecturas y Middleware en Redes Domóticas. En los últimos dos años, los investigadores han enfocado esfuerzos para proponer arquitecturas interoperables. Los enfoques y trabajos son variados. Existen arquitecturas propuestas como MiDA’s(Mobile Internet Device with Network Appliance) [17], UMB [21], CINEMA(Columbia InterNet Extensible Multimedia Architecture) [34], mPRM(Remote Manangement Concept) [37]. Sin embargo, los trabajos han sido muy enfocados a resolver una aplicación en particular. Proponen arquitecturas dependientes de los servicios que se desean integrar y esto las hace poco escalables. En términos de ambientes móviles, puede comentarse que los trabajos coinciden en los siguientes puntos: 1. Es necesario un protocolo que permita descubrir el dispostivo y que determine su posición. 2. Es necesario un mecanismo de autentificación que optimice las 3.

(15) CAPÍTULO 1. INTRODUCCIÓN. caracterı́sticas de movilidad, es decir que elimine la necesidad de autentificarse si el dispositivo cambia de celda. 3. Es necesario establecer un middleware que responda a los caracterı́sticas del medio para proveer o denegar servicios. 4. Es necesario definir estrategias para determinar que servicios serán ofrecidos dependiendo de la ubicación del dispositivo. Por ejemplo si se ubica en la cocina, el dispositivo puede acceder a los servicios de la cafetera, mientras que al moverse a la recámara, deberá solo de tener acceso a la televisión o a la lámpara. Por otro lado, en términos de arquitecturas los trabajos identifican los siguientes puntos importantes: 1. Identifican un servicio administrador y controlador de servicios. Este puede ser distribuido como lo describe autor en la arquitectura MiDas, o bien centralizado como en mPRM. 2. Identifican un middleware encargado de manejar la comunicación con los diferentes estándares de los dispositivos. 3. Identifican un middleware broker que mantenga la comunicación entre las interfaces de los dispositivos y los servicios. 4. Determinan el costo de integración según el número de interfaces necesarias para proporcionar flexiblidad y transparencia de conexión y del servicio. 5. Las arquitecturas son orientadas a servicios que responden a eventos. En realidad, existe un amplio número de arquitecturas que proponen soluciones e integración entre diversas arquitecturas y estándares. Sin embargo, la escalabilidad y la portabilidad son un punto débil. Una de las arquitecturas más sofisticadas es propuesta por Cho [4], propone 3 componentes principales: Middleware Manager, Middleware Broker y el Web Server. El manager controla los dispositivos que pertenecen al tipo de red. El broker permite la comunicación entre los diferentes managers y finalmente el Web Server permite la administración de los dispositivos via web. Otra de las 4.

(16) CAPÍTULO 1. INTRODUCCIÓN. más actuales es la propuesta por Moon [24], quien propone una estructura principal basada en un mmiddleware de tablas de ruteo. Incluye un adaptador que permita la comunicación fı́sica de los dispositivos; además un middleware de red y uno de mensajes.. 1.1.2.. Integrando Ambientes Heterogéneos basados OSGi. El ambiente OSGi fue pensado para manejar de manera externa las interfaces, donde los proveedores realizarán un tipo de manejador que permitiera la comunicación con el gateway OSGi. Es decir, una vez que se define la interfaz, OSGi tiene disponible de manera implicita la integración con las interfaces que han sido instaladas en la pasarela de servicios, como es el caso de Jini, HTTP, UPnP. Esto elimina la necesidad de que cada interfaz tuviera que integrarse de manera especifica a los otros estándares, ya que se logra con el simple hecho de interconectarlo a OSGi. El mercado apunta hacia OSGi debido a que internamente ya controla y administra los servicios que se integran mediante una interfaz a la pasarela de servicios. Sin embargo, Bellavista [2] resalta la necesidad de que OSGi integre un middleware que soporte las caracterı́sticas de los ambientes móviles. Algunos autores como Lee [21], Hall [32] o Latvakoski [17], están estableciendo algunas propuestas que han sido publicadas en 2004. Sin embargo, dentro de sus trabajos han propuesto soluciones sin un impacto formal 1 , pero coinciden en describir las siguientes caracterı́sticas para la interfaz con OSGi: Se debe incluir el descubrimiento del dispositivo móvil con la definición de su instalación, activación y desinstalación. Se debe definir la denegación/otorgación del servicio bajo un esquema óptimo de autentificación. Se debe especificar el proceso de adaptación durante su tiempo activo, asi como el esquema de servicio disponible para el dispositivo y los servicios que éste proveé a la red de manera transparente [31]. 1. Actualmente, no existe una especificación estándar y abierta de acceso a servicios de dispositivos móviles en OSGi.. 5.

(17) CAPÍTULO 1. INTRODUCCIÓN. 1.2.. Justificación. Las limitaciones de movilidad de las redes cableadas y el alto costo de la infraestructura para nuevas instalaciones han llevado a buscar nuevas alternativas [39]. La integración de redes inalámbricas a las redes domóticas proponen una alternativa de acceso móvil y flexible, orientada a ofrecer ventajas competitivas en costos. Bajo este esquema, Bluetooth es una de las alternativas que tienen mayor impacto y futuro en estos momentos. Actualmente, existen varios investigadores que están trabajando en proporcionar modelos que solucionen las caracterı́sticas distintivas de la comunicación inalámbrica. Sin embargo, el objetivo es desarrollar un modelo basado en OSGi, debido a la importancia que tiene éste estándar como plataforma para proveer servicios con pasarelas residenciales. Además, OSGi es una especificación abierta que ha sido retomada por una gran variedad de proveedores como IBM, Motorola, Oracle o Intel [1]. La integración del modelo basado en las caraterı́sticas de instalación, registro, activación y provisión del servicio proporcionadas por OSGi para tecnologı́as Jini, http y plug and play son la base para plantear la funcionalidad del modelo. Considerando que hasta el momento OSGi, no ha definido una interface aceptada por el estándar, abre una ventana de posibilidades de proveer una solución. La solución debe aprovechar las ventajas y expectativas de flexibilidad que las comunicaciones inalámbricas ofrecen. Asi mismo, en la validación del modelo se realizará un prototipo con Bluetooth que demuestre que los problemas planteados en esta propuesta son resueltos. Bluetooth es una tecnologı́a que se considera con mayor auge en estos momentos y se visualiza mayor aceptación en el futuro.. 1.3.. Objetivos. 1.3.1.. Objetivo General. Desarrollar un modelo que permita la integración de tecnologı́as inalámbricas de corto alcance en los ambientes inteligentes de las redes domóticas basado en el estándar OSGi.. 6.

(18) CAPÍTULO 1. INTRODUCCIÓN. 1.3.2.. Objetivos Especı́ficos. 1. Definir el modelo de interacción entre el dispositivo móvil y el gateway de OSGi para integrarlo a la red domótica. El dispositivo debe de ser registrado, configurado, activado, actualizado y/o desinstalado de manera transparente dentro de la red; tal como es especificado en OSGi [7]. 2. Definir el modelo de interacción entre el OSGi y el dispositivo móvil. El dispositivo debe accesar a los servicios que son proporcionados dentro de la red domótica por medio de la pasarela de servicios de OSGi. 3. Definir el modelo para satisfacer las caracterı́sticas inherentes de la movilidad y el enlace espontáneo de los dispositivos inalámbricos. Estas caracterı́sticas son: el descubrimiento, la autentificación, la búsquedad y provisión de los servicios locales dependientes de la posición y la identificación del dispositivos [6].. 1.4.. Alcances. Sobre el Modelo: 1. Proponer un modelo genérico para resolver la interoperabilidad de OSGi con las diferentes tecnologı́as inalámbricas. 2. El modelo deberá abstraer las caracterı́sticas de los ambientes móviles y proponer un middleware que integre los dispositivos. 3. El dispositivo deberá de quedar disponible para la acceso y control a través de mecanismos eficientes que minimicen el número de interfaces. Sobre la validación del modelo: 1. El modelo será validado por medio de la realización de un prototipo utilizando la tecnologı́a Bluetooth y el framework Knopflerfish de OSGi. 2. Se determinará el número de interfaces interoperables, los niveles de flexibilidad, transparencia y calidad del servicio. 7.

(19) CAPÍTULO 1. INTRODUCCIÓN. Sobre el prototipo: 1. El prototipo deberá permitir determinar la efectividad del modelo propuesto. 2. El prototipo será implementado en java para compatibilidad con OSGi. 3. Se usará un PDA como dispotivo móvil y una laptop como pasarela servicios que ejecute Knopflerfish y con el respectivo adaptador bluetooth. Limitaciones: El middleware prototipo se enfocará sobre Bluetooth y explorá sus caracterı́sticas. El descubrimiento del dispositivo se realizará en base a las especificaciones. Futuros trabajos: Construcción del middleware completo para integrar a OSGi.. 1.5.. Hipótesis. Proponer un modelo genérico e integrador de redes inalámbricas para las redes domóticas orientado a servicios OSGi, puede: Ofrecer mayor portabilidad. Minimizar el número de interfaces para garantizar la interoperabilidad Proporcionar mayor nivel flexibilidad y transparencia de acceso a los servicios móviles.. 1.6.. Metodologı́a. Se incluyen cinco elementos principales de la metodologı́a que tienen el objetivo de cubrir los tiempos destinados para el trabajo de tesis [25], [5]. En la primera fase, se trabaja sobre el tema, el diseño de la investigación y la definición de la propuesta de manera formal. Posteriormente, en la primer 8.

(20) CAPÍTULO 1. INTRODUCCIÓN. etapa de la investigación se tiene el propósito de fortalecer los conceptos y el contexto del tema. Para ello, se realiza una fase de experimentación y análisis de resultados, en donde se obtienen los primeros capı́tulos del reporte final. Después, se propone una segunda etapa de investigación para formular y experimentar sobre los objetivos concretos de la tesis. En esta etapa se trabajará sobre los experimentos que permitan demostrar la hipótesis, validar los resultados y concluir la investigación. Finalmente, se considera la etapa de integración del reporte formal de la tesis. Esta etapa deberá integrar los reportes, experimentos y resultados llevados a cabo durante la etapa I y II de la investigación.. 9.

(21) Capı́tulo 2 OSGi en las Redes Domóticas OSGi (Open Services Gateway Iniciative) es una alianza formada en 1999 con el objetivo de crear una especificación de referencia completa, no restrictiva, abierta y no normativa para redes y dispositivos de área local. Para ello, la alianza cuenta con la participación y el respaldo de las compañı́as más importantes de software y hardware como IBM, SUN, Wirlhpool, Intel, etc [1]. Inicialmente la misión fue especificar top boxes y pasarelas de servicios para hogares, pero actualmente la especificación esta siendo usada en automatización industrial, automovilı́stica y telemática. Ası́, la especificación intenta cubrir sus requerimientos, proporcionando comunicación entre varios dispositivos de una red local como una casa, oficina o automóvil. Además, OSGi promueve el descubrimiento y la colaboración dinámica de dispositivos y servicios de los diferentes proveedores. Otro de los objetivos de OSGi, es presentar un modelo arquitectural que describe los escenarios posibles de los casos de negocio. El modelo abierto propone esquemas de implementación de las redes de manera adaptable a las caracterı́sticas del ambiente y en diferentes esquemas de negocio, como se muestra en la figura 2.1. Asimismo, proporciona referencias distribuidas y centralizadas para la provisión de los servicios. En ellas, la infraestructura de comunicación, los proveedores, el cliente y los servicios, interoperan a través de la pasarela1 basada en OSGi. 1. La pasarela es un servidor embebido que se inserta en la propia red domótica para conectar la red Internet externa con los clientes internos.. 10.

(22) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. Figura 2.1: Entorno Adaptable de Redes Domóticas en Pasarelas Residenciales.. 2.1.. Caracterı́sticas Generales de OSGi. Según [1], OSGi incluye las siguientes caracterı́stcas: Propone una especificación abierta y un framework basado en componentes para aplicaciones orientadas a servicios. Ofrece la instalación de nuevos componentes y aplicaciones, interoperando por medio de programación de APIs que pueden ser importandas o exportadas entre aplicaciones, denominadas bundles. El ambiente de ejecución del framework es un modelo cooperativo que permite de manera flexible el descubrimiento, el registro y la actualización de las aplicaciones instaladas en él. Incluye un manejador de aplicaciones que permite instalar aplicaciones de manera transparente para los desarrolladores. Incluye un conjunto de servicios de sistema y estándares para el soporte de las aplicaciones como logTracker, http, xml, IO, bootloader, entre otros.. 2.2.. La Especificación OSGi. La especificación abierta de OSGi consta de tres secciones importantes2 , donde se describen los aspectos básicos y estratégicos que deben cumplir las 2. Se analizó la version 3, ya que la última versión en mayo de 2006 es la 4, ésta fue liberada en los meses posteriores a la investigación.. 11.

(23) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. implementaciones del framework[16]. Estas son: 1. Sección de referencia. Es comprendida por documentos de referencia sobre arquitecturas, modelos, terminologı́a e información relacionados para la implantación de soluciones basadas en OSGi. 2. Sección Normativa. Incluye la descripción detallada del framework. Se compone por el conjunto de clases con sus métodos y propiedades que debe cumplir las implementaciones, como son: el bundle, bundlecontext, servicios, registros, eventos, notificaciones, permisos, conectores de entrada y salida, registros, ambientes de ejecución, posicionamiento y medidas. 3. Sección Recomendada. Incluye un conjunto de especificaciones para bundles de aplicación que han sido aceptados por OSGi, como lo son Jini, Http UPnp. El objetivo es continuar con la compatibilidad para protocolos de comunicación de servicios Jini, UPnP y Http en las diferentes versiones.. 2.3.. Los Modelos Arquitecturales para Soluciones basadas en OSGi. La arquitectura señala la relación de los elementos que pueden definir un ambiente basado en OSGi; es integrada por cuatro bloques: infraestructura, plataforma de servicios, proveedor de aplicaciones orientados a servicios y administración de atención a clientes, tal como es mostrado en la figura 2.2. La infraestructura propone las caracterı́sticas de acceso a la red y al servidor de la plataforma. Se relaciona con la plataforma de servicio quién ejecuta las aplicaciones disponibles. La plataforma garantiza los mecanismos para el ciclo de vida de las aplicaciones que serán contratadas por los usuarios y sumistradas por los diferentes proveedores a través de la infraestructura. El proveedor define las relaciones entre las aplicaciones, la instalación, el aseguramiento de la integridad, demanda, y el mantenimiento. La atención a clientes determina la administración de cuentas y el registro de los servicios proporcionados al usuario; es relacionada con la plataforma de aplicaciones y con el proveedor de servicios. Similarmente, se especifica un 12.

(24) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. identificador de la plataforma de servicios, el cual será asignado por operador.. Figura 2.2: Elementos de Modelos de Negocio basados en OSGi. De esta manera, el estándar describe los siguientes cuatro modelos propuestos: 1. Modelo de Pasarela de Servicios. Representa una referencia para la especificación de sistemas basados en pasarelas residenciales a gran escala. Divide el escenario en dos ambientes definidos como la residencia y la localización del operador. El operador define los roles del proveedor de servicios, quien desarrolla, instala y mantiene los servicios a través de la pasarela del operador. Ésta a su vez, se conecta a la residencia por medio de la infraestructura de red, donde se ubica la pasarela y la plataforma de servicios. La pasarela ofrece los servicios del operador dentro de la red local y los dispositivos locales. La red local de dispositivos varı́a según el tipo de servicio y de mercardo. Las tecnologı́as tı́picamente usadas en la red local son: EIB, Ethernet, WiFi, IEEE 1394, entre otros. Mientras, para el proveedor de la WAN, puede ser DSL, Ethernet o redes de celulares(GSM, AMPS). 2. Modelo Industrial. Es recomendado cuando se desea un acceso remoto a través de computadora, pero no hay un modelo de acceso al proveedor de servicios. Un ejemplo es el acceso mediante una conexión de celular. Este modelo implica problemas de interoperabilidad. Sin embargo la propuesta es: un operador del celular encargado de la provision de servicios, conectado por una estación de la célula, la cual es el punto de acceso a la plataforma de servicios remota. 3. Modelo Autoadministrable. Es muy similar a una red residencial normal, que incluye la plataforma de servicios por medio de una 13.

(25) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. computadora y dispositivos conectados por medio un enruteador con ethernet o WiFI, pero incluye un enlace de intercambio privado. 4. Modelo de Pasarela Virtual. Considera que la pasarela no esta localizada en la residencia, por lo que los servicios son controlados por medio de la red. La ventaja es que el sistema puede ser contralado por el operador en su mayor parte, pero la conexión de los dispositivos es más complicada de manera local.. 2.4.. El Framework de OSGi. El framework de OSGi es un modelo conciso y consistente para desarrollo de aplicaciones basado en bundles. Básicamente, simplifica la implementación de aplicaciones utilizando los servicios a través de interfaces y componentes. Además, proporciona mecanismos para la instalación de bundles, resolución automática de dependencias e interacción de modelos de ejecución orientados a eventos y servicios.. 2.4.1.. La Arquitectura del Framework. La arquitectura de framework se basa en un conjunto de bundles que pueden correr sobre dispositivos compatibles con java. Los bundles son aplicaciones que pueden ser instaladas, actualizadas y desinstaladas dinámicamente. Los bundles contienen mecanismos y algoritmos para controlar dispositivos individuales. Algunos de ellos son básicos para la operación del framework, mientras que otros interactuan con él para formar una plataforma de servicios [14]. De manera general, la arquitectura se compone de las siguientes capas que se muestran en la figura 2.3: 1. OS y Hardware. Los aspectos de hardware no son incluidos como parte de la especificación, ya que es es independiente de la platarforma. 2. El ambiente de ejecución. Se basa en el ambiente de JVM de java, éste proporciona todas las caracterı́sticas de ser abierto, confiable, seguro, maduro y portable. 14.

(26) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. Figura 2.3: Arquitectura de Capas de OSGi. 3. Módulos. Esta capa resuelve la cooperación y dependencias entre bundles. Define la forma transparente de importar y exportar los bundles dentro de paquetes. 4. Administración del Ciclo de Vida. Encapsula los mecanismos para que los bundles puedan ser instalados, iniciados y activados; o bien detenidos y desinstalados. Estos procesos son realizados mediante el Manifesto incluido en los archivos JAR de los bundles. El manifiesto contiene información sobre dependencias, versiones y servicios del bundle que son requeridos para su instalación en el framework. Básicamente, el diagrama de clases del framework mostrado en la figura 2.4, incluye las siguientes caracterı́sticas agrupadas en 4 puntos principales: 1. Controlador de Bundles. Implementa las interfaces de BundleActivator y bundle. Se encarga del ciclo de vida de bundles(instalar, resolver, iniciar, detener y desinstalar). Además, controla el classloader, a través del encabezado del manifiesto. Se comunica con el manejador de servicios y con el módulo de seguridad para definir la resolución de los servicios. 2. Controlador de Servicios. Implementa las interfaces para registrar y eliminar los servicios que están asociados al framework. Para ello, la interfaz ServiceReference permite mantener la información importante sobre los servicios y se auxilia de la clase filter para la búsqueda de propiedades. Se comunica con el controlador de bundles para regresar información sobre los servicios activos. 15.

(27) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. Figura 2.4: Diagrama de Clases del Framework de OSGi. 3. El framework. Implementa la interfaz Bundle Context que permite controlar el acceso a los bundles en ambiente de ejecución. Implementa los eventos y los listeners para registrar actividades de bundles y agregar o eliminar servicios. Maneja los eventos de framework sobre la inicialización del sistema y su contexto, además se comunica con el administrador de bundles. De la misma forma, realiza el manejo de excepciones y de constantes que sean utilizadas. Por último, define aspectos del ciclo de vida de los bundles. 4. Administración de la seguridad. Las clases de seguridad de java se integran al controlador de bundles para determinar las caracterı́sticas del ambiente de ejecución de los bundles activados. Se basa en la 16.

(28) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. plataforma de seguridad definida por Java. 5. Servicio de Registro. Facilita la administración de los bundles activos o eliminados, con el objetivo de realizar un control dinámico de bundles. 6. Servicios Estándares : La version 3 del framework, mostrada en la figura 2.5, incluye:. Figura 2.5: Servicios del Framework de OSGi. Servicios del Framework: Bundles enfocados a administración, accesos y manejadores de URL. Servicios del Sistema: Administración de Accesos. Servicios de protocolo: Http, UPnp y Jini. Servicios Misceláneos: Wire Admin, XML y Axis.. 2.4.2.. Bundles. Un bundle es un archivo JAR que son entidades de instalación para almacenar aplicaciones y sus recursos. Las relaciones y dependencias son implementadaas por el Bundle Activator, quien controla las actividades de iniciar, resolver, actualizar y eliminar los bundles. Ası́, el mismo framework representa un Bundle, el cual es denominado System Bundle y se le asigna el identificador cero. De manera general, pueden definirse las siguientes caracterı́sticas de los bundles: Siguen los encabezados estrictos del manifiesto que asocia información de dependencias con otros bundles, con códigos nativos, versiones, localizaciones, permisos, entre otros. 17.

(29) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. Están asociados a un espacio de nombres definido en la base de datos de los bundles instalados. La base de datos es consultada para resolver cualquier servicio de los bundles. Tiene definido un ambiente de ejecución en el framework y durante el tiempo de activación, dependiendo de los permisos y el classpath asignados en el encabezado. Existen reglas definidas para la búsqueda de clases y recursos proporcionadas por el classLoader, el cual responde a las solicitudes de otros servicios para resolver dependencias y asociaciones de los bundles. Bundle Object Para todo bundle instalado existe su correspodiente Bundle Object y éste objeto permite manejar el ciclo de vida de un bundle. Un objeto Bundle tiene las siguientes caracterı́sticas: 1. Tiene asociado un identificador único y una localización asignada durante la instalación. 2. Los estados de un bundle son: instalado, resuelto, iniciado, detenido, activado y desinstalado. 3. Un bundle pude ser instalado solo sı́ las dependencias han sido resueltas. Si las dependencias no se resuelven, entonces el bundle pasa al estado de iniciado. 4. Cuando un bundle objeto es detenido, los objetos que importaron dicho objeto pueden continuar accesando código de éste. 5. El framework debe de garantizar que a través del proceso de actualización, exista solamente una versión activada, importada y exportada en el framework. 6. Cuando un bundle es desinstalado, el sistema debe de liberar todos los recursos asociados. Sin embargo, si algún bundle está siendo usado, el sistema debe mantener el código relacionado aún después de haber sido desinstalado. 18.

(30) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. Bundle Context El bundle Context representa el objeto proxy entre los bundles instalados y los objetos en contexto de ejecución para el framework. Es el reponsable de regresar la información del objeto en ejecución como la versión, vendedor, procesador, etc. Cuando un bundle es iniciado, se crea un objeto de contexto para mantener la persistencia de almacenamiento al bundle instalado.. 2.4.3.. Objetos para los Servicios.. La cooperación entre los servicios es soportada por medio de objeto service controller, el cual implementa las interfaces service registration, service reference y service event. La interfaz de servicio de registro mantiene actualizada la base de datos de servicios instalados en el framework. La interfaz de servicios de referencia encapsula la información del servicio que representa. Mientras la interfaz de eventos se encarga de resolver/notificar los cambios de estado de los servicios instalados. De esta froma, cuando un nuevo servicio es instalado en el framework, el controlador de servicios se encarga de registrar el nuevo objeto. Si un objeto es registrado exitosamente, entonces el servicio regresa un objeto de ServiceRegistration y genera un ServiceListener basado en el concepto de callbacks de java. Por otro lado, las propiedades del registro y los datos que se guardan durante el proceso de registro, forman un diccionario de llaves que permite realizar filtros para acceder a los objetos. Además, con ello se lleva el registro del uso de los servicios al incrementarse dependiendo los accesos al objeto de Contexto. El acceso a la información de los servicios se realiza por medio de dos métodos implementados por la interfaz: getRegisteredServices() y getServicesinUse(). Los Filtros Los filtros basados en la interfaz Filter, permiten la búsqueda de las propiedades de los servicios. Son basados en el protocolo de busquedad LDAP. Esta interfaz es muy útil para ligar información de objetos o bien para determinar si se trata de un nuevo objeto. 19.

(31) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. Service Factories El objetivo de esta interfaz es generar objetos que puedan ser configurables, dando la flexibilidad al framework para realizar las actividades de registro. Remplazan la opción de implementar listeners, en lugar de ello, este servicio notifica cuando un objeto ha cambiado. Entonces, los métodos se encargan de resolver las dependencias, de llevar el número de usos del servicio a cero, entre otras cosas.. 2.4.4.. Eventos. El framework soporta tres tipos de eventos: 1. Eventos de Servicio. Reporta las actividades de registro y eliminación del registro de los objetos de servicios. 2. Eventos de Bundles. Reportan los cambios en el ciclo de vida de los bundles. 3. Eventos del Framework. Reporta cambios sobre cambios en el framework.. 2.4.5.. Listeners. Proporcionan interfaces asociadas a los servicios, bundles y el framework para notificar que se ha agregado un servicio, un nuevo bundle o ha cambiado algún evento.. 2.4.6.. Especificación de Acceso a los Dispositivos. La especificación de acceso de dispositivos soporta la detección automática y la inserción de dispositivos existentes sobre una plataforma de servicios OSGi. También facilita la conexión o desconexión en hotspot de nuevos dispositivos, la descarga e instalación de los drives de dispositivos en demanda.. 20.

(32) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. No obstante, esta especificación deliberadamente no prescribe algún dispositivo o tecnologı́a de red en particular. La especificación se centra en el agregado de dispositivos alimentados por diferentes vendedores. Esto enfatiza el desarrollo de interfaces de dispositivos estandarizados para ser definidos en categorı́as de dispositivos, aunque tales categorı́as de dispositivos no son definidas en esta especificación 3 . Operación La especificación define el comportamiento del manejador del dispositivo. Detecta el registro del servicio del dispositivo y es responsable por la asociación de estos con el apropiado servicio del driver. Se hace con la ayuda de los servicios del localizador de controladores y del selector de controladores que permiten al manejador encontrar un Driver Bundle e instalarlo. Servicios de Dispositivos Los servicios de dispositivos pueden variar ampliamente: algunos representan dispositivos f´ı́sicos individuales y otros representan redes completas. Muchos servicios de dispositivos pueden simultáneamente representar al mismo dispositivo fı́sico a diferentes niveles de abstracción, por ejemplo: 1. Una red conectado mediante USB. 2. Un dispositivo adherido sobre una red USB. 3. El mismo dispositivo reconocido como USB o un puente Ethernet. 4. El mismo dispositivo reconocido en una Ethernet. 5. El mismo en una impresora. Un dispositivo también puede ser representado en diferentes caminos, un ratón USB puede ser considerado como un dispositivo USB el cual entrega 3. Este punto resalta que es necesario definir una categorı́a que sorporte el acceso a los servicios, como lo representan dispositivos de inalámbricos de corto alcance.. 21.

(33) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. información sobre el bus USB o como un dispositivo Mouse el cual entrega coordenadas acerca de su estado. Cada representación tiene implicaciones especı́ficas, ası́ los servicios de dispositivos pertenecen a una categorı́a de dispositivos definida. Una categorı́a de dispositivos especifica el método para la comunicación con un servicio de dispositivos, y habilita interoperabilidad entre los bundles que son basados en la misma base tecnológica.. 2.4.7.. Especificación de Servicios Jini. Jini es un middleware de red para computación ubicua basada en Java para crear una federación o servicios que trabajan juntos de máquinas virtuales [22]. Es una capa de software que proporciona la información de dispositivos para ser agregados directamente a la red sin tratamiento de controladores y configuración del sistema operativo. Ası́, Jini es considerado como una solución de software para redes residenciales de SunMicrosystem. Los objetivos de Jini son: 1. Compartir recursos y servicios sobre una red. 2. Proporcionar acceso a los recursos de la red en cualquier lugar. 3. Ofrecer un ambiente programación basado en patrones para el desarrollo robusto de sistemas distribuidos. 4. Simplifica la tarea de construccón y mantenimiento de software para los usuarios. 5. Una de las fortazalezas es estar compuesto por protocolos llamados discovery, join, y lookup. La Especificación Jini en OSGi Los dos aspectos esenciales descritos por la especificación son: el descubrimiento y control de servicios Jini dentro de un framework de OSGi y la exportación de servicios OSGi como servicios Jini. El objetivo es proponer la especificación estándar para comunidad, para que pueda ser retomada 22.

(34) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. por los diferentes proveedores de aplicaciones OSGi. Entonces, se pretende cumplir con tres puntos esenciales: transparencia, capacidades de exportación e importación de los servicios. Para cumplir con estos puntos, el diagrama de clases del estándar que se muestra en la figura 2.6, puede dividirse en los siguientes puntos importantes:. Figura 2.6: Diagrama de Clases para la especificación Jini.. 1. Servicio de Importación. Es servicio permite que por cada servicio Jini, no se agregue un servicio en OSGi, sino que el driver es quien controla el acceso a los dispositivos. Entonces, el driver es quien mantiene la lista de los servicios que son registrados en la red Jini. Cuando un servicio es imporatdo, se agrega información sobre device category, service id y entries. 2. Servicio de Exportación. Todos los objetos de servicios exportados deben de estar directamente referenciados y deben ser serializables. Aunque los servicios son creados de manera local, son ejecutados en la máquina local, por lo que se necesita un proxy que mantenga disponible la plataforma OSGi.. 23.

(35) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. 3. Proxy o Bundle Jini Driver. Transforma cualquier servicio Jini descubierto en la red y lo transforma en un servicio registrado para OSGi. 4. Jini Interfaz. Representa la interfaz del dispositvo Jini. Modo de Operación. Cuando un dispositivo Jini es agregado a la red, éste usa un protocolo adicionado, denominado discovery and join, el cual registra el servicio con el ServiceRegistrar class de Jini. Cuando un dispositivo proporciona un servicio, se ejecuta el servicio de lookup y éste descarga el objeto usando la serialización. Entonces, el driver de OSGi debe registrar los servicos de OSGi para importar los servicios dentro del ambiente de OSGi. El driver Jini debe estar escuchando si la red Jini descubre un nuevo dispositivo. Cuando ocurre este evento, el driver debe regresar el objeto proxy para que el servicio sea registrado en OSGi usando ServiceRegister. Cuando los servicios son registrados en el framework, el driver también debe manejar el ciclo de vida de los servicios tanto en OSGi como en Jini. El driver de Jini carga los códigos de otras máquinas virtuales y ejecuta este código en el ambiente de OSGi. De esta forma, el framework de OSGi registra los objetos de servicios bajo el nombre de la interfaz, la cual debe ser importada por otro bundle. Cada interfaz de servicio registrado debe ser exportada por uno o más bundles. Esto implica que el driver de Jini debe asegurarse que los objetos de Jini soporten la interfaz más reciente de manera dinámica.. 2.4.8.. Especificación UPnp con OSGi. UPnp (Universal Plug and Play) es un estándar que se caracteriza por soportar cero configuración de los dispositivos, una operación de red transparente y descubrimiento automático. Ası́, un dispositivo UPnp puede agregarse a la red, obtener una dirección IP y ofrecer servicios de manera automática. Para ello, UPnp utiliza los protocolos TCP/IP para publicar sus servicios usando una interfaz XML. Ası́, el servicio del dispositivo UPnp puede ser llamado, accesado u operado a través del uso de la interfaz. La especificación OSGi para dispositivos UPnp se enfoca en definir la manera en que pueden ser bajados los servicios UPnp y como pueden ser 24.

(36) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. manejados en un sistema remoto. Es decir como desarrollar bundles que puedan interoperar con dispositivos y puntos de control. La Arquitectura OSGi-UPnp Básicamente, la especificación del dispositivo UPnp en OSGi, esta orientada a la integración del servicio, para que éste sea visto como un servicio de OSGi y pueda ser usado dentro del framework. Para ello, el diagrama de clases que se muestra en la figura 2.7, se integra de los siguientes elementos importantes:. Figura 2.7: Diagrama de Clases para la Especificación UPnp.. 1. Servicio. El servicio es formado por los objetos de servicio, acciones y variables. 2. Dispositivo. El dispositvo implementa los servicios del UPnp. 3. Driver. El driver permite administrar los servicios que son registrados en el framework, a la vez sirve como proxy con los dispositivos. 4. Otros elementos. Incluye interfaces para manipular información de ı́conos y listeners.. 25.

(37) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. El driver UPnp debe manejar la funcionalidad del protocolo y la interacción con los bundles UPnp. Ası́, cuando un nuevo dispositivo es detectado en la red, el dispositivo es registrado en OSGi usando la interfaz service.. 2.5.. Implementaciones del Framework de OSGi. Actualmente, el framework de OSGi ha sido implementado por varios investigadores y empresas que demuestran su operabilidad y viabilidad. Dentro de las implementaciones libres se encuentran: 1. OSCAR. Es una implementación de la versión 2 y 3 del framework. Se enfoca a proporcionar un ambiente dinámico de componentes. Proporciona un framework ligero que se puede configurar dependiendo de las necesidades y capacidades de las pasarelas. Incluye un repositorio de bundles y un ambiente de desarrollo. 2. Knopflerfish. Es una versión abierta basada en la versión propietaria Ubiserv. Incluye un administrador y librerı́as para bundles en entorno gráfico. Además, proporciona un plug-in de desarrollo bajo entorno de eclipse. 3. Java Embedded Server. Es la implementación propuesta por Java Sun para version 1.0 del framework de OSGi.. Se caracteriza por ser muy ligero y proveer solamente los servicios elementales para la administración de bundles [35]. Además, existen versiones propietarias como: 1. Service Management Framework (SMF). Es una implementación de IBM de la especificación de OSGi r.3. Puede obtenerse la versión solamente de desarrollo o bien utilizar el plug-in para el ambiente de desarrollo WebSphere (WSDD). Se caracteriza por que el framework puede ser instalado en cualquier tipo de pasarelas, ya que integra la máquina virtual de java(JVM). Incluye un SMF Bundle Developer 26.

(38) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. diseñado para realizar pruebas de las aplicaciones en un ambiente gráfico. Además, ofrece caracterı́sticas basadas en el ambiente de desarrollo WSDD, como lo son el cargador de clases y la administración de los recursos [15]. 2. Prosyst. En mBedded Server 5.2 facilita un entorno especializado de desarrollo para aplicaciones basadas en OSGi versión 3 y 4. Incluye versiones para manejo de dispositivos móviles para arquitecturas OMA4 . Además incluye librerı́as para administración y aplicaciones gráficas y un plug-in para JBuilder [29].. 2.5.1.. Knopflerfish. Knopflerfish es un proyecto creado para el desarrollo y distribución de código, herramientas y aplicaciones basadas en OSGi. Se considera una versión robusta, que está continúamente actualizada. Actualmente, la implementación del framework corresponde a la versión 3, ya que la versión 4 fue liberada en el mes octubre de 2005.. 2.5.2.. Componentes del Framework Knopflerfish. Como parte de la implementación, se incluyen los siguiente servicios y componentes [20]: Base framework. Soporta el ciclo de vida de los bundles. Contiene los siguientes componentes: • Servicio de Administración de Paquetes. • Servicio de Administración de Permisos. • Servicio StartLevel. • Servicio URL. Utlierı́a de Seguimiento de Servicios. Servicio de registros. 4. Arquitectura propuesta por Texas Instrument para aplicaciones de smartphones.. 27.

(39) CAPÍTULO 2. OSGI EN LAS REDES DOMÓTICAS. Servicio HTTP. Manejador de Configuración. Maneja el almacenamiento persistente de los datos de aplicación. Manejador de dispositivos. Maneja los componentes de software relacionados con los controladores de los dispositivos fı́sicos. Servicio de Administración de Usuarios. Funcionalidad de control de accesos de usuarios. Servicios de Preferencias. Posicionamiento. Manejador de posiciones. Manejador de unidades. Metatype API. Permite que las aplicaciones puedan publicar información. Utilerı́a XML. Proporciona clases template para traductores XML. Instalación Remota En base a la revisión de la implementación de los frameworks abiertos, Knopflerfish es uno de los que ofrecen más ventajas en cuánto seguimiento de la especificación, en ambiente de desarrollo y los servicios que ya se han implementado como parte del framework.. 28.

(40) Capı́tulo 3 Ambientes Domóticos basados en Tecnologı́as Inalámbricas La comunicación en los ambientes domóticos orientados principalmente al control y el monitoreo de dispositivos y aplicaciones, tiene retos importantes por resolver y fortalecer. Las soluciones están basadas en la simplicidad, la transparencia de conexión, disponibilidad y facilidad de uso para los usuarios. Dobrev [27], sugiere que a medida que estos cuatro puntos sean cubiertos, la tecnologı́a será menos costosa y más fácil de proporcionar a los hogares. Desde este marco, uno de los conceptos asociados a las soluciones, es la movilidad. La movilidad permite al usuario utilizar los servicios sin necesidad de estar ubicado en un mismo lugar; o bien, cambiar de ubicación y continuar utilizando los servicios. Ası́, las tecnologı́as inalámbricas emergen como una alternativa alentadora para satisfacer las necesidades de comunicación móvil en ambientes como los domóticos. Mallick [23], considera que las tecnologı́as móviles no necesariamente deben ser inalámbricas, pero la movilidad se adapta de manera más natural si no es alámbrica. Con ello, una aplicación inalámbrica puede ser móvil, siempre que proporcione servicios independientes de la localización y con la mayor transparencia posible. Es decir, la aplicación móvil está diseñada para proveer servicios dependiendo de la ubicación. También define las terminales finales para los servicios y las terminales para obtenerlos; además, identifica el dinamismo y las limitaciones de disponiblidad, la limitación de recursos y la conectividad intermitente [3]. Para ello, en las secciones siguientes se describen a detalle los conceptos 29.

(41) CAPÍTULO 3. AMBIENTES DOMÓTICOS BASADOS EN TECNOLOGÍAS INALÁMBRICAS mencionados en esta sección.. 3.1.. Clasificación de las Redes Inalámbricas. Las tecnologı́as inalámbricas abarcan un conjunto de redes, cuya transmisión de datos, audio y video se realiza mediante ondas de radio. Dependiendo del alcance de la comunicación y las frecuencias utilizadas, existen las siguientes cuatro categorı́as [23]: 1. Redes de Area Personal WPAN (Wireless Personal Area Network). Son aquellas que permiten comunicación entre los dispositivos electrónicos de la persona, tales como PDA, computadoras, audı́fonos, teléfonos, etc. Se caracterizan por proporcionar comunicación de corto alcance, bajo consumo de energı́a, bajo costo y por formar redes de espacios pequeños. La interoperabilidad y la cobertura representan sus dos principales metas. Dentro de los estándares lı́deres se encuentran: IrDA, Bluetooth, 802.15 y ZigBee. 2. Redes Inalámbricas de Area Local WLAN (Wireless Local Area Network). Representan soluciones para espacios definidos como oficinas, corporaciones, hoteles, aeropuertos, etc. Son usados para ahorrar costos, evitar tendidos de cable o proveer accesos rápidos a Internet. Tienen cobertura aproximada de 50 hasta 150 metros con rendimiento de 1 a 54 Mbps. Los consumos de energı́a dependen de los productos, mientras que los costos varı́an dependiento de las caracterı́sticas de instalación y el estándar propuesto. Las configuraciones pueden ser por puntos de accesos o peer-to-peer, siendo éste último el más común para integrar puntos de acceso extendidos. Los estándares conocidos son especificados por tres vertientes: IEEE y ETSI(European Telecommunications Standards Institute) y la alianza HomeRF. El estándar lı́der es 802.11b o WiFi, pero también existen 802.11a, 802.11g y HIPERLAN/1 y 2. 3. Redes Inalámbricas de Area Amplia WWAN (Wireless Wide Area Network). Proporcionan cobertura inalámbrica nacional o incluso internacional para comunicación de voz y datos. Son redes en las que el acceso requiere de costo o permisos definidos y operan sobre 30.

(42) CAPÍTULO 3. AMBIENTES DOMÓTICOS BASADOS EN TECNOLOGÍAS INALÁMBRICAS. frecuencias con licencia. La calidad y la velocidad depende de la tecnologı́a utilizada, mientras que el costo y la cobertura depende de la red. Inicialmente eran redes analógicas y han evolucionado a redes digitales, proporcionando mayores beneficios. Estas tecnologı́as han mejorado sus caracterı́sticas de desempeño y los servicios ofrecidos en tres generaciones. Actualmente, la tercera generación está orientada a proporcionar servicios de alta calidad y de alta velocidad, cuyos estándares están regulados por la asociación GSM, el grupo CDMA, el foro UMTS, Mobitex y Motorola. 4. Redes Satelitales. Originalmente fueron propuestas para sistemas de comunicación de voz y datos con cobertura en todo el planeta, sin necesidad de puentes entre dispositivos. Sin embargo, éstas han resultado soluciones muy caras que pueden ser remplazadas por redes de área amplia. Actualmente, se utilizan para soluciones de localización. Su velocidad varı́a de 2.4 kbps a 2 Mbps. Algunos de los proveedores de servicios de redes satelitales son: Iridium, GlobalStart, Teledesic, Asia Cellular Satellite, entre otros. Dentro de los ambientes domóticos, las redes personales representan mayor potencial para comunicar dispositivos dentro de espacios definidos con personas autorizadas. Por ello, a continuación se revisan a detalle las redes basadas en IrDA, Bluetooth, 802.15 y Zigbee.. 3.1.1.. IrDA. Por sus siglas en inglés Infrared Data Association, es un estándar internacional que abarca un amplio rango aplicaciones, cómputo y dispositivos de comunicación. Los protocolos proporcionan alta velocidad, rango corto y conexión punto a punto. La comunicación tiene un rango de 1 a 2 metros, requiere bajo consumo de energı́a, proporciona comunicación bidireccional y la transmisión de datos es de 9600 bps y con un máximo 4Mbps. Una de las principales desventajas es que no permite comunicación ubicua, pero es competitivamente muy barato; por lo que es usado en un amplio número de dispositivos [39].. 31.

(43) CAPÍTULO 3. AMBIENTES DOMÓTICOS BASADOS EN TECNOLOGÍAS INALÁMBRICAS. 3.1.2.. Bluetooth. Es una tecnologı́a para aplicaciones móviles que no requiere la vista entre los dispositivos, como en el caso de IrDA. Permite la comunicación a través de barreras fı́sicas en un rango de 10 a 100 metros para voz y datos. Transmite a una frecuencia 2.4GHz con máximo de 720 Kbps. Proporciona el descubrimiento del dispositivo con conexión punto a punto o multipunto. Dos o más dispositivos conectados forman un piconet en una red ad hoc con un máximo de 8 dispositivos. En el caso de redes con más de 8 dispositivos, deben formar una configuración de scatternet, en la que los dispositivos son disponibles a través de los piconets. La especificación de Bluetooth describe una arquitectura de capas basada en una pila de protocolos, como lo muestra la figura 3.1. La capa fı́sica incluye la Host Controller Interface para comunicarse con la capa de Link Manager. La siguiente capa es denominada Logical Link Control Adaptation Protocol (L2CAP), que es un protocolo multiplexado en varios protocolos, como Service Discovery Protocol (SDP), Object Exchange Protoco (OBEX) y RFCOMM. Uno de los más usados es el RFCOMM, el cual emula la interfaz de puerto serial por medio de módulos de hardware que proporcionan la interfaz RS232 o RS485. A nivel de ésta capa, es necesiario levantar un servicio SPP(Serial Port Profile) que le permite comunicación basada en la interfaz serial.. 3.1.3.. 802.15. El Estándar IEEE 802.15 se enfoca básicamente en el desarrollo de estándares para redes tipo PAN o redes inalámbricas de corta distancia. Al igual que Bluetooth, el 802.15 permite que los dispositivos inalámbricos portátiles como PCs, PDAs, teléfonos, pagers, entre otros, puedan comunicarse e interoperar uno con el otro. Se divide en los siguientes cuatro grupos: 802.15.1,802.15.3, (802.15.3a y 802.15.3b) y 802.15.4. La especificación 802.15.1 es la base para el estándar Bluetooth. El 802.15.3 especifica las caracterı́sticas para las capas MAC y fı́sica, alcanzando velocidades de 11, 22, 33, 44, y 55 Mbps. Permite redes punto a punto a un bajo consumo de energı́a. El 802.15.4 especifica las capas MAC y fı́sica con velocidades de 250 kbps, 40 kbps, y 20 kbps, mediante 16 canales en las frecuencias de 2.4 GHz. Define comunicación basada en un coordinador, direccionamiento de 16 o 64 bits y utiliza un protocolo de handshaked que le 32.

(44) CAPÍTULO 3. AMBIENTES DOMÓTICOS BASADOS EN TECNOLOGÍAS INALÁMBRICAS. Figura 3.1: Pila de Protocolos de Bluetooth. aumenta la confiabilidad.. 3.1.4.. Zigbee. Es soportado y desarrollado por la Zigbee Alliance para operar dentro de las frecuencias de 2.4Hz, 915MHz y 968 MHz. Tiene un rendimiento de 250 kbits por segundo dentro de un rango de 100 metros. Además, soporta 128, 64 o 32 bits para encriptación Advanced Encryption Standard (AES). La capa fı́sica es desarrollada bajo el estándar IEEE 802.15.4. Se considera un protocolo más simple que Bluetooth, debido a que la pila de protocolos, mostrada en la figura 3.2, es un 10 por cierto más simple [19]. También soporta redes tipo estrella, punto a punto o h´ı́bridas.. 33.

(45) CAPÍTULO 3. AMBIENTES DOMÓTICOS BASADOS EN TECNOLOGÍAS INALÁMBRICAS. Figura 3.2: Pila de Protocolos de Zigbee y 802.15.4.. 3.2.. Principios de Diseño en Ambientes Móviles. Diseñar espacios inteligentes integrados por diferentes tipos de electrodomésticos, computadoras, dispositivos personales y de oficina, es parte de los expectativas de las redes domóticas, la computación móvil y ubicua [36]. El propósito es lograr que el usuario pueda percibir un entorno transparente y sencillo, como actualmente sucede al adquirir una televisión o un dvd. Al usuario no le importa el proveedor o la forma de comunicación del dispositivo, ya que sólo le preocupa usar el dispositivo de forma sencilla. Sin embargo, lograr estas caracterı́sticas deseables aún resulta muy costoso debido a la falta de una infraestructura estándar de hardware y software que oculte aspectos complejos de diseño. Esta infraestructura debe satisfacer medios interoperables de comunicación, de control y organización entre los diferentes dispositivos. Por ello, es necesario un middleware que combine las caracterı́sticas del hardware y la tecnologı́a de software que soporte la cooperación armónica de ellos. Este middleware debe ser utilizado por los desarrolladores de aplicaciones quienes solamente se enfocan en la aplicación del usuario; sin necesidad de involucrarse en los aspectos del ambiente y ası́ disminuir los costos de desarrollo o construcción.. 3.2.1.. Complejidad de los Ambientes Móviles. Según Nakajima [26], la complejidad de desarrollar el middleware depende directamente de tres factores: 34.

(46) CAPÍTULO 3. AMBIENTES DOMÓTICOS BASADOS EN TECNOLOGÍAS INALÁMBRICAS. 1. Abtracción. Representa el nivel de abstracción deseado para el desarrollo de las aplicaciones y la dificultad de los algoritmos para el programador. 2. Ocultamiento de la complejidad. Representa las caracterı́sticas que se desean ocultar por el middleware, como son los aspectos de la distribución, la reconfiguración dinámica, autoconfiguración, la interacción, el descrubrimiento y la personalización. 3. Reducción de costos. Representa los niveles de reutilización para las aplicaciones basadas en el middleware. En el mismo sentido, en [24] [21] consideran que la complejidad depende también de la integración de los diferentes protocolos de comunicación entre los dispositivos. Si el middleware se diseña para utilizar interfaces de manera especı́fica, es decir, interfaces dependientes del protocolo, la complejidad del middleware interoperable aumenta. Es decir, O(n) = (α(n) + β(n) + γ(n))θ(n). (3.1). donde O(n) es la complejidad del middleware, θ(n) es la complejidad de las interfaces, las funciones α, β y γ, corresponden a la compejidad de abstracción, ocultamiento y reducción de costos, respectivamente. Y además: θ(n) = mk. (3.2). donde m el número de interfaces para los protocolos diferentes de los k dispositivos. Ası́, se considera que la complejidad del middleware es directamente proporcional a la interoperabilidad. Por lo tanto, es deseable un middleware que pueda adaptarse a diferentes protocolos sin necesidad de definir nuevas interfaces de comunicación e interacción.. 35.

(47) CAPÍTULO 3. AMBIENTES DOMÓTICOS BASADOS EN TECNOLOGÍAS INALÁMBRICAS. 3.2.2.. Requerimientos de los Ambientes Móviles. En [33] y [6] se define que los ambientes móviles son también sistemas distribuidos, cuyo diseño debe satisfacer los siguientes requermientos no funcionales distintivos: 1. Los elementos móviles tienen recursos limitados comparados con los elementos estáticos, como la velocidad del procesador y la capacidad de disco y memoria. 2. La movilidad es un problema de seguridad inherente, ya que el acceso a los dispositivos móviles es más suceptible a ataques de seguridad. 3. La conectividad móvil es altamente variable en rendimiento y confiabilidad, debido a la disponibilidad del ancho de banda dependiente de la ubicación. 4. Los elementos móviles dependen de la capacidad de energı́a disponible. Estas restricciones afectan los esquemas tradicionales de diseño para los modelos de datos y de comunicación en sistemas distribuidos, como cliente/servidor. Los modelos propuestos deben cubrir estos aspectos, buscando equilibrio entre el dinamismo y la adaptación de la movilidad de los clientes. La transparencia de movilidad es considerada un requerimiento funcional complejo que está fuertemente acoplado a las necesidades de las aplicaciones móviles. La tendencia es que la tecnologı́a sea transparente para los usuarios, lo cual ha propiciado la integración de este requerimiento como parte del middleware. Para ello, se deriva en los siguientes requerimientos no funcionales[28]: 1. Asincronı́a. Desacoplar los componentes del cliente y del servidor; además del envió de mensajes en multidifusión. 2. Lightweight. Debe usarse la cantidad mı́nima de funcionalidad por la mayorı́a de las aplicaciones. Y en los siguientes requerimientos funcionales: 36.

(48) CAPÍTULO 3. AMBIENTES DOMÓTICOS BASADOS EN TECNOLOGÍAS INALÁMBRICAS. 1. Reconfiguración dinámica. Debe permitir la detección de cambios sobre los recursos disponibles, ası́ como la relocalización de ellos y la notificación de los cambios. 2. Adaptación. El sistema debe tener la habilidad para reconocer necesidades desconocidas y en tiempo de ejecución adoptarlas para resolver la funcionalidad. 3. Context Awareness. El contexto debe ser considerado como una capa que vigile las caracterı́sticas del dispositivo, las actividades del usuario y el estado de los servicios. La información del contexto es un elemento básico para satisfacer estos requerimientos funcionales, es por ello que el context aware computing se encarga de proporner modelos para descubrir y reaccionar a los eventos del entorno ante la dificultad de la adquisición de la información [38]. Las aplicaciones dependen del tipo de información recabada, la cual es procesada con el fin de definir las acciones pertinentes en el sistema. Por lo tanto, es deseable que el middleware proporcione mecanismos y componentes para monitorear el ambiente de diferentes recursos, procesar los datos de manera heterogénea y almacenar el contexto. Además, incluir los mecanismos de envı́o de mensajes y la posibilidad de publicar las interfaces a medida de lo posible.. 3.3.. Arquitecturas orientadas a Ambientes Móviles. Los investigadores en computo móvil, ubicuo y distribuido han desarrollado arquitecturas y modelos que incluyen middlewares especı́ficos. El objetivo es satisfacer los requerimientos que se han definido como necesarios para soportar la transparencia de comunicación de los dispositivos móviles, Se definen esquemas que representan el estado del arte de las arquitecturas móviles. Éstas varı́an en complejidad y en el tipo de requerimientos que satisfacen. Es por esto, que a continuación se describen de manera general modelos y proyectos destacados.. 37.

(49) CAPÍTULO 3. AMBIENTES DOMÓTICOS BASADOS EN TECNOLOGÍAS INALÁMBRICAS. 3.3.1.. Modelos basados en Cliente/Servidor. Desde la perspectiva del modelo cliente/servidor para ambientes móviles, Satyanarayanan [33] propone un modelo extendido basado en el requerimiento de movilidad. Este modelo identifica cómo los clientes y los servidores son diferenciados por la manera en que satisfacen los requerimientos no funcionales mencionados en la sección 3.2. Dichos requerimientos necesitan de operaciones que clientes tradicionales deben eliminar. Básicamente, los clientes deben integran mecanismos para los estados de desconexión, replicación, conectividad débil, aislamiento de transacciones, métodos de caching, semántica de callbacks y validaciones, algoritmos de revocación y análisis de adaptación.. Figura 3.3: Ejemplo de Modelo Cliente-Servidor para Ambientes Móviles. Por otro lado, considerando que los dispositivos móviles son limitados, los mecanimos deben ser ocultados por el middleware bajo dos tipos de modelos: smart client y thin client [23]. El cliente inteligente es aquel donde la lógica del negocio es ejecutada del lado cliente, por lo que hay acceso a datos aún si se está desconectado. Para ello, se requiere un modelo de persistencia y sincronización de datos, tanto en el cliente como el servidor. El cliente ligero es basado en una arquitectura de tres capas, donde el cliente móvil sólo se enfoca a la presentación de la aplicación. El cliente móvil se supone como un microexplorador sin ejecutar aspectos de la lógica de la aplicación. Además, utiliza un middleware especı́fico, basado en pasarelas o servidores de aplicaciones que sólo se comunican a través de la infraestructura de una red inalámbrica.. 38.