Capítulo VI:
Arquitectura Two Proxy Servers para dispositivos móviles sobre redes UMTS
En este trabajo se analiza el problema de la desconexión por caída de cobertura en una sesión de streaming de objetos multimedia en teléfonos móviles operando sobre redes UMTS.
Se analiza el contexto tecnológico de la movilidad basada en telefonía móvil y se explica la adaptacion de la estructura TPS a este contexto en diferentes variantes basadas en la modalidad de streaming que se utilize.
Introducción
En el tratamiento de temas relacionados a streaming en movilidad y más concretamente cuando involucran dispositivos móviles sobre redes GSM o similares se plantean restricciones que podríamos agrupar en al menos dos categorías:
Las limitaciones propias de los dispositivos móviles
El sistema de red subyacente
Por ello a continuación veremos los aspectos de ambas características que más gravitación tienen en la adaptación de la arquitectura TPS a este contexto
Tecnologías para desarrollos sobre dispositivos móviles
Los dispositivos de mano como los teléfonos móviles y asistentes personales digitales (Personal Digital Assitant, PDA) están limitados en cuanto a capacidad de procesamiento, espacio de almacenamiento, conectividad e interfaz de usuario.
Otra limitación importante es el consumo de energía ya que los dispositivos de mano tienen un tiempo de funcionamiento autónomo limitado. Estas limitaciones pueden provocar resultados inaceptables aún cuando la red proporcione una buena QoS, por lo que es necesario tener esto en cuenta al desarrollar aplicaciones multimedia para dispositivos móviles.
Esas limitaciones condicionan también las posibilidades de desarrollar aplicaciones sobre este tipo de dispositivos.
A continuación se analizarán las tecnologías disponibles para soportar la solución del problema que nos ocupa.
Considerando que en (19) proponíamos una arquitectura basada en agentes JADE, comenzamos evaluando su potencial inclusión en el escenario actual, donde el host en movilidad ahora es un teléfono móvil. Luego pasamos a analizar la plataforma de desarrollo para móviles, Java Micro Edition (Java ME) y más específicamente su API Multimedia.
LEAP
En (19) desarrollamos una solucion basada en agentes inteligentes. En aquel caso, los agentes (uno residiendo en el host móvil y otro en un host de la red fija) se comunicaban entre si mediante mensajes FIPA-ACL (FIPA-Foundation for Intelligent Physical Agents, ACL-Agent Communication Language). Intercambiando, encapsulados en ACL, tanto mensajes RTSP como RTP. La plataforma, mediante su Message Transport Protocol (MTP) se encargaba de detectar las desconexiones, de comunicarlas a los agentes, de intentar luego la reconexión y de, una vez lograda, avisar la reconexión a los agentes y re-enviar los mensajes no enviados. Y esta estructura multiagentes no solo controlaba la situación de la desconexión trabajando colaborativamente, sino que dejaba la puerta abierta para el agregado de nuevos servicios, en la forma de nuevos agentes. Por ejemplo para monitorear el estado de la red y tomar medidas proactivas o para negociar sesiones de videostreaming tipo VoD con otros agentes.
JADE esta desarrollado sobre la API de JAVA SE y por lo tanto no puede ejecutar en teléfonos móviles. Pero la plataforma LEAP (65), es un add-on de JADE para la utilización de agentes en dispositivos móviles. Esta plataforma presenta dos modos de ejecución: Stand-alone y Split. Stand-alone es básicamente la instalación de una plataforma JADE en toda regla, en el propio dispositivo. Pero este modo de ejecución solo puede utilizarse con dispositivos de configuración tipo Connected Device Configuration (CDC), estos es, del tipo PDA. Y aunque factible, la propia documentación de la plataforma aconseja el modo Split. El cual consiste en dividir la plataforma en dos componentes; un componente Front-End, que reside en el dispositivo (es un MIDlet), y otro Back-End que reside en un host situado en la red fija. Los dispositivos tipo Connected Limited Device Configuration (CLDC), es decir, los teléfonos móviles, solo disponen de este modo de ejecución para LEAP.
Estructuralmente, el modo Split guarda una estrecha relación con la arquitectura aquí propuesta por nosotros.
No obstante la factibilidad del uso de agentes en terminales móviles, hay razones de peso, para desechar su uso. La primera de estas razones es la necesaria economía de recursos a la hora de diseñar una aplicación móvil, la cual obliga a practicar un minimalismo que conduce a descartar toda estructura prescindible. Y considerando que la ejecución de videostreaming es recurso-intensiva, en nuestro caso el minimalismo debe ser extremo.
Por otro lado la mayoría de las Kilo Virtual Machine (KVM) de los móviles actuales no son multitasking. Esto implica que solo puede haber un MIDlet activo y en caso de usar LEAP, ese MIDlet sería la propia plataforma LEAP.
Por último la estrategia de transportar paquetes RTP encapsulados en mensajes FIPA-ACL ya deja de ser viable en tanto que MTP es un protocolo basado en HTTP, que es lo mismo que decir TCP y las redes móviles actuales no tienen el suficiente ancho de banda para soportar eficientemente videostreaming TCP.
Java ME
Un importante condicionante tecnológico en los desarrollos para telefonía móvil es la plataforma a utilizar. Java ME con alrededor del 80% del mercado de dispositivos móviles (según Sun y a Noviembre de 2006 4 billones de dispositivos móviles (14) sobre un total estimado en 5 billones, soportan JME) es a todos los efectos un estándar de facto.
Desde siempre Java tiene un slogan que reza “write-once run everywhere” y que habla de la portabilidad del código desarrollado en Java. Considerando la enorme variedad de dispositivos que el mercado ofrece, disponer de una herramienta que permita desarrollar para todos ellos es más que interesante. Pero hay que decir que, en lo que ha móviles se refiere, el citado slogan es cuanto menos, inexacto. Las implementaciones de Java proporcionadas por los fabricantes, suelen incumplir o cumplir parcialmente las Java Specification Requests (JSR). Que son las especificaciones emanadas de los Java Community Process (JCP) (15) que describen las distintas API's disponibles en la plataforma.
Y en la práctica esto puede implicar toda una gama de problemas para adaptar una aplicación a otra marca o incluso modelos de la misma marca. Cuya solución puede involucrar, desde pequeños cambios cosméticos, hasta el replanteo completo de la aplicación.
Actualmente, las expectativas están puestas en la definición del nuevo Mobile Information Device Profile 3.0 (MIDP 3.0). Cuya especificación esta siendo desarrollada (JSR 271) y que no solo expandirá la funcionalidad de la plataforma en todas las áreas sino que también mejorará la interoperabilidad entre dispositivos. Y también, aunque no es de por si un estándard, en Android que es un sistema operativo para móviles desarrollado por Google en el contexto de la Open Handset Project (66). Este SO, basado en un kernel de Linux, tiene la característica de que, si bien permite ser programado en sintaxis Java, está basado en una máquina virtual Dalvik, que no opera con el mismo bytecode de Java. Esta JVM está optimizada para funcionar con poca memoria y permite ejecutar varias instancias de la máquina virtual (multitasking) delegando en el SO el soporte de isolación. El SDK distribuido actualmente resulta muy interesante y se asume que con el respaldo de Google más la anunciada política de bajo costo de los dispositivos resulte un competencia feroz de Symbian (67). Pero obviamente una aplicación desarrollada para Android no funcionará en móviles JME cualquiera sea el SO de base.
En lo relativo a multimedia, Java ME ofrece una API llamada Mobile Media API (MMAPI). Esta API, basada en la especificación JSR-135, extiende la funcionalidad de la plataforma Java ME proveyendo soporte para audio y vídeo. Pero a la fecha, la mayoría de las implementaciones de esta API suelen ser disfuncionales. Sobre todo en lo que a videostreaming se refiere.
MMAPI
Los esfuerzos de la comunidad Java en materia de multimedia para móviles recién comenzaron a mediados de 2001, cuando la JCP acordó desarrollar una especificación formal que tratara esta temática.
Así el 11 de Junio de 2002 resultó aprobada la liberación de la primera Final Release de la JSR-135, con el único voto en contra de Philips que de acuerdo a la información suministrada por el sitio de la JCP (www.jcp.org) estaba en desacuerdo por la estrecha relación entre esta JSR y la Java Media Framework (JMF 1.0).
Claramente, en el diseño de la MMAPI, se percibe la influencia de JMF (Java Media Framework). Las dos API’s comparten muchas similitudes. Ambas son APIs de alto nivel destinadas a trabajar con datos multimedia. Las dos comparten el concepto de Player y Datasource, proveyendo además de similares funcionalidades. Esto, sin embargo, no significa que MMAPI sea una versión reducida de JMF. A diferencia de MMAPI, JMF está diseñado para ser utilizado en entornos cliente-servidor donde hay suficiente cantidad de recursos. JMF 2.1 tiene un gran número de características que no se encuentran en MMAPI, porque presenta ciertos rasgos que la hacen incompatible para su uso con dispositivos inalámbricos.
Pero ya el tamaño de memoria requerido por JMF resulta prohibitivo para la memoria promedio de un móvil. De ahí que hubiera que adaptar la API a las posibilidades que presentan los móviles (memoria, procesamiento y conectividad). Es así que MMAPI presenta sensibles limitaciones respecto a JMF, no obstante ciertos conceptos resultan comunes:
Figura 1 - Estados de un objeto Player
Player, este objeto es agnóstico respecto al tipo de objeto multimedia a reproducir (reproduce tanto audio como vídeo). Y al igual que su homónimo de JMF presenta cinco estados; Unrealized, Realized, Prefetched, Started, Closed. La Figura 1 muestra el ciclo de vida de un objeto Player.
La interface Control, permite controlar algunas funciones de procesamiento de la información de media. Cada tipo de información (audio, vídeo) tiene una serie de controles asociados que pueden implementarse.
El objeto Datasource que sirve de soporte de protocolos y que oculta los detalles de la fuente (si es archivo, streaming, etc.). Este objeto proporciona métodos al Player para acceder a los datos. Así mismo siendo que implementa la interface Controllable, también proporciona controles extra, vía interfaces específicas del tipo de contenido.
El objeto Manager, que es quién gestiona la creación de los Players y la asociación con los correspondientes Datasource. También permite preguntar sobre protocolos y tipos de media soportados.
|
