View
25
Download
4
Category
Preview:
DESCRIPTION
vargas
Citation preview
Centro de Investigacion y de Estudios Avanzadosdel Instituto Politecnico Nacional
Laboratorio de Tecnologıas de Informacion
Una plataforma de handoververtical para aplicaciones en
dispositivos moviles
Tesis que presenta:
Juan Antonio Vargas Enrıquez
Para obtener el grado de:
Maestro en Cienciasen Computacion
Director de la Tesis:Dr. Arturo Dıaz Perez
Cd. Victoria, Tamaulipas, Mexico. Febrero, 2009
c© Derechos reservados porJuan Antonio Vargas Enrıquez
2009
Esta investigacion fue parcialmente financiada mediante el proyecto No. 51623 del ”Fondo MixtoConacyt-Gobierno del Estado de Tamaulipas”
This research was partially funded by project number 51623 from ”Fondo Mixto Conacyt-Gobiernodel Estado de Tamaulipas”
La tesis presentada por Juan Antonio Vargas Enrıquez fue aprobada por:
Dr. Luis Gerardo de la Fraga
Dr. Victor Jesus Sosa Sosa
Dr. Arturo Dıaz Perez, Director
Cd. Victoria, Tamaulipas, Mexico., 26 de Febrero de 2009
A mama, a papa (+), gracias por haberme dado la oportunidad de educarme. A mi esposa Lilia porel apoyo incondicional que siempre me ha brindado a pesar de mi caracter difıcil y de mi errores,Lilia tu siempre has creıdo en mı, a mi hijo Juan Antonio, has sido un nino muy deseado, ahoratengo una razon mas para seguir adelante, a todos ustedes les dedico este trabajo con mucho
carino.
Agradecimientos
Al Dr. Arturo Dıaz por su acertada direccion durante todo el desarrollo de este trabajo de tesis,sus valiosos comentarios y su paciencia hicieron posible su culminacion.
A los doctores Victor Jesus Sosa Sosa y Luis Gerardo de la Fraga por el tiempo dedicado arevisar mi tesis,sus valiosos comentarios contribuyeron a mejorar la calidad de este trabajo.
Al Instituto Tecnologico de Cd. Victoria y en particular al Ing. Francisco Ruvalcaba Gonzalezpor el apoyo economico brindado para la realizacion de estos estudios y por todas la facilidadesotorgadas.
Al Ing. Enrique Flores por toda la ayuda brindada para la realizacion de mis estudios.
Al Lic. Joel Picazo por el apoyo brindado para la terminacion de este trabajo de tesis.
A Goyo por la motivacion que me dio para acelerar la terminacion de esta tesis.
A todos los investigadores del Laboratorio de Tecnologıas de Informacion del CINVESTAVTamaulipas por haber estado siempre dispuestos a compartir sus conocimientos conmigo.
Al CONACYT por el apoyo economico otorgado para la realizacion mis estudios de maestrıa
A mis companeros de cubıculo, Fede, Juan Carlos y Daniel (el mudo) quienes hicieron masllevaderas las largas jornadas de trabajo.
Indice General
Indice General I
Indice de Figuras V
Indice de Tablas VII
Indice de Algoritmos IX
Resumen XI
Abstract XIII
1. Introduccion 1
2. Conceptos generales 72.1. Telefonos inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. El dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Asistentes personales digitales (PDA) . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Interfaces de comunicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1. El sistema GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.2. Arquitectura del sistema GSM . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.3. General Packet Radio Service (GPRS) . . . . . . . . . . . . . . . . . . . . . 16
2.4.4. Arquitectura del sistema GPRS . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.5. Redes inalambricas 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.6. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5. El sistema operativo Symbian y la plataforma S60 . . . . . . . . . . . . . . . . . . 22
2.6. Handover vertical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.7. Seguridad computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7.1. Servicios de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.2. Herramientas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3. Arquitectura 313.1. Sistema de monitoreo de signos vitales . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2. Arquitectura del sistema de monitoreo de signos vitales . . . . . . . . . . . . . . . . 35
3.2.1. Arquitectura del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.2. Arquitectura del servidor de aplicacion . . . . . . . . . . . . . . . . . . . . 38
3.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
I
4. Comunicaciones 414.1. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1. Transferencia de archivos por Bluetooth . . . . . . . . . . . . . . . . . . . . 424.1.2. Comunicacion entre telefono celular y servidor de aplicacion por Internet . . 55
4.2. Handover vertical GPRS/WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.2.1. Mecanismo de handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.2.2. Cambio de red durante transferencia de archivos . . . . . . . . . . . . . . . 69
4.3. Servicios de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.3.1. Autenticacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.3.2. Confidencialidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.3.3. Integridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5. Resultados 895.1. Funcionalidad de la plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895.2. Desempeno de la plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2.1. Tiempo de handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.2.2. Tamano optimo de bloque de TCP usando red WLAN . . . . . . . . . . . . 975.2.3. Tamano optimo de bloque de TCP usando red GPRS . . . . . . . . . . . . 985.2.4. Tiempos de cifrado/descifrado . . . . . . . . . . . . . . . . . . . . . . . . . 1005.2.5. Tiempo de transferencia de archivos usando red WLAN . . . . . . . . . . . 1005.2.6. Tiempo de transferencia de archivos usando red GPRS . . . . . . . . . . . . 1035.2.7. Consumo de energıa durante cifrado y descifrado de datos . . . . . . . . . . 1065.2.8. Consumo de energıa durante transferencia usando red WLAN . . . . . . . . 1105.2.9. Consumo de energıa durante transferencia usando red GPRS . . . . . . . . . 111
5.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6. Conclusiones y trabajo futuro 1136.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
A. Modelo de sockets 117A.0.1. El modelo de sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117A.0.2. Funciones comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.0.3. Funciones del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119A.0.4. Funciones del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119A.0.5. Secuencia de conexion de sockets . . . . . . . . . . . . . . . . . . . . . . . 121
B. Funciones utilizadas 123B.1. Funciones para manejo de handover . . . . . . . . . . . . . . . . . . . . . . . . . . 123
B.1.1. La funcion SelectBestIAPL() . . . . . . . . . . . . . . . . . . . . . . . . . 123B.1.2. La funcion SelectBestWlanIAPL() . . . . . . . . . . . . . . . . . . . . . . . 125B.1.3. Funciones de interfaz Symbian C++/Python (wrapper) . . . . . . . . . . . 126
B.2. Funciones para servicios de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . 128
II
B.2.1. Funciones de cifrado y descifrado . . . . . . . . . . . . . . . . . . . . . . . 128B.2.2. Funciones de interfaz Open C/Python (wraper) . . . . . . . . . . . . . . . . 129
Bibliografıa 133
III
Indice de Figuras
2.1. Estructura celular de red GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2. Arquitectura del sistema GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3. Arquitectura del sistema GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4. Pila de protocolos Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5. Modelo de capas de seguridad computacional . . . . . . . . . . . . . . . . . . . . . 262.6. Criptografıa de llave simetrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1. Sistema de monitoreo de signos vitales . . . . . . . . . . . . . . . . . . . . . . . . 323.2. Arquitectura del sistema de monitoreo de signos vitales . . . . . . . . . . . . . . . . 353.3. Arquitectura del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4. Arquitectura del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1. Ubicacion de protocolo de transferencia por Bluetooth . . . . . . . . . . . . . . . . 434.2. Intercambio de mensajes de comando AlarmaAmarilla . . . . . . . . . . . . . . . . 444.3. Procesamiento del comando AlarmaAmarilla . . . . . . . . . . . . . . . . . . . . . 444.4. Intercambio de mensajes de comando AlarmaRoja . . . . . . . . . . . . . . . . . . 454.5. Procesamiento del comando AlarmaRoja . . . . . . . . . . . . . . . . . . . . . . . 464.6. Intercambio de mensajes de comando BorraMemoria . . . . . . . . . . . . . . . . . 464.7. Procesamiento del comando BorraMemoria . . . . . . . . . . . . . . . . . . . . . . 474.8. Intercambio de mensajes de comando GetInfoPaciente . . . . . . . . . . . . . . . . 484.9. Procesamiento del comando GetInfoPaciente . . . . . . . . . . . . . . . . . . . . . 484.10. Intercambio de mensajes de comando GetID . . . . . . . . . . . . . . . . . . . . . 494.11. Procesamiento del comando GetID . . . . . . . . . . . . . . . . . . . . . . . . . . 494.12. Intercambio de mensajes de comando GetTemperatura . . . . . . . . . . . . . . . . 504.13. Procesamiento del comando GetTemperatura . . . . . . . . . . . . . . . . . . . . . 504.14. Intercambio de mensajes del comando GetArchivos . . . . . . . . . . . . . . . . . . 514.15. Procesamiento del comando GetArchivos . . . . . . . . . . . . . . . . . . . . . . . 524.16. Procesamiento de envıa/recibe archivo . . . . . . . . . . . . . . . . . . . . . . . . 534.17. Intercambio de mensajes de comando StartDatosContinuos . . . . . . . . . . . . . 544.18. Procesamiento del comando StartDatosContinuos . . . . . . . . . . . . . . . . . . 544.19. Formato de mensajes de comandos simples . . . . . . . . . . . . . . . . . . . . . . 554.20. Formato de mensajes del comando GetInfoPaciente . . . . . . . . . . . . . . . . . . 564.21. Formato de mensajes del comando GetArchivos . . . . . . . . . . . . . . . . . . . . 574.22. Formato de mensajes de comandos GetID, GetTemperatura y StartDatosContinuos . 584.23. Ubicacion del protocolo de transferencia en modelo de capas tcp/ip . . . . . . . . . 594.24. Intercambio de mensajes de comando ENVIA ARCHIVO . . . . . . . . . . . . . . . 604.25. Procesamiento del comando ENVIA ARCHIVO . . . . . . . . . . . . . . . . . . . . 614.26. Intercambio de mensajes de comando RETRANSMITE ARCHIVO . . . . . . . . . . 614.27. Procesamiento del comando RETRANSMITE ARCHIVO . . . . . . . . . . . . . . . 62
V
4.28. Formato de mensajes de comandos del protocolo . . . . . . . . . . . . . . . . . . . 634.29. Formato de mensaje de bloque de datos . . . . . . . . . . . . . . . . . . . . . . . . 634.30. Cambio de red de GPRS a WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.31. Cambio de red de WLAN a GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.32. Cambio de red de WLAN a WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . 684.33. Diagrama de flujo de algoritmo de seleccion de punto de acceso a Internet . . . . . 694.34. Intercambio de mensajes durante handover . . . . . . . . . . . . . . . . . . . . . . 714.35. Proceso de handover durante transferencia de archivo . . . . . . . . . . . . . . . . 724.36. Ubicacion de los servicios de seguridad . . . . . . . . . . . . . . . . . . . . . . . . 734.37. Distribucion de llaves de sesion y autenticacion . . . . . . . . . . . . . . . . . . . . 744.38. Proceso de distribucion de llave de sesion . . . . . . . . . . . . . . . . . . . . . . . 754.39. Algoritmo de cifrado AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.40. Algoritmo de descifrado AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814.41. Cifrado de un bloque de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.42. Servicio de integridad en telefono celular . . . . . . . . . . . . . . . . . . . . . . . 834.43. Proceso de calculo de SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.44. Servicio de integridad en servidor de aplicacion . . . . . . . . . . . . . . . . . . . . 86
5.1. Escenario para pruebas de funcionalidad . . . . . . . . . . . . . . . . . . . . . . . . 925.2. Tiempo de handover WLAN/GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . 935.3. Tiempo de handover GPRS/WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . 945.4. Tiempo de handover WLAN/WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . 955.5. Tamano optimo de bloque de TCP usando red WLAN . . . . . . . . . . . . . . . . 975.6. Tamano optimo de bloque de TCP usando red GPRS . . . . . . . . . . . . . . . . 985.7. Grafica comparativa de tiempos de cifrado/descifrado . . . . . . . . . . . . . . . . 995.8. Tiempos de transferencia usando red WLAN . . . . . . . . . . . . . . . . . . . . . 1015.9. Tiempos de transferencia con y sin servicios de seguridad usando WLAN . . . . . . 1035.10. Tiempos de transferencia usando red GPRS . . . . . . . . . . . . . . . . . . . . . . 1045.11. Tiempos de transferencia con y sin servicios de seguridad usando GPRS . . . . . . . 1055.12. Megabytes cifrados con una baterıa con carga completa . . . . . . . . . . . . . . . 1085.13. Megabytes descifrados con una baterıa con carga completa . . . . . . . . . . . . . . 1095.14. Megabytes transferidos con una baterıa con carga completa . . . . . . . . . . . . . 110
A.1. Secuencia para modo de entrega de flujo fiable . . . . . . . . . . . . . . . . . . . . 121
VI
Indice de Tablas
2.1. Comparativo de telefonos inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Comandos del protocolo de transferencia por Bluetooth . . . . . . . . . . . . . . . 333.2. Ventajas y desventajas de reds WLAN y GPRS . . . . . . . . . . . . . . . . . . . . 34
4.1. Comandos del protocolo de transferencia de archivo por Internet . . . . . . . . . . . 574.2. Combinaciones Llave-Bloque-Ronda . . . . . . . . . . . . . . . . . . . . . . . . . . 784.3. Propiedades de los algoritmos de hash seguro . . . . . . . . . . . . . . . . . . . . . 83
5.1. Tiempos de transferencia usando red WLAN . . . . . . . . . . . . . . . . . . . . . 1005.2. Tiempos de transferencia usando red GPRS . . . . . . . . . . . . . . . . . . . . . . 1025.3. Tiempos de transferencia con servicios de seguridad usando red WLAN . . . . . . . 1025.4. Tiempos de transferencia con servicios de seguridad usando red GPRS . . . . . . . . 1065.5. Megabytes cifrados con una baterıa con carga completa . . . . . . . . . . . . . . . 1065.6. Megabytes descifrados con una baterıa con carga completa . . . . . . . . . . . . . . 1075.7. Megabytes transferidos con una baterıa con carga completa . . . . . . . . . . . . . 107
VII
Indice de Algoritmos
1. Pasos para establecer llave de sesion. . . . . . . . . . . . . . . . . . . . . . . . . . 75
IX
Resumen
Una plataforma de handover vertical para aplicaciones endispositivos moviles
por
Juan Antonio Vargas EnrıquezMaestro en Ciencias del Laboratorio de Tecnologıas de Informacion
Centro de Investigacion y de Estudios Avanzados del Instituto Politecnico Nacional, 2009Dr. Arturo Dıaz Perez, Director
Un inconveniente que presentan las aplicaciones que acceden a Internet por medio de una red
inalambrica desde un telefono celular, es que se requiere de un cambio manual en la configuracion
de la red de acceso. Este cambio manual en la configuracion puede ser molesto si consideramos que
la disponibilidad de una red inalambrica puede variar a medida que el usuario se desplaza.
En este trabajo de tesis se presenta un mecanismo denominado handover vertical, el cual soluciona
el problema de cambio de red en dispositivos moviles, en particular telefonos celulares que cuentan
con interfaz Wi-Fi. La plataforma de handover propuesta permite a las aplicaciones que se ejecutan
en un telefono celular y que acceden a Internet, cambiar de manera automatica entre redes GPRS y
WLAN. Ademas, con el objeto de evaluar el desempeno de la plataforma se presenta una aplicacion
que realiza transferencia de datos desde un telefono celular hacia una computadora de escritorio que
actua como servidor de aplicacion a traves de un canal seguro, el cual proporciona los servicios de
confidencialidad, integridad y autenticacion.
Las pruebas realizadas demuestran que el mecanismo de handover efectua los cambios de red
en los tres posibles escenarios: WLAN a GPRS, GPRS a WLAN y WLAN a WLAN. Las pruebas de
transferencia de datos confirman que los datos enviados por Internet a traves del canal seguro llegan
a su destino ıntegros, y que es posible regresarlos a su condicion original descifrandolos. Se confirma
tambien que la transferencia se efectua correctamente incluso si se presentan errores de transmision
o cambios de red.
XI
Abstract
A vertical handover platform for applications on mobiledevices
by
Juan Antonio Vargas EnrıquezMaster of Science in Information Technology Laboratory
Research Center for Advance Study from the National Polytechnic Institute, 2009Dr. Arturo Dıaz Perez, Advisor
A recent improvement to cell phones has been the incorporation of communication interface Wi-
Fi, this one is a fast and inexpensive alternative to access the Internet. One drawback that current
applications that access the Internet through a wireless network from a cell phone have, is that they
require a manual change in the configuration of the access network. This manual change in the
settings can be annoying when you consider that the availability of a wireless network can vary as
the user moves.
In this thesis, it is presented a mechanism called vertical handover, this mechanism solves the
problem of network changes on mobile devices, particulary cell phones that have Wi-Fi interface.
The proposed handover platform enables applications accessing the Internet on a cell phone to
automatically switch between WLAN and GPRS networks. Additionally, in order to assess the
performance of the handover platform, it is shown an application that allows the transfer of data
through a secure channel via Internet from a cell phone to a desktop computer that acts as an
application server. The secure channel provides confidentiality, integrity and authentication.
The tests conducted showed that the handover mechanism made network changes in the three
possible scenarios: GPRS to WLAN, GPRS to WLAN and WLAN to WLAN. Tests for transfer of
data confirmed that the data sent over the Internet via secure channel arrived at its destination
intact, and may return to its original condition decrypted. It is also confirmed that the transfer is
done even if there are transmission errors or network changes.
XIII
1Introduccion
En abril de 1973 el Dr. Martin Cooper, considerado el inventor del primer telefono portatil
moderno, realizo la primera llamada desde un telefono celular portatil. Fue hasta el ano de 1979 en
que el primer sistema de telefonıa celular comercial inicio operaciones en Tokio. En 1982, la Comision
Federal de Comunicaciones (FCC) de los Estados Unidos finalmente autorizo el servicio comercial
celular en ese paıs. Para 1987 el numero de suscriptores de telefonıa celular en los Estados Unidos
excedio el millon. Desde entonces, el numero de usuarios de telefonıa celular ha crecido de manera
exponencial. En el ano 2005, el numero de telefonos celulares en uso en el mundo habıa alcanzado
la cifra de 2,168,433,600 [4].
El telefono celular ha evolucionado rapidamente desde su invencion hasta convertirse en la
actualidad en un dispositivo multifuncion [28]. Actualmente el uso del telefono celular ya no se
limita solo a realizar llamadas de voz. De acuerdo a una encuesta realizada en los Estados Unidos
por AOL (America On Line) en marzo de 2006 sobre el uso del celular [2], el 8 % de los usuarios lo
usa para acceder a la Web y el 7 % lo usa para el envıo o consulta de correo electronico.
El uso del telefono celular para acceder a Internet tendera a aumentar en los proximos anos. La
1
2
integracion de la interfaz Wi-Fi sera determinante en este aspecto porque provee a los usuarios una
manera economica y rapida de acceder a Internet. Actualmente, el numero de telefonos celulares
que cuentan con esta interfaz es reducido, pero de acuerdo al informe “Wi-Fi Component Forecast
and Vendor Share” del 2005 [3], para el ano 2009 la mayorıa de los chips Wi-Fi seran destinados a
telefonos celulares.
En los proximos anos se espera que las redes inalambricas de area local o WLAN (Wireless local
area network) esten ampliamente distribuidas en sitios publicos como hoteles, oficinas, escuelas,
plazas, centros comerciales y aeropuertos [23]. Las aplicaciones que acceden a Internet desde
dispositivos moviles con interfaz Wi-Fi requeriran la integracion de las redes WLAN y el servicio
de radio de paquetes en general o GPRS (General Packet Radio Service). Por lo tanto, existe una
necesidad de desarrollar herramientas que integren de forma transparente e imperceptible diferentes
tecnologıas de comunicacion en un solo medio de acceso a Internet, de tal manera que cualquier
aplicacion pueda acceder automaticamente a la red de comunicacion mas apropiada. Ası, se pueden
aprovechar las ventajas de la amplia cobertura que ofrece la red GPRS y el bajo costo y la alta tasa
de transferencia que ofrece la red WLAN, y al mismo tiempo sobreponerse de las desventajas del
alto costo y baja tasa de transferencia que presenta la red GPRS. Esta integracion debera tomar en
cuenta dos aspectos muy importantes: el proceso para cambiar de una red de comunicacion a otra
de diferente arquitectura, proceso conocido como handover vertical, y los servicios de seguridad.
La seguridad es un reto que enfrenta todo sistema computacional. Con el advenimiento de las
redes de computadoras y particularmente con la popularizacion de la Internet los sistemas de computo
se volvieron mas vulnerables a ataques de seguridad. La Internet es una red publica que puede ser
accedida por cualquier persona y en donde practicamente cualquier sistema de computo, desde los
grandes sistemas corporativos hasta el sistema casero, pueden ser potencialmente vulnerables a un
ataque informatico desde cualquier lugar del mundo.
Actualmente existen una gran variedad de aplicaciones moviles que acceden a Internet, estas
aplicaciones intercambian informacion ya sea por medio de mensajes de correo electronico, para
efectuar operaciones bancarias, para consultar o actualizar bases de datos, etc. No debemos de
pasar por alto que cuando se trata de intercambiar informacion entre computadoras la seguridad es
1. Introduccion 3
importante. En este sentido, las redes inalambricas son un caso especial por ser mas vulnerables
a ataques ya que las senales viajan por el aire en donde pueden ser facilmente interceptadas.
Por esta razon, todo sistema computacional que involucre comunicaciones inalambricas debe de
considerar, dependiendo del tipo de aplicacion, la integracion de uno o mas servicios de seguridad
para garantizar que la informacion que esta transmitiendo no sea objeto de espionaje o modificacion
no autorizada. No deseamos que informacion tan importante como passwords, informacion de cuentas
bancarias o informacion personal sea vista o alterada por personas no autorizadas, y para garantizar
la transferencia segura de esta informacion se debe de establecer un canal de comunicacion seguro
entre ambos extremos de la comunicacion.
Con el fin de demostrar la funcionalidad de la arquitectura propuesta, se presenta como caso
de estudio o caso practico una aplicacion del area de la salud, un sistema de monitoreo de signos
vitales. Este sistema esta formado por tres componentes principales: un dispositivo sensor, un telefono
celular y un servidor de aplicacion. El dispositivo sensor captura signos vitales por medio de sensores
colocados en el cuerpo del paciente, esta informacion es enviada a un telefono celular por medio
de un enlace Bluetooth. El telefono celular a su vez envıa la informacion a traves de Internet a un
servidor de aplicacion ubicado en un centro medico. El telefono celular actua como gateway entre el
dispositivo Bluetooth y el servidor de aplicacion.
Objetivo general
El objetivo de este trabajo de tesis es proponer una solucion al problema del handover vertical
entre redes GPRS y WLAN para aplicaciones que accedan a Internet en dispositivos moviles y al
mismo tiempo proporcionar los servicios de seguridad necesarios para tales aplicaciones.
Objetivos particulares
Desarrollar una plataforma para el manejo del handover vertical entre una red GPRS y una red
WLAN.
Incorporar los servicios de seguridad de autenticacion, confidencialidad e integridad a la
aplicacion
Construir una aplicacion para servicios en el area de salud, la cual nos permitira verificar la
4
funcionalidad de la solucion propuesta y la necesidad de los servicios de seguridad.
Para desarrollar el trabajo de tesis que aquı se ha planteado y al mismo tiempo cumplir con los
objetivos propuestos, se ha seguido una metodologıa que consta de los siguientes pasos:
1. Revision del caso de estudio. El caso de estudio es una aplicacion para servicios en el area de la
salud, la cual permite monitorear los signos vitales de un paciente por medio de un dispositivo
sensor y un telefono celular. La informacion que procesa el sistema son las senales electricas
del corazon y la temperatura corporal, esta informacion es enviada por medio del telefono
celular a un servidor de aplicacion localizado en un centro medico. El objetivo de la revision es
determinar la arquitectura del sistema.
2. Analisis del proceso de handover. En este paso se determinan las variables involucradas en el
proceso de handover tales como disponibilidad de redes GPRS y Wi-Fi y potencia de la senal
de las redes WLAN. Con estas variables se determina a su vez la polıtica de decision a seguir.
3. Desarrollo del modulo de handover. El modulo de handover vertical efectua el cambio entre
redes GPRS y WLAN de acuerdo a la polıtica de decision establecida.
4. Diseno de protocolos. En este paso se disenan los protocolos de transferencia de archivo
necesarios para la aplicacion de monitoreo de signos vitales que se esta tomando como caso de
estudio. Se desarrolla un protocolo para efectuar la transferencia de archivos entre el dispositivo
sensor y el telefono celular por medio de la interfaz Bluetooth y un protocolo para efectuar la
transferencia entre el telefono celular y el servidor de aplicacion a traves de Internet.
5. Implementacion de los protocolos. El sistema de monitoreo de signos vitales obtiene informacion
de signos vitales del paciente y los envıa a un centro medico para su analisis. Estos datos deben
ser transferidos utilizando un protocolo que garantice su entrega a pesar de los posibles errores
de transmision que se pudieran presentar. En este paso se hace la implementacion de los
protocolos que se disenaron en el paso anterior.
1. Introduccion 5
6. Integracion del modulo de handover. La interfaz que se usa para acceder a Internet desde el
telefono celular se puede seleccionar manualmente cuando se ejecuta un programa que accede
a Internet. Una vez que se ha seleccionado esta interfaz esta no cambia durante la ejecucion del
programa. Es posible realizar la transferencia de informacion desde el celular hacia el servidor de
aplicacion de esta manera. Sin embargo si queremos utilizar una red que proporcione mejores
caracterısticas de ancho de banda, economıa o cobertura, necesitamos un mecanismo que
seleccione automaticamente la interfaz mas adecuada durante la ejecucion del programa. La
integracion del modulo de handover a la aplicacion que transfiere archivos desde el celular por
medio de Internet tiene este proposito. La transferencia de archivos se hara de acuerdo a los
protocolos disenados, pero sobre la red de comunicacion mas adecuada de acuerdo a la polıtica
de decision establecida en el modulo de handover.
7. Integracion de los servicios de seguridad. Los servicios de seguridad establecen un canal de
comunicacion seguro entre el telefono celular y el servidor de aplicacion. Los servicios de
seguridad integrados a la transferencia de archivos son la confidencialidad, la integridad y la
autenticacion. La confidencialidad se implementa por medio se criptografıa de llave simetrica,
la integridad se implementa por medio de una funcion hash, y la autenticacion se implementa
por medio de un esquema de distribucion de llaves de sesion.
8. Definicion de metricas. Para evaluar el desempeno de la aplicacion se definen algunas metricas
tales como el tiempo de cifrado, el consumo de energıa, el tiempo de cambio de red de
comunicacion, el tiempo de transferencia de archivos, etc.
9. Realizacion de pruebas y analisis de resultados. Se evalua la aplicacion de acuerdo a las metricas
establecidas y se analizan los resultados obtenidos.
El contenido de este trabajo de tesis se organiza de la siguiente manera: en el Capıtulo 2, se
abordan los conceptos generales de la telefonıa celular, de las diferentes interfaces de comunicacion y
de la seguridad informatica. En el Capıtulo 3 se presenta la arquitectura del sistema de monitoreo de
signos vitales y se describen cada unos de sus componentes. En el Capıtulo 4 se abordan los temas de
6
las comunicaciones por Bluetooth y por Internet, haciendo enfasis en los protocolos desarrollados para
la transferencia de informacion y en el mecanismo de handover vertical, ademas se trata tambien
el tema de los servicios de seguridad informatica que fueron implementados. En el Capıtulo 5 se
presentan el caso de estudio y los resultados obtenidos de acuerdo a las metricas establecidas.
Finalmente en el Capıtulo 6, se presentan las conclusiones del trabajo de tesis.
2Conceptos generales
El desarrollo de aplicaciones para dispositivos moviles, a diferencia del desarrollo de aplicaciones
para computadoras de escritorio, esta sujeto a varias consideraciones. Por un lado estan las
restricciones impuestas por el propio dispositivo movil, tales como la memoria disponible, el tamano de
la pantalla, la disponibilidad de las redes de comunicacion, la duracion de la baterıa, etc. Por otro lado
es necesario familiarizarse con las diferentes tecnologıas involucradas, tales como la telefonıa celular,
sistemas operativos propietarios, lenguajes de programacion y ambientes de desarrollo especializados.
En este capıtulo se presentan los conceptos basicos necesarios para comprender el desarrollo de
aplicaciones para dispositivos moviles.
2.1 Telefonos inteligentes
Aunque no existe una clara distincion entre un telefono celular y un telefono celular inteligente,
generalmente, un telefono inteligente es un telefono celular multifuncion de siguiente generacion que
proporciona capacidades de comunicacion de voz y mensajerıa de texto y facilita el procesamiento de
datos al mismo tiempo que tiene conectividad inalambrica mejorada. Se podrıa considerar al telefono
7
8 2.1. Telefonos inteligentes
celular inteligente como la fusion entre un poderoso telefono celular y una PDA (Personal Digital
Assistant) con interfaz inalambrica.
A diferencia de la mayorıa de los telefonos celulares, un telefono celular inteligente tiene las
siguientes caracterısticas:
Una pantalla a color de LCD con luz posterior.
Capacidad inalambrica mejorada tal como Wi-Fi, Bluetooth e infrarrojo, y la capacidad para
sincronizarse con computadoras.
Una memoria grande (RAM y ROM) y almacenamiento permanente (tarjetas de memoria o
discos duros internos)
Un sistema operativo avanzado con un conjunto de aplicaciones que usualmente incluye juegos
y calendarios, agenda, directorio, reproductor de medios, lector de libros, grabadora de voz y
funciones de libreta y calculadora. Muchos tiene una camara, algunos tiene incluso lentes Carl
Zeiss.
Ademas, los telefonos inteligentes generalmente caen dentro de tres categorıas en terminos de
diseno de auricular, representando tres campos en el sector de la industria.
Telefonos celulares de alto rango, por fabricantes de telefonos celulares, tales como Nokia,
Ericsson, y Motorola.
Telefonos PDA por HP y Palm, y
Dispositivos de correo electronico inalambricos mejorados (Blackberry) por Research in Motion
(RIM).
Los fabricantes de telefonos celulares acostumbran a desarrollar su propio sistema operativo
propietario, altamente personalizado para su lınea de productos. Dentro del mercado de telefonos
celulares, existen solo unos pocos sistemas operativos: Symbian OS, Microsoft Windows Mobile,
Palm OS y algunas variaciones de sistemas Linux empotrados.
2. Conceptos generales 9
Symbian OS es claramente el lıder del mercado, impulsando mas de 32 millones de telefonos
celulares y telefonos inteligentes fabricados por Nokia, Sony Ericsson, Motorola, Samsung, y otros.
Por otro lado Linux esta llamando la atencion en este mercado tambien.
Estos sistemas operativos estan altamente optimizados para telefonos celulares con recursos
restringidos y para telefonos inteligentes y se estan volviendo muy sofisticados en el soporte de
multihilo, administracion avanzada de energıa , y unos pocos tipos de capacidades inalambricas.
2.2 El dispositivo
Los componentes de hardware de un telefono celular normalmente incluyen un microprocesador,
una tarjeta principal, una antena, ROM, RAM, una baterıa, almacenamiento adicional tal como
memoria flash o una tarjeta SD, interfaces de red, y un pantalla de LCD. Algunos telefonos inteligentes
tienen un pequeno disco duro. En el cuadro 2.1 se presenta un comparativo de las principales
caracterısticas de algunos telefonos inteligentes populares, las cuales se describen a continuacion.
Nokia Nokia Treo BlackBerry Samsung iPhoneN93 N95 700p 8800 BlackJack
Categorıa Alto rango Alto rango PDA Correo Correo Alto rangomejorado mejorado
Tamano de Pantalla 2.4 ” 2.8 ” 2.6 ” 2.5 ” 2.2 ” 3.5 ”
Resolucion 320 x 240 240 x 320 320 x 320 320 x 240 320 x 240 320 x 480
Memoria integrada 50 Mb 100 Mb 128 Mb 64 Mb 64 Mb 8 Gb
Camara 3.2 5 1.3 - 1.3 2(Megapixeles)
Red EDGE EDGE EVDO EDGE WCDMA EDGEGPRS GPRS 2100 WiFiWiFi WiFi
Teclado Numerico Numerico QWERTY QWERTY QWERTY Virtual
Sistema Operativo Symbian Symbian Palm OS BlackBerry Windows M OS X
Duracion de baterıa 5.1 h 5 h 4.5 h 5 h 5.5 h 8 hHablar/Espera 240 h 280 h 300 h 528 h 264 h 250 h
Bluetooth Si Si Si No Si Si
Tabla 2.1: Comparativo de telefonos inteligentes
10 2.2. El dispositivo
Los procesadores para los telefonos inteligentes incluyen el ARM (advanced RISC machine),
el Dragon Ball de Motorola, el MIPS, y el OMAP de Texas Instruments. La arquitectura XScale
aprovecha la tecnologıa de administracion de voltaje, la cual permite que el voltaje de operacion
del procesador y la frecuencia escalen dinamicamente en respuesta a necesidades de computacion y
comunicacion variantes.
Los investigadores han estado trabajando para abordar la importante cuestion de la eficiencia de
energıa del telefono inteligente. Los telefonos inteligentes tıpicamente usan tres tipos de baterıas:
NiMH (hidruro metalico de nıquel), Li-ion (ion de litio), y Li-polymer (polımero de litio), todas las
cuales soportan unas pocas horas de tiempo de conversacion y una semana de tiempo de espera. Las
comunicaciones inalambricas, tales como Wi-Fi, generalmente consumen energıa mas rapidamente
que las simples tareas de computacion.
Los sistemas operativos y las aplicaciones son comparativamente mas pequenas que sus contra-
partes de escritorio. Ası, es posible y altamente deseable poner todo el codigo del sistema y
aplicaciones en RAM, ROM o memoria flash. Muchos telefonos inteligentes tienen de 64 a 128
Mbytes de SRAM para codigo de aplicaciones, de 128 a 256 Mbytes de memoria flash para codigo
del sistema, y mas de 128 Mbytes de memoria flash para datos de usuario.
Las pantallas de los telefonos inteligentes estan disenadas para facilitar varias aplicaciones,
incluyendo navegacion en la Web, correo electronico y reproduccion de audio y vıdeo. El tamano
de las pantallas varıa desde 2.2 pulgadas hasta 10 pulgadas. La resolucion de la pantalla continua
mejorando, algunos telefonos inteligentes tienen pantallas QVGA (320 x 240) o VGA (640 x 480)
con mas de 64,000 colores.
Muchos telefonos inteligentes adoptan el teclado tradicional de 12 botones, mas teclas de funcion
y navegacion. Este diseno permite la operacion con una mano. Algunos telefonos inteligentes usan un
diseno QWERTY, una version pequena del teclado de computadora estandar. Algunos otros telefonos
inteligentes, especialmente telefonos PDA, proporcionan un lapiz optico para escritura a mano.
2. Conceptos generales 11
2.3 Asistentes personales digitales (PDA)
Un PDA (Personal Digital Assistant) es una computadora que cabe en la palma de la mano. Su
principal proposito es llevar las aplicaciones de administracion de informacion personal y datos como:
agenda, calendario, notas y tareas. Las PDAs han estado en el mercado un buen numero de anos
y actualmente pueden hacer muchas mas funciones que solo administrar informacion personal. Las
PDAs pueden ser usadas para acceder a Internet para navegar en la Web o para acceder al correo
electronico, trabajan con documentos de MS Office, se les puede agregar un GPS para navegacion,
se puede jugar con ellas y algunas incluso funcionan como telefonos celulares y tiene camara digital
integrada.
Todas las PDAs tienen pantallas sensibles, las cuales responden tanto al lapiz optico como a
los dedos, actualmente las pantallas son a color. Todas tienen un lapiz optico, el cual se puede
usar para navegar en la pantalla e ingresar informacion por medio de reconocimiento de escritura.
Algunas han incorporado ahora pequenos teclados, los cuales se han hecho populares. A diferencia
de las computadoras personales, la mayorıa de los PDAs no disponen de disco duro porque los que se
suelen utilizar son demasiado grandes, demasiado lentos y consume mucha energıa. Pero la tecnologıa
ha avanzado a pasos agigantados. En estos dıas, los reproductores personales como el Ipod tiene
discos duros diminutos.
2.4 Interfaces de comunicacion
Los dispositivos moviles, tales como telefonos inteligentes o PDAs, pueden contar con varias
interfaces de comunicacion, estos dispositivos poseen por lo general una interfaz para servicio
telefonico celular tal como GSM, pero adicionalmente pueden contar con una o mas interfaces
tales como Infrarrojo, USB (Universal Serial Bus),Bluetooth o Wi-Fi. A continuacion se describen
las interfaces de comunicacion mas importantes presentes en dispositivos moviles.
12 2.4. Interfaces de comunicacion
2.4.1 El sistema GSM
El Sistema Global para Comunicaciones Moviles (GSM por sus siglas en ingles) es la tecnologıa
que soporta la mayorıa de las redes de telefonıa celular en el mundo. Actualmente la tecnologıa GSM
es usada por mas de dos mil millones de personas en mas de 200 paıses en el mundo, y contabiliza
el 81 % del mercado mundial de telefonıa celular [1].
En 1982, el principal cuerpo de gobierno de los operadores de telecomunicaciones europeos,
conocido como CEPT (Conference Europeenne des Postes et Telecommunicactions), creo el
comite Groupe Speciale Mobile, lo cual dio origen a las siglas GSM.
La tarea que se le asigno al comite fue definir un nuevo estandar para un sistema de radio
celular para toda Europa en la banda de los 900 Mhz [26]. Con el transcurso del tiempo, CEPT
evoluciono en una nueva organizacion, el Instituto Europeo de Estandares de Comunicacion (ETSI
por sus siglas en ingles). Esto, sin embargo, no cambio la tarea de GSM. La meta de GSM fue
sustituir las tecnologıas nacionales ya sobrecargadas y por lo tanto caras de los paıses miembros, con
un estandar internacional.
En 1991 los primeros sistemas GSM estuvieron listos para ser puestos en operacion. El significado
del acronimo cambio el mismo ano para significar Global System for Mobile Communications [9].
2.4.2 Arquitectura del sistema GSM
La red GSM utiliza una estructura celular como se muestra en la Figura 2.1. La idea basica de una
red celular es dividir la gama de frecuencias disponible, para asignar solo partes de ese espectro de
frecuencias a cualquier estacion transmisora, y reducir el alcance de una estacion base para reutilizar
las escasas frecuencias tanto como sea posible. Una de las principales metas de la planeacion de la
red es reducir la interferencia entre diferentes estaciones base.
Ademas de la ventaja de reutilizar frecuencias, una red celular tambien tiene las siguientes
desventajas:
Un numero en aumento de estaciones base incrementa el costo de la infraestructura y lıneas
2. Conceptos generales 13
BTS
BTS
BTSBSC
BSC
BTS
BSC
MSC
GMSC
EIR
AUC
HLR
VLR
PSTNISDNPDN
MS
MS
MS
BSS
Figura 2.1: Estructura celular de red GSM
de acceso.
Todas las redes requieren que, a medida que la estacion movil se mueve, una llamada activa
sea entregada de una celula a otra, proceso conocido como entrega (handover).
La red tiene que mantenerse informada de la ubicacion aproximada de la estacion movil, aun
sin una llamada en curso, para ser capaz de entregar una llamada entrante a esa estacion movil.
El segundo y tercer punto requieren amplia comunicacion entre la estacion movil y la red,
ası como entre los distintos elementos de la red.
Una red GSM esta compuesta por varios elementos: la estacion movil (MS), el modulo de
identificacion del suscriptor (SIM), el subsistema de estacion base (BSS), la estacion base transmisora
(BTS), la estacion base controladora (BSC), la unidad de transcodificacion y adaptacion (TRAU),
14 2.4. Interfaces de comunicacion
BTS
BSC
BTS
BTSBTS
BTS
BTS
BTS
BTS
Frecuencia 3
Frecuencia 3
Frecuencia 1
Frecuencia 4
Frecuencia 2
Frecuencia 4
Frecuencia 2
Frecuencia 1
Figura 2.2: Arquitectura del sistema GSM
el centro de conmutacion de servicios moviles (MSC), el registro de ubicacion de origen (HLR), el
registro de ubicacion de visitante (VLR), y el registro de identidad del equipo (EIR). Todos juntos
forman una red publica terrestre movil (PLMN por sus siglas en ingles).
La figura 2.2 muestra una vision general de los subsistemas GSM, los cuales se describen a
continuacion:.
Estacion movil: GSM-PLMN contiene tantos MS como sean posibles, estan disponibles en
varios estilos y clases de potencia.
Modulo de identidad del suscriptor (SIM): GSM distingue entre la identidad del subscriptor
y la del equipo movil. El SIM determina el numero de directorio y las llamadas facturadas a
un subscriptor. El SIM es una base de datos en el lado del usuario. Fısicamente, consiste de
un chip, el cual el usuario debe insertar en el telefono GSM antes de que pueda ser usado. El
SIM se comunica directamente con el VLR e indirectamente con el HLR.
2. Conceptos generales 15
Subsistema de estacion base (BSS):A traves de la Interfaz-aire el BSS ofrece una conexion
entre las MS de un area limitada y el subsistema de la red de conmutacion (NSS). El BSS
consiste de los siguientes elementos: uno o mas BTS, un BSC y un TRAU.
Estacion base transmisora-receptora (BTS): Un gran numero de BTSs se encargan de las
tareas relacionadas con el radio y proporcionan la conectividad entre la red y la estacion movil
(MS) por medio de la Interfaz-aire.
Estacion base controladora (BSC): Los BTS de un area estan conectados al BSC por medio
de una interfaz llamada la interfaz Abis. El BSC se encarga de las funciones centrales y del
control de los subsistemas (BSS). El BSS comprende el BSC mismo y los BTSs conectados.
Unidad de transcodificacion y adaptacion (TRAU): En un sistema GSM, la compresion
de datos es llevada a cabo tanto en el MS como en el TRAU. Desde la perspectiva de la
arquitectura, el TRAU es parte del BSS.
Centro de conmutacion de servicios moviles (MSC): Un gran numero de BSCs son
conectados al MSC por medio de la interfaz-A. El MSC es muy similar a un telefono digital
regular, intercambia y es accedido por redes externas exactamente de la misma manera. Las
principales tareas de un MSC son el encaminamiento de llamadas entrantes y salientes, y la
asignacion de canales de usuario en la interfaz-A.
Registro de ubicacion de origen(HLR): El HLR es un subcentro de una red GSM. Un HLR
es un repositorio que almacena los datos de un gran numero de suscriptores. Un HLR puede
ser considerado como una gran base de datos que administra los datos de literalmente cientos
de miles de suscriptores. Cada PLMN requiere de al menos un HLR.
Registro de ubicacion de visitante (VLR): El VLR fue ideado de tal manera que el HLR
no se sobrecargarıa con peticiones de datos acerca de sus subscriptores. Al igual que el HLR,
un VLR contiene datos del suscriptor, pero solo parte de los datos que estan en el HLR y solo
mientras el suscriptor particular vaga en el area por la cual el VLR es responsable.
16 2.4. Interfaces de comunicacion
Registro de identidad de equipo (SIM): Debido a que las identidades de los suscriptores
y de sus equipos moviles estan separadas, los equipos robados pueden ser reutilizados
simplemente usando cualquier SIM valido. Para prevenir esa clase de abuso cada equipo
terminal GSM contiene un identificador unico, el identificador internacional de equipo movil
(IMEI por sus siglas en ingles).
2.4.3 General Packet Radio Service (GPRS)
GSM fue originalmente disenado para soportar solamente conexiones de conmutacion de circuitos
al nivel de la interfaz de radio, con tasas de transferencia de datos de usuario de hasta 9.6 Kb/s
[26]. La utilizacion de un circuito conmutado significa que el usuario ocupa un canal completo de
trafico durante todo el tiempo que dura la llamada aun cuando este canal solamente sea utilizado
una pequena fraccion de tiempo. Cuando se trata de trafico en rafaga el resultado es una utilizacion
de los recursos de radio altamente ineficiente [6]. Estas ineficiencias pueden ser superadas utilizando
un servicio de conmutacion de paquetes. Esto es debido a que el canal solo sera asignado cuando sea
necesario, y sera liberado tan pronto como termine la transmision de los paquetes. De esta manera
varios usuarios pueden compartir un mismo canal fısico.
Para corregir estas ineficiencias han sido desarrolladas dos tecnologıas : paquete de datos celular
digital (CDPD por sus siglas en ingles) y el servicio de radio general de paquetes (GPRS por sus
siglas en ingles).
GPRS es un nuevo servicio portador para GSM que mejora significativamente y simplifica el
acceso inalambrico a redes de paquetes de datos. GPRS intenta optimizar los recursos de radio y de
red, y mantiene una estricta separacion entre los subsistemas de radio y el subsistema de red, aunque
el subsistema de red es compatible con otros subsistemas de acceso de radio GSM. Los recursos de
interfaz de radio pueden ser compartidos dinamicamente entre circuitos conmutados y el servicio de
paquetes, como una funcion de la carga de servicio y de las preferencias del operador. La tasa de
transferencia varıa desde 9 Kb/s hasta mas de 150 Kb/s por usuario.
La transmision de paquetes GPRS ofrece facturacion mas amigable para el usuario que la ofrecida
2. Conceptos generales 17
por los servicios de conmutacion de circuitos. En los servicios de conmutacion de circuitos, la
facturacion se basa en la duracion de la conexion y normalmente se factura por minuto o por
segundo. En contraste con esto, con los servicios de conmutacion de paquetes, la transferencia de
datos es tıpicamente facturada por kilo byte de datos transmitidos. La ventaja para el usuario es que
puede estar en lınea por un largo periodo de tiempo pero sera facturado por el volumen de datos
transmitidos.
2.4.4 Arquitectura del sistema GPRS
Con el fin de integrar GPRS en la arquitectura GSM existente se requieren dos nuevos
componentes adicionales de red, el nodo de apoyo de pasarela GPRS (GGSN por sus siglas en ingles),
y el nodo de apoyo de servicio GPRS (SGSN por sus siglas en ingles). El GGSN es responsable de
la entrega y encaminamiento de los paquetes de datos entre la estacion movil (MS) y las redes de
paquetes de datos externas (PDN por sus siglas en ingles) por medio del punto de referencia Gi.
El SGSN es responsable de la entrega de paquetes de datos desde y hacia las estaciones moviles
dentro de su area de servicio. Sus tareas incluyen el encaminamiento y transferencia de paquetes, el
manejo de la movilidad, el manejo de enlace logico y las funciones de autenticacion y facturacion [6].
El registro de ubicacion del SGSN almacena informacion y perfiles de usuario de todos los usuarios
GPRS registrados con este SGSN.
El nodo de apoyo de pasarela (GGSN) actua como una interfaz entre la red troncal y las redes
externas de paquetes de datos. Convierte los paquetes provenientes del SGSN al formato apropiado
del protocolo de paquetes de datos (PDP por sus siglas en ingles) y lo envıa a la correspondiente red
de paquetes de datos. En la direccion opuesta, las direcciones PDP de los paquetes de datos entrantes
son convertidas a la direccion GSM del usuario destino. En la Figura 2.3 se ilustra la arquitectura
del sistema
18 2.4. Interfaces de comunicacion
BSC
BTS
BSC
EIR HLR
MSQVLR
SMS-GMSCSMS-IWMSC
MS
BSS
BTS
PDN
OtraGPRS PLMN
GGSN
SGSN
Gb
Gd
Gf
Gs
Gr
Gn
Gi
Gp
Gc
D
GGSN
Figura 2.3: Arquitectura del sistema GPRS
2.4.5 Redes inalambricas 802.11
Sin duda, los protocolos IEEE 802.11 y sus esquemas de transmision son realmente uno de los
logros mas notables de normalizacion. Un incontable numero de dispositivos estan en la actualidad
basados en esta norma. Empezo como una extension inalambrica para redes de area local en 1997, y
desde entonces ha sido mejorado y ampliado gradualmente hacia una muy flexible y bien entendida
tecnologıa. Debido a que el 802.11 fue construido para sistemas de radio en el espectro sin licencia,
practicamente no hay ninguna limitacion en la utilizacion del 802.11. El espectro sin licencia es a
menudo armonizado en todo el mundo, lo que significa que dichos sistemas de radio se pueden usar
en cualquier lugar y momento. Debido a su inherente simplicidad, el 802.11 es el estandar dominante
para los sistemas comerciales de comunicacion inalambrica.
El IEEE publico el estandar original IEEE 802.11 en 1997 como una especificacion para un
esquema de transmision y un protocolo de control de acceso al medio para las redes de area local
inalambricas (WLAN). Una version revisada de precision mejorada se publico en 1999. Al mismo
tiempo, el 802.11a y 802.11b, que fueron los primeros subestandares para extender el 802,11,
se publicaron en forma paralela en 1999. Actualmente el 802.11 esta dividido en muchos mas
2. Conceptos generales 19
subestandares cada uno trata extensiones particulares.
Al igual que el IEEE 802.3 (Ethernet) y el 802.5 (Token Ring), el estandar 802.11 se centra
en las dos capas mas bajas (1 y 2) del modelo de referencia OSI (Open System Interconnection).
Este modelo de referencia divide la capa de control de enlace de datos (DLC) en las subcapas de
control de enlace logico (LLC) y control de acceso al medio (MAC). El 802.11 define los esquemas
de transmision de la capa fısica (capa 1 de OSI) y el protocolo MAC, pero no la funcionalidad del
LLC.
Para el LLC, el sistema 802.11 puede depender en protocolos generales que son usados en
otros estandares 802. Esta capa LLC es especificada independientemente para todas las redes 802
alambricas o inalambricas.
2.4.6 Bluetooth
Bluetooth es una tecnologıa de radio comunicacion de corto alcance estandarizada por el SIG
(Special Interest Group) Bluetooth, que habilita a los dispositivos a encontrar y conectarse con
otros dispositivos. Bluetooth esta disenado para satisfacer las necesidades de conexion inalambrica
de corto alcance de una variedad de dispositivos, tales como impresoras, ratones, telefonos celulares,
etc. Aunque la luz infrarroja tambien puede ser usada para comunicaciones inalambricas, esta presenta
dos serias limitantes. Primero, se requiere que los dispositivos esten muy cerca, menos de 1 metro de
distancia. Segunda, se requiere que los dispositivos se encuentren en una lınea de vista uno del otro.
Bluetooh no presenta estas limitantes. Debido a que se basa en ondas de radio, Bluetooth supera
estos obstaculos. Los dispositivos Bluetooth se pueden comunicar a distancias de hasta 10 m y no
es necesario que los dispositivos esten en lınea de vista, incluso es posible comunicarse a traves de
las paredes.
La capa fısica de radio de Bluetooth opera en la banda libre Industrial, Cientıfica y Medica (ISM
por sus siglas en ingles) a 2.4 Ghz. La ventaja de operar en esta banda es la disponibilidad mundial y
compatibilidad. Una potencial desventaja es el hecho que los dispositivos Bluetooth deben compartir
esta banda con muchos otros emisores de RF (radio frecuencia), tales como sistemas de seguridad
20 2.4. Interfaces de comunicacion
automotrices y otros estandares de comunicacion inalambricos como el 802.11. Para superar esta
desventaja, Bluetooth emplea un sistema de salto de frecuencia rapido y usa paquetes mas cortos
que otros estandares en la banda ISM. El salto de frecuencia es un cambio de una frecuencia a otra
dentro de la banda ISM. Despues de que un dispositivo Bluetooth envıa o recibe un paquete, cambia
a otra frecuencia antes de que el siguiente paquete sea enviado. Este esquema tiene 3 ventajas:
permite a los dispositivos Bluetooth usar completamente la banda ISM disponible, se asegura que
la interferencia sera de corta duracion y proporciona un nivel basico de seguridad porque es muy
difıcil para un dispositivo espıa predecir cual sera la proxima frecuencia que utilizaran los dispositivos
Bluetooth.
El nucleo de la especificacion Bluetooth es la pila de protocolos Bluetooth. Al proporcionar capas
de funcionalidad bien definidas, la especificacion Bluetooth asegura interoperabilidad de dispositivos
Bluetooth. Como se puede ver en la Figura 2.4, estas capas van desde el nivel bajo de enlace de
radio hasta las aplicaciones y perfiles.
En la base de la pila de protocolos Bluetooth esta la capa de radio. La capa de radio describe las
caracterısticas fısicas que el componente transmisor-receptor de un dispositivo Bluetooth debe tener.
Estas incluyen caracterısticas de modulacion, tolerancia de radio frecuencia y nivel de sensibilidad.
Arriba de la capa de radio esta la capa baseband y link controller (controlador de enlace). La
parte baseband de la capa es responsable de formatear apropiadamente los datos para transmision
desde y hacia la capa de radio. La parte link controller de esta capa es responsable de llevar a cabo
los comandos del gestor de enlace y establecer y mantener el enlace estipulado por el gestor de
enlace.
La capa link manager traduce los comandos que recibe de la interfaz controladora de anfitrion
(HCI por sus siglas en ingles) en operaciones de nivel baseband. Es responsable de establecer y
configurar los enlaces y de la gestion de cambios de potencia, entre otras tareas.
La capa HCI (Host Controller Interface) actua como una frontera entre las capas inferiores y
superiores de la pila de protocolos Bluetooth.
Arriba de la capa HCI estan las capas superiores de la pila de protocolos Bluetooth. La primera
es la capa L2CAP (logical link control and adaptation protocol). La capa L2CAP es principalmente
2. Conceptos generales 21
Aplicaciones y Perfiles
OBEX
SDP RFCOMM
L2CAP
HCI
Link manager
Baseband/Link controller
Radio
Figura 2.4: Pila de protocolos Bluetooth
responsable de establecer conexiones a traves de enlaces existentes o solicitar un enlace si no existe
uno previamente. Tambien es responsable del multiplexado entre los diferentes protocolos de la capa
superior, tales como RFCOMM y SDP, para permitir que muchas aplicaciones diferentes usen un
mismo enlace.
La capa SDP (Service Discovery Protocol) define las acciones para clientes y servidores de servicios
Bluetooth. Un cliente SDP se comunica con un servidor SDP usando un canal reservado sobre un
enlace L2CAP para encontrar que servicios estan disponibles. Cuando el cliente encuentra el servicio
deseado, solicita una conexion separada para usar el servicio. El canal reservado es dedicado a la
comunicacion SDP de tal manera que un dispositivo siempre conozca como conectarse al servicio
SDP en cualquier otro dispositivo. Un servidor SDP mantiene su propia base de datos SDP, la cual
22 2.5. El sistema operativo Symbian y la plataforma S60
es un conjunto de registros de servicio que describe los servicios que el servidor ofrece.
Tambien arriba de la capa L2CAP se encuentra la capa RFCOMM. El protocolo RFCOMM emula
las configuraciones y estatus de un cable serial de un puerto serial RS-232. RFCOMM se conecta a
las capas inferiores del protocolo Bluetooth a traves de la capa L2CAP.
Al proporcionar la emulacion del puerto serial, RFCOMM apoya un legado de aplicaciones de
puerto serial. Tambien soporta el protocolo OBEX y varios de los perfiles Bluetooth.
2.5 El sistema operativo Symbian y la plataforma S60
Symbian es un sistema operativo para telefonos inteligentes. Symbian se formo en 1998 por
Ericsson, Motorola, Nokia y Psion para proporcionar un estandar comun y habilitar el mercado en
masa de una nueva generacion de dispositivos inalambricos [10]. Matsushita se unio a Symbian en
1999, en enero de 2002 la empresa conjunta Sony Ericsson tomo participacion en Symbian y en abril
de 2002 Siemens tambien se unio a Symbian como accionista. Desde el inicio, la meta de Symbian
fue desarrollar un sistema operativo y una plataforma de software para telefonos moviles avanzados.
Para este proposito, el sistema operativo EPOC desarrollado por Psion formo una base solida. Fue
un sistema operativo modular multitarea de 32 bits disenado para dispositivos moviles. Symbian es
un sistema operativo multitarea con caracterısticas que incluyen un sistema de archivos, un marco
de interfaz grafica de usuario, soporte para multimedia, una pila de TCP/IP y bibliotecas para todas
las caracterısticas de comunicacion encontradas en los telefonos inteligentes[5].
El nucleo del S.O. Symbian consiste de la base (microkernel y controladores de dispositivos),
middleware (servidores de sistema, seguridad y marco de aplicaciones), y comunicaciones (telefonıa,
mensajerıa y redes de area personal). Este nucleo permanece comun a los diferentes dispositivos que
soportan al S.O. Symbian. Cuando el S.O. Symbian se monta al nuevo hardware la base necesita ser
cambiada, pero esto no afecta las capas superiores.
La arquitectura del sistema es modular y esta disenado con un buen enfoque orientado a objetos.
2. Conceptos generales 23
La mayorıa de las operaciones estan basadas en un modelo cliente-servidor que permite a todas las
aplicaciones usar los servicios proporcionados por el sistema, ası como otras aplicaciones. El S.O.
Symbian tambien contiene un marco de seguridad que proporciona administracion de certificados y
modulos de criptografıa.
El microkernel se ejecuta directamente en el procesador en modo privilegiado. Es responsable
del manejo de la energıa y del manejo de la memoria, posee los controladores de los dispositivos, y
tambien es la capa de interfaz entre el hardware y el software.
2.6 Handover vertical
Las redes inalambricas de area local (WLAN) son los sistemas de redes inalambricas mas
ampliamente usados en escuelas, oficinas, aeropuertos, etc. Este tipo de red tiene la ventaja de
que es muy economico y tiene altas tasas de transferencia, aunque su cobertura esta limitada a
unos cuantos metros. Por otro lado GPRS, el servicio de datos del sistema GSM, proporciona alta
movilidad y conectividad ”siempre en lınea” para los usuarios moviles. Sin embargo el servicio es
relativamente caro y la tasa de transferencia es baja [11].
Debido a su movilidad, es de esperarse que un dispositivo se mueva entre redes de comunicacion
de diferente arquitectura. Por lo tanto, los usuarios que tiene los dos sistemas en sus dispositivos
moviles estan en posibilidad de usar la red WLAN para acceder a Internet donde quiera que la red
este disponible, y cambiar a la red GPRS cuando se hayan alejado del area de cobertura de la red
inalambrica.
Un procedimiento que permite moverse entre redes GPRS y WLAN, y en general entre redes de
diferente arquitectura es conocido como handover vertical. Para poder lograr el handover vertical se
tiene que abordar varios asuntos tales como la toma de decision del handover, la autenticacion y el
manejo de la movilidad.
Un criterio de decision usado para efectuar el handover vertical son los parametros de la capa
fısica como la potencia de la senal recibida y la perdida de la senal. Otro criterio se basa en el ancho
24 2.7. Seguridad computacional
de banda relativo de las redes WLAN y GPRS. Tambien se ha usado un criterio de decision basado
no solo en los parametros de la capa fısica y en el ancho de banda de la red, sino en las condiciones
de la red tales como preferencia de usuario y retraso y perdida de paquetes [27].
La autenticacion para redes integradas WLAN/GPRS puede ser dividida en dos partes, basada en
SIM y basada en WLAN. En la autenticacion basada en SIM, los usuario itinerantes son autenticados
y facturados usando el modulo de identidad del subscriptor. En el enfoque de autenticacion basado en
WLAN, se requiere un servidor de autenticacion, autorizacion y contabilidad en ambas redes WLAN
y GPRS [11].
El esquema de manejo de movilidad que mantiene la continuidad de una conexion debe ser
considerado durante el handover vertical.
El Instituto Europeo de Estandares de Comunicacion (ETSI por sus siglas en ingles) define dos
enfoques para la integracion de redes WLAN y redes celulares: estrechamente acoplada y debilmente
acoplada. La principal diferencia entre acoplamiento estrecho y acoplamiento debil consiste en si el
trafico del usuario es entregado o no a traves de la red central celular [24]. Esto significa que, cuando
la red celular y la red WLAN estan estrechamente acopladas, el trafico proveniente de la red WLAN
fluye en el nucleo de la red celular y hacia afuera a la red de paquetes de datos externa (PDN por
sus siglas en ingles). En contraste, en el caso del acoplamiento debil, la red WLAN no comparte
ninguno de los nucleos de la red celular excepto para las funciones de autenticacion, autorizacion y
contabilidad
2.7 Seguridad computacional
La seguridad computacional se define como el conjunto de medidas o sistemas de control para
preservar los datos, protegerlos contra robo o ataques de la red y garantizar su integridad [14]. Para
garantizar la seguridad de un canal de comunicacion debemos conocer cuales son la amenazas y los
ataques a los que puede ser sometido.
Segun el Glosario de Seguridad de Internet (RFC 2828) [8], amenaza es:
Un potencial de violacion de seguridad, que existe cuando hay una circunstancia, la capacidad, accion
2. Conceptos generales 25
o evento que podrıa violar la seguridad y causar danos. Es decir, una amenaza puede ser un peligro
que podrıa explotar una vulnerabilidad.
Por otra parte un ataque es:
Un asalto a la seguridad del sistema que se deriva de una amenaza inteligente, es decir, un acto
inteligente que es un intento deliberado para evadir los servicios de seguridad y violar la polıtica de
seguridad de un sistema.
Los ataques de seguridad se clasifican en ataques pasivos y ataques activos [8]. Los ataques pasivos
son aquellos que se refieren al espionaje o vigilancia de las transmisiones, el objetivo del oponente es
obtener la informacion que se transmite. Dos tipos de ataques pasivos son, la revelacion del contenido
del mensaje y el analisis de trafico [25]. Los ataques activos involucran alguna modificacion del flujo
de datos o la creacion de un flujo falso y pueden ser subdivididos en cuatro categorıas: mascarada,
reproduccion, modificacion de mensajes y denegacion de servicio.
Una mascarada ocurre cuando una entidad pretende ser una entidad diferente. La reproduccion
involucra la captura pasiva de una unidad de datos y su subsecuente retransmision para producir un
efecto no autorizado. La modificacion de mensajes simplemente significa que una parte del mensaje
legıtimo es alterada, o que los mensajes se retrasan o son reordenados, para producir un efecto no
autorizado. La denegacion de servicio impide o inhibe el uso normal o la gestion de los servicios de
comunicaciones.
La seguridad computacional se basa en un modelo de capas (Figura 2.5), en este modelo las
aplicaciones estan en la capa superior, las aplicaciones proporcionan al usuario final servicios tales
como correo electronico, consulta y actualizacion de bases de datos, servicios financieros o algun otro
tipo de servicio. Debajo de esta capa esta la capa de servicios de seguridad, esta capa proporciona a las
aplicaciones los servicios de confidencialidad, integridad, autenticacion y no repudio. Las aplicaciones,
dependiendo de sus caracterısticas y necesidades pueden requerir uno o mas de estos servicios de
seguridad. En la parte inferior del modelo se encuentra la capa de herramientas de seguridad, esta
capa proporciona los algoritmos necesario para la implementacion de los servicios de seguridad que
se encuentran en la capa superior. Los servicios de seguridad ası como las herramientas de seguridad
se explican a continuacion.
26 2.7. Seguridad computacional
Confidencialidad Integridad Autenticación
Aplicaciones para dispositivos móviles
Herramientas de seguridad
Correo electrónicoServicios bancariosTransferencia de archivos
Aplicaciones médicasServicios finacierosActualización de BD
Algoritmos Criptográficos
FuncionesHash
FirmasDigitales
Llave simétrica
Llave pública
DES, 3DES,AES
RSA,ECC
MD5SHA-1
SHA-256SHA-512
DSAPKCS
ECDSA
No repudio
Figura 2.5: Modelo de capas de seguridad computacional
2.7.1 Servicios de seguridad
Se puede formar una buena idea de lo que es la seguridad de computadoras y redes examinando
los principios en los que esta se basa. La seguridad de las computadoras y redes esta basada en tres
pilares, que comunmente se conocen por las siglas en ingles CIA:
Confidencialidad
Integridad
Disponibilidad
Ademas del CIA hay otros terminos y siglas. Cada uno de estos tiene su propio significado, pero
todos son parte del modelo CIA.
Identificacion
Autenticacion
Autorizacion
2. Conceptos generales 27
Rendicion de cuentas
No repudio
Dentro de estos terminos, la confidencialidad, la integridad, la autenticacion y el no repudio
constituyen lo que se conoce como servicios de seguridad [20], los cuales se definen a continuacion:
Confidencialidad: Garantiza que la informacion sensitiva puede solamente ser accedida por
usuarios o entidades autorizados para revelarla.
Integridad: Es un servicio que se ocupa de la modificacion no autorizada de datos.
Autenticacion: Es un servicio relacionado con la identificacion. Esta funcion se aplica tanto
a entidades como a la informacion misma.
No repudio: Es un servicio que previene a una entidad negar compromisos o acciones previas.
2.7.2 Herramientas de seguridad
Criptografıa de llave simetrica
La criptografıa de llave simetrica es una forma de criptosistema en el que el cifrado y descifrado
se realizan usando la misma llave. La criptografıa de llave simetrica transforma texto claro en texto
cifrado mediante una llave secreta y un algoritmo de cifrado. Utilizando la misma llave y un algoritmo
de descifrado, el texto claro es recuperado del texto cifrado (Figura 2.6). Un algoritmo de cifrado
puede ser sometido a dos tipos de ataque: 1) el criptoanalisis, basado en las propiedades del algoritmo
de cifrado, y 2) la fuerza bruta, el cual involucra intentar todas las llaves posibles.
Un cifrador de flujo es aquel que cifra un flujo de datos digitales un byte a la vez. Ejemplos de
cifradores de flujo clasicos son el cifrador Vigenere y el cifrador Vernam. Un cifrador de bloque es
aquel en el cual un bloque de texto claro es tratado como un todo y es usado para producir un bloque
de texto cifrado de igual longitud.Tıpicamente se usa un tamano de bloque de 64 o 128 bits. Usando
alguno de los modos de operacion, un cifrador de bloque puede ser usado para lograr el mismo efecto
que un cifrador de flujo [25].
28 2.7. Seguridad computacional
Llave secreta compartida porremitente y dest inatario
Llave secreta compartida porremitente y dest inatario
Algoritmo de cifrado Algoritmo de descifrado
Texto cifradoHola mundoCd, VictoriaCinvestav
tesis
Hola mundoCd, VictoriaCinvestav
tesis
EntradaTexto claro
SalidaTexto claro
Figura 2.6: Criptografıa de llave simetrica
El algoritmo de cifrado AES
Las siglas AES significan Advanced Encryption Standard o Estandar de Cifrado Avanzado. AES
es un algoritmo de cifrado de llave simetrica que sustituira al Estandar de Cifrado de Datos (DES por
sus siglas en ingles). Fue el resultado de una convocatoria mundial para la presentacion de algoritmos
de cifrado emitida por el Instituto Nacional de Estandares de Tecnologıa (NIST por sus siglas en
ingles) del gobierno de los Estados Unidos en 1997 y completado en 2000. El algoritmo ganador,
Rijndael, fue desarrollado por dos criptologos belgas, Vincent Rijmen y Joan Daemen.
El algoritmo AES solo soporta tamanos de bloque de 128 bits y tamanos de llave de 128, 192 y
256 bits. Cada tamano de llave de cifrado hace que el algoritmo se comporte ligeramente diferente,
por lo que el aumento de tamano de llave no solo ofrece un mayor numero de bits con los que se
pueden cifrar los datos, sino que tambien aumenta la complejidad del algoritmo de cifrado.
La funcion hash SHA-1
El Algoritmo de Hash Seguro (SHA por sus siglas en ingles) fue desarrollado por el
Instituto Nacional de Estandares de Tecnologıa (NIST) y publicado como un Estandar Federal de
Procesamiento de Informacion (FIPS 180) en 1993; una version revisada se publico como FIPS 180-1
en 1995 y es referida generalmente como SHA-1. SHA se basa en principios similares a los utilizados
por Ronald L. Rivest del MIT en el diseno de los algoritmos de resumen de mensaje MD4 y MD5
[25]. SHA es un conjunto de funciones hash criptograficas, los cinco algoritmos que lo componen
2. Conceptos generales 29
son SHA-1, SHA-224, SHA-256, SHA-384, y SHA-512 [19].
SHA-1 es una funcion que puede procesar un mensaje de una longitud maxima de 264−1 bits para
producir una representacion condensada llamada resumen del mensaje. La funcion SHA-1 genera un
resumen o digesto de 20 bytes o 160 bits de longitud. Este algoritmo permite determinar la integridad
de un mensaje: cualquier cambio en el mensaje resultara con una probabilidad muy alta en un resumen
de mensaje diferente[19].
En el Capıtulo 4 se da una explicacion mas detallada tanto del algoritmo de cifrado AES, como
del algoritmo de hash seguro SHA-1.
2.8 Resumen
En este capıtulo se presentaron los conceptos basicos necesarios para comprender el desarrollo de
aplicaciones moviles especialmente para telefonos celulares inteligentes y se describieron los servicios y
herramientas de seguridad computacional necesarios para establecer canales de comunicacion seguros.
En el siguiente capıtulo se presentara la arquitectura de la aplicacion desarrollada.
3Arquitectura
Con el fin de demostrar la funcionalidad de la plataforma de handover vertical propuesta en
el Capıtulo 1, en este capıtulo se presenta como caso practico una aplicacion del area de la
salud. Esta aplicacion es un sistema que permite monitorear remotamente desde un centro medico los
signos vitales de un paciente. Este sistema utiliza Internet para enviar la informacion hacia el centro
medico y lo hace por medio de un canal de comunicacion seguro que garantiza la autenticidad, la
confidencialidad y la integridad de los datos. En este capıtulo se presenta tambien la arquitectura de
este sistema y se describe la funcionalidad de los componentes principales del mismo.
3.1 Sistema de monitoreo de signos vitales
El dispositivo monitor es parte de un sistema que proporciona un servicio completo de cuidado de
la salud. El sistema esta compuesto por varios servicios ligados a la red de telefonıa celular, a redes
inalambricas e Internet. El sistema de monitoreo de signos vitales esta formado por tres componentes
principales como se muestra en la Figura 3.1: un dispositivo monitor con interfaz Bluetooth que
registra signos vitales por medio de sensores, un telefono celular con interfaces Bluetooth y Wi-
31
32 3.1. Sistema de monitoreo de signos vitales
InternetDispositivomoni tor
Bluetooth
802.11
GPRS
Access Point
Red GSM
Servidor de Aplicación
Teléfono celular
Figura 3.1: Sistema de monitoreo de signos vitales
Fi y un servidor de aplicacion. El dispositivo monitor captura signos vitales por medio de sensores
colocados en el cuerpo del paciente, esta informacion es enviada a un telefono celular por medio de
un enlace Bluetooth. El telefono celular envıa la informacion a traves de Internet a un servidor de
aplicacion ubicado en un centro medico utilizando la red GPRS o una red inalambrica. El telefono
celular actua como una pasarela entre el dispositivo sensor y el servidor de aplicacion.
El dispositivo monitor es un dispositivo electronico ambulatorio, dedicado a monitorear
continuamente la actividad cardiaca de un paciente y alertarlo a el y al centro de atencion medica
cuando sea detectada una anormalidad. El dispositivo por sı mismo es capaz de producir todos los
datos requeridos por un medico para dar un diagnostico. Tambien puede advertir y guiar al paciente
acerca de las acciones a tomar en caso de que surjan problemas cardiacos. El dispositivo monitor
adquiere y procesa los siguientes signos vitales:
1. Senales electricas cardiacas
2. Temperatura corporal
3. Actividad fısica
3. Arquitectura 33
Al monitorear estas senales, el dispositivo analiza la informacion contenida en ellas y alerta al
paciente acerca de las siguientes situaciones:
Alarma amarilla: un problema de salud no crıtico ha sido detectado, un doctor deberıa ser visto
pronto
Alarma roja: un problema de salud crıtico ha sido detectado, se requiere asistencia medica
inmediata
El dispositivo monitor es un dispositivo personal de vigilancia medica dedicado a la supervision de
pacientes con enfermedades del corazon declaradas; isquemia, fibrilacion, arritmia, etc. El dispositivo
monitor permite:
Alertar al paciente en cualquier caso de que se detecte un mal funcionamiento del corazon
Reducir el numero de muertes debido a atencion medica tardıa
Mejorar la calidad de vida de los pacientes
Comandos iniciados por dispositivo monitor Comandos iniciados por telefono celularComando Respuesta esperada Comando Respuesta esperadaAlarmaAmarilla AckAlarmaAmarilla BorraMemoria GetConfirmarBorrarAlarmaRoja AckAlarmaRoja AckBorraMemoria
GetArchivos SendingArchivo, SinArchivosGetID SendingIDGetInfoPaciente SendingInfoPacienteGetTemperatura SendingTempStartDatosContinuos SendingDatosStopDatosContinuos
Tabla 3.1: Comandos del protocolo de transferencia por Bluetooth
La transferencia de datos por medio de la interfaz Bluetooth se hace por medio de un protocolo
de transferencia de archivos desarrollado especialmente para esta aplicacion. Los comandos de este
protocolo de comunicacion se muestran en la Tabla 3.1.
34 3.1. Sistema de monitoreo de signos vitales
Ventajas DesventajasRed WLAN Ancho de banda de hasta 54 Mbps Cobertura limitada
Mas economicaRed GPRS Cobertura muy amplia Ancho de banda maximo de 150 Kbps
Mayor costo, se factura por Kb
Tabla 3.2: Ventajas y desventajas de reds WLAN y GPRS
Los comandos iniciados por el dispositivo monitor son las alarmas que se activan cuando el
paciente necesita asistencia medica. Estas alarmas son enviadas al telefono celular donde la aplicacion
alerta al paciente y reenvıa las alarmas al centro de atencion medica. Las comandos de alarma esperan
un comando de respuesta como confirmacion de que fueron recibidas por el telefono celular, si este
comando de respuesta no es recibido, la alarma se envıa de nuevo hasta que se reciba la confirmacion.
En estos comandos el dispositivo monitor actua como cliente y el telefono celular actua como servidor.
Los comandos iniciados por el telefono celular son emitidos para solicitar al dispositivo monitor
la informacion almacenada en su memoria interna. Esta informacion puede ser: datos personales del
paciente, identificacion del dispositivo, archivos de datos de senales cardiacas o temperatura corporal.
Tambien puede ser un comando para borrar la memoria del dispositivo monitor. Cada uno de estos
comandos puede requerir de una o mas respuestas emitidas por el dispositivo monitor. En estos
comandos el telefono celular actua como cliente y el dispositivo monitor actua como servidor.
La informacion recibida en el telefono celular es enviada a su vez a un servidor de aplicacion
localizado en un centro de atencion medica. Los datos capturados por el dispositivo monitor son
almacenados como archivos, el envıo de estos archivos entre el telefono celular y el servidor de
aplicacion a traves de Internet se hace por medio de la red GPRS o por medio de una red WLAN.
Para efectuar este envıo se desarrollo un nuevo protocolo de transferencia de archivos.
El servidor recibe la informacion proveniente desde el dispositivo monitor. La aplicacion en el
servidor realiza las siguientes funciones: almacena la informacion, proporciona herramientas para
la presentacion y analisis de datos para que personal medico realice diagnosticos, y se encarga de
procesar las alarmas.
Los telefonos celulares acceden a Internet usando la red GPRS, pero cada vez hay un mayor
3. Arquitectura 35
Teléfono celular
Aplicación monitorde signos vitales
ComunicacionesBluetooth
ComunicacionesInternet
Aplicación monitorde signos vitales
ComunicacionesInternet
Servidor en centromédico
Internet
DispositivoMonitor
EnlaceBluetooth
Protocolode
transferenciapor Bluetooth
Protocolode
transferenciapor Internet
Figura 3.2: Arquitectura del sistema de monitoreo de signos vitales
numero de telefonos celulares que cuentan con la interfaz Wi-Fi lo que permite el acceso a Internet
por medio de una red inalambrica. Tener la interfaz Wi-Fi nos da la opcion de acceder a Internet
por la red que sea mas conveniente, ya que cada una de ellas tiene ventajas y desventajas como se
muestra en la Tabla 3.2. Podemos ver que al tener la opcion de utilizar cualquiera de las 2 redes se
pueden aprovechar las ventajas de la amplia cobertura que ofrece la red GPRS y el bajo costo y la
alta tasa de transferencia que ofrece la red WLAN.
La informacion transferida por el sistema de monitoreo se envıa a traves de redes inalambricas
e Internet por lo que puede ser potencialmente sujeta a espionaje. Es necesario considerar algun
mecanismo que proteja esta informacion personal y sensible, esto se logra agregando un componente
de seguridad que garantice la autenticidad, confidencialidad e integridad de la informacion.
3.2 Arquitectura del sistema de monitoreo de signos vitales
La arquitectura que se propone para el sistema de monitoreo de signos vitales se muestra en la
Figura 3.2. En esta arquitectura el telefono celular desempena el papel mas importante de todo el
sistema porque actua como una pasarela entre el dispositivo monitor de signos vitales y el servidor
de aplicacion. La arquitectura sigue el modelo cliente servidor, en donde el cliente es la aplicacion
que se ejecuta en el telefono celular y donde se tiene dos servidores, el dispositivo monitor que actua
como servidor para las comunicaciones Bluetooth y el servidor de aplicacion que actua como servidor
36 3.2. Arquitectura del sistema de monitoreo de signos vitales
Presentaciónde datos
Transferenciade archivo por
Internet
Integridady
confidencialidadArchivo de datos
Archivo dedatos cifrado
Archivo de datos
Internet
Aplicación en teléfono celular
Módulo de handover
IAP seleccionado
Autenticación
Llave de sesión
Solicitud de llavede sesión
Transferenciade archivoBluetooth
Figura 3.3: Arquitectura del cliente
para las comunicaciones por Internet. El telefono celular recibe por medio de un enlace Bluetooth la
informacion proveniente del dispositivo monitor, la procesa y la reenvıa a traves de Internet hacia el
servidor de aplicacion. Para efectuar esta transferencia de datos de manera confiable se utilizan dos
protocolos de comunicacion, uno para la transferencia por Bluetooth y el otro para la transferencia
por Internet.
3.2.1 Arquitectura del cliente
Las funciones que realiza el cliente son: la recepcion de los datos provenientes del dispositivo
monitor, la presentacion de los datos, la seleccion automatica del medio de acceso a Internet, el
establecimiento de un canal de comunicacion seguro con el servidor de aplicacion, y la trasferencia
de datos hacia el servidor de aplicacion. La arquitectura del cliente se muestra en la Figura 3.3 se
compone de seis modulos los cuales se describen a continuacion:
Modulo de transferencia de archivo por Bluetooth: La funcion de este modulo es transferir
los datos almacenados en la memoria interna del dispositivo monitor hacia el telefono celular. La
transferencia de datos por medio de la interfaz Bluetooth se hace con un protocolo de transferencia
3. Arquitectura 37
de archivos desarrollado para este proposito. Este protocolo es necesario porque el dispositivo monitor
de signos vitales tiene capacidades de computo limitadas y solo cuenta con una implementacion del
protocolo de transporte RFCOMM, tambien es necesario para permitir la recuperacion de errores de
transmision frecuentes en las comunicaciones por Bluetooth.
Modulo de presentacion de datos: La funcion de este modulo es presentar en el telefono
celular los datos recibidos del dispositivo monitor. La presentacion de los datos se hace por medio de
una interfaz grafica, esta interfaz realiza dos funciones: informa al usuario sobre las alarmas emitidas
por el dispositivo monitor y presenta las senales electricas cardiacas de manera que el usuario las
pueda interpretar de manera sencilla.
Modulo de handover: El envıo de archivos entre el telefono celular y el servidor de aplicacion
a traves de Internet se hace por medio del punto de acceso GPRS o por medio del punto de acceso
WLAN. La funcion de este modulo es seleccionar el mejor punto de acceso a Internet (IAP por sus
siglas en ingles) desde el punto de vista de economıa y ancho de banda. En este modulo se toma
la decision sobre cual punto de acceso a Internet va a ser seleccionado para abrir una conexion. El
criterio de seleccion es el siguiente: si no hay disponible alguna red inalambrica en la que el cliente
este registrado, entonces se selecciona GPRS como punto de acceso a Internet, de lo contrario se
selecciona la red WLAN, si hay mas de una red WLAN se selecciona la que tenga la senal mas
potente.
Modulo de transferencia de archivo por Internet: La funcion de este modulo es transferir el
archivo de datos desde el telefono celular hacia el servidor de aplicacion. El modulo de transferencia
de archivo se encarga de abrir la sesion de transferencia y efectuar el envıo de datos. Para efectuar
este envıo se utiliza un protocolo de transferencia de archivos. Este protocolo es similar al utilizado en
la transferencia de archivos entre el dispositivo monitor y el telefono celular. La principal diferencia
consiste en que el protocolo de transferencia por Internet mantiene el estado de la transferencia,
de esta manera es posible recuperarse de errores de transmision. Si la transferencia del archivo se
interrumpe, esta se reanuda en el punto en el que se interrumpio.
Modulo autenticacion: Este modulo tiene dos funciones, la primera es gestionar la autenticacion
y la segunda es gestionar llaves de sesion. En esta arquitectura el servidor de aplicacion actua tambien
38 3.2. Arquitectura del sistema de monitoreo de signos vitales
como autoridad autenticadora y autentica a los clientes. En este esquema de autenticacion cada uno
de los clientes comparte una llave secreta con el servidor de aplicacion y se asume que esta llave
secreta ha sido previamente distribuida. Los servicios proporcionados por el modulo de integridad y
confidencialidad requieren el uso de una llave simetrica temporal. Este modulo se encarga de gestionar
esta llave de sesion con el servidor de aplicacion.
Modulo de integridad y confidencialidad: La funcion de este modulo es proporcionar los
servicios de seguridad necesarios para realizar una transferencia de datos segura. Los servicios que
proporciona este modulo son la confidencialidad y la integridad. El servicio de confidencialidad se
proporciona por medio de un algoritmo de cifrado de llave simetrica. El servicio de integridad se
proporciona por medio del calculo de una funcion hash. El canal de comunicacion seguro entre cliente
y servidor se establece autenticando el cliente, posteriormente se cifra toda la informacion que el
cliente envıa al servidor y al final se verifica la integridad de la informacion transferida comparando
en el servidor las funciones hash calculadas en ambos extremos del canal de comunicacion.
3.2.2 Arquitectura del servidor de aplicacion
Las funciones que realiza el servidor de aplicacion son: el establecimiento de un canal de
comunicacion seguro con el cliente para efectuar la transferencia de los datos, la recepcion de los
datos provenientes del telefono celular, y la presentacion de los datos. La arquitectura del servidor
de aplicacion se muestra en la Figura 3.4, se compone de cuatro modulos los cuales se describen a
continuacion:
Modulo de transferencia de archivo por Internet: La funcion de este modulo es recibir
el archivo de datos enviado por la aplicacion cliente. Utilizando el protocolo de transferencia
desarrollado, se encarga tambien de mantener junto con el cliente el estado de la transmision del
archivo. En caso de que se presente una falla en la comunicacion el servidor reinicia la recepcion a
partir del ultimo bloque que recibio correctamente.
Modulo de autenticacion: Este modulo realiza dos funciones, responde a las peticiones de
autenticacion de los clientes y provee la llave de sesion que requieren los modulos de integridad y
3. Arquitectura 39
Presentaciónde datos
Transferenciade archivo por
Internet
Integridady
confidencialidadArchivo dedatos cifrado
Archivo de datosInternet
Aplicación en centro médico
Autenticación
Llave de sesión
Llave de sesión
Figura 3.4: Arquitectura del servidor
confidencialidad del cliente y del servidor. El servidor autentica a los clientes comparandolos contra
una lista de clientes registrados, cada registro en la lista consta de una identificacion de cliente y de
la llave secreta respectiva que el cliente comparte con el servidor. Una vez que se ha autenticado al
cliente, el servidor emite la llave de sesion correspondiente y se la envıa al cliente.
Modulo de integridad y confidencialidad: Su funcion es establecer un canal de comunicacion
seguro con su contra-parte en el lado de cliente. Proporciona los servicios de integridad y
confidencialidad necesarios para efectuar la transferencia segura de datos. Este modulo se encarga
de descifrar con la llave de sesion previamente distribuida los bloques de datos recibidos del cliente.
Al finalizar la recepcion del archivo se calcula el resumen del mismo utilizando una funcion hash
y se determina si el archivo se recibio ıntegro comparando el resumen recibido contra el resumen
calculado. El archivo se recibio ıntegro si ambos resumenes son iguales.
Modulo de presentacion de datos: La funcion de este modulo es presentar al personal en el
centro de atencion medica los datos recibidos del dispositivo monitor. Este modulo procesa y le da
formato a los datos para presentarlos por medio de una interfaz grafica, esta interfaz informa sobre
las alarmas emitidas por el dispositivo monitor y presenta las senales electricas cardiacas para que el
personal medico pueda realizar un diagnostico y en su caso gestionar la atencion medica necesaria
para el paciente que porta el dispositivo.
40 3.3. Resumen
3.3 Resumen
En este capıtulo se presentaron el caso practico en donde se demuestra la funcionalidad de la
plataforma propuesta, ası como la arquitectura del sistema. Esta arquitectura permite efectuar una
transferencia de datos segura a una aplicacion bajo el modelo cliente-servidor. Al mismo tiempo
la arquitectura incluye un modulo que permite utilizar una red WLAN cuando esta se encuentre
disponible, aprovechando ası las ventajas que proporciona esta, tales como mejor ancho de banda y
economıa, comparada con la red celular GPRS. Una caracterıstica importante de esta arquitectura
es que puede ser adaptada a diferentes aplicaciones y no solo al caso practico que se presenta.
En el siguiente capıtulo se presentaran con detalle las tres principales funciones de la arquitectura:
comunicaciones, handover vertical y seguridad.
4Comunicaciones
La arquitectura que se propuso en el capıtulo anterior esta compuesta de varios modulos los cuales
en conjunto realizan funciones que se organizan en tres areas principales, comunicaciones, servicios
para el manejo de handover vertical y servicios de seguridad. El area de comunicaciones realiza las
operaciones para efectuar la transferencia de datos entre el dispositivo monitor y el telefono celular
y entre el telefono celular y el servidor de aplicacion. El servicio de manejo de handover vertical se
encarga de realizar el cambio automatico entre las redes WLAN y GPRS para acceder a Internet, y
el area de seguridad incluye todas las operaciones para establecer un canal de comunicacion seguro
entre el telefono celular y el servidor de aplicacion para realizar la transferencia de datos. En este
capıtulo se describe detalladamente la implementacion de cada una de estas areas de la arquitectura.
4.1 Comunicaciones
El sistema de monitoreo de signos vitales transfiere informacion desde el dispositivo monitor hasta
el servidor de aplicacion, esta transferencia se hace pasando por dos tipos de red diferentes, Bluetooth
e Internet. Para efectuar esta transferencia de datos de manera confiable se utilizan dos protocolos
41
42 4.1. Comunicaciones
de comunicacion uno para cada tipo de red. Ambos protocolos son similares, la principal diferencia
consiste en el protocolo de transporte sobre el que se construyeron. El protocolo de transferencia para
Bluetooth se construyo sobre el protocolo RFCOMM y el protocolo para transferencia por Internet
se construyo sobre TCP/IP.
4.1.1 Transferencia de archivos por Bluetooth
El dispositivo monitor de signos vitales almacena en su memoria interna la informacion capturada
por los sensores colocados en el cuerpo del paciente. Estos datos deben ser enviados periodicamente
al centro medico para que se realice el diagnostico del estado del paciente. Esta transferencia de
informacion se realiza en dos pasos, primero los datos son transferidos del dispositivo monitor hacia
el telefono celular a traves de una interfaz Bluetooth, y posteriormente son transferidos desde el
telefono celular hacia el servidor de aplicacion a traves de Internet. La transferencia de datos por
medio de la interfaz Bluetooth requiere de la implementacion de un protocolo de transferencia de
archivo por dos razones. La primera es que el dispositivo monitor de signos vitales tiene capacidades
de computo limitadas y solo cuenta con una implementacion del protocolo de transporte RFCOMM
[12]. La segunda es que la comunicacion por Bluetooth presenta errores frecuentes y es necesario
algun mecanismo de recuperacion de errores adicional al que proporciona RFCOMM.
En este protocolo se usa un proceso de handshaking para establecer la comunicacion entre el
dispositivo monitor y el telefono celular. El handshaking es un proceso por el cual dos dispositivos
establecen un circuito virtual. El handshaking inicia cuando un dispositivo envıa un mensaje al otro
dispositivo para indicarle que quiere establecer un canal de comunicacion. Los dos dispositivos se
envıan a continuacion varios mensajes de ida y vuelta que les permite establecer y mantener la
comunicacion. Bajo condiciones normales, los mensajes que se intercambian entre el dispositivo
monitor y el telefono llegan a su destino pero en ocasiones algunos mensajes se pierden, para
evitar ciclos de espera infinitos al recibir los mensajes se utilizan tiempos de espera lımite. En este
protocolo se utilizan tres tipos de tiempos de espera, largos, medianos y cortos, el tipo de tiempo
de espera depende del comando del protocolo. Los tiempos de espera largo y mediano se utilizan
4. Comunicaciones 43
Protocolo de transferencia
API de sockets
RFCOMM
L2CAP
Figura 4.1: Ubicacion de protocolo de transferencia por Bluetooth
en los comandos de alarma y el tiempo de espera corto se utiliza en todos los comandos, como se
explica mas adelante en esta seccion. En esta implementacion del protocolo el tiempo de espera
largo se definio de 300 segundos, el mediano de 60 segundos y el corto de 5 segundos aunque estos
valores pueden ser configurados de manera diferente. Cuando hay perdida de mensajes o cuando se
presentan errores de comunicacion, el mecanismo de recuperacion de errores del protocolo suspende
completamente la transferencia del archivo para permitir que el telefono celular y el dispositivo
monitor se sincronicen de nuevo. Una vez sincronizados los dispositivos, la transferencia del archivo
se reanuda desde el inicio. Este mecanismo de recuperacion es simple pero suficiente para garantizar
que la transferencia de los archivos se lleve a cabo con exito.
El protocolo de transferencia esta colocado sobre el protocolo de transporte RFCOMM como se
muestra en la Figura 4.1. El protocolo RFCOMM emula los parametros de un cable de serie y el
estado de un puerto RS-232 para transmitir datos en serie. El protocolo RFCOMM se conecta a las
capas inferiores de la pila de protocolos Bluetooth a traves de la capa L2CAP [16]. La capa L2CAP
proporciona servicios de datos sin conexion y orientados a conexion y segmentacion y re-ensamble
de paquetes, entre otros servicios [22]. Entre de la capa RFCOMM y el protocolo de transferencia
se encuentra una capa con una API de sockets. Se utilizo un modelo de sockets para facilitar el
44 4.1. Comunicaciones
desarrollo del protocolo de transferencia y al mismo tiempo hacer mas portable este desarrollo. El
conjunto mınimo de funciones que se usaron para este modelo se describen a detalle en el Anexo A.
La especificacion del protocolo de transferencia incluye los comandos que se muestran en la Tabla
3.1.
AckAlarmaAmaril laCelularDispositivo
moni tor
AlarmaAmari l la
Figura 4.2: Intercambio de mensajes de comando AlarmaAmarilla
El comando AlarmaAmarilla: Este comando es emitido por el dispositivo monitor. La alarma
amarilla se emite para alertar al paciente cuando se ha detectado un problema de salud no crıtico.
La alarma amarilla le indica al paciente que debe visitar al doctor en las siguientes 24 horas. En una
situacion ideal el intercambio de mensajes se hace como se muestra en la Figura 4.2. El dispositivo
emite el comando AlarmaAmarilla y el telefono celular responde con el comando de reconocimiento
AckAlarmaAmarilla.
EnvíaAlarmaAmaril la
Espera AckAlarmaAmaril la
Estado Inicial
Timeout (300 seg.)
Celular
AckAlarmaAmaril la
Espera comandos
AlarmaAmaril la
Dispositivomoni tor
EnvíaAckAlarmaAmaril la
Figura 4.3: Procesamiento del comando AlarmaAmarilla
En una situacion real los mensajes que se intercambian entre el dispositivo monitor y el telefono
4. Comunicaciones 45
celular pueden no llegar a su destino, el protocolo de transferencia toma en cuenta esta situacion y
define estados de espera como se muestra en el diagrama de la Figura 4.3. El problema de los mensajes
perdidos se soluciona introduciendo tiempos de espera lımite (timeout) cuando se esta esperando
un comando. Cuando el dispositivo monitor emite el comando AlarmaAmarilla espera recibir del
telefono celular un comando de reconocimiento AckAlarmaAmarilla, si este comando se recibe el
dispositivo regresa a su estado inicial, si el reconocimiento no se recibe en un tiempo de espera lımite
largo, el dispositivo monitor vuelve a emitir la alarma. El telefono celular por su parte inicialmente
esta en un estado de espera infinito esperando comandos de alarma, cuando se recibe el comando
AlarmaAmarilla el telefono responde con el comando de reconocimiento AckAlarmaAmarilla y regresa
a su estado inicial.
AckAlarmaRoja CelularDispositivomoni tor
AlarmaRoja
Figura 4.4: Intercambio de mensajes de comando AlarmaRoja
El comando AlarmaRoja: Este comando es emitido por el dispositivo monitor. La alarma roja
se emite para alertar al paciente cuando se ha detectado un problema de salud crıtico. La alarma
roja le indica al paciente que debe conseguir asistencia medica inmediatamente. El intercambio de
mensajes de este comando se hace como se muestra en la Figura 4.4. El dispositivo emite el comando
AlarmaRoja y el telefono celular responde con el comando de reconocimiento AckAlarmaRoja.
Como se muestra en Figura 4.5, cuando el dispositivo monitor emite el comando AlarmaRoja
espera recibir del telefono celular un comando de reconocimiento AckAlarmaRoja, si este comando
se recibe el dispositivo regresa a su estado inicial, si el reconocimiento no se recibe en el tiempo de
espera lımite mediano, el dispositivo monitor vuelve a emitir la alarma. El telefono celular por su parte
inicialmente esta en un estado de espera infinito esperando comandos de alarma, cuando se recibe
46 4.1. Comunicaciones
EnvíaAlarmaRoja
Espera AckAlarmaRoja
Estado Inicial
Timeout (60 seg.)
Celular
AckAlarmaRoja
Espera comandos
AlarmaRoja
Dispositivomoni tor
EnvíaAckAlarmaRoja
Figura 4.5: Procesamiento del comando AlarmaRoja
el comando AlarmaRoja la aplicacion en el telefono responde con el comando de reconocimiento
AckAlarmaRoja y regresa a su estado inicial. El tiempo de espera lımite del reconocimiento de la
alarma roja es menor que el de la alarma amarilla. Esto se debe al caracter de urgencia de la
alarma roja, cuando esta se emite el paciente necesita recibir atencion medica urgente, por lo tanto
es necesario que la aplicacion en el telefono celular confirme al dispositivo monitor lo mas pronto
posible si recibio tal alarma, para que en caso contrario el dispositivo monitor envie de nuevo la
alarma roja.
GetConfirmarBorrarCelular Dispositivomoni tor
BorraMemoria
AckBorraMemoria
Figura 4.6: Intercambio de mensajes de comando BorraMemoria
Comando BorraMemoria: El comando BorraMemoria es emitido por el telefono celular. Este
comando le indica al dispositivo monitor que elimine de su memoria interna los archivos con los
datos de las senales electricas cardiacas. Suponiendo un ambiente libre de errores de transmision, el
intercambio de mensajes de este comando se hace como se muestra en la Figura 4.6. El telefono
emite el comando BorraMemoria y el dispositivo monitor responde con el comando de solicitud
4. Comunicaciones 47
de confirmacion de borrado GetConfirmarBorrar, el telefono al recibir la solicitud de confirmacion
responde con el comando de confirmacion de borrado AckBorraMemoria, el dispositivo monitor al
recibir la confirmacion del borrado procede a eliminar los archivos de datos.
EnvíaBorraMemoria
EsperaGetConfirmBorrar
EnvíaAckBorraMemoria
Timeout
Celular
GetConfirmarBorrar
Esperacomandos
BorraMemoria
Dispositivomoni tor
EnvíaGetConfirmarBorrar
Estadoinicial
EsperaAckBorraMemoria
Borramemor ia
Timeout
AckBorraMemoria
Figura 4.7: Procesamiento del comando BorraMemoria
En la Figura 4.7 se muestra el funcionamiento del comando BorraMemoria tomando en cuenta
los posibles errores de comunicacion que se pudieran presentar. El telefono celular emite una solicitud
de borrado de memoria con el comando BorraMemoria, y entra en un estado de espera para
recibir del dispositivo monitor una solicitud de confirmacion del borrado por medio de comando
GetConfirmarBorrar, si la solicitud de confirmacion no se recibe en un tiempo lımite corto, el protocolo
pasa a su estado inicial, si se recibe, el celular emite el comando de reconocimiento AckBorraMemoria
para indicarle al dispositivo monitor que se confirma el comando de borrado de memoria. El dispositivo
monitor por su parte al recibir el comando BorraMemoria le envıa al telefono celular el comando
GetConfirmarBorrar para solicitarle la confirmacion del borrado de memoria, y pasa a un estado de
espera para recibir el comando AckBorraMemoria, si este no se recibe en el tiempo lımite corto el
comando BorraMemoria es ignorado, si se recibe, se procede al borrado de la memoria interna.
Comando GetInfoPaciente: El comando GetInfoPaciente es emitido por el telefono celular.
Este comando le indica al dispositivo monitor que envıe al telefono celular los datos personales del
48 4.1. Comunicaciones
paciente tales como, nombre, edad, peso, etc. El intercambio de mensajes del comando sin considerar
los posibles errores en la comunicacion se muestra en la Figura 4.8.
SendingInfoPacienteCelular Dispositivomoni tor
GetInfopaciente
Figura 4.8: Intercambio de mensajes de comando GetInfoPaciente
En la Figura 4.9 se muestra el funcionamiento del comando GetInfoPaciente tomando en cuenta
que una situacion real se presentan errores en la comunicacion. El telefono emite el comando
GetInfoPaciente y entra en un estado de espera para recibir del dispositivo monitor el comando
SendingInfoPaciente, si este comando no se recibe en un tiempo lımite corto, el telefono pasa a su
estado inicial, si se recibe, se pasa a un estado para recibir la informacion del paciente y cuando se
termina de recibir se pasa al estado inicial. El dispositivo monitor por su parte al recibir el comando
GetInfoPaciente procede a enviar el comando SendingInfoPaciente para indicarle al telefono que se
va a iniciar el envıo de los datos del paciente y posteriormente envıa estos datos.
EnvíaGetInfoPaciente
Espera SendingInfoPaciente
Recibe datos
del paciente
Timeout
Celular
SendingInfoPaciente
Espera comandos
GetInfoPaciente
Disposit ivo monitor
EnvíaSendingInfoPaciente,datos del paciente
Estadoinicial
Figura 4.9: Procesamiento del comando GetInfoPaciente
4. Comunicaciones 49
SendingIDCelular Dispositivomoni tor
GetID
Figura 4.10: Intercambio de mensajes de comando GetID
Esta estructura de protocolo se repite para los comandos GetID y GetTemperatura, sus
intercambios de mensajes se muestran en las Figuras 4.10 y 4.12. Ası tambien el funcionamiento de
estos comandos en una situacion real es muy similar al funcionamiento del comando GetInfoPaciente,
solo cambia la informacion que se obtiene del dispositivo monitor, como se muestra en las Figura
4.11 y 4.13.
EnvíaGetID
Espera SendingID
Recibe modelo, serie,
versión f i rmware
Timeout
Celular
SendingID
Espera comandos
GetID
Dispositivomoni tor
EnvíaSendingID,
modelo, serie, ver. f irmware
Estadoinicial
Figura 4.11: Procesamiento del comando GetID
El comando GetArchivos: El comando GetArchivos es emitido por el telefono celular. El
dispositivo monitor responde a este comando enviando hacia el telefono celular todos los archivos con
los datos de las senales electricas cardiacas. Ignorando los errores de comunicacion, el intercambio
de mensajes del comando GetArchivos se hace como se muestra en la Figura 4.14, en esta figura
podemos observar que el envıo de cada archivo no se hace en una sola operacion sino que se hace
50 4.1. Comunicaciones
SendingTemperaturaCelularDispositivo
moni tor
GetTemperatura
Figura 4.12: Intercambio de mensajes de comando GetTemperatura
EnvíaGetTemperatura
EsperaSendingTemp
Recibetemperatura
Timeout
Celular
SendingTemp
Esperacomandos
GetTemperatura
Dispositivomoni tor
EnvíaSendingTemp
Timeout
Estadoinicial
Figura 4.13: Procesamiento del comando GetTemperatura
4. Comunicaciones 51
por bloques. El telefono celular emite el comando GetArchivos, el dispositivo puede responder con el
comando SendingArchivo si hay archivos en el dispositivo, seguido del archivo que se envıa, o con el
comando SinArchivos, si no hay archivos en el dispositivo.
SendingArchivo
Celular Dispositivomoni tor
GetArchivos
bloque de datos
FinArchivo
BloqueRecibido
. . .
SinArchivosCelular Dispositivomoni tor
GetArchivos
Figura 4.14: Intercambio de mensajes del comando GetArchivos
En la Figura 4.15 se muestra el funcionamiento general del comando GetArchivos en condiciones
reales. El telefono celular emite el comando GetArchivos y entra en un estado de espera en
donde puede recibir un comando SendingArchivo por cada archivo que se recibe, un comando de
FinTransmision cuando se hayan enviado todos los archivos, o un comando SinArchivos si no hay
archivos en el dispositivo monitor.
Cuando el dispositivo monitor tiene archivos en la memoria, el telefono celular recibe el comando
SendingArchivo y pasa a un estado para recibir los archivos enviados por el dispositivo. En la Figura
4.16 se muestra el funcionamiento a detalle del envıo y recepcion de cada archivo dentro del comando
GetArchivos. Despues de que el telefono envio el comando GetArchivos entra en un estado de espera,
en este estado se puede recibir un comando SendingArchivo, si el dispositivo va a enviar un archivo, o
un comando FinTransmision si el dispositivo ya envio todos los archivos. Si no se recibe una respuesta
en un tiempo de espera corto, el telefono celular pasa a un estado de espera para sincronizarse con
el dispositivo monitor y despues vuelve a emitir el comando GetArchivos. Si se recibio un comando
SendingArchivo, el telefono pasa a un estado en donde se reciben los bloques que forman un archivo,
de este estado se sale si se excede el tiempo de espera de algun bloque o si recibe el comando
52 4.1. Comunicaciones
EnvíaGetArchivos
Recibearchivo
Celular
Esperacomandos
Obtenlista de archivos
GetArchivos
EnviaSinArchivos
No hayarchivos
Si hayarchivos
EnvíaArchivo
EnvíaFinTransmisión
No hay masarchivos
Dispositivomoni tor
EstadoInicial
SinArchivos /FinTransmisión
Obtensiguientearchivo
Siguientearchivo
Figura 4.15: Procesamiento del comando GetArchivos
FinArchivo. Si se excedio el tiempo de espera de algun bloque se pasa al estado de sincronizacion. Si
se recibe un comando FinArchivo se envıa al dispositivo el comando ArchivoRecibido para confirmar
la recepcion. En el dispositivo por su parte cuando se recibe el comando GetArchivos se envıa al
celular el comando SendingArchivo y se pasa a un estado para enviar los bloques que forman un
archivo. De este estado se sale si hay algun error en el envıo de un bloque o si se alcanzo el fin
del archivo. Si hubo algun error, se pasa a un estado de espera para sincronizarse con el telefono.
Si se alcanzo el fin de archivo, se envıa al telefono el comando FinArchivo y se pasa a un estado
para esperar el comando ArchivoRecibido. Si el comando ArchivoRecibido no se recibe en un tiempo
de espera corto, se pasa al estado de espera para sincronizarse con el telefono, si el comando se
recibio se procede a obtener el siguiente archivo para ser enviado.
Comando StartDatosContinuos: El comando StartDatosContinuos es emitido por el telefono
celular. Este comando le indica al dispositivo monitor que envıe al telefono celular periodicamente
los datos de las senales electricas cardiacas hasta que se reciba el comando StopDatosContinuos. El
intercambio de mensajes se hace como se muestra en la Figura 4.17, al igual que en los comandos
anteriores se asume un escenario ideal. Cada vez que el dispositivo se dispone a enviar los datos de
las senales electricas cardiacas, le envıa al telefono el comando SendingDatosContinuos.
4. Comunicaciones 53
Envia GetArchivos
EsperaSendingArchivo/FinTransmisión
RecibeBloques
Celular
SendingArchivo
FinArchivo
Esperacomandos
GetArchivos
EsperaArchivoRecibido
EnvíaSendingArchivo
EnvíaBloques
EnvíaArchivoRecibo
EnvíaFinArchivo
Fin deArchivo
Dispositivomoni tor
TimeOut
Estadode espera
TimeOutEstado
de esperaError
Timeout
ArchivoRecibido
Obtensiguientearchivo
Estadoinicial
FinTransmisión
Figura 4.16: Procesamiento de envıa/recibe archivo
En un escenario real, el comando StartDatosContinuos funciona como se muestra en la Figura
4.18. El telefono emite el comando StartDatosContinuos y entra en un estado de espera para recibir
del dispositivo monitor el comando SendingDatosContinuos, si este comando no se recibe en un
tiempo de espera corto el telefono pasa a su estado inicial, de lo contrario recibe los datos de las
senales electricas cardiacas. El telefono permanece en este estado de espera de datos hasta que se
emite el comando StopDatosContinuos. El dispositivo monitor por su parte al recibir el comando
StartDatosContinuos entra en un estado en donde envıa el comando SendingDatosContinuos para
indicarle al telefono que se va a iniciar el envıo de las senales electricas cardiacas, y posteriormente
hace el envıo de los datos. El dispositivo permanece en un ciclo en este estado hasta que ocurre
un error de transmision o se recibe el comando StopDatosContinuos, en cualquiera de los casos el
dispositivo regresa al estado inicial.
Formato de mensajes: Los comandos del protocolo se codifican por medio de un numero de
8 bits, y su longitud varıa dependiendo del tipo de comando. Los formatos de los mensajes de los
comandos que no contiene informacion adicional como los de alarma y el comando de borrado tiene
una longitud de un byte como se muestran en la figura 4.19.
54 4.1. Comunicaciones
SendingDatos
Celular Dispositivomoni tor
StopDatosContinuos
. . .
StartDatosContinuos
SendingDatos
Figura 4.17: Intercambio de mensajes de comando StartDatosContinuos
EnvíaStartDatosContinuos
Recibedatos continuos
Celular
Esperacomandos
StartDatosContinuos
Disposit ivo Monitor
EnviarSendingDatos
StopDatosContinuos/TimeOut
Timeout/StopDatosContinuos
Estadoinicial
SendingDatos
Figura 4.18: Procesamiento del comando StartDatosContinuos
El formato del mensaje del comando GetInfoPaciente y de su correspondiente mensaje de
respuesta SendingInfoPaciente se muestran en la Figura 4.20. La longitud del mensaje de respuesta
SendingInfoPaciente es de 245 bytes, el primer byte identifica al mensaje y los 244 bytes restantes
contienen la informacion del paciente.
El formato de los mensajes utilizados para el envıo de archivos se muestra en la Figura 4.21.
El mensaje del comando SendingArchivo contiene el encabezado del archivo que se va a enviar. El
archivo se envıa en bloques, la longitud del bloque utilizado por el comando GetArchivos para el envıo
de datos es de 667 bytes. Como se explicara mas adelante en el capıtulo 5, este valor se escogio por
que es el que ofrece el mejor balance entre tiempos de transmision razonables y menor numero de
4. Comunicaciones 55
AlarmaAmari l la
AlarmaRoja
AckAlarmaAmaril la
AckAlarmaRoja
05
0A
0F
14
19
1E
BorraMemoria
GetConfirmarBorrar
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
AckBorraMemoria1 byte20
Figura 4.19: Formato de mensajes de comandos simples
errores de comunicacion.
La estructura del formato de los mensajes de los comandos GetID, GetTemperatura y
StartDatosContinuos se muestra en la Figura 4.22.
4.1.2 Comunicacion entre telefono celular y servidor de aplicacion por
Internet
La transferencia de datos desde el telefono celular hacia una computadora de escritorio que actua
como servidor de aplicacion forma parte de la plataforma sobre la cual se pueden desarrollar otras
aplicaciones. Esta transferencia se efectua a traves de Internet ya sea por medio del servicio de datos
GPRS o por medio de una red WLAN. Para efectuar el envıo de archivos entre el telefono celular y
el servidor de aplicacion a traves de Internet se desarrollo un protocolo de transferencia de archivos
basado en el protocolo TCP/IP. Este protocolo esta ubicado sobre el protocolo de transporte TCP
de la pila de protocolos TCP/IP (Figura 4.23). TCP comprueba que ningun segmento se ha perdido
dando a cada uno un numero de secuencia, que es tambien usado para asegurarse de que los paquetes
56 4.1. Comunicaciones
GetInfoPaciente
Edad
78
7D
Estatura
Contacto
1 byte
1 byte
NombreFecha de nacimiento
Otros datosInformación de doctor
50 bytes
Información del paciente
244 bytes
245 bytes SendingInfoPaciente
PesoTipo de sangreAlergiasCURP
8 bytes 4 bytes 4 bytes 4 bytes 4 bytes
12 bytes 16 bytes 12 bytes 50 bytes 80 bytes
Figura 4.20: Formato de mensajes del comando GetInfoPaciente
han llegado a la entidad destino en el orden correcto. TCP devuelve un reconocimiento por bytes
que han sido recibidos correctamente; un temporizador en la entidad origen del envıo verifica si el
reconocimiento no es recibido en un tiempo de espera lımite, y el paquete sera entonces retransmitido.
TCP revisa que no haya bytes danados durante el envıo usando un checksum; este es calculado por
el emisor en cada paquete antes de ser enviado, y comprobado por el receptor.
El protocolo de transferencia de archivos por Internet es similar al utilizado en la comunicacion
entre el dispositivo monitor y el telefono celular. La principal diferencia se encuentra en el mecanismo
de recuperacion de errores de comunicacion durante la transferencia de archivos. El protocolo de
transferencia por Internet mantiene el estado de la transferencia, de esta manera es posible incorporar
un mecanismo de recuperacion de errores mas eficiente. Si la transferencia del archivo se interrumpe,
esta se reanuda en el punto en el que se interrumpio. Este esquema de recuperacion de errores
es necesario debido a que las interrupciones en la transferencia de datos se pueden presentar con
mas frecuencia en este protocolo. Aunque tanto GPRS como Wi-Fi proporcionan una comunicacion
mas confiable que Bluetooth, las interrupciones en la transferencia de datos se pueden presentar no
solo por errores de transmision sino por el cambio de red de comunicacion que produce el modulo
de handover vertical que forma parte de la arquitectura. Como se explica mas detalladamente en
4. Comunicaciones 57
GetArchivos
Modo de almacenamiento
28
32
Derivación usada
1 byte
1 byte
NombreFecha y hora
128 bytes
Encabezado del archivo
141 bytes
142 bytes SendingArchivo
Frecuencia de muestreo EGG
7 bytes 2 bytes 2 bytes 2 bytes
SinArchivos1 byte2D
Figura 4.21: Formato de mensajes del comando GetArchivos
Comandos Iniciados por celular Respuesta del servidorENVIA ARCHIVO COMANDO RECIBIDO
RETRANSMITE ARCHIVO Ultimo bloque recibido
EOF EOF RECIBIDO
Bloque de datos BLOQUE RECIBIDO
Tabla 4.1: Comandos del protocolo de transferencia de archivo por Internet
la siguiente seccion, el modulo de handover permite cambiar de la red GPRS a una red Wi-Fi y
viceversa. Estos cambios de una red a otra se pueden presentar varias veces durante la transferencia
de un archivo y no serıa conveniente tener que reanudar la transferencia desde el inicio cada vez que
se presenta un cambio de red, mas aun, cuando el cambio de red se da hacia GPRS serıa deseable
conservar la parte del archivo que ya se ha transferido para ahorrar costos. En este protocolo solo
se usa un tiempo de espera lımite para resolver el problema de los mensajes perdidos para todos los
comandos. El tiempo de espera lımite usado en esta implementacion es de 5 segundos.
La implementacion de las alarmas y de los demas comandos del protocolo de comunicacion entre
el dispositivo monitor y el telefono celular es posible tambien realizarla sin problema en este protocolo
de transferencia por Internet, sin embargo solo se ha implementado la transferencia de archivos por
ser la operacion mas compleja y la que tiene mayor relevancia.
Al igual que en el protocolo para transferencia de archivos por Bluetooth, en el desarrollo de
58 4.1. Comunicaciones
GetTempera tura
Versión de firmware
6E
87
1 byte
1 byte
ModeloNúmero de serie
40 bytes
Información de identif icación
60 bytes
61 bytes SendingID
10 bytes 10 bytes
SendingTemp2 bytes73
Get ID1 byte82
Temperatura
1 byte
50
55
5A
1 byte
1 byte
1 byte
Star tDatosCont inuos
SendingDatos
StopDatosCont inuos
Figura 4.22: Formato de mensajes de comandos GetID, GetTemperatura y StartDatosContinuos
este protocolo se utilizo el modelo de sockets de TCP. Debido a que el modelo de sockets de TCP
es bastante comun y a que la documentacion es ampliamente disponible no se abundara sobre este
tema. En este protocolo de transferencia, el telefono celular actua como cliente y una computadora
de escritorio actua como servidor. Los comandos de este protocolo se muestran en la Tabla 4.1. Este
protocolo tiene dos comandos principales ENVIA ARCHIVO y RETRANSMITE ARCHIVO, de estos
dos comandos se derivan otros comandos que los complementan y que consisten basicamente en
respuestas y reconocimientos.
El comando ENVIA ARCHIVO: En este protocolo de transferencia, el servidor de aplicacion
esta en espera de recibir del cliente peticiones de envıo de archivos hacia el servidor. El comando
ENVIA ARCHIVO le indica al servidor de aplicacion que un cliente (telefono celular) desea iniciar una
sesion de transferencia para enviar un archivo hacia el servidor. Este comando inicia una secuencia de
4. Comunicaciones 59
Protocolo de transferenciadesarrollado
Protocolos de aplicaciónFtp, Telnet, SMTP
TCP/UDP
IP
GPRS 802.11
Figura 4.23: Ubicacion del protocolo de transferencia en modelo de capas tcp/ip
intercambio de mensajes. En la Figura 4.24 se muestra este intercambio considerando un escenario
libre de errores de comunicacion. El servidor le confirma al cliente que recibio este comando, por
medio de un mensaje de reconocimiento COMANDO RECIBIDO. El servidor por su parte despues de
recibir el comando ENVIA ARCHIVO, espera a que el cliente le envıe los mensajes con los bloques
de datos que forman el archivo. A cada mensaje de bloque de datos recibido, el servidor responde
con un mensaje de reconocimiento BLOQUE RECIBIDO.
En la Figura 4.25 se muestra el funcionamiento del comando ENVIA ARCHIVO considerando
los errores de transmision que se puedan presentar, el telefono celular emite el comando
ENVIA ARCHIVO y entra en un estado de espera para recibir del servidor de aplicacion el comando
COMANDO RECIBIDO, si se recibe el comando, el telefono pasa a un estado en donde se envıan
todos los bloques que forman el archivo, de este estado se sale cuando se alcanza el fin de archivo o
si no se recibio la confirmacion de la recepcion en el servidor de algun bloque en el tiempo de espera
lımite. Cuando se alcanza el fin del archivo que se esta enviando, el telefono emite el comando EOF
para indicarle al servidor que termino el envıo de bloques de datos y el telefono entonces entra en un
estado de espera para recibir el comando EOF RECIBIDO, cuando el comando se recibe, el telefono
pasa a su estado inicial, si el comando no se recibe se pasa al estado de espera para sincronizarse con
60 4.1. Comunicaciones
COMANDO_RECIBIDO
Celular Servidor de aplicación
ENVIA_ARCHIVO
. . .
bloque 1
bloque n
EOF
BLOQUE_RECIBIDO
EOF_RECIBIDO
Figura 4.24: Intercambio de mensajes de comando ENVIA ARCHIVO
el servidor de aplicacion y reiniciar la transmision del archivo. El servidor de aplicacion por su parte
esta esperando recibir comandos, cuando recibe el comando ENVIA ARCHIVO, el servidor le confirma
al telefono la recepcion del comando emitiendo a su vez el comando COMANDO RECIBIDO y pasa
a un estado en donde se reciben los bloques de datos, a cada bloque recibido el servidor responde
con un mensaje de confirmacion BLOQUE RECIBIDO, de este estado se sale si recibe el comando
EOF o si se presenta algun error en la recepcion de los bloques. Si se recibio el comando EOF el
servidor emite el comando EOF RECIBIDO para confirmarle al telefono que recibio el comando EOF.
Si hubo algun error en la recepcion de bloques, el servidor pasa a un estado para salvar el estado de
la transferencia y despues pasa a un estado de espera para sincronizarse con el telefono.
El comando RETRANSMITE ARCHIVO: En general este comando es muy similar al
comando ENVIA ARCHIVO. El comando RETRANSMITE ARCHIVO es enviado por el telefono
y le indica al servidor que la transferencia de un archivo fallo y que se va a reiniciar en el punto en
que se interrumpio. Esto se logra porque al presentarse un error en la recepcion de algun bloque de
datos en el servidor, se salva el consecutivo del ultimo bloque que se recibio correctamente. En la
Figura 4.26 se muestra el intercambio de mensajes del comando, este intercambio es practicamente
4. Comunicaciones 61
EsperaCOMANDO_RECIBIDO
EnvíaBloques
Celular
Fin dearchivo
Esperacomandos
ENVIA_ARCHIVO
EsperaEOF_RECIBIDO
EnvíaCOMANDO_RECIBIDO
RecibeBloques
EnvíaEOF
EnvíaEOF_RECIBIDO
EOF
Servidor de aplicación
TimeOut
Estadode espera
TimeOut Estadode espera
Error
Timeout
EOF_RECIBIDO
EmiteENVIA_ARCHIVO
COMANDO_RECIBIDO
Estadoinicial
Guardaestado de
transferencia
Figura 4.25: Procesamiento del comando ENVIA ARCHIVO
últ imo bloque recibido
Celular Servidor de aplicación
RETRANSMITE_ARCHIVO
. . .
bloque n + 1
bloque m
EOF
BLOQUE_RECIBIDO
EOF_RECIBIDO
Figura 4.26: Intercambio de mensajes de comando RETRANSMITE ARCHIVO
62 4.1. Comunicaciones
igual al del comando ENVIA ARCHIVO, la unica diferencia es que en respuesta al comando
RETRANSMITE ARCHIVO, el servidor responde con el consecutivo del ultimo bloque recibido y
no con una confirmacion.
Esperaúlt imo bloque
recibidoEnvía
Bloques
Celular
Fin dearchivo
Esperacomandos
RETRANSMITE_ARCHIVO
EsperaEOF_RECIBIDO
Envíaúlt imo bloque
recibido
RecibeBloques
EnvíaEOF
EnvíaEOF_RECIBIDO
EOF
Servidor de aplicación
TimeOut
Estadode espera
TimeOut
Estadode espera
Error
Timeout
EOF_RECIBIDO
EmiteRETRANSMITE_ARCHIVO
últ imo bloque recibido
Estadoinicial
Guardaestado de
transferencia
Figura 4.27: Procesamiento del comando RETRANSMITE ARCHIVO
El funcionamiento del comando RETRANSMITE ARCHIVO en una situacion real se muestra
en la Figura 4.27, aquı tambien se observa que la unica diferencia con respecto al comando
ENVIA ARCHIVO es que el servidor responde al comando con el consecutivo del ultimo bloque
recibido y no con una confirmacion.
Formato de mensajes: Los comandos del protocolo se codifican por medio de un numero de 8
bits. En la Figura 4.28 se muestran los formatos de los mensajes del protocolo, todos los mensajes
de los comandos son de 1 byte de longitud excepto el comando ENVIA ARCHIVO, que tiene una
longitud de 256 bytes. El mensaje que contiene el bloque de datos esta formado por dos partes como
se muestra en la Figura 4.29, la primera es un numero consecutivo de bloque de 4 bytes, la segunda
es el bloque de datos el cual puede variar de 256 a 4096 bytes.
4. Comunicaciones 63
ENVIA_ARCHIVO10h 256 bytes
RETRANSMITE_ARCHIVO20h
COMANDO_RECIBIDO1 byte30h
1 byte
FFh 1 byte
1 byte
EOF
EOF_RECIBIDO40h
Nombre de archivo
255 bytes
Figura 4.28: Formato de mensajes de comandos del protocolo
Número de bloque Bloque de datos
4 bytes 256 a 4096 bytes
Figura 4.29: Formato de mensaje de bloque de datos
4.2 Handover vertical GPRS/WLAN
En la mayorıa de las aplicaciones para telefonos celulares con interfaz Wi-Fi, la seleccion de la
red que se va a utilizar para acceder a Internet no se hace de manera automatica, por lo general
el sistema operativo del telefono celular proporciona un menu de seleccion al momento de ejecutar
la aplicacion o alguna manera de configurar de manera predeterminada la red de acceso a Internet.
Las aplicaciones que acceden a Internet desde telefonos celulares con interfaz Wi-Fi requieren la
integracion de las redes WLAN y GPRS para que el acceso a Internet sea transparente para el
usuario. El proceso de handover vertical ha sido ampliamente tratado en la literatura formal y se han
propuesto diferentes soluciones.
En [21], Salkintzis discute las motivaciones para la integracion de redes WLAN con redes celulares
64 4.2. Handover vertical GPRS/WLAN
3G y presenta un esquema para acoplar estrechamente una red WLAN con redes GPRS. El esquema
propuesto garantiza autenticacion, autorizacion y facturacion comunes, ası como continuacion
imperceptible del servicio a traves de redes GRPS y WLAN. En este sistema la red WLAN es
desplegada como una red alternativa y se conecta al nucleo de la red GPRS a traves de la interfaz
estandar Gb. Desde el punto de vista del nucleo de la red, la WLAN es considerada como cualquier
otra area de encaminamiento GPRS en el sistema. Los dos componentes principales de este esquema
son el GIF (GPRS Interworking Function) que conecta el sistema de distribucion (DS) con el nodo
de apoyo de servicio GPRS (SGSN), y la funcion de adaptacion WLAN (WAF) que proporciona las
funciones apropiadas de trabajo de red conjunto, y que hace factible el transporte de senalizacion y
datos GPRS sobre redes WLAN 802.11.
En [7] se propone una arquitectura hıbrida para soportar handover vertical entre una red IEEE
802.11 y una red UMTS (Universal Mobile Telecommunications System) , que incorpora el protocolo
SIP (Session Initiation Protocol) y el protocolo IP movil. Dado que los protocolos IP movil y SIP
son arquitecturas disenadas para diferentes aplicaciones, la solucion que se propone incorpora IP
movil y SIP en una sola arquitectura en donde los dos protocolos se complementan uno al otro. Esta
arquitectura multicapa usa el protocolo SIP para el dominio del tiempo real, y el protocolo IP movil
para el dominio del tiempo no real.
En [11] se propone un esquema de handover vertical entre redes WLAN y GPRS basado en el
encaminamiento. Ademas, se presenta un modelo de decision para el handover, que reduce el tiempo
latente del procedimiento de handover. La arquitectura del sistema propuesto difiere del IP movil
estandar, se utiliza una tarjeta de interfaz de red virtual (NIC virtual) en lugar del agente foraneo
utilizado en el IP movil. Debido a que la escasez de direcciones de IP es un problema serio, el
protocolo NAT se usa extensivamente. Para inter-operar con NAT, se aplica un metodo para hacer
tuneles de UDP. Se propone tambien un modelo de decision disenado para reducir la perdida de
paquetes e incrementar el rendimiento. Para lograr esto se propone un mecanismo de pre-handover
para poner el GPRS en estado de preparacion antes de que ocurra el handover.
En un artıculo de Song et al del 2007 [24] se propone un esquema de acoplamiento hıbrido para
soportar trabajo conjunto entre redes UMTS y WLAN que distingue las rutas del trafico de acuerdo al
4. Comunicaciones 65
tipo de trafico. Para trafico de tiempo real se escogio la arquitectura de red estrechamente acoplada.
Para trafico de tiempo no real se utilizo la arquitectura debilmente acoplada. En el esquema de
acoplamiento hıbrido los autores usan IP movil y la opcion de atadura simultanea para soportar
movilidad de IP para ambas rutas de trafico. Los autores afirman que con el esquema propuesto es
posible soportar el handover de manera imperceptible y que la red acomoda el trafico de tiempo real
proveniente de la WLAN de manera eficiente, sin embargo no se menciona que se haya realizado
alguna implementacion del mismo.
En el artıculo de Ma et al [15] se propone un metodo para facilitar el handover vertical entre
redes UMTS y WLAN usando el protocolo MSCTP (Mobile Stream Control Transmission Protocolo).
Los autores escogieron este protocolo debido a una caracterıstica llamada multi-homing, esta
caracterıstica permite agregar la interfaz sin importar si la interfaz en el extremo de la red pertenece
a la misma tecnologıa, siempre y cuando sea posible establecer una conexion a Internet por medio de
una direccion de IP. El protocolo ofrece una solucion de handover suave de extremo a extremo para
manejo de movilidad, y a diferencia de las tecnicas basadas en MIP (Mobile Internet Protocol) o SIP, el
esquema propuesto no requiere componentes adicionales como agentes locales/foraneos o servidores
SIP. Los autores afirman, basados en simulaciones, que el desempeno mejora significativamente, sin
demostrarlo con una implementacion o prototipo.
En [13] se propone un protocolo de manejo de movilidad vertical para redes de acceso
UMTS/WLAN para usuarios vehiculares de movimiento rapido. Este protocolo utiliza un algoritmo
de prediccion para determinar la siguiente posicion del usuario movil basandose en informacion de
localizacion adquirida por un sistema GPS, y por los informes de administracion de energıa de la red
UMTS. El sistema intenta determinar proactivamente a cual punto de acceso WLAN o estacion base
UMTS cambiara el usuario y cuando deberıa ocurrir este handover. Los autores afirman que con este
protocolo se puede lograr un handover imperceptible y rapido de UMTS a WLAN y viceversa, sin
embargo los resultados fueron obtenidos por medio de una simulacion y no por la implementacion
fısica mediante un prototipo.
La mayorıa de los trabajo revisados sin embargo se han limitado a presentar propuestas de solucion
o simulaciones, y en los casos en donde se ha hecho alguna implementacion, en su mayorıa no se
66 4.2. Handover vertical GPRS/WLAN
ha considerado el uso de dispositivos moviles como telefonos celulares inteligentes o PDA. En otros
trabajos se utilizan los protocolos de movilidad SIP y MIP los cuales no estan estandarizados haciendo
difıcil la implementacion practica de estos mecanismos de handover. Se encontro tambien que en
ninguno de los trabajos revisados se han construido aplicaciones que funcionen sobre la plataforma
de handover propuesta.
En este trabajo de tesis a diferencia de los casos revisados en la literatura formal, se hizo una
implementacion de la plataforma de handover propuesta en un telefono celular. La plataforma
de handover permite a las aplicaciones que se ejecutan en el telefono celular y que acceden
a Internet, cambiar de manera automatica entre redes GPRS y WLAN. Esta implementacion
se desarrollo utilizando el protocolo TCP/IP, el cual es un protocolo para comunicaciones por
Internet que esta ampliamente distribuido haciendo que esta se facilmente transportable a diferentes
plataformas de computo. Ademas se desarrollo una aplicacion practica que permite efectuar la
transferencia de datos desde el telefono celular hacia una computadora de escritorio que actua como
servidor de aplicacion a traves de Internet.
4.2.1 Mecanismo de handover
El mecanismo para efectuar el handover forma parte de la aplicacion que se ejecuta en el telefono
celular y se invoca bajo dos circunstancias: cuando se detecta la perdida de la senal de la red que
se esta utilizando actualmente, o cuando se encuentra que hay disponible una mejor red de acuerdo
a la polıtica de seleccion. El algoritmo que se utiliza en el proceso de busqueda de la mejor red de
acceso a Internet se muestra mas claramente con el diagrama de la Figura 4.33. La plataforma de
handover desarrollada considera 3 escenarios en los que se puede presentar un cambio de red:
Cambio de red GPRS a WLAN: Cuando el telefono celular esta accediendo a Internet por
medio de la red GPRS, e ingresa al area de cobertura de una red WLAN en la cual el telefono
esta registrado como usuario, como se muestra en la Figura 4.30, se puede presentar un cambio de
red de GPRS a WLAN. Este cambio de red no se da inmediatamente despues de que la red WLAN se
detecta, para asegurar que la conexion sea estable, el cambio se da cuando la potencia de la senal de
4. Comunicaciones 67
GPRS
Red inalámbricaRed GSM
Teléfono celular
Figura 4.30: Cambio de red de GPRS a WLAN
la red WLAN alcanza un valor mınimo - 75 dBm, este valor se determino por medio de pruebas que
se realizaron. En estas pruebas se encontro experimentalmente que el valor mınimo de potencia de
senal necesario para que el telefono celular se conecte a una red WLAN es de -85 dBm, sin embargo
con valores de potencia de senal menores a -80 dBm se presentan variaciones abruptas en la potencia
de la senal, lo que ocasiona inestabilidad en la conexion. Con un valor de potencia de senal mayor a
-75 dBm se encontro que la conexion es mucho mas estable.
GPRSRed inalámbricaRed GSM
Teléfono celular
Figura 4.31: Cambio de red de WLAN a GPRS
Cambio de red WLAN a GPRS: Las redes WLAN tiene una cobertura que se limita a unos
cuantos metros del punto de acceso, cuando el telefono celular sale del area de cobertura de una red
68 4.2. Handover vertical GPRS/WLAN
WLAN a la que estaba conectado y no existe otra red WLAN disponible, el cambio de red de acceso
a Internet se da hacia la red GPRS, si hay cobertura de la red celular. La Figura 4.31 muestra mas
claramente este escenario de cambio de red. Como se explico en el escenario anterior, la potencia de
senal mınima para establecer una conexion es de -75 dBm, cuando la potencia de la senal cae por
abajo de este valor se considera que el telefono celular esta fuera del area de cobertura de la red
inalambrica, y se procede a cerrar la conexion para hacer el cambio hacia la red GPRS.
Red inalámbrica 2
Teléfono celular
Red inalámbrica 1
Figura 4.32: Cambio de red de WLAN a WLAN
Cambio de red WLAN a WLAN: En edificios grandes o en instalaciones muy extensas tales
como universidades o aeropuertos es comun que el servicio de Internet inalambrico se proporcione por
medio de varias redes WLAN cuyas coberturas en algunos puntos se traslapan. Cuando se presenta
un escenario como este, el cambio se da de una red WLAN a otra, como se muestra en la Figura 4.32.
Este cambio se puede efectuar bajo dos condiciones: cuando se pierde la senal de la red WLAN que
se esta utilizando actualmente y de la que se esta alejando el telefono celular, o cuando se detecta
que la senal de la red hacia la que se esta moviendo el telefono es mas potente que la senal de la
red que se esta utilizando actualmente.
En el Apendice B en la pagina 123, se describen las principales funciones utilizadas en la
implementacion del mecanismo handover.
4. Comunicaciones 69
WLANdisponible?
SI
NO
SeleccionarGPRS como
red de acceso
Hay másde una red
disp.?
SI
NO
Seleccionar redWLAN de mayor
potencia
GPRSdisponible?
SI
NO
Sin conexión
Regresar redde acceso
seleccionada
Seleccionar redWLAN disponible
Inicio
Figura 4.33: Diagrama de flujo de algoritmo de seleccion de punto de acceso a Internet
4.2.2 Cambio de red durante transferencia de archivos
La transferencia de archivo es una operacion que por lo general toma un cierto tiempo llevarse
a cabo. Por lo tanto es de esperarse que durante esta operacion se presenten interrupciones en la
comunicacion o errores de transmision debido a perdida de bloques de datos. Cuando se trata de
comunicaciones inalambricas estos problemas se acentuan por la naturaleza de las mismas. Por otro
lado, si tomamos en cuenta que el telefono celular usado en esta implementacion tiene disponibles
dos interfaces de comunicacion con las cuales se puede acceder a Internet, el uso de un mecanismo de
handover durante la transferencia de archivos se hace necesario para que el servicio de transferencia
pueda manejar adecuadamente la perdida de senal de la red en uso o la disponibilidad de otra red con
mejores caracterısticas. Si bien es cierto que existen otros servicios dentro del sistema de monitoreo
de signos vitales, el servicio de transferencia de archivos es el unico que merece la integracion del
mecanismo de handover por las razones que se expusieron anteriormente.
El objetivo del modulo del handover vertical es proporcionar el mejor medio de acceso a Internet
durante la transferencia de archivos. Antes de iniciar la transferencia de archivos desde el celular al
70 4.2. Handover vertical GPRS/WLAN
servidor de aplicacion se llama a la funcion de handover para que proporcione la red de acceso mas
apropiada basada en el criterio de seleccion establecido. El modulo de handover es independiente del
protocolo de transferencia, esta colocado en una capa inferior y se encarga de proporcionar la mejor
red de comunicacion disponible. El protocolo de transferencia se encarga de asegurarse que el archivo
de datos se transfiera completo desde el telefono celular hacia el servidor de aplicacion, para hacerlo
se utiliza un mecanismo de recuperacion de errores que se encuentra distribuido entre el telefono
celular y el servidor de aplicacion. El mecanismo de recuperacion de errores es iniciado en el telefono
celular y permite reanudar una transferencia interrumpida a partir del punto de interrupcion. Para
lograr esto, el telefono celular genera un numero consecutivo del bloque que se esta enviando, este
numero se agrega al mensaje que contiene el bloque de datos, el servidor de aplicacion al recibir el
mensaje con el bloque del archivo salva en una variable el numero del bloque recibido, al terminar la
transferencia del archivo el telefono celular pone a ceros esta variable para indicar que el archivo se
recibio correctamente. Para el protocolo de trasferencia un cambio de red de comunicacion es visto
como un caso de error de transmision y por lo tanto cuando esto ocurre entra en funcionamiento
el mecanismo de recuperacion de errores y este a su vez invoca al modulo de handover. Durante la
transferencia de un archivo se pueden presentar varios cambios de red, estos cambios sin embargo
solo se presentan bajo dos circunstancias:
Cambio de red por perdida de senal: Como se muestra en la Figura 4.35 cuando se detecta
un error de transmision debido a la perdida de senal de la red que se esta usando en el telefono
celular el protocolo responde con el mecanismo de recuperacion de errores, este a su vez invoca al
modulo de handover para proporcionar la nueva mejor red de comunicacion. Del lado del telefono
celular la conexion es cerrada y se entra a un estado de espera para sincronizar el telefono celular
con el servidor de aplicacion, una vez que estan sincronizados se abre una conexion con la nueva
mejor red disponible. Cuando el telefono celular establece la sesion de transferencia con el servidor,
verifica si hay alguna transferencia en curso revisando el valor de la variable que almacena el numero
del ultimo bloque enviado, si este es diferente de cero significa que no se completo la transferencia
del archivo y se emite el comando RETRANSMITE ARCHIVO y entra en un estado de espera del
numero consecutivo del ultimo bloque que recibio el servidor. El servidor de aplicacion por su parte
4. Comunicaciones 71
COMANDO_RECIBIDO
Celular Servidor de aplicación
ENVIA_ARCHIVO
. . .
bloque 1
EOF
BLOQUE_RECIBIDO
EOF_RECIBIDO
handover
últ imo bloque recibido n
RETRANSMITE_ARCHIVO
. . .
bloque n +1
BLOQUE_RECIBIDO
Figura 4.34: Intercambio de mensajes durante handover
al detectar el error de comunicacion salva el numero del ultimo bloque recibido, cierra la conexion
y se sincroniza con el telefono celular. Una vez que el servidor esta sincronizado acepta peticiones
de conexion del telefono celular, cuando se recibe la peticion de conexion, el servidor espera para
recibir comandos. El servidor al recibir el comando RETRANSMITE ARCHIVO le envıa al telefono
celular en respuesta el numero del ultimo bloque recibido. El telefono celular al recibir el numero del
ultimo bloque inicia la transferencia del archivo a partir del siguiente bloque. El protocolo realiza
todas estas operaciones mediante una serie de mensajes que intercambian el telefono celular y el
servidor de aplicacion como se muestra en la Figura 4.34.
Cambio de red al encontrar una mejor red disponible: Durante la transferencia de un archivo
el mecanismo de handover verifica periodicamente si existe alguna red que proporcione mejores
caracterısticas que la red que esta usando actualmente el telefono celular. Cuando se detecta una
mejor red de comunicacion el mecanismo de handover suspende la transferencia del archivo. cierra
la conexion actual y abre otra conexion con la nueva mejor red. Al suspender la transferencia del
72 4.3. Servicios de seguridad
Esperanúmero de úl t imo
bloque recibido
EnvíaBloques
Celular
Fin dearchivo
Esperacomandos
RETRANSMITE_ARCHIVO
Envíaúlt imo bloque
recibido
RecibeBloques
EnvíaEOF
EnvíaEOF_RECIBIDO
EOF
Servidor de aplicación
Cierra conexióny sincroniza
Error
EmiteRETRANSMITE_ARCHIVO
número de úl t imobloque recibido
salvaúlt imo bloque
recibido
Error
Espera solicitudde conexión
Cierra conexióny sincroniza
Abrenueva conexión
Handover
Figura 4.35: Proceso de handover durante transferencia de archivo
archivo se produce un error de comunicacion, es de esta forma en la que el protocolo es enterado del
cambio de red. El protocolo responde a este error con el mecanismo de recuperacion de errores que se
explico anteriormente. El error de comunicacion en este caso es producido por el propio mecanismo de
handover al abortar la transferencia. Despues de que se restablece la comunicacion entre el telefono
celular y el servidor de aplicacion la transmision del archivo se reanuda de la misma manera que en
el caso anterior. Este proceso de cambio de red ocurre cuando el telefono celular entra en el area
de cobertura de alguna red inalambrica. En esta implementacion la busqueda de redes disponibles
es un proceso que se repite cada 5 segundos, pero este tiempo puede ser configurado con un valor
diferente.
4.3 Servicios de seguridad
La plataforma de handover vertical fue pensada como una capa colocada entre las interfaces
de comunicacion del telefono celular y las aplicaciones para el usuario final. Debido que muchas
aplicaciones que acceden a Internet intercambian informacion confidencial como datos personales,
4. Comunicaciones 73
Aplicaciones que acceden a Internet
Sistema Operativo
Módulo deHandover
Interfaz GPRS
InterfazWi-Fi
ConfidencialidadAES
IntegridadSHA-1
Figura 4.36: Ubicacion de los servicios de seguridad
numeros de cuenta bancarios, numeros de tarjetas de credito, etc., en el diseno se considero que serıa
conveniente que la plataforma tuviera un modulo que proporcionara servicios de seguridad, el cual
estarıa ubicado en esta misma capa como se muestra en la Figura 4.36. Ademas, como la plataforma
que se desarrollo en este trabajo de tesis se basa en el uso de redes inalambricas, se considero a
este modulo como una parte indispensable de la arquitectura. El modulo de servicios de seguridad
desarrollado presta los servicios de autenticacion, confidencialidad e integridad a las aplicaciones que
se encuentran en la capa superior.
La informacion que se envıa desde el telefono celular hacia el servidor de aplicacion es por un
lado informacion confidencial porque consiste de datos personales y por otro lado es informacion
sensible en el sentido de que es informacion que se utiliza para realizar el diagnostico del paciente.
La corrupcion de esta informacion o su manipulacion mal intencionada podrıa tener consecuencias
graves en la salud del paciente. El modulo de seguridad establece un canal de comunicacion seguro
entre el telefono celular y el servidor de aplicacion para garantizar que esta informacion no sea sujeta
a espionaje o a manipulacion mal intencionada, este canal se establece, primero garantizando la
autenticidad de la informacion procedente del telefono celular, posteriormente cifrando los datos
durante la transferencia de datos entre el celular y el servidor de aplicacion para que no puedan ser
74 4.3. Servicios de seguridad
Servidor de aplicación
YCentro de
distr ibución de llaves
Solicitud de llave de sesión
Solicitud de llave de sesión
Llave de sesión Llave de sesión
Figura 4.37: Distribucion de llaves de sesion y autenticacion
vistos por terceros y por ultimo verificando que los datos hayan llegado al servidor de aplicacion tal
como se enviaron desde el telefono celular.
4.3.1 Autenticacion
Un componente del modulo de servicios de seguridad es el modulo de distribucion de llaves de
sesion. Este modulo se encarga de distribuir entre el cliente y el servidor las llaves de sesion necesarias
para el cifrado de datos, como se muestra en la Figura 4.37. Ademas, el protocolo de gestion de
las llaves de sesion realiza la funcion de autenticacion. Bajo este esquema el servidor de aplicacion
actua como un centro de distribucion de llaves de sesion y al mismo tiempo autentica al telefono
celular cuando este desea establecer una sesion de transferencia. La autenticacion implementada
solo se realiza en un sentido, el servidor de aplicacion autentica al telefono celular pero el telefono
celular no autentica al servidor de aplicacion. La autenticacion se da en un solo sentido debido a que
la aplicacion que se desarrollo para evaluar la plataforma solo transfiere archivos desde el telefono
celular hacia el servidor de aplicacion, no se efectua transferencia de archivos ni hacia el telefono
celular, ni entre dos telefonos celulares que forman parte del sistema. Por lo tanto no se justifica tener
4. Comunicaciones 75
un centro de distribucion de llaves separado del servidor de aplicacion. El proceso de distribucion de
llaves se sesion asume que tanto el cliente como el servidor comparten una llave secreta la cual fue
previamente distribuida de alguna forma. Las llaves de sesion distribuidas son usadas solo por un
tiempo limitado para protegerlas. En esta implementacion el tiempo de vida de una llave de sesion
se fijo en 1 dıa.
ClienteA
ServidorB
(1) Sol ic i tud | | N1
(2) L lave de ses ión c i f radacon l lave maest ra
(3) f (N2) c i f rado conl lave de ses ión
Figura 4.38: Proceso de distribucion de llave de sesion
El proceso para la distribucion de llaves de sesion se hace de acuerdo a como se muestra en la
Figura 4.38. Este proceso se efectua despues que el cliente establece la conexion con el servidor. La
llave de sesion es establecida con la secuencia de pasos que se muestra en el Algoritmo 1.
Algorithm 1 Pasos para establecer llave de sesion.
1. A emite una solicitud a B para una llave de sesion e incluye una palabra unica, N1.
2. B responde con un mensaje que es cifrado usando la llave maestra compartida. La respuestaincluye la llave de sesion seleccionada por B, un identificador de B, el valor f(N1) y otrapalabra unica, N2
3. Usando la nueva llave de sesion, A regresa f(N2) a B.
A desea comunicarse con B para establecer una sesion de transferencia de datos. En el paso 1
A le envıa a B un mensaje con una solicitud para obtener una llave de sesion, el mensaje incluye
76 4.3. Servicios de seguridad
la identificacion de A y una palabra unica N1, este mensaje se envıa sin cifrar. En el paso 2 B
responde a la solicitud con un mensaje cifrado con la llave maestra que A y B comparten, el mensaje
de respuesta contiene : 1) la solicitud original enviada por A, con lo cual A puede verificar que
la respuesta corresponde a la solicitud que hizo, 2) un identificador de B, 3) una funcion de N1,
esta funcion ha sido previamente acordada entre A y B, y permite verificar a A que el mensaje de
respuesta proviene de B ,y 4) una palabra unica N2 generada por B. El proceso de autenticacion se
realiza en el ultimo paso del proceso de distribucion de llaves de sesion de la siguiente manera: en el
paso 3 B recibe como respuesta un mensaje que supuestamente viene de A, como este contiene una
funcion de la palabra unica N2 que B le envio a A y la cual fue previamente acordada por ambos, y
ademas viene cifrado con la llave de sesion que ambos A y B comparten, B confirma que A es quien
efectivamente es el emisor del mensaje.
En esta implementacion, el servidor de aplicacion mantiene un archivo con las llaves privadas
que comparte con cada uno de los clientes (telefono celular), cada cliente mantiene un registro en
el archivo, y cada registro contiene la llave privada, la ultima llave de sesion emitida para ese cliente
y la fecha en que se emitio. Cuando el servidor de aplicacion recibe una solicitud de llave de sesion
por parte de un cliente busca ese cliente en el archivo de llaves privadas, si lo encuentra obtiene su
llave privada, y si existe una llave de sesion almacenada verifica si es valida comparando la fecha del
sistema con la fecha de emision de la llave de sesion. Si la antiguedad de la llave de sesion es mayor
de un dıa o si no hay llave de sesion almacenada, entonces el servidor genera una nueva llave de
sesion y la almacena en el registro del cliente. La llave de sesion obtenida se envıa al cliente. Si el
cliente no se encuentra registrado en el archivo de llaves privadas se envıa un mensaje de respuesta
rechazando la solicitud. La estructura de la llave de sesion es simple, es un numero aleatorio de 16
bytes o 128 bits, la llave no contiene mas informacion que esta. Este numero de 128 bits se genera
a partir de un numero aleatorio de entre 6 y 8 dıgitos, este numero es convertido entonces a una
cadena de caracteres, y a esta cadena se la aplica la funcion hash MD5, el resultado que regresa la
funcion MD5 es siempre un resumen de 16 bytes, y este valor se convierte entonces en la llave de
sesion.
4. Comunicaciones 77
4.3.2 Confidencialidad
La criptografıa es la ciencia de los codigos secretos, la cual habilita la confidencialidad de las
comunicaciones a traves de un canal inseguro. Protege contra entidades no autorizadas previniendo
la alteracion no autorizada de uso. En general, usa un sistema criptografico para transformar un texto
en claro a uno cifrado, usando la mayorıa de las veces una llave. El algoritmo de cifrado utilizado en
este trabajo de tesis es el AES el cual se describe a continuacion.
El algoritmo AES
El algoritmo AES (Advanced Encryption Standard) es el ganador del concurso llevado a cabo en
1997 por el gobierno de los Estados Unidos de America, despues que se encontro que el algoritmo
DES (Data Encryption Standard) era demasiado debil debido al tamano pequeno de su llave. En
Octubre del ano 2000 una version ligeramente modificada del algoritmo Rijndael fue declarada el
nuevo estandar de cifrado [17].
El algoritmo Rijndael, cuyo nombre deriva de los nombres de sus dos inventores, los Belgas, Joan
Daemen y Vincent Rijmem, es un cifrador de bloque, lo cual significa que trabaja en grupos de
bits de longitud fija, los cuales son llamados bloques. El algoritmo toma un bloque de datos de un
cierto tamano, normalmente de 128 bits, y produce un correspondiente bloque de salida del mismo
tamano. La transformacion requiere una segunda entrada, la cual es la llave secreta. Mientras que
AES soporta solo tamanos de bloque de 128 bits y tamanos de llave de 128, 192 y 256 bits, el
algoritmo original Rijndael puede soportar bloques y llaves de longitudes variables de 128, 192 y 256
bits [18].
AES es un cifrador de bloque iterativo con una longitud de bloque de 128 bits y una llave de
longitud variable. Las diferentes transformaciones operan sobre los resultados intermedios, llamados
Estado. El Estado es un arreglo rectangular de bytes y debido a que el tamano del bloque es de 128
bits, o 16 bytes, el arreglo rectangular es de dimension 4 x 4. El numero de columnas del Estado es
el tamano del bloque dividido por 32 y se denota Nb. La llave de cifrado es igualmente representada
como un arreglo rectangular con cuatro filas. El numero de columnas de la llave de cifrado, denotada
Nk, es igual a la longitud de la llave dividida por 32.
78 4.3. Servicios de seguridad
Longitud de Llave Tamano de bloque Numero de rondas(Nk palabras) (Nb palabras) (Nr)
AES-128 4 4 10AES-192 6 4 12AES-256 8 4 14
Tabla 4.2: Combinaciones Llave-Bloque-Ronda
Especificacion del algoritmo
Para el algoritmo AES, la longitud del bloque de entrada, el bloque de salida y el Estado, es de
128 bits. Esto es representado por Nb = 4 el cual refleja el numero de palabras de 32 bits en el
Estado.
Para el algoritmo AES la longitud de la llave de cifrado, K, es 128, 192 o 256 bits. La longitud de
la llave esta representada por Nk = 4, 6 u 8, el cual refleja el numero de palabras de 32 bits en la
llave de cifrado.
Para el algoritmo AES el numero de rondas a ser ejecutadas durante la ejecucion del algoritmo es
dependiente del tamano de la llave. El numero de rondas es representado por Nr, donde Nr = 10
cuando Nk = 4, Nr = 12 cuando Nk = 6, y Nr = 14 cuando Nk = 8.
Las unicas combinaciones Llave-Bloque-Ronda que estan permitidas en el estandar se muestran en
el Cuadro 4.2. Durante cada ronda tanto del cifrador como del descifrador, el algoritmo AES aplica
una ronda de transformacion que esta compuesta de cuatro diferentes transformaciones:
1. Substitucion de bytes usando una tabla de substitucion (S-box)
2. Cambio de filas en el arreglo de Estado
3. Mezcla de los datos dentro de cada columna del arreglo de Estado
4. Adicion de una Llave de Ronda al Estado
Cifrado
Al inicio del cifrado la entrada es copiada al arreglo de Estado. Despues de una adicion inicial de
Llave de Ronda el arreglo de Estado es transformado implementando una ronda de transformacion
4. Comunicaciones 79
Ronda = 1
AddRoundKey
SubBytes
ShiftRows
MixColumns
AddRoundKey
Ronda <= Nr - 1Ronda = Ronda + 1
salida = Estado
Estado = entrada
SubBytes
ShiftRows
AddRoundKey
Últ imaRonda
Inicio
SI
NO
Figura 4.39: Algoritmo de cifrado AES
10, 12, o 14 veces (dependiendo de la longitud de la llave), siendo la ronda final ligeramente diferente
de las Nr − 1 rondas. El estado final es entonces copiado a la salida.
La funcion de transformacion es parametrizada usando una llave de ronda que consiste de un
arreglo unidimensional de palabras de cuatro bytes derivadas a partir de la llave original por medio
de un proceso llamado Calendarizacion de Llave.
El proceso de cifrado se muestra en la Figura 4.39. Las transformaciones individuales SubBytes(),
ShiftRows(), MixColumns(), y AddRoundKey() procesan el Estado, su funcionamiento se describe
mas adelante en esta subseccion. Como se muestra tambien en la Figura 4.39, todas las Nr rondas
son identicas, con excepcion de la ronda final, la cual no incluye la transformacion MixColumns().
La transformacion SubBytes() es una transformacion no lineal de sustitucion de bytes que opera
80 4.3. Servicios de seguridad
independientemente en cada byte del Estado usando una tabla de substitucion (S-Box). En la
transformacion ShiftRows() los bytes en las tres ultimas filas del Estado son cıclicamente movidas
un diferente numero de bytes. La primera fila, r = 0, no es movida. La transformacion MixColumns()
opera en el Estado columna por columna, tratando cada columna como un polinomio de cuatro
terminos. Las columnas son consideradas como polinomios sobre GF(28) y son multiplicadas modulo
x4 + 1 con un polinomio fijo a(x), dado por a(x) = 03x3 + 01x2 + 01x + 02. En la transformacion
AddRoundKey(), una llave de Ronda se suma al Estado por medio de una simple operacion XOR a
nivel bit. Cada llave de Ronda consiste de Nb palabras del calendario de llaves. Estas Nb palabras
son sumadas cada una a las columnas del Estado.
Expansion de Llave
El algoritmo AES toma la Llave de Cifrado, K, y ejecuta una rutina de Expansion de Llave para
generar un calendario de llaves. La expansion de llave genera un total de Nb(Nr + 1) palabras:
el algoritmo requiere un conjunto inicial de Nb palabras, y cada una de las Nr rondas requiere
Nb palabras de datos de la llave. El calendario de llaves resultante consiste de un arreglo lineal de
palabras de 4 bytes, denotado [Wi], donde i esta en el rango de 0 ≤ i < Nb(Nr + 1).
Descifrado
Las transformaciones del cifrado pueden ser invertidas y luego ejecutadas en orden inverso
para producir un descifrado sencillo para el algoritmo AES como ilustra en la Figura
4.40. Las transformaciones individuales usadas en el descifrado, InvShiftRows(), InvSubBytes(),
InvMixColumns(), y AddRoundKey() basicamente efectuan las operaciones inversas que sus
correspondientes transformaciones en el cifrado, y en el caso de la transformacion AddRoundKey()
la operacion es la misma pero la llave de cifrado se aplica en orden inverso. Se puede obtener
informacion mas detallada sobre el algoritmo AES en [18].
El servicio de confidencialidad se implementa en ambos extremos del canal del comunicacion. Sin
embargo, en el caso especıfico de este trabajo de tesis, los datos solo fluyen desde al cliente hacia
el servidor pero no viceversa. Por lo tanto el cliente cifra los datos por bloque antes de enviarlos al
servidor y el servidor los descifra despues de recibirlos para restaurarlos a su condicion original.
El protocolo de transferencia de archivos divide el archivo de datos en bloques para ser enviado
4. Comunicaciones 81
Ronda = Nr - 1
AddRoundKey
InvShiftRows
AddRoundKey
Ronda = 1Ronda = Ronda - 1
salida = Estado
Estado = entrada
InvShiftRows
AddRoundKey
Últ imaRonda
Inicio
InvSubBytes
InvMixColumns
InvSubBytes
SI
NO
Figura 4.40: Algoritmo de descifrado AES
desde el telefono celular hacia el servidor de aplicacion. En esta implementacion se utilizaron diferentes
tamanos de bloque, los cuales van desde los 256 bytes hasta 4 Kb, sin embargo el algoritmo de cifrado
AES solo puede cifrar bloques de exactamente 16 bytes. Cuando el tamano del bloque de datos a
cifrar es mayor de 16 bytes no es posible cifrarlo en una sola operacion. En este caso el ciframiento
se hace por partes como se muestra en la Figura 4.41. Este es un proceso iterativo en donde se
toman los primeros 16 bytes y se cifran, y el resultado se almacena en un buffer, luego se prosigue
con los siguientes 16 bytes, y el resultado se agrega a los bytes previamente cifrados, y se continua
ası hasta que se cifran los ultimos 16 bytes de bloque. El resultado de este proceso es un bloque de
datos cifrado que tiene un tamano mayor a 16 bytes. Como los tamanos de bloque se seleccionaron
de manera que fueran multiplos de 16 bytes, no se tiene ningun problema con fragmentos de bloque
82 4.3. Servicios de seguridad
Fragmento de 16 bytes 1
Fragmento de 16 bytes 2
Fragmento de 16 bytes 3
Fragmento de 16 bytes n
Bloque de datosoriginal
CifradorAES
Fragmento de 16 bytes 1
Fragmento de 16 bytes 2
Fragmento de 16 bytes 3
Fragmento de 16 bytes n
Bloque de datoscifrado
Figura 4.41: Cifrado de un bloque de datos
cuyo tamano sea menor a 16 bytes, excepto con el ultimo bloque de datos del archivo. En este caso,
como el algoritmo de cifrado no acepta menos de 16 bytes, los bytes faltantes se completan con
caracteres de relleno. Una vez que el bloque de datos ha sido cifrado el protocolo de trasferencia lo
envıa hacia el servidor de aplicacion. En el servidor de aplicacion se efectua una operacion similar. Los
bloques de datos provenientes del telefono celular viene cifrados y hay que descifrarlos con la llave
correspondiente. El bloque de datos cifrado se descifra en fragmentos de 16 bytes, los fragmentos
descifrados se van uniendo para formar el bloque de datos original. Cuando se trata del ultimo
bloque de datos del archivo se retiran los caracteres de relleno que fueron agregados despues de
haber descifrado ese fragmento.
En el Apendice B en la pagina 123, se describe la implementacion de las funciones utilizadas
para el cifrado y descifrado de datos.
4.3.3 Integridad
La integridad de la informacion intercambiada entre el cliente y el servidor se verifica por medio
de una funcion hash. El servicio de integridad se proporciona utilizando la funcion hash SHA-1. La
funcion SHA-1 genera un resumen o digesto de 20 bytes o 160 bits de longitud. Esta funcion hash
fue seleccionada porque proporciona un nivel de seguridad adecuado, su funcionamiento se describe
a continuacion.
La funcion SHA-1
SHA-1 es un algoritmo iterativo, esta funcion puede procesar un mensaje para producir una
4. Comunicaciones 83
CifradoAES
SHA1Transferenciade archivo
Confidencialidad Integridad
Resumen
Envíaresumen
a servidor
Archivo
Figura 4.42: Servicio de integridad en telefono celular
representacion condensada llamada resumen del mensaje. Este algoritmo permite determinar la
integridad de un mensaje: cualquier cambio en el mensaje resultara con una muy alta probabilidad
en un resumen de mensaje diferente.
Algoritmo Tamano de Tamano de Tamano de Tamano de Seguridadmensaje bloque palabra resumen
(bits) (bits) (bits) (bits) (bits)SHA-1 <264 512 32 160 80SHA-256 <264 512 32 256 128SHA-384 <2128 1024 64 384 192SHA-512 <2128 1024 64 512 256
Tabla 4.3: Propiedades de los algoritmos de hash seguro
El algoritmo puede ser descrito en dos etapas: preprocesamiento y calculo del hash. El
preprocesamiento involucra el relleno de un mensaje, el analisis del mensaje rellenado en bloques
de m bits y el establecimiento de valores de inicializacion que se utilizaran en el calculo del hash. El
calculo del hash genera un calendario de mensaje a partir del mensaje rellenado y usa ese calendario,
junto con funciones, constantes, y operaciones de palabra para generar iterativamente una serie de
valores hash. El valor hash final generado por el calculo del hash se usa para determinar el resumen
del mensaje.
84 4.3. Servicios de seguridad
El algoritmo SHA-1 se distingue de los otros algoritmos de la familia SHA, SHA-256, SHA-
384,SHA-512 en el numero de bits de seguridad que proporciona, lo cual esta relacionado
directamente con la longitud del resumen del mensaje. Ademas los cuatro algoritmos difieren en
cuanto al tamano de los bloques y tamanos de palabra que son usados durante el calculo del hash.
El Cuadro 4.3 presenta las propiedades basicas de los cuatro algoritmos de hash seguro.
Preprocesamiento
El preprocesamiento debera tomar lugar antes que inicie el calculo del hash. Este preprocesamiento
consiste de tres pasos: rellenado del mensaje, M , analisis del mensaje rellenado en bloques de mensaje,
y el establecimiento del valor inicial del hash, H(0). El mensaje, M , debe ser rellenado antes de
comenzar el calculo del hash. El proposito de este relleno es garantizar que el mensaje rellenado es
un multiplo de 512 bits. Despues que el mensaje ha sido rellenado debe ser analizado en N bloques de
512 bits, M (1), M (2), . . . , M (N). Dado que los 512 bits del bloque de entrada pueden ser expresados
como dieciseis palabras de 32 bits, los primeros 32 bits del bloque de mensaje i son denotados M(i)0 ,
los siguientes 32 bits son M(i)1 , y ası sucesivamente hasta M
(i)15 . Despues del analisis del mensaje se
establece el valor inicial del hash, H(0), este valor inicial consiste de las siguientes 5 palabras de 32
bits, en hexadecimal:
H(0)0 = 67452301
H(0)1 = efcdab89
H(0)2 = 98badcfe
H(0)3 = 10325476
H(0)4 = c3d2e1f0
Calculo del hash
El algoritmo SHA-1 puede ser usado para procesar un mensaje, M , de l bits de longitud, donde
0 ≤ l < 264. El algoritmo usa 1) un calendario de mensaje de ochenta palabras de 32 bits, 2) cinco
variables de trabajo de 32 bits cada una, y 3) un valor hash de cinco palabras de 32 bits. El resultado
final de SHA-1 es un resumen de mensaje de 160 bits. Las palabras del calendario de mensajes son
4. Comunicaciones 85
i < = N
Prepara el calendario de mensajes
Inicializa variablesde trabajo
t < = 7 9
Calcula funcioneslógicas
Calcula valoreshash intermedios
i = 1
t = 0
t = t + 1
i = i + 1
SI
SI
NO
NO
inicio
Fin
Figura 4.43: Proceso de calculo de SHA-1
etiquetadas W0, W1, . . . , W79. Las cinco variables de trabajo son etiquetadas a, b, c, d, y e.
Despues que se completo el preprocesamiento, cada bloque de mensaje, M (1), M (2), . . . , M (N),
es procesado en orden como se ilustra en la Figura 4.43. Despues de repetir los pasos 1 al 4 un total
de N veces, el resumen de mensaje resultante de 160 bits M , se obtiene concatenando las 5 palabras
de 32 bits que contiene los valores hash finales
H(N)0 ‖H
(N)1 ‖H
(N)2 ‖H
(N)3 ‖H
(N)4
El servicio de integridad se utiliza en este trabajo de tesis para garantizar que el archivo de datos
con los signos vitales del paciente no haya sido modificado durante la transferencia que se hace desde
el telefono celular al servidor de aplicacion. Como se muestra en la Figura 4.42, del lado del telefono
celular despues de que el archivo de datos fue cifrado y transferido hacia el servidor de aplicacion, el
servicio de integridad es implementado calculando la funcion hash SHA-1 al archivo de datos original,
86 4.4. Resumen
descifradoAES
SHA1
Transferenciade archivo
Confidencialidad
Integridad
Resumen recibidoRecibe
resumen
Resumen calculado
Compararesumenes
Archivo
Figura 4.44: Servicio de integridad en servidor de aplicacion
el resumen que genera la funcion SHA-1 se envıa despues al servidor de aplicacion. En el servidor
de aplicacion, como se muestra en la Figura 4.44, el servicio de integridad se implementa despues
de que se recibio el archivo y su correspondiente resumen desde el telefono celular, el archivo de
datos es primero descifrado y posteriormente se le calcula la funcion SHA-1, el resumen calculado
se compara entonces con el resumen que se recibio, si ambos resumenes son iguales significa que
el archivo se recibio ıntegro y se envıa un reconocimiento al telefono celular, si los resumenes no
coinciden significa que el archivo se corrompio durante la transferencia, el servidor de aplicacion en
este caso no regresa el reconocimiento y el telefono celular entonces reenvıa el archivo de datos.
4.4 Resumen
En este capıtulo se presentaron los diferentes procesos de comunicacion de datos que forman
parte de la arquitectura de la plataforma de handover vertical. Se presentaron los dos protocolos
de comunicacion desarrollados, el primero para realizar la transferencia de archivos sobre un
enlace Bluetooh utilizando como protocolo de transporte a RFCOMM, el segundo para realizar
la transferencia de archivos a traves de Internet, a este protocolo se le incorporo un mecanismo
de recuperacion de errores el cual permite reanudar una transmision en el punto en el que
4. Comunicaciones 87
fue interrumpida. Se describio tambien el mecanismo de handover que permite hacer el cambio
automatico entre redes GPRS y WLAN, como una solucion a los problemas de costo y ancho de
banda de una conexion a Internet en un telefono celular. Se presento la implementacion de los servicios
de seguridad. Se describio el esquema de distribucion de llaves de sesion y el servicio de autenticacion
incorporado a este. Se describio el algoritmo de ciframiento AES el cual se utilizo para garantizar
la confidencialidad durante la transferencia de datos. Se describio la funcion de hash seguro SHA-1,
utilizada para verificar la integridad de los datos despues de la transmision. En el siguiente Capıtulo
se describiran las pruebas funcionales y de desempeno, y se mostraran los resultados obtenidos en
dichas pruebas.
5Resultados
Con el fin de demostrar la funcionalidad de la arquitectura propuesta y de los esquemas de
comunicacion descritos en el Capıtulo 4, se presenta como caso de estudio o caso practico una
aplicacion del area de la salud denominada Sistema de Monitoreo de Signos Vitales. Este sistema
esta formado por tres componentes principales como se muestra en la Figura 3.1: un dispositivo
sensor, un telefono celular y un servidor de aplicacion. El Sistema Monitor de Signos Vitales captura
signos vitales por medio de sensores colocados en el cuerpo del paciente, esta informacion es enviada a
un telefono celular por medio de un enlace Bluetooth. El telefono celular a su vez envıa la informacion
por medio de Internet a un servidor de aplicacion ubicado en un centro medico. En este capıtulo se
presentan los resultados de la pruebas de funcionalidad y de desempeno de la aplicacion practica de
la arquitectura propuesta.
5.1 Funcionalidad de la plataforma
Para probar la funcionalidad de la arquitectura propuesta se utilizo el siguiente escenario: La
aplicacion cliente se instalo en un telefono celular Nokia N91, este telefono celular cuenta con
89
90 5.1. Funcionalidad de la plataforma
interfaces de comunicacion Bluetooth, GPRS y 802.11 (Wi-Fi), la aplicacion servidora se instalo en
una computadora de escritorio con sistema operativo Linux. Se tuvieron disponibles dos redes
inalambricas las cuales fueron registradas como puntos de acceso a Internet en la configuracion
del telefono celular. La autenticacion para acceder a las redes inalambricas se hizo por medio de
filtrado de direccion MAC.
Para verificar que se efectuaran correctamente los tres cambios de red posibles, se realizaron las
siguientes pruebas:
1. Cambio de red WLAN a red GPRS
2. Cambio de GPRS a red WLAN
3. Cambio de red WLAN a otra red WLAN
En cada una de las pruebas se envio un archivo desde el telefono celular hacia el servidor de
aplicacion, y se verifico que el archivo transferido se recibiera decodificado correctamente e ıntegro.
Cambio de red WLAN a red GPRS
Para efectuar la prueba de funcionalidad y verificar el cambio de red de WLAN a GPRS, se
coloco el telefono celular a una distancia aproximada de 2 metros del punto de acceso de una red
WLAN a la que se denomino A, la potencia de la senal de la red A a esta distancia vario entre -60 y
-65 dBm, el segundo punto de acceso se ubico a una distancia aproximada de 25 metros, las lecturas
de la potencia de la senal de la segunda red WLAN a la que se denomino B siempre fueron menores
a -80 dBm. Se inicio la transferencia de un archivo de imagen con formato jpeg de un tamano de
199 KB, el punto de acceso seleccionado automaticamente por la aplicacion en el telefono celular
fue la red WLAN A. Una vez que se establecio la comunicacion con el servidor de aplicacion, se
efectuo la autenticacion y se inicio la transmision. Despues de unos segundos el telefono celular fue
movido alejandose de ambas redes WLAN como se muestra en la Figura 5.1, al perderse la senal
de la red inalambrica A la transferencia se interrumpio despues de haber transferido en promedio
aproximadamente 4 KB. Esta prueba se efectuo 10 veces, en cada corrida el nuevo punto de acceso
seleccionado automaticamente fue la red GPRS, se reinicio la transmision del archivo en el punto en
5. Resultados 91
el que se habıa interrumpido y se continuo la transferencia hasta que se completo el envıo del archivo
de imagen. Tambien se verifico en cada corrida que el archivo de imagen hubiera sido recibido en el
servidor de aplicacion debidamente descifrado e ıntegro.
Cambio de red GPRS a red WLAN
Para verificar el cambio de red GPRS a WLAN, el telefono se ubico en una posicion entre los
puntos de acceso de las redes WLAN A y B de tal forma que estuviera fuera de la cobertura de ambas
redes WLAN. Al iniciar la aplicacion en el telefono celular, el punto de acceso seleccionado fue la red
GPRS, la autenticacion se efectuo correctamente distribuyendose la llave de sesion correspondiente.
Despues de haberse iniciado la transferencia del archivo, el telefono celular fue movido hacia el punto
de acceso de la red WLAN A. Cuando la aplicacion en el telefono celular detecto que la red WLAN
A tenıa la potencia de senal suficiente (mayor a -75 dBm) se interrumpio la transferencia que se
estaba efectuando a traves de la red GPRS y se reinicio en el punto en el que se habıa quedado
pero ahora a traves de la red WLAN A. Esta prueba se realizo 10 veces, en ella, el cambio de red
tomo en promedio aproximadamente 3 segundos. Al haberse concluido el cambio de red la velocidad
de transferencia aumento considerablemente. Al terminar la transferencia del archivo en cada una de
las pruebas se verifico que el archivo estuviera en el servidor de aplicacion y que estuviera decodificado
correctamente e ıntegro.
Cambio de red WLAN a otra red WLAN
La tercera prueba fue para verificar el cambio de una red WLAN a otra, para efectuar esta
prueba se coloco al telefono celular cerca del punto de acceso de la red WLAN A. Al iniciar la
aplicacion en el telefono celular, el punto de acceso seleccionado fue la red WLAN A, la autenticacion
se efectuo correctamente distribuyendose la llave de sesion correspondiente. Una vez iniciada la
transferencia del archivo, se desplazo el telefono hacia el punto de acceso de la red WLAN B, cuando
la aplicacion en el telefono celular detecto que la red WLAN B tenıa la potencia de senal suficiente,
se interrumpio la transferencia que se estaba efectuando a traves de la red WLAN A y se reinicio en
el punto en el que se habıa quedado pero ahora a traves de la red WLAN B, el cambio de red
tomo aproximadamente 1 segundo. Al terminar la transferencia del archivo se verifico que el archivo
estuviera en el servidor de aplicacion y que estuviera decodificado correctamente e ıntegro. Al igual
92 5.2. Desempeno de la plataforma
Red Wlan A
Red Wlan BNokia N91
2 m
25 m
Figura 5.1: Escenario para pruebas de funcionalidad
que en las pruebas anteriores esta prueba se repitio 10 veces obteniendo el mismo comportamiento
en cada ejecucion.
5.2 Desempeno de la plataforma
Para evaluar el desempeno de la plataforma de handover vertical se efectuaron 15 pruebas las
cuales se clasifican de acuerdo a las siguientes categorıas:
Tiempo de handover
Tamano optimo de bloque de TCP
Tiempo de transferencia de archivo
Tiempos de cifrado/descifrado
Consumo de energıa
5. Resultados 93
A continuacion se describe como se realizo cada una de las pruebas y se muestran los resultados
que se obtuvieron.
5
10
15
20
25
30
35
40
45
0 20 40 60 80 100
Tie
mpo
en
seg.
Pruebas efectuadas
Tiempos de cambio de red WLAN a GPRS en Nokia N91
Tiempo de handover
Figura 5.2: Tiempo de handover WLAN/GPRS
5.2.1 Tiempo de handover
El objetivo de esta serie de pruebas es determinar el tiempo que trascurre al efectuar los diferentes
cambios de red que se pueden presentar durante la transferencia de archivos. Las pruebas que se
realizaron dentro de esta categorıa son:
Tiempo de handover WLAN/GPRS
Tiempo de handover GPRS/WLAN
Tiempo de handover WLAN/WLAN
94 5.2. Desempeno de la plataforma
1
2
3
4
5
6
7
8
9
10
0 20 40 60 80 100
Tie
mpo
en
seg.
Pruebas efectuadas
Tiempos de cambio de red GPRS a WLAN en Nokia N91
Tiempo de handover
Figura 5.3: Tiempo de handover GPRS/WLAN
Tiempo de handover WLAN/GPRS
Las pruebas para determinar el tiempo de cambio de una red WLAN a la red GPRS se realizaron
colocando el telefono celular a una distancia aproximada de dos metros del punto de acceso. Las
pruebas se hicieron con la baterıa del telefono celular completamente cargada. Esta prueba se
realizo de la siguiente manera:
1. Se creo una conexion de TCP con un servidor utilizando el punto de acceso WLAN en el puerto
18000
2. Se cerro la conexion WLAN
3. Se creo una conexion de TCP con un servidor utilizando el punto de acceso GPRS en el puerto
18001
4. Se midio el tiempo que transcurrio desde antes de cerrar la conexion WLAN hasta despues de
5. Resultados 95
que se creo la conexion GPRS
5. Se cerro la conexion GPRS
Este proceso se repitio 100 veces. El tiempo promedio de cambio de red de WLAN a GPRS en las
100 pruebas realizadas fue de 18.689 seg. y la desviacion estandar fue de 9.1002 seg. Los resultados
de los 100 cambios de red se muestran en la Figura 5.2
0.6
0.8
1
1.2
1.4
1.6
1.8
2
0 20 40 60 80 100
Tie
mpo
en
seg.
Pruebas efectuadas
Tiempos de cambio de red WLAN a WLAN en Nokia N91
Tiempo de handover
Figura 5.4: Tiempo de handover WLAN/WLAN
Tiempo de handover GPRS/WLAN
Las pruebas para determinar el tiempo de cambio entre las redes GPRS y WLAN se realizaron
colocando el telefono celular a una distancia aproximada de 2 metros del punto de acceso. Las pruebas
se hicieron con la baterıa del telefono celular completamente cargada. Esta prueba se realizo de la
siguiente manera:
1. Se creo una conexion de TCP con un servidor utilizando el punto de acceso GPRS en el puerto
18000
96 5.2. Desempeno de la plataforma
2. Se cerro la conexion GPRS
3. Se creo una conexion de TCP con un servidor utilizando el punto de acceso WLAN en el puerto
18001
4. Se midio el tiempo que transcurrio desde antes de cerrar la conexion GPRS hasta despues de
que se creo la conexion WLAN
5. Se cerro la conexion WLAN
Este proceso se repitio 100 veces. En las 100 pruebas que se realizaron el tiempo promedio de
cambio de red de GPRS a WLAN fue de 3.7573 seg. y la desviacion estandar fue de 0.97015 seg.
Las resultados de los 100 cambios de red se muestran en la Figura 5.3.
Tiempo de handover WLAN/WLAN
Para efectuar esta prueba se dispuso de dos redes WLAN cuyos puntos de acceso se encontraban
ubicados a una distancia aproximada de 25 m. uno del otro, y que estaban ubicados de tal manera
que en el punto intermedio entre los dos puntos de acceso ambas redes tenıan cobertura. De esta
manera se evito que el cambio red se hiciera a la red GPRS. El telefono celular se coloco en este
punto intermedio. La prueba se realizo de la siguiente manera:
1. Se creo una conexion de TCP con un servidor utilizando el punto de acceso WLAN en el puerto
18000
2. Se cerro la conexion WLAN
3. Se creo una conexion de TCP con un servidor utilizando el punto de acceso WLAN en el puerto
18001
4. Se midio el tiempo que transcurrio desde antes de cerrar conexion WLAN hasta despues de
que se creo la otra conexion WLAN
5. Se cerro la segunda conexion WLAN
5. Resultados 97
Este proceso se repitio 100 veces. El tiempo promedio de cambio de red de WLAN a WLAN
en las 100 pruebas realizadas fue de 1.2505 seg. y la desviacion estandar fue de 0.13713 seg. Los
resultados de los 100 cambios de red se muestran en la Figura 5.4
5
10
15
20
25
30
35
1 2 3 4 5 6
Tie
mpo
en
seg.
Tamaño de bloque de TCP en KB
Tamaño óptimo de bloque para transferencia por WLAN en Nokia N91
Tiempo de transferencia
Figura 5.5: Tamano optimo de bloque de TCP usando red WLAN
5.2.2 Tamano optimo de bloque de TCP usando red WLAN
El objetivo de esta prueba fue determinar cual serıa el tamano del bloque de datos para ser usado
en las operaciones con sockets de TCP que proporcionarıa el menor tiempo de transferencia de datos
entre el telefono celular y el servidor de aplicacion usando la red WLAN. Para efectuar esta prueba se
realizo la transferencia de un archivo de texto de 1 KB de longitud, este archivo se transfirio desde el
telefono celular hacia el servidor de aplicacion. Se utilizaron bloques de diferente tamano buscando
reducir el tiempo de transferencia, el tamano de los bloques vario de 256 bytes a 6 KB. Cada tamano
de bloque se probo 20 veces, la prueba se detuvo cuando el aumento en el tamano del bloque de
98 5.2. Desempeno de la plataforma
datos de TCP ya no trajo una reduccion en el tiempo de transferencia. Los tiempos promedio de
transferencia para cada tamano de bloque se muestran en la Figura 5.5. Se encontro que el tamano
optimo de bloque es de 4 KB, con bloques de tamano mayor se obtiene una pequena reduccion en
el tiempo de transferencia pero tambien aumenta el numero de errores de transmision.
200
300
400
500
600
700
800
900
1000
20 40 60 80 100 120 140
Tie
mpo
en
seg.
Tamaño de bloque de TCP en bytes
Tamaño óptimo de bloque para transferencia por GPRS en Nokia N91
Tiempo de transferencia
Figura 5.6: Tamano optimo de bloque de TCP usando red GPRS
5.2.3 Tamano optimo de bloque de TCP usando red GPRS
Esta prueba es similar a la anterior, su objetivo fue encontrar el tamano de bloque de datos que
usado en las operaciones con sockets de TCP proporcione el menor tiempo de transferencia cuando
se use la red GPRS. Como se menciono en el Capıtulo 2, la tasa de transferencia maxima de GPRS
es de solo 150 KBps y el usuario es facturado por KB, el costo actual es de aproximadamente 13
centavos. Por estas dos razones para efectuar esta prueba se realizo la transferencia de un archivo
de texto de 64 KB de longitud, este archivo se transfirio desde el telefono celular hacia el servidor de
5. Resultados 99
aplicacion. Se utilizaron bloques de diferente tamano buscando reducir el tiempo de transferencia, el
tamano de los bloques vario desde 32 bytes a 128 bytes en incrementos de 16 bytes. Cada tamano
de bloque se probo 5 veces, la prueba se detuvo cuando el aumento en el tamano del bloque de
datos de TCP ya no trajo una reduccion en el tiempo de transferencia. Los tiempos promedio de
transferencia para cada tamano de bloque se muestran en la Figura 5.6. Se encontro que el tamano
optimo de bloque es de 96 bytes, sin embargo, se encontro que la tasa de transferencia de la red
GPRS varıa durante el dıa de acuerdo a la carga de la red GSM. Esto ocasiona que cuando la red
celular esta saturada se incrementa el numero de errores de transmision con este tamano de bloque.
Por esta razon se utilizo el bloque de 64 bytes que es el que proporciona la mejor velocidad de
transmision a diferentes horas del dıa.
20
40
60
80
100
120
0 1 2 3 4 5 6
Tie
mpo
en
seg.
Tamaño de archivo en MB
Comparativo de tiempos de cifrado/descifrado en Nokia N91
Tiempo de cifradoTiempo de descifrado
Figura 5.7: Grafica comparativa de tiempos de cifrado/descifrado
100 5.2. Desempeno de la plataforma
5.2.4 Tiempos de cifrado/descifrado
Para efectuar esta prueba se dispuso de 8 archivos cuyos tamanos fueron desde los 128 KB
hasta los 5 MB. Cada uno de estos archivos se cifro 20 veces en el telefono celular para obtener el
tiempo promedio de cifrado. Para efectuar la prueba de tiempo de descifrado estos 8 archivos fueron
previamente cifrados y copiados al telefono celular, ahı fueron descifrados 20 veces para obtener el
tiempo promedio de descifrado. En las pruebas de cifrado realizadas se encontro que la tasa de cifrado
promedio es de 47.89 KB/seg con una desviacion estandar de 1.4 KB/seg, lo cual demuestra que la
tasa de cifrado se mantiene mas o menos constante independientemente del tamano del archivo que
se esta cifrando. En las pruebas de descifrado se obtuvieron resultados similares, la tasa de descifrado
promedio fue de 50.00 KB/seg con una desviacion estandar de 2.29 KB/seg, se observo que la tasa
de descifrado es ligeramente mayor para los archivos cuyo tamano es mayor de 2 MB. En la Figura 5.7
se muestran los resultados de ambas pruebas, se observa que el tiempo de descifrado es ligeramente
menor que el tiempo de cifrado para cada uno de los archivos.
128 KB 256 KB 512 KB 1 MB 2 MB 3 MB 4 MB 5 MBTiempo promediode transferencia 1.08 2.00 2.93 4.48 8.27 11.97 15.75 19.94en segundos
Tasa real detransferencia 118.04 128.00 174.67 228.83 247.68 256.06 260.06 256.76en KB/s
Tabla 5.1: Tiempos de transferencia usando red WLAN
5.2.5 Tiempo de transferencia de archivos usando red WLAN
Los objetivos de esta prueba fueron:
Determinar el tiempo promedio de transferencia para archivos de diferentes tamanos cuando
se usa la red inalambrica.
5. Resultados 101
Determinar la tasa de transferencia real.
Determinar el costo en tiempo al agregar los servicios de seguridad a la transferencia de archivo.
5
10
15
20
25
0 1 2 3 4 5 6
Tie
mpo
en
seg.
Tamaño de archivo en MB
Tiempos de transferencia de archivo sin servicios de seguridad usando WLAN
Tiempo de transferencia
Figura 5.8: Tiempos de transferencia usando red WLAN
Para determinar el tiempo de transferencia y la tasa de transferencia se dispuso de 8 archivos cuyos
tamanos fueron desde los 128 KB hasta los 5 MB. Cada uno de estos archivos se envio 20 veces desde
el telefono celular hacia el servidor de aplicacion utilizando la red inalambrica y se midio el tiempo
que tomo enviar cada archivo. El tamano de bloque que se utilizo en la transferencia de archivo fue
de 4 KB, este fue el tamano optimo de bloque que se encontro para la red WLAN en las pruebas
que se describieron anteriormente. En la medicion del tiempo de transferencia no se consideraron
las operaciones de autenticacion, cifrado y calculo de la funcion hash. Con los tiempos medidos se
calcularon el tiempo promedio de transferencia y la tasa de transferencia real para cada tamano de
archivo. La tasa de transferencia real se calculo dividiendo el tamano del archivo en KB entre el
tiempo promedio de transferencia de ese archivo. Los resultados obtenidos se muestran en la Tabla
102 5.2. Desempeno de la plataforma
5.1, se observa que la tasa de transferencia para archivos menores de 1 KB se encuentra alrededor de
los 128 KB/s y para archivos iguales o mayores de 1 KB se encuentra alrededor de los 256 KB/s. El
comportamiento de la tasa de transferencia es casi lineal para tamanos de archivo iguales o mayores
a 1 MB, esto se puede observar mejor en la Figura 5.8.
4 KB 8 KB 16 KB 32 KB 64 KB 128 KB 256 KBTiempo promediode transferencia 20.74 44.41 83.77 159.58 287.80 519.42 905.65en segundos
Tasa real detransferencia 0.19 0.18 0.19 0.20 0.22 0.24 0.28en KB/s
Tabla 5.2: Tiempos de transferencia usando red GPRS
Para determinar el costo en tiempo que los servicios de seguridad agregan a la transferencia de
archivo, se realizo el mismo procedimiento que en la prueba anterior pero las mediciones se hicieron
considerando el tiempo que toma efectuar las operaciones de autenticacion, cifrado del archivo y
calculo de la funcion hash. Los resultados obtenidos en esta prueba se muestran en la Tabla 5.3.
Se observa que los servicios de seguridad imponen una carga de procesamiento considerable, en
particular el cifrado de datos como se mostro en la Figura 5.7, esta carga extra tiene un costo en el
tiempo de transferencia. El impacto de los servicios de seguridad en el tiempo de transferencia del
archivo se observa claramente en la Figura 5.9, en donde se muestra un comparativo de los tiempos
de transferencia con y sin servicios de seguridad.
128 KB 256 KB 512 KB 1 MB 2 MB 3 MB 4 MB 5 MBTiempo promediode transferencia 1.08 s 2.00 s 2.93 s 4.48 s 8.27 s 11.97 s 15.75 s 19.94 s
Tiempo promediode transferencia 3.83 s 7.30 s 13.62 s 25.70 s 49.89 s 74.66 s 102.04 s 125.61 scon servicios
Costo de serviciosde seguridad en 354.6 % 365.0 % 464.8 % 573.6 % 603.2 % 623.7 % 647.8 % 629.9 %porcentaje
Tabla 5.3: Tiempos de transferencia con servicios de seguridad usando red WLAN
5. Resultados 103
0
20
40
60
80
100
120
0 1 2 3 4 5 6
Tie
mpo
en
seg.
Tamaño de archivo en MB
Comparativo de tiempos de transferencia de archivo con y sin servicios de seguridad usando WLAN
Tiempo de transferencia con serviciosTiempo de transferencia sin servicios
Figura 5.9: Tiempos de transferencia con y sin servicios de seguridad usando WLAN
5.2.6 Tiempo de transferencia de archivos usando red GPRS
Los objetivos de esta prueba al igual que la prueba anterior fueron:
Determinar el tiempo promedio de transferencia para archivos de diferentes tamanos cuando
se usa la red GPRS.
Determinar la tasa de transferencia real.
Determinar el costo en tiempo al agregar los servicios de seguridad a la transferencia de archivo.
Para determinar el tiempo de transferencia y la tasa de transferencia de la red GPRS se dispuso
de 7 archivos cuyos tamanos fueron desde los 4 KB hasta los 256 KB. El tamano de estos archivos
fue menor que en la prueba similar con red WLAN debido a dos razones, la primera es que la tasa
de transferencia maxima de GPRS es de solo 150 KB/s y en pruebas preliminares se observo que la
tasa real es mucho menor, ademas de que con archivos de tamano mayor a 512 KB se presentaban
104 5.2. Desempeno de la plataforma
100
200
300
400
500
600
700
800
900
1000
100 200 300 400 500
Tie
mpo
en
seg.
Tamaño de archivo en KB
Tiempos de transferencia de archivos sin servicios de seguridad usando red GPRS
Tiempo de transferencia
Figura 5.10: Tiempos de transferencia usando red GPRS
errores de transmision que extendıan considerablemente el tiempo de transferencia, la segunda razon
es que el costo por kilobyte transferido harıa que la prueba fuera muy costosa para archivos de mas
de 1 MB. En esta prueba cada uno de estos archivos se envio 10 veces desde el telefono celular
hacia el servidor de aplicacion utilizando la red GPRS y se midio el tiempo que tomo enviar cada
archivo. El tamano de bloque que se utilizo en la transferencia de archivo fue de 64 bytes, este fue
el tamano optimo de bloque que se encontro para la red GPRS en las pruebas que se describieron
anteriormente. En la medicion del tiempo de transferencia no se consideraron las operaciones de
autenticacion, cifrado y calculo de la funcion hash. Con los tiempos medidos se calcularon el tiempo
promedio de transferencia y la tasa de transferencia real para cada tamano de archivo. La tasa de
transferencia real se calculo dividiendo el tamano del archivo en KB entre el tiempo promedio de
transferencia de ese archivo. Los resultados obtenidos se muestran en la Tabla 5.2, se observa que
la tasa de transferencia para todos los tamanos de archivo usados es de alrededor de 0.20 KB/s,
esto es mucho menor que la tasa maxima especificada en GPRS . El comportamiento de la tasa
5. Resultados 105
de transferencia tiende a mejorar ligeramente a medida que el tamano del archivo aumenta, esto se
puede observar mejor en la Figura 5.10.
100
200
300
400
500
600
700
800
900
1000
100 200 300 400 500
Tie
mpo
en
seg.
Tamaño de archivo en KB
Comparativo de tiempos de transferencia de archivo con y sin servicios de seguridad usando GPRS
Tiempo de transferencia con serviciosTiempo de transferencia sin servicios
Figura 5.11: Tiempos de transferencia con y sin servicios de seguridad usando GPRS
Para determinar el costo en tiempo que los servicios de seguridad agregan a la transferencia
de archivo, las mediciones se hicieron considerando el tiempo que toma efectuar las operaciones de
autenticacion, cifrado del archivo y calculo de la funcion hash. Se podrıa pensar que el impacto de
los servicios de seguridad serıa el mismo que el caso del uso de la red WLAN debido a que la carga de
procesamiento es independiente de la red utilizada para hacer la transferencia, sin embargo debido a
que la tasa de transferencia real de GPRS es muy pequena, el impacto de los servicios de seguridad
en el tiempo de transferencia es practicamente nulo, como se muestra en la Tabla 5.4. El impacto
de los servicios de seguridad en el tiempo de transferencia del archivo se observa claramente en la
Figura 5.11, en donde se muestra un comparativo de los tiempos de transferencia con y sin servicios
de seguridad.
106 5.2. Desempeno de la plataforma
4 KB 8 KB 16 KB 32 KB 64 KB 128 KB 256 KBTiempo promediode transferencia 20.74 s 44.41 s 83.77 s 159.58 s 287.80 s 519.42 s 905.65 s
Tiempo promediode transferencia 21.39 s 44.70 s 81.91 s 163.26 s 288.38 s 519.61 s 921.74 scon servicios
Costo de serviciosde seguridad en 1.03 % 1.01 % 0.00a % 1.02 % 1.00 % 1.00 % 1.01 %porcentaje
Tabla 5.4: Tiempos de transferencia con servicios de seguridad usando red GPRS
aEste resultado se obtiene porque las condiciones de la red celular durante las pruebas fueron diferentes.
5.2.7 Consumo de energıa durante cifrado y descifrado de datos
Como se menciono en el Capıtulo 2, la duracion de la baterıa es una de las principales
preocupaciones de los disenadores de aplicaciones para telefonos celulares y en general para
dispositivos moviles, por lo tanto es importante determinar cual es el consumo de energıa de la
aplicacion desarrollada. En las pruebas que se describieron anteriormente se encontro que de los
servicios de seguridad implementados, el cifrado de datos es la operacion que consume mas tiempo
de procesamiento y por lo tanto mas energıa. Por esta razon se selecciono esta operacion para
encontrar cual es el impacto que tiene en el consumo de energıa en el telefono celular.
MB cifrados Nivel de carga de baterıa
100 100 %
200 100 %
381 100 %
480 85 %
570 71 %
586 57 %
776 14 %
Tabla 5.5: Megabytes cifrados con una baterıa con carga completa
Los objetivos de esta prueba fueron:
Determinar el porcentaje de uso de la baterıa por megabyte cifrado.
Determinar el porcentaje de uso de la baterıa por megabyte descifrado.
5. Resultados 107
MB descifrados Nivel de carga de baterıa
100 100 %
200 100 %
237 100 %
355 86 %
468 72 %
584 57 %
589 43 %
749 29 %
Tabla 5.6: Megabytes descifrados con una baterıa con carga completa
Para determinar el porcentaje de uso de la baterıa por megabyte cifrado primero fue necesario
cargar apropiadamente la baterıa, para hacerlo se descargo la baterıa completamente y despues se
realizo una carga completa, esto garantizo que la duracion de la baterıa fuera la maxima. Una vez
que se cargo la baterıa se cifro repetidamente un archivo de texto de 1 MB, realizando esta operacion
hasta que se agoto la baterıa, cada vez que se cifraba el archivo se tomaba una lectura del nivel
actual de la baterıa.
MB transferidos Nivel de carga de baterıa
100 100 %
166 100 %
211 85 %
242 71 %
280 57 %
327 42 %
373 28 %
574 14 %
Tabla 5.7: Megabytes transferidos con una baterıa con carga completa
Los resultados de la prueba se muestran en la Tabla 5.5. Se encontro que se pueden cifrar
aproximadamente 780 MB con una baterıa con carga completa, sin embargo no es posible determinar
con exactitud el porcentaje de baterıa usado por megabyte cifrado, debido a que la funcion que
proporciona el sistema operativo Symbian no tiene la granularidad suficiente para determinar con
exactitud el nivel de carga de la baterıa. Se observo que el comportamiento de la baterıa no es lineal,
a medida que el nivel de carga de la baterıa disminuye los cambios de nivel se dan mas rapidamente,
esto se puede observar claramente en la Figura 5.12, en donde observamos que se pueden cifrar
108 5.2. Desempeno de la plataforma
0
20
40
60
80
100
200 300 400 500 600 700 800
% d
e ca
rga
de b
ater
ía.
Megabytes cifrados
Megabytes de información cifrados con una batería con carga completa en Nokia N91
Consumo de batería al cifrar
Figura 5.12: Megabytes cifrados con una baterıa con carga completa
aproximadamente 500 MB antes de que el nivel de carga de la baterıa caiga de 100 a 86 %, pero
solo podemos cifrar 100 MB antes de que el nivel de carga caiga de 86 a 71 %.
Para determinar el porcentaje de uso de la baterıa por megabyte descifrado se siguio un
procedimiento similar al anterior. Una vez que se cargo la baterıa se descifro repetidamente un
archivo de 1 MB que habıa sido previamente cifrado, realizando esta operacion hasta que se agoto la
baterıa, cada vez que se descifraba el archivo se tomaba una lectura del nivel actual de la baterıa.
Los resultados de la prueba se muestran en la Tabla 5.6. Se encontro que se pueden descifrar
aproximadamente 750 MB con una baterıa con carga completa. Se observo que el comportamiento
de la baterıa no es lineal como se muestra en la Figura 5.13, pero es diferente al comportamiento
que mostro en la prueba de cifrado.
5. Resultados 109
0
20
40
60
80
100
200 300 400 500 600 700 800
% d
e ca
rga
de b
ater
ía.
Megabytes descifrados
Megabytes de información descifrados con una batería con carga completa en Nokia N91
Consumo de batería al descifrar
Figura 5.13: Megabytes descifrados con una baterıa con carga completa
110 5.2. Desempeno de la plataforma
5.2.8 Consumo de energıa durante transferencia usando red WLAN
El objetivo de esta prueba fue determinar el porcentaje de uso de baterıa por megabyte transferido
cuando se usa la red WLAN.
Para determinar el porcentaje de uso de baterıa por megabyte transferido se cargo la baterıa como
se hizo en pruebas anteriores y se envio repetidamente un archivo de 1 MB desde el telefono celular
hacia el servidor de aplicacion. Esta operacion se realizo hasta que se agoto la baterıa, cada vez
que se completaba la transferencia del archivo se tomaba una lectura del nivel actual de la baterıa.
Los resultados de la prueba se muestran en la Tabla 5.7. Se encontro que se pueden transferir
aproximadamente 580 MB con una baterıa con carga completa. Se observo que el comportamiento
de la baterıa no es lineal como se muestra en la Figura 5.14, pero el comportamiento es diferente al
que mostro en la pruebas de consumo de energıa de cifrado y descifrado.
0
20
40
60
80
100
100 200 300 400 500 600
% d
e ca
rga
de b
ater
ía.
Megabytes enviados
Megabytes de información enviados con una batería con carga completa en Nokia N91 usando WLAN
Consumo de batería por MB transferido
Figura 5.14: Megabytes transferidos con una baterıa con carga completa
5. Resultados 111
5.2.9 Consumo de energıa durante transferencia usando red GPRS
El objetivo de esta prueba era determinar el porcentaje de uso de baterıa por megabyte transferido
al usar la red GPRS, sin embargo esta prueba no pudo ser llevada a cabo debido al costo que
implicarıa realizarla. En la prueba anterior se encontro que se podıan enviar aproximadamente 580
MB desde el telefono celular hacia el servidor de aplicacion usando la red WLAN. Con un costo en
pesos de 13 centavos por kilobyte, transferir al menos los mismos 580 MB por la red GPRS costarıa
aproximadamente $ 77,209.60.
5.3 Resumen
Las pruebas de funcionamiento realizadas al sistema de monitoreo de signos vitales demostraron
que la transferencia de archivos entre el telefono celular y el servidor de aplicacion se puede realizar
satisfactoriamente y de manera segura a pesar de los errores de comunicacion y de los cambios de red
que se introdujeron. Los errores de comunicacion fueron manejados adecuadamente por el mecanismo
de recuperacion de errores del protocolo de transferencia por Internet lo que permitio reiniciar la
transferencia en el punto en el que se habıa suspendido. Ademas, cuando se presentaron perdidas de
senal de la red que se estaba utilizando o cuando una mejor red estuvo disponible, el mecanismo de
handover vertical fue capaz de proporcionar una nueva mejor red en un tiempo razonable y sin que
la transferencia de archivos se viera afectada. Es importante mencionar que se verifico que el canal
de comunicacion seguro establecido entre el telefono celular y servidor de aplicacion efectivamente
cifra y descifra correctamente la informacion y la transfiere ıntegra.
Las pruebas de desempeno mostraron que las operaciones de cifrado y descifrado en el
telefono celular representan una sobrecarga significativa en tiempo de procesamiento al servicio de
transferencia de archivos cuando este se realiza utilizando la red WLAN, sin embargo, las operaciones
de cifrado y descifrado no tiene efecto significativo en el consumo de energıa. Las pruebas de
desempeno tambien demostraron los beneficios del cambio automatico de red de GPRS a WLAN, en
donde se confirmo que la tasa de transferencia y por lo tanto el tiempo de transferencia al utilizar
112 5.3. Resumen
una red WLAN son muy superiores comparados con la red GPRS, ası mismo, se demostro que no es
viable, al menos en el caso de esta aplicacion, el uso de la red GPRS para la transferencia de archivos
de gran tamano, debido a lo elevado del costo por kilobyte transferido. Ademas, el servicio de datos
no es muy eficiente ni constante debido a la disponibilidad de la red GPRS, la tasa de transferencia
presenta fuertes variaciones durante el dıa dependiendo de la saturacion de la red de telefonıa celular.
6Conclusiones y trabajo futuro
El telefono celular moderno se ha convertido en un dispositivo multifuncion que poco a poco
ha ido reuniendo las funciones de varios dispositivos, tales como agendas electronicas, vıdeo juegos
portatiles, reproductores de musica, etc. Existe gran variedad de aplicaciones moviles que aprovechan
las nuevas caracterısticas del telefono celular. Sin embargo, las aplicaciones que acceden a Internet
no se ha popularizado, con excepcion quiza del correo electronico, debido a los costos elevados del
servicio GPRS. Una mejora reciente que se le ha hecho al telefono celular ha sido la incorporacion de
la interfaz Wi-Fi, esta se presenta como una alternativa rapida y economica para acceder a Internet.
Un inconveniente que presentan la mayorıa de las aplicaciones actuales que acceden a Internet por
medio de una red WLAN, desde un telefono celular, es que se requiere un cambio manual en la
configuracion de la red de acceso. Esta configuracion manual puede ser molesta si consideramos que
la disponibilidad de una red inalambrica puede variar a medida que el usuario se desplaza.
Al iniciar el desarrollo de este trabajo de tesis nos propusimos desarrollar un mecanismo que
solucionara el problema del cambio de la red en dispositivos moviles que cuentan con interfaz Wi-Fi
y que permitiera efectuar automaticamente este cambio entre redes GPRS y WLAN.
La plataforma de handover vertical que se desarrollo actua como un modulo independiente
113
114
que puede ser usado por cualquier aplicacion que acceda a Internet desde un telefono celular. La
integracion de la plataforma de handover a diferentes aplicaciones es factible como se demostro con
el desarrollo e implementacion del sistema de monitoreo de signos vitales.
Se implementaron dos protocolos descritos en el Capıtulo 4 en la pagina 41, como parte del
desarrollo del sistema de monitoreo de signos vitales: un protocolo para las comunicaciones por
Bluetooth y otro para las comunicaciones por Internet.
El protocolo de comunicaciones por Bluetooth se diseno para realizar de manera confiable la
transferencia de informacion desde el dispositivo monitor hacia el telefono celular. Este protocolo se
desarrollo considerando que el dispositivo sensor tiene recursos de computo limitados, es simple ya
que solo consta de 10 comandos pero demostro ser lo suficientemente robusto como para realizar
satisfactoriamente la transferencia de archivos a pesar de los errores frecuentes de comunicacion.
El protocolo para comunicaciones por Internet es similar al protocolo para Bluetooth, se
diseno para realizar de manera confiable la transferencia de informacion desde el telefono celular
hacia el servidor de aplicacion. La incorporacion a este protocolo de los mecanismos de recuperacion
de errores de transmision y de handover permitio que las transferencias de datos se completaran a
pesar de los errores de comunicacion y de los cambios de red. Ademas, estos mecanismos hicieron
posible un uso mas eficiente de la red GPRS al permitir reanudar las transmisiones en el punto en el
que fueron interrumpidas.
Los servicios de seguridad agregados al sistema de monitoreo de signos vitales garantizan que
la informacion que se envıa desde el telefono celular hacia el servidor de aplicacion no pueda ser
observada ni manipulada por personas no autorizadas. La confidencialidad se implemento cifrando
todos los datos enviados hacia el servidor de aplicacion por medio del algoritmo AES. La verificacion
de la integridad de los datos se realiza al final de cada transferencia y se implemento utilizando
el algoritmo de hash seguro SHA-1. La autenticacion se implemento como parte del esquema de
distribucion de llaves de sesion.
Las pruebas realizadas mostraron que la plataforma de handover efectua satisfactoriamente los
cambios de red en los tres posibles escenarios:
6. Conclusiones y trabajo futuro 115
Cambio de red WLAN a red GPRS
Cambio de red GPRS a WLAN
Cambio de red WLAN a otra red WLAN
El cambio de red WLAN a GPRS se realizo en promedio en 18.68 segundos, el cambio de red
GPRS a WLAN se realizo en promedio en 3.75 segundos y el cambio de red WLAN a WLAN se
realizo en promedio en 1.25 segundos. El cambio de red WLAN a GPRS toma un tiempo considerable
comparado con los otros dos cambios de red debido a que el tiempo de respuesta de la red GPRS
es grande. El menor tiempo de acceso registrado durante las pruebas fue de mas de 6 segundos,
sin embargo, este tiempo de conexion presenta fuertes variaciones durante el dıa dependiendo de la
saturacion de la red celular telefonica.
Las pruebas de transferencia de archivo muestran que la tasa de transferencia real, cuando se usa
la red WLAN es de hasta 256.76 KB/s. Sin embargo la tasa de transferencia de la red GPRS es de
tan solo 0.28 KB/s en el mejor de los casos, muy por abajo de la tasa de transferencia esperada de
150 Kbps. Ademas, en el caso de la red GPRS las pruebas mostraron que la disponibilidad de la red
presenta fuertes variaciones dependiendo de la hora del dıa.
Se encontro tambien que el efecto de las operaciones de cifrado y descifrado ejecutadas en
el telefono celular tiene muy poco impacto en el consumo de energıa, siendo posible cifrar hasta
aproximadamente 380 Mb con solo el 15 % de la carga de la baterıa.
En terminos generales, podemos concluir que la plataforma de handover desarrollada
funciona satisfactoriamente y puede tener aplicacion practica, lo anterior fue demostrado con la
implementacion que se hizo en el telefono celular del sistema de monitoreo de signos vitales. Este
sistema, como las pruebas lo demostraron, es capaz de transferir informacion desde el telefono
celular hacia el servidor de aplicacion en escenarios de cambio de red, garantizando la integridad y
la confidencialidad de la informacion.
Aunque los objetivos establecidos al inicio de este trabajo de tesis fueron alcanzados y se
cumplio con la funcionalidad prometida hay algunos aspectos que podrıan ser mejorados. Este trabajo
se verıa mejorado anadiendo a la plataforma el servicio de no repudio. Esto harıa a la plataforma
116 6.1. Trabajo futuro
mas robusta porque permitirıa desarrollar otras aplicaciones que requieran demostrar en caso de
una disputa quien realizo una determinada transaccion, como es el caso de las aplicaciones de pago
electronico.
6.1 Trabajo futuro
Un trabajo futuro que podrıa derivarse de esta tesis es el desarrollo de una plataforma de handover
vertical para dispositivos moviles con tecnologıa 3G. La tecnologıa actual en la mayorıa de los telefonos
es 2G, esta tecnologıa proporciona el servicio de transferencia de datos a traves de GPRS, esta red
tiene una muy baja tasa de transferencia como se demostro en las pruebas realizadas. La tecnologıa 3G
proporciona un servicio de datos con una tasa de transferencia de hasta 1.5 Mbps y esta sustituyendo
rapidamente a la tecnologıa 2G, por lo tanto serıa recomendable actualizar la plataforma para que
el proceso de handover se haga entre las redes WLAN y HSDPA que es el servicio de datos de 3G.
Otro trabajo futuro que podrıa hacerse a partir de esta tesis es el uso de criptografıa de llave publica,
esto permitirıa entre otras cosas el uso de firmas digitales para aquellas aplicaciones que lo requieran
y permitirıa implementar un mejor esquema de distribucion de llaves de sesion. Un tercer trabajo
futuro serıa agregar al servicio de transferencia de archivos un mecanismo de compresion de datos,
con el objeto de reducir los tiempos de transmision y al mismo tiempo aprovechar mejor el ancho de
banda.
AModelo de sockets
A.0.1 El modelo de sockets
A fin de facilitar el desarrollo de protocolos de capas superiores, y al mismo tiempo hacer este
desarrollo mas portable, se utilizo el modelo de sockets. Tıpicamente, uno de los extremos de
una comunicacion basada en sockets es un servidor, y la otra es el cliente. En este protocolo de
comunicacion el telefono celular desempena el papel del cliente y el dispositivo monitor de signos
vitales el de servidor.
El conjunto mınimo de funciones que se proponen para este modelo de sockets se divide en tres
grupos:
Las funciones comunes a ambos extremos cliente y servidor,
Las funciones del lado del cliente
Las funciones del lado del servidor
117
118
A.0.2 Funciones comunes
La funcion socket(): Una funcion para ambos, clientes y servidores es socket(), esta funcion
crea un socket de acuerdo a los parametros que se le pasan como argumentos. La funcion es declarada
de la siguiente manera:
int socket(int domain, int type, int protocol);
El valor que regresa la funcion es de tipo entero. El argumento domain indica que familia de protocolos
se desea usar. En este caso la familia serıa AF BT. Los valores definidos para el argumento type son
dos. SOCK STREAM le dice al sistema que se esta pidiendo un servicio de entrega de flujo confiable.
SOCK DGRAM solicita un servicio de datagramas sin conexion. El argumento protocol depende de
los dos argumentos anteriores y no siempre tiene significado. En este caso se usa 0 para su valor.
La funcion recv(): La funcion recv() recibe datos de un socket. La funcion es declarada de la
siguiente manera:
int recv(int s, void *buf, int buffsize);
El argumento s es un socket conectado. El argumento buf es un buffer en donde se pondran
los datos recibidos. El argumento buffsize indica el tamano maximo de los datos que se reciben a
la vez. La funcion regresa la longitud del mensaje cuando se recibio con exito. Si no hay mensajes
disponibles en el socket, la llamada espera a que llegue un mensaje, a menos que el socket sea no
bloqueante, en este caso la funcion regresa un valor de -1.
La funcion send(): La funcion send() envıa datos al socket. El socket debe estar conectado a
un socket remoto. La funcion es declarada de la siguiente manera:
int send(int s, const void *msg, int len);
A. Modelo de sockets 119
El argumento s es un socket conectado. El argumento msg es un buffer en donde estan los datos
a ser enviados. El argumento len indica longitud del mensaje que se envıa. La funcion regresa la
longitud del mensaje enviado.
La funcion close(): La funcion close() cierra la conexion en el socket y libera el descriptor de
socket. La funcion es declarada de la siguiente manera:
int close(int s);
El argumento s es el descriptor del socket que se quiere cerrar. La funcion regresa 0 si termino con
exito y -1 si ocurrio algun error.
A.0.3 Funciones del cliente
Tıpicamente el cliente inicia la conexion al servidor. El cliente sabe a cual servidor va a llamar.
Conoce su direccion y conoce el puerto (canal) en el que escucha el servidor.
La funcion connect(): Una vez que un cliente ha creado un socket, necesita conectarlo a un
puerto especıfico en un sistema remoto. La funcion es declarada de la siguiente manera:
int connect(int s, char *address, int port);
El argumento s es el socket, el valor regresado por la funcion socket. El argumento address es un
apuntador a una cadena de caracteres con la direccion del servidor. El argumento port es el puerto
(canal) por el que se va a escuchar al servidor. Si la funcion se ejecuta con exito regresa 0, de lo
contrario regresa -1.
A.0.4 Funciones del servidor
El servidor tıpico no inicia la conexion. En lugar de eso espera que un cliente lo llame y solicite
servicios. La interfaz de sockets ofrece tres funciones basicas para manejar esto.
120
La funcion bind(): Se utiliza la funcion bind() para indicar al socket que puerto se desea servir.
La funcion se declara de la siguiente manera:
int bind(int s,char * address, int port );
El argumento s es el socket, el valor regresado por la funcion socket. El argumento address es un
apuntador a una cadena de caracteres con la direccion del servidor. Se puede utilizar una constante
simbolica o una cadena vacıa para indicar que se van a servir todas las solicitudes en el puerto
indicado, independientemente de que direccion se trate. El argumento port es el puerto (canal) por
el que va a escuchar el servidor. Si la funcion se ejecuta con exito regresa 0, de lo contrario regresa
-1.
La funcion listen(): La funcion listen() escucha las conexiones que se hacen al socket. La
funcion se declara de la siguiente manera:
int listen(int s, int backlog);
El argumento s es el socket, el valor regresado por la funcion socket. El argumento backlog le
indica al socket cuantas conexiones entrantes aceptara mientras esta ocupado atendiendo la ultima.
Es decir determina el tamano maximo de la cola de conexiones pendientes.
La funcion accept(): El servidor acepta la conexion utilizando la funcion accept(). La funcion
se declara de la siguiente manera:
int accept(int s,char * address);
El argumento s es el socket, el valor regresado por la funcion socket, ligado a una direccion
con la funcion bind() y que esta escuchando conexiones. El argumento address es un parametro de
resultado, en este se regresa la direccion de la entidad que se esta conectando.
A. Modelo de sockets 121
A.0.5 Secuencia de conexion de sockets
La secuencia de pasos para realizar una conexion tanto en el cliente como en el servidor se muestra
en la Figura A.1.
Socket
bind
listen
accept
send/recv
close
Socket
connect
send/recv
close
Servidor Cliente
Figura A.1: Secuencia para modo de entrega de flujo fiable
Del lado del servidor se ejecutan las siguientes acciones:
socket(): Crea el socket
bind(): Asocia la direccion del socket en el servidor
listen(): Especifica el numero maximo de solicitudes de conexion que pueden estar pendientes
para este proceso
accept(): Establece la conexion con un cliente especıfico
122
send(), recv(): Envıa y recibe datos
close(): Cierra conexion y libera descriptor de socket
Del lado del cliente se ejecutan las siguientes acciones:
socket(): Crea el socket
connect(): Establece la conexion con servidor
send(), recv(): Envıa y recibe datos
close(): Cierra conexion y libera descriptor de socket
BFunciones utilizadas
B.1 Funciones para manejo de handover
B.1.1 La funcion SelectBestIAPL()
La funcion SelectBestIAPL() regresa como resultado el numero de identificacion del mejor punto
de acceso a Internet (IAP por sus siglas en ingles) disponible en el telefono celular. Esta funcion no
toma ningun argumento, y regresa como resultado un entero sin signo. El valor de retorno corresponde
al identificador del mejor punto acceso acceso a Internet (IAP por sus siglas en ingles), y se obtiene
de acuerdo al algoritmo que se describio en el capıtulo 3. La funcion SelectBestIAPL() esta escrita
en Symbian C++, y se programo con la biblioteca de desarrollo S60 3rd Edition C++ FP2, se
compilo como una DLL para poder ser invocada desde un programa en Python para S60. Para hacer
la interfaz entre Symbian C++ y Python se utilizo un envoltorio (wrapper), el cual se describe mas
adelante en este apendice.
TUint32 CIAPEngine::SelectBestIAPL()
123
124 B.1. Funciones para manejo de handover
/* Regresa el identificador (IAPid) del mejor punto de acceso, seleccionado
* de acuerdo a la polıtica de seleccion siguiente:
* si hay una red WLAN disponible entonces la selecciona (la de mayor potencia se se~nal)
* si no hay red WLAN, selecciona la red GPRS, si hay algun error se devuelve 0
*/
{
RConnectionMonitor iConnMon;
TRequestStatus status;
TFileName iapName;
TUint32 iapID=0;
TConnMonIapInfoBuf iapBuf;
User::LeaveIfError( iConnMon.ConnectL() ); //conectando con el servidor
// Primero se busca el IAP que sea WLAN y que tenga la mayor potencia
iapID = SelectBestWlanIAPL();
if (iapID == 0)
// Como no hubo red WLAN disponible, ahora intentamos GPRS
{
iConnMon.GetPckgAttribute( EBearerIdGPRS, 0, KIapAvailability, iapBuf, status );
User::WaitForRequest( status ) ;
if ( status.Int() != KErrNone )
{
return 0;
}
else
{ //Si hay alguna red GPRS disponible que sea IAP
TInt countIaps = iapBuf().iCount;
if (countIaps > 0)
{
// regresa la primera red GPRS de la lista de IAPs disponibles
iapID = iapBuf().iIap[0].iIapId;
}
}
}
return iapID;
}
B. Funciones utilizadas 125
B.1.2 La funcion SelectBestWlanIAPL()
La funcion SelectBestWlanIAPL() regresa como resultado el numero de identificacion de la red
WLAN que tiene la mayor potencia de senal en el telefono celular. Esta funcion no tiene argumentos,
y regresa como resultado un entero sin signo. El valor de retorno corresponde al identificador del
punto acceso acceso a Internet de la red WLAN que tiene la senal mas potente. El identificador de
la red WLAN se obtiene realizando una busqueda secuencial de todas las redes que son detectadas
en el telefono celular. La funcion SelectBestWlanIAPL() tambien esta escrita en Symbian C++. La
potencia de la senal se obtiene a partir del atributo iSignalStrength de la clase iNetwork, esta clase
es a su vez un atributo de la clase pkgNetworks, una instancia de esta ultima clase se obtiene por
medio de un llamado a la funcion GetPckgAttribute(). La funcion GetPckgAttribute forma parte de
las APIs de la biblioteca de desarrollo S60 3rd Edition C++ FP2.
TUint32 CIAPEngine::SelectBestWlanIAPL()
{
/* Selecciona la red WLAN que tenga el menor valor de potencia de se~nal
* y que sea menor a 75 dB (entre mayor es valor, menor es la potencia), siempre
* y cuando la red inalambrica sea un IAP
*/
TBuf<32> netName;
RConnectionMonitor monitor;
TUint32 iapId,potencia,menor_potencia;
TUint32 iSelected_Wlan_IapId=0;
menor_potencia = 100;
TPckgBuf<TConnMonNetworkNames> pkgNetworks;
// establece la conexion con el monitor de servidor
monitor.ConnectL();
// prepara limpieza de salida
CleanupClosePushL(monitor);
TRequestStatus status;
// obten la lista de redes disponibles
monitor.GetPckgAttribute(EBearerIdWLAN, 0, KNetworkNames, pkgNetworks, status);
126 B.1. Funciones para manejo de handover
// suspende el hilo hasta que la informacion es obtenida
User::WaitForRequest( status ) ;
// sal si el metodo asıncrono regresa un error
User::LeaveIfError(status.Int());
// para cada red WLAN
for(TUint i=0; i<pkgNetworks().iCount; i++)
{
// Obten el nombre de la red WLAN
netName.Copy(pkgNetworks().iNetwork[i].iName);
// Obten la potencia de la se~nal de la red WLAN
potencia= pkgNetworks().iNetwork[i].iSignalStrength;
// Obten el identificador de IAP de la red WLAN
iapId = ObtenIapId(netName);
if (potencia <= 75 && iapId > 0)
// se consideran aquellas WLANs cuya potencia es menor a 75dB
// y que sean puntos de acceso a internet (IAP)
if (potencia < menor_potencia)
{
menor_potencia = potencia;
iSelected_Wlan_IapId = iapId;
}
}
return iSelected_Wlan_IapId;
}
B.1.3 Funciones de interfaz Symbian C++/Python (wrapper)
La funcion SelectBestIAPL() esta escrita en Symbian C++, y se compilo como una DLL para
ser invocada desde un programa escrito en Python para S60. Para poder hacer el llamado de una
funcion escrita en Symbian C++ desde un programa en Python, se necesita un programa de interfaz
entre ambos lenguajes de programacion, este programa recibe el nombre de envoltorio (wraper). El
envoltorio esta escrito en OpenC para S60, su funcion es pasar los resultados del programa escrito
en Symbian C++ a un formato que sea entendible para Python.
B. Funciones utilizadas 127
#include <e32std.h>
#include <python.h>
#include "symbian_python_ext_util.h"
#include "IAPEngine.h"
extern "C"
void _mod_cleanup();
extern "C" PyObject*
IapSelect(PyObject* /*self*/, PyObject* args)
{
PyObject* Iaplist = PyList_New(1);
PyObject* IapId;
PyObject* IapName;
PyObject * tup;
TUint32 Id=0;
CIAPEngine* iIAPEngine ;
iIAPEngine = CIAPEngine::NewL();
Id = iIAPEngine->SelectBestIAPL();
IapId = Py_BuildValue("i", Id);
PyList_SetItem(Iaplist, 0,IapId);
return Iaplist;
}
extern "C"
{
static const PyMethodDef
Iaptools_methods[] = {
{"IapSelect", (PyCFunction)IapSelect, METH_VARARGS, NULL},
{NULL, NULL} /* sentinela */
};
DL_EXPORT(void)
initIaptools(void) // Aquı :este sımbolo fue definido en algun archivo frz
{
128 B.2. Funciones para servicios de seguridad
PyObject *m;
m = Py_InitModule("Iaptools", (PyMethodDef*)Iaptools_methods);
return;
}
} /* extern "C" */
B.2 Funciones para servicios de seguridad
B.2.1 Funciones de cifrado y descifrado
El cifrado y descifrado de los datos se hace con el algoritmo de cifrado AES el cual utiliza una
llave de 128 bits. Las funciones de cifrado y descifrado se escribieron OpenC, la implementacion se
hizo utilizando la biblioteca de funciones OpenSSL.
La funcion de cifrado s60 encrypt AES() toma como argumentos de entrada dos cadenas de
caracteres y un numero entero, la primera cadena es el texto a cifrar y es de 16 bytes, la segunda
cadena es la llave y el entero es la longitud de la llave, el argumento de salida es el texto cifrado y es
una cadena de caracteres de 16 bytes. El argumento de entrada que contiene la llave es una cadena
de longitud arbitraria sin embargo la funcion s60 encrypt AES() la convierte a una llave de 16 bytes
o 128 bits por medio de la funcion hash MD5.
La funcion de descifrado s60 decrypt AES() efectua la operacion inversa de la funcion
s60 encrypt AES(), toma los mismos argumentos de entrada pero significan cosas diferentes, en
este caso la primera cadena de entrada es el texto cifrado y la cadena de salida es el texto claro.
#include <stddef.h>
#include <openssl/aes.h>
#include <openssl/md5.h>
void s60_encrypt_AES( unsigned char* in, unsigned char* out,
unsigned char* password, int passlen)
{
B. Funciones utilizadas 129
unsigned char digest[MD5_DIGEST_LENGTH];
AES_KEY key;
MD5(password, passlen, digest);
AES_set_encrypt_key(digest, 128, &key );
AES_encrypt( in, out,&key);
}
void s60_decrypt_AES( unsigned char* in, unsigned char* out,
unsigned char* password, int passlen)
{
unsigned char digest[MD5_DIGEST_LENGTH];
AES_KEY key;
MD5(password, passlen, digest);
AES_set_decrypt_key(digest, 128, &key );
AES_decrypt( in, out,&key);
}
B.2.2 Funciones de interfaz Open C/Python (wraper)
Las funciones s60 encrypt AES() y s60 decrypt AES() tambien se compilaron como una DLL
para poder ser invocadas desde un programa en Python para S60, por lo tanto tambien se necesita
un programa de interfaz entre OpenC y Python, para convertir el resultado generado por las funciones
escritas en OpenC al formato de datos de Python. El programa de interfaz se muestra a continuacion,
y tambien esta escrito en OpenC.
#include <python.h>
#include "s60crypt.h"
static PyObject* pycrypt_encrypt_AES(PyObject* self, PyObject* args)
{
char* data;
int datalen;
char* pw;
int pwlen;
130 B.2. Funciones para servicios de seguridad
char* out;
PyObject* result;
if (!PyArg_ParseTuple(args, "s#s#", &data, &datalen, &pw, &pwlen))
return NULL;
out = (char*)malloc(datalen);
if (!out)
return PyErr_NoMemory();
s60_encrypt_AES( data, out, pw, pwlen);
result = Py_BuildValue("s#", out, datalen);
free(out);
if (!result)
return PyErr_NoMemory();
return result;
}
static PyObject* pycrypt_decrypt_AES(PyObject* self, PyObject* args)
{
char* data;
int datalen;
char* pw;
int pwlen;
char* out;
PyObject* result;
if (!PyArg_ParseTuple(args, "s#s#", &data, &datalen, &pw, &pwlen))
return NULL;
out = (char*)malloc(datalen);
if (!out)
return PyErr_NoMemory();
s60_decrypt_AES( data, out, pw, pwlen);
result = Py_BuildValue("s#", out,datalen);
free(out);
if (!result)
return PyErr_NoMemory();
return result;
}
B. Funciones utilizadas 131
static const PyMethodDef PyCryptMethods[] =
{
{"encrypt_AES", pycrypt_encrypt_AES, METH_VARARGS},
{"decrypt_AES", pycrypt_decrypt_AES, METH_VARARGS},
{NULL, NULL}
};
DL_EXPORT(void) initpycrypt(void)
{
(void)Py_InitModule("pycrypt_v", PyCryptMethods);
}
Bibliografıa
[1] GSM World. disponible en http://www.gsmworld.com. 7 de Septiembre 2008.
[2] How americans use their cell phones. Disponible en http://www.pewinternet.org/pdfs/
PIP_Cell_phone_study.pdf. 21 de Septiembre 2008.
[3] Wi-Fi Component Forecast and Vendor Share 2005. Disponible en http://www.
strategyanalytics.net/default.aspx?mod=ReportAbstractViewer&a0=2480. 18 de
Octubre 2008.
[4] Central Intelligence Agency. The World Factbook 2007. Potomac Books Inc., 2007.
[5] Steve Babin and Richard Harrison. Developing Software for Symbian OS, page 11. John Wiley
& Sons Ltd, 2006.
[6] Christian Bettstetter, Hans-Jorg Vogel, and Jorg Eberspacher. GSM Phase 2+ General Packet
Radio Service GPRS: Architecture, Protocols and Air Interface. IEEE Communications Surveys,
2:2–4, 1999.
[7] R. Good and N. Ventura. A Multilayered Hybrid Architecture to Support Vertical Handover
between IEEE802.11 and UMTS. IWCMC 2006, 1:257–262, 2006.
[8] Network Working Group. Internet Security Glossary (rfc 2828). pages 13,170, 2007.
[9] Gunnar Heine. GSM Networks: Protocols, Terminology and Implementation, page 2. Artech
House, 1999.
[10] Digia Inc. Programming for the Series 60 Platform and Symbian OS, pages 1,6. John Wiley &
Sons Ltd, 2003.
133
134 BIBLIOGRAFIA
[11] Rong-Hong Jan and Wen-Yueh Chiu. An approach for seamless handoff among mobile
WLAN/GPRS integrated networks. Computer Communications, 29:32–41, 2005.
[12] Houda Labiod, Hossam Afifi, and Costantino de Santis. Wi-Fi Bluetooth ZigBee and WiMax,
page 104. Springer, 2007.
[13] Tom Van Leeuwen, Ingrid Moerman, and Piet Demeester. Location assited fast vertical handover
for UTMS/WLAN overlay networks. Computer Communications, 29:2601–2611, 2006.
[14] Rick Lehtinen. Computer Security Basics, 2nd Edition. O’Reilly, 2006.
[15] Li Ma, Fei Yu, and Victor Leung. A New Method to Support UMTS/WLAN Vertical Handover
Using SCTP. IEEE Wireless Communications, 11:44–51, 2004.
[16] Nathan J. Muller. Bluetooth Demystified. McGraw-Hill, 2001.
[17] NIST. Report on the Development of the Advanced Encryption Standard (AES), October 2000.
[18] NIST. Announcing the ADVANCED ENCRYPTION STANDARD (AES), November 2001.
[19] NIST. Announcing the SECURE HASH STANDARD, August 2002.
[20] Francisco Rodrıguez-Henrıquez, N.A. Saquib, Arturo Dıaz Perez, and Cetin Kaya Koc.
Cryptographic Algorithms on Reconfigurable Hardware, pages 8–9. Springer, 2006.
[21] Apostolis K. Salkintzis. Interworking between WLANs and third-generation cellular data
networks. Vehicular Technology Conference, 2003, 3:1802–1806, 2006.
[22] Bluetooth SIG. Specification of the Bluetooth System, Version 2.0, page 29. Bluetooth SIG,
2004.
[23] Raymond Smith. Wi-Fi Home Networking, pages 16–19. McGraw-Hill, 2003.
[24] Jee-Young Song, Hye Jeong Lee, Sun-Ho Lee, and Dong-Ho Cho. Hybrid coupling scheme for
UMTS and wireless LAN interworking. International Journal of Electronics Communications,
61:329–336, 2007.
BIBLIOGRAFIA 135
[25] William Stallings. Cryptographic and Network Security Principles and Practices, pages 11–
14,353. Prentice Hall, 2005.
[26] Raymond Steele, Chin-Chun Lee, and Peter Gould. GSM, cdmaOne and 3G Systems, page 65.
John Wiley & Sons Ltd, 2001.
[27] Q. Zhang, C. Guo, Z. Guo, and W. Zhu. Efficient mobility management for vertical handoff
between WWAN and WLAN. IEEE Communications Magazine, 41:102–108, 2003.
[28] Pei Zheng and Lionel M. Ni. Spotlight: The Rise of the Smart Phone. IEEE Distributed Systems
Online, 7:1–14, 2006.
Recommended