Modulo 3

REDES AVANZADAS DE TELECOMUNICACIONES
rubenkustra@gmail.com 1

Ing. RUBEN KUSTRA
rubenkustra@gmail.com

MODULO 3: Redes de Datos

** Parte de este material ha sido redactado por el Ing. Eduardo Moreira
del ITBA.

Objetivo del modulo:

A la finalizacin del curso el alumno podr entender :
Los principios fundamentales de transmisin de seales en tiempo
real sobre redes asincrnicas.
Las implementaciones de Voz sobre IP (VOip) en las Redes de
Nueva Generacin (NGN en Ingles).
Como se interconectan las Redes de Nueva Generacin.
Los aspectos tecnolgicos relativos a la Calidad de Servicio que
afectan el funcionamiento de las Redes de Nueva Generacin y las
herramientas disponibles para lograr un adecuado nivel de
servicio.

ndice:

Unidad 1
Transmisin de seales en tiempo real en redes asincrnicas
Presentacin del escenario
Transmisin de voz en redes asincrnicas
Resumen de VoFR
Resumen de VoATM
Paquetizacin
Tamao del Payload a utilizar
CODEC a utilizar
Retardo extremo a extremo
Eco
VAD y CNG


Unidad 2
Sealizacin de telefona en redes sobre paquetes
Sealizacin en una red de VoIP - Necesidades
Sistemas de sealizacin estndar
ITU-T Rec. H.323
Endpoints
Gatekeeper
Peer to peer (P2P)
Gatekeeper routed call
IETF RFC 3261 Session Initiation Protocol (SIP)
Componentes y protocolos
Universal Resource Identifier (URI)
Sistemas de sealizacin propietarios

Unidad 3
Interconexin entre redes de telefona
Interconexin de redes de Voz sobre paquetes con las redes
tradicionales de telefona
Entre operadores que utilizan redes TDM
Entre un operador que utiliza una red TDM con un operador que
utiliza una red VoIP
Entre operadores que utilizan redes VoIP
Traslacin de la sealizacin
Transcodificacin del canal de audio
SIGTRAN

Unidad 4
Calidad de servicio en redes de telefona sobre paquetes
QoS en redes de voz sobre IP - su influencia en la topologa de red
Calidad de Voz
Probando la Calidad de Voz
Medicin de claridad
Puntajes de PSQM+
Mediciones de Retardo
Mediciones de Eco
Calidad del Call Setup
Parmetros de performance de una red IP y sus efectos sobre la calidad
de voz
Recursos para brindar QoS: RSVP, MPLS, BW, etc.


APENDICES: Articulo sobre Comunicaciones unificadas + NGN (Contec).
IMS.

.- Bibliografia y acronimos.

Contenido temtico:

Unidad 1
Transmisin de seales en tiempo real en redes asincrnicas

Introduccin

Las redes de telefona han evolucionado desde sus inicios hasta llegar a
un punto de ruptura en el diseo conceptual de la solucin tecnolgica en
que se basa su funcionamiento.

Las primeras centrales telefnicas conmutaban manualmente circuitos
analgicos que luego fueron migrando a conmutacin electromecnica
automtica y luego a conmutacin electrnica automtica de circuitos
digitales.


Central telefnica manual circa 1900

Figura 1


Figura 2

Selector Strowger corazn de una central telefnica electromecnica
del tipo de elevacin y giro


Figura 3

Central telefnica de conmutacin de circuitos digital Siemens EWSD


Figura 4

Cada cambio tecnolgico tuvo su punto de ruptura. El ltimo que
presenciamos se da por el agotamiento del desarrollo de funcionalidades
basadas en la conmutacin de circuitos, sumado al incremento de
necesidades de ancho de banda en la conexin de los usuarios y de
integracin de redes, para poder brindar servicios de valor agregado
convergentes.

As surgen soluciones de transmisin de seales en tiempo real sobre
redes asincrnicas, que si bien no ofrecen garantas intrnsecas de
entrega de seales en tiempo real, si disponen de ancho de banda on-
demand suficiente y herramientas para su gestin, para correr
aplicaciones de servicios.
A este movimiento se le suman las necesidades de unificacin de redes
de servicios. Por un lado tenemos las redes conmutadas de circuitos y
por otro lado las redes asincrnicas de paquetes. Esta separacin atenta
contra las necesidades de economa de operacin y de integracin de
servicios.

Elementos en una red VoIP


Figura 5. Evolucin de la redes de telefona siguiendo una adaptacin de
la teora del Equilibrio Puntuado


Que son las seales en tiempo real

Las seales en tiempo real son aquellas seales sensibles al delay. La
informacin transportada debe ser entregada a su destinatario dentro de
un tiempo definido, pasado el cual la informacin ya no es relevante o la
calidad de servicio cae abruptamente.
Las seales en tiempo real las podremos dividir en dos categoras
mayores : Streaming y Servicios Interactivos.

Ejemplos de Streaming son las transmisiones unidireccionales de
Broadcasting (radio y TV) y ejemplos de Servicios Interactivos son la
telefona y la video conferencia.

En el primer caso, un delay de varios segundos en la transmisin de un
partido de ftbol en vivo y en directo no afecta la calidad de la
experiencia del usuario, mientras que en el segundo caso, una
conversacin telefnica debe tener una cadencia adecuada, con delays
del orden de los milisegundos, para poder ser llevada a cabo
satisfactoriamente para el usuario.

Figura 6. Ejemplos de seales en tiempo real : Servicios Interactivos y
Servicios de Streaming


Presentacin del escenario

Esquema bsico de una transmisin de voz en la red telefnica
conmutada :

Figura 7. Esquema bsico de la red TDM

La experiencia de una conversacin (voz) es un intercambio de datos en
tiempo real susceptible a varios factores fsicos fundamentales que
inciden en la calidad de la experiencia :

Factores Fsicos :
CLARIDAD
RETARDO
ECO
INTERRUPCIONES

Tradicionalmente las redes de voz se han basado en redes TDM (Time
Division Multiplexing) de conmutacin de circuitos, donde la Claridad, el
Retardo, el Eco y las Interrupciones estn perfectamente acotados,
predecibles y son constantes a lo largo del tiempo debido al principio
mismo de funcionamiento de la tecnologa.
Las redes TDM son bsicamente redes sincrnicas perfectamente
acomodadas para el transporte de la voz humana en tiempo real.


Figura 8.Factores fsicos que inciden en la calidad de voz Redes TDM
fijados por la tecnologa

Las redes de paquetes y en particular las redes IP estn perfectamente
acomodadas para el transporte de servicios asincrnicos. El e-mail
(Simple Mail Transport Protocol - SMTP [RFC 821] e Internet Message
Access Protocol - IMAP [RFC 2060]) y la navegacin Web (HyperText
Transfer Protocol HTTP [RFC 2616]) han potenciado el crecimiento de
las redes IP, tanto pblicas como privadas, como infraestructura de
transporte para la creacin de servicios de valor agregado. Estos
servicios consisten en el intercambio asincrnico de informacin.

El crecimiento de las redes IP ha requerido el desarrollo de herramientas
para su gerenciamiento y control, que han permitido incrementar la
calidad de servicio brindada por este tipo de redes y predecir y
garantizar su funcionamiento. Estas mejoras posibilitaron experimentar
con el transporte de seales en tiempo real, alimentando un crculo
virtuoso de mejoras que desembocaron en redes IP lo suficientemente
robustas y predecibles para la implementacin de servicios en tiempo
real y garantizar su funcionamiento.

Los niveles de calidad de servicio que es posible hoy da alcanzar con las
redes IP gerenciadas, ha permitido llevar el transporte de seales en
tiempo real a un estado superior, como es el caso del transporte de
flujos sincrnicos, por ejemplo E1s, T1s, E3. Estas tecnologas, conocidas
como TDMoIP CEoIP (Circuit Emulation over IP) genricamente como
pseudowire, implementan algoritmos avanzados de recuperacin de
reloj en el extremo distante que permiten mantener el sincronismo.
Estas tecnologas estn normadas por el ITU-T (Rec. Y-1413), mientras


que existe un draft del IETF.

Las redes IP han probado tener la capacidad de transportar cualquier
tipo de seal, por lo que es usual escuchar generalizaciones como AoIP
(Any over IP).

Figura 9.Factores fsicos que inciden en la calidad de voz Redes VoP
gerenciados


Transmisin de voz en redes asincrnicas

Figura 10.Escenario de una llamada en VoP

La sigla VoP (Voice over Packet) cobija varios conjuntos de protocolos
que permiten el uso de redes asincrnicas (tpicamente redes de
paquetes) para el transporte de voz.

Las redes de VoP pueden estar basadas en diferentes tipos de redes
asincrnicas de transporte. Las redes asincrnicas de transporte podrn
ser Frame Relay, ATM o IP, donde tendremos VoFR, VoATM o VoIP.
Los conjuntos de protocolos sern similares adaptndose a la red de
transporte. Las diferentes redes de transporte pueden emular redes o
realizar el transporte de IP, en esos casos el resultado ser Voz sobre IP.

Resumen de VoFR
VoFR le permite a un router llevar trfico de voz (por ejemplo llamadas
telefnicas y faxes) por una red Frame Relay, utilizando el protocolo
FRF.11. Esta especificacin define datos, voz, fax, DTMF relay y tramas
de sealizacin por canal asociado (CAS)/sealizacin por bit robado. El
backbone de Frame Relay debe ser configurado para incluir el map class
y Local Management Interface (LMI).

Resumen de VoATM
VoATM le permite a una red ATM llevar trfico de voz (por ejemplo
llamadas telefnicas y faxes).
Todo el trfico de o a una red ATM est prefaceado con un identificador


de camino virtual (Virtual Path Identifier - VPI) y un identificador de
canal virtual (Virtual Channel Identifier - VCI). Un par VPI-VCI es
considerado un circuito virtual simple. Cada circuito virtual es una
conexin privada a otro nodo de la red ATM. Cada circuito virtual es
tratado como un mecanismo punto a punto a otro router o host y es
capaz de soportar trfico bidireccional.
Cada nodo ATM establece una conexin separada a cada otro nodo en la
red ATM con el cual se debe comunicar. Todas esas conexiones son
establecidas por medio de un circuito virtual permanente (Permanent
Virtual Circuit - PVC) o un circuito virtual conmutado (Switched Virtual
Circuit - SVC) con un mecanismo de sealizacin ATM. Esta sealizacin
est basada en la especificacin de Interfase de Usuario-Red (User-
Network Interface - UNI) V3.0 del ATM Forum.
Cada circuito virtual es considerado un enlace completo y separado a un
nodo de destino. Los datos pueden ser encapsulados segn sea necesario
a travs de la conexin, y la red ATM no le presta atencin al contenido
de los datos. El nico requerimiento es que los datos sean enviados al
procesador ATM en una manera que sigue el formato especfico de ATM
adaptation layer (AAL)Tanto las redes Frame Relay, como las redes ATM
se utilizan usualmente como capa de transporte para transportar redes
IP. En estos casos estamos en presencia de redes IP que transportan
voz, independientemente de la capa de transporte utilizada.

Muchos tipos de redes se utilizan actualmente para el transporte de
redes IP. Ejemplos son las mismas redes TDM (E1 leased lines), Packet
over SONET/SDH POS [RFC 2615], Point to Point Protocol PPP [RFC
1661] sobre lneas telefnicas, etc., adems de las redes Frame Relay y
las redes ATM.

En ms estudiaremos Voz sobre IP, siendo sta la ms difundida.


Las redes de VoIP estn caracterizadas por los siguientes conceptos :

1 Paquetizacin
2 Retardo extremo a extremo
3 Eco
4 VAD y CNG

Paquetizacin

Figura 11.Generacin del flujo RTP

El flujo de datos entregado por el conversor A/D al VoP engine es de 1
byte cada 125 microsegundos 8.000 bytes por segundo (ver teorema
de Nyquist Muestreo y Cuantificacin - Digitalizacin de seales
telefnicas).

El extremo inferior de paquetizacin ser un paquete por cada byte
recibido 8.000 paquetes por segundo. El extremo superior no estara
limitado tcnicamente. Suponiendo 1 segundo de tiempo de captura,
tendremos 1 paquete de 8.000 bytes por segundo.


Figura 12.

Tiempo de captura de 125 microsegundos : 8.000 paquetes por segundo
de 1 byte de payload.
Tiempo de captura de 1 segundo : 1 paquete por segundo de 8.000
bytes de payload.

Debe encontrarse el balance entre cantidad de paquetes y retardo de
captura.


En el extremo distante deben proveerse mecanismos que solventen las
degradaciones que sufre el flujo de datos al atravesar la red asincrnica,
esto es, la falta de secuencia, los retardos variables que producen la
entrega de paquetes a ritmo variable y la prdida de paquetes (por
prdida en s por arribar demasiado tarde).

Figura 13.Necesidades de secuenciamiento, temporizacin y
extrapolacin

Los mecanismos disponibles son :

Dejitter buffer
Secuenciador
Extrapolacin

El protocolo que transporta el flujo de audio es RTP (Real Time Protocol
IETF RFC 1889).
RTP corre sobre UDP. UDP no garantiza la entrega de paquetes ni el
secuenciamiento.
La falta de secuenciamiento de UDP es solventada por las aplicaciones
que utilizan RTP, mediante el nmero de secuencia presente en el
encabezado de RTP. Con este nmero de secuencia, la aplicacin puede
discernir si faltan paquetes y ordenar los paquetes que arriban fuera de
orden.
El encabezado RTP tambin provee un timestamp que permite el
rearmado del flujo de audio a inyectar en el lado B a una tasa constante
de 64 kbps.
El encabezado de RTP tambin transporta la indicacin del CODEC


(COder DECoder) con el cual ha sido armado el payload de datos de
audio en origen, de forma que el VoP engine del lado B puede interpretar
el contenido del payload.

El VoP engine estar formado, principalmente por un DSP (Digital Signal
Procesor) que realiza la funcin de paquetizacin en HW, de forma de
descargar al procesador de control del trabajo de lidiar con la seal de
audio.

Los requerimientos de ancho de banda en la red IP quedarn entonces
definidos por dos parmetros fundamentales :

1 Tamao del Payload a utilizar
2 CODEC a utilizar

Tamao del Payload a utilizar
El conversor A/D del lado A entrega un flujo de datos constante de 8.000
bytes por segundo.
Estos 8.000 bytes pueden ser enviados, en un extremo, en 8.000
paquetes de 1 byte , en un posible otro extremo, en 1 paquete de
8.000 bytes.
Cada paquete tiene sus correspondientes encabezados. Los encabezados
son de tamao constante. En el extremo de mnima enviaremos 8.000
veces el encabezado, en el extremo de mxima mandaremos solo 1 vez
el encabezado. Los requerimientos de ancho de banda estarn, entonces,
relacionados con el tamao del payload que se defina de transmisin.
El tamao del payload tambin define el tiempo de captura y, por lo
tanto el retardo extremo a extremo de la transmisin de la voz.
Definiendo payload de 1 byte, el tiempo de captura de 1 byte es de 125
microsegundos, o sea, que el extremo local A demorar 125
microsegundos en armar el paquete de audio para mandarlo al destino.
En cambio, si el payload es de 8.000 bytes, el tiempo de captura es de 1
segundo, o sea, que el extremo local A demorar 1 segundo en armar el
paquete de audio para mandarlo al destino.

Estos extremos indicados son solo a modo de ejemplo para
indicar la variabilidad de los requerimientos de ancho de banda.
Los valores de tamao de payload estn estandarizados para
cada CODEC.

El tiempo de captura deber estar acorde a los requerimientos de calidad
objetivo de la red de VoIP que se est diseando.
Los valores estndar de retardo extremo a extremo (one way) admisibles
para redes de telefona son, de acuerdo a la Recomendacin ITU-T


G.114, de :

Menor a 150 milisegundos para redes nacionales.

Entre 150 y 400 milisegundos para redes internacionales con tramos
satelitales.

Mayor 400 milisegundos es inadmisible para redes de telefona y solo
puede ser aceptado en caso de tramos de larga distancia internacional
donde haya 2 saltos satelitales.

CODEC a utilizar
El conversor A/D entregar la seal de audio muestreada y cuantificada
segn ley A (o ley mu donde sea de aplicacin), a una tasa de
informacin de 8.000 bytes por segundo.
La informacin de audio puede ser codificada a efectos de disminuir los
requerimientos de ancho de banda al suprimir informacin redundante.
Esta codificacin se realiza segn CODECs estndar, normados por el
ITU-T. Los CODECs usualmente utilizados en telecomunicaciones son :

2.1) Recomendacin G.711 ley A y ley mu (64 kbps sin compresin)
2.2) Recomendacin G.729 Annex A (8 kbps)
2.3) Recomendacin G.723 (high 6,3 kbps & low 5,3 kbps)
2.4) GSM (13,2 kbps)

Cada CODEC define una tasa de informacin y diferentes valores de
payload estndar.

Trama de streaming
Figura 14

El encabezado de RTP est compuesto por 12 bytes. El encabezado UDP
es de 8 bytes. El encabezado IP es de 20 bytes.


Cada paquete de payload de audio tendr los encabezados de 12 bytes
de RTP + 8 bytes de UDP + 20 bytes de IP, total 40 bytes (en caso de
trabajar sobre redes Ethernet, a esto se le debe sumar el Inter Frame
Gap, Prembulo de MAC, encabezado de MAC y el FCS).

Como ejemplo de cmo vara el ancho de banda requerido, suponemos
trabajar en G.711.
Si debemos enviar 8.000 paquetes por segundo con payload de 1 byte,
cada paquete tendr 41 bytes + 23 de padding, 64 bytes, nos da
512.000 bytes por segundo 4,096 mbps.
En cambio, si enviamos 1 paquete por segundo con payload de 8.000
bytes (en realidad esto no es posible debido a que el MTU es de 1500
bytes, por lo que el paquete debera fraccionarse en 6 sub-paquetes),
nos da 8.040 bytes por segundo 64,32 kbps

G.711 tiene definidos 3 tamaos de payload estndar :

100 paquetes por segundo de 80 bytes (cada paquete con 10 mseg
de audio)
50 paquetes por segundo de 160 bytes (cada paquete con 20 mseg
de audio)
33,33 paquetes por segundo de 240 bytes (cada paquete con 30
mseg de audio)

A menor tamao de payload, mayor ancho de banda requerido.
Utilizar diferentes tamaos de payload depender de los compromisos de
requerimientos de calidad, disponibilidad de ancho de banda y
confiabilidad de la red.
Si la red IP es poco confiable, perder un paquete de 240 bytes de
payload es ms daino (medido en calidad de audio) que perder un
paquete de 80 bytes.
Si la red IP tiene limitaciones de ancho de banda, utilizaremos payload
mayores para usar menos ancho de banda.
Si la calidad de servicio que debemos brindar debe ser alta, utilizaremos
payloads menores, ya que requieren menores tiempos de captura y
menor retardo extremo a extremo.

Los anchos de banda requeridos para G.711 para los diferentes payloads
estndar son :

80 bytes :
80 bytes + 40 bytes de encabezado = 120 bytes
100 paquetes por segundo de 120 bytes = 12.000 bytes por segundo =
96.000 bps


160 bytes :
80.000 bps

240 bytes :
33,33 paquetes por segundo de 280 bytes = 9.333,3 bytes por segundo
= 74.667 bps

Un CODEC usualmente utilizado en redes de VoIP es G.729, de 8 kbps de
tasa de informacin.
Este CODEC tiene 2 tamaos de payload estndar :

50 paquetes por segundo de 20 bytes (cada paquete con 20 mseg de
audio)
33,33 paquetes por segundo de 30 bytes (cada paquete con 30
mseg de audio)

Los requerimientos de ancho de banda son entonces :

20 bytes :
24.000 bps

30 bytes :
33,33 paquetes por segundo de 70 bytes = 2.333,3 bytes por segundo =
18.667 bps

Variando el CODEC y el payload obtenemos requerimientos de ancho de
banda (solo de IP) que van desde los 19 kbps hasta los 96 kbps.

Retardo extremo a extremo

Debido a que el flujo de audio viaja en una red asincrnica de paquetes,
los paquetes con informacin de audio pueden llegar al extremo distante
fuera de secuencia y a un ritmo de arribada variable.
Los paquetes son recibidos por el VoP engine del extremo distante y
deben ser ordenados para ser entregados al conversor D/A e


inyectarlos a la lnea telefnica.
Este ordenamiento, que debe realizar el VoP engine del extremo
distante, se basa en volver a poner en secuencia los paquetes que
arriban fuera de secuencia, esperar los paquetes que llegan demorados y
en caso de que no lleguen, extrapolar el audio que falta.
Normalmente el VoP engine del extremo distante esperar el tiempo de 3
paquetes para armar el flujo de datos de tasa constante de 64 kbps que
se inyectar al conversor D/A. Esta funcionalidad se denomina Dejitter
buffer.

Entonces tenemos ahora todos los componentes que suman retardo a la
transmisin de voz desde el origen A hasta el extremo distante B en una
red de VoIP :

1) Tiempo de captura en el origen
2) Latencia de procesamiento en el VoP engine del origen
3) Retardo de propagacin en el enlace asincrnico
4) Latencia de procesamiento en el VoP engine del extremo distante o
destino
5) Dejitter buffer en el extremo distante

Suponiendo CODEC G.711 con payload de 160 bytes, con una red IP con
30 milisegundos de RTD (Round Trip Delay) :

1) Tiempo de captura en origen : 20 miliseg
2) Latencia en origen : 1 miliseg
3) Retardo de propagacin (one way) : 15 miliseg
4) Latencia en destino : 1 miliseg
5) Dejitter buffer : 3 x 20 miliseg = 60 miliseg

Total : 97 milisegundos

Eco

Tenemos 2 tipos de eco. El eco local y el eco distante. El eco local es el
que se produce en el Hbrido del origen. El eco distante es el que se
produce en el Hbrido distante.

El eco local es normalmente reproducido en el origen para no tener el
efecto de vaco en el auricular (side tone).
En el ejemplo anterior, si parte de la potencia entregada al Hbrido
distante por el conversor D/A es reflejada, el origen vuelve a recibir
parte del audio que envi 194 milisegundos despus de haberlo enviado.


Este tiempo es suficiente para desacoplar la voz del que est hablando
del eco y ste pasa a ser notorio, por lo que es requerido un cancelador.

Si la transmisin desde el origen al destino es realizada por una red
sincrnica TDM, el retardo total extremo a extremo es del orden de los 5
milisegundos. El eco reflejado en el Hbrido de destino arribara al origen
nuevamente 10 milisegundos despus de haber sido enviado, por lo que
no se llega a desacoplar y no es percibido por el que habla como eco.

Los valores umbrales a partir de los cuales el eco pasa a ser percibido
son :

1 Tiempo en que la voz del que habla retorna a su auricular (Echo Tail
Length ETL) mayor a 32 milisegundos.
2 Atenuacin de la voz del que habla que retorna a su auricular (Echo
Return Loss ERL) mayor a -10 dB.

Como vimos, la transmisin de la voz en la red IP es a 4 hilos, o sea,
los canales de transmisin y de recepcin son independientes,
separados. Con esto, las redes IP de voz no producen eco.
Las redes IP trabajan con retardos mucho mayores que los usuales de
redes TDM. Si la red TDM tiene eco, normalmente no es necesario
controlarlo, salvo en los casos de llamadas de larga distancia donde hay
tramos que deben pasar por enlaces satelitales, donde el retardo de
propagacin es del orden de los 250 milisegundos.

Figura 15. Fuentes de eco durante la llamada

Si esta red TDM con eco se interconecta con una red de VoIP, el eco
presente pasa a ser percibido por el retardo adicional insertado.


VAD y CNG

Normalmente en una conversacin telefnica mientras uno habla, el otro
escucha, turnndose a medida que la conversacin se desarrolla.
En funcin de la naturaleza de una conversacin, aquel que escucha no
est hablando, por lo que no habra informacin referida a la
conversacin que deba ser transmitida desde el extremo del que esta
escuchando hacia el extremo del que est hablando.
El canal de audio de transmisin de aquel que est escuchando sin
hablar solo estar transmitiendo el ruido ambiente que capta. Salvo
casos donde hay mucho ruido de fondo (fbricas, en la calle, etc.) el
ruido ambiente es muy similar al ruido blanco, por lo que si el ruido
blanco puede ser generado en el extremo del que est hablando, no sera
necesario transmitir ste ruido ambiente captado en el origen del que
est escuchando.
Al no ser necesario transmitir informacin de audio, puede ahorrarse el
ancho de banda utilizado por el canal de transmisin del que est solo
escuchando.
Cada extremo del canal de audio tendr umbrales de deteccin de
actividad de voz (est hablando o est escuchando y no habla y solo hay
ruido de fondo). Con esto, cuando el umbral de actividad de voz es
sobrepasado, el VoP engine comienza a transmitir audio; cuando el
umbral es cruzado nuevamente, el VoP engine deja de transmitir audio,
sealizando al otro extremo para que comience a reproducir el ruido de
confort (Confort Noise Generation - CNG).
Esta funcionalidad se denomina Deteccin de Actividad de Voz (Voice
Activity Detection - VAD).


Unidad 2
Sealizacin de telefona en redes sobre paquetes

Sealizacin en una red de VoIP - Necesidades

Una red IP tiene un direccionamiento basado en direcciones IP. Esto tan
obvio tiene una implicancia fundamental cuando se requiere brindar un
servicio de telefona corriendo sobre una red de transporte IP.

Una red telefnica basa su direccionamiento en nmeros telefnicos
(ITU-T Recomendacin E.164).

La finalidad de los sistemas de sealizacin en redes de VoIP es
trasladar la experiencia del usuario de direccionamiento por nmeros
telefnicos a los requerimientos de direccionamiento de una red IP.

Bsicamente los usuarios de una red telefnica conocen nmeros
telefnicos. Una red de VoIP debe proporcionar los elementos de
traslacin de nmeros telefnicos a direcciones IP y viceversa.

En una red IP, el direccionamiento puede ser esttico (cada elemento de
la red IP tiene una direccin IP fija inamovible) dinmico mediante el
servicio DHCP (Dynamic Host Configuration Protocol [RFC 2131]),
donde cada elemento de la red IP obtiene una direccin IP asignada al
momento de conectarse a la red, que ser constante mientras el equipo
permanezca conectado a la red. El direccionamiento puede basarse en
nombres de Hosts mediante el servicio DNS (Domain Name Service -
http://www.dns.net/dnsrd/rfc/). El sistema de sealizacin debe poder
lidiar con todos estos requerimientos.

El sistema de sealizacin en una red de VoIP debe proveer :

1) traslacin de nmeros de telfono a direcciones IP nombres de
Hosts y viceversa
2) registracin dentro de la zona de influencia de la red de VoIP -
presencia
3) estado de los terminales
4) secuenciamiento de eventos de llamada

El sistema de sealizacin de una red de VoIP podr estar compuesto
por diferentes protocolos que realizan funciones especficas requeridas
para el establecimiento de llamadas.

Bsicamente el conjunto de protocolos debe definir :


1) quien llama u origina
2) a quien llama o recibe
3) secuencia y contenido de la mensajera
4) que elementos de red intervienen
5) datos requeridos mandatorios y optativos para el establecimiento
de la llamada
6) casos de error y su tratamiento posterior
7) interworkings con otros sistemas de sealizacin
8) acomodamiento a las regulaciones de aplicacin

Existen varios sistemas de sealizacin creados especficamente para
redes de VoIP.
Los sistemas de sealizacin pueden ser estndar o propietarios.


Sistemas de sealizacin estndar

Existen 4 sistemas de sealizacin estndar :

1) ITU-T Recomendacin H.323
2) IETF RFC 3261 Session Initiation Protocol (SIP)
3) IETF RFC 2705 Media Gateway Control Protocol (MGCP)
4) ITU-T Recomendacin H.248 MEGACO

Cada sistema de sealizacin define un modelo de red de VoIP,
definiendo los elementos lgicos intervinientes, el secuenciamiento, el
contenido de mensajera, etc.
Estos sistemas de sealizacin estndar permiten la interoperatibilidad
entre equipamiento provisto por diferentes fabricantes y desarrolladores
que adhieren al sistema de sealizacin.
Si bien dentro del ncleo de cada sistema de sealizacin se especifican
los servicios disponibles dentro de todo el espectro de servicios
tradicionales de las redes telefnicas, cada protocolo se adapta mejor a
los diferentes tipos de servicio que se desea brindar con la red de VoIP.
As, tradicionalmente el modelo de VoIP de H.323 se utiliz para redes
de larga distancia con escasos servicios disponibles de cara al abonado.
El modelo de VoIP de MGCP es una concepcin centralizada muy
adoptada por los fabricantes de switches TDM que requirieron migrar su
tecnologa a las redes NGN (New Generation Network).
El modelo SIP nace de la misma concepcin descentralizada de Internet
con un lenguaje textual muy similar al HTTP.
El modelo MEGACO nace de un esfuerzo conjunto entre el ITU-T y el
IETF para crear un protocolo que compense las dificultades propias de
cada protocolo existente.

H.323 y SIP suelen ser clasificados como protocolos de Terminales
Inteligentes, mientras que MGCP y MEGACO son clasificados como
protocolos de control de dispositivos.
H.323 y SIP requieren mucha inteligencia en el Terminal del abonado,
mientras que en MGCP y MEGACO la inteligencia est centralizada en el
centro de control de la red.

Cada concepcin de protocolo presenta sus beneficios y perjuicios.
Los protocolos de Terminales Inteligentes presentan la ventaja de que la
inteligencia est descentralizada, por lo que los rganos centrales de
control requieren menor capacidad de procesamiento. Cuando una
nueva funcionalidad es agregada a la red, los Terminales de abonado
deben ser upgradeados para poder soportar los nuevos servicios. El
upgrade de un Terminal es una tarea sencilla, pero en redes con miles a


cientos de miles de Terminales, la tarea es sumamente onerosa y
compleja. Si los Terminales son de diferente tipo y/o proveedor, la
implementacin de nuevas funcionalidades requiere pruebas extensivas
de interoperatividad.

Los protocolos de Control de Dispositivo presentan la ventaja de que la
Inteligencia est centralizada (Terminales tontos). El rgano
centralizado de control tiene implementadas todas las funcionalidades
de red, por lo que la capacidad de procesamiento requerida es
normalmente inmensa cuando estamos en presencia de redes de miles a
cientos de miles de terminales.

No hay una guerra de protocolos. H323 est ya muy debuggeado y su
funcionamiento es robusto, predecible y estable.
SIP se esta imponiendo a fuerza de su simpleza y liviandad. Le falta
camino de estandarizacin por delante.
MGCP y MEGACO son protocolos muy vistos en concepciones migradas
de switches TDM donde el control se encuentra centralizado. No son
modelos amigables que permitan la incursin de desarrolladores
independientes, fundamentalmente en el mbito de aplicaciones de
valor agregado.

Los sistemas de sealizacin H.323 y SIP se encuentran ya tan
difundidos que se han creado grupos independientes de desarrolladores
que han creado bibliotecas libres de cdigo fuente abierto, disponibles
en Internet. Estas bibliotecas de cdigo fuente permiten crear stacks
corriendo en servidores Unix, Linux Windows que, mediante una o
varias APIs (Application Program Interface), se comunican con
aplicaciones desarrolladas ad-hoc, transformando al servidor en un
elemento de red de VoIP, para crear gateways, softswitches, etc.
Si bien existen bibliotecas abiertas de MGCP, no tienen actividad notoria
en Internet ni se ven frecuentemente aplicaciones basadas en esas
bibliotecas.
No se ven en Internet bibliotecas abiertas de MEGACO.

A continuacin describiremos los dos sistemas de sealizacin de VoIP
estndar ms usuales H.323 y SIP, por ser estos los ms difundidos en
el mercado.

ITU-T Recomendacin H.323

Mediante la recomendacin ITU-T H.323, la ITU se embarca a normar
las comunicaciones en VoIP. La versin actual es la 4.


Usualmente se menciona a la recomendacin H.323 como un paraguas
de contencin de una serie de protocolos que definen el funcionamiento
de una red de VoIP.
El modelo de VoIP de H.323 consta de 2 elementos fundamentales :

1 Endpoints
2 Gatekeeper

Endpoints

Los Endpoints son los elementos lgicos que originan y/o reciben
llamadas. Los Endpoints pueden tener 2 funciones bsicas :

1 Terminal
2 Gateway

Como terminal se identifican los HardPhones, los SoftPhones y los ATA
(Analog Telephone Adapter), aunque stos ltimos pueden ser tambin
considerados gateways.
Como gateway se identifican aquellos elementos de red que permiten la
interconexin con otras redes de telefona.
Cada gateway tendr dos lados. Un lado mirando la red de VoIP y el
otro lado mirando a la red TDM. Dependiendo del tipo de conexin que
se tenga del lado TDM tendremos diferentes tipos de gateways :

1) Lneas analgicas FXS y/o FXO
2) Lneas digitales ISDN BRI
3) Lneas digitales E1 con soporte para diferentes tipos de sealizacin :
MFCR2, ISDN PRI CCS#7

Las redes TDM que pueden estar interconectadas a los gateways pueden
ser, respectivamente :

1) Telfonos analgicos, centrales privadas multilneas analgicas
2) Telfonos digitales, centrales privadas multilneas digitales
3) Centrales telefnicas TDM, centrales privadas digitales

Tambin como gateway existen los llamados Session Border Controller
(SBC), que permiten la interconexin de dos redes de VoIP en forma
segura y con control sobre las llamadas. Estos gateways tienen dos
lados VoIP (ver ms adelante en el texto).


Gatekeeper

En una red de VoIP, el gatekeeper es el encargado de realizar la
traslacin de los nmeros E.164 a direcciones IP y viceversa.
El gatekeeper registra todos los gateways y terminales dentro de su
zona. Cada gateway se registrar con su direccin IP (esttica o
dinmica) y un identificador nico H323ID.
Para realizar la traslacin, el gatekeeper contar con una lista de
asignacin de nmeros o parte de nmeros E.164 (prefijos) asignada a
una direccin IP H323ID.

Cada gatekeeper define una zona que controla. Varias zonas pueden
intercomunicarse. El gatekeeper puede tambin enviar y recibir
llamadas a y de otras zonas.

H.323 permite el uso de gatekeepers alternativos. Un terminal/gateway
se registrar en un gatekeeper primario y podr tener una lista de
gatekeepers alternativos en caso de que el primario desaparezca de la
red.

El gatekeeper puede ser controlado a nivel superior por un Call Agent,
Call Server SoftSwitch que le permita tomar decisiones de ruteo
(traslacin de los nmeros E.164 a direcciones IP y viceversa)
inteligentes.

H.323 permite variantes del modelo de resolucin de llamada en funcin
del despliegue de red.

Los modelos de llamada pueden ser :

1 Peer to peer (P2P)
2 Gatekeeper routed call

Peer to peer (P2P)
La llamada es enviada desde el terminal/gateway de origen al
terminal/gateway de destino. No hay un gatekeeper involucrado en la
resolucin de llamada. Este modelo de llamada es sumamente sencillo
pero no contamos con un agente que realice la traslacin de numeracin
E.164 a direcciones IP, por lo que el terminal/gateway de origen debe
poder realizar la traslacin de numeracin E.164 a la direccin IP de
destino. Su aplicacin principal es troncales IP de off-load.


Gatekeeper routed call
La llamada es enviada al gatekeeper para que realice la traslacin del
nmero E.164 discado por el usuario originante a la direccin IP
direcciones donde ese nmero se encuentra o se accede. A diferencia
del modelo P2P, el gatekeeper puede realizar balanceo de carga entre
los gateways de destino. Este balanceo de carga considerar el caso en
que un gateway no est disponible (se desregistr), esta excedido en su
carga (Resource Availability Indicator - RAI) u otros elementos
dinmicos de decisin.

Este modelo de llamada tiene dos subvariantes :

i) Direct mode
ii) Routed mode

i) Direct mode
La sealizacin de llamada es cursada directamente entre los
terminales/gateways de origen y destino una vez que el gatekeeper ha
realizado la traslacin de nmero E.164 a direccin IP. Este modo de
llamada es stateless, ya que el gatekeeper no es informado del progreso
de la llamada.

ii) Routed mode
La sealizacin de llamada es cursada a travs del gatekeeper. Este
modo de llamada es statefull, ya que el gatekeeper conoce el estado de
la llamada. Esto permite implementar sistemas de tarifacin
centralizados.

Para que el gatekeeper pueda realizar la traslacin de nmero E.164 a
direccin IP, el gatekeeper debe saber si el equipo que se encuentra en
la direccin IP definida est presente en la red. Esto se logra mediante
la Registracin.
Cada terminal/gateway se registra en el gatekeeper y mantiene un
keep-alive peridico (tpicamente cada 45 ~ 60 segundos).

Cada funcin dentro de H.323 es realizada por un protocolo definido.
H.323 define un conjunto de protocolos especficos con las siguientes
funciones :
H.225 RAS : Registration, Admission & Status
H.225 Call Signaling (Q.931)
H.245 Control Function Signaling
H.450 Supplementary Services


En funcin del modelo + modo de llamada, los diferentes protocolos
entran en funcionamiento.
En el modelo P2P, los protocolos que entran en funcionamiento son
Q.931 y H.245.
Una llamada realizada en una red servida por un gatekeeper, bajo el
modo routed requiere el uso de los protocolos H.225, Q.931 y H.245
mnimamente. Esto produce gran carga de sealizacin.
A fin de disminuir la carga de sealizacin, la sealizacin de H.245
puede ser embebida (tunelizada) dentro de la sealizacin Q.931, por lo
que se definen dos nuevas subcategoras de sealizacin de llamada :

1 Slow Start
2 Fast Start (H.245 tunneling)

En el modo Fast Start, se obtiene una ganancia dinmica de
procesamiento en los terminales/gateways y gatekeeper, con mnima
prdida de funcionalidades.

Figura 16.Modelos en H.323

En una llamada H.323 tendremos entonces en juego hasta 4 direcciones
IP diferentes :

1) La direccin IP del terminal/gateway originante
2) La direccin IP del gatekeeper a donde los gateways se registrarn
(H.225 RAS)
3) La direccin IP del Call Agent, dependiente del Gatekeeper para la
sealizacin de llamada (Q.931)
4) La direccin IP del terminal/gateway de destino de intercambio del


flujo RTP

Figura 17.Las direcciones IP puestas en juego

Dependiendo del modelo de llamada, algunas direcciones IP pueden
superponerse.


IETF RFC 3261 Session Initiation Protocol (SIP)

SIP, definido segn RFC 3261, es un protocolo de sealizacin a nivel de
aplicacin para el establecimiento, modificacin y terminacin de
sesiones de tiempo real entre participantes sobre una red IP. SIP puede
soportar cualquier tipo de sesiones simple o multimedia, inclusive
teleconferencia.

SIP soporta 5 facetas del establecimiento y terminacin de
comunicaciones multimedia.

1 User location : Los usuarios pueden moverse a otras locaciones y
acceder a sus aplicaciones de telefona u otras facilidades desde la
locacin remota.

2 User availability : Este paso se refiere a la determinacin de la
disponibilidad de la parte llamada para entablar la comunicacin.

3 User capabilities : En este paso, son determinados el medio y los
parmetros del medio a ser usado.

4 Session setup : Se establecen sesiones punto a punto y
multipartes, con parmetros de sesin acordados.

5 Session management : Este paso incluye transferencia y
terminacin de sesiones, modificacin de los parmetros de la
sesin y la invocacin de servicios.

SIP emplea elementos de diseo desarrollados para protocolos
anteriores. SIP est basado en un modelo transaccional
request/response similar a HTTP. Cada transaccin consiste en una
requisitoria de cliente que invoca un mtodo particular o funcin, en el
servidor y, al menos una respuesta. SIP utiliza la mayora de los campos
de encabezado, reglas de codificacin y cdigos de estado de HTTP. Esto
provee un formato legible basado en texto para mostrar la informacin.
SIP incorpora el uso de SDP (Session Description Protocol), el cual
define el contenido de la sesin utilizando un juego de tipos similar a los
utilizados en MIME (Multipurpose Internet Mail Extensions).

Componentes y protocolos

Un sistema que usa SIP puede ser visto como compuesto por
componentes definidos en dos dimensiones : cliente/servidor y
elementos de red individuales. Los roles de cliente y servidor son


definidos en la RFC 3261 como sigue :

6 Cliente : Un cliente es cualquier elemento de red que enva
requerimientos de SIP y recibe respuestas de SIP. Los clientes
pueden o no recibir interaccin humana. Los User agents y
Proxies son clientes.

7 Servidor : Un servidor es un elemento de red que recibe
requerimientos de SIP para servirlos y enva respuestas a esos
requerimientos. Ejemplos de servidores son los Proxies,
servidores de User agents, servidores de redireccin y
Registrars.

Los elementos individuales de una configuracin estndar de SIP
incluyen los siguientes :

8 User Agent : El user agent reside en cada endstation SIP. Acta en
dos roles :
o User Agent Client (UAC) : realiza requerimientos SIP
o User Agent Server (UAS) : recibe requerimientos SIP y
genera una respuesta que acepta, rechaza o redirecciona un
requerimiento.
9 Redirect Server : El redirect server se utiliza durante el inicio de
una sesin para determinar la direccin del dispositivo de la parte
llamada. El redirect server retorna esta informacin al dispositivo
llamante, indicndole al UAC que contacte una URI (Universal
Resource Identifier) alternativa. Una URI es un identificador
genrico usado para nombrar cualquier recurso de Internet. Las
URL usadas en las direcciones Web es un tipo de URI (ver RFC
2396 para mayores detalles).
10 Proxy Server : El proxy server es una entidad intermediaria que
acta como server y como cliente con el propsito de hacer
requisitorias de parte de otros clientes. Un proxy server juega el
rol primario de enrutamiento, esto es, su funcin es asegurar que
una requisitoria sea enviada a otra entidad ms cercana al usuario
de destino. Los proxies son tambin utilizados para aplicar
polticas (por ejemplo, asegurar que un usuario est habilitado
para realizar llamadas). Un proxy interpreta, y, si es necesario,
reescribe partes especficas de un mensaje de requisitoria antes
de reenviarlo.
11 Registrar : Un registrar en un server que acepta requisitorias
REGISTER y coloca la informacin recibida (la direccin SIP y la
direccin IP asociada del dispositivo que se registr) en aquellas
requisitorias dentro del location service para el dominio que l


maneja.
12 Location service : Un location service es usado por un SIP redirect
proxy server para obtener informacin sobre las posibles
locaciones del lado llamado. Para este propsito, el location
service mantiene una base de datos del mapeo de direcciones
SIP/direcciones IP.

Los servers indicados estn definidos en la RFC 3261 como dispositivos
lgicos. Pueden ser implementados como servidores separados o
pueden estar combinados en una nica aplicacin que reside en un
nico servidor fsico.

Figura 18. Componentes de SIP

SIP corre normalmente sobre UDP por razones de performance y provee


sus propios mecanismos de confiabilidad, pero puede ser montado sobre
TCP. Si se requiere un nivel de confiabilidad superior, SIP puede ser
montado alternativamente sobre TLS (Transport Layer Security
Protocol), brindando seguridad y encriptacin.

Asociado con SIP est SDP, definido por la RFC 2327. SIP es usado para
invitar a uno o ms participantes a una sesin, mientras que el cuerpo
codificado segn SDP del mensaje SIP contiene informacin sobre que
tipo de media utilizarn las partes (por ejemplo audio, video). Despus
de que esta informacin es intercambiada y reconocida, todos los
participantes conocen las direcciones IP de los otros participantes,
capacidades de transmisin disponibles y tipo de media. Luego, la
transmisin de media comienza, utilizando un protocolo de transporte
adecuado (RTP). A todo lo largo de la sesin, los participantes pueden
hacer cambios a los parmetros de la sesin, tales como tipos de media
o altas o bajas de participantes, utilizando mensajes SIP.

Universal Resource Identifier (URI)

Un recurso dentro de una configuracin SIP es identificado por una URI.
Ejemplos de recursos de comunicacin incluyen los siguientes :

1 Un usuario de un servicio on-line
2 Una encarnacin en un telfono multilnea
3 Una casilla de correo en un sistema de mensajera
4 Un nmero de telfono en un servicio de gateway
5 Un grupo (tal como ventas o help-desk) en una organizacin

Las URIs de SIP tienen un formato basado en el formato de direcciones
de mail, llamadas como usuario@dominio. Hay dos esquemas
comunes. Una URI ordinaria de SIP es de la forma :

sip:emoreira@iplan.com.ar

La URI puede tambin incluir una contrasea, nmero de puerto y
parmetros relacionados. Si se requiere transmisin segura, sip: es
reemplazado por sips:. En este ltimo caso, los mensajes de SIP son
transportados sobre TLS.


Sistemas de sealizacin propietarios

Son protocolos vistos en sistemas de tipo corporativo PBXs IP. Los
protocolos propietarios que aparecieron en sistemas enfocados al
servicio de operadores y prestadores ya han desaparecido o migrado a
los estndares.
Ms actualmente ha surgido una nueva ola de protocolos propietarios
para servicios globales alternativos, tal el caso de Skype. La propiedad
del protocolo de Skype va ms all de la simple no interoperatividad,
sino que adems, toda la sealizacin corre encriptada entre los
elementos de red.
Al momento de la burbuja de las empresas punto com, muchos
fabricantes de PBXs TDM se embarcaron al desarrollo de PBXs IP
aprovechando el uso de redes corporativas LAN con capacidad, medida
en ancho de banda, ociosa. En ese entonces, el protocolo de VoIP que
estaba en desarrollo era H.323 que no brindaba funcionalidades para
portar los servicios de las PBX TDM al mundo IP. Con esto surgi la
necesidad de crear protocolos propietarios que permitieran brindar esos
servicios.
Cada fabricante desarroll su propio protocolo y ninguno es
interoperable. As vemos fabricantes como Cisco, Avaya, 3Com, etc.,
cada uno con su propio protocolo.
La solucin de PBX IP normalmente provee 4 elementos bsicos :

1) Call Server, con o sin posibilidad de conectar telfonos analgicos
tradicionales
2) Telfonos IP en diferentes sabores (hardphones, softphones,
manos libres para salas de conferencia, inalmbricos, etc.)
3) Gateway de interconexin a la PSTN con lneas FXO, lneas ISDN
BRI, E1s con sealizacin ISDN PRI MFCR2
4) Interfase de interconexin entre PBXs a la red pblica mediante
protocolo estndar H.323 SIP (IP trunking)

Si bien el stack y la mensajera de estos protocolos son totalmente
propietarios, su concepto de funcionamiento es muy similar a los de los
sistemas de sealizacin estndares.
A medida que avanza la estandarizacin de SIP, fundamentalmente en
materia de servicios, ms y ms fabricantes de PBX IP tienden a utilizar
SIP como protocolo interno y externo.


Unidad 3
Interconexin entre redes de telefona

Interconexin de redes de Voz sobre paquetes con las redes
tradicionales de telefona

El servicio de telefona es un servicio universal que debe asegurar la
interconexin de todos contra todos. Cada operador que brinde servicio
de telefona podr optar por la solucin tecnolgica que mejor se adecue
a su modo de encarar el negocio.
Cuando dos operadores deben interconectar sus redes para asegurar el
servicio de telefona extremo a extremo, deben ponerse de acuerdo de
antemano en la forma en que se interconectarn.
La autoridad de aplicacin podr recomendar un estndar de
interconexin que se aplicar en caso de que las partes no se pongan de
acuerdo en el modo de realizar la interconexin. En la Argentina, la
autoridad de aplicacin, la SECOM (Secretara de Comunicaciones),
mediante su organismo tcnico, la CNC (Comisin Nacional de
Comunicaciones), define el RNI (Reglamento Nacional de
Interconexin), el cual se remite al PFSN (Plan Fundamental de
Sealizacin Nacional) como mtodo para interconectar redes entre
operadores de telefona.
Sin embargo, los acuerdos de interconexin, por ser acuerdos entre
partes, pueden optar por diferentes soluciones tecnolgicas de
interconexin.

La interconexin entre operadores de servicio de telefona puede darse
en los casos siguientes:

1) Entre operadores que utilizan redes TDM
2) Entre un operador que utiliza una red TDM con un operador
que utiliza una red VoIP
3) Entre operadores que utilizan redes VoIP

El caso 1) est fuera del alcance de este curso.
Los casos 2) y 3) se describirn a continuacin.

Entre los operadores que se interconectan debe establecerse quien es el
responsable de la adaptacin, en otras palabras, cual de los operadores
pone el gateway. En funcin de esto, la red del otro operador ser vista
como parte de la misma red.


Caso 2)
Entre un operador que utiliza una red TDM con un operador que
utiliza una red VoIP (VoIP <=> TDM)

Para realizar la interconexin deben utilizarse gateways. Un gateway,
como vimos, es un elemento de red que sirve de conversor de
protocolos y media entre una red por un lado y la otra red por el otro.
Normalmente los gateways son equipos que hablan protocolo de VoIP
del lado IP y protocolo TDM del lado PSTN.
Como tal, el gateway realiza dos funciones bsicas :



Como ya dijimos, un gateway tiene dos caras. Una que mira hacia la red
de VoIP y otra que mira a la red TDM. Cada red tiene su propio sistema
de sealizacin de llamada.

Visto desde el lado VoIP, el gateway se presenta como un Endpoint ms
dentro de la zona como un User Agent, el cual origina y recibe
llamadas.
Visto desde el lado TDM, el gateway se presenta como una central
adyacente, PBX o telfono, el cual origina y recibe llamadas.

Como tal, un gateway debe cumplir todas las funciones de un Endpoint
del lado VoIP y todas las funciones de una central adyacente del lado
TDM.

Cada sistema de sealizacin est preparado para, en mayor o menor
medida, con mejores o peores capacidades o complejidades, resolver
llamadas. El gateway recibe una llamada de un lado, traduce la
sealizacin del sistema que recibe al sistema que debe enviar y enva
la llamada hacia el otro lado.
Esta traduccin de sealizacin debiera ser lo ms transparente posible.
El grado de transparencia que pueda brindar un gateway depender de
los siguientes factores :

a) del protocolo utilizado en el lado VoIP
b) del protocolo utilizado en el lado TDM
c) de las funcionalidades soportadas por el controlador del gateway


Cuando la traduccin debe hacerse desde un protocolo ms rico a otro
ms pobre (por ejemplo una llamada TDM VoIP donde el protocolo de
TDM es CCS#7 y el de VoIP es H.323), la traduccin debe descartar
informacin que viene en el protocolo ms rico, ya que no existen los
valores a completar en el protocolo ms pobre.

Figura 19.Traduccin de protocolos de TDM => VoIP

Cuando la traduccin debe hacerse desde un protocolo ms pobre a otro
ms rico (por ejemplo una llamada VoIP TDM donde el protocolo de
VoIP es H.323 y el de TDM es CCS#7), la traduccin debe completar
informacin con valores por defecto decretados que es necesario
enviar en el protocolo ms rico.

Figura 20.Traduccin de protocolos de VoIP => TDM

Los valores faltantes a completar o los valores a descartar deben ser
compensados por el controlador del gateway mediante mecanismos
inteligentes (por ejemplo traducciones del DNIS en funcin de la
Categora del llamante, definicin de la Categora en funcin del ANI del
llamante, etc.)

Para compensar estas falencias, la ITU-T defini, en conjunto con los


proveedores de tecnologa, un mtodo de transparencia de sealizacin
TDM sobre redes VoIP. El mtodo, definido en la Recomendacin ITU-T
Q.1980, se denomina NSS (Narrowband Signalling Syntax) y consiste,
bsicamente, en el encapsulado de la sealizacin TDM dentro del
protocolo de VoIP.

Este mtodo es requerido, por ejemplo, en los casos donde la red de
transporte de Larga Distancia es reemplazada por una red de VoIP. Esta
solucin se denomina comnmente Class 4 replacement.

Figura 21.Class 4 replacement

Los softswitches intermedios en la red de VoIP podrn dejar pasar de
largo la sealizacin TDM encapsulada sin tocarla leerla y tomar
decisiones de ruteo inteligentes en funcin de ella, modificarla de
requerirse.


El gateway debe realizar la transcodificacin del canal de audio del
CODEC utilizado en la red de VoIP a la codificacin PCM presente en las
tramas E1s de interconexin a audio analgico en banda en el caso de
gateways con lneas analgicas del lado TDM y viceversa.

El gateway deber proveer tambin mecanismos de deteccin y pasaje
de comunicaciones de fax y, en menor medida, de modem. Estos
mecanismos se denominan fax/modem relay fax/modem passthrough.
El mecanismo de fax relay/fax store&forward se encuentra normado por
las Recomendaciones ITU-T T.38 y T.37 respectivamente, que son de
aplicacin universal en las redes de VoIP independiente del sistema de


sealizacin de llamada, ya que la negociacin de fax o modem se
realiza en el estado de respuesta de la llamada.
El mecanismo de modem relay no se encuentra an normado. Los
mecanismos disponibles actualmente son aplicaciones propietarias (hay
un intento de normarlo en la RFC 2833).

Adems, el gateway deber proveer tambin mecanismos de deteccin
y pasaje de tonos DTMF, utilizados en banda para acciones interactivas
con IVRs. Este mecanismo se denomina DTMF Relay (RFC 2833),
existiendo dos mtodos de operacin: en banda y por sealizacin. La
concepcin bsica de funcionamiento del DTMF Relay es detectar el
dgito en origen y sealizar por IP el dgito marcado como dgito y no
como tono de voz. Esto es especialmente requerido en caso de utilizar
CODECs de alta complejidad y bajo ancho de banda.

SIGTRAN

Las redes de Sealizacin CCS7 de la PSTN han sido diseadas para la
sealizacin de llamadas de voz y sus servicios relativos. Las redes de
CCS7 soportan sealizacin de llamadas orientadas a conexin y no
orientadas a conexin. Con el advenimiento del servicio se SMS (Short
Message Service) las redes de CCS7 se han visto sobreutilizadas a su
diseo y funcin original, requiriendo da a da incrementos de su
capacidad. Las redes IP gerenciadas ofrecen un sustrato de transporte
adecuado con anchos de banda disponibles para llevar las transacciones
de CCS7.
Los protocolos disponibles de transporte TCP y UDP mostraron no ser los
adecuados para el transporte de mensajera de CCS7, requirindose el
diseo de un nuevo stack de protocolo adecuado para este fin.
As nace el protocolo Stream Control Transmission Protocol SCTP [RFC
2960] que cubre las necesidades estrictas de secuenciamiento,
temporizaciones, etc de CCS7 definidas por el ITU-T, sobre una red IP.

Figura 22


Las funcionalidades de SIGTRAN son utilizadas en la implementacin de
STPs (Signaling Transfer Point) nativos en IP y para implementar
Gateways de interconexin con la PSTN que soportan sealizacin CCS7.
Los modelos usuales de GWs a la PSTN con soporte de CCS7 estn
normalmente constituidos por tres unidades lgicas :

SGW : Signaling Gateway
MG
W
: Media Gateway
MGC : Media Gateway Controller

SGW : Signaling Gateway

Convierte el link de sealizacin TDM (64 kbps) mediante la terminacin
de una E1, extraccin del canal de sealizacin de una E1 o V.35,
envindolo encapsulado en SIGTRAN al MGC.

MGW : Media Gateway

Termina los canales vocales (Bearer Channels) PCM mediante la
terminacin de E1s (normalmente varias E1s) transcodificando los
canales de audio a flujos RTP en la red IP.

MGC : Media Gateway Controller

Recibe los canales de sealizacin encapsulados en SIGTRAN desde el
SGW, realiza la funcin de alocacin (conversin bidireccional de CIC
<=> E1 + Time Slot fsico). Enva/recibe la sealizacin de llamada al
MGW. Inicia/termina la llamada del lado VoIP.

Las unidades lgicas indicadas pueden estar implementadas en
dispositivos fsicos separados o integrados en cualquier combinacin.

Las implementaciones disponibles permiten la interconexin con la red
de CCS7 en los modos Asociado y Cuasi-Asociado.


Figura 23. Topologa lgica de interconexin con la PSTN en CCS7
Modo Asociado

Figura 24.Topologa lgica de interconexin con la PSTN en CCS7
Modo Cuasi-Asociado


Es comn ver implementaciones donde el MGC est integrado al
softswitch de la red VoIP, concentrando la inteligencia e interfases de
OAM de la red VoIP.

Caso 3)
Entre operadores que utilizan redes VoIP (VoIP <=> VoIP)

Inicialmente la interconexin entre operadores que utilizaban redes de
VoIP se plante como la unin de dos segmentos de red mediante
Firewalls que proveyeran funciones de NAT (Network Address
Translation [RFC 1631]) y funciones de seguridad. Inicialmente exista
un nico protocolo de VoIP extensamente utilizado, H.323.
H.323 prob ser un protocolo duro para atravesar Firewalls y soportar
NAT, principalmente debido a que dentro de la mensajera se informan
las direcciones IP de los miembros de la llamada. El NAT debe cambiar
las direcciones IP dentro de la mensajera, por lo que se debe realizar
una inspeccin profunda de los paquetes IP. Normalmente, los Firewalls
que realizan NAT que permiten el paso de H.323 se denominan H.323
aware.
Figura 25.Interconexin entre operadores de VoIP concepcin original

Adicionalmente, cuando dos operadores se interconectan, son
necesarias realizar traslaciones de nmeros, cambios de ANIs, funciones
de seguridad, mediciones de volumen y crdito reciproco.

Ms actualmente, se plantearon necesidades de translacin de sistemas
de sealizacin, donde los dos operadores que se interconectan utilizan
redes de VoIP pero diferentes sistemas de sealizacin, tpicamente
operadores que utilizan H.323 que se deben interconectar con
operadores que utilizan SIP. Todos estos requerimientos no eran


posibles de cumplir con un Firewall.

Surgieron las soluciones tipo Back to Back con gateways enfrentados
con E1s, tpicamente con sealizacin ISDN PRI. Estas soluciones, si
bien vlidas, presentan varios inconvenientes insalvables :

1) Hay doble salto VoIP, por lo que pueden presentarse problemas en
llamadas de fax y pasaje de dgitos DTMF.
2) Hay una doble Codificacin/Decodificacin, por lo que puede verse
afectada la calidad de voz.
3) Hay una doble Paquetizacin/Depaquetizacin, por lo que se
incrementa el delay.

Figura 26.Interconexin entre operadores IP con esquema B2B

Basado en este tipo de soluciones, aparecen los llamados SBC (Session
Border Controller) que son bsicamente gateways IP IP, donde ambos
lados son VoIP.
Los SBC se presentan a cada lado de red como un Endpoint/User Agent
en su respectiva red. Podrn ser H.323 a SIP, H.323 a H.323 SIP a
SIP.
Normalmente se definen un lado inbound y un lado outbound siendo
el inbound el lado que mira a la red propia y el outbound el que mira a
la red de otro operador.

Usualmente los SBC se utilizan como portal de una red privada a
Internet, permitiendo interconectar una red privada de VoIP con carriers
de Larga Distancia que utilizan Internet como red de transporte, en
forma controlada y segura.


Figura 27.Interconexin entre operadores IP con esquema SBC

Los SBC, adems de realizar la traslacin del sistema de sealizacin del
inbound al del outbound y viceversa, realizan funciones de ruteo
inteligentes (por ejemplo Least Cost Routing LCR), control de calidad
del carrier (medido en ASR Answer to Seizure Ratio, ACD Average
Call Duration, Jitter y Packet Loss), traslaciones de numeracin (ANI y
DNIS), control de volumen de llamadas (suma de minutos llamadas
concurrentes), balance de crdito (crdito positivo postpago balance
de minutos entregados mutuamente), etc.

Los SBC pueden utilizarse solo como traslador de sealizacin, donde el
flujo RTP no atravieza el SBC, como portal nico donde tanto la
sealizacin como el flujo RTP pasan por l (Topology Hiding). En el
primer caso, se debe proveer adicionalmente un Firewall para el flujo
RTP. En el segundo caso permiten el paso transparente o no del flujo de
audio RTP (RTP Proxy). Oficiar de RTP Proxy permite adicionalmente al
SBC medir y controlar la calidad de audio por mediciones indirectas de
calidad mediante los parmetros de RTCP.
Los servicios de DTMF/fax/modem relay inband no son alterados al
atravesar el SBC (el SBC oficia solo como proxy para el flujo RTP) y son
negociados entre los endpoints/user agents de origen y destino
independientemente del SBC que est en medio.

Pueden plantearse soluciones de SBC que realicen la transcodificacin
del CODEC utilizado por la llamada. Tpicamente una llamada que se
cursa por Internet utiliza un CODEC de alta complejidad y bajo ancho de


banda (G.729 G.723), mientras que las llamadas que se cursan en una
red de VoIP privada utilizan CODECs de baja complejidad y alto ancho
de banda como G.711 debido a que normalmente hay altas
disponibilidades de ancho de banda. Para realizar la transcodificacin el
SBC debe oficiar de RTP proxy.
En estos casos, el SBC deber contar con bancos de DSPs para realizar
la transcodificacin por HW (la transcodificacin por SW, realizada por la
CPU del equipo, insume mucha capacidad de procesamiento).


Unidad 4
Calidad de servicio en redes de telefona sobre paquetes

QoS en redes de voz sobre IP - su influencia en la topologa de
red

La calidad de servicio es un concepto global que debe ser enfocado por el
prestador de servicio.
Afectan a la calidad de servicio en forma global la calidad de voz, la
calidad del establecimiento/resolucin de llamadas (disponibilidad y
confiabilidad de la red, tiempo y calidad del call setup) y servicios de
soporte (facturacin, customer care, provissioning, asistencia tcnica,
informacin, reparaciones, etc.).

Figura 28.Grandes grupos de calidad de servicio

La calidad de la red de transporte IP es uno de los pilares fundamentales
que hacen a la calidad de servicio en una red de VoIP, ya que afectan a
la calidad de la voz y a la calidad del Call Setup.
En funcin de la capacidad de controlar la calidad de servicio de la red de
transporte IP tendremos capacidad de controlar la calidad de voz y la
calidad del Call Setup (la calidad del Call Setup tambin est


fuertemente influenciada por la robustez de las plataformas de
conmutacin involucradas).

Una llamada telefnica comienza cuando el originante descuelga el
telfono y termina cuando cualquiera de las dos partes cuelga. La
experiencia del usuario toma en cuenta todo lo que pasa entremedio,
esto es la calidad del Call Setup (Dial Tone, PDD - Post Dial Delay, RBT -
Ring Back Tone, xito en comunicarse, disponibilidad del servicio) y la
calidad de voz.

Cada uno de estos dos pilares (calidad del Call Setup y calidad de la voz)
son dos mundos que se abordan y se miden de maneras diferentes.
Mientras que la calidad del Call Setup puede ser medida directa y
permanentemente ex-post (mediciones de ASR - Answer to Seizure
Ratio, ACD Average Call Duration, PDD, etc, como integracin de un
cmulo finito de llamadas cursadas), la medicin de la calidad de voz
requiere de mediciones directas off-line proactivas o mediciones
indirectas mediante estadsticas de parmetros de RTCP, packet loss,
OWA, etc.


Calidad de Voz

La calidad de voz es uno de los aspectos ms importantes dentro de lo
que es la calidad de servicio (QoS).
La calidad de voz se manifiesta, en esencia en los odos de la persona
que mantiene la comunicacin.
A pesar de que hay docenas de mtricas que caracterizan las seales
elctricas utilizadas en la PSTN para transportar voz, ninguna de estas
asegura lo mismo en las redes de nueva generacin. Hay cuatro
parmetros fundamentales que caracterizan la calidad de voz: claridad,
retardo, eco e interrupciones.

1 Claridad: fidelidad de la seal de voz, ausencia de distorsin e
inteligibilidad. Inciden en la claridad el ruido superpuesto, fritura,
bajo volumen (el que escucha reconoce quien es el que habla ?)
2 Retardo extremo a extremo: el tiempo que toma la seal de voz
para viajar desde el extremo que habla hasta el que escucha.
3 Eco: es el sonido de la voz de la persona que habla y que retorna
hacia ella.
4 Interrupciones: son los momentos en que se producen silencios por
perdida del audio enviado.

Figura 29.

Las relaciones entre claridad, el retardo y el eco pueden ser un tanto
complejas como se muestra en la figura. Imaginando la calidad de voz
como un punto en el grfico, se puede ver que la calidad mejora cuando
ese punto est ms cerca de la interseccin de los tres ejes. En otras


palabras, cuando la distancia entre el punto y la interseccin aumenta, la
calidad disminuye.

Otras observaciones interesantes incluyen :

1 El modo en que se percibe a uno solo de los parmetros
afecta a toda la calidad de voz.
Una de las principales razones por la cual la claridad, el retardo y el eco
se toman como grupo es que muchos usuarios reportarn una calidad de
voz inaceptable aunque solo uno de los parmetros sea inaceptable. Por
ejemplo, los usuarios rara vez distinguen entre distorsin y algn eco
molesto, y simplemente reportan calidad de llamada inaceptable.

2 La claridad y el retardo son parmetros independientes de
la calidad de voz.
La distorsin y la fidelidad son independientes del retardo extremo a
extremo, de modo que puede haber un sonido claro con un retardo alto,
de todas maneras la claridad debe ser razonablemente buena y el
retardo razonablemente bajo. El retardo afecta fundamentalmente a la
interactividad de una conversacin telefnica.

3 El eco es independiente del retardo y el eco afecta a la
claridad.
El eco es solo perceptible cuando el retardo de la red est por encima de
cierto umbral. Dicho en otras palabras, el eco que llega desde el punto
remoto no ser audible a menos que haya un retardo tal que lo haga
sonar separado de la frase dicha originalmente. De la misma manera la
claridad que se percibe a menudo est afectada negativamente por el
eco audible.

Probando la Calidad de Voz

Tradicionalmente las tcnicas de prueba de calidad de voz asumen que
los circuitos telefnicos son esencialmente lineales, pero en el caso de
VoIP se utilizan CODECs (como G.729 y G.723) que no permiten asumir
linealidad de circuitos.

Parmetros de performance de una red IP y sus efectos sobre la
calidad de voz

La red de transporte IP se caracterizar por sus parmetros
caractersticos de performance. Los parmetros caractersticos sern :


Valores Cuantitativos de performance de Red :
1 Retardo de propagacin (Propagation Delay - Round Trip Delay)
2 Jitter (Variacin del retardo a lo largo del tiempo)
3 Prdida de paquetes (relativo a la prdida en si y no al descarte
por arribo tardo)
4 Disponibilidad de ancho de banda

En funcin de los valores que adopten estos parmetros caractersticos
de performance, obtendremos un grado de calidad de voz que
caracterizar a la red de VoIP.
As, cada uno de estos parmetros de performance influyen en los
valores perceptuales caractersticos de la voz : claridad, retardo, eco e
interrupciones.

Valores perceptuales de la Calidad de Voz :

1 Claridad : influenciada por el jitter, la prdida de paquetes y el
CODEC utilizado
2 Retardo : influenciado por el delay y el jitter
3 Eco : influenciado por el delay y el jitter
4 Interrupciones : influenciado por el delay, el jitter y la prdida de
paquetes

Los valores cuantitativos de performance de la red de transporte IP
tendrn valores lmites superiores, superados los cuales, la red de
transporte deja de ser apta para el servicio de VoIP.

Se consideran como valores lmites los siguientes :

RTD : menor a 200 milisegundos
Jitter : menor a 3 paquetes de RTP (60 milisegundos)
Prdida de paquetes : menor al 1 %

Mediante el Modelo E (ver ms adelante) podr inferirse la calificacin
en unidades MOS de la calidad de voz que nos dar la red de VoIP, en
funcin de los valores medidos de performance de la red IP, sumado a
los detalles de la implementacin.
Sin entrar en complejos clculos y mediciones, los parmetros de
performance de la red IP a priori nos darn una idea de si la red ser
apta para montar un servicio de VoIP.
Cada valor de performance incide sobre la calidad de voz y la
concurrencia de los valores que adopten inciden combinadamente en el
resultado final.


La prdida de paquetes puede presentarse de dos formas distintas :
Prdida Uniforme Prdida en Rfagas.
La Prdida Uniforme incide a todo lo largo de la conversacin
distorsionando el audio que le llega al que escucha.
La Prdida en Rfagas afecta porciones de la conversacin haciendo que
el audio sea ininteligible cuando se produce la prdida del tren de
paquetes.
La Prdida Uniforme es la que ms afecta a la experiencia del usuario ya
que hace desagradable toda la conversacin.

La forma aproximada en que la prdida de paquetes uniforme (resto de
valores constante) afecta la calidad medida en unidades de MOS, para el
CODEC G.711 es :

Prdida de
paquetes [%]
MOS esperado
0 4,1
5 2,9
10 2,4
15 2,0
20 1,7

Figura 30

El ancho de banda disponible nos dar una indicacin del volumen de
trfico de llamadas que podrn cursarse, considerando el CODEC que se
utilizar. Cuando existen restricciones de ancho de banda disponible
para el pasaje de los flujos RTP, es esperable observar un aumento de la
prdida de paquetes, del jitter y del RTD, degradndose la calidad de la
voz de todas las llamadas en curso y la experiencia de los usuarios.

Es importante considerar, que, a diferencia de las redes TDM, la
congestin de los enlaces de datos IP que transportan llamadas en VoIP,
no se traduce en el concepto de congestin de las redes TDM, donde
nuevas llamadas son rechazadas por falta de canales disponibles, pero
no hay degradacin de las llamadas en curso. La congestin de enlaces
de datos IP produce una degradacin en la calidad de servicio (calidad
de voz) de todas las llamadas en curso. Los sistemas de sealizacin
VoIP proveen mtodos de restriccin de aceptacin de nuevas llamadas
en funcin del uso de ancho de banda corriente por las llamadas que
estn en curso, sobre la base del conocimiento del ancho de banda
disponible (CAC Call Admision Control).


Medicin de calidad

Debido a la naturaleza subjetiva de las pruebas de calidad de voz, uno
de los mtodos utilizados durante aos fue el Mean Opinion Score (MOS)
en la Recomendacin P.800 de la ITU-T cuya gran desventaja es el
tiempo y esfuerzo necesario.

Debido a la complejidad de la implementacin del mtodo MOS, surgi la
necesidad de implementar mtodos de medicin de la calidad de voz que
sean objetivos y que se aproximen a la experiencia humana.

Existen dos tipos de mediciones objetivas de calidad de voz :

1 El Modelo Perceptual
2 El Modelo E.

Modelo Perceptual

Uno de los primeros modelos perceptuales estandarizados por el ITU-T
fue el PSQM (Perceptual Speech Quality Measurement) definido por la
recomendacin P.861. El algoritmo de PSQM provee un mtodo mediante
el cual la conversacin dentro de un ancho de banda de voz de 300 a
3400 Hz puede medirse objetivamente en distorsin, efectos del ruido y
fidelidad de la percepcin.

Para hacerlo, PSQM toma una muestra de voz limpia y la compara con la
versin ms o menos distorsionada teniendo en cuenta lo que es
perceptivamente importante. PSQM provee un puntaje relativo que indica
cuan diferente es la seal distorsionada respecto a la original desde la
perspectiva del odo humano.

Una versin mejorada de PSQM y conocida como PSQM+, se desarroll
para correlacionar los puntajes MOS en presencia de fallas de red (como
por ejemplo prdidas de paquetes).

Los puntajes de PSQM+ son esencialmente una medida de distorsin. Un
0 indica sin distorsin o claridad perfecta (la seal recibida es igual a la
seal enviada), mientras que un puntaje alto representa un alto grado de
distorsin o degradacin de la claridad.

La escala nominal para PSQM+ es la siguiente:


0 2.5 Calidad de voz de la PSTN
2.5 4.5 Aceptable pero perceptiblemente
degradada
Arriba de 4.5 Inaceptable

Los valores superiores a 10 no son comunes.

Posteriormente apareci el modelo PESQ (Perceptual Evaluation of
Speech Quality), estandarizado por el ITU-T bajo recomendacin P.862,
haciendo obsoleto al modelo PSQM+.

Modelo E

El ITU-T ha desarrollado otra clase de medicin objetiva, conocida como
el Modelo E, que ha sido estandarizado bajo recomendacin G.107. El
Modelo E es una herramienta para predecir como calificara un usuario
medio la calidad de voz de una llamada telefnica con parmetros
caractersticos de transmisin conocidos. Estima la satisfaccin del
usuario de una conversacin telefnica desde el punto de vista del
oyente.
El Modelo E calcula el factor de calificacin de transmisin R, utilizando
los factores de deterioro de red, que fueran obtenidos despus de un
conjunto extensivo de experimentos subjetivos. Los factores de deterioro
tpicos usados en redes VoIP son los CODECs, retardo y prdida de
paquetes. Despus de calcular el valor R basado en los factores de
deterioro, el valor R es convertido a un resultado MOS.
A partir de que el Modelo E est basado en la medicin de deterioros, es
apropiado para el anlisis de las causas de raz en trminos de factores
de deterioro, as como tambin a segmentos de red y puede ser
incorporado dentro de los sistemas de gerenciamiento de Red. El Modelo
E tambin es escalable, debido a que no requiere de las muestras de voz
entre varios pares de nodos de la red para estimar la calidad de voz.
El Modelo E consiste de varios modelos que relacionan parmetros
especficos de deterioro y sus interacciones para la performance extremo
a extremo.
La performance total extremo a extremo, considerando todos los
factores, es estimada usando el mtodo del Factor de Deterioro. La
ecuacin para obtener el factor de calificacin de transmisin R es :

R = R
0
I
s
I
d
I
e
+ A

Donde :


R
0
: la relacin seal a ruido bsica basada en la calificacin de
loudness del emisor y receptor y el ruido del circuito y ambiente.
I
s
: la suma de los deterioros de transmisin de voz en tiempo real o
simultneos, por ejemplo niveles de loudness, sidetone y distorsin
de cuantificacin PCM.
I
d
: la suma de los deterioros de retardo relativos a la seal vocal, por
ejemplo eco local, eco remoto y retardo absoluto.
I
e
: el factor de deterioro del equipamiento para equipamiento especial,
por ejemplo CODEC de bajo bit rate (determinado subjetivamente
para cada CODEC y para cada % de prdida de paquetes y
documentado en el Apndice I de la recomendacin ITU-T G.113).
A : el factor de ventaja suma al total y mejora el valor de R para
nuevos servicios.

Asumiendo que el eco est apropiadamente controlado por los
canceladores de eco, veamos un ejemplo de los deterioros del Modelo E,
en trminos de retardo, CODEC y prdida de paquetes.

La curva de la figura traza el factor de calificacin de transmisin R
versus el retardo en un sentido para la conexin de referencia. La escala
de la derecha del diagrama incluye la escala de Satisfaccin del usuario
para referencia. Esta curva considera solo variable el retardo con el resto
de los parmetros fijos y de valores admisibles.

Basados en esta curva, si el retardo es el nico deterioro de la red VoIP,
una calificacin de muy satisfecho requiere un retardo en un sentido
menor a 140 milisegundos.


Figura 31.

Valores de I
e
para varios CODECs (la lista completa puede buscarse en la
recomendacin ITU-T G.113).

CODEC Tipo de CODEC Bit Rate [kbps] Valor de I
e

G.711 PCM 64 0
G.726 ADPCM 40 2
32 7
24 25
G.728 LD-CELP 16 7
G.729-A + VAD CS-ACELP 8 11
GSM-Full Rate RPE-LTP 13 20
GSM-Half Rate VCELP 5,6 23
GSM-EFR ACELP 12,2 5
G.723.1 MP-MLQ 5,3 19
G.723.1 MP-MLQ 6,3 15

El Modelo E permite planificar una red de VoIP o predecir el impacto de
cambios que se pudieran realizar.


Mediciones de Retardo

El retardo no afecta al sonido de la conversacin de voz pero si al ritmo y
a la sensacin que se tiene de la misma.
Por ejemplo, alguien que habla puede repetir sus dichos cuando no
recibe una respuesta esperada a tiempo, que colisiona con la respuesta
demorada del extremo distante, resultante en doubletalk.
La mayora de los usuarios no notarn demoras por debajo de los 100
mseg. Los usuarios notarn una vacilacin dbil en la respuesta de su
asociado cuando el retardo est dentro de los 100 a 300 mseg. Esta
vacilacin puede afectar como cada escucha percibe el humor de la
conversacin.
Por encima de los 300 mseg, el retardo es obvio. Los usuarios comienzan
a retrazarse para prevenir interrupciones, y la calidad de la conversacin
la hace casi imposible (Recomendacin ITU-T G.114)

Hay dos formas de medir el retardo en un ambiente de VoP, el PING
acstico y el mtodo llamado MLS Normalized Cross Correlation. Ambos
deben asegurar que la medida de retardo sea consistente debido a la
dinmica de las redes de datos.

5 PING Acstico: Como su nombre lo indica, es la transmisin de
audio y se mide el tiempo que toma en viajar desde un extremo al
otro. El PING acstico debe acompaarse de otros mtodos para
asegurar consistencia.
6 MLS Normalized Cross Correlation: Este mtodo usa una seal de
prueba que se asemeja al ruido pero que a diferencia de ste, su
patrn es predecible, repetible y permite los clculos de retardo.

Los patrones estndares posibles a utilizar para medicin de retardo son:

1 Recomendacin ITU-T G.114 (150 ms)
2 Otros patrones de redes tales como la PSTN
3 Resultados de pruebas subjetivas para determinar que es lo
aceptable
4 Objetivos de otros carriers u operadores (ej. 125 ms)

Mediciones de Eco

La caracterizacin del eco mayormente involucra la medicin de los
niveles de eco y el tiempo que ste toma para retornar hacia la persona
que habla.


Determinacin del eco aceptable

La recomendacin G.131 de la ITU-T describe la relacin entre la
intensidad (loudness) del eco de la persona que habla y su retardo y
como estos dos parmetros se combinan para impactar negativamente
en la calidad de la conversacin.

La intensidad se mide por un parmetro llamado TELR (Talker Echo
Loudness Rating) que es la diferencia el dB en el nivel de seal entre la
seal de voz de origen y el eco recibido. De modo que lo deseable es un
alto TELR y un bajo retardo de transmisin.

Determinado el retardo de transmisin en un sentido, se puede conocer
que valor de TELR se necesita para caer dentro del rango aceptable. Este
valor de TELR es el que se utilizar para correr la prueba de eco en
instrumentos tipo VQT (Voice Quality Tester).


Calidad del Call Setup

La calidad del Call Setup se refiere a la confiabilidad de la red y los
rganos de conmutacin que la componen para poder establecer y
disolver llamadas.

El usuario de una red de telefona acepta como razonable un valor de
ASR del orden del 65 ~ 75 %. El 35 ~ 25 % restante de intentos de
llamada que resultaron infructuosos deben ser atribuibles a razones
atendibles, por ejemplo abonado ocupado no contesta (la
implementacin de servicios de completacin de llamada, tipo Voice Mail,
tienden a aumentar el ASR y por lo tanto la cantidad de llamadas
fructferas facturables).
Adems, las llamadas se deben disolver cuando los usuarios cortan
(salvo en los casos de lmite de tiempo de comunicacin control de
crdito disponible). Si las llamadas se interrumpen por problemas de
sealizacin (incorrecta inicializacin de temporizadores, eventos
faltantes, etc.) el usuario considerar inadecuado el funcionamiento de la
red de telefona. Las mediciones de ACD dan un indicador del
funcionamiento de la red. Mediciones de ACD de escasos segundos
indican redes donde las llamadas se cortan redes donde la calidad de
audio es criticable.

El sistema de sealizacin utilizado en la red de VoIP debe ser lo
suficientemente robusto para asegurar que la totalidad de intentos de
llamada infructuosos se deban a situaciones externas o de usuario y no a
problemas de red y que las llamadas sean disueltas cuando los usuarios
deciden (directa o indirectamente).

Gran parte de las funciones (protocolos) de los sistemas de sealizacin
de VoIP corren sobre UDP. Otras partes corren sobre TCP. Si bien los
protocolos cuentan con seguridades de capa superior y temporizaciones,
la prdida de paquetes en la red IP impacta directamente en la calidad
del Call Setup.
Normalmente el Call Setup de una llamada insume muy bajo ancho de
banda. La cantidad de paquetes IP necesarios para completar todo el Call
Setup de una llamada es del orden de pocas decenas.

Tanto la calidad de Voz, como la calidad del Call Setup se ven
influenciados directamente por la calidad de la red de transporte.

Como ya se ha dicho anteriormente, una comunicacin telefnica es una
experiencia extremo a extremo. Cada operador telefnico tiene solo un
segmento de toda la cadena de redes y rganos de conmutacin por


donde pasa la llamada. Si bien un operador no puede ser responsable
por toda la cadena, deber asegurar la calidad de servicio en el eslabn
que le corresponde de modo que la suma de eslabones con calidad
presentar al usuario una experiencia extremo a extremo de calidad.

A diferencia de las redes TDM, las redes de VoIP brindan mayor
flexibilidad de poder utilizar infraestructuras de red de terceros pblica,
como Internet, para transporte.
Dependiendo del grado de control que el operador tenga sobre la red de
transporte IP, podr aplicar polticas de calidad de servicio que aseguren
un grado de servicio adecuado en el eslabn que le corresponde.


Recursos para brindar QoS. RSVP, MPLS, BW, etc.

En las redes IP se maneja comnmente el concepto de calidad a fuerza
bruta, que bsicamente se refiere a manejar enlaces con ancho de
banda ocioso. El ancho de banda ha pasado de ser un recurso
sumamente oneroso a valores ms accesibles, por lo que, si bien no es
una opcin inteligente desde el punto de vista tecnolgico, se presenta
como un recurso vlido.

Se debe remarcar que el correcto dimensionamiento del ancho de banda
requerido en funcin del trfico esperable, no solo de VoIP, sino del
trfico sumado de todas las aplicaciones, es el punto de partida del
diseo de una red. De poco sirve aplicar recursos para asegurar la
calidad de voz en la red si el ancho de banda del enlace por donde pasan
los flujos RTP est subdimensionado.

Las redes IP brindan actualmente herramientas tecnolgicas para
asegurar el cumplimiento de determinados estndares de calidad de
servicio.

Dentro de las herramientas de QoS disponibles podemos citar :

1 Fraccionamiento e Interleaving
2 Marcado de paquetes de flujo de voz y utilizacin de colas
preferenciales para tratamiento de paquetes marcados
3 Reserva de ancho de banda para flujos de voz
4 RSVP (Resource ReSerVation Protocol) IETF RFC 2205
5 MPLS (MultiProtocol Label Switching) IETF RFC 3031 y
anexas

Fraccionamiento e Interleaving
Este mtodo es usado en enlaces de ancho de banda limitado
compartidos con otras aplicaciones. El principio de funcionamiento es
marcar los paquetes de RTP con IP Precedence, los paquetes de MTU alto
sern fraccionados para intercalar paquetes de voz marcados.

Marcado de paquetes de flujo de voz y utilizacin de colas
preferenciales para tratamiento de paquetes marcados
Los paquetes de RTP son marcados con IP Precedence. Las colas de los
routers despacharn los paquetes marcados prioritariamente.


Reserva de ancho de banda para flujos de voz
En los enlaces donde existe trfico RTP y dems trfico de otras
aplicaciones, se realiza una reserva de ancho de banda para el volumen
de trfico esperado de VoIP.

RSVP (Resource ReSerVation Protocol) IETF RFC 2205
Este protocolo permite la reserva de ancho de banda por llamada segn
el camino recorrido por el primer paquete de voz. La reserva de ancho de
banda es bidireccional, pero el flujo de paquetes de retorno debe seguir
el mismo path que el flujo de paquetes de ida.

MPLS (MultiProtocol Label Switching) IETF RFC 3031 y anexas
Mediante MPLS pueden reservarse tneles para tipos de trfico en
enlaces compartidos.


APENDICE: Articulos sobre Comunicaciones unificadas + NGN (Contec
Consulting).









Subsistema Multimedia IP
Subsistema Multimedia IP (IMS) (IP Multimedia Subsystem) es un conjunto de especificaciones
que describen la arquitectura de las redes de siguiente generacin (Next Generation Network, NGN),
para soportar telefona y servicios multimedia a travs de IP. Ms concretamente, IMS define un marco
de trabajo y arquitectura base para trfico de voz, datos, video, servicios e imgenes conjuntamente a
travs de infraestructura basada en el ruteo de paquetes a travs de direcciones IP. Esto permite
incorporar en una red todo tipo de servicios de voz, multimedia y datos en una plataforma accesible a
travs de cualquier medio con conexin a internet, ya sea fija, o mvil. Slo requiere que los equipos
utilicen el protocolo de sesin SIP (Session Initation Protocol) que permite la sealizacin y
administracin de sesiones.
ste concepto requiere que cada dispositivo conectado a la red que requiera sesiones multimedia, de
voz y de datos, posea una direccin IP nica, por lo que la cantidad de direcciones IP necesarias para
tener operativa una red de stas caractersticas es mayor al actual soportado por el protocolo IPv4. Por
lo mismo IMS requiere la implementacin previa del protocolo IPv6, que ampla la cantidad de
direcciones IP disponibles para asignar.
Introduccin al IMS
Las tecnologas que se utilizan en telecomunicaciones han ido ingresando en distintos momentos en el
tiempo, y por lo tanto siendo soportadas por plataformas diversas especficas para cada una de ellas,
principalmente en concordancia con la tecnologa que exista en los surgimientos de cada uno de los
medios de comunicacin.
Inicialmente las arquitecturas tecnolgicas que soportaban cada una de las redes de comunicacin
estaban separadas, y utilizaban protocolos distintos. La televisin usa altas frecuencias y ultra altas
frecuencias, los telfonos mviles usan GSM y los computadores personales internet (a travs del
protocolo TCP/IP en la mayora de los casos). Sin embargo los equipos de acceso a estas redes


incorporaban cada vez ms tecnologa que permite obtener diversos contenidos multimedia. Los
telfonos mviles comenzaron a incorporar imgenes, msica y video. Adems exista un desafo en
poder mantener las sesiones de los telfonos mviles cuando cambiaban de red, ya sea a otra del
mismo proveedor u otro diferente a travs de Roaming.
Por lo mismo, el grupo 3rd Generation Partnership Project se plante crear el IMS que pretende ser una
arquitectura que soporte el trfico de voz, datos y multimedia mediante la conmutacin de paquetes a
direcciones IP, y con independencia del medio de acceso: telfonos mviles, fijos; computadores
personales; y todo dispositivo que pueda tener una direccin IP en la red. Slo requiere que los equipos
utilicen el protocolo de sesin SIP (Session Initation Protocol) que permite la sealizacin y
administracin de sesiones.
1

Origen del IMS
IMS fue definido originalmente por un congreso llamado 3G.IP en 1999. 3G.IP desarroll la arquitectura
original del IMS, la cual fue llevada a 3rd Generation Partnership Project(3GPP), como parte de su
trabajo de estandarizacin de sistemas 3G para celulares en la red de Sistema Universal de
Telecomunicaciones Mviles o UMTS por sus siglas en ingls. Su primera aparicin fue en Release 5,
cuando multimedia basada en SIP fue incluida.
Arquitectura
El grupo 3GPP fue el desarrollador de la tecnologa 3G basadas en el estndar GSM y GPRS, y defini
IMS como parte de su arquitectura de red. El grupo 3GPP2 en tanto, se ha encargado de desarrollar
dicha tecnologa, basada en estndares CDMA2000 e IS-41, y a s mismo desarrolla el sistema IMS en
sus redes, en funcin de lo establecido por el grupo 3GPP. Por lo mismo existen dos arquitecturas IMS
similares, cada una desarrollada por uno de estos grupos.
La arquitectura genrica del IMS es soporta la comunicacin entre equipos que utilizan SIP para la
sealizacin y la administracin de sesiones, adems de los protocolos Diameter y Megaco/H.248 para
operaciones y manejo de recursos multimedia respectivamente. Parte fundamental de la arquitectura
IMS est compuesta por los servidores de aplicacin, quienes se encargan de: invocar los servicios,
identificar qu sealizacin es requerida y de qu forma los servicios interactan ente s.
3

IMS en 3GPP
Una red 3G se caracteriza por dividir el ncleo de la red en dos dominios:
Dominio de Circuitos Conmutados (Circuit Switched Domain): Basado en la red GSM. Permite
el envo de mensajes cortos (SMS).


Domino de Paquetes Conmutados (Packet Switched Domain): La red GPRS nace de una
evolucin de la red GSM, debido a la necesidad de interactuar con internet. Esto permiti
conectividad IP bsica a usuarios mviles.

Para proveer servicios basados en el protocolo IP, el IMS debe cumplir con ciertos requisitos:
Calidad de servicio punta a punta en servicios VoIP, igual o mejor que en modalidad de
transmisin de voz por circuito conmutado.
Capacidad para soportar roaming.
Una o ms aplicaciones multimedia por sesin.
Soporte para el funcionamiento con redes de circuito conmutado.
El acceso a los servicios debe ser independiente de la tecnologa de acceso (WLAN, xDSL,
GPRS, etc.).
Soporte para la interaccin con otras redes, por ejemplo, con Internet.

La capa IMS se puede diagramar de la siguiente manera:

Capas 3GPP / TISPAN - Arquitectura IMS


Capas 3GPP / TISPAN - HSS en la capa IMS
IMS en 3GPP2
El grupo 3GPP2 defini la plataforma IP MMD, que consta de IMS y un subsistema de paquetes de
datos (PDS: Packet Data Subsystem), para dar soporte a las sesiones multimedia. IP MMD fue
diseado para proveer servicios y conectividad IP punta a punta por medio de una red de ncleo PS.
]Diferencias IMS 3GPP versus 3GPP2
Como IMS 3GPP, utiliza el protocolo SIP para la sealizacin y la mayora de sus componentes tienen
la misma funcionalidad. A pesar de sus similitudes, se requieren los cambios que se muestran en la
siguiente tabla para utilizar IMS sobre 3GPP2:


Diferencia 3GPP 3GPP2
Administracin de movilidad "Tunneling" de capa 2 usando GPRS IP mvil
Versin IP Slo IPV6 IPv4 e IPv6 (opcional)
Tarjeta inteligente UICC R-UIM (opcional)
Seguridad de acceso Slo Ipsec Existen alternativas
GGSN fija/PDSN GGSN nunca cambia PDSN cambia
Ubiacin de P-CSCF GGSN y P-CSCF siempre en la misma red GGSN y P-CSCF pueden estar separados
Posicionamiento -- PDE y servidor de posicin
Base de datos HSS AAA y bases de datos
Servicios CAMEL Interfaz Si entre HSS y IM-SSF --

Servidores de Aplicacin (AS)
IMS define tres tipos de servidores de aplicacin: Servidores SIP, OSA y CAMEL. Los SIP se comunican
directamente con los S-CSCF a travs del protocolo SIP. Los servidores OSA cumplen la misma
funcin, pero requieren el uso de un servidor SCS (Service Capability Server) como intermediario entre
el servidor OSA y el S-CSCF para traducir mensajes SIP. El servidor CAMEL, es un conjunto de
mecanismos que permiten al operador de la red entregar servicios especficos de operador a los
usuarios, a travs de IP-SSF, que traduce las solicitudes CAMEL a solicitudes SIP.
Un AS puede contener ms de una aplicacin IMS. De esta forma, AS utiliza e interpreta los mensajes
SIP enviados por el S-CSCF para enviar de vuelta una respuesta a travs de este mismo servidor.
7

Escalabilidad de IMS
IMS fue diseado para dar soporte amplio y complejo a los servicios multimedia IP para un alto nmero
de usuarios. A la vez, los servidores CSCF pueden ser asignados dinmicamente a los usuarios,


permitiendo escalabilidad independiente del nivel de trfico. Los servidores son distribuidos de tal modo
que la capacidad es extensible. Adems, el protocolo usado es SIP, que al ser basado en texto es fcil
de depurar, pero el tamao de los mensajes es grande.
Seguridad
La seguridad se divide, segn 3GPP, en seguridad de acceso y seguridad en el dominio de la red: En
relacin a la seguridad de acceso, los mensajes SIP entre el P-CSCF y el terminal IMS son protegidos
por dos asociaciones de seguridad IPsec despus de la autentificacin y la autorizacin en la etapa de
registro.
Para seguridad en el dominio de la red, se implementan SEGs en el borde del dominio de seguridad.
Autentificacin y proteccin de integridad en este intercambio son obligatorias, y se recomienda el
cifrado. De esta forma, si el P-CSCF en una red visitada y el S-CSCF en la red local estn en diferentes
dominios de seguridad, se podr mantener la seguridad de la sesin


Bibliografia:

Bibliografa Mandatoria

- Bill Douskalis, IP Telephony, Hewlett-Packard Professional Books
- John C. Bellamy, Digital Telephony, John Wiley & Sons
- Daniel Collins, "Carrier Grade Voice Over IP", McGraw-Hill Professional
Publishing
- Jonathan Davidson, "Voice over IP fundamentals 2nd Edition", Cisco
Press
- Gonzalo Camarillo, "SIP Demystified", McGraw-Hill Professional
Publishing

Bibliografa Complementaria

- Srinivas Vegesna, "IP Quality of Service", Cisco Press
- Millan Tejedor, Ramn Jess, Redes de datos y convergencia IP,
Creaciones Copyright
- H. Sinnreich, A B Johnston, "Internet Communications Using SIP", John
Wiley & Sons
- Scott Keagy, "Integrated Voice and Data Networks", Cisco Press
- R. Kustra, O. Tujsnaider, Principios de comunicaciones digitales Vol I
& II, AHCIET
- R. R. Stewart, Q. Xie, Stream Control Transmission Protocol (SCTP),
Addison-Wesley Longman Publishing Co., Inc

Acrnimos

A

ADSL Asymmetric Digital Subscriber Loop (Lnea Digital de Abonado
Asimtrica)
AES: Advanced Encryption System (Sistema de Encriptacin de Datos
Avanzado).
AOEN: All-Optical Ethernet Network (Red Ethernet Totalmente ptica).
ATA: Analogue Telephone Adapter (Adaptador Telefnico Analgico)
ATM: Asynchronous Transfer Mode (Modo de Transferencia Asncrona)


B

BPON Broadband PON (PON de Banda Ancha)

C

CAPEX: Capital Expenditures (Gastos de Capital)
CATV: Cable-Television (Televisin por Cable).
CDMA: Code Division Multiple Access (Acceso Mltiple por Divisin de
Cdigo)
CM: Cable Modem (Mdem de Cable)
CMTS: Cable Modem Termination System (Sstema Terminal de Mdems
de Cable)
CO/HE: Central Office/Head End (Oficina Central/ Equipamiento de
Cabecera de Cable)
CWDM Coarse Wavelength Division Multiplexing (Multiplexacin por
divisin aproximada de longitud de onda)

D

DES: Data Encryption System (Sistema de Encriptacin de Datos).
DG: Distribuidor General (MDF en ingls)
DOCSIS: Data Over Cable Service Interface Specification (Especificacin
de Interfaz sobre Servicios de Datos por Cable)
DSLAM Digital Subscriber Line Access Multiplexer (Multiplexor de Acceso
por Lnea Digital de Abonado)
DSP: Digital Signal Processing (Procesamiento Digital de Seal)
DVB: Digital Video Broadcasting (Difusin de Video Digital)
DVB-C: DVB-Cable (estndares DVB para transmisin por Cable)
DVB-H: DVB for Handhelds (estndares DVB para Terminales de mano
mviles)
DVB-RCC: DVB Return Channel Cable (Canal de Retorno DVB)
DVB-S DVB-Satellite (estndares DVB para transmisin por Satlite)
DVB-T: DVB Terrestrial (estndares DVB para transmisin Terrestre)
DWDM: Dense wavelength Division Multiplexing (Multiplexacin por
Divisin en Longitudes de Onda Densas)

E

EFM: Ethernet in the First Mile (Ethernet en la ltima Milla)
EPON: Ethernet PON

F


FDM: Frequency Division Multiplexing/Multiplexer
(Multiplexacin/Multiplexor por Divisin de Frecuencia)
FEXT: (Far-End CrossTalk) Diafona en el Terminal Lejano Denominada
Telediafona
FO: Fiber ptic (Fibra ptica)
FR: Frame Relay (Retransmisin de Tramas).
FSAN: Full Service Access Network
FTTB: Fiber to the Building (Fibra al Edificio del Cliente)
FTTC: Fiber to the Corner (Fibra a la Esquina del Cliente)
FTTH: Fiber to the Home (Fibra al Hogar del Cliente)
FTTX: Fiber to the X
FXO Foreign Exchange Office (Puerto de Conexin de Centralitas
Telefnicas)
FXS: Foreign Exchange Station (Puerto de Conexin de Telfonos
Analgicos)

G

GEM: GPON Encapsulation Method (Mtodo de Encapsulacin para
GPON)
GEPON: Gigabit Ethernet PON.
GMPLS: Generalized Multi-Protocol Label Switching (Conmutacin de
Etiquetas Multi-Protocolo Generalizado) (tambin llamado MPS)
GPON: Gigabit-Capable PON

H

HDPE: (High Density PE).
HDTV: High Definition TV (TV de Alta Definicin).
HE: (Head-End) (Equipamiento de Cabecera de Cable)
HFC Hybrid Fiber Coaxial (Red Hbrida de Fibra y Coaxil)
HGW: Home Gateway (Gategay de Usuario (en redes NGN))
HSS: Home Subscriber Server (Servidor de Usuarios Locales (en redes
NGN))

I

IEEE Institute of Electrical and Electronics Engineers (Instituto de
Ingenieros Elctricos y Electrnicos)
IETF: Internet Engineering Task Force.
IP: Internet Protocol (Protocolo de Internet)
IPTV: IP Television (Televisin por IP)
ISDN: Integrated Services Digital Network (Red Digital de Servicios
Integrados)


ISP: Internet Service Provider (Provedor de Servicios de Internet)
ITU Internacional Telecomunication Union (Unin de Telecomunicaciones
Internacional)

L

LAN: Local Area Network (Red de rea Local)
LT: Line Terminal (Terminal de Lnea)

M

MC: Module Control (Mdulo de Control (en redes NGN))
MDF: Main Distributing Frame (Distribuidor General)
MEF: Metro Ethernet Forum (Foro de Metro Ethernet).
MEGACO: Media Gateway Controller.
MGC: Media Gateway Controller.
MGCP: Media Gateway Control Protocol (Protocolo de Control de Media
Gateways)
MPEG2: Moving Pictures Experts Group 2 (grupo de expertos en
imgenes en movimiento)
MPEG-TS: MPEG Transport Stream (Flujo de transporte MPEG)
MPLS: Multi-Protocol Label Switching (Conmutacin de Etiquetas Multi-
Protocolo)
MPS: Multiprotocol Lambda Switching (tambien llamado GMPLS)
MSP: Multi Service Platform (Plataforma Multiservicio (en redes NGN))

N

NAP: Network Access. Point (Punto de Acceso de Red (en redes PON))
NEXT: (Near-End CrossTalk) Paradiafona
NF: Nodo Final.
NGN: Next Generation Networks (Redes de Nueva Generacin).
NID: Network Interface Device (Dispositivo Interface con la Red)
NP: Nodo Primario.
NRZ: Non Return to Zero (Sin Retorno a Cero)
NT: Network Terminal (Terminal de Red).

O

OADM: Optical Add-Drop Multiplexer (Multiplexor de Extraccin e
Insercin ptica)
OAM: Operative, Administrative and Maintence (Operacin,
Administracin y Mantenimiento).
ODN: Optical Distribution Network (Red de Distribucin ptica)


OFDM: Orthogonal Frequency Division Multiplexing (Multiplexacion por
Divisin de Frecuencias Ortogonales)
OLT: Optical Line Termination (Terminacin de Lnea ptica (en redes
PON))
ONT/ONU: Optical Network Termination/Optical Network Unit
(Terminacin de Red ptica/ Unidades de Red ptica (en redes PON))

P

PABX: Private Automatic Branch Exchange (Central Automtica de
Conmutacin Privada centralita)
PAL: (PoliEtileno-Al Laminado)
PBX (Private Branch eXchange) (Conmutador Privado no Automtico)
PCR: Punto de conexin de red
PDH (Plesiochronous Digital Hierarchy): Jerarqua de transmisin dgital
PDH: Plesiochronous Digital Hierarchy (Jerarqua Digital Plesicrona)
PE: Polyethylene (Polietileno)
PLC: Power Line Communication
PLC: Power Line Communication (Comunicacin por Lneas de Energa)
PMP: Point to Multipoint (Punto a Multipunto)
PON: Passive Optic Network (Red ptica Pasiva)
POTS: Plain Old Telephone Service (Servicio Telefnico Tradicional)
PPP: Point to Point Protocol (Protocolo de Punto a Punto)
PPV: Pay per View (Pagar para ver)
PSTN: Public Switched Telephone Network (Red de Telefona
Conmutada)
PTP: Point to Point (Enlace Punto a Punto)
PTR: Punto de terminacin de red

Q

QAM: Quadrature Amplitude Modulation (Modulacin de Amplitud en
Cuadratura)
QoS: Quality of Service (Calidad de Servicio)
QPSK: Quaternary/ Quadrature/Quadriphase Phase Shift Keying
(Modulacin por Desviacin de Fase Cuaternaria/ en
Cuadratura/Cudrifase)

R

RADSL (Rate-Adaptive Digital Subscriber Line) Lnea Digital de Abonado
de Velocidad Ajustable.
RDSI: Red Digital de Servicios Integrados (ISDN en ingls)
RF: Radio Frequency (Radiofrecuencia)


RTP: Real Time Transport Protocol (Protocolo de Transporte de Tiempo
Real)
Rx: Recepcin.

S

SBT: (Servicio Bsico Telefnico)
S-CDMA: Syncrhronous CDMA (CDMA Sincrnico)
SDH: Synchronous Digital Hierarchy (Jerarqua Digital Sincrnica)
SDSL: Symmetric Digital Subscriber Line) (Lnea Digital de Abonado
Simtrica)
SHDSL: (Single-pair High-speed Digital Subscriber Line) Lnea digital de
abonado de un solo par de alta velocidad)
SIGTRAN: Signalling Transport
SIP: Session Initiation Protocol (Protocolo de Iniciacin de Sesin).
SNMP: Simple Network Managing Protocol (Protocolo de Gestin de
Red).
SOHO: Small Office House Office (Pequea Oficina Oficina
Hogarea)
SR: Sub Repartidores
SS7: Signaling System number 7 (Sistema de sealizacin nmero 7)
STB: Set Top Box (Aparato colocado arriba del Televisor) Dispositvo
para IPTV
SW: Switch (Conmutador)

T

TCP/IP: Transmission Control Protocol/Internet Protocol (Protocolo de
Control de Transmisin/ Protocolo de Internet)
TDMA: Time Division Multiple Access (Acceso Mltiple por Divisin de
Tiempo).
Tecnica que permite canalizar un medio para
ToIP: Telephony over IP (Telefona sobre IP)
Tx: Transmisin.

U

USB: Universal Serial Bus (Bus Serie Universal)

V

VDSL: Very High Digital Subscriber Line (Lnea Digital de Abonado de
Alta Velocidad)
VoD: Video on Demmand (Video bajo demanda)


VoIP: Voice over IP (Voz sobre IP)

W

WAN: Wide Area Networks (Redes de rea Amplia)
WDM: Wavelength Division Multiplexing (Multiplexin por division de
longitud de onda)

X

XDSL: X Digital Subscriber Loop (Lnea Digital de Abonado), La X se
utiliza para generalizar a todas las tcnicas de transmisin digital sobre
la lnea de abonado por ejemplo ADSL, HDSL, VDSL, SDSL

Modulo 3

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modulo 3

Uploaded by

Copyright:

Available Formats

REDES AVANZADAS DE TELECOMUNICACIONES

You might also like