sistemas de acceso opticos: norma dvb-c página...

Sistemas de Acceso Opticos: Norma DVB-C Página III.1

SISTEMAS DE ACCESO OPTICOS / Diciembre_2001 (Página 1 de 36)

3_ NORMA DVB-C En gran parte del mundo

(1), la televisión digital sobre redes-HFC (“Hybrid Fiber Coaxial”), ya abordada en el capítulo anterior, se basará en el estándar europeo ETS 300 429, “Digital Broadcasting Systems for Television, Sound and Data services; Framing structure, Channel coding and Modulation for Cable systems”, elaborado bajo el auspicio de la Unión Europea de Radiodifusión (EBU) y el Instituto Europeo de Estandarización de Telecomunicaciones (ETSI). Dicho estándar se resumen en la siguiente Figura:

Figura 3.1. Estándar ETS 300 429 : Diagrama de Bloques

(1) Amén del estándar europeo, basado en la norma DVB (“Digital Video Broadcasting”), también existe un estándar americano, basado en la norma ATSC (“Advanced Television Standards Committee”).

RELOJ

MPEG-2

INTERFAZFISICO (BB)

Desinversiòn SYNC1DESALEATORIZD.

DescodificadorREED-SOLOMON

ENTRELAZADOCONVOLUCIONAL

(8)

(8)

(8)(8)

CONVERSOR

m -> BYTE (Q)DECODIFICADOR

DIFERENCIAL

(I)FORMACIONBANDA BASE

(m)

(Q)

DemoduladorQAMCABLE (RF)

S

CABLE (RF)ModuladorQAM

(m)

(I)

ECUALIZADOR

(m)CODIFICADORDIFERENCIAL

(m)

CONVERSOR

BYTE -> m

(8)

(8)

S

RECEPTOR DIGITAL

ENTRELAZADOCONVOLUCIONAL

CodificadorREED-SOLOMON

Inversiòn SYNC1ALEATORIZADOR

INTERFAZFISICO (BB)

CABECERA DE CABLE

(8) (8) (8) MPEG-2

RELOJ



Como se desprende de dicha Figura, el estándar comienza por la formación de la Banda Base de entrada, de acuerdo con la capa de transporte MPEG-2 (“Moving Pictures Experts Group”) que, a continuación, se somete a un proceso de Aleatorización, a fin de conformar su espectro. Posteriormente, y de acuerdo con la técnica-FEC (“Forward Error Correction”), a la trama binaria resultante se le aplica una codificación Reed-Solomon y un Entrelazado convolucional, de cara a la detección y corrección de errores en el extremo receptor. Y, por último, se conforma la banda base que es modulada en QAM (“Quadrature Amplitude Modulation”): conver-sión de octectos (bytes) en símbolos-QAM (de m bits cada uno, según el número de estados de la constelación), filtra-do en coseno alzado, y modulación-QAM, propiamente dicha. Asímismo, y como se observa en la Figura 3.1, en el lado receptor se llevan a cabo los procesos recíprocos, a fin de obtener las señales MPEG-2 iniciales.

3_1_ CODIGO FUENTE: Multiplaje “MPEG-2 Transport Stream” De acuerdo con el estándar ISO/IEC 13818-1, la codificación del vídeo y audio (según, respectivamente, los estánda-res ISO/IEC 13818-2 y 13818-3, también conocidos como “MPEG-2/Vídeo” y “MPEG-2/Audio”) genera unos flujos elementales que se segmentan en paquetes de longitud variable, denominados PES (“Packetized Elementary Stream”), tal y como se ilustra en la Figura 3.2. A su vez, un flujo de paquetes_PES con un mismo PID (“Packet IDentifier”) constituye un “PES Streams”. Cada PID identifica, por ejemplo, el vídeo o audio de cada programa. Distintos “PES Streams”, correspondientes a diferentes programas, se multiplexan en un único flujo, denomimado “Transport Streams” (TS), que se estructura en base a paquetes de 188 bytes de longitud, conocidos como “MPEG-2/TS”, cuya sintaxis se refleja en la Figura 3.3. Al respecto, el estándar especifica que el primer byte de la cabecera de un paquete_PES ha de coincidir con el primer byte de la carga útil de un paquete MPEG-2/TS (2). (2) También pueden existir paquetes MPEG-2/TS vacíos (“null packets”).



3.2. Paquetes “PES” y “MPEG-2/TS”

Un paquete MEG-2/TS puede transportar bien paquetes_PES (con información de vídeo y audio, por ejemplo), bien información_PSI (“Program Specific Information”, que establece la correspondencia entre los progrmas y los PID asociados), o bien datos “privados”, que escapan a la especificación ISO/IEC 1318-1 (para, por ejemplo, aplicaciones interactivas: telebanca, telecompra,..) (3).

(3) Generalmente, en un “Transport Stream” habrá paquetes (MPEG-2/TS) que transporten paquetes_PES, otros que lleven secciones_PSI, y,

también, algunos que acarreen datos “privados” (bien directamente, en el propio paquete MPEG-2/TS, o bien indirectamente, en los pa-quetes_PES y/o en las secciones_PSI).

CODIFICADOR de AUDIO(ISO/IEC 13818-3)

CODIFICADOR de VIDEO(ISO/IEC 13818-2)

PAQUETIZADOR

PAQUETIZADOR

AUDIO-1

VIDEO-1

PROGRAMA-n

PROGRAMA-1

PROGRAMA-2

X

M

U

MPEG-2/TS



Figura 3.3. Sintaxis del paquete MPEG-2/TS

Para mayor detalle, se sugiere consultar el Anexo adjunto al presente capítulo (Anexo 3.A: “Sintaxis y Semántica de los Paquetes MPEG-2/TS y PES”), donde se refleja con cierto nivel de detalle los conceptos arriba apuntados, especi-ficados en la recomendación ISO/IEC 1318-1. 3_2_ CODIFICACION DE CANAL

HEADER PAYLOADHEADER PAYLOAD HEADER PAYLOAD HEADER PAYLOAD

ITWOFFSET

DTS_NEXT_AUSPLICE

TYPE

188 bytes188 bytes 188 bytes 188 bytes

SYNCBYTE

TRANSPORTERROR

INDICATOR

TRANSPORTSCRAMBLING

CONTROL

TRANSPORTPRIORITY

PIDPAYLOAD

UNIT STARTINDICATOR

ADAPTATIONFIELD

CONTINUITYCOUNTER

ADAPTATIONFIELD

CONTROL

411 1 13 2 2

ADAPTATIONFIELD

LENGTH

ELEMENTARYSTREAM

PRIORITY

5

RANDOM ACCESS

INDICATOR

DISCONTINUITYINDICATOR

STUFFINGBYTES

OPTIONALFIELDS

FLAGS

PIECEWISERATE

8

1 1

PROGRAMCLOCK

REFERENCE

TRANSPORTPRIVATE

DATA

SPLICE COUNTDOWN

OPCR

3

OPTIONALFIELDS

ADPTATIONFIELDS

EXTENSION LENGTH

TRANSPORTPRIVATE DATA

LENGTHFLAGS

ITW_VALIDFLAG

8

84242

15

1

88

2 331 22 4



Como se observa en la Figura 3.1, la codificación de canal contempla tanto la Aleatorización (para la conformación del espectro), como un código de protección de errores tipo-FEC (el Reed-Solomon, concretamente), y un Entrelazado convolucional (para la protección frente a errores en ráfaga) (4). 3_2_1_ Aleatorización Como ya se ha apuntado, la finalidad de la Aleatorización es conformar el espectro, tal que éste se distribuya unifor-memente (espectro “blanqueado”, denso y limitado), en lugar de concentrarse en rayas espectrales periódicas (lo cual acentuaría la interferencia entre símbolos). A tal fin, es necesario convertir el código fuente (el “Transport Stream”) en una señal casual (aleatoria) (5), para lo cual la ETS 300 429 especifica una aleatorización tipo “set-reset”, que se ilustra en la Figura 3.4.

Figura 3.4. Ilustración de la Aleatorización tipo “set-reset”

(4) En canales más severos que el cable (los de tipo radioeléctrico, por ejemplo, bien terrenales o bien por satélite) la codificación de canal

contempla, además, un Código Convolucional (de Viterbi), configurándose así una concatenación de códigos: un “inner code” (el de Viberbi) y un “outer code” (el Reed-Solomon). Junto con el Entrelazado, tal concatenación de códigos trabaja a 3/4 dB del límite de Shannon, proporcionado una tasa de error de 10-5 para Eb/N0 de 2/2.5 dB.

(5) Mientras el espectro de una secuencia aleatoria (equiprobable) obedece a la consabida expresión 2A2Tb (sinc fTb)2 , donde Tb representa

el intervalo de bit, el de una secuencia seudoaleatoria de período L sigue la expresión:

(1/L2)A2δ(f) + [(L+1)/L2] A2 (sinc fTb)2 Σnδ[f-(n/LTb)]

con rayas espectrales separadas (1/LTb).

1010101010CODIGO FUENTE

(perìodo = L = 2)

CODIGO FUENTEALEATORIZADO

0110011101

ex_ORex_OR

1100110111SECUENCIA

SEUDOALEATORIA

SECUENCIASEUDOALEATORIA

1100110111

1010101010CODIGO FUENTE

(perìodo = L = 2)

(RCX)(RCX)(TRX)(TRX)



Como se observa, es preciso generar una secuencia binaria seudoaleatoria (“Pseudo Random Binary Sequence”, PRBS ), lo cual se realiza merced a un registro de desplazamiento de varias etapas y con algún tipo de realimentación, tal y como, a título de ilustración, se refleja en la Figura 3.5. Como se aprecia en dicha Figura, si el registro de despla-zamiento consta de k etapas, la secuencia binaria seudoaleatoria tendrá una longitud (L) de 2k-1 bits.

Figura 3.5. Generación de una Secuencia Binaria Seudoaleatoria

Tras las anotaciones anteriores, resulta fácil comprender el esquema de aleatorización contemplado en la norma ETS 300 429, que se ilustra en la Figura 3.6. Como se aprecia, el registro de desplazamiento normalizado consta de quince etapas ( k=15 ), con realimentación en las dos últimas, por lo que el polinomio generador será 1+x14+x15 La PRBS resultante es “00000011....”

0100111

10

1

ETAPA 7ª = ESTADO INICIAL

110

1

ESTADO INICIAL

1

10

01

ETAPA 1ª

111

01

0

ETAPA 2ª

1

1111

00

ETAPA 3ª

00111

01

1

ETAPA 4ª

0

00111

11

0

ETAPA 5ª

1

100111

11

1

ETAPA 6ª

0



Figura 3.6. ETS 300 429: Esquema de Aleatorización

A fin de soportar la sincronización del proceso (básica en los aleatorizadores tipo “set-reset”), el byte de sincronismo del paquete MPEG-2/TS (el primero de los 188 bytes del paquete, con valor, prefijado, de 47HEX) no se aleatoriza. A tal fin, el proceso de aleatorización no se detiene, sino que se inhabilita mediante la puerta AND. En cambio, dicho byte se invierte cada ocho paquetes (pasando del valor 47HEX al valor B8HEX ), a fin de reinicializar el proceso de aleatorización. Efectivamente, al llegar el byte de sincronismo invertido se carga la secuencia de inicialización en el registro de des-plazamiento, y comienza el proceso de aleatorización con el byte que sigue al de sincronismo (puesto que éste, como ya se ha apuntado, no se aleatoriza), manteniéndose dicho proceso hasta la llegada de un nuevo byte de sincronismo invertido (es decir, tras siete bytes de sincronismo no-invertidos), tal y como se ilustra en la Figura 3.7.

9

0

8765432 1510 11 12 13 141

0001001 101 000 0

ex_ORex_OR

ex_ORex_OR

ANDAND

SECUENCIA DE INICIALIZACION

PRBS = 0 0 0 0 0 0 1 1 ...

CODIGO FUENTE ALEATORIZADOENABLE

CODIGO FUENTE



Figura 3.7. Proceso de Aleatorización

A fin de controlar la interferencia (evitanto la emisión de una portadora no modulada), la norma ETS 300 429 especi-fica que el anterior proceso de aleatorización deberá estar activo también en ausencia de señal o, incluso, cuando ésta no responda al formato MPEG-2/TS. 3_2_2_ Codificación Reed-Solomon Los códigos Reed-Solomon son un subconjunto de los códigos BCH (“Bose Chadhuri Hocquenghem”), pertenecien-do, consecuentemente, a la familia de los códigos cíclicos. Además, los códigos Reed-Solomon son no-binarios (6) ; es decir, en una palabra código cs = (c1, c2, ...cs) los elemen-tos (símbolos) ci , siendo 1≤i ≤ s , pertenecerán a un alfabeto q-ary, siendo q normalmente una potencia de 2, tal que q = 2m , de modo que m bits de información conforman un símbolo.

(6) La ventaja de los códigos no-binarios se puede ilustrar con el siguiente ejemplo:

Supuesto un código binario tipo (N,K) = (7,3) la relación entre el espacio total (2N=27=128) y el espacio de las palabras código (2K=23=8) es de 128/8 =16 . En cambio, considerando un código no-binario tambien de (N,K) = (7,3) donde cada símbolo está consti-tuido por m=3 bits, la relación entre el espacio total (2Nm=221=2.097.152) y el espacio de las palabras código (2Km=29=512) es de 2097152/512=4.096

Obviamente, cuando mayor es la relación entre ambos espacios, mayor será la distancia mínima que puede ser conseguida.

SYNCSYNC(1 byte)

187 bytes

Paquete MPEG-2/TS

SYNC 8SYNC 8

SYNC 1SYNC 1187 bytes 187 bytesSYNC 2SYNC 2

SYNC 1SYNC 1 187 bytes

Perìodo PRBS = 1.053 bytes



Consecuentemente, un código Reed-Solomon (N,K) es aquel que transforma una palabra, entrante, de K símbolos en otra palabra, saliente, de N símbolos, tal y como se ilustra en la Figura 3.8. Tanto los símbolos de la palabra entrante cK como los símbolos de la palabra saliente cN pertenecerán a un alfabeto q-ary (es decir, cada uno constará de m bits).

Figura 3.8. Codificador Reed-Solomon

Para un código no-binario, la distancia entre dos palabras código se define como el número de símbolos en los que difieren. Concretamente, para un código Reed-Solomon la distancia mínima de código (7) obedece a la expresión Dmín = N-K+1 Consecuentemente, un código Reed-Solomon es capaz de corregir una combinación de hasta T símbolos erróneos, tal que T = (Dmín-1)/2 = (N-K)/2 , requiriendo, pues, no más que 2T símbolos de paridad (N-K). Concretamente, la norma ETS 300 429 especifica un código del tipo (204,188) simbolos, donde cada símbolo es un octeto (m=8), que, consecuentemente, será capaz de corregir hasta T=(204-188)/2 = 8 símbolos erróneos (es decir, hasta 64, 8x8, bits erróneos). Asímismo, la norma especifica que esta codificación se aplicará también al byte de sin-cronismo, tanto invertido como no. Del anterior párrafo se desprende, claramente, que el código Reed-Solomon es adecuado para errores en ráfaga, pro-pios de canales con memoria, pero no es eficiente para errores aleatorios. Efectivamente, el código (204,188) puede corregir hasta 64 bits (consecutivos) erróneos, pero, para ello, requiere la recepción si error de (204-8)x8 = 1.568 bits. Considerando que las palabras con más de T=8 símbolos erróneos no serán corregidas, y supuesto un canal binario simétrico (“Binary Symmetric Channel”, BSC) con probabilidad p de error en símbolo, la probabilidad de error en símbolo a la salida del descodificador se puede aproximar por la expresión:

(7) Distancia menor (mínima) entre dos palabras cualesquiera del código, que, al tratarse de un código lineal, corresponde al “peso” de la

palabra código de menor “peso” (con menor número de símbolos no nulos).

CODIFICADORm mm

K

m mm

N



En general, se puede aproximar que la probabilidad de error en bits de un código Reed-Solomon decrece exponen-cialmente con N y que la complejidad del descodificador es proporcional a una pequeña potencia de exponente, tam-bién, N. 3_2_3_ Entrelazado Convolucional El proceso de entrelazado, “interleaving”, se aplica a los paquetes ya codificados (Reed-Solomon) con objeto de segmentar y repartir las ráfagas prolongadas de errores, facilitando así su posterior detección y corrección en recep-ción, tal y como se ilustra en la Figura 3.9.

Figura 3.9. Funcionalidad del Entrelazado (“Interleaving”)

Al respecto, la norma ETS 300 429 propone un entrelazado convolucional (8) basado en la aproximación de Forney, que se ilustra en las Figuras 3.10. y 3.11.

2222 44441111 3333 2222 44441111 3333

2222 44441111 33332222 44441111 3333 2222 44441111 3333

1234 12341234 1234

SECUENCIA RECIBIDASECUENCIA TRANSMITIDA

TRANSMISION SIN ENTRELAZADO SECUENCIA RECIBIDASECUENCIA TRANSMITIDA

ERRORES AISLADOS, FACILES DE DETECTAR Y CORREGIRTRANSMISION CON ENTRELAZADO

ERRORES CONSECUTIVOS, DIFICILES DE DETECTAR Y CORREGIRERRORES

EN RAFAGA

jmj

tjmE pp

m

jjP

m

−−−

+=

−

−−

≈ ∑ 1212

1

)1(1212

1



Figura 3.10. Ilustración del Entralazado Convolucional

Como se observa, los símbolos (octetos) entrantes son alojados, secuencialmente, en un banco de I registros, propor-cionando cada registro M símbolos más de almacenamiento que el registro precedente, y comportándose cada registro

(8) La ventaja del Entrelazado Convolucional sobre el Entrelazado de Bloques es que aquel comporta la mitad de retraso y requiere la mitad

de memoria que éste.

4

14

16 8

14

15

16 4

13

26

4

3

6

7

8

2

5

1

2

4

3

2

3

4

11

5

7

8

5 1

13

10

15 11

12

13

10

9 1

2

3

10

12 4

10

11

12

3

9 9

6

11 7

8

9

6

5 1

2

7

5

6

7 3



como una cola-FIFO (“First In First Out”). Con cada nuevo símbolo (octeto) el conmutador pasa a un nuevo registro, repitiéndose el proceso cada I símbolos.

Figura 3.11. Entrelazado Convolucional de Forney

Concretamente, la norma ETS 300 429 especifica una profundidad de entreladazado de 12 (I=12) y un valor de M=17 octetos, tal que M=N/I=204/12=17, de modo que el byte de sincronismo, invertido o no, se encaminará siempre por la rama superior del entrelazador (aquella de retraso nulo, para la que I=0). Como se observa en las Figuras 3.10 y 3.11, el retraso total, desde la entrada al entrelazador hasta la salida del desen-trelazador, de un símbolo (octeto) es igual a I(I-1)M símbolos. Por último, y como resumen de cuanto antecede sobre la Codificación de Canal, cabe señalar que la conjunción del código Reed-Solomon (de eficiencia T=8) con un entrelazado convolucional (de profundidad I=12) posibilita la corrección de hasta TxI = 8x12 = 96 símbolos erróneos (es decir, 96x8=768 bits). 3_3_ MODULACION QAM A la Codificación de Canal sigue la Modulación QAM (“Quadrature Amplitude Modulation”), para cuyo análisis se van a distinguir tres procesos: la Conversión de Bytes a Símbolos (9), el Filtrado de Nyquist, y la Modulación QAM propiamente dicha. 3_3_1_ Conversión de Bytes a Símbolos (9)

M

(I-1)M

2M

M

(I-1)M

2MCANAL



Tras el Entrelazado Convolucional, los octetos (bytes) se han de convertir en símbolos, de q bits cada uno, tal que el número de estados o niveles de la Modulación QAM (16, 32, 64, 128, o 256) sea igual a 2q ; es decir, q tomará, respec-tivamente, los valores 4, 5,6,7, y 8. Tal conversión se ilustra en la Figura 3.12, que corresponde al caso de 64-QAM (q=6), siendo b5 el bit más significa-tivo (“Most Significant Bit”, MSB) y b0 el menos significativo (“Most Significant Bit”, MSB).

SALIDA DEL ENTRELAZADOR CONVOLUCIONAL (OCTETOS)

Byte V Byte V+1 Byte V+2

b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 MSB LSB b5 b4 b3 b2 b1 b0 b5 b4 b3 b2 b1 b0 b5 b4 b3 b2 b1 b0 b5 b4 b3 b2 b1 b0

Símbolo Z Símbolo Z+1 Símbolo Z+2 Símbolo Z+3

AL CODIFICADOR DIFERENCIAL (6 Bits por SIMBOLO)

Figura 3.12. Conversión de Bytes a Símbolos

Además, los dos bits más significativos de cada símbolo ( bq-1 y bq-2, o, respectivamente, Ak y Bk ) se codifican dife-rencialmente, de la acuerdo con la expresión siguiente (10) y la Figura 3.13, a fin de obtener una constelación-QAM invariante con una rotación de π/2.

(9) En el contexto de la Modulación QAM el significado del término “símbolo” es diferente al que tenía en el apartado anterior de la Codifi-

cación de Canal (mientras en ésta el “símbolo” equivale al octeto, o byte, en la Modulación QAM el “símbolo” se asimila a la combina-ción binaria correspondiente a cada estado o nivel).

(10) En dicha expresión, “✇ “ representa la función EXOR, “+” representa función OR, “*” representa la función AND, y la raya superior representa la Inversión.



Ik = (Ak Bk) * (Ak Ik-1) + (Ak Bk) * (Ak Qk-1) Qk = (Ak Bk) * (Bk Qk-1) + (Ak Bk) * (Bk Ik-1)

Figura 3.13. Conversión Bytes a Símbolos, con Codificación Diferencial

Merced a esta codificación diferencial, los puntos del cuadrante primero de la constelación-QAM se pueden convertir en los del cuadrante segundo, tercero o cuarto, sin más que cambiar los dos bits más significativos (Ik y Qk) y rotar, respectivamente, π/2, π, o 3π/2 el resto de los bits (q-2) del símbolo. Ello se puede comprobar, por ejemplo, en la Figura 3.14.

Figura 3.14. Constelación de la Modulación 16-QAM

CONVERSIONBYTE

aSIMBOLO

OCTETOS

delENTRALAZADOR

CONVOLUCIONAL

CODIFICADORDIFERENCIAL

BK=bq-2

AK= bq-1

q-2 bits = bq-3,..,b0

MAPEADOIK

QKQ

I

11001101

11101111

01100100

01110101

10011011

10001010

00110010

000100000

IKQK=01IKQK=11

IKQK=00IKQK=10

I

Q



3_3_2_ Filtrado de Nyquist Antes de la modulación QAM, y con objeto de reducir la interferencia entre símbolos, las señales I y Q se someten a un filtrado de raiz (11) de coseno alzado, con factor de redondeo (“roll-off”) de α=0.15 , tal y como refleja la expresión siguiente y se ilustra en la Figura 3.15.

H(f) = 1 para f< fN(1-α)

H(f) = {(1/2) + (1/2) sen [(π/2fN) [(fN-f)/α]]}1/2

para fN(1-α) ≤ f≤ fN(1+α)

H(f) = 0 para f> fN(1+α)

donde fN representa la frecuencia de Nyquist, que es igual a la mitad de la velocidad de modulación, fN = 1/(2TS) = RS/2 , siendo TS = 1/RS el período de símbolos.

Figura 3.15. Característica de Amplitud del filtro “Half-Nyquist”

(11) De “raíz”, puesto que tal filtrado se reparte entre transmisión y recepción.

rm < 0.4 dB

H(f)

-3,01 dB

0 dB

1.15 fNf0fN0.85 fN

Rejection > 43 dB

FRECUENCIA



3_3_3_ Modulación QAM Como ya se ha anticipado, la norma ETS 300 429 especifica una modulación tipo QAM (“Quadrature Amplitude Modulation”) de 16, 32, 64, 128 o 256 estados (o niveles). Al respecto, y a título de ejemplo, se va analizar el sistema 16-QAM, cuya constelación ya se ilustró en la Figura 3.14, y se vuelve a representar, aunque resaltanto otros detalles, en la Figura 3.16.

Figura 3.16. Constelación de la Modulación 16-QAM

Como se observa en la Figura 3.16, cada punto de la constelación dista d = 2a de sus vecinos. Por ello, considerando la simetría de la distribución, y presumiendo que dichos puntos son equiprobables, resulta que la energía media de la señal (del símbolo) será:

ES = (1/4) [(a2+a2) + (9a2+a2) + (a2+9a2) + (9a2+9a2)] = 10a2 de donde a = (0.1xES)1/2 y d = 2a = 2 (0.1xES)1/2

kQa

( 3a, a )( a, a )

( 3a, 3a )( a, 3a )

2a

kIa

2a

Q (t)Q (t)

I(t)



Y como cada símbolo está compuesto por cuatro bits (16=24) será ES=4Eb de donde se desprende que a = (0.4xEb )1/2 y d = 2a = 2 (0.4xEb )1/2 (12) Tomando los coeficientes kI y kQ los valores ±1 y ±3 , la señal 16-QAM obedecerá a la expresión:

v16-QAM = kI a I(t) + kQ a Q(t) Y considerando que I(t) = (2/TS)1/2 cos w0t y que Q(t) = (2/TS)1/2 sen w0t resulta que:

v16-QAM = kI [0.2(ES/TS)]1/2 cos w0t + kQ [0.2(ES/TS)]1/2 sen w0t Como TS es el intervalo del símbolo ( TS = q Tb ) y ES es la energía del mismo, el cociente ES/TS será igual a la potencia del símbolo (PS), de donde:

v16-QAM = kI [0.2 PS]1/2 cos w0t + kQ [0.2 PS]1/2 sen w0t

v16-QAM = AI(t) [PS]1/2 cos w0t + AQ(t) [PS]1/2 sen w0t

donde AI(t) y AQ(t) pueden tomar los valores de ±1 (0.2)1/2 y ±3 (0.2)1/2 También, y asumiendo que los cuatro posibles valores de AI(t) y AQ(t) son equiprobables, parece evidente que:

[AI(t)]2 = [AQ(t)]2 = 1 En base a cuanto antecede, en la Figura 3.17 se representan el modulador y el demodulador 16-QAM. Por otra parte, la densidad espectral de potencia obedece a la relación:

GQAM(f) = (PSTS/2) [sinc (f-f0)TS]2 + (PSTS/2) [sinc (f+f0)TS]2 (12) Esta distancia es, por ejemplo, significativamente mayor que la correspondiente a un sistema PSK-16 (“Phase Shift Keying” de 16

estados), cuyo valor es d = 2a = 2 (0.15xEb )1/2 de donde se deduce que la modulación 16-QAM registra una Probabilidad de Error me-nor que la PSK-16



Figura 3.17. Modulador y Demodulador 16-QAM

Además, y considerando el factor de redondeo de α=0.15, resulta que el ancho de banda necesario será igual a:

B (MHz) = [ Rb(Mbps) / q ] (1+α) = 1.15 [ Rb(Mbps) / q ] donde Rb(Mbps) es el régimen binario (número de bits por segundo) a la entrada del modulador, y q , como se ha visto anteriormente, es el número de bits por símbolo (tal que 2q = M = número de estados de la modulación). Y, como es sabido, la probabilidad de error se atiene a la expresión:

P(e/s1) ≤ Σ desde k=2 hasta k=M (1/2) Erfc [(dk,1)2/4η]1/2 donde P(e/s1) representa la probabilidad de error cuando se ha transmitido el símbolo s1 , Erfc es la función de error complementaria (13) , dk,1 es la distancia desde s1 hasta cada uno de los M-1 símbolos restantes del sistema de modula-ción, y η es la densidad espectral de ruido a la entrada del modulador (14).

(13) Como es consabido Erfc (x) = [2/π1/2] ∫ entre x e ∞ exp (-u2) du , que se puede aproximar por Erfc (x) = exp (-x2) / [x π1/2] cuando

x>> (14) Supuesto ruido blanco, será η = KTF , siendo K la constante de Boltzmann (1,38 10-23 Julios/ºK) , T la temperatura absoluta, y F el

factor de ruido.

AQ(t)

AI(t)

sen w0t

cos w0t

0

TS

dt

0

TS

dt

AQ(t)

AI(t) vQAM (t)

PS sen w0t

PS cos w0t

SS

90º

0º



Aplicando la anterior expresión al sistema 16-QAM, particularizándola para el caso más desfavorable [por ejemplo, el símbolo (a,a) de la Figura 3.16, totalmente “cercado” por símbolos vecinos] , presumiendo una tasa de error baja [que permite considerar, unicamente, a los cuatro símbolos más cercanos al (a,a)] , y recordando que d = 2a = 2

(0.4xEb )1/2 = (1.6xEb )1/2 resulta que: Pe ≤ 4 (1/2) Erfc [1.6 Eb/4η]1/2 = 2 Erfc [0.4 Eb/η]1/2 Por último, en la Tabla adjunta se representa un mapa de posibles configuraciones del estándar ETS 300 429:

REGIMEN EFECTIVO MPEG-2/TS

(Mbps)

REGIMEN tras

RS(204,188) (Mbps)

VELOCIDAD MODULACION

(Mbaudios)

BANDA OCUPADA

(MHz)

TIPO de

MODULACION

38,1 31,9 25,2

41,34 34,61 27,34

6,89 6,92 6,84

7,92 7,96 7,86

64-QAM 32-QAM 16-QAM

31,672 (*)

34,367 (*)

6,87 (*)

7,90 (*)

32-QAM

18,9 16,0 12,8

20,52 17,40 13,92

3,42 3,48 3,48

3,93 4,00 4,00


9,6 8,0 6,4

10,44 8,70 6,96

1,74 1,74 1,74

2,00 2,00 2,00


(*) Compatible con la Jerarquía Digital Plesiócrona Europea. BIBLIOGRAFIA UTILIZADA



.- Estándar EN 300 429 del ETSI, “Digital Broadcasting Systems for Television, Sound and Data services: Framming structure, Channel coding and Modulation for Cable systems”, v1.2.1 (1998-04).

.- Norma ISO/IEC 13818-1/2/3, “Information technology: Generic coding of moving pictures and associated audio information:

Systems, Video and Audio”, edición 1996-04-15 .- Bernard Sklar, “Digital Communications”, Prentice-Hall International Inc, 1988. .- John G. Proakis y Masoud Salehis, “Communications Systems Engineering”, Prentice-Hall Englewood, New Jersey, 1996. .- Taub Schilling, “Principles of Communications System”, McGraw-Hill International, 1986.



Anexo 3.A: SEMANTICA DE PAQUETES “MPEG-2/TS” Y “PES”

3.A_1_ Paquetes “MPEG-2/TS” y “PES” De acuerdo con el estándar ISO/IEC 13818-1, la codificación del vídeo y audio (según, respectivamente, los estánda-res ISO/IEC 13818-2 y 13818-3, también conocidos como “MPEG-2/Vídeo” y “MPEG-2/Audio”) genera unos flujos elementales que se segmentan en paquetes de longitud variable, denominados PES (“Packetized Elementary Stream”), tal y como se ilustra en la Figura 3.A_1 adjunta.

Figura 3.A_1 Paquetes “PES” y “MPEG-2/TS”

A su vez, un flujo de paquetes_PES con un mismo PID (“Packet IDentifier”) constituye un “PES Streams”. Cada PID identifica, por ejemplo, el vídeo o audio de cada programa. Distintos “PES Streams”, correspondientes a diferentes programas, se multiplexan en un único flujo, denomimado “Transport Streams” (TS), que se estructura en base a paquetes de 188 bytes de longitud, conocidos como “MPEG-

CODIFICADOR de AUDIO(ISO/IEC 13818-3)

CODIFICADOR de VIDEO(ISO/IEC 13818-2)

PAQUETIZADOR

PAQUETIZADOR

AUDIO-1

VIDEO-1

PROGRAMA-n

PROGRAMA-1

PROGRAMA-2

X

M

U

MPEG-2/TS



2/TS”. Al respecto, el estándar especifica que el primer byte de la cabecera de un paquete_PES ha de coincidir con el primer byte de la carga útil de un paquete MPEG-2/TS (1). 3.A_2_ Paquetes “MPEG-2/TS”: Sintaxis y Semántica La Figura 3.A_2 representa la sintaxis de un paquete MPEG-2/TS, de acuerdo con el estándar ISO/IEC 13818-1.

Figura 3.A_2 Sintaxis del paquete MPEG-2/TS

(1) También pueden existir paquetes MPEG-2/TS vacíos (“null packets”).

HEADER PAYLOADHEADER PAYLOAD HEADER PAYLOAD HEADER PAYLOAD

ITWOFFSET

DTS_NEXT_AUSPLICE

TYPE

188 bytes188 bytes 188 bytes 188 bytes

SYNCBYTE

TRANSPORTERROR

INDICATOR

TRANSPORTSCRAMBLING

CONTROL

TRANSPORTPRIORITY

PIDPAYLOAD

UNIT STARTINDICATOR

ADAPTATIONFIELD

CONTINUITYCOUNTER

ADAPTATIONFIELD

CONTROL

411 1 13 2 2

ADAPTATIONFIELD

LENGTH

ELEMENTARYSTREAM

PRIORITY

5

RANDOM ACCESS

INDICATOR

DISCONTINUITYINDICATOR

STUFFINGBYTES

OPTIONALFIELDS

FLAGS

PIECEWISERATE

8

1 1

PROGRAMCLOCK

REFERENCE

TRANSPORTPRIVATE

DATA

SPLICE COUNTDOWN

OPCR

3

OPTIONALFIELDS

ADPTATIONFIELDS

EXTENSION LENGTH

TRANSPORTPRIVATE DATA

LENGTHFLAGS

ITW_VALIDFLAG

8

84242

15

1

88

2 331 22 4



Un paquete MEG-2/TS puede transportar bien paquetes_PES, bien información-PSI (“Program Specific Informa-tion”), o bien datos, “privados”, de otro tipo (para, por ejemplo, aplicaciones interactivas: telebanca, telecompra,..). Ello se aprecia claramente en la definición semántica del paquete MPEG-2/TS, que se describe, sucintamente, a conti-nuación:

“sync_byte” (8 bits) : Octeto de valor “0100 0111”

“transport_error_indicator” (1 bit): De valer “1” indicaría la existencia de, al menos, un bit erróneo en el paquete.

“payload_unit_start_indicator” (1 bits): Si su valor es “1”, indica que la carga útil de este paquete MPEG-2/TS comienza con el primer byte bien de un paquete_PES o bien de una sección-PSI (“Program Specific Informa-tion”), valiendo “0” en caso de que el paquete_PES o la sección-PSI no comiencen en el paquete MPEG-2/TS en cuestión.

“transport_priority” (1 bit): Cuando su valor es “1” indica que el paquete tiene máxima prioridad.

“packet_ identifier” PID (13 bits): Indica el tipo de información transportada en la carga útil del paquete. Para

algunos casos (“Program Association Table”, PAT, “Conditional Access Table”, CAT, paquetes nulos,..) el PID tiene un valor predeterminado.

“transport_scrambling_control” (2 bits): Señala el tipo de aleatorización de la carga útil del paquete (no aleatori-

zada, definida por el usuario,..). La cabecera y, en su caso, el campo de adaptación (“adaptation_field”) no se aleatorizan.

“adaptation_field_control” (2 bits): Estos dos bits indican si a la cabecera del paquete le sigue un “adapta-

tion_field” y/o carga útil. Así, por ejemplo, el valor “01” indica que unicamente existe carga útil, el valor “10” que unicamente “adaptation_fiel”, y el valor “11” que ambos.

“continuity_counter” (4 bits): Campo de cuatro bits, que se va incrementando con cada paquete de igual PID.



A los anteriores campos, que suman un total de 32 bits (4 bytes), le puede seguir bien la carga útil (que, como ya se ha indicado, puede ser paquetes_PES, información PSI, o, incluso, datos privados), o bien un “adaptation_field”, cuya semántica se describe a continuación:

“adaptation_field_length” (8 bits): Indica el número de bytes en el “adptation_field” que siguen a este campo “adaptation_field_length”. Además, este campo posibilita el único mecanismo de relleno factible cuando se trans-porta paquetes_PES. Así cuando la carga útil de un paquete MPEG-2/TS no se completa totalmente con informa-ción de paquetes_PES, se define un “adptation_field_length” mayor que la información disponible en el “adapta-tion_field”, subsanándose los bytes de diferencia con información de relleno (los bytes de relleno, “stuf-fing_bytes”, que tienen el valor “1111 1111”, son descartados por el descodificador).

“discontinuity_indicator” (1 bit): Campo que se utiliza para indicar discontinuiudad bien en la base de tiempo o

bien el el “continuity_counter”.

“random_access_indicator” (1 bit): Indica si en el paquete en curso se inserta información de ayuda para el acceso aleatorio.

“elementary_stream_priority_indicator” (1 bit): Si su valor es “1” indica que el paquete al que pertenece tiene la

máxima prioridad de entre aquellos del mismo PID (se utiliza, por ejemplo, para paquetes que transportan infor-mación de intratramas-I).

.- “PCR_flag” (1 bit): Cuando su valor es “1”, señala que el paquete en curso contiene información PCR (“Pro-

gram Clock Reference”).

“OPCR_flag” (1 bit): Si su valor es “1”, indica que el paquete en curso contiene información OPCR (“Original Program Clock Reference”).

“splicing_point_flag” (1 bit): Cuando su valor es “1” señala que el “adaptation_field” contiene un campo de “spli-

ce_countdown”.

“transport_private_data_flag” (1 bit): Si su valor es “1” indica que el “adaptation_field” contiene uno, o más, bytes de datos privados.



“adaptation_field_extension_flag” (1 bit): Cuando su valor es “1” señala la presencia de un “adapta-tion_field_extension”.

“program_clock_reference” PCR (42 bits): Información de reloj que se codifica en dos subcampos: uno de 33 bits

(PCR_base) y el otro de 9 bits (PCR_extension).

“original_program_clock_reference” OPCR (42 bits): Campo opcional, codificado también en dos subcampos, que unicamente puede estar presente en paquetes con campo PCR.

“splice_countdown” (8 bits): Este contador especifica el número de paquetes MPEG-2/TS de igual PID necesarios

hasta alcanzar el “splicing point”, el cual se localiza inmediatamente después del último byte del paquete en el que este contador alcanza el valor de cero. Tras ello, la carga útil del siguiente paquete MPEG-2/TS con igual PID comenzará con el primer byte de un paquete_PES.

“transport_private_data_length” (8 bits): Campo cuyo valor indica el número de bytes de datos privados (“priva-

te_data bytes”) que siguen, inmediatamente, a este campo.

“transport_private_data” (variable): Campo de longitud variable (pero que, no obstante, no puede sobrepasar el “adaptation_field”) cuyos bytes escapan a la normalización de ITU-T e ISO/IEC.

“adaptation_field_extension_length” (8 bits): Campo cuyo valor señala el número de bytes del “extended adapta-

tion field data” que siguen, inmediatamente, a este campo.

“ltw_flag” (1 bit): Cuando su valor es “1” indica la presencia de un campo “itw_offset”.

“piecewise_rate_flag” (1 bit): Cuando su valor es “1” señala la presencia de un campo “piecewise_rate”.

“seamless_splice_flag” (1 bit): Cuando su valor es “1” indica la presencia de los campos “splice_type” y “DTS_next_AU”.

“ltw_valid_flag” (“legal time window_valid_flag”) (1 bit): Cuando su valor es “1” indica que el valor del campo

“ltw_offset” es válido.



“ltw_offset” (15 bits): Campo que transporta el “legal time window offset”, información ésta de interés para equi-

pos muy específicos (remultiplexores, por ejemplo).

“piecewise_rate” (22 bits): Campo éste con información relacionada, también, con el “legal time window offset”.

“splice_type” (4 bits): Campo que vale “0000” cuando se transportan paquetes_PES de audio, y que, si éstos son de vídeo, señala ciertas condiciones (perfil, nivel,..) para su ensamblado.

“DTS_next_AU” (“Deconding Time Stamp next Access Unit”) (33 bits): Campo que transporta información rela-

cionada con el “splicing point” y con el “splice_countdown”. 3.A_3_ Paquetes_PES: Sintaxis y Semántica Como ya se ha indicado, la codificación del vídeo y audio (según, respectivamente, los estándares ISO/IEC 13818-2 y 13818-3, también conocidos como “MPEG-2/Vídeo” y “MPEG-2/Audio”) genera unos flujos elementales que se segmentan en paquetes de longitud variable, denominados PES (“Packetized Elementary Stream”) (2). La Figura 3.A_3 representa la sintaxis de un paquete_PES, de acuerdo con el estándar ISO/IEC 13818-1. Al respecto, y como ya se ha apuntado, dicho estándar especifica que el primer byte de la cabecera de un paquete_PES ha de coin-cidir con el primer byte de la carga útil de un paquete MPEG-2/TS.

(2) A su vez, distintos “PES Streams”, correspondientes a diferentes programas, se multiplexan en un único flujo, denomimado “Transport

Streams” (TS), que se estructura en base a paquetes de 188 bytes de longitud, conocidos como “MPEG-2/TS”, cuya sintaxis y semántica ya se ha descrito en el epígrafe anterior (3.A_2_).



Figura 3.A_3 Sintaxis del paquete_PES

A continuación se describe la semántica de los distintos campos:

“packet_start_code_prefix” (24 bits): Campo de veintitrés “0” y un “1” (“000001” en hexadecimal) que identifica el comienzo de un paquete_PES.

“stream_id” (8 bits): Define el tipo de paquete: de vídeo, de audio, datos auxiliares,...

“PES_packet_length” (16 bits): Indica el número de bytes que siguen al último (byte) de este campo.

“PES_scrambling_control” (2 bits) : Señala el tipo de aleatorización de la carga útil del paquete. La cabecera del

paquete (incluído, en su caso, el “optional_field”) no se aleatorizan.

PACKET STARTCODE PREFIX

STREAM_ID

PESSCRAMBLING

CONTROL

OPTIONALPES

HEADERPES PACKET DATA BYTES

PACKHEADER

FIELD

PESEXTENSIONFIELD DATA

P-STD BUFFER

“10”ORIGINAL

or COPY

DATAALIGNMENTINDICATOR

COPYRIGHTPES

PRIORITYSTUFFING

BYTESPES HEADER

DATA LENGTHFLAGS

m*812 1 1 1

PRESENTATIONDECODER

TIME STAMP

ELEMENTARYSTREAM

RATE

ELEMENTARYSTREAM CLOCK

REFERENCE

PESEXTENSION

PREVIOUSPESCRC

PROGRAMPACKET

SEQ.CNTR.

42 22

FLAGSOPTIONAL

FIELDS

PESPRIVATE

DATA

33

8

16

8

8

7128 8 16

5

PESPACKETLENGTH

OPTIONALFIELDS

2

24 8

TRICKMODE

CONTROL

ADDITIONALCOPYINFO

8

16

PESEXTENSION

FIELD LENGTH

7



“PES_priority” (1 bit): Cuando su valor es “1” indica la máxima prioridad (caso de, por ejemplo, paquetes asocia-dos a intra-tramas, o tramas-I).

“data_alignment_indicator” (1 bit): Campo tipo “flag” que, cuando su valor es “1”, señala que la cabecera del

paquete es seguida, inmediatamente, por información de vídeo o audio.

“copyright” (1 bit): Si su valor es “1” indica que la carga útil está protegida por “copyright”; si su valor es “0” se considerará indefinido.

“original_or_copy” (1 bit): Original si “1” y copia si “0”.

“PTS_DTS_flags” (2 bits): Indica la existencia de uno, o ambos, campos: PTS (“Presentation Time Stamp”) y DTS

(“Decoding Time Stamp”). Cuando su valor es “11” señala la existencia de ambos campo, PTS y DTS, en la cabe-cera del paquete_PES.

“ESCR_flag” (1 bit): Cuando su valor es “1” indica la existencia del campo ESCR (“Elementary Stream Clock

Reference”).

“ES_rate_flag” (1 bit): Cuando su valor es “1” indica la existencia del campo “ES_rate” (“Elementary Stream_rate”).

“DSM_trick_mode_flag” (1 bit): Cuando su valor es “1” señala la existencia de un campo, de 8 bits, “trick_mode”.

“additional_copy_into_flag” (1 bit): Si su valor es “1” indica la existencia de un campo “additional_copy_into”.

“PES_CRC_flag” (1 bit): Cuando su valor es “1” señala la existencia de un campo CRC (“Cyclic Redundancy

Check”).

“PES_extension_flag” (1 bit): Si su valor es “1” señala la existencia de un “extension_field” en el paquete_PES.

“PES_header_data_length” (8 bits): Indica el número de bytes ocupados por los campos opcionales y posibles bytes de relleno contenidos en la cabecera del paquete_PES.



“market_bit” (1 bit): Su valor es “1”.

“Presentation_Time_Stamp”, PTS (33 bits): Codificado en tres subcampos, facilita información sobre la base de

tiempos de la representación.

“Decoding_Time_Stamp”, DTS (33 bits): Codificado también en tres subcampos, facilita información sobre la base de tiempos de la descodificación.

“Elementary_Stream_Clock_Reference” ESCR (42 bits): Codificado en dos subcampos (ESCR_base y

ESCR_extension) facilita información sobre la temporización.

“elementaty_stream_rate” (22 bits): Campo que especifica la velocidad (evaluada en unidades de 50 by-tes/segundo) a la cual el descodificador debe recibir los bytes de un “PES Stream”.

“trick_mode_control” (3 bits): Campo que se utiliza para especificar algunos tipos de representación: fast forward,

slow motion, ...

“field_id” (2 bits): Aporta información sobre la imagen que debe ser representada.

“intra_slice_refresh” (1 bit): Campo relacionado con la eventual pérdida de macrobloques.

“frequency_truncation” (2 bits): Campo que informa sobre la eventual existencia de restricciones en la utilización de los coeficientes-DCT.

“rep_cntrl” (5 bits): Asociado al campo “trick_mode_control”, señala el número de veces que una imagen debe

reproducirse.

“additional_copy_info” (7 bits): Bits que contienen datos privados concernientes al copyright.



“previous_PES_packet_CRC” (16 bits): Campo que transporta el “Cyclic Redundancy Check” (CRC) correspon-diente del paquete-PES anterior, excluyendo la cabecera del mismo (3), de acuerdo con el siguiente polinomio ge-nerador: x16+x12+x5+1

“PES_private_data_flag” (1 bit): Cuando su valor es “1” señala la existencia de datos “privados” en la cabecera

del paquete_PES.

“pack_header_field_flag” (1 bit): Si su valor es “1” indica la existencia de un “pack header” (4) en la cabecera del paquete_PES.

“program_ packet_sequence_counter_flag” (1 bit): Cuando vale “1” señala la existencia de los campos “pro-

gram_ packet_sequence_counter_flag”, “MPEG1-MPEG2_identifier” y “original_stuff_length”.

“P-STD_buffer_flag” (1 bit): Si su valor es “1” indica la existencia de los campos “P-STD_buffer_scale” y “P-STD_buffer_size” en la cabecera del paquete_PES (5).

“PES_extension_flag_2” (1 bit): Cuando su valor es “1” señala la existencia del campo

“PES_extension_field_length” y asociados.

“PES_private_data” (16 bits): Campo que contiene datos privados.

“pack_field_length” (8 bits): Indica la longitud, en bytes, del “pack_header_field”.

“program_packet_sequence_counter” (7 bits): Contador opcional, que se incrementa con cada paquete_PES, con funcionalidad similar a la del “continuity_counter” del paquete MPEG-2/TS.

(3) Se excluye la cabecera del paquete-PES porque ésta puede ser modificada durante el transporte.

(4) Los paquetes-PES de un “Program Stream” se organizan en “packs”, que están constituidos por un “pack header” más “ceros” o más paquetes-PES. El “pack header” comienza con un código inicial de 32 bits, y transporta información de temporización y régimen bina-rio.

(5) Las siglas STD obedecen a la expresión “System Target Decoder”, que constituye un hipotético modelo de referencia del proceso de descodificación.



“MPEG1_MPEG2_identifier” (1 bit): Cuando su valor es “0” señala que la información transportada por el paque-te_PES corresponde a un Program Stream.

“original_stuff_length” (6 bits): Campo que indica el número de bytes de relleno de la cabecera del paquete_PES.

“P-STD_buffer_scale” (1 bit) (5)

: Indica el tipo de información (audio o vídeo) y unicamente tiene sentido en el caso de Program Stream.

“P-STD_buffer_size” (13 bit) (5) : Define el tamaño del buffer de entrada y unicamente tiene sentido en el caso de

Program Stream.

“PES_extension_field_length” (7 bits): Especifica el número de bytes que siguen a este campo en el “PES_extension_field”.

“PES_packet_data_bytes” (N bytes): Bytes de un elementary stream. N será igual al valor especificado en el

campo “PES_packet_length” menos el número de bytes entre el último octeto de dicho campo y el primero de éste (“PES_packet_data_bytes”).

“stuffing_byte” (8 bits): Paquete de relleno, igual a ocho “1” (6)

,que puede ser insertado por el codificador (hasta un total de 32, como máximo, en la cabecera de un paquete_PES) y será descartado por el descodificador.

3.A_4_ “Program (7) Specific Information” En Transport Stream, la Program Specific Information se estructura en las siguientes cuatro Tablas:

(6) Igual que el “padding_byte”. (7) En el contexto de la ISO/IEC 1318-1 la noción de “programa” (un vídeo y varios audios asociados, por ejemplo) es menos exigente que en

Radiodifusión, donde un programa, amén de tener una misma referencia de reloj, también tiene un mismo comienzo y un mismo fin.



“Program Association Table (PAT)”: Facilita la correspondencia entre un “program_number” y el PID (“Pac-ket_IDentifier”) de los paquetes MPEG-2/TS que transportan la definición del programa. El “program_number” es un campo de 16 bit (8) que identifica cada programa (un vídeo y varios audios asociados, por ejemplo).

“Program Map Table (PMT)”: Facilita la correspondencia entre un “program_number” y el PID (“Pac-

ket_IDentifier”) de los “elementary streams” de vídeo y audio asociados a dicho programa.

“Conditional Access Table (CAT)”: Facilita la asociación entre el Acceso Condicional y el PID (“Packet IDenti-fier”) de los paquetes MPEG-2/TS que transportan los EMM (“Entitlement Management Message”).

“Network Information Table (NIT)”: De contenido privado (es decir, no especificado en la ISO/IEC 1318-1).

Para su transmisión en el Transport Stream, las anteriores Tablas se segmentan en secciones, y se insertan directamen-te en paquetes MPEG-2/TS (es decir, sin mapeado previo en paquetes_PES). Para el caso de las tablas PAT y CAT, el PID (“Packet IDentifier”) de los paquetes que las transportan está prefijado. Si bien la longitud de la secci�n es variable, ésta no puede sobrepasar los 1.024 bytes. El comienzo de una secci�n está indicado por un “pointer_field” (8 bits) que se ubica en la carga útil de un paquete MPEG-2/TS (9) . Las secciones no pueden ser aleatorizadas (10) . En las Figuras 3.A_4 se refleja la sintaxis de las distintas secciones.

(8) Dado que el valor “0” está reservado (para el NIT, “Network Information Table”), un Transport Stream puede transportar hasta 65.535

programas diferentes. (9) En un paquete MPEG-2/TS no puede haber más de un “pointer_field”. Consecuentemente, cuando se termina una secci�n (antes del final

del paquete) se utilizarán bytes de relleno (“1111 1111”). (10 ) En cambio, los “elementary streams” (de vídeo y audio) sí pueden ser aleatorizados, a efectos del acceso condicional.



Figura 3.A_4_a) Sintaxis de la secci�n PAT

Figura 3.A_4_b) Sintaxis de la secci�n PMT

Figura 3.A_4_c) Sintaxis de la secci�n CAT

SECTIONSYNTAX

INDICATOR

VERSIONNUMBER

SECTIONLENGTH

TRANSPORTSTREAM_ID

CRCLAST

SECTIONNUMBER

CURRENTNEXT

INDICATOR

2 16 2

PROGRAM

MAP PID-iNETWORK PID

3 1316

1

16

N LOOP

8

133

TABLE_ID

32

“0”

1 12 5

SECTIONNUMBER

8

------PROGRAMNUMBER 0

PROGRAM

NUMBER i------

8

PROGRAM ASSOCIATIONPROGRAM ASSOCIATION(SECTION)

1

SECTIONSYNTAX

INDICATOR

VERSIONNUMBER

SECTIONLENGTH

PROGRAMNUMBER

LASTSECTIONNUMBER

CURRENTNEXT

INDICATOR

2 16 2 1

PCRPID

8

TABLE_ID

13

“0”

1 12 5

SECTIONNUMBER

4

PROGRAMINFO

LENGTH

8

PROGRAM MAPPROGRAM MAP(SECTION)

1 8 3

32

ELEMENTARY PID

4138 12

STREAM TYPE ES INFO LENGTH

N LOOP

N LOOPDESCRIPTORS

CRC

12

3

N LOOPDESCRIPTORS

SECTIONSYNTAX

INDICATOR

VERSIONNUMBER

SECTIONLENGTH

CRCLAST

SECTIONNUMBER

CURRENTNEXT

INDICATOR

2 1

N LOOPDESCRIPTORS

8

TABLE_ID

32

“0”

1 12 5

SECTIONNUMBER

88

CONDITIONAL ACCESSCONDITIONAL ACCESS (SECTION)

1



Figura 3.A_4_d) Sintaxis de la secci�n NIT

Y a continuación se detalla la semántica de los campos más importantes de estas secciones:

“table_id” (8 bits): Identifica el tipo de Tabla (PAT, PMT, ..) al que corresponde la secci�n.

“table_id_extension” (16 bits): En las tablas PAT facilita el identificador del Transport Stream (necesario en redes que manejan varios Transport Streams), en las tablas PMT transporta el “program_number”,...

“section_number” (8 bits): Indica el número de secci�n, de cara a la correcta disposición de éstas en recepción.

“version_number” (5 bits): Señala la versión actualizada de la Tabla (utilizada cuando se cambia la configuración de un programa).

De cara a evaluar el régimen binario (mínimo) requerido por la program specific information, cabe asumir que cada programa está compuesto por dos elementary streams (vídeo y un audio) y que requiere un mínimo de 4 bytes para PAT y de 26 bytes para PMT. Además, se ha de considerar un 2%, aproximadamente, para cabecera (“sec-tion_length”, “version_number”,....) (11) .

(11) No se considera la información asociada al Acceso Condicional (Tablas CAT) porque la frecuencia con que se ha de transmitir es sensi-

blemente inferior a la de las Tablas PAT y PMT.

SECTIONSYNTAX

INDICATOR

128

TABLE_ID

1

PRIVATEPRIVATE (SECTION)

PRIVATEINDICATOR

1

PRIVATESECTIONLENGTH

2

N PRIVATE DATA BYTES

VERSIONNUMBER

LASTSECTIONNUMBER

CURRENTNEXT

INDICATOR

2 1

CRC

16

TABLE_IDEXTENSION

325

SECTIONNUMBER

8 8

N PRIVATEDATA



Con tales premisas, y suponiendo que el paquete MPEG-2/TS carece de “extension_field”, resulta que un paquete puede transportar la PAT de 45 programas (188 = 4+45x4+4) o la MPT de 7 programas (188 = 4+7x26+2). Conse-cuentemente, y suponiendo que la program specific information se transmite con una frecuencia de 25 Hz, el régimen binario por ella requerido será el siguiente:

NUMERO DE PROGRAMAS por TRANSPORT STREAM

1 5 10 32 128

PAT (Kbps) 37,6 37,6 37,6 37,6 112,8

MPT (Kbps) 37,6 37,6 75,2 188,0 714,4

TOTAL 75,2 75,2 112,8 225,6 827,2 donde 37.600 = 188x8x25 / 75.200 = 188x2x8x25 / ... 3.A_5_ Datos “Privados” Los datos “privados” (es decir, los no especificados por la recomendación ISO/IEC 1318-1) pueden ser transportados, básicamente, de las siguientes formas: 1_ En el paquete MPEG-2/TS, en el “adaptation_field”, que puede transportar hasta 183 bytes de datos privados (188 = 4+1+183). 2_ En el paquete_PES, bien en su cabecera (en el campo opcional, de 16 bytes, “PES_private_data”) o bien en su carga útil (en el campo “PES_packet_data_bytes”). 3_ En los “descriptores”, definidos por el usuario, y transportados en las secciones de las Tablas PMT y CAT. Tales “descriptores” comienzan con un “descriptor_tag” (8 bits), que especifica el tipo de descriptor, y un “descrip-tor_length” (8 bits), que señala el número de bytes que siguen a este campo.



4_ En las “private_section”, que, transmitidas en las secciones-PSI (12), posibilitan el transporte de datos “privados” con un mínimo de estructura.

(12) PSI (“Program Specific Information”)

sistemas de acceso opticos: norma dvb-c página...

Documents