ESCUELA SUPERIOR DE INGENIEROS
INGENIERÍA DE TELECOMUNICACIÓN
PROYECTO FIN DE CARRERA
Servicio 3G de Teleasistencia basado en tecnología
OSA/Parlay
Raúl Parras Eliche Tutora: Isabel Román Martínez
Abril 2007
Dedicado a mis padres, mis abuelos
y a mi hermana Sara.
Quiero dar las gracias de manera muy especial a
Isabel Román Martínez que me ha ayudado y guiado
en la realización del presente proyecto a lo largo de
éstos últimos meses.
Índice general
Raúl Parras Eliche 7
Índice general
Índice figuras...................................................................................................... 10
Capítulo I ............................................................................................................ 13
Introducción General ......................................................................................... 13
1. Motivación y objetivos..................................................................................... 15
2. Ejecución temporal .......................................................................................... 22
3. Material empleado ........................................................................................... 25
4. Material empleado ........................................................................................... 27
Capítulo II .......................................................................................................... 30
Introducción Teórica.......................................................................................... 30
1. Los servicios 3G ............................................................................................... 32 1.1 Introducción ..........................................................................................................32 1.2 IMT (International Mobil Telecomunications) .....................................................34
1.2.1 Objetivos de IMT-2000 ....................................................................................34 1.2.2 Requisitos de un sistema de tercera generación ...............................................35
1.3 Los factores de éxito de 3G...................................................................................36 1.4 El Foro UMTS ......................................................................................................38
2. OSA/Parlay....................................................................................................... 41 2.1 Introducción ..........................................................................................................41 2.2 Beneficios de OSA/Parlay.....................................................................................44
2.2.1 Rapidez en la creación de servicios..................................................................44 2.2.2 Independencia de la red....................................................................................44 2.2.3 Independencia del fabricante ............................................................................45 2.2.4 Existencia de un gran número de desarrolladores de aplicaciones ...................45 2.2.5 Vendedores de aplicaciones y servicios basados en OSA/Parlay ind...............45
2.3 Arquitectura de OSA.............................................................................................46 2.4 Mecanismos básicos de OSA ................................................................................46
2.4.1 Mecanismos Básicos entre Aplicaciones y Armazón .......................................47
Índice general
Raúl Parras Eliche 8
2.4.2 Mecanismos Básicos entre Armazón y SCS .................................................... 48 2.4.3 Mecanismos Básicos entre Servidor de Aplicaciones y SCS........................... 48
2.5 Seguridad relacionada con el usuario final ........................................................... 48 2.5.1 Autorización a los usuarios finales para usar aplicaciones .............................. 48 2.5.2 Autorización a las aplicaciones de los usuarios finales.................................... 49 2.5.3 Opciones de privacidad del usuario final ......................................................... 49
2.6 OSA/Parlay en la Red de Telecomunicaciones .................................................... 49 2.7 Especificación de OSA/Parlay.............................................................................. 50
2.7.1 SCF Control de Llamada ................................................................................. 52 2.7.1.1 SCF Control de Llamada Genérico ........................................................ 54 2.7.1.2 SCF Control de Llamada Multi-Partícipe............................................... 56 2.7.1.3 SCF Control de Llamada Multimedia .................................................... 57 2.7.1.4 SCF Control de Llamada de Conferencia............................................... 59
2.7.2 SCF Interacción de Usuario ............................................................................. 62 2.7.3 SCF Movilidad................................................................................................. 63
3. MiLife™ ISG SDK...........................................................................................66 3.1 Introducción.......................................................................................................... 66
3.1.1 MiLife™ ISG................................................................................................... 67 3.1.2 MiLife™ ISG SDK.......................................................................................... 69
3.2 Simulador ISG ...................................................................................................... 71 3.2.1 Estructura del SDK .......................................................................................... 71 3.2.2 Configuración del simulador ISG .................................................................... 75 3.2.3 Paneles de simulación...................................................................................... 83
3.3 Convenience Classes ............................................................................................ 89 3.3.1 OSA/Parlay convenience classes ..................................................................... 89 3.3.2 Script convenience classes............................................................................... 91
3.4 Scripts XML ......................................................................................................... 91
Capítulo III ......................................................................................................... 98
Desarrollo del Proyecto ...................................................................................... 98
1. Introducción....................................................................................................100
2. Base de Datos..................................................................................................103
3. Configuración y creación del entorno de simulación..................................107
4. Clases de la aplicación ...................................................................................109 4.1 Paquete BaseDeDatos......................................................................................... 113 4.2 Paquete EstadoTerminal ..................................................................................... 114 4.3 Paquete Localizacion.......................................................................................... 116 4.4 Paquete InteracciónUsuario ................................................................................ 117 4.5 Paquete MensajeriaMultimedia .......................................................................... 121 4.6 Paquete Gestion .................................................................................................. 123 4.7 Paquete TipoDatos.............................................................................................. 126
Capítulo IV........................................................................................................ 130
Conclusiones y líneas futuras .......................................................................... 130
Capítulo V ......................................................................................................... 134
Índice general
Raúl Parras Eliche 9
Referencias bibliográficas................................................................................ 134
Capítulo VI ....................................................................................................... 139
Anexos............................................................................................................... 139
1. Anexo I: Archivo de simulación: teleasistencia.xml ................................... 141
2. Anexo II: Código de la Aplicación................................................................ 149 2.1 Teleasistencia.java ..............................................................................................149 2.2 Paquete BaseDeDatos .........................................................................................153
2.2.1 BBDD.java .....................................................................................................153 2.3 Paquete EstadoTerminal......................................................................................156
2.3.1 EstadoUsuario.java.........................................................................................156 2.3.2 EstadoUsuarioLis.java....................................................................................158
2.4 Paquete Localizacion ..........................................................................................164 2.4.1 LocalizacionUsuario.java ...............................................................................164 2.4.2 HiloLoc.java...................................................................................................173
2.5 Paquete InteraccionUsuario.................................................................................176 2.5.1 InteraccionUsuarioLoc.java............................................................................176
2.6 Paquete MensajeriaMultimedia...........................................................................182 2.6.1 MensajeMultimedia.java ................................................................................182 2.6.2 MensajeMultimediaLis.java ...........................................................................186
2.7 Paquete Gestion...................................................................................................193 2.7.1 GestionAlarmas.java ......................................................................................193 2.7.2 GestionAmbulancias.java...............................................................................196 2.7.3 GestionCaida.java...........................................................................................200 2.7.4 GestionPacientes.java.....................................................................................202 2.7.5 Script.java.......................................................................................................207
2.8 Paquete TipoDatos ..............................................................................................213 2.8.1 Alarma.java ....................................................................................................213 2.8.2 Ambulancia.java.............................................................................................215 2.8.3 NumerosServicio.java ....................................................................................215 2.8.4 Paciente.java...................................................................................................216
3. Anexo III: Javadoc......................................................................................... 218
Índice de figuras
Raúl Parras Eliche 10
Índice de figuras
Índice figuras Figura 1. Diagrama de Gantt...................................................................................................... 24
Figura 2. Roaming internacional entre redes ............................................................................ 33 Figura 3. Evolución de GSM hacia UMTS.................................................................................. 39
Figura 4. Arquitectura típica de OSA/Parlay.............................................................................. 50 Figura 5. GCC. Interfaces del servicio ....................................................................................... 55 Figura 6. GCC. Interfaces de la aplicación ................................................................................ 56 Figura 7. Paquete MPCC............................................................................................................ 57 Figura 8. MMCC. Clases de la aplicación.................................................................................. 58 Figura 9. MMCC. Clases del servicio ......................................................................................... 59 Figura 10. CCCS. Clases de la aplicación.................................................................................. 61 Figura 11. CCCS. Clases del servicio ......................................................................................... 62 Figura 12. Paquete Interacción de Usuario Genérica ................................................................ 63 Figura 13. Paquete Movilidad .................................................................................................... 65
Figura 14. Arquitectura típica de OSA/Parlay............................................................................ 68 Figura 15. Estructura de MiLife™ ISG SDK.............................................................................. 69 Figura 16. Estructura detallada del SDK.................................................................................... 72 Figura 17. Herramienta gráfica del simulador ISG.................................................................... 75 Figura 18. Conexión con el simulador........................................................................................ 76 Figura 19. Menú View de la herramienta gráfica ....................................................................... 77 Figura 20. Pestaña General del Menú Preferentes..................................................................... 78 Figura 21. Pestaña Panels del Menú Preferences ...................................................................... 79 Figura 22. Pestaña User Location del Menú Preferences .......................................................... 79 Figura 23. Pestaña Call Control & User Interaction del Menú Preferences.............................. 80 Figura 24. Pestaña Framework del Menú Configuration ........................................................... 81 Figura 25. Pestaña MultiMediaMessaging del Menú Configuration.......................................... 82 Figura 26. Script y User Location Panels .................................................................................. 84 Figura 27. User Status Panel ...................................................................................................... 86 Figura 28. Call Control & MMM Panel ..................................................................................... 87 Figura 29. Reproducción de mensaje de User Interaction.......................................................... 88 Figura 30. Adaptadores de OSA/Parlay convenience classes..................................................... 90
Índice de figuras
Raúl Parras Eliche 11
Figura 31. Adaptadores de Script convenience classes ...............................................................91 Figura 32. Etiqueta simulation ....................................................................................................92 Figura 33. Etiqueta suscriberSet. ................................................................................................93 Figura 34. Etiqueta step ..............................................................................................................94 Figura 35. Etiqueta programSet ..................................................................................................95 Figura 36. Etiqueta BehaviorSet .................................................................................................96
Figura 37. Tablas pacientes, cuidadores y servicios_contratados ............................................104 Figura 38. Tabla ambulancias...................................................................................................105 Figura 39. Tablas estadopacloc.................................................................................................105 Figura 40. Esquema completo del proyecto...............................................................................110 Figura 41. Clase TeleAsistencia ................................................................................................110 Figura 42. Principales relaciones de la clase TeleAsistencia ...................................................112 Figura 43. Esquema del paquete BaseDeDatos.........................................................................113 Figura 44. Clase BBDD.............................................................................................................113 Figura 45. Esquema del paquete EstadoTerminal.....................................................................114 Figura 46. Clases EstadoUsuarioLis y EstadoUsuario .............................................................115 Figura 47. Esquema del paquete Localizacion..........................................................................116 Figura 48. Clases LocalizacionUsuario e HiloLoc ...................................................................117 Figura 49. Esquema del paquete InteraccionUsuario ...............................................................120 Figura 50. Clase InteraccionUsuarioLoc ..................................................................................120 Figura 51. Esquema del paquete MensajeriaMultimedia ..........................................................121 Figura 52. Clase MensajeriaMultimediaLis ..............................................................................122 Figura 53. Clase MensajeriaMultimedia ...................................................................................123 Figura 54. Esquema del paquete Gestion ..................................................................................123 Figura 55. Clases GestionCaida, GestionAmbulancias,GestionAlarmas y Script.....................125 Figura 56. Clase GestionPacientes............................................................................................125 Figura 57. Esquema del paquete TipoDatos..............................................................................126 Figura 58. Clase Alarma ...........................................................................................................127 Figura 59. Clase Paciente .........................................................................................................127 Figura 60. Clase Ambulancia ....................................................................................................128 Figura 61. Interfaz NumerosServicio.........................................................................................128
Figura 62. Lista de Paquetes .....................................................................................................218 Figura 63. Paquete BaseDeDatos..............................................................................................219 Figura 64. Paquete TipoDatos...................................................................................................219 Figura 65. Paquete Localización...............................................................................................220 Figura 66. Paquete Gestión .......................................................................................................220 Figura 67. Paquete InteraccionUsuario ....................................................................................221 Figura 68. Paquete EstadoTerminal..........................................................................................221 Figura 69. Paquete MensajeriaMultimedia ...............................................................................222
Índice de figuras
Raúl Parras Eliche 12
Raúl Parras Eliche 13
Capítulo I
Introducción General
Raúl Parras Eliche 14
Capítulo I: Introducción general 1. Motivación y objetivos
Raúl Parras Eliche 15
1. Motivación y objetivos 1. Motivación y objetivos
l imparable avance de las tecnologías de sistemas de información y las
comunicaciones está haciendo posible cada vez más que éstas se apliquen
a campos donde hasta hace unos años era una idea simplemente impensable. Las
posibilidades que se nos presentan hoy día, por ejemplo con la evolución de los
servicios móviles, son innumerables, permitiendo el desarrollo de aplicaciones con
múltiples funcionalidades y en muy diversos ámbitos. Uno de estos ámbitos en los que
las tecnologías de la información y las comunicaciones han experimentado un
crecimiento considerable es la medicina, permitiendo el desarrollo de nuevos y más
completos servicios de telemedicina. Básicamente, la telemedicina consiste en aplicar la
medicina a distancia, empleando para ello las tecnologías anteriormente mencionadas.
Dentro de esta disciplina podremos encuadrar también a la teleasistencia, entendiendo
como tal la prestación de servicios sanitarios, de auxilio, etc. con el objetivo de mejorar
la calidad de vida de las personas a quien va dirigido, generalmente personas
vulnerables, ya sea por enfermedad, discapacidad, edad avanzada, etc. Esta conjunción,
la de aplicar tecnologías en claro crecimiento y con un futuro prometedor, junto a la de
ofrecer un servicio muy útil para un conjunto de personas muy amplio y que les puede
suponer una mejora considerable en su estilo de vida, es lo que me hizo decantarme por
la realización de este tipo de proyecto.
E
Capítulo I: Introducción general 1. Motivación y objetivos
Raúl Parras Eliche 16
El objetivo primordial, por tanto, que se persigue con este trabajo, es el intento
de aunar las tecnologías más modernas de telefonía móvil con la idea de ofrecer un
servicio de asistencia a personas cuyas capacidades físicas y/o mentales se encuentran
notablemente mermadas. Es por ello que se pensó en realizar un servicio de
teleasistencia destinado a un amplio abanico de personas, desde personas mayores en
general, hasta por ejemplo, personas enfermas de alzheimer, en las que la pérdida de
memoria y las dificultades de orientación son unos de los principales problemas.
El servicio que se propone en este proyecto difiere en su forma respecto a los
servicios tradicionales de teleasistencia. Normalmente, este tipo de ofertas se han
centrado en la atención a las personas permitiendo la permanencia en sus hogares sin la
necesidad de que estuvieran permanente vigilados, ofreciéndoles una vía de
comunicación fácil con sus cuidadores. Estos servicios normalmente son también de
compañía para estas personas, estableciendo con ellas comunicaciones periódicas para
comprobar su estado y por ejemplo, para recordarles las medicinas que deben tomar. La
implementación más normal de este tipo de sistemas consiste en un terminal conectado a
la red telefónica que a su vez establece comunicación con otro dispositivo, mucho más
pequeño, que es el que tiene que llevar consigo el paciente. Con este pequeño sistema el
paciente tiene atención inmediata en caso de emergencia, pero sólo en el ámbito de su
casa. Esto está muy bien si nuestro paciente tiene movilidad reducida, pero si no es así,
si es capaz de moverse por sí mismo fuera de su casa, es necesario algo más, pues se
hace necesario conocer la posición del mismo en todo momento.
Es en este punto donde el presente proyecto busca aportar ideas, soluciones,
modernas desde el punto de vista tecnológico y asequibles desde el punto de vista
económico. Por ambas razones, se optó por realizar un servicio de teleasistencia sobre
redes móviles de tercera generación utilizando el estándar de OSA/Parlay. Se eligió la
tecnología UMTS porque es la más moderna y porque ofrece una serie de
funcionalidades y capacidades que la red GSM no contempla, si bien es verdad, que al
emplear la interfaz OSA/Parlay estamos independizando lo que es nuestra aplicación de
la red que haya por debajo, es decir, para nosotros la red será un conjunto de ‘cajas’ y
cada una de ellas nos ofrecerá una serie de funcionalidades. Nuestra aplicación tendrá
que usar aquellas que le sean útiles para el fin perseguido, obtener de ellas la
Capítulo I: Introducción general 1. Motivación y objetivos
Raúl Parras Eliche 17
información que creamos conveniente, procesarla y tomar decisiones cuando sea
necesario.
La opción de crear una aplicación utilizando telefonía móvil se basa también en
que nos interesaba la idea de que la implementación del sistema fuera lo más sencilla
posible y además, como se ha comentado antes, no sólo abarcara la residencia de
nuestros pacientes. La forma más sencilla, a nuestro juicio, es aprovechar las redes
móviles existentes, lo que implica que los pacientes sólo necesitarían llevar con ellos su
teléfono móvil, para por ejemplo, saber en cada momento cuál es su posición, y en caso
de emergencia, contactar con ellos.
Otro aspecto que interesaba mucho era la opción de poder testear la aplicación,
por lo que, una vez decidido el tema a realizar y antes de delimitar más el alcance y
profundidad del mismo, se decidió buscar algún tipo de software o simulador que lo
permitiera. La verdad es que apenas se encontraron un par de herramientas que
permitieran probar una aplicación de este tipo, y finalmente se escogió el software
MiLife™ ISG SDK 7.1 de Lucent Technologies, por ser el más completo y el que más se
adecuaba a lo que se buscaba. Esta herramienta, como se explicará en el punto 3 de la
Introducción Teórica, nos ofrece, por un lado, el conjunto de funcionalidades antes
mencionadas, es decir, un conjunto de capacidades de servicio abstraídas de la red que
se comunican a través de una interfaz OSA/Parlay, y por otro, un entorno de desarrollo
de aplicaciones más simple junto a un simulador para poder testear dichas aplicaciones.
En conclusión, esta herramienta nos ofrecía un entorno de simulación completo para
probar la aplicación.
Una consecuencia directa de querer probar la aplicación es que es indispensable
el uso del simulador, y por lo tanto, adecuarse a las características del mismo. Eso
implica que en el código creado haya sido inevitable la mezcla de código destinado a la
aplicación en sí junto a código cuya única funcionalidad es la de interactuar con el
simulador para permitir de esa manera la simulación, y poder crear así una situación de
interactividad que muestre en la mayor medida de lo posible la funcionalidad real de la
aplicación. Esa mezcla de código provoca que la aplicación creada no sea una versión
real, pues gran parte del mismo se ha tenido que crear para recrear situaciones y
Capítulo I: Introducción general 1. Motivación y objetivos
Raúl Parras Eliche 18
actividades que en la realidad no las realizaría la aplicación, sino los pacientes o demás
elementos reales que compongan el conjunto del servicio.
Otra consecuencia de utilizar el software antes mencionado es que se presentaba
la posibilidad de programar utilizando una API en Java (las Convenience Classes)
suministrada por él mismo, en vez de usar la API de OSA/Parlay directamente. Por lo
pronto, dicha API había que utilizarla en la comunicación del programa con el
simulador. Se estudiaron las dos posibilidades, y se eligió la suministrada por MiLife™
ISG SDK, pues esta API suponía utilizar un nivel de abstracción superior y ocultaba
muchas de las dificultades en cuanto programación de la API de OSA/Parlay y en
cuanto a la complejidad de la estructura de los datos a utilizar.
Una vez definido el entorno de desarrollo a utilizar se empezó a definir de una
manera más concreta el servicio de teleasistencia. La funcionalidad principal que se
buscaba, como se ha comentado anteriormente, era la localización permanente de todos
los pacientes o abonados al servicio, independientemente del lugar donde se
encontraran. Partiendo de esa idea, se fueron añadiendo funcionalidades, intentando
utilizar la mayor cantidad de capacidades de servicio. Evidentemente, el uso del
simulador ha limitado también muchas de estas ideas iniciales, pues no soportaba
algunas de esas características. A continuación se van a enumerar una serie de puntos
que describen el funcionamiento del servicio creado:
En la configuración inicial del servicio y creación del entorno se han definido
los siguientes actores:
o Los pacientes: elementos principales de la aplicación, pues entorno a
ellos gira todo el servicio.
o Los cuidadores: cada paciente va a tener su cuidador designado. Un
mismo cuidador puede estar asignado a varios pacientes. La misión del
cuidador no es estar siempre con el paciente, si no una persona que
conoce los hábitos de sus pacientes, que los visita periódicamente y es,
digamos, la cara visible del servicio de teleasistencia de cara al paciente.
Cada cuidador va a disponer también de su terminal móvil.
Capítulo I: Introducción general 1. Motivación y objetivos
Raúl Parras Eliche 19
o La central: es el lugar donde se coordina todo el servicio. Puede ser el
lugar donde se ejecute la aplicación. Dispone de varios terminales
(números de abonado) para realizar las distintas tareas. Está el número
principal (denominado central) y que es el que usa la aplicación para
realizar las llamadas y envío de mensajes de manera automática y un
número asignado a una operadora para dar soporte de atención al
cliente. Todas las llamadas entrantes a la central que no correspondan a
situaciones de emergencia, se desvían a la operadora.
o Las ambulancias: cada una dispondrá de su terminal móvil para ser
requerida en caso de que un paciente la necesite en caso de emergencia.
El servicio principal, como ya se ha comentado, es el de localización continua
de los pacientes. La aplicación conoce cuál es la posición de referencia de cada
uno de ellos, y periódicamente comprueba cuál es su posición (en un intervalo
que puede ser configurable, dependiendo de la capacidad de proceso de que se
disponga), de tal manera que si en cualquier momento la distancia de dicho
paciente con respecto a la de referencia supera el kilómetro, se generará una
alarma.
En paralelo a la acción anterior, la aplicación es capaz de tratar las alarmas
generadas, de tal manera que cuando detecta la creación de una, se procede a su
identificación y posterior tratamiento.
Como vemos, el servicio depende totalmente de que los terminales de los
pacientes tengan un correcto funcionamiento, es decir, estén siempre encendidos
y tengan cobertura. Por ello, la aplicación es capaz de detectar cuando algún
terminal pasa a un estado no alcanzable. Cuando esto sucede con algún terminal
de los pacientes, inmediatamente se avisa mediante un mensaje multimedia al
cuidador correspondiente, para que sea éste el que se encargue de revisar el
estado del paciente y su terminal. En caso de que no pueda o haya algún tipo de
emergencia, será él el encargado de dar la alarma. De la misma manera, cuando
un terminal vuelve a un estado alcanzable, se avisa al cuidador.
Cuando se genera una alarma por una posición no adecuada del paciente, el
protocolo de actuación que se sigue es el siguiente:
Capítulo I: Introducción general 1. Motivación y objetivos
Raúl Parras Eliche 20
1. Se comprueba cuál es la posición del cuidador asociado al paciente,
pues si está muy cerca del paciente, es muy probable que se
encuentre con él. Se ha decidido que si la distancia entre ambos es
menor de 20 metros, suponemos que están juntos. Se procede
entonces a enviar un mensaje multimedia al cuidador informando de
que la posición de su paciente ha excedido el radio de seguridad y
que se considera que él se encuentra acompañándole debido a su
proximidad. Si esto no fuera así, el cuidador debe informar de ello.
Por último se anotará el estado del paciente y no se comprobará más
su posición.
2. Si la distancia entre ambos supera los 20 metros, la central se pone
en contacto con el cuidador. Como es un proceso automático, se le
reproduce un mensaje en el que se le pregunta si él está con el
paciente (o sabe si está acompañado) o si desconoce cuál es su
situación.
3. El cuidador responderá (mediante pulsación de teclas). Si el
paciente se encuentra acompañado, se anotará que el paciente no
está sólo y no se comprobará su posición más. Por el contrario, si el
paciente está sólo, se procederá a llamar a una ambulancia que esté
disponible y su posición sea la más cercana a él.
4. Cuando el cuidador deje de nuevo sólo al paciente, él, mediante un
mensaje multimedia dirigido un terminal específico de la central,
activa de nuevo la comprobación de la posición de su paciente.
Se ha contemplado también otro tipo de alarmas, por ejemplo de caídas. Se
supone que el terminal del paciente estaría conectado a algún tipo de sensor de
caídas, y que, cuando éste le avisara, pues inmediatamente mandaría un mensaje
de alarma a un número específico de la central. El tratamiento que se ha hecho
de este tipo de alarma es simplemente avisar a la ambulancia más cercana (y
disponible) para ir en su auxilio.
Por último comentar que en cuanto al tratamiento de los mensajes y de las
alarmas enviadas a través de este método, se pretendía especificar un formato concreto
Capítulo I: Introducción general 1. Motivación y objetivos
Raúl Parras Eliche 21
en el contenido de los mismos, y que fuera la aplicación la que capturase el mensaje y
analizara el contenido. Capturar el mensaje sí se ha conseguido, pero ha sido imposible
recuperar el contenido debido a que el simulador no soporta esta funcionalidad. Por este
motivo, ha sido necesario distinguir los mensajes mediante su dirección de origen y su
dirección destino, y tomando mediante esas direcciones las medidas oportunas. Es por
eso por lo que existen números específicos en la central para enviar los mensajes por
alarmas de caída y para cambiar el estado de un paciente.
Como conclusión a este punto me gustaría añadir que, normalmente, el proceso
de creación de este tipo de servicios se ciñe a las peticiones del cliente que lo haya
encargado. Evidentemente, aquí no ha existido ningún cliente, por eso los objetivos no
han constituido un conjunto de requisitos inamovible. Se ha partido de una idea, la
adaptación de un servicio útil a la sociedad a las tecnologías de telefonía móvil de nueva
generación, y según avanzaba el tiempo y se comprobaban los medios y la complejidad
de la misma, se iba modelando hasta obtener la aplicación que conforma este proyecto.
El objetivo principal era pues el de introducirnos en el mundo de la creación de
aplicaciones para redes móviles usando una interfaz estándar y abierta, independiente de
la red subyacente y del propietario de la misma, es decir, crear una aplicación basada en
OSA/Parlay, pues el utilizar esta tecnología supone un hecho diferenciador con respecto
a otros servicios del mismo estilo.
Capítulo I: Introducción general 2. Ejecución temporal
Raúl Parras Eliche 22
2. Ejecución temporal 2. Ejecución temporal
n la realización del presenta proyecto, la fase de documentación ha
ocupado un lugar importante. El desconocimiento acerca de la tecnología
OSA/Parlay era total, por lo que ha sido necesario tomarse un tiempo para recopilar
información sobre el tema. Establecer un límite de tiempo para cada etapa de
implementación del proyecto es bastante complicado, pues muchas de ellas se han
realizado en diferentes momentos, alternándose unas a otras, pero las principales, y en el
orden en que se indican, se pueden resumir en las siguientes:
Documentación acerca de los servicios móviles de tercera generación y la
tecnología OSA/Parlay.
Búsqueda de un software que permitiera probar una aplicación que usara
OSA/Parlay. El software elegido fue, como ya se ha comentado, MiLife™ ISG
SDK 7.1 de Lucent Technologies.
Familiarización con el software anterior, comprobando las posibilidades que
ofrecía y cuáles no, y refrescando el lenguaje XML para la creación del entorno
de simulación que necesitaba el software.
Desarrollo de la base de datos y de la aplicación Java que usa la API
suministrada por el software MiLife.
Redacción de la memoria del proyecto.
E
Capítulo I: Introducción general 2. Ejecución temporal
Raúl Parras Eliche 23
En la representación de la página siguiente (figura 1) se aprecia un diagrama de
Gantt en el que quedan reflejadas todas las etapas antes mencionadas junto a su duración
aproximada.
Capítulo I: Introducción general 2. Ejecución temporal
Raúl Parras Eliche 24
Figura 1. Diagrama de Gantt
Capítulo I: Introducción general 3. Material empleado
Raúl Parras Eliche 25
3. Material empleado
3. Material empleado
n este punto se va a enumerar el conjunto de programas utilizado en
la realización de este proyecto. Se ha intentado en todo momento utilizar
software gratuito, de libre distribución, y en algunos casos, software libre.
Como ya se ha comentado anteriormente, para crear un entorno de simulación
apropiado para testear la aplicación se ha empleado el software MiLife™ ISG SDK 7.1
de Lucent Technologies. No se va a describir nada más sobre este producto en este
punto porque se le dedicará otro en exclusiva más adelante. Para configurar el simulador
del software anterior y cargarlo de información para la simulación ha sido necesario
trabajar con archivos XML. Para su tratamiento se ha utilizado un simple editor de texto
muy completo, que soporta multitud de lenguajes: el Notepad++ v. 3.9.
Además de la información suministrada al simulador mediante los archivos
XML, se ha creado una base de datos que almacena toda la información que necesita el
servicio. Las características de la misma se describirán con más detalle en el punto III de
la memoria, que describe todo el trabajo realizado. Para la creación de la base de datos y
su posterior tratamiento se ha utilizado MySQL. Para ello se instaló MySQL Server 5.0
en el sistema. Además, se prefería utilizar algún tipo de herramienta gráfica para la
manipulación de la base de datos, por entenderse que es mucho más cómodo y rápido,
E
Capítulo I: Introducción general 3. Material empleado
Raúl Parras Eliche 26
así que también se instaló MySQL Tools for 5.0. Todo este software es suministrado de
forma gratuita por MySQL AB.
En cuanto a la programación del código, como al final se utilizó la API Java
suministrada por el software MiLife, se utilizó el SDK Eclipse 3.2.1, por facilitar
enormemente este proceso. Para ello se importaron una serie de librerías necesarias para
utilizar dicha API y que también suministra MiLife. Por último, para obtener las clases y
los distintos diagramas en UML se utilizó el plugin gratuito para eclipse OMONDO.
Capítulo I: Introducción general 4. Contenido de la memoria
Raúl Parras Eliche 27
4. Contenido de la memoria 4. Material empleado
oda la documentación que se presenta en este documento está dividida en
los capítulos que se enumeran y explican a continuación:
Capítulo I: Introducción general. Este capítulo servirá para exponer tanto la
motivación que ha llevado a la realización del presente proyecto como los
objetivos que se pretendían alcanzar. Se explicará además el material empleado
así como la planificación temporal.
Capítulo II: Introducción teórica. En este apartado se va a desarrollar toda la
base teórica que soporta la implementación de este proyecto. Se comenzará con
un pequeño resumen sobre los servicios móviles de tercera generación,
exponiendo las posibilidades de los mismos y las aportaciones respecto a
tecnologías anteriores. Posteriormente se explicará ampliamente en qué consiste
la tecnología OSA/Parlay y qué ventajas se obtienen de su uso. Y para finalizar
se analizará con profundidad el software MiLife ™ ISG SDK 7.1, describiendo
todas sus partes y cómo se han utilizado en el presente proyecto.
Capítulo III: Desarrollo del proyecto. En este punto se describirá todo el
trabajo realizado. En primer lugar la base de datos implementada;
posteriormente se explicará la configuración realizada en el simulador y la
T
Capítulo I: Introducción general 4. Contenido de la memoria
Raúl Parras Eliche 28
creación del entorno de simulación, y por último se expondrán todas las clases
Java creadas a partir de sus representaciones en UML, comentando sus
características principales.
Capítulo IV: Conclusiones y líneas futuras.
Capítulo V: Referencias bibliográficas.
Capítulos VI: Anexos. Se incluye en este punto todo el código realizado: el
archivo XML necesario para la simulación, todo el código Java y el Javadoc.
Capítulo I: Introducción general 4. Contenido de la memoria
Raúl Parras Eliche 29
Raúl Parras Eliche 30
Capítulo II
Introducción Teórica
Raúl Parras Eliche 31
Capítulo II: Introducción teórica 1. Los servicios 3G
Raúl Parras Eliche 32
1. Los servicios 3G 1. Los servicios 3G 1.1 Introducción
os servicios asociados con la tercera generación proporcionan la
posibilidad de transferir tanto voz y datos (una llamada telefónica) como
así como exclusivamente datos (como la descarga de programas, intercambio de correo
electrónico y mensajería instantánea).
La tercera generación de móviles, denominada 3G, evoluciona para integrar
todos los servicios ofrecidos por las distintas tecnologías y redes actuales, como GSM,
TACS, DECT, RDSI e Internet, utilizando cualquier tipo de terminal, sea un teléfono
fijo, inalámbrico o móvil, tanto en un ámbito profesional como doméstico, ofreciendo
una mayor calidad de los servicios y soportando la personalización por el usuario y los
servicios multimedia móviles en tiempo real. La velocidad de transferencia de datos que
la UIT requiere en su solución IMT-2000 va desde los 144 kbit/s en vehículos a gran
velocidad hasta los 2 Mbit/s en terminales en interiores de edificios (cifra al menos 60
veces superior a la que se tenía hasta hace poco utilizando un módem vocal y la RTC),
pasando por los 384 kbit/s para usuarios móviles en el extrarradio, o vehículos a baja
velocidad. En la siguiente figura se ilustra una de las aspiraciones de los servicios 3G: el
Roaming Internacional.
L
Capítulo II: Introducción teórica 1. Los servicios 3G
Raúl Parras Eliche 33
Figura 2. Roaming internacional entre redes
Los servicios 3G combinan el acceso móvil de alta velocidad con los servicios
basados en el protocolo IP. Pero esto no sólo conlleva una conexión rápida con la World
Wide Web, sino que implica además nuevas formas de comunicarse, de acceder a la
información, de hacer negocios, de aprender y de disfrutar del tiempo libre, dejando a un
lado las conexiones lentas, los grandes terminales y los puntos de acceso fijos. Con la
3G se pueden realizar múltiples conexiones simultáneamente desde un mismo terminal
móvil. Así, por ejemplo, un usuario podría conectarse a una base de datos remota para
obtener información sin necesidad de interrumpir una sesión de videoconferencia.
Para que los usuarios utilicen los servicios 3G hará falta nuevos teléfonos y
otros dispositivos capaces de proporcionar los servicios que se deseen, desde los de
telefonía móvil hasta los de multimedia (voz, datos y vídeo). Además, en las redes
móviles es necesario introducir nuevos sistemas de transmisión por radio, cambiar parte
de las plataformas de conmutación y de transmisión, e incorporar los nodos de servicio
que hagan posibles las prestaciones 3G.
Si el paso de los sistemas de primera generación (analógicos) a los de segunda
consistió, básicamente, en el cambio de la tecnología, el paso de la segunda a la tercera
generación significará además el cambio de modelo de negocio. En este nuevo modelo
las aplicaciones personalizadas/localizadas y multimedia serán las protagonistas, tanto
para los ciudadanos residenciales como para los empresariales, viendo los operadores
como se incrementa el tráfico en sus redes y se crean nuevas oportunidades de negocio.
Capítulo II: Introducción teórica 1. Los servicios 3G
Raúl Parras Eliche 34
Existen, además, razones evidentes que explican la necesidad de introducir la
3G. Por una parte se encuentra la capacidad de las redes móviles actuales, que sólo
permiten albergar un número determinado y limitado de usuarios, con un patrón de
consumo similar al actual, y que en cuanto se sobrepasa la congestión de la red se
manifiesta de manera insoportable para los usuarios. Por otra parte, se encuentra el
incremento de tráfico motivado por la sustitución del tráfico fijo por el móvil, en cuanto
el coste de las llamadas se reduzca y los hábitos de los usuarios se modifiquen,
necesitándose entonces más espectro. Y, por último, la aparición de nuevos servicios,
muchos de ellos personalizados, donde la convergencia con Internet y el aumento de
aplicaciones multimedia supondrán un aumento significativo de tráfico; tanto es así que
los analistas estiman que supondrá en torno a un 30% de tráfico adicional en tan sólo
dos o tres años.
Los fabricantes de infraestructura y terminales móviles están haciendo un gran
esfuerzo para disponer de los equipos de 3G, ya que ven en ella una gran oportunidad
para el desarrollo de su negocio y supervivencia a largo plazo. Así, todos los grandes,
como Alcatel, Ericsson, Lucent, Motorola, Nokia, Nortel o Siemens, enfocan su
estrategia en esta línea y se esfuerzan por desarrollar los estándares y fabricar los
equipos para que estén a tiempo, además de impulsar el desarrollo de aplicaciones
mediante la alianza con terceros.
1.2 IMT (International Mobil Telecomunications)
IMT-2000 es una norma de la ITU para los sistemas de la 3G que proporcionará
acceso inalámbrico a la infraestructura de telecomunicaciones global por medio de
sistemas satelitales y terrestres, para dar servicio a usuarios fijos y móviles en redes
públicas y privadas en siglo XXI.
1.2.1 Objetivos de IMT-2000
Los objetivos primarios de ITU para IMT-2000 son:
Capítulo II: Introducción teórica 1. Los servicios 3G
Raúl Parras Eliche 35
La eficacia operacional, particularmente para los datos y servicios
multimedia.
Flexibilidad y transparencia en la provisión de servicio global.
La tecnología adecuada para aumentar la penetración de las
telecomunicaciones, es decir, ofrecer un coste accesible para millones de
personas en el mundo que todavía no tienen teléfono.
La incorporación de toda una variedad de sistemas.
Alto grado de uniformidad de diseño a escala mundial.
Alto nivel de calidad, comparable con la de una red fija.
Utilización de un terminal de bolsillo a escala mundial.
La conexión móvil-móvil y móvil-fijo.
La prestación de servicios por más de una red en cualquier zona de
cobertura.
1.2.2 Requisitos de un sistema de tercera generación
Alta velocidad en transmisión de datos: hasta 144 Kbit/s sobre vehículos;
hasta 384 Kbit/s en peatones y hasta 2 Mbit/s en terminales estáticos.
Transmisión de datos simétrica y asimétrica.
Servicios de conmutación de paquetes y en modo circuito, tales como
tráfico Internet (IP) y video en tiempo real.
Calidad de voz comparable con la calidad ofrecida por sistemas cableados.
Mayor capacidad y mejor eficiencia del espectro con respecto a los sistemas
actuales.
Capacidad de proveer servicios simultáneos a usuarios finales y terminales.
Incorporación de sistemas de segunda generación y posibilidad de
coexistencia e interconexión con servicios móviles por satélite.
Itinerancia internacional entre diferentes operadores (Roaming
Internacional).
Los sistemas de tercera generación deberán proveer soporte, entre otras, a
aplicaciones como:
Servicios unificados de mensajes como correo electrónico multimedia.
Capítulo II: Introducción teórica 1. Los servicios 3G
Raúl Parras Eliche 36
Aplicaciones de comercio electrónico móvil, que incluye operaciones
bancarias y compras móviles.
Aplicaciones audio/video en tiempo real como videoteléfono,
videoconferencia interactiva, audio y música, aplicaciones multimedia
especializadas como telemedicina y supervisión remota de seguridad.
1.3 Los factores de éxito de 3G
El lanzamiento de un nuevo producto, servicio o tecnología se enfrenta siempre
a enormes incertidumbres. Son muchos los casos de tecnologías muy prometedoras que,
tras impulsar grandes inversiones de capital y talento, no fueron adoptadas por los
mercados en la escala que inicialmente se había previsto. Los servicios 3G han
despertado grandes expectativas y muchas compañías han apostado parte de su futuro en
el despliegue y lanzamiento de los servicios de tercera generación.
La existencia de países como Japón o Corea, u otros en entornos más próximos
donde los servicios 3G llevan ya años desplegados, permiten contar con excelentes
bancos de pruebas que permiten reducir los riesgos, desechando los modelos menos
exitosos y aprender de las estrategias que alrededor de 3G han gozado de mejor acogida
por parte de los usuarios.
En los distintos mercados analizados parece que hay un patrón común a las
empresas que han tenido éxito en el lanzamiento del servicio de banda ancha en
movilidad. En sus estrategias han primado: la cobertura, la disponibilidad de terminales
y el lanzamiento de nuevos servicios capaces de aprovechar al máximo las nuevas
oportunidades de 3G.
La cobertura
El despliegue de las redes tiene mucho que ver con el esfuerzo inversor. Por
ejemplo, Vodafone España fijó su plan de inversión en 2.880 millones de euros
en España desde abril de 2004 a marzo de 2009 (inversión que incluye tanto la
ampliación de capacidad de los servicios 2G como el despliegue de 3G). Este
Capítulo II: Introducción teórica 1. Los servicios 3G
Raúl Parras Eliche 37
esfuerzo inversor se puede, sin embargo, ver lastrado por las dificultades
normativas que imposibilitan la creación de la infraestructura.
La disponibilidad de terminales
Pocos sectores de actividad ofrecen un grado de competencia similar, que se
manifiesta en un gran esfuerzo por parte de las compañías por entender qué
combinación de elementos es la que más valora un cliente a la hora de optar por
una de las operadoras que actualmente compiten en España. En un reciente
estudio, se pone de manifiesto que las principales razones para cambiar de
operador son, por este orden: el cambio de terminal, la complejidad de las tarifas
y la calidad del servicio. La enorme relevancia que el usuario español da al
cambio del teléfono móvil lleva al conjunto de las operadoras a invertir
anualmente en el subsidio de los terminales entre 850 y 1.000 millones de euros.
La disponibilidad de terminales con las prestaciones adecuadas para sacar
partido de los nuevos servicios es uno de los grandes retos del sector a corto y
medio plazo.
Los nuevos servicios
El lanzamiento de los primeros servicios 2,5G (GPRS y EDGE) para
particulares y empresas ofreció a los clientes la posibilidad de familiarizarse con
los servicios de datos en movilidad. La introducción de la banda ancha en el
móvil permite ofrecer servicios multimedia más avanzados -especialmente de
audio y video-, abrir nuevas formas de comunicación -como la
videoconferencia- o agilizar el acceso a la información empresarial - tarjeta de
datos 3G-; pero antes del lanzamiento, cientos de miles de usuarios estaban ya
familiarizados con nuevas formas de utilizar la telefonía móvil. Esta base de
usuarios es uno de los principales activos para el lanzamiento de la tercera
generación.
La oportunidad que tenemos por delante es formidable, la nueva
comunicación móvil se puede afianzar como una de las principales plataformas
para el desarrollo de la Sociedad de la Información en España. El éxito en el
Capítulo II: Introducción teórica 1. Los servicios 3G
Raúl Parras Eliche 38
despliegue del servicio depende, naturalmente y en primer lugar, de la capacidad
de las operadoras para saber convertir la nueva tecnología en productos y
soluciones atractivos para los usuarios; este esfuerzo demanda un enorme
esfuerzo inversor. Pero, no menos importante, es la necesidad de que exista un
entorno regulador favorable, poco intervencionista y estable que estimule la
inversión. En el caso español es, además, especialmente necesario que la mesa
de concertación, impulsada desde la Administración Central, tenga éxito y sirva
para eliminar los obstáculos que impiden la instalación de nuevas estaciones
base que han de garantizar la correcta prestación del servicio. La telefonía móvil
es un activo del conjunto de la sociedad y puede ser uno de los grandes
dinamizadores de la Sociedad de la Información, de la capacidad de las
operadoras y de las Administraciones Públicas para armonizar sus intereses y
aunar esfuerzos siempre que, como país, estemos a la altura del reto planteado.
En realidad lo más sobresaliente de la telefonía móvil debería ser su
aportación a la Sociedad de la Información , extendiendo la información y el
ocio al ciudadano, acercando los sistemas de información a empresas,
aumentando así su productividad y lo que desde un punto de vista social
resultaría más importante, integrar a todas y cada una de las comunidades
existentes en la sociedad en un espacio, donde no sólo se garantice la
información a las personas y comunicación entre ellas, se fomente la
productividad entre las empresas y la relación de éstas con las Administraciones,
si no que, y esto es mucho más ambicioso, se desarrolle la convivencia y la
tolerancia entre las personas y las ideas, en un mundo que no puede permitirse la
exclusión por tanto de valor o valores no productivos en sectores marginados o
en desigualdad.
1.4 El Foro UMTS
En Europa, el Instituto Europeo de Telecomunicaciones (ETSI) propuso la
norma paneuropea de tercera generación UMTS (Universal Mobile Telecommunications
System). UMTS es miembro de la familia global IMT-2000 del sistema de
comunicaciones móviles de tercera generación de UIT. El estándar UMTS (Universal
Capítulo II: Introducción teórica 1. Los servicios 3G
Raúl Parras Eliche 39
Mobile Telephone System) está basado en la tecnología W-CDMA. UMTS está
gestionado por la organización 3GPP, también responsable de GSM, GPRS y EDGE.
En la implantación de los sistemas 3G juega un papel importantísimo el Foro
UMTS (www.umts-forum.org), un organismo independiente creado en diciembre de
1996 en el que participan casi 170 compañías de 30 países pertenecientes a las industrias
suministradoras de equipos, operadores de telecomunicaciones y organismos de
regulación. El Foro está comprometido en la formación del consenso necesario para
introducir y desarrollar con éxito el estándar UMTS y así poder satisfacer la demanda
del mercado de unas comunicaciones móviles personales de bajo coste y alta calidad. En
la siguiente figura se puede observar los pasos que se han seguido y se siguen en la
implantación de UMTS.
Figura 3. Evolución de GSM hacia UMTS
El Foro UMTS también actúa como catalizador con las organizaciones
especializadas que tratan sobre estandarización y espectro, entre otros aspectos, y
mantiene relaciones con organizaciones de carácter regional y mundial, organismos de
estandarización y otras comunidades reconocidas tanto de la industria como de
operadores.
Una aportación, básica, pero esclarecedora e imprescindible del Foro es la
propia definición de UMTS, dejando aparte sus aspectos tecnológicos, como "un sistema
de comunicaciones móviles que ofrece significativos beneficios a los usuarios,
incluyendo una alta calidad y servicios inalámbricos multimedia sobre una red
Capítulo II: Introducción teórica 1. Los servicios 3G
Raúl Parras Eliche 40
convergente con componentes fijos, celulares y por satélite. Suministrará información
directamente a los usuarios y les proporcionará acceso a nuevos y novedosos servicios y
aplicaciones. Ofrecerá comunicaciones personales multimedia al mercado de masas, con
independencia de la localización geográfica y del terminal empleado (movilidad del
terminal, personal y de servicios)".
Actualmente, del estándar 3G basado en la evolución de las redes GSM (G-
UMTS) se ocupa 3GPP (Third Generation Partnership Project), /www.3gpp.org/, creado
en diciembre de 1998 y formado por grupos de estandarización de todo el mundo. En
concreto, participan ETSI (Instituto Europeo de Estándares de Telecomunicación) en
Europa, TTC y ARIB (Asociación de las Empresas del Sector de Radio) en Japón, TTA
(Asociación de Tecnologías de Telecomunicaciones) en Corea, T1 en Estados Unidos y
CWTS en China, junto a diversos fabricantes y operadores. La finalidad del 3GPP
consiste en establecer especificaciones abiertas aceptadas en todo el mundo para
garantizar, entre otras cosas, la itinerancia mundial, mediante la cooperación entre
distintos organismos de normalización nacionales y regionales.
En Estados Unidos, de manera similar, la TIA puso en marcha 3GPP2, con el
objetivo de estandarizar la tecnología de acceso radio cdma2000, así como las interfaces
hacia las redes centrales ANSI-41.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 41
2. OSA/Parlay
2. OSA/Parlay 2.1 Introducción
Esta sección ofrece una breve explicación sobre cómo se originó y desarrolló la
Arquitectura de Servicios Abiertos (OSA). Al mismo tiempo introduce conceptos para
ayudar a entender dicha arquitectura de servicios, como son el de Red Inteligente y
CAMEL.
El concepto de arquitectura de Red Inteligente (IN) nació al final de los 80’s
como una extensión del Sistema de Señalización 7 (SS7). Esta arquitectura básicamente
fue desarrollada para la red telefónica conmutada fija. La principal idea de la red
inteligente es la de separar los servicios de control y las funciones de conmutación, con
el objetivo de crear una arquitectura de servicios fácil de gestionar y mas eficiente en el
momento de crear servicios para los usuarios.
La arquitectura de Red Inteligente es actualmente un estándar de la Unión de
Telecomunicaciones Internacional - Sección Telecomunicaciones (ITU-T), el cual
define elementos y relaciones que ofrecen como resultado servicios de valor añadido
(AVS) en beneficio de los usuarios.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 42
Por otro lado, la estandarización del Sistema Global de Comunicaciones
Móviles, por sus siglas en ingles GSM (Global System for Mobile Communications),
tuvo su inicio tiempo antes que la estandarización del modelo de Red Inteligente. Sin
embargo, GSM fue desarrollado basándose en la red de digital de servicios integrados,
por sus siglas en ingles “ISDN - Integrated Services Digital Network”, pero tan pronto
fue generado el estándar de Red Inteligente, se buscó relacionarlo con las redes móviles.
Para solucionar este problema, el Instituto Europeo de Estándares de
Telecomunicación (ETSI European Telecommunications Standards Institute) definió
Aplicaciones Adaptables para el enriquecimiento Lógico de Redes Móviles (CAMEL -
Customized Applications for Mobile Network Enhanced Logic), las cuales describen
una arquitectura similar a la de Red Inteligente pero aplicable a redes móviles.
CAMEL fue el primer intento para adaptar el concepto de Red Inteligente a
Redes Móviles. Tiene la capacidad de proveer servicios de conmutación de voz debido a
que está basado en la arquitectura de la Red Inteligente. Sin embargo, la aparición del
Sistema Universal de Telecomunicaciones Móviles (UMTS – Universal Mobile
Telecommunication System) ha hecho que CAMEL no sea óptimo para ser
implementado. Por otro lado GSM es una red conmutada de voz genérica, entonces
conceptualicemos a UMTS como una red total de integración de voz y datos, basada
completamente en transporte y encaminamiento de datos. UMTS es la unión entre
Internet, Redes Telefónicas, Redes Móviles y la Red de Transmisión de TV y radio. El
modelo de servicio que ofrece CAMEL es muy restrictivo para este ambiente de
servicios integrados.
Siguiendo estos principios, las líneas de trabajo se centraron en la integración de
los conceptos de Red Inteligente y CAMEL, surgiendo así la Arquitectura de Servicios
Abiertos (o también llamado Acceso a Sistemas Abiertos – Open Service Access), la
cual permite el aprovisionamiento de servicios a través de tecnologías y sistemas de
gestión diferentes. Esta herramienta abre la posibilidad de establecer modelos
independientes de negocios por los gestores de las redes de telecomunicaciones de
tercera generación. OSA es la arquitectura para servicios móviles desarrollada por el
3GPP (3rd Generation Partnership Program) que también fue adoptada por el 3GPP2.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 43
Actualmente Internet ha creado oportunidades para implementar nuevas
comunicaciones y servicios, pero el modelo de Internet es totalmente opuesto a CAMEL
y al concepto de Red Inteligente. Mientras que en la red inteligente los servicios son
ofrecidos y gestionados por un operador de red, Internet abre la posibilidad para que
cualquier entidad con infraestructura básica pueda ofrecer sus servicios. Parlay nace
como la solución al problema de coexistencia entre estos modelos.
Parlay es la definición de una interfaz estándar y abierta para permitir el acceso
a los recursos de la red a operadores y aplicaciones que no tengan que estar en el
dominio del operador; es la especificación de la API de OSA.
En la actualidad, se utilizan los términos OSA, Parlay y OSA/Parlay
indistintamente. OSA/Parlay es una API (Application Programming Interface) que
permite la creación de servicios de telecomunicaciones de manera rápida. Está definida
por el grupo Parlay, que es un consorcio de empresas del mundo de las
telecomunicaciones y la informática con fines no lucrativos. Actualmente está
compuesto por más de 65 compañías (Alcatel, HP, IBM, Lucent, Siemens, Sun, British
Telecom, NTT, etc.) El grupo Parlay fue fundado en 1998 y desde entonces se han
creado cuatro versiones de las especificaciones Parlay. La mayoría del trabajo técnico se
realiza en grupos de trabajo que incluyen miembros de Parlay, 3GPP y ETSI.
La API de OSA/Parlay es independiente de la tecnología. Está diseñada para ser
usada en redes móviles, fijas y redes de nueva generación basadas en protocolo IP.
También es independiente del lenguaje de programación utilizado (Java, C, C++, etc.).
OSA/Parlay está basado en estándares abiertos tales como CORBA, IDL, Java,
UML y Servicios Web (SOAP, XML y WSDL).
El objetivo del grupo Parlay cuando se fundó fue potenciar la convergencia de
los mundos de las comunicaciones y la informática. Una manera de lograr esto es usar la
tecnología que se utiliza para la creación de aplicaciones informáticas para desarrollar
servicios de comunicaciones.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 44
En los siguientes apartados se verá cuales son los beneficios de OSA, dónde
encaja en la red, se describirá qué funcionalidades ofrece, los mecanismos principales y
se hará un recorrido por la especificación.
2.2 Beneficios de OSA/Parlay
Los principales beneficios que se consiguen utilizando OSA/Parlay son los
siguientes:
Rapidez en la creación de servicios.
Independencia de la red.
Independencia del fabricante.
Existencia de un gran número de desarrolladores de aplicaciones.
Vendedores de aplicaciones y servicios basados en OSA/Parlay independientes.
2.2.1 Rapidez en la creación de servicios
OSA/Parlay está basada en las mismas soluciones que los desarrolladores de
software comercial usan cuando construyen aplicaciones, al contrario que los entornos
de desarrollo propietarios para la creación de servicios que se estaban usando. Una
ventaja de esto es que es muy fácil desarrollar aplicaciones OSA/Parlay usando
herramientas de desarrollo normales para aplicaciones Java tales como el J-Builder de
Borland o el Websphere Studio de IBM, incluso con entornos gratuitos. Muchos
vendedores como Ericsson y Lucent Technologies también proporcionan herramientas
de simulación, pudiendo simular las aplicaciones desde ordenadores personales.
Ericsson, IBM y Telenor han realizado experimentos que demuestran que
usando OSA/Parlay se reducen significativamente los tiempos de desarrollo de servicios
de comunicación.
2.2.2 Independencia de la red
La API de OSA/Parlay fue diseñada, en la medida de lo posible, para que fuera
independiente de la red que hubiera debajo. Una aplicación móvil no necesita saber qué
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 45
tecnología se está usando para implementar los servicios de localización. El
desarrollador de la aplicación tan solo necesita saber las coordenadas de la localización
y la precisión. Esto permite a una aplicación funcionar igual de bien en diferentes redes,
y la misma aplicación se puede instalar incluso en redes fijas. De nuevo, la aplicación no
se preocupa de cómo se determina la información de localización, sólo de los datos de
localización. Las mismas consideraciones se pueden aplicar a otras áreas funcionales,
tales como establecer una llamada, cargar al usuario una cierta cantidad por el uso del
servicio, etc.
2.2.3 Independencia del fabricante
Una consecuencia de la independencia de la tecnología (y la red) de OSA/Parlay
es que también son independientes del fabricante. Los proveedores de servicios se
benefician al tener un conjunto único de interfaces que son soportadas por muchos
fabricantes de plataformas. Esto añade aún más flexibilidad en el desarrollo.
2.2.4 Existencia de un gran número de desarrolladores de aplicaciones
El uso de tecnología estándar software significa que los desarrolladores de
software con experiencia en C++ y CORBA o Java pueden desarrollar aplicaciones
usando OSA/Parlay fácilmente. Se estima que hay entorno a 1,5 millones de
desarrolladores de C y Java en el mundo en contraste con los desarrolladores de
servicios en RI que necesitan un entrenamiento muy especializado y no hay más que
unos pocos miles en el mundo.
2.2.5 Vendedores de aplicaciones y servicios basados en OSA/Parlay
independientes
Un resultado del uso de tecnología de desarrollo de software estándar es que se
está creando una comunidad creciente de vendedores de software independientes que
están desarrollando y vendiendo aplicaciones y servicios basados en OSA/Parlay. El
grupo Parlay realiza cada cierto tiempo demostraciones donde los vendedores pueden
demostrar las nuevas aplicaciones y servicios basados en OSA/Parlay.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 46
2.3 Arquitectura de OSA
Los servicios de 3G no se basan en servicios tradicionales detallados como los
servicios suplementarios de los sistemas 2G, sino que proporcionan servicios usando
herramientas de desarrollo genéricas, como OSA.
En OSA los servicios se implementan con aplicaciones que usan los recursos de
la red accesibles a través de las interfaces de OSA.
OSA puede dividirse en tres partes:
Aplicaciones: implementadas en servidores de aplicación. Ejemplos de
aplicaciones son tarificación por contenidos, conferencia, aplicaciones basadas
en localización, etc.
Armazón (Framework): proporciona los mecanismos básicos para que las
aplicaciones puedan usar los recursos de la red. Ejemplos de estos mecanismos
son la autentificación y el descubrimiento de funcionalidades.
Servidores de Capacidades de Servicio (SCS): contienen los conjuntos de
capacidades de servicio denominados Funcionalidades de Capacidades de
Servicio (SCF – Service Capability Features), que son abstracciones de las
funcionalidades de la red real.
Los SCF’s de OSA se definen a partir de sus interfaces y métodos. Las
interfaces se dividen en dos grupos:
Interfaces de Armazón.
Interfaces de Red.
2.4 Mecanismos básicos de OSA
Se pueden clasificar según las entidades involucradas:
Entre Aplicación y Armazón
Entre Armazón y SCS
Entre Servidor de aplicaciones y SCS
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 47
Algunos sólo se realizan una vez y otros cada vez que un usuario se subscribe a
la aplicación.
2.4.1 Mecanismos Básicos entre Aplicaciones y Armazón
Autentificación
Una aplicación puede acceder a la función de autentificación si previamente
existe un acuerdo de servicio. La aplicación debe autentificar al Armazón y
viceversa. Esto debe realizarse siempre antes de poder usar otras funciones de
OSA.
Autorización
Consiste en determinar qué acciones puede realizar una aplicación previamente
autentificada. Una aplicación podrá acceder a un determinado número de SCF’s.
Descubrimiento de las funciones del Armazón y de los SCF’s
disponibles
Después de realizar la autentificación correctamente, las aplicaciones pueden
obtener qué funciones están disponibles en el Armazón y usar la función de
Descubrimiento para obtener información de para qué SCF’s tiene autorización.
La función de Descubrimiento puede ser utilizada en cualquier momento
después de la autentificación.
Establecimiento de acuerdos de servicio
Antes de que una aplicación pueda interactuar con un SCF de red, hay que
establecer un acuerdo de servicio. Éste constará de una parte “offline”
(intercambio de documentos físicos por ejemplo) y una parte “online”
(documentos electrónicos). La aplicación debe firmar los documentos
electrónicos del acuerdo de servicio para poder acceder a los SCF’s.
Acceso a los SCF’s de red
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 48
El Armazón proporciona funciones para controlar el acceso a SCF’s o datos de
servicio para cualquier método de la API desde cualquier aplicación, con niveles
de seguridad adecuados.
2.4.2 Mecanismos Básicos entre Armazón y SCS
Registro de SCF’s de Red
Los SCF’s que ofrece un SCS pueden ser registrados en el Armazón. Así, éste
podrá informar a las aplicaciones cuando soliciten un listado de los SCF’s
disponibles. Este mecanismo se usa cuando se instala o actualiza un SCS.
2.4.3 Mecanismos Básicos entre Servidor de Aplicaciones y SCS
Petición de notificación de eventos
Los SCF’s que ofrece un SCS pueden ser registrados en el Armazón. Así, éste
podrá informar a las aplicaciones cuando soliciten un listado de los SCF’s
disponibles. Este mecanismo se usa cuando se instala o actualiza un SCS.
2.5 Seguridad relacionada con el usuario final
Después de que una aplicación haya sido autentificada y autorizada para usar
SCF’s, los aspectos de seguridad relacionados con el usuario final suponen un problema
importante. Existen tres aspectos a tener en cuenta que se enumeran a continuación.
2.5.1 Autorización a los usuarios finales para usar aplicaciones
Un usuario final estará autorizado a usar una aplicación sólo cuando se suscriba
a ella. La suscripción es parte del Acuerdo de Nivel de Servicio (SLA – Service Level
Agreement) que se firma entre el HE (Home Environment) y el HE-VASP (Home
Environment – Value Add Service Provider) si el usuario final se ha suscrito a la
aplicación antes de que la aplicación acceda a las SCF’s.
El HE controla las suscripciones y puede usar políticas para definir y restringir
la lista de servicios ofrecidos al usuario final. El HE tiene que compartir la información
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 49
de suscripción y activación de servicios con el HE-VASP para que éste conozca qué
usuarios pueden usar sus servicios.
2.5.2 Autorización a las aplicaciones de los usuarios finales
El HE podrá proporcionar capacidades de servicio a una aplicación si las
siguientes condiciones se cumplen:
El usuario final se ha suscrito a la aplicación.
El usuario final ha activado la aplicación.
El uso de esa capacidad de servicio de red no viola la privacidad del usuario
final.
Cada vez que una aplicación intenta usar un SCF para un determinado usuario
final, el SCS se asegura de que las anteriores condiciones se cumplen.
2.5.3 Opciones de privacidad del usuario final
El HE puede ofrecer al usuario final un conjunto de opciones de privacidad. Por
ejemplo, puede permitir decidir si la posición del usuario puede darse a terceras partes, o
si el usuario acepta recibir información no solicitada expresamente a su terminal. El SCS
asegura que la aplicación no viola estas preferencias.
2.6 OSA/Parlay en la Red de Telecomunicaciones
El modelo de OSA/Parlay añade un nuevo elemento en la red, la pasarela o
plataforma OSA/Parlay, usada para enlazar las aplicaciones que usan la API de
OSA/Parlay con los elementos de red existente. Estará bajo el control del operador de
red o del proveedor de servicio y es un punto por el que pasarán todas las interacciones
OSA/Parlay. Es aquí donde residirá el Armazón. Gracias a esto las aplicaciones son
independientes de los protocolos específicos usados en la red, permitiendo que las redes
evolucionen y cambien sin afectar a los servicios y aplicaciones. En la figura siguiente
se puede observar la arquitectura típica de OSA/Parlay.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 50
Figura 4. Arquitectura típica de OSA/Parlay 2.7 Especificación de OSA/Parlay
Se lista a continuación el contenido de la especificación de OSA/Parlay (versión
4.1), que contiene la definición de todas las SCF’s disponibles en el SCS. Las
especificaciones han sido definidas conjuntamente entre ETSI, el grupo Parlay y 3GPP
en colaboración con un conjunto de compañías miembros de la comunidad JAIN.
El documento completo denominado “Open Service Access (OSA); Application
Programming Interface (API)” consta de las siguientes partes:
Parte 1: Introducción (Overview)
Parte 2: Definiciones de Datos Comunes (Common Data Definitions)
Parte 3: Armazón (Framework)
Parte 4: SCF Control de Llamada (Call Control)
o Subparte 1: Definiciones Comunes del Control de Llamada (Call
Control Common Definitions)
o Subparte 2: SCF Control de Llamada Genérico (Generic Call Control
SCF)
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 51
o Subparte 3: SCF Control de Llamada Multi-Partícipe (Multi-Party Call
Control SCF)
o Subparte 4: SCF Control de Llamada Multimedia (Multi-Media Call
Control SCF)
o Subparte 5: SCF Control de Llamada de Conferencia (Conference Call
Control SCF)
Parte 5: SCF Interacción de Usuario (User Interaction SCF)
Parte 6: SCF Movilidad (Mobility SCF)
Parte 7: SCF Capacidades de Terminal (Terminal Capabilities SCF)
Parte 8: SCF Control de Sesión de Datos (Data Session Control SCF)
Parte 9: SCF Mensajería Genérica (Generic Messaging SCF)
Parte 10: SCF Gestor de Conectividad (Connectivity Manager SCF)
Parte 11: SCF Gestión de Cuentas (Account Management SCF)
Parte 12: SCF Tarificación (Charging SCF)
Parte 13: SCF Administración de Políticas (Policy Management SCF)
Parte 14: SCF Gestión de Presencia y Disponibilidad (Presence and
Availability Management SCF)
Las especificaciones de OSA definen una arquitectura que permite a los
desarrolladores de servicios hacer uso de las funcionalidades de la red a través de una
interfaz estándar abierta. Las funcionalidades de red se describen como Funcionalidades
de Capacidades de servicio (SCF – Service Capability Features) o simplemente
Servicios (ambos términos se utilizan indistintamente en la especificación). El Armazón
de OSA es el componente que conecta los Servicios con las Aplicaciones.
El propósito de la API de OSA es encapsular la complejidad de la red, sus
protocolos y su implementación específica de las aplicaciones. Las aplicaciones no
tienen que conocer qué nodos de la red interactúan con un SCS para proporcionar una
SCF a la aplicación. La red específica subyacente y sus protocolos son transparentes a la
aplicación.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 52
La primera parte de la especificación contiene una introducción, la segunda
parte contiene las definiciones de los tipos de datos comunes y la tercera parte las
interfaces del Armazón. Las siguientes partes contienen las descripciones de los SCF’s.
Cada una de las partes está estructurada de la siguiente manera:
Diagramas de secuencia
Relaciones de clases
Especificación de la interfaz
Diagramas de transición de estados (STD – State Transition Diagrams)
Definición de tipos de datos
La API de OSA está definida usando UML que es independiente de la
tecnología. OSA se puede realizar de múltiples maneras y además de la definición en
UML, la especificación incluye:
Un anexo normativo con la API de OSA en IDL que especifica la realización en
CORBA.
Un anexo informativo con la API de OSA en WSDL que especifica la
realización en SOAP/HTTP.
Un anexo informativo con la API de OSA en Java (conocida como “JAIN
Service Provider API).
A continuación se van a detallar a modo de ejemplo las partes 4, 5 y 6 de la
especificación, es decir, la de control de Llamada (Call Control SCF), Interacción de
Usuario (User Interaction SCF) y Movilidad (Mobility SCF), por ser tres de las SCF’s
más usadas en la aplicación desarrollada en este proyecto.
2.7.1 SCF Control de Llamada
En la norma ES 202 915, Parlay 4, se especifican 4 partes de la API Control de
Llamada (CC – Call Control):
SCF Control de Llamada Genérico (GCC - Generic Call Control SCF)
SCF Control de Llamada Multi-Partícipe (MPCC - Multi-Party Call Control
SCF)
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 53
SCF Control de Llamada Multimedia (MMCC - Multi-Media Call Control
SCF)
SCF Control de Llamada de Conferencia (CCC - Conference Call Control
SCF)
Tres de éstas se han incluido en la versión 5 del 3GPP: Control de Llamada
Genérico, Control de Llamada Multi-Partícipe y Control de Llamada Multimedia. GCC
es la misma API que estaba presente en la previa especificación para 3GPP Versión 99
(TS 129 198 V3). MPCC se introdujo en la versión 4 y MMCC en la versión 5. Las 4
estaban ya incluidas en ETSI 201 195, Parlay 3.
El trabajo conjunto entre los grupos 3GPP CN5, ETSI SPAN y el grupo de
trabajo de control de llamada de Parlay con la colaboración de JAIN se han centrado en
MPCC y MMCC. Se han mejorado mucho las funcionalidades y para ello ha sido
necesario eliminar la herencia que había entre GCC y MPCC. Se ha dejado de trabajar
en GCC y la futura base del control de llamada es ahora MPCC.
El modelo de llamada usado en esta SCF tiene los siguientes objetos:
Un objeto llamada. Una llamada es la relación entre varios participantes. Está
relacionado con la visión de la llamada como un todo que tiene la aplicación.
Un objeto extremo de llamada (call leg). Representa la asociación lógica entre
una llamada y una dirección. La relación incluye al menos la relación de
señalización con el participante. La relación con la dirección se hace cuando el
extremo es encaminado. Antes el objeto estará “inactivo” y no asociado aún con
la dirección.
Una dirección. Representa de forma lógica a un participante en la llamada.
Un terminal. Es el punto final de la señalización y/o datos para un participante.
Este objeto no se considera en la especificación.
El objeto llamada se usa para establecer una relación entre varios participantes
creando un extremo de llamada para cada participante. Junto con la relación de
señalización que representa un extremo de llamada puede haber una conexión portadora
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 54
(en redes tradicionales de sólo voz) o un determinado número (cero o más) de canales de
medios (en redes multimedia).
Un extremo de llamada puede vincularse a una llamada o desvincularse. Cuando
un extremo está vinculado, quiere decir que los canales de información (portadores o
multimedia) del extremo están conectados a los canales de información de los otros
extremos vinculados a la misma llamada. Normalmente existe un número limitado de
extremos que pueden estar siendo encaminados o conectados a la llamada.
Algunas redes distinguen entre extremos de llamada pasivos y controladores.
Por definición la llamada será liberada cuando el extremo controlador sea liberado. El
resto de extremos se denominan pasivos. Actualmente, no existe manera de especificar
que extremo es el controlador.
Existen dos formas en las que la aplicación obtiene el control de una llamada.
La aplicación puede solicitar ser notificada de las llamadas que cumplen unos
determinados criterios. Cuando una llamada que cumpla esos criterios se produzca, se
informa a la aplicación que puede pasar a controlar la llamada. Otra forma es crear una
nueva llamada desde la propia aplicación.
A continuación se describirán cada una de las subpartes de esta API.
2.7.1.1 SCF Control de Llamada Genérico
El Servicio de Control de Llamada Genérico (GCCS) proporciona el servicio de
control de llamada básico a la API. Está basado en un modelo de tres participantes, que
permite que las llamadas puedan ser creadas por la red y encaminadas a través de la red.
El GCCS soporta las suficientes funcionalidades para permitir el
encaminamiento de llamadas y la gestión de llamadas para los servicios de Red
Inteligente actuales en el caso de redes telefónicas conmutadas, o su equivalente en
redes basadas en paquetes.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 55
La intención del GCCS es estar preparada para especificaciones de control de
llamada tales como las recomendaciones de la ITU-T H.323, Q.763 ISUP, Q.931 y
Q.2931, la especificación UNI3.1 del ATM Forum y la recomendación del IETF RFC
3261 SIP (Session Initiation Protocol) o cualquier otra tecnología de control de llamada.
Aquí las llamadas están limitadas a llamadas de dos participantes. No se puede
acceder explícitamente a los extremos de la llamada ni a los medios. De esto se encargan
MPCC y MMCC.
El GCCS está representado por las clases “IpCallControlManager” e “IpCall”.
Algunos métodos son asíncronos y no bloquean mientras se realizan las tareas. Por
tanto, el cliente puede manejar muchas más llamadas que si se usaran llamadas
síncronas. Para manejar las respuestas y los informes, los desarrolladores deben
implementar dos clases “IpAppCallControlManager” e “IpAppCall”. En las siguientes
figuras se muestra el diagrama de clases.
Figura 5. GCC. Interfaces del servicio
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 56
Figura 6. GCC. Interfaces de la aplicación
2.7.1.2 SCF Control de Llamada Multi-Partícipe
Este servicio mejora la funcionalidad del GCCS con la gestión de extremos de
llamada. Permite también el establecimiento de llamadas multi-partícipe, conectando
muchos extremos simultáneamente a una misma llamada.
El servicio MPCC está formado por las clases “IpCallLeg”, “IpMultiPartyCall”
e “IpMultiPartyCallControlManager” que sirven de interfaz a los servicios de la red.
Algunos métodos son asíncronos igual que ocurría en GCCS para permitir controlar más
llamadas simultáneamente. El desarrollador tiene que implementar las clases de callback
para manejar las respuestas e informes. En la siguiente figura se muestra un diagrama de
clases.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 57
Figura 7. Paquete MPCC
2.7.1.3 SCF Control de Llamada Multimedia
El servicio de Control de Llamada Multimedia amplía la funcionalidad del
servicio MPCC con capacidades multimedia. Para manipular los aspectos multimedia de
una llamada se introduce el concepto de flujo de medios. Un flujo de medios es un flujo
bidireccional de medios asociado con un extremo de la llamada. Normalmente estos
flujos de medios son negociados por los terminales de la llamada. La aplicación puede
controlar estos flujos de las siguientes maneras:
Activándose cuando se establece un flujo de medios que cumple unas
características concretas definidas por la aplicación.
Monitorizando el establecimiento (adicción) o liberación (substracción) de
flujos de medios en una llamada saliente.
Permitiendo o denegando el establecimiento de flujos de medios.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 58
Eliminando explícitamente flujos de medios ya establecidos.
Solicitando el flujo de medios asociado a un determinado extremo de la
llamada.
Al igual que en los dos últimos SCF’s aquí existen operaciones asíncronas por el
mismo motivo que antes. En las siguientes figuras se muestran las clases que componen
este SCF.
Figura 8. MMCC. Clases de la aplicación
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 59
Figura 9. MMCC. Clases del servicio
2.7.1.4 SCF Control de Llamada de Conferencia
El servicio Control de Llamada de Conferencia mejora el servicio
MMCC. Da a la aplicación la posibilidad de manipular subconferencias dentro de una
conferencia. Una subconferencia es un grupo de extremos de llamada dentro de una
conferencia. Sólo los participantes de la misma subconferencia tienen una conexión de
portadora (o una conexión de canales de medios) con los otros. Las aplicaciones pueden:
Crear nuevas subconferencias dentro de una conferencia, bien como una
subconferencia vacía o dividiendo una subconferencia existente en dos.
Mover extremos de llamada entre subconferencias.
Unir subconferencias en una.
Obtener un listado de todas las subconferencias de la llamada.
La conferencia genérica también posibilita manipular detalles de una
conferencia multimedia típica como:
Interfuncionamiento con protocolos de conferencia (por ejemplo H.323).
Manipulación de los medios en el MCU (difusión de video por ejemplo).
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 60
Manejo de políticas de conferencia multimedia (cómo debe manipularse el
video, cómo se controla la voz, etc.)
Pero además, este servicio añade el soporte para la reserva de recursos
necesarios para realizar la conferencia. La aplicación puede:
Reservar recursos durante un periodo de tiempo predefinido.
Liberar recursos reservados.
Buscar la disponibilidad de recursos de conferencia basándose en unos
determinados criterios.
Existen dos formas de iniciar una conferencia:
La conferencia puede iniciarse en un tiempo preestablecido por el servicio, en el
tiempo de comienzo indicado en la reserva. La aplicación es notificada de esto.
Entonces, puede añadir participantes a la conferencia o los participantes pueden
agregarse a la conferencia marcando una dirección (número de teléfono)
suministrado durante la reserva.
La conferencia puede ser creada directamente a petición de la aplicación.
La interfaz de Control de Llamada de Conferencia hereda de la interfaz de
Control de Llamada Multimedia y ésta a su vez de la interfaz de Control de Llamada
Multi-Participe. Es posible implementar el control de llamada de conferencia sin
ninguna funcionalidad multimedia usando sólo los métodos heredados de MPCC
además de los métodos propios.
El servicio consta de 2 paquetes, uno para las clases del lado de la aplicación y
otro para las del lado del servicio. En las siguientes figuras se muestran los diagramas de
clases.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 61
Figura 10. CCCS. Clases de la aplicación
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 62
Figura 11. CCCS. Clases del servicio
2.7.2 SCF Interacción de Usuario
El servicio Interacción de Usuario (UI – User Interaction) permite a las
aplicaciones interactuar con los usuarios finales. Consta de tres interfaces:
Gestor de Interacción de usuario: Contiene funciones de gestión de asuntos
relacionados con la interacción con el usuario.
Interacción de Usuario Genérica (GUI – Generic User Interaction). Contiene
métodos para interactuar con el usuario final.
Interacción de Usuario de Llamada (CUI – Call User Interaction). Tiene
métodos para interactuar con el usuario final cuando éste está realizando una
llamada.
GUI proporciona funciones para enviar información al usuario final o para
obtenerla de él. Así permite a las aplicaciones enviar mensajes SMS y USSD por
ejemplo. Una aplicación puede usar esta interfaz independientemente de otras SCF’s.
CUI es equivalente a GUI pero mientras el usuario está vinculado a una llamada, es
decir, es participante de una llamada. De hecho, CUI hereda de GUI. En la siguiente
figura se muestra el diagrama de clases.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 63
Figura 12. Paquete Interacción de Usuario Genérica
2.7.3 SCF Movilidad
El servicio de Movilidad (Mobility SCF) es un conjunto de servicios
usados habitualmente para implementar aplicaciones relacionadas estrechamente con la
movilidad del usuario. Consta de 4 interfaces o servicios:
Localización de Usuario (UL – User Location). Proporciona un servicio de
localización geográfica general. Con este servicio las aplicaciones pueden
obtener la localización geográfica y el estado de usuarios de telefonía fija, móvil
o basada en IP.
Localización de Usuario Camel (ULC - User Location Camel). Proporciona
información de localización basada en la información de la red, en vez de con
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 64
coordenadas geográficas usadas en UL. Con las funciones de ULC, una
aplicación puede solicitar el número del VLR, la localización de un
Identificador de Área y de un Identificador Global de Celda y otros datos de
localización.
Localización de Usuario de Emergencia (ULE – User Location Emergency). En
el caso de llamadas de emergencia, la red puede localizar al llamante
automáticamente. La localización obtenida se envía directamente a la aplicación
encargada de manejar la localización de usuario en casos de emergencia.
Estado del usuario (US – User Status). Proporciona un servicio de estado del
usuario general, permitiendo conocer cuál es el estado de usuario de telefonía
fija, móvil o basada en IP.
En UL y ULC la aplicación puede obtener información de localización de un
usuario de las siguientes maneras:
Cuando se produzca un evento que cumpla determinados criterios, por ejemplo
cuando se produzca una variación en la situación del usuario.
De manera periódica, indicando un intervalo deseado.
Por petición explícita de la aplicación.
En ULE y US no se puede obtener información de manera periódica, pero sí
explícitamente y cuando ocurra un evento. Este evento en ULE es la creación de una
llamada de emergencia y en US podría ser el cambio de estado del usuario.
Muchas de las funciones son asíncronas para que la aplicación pueda manejar
más información simultáneamente. Las aplicaciones deben realizar las correspondientes
interfaces para obtener los resultados e informes.
En la siguiente figura se muestran los diagramas de clases.
Capítulo II: Introducción teórica 2. Osa/Parlay
Raúl Parras Eliche 65
Figura 13. Paquete Movilidad
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 66
3. MiLife™ ISG SDK
3. MiLife™ ISG SDK 3.1 Introducción
n la realización del presente proyecto se ha utilizado la herramienta
software MiLife™ ISG SDK 7.1 de Lucent Technologies. Dicha
herramienta se ofrecía de forma gratuita (sólo había que registrarse primero) en la Web
de Lucent: http://www.lucent.com/developer/milife.
Esto no quiere decir que se pueda emplear este software con fines lucrativos: es
una herramienta de aprendizaje y simulación de conceptos cuya puesta en práctica en la
vida real es bastante costosa por todos los recursos que necesita.
Hay que señalar que, desde un par de meses después de la adquisición por mi
parte de dicho software, la Web de Lucent cambió, pasando a ser hasta ahora
http://www.alcatel-lucent.com, en la que este software ha dejado de estar disponible.
La aplicación se estructura en dos partes bien diferenciadas: MiLife™ ISG y
MiLife™ ISG SDK. A continuación se hará una pequeña introducción a las mismas.
E
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 67
3.1.1 MiLife™ ISG
MiLife™ ISG (Intelligent Services Gateway) provee un camino estándar para
que los operadores faciliten sus recursos de red a los proveedores de servicios de
aplicaciones (ASPs –Applications Service Providers) y a los desarrolladores de
aplicaciones cliente 3G. ISG esconde los detalles subyacentes de la red y protege a los
desarrolladores de aplicaciones de las complejidades de las redes de
telecomunicaciones.
ISG posee las siguientes características:
Un conjunto de métodos OSA (Open Service Architecture) [en forma de APIs],
que ofrecen un acceso seguro a los recursos internos de la red.
Las APIs están definidas mediante los estándares de OSA/Parlay y también en
IDL (CORBA). Las aplicaciones cliente creadas por los desarrolladores serán
capaces de enviar peticiones a la ISG a través de estas APIs.
Un juego de Servidores de Capacidades de Servicio (SCS – Service Capability
Servers) que son los que proveen la interfaz y funcionalidad para interactuar con
los elementos de la red. Estos SCSs no son más que abstracciones de las
funcionalidades de la red, permitiendo de esta manera separar los detalles
técnicos de la red de la implementación de los servicios.
ISG está basado y soporta los siguientes estándares:
3GPP OSA Release 6 (ver 3GPP TS 29.198 y http://www.3gpp.org para más
información)
Parlay 4.1 (ver punto anterior y/o http://www.parlay.org para más información)
PAM Specification Document – Version 1.0 (ver http://www.pamforum.org
para más información)
CORBA 2.3 (ver http://www.corba.org para más información).
Para entender de una manera adecuada lo que nos ofrece MiLife™ ISG es
aconsejable recordar algo que ya se comentó en el punto anterior: la arquitectura típica
de OSA/Parlay. Para ello, se vuelve a mostrar a continuación la figura relacionada con
dicha arquitectura:
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 68
Figura 14. Arquitectura típica de OSA/Parlay
El bloque central que se puede apreciar en la figura correspondería a la pasarela
o gateway necesaria en este tipo de sistemas, y a través de la cual se canalizan todas las
interacciones OSA/Parlay hacia la red y viceversa. Pues bien, MiLife™ ISG hace las
funciones de esa pasarela o plataforma OSA/Parlay. Como se aprecia en la figura, es en
este lugar donde reside el Framework o Armazón, y será este dispositivo el que se
preocupe de cómo y donde obtener la información de la red que se solicite desde
nuestras aplicaciones. Como se verá más adelante, una de las cosas más útiles de utilizar
este software, es que nos ofrece una API más sencilla de manejar que la de OSA/Parlay.
Podemos ver como las aplicaciones clientes residen en un servidor de
aplicaciones y acceden a los Servidores de Capacidades de Servicio, SCSs, a través de la
API de OSA/Parlay del ISG. Estas APIs constituyen el adhesivo entre dichas
aplicaciones y los SCSs. De esta manera, las aplicaciones pueden llegar a ser
independientes de la tecnología de la red que haya por debajo.
Los SCSs proveen a las aplicaciones clientes los SCFs (Funcionalidades de
Capacidades de Servicio) de OSA. Un SCS puede tener múltiples SCFs. Los recursos de
la red son los elementos de la misma, así como los protocolos usados.
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 69
3.1.2 MiLife™ ISG SDK
MiLife™ ISG SDK (Software Development Kit) es una colección de
herramientas, documentación y código que facilita el desarrollo y el testeo de
aplicaciones basadas en el ISG de Lucent. Como cualquier sistema de desarrollo
software, el SDK contiene librerías, ejemplos y documentación necesarios para crear
aplicaciones propias.
Pero MiLife™ ISG SDK, además, incluye un potente simulador, que permite
probar las aplicaciones creadas sin la necesidad de recurrir a otros sistemas de prueba,
más reales, pero a la vez mucho más costosos.
El diagrama que se aprecia a continuación muestra la estructura básica de
MiLife™ ISG SDK:
Figura 15. Estructura de MiLife™ ISG SDK
Como aparece en la figura, la estructura básica consiste en los siguientes
componentes:
Convenience Classes
De la misma manera que MiLife™ ISG, con el SDK podemos utilizar
directamente las APIs de OSA/Parlay (en CORBA), y en diversos ejemplos
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 70
suministrados podemos ver el uso de las mismas. Pero a la vez se comprueba
que el uso de dichas interfaces no es trivial. Es por ello, que este entorno de
desarrollo nos ofrece las Convenience Classes, que son interfaces Java que
esconden la mayor parte de la complejidad de las APIs de OSA/Parlay. Son un
nivel de abstracción superior, es decir, las APIs que ofrece no son directamente
las de OSA/Parlay, sino que encapsula éstas ofreciendo otras mucho más
sencillas de utilizar, en Java, y que ahorra enormemente el proceso de creación
de aplicaciones. Evidentemente, esta abstracción provoca también una
simplificación en muchas de las funcionalidades, pero suficientes para los
objetivos que se persiguen en el presente proyecto.
Simulador y herramientas
El simulador ISG proporciona toda la funcionalidad necesaria para que una
aplicación recupere, reciba e intercambie datos a través de las interfaces de
OSA/Parlay. El simulador no está conectado con equipos de una red real. Se
puede controlar a través de una herramienta gráfica o a través de la línea de
comandos. La herramienta gráfica, que es la que se ha usado en la realización de
este proyecto para la simulación, permite, entre otras cosas, ejecutar scripts, así
como cambiar y ver el estado del simulador.
Documentación
Como se ha comentado más arriba, el software viene acompañado de guías de
referencia, tutoriales y del manual del usuario para el simulador. Además
incluye todas las librerías necesarias para poder trabajar con otros entornos de
desarrollo, como por ejemplo Eclipse, que es el que se ha usado en la realización
de este proyecto.
Aplicaciones de ejemplo y scripts
Como ayuda para empezar, el SDK incluye algunos ejemplos de aplicaciones
con las funcionalidades más significativas. Para ejecutar las aplicaciones
primero hay que hacer correr el simulador. Éste hace uso de un script, escrito en
XML, que le da toda la información que necesita para un comportamiento
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 71
dinámico durante la simulación. Por ejemplo, en el script se puede definir que
un abonado camine desde un punto A hasta otro B con una cierta velocidad. El
SDK también contiene scripts de ejemplo.
3.2 Simulador ISG
Este punto describe más en detalle las características y el uso del simulador de
MiLife™ ISG SDK. Nos vamos a centrar sobre todo en la herramienta gráfica del
mismo, pues ha sido la más usada. También se describirá la estructura de los archivos
XML usados para crear el entorno de pruebas de la aplicación.
En primer lugar profundizaremos en la estructura del paquete SDK y en algunas
de sus principales características. A continuación se describirán los pasos más
importantes que se han seguido para configurar y usar tanto el simulador como la
herramienta gráfica, describiendo los paneles de simulación, elementos que forman parte
de la herramienta gráfica y que permiten llevar a cabo la simulación.
3.2.1 Estructura del SDK
A continuación se muestra una figura que muestra la estructura del SDK con un
nivel de detalle mucho mayor que el mostrado en el punto anterior:
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 72
Figura 16. Estructura detallada del SDK
En la figura podemos apreciar que existen tres capas bien diferenciadas: la de
aplicación, la del simulador y la de herramientas. En la capa de aplicación es donde
residirán las aplicaciones creadas, que podrán usar la API de OSA/Parlay directamente o
bien las OSA/Parlay Convenience Classes suministradas por el SDK. Estas aplicaciones
se comunicarán con el simulador a través de la interfaz OSA/Parlay, y éste hará uso de
las herramientas suministradas por la herramienta gráfica para poder suministrar a la
aplicación toda información que solicite acerca de la red.
El simulador SDK es, en realidad, una colección de simuladores, uno por cada
uno de los siguientes SCSs (Service Capability Servers):
Framework (FW): simula el armazón, pieza necesaria en este tipo de
arquitectura de servicios, y con la que es necesaria establecer la comunicación
inicial para poder obtener el resto de funcionalidades.
User Location (UL): ofrece información acerca de las posiciones de los
terminales siguiendo distintos procedimientos (cuando se solicite,
periódicamente o por eventos previamente especificados).
User Status (US): ofrece información sobre el estado de los terminales
(ocupado, apagado o encendido), y al igual que el anterior, también de diversas
maneras (cuando se solicite o por eventos programados).
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 73
Presence and Availability Management (PAM).
Charging and Accounting Management (CHAM): permite manejar la
tarificación de los abonados.
Call Control (CC): ofrece todas las funcionalidades relacionadas con una
llamada telefónica.
User Interaction (UI): simulador que ofrece la capacidad de reproducir
mensajes predefinidos a través de una llamada y poder obtener respuesta del
oyente (a través de la pulsación o pulsaciones de las teclas del terminal).
Messaging (MSG): ofrece la capacidad de envío y detección de llegada de
correos electrónicos.
Multi-Media Messaging (MMM): ofrece la capacidad de envío y detección de
llegada de mensajes (MMS).
El simulador incluye un monitor de mensajes OSA/Parlay entre la
aplicación de usuario y él mismo. Además, los eventos más importantes
ocurridos durante la simulación se copian en un fichero (log). El bloque Script
Processor es usado para cargar y ejecutar scripts en la herramienta gráfica desde
la aplicación.
El simulador está inicialmente vacío, lo que significa que no contiene ningún
tipo de información de simulación, como son los abonados y sus comportamientos. La
única manera de llenarlo de información es a través de los scripts. Aunque se pueden
hacer cambios del estado del simulador con la herramienta gráfica, como por ejemplo
cambiar la localización o estado de un abonado, sus posibilidades son limitadas. Los
scripts ofrecen un mayor control para la simulación, desde el punto de vista de la
precisión y de la temporalidad.
Todos los SCSs simulados soportan el concepto de abonado. Un abonado se
identifica mediante su MSISDN, que es un número de 12 dígitos. El nombre del
abonado, definido en el script, es también visible en la herramienta gráfica. Como el
nombre del abonado puede ser elegido libremente, es más fácil referenciar un nombre
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 74
que un número (que es lo que es el MSISDN). El simulador ISG también soporta el
concepto de grupos, que son tratados por la herramienta gráfica como un único abonado
(desde el punto de vista de la localización, estado,...) con un rango de distintos
MSISDNs. Esto es útil cuando hay que realizar pruebas con multitud de abonados. El
concepto de grupo no es soportado por la interfaz OSA/Parlay, sin embargo una petición
de cualquier abonado que es parte de un grupo es una solicitud válida, de la misma
manera que si un grupo hace una llamada en el simulador, las aplicaciones pueden
recibir disparos por cada uno de los abonados de ese grupo.
Como ya se ha comentado anteriormente, el simulador ofrece una serie de
herramientas para trabajar, una gráfica, y otra desde línea de comandos.
Herramienta gráfica. El simulador se puede arrancar desde dentro de la
herramienta gráfica. Ésta provee una manera para ver y controlar los scripts, los
SCSs y el monitor de mensajes OSA/Parlay CORBA. Esta herramienta consiste
en un conjunto de herramientas que corren bajo la misma aplicación. Puede
estar desconectada o conectada con el simulador. En éste último caso, y con un
script cargado, la apariencia de la misma es más o menos como se puede
apreciar en la siguiente figura:
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 75
Figura 17. Herramienta gráfica del simulador ISG
Herramienta de línea de comandos. Permite controlar el simulador mediante
scripts. Con esta herramienta el usuario puede comprobar el estado del Script
Processor y cargar y ejecutar scripts. Normalmente se utiliza para
procesamiento de archivos por lotes.
3.2.2 Configuración del simulador ISG
Gracias a la comunicación CORBA entre varios elementos, las aplicaciones
cliente, el simulador y las herramientas (tanto gráfica como la de línea de comandos)
pueden correr en diferentes ordenadores. De la misma manera, la herramienta gráfica y
el simulador pueden ejecutarse bajo la misma Máquina virtual de Java (JVM), a
diferencia de la herramienta de línea de comandos y aplicaciones que no pueden correr
en la misma JVM que el simulador. Por esta razón, ha sido necesario instalar dos
máquinas virtuales en el ordenador en el que se ha desarrollado el proyecto, puesto que
el simulador y las aplicaciones corrían en la misma máquina. Como el simulador, según
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 76
el fabricante, estaba probado para JSE v 1.4, es esta JVM la que soporta el simulador. A
parte, se instaló el JDK 6, que es el que se usa para hacer correr las aplicaciones.
Con la herramienta gráfica de Lucent MiLife™ ISG SDK podemos realizar lo
siguiente:
Arrancar el simulador: es la manera más fácil de hacerlo. Se puede configurar la
herramienta gráfica (y es la configuración utilizada en el presente proyecto) para
que una vez arrancada establezca conexión con el simulador, corra éste en la
misma máquina o en otra diferente. Esto se hace a través del fichero
isgsimgui.properties o también con una opción de la herramienta gráfica. Una
vez haya arrancado la aplicación, la apariencia del mismo es la misma que la
mostrada en la figura anterior, pero sin información alguna cargada (el panel de
los scripts, que es la parte de la izquierda aparecerá vacía, así como todo lo
relacionado con los abonados).
Conectar a un simulador remoto: aunque se puede hacer de manera automática,
si el simulador está en una máquina remota es preferible hacerlo de manera
manual. El simulador soporta que se conecten múltiples clientes, ya sea desde la
herramienta gráfica o desde la de línea de comandos. La conexión desde la
herramienta gráfica, que es la que se ha utilizado, se ilustra con la figura 19:
Figura 18. Conexión con el simulador
Una vez establecida la conexión, se puede cargar un script (mediante el panel
de script) y ejecutarlo, para comenzar así la simulación.
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 77
Desconectar el simulador: como se puede apreciar en la figura anterior, en el
menú File tenemos la opción de desconexión, o simplemente podemos cerrar la
aplicación.
La configuración del SDK, y por ello del simulador y la herramienta gráfica, se
puede realizar de las siguientes maneras:
Desde el menú View de la herramienta gráfica.
Figura 19. Menú View de la herramienta gráfica
Desde este menú se puede seleccionar activar o desactivar ciertas partes de la
herramienta y nos permite acceder a los submenús Preferences y Configuration.
A continuación se muestran imágenes de cada submenú con las configuraciones
escogidas.
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 78
Figura 20. Pestaña General del Menú Preferentes
En esta ventana encontramos varias pestañas. En la primera de ellas,
simplemente se ha escogido que la aplicación arranque y se conecte al simulador
automáticamente. Como ya se dijo anteriormente, se ha utilizado el mismo
ordenador para todo, por lo que el simulador corre en localhost. A continuación
se muestran las demás pestañas con las opciones utilizadas.
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 79
Figura 21. Pestaña Panels del Menú Preferences
La herramienta gráfica se compone de distintos paneles que engloban a todos
los SCSc. En esta pantallas podemos escoger los paneles, y por tanto los SCSs
que queremos que aparezcan, pues a lo mejor nuestra aplicación no hace uso de
ellos.
Figura 22. Pestaña User Location del Menú Preferences
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 80
En esta pantalla se pueden configurar algunas opciones del SCS User Location.
Se puede escoger entre un mapa almacenado localmente o uno escogido de
Internet.
A continuación se muestra la última pestaña de esta pantalla, que contiene
algunas características de aspecto y uso del panel Call Control & MMM, que es
en el que aparecen los terminales de los abonados cargados en el simulador. La
configuración de User Interaction también se incluye aquí, pues está
íntimamente relacionada con las llamadas.
Figura 23. Pestaña Call Control & User Interaction del Menú Preferences
A continuación se muestran las otras opciones elegidas del submenú
Configuration, que al igual que el Preferences, es una pantalla con diversas
pestañas.
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 81
Figura 24. Pestaña Framework del Menú Configuration
Cada aplicación en la base de datos del Framework tiene asociada un
identificador de aplicación (Application ID), usado para autentificar la
aplicación en el simulador. Unido a cada identificador de aplicación están los
servicios que la aplicación puede usar (Servidores de Capacidades de Servicio,
SCSs). En esta pantalla podemos ver como podemos borrar, actualizar o crear
nuevos identificadores de aplicación, crear su contraseña (Secret Key) y
asociarle a cada uno de ellos los servicios que vayan a usar. Se puede ver en la
imagen el creado para este proyecto. Esta tarea se puede hacer también a través
de los scripts, de manera que cada vez que se ejecutan, crean el Aplication ID si
no estaba creado.
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 82
Figura 25. Pestaña MultiMediaMessaging del Menú Configuration
Esta pestaña, MultiMediaMessaging, puede ser usada para activar o desactivar
algunos escenarios de error en el envío de mensajes multimedia, para hacer la
simulación más realista. Entre ellos podemos destacar:
o Activar o desactivar las respuestas en caso de fallo.
o Incluir texto extra para que sea lanzado a través de la excepción para los
fallos de envío y cancelación de mensajes.
o Incluir un número de abonado al que enviar el mensaje de entrega
fallida.
Estas configuraciones permiten al usuario activar errores para así comprobar las
distintas excepciones. Estas excepciones se producen en la red, pero se
configuran en el simulador pues es éste el que simula el comportamiento de la
misma.
Editando las propiedades del simulador.
Se ha visto cómo se pueden configurar ciertas características de la herramienta
gráfica a través de los menús y barras de herramientas de la misma, pero la
mayoría de características, sobre todo del panel de User Location, que es el que
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 83
necesita de una mayor definición de características para crear el entorno deseado
(lugares del mapa, imágenes de lugares, posicionamiento de dichos lugares,…),
se tienen que hacer a través del fichero de configuración isgsimgui.properties.
En cuanto a lo que el simulador se refiere, desde la herramienta gráfica
solamente se puede configurar el identificador de aplicación para el Framework.
Las propiedades específicas del simulador están definidas en el archivo
isgsimulator.properties. En este fichero de pueden modificar multitud de
características de la red, para cada uno de los SCSs por separado. A modo de
ejemplo, se muestran un par de líneas de dicho archivo:
o isgsim.us.network_type=UMTS
Establece el tipo de red para el SCS User Status. Cuando su valor es
UMTS, el disparo de eventos por parte de la red será soportado por el
simulador. Cuando el valor es CDMA, no.
o isgsim.ul.network_type=CDMA
Hace lo mismo que la línea anterior pero para el simulador User
Location.
3.2.3 Paneles de simulación
Ya se ha descrito, sin entrar en demasiados detalles, la configuración básica que
se ha utilizado en el simulador y en la herramienta gráfica de MiLife™ ISG SDK. Ahora
se van a describir brevemente los paneles de que consta dicha herramienta, y que son los
que permiten interactuar con las aplicaciones creadas, para tratar de conseguir un
realismo lo más alto posible. Nos centraremos en los que se han usado en el desarrollo
de la aplicación de teleasistencia.
Si volvemos a mirar la figura 17 (Estructura detallada del SDK) veremos como
la herramienta gráfica se compone de una serie de paneles, y son éstos los que
intercambian directamente información son los SCSs correspondientes del simulador.
Cada SCS tiene su propio panel, excepto el de User Interaction, puesto que un abonado
de User Interaction no existe hasta que una llamada esté activa. Los anuncios de este
SCSs se muestran tanto en el panel User Location y en el Call Control.
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 84
Los paneles se pueden ejecutar solos, sin necesidad de arrancar la herramienta
gráfica, con lo que sólo se estaría ejecutando el SCS correspondiente en el simulador.
Para ello hay que ejecutar “panel.bat” en el directorio bin de la instalación del SDK. Se
necesita también pasar el tipo de panel como primer parámetro el archivo de lotes (los
tipos son: UL, US, PAM, CHAM, CC, Messaging, Script y Monitor).
El primer panel que se va a mostrar es el de script. Aparece a la izquierda de la
herramienta gráfica y contiene información acerca del script cargado en el simulador. En
la figura se puede apreciar con un rectángulo de color rojo que lo rodea.
Figura 26. Script y User Location Panels
Podemos realizar varias acciones con los scripts. Dentro de un script se definen
uno o varios programas, y dentro de ellos, uno o más pasos. En este panel, podemos
elegir el script que queremos cargar, elegir dentro de él el programa que queremos y
luego ejecutar los pasos que necesitemos. Se pueden elegir distintos modos de ejecución
de scripts (modo continuo o no).
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 85
En la misma figura anterior podemos observar también el User Location Panel.
Se observa como este panel tiene dos partes bien diferenciadas: una, la de arriba, en la
que se muestra el mapa donde se está realizando la simulación, y otra consistente en una
tabla que contiene todos los abonados que se encuentran registrados en el SCS User
Location. En el mapa, un dispositivo móvil representa a un abonado o grupo de
abonados. El movimiento de dicho dispositivo se corresponde con el movimiento del
abonado. Además, las llamadas y los anuncios entre abonados se muestran en el mapa
para que sea más intuitivo. En la tabla, además del nombre de cada abonado, su número
o MSISDN y de su posición en el mapa (longitud y latitud) se puede obtener el radio de
incertidumbre.
El simulador User Location soporta dos modelos básicos de red. Se deberá
definir en el script cuál se está usando. El primero de ellos es el ideal, en el que el
simulador devuelve exactamente la localización del abonado a la aplicación que lo
solicite (a través de la interfaz OSA/Parlay). El segundo de ellos es un modelo de rejilla,
en el que el simulador devuelve la posición central de la rejilla o celda donde se
encuentra el abonado. Si se pica en la opción Show Grid de un abonado en cuestión se
mostrará en el mapa la celda para ese abonado. El tamaño de la celda en metros es igual
al radio de incertidumbre.
En el mapa se pueden añadir imágenes propias para abonados y lugares de
interés. Para ello deben añadirse los archivos GIF o JPG en el directorio etc\images.
Como también se ha comentado antes, se pueden añadir mapas, como ha sido este caso
con el de Sevilla. Para ello hay que añadirlos en etc\maps. Si se añaden mapas, es
también recomendable actualizar el fichero mapcoordinates.properties en el directorio
anterior. Este fichero contiene las coordenadas de los límites de todos los mapas que se
almacenan localmente para el simulador.
A continuación se presenta la imagen del panel User Status. Éste consiste en una
tabla con todos los abonados registrados en el SCS correspondiente. En dicha tabla,
además del nombre del abonado y su MSISDN respectivo, se muestra el tipo de terminal
que posee (MOBILE, IP o FIXED) y da información de en qué estado se encuentra cada
terminal (REACHABLE, NOT REACHABLE o BUSY). Además permite seleccionar
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 86
tanto el tipo de terminal como el estado en que queremos que esté cada uno de ellos.
Esta característica es la que se ha utilizado en nuestro servicio de teleasistencia. La
aplicación detecta cuando algún terminal de los pacientes alcanza un estado de NOT
REACHABLE, puesto que se ha solicitado previamente a la interfaz OSA/Parlay que
notifique dicho evento. Para simular esto, es necesario este panel.
Figura 27. User Status Panel
Por último se va a mostrar el panel relacionado con las llamadas y la mensajería
multimedia. Estas funcionalidades comparten panel de simulación. Éste está formado
también por dos partes: una serie de terminales con aspecto de teléfono, que representan
los dispositivos de los abonados, y una tabla con el estado actual de cada abonado (en lo
que a llamadas se refiere). Esto se ilustra con la figura 28.
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 87
Figura 28. Call Control & MMM Panel
Todos los teléfonos de todos los abonados definidos en el SCS de Call Control
no aparecen al arrancar el panel (sólo aparecen un número fijo definido en la
configuración de dicho panel). Si queremos ver algún terminal en concreto que no
aparece, se activa la casilla Show device del abonado en cuestión.
Con estos teléfonos podemos llamar a cualquier abonado definido en el
simulador (cuando se establezca una llamada aparecerá en la tabla información
relacionada con la misma -número origen, destino,...). Estos dispositivos nos permiten
también mandar MMS, accediendo mediante el botón Menú que tienen en el centro y
navegando por las opciones que aparecen en la pantalla.
El panel Call Control puede reproducir anuncios correspondientes a la
funcionalidad User Interaction y mostrar los textos correspondientes a dichos anuncios
encerrados en bocadillos, como puede apreciarse en la siguiente figura:
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 88
Figura 29. Reproducción de mensaje de User Interaction
Aunque el SCF User Interaction no soporta anuncios de texto, el simulador ISG,
los script y la herramienta gráfica sí que lo soportan (mostrándolos a través de
bocadillos, y no dentro de los terminales) pero solamente para demostraciones. Por otro
lado, el simulador sólo permite que haya interacción con el usuario que inicia la
llamada, y no permite recoger información del que la recibe. Esto ha supuesto un
problema durante la realización del presente proyecto y se explicará más adelante con
detalle, tanto el problema como la solución adoptada.
Destacar también que existen más paneles, correspondientes al resto de SCSs, y
cuya apariencia es muy parecida a los ya expuestos. No se entra en más detalles puesto
que apenas se han utilizado en la realización del proyecto. Concretamente, además de
los explicados, el simulador dispone de los siguientes:
Messaging
Presence and Availability Management
Charging and Accounting
Monitoring
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 89
3.3 Convenience Classes
El objetivo de MiLife™ SDK es facilitar el desarrollo rápido de aplicaciones
que tienen como objetivo comunicarse con MiLife™ ISG. Éste soporta la versión R4 de
de la API de OSA definida por el Third Generation Partnership Project (3GPP) y la
versión 3.2 de la API de Parlay definida por el Parlay Forum. Todas estas APIs están
definidas en OMG IDL, permitiendo una comunicación directa con el simulador ISG
usando CORBA. Alternativamente, el SDK ofrece un conjunto de clases Java que
facilitan enormemente el desarrollo de aplicaciones. Estas clases son las Convenience
classes, y son las que se han utilizado en el desarrollo del servicio de teleasistencia.
Estas clases se pueden dividir en dos partes:
OSA/Parlay convenience classes: proporcionan una API Java que se
corresponde con una abstracción de alto nivel de las interfaces OSA/Parlay. Esta
API Java ofrece la mayoría de funcionalidades de OSA/Parlay, escondiendo
muchas de las partes más engorrosas de la misma.
Script convenience classes: proveen una API Java para controlar el simulador
desde un programa Java, por ejemplo para cargar scripts de simulación en el
simulador y ejecutarlos.
3.3.1 OSA/Parlay convenience classes
Este conjunto de clases consiste en un número de adaptadores, como se muestra
en la figura de más abajo. Cada adaptador ofrece una interfaz simplificada hacia la
interfaz OSA/Parlay del SCSs correspondiente. Las principales simplificaciones son:
Las estructuras más complejas de datos están ocultas.
Los valores por defecto se usan en la mayor medida posible.
Los métodos asíncronos se han transformado en síncronos donde ha sido
posible.
Con los adaptadores, la tarea de crear una pequeña aplicación y probarla se
simplifica, pues estos son capaces de comunicarse con el simulador ISG. La figura 31
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 90
ilustra un esquema con los adaptadores existentes y su correspondiente mapeo con los
SCSs existentes en MiLife™ SDK.
Figura 30. Adaptadores de OSA/Parlay convenience classes
A continuación se van a enumerar los pasos a seguir, y que evidentemente se
han seguido en el presente proyecto, para crear una aplicación usando estas clases. Estos
pasos solamente se refieren a cómo obtener acceso a los SCSs, ya que una vez que lo
tenemos el uso de que hagamos de las funcionalidades de los mismos depende del fin
que se quiera obtener con nuestra aplicación.
1. Si usamos el simulador ISG para probar la aplicación, deberemos configurarlo
primero para que reconozca la aplicación (suministrándole el identificador de
aplicación y el secret key). Como ya se vio en puntos anteriores, esta información se
crea bien a partir del script de simulación bien a través de la pestaña de
configuración del Framework de la herramienta gráfica. En el caso de una ISG
‘real’, será el operador el que suministre estas credenciales. En el caso que nos
ocupa, esta información de identificación y autentificación la creamos nosotros
mismos.
2. En la aplicación, hay que crear un FrameworkAdapter usando la clase
FrameworkAdapterFactory. Se necesita pasarle como parámetro el identificador de
aplicación previamente creado y el secret key, de esta manera nuestra aplicación se
autentificará con el framework.
3. Mediante el FrameworkAdapter antes creado, podemos obtener el resto de
adaptadores de servicio usando uno de los métodos select……Service().
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 91
4. Usar los adaptadores para acceder a las funcionalidades que necesitemos de cada
SCS.
3.3.2 Script convenience classes
Estas clases son mucho menos extensas que las anteriores. Consisten
simplemente en dos adaptadores:
ScriptAdapter: ofrece una interfaz simplificada que permite cargar y ejecutar
scripts en el simulador.
FileMgrAdapter: ofrece una interfaz con funciones que permiten el manejo de
ficheros y carpetas. Este adaptador ofrece una lista de los scripts que están
disponibles para el Script Processor (que es una parte del simulador ISG).
Además de estos adaptadores, existe la interfaz ScriptCallback. Una clase que
implemente esta interfaz recibirá notificaciones sobre los eventos más importantes
relacionados con las ejecuciones de los scripts. Todo esto se ilustra en la siguiente
figura:
Figura 31. Adaptadores de Script convenience classes
3.4 Scripts XML
En este punto se va a comentar las características principales del formato de los
scripts con los que hay que abastecer al simulador para establecer las condiciones
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 92
necesarias para las pruebas de simulación. Hay que definirlos en XML. MiLife™ SDK
define una serie de esquemas (schemas) que hay que seguir para que el simulador, a
través del script panel de la herramienta gráfica, reconozca los scripts como válidos.
Todo script de simulación debe contener como elemento raíz la etiqueta
<simulation>. Esta etiqueta representa una simulación. Los elementos hijo de ésta se
muestran en el siguiente esquema. El orden de los mismos no tiene porqué ser el mismo
que se muestra en el esquema, pero de aparecer, tienen que ser únicos.
Figura 32. Etiqueta simulation
Mediante <suscriberSet> definimos el conjunto de los abonados, <suscriber>,
que van a estar presentes en la simulación. Se define para cada uno de ellos su nombre,
mediante un atributo y su MSISDN (también es posible definir un alias). Otro posible
atributo es groupSize, por defecto a uno, y que indica si estamos ante un abonado o un
grupo. Se ilustra con el siguiente esquema:
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 93
Figura 33. Etiqueta suscriberSet.
Con la etiqueta <stepSet> definimos un conjunto de pasos. Cada uno de ellos se
define mediante la etiqueta <step>. Cada script puede definir uno o más programas. Un
programa no es más que referencias ordenadas a pasos definidos dentro de <stepSet>.
Estos pasos son distintos según a que SCS pertenezca la actividad que queremos
realizar. También pueden definirse pasos globales, que afectarán a todos los SCSs
(como añadir o remover abonados).
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 94
Figura 34. Etiqueta step
Vemos como la etiqueta <scsStep> que aparece en el esquema anterior es
abstracta, es decir, sólo podemos usar una concreta: ccStep, ulStep,…, dependiendo de
a qué SCS pertenezca la acción.
A la etiqueta <step> se le puede especificar un nombre, mediante el atributo
name, que será la forma de referenciar dicho paso en cualquier punto del script.
Como se ha comentado anteriormente, en la definición de los programas, lo
único que se hace es referenciar pasos definidos anteriormente, y asignarles un orden
aportando también información de tiempo. Con la etiqueta <programSet> se engloban
todas las definiciones relacionadas con los programas. Cada programa que se defina ha
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 95
de estar encerrado entre etiquetas <program>, y con <programStep> se referencia el
paso que se necesite. Se ilustra lo anterior con el esquema correspondiente.
Figura 35. Etiqueta programSet
Como se puede apreciar en la figura 36, para definir un paso de un programa, o
bien se referencia un paso previamente definido, o bien usamos la etiqueta <clear>, que
lo que hace es reiniciar todos los datos del simulador. Además, mediante la etiqueta
<delay> podemos indicar el retraso en milisegundos con respecto al paso anterior, o bien
con <fromStart> se indica el retraso en la ejecución del paso pero con respecto al inicio
del programa. Para definir el orden se utiliza un atributo dentro de <programStep>, seq,
que toma valores enteros.
Por último comentar que la etiqueta <behaviorSet> contiene una lista global de
definiciones de comportamiento, diferente para cada uno de los SCSs. Cada SCS posee
sus etiquetas propias. Se muestra el esquema general a continuación.
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 96
Figura 36. Etiqueta BehaviorSet
Capítulo II: Introducción teórica 3. MiLife™ ISG SDK
Raúl Parras Eliche 97
Raúl Parras Eliche 98
Capítulo III
Desarrollo del Proyecto
Raúl Parras Eliche 99
Capítulo III: Desarrollo del proyecto 1. Introducción
Raúl Parras Eliche 100
1. Introducción 1. Introducción
n este capítulo se va a describir todo el trabajo realizado durante este
proyecto. A modo de introducción se exponen los puntos más importantes
que se van a desarrollar posteriormente:
Base de Datos. Para el funcionamiento de la aplicación es necesario que se
almacene información acerca de los pacientes, cuidadores, ambulancias, etc. por
lo que se pensó en crear una pequeña base de datos, y que la aplicación la
gestionara.
Configuración simulador y creación del entorno de simulación. El simulador
venía configurado con una serie de características estáticas, como un mapa
propio, una serie de lugares y terminales, etc. que se han modificado para
adecuarlas a nuestros requisitos. Por otro lado, para realizar cualquier
simulación, hay que aportar información dinámica al simulador: como el
número de abonados que van a participar (especificando nombres y números de
terminal), sus movimientos y otras características. Esto se realiza mediante un
fichero XML, con una serie de etiquetas predefinidas, como ya se comentó en el
capítulo anterior.
Programación. Se describirá aquí todo el código java desarrollado utilizando la
representación en UML de las distintas clases implementadas. Se mostrarán
E
Capítulo III: Desarrollo del proyecto 1. Introducción
Raúl Parras Eliche 101
también las relaciones principales entre las clases. No se entrará en detalles,
pues para eso se aporta todo el código comentado en los anexos.
Antes de comenzar con los apartados mencionados más arriba, se van a
enumerar los SCF’s que emplea la aplicación desarrollada, explicando cuál es la
funcionalidad que se busca con ellos:
Framework (FW): simula el armazón, pieza necesaria en este tipo de
arquitectura de servicios, y con la que es necesaria establecer la comunicación
inicial para poder obtener el resto de funcionalidades.
User Location (UL): ofrece información acerca de las posiciones de los
terminales siguiendo distintos procedimientos (cuando se solicite,
periódicamente o por eventos previamente especificados); es la base de la
aplicación creada, pues de esta manera nuestros pacientes están totalmente
vigilados, ya que su posición es comprobada periódicamente.
User Status (US): ofrece información sobre el estado de los terminales
(ocupado, apagado o encendido), y al igual que el anterior, también de diversas
maneras (cuando se solicite o por eventos programados). En el servicio
implementado se ha utilizado para detectar cuando el terminal de un paciente se
apaga (o queda fuera de cobertura), pues esto supone que no se pueda seguir
comprobando su posición.
Call Control (CC): ofrece todas las funcionalidades relacionadas con una
llamada telefónica. Es necesaria para poder establecer criterios y poder capturar
las llamadas requeridas (las llamadas son tratadas como objetos) para así
realizar la actividad que en cada momento se precise: desviarla a otro número,
rechazarla, reproducir mensajes pregrabados,...
User Interaction (UI): simulador que ofrece la capacidad de reproducir
mensajes predefinidos a través de una llamada y poder obtener respuesta del
oyente (a través de la pulsación o pulsaciones de las teclas del terminal). En el
servicio de Teleasistencia se ha utilizado para que los cuidadores informen a
través de un menú predefinido de la situación de su paciente, cuando una alarma
por posible pérdida se produce.
Capítulo III: Desarrollo del proyecto 1. Introducción
Raúl Parras Eliche 102
Multi-Media Messaging (MMM): ofrece la capacidad de envío y detección de
llegada de mensajes (MMS). En la aplicación creada se utiliza cuando es
necesario transmitir información sin la necesidad de obtener una respuesta del
destinatario de la misma. Por ejemplo, cuando un cuidador se encuentra con su
paciente, el servicio de localización periódica se desactiva, si salen del radio de
seguridad, pues el paciente se encuentra atendido. Cuando, el paciente se vaya a
quedar sólo, el cuidador, a través de un MMS, informa a la central de que es
necesario activar de nuevo dicho servicio de localización para el paciente.
Capítulo III: Desarrollo del proyecto 2. Base de datos
Raúl Parras Eliche 103
2. Base de datos 2. Base de Datos
e han creado sólo aquellas tablas necesarias para la aplicación, y con las
columnas más imprescindibles. Desde el punto de vista de la aplicación
final sería necesario conocer muchos más datos de los pacientes, como por ejemplo
enfermedades, medicamentos y otro tipo de información médica. También sería
interesante tener almacenada más información acerca de cuidadores y ambulancias,
pero, como se ha comentado más arriba, sólo se han creado aquellas tablas y columnas
necesarias para hacer correr la aplicación.
La base de datos está realizada con SQL, más concretamente con MySQL. El
servidor de base de datos empleado ha sido MySQL Server 5.0. Como se comentó en la
introducción general, se ha hecho uso también de MySQL Tools for 5.0, que incluye la
herramienta MySQL Administrator. Con ella el proceso de creación de bases de datos se
acelera enormemente. La base de datos creada se llama teleasistencia y tienen acceso a
ella los usuarios root y user (ambos tienen como contraseña pass). El usuario user es el
que utiliza la aplicación para realizar consultas y actualizaciones de la base de datos
cuando se está ejecutando. Para el acceso a la base de datos se ha utilizado la API
JDBC, para lo cual se empleó el driver MySQL Connector/J, que es el driver de JDBC
para MySQL. El driver lo suministra libremente MySQL AB, creadora del resto de
software antes mencionado.
S
Capítulo III: Desarrollo del proyecto 2. Base de datos
Raúl Parras Eliche 104
Para representar las distintas tablas que conforman la base de datos se ha hecho
uso de otra herramienta del paquete MySQL Tools: MySQL Workbench. Esta
herramienta permite crear base de datos de una manera gráfica. Pero lo que se ha
utilizado de ellas es la capacidad de realizar ingeniería inversa: a partir de una base de
datos creada, es capaz de obtener su representación gráfica. Es esta representación la
que se muestra a continuación. En primer lugar se muestran las tablas cuidadores,
pacientes y servicios_contratados y las relaciones existentes entre ellas.
Figura 37. Tablas pacientes, cuidadores y servicios_contratados
La tabla pacientes contiene, como su nombre indica, a los pacientes. En ella se
almacena el DNI, MSISDN y nombre y apellidos de cada uno de ellos. Además, se
almacena el DNI del cuidador que tiene asociado, así como su longitud y latitud de
referencia. Todos los pacientes almacenados en esta tabla no tienen porqué tener algún
servicio contratado. Para ello se emplea la tabla servicios_contratados. En ella, cada
entrada asocia el DNI de un paciente con el código de una alarma (el índice es un entero
que se auto incrementa cuando se añade una entrada en la tabla). En la aplicación
implementada se tienen dos tipos de servicios: el de localización y el de caída.
Evidentemente, el DNI del paciente es una foreign key (relación de uno a muchos), al
Capítulo III: Desarrollo del proyecto 2. Base de datos
Raúl Parras Eliche 105
igual que lo es el DNI del cuidador en la tabla pacientes. En la tabla cuidadores se
almacena la información relativa a estos, identificándolos también mediante su DNI.
A continuación se muestran las dos tablas que restan para completar la base de
datos: estadopacloc y ambulancias.
Figura 38. Tabla ambulancias
Figura 39. Tablas estadopacloc
En la tabla ambulancias, como su propio nombre indica, se almacenan las
ambulancias de las que dispone el servicio. Por ahora sólo se almacenan de ellas su
Capítulo III: Desarrollo del proyecto 2. Base de datos
Raúl Parras Eliche 106
MSISDN, para poder contactar con ellas (el índice es un entero que se auto incrementa
cuando se añade una entrada en la tabla). En cuanto estadopacloc, es una tabla necesaria
en tiempo de ejecución de la aplicación. Cada entrada almacena una asociación entre un
MSISDN (el de un paciente) y su estado en el servicio de localización, que se representa
mediante un entero. Estos estados son necesarios para la aplicación para saber si un
paciente se encuentra atendido o no, porque esto condicionará la necesidad de generar
una alarma según ciertas condiciones.
Capítulo III: Desarrollo del proyecto 3. Configuración de simulador
Raúl Parras Eliche 107
3. Configuración del simulador 3. Configuración y creación del entorno de simulación
n lo que se refiere a la configuración del simulador, ha sido necesario
modificar ciertos archivos de configuración para adaptarlo al entorno que
se buscaba. Los principales cambios se han llevado a cabo en simulador UL (User
Location).
El software MiLife suministra mapas de las principales ciudades europeas.
Sobre estos mapas, hay que definir la longitud y latitud tanto máxima como mínima, que
se corresponden con las esquinas de los mismos. Por parte de España, el mapa que se
aporta es el de Madrid, pero con muy poca resolución; por eso se pensó en utilizar otro
de mayores dimensiones. Como había que buscar otro, pues se aprovechó para usar uno
de Sevilla. Una vez conseguido el mapa en Internet, y para conseguir un mayor
realismo, se decidió no usar las coordenadas por defecto que suministra el programa,
pues eso supondría obtener unas distancias que en nada se corresponderían con lo que se
visualizase en el mapa. Para obtener tanto la longitud como la latitud del mapa que se
poseía, se recurrió al programa Google Earth, de distribución gratuita. Una vez definido
el escenario, y con unas coordenadas bastantes próximas a la realidad, se pasó a definir
en el mapa lugares fijos, como la sede central desde donde se supone que se presta el
servicio de teleasistencia como los lugares de residencia de cada uno de los pacientes.
Estos lugares se especifican en el fichero isgsimgui.properties, y a cada uno de ellos se
les asocia una imagen para que aparezca en el mapa. Estos lugares son independientes
del mapa que se utilice, aparecerán en todos, por lo que los lugares de ejemplo que
E
Capítulo III: Desarrollo del proyecto 3. Configuración de simulador
Raúl Parras Eliche 108
especificaba el simulador se eliminaron. El resto de características de configuración
apenas se han modificado.
En cuanto a la creación del entorno de simulación, se refiere a la creación del
fichero XML que proporciona al simulador toda la información que necesita para llevar
a cabo la simulación del servicio de telasistencia. El fichero creado, denominado
también teleasistencia, define los abonados (con nombres y MSISDN) en cada uno de
los simuladores menores que conforman el simulador al completo, define los
comportamientos en algunos de los simuladores (comportamiento en cuanto movimiento
sobre el mapa en el simulador UL, comportamiento a la hora de actuar en caso de recibir
una llamada en el simulador, etc.). También se definen caraterísticas técnicas de los
simuladores, como características temporales de respuesta, retrasos, tipos de red,
probabilidad de error en las peticiones o respuestas, etc. Se proporciona dicho archivo
en los anexos, para consultarlo con mayor detalle.
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 109
4. Clases de la aplicación 4. Clases de la aplicación
omo ya se ha comentado en la introducción de este capítulo, en este punto
se va a describir todo el código desarrollado. Se va a abordar desde un
punto de vista gráfico, es decir, no se va a entrar en describir de forma detallada el
código, si no que se va a recurrir a esquemas y representaciones en UML. Para alguna
duda más concreta, se aporta todo el código comentado y el Javadoc en los anexos.
En la imagen que se muestra a continuación se muestra el esquema del proyecto
al completo. Todo el código fuente se encuentra en la carpeta src. En la carpeta bin se
encuentran todos los archivos ejecutables y en doc toda la documentación (Javadoc) del
proyecto (que también se suministra en los anexos).
C
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 110
Figura 40. Esquema completo del proyecto
La estructura que se va a seguir en este punto es la misma que la que se sigue en
el proyecto. Se va a ir analizando las clases de cada paquete por separado. La clase
TeleAsistencia, cuya representación en UML se muestra a continuación (figura 41) no
pertenece a ninguno de los paquetes creados, pues se trata de la clase principal que
contiene el método Main().
Figura 41. Clase TeleAsistencia
Esta clase es la encargada de iniciar el servicio de TeleAsistencia. Mediante el
método iniciaAplicacion() se identifica con el Framework (contiene el identificador de
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 111
aplicación y la contraseña) y a partir de ahí obtiene el resto de adaptadotes de servicio
necesarios en la aplicación. Por último, en el método Main(), existe un bucle infinito que
se encarga de procesar constantemente el vector de alarmas. Una vez iniciado el resto de
adaptadores (que implica crear hilos hijos para el procesamiento del estado de los
pacientes), el hilo principal, el del Main(), se duerme. Cuando alguno de estos hilos
hijos crea una alarma, lo despierta, y entra en el bucle entes mencionado para el
procesamiento de la alarma en cuestión.
A continuación se muestra un diagrama con las relaciones más importantes entre
esta clase y las clases que se encargan de ofrecer las funcionalidades de red más
importantes. Estas clases se analizarán más adelante. Podemos comprobar como
podemos hacer una distinción en dos grupos de clases a las que accede TeleAsistencia:
las que lanzan el resto de servicios que componen la aplicación y las que se encargan de
la gestión (clases que definen métodos para el tratamiento de objetos específicos). Se
enumeran a continuación las que lanzan el resto de funcionalidades del servicio:
1. LocalizacionUsuario: se encarga de crear un nuevo hilo que comprueba y analiza
periódicamente las posiciones de los pacientes.
2. InteraccionUsuarioLoc: implementa una interfaz Listener; captura las llamadas
provocadas por una alarma en el servicio de localización y realiza la interacción con
los cuidadores.
3. EstadoUsuarioLis: implementa una interfaz Listener; tiene como misión detectar los
cambios de estado de los terminales de los pacientes (cuando un terminal se apaga o
queda fuera de cobertura, se genera un evento procedente de la red, previamente
configurado, y que esta clase captura y procesa).
4. MensajeMultimediaLis: implementa una interfaz Listener; está continuamente
detectando la llegada de un mensaje a los terminales de cambio de estado del
paciente o alarma por caída.
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 112
Figura 42. Principales relaciones de la clase TeleAsistencia
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 113
4.1 Paquete BaseDeDatos
Este paquete, como se ve en el esquema del paquete mostrado a continuación,
sólo contiene una clase: BaseDeDatos. El resto de archivos corresponden a los
diagramas UML de la clase.
Figura 43. Esquema del paquete BaseDeDatos
En la siguiente figura podemos observar la representación UML de la clase. Esta
clase define los métodos necesarios para acceder a la base de datos de la aplicación. El
método reiniciaBBDDloc() es llamado por el método Main() cuando se inicia la
aplicación, y reinicia la tabla estadopacloc, asignando el estado normal (en el que se
chequea la posición periódicamente) a todos los pacientes. Los métodos restantes de la
clase sirven para actualizar datos de la base de datos (actualiza(sentencia_SQL)) o para
realizar alguna consulta (consulta(sentencia_SQL)), y pueden ser llamados desde
cualquier lugar.
Figura 44. Clase BBDD
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 114
4.2 Paquete EstadoTerminal
El contenido de este paquete se puede visualizar en la siguiente figura. Este
paquete agrupa las clases que tienen una funcionalidad común: la de averiguar cuál es el
estado en el que se encuentra un terminal de abonado, aunque según la clase, se hace de
una manera u otra. Este estado puede ser: REACHABLE, BUSY o NOT REACHABLE.
Se definen dos clases en el paquete EstadoTerminal: EstadoUsuario y
EstadoUsuarioLis.
Figura 45. Esquema del paquete EstadoTerminal
A continuación se puede observar la representación en UML (figura 46) de las
clases antes mencionadas. Vemos como EstadoUsuarioLis implementa una interfaz
Listener y accede a EstadoUsuario.
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 115
Figura 46. Clases EstadoUsuarioLis y EstadoUsuario
La diferencia entre ambas clases radica en que EstadoUsuarioLis, al
implementar la interfaz Listener correspondiente (suministrada por las Convenience
Classes de MiLife) está continuamente ‘escuchando’ el estado de los terminales que se
le especifique, en nuestro caso, los de los pacientes. Con el método establecerUsuarios()
le especificamos los números de abonado (MSISDN) que queremos monitorizar y con el
método iniciaMonitorizacionEstado() informamos a la red y solicitamos el inicio de la
escucha. Cuando algún terminal de los especificados cambie su estado, la red lo
notificará mediante un evento, que será capturado por el método onEvent(), y se dará
paso a procesaEstado(), que tomará las medidas oportunas. Mientras que
EstadoUsuario() ofrece la funcionalidad de usar el método estadoTerminal(MSISDN),
que devuelve el estado en el que se encuentra el terminal especificado como parámetro.
El uso que hace la clase Listener de EstadoUsuario es la de usar el constructor de ésta,
para no repetir código.
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 116
A la clase EstadoUsuario se accede desde cualquier punto de la aplicación, es
decir, la usará cualquier clase que necesite de la información del estado de un terminal
concreto, mientras que la clase EstadoUsuarioLis, la ejecuta el método Main() al
iniciarse la aplicación, para que esté continuamente ejecutándose.
4.3 Paquete Localizacion
Este paquete almacena las clases relacionadas con el servicio de localización.
Como se puede ver en el esquema del mismo, define dos clases: LocalizacionUsuario y
HiloLoc. El servicio de localización de pacientes, como ya se explicó en la introducción
general de este documento, consiste en comprobar periódicamente cuáles son las
posiciones de los pacientes y analizar qué distancia les separa de sus posiciones de
referencia, que normalmente corresponderá a sus casas. Se ha establecido un intervalo
de chequeo de las posiciones de 30 segundos, aunque esto es configurable. Si esas
distancias superan el kilómetro, se generará una alarma por cada paciente que la haya
superado.
Figura 47. Esquema del paquete Localizacion
La representación en UML de las clases se muestra más abajo. La clase
LocalizacionUsuario la utiliza el método Main() cuando se inicia la aplicación.
Mediante el método invocaUL(), se crea un objeto de la clase HiloLoc, que extiende a la
clase Thread, creándose un nuevo hilo que es el encargado de solicitar a la red las
posiciones de los pacientes que tengan contratado el servicio (método run(), que
consiste en un bucle infinito). Cuando obtenga esas posiciones, el método
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 117
procesaPosiciones(UserLocations) de la clase LocalizacionUsuario se encargará de
procesarlas.
Figura 48. Clases LocalizacionUsuario e HiloLoc
El procesamiento de esas posiciones puede provocar que se cree una alarma, lo
que originará de inmediato que el hilo principal se despierte. Este hilo analizará la
alarma mediante el método procesaAlarmaLoc(…), que básicamente lo que hace es
averiguar cuál es la distancia entre el paciente y su cuidador. Si la distancia es menor a
20 metros, se procede a enviar un mensaje al cuidador (utilizando la clase
MensajeMultimedia) informándole del hecho. Si es mayor a 20 metros, se establece
comunicación con el cuidador mediante una llamada telefónica. El cuidador responderá
con información que será analizada con el método procesaRespCuid(…), y según su
respuesta, se llamará a una ambulancia para que vaya en auxilio del paciente o
simplemente se cambiará su estado.
4.4 Paquete InteracciónUsuario
Este paquete pretende agrupar a las clases que ofrecen la funcionalidad de la red
denominada UserInteraction. La interacción con el usuario se refiere a que sobre una
llamada telefónica se reproduzcan mensajes pregrabados, normalmente menús, y el
oyente pulse las teclas asociadas a la opción que desee o las elija mediante voz. Para
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 118
realizar esta actividad, es necesario ‘capturar’ de entre todas las llamadas que se
produzcan por la interfaz OSA/Parlay aquellas que nos interesen, por lo que hay que
establecer una serie de criterios (esto implica realizar una escucha continua de las
llamadas que se están produciendo). Después de que esa llamada sea capturada, se
iniciará el envío de los mensajes pregrabados y la posterior captura de las respuestas del
oyente.
Pues bien, en la aplicación realizada, sólo en una ocasión se establece
interacción con un usuario, más concretamente con los cuidadores. Como se ha
comentado en el apartado anterior, cuando se produce una alarma por localización y la
distancia del paciente respecto al cuidador supera los 20 metros, se establece
comunicación con el cuidador correspondiente. Se supone que, en realidad, el ordenador
donde esté corriendo esta aplicación estaría conectado a un teléfono o similar, y en el
momento que hubiera que establecer comunicación con el cuidador se ejecutaría la
orden pertinente sobre dicho aparato. En nuestro caso, puesto que se trata de una
simulación, teníamos que conseguir que el teléfono del simulador asociado al servicio
de teleasistencia (denominado central) realizara la llamada al cuidador en cuestión de
manera automática, es decir, que la aplicación la realizara, y no manualmente desde el
simulador. Para conseguir esto se ha realizado lo siguiente:
En los scripts que cargan información en el simulador se pueden definir
también programas (acciones a realizar por los abonados definidos dentro
del simulador). Se han creado entonces todas las posibles llamadas que se
pueden producir entra la central y los cuidadores (siendo cada llamada un
programa independiente).
Se han empleado unas clases definidas en la API de MiLife que permiten
comunicarse con el simulador desde la aplicación, de tal manera que se
pueden ejecutar programas definidos en los scripts, conociendo de ante
mano el nombre de los ficheros XML y el de los programas a ejecutar. Se ha
creado una clase que engloba a estas funcionalidades, denominada Script,
que pertenece al paquete de Gestión, y que se explicará más adelante.
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 119
Teniendo en cuenta lo anterior, el funcionamiento es el siguiente: cuando se
produce la alarma por localización, y la distancia entre cuidador y paciente supera los 20
metros, se hace uso de los métodos definidos en la clase antes mencionada, se ejecuta
una llamada desde la central al cuidador, deteniendo el hilo a continuación. Entonces
esta llamada será capturada (con el método onEvent(CallControlEvent)) por el hilo que
está a la escucha de las llamadas, es decir, por la clase UserInteraction, pues
implementa la interfaz CallControlListener. Una vez capturada, es cuando se hace uso
de las características de esta funcionalidad. Se reproduce un mensaje al cuidador
mediante el método enviarMenuAlarmaLoc(Call), informándole de que su paciente ha
excedido el radio de seguridad, y se le pide que informe si conoce la situación del
cuidador (puede que está acompañado de familiares y él lo sepa) o no. El cuidador
pulsará una tecla, se comprobará la respuesta mediante el método
tratarRespCuid(UIReport) (se ha tenido en cuenta que su pulsación sea errónea o fuera
de tiempo y en tal caso se le avisa y se le da un nuevo intento) y se grabará para que sea
analizada por el hilo principal que previamente se durmió (por lo que en este punto se
vuelve a despertar).
Aunque se ha comentado más arriba que lo que se hace es ejecutar una llamada
desde la central al cuidador, la llamada que se ejecuta en realidad en el simulador es en
el sentido contrario: desde el cuidador a la central. Esto es debido a lo que ya se explicó
en el apartado 3 del capítulo II: la interacción con el usuario en el simulador sólo se
permite en el sentido del llamante, por lo que para poder establecer comunicación con
los cuidadores, reproducirles un mensaje y obtener una respuesta de ellos, la llamada
deben iniciarla los cuidadores. Esto en realidad no sería así, pues la interacción se
establece independientemente de quién inicie la llamada.
A continuación se muestra el esquema de este paquete. Sólo contiene una clase,
InterccionUsuarioLoc, pues sólo se establece interacción en el servicio de localización.
Dicha clase se representa también más abajo en UML.
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 120
Figura 49. Esquema del paquete InteraccionUsuario
Figura 50. Clase InteraccionUsuarioLoc
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 121
4.5 Paquete MensajeriaMultimedia
Este paquete contiene las clases cuya funcionalidad está relacionada con el
envío y recepción de mensajes multimedia. A pesar de ser mensajes multimedia, el uso
que se hace de ellos es sólo para texto, aunque se podría enviar todo tipo de datos:
mensajes de voz, imágenes, etc. Al igual que en el paquete UserStatus, se definen dos
clases: MensajeMultimedia, que define métodos para enviar un mensaje multimedia
estableciendo las direcciones de emisor y receptor y especificando el fichero de texto
que contiene la información a enviar y MensajeMultimediaLis, que implementa la
interfaz MMMListener, y cuya funcionalidad es la de estar continuamente ‘escuchando’
si llegan mensajes a dos terminales específicos provenientes de los pacientes o los
cuidadores (los de reopción de alarmas de caída y cambios de estado de los pacientes en
el servicio de localización). El contenido del paquete se muestra en la imagen siguiente.
Figura 51. Esquema del paquete MensajeriaMultimedia
La representación en UML de ambas clases se muestra más adelante, en la
figura 52. La clase MensajeMultimediaLis la utiliza el método Main() cuando se inicia la
ejecución de la aplicación. Crea un objeto de ese tipo, y mediante el método
monitorizaMMM() establece los criterios y solicita a la interfaz OSA/Parlay el inicio de
la escucha para la recepción de mensajes multimedia según los criterios establecidos.
Cuando algún mensaje cumpla los criterios, se produce un evento desde la interfaz, que
la aplicación captura en forma de objeto del tipo MMMEvent en el método
onEvent(MMMEvent), y éste llamará al método procesaMMS(…) que analizará el
mensaje y tomará las medidas oportunas (según sea una alarma por caída o un aviso
para cambiar el estado de un paciente).
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 122
Figura 52. Clase MensajeriaMultimediaLis
En cuanto a la clase MensajeMultimedia, decir que una vez que hemos
construido un objeto de la misma, mediante el método
establecerDirecciones(receptores,emisor) especificamos el número de abonado del
terminal que va a enviar el MMS y el conjunto de números de los terminales que reciben
dicho mensaje y con el método enviarMensaje(…) se produce el envío del mensaje. A
este último método se le pasa el fichero de texto que contiene la información a enviar.
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 123
Figura 53. Clase MensajeriaMultimedia
4.6 Paquete Gestion
Se muestra a continuación el contenido de este paquete. Como se puede
comprobar engloba a cinco clases encargadas de gestionar distintos aspectos.
Figura 54. Esquema del paquete Gestion
Las clases que conforman este paquete, a diferencia de lo que ocurre en los
anteriores, no están asociadas por la funcionalidad de la red con la que trabajan. En este
paquete se han incluido clases que ofrecen métodos para manejar los distintos tipos de
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 124
datos creados y para manejar la comunicación con el simulador. A continuación se
enumeraran sus principales características así como sus cometidos:
1. GestionAlarmas. Como se ha comentado en otros puntos del presente documento,
cuando nos referimos a que se genera una alarma se quiere decir que se crea un
objeto del tipo Alarma. Una vez creada esta alarma, se añade a un vector, de manera
que lo que se hace es formar una cola FIFO: la primera que se cree será la primera
en ser tratada, y este vector es continuamente leído por el hilo principal. Pues bien,
para comprobar, añadir o eliminar alarmas del vector, hay que hacerlo de una
manera sincronizada (pues son hilos hijos los que las van creando). Esta clase define
estos métodos, de tal manera que sólo un hilo podrá acceder en un momento
determinado al vector de alarmas.
2. GestionAmbulancias. Clase que define métodos para tratar los objetos Ambulancia.
El principal método es ambulanciaMasCercana(…) que devuelve el MSISDN de la
ambulancia que está más cerca de la posición que se le pasa como parámetro,
teniendo en cuenta también que esté libre.
3. GestionCaida. Cada vez que se procese una alarma por caída de un paciente, se
implementa un objeto de esta clase. Define el método procesaAlarmaCaida(), que lo
que hace es averiguar la posición del paciente y con ella obtener cuál es la
ambulancia libre y más cercana a él, empleando para ello el método
ambulanciaMasCercana() explicado más arriba.
4. GestionPacientes. Clase que define métodos para tratar los objetos Paciente,
creados a partir de la información almacenada en la base de datos. En el comienzo
de la aplicación, se lee la base de datos y se crean tantos objetos Paciente como
pacientes tengan contratado el servicio de localización, para poder trasladar esa
información al hilo que comprueba periódicamente sus posiciones.
5. Script. Esta clase se ha explicado anteriormente. Utiliza un adaptador de servicio
definido en la API del software MiLife utilizado que permite la comunicación con el
simulador para cargar scripts, ejecutar programas, pararlos, etc. Implementa la
interfaz ScriptCallBack. Al implementar esta interfaz se generan eventos en
determinadas situaciones (cuando se inicia o se termina de ejecutar un paso, o un
programa entero, cuando se completa la carga de un script, cuando se pausa la
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 125
ejecución, etc.) que son capturados por los métodos definidos por la interfaz, Esto
permite estar continuamente informado del estado del simulador, y poder
sincronizar la ejecución del programa con la simulación.
A continuación se representa el esquema UML de estas clases. Las relaciones
que se aprecian son sólo las que existen entre las clases del paquete, que básicamente
son las que tiene GestionCaida con el resto, puesto que ésta, al ser la que define la
actuación en caso de caída, ha de tratar con objetos Alarma y Ambulancia y
comunicarse con el simulador para establecer conexión telefónica con las ambulancias.
Figura 55. Clases GestionCaida, GestionAmbulancias,GestionAlarmas y Script
Figura 56. Clase GestionPacientes
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 126
4.7 Paquete TipoDatos
En este paquete se aglutinan aquellas clases e interfaces que definen los tipos de
datos así como constantes utilizadas por la aplicación. El contenido del mismo se
muestra en el esquema de más abajo. Se compone de tres clases y una interfaz.
Figura 57. Esquema del paquete TipoDatos
Se presenta a continuación la representación en UML de cada una de estas
clases, comentando sus características principales. Con la clase Alarma se define el
formato de las alarmas. Muchos de los campos que la componen no han sido utilizados
en la aplicación desarrollada, pero se han incluido pensando en posibles ampliaciones,
en las que se oferte una gama de servicios mayor y la gama de alarmas sea por tanto
mucho más amplia y como consecuencia haya que establecer prioridades. En esta clase
se definen también los valores constantes de los tipos de alarmas con las que trabaja la
aplicación: caída y persona perdida.
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 127
Figura 58. Clase Alarma
En cuanto a la clase Paciente sirve para reunir en un mismo objeto toda la
información necesaria de un paciente. Se usa principalmente cuando la aplicación
empieza a correr, pues como se comentó anteriormente, antes de lanzar los servicios
debemos de leer la base de datos para averiguar cuántos pacientes tienen contratado
algún tipo de servicio. Como resultado de esa lectura, se crea un vector de objetos
Paciente, que contiene toda la información de los pacientes (su identificación en forma
de DNI y su número de abonado), así como un vector para cada uno de ellos con los
servicios contratados. A partir de este momento, la aplicación tiene los datos necesarios
para lanzar los servicios.
Figura 59. Clase Paciente
Al igual que ocurre con los pacientes, cuando comienza a correr la aplicación, el
método Main() crea un vector de objetos Ambulancia, donde cada objeto se
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 128
corresponde con una ambulancia real (en este caso en el simulador). Para ello, el
servicio tiene registradas a todas sus ambulancias en la base de datos, y la aplicación
sólo tiene que realizar una consulta.
Figura 60. Clase Ambulancia
Por último, el paquete contiene a la interfaz NumerosServicio. En ella, se
definen los MSISDN de los terminales que componen el servicio de teleasistencia.
Figura 61. Interfaz NumerosServicio
Capítulo III: Desarrollo del proyecto 4. Clases de la aplicación
Raúl Parras Eliche 129
Raúl Parras Eliche 130
Capítulo IV
Conclusiones y líneas futuras
Raúl Parras Eliche 131
Capítulo IV: Conclusiones y líneas futuras
Raúl Parras Eliche 132
Conclusiones y líneas futuras
Como ya bien se comentó en el Capítulo I, una de las motivaciones principales a
la hora de realizar este tipo de aplicación es poder utilizar una tecnología como
OSA/Parlay, es decir, una interfaz estándar y abierta, independiente de la red subyacente
y del propietario de la misma. Pero la realización de este tipo de servicios es una tarea
complicada y dura, por lo que este proyecto pretende sentar las bases para que en
sucesivos trabajos esta tarea continúe y se desarrolle aún más. El camino a seguir, es en
mi opinión, el de poder crear no una aplicación con una o diversas funcionalidades, sino
diseñar una solución abierta, es decir, una manera estándar de gestionar distintos eventos
o alarmas, en el que cada servicio nuevo se pueda añadir sin que interfiera al resto. Crear
módulos independientes, pero relacionados entre sí, y cada uno con su función bien
definida. Esto es algo parecido a lo que nos ofrece OSA/Parlay: funcionalidades
genéricas abstraídas de la red, que podemos usar como convengan.
La aplicación realizada en este proyecto ha intentado ser lo más general posible,
es decir, dejar la puerta abierta para que puedan ser añadidos nuevos servicios (que no
son más que distintos usos de esas funcionalidades de la red antes mencionadas), aunque
como también se ha comentado se ha convertido en una tarea bastante complicada dado
que para poder conseguir testear el servicio ha sido obligatorio el empleo de código para
la comunicación con el simulador para recrear situaciones desde la propia aplicación
(que en realidad sería originadas por pacientes o cuidadores o aquellas personas
relacionadas con el servicio). Es por esto que se propone como posterior trabajo el
depurar esta aplicación, intentando delimitar aún más las partes con funcionalidades
Capítulo IV: Conclusiones y líneas futuras
Raúl Parras Eliche 133
distintas y añadiendo más servicios, aprovechando de esta manera todo el potencial que
ofrecen las redes móviles de tercera generación y, sobre todo, el empleo de la tecnología
OSA/Parlay.
Por otro lado, y complementado lo dicho en el párrafo anterior, otra posible
línea de actuación sería la de un análisis de escalabilidad del servicio implementado. El
simulador empleado tiene la posibilidad de utilizar un monitor para escuchar todos los
mensajes OSA/Parlay que pasan por la interfaz, por lo que también sería muy
interesante conocer como se comporta la aplicación de teleasistencia, que tiene que
comprobar periódicamente cuál es la posición de los pacientes, con un nivel de pacientes
mucho más elevado, observando la carga de tráfico y el nivel de saturación del servicio.
Comentar también que en toda esta memoria se ha hablado del hecho de la
localización de los pacientes, para lo que resulta necesario que todos ellos lleven encima
su terminal móvil. Pero como se comentó también en los objetivos del Capítulo I, este
servicio de asistencia está pensado para personas cuyas capacidades físicas y/o mentales
están notablemente mermadas, por lo que no parece muy lógico que estas personas
lleven consigo un teléfono móvil de tercera generación (básicamente porque apenas van
a usar ninguna de las capacidades que ofrece) tal y como los que existen en el mercado
actualmente y porque no se puede gravar a un paciente con la obligación de recordar que
tiene que portar un terminal telefónico, recargarlo …. Por eso, el desarrollo de un
terminal específico para el servicio sería muy interesante. Este dispositivo podría
integrar también otro tipo de sensores, generadores y/o detectores de alarmas (como por
ejemplo el de caídas), y podría diseñarse para que su uso fuera más transparente al
usuario, apoyándonos por ejemplo en tecnologías desarrolladas dentro del campo de la
inteligencia ambiental.
Raúl Parras Eliche 134
Capítulo V
Referencias bibliográficas
Raúl Parras Eliche 135
Capítulo V: Referencias bibliográficas
Raúl Parras Eliche 136
Referencias bibliográficas [1] Web de referencia OSA/Parlay: http://www.parlay.org/
[2] Web de referencia 3GPP: www.3gpp.org/
[3] Unión Internacional de Telecomunicaciones: IMT-2000
http://www.itu.int/home/imt.html
[4] Francisco José Fernández Jiménez. Resumen de la versión 4.1 de las
especificaciones de OSA y Parlay. Profesor Colaborador del
Departamento de Ingeniería de Sistemas y Automática. Área de
conocimiento Ingeniería Telemática. Escuela Superior de Ingeniería
Industrial. Universidad de Sevilla.
[5] Tecnología UMTS/3G. Disponible en:
http://www.umtsforum.net/tecnologia.asp
[6] Sobre el Foro UMTS (About the Forum). Disponible en: http://www.umts-
forum.org/content/view/2002/125/
[7] Informe esencial sobre telefonía por el protocolo Internet (IP). Disponible
en: www.itu.int/ITU-D/e-strategies/2007/publications-articles/pdf/IP-
tel_report-es.pdf
Capítulo V: Referencias bibliográficas
Raúl Parras Eliche 137
[8] Jaime Martin Serrano Orozco. OSA/Parlay. Departamento de
Comunicaciones y Teoría de la Señal. Universidad Politécnica de
Cataluña.
[9] MiLife™ ISG SDK 7.1 Documentation. ISG Software Development Kit.
Disponible en: http://www1.alcatel-
lucent.com/gsearch/search.jhtml?_requestid=66991
[10] Célio Rosa. El desafío del Valor Agregado. Disponible en:
www.parlay.org/imwp/idms/popups/pop_download.asp?contentID=7368
[11] Telefónica de Argentina. NGN: Hacia la convergencia de los servicios. La
evolución de los servicios en el marco de las redes de próxima generación.
[12] Federico Traspaderne Barnusell. Un futuro prometedor. La Sociedad de la
Información y la banda ancha en movilidad (3G).Manager de Ventas
Equipo Administración Pública de Vodafone. Disponible en:
http://portal.astic.es/NR/rdonlyres/DC47225F-9B96-421D-8638-
9EC17A0E7C26/0/mono07.pdf
[13] José Manuel Fornés Rumbao. OSA/Parlay: MiLife™ ISG SDK 4.0
(Lucent Technologies). Profesor adscrito al Área de Ingeniería Telemática,
dentro del Departamento de Ingeniería de Sistemas y Automática. Escuela
Superior de Ingeniería Industrial. Universidad de Sevilla. Disponible en:
http://trajano.us.es/~fornes/RSR/2005/Trabajo%20OSA_Parlay/Presentaci
on%20OSA_Parlay.ppt
[14] Iván Jirón A. y Héctor Kaschel C. Funadamentos para Redes de Próxima
Generación. Departamento de Ingeniería Eléctrica, Facultad de Ingeniería,
Universidad de Santiago de Chile. Disponible en:
http://www.senacitel.cl/senacitel2002/PG001.pdf
[15] UMTS, teléfonos móviles de tercera generación. Disponible en:
http://www.consumer.es/web/es/tecnologia/hardware/2004/03/11/96931.ph
p
Capítulo V: Referencias bibliográficas
Raúl Parras Eliche 138
[16] Sistemas Celulares de Tercera Generación. Disponible en:
http://www.monografias.com/cgi-
bin/search.cgi?query=sistemas%20celulares%20de%20tercera%20generaci
on
[17] Germán Medinabeitia Luque y Fernando Cárdenas Fernández. Bases de
Datos. Apuntes 5º Curso de Ingeniería de Telecomunicación.
Departamento de Ingeniería de Sistemas y Automática. Área de Ingeniería
Telemática. Escuela Superior de Ingeniería Industrial. Universidad de
Sevilla.
[18] José Manuel Framiñán Torres. Sistemas de Información basados en Web.
Versión: 0.3 (16/09/2006). Profesor Titular del Departamento de
Organización Industrial y Gestión de Empresas. Área de conocimiento
Organización de Empresas. Escuela Superior de Ingeniería Industrial.
Universidad de Sevilla.
[19] Antonio Jesús Sierra Collado. Fundamentos de Telemática. Apuntes 3º de
Ingeniería de Telecomunicación. Departamento de Ingeniería de Sistemas
y Automática. Área de Ingeniería Telemática. Escuela Superior de
Ingeniería Industrial. Universidad de Sevilla.
[20] Tutorial de Eclipse. Disponible en:
http://eclipsetutorial.forge.os4os.org/in1.htm
[21] Acceso a Base de Datos (JDBC). Disponible en:
http://www.programacion.com/tutorial/jdbc/
[22] Tutorial Java Nivel Básico. Disponible en:
http://www.programacion.net/java/tutorial/java_basico/
Raúl Parras Eliche 139
Capítulo VI
Anexos
Raúl Parras Eliche 140
Capítulo VI: Anexos Anexo I: teleasistencia.xml
Raúl Parras Eliche 141
1. Anexo I: Archivo de simulación: teleasistencia.xml 1 <?xml version="1.0" encoding="UTF-8"?> 2 <simulation xmlns="http://www.lucent.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:schemaLocation="http://www.lucent.com simulation.xsd" name="Simulacion de Teleasistencia">
3 4 <subscriberSet> 5 6 <subscriber name="Fernando"> 7 <MSISDN>150111111111</MSISDN> 8 </subscriber> 9 10 <subscriber name="Carmen"> 11 <MSISDN>150222222222</MSISDN> 12 </subscriber> 13 14 <subscriber name="Antonia"> 15 <MSISDN>150333333333</MSISDN> 16 </subscriber> 17 18 <subscriber name="Manuel"> 19 <MSISDN>150444444444</MSISDN> 20 </subscriber> 21 22 <subscriber name="Central"> 23 <MSISDN>160111111111</MSISDN> 24 </subscriber> 25 <subscriber name="Operadora"> 26 <MSISDN>160222222222</MSISDN> 27 </subscriber> 28 <subscriber name="numeroAlarmasCaida"> 29 <MSISDN>160333333333</MSISDN> 30 </subscriber> 31 <subscriber name="numeroCambiosEstadoPAciente"> 32 <MSISDN>160444444444</MSISDN> 33 </subscriber> 34 35 <subscriber name="Cuidador1"> 36 <MSISDN>170111111111</MSISDN> 37 </subscriber> 38 <subscriber name="Cuidador2"> 39 <MSISDN>170222222222</MSISDN> 40 </subscriber> 41 <subscriber name="Cuidador3"> 42 <MSISDN>170333333333</MSISDN> 43 </subscriber> 44 45 <subscriber name="Ambulancia1"> 46 <MSISDN>180111111111</MSISDN> 47 </subscriber> 48 <subscriber name="Ambulancia2"> 49 <MSISDN>180222222222</MSISDN>
Capítulo VI: Anexos Anexo I: teleasistencia.xml
Raúl Parras Eliche 142
50 </subscriber> 51 52 </subscriberSet> 53 54 <behaviorSet> 55 56 <!-- Define comportamientos que se pueden referenciar en cualquier lugar del
script --> 57 <ccBehaviorEndCall name="end_by_caller" byCaller="true"/> 58 <ccBehaviorEndCall name="end_by_callee" byCaller="false"/> 59 60 <ccBehaviorStatic name="available" act="willAnswer" answerDelay="4000"/> 61 <ccBehaviorStatic name="refuser" act="willRefuse"/> 62 63 <!-- Datos de localizacion de usuarios --> 64 <ulBehaviorStatic name="ul_Fernando" longitude="-5.98466"
latitude="37.38911"/> 65 <ulBehaviorStatic name="ul_Carmen" longitude="-5.97153" latitude="37.39874"/> 66 <ulBehaviorStatic name="ul_Antonia" longitude="-5.92810" latitude="37.38381"/> 67 <ulBehaviorStatic name="ul_Manuel" longitude="-5.95931" latitude="37.37933"/> 68 69 <ulBehaviorStatic name="ul_Cuidador1" longitude="-5.97125"
latitude="37.39050"/> 70 <ulBehaviorStatic name="ul_Cuidador2" longitude="-5.95282"
latitude="37.39764"/> 71 <ulBehaviorStatic name="ul_Cuidador3" longitude="-5.95135"
latitude="37.38389"/> 72 73 <!-- Datos de localizacion de la central --> 74 <ulBehaviorStatic name="ulCentral" longitude="-5.95589" latitude="37.39038"/> 75 76 <!-- Datos de localizacion y de movimiento de las ambulancias --> 77 <ulBehaviorRandom name="randomAmbulancia1" speed="100"> 78 <start longitude="-5.9722" latitude="37.4103"/> 79 <end longitude="-6.0056" latitude="37.3969"/> 80 </ulBehaviorRandom> 81 82 <ulBehaviorRandom name="randomAmbulancia2" speed="200"> 83 <start longitude="-5.9811" latitude="37.3864"/> 84 <end longitude="-5.9786" latitude="37.375"/> 85 </ulBehaviorRandom> 86 87 <!-- Todos los terminales, ya sean fijos o moviles, encendidos al iniciarse --> 88 <usBehaviorStatic name="usMobile" status="ON" terminal="MOBILE"/> 89 <usBehaviorStatic name="usFixed" status="ON" terminal="FIXED"/> 90 91 </behaviorSet> 92 93 <scsSet> 94 <ccState> 95 <!-- Establece el retraso, para el simulador CC, entre una solicitud y
una respuesta a traves de la interfaz OSA Parlay --> 96 <latency>50</latency> 97
Capítulo VI: Anexos Anexo I: teleasistencia.xml
Raúl Parras Eliche 143
98 <!-- El simulador, despues de 30s, considerara la llamada como no respondida -->
99 <parameters noAnswerTime="30000"/> 100 </ccState> 101 102 <ulState> 103 <!-- Establece el retraso, para el simulador UL, entre una solicitud y
una respuesta a traves de la interfaz OSA Parlay --> 104 <latency>50</latency> 105 <!-- This would generate simulated errors, so set to 0 --> 106 <fixedErrorFilter percentage="0"/> 107 <networkModel> 108 <!-- reports real position, modified by uncertainty radius --> 109 <ideal uncertainty="0"/> 110 </networkModel> 111 </ulState> 112 113 <usState> 114 <!-- sets the delay for the US SCS simulator between a request and
response through the OSA/Parlay interface --> 115 <latency>50</latency> 116 </usState> 117 118 <uiState> 119 <!-- sets the initial state of the UI simulator --> 120 <!-- inherited tags: latency, defaultSubscriberState and requestTimeout
--> 121 <!-- list of available announcements referenced by application --> 122 <uiInfoSet> 123 <uiInfo id="1" sound="announce.wav" text="Pulse: 1-Paciente
asistido. 2-No sabe nada." duration="10000"/> 124 <uiInfo id="2" sound="announce.wav" text="Muchas Gracias!
Se tomaran las medidas oportunas." duration="4000"/> 125 <uiInfo id="3" sound="announce.wav" text="La opcion
escogida no es valida." duration="4000"/> 126 <uiInfo id="4" sound="announce.wav" text="Demasiado
tarde." duration="4000"/> 127 </uiInfoSet> 128 </uiState> 129 130 </scsSet> 131 132 <stepSet> 133 <!-- Registro del Servicio de Teleasistencia con el Framework --> 134 <step name="Registrar_Servicio_Teleasistencia"> 135 <fwStep> 136 <fwState> 137 <applicationId> 138 <create id="Servicio de Teleasistencia"
secret="00010203040506070809"> 139 <service
name="P_USER_LOCATION"/> 140 <service
name="P_USER_STATUS"/>
Capítulo VI: Anexos Anexo I: teleasistencia.xml
Raúl Parras Eliche 144
141 <service name="P_USER_INTERACTION"/>
142 <service name="P_GENERIC_CALL_CONTROL"/>
143 <service name="P_MULTI_MEDIA_MESSAGING"/>
144 </create> 145 </applicationId> 146 </fwState> 147 </fwStep> 148 </step> 149 150 <!-- Aniade los usuarios al Simulador CC --> 151 <step name="Anadir_CC_Suscribers"> 152 <ccStep> 153 <addSubscriber> 154 <subscriberRef>Central</subscriberRef> 155 </addSubscriber> 156 <addSubscriber> 157 <subscriberRef>Cuidador1</subscriberRef> 158 </addSubscriber> 159 <addSubscriber> 160 <subscriberRef>Cuidador2</subscriberRef> 161 </addSubscriber> 162 <addSubscriber> 163 <subscriberRef>Cuidador3</subscriberRef> 164 </addSubscriber> 165 <addSubscriber> 166 <subscriberRef>Operadora</subscriberRef> 167 </addSubscriber> 168 <addSubscriber> 169
<subscriberRef>numeroAlarmasCaida</subscriberRef> 170 </addSubscriber> 171 <addSubscriber> 172
<subscriberRef>numeroCambiosEstadoPAciente</subscriberRef> 173 </addSubscriber> 174 <addSubscriber> 175 <subscriberRef>Fernando</subscriberRef> 176 </addSubscriber> 177 <addSubscriber> 178 <subscriberRef>Carmen</subscriberRef> 179 </addSubscriber> 180 <addSubscriber> 181 <subscriberRef>Antonia</subscriberRef> 182 </addSubscriber> 183 <addSubscriber> 184 <subscriberRef>Manuel</subscriberRef> 185 </addSubscriber> 186 <addSubscriber> 187 <subscriberRef>Ambulancia1</subscriberRef> 188 </addSubscriber> 189 <addSubscriber>
Capítulo VI: Anexos Anexo I: teleasistencia.xml
Raúl Parras Eliche 145
190 <subscriberRef>Ambulancia2</subscriberRef> 191 </addSubscriber> 192 </ccStep> 193 </step> 194 195 <!-- Aniade losusuarios al simulador UL --> 196 <step name="Establecer_User_Location"> 197 <ulStep> 198 <!-- Se establecen laas posiciones iniciales para los enfermos
--> 199 <ulSubscriberState> 200 <subscriberRef>Fernando</subscriberRef> 201 <behaviorRef>ul_Fernando</behaviorRef> 202 </ulSubscriberState> 203 <ulSubscriberState> 204 <subscriberRef>Carmen</subscriberRef> 205 <behaviorRef>ul_Carmen</behaviorRef> 206 </ulSubscriberState> 207 <ulSubscriberState> 208 <subscriberRef>Antonia</subscriberRef> 209 <behaviorRef>ul_Antonia</behaviorRef> 210 </ulSubscriberState> 211 <ulSubscriberState> 212 <subscriberRef>Manuel</subscriberRef> 213 <behaviorRef>ul_Manuel</behaviorRef> 214 </ulSubscriberState> 215 216 <!-- Posicion inicial para la Central --> 217 <ulSubscriberState> 218 <subscriberRef>Central</subscriberRef> 219 <behaviorRef>ulCentral</behaviorRef> 220 </ulSubscriberState> 221 222 <!-- Posicion inicial para las ambulancias --> 223 <ulSubscriberState> 224 <subscriberRef>Ambulancia1</subscriberRef> 225 <behaviorRef>randomAmbulancia1</behaviorRef> 226 </ulSubscriberState> 227 <ulSubscriberState> 228 <subscriberRef>Ambulancia2</subscriberRef> 229 <behaviorRef>randomAmbulancia2</behaviorRef> 230 </ulSubscriberState> 231 232 <!-- Posicion inicial para los cuidadores --> 233 <ulSubscriberState> 234 <subscriberRef>Cuidador1</subscriberRef> 235 <behaviorRef>ul_Cuidador1</behaviorRef> 236 </ulSubscriberState> 237 <ulSubscriberState> 238 <subscriberRef>Cuidador2</subscriberRef> 239 <behaviorRef>ul_Cuidador2</behaviorRef> 240 </ulSubscriberState> 241 <ulSubscriberState> 242 <subscriberRef>Cuidador3</subscriberRef>
Capítulo VI: Anexos Anexo I: teleasistencia.xml
Raúl Parras Eliche 146
243 <behaviorRef>ul_Cuidador3</behaviorRef> 244 </ulSubscriberState> 245 246 </ulStep> 247 </step> 248 <step name="Establecer_User_Status"> 249 <usStep> 250 <!-- Todos los usuarios con el dispositivo movil o fijo
encendido --> 251 <usSubscriberState> 252 <subscriberRef>Fernando</subscriberRef> 253 <behaviorRef>usMobile</behaviorRef> 254 </usSubscriberState> 255 <usSubscriberState> 256 <subscriberRef>Carmen</subscriberRef> 257 <behaviorRef>usMobile</behaviorRef> 258 </usSubscriberState> 259 <usSubscriberState> 260 <subscriberRef>Antonia</subscriberRef> 261 <behaviorRef>usMobile</behaviorRef> 262 </usSubscriberState> 263 <usSubscriberState> 264 <subscriberRef>Manuel</subscriberRef> 265 <behaviorRef>usMobile</behaviorRef> 266 </usSubscriberState> 267 <usSubscriberState> 268 <subscriberRef>Ambulancia1</subscriberRef> 269 <behaviorRef>usMobile</behaviorRef> 270 </usSubscriberState> 271 <usSubscriberState> 272 <subscriberRef>Ambulancia2</subscriberRef> 273 <behaviorRef>usMobile</behaviorRef> 274 </usSubscriberState> 275 <usSubscriberState> 276 <subscriberRef>Cuidador1</subscriberRef> 277 <behaviorRef>usMobile</behaviorRef> 278 </usSubscriberState> 279 <usSubscriberState> 280 <subscriberRef>Cuidador2</subscriberRef> 281 <behaviorRef>usMobile</behaviorRef> 282 </usSubscriberState> 283 <usSubscriberState> 284 <subscriberRef>Cuidador3</subscriberRef> 285 <behaviorRef>usMobile</behaviorRef> 286 </usSubscriberState> 287 288 289 <usSubscriberState> 290 <subscriberRef>Central</subscriberRef> 291 <behaviorRef>usFixed</behaviorRef> 292 </usSubscriberState> 293 <usSubscriberState> 294 <subscriberRef>Operadora</subscriberRef> 295 <behaviorRef>usFixed</behaviorRef>
Capítulo VI: Anexos Anexo I: teleasistencia.xml
Raúl Parras Eliche 147
296 </usSubscriberState> 297 <usSubscriberState> 298
<subscriberRef>numeroAlarmasCaida</subscriberRef> 299 <behaviorRef>usFixed</behaviorRef> 300 </usSubscriberState> 301 <usSubscriberState> 302
<subscriberRef>numeroCambiosEstadoPAciente</subscriberRef> 303 <behaviorRef>usFixed</behaviorRef> 304 </usSubscriberState> 305 </usStep> 306 </step> 307 308 <step name="Central_llama_170111111111"> 309 <ccStep> 310 <ccSubscriberState> 311 <subscriberRef>Cuidador1</subscriberRef> 312 <ccBehaviorSingleCall number="160111111111"/> 313 </ccSubscriberState> 314 315 <ccSubscriberState> 316 <subscriberRef>Central</subscriberRef> 317 <behaviorRef>available</behaviorRef> 318 </ccSubscriberState> 319 </ccStep> 320 </step> 321 322 <step name="Central_llama_170222222222"> 323 <ccStep> 324 <ccSubscriberState> 325 <subscriberRef>Cuidador2</subscriberRef> 326 <ccBehaviorSingleCall number="160111111111"/> 327 </ccSubscriberState> 328 329 <ccSubscriberState> 330 <subscriberRef>Central</subscriberRef> 331 <behaviorRef>available</behaviorRef> 332 </ccSubscriberState> 333 </ccStep> 334 </step> 335 <step name="Central_llama_170333333333"> 336 <ccStep> 337 <ccSubscriberState> 338 <subscriberRef>Cuidador3</subscriberRef> 339 <ccBehaviorSingleCall number="160111111111"/> 340 </ccSubscriberState> 341 342 <ccSubscriberState> 343 <subscriberRef>Central</subscriberRef> 344 <behaviorRef>available</behaviorRef> 345 </ccSubscriberState> 346 </ccStep> 347 </step>
Capítulo VI: Anexos Anexo I: teleasistencia.xml
Raúl Parras Eliche 148
348 <step name="Central_llama_180111111111"> 349 <ccStep> 350 <ccSubscriberState> 351 <subscriberRef>Central</subscriberRef> 352 <ccBehaviorSingleCall number="180111111111"/> 353 </ccSubscriberState> 354 355 <ccSubscriberState> 356 <subscriberRef>Ambulancia1</subscriberRef> 357 <behaviorRef>available</behaviorRef> 358 </ccSubscriberState> 359 </ccStep> 360 </step> 361 <step name="Central_llama_180222222222"> 362 <ccStep> 363 <ccSubscriberState> 364 <subscriberRef>Central</subscriberRef> 365 <ccBehaviorSingleCall number="180222222222"/> 366 </ccSubscriberState> 367 368 <ccSubscriberState> 369 <subscriberRef>Ambulancia2</subscriberRef> 370 <behaviorRef>available</behaviorRef> 371 </ccSubscriberState> 372 </ccStep> 373 </step> 374 375 </stepSet> 376 377 <programSet> 378 <program name="setup"> 379 <!-- clears current simulation --> 380 <programStep seq="0"> 381 <clear/> 382 <delay>0</delay> 383 </programStep> 384 <programStep seq="10"> 385 <stepRef>Registrar_Servicio_Teleasistencia</stepRef> 386 <delay>0</delay> 387 </programStep> 388 <programStep seq="20"> 389 <stepRef>Anadir_CC_Suscribers</stepRef>
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 149
2. Anexo II: Código de la Aplicación 2.1 Teleasistencia.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado OSA/Parlay 3 * 4 * TeleAsistencia.java 5 */ 6 7 import BaseDeDatos.BBDD; 8 import EstadoTerminal.EstadoUsuarioLis; 9 import Gestion.*; 10 import InteraccionUsuario.InteraccionUsuarioLoc; 11 import Localizacion.LocalizacionUsuario; 12 import MensajeriaMultimedia.MensajeMultimediaLis; 13 import TipoDatos.*; 14 import com.lucent.isg.appsdk.framework.*; 15 import com.lucent.isg.appsdk.userlocation.*; 16 import java.util.*; 17 18 /** 19 * Clase principal del servicio de tele asistencia. Contiene el método Main(). 20 * @author Raúl Parras Eliche. 21 */ 22 public class TeleAsistencia { 23 24 /** 25 * @uml.property name="fwAdapter" 26 */ 27 private FrameworkAdapter fwAdapter; 28 private Script script = null; 29 30 31 /** 32 * Metodo que inicializa el FrameworkAdapter. 33 * 34 * @throws FrameworkException 35 */ 36 private void iniciaAplicacion()throws FrameworkException{ 37 38 String Application_ID = "Servicio de Teleasistencia"; 39 String password = "00010203040506070809"; 40 41 fwAdapter =
FrameworkAdapterFactory.createFrameworkAdapter(Application_ID, password); 42 43 } 44 45 46 /**
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 150
47 * Metodo que termina todos los contratos de servicio con el framework y libera 48 * los recursos. 49 * 50 * @throws FrameworkException 51 * 52 */ 53 private void cleanup() throws FrameworkException { 54 55 if (script != null){ 56 57 script.destroy(); 58 } 59 60 if (fwAdapter != null){ 61 62 fwAdapter.endAccess(); 63 fwAdapter.destroy(); 64 } 65 66 } 67 68 69 /** 70 * Método que lista los servicios disponibles en el ISG. 71 * 72 * @throws FrameworkException 73 */ 74 public void listarServicios()throws FrameworkException{ 75 76 77 String lista_servicios[] = fwAdapter.listServices(); 78 if (lista_servicios.length > 0){ 79 80 System.out.println("Se ofrecen los siguientes servicios: "); 81 82 for (int i=0; i < lista_servicios.length; i++){ 83 84 System.out.println(" --> " +lista_servicios[i]);
85 } 86 }else{ 87 System.out.println("No hay servicios disponibles."); 88 } 89 90 System.out.println(""); 91 } 92 93 94 /** 95 * Función Main() del servicio. 96 * 97 * @param args 98 */ 99 public static void main(String[] args) {
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 151
100 // TODO Auto-generated method stub 101 102 // Inicializo el vector de ambulancias 103 GestionAmbulancias.listaAmbulancias(); 104 105 GestionPacientes gp = new GestionPacientes(); 106 107 // muestro por pantalla todos los pacientes con algún servicio contratado 108 Vector Pacientes = gp.listaPacientes(); 109 gp.imprimeVectorPacientes(Pacientes); 110 111 // preparo la tabla estadopacloc de la BBDD para la localización de pacientes 112 BBDD.reiniciaBBDDloc(Pacientes); 113 114 // no necesito más el vector Pacientes 115 Pacientes.clear(); 116 //*************************************************************************** 117 118 TeleAsistencia tA = new TeleAsistencia(); 119 120 // cargo el fichero XML "teleasistencia" en el simulador, necesario para 121 // realizar la simulacion y ejecuto el programa setup 122 tA.script = new Script(); 123 tA.script.cargaScript("teleasistencia.xml"); 124 tA.script.ejecutaPrograma("setup", true); 125 //*************************************************************************** 126 127 LocalizacionUsuario lu = null; 128 InteraccionUsuarioLoc iu = null; 129 MensajeMultimediaLis MMLis = null; 130 131 try { 132 // creo el FrameworkAdapter 133 tA.iniciaAplicacion(); 134 tA.listarServicios(); 135 136 137 // se inicia la localización periódica de los pacientes 138 lu = new LocalizacionUsuario(tA.fwAdapter); 139 lu.invocaUL(); 140 141 142 // lanzo la monitorización de llamadas 143 iu = new InteraccionUsuarioLoc (tA.fwAdapter); 144 iu.MonitorizaLLamadaLoc(); 145 146 // lanzo la monitorización en la recepción de MMS 147 MMLis= new MensajeMultimediaLis(tA.fwAdapter); 148 MMLis.monitorizaMMM(); 149 150 151 // lanzo la monitorizacion del estado de los terminales 152 EstadoUsuarioLis euLis = new EstadoUsuarioLis(tA.fwAdapter); 153 euLis.establecerUsuarios();
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 152
154 euLis.iniciaMonitorizacionEstado(); 155 156 157 // bucle que comprueba continuamente si el Vector Alarmas está
vacío; 158 // en caso contrario, tendrá que lanzar el tratamiento de alarmas 159 160 Alarma alarma; 161 162 while (true){ 163 164 // primero comprobamos si hay alguna alarma generada 165 166 while (!GestionAlarmas.Alarmas.isEmpty()){ 167 168 alarma = GestionAlarmas.Alarmas.firstElement(); 169 170 switch (alarma.id_alarma){ 171 172 case Alarma.CAIDA: 173 System.out.println("Se va a procesar
alarma por caida."); 174 GestionCaida gc = new
GestionCaida(tA.fwAdapter,tA.script); 175 gc.procesaAlarmaCaida(alarma); 176 break; 177 178 case Alarma.PERSONA_PERDIDA: 179 System.out.println("Se va a procesar
alarma por persona perdida."); 180 lu.procesaAlarmaLoc(alarma, tA.script,
tA.fwAdapter); 181 break; 182 183 default: 184 System.out.println("No se reconoce el tipo
de alarma."); 185 GestionAlarmas.eliminaAlarma(alarma);
186 187 } 188 } 189 190 191 synchronized (GestionAlarmas.Alarmas) { 192 System.out.println(""); 193 System.out.println("Bloqueo el hilo principal a la
espera de alarmas"); 194 System.out.println(""); 195 try { 196 GestionAlarmas.Alarmas.wait(); 197 } catch (InterruptedException e) { 198 // TODO Auto-generated catch block 199 e.printStackTrace();
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 153
200 } 201 202 } 203 204 } 205 206 } catch (FrameworkException e1) { 207 // TODO Auto-generated catch block 208 System.out.println("\n--- FrameworkException atrapada ---\n"); 209 e1.printStackTrace(); 210 System.out.println(""); 211 212 }finally{ 213 214 try { 215 216 tA.cleanup(); 217 lu.cleanup(); 218 219 } catch (FrameworkException e) { 220 // TODO Auto-generated catch block 221 System.out.println("\n--- FrameworkException atrapada ---
\n"); 222 e.printStackTrace(); 223 System.out.println(""); 224 } catch (UserLocationException e) { 225 // TODO Auto-generated catch block 226 System.out.println("\n--- UserLocationException atrapada ---
\n"); 227 e.printStackTrace(); 228 System.out.println(""); 229 } 230 } 231 } 232 233 }
2.2 Paquete BaseDeDatos 2.2.1 BBDD.java
1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * BBDD.java 5 */ 6 7 package BaseDeDatos; 8 9 import java.sql.*; 10 import java.util.Iterator; 11 import java.util.Vector; 12
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 154
13 import TipoDatos.Alarma; 14 import TipoDatos.Paciente; 15 16 /** 17 * Clase que implementa los métodos necesarios para el tratamiento de la base de datos del 18 * servicio. 19 * 20 * @author Raúl Parras Eliche 21 */ 22 public class BBDD { 23 24 private static Connection con = null; 25 private static Statement stmt = null; 26 private static ResultSet rs = null; 27 28 29 /** 30 * Método que realiza una consulta en la BBDD de la aplicación. 31 * 32 * @param sentencia_SQL - consulta SQL que queremos realizar. 33 * @return rs - objeto ResultSet con la información consultada en la BBDD. 34 */ 35 36 public static ResultSet consulta (String sentencia_SQL){ 37 38 try { 39 40 Class.forName("com.mysql.jdbc.Driver"); 41 42 } catch (ClassNotFoundException ex) { 43 // TODO Auto-generated catch block 44 System.out.print("\n--- ClassNotFoundException caught ---\n"); 45 System.out.println(ex.getMessage()); 46 } 47 48 try { 49 //host por defecto: 127.0.0.1 50 //puerto por defecto: 3306 51 String url = "jdbc:mysql://localhost/teleasistencia"; 52 con = DriverManager.getConnection(url,"user","pass"); 53 54 stmt = con.createStatement(); 55 rs = stmt.executeQuery(sentencia_SQL); 56 57 } catch (SQLException ex) { 58 // TODO Auto-generated catch block 59 System.out.println("\n--- SQLException caught ---\n"); 60 while (ex != null) { 61 System.out.println("Message: " + ex.getMessage ()); 62 System.out.println("SQLState: " + ex.getSQLState ()); 63 System.out.println("ErrorCode: " + ex.getErrorCode ()); 64 ex = ex.getNextException(); 65 System.out.println(""); 66 } 67 } 68 69 return rs; 70 } 71 72 /**
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 155
73 * Método para actualizar datos (actualizar, insertar o borrar) de la BBDD de 74 * la aplicación 75 * 76 * @param sentencia_SQL - orden en SQL a ejecutar. 77 */ 78 79 public static void actualiza(String sentencia_SQL){ 80 81 try { 82 83 Class.forName("com.mysql.jdbc.Driver"); 84 85 } catch (ClassNotFoundException ex) { 86 // TODO Auto-generated catch block 87 System.out.print("\n--- ClassNotFoundException caught ---\n"); 88 System.out.println(ex.getMessage()); 89 } 90 91 try { 92 //host por defecto: 127.0.0.1 93 //puerto por defecto: 3306 94 String url = "jdbc:mysql://localhost/teleasistencia"; 95 con = DriverManager.getConnection(url,"user","pass"); 96 97 stmt = con.createStatement(); 98 stmt.execute(sentencia_SQL); 99 100 101 } catch (SQLException ex) { 102 // TODO Auto-generated catch block 103 System.out.println("\n--- SQLException caught ---\n"); 104 while (ex != null) { 105 System.out.println("Message: " + ex.getMessage ()); 106 System.out.println("SQLState: " + ex.getSQLState ()); 107 System.out.println("ErrorCode: " + ex.getErrorCode ()); 108 ex = ex.getNextException(); 109 System.out.println(""); 110 } 111 } 112 113 } 114 115 116 /** 117 * Método que prepara la tabla estdopacloc de la Base de Datos antes de 118 * comenzar a comprobar y procesar la posición de los pacientes. Esta tabla 119 * almacena el estado de dichos pacientes (estado relacionado con la 120 * necesidad o no de comprobar sus posiciones en cada instante). 121 * 122 * @param Pacientes - Vector con todos los pacientes que existen en la BBDD 123 * y que tienen al menos algún servicio contratado. 124 */ 125 public static void reiniciaBBDDloc(Vector Pacientes){ 126 127 // borro los datos de la tabla estadopacloc 128 String sentencia_SQL = "TRUNCATE TABLE estadopacloc"; 129 BBDD.actualiza(sentencia_SQL); 130 //************************************************************************** 131 132
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 156
133 // Actualizo la tabla estadopacloc con los estados de los pacientes de 134 // localización 135 Iterator it1 = Pacientes.iterator(); 136 137 Paciente pac = null; 138 Vector serv = null; 139 Iterator it2 = null; 140 Integer alarm; 141 142 while (it1.hasNext()){ 143 144 pac = (Paciente) it1.next(); 145 serv = pac.servicios; 146 147 it2 = serv.iterator(); 148 149 while (it2.hasNext()){ 150 alarm = (Integer)it2.next(); 151 152 if (alarm == Alarma.PERSONA_PERDIDA){ 153 154 sentencia_SQL = "INSERT INTO estadopacloc " + 155 "(MSISDN,estadoLoc) " + 156 "VALUES ('" + pac.MSISDN + "','" 157 + Paciente.PacNORMAL + "')"; 158 159 BBDD.actualiza(sentencia_SQL);
160 } 161 162 } 163 } 164 } 165 166 }
2.3 Paquete EstadoTerminal 2.3.1 EstadoUsuario.java
1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * EstadoUsuario.java 5 */ 6 7 package EstadoTerminal; 8 9 import com.lucent.isg.appsdk.userstatus.*; 10 import com.lucent.isg.appsdk.framework.*; 11 12 /** 13 * Clase que implementa los métodos necesarios para averiguar el estado de un terminal. 14 *
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 157
15 * @author Raúl Parras Eliche 16 */ 17 public class EstadoUsuario { 18 19 /** 20 * Adaptador de servicio de estado de usuario. 21 */ 22 UserStatusAdapter usAdapter; 23 24 25 /** 26 * Construye un objeto EstadoUsuario e inicializa el Adaptador UserStatus mediante 27 * el FrameworkAdapter. 28 * 29 * @param fwAdapter - FrameworkAdapter del servicio de tele asistencia, necesario 30 * para obtener el resto de adaptadores. 31 */ 32 public EstadoUsuario(FrameworkAdapter fwAdapter){ 33 34 // Creo el adaptador de servicio 35 try { 36 37 usAdapter = fwAdapter.selectUserStatusService(); 38 39 System.out.println("Token de servicio de Estado de Usuario: " 40 + usAdapter.getServiceToken() +"\n"); 41 42 } catch (FrameworkException e) { 43 // TODO Auto-generated catch block 44 System.out.println("\n--- FrameworkException atrapada ---\n"); 45 e.printStackTrace(); 46 System.out.println(""); 47 } 48 } 49 50 /** 51 * Método que devuelve el estado de un terminal (REACHABLE, NOT REACHABLE O
BUSY). 52 * 53 * @param MSISDN - Número del terminal del que se quiere averiguar su estado. 54 * @return estadoUsuario - Estado del terminal: REACHABLE, NOT REACHABLE O
BUSY. 55 */ 56 public int estadoTerminal(String MSISDN){ 57 58 59 // por defecto el terminal no está disponible, por si falla la petición que no 60 // envíe otra cosa cuando no lo sabemos 61 int estadoUsuario = UserStatus.US_NOT_REACHABLE; 62 63 try { 64 UserStatus usStatus = usAdapter.requestStatus(MSISDN); 65 estadoUsuario = usStatus.getStatus(); 66
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 158
67 } catch (UserStatusException e) { 68 // TODO Auto-generated catch block 69 e.printStackTrace(); 70 } 71 72 return estadoUsuario; 73 } 74 75 /** 76 * Método que elimina el adaptador de servicio UserStatus. 77 */ 78 public void cleanup(){ 79 80 81 try { 82 usAdapter.destroy(); 83 84 } catch (UserStatusException e) { 85 // TODO Auto-generated catch block 86 System.out.println("\n--- UserInteractionException atrapada ---\n"); 87 e.printStackTrace(); 88 System.out.println(""); 89 } 90 91 } 92 }
2.3.2 EstadoUsuarioLis.java
1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * EstadoUsuarioLis.java 5 */ 6 7 package EstadoTerminal; 8 9 import BaseDeDatos.BBDD; 10 import Gestion.GestionPacientes; 11 import MensajeriaMultimedia.MensajeMultimedia; 12 import TipoDatos.NumerosServicio; 13 import TipoDatos.Paciente; 14 15 import com.lucent.isg.appsdk.framework.FrameworkAdapter; 16 import com.lucent.isg.appsdk.userstatus.*; 17 18 import java.sql.ResultSet; 19 import java.sql.SQLException; 20 import java.util.*; 21 22 /** 23 * Clase que implementa la interfaz UserStatusListener. Esta clase se encarga de 24 * establecer criterios para activar la monitorización en el cambio de estado de
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 159
25 * los terminales de los pacientes y define los métodos que capturan los eventos 26 * producidos como consecuencia de esa monitorización. 27 * 28 * @author Raúl Parras Eliche 29 * 30 */ 31 public class EstadoUsuarioLis implements UserStatusListener { 32 33 34 private FrameworkAdapter fwAdapter = null; 35 private EstadoUsuario eu = null; 36 private int assignmentId; 37 38 /** 39 * Array de UserStatus con los MSISDN de los pacientes que se va a comprobar sus
estados. 40 */ 41 private String[] usuarios = null; 42 43 44 /** 45 * Array de UserStatus que contendrá el estado de los pacientes cuando se produzca 46 * un evento. 47 */ 48 private UserStatus[] estadoActual = null; 49 50 /** 51 * Construye un objeto UserStatusLis usando el FrameworkAdapter para inicializar 52 * el adaptador UserStatus necesario. 53 * 54 * @param fwAdapter - FrameworkAdapter del servicio de tele asistencia, necesario 55 * para obtener el resto de adaptadores. 56 */ 57 public EstadoUsuarioLis(FrameworkAdapter fwAdapter){ 58 59 // obtengo un nuevoAdaptador de servicio usAdapter 60 this.fwAdapter = fwAdapter; 61 eu = new EstadoUsuario(fwAdapter); 62 63 } 64 65 66 /** 67 * Método que establece la información acerca de los pacientes para poder iniciar 68 * la monitorización de sus estados. 69 * 70 */ 71 public void establecerUsuarios(){ 72 73 // obtengo un vector con todos los pacientes que tienen contratado algún 74 // servicio, que son a los que voy a chequear el estado de sus terminales 75 GestionPacientes gp = new GestionPacientes(); 76 Vector pacientes = gp.listaPacientes(); 77
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 160
78 // construyo a partir de ese vector otro vector con los MSISDN de los pacientes 79 Iterator it = pacientes.iterator(); 80 Paciente p; 81 Vector<Long> pac= new Vector<Long>(); 82 83 while (it.hasNext()){ 84 85 p = (Paciente)it.next(); 86 pac.addElement(new Long(p.MSISDN)); 87 88 } 89 90 // elimino el vector de objetos paciente 91 pacientes.clear(); 92 93 94 // transformo el vector de MSISDN a array de String 95 usuarios = new String[pac.size()]; 96 it = pac.iterator(); 97 int i =0; 98 Long l; 99 while (it.hasNext()){ 100 l = (Long)it.next(); 101 usuarios[i] = l.toString(); 102 i++; 103 } 104 105 // elimino el vector pac 106 pac.clear(); 107 108 } 109 110 111 /** 112 * Método que inicia la monitorización del estado de los terminales de 113 * los pacientes. 114 * 115 */ 116 public void iniciaMonitorizacionEstado(){ 117 118 try { 119 assignmentId = eu.usAdapter.requestTriggeredStatus(usuarios, this); 120 } catch (UserStatusException e) { 121 // TODO Auto-generated catch block 122 System.out.println("\n--- UserInteractionException atrapada ---\n"); 123 e.printStackTrace(); 124 System.out.println(""); 125 } 126 127 } 128 129 /** 130 * Método utilizado para parar la monitorización del estado de los terminales 131 * de los pacientes.
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 161
132 */ 133 public void pararMonitorizacionEstado(){ 134 135 try { 136 eu.usAdapter.stopTriggeredStatus(assignmentId); 137 } catch (UserStatusException e) { 138 // TODO Auto-generated catch block 139 System.out.println("\n--- UserInteractionException atrapada ---\n"); 140 e.printStackTrace(); 141 System.out.println(""); 142 } 143 144 } 145 146 147 /** 148 * Método llamado desde onEvent cuando el terminal de un paciente cambia de 149 * estado, realizando las acciones pertinentes. 150 * 151 */ 152 private void procesaEstado(){ 153 154 UserStatus estAct = null; 155 String sentencia_SQL; 156 Long MSISDNcuidador = null; 157 MensajeMultimedia mm = null; 158 159 for (int p = 0; p < estadoActual.length; p++){ 160 161 estAct = estadoActual[p]; 162 163 switch (estAct.getStatus()){ 164 165 case UserStatus.US_NOT_REACHABLE: 166 // si el evento es el terminal apagado, es porque antes tenía
que 167 // estar REACHABLE 168 169 try { 170 // busco el MSISDN de su cuidador 171 sentencia_SQL = "SELECT id_cuidador FROM
pacientes " + 172 "WHERE MSISDN='" +
estAct.getUser() +"'"; 173 174 ResultSet rs = BBDD.consulta(sentencia_SQL); 175 rs.next(); 176 177 sentencia_SQL = "SELECT MSISDN FROM
cuidadores " 178 + "WHERE id_cuidador='" + rs.getInt(1)
+"'"; 179 180 rs = BBDD.consulta(sentencia_SQL);
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 162
181 rs.next(); 182 183 MSISDNcuidador = rs.getLong(1); 184 185 } catch (SQLException e) { 186 // TODO Auto-generated catch block 187 System.out.println("\n--- SQLException atrapada ---
\n"); 188 e.printStackTrace(); 189 System.out.println(""); 190 } 191 192 // se prodede a enviar un MMS al cuidador del paciente 193 mm = new MensajeMultimedia(fwAdapter); 194 mm.establecerDirecciones(new
String[]{MSISDNcuidador.toString()}, 195 NumerosServicio.MSISDNcentral); 196 // se le pasa como parámetro el archivo de texto que contiene
la 197 // información a enviar y el MSISDN del paciente que ha
generado 198 // el evento 199 mm.enviarMensaje("avisoTerminalOff.txt",estAct.getUser()); 200 mm.cleanup(); 201 202 // cambio el estado del paciente a atendido 203 sentencia_SQL = "UPDATE estadopacloc SET estadoLoc='" 204 +Paciente.PacATENDIDO +"' WHERE MSISDN='"
+estAct.getUser() +"'"; 205 BBDD.actualiza(sentencia_SQL);
206 207 break; 208 209 case UserStatus.US_REACHABLE: 210 211 try { 212 // busco el MSISDN de su cuidador 213 sentencia_SQL = "SELECT id_cuidador FROM
pacientes " + 214 "WHERE MSISDN='" +
estAct.getUser() +"'"; 215 216 ResultSet rs = BBDD.consulta(sentencia_SQL); 217 rs.next(); 218 219 sentencia_SQL = "SELECT MSISDN FROM
cuidadores " 220 + "WHERE id_cuidador='" + rs.getInt(1)
+"'"; 221 222 rs = BBDD.consulta(sentencia_SQL); 223 rs.next(); 224
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 163
225 MSISDNcuidador = rs.getLong(1); 226 227 } catch (SQLException e) { 228 // TODO Auto-generated catch block 229 System.out.println("\n--- SQLException atrapada ---
\n"); 230 e.printStackTrace(); 231 System.out.println(""); 232 } 233 234 // se prodede a enviar un SMS al cuidador del paciente 235 mm = new MensajeMultimedia(fwAdapter); 236 mm.establecerDirecciones(new
String[]{MSISDNcuidador.toString()}, 237 NumerosServicio.MSISDNcentral); 238 // se le pasa como parámetro el archivo de texto que contiene
la 239 // información a enviar y el MSISDN del paciente que ha
generado 240 // el evento 241 mm.enviarMensaje("avisoTerminalOn.txt",estAct.getUser()); 242 mm.cleanup(); 243 244 // cambio el estado del paciente a normal 245 sentencia_SQL = "UPDATE estadopacloc SET estadoLoc='" 246 + Paciente.PacNORMAL + "' WHERE MSISDN='" 247 + estAct.getUser() + "'"; 248 BBDD.actualiza(sentencia_SQL); 249 250 break; 251 252 default: 253 System.out.println("Estado no reconocido: " +
estAct.getUser() + "."); 254 255 } 256 257 } 258 259 } 260 261 //=================================================== 262 // Implementacion de la interfaz UserStatusListener 263 //=================================================== 264 265 /** 266 * Método llamado por las Convenience Classes cuando se produce alguno de los 267 * eventos programados por la aplicación. 268 * 269 * @param usEvent - El evento UserStatus que se acaba de producir. 270 */ 271 public void onEvent(UserStatusEvent usEvent) { 272 // TODO Auto-generated method stub 273
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 164
274 System.out.println("En método onEvent() del Listener de Estado de Usuario."); 275 276 estadoActual = usEvent.getUserStatusList(); 277 278 procesaEstado(); 279 } 280 281 /** 282 * No se usa. 283 */ 284 public void onError(UserStatusError usError) { 285 // TODO Auto-generated method stub 286 287 } 288 }
2.4 Paquete Localizacion 2.4.1 LocalizacionUsuario.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * LocalizacionUsuario.java 5 */ 6 7 package Localizacion; 8 9 import java.sql.ResultSet; 10 import java.sql.SQLException; 11 12 import BaseDeDatos.BBDD; 13 import Gestion.GestionAlarmas; 14 import Gestion.GestionAmbulancias; 15 import Gestion.Script; 16 import MensajeriaMultimedia.MensajeMultimedia; 17 import TipoDatos.Alarma; 18 import TipoDatos.NumerosServicio; 19 import TipoDatos.Paciente; 20 21 import com.lucent.isg.appsdk.framework.FrameworkAdapter; 22 import com.lucent.isg.appsdk.framework.FrameworkException; 23 import com.lucent.isg.appsdk.userlocation.UserLocation; 24 import com.lucent.isg.appsdk.userlocation.UserLocationAdapter; 25 import com.lucent.isg.appsdk.userlocation.UserLocationError; 26 import com.lucent.isg.appsdk.userlocation.UserLocationException; 27 28 /** 29 * Clase que engloba todo lo relacionado con el servicio de localización de los 30 * pacientes. Crea un hilo que es el encargado de comprobar sus posiciones y define 31 * métodos para tratar las alarmas correspondientes así como la respuestas de los
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 165
32 * cuidadores. 33 * 34 * @author Raúl Parras Eliche 35 * 36 */ 37 public class LocalizacionUsuario { 38 39 /** 40 * Tiempo que dormimos el hilo entre comprobación y comprobación de la posición 41 * de los pacientes 42 */ 43 public static final int TIEMPO_DORMIDO_LOC = 30; 44 45 /** 46 * Adaptador del servicio de localización. 47 */ 48 private UserLocationAdapter ulAdapter = null; 49 50 /** 51 * Variable que sirve para detener la ejución del hilo hasta que la respuesta del 52 * cuidador asociado al paciente que ha generado la alarma está lista. 53 */ 54 public static boolean stopLoc = true; 55 56 /** 57 * Variable donde se almacena la respuesta del cuidador asociado a un paciente 58 * que ha generado una alarma de localización. 59 */ 60 public static int RespCuidLoc; 61 62 /** 63 * Variable que almacena el MSISDN del cuidador asociado al paciente cuya 64 * alarma se está tratando. 65 */ 66 public static long MSISDNcuidAlarma; 67 68 69 /** 70 * Constructor de la clase LocalizacionUsuario. Inicia el adaptador de servicio para 71 * la localización de los usuarios. 72 * 73 * @param fwAdapter - FrameworkAdapter del servicio de tele asistencia, necesario 74 * para obtener el resto de adaptadores. 75 */ 76 public LocalizacionUsuario(FrameworkAdapter fwAdapter){ 77 78 try { 79 ulAdapter = fwAdapter.selectUserLocationService(); 80 81 } catch (FrameworkException e) { 82 // TODO Auto-generated catch block 83 e.printStackTrace(); 84 } 85
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 166
86 System.out.println("Token del Servicio de Localización: " 87 + ulAdapter.getServiceToken()); 88 System.out.println(""); 89 90 } 91 92 93 /** 94 * Método que termina el adaptador de servicio para localización. 95 * 96 * @throws UserLocationException 97 * de servicio. 98 */ 99 public void cleanup() throws UserLocationException { 100 101 if (ulAdapter != null){ 102 103 ulAdapter.destroy(); 104 } 105 106 } 107 108 /** 109 * Método que imprime por pantalla un array de localizaciones. 110 * 111 * @param locations - Array de posiciones que se va a imprimir. 112 */ 113 public static void imprimeLocalizacion(UserLocation[] locations){ 114 115 for (int i= 0; i<locations.length; i++){ 116 117 UserLocation loc = locations[i]; 118 System.out.print("userid: " +loc.getUser()); 119 120 UserLocationError error =loc.getError(); 121 if (error!=null){ 122 System.out.println(", error: " +error.toString()); 123 }else{ 124 System.out.print(", longitude: " +loc.getLongitude()); 125 System.out.println(", latitude: " +loc.getLatitude()); 126 } 127 } 128 } 129 130 131 /** 132 * Método que inicia el servicio de localización. Para ello crea un hilo específico, 133 * que será el encargado de comprobar periódicamente las posiciones de los 134 * pacientes. 135 * 136 */ 137 public void invocaUL() { 138 139 HiloLoc hiloLoc = new HiloLoc(ulAdapter);
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 167
140 hiloLoc.start(); 141 } 142 143 144 /** 145 * Método que procesa las posiciones de los pacientes buscando algún tipo de anomalía. 146 * Si la encuentra, crea una nueva alarma. 147 * 148 * @param locations - Array de posiciones que se comprobarán comparándolos con los 149 * de referencia que se possen de los pacientes. 150 * 151 * @throws SQLException 152 */ 153 public static void procesaPosiciones(UserLocation[] locations) throws SQLException{ 154 155 System.out.println(""); 156 157 String sentencia_SQL; 158 159 // calculamos la distancia ahora 160 161 for (int i= 0; i < locations.length; i++){ 162 163 int alarma; 164 long MSISDN; 165 double distancia; 166 int estadoPac; 167 168 ResultSet rs; 169 170 UserLocation loc_ref; 171 locations[i].getError(); 172 173 System.out.println(""); 174 System.out.println("userid: " +locations[i].getUser()); 175 176 if (locations[i].getError()!=null){ 177 178 System.out.println(", error: " +
locations[i].getError().toString()); 179 }else{ 180 // obtengo la latitud y la longitud de referencia de cada
paciente 181 // utilizo MSISDN para buscarlas porque antes ya he
asociado 182 // los MSISDN a los dni 183 sentencia_SQL = "SELECT longitud,latitud FROM pacientes "
+ 184 "WHERE MSISDN='" +
locations[i].getUser() +"'"; 185 rs = BBDD.consulta(sentencia_SQL); 186 187 rs.next(); 188 loc_ref = new UserLocation
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 168
(rs.getDouble(1),rs.getDouble(2)); 189 190 // calculo la distancia entre ambas posiciones 191 distancia = locations[i].distanceTo(loc_ref); 192 193 System.out.println("Distancia del paciente = " 194 + locations[i].getUser() + 195 " con respecto a su posicion de
referencia: " 196 + distancia +" km."); 197 198 // supongo un radio de seguridad de 1 km 199 if (distancia < 1){ 200 201 System.out.println("No hay necesidad de generar
una " + 202 "alarma para este " +
"paciente."); 203 System.out.println(""); 204 205 }else{ 206 207 alarma = Alarma.PERSONA_PERDIDA; 208 MSISDN =
Long.valueOf(locations[i].getUser()).longValue(); 209 210 sentencia_SQL = "SELECT estadoLoc FROM
estadopacloc " + 211 "WHERE MSISDN='" + MSISDN
+ "'"; 212 rs = BBDD.consulta(sentencia_SQL); 213 rs.next(); 214 estadoPac = rs.getInt(1); 215 216 // comprobamos primero que la alarma no se haya
generado ya y que el 217 // estado del paciente sea normal (no atendido)
antes de crear la 218 // alarma 219 if
((!GestionAlarmas.compruebaAlarmaCreada(alarma, MSISDN)) && 220 (estadoPac ==
Paciente.PacNORMAL)){ 221 222 System.out.println("El paciente ha
excedido el radio de seguridad de 1 km." 223 + "Se procederá a la
creación de la alarma correspondiente."); 224 System.out.println(""); 225 226 Alarma a = new Alarma(alarma,
MSISDN); 227 228 GestionAlarmas.anadeAlarma(a);
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 169
229 230 } 231 232 } 233 } 234 } 235 } 236 237 /** 238 * Método encargado de procesar las alarmas generadas por una posición incorrecta 239 * del paciente. 240 * 241 * @param alarma - Objeto alarma que se va a tratar. 242 * @param script - Clase para cargar y ejecutar programas en el simulador. 243 * @param fwAdapter - FrameworkAdapter del servicio de tele asistencia, necesario 244 * para obtener el resto de adaptadores. 245 */ 246 public void procesaAlarmaLoc(Alarma alarma, Script script, 247 FrameworkAdapter fwAdapter){ 248 249 System.out.print ("Procesando alarma.......ORIGEN: "); 250 System.out.print("usuario " + alarma.MSISDN +", tipo " +alarma.id_alarma); 251 System.out.println("........................"); 252 253 // primero vamos a comprobar cúal es la posición del cuidador que 254 // esté a cargo del paciente que ha generado la alarma; 255 // es decir, si están juntos (distancia entre ambos menor a 20 256 // metros), no hay ningúm problema. 257 // Para ello, necesito hallar primero al cuidador y después su MSISDN 258 259 String sentencia_SQL = "SELECT id_cuidador FROM pacientes WHERE
MSISDN='" 260 + alarma.MSISDN +"'"; 261 262 263 try { 264 265 ResultSet rs = BBDD.consulta(sentencia_SQL); 266 rs.next(); 267 268 sentencia_SQL = "SELECT MSISDN,nombre,apellido1,apellido2
FROM " + 269 "cuidadores " + "WHERE id_cuidador='" +
rs.getInt(1) +"'"; 270 rs = BBDD.consulta(sentencia_SQL); 271 rs.next(); 272 273 MSISDNcuidAlarma = rs.getLong(1); 274 Long MSISDNpaciente = alarma.MSISDN; 275 276 System.out.println("Los datos del cuidador asociado al paciente son: "); 277 System.out.println(" MSISDN -->> " + MSISDNcuidAlarma); 278 System.out.println(" Nombre -->> " + rs.getString(2)); 279 System.out.println(" Apellido 1 -->> " + rs.getString(3));
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 170
280 System.out.println(" Apellido 2 -->> " + rs.getString(4)); 281 282 283 // calculo ahora la posicion del cuidador y la del paciente, para poder 284 // calcular la distancia entre ambos 285 Long MSISDNcuidador = MSISDNcuidAlarma; 286 String[] ULcuidador =
{MSISDNcuidador.toString(),MSISDNpaciente.toString()}; 287 UserLocation[] LOCcuid; 288 289 290 LOCcuid = ulAdapter.requestLocation(ULcuidador); 291 LocalizacionUsuario.imprimeLocalizacion(LOCcuid); 292 293 // la distancia entre ambos es una cantidad en km 294 double distanciaKM = LOCcuid[0].distanceTo(LOCcuid[1]); 295 long distanciaM = (long)(distanciaKM * 1000); 296 System.out.println("Distancia entre paciente y cuidador: " 297 + distanciaM +" m."); 298 299 if (distanciaM <= 20){ 300 301 System.out.println("Suponemos que el paciente se " + 302 "encuentra con su cuidador."); 303 System.out.println("Se le enviará un MMS avisándole."); 304 305 MensajeMultimedia mm = new
MensajeMultimedia(fwAdapter); 306 mm.establecerDirecciones(new
String[]{MSISDNcuidador.toString()}, 307 NumerosServicio.MSISDNcentral); 308 // se le pasa como parámetro el archivo de texto que contiene
la 309 // información a enviar 310 mm.enviarMensaje("avisoAlarma.txt",
MSISDNpaciente.toString()); 311 mm.cleanup(); 312 313 // cambio el estado del paciente a atendido 314 sentencia_SQL = "UPDATE estadopacloc SET estadoLoc='" 315 + Paciente.PacATENDIDO + "' WHERE MSISDN='"
+ alarma.MSISDN + "'"; 316 BBDD.actualiza(sentencia_SQL); 317 318 319 }else{ 320 321 String programa = "LLamada_Central_" + MSISDNcuidador; 322 int contLLamadas = 1; 323 script.ejecutaPrograma(programa, true); 324 325 procesaRespCuid(alarma, ulAdapter, script, LOCcuid[1],
contLLamadas, 326 MSISDNcuidador, fwAdapter);
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 171
327 328 } 329 330 } catch (UserLocationException e1) { 331 // TODO Auto-generated catch block 332 System.out.println("\n--- UserLocationException caught ---\n"); 333 e1.printStackTrace(); 334 335 } catch (SQLException e) { 336 // TODO Auto-generated catch block 337 e.printStackTrace(); 338 } 339 340 // eliminamos la alarma 341 GestionAlarmas.eliminaAlarma(alarma); 342 343 } 344 345 346 /** 347 * Método que procesa la respuesta del cuidador encargado del paciente que ha 348 * generado la alarma por localización. 349 * 350 * @param alarma - Objeto alarma que se está tratando. 351 * @param ulAdapter - Adaptador del servicio de localización. 352 * @param script - Clase para cargar y ejecutar programas en el simulador. 353 * @param locPac - Posición del paciente que ha causado la alarma. 354 * @param contLLamadas - Intentos de llamadas al cuidador sin éxito. 355 * @param MSISDNcuidador - Número del terminal del cuidador asociado al paciente que 356 * ha generado la alarma. 357 * @param fwAdapter - FrameworkAdapter del servicio de tele asistencia, necesario 358 * para obtener el resto de adaptadores. 359 */ 360 private static void procesaRespCuid(Alarma alarma, UserLocationAdapter ulAdapter, 361 Script script, UserLocation locPac, int contLLamadas, Long
MSISDNcuidador, 362 FrameworkAdapter fwAdapter){ 363 364 String sentencia_SQL = null; 365 String programa = null; 366 String MSISDNamb = null; 367 368 // bucle que nos sirve para dormir el hilo hasta que tengamos lista la respuesta 369 // del cuidador 370 while (stopLoc){ 371 372 try { 373 Thread.sleep(5000); 374 } catch (InterruptedException e) { 375 // TODO Auto-generated catch block 376 e.printStackTrace(); 377 } 378 } 379 stopLoc = true;
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 172
380 381 // compruebo cual ha sido la respuesta del cuidador y realizo las 382 // acciones correspondientes 383 384 switch(RespCuidLoc){ 385 386 case GestionAlarmas.ATENDIDO: // cambio el estado del paciente 387 388 sentencia_SQL = "UPDATE estadopacloc SET estadoLoc='" 389 + Paciente.PacATENDIDO + "' WHERE MSISDN='" +
alarma.MSISDN + "'"; 390 BBDD.actualiza(sentencia_SQL); 391 392 break; 393 394 case GestionAlarmas.DESCONOCIDO: 395 // llamo a la ambulancia más cercana al paciente 396 397 MSISDNamb = GestionAmbulancias.ambulanciaMasCercana(locPac, 398 ulAdapter,fwAdapter); 399 400 if (MSISDNamb != null){ 401 402 programa = "LLamada_Central_" + MSISDNamb; 403 script.ejecutaPrograma(programa, false); 404 405 // y modifico el estado del paciente para que no siga
generando la 406 // misma alarma 407 sentencia_SQL = "UPDATE estadopacloc SET estadoLoc='" 408 + Paciente.PacATENDIDO + "' WHERE MSISDN='"
+ alarma.MSISDN + "'"; 409 BBDD.actualiza(sentencia_SQL); 410 } 411 412 break; 413 414 default: 415 // se engloban aquí los casos de error de marcado del cuidador 416 // y de expiración del tiempo 417 if (contLLamadas < 2){ 418 419 programa = "LLamada_Central_" + MSISDNcuidador; 420 contLLamadas ++; 421 script.ejecutaPrograma(programa, true); 422 procesaRespCuid(alarma, ulAdapter, script, locPac, 423 contLLamadas,
MSISDNcuidador,fwAdapter); 424 425 } else { 426 // si ya hemos llamado dos veces al cuidador sin éxito,
llamamos a la 427 // ambulancia más cercana 428 System.out.println("Se ha llamado al cuidador 2 veces sin
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 173
éxito."); 429 System.out.println("Se procederá a llamar a la ambulancia
más cercana."); 430 MSISDNamb =
GestionAmbulancias.ambulanciaMasCercana(locPac, 431 ulAdapter,fwAdapter); 432 433 if (MSISDNamb != null){ 434 435 programa = "LLamada_Central_" + MSISDNamb; 436 script.ejecutaPrograma(programa, false); 437 438 // y modificamos el estado del paciente para que no
siga 439 // generando la misma alarma 440 sentencia_SQL = "UPDATE estadopacloc SET
estadoLoc='" 441 + Paciente.PacATENDIDO + "' WHERE
MSISDN='" 442 + alarma.MSISDN + "'"; 443 BBDD.actualiza(sentencia_SQL); 444 445 } 446 } 447 } 448 } 449 450 }
2.4.2 HiloLoc.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * HiloLoc.java 5 */ 6 7 package Localizacion; 8 9 import java.sql.SQLException; 10 11 import Gestion.GestionPacientes; 12 import TipoDatos.Alarma; 13 14 import com.lucent.isg.appsdk.userlocation.UserLocation; 15 import com.lucent.isg.appsdk.userlocation.UserLocationAdapter; 16 import com.lucent.isg.appsdk.userlocation.UserLocationException; 17 18 /** 19 * Clase que implementa un nuevo hilo para el servicio de localización. 20 * Se encargará de comprobar periódicamente las posiciones de los pacientes. 21 * 22 * @author Raúl Parras Eliche
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 174
23 */ 24 public class HiloLoc extends Thread { 25 26 /** 27 * Variable para poder parar el hilo (con valor false). 28 */ 29 private boolean continuar = true; 30 31 /** 32 * Adaptador del servicio de localización. 33 */ 34 private UserLocationAdapter ulAdapter; 35 36 /** 37 * Método para detener este hilo. 38 */ 39 public void detenerHilo(){ 40 41 continuar = false; 42 } 43 44 45 /** 46 * Construye un objeto de la clase HiloLoc. Realiza una copia del adaptador 47 * UserLocation que recibe como parámetro. 48 * 49 * @param ulAdapter - Adaptador del servicio de localización. 50 */ 51 public HiloLoc (UserLocationAdapter ulAdapter){ 52 53 this.ulAdapter = ulAdapter; 54 55 } 56 57 58 /** 59 * Definimos el método run() similar al main() pero para Hilos. 60 * 61 */ 62 public void run(){ 63 64 // creo un array de string con todos los MSISDN de los pacientes que tienen 65 // este servicio contratado 66 67 GestionPacientes g_p = new GestionPacientes(); 68 String[] UL_abonados = g_p.listado_MSISDN(Alarma.PERSONA_PERDIDA); 69 70 // obtengo la posicion de los abonados 71 UserLocation[] locations; 72 try { 73 74 locations = ulAdapter.requestLocation(UL_abonados); 75 LocalizacionUsuario.imprimeLocalizacion(locations); 76
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 175
77 } catch (UserLocationException e1) { 78 // TODO Auto-generated catch block 79 System.out.println("\n--- UserLocationException caught ---\n"); 80 e1.printStackTrace(); 81 } 82 83 System.out.println(""); 84 85 while(continuar){ 86 87 try { 88 89 sleep(LocalizacionUsuario.TIEMPO_DORMIDO_LOC *
1000); 90 91 } catch (InterruptedException e) { 92 // TODO Auto-generated catch block 93 System.out.println("\n--- InterruptedException caught ---\n"); 94 e.printStackTrace(); 95 } 96 97 // obtenemos las nuevas posiciones de los pacientes 98 99 try { 100 101 locations = ulAdapter.requestLocation(UL_abonados); 102 LocalizacionUsuario.procesaPosiciones(locations); 103 104 } catch (UserLocationException e) { 105 // TODO Auto-generated catch block 106 System.out.println("\n--- UserLocationException caught ---\n"); 107 e.printStackTrace(); 108 109 } catch (SQLException e) { 110 // TODO Auto-generated catch block 111 System.out.println("\n--- SQLException caught ---\n"); 112 while (e != null) { 113 System.out.println("Message: " + e.getMessage
()); 114 System.out.println("SQLState: " + e.getSQLState
()); 115 System.out.println("ErrorCode: " + e.getErrorCode
()); 116 e = e.getNextException(); 117 System.out.println(""); 118 } 119 120 } 121 122 } 123 124 } 125 }
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 176
2.5 Paquete InteraccionUsuario 2.5.1 InteraccionUsuarioLoc.java
1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * InteraccionUsuarioLoc.java 5 */ 6 7 package InteraccionUsuario; 8 9 import Gestion.GestionAlarmas; 10 import Localizacion.LocalizacionUsuario; 11 import TipoDatos.NumerosServicio; 12 13 import com.lucent.isg.appsdk.callcontrol.*; 14 import com.lucent.isg.appsdk.framework.*; 15 import com.lucent.isg.appsdk.userinteraction.*; 16 17 /** 18 * Clase que engloba todo lo relacionado con la captura de las llamadas, pues 19 * implementa la interfaz CallControlListener, y establece la interacción con 20 * los usuarios. Establece los criterios de captura y define métodos para tratar 21 * la información asociada ha dicha interacción. 22 * 23 * @author Raúl Parras Eliche 24 * 25 */ 26 27 public class InteraccionUsuarioLoc implements CallControlListener { 28 29 private CallControlAdapter ccAdapter = null; 30 private UserInteractionAdapter uiAdapter = null; 31 32 33 // objeto de interaccion de usuario de llamada 34 private UICall uiCall = null; 35 36 // parámetros de la monitorización de las llamadas 37 // las direcciones origen y destino están cambiadas porque el simulador sólo permite 38 // que la interaccion con el usuario se produzca en el sentido del llamante, así que 39 // para que el cuidador oiga el menú cuando se produzca la alarma, tengo que forzar a 40 // que sea él el que llame a la central, en vez de la central a él, como se haría en 41 // la realidad 42 43 private String direccionOrigen = "*"; 44 private String direccionDestino = NumerosServicio.MSISDNcentral; 45 private int mascara = Event.ADDRESS_ANALYSED; 46 private boolean originatorEvents = false; 47 private boolean modoInterrupcion = true; 48 49 // identificadores de los mensajes a enviar (se corresponden con los del script
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 177
50 // teleasistencia.xml) 51 private static final int ID_MENU = 1; 52 private static final int ID_GRACIAS = 2; 53 private static final int ID_INCORRECTO = 3; 54 //private static final int ID_TARDE = 4; 55 56 // valor devuelto al habilitar la notificación de llamadas 57 private int assignmentId; 58 59 60 /** 61 * Constructor de la clase InteraccionUsuario. Inicializa los adaptadores para los 62 * servicios de control de llamada e interacción con el usuario. 63 * 64 * @param fwAdapter - FrameworkAdapter del servicio de tele asistencia, necesario 65 * para obtener el resto de adaptadores. 66 */ 67 public InteraccionUsuarioLoc(FrameworkAdapter fwAdapter){ 68 69 // Creo los adaptadores de servicio 70 try { 71 72 ccAdapter = fwAdapter.selectCallControlService(); 73 uiAdapter = fwAdapter.selectUserInteractionService(); 74 System.out.println("Token de servicio de Interaccion de Usuario: " 75 + uiAdapter.getServiceToken() +"\n"); 76 77 } catch (FrameworkException e) { 78 // TODO Auto-generated catch block 79 e.printStackTrace(); 80 } 81 } 82 83 /** 84 * Método que establece los criterios para la escucha de llamadas y lanza la 85 * monitorización de las mismas. 86 * 87 */ 88 public void MonitorizaLLamadaLoc(){ 89 90 91 // creo el objeto call criteria necesario para la monitorizacion de las llamadas 92 CallCriteria criterio = new CallCriteria(direccionOrigen,direccionDestino, 93 mascara,originatorEvents,modoInterrupcion); 94 95 try { 96 assignmentId = ccAdapter.enableCallNotification(criterio, this); 97 } catch (CallControlException e) { 98 // TODO Auto-generated catch block 99 e.printStackTrace(); 100 } 101 102 } 103
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 178
104 105 /** 106 * Método que envía a través de la llamada que ha sido capturada un menú para 107 * que el cuidador responda. 108 * 109 * @param call - Objeto llamada capturado. 110 */ 111 private void enviarMenuAlarmaLoc(Call call){ 112 113 114 // obtengo el objeto de interaccion de usuario de la llamada 115 try { 116 uiCall = uiAdapter.createUICall(call); 117 } catch (UserInteractionException e1) { 118 // TODO Auto-generated catch block 119 e1.printStackTrace(); 120 } 121 122 // especifico el mensaje a enviar 123 SendInfoCriteria sic = new SendInfoCriteria(ID_MENU); 124 125 // espero un único número de respuesta (valor de tiempo de 5 segundos) 126 CollectCriteria cc = new CollectCriteria(1,1,null,5000,3000); 127 128 // se reproduce el menú y se espera la respuesta del usuario 129 UIReport uiReport = null; 130 131 try { 132 133 uiReport = uiCall.sendInfoAndCollect(sic, cc); 134 135 136 } catch (UserInteractionException e1) { 137 // TODO Auto-generated catch block 138 System.out.println("UserInteractionException atrapada."); 139 System.out.println("Error: " + e1.getReportError()); 140 141 uiReport = new UIReport (UIReport.REPORT_TIMEOUT); 142 143 } finally{ 144 145 System.out.println("Menú enviado. Respuesta: " +uiReport); 146 147 // tratamiento de la respuesta del cuidador 148 tratarRespCuid(uiReport); 149 150 } 151 152 // termino la interaccion con el usuario en esta llamada y termino 153 // la llamada 154 155 try { 156 157 uiCall.release();
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 179
158 call.release(); 159 160 } catch (UserInteractionException e1) { 161 // TODO Auto-generated catch block 162 e1.printStackTrace(); 163 } catch (CallControlException e) { 164 // TODO Auto-generated catch block 165 e.printStackTrace(); 166 } 167 } 168 169 170 /** 171 * Método que trata la respuesta del cuidador. 172 * 173 * @param respuesta - Respuesta obtenida de la interacción con el usuario. 174 */ 175 private void tratarRespCuid(UIReport respuesta){ 176 177 SendInfoCriteria sic = null; 178 179 // si se entra en el siguiente if es que el cuidador ha introducido algún dato 180 if (respuesta.getReportType() == UIReport.REPORT_INFO_COLLECTED){ 181 182 // resupero el digito introducido por el cuidador 183 String digito = respuesta.getCollectedInfo(); 184 185 if(digito != null && digito.equals("1")){ 186 187 LocalizacionUsuario.RespCuidLoc =
GestionAlarmas.ATENDIDO; 188 189 sic = new SendInfoCriteria(ID_GRACIAS); 190 191 } else if( digito != null && digito.equals("2")){ 192 193 LocalizacionUsuario.RespCuidLoc =
GestionAlarmas.DESCONOCIDO; 194 195 sic = new SendInfoCriteria(ID_GRACIAS); 196 197 } else { 198 199 System.out.println("La información introducida por el cuidador
no " + 200 "es correcta."); 201 LocalizacionUsuario.RespCuidLoc =
GestionAlarmas.ERROR; 202 203 sic = new SendInfoCriteria (ID_INCORRECTO); 204 } 205 206 // si se entra aquí es que el tiempo del cuidador para introducir datos expiró 207 } else if(respuesta.getReportType() == UIReport.REPORT_TIMEOUT){
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 180
208 209 System.out.println("El cuidador no ha pulsado nada o tardado
demasiado."); 210 LocalizacionUsuario.RespCuidLoc = GestionAlarmas.TIMEOUT; 211 212 213 214 } else { 215 216 System.out.println("UIReport no válido, tipo: " +
respuesta.getReportType()); 217 } 218 219 if (sic != null){ 220 221 try { 222 uiCall.sendInfo(sic); 223 224 } catch (UserInteractionException e) { 225 // TODO Auto-generated catch block 226 e.printStackTrace(); 227 } 228 } 229 230 LocalizacionUsuario.stopLoc = false; 231 232 } 233 234 /** 235 * Método que elimina los adaptadores de servicio. 236 */ 237 public void cleanup(){ 238 239 try { 240 241 if (uiAdapter != null){ 242 243 uiAdapter.destroy(); 244 } 245 246 if (ccAdapter != null){ 247 248 ccAdapter.destroy(); 249 } 250 251 } catch (UserInteractionException e) { 252 // TODO Auto-generated catch block 253 System.out.println("\n--- UserInteractionException atrapada ---\n"); 254 e.printStackTrace(); 255 System.out.println(""); 256 } catch (CallControlException e) { 257 // TODO Auto-generated catch block 258 System.out.println("\n--- CallControlException atrapada ---\n"); 259 e.printStackTrace();
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 181
260 System.out.println(""); 261 } 262 263 264 } 265 266 /** 267 * Método que deshabilita la monitorización de llamadas. 268 * 269 * @return resultado 270 */ 271 public boolean paraMonitorizacionLLamada(){ 272 273 boolean resultado = false; 274 275 try { 276 resultado = ccAdapter.disableCallNotification(assignmentId); 277 } catch (CallControlException e) { 278 // TODO Auto-generated catch block 279 e.printStackTrace(); 280 } 281 282 return resultado; 283 } 284 285 286 //=================================================== 287 // Implementacion de la interfaz CallControlListener 288 //=================================================== 289 290 /** 291 * Método llamado por las Convenience Classes cuando se produce alguno de los 292 * eventos programados por la aplicación. 293 * 294 * @param ccEvent - El evento CallCOntrol que se acaba de producir. 295 */ 296 public void onEvent(CallControlEvent ccEvent) { 297 // TODO Auto-generated method stub 298 299 Call call = ccEvent.getCall(); 300 String MSISDNcuidador = call.getOriginatorAddress(); 301 Long MSISDNcuid = LocalizacionUsuario.MSISDNcuidAlarma; 302 303 if (MSISDNcuidador.equalsIgnoreCase(MSISDNcuid.toString())) { 304 305 System.out.println("En método onEvent() de InteraccionUsuario."); 306 System.out.println("Evento capturado en CallControlListener:" 307 + ccEvent.getCallEvent()); 308 309 switch (ccEvent.getCallEvent()) { 310 311 case Event.ADDRESS_ANALYSED: 312 313 enviarMenuAlarmaLoc(call);
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 182
314 break; 315 316 default: 317 System.out.println("onEvent(): event call capturado no válido:" 318 + ccEvent); 319 320 } 321 } else { 322 323 try { 324 // si un cuidador o quien sea realiza una llamada a la central
se 325 // desvía la llamada a una operadora para que lo atienda 326 call.routeRequest(NumerosServicio.MSISDNoperadora, 0, 0); 327 328 // la aplicación se desentiende de la llamada; ésta seguirá
activa 329 // hasta que una de las dos partes cuelgue 330 call.deassign(); 331 332 } catch (CallControlException e) { 333 // TODO Auto-generated catch block 334 e.printStackTrace(); 335 } 336 } 337 } 338 339 /** 340 * No se usa. 341 */ 342 public void onError(CallControlError arg0) { 343 // TODO Auto-generated method stub 344 System.out.println("En método onError() de InteraccionUsuarioLoc."); 345 } 346 }
2.6 Paquete MensajeriaMultimedia 2.6.1 MensajeMultimedia.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * MensajeMultimedia.java
5 */ 6 7 package MensajeriaMultimedia;
8 9 import com.lucent.isg.appsdk.mmm.*;
10 import com.lucent.isg.appsdk.framework.*;
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 183
11 12 import java.io.*;
13 14 /** 15 * Clase que ofrece la funcionalidad de enviar un MMS (indicando el fichero de
16 * texto que contiene la información) especificando desde que terminal y a cual.
17 * 18 * @author Raúl Parras Eliche
19 * 20 */ 21 public class MensajeMultimedia {
22 23 private MMMAdapter mmmAdapter = null ;
24 private MMMSession mmmSession = null;
25 private String receptores[];
26 private String emisor;
27
28
29 /**
30 * Constructor de la clase. Crea los adaptadores de servicio necesario para enviar
31 * un mensaje multimedia (MMMAdapter y MMMSession).
32 *
33 * @param fwAdapter - FrameworkAdapter del servicio de tele asistencia, necesario
34 * para obtener el resto de adaptadores.
35 */
36 public MensajeMultimedia(FrameworkAdapter fwAdapter){
37
38 // Creo el adaptador de servicio
39 try {
40
41 mmmAdapter = fwAdapter.selectMMMService();
42
43 System.out.println("Token de servicio de Mensajería Multimedia: "
44 + mmmAdapter.getServiceToken() +"\n");
45
46 } catch (FrameworkException e) {
47 // TODO Auto-generated catch block
48 System.out.println("\n--- FrameworkException atrapada ---\n");
49 e.printStackTrace();
50 System.out.println("");
51 }
52 }
53
54
55 /**
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 184
56 * Método que establece las direcciones origen y destino del MMS.
57 *
58 * @param receptores - Lista de direcciones destino para el MMS.
59 * @param emisor - Número que envía el MMS.
60 */
61 public void establecerDirecciones(String[] receptores, String emisor){
62
63 this.receptores = receptores;
64 this.emisor = emisor;
65
66 }
67
68
69 /**
70 * Método que envía en el MMS el contenido del archivo de texto que se le pasa
71 * como parámetro. Dicho archivo de texto debe estar en el directorio etc de la
72 * instalación de MiLiFE ISG SDK.
73 *
74 * @param archivo - nombre del fichero que contiene la información ha enviar en
75 * el MMS.
76 */
77 public void enviarMensaje(String archivo, String MSISDNpaciente){
78
79 try {
80 // creao una sesión multimedia
81 mmmSession = mmmAdapter.openMMMSession(receptores, emisor);
82
83 MMMMessageTreatment treatment[] = new MMMMessageTreatment[1];
84 treatment[0] = new MMMMessageTreatment();
85
86 File inputFile;
87 DataInputStream miDStream;
88 FileInputStream miFStream;
89
90 String home = "C:/Program Files/LT/ISG SDK/etc/" + archivo;
91 inputFile = new File(home);
92 miFStream = new FileInputStream(inputFile);
93 miDStream = new DataInputStream (miFStream);
94
95
96 // copio en un primer array de bytes la información del fichero de texto
97 // correspondiente
98 byte[] mensaje1 = new byte[(int)inputFile.length()];
99
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 185
100 for (int j=0; j<(int)inputFile.length();j++){
101 mensaje1[j] = miDStream.readByte();
102 }
103
104 // copio en un segundo array el MSISDN del paciente, por si el cuidador
105 // tiene a su cargo más de un paciente
106 byte[] mensaje2 = MSISDNpaciente.getBytes();
107
108 // uno los dos arrays de byte en uno sólo, que es el que se va a enviar
109 // por SMS
110 int longitud = (mensaje1.length + mensaje2.length);
111 byte[] mensaje3 = new byte[longitud];
112
113 for (int p = 0; p < mensaje1.length; p ++){
114
115 mensaje3[p] = mensaje1[p];
116 }
117
118 for(int r = mensaje1.length; r < longitud; r++){
119
120 mensaje3[r] = mensaje2[r-mensaje1.length];
121
122 }
123
124 mmmSession.sendMessage(emisor, receptores, MMMDeliverType.SMS,
125 new MMMMessageTreatment[0], mensaje3,
126 new org.csapi.mmm.TpMessageHeaderField[0]);
127
128 System.out.print("Mensaje enviado a: " );
129 for (int i=0; i < receptores.length; i++){
130
131 System.out.println(receptores[i]);
132 System.out.print(" ");
133 }
134
135 System.out.println("");
136
137 // cierro la sesión multimedia
138 mmmSession.close();
139 } catch (MMMException e) {
140 // TODO Auto-generated catch block
141 System.out.println("\n--- MMMException atrapada ---\n");
142 e.printStackTrace();
143 System.out.println("");
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 186
144 } catch (FileNotFoundException e) {
145 // TODO Auto-generated catch block
146 e.printStackTrace();
147 } catch (IOException e) {
148 // TODO Auto-generated catch block
149 e.printStackTrace();
150 }
151 }
152
153 /**
154 * Método que elimina el adaptador de servicio MMMessaging.
155 */ 156 public void cleanup(){
157
158 try {
159
160 if (mmmAdapter != null){
161
162 mmmAdapter.destroy();
163 }
164 } catch (MMMException e) {
165 // TODO Auto-generated catch block
166 e.printStackTrace();
167 }
168 }
169 }
2.6.2 MensajeMultimediaLis.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * MensajeMultimediaLis.java 5 */ 6 7 package MensajeriaMultimedia; 8 9 import BaseDeDatos.BBDD; 10 import Gestion.GestionAlarmas; 11 import Gestion.GestionPacientes; 12 import TipoDatos.Alarma; 13 import TipoDatos.NumerosServicio; 14 import TipoDatos.Paciente; 15 16 import com.lucent.isg.appsdk.framework.*; 17 import com.lucent.isg.appsdk.mmm.*; 18
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 187
19 import java.sql.ResultSet; 20 import java.sql.SQLException; 21 22 23 /** 24 * Clase que implementa la interfaz MMMListener. Es la encargada de capturar eventos 25 * (de la interfaz OSA/Parlay) relacionados con la recepción de MMS y define los 26 * métodos que procesan dichos eventos. 27 * 28 * @author Raúl Parras Eliche 29 * 30 */ 31 public class MensajeMultimediaLis implements MMMListener { 32 33 /** 34 * Adaptadores del servicio de Mensajería Multimedia. 35 */ 36 private MMMAdapter mmmAdapter; 37 private MMMSession mmmSession = null; 38 39 40 // se definen los receptores delos MMS que queremos que provoquen los eventos 41 private String receptorMMSalarmaCaida = NumerosServicio.MSISDNalarmaCaida; 42 private String receptorMMSCambioEstadoPaciente =
NumerosServicio.MSISDNcambioEstPac; 43 44 // origen de los MMS que queremos capturar 45 // para las alarmas por caída, los MMS sólo procederán de los pacientes 46 private String emisor1 = "150111111111"; 47 private String emisor2 = "150222222222"; 48 private String emisor3 = "150333333333"; 49 private String emisor4 = "150444444444"; 50 // para los cambios de estado de los pacientes, los MMS procederán de los cuidadores 51 private String emisor5 = "170111111111"; 52 private String emisor6 = "170222222222"; 53 private String emisor7 = "170333333333"; 54 55 /** 56 * Constructor de la clase MensajeMultimediaLis. Utiliza el FrameworkAdapter 57 * para inicializar el adaptador de servicio necesario (MMMAdapter). 58 * 59 * @param fwAdapter - FrameworkAdapter del servicio de tele asistencia, necesario 60 * para obtener el resto de adaptadores. 61 */ 62 public MensajeMultimediaLis(FrameworkAdapter fwAdapter){ 63 64 // creo el adaptador del servicio 65 try { 66 67 System.out.println("En el constructor de la clase
MensajeMultimediaLis."); 68 69 mmmAdapter = fwAdapter.selectMMMService(); 70 System.out.println("Token de sericio de Mensajería Multimedia: "
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 188
71 + mmmAdapter.getServiceToken()); 72 73 } catch (FrameworkException e) { 74 // TODO Auto-generated catch block 75 e.printStackTrace(); 76 } 77 78 } 79 80 81 /** 82 * Método que establece los criterios de monitorización de MMS y lanza la escucha. 83 * 84 */ 85 public void monitorizaMMM(){ 86 87 try { 88 System.out.println("En el método monitorizaMMM"); 89 90 MMMNotificationRequest criterio[] = new MMMNotificationRequest[7]; 91 criterio[0] = new MMMNotificationRequest(emisor1, 92 receptorMMSalarmaCaida,true); 93 criterio[1] = new MMMNotificationRequest(emisor2, 94 receptorMMSalarmaCaida,true); 95 criterio[2] = new MMMNotificationRequest(emisor3, 96 receptorMMSalarmaCaida,true); 97 criterio[3] = new MMMNotificationRequest(emisor4, 98 receptorMMSalarmaCaida,true); 99 criterio[4] = new MMMNotificationRequest(emisor5, 100 receptorMMSCambioEstadoPaciente,true); 101 criterio[5] = new MMMNotificationRequest(emisor6, 102 receptorMMSCambioEstadoPaciente,true); 103 criterio[6] = new MMMNotificationRequest(emisor7, 104 receptorMMSCambioEstadoPaciente,true); 105 106 mmmAdapter.createNotification(criterio, this); 107 108 System.out.println(""); 109 110 111 } catch (MMMException e) { 112 // TODO Auto-generated catch block 113 e.printStackTrace(); 114 } 115 116 } 117 118 /** 119 * Método llamado por onEvent y que, según el destino del MMS, realiza la acción 120 * correspondiente (bien genera una alarma por caída o bien cambia el estado de 121 * un paciente). 122 * 123 * @param MSISDNdestinoMMS - número de destino del MMS capturado. 124 * @param MSISDNorigenMMS - número del origen del MMS cappturado.
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 189
125 */ 126 private void procesaMMS(String MSISDNdestinoMMS, String MSISDNorigenMMS){ 127 128 String sentencia_SQL; 129 ResultSet rs = null; 130 131 try { 132 // comprobamos cual es el destino del MMS; si es para cambiar 133 // el estado de un paciente, el mensaje procederá de un cuidador, 134 // por lo que buscamos su dni 135 136 if
(MSISDNdestinoMMS.equalsIgnoreCase(receptorMMSCambioEstadoPaciente)){ 137 138 sentencia_SQL = "SELECT nombre,apellido1,id_cuidador
FROM cuidadores " + 139 "WHERE MSISDN='" +
MSISDNorigenMMS +"'"; 140 141 rs = BBDD.consulta(sentencia_SQL); 142 rs.next(); 143 144 System.out.println("Mensaje procedente del cuidador: " +
rs.getString(1) 145 + " " + rs.getString(2) + ", con DNI " +
rs.getInt(3) + "."); 146 147 // ahora busco los pacientes asociados a este cuidador 148 sentencia_SQL = "SELECT MSISDN FROM pacientes
WHERE id_cuidador='" 149 + rs.getInt(3) +"'"; 150 151 rs = BBDD.consulta(sentencia_SQL); 152 long MSISDNpaciente; 153 ResultSet rs2 = null; 154 155 if (rs.first()){ 156 157 // al menos tiene un paciente asociado 158 do{ 159 MSISDNpaciente = rs.getLong(1); 160 sentencia_SQL = "SELECT estadoLoc
FROM estadopacloc " + 161 "WHERE MSISDN='" +
MSISDNpaciente + "'"; 162 163 rs2 = BBDD.consulta(sentencia_SQL); 164 165 if(rs2.first()){ 166 167 switch(rs2.getInt(1)){ 168 169 case Paciente.PacATENDIDO: 170 sentencia_SQL =
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 190
"UPDATE estadopacloc SET estadoLoc='" 171 +
Paciente.PacNORMAL + "' WHERE MSISDN='" 172 +
MSISDNpaciente + "'"; 173 174
BBDD.actualiza(sentencia_SQL); 175 System.out.println("Se
ha actualizado el estado " + 176 "del
paciente."); 177 System.out.println("Se
vigilará su posición de nuevo."); 178 179 // si no estoy en la
última fila, m voy a ella. 180 // se supone que un
cuidador no va a estar 181 // atendiendo a más de
un paciente 182 if (!rs.last()){ 183 rs.last(); 184 } 185 186 default: 187 // si el estado es
normal (se está vigilando 188 // su posición) no hago
nada 189 } 190 }
191 192 } while(rs.next()); 193 194 195 } else{ 196 197 System.out.println("Este cuidador no tiene asociado
" + 198 "ningún paciente."); 199 } 200 201 } else{ 202 203 // el mensaje proviene de un paciente 204 // por lo que se trata de una alarma por caída 205 206 // creo un array de string con todos los MSISDN de los
pacientes 207 // que tienen este servicio contratado 208 209 GestionPacientes g_p = new GestionPacientes();
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 191
210 String clientesServCaida[] = g_p.listado_MSISDN(Alarma.CAIDA);
211 212 boolean servCaidaContratado = false; 213 int i = 0; 214 215 // comprueblo si el cliente del que procede la alarma tiene 216 // este servicio contratado 217 while ((!servCaidaContratado) && (i <
clientesServCaida.length)){ 218 219 if
(MSISDNorigenMMS.equals(clientesServCaida[i])){ 220 221 servCaidaContratado = true;
222 } 223 224 i++; 225 } 226 227 if (servCaidaContratado){ 228 229 sentencia_SQL = "SELECT
nombre,apellido1,id_paciente FROM " + 230 "pacientes " +"WHERE
MSISDN='" + MSISDNorigenMMS +"'"; 231 232 rs = BBDD.consulta(sentencia_SQL); 233 rs.next(); 234 235 System.out.println("Caída del paciente: " +
rs.getString(1) + " " 236 + rs.getString(2) + ", con DNI " +
rs.getInt(3) + "."); 237 238 // se genera la alarma 239 System.out.println("Se procederá a generar la
alarma " + 240 "correspondiente."); 241 sentencia_SQL = "SELECT MSISDN FROM
pacientes WHERE id_paciente='" 242 + rs.getInt(3) +"'"; 243 rs = BBDD.consulta(sentencia_SQL); 244 rs.next(); 245 Alarma a = new Alarma(Alarma.CAIDA,
rs.getLong(1)); 246 247 GestionAlarmas.anadeAlarma(a); 248 249 } else{ 250 251 System.out.println("Se ha producido una alarma por
caída, pero el "+
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 192
252 "usuario no tiene contratado el servicio.");
253 } 254 } 255 } catch (SQLException e) { 256 // TODO Auto-generated catch block 257 e.printStackTrace(); 258 } 259 260 } 261 262 //================================================= 263 // Implementacion de la interfaz MMMListener 264 //================================================= 265 266 /** 267 * Método llamado por las Convenience Classes cuando se produce alguno de los 268 * eventos programados por la aplicación. 269 * 270 * @param mmmEvent - El evento MultiMediaMessaging que se acaba de producir. 271 */ 272 public void onEvent(MMMEvent mmmEvent) { 273 // TODO Auto-generated method stub 274 System.out.println("Evento capturado en onEvent de MMMListener."); 275 System.out.println("Recepción de un MMS."); 276 277 mmmSession = mmmEvent.getSession(); 278 279 try { 280 281 System.out.println("Dirección origen del mensaje: " 282 + mmmSession.getDefaultSourceAddress()); 283 284 String DireccionDestino[] =
mmmSession.getDefaultDestinationAddressList(); 285 System.out.println("Dirección destino: " + DireccionDestino[0]); 286 287 // llamada al método que procesaría el contenido del mensaje que ha 288 // provocado el evento 289 procesaMMS(DireccionDestino[0],
mmmSession.getDefaultSourceAddress()); 290 291 } catch (MMMException e) { 292 // TODO Auto-generated catch block 293 e.printStackTrace(); 294 } 295 } 296 297 /** 298 * No se usa. 299 */ 300 301 public void onError(MMMError mmmError) { 302 // TODO Auto-generated method stub
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 193
303 304 } 305 }
2.7 Paquete Gestion 2.7.1 GestionAlarmas.java
1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * GestionAlarmas.java
5 */ 6 7 package Gestion;
8 9 import java.util.Iterator;
10 import java.util.Vector;
11 12 import TipoDatos.Alarma;
13 14 /** 15 * Clase encargada de la gestión de los objetos alarmas en el sistema.
16 * Define un vector donde se almacenarán según se creen. Define métodos para
17 * insertar las alarmas y eliminarlas de manera sincronizada.
18 * 19 * @author Raúl Parras Eliche
20 * 21 */ 22 public class GestionAlarmas {
23
24
25 /**
26 * Posible valor de las respuesta de un cuidador ante una alarma de localización.
27 */
28 public static final int ATENDIDO = 1;
29 /**
30 * Posible valor de las respuesta de un cuidador ante una alarma de localización.
31 */
32 public static final int DESCONOCIDO = 2;
33 /**
34 * Posible valor de las respuesta de un cuidador ante una alarma de localización.
35 */
36 public static final int ERROR = 3;
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 194
37 /**
38 * Posible valor de las respuesta de un cuidador ante una alarma de localización.
39 */
40 public static final int TIMEOUT = 4;
41
42
43 /**
44 * Vector donde se irán almacenando las alarmas que se creen.
45 */
46 public static Vector<Alarma> Alarmas = new Vector<Alarma>();
47
48
49
50 /**
51 * Método que añade una nueva alarma en el vector de alarmas que procesa el
52 * hilo principal. Es un método sincronizado para que no haya problemas de
53 * acceso múltiple al vector.
54 *
55 * @param alarma - Objeto alarma a insertar.
56 */
57
58 public static void anadeAlarma (Alarma alarma) {
59
60 synchronized (Alarmas) {
61
62 Alarmas.addElement(alarma);
63 System.out.println("La alarma se ha insertado con éxito.");
64 Alarmas.notify();
65
66 }
67
68 }
69
70
71 /**
72 * Método que elimina una alarma en el vector de alarmas que procesa el
73 * hilo principal. Es un método sincronizado para evitar accesos múltiples.
74 *
75 * @param alarma - Objeto alarma a eliminar del vector.
76 */
77
78 public static void eliminaAlarma (Alarma alarma) {
79
80 synchronized (Alarmas) {
81
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 195
82 if (Alarmas.removeElement(alarma)){
83
84 System.out.println("La alarma se ha eliminado con éxito.");
85 Alarmas.notify();
86
87 }else{
88 System.out.println("La alarma no se ha podido eliminar.");
89 }
90
91 }
92 }
93
94 95 /**
96 * Método que comprueba si ya se ha generado una alarma con los parámetros que se le
97 * pasan. Esto impedirá generar la misma alarma dos veces (por si se da la posibilidad de
98 * que el hilo hijo vuelva a comprobar la misma situacion anómala dos o más veces sin que el
99 * hilo principal haya procesado la alarma).
100 *
101 * @param alarma - tipo de alarma que se quiere comprobar.
102 * @param msisdn - número de abonado creador de la alarma que se quiere comprobar.
103 * @return alarmaCreada - True si la alarma ya se había creado previamente; False en
104 * cao contrario.
105 */
106
107 public static synchronized boolean compruebaAlarmaCreada(int alarma, long msisdn){
108
109 boolean alarmaCreada = false;
110
111 Iterator it = Alarmas.iterator();
112
113 while (it.hasNext() && !alarmaCreada){
114
115 Alarma a = (Alarma) it.next();
116
117 if (a.MSISDN == msisdn){
118
119 if (a.id_alarma == alarma){
120
121 alarmaCreada = true;
122 }
123 }
124 }
125 return alarmaCreada;
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 196
126 }
127 }
2.7.2 GestionAmbulancias.java
1 /*
2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay
3 *
4 * GestionAlarmas.java
5 */
6
7 package Gestion;
8
9 import java.sql.ResultSet;
10 import java.sql.SQLException;
11 import java.util.Iterator;
12 import java.util.Vector;
13
14 import BaseDeDatos.BBDD;
15 import EstadoTerminal.EstadoUsuario;
16 import TipoDatos.Ambulancia;
17
18 import com.lucent.isg.appsdk.framework.FrameworkAdapter;
19 import com.lucent.isg.appsdk.userlocation.UserLocation;
20 import com.lucent.isg.appsdk.userlocation.UserLocationAdapter;
21 import com.lucent.isg.appsdk.userlocation.UserLocationException;
22 import com.lucent.isg.appsdk.userstatus.UserStatus;
23
24 /**
25 * Clase encargada de la gestión de los objetos ambulancia.
26 *
27 * @author Raúl Parras Eliche
28 */
29 public class GestionAmbulancias {
30
31 /**
32 * Vector que contiene todas las ambulancias disponibles para la aplicación.
33 */
34 public static Vector<Ambulancia> Ambulancias = new Vector<Ambulancia>();
35
36 /**
37 * Método que inicializa el vector Ambulancias
38 */
39 public static void listaAmbulancias(){
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 197
40
41 Ambulancia amb;
42
43 String sentencia_SQL = "SELECT MSISDN FROM ambulancias";
44 ResultSet rs = BBDD.consulta (sentencia_SQL);
45
46 try {
47
48 while (rs.next()){
49 // las ambulancias están inicialmente todas libres
50 amb = new Ambulancia (rs.getLong(1), false);
51 Ambulancias.addElement(amb);
52
53 }
54
55 } catch (SQLException e) {
56 // TODO Auto-generated catch block
57 e.printStackTrace();
58 }
59 }
60
61 /**
62 * Método que devuelve el MSISDN de la ambulancia disponible más cercana a la
63 * posición que se le pasa como parámetro. Se comprueba también que el terminal
64 * móvil de la ambulancia esté encendido (REACHABLE).
65 *
66 * @param locPac - posición del paciente que necesita la ambulancia.
67 * @param ulAdapter - Adaptador del servicio de localización.
68 * @param fwAdapter - FrameworkAdapter del servicio de tele asistencia, necesario
69 * para obtener el resto de adaptadores.
70 * @return MSISDN - Número del terminal de la ambulancia disponible y más cercana
71 * al paciente.
72 */
73 public static String ambulanciaMasCercana(UserLocation locPac,
74 UserLocationAdapter ulAdapter, FrameworkAdapter fwAdapter){
75
76 // Creo un array de String con todos los MSISDN de las ambulancias que no
77 // están ocupadas en este momento y el estado de su terminal sea REACHABLE.
78 // Primero creo un vector, porque puede que el número total de ambulancias
79 // no coincida con las disponibles.
80 //******************************************************************************
81 Vector <String> MSISDNamb= new Vector<String>();
82
83 EstadoUsuario eu = new EstadoUsuario(fwAdapter);
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 198
84
85 Iterator it = Ambulancias.iterator();
86 Ambulancia a;
87 Long l;
88
89 while (it.hasNext()){
90 a = (Ambulancia)it.next();
91
92 // si la ambulancia no está ocupada y su estado es REACHABLE,
93 // copio su MSISDN al Vector MSISDNamb
94
95 if (!a.ocupado){
96
97 l = a.MSISDN;
98
99 if (eu.estadoTerminal(l.toString()) == UserStatus.US_REACHABLE){
100
101 MSISDNamb.addElement(l.toString());
102 }
103 }
104 }
105
106 // elimino el adaptador de servicio UserStatus
107 eu.cleanup();
108
109
110 String MSISDN = null;
111
112 switch (MSISDNamb.size()){
113
114 case 0:
115 // no hay ambulancias disponibles
116 // se devolverá null
117 break;
118
119 case 1:
120 // sólo hay una ambulancia disponible
121 // no hay que calcular cual es la más cercana
122 MSISDN = MSISDNamb.firstElement();
123
124 break;
125
126 default:
127 String[] amb = new String[MSISDNamb.size()];
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 199
128
129 it = MSISDNamb.iterator();
130 int i =0;
131 String s;
132
133 while (it.hasNext()){
134
135 s = (String)it.next();
136 amb[i] = s;
137 i++;
138 }
139
140 // Obtengo las posiciones de las ambulancias
141 // ***************************************************************************
142 UserLocation[] locAmb = null;
143
144 try {
145
146 locAmb = ulAdapter.requestLocation(amb);
147
148 } catch (UserLocationException e) {
149 // TODO Auto-generated catch block
150 e.printStackTrace();
151 }
152
153 // Calculo la distancia entre cada ambulancia y el paciente
154 // **************************************************************************
155
156 double d1 = 0;
157 double d2 = 0;
158
159 for (int j= 0; j<amb.length; j++){
160
161 if (j == 0){ // para la primera vez
162
163 d1 = locAmb[j].distanceTo(locPac);
164 MSISDN = locAmb[j].getUser();
165
166 } else{
167
168 d2 = locAmb[j].distanceTo(locPac);
169 if (d2 < d1){
170 d1 = d2;
171 MSISDN = locAmb[j].getUser();
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 200
172 }
173 }
174 }
175 }
176 return MSISDN;
177 }
178 }
2.7.3 GestionCaida.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * GestionCaida.java 5 */ 6 7 package Gestion;
8 9 import TipoDatos.Alarma;
10 11 import com.lucent.isg.appsdk.framework.FrameworkAdapter;
12 import com.lucent.isg.appsdk.framework.FrameworkException;
13 import com.lucent.isg.appsdk.userlocation.UserLocation;
14 import com.lucent.isg.appsdk.userlocation.UserLocationAdapter;
15 import com.lucent.isg.appsdk.userlocation.UserLocationException;
16 17 /** 18 * Clase que se encarga del tratamiento de las alarmas originadas por caída
19 * de un paciente. 20 * 21 * @author Raúl Parras Eliche
22 * 23 */ 24 public class GestionCaida {
25
26 private FrameworkAdapter fwAdapter = null;
27 private Script script = null;
28 private UserLocationAdapter ulAdapter = null;
29
30 /**
31 * Construye un objeto de la clase GestionCaida e inicializa el adaptador
32 * UserLocation mediante el FramworkAdapter.
33 *
34 * @param fwAdapter - FrameworkAdapter del servicio de tele asistencia, necesario
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 201
35 * para obtener el resto de adaptadores.
36 * @param script - Clase para cargar y ejecutar programas en el simulador.
37 */
38 public GestionCaida(FrameworkAdapter fwAdapter, Script script){
39
40 this.fwAdapter = fwAdapter;
41 this.script = script;
42
43 try {
44 ulAdapter = fwAdapter.selectUserLocationService();
45
46 } catch (FrameworkException e) {
47 // TODO Auto-generated catch block
48 e.printStackTrace();
49 }
50 }
51
52
53 /**
54 * Método encargado del procesamiento de la alarma por caída.
55 *
56 * @param alarma - Objeto alarma a tratar.
57 */
58 public void procesaAlarmaCaida(Alarma alarma){
59
60 // necesito la posición del paciente que ha generado la alarma, para ver
61 // cual es la ambulancia más cercana
62 Long MSISDNpac = alarma.MSISDN;
63
64 // obtengo la posicion de los abonados
65 UserLocation locPac = null;
66
67 try {
68
69 locPac = ulAdapter.requestLocation(MSISDNpac.toString());
70
71
72 } catch (UserLocationException e1) {
73 // TODO Auto-generated catch block
74 System.out.println("\n--- UserLocationException caught ---\n");
75 e1.printStackTrace();
76 }
77
78
79 String MSISDNamb = GestionAmbulancias.ambulanciaMasCercana(locPac,
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 202
80 ulAdapter,fwAdapter);
81
82 if (MSISDNamb != null){
83
84 String programa = "LLamada_Central_" + MSISDNamb;
85 script.ejecutaPrograma(programa, false);
86 GestionAlarmas.eliminaAlarma(alarma);
87 }
88 }
89 } 2.7.4 GestionPacientes.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * GestionPacientes.java 5 */ 6 7 package Gestion;
8 9 import java.sql.ResultSet;
10 import java.sql.SQLException;
11 import java.util.Iterator;
12 import java.util.Vector;
13 14 import BaseDeDatos.BBDD;
15 import TipoDatos.Alarma;
16 import TipoDatos.Paciente;
17 18 /** 19 * Clase que define los métodos necesarios para gestionar los objetos pacientes.
20 * 21 * @author Raúl Parras Eliche.
22 */ 23 public class GestionPacientes {
24 25 /**
26 * Metodo que devuelve un Vector con todos los objetos pacientes que tenemos en la BBDD,
27 * pero sólo aquellos que tienen contratado algún servicio.
28 *
29 * @return Pacientes - Listado de pacientes con algún servicio contratado.
30 */
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 203
31 public Vector listaPacientes(){
32
33 // vector que devuelve el método
34 Vector<Paciente> Pacientes = new Vector<Paciente>();
35
36 String sentencia_SQL = "SELECT id_paciente,MSISDN FROM pacientes";
37 ResultSet rs = BBDD.consulta (sentencia_SQL);
38
39 Vector<Integer> id_pacientes = new Vector<Integer>();
40 Vector<Long> MSISDN = new Vector<Long>();
41
42 // obtengo en un vector todos los pacientes almacenados en la BBDD
43 // y otro con sus MSISDN
44
45 try {
46
47 while (rs.next()){
48
49 id_pacientes.addElement(rs.getInt(1));
50 MSISDN.addElement(rs.getLong(2));
51 }
52 } catch (SQLException ex) {
53 // TODO Auto-generated catch block
54 System.out.println("\n--- SQLException caught ---\n");
55 while (ex != null) {
56 System.out.println("Message: " + ex.getMessage ());
57 System.out.println("SQLState: " + ex.getSQLState ());
58 System.out.println("ErrorCode: " + ex.getErrorCode ());
59 ex = ex.getNextException();
60 System.out.println("");
61 }
62 }
63
64 for (int i=0; i < id_pacientes.size(); i++){
65
66
67 // esta consulta me va a devolver todas las alarmas que tengo que
68 // tener en cuanta para el paciente anterior
69
70 sentencia_SQL = "SELECT cod_alarma FROM" +
71 "servicios_contratados WHERE " +
72 "id_paciente='" +
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 204
73 id_pacientes.elementAt(i) + "'";
74 rs = BBDD.consulta(sentencia_SQL);
75
76 try {
77 if (rs.next()){
78 //por lo menos ha contratado un servicio
79 Paciente pac = new Paciente();
80 pac.id_paciente = id_pacientes.elementAt(i);
81 pac.MSISDN = MSISDN.elementAt(i);
82 pac.servicios.addElement (new Integer(rs.getInt(1)));
83
84 // Bucle para almacenar en el vector el resto de
85 // los servicios contratados
86 while (rs.next()){
87 pac.servicios.addElement(new Integer(rs.getInt(1)));
88 }
89
90 // Introduzco el objeto paciente recién creado en el vector Pacientes
91 Pacientes.addElement(pac);
92
93 }
94
95 } catch (SQLException ex) {
96 // TODO Auto-generated catch block
97 System.out.println("\n--- SQLException caught ---\n");
98 while (ex != null) {
99 System.out.println("Message: " + ex.getMessage ());
100 System.out.println("SQLState: " + ex.getSQLState ());
101 System.out.println("ErrorCode: " + ex.getErrorCode ());
102 ex = ex.getNextException();
103 System.out.println("");
104 }
105 }
106
107 }
108
109 // vacío los vectores pacientes y MSISDN
110 id_pacientes.clear();
111 MSISDN.clear();
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 205
112
113 return Pacientes;
114 }
115 116 /**
117 * Metodo que imprime por la salida estandar un listado de pacientes.
118 *
119 * @param Pacientes - Listado de pacientes a imprimir.
120 */
121 public void imprimeVectorPacientes(Vector Pacientes){
122
123 Iterator it1 = Pacientes.iterator();
124
125 System.out.println("");
126 System.out.println("************ Listado de pacientes ************");
127 System.out.println("Id_paciente******MSISDN******Alarmas Contratadas**");
128
129 Paciente pac = null;
130
131 while (it1.hasNext()){
132
133 pac = (Paciente) it1.next();
134 System.out.print(" " + pac.id_paciente + " " + pac.MSISDN +" ");
135 Vector serv = pac.servicios;
136
137 Iterator it2 = serv.iterator();
138 while (it2.hasNext()){
139
140 Integer alarma = (Integer)it2.next();
141 System.out.print(" " + alarma.toString());
142 }
143 System.out.println();
144 }
145 System.out.println("");
146
147 }
148 149 /**
150 * Método que devuelve un array de string con los MSISDN de los pacientes que tienen
151 * contratado el servicio que recibe como parámetro.
152 *
153 * @param servicio - Código del servicio del que queremos saber qué pacientes lo
154 * lo tienen contratado.
155 * @return UL_abonados - lista de MSISDN de los pacientes que tienen el servicio
156 * contratado
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 206
157 */
158
159 public String[] listado_MSISDN (int servicio){
160
161 // creo un vector y no un array de String directamente porque el numero de
162 // abonados a este servicio puede variar
163
164 Vector<Long> abonados = new Vector<Long>();
165
166 // primero obtengo un listado de todos los pacientes que tienen algún servicio
167 // contratado
168 Vector Pacientes = listaPacientes();
169
170 Iterator it1 = Pacientes.iterator();
171 Paciente p = null;
172 Vector serv = null;
173 Iterator it2 = null;
174 Integer alarma;
175
176 while (it1.hasNext()){
177
178 p = (Paciente) it1.next();
179 serv = p.servicios;
180
181 it2 = serv.iterator();
182
183 while (it2.hasNext()){
184 alarma = (Integer)it2.next();
185
186 if (alarma == servicio)
187 abonados.addElement(new Long(p.MSISDN));
188 }
189
190 }
191
192 // convierto el vector de abonados UL a un array de String
193
194 String[] usuarios = new String[abonados.size()];
195
196 System.out.println("El vector de abonados para el servicio de "
197 + Alarma.tipoAlarma_toString(servicio) + ": ");
198
199 Iterator it3 = abonados.iterator();
200 int i =0;
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 207
201 Long l;
202 while (it3.hasNext()){
203 l = (Long)it3.next();
204 usuarios[i] = l.toString();
205 System.out.println(" ---->> " + usuarios[i]);
206 i++;
207 }
208 System.out.println("");
209
210 abonados.clear();
211 Pacientes.clear();
212 serv.clear();
213
214 return usuarios;
215 }
216 } 2.7.5 Script.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * Script.java 5 */ 6 7 8 package Gestion;
9 10 import com.lucent.isg.appsdk.script.*;
11 /** 12 * Clase que implementa la interfaz ScriptCallback. Define los métodos necesarios
13 * para cargar y descargar scripts y para ejecutar programas en el simulador.
14 * 15 * @author Raúl
16 * 17 */ 18 public class Script implements ScriptCallback {
19 20 21 // Clase para acceder a la interfaz ScriptProcessor.
22 private ScriptAdapter scriptAdapter = null;
23 24 // variable que indicará si el programa debe esperar la ejecucion en el simulador de
25 // un programa del script.
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 208
26 private boolean waitUntilStopped = true;
27 28 29 /** 30 * Constructor que ejecuta la inicializacion del script adapter y registra 31 * la interfaz ScriptCallback, para que los métodos onXXX de la clase sean
32 * llamados cuando se produzcan eventos importantes.
33 */ 34 public Script() {
35 36 System.out.println("Inicializando ScriptAdapter ...");
37 try { 38 39 // creamos el objeto SriptAdapter
40 scriptAdapter = ScriptAdapterFactory.createScriptAdapter(); 41 42 // register a callback interface (= this), causing the onXXXX() 43 // methods to be called upon important events
44 ScriptStatus status = scriptAdapter.registerCallback(this);
45 46 // display the status of the Script Processor 47 System.out.println("Status: " + status);
48 49 } catch (ScriptException e) {
50 e.printStackTrace();
51 } 52 } 53 54 /** 55 * Carga el script que se le pase como parametro en el simulador.
56 * Muestra ,además, el nombre de la simulacion así como todos los programas
57 * y pasos de que consta dicho archivo XML.
58 * 59 * @param scriptfile - Archivo XML que se cargará en el simulador.
60 */ 61 public void cargaScript(String scriptfile) {
62 63 System.out.println("Cargando script ...");
64 try { 65 // si una simulacion (script) ya esta cargada, se descarga:
66 if ( scriptAdapter.isScriptLoaded() ) { 67 scriptAdapter.unloadScript(); 68 System.out.println("Anterior script descargado.");
69 } 70
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 209
71 // cargamos el script de teleasistencia:
72 scriptAdapter.loadScript(scriptfile); 73 74 75 // obtenemos los programas disponibles:
76 String[] programs = scriptAdapter.getPrograms();
77 System.out.println("Los programas son:");
78 for ( int i = 0; i < programs.length; i++ )
79 System.out.println(" [" + i + "]=" + programs[i]);
80 81 // obtenemos los pasos disponibles:
82 String[] steps = scriptAdapter.getSteps(); 83 System.out.println("Los pasos son:");
84 for ( int i = 0; i < steps.length; i++ )
85 System.out.println(" [" + i + "]=" + steps[i]);
86 87 88 } catch (ScriptException e) {
89 e.printStackTrace();
90 } 91 92 } 93 94 95 /** 96 * Ejecuta un programa en el simulador.
97 * 98 * @param program - Nombre del programa a ejecutar en el simulador.
99 * @param waitUntilStopped - Boolean para indicar si queremos esperar que termine
100 * la ejecución del programa en el simulador (true para que espere).
101 */ 102 public void ejecutaPrograma(String program, boolean waitUntilStopped) {
103
104 this.waitUntilStopped = waitUntilStopped;
105 106 System.out.println("Going to run program \'" + program + "\'");
107 try { 108 109 scriptAdapter.runProgram(program, ScriptStatus.CONTINUOUS);
110 111 } catch (ScriptException e) {
112 e.printStackTrace(); 113 114 } 115
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 210
116 if ( waitUntilStopped ) { 117 synchronized (this) {
118 try { 119 // espera el notify() en onStopped() 120 wait(); 121 } catch (Exception e) { }
122 } 123 } 124 125 } 126 127 128 /** 129 * Descarga el script que haya en el simulador
130 * 131 */ 132 public void descargaScript(){
133 134 try {
135 scriptAdapter.unloadScript();
136
137 } catch (ScriptException e) {
138 e.printStackTrace();
139
140 }
141 } 142 143 144 /** 145 * Termina el ScriptAdapter.
146 */ 147 148 public void destroy() {
149 150 try { 151 // destroy the Script Adapter: 152 scriptAdapter.destroy(); 153 154 } catch (ScriptException e) {
155 e.printStackTrace(); 156 } 157 } 158 159 //============================================== 160 // Implementacion de la interfaz ScriptCallback
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 211
161 //============================================== 162 163 /** 164 * Método llamado cuando el proceso de registro es cancelado.
165 */ 166 public void onUnregistered()
167 { 168 // System.out.println("onUnregistered() called");
169 } 170 171 /** 172 * Método llamado cuando un script se carga con éxito en el simulador.
173 * 174 * @param filename name of script file
175 * @param simulation name of simulation
176 */ 177 public void onScriptLoaded(String filename, String simulation)
178 { 179 //System.out.println("onScriptLoaded() called");
180 //System.out.println(" Archivo cargado = " + filename);
181 //System.out.println(" Nombre de la simulacion = " + simulation);
182 } 183 184 /** 185 * Método llamado cuando se descarga un script del simulador.
186 */ 187 public void onScriptUnloaded()
188 { 189 //System.out.println("onScriptUnloaded() called");
190 } 191 192 /** 193 * Método llamado cuando un programa del script comienza a ejecutarse.
194 */ 195 public void onRunning(String program, int mode)
196 { 197 //System.out.println("onRunning() called");
198 //System.out.println(" Nombre del programa = " + program);
199 //System.out.println(" Modo de ejecución = " + ScriptStatus.modeName(mode));
200 } 201 202 /** 203 * Método llamado cuando se detiene la ejecución de un programa.
204 * Si al ejecutar un programa le dimos el valor true a la variable waitUntilStopped,
205 * este método hará un Notify() avisando al hilo que llamó a ejecutaPrograma, que
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 212
206 * estaba esperando, para avisarle de que el simulador ha terminado la ejecución.
207 */ 208 public void onStopped()
209 { 210 //System.out.println("onStopped() called en clase Script.");
211 212 if ( waitUntilStopped ) { 213 synchronized (this) {
214 try { 215 // notify wait() in runProgram()
216 notify(); 217 } catch (Exception e) { }
218 } 219 } 220 } 221 222 /** 223 * Método llamado cuando de pausa la ejecución de un programa.
224 */ 225 public void onPaused()
226 { 227 System.out.println("onPaused() called");
228 } 229 230 /** 231 * Método llamado cuando se ha terminado la ejecución de un paso de un programa.
232 */ 233 public void onExecutedProgramStep(String program, String nextStep, String errors)
234 { 235 //System.out.println("onExecutedProgramStep() called");
236 //System.out.println(" program = " + program);
237 //System.out.println(" nextStep = " + nextStep);
238 //System.out.println(" errors = " + errors);
239 } 240 241 /** 242 * Método llamado cuando un paso (fuera del contexto de un programa) ha sido ejecutado.
243 */ 244 public void onExecutedStep(String step, String errors)
245 { 246 //System.out.println("onExecutedStep() called");
247 //System.out.println(" step = " + step);
248 //System.out.println(" errors = " + errors);
249 } 250 }
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 213
2.8 Paquete TipoDatos 2.8.1 Alarma.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * Alarma.java 5 */ 6 7 package TipoDatos; 8 9 /** 10 * Clase que define las características de las alarmas. 11 * 12 * @author Raúl Parras Eliche 13 * 14 */ 15 public class Alarma { 16 17 /** 18 * Tipo de alarma. 19 */ 20 public static final int CAIDA = 1; 21 /** 22 * Tipo de alarma. 23 */ 24 public static final int PERSONA_PERDIDA = 2; 25 26 /** 27 * Código de identificación de la alarma. 28 */ 29 public int id_alarma; 30 31 /** 32 * MSISDN del paciente que genera la alarma. 33 */ 34 public long MSISDN; 35 36 /** 37 * Prioridad asociada a la naturaleza de la alarma. 38 */ 39 public int priAlarma; 40 41 /** 42 * Prioridad asociada al tiempo de reacción requerido frente a la alarma. 43 */ 44 public int priReaccion; 45 46 /** 47 * Estado actual de la alarma, que a su vez indicará si la alarma está o no 48 * activa y si está pendiente o no de ser atendida por el sistema. 49 */
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 214
50 public int estadoAlarma; 51 52 /** 53 * Identificador del operario que ha atendido la alarma. 54 */ 55 public int idOperario; 56 57 58 59 /** 60 * Construye un objeto vacío. 61 */ 62 public Alarma (){ 63 64 this.id_alarma = -1; 65 this.MSISDN = -1; 66 67 } 68 69 /** 70 * Construye un nuevo objeto Alarma con los datos especificados id_alarma y MSISDN. 71 * @param id_alarma 72 * @param MSISDN 73 */ 74 public Alarma(int id_alarma, long MSISDN){ 75 76 this.id_alarma = id_alarma; 77 this.MSISDN = MSISDN; 78 79 } 80 81 /** 82 * Método que devuelve el nombre del servicio asociado al número de alarma
especificado. 83 * @param alarma 84 * @return nombre_alarma 85 */ 86 public static String tipoAlarma_toString(int alarma){ 87 88 String nombre_alarma; 89 90 switch (alarma) { 91 case CAIDA: 92 nombre_alarma = "detección de caídas"; 93 break; 94 95 case PERSONA_PERDIDA: 96 nombre_alarma = "detección de personas perdidas"; 97 break; 98 99 default: 100 nombre_alarma = "servicio desconocido"; 101 break; 102 }
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 215
103 104 return nombre_alarma; 105 } 106 107 }
2.8.2 Ambulancia.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * Ambulancia.java 5 */ 6 7 package TipoDatos; 8 9 /** 10 * Clase que define las caraterísticas de los objetos Ambulancia. 11 * 12 * @author Raúl Parras Eliche 13 * 14 */ 15 public class Ambulancia { 16 17 /** 18 * Número del terninal de la ambulancia. 19 */ 20 public long MSISDN; 21 22 /** 23 * Estado en que se encuentra la ambulancia: si está libre o si se está utilizando 24 * con algún paciente. 25 */ 26 public boolean ocupado; 27 28 /** 29 * Construye un objeto Ambulancia con los datos especificados MSISDN y ocupado. 30 * 31 * @param MSISDN 32 * @param ocupado 33 */ 34 public Ambulancia(long MSISDN, boolean ocupado){ 35 36 this.MSISDN = MSISDN; 37 this.ocupado = ocupado; 38 } 39
2.8.3 NumerosServicio.java 1 /*
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 216
2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * NumerosServicio.java 5 */ 6 7 package TipoDatos; 8 9 /** 10 * Interfaz que define los números de los terminales que prestan el servicio. 11 * Se definen los números de la central, de la operadora y de los servicios 12 * de recepción de alarmas de caídas y de peticiones de cambios del estado 13 * de un paciente. 14 * 15 * @author Raúl Parras Eliche 16 * 17 */ 18 public interface NumerosServicio { 19 20 /** 21 * Número de terminal principal del servicio. 22 */ 23 public static final String MSISDNcentral = "160111111111"; 24 25 /** 26 * Número de terminal de la operadora. 27 */ 28 public static final String MSISDNoperadora = "160222222222"; 29 30 /** 31 * Número de terminal para recepción de las alarmas de caída. 32 */ 33 public static final String MSISDNalarmaCaida = "160333333333"; 34 35 /** 36 * Número de terminal para la recepción de los cambios de estado de los 37 * pacientes en el servicio de localización. 38 */ 39 public static final String MSISDNcambioEstPac = "160444444444"; 40 41 }
2.8.4 Paciente.java 1 /* 2 * Proyecto Fin de Carrera: Servicio de Teleasistencia basado en OSA/Parlay 3 * 4 * Paciente.java 5 */ 6 7 package TipoDatos; 8
Capítulo VI: Anexos Anexo II: Código de la aplicación
Raúl Parras Eliche 217
9 import java.util.Vector; 10 /** 11 * Clase que contiene los datos relacionados con un paciente. 12 * 13 * @author Raúl Parras Eliche 14 * 15 */ 16 public class Paciente { 17 18 /** 19 * Posible estado de un paciente del servicio de localización 20 */ 21 public static final int PacNORMAL = 1; 22 23 /** 24 * Posible estado de un paciente del servicio de localización 25 */ 26 public static final int PacATENDIDO = 2; 27 28 29 /** 30 * Entero que almacenará el dni del paciente. 31 */ 32 public int id_paciente; 33 34 35 /** 36 * Número del termninal del paciente. 37 */ 38 public long MSISDN; 39 40 41 /** 42 * Vector para almacenar los servicios contratados por cada cliente. 43 * @uml.property name="servicios" 44 */ 45 public Vector<Integer> servicios = new Vector<Integer>(); 46 47 }
Capítulo VI: Anexos Anexo III: Javadoc
Raúl Parras Eliche 218
3. Anexo III: Javadoc
A continuación se muestran algunas capturas de la documentación de la
aplicación generada mediante la herramienta JavaDoc, en las que se aprecian
todos los paquetes que han sido necesarios elaborar.
Paquetes de la aplicación
Figura 62. Lista de Paquetes
Capítulo VI: Anexos Anexo III: Javadoc
Raúl Parras Eliche 219
Paquete BaseDeDatos
Figura 63. Paquete BaseDeDatos
Paquete TipoDatos
Figura 64. Paquete TipoDatos
Capítulo VI: Anexos Anexo III: Javadoc
Raúl Parras Eliche 220
Paquete Localización
Figura 65. Paquete Localización
Paquete Gestión
Figura 66. Paquete Gestión
Capítulo VI: Anexos Anexo III: Javadoc
Raúl Parras Eliche 221
Paquete InteraccionUsuario
Figura 67. Paquete InteraccionUsuario
Paquete EstadoTerminal
Figura 68. Paquete EstadoTerminal
Capítulo VI: Anexos Anexo III: Javadoc
Raúl Parras Eliche 222
Paquete MensajeriaMultimedia
Figura 69. Paquete MensajeriaMultimedia