UNIVERSIDAD POLITÉCNICA SALESIANA, SEDE CUENCA
CARRERA DE INGENIERÍA ELECTRÓNICA
Trabajo de titulación previo a la obtención del título de Ingeniero Electrónico
PROYECTO TÉCNICO: “DISEÑO DE UNA INFRAESTRUCTURA DE TELECOMUNICACIONES PARA LA TRANSMISIÓN DE SIGNOS VITALES DE PACIENTES EN LA ZONA URBANA DE LA CIUDAD DE CUENCA”
Autor: David Homero Chandy Pesántez Tutor: Ing. Ángel Soto S. Mg. T. Co-Tutora: Ing. Mónica Karel Huerta Ph.D.
CUENCA – ECUADOR 2016
CESIÓN DE DERECHOS DE AUTOR
Yo, David Homero Chandy Pesántez, con documento de identificación No 0104844956, manifiesto mi voluntad y cedo a la Universidad Politécnica Salesiana la titularidad sobre los derechos patrimoniales en virtud de que soy autor del trabajo de grado intitulado: “Diseño de una Infraestructura de Telecomunicaciones para la Transmisión de Signos Vitales de Pacientes en la Zona Urbana de la Ciudad de Cuenca”, mismo que ha sido desarrollado para optar por el título de: Ingeniero Electrónico, en la Universidad Politécnica Salesiana, quedando la Universidad facultada para ejercer plenamente los derechos cedidos anteriormente. En aplicación a lo determinado en la Ley de Propiedad Intelectual, en mi condición de autor me reservo los derechos morales de la obra antes citada. En concordancia, suscribo este documento en el momento que hago entrega del trabajo final en formato impreso y digital a la Biblioteca de la Universidad Politécnica Salesiana.
Cuenca, 30 de Junio de 2016
David Homero Chandy Pesántez CI: 0104844956
CERTIFICACIÓN
Yo, declaro que bajo mi tutoría fue desarrollado el trabajo de titulación: “DISEÑO DE UNA INFRAESTRUCTURA DE TELECOMUNICACIONES PARA LA TRANSMISIÓN DE SIGNOS VITALES DE PACIENTES EN LA ZONA URBANA DE LA CIUDAD DE CUENCA”, realizado por David Homero Chandy Pesántez, obteniendo el Proyecto Técnico que cumple con todos los requisitos estipulados por la Universidad Politécnica Salesiana para ser considerado como Trabajo de Titulación. Cuenca, 30 de Junio del 2016
CI: 1103455802
DECLARATORIA DE RESPONSABILIDAD
Yo David Homero Chandy Pesántez, con documento de identificación No 0104844956, autor de “Diseño de una Infraestructura de Telecomunicaciones para la Transmisión de Signos Vitales de Pacientes en la Zona Urbana de la Ciudad de Cuenca”, certifico que el total contenido de este Proyecto Técnico es de mi exclusiva responsabilidad y autoría.
Cuenca, 30 de Junio de 2016
David Homero Chandy Pesántez CI: 0104844956
AGRADECIMIENTO
Quiero expresar mi más sincero agradecimiento a mi tutor de proyecto técnico Mg.T Ing. Angel Soto por ayudarme en el proceso de realización del presente trabajo de investigación. Al Grupo de Investigación de Telecomunicaciones (GITEL) encabezado por el Dr. Ing. Jack Bravo Torres, por la acogida brindada y los conocimientos compartidos.
Quiero hacer un extensivo agradecimiento a la Dra. Mónica Karel Huerta Investigadora del Proyecto Prometeo, quien con su gran experiencia y consejos ha sabido guiar acertadamente las distintas etapas de desarrollo de este proyecto de grado.
Quiero agradecer a una gran persona, que con sus palabras de aliento ha sabido levantarme al ánimo para seguir adelante, gracias por estar ahí todo este tiempo, gracias Victoria.
David H. Chandy P.
DEDICATORIA
Este trabajo de grado lo dedico a mis padres, personas nobles y de gran corazón, que supieron apoyarme incondicionalmente durante todo este camino. De ustedes he aprendido que las limitaciones solo están en nuestra mente, que los obstáculos no son más que pruebas a ser superadas y que con sacrificio todo se puede lograr. Les admiro Mélida y Segundo, gracias por todo. David H. Chandy P.
RESUMEN De acuerdo a los reportes estadísticos del Sistema Integrado de Seguridad ECU 911 Austro, los incidentes relacionados a la salud se han incrementado año tras año junto con el número de incidentes de tránsito. En este contexto, la calidad de la atención pre-hospitalaria y la coordinación oportuna de los diferentes actores de la red de salud pública, juegan un papel muy importante al momento de conservar la vida de un paciente. Con estos antecedentes, se propone la integración de la tecnología en escenarios de emergencia, como una herramienta que permita mejorar los tiempos de respuesta, monitorear remotamente el estado del paciente e incluso realizar video-consultas entre el sitio del incidente y personal médico ubicado en determinado centro de salud. En este proyecto técnico se propone el diseño de una infraestructura de telecomunicaciones que permita el envío y recepción de señales biomédicas de pacientes que son trasladados en vehículos de emergencia. El proceso de diseño empieza con el estudio del estado del arte sobre las tecnologías y sistemas relacionados a la telemedicina móvil. Luego se analizan las características de las señales biomédicas, en términos de periodicidad en la transmisión de datos, ancho de banda requerido, priorización, tasa de muestreo y almacenamiento. Una vez definidos los parámetros de las señales biomédicas se analizó los tipos de tecnologías de acceso inalámbrico que permitan la transmisión de datos en escenarios con vehículos en movimiento en zonas urbanas. De este análisis se obtiene que las redes celulares de tercera y cuarta generación (UMTS-LTE) se postulan como el medio de transmisión idóneo para el envío de señales biomédicas en esta clase de escenarios, por el considerable ancho de banda del enlace ascendente, la interoperabilidad con redes de tercera generación y por el nivel de cobertura en la ciudad de Cuenca. También se defninen los parámetros de calidad de servicio en términos de latencia máxima y porcentaje de pérdida de paquetes que la red debe proveer a los diferentes servicios de telemedicina, así como, su infraestructura lógica, infraestructura física y los dispositivos de red que lo componen. Finalmente se evalúa el desempeño de la red 4G para el flujo de datos en el enlace uplink, a través del software NS-3. Los resultados muestran que el rendimiento de la red disminuye cuando se incrementa el tráfico generado por otros usuarios o al incrementar la tasa de datos del flujo de información de las ambulancias. Adicionalmente se evidenció que el rendimiento de la red puede mejorar sustancialmente, al incrementar los recursos de radio o ancho de banda del canal.
i
Índice general
1 Estado del arte y análisis estadístico.
1
1.1
Tecnologías de sensores en el sitio de la emergencia . . . . . . . . . .
1
1.2
Tecnologías de telecomunicación entre unidad móvil de emergencia y centro de operaciones remoto . . . . . . . . . . . . . . . . . . . . . .
4
Tecnologías de procesamiento y gestión de la información en casos de emergencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Análisis estadístico de incidentes reportados al ECU 911 Austro . . .
9
1.3
1.4
2 Revisión de Normativas para el Manejo de Datos Médicos
15
2.1
Protocolo de Atención Prehospitalaria . . . . . . . . . . . . . . . . .
15
2.2
Registro de Atención Prehospitalaria . . . . . . . . . . . . . . . . . .
17
2.3
Registro de Atención Hospitalaria . . . . . . . . . . . . . . . . . . .
19
2.4
Protocolos de Transferencia de Información . . . . . . . . . . . . . .
20
2.4.1
Técnica SBAR - SAER . . . . . . . . . . . . . . . . . . . . .
21
Sistemas de Comunicación en los Servicios de Emergencia . . . . . .
22
2.5
3 Identificación y Determinación de Bio-señales 3.1
25
Señales Biomédicas y Signos Vitales . . . . . . . . . . . . . . . . . .
25
3.1.1
Temperatura Corporal . . . . . . . . . . . . . . . . . . . . .
26
3.1.2
Tasa de Pulsaciones . . . . . . . . . . . . . . . . . . . . . . .
26
3.1.3
Frecuencia Respiratoria . . . . . . . . . . . . . . . . . . . .
26
ii
3.1.4
Presión Sanguínea . . . . . . . . . . . . . . . . . . . . . . .
27
3.1.5
Saturación de Oxígeno . . . . . . . . . . . . . . . . . . . . .
27
3.1.6
Electrocardiograma . . . . . . . . . . . . . . . . . . . . . . .
28
3.1.7
Nivel de Glucosa . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2
Propiedades y Características de Señales Biomédicas . . . . . . . . .
29
3.3
Definición de Parámetros y Características . . . . . . . . . . . . . . .
33
4 Diseño de la Red de Telemedicina 4.1
4.2
4.3
36
Plataforma Tecnológica del SIS ECU 911 Austro . . . . . . . . . . .
36
4.1.1
Sistema de Monitoreo por Video-Vigilancia . . . . . . . . . .
36
4.1.2
Arquitectura de Red del SIS ECU 911 Austro . . . . . . . . .
37
4.1.3
Prototipo del Sistema de Telemedicina del SIS ECU 911 Austro 38
Determinación y distribución de usuarios y sus elementos dentro del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.2.1
Usuario y Elementos en Ambulancia . . . . . . . . . . . . . .
41
4.2.2
Usuario y Elementos en SIS ECU 911 Austro . . . . . . . . .
42
Determinación de la Red de Acceso . . . . . . . . . . . . . . . . . .
44
4.3.1
Análisis de las tecnologías inalámbricas para telemedicina . .
44
4.3.2
Análisis de las redes de acceso MAN y WAN en la ciudad de Cuenca . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.3.2.1
Operadora Otecel S.A (Movistar). . . . . . . . . . .
46
4.3.2.2
Operadora CNT E.P. . . . . . . . . . . . . . . . . .
47
4.3.2.3
Operadora Conecel S.A. (Claro) . . . . . . . . . .
48
4.3.2.4
Operadora ETAPA E.P. . . . . . . . . . . . . . . .
50
4.3.2.5
Ancho de Banda de las Redes de Acceso . . . . . .
50
Estudio de la Arquitectura de la Red de Acceso . . . . . . . .
53
4.3.3
iii
4.3.3.1
Arquitectura LTE . . . . . . . . . . . . . . . . . .
53
Parámetros de la red de acceso . . . . . . . . . . . . . . . . .
58
4.3.4.1
Banda de Frecuencia LTE en el Ecuador . . . . . .
58
4.3.4.2
Calidad del Servicio (QoS) . . . . . . . . . . . . .
60
4.3.4.3
Tecnologías de Acceso Múltiple y Ancho de Banda en LTE . . . . . . . . . . . . . . . . . . . . . . . .
63
4.3.4.4
Schedulers o Agendadores . . . . . . . . . . . . .
65
4.3.4.5
Modelo de Propagación . . . . . . . . . . . . . . .
67
Diseño de la Infraestructura Lógica de la Red . . . . . . . . . . . . .
68
4.4.1
Seguridad de la Red de Telemedicina . . . . . . . . . . . . .
71
Diseño de la Topología Física de la Red . . . . . . . . . . . . . . . .
73
4.5.1
75
4.3.4
4.4
4.5
Selección de dispositivos del sistema. . . . . . . . . . . . . .
5 Simulaciones y Análisis de Resultados 5.1
81
Softwares de Simulación . . . . . . . . . . . . . . . . . . . . . . . .
81
5.1.1
NS-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.1.1.1
LENA LTE/EPC Module . . . . . . . . . . . . . .
82
SUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.2
Trazas de movilidad . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
5.3
Simulación NS-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.3.1
Escenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.3.2
Escenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
Análisis de Resultados . . . . . . . . . . . . . . . . . . . . . . . . .
92
5.4.1
Análisis de Resultados de Escenario 1 . . . . . . . . . . . . .
92
5.4.2
Análisis de Resultados de Escenario 2 . . . . . . . . . . . . .
96
5.1.2
5.4
6 Conclusiones Y Recomendaciones
102 iv
6.1
Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2
Recomendaciones y Trabajo Futuro . . . . . . . . . . . . . . . . . . 103
Bibliografía
104
Anexo 1
110
Anexo 2
111
Anexo 3
112
Anexo 4
115
v
Índice de figuras 1.1
Porcentaje de Incidentes Registrados por el ECU 911 Austro . . . . .
10
1.2
Incidentes Policiales . . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.3
Incidentes de Tránsito . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.4
Incidentes de Salud . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.5
Incidentes Bomberos . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4.1
Sistema de video vigilancia SIS ECU 911 Austro . . . . . . . . . . .
37
4.2
Topología IT del SIS ECU 911 Austro . . . . . . . . . . . . . . . . .
38
4.3
Diagrama General del Proyecto de Telemedicina del SIS ECU 911 Austro 39
4.4
Presentación del aplicativo móvil del proyecto de Telemedicina del SIS ECU 911 Austro . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.5
Mapa del Cantón Cuenca . . . . . . . . . . . . . . . . . . . . . . . .
41
4.6
Elementos del usuario ambulancia . . . . . . . . . . . . . . . . . . .
42
4.7
Ubicación SIS ECU 911 Austro . . . . . . . . . . . . . . . . . . . .
43
4.8
Elementos del usuario SIS ECU 911 Austro . . . . . . . . . . . . . .
43
4.9
Redes de Acceso Inalámbrico [40] . . . . . . . . . . . . . . . . . . .
46
4.10 Mapa de Cobertura 4G de la Operadora Otecel en la Ciudad de Cuenca
47
4.11 Mapa de Calidad de la Señal 3G de la Operadora Otecel en la Ciudad de Cuenca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.12 Mapa de Cobertura 4G de la operadora CNT E.P. en la ciudad de Cuenca. 48
vi
4.13 Mapa de Cobertura 3.5G de la operadora CNT E.P. en la ciudad de Cuenca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.14 Mapa de Calidad de Señal 4G de la Operadora Conecel de la ciudad de Cuenca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.15 Mapa de Calidad de la Señal 3G de la Operadora Conecel en la Ciudad de Cuenca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.16 Localización de las Estaciones Base WiMax Movil en la Ciudad de Cuenca [41] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.17 Evolved Packet System [42] . . . . . . . . . . . . . . . . . . . . . .
54
4.18 Separación Funcional entre EPC y E-UTRAN [42] . . . . . . . . . .
54
4.19 Arquitectura E-UTRAN [42] . . . . . . . . . . . . . . . . . . . . . .
56
4.20 Arquitectura de Interoperabilidad de la red LTE con UMTS [42] . . .
58
4.21 Bandas de Frecuencia para la Tecnología LTE en el Ecuador. . . . . .
59
4.22 Canalización Adicional en la Banda de 1900 MHz. . . . . . . . . . .
59
4.23 Representación de una Señal OFDM [43] . . . . . . . . . . . . . . .
63
4.24 Comparación de OFDMA y SC-FDMA al transmitir símbolos QPSK [43] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
4.25 Modelos de propagación y datos medidos en el área urbana. [47] . . .
68
4.26 Infraestructura Lógica de la Red de Telemedicina . . . . . . . . . . .
69
4.27 Infraestructura Lógica de la red 4G . . . . . . . . . . . . . . . . . . .
70
4.28 VPN IPSec para la red de Telemedicina . . . . . . . . . . . . . . . .
72
4.29 Disposición Física de Equipos en Ambulancia . . . . . . . . . . . . .
74
4.30 Topología Física de la Red de Telemedicina . . . . . . . . . . . . . .
75
4.31 4G/3G Wireless Router TP-Link TL-MR3420 . . . . . . . . . . . . .
77
4.32 VPN Cisco RW110W . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4.33 Monitor de Signos Vitales Infinium - Omni Express . . . . . . . . . .
79
4.34 Pantalla Touchscreen Gechic On-Lap1002 . . . . . . . . . . . . . . .
79
vii
5.1
Modelo de Simulación LENA LTE-EPC . . . . . . . . . . . . . . . .
83
5.2
Interfaz Gráfica SUMO . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.3
Análisis de Emergencias de Tránsito Reportadas Cantón Cuenca Periodo Enero 2014 - Septiembre 2015 . . . . . . . . . . . . . . . . . . .
86
5.4
Area para simulación de movilidad de ambulancias . . . . . . . . . .
86
5.5
Entorno de JOSM para Edición de Mapa OpenStreetMap . . . . . . .
87
5.6
Visualización de simulación de movilidad en SUMO-GUI (Tiempo=10s). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.7
Visualización de simulación de movilidad en SUMO-GUI (Tiempo=45s) 89
5.8
Ubicación de Radio Base UAZ_POLITE_SALESIANA Operadora Otecel S.A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
RSRP - Modelo de Propagación COST 231 . . . . . . . . . . . . . .
93
5.10 RSRP - Modelo de Propagación Log Distance . . . . . . . . . . . . .
94
5.11 RSRP - Modelo de Propagación Friis . . . . . . . . . . . . . . . . . .
94
5.12 Throughput Promedio Escenario 2 (BW = 5 MHz) . . . . . . . . . . .
97
5.13 Retardo Promedio Escenario 2 (BW = 5 MHz) . . . . . . . . . . . . .
98
5.14 Tasa de Pérdida de Paquetes Escenario 2 (BW= 5 MHz) . . . . . . . .
99
5.9
5.15 Throughput Promedio Escenario 2 (BR: 1.024 Mbps) . . . . . . . . . 100 5.16 Retardo Promedio Escenario 2 (BR: 1.024 Mbps) . . . . . . . . . . . 100 5.17 Tasa de Pérdida de Paquetes Escenario 2 (BR: 1.024 Mbps) . . . . . . 101
viii
Índice de Tablas 1.1
Incidentes Registrados en el Servicio Integrado de Seguridad ECU 911 Austro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1
Características del Terminal Móvil de Radiocomunicación [26]
. . .
23
2.2
Características del Terminal Portátil de Radiocomunicación [27] . . .
23
2.3
Características del Terminal Portátil del sistema troncalizado del MSP [28] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.1
Señales a ser transferidas desde el sitio y sus prioridades. [17] . . . .
30
3.2
Requerimientos Típicos de Ancho de Banda para Bioseñales [9] . . .
31
3.3
Frecuencia de Muestreo y Tamaño de Datos para Signos Vitales [36] .
31
3.4
Características relevantes para la transmisión de señales biomédicas del equipo HeartStart MRx® [35] . . . . . . . . . . . . . . . . . . . . . .
32
Requerimiento de Almecenamiento Estimado al usar el equipo HeartStart MRx® [37] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.6
Prioridad y periodicidad de las señales biomédicas . . . . . . . . . .
34
3.7
Características de muestreo para la transmisión de señales biomédicas
34
4.1
Tecnologías Inalámbricas para Aplicaciones de Telemedicina Móvil [39] 44
4.2
Características de los Servicios de Telemedicina Móvil [39] . . . . . .
45
4.3
Ancho de Banda de las Redes de Acceso en la Ciudad de Cuenca . . .
51
4.4
QCIs Estandarizados para LTE [42] . . . . . . . . . . . . . . . . . .
62
4.5
Configuración de Ancho de Banda de canal LTE . . . . . . . . . . . .
65
3.5
ix
4.6
Parámetros de política de fase 1 ISAKMP . . . . . . . . . . . . . . .
72
4.7
Parámetros de política de fase 2 IPsec . . . . . . . . . . . . . . . . .
73
4.8
Adaptadores 3G/4G - WLAN/LAN . . . . . . . . . . . . . . . . . . .
77
4.9
Routers VPN Inalámbricos . . . . . . . . . . . . . . . . . . . . . . .
78
5.1
Parámetros de Simulación SUMO . . . . . . . . . . . . . . . . . . .
88
5.2
Parámetros de Simulación Escenario 1 . . . . . . . . . . . . . . . . .
91
5.3
Distribución de Usuarios para el Escenario de Simulación 2 . . . . . .
91
5.4
Parámetros de Simulación Escenario 2 . . . . . . . . . . . . . . . . .
92
5.5
Desempeño de la Red LTE - Modelo de Propagación COST231 . . . .
95
5.6
Desempeño de la Red LTE - Modelo de Propagación Log Distance . .
96
5.7
Desempeño de la Red LTE - Modelo de Propagación Friis . . . . . .
96
x
Capítulo 1 Estado del arte y análisis estadístico. Las tecnologías de la información y comunicación empleadas en los servicios médicos de emergencia son muy diversas. Con el objeto de brindar una descripción adecuada, se propone exponer las TICs de acuerdo al siguiente orden: 1. Tecnologías de sensores en el sitio de la emergencia. 2. Tecnologías de telecomunicación entre unidad móvil de emergencia y centro de operaciones remoto. 3. Tecnologías de procesamiento y gestión de la información en casos de emergencia.
1.1 Tecnologías de sensores en el sitio de la emergencia Las tecnologías de sensores in situ, hace referencia a los dispositivos electrónicos utilizados para la adquisición de datos biomédicos, redes de sensores inalambricas, redes de area corporal, etc., en el lugar de la emergencia. El proyecto CodeBlue [1] desarrollado en la universidad de Harvard, propone una infraestructura integral de comunicaciones para sensores médicos inalámbricos, en ambientes de cuidado crítico y emergencia. El diseño contempla los procesos de enrutamiento, designación, exploración y seguridad a ser aplicados en la comunicación de los sensores, PCs, tablets, y otros elementos para el monitoreo del estado de los pacientes. El establecimiento de la red, se lo realiza de forma ad hoc, ya que en principio no se depende de una infraestructura de comunicaciones externa. Esto permite que la comunicación entre los nodos sea versátil y flexible. El proyecto incentiva el desarrollo de 1
nuevos algoritmos de protocolos de enrutamiento para priorizar el tráfico en casos críticos, así como a la investigación de nuevas técnicas de criptografía para el uso eficiente de los recursos computacionales embebidos en un dispositivo-sensor y al desarrollo de software que permita la fácil integración de los dispositivos inalámbricos. En [2], Suganthi et al., desarrolla un dispositivo electrónico que procesa señales de sensores conectados al paciente y envía mensajes de texto, mediante la red GSM/GPRS, al detectar alteraciones en los datos biológicos del mismo. La unidad tiene como núcleo un microcontrolador PIC (Peripheral Interface Controller) que realiza la lectura de los diversos sensores, la lectura de coordenadas del módulo GPS, el envío/recepción de mensajes de texto y el establecimiento de una llamada de voz a los servicios de emergencia. El proyecto tiene un enfoque social al proveer un módulo de bajo costo y con conectividad a redes de altos índices de penetración. En [3], Chao et al., propone la incorporación de un módulo interactivo multimedia para el envío de datos de audio y video, además de la información biomédica. El sistema está compuesto básicamente por una red de sensores inalámbricos que recopilan las señales biológicas y una cámara inalámbrica. Tanto la información biomédica y multimedia son transmitidas hacia receptores independientes ubicados en la ambulancia; esto, para asegurar el ancho de banda requerido por los datos de audio y video. Los receptores sirven al mismo tiempo de gateways para transmitir la información hacia el centro de emergencias. Una de las limitaciones del proyecto propuesto por Chao et al., es el ancho de banda de uplink de la red CDMA1x, con máximos de 30 kbps, requeriéndose estrategias de prioridad de datos, implementación de buffers, redundancia de disponibilidad de canal, compresión de video, etc., para hacer frente a esta particularidad. Dentro de las aplicaciones de telemedicina, la video-conferencia es una de las más empleadas, ya que brinda una comunicación visual y auditiva directa entre médico y paciente. Es así que, en un entorno de emergencia médica la visualización en tiempo real del estado del paciente por parte del especialista, es de gran ayuda en el tratamiento pre-hospitalario. En este contexto, Corradini et al. [4], propone un sistema de transmisión de audio y video en tiempo real desde la emergencia hacia un servidor cloud, donde personal especializado realizará la evaluación del incidente e indicará el proceso a seguir. El sistema utiliza una tarjeta Raspberry Pi B+, que es un micro-computador con varios puertos para conexión de periféricos. En este caso un sensor de video es anexado a la tarjeta y mediante el protocolo RTMP (Real Time Messagging Protocol) se realiza el envío de la trama de datos hacia la plataforma de servicios cloud de Amazon EC2. A través de los servicios que ofrece Amazon EC2, el médico o personal de emergencias puede seguir las incidencias en el lugar de la emergencia, en su navegador web. Complementariamente, se realizan pruebas para medir la latencia entre la
2
imagen capturada y visualizada. Al incrementar las cuadros por segundo tanto como la resolución, se incrementa considerablemente el tiempo de llegada de datos. Un proyecto similiar desarrollado por Butean et al. [5], utiliza los servicios cloud de Microsoft Azure, orientado al monitoreo de datos biomédicos en tiempo real. Mediante el desarrollo de un entorno web, el personal médico, enfermeras e incluso familiares pueden acceder a la información del paciente. Respecto a las tecnologías de radio que usan los sensores y equipo médico dentro de la red que se forma en un escenario de emergencia, Tingting et al. [6], propone la utilización de la tecnología UWB (Ultra Wide Band), como un medio eficaz y seguro de comunicación. A través del ajuste de parámetros del equema de modulacion FMDCSK (Frequency Modulated - Differential Chaos Shift Keying), se logra reducir sustancialmente la tasa de error de bit al incrementar la tasa de transmisión de paquetes, y mantiene constante la tasa de error de bit al incrementarse la distancia entre transmisor y receptor. Estos resultados muestran la robustes y fiabilidad de la propuesta, indispensables en entornos de emergencia. En cuanto a la conectividad en una red se sensores inalámbricos, Wei et al. [7], propone la conformación de comunidades de routers-sensores en donde la cooperación y coordinación autónoma de todos los miembros es necesaria para asegurar el envío de la información de emergencia en tiempo real. Los sensores se conectan y envian información al router mas cercano, los routers a su vez reciben información de los sensores, procesan su información y por medio de otros routers envían la información a estaciones de monitoreo. Cada router es una unidad autónoma y se encarga de establecer la comunicación con los demas routers, formando redes tipo mesh. Al detectarse un estado de emergencia en un nodo, el algoritmo propuesto clasifica los routers que formarán la ruta principal de la conexión y los routers que formarán la ruta de barrera que protegerá el envío de la información, en caso de fallo de la ruta principal. En este mismo contexto, Khelil et al. [8], propone un nuevo esquema de comunicaciones Pa2Pa (Patient to Patient), el cual pondera autonomicamente el nivel de urgencia de un paciente o grupo de pacientes, sin el criterio o presencia de personal médico y en la ausencia de una infraestructura de red. En primera instancia se establece una red de sensores de área corporal BAN (Body Area Network), que recolectará los datos del paciente. Cada red BAN se comunica con otras, mediante una red ad-hoc wireless, formando un cloudlet (unidad pequeña de computo en la nube). El cloudlet cuenta con los recursos de computación de cada nodo, en un entorno distribuido, para el enrutamiento y procesamiento de los datos de cada paciente.
3
1.2 Tecnologías de telecomunicación entre unidad móvil de emergencia y centro de operaciones remoto En esta sección se da a conocer los diferentes avances que se han desarrollado respecto de las tecnologías que permiten la comunicación entre la unidad movil de emergencias y el centro coordinador o centro de atención médica remoto. Las redes de acceso inalámbricas, empleadas en aplicaciones de telemedicina, deben ser estudiadas considerando los siguientes criterios [9]: disponibilidad de red, confidencialidad de la información, latencia en la entrega de datos y aprovisionamiento de QoS (Quality of Service). Este último término hace referencia a la capacidad de la red para establecer prioridades de tráfico o garantizar cierto nivel de desempeño, para determinadas aplicaciones, a través de la modificación de KPIs (Key Performance Indicators) en la infraestructura de red del operador móvil. Zvikhachevskaya et al. estudia el esquema handoff, como uno de los factores que pueden incidir en la implementación de QoS. La probabilidad de bloqueo de una llamada está directamente relacionada al tipo de esquema handoff utilizado en el despliegue de red. Existen dos tipos de esquemas: priorizados y no-priorizados. Los primeros reservan, estiman y comparten los recursos de radio de acuerdo al tipo de tráfico que requiera cierta prioridad y los segundos transfieren la conexión, solo mientras exista canales de radio disponibles. Los autores integran un parámetro umbral como mecanismo de reserva de ancho de banda en un esquema priorizado durante la transmisión de datos de emergencia. Mediante simulaciones se demuestra que, cuanto mayor es el ancho de banda asignado a cierto servicio, menor es la probabilidad de bloqueo de su conexión en entornos de alta congestión de usuarios. En este mismo contexto, Challita et al. [10] analiza los algoritmos scheduling que administran y optimizan los recursos de radiofrecuencia en la red Wimax, como mecanismo para la implementación de QoS, en este tipo de tecnología. Dentro de los datos que se envían en una red de telemedicina no solo el tipo de tráfico (datos ECG, pulsos por minuto, temperatura, video, etc) debería definir los requerimientos de QoS, sino también su nivel de emergencia. Este parámetro no es considerado en el diseño de los algoritmos de uso frecuente, como round-robin (todos contra todos), encolamiento equitativo ponderado o incluso aquellos diseñados específicamente para Wimax, como: mSIR (maximum Signal to Interference Ratio), TRS (Temporary Removal Scheduler), EDF (Earliest Deadline First), entre otros. Challita et al. propone la integración de un nivel que pondere la criticidad de la emergencia para determinado servicio, dentro de la rutina de un protocolo de scheduling. Para la implementación se realizan pruebas de simulación con diferentes esquemas, obteniendose el mejor throughput de la red al integrar 4
la criticidad con el algoritmo round-robin. Este método permite compartir la máxima capacidad de canal a todos los solicitantes con un tasa de transmisión proporcional al nivel de emergencia. La calidad de la videoconferencia y la rapidez de transmisión de datos e imágenes de alta resolución, son piezas claves al momento de la toma de decisiones en ambientes de emergencia, donde la atención adecuada y un acertado diagnóstico médico son fundamentales para salvar la vida de un paciente. En este contexto, Lam et al. [11] analiza desempeño del estandar de comunicaciones inalámbricas IEEE 802.16, más conocido como WiMax, al transmitir datos de audio y video en tiempo real. La calidad de la información está directamente relacionada con el tipo de compresión de audio y vídeo. Los estándares de compresión de vídeo H.261, H.263 y H.264 son analizados, siendo el códec H.264 el más opcionado, por su alta eficiencia al comparar la calidad de video y las bajas tasas de datos que emplea para su transmisión. También se estudia los diversos estándares de compresión de audio, tales como G.722, G.711 y GSM 06.10. Mediante la implementación de un modelo probabilístico para el análisis de pérdida de paquetes y el empleo del estándar H.264 en un software de simulación, se estudia el desempeño de Wimax al variar la tasa de transmisión de los datos de video con cada uno de los codecs de audio antes descritos. Se obtiene que el throughput de la red es lineal a medida que se incrementa la tasa de transmisión de video. Respecto a la tasa de pérdida de paquetes, ésta se mantiene baja y estable hasta la velocidad de 380 kbps de transmisión de video. Al superar esta barrera, se evidencia un crecimiento de la tasa pero con diferentes pendientes, dependiendo del códec de audio utilizado. Los estándares G.722 y G.711, tienen un compartamiento similiar, al generar la menor tasa de pérdidas durante la transmisión conjunta de audio y video. En los párrafos que preceden, se ha estudiado el uso y optimización de Wimax como medio de transmisión para la información médica en situaciones de emergencia. Existen otras tecnologías que brindan igual o mejor desempeño al momento de transmitir datos biomédicos. Entre ellas se encuentra LTE (Long Term Evolution), catalogada como la tecnología de cuarta generación de telefonía móvil. El despliegue de la red LTE es ya una realidad en muchos países de latinoamérica y el mundo. Por lo que el estudio de su desempeño y optimización en aplicaciones de telemedicina es uno de los temas de gran interés en la comunidad científica en la actualidad. Rehman et al. [12], analiza el desempeño de la red 4G y el uso de femtoceldas para el streaming de video en ambientes indoor y vehiculos en movimiento (ambulancias). Una femtocelda, es una estación base reducida en tamaño y potencia, que permite mejorar cuantitativamente la cobertura de la red movil en escenarios indoor. Rehman et al propone la incorporación de una femtocelda al interior de una ambulancia, con el pro-
5
pósito de mejorar la relación señal a ruido, interferencia co-canal, multiple-handover, entre otros factores, propios de un vehículo en movimiento. Esto permite la implementación de QoS al momento de transmitir datos de vídeo en tiempo real. Los KPIs (Key Performance Indicators) analizados son el througput, retardo y tasa de pérdida de paquetes. Se configuran dos ambientes de simulación, el primero cuando se envian datos directamente a un eNodeB (estación base que provee el servicio LTE) o escenario macrocelda y el segundo a través de una femtocelda conectada a un eNodeB, en adelante mencionado como escenario femto. La datos de vídeo son enviados a una tasa de 128 kbps, utilizando el códec de compresión H.264 y en formato YUV. Los resultados muestran que la tasa de pérdida de paquetes en el escenario macrocelda supera en 10 puntos porcentuales el umbral aceptable para la transmisión de video, en cambio el usar femtoceldas la tasa de pérdidas es muy cercana a cero. En cuanto al throughput se observa que al utilizar femtoceldas la velocidad de la red es mayor en comparación al escenario de macroceldas cuando los canales son compartidos por otros usuarios que acceden al mismo tiempo a la red. El retardo de la red al usar femtoceldas es mucho menor en comparación del escenario de macrocelda ya que se evita la retrasmisión de paquetes por pérdidas en la propagación. Respecto a los protocolos que se utilizan para el envío de información médica en situaciones de emergencia, Sakthi et al. [13] desarrolla un protocolo fiable basado en AODV (Ad hoc On- demand Distance Vector) para el envío de paquetes que transmite mensajes de emergencia con los signos vitales del paciente a través de una MWN (Multihop Wireless Network). El protocolo usa el modo de transmisión anycast para establecer la ruta mas cercana entre el nodo origen y el nodo destino. Si la ruta original se avería, el protocolo automaticamente encuentra la ruta hacia el nodo gateway más cercano. El algoritmo busca la nueva ruta basado en el último salto válido, permitiendo mejorar la latencia respecto a una red en configuración unicast o multicast, que reconstruyen la ruta desde el nodo origen. Los resultados en simulaciones demuestran que el uso de anycast ayuda a disminuir significativamente el tráfico overhead generado por el protocolo AODV e incrementa la tasa de paquetes enviados-recibidos. La integración de redes inalámbricas heterogéneas como un medio de transmisión confiable para aplicaciones de tele-salud, es el paradigma en el cual se basa la propuesta de Brodziak et al. [14]. Los datos del paciente y la información multimedia generada son procesados por un conjunto de protocolos que colectan, optimizan, priorizan y transmiten los datos hasta la central de emergencias. Los datos de la capa de aplicación son encapsulados como tráfico IP y mediante un estimador de enlace junto con un buffer de priorización se realiza la distribución de paquetes de acuerdo a las condiciones de transmisión, disponibilidad de red y tipo de aplicación. La integridad y seguridad de los datos se garantiza por medio de la encriptación con algoritmos robustos al establecer 6
una VPN (Virtual Private Network) para la comunicación de los datos. Se realizan evaluaciones de campo, mediante pruebas de ping con cada operador móvil por separado y con el operador virtual propuesto. Este último alcanza el 99.4 % de disponibilidad del servicio, superando el 95% logrado por el segundo mejor, confirmando su alto desempeño y robustes.
1.3 Tecnologías de procesamiento y gestión de la información en casos de emergencia. En este apartado se da a conocer los diferentes sistemas de información y aplicaciones que se han desarrollado para la gestion de la información del paciente pre-hospitalario y datos relacionados a la emergencia en el lugar del incidente. Hauenstein et al. [15], diseña e implementa una arquitectura de software orientada al servicio para el intercambio de información entre varios organismos de respuesta. La arquitectura se basa en los siguientes criterios: 1) Diseño de un modelo de datos óptimo que habilite la compartición entre diversos tipos de información de fuentes diversas. 2) Diseño de un estándar para el intercambio de datos con el modelo propuesto. 3) Diseño de un portal de servicios web, en donde se mostrará la información orientada a tres tipos de usuarios: personal médico, coordinadores del centro de operaciones y personal de emergencia. La información a ser compartida proviene de sistemas ya desarrollados, lo más relevantes son: red de sensores de monitoreo de pacientes pre-hospitalarios desarrollado en el proyecto CodeBlue [1], información del sistema de vigilancia y reporte de incidentes SIRP (Surveillance and Incident Reporting Pda), sistema usado por los paramédicos para el ingreso de información del paciente mediante un PDA (Personal Digital Assistant). La implementación se lleva a cabo en la plataforma AID-N (Advanced Health and Disaster Aid Network), en donde se investigan tecnologías que habilitan la interoperabilidad de múltiples organismos de respuesta de emergencias, en la región metropolitana de Washington DC, EEUU. Un proyecto similar es desarrollado en la plataforma Med-on-@ix [16] que investiga el uso fiable de las TIC’s en el tratamiento pre-hospitalario del servicio de emergencias alemán. Protogerakis et al. [17], propone un sistema de comunicación entre el personal médico de emergencias en el sitio del incidente, un centro de coordinador de operaciones y un centro de salud remoto. La infraestructura de hardware comprende, entre otros, una unidad de comunicación, que adquiere, procesa y envía datos, mediante múltiples redes de acceso hacia el centro de operaciones. La arquitectura de software se abstrae en tres capas: capa de aplicación, capa de sesión y capa de red/transporte. 7
La capa de aplicación encapsula los dispositivos médicos e información de otros sensores en la unidad móvil de rescate como tambíen los clientes y servidores en el centro de operaciones remoto. La capa de sesión acondiciona los datos considerando niveles de prioridad, velocidad de transmisión y nivel de emergencia. La capa de red utiliza tuneles encriptados VPN a través de varias tecnologías de transmisión formando una sola interfaz virtual. Los protocolos TCP y RTP son usados en la capa de transporte ya que presentan mayor robustes frente a UDP al momento de reordenar paquetes. TCP es utilizado para la transmisión de información sensible y de precisión y UDP en aplicaciones de streaming de audio y video. El uso de elementos de la infraestructura core de un operador movil en la gestión de emergencias es analizado en [18]. Meng-Hsun et al., estudia un conjunto de APIs desarrollados por el consorcio Parlay X, que permiten la implementación de servicios Web utilizando funcionalidades del IMS (Ip Multimedia Sub-system) de una red celular, como SMS/MMS, CSCF (Call Session Control Functions) y GMLC (Gateway Mobile Location Center). La plataforma de servicios Parlay X consta de un gateway el cual habilita la comunicación entre el IMS y las aplicaciones desarrolladas para el servicio de emergencia. Adicionalmente cuenta con un servidor que almacena el estado de determinado usuario o dispositivo en una base de registros de suscriptores y un servidor XML para la gestión de ficheros acoplado a un sistema de notificaciones de voz basado en el protocolo SIP. Meng-Hsun et al. desarrolla un sistema piloto llamado “ALLSurvive” empleando las Parlay X API’s, para un escenario de alerta de tsunami luego de un terremoto en las costas de Japón donde el centro de alertas del pacífico envía una notificación de emergencia a la aplicación con la ubicación geográfica del seísmo y a través de una consulta al servidor de localización de móviles, se calcula los usuarios/dispositivos que se encuentran en un radio de 100 km, a los cuales se envia un SMS con la información de alerta y puntos de evacuación. En [19] Hameed et al., propone un modelo integrado de servicios médicos de emergencia, a través del desarrollo de una base de datos interactiva en la que hospitales, centros de emergencia y centros de atención primaria pueden acceder a los registros del paciente e intercambiar, administrar y colaborar en la gestión de la información. Los usuarios pueden ingresar al sistema para acceder o proveer información médica de acuerdo a los privilegios asignados por el administrador. Este último es el encargado de registrar la información relacionada al centro de salud y su respectivo staff médico. El personal médico es el encargado de crear el usuario-paciente con su respectiva información clínica. La implementación del modelo se realiza mediante el uso de lenguajes PHP y MYSQL, para el entorno web y base de datos respectivamente. Hidayat et al. [20], propone un sistema de referencias online para el servicio médico de
8
emergencias mediante el uso de smartphones y tecnologías de computación en la nube. El ecosistema de actores que se involucran en el diseño está conformado por los pacientes, usuarios en el centros de salud primario y usuarios en los hospitales. La aplicación cuenta con las siguientes características: 1) Menú de referencia donde el personal médico puede ingresar los datos requeridos para el traslado de un paciente desde el centro de salud hacia un hospital o entre hospitales, así como consultar la disponibilidad de especialistas y/o camas disponibles del hospital a referenciar. 2) Menú de búsqueda del nombre del hospital a referir con la ayuda de texto predictivo, mejorando los tiempos de respuesta en casos de emergencia, gracias a la base de datos dinámica ubicada en la plataforma de computación en la nube. 3) Mapa de ubicación geográfica en tiempo real de las ambulancias que se aproximan al hospital, transportando al paciente referido. El sistema propuesto reduce en un 90% el tiempo que se emplea para referir a un paciente comparado con un sistema tradicional papel-voz. Un trabajo similar propuesto por Freitas et al. [21], plantea la implementación de una registro electrónico para el manejo de datos pre-hospitalarios en las ambulancias del sistema de emergencias de Riberão Preto, Brasil. El objetivo primordial es permitir al profesional de salud el registro/recopilación de datos del paciente en al ambiente de cuidados pre-hospitalarios y enviar la información para la continuidad de la atención médica en el hospital. El proceso de desarrollo contempla en primera instancia la contrucción de un formato óptimo de registro electrónico médico, que permita el fácil acceso de la información en un ambiente de emergencias. Posteriormente, el diseño de una aplicación basada en Android usando Java, XML (eXtensible Markup Language) y SQL (Structured Query Language) para el almacenamiento en una base de datos temporal en el dispositivo móvil. Los datos generados por la aplicación son enviados al servidor web central mediante Wi-Fi. En caso de no disponer este medio de transmisión, la aplicación almacena el registro en la base de datos del móvil temporalmente y sincronizará la información con la base de datos centralizada tan pronto se habilite una nueva conexión al servidor central. La movilidad del usuario (personal médico) involucra la interoperabilidad de diferentes dispositivos que acceden simultáneamente al mismo servidor web, característica solventada por el uso del protocolo SOAP (Simple Object Access Protocol) en su implementación.
1.4 Análisis estadístico de incidentes reportados al ECU 911 Austro El Servicio Integrado de Seguridad ECU-911 es un proyecto que integra a las instituciones de socorro en una plataforma tecnológica al servicio de los 22 cantones de las 9
provincias de Azuay y Cañar para la atención inmediata, eficiente de casos de emergencia. A continuación se realiza un análisis estadístico sobre el número y tipo de incidentes que se han reportado al ECU 911 Austro. Tabla 1.1: Incidentes Registrados en el Servicio Integrado de Seguridad ECU 911 Austro Año
Policía
Tránsito
Salud
Bomberos
Municipal
Militar
Gestión de Riesgo
Total
2012
43250
9873
12316
4540
702
18
158
70857
2013
120330
29763
24026
5674
4231
47
293
184364
2014
120077
30403
29371
4622
3260
1808
389
189930
2015
59951
14608
15812
2180
2583
882
200
96216
Total
343608
84647
81525
17016
10776
2755
1040
541367
En la Tabla 1.1 se muestra un resumen de los datos obtenidos en el reporte estadístico publicado por el ECU 911 [22]. De acuerdo a la naturaleza de los incidentes estos son clasificados en siete clases: policial, tránsito, salud, bomberos, municipales, militar y gestión de riesgo. De estos eventos los que se reportan con mayor frecuencia son los de tipo policial, tránsito, salud y bomberos los cuales representan el 97.31% del total registrado, seguidos en menor cantidad por los de tipo municipal, militar y gestión de riesgo como se muestra en la Figura 1.1
Figura 1.1: Porcentaje de Incidentes Registrados por el ECU 911 Austro
A continuación se realiza el análisis de los cuatro incidentes que se presentan con mayor frecuencia, en periodos anuales, considerando el primer mes a mayo de determinado año y el doceavo mes a abril del siguiente. Esta apreciación se aplica en los periodos 2012-2013, 2013-2014 y 2014-2015. 10
Figura 1.2: Incidentes Policiales
En la Figura 1.2 se muestra el comportamiento de los incidentes de tipo policial. En el primer periodo, los datos experimentan una tasa promedio de crecimiento mensual del 22%, entre el primer y octavo mes, ya que inicialmente la cuidadanía no utilizaba o desconocía el número único de emergencias 911. A medida que el sistema se consolidaba, el número de incidentes se estabilizó alrededor de 10000 reportes mensuales aproximadamente. En los periodos consecutivos, las gráficas exhiben un patrón muy similiar, identificándose máximos comunes en los meses de mayo y diciembre, así como mínimos en enero y agosto. De igual manera el promedio mensual de registros por incidentes policiales en los dos últimos periodos es muy similir, con una desviación estandar del +/- 6.97% al +/- 6.7%, respectivamente. En cuanto a los incidentes de tránsito, los datos del primer periodo tienen un comportamiento diferenciado respecto a los datos del segundo y tercer período, como se observa en la Figura 1.3. El primer año presenta una tasa de crecimiento mensual del 35%, por el proceso de consolidación antes mencionado. El segundo y tercer año, los datos muestran un comportamiento similar, con máximos claramente identificables en mayo y diciembre, así como mínimos en febrero y agosto. La media de incidentes mensuales de los dos últimos periodos es de 2547 y 2515 eventos, con una desviación estándar de +/- 8.5% a +/- 9.1%, respectivamente.
11
Figura 1.3: Incidentes de Tránsito
Los incidentes clasificados como salud (Figura 1.4), difieren de los datos analizados en los párrafos anteriores. Las curvas obtenidas en cada periodo tienen una forma similar, pero no se traslapan ya que las cifras que describen las mismas se incrementan cada año. Esto se evidencia también en el promedio creiente de incidentes obtenidos en cada periodo: 1627.25 en el primero, 2174.75 en el segundo y 2553.41 en el tercero. Lo que significa que cada año es mayor el número de enfermedades y/o problemas de salud que requieren de atención emergente. Respecto a la desviación estandar, los valores obtenidos reflejan que los incidentes mensuales en cada periodo no varían demasiado respecto de la media, excepto el primer año, cuyo valor es levemente influenciado por el proceso de adaptación del sistema en sus inicios.
12
Figura 1.4: Incidentes de Salud
En la Figura 1.5, se exponen los datos correspondientes a los incidentes relacionados con la actividad bomberil. Por simple observación, se puede deducir que determinados meses exhiben un incremento substancial en sus cifras, como el lapso entre el tercer y sexto mes, donde los datos llegan a sus máximos locales, en los tres periodos. Este incremento inusual en las gráficas se debe en gran medida a la ola de incendios forestales provocados por el hombre en las épocas de sequía. La situación más crítica se presentó en el periodo 2012-2013, llegándose a registrar hasta 1278 incidentes en un mismo mes. La desviación estandar en este periodo refleja el comportamieno atípico, doblando las cifra obtenida en los años consecutivos. En cuanto al promedio de incidentes por mes, se experimenta una reducción progresiva del primer al tercer año, debido a las decisiones tomadas por las auoridades para disminuir este tipo de siniestros. Sin embargo la curva del último periodo, continúa mostrando la particularidad entre el lapso del tercero al sexto mes, pero con una media y una desviación estandar mucho menor que el primer año.
13
Figura 1.5: Incidentes Bomberos
14
Capítulo 2 Revisión de Normativas para el Manejo de Datos Médicos El Ministerio de Salud Pública (MSP) del Ecuador, es el organismo encargado de proveer las diferentes normativas y/o procedimientos a seguir con respecto a la información médica generada en el sistema de salud. De acuerdo a las entrevistas realizadas a personal médico, el primer proceso donde se generan datos médicos en situaciones de emergencia, es durante la atención prehospitalaria que reciben los pacientes o víctimas de determinado incidente. Estos datos son llenados manualmente en un Registro de Atención Prehospitalaria por parte del personal paramédico durante el traslado del paciente desde el lugar del incidente a la casa de salud asignada. Luego, cuando el paciente es ingresado al departamento de emergencias de determinada institución, se genera un Registro Diario Automatizado de Consultas y Atenciones Ambulatorias (también conocido como RDACAA) donde se especifica las diferentes patologías y datos médicos que caracterizan el estado del paciente. Finalmente, si el paciente requiere traslados para atención especializada se cuenta con un Protocolo de Transferencias de Información de Pacientes en Puntos de Transición el cual permite establecer un sistema de referenciación dentro del sistema de salud. A continuación se describirá brevemente las principales características con las que cuenta cada tipo de normativa.
2.1 Protocolo de Atención Prehospitalaria La atención prehospitalaria hace referencia a los cuidados médicos que recibe una persona fuera de las áreas asistenciales del sistema de salud y que son de suma importancia para mantener la vida de la persona. A continuación se da a conocer los diferentes procesos estipulados por el MSP en el documento intitulado Protocolos de Atención 15
Prehospitalaria para Emergencias Médicas [23], donde se detallan los pasos que sigue el personal paramédico en la atención de victimas en situaciones de emergencia. Adicionalmente, con esta descripción, se pretende identificar los diferentes puntos en donde el uso de la tecnología permita que el personal actúe de manera más eficiente en la atención a los pacientes. Los principios generales de atención en emergencia prehospitalaria son: 1. Evaluación de la escena (a) Verificación de la situación para proporcionar seguridad tanto al personal prehospitalario como al paciente. (b) Uso de equipos de protección individual y empleo de medidas de bioseguridad, de acuerdo a los fluidos corporales y/o sustancias quimico-biológicas presentes en el lugar del siniestro. (c) Evaluación de los recursos necesarios para la intervención en la emergencia médica. (d) Activación de la cadena de supervivencia (procedimientos que preservan la vida del paciente mediante la reanimación cardio-pulmonar y el uso de desfibrilador). (e) Acciones de triage (clasificación, rescate y evacuación) en caso de existir múltiples víctimas. 2. Evaluación primaria (a) Verificar la respuesta del paciente a preguntas sencillas. (b) Si el paciente está conciente: aplicar los protocolos de acuerdo a la patología existente. En caso de estar inconciente aplicar lo siguiente (conocido como procedimiento A-B-C-D-E de acuerdo a [23]): i. Aseguramiento de la permeabilidad de las vías respiratorias. ii. Adecuada respiración y ventilación. iii. Verificación del estado circulatorio y control de hemorragias. iv. Determinación de la escala de Glasgow (estado de coma), pupilas y focalidad. v. Protección de la víctima a la hipotermia. (c) En caso de pacientes críticos o de riesgo vital, implementación de procedimientos avanzados que eviten la complicación del mismo, procurando su traslado inmediato. 16
3. Evaluación secundaria (a) Toma de todos los signos vitales. (b) Realización del procedimiento especificado en el punto 2 b (procedimiento A-B-C-D-E) tantas veces como sea posible. (c) Examinación física de la víctima por regiones corporales (de cabeza a pies), para identificación de posibles lesiones. 4. Transporte y registro (a) Comunicación a la central de emergencias del estado y características del paciente. (b) Solicitud de traslado mediante los diferentes tipos de ambulancias de acuerdo a la gravedad del paciente: i. Traslado Simple ii. Transporte Asistencial Básico iii. Transporte Asistencial Avanzado (c) Respetar las políticas de traslado de pacientes hacia las instituciones de salud de acuerdo a la complejidad determinada. (d) Llenado de HCU-002 (Registro de Atención Prehospitalario, Ver Anexo 1) estipulado por el MSP. 5. Entrega y recepción del paciente (a) Entrega del paciente al personal médico notificado por la central de emergencias. (b) Descripción de la situación, evolución y tratamiento del paciente al personal médico. (c) Firma de recepción y entrega de copia de HCU-002 al personal médico.
2.2 Registro de Atención Prehospitalaria Una vez que el personal paramédico logra determinar la condición del paciente, el protocolo de atención prehospitalaria, estipula que se debe llenar un registro, en donde se puedan plasmar las diferentes características y novedades que presenta el paciente; tal como se menciona en el numeral 4, inciso d, de la sección 2.1. El documento HCU002, contiene toda la información de primera instancia sobre la situación del paciente 17
y su evolución desde el momento en que es atendido por el paramédico hasta su arribo al hospital o casa de salud. A continuación se presenta un resumen de las principales partes que consta el documento. • Datos Generales – Registro de datos personales del paciente: nombres y apellidos, cédula, sexo, edad, etc. – Datos informativos sobre la escena: dirección, fecha, hora, etc. • Interrogatorio – Antecedentes del evento, síntomas del paciente, medicamento que recibe, alergias, adicciones, etc. • Examen físico y diagnóstico – En esta sección se describe las posibles lesiones que puede presentar el paciente, así como la permeabilidad de la vía aérea y la presencia de alcohol. – Diagnóstico presuntivo y triage inicial. • Signos Vitales – En este campo se registran los pulsos por minuto, temperatura, presión arterial, frecuencia respiratoria por minuto, escala de coma de glasgow, reacción y dilatación de pupilas. – Estos datos son registrados en tres tiempos: en la escena, durante el transporte y en la entrega del paciente en la casa de salud asignada. • Trauma – Esta sección está dividida en dos partes: en la primera se describen las circunstancias en las que se produjo el trauma en caso de un accidente de tránsito. Y en la segunda parte, el detalle del tipo de heridas, quemaduras, fractura, intoxicación, envenenamiento, etc. • Emergencia gineco-obstétrica y neonatal – En este apartado se especifican los detalles del paciente cuando la causa de la emergencia es un posible parto, aborto o sangrado. • Paro cardio-respiratorio 18
– En esta sección se brinda detalles del paciente cuando se presenta un posible paro cardio-respiratorio, y de las maniobras de resucitación efectuadas por el personal paramédico. • Localización del trauma – En este apartado se da a conocer la localización del trauma en el cuerpo humano, mediante un dibujo del mismo en posición decúbito dorsal y ventral. • Procedimientos – En esta sección se describen las acciones que han sido tomadas por el personal paramédico para proporcionar estabilidad al paciente durante su traslado. • Entrega del Paciente – En este apartado se detalla el personal que entrega y recibe al paciente así como las firmas de descargo y la hora del evento.
2.3 Registro de Atención Hospitalaria Una vez que el paciente es atendido en el departamento de emergencias, los datos médicos del paciente son registrados en un formulario electrónico denominado Registro Diario Automatizado de Consultas y Atenciones Ambulatorias (RDACAA) [24]. En el año 2013 la Dirección Nacional de Estadística implementa este registro mediante dos sofwares: el primero online que incluye los diferentes serivicios y offline que mantiene el físico en una base de datos temporal para luego mediante la utilización de los servicios web integrar la información al Sistema Nacional de Información de Salud (SNIS). El registro se encuentra dividido en cuatro bloques principales: • Bloque A: Datos de la Unidad Operativa – Ubicación de la unidad operativa, lugar de atención y fecha, nombre de la unidad, tipo de unidad. • Bloque B: Datos del Profesional – Este bloque permite obtener información actualizada y general de los profesionales de la salud, en cada una de las unidades operativas. 19
– Campos que se registran en este apartado son: Nombres y apellidos, sexo, fecha de nacimiento, formación profesional o universitaria, especialidad/subespecialidad, nacionalidad, autoidentificación étnica, cédula, codigo del MSP, firma y sello. • Bloque C: Datos del Paciente – La información registrada en este bloque permite el seguimiento a los pacientes a nivel nacional en la Red de Salud Pública con la cédula de ciudadanía y cruzar variables como por ejemplo: morbilidad por sexo, autoidentificación, ubicación de grupos prioritarios por diagnóstico, grupos etarios, etc. – Algunos de los campos que se registran son: apellidos y nombres, cédula, sexo, fecha de nacimiento, nacionalidad, autoidentificación étnica, tipo de afiliación, grupos prioritarios de atención/otros, lugar de residencia habitual, etc. • Bloque D: Datos de Consulta/Atención – Este bloque permite conocer con precisión los diferentes diagnósticos y tipos de atención así como procedimientos y actividades de los profesionales, teniendo como resultados, entre otros, el Perfil epidemiológico de las consultas ambulatorias. – Algunos de los campos que se registran son: códigos de clasificación internacional de enfermedades, diagnóstico, síndrome, morbilidad, prevención, condición del diagnóstico, procedimientos, referencia y contra-referencia, interconsulta, etc.
2.4 Protocolos de Transferencia de Información Un paciente desde que ingresa al servicio de salud, va a ser tratado por una serie de profesionales de la salud en múltiples campos, desde la atención de emergencia, atención quirúrgica, cuidados intensivos y hospitalización. Una adecuada comunicación entre todo el equipo de salud garantiza la seguridad del paciente. Las brechas de comunicación cuando un paciente es tranferido entre departamento por motivos de interconsulta interna o externa a la casa de salud donde se encuentre, pueden provocar graves interrupciones en la continuidad de la atención, un tratamiento inadecuado y un daño potencial para el paciente . 20
La adopción de mecanismos estandarizados de transferencia de información como la técnica SBAR - SAER es ampliamente recomendada por la Organización Mundial de la Salud y ha sido aplicada en algunas instituciones de salud pública del Ecuador como es el caso del Hospital Vicente Corral Moscoso de la ciudad de Cuenca [25].
2.4.1 Técnica SBAR - SAER SBAR es una técnica que facilita la transferencia de información en situaciones complejas, cuando se requiere de atención inmediata o acción. El término SBAR es un acrónimo, que por sus siglas en inglés significa: Situation, Background, Assessment and Recommendation. Traducido al Español: SAER (Situación, Antecedentes, Evaluación y Recomendación). Esta técnica proporciona un formato estructurado con cuatro secciones, asegurando compartir información concisa y focalizada al momento de la transferencia de información de pacientes. Resulta especialmente útil en situaciones críticas en las cuales se requiere una respuesta inmediata. A continuación se detalla brevemente las acciones a seguir en cada sección de esta técnica. Situación En este paso se busca transmitir lo que está pasando con el paciente. Se identifica el cargo de la persona que reporta y el lugar de procedencia del mismo, luego se identifica al paciente por su nombre, cédula, historia clínica y departamento de donde proviene y la razón de la consulta, finalmente se realiza un breve descripción del problema incluyendo signos vitales del paciente. Antecedentes En este paso se define los antecedentes de morbilidad o aquellos de importancia clínica, mediante los siguientes datos recolectados por el personal médico: motivo y fecha de ingreso, datos significativos de la historia clínica, diagnóstico principal, procedimientos realizados, medicación administrada, alergias, resultados de laboratorio y cualquier otra información clínica útil. Evaluación En este paso se describe la evaluación actual del paciente informando la posible causa de la condición del mismo. Se describe los hallazgos en exámenes realizados intentando llegar a alguna conclusión o en su defecto dando paso a la valoración del profesional a quien se transfiere la información. Recomendación En este paso quien entrega la información del paciente debe intentar establecer que es lo que debería hacer dada la situación para llegar a una corrección del problema. Se especifica el pedido, el margen de tiempo, sugerencias y expectativas a seguir en el tratamiento del paciente.
21
En los párrafos anteriores se ha descrito las diferentes técnicas y procedimientos normativos que existen en la localidad para el manejo de datos médicos de los pacientes en el sistema de salud pública del Ecuador. Realizando un análisis a priori de los mismos se puede establecer la importancia que tiene la información de los signos vitales desde la atención prehospitalaria en casos de emergencia, hasta en la aplicación de la técnica SAER para la transferencia de información en puntos de transición. Con estos antecedentes el sistema a diseñarse deberá tener en consideración los diferentes escenarios en donde se genera este tipo de datos. En los siguientes apartados se discutirá más detalladamente las características de los mismos para su adecuada gestión y tratamiento.
2.5 Sistemas de Comunicación en los Servicios de Emergencia Una vez que se ha reportado determinada emergencia al ECU911, los operadores se comunican con el personal de primera respuesta (bomberos, cruz roja, agentes de tránsito, etc) mediante llamada telefónica, para informar la ubicación y características del incidente. Desde el momento en que el personal parte a la escena del siniestro, durante la atención in situ hasta el traslado de los pacientes a la casa de salud asignada, la central de emergencias establece un canal de comunicación constante con el equipo de rescate con el objeto de coordinar todos los procedimientos a seguir en la atención prehospitalaria de los pacientes. Este canal de comunicación está basado en el uso del espectro radio-eléctrico para la transmisión de voz mediante terminales portátiles y móviles de un sistema de radiocomunicación utilizando modulaciones analógicas y/o digitales. A través de este sistema se coordina verbalmente todos los procedimientos entre las diferentes organismos de socorro para el tratamiento, seguimiento y gestión de determinada emergencia. El Hospital del IESS “José Carrasco Arteaga” de la ciudad de Cuenca es una de las instituciones que se articula a los organismos de primera respuesta que coordina el SIS ECU 911 Austro. A continuación se describen los sistemas de comunicación que actualmente poseen las ambulancias de dicha institución. Para la obtención de esta información se realizó un levantamiento de datos mediante la visita a la unidad alfa 2 del departamento de transporte medicalizado del IESS. Mediante una entrevista y visita guiada, se encontró que cada unidad móvil (todas poseen los mismos equipos) cuenta con dos sistemas de radiocomunicación: 1. El primer sistema utiliza frecuencias del espectro radioeléctrico concesionadas 22
por el ente regulador de telecomunicaciones al HJCA (Hospital Jose Carrasco Arteaga). En cada unidad existen dos dispositivos que forman parte de este sistema: (a) Terminal Móvil: Dispositivo empotrable, instalado junto al tablero del conductor en la cabina del vehículo. Este terminal sirve esencialmente para la comunicación de la ubicación del incidente o como backup al terminal del paramédico en casos de no cobertura, ya que maneja más potencia al momento de transmitir. En la Tabla 2.1 se exponen las características técnicas más relevantes del dispositivo. Tabla 2.1: Características del Terminal Móvil de Radiocomunicación [26] Características Marca Modelo Rango de Frecuencia Potencia de Transmisión Modulación
Valores Motorola™ EM400™ VHF/UHF 25 - 45 Watts Analógica/FM
(b) Terminal Portátil: Dispositivo tipo handy que porta el paramédico para la comunicación del estado del paciente, situación de la escena, signos vitales, procedimientos a seguir y otros datos relevantes en el ámbito médico, durante la emergencia. En la Tabla 2.2 se muestran las características del dispositivo. Tabla 2.2: Características del Terminal Portátil de Radiocomunicación [27] Características Marca Modelo Rango de Frecuencia Potencia de Transmisión Modulación
Valores Motorola™ EP450™ VHF / UHF 1 - 5 Watts Analógica
2. El segundo sistema de radiocomunicación pertenece a la red troncalizada del Ministerio de Salud Pública, al cual se integran todos los organismos de rescate de los servicios de emergencia del Azuay. Este dispositivo es utilizado como respaldo al sistema descrito en el punto 1, ya que en determinadas locaciones la cobertura del primer sistema se pierde. En la Tabla 2.3 se muestran las características técnicas de este dispositivo. 23
Tabla 2.3: Características del Terminal Portátil del sistema troncalizado del MSP [28] Características Marca Modelo Rango de Frecuencia Potencia de Transmisión Modulación
Valores Motorola™ XTS® 1500 VHF, UHF, 700/800 MHz 1 - 5 Watts Digital
Adicionalmente, los paramédico comentan que como tercer y último recurso utilizan los celulares personales, en el caso de fallo de los sistemas antes descritos. A manera de conclusión de esta sección, se puede inferir que actualmente el único medio para la transmisión de datos de pacientes (incluidos los signos vitales) desde la atención prehospitalaria hasta el centro asistencial de salud, es a través de un sistema de radiocomunicación del servicio fijo-móvil terrestre. El uso de las tecnologías de la información y redes de nueva generación en este contexto, está supeditado a las capacidades tecnológicas que posea el terminal personal del paramédico y utilizado como “último recurso”.
24
Capítulo 3 Identificación y Determinación de Bio-señales En esta sección se identificarán y determinarán los signos vitales y señales biomédicas de los pacientes en un ambiente de emergencias, así como las características y propiedades para su transmisión y almacenamiento en un sistema de telemedicina.
3.1 Señales Biomédicas y Signos Vitales Una señal es una función de una o varias variables que contiene información. Las señales biológicas son aquellas que se obtienen de un sistema viviente y transmiten información sobre el estado o comportamiento del mismo [29]. Por ejemplo: los registros de temperatura de un paciente, el voltaje proporcionado por un electrodo ubicado en el cuero cabelludo, los patrones espaciales obtenidos por la absorción de rayos x de una tomografía computarizada, etc. Dentro de las señales biomédicas se encuentran los signos vitales, que miden las funciones más básicas del cuerpo humano. De acuerdo a [30] y al registro de atención prehospitalaria, los principales signos vitales monitoreados por los profesionales de la salud son: temperatura corporal, tasa de pulsaciones, tasa de respiración y presión sanguínea. Adicionalmente, los artículos que se citaron en la secciones 1.1, 1.2 y 1.3, mencionan otros datos biomédicos de gran importancia tales como la saturación de oxígeno, nivel de glucosa y electrocardiografía, como procedimientos que permiten mejorar la atención al paciente. En una entrevista con personal paramédico que labora en los servicios de emergencia, se confirmó que los signos vitales y datos biomédicos mencionados anteriormente, son los más usados durante la atención prehospitalaria.
25
A continuación se describe brevemente los signos vitales de acuerdo a lo revisado en [30], así como, la saturación de oxígeno, electrocardiograma y nivel de glucosa.
3.1.1 Temperatura Corporal La temperatura corporal de una persona varía dependiendo del género, actividad realizada, alimentación y consumo de fluidos, hora del día y etapa del ciclo menstrual en mujeres. El rango normal de temperatura se considera entre 36.5°C y 37.2°C para un adulto sano. La forma de obtener esta medición puede ser oral, rectal, axilar, en el oído y en la piel. La temperatura corporal puede considerarse anormal cuando se presenta fiebre (alta temperatura) o hipotermia (baja temperatura). Se considera fiebre cuando la temperatura se incrementa un grado o más sobre los 37°C e hiportermia cuando se encuentra un grado por debajo de los 35°C según la academia americana de medicina familiar.
3.1.2 Tasa de Pulsaciones La tasa de pulsación hace referencia al número de veces que el corazón late por minuto. Las arterias se expanden y contraen con el flujo de sangre que el corazón induce a través de las mismas. El pulso no solo mide los latidos del corazón sino tambíen su ritmo y la fuerza de la pulsación. En adultos saludables el rango normal se encuentra entre 60 a 100 pulsaciones por minuto. Este puede fluctuar e incrementarse con el ejercicio, enfermedades, heridas y emociones. Las féminas sobre los doce años tienden a tener tasas mas aceleradas que los varones. Los atletas y deportistas que hacen bastante ejercicio cardiovascular pueden llegar a tener tasas de 40 pulsaciones por minuto sin ningún tipo de problemas.
3.1.3 Frecuencia Respiratoria La frecuencia respiratoria o tasa de respiración es el número de inhalaciones/exhalaciones que una persona realiza en un minuto. La medición se realiza usualmente cuando la persona se encuentra en reposo realizando el conteo de las veces que el tórax se expande/contrae en un minuto. El número de respiraciones se puede incrementar con la fiebre y otras enfermedades en general. Cuando se verifica la respiración es importante revisar si la persona tiene algún tipo de dificultad en la respiración. Las tasas normales en una persona adulta en reposo varía de 12 a 16 inhalaciones/exhalaciones por minuto.
26
3.1.4 Presión Sanguínea La presión sanguínea hace referencia a la fuerza que la sangre ejerce sobre las paredes de las arterias. Cada vez que el corazón late, éste bombea sangre hacia las arterias, provocando el mayor nivel de presión cada vez que el corazón se contrae. Dos cifras son registradas cuando se mide la presión sanguínea. La más alta o presión sistólica refiere a la presión dentro de la arteria cuando el corazón se contrae y bombea sangre a través del cuerpo. A su vez la de menor valor o presión diastólica hace referencia a la presión dentro de la arteria cuando el corazón está distensionado o en reposo y se llena de sangre. Ambos tipos de presión son registrados en milímetros de mercurio (mmHg). La alta presión sanguínea o hipertensión, hace que las arterias incrementen su resistencia al flujo sanguíneo provocando que el corazón trabaje más fuerte para bombear la sangre a las mismas. Esto incrementa directamente el riesgo de sufrir enfermedades coronarias e infarto cerebral. Se considera presión arterial alta cuando se excede los 140 mmHg de presión sistólica o los 90 mmHg de presión diastólica. Una nueva categoría define la pre-hipertensión a personas que tienen entre 120 y 139 mmHg de presión sistólica o entre 80 y 89 mmHg de presión diastólica. Por lo tanto, una presión arterial saludable se considera cuando las mediciones se encuentran por debajo del umbral inferior de la categoría pre-hipertensiva. Adicionalmente a los signos vitales mencionados en los párrafos anteriores existen otros procedicimientos que permiten profundizar el conocimiento sobre el estado de salud de un paciente. Particularmente en entornos de emergencia es de gran ayuda para el personal médico la obtención de la saturación del oxígeno en la sangre, el electrocardiograma y nivel de glucosa.
3.1.5 Saturación de Oxígeno La saturación de oxígeno en la sangre hace referencia a la calidad de la función respiratoria y la cantidad de oxigeno que la sangre transfiere a los tejidos [31]. Esta medida expresa la cantidad de oxígeno que se combina con la hemoglobina para formar la oxihemoglobina, encargada de transportar el oxígeno a los tejidos a través de la sangre. Cada molécula de hemoglobina tiene cuatro enlaces disponibles a realizar con el oxígeno, el porcentaje de estos enlaces disponibles y los que verdaderamente se encuentran combinados con moléculas de oxígeno es lo que se denomina saturación de oxihemoglobina (SaO2 cuando es medida en sangre arterial y SpO2 cuando se mide en la periferia del cuerpo humano). Los valores típicos de SpO2 están entre 95% y 97% con un rango de variación de +/- 2%. Valores por debajo del 90% se asocian con situaciones patológicas o insuficiencia respiratoria. Este parámetro se puede obtener a través 27
de diversos procedimientos, siendo el óptico el más utilizado ya que no es invasivo y permite una lectura rápida y precisa en cuestión de segundos. Se emplea un emisor de luz a determinada frecuencia cuyos haces atraviesan el dedo y un sensor óptico diametralmente opuesto capta la cantidad de luz que no fue absorbida por la sangre. Esto se debe a que la oxihemoglobina está directamente relacionada con la coloración roja de la sangre y por consiguiente con el nivel de absorción de la luz a determinada longitud de onda.
3.1.6 Electrocardiograma El corazón está formado de músculo (miocardio) el cual se contrae rítmicamente permitiendo la circulación de la sangre a través del cuerpo. Antes de cada pulsación o sístole, una onda de corriente eléctrica pasa a través del corazón permitiendo la contracción del miocardio. El patrón de la propagación eléctrica no es aleatorio, pero se disemina sobre la estructura del corazón de tal manera que permite una efectiva y coordinada sístole. Esto resulta en un cambio de la diferencia de potencial medible en la superficie del cuerpo del individuo. La señal amplificada y filtrada es conocida como electrocardiograma, ECG o EKG. Un gran número de factores pueden influir en el ECG, incluyendo anormalidades en las fibras conductoras del corazón, anormalidades metabólicas (falta de oxígeno o ischemia) del miocardio, e incluso anormalidades macroscopicas relacionadas a la geometría del corazón. El ECG es un procedimieno de rutina en una evaluación médica completa, debido al rol esencial del corazón en la salud humana y a la relativa facilidad de registro y análisis de este procedimiento de una forma no invasiva [32].
3.1.7 Nivel de Glucosa La glucosa es un hidrato de carbono considerado la fuente principal de energía del cuerpo humano. Esta se genera mediante el consumo de alimentos que son metabolizados por el organismo, para luego ser transportados a través de la sangre a las diferentes células del cuerpo [33]. Este proceso es controlado principalmente por la hormona llamada insulina, producida en el páncreas. El nivel de glucosa en la sangre es muy variable ya que obedece a diversos factores como el tipo de actividad, alimentación, medicamentos, estrés, etc. El nivel de glucosa normal para una persona saludable, de acuerdo a [34], se encuentra en el rango de 80 mg/dl a 110 mg/dl cuando se realiza la prueba en ayunas y menor a 125 mg/dl cuando se realiza durante el día. La medición de este parámetro puede ser realizado de manera invasiva y no invasiva, siendo la primera la más común y utilizada. Las técnicas invasivas son llevadas a cabo por equipos elec-
28
trónicos que analizan la sangre previamente extraída del paciente, los cuales mediante procedimientos fotométricos o electroquímicos detectan el comportamiento del fluido corporal al reaccionar con una enzima denominada glucosa oxidasa. Los métodos no invasivos son aquellos que no comprenden la extracción previa de sangre del paciente. Por el contrario, se utilizan técnicas como espectroscopía, fotometría, colorimetría, etc., que no utilizan reacciones químicas para la obtención de los niveles de glucosa, siendo consideradas más cómodas para el paciente.
3.2 Propiedades y Características de Señales Biomédicas En la sección 1.2-1.3, diversos artículos analizan las caracteríticas de las diferentes señales biológicas y signos vitales como un procedimiento previo para determinar las características con las que una red de telemedicina deberá contar. Esto con el objeto de garantizar la gestión eficiente de datos en situaciones de emergencia. Los criterios que se analizan con más recurrencia en [9, 17, 35, 36] son: • Periodicidad en la transmisión de datos. • Ancho de banda requerido. • Priorización. • Tasa de muestreo. • Almacenamiento. Respecto de la periodicidad y prioridad en la transmisión de señales biomédicas, Protogerakis et al. (Tabla 3.1) define estas características, basado en un análisis cooperativo con personal médico. Los autores incluyen la comunicación por voz como una señal adicional, pero de muy alta prioridad, ya que facilita la comunicación en vivo entre el personal médico y paramédico. Los datos de vídeo, así como las imágenes en alta resolución también forman parte de las señales a ser transmitidas pero con prioridades por debajo de las señales biomédicas. Adicionalmente se incluye la transmisión del sonido de un estetoscopio, el cual solo se requeriría en casos aislados. Todas las señales que se presentan en esta figura, excepto las señales de audio y video, son adquiridas mediante un solo dispositivo monitor/desfibrilador, con la capacidad de trasmitir datos en tiempo real a través de la red de telecomunicaciones. 29
Tabla 3.1: Señales a ser transferidas desde el sitio y sus prioridades. [17]
En cuanto a la periodicidad, las señales pueden transmitirse de forma continua o intermitente, dependiendo de los requerimientos médicos y de la naturaleza de la señal. Esto último hace referencia a que ciertas señales biomédicas necesitan un determinado lapso de tiempo para ser obtenidas, lo cual no permite que se puedan transmitir de forma continua. Respecto al ancho de banda requerido para la transmisión de señales biomédicas, éste depende directamente de la tasa de muestreo y la resolución de bits que se empleen para la adquisición de las mismas. En los trabajos realizados por Zvikhachevskaya et al. (Tabla 3.2) y Zubairi et al. (Tabla 3.3) se exponen diferentes criterios al momento de definir el ancho de banda para determinadas señales biomédicas. En la Tabla 3.2 se expone las señales a ser medidas con su respectiva tasa de muestreo o sample rate, resolution o cantidad de bits utilizados para cuantificar las muestras y la tasa de bits resultante. Una de las particularidades que se observa en este planteamiento son los valores atípicos que los autores utilizan para la cuantificación o resolución, comprendiéndose estos entre 12 y 24 bits por muestra.
30
Tabla 3.2: Requerimientos Típicos de Ancho de Banda para Bioseñales [9]
A su vez en la Tabla 3.3 se exponen los criterios del trabajo de Zubairi et al. al momento de elegir la tasa de muestreo, la resolución y por ende el ancho de banda requerido. En este caso, la resolución de bits por muestra se ha normalizado para todas las señales en 16 bits por muestra. Esto permite tener tasas de datos homogénas al momento de asignar slots de tiempo en la transmisión mediante cualquier protocolo que se utilice. Tabla 3.3: Frecuencia de Muestreo y Tamaño de Datos para Signos Vitales [36]
En las Tablas 3.1 y 3.2 se ha descrito las características de las señales biomédicas de propuestas donde se ha requerido la construcción de hardware o se ha simulado la transmisión de la información en una red de telemedicina. Otros proyectos han optado por emplear los recursos que ofrecen equipos electrónicos disponibles en el mercado, como es el caso de Thelen et al [35], en donde el dispositivo HearStart MRx 31
Defibrillator/Monitor® de marca Phillips™, se encarga de la lectura de los signos vitales y de la disponibilidad de los mismos a través de interfaces de comunicación estandarizada. En la Tabla 3.4 se muestran las principales características de transmisión e interfaces que posee el dispositivo. Tabla 3.4: Características relevantes para la transmisión de señales biomédicas del equipo HeartStart MRx® [35]
Un aspecto adicional a tener en cuenta son los requerimientos de almacenamiento de las diferentes señales biomédicas. Cuando se transmiten los datos mediante una red de telemedicina, la cantidad de espacio de almacenamiento depende de la frecuencia con la que se transmita la información y los tipos de datos que se envian a través de la misma. A manera de ejemplificación en la Tabla 3.5 se muestra un aproximado mensual y anual de la capacidad de almacenamiento requerido, que el fabricante estima, al usar el equipo HeartStart MRx® . Tabla 3.5: Requerimiento de Almecenamiento Estimado al usar el equipo HeartStart MRx® [37] Datos
Señales Periódicas Eventos y Señales Periodicas ECG, eventos y señales periodicas
Datos (KByte)
Intervalo
Almacenamiento Anual
Almacenamiento Mensual
5 1 15 3 45 9
1 min 5 min 1 min 5 min 1 min 5 min
2.63 GB 0.53 GB 7.9 GB 1.58 GB 23.65 GB 4.73 GB
0.22 GB 0.04 GB 0.66 GB 0.13 GB 2 GB 0.4 GB
A manera de conclusión de esta sección, se observa que los datos de señales biomédicas a ser transmitidas en una red de telecomunicaciones, especialmente en situaciones de emergencia, deben poseer niveles de prioridad. Esto debido a que ciertas señales,
32
dependiendo el caso del paciente, llevan información clave para un correcto diagnóstico médico, que en ocasiones podría significar la vida del paciente. De esta forma, es imprescindible contar con protocolos que permitan implementar esta particularidad en una red de telecomunicaciones que transmita signos vitales. En este mismo contexto, la optimización de los canales de comunicación se puede llevar a cabo analizando la periodicidad de transmisión de las mismas, ya que ciertas señales pueden requerir solo determinados lapsos de muestreo y otras ser transmitidas constantemente, incrementando la disponibilidad del canal para cuando se requiera transmitir datos vitales en situaciones de emergencia. Respecto del ancho de banda, esto va a depender directamente del hardware que se emplee para recopilar los datos biomédicos, pudiendo ser a través de equipos disponibles en el mercado o mediante equipos que se desarrollen como parte de proyectos de investigación. En los primeros la ventaja esencial es que se encuentran estandarizados y cumplen con normativas internacionales para su uso médico, mientras que su desventaja es que en muchos de los casos la información que llevan es de carácter propietario y se encuentran encriptada, limitando las posibilidades de ser integrados a las redes de información. En cuanto al almacenamiento, al igual que el ancho de banda, éste depende del equipamiento médico que se utilice, por lo que se expuso a manera de ejemplo los requerimientos de un dispositivo disponible en el mercado y tomar sus datos como punto de partida para el diseño en las siguiente secciones.
3.3 Definición de Parámetros y Características Los parámetros y características con los que deberá contar el sistema, se propone en base a los diferentes datos obtenidos en las secciones 3.1 y 3.2. En la Tabla 3.6 se exponen los diferentes señales biomédicas con su respectiva prioridad al momento de realizar la transmisión de datos, siendo la señal de electrocardiograma la que mayor prioridad deberá tener. También se expone la periodicidad de transmisión de los signos vitales, que influirán al momento de definir el modelo y tipo de elementos terminales de la infraestructura de comunicaciones. El tipo de datos que van a ser transmitidos se deben adaptar a las características de la red de telecomunicaciones. En la Tabla 3.7 se exponen la tasa de muestreo, resolución y ancho de banda correspondiente a cada uno de los signos vitales. Como se puede observar, la señal que mayor ancho de banda requiere es el electrocardiograma, la cual influye en el ancho de banda total requerido. Esta cantidad, al sumar todos los valores, es de 8112,256 bps.
33
Tabla 3.6: Prioridad y periodicidad de las señales biomédicas Señal Biomédica
Prioridad
Periodicidad
Electrocardiograma (12 derivaciones) Tasa de Pulsaciones (pulsos por minuto) Presión Sanguínea (mmHg) Saturación de Oxígeno (%) Frecuencia Respiratoria Temperatura Nivel de Glucosa
1 2 3 4 5 6 7
Continua/Tiempo Real Continua Intermitente Continua Intermitente Intermitente Intermitente
Tabla 3.7: Características de muestreo para la transmisión de señales biomédicas Señal Biomédica
Tasa de Muestreo (mps*)
Resolución (bpm**)
Ancho de Banda (bps***)
Electrocardiograma Tasa de Pulsaciones Presión Sanguínea Saturación de Oxígeno Frecuencia Respiratoria Temperatura Nivel de Glucosa
125 - 500 2
16 16 16 16 16 16 16
2 - 8 Kbps 32 bps 32 bps 32 bps 0.128 bpm 16 bps 0.128 bpm
2 2 0.008 (1 muestra/2 min) 1 0.008 (1 muestra/2 min)
* muestras por segundo, ** bits por muestra, *** bits por segundo.
Adicionalmente a este valor se debe considerar, datos propios que los equipos de telemedicina agregan a los signos vitales, tal como se evidencia en la Tabla 3.5. Se puede observar que al trasmitir datos ECG, eventos y señales periódicas estos generan 45 kilobytes de datos. Suponiendo que esta información se genere cada segundo, se requeriría en este caso un ancho de banda de 360 kbps, para su transmisión. Cabe resaltar que esta cifra se genera con todos los dispositivos médicos conectados, datos clínicos del paciente y audio, como se señala en la hoja de especificaciones del equipo. Las características con las que deberá contar el sistema se seleccionan bajo el siguiente escenario: Los datos se generarán en un vehículo que se desplazará desde la casa de salud hacia el lugar del incidente y viceversa, en un ambiente urbano. Por consiguiente las tecnologías que mejor se adaptan a este escenario, son las redes celulares. Esto debido al despliegue de redes 2G, 3G y 4G que ofrecen los operadores móviles en la ciudad. ETAPA E.P., también ha desplegado una red de área metropolitana WiMax, para el servicio de voz y datos. Con estos antecedentes, se puede inferir que la transmisión de datos desde los vehículos de atención pre-hospitalaria hacia el centro de salud, se deberá realizar mediante un módem banda ancha comercializado por cualquiera de los entes antes mencionados. La elección de la tecnología de transmisión se analizará en la sección 5.3 34
Adicionalmente, se debe contar, en el vehículo de atención pre-hospitalaria, con un enrutador/gateway que multiplexe las diferentes señales de los signos vitales mediante la interfaz de comunicación del equipo médico con las señales de voz y vídeo. De acuerdo al estado del arte, estas dos últimas señales son de mucha importancia al momento de requerir tele-consultas, muy frecuentes en situaciones de emergencia. Varios trabajos científicos expuestos en el estado del arte, demuestran que las actuales redes celulares tienen la capacidad de transmitir este tipo de información. Con estos antecedentes se infiere que el throughput de la red deberá satisfacer el envío de las señales biomédicas, datos clínicos del paciente y comunicación voz/video. Finalmente en el centro de atención hospitalaria, se deberá contar con un servidor físico o virtual y base de datos, en donde se procese y almacene la información proveniente desde la unidad móvil de emergencia. Las características del mismo se analizará en la secció 5.3.
35
Capítulo 4 Diseño de la Red de Telemedicina El proceso de diseño consta de los siguientes pasos: 1. Estudio de la plataforma tecnológica del SIS ECU 911 Austro 2. Determinación y distribución del número de usuarios y sus elementos dentro del sistema. 3. Determinación de la red de acceso. 4. Diseño de la infraestructura lógica de la red. 5. Diseño de la topología fisica de la red.
4.1 Plataforma Tecnológica del SIS ECU 911 Austro 4.1.1 Sistema de Monitoreo por Video-Vigilancia El sistema de monitoreo del SIS ECU 911 Austro, está formado por una red de cámaras instaladas en diversas localidades de la ciudad de Cuenca y cantones de la provincia de Azuay y Cañar. Mediante esta red, los operadores de emergencia pueden observar incidentes que se pueden sucitar en los alrededores de su ubicación, como también brindar apoyo visual cuando se llevan a cabo concentraciones masivas de personas, entre otras utilidades. Las cámaras envian la información mediante un enlace de fibra óptica hacia los servidores de gestión ubicados en el centro de operaciones, como se muestra en la Figura 4.1. Los detalles de la topología, tecnologías de transmisión y protocolos usados en este sistema se encuentran protegidos por políticas de privacidad interna de la institución, por lo que no es posible su detalle. 36
Figura 4.1: Sistema de video vigilancia SIS ECU 911 Austro
4.1.2 Arquitectura de Red del SIS ECU 911 Austro Los diferentes actores que se involucrarán al momento de compartir la información de las señales biomédicas requerirán el acceso a un servidor que provea la información enviada desde las unidades móviles de emergencia. Este dispositivo estará ubicado, en un principio, en las instalaciones del SIS ECU 911 Austro, siendo pertinente la descripción general de la topología de red con la que cuenta dicha institución. En la Figura 4.2 se expone el esquema general de la infraestructura de red mediante la cual se brinda el acceso a internet, conectividad interna, servicios tecnológicos, etc. La empresa ETAPA EP, provee el servicio de conexión a internet mediante un enlace dedicado de fibra óptica. Esta conexión llega a un router umbral que distribuye la información a dos sub-sistemas principales. La primera derivación llega a un servidor con funciones proxy/gateway que permite el acceso a la DMZ (siglas en inglés de DeMilitarized Zone) conformada por servidores virtualizados en el centro de datos de la institución. La zona desmilitarizada (DMZ) se refiere a una zona segura que se ubica entre la red interna de una organización y una red externa [38]. En este entorno se implementan diversos servicios web accesibles tanto para la ciudadanía como para uso interno. Dentro de estos servicios se encuentra un aula virtual utilizada para capacitar al personal que labora en el centro de operaciones. La segunda derivación provee de conectividad a la red de área local a través de un sistema de seguridad (cortafuegos - IPS) entre el router y el switch-core de acceso. En cuanto a direcciones IP, la institución cuenta con 5 IP’s públicas arrendadas a la empresa ETAPA EP, las cuales permiten el acceso a los servidores ubicados en el data center desde una red externa. El dispositivo que permite esta conexión es el servidor proxy/gateway, el cual a través de una tradución de puertos, permite a una IP pública acceder a determinado servidor en la DMZ.
37
Figura 4.2: Topología IT del SIS ECU 911 Austro La topología que se muestra en la Figura 4.2 está basada en el modelo de seguridad informática llamado dual firewall (doble cortafuego) en donde se configura un cortafuego tanto para la red privada como para la DMZ. En esta zona se ubican generalmente los servidores web, correo y ftp de una empresa, los cuales representan un fuerte riesgo de pirateo. En este caso el cortafuego de acceso a la DMZ está implementado en un servidor con el sistema operativo ClearOS. Este último hace referencia a una distribución de Linux basada en CentOS utilizada como puerta de enlace y servidor de red con una interfaz de administración basada en web, orientado a la simplificación de las funciones de un servidor para su aplicación en las pequeñas y medianas empresas. El segundo cortafuego que protege la red privada es complementado con un sistema IPS (siglas en inglés de Intrusion Prevention System) de detección de intrusos que constantemente vigila e incorpora mecanismos de análisis de tráfico y sucesos en sistemas operativos y aplicaciones que permite detectar amenazas en tiempo real.
4.1.3 Prototipo del Sistema de Telemedicina del SIS ECU 911 Austro La Dirección Zonal de Operaciones del SIS ECU 911 Austro ha venido desarrollando diversos proyectos de investigación y aplicaciones tecnológicas para mejorar el acceso y atención en la coordinación de los servicios de emergencia, dentro de los cuales están:
38
• Reconocimiento facial mediante cámaras de videovigilancia. • Detección de velocidad de los vehículos mediante cámaras de videovigilancia. • Detección de movimiento y contador de peatones. • Telemedicina: Prototipo para la transmisión de signos vitales. De esta lista de emprendimientos el “Prototipo para la transmisión de signos vitales” está directamente relacionado con la propuesta general de investigación a la cual pertenece este trabajo de tesis, por lo que a partir de esta implementación, se intentará potenciar mediante el diseño de una infraestructura que asegure la conectividad entre los diferentes actores/usuarios finales que involucre el proyecto. Como primer paso, se describe su esquema general de funcionamiento. En la Figura 4.3 se muestra la distribución de los componentes principales del prototipo existente. La configuración de los mismos obedecen a una arquitectura cliente-servidor, en donde el sub-sistema RaspBerry Pi y App Movil se identifican como los clientes y DigitalOcean como arrendatario del servidor. El sub-sistema RaspBerry Pi está compuesto esencialmente, como su nombre lo indica, por el micro-computador RaspBerry Pi B+, un monitor LCD/Touch Liliput con interfaz HDMI, un concentrador/adaptador PIC que lee las señales biomédicas y las convierte en datos seriales y los dispositivos biomédicos conformado por un medidor de presión arterial, contador de pulsos y un medidor de saturación de oxígeno. El lenguaje empleado en el sub-sistema es Python, que adicionalmente incorpora una base de datos MySQL para el manejo de los datos biomédicos.
Figura 4.3: Diagrama General del Proyecto de Telemedicina del SIS ECU 911 Austro
El siguiente elemento que conforma la arquitectura es el servidor implementado en la plataforma DigitalOcean la cual provee servicios de hosting en la nube orientado a desarrolladores. Las características básicas del servidor son: 20 Gb de disco duro, 2 Gb de 39
memoria RAM, 1 Tb de subida y bajada de datos y con sistema operativo Linux/Ubuntu 14.04. El tercer y último elemento hace referencia al aplicativo móvil desarrollado para Android implementado en un smartphone en donde se visualiza los datos almacenados en el servidor. En la Figura 4.4 se puede observar la interfaz principal del aplicativo. Respecto a la transmisión de datos, se emplea un módem 4G de CNT para el enlace entre el sub-sistema RaspBerry y el servidor en la nube, a su vez el aplicativo móvil emplea también su conexión de datos para acceder a la información del servidor.
Figura 4.4: Presentación del aplicativo móvil del proyecto de Telemedicina del SIS ECU 911 Austro
4.2 Determinación y distribución de usuarios y sus elementos dentro del sistema La determinación y distribución de usuarios y elementos del sistema es fundamental al momento de dimensionar una red de telecomunicaciones. Esto permite en primer lugar que los recursos sean escalables en el tiempo y segundo asegurar la disponibilidad del servicio. Adicionalmente nos permite conocer la ubicación espacial de los usuarios, lo cual nos permitirá determinar el tipo de topología a ser empleada, en las siguientes etapas de diseño. A continuación se describe la naturaleza de los principales usuarios y elementos de la red.
40
4.2.1 Usuario y Elementos en Ambulancia El usuario ambulancia contempla todas las unidades móviles de atención pre-hospitalaria que el SIS ECU 911 Austro articula en su centro de operaciones. De acuerdo a información proporcionada por sus directivos, esta cantidad es de 27 unidades en la ciudad de Cuenca y 75 unidades en total considerando las provincias de Azuay y Cañar. La ubicación geográfica de estos usuarios, de acuerdo al alcance de este proyecto comprende solo la zona urbana de la ciudad de Cuenca. En la Figura 4.5, se expone el mapa del cantón Cuenca, en donde se puede identificar las zonas (color negro) que son consideradas urbanas de acuerdo al Plan De Ordenamiento Territorial 2015 del I. Municipio de Cuenca. Los elementos que forman parte de cada unidad de ambulancia se describen a continuación.
Fuente: GAD Cantón Cuenca PDOT 2015.
Figura 4.5: Mapa del Cantón Cuenca
Cada unidad de ambulancia cuenta con un sub-sistema de procesamiento de datos que tiene por objeto la obtención de las señales biomédicas/datos del paciente y su conversión en datos digitales, como se muestra en la Figura 4.6. Este proceso se lleva a cabo mediante el equipamiento médico que se encarga de recolectar la signos vitales/señales 41
biomédicas y un dispositivo Muldimedia Touchscreen, en donde se puede ingresar información adicional sobre el estado del paciente, así como datos clínicos del mismo. Toda esta información es recopilada y procesada en un computador/gateway el cual empaqueta los datos en protocolos del modelo TCP/IP, permitiendo el envío de la información a través de la red propuesta. Adicionalmente, en la Figura 4.6 se expone el flujo de información entre los diferentes bloques de este proceso.
Figura 4.6: Elementos del usuario ambulancia Las saetas que interconectan los bloques indican la dirección de la información, es así que entre el bloque Señales Biomédicas y Equipamiento Médico, esta tiene un solo sentido ya que el proceso es solo de lectura de datos. A su vez, entre el dispositivo Multimedia Touchscreen y Pc/Gateway la comunicación es bidireccional, en cuanto sirve para el envío y recepción de datos, desde la ambulancia hacia el SIS ECU 911 Austro y viceversa. Finalmente, los datos deben ser transmitidos, a través de la red MAN (Metro Access Network), mediante un Módem Banda Ancha (BA). El canal de comunicación entre los bloques 2 y 4 puede ser via Ethernet o Wifi, dependiendo del hardware del Módem BA. Generalmente los dispositivos comercializados por las operadoras cuentan con la implementación de una red Wifi en el mismo dispositivo. El uso de estos módems sería el más apropiado ya que en escenarios de emergencia, es muy probable que el Equipamiento Médico y el Multimedia Touchscreen necesiten ser movilizados fuera de la ambulancia. El tipo de red MAN a la que corresponderá el módem, se analizará en la sección 4.3.
4.2.2 Usuario y Elementos en SIS ECU 911 Austro El usuario SIS ECU 911 Austro, hace referencia al personal que accede a los servicios creados en el/los servidor/es que la institución gestione en su data center, para el monitoreo de los datos provenientes de las ambulancias. La ubicación del/los servidor/es se encuentra dentro del edificio del SIS ECU 911 Austro en la ciudad de Cuenca. En la Figura 4.7 se puede observar la ubicación del edificio institucional en Google Maps. Estos servidores se encuentran ubicados dentro de la zona desmilitarizada del data center que posee el SIS ECU 911 Austro, como se describe en la sección 4.1.2. El acceso 42
al mismo, se realiza a través de un determinado puerto de una dirección IP pública, con la que cuenta la entidad.
Fuente: http://maps.google.com
Figura 4.7: Ubicación SIS ECU 911 Austro
Los elementos que forman parte de este usuario corresponde a la topología de red que dispone la institución. En la Figura 4.8 se puede observar los diferentes bloques que conforman este proceso. El primer bloque corresponde al router de acceso, medio por el cual los datos hacia o desde el Servidor Virtualizado tiene acceso desde la red externa. Esto se logra mediante una dirección IP publica. El segundo bloque hace referencia a un firewall o cortafuegos denominado Clear Os, en donden se implementan los protocolos de seguridad y acceso a la zona desmilitarizada. En esta zona es donde se encontrarán virtualizados los servidores de aplicaciones, web, base de datos, etc.
Figura 4.8: Elementos del usuario SIS ECU 911 Austro
En este primer proceso de diseño se ha descrito los diferentes componentes de cada uno de los usuarios de este sistema, así como su ubicación espacial. En el siguiente proceso se determinará la tecnología que permita la comunicación de estos dos usuarios en la zona urbana de la ciudad de Cuenca.
43
4.3 Determinación de la Red de Acceso Para determinar la red de acceso que dará soporte al sistema de comunicación entre la unidad móvil de emergencia y el centro de operaciones, se va a seguir el siguiente procedimiento: 1. Análisis de las tecnologías inalámbricas para telemedicina. 2. Análisis de las redes de acceso en la ciudad de Cuenca. 3. Estudio de la arquitectura de la red de acceso. 4. Parámetros de la red de acceso.
4.3.1 Análisis de las tecnologías inalámbricas para telemedicina En [39] Batistatos et. al., realiza una recopilación del uso de las tecnologías inalambricas para telemedicina móvil en escenarios de vehículos en movimiento. Dentro de los distintos tipos de tecnologías inalámbricas que se estudian en este artículo están: redes 2G, 3G, 4G, WiMax, VANETS y Radio Cognitiva. En la Tabla 4.1, se puede observar las características que poseen estas tecnologías. Tabla 4.1: Tecnologías Inalámbricas para Aplicaciones de Telemedicina Móvil [39] Tecnología
Ancho de Banda
Movilidad
Cobertura
Complejidad
2G/2.5G (GSM/GPRS)
Bajo
Baja
Rural/Suburbano/Urbano
Baja
3G (UMTS)
Medio
Media
Suburbano/Urbano
Baja
3.5G (LTE, WiMax)
Alto
Media
Suburbano/Urbano
Media
4G (LTE-A,WiMax V2)
Alto
Alta
Rural/Suburbano/Urbano
Alta
VANET
En Investigación
Alta
Urbano
Alta
Radio Cognitiva
En Investigación
En Investigación
Rural/Suburbano/Urbano
Alta
De los datos mostrados en esta tabla, las tecnologías 4G son las que mejor prestación ofrecen respecto del ancho de banda, movilidad y cobertura. Sin embargo su complejidad es alta. Esto debido en gran parte, a la infraestructura y sistemas de procesamiento avanzado que se requieren para brindar altas tasas de transmisión de datos. Es de resaltar la inclusión de las redes vehiculares ad-hoc, las cuales permiten el establecimiento de clusters sin la necesidad de una infraestructura propia. Esto gracias a que cada nodo se comporta como un ente que puede recibir y enrutar información al mismo tiempo. Por otro lado las redes que utilizan radio cognitiva ha llamado mucho la atención de la comunidad científica ya que la misma ve el espectro radio-eléctrico no como una barrera sino como un campo de oportunidades sin explotar. Esta tecnología utiliza sistemas 44
de computo avanzado y redes neuronales que son capaces de predecir el comportamiento de determinado sector del espectro y modificar la frecuencia, diversidad de antena, potencia de transmisión, etc., con el objeto de utilizar el espectro desocupado. Una red de telemedicina móvil debe de proveer diferentes servicios. Estos van desde transferencia de imágenes sin compresión, hasta video-diagnostico de alta calidad. La diferencia existente entre unos y otros son los recursos mínimos red que necesitan para su establecimiento. Estas características son: tasa de datos, retardo maximo y tasa de pérdida de paquetes máxima. Al mismo tiempo estas características son consideradas los limitantes para que determinada red de acceso, pueda o no proveer el servicio indicado. En la Tabla 4.2 se muestran los diferentes servicios de una red telemedicina con sus respectivos requerimientos. Tabla 4.2: Características de los Servicios de Telemedicina Móvil [39] Tipo de Datos
Audio Video
Señales Biomédicas
Archivos
Servicio de Telemedicina
Tasa de Datos
Retardo Máximo
Pérdida de Paquetes (%)
Voz Sonido de Diagnostico Video de Normal Video de Alta Calidad ECG Heart Rate Presión Sanguínea Imagen sin comprimir Imagen ROI Jpeg
4-25 Kbps 32-256 Kbps 0.768-10 Mbps 0.64-5 Mbps 24 Kbps 2-5 Kbps 2-5 Kbps 30-40 Mbytes 15-19 Mbytes
150-400 ms 100-300 ms 150-400 ms 100-300 ms 1s 1s N.A. N.A. N.A.
3 1 1 0 0 0 N.A 0 0
Tomando en cuenta que cuatro de las seis tecnologías expuestas en la Tabla 4.1, corresponden a tecnologías estandarizadas por el 3GPP (3rd Generation Partnership Project), en la Figura 4.9 se exponen las mismas de acuerdo a rango de cobetura y su ancho de banda teóricos. En la Figura 4.9 se puede observar que las redes MAN (Metropolitan Area Networks) y WAN (Wide Area Networks), poseen distancias de cobertura ideales de hasta 50 y 30 Km, respectivamente. Así como anchos de banda cercanos a los 80 y 10 Mbps, respectivamente. Considerando los datos de la Tabla 4.2 y la movilidad de las ambulancias, estos dos tipos de red de acceso serían adecuados para la implementación de nuestro sistema de telemedicina. En la secció 4.3.2 se analizará la disponibilidad de estas redes en la ciudad de Cuenca.
45
Figura 4.9: Redes de Acceso Inalámbrico [40]
4.3.2 Análisis de las redes de acceso MAN y WAN en la ciudad de Cuenca Las redes de acceso MAN y WAN mencionadas en la sección 4.3.1 han sido desplegadas en la zona urbana de la ciudad de Cuenca. La red MAN o también conocida como Wimax, se encuentra implementada por parte de la empresa ETAPA E.P. Mientras que las redes WAN o 2.5G, 3G y 4G están desplegadas por los operadores móviles: Conecel S.A. (Claro), Otecel S.A.(Movistar) y CNT E.P. A continuación se muestran los mapas de cobertura y calidad de la señal que los operadores móviles ofrecen a los usuarios en la ciudad de Cuenca.
4.3.2.1 Operadora Otecel S.A (Movistar). El portal web de la marca Movistar, permite el acceso al mapa de cobertura de la red 4G LTE. Las opciones de 2G y 3.5G no están disponibles en este medio. En la Figura 4.10 se muestra el mapa de la cobertura 4G correspondiente a la ciudad de Cuenca. La Agencia de Regulación y Control de las Telecomunicaciones, mediante el portal web de la aplicación para smartphones “Señal Móvil Ecuador”, presenta mapas con la calidad de la señal de las tecnologías 2G y 3G de cada una de las operadoras. En la Figura 4.11 se puede observar la calidad de la señal 3G de esta operadora en la ciudad de Cuenca. 46
Fuente: http://www.movistar.com.ec
Figura 4.10: Mapa de Cobertura 4G de la Operadora Otecel en la Ciudad de Cuenca
Fuente: http://smovilecuador.supertel.gob.ec/SenalMovilEcuadorWeb/mapas.html
Figura 4.11: Mapa de Calidad de la Señal 3G de la Operadora Otecel en la Ciudad de Cuenca
4.3.2.2 Operadora CNT E.P. En el portal web de la operadora CNT E.P., se puede obtener información de los mapas de cobertura de la red 2G, 3.5G, Hspa+ y 4G LTE. En la Figura 4.12 y 4.13 se muestran 47
los mapas de cobertura correspondientes a la tecnología 4G y 3,5G en la ciudad de Cuenca, respectivamente.
Fuente: http://gis.cnt.com.ec/apppublico, Rojo: LTE Indoor, Amarillo: LTE Outdoor
Figura 4.12: Mapa de Cobertura 4G de la operadora CNT E.P. en la ciudad de Cuenca.
Fuente: http://gis.cnt.com.ec/apppublico, Verde: 3.5G Indoor, Celeste: 3.5G Outdoor
Figura 4.13: Mapa de Cobertura 3.5G de la operadora CNT E.P. en la ciudad de Cuenca.
4.3.2.3 Operadora Conecel S.A. (Claro) El mapa de cobertura de la tecnología 4G se obtuvo a través del portal www.opensignal.com, el cual emplea los datos reportados por los usuarios de determinada tecnología y operadora mediante una aplicación desarrollada para android. En la figura 4.14, se muestra las mediciones recopiladas por los usuarios 4G de esta operadora.
48
Fuente: http://www.opensignal.com
Figura 4.14: Mapa de Calidad de Señal 4G de la Operadora Conecel de la ciudad de Cuenca
Para la cobertura 3G de Conecel se recurre a la versión web del aplicativo “Señal Móvil Ecuador” de la ARCOTEL. En la figura 4.15 se puede observar los datos obtenidos para esta tecnología.
Fuente: http://smovilecuador.supertel.gob.ec/SenalMovilEcuadorWeb/mapas.html
Figura 4.15: Mapa de Calidad de la Señal 3G de la Operadora Conecel en la Ciudad de Cuenca
49
4.3.2.4 Operadora ETAPA E.P. La Empresa de Telecomunicaciones Agua Potable y Alcantarillado de la ciudad de Cuenca, ha desplegado la red MAN de tipo Wimax para el servicio de Internet mediante planes residenciales. El despliegue de las radio bases en la banda 2.3-2.4 GHz que implementan esta tecnología se puede obsevar en la Figura 4.16.
Figura 4.16: Localización de las Estaciones Base WiMax Movil en la Ciudad de Cuenca [41]
4.3.2.5 Ancho de Banda de las Redes de Acceso Uno de los aspectos que se mencionan en la Tabla 4.2, es la Tasa de Datos requerida para el establecimiento de los diferentes servicios de telemedicina. Este valor está estrechamente relacionado al ancho de banda de las redes de acceso. Ya que dependiendo de los valores que cierto operador ofrezca se podrá o no implementar determinado servicio de telemedicina a través del mismo. Con este antecedente se ha procedido a recopilar el ancho de banda de los diferentes operadores y tecnologias que existen en la ciudad, con el objeto de determinar la red y operador más idóneo para nuestro sistema. Las cifras que se exponen en la Tabla 4.3 son datos promedios extraídos de los portales web tanto del aplicativo movil de la ARCOTEL (para las tecnología 3G) como del
50
portal opensignal.com (para la tecnología 4G). Estos valores son reportados tanto por las actividades de control del ente estatal, como por los usuarios móviles que tienen la aplicación. Tabla 4.3: Ancho de Banda de las Redes de Acceso en la Ciudad de Cuenca Operador CNT E.P.
Otecel SA
Conecel S.A. ETAPA E.P.
Tecnología
Ancho de Banda Uplink (Mbps)
Ancho de Banda Downlink (Mbps)
3G
1.34
8.78
4G
3.41
15.72
3G
0.7
5.69
4G
10.39
18.33
3G
0.32
1.6
4G
14.26
20.01
Wimax Móvil
0.35
2.4
Con toda la información antes recopilada y las siguientes premisas, se procede a seleccionar la tecnología y operador más adecuado para nuestra red: • La disponibilidad de una red de telecomunicaciones, es un factor muy importante al momento de cumplir las condiciones mínimas de satisfacción que un sistema puede ofrecer a sus usuarios. Al diseñar una red de telemedicina para la transmisión de signos vitales, este aspecto toma una mayor connotación, debido a que la información que se está transmitiendo puede significar decisiones vitales que determinen la supervivencia de un paciente. Uno de los mecanismos que contribuyen a incrementar la disponiblidad es la redundancia de red. Es decir contar con un camino secundario que responda al tráfico generado cuando la red primaria se deteriore. Para su implementación existen diferentes configuraciones dependiendo del escenario de los usuarios. Una configuración 1+1 significa que el enlace primario y secundario transmiten información al mismo tiempo. Una configuración 1+0 significa que el enlace primario está transmitiendo y el secundario listo para transmitir. Y una configuración 0+0 significa que los dos enlaces están listos para transmitir. • Con lo expuesto en el párrafo anterior, se procede a analizar las propiedades de las redes de acceso antes mencionadas: La tecnología de las operadoras móviles, ha ido cambiando a través del tiempo. Es así que los estándares desarrollados por el 3GPP han permitido la evolución de las redes sin dejar de lado su interoperbilidad. Esta característica, se va a considerar como uno de los elementos clave para el establecimiento de la redundancia de nuestra red. Por ejemplo: Si se está transmitiendo determinada información por la red 4G y esta sufre un deterioro en la misma, el dispositivo terminal automáticamente se conecta a la red 3G o 51
2G dependiendo de cual ofrezca mejor calidad. En este contexto, la red WiMax Móvil no contaría con esta particularidad, de acuerdo a la Tabla 4.3. • Las redes de acceso, como se observa en la Tabla 4.3, poseen velocidades distintas para uplink y downlink. El interés de nuestro diseño recae sobre las características de los enlaces uplink. Ya que la información de interés, es la que se genera en la dirección ambulancia - centro de operaciones. Tomando en cuenta la redundancia y ancho de banda, la red de CNT, es la más equilibrada ofreciendo un ancho de banda 4G no muy distante de su similir en 3G. En el otro extremo está la red de Conecel S.A., la cual ofrece un excelente ancho de banda 4G pero el menor ancho de banda en 3G. Por su lado la operadora Otecel S.A., ofrece un ancho de banda muy bueno en 4G pero el doble de ancho de banda que Conecel S.A en 3G. • De acuerdo a la Tabla 4.2, considerando los servicios de voz, señales biomédicas y video de alta calidad MPEG-4, con las mas altas tasas de datos, se requeriría de una red con un troughput cercano a los 5.315 Mbps, para transmitir toda esta información de manera fiable. Con esta cifra, los enlaces uplink que cumplen con este requerimiento son los correspondientes a la red 4G de Otecel y Conecel. Pero en el caso que la señal se degrade y se realice un hand-over a la red 3G, los servicios deberán ser acoplados para priorizar el envío de señales biomédicas y la voz. En este escenario la red que mejor se acopla es el operador CNT, e incluso sin perder el servicio de vídeo pero con una tasa de datos mucho menor. • Otro factor muy importante es la cobertura que estas redes poseen en la ciudad. Respecto a 3G, todas las operadoras tienen un nivel de cobertura del 95% en la zona urbana de la ciudad de Cuenca, pero en 4G existen diferencias. La operadora estatal es la que menor área de servicio posee de acuerdo a la Figura 4.12 (información actualizada a marzo de 2016), mientras que la cobertura 4G de Otecel y Conecel son muy similares. En este contexto no serviría de mucho el equilibrio de los anchos de banda uplink entre 4G y 3G de CNT, si no se tiene una cobertura aceptable de la ciudad. • Con todo el análisis realizado en los puntos anteriores, la red más adecuada para la implementación de la red de telemedicina, es la red 4G de la operadora Otecel como red primaria y la red 3G de la misma operadora como red redundante debido al mejor ancho de banda uplink en 3G. Lo cual asegura que los datos más importantes que son las señales biomédicas y de voz, no se degraden.
52
4.3.3 Estudio de la Arquitectura de la Red de Acceso A continuación se describen los aspectos más relevantes de la arquitectura de la red primaria 4G (LTE), de acuerdo al reporte técnico de la empresa Alcatel-Lucent[42].
4.3.3.1 Arquitectura LTE A diferencia de las redes de conmutación de circuitos de los sistemas celulares previos, LTE (Long Term Evolution) ha sido diseñado para soportar específicamente servicios de conmutación de paquetes. LTE está orientado a proveer una conexión IP directa entre el equipamiento de usuario (UE - User Equipment) y la red de paquetes de datos (PDN - Packet Data Network), sin afectar las aplicaciones de los usuarios mientras se mueven. El término “LTE” hace referencia a la evolución de la tecnología de acceso de radio UMTS (Universal Mobile Telecommunications System) hacia la tecnología E-UTRAN (Evolved - Universal Terrestrial Radio Access Network). Esta innovación viene a la vez acompañada de la evolución de otros aspectos no relacionados al acceso de radio, bajo el término SAE (System Architecture Evolution), integrada por la red PC (Evolved Packet Core). LTE y SAE en conjunto conforman el EPS (Evolved Packet System). El EPS usa un concepto abstracto denominado bearers o portadores para enrutar el tráfico IP desde el gateway de la PDN hasta el UE. Un portador o bearer hace referencia a un flujo de paquetes IP con determinada calidad de servicio (QoS), entre el gateway y el UE. La E-UTRAN y el EPC configuran y establecen los bearers que requieran las aplicaciones del UE. El EPS provee la conectividad IP del UE a la PDN, para al acceso a Internet, así como para servicios de voz sobre IP (VoIP). Un bearer está asociado a determinado QoS. Pero a la vez múltiples portadores pueden ser configurados en un mismo usuario para proveer diferentes QoS. Por ejemplo, un usuario puede estar en llamada VoIP mientras navega por internet o descarga archivos FTP. En bearer VoIP provee determinado QoS para el establecimiento de la llamada, mientras que el bearer para la navegación o descarga FTP se ajusta a uno de tipo best-effort. Para una mejor compresión de este tema, en la sección 4.3.4.2 se detalla el uso de QoS mediante los bearers. En la Figura 4.17 se muestra la arquitectura global del EPS, incluyendo los elementos de red y las interfaces estandarizadas.
53
Figura 4.17: Evolved Packet System [42]
A nivel superior, la red está conformada por el core network o EPC y la red de acceso E-UTRAN. La red E-UTRAN está formada esencialmente por un solo nodo, o también llamado eNodeB, en donde se conectan los UE. Cada uno de estos elementos de red están interconectados a través de interfaces que permiten la interoperabilidad entre varios vendors. Esto permite que los operadores de red durante el despliegue puedan separar o unir los elementos lógicos de la red, dependiendo de las consideraciones comerciales del medio en que se encuentren. La división funcional entre el EPC y el E-UTRAN se muestra en la Figura 4.18.
Figura 4.18: Separación Funcional entre EPC y E-UTRAN [42]
EPC - Evolved Packet Core Es responsable del control global de los usuarios UE y el establecimiento de los bearers. Los principales nodos lógicos del EPC son: 54
• PDN Gateway (P-GW) • Serving Gateway (S-GW) • Mobility Management Entity (MME) Adicionalmente a estos nodos, el EPC también incluye otros nodos lógicos y funciones tales como el Home Subscriber Server y el Policy Control and Charging Rules Function, como se muestra en la Figura 4.17. Debido a que el EPS solo provee un camino bearer para determinado QoS, el control de las aplicaciones multimedia tales como VoIP lo maneja el IP Multimedia Subsystem (IMS), el cual se considera exterior al EPS. Los nodos lógicos del core network que se muestran en la Figura 4.17, se detallan a continuación: • PCRF (Policy Control and Charging Rules Function): es responsable de la toma de decisiones en las políticas de control, así como el control de las funcionalidades de facturación del PCEF (Policy Control Enforcement Function), en el P-GW. Adicionalmente provee la autorización de QoS (asignación QCI y tasas de datos), que determina la manera como cierto flujo de datos es tratado en el PCEF y asegura que su implementación esté de acuerdo al perfil del subscriptor. • HSS (Home Subscriber Server): este servidor contiene la información relacionada a los subscriptores del SAE, como el perfil QoS o restricciones de acceso de tipo roamin, etc. Además posee información dinámica como la ID del MME al cual el usuario está conectado o registrado. El HSS puede también integrar un centro de autenticación (AUC), el cual genera vectores para la autenticación y llaves de seguridad. • P-GW (PDN Gateway): es responsable de la asignación de la dirección IP a los usuarios UE, así como la ejecución de QoS y facturación basada en el tipo de flujo de acuerdo a la reglas del PCRF. Es responsable del filtrado de los paquetes IP del tráfico downlink del usuario en los diferentes bearers. Esto es llevado a cabo mediante Plantillas de Flujo de Tráfico (TFT - Traffic Flow Templates). También sirve como anclaje de mobilidad para el internetworking con tecnologías diferentes a 3GPP como CDMA2000 y WiMax. • S-GW (Serving Gateway): Todos los paquetes IP de los usuarios son transferidos a través del S-GW, el cual sirve como el anclaje de movilidad local para los data bearers cuando un usuario se mueve entre eNodeBs. También retiene información sobre los bearers cuando el usuario está en estado idle o inactivo y temporalmente acumula datos downlink mientras el MME inicia el proceso de paging 55
(notificación) del usuario para el restablecimiento de los bearers. Adicionalmente el S-GW desarrolla funciones administrativas de la red como recolección de información para facturación e interceptaciones legales. También sirve como el anclaje de mobilidad para la inter-operación con otras tecnologías 3GPP como GPRS y UMTS. • MME (Mobility Management Entitiy): La entidad administrativa de movilidad, es el nodo central de control que procesa la señalización entre los usuarios UE y el core network. Los protocolos que se implementan entre los UE y la red core son conocidos como protocolos NAS (Non Access Stratum). Las principales funciones del MME se pueden clasificar en dos tipos: Funciones relacionadas a la administración de bearers - que incluye el establecimiento, mantenimiento y emisión de bearers, a través de la capa de sesión de los protocolos NAS, y Funciones relacionadas a la administración de la conexión - que incluye el establecimiento de la misma y la seguridad entre la red y el usuario UE, a través de la capa de administración de movilidad del protocolo NAS.
Evolved Universal Terrestrial Radio Access Network La red de acceso de radio LTE, consiste de una red de eNodeBs, como se ilustra en la Figura 4.19. Los eNodeBs están normalmente interconectados entre sí por medio de la interfaz X2, y al EPC por medio de la interfaz S1. Si la conexión es hacia la entidad MME la interfaz se denomina S1-MME y si es hacia el S-GW la interfaz se conoce como S1-U. Los protocolos utilizados entre los eNodeBs y los usuarios UE son conocidos como protocolos “AS”.
Figura 4.19: Arquitectura E-UTRAN [42] 56
La E-UTRAN es responsable de todas las funcionalidades relacionadas al enlace de radio, como: • Radio resource management (RRM): Esto abarca todas las funciones relacionadas a los bearers a nivel de radio, control de radio bearers, control de admisión de radio, control de mobilidad de radio, scheduling y asignación dinámica de recursos a los usuarios UE tanto en el enlace uplink y downlink. • Header Compression: Esto ayuda al uso eficiente de la interfaz de radio, mediante la compresión de cabecera de paquetes IP, que pueden de alguna forma representar un significante overhead, especialmente para paquetes pequeños como VoIP. • Security: Todos los datos enviados a través de la interfaz de radio están encriptados. • Connectivity to the EPC: Esto consiste en la señalización hacia la entidad MME y del bearer path hacia el S-GW. Todas estas funciones residen en los eNodeBs, cada uno es responsable de administrar múltiples celdas. A diferencia de algunas tecnologías previas como GSM y UMTS, LTE integra la función de control de radio dentro de los eNodeB. Esto permite la interacción cercana de las diferentes capas de protocolos de la red de acceso de radio, reduciendo la latencia y mejorando la eficiencia. Este control distribuido a los eNodeBs elimina la necesidad de un controlador de alta disponibilidad y de gran capacidad de procesamiento, lo que se traduce en una potencial reducción de costos y puntos de fallo único. Adicionalmente, debido a que LTE no soporta soft handover (propiedad de los sistemas CDMA y W-CDMA que permite la conexión simultánea a dos o más celdas durante una llamada), no hay la necesidad de una entidad centralizada para la coordinación de este proceso. Una consecuencia de la falta de un controlador centralizado es que, cuando el usuario se mueve, la red debe de transferir toda la información relacionada a este, junto a cualquier dato en buffer desde un eNodeB a otro. Para este proceso, existen diversos mecanismos que evitan la pérdida de datos durante el handover, como la operación de la interfaz X2 entre los eNodeB.
Interoperabilidad Respecto a otras redes, el EPS soporta la interoperatividad y movilidad con redes que usan otras tecnologías de acceso de radio, como GSM, UMTS, CDMA 2000 y WiMax. La arquitectura para la interoperabilidad con redes 2G (GPRS) 57
y 3G (UMTS), se ilustra en la Figura 4.20. El S-GW actúa como un anclaje para la interoperatividad con otras tecnologías 3GPP , mientras que el P-GW lo hace para las tecnologías CDMA2000 y WiMax, mediante una interfaz de tipo PMIP (Proxy Mobile Internet Protocol). [42]
Figura 4.20: Arquitectura de Interoperabilidad de la red LTE con UMTS [42]
4.3.4 Parámetros de la red de acceso Para la validación de la red propuesta mediante la simulación, es necesario definir ciertos parámetros que permitan evaluar de manera eficiente el desempeño de la red para aplicaciones de servicios de telemedicina. En primer lugar se va a elegir la banda de frecuencia a ser usada por la red primaria, que en nuestro caso corresponde a LTE, luego se definirá los parámetros de QoS asignado al flujo de datos del perfil de usuario-ambulancia, técnicas de acceso múltiple, ancho de banda de canal, schedulers o agendadores, y finalmente el modelo de propagación.
4.3.4.1 Banda de Frecuencia LTE en el Ecuador La Agencia de Regulación y Control de las Telecomunicaciones en el Ecuador ARCOTEL (antes conformada por la SENATEL, SUPERTEL y CONATEL), ha definido las bandas del espectro radioeléctrico para la implementación de la tecnología LTE en el territorio nacional. En la Figura 4.21 se puede obsevar la canalización de las diferentes bandas de 700 MHz, AWS 1700/2100 MHz y 2.5 GHz estipuladas en la resolución TEL-804-29-CONATEL- 2012 del Consejo Nacional de Telecomunicaciones. En la Figura 4.22 se expone la canalización adicional para los operadores en la banda de 1900
58
MHz.
Figura 4.21: Bandas de Frecuencia para la Tecnología LTE en el Ecuador.
Figura 4.22: Canalización Adicional en la Banda de 1900 MHz.
A continuación se describen las asignaciones de estas bandas de frecuencia a los distintos operadores móviles: • El CONATEL autoriza a la empresa pública CNT E.P. en la banda de 700 MHz los bloques G - G’, H - H’ e I - I’ correspondientes a los rangos 733 - 748 MHz (Up Link) y 788 - 803 MHz (Down Link) a nivel nacional. Adicionalmente autoriza en la banda AWS 1700/2100 MHz los bloques A - A’, B - B’, C - C’ y D - D’ correspondientes a los rangos 1710 - 1730 MHz (Up Link) y 2110 - 2130 MHz (Down Link) a nivel nacional. • El CONATEL autoriza a la empresa Conecel el uso de 20 MHz de la banda de 1900 MHz distribuido en los bloques B3 - B3’, correspondientes a los rangos 1880 - 1885 MHz (Up Link) y 1960 - 1965 MHz (Down Link) y los bloques F F’ correspondientes a los rangos 1890 - 1895 MHz (Up Link) y 1970 - 1975 MHz (Downlink). Adicionalmente se otorga 40 MHz de la banda AWS 1700/2100 MHz, distribuido en los bloques E - E’, F - F’, G - G’ y H - H’, correspondientes a los rangos de 1730 - 1750 MHz (Up Link) y 2130 - 2150 (Down Link). 59
• El CONATEL otorga a la empresa Otecel el uso de 30 MHz de la banda de 1900 MHz, distribuido en los bloques A1 - A1’, A2 - A2’ y A3 - A3’, correspondiente a los rangos de frecuencia 1850 - 1865 MHz (Up Link) y 1930 - 1945 (Down Link). Adicionalmente se otorga 20 MHz de la misma banda, distribuido en los bloques B1 - B1’ y B2 - B2’ correspondiente a los rangos 1870 - 1880 MHz (Up Link ) y 1950 - 1960 MHz (Down Link). Basado en esta asignación de frecuencias se procede a seleccionar el parámetro EARFCN (E-UTRA Absolute Radio Frequendy Channel Number), de acuerdo a lo estipulado en la especificación técnica ETSI TS 136 101 V13.3.0 (2016-05) “LTE; Evolved Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio transmission and reception”. El rango de este parámetro oscila entre 0 - 262143. En el Anexo 2 se puede observar la equivalencia de las diferentes bandas E-UTRA con el EARFCN. Para nuestra red se van a seleccionar los valores correspondientes a la banda A1 - A1’ o banda 2 asignadas a la operadora Otecel. Los valores son los siguientes: Up Link EARFCN = 18600 y Down Link EARFCN = 600.
4.3.4.2 Calidad del Servicio (QoS) La calidad de servicio (QoS) de una red de telecomunicaciones, de acuerdo a la recomendación UIT-T E.800, comprende tanto la calidad de funcionamiento de la red, como la calidad de funcionamiento independiente de la red. La calidad de funcionamiento de la red hace referencia a los indicadores throughtput, tasa de error de bits, latencia, etc. que una red de telecomunicaciones puede ofrecer a sus subscriptores. Mientras que la calidad de funcionamiento independiente de la red, hace referencia a los indicadores en cuanto a la atención al cliente, número de reclamos atendidos, planes de compensación, etc. Los indicadores que se utilizará para evaluar la calidad de funcionamiento de la red en esta tesis comprende: throughput promedio, retardo promedio y tasa de pérdida de paquetes. El throughput promedio es la cantidad de información que se puede enviar a través de la red en un periodo de tiempo, su unidad se expresa en bits por segundo (bps). El retardo promedio, se define como el tiempo promedio en que se demoran los paquetes de un flujo de datos en llegar a su destino, su unidad se expresa en milisegundos (ms). La tasa de pérdida de paquetes, se define como el porcentaje de la razón entre el número de paquetes perdidos y el número de paquetes enviados. Esta cifra se expresa en unidades porcentuales (%). En este contexto, la red LTE posee diversos mecanismos para brindar una determinado servicio a sus usuarios. Uno de los mecanismos es el establecimiento de bearers, que son etiquetas con determinado QoS para un flujo de datos de extremo a extremo den60
tro del EPS. De forma general los bearers, pueden ser clasificados en dos categorías, basado en la naturaleza de QoS que proporcionan: 1. Minimum GBR (Guaranteed Bit Rate) bearers, son aquellos que pueden ser usados por aplicaciones de tipo VoIP. Este tipo de bearers tienen un valor asociado para que recursos de transmisión estén permanentemente dedicados para determinado flujo de datos. Tasas de bit más altas que las aseguradas por el bearer pueden ser permitidas siempre y cuando existan los recursos necesarios. En estos casos una tasa máxima de bit puede también estar asociada a un bearer de tipo GBR. 2. Non-GBR bearers, no garantizan ninguna tasa de bits del usuario. Este tipo de QoS puede ser usado para aplicaciones tales como navegación web o FTP. Para estos bearers ningún recurso de ancho de banda es asignado permanentemente al flujo de datos. Para la implementación de bearers, por parte de la red de acceso de radio, es responsabilidad de los eNodeBs asegurar la QoS necesaria sobre la interfaz de radio. Cada bearer está asociado a un valor QCI (QoS Class Identifier) y un ARP (Allocation and Retention Priority). Cada QCI está caracterizado por la prioridad, retardo de paquetes esperado y una tasa de pérdida de paquetes aceptable. Estos valores han sido estandarizados para que diferentes vendors tengan la misma comprensión sobre las características de estos servicios y puedan generar diverasas estrategias en la red para cumplir con los requsitos del usuario. Esto asegura que el operador LTE, espere un tratamiento uniforme del manejo del tráfico a través de la red sin importar del tipo de fabricante de los equipos. El conjunto de QCI’s estandarizados y sus características están disponibles en la especificación técnica 3GPP TS 23.203 V10.6.0. En la Tabla 4.4 se puede observar los diferentes tipos de QCI y sus características, adicionalmente se relaciona cierto tipo de servicios a cada uno de ellos.
61
Tabla 4.4: QCIs Estandarizados para LTE [42]
La prioridad y retardo de paquetes de la etiqueta QCI determina el modo de configuración de RLC (Radio Link Control) y como el scheduler a nivel de MAC maneja los paquetes enviados a través del bearer de la interfaz de radio. Por ejemplo, un paquete con prioridad más alta puede ser agendado antes que un paquete con prioridad más baja. Para bearers con bajo tasa de perdida de paquetes se puede asignar el modo AM (Acknowledged Mode) dentro del protocolo RLC para asegurar el envío exitoso de paquetes a través de la interfaz de radio. Con la información antes expuesta, se va a analizar el tipo de bearer LTE que mejor se adapte a la red de telemedicina para garantizar determinados servicios. En la información que se expone en la Tabla 4.2 se establecen los requerimientos mínimos de retardo y pérdida de paquetes, para cada tipo de servicio. El tipo de recurso que requieren los datos de audio, video y señales biomédicas es GBR o “tasa de bit garantizada”, que de acuerdo a la Tabla 4.4 corresponde a los identificadores 1, 2 ,3 y 4. Seleccionando los servicios de telemedicina de mejor calidad para cada tipo de dato, se obtiene que para establecer un servicio de Sonido de Diagnóstico el retardo máximo debe oscilar entre 100-300 ms y tener una tasa de pérdida de paquetes de 1%. El QCI que mejor se adapta para este tipo de datos es el número uno, con un retardo de paquetes de 100 ms y pérdida de paquetes de 1%. En cuanto al servicio de Video Diagnóstico de alta calidad el retardo máximo debe oscilar entre 100-300 ms y tasa de pérdida de paquetes cercano al 0%. El QCI que mejor se adapta es el número dos, con un retardo de paquetes de 150 ms y tasa de pérdida de paquetes del 0.1%. En cuanto al servicio para Señales Biomédicas el retardo puede ser de hasta 1 s y tasa de pérdida de paquetes cercanos a 0%. El QCI que mejor se adapta es el número 4, con retardo de 50 ms y tasa de perdida de paquetes del 0.1%. Respecto a la prioridad la más alta con el número 2 corresponde al servicio de voz, luego con prioridad 3 las señales biomédicas, y en cuarto lugar el 62
servicio de vídeo. Este proceso de selección está acorde a los análisis realizados en la sección 3.2, sobre las señales biomédicas y sus propiedades.
4.3.4.3 Tecnologías de Acceso Múltiple y Ancho de Banda en LTE Las transmisiones en el enlace ascendente y descendente en LTE están basadas en tecnologías de acceso múltiple. En el enlace descendente se utiliza Orthogonal Frequency Division Multiple Access (OFDMA) y en el enlace ascendente Single Carrier Frequency Division Multiple Access (SC-FDMA). Esta última es superior a la primera, sin embargo está restringida solo al enlace ascendente debido a requiere de mayor tiempo de procesamiento lo cual podría implicar una sobrecarga a las estaciones base.
OFDMA (LTE Downlink) Es una derivación de OFDM, que es un esquema de modulación digital multi-portadora, que en principio plantea que la información puede ser transmitida en un canal de radio variando la frecuencia, fase o magnitud. En lugar de enviar toda la información a través de una sola portadora, los datos de ingreso pueden ser multiplexados en transmisiones paralelas a menor tasa de datos que el flujo entrante. Las transmisiones paralelas son moduladas en sub-portadoras en el dominio de la frecuencia a través del uso de la transformada inversa de Fourier. Una vez que la señal es transmitida, en el receptor se demodula utilizando la FFT (Fast Fourier Transform). En la Figura 4.23 se muestra la representación de una señal OFDM en el dominio del tiempo y la frecuencia.
Figura 4.23: Representación de una Señal OFDM [43]
Mediante el uso de TDMA con OFDM, se logra la asignación dinámica de subportadoras entre diferentes usuarios del mismo canal. A esta técnica se la conoce como OFDMA, que se caracteriza por ser un sistema robusto de gran capacidad y resistente 63
al desvanecimiento por multitrayectoria. En LTE cada subportadora se modula con un esquema de modulación de acuerdo a la condición del canal, pudiendo ser esta: QPSK, 16QAM o 64 QAM. Los tamaños de la FFT varian desde 128 a 2048 dependiendo del ancho de banda utilizado, el cual en LTE puede ser de: 1.25, 2.5, 5, 10 y 20 MHz. En el dominio del tiempo, se introduce un tiempo de guarda, conocido como Prefijo Cíclico (CP - Cyclic Prefix), el cual permite disminuir la interferencia intersimbólica provocado por el retardo multitrayectoria diseminado en el canal de radio, su valor típico en LTE es de 4.69 us.
SC-FDMA (Up-Link) Single Carrier - Frequency Division Multiple Access, técnica de acceso múltiple que crea una portadora simple desplazada en el dominio de la frecuencia. Provee una resistencia robusta a la multitrayectoria sin el inconveniente del incremento de ruido gaussiano cuando se incrementa el número de sub-portadoras como sucede en OFDMA. En la Figura 4.24, se puede observar la comparación entre las técnicas SC-FDMA y OFDMA al enviar una secuencia determinada de símbolos QPSK.
Figura 4.24: Comparación de OFDMA y SC-FDMA al transmitir símbolos QPSK [43]
SC-FDMA transmite los símbolos en series de M veces la tasa de simbolo, con cada sub-simbolo ocupando M x 15 KHz de ancho de banda. Ocupando el mismo ancho de banda que OFDMA, pero sin el problema de ruido gaussiano de multiportadora de OFDMA.
64
Ancho de Banda LTE posee un anchos de banda escalables con valores de 1.4, 3, 5, 10, 15 y 20 MHz, usando un espaciamiento de sub-portadora de 15 KHz. Este espaciamiento es independiente del ancho de banda del canal. La duración de símbolo OFDMA y SC-FDMA es el mismo para ambos: 66.7 us., sobre el cual las subportadoras de 15 KHz (OFDMA - Downlink) y 60 KHz (SC-FDMA) son moduladas por un simbolo QPSK. El tamaño más pequeño de recursos asignados en uplink y downlink se donomina resource block (RB), con 180 KHz de ancho de banda y 0.5ms de duración. El ancho de banda de cada RB consta de 12 subportadoras de 15 KHz y 7 símbolos OFDMA/SC-FDMA. El número de RBs que se pueden usar en un determinado ancho de banda, no es el máximo posible, ya que determinados RBs son configurados como RBs de guarda. En la Tabla 4.5 se muestran los RBs máximos para cada ancho de banda. Tabla 4.5: Configuración de Ancho de Banda de canal LTE
De acuerdo a los datos analizados en la sección 4.3.4.1, cada bloque de frecuencia asignado a los operadores es de 5 MHz. Para el diseño de nuestra red, se opta que cada celda tenga un bloque de frecuencia o 25 RBs de acuerdo a la Tabla 4.5.
4.3.4.4 Schedulers o Agendadores En LTE un canal común debe ser compartido por varios usuarios, mediante un mecanismo que asigne los recursos de radio de una manera eficiente. Estos recursos en LTE están determinados por el esquema de modulación OFDM y SC-FDM. El objeto de agendar o planificar es encontrar una solución aceptable considerando los siguientes aspectos: • Máximo retardo aceptable de un paquete • Equidad en la distribución de recursos • Asignación eficiente de los recursos • Minimización de sobre-procesamiento
65
Agendador Round-Robin Este algoritmo es el más simple, ya que asigna a cada usuario un intervalo de tiempo, donde el mismo tiene acceso exclusivo al canal. La selección de los usuarios que tendrán acceso es implementado de tal forma que cada usuario tenga un lugar específico en la cola de espera para ser servido. Este tipo de agendador no considera ninguna información adicional mas que el tiempo que asigna a cada usuario. Este algoritmo no es eficiente cuando se considera la tasa de datos total en la celda. Solo los usuarios seleccionados pueden transmitir datos a una tasa limitada por su SNR (Signal to Noise Ratio). Si un usuario con un deficiente SNR es seleccionado para transmitir, la tasa de datos de la celda en ese slot será baja y por lo tanto el throughput total decrece. En la vida real los móviles se mueven a través de la celda incrementando o disminuyendo su SNR.
Agendador Maximum Rate Este algoritmo es la representación más severa en cuanto a aprovechar las fluctuaciones del SNR, con el objeto de obtener el mejor throughput dentro de la celda. Este agendador selecciona al usuario que mejor SNR tenga, por lo tanto la tasa de datos es la mayor de todos los usuarios. Si el valor SNR de todos los usuarios fuera igual en el tiempo, cada usuario tendría el mismo tiempo de transmisión. Sin embargo este agendador tiene serias desventajas que hacen su implementación poco probable. En el caso, que un usuario esté muy cercano a la radio base, hace que su SNR sea mucho mejor que el resto de usuarios en la celda. Por lo tanto el agendador siempre asignará a este usuario todos los recursos mientras realiza una descarga de datos. Ninguno de los otros usuarios podrán ser agendados para transmitir, mientras este usuario tenga packetes en espera. La poca aplicabilidad de este agendador, puede ser mejorada tratando de combinar este algoritmo con round-robin, pero que de igual manera la tasa de datos global decrece, considerablemente.
Agendador Proportional Fair La idea básica de este agendador es explotar las variaciones de la calidad del canal, pero no solo basado en el SNR absoluto, sino en el SNR de cada usuario con respecto a su valor SNR promedio. Para la implementación de este agendador, el eNodeB necesita medir la calidad de la señal de cada usuario de forma independiente, luego calcular su valor SNR medio, calcular su tasa de datos y comparar con la de los otros usuarios para determinar el que tenga mayor tasa y agendarlo para el siguiente intervalo. El throughput de este agendador es mucho mayor al algoritmo round-robin, ya que no asigna un slot fijo a cada usuario, sino se escoje al usuario que mejor SNR tenga respecto a su valor medio. Sin embargo, su throughput es menor al algoritmo Maximum Rate, pero introduce un determinado grado de equidad y una menos probable falta de recursos para el resto de usuarios. Las desventajas de este agendador es su alta complejidad por los calculos y mediciones que tiene que realizar 66
de forma continua. De acuerdo al análisis realizado en [44] y [45], tanto en escenarios de flujo de datos constante como de datos no persistente (web browsing), el agendador Proportional Fair brinda un desempeño equilibrado, con mejor throughput y equidad a los usuarios. Para que un operador ofrezca un determinado perfil de usuario a sus abonados, debe mejorar la calidad servicio añadiendo los denominados bearers, a los agendadores que en la vida real son más complejos y dependen de cada vendor.
4.3.4.5 Modelo de Propagación Un modelo de propagación es una aproximación numérica de las pérdidas que puede sufrir la señal electromagnética por diversos factores, tales como atenuación por condiciones climáticas, entorno de propagación (urbano, sub-urbano, rural), altura del trasmisor, altura del receptor, frecuencia, etc. Estos modelos han sido analizados para el despliegue de redes LTE en [46] por Shabbir et.al. y [47] por S. Mawjoud. Shabbir et.al., compara diversos modelos de propagación para una red LTE. Entre estos modelos están: Stanford University Interim (SIU), Okumura, Hata COST 231, COST WalfischIkegami y Ericsson 9999. Los escenarios que se plantean para la evaluación de cada modelo, radica en variar la altura de la radio base (30 - 80 m) y la frecuencia de operación (1900 y 2100 MHz). En cada caso se realizan las simulaciones para áreas urbanas, sub-urbanas y rurales. Los resultados de nuestro interés para la elección del modelo es el área urbana. Para este entorno, el modelo SUI, tiene la predición más baja de pérdidas tanto para 1900 y 2100 MHz, mientras que el modelo COST 231 Hata tiene las pérdidas mas altas para 1900 MHz y Ericsson 999 para 2100 MHz. A su vez, S. Mawjoud compara los modelos propagación Okumura-Hata, COST-231 Okumura-Hata, SUI y Log-Distance con mediciones reales realizadas en la ciudad Iraquí de Erbil. Los escenarios que se plantea es para entornos urbano y sub-urbano con altura de antenas de 35 y 28 m, respectivamente. La frecuencia de operación es 2600 MHz, Adicionalmente, S. Mawjoud implemente una corrección empírica a cada uno de los modelos antes mencionados, mediante el método de los mínimos cuadrados lineal. En la Figura 4.25, se muestra el resultado de la simulación de cada modelo y de los datos reales tomados de las mediciones efectuadas, en el entorno urbano. En esta figura se puede evidenciar el comportamiento de los distintos modelos siendo el modelo COST 231 Hata corregido el que más se asemeja a las mediciones reales.
67
Figura 4.25: Modelos de propagación y datos medidos en el área urbana. [47]
4.4 Diseño de la Infraestructura Lógica de la Red La infraestructura lógica de la red, se refiere a la forma en que una red transfiere tramas de un nodo a otro. Esta disposición consta de conexiones virtuales entre los nodos de la misma. Por lo general los protocolos de la capa de enlace de datos definen estas rutas de señales lógicas. Las topología de los enlaces punto a punto es relativamente simple, mientras que los medios compartidos requieren métodos de control de acceso al medio, de tipo deterministas o no deterministas. El tipo de topología empleado en el diseño de nuestra red de telemedicina es de tipo mixta, ya que abarca conexiones de tipo estrella, punto a punto, malla y árbol. En la Figura 4.26 se expone el diseño de la infraestructura lógica de la red de telemedicina. El tipo de topología a nivel de ambulancia es de tipo mixta. Las tramas de datos tanton del monitor de signos vitales y el multimedia touchscreen convergen en el router/wifi, creando una conexión tipo estrella. Estas tramas son enviadas a la red 4G/3G a través de una conexión punto a punto entre el router/wifi y el módem 4G/3G. Las direcciones lógicas de la red WLAN en la ambulancia, son proporcionadas mediante el protocolo DHCP del router/wifi. Las direcciones de red, para las ambulancias
68
son de clase C. En la Figura 4.26, se puede osbservar que en la unidad 1 se ha designado la red 192.168.0.0/29. De acuerdo a como se vaya integrando las ambulancias, se asignará una red WLAN cuya dirección en su tercer octeto se vaya incrementando en una unidad. En cuanto a la conexión punto a punto entre el router/wifi y el módem 4G/3G la asignación de direcciones lógicas son de tipo estático.
Figura 4.26: Infraestructura Lógica de la Red de Telemedicina
En cuanto al tipo de topología de la infraestructura lógica de la red 4G, ésta es de tipo 69
mixta, y varía para cada operador móvil. Su infraestructura lógica se encuentra establecida por interfaces que conectan las diferentes entidades de la misma. En la Figura 4.27 se puede observar las conexiones lógicas de la arquitectura 4G. A continuación se describen las mismas.
Figura 4.27: Infraestructura Lógica de la red 4G
La interfaz que conecta a los usuarios o Ue’s con la E-UTRAN se denomina Lte-Uu. La interfaz de comunicación entre los eNodeBs que forman la E-UTRAN se denomina X2. Para conectar la E-UTRAN a las entidades del EPC, se uiliza las interfaces S1-U y S1MME. Dentro del EPC, las conexiones no se dan entre todos las entidades, por lo que cada interfaz es diferente, como se observa en la Figura 4.27. Para la comunicación del EPC con las redes externas, IMS (Ip Multimedia System) e internet, se utiliza la interfaz SGi. Respecto a las direcciones lógicas de los UE’s, según lo analizado en la sección 4.3.3.1 éstas son gestionadas por la entidad P-GW perteneciente al EPC, mientas que las políticas para esta asignación, son gestionadas en la entidad PCRF. Cada operador establece sus propias reglas para la asignación de direcciones de acuerdo a la implementación de su infraestructura. En cuanto al tipo de topología que implementa el SIS ECU 911 Austro, ésta es de tipo árbol, según su descripción realizada en la sección 4.2. Para la institución no se requiere ninguna implementación adicional, más que la dirección IP pública y la asignación del puerto para el servidor de aplicaciones y monitoreo, el cual es gestionado por el departamento de TI de la institución.
70
4.4.1 Seguridad de la Red de Telemedicina Respecto a la seguridad de la información en la red de telemedicina propuesta, ésta se puede dividir en etapas, ya que se utilizan diferentes tecnologías para transmitir los datos. A nivel de ambulancia, se utiliza el estándar IEEE 802.11 para la comunicación entre el equipo médico y el PAD Multimedia con el router/wifi. Para esta tecnología hay diversas estrategias se pueden configurar para brindar seguridad a los datos, como: autenticación-encriptación, filtrado de paquetes, y listas de control de acceso. La autenticación-encriptación, protege el acceso de la información a usuarios no permitidos y cifra los datos, mediante técnicas de tipo WEP (Wired Equivalent Privacy), WPA (Wifi Protected Access), WPA-PSK (Pre Shared Key), WPA2 y WPA2-PSK, siendo esta última la que mejor desempeño implementa, al generar nuevas claves para cada conexión, basada en la clave precompartida con posiblidad de hasta 63 caracteres alfanuméricos y por su tipo de encriptación AES (Advanced Encryption Standard) de acuerdo a [48]. El filtrado de paquetes hace referencia al tipo de protocolos que la capa de aplicación puede enviar o no a través de la WLAN, por ejemplo: HTTP, HTTPS, POP3, IMAP, SMPT, Telnet, DNS, SNMP, etc. En este contexto, al momento de desarrollar las aplicaciones que utilizará el Multimedia Pad, se definirán los protocolos que deban ser filtrados en el router/wifi. En lo que respecta a la lista de control de acceso, ésta se implementa a nivel de dirección MAC, permitiendo o denegando el acceso de determinado equipo a la WLAN. Respecto a la seguridad de la información entre la ambulancia y el SIS ECU 911 Austro, está por un lado el tipo de políticas de privacidad de la información implementadas por el operador móvil y por otro lado el esquema de seguridad de la institución. De acuerdo a la Figura 4.26, luego que la información sale de la operadora 4G/3G, este ingresa a la nube de internet. En este segmento la seguridad de los datos está comprometida, ya que se desconoce la naturaleza con la que se maneja la misma. Para solventar esta particularidad se propone la implementación de una VPN (Virtual Private Network) que garantice la privacidad de los datos cuando la información es transmitida sobre la red el operador y la nube de internet. En la Figura 4.28, se muestra los componentes de la infraestructura lógica que intervienen para su implementación. En [49], Akun et.al. analiza los diferentes tipos de VPN que se pueden establecer en una red de datos. De los modelos que se exponen en el documento, la VPN de tipo VPLS (Virtual Private LAN Segment) es la que se ajusta a los requerimientos de nuestra infraestructura lógica. La nube de internet es usada para establecer una “línea dedicada” o tunel entre los dispositivos VPN. El tunel no es más que un tipo de encapsulación
71
Figura 4.28: VPN IPSec para la red de Telemedicina de un protocolo sobre otro protocolo, haciendo que la información del primero sea transparente al segundo. La encapsulación que utilizará la VPN para la red de telemedicina es de tipo IPsec (Internet Protocol security). Este tipo de encapsulación incluye una serie de estándares propuestos por el IETF (Internet Engineering Task Force), que introducen mecanismos de seguridad en la capa de red. Dentro de estos protocolos de seguridad se encuentra AH (Authentication Header), ESP (Encapsulating Security Payload), Sas (Security Associations), administración de claves y algoritmos de seguridad. AH permite la autenticación sobre el origen de los datos, integridad y anti- replicación de los mismos, mienstras que ESP provee confidencialidad. Adicionalmente IPSec provee protocolos completos para administración de llaves, tal como IKE (Internet Key Exchange). Para su implementación se requien dos fases, la primera relacionada a ISAKMP (Internet Security Association and Key Management Protocol) y la segunda a IPSec. En la Tabla 4.6 se muestran los parámetros que se deben configurar en los dispositivos sobre los cuales se implementará la VPN, en la primera fase. Parámetros Métodos de distribución de claves Algoritmo de cifrado Algoritmo HASH Método de autenticación Intercambio de claves Vida útil de SA IKE ISAKMP Key
Router Ambulancia ISAKMP AES SHA-1 Pre-shared DH 2 86400 telemedicinaECU
Router ECU 911 ISAKMP AES SHA-1 Pre-shared DH 2 86400 telemedicinaECU
Tabla 4.6: Parámetros de política de fase 1 ISAKMP En la segunda fase, se establece los parámetros para el encapsulamiento de tipo IPSec. En la Tabla 4.7 se puede observar estos parámetros. Respecto a la seguridad en el SIS ECU 911, ésta se encuentra administrada por su de72
Parámetros
Router Ambulancia
Router ECU 911
Conjunto de transformaciones Nombre del host del peer Dirección Ip del peer Red para cifrar
VPN-SET routerEcu911 Ip pública ECU 911 Austro Red WLAN de Ambulancia VPN-MAP ipsec-isakmp
VPN-SET routerAmbu Ip módem Red interna asignada al servidor apps VPN-MAP ipsec-isakmp
Nombre la asignación criptográfica Establecimiento de SA
Tabla 4.7: Parámetros de política de fase 2 IPsec partamento de TI, a través del firewall y del servidor ClearOS, como se puede observar en la Figura 4.26.
4.5 Diseño de la Topología Física de la Red La topología física de la red muestra la distribución física de los dispositivos conectados a la red. Así como la descripción y etiquetado del cableado/medio de transmisión entre los equipos. La ubicación de los equipos en la unidad de ambulancia, se realizará en la parte interior de la misma. El monitor de signos vitales estará ubicado en el armario de dispositivos médicos, a un costado del área de camilla y el multimedia pad, en un soporte que se adapte al costado opuesto del monitor de signos vitales. Esta ubicación puede estar sujeta a modificación de acuerdo a las condiciones de cada ambulancia. El Wi-Fi/Router estará ubicado junto al Módem 4G/3G y deberán contar con anclaje a la pared que divide la cabina con el área de maniobra de los paramédicos, debido a los movimientos bruscos a los que está sujeto la unidad en casos de emergencia. En la Figura 4.29, se puede observar de forma gráfica la ubicación antes descrita.
73
Figura 4.29: Disposición Física de Equipos en Ambulancia
En la Figura 4.30, se muestra el tipo de cableado/medio de transmisión entre los diferentes componentes de la red de telemedicina. En cuanto al cableado entre el router/wifi y el módem, será de tipo UTP categoría 5, con conectores RJ-45. En lo que respecta al medio inalámbrico, la red WLAN de la ambulancia utiliza las técnicas de modulación de la capa física de IEEE 802.11, como DSSS (Direct Sequence Spread Spectrum) o FHSS (Frequency Hoping Spread Spectrum). En los canalización libre de 2.4 GHz o 5 GHz, dependiendo de la versión del estándar IEEE 802.11 (a/b/g/n). Respecto al acceso para la tecnología 4G, éste ya fue analizada en la sección 4.3.4.3.
74
Figura 4.30: Topología Física de la Red de Telemedicina
4.5.1 Selección de dispositivos del sistema. Los dispositivos de red a ser utilizados para la transmisión de los signos vitales e información multimedia desde la ambulancia son el Módem 4G/3G y Router/Wifi. Las 75
características que debe poseer el Módem 4G/3G, son las siguientes: 1. Conexión 4G principal y 3G redundante en configuración 1+0. 2. Interfaz de tipo ethernet para la conexión con el WiFi/Router. 3. Soporte de pasarela para VPN tipo IPSec. De acuerdo a consultas realizadas en los puntos de atención al cliente, las operadores ofrecen módems BA (Banda Ancha), de tipo dongle (conector usb) y mifi (WLAN incluido), para la navegación en internet a través de la red móvil 4G/3G. Los dispositivos que proveen este servicio por lo general no cuentan con una interfaz ethernet, por lo que no cumplirían el segundo requisito. Para solucionar este inconveniente se buscó diversas alternativas, que los operadores ofrecen a través de su red. Al consultar el portafolio para clientes de tipo corporativo, se encontró que los operadores ofrecen la comunicación. La cual consiste en instalar chips móviles en maquinaria e infraestructura para automatizar tareas y acceder a información en tiempo real del estado y ubicación de los equipos. Estos dispositivos se adaptarían a las interfaces que el usuario requiera según la información en los portales web de las operadoras. Respecto al modelo y marca de los equipos que utilizan, no se pudo obtener información directa de los operadores, debido a sus políticas de confidencialidad. Alternativamente se buscó dispositivos que puedan adaptar los módems BA de tipo dongle a una interfaz ethernet y que también soporte el tercer requerimieno respecto a la VPN. En este contexto se encontraron diversas marcas y modelos. En la Tabla 4.8 se puede observar algunas de las prestaciones más sobresalientes que ofrecen estos dispositivos, de acuerdo a los hojas de especificaciones consultado en la página web de cada fabricante. Todos estos equipos, cumplen con las tres condiciones mencionadas al inicio de esta sección. En cuanto a los puertos ethernet, se puede observar que el único equipo que difiere es el modelo TL-MR3020 de la marca TP-Link debido a que posee un solo puerto ethernet, el cual puede funcionar como LAN o WAN dependiendo su configuración. Este equipo en principio sería el adecuado ya que solo se necesita un puerto para la comunicación con el router/wifi. Pero si se toma en cuenta, un futuro crecimiento de la red, este modelo no sería el más apropiado. Por lo tanto, la selección estaría entre los modelos que cuentan con hasta cinco puertos ethernet. El criterio se basa en las necesidades reales para la red de telemedicina y los costos. El modelo de la marca Mofi-Network, es un dispositivo muy versátil, ya que ofrece adicionalmente la integración de más de un operador al contar con dos slots adicionales para tarjetas SIM. Esta característica aparentemente llamativa, no asegura su operatividad al momento de implementarse en la vida real, ya que el módem integrado 76
Tabla 4.8: Adaptadores 3G/4G - WLAN/LAN Marca
Modelo
Ethernet
Pasarela VPN
3G/3G Port
Costo*
Tp-Link Tp-Link Mofi-Network D-Link
TL-MR3020 TL-MR3420 MOFI4500-4GXeLTE DWR-116
1 x 10/100M 5 x 10/100M 5 x 10/100M 5 x 10/100M
si si si si
USB 2.0 USB 2.0 USB 2.0 /2 Sim USB 2.0
$44 $50 $240 $113
(*) Precio referencial obtenido en: http://www.amazon.com Fuente: http://www.tp-link.com http://www.mofinetwork.com http://www.dlink.com
en el equipo, no estaría homologado por la operadora. Por su lado el modelo DWR-116, aparte de aceptar los módems 4G/3G, también lo hace con módems CDMA, CDMAEVDO, pero utilizando el mismo puerto USB. Estas características adicionales de estos dos modelos se reflejan claramente en su costo, que si bien podrían incrementar la disponibilidad de la red, no aseguran su funcionalidad al momento de su implementación. En consecuencia el modelo TL-MR3420 de la marca TP-Link, se adapta a las necesidades de nuestra red y a un costo razonable. La forma de su chasis y disposición de los puertos se pueden observar en la Figura 4.31.
Fuente: http://www.tp-link.com
Figura 4.31: 4G/3G Wireless Router TP-Link TL-MR3420 Respecto al router/wifi, la principal característica que este dispositivo debería tener, es la capacidad para implementar VPNs, específicamente IPSec, debido al diseño estipulado en la sección 4.4.1. Adicionalmente debe contar con WLAN 802.11 b/g/n, con seguridad de tipo WPA2, y listas de control de acceso a nivel MAC. De acuerdo a estas características se ha logrado obtener una extensa lista de equipos disponibles en el mercado, orientados exclusivamente para implementar VPNs. En la Tabla 4.9, se exponen diferentes modelos de dispositivos, junto a sus características que serán tomadas en cuenta para su selección. Cabe mencionar, de acuerdo a las hojas de especificaciones, 77
que todos ellos cuentan con interfaces Gigabit Ethernet, excepto el modelo RV110W. Ya que todos estos dispositivos cumplen con los requerimientos técnicos, se procede a seleccionar el dispositivo de acuerdo a las necesidades reales y su costo-beneficio. Tabla 4.9: Routers VPN Inalámbricos Marca
Modelo
WLAN
WLAN Speed
VNP IPSec
Antenna
Costo*
UTT TP-Link Cisco Cisco
AC750W TL-ER604W RV180W RV110W
802.11 ac/a/b/g/n 802.11 b/g/n 802.11 b/g/n 802.11 b/g/n
750 Mbps max 300 Mbps max 800 Mbps max 90 Mbps max
x10 x30 x10 x5
3x7dBi 2x5dBi 2x1.8 dBi 2x1.8 dBi
$100 $120 $333 $50
(*) Precio referencial obtenido en: http://www.amazon.com Fuente: http://www.uttglobal.com http://www.tp-link.com http://www.cisco.com
En la sección 4.3.2.5 se analizó que la tasa de datos máxima de los servicios de telemedicina es de 5.315 Mbps. Considerando esta cifra, todos los equipos de la lista se adaptan perfectamente a la tasa de datos requerida. Sin embargo, los modelos que ofrecen 300, 750 y 800 Mbps, sobrepasan en gran medida las necesidades reales para la implementación de la red de telemedicina. Además, sus costos se elevan considerablemente de acuerdo a su rendimiento, como se puede observar en la Tabla 4.9. Por consiguiente el modelo RV110W de la marca Cisco se adapta a la tasa de datos requerida y a un costo razonable. Este equipo cuenta con cinco interfaces Fast Ethernet 10/100 Mbps, cuatro para LAN y una para WAN, listas de control de acceso y seguridad WPA2. En la Figura 4.32, se muestra la forma del chasis y la disposición de los diferentes puertos, de acuerdo a su hoja de especificaciones.
Fuente: http://www.cisco.com
Figura 4.32: VPN Cisco RW110W
La selección de los equipos para el monitoreo de los signos vitales y el ingreso de los datos clínicos del paciente, está a cargo de la fase de implementación del proyecto. A manera de ofrecer una perspectiva sobre los dispositivos que se van a utilizar en las ambulancias, a continuación se describen las principales características de cada uno de ellos. 78
• Monitor de Signos Vitales: El modelo OmniExpress de la marca Infinium, es un equipo que tiene la capacidad para adquirir mútiples parámetros como: ECG de 5 derivaciones, NIBP (Non Invasive Blood Pressure), SPO2 (Saturación de Oxígeno), tasa de pulsaciones, temperatura corporal, respiración y medición de CO2 (capnometría). Adicionalmente cuenta con una pantalla touhscreen de 7”, donde se pueden visualizar hasta 32 formas de onda, puerto de comunicación ethernet, rs-232 y comunicación inalámbrica IEEE 802.11 b/g. En la Figura 4.33, se puede observar el panel frontal de este dispositivo y la distribución de los elementos de la interfaz gráfica en la pantalla.
Fuente: http://www.infiniummedical.com
Figura 4.33: Monitor de Signos Vitales Infinium - Omni Express
• Pad Touchscreen: El modelo On-Lap1002 de la marca Gechic, es un monitor portátil touchscreen de 10.1” con puertos HDMI, VGA y resolución de 1280x800 pixeles. Este es un dispositivo plug-and-play que no necesita la instalación de drivers. En la Figura 4.34, se muestra la disposición física de este equipo.
Fuente: http://www.gechic.com
Figura 4.34: Pantalla Touchscreen Gechic On-Lap1002 79
Este dispositivo solo muestra la interfaz gráfica de la aplicación en donde se ingresará los datos clínicos del paciente. Esta aplicación correrá sobre un mini-computador Jetson TK1 de la marca Nvidia, que es un kit de desarrollo de aplicaciones para sistemas embebidos. Este dispositivo ejecuta una distribución personalizada de Linux llamada Linux4Tegra, sobre la cual se configuran las diversas aplicaciones por parte del desarrollador. Posee diversas interfaces, entre ellas: un puerto LAN Gigabit Ethernet, puertos USB 2.0 y 3.0, HDMI, entrada/salida de audio, puerto rs-232, puerto SATA, micro-SD, etc.
80
Capítulo 5 Simulaciones y Análisis de Resultados En este capítulo se analizará el desempeño de los diferentes parámetros, definidos en la sección 4.3.4, de la red LTE como tecnología de acceso primaria del sistema de telemedicina para la transmision de señales biomédicas. En la sección 5.1 se describen los diferentes softwares de simulación utilizados en este proyecto, en la sección 5.2 se establecen las trazas de movilidad, en la sección 5.3 se describen los escenarios de simulación y en la sección 5.4 se analiza los resultados obtenidos.
5.1 Softwares de Simulación 5.1.1 NS-3 Ns-3 es un simulador de red de eventos discretos orientado principalmente para su uso en la investigación y academia. Se categoriza como software libre bajo la licencia GNU GPLv2 y disponible públicamente en el portal web del proyecto www.nsnam.org. Su infraestructura de software permite el desarrollo de modelos de simulación muy realísticos, que incluso se puede considerar como un emulador de red en tiempo real. Se emplea principalmente para la investigación de redes basadas en IP y no-IP, sin embargo su mayor uso se centra en la simulación de redes inalámbricas/IP que involucran modelos como Wi-Fi, WiMax o LTE en las capas 1 y 2 y una gran variedad de protocolos de enrutamiento estático y dinámico como OLSR y AODV para aplicaciones basadas en IP. NS-3, está constituido por un conjunto de librerias de software que trabajan en conjunto. Los usuarios utilizan estas librerias mediante scripts basados en el lenguaje de programación de C++ o Python. Ns-3 emplea la abstracción de algunos conceptos utilizados en el estudio de redes, las principales son:
81
1. Node (Nodo): es la abstracción de un dispositivo de computación básico. A este elemento se le puede agregar diferentes funcionalidades como aplicaciones, protocolos, interfaces físicas. Este término sería el equivalente al llamado host o dispositivo terminal. 2. Application (Aplicación): es la abstracción de un programa de usuario básico que genera alguna actividad para ser simulada. 3. Channel (Canal de comunicación): es la abstracción del medio por el cual la información se envía por la interfaz de un nodo a otro. En ns-3 representa conectar un nodo, a un objeto que representa un canal de comunicación. 4. Net Device (Tarjeta de red): es la abstracción del software driver y el hardware de un dispositivo o tarjeta de red. Este es instalado en un nodo para que este pueda comunicarse con otros nodos a través de un canal de comunicación. 5. Topology Helpers (Facilitador de Topología): es la abstracción de un administrador de red que permite la conexión entre nodos, aplicaciones, canales de comunicación y tarjetas de red, de una forma simplificada. Para la simulación de redes de LTE, ns-3 cuenta con un modulo especializado que permite implementar diversos escenarios de la arquitectura LTE, en la sección 5.1.1.1 se describe este módulo.
5.1.1.1 LENA LTE/EPC Module Este módulo o conjunto de librerias de código abierto, es desarrollado en el CTCC (Centre Tecnologic de Telecomunicacions de Catalunya), que es un centro de investigación sin fines de lucro orientado a las telecomunicaciones, fundado en el 2001. El objetivo de este proyecto está orientado al diseño y evaluación de desempeño de diversos elementos de una red LTE como: • Schedulers para Down-Link y Up-Link. • Algoritmos para la administración de recursos de radio. • Soluciones para la coordinación de interferencias inter-celda. • Administración de mobilidad y balanceo de carga. • Soluciones para redes heterogéneas. • Provisionamiento end-to-end de QoS. 82
• Soluciones para redes Multi-RAT (Multi - Radio Access Technologies). • Sistemas LTE cognitivos. El modelo de simulación LTE-EPC tiene dos componentes principales: • El modelo LTE: este modelo incluye el conjunto de protocolos de Radio de LTE (RRC, PDCP, RLC, MAC, PHY). Estas entidades residen dentro de los nodos UE (User Equipment) y eNB (eNodeB). • El modelo EPC: este modelo incluye las interfaces, protocolos y entidades del core LTE. Estas entidades y protocolos residen dentro de los nodos SGW, PGW y MME, y parcialmente en los nodos eNB. En la Figura 5.1 se muestra el modelo de simulación de la arquitectura LTE del proyecto LENA.
Fuente: http://networks.cttc.es/mobile-networks/software-tools/lena/
Figura 5.1: Modelo de Simulación LENA LTE-EPC La versión que se empleará para la simulación de los distintos escenarios es ns3.19, la cual se ejecuta en la distribución de Linux Ubuntu 12.04 LTS “Precise Pangolin”. Los pasos para su instalación se especifican en el Anexo 3.
5.1.2 SUMO SUMO (Simulation of Urban MObility) [50], es una suite gratuita y libre para la simulación de tráfico, disponible desde el 2001 por parte del Instituto de Sistemas de Transportación de Berlín. SUMO permite el modelamiento intermodal de sistemas de tráfico incluyendo vehículos terrestres, transporte público y peatones. SUMO incluye
83
una variedad de herramientas que permiten manejar tareas como descubrimiento de ruta, visualización, importar red de vias y cálculos de emisión de gases. Esta plataforma ofrece algunas características, tales como: • Simulación microscópica: modelación explícita de vehículos, peatones y transporte público. • Interacción en línea: control de la simulación con TraCl • Simulación de tráfico multimodo. • Programación de luces de tráfico importados o generadas automáticamente por SUMO. • Tamaño de la red y número de vehículos simulados sin limitaciones. • Compatiblidad con formatos: OpenStreetMap, VISUM, VISSIM, NavTeq. • SUMO es implementado en C++ y usa solo librerias portátiles. La configuración de los diferentes parámetros y creación de archivos, se los realiza a través de la línea de comandos. Sin embargo SUMO posee una interfaz gráfica para la visualización de la movilidad de los vehículos durante una simulación. En la Figura 5.2 se muestra esta interfaz gráfica.
Figura 5.2: Interfaz Gráfica SUMO
La versión que se empleará para la simulación es SUMO 0.25, instalado en el sistema operativo Linux 12.04 LTS. Los pasos para su instalación se precisan en el Anexo 3. 84
5.2 Trazas de movilidad Una vez que se han definido las herramientas para la simulación, el primer paso es la obtención de las trazas de movilidad o vectores discretos de posición y velocidad que representará el movimiento de las ambulancias. A continuación se describe este proceso. Para obtener las trazas de movilidad, primero se va a definir la ubicación geográfica en donde se van a movilizar las ambulancias. El criterio para determinar esta área, se basa en el análisis realizado en la sección 1.4 respecto a las estadísticas de incidentes de emergencia registrados en la ciudad de Cuenca por parte del SIS ECU 911 Austro. En este apartado se define que el segundo tipo de emergencia más reportado son los relacionados a los accidentes de tránsito. Esto tipo de emergencias tienen un elevado índice de morbilidad en la ciudad de Cuenca de acuerdo a [51], por lo que los tiempos de respuesta y la correcta atención pre-hospitalaria pueden determinar la supervivencia, o no, del paciente. En la Figura 5.3 se muestra el mapa de emergencias de tránsito reportadas en el cantón Cuenca. En este mapa se observa que los incidentes se provocan en las intersecciones y redondeles de la urbe, especialmente en los redondeles ya que estos sectores muestran indicativos de color rojo-naranja. Una de las rotondas identificadas en el mapa como la intersección de la Avenida de las Américas y la calle Turuhuayco, es una zona de alto riesgo debido a la confluencia de hasta seis arterias viales, cuatro de ellas doble vía, que comunican a grandes zonas sub-urbanas de la ciudad de Cuenca. Por lo tanto, se configura como el ambiente más propicio para evaluar el desempeño de la red de telemedicina. El área seleccionada para simular la movilidad de las ambulancias es de 3 Km2 , con centro aproximado al redondel de la Avenida de las Américas y Turuhuayco. En la Figura 5.4, se muestra el mapa de este sector.
85
Figura 5.3: Análisis de Emergencias de Tránsito Reportadas Cantón Cuenca Periodo Enero 2014 - Septiembre 2015
Fuente: https://www.openstreetmap.org
Figura 5.4: Area para simulación de movilidad de ambulancias 86
Una vez que se ha seleccionadao el área, se procede a exportar un archivo con extensión *.osm, el cual contiene toda la información de los elementos asociados al área del mapa seleccionado. Este proceso es indispensable ya que a partir de este archivo el simulador SUMO procesa los datos del mapa para construir las rutas de los vehículos. Previa a la simulación en SUMO, es necesario la edición del archivo *.osm, para evitar que vías peatonales sean consideradas calles para la circulación de vehículos, eliminación o integración de semáforos, etc. Para este efecto, se utiliza un applet desarrollado en Java, bajo el nombre de JOSM (Java OpenStreetMap editor) [52], el cual permite realizar modificaciones en la estructura del archivo *.osm. En la Figura 5.5 se puede observar el entorno de este editor, al editar el mapa del área seleccionada.
Figura 5.5: Entorno de JOSM para Edición de Mapa OpenStreetMap
Una vez que el mapa ha sido editado, se procede a realizar la simulación de movilidad a través del simulador SUMO. En la Tabla 5.1 se detallan los parámetros considerados para la generación de las trazas de movilidad. Luego de generar el archivo de simulación de movilidad, éste debe ser exportado al formato *.tcl para que el simulador NS-3 pueda adoptar la movilidad de los nodos de acuerdo a la simulación generada por SUMO. Para visualizar, la movilidad de los nodos creados por la simulación, se hace uso de la interfaz gráfica SUMO-GUI. En la Figura 5.6 se puede observar números en negrita que representan la id del vehículo y su posición, cuando ha transcurrido 10 s. de simulación. De la misma forma, en la Figura 5.7, se puede observar a los identificadores de los vehículos y su nueva posición cuando ha transcurrido 45 s de simulación. Es nece87
Tabla 5.1: Parámetros de Simulación SUMO Parámetro Tiempo de Simulación Número de vehículos Area de Simulación Tipo de Vehículo Velocidad Máxima Elección de Ruta Algoritmo de Enrutamiento
Valor 100 s. 100 3 Km2 Emergency 100 Km/h Random Dijsktra
sario señalar que la simulación se llevó a cabo con 100 vehículos, pero por razones de ilustración de la movilidad, son visibles solo 6 vehículos en las Figuras 5.6 y 5.7.
Figura 5.6: Visualización de simulación de movilidad en SUMO-GUI (Tiempo=10s).
88
Figura 5.7: Visualización de simulación de movilidad en SUMO-GUI (Tiempo=45s)
5.3 Simulación NS-3 La simulación del envío de paquetes de datos desde la ambulancia hasta el centro de operaciones del SIS ECU 911, a través de la red LTE, se va a realizar mediante el software NS-3. En la sección 5.3.1 y 5.3.2 se definirán los parámetros para cada uno de los escenarios a ser configurados. A continuación se decriben las especificaciones sobre la ubicación de la radio base y el tipo de conexión entre la arquitectura de la red LTE y el router de acceso del SIS ECU 911. • Ubicación de la radio base o eNodeB: Otecel S.A. (Movistar), se consideró la operadora que mejor prestaciones brindaba como red de acceso para el sistema de telemedicina, de acuerdo al análisis en la sección 4.3.2.5. Se procedió a realizar consultas al personal de mantenimiento de las estaciones base, sobre la ubicación de la estación más cercana al redondel de la Avenida de las Américas y Turuhuaico. Como respuesta se obtiene que la estación más próxima es la que se 89
Figura 5.8: Ubicación de Radio Base UAZ_POLITE_SALESIANA Operadora Otecel S.A. encuentra en las coordenadas WGS Lat: -2.88294444 Lon: -78.98777778, ubicación que se puede observar en la Figura 5.8. La distancia desde la radio base hasta el redondel es de aproximadamente 320 mts, en línea recta.
• Enlace P-GW - Servidor SIS ECU 911: La conexión entre el PDN Gateway de la red LTE y el servidor SIS ECU 911 Austro, se da a través de un enlace punto a punto de 100 Gigabits/s con retardo de 10 ms, que emulará la capacidad y latencia de un enlace de fibra óptica.
5.3.1 Escenario 1 En el escenario de simulación 1 se evalúa la potencia de la señal recibida por los equipos de usuario de los nodos móviles (ambulancias) al utilizar los modelos de propagación Cost231, Log Distance y Friis y su efecto en el throughput, retardo y pérdida de paquetes en el enlace ascendente y descendente. En la Tabla 5.2 se observa la configuración de los parámetros de la red LTE, tráfico, y movilidad para los requerimientos antes mencionados.
90
Tabla 5.2: Parámetros de Simulación Escenario 1 Tipo de Parámetro
LTE
Trafico Movilidad
Parámetro Scheduler Path Loss Model DL Earfcn UL Earfcn Bandwidth Channel Antena UE Power Tx UE Noise Figure eNodeB Power Tx eNodeB Noise Figure # UEs (Ambulancias) # eNodeBs EPS Bearer Protocolo UL/DL Bit Rate UL/DL Tamaño de Paquetes Tiempo de Simulación Movilidad UE’s
Valor Proportional Fair Cost231/Log Distance/Friis 600 (1930 MHz) 18600 (1850 MHz) 25 RBs (5 MHz) Isotrópica 24 dBm 7 dB 43 dBm 2 dB 5 1 Default UDP 512 Kbps 1024 bytes 50 s Trazas SUMO
5.3.2 Escenario 2 En este escenario, se evaluará el desempeño del enlace ascendente para el flujo de datos desde el módem de la ambulancia hasta el servidor del SIS ECU 911 Austro. El número de usuarios varía de acuerdo a la Tabla 5.3, considerando un número fijo de 5 unidades en cada distribución. Respecto a la tasa de datos, los módems de las ambulancias transmitirán datos en tres tasas diferentes y los usuarios adicionales, a determinados valores como se muestra en la Tabla 5.3 Tabla 5.3: Distribución de Usuarios para el Escenario de Simulación 2 Distribución Ambulancia Usuario Trafico 1 Usuario Trafico 2
10 u 5 3 2
20 u 5 7 8
40 u 5 17 18
60 u 5 27 28
Tasa de Datos 0.512/1.024/1.536 Mbps 0.256 Mbps 0.512 Mbps
En la Tabla 5.4 se exponen los parámetros de simulación relacionados a la red LTE, tráfico y movilidad. De este escenario se obtendrá los parámetros throughput, latencia y pérdida de paquetes, al incrementar el número de usuarios, a diferentes tasas de datos y al incrementar el ancho de banda del canal. 91
Tabla 5.4: Parámetros de Simulación Escenario 2 Tipo de Parámetro
LTE
Tráfico
Movilidad/Posición
Parámetro Scheduler Path Loss Model DL Earfcn UL Earfcn Bandwidth Channel Antena UE Power Tx UE Noise Figure eNodeB Power Tx eNodeB Noise Figure # eNodeBs EPS Bearer Protocolo UL/DL Tamaño de Paquetes UL/DL Tiempo de Simulación UEs Ambulancias UEs Tráfico Adicional 1 UEs Tráfico Adicional 2
Valor Proportional Fair Friis 600 (1930 MHz) 18600 (1850 MHz) 5, 10, 20 MHz Isotrópica 24 dBm 7 dB 43 dBm 2 dB 1 GBR - CONV_VOICE UDP 1024 bytes 50 s Trazas SUMO Constante/Circular Randómico Constante/Malla
5.4 Análisis de Resultados 5.4.1 Análisis de Resultados de Escenario 1 El objetivo del primer escenario es analizar el comportamiento de la potencia recibida por el equipo de usuario o UE de las ambulancias mientras el vehículo realiza su recorrido durante el tiempo de simulación. Este dato se obtiene mediante la extracción del parámetro RSRP (Reference Signal Received Power), que hace referencia al promedio lineal de las contribuciones de potencia de los recursos de radio que transportan señales de referencia de una celda específica, dentro del ancho de banda del canal [53]. En la Figura 5.9, 5.10 y 5.11 se observa el parámetro RSRP en dBm de cada una de las ambulancias (RSRP1 = Ambulancia 1, RSRPn = Ambulancia n) para los modelos de propagación COST231, Log-Distance y Friis respectivamente. En estas tres figuras, se puede observar que la potencia de cada ambulancia son distintas, debido a que cada una posee trayectorias diferentes, generadas por el simulador de tráfico SUMO. También, se evidencia que la ambulancia que menor potencia percibe, es la número 4, mientras que 1 y 5 son las que detectan mayor potencia en los UEs. En la Figura 5.9, se puede observar el gran efecto de atenuación que sufre la señal 92
cuando se utiliza el modelo de propagación COST 231. Los niveles de potencia oscilan entre -130 y -95 dBm aproximadamente, pero solo dos de las cinco ambulancias logran valores superiores a -110 dBm. Este modelo COST231 está basado en el modelo empírico de Okumura-Hata, pero extendido para frecuencias de hasta 2000 MHz. Si bien este modelo toma en cuenta el tipo de área (urbana, sub-urbana y rural) en donde se realiza el análisis, es el que mayor pérdidas muestra en su aplicación.
Figura 5.9: RSRP - Modelo de Propagación COST 231
En la Figura 5.10 se exponen los diferentes niveles de potencia, al implementar el modelo Log-Distance. Al aplicar este modelo, los niveles de potencia reportados por los UEs de las ambulancias mejoran respecto al modelo COST231, obteniéndose niveles entre -120 y -90 dBm. Este modelo calcula las pérdidas de acuerdo a la distancia trasmisor-receptor y a un factor que representa el ambiente en donde se propaga la misma.
93
Figura 5.10: RSRP - Modelo de Propagación Log Distance
El tercer modelo implementado en la simulación del escenario 1 es el modelo de propagación de Friis o del “espacio libre”, el cual solo toma en cuenta la distancia entre el trasmisor y receptor como factor atenuador de la potencia de la señal. Con este modelo los niveles de potencia RSRP se ubican entre -80 y -60 dBm.
Figura 5.11: RSRP - Modelo de Propagación Friis
El efecto directo de la atenuación de la señal, es la disminución de la calidad de servicio de una red de comunicación inalámbrica. En la Tabla 5.5, 5.6 y 5.7 se exponen los resultados de throughput, retardo y pérdida de paquetes al configurar el escenario de simulación con los modelos de propagación COST231, Log Distance y Friis, respectivamente.
94
En la Tabla 5.5, se puede observar los valores de desempeño al utilizar el modelo de propagación COST 231. Respecto a los valores del enlace Down Link, el throughput de la red es igual a la tasa de datos configurada en la Tabla 5.2, a excepción de la ambulancia número 4, consecuencia de los bajos niveles de potencia RSRP de acuerdo a la Figura 5.9. Respecto a los valores de retardo y pérdida de paquetes, estos se encuentran dentro de los umbrales requeridos para el establecimieno de servicios de telemedicina, de acuerdo a la Tabla 4.5. En cuanto a los valores de UpLink, estos se encuentran muy afectados cuando se aplica el modelo de propagación COST231. Los mejores indicadores los logra la ambulancia 1, con el mejor thoughput, menor retardo y pérdida de paquetes. Pero establecer un servicio de telemedicina bajo estos valores, es poco recomendable, ya que si bien el throughput y retardo son aceptables, un 40% de pérdida de paquetes es demasiado alto. Tabla 5.5: Desempeño de la Red LTE - Modelo de Propagación COST231 Enlace
Up Link
Down Link
Ambulancia 1 2 3 4 5 1 2 3 4 5
Throughput Promedio
Retardo Promedio
Pérdida de Paquetes
304.081 Kbps 63.309 Kbps 40.6 Kbps 0 Kbps 209.171 Kbps 513.682 Kbps 513.61 Kbps 510.22 Kbps 426.318 Kbps 513.692 Kbps
160.608 ms 522.264 ms 464.512 ms N.A. 209.632 ms 15.163 ms 18.508 ms 39.392 ms 70.843 ms 15.637 ms
40.96 % 91.392 % 92.096 % 100 % 59.456 % 0% 0.032 % 0.672 % 17.024 % 0%
En la Tabla 5.6 se exponen los valores de desempeño de la red, considerando el modelo de propagación Log-Distance. Los valores en el enlace descendente se normalizan para todas las ambulancias, a diferencia del modelo Cost 231. A su vez, en el enlace ascendente se mejora los valores de throughput pero se mantiene una tasa de pérdida de paquetes muy alta.
95
Tabla 5.6: Desempeño de la Red LTE - Modelo de Propagación Log Distance Enlace
Up Link
Down Link
Ambulancia 1 2 3 4 5 1 2 3 4 5
Throughput Promedio
Retardo Promedio
Pérdida de Paquetes
375.53 Kbps 231.22 Kbps 168.65 Kbps 0 Kbps 348.88 Kbps 513.67 Kbps 513.63 Kbps 513.69 Kbps 513.64 Kbps 513.68 Kbps
152.815 ms 343.582 ms 233.716 ms N.A. 183.201 ms 14.96 ms 16.94 ms 17.42 ms 20.06 ms 14.66 ms
27.168 % 55.008 % 67.168 % 100 % 32.384 % 0% 0.032% 0% 0.032 % 0%
En la Tabla 5.7, se muestran los valores de desempeño de la red, al implementar el modelo de propagación de Friis. Al no considerarse atenuaciones, mas que solo las provocadas por la distancia entre el transmisor y receptor, el throughput de los enlaces descendente y ascendente son los máximos. Respecto al retardo de los paquetes, en el enlace ascendente se observa un mayor valor esto debido a la menor potencia de los dispositivos UEs y a las retransmisiones de la capa física de la red inalámbrica, como su principal efecto. En cuanto a la tasa de pérdida de paquetes es muy cercana a cero. Tabla 5.7: Desempeño de la Red LTE - Modelo de Propagación Friis Enlace
Up Link
Down Link
Ambulancia 1 2 3 4 5 1 2 3 4 5
Throughput Promedio
Retardo Promedio
Pérdida de Paquetes
513.59 Kbps 513.59 Kbps 513.59 Kbps 513.59 Kbps 513.59 Kbps 513.66 Kbps 513.65 Kbps 513.68 Kbps 513.69 Kbps 513.67 Kbps
23.929 ms 23.930 ms 23.931 ms 23.932 ms 23.933 ms 16.999 ms 17.999 ms 14.999 ms 13.999 ms 15.999 ms
0.032 % 0.032 % 0.032 % 0.032 % 0.032 % 0.032 % 0.032 % 0% 0% 0%
5.4.2 Análisis de Resultados de Escenario 2 El objetivo del segundo escenario se resume en analizar la capacidad de gestión de los recursos de radio por parte de los schedulers de la red LTE, al agregarse tráfico por parte 96
de otros usuarios en la red. Los indicadores de desempeño serán obtenidos para el flujo de datos ascendente entre las ambulancias y el centro de operaciones del SIS ECU 911 Austro. En este contexto, el modelo de propagación que mejor se adapta para visualizar el efecto directo de la gestión de los recursos de radio en el enlace uplink es el modelo de Friis, al considerar como único atenuante de la señal, la distancia entre la ambulancia y el eNodeB y al brindar la mejor calidad de servicio en el enlace ascendente, respecto de los modelos COST231 y Log-Distance, como se muestra en la sección 5.4.1. El escenario planteado en 5.3.2 se puede considerar un escenario cŕitico o de máximo esfuerzo, ya que los usuarios que crean tráfico, requieren de una conexión dúplex constante para tasas de datos de 256 y 512 Kbps. Los resultados de las simulaciones han sido organizados en dos grupos. El primero hace referencia de los resultados al variar la tasa de transmisión de los paquetes de la ambulancia, con un ancho de banda de canal constante (5Mhz), mientras que el segundo grupo muestra los resultados al variar el ancho de banda del canal con una tasa de trasmisión constante (1.024 Mbps). A continación es exponen los resultados del primer grupo. En la Figura 5.12, se expone el throughput promedio, obtenido por las ambulancias, cuando se transmite información con tres tasas de datos diferentes. Se observa que el throughput decrece de manera considerable cuando se envia información a tasas de datos de 1.536 Mbps y 1.024 Mbps, lo que no sucede para una tasa de datos de 512 Kbps, la cual disminuye pero en menor proporción respecto de las dos primeras.
Figura 5.12: Throughput Promedio Escenario 2 (BW = 5 MHz)
97
En la Figura 5.12, también se observa el efecto de los agendadores al momento de gestionar los recursos de radio, asegurando la entrega de un determinado bloque de recursos de radio, dependiendo de la disponibilidad de canales y del perfil de usuario. Este proceso se evidencia en el comportamiento del throughput al enviar información con una tasa de datos de 1.536 Mbps. Se puede observar que a partir de los 20 usuarios, éste toma la forma del throughput de 1.024 Mbps, y que al partir de los 40 usuarios toma la forma del throughput de 512 Kbps. Respecto al retardo promedio, en la Figura 5.13 se puede observar que la tendencia de este indicador es de crecimiento, conforme aumenta el número de usuarios de la red. Sin embargo los valores que presenta este parámetro para las diferentes tasas de datos, se pueden considerar aceptables, tomando como referencia los valores requeridos para el establecimiento de servicios de telemedicina, en la Tabla 4.5.
Figura 5.13: Retardo Promedio Escenario 2 (BW = 5 MHz)
Con relación a la tasa de pérdida de paquetes, la Figura 5.14 expone los resultados del escenario 2. Se puede observar, que los valores son muy altos a partir de los 20 usuarios. Esto se debe al procedimiento de asignación de los recursos de radio y slots de tiempo, gestionados por los algoritmos de agendamiento o schedulers. Los cuales garantizan un determinado throughput y slot de tiempo a todos los usuarios, pero con una tasa de pérdidad de paquetes muy elevada. Cabe señalar que este escenario es muy exigente ya que se envia paquetes constantemente por parte de todos los usuarios tanto en el enlace Uplink y Downlink.
98
Figura 5.14: Tasa de Pérdida de Paquetes Escenario 2 (BW= 5 MHz)
El segundo grupo de simulaciones evalua el desempeño de la red de este mismo escenario al enviar información con una tasa de datos de 1.024 Mbps desde las ambulancias, pero con anchos de banda de canal ascendente y descendente de 5, 10 y 20 MHz, el máximo estipulado para LTE, de acuerdo a lo descrito en la sección 4.3.4.3. En la Figura 5.15 se puede obsevar el comportamiento del throughput, el cual mejora considerablemente al incrementarse el ancho de banda del canal de radio. Esto debido a que existe más bloques de recursos disponibles. Al utilizar 10 MHz de ancho de banda, el troughput se mantiene constante hasta los 40 usuarios mientras que al utilizar 20 MHz, el throughput se mantiene estable, hasta por lo menos con 60 usuarios, cifra tope analizada en este escenario.
99
Figura 5.15: Throughput Promedio Escenario 2 (BR: 1.024 Mbps)
Con respecto al retardo promedio, se observa en la Figura 5.16, que los valores obtenidos al utilizar 10 MHz de ancho de banda, estos se mantienen entre 20 a 30 ms hasta los 40 usuarios, pero al llegar el valor de 60 usuarios este se incrementa hasta 150 ms. Por otro lado al utilizar 20 MHz, de ancho de banda se obtiene un retardo casi uniforme con valores entre 20 y 30 ms aproximadamente.
Figura 5.16: Retardo Promedio Escenario 2 (BR: 1.024 Mbps)
En cuanto a la tasa de pérdida de paquetes, esta se mantiene cerca del 0% hasta los cuarenta usuarios al emplear 10 MHz de ancho de banda, mientras que al transmitir en 100
un canal de 20 MHz, la tasa pérdida de paquetes es cercana a cero hasta por lo menos 60 usuarios.
Figura 5.17: Tasa de Pérdida de Paquetes Escenario 2 (BR: 1.024 Mbps)
Con los últimos datos, presentados en las Figuras 5.15, 5.16 y 5.17, se evidencia que la disponibilidad de recursos de radio, es indispensable al momento de enviar información que requiera especial tratamiento. El establecimiento de agendadores en los mecanismos de control de acceso al medio, están principalmente diseñados para asegurar el servicio de determinadas aplicaciones que emplea el usuario común. El sistema de telemedicina, se debe adaptar a estas consideraciones, al no existir una política de exclusividad cuando se transmita datos de emergencia.
101
Capítulo 6 Conclusiones Y Recomendaciones 6.1 Conclusiones • Se diseñó una infraestructura de telecomunicaciones para la transmisión de signos vitales de pacientes en la ciudad de Cuenca, mediante una red de telemedicina que integra los servicios de la red celular 4G como acceso inalámbrico para el envío de señales biomédicas, de pacientes en vehículos de emergencia hacia el centro de operaciones del SIS ECU 911 Austro. • Se determinó que el promedio del número de incidentes de tipo salud en los periodos 2012-2015, aumenta hasta en un 30% en cada año. Lo cual trae consigo la necesidad de la tecnificación y mejoramiento de los sistemas de comunicación entre las diferentes instituciones de salud de la ciudad y el SIS ECU 911 Austro. • A través del estudio del estado del arte se determinó que los servicios de una red de telemedicina móvil, en situaciones de emergencia, debe considerar la transmisión de audio y vídeo de calidad de diagnóstico, señales biomédicas y transferencia de archivos clínico-médicos del paciente; en este mismo contexto, se determinó el rango aceptable en cuanto a retardo y pérdida de paquetes que estos servicios pueden tolerar. • Se determinó que la red 4G-LTE es la tecnología de acceso inalámbrico más idónea para la transmisión de signos vitales de pacientes en situaciones de emergencia, por las siguientes razones: considerable ancho de banda del enlace ascendente, para vehículos en movimiento, interoperabilidad con redes de tercera generación, para establecer una red redundante y por el nivel de cobertura en la ciudad de Cuenca.
102
• Mediante la simulación del escenario 1 se determinó que los modelos de propagación COST231 y Log-Distance, atenúan la señal del enlace ascendente, provocando la disminución del throughput, incremento de retardo y tasa de pérdida de paquetes al enviar información desde los vehículos de emergencia hacia el servidor SIS ECU 911 Austro; en este mismo contexto, se determinó que el modelo de propagación de Friis, permite obtener el máximo desempeño de la red, al mejorar los indicadores de calidad de servicio. • Mediante la simulación del escenario 2, se determinó que para un canal de transmisión de 5 MHz de ancho de banda, los indicadores de calidad de servicio disminuyen a medida que aumenta el número de usuarios de la red 4G y al incrementarse la tasa de transmisión de datos del flujo de información que envian los vehículos de emergencia; en este mismo contexto se determinó que los indicadores de calidad de servicio mejoran conforme aumenta los recursos de radio del canal de transmisión.
6.2 Recomendaciones y Trabajo Futuro • Se recomienda investigar nuevas políticas en las redes de acceso inalámbrico que permitan la identificación del tráfico de datos de una red de telemedicina en situaciones de emergencia, que habiliten la atención obligatoria y primaria en cuanto a recursos de radio, asignación de slots de tiempo, disminución de latencia, perdida de paquetes, etc. que garanticen el flujo de datos ambulanciacentro de operaciones de emergencia. • Respecto a la seguridad de los datos del paciente, se recomienda implementar niveles de autenticación y acceso a los datos, por parte de los usuarios de la red de telemedicina. Como también la integración automática de dispositivos médicos a través de autoridades de certificación centralizadas. • Se recomienda, investigar la ampliación de la cobertura de la red de telemedicina a zonas rurales o de dificil acceso, mediante la integración de otro tipo de tecnologías de comunicación inalámbrica que permitan establecer un canal fiable para el envío de señales biomédicas.
103
Bibliografía [1] D. Malan, F. J. Thaddeus, M. Welsh, and S. Moulton, “CodeBlue : An Ad Hoc Sensor Network Infrastructure for Emergency Medical Care,” in Proceeding on the MobiSys 2004 Workshop on Applications of Mobile Embedded Systems, pp. 12–14, ACM, 2004. [2] J. Suganthi, N. Umareddy, and N. Awasthi, “Medical alert systems with telehealth amp; telemedicine monitoring using gsm and gps technology,” in Computing Communication Networking Technologies (ICCCNT), 2012 Third International Conference on, pp. 1–5, July 2012. [3] C. Hu, W. Liu, Y. Pan, Z. Liu, J. Liao, and M.-H. Meng, “Wireless acquisition system for the real ambulance field,” in Robotics and Biomimetics, 2008. ROBIO 2008. IEEE International Conference on, pp. 1081–1086, Feb 2009. [4] A. Corradini and C. Gheorghiasa, “Cambulance: A live video streaming system for ambulance services,” in Information and Communication Technology Research (ICTRC), 2015 International Conference on, pp. 100–103, May 2015. [5] A. Butean, A. David, C. Buduleci, and A. Daian, “Auxilum medicine: A cloud based platform for real-time monitoring medical devices,” in Control Systems and Computer Science (CSCS), 2015 20th International Conference on, pp. 874–879, May 2015. [6] T. Huang, L. Wang, and W. Xu, “System parameter adjustment of fm-dcsk uwb for different medical environments,” in Medical Information and Communication Technology (ISMICT), 2015 9th International Symposium on, pp. 162–165, March 2015. [7] F. Wei, Y. Kotake, M. Haque, Y. Fukunaga, T. Gouda, X. Lu, and K. Mori, “Autonomous community adjustment technology for real-time transmission of emergency information,” in Autonomous Decentralized Systems (ISADS), 2011 10th International Symposium on, pp. 240–247, March 2011.
104
[8] A. Khelil, “Pa2pa: Patient to patient communication for emergency response support,” in e-Health Networking Applications and Services (Healthcom), 2011 13th IEEE International Conference on, pp. 237–240, June 2011. [9] A. Zvikhachevskaya, G. Markarian, and L. Mihaylova, “Quality of service consideration for the wireless telemedicine and e-health services,” in Wireless Communications and Networking Conference, 2009. WCNC 2009. IEEE, pp. 1–6, April 2009. [10] N. Challita, R. Abdallah, and N. Taher, “Analysis and enhancement of wimax scheduling for telemedicine support,” in Advances in Biomedical Engineering (ICABME), 2013 2nd International Conference on, pp. 61–64, Sept 2013. [11] K. Lam, H. Tung, K. Tsang, and K. Ko, “Wimax telemedicine system for emergence medical service,” in Information, Communications and Signal Processing, 2009. ICICS 2009. 7th International Conference on, pp. 1–5, Dec 2009. [12] I. Rehman, N. Philip, and R. Istepanian, “Performance analysis of medical video streaming over 4g and beyond small cells for indoor and moving vehicle (ambulance) scenarios,” in Wireless Mobile Communication and Healthcare (Mobihealth), 2014 EAI 4th International Conference on, pp. 211–216, Nov 2014. [13] P. Sakthi and R. Sukanesh, “A reliable and fast routing data transmission protocol for wi-fi based real-time patient monitoring system,” in Electronics and Communication Systems (ICECS), 2014 International Conference on, pp. 1–5, Feb 2014. [14] T. Brodziak, I. Forkel, P. Irla, P. Kornatowski, and P. Seidenberg, “Secure and reliable communication for telemedical applications in emergency medical services,” in ICT meets Medicine and Health (ICTMH2013) Workshop, (Bremen, Germany), 2013. [15] L. Hauenstein, T. Gao, T. W. Sze, D. Crawford, A. Alm, and D. White, “A crossfunctional service-oriented architecture to support real-time information exchange in emergency medical response,” in Engineering in Medicine and Biology Society, 2006. EMBS ’06. 28th Annual International Conference of the IEEE, vol. Supplement, pp. 6478–6481, Aug 2006. [16] M. Skorning, S. Bergrath, D. Rörtgen, J. Brokmann, S. Beckers, M. Protogerakis, T. Brodziak, and R. Rossaint, “[e-health in emergency medicine - the research project med-on-@ix],” Der Anaesthesist, vol. 58, pp. 285–292, March 2009. [17] M. Protogerakis, A. Gramatke, and K. Henning, “A system architecture for a telematic support system in emergency medical services,” in Bioinformatics and 105
Biomedical Engineering , 2009. ICBBE 2009. 3rd International Conference on, pp. 1–4, June 2009. [18] M.-H. Tsai, R. Chen, J.-F. Sung, E. Wu, E. Wei, Z.-H. Wu, and J.-S. Liang, “Efficient and flexible emergency communications in next generation mobile network,” in e-Business Engineering (ICEBE), 2011 IEEE 8th International Conference on, pp. 96–101, Oct 2011. [19] S. Hameed, A. Zahirul Alam, N. Nuh, and N. Salim, “Integrated medical emergency model: An interactive web-based database,” in Computer and Communication Engineering (ICCCE), 2010 International Conference on, pp. 1–6, May 2010. [20] T. Hidayat and S. Supangkat, “Mobile cloud design of referral for emergency medical service support system,” in ICT For Smart Society (ICISS), 2014 International Conference on, pp. 222–225, Sept 2014. [21] A. Freitas Duarte, H. Cesar, A. Mendes Marques, P. Mazzoncini de Azevedo Marques, and G. Alves Pereira Junior, “Prehospital electronic record with use of mobile devices in the samu’s ambulances in ribeirão preto-brazil,” in ComputerBased Medical Systems (CBMS), 2015 IEEE 28th International Symposium on, pp. 362–363, June 2015. [22] “Estadísticas Centros estadisticas/, 2015.
ECU
911.”
http://www.ecu911.gob.ec/
[23] “Protocolos de Atención Prehospitalaria para Emergencias Médicas.” http://www.colegiomedicoguayas.com/GUIAS%20MSP/PROTOCOLOS% 20DE%20ATENCION%20PREHOSPITALARIA%20PARA%20EMERGENCIAS% 20MEDICAS.pdf, 2011. Ministerio de Salud Pública del Ecuador. [24] “Instructivo para el Llenado del Registro Diario de Atenciones y Consultas Ambulatorias.” https://aplicaciones.msp.gob.ec/salud/ archivosdigitales/documentosDirecciones/dnn/archivos/ instructivo-rdaca__final_04_09_2013.pdf, 2013. Ministerio de Salud Pública del Ecuador. [25] N. Llerena and L. Cárdenas, “Protocolo de Transferencia de Información de Pacientes en Puntos de Transición.” http://hvcm.gob.ec/wp-content/uploads/2015/03/ PROTOCOLO-DE-TRANSFERENCIA-DE-INFORMACION-DE-PACIENTES.pdf, 2015. Hospital Vicente Corral Moscoso.
106
[26] “EM400™ Radio Móvil Industrial.” http://www.sicom.com.uy/recursos/ em400/LS-EM400-PS-LR.pdf, 2009. Motorola, Inc. [27] “EP450™ Radio Portátil Industrial.” http://www.motorolasolutions. com/content/dam/msi/docs/business/products/two-way_radios_and_ pagers_-_business/latin_america_-_portable_radios/wide_area_ large_business/_documents/staticfile/ls-p450-ps-lr_low.pdf, 2005. Motorola, Inc. [28] “XTS™1500 Digital Portable Radio.” http://www.motorolasolutions.com/ en_xl/products/two-way-radios/portable-radios/xts1500.html, 2008. Motorola, Inc. [29] B. Delgutte, “Course materials for HST.582J / 6.555J / 16.456J Biomedical Signal and Image Processing.” http://ocw.mit.edu, 2007. Massachusetts Institute of Technology. [30] K. StayWell, “Vital Signs (Body Temperature, Pulse Rate, Respiration Rate, Blood Pressure).” http://www.hopkinsmedicine.org/healthlibrary/, 2015. [31] M. Laborde, “Medida de la saturación de oxígeno por medio optico,” XIII Seminario de Ingeniería Biomédica Facultades de Medicina e Ingeniería Universidad de la República Oriental del Uruguay Montevideo, 2004. [32] A. Reisner, G. Clifford, and R. Mark, “ Course materials for HST.582J / 6.555J / 16.456J, Biomedical Signal and Image Processing.” http://ocw.mit.edu, 2007. Massachusetts Institute of Technology. [33] V. López and W. Oñate, “Diseño e Implementación de un Glucómetro no Invasivo Basado en la Ley de Lambert Beer y Longitud de Onda Cercana al Infrarrojo (NIR) con Interfaz de Comunicación Bluetooth a Dispositivos con Sistema Operativo Android.” http://dspace.ups.edu.ec/handle/123456789/ 6332, 2014. Universidad Politécnica Salesiana. [34] B. Wisse and D. Zieve, “Blood sugar test - blood.” https://www.nlm.nih. gov/medlineplus/ency/article/003482.htm, 2014. U.S. National Library of Medicine. [35] S. Thelen, M. Czaplik, P. Meisen, D. Schilberg, and S. Jeschke, “Using off-theshelf medical devices for biomedical signal monitoring in a telemedicine system for emergency medical services,” Biomedical and Health Informatics, IEEE Journal of, vol. 19, pp. 117–123, Jan 2015. 107
[36] J. A. Zubairi, “Aggregation scheme implementation for vital signs data over the network,” in High-Capacity Optical Networks and Enabling Technologies (HONET), 2009 6th International Symposium on, pp. 129–133, Dec 2009. [37] “HeartStart Telemedicine System User Guide.” http://www.ems.philips. com/Product/MRx.aspx, 2009. Philips Electronics North America Corp. [38] J.-M. Royer, Seguridad en la informática de empresa. Ediciones ENI, Aug 2004. [39] M. C. Batistatos, G. V. Tsoulos, and G. E. Athanasiadou, “Mobile telemedicine for moving vehicle scenarios: Wireless technology options and challenges,” J. Netw. Comput. Appl., vol. 35, pp. 1140–1150, May 2012. [40] “Understanding Wi-Fi and WiMax as Metro-Access Solutions.” http://www. rclient.com/PDFs/IntelPaper.pdf, 2004. Intel Corporation. [41] S. Bacuilima, “Estudio y diseño de una red wimax para la ciudad de cuenca.” http://dspace.ucuenca.edu.ec/bitstream/123456789/2555/1/ tm4320.pdf, 2010. Universidad de Cuenca. [42] “The LTE Network Architecture.” http://www.cse.unt.edu/~rdantu/FALL_ 2013_WIRELESS_NETWORKS/LTE_Alcatel_White_Paper.pdf, 2009. AlcatelLucent. [43] T. Bhandare, “LTE and WiMax Comparison.” http://www.halcyonwireless. com, 2008. Santa Clara University. [44] T. Schrage, “LTE: Scheduling and HARQ.” http://www.halcyonwireless. com, 2010. Seminar Ausgewählte Kapitel der Nachrichtentechnik, WS 2009/2010. [45] H. Safa and K. Tohme, “Lte uplink scheduling algorithms: Performance and challenges,” in Telecommunications (ICT), 2012 19th International Conference on, pp. 1–6, April 2012. [46] N. Shabbir, M. T. Sadiq, H. Kashif, and R. Ullah, “Comparison of radio propagation models for long term evolution (lte) network,” International Journal of Next-Generation Networks, vol. 3, pp. 27–41, September 2011. [47] S. A. Mawjoud, “Comparison of propagation model accuracy for long term evolution (lte) cellular network,” International Journal of Computer Applications, vol. 79, pp. 41–45, October 2013. [48] C. Douligeris and D. N. Serpanos, IEEE 802.11 Security, pp. 297–312. WileyIEEE Press, 2007. 108
[49] Z. Aqun, Y. Yuan, J. Yi, and G. Guanqun, “Research on tunneling techniques in virtual private networks,” in Communication Technology Proceedings, 2000. WCC - ICCT 2000. International Conference on, vol. 1, pp. 691–697 vol.1, 2000. [50] R. Hilbrich, “Sumo simulation of urban mobility.” http://www.dlr.de/ts/ en/desktopdefault.aspx/tabid-9883/16931_read-41000/. Institute of Transportation Systems. [51] J. Escandón, P. Guamán, and M. Jiménez, “Morbilidad y mortalidad en el área de emergencia del hospital vicente corral m. de la ciudad de cuenca durante el periodo 2000 -2002.” http://cdjbv.ucuenca.edu.ec/ebooks/doi27964.pdf, 2005. Universidad de Cuenca. [52] I. Scholz and D. Stöcker, “Josm.” https://josm.openstreetmap.de/. [53] “Lte;evolved universal terrestrial radio access (e-utra); physical layer; measurements.” http://www.etsi.org/deliver/etsi_ts/136200_136299/ 136214/13.01.00_60/ts_136214v130100p.pdf, 2016. 3GPP TS 36.214 version 13.1.0 Release 13.
109
Anexo 1 HCU-002 Registro de Atención Prehospitalaria
110
Anexo 2 Números de Canal E-UTRA segun la norma 3GPP ETSI TS 136 101 V13.3.0 (2016-05)
111
Anexo 3 Instalación de JOSM, SUMO y NS-3 La instalación de los softwares, ha sido realizado en computador de 32 bits con sistema operativo Linux, distribución Ubuntu 12.04 LTS “Precise Pangolin”. Instalación de JOSM 1. Actualizar la vesión de java y jdk. $ sudo add-apt-repository ppa:webupd8team/java $ sudo apt-get update $ sudo apt-get install oracle-java7-installer $ sudo update-java-alternatives -s java-7-oracle 2. Descargar la versión multiplataforma “josm-latest.jar (version 10518)” en https://josm.openstreetmap.de/ 3. Para ejecutar, dirigirse a la carpeta donde se encuentra el archivo *.jar en el terminal e introducir el siguiente comando: $ java -jar josm-latest.jar Instalación de SUMO La versión de SUMO utilizada para la simulación de movilidad es 0.25.0, su instalación se realiza mediante la ejecución de comandos en el terminal del equipo: 1. Descargar software en http://sumo.dlr.de/wiki/Main_Page con extensión *tar.gz 2. Previo a la instalación, actualizar o instalar las siguientes librerias para el correcto funcionamiento de SUMO: $ sudo apt-get install libgdal1h libgdal-dev g++ libxerces-c3.1 libxerces-c-dev libicudev libproj-dev libfox-1.6-dev libgl1-mesa-dev libglu1-mesa-dev python 3. Dirigirse al directorio donde se encuentra el archivo *tar.gz con el comando y extraer los archivos con el siguiente comando: $ sudo tar -xzvf sumo-src-0.25.0.tar.g 4. Mover los archivos descomprimidos hacia el directorio “/usr/local/src”, mediante el 112
siguiente comando: $ sudo mv -v sumo-0.25.0 /usr/local/src 5. Dirigirse al directorio “/usr/local/src/sumo-0.25.0” e ingresar los siguientes comandos: $ sudo ./configure –with-fox-includes=/usr/include/fox-1.6 \ –with-gdal-includes=/usr/include/gdal –with-proj-libraries=/usr \ –with-gdal-libraries=/usr –with-proj-gdal $ sudo make $ sumo make install Instalación de NS-3 La versión del software utilizado es NS-3.19: 1. Instalación de prerrequisitos: $ sudo apt-get install gcc g++ python python-dev mercurial bzr gdb valgrind gsl-bin libgsl0-dev libgsl0ldbl flex bison tcpdump sqlite sqlite3 libsqlite3-dev libxml2 libxml2dev libgtk2.0-0 libgtk2.0-dev uncrustify doxygen graphviz imagemagick texlive texlivelatex-extra texlive-generic-extra texlive-generic-recommended texinfo dia texlive texlivelatex-extra texlive-extra-utils texlive-generic-recommended texi2html python-pygraphviz python-kiwi python-pygoocanvas libgoocanvas-dev python-pygccxml 2. Crear un nuevo directorio y descargar el archivo comprimido: $ mkdir ns3 $ cd ns3 $ wget http://www.nsnam.org/release/ns-allinone-3.19.tar.bz2 3. Descomprimir el archivo *.tar.bz2 e ingresar al directorio /ns-allinone-3.19: $ tar xjf ns-allinone-3.19.tar.bz2 $ cd ns-allinone-3.19/ 4. Instalar n-s3.19: $ ./build.py –enable-examples –enable-tests
113
$ ./waf -d debug –enable-examples –enable-tests configure $ ./waf 5. Comprobar instalación: $ ./test.py
114
Anexo 4 Código C++ para la simulación de los Escenarios 1 y 2 /* -*- Mode: C++; c-file-style: ”gnu”; indent-tabs-mode:nil; -*- */ #include ”ns3/lte-helper.h” #include ”ns3/epc-helper.h” #include ”ns3/core-module.h” #include ”ns3/network-module.h” #include ”ns3/ipv4-global-routing-helper.h” #include ”ns3/internet-module.h” #include ”ns3/mobility-module.h” #include ”ns3/lte-module.h” #include ”ns3/applications-module.h” #include ”ns3/point-to-point-helper.h” #include ”ns3/config-store.h” #include ”ns3/flow-monitor-helper.h” #include ”ns3/ns2-mobility-helper.h” #include #include
using namespace ns3;
NS_LOG_COMPONENT_DEFINE (”Tesis-LTE”); int main (int argc, char *argv[]) {
115
// Configuración del Tiempo de Simulación double tiempo_sim = 51.00;
//Configuración de Parámetros LTE Config::SetDefault (”ns3::LteHelper::Scheduler”, StringValue ( ”ns3::PfFfMacScheduler”)); Config::SetDefault (”ns3::LteHelper::PathlossModel”, StringValue ( ”ns3::FriisSpectrum PropagationLossModel”)); Config::SetDefault (”ns3::LteEnbNetDevice::DlEarfcn”, UintegerValue (1950)); Config::SetDefault (”ns3::LteEnbNetDevice::UlEarfcn”, UintegerValue (19950)); Config::SetDefault (”ns3::LteEnbNetDevice::UlBandwidth”, UintegerValue (25)); Config::SetDefault (”ns3::LteEnbNetDevice::DlBandwidth”, UintegerValue (25)); Config::SetDefault (”ns3::LteUePhy::TxPower”, DoubleValue (24)); Config::SetDefault (”ns3::LteUePhy::NoiseFigure”, DoubleValue (7)); Config::SetDefault (”ns3::LteEnbPhy::TxPower”, DoubleValue (43)); Config::SetDefault (”ns3::LteEnbPhy::NoiseFigure”, DoubleValue (2)); Config::SetDefault (”ns3::LteEnbRrc::SrsPeriodicity”, UintegerValue (320));
// Argumentos por Línea de Comandos CommandLine cmd; cmd.Parse(argc, argv);
// Creación Nodos Ambulancias NodeContainer ueAmbulancias; ueAmbulancias.Create(5);
116
// Instalación de trazas de movilidad en los Nodos Terminales Móviles Ns2MobilityHelper ns2 = Ns2MobilityHelper (”scratch/ns2mobility.tcl”); ns2.Install(NodeList::Begin(),NodeList::End());
// Creación Nodos Usuario de Datos Fijo (Mediano) NodeContainer ueDatosFijos; ueDatosFijos.Create(5);
// Configuración de la Movilidad de Nodos Fijos MobilityHelper fijosMobility; fijosMobility.SetPositionAllocator (”ns3::GridPositionAllocator”, ”MinX”, DoubleValue (540.0), ”MinY”, DoubleValue (464.0), ”DeltaX”, DoubleValue (300.0), ”DeltaY”, DoubleValue (300.0), ”GridWidth”, UintegerValue (5), ”LayoutType”, StringValue (”RowFirst”)); fijosMobility.SetMobilityModel(”ns3::ConstantPositionMobilityModel”); fijosMobility.Install(ueDatosFijos);
// Creación Nodos Usuarios Datos Fijos (Avanzados) NodeContainer ueDatosAdv; ueDatosAdv.Create(10);
// Configuración de la Movilidad de Nodo Ambulancia MobilityHelper fijosMobility2; Ptr ThetaAngle =
117
CreateObject (); ThetaAngle->SetAttribute (”Min”, DoubleValue (-50.0)); ThetaAngle->SetAttribute (”Max”, DoubleValue (50.0)); Ptr RhoAngle = CreateObject (); RhoAngle->SetAttribute (”Min”, DoubleValue (100.00)); RhoAngle->SetAttribute (”Max”, DoubleValue (700.00)); fijosMobility2.SetPositionAllocator (”ns3::RandomDiscPositionAllocator”, ”Theta”, PointerValue(ThetaAngle), ”Rho”, PointerValue(RhoAngle), ”X”, DoubleValue (940.0), ”Y”, DoubleValue (864.0)); fijosMobility2.SetMobilityModel(”ns3::ConstantPositionMobilityModel”); fijosMobility2.Install (ueDatosAdv);
// Creación del PacketCore (EPC y PGW) de LTE Ptr lteHelper = CreateObject (); Ptr epcHelper = CreateObject (); lteHelper->SetEpcHelper (epcHelper); Ptr pgw = epcHelper->GetPgwNode (); ConfigStore inputConfig; inputConfig.ConfigureDefaults(); cmd.Parse(argc, argv);
118
// Creación del Servidor Remoto NodeContainer servidor_remoto; servidor_remoto.Create (1); Ptr remoteHost = servidor_remoto.Get (0); InternetStackHelper internet; internet.Install (servidor_remoto);
// Configuración enlace Servidor Remoto - Packet Gateway (pgw) PointToPointHelper p2ph; ph.SetDeviceAttribute (”DataRate”, DataRateValue (DataRate (”100Gb/s”))); p2ph.SetDeviceAttribute (”Mtu”, UintegerValue (1500)); p2ph.SetChannelAttribute (”Delay”, TimeValue (Seconds (0.010))); NetDeviceContainer internetDevices = p2ph.Install (pgw, remoteHost); Ipv4AddressHelper ipv4h; ipv4h.SetBase (”1.0.0.0”, ”255.0.0.0”); Ipv4InterfaceContainer internetIpIfaces = ipv4h.Assign (internetDevices); Ipv4Address remoteHostAddr = internetIpIfaces.GetAddress (1);
// Configuración Enrutamiento Estático Servidor Remoto - Packet Gateway (pgw) Ipv4StaticRoutingHelper ipv4RoutingHelper; Ptr remoteHostStaticRouting = ipv4RoutingHelper.GetStaticRouting (remoteHost->GetObject ()); remoteHostStaticRouting->AddNetworkRouteTo (Ipv4Address (”7.0.0.0”), Ipv4Mask (”255.0.0.0”), 1);
// Creación de eNodoB
119
NodeContainer enbNodes; enbNodes.Create(1);
// Instalación de Modelo de Movilidad Estático a eNodoB Ptr positionAlloc = CreateObject (); positionAlloc->Add (Vector(940.0,864.0,0.0)); MobilityHelper mobility; mobility.SetMobilityModel(”ns3::ConstantPositionMobilityModel”); mobility.SetPositionAllocator(positionAlloc); mobility.Install(enbNodes);
// Instalación de dispositivos LTE en Nodos Ambulancias, Fijos y Avanzados NetDeviceContainer enbLteDevs = lteHelper->InstallEnbDevice (enbNodes); NetDeviceContainer ueLteDevsAmbu = lteHelper->InstallUeDevice (ueAmbulancias); NetDeviceContainer ueLteDevsFijos = lteHelper->InstallUeDevice (ueDatosFijos); NetDeviceContainer ueLteDevsAdv = lteHelper->InstallUeDevice (ueDatosAdv);
// Configuración IP en Terminales Ambulancias internet.Install (ueAmbulancias); Ipv4InterfaceContainer ueIpIfaceAmbulancia; ueIpIfaceAmbulancia = epcHelper-> AssignUeIpv4Address (NetDeviceContainer (ueLteDevsAmbu));
// Configuración IP en Terminales Datos Fijos internet.Install (ueDatosFijos); Ipv4InterfaceContainer ueIpIfaceFijos;
120
ueIpIfaceFijos = epcHelper-> AssignUeIpv4Address (NetDeviceContainer (ueLteDevsFijos));
// Configuración IP en Terminales Datos Avanzados internet.Install (ueDatosAdv); Ipv4InterfaceContainer ueIpIfaceAdv; ueIpIfaceAdv = epcHelper-> AssignUeIpv4Address (NetDeviceContainer (ueLteDevsAdv));
// Configuración de Enrutamiento de Terminales Ambulancias for (uint32_t u = 0; u < ueAmbulancias.GetN (); ++u) { Ptr ueAmbul = ueAmbulancias.Get (u);
// Configuración de Gateway por Defecto en terminales Ptr ueStaticRouting = ipv4RoutingHelper.GetStaticRouting (ueAmbul->GetObject ()); ueStaticRouting->SetDefaultRoute (epcHelper-> GetUeDefaultGatewayAddress (), 1); }
// Configuración de Enrutamiento de Terminales Fijos for (uint32_t u = 0; u < ueDatosFijos.GetN (); ++u) { Ptr ueFijo = ueDatosFijos.Get (u);
121
// Configuración de Gateway por Defecto en terminales Ptr ueStaticRoutingFijo = ipv4RoutingHelper.GetStaticRouting (ueFijo->GetObject ()); ueStaticRoutingFijo->SetDefaultRoute (epcHelper-> GetUeDefaultGatewayAddress (), 1); }
// Configuración de Enrutamiento de Terminales Avanzados for (uint32_t u = 0; u < ueDatosAdv.GetN (); ++u) { Ptr ueAdv = ueDatosAdv.Get (u);
// Configuración de Gateway por Defecto en terminales Ptr ueStaticRoutingAmbu = ipv4RoutingHelper.GetStaticRouting (ueAdv->GetObject ()); ueStaticRoutingAmbu->SetDefaultRoute (epcHelper-> GetUeDefaultGatewayAddress (), 1); }
// Configuración de Acoplamiento Inicial Terminales Ambulancias - eNodoB for (uint16_t i = 0; i < ueAmbulancias.GetN (); i++) { lteHelper->Attach (ueLteDevsAmbu.Get(i), enbLteDevs.Get(0)); }
122
// Configuración de Acoplamiento Inicial Terminales Fijos - eNodoB for (uint16_t i = 0; i < ueDatosFijos.GetN (); i++) { lteHelper->Attach (ueLteDevsFijos.Get(i), enbLteDevs.Get(0)); }
// Configuración de Acoplamiento Inicial Terminales Avanzados - eNodoB for (uint16_t i = 0; i < ueDatosAdv.GetN (); i++) { lteHelper->Attach (ueLteDevsAdv.Get(i), enbLteDevs.Get(0)); }
// Instalación y Configuración de la Capa de Aplicación en //Terminales Ambulancias y Servidor uint16_t dlPort = 1234; uint16_t ulPort = 2000; double intervalo_paqAmbu = 6; ApplicationContainer clientAppsAmbulancia; ApplicationContainer serverAppsAmbulancia;
for (uint32_t u = 0; u < ueAmbulancias.GetN (); ++u) { ++ulPort; PacketSinkHelper dlPacketSinkHelper (”ns3::UdpSocketFactory”, InetSocketAddress (Ipv4Address::GetAny (), dlPort));
123
PacketSinkHelper ulPacketSinkHelper (”ns3::UdpSocketFactory”, InetSocketAddress (Ipv4Address::GetAny (), ulPort)); serverAppsAmbulancia.Add (dlPacketSinkHelper.Install (ueAmbulancias.Get(u))); serverAppsAmbulancia.Add (ulPacketSinkHelper.Install (remoteHost)); UdpClientHelper dlClient (ueIpIfaceAmbulancia.GetAddress (u), dlPort); dlClient.SetAttribute (”Interval”, TimeValue (MilliSeconds(intervalo_paqAmbu))); dlClient.SetAttribute (”MaxPackets”, UintegerValue(1000000)); UdpClientHelper ulClient (remoteHostAddr, ulPort); ulClient.SetAttribute (”Interval”, TimeValue (MilliSeconds(intervalo_paqAmbu))); ulClient.SetAttribute (”MaxPackets”, UintegerValue(1000000)); clientAppsAmbulancia.Add (dlClient.Install (remoteHost)); clientAppsAmbulancia.Add (ulClient.Install (ueAmbulancias.Get(u))); }
// Instalación y Configuración de la Aplicación en Terminales Fijos y Servidor uint16_t dlPortFijo = 2234; uint16_t ulPortFijo = 3000; double intervalo_paqFij = 32; ApplicationContainer clientAppsFijos; ApplicationContainer serverAppsFijos;
for (uint32_t u = 0; u < ueDatosFijos.GetN (); ++u) { ++ulPortFijo; PacketSinkHelper dlPacketSinkHelperFijos (”ns3::UdpSocketFactory”,
124
InetSocketAddress (Ipv4Address::GetAny (), dlPortFijo)); PacketSinkHelper ulPacketSinkHelperFijos (”ns3::UdpSocketFactory”, InetSocketAddress (Ipv4Address::GetAny (), ulPortFijo)); serverAppsFijos.Add (dlPacketSinkHelperFijos.Install (ueDatosFijos.Get(u))); serverAppsFijos.Add (ulPacketSinkHelperFijos.Install (remoteHost)); UdpClientHelper dlClientFijos (ueIpIfaceFijos.GetAddress (u), dlPortFijo); dlClientFijos.SetAttribute (”Interval”, TimeValue (MilliSeconds(intervalo_paqFij))); dlClientFijos.SetAttribute (”MaxPackets”, UintegerValue(1000000)); UdpClientHelper ulClientFijos (remoteHostAddr, ulPortFijo); ulClientFijos.SetAttribute (”Interval”, TimeValue (MilliSeconds(intervalo_paqFij))); ulClientFijos.SetAttribute (”MaxPackets”, UintegerValue(1000000)); clientAppsFijos.Add (dlClientFijos.Install (remoteHost)); clientAppsFijos.Add (ulClientFijos.Install (ueDatosFijos.Get(u))); }
// Instalación y Configuración de la Aplicación en Terminal Ambulacia y Servidor uint16_t dlPortAdv = 3234; uint16_t ulPortAdv = 4000; double intervalo_paqAdv = 16; ApplicationContainer clientAppsAdv; ApplicationContainer serverAppsAdv;
for (uint32_t u = 0; u < ueDatosAdv.GetN (); ++u) { ++ulPortAdv;
125
PacketSinkHelper dlPacketSinkHelperAdv (”ns3::UdpSocketFactory”, InetSocketAddress (Ipv4Address::GetAny (), dlPortAdv)); PacketSinkHelper ulPacketSinkHelperAdv (”ns3::UdpSocketFactory”, InetSocketAddress (Ipv4Address::GetAny (), ulPortAdv)); serverAppsAdv.Add (dlPacketSinkHelperAdv.Install (ueDatosAdv.Get(u))); serverAppsAdv.Add (ulPacketSinkHelperAdv.Install (remoteHost)); UdpClientHelper dlClientAdv (ueIpIfaceAdv.GetAddress (u), dlPortAdv); dlClientAdv.SetAttribute (”Interval”, TimeValue (MilliSeconds(intervalo_paqAdv))); dlClientAdv.SetAttribute (”MaxPackets”, UintegerValue(1000000)); UdpClientHelper ulClientAdv (remoteHostAddr, ulPortAdv); ulClientAdv.SetAttribute (”Interval”, TimeValue (MilliSeconds(intervalo_paqAdv))); ulClientAdv.SetAttribute (”MaxPackets”, UintegerValue(1000000)); clientAppsAdv.Add (dlClientAdv.Install (remoteHost)); clientAppsAdv.Add (ulClientAdv.Install (ueDatosAdv.Get(u))); }
//Iniciación de Servidores Y Clientes serverAppsAmbulancia.Start (Seconds (1.00)); clientAppsAmbulancia.Start (Seconds (1.00)); serverAppsFijos.Start (Seconds (1.00)); clientAppsFijos.Start (Seconds (1.00)); serverAppsAdv.Start (Seconds (1.00)); clientAppsAdv.Start (Seconds (1.00));
//Habilitación de Trazas de la Capa Física LTE en Downlink y Uplink
126
lteHelper->EnableDlPhyTraces (); lteHelper->EnableDlTxPhyTraces (); lteHelper->EnableDlRxPhyTraces (); lteHelper->EnableUlPhyTraces (); lteHelper->EnableUlTxPhyTraces (); lteHelper->EnableUlRxPhyTraces ();
// Configuración de Monitor de Flujo en Clientes y Servidor Ptr flowMonitor; FlowMonitorHelper flowHelper; flowMonitor = flowHelper.Install (ueDatosAdv); flowMonitor = flowHelper.Install (ueDatosFijos); flowMonitor = flowHelper.Install (ueAmbulancias); flowMonitor = flowHelper.Install (remoteHost);
// Configuración de Tiempo de Simulación e Inicio de Simulación. Simulator::Stop(Seconds(tiempo_sim)); Simulator::Run(); Simulator::Destroy();
// Obtención de Archivo Xml con información del Monitor de Flujo flowMonitor->SerializeToXmlFile(”TesisLTE-p20.xml”, false, false);
//Visualización de Estadísticas FlowMonitor //./waf –pyrun ”src/flow-monitor/examples/flowmon-parse-results.py TesisLTE.xml”
127
return 0; }
128
