NOS INTERESA

TMB . 48

NOS INTERESA

TMB . 49

La evolución y abaratamiento de latecnología en el mundo IT ha permitidola sustitución de los enlaces PDH ySDH por otros basados en IP. Losanchos de banda han ido incrementán-dose al tiempo que su precio bajaba.Ahora la tecnología de red se perfilacomo clara candidata a futuro parasustituir al cableado basado en la fami-lia SDI. Analizamos a continuación losdiferentes estándares y tendencias.

Durante muchos años hablar devídeo digital en entornos de producciónha sido hablar de la familia SDI:

- Versión eléctrica (Imagen 1)

- Versión óptica. SMPTE 296-2006:Encapsulado de hasta 3G-SDI sobrefibra.

Hoy en día con la convergencia deinformática y audiovisual las cosas

están cambiando y ya hay dos están-dares que se postulan como alternati-va al cableado SDI:

- SMPTE 2022-6: Transport of HighBit Rate Media Signals over IPNetworks (HBRMT)

- IEEE 802.1: Audio Video Bridging(AVB)

El sueño de poder sustituir una gran

matriz SDI por switchers y routers yaes posible.

CARACTERÍSTICAS DEL TRANSPORTE

DE VÍDEO SIN COMPRIMIR SOBRE RED

Estas son algunas de las caracterís-ticas que debería tener:

1.Algunas ya disponibles para SDI:

a. Vídeo sin comprimir y sin pérdidade cuadros

Txt: Vicente Pla Ferri

Imagen 1

b. Baja latencia

c. No propietario

2.Otras que lo mejoren:

a. Mayor flexibilidad y agilidad

b. Transporte a través de un únicocable de: vídeo, metadatos, controly sincronismos.

c. Conmutación entre señal principaly redundada sin cortes.

d. Bajo coste gracias a la economíade escala

El mundo de las redes tradicional-mente ha tenido algunos problemasque impactan muy negativamente paraconseguir estos requerimientos:

- Pérdida de paquetes

- Errores de ráfaga

- Recepción con orden incorrecto depaquetes

- Variación del retardo

- El rendimiento de la red puede variaren función de la congestión de ésta através del tiempo.

De aquí que siempre habrá quetener en cuenta todos estos factoresde cara a abordar un diseño. Otro fac-tor muy importante es decidir si quere-mos que nuestra infraestructuraaudiovisual en red esté basada enelectrónica estándar o por el contrarioqueremos utilizar equipamiento especí-fico (Imagen 2).

SMPTE 2022 está basado en IP(capa 3) mientras que AVB es de capa2, es decir, no permite el direcciona-miento a través de redes públicas.Para transportar AVB es necesariodisponer de conmutadores específicospara AVB. A cambio, AVB está pensa-do para trabajar con audio y vídeo y nonecesita de otras normas externas alestándar para manejar la calidad deservicio y la sincronía entre señales.Analicemos en detalle cada una deellas.

SMPTE 2022Aborda la transmisión de señales de

TV a través de redes IP. Sus inicios se

remontan a principios de siglo cuandoel Pro-MPEG Forum trabajó en el ‘Codeof Practice #3’ (Pro-MPEG COP#3).Fue diseñado para permitir corregirlos problemas de pérdidas de paque-tes en el transporte de señales devídeo sobre redes IP, sin la necesidadde retransmisión.

Evolución

Fue normalizada en 2007 para eltransporte de vídeo sobre IP:

- SMPTE 2022-1: “Forward ErrorCorrection for Real-timeVideo/Audio Transport Over IPNetworks”. Define una protección deerrores FEC para la transmisión deflujos de vídeo sobre IP.

Al principio sólo para señales MPEG-2 TS de tasa binaria constante:

- SMPTE 2022-2: “UnidirectionalTransport of Constant Bit RateMPEG-2 Transport Streams on IPNetworks”. Especifica cómo encap-sular en paquetes IP señales devideo comprimidas encapsuladas enMPEG-2 TS. El estándar cubre lacapa de transporte (RTP y UDP) asícomo temas de temporización ytamaños de buffers.

En 2010 se añadió la posibilidad detrabajar con MPEG-2 TS a tasas bina-rias variables:

- SMPTE 2022-3: “UnidirectionalTransport of Variable Bit RateMPEG-2 Transport Streams on IPNetworks”. Define la forma de trans-portar por IP paquetes de MPEG-2TS de tasa binaria variable de formaque ésta sea constante entre men-sajes PCR (piecewise constant).

- SMPTE 2022-4: “UnidirectionalTransport of Non-PiecewiseConstant Variable Bit Rate MPEG-2Streams on IP Networks”. Es muysimilar a la parte 3, pero sin restric-ciones a nivel de tasas binarias.

Finalmente se añadieron las partesque ahora nos interesan; las del trans-porte de señales de vídeo sin compri-mir:

- SMPTE 2022-5: “Forward ErrorCorrection for High Bit Rate MediaTransport Over IP Networks”.Extiende la parte 1 del estándar aseñales de hasta 3 Gbits/s o más.

- SMPTE 2022-6: “Transport of HighBit Rate Media Signals over IPNetworks (HBRMT)” Especifica laforma de transmitir por IP señalesde vídeos sin comprimir.

- SMPTE 2022-7: “SeamlessProtection Switching of SMPTE ST2022 IP Datagrams” Define laforma de sincronizar dos señalesque viajan por distintos caminos

TMB . 50

NOS INTERESA

Imagen 2

para poder realizar una conmutaciónsin cortes entre ellas.

También se propuso la parte 8 delestándar para encapsular JPEG2000en MPEG2-TS sobre IP pero finalmentese abordó desde el Video ServicesForum (VSF).

SMPTE 2022-6: TRANSPORT OF

HIGH BIT RATE MEDIA SIGNALS OVER

IP NET WORKS (HBRMT).Cuando trabajamos con video en

directo hay determinados aspectos atener en cuenta. El primero de ellossería cómo abordar el mapeado deseñales de un entorno SDI sobre lacarga útil de un datagrama IP.

SMPTE 2022-6 lo define para seña-les SD-SDI, HD-SDI y 3G-SDI sin com-primir sobre un interface IP. Se intentapues sustituir el tradicional cableado

coaxial de la familia SDI por un sistemaen estrella basado en IP (Imagen 3)

Como se observa en la pila de proto-colos utilizados, la norma se basa entransmitir vídeo a través de equipa-miento IP estándar. Como es tradicio-nal en señales de alta tasa binaria, laseñal audiovisual se transmite a travésde UDP y por tanto no se garantiza laconfirmación de entrega ni el controlde flujo. Eso sí, mediante RTP se añademecanismos para la compensación del

jitter y detección de paquetes que lle-gan fuera de orden a consta de intro-ducir un pequeño retardo. Si adicional-mente se necesitara de control deerrores, habría que introducir un códi-go FEC mediante la utilización deSMPTE 2022-5, que añadiría másretardo cuanto más robusto fuera.

. Quedan fuera de la norma aspectosimportantes como son la calidad delservicio de la red (QoS) y la sincroniza-ción de señales.

OTRO FACTOR MUY IMPORTANTE ES DECI-DIR SI QUEREMOS QUE NUESTRA INFRAES-TRUCTURA AUDIOVISUAL EN RED ESTÉBASADA EN ELECTRÓNICA ESTÁNDAR OPOR EL CONTRARIO QUEREMOS UTILIZAREQUIPAMIENTO ESPECÍFICO.

NOS INTERESA

TMB . 52

Calidad de Servicio (QoS).

El diseño y configuración de la infra-estructura de red será clave paragarantizar la calidad del servicio (QoS).En toda red de datos conmutados exis-ten una serie limitaciones, que si no setoman las acciones oportunas, afec-tarán al servicio: bajo rendimiento de laelectrónica de red, pérdida de paque-tes, retardos, latencia, jitter y pérdidade orden de los paquetes entregados,entre otros. Para evitarlos habrá quedimensionar adecuadamente nuestrared y definir políticas de calidad del ser-vicio. De esta forma nuestra infraes-tructura soportará los nuevos servi-cios de vídeo.

Redes multicast.

Una de las grandes ventajas que nosbrindan las redes IP es el uso de gru-pos multicast. Esta forma de distribu-ción permite que los conmutadores yenrutadores distribuyan la señal de ungrupo a todo aquel cliente que se hayasuscrito a él.

La tecnología multicast permite, quedesde un equipo servidor hasta laelectrónica de red, sólo viaje una répli-ca de la señal con el consiguiente aho-rro de ancho de banda. Lo ideal serápues definir un grupo multicast paracada una de las fuentes de señal. Deese modo cualquier cliente puede reci-bir la señal con tan sólo suscribirse algrupo correspondiente.

El principal problema con el que nosencontramos al trabajar en multicastes que para IP v4 las redes públicas nopermiten su uso.

No obstante las ventajas son cuan-tiosas. Gracias a la electrónica de red

podremos prescindir de matrices, dis-tribuidores, etc (Imagen 4).

Conmutación sin cortes entre seña-les.

Gracias a SMPTE 2022-7 podremosrealizar la conmutación sin cortesentre una seña principal y otra reservaaunque los caminos de llegada deambas difieran en lo que al retardointroducido se refiere.

Sincronización entre señales.

Si en el mundo SDI la sincronizaciónsiempre se ha hecho mediante la utili-zación de señales de Black Burst oTriSync mediante cable separado, en elmundo de las redes tradicionalmentese ha utilizado Network Time Protocol(NTP). Este protocolo fue diseñadopara la sincronización horaria entremáquinas y su resolución llega hastalos milisegundos. ¿Qué pasa entoncessi necesitamos más precisión?

En 2002 se desarrolló la versión 1del estándar IEEE1588, también cono-cido como Precise Time Protocol(PTP). Se trata de un protocolo multi-cast (lo que lo inutilizaba para redes

públicas) capaz de ofrecer una preci-sión de 10 us.

Posteriormente apareció en 2008 laversión 2 del estándar con una resolu-ción de unos 30 ns. y que también eracapaz de transmitirse vía unicast (y portanto por redes públicas). Otra de lasventajas frente a NTP es que es capazde saltarse las colas de enrutado/con-mutación si se dispone de electrónicade red compatible con PTP (Imagen 5).

A finales de 2014 se aprobó SMPTE2059-2 que se trata de un perfil deIEEE1588 con las opciones necesariaspara trabajar con vídeo sin comprimir.

IEEE 802.1: AUDIO VIDEO

BRIDGING ( AVB)Abordemos ahora la otra alternativa

que nos ofrece el mercado.

Audio Video Bridging (AVB) es el con-junto de las normas técnicas elabora-das en el Institute of Electrical andElectronics Engineers (IEEE) por elGrupo de Trabajo de “Audio VideoBridging” dentro del Comité deNormas IEEE 802.1. La misión de AVB

SE PROPUSO LA PARTE 8 DEL ESTÁNDARPARA ENCAPSULAR JPEG2000 ENMPEG2-TS SOBRE IP PERO FINALMENTESE ABORDÓ DESDE EL VIDEO SERVICESFORUM (VSF).

NOS INTERESA

Imagen 3

Imagen 4

TMB . 53

es proporcionar las especificacionesque permitan servicios de streamingsincronizados de baja latencia a travésde redes IEEE 802.1

Para ello se desarrollaron lassiguientes especificaciones que seaprobaron en 2011:

- IEEE 802.1AS: Temporización ySincronización para aplicacionessensibles al tiempo (gPTP),

- IEEE 802.1Qat: Protocolo de reservade Stream (SRP),

- IEEE 802.1Qav: Transmisión y colaspara Streams sensibles al tiempo(FQTSS)

- IEEE 802.1BA: Sistemas de AudioVideo Bridging

(Imagen 6)

Posteriormente en 2012 surge laAVnu Alliance, una asociación que per-sigue conseguir, mediante la utilizaciónde estándares abiertos, conexiones enred con baja latencia y sincronizadastemporalmente. Bajo este paraguas seengloban tecnologías de los mercadosde: Automoción, Audiovisual, Industrialy Electrónica de Consumo (Imagen 7).

¿QUÉ ES AVB?AVB es el intento de reemplazar la

complejidad física del cableado tradi-cional SDI, y los problemas de las pri-meras implementaciones audiovisua-les sobre red, por un conjunto de solu-ciones abiertas basadas en estánda-res que permitan la interoperabilidadentre diferentes plataformas (Imagen8).

Fue pensado para la evolución deEthernet, y su familia, de forma quepermitiera el soporte de aplicaciones

en tiempo real de audio, vídeo y control.Es el nombre común que toman el con-junto de estándares desarrollados porel grupo de trabajo “IEEE 802.1 AudioVideo Bridging Task Group”. Su trabajose basa en 3 pilares:

1.Alta precisión en la temporizaciónpara permitir:

a. El soporte de relojes de bajo jitter

b. Sincronización de varios streams.

2.Reserva de ancho de banda: permite

a una aplicación de consumo audiovi-sual notificar a los dispositivos de redque recursos necesitará para que seproceda a su reserva.

3.Reglas de colas y envíos: aseguranque un stream pueda pasar por lared dentro de los retardos especifi-cados en la reserva.

¿QUÉ ES TSN?

Time Sensitive Networking es la evo-lución de AVB para expandir el rango,funcionalidad y aplicaciones del están-dar. TSN es el nuevo nombre para laevolución de las normas desarrolladaspor AVB. Ofrecerá compatibilidadhacia atrás con AVB, pero añadiendonuevas funcionalidades como parte delestándar. Entre ellas estarán:

1.Tolerancia a fallos y redundancia

2.Mejoras en temporización y latencia.

NOS INTERESA

Imagen 5

Imagen 6

Imagen 7

NOS INTERESA

TMB . 54

FUNCIONAMIENTO

La implementación de AVB se basaen “pequeñas” extensiones sobre lasdirecciones MAC y conmutadores decapa 2 de tipo estándar (Imagen 9).

Estos “pequeños” cambios permitenque dispositivos AVB y no AVB se pue-dan comunicar entre ellos medianteframes 802 estándar. En ese caso,como se aprecia en la figura, sólo losdispositivos AVB seráncapaces de:

1.Reservar los recursos dered necesarios.

2.Sincronizar los streams.

En la norma IEEE802.1BA se describe laconfiguración por defectode los dispositivos AVBdentro de una red y cómodeterminar si los dispositi-vos soportan AVB.Cualquier dispositivo no-AVB es identificado conuna etiqueta para evitarerrores.

SINCRONIZ ACIÓN

El concepto clave de AVBes que todos los dispositi-vos de la red reciban la sin-cronía maestra. A partir deahí funcionan con su propioreloj interno que se re-sin-croniza con el maestro una vez porsegundo. Entre todos los dispositivosse decide, de forma automática, el quemayor precisión de reloj tiene y senombra como gran-maestro. En casode fallo o desconexión de la red delgran-maestro el sistema decide cuál losustituirá.

Una vez que un dispositivo ha sincro-nizado con el gran-maestro, sincroni-zará su reproducción con él.Posteriormente añadirá una marcacon el tiempo de presentación (displaytimestamp) de forma que, si el mismocontenido llega a dos dispositivos dis-tintos, estos la presentarán al mismotiempo (imaginemos por ejemplo dosaltavoces de un par estéreo).

Al igual que SMPTE-2022, la sin-

cronía está basada en el estándar IEEE1588 (PTP), pero en este caso las dife-rencias son suficientemente importan-tes como para justificar un estándardiferente: IEEE 802.1AS (tambiénconocido como gPTP). La sincroníagPTP sólo funcionará si todos los con-mutadores entre fuente y destino sonAVB.

GESTIÓN DEL TRÁFICO

En la mayoría de los hogares de hoyen día, salvo que se tenga contratadavoz por IP o IPTV, todos los datos tie-nen el mismo nivel de prioridad. El trá-fico web tiene el mismo tratamientoque el audiovisual, por tanto, si haymucho uso de la red en el hogar cau-

sará un retardo en laentrega de paquetes deaudio o vídeo que cau-sará un pequeño corteperceptible.

Para evitarlo, AVB per-mite que el dispositivo deorigen, el/los conmuta-dores intermedios, yel/los dispositivos dedestino, hablen entreellos y reserven un anchode banda para que lacomunicación no se veaafectada por el tráfico dela red. Existe una reservade ancho de bandadurante el tiempo quedura la reproducción delcontenido. Cuando acaba

la comunicación entre dispositivos seprocede a liberar el ancho de bandareservado. Si en el proceso de la nego-ciación entre dispositivos se detectaraque no existen recursos suficientespara reservar el ancho de banda nece-sario, se comunica al transmisor y des-tinatario del contenido para que tomenlas acciones necesarias que eviten lainterrupción del servicio (bajar resolu-ción, frecuencia de muestreo, etc.).

En la especificación IEEE 802.1Qavse explica cómo utilizar el estándar801.Q (que especifica el marcado detráfico en trunks) para la gestión deltráfico en AVB.

CONTROLES DE ADMISIÓN

Aún con un exigente sistema de ges-tión del tráfico entregar los paquetes

UNA ASOCIACIÓN QUE PERSIGUE CONSE-GUIR, MEDIANTE LA UTILIZACIÓN DEESTÁNDARES ABIERTOS, CONEXIONES ENRED CON BAJA LATENCIA Y SINCRONIZA-DAS TEMPORALMENTE.

Imagen 8

de datos, con baja laten-cia y bajo jitter, sólo esposible si los recursos dered están disponibles a lolargo de toda la cadenade transmisión. AVBimplementa un protocolode reserva de streamsque se especifica en802.Qat “Stream Reser-vation Protocol (SRP)”.

En SRP los elementostransmisores de conteni-do se denominan‘Talkers’ y los receptores‘Listeners’. Ambos sonlos responsables degarantizar que el caminoesté disponible y reservar los recursosnecesarios. El proceso es el siguiente:

1.El ‘Talker’ envía un mensaje SRP‘Talker advertise’ con:

a. Identificador del Stream:

i. Dirección MAC

ii. Identificador único del ‘Talker’(16 bits)

b. Requerimientos de calidad de ser-vicio (QoS):

i. Tipo de tráfico

ii. Tasa binaria

iii.Latencia

2.Los dispositivos de red reciben elmensaje y comprueban si tienen dis-ponible el ancho de banda requeridoen la salida que lleva al ‘Listener’:

a. Sí: El mensaje se propaga hastael siguiente equipo.

b. No: Responden al ‘Talker’ que noes posible.

3.Cuando un ‘Listener’ recibe un‘Talker Advertise’ responde con unmensaje ‘Listener Ready’:

a. Informa al ‘Talker’ de la latenciatotal del camino.

b. Los dispositivos de red interme-dios reservan los recursos de rednecesarios para que esta transmi-sión se pueda llevar a cabo.

4.Cuando el ‘Talker’ recibe el ‘ListenerReady’ inicia la transmisión.

PROTOCOLOS DE CAPAS SUPERIORES

Asociados a AVB aparecen toda unaserie de protocolos de gran utilidad:

- IEEE 1722 “AVB Transport Protocol(AVB-TP):

- Define streams interoperables conformatos varios formatos y encap-sulaciones (Raw, MPEG-2 TS,Firewire, etc)

- Mecanismos de sincronización demedia

- Asignación de direcciones multi-cast

- IEEE 1722.1 “Device Discovery,Enumeration, ConnectionManagement and Control Protocolfor 1722-Based Devices”

- IEEE 1733 “layer 3 transport proto-col for time-sensitive applications in

local area networks”

- Define la forma deencapsular RTP sobre AVB.

- RTP sobre AVB utili-za paquetes conocidoscomo RTCP.

CONCLUSIÓN

Las redes IP empiezan aser una forma rentable detransportar señales de pro-ducción sin comprimir den-tro de una infraestructuraaudiovisual. Hemos analiza-do las características delos dos estándares más

usados hoy en día:

- SMPTE 2022 que puede ser utiliza-do a través de redes IP estándar,pero que obliga a definir políticas deQoS y a la utilización de un estándarexterno para la sincronización destreams.

- AVB, con retardos menores, que escapaz de a través de Capa 2, ymediante electrónica de red específi-ca, gestionar de forma transparentepara el usuario la QoS y sincroniza-ción.

Cada fabricante apuesta por una deellas, pero técnicamente parece quede cara al usuario final será más sen-cillo de implementar:

- AVB para instalaciones locales (LAN)

- SMPTE 2022 para el transporte através de redes públicas (WAN)

EL TRÁFICO WEB TIENE EL MISMO TRATA-MIENTO QUE EL AUDIOVISUAL, PORTANTO, SI HAY MUCHO USO DE LA RED ENEL HOGAR CAUSARÁ UN RETARDO EN LAENTREGA DE PAQUETES DE AUDIO O VÍDEOQUE CAUSARÁ UN PEQUEÑO CORTE PER-CEPTIBLE.

Imagen 9

TMB . 55

NOS INTERESA