Control de interrupciones de vídeo streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC

Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 2 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 3 Agradecimientos Agradezco a mi Dios Padre Celestial por su fortaleza y guía para cumplir con este gran reto y sueño profesional. A mi preciosa esposa Elena, a mis adorados hijos Camila y Mateo, por el tiempo que me han concedido, un tiempo en el que no he podido ser parte de la historia familiar, pero que siempre han sido mi fuente de amor, paciencia, inspiración, fortaleza y alegría, este trabajo es también el suyo. A mi querida familia, a mis padres y hermanos, por haber sido el apoyo y fuerza en cada momento, en cada desánimo para seguir en este duro camino de mi vida. A Silvana e Iván por ser mis amigos incondicionales en este gran sueño y a mis amigos de siempre, por sus palabras de aliento y motivación diaria que me han permitido seguir adelante en este reto. Con todo mi corazón, un sentido gracias a Elsa y Álvaro, por su paciencia, apoyo y palabras de ánimo que apuntalaron a levantarme de mis caídas y seguir perseverando en esta hermosa meta de mi vida. A ti Tatiana, amiga y hermana, compañera de esta travesía, que con tu gran apoyo profesional, moral y humano, me han permitido continuar en los momentos difíciles de este trabajo y esta profesión. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 4 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 5 Resumen Los avances en la Tecnología de la Información y la Comunicación han impactado la Sociedad muy sorprendentemente, constituyéndose en un elemento de vital importancia. El ser humano está en una constante búsqueda de nuevas tecnologías, que simplifiquen las actividades en cualquiera de las áreas que necesite. En la Comunicación inalámbrica se ha incrementado el ancho de banda usando nuevas técnicas de codificación, se ha mejorado mucho la arquitectura hardware de los terminales móviles y sus sistemas operativos. El hardware puede incluir hasta ocho núcleos, pantallas flexibles que faciliten el consumo de contenidos de realidad virtual y de realidad aumentada. Los sensores permiten diseñar aplicaciones inteligentes e interactivas con el medio físico. Los sistemas operativos optimizan el consumo energético y manejo eficiente de datos multimedia (audio y vídeo). Servicios móviles como la videoconferencia y streaming de video almacenado son muy habituales a día de hoy; por lo que es imperativo garantizar la prestación del servicio con criterios de calidad de experiencia. Desafío complejo porque la gran cantidad de tráfico que demanda este servicio es difícil de procesar en los limitados recursos de los terminales móviles. Pero más complejo es el hecho que el canal inalámbrico tiene un comportamiento impredecible ocasionado por la desconexión impredecible del canal inalámbrico que causa interrupciones del servicio de video. Esto afecta muy negativamente a la Calidad de la experiencia del usuario y pone en peligro el futuro éxito de este servicio. Por eso, en esta tesis se ha contribuido a mitigar este problema, contribuyendo con varias soluciones software que se aplican en diferentes ambientes. Para ello se ha modelado con patrones de diseño una arquitectura básica de un esquema general de video streaming. Para entender el problema que afecta al servicio de video streaming, se modeló y generó un modelo matemático que permite demostrar claramente que el rendimiento del servicio ante interrupciones es muy pobre. La primera solución consiste en utilizar proxies para mitigar los efectos adversos de una interrupción de video streaming; permitiendo al cliente continuar consumiendo el contenido multimedia desde la posición en la que se encontraba, dado el establecimiento del canal de comunicación. Posteriormente se planteó un modelo basado en realidad aumentada, donde el usuario puede observar en tiempo real mediante técnicas de realidad aumenta, como se encuentra el estado del canal de comunicación en un lugar dado; para Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 6 con esta información tome acciones que permitan la continuidad del contenido multimedia, evitando entrar en zonas de interrupción. Se utilizó el modelo base en forma iterativa con incrementales de funcionalidad mediante el uso de patrones software y reglas de negocio que evalúan el estado del canal de comunicación a través del sensado del dispositivo móvil, entregando información que permite desplegar consultas colaborativas debido a que arma mapas online con la información obtenida sobre la ruta seguida por el usuario mediante archivos KML. Estos archivos pueden ser consumidos por herramientas como Google Earth y Google Maps Finalmente, se planteó un modelo para video en tiempo real que permita controlar la interrupción de una sesión de videoconferencia por video streaming, debido a una disrupción del canal de comunicación inalámbrico. Se mantuvo el modelo base en forma iterativa con incrementales en sus dos subsistemas: establecimiento y externo. Cada uno de estos subsistemas se desarrolló con base en patrones software de diseño y funcionalidades adicionales para cumplir con el objetivo de proveer control de interrupción y continuidad del servicio de videoconferencia. Ninguna de las soluciones anteriores supone un coste adicional en el tiempo de ejecución y se ha definido un mecanismo que permite reestablecer la sesión; continuar con la visualización del contenido multimedia desde la posición en la que se encontraba, cuando se produjo la disrupción. Minimizando significativamente el impacto negativo de la pérdida de sesión y mejorando la experiencia de usuario en servicios de videoconferencia y video streaming. Palabras clave Video streaming, comunicación inalámbrica, dispositivos inalámbricos, agentes inteligentes, servicios Web, disrupción, interrupción, recuperación, video streaming bajo demanda, video streaming en tiempo real, WebRTC, HTML5, DASH, sensores, reglas de negocio, patrones software de diseño, realidad aumenta, KML, KMZ. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 7 Abstract Advances in information technology and communication have impacted surprisingly in the society, being an element of vital importance. Human beings are in constant search for new technologies that reduce the activities in any of the needed areas. In wireless communication the bandwidth has been increased using new coding techniques, the hardware architecture of mobile devices and their operating systems has been greatly improved. The hardware can include up to eight cores, flexible displays to facilitate the use of virtual and augmented reality. Sensors allow to design smart applications with the physical environment. Operating systems optimize energy consumption and efficient management of multimedia data (audio and video). Mobile services such as videoconferences and video streaming are very common these days, so it is imperative to ensure the service with quality criteria of experience. This is a complex challenge because of the amount of traffic that this service demands, is difficult to process in the limited resources of mobile terminals. The wireless channel has an unpredictable behavior caused by the unpredictable wireless channel disconnection that causes interruptions in the video service. This negatively affects to the quality of user experience and puts in danger the future success of this service. Therefore, this thesis has contributed to mitigate this problem with several software solutions that apply in different environments. For this reason a basic architecture of a general scheme of video streaming has been modeled with design patterns. To understand the problem that affects the video streaming service, it was modeled and created a mathematical model to demonstrate clearly that service performance facing interruptions is very poor. The first solution is to use proxies to mitigate adverse effects of a video streaming interruption; allowing the costumer continue consuming the multimedia content from the position he was when the channel communication was stablished. After that a model based on augmented reality was raised, where the user can observe in real time trough augmented techniques how is the status of the communication channel in a specific place, for this information I took decisions that Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 8 allow the continuity of multimedia content, avoiding entering in interruption areas. The base model was used interactively with increments of functionality through the use of software patterns and business rules that evaluate the status of the communication channel by sensing the mobile device, providing information that allows to deploy collaborative consultations because online maps are formed with the obtained information of the route followed for the user through KML files. This files can be consumed by tools like Google Earth and Google Maps. Finally, a model for video in real time that allows to control the interruption of a videoconference by video streaming was raised, due to a disruption of the wireless communication channel. The base model was maintained in an iteratively way with incremental in two systems: establishment and external. Each of these subsystems was developed based on design software patterns and additional features to get the goal of provide interruption control and continuity of videoconference service. None of the previous solutions has an additional cost in the executing time and a mechanism to reestablish the session, continue displaying the media from the position that the costumer was when the disruption occurred was defined. Significantly minimizing the negative impact of the loss of session and improving the user experience in videoconferences and video streaming. Keywords Video streaming, wireless communication, wireless devices, smart agents, web services, disruption, interruption, video streaming on demand, video streaming in real time, WebRTC, HTML5, DASH, sensors, business rules, design software patterns, augmented reality, KML, KMZ. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 15 Índice de Figuras Figura 2.1: Redes inalámbricas por área de cobertura....................................... 38 Figura 2.2: Uso de las versiones de SDK de Android en teléfonos inteligentes . 42 Figura 2.3: Flujo de control y transporte sesión multimedia ............................. 44 Figura 2.4: Arquitectura básica servicio video streaming .................................. 46 Figura 2.5: Diagrama de estados para RTSP ....................................................... 50 Figura 2.6: Establecimiento de conexión en RTSP .............................................. 50 Figura 2.7: Ejemplo de afectación del jitter ........................................................ 59 Figura 2.8: Patrón MVC ....................................................................................... 74 Figura 2.9: Patrón Strategy ................................................................................. 76 Figura 2.10: Patrón Observer .............................................................................. 76 Figura 2.11: Patrón Proxy ................................................................................... 77 Figura 2.12: Patrón Adapter ............................................................................... 77 Figura 2.13: Archivo KML generado desde Google Earth ................................... 81 Figura 2.14: Escenario de adaptación DASH ....................................................... 85 Figura 2.15: Casos de uso servicio video streaming ........................................... 88 Figura 2.16: Modelo patrones software para servicio video streaming ............ 89 Figura 2.17: Diagrama de clases servicio video streaming ................................. 90 Figura 2.18: Diagrama de secuencia servicio video streaming .......................... 91 Figura 2.19: Diagrama de secuencia servicio video streaming .......................... 92 Figura 2.20: Comportamiento flujos peor escenario.......................................... 93 Figura 2.21: Comportamiento flujos mejor escenario ....................................... 94 Figura 2.22: Datos transmitidos vs retransmitidos por flujo .............................. 99 Figura 2.23: Datos totales transmitidos vs retransmitidos .............................. 100 Figura 2.24: Datos transmitidos vs retransmitidos por flujo ............................ 102 Figura 2.25: Datos totales transmitidos vs retransmitidos .............................. 102 Figura 2.26: Datos transmitidos vs retransmitidos por flujo ............................ 104 Figura 2.27: Datos totales transmitidos vs retransmitidos .............................. 104 Figura 2.28: Tiempo de ejecución escenarios .................................................. 106 Figura 2.29: Tiempo Dato y Tiempo Interrupción ............................................ 107 Figura 3.1: Casos de uso modelo base .............................................................. 112 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 16 Figura 3.2: Modelo base para control de interrupciones ................................. 115 Figura 3.3: Diagrama de clases modelo base ................................................... 117 Figura 3.4: Diagrama de secuencia modelo base ............................................. 118 Figura 3.5: Diagrama de despliegue modelo base............................................ 119 Figura 3.6: Tiempo de ejecución escenarios .................................................... 124 Figura 3.7: Diagrama de clase de APC - Aplicación ........................................... 127 Figura 3.8: Diagrama de clase APC – Proxy ...................................................... 128 Figura 3.9: Diagrama de clase de APS - Proxy................................................... 128 Figura 3.10: Diagrama de clase de APC - Proxy Comportamiento ................... 129 Figura 3.11: Diagrama de clase de APS - Proxy Comportamiento .................... 130 Figura 3.12: Diagrama de secuencia de APC - Reproducir Video - Parte 1 ...... 131 Figura 3.13: Diagrama de secuencia de APC - Reproducir Video - Parte 2 ...... 131 Figura 3.14: Diagrama de secuencia de APS - Ejecutar Servidor Proxy ............ 132 Figura 3.15: Diagrama de despliegue ............................................................... 132 Figura 3.16: Arquitectura para envío de imágenes con agente JADE .............. 134 Figura 3.17: Arquitectura JADE - RTSP .............................................................. 135 Figura 3.18: Paso de mensajes FIPA-ACL .......................................................... 141 Figura 3.19: Jitter de paquetes de audio .......................................................... 143 Figura 3.20: Jitter de paquetes de video .......................................................... 143 Figura 3.21: Retraso paquetes de audio ........................................................... 144 Figura 3.22: Retraso de paquetes de video ...................................................... 144 Figura 3.23: Error de código ............................................................................. 147 Figura 3.24: Corrección en el código ................................................................ 147 Figura 4.1: Casos de uso modelo basado con RA ............................................. 152 Figura 4.2: Caso de uso regla de negocio ......................................................... 156 Figura 4.3: Modelo con RA................................................................................ 158 Figura 4.4: Diagrama de clases modelo con RA ................................................ 161 Figura 4.5: Diagrama de secuencia modelo con RA ......................................... 162 Figura 4.6: Diagrama de secuencia modelo con RA. ........................................ 164 Figura 4.7: Tiempos de ejecución en escenarios .............................................. 167 Figura 4.8: Diagrama de clase APC con RA ....................................................... 170 Figura 4.9: Diagrama de clase APC con RA ....................................................... 171 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 17 Figura 4.10: Diagrama de clases APS Aplicación con regla de negocio ............ 171 Figura 4.11: Diagrama de clase APS con regla de negocio ............................... 172 Figura 4.12: Diagrama de secuencia ................................................................. 173 Figura 4.13: Diagrama de despliegue ............................................................... 174 Figura 4.14: Arquitectura JADE con RA y reglas de negocio ............................. 176 Figura 4.15: Arquitectura con RA y reglas de negocio...................................... 176 Figura 4.16: Aplicación Google Earth con despliegue KML .............................. 179 Figura 4.17: Aplicación Google Earth con despliegue de KML ......................... 179 Figura 4.18: Aplicación Google Earth con despliegue de KML ......................... 179 Figura 4.19: Paso de mensajes FIPA-ACL .......................................................... 180 Figura 4.20: Jitter de paquetes de audio .......................................................... 183 Figura 4.21: Jitter de paquetes de video .......................................................... 184 Figura 4.22: Retraso paquetes de audio ........................................................... 184 Figura 4.23: Retraso de paquetes de video ...................................................... 185 Figura 4.24: Prueba realizada en residencia ..................................................... 186 Figura 4.25: Prueba realizada en residencia ..................................................... 186 Figura 4.26: Prueba realizada en la ULPGC ....................................................... 187 Figura 5.1: Casos de uso modelo para video en tiempo real ........................... 193 Figura 5.2: Modelo para video en tiempo real ................................................. 196 Figura 5.3: Diagrama de clases para modelo en tiempo real ........................... 200 Figura 5.4: Diagrama de secuencia modelo para video en tiempo real ........... 202 Figura 5.5: Diagrama de despliegue modelo para video en tiempo real ......... 203 Figura 5.6: Tiempos de ejecución en escenarios .............................................. 206 Figura 5.7: Visión general de la arquitectura ARW ........................................... 207 Figura 5.8: Diagrama clase solución video en tiempo real ............................... 209 Figura 5.9: Diagrama de secuencia establecimiento ........................................ 210 Figura 5.10: Diagrama de secuencia reconexión .............................................. 211 Figura 5.11: Diagrama de despliegue ............................................................... 212 Figura 5.12: Arquitectura ARW ......................................................................... 213 Figura 5.13: Establecimiento de la comunicación ............................................ 215 Figura 5.14: Comunicación y reconexión .......................................................... 217 Figura 5.15: Comunicación entre Computador-Computador .......................... 219 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 18 Figura 5.16: Comunicación entre Dispositivo móvil-Dispositivo móvil ............ 219 Figura 5.17: Interrupción y reconexión entre dos usuarios ............................. 219 Figura 5.18: Comunicación inicial – Canal de Video ......................................... 221 Figura 5.19: Comunicación inicial – Canal de Audio ......................................... 222 Figura 5.20: Interrupción – Canal de Video ...................................................... 222 Figura 5.21: Interrupción – Canal de Audio ...................................................... 223 Figura 5.22: Reconexión – Canal de Video ....................................................... 223 Figura 5.23: Reconexión – Canal de Audio ....................................................... 224 Figura 5.24: Comunicación inicial – Canal de Video ......................................... 226 Figura 5.25: Comunicación inicial – Canal de Audio ......................................... 226 Figura 5.26: Interrupción – Canal de Video ...................................................... 227 Figura 5.27: Interrupción – Canal de Audio ...................................................... 227 Figura 5.28: Reconexión – Canal de Video ....................................................... 228 Figura 5.29: Reconexión – Canal de Audio ....................................................... 228 Figura 5.30: Resultados de canal de audio – fase inicial .................................. 231 Figura 5.31: Resultado de canal de video – fase inicial .................................... 231 Figura 5.32: Resultados de canal de audio – zona de no cobertura................. 231 Figura 5.33: Resultados de canal de video – zona de no cobertura ................. 232 Figura 5.34: Resultados de canal de audio – zona de cobertura ...................... 232 Figura 5.35: Resultados canal de video – zona de cobertura .......................... 232 Figura 5.36: Resultados de canal de audio – retorno de una interrupción ...... 232 Figura 5.37: Resultado de canal de video – retorno de una interrupción........ 232 Figura 5.38: Sesión inicial de comunicación ..................................................... 234 Figura 5.39: Resultados de inicio de sesión - canal de audio ........................... 234 Figura 5.40: Resultados de inicio de sesión – canal de video ........................... 234 Figura 5.41: Resultados zona de no cobertura – canal de audio ..................... 234 Figura 5.42: Resultados zona de no cobertura – canal de video ...................... 234 Figura 5.43: Resultados de una desconexión de sesión – canal de audio ........ 235 Figura 5.44: Resultados de una desconexión de sesión – canal de video ........ 235 Figura 5.45: Nueva sesión reconectada ............................................................ 235 Figura 5.46: Resultados de la sesión reconectada – canal de audio. ............... 235 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 19 Introducción En este capítulo se presenta: las motivaciones y contexto del problema que ha sugerido la realización de este trabajo de investigación, los objetivos y aportaciones de esta tesis doctoral y por último presentamos la estructura de esta memoria. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 20 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 21 1.1. Motivaciones Con la penetrante aceptación de las redes inalámbricas sobre dispositivos inalámbricos en ámbitos empresariales, residenciales y públicos, mediante el uso de los estándares como: Wireless Fidelity (WiFi) [1]; Worldwide Interoperability for Microwave Access (WiMAX) [2], 3rd Generation Partnership Project (3GPP-3GPP2) [2], [3]; Universal Mobile Telecommunications System (UMTS) [4] y Long Term Evolution (LTE) [5], han permitido visualizar contenidos multimedia en tiempo real mediante la utilización de tecnología de streaming. Video streaming es una técnica que consiste en objetos multimedia que se reproducen y descargan simultáneamente desde el Internet sin la necesidad de almacenar toda la información en la memoria del cliente, por tanto, no requiere que el video se almacene en el teléfono móvil. El problema para implantar la visualización de contenidos multimedia en dispositivos inalámbricos en tiempo real o bajo demanda, radica en varios aspectos: limitaciones de procesamiento, memoria, consumo de batería, pantalla de visualización y un comportamiento caótico espacio-temporal e irregular de los canales de comunicación inalámbricos (todas las tecnologías sufren de este inconveniente, en especial WiFi que provoca impredecibles pérdidas de cobertura), que provocan desconexiones radio por varias causas: deterioro de la señal, fuera de cobertura, entre otros [6]. Estas impredecibles desconexiones afectan la transmisión del contenido multimedia mediante tecnología video streaming, haciendo que sea necesario el inicio de una nueva sesión o siendo muy pesimista el abandono de la misma. Los buffers de visualización mitigan desconexiones de muy corta duración. Si la desconexión es de larga duración, el buffer se vacía y se corta la visualización. Es imperioso, plantear una solución al problema que afecta a la transmisión de contenido multimedia mediante mecanismos, que permitan controlar el restablecimiento de la comunicación y posterior visualización del contenido multimedia desde la posición en la que se encontraba, el cliente, al momento de ocurrir la interrupción. Una de las primeras aproximaciones realizadas por el grupo de investigación, establece un mecanismo basado en proxies, usado en computadores portátiles y dispositivos inalámbricos basados en sistema operativo Symbian [7]. Este mecanismo Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 22 implementa el uso de agentes para recuperar sesiones Real Time Streaming Protocol (RTSP) [8], desarrollados en Java Agent Development Framework (JADE) [9] para portátiles y JADE Lightweight Extensible Agent Platform (LEAP) [10] para dispositivos inalámbricos. Un Proxy es un conocido patrón de diseño software. Por ello, la principal motivación de esta tesis doctoral es lograr que esta arquitectura puede ser usada como un modelo de base para conseguir soluciones aplicables a varios tipos de dispositivos inalámbricos utilizando patrones de diseño software más potentes. 1.2. Contexto del problema El constante desarrollo tecnológico de los dispositivos inalámbricos y las redes de comunicación inalámbrica han despertado mucho interés en los usuarios por el consumo de aplicaciones para visualizar contenido multimedia en tiempo real o bajo demanda. Los teléfonos móviles hoy en día, son dispositivos poderosos con varias interfaces de redes inalámbricas heterogéneas, que permiten recibir la información multimedia a través de la tecnología video streaming a bajo costo. Video streaming es muy apropiada para aplicaciones cliente que corren en dispositivos portables (celulares, agenda personal de bolsillo, reproductor de audio digital) debido a su limitada memoria y ancho de banda; esta técnica trata de ocultar la latencia de la red en una sesión entre el cliente y el servidor, consiguiendo que el tiempo de espera por tramas de video consecutivas sean mínimas. Sin embargo, las interrupciones del servicio de video streaming o videoconferencia provocan que el servidor continúe enviando información generando gasto de recursos del servidor y sobrecarga en el canal. Mitigar estos efectos es importante porque con video streaming es posible acceder a contenidos de televisión digital que proporcionan cadenas de televisión, esto permite el aumento de sus cuotas de audiencia a un precio razonable. Mitigar las interrupciones de servicio en video streaming móvil en Internet con redes de acceso móvil e inalámbricas es un problema que aún no ha sido solucionado eficientemente, existe dificultad de controlar las interrupciones intermitentes Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 23 ocasionados por pérdida de cobertura u otras causas en redes inalámbricas. La pérdida de conexión puede ser por naturaleza muy variada y producirse a diferentes niveles de la arquitectura de red; surgen entonces dificultades de recepción de datos multimedia, cierre de la sesión actual y obligatoriedad de abrir una nueva sesión, gastos de los recursos del servidor al enviar tramas multimedia desconociendo el estado real del cliente; todo esto confluye a la perdida de efectividad de video streaming y a la ineficiencia de RTSP, ocasionando también pérdida de tiempo del usuario que abandona la sesión de forma definitiva. Un problema importante que las redes inalámbricas presentan ante un servicio de video streaming es la baja fiabilidad a fluctuaciones de ancho de banda que conducen a la degradación de la calidad de video de manera significativa [11][12]. Especialmente en servicios de video streaming multimedia móvil donde las prestaciones son muy altas de ancho de banda y velocidad de transmisión de datos, para satisfacer la demanda del Mercado. Los operadores móviles están aprovechando WiFi para aliviar la presión de la demanda de ancho de banda creciente de aplicaciones y están tratando de proveer mecanismos inteligentes que controlen la forma que acceden los usuarios a las redes WiFi. Esta falta de controles degrada la Calidad de la Experiencia de usuario (QoE, del inglés Quality of Experience). Es importante el aprovisionamiento de la Calidad de Servicio (QoS, del inglés Quality of Service) de extremo a extremo, necesario para el mantenimiento continuo de reproducción de video en las aplicaciones multimedia en tiempo real. Condición que se ve afectada por la realidad del canal inalámbrico que es muy variable en el tiempo, debido a interferencia, fading, y movilidad; provocando que el servicio de video streaming media no pueda ser difundido con calidad [13][14]. Múltiples factores afectan a las redes inalámbricas al realizar video streaming, problemas como ancho de banda variable en el tiempo, efectos de atenuación, degradación de señal, interferencias, retraso, jitter o alta tasa de pérdida de paquetes. Si el remitente transmite más rápido que el ancho de banda disponible, entonces la congestión ocurre. Los paquetes se pierden y hay una severa caída de la calidad de video. Si el emisor transmite más lento que el ancho de banda disponible entonces el receptor produce una calidad de video óptima [15] [16] [17]. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 24 Sin embargo, la transmisión de datos en los canales inalámbricos sufren de muchos errores, pérdidas frecuentes de paquetes y la cobertura de radio no siempre es constante, por lo que se produce interrupciones frecuentes del teléfono móvil. Estas interrupciones son totalmente impredecibles y únicamente se puede mitigar su efecto adverso sobre la comunicación [18]. La transmisión del video streaming en redes inalámbricas enfrenta desafíos de las condiciones del canal y recursos de red limitados. Por lo tanto, para un eficiente video streaming se requiere de una eficiente QoS y un mecanismo de control. Esto permite mitigar la inestabilidad de las redes inalámbricas a problemas como ancho de banda variable en el tiempo y limitado, y la congestión de tráfico durante la transmisión de una ráfaga de flujos [19] [20]. El servicio de video streaming presenta un proceso complejo de percepción por el usuario en su sistema visual y auditivo, combinado con el sistema sensorial y cognitivo. La relación que presentan los aspectos sensorial y auditivo con el video determinan aspectos como: brillo, color, forma, movimiento, tono de audio, volumen y timbre [21][22]. La QoE para los servicios multimedia se relaciona fuertemente con la QoS, rendimiento del terminal y atributo de servicio. La QoE es una medida del rendimiento de los niveles de servicio video streaming bajo la perspectiva del usuario, proporciona una medida subjetiva que cuantifica el impacto que tiene en el usuario la presencia de fallos en el servicio. Estos fallos pueden ser determinados por métricas de QoE como: la duración de los fallos en el servicio, errores por segundo y segundos sin disponibilidad del servicio [23]. En relación al rendimiento de un dispositivo móvil ante un video streaming, tenemos factores que afectan drásticamente la QoE por limitaciones de capacidad del procesamiento, capacidad de visualización, velocidad de procesamiento, capacidad de almacenamiento y tamaño del buffer de memoria, factor clave para mitigar el retraso y el jitter [24]. La Unión Internacional de Telecomunicaciones (ITU-T, del inglés International Telecommunication Union) desarrolló modelos de QoE estandarizados para predecir la calidad de audio, video y voz; utilizando de forma subjetiva Mean Opinion Score (MOS) [24] [25] [26]. En [27] se analiza los enfoques de medición de calidad de video propuestos para evaluar la diferencia de calidad entre fotografías Peak-Signal-to-NoiseRatio (PSNR), para medir los efectos de percepción de las deficiencias de video Video Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 31 establecimiento, éste invoca al servidor WebRTC quien solicita permiso al cliente WebRTC para acceder al recurso de la cámara y micrófono del dispositivo móvil y la creación de un usuario. Proxy al recibir el usuario creado invoca al algoritmo validación para verificar si es nuevo o existe en la base de datos de usuario. Si es nuevo lo crea y registra en la base de datos, si existe solicita a la base de datos la información del usuario para entregarle al servidor WebRTC. Creados los usuarios para los clientes WebRTC, Proxy espera que uno de ellos solicite el inicio de videoconferencia para pedir a estrategia el algoritmo establecimiento. Una vez establecida la sesión, el Proxy del subsistema sesión activa el Observer de Modelo para que informe si existe algún cambio en el umbral del almacenamiento temporal. Dada la alerta por Observer, el Proxy solicita confirmación mediante el monitoreo del Observer externo canal del subsistema externo sobre el estado del canal de comunicación. Con un estado de interrupción, el Proxy solicita a estrategia implantar el algoritmo interrupción que ejecuta dos actividades: solicitar el almacenamiento temporal de los flujos de audio y video emitidos por los clientes WebRTC en los dispositivos inalámbricos y comunicar a sus vistas de esta situación mediante un mensaje Reconectando. Si el estado del canal indica que está operativo, Proxy solicita a estrategia cambiar al algoritmo conexión para solicitar el restablecimiento de la sesión de videoconferencia, por lo que es llamado nuevamente el subsistema establecimiento. Una vez establecida la sesión, el Proxy solicita al almacenamiento temporal de los clientes enviar este buffer almacenado al almacenamiento del servidor de aplicaciones, para en éste llamar al patrón Adapter para que convierta el flujo de audio y video y sea enviado nuevamente a los clientes WebRTC opuestos para despliegue en vista de cada dispositivo móvil. Con la experimentación práctica se ha demostrado que es factible mantener el modelo base e incrementar o reemplazar nuevas funcionalidades, existe un incremento de coste por el tiempo de establecimiento de la sesión de videoconferencia que es mínima y no afecta al tiempo de ejecución de la videoconferencia y video streaming de video ante varias interrupciones del canal de comunicación inalámbrica. En cuanto a publicaciones, este trabajo ha dado lugar a la publicación: • T. Gualotuña, D. Marcillo, E. M. López, and A. Suárez-Sarmiento, Mobile Video Service Disruptions Control in Android Using JADE” in Advances in Computing Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 32 and Communications, Springer, 2011, pp. 481–490, que presenta la arquitectura basado en proxies y agentes inteligentes para el control de interrupciones en ambientes inalámbricos en dispositivos Android, que resuelve la interrupción y reanuda automáticamente la sesión de video streaming sin pérdida de la información mediante la aplicación de almacenamiento temporal intermedio. En relación a la definición y ejecución de proyectos de investigación como Director de proyecto se ha dado lugar a: • Prototipo de un sistema ubicuo de localización y navegación autónoma usando dispositivos móviles, que promueve el desarrollo de aplicaciones que permiten utilizar realidad aumentada y geolocalización para ubicación de lugares en la Escuela Politécnica del Ejército (ESPE), Quito, Ecuador. • Diseño de un mecanismo para control de interrupciones en servicios de video streaming en dispositivos Android, que permitió el desarrollo del aplicativo para dispositivos Android para la recuperación de sesiones de video streaming frente a una interrupción. • Sistema de monitorización para el servicio de comunicaciones unificadas en Elastix 2, que propone implementar en el sistema de monitorización un mecanismo que permita la continuidad de la información ante algún quiebre del canal de comunicación inalámbrico. • Mitigación de interrupciones en un servidor de contenido multimedia basado en tecnología IPTV, que propone controlar la interrupción en ambientes inalámbricos entre el servidor de contenidos multimedia y el set top box, y este envíe dicha señal hacia una TV. En cuanto a trabajo dentro del grupo de investigación en Modelos de Procesos de Software de la ESPE se ha colaborado con el proyecto: • Laboratorio industrial en Ingeniería de Software Empírica, cuyo objetivo es mejorar la comprensión del proceso de desarrollo de software en la industria, utilizando ambientes experimentales controlados y estudios empíricos que Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 33 permitan obtener conocimiento sobre el comportamiento de las tecnologías de software en diferentes entornos. En cuanto a trabajo del grupo de investigación de televisión digital ESPETV se ha colaborado en los proyectos: • Diseño y desarrollo de una aplicación de contenidos interactivos para tv digital basada en el middleware Ginga del sistema brasileño, se centra en el estudio y desarrollo de contenidos interactivos utilizando el middleware Ginga y su motor de presentación Ginga-Nested Context Language (NCL). • Video streaming para la visualización en tiempo real de la funcionalidad de una aplicación interactiva transmitida en Broadcast Transport Stream, se centra en la generación de un enlace entre el usuario y el laboratorio de televisión digital mediante su plataforma de usabilidad permitiendo realizar pruebas de funcionalidad de las aplicaciones interactivas en tiempo real. En relación a la definición y propuesta de proyectos de investigación a ejecutarse se ha colaborado en: • Monitoreo de un invernadero mediante el uso de Wireless Sensor Network (WSN) y tratamiento de flujos de datos mediante técnicas adaptativas a cambios del entorno, que busca desarrollar un sistema que permita la captura de la información de humedad relativa, temperatura y suelo por medio de sensores en un invernadero, para almacenarlos y procesarlos mediante minería de datos con la finalidad de establecer patrones que apoyen en la toma de decisiones. 1.5. Estructura de la memoria El trabajo que hemos llevado a cabo se presenta en seis capítulos claramente definidos en esta memoria. Cada uno corresponde a un aspecto del estudio de la investigación. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 34 En el capítulo 2, se presentan: los avances del video streaming de video, arquitectura, servidores y protocolos, sobre redes inalámbricas; la necesidad de plantear un mecanismo que permita mitigar los impactos de las interrupciones del servicio de video streaming; las herramientas disponibles a utilizarlas en el desarrollo del mecanismo; y el modelo basado en patrones software del servicio video streaming. En el capítulo 3 se presenta: el modelo basado en patrones software de diseño para Android utilizando agentes que se implantan en una aplicación nativa. En el capítulo 4 se presenta la iteración del modelo anterior para incluir: experiencia inmersiva y sensado móvil; y la publicación de archivos Keyhole Markup Language (KML), para representar la información, tratada por el agente inteligente, con herramientas para visualizar múltiple cartografía como: Google Earth o Google Maps. En el capítulo 5, sobre una plataforma Web multiplataforma para video en tiempo real, se establece el modelo base para controlar interrupciones de una sesión de Web videoconferencia y video streaming de video, debido a una disrupción del canal de comunicación inalámbrico. Se mantuvo el modelo base en forma iterativa con incrementales en sus dos subsistemas: establecimiento y externo. Cada uno de estos subsistemas se desarrolló con base en patrones software de diseño y funcionalidades adicionales para cumplir con el objetivo de proveer control de interrupción y continuidad del servicio de Web videoconferencia y video streaming de video. En el capítulo 6 se presentan las conclusiones de este trabajo y se comentan algunas líneas de trabajo que consideramos serán interesantes abordar. Por último, se presenta el glosario de términos empleados a lo largo de la memoria, las referencias bibliográficas consultadas. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 35 Problemática de video streaming y videoconferencia inalámbricos En este capítulo se presenta en primer lugar el desarrollo espectacular de las redes inalámbricas, en especial WiFi, y los avances tecnológicos de los dispositivos inalámbricos en los últimos años por el consumo de nuevos productos, como servicio de video streaming. Se estudia el auge sensacional de los servicios de video streaming y videoconferencia móviles, y se introduce en las arquitecturas que manejan para brindar QoE. Se especifican los inconvenientes que producen las interrupciones de servicio de video streaming y videoconferencia y los retos planteados para bosquejar un mecanismo que permita mitigar el impacto de una interrupción. Finalmente se diseña un modelo basado en patrones software para el servicio de video streaming. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 36 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 37 2.1. Tecnología de redes y dispositivos Las redes inalámbricas están emergiendo para proveer a los usuarios mejores servicios basados en las ventajas que presentan como: movilidad, flexibilidad, escalabilidad, velocidad, simplicidad y costos reducidos de implementación. Esto se debe al gran avance tecnológico que ha tenido las infraestructuras inalámbricas como redes de área personal inalámbrica (Bluetooth), Home Radio Frequency (HomeRF), Zigbee, WiFi, LTE. En la Figura 2.1 se visualiza la clasificación de las redes inalámbricas en varias categorías, de acuerdo al área geográfica desde la que el usuario se conecta a la red, denominada área de cobertura. La tecnología WiFi define una red de área local inalámbrica (WLAN, del inglés Wireless Local Area Network) que cubre un área equivalente a la red local de un hogar o empresa, con un alcance aproximado de cien metros. Permite que los dispositivos inalámbricos que se encuentran dentro del área de cobertura puedan conectarse entre sí. Es ampliamente utilizada a día de hoy y se ha optimizado su rendimiento y eficiencia espectral [34], que ha permitido ejecutar aplicaciones de contenido multimedia. Prácticamente todos los teléfonos móviles implantan WiFi. Proporciona movilidad; facilidad de instalación y configuración; y relativas altos anchos de banda [35], tanto en la banda de 2,4 como 5 GHz. A pesar de la expansión actual de la versión Institute of Electrical and Electronic Engineers (IEEE) 802.11n, la industria ya trabaja en nuevos productos y dispositivos basados en el estándar IEEE 802.11ac, creciendo un 30% respecto al año pasado (Figura 2.2). Este estándar dispondrá de tasas de transmisión de al menos algunos Gbps para la comunicación multimedia entre los clientes con dispositivos inalámbricos con una alta fiabilidad y una cobertura uniforme [36] [37]. El nuevo estándar IEEE 802.11ad está pensado para comunicaciones directas de gran velocidad y corto alcance entre equipos como ordenadores, móviles, tabletas, discos de red y televisores, tanto para vídeo en video streaming en alta definición (HD, del inglés High Definition) o ultra alta definición (UHD, del inglés Ultra High Definition) sin cables como para pasar grandes cantidades de datos de forma inalámbrica entre por ejemplo un disco duro y un ordenador. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 38 Figura 2.1: Redes inalámbricas por área de cobertura La incorporación de nuevas tecnologías, tanto en los teléfonos móviles como en las redes inalámbricas, ha permitido el despliegue de nuevos servicios de video streaming y comunicación en tiempo real, gracias a las altas tasas de transmisión y capacidades de memoria y buferización disponibles para la implementación de estos nuevos servicios [38] [39]. Esto ha configurado un nuevo paradigma social, cultural y educativo; ya que no solo aportan con la movilidad sino también con la conectividad, ubicuidad y permanencia [40]. La insaciable demanda por dispositivos inalámbricos como: teléfonos inteligentes; tabletas y otros dispositivos, y la computación ubicua están generando una enorme cantidad de datos en las redes inalámbricas; esto se debe a la capacidad de comunicación, procesamiento y almacenamiento por parte de los dispositivos inalámbricos y su facilidad para integrarse con esta redes [41]. El Cisco Visual Networking Index (VNI) predice que el tráfico global en redes móviles se multiplicaría 18 veces en el periodo de 2011 a 2016, alcanzando 10.8 exabytes por mes [42]. En paralelo, el uso de WiFi para acceso al Internet está creciendo exponencialmente en la medida en que más dispositivos se habilitan con capacidad WiFi. El número de sitios públicos con acceso inalámbrico a Internet se expande y la aceptación del usuario se incrementa [43]. Otro paradigma que se encuentra en formación es el llamado Internet móvil, apoyado en la integración de tecnología de las redes inalámbricas, dispositivos Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 39 inalámbricos inteligentes (teléfonos o celulares inteligentes) y funcionalidades de cómputo móvil [44]. Estos logros proporcionan a los usuarios móviles acceso ubicuo a la Internet mediante un sistema convergente basado en redes de acceso heterogéneas para proporcionar servicios móviles de alta calidad [45]. El mercado de teléfonos inteligentes en todo el Mundo creció un 13,0% por año al segundo trimestre de 2015, con 341,5 millones de equipos vendidos, de acuerdo con datos de la International Data Corporation (IDC) de la estadística Worldwide Quarterly Mobile Phone Tracker (WQMPT). Android domina el Mercado con una participación de 82,8%, en el segundo trimestre de 2015, iOS presenta un descenso en un 22,3% respecto al trimestre de 2014, Windows Phone experimentó un descenso intertrimestral del 4,2% y Blackberry OS, sigue disminuyendo en el crecimiento a nivel mundial. La tabla 2.1 describe las características de las diferentes versiones del SDK de Android que han salido al mercado. Tabla 2.1: Características de las versiones SDK de Android Versión Nombre Características 1.0 Apple Pie Lanzado en septiembre 2008. Primera versión de Android. Navegador Web con soporte de múltiples ventanas. Soporte básico de cámara de fotos. Mensajería instantánea. Reproductor de música. Soporte para teléfonos con LED. Marcación por voz. Conectividad WiFi y Bluetooth. Aplicaciones básicas. Nunca se utilizó comercialmente. 1.1 Banana Bread Lanzado en febrero 2009. Versión que usaron para corregir errores de la primera versión. Adiciona detalles y reseñas sobre lugares y negocios en Google Maps. Nueva pantalla para manos libres. Mostrar y ocultar teclado. Guardar archivos adjuntos en los mensajes. 1.5 Cupcake Lanzado en abril 2009. Basado en Linux kernel 2.6.27. Rediseño completo de todos los elementos de la interfaz. Transiciones animadas entre ventanas. Intérprete JavaScript. Posibilidad de personalizar los widgets mostrados en la pantalla de inicio. Añade la posibilidad de grabar y reproducir vídeos. 1.6 Donut Lanzado en septiembre 2009 Basado en Linux kernel 2.6.29 Adiciona el Quick Search Box, una caja de búsqueda en la pantalla de inicio con autocompletado y capacidad de aprendizaje. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 40 Mejora la velocidad de la cámara. Posibilidad de conectarse a redes VPN, 802.1x. Nuevo motor de texto a voz. 2.0 - 2.1 Eclair Lanzado en octubre 2009. Basado en Linux kernel 2.6.29 Rediseñó la interfaz del navegador, contando ahora con soporte para distintas características de HTML5. Mejoras en el teclado virtual. Galería 3D, al estilo Cover Flow. Nuevas aplicaciones de reloj/tiempo y noticias. Google Goggles. Mejoras en la duración de la batería. 2.2 – 2.2.3 Froyo Lanzado en mayo 2010. Basado en Linux kernel 2.6.32. Soporte WiFi IEEE 802.11n. Soporte Flash 10.1 y Adobe AIR 2.5 Soporte de la API gráfica OpenGL 2.0 Creación de un compilador JIT que mejora entre 2 y 5 veces en Rendimiento frente a Eclair. Incorporación del mismo motor de Javascript V8 de Chrome. Opciones avanzadas de gestión energética 2.3 – 2.3.7 Ginger Bread Lanzado en diciembre 2010. Basado en Linux kernel 2.6.35. Soporte de resoluciones de hasta 1.280x760. Soporte para: pantallas extra grandes. Reproducción de videos y decodificación de audio AAC. Teclado multitáctil. Soporte nativo para telefonía. Soporte para sensores como giroscopio y barómetro. Administración de la energía mejorada. 3.0 - 3.2.6 Honey Comb Lanzado en febrero 2011. Basado en Linux kernel 2.6.36. Sistema multitarea mejorado. Soporte para tabletas, video chat, redes WiFi. Se añade soporte para una gran variedad de periféricos y accesorios con conexión USB. 4.0 – 4.0.4 Ice Cream Sandwich Lanzado en noviembre 2011. Basado en Linux kernel 3.0.1. Versión que unifica el uso en cualquier dispositivo. Interfaz limpia y moderna con una nueva fuente llamada Roboto. Aceleración por hardware que permite manejar a la interfaz aumentando notablemente su rapidez. Respuesta a la experiencia de usuario. Multitarea mejorada. Gestor del tráfico de datos de internet. Mejoras en el corrector de texto. Posibilidad de realizar fotografías panorámicas de forma automática. Reconocimiento de voz del usuario. Reconocimiento facial. Lápiz táctil. 4.1 – 4.3.1 Jelly Bean Lanzado en julio 2012. Basado en Linux kernel 3.0.31. Optimización de las transiciones en la interfaz. Pantalla de inicio con widgets e iconos. Vista previa de las capturas fotográficas. Predicción de palabras del teclado. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 47 El Proxy se comporta como un Proxy multimedia y se encarga de mantener la comunicación con el cliente durante la reproducción del video, estado de la sesión e interacción con el usuario [64], [65]. Algunas arquitecturas que emplea las tecnologías video streaming se las detalla a continuación [60], [62]: - Arquitectura típica, usa la arquitectura cliente-servidor y los protocolos más usados son: • Para el escenario sin control sobre la transmisión tenemos Hypertext Transfer Protocol (HTTP). • Para el escenario con control sobre la transmisión tenemos: o En el nivel de aplicación: RTSP responsable de la entrega de datos en tiempo real, no orientado a conexión. El control y reenvío de datos es responsabilidad de Transmission Control Protocol (TCP), Microsoft Media Server (MMS), Real Time Messaging Protocol (RTMP) y Real Time Media Flow Protocol (RTMFP). o En el nivel de transporte: Real Time Transport Protocol (RTP), User Datagram Protocol (UDP) y TCP. - Arquitectura sin servidor (Server-Less), no presenta un servidor de audiovideo, el archivo se le proporciona al cliente mediante un servidor Web (pseudo-video streaming o Fast-Start). Usa TCP y HTTP. - Arquitectura sin cliente, no hay una aplicación cliente. Simula el funcionamiento de un servicio bajo demanda con flujo de datos en directo. Para visualizar el contenido multimedia se utiliza un applet java o algún plugin. En todas estas arquitecturas ninguna incluye un mecanismo para reconectar automáticamente la sesión de comunicación ante una interrupción del canal inalámbrico. El servidor es el encargado de transmitir nuestro programa contenido multimedia (programa de televisión, archivo de video…) usando la tecnología video streaming. Para entender mejor cómo funciona en el contexto de la tecnología video streaming, vamos a explicarlo como un proceso dividido en tres etapas: adquisición, Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 48 codificación-transcodificación y entrega. Durante el proceso de adquisición se captura la señal en directo (cámara o tarjetas de captura de audio y video) o se la recibe de algún sitio Web que permita compartir videos, para después codificar la señal. La primera codificación se lleva a cabo en el origen siguiendo los estándares del mercado, en este punto es donde la señal tiene la máxima calidad [66]. Existen algunos software de codificación, los más comunes son; Wirecast, Viewcast, Digital Rapids, Flash Media Live Encoder… En el proceso de transcodificación se descomprime la señal codificada (la señal entra al servidor video streaming) y después se codifica de nuevo a los diferentes formatos. La señal se optimiza para que llegue sin problemas de retransmisión a los diferentes dispositivos. Finalmente en la entrega la señal llega al usuario final en cada una de las calidades y formatos disponibles a los diferentes dispositivos. Esta entrega se la realiza con cualquiera de los protocolos para servicio de video streaming. Los servidores de video streaming deben procesar datos multimedia con ciertas restricciones temporales para prevenir fallas (llamadas jerkiness en video y pops en audio), para poder ofrecer servicios de calidad [67]. Además deben soportar comandos tipo VCR 59 que permitan parar, poner en pausa, adelantar o retroceder el video y entregar el audio y video sincronizados [68]. Un servidor típico de video streaming consta de: • Comunicador: contempla la capa de aplicación y los protocolos de transporte implementados en el servidor. • Sistema Operativo: debe soportar aplicaciones en tiempo real a más de los servicios típico. • Sistema de almacenamiento: debe soportar almacenamiento y retiro continuo de medios. Uno de los más utilizados como servidor de video streaming es VLC media player, del proyecto VideoLAN. VLC media player es un framework y reproductor multimedia libre y de código abierto, multiplataforma. Soporta la mayoría de archivos multimedia, así como DVD, Audio CD, VCD y diversos protocolos de transmisión. Utiliza la biblioteca CODEC libavCODEC del proyecto FFmpeg para manejar los muchos formatos soportados Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 49 por esta, y emplea la biblioteca de descifrado DVD libdvdcss para poder reproducir DVD cifrado. El desarrollo de los protocolos de comunicación y transporte, que mejoran y agilizan el proceso de transmisión de datos, han permitido que se implementen servicios de video streaming. Los protocolos de transporte se encargan del control de errores, la secuenciación y el control de flujo en el servicio de video streaming. Se presenta dos protocolos TCP [69] que ocasiona un retraso muy elevado, debido a procesos de retransmisión que los servicios en tiempo real no pueden asumir; y UDP [70] que permite el envío de datagramas sin control de flujo ni necesidad de confirmación de entrega, evitando la demora del proceso con interrupciones por errores en el protocolo. Los protocolos de comunicación permiten gestionar el establecimiento y sesión mediante RTSP y el transporte y control mediante RTP y Real Time Control Protocol (RTCP). RTSP [8], es un protocolo que se encarga de mantener y controlar la sesión entre el cliente y el servidor de streaming. Actúa únicamente en la parte de control del envío de datos en tiempo real, ya que los datos viajan por canales diferentes. Permite establecer una comunicación entre el cliente y el servidor para ejecutar interacciones (pausa, avance, retroceso) durante la reproducción e intercambio de mensajes por medio de un conjunto de métodos. RTSP es independiente de la capa transporte y distingue tres estados: inicial, listo (estado posterior a la inicialización de la sesión) y emitiendo (estado en el que se lleva a cabo la distribución de los contenidos). En la Figura 2.5, se observa la transición entre un estado u otro mediante la ejecución de los métodos. Un ejemplo del proceso de establecimiento de sesión se observa en la Figura 2.6, además del intercambio de mensajes propios del protocolo RTSP, también observamos el envío de la información multimedia mediante el protocolo RTP y el envío de información de control por parte del cliente mediante protocolo RTCP. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 50 Figura 2.5: Diagrama de estados para RTSP Figura 2.6: Establecimiento de conexión en RTSP RTP [71], es un protocolo para el transporte extremo a extremo de datos (audio y video) en tiempo real sobre la Red. No garantiza que los paquetes lleguen a su destino, producto de la variación de las características de la Red en el transcurso de la comunicación. Generalmente trabaja sobre UDP, por lo que necesita apoyo de protocolos asociados, como RTCP, para informar y realizar cierto control sobre el estado del canal de comunicación. No define un mecanismo para asegurar la calidad de servicio, porque solamente se centra en el transporte de los datos. RTCP [72], funciona en conjunto con RTP y su objetivo es la monitorización del envío de paquetes RTP, mediante la transmisión periódica de paquetes de control. Su Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 51 función principal es de entregar información estadística de la conexión acerca de calidad de servicio (pérdida de paquetes, retraso, jitter), que puede ser empleada por aplicaciones para ajustar la codificación y otros parámetros. Session Description Protocol (SDP) [73], es un protocolo que se emplea para describir los parámetros de inicialización de sesiones multimedia. Define parámetros que permite cubrir aspectos como anuncio de sesión, invitación a sesión y negociación. No se encarga de entregar los contenidos (datos), sino de entablar una negociación entre las entidades que intervienen en la sesión como tipo de contenido, formato y demás parámetros asociados. 2.2.2. El servicio de videoconferencia La videoconferencia es un servicio de telecomunicación multimedia, que permite la comunicación e interacción en tiempo real entre dos personas o grupo de personas que se encuentran geográficamente distantes [74]. Dependiendo de la tecnología que se utilice, la videoconferencia logra ser completamente interactiva y crea un ambiente como que todas las personas participantes de la videoconferencia se encontrasen en la misma ubicación física [75]. La forma genérica de clasificar los sistemas de videoconferencia considera el tipo de enlace [76]. Dentro de esta clasificación se encuentran: • Sistema punto a punto: la comunicación se realiza entre dos puntos remotos. • Sistema multipunto: la comunicación se realiza entre dos puntos o más sedes enlazadas. Los componentes básicos que conforman un sistema de videoconferencia son los siguientes: • Red de comunicaciones: es donde se consolida el sistema de videoconferencia, proporciona una comunicación digital bidireccional. La selección de la red de comunicación para prestar el servicio de videoconferencia depende de los requisitos del usuario. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 52 • Sala de videoconferencia: es el espacio acondicionado para alojar a los participantes de la videoconferencia. Considera cuatro componentes: ambiente físico, sistema de video, sistema de audio y sistema de control. • CODEC: es el que provee de los formatos de audio y video necesarios para establecer la videoconferencia. Hasta hace unos años, la videoconferencia tendía a encajar en uno de estos dos ámbitos: empresas con grandes presupuestos que tenían grandes salas de conferencias especializadas, que recuerdan a pequeños estudios de difusión; y organizaciones más pequeñas que tenían que buscar soluciones más rentables que afectaban a la calidad de la imagen y el audio. En ambos casos, las deficiencias en la facilidad de uso y la fiabilidad conllevaban frecuentes llamadas telefónicas al equipo de apoyo en busca de asistencia. Uno de los claros culpables durante esta primera generación de soluciones de videoconferencia era la conexión a Internet, ya que aquellos que tuvieran mala conexión tenían que descifrar los diálogos irregulares con la visión borrosa de los que hablaban [77]. Con estas restricciones en mente, se pretendía conseguir llamadas que fueran lo suficientemente buenas; después de todo, el propósito era ahorrar costes al eliminar la necesidad de viajar por reuniones presenciales. En la actualidad, la videoconferencia de alta calidad no está al alcance de unos pocos, sino de unos muchos. La mejora del acceso a Internet de banda ancha de alta velocidad, las redes WiFi y el 4G han favorecido la creación de servicios de consumo como Skype, Google Hangouts y WebRTC, mientras que las restricciones presupuestarias han intensificado aún más la necesidad de un modelo de negocio virtual para organizaciones de todo tipo de tamaños y formas. El futuro de la videoconferencia puede estar dentro del propio navegador, WebRTC es un estándar abierto que forma parte de la especificación de HTML5 y que permite la comunicación de video y audio de alta calidad a través de la Web sin necesidad de utilizar plugins adicionales para poder realizar esta tarea. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 53 2.2.3. Degradación de la calidad de experiencia de usuario Es importante en todo servicio de video streaming sobre redes inalámbricas no solo tomar en cuenta la valoración del rendimiento de la Red sino también tomar en cuenta la percepción, perspectivas y hábitos del usuario [78]. El problema de entregar QoE en redes inalámbricas ha sido abordado desde diferentes aristas como disponer de eficientes técnicas de compresión del audio y video, tecnologías alternativas como video streaming adaptativo, entre otros [79]. La QoS de la comunicación inalámbrica no es el único parámetro considerado para determinar si un servicio de video streaming establecido es óptimo. Es necesario tener un punto de vista del usuario, quiere decir, valorar la percepción (QoE) que el usuario tiene sobre el servicio. Estos aspectos pueden ser el tamaño de la pantalla y resolución del dispositivo móvil, CODEC utilizado y capacidad del búfer de datos ante las tasas de velocidad de carga durante la reproducción del video [80]. La QoS permite administrar los efectos que tiene el fenómeno de la congestión sobre el rendimiento del servicio de video streaming, para esto se hace uso de servicios integrados y servicios diferenciados que trabajan sobre los diferentes flujos de datos o sobre usuarios, como factor de métrica a nivel de capa de red, la QoS mide la cantidad de paquetes perdidos, el retraso y la variación del mismo (Jitter) [81]. QoE evalúa la calidad del vídeo desde dos perspectivas: • Desde el punto de vista del usuario: es decir, la percepción de la calidad del vídeo recibido en el cliente a la hora de su reproducción y visionado. Para este caso la degradación de la calidad se puede presentar de muchas maneras: por el efecto bloque, la pixelación, congelado de la imagen, entre otros. La medida de la calidad de los contenidos del vídeo recibido en el cliente puede realizarse mediante métricas objetivas o mediante métricas subjetivas. Las métricas objetivas están basadas en el uso de algortimos y las más empleadas son: PSNR y SSIM. Ambas requieren acceso a los contenidos originales para poder cuantificar la calidad de la imagen recibida. Por su parte, las métricas subjetivas se basan en las Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 54 opiniones de los usuarios frente a los estímulos de vídeo recibidos. El estudio de la calidad de vídeo mediante evaluaciones subjetivas supone un consumo de tiempo elevado, por lo que, habitualmente, se recurre a métricas objetivas. A pesar del dominio de las métricas objetivas PSNR y SSIM, existen otras, como MOVIE [82], que obtienen un elevado grado de correlación con las métricas subjetivas. Su principal inconveniente, a día de hoy, es el elevadísimo coste computacional durante su cálculo. • Desde el punto de vista de la red: además de las métricas anteriores de calidad percibida, e independientemente del tipo de CODEC empleado, tenemos que tener en cuenta la calidad de la transmisión reflejada a través del nivel de servicio de la red (es decir, si la conexión es capaz de transportar el vídeo). Los parámetros de ancho de banda, retraso, jitter y pérdidas serán determinantes para decidir si la red está preparada para ofrecer tráfico en tiempo real. Hoy en día aún existen una serie de limitaciones tecnológicas para ofertar un servicio de audio/vídeo de alta calidad a través de redes inalámbricas. La dinámica de las redes tipo best-effort en términos de variaciones de ancho de banda y retrasos hace que sea un problema proporcionar una buena calidad en las transmisiones video streaming. Algunas técnicas de codificación implementan métodos de corrección de errores [83]. Otra opción que podemos plantear es mejorar la arquitectura de red: podemos sobredimensionar el ancho de banda del enlace y esperar que el retraso, el jitter y las pérdidas no sean demasiado elevados (sin garantías). También podríamos solicitar la retransmisión de aquellos paquetes perdidos, pero aumentaríamos el retraso, empeorando aún más la calidad. Necesitamos, por tanto, otras soluciones para garantizar cierta QoS en los servicios de distribución de vídeo a través de redes inalámbricas. Por ejemplo, algunos programas utilizan técnicas a nivel de aplicación, como son el empleo de búffers o algoritmos de codificación resistentes a pérdidas, buscando mitigar los efectos del retraso, el jitter y las pérdidas. Una de las causas más frecuentes de los problemas que ocurren para el servicio de video streaming es una conexión a la red WiFi débil o intermitente. Las repeticiones Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 55 de almacenamiento en buffer o las cargas frecuentes, los problemas para iniciar la sesión del servicio de video streaming, los mensajes de error que indican que no es posible conectarse a la red WiFi o problemas para reproducir la sesión en un dispositivo, generalmente indican que la conexión a red WiFi es lenta o sufre interrupciones. Estos problemas afectan fuertemente a los diferentes tipos de servicio de video streaming que en la actualidad se utilizan: • En directo (live), similar a un canal de televisión. • Bajo demanda (on-demand), similar a un reproductor de vídeo. • Casi bajo demanda, simula el funcionamiento de un servicio bajo demanda con flujos de vídeo en directo. • Todos ellos utilizan técnicas de compresión de vídeo como MPEG-2/4, H.264/AVC, VP8 son una parte crítica del servicio de video streaming sobre redes WiFi [84], [85], [86], [87]. En las redes WiFi, se debe cumplir con características y requisitos de servicio para soportar servicio de video streaming como alto nivel de calidad, velocidad, tasa de bits, tasa de error máximo tolerable de paquetes y límites de retraso [88]. Factores que provocan las interrupciones en redes WiFi La transmisión de datos en redes WiFi presenta muchos factores que provocan pérdidas frecuentes de paquetes y quiebres de cobertura de radio, generando interrupciones en los usuarios de dispositivos inalámbricos. Los servicios de video streaming multimedia en la actualidad requieren de altas velocidades de transmisión de datos y grandes anchos de banda, esto es un serio problema en la comunicación inalámbrica por su baja fiabilidad y fluctuaciones del ancho de banda que conducen a la degradación de la calidad del contenido multimedia de manera significativa [89]. Este escenario es uno de los primeros problemas que se genera al transmitir paquetes de video atrasados y por lo tanto tenemos degradación tanto en el rendimiento de la red como la calidad del video. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 56 Otros factores que modifican las condiciones del canal de comunicación inalámbrico en el tiempo son la interferencia, fading y movilidad [90], donde es importante garantizar el aprovisionamiento de la calidad de servicio de extremo a extremo, muy necesario para la reproducción continua del contenido multimedia en tiempo real. Con respecto al ancho de banda disponible por el canal de comunicación inalámbrica, tenemos dos casos a ser analizados: • Si el ancho de banda disponible del canal de comunicación inalámbrica es menor a la tasa de transmisión del emisor, se presenta un escenario de congestión con pérdida de paquetes y una caída drástica de la calidad de video. • Si el ancho de banda disponible del canal de comunicación inalámbrica es mayor a la tasa de transmisión del emisor, se presenta un escenario de no pérdida de paquetes y una calidad de video óptima. La transmisión de contenido multimedia mediante tecnología video streaming a través de redes inalámbricas se expone a factores que inciden en disrupciones en la sesión multimedia como: • Variación en el tiempo de las condiciones de ancho de banda, retraso, jitter o alta tasa de pérdida de paquetes, generando pérdidas frecuentes de paquetes. • Cobertura de radio, no siempre constante, produce interrupciones totalmente impredecibles en los usuarios móviles. • Interferencia con otros dispositivos inalámbricos. • Variación de la velocidad de transmisión de los datos, depende de numerosos factores como: efectos de atenuación, degradación de la señal, aparición de interferencias, entre otros. En conclusión la transmisión de contenido multimedia mediante tecnología video streaming en redes inalámbricas enfrenta desafíos de las condiciones del canal, recursos de red limitados y la inestabilidad de la red inalámbrica conduce a problemas tales como Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 63 Un agente puede tener también acceso a un dominio y/o información de un modelo, si se asocia con la estructura de éste. Muchos de los sistemas existentes no tienen capacidad de colaboración, se utiliza agentes inteligentes para obtener la capacidad de cooperación entre ellos y así poder realizar y ejecutar las actividades encomendadas. Otro aspecto importante de resaltar es Agent Management System (AMS), sistema compuesto de múltiples agentes inteligentes interactuantes, cuyo objetivo principal es resolver problemas difíciles de hacerlo por un agente individual, gracias a la interacción de uno con otro mediante mensajes en ese entorno basados en características como: habilidades sociales, proactivas y reactivas [104]. Se debe considerar que para desplegar un agente debemos tomar en cuenta todos los aspectos referidos a su comportamiento y apoyarnos en metodologías y herramientas que permitan construir aplicaciones distribuidas basadas en componentes. Es necesario entonces considerar los siguientes aspectos definidos en [105]: • Modelar los agentes en un sistema y las interfaces de estos agentes. • Describir la información consumida y generada por cada agente. • Esbozar las posibles interrelaciones entre agentes. • Especificar el contenido de la información intercambiada entre agentes, estas especificaciones deber ser interpretables por la computadora y proveer suficiente detalle para conducir al despliegue de los agentes. Uno de los últimos desarrollos en tecnología de agentes, son los agentes móviles, se basan en el principio organizador de redes de comunicación entre ordenadores, conocido como Control de Procedimientos Remotos (RPC, del inglés Remoto Procedure Control) [106]. Cuando un ordenador cliente de una red (no importa su tamaño) dirige una petición al servidor de archivos para ejecutar una aplicación, el cliente debe realizar al menos dos comunicaciones: una solicitando la ejecución de un programa determinado, y otra informando al servidor que la operación se ha completado con éxito. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 64 La alternativa a este procedimiento es la Programación Remota (RP, del inglés Remote Programming), consistente en acordar por adelantado qué tareas pueden realizar los clientes sin ningún tipo de verificación ni confirmación por parte de los servidores [106]. De esta forma un cliente enviaría una instrucción al servidor de archivos, y una vez allí ejecuta un programa en concreto. Este procedimiento (remoto) que es una orden realizada por el cliente pero ejecutada en el servidor (local) recibe el nombre de operación o instrucción móvil, haciendo hincapié en que se trata de una orden remota que se ejecuta localmente. Un agente móvil puede suspender el proceso que esté realizando, transportarse a sí mismo por medio de la red y reanudar la ejecución del proceso que estaba llevando a cabo donde estime oportuno. Esta capacidad le permite al agente seleccionar la información recuperada antes de enviarla por la red, lo que evita la transferencia de grandes cantidades de información que podría ser inútil. Existe una gran cantidad de software denominado como software de agentes para Linux, Windows y otros sistemas operativos, sin embargo la herramienta para desarrollar agentes más extendida y utilizada es JADE [107] gracias a sus buenas herramientas gráficas, documentación, soporte, Licencia Pública General Reducida (LGPL) de GNU. JADE JADE es un middleware que proporciona tanto un entorno de desarrollo como un entorno de ejecución para la realización y mantenimiento de sistemas multiagente [107]. El entorno de desarrollo está formado por una serie de bibliotecas en Java que permiten la implementación de agentes de manera limpia e independiente de la plataforma sobre la que se va a ejecutar. El entorno de ejecución permite a los agentes vivir y comunicarse entre ellos. Está realizado enteramente en Java y proporciona una serie de herramientas que permiten al desarrollador controlar y depurar a los agentes en tiempo real [107]. Los aspectos más importantes en que se basa la plataforma JADE tenemos: Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 65 • Ejecución de agentes completamente asíncrona. • Comunicación entre agentes en la misma o diferentes plataformas JADE/ LEAP [10], [108]. • Programación de agentes mediante un conjunto de paquetes Java. • Validación de la ejecución mediante seguimiento mensajes y estado interno del agente. • Es la plataforma más extendida porque implementa el estándar FIPA (FIPA, del inglés Foundation for Intelligent Physical Agent) [109]. Los agentes JADE necesitan del entorno de ejecución donde poder vivir. Cada instancia del entorno de ejecución se denomina contenedor (container). Al conjunto de los contenedores se le denomina plataforma (platform) y proporciona una capa que oculta a los agentes y al desarrollador, el entorno donde se ha decidido ejecutar la aplicación. Entre sus principales funciones y ventajas tenemos [107]: • Ejecución distribuida. • Interfaz gráfica para monitorización y depuración de agentes, incluyendo los que se encuentran en hosts remotos. • Creación de agentes móviles. • Ejecución de actividades en paralelo. • Intercambio de mensajes ACL (ACL, del inglés Agent Communications Language) entre agentes. • Registro automático de agentes (vía AMS). • Servicio de nombres. En cada plataforma debe existir un contenedor especial denominado contenedor principal (main container). La principal diferencia del contenedor principal respecto al resto de contenedores es que alberga dos agentes especiales: • AMS proporciona el servicio de nombres asegurando que cada agente en la plataforma disponga de un nombre único. También representa la autoridad, es posible crear y matar agentes en contenedores remotos requiriéndoselo al agente AMS [110]. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 66 • Directory Facilitator (DF), proporciona el servicio de páginas amarillas. Gracias al agente DF, un agente puede encontrar otros agentes que provean los servicios necesarios para lograr sus objetivos [109]. Los agentes JADE tienen nombres únicos y se permite a cada agente descubrir a otros agentes y comunicarse con ellos mediante comunicaciones punto a punto. Los agentes proporcionan servicios, cada agente puede buscar a otros dependiendo de los servicios que proporcionen otros agentes. La estructura de los mensajes se basa en el lenguaje ACL [110] que ha sido definido por la FIPA. Se ha escogido JADE como la herramienta de desarrollo, ya que cumple con las especificaciones FIPA y soporta la mayor parte de la infraestructura establecida como: protocolos de comunicación, codificación de mensajes y servicio de páginas amarillas. La comunicación entre agentes se lleva a cabo a través de mensajes asíncronos, es decir, el agente que envía el mensaje y el destinatario del mensaje no tienen por qué estar disponibles al mismo tiempo. Es más, el destinatario no tiene porqué existir en ese instante. Los mensajes se pueden enviar a un agente en concreto o se pueden enviar a agentes que se desconocen pero se sabe que poseen unas ciertas características. La comunicación entre agentes es fundamental para poder conseguir la potencia propia de los sistemas multiagente. Para que los agentes se puedan comunicar deben usar el mismo lenguaje de comunicación. ACL permite transmitir una serie de conocimiento que viene expresado en un lenguaje de contenido. Toda la comunicación está basada en el intercambio de mensajes. La plataforma JADE que alberga al agente se encarga de hacerle llegar los mensajes a la plataforma del agente destinatario. La codificación decodificación de mensajes la hacen automáticamente los agentes. JADE-LEAP Los agentes escritos en JADE pueden ejecutarse en entornos móviles como teléfonos o asistentes digitales personales (PDA, del inglés Personal Digital Assistant) integrando las Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 67 redes inalámbricas junto con las redes convencionales. El problema es que JADE no puede correr en pequeños dispositivos debido a diversas razones: • Espacio: la memoria necesaria para el entorno de ejecución es de varios megas. • Versión del JDK: JADE necesita el JDK 1.4 o posterior, mientras que la mayoría de los dispositivos solo soportan Personal Java (PJava). • Características propias de las redes inalámbricas: IP dinámicas, conectividad intermitente o bajo ancho de banda, hace que JADE no sea lo apropiado [10]. Para ello surge LEAP que permite ejecutar agentes JADE en dispositivos inalámbricos y/o conectados a través de redes inalámbricas [10] [111]. Los container del entorno de ejecución de JADE-LEAP se dividen en dos partes, un FrontEnd, que se ejecuta en el dispositivo móvil, y un BackEnd que se ejecuta en un servidor de la red fija [111]. 2.4. Trabajos relacionados y estado del arte Se han utilizado proxies para adaptar la velocidad de transmisión, teniendo en cuenta el estado del canal inalámbrico, en [112] se presenta una técnica de distribución de video que gestiona de forma inteligente el uso del ancho de banda y la capacidad de almacenamiento disponible en los servidores proxy, a través de la pre captura de una determinada cantidad de datos de video y almacenarlos a priori en los servidores proxy. El servidor proxy se utiliza para superar las restricciones al recuperar flujos multimedia a través de WAN, al reducir el requisito de ancho de banda del backbone. Otros trabajos utilizan los proxies para solventar el problema de pérdida de paquetes al transmitir video streaming basados en los recursos previamente almacenados: en [65] se propone una técnica de almacenamiento en cache para mitigar los efectos de la latencia, perdida de paquetes y demoras, que despliega proxies multimedia a lo largo del camino del servidor al cliente. En esta técnica un servidor proxy almacena los flujos iniciales de un video largo; cuando en el futuro el cliente solicita el Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 68 flujo, el servidor proxy envía los flujos iniciales, además se conecta con el servidor del video y pide la retransmisión de los flujos posteriores. Se enfoca en garantizar la calidad del servicio al reducir el retraso y controlar los límites de rendimiento así como mejorar la continuidad del video streaming frente a un retraso o pérdida de paquetes en la red. Una arquitectura de distribución de video asistida por un proxy, que reduce los requisitos exigidos al servidor y mejora la experiencia en el cliente se indica en [64]. Se desarrolla para ello, dos técnicas de video streaming asistidas por el proxy: captura asistida por el proxy y captura selectiva asistida por el proxy, las cuales proveen servicio instantáneo a un gran número de clientes. Esto incrementa la funcionalidad de la propuesta al implantar técnicas de selección de videos populares y asignación inteligente de recursos entre el servidor proxy y el servidor central. Para proporcionar un servicio de tolerancia a interrupciones a los dispositivos inalámbricos, propone [113] el uso de un middleware en ambientes móviles basados en la intensidad de la señal de la red, Signal Strength (SS), aplicando un esquema de memorización intermedia (buffering) desarrollado en Java y aplicado a dispositivos inalámbricos Android. Una manera de localizar zonas de interrupción propone [114] mediante un sistema para construir una base de datos basada en RSSI, que permite ubicar zonas de interrupción en locales interiores mediante la comparación de los valores RSSI medidos con los valores que se encuentran en la base de datos. Los valores que constituyen la base de datos son previamente tomados mediante un dispositivo LiDAR (LiDAR, del inglés Laser Imaging Detection and Ranging) y un receptor WiFi. Para reducir la tasa de distorsión del video streaming [115], utiliza un proxy intermediario entre el servidor y el cliente, éste se encuentra localizado en el último salto de la red hacia el cliente, el cual coordina la comunicación usando un emisor de video streaming híbrido en un framework de optimización, dicho framework permite al proxy determinar que paquetes deben ser enviados desde el servidor de medios o retransmitidos directamente desde el proxy. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 69 Un middleware de agente móvil que maneja el aprovisionamiento del contenido multimedia a los dispositivos clientes en redes inalámbricas plantea [116], esta solución se enfoca en predecir la movilidad del cliente entre áreas de cobertura, permitiendo la migración de los sistemas multiagente de forma personalizada, mediante la adaptación de los contenidos multimedia de acuerdo a los perfiles y preferencias de los usuarios y la anticipación de sus movimientos. Esta solución de predicción se caracteriza por ser ligera y descentralizada explotando la información obtenida del monitoreo del cliente acerca de la intensidad de la señal recibida de las estaciones base IEEE 802.11; las sesiones personalizadas de readecuación proactiva permiten mantener la continuidad del servicio. Una alternativa de uso de los proxies como agentes de software de una plataforma propietaria para resolver las interrupciones se indica en [117], mantiene la continuidad del servicio de video streaming, cuando el cliente se mueve de una localidad inalámbrica a otra en tiempo de ejecución, generando un proceso de itinerancia. Para ello es importante la predicción de la entrega que permite migrar los proxies del móvil hacia redes inalámbricas donde el cliente móvil se reconectará y mediante el uso de un esquema de buffer proactivo y adaptativo se precargan los contenidos de multimedia. Un esquema de localización colaborativo basada en los valores RSSI y filtrando aquellos que son afectados notablemente por las condiciones del entorno describe [118], para obtener una mejor aproximación de la localización de los dispositivos mediante el algoritmo del camino más corto y ubicar aquellos que tengan el mejor RSSI para compartir información de zonas de cobertura. Para distribuir video bajo demanda [119], presenta un middleware basado en agentes, estos agentes se comportan como proxies, capaces de negociar el nivel de calidad y el flujo de flujos dependiendo de los perfiles y características del dispositivo y de las preferencias de usuario. Los componentes de esta propuesta pueden operar de forma autónoma para responder a los requisitos incluso en caso de la interrupción temporal del dispositivo. Un sistema que permite la localización en interiores basada en WiFi, utilizando herramientas para visualización 3D como Google Earth, archivos KML e integrándolas en Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 70 un entorno Web se presenta en [120] para despliegue de las zonas de cobertura de los interiores. Un mecanismo de sincronización multimedia, que reproduce los flujos en un entorno móvil de manera controlada y suave presenta [121], basa su mecanismo en un método de almacenamiento en buffer y un control efectivo de la reproducción del flujo, minimizando así el efecto de las característica de la red inalámbrica. Para implementar este entorno utilizan el concepto de proxy que negocia cómo van los flujos desde el buffer del servidor hacia los usuarios móviles. Este método propuesto mantiene la reproducción continua de los flujos y mantiene una presentación multimedia natural mediante el ajuste de la duración de la trama en pantalla. Se plantea una solución middleware basada en proxies móviles que funcionan en los bordes de la red inalámbrica alámbrica [122], apoyando a los servicios continuos, sobre todo por los contenidos multimedia en la búsqueda de evitar interrupciones de streaming. Este mecanismo intenta explotar la migración de los proxies móviles con antelación a las celdas inalámbricas donde los clientes móviles van a volver a conectarse. Una estrategia de buferización en dos niveles es planteada por [123], para mantener la continuidad del servicio de video streaming independiente de la movilidad del cliente para dispositivos inalámbricos. El diseño de Persistent Connectivity Management Protocol (PCMP) para el proyecto Drive-thru se presenta en [124], el cual consta de un cliente y un proxy, para gestión de las pérdidas de paquetes debido a errores de bits en redes inalámbricas, lo que produce un impacto en el rendimiento de TCP. El PCMP se encarga de mantener únicamente las sesiones TCP dentro de la red inalámbrica que pasen a través del proxy. Se discute en [125] por el desarrollo de un software multiagente para sistemas P2P video streaming de video basado en agentes. Presentan un agente software que mejorar la continuidad en sistemas de video streaming P2P, viendo el usuario en mejor calidad y menor retraso de extremo a extremo. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 71 Otra solución tolerante a interrupciones y retrasos para compartir archivos mediante P2P en una MANET (MANET, del inglés Mobile Ad Hoc Networks) se plantea en [126]. Se implementa un modelo de comunicación asíncrona en el cual nodos en la red pueden delegar tareas a otros nodos y esperar por su respuesta, mejorando así el rendimiento en la transmisión de datos. Una propuesta para reducir las interrupciones que se originan cuando un dispositivo móvil cambia de un medio inalámbrico a otro se indica en [127]. Enfocándose en el caso de cambiar desde un medio unicast a uno broadcast. Su solución propuesta reduce las interrupciones priorizando los paquetes de entrada justo antes de cambiar a broadcast. Se plantean una solución de buferización en [128], para brindar la posibilidad de monitorear remotamente la actividad cardiaca de deportistas durante una carrera utilizando estaciones base ubicada a lo largo del camino. Los sensores transmiten los datos a la estación base; cuando se pierde la conexión, los datos son almacenados localmente en cache esperando tener nuevamente una conexión para enviarlos. Existen trabajos, desarrollados por los integrantes de nuestro grupo de investigación, quienes presentan propuestas que posibilitan la continuidad del video streaming cuando ocurra una interrupción, estos los analizamos a continuación: Se propone un nuevo protocolo ligero y de administración del buffer, para soportar eficientemente las interrupciones y recuperar automáticamente la sesión de video streaming en [129]. Se implementa a través de un cliente proxy en un dispositivo móvil y un servidor proxy para el control de las interrupciones. En caso de presentarse interrupciones el usuario es notificado y se le solicita que se mueva a un área de mejor cobertura, pero carece de reconexión automática ante las interrupciones. Un software desarrollado con la técnica cross-layer, que no solo censa la congestión en redes WiFi, sino también el nivel de cobertura, la tasa de paquetes recibidos y perdidos para mejorar la QoS en aplicaciones de VoD (VoD, del inglés Video on Demand) con formato MPEG4 usando los protocolos RTSP/RTP se presenta en [130]. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 72 Otro mecanismo de control basado en la gestión de sesiones y de buffers proactivos de datos multimedia se presenta en [131], este utiliza agentes de software de la plataforma JADE-LEAP para gestionar las interrupciones presentadas en redes inalámbricas. Una arquitectura basada en proxies y agentes inteligentes para dispositivos inalámbricos Android se indica en [132]. Permite restablecer automáticamente la sesión de video streaming, sin pérdida de información, generada por interrupciones en ambientes inalámbricos, pero se limita a un sistema operativo y disponer de la aplicación en cada dispositivo inalámbrico. Un protocolo basado en la arquitectura de proxies es planteado en [133]. Este implementa la técnica de gestión de buffer para controlar interrupciones en la comunicación inalámbrica multimedia y recuperar la sesión de video streaming de forma automática, este mecanismo se aplicó a dispositivos inalámbricos. Finalmente se propuso un mecanismo de control basado en a la gestión de buffers proactivos de datos multimedia manejados por agentes JADE LEAP en [134], Este se encargan de resolver la interrupción intermitentes WiFi y lograr la reanudación automática de las sesiones RTSP en dispositivos inalámbricos, limitados a la gama de celulares Nokia. Analizados los trabajos, se puede concluir que han trabajado sobre plataformas específicas por la arquitectura heterogénea que presentan los teléfonos inteligentes, lo que genera implantar soluciones únicas y no generales. El uso de websockets no es posible porque éstos no manejan conexiones de datos usando RTP, solo comandos de control mediante el protocolo TCP. Los agentes inteligentes desarrollados solo establecen una comunicación sencilla entre ellos mediante el protocolo MTP. Ninguno ha realizado un modelo basado en patrones software de diseño que permita generalizar el problema de servicio video streaming. Hasta donde alcanza nuestro conocimiento, nunca antes habían planteado modelos basados en patrones software de diseño para controlar interrupciones en servicios de video streaming y videoconferencia. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 79 Reglas de negocio Dentro del contexto de aplicaciones empresariales, existe el concepto de regla de negocio. Estas reglas son definidas por las directivas de la organización y pueden ser condiciones o parámetros de los diferentes servicios que ésta presta [140]. Algunos ejemplos son: • El precio de un minuto de telefonía celular, según el plan al que pertenezca el usuario. • Las condiciones para aceptar o rechazar una solicitud de crédito. • Los parámetros para realizar descuentos por compra de productos en combo. • Las condiciones para admitir a un estudiante en una Universidad. Las reglas evolucionan a lo largo del ciclo de vida de la organización debido a su estrecha dependencia de los motivadores de negocio que puede tener una organización y las fuerzas externas. Por tal razón, el tiempo de respuesta ante dicha evolución debe ser el mínimo posible al igual que el impacto económico ante un cambio en un motivador o en una fuerza externa. Es así como la decisión de mantener dentro del código de una o varias aplicaciones de la empresa las reglas de negocio, tiene gran impacto en especial económico. Específicamente debido a la cantidad de cambios que se puedan requerir, para ajustar el código en las aplicaciones en el momento en que apremia satisfacer una necesidad de negocio basada en una nueva regla o en el cambio de una de éstas. Los motores de reglas de negocio o BRMS (BRMS, del inglés Business Rule Management System) surgen como una alternativa de solución a la problemática de administrar el cambio de las reglas de negocio en una organización, en nuestro caso con agentes de software [9]. En particular los BRMS ofrecen: • Un repositorio común a las aplicaciones donde se guardan las reglas de negocio versionadas. • Herramientas que permiten definir estas reglas tanto a usuarios técnicos (desarrolladores) como a usuarios no técnicos (directivos, expertos de negocio). Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 80 • Independencia entre el lenguaje de programación de una aplicación y el lenguaje para expresar las reglas. • Facilidad para definir las reglas de negocio, por categorías, en un lenguaje de alto nivel propio del motor de reglas. • Un mecanismo de despliegue de las reglas de negocio. Lenguaje de marcado basado en XML para representación de datos geográficos en 3D Un archivo en formato KML [141] contiene coordenadas, direcciones, altura, entre otras variables que permiten representar en un mapa, una ruta o punto de interés, en otras palabras, es el lenguaje de marcado basado en XML (XML, del inglés eXtensible Markup Language) para representar datos geográficos en tres dimensiones [142]. Es reconocido como un estándar en el Open Geospatial Consortium [143]. Un archivo KML especifica una característica (un lugar, una imagen, una posición, una ruta o un polígono), que contienen coordenadas (latitud y longitud), que en muchas ocasiones puede venir comprimido en un archivo KMZ (KMZ, del inglés Keyhole Markup Language Zip) [144]. Un archivo KML tiene la siguiente estructura: 1. Cabecera del XML: <?xml version="1.0" encoding="UTF-8"?> 2. Espacio de nombres o Namespace propio de KML: <kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2" xmlns:kml="http://www.opengis.net/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom"> 3. El objeto Placemark que hace referencia a la posición, dividido en nombre, descripción y conjunto de coordenadas que conforman el camino: <Placemark> <name>Ruta de Prueba</name> <styleUrl>#m_ylw-pushpin</styleUrl> <LineString> Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 81 <tessellate>1</tessellate> <coordinates> -78.45876922394318,-0.2907473038582219,0 -78.45962845232083,- 0.2910824364469906,0 -78.45926872660962,-0.2918885432418332,0 78.45885131304623,-0.2924142379706846,0 -78.45776061343645,- 0.2945232380020063,0 -78.45716919796966,-0.2955813292945207,0 78.45587564927628,-0.297815041302652,0 -78.45679124311162,- 0.2983939244213915,0 -78.45828346321,-0.2991575516721163,0 </coordinates> </LineString> </Placemark> Un archivo KML para dispositivos inalámbricos permite los siguientes elementos: • Marcas de posición con elementos de nombre <name>. • Puntos, íconos, carpetas. • Elementos HTML. • KMZ (KML comprimido que incluye imágenes adjuntas). • Cadenas de línea y polígonos. • Aspectos como el color, el relleno y la opacidad. Para crear un archivo KML se puede recurrir desde un editor de texto plano, como un programa especializado de coordenadas que nos genere este archivo, como se presenta en la Figura 2.14. Figura 2.14: Archivo KML generado desde Google Earth Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 82 Los archivos KML sirven para la creación de modelos y el almacenamiento de coordenadas geográficas como puntos, rutas, imágenes, polígonos, entre otros; las cuales se pueden compartir o utilizar para referenciar un lugar o información específica con otros usuarios. HTML5 HyperText Markup Language 5 (HTML5) ) [145] corresponde a la quinta revisión del lenguaje básico de la Web. Establece nuevos elementos y atributos, introduce elementos multimedia como la etiqueta <video> y <audio> que permiten el despliegue en navegador mediante interfaces estándar. La comunicación, se implementa mediante el uso de API (API, del inglés Application Programming Interface) WebSocket que permiten una comunicación bidireccional entre el servidor y el navegador Web. La etiqueta <video> permite reproducir archivos de vídeo en la página Web sin necesidad de usar plugins o el uso de herramientas de terceros como Flash. La personalización del reproductor se lo realiza mediante el uso de hojas de estilo CSS (CSS, del inglés Cascading Style Sheets) y JavaScript, entregando una apariencia única al reproductor. Entre los formatos aceptados por HTML5 para la etiqueta de video tenemos: H.264 [48], conocido también como MPEG-4 parte 10; OGM (OGM, del inglés Ogg Media) [146] que utiliza como CODEC de vídeo a Theora y de audio a Vorbis; WebM [66], que soporta para audio el CODEC Vorbis, y para video el CODEC VP8. Tabla 2.2: CODEC de audio y video soportados por navegadores Web FORMATO CHROME FIREFOX INTERNET EXPLORER OPERA SAFARI WebM (VP8+Vorbis) SI SI NO SI NO OGG (Theora+Vorbis) SI SI NO SI NO MP4 (H.264+MP3) SI NO SI NO SI MP4 (H.264+AAC) SI NO SI NO SI Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 83 En la Tabla 2.2 se muestra una lista de los CODEC de audio y video soportados por los navegadores más populares, donde se observa que al menos un formato de audio y vídeo es compatible para HTML5 Uno de los aportes importantes de HTML5 es el uso del protocolo WebSocket que establece un canal de comunicación bidireccional entre el navegador Web y el servidor sobre una única conexión TCP [147]. Está diseñado para funcionar sobre los puertos 80 y 443, además sobre proxies HTTP y no limita el uso de HTTP en Websocket. Permite mantener conexiones persistentes entre el navegador y el servidor para un intercambio de información independiente del tiempo [148]. Los navegadores en dispositivos inalámbricos que soportan el estándar HTML5 son Chrome, Firefox y Opera [146]. En conclusión HTML5 se caracteriza por presentar cambios significativos en tres aspectos: estructura, nuevos elementos y funcionalidad [145], [149]. Dynamic Adaptive Video streaming over HTTP Dynamic Adaptive Streaming over HTTP (DASH) es una solución desarrollada por MPEG y publicada como ISO/IEC 23009-1; 2012 [150]. Presenta algunas ventajas indicadas en [150–153] y que las podemos resumir: • Permite el uso de conexiones HTTP/TCP para reutilizar la infraestructura de red existente. • Brinda disponibilidad de recursos a gran escala de los servidores basados en RTP. • Mejora la QoE mediante la entrega de servicios video streaming adaptativos [154]. En la Figura 2.15 se observa el escenario donde el cliente provee al sistema de cierto grado de adaptación requiriendo los segmentos que más se adecúen al ancho de banda disponible [155]. Estos segmentos se codifican en múltiples versiones, cada uno con diferentes parámetros de codificación, por lo tanto se dispone de múltiples niveles de Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 84 calidad con el mismo contenido multimedia. El cliente puede solicitar estos segmentos para su despliegue mediante la URL asignada a cada uno. DASH principalmente define dos formatos: • Media Presentation Description (MPD) [156]: que es un archivo de metadatos que describe el contenido disponible y algunas otras características. • Formato de los segmentos. El cliente de DASH debe seguir el siguiente proceso para reproducir el contenido multimedia [152]: • Obtiene el archivo MPD mediante HTTP, correo electrónico u otro tipo de transporte. • Extraer la información necesaria para la reproducción. • Obtenida la información, selecciona las características adecuadas y empieza a realizar la transmisión multimedia mediante peticiones HTTP de los segmentos que cumplen con las características seleccionadas. MPD es un documento XML con el que un cliente DASH obtiene los metadatos necesarios para acceder a los segmentos y proporcionar un servicio de streaming al usuario. La estructura jerárquica de MPD, conformada por: • Period: determina el intervalo temporal del contenido multimedia y puede contener uno o varios adaptation sets. • Adaptation set: proporciona información de las diferentes versiones de codificación de los contenidos (bitrate), lo que implica tener diferentes representations. • Representation: es la codificación a ser entregada y puede tener uno o varios segments. • Segment: son cada uno de las partes en las que se encuentra dividido los contenidos y contienen su propia URL para que el cliente puede descargarse mediante peticiones GET HTTP. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 85 Figura 2.15: Escenario de adaptación DASH Un sistema de distribución multimedia, cuya arquitectura básica está basada en la tecnología DASH, dispone de un servidor HTTP y un cliente. Se puede añadir elementos intermedios como: cache HTTP y proxy, con el propósito de mejorar la eficiencia del servicio. La descripción de cada elemento, la presentamos a continuación: • Servidor HTTP: se encarga de almacenar archivos MPD asociados con la descripción de los medios y los contenidos codificados siguiendo el estándar DASH. Es un servidor HTTP convencional. • Caché HTTP: es un espacio de almacenamiento para peticiones y respuestas HTTP. Si llega una petición HTTP similar a las almacenadas, envía la respuesta sin tener que consultar al servidor. • Cliente: se encarga de pedir y reproducir los contenidos al servidor Web mediante peticiones GET estándar. El control y la lógica de adaptación al ancho de banda disponible reside en el lado del cliente, dando solución a problemas de escalabilidad en el lado del servidor. Es importante indicar que el estándar DASH solo describe a MPD y el formato de los segmentos. La forma en la que se realiza el envío de MPD, la codificación de los medios y el comportamiento del cliente sobre el proceso de estimación del ancho de banda y las decisiones acerca de la solicitud de los segmentos para llevar a cabo la adaptación de los contenidos no se encuentran definidos en el estándar DASH [152]. La fortaleza de la tecnología DASH está en el uso de protocolos ampliamente manejados para el intercambio de información en Internet, que no eran considerados Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 86 factibles para efectuar una transmisión de contenido multimedia. El uso de DASH permite la utilización de este tipo de protocolos, en escenarios video streaming, proveyendo de cierto grado de adaptación en función de las capacidades del cliente y del estado de la red. El video streaming adaptativo sobre HTTP esté siendo gradualmente adoptado por los proveedores de contenidos y servicios en la red, gracias a las ventajas brindadas en términos de uso de recursos y calidad percibida por el usuario. WebRTC WebRTC (WebRTC, del inglés Web Real-Time Communications) es un proyecto de software libre mantenido por Google, Mozilla y Opera y es parte de la propuesta HTML5. Se encuentra definida entre el World Wide Web Consortium (W3C) y el Internet Engineering Task Force (IETF) y permite habilitar las capacidades Real Time Communication (RTC) entre navegadores de internet usando simplemente API JavaScript, proporcionando audio, video y datos P2P (P2P, del inglés Peer-to-Peer)[157] sin necesidad de plugins [158]. En el experimento realizado en el capítulo 5 se lo utilizó por su característica de ser gratuito y de código abierto. WebRTC implementa las Web API siguientes [87]: • MediaStream: permite acceder a los flujos de media del equipo, tales como cámara, micrófono u otro dispositivo de captura. Esta petición se realiza a través de la función getUserMedia. • RTCPeerConnection: establece la conexión entre pares (navegador a navegador), para transmitir la información. • RTCDataChannel: permite la comunicación de otros tipos de datos en tiempo real, tales como chat de texto, transferencia de archivos… WebRTC no implementa la gestión de sesiones o también llamada señalización abstracta, lo deja a JSEP (JSEP, del inglés Java Session Establishment Protocol) [159], quien se encarga de controlar el mecanismo de señalización a través de JavaScript, este Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 87 mecanismo elimina casi por completo al navegador del núcleo de flujo de señalización, la única interfaz que necesita es que la aplicación envié las descripciones de sesión e interactúe con ICE (ICE, del inglés Interactive Connection Establishment) [160]. Como protocolos de transporte WebRTC utiliza a UDP para la transmisión de audio y video en tiempo real; SRTP (SRTP, del inglés Secure Real-Time Transport Protocol) para proveer seguridad y protección al transporte de recursos RTP; RTCP para supervisar las estadísticas de transmisión de flujos de datos. Para dar solución al NAT (NAT, del inglés Network Address Translation) [161], WebRTC presenta tres soluciones: STUN (STUN, del inglés Session Traversal Utilities for NAT) [162] protocolo de red tipo cliente-servidor utilizado por clientes NAT para encontrar su dirección IP pública; TURN (TURN, del inglés Traversal Using Relay NAT) [163] extensión del protocolo STUN, utilizado para retransmitir video o datos en una comunicación punto a punto; ICE se lo considera como un marco que define el uso de los protocolos STUN y TURN para poder atravesar NAT, mediante el tratamiento de distintas rutas para establecer la comunicación entre dos usuarios, sin la necesidad de emplear otros servicios [87]. WebRTC soporta diversos CODEC para audio y video, los más utilizados son OPUS y VP8 respectivamente; destacan por su bajo consumo de ancho de banda, baja latencia y soporte de hardware de cliente heterogéneo y fueron utilizados en el experimento porque son gratuitos y de código abierto [87]. WebRTC dispone de un agente que permite extraer métricas de comunicación en una aplicación web, para obtener estas estadísticas se han definido una serie de API JavaScript que permiten obtener información estadística acerca de una comunicación [164]. 2.5.3. Esquema básico cliente servidor de video streaming con patrones Se utiliza el modelo de caso de usos para describir la funcionalidad del servicio de video streaming. En la Figura 2.16 y tabla 2.3-2.4 se muestra la relación entre los actores y los casos de en este servicio Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 88 Figura 2.16: Casos de uso servicio video streaming Tabla 2.3: Casos de uso servicio video streaming – solicitar video Caso de uso: solicitar video Actores: cliente, servidor video streaming Resumen: describe como inicia la petición del video Precondiciones: Descripción: 1. El cliente solicita la visualización del video. 2. Ingresa los datos del protocolo, IP del servidor, puerto y video. 3. Recibe parámetros de sesión Pos condiciones: Observaciones: Tabla 2.4: Casos de uso servicio video streaming - enviar video Caso de uso: enviar video Actores: servidor video streaming, cliente Resumen: describe como realiza la entrega del video al cliente Precondiciones: Descripción: 1. En función de los datos con que solicito video toma la información de: 1.1 Librería de videos. 1.2 Dispositivo de captura de video. 2. Envía al cliente el video en flujos. 3. Cliente recibe flujo y lo despliega. Pos condiciones: Observaciones: El primer caso de uso del servicio video streaming describe como inicia la petición de video, explicado en la Tabla 2.3. El segundo caso de uso del servicio video streaming describe como se realiza la entrega del video al cliente, explicado en la Tabla 2.4. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 95   =  −  2 De esta manera puedo obtener el tiempo de cada uno de los T DATO último, de cada flujo generado por una interrupción y que conforman el T FLUJOn . Es importante observar que en este escenario solo el último T DATO del último flujo transmitido no presenta retransmisión en todo el escenario analizado. Como las interrupciones se presentaron cercanas a la inicialización del video streaming, se concluye en primera instancia que se trata de un escenario que presenta un bajo aporte de tiempo de retransmisión de T DATO acumulado en todo el tiempo de ejecución del escenario. Este análisis aplica para cualquier escenario que se presente. Es necesario ordenarlos, en este caso ascendentemente, y así nos ajustamos a la Figura 2.21 de peor escenario, con lo cual podemos utilizar la fórmula descrita para calcular el tiempo de cada T DATO último de cada flujo generado por una interrupción. A continuación se explica el detalle de la obtención de la ecuación del tiempo total de ejecución del video en este modelo. Si analizamos las Figuras 2.21 y 2.22 tenemos que el T EJECUCION está determinado por la siguiente ecuación:   ! = !  "#$%& + !  "#$%&( + !  "#$%&) +⋯+ !  "#$%& +++1×  ++× . ++−1× / +⋯+2 ×  +  + !001 ! + !001 !. + !001 !/ +⋯++ !001 ! Donde: T INICIOFLUJO es el tiempo de establecimiento de la sesión de video streaming. T DATO es el tiempo de transmisión de datos en el flujo. T INTERRUPCIÓN es el tiempo de duración de la interrupción. n es el número de interrupciones. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 96 Asumiendo que el servicio de video streaming presenta iguales tiempos de establecimiento en todos los casos, entonces el T INICIOFLUJO presentan el mismo tiempo de duración, por lo que:  !  "#$%& = !  "#$%&( = !  "#$%&) =⋯= !  "#$%& = !  "#$%& Entonces:   ! =++1× !  "#$%& +++1×  ++× . ++−1 × / +⋯+2×  +  + !001 ! + !001 !. + !001 !/ +⋯++ !001 ! Luego si agrupamos los T DATO transmitidos más de una vez, agrupamos las T INTERRUPCION presentadas y separamos el T DATOn transmitido una sola vez, tenemos:   ! =++1× !  "#$%& +2++1×  ++× . ++−1× / +⋯+2 ×  3 + !001 ! + !001 !. + !001 !/ +⋯ + !001 ! +  Ahora si aplicamos sumatorio tenemos la ecuación que determina el T EJECUCION del modelo de servicio video streaming, nuestra ecuación 3:   ! =++1× !  "#$%& +456+1× 78 9  :; +4 !001 !8  :; +  3 Donde: ++1× !  "#$%& es el tiempo total de inicio de los flujos transmitidos por n interrupciones. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 97 ∑56+1× 78 9  :; es el tiempo total de T DATO transmitidos más de una vez. ∑ !001 !8  :; es el tiempo total de interrupciones.   es el tiempo del dato transmitido una sola vez. Si analizamos las ecuaciones (1) y (2) podemos concluir que: • En la ecuación (1) el número de tramas no retransmitidas será siempre mucho menor en el peor escenario, debido a que las interrupciones ocurren cuando el usuario ha visto la mayor cantidad del video. • En la ecuación (2) el número de tramas no retransmitidas será siempre mucho mayor en el mejor escenario, debido a que las interrupciones ocurren cuando el usuario se encuentra en los inicios del video. Con la finalidad de evaluar el modelo matemático es necesario ponderar el peso que tiene el retransmitir un flujo en base al número de interrupciones dadas. Se plantean las siguientes consideraciones: • Capacidad de canal constante. • No existen retransmisiones por causas de pérdida de datos en el canal. Ahora determinaremos la ecuación que permita calcular la cantidad de bits transmitidos en cada T DATOi : >ú @ A6 +66@ =  8 ×BCD6@@ @ B+E Si consideramos un canal ADSL con acceso mediante WiFi que tiene una capacidad del canal de 10 Mbps y si T DATO1 tuvo un tiempo de ejecución de 17,96 segundos tenemos que el número de bits que se transmitieron sería de: >ú @ A6 +66@ = 17,96×10=179,6 KA6 =22,45 KN Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 98 Analicemos un ambiente en el que tenemos tres interrupciones, los tiempos de cada uno de los T FLUJO generados por las interrupciones son: de 27, 13, 3 y 31 medidos en segundos y la capacidad del canal es 10 Mbps. Si aplicamos el método descrito para evaluar el mejor o peor escenario, tenemos los resultados que se indican en las tablas 2.5-2.6. Tabla 2.5: Flujos ubicados y ordenados para escenario en (s) Tflujo3 Tflujo2 Tflujo1 Tflujo4 Número retransmisiones flujos Tdato1 (s) 3 3 3 3 3 Tdato2 (s) 10 10 10 2 Tdato3 (s) 14 14 1 Tdato4 (s) 4 0 Tflujo (s) 3 13 27 31 Cantidad de datos (MB) 3,75 16,25 33,75 38,75 Tabla 2.6: Flujos escenario en (MB) Tflujo3 Tflujo2 Tflujo1 Tflujo4 Número retransmisiones flujo Tdato1 (MB) 3,75 3,75 3,75 3,75 3 Tdato2 (MB) 15,625 15,625 15,625 2 Tdato3 (MB) 17,5 17,5 1 Tdato4 (MB) 5 0 Tflujo (MB) 3,75 16,25 33,75 38,75 Capacidad canal (Mbps) 10 10 10 10 Tabla 2.7: Total de bytes transmitidos y retransmitidos por flujo Flujo Tflujo (s) Tflujo (MB) Datos retransmitidos (MB) Número retransmisiones Total datos retransmitidos (MB) 1 27 33,75 20 1 20 2 13 16,25 7,5 2 15 3 3 3,75 3,75 3 11,25 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 99 Ahora calculemos el total de bytes trasmitidos en cada flujo e igual lo hacemos para los retransmitidos, los resultados se exponen en la tabla 2.7. Ahora calculemos los totales del flujo completo de este escenario, descritos en la tabla 2.8. De los resultados observamos que se ha retransmitido un total de datos de 53,75 MB y el total de datos de video es 38,75 MB, dejando un incremento de video transmitido de 138,71%. Se presentan la Figura 2.23 que permiten visualizar el número de retransmisiones que ha tenido el flujo y asociado el total de datos retransmitidos en (MB). La Figura 2.24 permite visualizar el total de datos del video versus el total de datos retransmitidos. Tabla 2.8: Total de bytes transmitidos y retransmitidos por video Total tiempo video (s) Total datos video (MB) Total datos retransmisiones (MB) Incremento (%) 31 38,75 53,75 138,71 Figura 2.23: Datos transmitidos vs retransmitidos por flujo NUMERO RETRANSMISIONES TOTAL DATOS RETRANSMITIDOS (MB) 0 10 20 123 123 20 15 11,25 FLUJOS DE DATOS NUMERO RETRANSMISIONES TOTAL DATOS RETRANSMITIDOS (MB) Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 100 Figura 2.24: Datos totales transmitidos vs retransmitidos Tabla 2.9: Flujos ubicados y ordenados para mejor escenario en (s) Tflujo2 (s) Tflujo1 (s) Tflujo3 (s) Tflujo4 (s) Número retransmisiones flujos Tdato1 (s) 13,96 13,96 13,96 13,96 3 Tdato2 (s) 4 4 4 2 Tdato3 (s) 11,3 11,3 1 Tdato4 (s) 1383,74 0 Tflujo (s) 13,96 17,96 29,26 1413 Cantidad de datos (MB) 17,45 22,45 36,575 1766,25 Tabla 2.10: Flujos mejor escenario en (MB) Tflujo2 (s) Tflujo1 (s) Tflujo3 (s) Tflujo4 (s) Número retransmisiones flujo Tdato1 (MB) 17,45 17,45 17,45 17,45 3 Tdato2 (MB) 5 5 5 2 Tdato3 (MB) 14,125 14,125 1 Tdato4 (MB) 1729,675 0 Tflujo (MB) 17,45 22,45 36,575 1766,25 Capacidad canal (Mbps) 10 10 10 10 Ahora realizamos el mismo análisis para un caso experimental del mejor escenario cuyos datos son: 17.96, 13.96 y 29.26 medidos en segundos y el tiempo completo del video es 1413 segundos. Si aplicamos el método descrito para evaluar el mejor escenario, tenemos los resultados que se indican en las tablas 2.9-2.10. 38,75 53,75 DATOS TOTALES TRANSMITIDOS Total datos video (MB) Total datos retransmisiones (MB) Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 101 Ahora calculemos el total de bytes trasmitidos en cada flujo e igual lo hacemos para los retransmitidos, los resultados se exponen en la tabla 2.11. Ahora calculemos los totales del flujo completo de este escenario, descritos en la tabla 2.12. De los resultados observamos que se ha retransmitido un total de datos de 76,48 MB y el total de datos de video es 1766,25 MB, dejando un incremento de video transmitido de 4,33%. Se presenta la Figura 2.25 que permiten visualizar el número de retransmisiones que ha tenido el flujo y asociado el total de datos retransmitidos en (MB). La Figura 2.26 permite visualizar el total de datos del video versus el total de datos retransmitidos. Tabla 2.11: Total de bytes transmitidos y retransmitidos por flujo Flujo Tflujo (s) Tflujo (MB) Datos retransmitidos (MB) Número retransmisiones Total datos retransmitidos (MB) 1 29,26 36,575 39,9 1 39,9 2 17,96 22,45 34,9 2 69,8 3 13,96 17,45 17,45 3 52,35 Tabla 2.12: Total de bytes transmitidos y retransmitidos por video Total tiempo video (s) Total datos video (MB) Total datos retransmisiones (MB) Incremento (%) 1413 1766,25 76,48 4,33 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 102 Figura 2.25: Datos transmitidos vs retransmitidos por flujo Figura 2.26: Datos totales transmitidos vs retransmitidos Ahora realizamos el mismo análisis para un caso experimental del peor escenario cuyos datos son: 114.44, 123.48 y 157.61 medidos en segundos y el tiempo completo del video es 1413 segundos, tenemos los resultados que se indican en las tablas 2.132.14. NUMERO RETRANSMISIONES TOTAL DATOS RETRANSMITIDOS (MB) 0 20 40 60 80 123 123 39,9 69,8 52,35 FLUJOS DE DATOS NUMERO RETRANSMISIONES TOTAL DATOS RETRANSMITIDOS (MB) 1766,25 76,48 DATOS TOTALES TRANSMITIDOS Total datos video (MB) Total datos retransmisiones (MB) Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 103 Tabla 2.13: Flujos ubicados y ordenados para peor escenario en (s) Tflujo1 (s) Tflujo2 (s) Tflujo3 (s) Tflujo4 (s) Número retransmisiones flujos Tdato1 (s) 114,44 114,44 114,44 114,44 3 Tdato2 (s) 9,04 9,04 9,04 2 Tdato3 (s) 34,13 34,13 1 Tdato4 (s) 1255,39 0 Tflujo (s) 114,44 123,48 157,61 1413 Cantidad de datos (MB) 143,05 154,35 197,0125 1766,25 Tabla 2.14: Flujos peor escenario en (MB) Tflujo1 (s) Tflujo2 (s) Tflujo3 (s) Tflujo4 (s) Número retransmisiones flujo Tdato1 (MB) 143,05 143,05 143,05 143,05 3 Tdato2 (MB) 11,3 11,3 11,3 2 Tdato3 (MB) 42,6625 42,6625 1 Tdato4 (MB) 1569,2375 0 Tflujo (MB) 143,05 154,35 197,0125 1766,25 Capacidad canal (Mbps) 10 10 10 10 Tabla 2.15: Total de bytes transmitidos y retransmitidos por flujo Flujo Tflujo (s) Tflujo (MB) Datos retransmitidos (MB) Número retransmisiones Total datos retransmitidos (MB) 1 157,61 197,0125 297,4 1 297,4 2 123,48 154,35 286,1 2 572,2 3 114,44 143,05 143,05 3 429,15 Ahora calculemos el total de bytes trasmitidos en cada flujo e igual lo hacemos para los retransmitidos, los resultados se exponen en la tabla 2.15. Ahora calculemos los totales del flujo completo de este escenario, descritos en la tabla 2.16. De los resultados observamos que se ha retransmitido un total de datos de 494,41 MB y el total de datos de video es 1766,25 MB, dejando un incremento de video transmitido de 27,99%. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 104 Se presenta la Figura 2.27 que permiten visualizar el número de retransmisiones que ha tenido el flujo y asociado el total de datos retransmitidos en (MB). La Figura 2.28 permite visualizar el total de datos del video versus el total de datos retransmitidos. Tabla 2.16: Total de bytes transmitidos y retransmitidos por video Total tiempo video (s) Total datos video (MB) Total datos retransmisiones (MB) Incremento (%) 1413 1766,25 494,41 27,99 Figura 2.27: Datos transmitidos vs retransmitidos por flujo Figura 2.28: Datos totales transmitidos vs retransmitidos NUMERO RETRANSMISIONES TOTAL DATOS RETRANSMITIDOS (MB) 0 500 1000 1 2 3 12 3 297,4 572,2 429,15 FLUJOS DE DATOS NUMERO RETRANSMISIONES TOTAL DATOS RETRANSMITIDOS (MB) 1766,25 494,41 DATOS TOTALES TRANSMITIDOS Total datos video (MB) Total datos retransmisiones (MB) Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 111 3.1. Análisis del diseño basado en patrones software En el capítulo 2 se planteó el modelo del servicio video streaming mediante patrones software de diseño de software, concretamente patrón MVC. Posterior se realizó el modelamiento matemático que permitió demostrar que existe un impacto negativo en el servicio de video streaming, debido a la disrupción del canal de comunicación inalámbrico que provoca la interrupción del servicio. Este impacto negativo, en el lado de la red genera tráfico y congestión por la cantidad de retransmisiones de datos solicitadas, con la posibilidad de saturar la capacidad del canal. Con respecto al usuario, genera una negativa calidad de experiencia por las continuas interrupciones que ocasionan reinicios del servicio permanentemente, demoras en el restablecimiento de la sesión y visualización de repetitiva de flujos de datos; que pueden determinar en el usuario el abandono definitivo de la sesión video streaming. Nuestro interés es establecer un modelo basado en patrones software de diseño que permita controlar las interrupciones del servicio video streaming ocasionadas por quiebres del canal de comunicación inalámbrico. Permitiendo así mitigar o minimizar el tiempo de restablecimiento de la sesión video streaming, la retransmisión de flujos de datos y en consecuencia la no visualización repetitiva de estos flujos. Con esto se pretende validar que nuestro modelo reduce considerablemente el tiempo de establecimiento de la sesión, retransmisiones y en consecuencia el tiempo total de ejecución del servicio. Esto mejoraría notablemente la QoE del usuario debido a que el usuario va a tener menores tiempos de restablecimiento de la sesión y aportando continuidad al flujo de datos del video. Para conseguir esto, nuestro modelo incorpora funcionalidades que permiten controlar las interrupciones de la sesión por quiebres del canal y reconectar automáticamente, garantizando la continuidad del servicio video streaming. Esto permite además la continuidad de los flujos de datos del video mejorando la QoE al usuario. Para mantener flexibilidad de cambio, orden y reutilización en el modelo propuesto, se utilizó el patrón de diseño MVC. Se utiliza el modelo de caso de usos para Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 112 describir la funcionalidad del modelo base. En la Figura 3.1 y Tabla 3.1-3.6 se muestra la relación entre los actores y los casos de en este modelo. El primer caso de uso describe el inicio de petición de video y su despliegue en pantalla, explicado en la Tabla 3.1. El segundo caso de uso describe la importancia de monitorear el umbral de almacenamiento temporal, explicado en la Tabla 3.2. El tercer caso de uso describe el proceso a seguir para confirmar que se trata de una interrupción, se evalúa el estado del canal de comunicación, explicado en la Tabla 3.3. El cuarto caso de uso describe como dado un evento del canal de comunicación, debe gestionarse la continuidad del servicio de video streaming, explicado en la Tabla 3.4. El quinto caso de uso describe las actividades a cumplir cuando ocurre una interrupción y como se controla la misma, explicado en Tabla 3.5. El sexto caso de uso describe las actividades a cumplir cuando el canal de comunicación se ha restablecido, explicado en la Tabla 3.6. Figura 3.1: Casos de uso modelo base Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 113 Tabla 3.1: Casos de uso modelo base reproducir video Caso de Uso: reproducir video Actores: cliente Resumen: describe inicio petición de video y su despliegue. Precondiciones: Descripción: 1. El cliente solicita visualización del video. 2. Ingresa datos IP del servidor, puerto y video. 3. Los datos son validados por el Proxy. 4. Si no existen problemas el Proxy solicita el servicio al servidor video streaming. 5. Se despliega una ventana en la que inicia el video streaming. 6. El servidor inicia la entrega de flujos al almacenamiento temporal. Pos condiciones: solicita la revisión constante del almacenamiento. Observaciones: Tabla 3.2: Casos de uso modelo base solicitar revisión almacenamiento Caso de Uso: solicitar revisión almacenamiento Actores: Resumen: explica la importancia de monitorear umbral de almacenamiento temporal Precondiciones: el Proxy solicita la revisión del almacenamiento Descripción: 1. Se pide constantemente información del umbral del almacenamiento. 2. Se compara con el máximo nivel establecido. 3. Se genera una alerta en caso de superación del umbral definido. 4. Se comunica este problema al Proxy Pos condiciones: solicita la evaluación del canal de comunicación Observaciones: Tabla 3.3: Casos de uso modelo base evaluar estado de canal Caso de Uso: evaluar estado canal de comunicación Actores: Resumen: para confirmar que se trata de una interrupción, se evalúa el estado del canal de comunicación. Precondiciones: Proxy solicita evaluación del canal de comunicación Descripción: 1. Se evalúa el canal de comunicación. 2. Se determina el estado del canal de comunicación 3. Este estado es comunicado al Proxy. Pos condiciones: se solicita mantener la continuidad del servicio Observaciones: Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 114 Tabla 3.4: Casos de uso modelo base mantener continuidad del video Caso de Uso: mantener continuidad del video Actores: Resumen: dado un evento del canal de comunicación debe gestionarse la continuidad del servicio video streaming. Precondiciones: el proxy solicita ejecución de proceso de acuerdo al estado del canal de comunicación. Descripción: Alerta interrupción : 1. En caso de ser una alerta de interrupción se solicita la gestionar interrupción del servicio. Alerta conexión: 2. Cuando el canal se ha restablecido se solicita gestionar reconexión. Pos condiciones: Observaciones: Tabla 3.5: Casos de uso modelo base gestionar interrupción del servicio Caso de Uso: gestionar interrupción del servicio Actores: Resumen: explica las actividades a cumplir cuando ocurre una interrupción y como se controla la misma. Precondiciones: Descripción: 1. Se solicita el almacenamiento de los flujos en el buffer. 2. Se despliega en la interfaz gráfica del usuario el mensaje “Reconectando” por el problema dado y que se encuentra en estado de espera para reconectarse automáticamente 3. Se pide el servicio de evaluar continuamente el canal de comunicación. Pos condiciones: Observaciones: Tabla 3.6: Casos de uso modelo base gestionar reconexión Caso de Uso: gestionar reconexión Actores: Resumen: explica las actividades a cumplir cuando el canal se ha restablecido. Precondiciones: Descripción: 1. Se solicita que los flujos almacenados en el buffer sean transmitidos al dispositivo cliente. 2. El cliente automáticamente continúa visualizando el video en el punto en el que se encontraba cuando ocurrió la interrupción. Pos condiciones: Observaciones: Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 115 3.1.1. Justificación de los patrones software a utilizar El propósito de este diseño basado en patrones software probados es generar un modelo genérico que pueda ser implementado en cualquier escenario de experimentación. Esto se consigue gracias a la utilización del patrón MVC que permite un desarrollo modular, escalable, flexible y de fácil mantenimiento. Se fortalece este patrón con la implementación de algunos patrones software adicional que permiten entregar más funcionalidades. Los patrones software adicionados son: Composite, Observer, Strategy y Proxy. En la capa vista un patrón Composite para organizar estructuradamente su contexto y componentes y facilidad a cambios. En la capa modelo un patrón Observer que acompañe para determinar oportunamente los cambios de estado del almacenamiento temporal. En la capa controlador un patrón Strategy que permita determinar la acción a seguir notificados por el patrón Observer, y un patrón Proxy que es el orquestador e intermediario del mecanismo control de interrupción entre el servidor y el cliente. Figura 3.2: Modelo base para control de interrupciones Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 116 La Figura 3.2 indica cómo se encuentran ubicadas las funcionalidades del modelo base y el incremental que tiene para poder tener un mecanismo para control de interrupciones efectivo. De acuerdo a los casos de uso tenemos que los patrones software se han implementado de la siguiente manera: • Reproducir video: se ha realizado mediante el patrón Composite, permitiendo organizar estructuradamente su contexto y componentes y brindar facilidad a cambios. • Solicitar revisión almacenamiento: se ha implementado mediante el patrón Observer y se encarga de monitorear el umbral del almacenamiento temporal, notificando una alerta al Proxy cuando supera el límite establecido. • Evaluar estado canal de comunicación: entregada la alerta del Observer del almacenamiento temporal, se requiere validar si ésta es por quiebre del canal de comunicación. Esto se lo implementa ubicando un patrón Observer a nivel de la capa controlador que permita monitorear al canal y verificar si existe una interrupción, solicitado por Proxy. Mantener continuidad del video: este caso de uso engloba a dos casos de uso Gestionar interrupción del servicio y Gestionar reconexión del servicio. Entregada la alerta de canal desconectado, Proxy solicita al patrón Strategy, implementado en caso de uso Mantener continuidad del video para que determine la acción a seguir de acuerdo a la alerta. Si la alerta es canal desconectado se procede con la acción descrita en el caso de uso Gestionar interrupción del servicio y se ejecuta la acción interrupción. Ésta acción solicita al servidor enviar los flujos de datos al almacenamiento temporal mientras se mantenga la alerta y despliegue en la vista el mensaje Reconectando. Superado el problema de interrupción, Observer del canal emite alerta canal conectado. Proxy solicita a Strategy determine la acción correspondiente y proceda con la acción descrita en el caso de uso Gestionar reconexión del servicio y ejecuta la acción reconexión. Ésta acción indica que los flujos almacenados en el buffer sean transmitidos al cliente. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 117 Figura 3.3: Diagrama de clases modelo base 3.1.2. Diseño arquitectónico y de despliegue Basado en el modelo creado mediante patrón MVC se establece el diagrama de clases que se muestra en la Figura 3.3. Cada una de estas clases se encuentra asociada a una de las capas de MVC con sus respectivos patrones software así tenemos: • Capa modelo y patrón Observer: engloban las clases que determinan el almacenamiento temporal y monitoreo el estado del umbral del buffer. Estas son: AgentProxy, ServerStreaming, DataListener y Buffer. • Capa vista y patrón Composite: contiene las clases que permiten interactuar y desplegar el video con el servidor video streaming. Estas son: Video Player, Parámetros y Video View. • Capa controlador y patrones software Proxy y Strategy: contiene las clases para controlar las interrupciones y tomar acciones. Estas son: AgenteProxyCliente, AgenteProxyServidor, ActionControler, InterrupciónAction y ReconexiónAction. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 118 Figura 3.4: Diagrama de secuencia modelo base El observador externo y patrón Observer: contiene las clases que evalúan el estado del canal de comunicación. Estas son: CanalListener y CanalComunicación. La Figura 3.4 describe el diagrama de secuencia del modelo base diseñada, para la interacción entre el cliente y el servidor al solicitar la visualización de un video. El Video Player es quien inicia la aplicación, definiendo los parámetros mediante la clase Parámetros. Posterior solicita reproducir video y eleva la petición a Proxy quien valida y pide parámetros de servicio al ServidorStreaming. Éste entrega descripción de sesión al Proxy para que los envíe a Video Player. Una vez establecida la sesión, Proxy solicita a ServerStreaming envíe video. Buffer recibe el flujo de datos e inmediato entrega a VideoView para su despliegue. Por su parte Proxy solicita control de datos a Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 119 DataListener sobre estado de umbral del Buffer. Buffer envía estado a DataListener y éste evalúa, determinando si existe alerta. Al darse alerta informa a Proxy para que confirme mediante monitoreo al canal de comunicación con CanalListener. Éste monitorea el canal de comunicación y entrega estado conectado o desconectado a Proxy. Si el estado entregado es canal desconectado inmediato Proxy solicita acción a ActionControler, quien determina la acción a realizarse. Con el estado de canal desconectado ActionControler invoca a InterrupciónAction para que ejecute acciones. La acción a ejecutarse es indicar al servidor que envíe el flujo de datos al Buffer mientras se mantenga es estado desconectado. Proxy solicita seguir monitoreando al canal e informe si existe cambio de estado. Al presentarse cambio de estado a canal conectado, vuelve a solicitar acción a ActionControler, quien invoca a ReconexiónAction para que ejecute acciones. La acción es indicar que Buffer envíe los flujos almacenados para que VideoView despliegue el video. Figura 3.5: Diagrama de despliegue modelo base Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 120 La Figura 3.5 describe el diagrama de despliegue del servicio de video streaming con control de interrupciones. Contiene dos usuarios: cliente y servidor. El cliente corresponde a cualquier dispositivo móvil y contiene las clases: VideoPlayer, VideoView, Parámetros, AgenteProxyCliente, DataListener y Buffer. El servidor es un servidor de aplicaciones que contiene las clases: ServerStreaming, AgenteProxyServidor, ActionControler, InterrupciónAction, ReconexiónAction y Buffer. Se debe indicar que la clase AgentProxy de la capa controlador se encuentra distribuida entre el cliente y el servidor con el propósito de atender sus peticiones y respuestas. Esta comunicación entre estos agentes de AgentProxy establece un canal de comunicación que lo monitorea CanalListener. Utilizando el diagrama de despliegue, explicado anteriormente, VideoPlayer instancia mediante mensaje interno a Parámetros para obtener información para solicitar video. Con esta información Video Player envía una petición mediante protocolo RTSP pidiendo parámetros de sesión al Proxy. Éste solicita a Servidor estos parámetros. Servidor mediante protocolo SDP envía la descripción de la sesión al cliente. Es preciso indicar que la comunicación entra el cliente y el servidor ahora tiene un intermediario que es Proxy. Establecida la sesión, Proxy solicita mediante mensaje interno al servidor enviar el video de la fuente indicada en URL Streaming. El servidor entrega el flujo de datos del video a Proxy mediante mensaje interno. Proxy envía el flujo de datos mediante protocolo RTP al Buffer del cliente. El Buffer mediante mensaje interno entrega al VideoView el flujo de datos para su visualización. La comunicación entre agentes proxy del cliente y del servidor lo realiza con mensajes FIPA-ACL. 3.2. Modelo matemático de rendimiento Partiendo de la ecuación obtenida en el modelo matemático para el servicio de video streaming: Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 127 Figura 3.7: Diagrama de clase de APC - Aplicación Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 128 Figura 3.8: Diagrama de clase APC – Proxy Figura 3.9: Diagrama de clase de APS - Proxy Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 129 Figura 3.10: Diagrama de clase de APC - Proxy Comportamiento Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 130 Figura 3.11: Diagrama de clase de APS - Proxy Comportamiento Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 131 Figura 3.12: Diagrama de secuencia de APC - Reproducir Video - Parte 1 Figura 3.13: Diagrama de secuencia de APC - Reproducir Video - Parte 2 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 132 Figura 3.14: Diagrama de secuencia de APS - Ejecutar Servidor Proxy Figura 3.15: Diagrama de despliegue Los diagramas de secuencia del APC contiene la parte 1 y 2 que corresponde a reproducir video y el diagrama de secuencia del APS contiene ejecutar servidor proxy (Figura 3.12-3.14). Se explica a detalle la comunicación que se da entre las clases para cumplir el establecimiento de la sesión de video streaming, la activación de los Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 133 observadores: del almacenamiento y del canal de comunicación, la definición de una interrupción y la selección del algoritmo que se ejecutara de acuerdo al evento ocurrido. Finalmente tenemos el diagrama de despliegue de la solución base para control de interrupciones y contiene dos componentes que son el servidor de aplicaciones y dispositivo inalámbrico. Cada uno de ellos tiene distribuida las clases que conforman la solución y están distribuidas como se puede observar en la Figura 3.15. Al iniciar esta visualización el Proxy solicita el trabajo de observador a SharedPreference quien continuamente está revisando a BuscadorVideo y define alerta de umbral superado. Si este evento ocurre el Proxy solicita el servicio de ConnectionListener de observar el estado del canal de comunicación, si esta respuesta asegura que hay una interrupción el Proxy invoca al servicio del ThreadBehaviourFactory para que seleccione el algoritmo a ejecutar, en este caso Behaviour. Este algoritmo se encarga de que el Proxy solicite al ServerStreaming el almacenamiento temporal de los flujos que no pueden ser transmitidos y al ConnectionListener pide que evalúe el canal y determine su restablecimiento. Al restablecerse el canal el Proxy recibe esta notificación y pide al ThreadBehaviourFactory la ejecución del algoritmo correspondiente, para esta situación será CyclicBehaviour mediante el cual el Proxy solicita la transmisión del flujo que se encuentra almacenado en el Buffer del Servidor de Aplicación y sea entregado al proceso de visualización ubicado en el dispositivo móvil. 3.3.2. Desarrollo del modelo con software libre Se realizó un primer modelo para implantar la arquitectura para paso de imágenes con agente JADE de la siguiente manera (Figura 3.16): un Agente Jade que realiza la función de servidor, al cual se le designó el comportamiento de obtener la imagen del repositorio y enviarla al cliente. En el cliente, que es el dispositivo móvil Android, se instaló otro Agente cuyo comportamiento fue recibir la fotografía y desplegarla en la pantalla. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 134 Figura 3.16: Arquitectura para envío de imágenes con agente JADE Posterior se realizó un segundo modelo que permitió adaptar la arquitectura ya explicada de los agentes Jade al protocolo RTSP/RTP que ha logrado que la técnica de video streaming sea muy utilizada, y esté vigente hasta la actualidad. El éxito del protocolo RTSP, se debe a su velocidad y eficiencia a la hora de transmitir videos de gran tamaño y calidad. A esta eficiencia en los dispositivos inalámbricos se le añade los CODEC de video H.263 y H.264, que comprimen mediante algoritmos el tamaño de los fotogramas, para evitar ocupar un gran espacio de memoria en el dispositivo móvil. RTSP envía al video por dos canales, uno donde emitirá los fotogramas y otra el audio, los cuales obedecen a un instante en el tiempo para poderlos sincronizar. La característica principal de RTSP es enviar paquetes RTP a través del protocolo de transporte UDP, lo cual hace que los paquetes sean enviados y recibidos de manera rápida, porque no es orientado a la conexión, siendo esta su gran fortaleza, pero también se convierte en su mayor debilidad, ya que nadie garantiza que el cliente reciba los paquetes o que exista la perdida de estos, que es evidente en una interrupción del cliente. Para superar este gran inconveniente, el mecanismo que realiza la transferencia de video en tiempo real sobre teléfonos móviles, determina las siguientes entidades (Figura 3.17): Un Servidor de video RTSP basado en VLC, un APS, un dispositivo móvil que actúa como cliente, albergando un APC y a la aplicación RTSP Cliente la cual se llama PV Player y viene integrada al dispositivo Android, esta generará las peticiones y visualiza el video. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 135 Figura 3.17: Arquitectura JADE - RTSP Al colocar agentes de software JADE en el APS y APC, éstos cooperan en definir cuándo el móvil está fuera de cobertura al usar señalización MTP, encargándose de resolver las interrupciones intermitentes y reanudar automáticamente la sesión de video streaming. Los mensajes transmitidos FIPA-ACL al teléfono móvil son guardados en el buffer del APS ya que no pueden ser entregados al destinatario, reenviándose una vez que se reanude la conexión. El servidor de video streaming VLC se conecta con el APS y mediante acceso inalámbrico con el APC. En las comunicaciones establecidas entre los pares servidor– APS y APC–Cliente se transmiten mensajes utilizando el protocolo RTSP y para transmitir video el protocolo RTP. La comunicación entre el par APS-APC, que se despliegan en la Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 136 plataforma JADE, se comunican a través de mensajes FIPA ACL, simplificando la comunicación entre agentes. El APC se divide en dos partes: el Front-End que actúa con el dispositivo móvil Android y el Back-End con el servidor de video streaming. La comunicación entre estas partes es mediante un canal de comunicación inalámbrica, donde las posibles interrupciones se gestionan de forma transparente por el APC. Además se implementa de forma transparente dos funciones: el mecanismo de almacenamiento y envío, y el intercambio de mensajes de negociación RTSP y los paquetes RTP y RTCP. Con este se garantiza que el agente de dispositivo móvil nunca se va a desconectar del cliente. El APS recepta los mensajes del APC y los envía al servidor según los puertos establecidos en la negociación y recepta los mensajes provenientes del servidor para renviarlos al APC El uso de señalización MTP entre los agentes APS-APC permite definir si el dispositivo móvil está fuera de cobertura en una comunicación inalámbrica y reanudar automáticamente la sesión de video streaming. Al ocurrir una interrupción, los mensajes FIPA-ACL ya no se transmiten al dispositivo móvil y son almacenados en el buffer del APS, para ser entregados al APC una vez restablecida la conexión. Estos mensajes almacenados en el APS son encapsulados y tratados por el servicio de reparto persistente hasta que el agente APC se conecte y puedan ser enviados. Con este proceso se hace transparente el comportamiento de interrupción de la red inalámbrica al servidor y al cliente. El protocolo MTP permite definir el tiempo de espera para intentar reconectar APS-APC, cuyo valor que por defecto es un minuto. Se debe considerar éste tiempo para el dimensionamiento del buffer. La mitigación de disrupciones mediante la arquitectura planteada, usando agente de software como JADE permite una alternativa para controlar y mejorar el proceso de transmisión de datos, incrementado de esta forma, la usabilidad del sistema. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 143 Figura 3.19: Jitter de paquetes de audio Figura 3.20: Jitter de paquetes de video Retraso La Figura 3.21 presenta el retraso para los paquetes de audio La Figura 3.22 presenta el retraso para los paquetes de video 0 0,2 0,4 0,6 0,8 1 1,2 1 101 201 301 401 501 JITTER AUDIO Con Proxy Sin Proxy 0 0,01 0,02 0,03 0,04 0,05 0,06 1 101 201 301 401 501 JITTER VIDEO Con Proxy Sin Proxy Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 144 Figura 3.21: Retraso paquetes de audio Figura 3.22: Retraso de paquetes de video Tanto los gráficos del jitter y del retraso nos demuestran que JADE lleva paquetes más grandes, pues poseen mayor información como es la de control, pero si se puede observar mayor estabilidad en la comunicación, ya que no existe interrupciones. 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 1 101 201 301 401 501 RETRASO AUDIO Con Proxy Sin Proxy 0 0,1 0,2 0,3 0,4 0,5 0,6 1 101 201 301 401 501 RETRASO VIDEO Con Proxy Sin Proxy Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 145 Uno de los beneficios de JADE-ANDROID es que intenta reconectar el APS y el APC durante algún tiempo. El protocolo MTP permite definir el tiempo de espera para que el cliente se reconecte, valor que por defecto es un minuto; éste tiempo influye en el dimensionamiento del buffer. Al restablecerse la conexión entre los agentes, el APC lee los flujos ordenados en el buffer y los envía al video reproductor del Cliente. De esta forma se permite que el cliente recupere el video desde el punto de quiebre. Los resultados obtenidos es la reproducción de audio y video, con calidad al 100%. Al momento de salir del área de cobertura por aproximadamente 30 segundos, los paquetes tanto de audio y video se recuperan de manera exitosa, sin pérdida de ningún paquete, pero si con una demora al momento de reconectarse, debido a que los paquetes que se han quedado guardados en el buffer deben ser despachados y recalculados su retraso. En un intervalo de tiempo de 30-45 segundos fuera del área de conexión, los paquetes de audio y video llegan a su destino, el audio se logra escuchar, pero el video se atrasa y muchas veces no se reproduce, ya que el buffer es muy pequeño y no logra recalcular totalmente el flujo. A un tiempo mayor de 45 segundos, los paquetes de audio y video llegan al APC, pero el PvPlayer no los reproduce. Motivo por el cual, se decidió realizar más pruebas para comprobar la efectividad del sistema, y saber si el software desarrollado estaba fallando o dependía de otros factores ajenos al mismo. El resultado de estas últimas pruebas afirmaron que el motivo del mal funcionamiento de los 30 segundos, se debía al timestamp (marca de tiempo), ya que el PvPlayer decide desplazar los paquetes que tienen un gran retraso y no tomarlos en cuenta, produciendo que la aplicación ya no responda. Así también cuando existe una interrupción, muchas veces se puede observar que el video se demora un poco más en regresar que el audio, existiendo una desincronización, esto se debe porque un paquete de audio es igual a un flujo, en cambio en el video, un flujo son varios paquetes, teniendo que esperar que lleguen todos los paquetes para que se complete el flujo y poder reproducir. A demás de esto los paquetes Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 146 de audio oscilan en un tamaño de 97 a 450 bytes, en cambio los de video de 300 a 1400 bytes, haciendo que el audio utilice menos ancho de banda que el video. Luego de estas pruebas se ha realizado con el PvPlayer el video streaming sin proxy y a los 30 segundos se recupera de manera inmediata la transmisión, pero se pierden todos los paquetes que se han emitido en el lapso de tiempo de la interrupción. Pasado de los 30 segundos la conexión se corta y ya no regresa ni el audio ni el video. De los resultados obtenidos se concluye que para obtener una mayor calidad de video streaming, es necesario que: • El proveedor de servicios de video streaming debe en lo posible realizar sus emisiones de video en tiempo real. • Configurar de manera correcta todos los parámetros del servidor RTSP. • Utilizar los CODEC adecuados para cada dispositivo móvil. • El usuario final se encuentre en un área de cobertura donde la intensidad de la señal sea buena. Al momento de realizar las pruebas con el software Jade –Video streaming versión 0.9, se utilizó la herramienta wireshark en donde pudimos observar que todos los paquetes se estaban transmitiendo con un tamaño de 1500 bytes, lo cual hizo que se revise el archivo de captura de tráfico de red, y pudimos constatar que la mayoría de los paquetes se completaban con ceros, muchas veces casi vacíos pero su tamaño era constante, es decir 1500 bytes. Luego de obtener estos resultados, se revisó el APS, donde se verificó el valor real del paquete, que indicaba que siempre estaba enviando con 1500 bytes, valor con el que se inicializó, como se puede ver en la Figura 3.23. EL cambio que se realizó se muestra en la Figura 3.24, en donde se utilizó un manejador de Bytes (ByteArrayOutputStream), para poder obtener el contenido útil del array y de esta manera enviar en el mensaje JADE. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 147 Figura 3.23: Error de código Figura 3.24: Corrección en el código Luego de esta implementación se obtuvo lo esperado, ahora si los paquetes se están enviando con el tamaño real. Este fue un error de programación que generalmente se comete, pero que fue solucionado con éxito, ya que después de esto el resultado fue el Software Video streaming – Jade versión 1.1, en donde el video y el audio se pasa sin distorsión alguna. Con este ajuste, se pudo llegar a arreglar el error de la distorsión de la imagen y el video, ya que estaba utilizando ancho de banda innecesario. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 148 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 149 Solución basada en realidad aumentada para control de interrupciones En este capítulo se describe la funcionalidad incrementada al modelo base con el objetivo de proporcionar ambientes de experiencia inmervisa al usuario mediante sensado móvil, que le permitan minimizar el acceso a zonas de interrupción mediante despliegue de información con realidad aumentada y archivos KML para consulta colaborativa. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 150 Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 151 4.1. Análisis del diseño basado en patrones software En el capítulo 3 se planteó el modelo base basado en patrones software de diseño, concretamente en proxy, que ha permitido controlar las interrupciones del servicio video streaming ocasionadas por quiebres del canal de comunicación inalámbrico mediante una arquitectura de proxies. Esto ha permitido entregar al usuario continuidad del servicio debido a que una vez detectado la interrupción pide que se almacene los flujos y éstos sean entregados cuando se haya restablecido el canal. Esta implementación puede incurrir en tiempos adicionales de procesamiento e inversión de recursos, por los proxies y almacenamiento temporal respectivamente. Pero son totalmente despreciables debido a la reducción del impacto negativo, ocasionado por las interrupciones del servicio por quiebres del canal de comunicación, por mitigar la retransmisión de flujos de datos, minimizar tiempos de restablecimiento de la sesión y la continuidad del servicio, impactando y mejorando notablemente la QoE del usuario. Utilizando este modelo, estamos interesados en presentar un modelo incremental en el que se establezcan componentes adicionales que integre características de experiencia inmersiva con sensado móvil y RA Estas aportaciones permiten brindar QoE al usuario con el propósito de minimizar el acceso a zonas de interrupción del canal inalámbrico. Con el mecanismo diseñado en el capítulo 3 y utilizando nuevas tecnologías se planteó la necesidad de ofrecer nuevas funcionalidades al modelo propuesto en el capítulo anterior. Se desarrolló una arquitectura que permita integrar características de experiencia inmersiva con sensado móvil. Esto permitió entregar al usuario información de la intensidad de la señal del dispositivo móvil mediante técnicas de RA, para minimizar el acceso del usuario a zonas de interrupción del canal inalámbrico. Además se generó mapas personalizados online con la información del nivel de RSSI en puntos geográficos, mediante la construcción de archivos KLM/KMZ para compartirlos a través de Internet con las aplicaciones Google Earth y Google Maps. A continuación se enumeran los requisitos funcionales que deben contener el diseño de este modelo, los cuales se han determinado mediante diagramas de casos de uso y la descripción concreta de los mismos. La Figura 4.1 y las Tablas 4.14.11 muestran los casos de uso. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 152 Figura 4.1: Casos de uso modelo basado con RA El primer caso de uso describe las actividades desde que el cliente solicita el servicio de video streaming hasta que el proxy como intermediario pide al servidor el despliegue en el cliente y su almacenamiento temporal, explicado en Tabla 4.1. El segundo caso de uso describe la importancia de monitorear el umbral del almacenamiento temporal donde se alojan los flujos, explicado en la Tabla 4.2. El tercer caso de uso describe toda la funcionalidad referente al análisis por reglas de negocio para evaluar el estado de los recursos del dispositivo, explicado en la Tabla 4.3. El cuarto caso de uso describe la solicitud de confirmación de una interrupción mediante la evaluación del canal de comunicación, explicado en la Tabla 4.4. El quinto caso de uso describe el proceso que sigue el proxy para gestionar la continuidad del servicio de video streaming ante una interrupción, explicado en la Tabla 4.5. El sexto caso de uso describe el uso de buffer para almacenar los flujos que han sido enviados por el servidor y que no pueden ser entregados al dispositivo inalámbrico por la interrupción, explicado en la Tabla 4.6. El séptimo caso de uso describe la recuperación de los flujos almacenados en el buffer y el despliegue en el cliente, cuando se ha recuperado el canal de comunicación, explicado en la Tabla 4.7. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 255 [107] F. Bellifemine, G. Caire, G. Rimassa, A. Poggi, T. Trucco, E. Cortese, F. Quarta, G. Vitaglione, N. Lhuillier, and J. Picault, “Java Agent Development Framework,” TILAB Italia, http://jade. cselt. it, status, vol. 10, p. 2002, 2002. [108] A. Pokahr, L. Braubach, and A. Walczak, “Jadex user guide,” Hamburg, Germany, 2007. [109] F. Bellifemine, A. Poggi, and G. Rimassa, “JADE–A FIPA-compliant agent framework,” in Proceedings of PAAM, 1999, vol. 99, no. 97–108, p. 33. [110] F. L. Bellifemine, G. Caire, and D. Greenwood, Developing multi-agent systems with JADE, vol. 7. John Wiley & Sons, 2007. [111] A. Moreno, A. Valls, and A. Viejo, Using JADE-LEAP implement agents in mobile devices. Universitat Rovira i Virgili. Departament d’Enginyeria Informàtica, 2003. [112] Y. Wang, Z.-L. Zhang, D. H. Du, and D. Su, “A network-conscious approach to endto-end video delivery over wide area networks using proxy servers,” in INFOCOM’98. Seventeenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, 1998, vol. 2, pp. 660–667. [113] S. Cha, W. Du, and B. J. Kurz, “Middleware framework for disconnection tolerant mobile application services,” in Communication Networks and Services Research Conference (CNSR), 2010 Eighth Annual, 2010, pp. 334–340. [114] Y.-C. Lee and S.-H. Park, “RSSI-based fingerprint map building for indoor localization,” in Ubiquitous Robots and Ambient Intelligence (URAI), 2013 10th International Conference on, 2013, pp. 292–293. [115] J. Chakareski, P. Chou, and others, “RaDiO Edge: Rate-distortion optimized proxydriven streaming from the network edge,” Networking, IEEE/ACM Transactions on, vol. 14, no. 6, pp. 1302–1312, 2006. [116] P. Bellavista and A. Corradi, “A QoS management middleware based on mobility prediction for multimedia service continuity in the wireless internet,” in Computers and Communications, 2004. Proceedings. ISCC 2004. Ninth International Symposium on, 2004, vol. 1, pp. 531–538. [117] P. Bellavista, A. Corradi, and C. Giannelli, “Mobile proxies for proactive buffering in wireless internet multimedia streaming,” in Distributed Computing Systems Workshops, 2005. 25th IEEE International Conference on, 2005, pp. 297–304. [118] Y.-S. Chen, T.-L. Chin, and Y.-C. Huang, “Collaborative localization in Wireless Sensor Networks based on dependable RSSI,” in Wireless Personal Multimedia Communications (WPMC), 2012 15th International Symposium on, 2012, pp. 341–347. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 256 [119] P. Bellavista and A. Corradi, “How to support Internet-based distribution of video on demand to portable devices,” in Computers and Communications, 2002. Proceedings. ISCC 2002. Seventh International Symposium on, 2002, pp. 126–132. [120] S. Chan, G. Sohn, L. Wang, and W. Lee, “Dynamic WIFI-Based Indoor Positioning in 3D Virtual World,” ISPRS-International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, vol. 1, no. 4, pp. 1–6, 2013. [121] D.-H. Nam and S.-K. Park, “Adaptive multimedia stream presentation in mobile computing environment,” in TENCON 99. Proceedings of the IEEE Region 10 Conference, 1999, vol. 2, pp. 966–969. [122] P. Bellavista, A. Corradi, and C. Giannelli, “Mobile proxies for proactive buffering in wireless internet multimedia streaming,” in Distributed Computing Systems Workshops, 2005. 25th IEEE International Conference on, 2005, pp. 297–304. [123] P. Bellavista, A. Corradi, and L. Foschini, “Java-based proactive buffering for multimedia streaming continuity in the wireless Internet,” in World of Wireless Mobile and Multimedia Networks, 2005. WoWMoM 2005. Sixth IEEE International Symposium on a, 2005, pp. 448–450. [124] J. Ott and D. Kutscher, “A disconnection-tolerant transport for drive-thru internet environments,” in INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE, 2005, vol. 3, pp. 1849–1862. [125] K. D. Teket, M. Sayit, and G. Kardas, “Software agents for peer-to-peer video streaming,” IET Software, vol. 8, no. 4, pp. 184–192, 2014. [126] C. E. Palazzi and A. Bujari, “A delay/disruption tolerant solution for mobile-tomobile file sharing,” in Wireless Days (WD), 2010 IFIP, 2010, pp. 1–5. [127] U. Kumar and S. Agarwal, “Coding to Mitigate Video Disruption during Wireless Access Switching,” in Global Telecommunications Conference (GLOBECOM 2011), 2011 IEEE, 2011, pp. 1–5. [128] D. Benferhat, F. Guidec, and P. Quinton, “Disruption-tolerant wireless biomedical monitoring for marathon runners: A feasibility study,” in Wireless Personal Multimedia Communications (WPMC), 2011 14th International Symposium on, 2011, pp. 1–5. [129] A. Suarez, E. MacXas, J. MartXn, Y. Gutiérrez, and M. Gil, “Light Protocol and Buffer Management for Automatically Recovering Streaming Sessions in WiFi Mobile Telephones,” in Mobile Ubiquitous Computing, Systems, Services and Technologies, 2008. UBICOMM’08. The Second International Conference on, 2008, pp. 70–76. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 257 [130] E. Macias and A. Suarez, “Proactive estimation of the video streaming reception quality in WiFi networks using a cross-layer technique,” Latin America Transactions, IEEE (Revista IEEE America Latina), vol. 7, no. 3, pp. 383–389, 2009. [131] A. Suarez Sarmiento, F. Espino, and E. Macias, “Automatic recovering of RTSP sessions in mobile telephones using JADE-LEAP,” Latin America Transactions, IEEE (Revista IEEE America Latina), vol. 7, no. 3, pp. 410–417, 2009. [132] T. Gualotuña, D. Marcillo, E. M. López, and A. Suárez-Sarmiento, “Mobile Video Service Disruptions Control in Android Using JADE,” in Advances in Computing and Communications, Springer, 2011, pp. 481–490. [133] A. Suárez, M. La-Menza, E. M. MacXas, and V. S. Sunderam, “Automatic Resumption of Streaming Sessions over Wireless Communications Using Agents.,” in IMECS, 2006, pp. 926–931. [134] A. Suárez, M. La-Menza, E. M. MacXas, and V. Sunderam, “Automatic resumption of streaming sessions over WiFi using JADE,” IAENG International Journal of Computer Science, vol. 33, no. 1, pp. 92–100, 2007. [135] T. O’reilly, “What is Web 2.0: Design patterns and business models for the next generation of software,” Communications & strategies, no. 1, p. 17, 2007. [136] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design patterns: elements of reusable object-oriented software. Pearson Education, 1994. [137] D. Van Krevelen and R. Poelman, “A survey of augmented reality technologies, applications and limitations,” International Journal of Virtual Reality, vol. 9, no. 2, p. 1, 2010. [138] J. Fombona Cadavieco, M. Á. Pascual Sevillano, and M. F. Madeira Ferreira Amador, “Realidad aumentada, una evolución de las aplicaciones de los dispositivos móviles,” 2012. [139] S. Bellón Alcarazo, J. Creixel Rojo, and Á. Serrano Laguna, “Look!: framework para aplicaciones de realidad aumentada en Android,” 2011. [140] P. Browne, JBoss Drools business rules. Packt Publishing Ltd, 2009. [141] D. Nolan and D. T. Lang, “Keyhole markup language,” in XML and Web Technologies for Data Sciences with R, Springer, 2014, pp. 581–618. [142] Y. Du, C. Yu, and L. Jie, “A study of GIS development based on KML and Google Earth,” in INC, IMS and IDC, 2009. NCM’09. Fifth International Joint Conference on, 2009, pp. 1581–1585. [143] O. G. Consortium and others, “OGC KML,” Open Geospatial Consortium (OGC), Standard OGC, 2009. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 258 [144] J. Rohlf and B. McClendon, “Markup language for an interactive geographic information system.” Google Patents, 2008. [145] M. Pilgrim, HTML5: up and running. O"Reilly Media, Inc., 2010. [146] A. LÓPEZ HERREROS, “Estudio de emisión de vXdeo sobre HTML5,” 2014. [147] V. Wang, F. Salim, and P. Moskovits, The definitive guide to HTML5 WebSocket, vol. 1. Springer, 2013. [148] Q. Liu and X. Sun, “Research of Web Real-Time Communication Based on Web Socket,” 2012. [149] W. W. W. Consortium and others, “W3C. 2014. HTML 5: Techniques for providing useful text alternatives.” . [150] ISO/IEC, “ISO/IEC 23009-1:2014 Information technology – Dynamic adaptive streaming over HTTP (DASH) – Part 1: Media presentation description and segment formats.” 2014. [151] A. Hamza and M. Hefeeda, “A DASH-based free viewpoint video streaming system,” in Proceedings of Network and Operating System Support on Digital Audio and Video Workshop, 2014, p. 55. [152] P. Lazarakis, “Dynamic adaptive streaming over HTTP,” 2014. [153] S. Lederer, C. Mueller, C. Timmerer, C. Concolato, J. Le Feuvre, and K. Fliegel, “Distributed DASH dataset,” in Proceedings of the 4th ACM Multimedia Systems Conference, 2013, pp. 131–135. [154] C. Alberti, D. Renzi, C. Timmerer, C. Mueller, S. Lederer, S. Battista, and M. Mattavelli, “Automated QoE evaluation of dynamic adaptive streaming over HTTP,” in Quality of Multimedia Experience (QoMEX), 2013 Fifth International Workshop on, 2013, pp. 58–63. [155] I. Sodagar, “The mpeg-dash standard for multimedia streaming over the internet,” IEEE MultiMedia, no. 4, pp. 62–67, 2011. [156] T. Lohmar, T. Einarsson, P. Fröjdh, F. Gabin, and M. Kampmann, “Dynamic adaptive HTTP streaming of live content,” in World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2011 IEEE International Symposium on a, 2011, pp. 1–8. [157] J. K. Nurminen, A. J. Meyn, E. Jalonen, Y. Raivio, and R. GarcXa Marrero, “P2P media streaming with HTML5 and WebRTC,” in Computer Communications Workshops (INFOCOM WKSHPS), 2013 IEEE Conference on, 2013, pp. 63–64. [158] C. Alexandru, “Impact of WebRTC (P2P in the Browser),” Internet Economics VIII, vol. 39, 2014. Control de interrupciones de video streaming móvil en arquitecturas Android usando técnicas de realidad aumentada y WebRTC 259 [159] J. Uberti and C. Jennings, “Javascript Session Establishment Protocol,” draft-ietfrtcweb-jsep-06 (work in progress), 2014. [160] J. Rosenberg, “Interactive connectivity establishment (ICE): A protocol for network address translator (NAT) traversal for offer/answer protocols,” 2010. [161] P. RodrXguez Pérez, J. Cerviño Arriba, I. Trajkovska, and J. Salvachúa RodrXguez, “Advanced Videoconferencing based on WebRTC,” 2012. [162] J. Rosenberg, R. Mahy, P. Matthews, and D. Wing, “Session traversal utilities for NAT (STUN),” 2008. [163] R. Mahy, P. Matthews, and J. Rosenberg, “Traversal using relays around nat (turn): Relay extensions to session traversal utilities for nat (stun),” 2010. [164] H. Alvestrand, “A Registry for WebRTC statistics identifiers,” 2012.