Tesis Vargas

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.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


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),


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.


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.


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


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


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


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


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


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.


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


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.


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


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].


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


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


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


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


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


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


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


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


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


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


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.


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.


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


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


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


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


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


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


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


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


RETRANSMITE_ARCHIVO

. . .

bloque n + 1

bloque m

EOF

BLOQUE_RECIBIDO

EOF_RECIBIDO

Figura 4.26: Intercambio de mensajes de comando RETRANSMITE ARCHIVO


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


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.


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


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


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


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


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.


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


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


COMANDO_RECIBIDO


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


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,


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



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


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


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.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.


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


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


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


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


Fragmento de 16 bytes 1



Fragmento de 16 bytes n

Bloque de datosoriginal

CifradorAES




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


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.


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


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


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


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


2. Se cerro la conexion GPRS


18001

4. Se midio el tiempo que transcurrio desde antes de cerrar la conexion GPRS hasta despues de

que se creo 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:


18000



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


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


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


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.


Tiempos de transferencia de archivo sin servicios de seguridad usando WLAN


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


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.


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


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


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.


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


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


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.


#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)

{


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 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)


s60_decrypt_AES( data, out, pw, pwlen);

result = Py_BuildValue("s#", out,datalen);

free(out);

if (!result)


return result;

}


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.

Tesis Vargas

Documents

Transcript of Tesis Vargas