PDF1 - LDC

Servicios de vídeo sobre redes móviles de
nueva generación
Rosa María Bernárdez Rodríguez, Joaquín María López Muñoz, Antonio Ferreras García,
José Luis García Gómez
Telefónica Investigación y Desarrollo
Juan Rufino López Lorite, Javier Lorente Martínez
Telefónica Móviles España
En este artículo se exponen las dificultades que se encuentran en la creación de
servicios de vídeo sobre la nueva generación de redes móviles. Problemas actuales
como el alto tiempo de latencia, el ancho de banda variable y la asimetría del canal,
imponen requisitos muy críticos a las aplicaciones de este tipo, mientras no se
encuentren disponibles recursos de red como son la garantía de calidad de servicio o
el tiempo real en la transmisión de datos.
MoviStar Vídeo supuso un gran esfuerzo tecnológico para el envío de vídeo a través de
canales GSM y ha sido el precedente para el desarrollo de nuevos servicios sobre las
redes GPRS/UMTS.
INTRODUCCIÓN
La provisión de servicios multimedia sobre redes en
tiempo real habitualmente se denomina con el término anglosajón de streaming. Con este término, prácticamente intraducible, se pretende señalar los requisitos de tiempo real que requieren los servicios de este
tipo: se necesita un flujo continuo y mantenido de
datos para que el disfrute de los contenidos sea efectivo. La diferencia con los servicios de descarga debe
quedar clara; aquí se produce primero el envío de
datos y sólo después se accede a los contenidos. En el
streaming, el transporte y el tratamiento de datos se
producen de forma simultánea. Para fijar conceptos,
podemos establecer una comparación con los servicios de televisión: la descarga se asemeja al visionado
de una película de vídeo, donde los contenidos ya se
encuentran de manera local en el receptor, siendo el
streaming la recepción de un canal de televisión.
Siguiendo con la analogía, el centro emisor de contenidos en streaming debe servir a multitud de clientes;
es prácticamente imposible atender las demandas
individuales de cada uno, por lo que los contenidos
emitidos deben ser uniformes para todos ellos. Incluso cuando los contenidos no se emiten en tiempo real,
sino que están ya disponibles en el servidor, éste no
puede, por requisitos de potencia, realizar un tratamiento personalizado para cada uno, sino simplemente realizar la conexión con el cliente y a continuación realizar la transmisión de los contenidos.
En el caso del streaming, los requisitos de red son
necesariamente más exigentes que en otro tipo de servicios: disminuciones del ancho de banda disponible
o variaciones de latencia en recepción, traen consecuencias fatales en la calidad del servicio, con interrupciones y saltos muy notables de audio y vídeo. Un
proceso completo de streaming multimedia puede
verse en la Figura 1.
Las demandas de nuevos servicios sobre las redes
móviles de tercera generación se centran habitualmente en los contenidos multimedia; nuevas aplicaciones multimedia permitirán incrementar los beneficios por el mayor tiempo de uso y el valor añadido
que estas aplicaciones suponen. UMTS clasifica los
servicios atendiendo a la calidad se servicio (QoS) que
demandan de la siguiente forma:
1. Clase conversacional, con altos requisitos de retardo
y estabilidad de ancho de banda, como, por ejemplo, la videoconferencia.
Número 21 · Junio 2001
Comunicaciones de Telefónica I+D
169
2. Clase streaming, con altos requisitos de retardo y
más relajado en el ancho de banda, como los servidores de vídeo y audio.
3. Clase interactiva, como la navegación web.
4. Clase diferida, como el e-mail.
De estos cuatro servicios sólo los dos primeros se relacionan con el streaming en tiempo real, siendo la diferencia fundamental entre ambos el hecho de que los
servicios conversacionales requieren unos tiempos de
retardo muy bajos. La QoS de las futuras redes móviles [1] permitirá la transmisión de ambas clases de
contenidos multimedia. No obstante, se necesitarán
nuevas herramientas para hacer esa transmisión posible y, en especial, nuevos protocolos que solucionen la
problemática asociada con la transmisión en paquetes
de estos contenidos. El siguiente apartado, dedicado a
Streaming Multimedia sobre IP y 3GPP, trata de los
protocolos de aplicación y transporte necesarios para
la transmisión de contenidos en tiempo real sobre
redes IP, que habrá que implementar y tratar tanto en
los clientes como en los servidores de las redes 3G.
¿Y qué hay de las redes móviles actuales? ¿Soportan
estos tipos de servicios?. Ya hemos visto que los requisitos son muy exigentes; el concepto de calidad de servicio, o garantía de unas condiciones mínimas de
ancho de banda y transmisión en las redes, envuelve
la definición de cualquiera de estos servicios. Por ello,
las redes de tercera generación prevén la negociación
de la red con los terminales y aplicaciones para garantizar unas calidades de transmisión sobre las que
soportar ese tipo de servicios. En las redes actuales no
se dispone de dichas facilidades. En el apartado dedicado a Streaming Multimedia sobre GSM y GPRS se
expone la problemática y las soluciones que ha desarrollado Telefónica en este campo.
Figura 1. Distribución de contenidos multimedia
Comunicaciones de Telefónica I+D
170
Número 21 · Junio 2001
STREAMING MULTIMEDIA SOBRE IP Y 3GPP
El establecimiento de una red con servicios multimedia no es una tarea trivial. En principio, se pueden
implementar redes multimedia sobre muy distintos
medios de transporte, enlaces punto a punto, redes
ATM, etc., pero Internet ha crecido tanto en los últimos años y es accesible por tan gran número de usuarios que, cuando hablamos de protocolos de streaming
multimedia casi no es necesario decir que hablamos
de Internet, a pesar de que como red datagrama compartida, Internet no es el medio natural para distribuir tráfico sincronizado o en tiempo real.
Por las características de la transmisión de datos multimedia y por las características de Internet nos vamos
a encontrar con muchas dificultades, entre ellas están:
Los sistemas de creación de contenidos tienen una
o más fuentes de datos, por ejemplo, un micrófono
y una cámara. Para componer un vídeo multimedia
con distintos tipos de datos, se hace necesario editar los datos originales en formato no comprimido,
generalmente, esto requiere grandes cantidades de
espacio de almacenamiento. Para facilitar la recuperación de datos se hacen necesarios mecanismos de
compresión y transporte, que no obliguen al espectador a descargar del servidor todos los contenidos
completos para poder visualizarlos después.
Una vez en el terminal del cliente, es necesario
tener disponibles decodificadores de contenidos
que puedan ir descomprimiendo sonido e imágenes
al tiempo que se reciben; no hay que esperar a que
haya llegado el contenido completo.
Las aplicaciones multimedia requieren un ancho de
banda muy alto. Una forma de paliar, parcialmente, este problema es proveer codificadores con alta
capacidad de compresión. Así, se pueden ofrecer
contenidos multimedia a diferentes calidades,
dependiendo del ancho de banda del que se disponga.
Los datos de audio y vídeo se deben reproducir con
el mismo régimen en que han sido muestreados. Si
los datos no llegan en tiempo, los artefactos visuales y auditivos pueden llegar a ser intolerables.
Muchas aplicaciones multimedia requieren que la
transmisión sea en tiempo real, es el caso de las
aplicaciones de Voz sobre IP (VoIP).
Generalmente, las aplicaciones multimedia generan tráfico a ráfagas que pueden saturar los búferes
intermedios del cliente (en los decodificadores, por
ejemplo). El simple aumento del ancho de banda
no soluciona este problema. Hay que tomar medidas de control de búfer que alisen el tráfico en ráfagas.
En muchos modelos de uso, por ejemplo la videodifusión, las aplicaciones multimedia son multicast,
es decir, el mismo contenido va dirigido a muchos
usuarios simultáneamente. Si los protocolos de streaming están preparados para gestionar tráfico multicast se puede reducir mucho el tráfico en la red.
Los recursos compartidos de la red no siempre
están disponibles, sin embargo, las aplicaciones en
tiempo real requieren un ancho de banda garantizado, por lo que será necesario usar protocolos que
reserven recursos a lo largo del camino de transmisión. En el caso de los sistemas 3G ya están previstas las negociaciones de calidad de servicio.
Internet es una red de conmutación del conjunto
de bit del datagrama, donde los paquetes se encaminan de forma independiente a través de redes
compartidas. No se puede garantizar que los datos
en tiempo real lleguen a su destino de forma
secuencial y ordenada, por lo que habrá que definir
nuevos protocolos para la ordenación y sincronización de paquetes.
Es necesario definir algunas aplicaciones estándar
que presenten los datos multimedia.
Internet transporta todo tipo de tráfico, cada cual con
sus características y requisitos. Por ejemplo, una aplicación de transferencia de fichero requiere que una
cierta cantidad de datos sea transferida en una cantidad de tiempo aceptable, mientras que la voz sobre IP
requiere que la mayor parte de los paquetes lleguen al
Figura 2. Streaming 3GPP/·3GPP2: Stack de protocolos
receptor en menos de 0,3 segundos. La solución es
clasificar el tráfico, asignando distinta prioridad a las
distintas aplicaciones, y hacer las reservas de recursos
correspondientes.
Surgirán, además, nuevas dificultades provenientes de
las características de las redes móviles inalámbricas:
dificultad de sincronización de streams, tiempos de
latencia de red excesivos, problemas para transmisión
de voz interactiva en tiempo real, etc.
El servicio de streaming multimedia de la red de
paquetes conmutada 3GPP está siendo estandarizado
[2] basándose en las partes de control y transporte de
los protocolos del IETF/W3C RTSP (Real Time Streaming Protocol), RTP (Real Time Transport Protocol)
RTCP (Real Time Control Protocol) y SDP (Session
Description Protocol). Estos protocolos (ver la Figura
2) van a ser explicados con detalle en los próximos
apartados, pero podemos adelantar que sientan las
bases para los servicios integrados en tiempo real [3].
Los servicios integrados permiten manejar una sola
infraestructura para las aplicaciones multimedia y las
aplicaciones tradicionales. Es un acercamiento integral para proveer a las aplicaciones el tipo de servicio
que necesitan y en la calidad deseada.
El protocolo RTP
El protocolo de transporte en tiempo real, Real Time
Transport Protocol (RTP) [4] es un protocolo IP que
proporciona soporte para el transporte de datos en
tiempo real, como streams de vídeo y audio. Los servicios proporcionados por RTP incluyen la reconstrucción de temporizaciones, la detección de pérdida
de paquetes y la seguridad e identificación de conte-
Número 21 · Junio 2001
Comunicaciones de Telefónica I+D
171
nidos. RTP se ha diseñado principalmente para la
transmisión multicast, pero también puede ser utilizado en unicast. Se puede usar igualmente para transporte unidireccional, por ejemplo el video-ondemand, o para servicios interactivos, como la telefonía por Internet. RTP trabaja conjuntamente con el
protocolo auxiliar de control para obtener realimentación acerca de la calidad de transmisión y para obtener información acerca de los participantes en la
sesión.
Como se ha comentado anteriormente, Internet es
una red basada en datagramas y los paquetes enviados
se reciben con retardos no predecibles y desordenados, sin embargo, las aplicaciones multimedia requieren temporizaciones apropiadas en la transmisión de
datos y en su reproducción. RTP proporciona marcas
temporales, numeración de secuencias y otros mecanismos para tener en cuenta los problemas relativos a
la temporización. Con estos mecanismos, RTP proporciona transporte punto a punto en tiempo real
sobre la red datagrama.
La temporización es la información más importante
en las aplicaciones de tiempo real. Quien envía asigna
una marca temporal (timestamp), acorde al momento
en que el primer octeto del paquete fue muestreado.
El receptor usa esta marca temporal para reconstruir
la temporización y reproducir los datos a la velocidad
correcta. Las marcas temporales también se usan para
sincronizar distintas secuencias de datos (audio y
vídeo). Sin embargo, RTP, por si mismo, no es responsable de la sincronización. Esto ha de ser realizado por protocolos superiores de la aplicación.
Puesto que UDP no despacha los paquetes ordenados
en el tiempo, se usa la numeración de secuencias para,
en recepción, ordenar los paquetes recibidos. La
numeración de secuencias se usa también para la
detección de pérdidas de paquetes. Hay que hacer
notar que en algunos formatos de vídeo, cuando una
imagen se parte en varios paquetes RTP, todos ellos
llevarán la misma marca temporal, de ahí que estas
marcas no sean suficientes para mantener la ordena-
Figura 3. Datos RTP en un paquete IP
Comunicaciones de Telefónica I+D
172
Número 21 · Junio 2001
ción de paquetes.
Un identificador de carga payload especifica el formato de datos, así como el esquema de compresióndecomprensión. Con este identificador la aplicación
receptora sabe como interpretar y reproducir los
datos. Los identificadores de carga se definen en la
RFC 1890, entre otros están PCM, vídeo y audio
MPEG1/MPEG2, vídeo JPEG, vídeo Sun CellB,
secuencias de vídeo H.261, etc. Se pueden agregar
tipos nuevos, proporcionando un perfil y una especificación de formato. En un momento dado de la
transmisión, un emisor RTP sólo puede enviar un
tipo de carga, a pesar de que ésta puede variar durante la transmisión, por ejemplo, para ajustarse a condiciones de congestión de red.
Otra función que realiza el protocolo RTP es la identificación de las fuentes de datos (ver la Figura 3). Le
permite a la aplicación receptora conocer de donde
vienen los datos, por ejemplo en una audio conferencia, a partir del identificador de la fuente se puede
saber quién está hablando. Los anteriores mecanismos
se implementan a través de las cabeceras RTP.
Los dos protocolos de transporte más utilizados en
redes IP son TCP y UDP. TCP proporciona un flujo
fiable y orientado a conexión entre dos terminales,
mientras que UDP proporciona un servicio datagrama no fiable y no orientado a conexión. La elección
de UDP se debe a varias razones, en primer lugar RTP
puede hacer uso de las funciones de multiplexado y
checksum de UDP, además, RTP se ha diseñado pensando en los servicios multicast, para lo cual la conexión TCP no es apropiada por problemas de escalabilidad; en segundo lugar RTP ha sido diseñado para
datos en tiempo real, la fiabilidad del transporte no es
tan importante como la recepción en el tiempo adecuado. Es más, TCP implementa la fiabilidad de
transmisión usando la retransmisión de paquetes, lo
cual en el caso de tráfico de datos en tiempo real es un
inconveniente. En el caso de congestión de red, los
paquetes perdidos, simplemente, redundarán en una
calidad inferior, pero aceptable, si el protocolo insiste
en la transmisión fiable, retransmitiendo paquetes
perdidos, el retardo posiblemente aumentará, degradando más la calidad de la recepción.
En la práctica RTP se implementa generalmente dentro de la aplicación, pues temas como la recuperación
de paquetes perdidos o de control de las congestiones
de red, tienen que ser implementados al nivel de aplicación.
las marcas temporales para calcular el retardo de
ida y vuelta entre el receptor y el transmisor.
2. SR (informe de emisor). Los informes de emisor son
generados por los emisores activos. Además de
datos sobre la calidad de recepción, como en los
RR, contienen datos de sincronización intermedia,
de contadores acumulativos de paquetes y del
número de byte enviados.
Para establecer una sesión RTP, la aplicación define
una pareja de direcciones destino de transporte (una
dirección de red con un par de puestos para RTP y
RTCP). En una sesión multimedia, cada tipo de datos
(medium) es transportado por una sesión RTP, separada con sus propios paquetes RTCP e informando de
la calidad de recepción para esa sesión. Por ejemplo,
audio y vídeo viajarán por sesiones separadas de RTP,
permitiendo de esta manera al receptor decidir cuando desea recibir una determinada secuencia de datos
multimedia.
3. SDES (datos de descripción de fuente). Contienen
información descriptiva de la fuente de datos.
En la RFC 1889 se describe un escenario de audioconferencia que ilustra el uso de RTP 1889. Supongamos que cada participante envía datos de audio de
20 ms de duración. Cada segmento de datos audio es
precedido por una cabecera RTP y el paquete RTP
resultante se envía en un paquete UDP. La cabecera
RTP indica el tipo de codificación de audio, las aplicaciones pueden cambiar la codificación durante la
conferencia, como reacción a situaciones de congestión de red. La información de temporización y
secuencia de la cabecera RTP es usada por los receptores para reconstruir la temporización de la fuente de
datos, así, en este ejemplo, los segmentos de audio son
reproducidos de forma continua cada 20 ms.
Monitorización de la calidad de servicio (QoS) y congestión de red. La función primaria de RTCP es proporcionar realimentación a una aplicación sobre la
calidad de la distribución. Esta información le es
útil a los emisores, a los receptores y a otras terceras
partes interesadas (monitores de aplicación, por
ejemplo). El emisor puede ajustar su transmisión
basándose en estos informes. El receptor puede
determinar si la congestión de red es local, regional
o global. Los gestores de red pueden evaluar el rendimiento de la red para la distribución multicast.
El protocolo RTCP
Real Time Control Protocol (RTCP) [5] es un protocolo diseñado para trabajar conjuntamente con RTP. En
una sesión RTP, los participantes se envían periódicamente paquetes RTCP para tener realimentación
sobre la calidad de recepción. Se definen cinco tipos
de paquetes RTCP para transportar la información de
control. Estos son:
1. RR (informe de receptor). Informes enviados por los
participantes que no son emisores activos. Estos
informes contienen datos acerca de la calidad de
recepción, incluyendo el número más alto de
secuencia recibido, el número de paquetes perdidos, la información sobre paquetes desordenados y
4. BYE (adiós). Indica el fin de la participación.
5. APP (datos específicos de la aplicación). Se han reservado para usos experimentales, mientras se desarrollan nuevas funciones y tipos de aplicaciones.
A través de estos paquetes, RTCP proporciona los
siguientes servicios:
Identificación de fuentes. Las fuentes de datos se
identifican en los paquetes RTP con identificadores
de 32 bit generados aleatoriamente. Estos identificadores no son apropiados para usuarios humanos.
Los paquetes RTCP SDES (descripción de fuente)
contienen identificadores únicos globales (nombres
canónicos) e información textual, como el nombre
de los participantes, el número de teléfono, la
dirección de e-mail, etc.
Sincronización intermedia. RTCP envía informes
con información de tiempo real que corresponde a
una determinada marca temporal RTC. Esa información puede ser utilizada para sincronizar fuentes
de datos que procedan de distintas sesiones RTP.
Escalado de la información de control. Los paquetes
RTCP se envían periódicamente entre los participantes. Cuando el número de participantes aumenta, se hace necesario establecer un compromiso
Número 21 · Junio 2001
Comunicaciones de Telefónica I+D
173
entre la obtención de información actualizada y la
sobrecarga por tráfico de la red. Para escalar el tráfico de grupos multicast grandes, RTCP ha de limitar el tráfico de control procedente de los recursos
de red a los que más se accede. RTP limita el tráfico de control al 5 por ciento del tráfico total de la
sesión, esto se refuerza ajustando el tráfico RTCP a
un régimen acorde al número de participantes.
El protocolo RTSP
En vez de almacenar grandes ficheros multimedia y
reproducirlos, los datos multimedia se envían a través
de la red secuencialmente en streams. El proceso de
streaming rompe los datos en paquetes del tamaño
apropiado para su transmisión entre servidor y cliente. Un cliente puede reproducir el primer paquete,
mientras decodifica el segundo y recibe el tercero. Así,
el usuario puede disfrutar de los contenidos sin esperar a que finalice la transmisión
Real Time Streaming Protocol (RTSP) es el protocolo
de streaming en tiempo real, siendo un protocolo
multimedia cliente-servidor de presentación para permitir el despacho controlado de los datos multimedia
a través de la red IP. Proporciona una interfaz, al estilo de un reproductor de vídeo, con funciones de control remoto como "pausa", "avance rápido", "atrás" e
"ir a posición". Las fuentes de datos pueden ser tanto
en directo como en diferido (enlatadas).
RTSP es un protocolo a nivel de aplicación, diseñado
para trabajar conjuntamente con protocolos de bajo
nivel como RTP. Proporciona mecanismo para seleccionar canales de envío (como UDP, UDP multicast y
TCP) y mecanismos de despacho basados en RTP. Es
válido tanto para difusión (unicast) como multidifusión (multicast).
RTSP es el "control remoto en red" entre el servidor
y el cliente. Este protocolo proporciona las siguientes
operaciones:
Recuperación de datos del servidor. El cliente pide la
descripción de una presentación y le pide al servidor que establezca la sesión para enviar los datos
solicitados.
Invitación al servidor de medios a una conferencia. El
servidor de medios puede ser invitado a una conferencia para reproducir o para grabar una presentación.
Añadir datos multimedia a una presentación existen-
Comunicaciones de Telefónica I+D
174
Número 21 · Junio 2001
te. El servidor y el cliente pueden notificarse uno al
otro la disponibilidad de datos adicionales.
RTSP pretende proporcionar, para presentaciones
multimedia, los mismos servicios que HTTP proporciona para texto y gráficos, de hecho se ha diseñado
intencionadamente con una sintaxis similar, de tal
modo que la mayor parte de los mecanismos de extensión de HTTP se pueden añadir a RTSP.
En RTSP cada presentación y cada stream multimedia
es identificado por una URL RTSP. La presentación
completa y las propiedades de los media se definen en
un fichero de descripción de presentación, entre la
información se incluye el tipo de codificación, el idioma, las URLs RTSP, las direcciones de destino, los
puertos y otros parámetros. El cliente puede obtener
este fichero mediante HTTP, e-mail u otros métodos.
RTSP difiere de HTTP en muchos aspectos. En primer lugar, HTTP es un protocolo sin estados y RTSP
ha de mantener los estados de la sesión para enlazar
las peticiones con los streams relacionados. En segundo lugar, HTTP es asimétrico, cuando el cliente realiza una petición el servidor responde; mientras que
en RTSP ambos, cliente y servidor, pueden realizar
peticiones.
Los servicios y operaciones soportados son:
Options. El cliente o el servidor comunican a la otra
parte las opciones que pueden aceptar.
Describe. El cliente recupera la descripción de una
presentación o medio identificado por una URL
Announce. Cuando se envía desde el cliente al servidor, Announce envía la descripción de una presentación identificada por su URL. Cuando se
envía desde el servidor al cliente, Announce actualiza la descripción de sesión en tiempo real.
Setup. El cliente le pide al servidor que reserve
recursos para un stream y para iniciar una sesión
RSTP.
Play. El cliente le pide al servidor que comience a
enviar datos para el stream reservado, vía Setup.
Pause. El cliente, temporalmente, para el flujo del
stream sin liberar los recursos asociados.
Teardown. El cliente le pide al servidor que detenga
el envío de un determinado stream y libere los
recursos asociados.
Get_Parameter. Recupera el valor de un parámetro
de una presentación o un stream identificado por su
URI.
Set_Parameter. Asigna el valor de un parámetro de
una presentación o stream identificado por su URI.
Redirect. El servidor informa al cliente de que se
debe conectar a otra dirección de servidor. La cabecera obligatoria de localización indica el URL que
el cliente debe contactar
Record. El cliente inicia la grabación de unos datos
multimedia de acuerdo a la descripción de la presentación.
Algunos de estos métodos pueden ser enviados tanto
por el cliente como por el servidor, pero otros sólo
pueden ser emitidos en una dirección. No todos los
métodos son necesarios para tener un servidor plenamente funcional. Por ejemplo, un servidor de medios,
alimentado con datos en vivo, puede no soportar el
método Pause.
Las solicitudes RTSP se envían, como norma general,
por un canal independiente del canal de datos. Pueden ser transportadas por conexiones persistentes o
creando una conexión por petición/respuesta
El protocolo RSVP
Resource Reservation Protocol (RSVP) [6] es el protocolo de control de red que permite al receptor de
datos solicitar una determinada calidad de servicio
punto a punto. Las aplicaciones en tiempo real usan
RSVP para reservar los recursos necesarios en los routers a lo largo de los caminos de transmisión, de tal
manera que el ancho de banda requerido esté disponible cuando la transmisión tenga lugar. RSVP es el
principal componente de los servicios integrados por
Internet, puede proporcionar tanto servicios en tiempo real (garantiza una calidad) como servicios besteffort (se hace lo que se puede).
Cuando una aplicación en un servidor (la que recibe
el stream de datos) solicita una calidad de servicio
(QoS) determinada, usa RSVP para emitir la solicitud
a los routers a lo largo del camino que recorre el stream. RSVP es el protocolo responsable de la negociación de los parámetros de conexión con dichos routers.
Figura 4. Reserva de recursos en un nodo del camino de transmisión
Cada nodo con capacidades de reserva de recursos
tiene varios procedimientos locales para realizar las
operaciones relacionadas.
En la Figura 4 podemos observar los elementos responsables de ejecutar los métodos de reserva. Estos
son:
El control de políticas. Determina si el usuario tiene
permisos administrativos para realizar reservas. Este
módulo ha de implementar también la autentificación, el control de acceso y el mantenimiento de
reservas.
El control de admisión. Lleva el control de los recursos del sistema y determina si el nodo tiene recursos suficientes para proporcionar la calidad de servicio solicitada.
El demonio RSVP. Chequea los dos módulos anteriores. Si algún chequeo falla, el programa le
devuelve un código de error a la aplicación que ha
originado la solicitud. Si ambos chequeos tienen
éxito, el demonio RSVP asigna parámetros en el
clasificador de paquetes y en el despachador de
paquetes, para obtener la QoS requerida.
El clasificador de paquetes. Determina el tipo de
QoS para cada paquete.
El despachador de paquetes. Ordena la transmisión
de los paquetes para conseguir la QoS prometida
para cada stream.
El demonio RSVP también se comunica con los procesos de enrutado para determinar cual es el camino al
Número 21 · Junio 2001
Comunicaciones de Telefónica I+D
175
que hay que enviar las solicitudes de reserva de recursos y para manejar los cambios de ruta.
Este procedimiento de reserva se repite en cada nodo,
a lo largo del camino inverso del stream, hasta que el
procedimiento de reserva llega a un nodo con otra
reserva para el mismo stream; finalizando la reserva de
recursos para ese camino.
Las reservas se implementan con dos tipos de mensajes RSVP: PATH y RESV.
Los mensajes PATH se envían periódicamente desde
el emisor a la dirección multicast. Un mensaje PATH
contienen especificaciones de flujo para describir
características del emisor (formato de datos, dirección
del emisor y puerto emisor) y características de tráfico. Esta información se utiliza en los receptores para
encontrar el camino inverso al emisor y para determinar que recursos deben ser reservados. Los receptores
deben unirse al grupo multicast para poder recibir los
mensajes PATH.
Este mecanismo de reserva proporciona una de las
principales características de RSVP, escalabilidad para
gran número de usuarios multicast.
Otros protocolos
Además de los protocolos vistos hasta ahora, se necesitarán algunos otros complementarios, los cuáles
están siendo también objeto de estandarización. Estos
son:
El protocolo SDP. Session Description Protocol (RFC
2327) es una sintaxis de descripción de la sesión,
basada en texto, que informa de la dirección del
servidor, de los contenidos de los streams y códecs
necesarios y de los contenidos solicitados durante la
sesión por el cliente.
Los mensajes RESV son generados por los receptores,
y contienen parámetros de reserva, especificaciones de
flujo y de filtro. Las especificaciones de filtro definen
que paquetes deben ser usados por el clasificador de
paquetes. La especificación de flujo es usada en el despachador de paquetes y su contenido depende del servicio. Los mensajes RESV siguen exactamente el
camino inverso de los mensajes PATH, estableciendo
reservas, en cada nodo, para uno o más emisores.
El protocolo CC/PP. Composite Capability/Preference
Profiles (CC/PP) permite el formateo o adaptación
de los contenidos para que se adapten a las capacidades del terminal, de acuerdo a las disponibilidades software y hardware y a las preferencias de
usuario.
Las reservas RSVP en un nodo han de ser confirmadas periódicamente con mensajes de refresco, la
ausencia de estos mensajes durante un determinado
tiempo destruye el estado de reserva de los recursos.
Usando estas reservas blandas, RSVP pueden manejar
El protocolo SMIL. Synchronised Multimedia Integration Language (SMIL) es un lenguaje basado en
XML que permite a los autores describir el comportamiento temporal de las presentaciones multimedia, asociar hyperlinks con determinados objetos
Figura 5. Progreso de la solicitud de reserva en el árbol multicast
Comunicaciones de Telefónica I+D
176
fácilmente rutas y miembros multicast cambiantes.
Las solicitudes de reserva (ver la Figura 5) son iniciadas por los receptores. No necesitan viajar por todo el
camino hasta el emisor. Viajan solamente hasta
encontrarse por el camino con otra solicitud de reserva para el mismo stream.
Número 21 · Junio 2001
e incluso realizar la descripción de la presentación
en pantalla.
de datos es habitualmente menor de 1 segundo. El
problema es el bajo ancho de banda ofrecido.
La otra cara de la estandarización son las aplicaciones
comerciales, que, debido a la extensión de su uso, se
convierten en estándares "de facto". Estas aplicaciones utilizan protocolos propietarios para la realización
de las diferentes funciones y, por supuesto, sólo se
entienden entre ellas. Debido a la gran competencia
que existe entre los diferentes fabricantes, muy pocos
de ellos apostarán sólo por la implementación oficial
de los servicios, sino que tratarán de conseguir ventajas competitivas con otro tipo de soluciones que estén
disponibles antes de la estandarización completa de
los protocolos y aplicaciones. Así, la alianza entre
Nokia y RealNetworks, para integrar la tecnología de
recepción de vídeo del segundo sobre los terminales
del primero, supone un primer paso en este sentido.
Redes GPRS. Es una conexión de paquetes en la que
por el momento no se ofrece garantía de calidad de
servicio. El ancho de banda es variable, así como el
retardo de transmisión.
Actualmente existen, con el permiso de Quicktime,
dos tecnologías comerciales que se reparten en el mercado del streaming de vídeo sobre IP: Windows Media
de Microsoft y Real Video de RealNetworks. Ambas
utilizan codificadores propietarios y la mayor parte de
los protocolos de transporte son, asímismo, específicos. UMTS ofrecerá un canal válido para la utilización de este tipo de aplicaciones, por lo que, como es
habitual, las tecnologías para el streaming de contenidos que se impongan dependerán de multitud de factores, siendo uno de los fundamentales la rapidez con
que los estándares alcancen el mercado y sean adoptados por los fabricantes de terminales.
Ninguna de las aplicaciones comerciales señaladas es
capaz de transmitir vídeo en las redes móviles actuales, debido a la dificultad de garantizar la calidad de
servicio que requieren estos sistemas para su funcionamiento. Telefónica dispone de servicios avanzados,
basados en la adaptación de la codificación de vídeo
al canal con el que se ha conseguido realizar diferentes servicios de transmisión de vídeo con notable
éxito, cómo se explica en el siguiente apartado.
STREAMING SOBRE GSM Y GPRS
Las redes GSM y GPRS presentan una problemática
especial que, en general, no permite la difusión de
vídeo con la arquitectura cliente-servidor. Ésta se describe a continuación:
Redes GSM. Al ser una conexión de circuitos, la
calidad de servicio, si no garantizada, sí se mantiene a muy buen nivel. El retardo en la transmisión
No obstante, con otro tipo de configuraciones, como
peer-to-peer, sí es posible utilizar estas redes para realizar ciertos tipos de servicios multimedia. La Dirección de Nuevos Servicios y Aplicaciones de Telefónica Móviles España y la División de Tecnología Multimedia de Telefónica Investigación y Desarrollo, han
colaborado, desde el año 1996, en el marco de sucesivos proyectos que incluyen entre sus actividades el
desarrollo de tecnologías y productos para la captura,
codificación y transmisión de vídeo en tiempo real,
utilizando canales de muy bajo ancho de banda, como
GSM y, más recientemente, GPRS. En un futuro próximo, estas tecnologías se ensayarán sobre la red
UMTS.
Dos son los hitos tecnológicos más importantes alcanzados en el campo de la transmisión de vídeo durante estos cinco años de colaboración:
1. El codificador/decodificador (códec) de vídeo propietario basado en H.263 para muy bajos anchos de
banda. Este códec, capaz de operar en tiempo real
sobre plataformas PC convencionales, ha sido integrado en la aplicación MoviStar Vídeo, en el sistema de transmisión de vídeo por satélite Scoop y en
diversos prototipos de transmisión de vídeo a través de GPRS.
2. El algoritmo dinámico de control de buffer para la
transmisión de vídeo en tiempo real, que permitió la
introducción de un esquema de codificación PB
(Prediction-Bidirectional) en la aplicación MoviStar
Vídeo y en los prototipos de transmisión de vídeo
por GPRS.
En los apartados siguientes se describen estas tecnologías y los productos desarrollados a partir de ellas.
El códec de vídeo de muy bajo ancho de banda
La mayoría de los códecs de vídeo existentes en el
mercado, denominados de "bajo ancho de banda",
típicamente operan en regímenes binarios muy por
encima de las capacidades de las redes móviles actuales (GSM y GPRS) y en el mejor de los casos bajan
Número 21 · Junio 2001
Comunicaciones de Telefónica I+D
177
hasta anchos de banda de 28 kbit/s, aún por encima
de lo que provee GSM y algunas implementaciones
de GPRS. Además, muchos de estos códecs exigen
demasiada capacidad computacional, como para permitir la codificación de vídeo en tiempo real en
máquinas convencionales.
21 H.263+)
Así pues, en el proceso de transición de GSM/GPRS
a redes móviles con mayor capacidad y sin mecanismos de QoS, es necesario contar con códecs de vídeo
que se ajusten al siguiente entorno de trabajo:
Alternative INTER VLC Mode (AIV, anexo S, draft
21 H.263+)
Requerimientos computacionales modestos para la
codificación en tiempo real.
Ancho de banda muy limitado (a partir de 9600
bit/s)
QoS no garantizada: variaciones en el régimen
binario y altos tiempos de latencia.
Telefónica I+D cuenta en la actualidad con un códec
de vídeo en tiempo real que se ajusta con éxito notable a estos estrictos requerimientos. Este códec, que
comenzó a desarrollarse para las primeras versiones de
MoviStar Vídeo sobre canales de datos GSM, se ha
utilizado después, también, para otros productos y
redes de datos distintas de la original (TCP/IP sobre
GPRS, por ejemplo). En la actualidad, el códec ha
alcanzado un grado de sofisticación y madurez que lo
sitúa en una posición ventajosa con respecto a otras
tecnologías existentes en el mercado, como el codificador MPEG-4 de Microsoft [7, 8].
La arquitectura general del códec está basada en el
estándar H.263 [9], e incorpora una serie de mejoras
propuestas en H.263+ [10], y unas optimizaciones
propietarias especialmente adaptadas al entorno de
trabajo descrito más arriba.
Mejoras provenientes de H.263+
Entre las mejoras incorporadas al códec, provenientes
del estándar H.263+, citamos a continuación las más
importantes:
Deblocking Filter Mode (DF, anexo J, draft 21
H.263+)
Filtro introducido en el bucle de codificación para
la eliminación del típico efecto bloque en codificación de vídeo a baja tasa de bit.
Advanced INTRA Coding Mode (AIC, anexo I, draft
Comunicaciones de Telefónica I+D
178
Número 21 · Junio 2001
Modo especial de predicción interna para imágenes
tipo INTRA. Consigue mejoras de hasta un 45 por
ciento en la codificación de tales imágenes, especialmente en formatos grandes y baja tasa de bit.
Utilización de códigos de longitud variable alternativos tipo Huffman para la codificación de los coeficientes de la DCT en imágenes tipo INTER.
Consigue mejoras del orden de un 4 por ciento en
codificación a alta calidad.
Improved PB Frames Mode (IPB, anexos G y M,
draft 21 H.263+)
Uno de los modos principales del codificador.
Consiste en la codificación de imágenes de forma
bidireccional, a partir de la imagen anterior y posterior codificadas, con un aumento del paso de
cuantificación configurable en tales imágenes. Produce mejoras muy notables en eficiencia de codificación, desde un 15 a un 40 por ciento, con variaciones de la calidad de las imágenes apenas perceptibles y disminución también muy notable del
tiempo de proceso. Esta opción sitúa a nuestro
códec muy por delante de otros códecs del mercado en eficiencia de compresión, entre ellos el
MPEG-4 de Microsoft. El modo mejorado PB
introduce problemas específicos en la transmisión
de vídeo en tiempo real.
Control del Error de Redondeo en la Interpolación a
Medio Píxel (apartados 5.1.4.3 y 6.1.2, draft 21
H.263+)
Sistema que disminuye notablemente la degradación de las imágenes en codificaciones a muy baja
tasa de bit, en las que necesariamente se deben
colocar el mínimo número de puntos de refresco
posible (imágenes tipo INTRA). Debido a esta
mejora, en este tipo de codificaciones se supera en
calidad rápidamente a otros códecs del mercado
como la implementación de MPEG-4 de Microsoft.
Sin duda, el modo mejorado Improved Frames Mode
(PB) es el que ha tenido un impacto mayor en la
mejora de la eficiencia del códec con respecto a otros
productos comerciales, aunque esta tecnología introduce problemas específicos en la codificación en tiem-
po real que se discuten más adelante en este mismo
artículo.
entre un 5 y un 10 por ciento.
2. Detección automática de cambios de secuencia
Mejoras propietarias
Estas mejoras se investigaron e implementaron enteramente dentro de Telefónica I+D [11, 12]. Son las
siguientes:
1. Método de compensación de vectores de movimiento
Es un método avanzado, frente a la mayoría de
algoritmos utilizados por otros codificadores, de
búsqueda de vectores de movimiento, cuyo objetivo es la minimización global del número de bit
generados por la codificación de los coeficientes de
la DCT de cada macrobloque, junto con su vector
de movimiento correspondiente (ver la Figura 6)
Los algoritmos de otros suministradores tratan de
minimizar únicamente la parte referente a los coeficientes de la DCT. Estos métodos son ineficientes a baja tasa de bit, debido a que la parte correspondiente a la codificación del vector de movimiento cobra mayor importancia, frente a la parte
de los coeficientes de la DCT, cuanto menor es
dicha tasa y es un efecto que no tienen en cuenta.
El algoritmo construido viene a subsanar estas pérdidas de eficiencia, tratando de minimizar el
número de bit producidos por el bloque en su globalidad, incluyendo todos sus elementos (cabeceras, coeficientes de la DCT y vectores de movimiento) a la hora de elegir el vector que minimiza
el número de bit global, obteniendo mejoras de
eficiencia de hasta el 16 por ciento y, típicamente,
Esta técnica consigue que el codificador detecte de
forma automática cuando se producen cambios de
secuencia, es decir, los momentos en que dos imágenes consecutivas tienen una correlación muy
baja. Dicho de otro modo, se detectan los cambios
de "escena". La codificación basada en la imagen
anterior de la primera imagen de una nueva escena
es muy problemática e ineficiente, siendo preferible codificarla de forma autónoma como una imagen independiente y a partir de aquí codificar por
el método habitual las imágenes de la misma
secuencia. Mediante este algoritmo se consigue la
detección de cambios de escena de manera automática, sin necesidad de la intervención del usuario durante la codificación.
Están orientadas, en especial la primera de ellas, a la
mejora de la eficiencia del códec en regímenes (ancho
de banda disponible) muy bajos, a partir de 9600
bit/s, donde algunas de las asunciones que hacen los
algoritmos estándar que operan a velocidades mayores
dejan de ser válidas.
Integración del códec en sistemas de tiempo real
Durante el desarrollo del códec, y especialmente de la
parte codificadora, se invirtió un gran esfuerzo en
optimizar el código fuente para conseguir rendimientos aceptables en arquitecturas con una capacidad
computacional reducida. Esto permitió la integración
Figura 6. Mejoras obtenidas con el método de compensación de vectores de movimiento para tres secuencias de test estándar
Número 21 · Junio 2001
Comunicaciones de Telefónica I+D
179
del codificador en las cámaras compactas de MoviStar
Vídeo, basadas en una arquitectura de PC industrial
sobre procesadores tipo Intel 486.
Aunque la mayor parte del código fuente del códec
está escrito en lenguaje C estándar, algunas de las partes críticas del mismo se trasladaron a código máquina nativo y en algunos casos aprovechan las capacidades MMX del procesador (si están disponibles).
Como resultado de las distintas optimizaciones del
código, ha sido posible alcanzar tasas de hasta 15 frames/s para canales GSM de tamaños de imagen reducidos (SubQCIF, 128x96 pixels) y más aún para canales GPRS.
Algoritmo adaptativo de control de buffer
Las redes de datos móviles actuales, que, en general,
no soportan QoS (GSM) o lo soportan de forma
rudimentaria (GPRS [13]), se caracterizan por un
comportamiento dinámico muy poco estable, como
es:
Ancho de banda reducido (a partir de 9600 bit/s) y
variable, con bruscas variaciones.
Tiempo de latencia muy alto, en torno al segundo.
Estas características hacen especialmente difícil la
transmisión de vídeo en tiempo real, puesto que los
esquemas de streaming no avanzados asumen, en
general, cierto ancho de banda mínimo garantizado y
no están preparados para variaciones bruscas de las
condiciones de transmisión.
En las experiencias de transmisión sobre redes de
datos móviles, llevadas a cabo por la Dirección de
Desarrollo de Nuevos Servicios y Aplicaciones y la
División de Tecnología Multimedia de Telefónica
I+D, se contaba, además, con las siguientes restricciones adicionales:
El modo de baja calidad en el que típicamente se
opera introduce fuertes variaciones en el flujo de
salida del codificador de vídeo.
La baja capacidad computacional disponible para el
codificador de vídeo hace impracticable el descarte
de frames.
La introducción en el códec del modo mejorado PB,
en el que cada chunk de vídeo emitido por el codifi-
Comunicaciones de Telefónica I+D
180
Número 21 · Junio 2001
cador se compone de dos frames, agrava aún más estas
condiciones.
Como respuesta al escenario descrito, la División de
Tecnología Multimedia de Telefónica I+D ha desarrollado un algoritmo de control de buffer propietario
que de forma eficiente controla la temporización en
las capturas de imagen, de forma que:
Los tiempos entre capturas estén lo más equiespaciados posible.
Las capturas se ralenticen o aceleren de acuerdo a
las variaciones del ancho de banda del canal y del
flujo de salida del codificador.
Este algoritmo, junto con las capacidades intrínsecas
del códec de vídeo de adaptación a un régimen binario más o menos constante, ha permitido espectaculares resultados de transmisión de vídeo en tiempo real
a través de GPRS, como los mostrados recientemente
en la feria SIMO 2000. El algoritmo ha sido también
incorporado a la última versión del producto MoviStar
Vídeo.
Descripción del algoritmo
Una descripción en detalle del algoritmo adaptativo
de control de buffer está más allá del ámbito y los propósitos de este artículo. Aún así, es posible explicar
someramente los principios en los que se asienta esta
tecnología.
El algoritmo de control se encarga de gobernar las
interacciones de los siguientes elementos:
El módulo de captura de imágenes, que recibe peticiones de captura y entrega asíncronamente el
resultado, tras un tiempo caracterizado por la variable aleatoria TC.
El codificador de vídeo, que acepta dos imágenes en
cada petición de compresión y devuelve un chunk
de vídeo de longitud (aleatoria) Lv con el resultado
de la compresión, tras un tiempo TV.
Un canal de comunicaciones, caracterizado (al
menos en primera aproximación) por una velocidad constante de transmisión V, con una cola de
transmisión infinita (o al menos suficiente para
albergar una cantidad razonable de información a
transmitir).
En condiciones de régimen permanente, los tiempos,
tamaños de chunk y velocidades del modelo, son
constantes, por lo que los distintos eventos del proceso de control (captura de las dos imágenes, compresión y entrega al canal) presentan la ordenación
que se muestra en la Figura 7.
Se ha asumido aquí que el conjunto cámara/codificador tiene potencia suficiente para alimentar de
forma continua al canal de transmisión, de forma
que la ocupación del mismo tiene forma de diente
de sierra, con codificación disparada en la cota de
ocupación U y captura de la primera imagen del par
disparada en la cota U'. El objetivo principal del
algoritmo de control es entonces asegurar que, dada
la cota de disparo de codificación U, los tiempos
entre capturas de dos imágenes consecutivas, denominados en la figura t1 y t2, sean iguales. De forma
trivial se comprueba que estos parámetros, junto
con la cota máxima de ocupación U', están determinados por U, V y LV según:
U' = U + LV
Figura 7. Algoritmo de control de buffer en régimen permanente, con
las hipótesis de potencia suficiente y TC < TV.
Aplicaciones para la transmisión de vídeo en
redes móviles
t1, t2 = LV /2V
Fuera de la situación de régimen permanente, el
algoritmo funciona permitiendo que los tiempos t1
y t2 oscilen dentro de unos márgenes, determinados
por el valor de estos mismos parámetros en el chunk
de vídeo anterior, esto es:
α)(t2)chunk anterior
α)(t2)chunk anterior ≤ t1 ≤ (1+α
(1-α
α)(t1)chunk anterior ≤ t2 ≤ (1+α
α)(t1)chunk anterior
(1-α
donde α es un parámetro de relajación entre 0 y 1
(típicamente 0,2). De esta forma, cambios bruscos
en V, LV o en el tiempo de codificación TV, se
amortiguan de forma geométrica. Nótese que el
modelo no depende del conocimiento a priori del
canal de comunicaciones (esto es, de la variable aleatoria V), lo que lo hace especialmente apto para
redes de ancho de banda variable como GSM y
GPRS.
Este algoritmo adaptativo se combina con la capacidad del códec de ajustarse más o menos estrechamente a una tasa de bit dada, independientemente
de los incrementos del contenido visual, debidos,
por ejemplo, a movimientos de la cámara o aparición de nuevos objetos en la escena.
Las tecnologías descritas en los apartados anteriores se
han integrado en diversos productos dentro de los
sucesivos proyectos de desarrollo mantenidos en Telefónica. Así, Telefónica Móviles España se convirtió en
pionera en el área de la televigilancia a través de GSM,
con MoviStar Vídeo, y ha vuelto a colocarse a la vanguardia tecnológica de la transmisión de vídeo por
GPRS, con los prototipos mostrados recientemente
en la feria SIMO 2000.
El futuro, con la promesa de la red UMTS, dotada de
mayor ancho de banda y negociación de QoS, y el
advenimiento de dispositivos móviles multimedia,
como PDAs y teléfonos móviles de tercera generación, auguran un brillante futuro para la investigación
en el campo de la transmisión de vídeo sobre redes
móviles.
MoviStar Vídeo
MoviStar Vídeo, del que se liberaron las primeras versiones en el año 1997 y ha sido constantemente perfeccionado hasta la actualidad, consiste en un sistema
completo de televigilancia a través de GSM, que comprende los siguientes elementos:
Una estación de control, instalada generalmente en
un ordenador PC estándar, dotada de uno o más
teléfonos móviles para las comunicaciones vía
GSM.
Número 21 · Junio 2001
Comunicaciones de Telefónica I+D
181
Figura 8. Monitorización de una cámara remota en el programa MoviStar Vídeo.
Una o más cámaras de televigilancia, equipos compactos diseñados por Telefónica I+D, que contienen un dispositivo de captura de imágenes, un procesador basado en arquitectura PC104 y un teléfono móvil de ingeniería GSM.
La estación de control puede establecer comunicación
con las cámaras registradas en su base de datos y
monitorizarlas en tiempo real, controlando remotamente los parámetros de calidad y tamaño del vídeo
transmitido, entre otros (ver la Figura 8). El sistema
también incluye un módulo de gestión, mediante
SMS, de alarmas y de comunicación entre las cámaras
y la estación de control.
Las cámaras son equipos compactos diseñados enteramente por Telefónica (ver la Figura 9) e incorporan
en un espacio de dimensiones muy reducidas una
cámara de vídeo digital, una tarjeta de adquisición de
vídeo, una placa tipo PC104 con un procesador
AMD 5x86 a 133 MHz y un teléfono móvil de ingeniería. Estas cámaras trabajar con el sistema operativo
embebido Pharlap basado en MS-DOS, en el cual se
ejecuta el programa de control y el codificador de
vídeo propietario desarrollado por la División de Tecnología Multimedia de Telefónica I+D.
A partir de la versión 4.0, MoviStar Vídeo incorpora
en su codificador el modo mejorado PB, que, junto
con el algoritmo de control adaptativo de buffer, ha
permitido alcanzar velocidades de refresco de 15 frames/s en secuencias de baja resolución. Los autores no
conocen ninguna otra tecnología, comercial o experimental, que haya alcanzado unas cotas tan altas de
eficiencia para canales GSM de 9600 bit/s.
MoviStar WebCam
MoviStar WebCam es un desarrollo basado en
MoviStar Vídeo que permite distribuir por Internet
las imágenes capturadas desde una cámara remota de
MoviStar Vídeo mediante tecnologías comerciales de
streaming para Internet, como Netshow Server de
Microsoft (ver la Figura 10).
MoviStar WebCam ha sido exhibido en la feria SIMO
2000.
Aplicación de vídeo sobre GPRS
Durante el SIMO 2000, y aprovechando la instalación por parte de Telefónica Móviles de una maqueta
GPRS en el recinto ferial, se exhibió una aplicación
peer to peer de transmisión de vídeo sobre GPRS. Esta
aplicación, se compone de:
Un programa cliente instalado sobre un ordenador
PC portátil, con conexión a Internet mediante un
teléfono móvil GPRS.
Un programa servidor, con dirección pública de
Internet, corriendo sobre un PC conectado a un
dispositivo de captura de vídeo.
Figura 9. Cámara compacta de MoviStar Vídeo junto con su alimentador.
Comunicaciones de Telefónica I+D
182
Número 21 · Junio 2001
Figura 10. Ejemplo de acceso, mediante MoviStar WebCam, a una cámara MoviStar Vïdeo desde un browser de Internet
La transmisión de vídeo se efectúa sobre un canal de
comunicaciones TCP/IP. A pesar de la ineficiencia
intrínseca de este protocolo de transporte para la
transmisión de vídeo en tiempo real, la utilización del
códec avanzado y de un algoritmo adaptativo de control de buffer permiten a la aplicación alcanzar tasas
regulares de hasta 15 frames/s para una resolución de
176x144 pixels.
La parte cliente de la aplicación presenta una interfaz
gráfica futurista (ver la Figura 11), que sugiere el
advenimiento de futuros dispositivos multimedia
basados en UMTS.
A medida que la red GPRS ofrezca más prestaciones,
las aplicaciones desarrolladas se adaptarán para aprovechar esas mejoras de transmisión, ofreciendo servi-
cios de más y mayor ámbito de aplicación.
CONCLUSIONES
En el artículo se han enumerado y explicado las nuevas tecnologías que se están desarrollando en los foros
de Internet, tecnologías que están siendo utilizadas en
la estandarización de los servicios de streaming en
3GPP y 3GPP2. Protocolos tales como RTSP, RTP o
RSVP, que, junto con la garantía de calidad de servicio en las redes, se utilizarán en servidores y terminales para el control de la transferencia de contenidos
multimedia, en aplicaciones tales como servidores de
vídeo o videoconferencia. No obstante, existen otros
sistemas propietarios, como los de Microsoft o RealNetworks, que competirán en el establecimiento de
Figura 11. Interfaz gráfica del programa cliente de la aplicación de vídeo sobre GPRS
Número 21 · Junio 2001
Comunicaciones de Telefónica I+D
183
los servicios; habrá que estar muy atento a la evolución del mercado, que será a la postre quien marque
las tendencias.
Por otra parte, no es necesario esperar a las redes de 3ª
generación para ofrecer servicios de streaming de con-
tenidos. Si bien, los servicios de arquitectura clienteservidor son difíciles de ofrecer, debido a las características de las redes actuales, sí es posible realizar aplicaciones peer-to-peer en las que el emisor se adapte al
canal para la transmisión de contenidos.
Glosario de Acrónimos
3GPP 3rd Generation Partnership Project
3GPP2 3rd Generation Partnership Project 2
RSVPl ReSource Reservation Protocol
RTCP Real-Time Transport Control Protocol
ATM Asynchronous Transfer Mode
GPRS General Packet Radio Service
RTP Real Time Protocol
RTSP Real Time Streaming Protocol
GSM Global System for Mobile Communication
IETF Internet Engineering Task Force
JPEG Joint Photographic Experts Group
SDES Source Description
SDP Session Description Protocol
SR Sender Report
MPEG Moving Picture Experts Group
PCM Pulse-Code Modulation
QoS Quality of Service
RFC Request For Comments
RR Receiver Report
UMTS Universal Mobile Telecommunications System
URI Uniform Resource Identifier
URL Unified Resource Locator
W3C World Wide Web Consortium
Referencias
1.
2.
3.
4.
5.
6.
7.
8.
3GPP: Qos Concept and Architecture. 3G TS 23.107.
CHUNLEI LIU: Multimedia Over IP: RSVP, RTP, RTCP, RTSP
RFC 1633: Integrated Services Architecture.
RFC 1889: RTP: A Transport Protocol for Real-Time
Applications.
RFC 1890: RTP Profile for Audio and Video Conferences
with Minimal Control.
RFC 2205: Resource ReSerVation Protocol (RSVP). Version 1
Functional Specification
ISO: MPEG-4 Video Group, Generic coding of audio-visual
objects: Part 2 Visual. ISO/IEC JTC1/SC29/WG11 N1902,
FDIS of ISO/IEC 14-496-2, Atlantic City, November 1998.
R. KOENEN (ed.): Overview of the MPEG-4 Standard.
ISO/IEC JTC1/SC29/WG11 N3747, La Baule, October 2000.
http://www.cselt.it/mpeg/standards/mpeg-4/mpeg
4.htm
Comunicaciones de Telefónica I+D
184
Número 21 · Junio 2001
9. ITU-T: Video Coding for Low Bit Rate Communication.
Recommendation H.263, May 1996.
10. ITU-T: Video Coding for Low Bit Rate Communication.
Recommendation H.263+, draft 21, January 1998.
11. J. SASTRE, A. FERRERAS, J.F. HERNÁNDEZ-GIL: Motion
Vector Size Compensation Based Method For Very Low Bit Rate Video
Coding. Proc. International Picture Coding Symposium PCS’99. Portland,
April 1999.
12. J. SASTRE, A..FERRERAS, J.F HERNÁNDEZ-GIL: Motion Vector Size
Compensation Based Method For Very Low Bit Rate Video Coding. IEEE
Transactions on Circuits and Systems for Video Technology. Vol. 10, No. 7,
October 2000.
13. ETSI: Digital cellular telecommunications system (Phase 2+), General
Packet Radio Service (GPRS), Service description, Stage 2. GSM 03.60
version 7.4.1, Release 1998.