Informe Preliminar: Estado del Arte de Receptores Moviles Aplicaciones

Transcripción

1 Informe Preliminar: Estado del Arte de Receptores Moviles Aplicaciones ÁREA DE APLICACIONES TELEMÁTICAS INVESTIGADORES JUAN MAURICIO VILLANUEVA JOEL TELLES CASTILLO ELEAZAR SAL Y ROSAS CELI INICTEL-UNI Lima, Febrero de

2 Contenido CAPITULO I ESPECIFICACIONES DE RECEPTORES ONE-SEG Introducción Especificaciones Conclusiones... 8 CAPITULO II ESTUDIO DE LOS APLICATIVOS EXISTENTES PARA MOVILES Introducción Aplicaciones de Televisión Digital en Móviles M-Government M-Voting M-Commerce Estudio de caso 1: Middleware Ginga-NCL en móviles - Formula Estudio de caso 2: Middleware Ginga-NCL en móviles Comerciales Conclusiones CAPITULO III TECNOLOGIAS DE INTERACTIVIDAD Y DE CANAL DE RETORNO Introducción Tecnologías de Interactividad Canal de Retorno Conclusiones CAPITULO IV INTERFACES DE USUARIOS PARA APLICACIONES Introducción Interfaces de Usuarios usando J2ME Desarrollo de aplicaciones utilizando J2ME Configuración CLDC El perfil MIDP Sistemas Operativos y Niveles de Programación Conclusiones CAPITULO V SISTEMA OPERATIVO Y NIVELES DE PROGRAMACION EN DISPOSITIVOS MOVILES Introducción Sistemas Operativos para Móviles Middleware para Dispositivos Móviles Conclusiones CAPITULO VI EQUIPOS MOVILES BASADOS EN EL ESTANDAR ISDB-T Introducción Equipos móviles basados en el Estándar ISDB-T Conclusiones REFERENCIAS

3 CAPITULO I ESPECIFICACIONES DE RECEPTORES ONE-SEG 1.1. Introducción La Norma Brasileña ABNT NBR 15604, especifica un conjunto de funcionalidades esenciales requeridas de los dispositivos de recepción de televisión digital full-seg, así como los de one-seg, destinados a recibir señales en la modalidad fija, móvil y portátil [1]. Un dispositivo one-seg, es aquel que decodifica exclusivamente informaciones de audio, video, datos, etc., asignada en el segmento central de los 13 segmentos. Este dispositivo, permite realizar la interactividad a través de canal de interactividad, el cual es un mecanismo de comunicación que suministra conexión entre el receptor y un servidor remoto. En este contexto, en este capítulo, se estudiara las especificaciones relacionadas a los receptores on-seg, los cuales se encuentran contenidos en la Norma ABNT NBR [1] Especificaciones Entre las especificaciones de los receptores one-seg, según la norma ABNT NBR 15604, están: a) Receptor portátil: La clasificación one-seg se destina a los receptores del tipo portátil, también conocidos como handheld, para pantallas de exhibición de dimensiones reducidas, normalmente hasta 7 pulgadas. Entre los productos clasificados como one-seg, están los receptores integrados con teléfono celular, PDA, dongle y televisores portátiles, los cuales reciben alimentación de una batería interna y, por lo tanto sin necesariamente requerir una fuente externa de energía, así como aquellos destinados a automóviles. Estos tipos de receptores son capazes de recibir y decodificar señales de televisión digital terrestre. b) Dispositivos portátiles de recepción parcial (one-seg): La unidad de recepción parcial debe ser capaz de por lo menos sintonizar los canales de 3

4 televisión limitados por la banda de UHF, comprendidos entre los canales 14 a 69. c) Ancho de banda del canal: El ancho de banda del canal debe ser compatible con lo especificado en el ABNT NBR 15601:2007, como sigue: dispositivos fijos o móviles de recepción (full-seg): 5.7 MHZ dispositivos portátiles (one-seg): 0.43 MHz d) Presentación de contenidos one-seg en receptores full-seg: La presentación de los contenidos transmitidos para los receptores one-seg, en los dispositivos de recepción full-seg, simultáneamente o no, depende de la arquitectura del receptor. La especificación de esta funcionalidad es, por lo tanto, facultada al fabricante. e) Memorias: El receptor que disponga de middleware instalado en su arquitectura debe poner a disposición 2 MB o más de memoria volátil para contenidos de datos transmitidos por ciclo de vida definido por la aplicación. El receptor debe disponer de memoria no volátil para almacenamiento de códigos de programa. f) Decodificación de vídeo e interfaces de salidas: El receptor debe ser capaz de decodificar un stream de vídeo H.264/AVC, de acuerdo con la ABNT NBR : perfiles y niveles, decodificación de los servicios primarios, formatos y tasa de cuadros, señales e interfaces de salida de vídeo analógico y digital, salida de RF, etc. g) Decodificación de audio e interfaces de salidas: El receptor debe ser capaz de decodificar stream de audio en el estándar MPEG-4 AAC, de acuerdo con la ABNT NBR : parámetros para decodificación de audio, perfiles y niveles, decodificación del stream primario, interfaces de salidas analógica o digital. h) Decodificador de datos primarios: La implementación del middleware Ginga es opcional, pero, desde que colocado en el receptor, los requisitos mínimos obligatorios definidos en la Tabla 1.1 deben ser implementados necesariamente. 4

5 Tabla 1.1. Implementación del Middleware Ginga en un Receptor one-seg. Lenguaje de Programa Full-seg One-seg Descripción Ginga NCL Obligatorio Obligatorio Java Obligatorio Opcional Puente de Enlace entre Lenguajes LUA Puente Obligatorio Opcional ECMAScript Opcional Opcional Maquina de Ejecución Engine Maquina virtual Java Obligatorio Opcional LUA Obligatorio Obligatorio Suite de prueba Declaración de conformidad Obligatorio Obligatorio Receptor full-seg Ginga-J es obligatorio Obligatorio en el one-seg, en caso de ser implementado en Java Debe pasar por el conjunto de ensayos definidos en las especificaciones de la suite de prueba i) Suite de prueba: Para garantizar la interoperabilidad entre las más diversas implementaciones e integraciones del middleware Ginga en distintas arquitecturas de hardware y software, el middleware incorporado debe pasar obligatoriamente por un conjunto de ensayos, de conformidad con las especificaciones de la suite de prueba definida por el foro del sistema brasileño de televisión digital. El resultado de las pruebas debe ser la base del documento de declaración de proveedor, el cual debe garantizar que el middleware Ginga incorporado en la plataforma cumpla totalmente los requisitos definidos por las normas: ABNT NBR ABNT NBR ABNT NBR Del mismo modo, las aplicaciones interactivas enviadas al receptor, por cualquier medio físico, deberán someterse a ensayo para la validación. j) Accesibilidad: Aunque su transmisión es obligatoria, los recursos de accesibilidad son de implementación facultativa en cualquier tipo de 5

6 receptor. Sin embargo, una vez puestos a disposición, integralmente o en parte, deben obligatoriamente cumplir las especificaciones de la norma. Los recursos que componen el conjunto de accesibilidad son: Closed-caption Audio descripción Locución Doblaje Ventana de LIBRAS (Lenguaje Brasileño de Señales) k) Funciones mínimas recomendadas: Para que el usuario pueda disfrutar de los servicios disponibles en las transmisiones digitales, es recomendable que se ofrezcan las siguientes funciones: Encender/apagar: conmutación para plena operación o estado de espera Numéricas (0 a 9): acceso directo a los canales y letras de acuerdo con la ETSI ES :2003. Canales superior e inferior: navega por los canales almacenados Control de volumen: aumentar o reducir el volumen Guía (EPG): acceso a la guía de programación. l) Función EPG: La implementación del EPG es facultativa para los fabricantes de los receptores. Las transmisiones deben permitir obligatoriamente informaciones en tres diferentes tipos básicos de distribución de la EIT y el receptor que recibe informaciones de estas tablas debe mostrar obligatoriamente este contenido en área reservada para cada tipo de EPG. H-EIT: para full-seg M-EIT: para receptor móvil L-EIT: para receptor one-seg m) Funciones de la Comunicación Interactiva: La implementación del canal de interactividad es facultativa al fabricante del dispositivo de recepción. Sin embargo, al ser implementado, debe obligatoriamente estar en conformidad con las especificaciones de la norma. 6

7 n) Comunicación interactiva (bidireccional) canal de interactividad: La implementación del canal de interactividad es facultativa al fabricante del dispositivo de recepción, sin embargo, una vez implementado, debe seguir lo establecido en la norma. o) Receptores con mecanismos para interactividad: Para los receptores que dispongan de mecanismos de interactividad, las teclas, o cualquier otra forma de interfaz, deben suministrar obligatoriamente las siguientes funcionalidades: Confirma: confirmar la operación Salir: abandonar la operación Volver: retornar a la operación anterior Direccionales (arriba, abajo, derecha e izquierda): navegación de colores (verde, amarilla, azul, y roja): atajos para funcionalidades contextuales; Info: informaciones sobre programación Menú: presenta opciones de acuerdo con el contexto. p) Receptor one-seg: Los receptores one-seg (un segmento) deben ser, obligatoriamente, capaces de decodificar bitstreams con todas las herramientas de codificación descritas en el perfil baseline: H.264/AVC 1.3. Las restricciones en los parámetros de codificación de vídeo para dispositivos portátiles deben estar de conformidad con la norma ABNT NBR :2007. q) Receptores one-seg: Los receptores one-seg deben soportar obligatoriamente por lo menos la decodificación de vídeo en los formatos; CIF con razón de aspecto de 4:3, QVGA y SQVGA, ambos con razón de aspecto de 4:3 y 16:9. Estos formatos de vídeo se presentan en la Tabla 1.2, pudiendo, a criterio del fabricante del receptor, ser agregadas otras resoluciones no especificadas aquí. 7

8 Formato de vídeo de salida Razón de aspecto Tabla 1.2. Resoluciones obligatorias. Número de líneas a ser decodificadas aspect ratio info Formato de vídeo de salida Razón de aspecto Número de líneas a ser decodificadas SQVGA 4:3 160 x i 4:3 720 x SQVGA 16:9 160 x i 16:9 720 x QVGA 4:3 320 x p 16:9 720 x QVGA 16:9 320 x p 16: x CIF 4:3 352 x i 16: x aspect ratio info r) Tasa de Cuadros (frame rate): Receptores one-seg: Los receptores oneseg deben soportar obligatoriamente por lo menos las tasas de cuadros de 5fps, 10fps, 12fps, 15fps, 24fps y 30fps. Esas tasas de cuadros especificadas pueden ser excedidas por otras no especificadas en esta Norma, a criterio del fabricante del receptor. s) Decodificación de datos primarios: Receptores one-seg: Se define para los receptores one-seg el middleware Ginga declarativo con Engine LUA. Por lo tanto, cuando esté presente en el receptor one-seg debe obligatoriamente contemplar las especificaciones del Ginga-NCL stand alone con máquina de ejecución LUA. El puente con una maquina Java es opcional Conclusiones Las especificaciones técnicas y funcionalidades de los receptores one-seg, se encuentran estipuladas por la Norma ABNT NBR Un aspecto importante para la implementación de aplicaciones interactivas, radica en la obligatoriedad del uso del lenguaje declarativo Ginga-NCL, siendo opcional el uso del lenguaje procedural Ginga-J. 8

9 CAPITULO II ESTUDIO DE LOS APLICATIVOS EXISTENTES PARA MOVILES 2.1. Introducción El éxito de una aplicación sobre otra (asumiendo que tengan funciones similares) se encuentra relacionado en gran medida a su diseño de interfaz gráfica y la forma en que el usuario interactúa con el sistema. En diversos estudios, tanto en universidades como en la industria, han intentado explorar las mejores prácticas para el diseño de interfaces interactivas en el área de televisión digital. Un ejemplo podría darse durante una franja publicitaria en televisión, el telespectador podría acceder a contenidos de comerciales interactivos de la siguiente forma: Si está interesado en un producto avisado, el telespectador puede acceder a información específica relativa a este, la cual se sobreimprime en la pantalla del televisor. El telespectador puede «marcar» el aviso para poder revisar información detalla en otro momento. El telespectador puede solicitar folletos o una llamada de un agente de ventas. Se puede incentivar al telespectador que vea o interactúe con un aviso de publicidad a través del envío posterior de cupones de descuento, ofertas o sorteos. Concursos interactivos sobre información de productos avisados. Compra impulsiva: permitir al telespectador comprar un producto inmediatamente luego de ver un aviso. También podemos tener aplicaciones interactivas para poder hacer votaciones con respecto a lo que ve en la pantalla, El desafío de hoy es poder analizar las necesidades de la sociedad y planear lineamientos para su desarrollo [2] Aplicaciones de Televisión Digital en Móviles Una las ventajas de la portabilidad de la TV digital es el acceso al contenido en cualquier lugar, cualquier momento, aun cuando el equipo móvil se encuentre en 9

10 movimiento, esto nos permite el surgimiento de nuevos servicios como: oferta de guías electrónicas para programas televisivos, control de acceso bancario, servicio de salud, servicios educativos, servicios de gobierno, etc M-Government Es la extensión de la administración pública electrónica para plataformas móviles. Esta plataforma se convierte en un instrumento para el estado con el fin de acercarse más al ciudadano en cualquier lugar y a cualquier hora. Los dispositivos móviles proveen un importante canal de acceso entre el gobierno y los ciudadanos, en algunos lugares como Singapur, China, Londres y Hong Kong, los habitantes pueden registrarse para recibir mensajes de alerta SMS con información, como por ejemplo en Singapur, renovación de pasaporte, en Londres, Alertas terroristas y broadscast de emergencias, en Hong Kong avisos de enfermedades contagiosas, en la china información mediante SMS para los diputados M-Voting La aplicación para M-voting, tiene la finalidad de establecer el diálogo entre el gobierno con la población, de esta manera insertar cada vez más la administración pública en la toma de decisiones, con la aprobación de la población, para elegir diferentes planos de acción dentro de un municipio, departamento o gobierno [24] M-Commerce El M-Commerce (mobile commerce, por su siglas en ingles) es la compra y venta de productos o servicios a través de dispositivos de mano conectados en forma inalámbrica como teléfonos celulares y asistentes digitales personales (PDA's). La capacidad multimedia para el despliegue de todo tipo de servicios interactivos, atractivos para los usuarios como nuevas oportunidades de negocio modifica la cadena de valor tradicional del negocio móvil [28] Estudio de caso 1: Middleware Ginga-NCL en móviles - Formula 1 Siendo digital la imagen transmitida es posible que el contenido sea comprimido reduciendo así la tasa de bits generada esto posibilita su transmisión a 10

11 una menor ancho de banda. A demás de poder transmitir más de una señal de video, audio y datos. El canal de datos nos va a permitir la interactividad. En este panorama, una de las aplicaciones desarrolladas basadas en middleware Ginga-NCL para dispositivos portátiles, fue una carrera de Fórmula 1 [25], como ilustrado en la Figura 2.1. En esta aplicación se tiene ocupada parte de la pantalla ejecutando la aplicación, y el resto del espacio es utilizado para presentar tres opciones para la interactividad. Figura 2.1. Aplicación de Formula 1 Las interacciones pueden ser realizadas presionando las teclas 1, 2 o 3 del dispositivo. El uso de la tecla 1 presenta la información sobre los pilotos de la formula1. En el caso de usar la tecla 2, la información sobre los equipos son exhibidas y el uso de la tecla 3 muestra la pista de competición. En todos los casos, el video pasa a ocupar la cuarta parte de la pantalla cuando una nueva opción de interacción es exhibida, como podemos ver en la Figura

12 Figura 2.2. Los tres casos de interacción de la aplicación Formula 1 Cuando se presiona la tecla 9, la aplicación vuelve al estado inicial, los reproductores usados en la Formula 1 fueron los de video e imagen. La gran mayoría de los problemas durante la realización de las pruebas fueron solucionados durante los ensayos realizados con la aplicación en cuestión. En el caso de la imagen fue observada una limitación de los tipos de imagen soportados. Además de esta limitación la presentación de la imagen no presentar mayor problema. Esta aplicación, desarrollada en Middleware Ginga, fue ejecutada utilizando el sistema operativo Symbian. Algunas limitaciones fueron observadas durante la ejecución de referida aplicación, talos como: El reproductor del video presento problemas durante la apertura del video y el volumen. Este problema fue solucionado utilizando un API de Symbian, sin embargo, es complejoy de uso restrigido. Durante la ejecución de la aplicación Formula 1, se hizo evidente la limitación de la cantidad total de los archivos multimedia que podrían ser presentados al mismo tiempo en una aplicación de NCL. Las tres imágenes que representan las opciones de interacción ocupada inicialmente espacio de memoria. Debido a esto, la suma de los tamaños de los contenidos terminó 12

13 siendo muy grande, y la aplicación del dispositivo se finalizaba por falta de recursos Estudio de caso 2: Middleware Ginga-NCL en móviles Comerciales Como segunda aplicación estudiada, se tiene la ejecución de un video Matrix, en toda el área disponible del dispositivo portátil Matrix_Mobile. Esta aplicación fue desarrollada e implementada basada en el Ginga NCL, en la cual se tiene como objetivo realizar las pruebas de sincronismo de imágenes y videos. La interface de la aplicación se ilustra en la Figura 2.3. Figura2.3. Aplicación Matrix_Mobile Durante la ejecución de la aplicación, en un determinado momento, uno de los protagonistas muestra una batería. En ese momento, la aplicación reduce el tamaño del vídeo y, en el espacio restante un comercial de una batería es mostrado por un periodo de tiempo. Cuando este tiempo expira, el anuncio es eliminado y el vídeo se restaura a su tamaño original, como ilustrado en la Figura 2.4. Figura 2.4. Primer caso de Sincronismo de Aplicación Matrix_Mobile. 13

14 En otro momento, el actor se encuentra cerca de la cámara, resaltando sus gafas. En ese momento, el vídeo se reduce con el fin de proporcionar espacio para una opción de interacción 01->Interativo, que está disponible por un tiempo fijo. Después de este tiempo, la imagen se retira, el tamaño del vídeo se ha restaurado y el usuario ya no podría realizar la interacción. Este escenario se muestra en la Figura 2.5. Figura 2.5. Segundo caso de sincronismo de la aplicación Matrix_mobile. Si el usuario elige interactuar, deberá pulsar el botón 1, luego el vídeo se reducirá de tamaño y se desplegará un comercial de gafas de sol. Unos segundos después, el anuncio se retira y se restaura a su tamaño original, como ilustrado en la Figura 2.6. Figura 2.6. Tercer caso de sincronismo de la aplicación Matrix_Mobile Conclusiones Con la televisión interactiva el modo de ver la televisión va a cambiar, va a pasar de ser un dispositivo de comunicación unidireccional a uno que nos permita establecer un diálogo entre el televidente y el canal de TV, siendo uno de los beneficios la mejora en la calidad del video y audio, la optimización del ancho de banda y el ofrecimiento de nuevos servicios de interactividad. Las aplicaciones presentadas en este trabajo, tuvieron como referencia bibliográfica, las realizadas en la Pontificia Universidad Católica de Rio de Janeiro, 14

15 Brasil, la cual se encuentra desarrollando aplicaciones en dispositivos móviles utilizando el Ginga-NCL. 15

16 CAPITULO III TECNOLOGIAS DE INTERACTIVIDAD Y DE CANAL DE RETORNO 3.1. Introducción Desde un visto de vista comercial, el aspecto fundamental que diferencia la televisión digital de la televisión existente es la capacidad que tiene el televidente de interactuar con su equipo receptor utilizando un canal de retorno determinado. Esta interactividad propia de la televisión digital abre un abanico de posibilidades para el desarrollo de aplicaciones comerciales que le permitan al usuario interactuar con el equipo mediante el intercambio de información. Las aplicaciones que pueden desarrollarse son diversas desde la recepción de mensajes de alerta en caso de algún desastre natural, el ofrecer productos de compra por cada comercial que aparece en la televisión o separar una cita con el seguro social. Actualmente, los diversos estándares en Televisión Digital, se encuentran desarrollando aplicaciones, y probando las funcionalidades y beneficios de interactividad que esta tecnología ofrece. En este capítulo se presenta un estudio introductorio acerca de los aspectos tecnológicos de interactividad y canales de retorno Tecnologías de Interactividad La interactividad que realiza el televidente con el canal receptor es en base de botones de comando. Estos botones de comando son configurables en la interfaz de usuario del programa J2ME. Se están realizando estudios relacionados a la identificación de simuladores de dispositivos móviles, en la cual es posible emular aplicaciones de televisión digital Canal de Retorno El canal de retorno que existe actualmente en diferentes países que han implementado TdT, son los siguientes: GPRS, WiFi, Wi-Max. Cabe rescatar que para el manejo de cada uno de estos canales de retorno para Java resulta transparente, es decir, si el dispositivo cuenta con WiFi la interactividad se producirá vía WiFi siendo transparente para el programa Java Conclusiones 16

17 El desarrollo de aplicaciones en dispositivos móviles ha sido poco desarrollado en los países donde se brinda el servicio de TdT, lo que significa un gran reto para el proyecto en la concepción e implementación de una aplicación para dispositivos móviles. Los canales de retorno que se han utilizado en los países que implementan TdT están bastante identificados y estos son todas las redes de datos inalámbricas: GPRS, WiFi y Wimax. 17

18 CAPITULO IV INTERFACES DE USUARIOS PARA APLICACIONES 4.1. Introducción Para el desarrollo de una aplicación en dispositivos móviles los software más utilizados comercialmente son Java MicroEdition (J2ME) y Microsoft.NET Micro Framework. La principal diferencia en ambos software para el desarrollo de aplicaciones, es el precio. El primero es un software libre mientras que el segundo es un software comprable. El desarrollo de este capítulo comprende el estudio de la tecnología J2ME para equipos móviles, la arquitectura de un programa J2ME y que dispositivos electrónicos pueden ejecutar un programa J2ME. Así también, se estudiara que sistemas operativos soportan una aplicación J2ME para televisión digital Interfaces de Usuarios usando J2ME El desarrollo de una interface de usuario utilizando J2ME se realiza de dos maneras [20]: Utilizando las librerías existentes en J2ME para el desarrollo de la interfaz de usuario: En este modo de desarrollo de la interfaz grafica se utilizan las herramientas propias de J2ME. Java MicroEdition permite el uso de formularios, botones, cuadro de texto, etc. La desventaja de este tipo de aplicaciones radica en que no se explota las características de resolución de la pantalla del celular. Desarrollar la interfaz de usuario sin utilizar librerías: En este modo de desarrollo de la interfaz grafica se realiza de manera nativa, es decir explotando y manejando cada pixel de la pantalla del celular. Java MicroEdition ha desarrollado librerías que permiten manipular al máximo la resolución de pantalla del celular Desarrollo de aplicaciones utilizando J2ME El entorno de desarrollo Java es el más utilizado para las aplicaciones en móviles es Java MicroEdition. Las razones por la cual este éxito es básicamente el tema de portabilidad de Java [20]. El concepto de portabilidad radica en el hecho en 18

19 que un programa Java puede funcionar en cualquier dispositivo independiente del sistema operativo, es decir, una aplicación desarrollada en J2ME puede funcionar en celulares con sistemas operativos Linux, Windons CE, Symbian o Android. En la Figura 4.1 se ilustra las diferentes aplicaciones para cada entorno de Java. Se puede observar que para el entorno Java 2 Micro Edition (J2ME) es posible el desarrollo de aplicaciones para los receptores basados en Set-Top-Box y equipos celulares. Figura 4.1. Entornos de desarrollo Java. El desarrollo de una aplicación utilizando el programa J2ME está basado en clases. Para asegurar la portabilidad del programa J2ME se utiliza una arquitectura en jerarquía de clases. Así un programa J2ME está basado en configuración, perfil y APIs opcionales. Cada uno de estos bloques de esta jerarquía contiene un determinado número de paquetes (conjunto de clases), los cuales se complementan en el desarrollo de una aplicación. El la Figura 4.2 se detalla de manera grafica el concepto de la arquitectura de un programa J2ME. 19

20 Figura 4.2. Arquitectura de un programa J2ME A continuación se detalla cada uno de los componentes de la arquitectura de un programa J2ME: a) Configuración: Es un conjunto de clases estándar tomadas de J2SE que son la base de la programación J2ME. Además la configuración está directamente relacionada con el tipo de memoria virtual que funcionara en el dispositivo móvil. Existen dos tipos de configuraciones en J2ME: CLDC (Connected Limited Device Configuration): Limitada capacidad de memoria y procesamiento. Orientado a dispositivos de baja gama, recursos más limitados y conectividad limitada, con: Procesadores de bits 160 KB a 512 KB de memoria disponible para Java 16 MHz a 32 MHz Limitaciones de consumo (baterías) Conectividad a red (inalámbrica) Restricciones importantes en el interfaz de usuario Esta especificado en el JSR 30. Especificación CLDC 1.0: Sun proporciona una implementación de referencia de CLDC sobre la maquina virtual KVM, para todos los OS móviles Principales fabricantes de móviles la implementan en sus nuevos modelos (Nokia, Motorola, Samsung,...) CDC (Connected Device Configuration): Mayor capacidad de procesamiento y memoria. Esta configuración está orientada a dispositivos de alta gama, conectados y menos limitados con: Procesadores de 32 bits 512 KB de ROM 20

21 256 KB de RAM Conexión a red (fija) Soporte completo a la especificación de JVM Interfaz de usuario relativamente limitado Esta especificado en JSR 36. Ejemplos de esta configuración tenemos. Internet screenphones, DTV set top boxes y sistemas telemáticos de automóviles. La maquina virtual para esta configuración es llamada CVM. Cabe rescatar que JavaTV 1.0 apareció pensando en esta configuración. b) Perfil: Un perfil es un conjunto de clases Java que complementan una configuración para un conjunto específico de dispositivos. El perfil define el ciclo de vida de la aplicación, interfaz de usuario, conexiones de red, mecanismos de persistencia, aspectos de seguridad y el manejo de la memoria no volátil del dispositivo móvil. Los perfiles se especifican vía la iniciativa Java Community Process (JCP). El perfil más usado es el MIDP (Mobile Information Device Profile) sobre CLDC. Algunos perfiles para la configuración CDC son: J2ME Foundation Profile (FP): Es el perfil básico para dispositivos CDC sin interfaz gráfico. J2ME Personal Profile (PP): Es el perfil gráfico básico para dispositivos CDC. J2ME Personal Basis Profile (PBP): Este perfil es para dispositivos de red con nivel básico de presentación gráfica. En el caso de perfiles para una configuración CLDC, se tiene: J2ME Mobile Information Device Profile (MIDP): Perfil para dispositivos inalámbricos. J2ME PDA Profile: Perfil para agendas personales electrónicas. Es importante destacar que para el desarrollo de las aplicaciones en televisión digital, para dispositivos móviles, se utilizará el perfil MIDP, porque este perfil está dirigido a todos los dispositivos móviles. c) APIs opcionales: Las APIs opcionales son extensiones de los perfiles, es decir, son APIs que añaden funcionalidad específica a uno o varios perfiles, como 21

22 por ejemplo el manejo del periférico bluetooth, GPS, memoria SD, etc. Entre las APIS opcionales más conocidas se pueden mencionar: Java API para Bluetooth (JSR 82): Permite el manejo del periférico bluetooth. Wireless Messaging API (JSR 120): Permite el envío y recepción de texto o mensajes binarios. Mobile Media API (JSR 135): Permite el desarrollo de aplicaciones para procesamiento multimedia. Java TV API: Permite el desarrollo de aplicaciones interactivas para Televisión digital 4.4. Configuración CLDC El rol de CLDC es definir una plataforma estándar adaptada a los teléfonos móviles, es decir, CLDC responde a la necesidad de hacer que las aplicaciones funcionen con toda la gama de celulares. De esta manera, CLDC garantiza la portabilidad y la interoperabilidad del código entre los dispositivos móviles. Así también, la configuración CLDC define las bases comunes de programación: entradas-salidas, redes, seguridad, etc. El perfil específico depende de las funcionalidades de alto nivel: gestión del ciclo de vida de la aplicación, interface del utilizador, etc. Las características de la configuración CLDC son las siguientes: Implementación de Punto Flotante. No existencia de grupo de Tareas. No existencia de finalización de instancias de clases. Pocas clases de errores. No socialización de objetos. El perfil específico depende de las funcionalidades de alto nivel: gestión del ciclo de vida de la aplicación, interface del utilizador, etc. En la Tabla 4.1 se muestran los diferentes paquetes incluidos en la configuración CLDC [19]. 22

23 Tabla 4.1. Paquetes estándares para la configuración CLDC. Tipos Package Clases Clases sistema del java.lang Object, Class, Runtime, System, Thread, Runnable, String, StringBuffer, Throwable Clases de tipos de datos java.lang Boolean, Byte, Short, Integer, Long, Character Clases para excepciones java.lang Exception, ClassNotFoundException, IllegalAccessException, InstantiationException, InterruptedException, RuntimeException, ArithmeticException, ArrayStoreException, ClassCastException, IllegalArgumentException, IllegalThreadStateException, NumberFormatException, IllegalMonitorStateException, IndexOutOfBoundsException, ArrayIndexOutOfBoundsException, StringIndexOutOfBoundsException, NegativeArraySizeException, NullPointerException, SecurityException Clases errores de java.lang Error, VirtualMachineError, OutOfMemoryError Clases colecciones de java.util Vector, Stack, Hashtable, Enumeration Clases de calendarios y relojes Clases de excepciones Clases de excepciones Clases de entradassalidas Clases utilitarias suplementarias java.util java.util java.io java.io java.util java.lang Calendar, Date, Timezone EmptyStackException, NoSuchElementException EOFException, IOException, InterruptedException, UnsupportedEncodingException, UTFDataFormatException Inputstream, OutputStream, ByteArrayInputStream, ByteArrayOutputStream, DataInput, DataOutput, DataInputStream, DataOutputStream, Reader, Writer, InputstreamReader, OutputStreamWriter, PrintStream java.util.ramdom, java.lang.math 4.5. El perfil MIDP Un perfil MIDP son todas las APIs adicionales estándar que se han creado para aplicaciones. El conjunto de estas APIs adicionales están dirigidas al desarrollo de la interfaz de usuario y al manejo de datos en la memoria no volátil, como ilustrado en la Figura

24 Figura 4.2. Perfil MIDP. Los paquetes adicionales para el perfil MIDP son los siguientes: javax.microedition.io javax.microedition.lcdui javax.microedition.lcdui.game javax.microedition.media javax.microedition.media.control javax.microedition.midlet javax.microedition.rms Cada uno de estos paquetes está dirigido al desarrollo de interfaz de usuario, las cuales pueden servir para el desarrollo de aplicaciones simples, hasta el desarrollo de un juego multimedia. En la Figura 4.3 se ilustran todas las clases del paquete javax.microedition.lcdui. Puede observarse que en este paquete están todas las clases para el desarrollo de una interfaz de usuario estándar, tales como cuadros de textos, cuadro de comandos, formularios, etc [20]. Figura 4.3. El paquete javax.microedition.lcdui Sistemas Operativos y Niveles de Programación El hardware y el software para una aplicación Java TV en Móviles están relacionados mediante la arquitectura mostrada en la Figura 4.4. Como se puede 24

25 observar el programa J2ME deberá funcionar sobre un sistema operativo de tiempo real, lo cual es aceptable debido a que se está trabajando con señales de video. El sistema operativo facilita el trabajo de la programación en Java, haciendo que el manejo del hardware sea transparente para un programa java [21]. Figura 4.4. Jerarquía de Niveles para una aplicación TdT J2ME Conclusiones La programación para el desarrollo de una aplicación para televisión digital será más factible de realizarla en J2ME, viéndolo desde el punto de vista que es un software libre y que no se contara con el problema de obtener una licencia. Para el caso de este estudio la utilización del middleware GINGA para el desarrollo de aplicaciones en dispositivos móviles está todavía en estudio debido al problema que GINGA no es portátil (es decir solo funciona para ciertos teléfonos celulares) y eso en el caso del mercado de telefonía celular es crítico. Para el desarrollo de una aplicación en J2ME para televisión digital se deberá estudiar el API Java TV 1.1 debido a que esta API maneja todos los recursos necesarios para el desarrollo de una aplicación interactiva utilizando como canal de retorno las tecnologías de comunicación GPRS, WIFI o Wimax. 25

26 CAPITULO V SISTEMA OPERATIVO Y NIVELES DE PROGRAMACION EN DISPOSITIVOS MOVILES 5.1. Introducción En un escenario de televisión digital terrestre con receptores móviles, no se debe perder de vista que la función principal de un celular es la de comunicarse entre personas a través de una conversación. Las funciones adicionales a este principio, se encuentran en un segundo plano. En este panorama, cualquier middleware para estos dispositivos móviles debe tomar en cuenta las siguientes consideraciones: uso de la batería con bajo consumo de energía, procesamiento de memoria limitado, movilidad con proceso handoff, tamaño de display y teclado pequeño. En este capítulo, se estudiaran los principales sistemas operativos soportados por dispositivos móviles, así como sus niveles de programación soportados, relacionando las características de programación con las consideraciones impuestas los dispositivos móviles Sistemas Operativos para Móviles Windows Mobile, desarrollado por Microsoft, tiene como ventaja permitir el desarrollo de sus aplicaciones a través de las mismas herramientas usadas en la versión de Windows en computadoras. Por otro lado, este sistema y sus herramientas poseen costos de licencia. El crecimiento del mercado de dispositivos portátiles ha despertado el interés de los desarrolladores de Sistemas Operativos LINUX. Un aspecto interesante de Linux es el soporte a sistemas heterogéneos [3]. Adicionalmente, Linux posee una plataforma abierta y la mayoría de sus herramientas de desarrollo pueden ser usadas sin costo adicional. Uno de los softwares para móviles de código abierto, con gran potencial para el desarrollo de aplicaciones es el Android, basado en el kernel de LINUX con algunas librerías desarrolladas por Google, cuyas aplicaciones son programadas en Java. Entre las principales características se que pueden mencionar del Android están: 26

27 Framework de aplicaciones, permite rehusó y remplazo de componentes. Maquina virtual Dalvick, optimizada para dispositivos móviles. Navegador integrado basado en el motor Web Kit. Soporte para medios con formatos comunes de audio, video e imágenes planas (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF). Soporte a la tecnología Bluetooh EDGE, 3G y WiFi, también con limitaciones de hardware, entre algunas de sus características. Así también, existe el sistema operativo SYMBIAN, desarrollado específicamente para dispositivos portátiles, siendo un sistema robusto y se encuentra en el mercado desde Fue desarrollado con el objetivo de ser económico en el consumo de recursos, en especial memoria y batería. Además posee una plataforma abierta y las aplicaciones pueden ser desarrolladas en una serie de tecnologías diferentes, como SYMBIAN C++, Java y Flash. Aunque tiene muchos beneficios, los costos ligados a la plataforma constituyen un punto negativo. El sistema en si no es gratuito para el fabricante del dispositivo y las herramientas de desarrollo gratuitas poseen recursos limitados, a pesar de ser estables. Entre los tres sistemas operativos presentados anteriormente, SYMBIAN posee mayor disponibilidad de desarrollo para dispositivos móviles, además de ofrecer soporte a través de comunidades y foros sobre el sistema. Las principales plataformas de desarrollo del sistema operativo Symbian son la plataforma nativa y la plataforma JavaME. En la plataforma nativa, el lenguaje Symbian C++, que es basado en C++, es usado en el desarrollo de las aplicaciones. Symbian C++ es un leguaje complejo, pero permite al desarrollador tener un mayor control sobre el código de la aplicación. Facilitando, con eso la definición de las optimizaciones más sofisticadas. El desarrollo en la plataforma nativa del sistema Symbian también implica en la posibilidad del uso directo del API perfeccionado [4], y del acceso completo a los recursos de hardware. La plataforma JavaME (Micro ou Mobile Edition) es un subconjunto de J2SE [5] y fue desarrollada para atender los requisitos de los dispositivos portátiles. 27

28 La plataforma Symbian C++ ofrece algunos perfiles de desarrollo para interfaces como usuario, denominadas UIs (User Interface). Las UIs determinan las características específicas del sistema Symbian, y son asociadas a las familias de dispositivos. Una interfaz de usuario del sistema operativo Symbian es el S60, el cual se encuentra asociado a una interfaz SDK que ofrece soporte para el desarrollo de aplicaciones [4]. Para el desarrollo de una interface de usuario basado en el S60, de debe de tener en cuenta: Disponibilidad de la documentación Soporte al desarrollo Cantidad de dispositivos S60 disponibles en el mercado Pruebas en dispositivos con mayor flexibilidad y rapidez Adicionalmente, el sistema operativo Symbiam es uno de los más utilizado en Europa para dispositivos portátiles, seguido por los dispositivos BlackBerrys y luego la versión móvil de Windows. Otros sistemas operativos son Linux, PalmOS entre los más utilizados [6] Middleware para Dispositivos Móviles Middleware es una capa intermediaria entre el hardware/so y las aplicaciones. Su objetivo es esconder los detalles de la plataforma de hardware y sistema operacional para que el desarrollo de las aplicaciones sea simplificada. En el contexto de televisión digital terrestre, el objetivo del middleware consiste en permitir que las aplicaciones se ejecuten sin preocuparse por otras cuestiones, como el método de transporte utilizado. Entre los principales estándares para dispositivos portátiles [7], puede citarse el Estándar LASeR (Lightweight Application Scene Representation) [8] y [9], el Middleware BML (Broadcast Markup Language) [10] y el Giga. a) Estándar LASeR: Es un estándar para la representación multimedia de dispositivos móviles basados en codificadores MPEG-4. Entre sus principales aplicaciones en TV móvil, consiste en proveer acceso a canales de televisión e información relacionada. El estándar LASeR permite una agregación de 28

29 diferentes servicios multimedia, incluyendo interfaces interactivas, guías de programación electrónica, votación electrónica, etc. Por ejemplo, en la Figura 5.1, se ilustra la pantalla de un dispositivo móvil, el cual incluye informaciones de interactividad, una lista de canales para suscripción y propagandas financieras [8]. Figura 5.1. LASeR: Aplicación para televisión móvil interactiva. La Figura 5.2 ilustra la arquitectura del sistema LASeR. Primeramente, una aplicación, muestra para el usuario una escena SVG con una extensión de escena LASeR. Enseguida la aplicación puede ser modificada por otra escena mediante una actualización dinámica. En seguida una codificación binaria es utilizada para compresión de datos, disminuyendo los atrasos de transmisión. Finalmente, se tiene una camada de transporte para realizar el empaquetamiento y sincronismo de datos [12] y [13]. Aplicación Escenario SVG Extensiones LASeR Comandos LASeR Actualización Dinamica Codificación Binaria Audio Video Imagen Fuente. SAF Transporte Network (Red) Figura 5.2 Arquitectura del Middleware LASeR. 29

30 b) El middleware BML: en la Figura 5.3 se ilustra la arquitectura del estándar Japonés para TV Digital, el cual especifica un agente de usuario BML, que es responsable de recibir y mostrar las aplicaciones BML. El Lenguaje BML se basa en XHTML, CSS, DOM y ECMAScript [14], tecnología estandarizada por el W3C. El foco del lenguaje BML es la interacción con el usuario, y no el sincronismo entre archivos multimedia. Cualquier otra forma de sincronismo que no sea interactividad requiere ser implementada con el uso de scripts. Figura 5.3. Arquitectura del Middleware BML Los lenguajes de scripts son procedurales y poseen un poder de expresión mayor que el ofrecido por los lenguajes declarativos. Sin embargo, el uso de lenguajes procedurales son más complejos y propenso a errores. En el contexto de la TV Digital, cuando se enfrentan con la necesidad de utilizar un lenguaje procedural, el programador de la aplicación debe tener el perfil de un desarrollador de software [10]. c) Middleware Ginga: es el padrón brasilero para TV Digital, desarrollado por la Pontificia Universidad Católica de Rio de Janeiro y la Universidad Federal de Paraiba. La primera, se responsabilizo por el ambiente declarativo del Ginga. La segunda, se responsabilizo por el ambiente procedural. Una observación importante, es que aun no existen implementaciones comerciales de este middleware para dispositivos móviles, donde solo es exigió el ambiente declarativo [25]. En este panorama, el middleware Ginga define dos clases de aplicaciones, las declarativas Ginga NCL y las de procedimiento Ginga- J [26]. El uso de ambos 30

31 lenguajes es obligatorio en los terminales fijos (Set-Top-Box) y es importante mencionar, que para los receptores portátiles la utilización de Ginga-NCL es obligatorio y el Ginga-J es opcional [1]. La parte declarativa del middleware de TV Digital Brasilero, Ginga-NCL, utiliza el lenguaje NCL (Nested Context Languaje) para describir presentaciones hipermedia de TV Digital, es un lenguaje que se enfoca en el sincronismo de midias (multimedias), en el cual la interactividad del usuario es un caso particular. En NCL el sincronismo es definido por especificaciones de los relacionamientos entre estructuras que referencias contenido (objetos multimedia). NCL ofrece soporte a la adaptabilidad del contenido y de la forma como un contenido particular debe ser presentado. Una adaptación puede ser realizada con base en reglas definidas por la aplicación, por características del dispositivo receptor o por el contexto de presentación (perfil del usuario, localización, etc). El soporte de múltiplos dispositivos puede ser especificado de forma transparente en la definición del layout de la aplicación, donde el programador puede definir el dispositivo de exhibición deseado [27]. NCL también ofrece un gran soporte a la reutilización, tanto de objetos multimedia como los elementos que especifican el diseño de la aplicación. Como en NCL el contenido es separado de los problemas de sincronismo, la reutilización es siempre de manera trivial [16]. El soporte a la edición en tiempo de exhibición es ofrecido a través de las especificaciones de una API de edición. Esta API define comandos que pueden ser transportados en metadatos de sincronización o asociados por código procedural. Los comandos pueden ser enviados por el proveedor de contenidos, obtenido a través de un canal de retorno, o de las aplicaciones residentes. Los comandos definidos permiten la edición, supresión o alteración de la estructura definidas por el lenguaje [17]. La Figura 5.4 ilustra la arquitectura modular del Ginga-NCL para dispositivos portátiles, que es dividida en dos subsistemas lógicos: la máquina de presentación del Ginga-NCL y el Núcleo Ginga. 31

32 Maquina de Presentación Ginga-NCL Conversor Schedule Layout Manager Administrador Adm. de Exhibidores Formateador de Bases Privadas Adm. de Contenido NCL Núcleo Ginga Procesador de Datos Administrador de Contenido Adm. de Actualizaciones Persistencia Maquina Lua Administrador Sintonizador 1-seg Transporte Grafico Capa de Abstracción Librerías, Sistema Operativo y Hardware Adaptadores Exhibidores Figura 5.4. Arquitectura Ginga-NCL para Dispositivos Móviles En el núcleo Ginga, el modulo de Sintonizador es responsable de recibir el contenido de televisión digital para portátiles transmitido por proveedores de contenido. Las aplicaciones interactivas pueden llegar al dispositivo portátil multiplexadas en el contenido, o por otra interface de red (por ejemplo, el canal de datos ofrecidos por el operador de telefonía móvil, conexión bluetooth o IEEE , etc.). En el primer caso, la aplicación es obtenida a través de un tratamiento efectuado por el modulo de procesador de datos, sobre el contenido recibido. En el segundo caso, un componente de transporte es creado para controlar los protocolos e interfaces de la red y atender la demanda de la presentación de la maquina contenido y aplicaciones Conclusiones Sistemas operaciones basado en Linux, a pesar de ser códigos abiertos, en diversas referencias bibliográficas manifiestan limitaciones con respecto a los recursos cuando se tiene un sistema operativo Linux integrado. EL middleware Ginga para TV digital ofrece soporte para el desarrollo tanto de lenguajes declarativos Ginga-NCL y procedurales Ginga-J. El Ginga-NCL y Ginga-J son obligatorios para equipos fijos (Set-Top-Box). Para equipos móviles el Ginga-NCL es obligatorio y el Ginga-J es opcional. 32

33 Existen pruebas de interactividad desarrollados en base de al Middleware Ginga-NCL sin embargo la gran mayoría han sido en implementadas a nivel de laboratorio e investigaciones académicas. 33

34 6.1. Introducción CAPITULO VI EQUIPOS MOVILES BASADOS EN EL ESTANDAR ISDB-T One-seg es un servicio de transmisión de audio y video digital para dispositivos móviles. Este servicio forma parte del estándar japonés ISDB-T (Integrates Services Digital Broadcasting - Terrestrial), adoptado recientemente por el Perú. De este escenario, la Norma Legal RM MTC-03, intitulada Aprueban Especificaciones Técnicas Mínimas de los receptores de Televisión Digital Terrestre del Estándar ISDB-T (Integrated Services Digital Broadcasting-Terrestrial), determina las especificaciones mínimas para los receptores one-seg que serán utilizadas en el Perú [18], las cuales son presentadas en la Tabla 6.1. Tabla 6.1. Especificaciones mínimas para receptores one-seg. Nº Parámetro Especificación 1 Modulación One-seg :QPSK y 16QAM 2 Perfiles y niveles del vídeo One-seg: H.264/AVC L1.3 3 Formatos de videos One-seg SQVGA 160x120 (4:3) SQVGA 160x90 (16:9) QVGA 320x240 (4:3) QVGA 320x180 (16:9) Y CIF 352x288 (4:3) 4 Tasa de cuadros (frame rate) One-seg: 5fps, 10 fps, 12 fps, 15 fps y 24 fps 5 Perfiles y niveles del audio One-seg: LC L2 y HE-AAC+SBR+PS 6.2. Equipos móviles basados en el Estándar ISDB-T El sistema ISDB-Tb usa la banda UHF con frecuencias que van desde los 470 a los 860 MHz. Dentro de este espectro, con un ancho de banda de 300 MHz. En este ancho de banda son divididos 13 segmentos, de los cuales 12 son utilizados por estaciones de televisión para transmitir contenidos en HD, y 1 segmento para transmitir señales para equipos móviles. 34

35 One-seg en ISDB-T utiliza video codificado en H.264, transportado en formato MPEG-2, con 30 cuadros por segundo. Para verificar que equipos móviles soportan el estándar ISDB-T, se visitaron las páginas electrónicas de los fabricantes que venden equipos en el Perú, tales como: LG Sony Ericson Sharp Samsung Nokia Receptor USB a) Móvil LG KB775 Características del LG KB775: Cámara de 3 Mega Pixels Pantalla 3 sensible al tacto MP3 Player Radio FM Bluetooth Estéreo Sintonizador ISDB-T Soporte para Micro SD Java (2.0) MMS, SMS, EDGE/GPRS. 35

36 Figura 6.1. Celular móvil LG KB775. b) Sony Ericson Modelo Bravia SO930iTV El SO930iTV es un teléfono celular de la gama de televisores de Sony, Bravia. El móvil cuenta con una pantalla Widescreen de 3 pulgadas (240 x 432 píxeles), y la mejor función de este celular, es la posibilidad de sintonizar canales de televisión. Cuenta con una memoria de 2GB en la cual le es posible almacenar programas de TV, además incluye una cámara de 2 megapíxeles. Este equipo es solamente comercializado en el mercado Japonés. Figura 6.2. Celular Sony Ericsson SO930iTV Entre otras características el SO93oiTV tiene: Grabación TV en una tarjeta de memoria de 2GB. Cámara de 2 megapíxeles. Pantalla WQVGA TFT de 3 pulgadas y 240 x 432 píxeles. Disponible Solo para Japón. 36

37 Figura 6.3. Celular Sony Ericsson SO930iTV Figura 6.4. Celular Sony Ericsson SO930iTV c) Sharp SH-04A NTT DoCoMo presentó en el mercado de Japón el nuevo teléfono celular llamado Sharp SH-04A, el cual cuenta con las siguientes especificaciones técnicas: Pantalla de 3.5 pulgadas ( pixeles) Slot para tarjeta de memoria microsd/microsdhc (hasta 8GB) GPS Bluetooth Sintonizador 1Seg TV Cámara de 5.2 megapixeles Teclado QWERTY Full Sistema Operativo basado en Symbian OS 37