Índice

Pág.

El sistema DAB. Descripción general.............................................. 2

Presente y futuro de DAB................................................................ 3

Instituciones que trabajan en DAB.................................................. 4

RO MOT

Descripción general................................................................... 5

Estructura................................................................................... 6

Parámetros................................................................................. 7

Modelo de un decodificador MOT y sus interfaces................... 8

Mecanismos de transmisión....................................................... 10

Codificación............................................................................... 12

Transmisión de un conjunto de ficheros.................................... 14

Bibliografía y documentación.......................................................... 15

El sistema DAB. Descripción general

DAB, son las siglas de Digital Audio Broadcasting (Radiodifusión de Audio Digital). También se le conoce con el nombre de sistema Eureka 147, pues fue este consorcio el encargado de desarrollar el estándar. Podemos considerar este sistema como el avance más importante en tecnología radio desde la introducción de la radio FM estéreo.

Es capaz de proporcionar de manera eficiente radiodifusión digital multiservicio de gran calidad, para receptores móviles, portátiles y fijos usando únicamente una antena no direccional. Puede funcionar en cualquier frecuencia entre 30 MHz y 3 GHz para receptores móviles (más alta para la fija) y puede usarse en redes terrestres, por satélite, híbridas (satélite con complemento terrestre) y de difusión por cable.

El sistema DAB está pensado para utilizarse de una manera flexible. Permite acomodar diferentes velocidades de transmisión y multiplexar digitalmente muchos tipos de fuentes y canales con diferentes opciones de codificación de los programas, de los datos asociados a éstos y de servicios de datos adicionales.

De manera análoga a cuando entramos en un multicine donde se exhiben varias películas y elegimos una de ellas, podemos entrar en un múltiplex DAB y seleccionar varios programas de audio o servicios de datos, pues el sistema permite multiplexarlos para formar un bloque de 1.5 Mbit/s y ser emitidos juntos, obteniéndose el mismo área de servicio para todos.

Las principales ventajas que ofrece DAB sobre la radiodifusión tradicional son las siguientes:

• Eficiencia en la utilización del espectro y la potencia. Se consigue intercalando señales de varios programas junto a una especial característica de reuso de frecuencia (Single Frecuency Network, SFN) que permite a las redes de difusión extenderse, virtualmente sin límite, gracias a transmisores adicionales que llevan a cabo la misma multiplexación en la misma frecuencia. Utiliza un único bloque para una red internacional, nacional, regional o local con transmisores de baja potencia.

• Mejoras en la recepción. La información transmitida se reparte tanto en el dominio del tiempo como de la frecuencia de manera que los efectos de la distorsión del canal y la atenuación puedan ser eliminadas de la señal recibida en el receptor, incluso cuando trabaja en condiciones de fuerte propagación multitrayecto (debida a la reflexión en edificios y montañas). Para lograrlo, se codifican y se multiplexan las señales en OFDM (Orthogonal Frequency División Multiplexing), distribuyendo la información entre un elevado nº de frecuencias. Para proteger la señal de errores de transmisión el sistema se vale de 2 técnicas llamadas UEP y EEP (Unequal/Equal Error Protection). La primera es la preferible, pues ofrece más protección para los datos más críticos.

• Calidad de sonido. Podemos llegar alcanzar una calidad equivalente a la de un CD gracias al layer II del estándar MPEG Audio (también conocido como MUSICAM). Este sistema aprovecha el efecto de enmascaramiento que se produce debido a las características psicoacústicas del oído humano, ya que éste no es capaz de percibir todos los sonidos presentes en un momento dado, y por tanto no es necesario transmitir los sonidos que no son audibles. De esta forma eliminamos la información redundante. Típicamente el múltiplex contiene 6 programas de audio estéreo de gran calidad (192 kbps) usando el estándar MPEG-1 Audio, además de servicios adicionales.

• Flexibilidad. Los servicios pueden estructurarse y configurarse dinámicamente. Por ejemplo, una emisora de radio durante un programa donde se debate o dialoga puede emitir usando una velocidad baja (con 64 o 96 kbps es suficiente), ocupando un ancho de banda pequeño, mientras que a otras horas puede emitir audio estéreo con velocidades mayores (128 o 192 kbps) y por lo tanto con más ancho de banda.

• Servicios de datos. Junto a la señal de audio se transmiten otras informaciones:

• Canal de información. Transporta la configuración del múltiplex, información de los servicios, fecha y hora, información del tráfico, avisos de emergencia, etc.

• Datos asociados al programa (PAD). Se dedican a la información directamente relacionada con los programas de audio: títulos musicales, autor, texto de las canciones en varios idiomas. La capacidad del PAD es ajustable (mínimo de 667 bit/s con MPEG-1 o 333 bit/s con MPEG-2)

• Servicios adicionales. Por ejemplo el envío de imágenes y textos a tableros de anuncios electrónicos, incluso vídeo. Puede ofrecer Acceso Condicional (CA) para servicios de pago aunque la administración específica del subscriptor no forma parte del estándar DAB.

2. Presente y futuro de DAB

El sistema DAB supone una auténtica revolución respecto a la tradicional radiodifusión pues ésta es analógica y nunca llegaría a ofrecer las ventajas del sistema DAB. Sin embargo, precisamente el hecho de suponer un gran cambio (infraestructuras, software, preparación técnica...) junto otros factores pueden frenar su implantación a nivel mundial. Quizá el mayor problema sea la falta de apoyo de la NAB (Asociación Nacional de Emisores de Estados Unidos). Ésta argumenta a su favor la falta de espacio radioeléctrico, entre otras razones. El respaldo de Estados Unidos a este sistema debería ser su principal garantía de futuro.

El primer país donde comenzaron las emisiones regulares de radio digital fue el Reino Unido en 1995. Poco a poco el resto de países europeos están apoyando este sistema y prácticamente en la mayoría de ellos se puede recibir DAB aunque en algunos todavía esté en fase experimental. En julio del año 2.000 Suecia era el país con una mayor red de transmisión DAB llegando al 85 % de la población. En Noruega llegaba al 35 %, en Holanda al 50 %, y en Bélgica al 70%.

Mapa de la implantación del sistema DAB en abril de 2001.

La situación en España actualmente es buena, pues más del 30% de la población puede recibirla. Se debe alcanzar al 50 % de la población antes finalizar el mes de junio de 2001. Las primeras radiodifusiones digitales comenzaron en abril de 1998 en Madrid, Barcelona y Valencia. Actualmente también existen servicios en el País Vasco, Cataluña y Galicia.

En Madrid y Barcelona, se están emitiendo actualmente los múltiplex denominados MF-1; MF-2 y FU-E. Las competencias se reparten entre Gobierno central y las Comunidades Autónomas.

3. Instituciones que trabajan en DAB

El sistema DAB, como puede deducirse de lo expuesto anteriormente, fue concebido por europeos. Los primeros trabajos sobre DAB aparecieron en Alemania, en el Institut für Rindfunktechnik en el año 1981. Posteriormente, en 1987, se formó el proyecto Eureka 147 en el que han contribuido emisoras, centros de investigación, operadores de redes y firmas de electrónica de consumo. El nº 147 proviene de que resultó ser, después de mucho tiempo, el 147º proyecto técnico.

El consorcio Eureka 147 es la principal institución sobre DAB, pues fue quién lo creo y quién sigue desarrollando estándares que lo complementan y mejoran. El sistema DAB ha sido el único que la UIT (ITU en inglés) ha reconocido a nivel mundial, a pesar de sus rigurosos requerimientos. La Unión Internacional de Telecomunicaciones es la principal organización a nivel mundial en el campo de las telecomunicaciones y la mayor parte de los países forman parte de ella.

El World DAB Forum (Foro Mundial sobre DAB) se dedica, según sus propias palabras, a convertir el sistema DAB -una brillante logro de la ingeniería- en un éxito comercial a nivel mundial. Trabaja ayudando en la cooperación internacional entre operadores de red, emisoras, gobiernos, fabricantes, etc. Como el trabajo del Consorcio Eureka 147 ha llegado casi al final, perfeccionando ahora el sistema DAB, lo apropiado sería que Eureka 147 se fusionase en el World DAB Forum en el futuro.

European Committee for Electrotechnical Standardization

Es la organización europea que se encarga de los estándares sobre electricidad y electrónica. Varias especificaciones de Eureka 147 ya han sido aprobadas por esta organización.

ETSI (Instituto Europeo de eStándares de Telecomunicaciones) .

Es una organización sin ánimo de lucro cuya misión es producir los estándares de telecomunicaciones que serán utilizados durante décadas en Europa y el extranjero. Esta institución, la más importante en el campo de las telecomunicaciones en Europa, emite sus propios estándares y aprueba los que han elaborado otras organizaciones, como por ejemplo el consorcio Eureka 147.

El documento que vamos a tratar, Rules of Operation for the Multimedia Object Transfer Protocol, fue presentado al ETSI en marzo de 2000. Se encuentra en trámite de aprobación por el ETSI y ya está casi listo para su estandarización.

4. RO MOT

Digital Audio Broadcasting System (DAB); Rules of Operation for the Multimedia Object Transfer Protocol.

Borrador ETSI TR 101 497 v.1.1.1

4.1. Descripción general

MOT es un protocolo de transporte para la transmisión de contenido multimedia en canales de datos DAB a varios tipos de receptores con capacidades multimedia.

Hay muchas posibilidades para transmitir información que están incorporadas en el mecanismo común de transporte para los diferentes canales de datos de DAB, de tal manera que el acceso al contenido multimedia está unificado dentro del sistema DAB.

MOT asegura interoperabilidad entre los diferentes servicios de datos y tipos de aplicación, los diferentes dispositivos receptores y los equipos de diferentes fabricantes.

El propósito del protocolo MOT es transmitir objetos de longitud finita de una fuente de información (un proveedor de contenidos o servicios) a un destino (un terminal).

En esta figura podemos ver las entidades MOT:

Las ventajas del protocolo MOT son:

• No aplica restricciones al contenido que pueda ser transmitido.

• La segmentación y transmisión de paquetes es transparente a la aplicación del usuario.

• El estándar MOT existente puede ser ampliado de manera que sea compatible con el anterior.

Hay que señalar que el protocolo MOT se ocupa del nivel de transporte y no del nivel de aplicación, aunque contiene información básica de la administración de objetos y de la presentación del contenido multimedia. Tampoco se ocupa del direccionamiento de los receptores ni del acceso condicional (CA).

El tamaño de los objetos que pueden ser transmitidos usando MOT está limitado por el tamaño máximo del cuerpo que puede calcularse así:

TamañoMáx=min ((máx. cuerpo de datos por grupo de datos MSC)*(máx. nº de segmentos por cuerpo), máx. TamañoCuerpo (BodySize) señalado en la cabecera MOT)

La limitación real es finalmente el primer término que es igual a 255 MBytes.

El tamaño de cualquier información que pudiera ser llevada en la cabecera está limiteada por el tamaño del campo TamañoCabecera (HeaderSize) que va de 8 Kbytes a 1 Byte.

Los métodos de transmisión DAB que puede utilizarse para transportar objetos MOT son el modo paquete y el PAD (Datos Asociados al Programa).

4.2. Estructura

Ahora vamos a describir las diferentes operaciones necesarias para transmitir un archivo o un conjunto de archivos (por ejemplo un directorio) en formato MOT sobre DAB. El primer paso en el proceso es identificar el archivo y crear la cabecera MOT. Esta contiene tanto la identificación pura del fichero como la información adicional. El fichero o archivo está referido como el cuerpo MOT. En esta etapa la cabecera y cuerpo MOT corresponden a un objeto MOT, que ya está listo para su segmentación.

La estructura menos común para los dos diferentes mecanismos de transporte (Modo paquete y X-PAD) son los grupos de datos MSC (Canal de Servicio Principal). La cabecera MOT y el cuerpo son transportados en diferentes tipos de grupos MSC y por lo tanto la segmentación será aplicada independientemente sobre la cabecera y el cuerpo. El cuerpo MOT será separado en segmentos de igual tamaño y el último tendrá los bytes restantes. El tamaño de los segmentos de la cabecera y el tamaño de los segmentos del cuerpo son independientes igual que el tamaño del último segmento de la cabecera y el último segmento del cuerpo.

Se toman las siguientes consideraciones para realizar un segmentación: minimizar la cabecera, proveer robustez a la transmisión y facilitar la administración de los segmentos en el decodificador de datos DAB.

Proceso de segmentación para un objeto MOT. El proceso para segmentar un directorio es similar.

Este proceso se considera dentro del nivel de transporte. Después, en el nivel de red, se formarán paquetes de dos maneras diferentes: modo paquete (Packet Mode) o X-PAD, es decir, en grupos de datos X-PAD.

4.3 Parámetros

Parámetros de la cabecera básica

La cabecera básica obligatoria contiene importante información sobre el cuerpo. TipoContenido y SubTipoContenido normalmente deciden si el objeto será procesado o descartado. Los parámetros TamañoCabecera y TamañoCuerpo sirven de ayuda para comprobar la integridad del objeto y la memoria requerida.

El campo TamañoCuerpo (BodySize) tiene 28 bits e indica el tamaño total del cuerpo del objeto en bytes. Si está relleno de unos (0xFFFFFFF) es que se desconoce el tamaño.

El campo TamañoCabecera (HeaderSize) ocupa 13 bits que indican la longitud total de la cabecera (incluida la cabecera de extensión) en bytes. El tamaño mínimo es 7, cuando solamente la cabecera básica está presente.

Vídeo	000100
Transporte MOT	000101
Sistema	000110
Tabla propietaria	111111

En el campo TipoContenido se indica la categoría del contenido del cuerpo. Hay 8 tipos

Datos generales	000000
Texto	000001
Imagen	000010
Audio	000011

El campo SubTipoContenido es bastante flexible y nos indica el tipo exacto de contenido que lleva el cuerpo. Podemos transmitir tanto tipos MIME (descripción multimedia muy utilizada en Internet para los e-mails) como documentos HTTP.

Parámetros de la cabecera de extensión

Todos los parámetros consisten en ParamId (identificador de parámetro), una indicación del tamaño (DataFieldLength) y por supuesto, el ValorCampo (DataField).

La etiqueta TiempoCreación (CreationTime) es la marca de la hora / fecha del contenido del cuerpo MOT. Puede usarse por proveedor de contenidos / servicios para mantener un registro exacto durante las transmisiones.

Ningún objeto MOT será presentado antes de empezar su tiempo de validación (StartValidity). Si un objeto se recibe mucho antes de su tiempo StartValidity, el decodificador MOT puede quitarlo de la memoria en el caso de que tenga poca. No está permitido simultáneamente transmitir dos versiones del mismo objeto. Hay sólo UNA versión de un objeto identificado en NombreContenido al mismo tiempo.

Análogamente, ningún objeto será presentado después de tiempo de expiración (ExpireTime). En este momento, cualquier objeto presente será eliminado del display del terminal y de la memoria. Un ExpireTime con valor Now (ahora) implica que el objeto se invalida inmediatamente. El uso de Now sólo se permite para actualizar la cabecera para borrar un objeto y eliminar su presentación.

El parámetro TriggerTime se utiliza para señalar en qué momento debe empezar la presentación de un objeto. Si lleva el valor Now significa que este objeto será presentado inmediatamente después de la recepción. Este campo puede ser muy útil para, por ejemplo, lanzar al mismo tiempo una imagen animada y su correspondiente sonido.

El NúmeroVersión (VersionNumber) de un objeto debe incrementarse sólo si el cuerpo no es idéntico al cuerpo del último objeto MOT con el mismo NombreContenido. Es decir, este campo permite actualizar objetos de manera eficiente en el decodificador MOT.

Podemos ayudar al decodificador en la administración de su memoria con el parámetro Prioridad (Priority) que le aconsejaría a decidir que objetos mantener o quitar de ella.

Una etiqueta importante es NombreContenido (ContentName) pues identifica a todos los objetos MOT. Si un objeto es recibido con el mismo NombreContenido, reemplaza al antiguo. Este parámetro es obligatorio para todos los objetos aunque curiosamente no está en la cabecera básica.

Además podemos tener otros parámetros como DescripciónContenido (ContentDescription) para llevar una descripción del contenido que pueda ver el usuario; Etiqueta (Label) para nombrar el objeto con una cadena de caracteres; DistanciaRetransmisión (RetransmisiónDistance) que tiene un significado similar a Prioridad; o GrupoReferencia (GroupReference) cuyo significado aún está por definir.

4.4 Modelo de un decodificador MOT y sus interfaces

El modelo describe la funcionalidad de un decodificador de datos MOT en sus diferentes niveles incluyendo las interfaces en el receptor DAB (demultiplexador conjunto DAB) y el terminal. Veamos una figura con la descripción general:

Nivel de red

En el modo paquete, la dirección del paquete debe usarse para identificar el servicio en particular dentro del subcanal. La validación de cada paquete se verifica evaluando el CRC (Suma de comprobación) del paquete. En el modo X-PAD, el tamaño del grupo de datos MSC viene del indicador Tamaño (Length) del grupo de datos inmediatamente precedido del comienzo del grupo de datos MOT.

Nivel de grupo de datos

La validación de cada grupo de datos MSC se verifica evaluando su CRC. El campo de datos del grupo MSC contiene un segmento completo (incluyendo la cabecera de segmentación con los campos RepetitonCount y SegmentSize). El correspondiente número de segmento y el TransportId los aporta la cabecera de sesión del grupo de datos.

Nivel de segmentación y nivel de objetos

Un decodificador de datos MOT está formado por dos partes: la unidad de reensamblaje que reensambla cabeceras, cuerpos y directorios MOT; y el administrador de objetos que controla a la unidad de reensamblaje, guardando los objetos recibidos y maneja las peticiones de la aplicación del usuario. Es necesario explicar los tipos de grupos: tipo 3 son de cabecera MOT, tipo 4 son los cuerpos MOT, tipo 5 son un cuerpo MOT y los parámetros CA, tipo 6 son directorios MOT y tipo 1 son mensajes CA. CA es el Acceso Condicional, es decir, servicios de pago.

Se describen, además, dos modos de operación para el decodificador: el modo cabecera MOT en donde son procesados tanto cabeceras como cuerpos, y el modo directorio MOT que procesa directorios y cuerpos. Si un flujo de datos contiene tanto cabeceras como directorios, el decodificador deberá trabajar en los dos modos. Tanto la unidad de reensamblaje como el administrador de objetos están en el mismo modo.

La unidad de reensamblaje continuamente evalúa los grupos de datos que llegan. De estar preparada para que muchos objetos se transmitan aplicando intervalos, por lo tanto se codifican casi en paralelo.

Esta unidad mantiene una lista con los TransportId de las cabeceras MOT que se envían al administrador de objetos para que sepa que el resto de cabeceras con el mismo TransportId sean descartadas. Si el administrador de objetos MOT quita una cabecera MOT de su memoria se lo dice a la unidad de reensamblaje. Entonces ésta eliminará este TransportId de su lista y continuará aceptando cabeceras MOT con sus TransportId.

El modo directorio MOT es similar al anterior. El reensamblaje de cuerpos MOT es independiente del modo en que esté la unidad de reensamblaje. Si el administrador pide un cuerpo, la unidad obtiene una petición, indicando que los cuerpos están siendo reensamblados. La petición incluirá el TransportId y el tamaño de los cuerpos y quizá también el TamañoSegmento (si se da en un directorio MOT). La unidad de reensamblaje puede entonces asignar memoria para los cuerpos requeridos.

La unidad de administración almacena objetos y permite que la aplicación los pida, por ejemplo, a través de su NombreContenido o por la etiqueta MOT. Intenta reducir el tiempo de acceso e incluye algunas estrategias de caché. Evalúa los parámetros MOT y hace que estos parámetros estén disponibles a la aplicación del usuario. Si un objeto expira debido al parámetro ExpireTime, se quita de la memoria y se advierte a la aplicación de esto.

Nivel de aplicación

El nivel de aplicación pide objetos al decodificador MOT y los presenta. La especificación del nivel de aplicación de usuario no es parte de MOT.

4.5 Mecanismos de transmisión

Cuando transmitimos datos en un sistema de difusión, el proveedor de servicios siempre tiene que tener en cuenta que el terminal puede perder datos debido a que el receptor se apague, no tenga señal, o sintonice otro servicio; o a una mala recepción debida a las condiciones del canal radio (bits erróneos).

MOT usa algunos mecanismos que permiten al receptor recobrar grupos de datos perdidos y objetos para asegurar un recepción correcta: repetición en el nivel de grupo de datos, repetición en el nivel de objetos, retransmisión de objetos e inserción de cabeceras MOT.

Los errores de transmisión pueden causar que el receptor falle en la decodificación de los datos, por eso se recomienda usar uno o más de los cuatro mecanismos mencionados para asegurar la recepción, aunque ello baje la tasa de bits normal.

MOT permite otro mecanismos para permitir la transmisión / recepción de objetos en paralelo: intercalado de objetos en un flujo MOT.

Podemos realizar una transmisión tanto cíclica como no cíclica. La transmisión no cíclica se usa normalmente cuando el objeto se necesita sólo durante un periodo limitado de tiempo, por ejemplo, una diapositiva. En una transmisión no cíclica de un objeto con repeticiones sólo los receptores sintonizados con el flujo MOT durante la transmisión pueden, bajo buenas condiciones de recepción, recibir y guardar el objeto. Si un receptor sintoniza después de está transmisión no cíclica, le será imposible recibir los datos.

Este problema se lo resuelve una transmisión cíclica. Este tipo de transmisión está destinada para aplicaciones de usuario que necesitan tener objetos disponibles en el terminal durante mucho tiempo. Si el terminal solicita un objeto MOT que ya no está en memoria, tiene que esperar al próximo ciclo. Un ejemplo sería un aplicación en un sitio Web de difusión. Cada objeto se transmite muchas veces de manera cíclica con un período entre cada transmisión. También podemos, dentro de un ciclo, repetir el mismo objeto (podemos también actualizarlo). Veamos las diferencias con una transmisión no cíclica:

repetición última repetición

Transmisión no cíclica de un objeto con repeticiones.

repetición retransmisión

periodo

Transmisión cíclica de un objeto con repeticiones.

Los diferentes objetos en un flujo cíclico MOT son identificados por su NombreContenido. Se recomienda transmitir los objetos más importantes con más frecuencia que el resto para mejorar el acceso al servicio. Para tratar esto tenemos que utilizar los mecanismos de transmisión MOT.

La repetición en el nivel de grupo de datos MSC es una manera de proveer una recepción confiable de objetos. Esto implica que los grupos de datos MSC contienen segmentos MOT que son transmitidos más de una vez con el mismo contenido de datos. Con n repeticiones tenemos que cada grupo MSC se transmite n+1 veces. El índice de Repetición del grupo de datos MSC se establecerá para indicar el número restante de repeticiones de este grupo con el mismo contenido de datos ocurriendo en los sucesivos grupos de datos MSC del mismo tipo. Un índice de Repetición con valor 1111 indica que la repetición continua durante un periodo indefinido.

Otro mecanismo es la repetición en el nivel de objetos, más fiable que la anterior. La repetición en el nivel de objetos significa que el objeto se transmite más de una vez con el mismo TransportId, la misma segmentación y exactamente el mismo contenido en cabecera y cuerpo. Se permite inmediatamente parar la transmisión de un objeto, sin completar la secuencia de repetición, si es actualizado o eliminado.

La retransmisión de objetos implica tener acceso a la información en cualquier momento. Un objeto se conserva con el mismo NombreContenido en todas las retransmisiones. Si su cabecera, cuerpo o TamañoSegmento se han cambiado se le asignará un nuevo TransportId, si no el TransportId será el mismo. El proveedor de servicios se asegurará de que los TransportId no son reusados hasta que otros TransportId se han usado. El parámetro DistanciaRetransmisión se puede utilizar aquí para indicar el tiempo máximo garantizado hasta la próxima retransmisión del objeto.

El cuarto mecanismo es insertar cabeceras MOT. Si hacemos transmisiones adicionales de la cabecera MOT junto a las repeticiones permitimos a los decodificadores que pierdan la cabecera y la parte inicial de un objeto empezar a recoger las subsecuentes partes del objeto.

Los objetos MOT en un flujo MOT pueden ser intercalados para que, por ejemplo, parezca que son transmitidos en paralelo. En el flujo físico MOT el intercalado significa que los segmentos de los objetos intercalados son multiplexados para que la transmisión de un objeto empiece antes de la transmisión de otro objeto y la repetición hayan acabado. Aquí podemos observar un ejemplo con 2 objetos:

El intercalado puede usarse para insertar objetos con gran prioridad dentro del flujo MOT durante la transmisión de objetos grandes con un gran tiempo de transmisión. Si se intercalan objetos en un flujo MOT se recomienda limitar el nº de objetos intercalados. Cuando muchos objetos que tienen el TriggerTime a Now se intercalan, el proveedor de servicios / contenidos tiene que pensar que estos objetos pueden recibirse más o menos al mismo tiempo, y como consecuencia, la presentación quizás no sea predecible.

La actualización de un objeto se hace cuando cambia su segmentación, la cabecera y / o el cuerpo. Para ello el terminal debe cambiar el TransportId.. Si cambia el cuerpo se incrementa el campo NúmeroVersión. Para borrar un objeto usamos el parámetro ExpireTime.

4.6 Codificación

El grupo de datos MSC es el nivel común más bajo para el transporte de MOT en modo Paquete y PAD. Lleva unos parámetros o flags. Los más importantes los vamos a ver a continuación:

• Flag de extensión. Indica si el campo Extensión (utilizado para CA) está presente o no.

• Flag CRC. Indica si hay un grupo CRC o no. En el caso de transporte de objetos MOT en PAD se recomiendo encarecidamente que halla un grupo de datos MSC con CRC porque no hay otra detección de errores. En el modo paquete hay una detección de error añadida en el nivel de red pero el CRC es en este caso utilizado para la detección de paquetes perdidos. CRC se utiliza para guardar la suma de comprobación.

• Flag de sesión. Indica la presencia del flag Último y número de segmento. Si hay sólo un segmento en la cabecera MOT, cuerpo o directorio, se recomienda establecer a 0 este flag para esta parte del objeto, es decir, omitir el flag Último y número de segmento.

• Tipo de grupo de datos. Indica el tipo de datos que se transportan en el campo de datos MSC. Los tipos ya se explicaron en el nivel de segmentación y nivel de objetos (punto 4.4).

• Último. Indica cuando este grupo de datos MSC es el último segmento de un grupo de segmentos (correspondiente a una cabecera MOT o un cuerpo).

• Índice de continuidad. Se incrementa para cada grupo de datos de un cierto tipo con un contenido diferente del grupo de datos inmediatamente precedente. Normalmente se usa para detectar que grupos de datos completos se han perdido durante la conexión.

• Índice de repetición. Se usa para indicar las repeticiones en el nivel de grupo de datos MSC.

• Nº de segmento. Indica el número de segmento contando que el primero segmento lleva el 0 y se incrementa para cada nuevo segmento.

• Flag del TransportId. Indica la presencia del TransportId. En este caso de MOT siempre se establecerá a uno porque el TransportId es obligatorio.

Además tenemos la cabecera del grupo de datos MSC, el indicador de tamaño, el propio TransportId, los datos del grupo de datos MSC y el CRC del grupo de datos MSC.

Ahora vamos a ver un ejemplo de codificación de un objeto MOT con segmentación.

Transmitiremos un archivo con los atributos siguientes: Tamaño=1000 bytes, Tipo=Archivo HTML, Nombre=Test_html.htm

No es necesaria un segmentación de cabecera. Construimos 2 segmentos de 500 bytes para el cuerpo MOT. No habrá repetición en nivel de transporte ni en el de objetos. El índice de continuidad se establece a cero indicando que cada grupo de datos es el primero de su tipo. El TransportId será 1111000011110000 según se ha descrito en el propio estándar.

La codificación del primer grupo de datos MSC (cabecera MOT) es la siguiente: flag de extensión a 0, flag de CRC a 1, flag de sesión a 0, el tipo de datos será cabecera MOT (0011), el índice de continuidad indicará 0000, el índice de repetición a cero, flag de TransportId a 1 (normal, porque es obligatorio) y el TransportId como se menciona en el propio estándar. Se omiten Último, Extensión y número de segmento.

En el campo de datos van 13 bits de TamañoSegmento (23 bytes), 28 bits para el TamañoCuerpo (1000 bytes), 13 bits para el TamañoCabecera (23 bytes), 6 bits que indican el TipoContenido (texto), 9 bits para SubtipoContenido (html) y 14+2 bytes ocupados por NombreContenido (Test_html.htm). El campo de la suma de comprobación lleva 2 bytes que dependen del contenido del grupo de datos.

La codificación del segundo y tercer grupo de datos MSC (los 2 segmentos en que dividimos el archivo) es prácticamente igual, para el primero es: flag de extensión a 0, flag de CRC a 1, flag de sesión a 1 (están presentes el flag Último y el número de segmento), el tipo de datos será cuerpo MOT (0100), el índice de continuidad indicará 0000, el índice de repetición a 0, el bit de Último a 0, el número de segmento con 16 bits a cero (1º segmento), flag de TransportId a 1 y el TransportId como se menciona en propio estándar. Se omite el campo Extensión.

En el campo de datos indicamos con TamañoSegmento que hay 500 bytes y otros parámetros. También es necesario un apartado para el CRC.

En el tercer grupo de datos (2º segmento) tenemos que encender el bit de Último y cambiar el número de segmento a 1 (con 15 ceros antes), el resto se mantiene igual.

El RO MOT permite actualizar objetos (cabecera, cuerpo o directorios) transmitiendo el nuevo objeto completo con el mismo NombreContenido e incrementando el NúmeroVersión. Podemos actualizar sólo la cabecera del objeto MOT.

4.7. Transmisión de un conjunto de ficheros

Un conjunto de ficheros consiste en ficheros que serán manejados como una unidad. Es necesario mencionar que significa transferencia confiable de un conjunto de ficheros del proveedor de servicios / contenidos al terminal.

Para poder soportar todas las aplicaciones de usuario que necesitan transportar un conjunto de archivos al terminal se define un mecanismo general.

Para pasar la estructura de un directorio a MOT cada fichero del conjunto se completa con la cabecera MOT y se construye un objeto MOT. Los NombresContenido de los objetos MOT se usan para trazar la estructura del directorio del proveedor de contenido al terminal. El NombreContenido consiste en un prefijo igual para todos los objetos y el nombre del archivo relativo a la raíz del directorio. El separador en la jerarquía será el carácter de la barra ` / `.

Ahora veamos un ejemplo de cómo un proveedor, llamado en este caso charlie, transmite un directorio vía DAB, que empieza en “C:\data\provider1\”.

Lista de archivos:

C:\data\provider1\base.htm

C:\data\provider1\products.htm

C:\data\provider1\images\logo.jpg

C:\data\provider1\images\device1.jpg

C:\data\provider1\images\device2.jpg

Los NombresContenido deben ser: O incluso:

charlie/base.htm

charlie/products.htm

charlie/images/logo.jpg

charlie/images/device1.jpg

charlie/images/device2.jpg

Reseñar que:

• El terminal distingue mayúsculas y minúsculas. Por lo tanto una referencia a un objeto debe usar las mismas letras (mayúsculas o minúsculas) para el NombreContenido de un objeto. Por ejemplo: un objeto con NombreContenido index.htm no puede ser referenciado con Index.htm, incluso si la referencia se hace en un sistema basado en MS-DOS.

• En los sistemas no basados en MS-DOS MOT asigna significado jerárquico a la barra (` / '). Por lo tanto los nombres originales en un sistema basado en MS-DOS no contendrán barras (` / '). En MOT la barra invertida (` \ `) no tiene significado jerárquico.

Una transmisión no cíclica puede usarse para aplicaciones de usuario como bajar software o periódicos electrónicos que son transmitidas en un momento conocido por el terminal así que el terminal puede encenderse en este momento. Los archivos pueden entonces ser almacenados y / o procesados (ej: imprimir) después de su recepción. Si el terminal no está encendido en el momento oportuno o no le es posible guardar y procesar los ficheros, puede perder algunos o todos estos ficheros. Si queremos asegurar la recepción podemos realizar repeticiones o insertar cabeceras MOT como vimos anteriormente.

La transmisión cíclica se entiende para aplicaciones de usuario que estarán disponibles en el terminal siempre. Si el terminal pide un objeto MOT que ya no está en su memoria entonces solamente tiene que esperar un nuevo ciclo.

Para cambiar un objeto hacemos lo siguiente: si un archivo se modifica, su NumeroVersión se incrementa y el objeto MOT será transmitido tan pronto como sea posible considerando la posición del objeto dentro del ciclo de transmisión y considerando la disponibilidad requerida en el terminal.

Para borrar un objeto: se generan y se transmiten tan pronto como sea posible un cabecera de actualización con el correspondiente NombreContenido, sin NúmeroVersión (pues se refiere a todas las versiones) y el ExpireTime puesto a Now. Esta cabecera de actualización debe omitirse en omitida después de un pocas transmisiones.

Para añadir un objeto, el nuevo objeto será transmitido tan pronto como sea posible respecto a su posición con otros objetos y considerando la disponibilidad requerida en el terminal.

5. Bibliografía y documentación

• Borrador ETSI TR 101 497 v1.1.1 (Informe técnico). Digital Audio Broadcasting System; Rules of Operation for the Multimedia Object Transfer Protocol (RO MOT).

• Compendio de la especificación del sistema DAB dada en el documento ETSI 300 401

• Consorcio Eureka 147 : http://www.eurekadab.org

• World DAB Forum: http://www.worlddab.org

• Radio Televisión Española (RTVE): http://www.rtve.es/dab

• DAB: Radiodifusión Audio Digital:

• Periódico El Mundo, 25 de julio de 2000, sección Sociedad.

• Instituto Europeo de eStándares de Telecomunicaciones (ETSI): http://www.etsi.org

Proveedor de servicios o contenidos

Terminal

Codific. MOT

Codif.

PAD

Codif.

Audio

Codif.

MOT

Codif.

de paquetes

Multip.

de paquetes

Multip. conjunto

DAB

Demulti. conj. DAB

Decodif. datos DAB

Archivo

Segmento

Cabecera de segmento

Cabecera de extensión

Segmento 1 del cuerpo

Segmento 1 del cuerpo

Segmento n del cuerpo

·····

Cabecera básica

Cabecera de segmento

Segmento

Cabecera de datos MSC

CRC de datos MSC

Campo de datos del grupo de datos MSC

Cabecera de sesión

Cabecera de datos MSC

CRC de datos MSC

Campo de datos del grupo de datos MSC

Cabecera de sesión

Nivel de aplicación de usuario

Terminal

Decod. de aplic. del usuario

Usuario

Nivel de objetos

Decodificador de grupo de datos

cabecera MOT

Nivel de Segmentación

Paquetes

Decod.

Modo Paquete

Decod.

PAD

Nivel de grupo de datos

Subcampos de datos X-PAD

Nivel de red

Grupos MSC

Decodificador de datos MOT

Administrador de objetos

Cuerpos MOT

cabeceras, cuerpos, directorios

Unidad de reensamblaje

cuerpo MOT

directorio MOT

obj.

obj.

obj.

obj.

obj.

obj.

obj.

obj.

obj.

obj.

Acu1

Acab

Acu2

Acu6

Acu5

Acu4

Acu3

Objeto A

Bcu2

Bcu1

Bcab

Objeto B

Segmentos en flujo MOT

Bcu2

Bcu1

Bcab

Acu3

Acu4

Acu5

Acu6

Acu2

Acu1

Acab

base.htm

products.htm

images/logo.jpg

images/device1.jpg

images/device2.jpg