Cálculo del ancho de banda

Transcripción

1 Cálculo del ancho de banda Orientaciones: Para lograr un buen entendimiento del tema es importante que sepas: Características de los CODECs de voz y cálculo de ancho de banda de estos CODECs. Características de la pila de protocolos para el transporte de medios en VoIP. El ancho de banda requerido para el transporte de voz sobre redes IP depende de varios factores. Seguidamente serán analizados estos factores. CODEC Los codificadores utilizados hoy en día son de tasa de datos constante, esto da lugar a un tipo de tráfico particular que tiene dos características bien claras que simplifican el análisis: Tasa de paquetes (Pr) constante. Tamaño de paquete (Pl) fijo. Encontrar el ancho de banda en VoIP radica solamente en encontrar estos dos parámetros. Tanto la tasa de paquetes como el tamaño de paquete dependen del codificador que se utilice. El tamaño total de la trama (el análisis incluye hasta el nivel de enlace) depende además del tamaño del encabezado de cada uno de los protocolos que intervienen, estos son RTP, UDP, IP y el protocolo de nivel de enlace utilizado (ATM, FR, Ethernet, entre otros). La siguiente figura ilustra el proceso de codificación y paquetización que ocurre en un teléfono IP para convertir la voz analógica en voz paquetizada. Éste consta de tres bloques, el bloque de conversión analógico-digital (muestreo y cuantificación), el bloque de codificación, y el bloque de paquetización.

2 Diagrama en bloques de un teléfono IP. El primer bloque realiza la conversión analógica/digital muestreando a una tasa de muestras por segundo con 8 bits por muestra, dando como resultado una tasa de datos de entrada al codificador de 64kbps. La mayoría de los codificadores que se utilizan comercialmente parten de este tipo de señal digital para codificar. Luego, dependiendo del codificador que se utilice, los parámetros Cr, Tt y Lt cambiarán. Cr es la tasa de entrada divida por la tasa de salida. Cuando se codifica la señal digital entrante, esta se almacena durante un tiempo y cuando se recolecta la información suficiente, se comprime. Esto da lugar a ráfagas de datos comprimidos a la salida del codificador. A este tiempo de duración entre ráfagas se le llama tamaño de trama (Tt) y se mide en unidades de tiempo (normalmente milisegundos). La salida del codificador tendrá una longitud en bytes dependiente del tamaño de la trama que la llamamos longitud de trama (Lt). Del codificador salen tramas de longitud Lt y duración Tt que entran al paquetizador, el cual acumula N tramas y las coloca en el campo de información del protocolo RTP que, a su vez, es colocado dentro de un paquete IP. Se podría atribuir a este bloque la función de agregar el nivel dos. A toda esta información que agrega el paquetizador se le llamará encabezado (H). Para calcular entonces el tamaño total del paquete (Pl) en bytes habrá que sumar el encabezado H, más la longitud de trama (Lt) multiplicada por la cantidad de tramas por paquete (N). Pl = H + Lt N El codificador aporta una trama cada Tt segundos, pero el paquetizador acumula N tramas y luego agrega H y las envía. Por lo que sacará un paquete cada N Tt segundos, lo que da una tasa de paquetes de 1/(N Tt).

3 El ancho de banda (BW) se obtiene de la multiplicación del tamaño total del paquete (Pl) pasado a bits y la tasa de paquetes (Pr). BW = Pl Pr 8 (H + N Lt) 8 BW = N Tt Para realizar el cálculo del ancho de banda es necesario conocer las características de los codificadores a utilizar. La siguiente figura muestra cómo funcionan la mayoría de los codificadores empleados en teléfonos IP. Muchos codificadores presentan estos tres parámetros básicos que se observan en la figura: El tiempo de trama (Tt), el retardo de "lookahead" (Tla) y el tiempo de procesamiento (Tproc). A éste tipo de codificadores se los llama basados en tramas. No todos los codificadores funcionan exactamente de esta forma pero sí muchos de los más importantes como el G.729 y el G.723. El codificador G.711 es un codificador basado en muestras, aunque, se puede decir también que es un codificador basado en tramas donde cada muestra tiene 8 bits. A la entrada del codificador hay una cantidad de información (TRAMA 1 por ejemplo) que requiere ser codificada y transmitida. La información en TRAMA 1, correspondería a Tt milisegundos de voz y a M bytes de longitud. La longitud M saldría simplemente de multiplicar 8000 muestras (bytes) por segundo por el tiempo de trama (Tt). Luego de comprimirse la información, la salida será TRAMA 1c que contendrá la información de audio correspondiente a Tt milisegundos pero una longitud en bytes Lt que será M/Cr. A pesar de que la información de voz corresponde a Tt milisegundos, para realizar la compresión se necesitan Tt + Tla milisegundos. Esto se debe al funcionamiento de los algoritmos que se utilizan para realizar el cálculo. Estos algoritmos precisan conocer muestras del futuro para estimar mejor la señal de audio y poder así lograr una compresión mayor. A esta información más allá del Tt se la conoce como retardo de "lookhead" y su valor depende específicamente de cada codificador.

4 Funcionamiento del codificador La compresión tiene un tiempo de procesamiento que dependerá del procesador utilizado y de la complejidad del algoritmo. Este tiempo se conoce como tiempo de procesamiento (Tproc). Los procesadores digitales de señal (Digital Signal Procesors, DSP) son procesadores especialmente diseñados para este tipo de operaciones. Un parámetro de medición de desempeño de estos procesadores es la cantidad de millones de instrucciones por segundo que puede ejecutar (MIPS). Existen criterios para seleccionar un DSP que realice la compresión de la voz: El tiempo para realizar la compresión no puede exceder de Tt, porque es el tiempo de espaciamiento entre tramas. Si el DSP tardase más tiempo en realizar la compresión, le estaría llegando la TRAMA 2 cuando todavía no ha terminado de comprimir la TRAMA 1 y así sucesivamente.

5 El DSP tiene que ejecutar una cierta cantidad de instrucciones en ese tiempo. La cantidad de MIPS (Millones de Instrucciones por Segundo) necesarias dependerán del tipo de codificador que utilice. En síntesis, el retardo inicial desde que entra el primer bit sin comprimir hasta que sale del codificador transcurren Tt + Tla + Tproc, el espaciamiento entre tramas y la duración de la información de audio contenida en cada trama es Tt, y se necesitan Tt + Tla milisegundos a la entrada para poder comenzar a realizar la compresión en este tipo de codificadores. En la tabla siguiente se muestra un listado de los codificadores más utilizados con los parámetros correspondientes. Parámetros de codificadores más usados. Los CODECs afectan el ancho de banda porque ellos determinan la carga útil en el tamaño de los paquetes transferidos sobre el tramo IP de la llamada. Si se incrementa el tamaño de la carga útil, se reduce el número total de paquetes enviados, reduciendo el número de cabeceras necesarias para la llamada, lo cual disminuye el ancho de banda necesario. Cálculo de la longitud del paquete IP La voz se empaqueta sobre RTP, que a la vez lo hace sobre UDP y este sobre IP. Estos elementos están siempre en una comunicación de VoIP. En cambio el protocolo de nivel dos puede ser cualquiera que pueda transportar IP (ATM, FR, Ethernet, entre otros). El protocolo RTP tiene tamaño variable, aunque siempre que no haya mezcla de audio, el tamaño será de 12 bytes. Como se muestra en la figura siguiente, cada fila posee 32 bits (4 bytes), y los campos en negro son los que se transmitirán normalmente. El campo SSRC es el que identifica a la fuente de audio. En el caso de conferencias el tamaño será de éstos 12 bytes + 4 bytes por cada fuente contribuyente. Es decir, cuando un dispositivo

6 mezcla ráfagas de audio, el dispositivo que mezcla está identificado por el SSRC mientras que las ráfagas de audio que recibe el mezclador con un determinado SSRC, son identificadas por el CSRC que posee 4 bytes. La cantidad de fuentes de audio mezcladas está indicada con el contador de contribuyentes (CC). Cuando no se mezcla audio el CC va en cero. Paquete RTP. En UDP el tamaño del encabezado es de 8 bytes. En cuanto a IP el encabezado en la mayoría de los casos es de 20 bytes, pero podría crecer hasta 60 bytes con el campo de opciones. Esto no es usual en VoIP por lo que se toma 20 bytes como tamaño de la cabecera IP. El total de la longitud de encabezados en el paquete es entonces: Longitud de encabezados para protocolos Cada protocolo tiene su propio encabezado, el cual debe ser transportado en conjunto con la voz digitalizada. Por lo tanto, si el sistema CODEC fuese G.729 muestreando en períodos de 20 ms por muestra de 8 bits, el total de la trama sería de 60 octetos ó 480 bits, por lo que el ancho de banda total requerido es de 24kbps. Si hacemos que el período de la muestra disminuya, el tamaño del encabezado permanece igual por lo que, porcentualmente, el encabezado es mayor cuando la muestra es menor. Aunque las muestras de voz son comprimidas por el Procesador Digital de Señales (Digital Signal Processor - DSP), y difieren en el tamaño en dependencia del CODEC utilizado, las cabeceras siempre tienen un tamaño constante de 40 bytes. Si se analiza un paquete de VoIP, donde se ha utilizado, como en el ejemplo anterior, el CODEC G.729

7 para codificar la voz, la cabecera resulta relativamente grande en comparación con los 20 bytes de muestra de voz por defecto del CODEC. Utilizando Compresión de la Cabecera RTP (RTP Header Compression - crtp), las cabeceras IP/UDP/RTP pueden comprimirse de 40 a 2 ó 4 bytes. Esta compresión puede ofrecer un importante ahorro del ancho de banda en VoIP. En la siguiente figura se ilustra la compresión del encabezado: Compresión de encabezado A primera vista puede resultar difícil creer que 40 bytes de cabeceras se logren reducir a sólo 2 ó 4. Pues, si analizamos las cabeceras de los protocolos IP, UDP y RTP, mostrados en la figura anterior, nos damos cuenta de que en un flujo de datos individual, entre una sola fuente y un destino, la mayoría de sus campos no cambian entre un paquete y otro. En la siguiente figura se muestran, sombreados en color gris, los campos que no cambian en paquetes consecutivos. A partir de aquí sería fácil pensar en algún tipo de algoritmo de comprensión que no retransmita estos campos con cada paquete. Adicionalmente se pueden observar dos campos, la longitud del paquete IP y la longitud de UDP, que pueden ser considerados redundantes en muchas de las tecnologías de sistemas de redes, pues la capa de enlace (Ethernet, PPP, etc.) también indica la longitud completa del paquete. Por tanto, estos dos campos pueden ser removidos de los paquetes transmitidos. Por otro lado, otro campo más de IP y dos de RTP pueden ser descritos como predecibles. La identificación de fragmento de IP y el número de secuencia de RTP se incrementan previsiblemente en uno con cada paquete transmitido, y la estampilla de tiempo (timestamp) RTP se incrementa de acuerdo a la razón de paquetes intercambiada en los parámetros de sesión RTP. Estos tres campos también podrían ser excluidos. Examinando todos los campos mostrados en la siguiente figura, vemos que sólo uno permanece: la suma de chequeo de la cabecera IP. Pero si ningún otro campo de la cabecera IP se necesita, este campo deja de tener sentido y también podemos eliminarlo.

8 Al parecer no se necesita ninguna de las cabeceras, se podría lograr una simplificación completa. No obstante, el receptor de un paquete comprimido (el descompresor) debe ser capaz de reconstituir las cabeceras para que el paquete pueda ser procesado por IP y el software de las capas superiores. Para esto debe recibir el primer paquete sin comprimir, con todas sus cabeceras presentes, y almacenar sus campos en un bloque de estado dentro del contexto al que pertenece el flujo de paquetes. Cuando llega cada paquete comprimido del contexto, el descompresor puede reconstruir las cabeceras usando los datos almacenados. Para establecer el contexto de un paquete comprimido (a fin de que el descompresor pueda restituir los campos de las cabeceras IP, UDP y RTP) se debe intercambiar un identificador extremo a extremo, orientado a conexión. El identificador de sesión de contexto (CID: Context Session Identifier) puede tener una longitud de 16 bits (permitiendo hasta contextos) o puede ser reducido a 8 bits si no se requieren más de 256 contextos. Cuando se transmite el paquete completo inicial para establecer los valores invariantes de las cabeceras, se utilizan los campos de longitud redundantes para transportar el CID del contexto como se muestra en la siguiente figura. El primer bit del campo de longitud del paquete IP es usado para indicar si el CID usado es de 8 ó 16 bits. Cuando los paquetes comprimidos son enviados, comienzan con una bandera para indicar si el CID usado es de 8 ó 16 bits y después viajan sólo con el CID. Como se comentó antes, el identificador de fragmentos de IP y el número de secuencia de RTP son predecibles, pero no son enteramente redundantes pues sirven para detectar

9 paquetes perdidos o fuera de orden. Este procedimiento, no obstante, puede ser reducido razonablemente a sólo 4 bits, brindando la misma función, a pesar de tener una ventana más pequeña. Como se muestra en la siguiente figura, cuando las cabeceras son transmitidas completas, el número de secuencia es transportado también en el campo innecesario de longitud. Para identificar completamente a los paquetes comprimidos se usa el número de secuencia junto con el CID. Note que la ubicación del número de secuencia cambia de acuerdo a si el CID usado es de 8 o 16 bits. El transmisor (compresor) tiene ahora la opción de enviar los paquetes como paquetes IP no comprimidos (de forma normal), con las cabeceras completas pero reemplazando todos los campos con CIDs (de esta forma se prepara al descompresor para recibir paquetes comprimidos) o como paquetes comprimidos. Además, el transmisor puede elegir si comprimir todas las cabeceras o sólo las de IP y UDP. Por otro lado, el nodo receptor necesita contar con alguna forma para determinar qué tipo de paquete, de los mencionados antes, se está transmitiendo. Afortunadamente muchos protocolos del nivel de enlace, como Ethernet y PPP, tienen formas de indicar qué protocolo viaja en su carga útil. Este mecanismo es usado para indicar que la carga útil es IP, pero puede ser extendido para indicar que el paquete es de IP con CIDs (FULL_HEADER), que tiene comprimidas las cabeceras IP y UDP (COMPRESSED_UDP), o que está totalmente comprimido, incluyendo RTP, (COMPRESSED_RTP). Además de los ya mencionados, se requieren dos tipos más de paquetes. El primero, COMPRESSED_NON_TCP, que usa todas las cabeceras comprimidas e incluye 2 bytes extras para transportar el campo de identificación de fragmento de la cabecera de IPv4. Éste puede ser útil en enlaces que presenten un alto porcentaje de pérdida de paquetes, pues ayuda a identificar los paquetes perdidos. El último tipo de paquete es el CONTEXT_STATE, que es usado para permitir al descompresor solicitar el envío de un

10 paquete con todas las cabeceras de parte del compresor para refrescar su estado en el contexto. Esto puede ser hecho periódicamente para chequear el sincronismo, después de haber realizado numerosos cambios o después de que se detecte un error. Nota: Para conocer con más detalles la estructura de estos diferentes tipos de paquetes, te recomendamos ir al epígrafe 15.4 del libro The Internet and Its Protocols de la bibliografía complementaria. Con esta compresión el ancho de banda de un canal G.729 se reduce de 24kbps a 11.2kbps, lo cual hace más eficiente el uso de los recursos de transmisión. La compresión de encabezado, como se explicó, puede estar presente hasta un 98% del tiempo, sin embargo, se debe enviar una trama del encabezado sin comprimir cada cierto tiempo para verificar el estado de ambos lados de la conexión, esto debe realizarse periódicamente o cuando un campo fijo del encabezado ha cambiado, por ejemplo el tipo de tráfico transportado. La compresión de encabezado, es una forma de ahorro de ancho de banda que puede utilizarse cuando el ancho de banda es escaso, o en casos donde el ancho de banda es caro, como por ejemplo en una transmisión satelital. En enlaces de ancho de banda considerable, la mayoría de fabricantes, no recomiendan utilizar compresión de encabezados ya que con esta función, los microprocesadores de los enrutadores se utilizan más por lo que puede experimentar problemas a la hora de ejecutar otras tareas. Es una buena práctica que los CPU de los enrutadores trabajen entre el 60 y 70% de su capacidad para que la red funcione sin problemas de congestión. Una alternativa a utilizar compresión de encabezados es la de mandar más tramas de voz por paquete para enviar menos encabezado en relación al tráfico efectivo enviado. Esto es particularmente efectivo en enlaces satelitales, y el sistema a adquirir debe contar con esta funcionalidad. Por ejemplo en un sistema operando con G.729 se envían 2 tramas de voz por paquete, pero es posible enviar 4, claro pagando el precio con retardo adicional de 20ms en estos casos. Cálculo de la longitud del encabezado de nivel 2 A continuación se analizan los distintos tipos de transporte a nivel 2 para el tráfico de voz sobre IP. En la mayoría de los casos, simplemente se trata de calcular cual es el valor de encabezado que habría que sumar al paquete IP en función del nivel de enlace que se utilice.

11 Ethernet Trama Ethernet. Si se suman en la figura anterior la cantidad de bytes de encabezado más el tráiler, se obtienen 38 bytes, y este es el valor que habría que utilizar en el cálculo. Muchas veces se olvida considerar los campos Preámbulo, SFD, e IFG debido a que no poseen información concreta sino que cumplen funciones de sincronismo a nivel de acceso al medio q Trama Ethernet con formato 802.1q. En el caso de trabajar con tramas Ethernet con formato 802.1q, presente normalmente en puertos del tipo trunk en los switches o routers, habrá que sumar 4 bytes más, es decir, el total es de 42 bytes. Si se utiliza QinQ o VLAN STACKING, habría que simplemente sumar 4 bytes más a los 42. PPPoE En este caso hay que sumar 6 bytes más al encabezado de Ethernet. Cuatro bytes de PPPoE y dos bytes de PPP. PPP El protocolo PPP esta desarrollado para transportarse con distintos protocolos de enlace, pero la forma más utilizada es con HDLC. El formato de trama para este transporte es el siguiente: Formato de la trama PPP. Según se ve en la figura, el tamaño del encabezado sería de entre 6 y 9 bytes dependiendo del tamaño del campo Protocolo. Si se utiliza la compresión de encabezado definida en PPP, los campos de Dirección y control no se transmiten ya que son constantes y no hay ambigüedad ya que el campo de protocolo no puede ser 0xFF. En la práctica se suelen considerar 6 bytes de encabezado.

12 MLPPP Tiene dos modos de trabajo, con número de secuencia largo ó con número de secuencia corto. En el primer caso, se agregan 4 bytes al encabezado de PPP, mientras que en el segundo 2 bytes. MPLS Cuando se usa este tipo de tecnología, se agrega una etiqueta de 4 bytes entre el protocolo de enlace y el de red. En principio el protocolo de nivel 2 debería indicar que sobre éste está la etiqueta de MPLS. Formato de la trama usando MPLS. Para el cálculo de ancho de banda habría entonces que sumar los 4 bytes de MPLS al encabezado de nivel 2. En el caso de que se concatenen etiquetas, se deberían sumar 4 bytes más por cada etiqueta. Optimización con sistemas VAD Existen otros factores a tener en cuenta en el cálculo del ancho de banda como es la supresión de silencio que se basa en la Detección de Actividad de la Voz. (Voice Activity Detection - VAD). Por lo general, las conversaciones pueden contener un 60 porciento de silencio. En las redes de telefonía tradicionales basadas en conmutación de circuitos, todas las llamadas de voz utilizan un ancho de banda constante de 64 kbps sin importar cuánto tiempo de la conversación se emplea en hablar y cuanto en silencio. En las redes de VoIP tanto la conversación como el silencio es paquetizado. La Detección de Actividad de Voz envía paquetes RTP sólo cuando es detectada la voz. De esta forma, el transmisor deja de enviar información ahorrando ancho de banda. El factor de actividad de la voz suele considerárselo en el orden de un 35%, aunque un valor de 50% parece ser un valor más acorde a mediciones reales. Como consecuencia, se suele multiplicar el resultado del cálculo del ancho de banda por este factor. Efecto de usuarios concurrentes Lo establecido anteriormente es válido para situaciones donde solo existe un usuario. Sería tentador pretender diseñar una red de voz, en la cual calculemos el ancho de banda y multipliquemos por el 40% para dar un dato realista del requerimiento real de ancho de banda, lastimosamente, esto no puede asumirse así y debemos tomar en cuenta el efecto de otros usuarios en la red, que también utilizan los recursos de transmisión. Entonces, lo que hace falta es saber cuánto ancho de banda extra necesitamos para acomodar a todos los usuarios. Dicha respuesta puede encontrarse al desarrollar la función de distribución binomial. Si consideramos que existen n suscriptores, la probabilidad de que x número de suscriptores estén hablando al mismo tiempo viene dada por la siguiente ecuación:

13 Donde p = 0.4 (probabilidad de habla en la conversación) Entonces la probabilidad de que no hayan más de x suscriptores hablando en un tiempo determinado está dada por: El objetivo es buscar entonces el valor de x para que la probabilidad sea lo suficientemente alta como para asumir que no habrán más suscriptores hablando al mismo tiempo, por ejemplo una Pb de Sumamos entonces los Pa(0) + Pa(1) + Pa(2) + hasta que el total sea o exceda Por ejemplo si requerimos que nuestra red pueda manejar hasta 1000 llamadas simultáneas, y el factor VAD es del 40%, necesitamos que la probabilidad de que se pierdan paquetes sea igual o menor a 0.1, entonces valuando la función obtenemos un valor de x de 448 a 458 de 1000 usuarios posibles. Esto implica que el dimensionamiento de la red puede considerar 448 usuarios en cualquier dirección por cada 1000 usuarios conectados. A continuación se ilustra la gráfica de Pb que nos ayuda a describir mejor este comportamiento: Efecto de suscriptores concurrentes utilizando VAD Consideraciones para el cálculo del ancho de banda Otro factor que suele sumarse al cálculo es el aumento de ancho de banda debido al envío de mensajes de RTCP (Real-Time Transport Control Protocol). La RFC3550 donde se definen los protocolos RTP y RTCP, recomienda reservar un ancho de banda de un 5% más para el envío del RTCP.

14 Finalmente es necesario considerar el diseño de la topología de la red. Los circuitos PSTN están construidos como enlaces punto a punto, y las redes VoIP son fundamentalmente punto a multipunto, por lo que es necesario considerar a dónde se está dirigiendo el tráfico y agrupar a este consecuentemente. Este agrupamiento se convierte en un factor más para decidir un ancho de banda en los enlaces redundantes. Los enlaces punto a punto no necesitarán más ancho de banda que el número de llamadas de voz introducidos hacia y desde los enlaces PSTN, aunque la calidad de la voz puede afectarse cuando se acerca a la velocidad del enlace. Si uno de estos enlaces se pierde, es necesario asegurar que los enlaces redundantes tendrán la capacidad de manejar el incremento del tráfico. Relación entre el Ancho de banda, el Retardo y la Tasa de error Por lo general, cuando se diseña una red con VoIP, todos los esfuerzos se centran en reducir el consumo del ancho de banda cuanto más sea posible, pero como es usual en ingeniería, todo tiene un costo. En este caso el costo pasa por el aumento de retardo y la tasa de error. Si se supone que se definió el codificador G.729 que trabaja a 8kbps, este codificador tiene un tamaño de trama de 10ms y una longitud de trama de 10bytes. En la tabla 3.3 se muestra el aumento de retardo en función del aumento de N (cantidad de tramas por paquetes), y la disminución de ancho de banda. Relación entre el retardo, cantidad de tramas y ancho de banda Nótese que a menor ancho de banda, mayor retardo. El retardo en esta tabla es solo el Tt multiplicado por N, a este habría que sumar 5 ms más de look-ahead, como máximo 10 ms más de procesamiento, el retardo en la red, y el retardo de decodificación que está asociado a la configuración del jitter buffer que suele estar en el orden de los 20ms. Si se supone que el retardo en la red no supera los 40ms, el retardo de procesamiento es del orden de 5ms, y el jitter buffer de 20ms, se deberían sumar 70ms más a los valores indicados en la tabla. A partir de los ms la percepción de la calidad de la voz en comunicaciones interactivas empieza a disminuir notablemente con lo que no se recomendaría en este caso, elegir un valor de N superior a 5.

15 La última consideración al respecto es que por la naturaleza del transporte de tramas, un bit errado en el FCS de Ethernet por ejemplo implica el descarte de la trama, y el descarte de una trama Ethernet con una información de audio equivalente a 60 ms equivaldría al descarte de 3 tramas Ethernet de 20ms, lo cual podría disminuir la calidad de la voz en ciertos escenarios. Cálculo demostrativo Suponiendo que se desea enviar por la red IP una comunicación, cada vez que llega una muestra vocal del lado TDM (esto es, cada 125 microsegundos, codificación según UIT-T G.711) se debe generar un paquete. Este paquete se compondrá de: - Carga útil = una muestra de voz (1 byte) - Encabezado del protocolo RTP = 12 bytes - Encabezado del protocolo UDP = 8 bytes - Encabezado del protocolo IP = 20 bytes - Encabezado de Ethernet + secuencia FCS = 18 bytes - Tamaño total del paquete = 59 bytes Ahora bien, en un segundo se tienen muestras vocales del lado TDM y según lo asumido anteriormente del lado IP se tienen paquetes de 59 bytes cada uno, traducido esto en ancho de banda resulta ser: - Lado TDM muestras por segundo x 8 bits = bits/s - Lado IP paquetes por segundo x 59 bytes x 8 = bits/s Por lo absurdo del resultado (se requiere a la salida un ancho de banda 59 veces superior al de entrada), queda claro pues, que la paquetización de la voz no se hace muestra a muestra TDM. Aparece entonces un nuevo concepto, el denominado período de paquetización o sampling rate. Para generar un paquete de voz IP se espera hasta acumular una cantidad importante de muestras vocales TDM; por ejemplo, un período típico de paquetización es de 20 milisegundos. Del lado TDM, en 20 milisegundos se acumulan: 1 muestra vocal μs X muestras vocales ms X = 20 / 0,125 = 160 muestras vocales

16 En estas condiciones, el súper paquete de voz se compondrá de: - Carga útil = 160 muestras de voz (160 bytes) - Encabezado del protocolo RTP = 12 bytes - Encabezado del protocolo UDP = 8 bytes - Encabezado del protocolo IP = 20 bytes - Encabezado de Ethernet + secuencia FCS = 18 bytes - Tamaño total del súper paquete = 218 bytes Para este caso, en un segundo se tienen muestras vocales del lado TDM; del lado IP se tienen 50 paquetes de 218 bytes, traducido esto en ancho de banda resulta: - Lado TDM 8000 muestras por segundo x 8 bits = bits/s - Lado IP 50 paquetes por segundo x 218 bytes x 8 = bits/s Este último resultado parece ser más lógico. Se puede observar que debido al overhead introducido por los encabezados de los protocolos de transporte, el ancho de banda requerido a la salida es mayor que el de entrada. Para reducir este ancho de banda se puede hacer uso de varias herramientas: - Alrededor del 60 % del tiempo de una comunicación son silencios, en el origen pueden suprimirse estos silencios y no transmitirse (luego en el destino se sintetizan). - En lugar de mantener la codificación G.711, en el lado IP puede utilizarse otra que requiera una tasa menor en lugar de los 64 kbps. - Una combinación de las anteriores; es decir, otra codificación con supresión de silencios. Aplicando como variante la codificación G.729 sin supresión de silencios y con un período de paquetización de 20 milisegundos, se obtiene: Del lado TDM (G.711), en 20 milisegundos se acumulan: 1 muestra vocal μs X muestras vocales ms X = 20 / 0,125 = 160 muestras vocales

17 En estas condiciones, en el lado IP, el paquete de voz se compondrá de: - Carga útil = 20 vectores representativos de la voz con codificación G.729 (20 bytes) - Encabezado del protocolo RTP = 12 bytes - Encabezado del protocolo UDP = 8 bytes - Encabezado del protocolo IP = 20 bytes - Encabezado de Ethernet + secuencia FCS = 18 bytes - Tamaño total del paquete = 78 bytes En un segundo se acumulan muestras vocales del lado TDM; del lado IP son 50 paquetes de 78 bytes, traducido esto en ancho de banda resulta ser: - Lado TDM muestras x 8 bits = bits/s - Lado IP. 50 paquetes x 78 bytes x 8 = bits/s De este modo se aprecia con total claridad que ocurre un ahorro sustancial de ancho de banda (más de la mitad), que como casi todo en ingeniería tiene su costo, en este caso se trata de haber introducido una nueva demora en el proceso para acumular muestras vocales (en este ejemplo, 20 ms), así como del empleo de un CODEC que bien debe tomar una menor cantidad de muestras por segundo o bien codificar las muestras con menor cantidad de bits para reducir la tasa; ambas formas tienen el mismo efecto, pérdida de información que a la hora de reconstruir la voz se traduce en peor calidad. La supresión de silencios en el origen suele ser denominada VAD (Voice Activity Detection) y la sintetización de ruido blanco en el destino suele ser llamado CNG (Comfort Noise Generation). Tal y como se ha dicho ya, con estas técnicas se logra reducir el ancho de banda requerido a costa de introducir demoras adicionales, que rondan en la práctica los 10 ms. Comprobación: En los ejercicios propuestos de este tema podrás encontrar la forma de comprobar si dominas el método para el cálculo del ancho de banda de VoIP. Si no logras resolver estos ejercicios nuestro concejo es que vuelvas a estudiar este epígrafe y lo intentes nuevamente.