Tesis Vargas

n y de Estudios Avanzados
Centro de Investigacio
cnico Nacional
del Instituto Polite
Laboratorio de Tecnologas de Informacion
Una plataforma de handover

vertical para aplicaciones en
dispositivos m
oviles
Tesis que presenta:

Juan Antonio Vargas Enrquez
Para obtener el grado de:

Maestro en Ciencias
en Computaci
on
Director de la Tesis:
Dr. Arturo Daz Perez
Cd. Victoria, Tamaulipas, Mexico.
Febrero, 2009
c Derechos reservados por

2009
Esta investigacion fue parcialmente financiada mediante el proyecto No. 51623 del Fondo Mixto
Conacyt-Gobierno del Estado de Tamaulipas
This research was partially funded by project number 51623 from Fondo Mixto Conacyt-Gobierno
del Estado de Tamaulipas
La tesis presentada por Juan Antonio Vargas Enrquez fue aprobada por:
Dr. Luis Gerardo de la Fraga
Dr. Victor Jesus Sosa Sosa
Dr. Arturo Daz 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 por
el apoyo incondicional que siempre me ha brindado a pesar de mi caracter difcil y de mi errores,
Lilia tu siempre has credo en m, a mi hijo Juan Antonio, has sido un nino muy deseado, ahora
tengo una razon mas para seguir adelante, a todos ustedes les dedico este trabajo con mucho
carino.
Agradecimientos
Al Dr. Arturo Daz 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 a
revisar 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 Gonzalez
por el apoyo economico brindado para la realizacion de estos estudios y por todas la facilidades
otorgadas.
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 Tecnologas de Informacion del CINVESTAV
Tamaulipas por haber estado siempre dispuestos a compartir sus conocimientos conmigo.
Al CONACYT por el apoyo economico otorgado para la realizacion mis estudios de maestra
A mis companeros de cubculo, Fede, Juan Carlos y Daniel (el mudo) quienes hicieron mas
llevaderas las largas jornadas de trabajo.
Indice General
Indice General
Indice de Figuras
Indice de Tablas
VII
Indice de Algoritmos
IX
Resumen
XI
Abstract
XIII
1. Introducci
on
2. Conceptos generales
2.1. Telefonos inteligentes . . . . . . . . . . . . . . .
2.2. El dispositivo . . . . . . . . . . . . . . . . . . . .
2.3. Asistentes personales digitales (PDA) . . . . . . .
2.4. Interfaces de comunicacion . . . . . . . . . . . .
2.4.1. El sistema GSM . . . . . . . . . . . . . .
2.4.2. Arquitectura del sistema GSM . . . . . . .
2.4.3. General Packet Radio Service (GPRS) . . .
2.4.4. Arquitectura del sistema GPRS . . . . . .
2.4.5. Redes inalambricas 802.11 . . . . . . . . .
2.4.6. Bluetooth . . . . . . . . . . . . . . . . .
2.5. El sistema operativo Symbian y la plataforma S60
2.6. Handover vertical . . . . . . . . . . . . . . . . .
2.7. Seguridad computacional . . . . . . . . . . . . .
2.7.1. Servicios de seguridad . . . . . . . . . . .
2.7.2. Herramientas de seguridad . . . . . . . . .
2.8. Resumen . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Arquitectura
3.1. Sistema de monitoreo de signos vitales . . . . . . . . .
3.2. Arquitectura del sistema de monitoreo de signos vitales .
3.2.1. Arquitectura del cliente . . . . . . . . . . . . .
3.2.2. Arquitectura del servidor de aplicacion . . . . .
3.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
9
11
11
12
12
16
17
18
19
22
23
24
26
27
29
.
.
.
.
.
31
31
35
36
38
40
4. Comunicaciones
4.1. Comunicaciones . . . . . . . . . . . . . . . . . . . . .
4.1.1. Transferencia de archivos por Bluetooth . . . . .
4.1.2. Comunicacion entre telefono celular y servidor de
4.2. Handover vertical GPRS/WLAN . . . . . . . . . . . . .
4.2.1. Mecanismo de handover . . . . . . . . . . . . .
4.2.2. Cambio de red durante transferencia de archivos
4.3. Servicios de seguridad . . . . . . . . . . . . . . . . . .
4.3.1. Autenticacion . . . . . . . . . . . . . . . . . .
4.3.2. Confidencialidad . . . . . . . . . . . . . . . . .
4.3.3. Integridad . . . . . . . . . . . . . . . . . . . .
4.4. Resumen . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
aplicacion por Internet
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
5. Resultados
5.1. Funcionalidad de la plataforma . . . . . . . . . . . . . . . . . . . .
5.2. Desempeno de la plataforma . . . . . . . . . . . . . . . . . . . . . .
5.2.1. Tiempo de handover . . . . . . . . . . . . . . . . . . . . . .
5.2.2. Tamano optimo de bloque de TCP usando red WLAN . . . .
5.2.3. Tamano optimo de bloque de TCP usando red GPRS . . . .
5.2.4. Tiempos de cifrado/descifrado . . . . . . . . . . . . . . . . .
5.2.5. Tiempo de transferencia de archivos usando red WLAN . . .
5.2.6. Tiempo de transferencia de archivos usando red GPRS . . . .
5.2.7. Consumo de energa durante cifrado y descifrado de datos . .
5.2.8. Consumo de energa durante transferencia usando red WLAN
5.2.9. Consumo de energa durante transferencia usando red GPRS .
5.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
42
55
63
66
69
72
74
77
82
86
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
89
92
93
97
98
100
100
103
106
110
111
111
6. Conclusiones y trabajo futuro

113
6.1. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
A. Modelo de
A.0.1.
A.0.2.
A.0.3.
A.0.4.
A.0.5.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
117
117
118
119
119
121
B. Funciones utilizadas
B.1. Funciones para manejo de handover . . . . . . . . . . . . . . .
B.1.1. La funcion SelectBestIAPL() . . . . . . . . . . . . . .
B.1.2. La funcion SelectBestWlanIAPL() . . . . . . . . . . . .
B.1.3. Funciones de interfaz Symbian C++/Python (wrapper)
B.2. Funciones para servicios de seguridad . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
123
123
123
125
126
128
II
sockets
El modelo de sockets
Funciones comunes .
Funciones del cliente .
Funciones del servidor
Secuencia de conexion
. . . . . .
. . . . . .
. . . . . .
. . . . . .
de sockets
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B.2.1. Funciones de cifrado y descifrado . . . . . . . . . . . . . . . . . . . . . . . 128

B.2.2. Funciones de interfaz Open C/Python (wraper) . . . . . . . . . . . . . . . . 129
Bibliografa
133
III
Indice de Figuras
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
Estructura celular de red GSM . . . . . . . .

Arquitectura del sistema GSM . . . . . . . .
Arquitectura del sistema GPRS . . . . . . .
Pila de protocolos Bluetooth . . . . . . . . .
Modelo de capas de seguridad computacional
Criptografa de llave simetrica . . . . . . . .
3.1.
3.2.
3.3.
3.4.
Sistema de monitoreo de signos vitales .

Arquitectura del sistema de monitoreo de
Arquitectura del cliente . . . . . . . . .
Arquitectura del servidor . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
18
21
26
28
. . . . . . . .
signos vitales .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
35
36
39
4.1. Ubicacion de protocolo de transferencia por Bluetooth . . . . . . . . . . . . . . .

4.2. Intercambio de mensajes de comando AlarmaAmarilla . . . . . . . . . . . . . . .
4.3. Procesamiento del comando AlarmaAmarilla . . . . . . . . . . . . . . . . . . . .
4.4. Intercambio de mensajes de comando AlarmaRoja . . . . . . . . . . . . . . . . .
4.5. Procesamiento del comando AlarmaRoja . . . . . . . . . . . . . . . . . . . . . .
4.6. Intercambio de mensajes de comando BorraMemoria . . . . . . . . . . . . . . . .
4.7. Procesamiento del comando BorraMemoria . . . . . . . . . . . . . . . . . . . . .
4.8. Intercambio de mensajes de comando GetInfoPaciente . . . . . . . . . . . . . . .
4.9. Procesamiento del comando GetInfoPaciente . . . . . . . . . . . . . . . . . . . .
4.10. Intercambio de mensajes de comando GetID . . . . . . . . . . . . . . . . . . . .
4.11. Procesamiento del comando GetID . . . . . . . . . . . . . . . . . . . . . . . . .
4.12. Intercambio de mensajes de comando GetTemperatura . . . . . . . . . . . . . . .
4.13. Procesamiento del comando GetTemperatura . . . . . . . . . . . . . . . . . . . .
4.14. Intercambio de mensajes del comando GetArchivos . . . . . . . . . . . . . . . . .
4.15. Procesamiento del comando GetArchivos . . . . . . . . . . . . . . . . . . . . . .
4.16. Procesamiento de enva/recibe archivo . . . . . . . . . . . . . . . . . . . . . . .
4.17. Intercambio de mensajes de comando StartDatosContinuos . . . . . . . . . . . .
4.18. Procesamiento del comando StartDatosContinuos . . . . . . . . . . . . . . . . .
4.19. Formato de mensajes de comandos simples . . . . . . . . . . . . . . . . . . . . .
4.20. Formato de mensajes del comando GetInfoPaciente . . . . . . . . . . . . . . . . .
4.21. Formato de mensajes del comando GetArchivos . . . . . . . . . . . . . . . . . . .
4.22. Formato de mensajes de comandos GetID, GetTemperatura y StartDatosContinuos
4.23. Ubicacion del protocolo de transferencia en modelo de capas tcp/ip . . . . . . . .
4.24. Intercambio de mensajes de comando ENVIA ARCHIVO . . . . . . . . . . . . . .
4.25. Procesamiento del comando ENVIA ARCHIVO . . . . . . . . . . . . . . . . . . .
4.26. Intercambio de mensajes de comando RETRANSMITE ARCHIVO . . . . . . . . .
4.27. Procesamiento del comando RETRANSMITE ARCHIVO . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
44
44
45
46
46
47
48
48
49
49
50
50
51
52
53
54
54
55
56
57
58
59
60
61
61
62
4.28. Formato de mensajes de comandos del protocolo . . . .

4.29. Formato de mensaje de bloque de datos . . . . . . . . .
4.30. Cambio de red de GPRS a WLAN . . . . . . . . . . . .
4.31. Cambio de red de WLAN a GPRS . . . . . . . . . . . .
4.32. Cambio de red de WLAN a WLAN . . . . . . . . . . .
4.33. Diagrama de flujo de algoritmo de seleccion de punto de
4.34. Intercambio de mensajes durante handover . . . . . . .
4.35. Proceso de handover durante transferencia de archivo .
4.36. Ubicacion de los servicios de seguridad . . . . . . . . .
4.37. Distribucion de llaves de sesion y autenticacion . . . . .
4.38. Proceso de distribucion de llave de sesion . . . . . . . .
4.39. Algoritmo de cifrado AES . . . . . . . . . . . . . . . .
4.40. Algoritmo de descifrado AES . . . . . . . . . . . . . .
4.41. Cifrado de un bloque de datos . . . . . . . . . . . . . .
4.42. Servicio de integridad en telefono celular . . . . . . . .
4.43. Proceso de calculo de SHA-1 . . . . . . . . . . . . . .
4.44. Servicio de integridad en servidor de aplicacion . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
acceso a Internet
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
5.1. Escenario para pruebas de funcionalidad . . . . . . . . . . . . . . . . . .

5.2. Tiempo de handover WLAN/GPRS . . . . . . . . . . . . . . . . . . . .
5.3. Tiempo de handover GPRS/WLAN . . . . . . . . . . . . . . . . . . . .
5.4. Tiempo de handover WLAN/WLAN . . . . . . . . . . . . . . . . . . . .
5.5. Tamano optimo de bloque de TCP usando red WLAN . . . . . . . . . .
5.6. Tamano optimo de bloque de TCP usando red GPRS . . . . . . . . . .
5.7. Grafica comparativa de tiempos de cifrado/descifrado . . . . . . . . . .
5.8. Tiempos de transferencia usando red WLAN . . . . . . . . . . . . . . .
5.9. Tiempos de transferencia con y sin servicios de seguridad usando WLAN
5.10. Tiempos de transferencia usando red GPRS . . . . . . . . . . . . . . . .
5.11. Tiempos de transferencia con y sin servicios de seguridad usando GPRS .
5.12. Megabytes cifrados con una batera con carga completa . . . . . . . . .
5.13. Megabytes descifrados con una batera con carga completa . . . . . . . .
5.14. Megabytes transferidos con una batera con carga completa . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
63
67
67
68
69
71
72
73
74
75
79
81
82
83
85
86
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
92
93
94
95
97
98
99
101
103
104
105
108
109
110
A.1. Secuencia para modo de entrega de flujo fiable . . . . . . . . . . . . . . . . . . . . 121
VI
Indice de Tablas
2.1. Comparativo de telefonos inteligentes . . . . . . . . . . . . . . . . . . . . . . . . .
3.1. Comandos del protocolo de transferencia por Bluetooth . . . . . . . . . . . . . . .

3.2. Ventajas y desventajas de reds WLAN y GPRS . . . . . . . . . . . . . . . . . . . .
33
34
4.1. Comandos del protocolo de transferencia de archivo por Internet . . . . . . . . . . .

4.2. Combinaciones Llave-Bloque-Ronda . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3. Propiedades de los algoritmos de hash seguro . . . . . . . . . . . . . . . . . . . . .
57
78
83
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
5.7.
Tiempos de transferencia usando red WLAN . . . . . . . . . . . . . .

Tiempos de transferencia usando red GPRS . . . . . . . . . . . . . . .
Tiempos de transferencia con servicios de seguridad usando red WLAN
Tiempos de transferencia con servicios de seguridad usando red GPRS .
Megabytes cifrados con una batera con carga completa . . . . . . . .
Megabytes descifrados con una batera con carga completa . . . . . . .
Megabytes transferidos con una batera con carga completa . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
100
102
102
106
106
107
107
VII
Indice de Algoritmos
1.
Pasos para establecer llave de sesion. . . . . . . . . . . . . . . . . . . . . . . . . .
75
IX
Resumen
Una plataforma de handover vertical para aplicaciones en
dispositivos m
oviles
por

Maestro en Ciencias del Laboratorio de Tecnologas de Informacion
Centro de Investigacion y de Estudios Avanzados del Instituto Politecnico Nacional, 2009
Dr. Arturo Daz 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 mobile
devices
by

Master of Science in Information Technology Laboratory
Research Center for Advance Study from the National Polytechnic Institute, 2009
Dr. Arturo Daz Perez, Advisor
A recent improvement to cell phones has been the incorporation of communication interface WiFi, 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
1
Introduccion
n 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 telefona 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 pas. Para 1987 el numero de suscriptores de telefona celular en los Estados Unidos
excedio el millon. Desde entonces, el numero de usuarios de telefona celular ha crecido de manera
exponencial. En el ano 2005, el numero de telefonos celulares en uso en el mundo haba 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 envo o consulta de correo electronico.
El uso del telefono celular para acceder a Internet tendera a aumentar en los proximos anos. La
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 mayora 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
tecnologas 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. Introducci
on
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 enva 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 metodologa 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 poltica 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 poltica 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 enva 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. Introducci
on
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
caractersticas de ancho de banda, economa 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 poltica
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 criptografa 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 energa, 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 Captulo 2, se
abordan los conceptos generales de la telefona celular, de las diferentes interfaces de comunicacion y
de la seguridad informatica. En el Captulo 3 se presenta la arquitectura del sistema de monitoreo de
signos vitales y se describen cada unos de sus componentes. En el Captulo 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 Captulo 5 se
presentan el caso de estudio y los resultados obtenidos de acuerdo a las metricas establecidas.
Finalmente en el Captulo 6, se presentan las conclusiones del trabajo de tesis.
2
Conceptos generales
l 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 batera, etc. Por otro lado
es necesario familiarizarse con las diferentes tecnologas involucradas, tales como la telefona celular,
sistemas operativos propietarios, lenguajes de programacion y ambientes de desarrollo especializados.
En este captulo se presentan los conceptos basicos necesarios para comprender el desarrollo de
aplicaciones para dispositivos moviles.
2.1
Tel
efonos 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 mensajera de texto y facilita el procesamiento de
datos al mismo tiempo que tiene conectividad inalambrica mejorada. Se podra considerar al telefono
2.1. Tel
efonos inteligentes
celular inteligente como la fusion entre un poderoso telefono celular y una PDA (Personal Digital
Assistant) con interfaz inalambrica.
A diferencia de la mayora de los telefonos celulares, un telefono celular inteligente tiene las
siguientes caractersticas:
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 categoras 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 lnea 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.
Symbian OS es claramente el lder 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 energa , 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 batera, 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
caractersticas de algunos telefonos inteligentes populares, las cuales se describen a continuacion.
Categora
Tama
no de Pantalla
Resolucion
Memoria integrada
Camara
(Megapixeles)
Red
Teclado
Sistema Operativo
Duracion de batera
Hablar/Espera
Bluetooth
Nokia
N93
Alto rango
Nokia
N95
Alto rango
Treo
700p
PDA
Samsung
BlackJack
Correo
mejorado
2.2
320 x 240
64 Mb
1.3
iPhone
2.6
320 x 320
128 Mb
1.3
BlackBerry
8800
Correo
mejorado
2.5
320 x 240
64 Mb
-
2.4
320 x 240
50 Mb
3.2
2.8
240 x 320
100 Mb
5
EDGE
GPRS
WiFi
Numerico
Symbian
5.1 h
240 h
Si
EDGE
GPRS
WiFi
Numerico
Symbian
5h
280 h
Si
EVDO
EDGE
WCDMA
2100
EDGE
WiFi
QWERTY
Palm OS
4.5 h
300 h
Si
QWERTY
BlackBerry
5h
528 h
No
QWERTY
Windows M
5.5 h
264 h
Si
Virtual
OS X
8h
250 h
Si
Tabla 2.1: Comparativo de telefonos inteligentes
Alto rango
3.5
320 x 480
8 Gb
2
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 tecnologa 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
energa del telefono inteligente. Los telefonos inteligentes tpicamente usan tres tipos de bateras:
NiMH (hidruro metalico de nquel), Li-ion (ion de litio), y Li-polymer (polmero 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 energa mas rapidamente
que las simples tareas de computacion.
Los sistemas operativos y las aplicaciones son comparativamente mas pequenas que sus contrapartes 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 vdeo. El tamano
de las pantallas vara 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
11
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 mayora de los PDAs no disponen de disco duro porque los que se
suelen utilizar son demasiado grandes, demasiado lentos y consume mucha energa. Pero la tecnologa
ha avanzado a pasos agigantados. En estos das, los reproductores personales como el Ipod tiene
discos duros diminutos.
2.4
Interfaces de comunicaci
on
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 comunicaci

on
2.4.1
El sistema GSM
El Sistema Global para Comunicaciones Moviles (GSM por sus siglas en ingles) es la tecnologa
que soporta la mayora de las redes de telefona celular en el mundo. Actualmente la tecnologa GSM
es usada por mas de dos mil millones de personas en mas de 200 pases en el mundo, y contabiliza
el 81 % del mercado mundial de telefona 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 tecnologas nacionales ya sobrecargadas y por lo tanto caras de los pases 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 lneas
13
BSS
BSC
MS
BSC
BTS
PSTN
ISDN
PDN
MSC
BTS
GMSC
EIR
AUC
BSC
HLR
BTS
VLR
MS
BTS
MS
Figura 2.1: Estructura celular de red GSM
de acceso.
Todas las redes requieren que, a medida que la estacion movil se mueve, una llamada activa
sea entregada de una celula a otra, proceso conocido como entrega (handover).
La red tiene que mantenerse informada de la ubicacion aproximada de la estacion movil, aun
sin una llamada en curso, para ser capaz de entregar una llamada entrante a esa estacion movil.
El segundo y tercer punto requieren amplia comunicacion entre la estacion movil y la red,
as como entre los distintos elementos de la red.
Una red GSM esta compuesta por varios elementos: la estacion movil (MS), el modulo de
identificacion del suscriptor (SIM), el subsistema de estacion base (BSS), la estacion base transmisora
(BTS), la estacion base controladora (BSC), la unidad de transcodificacion y adaptacion (TRAU),
14

on
Frecuencia 3
Frecuencia 4
BSC
BTS
Frecuencia 1
BTS
BTS
Frecuencia 4
BTS
Frecuencia 3
Frecuencia 2
Frecuencia 2
BTS
BTS
BTS
Frecuencia 1
BTS
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:.
Estaci
on m
ovil: GSM-PLMN contiene tantos MS como sean posibles, estan disponibles en
varios estilos y clases de potencia.
M
odulo 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. Fsicamente, 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.
15
Subsistema de estaci
on 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.
Estaci
on 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.
Estaci
on 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 transcodificaci
on y adaptaci
on (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 conmutaci
on de servicios m
oviles (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 ubicaci
on 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 ubicaci
on de visitante (VLR): El VLR fue ideado de tal manera que el HLR
no se sobrecargara con peticiones de datos acerca de sus subscriptores. Al igual que el HLR,
un VLR contiene datos del suscriptor, pero solo parte de los datos que estan en el HLR y solo
mientras el suscriptor particular vaga en el area por la cual el VLR es responsable.
16

on
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 fsico.
Para corregir estas ineficiencias han sido desarrolladas dos tecnologas : 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 vara 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
17
por los servicios de conmutacion de circuitos. En los servicios de conmutacion de circuitos, la

facturacion se basa en la duracion de la conexion y normalmente se factura por minuto o por
segundo. En contraste con esto, con los servicios de conmutacion de paquetes, la transferencia de
datos es tpicamente facturada por kilo byte de datos transmitidos. La ventaja para el usuario es que
puede estar en lnea 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 enva a la correspondiente red
de paquetes de datos. En la direccion opuesta, las direcciones PDP de los paquetes de datos entrantes
son convertidas a la direccion GSM del usuario destino. En la Figura 2.3 se ilustra la arquitectura
del sistema
18

on
SMS-GMSC
SMS-IWMSC
Otra
GPRS PLMN
BSS
Gd
Gp
GGSN
BSC
Gb
SGSN
BSC
Gn
BTS
Gf
Gr
Gc
Gs
GGSN
Gi
BTS
EIR
HLR
PDN
MS
MSQVLR
Figura 2.3: Arquitectura del sistema GPRS
2.4.5
Redes inal
ambricas 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
tecnologa. 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
19
subestandares cada uno trata extensiones particulares.

Al igual que el IEEE 802.3 (Ethernet) y el 802.5 (Token Ring), el estandar 802.11 se centra
en las dos capas mas bajas (1 y 2) del modelo de referencia OSI (Open System Interconnection).
Este modelo de referencia divide la capa de control de enlace de datos (DLC) en las subcapas de
control de enlace logico (LLC) y control de acceso al medio (MAC). El 802.11 define los esquemas
de transmision de la capa fsica (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 tecnologa 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 lnea 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 lnea de vista, incluso es posible comunicarse a traves de
las paredes.
La capa fsica de radio de Bluetooth opera en la banda libre Industrial, Cientfica y Medica (ISM
por sus siglas en ingles) a 2.4 Ghz. La ventaja de operar en esta banda es la disponibilidad mundial y
compatibilidad. Una potencial desventaja es el hecho que los dispositivos Bluetooth deben compartir
esta banda con muchos otros emisores de RF (radio frecuencia), tales como sistemas de seguridad
20

on
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 enva 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
difcil para un dispositivo espa 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
caractersticas fsicas que el componente transmisor-receptor de un dispositivo Bluetooth debe tener.
Estas incluyen caractersticas 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
21
Aplicaciones y Perfiles
OBEX
SDP
RFCOMM
L2CAP
HCI
Link manager
Baseband/Link controller
Radio
Figura 2.4: Pila de protocolos Bluetooth
responsable de establecer conexiones a traves de enlaces existentes o solicitar un enlace si no existe

uno previamente. Tambien es responsable del multiplexado entre los diferentes protocolos de la capa
superior, tales como RFCOMM y SDP, para permitir que muchas aplicaciones diferentes usen un
mismo enlace.
La capa SDP (Service Discovery Protocol) define las acciones para clientes y servidores de servicios
Bluetooth. Un cliente SDP se comunica con un servidor SDP usando un canal reservado sobre un
enlace L2CAP para encontrar que servicios estan disponibles. Cuando el cliente encuentra el servicio
deseado, solicita una conexion separada para usar el servicio. El canal reservado es dedicado a la
comunicacion SDP de tal manera que un dispositivo siempre conozca como conectarse al servicio
SDP en cualquier otro dispositivo. Un servidor SDP mantiene su propia base de datos SDP, la cual
22
2.5. El sistema operativo Symbian y la plataforma S60
es un conjunto de registros de servicio que describe los servicios que el servidor ofrece.
Tambien arriba de la capa L2CAP se encuentra la capa RFCOMM. El protocolo RFCOMM emula
las configuraciones y estatus de un cable serial de un puerto serial RS-232. RFCOMM se conecta a
las capas inferiores del protocolo Bluetooth a traves de la capa L2CAP.
Al proporcionar la emulacion del puerto serial, RFCOMM apoya un legado de aplicaciones de
puerto serial. Tambien soporta el protocolo OBEX y varios de los perfiles Bluetooth.
2.5
El sistema operativo Symbian y la plataforma S60
Symbian es un sistema operativo para telefonos inteligentes. Symbian se formo en 1998 por
Ericsson, Motorola, Nokia y Psion para proporcionar un estandar comun y habilitar el mercado en
masa de una nueva generacion de dispositivos inalambricos [10]. Matsushita se unio a Symbian en
1999, en enero de 2002 la empresa conjunta Sony Ericsson tomo participacion en Symbian y en abril
de 2002 Siemens tambien se unio a Symbian como accionista. Desde el inicio, la meta de Symbian
fue desarrollar un sistema operativo y una plataforma de software para telefonos moviles avanzados.
Para este proposito, el sistema operativo EPOC desarrollado por Psion formo una base solida. Fue
un sistema operativo modular multitarea de 32 bits disenado para dispositivos moviles. Symbian es
un sistema operativo multitarea con caractersticas 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 caractersticas 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 (telefona,
mensajera 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.
23
La mayora 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 criptografa.
El microkernel se ejecuta directamente en el procesador en modo privilegiado. Es responsable

del manejo de la energa 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 lnea 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
fsica 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 fsica 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
25
o evento que podra violar la seguridad y causar danos. Es decir, una amenaza puede ser un peligro
que podra 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 poltica 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 categoras: 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
legtimo 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 caractersticas y necesidades pueden requerir uno o mas de estos servicios de
seguridad. En la parte inferior del modelo se encuentra la capa de herramientas de seguridad, esta
capa proporciona los algoritmos necesario para la implementacion de los servicios de seguridad que
se encuentran en la capa superior. Los servicios de seguridad as como las herramientas de seguridad
se explican a continuacion.
26
Aplicaciones para dispositivos mviles

Correo electrnico
Servicios bancarios
Transferencia de archivos
Confidencialidad
Integridad
Aplicaciones mdicas
Servicios finacieros
Actualizacin de BD
Autenticacin
No repudio
Herramientas de seguridad
Algoritmos
Criptogrficos
Funciones
Hash
Firmas
Digitales
Llave simtrica
DES, 3DES,AES
MD5
SHA-1
SHA-256
SHA-512
DSA
PKCS
ECDSA
Llave pblica
RSA,ECC
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
27
Rendicion de cuentas
No repudio
Dentro de estos terminos, la confidencialidad, la integridad, la autenticacion y el no repudio
constituyen lo que se conoce como servicios de seguridad [20], los cuales se definen a continuacion:
Confidencialidad: Garantiza que la informacion sensitiva puede solamente ser accedida por
usuarios o entidades autorizados para revelarla.
Integridad: Es un servicio que se ocupa de la modificacion no autorizada de datos.
Autenticaci
on: 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
Criptografa de llave sim

etrica
La criptografa de llave simetrica es una forma de criptosistema en el que el cifrado y descifrado
se realizan usando la misma llave. La criptografa 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 Vigen`ere 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.Tpicamente se usa un tamano de bloque de 64 o 128 bits. Usando
alguno de los modos de operacion, un cifrador de bloque puede ser usado para lograr el mismo efecto
que un cifrador de flujo [25].
28

Llave secreta compartida por
remitente y destinatario
Llave secreta compartida por

remitente y destinatario
Texto cifrado
Hola mundo
Cd, Victoria
Cinvestav
Hola mundo
Cd, Victoria
Cinvestav
tesis
Entrada
Texto claro
tesis
Algoritmo de cifrado
Algoritmo de descifrado
Salida
Texto claro
Figura 2.6: Criptografa 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 Tecnologa (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 funci
on hash SHA-1
El Algoritmo de Hash Seguro (SHA por sus siglas en ingles) fue desarrollado por el
Instituto Nacional de Estandares de Tecnologa (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
29
son SHA-1, SHA-224, SHA-256, SHA-384, y SHA-512 [19].
SHA-1 es una funcion que puede procesar un mensaje de una longitud maxima de 264 1 bits para
producir una representacion condensada llamada resumen del mensaje. La funcion SHA-1 genera un
resumen o digesto de 20 bytes o 160 bits de longitud. Este algoritmo permite determinar la integridad
de un mensaje: cualquier cambio en el mensaje resultara con una probabilidad muy alta en un resumen
de mensaje diferente[19].
En el Captulo 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 captulo 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 captulo se presentara la arquitectura de la aplicacion desarrollada.
3
Arquitectura
on el fin de demostrar la funcionalidad de la plataforma de handover vertical propuesta en

el Captulo 1, en este captulo 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 captulo 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 telefona 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
802.11
Access Point
Bluetooth
Internet
Dispositivo
monitor
Telfono celular
Servidor de Aplicacin
GPRS
Red GSM
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 enva 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 fsica
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 crtico ha sido detectado, un doctor debera ser visto
pronto
Alarma roja: un problema de salud crtico 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 tarda
Mejorar la calidad de vida de los pacientes
Comandos iniciados por dispositivo monitor

Comando
Respuesta esperada
AlarmaAmarilla AckAlarmaAmarilla
AlarmaRoja
AckAlarmaRoja
Comandos iniciados por tel

efono celular
Comando
Respuesta esperada
BorraMemoria
GetConfirmarBorrar
AckBorraMemoria
GetArchivos
SendingArchivo, SinArchivos
GetID
SendingID
GetInfoPaciente
SendingInfoPaciente
GetTemperatura
SendingTemp
StartDatosContinuos SendingDatos
StopDatosContinuos
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
Red WLAN Ancho de banda de hasta 54 Mbps
Mas economica
Red GPRS Cobertura muy amplia
Desventajas
Cobertura limitada
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 reenva 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 enva 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 envo 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 envo 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
Protocolo
de
transferencia
por Bluetooth
Telfono celular
Aplicacin monitor
de signos vitales
Dispositivo
Monitor
Protocolo
de
transferencia
por Internet
Servidor en centro
mdico
Aplicacin monitor
de signos vitales
Internet
Enlace
Bluetooth
Comunicaciones
Bluetooth
Comunicaciones
Internet
Comunicaciones
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 enva 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

Aplicacin en telfono celular
Transferencia
de archivo
Bluetooth
Presentacin
de datos
Autenticacin
Solicitud de llave
de sesin
Llave de
sesin
Archivo
de datos
Transferencia
de archivo por
Internet
Archivo
de datos
IAP
seleccionado
Integridad
y
confidencialidad
Internet
Archivo de
datos
cifrado
Mdulo de
handover
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 reenva 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:
M
odulo 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.
M
odulo de presentaci
on 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.
M
odulo de handover: El envo 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 economa 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.
M
odulo 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 envo de datos. Para efectuar
este envo 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.
M
odulo autenticaci
on: 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.
M
odulo 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 enva 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 aplicaci

on
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:
M
odulo 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.
M
odulo de autenticaci
on: 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
Aplicacin en centro mdico
Presentacin
de datos
Autenticacin
Llave de
sesin
Llave de
sesin
Internet
Transferencia
de archivo por
Internet
Archivo de
datos
cifrado
Integridad
y
confidencialidad
Archivo
de datos
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 enva al cliente.
M
odulo 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.
M
odulo de presentaci
on 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 captulo 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
economa, comparada con la red celular GPRS. Una caracterstica importante de esta arquitectura
es que puede ser adaptada a diferentes aplicaciones y no solo al caso practico que se presenta.
En el siguiente captulo se presentaran con detalle las tres principales funciones de la arquitectura:
comunicaciones, handover vertical y seguridad.
4
Comunicaciones
La arquitectura que se propuso en el captulo 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
captulo 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 enva un mensaje al otro
dispositivo para indicarle que quiere establecer un canal de comunicacion. Los dos dispositivos se
envan 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 lmite. En este
protocolo se utilizan tres tipos de tiempos de espera, largos, medianos y cortos, el tipo de tiempo
de espera depende del comando del protocolo. Los tiempos de espera largo y mediano se utilizan
4. Comunicaciones
43
Protocolo de transferencia
API de sockets
RFCOMM
L2CAP
Figura 4.1: Ubicacion de protocolo de transferencia por Bluetooth
en los comandos de alarma y el tiempo de espera corto se utiliza en todos los comandos, como se
explica mas adelante en esta seccion. En esta implementacion del protocolo el tiempo de espera
largo se definio de 300 segundos, el mediano de 60 segundos y el corto de 5 segundos aunque estos
valores pueden ser configurados de manera diferente. Cuando hay perdida de mensajes o cuando se
presentan errores de comunicacion, el mecanismo de recuperacion de errores del protocolo suspende
completamente la transferencia del archivo para permitir que el telefono celular y el dispositivo
monitor se sincronicen de nuevo. Una vez sincronizados los dispositivos, la transferencia del archivo
se reanuda desde el inicio. Este mecanismo de recuperacion es simple pero suficiente para garantizar
que la transferencia de los archivos se lleve a cabo con exito.
El protocolo de transferencia esta colocado sobre el protocolo de transporte RFCOMM como se
muestra en la Figura 4.1. El protocolo RFCOMM emula los parametros de un cable de serie y el
estado de un puerto RS-232 para transmitir datos en serie. El protocolo RFCOMM se conecta a las
capas inferiores de la pila de protocolos Bluetooth a traves de la capa L2CAP [16]. La capa L2CAP
proporciona servicios de datos sin conexion y orientados a conexion y segmentacion y re-ensamble
de paquetes, entre otros servicios [22]. Entre de la capa RFCOMM y el protocolo de transferencia
se encuentra una capa con una API de sockets. Se utilizo un modelo de sockets para facilitar el
44
4.1. Comunicaciones
desarrollo del protocolo de transferencia y al mismo tiempo hacer mas portable este desarrollo. El
conjunto mnimo 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.
AlarmaAmarilla
Dispositivo
monitor
AckAlarmaAmarilla
Celular
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 crtico.
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.
Dispositivo
monitor
Celular
AckAlarmaAmarilla
AlarmaAmarilla
Enva
AlarmaAmarilla
Espera
AckAlarmaAmarilla
Estado Inicial
Espera
comandos
Enva
AckAlarmaAmarilla
Timeout (300 seg.)
Figura 4.3: Procesamiento del comando AlarmaAmarilla
En una situacion real los mensajes que se intercambian entre el dispositivo monitor y el telefono
4. Comunicaciones
45
celular pueden no llegar a su destino, el protocolo de transferencia toma en cuenta esta situacion y
define estados de espera como se muestra en el diagrama de la Figura 4.3. El problema de los mensajes
perdidos se soluciona introduciendo tiempos de espera lmite (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 lmite
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.
AlarmaRoja
Dispositivo
monitor
AckAlarmaRoja
Celular
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 crtico. 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 lmite mediano, el dispositivo monitor vuelve a emitir la alarma. El telefono celular por su parte
inicialmente esta en un estado de espera infinito esperando comandos de alarma, cuando se recibe
46
4.1. Comunicaciones
Dispositivo
monitor
Celular
AckAlarmaRoja
Enva
AlarmaRoja
Espera
AckAlarmaRoja
Estado Inicial
AlarmaRoja
Espera
comandos
Enva
AckAlarmaRoja
Timeout (60 seg.)
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 lmite 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.
BorraMemoria
Celular
GetConfirmarBorrar
Dispositivo
monitor
AckBorraMemoria
Figura 4.6: Intercambio de mensajes de comando BorraMemoria
Comando BorraMemoria: El comando BorraMemoria es emitido por el telefono celular. Este

comando le indica al dispositivo monitor que elimine de su memoria interna los archivos con los
datos de las senales electricas cardiacas. Suponiendo un ambiente libre de errores de transmision, el
intercambio de mensajes de este comando se hace como se muestra en la Figura 4.6. El telefono
emite el comando BorraMemoria y el dispositivo monitor responde con el comando de solicitud
4. Comunicaciones
47
de confirmacion de borrado GetConfirmarBorrar, el telefono al recibir la solicitud de confirmacion

responde con el comando de confirmacion de borrado AckBorraMemoria, el dispositivo monitor al
recibir la confirmacion del borrado procede a eliminar los archivos de datos.
Celular
Dispositivo
monitor
GetConfirmarBorrar
BorraMemoria
Enva
BorraMemoria
Espera
GetConfirmBorrar
Enva
AckBorraMemoria
Espera
comandos
Enva
GetConfirmarBorrar
Timeout
Timeout
Estado
inicial
Borra
memoria
Espera
AckBorraMemoria
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 lmite 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 enva 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 lmite 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 enve al telefono celular los datos personales del
48
4.1. Comunicaciones
paciente tales como, nombre, edad, peso, etc. El intercambio de mensajes del comando sin considerar
los posibles errores en la comunicacion se muestra en la Figura 4.8.
GetInfopaciente
Celular
SendingInfoPaciente
Dispositivo
monitor
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 lmite 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 envo de los datos del paciente y posteriormente enva estos datos.
Dispositivo monitor
Celular
SendingInfoPaciente
GetInfoPaciente
Enva
GetInfoPaciente
Espera
SendingInfoPaciente
Recibe
datos
del paciente
Espera
comandos
Timeout
Estado
inicial
Figura 4.9: Procesamiento del comando GetInfoPaciente
Enva
SendingInfoPaciente,
datos del paciente
4. Comunicaciones
49
GetID
Celular
Dispositivo
monitor
SendingID
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.
Celular
Dispositivo
monitor
SendingID
GetID
Enva
GetID
Espera
SendingID
Recibe
modelo, serie,
versin
firmware
Espera
comandos
Enva
SendingID,
modelo, serie,
ver. firmware
Timeout
Estado
inicial
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 envo de cada archivo no se hace en una sola operacion sino que se hace
50
4.1. Comunicaciones
GetTemperatura
Celular
SendingTemperatura
Dispositivo
monitor
Figura 4.12: Intercambio de mensajes de comando GetTemperatura
Celular
Dispositivo
monitor
SendingTemp
GetTemperatura
Enva
GetTemperatura
Espera
SendingTemp
Timeout
Recibe
temperatura
Espera
comandos
Timeout
Estado
inicial
Figura 4.13: Procesamiento del comando GetTemperatura
Enva
SendingTemp
4. Comunicaciones
51
por bloques. El telefono celular emite el comando GetArchivos, el dispositivo puede responder con el
comando SendingArchivo si hay archivos en el dispositivo, seguido del archivo que se enva, o con el
comando SinArchivos, si no hay archivos en el dispositivo.
GetArchivos
SendingArchivo
Celular
GetArchivos
bloque de datos
Dispositivo
monitor
Celular
SinArchivos
BloqueRecibido
Dispositivo
monitor
. . .
FinArchivo
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 envo y recepcion de cada archivo dentro del comando
GetArchivos. Despues de que el telefono envio el comando GetArchivos entra en un estado de espera,
en este estado se puede recibir un comando SendingArchivo, si el dispositivo va a enviar un archivo, o
un comando FinTransmision si el dispositivo ya envio todos los archivos. Si no se recibe una respuesta
en un tiempo de espera corto, el telefono celular pasa a un estado de espera para sincronizarse con
el dispositivo monitor y despues vuelve a emitir el comando GetArchivos. Si se recibio un comando
SendingArchivo, el telefono pasa a un estado en donde se reciben los bloques que forman un archivo,
de este estado se sale si se excede el tiempo de espera de algun bloque o si recibe el comando
52
4.1. Comunicaciones
Celular
GetArchivos
Enva
GetArchivos
Siguiente
archivo
Recibe
archivo
Espera
comandos
Dispositivo
monitor
Si hay
archivos
Obten
lista de archivos
Enva
Archivo
No hay
archivos
SinArchivos /
FinTransmisin
Estado
Inicial
Enva
FinTransmisin
Envia
SinArchivos
Obten
siguiente
archivo
No hay mas
archivos
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 enva al dispositivo el comando ArchivoRecibido para confirmar
la recepcion. En el dispositivo por su parte cuando se recibe el comando GetArchivos se enva 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 envo 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 enva 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 enve 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 enva al telefono el comando SendingDatosContinuos.
4. Comunicaciones
53
Dispositivo
monitor
Celular
GetArchivos
SendingArchivo
Espera
SendingArchivo/
FinTransmisin
Estado
inicial
Recibe
Bloques
Espera
comandos
Enva
SendingArchivo
Enva
Bloques
TimeOut
FinTransmisin
Envia
GetArchivos
Estado
de espera
TimeOut
FinArchivo
Estado
de espera
Error
Fin de
Archivo
Timeout
Enva
ArchivoRecibo
Obten
siguiente
archivo
Espera
ArchivoRecibido
Enva
FinArchivo
ArchivoRecibido
Figura 4.16: Procesamiento de enva/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 enva el comando SendingDatosContinuos para
indicarle al telefono que se va a iniciar el envo de las senales electricas cardiacas, y posteriormente
hace el envo 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 vara dependiendo del tipo de comando. Los formatos de los mensajes de los
comandos que no contiene informacion adicional como los de alarma y el comando de borrado tiene
una longitud de un byte como se muestran en la figura 4.19.
54
4.1. Comunicaciones
StartDatosContinuos
SendingDatos
Celular
Dispositivo
monitor
SendingDatos
. . .
StopDatosContinuos
Figura 4.17: Intercambio de mensajes de comando StartDatosContinuos
Celular
Dispositivo Monitor
StartDatosContinuos
Recibe
datos continuos
Enva
StartDatosContinuos
Espera
comandos
Enviar
SendingDatos
SendingDatos
Timeout/
StopDatosContinuos
Estado
inicial
StopDatosContinuos/
TimeOut
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 envo 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 enva en bloques, la longitud del bloque utilizado por el comando GetArchivos para el envo
de datos es de 667 bytes. Como se explicara mas adelante en el captulo 5, este valor se escogio por
que es el que ofrece el mejor balance entre tiempos de transmision razonables y menor numero de
4. Comunicaciones
55
05
1 byte
AlarmaAmarilla
0A
1 byte
AckAlarmaAmarilla
0F
1 byte
AlarmaRoja
14
1 byte
AckAlarmaRoja
19
1 byte
BorraMemoria
1E
1 byte
GetConfirmarBorrar
20
1 byte
AckBorraMemoria
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
Comunicaci
on entre tel
efono celular y servidor de aplicaci
on 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 envo de archivos entre el telefono celular y
el servidor de aplicacion a traves de Internet se desarrollo un protocolo de transferencia de archivos
basado en el protocolo TCP/IP. Este protocolo esta ubicado sobre el protocolo de transporte TCP
de la pila de protocolos TCP/IP (Figura 4.23). TCP comprueba que ningun segmento se ha perdido
dando a cada uno un numero de secuencia, que es tambien usado para asegurarse de que los paquetes
56
4.1. Comunicaciones
78
1 byte
7D
Informacin del paciente

1 byte
GetInfoPaciente
245 bytes
SendingInfoPaciente
244 bytes
Nombre
Fecha de nacimiento
Edad
Estatura
Peso
Tipo de sangre
Alergias
CURP
Contacto
Informacin de doctor
Otros datos
50
8
4
4
4
4
12
16
12
50
80
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
bytes
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 envo verifica si el
reconocimiento no es recibido en un tiempo de espera lmite, y el paquete sera entonces retransmitido.
TCP revisa que no haya bytes danados durante el envo usando un checksum; este es calculado por
el emisor en cada paquete antes de ser enviado, y comprobado por el receptor.
El protocolo de transferencia de archivos por Internet es similar al utilizado en la comunicacion
entre el dispositivo monitor y el telefono celular. La principal diferencia se encuentra en el mecanismo
de recuperacion de errores de comunicacion durante la transferencia de archivos. El protocolo de
transferencia por Internet mantiene el estado de la transferencia, de esta manera es posible incorporar
un mecanismo de recuperacion de errores mas eficiente. Si la transferencia del archivo se interrumpe,
esta se reanuda en el punto en el que se interrumpio. Este esquema de recuperacion de errores
es necesario debido a que las interrupciones en la transferencia de datos se pueden presentar con
mas frecuencia en este protocolo. Aunque tanto GPRS como Wi-Fi proporcionan una comunicacion
mas confiable que Bluetooth, las interrupciones en la transferencia de datos se pueden presentar no
solo por errores de transmision sino por el cambio de red de comunicacion que produce el modulo
de handover vertical que forma parte de la arquitectura. Como se explica mas detalladamente en
4. Comunicaciones
57
28
1 byte
GetArchivos
2D
1 byte
SinArchivos
32
Encabezado del archivo

1 byte
142 bytes
SendingArchivo
141 bytes
Nombre
128 bytes
Fecha y hora
7 bytes
2 bytes
Modo de almacenamiento
2 bytes
Derivacin usada
Frecuencia de muestreo EGG
2 bytes
Figura 4.21: Formato de mensajes del comando GetArchivos

Comandos Iniciados por celular
ENVIA ARCHIVO
RETRANSMITE ARCHIVO
EOF
Bloque de datos
Respuesta del servidor

COMANDO RECIBIDO
Ultimo
bloque recibido
EOF RECIBIDO
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 sera 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 sera deseable
conservar la parte del archivo que ya se ha transferido para ahorrar costos. En este protocolo solo
se usa un tiempo de espera lmite para resolver el problema de los mensajes perdidos para todos los
comandos. El tiempo de espera lmite usado en esta implementacion es de 5 segundos.
La implementacion de las alarmas y de los demas comandos del protocolo de comunicacion entre
el dispositivo monitor y el telefono celular es posible tambien realizarla sin problema en este protocolo
de transferencia por Internet, sin embargo solo se ha implementado la transferencia de archivos por
ser la operacion mas compleja y la que tiene mayor relevancia.
Al igual que en el protocolo para transferencia de archivos por Bluetooth, en el desarrollo de
58
4.1. Comunicaciones
6E
1 byte
73
Temperatura
GetTemperatura
2 bytes
SendingTemp
1 byte
82
1 byte
87
Informacin de identificacin
GetID
61 bytes
SendingID
60 bytes
1 byte
Modelo
Nmero de serie
Versin de firmware
40 bytes
10 bytes
10 bytes
50
1 byte
StartDatosContinuos
55
1 byte
SendingDatos
5A
1 byte
StopDatosContinuos
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 envo de archivos hacia el servidor. El comando
ENVIA ARCHIVO le indica al servidor de aplicacion que un cliente (telefono celular) desea iniciar una
sesion de transferencia para enviar un archivo hacia el servidor. Este comando inicia una secuencia de
4. Comunicaciones
59
Protocolos de
aplicacin
Ftp, Telnet, SMTP
Protocolo de
transferencia
desarrollado
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 enve 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 envan
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
lmite. Cuando se alcanza el fin del archivo que se esta enviando, el telefono emite el comando EOF
para indicarle al servidor que termino el envo de bloques de datos y el telefono entonces entra en un
estado de espera para recibir el comando EOF RECIBIDO, cuando el comando se recibe, el telefono
pasa a su estado inicial, si el comando no se recibe se pasa al estado de espera para sincronizarse con
60
4.1. Comunicaciones
ENVIA_ARCHIVO
COMANDO_RECIBIDO
bloque 1
Celular
BLOQUE_RECIBIDO
Servidor de aplicacin
. . .
bloque n
EOF
EOF_RECIBIDO
Figura 4.24: Intercambio de mensajes de comando ENVIA ARCHIVO
el servidor de aplicacion y reiniciar la transmision del archivo. El servidor de aplicacion por su parte
esta esperando recibir comandos, cuando recibe el comando ENVIA ARCHIVO, el servidor le confirma
al telefono la recepcion del comando emitiendo a su vez el comando COMANDO RECIBIDO y pasa
a un estado en donde se reciben los bloques de datos, a cada bloque recibido el servidor responde
con un mensaje de confirmacion BLOQUE RECIBIDO, de este estado se sale si recibe el comando
EOF o si se presenta algun error en la recepcion de los bloques. Si se recibio el comando EOF el
servidor emite el comando EOF RECIBIDO para confirmarle al telefono que recibio el comando EOF.
Si hubo algun error en la recepcion de bloques, el servidor pasa a un estado para salvar el estado de
la transferencia y despues pasa a un estado de espera para sincronizarse con el telefono.
El comando RETRANSMITE ARCHIVO: En general este comando es muy similar al
comando ENVIA ARCHIVO. El comando RETRANSMITE ARCHIVO es enviado por el telefono
y le indica al servidor que la transferencia de un archivo fallo y que se va a reiniciar en el punto en
que se interrumpio. Esto se logra porque al presentarse un error en la recepcion de algun bloque de
datos en el servidor, se salva el consecutivo del ultimo bloque que se recibio correctamente. En la
Figura 4.26 se muestra el intercambio de mensajes del comando, este intercambio es practicamente
4. Comunicaciones
61
Celular
ENVIA_ARCHIVO
COMANDO_RECIBIDO
Emite
ENVIA_ARCHIVO
Espera
COMANDO_RECIBIDO
Espera
comandos
Enva
Bloques
Enva
COMANDO_RECIBIDO
Recibe
Bloques
TimeOut
TimeOut
Fin de
archivo
Error
Estado
de espera
Guarda
estado de
transferencia
Estado
de espera
EOF
Enva
EOF
Estado
inicial
Timeout
Enva
EOF_RECIBIDO
Espera
EOF_RECIBIDO
EOF_RECIBIDO
Figura 4.25: Procesamiento del comando ENVIA ARCHIVO
RETRANSMITE_ARCHIVO
ltimo bloque recibido

bloque n + 1
Celular
BLOQUE_RECIBIDO
. . .
bloque m
EOF
EOF_RECIBIDO
Figura 4.26: Intercambio de mensajes de comando RETRANSMITE ARCHIVO
62
4.1. Comunicaciones
igual al del comando ENVIA ARCHIVO, la unica diferencia es que en respuesta al comando
RETRANSMITE ARCHIVO, el servidor responde con el consecutivo del ultimo bloque recibido y
no con una confirmacion.
Celular
RETRANSMITE_ARCHIVO
ltimo bloque recibido
Espera
ltimo bloque
recibido
Emite
RETRANSMITE_ARCHIVO
TimeOut
Espera
comandos
Enva
Bloques
Recibe
Bloques
Enva
ltimo bloque
recibido
Error
TimeOut
Fin de
archivo
Estado
de espera
Guarda
estado de
transferencia
Estado
de espera
EOF
Enva
EOF
Estado
inicial
Timeout
Enva
EOF_RECIBIDO
Espera
EOF_RECIBIDO
EOF_RECIBIDO
Figura 4.27: Procesamiento del comando RETRANSMITE ARCHIVO
El funcionamiento del comando RETRANSMITE ARCHIVO en una situacion real se muestra

en la Figura 4.27, aqu tambien se observa que la unica diferencia con respecto al comando
ENVIA ARCHIVO es que el servidor responde al comando con el consecutivo del ultimo bloque
recibido y no con una confirmacion.
Formato de mensajes: Los comandos del protocolo se codifican por medio de un numero de 8
bits. En la Figura 4.28 se muestran los formatos de los mensajes del protocolo, todos los mensajes
de los comandos son de 1 byte de longitud excepto el comando ENVIA ARCHIVO, que tiene una
longitud de 256 bytes. El mensaje que contiene el bloque de datos esta formado por dos partes como
se muestra en la Figura 4.29, la primera es un numero consecutivo de bloque de 4 bytes, la segunda
es el bloque de datos el cual puede variar de 256 a 4096 bytes.
4. Comunicaciones
10h
63
256 bytes
Nombre de archivo
ENVIA_ARCHIVO
255 bytes
20h
1 byte
RETRANSMITE_ARCHIVO
30h
1 byte
COMANDO_RECIBIDO
FFh
1 byte
EOF
40h
1 byte
EOF_RECIBIDO
Figura 4.28: Formato de mensajes de comandos del protocolo
Nmero de bloque
4 bytes
Bloque de datos
256 a 4096 bytes
Figura 4.29: Formato de mensaje de bloque de datos
4.2
Handover vertical GPRS/WLAN
En la mayora 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 hbrida 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 artculo de Song et al del 2007 [24] se propone un esquema de acoplamiento hbrido para
soportar trabajo conjunto entre redes UMTS y WLAN que distingue las rutas del trafico de acuerdo al
4. Comunicaciones
65
tipo de trafico. Para trafico de tiempo real se escogio la arquitectura de red estrechamente acoplada.
Para trafico de tiempo no real se utilizo la arquitectura debilmente acoplada. En el esquema de
acoplamiento hbrido 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 artculo 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 caracterstica llamada multi-homing, esta
caracterstica permite agregar la interfaz sin importar si la interfaz en el extremo de la red pertenece
a la misma tecnologa, 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 energa de la red
UMTS. El sistema intenta determinar proactivamente a cual punto de acceso WLAN o estacion base
UMTS cambiara el usuario y cuando debera 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
fsica mediante un prototipo.
La mayora 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 mayora no se
66
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
difcil 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 poltica de seleccion. El algoritmo que se utiliza en el proceso de busqueda de la mejor red de
acceso a Internet se muestra mas claramente con el diagrama de la Figura 4.33. La plataforma de
handover desarrollada considera 3 escenarios en los que se puede presentar un cambio de red:
Cambio de red GPRS a WLAN: Cuando el telefono celular esta accediendo a Internet por
medio de la red GPRS, e ingresa al area de cobertura de una red WLAN en la cual el telefono
esta registrado como usuario, como se muestra en la Figura 4.30, se puede presentar un cambio de
red de GPRS a WLAN. Este cambio de red no se da inmediatamente despues de que la red WLAN se
detecta, para asegurar que la conexion sea estable, el cambio se da cuando la potencia de la senal de
4. Comunicaciones
67
Telfono celular
Red inalmbrica
Red GSM
GPRS
Figura 4.30: Cambio de red de GPRS a WLAN
la red WLAN alcanza un valor mnimo - 75 dBm, este valor se determino por medio de pruebas que
se realizaron. En estas pruebas se encontro experimentalmente que el valor mnimo 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.
Telfono celular
Red GSM
GPRS
Red inalmbrica
Figura 4.31: Cambio de red de WLAN a GPRS
Cambio de red WLAN a GPRS: Las redes WLAN tiene una cobertura que se limita a unos
cuantos metros del punto de acceso, cuando el telefono celular sale del area de cobertura de una red
68
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 mnima 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.
Telfono celular
Red inalmbrica 1
Red inalmbrica 2
Figura 4.32: Cambio de red de WLAN a WLAN
Cambio de red WLAN a WLAN: En edificios grandes o en instalaciones muy extensas tales
como universidades o aeropuertos es comun que el servicio de Internet inalambrico se proporcione por
medio de varias redes WLAN cuyas coberturas en algunos puntos se traslapan. Cuando se presenta
un escenario como este, el cambio se da de una red WLAN a otra, como se muestra en la Figura 4.32.
Este cambio se puede efectuar bajo dos condiciones: cuando se pierde la senal de la red WLAN que
se esta utilizando actualmente y de la que se esta alejando el telefono celular, o cuando se detecta
que la senal de la red hacia la que se esta moviendo el telefono es mas potente que la senal de la
red que se esta utilizando actualmente.
En el Apendice B en la pagina 123, se describen las principales funciones utilizadas en la
implementacion del mecanismo handover.
4. Comunicaciones
69
Inicio
WLAN
disponible?
SI
Hay ms
de una red
disp.?
SI
Seleccionar red
WLAN de mayor
potencia
NO
NO
Regresar red
de acceso
seleccionada
Seleccionar red
WLAN disponible
GPRS
disponible?
SI
Seleccionar
GPRS como
red de acceso
NO
Sin conexin
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 caractersticas. Si bien es cierto que existen otros servicios dentro del sistema de monitoreo
de signos vitales, el servicio de transferencia de archivos es el unico que merece la integracion del
mecanismo de handover por las razones que se expusieron anteriormente.
El objetivo del modulo del handover vertical es proporcionar el mejor medio de acceso a Internet
durante la transferencia de archivos. Antes de iniciar la transferencia de archivos desde el celular al
70
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 p
erdida de se
nal: Como se muestra en la Figura 4.35 cuando se detecta
un error de transmision debido a la perdida de senal de la red que se esta usando en el telefono
celular el protocolo responde con el mecanismo de recuperacion de errores, este a su vez invoca al
modulo de handover para proporcionar la nueva mejor red de comunicacion. Del lado del telefono
celular la conexion es cerrada y se entra a un estado de espera para sincronizar el telefono celular
con el servidor de aplicacion, una vez que estan sincronizados se abre una conexion con la nueva
mejor red disponible. Cuando el telefono celular establece la sesion de transferencia con el servidor,
verifica si hay alguna transferencia en curso revisando el valor de la variable que almacena el numero
del ultimo bloque enviado, si este es diferente de cero significa que no se completo la transferencia
del archivo y se emite el comando RETRANSMITE ARCHIVO y entra en un estado de espera del
numero consecutivo del ultimo bloque que recibio el servidor. El servidor de aplicacion por su parte
4. Comunicaciones
71
ENVIA_ARCHIVO
COMANDO_RECIBIDO
bloque 1
BLOQUE_RECIBIDO
. . .
handover
RETRANSMITE_ARCHIVO
Celular
ltimo bloque recibido n
bloque n +1
BLOQUE_RECIBIDO
. . .
EOF
EOF_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 enva 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
caractersticas 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

Celular
Error
Handover
Error
salva
ltimo bloque
recibido
Recibe
Bloques
Cierra conexin
y sincroniza
Enva
Bloques
EOF
Fin de
archivo
Abre
nueva conexin
Enva
EOF
nmero de ltimo
bloque recibido
Espera
nmero de ltimo
bloque recibido
Enva
ltimo bloque
recibido
Cierra conexin
y sincroniza
Enva
EOF_RECIBIDO
RETRANSMITE_ARCHIVO
Emite
RETRANSMITE_ARCHIVO
Espera
comandos
Espera solicitud
de conexin
Figura 4.35: Proceso de handover durante transferencia de archivo
archivo se produce un error de comunicacion, es de esta forma en la que el protocolo es enterado del
cambio de red. El protocolo responde a este error con el mecanismo de recuperacion de errores que se
explico anteriormente. El error de comunicacion en este caso es producido por el propio mecanismo de
handover al abortar la transferencia. Despues de que se restablece la comunicacion entre el telefono
celular y el servidor de aplicacion la transmision del archivo se reanuda de la misma manera que en
el caso anterior. Este proceso de cambio de red ocurre cuando el telefono celular entra en el area
de cobertura de alguna red inalambrica. En esta implementacion la busqueda de redes disponibles
es un proceso que se repite cada 5 segundos, pero este tiempo puede ser configurado con un valor
diferente.
4.3
Servicios de seguridad
La plataforma de handover vertical fue pensada como una capa colocada entre las interfaces
de comunicacion del telefono celular y las aplicaciones para el usuario final. Debido que muchas
aplicaciones que acceden a Internet intercambian informacion confidencial como datos personales,
4. Comunicaciones
73
Aplicaciones que acceden a

Internet
Mdulo de
Handover
Confidencialidad
AES
Integridad
SHA-1
Sistema Operativo
Interfaz
GPRS
Interfaz
Wi-Fi
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 sera
conveniente que la plataforma tuviera un modulo que proporcionara servicios de seguridad, el cual
estara 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 enva 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 podra tener consecuencias
graves en la salud del paciente. El modulo de seguridad establece un canal de comunicacion seguro
entre el telefono celular y el servidor de aplicacion para garantizar que esta informacion no sea sujeta
a espionaje o a manipulacion mal intencionada, este canal se establece, primero garantizando la
autenticidad de la informacion procedente del telefono celular, posteriormente cifrando los datos
durante la transferencia de datos entre el celular y el servidor de aplicacion para que no puedan ser
74
Servidor de
aplicacin
Solicitud de
llave de sesin
Llave de sesin
Y
Centro de
distribucin
de llaves
Solicitud de
llave de sesin
Llave de sesin
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
Autenticaci
on
Un componente del modulo de servicios de seguridad es el modulo de distribucion de llaves de

sesion. Este modulo se encarga de distribuir entre el cliente y el servidor las llaves de sesion necesarias
para el cifrado de datos, como se muestra en la Figura 4.37. Ademas, el protocolo de gestion de
las llaves de sesion realiza la funcion de autenticacion. Bajo este esquema el servidor de aplicacion
actua como un centro de distribucion de llaves de sesion y al mismo tiempo autentica al telefono
celular cuando este desea establecer una sesion de transferencia. La autenticacion implementada
solo se realiza en un sentido, el servidor de aplicacion autentica al telefono celular pero el telefono
celular no autentica al servidor de aplicacion. La autenticacion se da en un solo sentido debido a que
la aplicacion que se desarrollo para evaluar la plataforma solo transfiere archivos desde el telefono
celular hacia el servidor de aplicacion, no se efectua transferencia de archivos ni hacia el telefono
celular, ni entre dos telefonos celulares que forman parte del sistema. Por lo tanto no se justifica tener
4. Comunicaciones
75
un centro de distribucion de llaves separado del servidor de aplicacion. El proceso de distribucion de

llaves se sesion asume que tanto el cliente como el servidor comparten una llave secreta la cual fue
previamente distribuida de alguna forma. Las llaves de sesion distribuidas son usadas solo por un
tiempo limitado para protegerlas. En esta implementacion el tiempo de vida de una llave de sesion
se fijo en 1 da.
(1) Solicitud || N1
Cliente
A
Servidor
B
(2) Llave de sesin cifrada
con llave maestra
(3) f(N2) cifrado con

llave de sesin
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 respuesta
incluye la llave de sesion seleccionada por B, un identificador de B, el valor f (N1 ) y otra
palabra 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 enva a B un mensaje con una solicitud para obtener una llave de sesion, el mensaje incluye
76
la identificacion de A y una palabra unica N1 , este mensaje se enva 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 da 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 enva al cliente. Si el
cliente no se encuentra registrado en el archivo de llaves privadas se enva 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 dgitos, este numero es convertido entonces a una
cadena de caracteres, y a esta cadena se la aplica la funcion hash MD5, el resultado que regresa la
funcion MD5 es siempre un resumen de 16 bytes, y este valor se convierte entonces en la llave de
sesion.
4. Comunicaciones
4.3.2
77
Confidencialidad
La criptografa 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 mayora 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 N b. La llave de cifrado es igualmente representada
como un arreglo rectangular con cuatro filas. El numero de columnas de la llave de cifrado, denotada
N k, es igual a la longitud de la llave dividida por 32.
78

Longitud de Llave
(N k palabras)
AES-128
4
AES-192
6
AES-256
8
Tama
no de bloque
(N b palabras)
4
4
4
N
umero de rondas
(N r)
10
12
14
Tabla 4.2: Combinaciones Llave-Bloque-Ronda

Especificaci
on 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 N b = 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 N k = 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 N r, donde N r = 10
cuando N k = 4, N r = 12 cuando N k = 6, y N r = 14 cuando N k = 8.
Las unicas combinaciones Llave-Bloque-Ronda que estan permitidas en el estandar se muestran en
el Cuadro 4.2. Durante cada ronda tanto del cifrador como del descifrador, el algoritmo AES aplica
una ronda de transformacion que esta compuesta de cuatro diferentes transformaciones:
1. Substitucion de bytes usando una tabla de substitucion (S-box)
2. Cambio de filas en el arreglo de Estado
3. Mezcla de los datos dentro de cada columna del arreglo de Estado
4. Adicion de una Llave de Ronda al Estado
Cifrado
Al inicio del cifrado la entrada es copiada al arreglo de Estado. Despues de una adicion inicial de
Llave de Ronda el arreglo de Estado es transformado implementando una ronda de transformacion
4. Comunicaciones
79
Inicio
Estado = entrada
AddRoundKey
Ronda = 1
Ronda = Ronda + 1
Ronda <= Nr - 1
NO
ltima
Ronda
SI
SubBytes
SubBytes
ShiftRows
ShiftRows
MixColumns
AddRoundKey
AddRoundKey
salida = Estado
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 N r 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 N r rondas
son identicas, con excepcion de la ronda final, la cual no incluye la transformacion MixColumns().
La transformacion SubBytes() es una transformacion no lineal de sustitucion de bytes que opera
80
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 cclicamente 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 N b palabras del calendario de llaves. Estas N b palabras
son sumadas cada una a las columnas del Estado.
Expansi
on 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 N b(N r + 1) palabras:
el algoritmo requiere un conjunto inicial de N b palabras, y cada una de las N r rondas requiere
N b 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 < N b(N r + 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 especfico de este trabajo de tesis, los datos solo fluyen desde al cliente hacia
el servidor pero no viceversa. Por lo tanto el cliente cifra los datos por bloque antes de enviarlos al
servidor y el servidor los descifra despues de recibirlos para restaurarlos a su condicion original.
El protocolo de transferencia de archivos divide el archivo de datos en bloques para ser enviado
4. Comunicaciones
81
Inicio
Estado = entrada
AddRoundKey
Ronda = Nr - 1
Ronda = Ronda - 1
Ronda = 1
NO
ltima
Ronda
SI
InvShiftRows
InvShiftRows
InvSubBytes
InvSubBytes
AddRoundKey
InvMixColumns
AddRoundKey
salida = Estado
Figura 4.40: Algoritmo de descifrado AES
desde el telefono celular hacia el servidor de aplicacion. En esta implementacion se utilizaron diferentes
tamanos de bloque, los cuales van desde los 256 bytes hasta 4 Kb, sin embargo el algoritmo de cifrado
AES solo puede cifrar bloques de exactamente 16 bytes. Cuando el tamano del bloque de datos a
cifrar es mayor de 16 bytes no es posible cifrarlo en una sola operacion. En este caso el ciframiento
se hace por partes como se muestra en la Figura 4.41. Este es un proceso iterativo en donde se
toman los primeros 16 bytes y se cifran, y el resultado se almacena en un buffer, luego se prosigue
con los siguientes 16 bytes, y el resultado se agrega a los bytes previamente cifrados, y se continua
as hasta que se cifran los ultimos 16 bytes de bloque. El resultado de este proceso es un bloque de
datos cifrado que tiene un tamano mayor a 16 bytes. Como los tamanos de bloque se seleccionaron
de manera que fueran multiplos de 16 bytes, no se tiene ningun problema con fragmentos de bloque
82
Fragmento de 16 bytes 1
Bloque de datos
original
Fragmento de 16 bytes n
Cifrador
AES
Bloque de datos
cifrado
Fragmento de 16 bytes n
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
enva 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 funci
on SHA-1
SHA-1 es un algoritmo iterativo, esta funcion puede procesar un mensaje para producir una
4. Comunicaciones
83
Confidencialidad
Cifrado
AES
Integridad
Transferencia
de archivo
SHA1
Resumen
Enva
resumen
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
SHA-1
SHA-256
SHA-384
SHA-512
Tama
no de
mensaje
(bits)
<264
<264
<2128
<2128
Tama
no de
bloque
(bits)
512
512
1024
1024
Tama
no de
palabra
(bits)
32
32
64
64
Tama
no de
resumen
(bits)
160
256
384
512
Seguridad
(bits)
80
128
192
256
Tabla 4.3: Propiedades de los algoritmos de hash seguro

El algoritmo puede ser descrito en dos etapas: preprocesamiento y calculo del hash. El
preprocesamiento involucra el relleno de un mensaje, el analisis del mensaje rellenado en bloques
de m bits y el establecimiento de valores de inicializacion que se utilizaran en el calculo del hash. El
calculo del hash genera un calendario de mensaje a partir del mensaje rellenado y usa ese calendario,
junto con funciones, constantes, y operaciones de palabra para generar iterativamente una serie de
valores hash. El valor hash final generado por el calculo del hash se usa para determinar el resumen
del mensaje.
84

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
(i)
como dieciseis palabras de 32 bits, los primeros 32 bits del bloque de mensaje i son denotados M0 ,
(i)
(i)
los siguientes 32 bits son M1 , y as sucesivamente hasta M15 . 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:
(0)
H0 = 67452301
(0)
H1 = ef cdab89
(0)
H2 = 98badcf e
(0)
H3 = 10325476
(0)
H4 = c3d2e1f 0
C
alculo del hash
El algoritmo SHA-1 puede ser usado para procesar un mensaje, M , de l bits de longitud, donde
0 l < 264 . El algoritmo usa 1) un calendario de mensaje de ochenta palabras de 32 bits, 2) cinco
variables de trabajo de 32 bits cada una, y 3) un valor hash de cinco palabras de 32 bits. El resultado
final de SHA-1 es un resumen de mensaje de 160 bits. Las palabras del calendario de mensajes son
4. Comunicaciones
85
inicio
i = 1
Fin
i<=N
i = i + 1
NO
SI
Prepara el calendario
de mensajes
Inicializa variables
de trabajo
t = 0
Calcula valores
hash intermedios
t <= 79
t = t + 1
NO
SI
Calcula funciones
lgicas
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
(N )
(N )
(N )
(N )
(N )
H0 kH1 kH2 kH3 kH4
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
Transferencia
de archivo
Confidencialidad
descifrado
AES
Recibe
resumen
Resumen recibido
Compara
resumenes
Resumen calculado
Integridad
Archivo
SHA1
Figura 4.44: Servicio de integridad en servidor de aplicacion
el resumen que genera la funcion SHA-1 se enva 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 enva 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 reenva el archivo de datos.
4.4
Resumen
En este captulo se presentaron los diferentes procesos de comunicacion de datos que forman
parte de la arquitectura de la plataforma de handover vertical. Se presentaron los dos protocolos
de comunicacion desarrollados, el primero para realizar la transferencia de archivos sobre un
enlace Bluetooh utilizando como protocolo de transporte a RFCOMM, el segundo para realizar
la transferencia de archivos a traves de Internet, a este protocolo se le incorporo un mecanismo
de recuperacion de errores el cual permite reanudar una transmision en el punto en el que
4. Comunicaciones
87
fue interrumpida. Se describio tambien el mecanismo de handover que permite hacer el cambio
automatico entre redes GPRS y WLAN, como una solucion a los problemas de costo y ancho de
banda de una conexion a Internet en un telefono celular. Se presento la implementacion de los servicios
de seguridad. Se describio el esquema de distribucion de llaves de sesion y el servicio de autenticacion
incorporado a este. Se describio el algoritmo de ciframiento AES el cual se utilizo para garantizar
la confidencialidad durante la transferencia de datos. Se describio la funcion de hash seguro SHA-1,
utilizada para verificar la integridad de los datos despues de la transmision. En el siguiente Captulo
se describiran las pruebas funcionales y de desempeno, y se mostraran los resultados obtenidos en
dichas pruebas.
5
Resultados
on el fin de demostrar la funcionalidad de la arquitectura propuesta y de los esquemas de

comunicacion descritos en el Captulo 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 enva la informacion
por medio de Internet a un servidor de aplicacion ubicado en un centro medico. En este captulo 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 haba interrumpido y se continuo la transferencia hasta que se completo el envo 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 tena 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 haba 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 tena 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 haba 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. Desempe
no de la plataforma
Nokia N91
25 m
Red Wlan B
2 m
Red Wlan A
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
Desempe
no 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 categoras:
Tiempo de handover
Tamano optimo de bloque de TCP
Tiempo de transferencia de archivo
Tiempos de cifrado/descifrado
Consumo de energa
5. Resultados
93
A continuacion se describe como se realizo cada una de las pruebas y se muestran los resultados
que se obtuvieron.
Tiempos de cambio de red WLAN a GPRS en Nokia N91

45
Tiempo de handover
40
35
Tiempo en seg.
30
25
20
15
10
5
0
20
40
60
80
100
Pruebas efectuadas
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 categora son:
Tiempo de handover WLAN/GPRS

Tiempo de handover GPRS/WLAN
Tiempo de handover WLAN/WLAN
94
5.2. Desempe
no de la plataforma
Tiempos de cambio de red GPRS a WLAN en Nokia N91

10
Tiempo de handover
9
8
Tiempo en seg.
7
6
5
4
3
2
1
0
20
40
60
80
100
Pruebas efectuadas
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 batera 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
Tiempos de cambio de red WLAN a WLAN en Nokia N91

2
Tiempo de handover
1.8
Tiempo en seg.
1.6
1.4
1.2
1
0.8
0.6
0
20
40
60
80
100
Pruebas efectuadas
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 batera del telefono celular completamente cargada. Esta prueba se realizo de la
siguiente manera:
1. Se creo una conexion de TCP con un servidor utilizando el punto de acceso GPRS en el puerto
18000
96
5.2. Desempe
no de la plataforma
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 tenan 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
Tamao ptimo de bloque para transferencia por WLAN en Nokia N91

35
Tiempo de transferencia
30
Tiempo en seg.
25
20
15
10
Tamao de bloque de TCP en KB
Figura 5.5: Tamano optimo de bloque de TCP usando red WLAN
5.2.2
Tama
no
optimo de bloque de TCP usando red WLAN
El objetivo de esta prueba fue determinar cual sera el tamano del bloque de datos para ser usado
en las operaciones con sockets de TCP que proporcionara el menor tiempo de transferencia de datos
entre el telefono celular y el servidor de aplicacion usando la red WLAN. Para efectuar esta prueba se
realizo la transferencia de un archivo de texto de 1 KB de longitud, este archivo se transfirio desde el
telefono celular hacia el servidor de aplicacion. Se utilizaron bloques de diferente tamano buscando
reducir el tiempo de transferencia, el tamano de los bloques vario de 256 bytes a 6 KB. Cada tamano
de bloque se probo 20 veces, la prueba se detuvo cuando el aumento en el tamano del bloque de
98
5.2. Desempe
no de la plataforma
datos de TCP ya no trajo una reduccion en el tiempo de transferencia. Los tiempos promedio de
transferencia para cada tamano de bloque se muestran en la Figura 5.5. Se encontro que el tamano
optimo de bloque es de 4 KB, con bloques de tamano mayor se obtiene una pequena reduccion en
el tiempo de transferencia pero tambien aumenta el numero de errores de transmision.
Tamao ptimo de bloque para transferencia por GPRS en Nokia N91

1000
900
Tiempo en seg.
800
700
600
500
400
300
200
20
40
60
80
100
Tamao de bloque de TCP en bytes
120
140
Figura 5.6: Tamano optimo de bloque de TCP usando red GPRS
5.2.3
Tama
no
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 Captulo 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 vara durante el da 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 da.
Comparativo de tiempos de cifrado/descifrado en Nokia N91

120
Tiempo de cifrado
Tiempo de descifrado
100
Tiempo en seg.
80
60
40
20
2
3
4
Tamao de archivo en MB
Figura 5.7: Grafica comparativa de tiempos de cifrado/descifrado
100
5.2. Desempe
no de la plataforma
5.2.4
Tiempos de cifrado/descifrado
Para efectuar esta prueba se dispuso de 8 archivos cuyos tamanos fueron desde los 128 KB
hasta los 5 MB. Cada uno de estos archivos se cifro 20 veces en el telefono celular para obtener el
tiempo promedio de cifrado. Para efectuar la prueba de tiempo de descifrado estos 8 archivos fueron
previamente cifrados y copiados al telefono celular, ah fueron descifrados 20 veces para obtener el
tiempo promedio de descifrado. En las pruebas de cifrado realizadas se encontro que la tasa de cifrado
promedio es de 47.89 KB/seg con una desviacion estandar de 1.4 KB/seg, lo cual demuestra que la
tasa de cifrado se mantiene mas o menos constante independientemente del tamano del archivo que
se esta cifrando. En las pruebas de descifrado se obtuvieron resultados similares, la tasa de descifrado
promedio fue de 50.00 KB/seg con una desviacion estandar de 2.29 KB/seg, se observo que la tasa
de descifrado es ligeramente mayor para los archivos cuyo tamano es mayor de 2 MB. En la Figura 5.7
se muestran los resultados de ambas pruebas, se observa que el tiempo de descifrado es ligeramente
menor que el tiempo de cifrado para cada uno de los archivos.
Tiempo promedio
de transferencia
en segundos
Tasa real de
transferencia
en KB/s
128 KB
256 KB
512 KB
1 MB
2 MB
3 MB
4 MB
5 MB
1.08
2.00
2.93
4.48
8.27
11.97
15.75
19.94
118.04
128.00
174.67
228.83
247.68
256.06
260.06
256.76
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.
Tiempos de transferencia de archivo sin servicios de seguridad usando WLAN

25
Tiempo en seg.
20
15
10
Figura 5.8: Tiempos de transferencia usando red WLAN
Para determinar el tiempo de transferencia y la tasa de transferencia se dispuso de 8 archivos cuyos

tamanos fueron desde los 128 KB hasta los 5 MB. Cada uno de estos archivos se envio 20 veces desde
el telefono celular hacia el servidor de aplicacion utilizando la red inalambrica y se midio el tiempo
que tomo enviar cada archivo. El tamano de bloque que se utilizo en la transferencia de archivo fue
de 4 KB, este fue el tamano optimo de bloque que se encontro para la red WLAN en las pruebas
que se describieron anteriormente. En la medicion del tiempo de transferencia no se consideraron
las operaciones de autenticacion, cifrado y calculo de la funcion hash. Con los tiempos medidos se
calcularon el tiempo promedio de transferencia y la tasa de transferencia real para cada tamano de
archivo. La tasa de transferencia real se calculo dividiendo el tamano del archivo en KB entre el
tiempo promedio de transferencia de ese archivo. Los resultados obtenidos se muestran en la Tabla
102
5.2. Desempe
no de la plataforma
5.1, se observa que la tasa de transferencia para archivos menores de 1 KB se encuentra alrededor de
los 128 KB/s y para archivos iguales o mayores de 1 KB se encuentra alrededor de los 256 KB/s. El
comportamiento de la tasa de transferencia es casi lineal para tamanos de archivo iguales o mayores
a 1 MB, esto se puede observar mejor en la Figura 5.8.
Tiempo promedio
de transferencia
en segundos
Tasa real de
transferencia
en KB/s
4 KB
8 KB
16 KB
32 KB
64 KB
128 KB
256 KB
20.74
44.41
83.77
159.58
287.80
519.42
905.65
0.19
0.18
0.19
0.20
0.22
0.24
0.28
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.
Tiempo promedio
de transferencia
Tiempo promedio
de transferencia
con servicios
Costo de servicios
de seguridad en
porcentaje
128 KB
256 KB
512 KB
1 MB
2 MB
3 MB
4 MB
5 MB
1.08 s
2.00 s
2.93 s
4.48 s
8.27 s
11.97 s
15.75 s
19.94 s
3.83 s
7.30 s
13.62 s
25.70 s
49.89 s
74.66 s
102.04 s
125.61 s
354.6 %
365.0 %
464.8 %
573.6 %
603.2 %
623.7 %
647.8 %
629.9 %
Tabla 5.3: Tiempos de transferencia con servicios de seguridad usando red WLAN
5. Resultados
103
Comparativo de tiempos de transferencia de archivo con

y sin servicios de seguridad usando WLAN
Tiempo de transferencia con servicios
Tiempo de transferencia sin servicios
120
Tiempo en seg.
100
80
60
40
20
0
0
Figura 5.9: Tiempos de transferencia con y sin servicios de seguridad usando WLAN
5.2.6
Tiempo de transferencia de archivos usando red GPRS
Los objetivos de esta prueba al igual que la prueba anterior fueron:

Determinar el tiempo promedio de transferencia para archivos de diferentes tamanos cuando
se usa la red GPRS.
Determinar la tasa de transferencia real.
Determinar el costo en tiempo al agregar los servicios de seguridad a la transferencia de archivo.
Para determinar el tiempo de transferencia y la tasa de transferencia de la red GPRS se dispuso
de 7 archivos cuyos tamanos fueron desde los 4 KB hasta los 256 KB. El tamano de estos archivos
fue menor que en la prueba similar con red WLAN debido a dos razones, la primera es que la tasa
de transferencia maxima de GPRS es de solo 150 KB/s y en pruebas preliminares se observo que la
tasa real es mucho menor, ademas de que con archivos de tamano mayor a 512 KB se presentaban
104
5.2. Desempe
no de la plataforma
Tiempos de transferencia de archivos sin servicios de seguridad usando red GPRS

1000
900
800
Tiempo en seg.
700
600
500
400
300
200
100
100
200
300
400
500
Tamao de archivo en KB
Figura 5.10: Tiempos de transferencia usando red GPRS
errores de transmision que extendan considerablemente el tiempo de transferencia, la segunda razon

es que el costo por kilobyte transferido hara 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.
Comparativo de tiempos de transferencia de archivo con

y sin servicios de seguridad usando GPRS
1000
900
Tiempo de transferencia con servicios

Tiempo de transferencia sin servicios
800
Tiempo en seg.
700
600
500
400
300
200
100
100
200
300
Tamao de archivo en KB
400
500
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 podra pensar que el impacto de
los servicios de seguridad sera el mismo que el caso del uso de la red WLAN debido a que la carga de
procesamiento es independiente de la red utilizada para hacer la transferencia, sin embargo debido a
que la tasa de transferencia real de GPRS es muy pequena, el impacto de los servicios de seguridad
en el tiempo de transferencia es practicamente nulo, como se muestra en la Tabla 5.4. El impacto
de los servicios de seguridad en el tiempo de transferencia del archivo se observa claramente en la
Figura 5.11, en donde se muestra un comparativo de los tiempos de transferencia con y sin servicios
de seguridad.
106
5.2. Desempe
no de la plataforma
Tiempo promedio
de transferencia
Tiempo promedio
de transferencia
con servicios
Costo de servicios
de seguridad en
porcentaje
4 KB
8 KB
16 KB
32 KB
64 KB
128 KB
256 KB
20.74 s
44.41 s
83.77 s
159.58 s
287.80 s
519.42 s
905.65 s
21.39 s
44.70 s
81.91 s
163.26 s
288.38 s
519.61 s
921.74 s
1.03 %
1.01 %
0.00a %
1.02 %
1.00 %
1.00 %
1.01 %
Tabla 5.4: Tiempos de transferencia con servicios de seguridad usando red GPRS
a
Este resultado se obtiene porque las condiciones de la red celular durante las pruebas fueron diferentes.
5.2.7
Consumo de energa durante cifrado y descifrado de datos
Como se menciono en el Captulo 2, la duracion de la batera 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 energa 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 energa. Por esta razon se selecciono esta operacion para
encontrar cual es el impacto que tiene en el consumo de energa en el telefono celular.
MB cifrados
100
200
381
480
570
586
776
Nivel de carga de batera

100 %
100 %
100 %
85 %
71 %
57 %
14 %
Tabla 5.5: Megabytes cifrados con una batera con carga completa
Los objetivos de esta prueba fueron:
Determinar el porcentaje de uso de la batera por megabyte cifrado.
Determinar el porcentaje de uso de la batera por megabyte descifrado.
5. Resultados
107
MB descifrados
100
200
237
355
468
584
589
749

100 %
100 %
100 %
86 %
72 %
57 %
43 %
29 %
Tabla 5.6: Megabytes descifrados con una batera con carga completa
Para determinar el porcentaje de uso de la batera por megabyte cifrado primero fue necesario
cargar apropiadamente la batera, para hacerlo se descargo la batera completamente y despues se
realizo una carga completa, esto garantizo que la duracion de la batera fuera la maxima. Una vez
que se cargo la batera se cifro repetidamente un archivo de texto de 1 MB, realizando esta operacion
hasta que se agoto la batera, cada vez que se cifraba el archivo se tomaba una lectura del nivel
actual de la batera.
MB transferidos
100
166
211
242
280
327
373
574

100 %
100 %
85 %
71 %
57 %
42 %
28 %
14 %
Tabla 5.7: Megabytes transferidos con una batera 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 batera con carga completa, sin embargo no es posible determinar
con exactitud el porcentaje de batera 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 batera. Se observo que el comportamiento de la batera no es lineal,
a medida que el nivel de carga de la batera disminuye los cambios de nivel se dan mas rapidamente,
esto se puede observar claramente en la Figura 5.12, en donde observamos que se pueden cifrar
108
5.2. Desempe
no de la plataforma
Megabytes de informacin cifrados con una batera con carga completa en Nokia N91
Consumo de batera al cifrar
100
% de carga de batera.
80
60
40
20
0
200
300
400
500
600
700
800
Megabytes cifrados
Figura 5.12: Megabytes cifrados con una batera con carga completa
aproximadamente 500 MB antes de que el nivel de carga de la batera 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 batera por megabyte descifrado se siguio un

procedimiento similar al anterior. Una vez que se cargo la batera se descifro repetidamente un
archivo de 1 MB que haba sido previamente cifrado, realizando esta operacion hasta que se agoto la
batera, cada vez que se descifraba el archivo se tomaba una lectura del nivel actual de la batera.
Los resultados de la prueba se muestran en la Tabla 5.6. Se encontro que se pueden descifrar
aproximadamente 750 MB con una batera con carga completa. Se observo que el comportamiento
de la batera 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
Megabytes de informacin descifrados con una batera con carga completa en Nokia N91
Consumo de batera al descifrar
100
80
60
40
20
0
200
300
400
500
600
Megabytes descifrados
700
800
Figura 5.13: Megabytes descifrados con una batera con carga completa
110
5.2.8
5.2. Desempe
no de la plataforma
Consumo de energa durante transferencia usando red WLAN
El objetivo de esta prueba fue determinar el porcentaje de uso de batera por megabyte transferido
cuando se usa la red WLAN.
Para determinar el porcentaje de uso de batera por megabyte transferido se cargo la batera 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 batera, cada vez
que se completaba la transferencia del archivo se tomaba una lectura del nivel actual de la batera.
Los resultados de la prueba se muestran en la Tabla 5.7. Se encontro que se pueden transferir
aproximadamente 580 MB con una batera con carga completa. Se observo que el comportamiento
de la batera 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 energa de cifrado y descifrado.
Megabytes de informacin enviados con una batera con carga completa

en Nokia N91 usando WLAN
Consumo de batera por MB transferido
100
80
60
40
20
0
100
200
300
400
Megabytes enviados
500
600
Figura 5.14: Megabytes transferidos con una batera con carga completa
5. Resultados
5.2.9
111
Consumo de energa durante transferencia usando red GPRS
El objetivo de esta prueba era determinar el porcentaje de uso de batera por megabyte transferido
al usar la red GPRS, sin embargo esta prueba no pudo ser llevada a cabo debido al costo que
implicara realizarla. En la prueba anterior se encontro que se podan 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 costara
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 haba 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 energa. 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 da dependiendo de la saturacion de la red de telefona celular.
6
Conclusiones 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, vdeo juegos
portatiles, reproductores de musica, etc. Existe gran variedad de aplicaciones moviles que aprovechan
las nuevas caractersticas 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 mayora 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 Captulo 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 enva 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 da 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 da.
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 energa, siendo posible cifrar hasta
aproximadamente 380 Mb con solo el 15 % de la carga de la batera.
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 podran ser mejorados. Este trabajo
se vera mejorado anadiendo a la plataforma el servicio de no repudio. Esto hara a la plataforma
116
6.1. Trabajo futuro
mas robusta porque permitira 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 podra derivarse de esta tesis es el desarrollo de una plataforma de handover
vertical para dispositivos moviles con tecnologa 3G. La tecnologa actual en la mayora de los telefonos
es 2G, esta tecnologa 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 tecnologa 3G
proporciona un servicio de datos con una tasa de transferencia de hasta 1.5 Mbps y esta sustituyendo
rapidamente a la tecnologa 2G, por lo tanto sera 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 podra hacerse a partir de esta tesis es el uso de criptografa de llave publica,
esto permitira entre otras cosas el uso de firmas digitales para aquellas aplicaciones que lo requieran
y permitira implementar un mejor esquema de distribucion de llaves de sesion. Un tercer trabajo
futuro sera 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.
A
Modelo 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. Tpicamente, 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 mnimo 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 funci
on 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 sera 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 funci
on 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 funci
on send(): La funcion send() enva 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 enva. La funcion regresa la
longitud del mensaje enviado.
La funci
on 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
Tpicamente 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 funci
on connect(): Una vez que un cliente ha creado un socket, necesita conectarlo a un
puerto especfico 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 tpico 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 funci
on 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 vaca 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 funci
on 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 funci
on 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
A.0.5
121
Secuencia de conexi
on 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.
Servidor
Cliente
Socket
Socket
bind
connect
listen
accept
send/recv
send/recv
close
close
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 especfico
122
send(), recv(): Enva 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(): Enva y recibe datos
close(): Cierra conexion y libera descriptor de socket
B
Funciones utilizadas
B.1
B.1.1
Funciones para manejo de handover

La funci
on 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 captulo 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 selecci
on 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 alg
un 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.1.2
125
La funci
on 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 inal
ambrica 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 conexi
on 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 informaci

on es obtenida
User::WaitForRequest( status ) ;
// sal si el m
etodo 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.
127
#include <e32std.h>
#include <python.h>
#include "symbian_python_ext_util.h"
#include "IAPEngine.h"
extern "C"
void _mod_cleanup();
extern "C" PyObject*
IapSelect(PyObject* /*self*/, PyObject* args)
{
PyObject* Iaplist = PyList_New(1);
PyObject* IapId;
PyObject* IapName;
PyObject * tup;
TUint32 Id=0;
CIAPEngine* iIAPEngine ;
iIAPEngine = CIAPEngine::NewL();
Id = iIAPEngine->SelectBestIAPL();
IapId = Py_BuildValue("i", Id);
PyList_SetItem(Iaplist, 0,IapId);
return Iaplist;
}
extern "C"
{
static const PyMethodDef
Iaptools_methods[] = {
{"IapSelect", (PyCFunction)IapSelect, METH_VARARGS, NULL},
{NULL,
NULL} /* sentinela */
};
DL_EXPORT(void)
initIaptools(void)
{
// Aqu
:este s
mbolo fue definido en alg
un archivo frz
128
B.2. Funciones para servicios de seguridad

PyObject *m;
m = Py_InitModule("Iaptools", (PyMethodDef*)Iaptools_methods);
return;
}
} /* extern "C" */
B.2
B.2.1
Funciones para servicios de seguridad

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)
{
129
unsigned char digest[MD5_DIGEST_LENGTH];

AES_KEY key;
MD5(password, passlen, digest);
AES_set_encrypt_key(digest, 128, &key );
AES_encrypt( in, out,&key);
}
void s60_decrypt_AES( unsigned char* in, unsigned char* out,
unsigned char* password, int passlen)
{
unsigned char digest[MD5_DIGEST_LENGTH];
AES_KEY key;
MD5(password, passlen, digest);
AES_set_decrypt_key(digest, 128, &key );
AES_decrypt( in, out,&key);
}
B.2.2
Funciones de interfaz Open C/Python (wraper)
Las funciones s60 encrypt AES() y s60 decrypt AES() tambien se compilaron como una DLL
para poder ser invocadas desde un programa en Python para S60, por lo tanto tambien se necesita
un programa de interfaz entre OpenC y Python, para convertir el resultado generado por las funciones
escritas en OpenC al formato de datos de Python. El programa de interfaz se muestra a continuacion,
y tambien esta escrito en OpenC.
#include <python.h>
#include "s60crypt.h"
static PyObject* pycrypt_encrypt_AES(PyObject* self, PyObject* args)
{
char* data;
int datalen;
char* pw;
int pwlen;
130
B.2. Funciones para servicios de seguridad

char* out;
PyObject* result;
if (!PyArg_ParseTuple(args, "s#s#", &data, &datalen, &pw, &pwlen))
return NULL;
out = (char*)malloc(datalen);
if (!out)
return PyErr_NoMemory();
s60_encrypt_AES( data, out, pw, pwlen);
result = Py_BuildValue("s#", out, datalen);
free(out);
if (!result)
return 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);
}
131
Bibliografa
[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:24, 1999.
[7] R. Good and N. Ventura. A Multilayered Hybrid Architecture to Support Vertical Handover
between IEEE802.11 and UMTS. IWCMC 2006, 1:257262, 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
BIBLIOGRAFIA
134
[11] Rong-Hong Jan and Wen-Yueh Chiu.
An approach for seamless handoff among mobile
WLAN/GPRS integrated networks. Computer Communications, 29:3241, 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:26012611, 2006.
[14] Rick Lehtinen. Computer Security Basics, 2nd Edition. OReilly, 2006.
[15] Li Ma, Fei Yu, and Victor Leung. A New Method to Support UMTS/WLAN Vertical Handover
Using SCTP. IEEE Wireless Communications, 11:4451, 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 Rodrguez-Henrquez, N.A. Saquib, Arturo Daz Perez, and Cetin Kaya Koc.
Cryptographic Algorithms on Reconfigurable Hardware, pages 89. Springer, 2006.
[21] Apostolis K. Salkintzis.
Interworking between WLANs and third-generation cellular data
networks. Vehicular Technology Conference, 2003, 3:18021806, 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 1619. 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:329336, 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:102108, 2003.
[28] Pei Zheng and Lionel M. Ni. Spotlight: The Rise of the Smart Phone. IEEE Distributed Systems
Online, 7:114, 2006.

Tesis Vargas

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tesis Vargas

Enviado por

Direitos autorais:

Formatos disponíveis

n y de Estudios Avanzados

Laboratorio de Tecnologas de Informacion

Una plataforma de handover

Tesis que presenta:

Para obtener el grado de:

Cd. Victoria, Tamaulipas, Mexico.

c Derechos reservados por

Dr. Luis Gerardo de la Fraga

Dr. Victor Jesus Sosa Sosa

Dr. Arturo Daz Perez, Director

Cd. Victoria, Tamaulipas, Mexico., 26 de Febrero de 2009

6. Conclusiones y trabajo futuro

B.2.1. Funciones de cifrado y descifrado . . . . . . . . . . . . . . . . . . . . . . . 128

Estructura celular de red GSM . . . . . . . .

Sistema de monitoreo de signos vitales .

4.1. Ubicacion de protocolo de transferencia por Bluetooth . . . . . . . . . . . . . . .

4.28. Formato de mensajes de comandos del protocolo . . . .

5.1. Escenario para pruebas de funcionalidad . . . . . . . . . . . . . . . . . .

A.1. Secuencia para modo de entrega de flujo fiable . . . . . . . . . . . . . . . . . . . . 121

2.1. Comparativo de telefonos inteligentes . . . . . . . . . . . . . . . . . . . . . . . . .

3.1. Comandos del protocolo de transferencia por Bluetooth . . . . . . . . . . . . . . .

4.1. Comandos del protocolo de transferencia de archivo por Internet . . . . . . . . . . .

Tiempos de transferencia usando red WLAN . . . . . . . . . . . . . .

Pasos para establecer llave de sesion. . . . . . . . . . . . . . . . . . . . . . . . . .

Juan Antonio Vargas Enrquez

Juan Antonio Vargas Enrquez

l desarrollo de aplicaciones para dispositivos moviles, a diferencia del desarrollo de aplicaciones

Symbian OS es claramente el lder del mercado, impulsando mas de 32 millones de telefonos

Los componentes de hardware de un telefono celular normalmente incluyen un microprocesador,

Tabla 2.1: Comparativo de telefonos inteligentes

el Dragon Ball de Motorola, el MIPS, y el OMAP de Texas Instruments. La arquitectura XScale

Asistentes personales digitales (PDA)

2.4. Interfaces de comunicaci

Arquitectura del sistema GSM

Figura 2.1: Estructura celular de red GSM

2.4. Interfaces de comunicaci

Figura 2.2: Arquitectura del sistema GSM

el centro de conmutacion de servicios moviles (MSC), el registro de ubicacion de origen (HLR), el

2.4. Interfaces de comunicaci

General Packet Radio Service (GPRS)

por los servicios de conmutacion de circuitos. En los servicios de conmutacion de circuitos, la

Arquitectura del sistema GPRS

2.4. Interfaces de comunicaci

Figura 2.3: Arquitectura del sistema GPRS

subestandares cada uno trata extensiones particulares.

2.4. Interfaces de comunicaci

Figura 2.4: Pila de protocolos Bluetooth

responsable de establecer conexiones a traves de enlaces existentes o solicitar un enlace si no existe

2.5. El sistema operativo Symbian y la plataforma S60

El sistema operativo Symbian y la plataforma S60

El nucleo del S.O. Symbian consiste de la base (microkernel y controladores de dispositivos),

El microkernel se ejecuta directamente en el procesador en modo privilegiado. Es responsable

2.7. Seguridad computacional

La seguridad computacional se define como el conjunto de medidas o sistemas de control para

2.7. Seguridad computacional

Aplicaciones para dispositivos mviles

Figura 2.5: Modelo de capas de seguridad computacional

Criptografa de llave sim

2.7. Seguridad computacional

Llave secreta compartida por

Figura 2.6: Criptografa de llave simetrica

El algoritmo de cifrado AES

son SHA-1, SHA-224, SHA-256, SHA-384, y SHA-512 [19].

on el fin de demostrar la funcionalidad de la plataforma de handover vertical propuesta en