pasarela bluetooth/gprs para dispositivos...

PASARELA BLUETOOTH/GPRS PARADISPOSITIVOS MÓVILES

Antonio Ángel Botella Galindo

21 de junio de 2007

Índice general

1. Introducción 1

2. Descripción del sistema 3

2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2. Ámbito del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1. iBAN del paciente . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2. Terminales móviles para recepción de alarmas . . . . . . . . . . . 7

2.3. Estructura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1. Subsistemas del software del NI . . . . . . . . . . . . . . . . . . . 8

2.3.1.1. Módulo de comunicaciones Bluetooth . . . . . . . . . . 8

2.3.1.2. Módulo de comunicaciones con el SCC . . . . . . . . . . 9

2.3.1.3. Módulo de gestión de comandos y control . . . . . . . . 9

2.3.1.4. Módulo de procesamiento y gestión de alarmas . . . . . . 10

2.3.2. Subsistemas del software de recepción y notificación de alarmas enterminales móviles . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.3. Aplicación web para la descarga de MIDlets . . . . . . . . . . . . . 11

3. Tecnologías implicadas 13

3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2. Tecnologías de Comunicación . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.2. Tecnologías de comunicaciones móviles . . . . . . . . . . . . . . . 15

3.2.2.1. GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.2.2. GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.2.3. EGPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.2.4. UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.3. WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3. Sistemas operativos para teléfonos móviles . . . . . . . . . . . . . . . . . 17

I

3.3.1. El sistema operativo Symbian OS . . . . . . . . . . . . . . . . . . 17

3.3.2. Otros sistemas operativos utilizados en teléfonos móviles . . . . . . 18

3.4. Lenguajes de Programación . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.1. Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4.2. J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4.3. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4.4. PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5. Lenguaje Unificado de Modelado (UML) . . . . . . . . . . . . . . . . . . 22

3.6. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.6.1. Eclipse SDK (Software Development Kit) . . . . . . . . . . . . . . 24

3.6.2. Carbide.j (Nokia Developers Suite for J2ME) . . . . . . . . . . . . 29

3.6.3. NCF (Nokia Connectivity Framework) . . . . . . . . . . . . . . . 33

3.6.4. Nokia PC Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6.5. Sun Java Wireless Toolkit for CLDC . . . . . . . . . . . . . . . . . 37

3.6.6. Ethereal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4. Dispositivos Hardware utilizados 43

4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2. Dispositivos Hardware utilizados para el desarrollo de la aplicación del NI . 44

4.2.1. Teléfono Nokia 9500 (Serie 80 2a Edición) . . . . . . . . . . . . . 44

4.2.2. Teléfono Nokia N93 (Serie 60 3a Edición) . . . . . . . . . . . . . . 44

4.2.3. Teléfono Nokia E61 (Serie 60 3aEdición) . . . . . . . . . . . . . . 46

4.2.4. Teléfono Nokia N70 (Serie 60 2a Edición, Feature Pack 3) . . . . . 47

4.2.5. Teléfono Nokia 6680 (Serie 60 2a Edición, Feature Pack 2) . . . . . 47

4.2.6. Teléfono Nokia 6230 (Serie 40 2a Edición) . . . . . . . . . . . . . 47

4.2.7. Teléfono Sony-Ericsson K608i . . . . . . . . . . . . . . . . . . . . 49

4.2.8. Pulsioxímetro Nonin 4100 . . . . . . . . . . . . . . . . . . . . . . 49

4.2.8.1. ¿Qué es la pulsioximetría? . . . . . . . . . . . . . . . . . 49

4.2.8.2. ¿Cómo se mide el SPO2? . . . . . . . . . . . . . . . . . 50

4.2.8.3. Pulsioxímetro Nonin 4100 . . . . . . . . . . . . . . . . . 52

4.2.9. GPS Leadtek 9553X . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.3. Dispositivos Hardware utilizados para el desarrollo de la aplicación derecepción y aviso de alarmas . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.4. Dispositivos Hardware utilizados para el desarrollo de la aplicación web parala descarga de MIDlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

II

5. Desarrollo del software del Nodo Inteligente 73

5.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2. Desarrollo software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2.1. Lenguaje de programación . . . . . . . . . . . . . . . . . . . . . . 73

5.2.2. Filosofía de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.2.2.1. Modelo de Ingeniería del Software . . . . . . . . . . . . 74

5.2.2.2. Patrón de Diseño software . . . . . . . . . . . . . . . . . 75

5.2.3. Análisis de la aplicación del Nodo Inteligente . . . . . . . . . . . 76

5.2.4. Subsistema de comunicaciones Bluetooth . . . . . . . . . . . . . . 78

5.2.4.1. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2.4.2. Diseño software . . . . . . . . . . . . . . . . . . . . . . 78

5.2.4.3. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . 92

5.2.5. Subsistema de comunicaciones con el SCC . . . . . . . . . . . . . 93

5.2.5.1. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.2.5.2. Diseño software . . . . . . . . . . . . . . . . . . . . . . 101

5.2.5.3. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . 109

5.2.6. Subsistema de gestión de comandos y control . . . . . . . . . . . . 109

5.2.6.1. Diseño software . . . . . . . . . . . . . . . . . . . . . . 109

5.2.6.2. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . 111

5.2.7. Subsistema de procesamiento y gestión de alarmas . . . . . . . . . 111

5.2.7.1. Diseño software . . . . . . . . . . . . . . . . . . . . . . 111

5.2.7.2. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . 114

5.2.8. Implementación del patrón de diseño MVC . . . . . . . . . . . . . 117

6. Desarrollo del software de recepción y notificación de alarmas 121

6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

6.2. Desarrollo del software de recepción y notificación de alarmas . . . . . . . 121

6.2.1. Lenguaje de programación . . . . . . . . . . . . . . . . . . . . . . 121

6.2.2. Análisis de la aplicación de recepción y notificación de alarmas . . 122

6.2.3. Subsistema de recepción de mensajes SMS/MMS . . . . . . . . . . 122

6.2.3.1. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.2.3.2. Diseño software . . . . . . . . . . . . . . . . . . . . . . 123

6.2.3.3. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . 125

7. Desarrollo de la aplicación web para la descarga de MIDlets 131

7.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

III

7.2. Lenguajes de programación y herramientas utilizadas . . . . . . . . . . . . 131

7.3. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7.4. Diseño software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

7.5. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

8. Manual de instalación y usuario 135

8.1. Manual de instalación de los MIDlets desarrollados . . . . . . . . . . . . . 135

8.1.1. Requisitos de instalación . . . . . . . . . . . . . . . . . . . . . . . 135

8.1.2. Proceso de instalación . . . . . . . . . . . . . . . . . . . . . . . . 135

8.1.3. Instalación mediante el envío directo de la aplicación al terminaldestino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

8.1.4. Instalación mediante la herramienta propietaria del fabricante delteléfono destino . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.1.5. Instalación mediante la aplicación web para la descarga de MIDlets 140

8.2. Manual de instalación de la aplicación web para la descarga de MIDlets . . 143

8.2.1. Requisitos de instalación . . . . . . . . . . . . . . . . . . . . . . . 143

8.2.2. Proceso de instalación . . . . . . . . . . . . . . . . . . . . . . . . 143

8.3. Manual de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

8.3.1. Manual de usuario de la aplicación del Nodo Inteligente . . . . . . 144

8.3.2. Manual de usuario de la aplicación de recepción y notificación dealarmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

9. Pruebas realizadas 151

9.1. Software del Nodo Inteligente . . . . . . . . . . . . . . . . . . . . . . . . 151

9.1.1. Pruebas de funcionalidad . . . . . . . . . . . . . . . . . . . . . . . 151

9.1.1.1. Subsistema de comunicaciones Bluetooth . . . . . . . . . 151

9.1.1.2. Subsistema de comunicaciones con el SCC . . . . . . . . 156

9.1.1.3. Subsistema de gestión de comandos y control . . . . . . 157

9.1.1.4. Subsistema de procesamiento y gestión de alarmas . . . . 158

9.1.2. Pruebas de integración del NI con el SCC . . . . . . . . . . . . . . 159

9.1.3. Pruebas de jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

9.1.4. Pruebas de medida de la batería del teléfono Nokia N93 . . . . . . 163

9.2. Software de recepción y notificación de alarmas . . . . . . . . . . . . . . . 163

9.3. Aplicación web para la descarga de MIDlets . . . . . . . . . . . . . . . . . 164

10. Conclusiones y líneas futuras 165

10.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

10.2. Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

IV

A. Terminología relacionada con Java 183

B. Principales Java Specification Request de J2ME 187

C. Plataformas de teléfonos móviles Nokia 191

D. Protocolo de comunicación entre el NI y el SCC 195

D.1. Paquetes del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

D.1.1. Paquete de identificación de paciente . . . . . . . . . . . . . . . . 195

D.1.2. Paquete de envío de comandos . . . . . . . . . . . . . . . . . . . . 196

D.1.3. Paquete de envío de datos . . . . . . . . . . . . . . . . . . . . . . 197

D.1.4. Paquete de indicación/respuesta . . . . . . . . . . . . . . . . . . . 198

D.1.5. Paquete de indicación del puerto UDP . . . . . . . . . . . . . . . . 198

D.2. Formato de las tramas GPS a recibir en el SCC . . . . . . . . . . . . . . . 199

V

Índice de figuras

2.1. Sistema de monitorización inalámbrica de pacientes. . . . . . . . . . . . . 4

2.2. Ámbito de los proyectos realizados por Antonio Ángel Botella Galindo yEmilio Jesús Cuberos Jiménez, respecto al sistema de la figura 2.1. . . . . . 5

2.3. iBAN desarrollada en este Proyecto Fin de Carrera. . . . . . . . . . . . . . 6

2.4. Envío de alarmas desde el NI a los familiares del paciente. . . . . . . . . . 8

3.1. Arquitectura de Bluetooth v1.1. Fuente: [11]. . . . . . . . . . . . . . . . . 16

3.2. Arquitectura Java. Fuente: [36]. . . . . . . . . . . . . . . . . . . . . . . . 19

3.3. Arquitectura de Eclipse SDK [55]. . . . . . . . . . . . . . . . . . . . . . . 24

3.4. Vistas y perspectivas de Eclipse. . . . . . . . . . . . . . . . . . . . . . . . 27

3.5. Perspectiva Java de Eclipse. . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.6. Perspectiva Debug de Eclipse. . . . . . . . . . . . . . . . . . . . . . . . . 28

3.7. Editor Java y algunos servicios del JDT. . . . . . . . . . . . . . . . . . . . 28

3.8. Pestaña de creación/edición de los ficheros .JAR y .JAD, en Carbide.j 1.5. . 31

3.9. Emuladores de la Serie 80, Serie 60 y Serie 40 de Nokia, que incorporaCarbide.j 1.5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.10. Aspecto de la ventana principal del programa Nokia Connectivity Frame-work 1.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.11. Escenario de test con un emulador de la Serie 60 y un adaptador USBBluetooth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.12. Ventana principal del programa PC Suite 6.8. . . . . . . . . . . . . . . . . 36

3.13. Instalación de un programa J2ME, en un teléfono Nokia N70, mediante PCSuite 6.8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.14. Panel de utilidades, en Sun Java Wireless Toookit 2.5 for CLDC Beta 2. . . 39

3.15. Ventana de selección de API del proyecto “BluetoothDemo” en Sun JavaWireless Toolkit 2.5 for CLDC Beta 2. . . . . . . . . . . . . . . . . . . . . 39

3.16. Instancias de emulador que se comunican entre sí. . . . . . . . . . . . . . . 40

3.17. Ejemplo de análisis de un paquete HTTP, en Ethereal 0.10.14. . . . . . . . 41

4.1. Teléfono Nokia 9500. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

VII

4.2. Teléfono Nokia N93. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3. Teléfono Nokia E61. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4. Teléfono Nokia N70. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5. Teléfono Nokia 6680. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.6. Teléfono Nokia 6230. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.7. Teléfono Sony-Ericsson K608i. . . . . . . . . . . . . . . . . . . . . . . . . 49

4.8. Pulsioxímetro de Aoyagi [99]. . . . . . . . . . . . . . . . . . . . . . . . . 51

4.9. LEDs y fotodetector de un pulsioxímetro. . . . . . . . . . . . . . . . . . . 52

4.10. Posibles sensores usados en pulsioximetría. . . . . . . . . . . . . . . . . . 52

4.11. Pulsioxímetro Nonin 4100. . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.12. Modos de funcionamiento del pulsioxímetro Nonin 4100 [114]. . . . . . . . 54

4.13. Formato de los paquetes de Modo 1 [114]. . . . . . . . . . . . . . . . . . . 55

4.14. Formato de los paquetes de Modo 2 [114]. . . . . . . . . . . . . . . . . . . 56

4.15. Bits del byte de estado, en el Modo 2. . . . . . . . . . . . . . . . . . . . . 57

4.16. Estructura genérica de los bytes HR-MSB, HR-LSB y SPO2. . . . . . . . . 58

4.17. Ejemplo de establecimiento del modo de funcionamiento, en el Nonin 4100. 60

4.18. GPS Leadtek 9553X. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.19. Sentencias NMEA-0183, en situaciones con cobertura y sin cobertura GPS. 62

5.1. Fases que componen cada ciclo del modelo incremental. . . . . . . . . . . 74

5.2. Patrón de diseño Modelo-Vista-Controlador (MVC). . . . . . . . . . . . . 76

5.3. Diagrama de actividad que muestra la interacción entre los elementos delpatrón MVC, en una aplicación software del juego del ajedrez. . . . . . . . 77

5.4. Diagrama de componentes que representa los módulos que integran elsoftware del NI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.5. Diagrama de componentes del módulo de comunicaciones Bluetooth. . . . 79

5.6. Diseño software de cada uno de los componentes del módulo de comunica-ciones Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.7. Diagrama de clases del componente para la búsqueda de dispositivos(Inquiry process) y de servicios (Service Discovery process) Bluetooth. . . 81

5.8. Diagrama de clases del componente para la comunicación Bluetooth. . . . . 83

5.9. Diagrama de clases del componente para la comunicación con el pul-sioxímetro Nonin 4100. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.10. Diagrama de clases del componente para la comunicación con el GPS. Clasesprincipales asociadas al uso de las interfaces JSR-82 y JSR-179 y otras clasesde uso general. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

VIII

5.11. Diagrama de clases del componente para la comunicación con el GPS. Clasesasociadas al uso de la interfaz JSR-179. . . . . . . . . . . . . . . . . . . . 90

5.12. Diagrama de actividad que detalla las tareas que se realizan dentro delsubsistema de comunicaciones Bluetooth. . . . . . . . . . . . . . . . . . . 94

5.13. Diagrama de secuencia que muestra la inicialización de un objeto de la claseBluetooth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.14. Diagrama de secuencia que refleja el proceso de búsqueda de dispositivosBluetooth (Inquiry process). . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.15. Diagrama de secuencia que refleja el proceso de búsqueda de serviciosBluetooth (Service Discovery process). . . . . . . . . . . . . . . . . . . . . 97

5.16. Diagrama de secuencia que ilustra el proceso de conexión con los disposi-tivos de la iBAN, a través del método initiateComms(). . . . . . . . . . . . 98

5.17. Diagrama de secuencia que muestra el proceso de lectura de datosprocedentes del pulsioxímetro Nonin 4100. . . . . . . . . . . . . . . . . . 99

5.18. Diagrama de secuencia que muestra el proceso de lectura de datosprocedentes del GPS Leadtek 9553X, mediante el uso de la interfaz JSR-179 (Location API). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.19. Diagrama de componentes del módulo de comunicaciones con el SCC. . . . 101

5.20. Diseño software de cada uno de los componentes del módulo de comunica-ciones con el SCC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.21. Diagrama de clases del componente para la implementación del protocolo decomunicación entre el NI y el SCC. . . . . . . . . . . . . . . . . . . . . . 104

5.22. Diagrama de clases del componente para la comunicación HTTP. . . . . . 105

5.23. Diagrama de clases del componente para la comunicación TCP/UDP. . . . 107

5.24. Diagrama de clases del componente para el cifrado de datos. . . . . . . . . 107

5.25. Diagrama de clases del componente gestor de datos. . . . . . . . . . . . . . 108

5.26. Diagrama de clases del componente gestor de indicaciones/respuestas. . . . 109

5.27. Diagrama de secuencia que refleja el funcionamiento del módulo decomunicaciones con el SCC. . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.28. Diagrama de clases del subsistema de gestión de comandos y control. . . . 112

5.29. Diagrama de secuencia que explica el funcionamiento del módulo de gestiónde comandos y control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5.30. Diagrama de clases del subsistema de procesamiento y gestión de alarmas. . 115

5.31. Diagrama de secuencia que explica el funcionamiento del módulo deprocesamiento y gestión de alarmas. . . . . . . . . . . . . . . . . . . . . . 116

5.32. Clases que implementan el patrón de diseño MVC en la aplicación del NI. . 118

5.33. Diagrama de secuencia que muestra el funcionamiento de la aplicación delNI (I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

IX

5.34. Diagrama de secuencia que muestra el funcionamiento de la aplicación delNI (II). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

6.1. Ciclo de vida y activación de MIDlets desarrollados con MIDP 2.0 [145]. . 123

6.2. Estructura de la aplicación de recepción y notificación de alarmas. . . . . . 124

6.3. Diseño software del subsistema de recepción de mensajes SMS/MMS. . . . 126

6.4. Diagrama de clases del subsistema de recepción de mensajes SMS/MMS. . 127

6.5. Diagrama de actividad: Funcionamiento de la aplicación de recepción ynotificación de alarmas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

6.6. Diagrama de secuencia: Funcionamiento de la aplicación de recepción ynotificación de alarmas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.7. Diagrama de secuencia: Tratamiento de las opciones del usuario en laaplicación de recepción y notificación de alarmas. . . . . . . . . . . . . . 130

7.1. Estructura de la aplicación web para la descarga de MIDlets. . . . . . . . . 132

7.2. Diseño software de los subsistemas de la aplicación para la descarga deMIDlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

7.3. Diagrama de actividad: Funcionamiento de la aplicación web para ladescarga de MIDlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

8.1. Enviar un archivo, a un dispositivo, a través de Bluetooth. . . . . . . . . . . 137

8.2. Examinar dispositivos Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . 137

8.3. Seleccionar dispositivo Bluetooth. . . . . . . . . . . . . . . . . . . . . . . 138

8.4. Iniciar transferencia de fichero. . . . . . . . . . . . . . . . . . . . . . . . . 138

8.5. Petición para recibir el fichero. . . . . . . . . . . . . . . . . . . . . . . . . 139

8.6. Apertura del mensaje recibido, que adjunta el MIDlet. . . . . . . . . . . . . 139

8.7. Petición para ejecutar la instalación del MIDlet. . . . . . . . . . . . . . . . 139

8.8. Motorola Phone Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.9. Navegador web del teléfono Nokia N93. . . . . . . . . . . . . . . . . . . . 141

8.10. Pantalla principal de la aplicación web para la descarga de MIDlets. . . . . 142

8.11. Pantalla de descarga. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8.12. Petición para ejecutar la instalación del MIDlet. . . . . . . . . . . . . . . . 143

8.13. Icono de la aplicación del Nodo Inteligente. . . . . . . . . . . . . . . . . . 144

8.14. Pantalla de Inquiry de la aplicación del Nodo Inteligente. . . . . . . . . . . 145

8.15. Pantalla de ServiceDiscovery de la aplicación del Nodo Inteligente. . . . . . 146

8.16. Pantalla de log y representación de datos de la aplicación del Nodo Inteligente.146

8.17. Icono de la aplicación de recepción y notificación de alarmas SMS. . . . . . 148

8.18. Pantalla de espera de alarmas SMS entrantes. . . . . . . . . . . . . . . . . 149

X

8.19. Pantalla de representación de alarmas SMS. . . . . . . . . . . . . . . . . . 149

9.1. Fichero de traza donde se han almacenado paquetes de datos en Modo 1. . . 155

9.2. Fichero de traza donde se han almacenado paquetes de datos en Modo 2. . . 155

9.3. Valores de jitter para tiempo de monitorización de 1 segundo. . . . . . . . . 161

9.4. Valores de jitter para tiempo de monitorización de 10 segundos. . . . . . . 161

9.5. Histograma del jitter con tiempo de monitorización de 1 segundo. . . . . . 162

9.6. Histograma del jitter con tiempo de monitorización de 10 segundos. . . . . 162

D.1. Paquete de identificación de paciente [4]. . . . . . . . . . . . . . . . . . . 196

D.2. Paquete de envío de un comando [4]. . . . . . . . . . . . . . . . . . . . . . 197

D.3. Paquete de envío de datos [4]. . . . . . . . . . . . . . . . . . . . . . . . . 197

D.4. Paquete de indicación/respuesta [4]. . . . . . . . . . . . . . . . . . . . . . 198

D.5. Paquete de puerto UDP [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . 199

XI

Índice de tablas

4.1. Características del teléfono Nokia 9500 [82]. . . . . . . . . . . . . . . . . 45

4.2. Características del teléfono Nokia N93 [79]. . . . . . . . . . . . . . . . . . 64

4.3. Características del teléfono Nokia E61 [85]. . . . . . . . . . . . . . . . . . 65

4.4. Características del teléfono Nokia N70 [87]. . . . . . . . . . . . . . . . . . 66



4.7. Características del teléfono Sony-Ericsson K608i [93][94]. . . . . . . . . . 69

4.8. Características principales del pulsioxímetro Nonin 4100 [114]. . . . . . . 69

4.9. Características principales del GPS Leadtek 9553X [124]. . . . . . . . . . . 70

4.10. Análisis de una sentencia $GPGGA. . . . . . . . . . . . . . . . . . . . . . 71

4.11. Análisis de una sentencia $GPRMC. . . . . . . . . . . . . . . . . . . . . . 72

8.1. Descripción de los valores monitorizados por el pulsioxímetro Nonin 4100que aparecen en la figura 8.16 [114]. . . . . . . . . . . . . . . . . . . . . . 147

9.1. Errores Symbian presentados por el teléfono Nokia 9500 durante lacomunicación SPP de Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 154

B.1. Principales JSR relacionadas con CDC y sus perfiles [40]. . . . . . . . . . . 187

B.2. Principales JSR relacionadas con CLDC y MIDP [76][40] (I). . . . . . . . 188

B.3. Principales JSR relacionadas con CLDC y MIDP [76][40] (II) (continuación). 189

C.1. Principales características de los teléfonos Nokia de la Serie 40 [169][171] (I).191

C.2. Principales características de los teléfonos Nokia de la Serie 40 [169][171](II) (continuación). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

C.3. Principales características de los teléfonos Nokia de la Serie 60[169][170][172]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

C.4. Principales características de los teléfonos Nokia de la Serie 80 [169][173]. 194

XIII

Capítulo 1

Introducción

La monitorización de pacientes con sensores cableados, que es todavía una práctica normalen hospitales y centros médicos, tiene como principal inconveniente la reducción de lamovilidad del paciente y la consecuente disminución de su calidad de vida.

El concepto de e-health o aplicación de las tecnologías de la información al campo dela salud, representa una alternativa y es una solución para la monitorización a distanciade pacientes (Telemedicine) [1].Gracias al desarrollo de la microelectrónica (aumentode la capacidad de integración) y a la aparición e implantación de nuevas tecnologíasinalámbricas como Bluetooth, WiFi (Wireless Fidelity), etc., es cada vez más factible lacreación e implantación de este tipo de sistemas de monitorización a distancia, cuyo fin esmejorar la vida de los pacientes sin degradar la calidad en la supervisión de su salud.

El presente Proyecto Fin de Carrera se encuadra dentro del ámbito de la e-health. Elobjetivo principal es la realización de un software capaz de concentrar la información demonitorización procedente de varios dispositivos electrónicos, portados por un paciente,y enviarla a un sistema externo encargado de gestionarla. Además, este software debe sercapaz de interpretar los datos del paciente monitorizado con el fin de generar alertas ensituaciones críticas. Por otro lado, también es objetivo de este proyecto el desarrollo de unsoftware adicional, para familiares del paciente, que se encargue de la recepción y de lanotificación de estas alertas.

Esta memoria cubre los aspectos más destacados del estudio y trabajo llevados a cabodurante la realización del presente Proyecto Fin de Carrera, por lo que ha sido dividida yestructurada en una serie de capítulos, con el fin de facilitar al lector su comprensión y suseguimiento. A continuación, siguiendo el orden de esta memoria, se describirá brevementeel contenido de cada uno de ellos.

La descripción del sistema en el que se enmarca este proyecto, introduciendo de forma

1

concisa el software que se ha desarrollado, se presenta en el capítulo 2.

En los capítulos 3 y 4 se hace un repaso todas las tecnologías (tecnologías de comunicación,lenguajes de programación, herramientas de desarrollo, etc.) y dispositivos hardware(teléfonos móviles, sensores, etc.), respectivamente, que se han utilizado en la ejecucióndel proyecto. Para cada tecnología y dispositivo hardware se efectúa un análisis técnico,resaltando sus principales características.

La estructura, el diseño y el funcionamiento del software desarrollado en el presenteProyecto Fin de Carrera se detalla en los capítulos 5, 6 y 7. En el capítulo 5 se abordael software de monitorización de pacientes que constituye el núcleo de este proyecto.La aplicación para la recepción y notificación de alarmas se estudia en el capítulo 6,siguiendo una estructura similar a la del capítulo 5. Además, se ha creado una aplicaciónweb para la instalación del software objetivo (capítulos 5 y 6) que se describe en el capítulo 7.

Para la instalación y la utilización de las aplicaciones detalladas en los capítulos 5, 6 y 7 seha incluido un manual de instalación y de usuario, de cada una de ellas, en el capítulo 8 deesta memoria.

Una descripción de todas la pruebas realizadas durante el desarrollo software de lasaplicaciones diseñadas en este Proyecto Fin de Carrera se incluye en el capítulo 9, mientrasque en el capítulo 10 se exponen las principales conclusiones extraídas de la realización delproyecto y se indican posibles líneas de trabajo futuras.

Por último, hay que añadir que al final de la memoria se han adjuntado una serie de apéndices,que complementan la información incluida en alguno de los capítulos anteriormenteseñalados.

2

Capítulo 2

Descripción del sistema

2.1. Introducción

Las personas que sufren enfermedades o afecciones que requieren una atención continuapor parte de sus familiares y/o médicos, ven mermada su calidad de vida con motivo de lasrevisiones médicas continuas o de la propia monitorización que dicha enfermedad requierasegún su relevancia. En casos extremos, hay pacientes que ven reducida notablemente supropia libertad de movimiento, al verse obligados a estar conectados a una máquina en elinterior de un hospital o de un centro médico. En [2][3] se propone un sistema que pretendemejorar la calidad de vida de algunas personas que se encuentran en esta situación.

El sistema presentado en [2][3] tiene por objetivo la monitorización continua, inalámbricae inteligente de pacientes en entornos cerrados (hospital, residencia de ancianos, etc.) yabiertos (escenario urbano, rural, etc.). Está basado en una red de área corporal Bluetooth,portada por el paciente, cuyo nodo central recibe información sobre su estado de saludy localización. Estos datos son cifrados y enviados a un servidor mediante Wi-Fi oGPRS/UMTS.

Además, el sistema permite el acceso remoto a los datos del paciente, desde un PC odesde un terminal móvil, y proporciona un mecanismo de generación de alarmas paraavisar, al personal médico y a los familiares del paciente, de la ocurrencia de situaciones deemergencia: valores monitorizados fuera de rango, paciente fuera de un área controlada osegura, molestias del paciente, etc.

La arquitectura del sistema global, que se muestra en la figura 2.1, está compuesta por lossiguientes elementos:

1. El SCC (Servidor de Control Central) que es un equipo servidor, dotado de conexióna internet, que centraliza la información de los pacientes monitorizados y proporcionaacceso a sus datos desde cualquier PC o dispositivo móvil.

2. La iBAN (intelligent Body Area Network) Bluetooth del paciente, que está formada

3

Sensor 1

Sensor N

...

GPS

iBAN del paciente

INTERNET

PC DE MONITORIZACIÓN (UCMNM)

SCC

NI

PC DE MONITORIZACIÓN (UCMNM)

GSM/GPRS/UMTS

WiFi

GPRS/UMTS

UCMM

WiFiBluetooth

1

K

... FAMILIARES

DELPACIENTE

REDDE

TELEFONÍAMÓVIL

Figura 2.1: Sistema de monitorización inalámbrica de pacientes.

por sensores Bluetooth y por un nodo central, denominado NI (Nodo Inteligente)1.

Estos dispositivos forman una red Bluetooth, donde el NI centraliza todas las comuni-caciones. Este nodo central posee, además, interfaces de WiFi y GSM/GPRS/UMTSque utiliza para la transmisión de la información del paciente al SCC o (WiFi oGPRS/UMTS) y para el envío de las alarmas, a la Unidad de Control y MonitorizaciónMóvil (UCMM) y a los terminales de los familiares del paciente (GSM/GPRS/UMTS).

3. La UCMM, que es un terminal móvil, que posee interfaces WiFi y GSM/GPRS/UMTSpara la comunicación con el SCC (WiFi o GPRS/UMTS) y para la recepción dealarmas procedentes del NI (GSM/GPRS/UMTS). Se conecta con el SCC parasupervisar remotamente la información de los pacientes.

4. Los terminales móviles de los familiares del paciente. Son teléfonos móviles conconexión a la red de telefonía (GSM/GPRS o GSM/GPRS/UMTS), que permiten larecepción de alarmas que envía el NI a través de dicha red.

5. Los PC de monitorización o Unidades de Control y Monitorización No Móvil(UCMNM), con conexión a internet, que acceden al SCC y hacen posible lasupervisión remota de los pacientes.

El presente Proyecto Fin de Carrera abarca, principalmente, el desarrollo del software decontrol de la iBAN del paciente, residente en el nodo central (NI), que ha sido el protagonistadel proyecto. Además, se ha diseñado el software de recepción y notificación de alarmas parafamiliares del paciente.

1Este nombre ha sido adquirido de la notación del sistema propuesto en [2][3].

4

EMILIO JESÚS CUBEROS JIMÉNEZANTONIO ÁNGEL BOTELLA GALINDO

Descarga/Instalaciónde las aplicacionesdel NI y familiares

Terminal móvilFamiliar SCC

PC demonitorización

(UCMNM)

AplicaciónSW

AplicaciónSW

AplicaciónSW

AplicaciónSW

AplicaciónSW

AplicaciónSW

NI UCMM

Figura 2.2: Ámbito de los proyectos realizados por Antonio Ángel Botella Galindo y EmilioJesús Cuberos Jiménez, respecto al sistema de la figura 2.1.

Adicionalmente, se ha desarrollado una aplicación web para la descarga e instalación dedichas aplicaciones en los terminales móviles2.

El resto de componentes del sistema, la UCMM, el SCC y los PC de monitorización, hansido abarcados por el Proyecto Fin de Carrera realizado por Emilio Jesús Cuberos Jiménez,que lleva por título “Desarrollo de una aplicación de telemedicina para el acceso remoto abioseñales desde dispositivos móviles” [4] (véase la figura 2.2).

Seguidamente, en el apartado 2.2, se describen los componentes del sistema objeto de esteproyecto y en el apartado 2.3, se desglosa los módulos en los que se ha estructurado laimplementación del software asociado a dichos componentes.

2.2. Ámbito del proyecto

A continuación, se detallan los bloques en los que se encuadra el software desarrollado en elámbito de este proyecto: la iBAN del paciente y los terminales móviles de los familiares.

2.2.1. iBAN del paciente

La iBAN consta de un conjunto de dispositivos que se comunican entre sí medianteBluetooth. Dicha red puede estar constituida por un número máximo de dispositivos (hastaN sensores, un dispositivo GPS y un teléfono móvil) que vendrá limitado por la tecnología

2Esta aplicación web tiene por objetivo facilitar la instalación del software desarrollado en los terminalesfinales.

5

iBAN

Figura 2.3: iBAN desarrollada en este Proyecto Fin de Carrera.

empleada, en este caso, Bluetooth. En el caso particular del presente Proyecto Fin de Carrera,la iBAN está compuesta por tres elementos, tal y como se muestra en la figura 2.3, que son:

1. Un pulsioxímetro (véase el apartado 4.2.8.3), capaz de medir la saturación de oxígenoen sangre, el ritmo cardíaco e información pletismográfica (onda pletismográfica) dela persona que lo porta.

Aunque en este caso sólo hay un sensor, la arquitectura se ha diseñado paraque sea sencillo adaptarla a las necesidades de cada paciente. Por ejemplo, unapersona diabética podría llevar un glucómetro, o si tiene problemas vasculares,un pulsioxímetro y un electrocardiógrafo (ECG) simultáneamente. Al cambiar loscomponentes de la iBAN, el software del NI debe ser modificado para que tenga encuenta dichos cambios.

Así pues, el diseño del software del nodo central (NI) se ha llevado a cabo pensando enesta propiedad de escalabilidad, es decir, que la introducción de un nuevo elemento, ola eliminación de uno ya existente, tenga el menor impacto posible en el código de laaplicación, siendo reutilizable para pacientes con diferentes afecciones médicas y queporten diferentes dispositivos.

6

2. Un terminal GPS (véase el apartado 4.2.9) que proporciona la posición del paciente enentornos abiertos.

3. Un nodo central (NI), que es un teléfono móvil, donde reside la aplicación softwaredesarrollada en este Proyecto Fin de Carrera y que lleva a cabo las siguientesfunciones:

Localizar al resto de los dispositivos de la iBAN y conectarse a ellos víaBluetooth.

Gestionar la comunicaciones Bluetooth, posibilitando la lectura de los datosmedidos y la configuración del resto de componentes de la iBAN (pulsioxímetroy GPS).

Procesar la información de monitorización necesaria para detectar posiblessituaciones de emergencia.

Detectar una situación de emergencia, generar alarmas que envía a la UCMM ya los familiares del paciente monitorizado.

Transmitir la información médica y de localización al SCC.

Permitir al SCC la gestión remota de la iBAN, por medio del envío de comandosque el NI debe recibir e interpretar.

Por ejemplo, ofrecer la posibilidad de modificar los valores umbrales delos parámetros usados para la detección de alarmas, cambiar el modo defuncionamiento de los sensores de la iBAN, resetear un sensor en un instantedeterminado, cambiar el período de transmisión de los datos, etc. Gracias a ello,la UCMM y los PC de monitorización también podrán configurar la iBAN, através de su conexión con el SCC.

Finalmente, se puede decir que el nodo central de la iBAN (NI) actúa como una pasarelao gateway, entre la iBAN Bluetooth y el SCC, añadiendo a dicha comunicación unacierta “inteligencia”, gracias al tratamiento de la información para detectar situaciones deemergencia y a la posibilidad de gestionar remotamente la iBAN, desde el SCC, a través delpropio NI.

2.2.2. Terminales móviles para recepción de alarmas

Son terminales con conexión a la red de telefonía móvil, receptores de las alarmas generadaspor el NI en casos de emergencia3. En cada uno de ellos se ejecuta una aplicación softwareque se encarga de recibir estas alertas y notificar su llegada al usuario. La figura 2.4 muestrael esquema utilizado.

3En el apartado 2.1, se señala claramente que las alarmas llegan tanto a la UCMM de médico, como a losterminales de los familiares.

7

FAMILIARES DEL PACIENTE

RED DE TELEFONÍA MÓVIL

NI

APLICACIÓN DE RECEPCIÓNY

NOTIFICACIÓN DE ALARMAS

...

... ...

Figura 2.4: Envío de alarmas desde el NI a los familiares del paciente.

2.3. Estructura del sistema

En los siguientes apartados se especifican los objetivos y funciones de los subsistemascorrespondientes a la implementación del software del nodo central de la iBAN (apartado2.3.1) y de recepción de alertas en los terminales móviles de los familiares de los pacientes(apartado 2.3.2).

Finalmente, en el apartado 2.3.3, se describe brevemente la aplicación de instalación delsoftware desarrollado.

2.3.1. Subsistemas del software del NI

En el software del nodo central (NI), se pueden diferenciar los siguientes módulos osubsistemas:

1. Módulo de comunicaciones Bluetooth.

2. Módulo de comunicaciones con el Servidor de Control Central.

3. Módulo de gestión de comandos y control.

4. Módulo de procesamiento y gestión de alarmas.

2.3.1.1. Módulo de comunicaciones Bluetooth

Este módulo, que se detalla en el apartado 5.2.4, tiene por objetivo gestionar la comunicacióncon el resto de componentes de la iBAN (pulsioxímetro y GPS) y la información de

8

monitorización que genera, según la configuración establecida en la red de área corporal(modos de funcionamiento, tiempo de monitorización establecido, etc.). Sus funcionesprincipales son:

1. Buscar al resto de los dispositivos pertenecientes a la iBAN.

2. Establecer la conexión Bluetooth con todos ellos.

3. Recibir y almacenar la información procedente del pulsioxímetro y del GPS, según laconfiguración que tengan estos dispositivos en cada momento.

4. Registrar los estados de todas las conexiones Bluetooth establecidas, indicando si enun momento dado están activas o caídas.

5. Recuperar la conexión de las comunicaciones Bluetooth que se hayan perdido.

2.3.1.2. Módulo de comunicaciones con el SCC

El principal objetivo de este módulo es permitir al SCC la gestión remota de la iBAN: lecturade datos, conocimiento del estado de la iBAN, configuración de la iBAN, etc.

Las funciones que lleva a cabo son:

1. Enviar los datos recibidos de los dispositivos Bluetooth al SCC.

2. Recibir los comandos del SCC y entregarlos al módulo de gestión y control decomandos.

3. Enviar todas las respuestas e indicaciones generadas por el módulo de gestión y controlde comandos, al SCC.

4. Recuperar la conexión con el SCC, en caso de que se haya perdido.

En el apartado 5.2.5, se detalla su estructura y funcionamiento.

2.3.1.3. Módulo de gestión de comandos y control

Este módulo, que se detalla en el apartado 5.2.6, tiene como principal objetivo interpretar loscomandos generados por el SCC y supervisar el estado de los componentes de la iBAN paranotificar la ocurrencia de eventos.

Sus funciones son:

1. Interpretar los comandos del SCC (un comando por cada petición) para llevar a cabolas acciones adecuadas sobre la iBAN.

2. Ejecutar cada comando sobre el dispositivo pertinente.

9

3. Generar la respuesta con el resultado de la acción ejecutada (una respuesta por cadacomando) y notificarla al módulo de comunicaciones SCC, para que sea enviada alSCC.

4. Supervisar el estado de los elementos de la iBAN, a través del registro de estadosrealizado por el módulo de comunicaciones Bluetooth.

5. Indicar si algún elemento de la iBAN pierde su conexión con el NI a través del módulode comunicaciones con el SCC.

2.3.1.4. Módulo de procesamiento y gestión de alarmas

Este módulo tiene como objetivo supervisar los datos médicos y de localización del pacientey generar/enviar alarmas, a la UCMM del médico y a los móviles de los familiares, en casode detectarse una situación de emergencia. Sus funciones son:

1. Procesar los datos del paciente, verificando si los valores predefinidos de determinadosparámetros se encuentran fuera de rango.

2. Generar y enviar la alarma adecuada, según el evento ocurrido.

3. Posibilitar la modificación de los criterios usados para detectar esas situacionesde emergencia: valores umbrales de los parámetros médicos, valores umbrales deposición, etc.

En el apartado 5.2.7, se detalla su estructura y funcionamiento.

2.3.2. Subsistemas del software de recepción y notificación de alarmasen terminales móviles

Para la recepción y notificación de alarmas, se ha desarrollado un módulo de recepciónde mensajes de texto (SMS o Short Message Service) y mensajes multimedia (MMS oMultimedia Messaging Service). Este módulo, que se detalla en el apartado 6.2.3, lleva acabo las siguientes funciones:

1. Recibir las alarmas SMS/MMS enviadas por el NI.

2. Notificar al usuario la entrada de una alarma SMS/MMS de una manera “insistente”,dada la importancia de la información que contiene dicho mensaje.

3. Permitir la posibilidad de realizar una llamada de teléfono, desde la propia aplicación,a un teléfono de emergencias médicas prefijado o incluso al del propio pacientemonitorizado.

10

2.3.3. Aplicación web para la descarga de MIDlets

La aplicación web para la descarga de las aplicaciones del NI y de recepción de alarmas,consta de los siguientes módulos, que proporcionan una interfaz gráfica, sencilla y amigable,especialmente diseñada para usuarios con poca experiencia en navegación a través deinternet:

1. Módulo de autenticación de usuario que permite sólo el acceso a los usuarios que hansido previamente registrados, mediante la realización de un filtrado de las peticionesentrantes. Dichas peticiones se harán a través de un nombre de usuario (user) y unaclave (password). El apartado 7.4, aborda con detalle este módulo.

2. Módulo de descarga de software que facilita la descarga de las aplicaciones, en lamedida de lo posible, con una explicación clara y concisa de cómo el usuario debeproceder para su realización, sea desde un PC o desde un teléfono móvil. En el apartado7.4, se detalla su funcionamiento.

11

Capítulo 3

Tecnologías implicadas

3.1. Introducción

Este capítulo se divide en tres apartados, donde se presentan, respectivamente, las tecnologíasde comunicación implicadas en la realización del proyecto, los sistemas operativos másutilizados en la telefonía móvil y los lenguajes de programación empleados para el desarrollodel software objetivo.

3.2. Tecnologías de Comunicación

3.2.1. Bluetooth

Bluetooth es una tecnología de comunicación inalámbrica, creada por el SIG (SpecialInterest Group) [5], en la que se basa el estándar IEEE 802.15.1 (Standard for WirelessPersonal Area Networks adapted from the Bluetooth specificacion)[6]. Su principal objetivoes reemplazar los cables para la comunicación entre dispositivos electrónicos portablesy/o fijos (ordenadores, teléfonos móviles, PDA, impresoras, auriculares, etc.), facilitandoasí la comunicación entre ellos [7][8]. Opera en la banda de frecuencias sin licencia ISM(Industrial, Scientific and Medical) [9], a 2.4 GHz, utilizando la técnica de frequencyhopping para evitar interferencias y desvanecimientos (fading). Su régimen binario oscilaentre 1 Mbps (Basic Rate) de Bluetooth v1.1 y 2-3 Mbps (Enhaced Data Rate) de Bluetoothv2.0. Esta tecnología se caracteriza, principalmente, por su robustez, su bajo consumo y sucoste reducido [7].

Las redes de dispositivos Bluetooth se denominan Piconets. En ellas uno de los dispositivosactúa como maestro, el cual establece y gestiona el patrón de frequency hopping que seva a usar, y el resto, hasta 7 dispositivos en modo activo, como esclavos [7]. Los esclavospueden participar en Piconets distintas, de modo que varias Piconets conectadas entre síforman lo que se denomina una red Scatternet [10] (conexión entre dos maestros de Piconets

13

diferentes).

La arquitectura de protocolos de Bluetooth v1.1 se muestra en la figura 3.1 [11]. Estaarquitectura se divide en una serie de niveles con sus protocolos asociados, donde destacanlos siguientes:

Protocolos del núcleo Bluetooth (Bluetooth Core Protocols):

• Protocolo de RF (Radio Frequency). Se utiliza en el nivel radio (BluetoothRadio) que es, principalmente, un circuito de RF (Radio Frequency) a 2.4 GHzque modula y transmite la señal. Como técnica de modulación utiliza GFSK(Gaussian Frequency Shift Keying) y las potencias de transmisión oscilan entrelos 0 dBm (dispositivo de Clase 3) a 20 dBm (dispositivo de Clase 1) [7].Transforma los paquetes del Baseband a señal de RF y viceversa.

• Protocolo de Baseband. Se emplea en el nivel de banda base (Baseband).Especifica e implementa los mecanismos de acceso al medio y de la capa físicapara proporcionar comunicación de voz en tiempo real, intercambio de datos ygestión de la red Bluetooth (codificación/decodificación de paquetes Bluetooth,señalización de control, acceso a los canales radio, etc.) [7].

• Link ManagerProtocol (LMP). Permite al nivel Link Manager controlar el modode operación de los dispositivos Bluetooth (creación y control de enlaces lógicos,seguridad, adaptación de la potencia de transmisión, etc.) y proporcionar losservicios necesarios para la gestión de los niveles inferiores (Bluetooth Radioy Baseband) [7].

• L2CAP (Logical Link Control and Adaptation Protocol). Se responsabiliza de lacreación, gestión y destrucción de canales L2CAP para el transporte de datos, dela provisión de calidad de servicio (QoS), etc. [7].

• SDP (Service Discovery Protocol). Es un protocolo de aplicación, requerido portodos los dispositivos Bluetooth [7], que sirve para descubrir servicios Bluetoothdisponibles.

Otros protocolos de entidades de nivel superior que utilizan los servicios de L2CAP son:

RFCOMM (Radio Frequency Communication). Es un protocolo que permite laemulación de comunicaciones de cable serie (RS-232) [11].

TCS-BIN (Telephony Control Protocol Binary). Define la señalización de control encomunicaciones de voz entre dispositivos Bluetooth [11].

Tras explicar la pila de protocolos Bluetooth se ha de puntualizar que el nivel HCI (Hostto Controller Interface), cuya implementación es opcional [7], hace de interfaz entre el

14

Bluetooth Controller Subsystem (niveles RF, Baseband y LMP) y el resto de la arquitecturaBluetooth (Bluetooth Host System).

Una vez estudiada la pila de protocolos de Bluetooth (figura 3.1), hay que mencionar elconcepto de perfil Bluetooth. Los perfiles Bluetooth especifican los protocolos necesarios ysus modos de uso para proporcionar al usuario una funcionalidad determinada. Por ejemplo,en Bluetooth v.1.1 se han definido, entre otros, los siguiente perfiles [11]:

GAP (General Access Profile). Detalla los procedimientos generales para el des-cubrimiento y conexión entre dispositivos Bluetooth, además de ciertos aspectos deseguridad. Debe ser soportado obligatoriamente por todos los dispositivos Bluetooth.

Service Discovery Application Profile. Define los procedimientos y características quedebe tener una aplicación que reside en un dispositivo Bluetooth para poder llevar acabo el descubrimiento de otro dispositivo Bluetooth.

SPP (Serial Port Profile). Establece los requisitos necesarios para que un dispositivoBluetooth pueda emular conexiones de cable serie usando el protocolo RFCOMM.

Generic Object Exchange Profile. Detalla los protocolos y procedimientos que lasaplicaciones necesitan para el intercambio de objetos.

La última versión de Bluetooth es la 2.1, que ha sido anunciada para el año 2007 [12][13].En el ámbito de este proyecto hay que destacar que el teléfono utilizado como NodoInteligente (Nokia N93) posee Bluetooth v2.0, mientras que el pulsioxímetro Nonin 4100y el módulo GPS Leadtek 9553X soportan Bluetooth v1.1 y v1.2, respectivamente. Todosestos dispositivos operan a nivel RFCOMM.

Para mayor información sobre la tecnología Bluetooth se recomienda la lectura de [7].

3.2.2. Tecnologías de comunicaciones móviles

3.2.2.1. GSM

GSM (Global System for Mobile communications) es un estándar de telefonía móvil queintrodujo importantes cambios respecto a sus predecesores (estándares de 1a generación),por lo que se considera dentro de la 2a generación (2G) de sistemas de comunicación móvil[14]. Las bandas de frecuencias que emplea son las de 900/1800 MHz (Europa) y las de850/1900 MHz (Estados Unidos y Canadá). La velocidad máxima que ofrece es inferior a14.4 Kbps (Kilobits por segundo) y entre los servicios que proporciona destacan [15]: Fax,SMS (Short Message Service) y CBS (Cell Broadcast Service), etc.

15

Bluetooth Radio

Baseband

Link Manager

L2CAP

RFCOMM

PPP

TCP|UDP

IP

AT-Commands

Audio

TCS BIN SDP

OBEX

vCard/vCal

WAP

WAE

HCI (Host to Controller Interface)

BLUETOOTHCONTROLLERSUBSYSTEM

BLUETOOTHHOSTSYSTEM

Figura 3.1: Arquitectura de Bluetooth v1.1. Fuente: [11].

3.2.2.2. GPRS

GPRS (General Packet Radio Service) es un sistema de conmutación de paquetes, quehace uso de GSM para transmitir datos usando el protocolo IP (Internet Protocol) [15].Combinado con GSM, constituye un sistema de telefonía de generación 2.5 (2.5G). Susvelocidades están comprendidas entre los 64-144 Kbps [15], lo que le permite ofrecer lossiguientes servicios [16]: acceso WAP (Wireless Application Protocol), SMS, CBS, MMS(Multimedia Messaging Service), PTT (Push To Talk), email, acceso a web, mensajeríainstantánea, etc.

3.2.2.3. EGPRS

EGPRS (Enhanced GPRS) es una evolución de GPRS que ofrece mejores velocidades(máximo teórico de 473.6 Kbps) y fiabilidad en la transmisión de datos [17]. Se consideraun sistema de generación 2.75 (2.75G).

3.2.2.4. UMTS

UMTS (Universal Mobile Telecommunications System) constituye la 3a generación desistemas de comunicación móvil, alcanzando velocidades de transmisión superiores a las desus predecesoras (2G, 2.5G y 2.75G): 384-3600 Kbps. Las bandas de frecuencia utilizadaspor UMTS son las de 2100/1900 MHz (Europa), 850/1900 MHz (Estados Unidos) o850/2100 MHz (Australia) [18]. Gracias a su mayor ancho de banda, es capaz de ofrecernuevos servicios como: videoconferencia, descarga de audio y vídeo, TV en tiempo real, etc.

16

3.2.3. WiFi

WiFi (Wireless Fidelity) engloba un conjunto de estándares de comunicación inalámbricabasados en la norma IEEE 802.11 [19]. El IEEE 802.11 define un protocolo decomunicaciones, en sus niveles OSI (Open System Interconnection) físico y de enlace, parasu funcionamiento en una red de área local inalámbrica o WLAN (Wireless Local AreaNetwork) [20]. Actualmente destacan los siguientes estándares [20]:

1. IEEE 802.11b. Trabaja en la banda de 2.4 GHz (ISM) ofreciendo una velocidadmáxima de 11 Mbps (Megabits por segundo).

2. IEEE 802.11a. Emplea la banda de los 5 GHz, que está libre de otras tecnologías quecoinciden con la banda de 2.4 GHz (Bluetooth, microondas, etc.). Su velocidad alcanzalos 54 Mbps, pero al presentar problemas de compatibilidad con productos 802.11b nocosecha el éxito de su sucesor (802.11g).

3. IEEE 802.11g. Utiliza también la banda de 2.4 GHz, pero su velocidad máxima esde 54 Mbps. Permite la compatibilidad con productos conformes a la norma IEEE802.11b.

4. IEEE 802.11n. Hace uso de las bandas de frecuencias de 2.4 GHz y 5 GHz, con unavelocidad teórica que alcanza los 600 Mbps. En la actualidad, el estándar está siendocompletado y revisado, pero algunos productos cumplen con las especificaciones deun borrador de éste, alcanzando velocidades reales de 80-100 Mbps.

La mayoría de los dispositivos WiFi actuales cumplen los estándares IEEE 802.11b y/o IEEE802.11g. Véase [21] y [22] para obtener más información.

3.3. Sistemas operativos para teléfonos móviles

3.3.1. El sistema operativo Symbian OS

Symbian es un sistema operativo propietario, para teléfonos móviles, creado por un consorciode fabricantes (Nokia, Sony-Ericsson, Samsung, Siemens, etc.) denominado Symbian Ltd[23][24]. Su primera versión fue lanzada en 1999 (Symbian OS v5.0) y desde entoncesha ido evolucionando hasta la versión 9.5 (Marzo de 2007) [25]. Symbian se ejecuta,exclusivamente, en procesadores ARM [24][26] y de los fabricantes que lo soportan destacanNokia y Sony-Ericsson, entre otros [27]. En la actualidad, es el sistema operativo másutilizado en telefonía móvil, alcanzando el número de 110 millones de terminales en el año2006 [28].

Sus principales características son [29]:

17

Posibilita el desarrollo de aplicaciones y servicios, en diferentes lenguajes deprogramación (C++, Java, etc.) y usando distintos tipos de contenidos.

Implementación modular, constituida por un conjunto de API (Application Program-ming Interface) y tecnologías, compartida por todos los dispositivos Symbian. Haceposible la interoperabilidad entre fabricantes.

Sistema multitarea (kernel multitarea, comunicaciones, gestión de datos y gráficos,etc.).

Diseño flexible de la interfaz gráfica de usuario.

Para obtener mayor información sobre Symbian OS y sus versiones, consultar [25] y [30].

3.3.2. Otros sistemas operativos utilizados en teléfonos móviles

Además de Symbian, existen otros sistemas operativos para móviles como son:

Sistemas operativos propietarios: Nokia OS, Sony-Ericsson OS, etc.

Palm OS.

Windows Mobile.

Para más información véase las referencias [31], [32], [33] y [34].

3.4. Lenguajes de Programación

3.4.1. Java

Java, creado por Sun Microsystems, Inc. en 1991 [35], es un lenguaje de alto nivel y orientadoa objetos que desde su fecha de lanzamiento (1995), ha ido evolucionando y abarcandoámbitos a los que inicialmente no estaba dirigido. En principio, fue concebido para eldesarrollo de programas para ordenadores de sobremesa (J2SE, Java 2 Standard Edition).Con el tiempo, el lenguaje ha sido mejorado haciendo posible el desarrollo de aplicacionesdistribuidas (J2EE, Java 2 Enterprise Edition) y aplicaciones para teléfonos móviles1 (J2ME,Java 2 Micro Edition). Su principal ventaja es la portabilidad, es decir, la independencia dela plataforma sobre la que el código Java va a ser ejecutado.

En la figura 3.2, se muestran las tres plataformas que se engloban dentro del lenguaje Java yque anteriormente han sido comentadas [36]: J2SE, J2EE y J2ME .

1Se recomienda la lectura del apéndice A que incluye un glosario de terminología Java relacionada conJ2ME.

18

JAVA VIRTUAL MACHINE (JVM)

Java 2Enterprise

Edition(J2EE)

Java 2Standard

Edition(J2SE)

KVM

OptionalPackages

OptionalPackages

OptionalPackages

CLDCCDC

Foundation Profile

Personal Profile

MIDP

CardVM

JavaCardAPIs

Servers

OPERATING SYSTEM

HARDWARE

Desktopmachines

1

2

High-endconsumerdevices

3 4

5

Low-endconsumerdevices

Smart-Cards

Java 2 Micro Edition (J2ME)

Java 2 Platform

Figura 3.2: Arquitectura Java. Fuente: [36].

3.4.2. J2ME

J2ME (Java 2 Micro Edition), tal y como se ha visto en el apartado anterior, es la plataformaque ofrece Java para la creación de aplicaciones en dispositivos con recursos limitados(teléfonos móviles, PDA, smartphones, etc.). Su arquitectura aparece en la figura 3.2, y loselementos que la componen son los siguientes [37][38][39]:

1. Las configuraciones, que son el conjunto mínimo de librerías que proporcionan lafuncionalidad básica para la creación de aplicaciones J2ME y que son independientesdel propósito de los dispositivos. Hay dos tipos, que se explican a continuación:

CLDC (Connected Limited Device Configuration). Pone a disposición delprogramador una versión reducida de algunos paquetes de J2SE (java.lang,java.io, java.util) y un paquete llamado javax.microedition.io, para conexionesde red [38]. Es apropiada para el desarrollo de programas que se van a ejecutaren dispositivos con capacidades de proceso y memoria limitadas, tales comoteléfonos móviles y PDA (Personal Digital Assistant). CLDC 1.1 es la versiónactual, que se define en la JSR (Java Specification Request)-1392.

2Aunque todas las JSR se encuentran disponibles en [40], se recomienda la lectura del apéndice B, dondese ha incluido cierta información sobre las principales JSR de J2ME (número de JSR, API, nombre y URL parasu descarga).

19

CDC (Connected Device Configuration). Ofrece un mayor número de paquetesque CLDC, siendo su funcionalidad bastante más parecida a la de J2SE(versión 1.4) . Se ajusta a dispositivos que tienen mayor velocidad de procesoy memoria que los dispositivos propios de CLDC. Entre ellos se encuentranalgunos electrodomésticos inteligentes (domótica), decodificadores de televisiónpor satélite, sistemas de telemetría, dispositivos embedidos, etc. [37]. La últimaversión es la CDC 1.1, definida en la JSR-218.

Actualmente, la funcionalidad ofrecida por CLDC, su perfil (MIDP, Mobile Informa-tion Device Profile) y sus paquetes opcionales está muy próxima a la de CDC, lo que semanifiesta en el hecho de que CLDC, a diferencia de CDC, esté presente en la mayoríade teléfonos Java actuales [41]. La portabilidad de una misma aplicación entre un grannúmero de terminales, junto con la funcionalidad total capaz de proveer, convierten aCLDC en la configuración preferida para la creación de aplicaciones para dispositivosmóviles [37].

2. Los perfiles, que extienden la funcionalidad de las configuraciones subyacentesofreciendo, por tanto, las liberías necesarias para ello. Se definen según lascaracterísticas y propósito de los dispositivos finales. Son cuatro y se clasifican segúnla configuración sobre la que trabajan [37]:

Un único perfil asociado a la configuración CLDC, que es el MIDP (Mobile In-formation Device Profile). Ofrece la funcionalidad necesaria para el desarrollode aplicaciones para terminales móviles (interfaz gráfica de usuario, conectivi-dad, almacenamiento persistente de datos, etc.). Aunque MIDP 2.0, definido enla JSR-118, es el perfil actualmente implementado por los teléfonos móviles, laversión 3.0 ya está especificada en la JSR-271[40].

Encima de MIDP 2.0 se disponen los paquetes opcionales JSR-75 (PDA OptionalPackages for the J2MEPlatform), JSR-82 (Java APIs for Bluetooth), JSR-135(Mobile Media API 1.1), JSR-177 (Security and Trust Services API), JSR-205(Wireless Messaging API 2.0), etc., que aumentan, a su vez, la funcionalidad ylos servicios que este perfil ofrece.

Tres perfiles asociados a CDC:

• Foundation Profile. Este perfil trabaja sobre la configuración CDC. Propor-ciona conectividad, pero no permite crear interfaces gráficas de usuario. Enla JSR-219, se define su versión 1.1.

• Personal Profile. Añade al perfil Foundation Profile las funciones necesariaspara crear una interfaz gráfica de usuario y otras de conectividad adicionales.El Personal Profile 1.1 que se define en la JSR-216.

• Personal Basis Profile. Es un subconjunto del Personal Profile que propor-ciona funciones de conectividad y una interfaz gráfica limitada . Su última

20

versión es la 1.1, definida en la JSR-217.

3. Una máquina virtual Java. Según la configuración y perfiles empleados, las necesi-dades (capacidades de proceso, memoria, interfaz gráfica, etc.) serán diferentes. Deacuerdo con esto, la máquina virtual Java asociada también será diferente. Hay dostipos, que son los siguientes [37]:

KVM (Kilobyte Virtual Machine). Ocupa tan sólo unos kilobytes, como supropio nombre indica, estando optimizada para dispositivos móviles, sistemasembedidos y PDA. Se implementa en los dispositivos MIDP (CLDC).

JVM (Java Virtual Machine). Se caracteriza porque es utilizada por lasplataformas J2SE y J2EE, y también por los programas J2ME desarrolladosmediante la configuración CDC.

Una exposición más detallada de la plataforma J2ME puede encontrarse en [37][38][39].

3.4.3. HTML

HTML (Hyper Text Markup Language) es un lenguaje creado en los años 90, por el WordWide Web Consortium (W3C), www.w3c.org, con el fin de especificar la estructura y elformato de un página web de una manera universal [42]. HTML permite [43]:

Crear documentos web con cabeceras, texto, tablas, listas, fotos, etc. especificandotodas sus características.

Recuperar información o vincular una información con otra, a través de enlaces dehipertexto.

Diseñar formularios para llevar a cabo transacciones de diversos tipos: búsqueda deinformación, reservas, compra de productos, etc.

Incluir, directamente, vídeo, sonido y otras aplicaciones en una página web.

En Diciembre de 1999 aparece su última versión que es HTML 4.01 [43].

3.4.4. PHP

PHP (PHP Hypertex Pre-processor) es un lenguaje de alto nivel, de código abierto, orientadoal desarrollo de aplicaciones servidoras que permiten crear y gestionar contenido dinámicoen páginas web [44]. Está embedido en el código HTML y es leído, interpretado y ejecutadopor el servidor web que aloja la página HTML, y nunca por el cliente, es decir, por elnavegador que solicita la página. Tiene una sintaxis parecida a los lenguajes C y Perl y

21

www.w3c.org

es muy utilizado para la conectividad a bases de datos (posee soporte para un gran númerode bases de datos nativas) [45].

Su última versión, PHP 5.2.2, ha sido lanzada en Mayo de 2007 [46] y está disponible parasu descarga en [47].

3.5. Lenguaje Unificado de Modelado (UML)

UML (Unified Modeling Language) es un lenguaje para el modelado de software, creado porla OMG (Object Management Group) en 1997 [48]. Según el OMG [49]:

“UML ayuda a especificar, visualizar y documentar, modelos de sistemas soft-ware, incluyendo su estructura y diseño, cumpliendo los requisitos solicitados.Se puede modelar cualquier tipo de aplicación, sea cual sea el hardware dondese ejecute, el sistema operativo, el lenguaje de programación y la red utilizada.”

Por lo tanto, UML es un lenguaje que permite especificar y construir el modelo de un sistemasoftware objetivo (modelo UML), sin establecer la metodología o el proceso a seguir en sucreación. En su versión 2.0 (2005), que incluye importantes cambios respecto a las versionesanteriores, se dispone de trece tipos de diagramas que se dividen en tres grupos claramentediferenciados[48][49]:

1. Diagramas de estructura. Representan la estructura estática del sistema. Aunqueincluye seis tipos, los más representativos son [54]:

Diagrama de Clases. Detalla la estructura de las clases e interfaces que componenel sistema (atributos y métodos), además de reflejar cómo se relacionan entre sí.

Diagrama de Componentes. Ofrece una vista física del sistema. Sirve pararepresentar las dependencias que existen entre los componentes software queconstituyen el sistema (librerías que utiliza una clase, ficheros que implementanun elemento software, etc.).

Diagrama de Despliegue. Muestra el hardware donde se ejecutarán los distintoselementos del sistema y cómo estos se comunican entre sí.

2. Diagramas de comportamiento. Representan cómo se comporta el modelo. Hay trestipos [54]:

Diagrama de Casos de Uso. Expresa la funcionalidad que proporciona el sistema,reflejando cómo los “actores” (una persona, una máquina, etc.) interaccionan conéste, a través de los diferentes “casos de uso”. Un “caso de uso” representa unaunidad de funcionalidad que puede ser empleada por un “actor” o por otro “casode uso”.

22

Diagrama de Actividades. Se utilizan para mostrar el flujo de control entre dos omás entidades mientras procesan una actividad.

Diagrama de Máquinas de Estados. Representa los diferentes estados en los quepuede estar una clase y cómo realiza la transición entre ellos.

3. Diagramas de interacción. Son derivados de los Diagramas de comportamiento yreflejan la interacción y el flujo de datos entre los distintos elementos del sistemamodelado. Existen cuatro tipos, pero destaca principalmente uno de ellos [54]:

Diagrama de Secuencia. Detalla el flujo de ejecución de un caso de uso específicoo de una parte de éste. En él se aprecian las llamadas entre los diferentes objetosque intervienen en la secuencia.

Aunque su última versión es UML 2.1.1 [51], en este proyecto se ha utilizado UML 2.1.

Para obtener más información sobre UML y sus diferentes tipos de diagramas, se recomiendala lectura de [52][53][54].

3.6. Herramientas de desarrollo

En esta sección se presenta el software empleado en el desarrollo de las aplicaciones queforman parte del ámbito del presente Proyecto Fin de Carrera. Las herramientas de desarrolloutilizadas han sido las siguientes:

Eclipse SDK (Software Development Kit).

Carbide.j (Nokia Developers Suite for J2ME).

NCF (Nokia Connectivity Framework).

Nokia PC Suite.

Sun Java Wireless Toolkit for CLDC.

Ethereal.

En cada uno de los apartados sucesivos se describirá el ámbito de utilización de cada una deestas herramientas, sus principales funciones y características, además del uso particular quese ha hecho de ellas durante la ejecución de este proyecto.

23

JDT CDT PDE

Integrated Development Environment (IDE)

Eclipse Runtime Platform

Rich Client

Platform

(RCP)

Applications

Contributed Plug-ins

Web Tools Platform

(WTP)

Bloques incluidos, por defecto, en Eclipse SDK.

Figura 3.3: Arquitectura de Eclipse SDK [55].

3.6.1. Eclipse SDK (Software Development Kit)

Centrándose en el uso que se ha hecho de esta herramienta, durante el presente ProyectoFin de Carrera, Eclipse podría definirse como un entorno de desarrollo integrado o IDE,de código abierto, que facilita al desarrollador la tarea de la programación gracias a susmúltiples características. Además, es funcionalmente extensible mediante la adición demódulos o plug-ins, lo que le permite adaptarse a las necesidades de cada usuario.

Las propiedades que lo caracterizan son [55]:

Multi-plataforma. Permite su ejecución en varios sistemas operativos como sonWindows, Linux, Solaris, AIX, HP-UX y Mac OSX.

Multi-lenguaje. Aunque está escrito en lenguaje Java y por defecto sólo permiteel desarrollo de este tipo de aplicaciones, con la integración de los plug-inscorrespondientes es posible utilizar otros lenguajes de programación como C/C++,Cobol, Python, Perl, PHP, etc.También está disponible en un gran número de idiomas [56], incluyendo el español.

Multi-rol. Además de las utilidades para la programación, Eclipse permite realizarmodelado (UML, por ejemplo), test de aplicaciones, creación de páginas web de formavisual (Web authoring), etc.

Eclipse posee una arquitectura modular, tal y como refleja el esquema de bloques de la figura3.3 [55][57]:

A continuación, se describen sus componentes brevemente:

1. Eclipse Runtime Platform: es la base de la arquitectura y provee los siguientes serviciosbásicos:

24

Registro de plug-ins: carga y gestiona los módulos disponibles.

Gestión de los recursos del sistema operativo.

Componentes de la interfaz gráfica de usuario.

Herramienta de actualización de plug-ins.

Ayuda de Eclipse.

2. Integrated Development Environment (IDE): sus servicios genéricos, idénticos entodos los plug-ins de lenguajes de programación, son:

Vistas: elementos gráficos, generalmente pestañas con listas de elementos,utilizados para la ejecución de tareas de bajo nivel (creación de un proyecto,búsqueda de ficheros, visualización de errores de compilación, etc.). En la figura3.4, se aprecian varias vistas dentro de la perspectiva Java de Eclipse.

Perspectivas: conjunto de vistas, relacionadas entre sí, que unifican su funcionali-dad para la realización de tareas de alto nivel (creación de una aplicación en Java,depuración de un programa, etc.). Las figuras 3.5 y 3.6, presentan dos de estasperspectivas.

Configuración de preferencias de los módulos instalados en Eclipse.

Motor de búsqueda de archivos (Java, C/C++, texto, UML, etc.) incluidos en losproyectos creados con Eclipse.

Depuración de aplicaciones por medio del depurador o debugger.

Cabe destacar la existencia de problemas en la depuración de programas J2ME,mediante el uso del plug-in EclipseME [58]. Debido a ello, no ha sido posibleaprovechar esta facilidad. No obstante, la depuración de código J2SE, que es laque Eclipse permite por defecto, ha sido testeada y probada satisfactoriamente.

Integración de Ant.

Ant es una herramienta que posibilita el procesamiento automático de tareas(compilación, creación de paquetes y emulación), sobre ficheros de código queforman parte de un proyecto, mediante la edición de un fichero XML (eXtensibleMarkup Language) [59].

Control de versiones con CVS (Current Versioning System).

Herramienta que permite la modificación simultánea de código de un proyecto,por parte de varios programadores, registrando todos los cambios realizados y unhistorial de sus versiones existentes [60].

Otros servicios, no genéricos, son:

Asistente de contenido (resaltado de sintaxis, sugerencia de atributos de unmétodo/procedimiento, etc.)

25

• Plantillas de código: bucles for, while, etc.• Asistente para el formato del código: sangrías, alineación, etc.• Identificación de problemas en tiempo real: la compilación se hace en tiempo

real, así que los errores del programa se notifican tras la realización de esteproceso.

3. JDT (Java Development Tool).

Único plug-in de lenguaje de programación que incluye Eclipse por defecto. Es elconjunto de funcionalidades (editor, depurador, etc. ) necesarias para el desarrollo deaplicaciones Java (J2SE). Sus servicios son:

Editor, diagramas de jerarquía de clases, asistente de contenido, plantillas decódigo y asistente para el formato del código.

Vistas Java.

Asistente de configuración de proyectos.

Depurador o debugger.

La figura 3.7, muestra el editor Java y otros servicios del JDT.

4. WTP (Web Tools Platform): soporte para aplicaciones web y J2EE.

5. CDT (C/C++ Development Tools): soporte para los lenguajes de programación C yC++.

6. PDE (Plug-in Development Environment): herramientas para el desarrollo de módulospara Eclipse.

7. Aplicaciones RCP (Rich Client Platform): aplicaciones de usuario, de alto contenidográfico, que el programador puede diseñar basándose en los elementos gráficos ymódulos empleados para la construcción de Eclipse.

8. Plug-ins: módulos opcionales capaces de aumentar las funciones y prestaciones deEclipse.

La versión disponible de Eclipse SDK [61], incluye las capas Eclipse Runtime Platform,Integrated Development Environment, JDT y PDE (véase la figura 3.3).

El amplio abanico de posibilidades que ofrece, el hecho de ser de código abierto y laflexibilidad que existe a través de la integración de plug-ins, han sido determinantespara la elección de Eclipse como herramienta de desarrollo en este proyecto. Aunque suversión actual es la 3.2.2, se han empleado las versiones 3.1.1 y 3.1.2, debido a motivos decompatibilidad con Carbide.j, software que se trata en el siguiente apartado.

26

Vista Search(búsqueda de ficheros)

Vista Outline(jerarquía de clases)

Vista Package Explorer(exploración de los proyectos creados)

PERSPECTIVA JAVA

Figura 3.4: Vistas y perspectivas de Eclipse.

Figura 3.5: Perspectiva Java de Eclipse.

27

Figura 3.6: Perspectiva Debug de Eclipse.

Figura 3.7: Editor Java y algunos servicios del JDT.

28

La utilización de Eclipse se ha centrado, básicamente, en la escritura y corrección del códigode las aplicaciones J2ME desarrolladas.

Para obtener mayor información sobre Eclipse véase [55][62][63].

3.6.2. Carbide.j (Nokia Developers Suite for J2ME)

Carbide.j, formalmente Nokia Developers Suite for J2ME, es un software para desarrol-ladores de aplicaciones J2ME que puede ser incluido, como plug-in, en diferentes IDE comoson Eclipse, NetBeans o IBM WebSphere Studio Developer, entre otros [64]. Esta herramien-ta es gratuita y se puede descargar desde la página oficial de Forum Nokia [65].

Aunque Carbide.j se ha utilizado como un software asociado a un IDE, también es posiblesu uso como una herramienta independiente.

Carbide.j proporciona un amplio conjunto de herramientas para que el programador puedacrear, emular, verificar y firmar aplicaciones J2ME para dispositivos Nokia. Los emuladoresque incluye inicialmente abarcan todas las plataformas de teléfonos móviles que Nokia tieneactualmente en el mercado: Serie 80, Serie 60 y Serie 40. Véase el apéndice C para másinformación.

Entre sus características principales destacan [66][67]:

1. Asistente de creación de clases Java.

2. Diseño de interfaces gráficas de usuario.

3. Asistente de creación de paquetes.

En J2ME la creación de un paquete está asociada a la creación de los ficheros.JAD (Java Application Descriptor) y .JAR (Java ARchive) que son necesarios para lainstalación del programa J2ME en el teléfono móvil correspondiente. El fichero .JADcontiene información (atributos) sobre la aplicación creada: nombre, versión, autor,configuración y perfil utilizados, MIDlet/s que contiene, icono representativo de cadaMIDlet, etc.Por otro lado, el fichero .JAR guarda las clases de Java compiladas (ficheros .class),algunos de los recursos adicionales utilizados por el programa (ficheros de texto,imagen y sonido)3 y varios de los atributos más significativos del fichero .JAD. Estesubconjunto de atributos se guardan en un fichero, denominado manifiesto del .JAR,cuyo contenido será incluido en el .JAR final. En la figura 3.8, se observa la pestaña decreación/edición de los ficheros .JAR y .JAD que ofrece Carbide.j, durante la creaciónde un paquete.

3En J2ME es posible utilizar un recurso externo, por ejemplo un fichero de texto, que se encuentre en lamemoria interna o externa del dispositivo móvil donde reside la aplicación. Esto es posible mediante el uso laJSR-75 (File Connection and PIM API).

29

4. Firma de paquetes.

Carbide.j ofrece la posibilidad de firmar una aplicación mediante un certificadoexpedido por una Autoridad de Certificados (CA o Certificate Authority) o generadopor el propio programador (autocertificado o self-certificate). Véase [68] [69] [70],para conocer más detalles sobre el modelo de seguridad de J2ME y la firma de estetipo de aplicaciones.

5. Soporte para los perfiles MIDP (Mobile Information Device Profile) y PP (PersonalProfile).

Permite la creación, prueba y emulación de aplicaciones MIDP y PP.

6. Gestión y configuración de los emuladores integrados.

La figura 3.9 refleja la apariencia de varios de los emuladores que Carbide.j in-tegra por defecto. Además de los disponibles, la herramienta permite la utilización denuevos emuladores por medio de la instalación de los denominados SDK (SoftwareDevelopment Kit). Un SDK es un conjunto de herramientas asociado a una plataformamóvil (Serie 80, Serie 60 o Serie 40) o a un modelo de teléfono móvil concreto,integrado por:

Preverificador de clases.

Emuladores.

Ejemplos de código.

Documentación.

El SDK correspondiente a una serie o a un teléfono ofrecerá al desarrollador las APIde programación correspondientes a los interfaces JSR soportadas por el teléfono o laserie a la que representa. En Forum Nokia [71] están disponibles los SDK de las Series80, 60 y 40, así como de ciertos modelos Nokia específicos.

Cuando un nuevo SDK Java es descargado e instalado, éste se integra en Carbide.j,permitiendo al usuario la emulación de toda su funcionalidad a través de su interfazgráfica. Además, si la herramienta está integrada con Eclipse, el nuevo SDK esdetectado por dicho IDE mediante una operación manual. Una vez finalizada ladetección, Eclipse permite seleccionar el SDK con el que se desea desarrollar unaaplicación.

7. Depuración de aplicaciones J2ME en el propio dispositivo móvil.

Es lo que se denomina ODD (On-Device-Debugging). Este aspecto sólo estádisponible para Carbide.j versión 1.5 (Julio del 2006) y dispositivos pertenecientes a

30

(a) Atributos de los ficheros .JAD y manifiesto del .JAR. (b) Vista previa de los ficheros .JAD y manifiesto del.JAR, que se van a generar.

Figura 3.8: Pestaña de creación/edición de los ficheros .JAR y .JAD, en Carbide.j 1.5.

la Serie 60 3a Edición. La conexión entre el dispositivo móvil y el PC donde resideCarbide.j se realiza a través de Bluetooth o WiFi.A lo largo de la realización de este proyecto se ha comprobado que la depuraciónODD falla con programas J2ME con un alto grado de complejidad: multithread,comunicaciones de diferentes tipos (Bluetooth, TCP/IP, UDP, HTTP, etc.

8. Soporte de scripts Ant, para la automatización de tareas de compilación, creación depaquetes y emulación.

Entre los requisitos de sistema para su instalación destaca la necesidad de emplear elSistema Operativo Windows XP Professional (SP2 o posterior) y la del Sun Java RuntimeEnvironment (JRE) v1.4.2_06 o posterior.

Su elección como software de desarrollo, además de por sus notables características, se hadebido al requisito de utilización del teléfono móvil Nokia 9500, único terminal disponibleal inicio del proyecto.

Durante la ejecución del proyecto han sido empleadas la versión 3.0.1 (Nokia DevelopersSuite) y las versiones 1.0 y 1.5 (Carbide.j). El uso de esta herramienta se ha centrado en laprueba, verificación y depuración de las aplicaciones desarrolladas, en aquellos casos en losque la emulación era posible.

Para profundizar más en las características y el manejo de Carbide.j 1.5, véase [67].

31

(a) Emulador de laSerie 40.

(b) Emulador de la Se-rie 60.

(c) Emulador de la Serie 80.

Figura 3.9: Emuladores de la Serie 80, Serie 60 y Serie 40 de Nokia, que incorpora Carbide.j1.5.

32

3.6.3. NCF (Nokia Connectivity Framework)

Esta herramienta se instala junto con Carbide.j, siendo su función principal proporcionar elsoporte necesario para permitir el correcto funcionamiento de los emuladores integrados endicha herramienta. NFC posee las siguientes características [72][73]:

1. Soporte para diferentes tecnologías de comunicación.Se puede verificar la conectividad de una aplicación (conexión a internet, Bluetooth,IrDA, SMS o MMS) sin instalar el programa en el dispositivo final.

2. Conectividad entre software SDK diferentes.Es posible la comunicación entre emuladores pertenecientes a SDK diferentes,instalados en un mismo PC. Esta funcionalidad ha sido utilizada en el proyecto parala realización de pruebas de comunicación Bluetooth entre instancias de emuladordistintas.

3. Conectividad entre software SDK y dispositivos reales .Permite la conexión entre emuladores pertenecientes a los SDK que residen en el PCy dispositivos hardware con tecnología Bluetooth, IrDA, SMS o MMS.Gracias a ello, a través de un programa ejecutado en un emulador, ha sido posiblerealizar la búsqueda de dispositivos y servicios Bluetooth reales, en una de las pruebasrealizadas en el presente Proyecto Fin de Carrera. Véase el apartado de pruebasrealizadas 9.1.1.1, para más detalles.

4. Conectividad entre software SDK y un servidor de aplicaciones.

5. Soporte para monitorización de las comunicaciones.Las comunicaciones gestionadas por NCF, pueden ser monitorizadas gracias a unaherramienta de log que ofrece la información a través de una consola. Se puede, porejemplo, analizar el contenido del tráfico HCI (Host Controller Interface) Bluetooth.

6. Autodetección de nuevos SDK.Los nuevos SDK de Nokia instalados se detectan e integran automáticamente en NCF.

7. Asistentes o wizards para la integración de software o hardware, compatible con NCF,no autodetectable.

8. Soporte hardware.NCF admite la conectividad entre emuladores y tarjetas hardware (Nokia D211,Socket Bluetooth, etc.) o entre emuladores y adaptadores USB con tecnologíaBluetooth.

La figura 3.10 muestra la pantalla principal del programa. En la ventana derecha, decolor blanco, la aplicación permite arrastrar elementos gráficos. Estos elementos gráficosrepresentan a componentes software y hardware, integrados en NCF, que el usuario desea

33

Figura 3.10: Aspecto de la ventana principal del programa Nokia Connectivity Framework1.2.

comunicar entre sí. Una vez ubicados en el panel, los elementos se configuran segúnlas propiedades de las comunicaciones que se quiera establecer entre ellos. Tras estaconfiguración, queda definido lo que se denomina “escenario de test” [72] [73]. Finalmente,el usuario puede monitorizar dichas comunicaciones, e incluso llevarlas a cabo de forma real,sin necesidad del dispositivo final.

Un ejemplo de escenario de test es representado en la figura 3.11, donde un emuladorperteneciente al Prototype SDK 4.0 S60 MIDP Emulator pretende comunicarse condispositivos Bluetooth reales, por medio de un adaptador USB Bluetooth.

La elección de Carbide.j lleva implícito este software, como se ha comentado al inicio delapartado. En todo el período de realización del proyecto se ha utilizado el programa NCFversión 1.2.

3.6.4. Nokia PC Suite

Es otro de los programas que se instalan junto con Carbide.j, aunque también es posibleencontrarlo para descargar individualmente en Forum Nokia [74]. Está orientado más haciael usuario que hacia el programador de aplicaciones, ya que se utiliza para el manejo yconfiguración de las comunicaciones entre un PC y un teléfono Nokia, permitiendo la gestióndel dispositivo móvil desde el PC. Posee soporte para conexiones Bluetooth, infrarrojos y

34

Figura 3.11: Escenario de test con un emulador de la Serie 60 y un adaptador USB Bluetooth.

USB.

En la figura 3.12, que refleja la ventana principal del programa, hay un icono por cada unode las funciones ofrecidas.

Todas las funciones son bastante autoexplicativas. Por ejemplo, PC Suite permite al usuarioel acceso a la agenda de contactos, mensajes de texto/multimedia, imágenes y vídeosalmacenados en el terminal. Además, es posible la trasferencia, en ambos sentidos, deficheros de texto, audio y vídeo.

Para el desarrollo de las aplicaciones del proyecto, las funciones más utilizadas han sido:

1. Gestión de conexiones. Esta función es muy útil para conectar terminales móviles aPC Suite, via Bluetooth, IrDA o USB. En el proyecto se ha empleado la conexiónBluetooth y USB.

2. Instalación de aplicaciones. Ha sido la función más empleada de todas ya que eranecesaria para la realización de pruebas en los dispositivos reales. Un proceso deinstalación de una aplicación J2ME, en un teléfono Nokia, se muestra en la figura3.13.

A la izquierda se aprecia el sistema de ficheros del equipo donde reside PC Suite.A la derecha, el sistema de ficheros de la memoria interna o externa del teléfono

35

Figura 3.12: Ventana principal del programa PC Suite 6.8.

36

Figura 3.13: Instalación de un programa J2ME, en un teléfono Nokia N70, mediante PCSuite 6.8.

móvil destino. Si hay varios teléfonos conectados, la herramienta permite fácilmentela selección de cualquiera de ellos en la misma pantalla de instalación.

3. Gestión de si

pasarela bluetooth/gprs para dispositivos...

Documents