bibing.us.esbibing.us.es/proyectos/abreproy/11413/descargar_fichero... · Índice general raúl...

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


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


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


Í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


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



Capítulo I

Introducción General

Capítulo I: Introducción general 1. Motivación y objetivos


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



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



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



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.



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:



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



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


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



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.



Figura 1. Diagrama de Gantt

Capítulo I: Introducción general 3. Material empleado


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


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


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



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 II

Introducción Teórica

Capítulo II: Introducción teórica 1. Los servicios 3G


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



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.



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:



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.



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



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



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



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



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


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.



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.



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.



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é



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.



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



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



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



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.



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)



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.



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)



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



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



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



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.



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.



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



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



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.



Figura 10. CCCS. Clases de la aplicación



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.



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



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.



Figura 13. Paquete Movilidad

Capítulo II: Introducción teórica 3. MiLife™ ISG SDK


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



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:



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.



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



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



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:



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



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



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:



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



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.



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.



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.



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



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.



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.



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



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.



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



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



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.



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:



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



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



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



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



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:



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



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



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.



Figura 36. Etiqueta BehaviorSet


Capítulo III

Desarrollo del Proyecto

Capítulo III: Desarrollo del proyecto 1. Introducción


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



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.



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


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



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



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



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


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


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


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



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



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.



Figura 42. Principales relaciones de la clase TeleAsistencia



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



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.



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.



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



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



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.



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.



Figura 49. Esquema del paquete InteraccionUsuario

Figura 50. Clase InteraccionUsuarioLoc



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



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.



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



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



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



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.



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



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 IV

Conclusiones y líneas futuras

Capítulo IV: Conclusiones y líneas futuras


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


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.


Capítulo V

Referencias bibliográficas

Capítulo V: Referencias bibliográficas


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



[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



[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/


Capítulo VI

Anexos

Capítulo VI: Anexos Anexo I: teleasistencia.xml


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>

50 </subscriber> 51 52 </subscriberSet> 53 54 <behaviorSet> 55 56  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  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  74 <ulBehaviorStatic name="ulCentral" longitude="-5.95589" latitude="37.39038"/> 75 76  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  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  96 <latency>50</latency> 97

98 

99 <parameters noAnswerTime="30000"/> 100 </ccState> 101 102 <ulState> 103  104 <latency>50</latency> 105  106 <fixedErrorFilter percentage="0"/> 107 <networkModel> 108  109 <ideal uncertainty="0"/> 110 </networkModel> 111 </ulState> 112 113 <usState> 114  115 <latency>50</latency> 116 </usState> 117 118 <uiState> 119  120  121  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  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"/>

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

190 <subscriberRef>Ambulancia2</subscriberRef> 191 </addSubscriber> 192 </ccStep> 193 </step> 194 195  196 <step name="Establecer_User_Location"> 197 <ulStep> 198  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  217 <ulSubscriberState> 218 <subscriberRef>Central</subscriberRef> 219 <behaviorRef>ulCentral</behaviorRef> 220 </ulSubscriberState> 221 222  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  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>

243 <behaviorRef>ul_Cuidador3</behaviorRef> 244 </ulSubscriberState> 245 246 </ulStep> 247 </step> 248 <step name="Establecer_User_Status"> 249 <usStep> 250  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>



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>

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


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 /**



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



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



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



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



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 /**



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



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 *



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



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



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



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.



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



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



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


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



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



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



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



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



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



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



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


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



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;



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



é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



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



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 }



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



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



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



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



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



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



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



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 /**



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



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


136

137 // cierro la sesión multimedia

138 mmmSession.close();

139 } catch (MMMException e) {


141 System.out.println("\n--- MMMException atrapada ---\n");





144 } catch (FileNotFoundException e) {



147 } catch (IOException e) {



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



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



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: "



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.



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 =



"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();



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 "+



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



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 /**


31 */

32 public static final int DESCONOCIDO = 2;

33 /**


35 */

36 public static final int ERROR = 3;



37 /**


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



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;



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;


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



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



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.



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



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()];



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



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



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 *





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



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


74 System.out.println("\n--- UserLocationException caught ---\n");

75 e1.printStackTrace();

76 }

77

78

79 String MSISDNamb = GestionAmbulancias.ambulanciaMasCercana(locPac,



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;


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 */



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


48

49 id_pacientes.addElement(rs.getInt(1));

50 MSISDN.addElement(rs.getLong(2));

51 }

52 } catch (SQLException ex) {


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


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='" +



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


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


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


104 }

105 }

106

107 }

108

109 // vacío los vectores pacientes y MSISDN

110 id_pacientes.clear();

111 MSISDN.clear();



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


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


139

140 Integer alarma = (Integer)it2.next();

141 System.out.print(" " + alarma.toString());

142 }

143 System.out.println();

144 }


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



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


177

178 p = (Paciente) it1.next();

179 serv = p.servicios;

180

181 it2 = serv.iterator();

182


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;



201 Long l;


203 l = (Long)it3.next();

204 usuarios[i] = l.toString();

205 System.out.println(" ---->> " + usuarios[i]);

206 i++;

207 }


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.



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


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



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


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



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


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



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



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 }



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 */



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 }



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 /*



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



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


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



Paquete BaseDeDatos

Figura 63. Paquete BaseDeDatos

Paquete TipoDatos

Figura 64. Paquete TipoDatos



Paquete Localización

Figura 65. Paquete Localización

Paquete Gestión

Figura 66. Paquete Gestión



Paquete InteraccionUsuario

Figura 67. Paquete InteraccionUsuario

Paquete EstadoTerminal

Figura 68. Paquete EstadoTerminal



Paquete MensajeriaMultimedia

Figura 69. Paquete MensajeriaMultimedia

bibing.us.esbibing.us.es/proyectos/abreproy/11413/descargar_fichero... · Índice general raúl...

Documents