Modelo Genérico para la Implentación de Servicios de Datos Dependientes de la Localización para Dispositivos Móviles Edición Única

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS MONTERREY PROGRAMA DE GRADUADOS EN TECNOLOGÍAS DE INFORMACIÓN Y ELECTRÓNICA. Modelo Genérico para la Implementación de Servicios de Datos Dependientes de la Localización para Dispositivos Móviles. Presentada como requisito parcial para obtener el grado de. Maestro en Ciencias en Tecnologı́a Informática Por Sara Cristina Oropeza Hernández Monterrey, N.L., Marzo de 2007. i.

(2) c Sara Cristina Oropeza Hernández, 2007.

(3) Modelo Genérico para la Implementación de Servicios de Datos Dependientes de la Localización para Dispositivos Móviles por. Ing. Sara Cristina Oropeza Hernández. Tesis Presentada al Programa de Graduados en Tecnologı́as de Información y Electrónica como requisito parcial para obtener el grado académico de. Maestro en Ciencias especialidad en. Tecnologı́a Informática. Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Monterrey Marzo de 2007.

(4) Instituto Tecnológico y de Estudios Superiores de Monterrey Campus Monterrey División de Tecnologı́as de Información y Electrónica Programa de Graduados en Tecnologı́as de Información y Electrónica. Los miembros del comité de tesis recomendamos que la presente tesis de Sara Cristina Oropeza Hernández sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias, especialidad en: Tecnologı́a Informática. Comité de tesis:. Dr. Raúl Valente Ramı́rez Velarde Asesor de la tesis. Dr. José Raúl Pérez Cázares. Ing. Pablo Dı́az López. Sinodal. Sinodal. Dr. Graciano Dieck Asad Director del Programa de Graduados. Marzo de 2007.

(5) A Andrés y Sebastián por recordarme que uno nunca debe perder la curiosidad ni la determinación de aprender nuevas cosas que un niño posee.

(6) Reconocimientos. Agradezco a toda la gente que me ha ayudado en la realización de mi tesis. A mis maestros por darme los conocimientos necesarios para poder desarrollar esta tesis. También agradezco de manera especial al Dr Hesham El-Rewini por sus valiosos comentarios ası́ como a Abdul Aziz, Manal Houri, Dhia Mahjoub y Rabie Ramadan, gracias a ellos pude dar el difı́cil paso de iniciar y enfocar mi investigación. A Igmar por su paciencia y por animarme en todo momento. Agradezco a Magui, a Isaı́, a Tavo, a Brenda y a Ulises por su apoyo. Agradezco a mis compañeros Rogelio y Guillermo, que me dieron ánimos para terminar esta tesis. También agradezco a mis padres por el apoyo que me han brindado para estudiar maestria. Finalmente agradezco a Dios porque no dejó que decayera mi determinación para trabajar en este proyecto.. Sara Cristina Oropeza Hernández Instituto Tecnológico y de Estudios Superiores de Monterrey Marzo 2007. vi.

(7) Modelo Genérico para la Implementación de Servicios de Datos Dependientes de la Localización para Dispositivos Móviles. Sara Cristina Oropeza Hernández, M.C. Instituto Tecnológico y de Estudios Superiores de Monterrey, 2007. Asesor de la tesis: Dr. Raúl Valente Ramı́rez Velarde. La siguiente tesis se enfoca en desarrollar un modelo genérico para servicios de datos dependientes de la localización para dispositivos móviles (del inglés Mobile Location Dependent Services, MLDS). Este tipo de servicios ha tomado gran importancia en los últimos años y su desarrollo se ha impulsado enormemente. Para proponer este modelo primero se definen los requerimientos técnicos necesarios que todo MLDS debe satisfacer. Los requerimientos técnicos se enfocan a los siguientes aspectos fundamentales: reducir el tráfico que los MLDS suponen a la red, disminuir el procesamiento llevado a cabo en el dispositivo móvil y cumplir con aspectos de seguridad para asegurar la confidencialidad y autenticidad de la información. El modelo propuesto señala una arquitectura distribuida de 3 capas y se enfoca en el aspecto central como un middleware que abstrae la funcionalidad del sistema para proveer una arquitectura extensible y escalable capaz de satisfacer las demandas de servicios de datos sin importar la implementación de los mismos. Finalmente para probar la validez del modelo propuesto se implementó una aplicación que accede al servicio de electrocardiograma y al servicio de consulta de historial de un paciente dentro de un hospital. Esta aplicación trabaja utilizando diferentes tecnologı́as de posicionamiento ası́ como implementaciones diferentes de servicios que ofrecen su funcionalidad a través del modelo propuesto..

(8) Índice general. Reconocimientos. VI. Resumen. VII. Índice de cuadros. X. Índice de figuras Capı́tulo 1. Introducción 1.1. Planteamiento del problema 1.2. Objetivo General . . . . . . 1.3. Objetivos Especı́ficos . . . . 1.4. Hipótesis . . . . . . . . . . . 1.5. Contribuciones . . . . . . . 1.6. Organización de la tesis . .. XI. . . . . . .. . . . . . .. . . . . . .. Capı́tulo 2. Marco teórico 2.1. Tecnologı́as de posicionamiento . 2.2. Trabajo relacionado . . . . . . . . 2.2.1. Requerimientos de MLDS 2.3. Implementaciones de MLDS . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. . . . .. . . . . . .. 1 2 3 3 3 3 4. . . . .. 5 5 7 7 9. Capı́tulo 3. Requerimientos técnicos para Mobile Location-Dependent Services 3.1. Flexible a las tecnologı́as de posicionamiento . . . . . . . . . . . . . . . 3.2. Alcance del descubrimiento de servicios . . . . . . . . . . . . . . . . . . 3.3. Privacidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Anuncio de servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5. Escalable y extensible . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6. Flujo de transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7. Independiente de la aplicación . . . . . . . . . . . . . . . . . . . . . . . 3.8. Baja carga en la red . . . . . . . . . . . . . . . . . . . . . . . . . . . .. viii. 12 12 13 13 14 14 15 15 15.

(9) Capı́tulo 4. Arquitectura propuesta 4.1. Aplicación estática . . . . . . . . . . . . . . . . . . . 4.2. Repositorios de servicios . . . . . . . . . . . . . . . . 4.3. Localizador . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. Operación . . . . . . . . . . . . . . . . . . . . 4.4. Servidor Proxy . . . . . . . . . . . . . . . . . . . . . 4.4.1. Operación . . . . . . . . . . . . . . . . . . . . 4.4.2. Seguridad en el proceso de comunicación entre y el dispositivo móvil . . . . . . . . . . . . . 4.5. MD-API . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1. Descripción de la interfaz MD-API . . . . . . 4.5.2. Ubicación del dispositivo móvil . . . . . . . . 4.5.3. Operación . . . . . . . . . . . . . . . . . . . . 4.6. Interacción entre componentes . . . . . . . . . . . . . Capı́tulo 5. Experimentación 5.1. Justificación . . . . . . . . . . . . . . . . . 5.2. Escenario . . . . . . . . . . . . . . . . . . 5.3. Implementación . . . . . . . . . . . . . . . 5.3.1. Resumen de componentes utilizados 5.4. Resultados . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . el servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . Proxy . . . . . . . . . . . . . . . . . . . . . . . .. 16 17 18 18 19 20 21 23 25 26 26 29 30. . . . . .. 32 32 33 34 38 39. Capı́tulo 6. Conclusiones 6.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 46 47. Apéndice A. Definición A.1. Grupo I . . . . . A.2. Grupo II . . . . . A.3. Grupo III . . . .. 48 48 51 55. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . en la implementación . . . . . . . . . . . . .. . . . . .. . . . . .. del MD-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. Apéndice B. Casos de uso del MD-API B.1. Búsqueda de servicios . . . . . . . . . . . . . . . . . . . . . B.2. Solicitud de servicios . . . . . . . . . . . . . . . . . . . . . B.2.1. Obteniendo los parámetros del servicio . . . . . . . B.2.2. Solicitud del servicio . . . . . . . . . . . . . . . . . B.2.3. Modificación-creación de información en el servicio Bibliografı́a. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 56 56 57 57 57 58 59. ix.

(10) Índice de cuadros. 4.1. Campos del mensaje . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 28. 5.1. Software utilizado en la experimentación . . . . . . . . . . . . . . . . .. 39. x.

(11) Índice de figuras. 4.1. Arquitectura genérica para un servicio móvil dependiente de la localización 4.2. Mapeo de zonas a repositorios de servicios . . . . . . . . . . . . . . . . 4.3. Diagrama de estados del localizador . . . . . . . . . . . . . . . . . . . . 4.4. Mapeo de servicios a locaciones fı́sicas . . . . . . . . . . . . . . . . . . 4.5. Mapeo de servicios a locaciones fı́sicas . . . . . . . . . . . . . . . . . . 4.6. Criterios de disponibilidad de servicios . . . . . . . . . . . . . . . . . . 4.7. Diagrama de estados del Servidor Proxy . . . . . . . . . . . . . . . . . 4.8. Diagrama de flujo de autentificación de sesión . . . . . . . . . . . . . . 4.9. Mecanismo de identificación entre el cliente móvil y servidor proxy . . . 4.10. Framework de un servicio móvil en un cliente . . . . . . . . . . . . . . 4.11. Mapeo de servicios a locaciones fı́sicas utilizando Bluetooth y WiFi . . 4.12. Diagrama de estados de comunicación de la aplicación móvil usando MD-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.13. Diagrama de actividad de los componentes de la arquitectura . . . . . .. 17 18 19 20 20 21 22 23 24 25 29. 5.1. 5.2. 5.3. 5.4.. . . . . . . . . . . . . . . . . . . la experi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34 36 37. B.1. Etapas de utilización del MD-API . . . . . . . . . . . . . . . . . . . . .. 57. 5.5. 5.6. 5.7. 5.8. 5.9.. Escenario utilizado en la experimentación . . . . . . . . . Simulación del entorno . . . . . . . . . . . . . . . . . . . Flujo de información entre elementos . . . . . . . . . . . Tablas correspondientes a las bases de datos utilizadas mentación . . . . . . . . . . . . . . . . . . . . . . . . . . Ejecución de la aplicación del dispositivo móvil . . . . . Ejecución de la aplicación del dispositivo móvil . . . . . Ejecución de la aplicación del dispositivo móvil . . . . . Ejecución de la aplicación del dispositivo móvil . . . . . Ejecución de la aplicación del dispositivo móvil . . . . .. xi. . . . . . . en . . . . . . . . . . . .. 29 30. 38 40 42 43 44 45.

(12) Capı́tulo 1. Introducción. Gracias a la expansión de los dispositivos móviles y de las redes los usuarios de dispositivos móviles tienen acceso a una gran cantidad de recursos y servicios antes limitados a las computadoras de escritorio. Todo este desarrollo ha originado una nueva tendencia en la cual los usuarios pueden acceder recursos desde cualquier lugar, en cualquier momento y en cualquier forma. Esta tendencia ha resultado en el término en inglés Mobile Location Services (MLS). Los MLS se pueden definir como servicios que integran la ubicación geográfica o posición de un dispositvo móvil con información adicional para proveer un valor agregado al usuario [22]. Los MLS han generando una gama muy amplia de servicios que van desde servicios de emergencia, servicios de navegación, servicios de información y servicios de publicidad (comercio móvil) entre otros. Este tipo de servicios utiliza la ubicación geográfica del usuario como un parámetro para proveer aplicaciones valiosas, relevantes al usuario en un determinado momento en el tiempo. De acuerdo con [14], los MLS ofrecen a los usuarios información localizable actualizada relevante a la posición de los mismos e información personalizada. A la fecha, se puede distinguir entre dos variedades de MLS: location-based services y location-dependent services. Los location-based services consisten en servicios visibles de manera permanente para el usuario, pero que adaptan sus contenidos basados en la ubicación del mismo. Este tipo de servicios se caracterizan por su capacidad de adaptación, es decir, son capaces de medir y adaptarse a las condiciones del ambiente en el cual están funcionando (ya sea el ambiente exterior como serı́a tipo y capacidad de la red, tráfico o ambiente interior como serı́a tipo de dispositivo móvil, capacidad de almacenamiento y de procesamiento). Los location-dependent services son aquellos servicios que se encuentran disponibles en ubicaciones geográficas especı́ficas. Este tipo de servicio utiliza la ubicación geográfica del usuario para buscar y proveer acceso a servicios. Los Mobile Location-Dependent Services (MLDS) pueden ser divididos a su vez en servicios para ambientes interiores (del inglés in door MLDS ) y servicios para ambientes exteriores (del inglés out door MLDS ). Inicialmente, los MLDS para ambientes exteriores tuvieron un mayor desarrollo gracias a la madurez de la tecnologı́a de posi1.

(13) cionamiento GPS. A su vez, el desarrollo de tecnologı́as de posicionamiento orientadas a redes [14] como E-OTD (Enhanced Observed Time Difference), TDOA (Time Difference Of Arrival ), AOA (Angle Of Arrival ) y mediciones de la ubicación utilizando el identificador de la celda potencializaron el desarrollo de los servicios para ambientes exteriores. Por otro lado, no se habı́a prestado mayor atención a los servicios para ambientes exteriores debido a que la aplicabilidad que estos podrı́an ofrecer no habı́a sido visualizada. Además, el desarrollo de tecnologı́as de posicionamiento en ambientes interiores habı́a encontrado limitantes como la pérdida o degradación en la señal del módem inhaámbrico causada por los materiales con los cuales se construyeron los edificios [26]. Esta situación empezó a cambiar a partir del año 2000 y una gran cantidad de investigación se ha desarrollado resultado en nuevas tecnologı́as de posicionamiento capaces de determinar la ubicación de un individuo con bastante exactitud en el interior de un edificio. Estos nuevos avances han incrementado la aplicabilidad de los MLDS en ambientes interiores. En el capı́tulo 5 se muestra una aplicación de MLDS en el interior de un edificio.. 1.1.. Planteamiento del problema. Existe una gran variedad de trabajo desarrollado en torno a los MLDS entre el cual se puede citar [3, 4, 8, 13, 19, 20]. Por un lado se tienen implementaciones que depedenden en gran medida de algoritmos propietarios para poder obtener la ubicación del dispositivo móvil y asociarla a los servicios disponibles [19, 20]. Este tipo de aplicación ofrece la desventaja de que ha sido desarrollada utilizando como base una tecnologı́a de posicionamiento especı́fica. Otras aplicaciones hacen uso de enormes cantidades de información [3] almacenada de manera centralizada originando problemas de congestionamiento y de acceso a información no permitida por falta de mecanismos de seguridad que protejan la misma. Del trabajo mencionado, solo [4,19] ofrecen una infraestructura completa y escalable capaz de proveer MLDS. Es necesarion considerar la escalabilidad y extensibilidad en los MLDS como un factor importante y no limirarse únicamente a resolver un problema especı́fico. Hasta hace pocos años, el área de MLDS no habı́a tomado mayor importancia. Actualmente, el número de aplicaciones de MLDS ha ido en aumento y se espera que crezca en los próximos años de manera dramática [14]. De acuerdo con el UMTS Forum el mercado global de los servicios móviles se va a incrementer de 0.7 billones de dólares en el 2003 a 9.9 billones de dólares en el año 2010 [5]. En consecuencia, mucho del trabajo llevado a cabo en el pasado se centró primordialmente en desarrollar aplica-. 2.

(14) ciones capaces de proveer servicios móviles dependientes de la localización ignorando principios fundamentales como son los requerimientos que todo MLDS debe satisfacer. Por este motivo, algunos esfuerzos [5, 7, 18, 23] han sido iniciados con el fin de proveer requerimientos en diferentes categorı́as y estandarizar el desarrollo de los MLDS.. 1.2.. Objetivo General. El objetivo general de esta tesis consiste en definir un modelo genérico que pueda ser utilizado para implementar cualquier MLDS sin diferenciar entre servicios interiores y exteriores. Para asegurar que el modelo sea genérico, deberá satisfacer una serie de requerimientos técnicos.. 1.3.. Objetivos Especı́ficos. • Establecer los requerimientos técnicos mı́nimos necesarios para todo MLDS. • Proveer una nueva funcionalidad permitiendo al cliente no solo obtener información, sino también modificarla según sea la aplicación. • Definir un API de programación para ser utilizado en el dispositivo móvil a fin de separar la parte de la aplicación de la parte del servicio.. 1.4.. Hipótesis. Probar que el modelo propuesto cumple con los requerimientos técnicos propuestos y es capaz de funcionar apropiadamente de tal forma que se puede estandarizar el desarrollo de los MLDS.. 1.5.. Contribuciones. En esta tesis se pueden encontrar las siguientes dos contribuciones: • Requerimientos técnicos básicos de los MLDS. • API básico de comunicación que puede ser utilizado por aplicaciones basadas en J2ME para acceder a las funciones ofrecidas por los MLDS. • Arquitectura distribuida capaz de soportar cualquier tipo de MLDS. 3.

(15) 1.6.. Organización de la tesis. El capı́tulo 2 muestra el trabajo previo recopilado. En el capı́tulo 3 se describen los requerimientos técnicos mı́nimos de un MLDS. La arquitectura propuesta en la tesis es descrita en el capı́tulo 4. En el capı́tulo 5 se encuentra la experimentación del modelo que cumple con las caracterı́sitcas descritas en los capı́tulos 3 y 4. Finalmente el capı́tulo 6 concluye esta tesis y sugiere investigaciones futuras que pueden dar continuidad a los tópicos cubiertos en esta tesis.. 4.

(16) Capı́tulo 2. Marco teórico. 2.1.. Tecnologı́as de posicionamiento. Existe una gran variedad de tecnologı́as de posicionamiento involucradas en la estimación de la posición de un dispositivo en un marco de referencia. Estas tecnologı́as se basan en modelos matemáticos y probabilı́sticos para estimar la ubicación de una terminal móvil. Las tecnologı́as de posicionamiento pueden ser divididas en dos tipos de familias [16]: las basadas en redes celulares y aquellas conocidas como tecnologı́as de posicionamiento local. La primera familia se puede subdividir a su vez en GPS, tecnologı́a orientada a red utilizando técnicas de triangulación y tecnologı́as orientadas a una red que utilizan el identificador de célula (torre transmisora) en conjunto con mediciones de radio. Por su parte, la segunda categorı́a integra tecnologı́as usadas en redes de rango limitado como son Bluetooth, 802.11, RFID e IrDA. En esta tesis se describen únicamente aquellas tecnologı́as basadas en esta última categorı́a. En el 2005 la compañı́a Skyhook Wireless diseño el sistema WPS que provee la ubicación de un dispositivo móvil en un ambiente exterior utilizando WiFi. Hasta ese momento se habı́a destinado el uso de WiFi a ambientes interioresy esto abrió la posibilidad de utilizarlo también en ambientes exteriores. Dado que existen una gran variedad de access points instalados en las calles y edificios, esta compañı́a se dio a la tarea de almacenar en una base de datos global los identificadores de cada access point y posteriormente por medio de un algoritmo privado triangfular la ubicación del dispositivo [24]. Esta tecnologı́a ofrece el mismo esquema de localización basado en coordenadas geográficas utilizado por GPS. En su trabajo Vossiek et al. [27] proponen un sistema que puede ser utilizado tanto en ambientes interiores como exteriores capaz de proveer una precisión de 5 a 15 m utilizando WLAN 802.11. Este sistema permite obtener la ubicación de un individuo en movimiento en un tiempo de 2 a 5 segundos. La ubicación proporcionada se encuentra en coordenadas geográficas estándares. Cabe mencionar que el cálculo de la ubicación. 5.

(17) es llevada a cabo en el dispositivo móvil, contrastando con otros trabajos en los cuales existe un servidor dedicado a determinar las coordenadas del dispositivo. Por otro lado, Wang et al. propone un sistema utilizando WLAN 802.11 en el cual la medición se lleva a cabo en la terminal móvil para ser enviada posteriormente a un servidor el cual hace los cálculos necesarios para estimar la ubicación de la terminal. El modelo de esta aplicación consiste de tres entidades, una encargada de hacer las mediciones, otra de procesar y calcular la ubicación y una tercera entidad utilizada como punto de referencia. En este caso la referencia requiere mantenerse a menos de 15 metros de la terminal para obtener una medición correcta. Este trabajo resulta un tanto limitado ya que la presencia de una referencia debe existir en todo momento a fin de poder estimar la ubicación de la terminal. Un sistema altamente existoso y con varios seguidores es RADAR [1] propuesto por Microsoft en el año 2000. Este sistema consta de dos fases: durante la fase previa, el usuario ubicado en el área de medición elige al azar puntos que serán utilizados como coordenadas de referencia. Cada punto es asociado con una coordenada (x,y) ası́ como una medición de la intensidad de señal en ese punto. Toda esta información se almacena en una base de datos y es durante la segunda fase que el sistema detectará la intensidad de señal de la terminal móvil y utilizando técnicas de triangulación y las intensidades almancenadas determinará la ubicación aproximada de la terminal. Los autores señalan que la precisión de su sistema está ı́ntimamente relacionada con el número de puntos elegidos en la fase previa. Un aspecto interesante que se propone es estudiar los patrones de movilidad del usuario basados en organización del edificio, fechas, historial del usuario, etc., de tal forma que exista una mayor concentración de puntos de referencia en ciertas zonas. En [10] se propone un sistema semejante a RADAR en el cual se almacenan coordenadas asociadas con la intensidad de señal. En ambos sistemas, la ubicación del dispositivo es calculada remotamente. Hasta ahora se ha hablado de sistemas basados en WLAN 802.11. Cabe mencionar que las implementaciones que utilizan Bluetooth difieren en cuanto a la manera de calcular la ubicación de la terminal, sin embargo ofrecen una precisión casi idéntica a la obtenida al utilizar WLAN 802.11. En [29] se propone un sistema capaz de determinar la ubicación de una terminal móvil sobre un eje coordinado. El esquema de localización es administrado por un servidor central que obtiene información de las estaciones base. La precisión del sistema oscila en ±5 metros.Hallberg et al. [6] propone un sistema similar a RADAR en el cual la terminal móvil obtiene parámetros necesarios para calcular su ubicación y los envı́a a un servidor el cual los procesa y determina la ubicación de la terminal con un grado de error de ±1,7m.. 6.

(18) 2.2. 2.2.1.. Trabajo relacionado Requerimientos de MLDS. A pesar de que las aplicaciones móviles son diferentes en naturaleza unas de otras, comparten ciertas caracterı́sticas que las distinguen de otro tipo de aplicaciones. En su trabajo Gianglis [5] señala que los MLDS han sido los últimos en entrar al mercado y por tal motivo, el desarrollo que han tenido no ha cubierto en su totalidad su potencial y sus implicaciones. Entre los aspectos importantes cubiertos en este trabajo podemos se observa el hincapié a clasificar las aplicaciones basadas en sus requerimientos de exactitud y el ambiente en donde serán ofrecidas. Además, el autor se centra en definir los modelos de negocio separando a los proveedores de tecnologı́as de posicionamiento de los proveedores de servicios. Se hace incapié en la protección a la privacidad como un factor determinante ası́ como en la regulacion y estandarización para segurar el éxito de esta tecnologı́a. Esto es debido a que los MLDS dependen a su vez de otras tecnologı́as para funcionar y dar valor agregado a los servicios. Aunque estos servicios puedan ser considerados l̈ocalesës importante tener en mente que millones de usuarios harán uso de ellos mientras se encuentran dentro de sus lı́mites. Por tal motivo, es importante asegurar una transición sea transparente al pasar de un servicio a otro. En su trabajo, Snoeren [23] se centra en definir los requerimientos para un servicio localizable escalable y general. El autor deja de lado los mecanismos rastreo pero sostiene que el dispositivo debe mantenerse conectado a la red a fin de ser localizable. Además propone que exista un servicio ubicuo capaz de recolectar y administrar los datos de la ubicación de las terminales móviles. Es necesario que la red soporte los mecanismos de ubicación del usuario de tal manera que si un mecanismo externo de localización se encuentra ausente, el dispositivo sea capaz de estimar su ubicación lógica dentro de una red. Este punto resulta vago debido a que una red no necesariamente refleja la ubicación exacta de un dispositivo, en especial si se habla de redes alámbricas en las cuales los ruteadores pueden ser las entidades más cercanas utilizadas para determinar la ubicación del dispositivo. La principal contribucación de este artı́culo consiste en la definición de locación. Existen una gran variedad de maneras en que la ubicación de un dispositivo puede ser medida. En este artı́culo se divide a los métodos de medición de ubicación en absolutos y relativos y se propone que cada ubicación geográfica sea dividida en contenedores o zonas que ofrezcan a su vez subdivisiones. Estas zonas pueden estar dadas por coordenadas geográficas o por agrupaciones de objetos que ofrecen un servicio. En [7] Tsalgatidou et al. hace una clasificaciñon de los requerimientos para MLDS en 6 categrı́as diferentes. La primer categorı́a hace referencia a los requerimientos. 7.

(19) de usuario o lo que se conoce en ingenierı́a de software como requerimientos funcionales [12]. Estos requerimientos se enfocan en definir qué esperarı́a un usuario que un servicio móvil hiciera para satisfacer una necesidad. Entre los requermientos mencionados se encuentran los aspectos visuales como mapas de la ciudad, directorios de servicios y acceso personalizado. Además se espera que el servicio se haga visible solamente cuando se el usuario se encuentra dentro de su área de cobertura. El acceso al servicio debe ser lo suficientemente rápido para evitar la pérdida de interés del usuario. Por último además de la información proveı́da por el servicio se puede proporcionar información como fotografı́as, puntos de interés, información acerca de objetos cercanos y mapas de rutas del área en la que se encuentra el usuario. Los requerimientos de usabilidad corresponden a la segunda categorı́a y se enfocan en disminuir el procesamiento dentro del dispositivo móvil ası́ como la cantidad de datos enviados por la red. Además sugiere la posibilidad de utilizar un servicio de manera offline. El aspecto de una interfaz de usuario sencilla y de fácil uso debe ser un factor obligatorio en cualquier aplicación móvil. Los requerimientos de confiabilidad engloban 3 factores: confiabilidad en los datos recibidos, confiabilidad del software utilizado y precisión de los algoritmos dependiendo de la tarea que se este ejecutando. Todos ellos se basan en la localización proveı́da por una entidad externa. La categorı́a referente a los requerimientos de privacidad hace incapié en asegurar la visibilidad de la información solamente a aquellas personas autorizadas. En la quinta categorı́a se describen los requerimientos que la infraestructura de posicionamiento debe proveer. Entre ellos encontramos utilizar métodos que proveen una precisión sujeta a limitaciones de costo, maximización del área donde el servicio es ofrecido, respuesta casi instantánea para aplicaciones de alto impacto como son servicios de emergencia, posibilidad de localizar a todos los dispositivos móviles dentro de un área ası́ como localizar varios dispositivos simultáneamente sin sobrecargar la red. Finalmente, los requerimientos de interoperabilidad asegurarı́an el uso de diferentes tecnologı́as que van desde diferentes sistemas de coordenadas para posicionamiento y uso de diferentes dispositivos móviles como celulares y PDAs. pervisive computing consiste en combinar una gran cantidad de pequeños dispositivos en un ambiente para proveer a un usuario de información. Posee similitudes con los servicios móviles en cuanto a los mecanismos necesarios para acceder a la información/servicios que estos ofrecen. En [18] se observan importantes contribuciones que pueden ser aplicables en el área de los MLDS. Los componentes de protocolo cubiertos incluyen nombramiento de atributos y servicios, método de comunicación inicial, alcance de descubrimiento del servicio, selección de servicios, descubrimiento y registro a un servicio, infraestructura de descubrimiento de servicios, información del estado del servicio e invocación del mismo. Todos estos componentes constituyen un eslabón importante en el diseño del descubrimiento de servicios. Estos aspectos intentan disminuir la cantidad de información que fluye a través de la red y ası́ como el procesamiento 8.

(20) llevado a cabo en el dispositivo móvil. Finalmente, el autor cubre aspectos como seguridad y privacidad considerándolos caracterı́siticas primordiales para proteger usuarios, dispositivos y servicios. Para ello es posible aplicar mecanismos de ocultamiento de servicios en varias etapas del descubrimiento el mismo. Esto ofrece la ventaja de exposición innecesaria de los servicios y adicionalmente se proveen mecanismos para restringir el acceso a los mismos una vez que estos sean descubiertos.. 2.3.. Implementaciones de MLDS. Las implementaciones de MLDS pueden ser divididas en dos categorı́as: aplicaciones que incorportan y adaptan la tecnologı́a de posicionamiento a su implementación y aplicaciones que separan la tecnologı́a de posicionamiento. En [20] Garcı́a et al. propone una aplicación móvil que proporciona servicios de información y reservación de restaurantes dentro de un complejo comercial. El área de cobertura se encuentra definida y equipada con Bluetooth access points. La implementación se enfoca en la determinación de la ubicación de la terminal móvil utilizando Bluetooth. El sistema consta de una arquitectura distribuida basada en CORBA. Hay 3 entidades fundamentales que se encargan de proveer los servicios a los usuarios: agente administrador de servicios (núcleo del sistema) que provee servicios al cliente. Existe un agente diferente por cada servicio. El profile agent se encarga administrar las preferencias de los usuarios. Esta información debe ser alimentada por el usuario cuando accesa el sistema. Por último se encuentra el agente de localización encargado de obtener la ubicación de la terminal y notificársela al agente administrador de servicios adecuado. Dentro de los aplicaciones con tecnologı́a de posicionamiento independiente se encuentran [3, 4, 8, 19]. En [4] se propone un sistema hı́brido que combina servicios para ambientes interiores y exteriores. La principal contribución de esta arquitectura consiste en disminuir los costos de desarrollo de un sistem multi servicios. Una contribución igualmente importante consiste en utilizar un enfoque orientado a zonas que reduce el esfuerzo realizado para encontrar un servicio. Cada zona está descrita por una serie de coordenadas ası́ como una descripción. Un sistema distribuido compuesto por el servidor de aplicaciones, el servidor de topologı́a y el servidor del usuario conforma la arquitectura del sistema. Cada servidor asocia una base de datos con información especı́fica. El servidor de aplicaciones es el motor que hace uso de los recursos del servidor de topologı́a para obtener mapas de ubicación y los recursos del servidor de usuario para obtener información acerca de la ubicación de los usuarios. La arquitectura del lado del cliente está basada en dos agentes de comunicación. Uno de ellos encargado de obtener los mapas del edificio en caso de que la terminal se encuentre en un ambiente interior y el discovery agent, encargado de notificar la ubicación actual de la terminal. 9.

(21) al servidor de usuario. Para distinguir entre ambientes interiores y exteriores la arquitectura proporciona un API de localización que utiliza puntos de referencia para hacer el cambio entre un contexto y otro (en este caso el contexto incluye la tecnologı́a de posicionamiento). Además de proponer un sistema independiente de la tecnologı́a de posicionamiento, [8] propone una arquitectura capaz de agregar o remover componentes sin depender de un control centralizado. Este sistema es similiar a [4] en el aspecto de proponer alcances de servicios (service scope) o contextos sobre los cuales el servicio puede ser ofrecido. Estos service scopes pueden ser contenidos a si vez por otros services scopes de tal forma que se heredan los servicios ofrecidos por el contexto contenedor. Los contextos se comunican entre ellos utilizando CORBA trading service. El servicio AROUND es el encargado de detectar el cambio de un contexto a otro y notificar a la aplicación del nuevo contexto al que ha ingresado. Posteriormente la aplicación contacta a un servicio de nombres y proporciona el nombre del nuevo contexto a fin de obtener la referencia a uno o más servidores AROUND que contienen los servicios disponibles para ese contexto. Finalmente la aplicación solicita a cada servidor los servicios disponiles y selecciona aquellos que cumplan con sus necesidades de información. En [3] se propone un framework para el diseño de MLDS y una aplicación distribuida basada en agentes que acceden los servicios disponibles en zonas. Una vez más aparece la definición de contextos para proveer modularidad en el diseño de MLDS. Un contexto de servicios consiste en una abstracción del lugar en el que un agente es ejecutado. A través de él, es posible acceder a una serie de servicios localmente disponibles. Dicho contexto de servicio puede modelar desde un nodo de red hasta un dominio administrativo dentro de una red o un access point. Bajo este esquema la movilidad de un agente es modelada en base al cambio de contextos, muy semejante a la implementación propuesta en [8]. Los contextos de servicios son, entidades configurables independientemente programadas e implementadas de acuerdo a ciertas reglas basadas en el tipo de servicios a los que proveen acceso. Dentro de cada contexto de servicio se pueden encontrar una serie de tuple spaces (repositorio compartido de información) que pueden ser accesados y proportcionan información parcial de los servicios basados en niveles de acceso dados por la identidad del usuario. Los agentes residen en el dispositivo móvil como entidades intermediarias entre servicios y aplicaciones. Además de los agentes encargados de proveer servicios, existen otros agentes destinados a comunicar contextos de servicios. Finalmente, el concepto de privacidad del servicio se basa en la identidad del usuario. El agente residente en la terminal móvil es capaz de atrapar eventos de conexión a la red para después obtener acceso a un tuple space del cual podrá obtener información que ha sido previamente filtrada basada en el contexto de servicio.. 10.

(22) Finalmente, Ratsimor et al. [19] proponen Agents2Go una arquitectura distribuida para proveer MLDS. La arquitectura propuesta segmenta funcionalidades haciendo de Agents2Go un sistema escalable y tolerante a fallos. La arquitectura se compone de 5 elementos: una aplicación del lado del cliente encargada de capturar las solicitudes de servicios provenientes del usuario y de mantener comunicación con la entidad que presta los servicios. Existe un componente central llamado A2G Server encargado de recibir y procesar las solicitudes provenientes de la aplicación móvil. Este componente actua como mediador entre los elementos de la arquitectura y la aplicación en el cliente móvil. Para asociar la localización del dispositivo con los servicios disponibles se utiliza un servidor localizador conectado a diferentes servidores que ofrecen servidio a zonas de cobertura especı́ficas. Cada uno de estos servidores se conecta a una base de datos distribuida que contiene información acerca de los diferentes servicios en la zona. Cuando el A2G Server recibe una solicitud del dispositivo móvil la envı́a al localizador el cual determina quien puede satisfacer dicha solicitud de servicio basándose en la ubicación de la terminal móvil. A continuación envı́a dicha solicitud al servidor capaz de satisfacerla. La respuesta es enviada nuevamente al A2G Server quien almacena ciertos parámetros a fin de utilizarlos como caché para futuras solicitudes y envı́a las respuestas al cliente. Este sistema utiliza un concepto similar a los contextos de servicio al almacenar toda la información referente a un área de cobertura en un servidor o servidores administrados por la entidad del área de cobertura en la que existen. Entre las aportaciones ofrecidas en [19] se encuentra la administración de procesamiento de tal forma que la aplicación móvil actual exclusivamente como el front end de todo el sistema.. 11.

(23) Capı́tulo 3. Requerimientos técnicos para Mobile Location-Dependent Services. En el pasado, el enfoque de los MLDS se enfocó a las aplicaciones comerciales [3, 19, 20]. En nuestros dı́as, la aplicabilidad de los MLDS ha ido en incremento y es posible encontrar otro tipo de aplicaciones como servicios de emergencia, servicios de navegación, servicios de información, anuncios, servicios de rastreo y servicios por cobrar [5]. A pesar de su enorme impacto, los MLDS continúan siendo una tecnologı́a joven en el mercado y por consecuencia, no existe una unificación en cuanto a los requerimientos que estos deben satisfacer. Aunque se ha realizado una gran cantidad de investigación en la implementación de MLDS para la solución de un problema especı́fico [2, 3, 8, 13, 19, 20], la atención que ha sido puesta en la definición de requerimientos técnicos que definan los componentes necesarios para definir e implementar MLS eficientes ha sido mı́nima. A continuación se describen los diferentes tipos de requerimientos técnicos para servicios de móviles dependientes de la localización.. 3.1.. Flexible a las tecnologı́as de posicionamiento. Actualmente existen varias alternativas de tecnologı́as de posicionamiento [1, 6, 9, 10, 16, 24, 27–29] para ambientes interiores y exteriores. La heterogeneidad de dichas tecnologı́as depende en gran medida del grado de precisión y exactitud que cada una provee y del algoritmo utilizado para ubicar al dispositivo en un área dada. En el caso de ambientes interiores se utiliza una locación simbólica dada por un plano de dos o tres dimensiones mapeadas sobre el marco de referencia de un área como puede ser una habitación o piso. Por otro lado, en ambientes exteriores el método más popular consiste en proveer una ubicación fı́sica dada por las coordenadas de latitud y longitud respecto al eje terrestre. En consecuencia, un servicio que depende de la localización debe ser capaz de adaptar la información proveı́da por la tecnologı́a de posicionamiento a fin de ubicarse en algún plano de referencia. Además, se debe considerar la posibilidad de utlizar 12.

(24) simultáneamente varias tecnologı́as de posicionamiento para mejorar el grado de precisión cuando se localiza a un dispositivo móvil. De la misma manera, es posible que conforme un dispositivo móvil se vaya desplazando utilice diferentes tecnologı́as de posicionamiento lo cual puede incluir su paso de un ambiente exterior a uno interior o viceversa [4].. 3.2.. Alcance del descubrimiento de servicios. Como se mencionó anteriormente, los servicios móviles localizables pueden ser divididos en 2 clases: location-dependent services y location-aware services (también llamado location-based services) [14, 23]. La clasificación de los servicios móviles localizables puede utilizarse como punto de inicio para decidir el alcance del descubrimiento de servicios por una aplicación móvil. La clasificación del alcance de descubrimiento de servicios propuesto en [18] y utilizado para el cómputo ubı́cuo puede aplicarse a nuestro estudio. Para los location-based services una topologı́a de red puede ser suficiente para delimitar los servicios disponibles. Es decir, el usuario podrá descubrir los servicios sı́ y solo sı́ si se encuentra en una red que los proporcione. En el caso de los location-dependent services, el alcance del descubrimiento de servicios se hace basado en la ubicación geográfica del usuario. En ambos casos se puede incluir los privilegios del usuario para acceder a los servicios aún cuando esté se encuentte en posición de descubrirlos. Este último aspecto permite incrementar la seguridad de acceso a la información, aspecto poco tomado en cuenta en las primeras implementaciones de MLDS.. 3.3.. Privacidad. Inicialmente las aplicaciones de MLDS fueron concebidas como servicios de anuncios publicitarios accesados indistintamente por varias personas. Por consecuencia, la aplicación accesada por cada usuario era la misma y la única amenaza residió en que una entidad maliciosa modificada la información proveı́da por el servicio. Actualmente la aplicabilidad de los servicios basados en la localización se ha extendido a instituciones como hospitales, organizaciones privadas y al comercio electrónico; en todas ellas la privacidad de la información se vuelve un aspecto fundamental [7]. De aquı́ podemos derivar dos aspectos importantes para asegurar la privacidad de la información: • La información viaja por redes inseguras y por tal razón debe ser cifrada. Solo los usuarios autorizados pueden ser capaces de descifrarla. • Solo usuarios autorizados deben ser capaces de acceder un servicio. En este caso, dos casos particulares se deben considerar: a) Los usuarios pueden descubrir todos 13.

(25) los servicios existentes en una zona y ser autentificados por cada servicio por separado. b) Los usuarios poseen un perfil global que indica los servicios a los cuales tienen acceso. Por consecuencia, los servicios a los que el usuario no tiene acceso ni siquiera son mostrados en la etapa de descubrimiento de servicios. En particular, la estrategia propuesta en b) puede resultar útil cuando el usuario tiene un perfil global manejado por un proveedor de servicios.. 3.4.. Anuncio de servicios. El número de usuarios que acceden a un servicio depende de la naturaleza del mismo. Basados en esta premisa, se pueden plantear dos estrategias diferentes para adquirir conocimiento de los servicios existentes en un área. La primera estrategia se enfoca en el caso en el cual una gran cantidad de usuarios desean saber acerca de la existencia de servicios. En este esquema, el servicio debe ser anunciado periódicamente a los usuarios. En consecuencia, se reduce la carga de la red ya que solo una entidad está notificando su existencia y únicamente aquellos individuos interesados proseguirán a contactarlo. En la segunda estrategia el dispositivo móvil envı́a un mensaje solicitando los servicios disponibles. Este mensaje puede ser enviado periódicamente o cuando el usuario detecta que se ha movido de una red a otra. Esto resulta particularmente útil cuando el número de usuarios que acceden al servicio es mı́nimo; por lo tanto la cantidad de tráfico en la red también se minimiza. Los dispositivos móviles poseen capacidades limitadas de almacenamiento y de memoria. Además, la heterogeneidad de los MLDS [5] deja en claro que es poco práctico almacenar las diferentes solicitudes de formatos de servicios. En base a esto, es necesario que el servicio provea al dispositivo móvil de un formato de servicios [19] que contenga una descripción de los datos que se pueden obtener. Ası́, cualquier aplicación más o menos genérica en el dispositivo móvil puede adaptarse dinámicamente para solicitar y mostrar la información de un servicio.. 3.5.. Escalable y extensible. Gracias a que la aplicabilidad de los MLDS se ha incrementado, está en claro que en un futuro no muy lejano los servicios ofrecidos bajo este esquema no pertenecerán exclusivamente al área del comercio móvil. La infraestructura que provea estos servicios debe estar preparada para agregar más usuarios y funcionalidades sin sufrir modificaciones drásticas.. 14.

(26) 3.6.. Flujo de transacciones. Inicialmente los MLDS fueron concebidos exclusivamente para proveer información basados en solicitudes de clientes móviles [3, 14, 19]. Aplicaciones como yellow pages y comercio móvil se basaron en el paradigma cliente servidor. También los servicios se enfocaron a la difusión de información basados en la ubicación del usuario [20]. Actualmente la implementación de MLDS incluye transacciones en las cuales el cliente envı́a información y el servicio la procesa. Para esta caso particular, el cliente solicita un servicio, obtiene la información que desea y la actualiza. Un ejemplo de esto se puede apreciar en [2].. 3.7.. Independiente de la aplicación. Como se mencionó con anterioridad, existen una gran variedad de aplicaciones para MLDS. Cada una ataca diferentes problemas y por consiguiente, proveerá de información en formatos diferentes al usuario. Es muy probable que unas aplicaciones serán más sofisticadas que otras y es posible que incluyan mapas, imágenes e inclusive audio. Sin importar el tipo de datos que el servicio provea, la aplicación debe ser capaz de mostrarlas al usuario. Sin embargo, las operaciones llevadas a cabo entre la aplicación y el servicio deben ser iguales. En conclusión, debe haber una entidad capaz de interactuar y definir las operaciones necesarias que serán llevadas a cabo por el cliente para acceder a un servicio. La aplicación se reduce a una entidad que extrae la información, le da formato y la despliega al usuario.. 3.8.. Baja carga en la red. Los MLDS deben ser capaces de minimizar el volumen de datos que van a transferir [7]. Aún cuando el servicio provea información a uno o a múltiples usuarios, la cantidad de datos transmitidos debe ser minimizada. Este requerimiento en particular tiene una relación muy cercana con las semántica que define al servicio. Esta situación ya se ha presentado en otras aplicaciones como el uso de internet en dispositivos móviles con capacidad de cómputo reducida.. 15.

(27) Capı́tulo 4. Arquitectura propuesta. En la sección anterior se cubrieron una serie de requerimientos técnicos que toda aplicación móvil dependiente de la localización debe implementar. Esta sección propone una arquitectura distribuida que implementa MLDS y que cumple con los requerimientos ya mencionados. Los MLDS pueden ser visualizados como servicios que obtienen información de bases de datos remotas. Sin embargo, los mecanismos intermedios entre la información y el cliente son el fundamento que permite la implementación de estos servicios. Entre las ventajas ofrecidas por esta arquitectura se encuentra que cada capa puede ser reemplazada independientemente cuando los requerimientos que la definen o la tecnologı́a que la implementa cambia. Cada capa realiza operaciones bien definidas [12]: • La capa de presentación engloba aspectos relacionados con la interfaz de usuario, ası́ como el formato de la información. Generalmente esta capa reside en el cliente y es, la que menos capacidad de procesamiento requiere. • La capa de aplicación o del negocio en cual se lleva a cabo todo el procesamiento para obtener la información y hacerla llegar a la capa de presentación. Esta capa puede llegar a ser tan compleja como la aplicación requiera y puede conformarse de varios componentes. • En la capa de datos se encuentra se almacena y estructura la información. Esta capa incluye los mecanismos fundamentales de acceso a la misma, es decir, las operaciones atómicas que permiten acceder la información de una base de datos. Para acoplar cada una de estas capas, existen interfaces bien definidas. Durante el desarrollo de esta tesis se hará un enfoque especial en la interfaz que acopla la capa de presentación con la capa de negocio. Por su caracterización, los MLDS pueden ser implementados de manera natural como sistemas distribuidos [8,19]. La figura 4.1 muestra la arquitectura distribuida de tres capas propuesta que soporta la implementación de cualquier MLDS. Esta arquitectura se basada en la propuesta en [19]. La arquitectura 16.

(28) consiste en los siguientes elementos: interfaz MD-API residente en el dispositivo móvil, Servidor Proxy, Localizador, repositorios de servicios y una aplicación estática residente en una Terminal de escritorio.. Figura 4.1: Arquitectura genérica para un servicio móvil dependiente de la localización Se ha incorporado una nueva funcionalidad en la arquitectura propuesta la cual consiste en permitir a la aplicación estática obtener, modificar y agregar información a los repositorios de servicios. Esta funcionalidad permiten que el servicio sea modificado y accesado por sus diferentes usuarios, ya sean móviles o estáticos.. 4.1.. Aplicación estática. Es una aplicación cliente-servidor, en la cual los clientes acceden a los servicios alojados en los repositorios de información modificando y visualizando sus contenidos. A primera vista puede resultar inapropiado permitir que un cliente estático accese servicios que solo son disponibles desde ciertas ubiaciones geográficas. En este caso, el usuario estático puede ser un administrador el cual puede modificar la información proveı́da por el servicio. De igual manera, es posible que un usuario pueda acceder al servicio móvil desde una terminal fija basado en los privilegios dados por su identidad. Por ejemplo, suponga que en un hospital la enfermera recepcionista es capaz de dar de alta pacientes y acentuar en sus historiales médicos información básica como tipo sanguı́neo, nombre, edad, etc. Por otro lado una enfermera que patrulla y accede el servicio de historial del paciente en la ubicación en la cual es ofrecido es capaz solamente 17.

(29) de modificar la información del paciente, más no es capaz de crear el historial médico de un paciente.. 4.2.. Repositorios de servicios. Almacenan los diferentes tipos de servicios incluyendo sus definiciones, la información que proveen y los mecanismos para permitir el acceso a los mismos. La información contenida en los repositorios de servicios se almacena basándose en la cercanı́a entre servicios. Por ejemplo, si los servicios A y B residen en la misma zona, la información que éstos proveen se encuentra almacenada en el mismo repositorio. Por lo tanto cada repositorio de servicios mapea una ubicación geográfica. Una ventaja de este mapeo es que se prepara la infraestructura para que en un futuro un proveedor de servicios administre los servicios ofrecidos en una ubicación en particular (por ejemplo, guı́as turı́sticas, información de tiendas, etc). Además se agiliza el proceso de búsqueda del servicio ya que la localización del servicio no se efectúa sobre todos los repositorios. La figura 4.2 muestra el proceso de división por zonas.. Figura 4.2: Mapeo de zonas a repositorios de servicios. 4.3.. Localizador. Un aspecto importante de un servicio dependiente de la localización es que el dispositivo móvil debe hacer todo lo posible para descubrir los servicios existentes en su ubicación actual, sin ofrecer la opción de un descubrimiento global de servicios, es decir, la búsqueda de todos los servicios existentes en la red [21]. El localizador el encargado de localizar el repositorio al que corresponde una solicitud de servicio dada por una ubicación. El localizador puede verse como un gran directorio en el cual se mapean 18.

(30) las zonas a repositorios de servicios. En consecuencia, encuentra exclusivamente los servicios próximos a la ubicación actual del dispositivo móvil.. 4.3.1.. Operación. El localizador es una entidad pasiva dentro la arquitectura. Se comporta de manera similar a un enrutador, obteniendo solicitudes y reenviándolas al repositorio de servicios adecuado basándose en la ubación del cliente. La figura 4.3 muestra el diagrama de estados del localizador. El localizador puede recibir 2 tipos de mensajes: Solicitud de servicios y solicitud de servicio especı́fico. Ambos tipos de mensajes proveen al localizador de una ubicación geográfica que se utilizará como delimitador en el proceso de ubicación del repositorio de servicios que contiene dicho servicio.. Figura 4.3: Diagrama de estados del localizador La parte medular de la operación del localizador es la localización del repositorio de servicios que contiene al servicio. Para ello, el localizador agrupa rangos de locaciones a un área general. Una vez localizada el área general, se desglosan los diferentes tipos de servicios mapeados a otro rango de locaciones más pequeño. El localizador posee una serie de tablas con dicha información y utiliza referencias a otras tablas que contienen a su vez, mapeos de direcciones a otras tablas o al repositorio de servicios que almacena dicho servicio. Por ejemplo suponga la conferencia de investigación de la figura 4.4 ubicada en el primer piso de un hotel donde se ofrecen 2 tipos de servicios a los expositores participantes . El primero serı́a el servicio de impresión y el segundo un servicio de consulta para verificar el programa ofrecido en cada habitación. Como se puede apreciar, 2 servicios son ofrecidos en una misma habitación. El dispositivo móvil localizado en las coordenadas (10,2) envı́a una solicitud para 19.

(31) Figura 4.4: Mapeo de servicios a locaciones fı́sicas descubrir los servicios existentes. El localizador recibirá esta solicitud a través del servidor Proxy e iniciará el proceso de descubrimiento de los servicios. En la figura 4.5 se observan las tablas para los servicios de impresión y de consulta de programa ofrecido en la habitación.. Figura 4.5: Mapeo de servicios a locaciones fı́sicas. 4.4.. Servidor Proxy. Este componente recibe los mensajes provenientes del dispositivo móvil, los procesa y envı́a a la entidad requerida para darles servicio. Modela la asociación existente entre ubicación fı́sica y criterios especı́ficos que determinan qué servicios existen cerca 20.

(32) del dispositivo móvil. Esta asociación se describe en la figura 4.6.. Figura 4.6: Criterios de disponibilidad de servicios Como puede observarse en el diagrama, un servicio puede ser descubierto si y solamente si el usuario se encuentra dentro del área de en la cual es servicio es ofrecido y cumple además con los criterios para poder acceder al mismo. Los criterios están dados por factores como la seguridad, la contratación de dicho servicio, o la jerarquı́a del usuario dentro de una organización. Además de actuar como un filtro para el descubrimiento de servicios, el servidor Proxy realiza las siguientes tareas: • Provee al dispositivo móvil de parámetros para acceder cualquier servicio. • Establece una sesión una vez que el usuario ha sido identificado • Mantiene un control de los servicios disponibles usando la ubicación del dispositivo móvil. • Redirecciona las peticiones de servicios al localizador. • Ocultar la infraestructura que sustenta a los servicios móviles actuando como mediador entre el dispositivo móvil y el resto de los componentes de la arquitectura. • Actúa como directorio de servicios. 4.4.1.. Operación. Igual que el localizador, el servidor Proxy esta definido como una entidad pasiva dentro de la arquitectura debido a que solamente atiende solicitudes del dispositivo móvil. En la figura 4.7 se aprecia el diagrama de estados del servidor Proxy. Como se puede apreciar, el servidor Proxy puede procesar tres tipos de solicitudes provenientes 21.

(33) del dispositivo móvil: solicitud de servicios, solicitud de formato de servicio y solicitud de servicio especı́fico. Cuando el servidor Proxy recibe una solicitud de servicios, este autentifica al usuario y obtiene los servicios existentes en la ubicación actual del mismo. Posteriormente aplica criterios basados en la identidad del usuario para obtener únicamente los servicios a los cuales este puede acceder, les asigna un identificador y los asocia con un Identificador de sesión obtenido en el proceso de autentificación del usuario. Como resultado, se crean parejas únicas de tipo (id sesión válida, id servicio) para distinguir los servicios disponibles. Posteriormente, envı́a los identificadores del servicio al dispositivo móvil. Este proceso es llamado establecimiento de sesión y se mantendrá válido mientras el usuario se mantenga dentro del alcance de dichos servicios. Si el dispositivo móvil no mantiene una comunicación con el Proxy Server, su sesión se elimina después de un tiempo determinado. La duración de una sesión depende del tipo de servicio móvil que se está implementando.. Figura 4.7: Diagrama de estados del Servidor Proxy Cuando el usuario solicita un servicio o un formato de servicio especı́fico, se prosigue a validar si el usuario se encuentra dentro del área de cobertura del servicio. Si el usuario no se encuentra dentro del área de cobertura, entonces se elimina 22.

(34) dicho servicio de la lista de servicios disponibles para el usuario y se envı́a la correspondiente notificación al dispositivo móvil. El la figura 4.8 muestra el diagrama de flujo que describe este proceso.. Figura 4.8: Diagrama de flujo de autentificación de sesión. 4.4.2.. Seguridad en el proceso de comunicación entre el servidor Proxy y el dispositivo móvil. En [21] se propone que al diseñar protocolos de comunicación, es necesario definir ciertos criterios para asignar funcionalidad a cada capa. En este artı́culo, Saltzer et. Al. argumenta que basado en los requerimientos de una aplicación es posible ubicar la implementación de funciones a capas superiores. Esto es, proveer mayor robustez a la aplicación y no a los mecanismos que hacen posible su implementación. Esta tesis se enfoca a los mecanismos que hacen posible la implementación de MLDS. Aspectos como criptografı́a y seguridad son considerados detalles crı́ticos de diseño de la aplicación y pueden variar dependiendo del tipo de servicio móvil que se desee implementar. Para proveer la seguridad adecuada en aplicaciones móviles donde la confidencialidad de la información se vuelve un factor determinante, es necesario tomar en consideración los siguientes aspectos fundamentales de seguridad de la información: • Un usuario requiere de autorización para tener acceso a un servicio particular. 23.

(35) Dicha autorización viene dada por la identidad del usuario y esta formada de una pareja de identificador de usuario y password. • Es necesario identificar si el usuario es quien dice ser, aún y si provee la información necesaria ( identificador de usuario y password) • Es necesario identificar al proveedor de servicios antes de proveerle cualquier información confidencial. • Una vez que se ha identificado al usuario, debe existir una manera para comunicarse en forma segura de tal forma que aunque un agente externo sea capaz de obtener la información, no pueda leerla. La presente tesis no hace un estudio exhaustivo acerca de dichos parámetros. Queda abierta cualquier posibilidad de realizar un estudio profundo enfocado a la seguridad de este tipo de aplicaciones móviles. A continuación se proponen mecanismos iniciales que cumplen de forma muy básica con los aspectos mencionados anteriormente. La figura 4.9 muestra el mecanismo de identificación inicial propuesto basado en un protocolo reto-respuesta descrito en [25].. Figura 4.9: Mecanismo de identificación entre el cliente móvil y servidor proxy En este esquema, el usuario móvil envı́a un mensaje con su identificación al servidor Proxy (1). El servidor Proxy le envı́a un reto para asegurarse que el usuario es quien dice ser. Este reto puede ser un número aleatorio lo suficientemente grande para no ser adivinado fácilmente (2). El usuario móvil cifra el mensaje con la clave que comparte con el servidor Proxy y le envı́a el mensaje cifrado al mismo (3). Adicionalmente, el usuario móvil elige un reto con las mismas caracterı́sticas y lo envı́a al servidor Proxy (4). El servidor Proxy recibe este reto, lo encripta usando la llave que comparte con el dispositivo móvil y le envı́a el mensaje cifrado (5). Hasta este punto, ambas partes han validado que sean quien dicen ser. Una vez cubierto este proceso, el usuario móvil puede proseguir a enviar su identificador y password para obtener una clave de 24.

(36) sesión que identificará su sesión y será utilizada para llevar a cabo cualquier transacción mientras la sesión sea válida. Toda la información que fluye entre el usuario móvil y el servidor Proxy estará encriptada e incluirá la clave de sesión obtenida en el proceso de autentificación inicial (ver diagrama de estados figura 4.13).. 4.5.. MD-API. En un servicio dependiente de la localización, una tecnologı́a de posicionamiento resulta un componente fundamental para proveer la posición actual del dispositivo móvil. Actualmente existen diferentes tecnologı́as de posicionamiento que proveen una la localización del dispositivo móvil en forma absoluta (latitud, longitud) o relativa a un marco de referencia (coordenadas x, y de una habitación o referenciada a una calle o establecimiento). Algunas implementaciones de servicios móviles incluyen la tecnologı́a de posicionamiento [19,20] como un componente más dentro del sistema que proponen. Otras implementaciones [4], proponen un modelo hı́brido capaz de manejar simultáneamente varias tecnologı́as de posicionamiento con el propósito de proveer una localización más exacta o una mayor flexibilidad en el caso de que el dispositivo móvil se mueva de un ambiente interior a un ambiente exterior. Sin embargo, a fin de promover una estandarización, se propone que la tecnologı́a de posicionamiento sea independiente del mecanismo que provee el servicio móvil a la aplicación residente en el dispositivo móvil. La figura 4.10 muestra el framework que cumple con dichas caracterı́sticas.. Figura 4.10: Framework de un servicio móvil en un cliente El MD-API provee una interfaz de programación y comunicación a una aplicación móvil residente en algún dispositivo móvil (por ejemplo un PDA) permitiéndole entablar comunicación con el servicio móvil. Las siguientes son funciones del MD-API: • Proveer los mecanismos necesarios para autentificar a un cliente móvil. • Localización de servicios. • Identificador de parámetros que el servicio móvil puede proveer. • Edición y consulta de la información proveı́da por el servicio. • Ofrecer una manera sencilla para obtener la información proveı́da por un servicio. 25.

(37) 4.5.1.. Descripción de la interfaz MD-API. Existen 4 aspectos fundamentales que deben ser tomados en cuenta en la implementación del MD-API. El primero consiste en proporcionar todos los métodos necesarios para poder acceder a un servicio sin importar su implementación. Es decir, el MD-API encapsula las funcionalidades ofrecidas por un servicio. El segundo consiste en proveer los mecanismos necesarios para validar el estado de cualquier operación. El tercero consiste en ofrecer una forma amigable para obtener la información recibida después de una solicitud asumiendo que solo se recibirá texto. Este aspecto se vuelve un factor determinante para que un programador decida utilizar el MD-API para implementar su aplicación móvil. Finalmente, se debe proveer la documentación necesaria para familiarizar al programador con el API. El apéndice A describe con detalle el MD-API desarrollado en esta tesis y en el apéndice B se describen ejemplos del uso del API. Para comunicarse con el servidor Proxy, el MD-API intercambia de información se lleva a través de mensajes los cuales describen el tipo de acción que desea llevar a cabo. La tabla 4.5.1 muestra los campos contenidos en un mensaje enviado por el MD-API al servidor Proxy. Estos mensajes actúan a nivel aplicación para permitir la correcta interpretación de la información intercambiada entre el servidor Proxy y el MD-API. Cabe mencionar que el proceso de comunicación llevado a cabo en el MD-API es bloqueante, es decir, no se proseguirá con la ejecución hasta que no se reciba una respuesta. Por lo tanto, cada mensaje enviado posee un par, esto es cada mensaje enviado recibirá una respuesta.. 4.5.2.. Ubicación del dispositivo móvil. Como se mencionó con anterioridad, la ubicación del dispositivo móvil es un parámetro obtenido por la aplicación a través de la tecnologı́a de posicionamiento. Actualmente, para servicios exteriores, GPS resulta la alternativa más popular proveyendo la ubicación del dispositivo en coordenadas terrestres [16]. Por otro lado, en ambientes interiores, se ha uniformado el uso de coordenadas para la determinación de la ubicación del dispositivo móvil [1, 4, 9, 16, 27–29]. En este esquema, una coordenada corresponde a un área especı́fica en la cual el dispositivo móvil puede encontrarse. Dicha área depende en gran medida de la precisión del algoritmo de posicionamiento y en las señales obtenidas del dispositivo móvil. Sin embargo, una manera de obtener una medición más precisa de la ubicación del disposivo móvil consiste en definir una mayor cantidad de coordenadas dentro de una ubicación dada.. 26.

(38) Campo Authentication. Option. Sub Option. Location. Session ID. Descripción Este campo indica el proceso de autenticación del dispositivo móvil y del servidor Proxy. Si algún valor existe en este campo, este indica los diferentes pasos del proceso de identificación. Los valores posibles que posee son (1) solicitar autenticación, (2) envı́o de retos y (3) solicitud de autorización. Estos valores corresponden al proceso descrito en la figura 4.9 que se cubrirá más adelante. Este campo señala la operación que se desea llevar a cabo en el servicio. Las opciones ofrecidas en este campo son: (1) solicitar servicios disponibles, (2) solicitar parámetros de servicio y (3) solicitar servicios. Este campo especifica el tipo de operación que se desea llevar a cabo dentro de un servicio. Hasta ahora se encuentran 3 operaciones fundamentales llevadas a cabo dentro de un servicio: (1) obtener información, (2) modificar/actualizar información y (3) agregar información. Estas operaciones son consideradas generales, sin embargo, cada servicio puede definir sub operaciones particulares a su implementación. Aquı́ se encodifican la ubicación del dispositivo móvil dada por las coordenadas, ası́ como un código indicando la tecnologı́a de posicionamiento utilizada para localizar al dispositivo. Actualmente no existe ninguna regulación con respecto a las diferentes tecnologı́as de posicionamiento, sin embargo, el uso de un identificador es necesario si se desea que un dispositivo móvil sea localizado por más de una tecnologı́a de posicionamiento. Este campo posee el identificador que describe a la sesión que existe entre la aplicación móvil y el servidor Proxy. Este campo es ignorado si el mensaje asigna algún valor en el campo Authentication. Para todas las demás interacciones entre el servidor proxy y el MD-API requieren que este campo posea un valor.. 27.

(39) Campo Service ID. Condition. Data. Descripción Contiene el identificador que el servicio al cual se desea acceder. El valor de este campo será tomando en cuenta solo en operaciones de solicitar servicio y solicitar parámetros de servicio. Al igual que el identificador de tecnologı́a de posicionamiento, el identificador del servicio no posee ninguna estandarización. Este campo describe alguna restricción que debe ser tomada en cuenta al momento de solicitar un servicio. La definición de este campo es tomada en cuenta si la operación que se está llevando a cabo es la solicitud de un servicio. Es posible que algún servicio no posea ninguna restricción, por lo tanto, este campo puede mantenerse vacı́o sin ocasionar ningún problema. Este campo contiene la información que el servicio va a utilizar para generar una respuesta al usuario. Se considera opcional, sin embargo, en la mayorı́a de los casos, siempre se definirá algún parámetro o dato necesario para la correcta ejecución del servicio. Adicionalmente, a través de este campo, el servidor Proxy notifica el estatus de la operación que ejecutó. Si se encuentra algún error en el procesamiento del servicio, un código de error es colocado en este campo. Cuadro 4.1: Campos del mensaje. El uso de diferentes tecnologı́as de posicionamiento se reduce a mapear rangos de coordenadas proporcionadas por la tecnologı́a de posicionamiento a través de la aplicación móvil a un servicio. Esta tarea es llevada a cabo en el localizador, el cual puede tener asignados diferentes tipos de rangos de coordenadas para cada servicio. Suponga que el ejemplo de la figura 4.4 proveyera conectividad de red utilizando Bluetooth y WiFi. En este caso, las tablas mostradas en la figura 4.5 deberı́an incluir un rango de ubicaciones determinadas a través de Bluetooh y otro rango dado por el uso de WiFi para notificar la ubicación del dispositivo móvil. La figura 4.11 muestra como quedarı́an las tablas utilizando las dos tecnologı́as de posicionamiento. Este esquema ofrece la ventaja de proveer flexibilidad en cuanto al uso de la tecnologı́a de posicionamiento sin la necesidad de modificar la aplicación móvil. Otra ventaja ofrecida consiste en permitir al usuario varias alternativas para obtener su ubicación robusteciendo la disponibilidad del servicio móvil en caso de que una de las dos interfaces de comunicación no se encuentre disponible.. 28.

(40) Figura 4.11: Mapeo de servicios a locaciones fı́sicas utilizando Bluetooth y WiFi. 4.5.3.. Operación. La figura 4.12 muestra el diagrama de estados de un caso tı́pico de uso de las operaciones ofrecidas por el MD-API en una aplicación móvil. Una vez obtenida una respuesta, la aplicación puede procesar la información.. Figura 4.12: Diagrama de estados de comunicación de la aplicación móvil usando MDAPI. 29.

(41) 4.6.. Interacción entre componentes. A lo largo de la siguiente sección se muestra la interacción entre los componentes de la arquitectura. El proceso de comunicación de servicios se divide en 2 fases. La primera consiste en el establecimiento de una sesión y el consecuente descubrimiento de servicios. La segunda fase consiste en el acceso a un servicio especı́fico. El proceso se puede apreciar en la figura 4.13.. Figura 4.13: Diagrama de actividad de los componentes de la arquitectura En la fase de descubrimiento de servicios el dispositivo móvil envı́a una solicitud al servidor Proxy. Este se encarga de autentificar al usuario y de enviar una solicitud al localizador para descubrir los servicios existentes en la ubicación actual del dispositivo móvil. El localizador posee toda la información de los servicios existentes y los notifica al servidor Proxy al recibir la solicitud. El servidor Proxy filtra los servicios recibidos basándose en la identidad del usuario y guarda solo los servicios autorizados en la sesión que ha establecido con el dispositivo móvil. A continuación envı́a al dispositivo los servicios encontrados. 30.

(42) En la fase de acceso a un servicio especı́fico el cliente a través del dispositivo móvil selecciona el servicio que desea acceder. Dado que no se tiene ninguna información acerca de que información proporciona dicho servicio es necesario hacer una primera solicitud para obtener los parámetros de consulta del servicio. El servidor Proxy verifica en su caché de sesión y envı́a los parámetros al dispositivo móvil. Una vez que este tiene conocimiento de los parámetros, el usuario puede hacer la solicitud de información utilizando el servicio. Dicha solicitud es enviada al servidor Proxy y este la reenvı́a al localizador que será el encargado de ubicar el repositorio de servicios que posee dicha información y de hacerle el query de información. El localizador incluye en su mensaje de query la dirección del servidor Proxy a fin de que la respuesta sea redirigida a este. Una vez que el servidor Proxy recibe la respuesta la envı́a al dispositivo móvil. Hasta este punto una solicitud común ha sido cubierta. Ahora bien, en caso de que el usuario móvil desee modificar la información que ha recibido, debe enviar una solicitud de update en la información del servicio que incluye las modificaciones hechas al servicio. Dicha solicitud es redireccionada al localizador y este a su vez la envı́a al repositorio de servicios apropiado. Una vez que la modificación ha sido efectuada, se envı́a una confirmación directamente al servidor Proxy y finalmente se notifica al dispositivo móvil. Cada vez que el servidor Proxy y el dispositivo móvil establecen alguna comunicación se utilizan parámetros para validar la seguridad del proceso como se explicó en la sección de Seguridad del proceso de comunicación entre el servidor Proxy y el dispositivo móvil.. 31.

(43) Capı́tulo 5. Experimentación. En las secciones anteriores se describieron los requerimientos básicos que todo servicio dependiente de la localización debe implementar ası́ como la arquitectura que los sustenta y la interfaz de programación que puede ser utilizada para implementarlos en dispositivos móviles. En esta sección se describe la experimentación llevada a cabo para probar el modelo propuesto enfocando el uso de MLDS a una aplicación con un contexto diferente al comercio, en el cual estas aplicaciones se han desarrollado mayoritariamente.. 5.1.. Justificación. Actualmente el uso de Tecnologı́a de Información en los hospitales se ha incrementado de manera razonable con el único propósito de mejorar el servicio ofrecido a los pacientes. El término Most Wired está siendo utilizado para describir el uso de Tecnologı́a de Información en áreas como procesos de negocio, servicio al cliente, seguridad y calidad, fuerza de trabajo y salud pública dentro de las diferentes instituciones de salud y hospitales en los Estados Unidos. Por otro lado, la empresa taiwanesa Chunghwa Telecom lanzó en enero del 2006 un programa para equipar a los hospitales con sistemas inalámbricos con el fin de incrementar la efectividad de los procesos que se llevan a cabo dentro de los hospitales. Algunas décadas atrás se consideraba que el uso de frecuencias para comunicación dentro de los hospitales como un proceso riesgoso debido a que aparentemente afectaba al instrumental médico y ponı́a en riesgo la vida del paciente. En la actualidad, estudios han demostrado que es posible que diferentes frecuencias sean utilizadas dentro de los hospitales sin causar interferencia en los aparatos médicos. Tecnologı́as como WiFi, Zigbee y Bluetooth pueden ser utilizadas en hospitales para proveer conectividad inalámbrica. El uso de tecnologı́a de información en los hospitales puede proveer las siguientes. 32.