Hacia la TV Digital Interactiva (3)

En esta tercera entrega sobre la TV Digital Interactiva se profundiza en las plataformas MHP, definidas a partir de la experiencia acumulada en este campo. Los beneficios que puede traer su adopción no son el resultado de un mito ni de las expectativas creadas: el estándar ha nacido como respuesta a la situación real del mercado de la TV Digital.

Dada la reciente aparición del estándar MHP, durante su especificación se ha tenido en cuenta su posible evolución, por lo que se ha especificado un conjunto de perfiles que definen sus características y que vienen marcados por distintas áreas de actuación y niveles. Las áreas de actuación corresponden a lo que se ha denominado application profile, y los niveles a los profiles.
Las áreas de actuación clasifican a las plataformas en función de las características de las aplicaciones que pueden ejecutar. En primer lugar, se define el área denominada Enhanced Broadcasting, que combina la transmisión digital de los servicios de vídeo y audio del operador con las aplicaciones que pueden ser descargadas para ser ejecutadas en el descodificador ofreciendo interactividad local; es decir, estas plataformas no poseen canal de retorno y la única interactividad que ofrecen se desarrolla en el propio descodificador del usuario. En segundo lugar, se sitúa el área correspondiente a Interactive Broadcasting, en la que se pueden proporcionar servicios interactivos que pueden o no estar asociados a los servicios de vídeo y audio ofrecidos por el operador, y que permiten una interactividad completa. En este caso, la plataforma está dotada de un canal de retorno, con objeto de realizar la comunicación entre los descodificadores y la cabecera. Finalmente se define el área llamada Internet Access, cuyo objetivo es permitir proveer a los usuarios de servicios Internet.

Arquitectura
Para evitar problemas derivados de la incompatibilidad de versiones de la plataforma tanto los application profiles como los profiles deben cumplir el principio de compatibilidad hacia atrás. En el caso de MHP 1.1, que posee application profile 3, y profile 2, se producirá una compatibilidad que soportará las tres áreas definidas, tanto para el profile 2 como para el profile 1.
Con el fin de lograr los objetivos de interoperatividad, la plataforma se organiza siguiendo una arquitectura en capas, siendo la inferior la Capa de Recursos del descodificador. Sobre ésta se sitúa la Capa de Software de Sistema, que aislará a las aplicaciones de los recursos existentes en el descodificador. Es en esta capa donde se implementa la JVM (Java Virtual Machine), que ofrece las diversas bibliotecas Java que finalmente conformarán el API que los proveedores de aplicaciones interactivas podrán utilizar en sus desarrollos. Y es precisamente este API el objeto de la mayor parte del esfuerzo de especificación llevado a cabo por DVB-MHP.
Sin embargo, MHP define también el comportamiento que las aplicaciones deben presentar en su ejecución, es decir, el ciclo de vida de las aplicaciones, permitiendo que incluso el operador pueda controlarlo desde la cabecera. Para llevar a cabo esta tarea, la capa de software de sistema incluye un elemento más: el Application Manager. Cuando un operador solicita un cambio de estado en una aplicación, o simplemente el sistema necesita detener una aplicación, la petición llega al Application Manager, que se encarga de ejecutar la orden recibida. Finalmente, en la parte superior de la arquitectura, aparece la Capa de Aplicaciones, que es lugar donde se sitúan las diversas aplicaciones descargadas y que utilizan los servicios ofrecidos por las capas inferiores.
Realmente, a través de esta arquitectura en capas se está estableciendo una relación jerárquica en la que el usuario, a través de la interfaz que la aplicación ofrece, controla su ejecución, y la aplicación, para poder llevar a cabo su cometido, utiliza el API disponible gracias a la capa de software de sistema, que finalmente acaba utilizando los recursos disponibles en el descodificador.
Sin embargo, el esfuerzo de estandarización no se queda exclusivamente en el hecho de especificar una API para los desarrolladores de aplicaciones interactivas, sino que llega a definir el comportamiento de dichas aplicaciones. Mediante la definición de su ciclo de vida, MHP permite controlar los diversos estados en los que las aplicaciones se pueden encontrar durante su ejecución, evitando en todo momento la aparición de situaciones incontroladas y confiriendo a la ejecución una gran robustez y fiabilidad.

Modelos de aplicaciones
En MHP se definen dos modelos de aplicaciones que están claramente diferenciados. Por un lado, se presentan las aplicaciones DVB-J, basadas en tecnologías Java, y, por otro, las aplicaciones DVB-HTML, que se basan en el uso de HTML y JavaScript. Aunque entre ambos modelos existen algunas diferencias, se presentan algunas características comunes a todas ellas.
En primer lugar, como ya se ha mencionado, las aplicaciones presentan un ciclo de vida muy definido, evitando el paso por estados incontrolados que podrían llevar a la plataforma a inestabilizarse. Aún así, para mayor seguridad, se proveen mecanismos que permiten que el operador pueda controlar el estado de las aplicaciones mediante la señalización desde la cabecera. En segundo lugar, MHP permite la concurrencia, es decir, un mismo terminal puede estar ejecutando varias aplicaciones al mismo tiempo. Esto implica un control de acceso a los recursos, que se realiza a través del arbitrio del Application Manager. Finalmente, las aplicaciones están asociadas a un servicio, es decir, a un canal. En el momento en el que el usuario cambia de canal, la plataforma consulta qué aplicaciones debe ejecutar y procede en consecuencia. Por ello, MHP especifica un mecanismo para la señalización de aplicaciones permitiendo llevar a cabo esta operativa.
Pero, ¿cómo puede un desarrollador realizar aplicaciones para esta plataforma?. Simplemente se deben utilizar el API disponibles. En el caso de aplicaciones DVB-J, estas son interfaces Java, recogidas de múltiples fuentes, como DAVIC, HAVi, JavaTV, y algunos de nuevo desarrollo como el paquete org.dvb.si. Para las aplicaciones DVB-HTML, se utiliza tecnología HTML y ECMAScript, haciendo visible la API Java a este último para poder llevar a cabo el acceso a la plataforma.
Como conclusión, DVB-MHP ha especificado una plataforma estándar basándose en el conocimiento acumulado de experiencias anteriores y tratando de proveer mecanismos que faciliten su adopción en el mercado de la forma menos traumática posible. Para ello, sus principios de funcionamiento se basan en la definición de unos profiles que marcan la evolución de la plataforma, junto una arquitectura pensada para facilitar la portabilidad e interoperatividad de aplicaciones, que están sometidas a un ciclo de vida muy definido. En definitiva, la plataforma MHP es prometedora, debido principalmente a sus fundamentos y a las grandes implicaciones que puede traer al mundo de la Televisión Digital. Ojalá que pronto todos hayamos adoptado este nuevo estándar.


Señalización de Aplicaciones MHP
-----------------------------------------------
En una plataforma MHP las aplicaciones están asociadas a un servicio. Se debe suministrar, por tanto, un mecanismo que permita llevar a cabo está asociación, y que a su vez el descodificador pueda interpretar. Este mecanismo es la Señalización de Aplicaciones, que tiene como objetivos