Sistemas context ‐ aware y servicios AAL sobre IMS 72

En la  actualidad,  la  mayoría de  las aplicaciones  AAL  aprovechan el  protocolo  IP  (Internet Protocol) que permite invocar servicios de una manera transparente y ubicua  a través de comunicaciones peer‐to‐peer o aplicaciones no dependientes del operador  de red. A través de la utilización de la arquitectura IMS y sus servicios, los operadores  de red y desarrolladores de aplicaciones pueden ofrecer servicios multimedia AAL 

ofreciendo soluciones dependientes de contexto y personalizadas a los usuarios.  

2.5.3.1 Sistemascontext‐aware

Particularizando  los  sistemas  sobre  context‐aware  realizados  en  el  marco  de  la  arquitectura IMS,  Kim  et.al.  [64]  presenta  un  servicio  habilitador  (enabler)  que 

gestiona el contexto en redes IMS considerando variables como el dispositivo, la red, 

el usuario, la posición y la movilidad.  

Según muestra la arquitectura del enabler desarrollado en la Figura 17, el componente  “Interface” recoge la información basada en el perfil del usuario o del dispositivo que  esté utilizando cuando se invoca un servicio. Después, el módulo “Data Transformer”  se encarga de transformar la información recibida en un lenguaje adecuado (Ontology  Web Language  ‐ OWL) para su procesamiento. Así “Query Engine” realiza consultas  sobre  la información  expresada  en  OWL  para  que en  “Reasoning  Engine”  estas  consultas sean sometidas a las reglas de razonamiento provistas en “Rule Manager”.  Finalmente,  el  módulo  “Generator”  es  el  encargado  de  dar  instrucciones  a  las  funcionalidades del enabler en función de la información de contexto inferida. 

Figura 17 Arquitectura de enabler context‐aware [64] 

Siguiendo con la implementación de sistemas context‐aware en IMS, Moon et.al. [104]  propone una plataforma de gestión de conocimiento de alto nivel con la finalidad de  ofrecer a terceros proveedores la creación de servicios personalizados considerando el  contexto del usuario. Esta plataforma se enmarca en una capa de conocimiento que se  sitúa entre la capa de control y la capa de aplicación. La plataforma se divide en dos  niveles en el que la capa de bajo nivel hace referencia al perfil, las preferencias y el  contexto de una entidad (usuario, dispositivo, red o servicio); mientras que la capa  superior contiene los componentes que procesan e infieren información de contexto a  a partir de estas entidades. La red de conocimiento anterior se basa en una ontología  compuesta  por  10  clases  (usuario,  preferencia,  grupo,  red,  dispositivo,  servicio,  localización, actividad, agenda y presencia) así como relaciones ente ellas que se  muestra en las siguientes figuras (Figura 18).  

Figura 18 Ontología de la red de conocimiento y clases “user” y “device” [104] 

El trabajo presentado en [57] muestra un framework soportado a través de las NGNs  para gestionar e integrar la información de contexto procedente de diversas fuentes y  ofrecerla a aplicaciones de cliente de una manera transparente. Tal y como muestra 

Figura 19, el núcleo del sistema, conocido como enabler de contexto se localiza dentro  de un operador de red y está compuesto por 3 sub‐módulos: un gestor de contexto  (context  manager),  una  base  de  datos  de  contexto  (context  database)  y  una  inteligencia de contexto (context intelligence). El “gestor de contexto” centraliza todas  las operaciones relacionadas con recoger y proveer la información procedente de las  fuentes  de  contexto.  La  “base  de  datos”  únicamente  almacena  información  de  contexto, mientras que la “inteligencia de contexto” aplica a través de una ontología  reglas de inferencia de conocimiento sobre los datos existentes. 

Figura 19 Framework de gestión de contexto [57] 

Las experiencias revisadas en IMS relacionadas con el soporte a servicios context  awareness se centran en el desarrollo de un servicio enabler de contexto que gestiona  la  información  procedente  de  los  distintos  dispositivos  y  redes  que  ofrecen  información del usuario a servicios de terceros de manera estructurada. La única  solución que expone una ontología desplegada en IMS realiza una aproximación muy  breve del perfil del usuario. Esto implica que dicha ontología sea poco robusta para la  provisión de servicios AAL ya que estos servicios contemplan múltiples factores del  usuario. Por tanto es necesario desplegar una ontología especifica mediante el servicio  de presencia que ofrece IMS que ofrezca un completo perfil de usuario servicios de  terceros que quieran particularizar sus funcionalidades dependiendo de la información  del usuario conectado a la red IMS. 

2.5.3.2 ServiciosAAL

En relación a los objetivos de AAL, la asistencia socio‐sanitaria se debería trasladar al 

entorno  del  paciente  (e.g.  domicilio,  lugar  de  trabajo,  etc.)  para  mejorar  sus 

condiciones y su autonomía. Para este fin, la comunicación y la participación de las  personas mayores en los servicios AAL se promovería en cualquier escenario y sobre  cualquier dispositivo gracias a la convergencia fijo‐móvil ofrecida por IMS [105][106].  Además, IMS permitiría establecer un framework de colaboración donde se fomentara 

la interacción entre personas mayores pudiendo compartir experiencias a través de  una comunicación multimedia enriquecida [108] [107]. Aparte de estos beneficios para  los usuarios mayores, los operadores de red pueden actuar como nuevos stakeholders  en el marco de provisión de servicios AAL empleando IMS para ofrecer servicios de  valor añadido y mecanismos fáciles de desarrollo para terceros proveedores. 

En  particular,  el  éxito  de  una  solución  de  teleasistencia  depende  del  nivel  de  compromiso existente con la necesidad real de cada actor involucrado en el modelo de  cuidado (pacientes, médicos y cuidadores), así como de la fiabilidad del sistema. Los  servicios más relevantes para los usuarios son aquellos que ofrecen información de la  condición de la persona, destacándose para cada grupo de actores los siguientes  servicios [109]: 

 Personas  mayores:  servicios  que  ofrecen  la  posibilidad  de  una  consulta  o  evaluación instantánea por parte de un profesional, así como la monitorización  física o la videoconferencia. 

 Cuidadores (formales e informales): videoconferencia, telemonitorización del  paciente, coordinación y acceso a otros servicios médicos y sociales. 

 Proveedores  de  servicios  sanitarios:  videoconferencia,  historia  médica  electrónica, e interacción con otros proveedores. 

Una de las principales características de un servicio de teleasistencia visto desde un  punto técnico es la fiabilidad, siendo un requisito indispensable para estos servicios  una buena calidad de servicio QoS. Además, resulta óptimo que el usuario pueda  acceder a los servicios desde diferentes puntos tanto fijos como móviles. De esta  manera, IMS suponen una opción tecnológica adecuada para el soporte del núcleo de  una plataforma de teleasistencia. Varios autores presentan como los beneficios de la  convergencia de red‐servicios‐dispositivos así como la provisión de servicio ubicua y  transparente que ofrece IMS pueden ser un elemento clave para establecer una  plataforma de teleasistencia.  

Así, los autores de [109] proponen la creación de un backbone basado en IMS para la  provisión de servicios de teleasistencia tales como: monitorización de parámetros  vitales; servicios de interacción social (videconferencia) para mantener el contacto con  amigos y familiares; y servicios de inteligencia ambiental y domótica. Esta plataforma  ha sido utilizada en proyectos tales como AmiVital [110] y CAALYX [111]. La plataforma  se asiente sobre una arquitectura IMs sobre la que se proveen los servicios. De manera  similar, el proyecto Minerva presentado en [112] se emplea la arquitectura IMS para  construir un sistema global de cuidado que permita realizar tareas de monitorización,  supervisión en tiempo real de los pacientes desde el centro médico, y modificación de  historias clínicas, notificación de citas, y ejecución de protocolos de emergencia. 

En el caso del trabajo presentado por Von Lubitz et.al. [113] se muestra la utilización  de una arquitectura IMS para  ofrecer soporte a  una red  colaborativa  global  de 

información sanitaria (Worlwide Healthcare Information Grid  ‐ WHIG). IMS actúa de  backbone para  conectar todos los  componentes  que  componen  dicha red:  EHRs  (Electronic Healthcare Records), data warehouses, sistemas de soporte a la decisión,  servicios de formación, dispositivos médicos, sistemas de información médica, etc.  Como ejemplo práctico, se ha empleado esta red para la gestión de catástrofes en  áreas  subdesarrolladas.  De  manera  similar,  los  autores  de  [114]  aprovechan  las  capacidades de IMS sobre las redes móviles para crear un sistema multi‐colaborativo 

de  telemedicina móvil para establecer comunicaciones entre el personal de una 

ambulancia y los médicos especialistas de un hospital remoto. 

Aprovechando las ventajas sobre calidad de servicios (QoS) que ofrece IMS, varios  sistemas de e‐salud proponen IMS como soporte de sus servicios multimedia. Por  ejemplo, el proyecto OTELO ofrece un servicio médico de tele‐ecografía robótica que  supone un servicio de valor añadido al operador de red móvil [115]. Carugi et. al. [95]  propone las capacidades de movilidad que ofrece IMS como soporte a la telemedicina 

móvil habilitando una comunicación continua en las diversas redes de acceso que se 

atraviesan en una atención de emergencia. Estas comunicaciones requieren de un  servicio de alta prioridad y una adecuada calidad de servicio (QoS). Varios tipos de  datos (audio, video, imágenes) son coordinados para proporcionar el ancho de banda  necesario para monitorizar los datos vitales del paciente.  

Lin et.al. [116] propone la utilización de los servicios habilitadores de IMS push‐to‐talk  y localización para la gestión de situaciones de emergencia, donde estos servicios se  encargan  respectivamente  del  procesamiento  de  llamadas  de  emergencia  y  la  localización del usuario que ha efectuado la llamada. En la línea del soporte a servicios  de emergencia a través de la utilización de IMS, los autores de [117] proponen una  aproximación a nivel de aplicación para mejorar la cobertura y la disponibilidad de los  servicios de emergencia. La arquitectura IMS utilizada emplea un nuevo componente  perteneciente al núcleo de IMS denominado E‐CSCF y que se encarga de gestionar  sesiones  de  emergencia.  De  manera  similar,  Politis  et.al.  [118]  presentan  un  framework  para  gestión  de  emergencias  basado en  IMS  que  permita establecer  comunicaciones  seguras  en  caso  de  emergencia  extremos  (ataques  terroristas,  catástrofes naturales, etc.) y ofrecer servicios centralizados tales como VoIP entre los  actores involucrados. 

Aparte de estas contribuciones, la mayoría de las experiencias de IMS en el campo de  las aplicaciones AAL están dirigidas al desarrollo de aplicaciones context‐aware a  través de la combinación del servicio de presencia de IMS y de la información de 

monitorización extraída de sensores que ofrecen información de parámetros vitales. 

Concretamente, Barachi et.al. [119] [120] [121] propone la interconexión de redes de  sensores con redes IMS para ofrecer al usuario servicios personalizados y adaptados a  la información del contexto (condiciones físicas y/o ambientales) monitorizado por los  sensores. Para ello emplea el servicio de presencia que permite enviar información de 

presencia del usuario a distintas aplicaciones. Como ejemplo en el campo de los  servicios  AAL,  el  autor  propone  la  atención  y  monitorización  de  pacientes  con  patología  cardíaca  para  gestionar  episodios  de  posible  ataque  cardíaco  que son  atendidos avisando a la ambulancia más cercana a la localización del paciente. Para la  inclusión de la información proporcionada por los sensores se propone la utilización de  los formatos PIDF [122], RPID [123] y GEOPRIV [124] a través del servicio de presencia  como muestra la Figura 20. 

Figura 20: Arquitectura IMS para servicios context‐aware [119] 

De manera similar, Arbanowski et.al. [125] propone la utilización de IMS para facilitar  la  integración, gestión y  orquestación de  nuevas  redes  de sensores inalámbricos  (zigbee, bluetooth, rfid) con servicios de redes de área personal (PAN‐ Personal Area  Networks).  Adicionalmente,  las  redes  de  próxima  generación  ofrecen  en  Dijkstra  et.al.[126]  una  serie  de  servicios  habilitadores  dentro  de  un  servicio  de 

telemonitorización de pacientes con problemas cardíacos que permiten contactar con 

una  red  de  profesionales  sanitarios  de  manera  dinámica  en  función  de  su  disponibilidad, localización o competencias.  

 En la línea de integración de redes de sensores con la arquitectura IMS, Rikitake et.  al.  [127]  justifica  la  adopción  de  IMS  para  el  desarrollo  de  un  sistema  de 

monitorización domiciliaria debido a las características de "transferencia en tiempo  real”, “notificación de eventos” y “gestión de datos” que provee la arquitectura. Para  la monitorización de parámetros vitales tales como el ECG y transferencia en tiempo  real se emplea el servidor XDMS y servidores de aplicación mostrados en la Figura 22.  La notificación de evento es empleada para avisar a un paciente crónico de ciertas  acciones de monitorización que debe llevar a cabo; y por último la “gestión de datos”  permite  poder  registrar  de  manera  diaria  todos  los  datos  monitorizados.  Adicionalmente, Domingo et.al. [128] propone un avance integrando los dos ámbitos  anteriores junto  con  redes  sociales  para ofrecer  aplicaciones  personalizadas  que  exploten el  conocimiento  asociado al  individuo. Así la  arquitectura propuesta se  muestra en la siguiente Figura 21 donde se refleja la particularidad en la conexión de  las redes de sensores con un dispositivo (smartphone, tablets, etc.) que hace de  pasarela con la red IMS. De igual manera se detalla la capa de servicio donde se  proveerán aquellas aplicaciones personalizadas y servicios habilitadores o enablers  (presencia, gestión de grupos) que harán uso de la información recogida por los 

sensores a través del servicio de presencia que permite también subscribirse a la  presencia de un cierto usuario. Por último la pasarela IMS Web 2.0 interconecta la red  IMS  con  las redes  sociales desplegadas en la  web  2.0,  pudiendo acceder  a  sus  contenidos.  

Figura 21: Integración de redes de sensores con IMS 

[128] 

Figura 22: Sistema de monitorización domiciliaria 

basado en IMS [127] 

Siguiendo con la provisión de servicios context‐awarenes soportados por las redes de  nueva generación, el proyecto AWARENESS [129] utiliza la arquitectura de red IMS  para crear una red orientada al soporte de la movilidad basada en contexto. Esta  infraestructura de red combinada con redes de sensores de área corporal (BAN)  permite ofrecer aplicaciones AAL para el tratamiento a distancia de pacientes con  dolor crónico y para la telemonitorización de crisis epilécticas. 

Todos los trabajos revisados anteriormente emplean los beneficios que proporciona   IMS en la construcción de una plataforma de servicios AAL aprovechando la gestión de  calidad QoS, el control  de  la  sesión  multimedia,  el  soporte a  la  movilidad  y  la  independencia  de  la  capa  de  transporte  y  servicio.  Además  aquellas  soluciones  dedicadas a la extracción de información de monitorización de los sensores utilizan el  servicio  de  presencia  de  IMS  para  el  envío  de  información  a  los  servicios  de  emergencia. Por el contrario, ninguno de estos trabajos plantea la construcción de  servicios habilitadores que apoyen las funcionalidades del servicio AAL soportado por  la arquitectura IMS. En la presente tesis doctoral se propone la creación de nuevos  servicios  enablers  para  el  soporte  de  las  funcionalidades  de  una  aplicación  de 

teleconsulta que no puede ser cubierta con los enablers existentes en el estado del  arte de IMS.