En resumen, el decodificador debe recoger la información del usuario para enviarla hacia el servidor por el canal de retorno, a través del router que está conectado a un puerto del STB. Por tanto, el STB requiere de un API que posibilite las mediciones, de espacio en memoria para almacenar los datos (esto es opcional solo si se guardan los datos en el STB) y de un canal de retorno para enviar la información al lugar donde se van a procesar los datos.
La información a enviar desde el STB al centro de procesamiento de dichos datos debe estar estructurada y contener los campos que se muestran a continuación:
1. Conocer el estado del receptor:
El requisito que se le solicita a este elemento es la medición del estado del STB: apagado o encendido, pues es este estado quién marque el inicio o final de la recogida de la información de los servicios. La única forma en que se podría detectar dicho estado sería mediante la consideración de que, en el caso de no haber respuesta del STB a la hora definida, se considere como apagado, y, en caso contrario, se considerará como encendido. Para este elemento no es necesario enviarlo, se puede prescindir de él.
Para esta función, de proteger la información, se puede agregar un campo corrector de errores (chequeo de suma) pero se propone para estudios futuros el desarrollo e incorporación en la estructura de dicho campo porque este solo sería útil cuando el STB cuente con la API para extraer sus datos. Pero como una “opción” de proteger de los datos, se decide enviar hacia el servidor caracteres que corroboren los campos específicos con información real y útil (campo Flags). Por tanto, debe haber un dígito 0 o 1 semejante a una bandera que corresponda a cada elemento; donde 0 descartamos ese campo y 1 se extraer la información de dicho campo para guardarla en la base de datos creada en el servidor (el campo Flags se compone de 10 caracteres). Esto mejora la eficacia en el procesamiento de la información pues el servidor solo se dedicaría a validar los datos en los campos de relevancia especificados.
3. Determinar la fuente de señal del receptor de televisión
Debe poder detectarse si el STB visualiza DTV o si la señal procede de un dispositivo externo como una memoria flash. En caso de que no esté viendo DTV los restantes elementos se descartarían porque estos son para medir el comportamiento de los usuarios con la señal de televisión digital. Esto está definido por un dígito: que toma valor 1 cuando está sintonizada DTV y valor 0 cuando se visualiza un dispositivo externo.
4. Brindar la identificación del receptor
Se debe enviar el modelo del receptor, correspondiente a cada marca, con el fin de conocer la especificidad del cálculo del valor mencionados en el elemento anterior. Para este se necesitan diez caracteres como se explica en el epígrafe 2.1.2.
5. Proporcionar las características de la señal recibida por el STB mostrado en el epígrafe 2.2
Para SSI se necesitan tres caracteres ver epígrafe 2.1.1
Para SQI se necesitan tres caracteres ver epígrafe 2.1.2
Para la ubicación geográfica del receptor se necesitan doce caracteres correspondientes a la dirección IP asignada por el proveedor de servicios al usuario como se menciona en el epígrafe 2.2.
6. Recoger información sobre los contenidos visualizados:
Encargado de medir los contenidos audiovisuales procedentes del canal de difusión como el canal y la información temporal (franja horaria) de dicha visualización. Así mismo, se debe medir la información adicional asociada al evento visualizado.
La mayoría de los datos de un determinado evento puede obtenerse cruzando la información del servicio consumido en la medición con una base de datos que recoge toda la información sobre los eventos programados en cada uno de los servicios. De esta manera se puede recoger las características concretas como el nombre del programa, clasificación u horario sin necesidad de recoger esa información en el
receptor. Esto quedó demostrado en el epígrafe 2.3 donde expresa que se necesitan seis caracteres para la franja horaria y tres caracteres para el canal virtual.
7. Auditar las aplicaciones/servicios interactivos
Deberá existir un elemento encargado de suministrar toda la información de interés relativa tanto a los servicios interactivos, como al uso que se hace de ello. Entonces al elemento anterior se le adiciona un campo de dos cifras para cuando el usuario vaya a votar, para este caso en específico.
Mientras que para otras aplicaciones interactivas necesitan habilitar campos para ellas como es en el Caso de Estudio 4 donde se necesitan enviar cinco caracteres correspondientes a la lectura del contador y seis caracteres para la identificación de dicho contador. Además para el Caso de Estudio 5 se reserva un campo de dos dígitos (debe estar entre el uno y el nueve para que sea válido) correspondiente al servicio que se quiere solicitar.
Todos los elementos anteriores forman la estructura de datos que debe enviar el STB hacia el servidor, en la Figura 2.10 se muestra el formato de dicha estructura.
Figura 2.10: Estructura que debe enviarse desde el STB hacia el servidor.
Además de la API que requiere el STB para extraer la información a enviar, se necesita de un programa o protocolo de la capa de aplicación del protocolo de comunicación TCP/IP que gestione la transmisión de la estructura datos. El programa mencionado anteriormente puede basarse en diferentes modelos de flujo como peer to peer (de igual a igual) donde los nodos actúan simultáneamente como clientes y servidores respecto a los demás nodos de la red; o el modelo cliente-servidor donde hay un nodo que provee de recursos o servicios, llamado servidor, y nodos demandantes de esos servicios, llamados clientes.
Para el escenario que se trata en este estudio se entiende que el modelo de flujo cliente-servidor es el más adecuado a seguir, como se menciona en el epígrafe 2.1. Debido a las ventajas que brinda este modelo en un sistema con multiusuario distribuidos a través de una red; como es el caso de la DTT interactiva donde todos los hogares que cuenten con STB van a ser peticiones como clientes con pequeñas tramas mientras que un servidor de servicios interactivos responderá con datos de gran tamaño.
Para la elaboración de los experimentos existen disímiles alternativas como sistema operativo de la Raspberry Pi; entre las que se encuentran Raspbian, OpenELEC, Kodi, Arch Linux ARM, Pidora, Flags Fuente
Señal
Modelo STB
SSI SQI IP Hora Canal Virtual Votar Servicios de acceso ID Contador Lectura Contador 10 1 10 3 3 12 6 3 2 2 6 5
Raspbmc, RISC OS [79]. Entonces de acuerdo al sistema operativo que se defina en la creación del programa se tendrán varias opciones para escogerse como lenguaje de programación a utilizar; algunos de estos son C, C++, Python, Java, JavaScript, Bash [80]. La implementación práctica de cada uno de estos elementos seleccionados será discutida en el capítulo 3.
2.8 Conclusiones Parciales
En los sistemas de televisión digital modernos, se considera que todos los servicios de acceso están disponibles solo a petición de los usuarios finales interesados. Las personas que se beneficiarían de los servicios de acceso deberían poder seleccionarlos (de una manera fácil y amigable). Para las personas que no desean hacer uso de un servicio de acceso específico, debe permanecer imperceptible. En otras palabras, los servicios de acceso deberían estar cerrados y solo visibles / audibles cuando se seleccionen. En fin, se va a recurrir a estudios estadísticos para conocer datos sociales que permitan incrementar y perfeccionar los servicios de la DTT brindados por los proveedores y para los proveedores. Tras realizar un análisis detallado de los casos de estudio, donde se describen escenarios de posible interés en el marco de los primeros pasos de la DTT interactiva en el contexto nacional, se concluye que la información a enviar desde el STB al centro de procesamiento de dichos datos debe estar estructurada y contener los campos que permitan proteger los datos, mostrar la fuente de señal del receptor de televisión, identificar el modelo de STB, caracterizar la señal DTV recibida, recoger la información sobre los contenidos visualizados, auditar las aplicaciones/servicios interactivos que brindan dichos contenidos. Además se presentan las distintas opciones de canal de retorno: tecnología WiFi, ADSL o la comunicación GSM posibles a utilizar en dichos escenarios para la transmisión de la estructura de los datos; de acuerdo a las oportunidades que ofrece tanto la empresa ETECSA como el hardware de la plataforma Raspberry Pi.