Metodología para implementar calidad de servicio (QoS) en la capa de

acceso aplicado a redes de nueva generación (NGN) enfocado en el servicio

de Voz

PROYECTO DE GRADO

Juan Pablo Arango Bernal

Luis Alberto Portilla Agreda

Asesor
Juan Carlos Cuéllar Quiñones
Magister

FACULTAD DE INGENIERÍA
DEPARTAMENTO ACADÉMICO DE TECNOLOGÍAS DE INFORMACIÓN Y
COMUNICACIONES
MAESTRÍA EN GESTIÓNINFORMÁTICA Y TELECOMUNICACIONES
SANTIAGO DE CALI
2012

1
 Metodología para implementar calidad de servicio (QoS) en la capa de
acceso aplicado a redes de nueva generación (NGN) enfocado en el servicio
de Voz

Juan Pablo Arango Bernal

Luis Alberto Portilla Agreda

Trabajo de grado para optar al título de

Máster en Gestión Informática y Telecomunicaciones con Énfasis
En Redes y Comunicaciones

Asesor
Juan Carlos Cuéllar Quiñones
Magister

FACULTAD DE INGENIERÍA
DEPARTAMENTO ACADÉMICO DE TECNOLOGÍAS DE INFORMACIÓN Y
COMUNICACIONES
MAESTRÍAEN GESTIÓNINFORMÁTICA Y TELECOMUNICACIONES
SANTIAGO DE CALI
2012

2
 Nota de aceptación

____________________________
____________________________
____________________________
____________________________
____________________________
____________________________

_________________________
Firma del Presidente del Jurado

_________________________
Firma del Jurado

_________________________
Firma del Jurado

Santiago de Cali, <Fecha>

3
 CONTENIDO

pág.

1. INTRODUCCIÓN 15

1.1. PLANTEAMIENTO DEL PROBLEMA 17

1.2. OBJETIVOS 18
1.2.1. Objetivo General. 18
1.2.2. Objetivos Específicos: 18

2. MARCO TEÓRICO 19

2.1. ESTUDIO DEL ESTADO ACTUAL DE LAS RECOMENDACIONES PARA

LA CALIDAD DE VOZ SOBRE REDES NGN´S. 19

2.2. ESTUDIO DE LOS RFC QUE TRATAN QOS PUBLICADOS POR EL

GRUPO DE TRABAJO DE INGENIERÍA DE INTERNET (IETF, INTERNET
ENGINEERING TASK FORCE) U OTRAS RECOMENDACIONES 19

2.3. GRUPOS QUE RELACIONAN LA CALIDAD DE SERVICIO 20

2.3.1. El IPPM (IP Performance Metrics). 20
2.3.1.1. Métricas 21
2.3.1.2. Metodologías de Medición de las Métricas. 21
2.3.2. IPFIX (IP Flow Information Export). 21

2.4. ESTUDIO DEL ESTADO ACTUAL DE LOS REQUERIMIENTOS DE LA

CRC PARA CALIDAD DE SERVICIO 22
2.4.1. Temas Generales de la CRC relacionados con QoS 22
2.4.2. Conceptos adoptados por la CRC. 24
2.4.2.1. UIT-T Y.1540 24
2.4.2.2. UIT-T Y.1541 24
2.4.2.3. ITU-T P.862 (PESQ) 25
2.4.2.4. Recomendación G.109 25

4
 2.4.2.5. E-Model (ITU-G.107) 25

2.5. ESTANDARES DE QoS DE LA ITU-T BASADAS EN REDES IP. 25

2.5.1. Recomendación Y.1540 26
2.5.1.1. Puntos de Medición y secciones medibles 27
2.5.1.2. Eventos de referencia de transferencia de paquetes IP (IPRE, IP packet transfer
reference events). 29
2.5.1.3. Parámetros de calidad de funcionamiento de la transferencia de paquetes IP. 29
2.5.1.3.1. Retardo de transferencia de paquetes IP (IPTD, IP packet transfer
delay) 30
2.5.1.3.2. Variación del retardo de paquetes IP IPDV (IP Packet Delay Varation)
entre 2 puntos de extremo a extremo. 30
2.5.1.3.3. Tasa de errores en los paquetes de protocolo Internet (IPER, IP packet
error ratio). 32
2.5.1.3.4. Tasa de pérdida de paquetes de protocolo Internet (IPLR, IP packet loss
ratio). 32
2.5.2. Recomendación Y.1541 32
2.5.2.1. Capacidad de transferencia. 33
2.5.2.2. Discusión general de QoS. 33
2.5.2.3. Clases de QoS de red. 34

2.6. ESTUDIO DE LAS RECOMENDACIONES QoS ENFOCADOS A

SERVICIOS VOZ SOBRE ACCESOS XDSL. 36
2.6.1. Transporte de ATM sobre xDSL. 37
2.6.2. Capa ATM. 37
2.6.2.1. Capa de Adaptación ATM 38
2.6.3. Manejo de Tráfico en ATM sobre xDSL. 41
2.6.3.1. Arquitectura de Servicios ATM. 41
2.6.3.2. Parámetros de QoS. 42
2.6.3.2.1. Peak-to-peak CDV (Peak-to-peak Cell Delay Variation o variación del Retardo
de Celda de pico a pico). 42
2.6.3.2.2. MaxCTD (Maximum Cell Transfer Delay o Retardo Máximo de Transferencia
de Celda). 42
2.6.3.2.3. CLR (Cell Loss Ratio o Tasa de Pérdida de Celdas). 43

5
 2.6.3.3. Parámetros de Tráfico. 43
2.6.3.4. Categorías de Servicio. 44
2.6.3.4.1. Velocidad de bits constante (Constant Bit RateCBR). 45
2.6.3.4.2. Velocidad de bit variable (variable bit rate VBR) 45
2.6.3.4.3. Velocidad de bit variable para tiempo Real (Real-Time Variable Bit Rate
rt-VBR) 45
2.6.3.4.4. Velocidad de bit variable no en tiempo Real (Non-Real-Time Variable Bit
Rate nrt-VBR) 45
2.6.3.4.5. Tasa de bits no especificado (Unspecified Bit Rate UBR). 46
2.6.3.4.6. Tasa de bits disponible (Available Bit Rate ABR). 46
2.6.4. Categoría de Servicios y Atributos de Parámetros ATM. 47
2.6.5. Control de Admisión de Conexión (Connection Admission Control o
CAC) 49
2.6.6. Conformidad del perfil de Tráfico (Usage/Network Parameter Control
o UPC/NPC). 49
2.6.7. Prioridad de pérdida de celda (CLP: Cell loss priority). 50
2.6.7.1. Tagging basado en CLP. 50
2.6.7.2. Descripción del Contrato de Tráfico. 51

3. ESTUDIO DE LAS REDES XDSL 52

3.1. CARACTERÍSTICAS DE xDSL 52

3.1.1. Tecnología DSL (Digital Subscriber Line) 53
3.2. CONEXIÓN BÁSICA xDSL. 54
3.3. VOZ SOBRE xDSL. 54
3.4. MODELO DE REFERENCIA DE VOZ SOBRE XDSL. 58
3.4.1. Definición de los bloques Funcionales del modelo de referencia de
Voz sobre xDSL. 59
3.4.1.1. Access Node 59
3.4.1.2. Network Termination 59
3.4.1.3. Customer Premises Interworking Function. 59
3.4.1.4. Customer Premises Distribution Network. 59
3.4.1.5. Customer Premises Equipment 59

6
 3.4.2. Definición de las interfaces funcionales del modelo de referencia de
Voz sobre xDSL. 59
3.4.2.1. V Interface 59
3.4.2.2. U Interface 59
3.4.2.3. Ta Interface 60
3.4.2.4. T Interface 60
3.4.2.5. R Interface 60
3.5. VoIP 60
3.5.1. Protocolos 60
3.5.2. Protocolo UDP 61
3.5.3. Protocolo TCP 61
3.5.4. RTP 62
3.5.4.1. Arquitectura 62
3.5.5. Protocolo SIP. 63
3.5.5.1. Funcionamiento. 63
3.5.6. SIP-T (SIP Trunk). 63
3.5.7. H.248. 64
3.6. MODELO DE VoIP EN xDSL. 64
3.6.1. Modelo. 64
3.7. ARQUITECTURA DE RED BASADA EN ETHERNET PARA
LA AGREGACIÓN DE xDSL. 65
3.7.1. Nodo de acceso. 66
3.8. ARQUITECTURAS DE QoS EN IP UTILIZADOS EN xDSL. 68
3.8.1. IP Best Effort 68
3.8.2. IntServ 69
3.8.2.1. Funcionamiento. 69
3.8.3. DiffServ 70
3.8.3.1. Funcionamiento. 70

4. ANÁLISIS DE LAS CARACTERÍSTICAS DEL DISPOSITIVO DE ACCESO

XDSL REFERENTE A LOS PARÁMETROS DE QOS. 71

7
4.1. DSLAM MA5600 71

4.1.1. Especificaciones del dispositivo MA5600. 71

4.1.2. Tipos de puertos MA5600. 72
4.1.3. Característica y funcionalidad. 74
4.1.4. Información general de capacidad y solución de QoS. 74
4.1.5. Clasificación de tráfico. 76
4.1.6. Política de tráfico preciso. 77
4.1.7. Cola y mecanismo de programación. 78
4.1.7.1. PQ (Priority queue) 79
4.1.7.2. WRR (Weighted round robin) 79
4.1.7.3. WRR-Max-Delay (weighted round robin maximum delay) 79

5. PLANTEAMIENTO DE LA METODOLOGÍA DE QoS A USARSE EN UNA

RED NGN PARA ACCESOS XDSL. 80

5.1. Metodología y consideraciones previas. 81

5.1.1. Configuración de los equipos. 82

5.1.2. Configuración de las rutas. 84
5.1.3. Sincronización de equipos. 84
5.1.4. Configuración de direccionamiento. 85
5.1.5. Escenario de laboratorio. 85
5.1.6. Medición del ancho de banda disponible en la red xDSL. 85
5.1.7. Generación de resultados 87
5.1.8. Procesamiento de medidas y resultados 87

6. CONFIGURACION DE EQUIPOS PARA VALIDACIÓN DE LA

METODOLOGÍA DE QoS A USARSE EN UNA RED NGN PARA ACCESOS
XDSL. 88

6.1. Diseño de pruebas de verificación. 88

8
 6.1.1. Pruebas sin calidad de servicio (Escenario No. 1). 93
6.1.2. Pruebas con políticas (CAR) y sin calidad de servicio (Escenario No.
2). 93
6.1.3. Pruebas con calidad de servicio (Escenario No. 3). 93

7. METODOLOGÍA SUGERIDA PARA EL OPERADOR DE

TELECOMUNICACIONES. 94

7.1. Descripción de la metodología. 94

8. ANÁLISIS DE RESULTADOS DE LA IMPLEMENTACIÓN DEL

LABORATORIO. 101

8.1. Pruebas Escenario No. 1. 101

8.2. Pruebas Escenario No. 2. 109

8.3. Pruebas Escenario No. 3. 113

8.3.1. Generación de VoIP (CLPNoTaggingNoSCR o CLPTaggingNoSCR)

+ IPTV + Internet 114

9. CONCLUSIONES 119

10. BIBLIOGRAFIA 121

11. LISTA DE ANEXOS 126

9
 LISTA DE TABLAS

pág.

Tabla 1.Parámetros de Calidad de funcionamiento que determinan la QoS en

NGN. 35
Tabla 2. Guía para las clases de QoS sobre protocolo IP. 36
Tabla 3. Servicios ofrecidos por la capa de adaptación. 41
Tabla 4. Servicios de red ATM. 48
Tabla 5. Parámetros de tráfico ATM y parámetros de calidad de servicio según la
categoría de servicio. 49
Tabla 6.Flujos de Monitoreo de celdas en cada modo de Política. 50
Tabla 7.Tráfico marcado para cada paquete del descriptor de tráfico. 51
Tabla 8. Comparación entres XDSL 53
Tabla 9. Relación de tipos de AAL a las categorías de servicios ATM. 58
Tabla10. Interfaces del MA5600. 73
Tabla 11. Propuesta de Best Effort para el tráfico del escenario No. 1. 89
Tabla 12. Propuesta de políticas de ancho de banda CAR del escenario No. 2. 89
Tabla 13. Propuesta de PQ o prioridad de colas de tráfico del escenario No. 3. 90
Tabla 14.Análisis de tráfico de voz en el acceso xDSL con Best Effort. 102
Tabla 15.Análisis de tráfico de voz en el acceso xDSL con CAR. 110
Tabla 16.Análisis de tráfico de voz en el acceso xDSL con PQ
(CLPNoTaggingNoSCR). 114
Tabla 17. Análisis de tráfico de voz en el acceso xDSL con PQ
(CLPTaggingNoSCR). 115
Tabla 18. Tabla comparativa de los escenarios de laboratorio. 118

10
 LISTA DE FIGURAS
pág.

Figura 1. Alcance de la Recomendación ITU-T Y.1540 27

Figura 2. Eventos de referencia de transferencia de paquetes IP 29
Figura 3. Eventos de retardo de transferencia de paquetes IP. Transferencia ‘extremo a extremo’
de un paquete IP. 30
Figura 4.Variación del retardo de paquetes IP entre dos puntos. 31
Figura 5.Trayecto de referencia UNI a UNI para los objetivos QoS de la red. 34
Figura 6.IP sobre ATM (U-Interface) 39
Figura 7.Tipos AAL 40
Figura 8. Relación entre CDV pico a pico y la MaxCTD. 42
Figura 9. Relación de los parámetros de tráfico ATM. 44
Figura 10. Banda ocupada por los tipos de tráfico ATM. 47
Figura 18.Topología básica de la red acceso de xDSL 54
Figura 19. Aarquitectura de voz sobre ATM en acceso xDSL. 55
Figura 20. Pila de protocolos acceso xDSL. 56
Figura 21.Modelo referencia arquitectura de Voz sobre xDSL 58
Figura 22.Cabecera IP (IPv4). 60
Figura 23. RTP en la pila de protocolos. 63
Figura 24. Modelo de VoIP. 65
Figura 25. Arquitectura de red Ethernet basada en xDSL. 66
Figura 26. Interfuncionamiento de ATM a Ethernet. 67
Figura 27.Arquitectura de múltiples VC´s. 68
Figura 28. Ejemplo de funcionalidad del MA5600. 72
Figura 29.Implementación de QoS en dirección descendente. 74
Figura 30.Implementación de QoS en dirección ascendente. 75
Figura 31.Lista de acceso ACL. 76
Figura 32.Muestra de control de tráfico a través de token bucket en la MA5600. 77
Figura 33.Programación de colas en la tarjeta principal de control. 78
Figura 34. Programación de colas en la tarjeta servicio. 79
Figura 35. Topología de laboratorio acceso ADSL. 82
Figura 36. Parámetro de línea del acceso ADSL en el lado receptor. 86

11
Figura 37.Parámetro de línea del acceso ADSL en el lado transmisor. 86
Figura 38. Parámetro de flujo de VoIP en D-ITG. 91
Figura 39. Parámetro de Multiflujo de VoIP en D-ITG. 92
Figura 40.Análisis Bitrate de 5 llamadas con canal básico (IPTV) e Internet en D-ITG. 103
Figura 41.Análisis Bitrate de 5 llamadas con parrilla (IPTV) e Internet en D-ITG. 103
Figura 42.Análisis delay de 5 llamadas con canal básico (IPTV) e Internet en D-ITG. 105
Figura 43.Análisis delay de 5 llamadas con canal parrilla (IPTV) e Internet en D-ITG. 105
Figura 44. Análisis jitter de 5 llamadas con canal básico (IPTV) e Internet en D-ITG. 106
Figura 45. Análisis jitter de 5 llamadas con canal parrilla (IPTV) e Internet en D-ITG. 107
Figura 46.Análisis packet loss de 5 llamadas con canal parrilla (IPTV) e Internet en D-ITG. 108
Figura 47.Análisis packet loss de 5 llamadas con canal parrilla (IPTV) e Internet en D-ITG. 108
Figura 48. Bitrate de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG. 111
Figura 49. Delay de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG. 111
Figura 50.Jitter de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG. 112
Figura 51.Pérdida de paquetes de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG.
113
Figura 52.Bitrate de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG. 116
Figura 53.Delay de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG. 116
Figura 54. Jitter de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG. 117
Figura 55. Perdidas de paquetes de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG.
117

12
 RESUMEN

Las empresas prestadoras de servicios de telefonía sobre redes NGN representan

un reto para los proveedores de tecnología, ya que desde el punto de vista de
gestión e ingeniería de red, deben suministrar plataformas suficientemente
robustas para soportar el manejo de la voz. Sin embargo, este tipo de servicio es
sensible al retardo que se presenta en una red de conmutación de paquetes,
causando baja calidad en la prestación de dicho servicio, en comparación al
servicio tradicional prestado por las redes de conmutación de circuitos.

Las empresas prestadoras de servicios de telecomunicaciones actualmente

convergen todos los servicios en una red de próxima generación (NGN) y las
exigencias hoy en día de calidad de servicio son más estrictas por los mismos
requerimientos de los usuarios. De esta manera es necesario plantear una
metodología de QoS para garantizar una operación eficaz en el transporte de los
servicios de tiempo real más críticos como la voz, garantizandola disminución de
los problemas comunes de latencia, Jitter, pérdida de paquetes y Eco en una red
NGN enfocados en los accesos xDSL.

La CRC (Comisión Reguladora De Comunicaciones) aplica las disposiciones de

QoS para que estas sean empleadas por los operadores de Telecomunicaciones y
deben ajustarse a las recomendaciones Y.1540 y Y.1541de la ITU-T (Unión
Internacional de Telecomunicaciones). Igualmente teniendo en cuenta la
importancia de QoS en los servicios soportados por las redes NGN se encuentran
series de recomendaciones generalizadas para aplicación de QoS que
específicamente no muestran, ni determinan mecanismo o proceso de buenas
prácticas de QoS hacia los accesos xDSL.

El objetivo de este documento es presentar una metodología para aplicar

mecanismos de QoS en una red NGN con acceso xDSL con el fin de mantener
calidad de servicio al servicio de VoIP, y que permita la provisión económica y
técnicamente eficiente de VoIP en favor del operador de telecomunicaciones y el
cliente.

Este proyecto analiza en detalle la provisión de QoS teniendo como soporte en su

infraestructura acceso base, un conjunto de tecnologías agrupadas en xDSL
(Digital Subscriber Line) sobre la cual se puede entregar múltiples servicios como
el de la voz con la finalidad de conocer y aprovechar la mejor característica de la
VoIP que nos permitan cumplir con el objetivo planteado.

Para validar el funcionamiento de la metodología de implementación, se han

realizado una serie de pruebas en tres escenarios como Best Effort, políticas de
ancho de banda y QoS, con el fin de analizar los resultados de los diferentes

13
casos en orden de complejidad, de forma que se pueda comprobar el correcto
funcionamiento del sistema y los beneficios alcanzados.

14
 1. INTRODUCCIÓN

Hablar de redes NGN (Next Generation Networks ó Redes de próxima generación)

es hablar de convergencia y donde la calidad de servicio (QoS - Quality of Service)
juega un papel importante para el tratamiento de la información (Datos-Voz-Video)
que la red transporta. Se destaca la evolución de uno de los servicios específicos
como la voz que ha migrado progresivamente desde las redes PSTN (Public
Switched Telephone Network) ó RTPC (Redes Telefónicas Públicas Conmutadas)
a las redes NGN basadas en el protocolo IP.

El proceso evolutivo de las telecomunicaciones hizo cambiar el modelo de

provisión de servicios de los operadores buscando la forma de integrar todo tipo
de servicios, y uno de ellos el de voz, en una única infraestructura de red con
mayor capacidad, calidad de servicio (QoS), seguridad y fiabilidad, llegando
entonces al modelo actual de Red de Próxima Generación o Next Generation
Network (NGN), que basa su transporte en el protocolo IP (Internet Protocol) y
que la ITU–T en su Recomendación Y.2001[1] la define como: “Red basada en
paquetes que permite prestar servicios de telecomunicación y en la que se pueden
utilizar múltiples tecnologías de transporte de banda ancha propiciadas por la QoS
(Quality of Service), y en la que las funciones relacionadas con los servicios son
independientes de las tecnologías subyacentes relacionadas con el transporte.
Permite a los usuarios el acceso sin trabas a redes y a proveedores de servicios
y/o servicios de su elección. Se soporta movilidad generalizada que permitirá la
prestación coherente y ubicua de servicios a los usuarios”.

En las Redes NGN convergen las tecnologías, los servicios, los contenidos de
audio, voz y video, datos los cuales, crecen exponencialmente exigiendo cada vez
más capacidad de canal, en consecuencia más demanda de recursos de red, y
paralelamente los usuarios finales exigen que los servicios funcionen de manera
adecuada.
Teniendo en cuenta el comportamiento de uso de los servicios, los operadores en
Colombia ven la necesidad de establecer metodologías para ofrecer Calidad de
Servicio, esto con el fin, de lograr que el ancho de banda en el bucle de acceso se
asigne de manera eficiente, para así garantizar y cumplir con compromisos reales
de calidad de servicio que lleve al usuario a sentir satisfacción plena por los
servicios contratados.

La Comisión de Regulación de Comunicaciones (CRC) sigue de cerca la

evolución de la Calidad de Servicio en Colombia, por lo cual es importante
establecer políticas en la capa de acceso xDSL de las redes de próxima
generación (NGN) que tracen una ruta; soportado en un proceso que se ajuste a
las necesidades de los usuarios finales y logrando la entrega del servicio con

15
QoS, permitiendo así que el operador tenga un factor diferenciador dentro del
mercado competitivo, principalmente entre las empresas operadoras de servicios
de telecomunicaciones.

El documento está organizado de la siguiente manera: en el capítulo 1 se

presentan el planteamiento del problema, el objetivo general y los objetivos
específicos del problema a resolver, en el capítulo 2 se explora un estudio de las
recomendaciones para la calidad de voz sobre redes NGN dentro del marco
Internacional y de la Comisión de Regulación de Colombia (CRC), en el capítulo 3
se explica detenidamente los accesos de última milla de la tecnología XDSL, en el
capítulo 4 se aborda un análisis de las características del dispositivo de acceso
xDSL referente a los parámetros de QoS, en el capítulo 5 se enmarca la
metodología para QoS en una Red NGN, se analiza y documentan los dispositivos
y actividades de implementación, pruebas, resultados, se definen los escenarios
del laboratorio y las pruebas necesarias a realizar. Para finalizar en el capítulo 6
se entregan las conclusiones obtenidas por el análisis de resultados de las
pruebas de laboratorio realizadas.

16
1.1. PLANTEAMIENTO DEL PROBLEMA

La tendencia actual de las empresas prestadoras de servicios de

telecomunicaciones de prestar todos los servicios sobre una misma
infraestructura, ha puesto de manifiesto el problema que tienen las redes NGN en
ofrecer calidad de servicio. Por esta razón, es necesario plantear una metodología
de QoS para garantizar la operación eficaz en el transporte de los servicios de
tiempo real más críticos como la voz. Con esto, se garantizaría la disminución de
los problemas comunes de latencia, Jitter, pérdida de paquetes y Eco en una red
NGN enfocados usuarios con bucle de acceso xDSL.

Actualmente, el método más utilizado para ofrecer calidad de servicio (QoS) en

redes NGN es Best Effort, cuya funcionalidad es asignar una cierta capacidad de
canal a todos los usuarios de la mejor manera posible, sin hacer verdaderos
compromisos en cuanto a la tasa de transferencia o el retardo de los paquetes. Sin
embargo, como esto no es realmente eficaz, las empresas de telecomunicaciones
que estén implementando o tengan una Red NGN deben desarrollar mecanismos
más especializados de QoS, para garantizar la mejora de los parámetros que
influyen en una buena prestación de un servicio calificado. No obstante, aún y
cuando alcanzan a dar solución a los problemas de QoS en la red, su progreso se
denota insuficiente en relación con el de la infraestructura y el crecimiento de la
misma.

Para este proceso de convergencia, las redes NGN con bucle de acceso xDSL
son bastante ambiciosas en cuanto a la variedad de servicios a ofrecer, por la
flexibilidad de los protocolos y los mecanismos de brindar varios servicios a través
del mismo medio. Sin embargo, es la satisfacción del usuario, uno de los puntos
más complejos e importantes a analizar y resolver que refleje un nivel de Calidad
de Servicio (QoS), vista como un factor que debe ser inherente a la red y qué ha
sido la respuesta a las nuevas exigencias que se derivaron del crecimiento de los
accesos xDSL.

Por lo tanto la implementación de una metodología para garantizar QoS puede

servir de apoyo no sólo para agilizar y mejorar si no para fijar un acuerdo de nivel
de servicio (ANS ó sus siglas en inglés Service Level Agreement (SLA)) entre el
operador y el cliente. De esta manera, un SLA identifica y define las necesidades
del cliente a la vez que controla sus expectativas de servicio en relación a la
capacidad del proveedor, proporciona un marco de entendimiento; simplificando y
reduciendo conflictos y favoreciendo el diálogo entre las partes.

17
1.2. OBJETIVOS

1.2.1. Objetivo General.

Formular una metodología para ofrecer QoS en una red NGN para accesos xDSL
enfocado en el servicio de VoIP.

1.2.2. Objetivos Específicos:

1. Identificar las recomendaciones/estándares que se ajusten a los

requerimientos de QoS en accesos xDSL para el servicio de VoIP.

2. Identificar los parámetros específicos de configuración de QoS para

dispositivos de acceso xDSL de la red NGN.

3. Establecer los procedimientos por usar en la implementación de QoS en una

red NGN para accesos xDSL.

4. Realizar pruebas de laboratorio que permitan obtener datos para verificar los
parámetros de QoS.

5. Documentar la metodología para implementar calidad de servicio basado en

las pruebas de laboratorio.

18
 2. MARCO TEÓRICO

2.1. ESTUDIO DEL ESTADO ACTUAL DE LAS RECOMENDACIONES PARA

LA CALIDAD DE VOZ SOBRE REDES NGN´S.

Hoy día las redes de conmutación de circuitos y conmutación de paquetes poco a

poco se han integrando a las redes IP que son infraestructuras que llevan tráfico
de PSTN y aplicaciones de multimedia. De esta manera esta convergencia implica
un crecimiento alto en servicios hacia el usuario. Sin embargo, la convergencia ha
sido lenta. Desde un punto de vista técnico, el principal obstáculo ha sido la
calidad de servicio (QoS) en las redes IP tradicionales. No obstante, el incremento
de nuevos servicios genera un efecto de limitación de ancho de banda y el
aumento de la latencia y pérdida de paquetes afectando los servicios de tiempo
real tales como la voz.

2.2. ESTUDIO DE LOS RFC QUE TRATAN QOS PUBLICADOS POR EL

GRUPO DE TRABAJO DE INGENIERÍA DE INTERNET (IETF, INTERNET
ENGINEERING TASK FORCE) U OTRAS RECOMENDACIONES

The Internet Architecture Board (IAB) como encargado del desarrollo técnico y de
la ingeniería de la Internet supervisa grupos de trabajo entre ellos el Internet
Engineering Task Force (IETF) que es uno de los grupos que participa en el
desarrollo de los estándares de Internet.

La Fuerza de Tareas de Ingeniería de la Internet (IETF) es una comunidad

internacional abierta; constituida por diseñadores de redes, fabricantes de equipos
y software, operadores e investigadores que trabajan con la arquitectura de
Internet y se encargan de desarrollar soluciones a problemas de operación y
técnicos que aparecen en la Internet y a la vez se encarga de mantener mediante
la creación, prueba e implementación el desarrollo de estándares y protocolos
requeridos para su adecuada operación.

La IETF se encuentra dividida en diez (10) áreas técnicas:

 Aplicaciones
 Administración de Redes
 Futuras Generaciones de Protocolo IP
 Internet
 Requerimientos Operacionales u operación y mantenimiento
 Rutas ó encaminamiento
 Seguridad

19
  Transporte
 Servicios de Usuario
 General

Dentro de cada área técnica se conforman grupos de trabajo (Working Groups)

conformados por voluntarios, grupos que una vez alcanzado el objetivo se
disuelven. Cada grupo de trabajo está liderado por un director de área los que
están agrupados en el Internet Engineering Steering Group (IESG).

Todo resultado y recomendación se presentan a través de los "Request for

Comments" por sus siglas en inglés RFCs (Petición de Comentarios) y son
documentos que sirven de referencia , describen, especifican y asisten en la
implementación, estandarización y discusión de la mayoría de las normas, los
estándares, las tecnologías y los protocolos relacionados con Internet y las redes
en general.

Los documentos RFCs que son fuentes de información están disponibles para el
público en general, en múltiples sitios en Internet, y se pueden obtener a través de
FTP Anónimo, ó vía correo electrónico.

2.3. GRUPOS QUE RELACIONAN LA CALIDAD DE SERVICIO

2.3.1. El IPPM (IP Performance Metrics).

Este grupo de trabajo mantiene contacto coordinado con los grupos CE 12 y CE

13 de la UIT-T ; define métodos y métricas para la calidad de funcionamiento,
comportamiento, y la confiabilidad de los servicios de datos teniendo en cuenta la
experiencia del usuario final, el proveedor del servicio y la de grupos
independientes de pruebas. Específicamente las actividades el CE 12 se centra en
la Calidad de extremo a extremo percibida por el usuario y todos los temas están
relacionados con la calidad y el CE 13 se dedica a la calidad de funcionamiento de
las redes (NP, Network Performance).

El marco de trabajo del grupo IPPM definió las métricas que se pueden tomar
como referencia para definir parámetros que permitan a usuarios y proveedores de
red conocer el estado de sus servicios de red y el rendimiento de la red IP, los
conceptos están consignados en el RFC2330 documento en el cual se establecen
conceptos y definiciones generales y sienta las bases para las especificaciones de
las distintas métricas.

20
2.3.1.1. Métricas

Teniendo en cuenta que la percepción del usuario del rendimiento de los servicios
de comunicaciones se ve afectada por factores o variables que se traducen a
degradación de los servicios el grupo de trabajo IPPM definió los estándares
ajustados a métricas en los RFC:

 Métrica de retardo en un sentido - RFC 2679 (One way Delay Metric). [2]
 Métrica de pérdida de paquetes en un sentido - RFC 2680 (One way Packet
Loss Metric). [3]
 Métrica de la variación del retardo de paquetes - RFC 3393 (IP - Packet
Delay Variation Metric). [4]
 Métrica para medir conectividad - RFC 2678 (IPPM Metric for Measuring
Connectivity). [5]
 Métrica del retardo de ida y vuelta - RFC 2681 (Round Trip Delay Metric).
[6]
 Métrica de la capacidad de transferencia - RFC 3148 (Bulk Transfer
Capacity Metric. [7]
 Métrica de muestreo de patrones de pérdidas en un sentido - RFC 3357
(One way Loss Pattern Sample Metric). [8]
 RFC 3432 (Network Performance Measurement for Periodic Streams). [9]

2.3.1.2. Metodologías de Medición de las Métricas.

Teniendo en cuenta las recomendaciones del IPPM en el RFC2330 como técnicas

aplicables para la medición se encuentran las metodologías de:

 Métrica individual.
 Métrica muestral.
 Métrica estadística.

Como los dispositivos de red pueden dar un tratamiento diferente a los paquetes
de los distintos protocolos se requiere especificar el tipo de tráfico (¨Packet of Type
P¨) a que se refiere la métrica.

2.3.2. IPFIX (IP Flow Information Export).

Para el monitoreo de la calidad de servicio el grupo de trabajo del IETF IPFIX

define el protocolo IP Flow Information Export (IPFIX) [10] para que funcione en
diversas aplicaciones de tal manera que permita la estandarización de la forma en
que enrutadores u otros dispositivos transporten la información de los flujos que
utilizan el protocolo IP. Este protocolo es un proceso de medición que recoge los

21
paquetes de datos en un punto de observación, opcionalmente, los filtra y agrega
información acerca de estos paquetes.

2.4. ESTUDIO DEL ESTADO ACTUAL DE LOS REQUERIMIENTOS DE LA

CRC PARA CALIDAD DE SERVICIO

Para el estudio del estado actual en materia de Calidad de Servicio expuestos por
la CRC se han considerado aquellos criterios que se mantienen y que enuncian de
alguna manera la importancia relevante que representa para la CRC la Calidad de
Servicio (QoS), referencias que se reflejan en los documentos y resoluciones que
expide en ejercicio de sus facultades legales y en especial las que le confiere la
Ley 1341 de 2009, como el órgano encargado de promover la competencia, evitar
el abuso de posición dominante y regular los mercados de las redes y los servicios
de comunicaciones, con el fin de que la prestación de los servicios sea
económicamente eficiente y refleje altos niveles de calidad.

2.4.1. Temas Generales de la CRC relacionados con QoS

La CRC Comisión de Regulación de Comunicaciones de la República de Colombia

en su Documento de respuestas a comentarios a la propuesta regulatoria
Régimen de redes en convergencia del 16/08/11 y Revisado por la Coordinación
Regulación de Infraestructura; enuncia los criterios basados en las respuestas a
los diferentes proveedores en las cuales trata el tema de Calidad de Servicio
referenciado en: 3.18 Artículo 25 Calidad de servicio.

La CRC expone que (…) Para el caso de redes IP, las metas están claramente
establecidas para los diferentes tipos de clases de servicio en la recomendación
UIT-T Y.1541 y con el establecimiento de un índice R mayor a 80.(…) sobre el uso
del índice R, la propuesta es que el mismo esté enfocado en redes IP.

La CRC tiene en cuenta para el cálculo del índice R con base en el modelo E, la
fórmula: R= Ro – Is – Id – I e-eff – A. Donde la recomendación UIT utiliza A=0 por
defecto. Y según el caso se plantea la utilización de los contornos del factor de
determinación de índices R adoptados por la enmienda 1 de la recomendación
G.109, los cuales establecen en redes conmutadas de paquetes y para diferentes
tipos de códec, la relación entre el factor R, el retardo absoluto y la probabilidad de
pérdida de paquetes.(…).

La CRC es clara que para los requerimientos de calidad de servicio sobre redes
conmutadas de paquetes IP deben mantenerse sobre la base de las
recomendaciones UIT-T Y.1540 y UIT-T Y.1541.

22
La CRC entiende que: (…) mediciones de PESQ son técnicamente medibles
pudiendo atenerse a la realidad de la red nacional y que PESQ se basa en el
estándar UIT-T P.862. Sin embargo, el índice R también puede medirse sin
dificultad y tiene una clara aplicación en el problema más relevante de la
paquetización de la voz, esto es la calidad de la misma tal y como sería percibida
por un usuario humano.

La CRC enuncia que (…) la disposición que sobre el particular se incluyó en la

Resolución CRC 3067 de 2011 está enfocada en conocer la calidad percibida por
el usuario cuando sostiene comunicaciones de voz a través de redes de
conmutación de paquetes,(…) confirmando (…) que para su cálculo se emplearán
los contornos del factor de determinación de índices R adoptados por la enmienda
1 de la recomendación G.109 los cuales establecen para diferentes tipos de
códec, la relación entre el factor R, el retardo absoluto y la probabilidad de pérdida
de paquetes.

La CRC en el documento <<Estudio Integral de Redes de Nueva Generación y

Convergencia Documento Amarillo Centro de Conocimiento del Negocio>> tiene
en cuenta los lineamientos y estándares de la UIT haciendo referencia a las
características principales de las NGN, incluidas en la Recomendación Y.2001:

Características fundamentales de la NGN

 Transferencia basada en paquetes;

 Separación de las funciones de control en capacidades de portador,
llamada/sesión, y aplicación/servicio;
 Separación entre la prestación del servicio y el transporte, y la provisión de
interfaces abiertas;
 Soporte de una amplia gama de servicios, aplicaciones y mecanismos
basados en bloques de construcción del servicio (incluidos servicios en
tiempo real/de flujo continuo en tiempo no real y multimedia);
 Capacidades de banda ancha con QoS extremo a extremo;
 Inter-funcionamiento con redes tradicionales a través de interfaces abiertas;
 Movilidad generalizada;
 Acceso sin restricciones de los usuarios a diferentes proveedores de
servicios;
 Variedad de esquemas de identificación;
 Percepción por el usuario de características unificadas para el mismo
servicio
 Convergencia de servicios entre fijo y móvil;
 Independencia de las funciones relativas al servicio con respecto a las
tecnologías de transporte subyacentes;
 Soporte de múltiples tecnologías de la última milla;

23
  La conformidad con todos los requisitos reglamentarios, por ejemplo en
cuanto a comunicaciones de emergencia, seguridad, privacidad,
interceptación legal, etc.”
De las anteriores características enunciadas en las Características fundamentales
de la NGN para el marco de la Calidad se servicio se resaltan aquellas que
protegen al usuario en la prestación del servicio, esto es preservar la percepción
por el usuario de características unificadas para el mismo servicio y la
característica: capacidades de banda ancha con QoS extremo a extremo;

Igualmente hace referencia a la calidad de servicio en: 3.1 Capa de conectividad

primaria (…) La tecnología que se elija dependerá de las consideraciones
comerciales, pero la transparencia y la calidad del servicio (QoS) deben
garantizarse en cualquier caso, ya que el tráfico de los clientes no debe ser
afectado por perturbaciones de la calidad, tales como las demoras, las
fluctuaciones y los ecos.

Teniendo en cuenta que los tipos de acceso son variados (DSL, cable, etc.) se
precisa que no se puede medir el desempeño y la Calidad QoS con un mismo
criterio porque las condiciones y las limitantes de las tecnologías de acceso tienen
particularidades propias de cada tecnología.

2.4.2. Conceptos adoptados por la CRC.

2.4.2.1. UIT-T Y.1540

La recomendación Y.1540 define parámetros que permiten especificar y evaluar la

calidad de funcionamiento en relación con:

 Velocidad
 Exactitud
 Seguridad de funcionamiento
 Disponibilidad de transferencia

2.4.2.2. UIT-T Y.1541

La recomendación Y.1541 especifica los valores de calidad de funcionamiento de

IP aceptables para cada uno de los parámetros de calidad de funcionamiento
definidos en la Recomendación UIT-T Y.1540 que finalmente son la base para
establecer los acuerdos de niveles de servicios (ANS) entre usuarios y
proveedores de servicios de red comunicaciones.

24
2.4.2.3. ITU-T P.862 (PESQ)

La recomendación P.862 toma como patrón de referencia la señal PESQ

(Perceptual Evaluation of Speech Quality) teniendo en cuenta los parámetros
tradicionales de redes de conmutación de circuitos como el ruido y el eco. En
esencia PESQ compara una señal de entrada o inicial con una señal degradada
resultante de la transmisión de la señal inicial a través de un sistema de
comunicación. Con la señal PESQ se puede obtener la nota media de opinión por
sus siglas en inglés MOS (Mean Opinion Score), que se enmarca dentro de una
metodología de un proceso subjetivo donde un grupo de personas valoran la
calidad de servicio de diferentes muestras de voz transmitidas a través de distintos
medios.

2.4.2.4. Recomendación G.109

Define categorías para la calidad de transmisión de señales de voz, utiliza como

valores de referencia las medias de opinión (MOS) y los porcentajes bueno o
mejor (%GOB) y mediocre o peor (%POW), determina con ellos la satisfacción del
usuario (la escala va de muy satisfechos a casi todos insatisfechos). [11]

2.4.2.5. E-Model (ITU-G.107)

EL modelo de recomendación de la ITU-T G.107, llamado E-Model, [12] tiene

como objetivo estimar, predecir la calidad de la voz en las redes que utilizan el
protocolo IP para llevar la voz (VoIP) y que es percibida por un usuario normal,
para estimar la calidad se toma como referencia parámetros medibles de la red.
El resultado del E-Model es un factor escalar, llamado R (Transmission Rating
Factor), que puede tomar valores entre 0 y 100, estos valores son directamente
proporcionales lo que significa que entre más alto sea el valor se tendrá mejor
calidad de voz.

2.5. ESTANDARES DE QoS DE LA ITU-T BASADAS EN REDES IP.

Hoy día los operadores de telecomunicaciones han migrado los servicios que
funcionan en las redes de conmutación de circuitos a redes de conmutación de
paquetes o NGN. Esta estructura lleva consigo servicios de la PSTN, tráfico de
aplicaciones de Internet y todos todo tipo de servicio de protocolo IP. Por lo tanto
esta “convergencia” cuyo escenario fue el gran atractivo en los bajos costos
mediante la consolidación de la tecnología y el crecimiento de la industria de la
telecomunicaciones a través del empaquetamiento de los servicios.

25
Pese a las grandes inversiones en redes NGN la convergencia ha
sido lenta. Desde un punto de vista técnico, el principal obstáculo ha sido la
calidad de servicio (QoS) debido a que el mecanismo más utilizado en la redes
NGN es Best Effort, cuya funcionalidad es asignar una cierta capacidad de canal
a todos los usuarios de la mejor manera posible, sin hacer verdaderos
compromisos en cuanto a la tasa de transferencia o el retardo de los paquetes, Sin
embargo, como esto no es realmente eficaz, ni mucho menos significativo, las
empresas de telecomunicaciones que estén implementando o tengan una red
NGN deben desarrollar mecanismos más especializados de QoS, para enfatizar
más la mejora de los parámetros que influyen en una buena prestación de un
servicio calificado, sobre todo, la voz sobre IP (VoIP). No obstante, aún y cuando
alcanzan a dar solución a los problemas de QoS en la red, su progreso se denota
insuficiente en relación con el de la infraestructura y el crecimiento de la misma.

La ITU-T (International Telecommunication Union Telecommunication

Standardization) tiene dos recomendaciones de importancia que hablan de los
parámetros comunes de QoS y mecanismos de red específicos de QoS sobre una
base de terminal a terminal.

Por lo tanto estas recomendaciones definen lo siguiente:

2.5.1. Recomendación Y.1540

Define los parámetros que se pueden utilizar para especificar y evaluar el

rendimiento de velocidad, precisión, fiabilidad y disponibilidad de la transferencia
de paquetes IP por medio de una comunicación de datos. Los parámetros
pueden ser empleados en caracterizar el flujo IP extremo a extremo y los
diferentes puntos de la red [13].

Esta recomendación es utilizada por los operadores de telecomunicaciones en la

planificación, desarrollo y evaluación de servicios que puedan transportarse en
una red IP con el objetivo de satisfacer las necesidades de los usuarios que
requieran de un manejo adecuado de sus servicios contratados.

En la figura 1 se muestra de manera resumida el alcance de esta recomendación.

Los parámetros de calidad de funcionamiento del servicio IP se definen sobre la
base de eventos de referencia de transferencia de paquetes IP que se pueden
observar en puntos de medición (MP, measurement points) asociados con
fronteras funcionales y jurisdiccionales. En efectos de comparabilidad y
exhaustividad, la calidad del servicio IP se considera en el contexto de la matriz de
calidad de funcionamiento de 3 × 3 definida en la Recomendación UIT-T I.350
[14]. En dicha matriz se identifican tres funciones de comunicación independientes
del protocolo: acceso, transferencia de información de usuario y desvinculación.

26
Cada función se considera con respecto a tres aspectos del funcionamiento en
general (o “criterios de calidad de funcionamiento”): velocidad, exactitud y
seguridad de funcionamiento. Un modelo de dos etapas asociado proporciona la
base para la descripción de la disponibilidad del servicio IP [16].

Figura 1. Alcance de la Recomendación ITU-T Y.1540

Tomado de [54]

2.5.1.1. Puntos de Medición y secciones medibles

Los puntos de medición (MP, measurement point): es una frontera entre un com-
putador principal y un enlace adyacente en donde pueden observarse y medirse
eventos de referencia de calidad de funcionamiento. De conformidad con la
recomendación de la UIT-T I.356 [18], los protocolos Internet normalizados se
pueden observar en puntos de medición IP. La recomendación UIT-T I.356
contiene más información sobre los MP para servicios digitales. Por lo tanto la
sección o una combinación de secciones son medibles si está limitada por un

27
conjunto de puntos de medición (MP). En esta Recomendación son medibles las
siguientes secciones:

 Sección básica: Puede ser un EL (Exchange link, N. del E.), una NS (network
section, N. del E.), un SRC (source host) o un DST (destination host). Las
secciones básicas están delimitadas por puntos de medición (MP).

La calidad de funcionamiento de cualquier EL o NS se puede medir en relación

con cualquier servicio IP de extremo a extremo unidireccional dado. Los MP de
ingreso son el conjunto de MP cruzados por paquetes de ese servicio cuando
entran en la sección básica. Los MP de egreso son el conjunto de MP cruzados
por paquetes de ese servicio cuando salen de la sección básica.

 Red con protocolo Internet de extremo a extremo (End-to-end IP network, N.

del E.): Conjunto de EL y NS que proporcionan el transporte de paquetes IP
transmitidos de un SRC (source host) a un DST (destination host). Los MP que
limitan la red IP de extremo a extremo son los MP del SRC (source host) y el
DST (destination host).

La calidad de funcionamiento de una red IP de extremo a extremo se puede

medir en relación con cualquier servicio IP de extremo a extremo unidireccional
dado. El MP de ingreso es el MP cruzado por paquetes de ese servicio cuando
entran en la red de extremo a extremo en el SRC (source host). El MP de
egreso es el MP cruzado por paquetes de ese servicio cuando salen de la red
de extremo a extremo en el DST (destination host).

Conjunto de secciones de red (NSE, network section ensemble): Un NSE es

cualquier subconjunto conectado de NS junto con todos los EL que las
interconectan. El término “NSE” se puede utilizar para referirse a una sola NS, dos
NS o cualquier número de NS y el que las conecta. Pares de NSE distintos están
conectados por enlaces de central. El término “NSE” se puede utilizar también
para representar toda la red IP de extremo a extremo. Los NSE están delimitados
por puntos de medición (MP).

La calidad de funcionamiento de cualquier NSE dado se puede medir en relación

con cualquier servicio IP de extremo a extremo unidireccional. Los MP de ingreso
son el conjunto de MP cruzados por paquetes de ese servicio cuando entran en
ese NSE. Los MP de egreso son el conjunto de MP cruzados por paquetes de ese
servicio cuando salen de ese NSE

28
2.5.1.2. Eventos de referencia de transferencia de paquetes IP (IPRE, IP
packet transfer reference events).

En el contexto de esta Recomendación, las definiciones que siguen se aplican en

un servicio IP de extremo a extremo especificado. Los términos definidos se
ilustran en la figura 2.

Figura 2. Eventos de referencia de transferencia de paquetes IP

Tomada de [52]

Un evento de transferencia de paquetes IP ocurre cuando:

 Un paquete IP cruza un punto de medición (MP).

 Se aplican procedimientos IP normalizados al paquete para verificar la

validez de la suma de control del encabezamiento.

 Los campos de dirección de origen y destino del encabezamiento del

paquete IP representan las direcciones IP del SRC (source host) y el
DST (destination host) previstos.

2.5.1.3. Parámetros de calidad de funcionamiento de la transferencia de

paquetes IP.

Esta cláusula define un conjunto de parámetros de calidad de funcionamiento de

la transferencia de información de paquetes IP utilizando los resultados de la
transferencia de paquetes IP. Los parámetros se pueden estimar sobre la base de
las observaciones efectuadas en los MP que limitan la sección básica o el NSE
sometido a prueba. [16]

29
2.5.1.3.1. Retardo de transferencia de paquetes IP (IPTD, IP packet transfer
delay)

Se define para todos los resultados paquetes satisfactorios y con errores a través
de una sección básica o un NSE. El IPTD es el tiempo (t2 – t1) que transcurre
entre la ocurrencia de dos eventos de referencia de paquetes IP correspondientes,
evento de ingreso IPRE1 en el momento t1 y evento de egreso IPRE2 en el
momento t2, siendo (t2 > t1) y (t2 – t1) ≤ Tmáx. Si el paquete se fragmenta dentro
del NSE, t2 es el momento en que se produce el evento de egreso
correspondiente final. El retardo de la transferencia de paquetes IP de extremo a
extremo es un retardo unidireccional entre el MP del SRC y el DST, como se
ilustra en la figura 3. [16]

Figura 3. Eventos de retardo de transferencia de paquetes IP. Transferencia ‘extremo a

extremo’ de un paquete IP.
Tomada de [39]

2.5.1.3.2. Variación del retardo de paquetes IP IPDV (IP Packet Delay

Varation) entre 2 puntos de extremo a extremo.

Las variaciones del retardo IP provocarán el aumento de los umbrales del

temporizador de retransmisión TCP y quizás den lugar también a que se retarden
las retransmisiones de paquetes o se retransmitan paquetes innecesariamente.
[16]

La variación del retardo de paquetes IP entre dos puntos de extremo a extremo se

define en base a las observaciones de llegadas de paquetes IP correspondientes
en los MP de ingreso y egreso (por ejemplo, MPDST, MPSRC). Dichas

30
observaciones caracterizan la variabilidad del esquema de eventos de referencia
de llegada de paquetes IP en el MP de egreso con referencia al esquema de
eventos de referencia correspondientes en el MP de ingreso. [16]

La variación del retardo de paquetes entre dos puntos (vk) para un paquete IP k
entre el SRC (source host) y el DST (destination host) es la diferencia entre el
retardo de transferencia de paquetes IP absoluto (xk) del paquete y un retardo de
transferencia de paquetes IP de referencia definido, d1, 2, entre esos mismos MP:
vk = xk – d1, 2. [16]

Figura 4.Variación del retardo de paquetes IP entre dos puntos.

Tomada de [40]

El retardo de transferencia de paquetes IP de referencia, d1, 2, entre el SRC

(source host) y el DST (destination host) es el retardo de transferencia de
paquetes IP absoluto que tiene el primer paquete IP entre esos dos MP. [16]

Valores positivos de la IPDV (IP Packet Delay Varation) entre dos puntos
corresponden a retardos de transferencia de paquetes IP superiores a los que
tiene el paquete IP de referencia; valores negativos de la IPDV (IP Packet Delay
Varation) entre dos puntos corresponden a retardos de transferencia de paquetes
IP inferiores a los que tiene el paquete IP de referencia. La distribución de las
IPDV (IP Packet Delay Varation) entre dos puntos es idéntica a la distribución de
los retardos de transferencia de paquetes IP absolutos desplazados en un valor
constante igual a d1, 2. [16]

31
2.5.1.3.3. Tasa de errores en los paquetes de protocolo Internet (IPER, IP
packet error ratio).

Es la relación entre el total de resultados paquete IP con errores y el total de

resultados transferencia de paquete IP satisfactoria más los resultados paquete IP
con errores en una población de interés (ver nota 1). [16]

Nota 1: La mayoría de los parámetros de calidad de funcionamiento se definen en

conjuntos de paquetes llamados poblaciones de interés. Para el caso extremo a
extremo, la población de interés es normalmente el conjunto total de paquetes que
se envía de un SRC (source host) a un DST. Los puntos de medición en el caso
extremo a extremo son el MP del SRC y el DST (destination host). [16]

2.5.1.3.4. Tasa de pérdida de paquetes de protocolo Internet (IPLR, IP packet

loss ratio).

Es la relación entre el total de resultados paquete IP perdido y el total de paquetes

IP transmitidos en una población de interés. [16]

2.5.2. Recomendación Y.1541

En esta recomendación se especifican los valores de calidad de funcionamiento IP

de la red (UNI-UNI) para cada uno de los parámetros de calidad de
funcionamiento definidos en la recomendación UIT-T Y.1540 [13]. Los valores de
calidad de funcionamiento específicos varían en función de la clase de QoS de la
red. En esta recomendación se definen ocho clases de QoS de red, de las cuales
dos son provisionales. Las clases de QoS de red definidas aquí tienen por objetivo
establecer las bases de los acuerdos entre los usuarios de extremo y los
proveedores de servicios de red, y entre los proveedores de servicio. Las clases
continuarán utilizándose cuando los acuerdos estáticos den paso a las peticiones
dinámicas soportadas por los protocolos de especificación de QoS. [17]

Las clases de QoS definidas aquí soportan una gama de aplicaciones

extremadamente amplia, entre las que se encuentran las siguientes: la telefonía
de conversación, las conferencias multimedia, el vídeo digital y la transferencia
interactiva de datos. [17]

En esta recomendación se presentan las clases de QoS de red necesarias para

soportar categorías QoS orientadas a los usuarios. Siendo así, esta
recomendación es coherente con el marco de trabajo general para la definición de
la calidad de los servicios de comunicaciones en la recomendación UIT-T G.1000
[19], y con las categorías QoS multimedia de usuario de extremo necesarias para

32
soportar las aplicaciones de usuario dadas en la recomendación UIT-T G.1010
[15]. [17]

2.5.2.1. Capacidad de transferencia.

Es un parámetro fundamental de QoS que tiene una influencia primordial sobre la

calidad de funcionamiento percibida por los usuarios de extremo. Muchas de las
aplicaciones de usuario tienen requisitos mínimos de capacidad, que deben
considerarse cuando se discuten los acuerdos de servicio. En la recomendación
UIT-T Y.1540 [17] no se define un parámetro para la capacidad, aunque se define
el parámetro de pérdida de paquetes. Los bits u octetos perdidos se pueden restar
del total enviado a fin de determinar provisionalmente la capacidad de la red.
Queda en estudio una definición independiente de la capacidad. [17]

En ciertos escenarios el usuario y el proveedor de servicios de red han acordado

la capacidad máxima de acceso que estará disponible para uno o más flujos de
paquetes, en una clase QoS específica (a excepción de la clase no especificada).
Un flujo de paquetes es el tráfico asociado con un tren de bits con conexión o sin
conexión determinado, que tiene el mismo computador principal de origen (SRC,
source host), computador principal de destino (DST, destination host), clase de
servicio e identificación de sesión. [17]

2.5.2.2. Discusión general de QoS.

Las definiciones de clases QoS presentadas en el tabla 1 presentan límites en la

calidad de funcionamiento de red entre las interfaces usuario-red (UNI). Mientras
que los usuarios (y las redes individuales) no excedan la especificación de
capacidad acordada o el contrato de tráfico, y se disponga de un trayecto (como
se define en la recomendación UIT-T Y.1540), los proveedores de servicio de red
debe tener la capacidad de soportar estos límites UNI a UNI durante la vida útil del
flujo.

De esta manera se definen los objetivos de calidad de funcionamiento de UNI a

UNI para los parámetros de calidad de funcionamiento que corresponden a los
eventos de referencia de transferencia de paquetes IP (IPRE, IP packet transfer
reference events). En la figura 5, los objetivos de calidad de funcionamiento de
una red UNI a UNI se aplican de la interfaz usuario-red a la interfaz usuario-red. El
trayecto de red UNI a UNI incluye el conjunto de secciones de red (NS, network
sections) y los enlaces inter-redes que proporcionan el transporte de los paquetes
IP transmitidos de la UNI, en el lado SRC, a la UNI en el lado DST. El trayecto de
referencia de la figura 5 es una adaptación del modelo de calidad de
funcionamiento Y.1540. [17]

33
 Figura 5.Trayecto de referencia UNI a UNI para los objetivos QoS de la red.
Tomada de [41]
2.5.2.3. Clases de QoS de red.

En esta recomendación Y.1541 se describen las clases de QoS de red definidas

indicando una combinación específica de límites en los valores de la calidad de
funcionamiento. De esta manera se incluyen directrices de uso de cada clase de
QoS de red.

34
 Tabla 1.Parámetros de Calidad de funcionamiento que determinan la QoS en NGN.
Tomada de [43]

Para garantizar un óptimo servicio de VoIP se debe trabajar con las siguientes
clases:

 Clase 0: Aplicaciones en tiempo real muy interactivas

Se caracterizan por ser altamente sensibles al retardo y al jitter. El retardo medio

máximo es 100 ms, el jitter debe ser menor a 50 ms, tasa de pérdidas inferior a
10−3 y la tasa de errores menor a 10−4 . Esta clase incluye aplicaciones como VoIP
y videoconferencia.

 Clase 1: Aplicaciones en tiempo real

Se caracterizan por ser sensibles al retardo y al jitter pero no requieren de

parámetros tan rígidos como la Clase 0. El retardo medio máximo es 400 ms, el
jitter debe ser menor a 50 ms, tasa de pérdidas inferior a 10−3 y la tasa de errores
menor a 10−4 . Esta clase incluye aplicaciones como VoIP y videoconferencia con
una calidad menor percibida en los extremos.

Esto de acuerdo la recomendación de la (ITU-T Recommendation Y.1541) [13]:

35
 Tabla 2. Guía para las clases de QoS sobre protocolo IP.
Tomada de [44]

En general el objetivo principal de las redes NGN es proporcionar una calidad

equivalente a la PSTN brindando servicios tradicionales de voz y otros servicios
auxiliares como fax, módem, entre otros. Por otro lado, para el caso del servicio
VoIP, se debe tener en cuenta que se tienen tres tipos diferentes de flujos de
datos: los paquetes de Voz, Señalización y Operaciones & Mantenimiento. Estos
componentes tienen diferentes necesidades de QoS las cuales, si son satisfechas
correctamente, brindarán una buena calidad en la experiencia del usuario.

2.6. ESTUDIO DE LAS RECOMENDACIONES QoS ENFOCADOS A

SERVICIOS VOZ SOBRE ACCESOS XDSL.

La voz sobre acceso xDSL permite transportar datos y voz sobre el mismo par
de cobre. Esta tecnología emplea la paquetización de la voz a diferencia de la
telefonía análoga o digital (BRI, PRI y E1) que utilizan conmutación de circuitos.

Los accesos xDSL tienen dos alternativas para la trasmisión de los paquetes voz
como VoATM y VoIP. ATM tiene unas ventajas debido a mecanismos propios del
protocolo que garantiza calidad de servicio (QoS). En el caso del protocolo IP no
proporciona garantía de QoS en su forma tradicional obligando a los operadores
de telecomunicaciones emplear mecanismos para garantizar la eficiencia del
servicio de voz.

Queda por aclarar que en los últimos años todos los servicios como datos, video y
voz se prestan sobre el mismo acceso obligando a emplear mecanismos de QoS
entre el DSLAM y el CPE obligando que los circuitos virtuales de ATM no compitan
entre sí.

36
Por lo tanto en éste documento se propone una metodología para implementar
QoS sobre accesos xDSL enfocado en los servicios de voz. Lo cierto es que no
existen recomendaciones enfocadas directamente a los servicios de voz sobre
xDSL, sino reportes técnicos de broadband forum y artículos que comentan el
manejo de la voz en estos dispositivos.

La red de acceso xDSL se ha apoyado tradicionalmente sobre arquitecturas de IP

sobre ATM (Asyncronous Transfer Mode). Sin embargo esta tecnología en años
anteriores se trabajaba sobre agregadores ATM en el acceso y en el core. Hoy día
los operadores de telecomunicaciones se han migrado a redes NGN conservando
la tecnología ATM en la última milla. Por ello, se debe analizar al detalle el
transporte de ATM en accesos xDSL e implementar mecanismos de QoS para los
multiplex servicios ofrecidos por los operadores de telecomunicaciones.

2.6.1. Transporte de ATM sobre xDSL.

Para el transporte de ATM sobre xDSL, los canales serán independientes a

cualquier velocidad de bits en un múltiplo entero de 32 kbit/s, hasta un total
máximo de la capacidad determinada por el proceso de inicio. Además, para cada
canal su tasa de bits en direcciones ascendente y descendente se puede ajustar
independientemente de las demás. [20]

2.6.2. Capa ATM.

La capa ATM es responsable por la transferencia de la información en forma de

celdas a través de la red. Para ello realiza una serie de funciones, que se
describen a continuación: Multiplexación/demultiplexación de celdas usando
los campos VPI (Virtual Path Identifier) y VCI (Virtual Channel Identifier).
Generación y extracción de cabeceras de las celdas. Esta función, presente
únicamente en los puntos de terminación ATM, tiene como objetivo la
generación/extracción de las cabeceras de las celdas, con excepción del HEC
(Header Error Check), que se procesa en la capa física. Translación de valores
VPI/VCI debido a la validez local (limitada a una interfaz) de los identificadores
(VPI/VCI). Es necesario cambiarlos en todos los nodos de conmutación. Estos
utilizan los valores VPI e VCI de entrada en cada enlace o puerto del conmutador,
para determinar los correspondientes valores de salida (VPI/VCI). Control de flujo
genérico: (GFC). El objetivo de esta función es el control de flujo desde los
usuarios a la red en la UNI, para controlar el tráfico de éstos. [21]

37
2.6.2.1. Capa de Adaptación ATM

Tiene como principal función compatibilizar y ofrecer los servicios deseados por
las capas superiores. De forma general, las funciones de la capa AAL son:

 Adaptación del servicio de usuario al modo de transporte ATM, a través de:

o Información sobre el reloj de servicio (sincronismo).

o Detección de celdas extrañas insertadas.

o Detección de celdas perdidas.

o Medios para determinar y tratar variación del atraso de celdas.

 Convertir el nivel de red ATM en transparente a la aplicación del usuario.

 Segmentación y remontaje en celdas y multiplexación.

Internamente la capa AAL está dividida en dos subcapas:

 CS (Convergence Sublayer o Capa de Convergencia), que realiza un

conjunto de funciones específicas de cada servicio.

 SAR (Segmentation and Reassembly o Segmentación y Re ensamblado),

que se ocupa de la segmentación y re ensamblado de las unidades de
datos que son mapeados en los 48 bytes fijos de carga útil de las celdas.

Debido a los diferentes requisitos exigidos por las aplicaciones (datos, voz y video)
no es posible dar a todas un tratamiento específico a través de una AAL única. Por
esa razón ITU-T definió grupos de aplicaciones, con requisitos semejantes,
basados en tres criterios:

 Relación de tiempo entre fuente y destino (puede ser una exigencia o no).

 Tasa de bits (constante o variable).

 Modo de conexión (servicios orientados a la conexión o no).

De esta manera ITU-T clasificó diferentes servicios y definió, de acuerdo con las
clases de servicios, cinco tipos de AAL (ver Figura 7).

38
  AAL 0: Representa la ausencia de funciones de la capa AAL; se utiliza para
que las aplicaciones posean acceso directo a la capa ATM al nivel de celda.

 AAL 1: Según la ITU-T 363.1 fue diseñado específicamente para transporte

de tráfico CBR (clase A) en tiempo real mediante un flujo de bits, aunque
opcionalmente se puede intercambiar información de estructura interna de
trama.

 AAL 2: Se utiliza para transporte de tráfico VBR (clase B). Según ITU-T
I.363.2, este tipo permite la transmisión eficiente de secuencias de
paquetes de corta longitud en aplicaciones sensibles al retardo.

 AAL 3/4: Según la ITU-T 363.3 efectúa los procedimientos necesarios para
suministrar servicios de clases C y D. Los tipos AAL 3 y AAL 4 fueron
combinados cuando se concluyó que los mismos procedimientos podrían
ser ejecutados para ambas clases de servicios.

 AAL 5: Según la ITU-T 363.5 efectúa los procedimientos necesarios para

suministrar servicios de las clases C y D, no obstante de forma más simple
que los procedimientos definidos para la AAL 3/4. AAL 5 es el preferido
para transportar paquetes IP o tramas Ethernet sobre redes ATM de
acuerdo a la figura 6. Además, una conexión de este tipo puede ser usada
por PPP (Point to Point Protocol) como si se tratara de un enlace punto a
punto síncrono.

Figura 6.IP sobre ATM (U-Interface)

Tomada de [45]

En la AAL 3/4 y AAL 5 la subcapa CS es dividida en:

39
  Subcapa de Convergencia Específica de Servicio (SSCS); y
 Subcapa Parte Común de Convergencia (CPCS).[20]

Figura 7.Tipos AAL

Tomada de [47]

Sin embargo, en la capa de adaptación AAL están definidos cuatro tipos de

servicios en función de los parámetros de velocidad, sincronización y conexión
que relacionan el origen con el destino. Las cuatro clases de servicio AAL se
denominan A, B, C, D y se pueden resumir de la siguiente manera:

 Clase A: Proporciona una velocidad de Tasa de bits constante (CBR), con

requerimientos de temporización extremo a extremo y orientada a conexión.
Similar al ofrecido por la conmutación de circuitos. Es adecuada para la
voz.

 Clase B: Permite una tasa de bits variable (VBR), con requerimientos de

temporización extremo a extremo y orientada a conexión. Es adecuada
para transmisión de video.

 Clase C: Permite una tasa de bits variable (VBR), sin requerimientos de

temporización extremo a extremo y orientada a conexión. Por ejemplo para
usar con Frame Relay.

 Clase D: Permite una tasa de bits variable (VBR), sin requerimientos de

temporización extremo a extremo y no orientada a conexión. Por ejemplo
para usar con IP.[21]

Por lo tanto, en la siguiente tabla 3 se resumen los diferentes servicios:

40
 Tabla 3. Servicios ofrecidos por la capa de adaptación.
Tomada de [53]

2.6.3. Manejo de Tráfico en ATM sobre xDSL.

En general, las categorías de servicios deben ser soportados por un adecuado

búfer y colas en todas las interfaces dentro de los sistemas xDSL. Además, el
nodo de acceso (DSLAM) tiene la capacidad de manejar las políticas de tráfico en
las interfaces V y U.

2.6.3.1. Arquitectura de Servicios ATM.

La arquitectura de servicios que provienen de la capa ATM consiste en las

siguientes seis categorías de servicio: [22]

 CBR Constant Bit Rate.

 Rt-VBR Real-Time Variable Bit Rate.
 Nrt-VBR Non-Real-Time Variable Bit Rate.
 UBR Unspecified Bit Rate.
 ABR Available Bit Rate.
 GFR Guaranteed Frame Rate.

Estas categorías de servicio se relacionan con las características de tráfico y

requisitos de QoS de acuerdo al comportamiento de red. Funciones como
enrutamiento, CAC (Connection Admission Control) y asignación de recursos son,
en general, una estructura diferente para cada categoría de servicio. De este
modo las categorías de servicio se distinguen por ser en tiempo real o no en
tiempo real como: [22]

 Tráfico en tiempo real: Las categorías CBR y rt-VBR se distinguen por si el

Traffic Descriptor contiene el parámetro PCR (Peak Cell Rate) o ambos
parámetros PCR y SRC (Sustainable Cell Rate). [22]

41
  Tráfico no en tiempo real: Las categorías nrt -VBR, UBR, ABR y GFR
difieren sobre la naturaleza de las garantías de servicio proporcionado por
la red y los mecanismos que se implementan en sistemas finales y redes
llevadas a cabo [22].Por lo tanto una selección de categoría de servicio
adecuado es de acuerdo a la aplicación específica. De esta manera se
comparara estas categorías en la sección 5.1.2.4.
2.6.3.2. Parámetros de QoS.

En esta sección se definen las categorías de servicio ATM utilizando los siguientes
parámetros de calidad de servicio como:

2.6.3.2.1. Peak-to-peak CDV (Peak-to-peak Cell Delay Variation o variación

del Retardo de Celda de pico a pico).
Se define como la diferencia entre el (1 - ) cuantil de CTD y el valor fijo de CTD.
Como se observa en la figura 8, el termino de pico a pico se refiere a la diferencia
entre el mejor y el peor caso de CTD, donde el peor caso es el retardo cuya
probabilidad de ser excedido es menor a siendo 10−9 un valor típico para 
[23]

Figura 8. Relación entre CDV pico a pico y la MaxCTD.

Tomada de [47]

2.6.3.2.2. MaxCTD (Maximum Cell Transfer Delay o Retardo Máximo de

Transferencia de Celda).
Se define como el tiempo transcurrido entre el evento de salida de la celda del
punto de medida 1 (habitualmente el UNI de la fuente) y el evento de la celda en el
punto de medida 2 (habitualmente el UNI del destino). El CDT se computa como la
suma de retardos de propagación y los retardos de proceso introducidos por los
elementos de la red atravesados por la conexión entre los dos puntos de medida.

42
Los valores obtenidos para el CDT deben ser interpretados en un contexto
estadístico. La figura 6 sirve de referencia para definir el CDV del pico a pico y el
MaxCTD. El retardo fijo incluye los tiempos de propagación, los tiempos de
transmisión y los componentes de retardo fijos introducidos por los conmutadores.
El CDV en cambio aparece como consecuencia de la multiplexación de
conexiones sobre el mismo puerto de salida, lo cual provoca que algunas celdas
tengan que esperar mientras que otras son transmitidas.

Así, se define el MaxCTD como él (1 - ) cuantil de CTD, donde el es el mismo

utilizado para definir CDV. [23]

2.6.3.2.3. CLR (Cell Loss Ratio o Tasa de Pérdida de Celdas).

Donde CLR es la relación entre el número de celdas perdidas y el número total de
celdas transmitidas en una conexión, es decir:

𝑁𝑜. 𝑑𝑒𝐶𝑒𝑙𝑑𝑎𝑠𝑃𝑒𝑟𝑑𝑖𝑑𝑎𝑠
𝐶𝐿𝑅 =
𝑁𝑜. 𝑡𝑜𝑡𝑎𝑙𝑑𝑒𝐶𝑒𝑙𝑑𝑎𝑠𝑇𝑟𝑎𝑛𝑠𝑚𝑖𝑡𝑖𝑑𝑎𝑠

Este parámetro debe de negociarse en cada uno de los sentidos de la conexión.

La red se compromete a garantizarlos pero solo desde el punto de vista
probabilístico y por lo tanto deben evaluarse sobre una ventana temporal
suficientemente grande. [23]

Sin embargo este retraso es la acumulación de los retrasos acumulados en cada

nodo y enlace de la red.

2.6.3.3. Parámetros de Tráfico.

El tráfico enviado por el usuario a través de las conexiones es definido por los
siguientes parámetros: [22]

 PCR (Peak Cell Rate o Tasa de Pico de Celdas): Velocidad máxima a la

cual una conexión puede generar tráfico, expresada en celdas/segundo.

 CDVT (Cell Delay Variation Tolerante o Tolerancia de Variación de Retardo

de Celdas): Tolerancia máxima del CDV, es decir, jitter máximo aceptable.

 SCR (Sustainable Cell Rate o Tasa Media de Celdas): Es la velocidad

media de transmisión (velocidad sostenible a largo plazo).

 MBS (Maximum Burst Size o Tamaño Máximo de Ráfaga): Es el número

máximo de celdas que pueden ser enviadas a la velocidad de pico.

43
  MFS (Maximum Frame Size o Tamaño Máximo de Trama): Es el número
máximo de celdas que pueden formar una trama.

 MCR (Minimum Cell Rate o Tasa Mínima de Celdas): Es la velocidad

mínima aceptable en el tráfico de celdas.

De esta manera en la figura 9 se muestra las relaciones entre los diferentes

parámetros de tráfico ATM.

Figura 9. Relación de los parámetros de tráfico ATM.

Tomada de [46]

2.6.3.4. Categorías de Servicio.

Una categoría de servicio ATM tiene como objetivo traducir un modelo de servicio
en un conjunto de procedimientos de caracterización de tráfico y gestión de
recursos que sean adecuados para un tipo de servicio, permitiendo de esta forma
la asignación eficaz de recursos por la red.

A una determinada categoría de servicio debe estar asociada una clase de QoS,
de forma que pueda ser perfectamente caracterizado el tipo de conexión que está
siendo solicitada por el usuario. Se debe resaltar, no obstante, que requisitos de
QoS específicos de un determinado servicio, son atendidos sólo en parte por la
categoría de servicio.

En el contrato de tráfico, que es negociado en el momento del establecimiento de

la conexión, la categoría de servicios es sólo uno de los puntos que son
negociados entre la red y el usuario. [21]

44
2.6.3.4.1. Velocidad de bits constante (Constant Bit RateCBR).

Es la capacidad de transferencia más simple y equivalente a los sistemas de

conmutación de circuitos tradicionales, con la salvedad de que se puede fijar la
velocidad de transmisión arbitrariamente. Supone una fuente de tráfico constante y
se define por tanto a partir del parámetro PCR (Peak Cell Rate) o velocidad de
pico. Aunque con esta capacidad de transferencia se garantiza la velocidad de
pico, la fuente de tráfico puede transmitir también a velocidades inferiores. [21]

2.6.3.4.2. Velocidad de bit variable (variable bit rate VBR)

En esta capacidad de transferencia se supone una fuente de tráfico variable y

hace falta, por tanto, más de un parámetro para definirla. En concreto se usan los
parámetros velocidad de pico (PCR), que es la máxima velocidad a la cual se
puede transmitir durante un tiempo determinado, la velocidad sostenida de celdas
o velocidad media (SCR) y la tolerancia a ráfagas (BT, Burst tolerance). [21]

2.6.3.4.3. Velocidad de bit variable para tiempo Real (Real-Time Variable Bit
Rate rt-VBR)

Esta categoría de servicio soporta aplicaciones en tiempo real, que requieren un

determinado retardo (CDT) y variación de retardo (CDV).Las conexiones rt-VBR
están caracterizadas en términos de una PCR, SCR y MBS. Se espera que
las fuentes transmitan a una velocidad que puede variar con el tiempo. Asimismo,
la fuente puede ser descrita como " ráfagas o bursty".

Esta clase de servicio puede ser empleada en aplicaciones de compresión de

video con velocidad variable. Se asume que las celdas que son retardadas más
allá del valor especificado por la CTD deben ser de valor muy poco significativo
para la aplicación. El servicio rt-VBR puede soportar multiplexación estadística de
fuentes en tiempo real. [21]
2.6.3.4.4. Velocidad de bit variable no en tiempo Real (Non-Real-Time
Variable Bit Rate nrt-VBR)

La categoría nrt-VBR soporta aplicaciones que no son en tiempo real y cuyas

características de tráfico son en ráfagas. Es caracterizada por una PCR, SCR y
MBS.

Para aquellas celdas que son transferidas de acuerdo al contrato de tráfico, se

espera una pérdida de celdas (CLR) muy baja, pero no posee un límite de retardo

45
asociado (CTD o CDV). El servicio nrt-VBR puede soportar multiplexación
estadística de conexiones. [21]
2.6.3.4.5. Tasa de bits no especificado (Unspecified Bit Rate UBR).

La categoría de servicio UBR soporta aplicaciones que no son críticas, que no

son en tiempo real, y por lo tanto, no requieren un determinado retardo o variación
de retardo. Ejemplo de tales aplicaciones son aplicaciones tradicionales de
comunicación entre computadores, tales como file transfer o e-mail. El servicio
UBR soporta un alto grado multiplexación estadística entre fuentes.

UBR no ofrece ningún servicio garantizado. No existe ningún compromiso

numérico en cuanto a garantía en pérdida de celdas (CLR) o la existencia de un
límite superior de retardo (CTD), por lo tanto, no requiere de
ningún conocimiento previo sobre las características del tráfico. Una red puedo o
no aplicar la PCR a las funciones CAC (Connection Admission Control) y UPC
(Usage Parameter Control). En el caso en que la red no haga cumplir la PCR, el
valor PCR es sólo para información. Cuando la PCR no se hace cumplir, es
todavía de ayuda el negociar la PCR, ya que esto le permite a la fuente descubrir
la limitación de ancho de banda más pequeña en el camino de la conexión. El
control de congestión en UBR puede ser realizado en capas superiores o
empleando una base extremo a extremo. [21]
2.6.3.4.6. Tasa de bits disponible (Available Bit Rate ABR).

Está diseñada para soportar aplicaciones que no pueden caracterizar

efectivamente su comportamiento de tráfico durante el establecimiento de la
conexión, pero que pueden adaptar su tráfico, bien sea incrementando o
reduciendo su velocidad de transmisión. Para esto ABR emplea un mecanismo de
control de flujo el cual soporta diversos tipos de feedback para controlar la
velocidad de la fuente en respuesta a cambios en las características de
transferencia de la capa ATM. Este feedback es transmitido hacia la fuente a
través de celdas de control específicas llamadas Resource Management Cells
(RM-cells). Aunque ningún parámetro QoS especifico es negociado, se espera que
los sistemas finales, los cuales adaptan su tráfico de acuerdo con el feedback,
experimentarán una relación de pérdidas de celdas (CLR) baja y podrán compartir
equitativamente el ancho de banda disponible de acuerdo con normas o criterios
de asignación específicos de la red.

La categoría de servicio ABR no está planificada para soportar aplicaciones en

tiempo real, por lo tanto, no requieren un determinado retardo (CTD) o variación
de retardo (CDV). A pesar de que Cell Delay Variation (CDV) no es controlado en
este servicio, las celdas admitidas no son retardadas innecesariamente.

46
El sistema final, durante el establecimiento de la conexión ABR, debe especificar a
la red dos valores:

 El máximo ancho de banda requerido, denominado PCR.

 El mínimo ancho de banda a utilizar, denominado MCR. MCR puede ser
cero. [21]
De esta manera ATM soporta diferentes clases de tráfico, se pueden ver en la
figura 10, cada clase requiere los mecanismos de control que mejor se adapten.

Figura 10. Banda ocupada por los tipos de tráfico ATM.

Tomada de [46]

2.6.4. Categoría de Servicios y Atributos de Parámetros ATM.

En la tabla 4se observa una lista de atributos de ATM (Parámetros de tráfico,

parámetros de QoS y Características de retroalimentación o feedback) y establece
si y cómo estos son compatibles con cada categoría de servicio.

47
 Tabla 4. Servicios de red ATM.
Tomada de [46]

Sin embargo en la tabla 5 proporciona ejemplos y un resumen de los parámetros

de tráfico ATM y los parámetros de calidad de servicio asociados a cada categoría
de servicio.

48
 Tabla 5. Parámetros de tráfico ATM y parámetros de calidad de servicio según la
categoría de servicio.
Tomada de [46]

2.6.5. Control de Admisión de Conexión (Connection Admission Control o

CAC)

El Control de Admisión de Conexión es el conjunto de acciones que son llevadas a

cabo por la red durante la fase de establecimiento de una conexión con el objeto
de verificar si la petición de conexión será aceptada o rechazada. Por ejemplo,
una conexión será rechazada si posee características de tráfico y calidad de
servicio que presenten peligro de congestión para la red.

Los mecanismos de control CAC pueden ser considerados la primera y principal

barrera para evitar que una red entre en congestión. En tráficos como CBR, VBR y
UBR no hay condiciones para la actuación de mecanismos reactivos, de manera
que deberán tomarse precauciones para prevenir la congestión. [21]

2.6.6. Conformidad del perfil de Tráfico (Usage/Network Parameter Control o

UPC/NPC).

Se define como el conjunto de acciones realizadas por la red para monitorear y

controlar el tráfico ofrecido en el interfaz de acceso del usuario o el proveniente de

49
otra red. De esta manera el objetivo es verificar que el perfil de tráfico es conforme
al contrato de servicio y tomar las acciones pertinentes en caso de violación del
contrato, evitando así el deterioro del QoS ofrecido al resto de conexiones. [23]

2.6.7. Prioridad de pérdida de celda (CLP: Cell loss priority).

El bit de Prioridad de pérdida de celda (CLP) es un campo de 1 bit en el
encabezado de la celda ATM que indica la prioridad relativa de la celda. Puede
utilizarse en momentos de congestión para descartar celdas con prioridad baja y
mantener las celdas con prioridad alta. Las celdas con bit 0 en CLP (CLP = 0) son
de alta prioridad y las celdas con bit 1 en CLP (CLP = 1) son de baja prioridad.

Algunos descriptores de tráfico y políticas de algoritmos sólo supervisarán las

celdas de alta prioridad y de baja prioridad. A veces, los dispositivos xDSL
monitorean ambos tipos de flujos de celdas con un identificador "CLP 0 + 1".

Los flujos de celda vigilados o supervisados, dependerá de la clase de servicio en

un circuito virtual y del descriptor de tráfico especificado en el circuito. Por lo tanto
se define 4 modos de políticas de acuerdo a la tabla 6. [24]

Tabla 6.Flujos de Monitoreo de celdas en cada modo de Política.

Tomada de [47]

2.6.7.1. Tagging basado en CLP.

Durante la congestión se puede utilizar una técnica llamada "tagging" para

cambiar el valor del bit de CLP. Dependiendo de los parámetros del contrato de
tráfico, la congestión puede causar que el dispositivo xDSL pueda cambiar el flujo
de celda CLP = 0 a CLP = 1, cambiando inmediatamente su estado de alta
prioridad a baja prioridad. Sin embargo el contrato de tráfico puede causar que la
celda pueda ser rechazada. [24]

50
2.6.7.2. Descripción del Contrato de Tráfico.
Cada circuito virtual ya sea un “Virtual Path Connection” o un “Virtual Channel
Connection” tiene un contrato de tráfico definido. Este contrato de tráfico incluye
una descripción del tipo de tráfico que utilizará el circuito, la clase de servicio
esperado en ese circuito y un descriptor de tráfico que cuantifica la tasa de celdas
permitidas.

Los descriptores de tráfico se describen en el RFC 2514 [25] y también se definen

tanto para una conexión de origen a destino y de destino a origen. Además, Es
posible que los valores del descriptor de tráfico sean diferentes en cada dirección.

Por lo tanto los parámetros PCR, SCR y MBS son combinados en 6 descriptores
de tráfico que incluyen información de los modos de ejecución y políticas.

Dado que las diferentes clases de servicio requieren de diferentes descriptores de

tráfico. Por ejemplo, el tráfico CBR no requiere ajuste de los parámetros de tráfico
de SCR o MBS. Además, los otros tipos de tráfico pueden requerir ajustes en
todos los parámetros de tráfico, sin embargo los parámetros pueden aplicarse a
celdas con CLP = 0 o flujos combinados de celdas con CLP 0 + 1 (ver anexo A).

La tabla 7 muestra el flujo de celda (s) marcadas o vigiladas por los parámetros
PCR, SCR y MBS para cada descriptor de tráfico. [24]

Tabla 7.Tráfico marcado para cada paquete del descriptor de tráfico.

Tomada de [47]

51
 3. ESTUDIO DE LAS REDES XDSL

En este capítulo se detallarán los tipos de estándares de la ITU que corresponden

con cada familia xDSL. También de explicará el tipo de conexión xDSL
relacionado al servicio de voz con los protocolos de encapsulamiento asociados.

xDSL es un término genérico para la gran variedad de tecnologías pertenecientes

a DSL (Digital Subscriber Line o Línea Digital de Suscriptor). DSL se refiere a la
tecnología usada entre el cliente y el operador, habilitando un mayor ancho de
banda de transmisión sobre las ya existentes convencionales líneas telefónicas de
cobre. xDSL utiliza mucho más ancho de banda de las líneas telefónicas de cobre
que el que se está usando actualmente para la transmisión de voz.

Aprovechando frecuencias que están por encima de las utilizadas para la telefonía
(400Hz−4KHz), xDSL puede codificar más datos alcanzando tasas de transmisión
muy altas, cosa que es imposible en el rango de frecuencias restringido para la red
telefónica. Para lograr el uso de frecuencias por arriba del espectro de la voz, el
equipo de xDSL debe ser instalado en ambos extremos del cable de cobre así
como a lo largo de toda la ruta del cable. Esto significa que, dispositivos que
limiten el ancho de banda deben ser removidos o evitados.

Una de las grandes limitantes de estas tecnologías es que por el uso del cableado
telefónico, este impone limitaciones de distancia para las transmisiones de datos
sobre esas frecuencias. A medida que la localización del cliente se aleja de la
central telefónica, la calidad de las transmisiones baja. En la actualidad, para
mantener la calidad en los servicios, se propone en los estándares una distancia
máxima de 5000 metros de distancia entre el cliente y la central telefónica.

3.1. CARACTERÍSTICAS DE xDSL

Existen gran variedad de tecnologías pertenecientes a xDSL, cada uno diseñado

con objetivos muy específicos y necesidades de mercado. Algunas de las formas
de xDSL son propietarias, otras simplemente son modelos teóricos y otros son
ampliamente usados como estándares. La mejor forma de categorizarlos es
dependiendo de los métodos de codificación que estos usan para codificar sus
datos. A continuación se mencionan algunos de los tipos de xDSL, y en la tabla
No.8 se presenta la comparación entre las tasas de transmisión de estas
tecnologías:

ADSL (Asymmetric Digital Subscriber Line), ADSL (G.lite), ADSL2, ADSL2-RE,

ADSL 2+, SHDSL (High Bit−Rate Digital Subscriber Line), VDSL (Very High
Bit−Rate DSL) y VDSL2+.

52
 Tabla 8. Comparación entres XDSL
Tomada de [37].

3.1.1. Tecnología DSL (Digital Subscriber Line)

Las tecnologías DSL (Digital Subscriber Line) utilizan diferentes frecuencias para
dividir los servicios de voz y datos a través de una línea de par de
cobre. Anteriormente, las redes telefónicas utilizan un ancho de banda
determinado para el tráfico de voz.

Las diferentes tecnologías DSL se caracterizan por la relación entre la distancia

alcanzada entre módems, velocidad, Asimetrías y simetrías entre el tráfico de
descendente (el que va desde la central hasta el usuario, ATU-C y ATU-R) y el
ascendente (en sentido contrario, ATU-R y ATU-C). Como consecuencia de estas
características, cada tipo de módem DSL se adapta preferentemente a un tipo de
aplicación o servicio.

Una ventaja principal de las tecnologías DSL es que ofrecen una

cantidad específica de ancho de banda que no varía con el número
de abonados en un área. Esto es porque este sistema funciona con independencia
para cada usuario, en cambio las tecnologías de cable e inalámbricos pueden
sufrir congestión en su acceso debido a que son sistemas de medios

53
compartidos. Esto hace que DSL sea ideal para el uso doméstico y empresarial
brindando un ancho de banda dedicado para los servicios de voz, datos y video.
3.2. CONEXIÓN BÁSICA xDSL.

La conexión del cliente (Hogar, Soho, Pymes) es un dispositivo

llamado (CPE) Customer Premises Equipment que permite el acceso a la red
del operador de telecomunicaciones. El modem CPE se conecta a un DSLAM
(Digital Subscriber Line Access Multiplexer) que está ubicado en la central offices
(CO).

El DSLAM agrega el tráfico de los diferentes clientes de datos, voz y video y lo

envía a través de un enlace ascendente de alta velocidad hacia la red de núcleo o
core de la red del operador de telecomunicaciones. En la Figura 18 se ilustra la
topología básica de la red acceso de xDSL.

Figura 11.Topología básica de la red acceso de xDSL

Tomada de [42].

3.3. VOZ SOBRE xDSL.

Esta metodología consiste en utilizar el conocimiento de las tecnología

involucradas en el acceso xDSL como la voz en la parte de ATM y en la parte
donde se paquetiza la voz (VoIP).

En la Figura 19 muestra el despliegue de la voz en la última milla por cobre con

protocolo ATM para xDSL hacia el CPE y en la figura 20 se muestra las pilas de
protocolos que se modelan en este escenario. En la arquitectura de voz sobre
ATM, el modem es un gateway que naturalmente se llama Dispositivo de
Acceso Integrado (IAD), que proporciona servicios integrados de voz y acceso a

54
datos. Este gateway o IAD tiene la posibilidad de manejar tráfico de voz y de
datos.

En el lado ATM se separa por circuitos virtuales VC´s (Virtuals Circuits) desde el
DSLAM y el CPE. La voz se maneja directamente sobre Adaptation Layer 2 o
AAL2 (ITU-T 363.2) con velocidad de bits constante (CBR) de servicio.

…………………………….. PSTN

E1 7
v

´s
v

SS
TRUNK GATEWAY o
IAD SIGNAL GATEWAY

SIG

IP
RAT
CENTRAL OFFICES
Modem xDSL

N
RED IP
CORE
VC 1: Voz over AAL1 (CBR) o
Voz over AAL2 (VBR)
DSLAM Softswitch
VC 2: Datos over AAL5 (UBR)
SWITCH AGREGATION

IPPBX

Multiplex Services Gateway

Softphone Telefono IP

Figura 12. Aarquitectura de voz sobre ATM en acceso xDSL.

En el DSLAM, el tráfico voz que va hacia el CPE se trasporta sobre protocolo de

encapsulamiento AAL1 (ITU-T 363.1) y AAL2 (ITU-T 363.2), De esta manera se
conectada a la red IP por medio del agregador. Todo el tráfico de voz que viene de
los diferentes VC´s (Virtuals Circuits) son trasportado a través de la red IP y
controlados por el softswich, en el caso de que un cliente de voz necesita llamar a
un abonado de la PSTN o viceversa este tráfico inmediatamente se trasporta por
el Gateway de Troncal y señalización.

En la figura 20 se muestra la pila de protocolo involucrados en el acceso xDSL

para el escenario de la figura 19.

55
 VOICE

IP

AAL1/AAL2

ATM

xDSL

Figura 13. Pila de protocolos acceso xDSL.

AAL1 es un protocolo cuya función principal es la emulación de circuitos, es decir,

que proporciona un servicio constante de velocidad de bits (CBR), permitiendo
lograr que AAL1 normalmente utilice las categorías de servicio ATM que especifica
el Peak Cell Rate (PCR), Cell Loss Ratio (CLR) y Cell Delay Variation (CDV)
necesarios para que soporte el servicio de voz sobre xDSL. Este flujo de celda es
independiente de la información contenida dentro de la tasa de servicio, sin
embargo el flujo continua en el circuito virtual de ATM, así no halla tráfico en el
acceso xDSL. [26]

Sin embargo el protocolo AAL1 no es recomendable utilizarlo en un backbone

ATM debido a que el flujo de tráfico siempre va ser constante así no haya ninguna
actividad en los VC´s (Virtual Circuit). Pero en una red xDSL si es importante
utilizarlo de modo constante dado que su acceso es independiente por usuario.

En el caso de AAL2 impone al protocolo una sobrecarga muy baja en los paquetes
de voz y también soporta la multiplexación de los diferentes flujos de voz en
un único VC (Virtual Circuit). Para los paquetes de voz, el protocolo AAL2 define
un encabezado que contiene un identificador que indica que el flujo al que
pertenece. De esta manera los flujos de voz se les garantizan un ancho de
banda determinado y al mismo tiempo experimentara bajos retrasos en el acceso
xDSL.

Además AAL2 se utiliza para las conexiones que se requieran trasmitir en tiempo
real, servicios de tasa de bits variables (VBR), tales como tráfico de voz con
supresión de silencio. Un paquete de voz es generalmente menor al
tamaño máximo de carga útil de una celda ATM, por lo que es ineficiente
tener una celda ATM solo para llevar un paquete de voz. Por lo tanto al trasportar
varios paquetes de voz en una misma celda ATM sería aumentar el retardo de

56
paquetización. AAL2 facilita el intercambio de una sola celda ATM entre varias
llamadas de voz. [26]

De esta manera el foro ATM identifica cuatro tipos de AAL (AAL3 y AAL4 se han
combinado), que corresponden a los diferentes tipos de tráfico que soportado. Por
lo tanto la tabla 9 muestra la relación de tipos de AAL a las categorías de servicio
ATM mostrando la donde la voz tiene el mejor uso.

57
 Tabla 9. Relación de tipos de AAL a las categorías de servicios ATM.
Tomada de [46]

3.4. MODELO DE REFERENCIA DE VOZ SOBRE XDSL.

El modelo de referencia de la figura 21 se deriva del modelo DSL Forum de

acuerdo a lo definido por los reportes técnicos TR-001 [27] y TR-012 [28]. Aunque
esta tesis se enfoca desde el bloque funcional de Access Node hasta el bloque
Custumer Premise Equipment y viceversa. [29]

Figura 14.Modelo referencia arquitectura de Voz sobre xDSL

Tomada de [45]

58
3.4.1. Definición de los bloques Funcionales del modelo de referencia de Voz
sobre xDSL.

3.4.1.1. Access Node

El nodo de acceso proporciona la agregación de varias interfaces físicas "U" de los

puertos xDSL y la suma del ancho de banda hacia la red de acceso. Este
dispositivo se refiere a un DSLAM. [29]

3.4.1.2. Network Termination

La terminación de red tiene como función de terminal la señal xDSL y entrar en las
instalaciones del cliente. [29]
3.4.1.3. Customer Premises Interworking Function.

El (CP-IWF) realiza la traslación de los métodos de señalización y portadoras

utilizadas por los equipos de telefonía existentes. [29]
3.4.1.4. Customer Premises Distribution Network.

La red de distribución cliente locales puede incluir la conmutación y/o equipos de

enrutamiento para ofrecer servicios de voz y datos a los equipos de premisa al
cliente (Customer Premises Equipment). [29]

3.4.1.5. Customer Premises Equipment

El servicio de voz se prestan a través de la customer premises distribution network

a los dispositivos del cliente como un IPPBX, IAD o terminales telefónicos. [29]

3.4.2. Definición de las interfaces funcionales del modelo de referencia de

Voz sobre xDSL.

3.4.2.1. V Interface
Esta interfaz es la que conecta el tráfico de voz al Core con protocolo IP. [29]

3.4.2.2. U Interface

Esta interfaz se conecta al Access Node con el Network Termination en cada uno
de los locales del cliente. Un ejemplo de ello es ADSL sobre ATM. [29]

59
3.4.2.3. Ta Interface

Esta interfaz es la conexión del Network Termination al (CP-IWF). Esta interfaz

puede ser una función interna cuando el Customer Premises Interworking Function
(CP-IWF) se integra con el equipo local del cliente. [29]

3.4.2.4. T Interface

Esta interfaz es la conexión del (CP-IWF) al Premises Distribution Network. [29]

3.4.2.5. R Interface

Esta interfaz conecta el bloque Premises Distribution Network al Customer

Premises Equipment. Un ejemplo es FXO, FXS o Ethernet. [29]

3.5. VoIP

3.5.1. Protocolos

IP es un protocolo que se utiliza en tecnología de conmutación de paquetes para

transportar datos a través de una red paquetes. Se forma la capa de red y
su función principal es encaminar los paquetes desde su origen hasta su destino.
Para cada paquete IP se añade un encabezado con el formato mostrado en la
figura 22.

Figura 15.Cabecera IP (IPv4).

Tomada de [42]

 El campo de Versión especifica el número de versión IP.

60
  El campo hLen específica la longitud de la cabecera en palabras de 32 bits.
 El tipo de servicio (TOS) permite que los paquetes se clasifican y se
tratan según la clase a la que pertenecen.
 El campo de Length especifica el tamaño de la carga útil en octetos.
 El tiempo de vida (TTL) es en realidad un contador que cuenta el número
de saltos que atraviesa el paquete.
 El campo protocol identifica el protocolo de capa superior, cuyo paquete se
encapsula dentro de este paquete.
 El campo Checksum proporciona una suma de comprobación en el
encabezado.
 Los campos que contienen las direcciones origen y destino del paquete se
incluyen también en la cabecera.
 El campo de Options se utiliza para proporcionar algunas opciones
adicionales y el campo del Pad se usa para hacer el tamaño del
encabezado igual a un número entero de palabras de 32 bits.

3.5.2. Protocolo UDP

(User Datagram Protocol, protocolo de datagrama de usuario) proporciona una

comunicación muy sencilla entre las aplicaciones de dos ordenadores. Al igual
que el protocolo IP, UDP es:

 No orientado a conexión: No se establece una conexión previa con el otro

extremo para transmitir un mensaje UDP. Los mensajes se envían sin más
y éstos pueden duplicarse o llegar desordenados al destino.

 No fiable: Los mensajes UDP se pueden perder o llegar dañados.

UDP utiliza el protocolo IP para transportar sus mensajes. Como vemos, no

añade ninguna mejora en la calidad de la transferencia; aunque sí incorpora los
puertos origen y destino en su formato de mensaje. Las aplicaciones (y no el
protocolo UDP) deberán programarse teniendo en cuenta que la información
puede no llegar de forma correcta.

3.5.3. Protocolo TCP

(Transmission Control Protocol, protocolo de control de transmisión) está basado

en IP que es no fiable y no orientado a conexión, y sin embargo es:

 Orientado a conexión: Es necesario establecer una conexión previa entre

las dos máquinas antes de poder transmitir ningún dato. A través de esta
conexión los datos llegarán siempre a la aplicación destino de forma
ordenada y sin duplicados. Finalmente, es necesario cerrar la conexión.

61
  Fiable: La información que envía el emisor llega de forma correcta al
destino.

Además, ofrece otras características como control de flujo, control de congestión y

confiabilidad en la entrega de paquetes en forma ordenada del emisor al receptor.
Es adecuado para las aplicaciones en tiempo real que requieren entrega
garantizada de los datos.

3.5.4. RTP

(Real-time Transport Protocol) Es un protocolo de nivel de aplicación que su

función principal es la entrega de contenido sensible al retardo, como audio
y video, a través de distintas redes. El propósito de RTP es facilitar la entrega,
seguimiento, reconstrucción, mezcla y la sincronización de los flujos de datos.
Aunque RTP no proporcionar calidad de servicio en redes IP, sus mezcladores
pueden utilizarse para facilitar distribución multimedia sobre una amplia gama de
tipos de enlaces y velocidades. Por lo tanto RTP está diseñado para utilizar los
protocolos de transporte tanto unicast y multicast. [30]
3.5.4.1. Arquitectura

RTP es un protocolo modular definido por la RFC 1889 [36]. RFC 1889 define los
campos básicos para el transporte de datos en tiempo real. Se define también
RTCP (Real-time Transport Control Protocol), cuyo propósito es proporcionar
información sobre la calidad de transmisión, información de los participantes de
sesiones RTP y permitir los servicios mínimos de control de sesión.

El Protocolo RTP es independiente del transporte y puede ser utilizado a lo largo

de diversas tecnologías de red. Los protocolos de transporte más común de RTP
son IP/UDP, ATM/AAL5 e IPX. En la Figura 23 se muestra el RTP en la pila de
protocolos. [30]

62
 Figura 16. RTP en la pila de protocolos.
Tomada de [49]

3.5.5. Protocolo SIP.

Es un protocolo de señalización perteneciente al nivel de aplicación que permite el

establecimiento de comunicaciones multimedia sobre redes IP mediante la
iniciación, modificación y finalización de sesiones. Fue desarrollado por el grupo
MMUSIC del IETF e inicialmente publicado en la RFC2543 y posteriormente
modificado en la RFC3261. [31]
3.5.5.1. Funcionamiento.

Este protocolo abierto se fundamenta en una arquitectura simple textual de

respuesta a pedidos similar al protocolo HTTP [OEA2006] y en una arquitectura
cliente – servidor en la cual el cliente inicia las llamadas y el servidor responde a
estas. Funciona en colaboración con otros protocolos como SDP, para la
comunicación de parámetros como puertos IP y códec empleados, y RTP, para el
transporte de los contenidos de voz y video. [31]

3.5.6. SIP-T (SIP Trunk).

SIP-T es un mecanismo que utiliza el protocolo SIP para facilitar la interconexión

de la PSTN con redes SIP el cual fue desarrollado por el IETF en la RFC3372
[OEA2006] y [RFC3372]. Este mecanismo surge debido a que es necesario que la
información del protocolo SS7 esté disponible durante las sesiones SIP.

La integración entre la señalización convencional y los mensajes SIP se logra

mediante la encapsulación y traducción respectivamente. En los gateways SIP-
ISUP, se encapsulan los mensajes ISUP en el protocolo SIP con el fin de
mantener la información necesaria para los diferentes servicios. Sin embargo,
algunos servidores SIP, como los Proxy Servers, no son capaces de entender
mensajes ISUP por lo que se traducen estos mensajes por sus correspondientes
dentro de la cabecera SIP. [31]

63
3.5.7. H.248.

H.248, o también llamado MEGACO, es el resultado de esfuerzos conjuntos entre

la ITU (ITU-T Recomendación H.248) y el IETF (RFC 2885) que define una
arquitectura centralizada para la gestión de sesiones y señalización de
aplicaciones multimedia entre múltiples extremos. Este estándar se desarrolló
como una extensión del protocolo MGCP haciéndolos iguales desde el punto de
vista de arquitectura ya que definen la relación entre el MGC y los MG. La
diferencia entre estos dos protocolos radica en que el H.248 soporta diferentes
redes, como IP o ATM, y tecnologías de acceso haciéndolo incompatible con el
MGCP. [31]

3.6. MODELO DE VoIP EN xDSL.

De acuerdo la arquitectura del reporte técnico TR-059 se ilustración un uso

adicional, mostrando su aplicación a la Voz sobre IP (VoIP).

3.6.1. Modelo.

La VoIP puede tener muchos modelos de servicios distintos. Además, como

protocolo de aplicación asumimos SIP, de acuerdo a la arquitectura de la figura 20
donde ilustramos el uso del servicio de VoIP en un acceso xDSL.

El servidor SIP Proxy o Sotfswitch se encuentra en el lado del operador de

telecomunicaciones cuya funcionalidad es de registrar, autenticar y de en rutar las
llamadas del usuario final. Para la conectividad a la PSTN se utiliza un Gateway
de troncal y señalización de acuerdo a la figura 24.

64
 Figura 17. Modelo de VoIP.
Tomada de [45]

3.7. ARQUITECTURA DE RED BASADA EN ETHERNET PARA

LA AGREGACIÓN DE xDSL.

Las actuales arquitecturas xDSL están son capaces de soportar altas velocidades
de bit/s para servicios que requieren QoS, multicast u otros servicios que
limitantes en el ambiente del core ATM. Con tecnología Ethernet en la agregación
de xDSL genera un mecanismo de transporte que soporta altas velocidades de
conexión basada en paquetes IP con QoS, simplificación de aprovisionamiento,
multicast y redundancias de manera eficiente.

Al igual al reporte técnico TR-059, la arquitectura que se ilustra en la Figura 25

utiliza una Broadband Network Gateway que proporcionar calidad de servicio
IP hasta el nivel de usuario.

65
 Figura 18. Arquitectura de red Ethernet basada en xDSL.
Tomada de [45]

3.7.1. Nodo de acceso.

Es el punto de agregación de la red de acceso xDSL y proporcionar las siguientes

capacidades de alto nivel:

 Debe ser capaz de poner fin a la capa ATM que viene del usuario.

 Debe tener conectividad ascendente a la red de agregación.

 ATM es compatible con xDSL (interfaz U), el nodo de acceso tiene

que desempeñar una función de inter-funcionamiento (IWF indicado en la
Figura 26) entre la capa ATM en el lado del usuario y la capa de ethernet en
el lado de la red.

 Las tramas ethernet nativas debe ser soportadas en el bucle acceso.

 Debe ser capaz de soporta QoS para los servicios de voz, datos y video.

66
 Figura 19. Interfuncionamiento de ATM a Ethernet.
Tomada de [48]

Dado que la red de agregación está basada en Ethernet el Access node y el

broadband network gateway están equipado con interfaces ethernet capaces de
virtualizar redes con VLAN tagging, esta etiqueta se define en el estándar IEEE
802.1Q. LAN VLAN tagging proporciona una agrupación de flujos de tráfico en una
VLAN con VID = X y otro flujo de tráfico con otra VLAN con VID = Y. La VLAN
tagging permite el marcado de una trama de CoS (Clase de servicio) usando 3 bits
del campo de prioridad, proporcionando así un mecanismo de clasificación de
servicio. También se utiliza para separar usuarios o servicios mediante la
asignación de un ID de VLAN diferentes para cada puerto xDSL. De esta manera
este mecanismo es de capa 2 y de cierto modo se estaría haciendo QoS en un
servicio específico.

En una arquitectura de servicios múltiples los VC´s (circuits virtuals) son

aprovisionados entre el nodo de acceso y RG (residential gateway). Los RG tiene
la posibilidad de asignar diferentes tráficos a los diferentes VC´s. En tal caso, el
tráfico generalmente es enviado sin etiqueta (untagged) al puerto correspondiente
del nodo del acceso para sí ser asignado una VLAN y darle una prioridad de
acuerdo al servicio de acuerdo a la figura 27.

67
 Figura 20.Arquitectura de múltiples VC´s.
Tomada de [45]

 Arreglos de S-Tag:

 A: Escenario donde todos los usuarios se asignan a una VLAN

común.

 B: Escenario donde cada usuario se le asigna una VLAN común

basado en un tipo de servicio.

 Notas de la figura 27:

 Los VC´s 1 y 2 se les pueden asignar diferentes marcas de

prioridad dentro de la misma VLAN o por VLAN´s separadas.

 Los VC´s 1 y 2 pueden llevar VID´s iguales o diferentes que resultan

en 1 o más VLAN´s en la interfaz V.

3.8. ARQUITECTURAS DE QoS EN IP UTILIZADOS EN xDSL.

3.8.1. IP Best Effort

Es el tipo de arquitectura que trabaja bajo el modelo del mejor esfuerzo, es decir,
se realiza la transmisión de datos utilizando los recursos disponibles y sin ofrecer
ningún tipo de prioridad o QoS. En este escenario, los distintos tipos de tráfico son

68
tratados de la misma forma en los diferentes nodos de la red empleando colas del
tipo FIFO, donde el paquete que llega primero a la cola es el primero en ser
atendido. Es por este motivo, que este modelo no es el adecuado para
aplicaciones multimedia sensibles al retardo y al jitter, como la voz o video que son
servicios de tiempo real.

A pesar de no ofrecer ningún trato especial a los paquetes transmitidos, esta

arquitectura es la que se tiene actualmente en los backbone de los operadores de
telecomunicaciones, donde la red hace lo mejor posible pero garantizando poco y,
así, se espera que se entregue la información transmitida siempre que estén
disponibles los recursos suficientes.

La ITU-T se refiere a este modelo como una arquitectura con capacidad de

transferencia del tipo mejor esfuerzo en la cual se renvían los paquetes utilizando
los recursos disponibles [31].

3.8.2. IntServ

Llamado como Integrated Services, es una arquitectura donde se garantiza la QoS

mediante la reserva recursos de red: los hosts solicitan una QoS específica a la
red para una aplicación o flujo de datos en particular y los routers envían las
solicitudes a los demás routers de la red [31].

3.8.2.1. Funcionamiento.

Para su funcionamiento, se utiliza el campo Etiqueta de Flujo de la cabecera IPv4

con el objetivo de identificar los flujos enviados a través de la red y, así, asignar
recursos a los diferentes flujos definidos.

Además, se hace uso del protocolo de reserva de recursos RSVP definido en el

RFC2205 de la IETF con el cual se reservarán recursos en cada nodo por donde
transitarán los paquetes pertenecientes al mismo flujo. La solicitud de reserva se
hace de origen a destino mediante un mensaje Path y los routers intermedios
comunican que tienen los recursos necesarios para la transferencia mediante un
mensaje Path State. Por otro lado, el destino envía un mensaje de confirmación
Resv por la misma trayectoria y los routers confirman la reserva mediante un
mensaje ResvConf.

En este modelo de QoS, se tienen dos tipos de servicio según los recursos que se
necesiten: Guaranteed Rate Service, donde los recursos se comportan como un
circuito virtual, o Controled Load Service, donde lo recursos solicitados se asignan
de manera dinámica [31].

69
3.8.3. DiffServ

Llamado como Differentiated Services, es una arquitectura que utiliza el

mecanismo de clasificación de tráfico con la finalidad de dar prioridades a los
servicios diferenciados para la provisión de QoS en redes IP. Este modelo es muy
usado actualmente debido a que tiene la capacidad de aceptar requerimientos de
diferentes aplicaciones y poder darles un trato un especial según su clasificación
[31].
3.8.3.1. Funcionamiento.

Para su funcionamiento, los routers, marcan los paquetes que pertenecen a una
determinada clase, según sus características como direcciones y/o puertos de
origen o destino, modificando el subcampo DSCP (Differentiated Service Code
Point) que se encuentra en el campo DS (Differentiated Services) de la cabecera
IP.

Asimismo, la diferenciación de servicios se realiza con la definición de

comportamientos específicos o prioridades, llamada PHB (Per-Hop Behavior),
para cada clase definida anteriormente. Al tráfico perteneciente a una misma clase
se le llama BA (Behavior Aggregate) [31].

70
4. ANÁLISIS DE LAS CARACTERÍSTICAS DEL DISPOSITIVO DE ACCESO
XDSL REFERENTE A LOS PARÁMETROS DE QOS.

En este capítulo se explicarán las características del dispositivo de acceso xDSL y

se detallará que tipo de funcionalidad de QoS aplica en la interfaz hacia el usuario.

En el análisis de cada dispositivo xDSL, los parámetros de QoS son una serie de
requisitos de servicio de red que se deben cumplir para topologías NGN con el fin
de garantizar un nivel de servicio adecuado para la transmisión de datos. Sin
embargo la calidad de servicio (QoS) permite establecer una conexión virtual
dedicada para la transmisión de voz, datos y videos a una velocidad específica y
entregarlo dentro de un marco de tiempo específico.

4.1. DSLAM MA5600

Este dispositivo DSLAM (Multiplexor de línea de acceso digital del abonado) tiene
la capacidad de manejar diferentes tarjetas xDSL y POTS (Plain Old Telephone
Service o Servicio de Telefonía Tradicional). Este equipo se encuentra ubicado en
la oficina central como indoor o en un barrio como outdoor.

Con el desarrollo de aplicaciones multimedia, la red de acceso xDSL ha venido

trabajando con múltiples servicios. Sin embargo el proveedor de comunicaciones
requiere que la red de acceso xDSL soporte varios servicios con el ánimo de
reducir el costo en la red. Por lo tanto la tecnología de calidad de servicio (QoS) es
la base importante en el suministro de servicios múltiples integrados en la última
milla. [32]

4.1.1. Especificaciones del dispositivo MA5600.

Con las crecientes necesidades en servicios de telecomunicaciones, la red de

acceso (AN) en esta caso xDSL debe proporcionar servicios integrados con gran
capacidad, alta velocidad y alta calidad (incluyendo datos, video, voz y multimedia)
de acuerdo a la figura 28. (ver anexo H)

El MA5600 tiene las siguientes especificaciones (ver anexo H):

 Este IP DSLAM soporta en el lado uplink capacidades de gigabit Ethernet

(GE) para satisfacer los requerimientos de alta velocidad de red de
telecomunicaciones de banda ancha.

71
  Como un módulo de acceso multiservicio, proporciona acceso integral para
enfrentar los requerimientos de servicios diversificados de con accesos
xDSL.
 Proporciona una calidad garantizada del servicio (QoS) enfocados a la
evolución de redes de nueva generación (NGN). [32]

Figura 21. Ejemplo de funcionalidad del MA5600.

Tomada de [33]

4.1.2. Tipos de puertos MA5600.

En la tabla 10 se observa las diversas interfaces red, servicio xDSL y de

mantenimiento para los diferentes requerimientos de red.

72
Tabla10. Interfaces del MA5600.
Tomada de [33]

73
4.1.3. Característica y funcionalidad.

El IP DSLAM MA5600 cuenta con una estructura de calidad de servicio (QoS)

donde su mecanismo modelo de QoS es DiffServ. El MA5600 IP DSLAM puede
garantizar QoS aplicación de control, renvío, administración y así sucesivamente.
De acuerdo con el análisis de las características de este dispositivo IP DSLAM y el
tráfico de red, puede haber dos puntos de congestión de tráfico en la dirección
descendente del tráfico. Por lo tanto, el MA5600 establece dos colas de QoS en la
tarjeta SCU y la tarjeta xDSL en la dirección descendente de los datos de tráfico
para tomar el control de prioridad de servicio y administración de la congestión de
tráfico. [34]

4.1.4. Información general de capacidad y solución de QoS.

Congestion Congestion
Classfication and Marking Avoidance Management

Queueing Congestion Point

Marker or
Policer DSCP written

IP Traffic ACL Diffserv

Classifier

WRED Scheduling
SCU
Backeplane bus
Congestion Point

Port
PVC
Modem
C
A Lookup
Port R
PVC
Modem

ADSL

Congestion Policing
Management

Figura 22.Implementación de QoS en dirección descendente.

Tomada de [45]

74
 Congestion Congestion Classfication and Marking
Management Avoidance

Congestion Point Marker or

Policer

DSCP written

IP Traffic CAR Diffserv

Classifier

Scheduling Queueing WRED

SCU
Backeplane bus
No Congestion

PVC
Modem
C Lookup
A
R
PVC
Modem

ADSL

Policing

Figura 23.Implementación de QoS en dirección ascendente.

Tomada de [38]

En las figuras 29 y 30 muestran la estructura de QoS del plano de re-envío de

datos del MA5600. Cuando el tráfico entra a la interfaz, el MA5600 determinará el
modo como se controlara el tráfico de acuerdo al resultado de la negociación de la
interfaz. El control del tráfico de la interfaz Ethernet en modo dúplex se resuelve a
través de transmisión “PAUSE FRAME”. En el modo half-duplex, se toma el
control mediante el modo de contrapresión. Los dos métodos pueden garantizar el
tráfico soportado de la interfaz que son tácticas para evitar congestión en la etapa
anterior.

En el proceso de QoS, el tráfico debe clasificarse para tomar un diferente proceso

de QoS con el fin de tomar diferentes tipos de tráfico.

Después de la clasificación de tráfico el MA5600 medirá, vigilará el tráfico y

posteriormente evalúa la tasa de tráfico de cierta duración (a largo plazo o corto
plazo). Cuando se produce alguna congestión, el MA5600 puede descartar,

75
marcar y degradar las operaciones de nivel de prioridad de los paquetes de
diferentes niveles.

Para garantizar los diferentes procesos de QoS (incluyendo retardo y ancho de

banda) para paquetes de distintos niveles de prioridad, el MA5600 enumera los
paquetes en distintas colas (hay 8 colas de nivel de prioridad en la tarjeta de
control principal y 4 colas de nivel de prioridad en la tarjeta xDSL). Las tácticas de
la cola son algoritmos de cola de prioridad (PQ), WRR, WRR-Max de retardo, y así
sucesivamente.

Cuando se produce la congestión, el MA5600 puede adoptar eficazmente un

mecanismo para evitar congestión y un algoritmo WRED (Weighted Random Early
Detection) para descartar paquetes selectivamente y evitar la congestión. [34]

4.1.5. Clasificación de tráfico.

La tarjeta SCU del MA5600 clasifica los datos Etherent/IP de la interfaz de

upstream y luego toma consecuente operaciones de QoS. El tráfico puede
clasificarse según el dominio 802.1P de la trama de Ethernet o el campo ToS de la
cabeza del paquete IP. De esta manera los paquetes se pueden clasificar con
información de la capa superior aplicando ACL de acuerdo a la figura 31.

80 BYTE OF ERHERNET PACKET

1 2 3 4 5 6 7 8

4 Byte

RULE MATCH Inclusive

Exclusive

Figura 24.Lista de acceso ACL.

Tomada de [38]

76
La ACL es tomada por el filtro rápido de hardware FFP en el chip LANSWITCH de
la tarjeta SCU; por lo tanto, el rendimiento de re-envío de hardware no se reducirá.
La ACL del MA5600 soporta la clasificación de tráfico según el paquete
Ethernet/IP de 80 bytes. [34]

4.1.6. Política de tráfico preciso.

El MA5600 admite la política de tráfico de acuerdo con la clasificación del tráfico.

El administrador de red puede controlar el tráfico mediante la tasa de acceso
comprometida (CAR o committed access rate) para evitar que el usuario ocupe un
ancho de banda de gran tamaño de acuerdo a la figura 32.

Token

Classification

Traffic Traffic

Token Bucket

Drop

Figura 25.Muestra de control de tráfico a través de token bucket en la MA5600.

Tomada de [38]

En primer lugar, los paquetes se clasifican y si los paquetes son de un tipo se

especifica su función de tráfico, después entra al tokens bucket para el proceso. Si
el token bucket contiene suficientes indicadores para la transmisión de paquetes,
inmediatamente pueden pasar al token bucket y transmitirlo. Si los tokens en el
bucket no cumplen con los requisitos de transmisión de paquetes, entonces serán
descartados. Así, el tráfico de paquetes de un tipo puede ser controlada. [34]

El token bucket pone los tokens en el bucket de acuerdo a la tasa establecida por
el usuario; además, la capacidad del tokens buckets se pueden establecer.
Cuando los tokens en el buckets exceden su capacidad, la cantidad de tokens no

77
aumentan. Cuando los paquetes son procesados por el tokens buckets y si hay
tokens suficientes para transmitir paquetes, rápidamente pueden ser transmitidos.
Sin embargo los tokens en el buckets no son suficientes los paquetes serán
descartados. [34]

Además de control de tráfico, la CAR puede marcar o señalar los paquetes y

establecer el nivel o modificar el nivel de prioridad de paquetes IP´s. [34]

4.1.7. Cola y mecanismo de programación.

En la figura 33 se observa que el MA5600 soporta 8 colas de prioridad en la

tarjeta principal de control y es compatible con los métodos de
programación de PQ, WRR, WRR-Max-Delay. En la figura 34 el MA5600 soporta
4 colas de prioridad en la tarjeta de servicio soportada con el método
de programación de PQ.

Queue
High_1

High_0
Classification
Medium_1

Medium_0

Ingress Traffic Normal_1

Egress Traffic

Normal_0

Low_1

Low_0

Figura 26.Programación de colas en la tarjeta principal de control.

Tomada de [38]

78
 Queue

Classification
CBR / 802.1p 6,7

RT-VBR / 802.1p 4,5

Ingress Traffic Egress Traffic

NRT-VBR / 802.1p 2,3

UBR / 802.1p 0,1

Figura 27. Programación de colas en la tarjeta servicio.

Tomada de [38]

4.1.7.1. PQ (Priority queue)

En el modo de prioridad cola los paquetes se transmiten de mayor a menor

prioridad. Así, los paquetes con mayor prioridad se transmiten primero en el
momento que haya congestión.

4.1.7.2. WRR (Weighted round robin)

En este modo se establece un valor de ponderación para cada cola (de mayor a
menor que son w7, w6, w5, w4, w3, w2, w1, w0). Valor de ponderación indica la
proporción de recursos. Así, la cola de prioridad baja obtiene un ancho de banda
determinado con la desventaja de obtener un servicio en un tiempo largo.

4.1.7.3. WRR-Max-Delay (weighted round robin maximum delay)

En este modo si el tiempo de espera de los paquetes de mayor prioridad excede

el retardo máximo, el paquete se transmite directamente.

79
5. PLANTEAMIENTO DE LA METODOLOGÍA DE QoS A USARSE EN UNA
RED NGN PARA ACCESOS XDSL.

Dentro del contexto de este capítulo, se evidenciara la necesidad de contar con

una red acceso xDSL que proporcione adecuadas prestaciones de calidad de
servicio, con la finalidad soportar diferentes servicios con estrictos mecanismos de
QoS, como la VoIP, la cuales necesitan que se garanticen ciertos anchos de
banda, retardo y jitter para su optima funcionalidad.

Para definir la metodología de QoS se realizaron una serie de planteamientos con

tres escenarios principales para el servicio de VoIP en redes xDSL, que
ejemplifican a una red de acceso xDSL formada por un segmento de red Ethernet
en el lado del agregador, lado usuario y la parte ATM entre el CPE (ADSL) y el
puerto.

Por lo tanto estos escenarios están integrados por los siguientes dispositivos:

 ZXR10 T64G de ZTE – SW capa 4 (Ver Anexo B): Equipo agregador de

capa 4 y su funcionalidad es de concentrar los tráficos de los DSLAM y
pertenece en la capa de acceso.

 DSLAM Huawei MA5600 (Ver Anexo H): Equipo DSLAM equipado con
puertos ADSL y VDSL cuya funcionalidad es interconectar los usuarios
directamente para la prestación de los diferentes servicio y se conecta
directamente al agregador ZXR10 T64G.

 MSAG ZXMSG 5200 (Ver Anexo C):Equipo DSLAM equipado con puertos
ADSL, VDSL, G.SHDSL y POTS cuya funcionalidad es interconectar los
usuarios directamente para la prestación de los diferentes servicio y se
conecta directamente al agregador ZXR10 T64G.

 2 Modem ADSL Echo Life HG520c (Ver Anexo D): Equipo Modem CPE
cuya funcionalidad es originar, encaminar y terminar una comunicación
como la voz, datos y video. Este equipo se conecta directamente a los
DSLAM ZXMSG 5200 y MA5600 a través de un puerto ADSL.

80
  Set-top-box ZXV10 B700 de ZTE. (Ver Anexo E): Equipo Modem CPE
cuya funcionalidad es terminar la comunicación de televisión (IPTV) y se
conecta directamente al Modem ADSL Echo Life HG520c.

 Generador de Tráfico D-ITG versión 2.8.0-rc1: Es una plataforma capaz

de producir tráfico de paquetes en la diferentes capas del modelo TCP/IP y
es compatible con IPv4 y IPv6.De modo que este generador se configura en
los computadores del laboratorio para la transmisión y recepción. [35]

 3 equipos de cómputo: Estos equipos de cómputo se utilizaron para las

funcionalidades de transmisión y recepción de tráfico con el D-ITG versión
2.8.0-rc1 y el otro computador se utilizo para las descargas a través de
Internet.

En los tres escenarios se pretende analizar el comportamiento de la voz sobre el

funcionamiento simultáneo de la televisión IP y el Internet. Sin embargo estos
servicios entraran a competir por el canal ATM en el momento de solicitudes
propias del usuario.

El primer escenario al que llamaremos “Escenario No 1” se muestra en la Figura

35; en él, se aplicara la primera arquitectura de Best Effort, la cual todos los
servicios entran a competir en el canal ATM. El segundo escenario al que
llamaremos “Escenario No 2” se le aplicara políticas (CAR) y el tercer escenario al
que le llamaremos “Escenario No 3” se le aplicaran políticas (CAR) y QoS con
prioridad de colas en el MA5600.

5.1. Metodología y consideraciones previas.

La metodología que se propone pretende validar el comportamiento del servicio de

voz en condiciones de estrés en el puerto lado ATM del acceso ADSL. De esta
manera se describen brevemente los pasos que se siguieron para su ejecución, de
tal forma que se tuviera un control sobre la mayoría de los factores que intervienen
en la realización de las pruebas.

81
5.1.1. Configuración de los equipos.

La configuración que se utiliza en la red de acceso xDSL con servicios triple play
son los siguientes de acuerdo con la figura 35:

Portatil trasmisor ITGSend

MSAG 020113/12
Computador de mesa

Modem ADSL HG520c

VC Voz: vpi 8 y vci 36

Vlan: 4000

T64G_2_PEÑON
Portatil Receptor ITGRec

Modem ADSL HG520c DSLAM 070105/58

T160G_PAR

Vlan:
RED IP
491
CORE
VC Voz: vpi 8 y vci 36
VC internet: vpi 2 y vci 35
VC IPTV: vpi 4 y vci 36 T64G_1_PEÑON Enrutamiento Dinámico
OSPF
T160G_SFD

Set-Top-Box
ZXV10 B700

Figura 28. Topología de laboratorio acceso ADSL.

 Para simular el tráfico de VoIP en condiciones reales se configuró la VLAN

4002 desde el DSLAM MA5600 hasta el T160G de San Fernando
(T160G_SFD), este SW Capa 4 es la frontera para ingresar al Core del
operador de telecomunicaciones desde anillo 1, también se hizo lo mismo
entre la MSAG ZXMSG 5200 hasta el T160G de Parcelaciones
(T160G_PAR), este SW Capa 4 es la frontera para ingresar al Core del
operador de telecomunicaciones desde anillo 6.

Para el lado del Core el operador tiene rutas que entienden los rangos de IP
que se configuraron en el portátil (ITGSend/ITGRec).

82
 El switch capa 4 ZXR10 T64G de ZTE es un equipo que tiene la función de
agregador de servicios y también trabaja en la capa de acceso. La conexión
física que tiene con el DSLAM MA5600 y el MSAG ZXMSG 5200 es giga
ethernet.

 El DSLAM MA5600 y el MSAG ZXMSG 5200 son equipos que concentran

puertos ADSL, VDSL y G.SHDSL entre otros. Aunque el dispositivo que se
le aplicará el estudio de la metodología es el DSLAM MA5600. Además se
tendrá en cuenta los diferentes modos de configuración de acuerdo con los
tres escenarios mencionados como:

 Normal (Escenario No. 1): Donde la VLAN de voz, internet y IPTV se

mapea al pvc correspondiente sin aplicar políticas ni QoS.

 Con políticas (Escenario No. 2): Donde la VLAN de voz, internet y

IPTV se mapea al pvc correspondiente con la condición de aplicar
políticas de ancho de banda para cada servicio, pero sin aplicar QoS.

 Con políticas y QoS (Escenario No. 3): Donde la VLAN de voz,

internet y IPTV se mapea al pvc correspondiente, se aplican las
políticas de ancho de banda y también se aplica QoS con prioridad
de colas (PQ).

 El Modem ADSL Echo Life HG520c que está instalado en el lado receptor
se configura en bridge para los tres pvc´s de servicio correspondientes al
anillo 1 del proveedor de telecomunicaciones, también se mapean los
puertos para discriminar tráfico; es decir, en un puerto Ethernet especifico
quedara habilitado el IPTV, VoIP y Internet.
Hay casos donde el pvc de internet queda en modo router debido a que hay
clientes que no tienen forma de levantar la sección PPPoE y necesita que el
modem ADSL haga esa función.

En el lado transmisor se conectará el mismo Modem ADSL Echo Life

HG520c, pero este CPE se conectara con la MSAG ZXMSG 5200 y se
configura en Bridge el PVC de voz y se mapea en los 4 puertos Ethernet.

Cabe aclarar que se requirió configurar la VLAN de voz del trasmisor como
el receptor hacia el BRAS con el objetivo de que los PC´s levantarán una
sesión PPPoE y poder sincronizarse a través de Internet con el servidor de
obuntu a través del comando:

83
 sudo ntpdate -u ntp.ubuntu.com
Este comando permitió que el reloj de cada PC quedara sincronizado para
la fidelización de los datos que nos arrojaba el receptor (ITGRec), aunque
en la sección 5.1.3 se explica lo relacionado con la sincronización.

 El Set-top-box ZXV10 B700 se configura automáticamente con un servidor

en el Data center del operador de telecomunicaciones. Este equipo en su
firmware inicial tiene para recibir una dirección IP por DHCP y de inmediato
es detectado y configurado.
El operador de telecomunicaciones tiene en su red de acceso configurado
el multicast para el servicio de IPTV.

En el caso del internet, el equipo de cómputo va hacer la PPPoE y tendrá la

función de bajar un archivo FTP con el ánimo de tener un tráfico constante en el
momento que se utilice todos los servicios.

Finalmente, el software de Medición D-ITG versión 2.8.0-rc1 analizara el tráfico de

voz generado desde el transmisor al receptor y mostrara el comportamiento del
servicio de VoIP en los tres escenarios propuesto.

5.1.2. Configuración de las rutas.

Además de las direcciones IP, el operador de telecomunicaciones tiene

establecido unas rutas en los ZXR10 T160G con que se encuentran en el core
para que exista conectividad extremo a extremo en toda la red.

5.1.3. Sincronización de equipos.

Para que las medidas de retardo y jitter que se toman en las pruebas sean válidas
y no se encontré con resultados erróneos, por ejemplo tiempos negativos en las
mediciones, es necesario que los equipos que inyectan y reciben el tráfico con el
D-ITG versión 2.8.0-rc1 estén sincronizados. Para llevar a cabo esta
sincronización se configuro la misma VLAN de voz hasta los BRAS de cada anillo,
de esta manera cada equipo de computo se autentico con una sección PPPoE.
Los computadores conectados directamente al Modem ADSL Echo Life HG520c
se sincronizaban automáticamente con este servidor mediante las utilidades
ntpdate de Linux; de esta forma nos aseguramos que en cada instante de tiempo
los equipos estén sincronizados.

84
5.1.4. Configuración de direccionamiento.

La configuración de la simulación del servicio de VoIP se requiere dirección IP

estático en el equipo de cómputo del transmisor y receptor. Estas direcciones
permite la comunicación con el switch de borde del core (ZXR10 T160G) del
operador de telecomunicaciones y después ser manejado con enrutamiento
dinámico (OSPF) y así completar la transmisión de paquete de voz, esto de
acuerdo a la figura 35.

La configuración de la PPPoE para el computador que va hacer las descargas se

hace en un equipo de cómputo window xp con login @temporales y password
prueba, esta cuenta me da una IP valida estática.

La configuración del servicio de IPTV se hace a través de unas direcciones IP

dinámicas enviadas de los router M6000 de ZTE del anillo 1 del operador de
telecomunicaciones.

5.1.5. Escenario de laboratorio.

Teniendo en cuenta que la distancia de conexión por cobre entre el Modem ADSL
Echo Life HG520c al DSLAM MA5600 lado receptor y la MSAG ZXMSG 5200
lado transmisor es muy corta. De esta manera se reduce considerablemente los
problemas de señal ruido S/N y atenuación.

Con respecto al tráfico que se va inyectar son en condiciones reales basándose en

que el tráfico de IPTV y de internet son prestados como cualquier usuario
existente. El tráfico de Voz al cual vamos analizar es controlado de acuerdo a los
escenarios planteados, dado que es el servicio de estudio en este documento.

5.1.6. Medición del ancho de banda disponible en la red xDSL.

Es importante conocer el ancho de banda que ofrece este tipo de medio de

transmisión, de tal forma que se pueda establecer un reparto de las capacidades
de dicha red entre los diferentes tipos de tráfico; además, conociendo este valor se
pueden establecer los límites de saturación de esta red de acceso.

La red de acceso xDSL que se implemento en el laboratorio fue un ADSL2plusde

acuerdo a sección 3.1.2.5. De manera que este tipo de tecnologías proporciona
diferentes anchos de banda de acuerdo a los tipos de tráficos que se valla
implementar; de esta forma podemos saber que el ancho de banda disponible en
el enlace ADSL de downstream es de 27,6 Mbps y el de upstream es 1,2 Mbps

85
para el DSLAM MA5600 (ver figura 36) y el enlace ADSL de downstream es de
27Mbps y el de upstream es 1,2 Mbps para la MSAG ZXMSG 5200 (ver figura 37).

Figura 29. Parámetro de línea del acceso ADSL en el lado receptor.

Tomada de [50]

Figura 30.Parámetro de línea del acceso ADSL en el lado transmisor.

Tomada de [51]

Posteriormente, el proveedor de comunicaciones informa que el tráfico de

downstream de IPTV es de 3.5 Kbps y de upstream de 100 Kbps para televisión
estándar y para el internet se maneja un estándar de downstream de 2 Mbps y de
upstream de 512 Kbps.

El tráfico de voz es simétrico aunque en el laboratorio se simulara un tráfico RTP

entrante que puede ocupar un ancho de banda aproximado de 100 Kbps. De esta

86
manera se puede calcular que se necesita 500Kbps de downstream en el
momento de una ocupación del 100 % de llamadas.

Por esta razón, se ha elegido una tasa de 4,6 Mbps como la máxima de
downstream y 1 Mbps de upstream estándar que maneja el operador de
telecomunicaciones, de manera que se tiene un rendimiento estable que nos
permitirá observar el impacto de los servicios en el momento que se empiece a
operar.

5.1.7. Generación de resultados

Durante cada inyección de tráfico, el D-ITG versión 2.8.0-rc1 proporciona una

funcionalidad mediante la cual se guardan archivos con información estadística
sobre los resultados, llamados archivos de “logs”. Estos archivos se almacenan en
un servidor de “logs” definido previamente en el computador conectado al Modem
ADSL Echo Life HG520c, y gracias a ello se obtiene las medidas que se van
analizar.

5.1.8. Procesamiento de medidas y resultados

La información recogida en los archivos de “logs” se visualiza mediante la misma

herramienta D-ITG versión 2.8.0-rc1 para obtener unos archivos .dat que
contienen la información sobre el caudal, el retardo, el jitter y los paquetes
perdidos, de la información enviada. Y finalmente con ayuda de Adobe Acrobat
Reader se procesan estos archivos para obtener las gráficas presentadas en la
sección de resultados.

Por tratarse de pruebas experimentales, hechas con equipos reales, se deben de

tomar en cuenta algunas consideraciones y limitaciones importantes que surgen al
momento de realizar las pruebas, las cuales se enlistan a continuación:

 Las pruebas se llevaron a cabo en un entorno de laboratorio en donde la

atenuación y la señal ruido S/N son mínimas debido a la buena calidad del
par telefónico que se utilizó. Sin embargo el broadcast de la red del
operador de telecomunicaciones podría en algún momento perturbar el
comportamiento de la red xDSL con aumento leve del ancho de banda en el
momento de la simulación del tráfico de Voz.

 Se establecen límites de ancho banda en el acceso ADSL del DSLAM

MA5600 tomando como profile una configuración global para todo los
usuarios del operador de telecomunicaciones, es decir; que esta
configuración se ajusta para todas las condiciones extremas donde no es
conveniente un aumento del profile.

87
6. CONFIGURACION DE EQUIPOS PARA VALIDACIÓN DE LA
METODOLOGÍA DE QoS A USARSE EN UNA RED NGN PARA ACCESOS
XDSL.

Dentro del contexto de este capítulo, de definirá las configuraciones en los

dispositivos de acceso para la validación de los escenarios planteados en el
capitulo 5. Con base a los datos obtenidos y el análisis de los mismos se definirá
una metodología paso a paso que permitirá que un operador de
telecomunicaciones pueda emplearla en todos los segmentos residenciales,
pymes y grandes clientes. De este modo no habría la necesidad de un acceso por
servicio, sino que tendrá un ahorro en puertos xDSL y pares telefónicos con la
instalación de múltiples servicios por un mismo acceso.

6.1. Diseño de pruebas de verificación.

Una vez establecido el proceso de toma de datos y pruebas a realizar en los

experimentos, las consideraciones previas que podrían influir en los resultados y
conocidos los escenarios de trabajo, se tiene que describir las pruebas que se
llevarán a cabo para verificar el buen funcionamiento de la propuesta.

Lo primero que se debe garantizar para que dicha propuesta funcione

adecuadamente es que los paquetes de voz hacia al lado ATM estén con prioridad
colas de acuerdo a lo estudiado en la sección 4.1.7, de tal forma puedan ser
enviados con alta prioridad desde el DSLAM hacia el usuario final. En el lado WAN
del DSLAM MA5600 hasta el switch de borde (ZXR10 T64G) no se aplicara
mecanismos de QoS debido a la alta capacidad de ancho de banda que maneja
esta interconexión física que es de giga ethernet.

Para la realización de las pruebas de validación en este proyecto será el DSLAM

MA5600 quien de la prioridad de los paquetes. La correcta priorización de los
paquetes se verificó con la herramienta D-ITG versión 2.8.0-rc1 mediante análisis
de comparativos de los resultados obtenidos y los datos de la recomendación
Y.1541 de la tabla 1.

En la prueba del escenario No 1. Se utiliza el método de Best Effort para el tráfico

de voz con un ancho de banda de bajada de 4,6 Mbps y 1 Mbps de subida. De
esta manera la parametrización de los descriptores de tráfico y categoría de

88
servicio lo visualizamos en la tabla 11 y las tablas de tráfico configuradas en el
anexo F.

Tabla 11. Propuesta de Best Effort para el tráfico del escenario No. 1.

Descriptor de Categoría CAR PCR SCR MBS Tipo de

VPI/VCI VLAN
Tráfico de Servicio (Kbps) (Kbps) (Kbps) (Kbps) tráfico

NoTrafficDescriptor UBR 8/36 4002 Off N/A N/A N/A Voz

NoTrafficDescriptor UBR 2/35 1723 Off N/A N/A N/A Internet

NoTrafficDescriptor UBR 4/36 1001 Off N/A N/A N/A IPTV

Basándose en la tabla 11, los descriptores de tráficos que se visualizan están

relacionados directamente con la categoría de servicio, dado que el descriptor No
Traffic Descriptor se asigna automáticamente. El VPI y VCI son parámetros
establecidos por el operador de telecomunicaciones para identificar los diferentes
servicios. Además las VLAN´s se mapean con los circuitos virtuales 8/36, 2/35 y
4/36. El CAR, PCR, SCR y MBS son parámetros que se configuran de acuerdo al
descriptor de tráfico, pero en este caso no se están parame trizados debido a que
la categoría de servicio UBR no los utiliza, esto de acuerdo a la sección 2.6.3.4.5.

Para el caso del escenario No. 2 se utilizará el método de políticas de ancho de

banda CAR para los paquetes de voz. De igual modo los demás tráficos como el
ancho de banda de bajada y subida seguirán igual a los utilizados en el escenario
No. 1 de acuerdo a la tabla 12 y el anexo F.

Tabla 12. Propuesta de políticas de ancho de banda CAR del escenario No. 2.

Categoría
Descriptor de CAR PCR SCR MBS Tipo de
de VPI/VCI VLAN
Tráfico (Kbps) (Kbps) (Kbps) (Kbps) tráfico
Servicio

NoClpNoScr UBR 8/36 4002 512 N/A N/A N/A Voz

NoTrafficDescriptor UBR 2/35 1723 Off N/A N/A N/A Internet

NoTrafficDescriptor UBR 4/36 1001 Off N/A N/A N/A IPTV

Para la prueba en el escenario No. 3 se utilizará el método de programación

de PQ o prioridad de colas en los paquetes de voz de acuerdo a la
parametrización de los descriptores de tráfico (anexo F) y teniendo en cuenta lo

89
comentado en la sección 3.3 donde los protocolos de encapsulamiento
AAL1/AAL2 son apropiados para el manejo adecuado de la voz en una red ATM,
aunque para los accesos xDSL es recomendable utilizar AAL1 que es su defecto
utiliza la categoría de servicio Constant Bit Rate(CBR).

Basándose en la tabla 13 aplicamos para el servicio de voz sobre el acceso xDSL

el concepto del RFC 2514 donde se explica que tipo de descriptores de tráfico se
aplica en la categoría de servicio CBR. Paralelamente se configura en la tabla de
tráfico una política de ancho de banda CAR para el servicio de voz.

Tabla 13. Propuesta de PQ o prioridad de colas de tráfico del escenario No. 3.

Categoría
Descriptor de CAR PCR SCR MBS Tipo de
de VPI/VCI VLAN
Tráfico (Kbps) (Kbps) (Kbps) (Kbps) tráfico
Servicio

ClpNoTaggingNoScr CBR 8/36 4002 600 512 N/A N/A Voz

ClpTaggingNoScr CBR 8/36 4002 600 512 N/A N/A Voz

NoTrafficDescriptor UBR 2/35 1723 off N/A N/A N/A Internet

NoTrafficDescriptor UBR 4/36 1001 off N/A N/A N/A IPTV

En cuanto a la generación de tráfico, las 5 llamadas simultáneas de VoIP se han

generado en el D-ITG versión 2.8.0-rc1con paquetes RTP de 96 Kbps de acuerdo
al códec G.711 utilizado comúnmente en conmutación de circuitos. El protocolo
manejado para cada llamada de voz es UTP con una duración de 60 segundos
para todo el muestreo de las llamadas, esto de acuerdo a la figura 38. La
inyección de flujos múltiples con dicha herramienta se realiza mediante el modo
grafico itggui-092 propio de D-ITG y su activación se hace a través del comando
java –jar ITGGUI.jar en la consola de Ubuntu.

90
 Figura 31. Parámetro de flujo de VoIP en D-ITG.

En la ventana de editar flujo (Edit Flow) se describe que tipo de flujo se va trabajar
y también que tipo de medida (Meter) se realiza en este caso (One-Way-Delay),
Esto indica que el tráfico va en un solo sentido, aunque para la voz este sistema
solo deja paramé trizar de esta manera. En las opciones de cabecera (Header
Option) se indica la IP destino y que tipo de protocolo de transporte se utilizará. El
sistema asigna el puerto lógico consecutivamente de acuerdo a los cinco flujos de
voz.

De esta manera el tiempo de duración de las llamadas son de 60 segundos

simultáneas y con códec G.711 a un ancho de banda de 96.1 Kbps por llamada
individual.

Sin embargo las características de cada uno de los flujos se simulan de acuerdo al
ejemplo que se visualiza en la figura 39.

91
 Figura 32. Parámetro de Multiflujo de VoIP en D-ITG.

Finalmente, el caso que interesa abordar es cuando cualquiera de los tipos de

tráfico o varios de ellos a la vez saturan la red de acceso impidiendo que otros
flujos puedan ser cursados y/o degradando la QoS de los flujos que están siendo
cursados en el momento de la congestión. Es por ello, que las pruebas de
verificación de esta propuesta se realizarán enfocándonos en los casos de
saturación de la red de acceso xDSL.

92
6.1.1. Pruebas sin calidad de servicio (Escenario No. 1).

La finalidad de las pruebas sin QoS en la red de acceso xDSL es tomar una
referencia con la que compara los diferentes flujos y cuáles de estos tiene mayor
peso en el momento de alto tráfico.

Para lograr que la red xDSL funcione sin ningún mecanismo de QoS, se realizó la
siguiente acción: aumentar el ancho de banda entre el puerto ADSL y el modem
CPE. Sin embargo, esta acción no es la ideal ya que depende de la calidad del par
telefónico.

6.1.2. Pruebas con políticas (CAR) y sin calidad de servicio (Escenario No.
2).

La finalidad de las pruebas con políticas de tráfico es garantizar un ancho de

banda determinado por cada servicio. De esta manera se certifica el tráfico de
downstream y upstream por cada circuito virtual.

Por lo tanto con esta práctica no se garantiza en su totalidad el tráfico de voz, ya

que el ancho de banda total de upstream es de 1 Mbps y debe ser compartido con
los otros flujos, por eso es importante implementar QoS para el control de flujo.

6.1.3. Pruebas con calidad de servicio (Escenario No. 3).

Las pruebas descritas en este apartado representan la forma en la que se validará

el funcionamiento de la propuesta de sugerir un mecanismo fácil de configurar y
eficiente en el tratamiento del tráfico de voz. Una vez que se hayan realizado las
pruebas sin QoS y con políticas de ancho de banda CAR, ahora se configurará lo
propuesto en la sección 6.1 en el puerta ADSL del DSLAM MA5600, para que se
pueda verificar la capacidad que tiene esta implementación de diferenciar y
priorizar el tráfico de voz, de tal forma que la calidad de servicio (QoS) en el
segmento de red xDSL no se pierda en la última milla entre el puerto ADSL y el
CPE y viceversa.

Todas las pruebas se realizarán con ayuda del D-ITG, el cual se encargará de
transmitir y recibir el tráfico generado, y realizar y almacenar las medidas que
guardará en los archivos de logs, para posteriormente procesarlos y obtener los
resultados correspondientes.

93
7. METODOLOGÍA SUGERIDA PARA EL OPERADOR DE
TELECOMUNICACIONES.

Lo que muestra la tabla 18 son los resultados comparativos entre los diferentes
escenarios implementados que permiten desarrollar la metodología, dado que se
visualiza los principales elementos para la implementación de QoS en una red
xDSL para el servicio de VoIP.

Las necesidades de QoS de los usuarios/clientes es el punto de partida y éstas

son aplicadas por el proveedor del servicio. Éstos a su vez son traducidos a
parámetros de funcionamiento relacionados con el servicio contratado y
parámetros de línea actuales de S/N (señal/ruido) y la atenuación entre el puerto
xDSL y el CPE.

El funcionamiento de QoS en el puerto xDSL depende de que tipo de prioridades

se van aplicar en la metodología. Por lo tanto el punto de estudio de esta tesis se
enfocó en el manejo que de la voz y como el operador de telecomunicaciones
puede enfrentar este tipo situaciones cuando en un mismo medio cobre se tenga 2
o 3 servicios simultáneos.

Sin embargo esto es comparado con la cantidad de reclamos que sufre un

operador de telecomunicaciones cuando todos sus accesos están en modo Best
Effort por la sencillez de operar estos servicios. Hoy día la prestación de servicios
de VoIP se ha incrementando de tal forma que algunas tecnología como las líneas
análogas, E1 y PRI son remplazados por líneas H.248, SIP y también por SIP –
TRUNK.

La metodología comprende de varios pasos que se derivan de un marco

especifico del servicio de VoIP, también se identificó criterios particulares de
calidad de servicio para este tipo de accesos xDSL como las categorías de
servicios (ver sección 2.6.3.4) y las necesidades de QoS actuales de los usuarios.

7.1. Descripción de la metodología.

En esta descripción se explicará paso a paso la metodología que se implemento

en el escenario No. 3, que fue el escenario en el cual se obtuvieron mejores
resultados de los parámetros de QoS, para el servicio de VoIP en un acceso
xDSL.

94
Paso # 1:

Se debe crear la VLAN del servicio y luego se coloca en modo Tagged en la

interfaz Uplink que interconecta al switch agregador. Este puerto Uplink en general
está en modo TRUNK para la conexión de multiplex VLAN´s de servicios.

En la Interfaz xDSL se configura en modo UnTagged o modo Access.

Paso # 2:

Después de la configuración del paso # 1 en la interfaz xDSL se procede con el

mapeo de los circuitos virtuales VPI y VCI a la VLAN del servicio. Esta
configuración se hace directamente en la interfaz. A partir de la configuración
anterior se debe tener en cuenta que el VPI y VCI queden activos.

La recomendación técnica para este paso es que el operador de

telecomunicaciones debe dejar en modo disable los PVC´s (Path Virtual Circuit)
que no estén mapeados a las VLAN´s del servicio. Se trata desde luego de
garantizar que no se transmitan tráficos indeseados al acceso xDSL.

Paso # 3:

Este paso es de gran importancia para las capacidades de ancho de banda del
acceso xDSL. El operador de telecomunicaciones antes de crear el profile debe
analizar que tipo de servicio contrato del usuario, por ejemplo: cantidad de líneas,
ancho de banda del internet y el tipo plan de televisión (básico/estándar o
Premium (High Definition). Teniendo en cuenta lo anterior se procede con la
creación del profile para el puerto xDSL, aunque esta configuración varía de
acuerdo al tipo de xDSL como ADSL 2 plus, VDSL y VDSL 2 plus, dado que esta
familia de accesos xDSL maneja anchos de bandas distintos.

Paso # 4:

Basándose en el paso anterior se debe asignar el profile en la interfaz xDSL. Esto

se hace en modo de configuración del dispositivo y después ingresar en el
puertoxDSL.

Para rectificar el funcionamiento del profile se debe instalar el Modem xDSL en el

usuario y observar que ancho de banda esta el Downstream y Upstream, esto de
acuerdo a la sección 5.1.6. Cabe señalar que estos parámetros pueden cambiar
por la distancia, Señal a ruido (S/N) y la atenuación.

95
Paso # 5:

En este paso se debe configurar las tablas de tráfico para el servicio de VoIP. El
operador de telecomunicaciones debe tener en cuenta que ancho de banda va
asignar para la VoIP, esto de acuerdo a la cantidad de líneas que el usuario
contrato. Paralelamente se fijan la categoría de servicio como CBR (Constant Bit
Rate) y rt-VBR (Real-Time Variable Bit Rate) de acuerdo a la necesidad del
cliente. De igual modo se configura los descriptores de tráfico con una categoría
de servicio específica y el tipo de prioridad de 0 a 7.

Paso # 6:

Después de la configuración de las tablas de tráfico del paso # 5 se asigna a cada

circuito virtual el traffic table o consecutivo (index) que fijo el DSLAM del operador
de telecomunicaciones. Cabe señalar que en una misma interfaz xDSL se pueden
determinar diferentes tablas de tráfico por servicio con la posibilidad de manejar
prioridades de colas de acuerdo a la sección 4.1.7.

De acuerdo a la metodología anterior se tomo como referencia el DSLAM MA5600

para aplicar los pasos sugeridos en la prestación QoS en un acceso xDSL:

 Se crea la Vlan de Voz con el siguiente comando (Paso 1):

PENO_5600_0701 (config) #vlan 4002smart

 Se crea un profile de acuerdo a la necesidad del servicio en la interfaz

ADSL (Paso 3):

PENO_5600_0701(confer)# adsl line-profile add 4

Do you want to name the profile (y/n) [n]:y
Please input profile name: PINT004M
Please choose default value type 0-adsl 1-adsl2+ (0~1) [0]:1
Will you set basic configuration for modem? (y/n)[n]:y
Trellis mode 0-disable 1-enable (0~1) [1]:
Downstream channel bit swap 0-disable 1-enable (0~1) [0]:1
Upstream channel bit swap 0-disable 1-enable (0~1) [0]:1
Please select channel mode 0-interleaved 1-fast (0~1) [0]:
Will you set interleaved delay? (y/n)[n]:y
Maximum downstream interleaved delay(0~255 ms) [14]:
Maximum upstream interleaved delay(0~255 ms) [14]:
Please select form of transmit rate adaptation in downstream:

96
 0-fixed 1-adaptAtStartup (0~1) [1]:
Will you set SNR margin for modem? (y/n)[n]:y
Target SNR margin in downstream(0~15 dB) [14]:
Minimum SNR margin in downstream (0~6 dB) [0]:
Maximum SNR margin in downstream (6~31 dB) [41]:
Target SNR margin in upstream (0~15 dB) [14]:
Minimum SNR margin in upstream (0~6 dB) [0]:
Maximum SNR margin in upstream (6~31 dB) [41]:
Will you set parameters for rate? (y/n)[n]:y
Minimum transmit rate in downstream (32~8160 Kbps) [18]:18
Maximum transmit rate in downstream (32~32000 Kbps) [24544]:4608
Minimum transmit rate in upstream (32~896 Kbps) [18]:
Maximum transmit rate in upstream (32~896 Kbps) [600]:1024

 Se busca los profile configurados en el DSLAM con el siguiente comando,

esto de acuerdo a la necesidad del servicio contratado y la distancia entre
la interfaz ADSL y el CPE (Paso 4):

 Después de haber asignado el profile específico se toma como referencia el

profile index para la configuración en el puerto ADSL (Paso 4):

97
 PENO_5600_0701(config)#interface adsl 0/5
PENO_5600_0701(config-if-adsl-0/5)#activate 58 profile-index 4

 Se configura las tablas de tráfico de acuerdo al servicio (Paso 5):

 Internet:
En esta tabla de tráfico por defecto se asigna la categoría de servicio
UBR (ver anexo F) y se configura con prioridad 1.

PENO_5600_0701(config)#traffic table index 90 ip car off priority 1

priority-policy pvc-Setting

 IPTV:
En esta tabla de tráfico por defecto se asigna la categoría de servicio
UBR (ver anexo F) y se configura con prioridad 3.

PENO_5600_0701(config)#traffic table index 91 ip car off priority 3

priority-policy pvc-Setting

 VoIP:
En esta tabla se configura el descriptor de tráfico
clpnoTaggingNoScrque indica CLP = 0 + 1 y CLP = 0. Sin embargo
𝑃𝐶𝑅0 no tagging ningún paquete a baja prioridad, sino que su flujo pasa
inmediatamente al sumador de CLP = 1 y CLP = 0 (ver anexo A).

PENO_5600_0701(config)#traffic table atm srvcategory cbr tdtype

clpnoTaggingNoScr clp01Pcr 512 clp0Pcr 496 priority 7 priority-
policy pvc-Setting

En esta tabla se configura el descriptor de tráfico clpTaggingNoScr que

indica CLP = 0 + 1 y CLP = 0. Sin embargo 𝑃𝐶𝑅0 se tagging el paquete,
es decir; que algunos paquetes cambia de alta prioridad a baja prioridad
y después se suma con los otros tráficos de baja prioridad (ver anexo A).
De esta manera en la salida del flujo de voz se suman los paquetes de
baja y alta prioridad en 𝑃𝐶𝑅0+1(ver anexo A).

PENO_5600_0701(config)#traffic table atm srvcategory cbr tdtype

ClpTaggingNoScr clp01Pcr 512 clp0Pcr 496 priority 7 priority-policy
pvc-Setting

98
  Después de haber configurado las tablas de tráfico para cada servicio se
procede en hacer las agregaciones en el circuito virtual (Paso 6):

 Internet:

PENO_5600_0701 (config) # service-port vlan 1723 ADSL 0/5/58 vpi 2

vci 35 rx-cttr 90 tx-cttr 90
Con este comando se mapea la VLAN 1723 al PVC 2/35, ahí mismo se le
asigna la tabla de tráfico de bajada y subida.

 IPTV

PENO_5600_0701 (config) # service-port vlan 1001 ADSL 0/5/58 vpi

4 vci 36 rx-cttr 91 tx-cttr 91
Con este comando se mapea la VLAN 1001 al PVC 4/36, ahí mismo se le
asigna la tabla de tráfico de bajada y subida.

 VoIP:

PENO_5600_0701 (config) # service-port vlan 4002 ADSL 0/5/58 vpi

8 vci 36 rx-cttr 43 tx-cttr 43

PENO_5600_0701 (config) # service-port vlan 4002 ADSL 0/5/58 vpi

8 vci 36 rx-cttr 45 tx-cttr 45
Con este comando se mapea la VLAN 4002 al PVC 8/36, ahí mismo se le
asigna la tabla de tráfico de bajada y subida.

Para mayor entendimiento de los comandos se explica algunos parámetros

utilizados:

 Index: Es usado para identificar el tipo de tráfico con el que vamos a

trabajar. Si este no es especificado al momento de la configuración, el
sistema automáticamente le asigna el valor más pequeño. Rango: 0 – 511.

 Ip car: Indica la tasa de acceso permitida (Committed Access Rate). Rango:

64 – 102400. Unidades: Kbps.

 Priority: Usada para configurar la prioridad, con rangos que van desde 0 a
6. Cuanto mayor sea el valor de la prioridad, mayor es la prioridad.

99
  Priority-policy: Indica la política de la prioridad, esta incluye: Pvc-Setting y
Tag-in-Package.

 Tag-in-Package: Realiza la programación basado en el valor de la

etiqueta. El sistema realiza la programación basado en la prioridad
802.1p del paquete.
 Pvc-Setting: Realiza la programación basado en el valor de la
prioridad.

Para la configuración del service-port en el IPDSLAM MA5600, se caso se utiliza

un ADSL:

En el modo config, ingresamos el siguiente comando, ejemplo:

PENO_5600_0701 (config) # service-port vlan 4002 ADSL 0/5/58 vpi 8

vci 36 rx-cttr 45 tx-cttr 45

 VLAN: hace relación a la VLAN de servicio que cada tarjeta tiene asignada.

 ADSL: es el tipo de puerto desde ADSL hasta SHDSL pasando por VDSL,
ATM, E3, etc…

 F / S / P: Hace referencia al frame 0, slot 5 y puerto 58, para el puerto de

la prueba.

 VPI - VCI: Los valores dependen del servicio a configurar:

 Internet: VPI: 2 VCI: 35

 IPTV: VPI: 4 VCI: 36
 VoIP: VPI: 8 VCI: 36

 SINGLE-SERVICE: Cuando el puerto es un solo PVC para un solo servicio.

 RX-CTTR 45 TX-CTTR 45: Indica los valores de tráfico en las direcciones

de entrada y salida

100
8. ANÁLISIS DE RESULTADOS DE LA IMPLEMENTACIÓN DEL
LABORATORIO.
En esta sección se presentan y se analizan los resultados derivados del uso de la
red de acceso xDSL propuesta sobre los diferentes escenarios que se han
descrito en el apartado anterior.

Se comenzará con el análisis de los casos que se realizaron en el Escenario No.1,

donde sólo se aplica la misma categoría de servicio en la tabla de tráfico para los
3 servicios (ver anexo F), las cuales se experimentar una competencia entre los
tráficos de los circuitos virtuales del lado ATM, y posteriormente se presentarán
escenarios en donde existen dos métodos distinto de manejar el tráfico del lado de
la red acceso xDSL.

Para poder obtener información relevante en la provisión de QoS en la red xDSL,

se analizó el comportamiento de los escenarios 1 y 2 para determinar parámetros
importantes que se deben tener en cuenta cuando se habla de QoS: el caudal, el
retardo, el jitter y los paquetes perdidos, cuyos valores se comparan con los
recomendados por la ITU Y.1541 y por eso, las categorías y descriptores de tráfico
presentadas en la Capítulo 2 y el anexo A son fundamentales para el cumplimiento
de la norma.

8.1. Pruebas Escenario No. 1.

Se comenzará trabajando con el Escenario No. 1, que es el más sencillo en el

sentido de que sólo se configurará las tablas de tráfico con categoría de servicio
UBR, es decir; que no se tendrá ninguna prioridad para los servicios de voz, datos
y video. El ancho de banda asignado entre la tarjeta ADSL y el CPE tendrá
congestión total en el momento en que estos servicios entren a competir por el
canal. Por lo tanto las tablas de tráfico se aplican tanto para el tráfico de bajada y
de subida como se observa en los siguientes comandos:

 service-port vlan 4002 ADSL 0/5/58 vpi 8 vci 36 rx-cttr 70 tx-cttr 70

 service-port vlan 1723 ADSL 0/5/58 vpi 2 vci 35 rx-cttr 90 tx-cttr 90
 service-port vlan 1001 ADSL 0/5/58 vpi 4 vci 36 rx-cttr 91 tx-cttr 91
Podemos observar cómo se aplica estos comandos en la interfaz ADSL:

101
La prueba propuesta para este escenario se muestra en la tabla 14 y anexo G.
Cabe mencionar, que esta propuesta de reparto entre los flujos de voz, Internet y
televisión, es simplemente para realizar las pruebas y ver el efecto que causa el
tráfico de voz en el momento que entra a competir por el canal. Esta simulación se
realizó teniendo en cuenta que el proveedor de telecomunicaciones no ha
empleado métodos más prácticos para atender las necesidades de los usuarios y
la capacidad medida en la red de acceso xDSL.

Por lo tanto se puede observar que ninguna llamada cumplió con los parámetros
establecidos por la recomendación Y.1541 en la que se dice que la clase 0 y 1 son
los datos más apropiados para el cumplimiento de calidad del servicio de voz.

Tabla 14.Análisis de tráfico de voz en el acceso xDSL con Best Effort.

Uno de los parámetros importantes que debemos tener en cuenta en esta tabla 14
es que se probó 2 veces las 5 llamadas simultáneas con el generador de tráfico D-
ITG y se observó que la primera tiene igual de pérdidas de paquetes, pero la
diferencia en que la segunda se sobrepasa del estándar, esto a causa que se
utilice un canal básico de televisión de 3,5 Mbps y el otro con la parrilla de canales
de 4,2 Mbps. De esta manera observamos que las diferentes peticiones del
usuario de IPTV pueden variar las medidas y el servicio de voz de manera
extrema.

De igual modo podemos detallar un poco más este tráfico con las siguientes
graficas 40 y 41:

102
Figura 33.Análisis Bitrate de 5 llamadas con canal básico (IPTV) e Internet en D-ITG.

Figura 34.Análisis Bitrate de 5 llamadas con parrilla (IPTV) e Internet en D-ITG.

103
En la figura 40 y 41 se observa el Bitrate (ancho de banda) de cada llamada con
su color correspondiente, es decir; que cada línea de color significa un ancho de
banda de ocupación de una llamada especifica. Sin embargo el color amarillo
representa la suma total de los anchos de banda, la cual puede visualizarse en la
decodificación del .log del anexo G. El ancho de banda de la figura 40 a diferencia
de la figura 41 muestra que los flujos tuvieron un comportamiento paralelo en todo
el tiempo que duraron las 5 llamadas simultáneas, pero en la figura 41 se puede
observar que el Bitrate de cada llamada empieza en tiempos diferentes y finaliza
por fuera del rango de los 60 segundos. Por lo tanto esto representaría perdidas
de paquetes como sucede en la figura 47.

De la misma manera el delay de las figuras 42 y 43 estuvieron por encima de los

valores de las clases 0 y 1 con resultados de 3848 ms y 6676,6 ms (ver anexo G).
Esto se representa en la línea amarilla como la suma de delay de cada llamada.
No obstante en la figura 42los parámetros tiene un comportamiento muy parecido
en cada llamada, aunque se observa que durante en el tiempo de los 60 segundos
aumenta este valor de delay. Por otra parte en la figura 43 muestra una variedad
en el tiempo con respecto a una llamada con otra, debido al extremo que enfrento
las 5 llamadas simultaneas cuando se utilizó la parrilla de canales de IPTV. Este
canal tiene un ancho de banda de 4,2 Mbps en el momento de su uso y al mismo
tiempo funcionando el Internet y la VoIP con saturación completa en el acceso
ADSL del espectro de bajada.

En conclusión esto se representa en un mal servicio VoIP hacia el usuario, aunque

de la misma manera la televisión y el internet presentan el mismo problema visual
con respecto a los datos adquiridos por la herramienta D-ITG.

Se observó como fue el comportamiento del delay en la figura 42 y 43:

104
Figura 35.Análisis delay de 5 llamadas con canal básico (IPTV) e Internet en D-ITG.

Figura 36.Análisis delay de 5 llamadas con canal parrilla (IPTV) e Internet en D-ITG.

105
Con respecto al jitter no se obtuvo ninguna variación de retardo por encima de los
5 ms debido a que la topología del core y de los anillos de acceso del operador de
telecomunicaciones maneja solamente el 10% de su capacidad. De manera que
ningún paquete sufrió ninguna variación en la comunicación de extremo a
extremo. Entre tanto la figura 44 y 45 si presenta una diferencia en el
comportamiento en el tiempo de la misma manera como se presentó en las
graficas de Bitrate y el delay.

Cabe concluir que el IPDV o Jitter del escenario No. 1 no tendría consecuencias
en la prestación del servicio de VoIP.

Figura 37. Análisis jitter de 5 llamadas con canal básico (IPTV) e Internet en D-ITG.

106
 Figura 38. Análisis jitter de 5 llamadas con canal parrilla (IPTV) e Internet en D-ITG.

En la figura 46 y 47 se observa cómo se comporta en el tiempo las 5 llamadas

simultáneas donde la figura 46 muestra que la perdida de paquetes se presenta en
la finalización de las llamadas, al contrario sucede en la figura 47 donde todo el
tiempo del eje horizontal se pierde paquetes. Podemos decir que el Packet Loss
se presentó en las dos pruebas del escenario No.1, sin embargo en la que utilizó
un canal básico en IPTV e Internet tuvo un porcentaje de pérdidas del 0.28 %,
cumpliendo con la recomendación Y.1541. A diferencia con la parrilla de canales
de IPTV e Internet presento pérdidas de 19,63%.

Por lo tanto se puede decir que el servicio de voz empezó a tener efectos de
retardo y pérdidas de paquetes en el momento de saturación extrema en el puerto
ADSL del DSLAM MA5600.

107
 Figura 39.Análisis packet loss de 5 llamadas con canal parrilla (IPTV) e Internet en D-
ITG.

Figura 40.Análisis packet loss de 5 llamadas con canal parrilla (IPTV) e Internet en D-
ITG.

108
Lo analizado es que la prueba en modo de Best Effort en el acceso ADSL del
DSLAM MA5600 demostró que el servicio de VoIP se vio muy afectado en el
momento que se utilizo IPTV e Internet, dado que el caudal ATM con múltiples
flujos en diferentes circuitos virtuales tiende a competir por el canal. Por lo tanto es
de gran importancia activar mecanismos fiables que garantice que los paquetes de
voz sean bien manejados en el acceso xDSL.

8.2. Pruebas Escenario No. 2.

En la sección 6.1, se muestran el diseño de las pruebas en el Escenario No. 2

que, a diferencia del caso anterior, tiene una configuración de tabla de tráfico para
el circuito virtual de VoIP que nos permitirá mejorar el comportamiento de la voz
en comparación con el de IPTV e Internet. Al aplicar la tabla de tráfico con
políticas de ancho de banda CAR se pretende reservar un ancho de banda
específico al tránsito de la voz y dejando los demás servicios iguales (ver anexo
F).

Por lo tanto los comandos aplicados son:

 service-port vlan 4002 ADSL 0/5/58 vpi 8 vci 36 rx-cttr 92 tx-cttr 92.
 service-port vlan 1723 ADSL 0/5/58 vpi 2 vci 35 rx-cttr 90 tx-cttr 90
 service-port vlan 1001 ADSL 0/5/58 vpi 4 vci 36 rx-cttr 91 tx-cttr 91

Podemos observar cómo se aplica estos comandos en la interfaz ADSL:

----------------------------------------------------------------------
VLAN VLAN PORT F/ S/ P VPI VCI FLOW FLOW RX TX STATE
ID ATTR TYPE PARA -
---------------------------------------------------------------------
4002 common adl 0/5 /58 8 36 - - 92 92 act/up
1723 common adl 0/5 /58 2 35 - - 90 90 act/up
1001 common adl 0/5 /58 4 36 - - 91 91 act/up
-------------------------------------------------------------

Esta prueba realizada se empieza de 1 llamada a 5 llamadas simultáneas igual a

la realizada en el Escenario No. 1, con la diferencia de que ahora la VoIP tiene un
ancho de banda de 512 Kbps reservado (ver anexo F). Los flujos que se generan
desde el transmisor hasta el receptor se analizaron y se obtuvieron los siguientes
datos de acuerdo a la tabla 15 y el anexo G.

109
 Tabla 15.Análisis de tráfico de voz en el acceso xDSL con CAR.

Con este análisis el caudal de voz aplicando políticas de tráfico CAR se nota la
mejoría en el delay que fue sensible en el escenario No. 1 con respecto al jitter y la
pérdida de paquetes. De este modo el delay, jitter y las pérdidas de paquetes
están por debajo de los parámetros de clase 1 de acuerdo los límites superiores
de la tabla 15.

De este modo el ancho de banda que se muestra en las líneas que se representan
en las diferentes llamadas de VoIP presentan una medida constante en el tiempo
(S) durante la 5 llamadas simultáneas con un promedio de ancho de banda de 367
Kbps (anexo G) y un delay 0,98 ms como se observa en la línea amarilla de la
figura 48 y 49.

110
Figura 41. Bitrate de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG.

Figura 42. Delay de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG.

111
De la misma manera el jitter presentó un comportamiento muy parecido al
escenario No.1 donde la variación de retardo de extremo a extremo no sufrió
ningún aumento. Aunque analizando un poco más la figura 50 se visualiza que la
líneas de la 2 y la 3 llamada tuvieron en el tiempo un leve aumento en el jitter pero
no significó un problema alguno para el servicio de voz.

Con respecto a la grafica de pérdidas de paquetes se muestra constante las líneas

de colores sobre el eje horizontal de la figura 51, es decir; que a través de los 60
segundos no hubo paquetes perdidos en el momento en que la parrilla de canales
de IPTV e Internet estaban funcionando al mismo tiempo.

Esta prueba de laboratorio del escenario No. 2 demostró un cambio satisfactorio

en la comparación de los parámetros de la recomendación ITU Y.1541 donde
analiza que estos datos cumplen con clase 1. Sin embargo el operador de
telecomunicaciones puede aplicar políticas de ancho de banda CAR para simular
QoS aunque se debe aclarar que el descriptor de tráfico por defecto es
NoCLPNoScr, es decir; que no tiene prioridad de flujo de acuerdo a lo estudiado
en el capitulo 2.

Figura 43.Jitter de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG.

112
 Figura 44.Pérdida de paquetes de 5 llamadas con parrilla de canales (IPTV) e
Internet en D-ITG.

De este modo el escenario No. 2 sin QoS puede ser parte de un contrato de VoIP
hacia el usuario final dado que los SLA´s pueden indicarse la política de ancho de
banda con la condición de que ese mismo tráfico no maneja prioridad de flujo CLP.

8.3. Pruebas Escenario No. 3.

En esta sección, se presentará el caso más completo de los considerados en este

proyecto de tesis, en donde a partir del análisis de las secciones anteriores ahora
se aplicarán dos tipos de descriptores de tráfico comunes para la categoría de
servicio CBR sugerido en esta implementación. En el DSLAM MA5600 se le ha
denominado dos tablas de tráficos como se observa en el anexo F con la función
de probar el comportamiento del flujo de voz en la saturación de la interfaz ADSL.

Los descriptores de tráfico CLPNoTaggingNoSCR y CLPNoTaggingNoSCR

trabaja sobre ATM (anexo A), aunque por defecto se aplica un CAR para
garantizar en ancho de banda estable en el circuito virtual 8/36. De la misma
manera el CLP activado tendrá dos funcionalidades como CLP = 0 para el primer
balde y CLP = 0 + 1 para el segundo balde llamado también Leaky Bucket.

Por lo tanto los comandos aplicados son:

113
  service-port vlan 4002 ADSL 0/5/58 vpi 8 vci 36 rx-cttr 43 tx-cttr 43 o
service-port vlan 4002 ADSL 0/5/58 vpi 8 vci 36 rx-cttr 45 tx-cttr 45
 service-port vlan 1723 ADSL 0/5/58 vpi 2 vci 35 rx-cttr 90 tx-cttr 90
 service-port vlan 1001 ADSL 0/5/58 vpi 4 vci 36 rx-cttr 91 tx-cttr 91

Podemos observar como se aplica estos comandos en la interfaz ADSL:

----------------------------------------------------------------------
VLAN VLAN PORT F/ S/ P VPI VCI FLOW FLOW RX TX STATE
ID ATTR TYPE PARA
----------------------------------------------------------------------
4002 common adl 0/5 /58 8 36 - - 43/45 43/45 act/up
1723 common adl 0/5 /58 2 35 - - 90 90 act/up
1001 common adl 0/5 /58 4 36 - - 91 91 act/up
-------------------------------------------------------------
La finalidad de realizar estas pruebas es que se observe como el flujo de VoIP no
interfiere con los circuitos virtuales de IPTV e Internet y viceversa, por lo tanto la
generación de tráfico de extremo a extremo se mantiene estable en la última milla
de acceso xDSL a pesar de la saturación de los caudales mencionados.

8.3.1. Generación de VoIP (CLPNoTaggingNoSCR o CLPTaggingNoSCR) +

IPTV + Internet

Esta prueba se configuro los parámetros de acuerdo a la tabla 13 donde el CLP

esta activo pero no tagging (anexo A) el flujo tomado que viene por el circuito
virtual de VoIP son de alta prioridad. Con este mecanismo garantizamos el modo
de PQ o prioridad de colas al tráfico de voz, es decir; estos flujos de transmitirán
primero que los otros flujos. Por lo tanto en la tabla 16 se observa los siguientes
resultados:

Tabla 16.Análisis de tráfico de voz en el acceso xDSL con PQ

(CLPNoTaggingNoSCR).

114
El caso de tagging en el descriptor de tráfico CLPTaggingNoSCR simplemente es
igual al otro con la única diferencia es el balde de PCR 0 (ver anexo A) donde
tiene la posibilidad de cambiar algún flujo de alta prioridad a baja prioridad
sumándose con el flujo que venía con CLP = 1 (ver anexo A). Aunque en
comparación con el descriptor de tráfico CLPNoTaggingNoSCR fue realmente
igual y el flujo de voz se sostuvo en los parámetros establecidos de la clase 0 de la
recomendación ITU Y.1541. De esta manera en la tabla 17 se observa los
siguientes resultados:

Tabla 17. Análisis de tráfico de voz en el acceso xDSL con PQ

(CLPTaggingNoSCR).

En los anteriores análisis, la figura 52 y 53 se visualiza el Bitrate (ancho de banda)

y el delay de forma constante sobre el eje vertical a través del tiempo que
transcurre de las 5 llamadas simultáneas. En la línea amarilla de las dos figuras se
observa la suma de los flujos.

En la figura 54 se observa que los datos del jitter de cada llamada estuvieron
constantes en el tiempo y por último la figura 55 se observa cero paquetes
perdidos, es decir; que la parrilla de canales de IPTV e Internet nunca afecto las
llamadas que a través del tiempo que dura las llamadas.

115
Figura 45.Bitrate de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG.

Figura 46.Delay de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG.

116
 Figura 47. Jitter de 5 llamadas con parrilla de canales (IPTV) e Internet en D-ITG.

Figura 48. Perdidas de paquetes de 5 llamadas con parrilla de canales (IPTV) e Internet
en D-ITG.

117
Finalmente los datos de la tabla 16, 17 y las figuras del escenario No.3 muestran
como esta implementación de calidad de servicio con prioridad de cola (PQ)
presenta unos parámetros de certificación de alta calidad en el ofrecimiento del
flujo de VoIP hacia el usuario. Sin embargo esto mejora notablemente las medidas
de extremo a extremo de un acceso xDSL sin perder paquetes por los multiplex
servicios que se pueden prestar a un usuario final. Además, al proporcionar un
ancho de banda reservado con políticas (CAR) al tráfico voz logra que este
servicio tenga un caudal fijo para trasmisión el lado ATM entre la interfaz ADSL y
el CPE.

Con respecto al mecanismo de PQ o prioridad de colas que se utilizó en la

implementación del escenario No. 3 se deduce que la categoría de servicio CBR
(Constant Bit Rate) se utilizó el número 7 como la más alta prioridad para servicios
de tiempo real como la VoIP (ver figura 34). Aunque exista una enorme cantidad
de flujos, se necesita también que cada uno de ellos se transmita por la red de
acceso xDSL de acuerdo a su prioridad establecida en la tabla de tráfico que se
configuro de acuerdo al anexo F.

Se puede decir que la comparación que se muestran en la tabla 18 de los

resultados de los escenarios No. 1, 2 y 3, se exponen una mejora sustancial en los
parámetros de delay en la configuración de políticas de ancho de banda (CAR) y
prioridad de colas (PQ).Sin embargo el jitter y las pérdidas de paquetes se
mantienen igual en el escenario No. 2 y 3. Con respecto al escenario No. 1 todos
lo parámetros con excepción del jitter mostraron alteraciones por la alta congestión
en la interfaz ADSL del DSLAM MA5600.

Tabla 18. Tabla comparativa de los escenarios de laboratorio.

118
 9. CONCLUSIONES

-Es importante aplicar técnicas de QoS debido a que los usuarios son el objetivo
primordial del operador de telecomunicaciones para competir en la convergencia
de productos y al mismo tiempo brindar una alta confiabilidad del servicio hacia el
cliente. Sin embargo la CRC busca definir regulaciones enfocadas hacia la
protección de los usuarios independientemente si son redes de conmutación de
paquetes o circuitos. Por consiguiente este tema adquiere relevancia en vista que
la Ley 142 de 1994 consideró al servicio de TPBC ó Telefonía Pública Básica
Conmutada (servicio básico de telecomunicaciones cuyo objeto es la transmisión
conmutada de voz a través de la Red Telefónica Pública Conmutada -RTPC- con
acceso generalizado al público), como un servicio público esencial y lo enmarcó
dentro de los Servicios Públicos Domiciliarios, junto con los servicios de
acueducto, alcantarillado, aseo, energía eléctrica y distribución de gas
combustible.(Ver: Ley 142 de 1994, Resolución 087 de 1.997 de la CRT) .

-Los servicios de voz tradicionales o POTS (Plain Old Telephone Service) que
usan redes de conmutación de circuitos son plataformas que garantizan una alta
calidad de servicio (QoS) en comparación con las redes NGN o IP. Sin embargo
los avances tecnológicos permitieron que la prestación del servicio de voz se
hicieran sobre redes IP lo cual se ajusto a la necesidades futuras sobre la
convergencia de los servicios. Por lo tanto es importante que estas plataformas
sigan dentro del marco de los indicadores de calidad de servicio de TPBC
(Telefonía Publica Básica Conmutada) que regula la CRC (Comisión Reguladora
de Comunicaciones). Por lo tanto los operadores de telecomunicaciones que han
migrado sus redes de voz a redes de próxima generación (NGN) no deben aplicar
arquitecturas basadas en mejor esfuerzo (Best effort), sino ajustarse a los
parámetros de QoS que brindan las redes NGN, de tal manera que se siga
cumpliendo con los parámetros regulatorios establecidos por la CRC entre otras
como en las Resoluciones CRC 2353 de 2010.

-Evidentemente en la red NGN se presenta congestión en las últimas millas

basadas en acceso xDSL dado que a que al integrar tecnologías IP con ATM se
requiere tratamientos para manejar cualquier tipo de flujo con prioridad de tráfico
al servicio de VoIP.

-Para aplicar mecanismos de QoS se requiere priorizar paquetes con los

requerimientos de retardo y jitter que establece las recomendaciones de la ITU y
los TR (Technical Report) de una red IP.

-Con las políticas de ancho de banda CAR, se obtiene valores adecuados de jitter
y de delay en la operación del servicio de VoIP, pero el mecanismo de QoS
propuesto mejoró totalmente los resultados con la implementación de prioridad de

119
flujo con CLP = 0. Esto permite que los parámetros del flujo de VoIP sean
priorizados en las colas que se presentan en la interfaz xDSL, lo cual hace que se
mantengan los requerimientos de calidad de servicio establecidos en la clase 0 de
la recomendación de la ITU-T Y.1541, así optimizando el ancho de banda entre el
DSLAM y el CPE en la medida que el par telefónico presente las mejores
condiciones.

-La metodología propuesta permite que cualquier operador de telecomunicaciones

con redes de nueva generación (NGN) y que opere con redes xDSL puedan
brindar un contrato tráfico explícito o SLA´s a todos sus usuarios.

-Finalmente se presenta una metodología con base en la investigación,

implementación y pruebas que garantizan ventajas en cuanto a la provisión de
servicios de VoIP sobre redes xDSL enfocados a usuarios residenciales y
comerciales. Además se permite extender la integración de múltiples servicios
hacia el usuario final y aportar mayor valor a las empresas operadoras de
telecomunicaciones con la disminución del número quejas al soporte técnico a
partir de la alta confiabilidad del servicio y de los datos estadísticos de la
percepción de la calidad de experiencia que se obtienen de los usuarios.

120
 10. BIBLIOGRAFIA

[1]. ITU–T. Recomendación Y.2001. [aut. libro] Grupo de Estudio 13 del Sector de
Normalización de la Unión Internacional de Telecomunicaciones.

[2] G.Almes, S. Kalidindi, M. Zekauskas, “A one-way Delay metric for IPPM”, IETF
RFC 2679, septiembre de 1999.

[3] G.Almes, S. Kalidindi, M. Zekauskas, “A One-way Packet Loss metric for

IPPM”, IETF RFC 2680, septiembre de 1999.

[4] C. Demichelis, P. Chimento , “IP Packet Delay Variation Metric for IP

Performance Metrics (IPPM)”, IETF RFC 3393, noviembre de 2002.

[5] J.Mahdavi, V.Paxson, “IPPM Metrics for Measuring Connectivity”, IETF RFC
2678, septiembre de 1999.

[6] G.Almes, S. Kalidindi, M. Zekauskas, “A Round-trip Delay Metric for IPPM”,

IETF RFC 2681, septiembre de 1999.

[7] M. Mathis, M. Allman, “A Framework for Defining Empirical BTC”, IETF RFC
3148, julio de 2001.

[8] R.Koodli, R. Ravikanth “One-way Loss Pattern Sample Metrics”, IETF RFC
3357, agosto de 2002.

[9] Network Working Group, Network performance measurement with periodic

streams, IETF RFC 3432, noviembre de 2002

[10] IETF, IP Flow Information Export (IPFIX) Charter,

TUhttp://www.ietf.org/html.charters/ipfix-charter.htmlUT.

[11] Francisco Javier Cantero Fernández, Departamento ASEP de la TSB,

cantero@itu.int.

[12] ITU-T G.107 The E-model, a computational model for use in transmission
planning, March 2005, http://www.itu.int/rec/T-REC-G.107/e

121
[13]. ITU–T. Recomendación Y.1540 (03/2011). Internet protocol aspects – Quality
of service and network performance. Internet protocol data communication service
– IP packet transfer and availability performance parameters.

[14]. ITU–T. Recomendación I.350 (03/93). Aspectos generales de calidad de

servicio y de calidad de funcionamiento en las redes digitales incluidas las redes
digitales de servicios integrados

[15] ITU–T. Recomendación G.1010 (11/2001). Calidad de servicio y de

transmisión. Categorías de calidad de servicio para los usuarios de extremo de
servicios multimedios.

[16] Blandon, David. Diaz,Yony. Guerrero,Fabio. Cuellar, Juan Carlos. Navarro,

Andres. Ochoa A, Catherine. Medición de la calidad del servicio en Redes de
Próxima Generación en Colombia. CINTEL. Diciembre 2010

[17]. ITU–T. Recomendación Y.1541 (02/2006). Aspectos del protocolo Internet –

Calidad de servicio y características de red. Objetivos de calidad de
funcionamiento de red para servicios basados en el protocolo Internet

[18] ITU–T. Recomendación I.356 (03/2000). [aut. libro] Calidad de funcionamiento

en la transferencia de células en la capa de modo de transferencia asíncrono de la
RDSI-BA.

[19]. ITU–T. Recomendación G.1000 (11/2001). Calidad de servicio y de

transmisión. Calidad de servicio en las comunicaciones: Marco y definiciones.

[20] Technical Report DSL Forum TR-042. ATM Transport over ADSL
Recommendation (Update to TR-017). August 2001, Issue 0.1,
http://www.broadband-forum.org

[21] ADSL. Instalación, configuración y mantenimiento. Telefonica España,

Dirección de Desarrollo y Formación. Malaga, marzo
2008,http://es.scribd.com/doc/35824988/La-Biblia-Del-ADSL

[22] ATM Forum Technical Committee AF-TM-0121.000. Traffic Management

Specification. March 1999,Version 4.1. http://www.broadband-forum.org.

[23] Redes de Comunicaciones. Jorge Martinez, Area de ingenieria telematica,

Departamento de comunicaciones. Universidad politecnica de Valencia, Ref.
2002.4070,http://books.google.com.co/books?id=Kyy_JSoUUJ8C&pg=PP5&lpg=P
P5&dq=redes+de+comunicaciones+jorge+martinez&source=bl&ots=smzjMIwODP
&sig=EGdGfI-

122
6_C8ZbKZjntMf8TCX9Eg&hl=es&sa=X&ei=VxUoUL2fLYb28gSy5oDQCg&ved=0C
EcQ6AEwAg#v=onepage&q=redes%20de%20comunicaciones%20jorge%20marti
nez&f=false

[24] Capitulo 13 Managing Cell Switching Modules (CSMs), ftp://ftp.uni-

duisburg.de/Hardware/Alcatel/OmniSwitch/UserManual-3.2/CH13.pdf

[25] RFC 2514 Definitions of Textual Conventions and object-identities for ATM
Management, M. Noto, 3Com, E. Spiegel, Cisco Systems, K. Tesink, Bellcore.
February 1999.

[26] Adapting Voice For ATM Networks, An AAL2 Tutorial. Mike McLoughlin and
John O’Neil, General Datacomn, 1997.

[27] Technical Report DSL Forum TR-001. System Reference Model, May 1996.

[28] Technical Report DSL Forum TR-012. Broadband Service Architecture for
Access to Legacy Data Networks over ADSL, Issue 1, June 1998.

[29] Technical Report DSL Forum TR-039. Requirements for Voice over DSL,
March 2001,

[30] Real-time Transport Protocol (RTP) security, Tik-110.501 Seminar on Network

Security (2000), Ville Hallivuori, Helsinki University of Technology.

[31] García Girón, Giancarlo. Tesis “Propuesta de migración de la red NGN de una
operadora implementada en IP hacia MPLS”. Lima, Noviembre de 2009.

[32] SmartAX MA5600/MA5603 Multi-service Access Module V300R003C05,

Huawei Technologies Co Ltd, Julio 2008, Issue 0.1, http://www.huawei.com

[33] Tomada SmartAX MA5600/MA5603 Multi-service Access Module

V300R003C05, Huawei Technologies Co Ltd, Julio 2008.

[34] MA5600 ACL & QoS Technology, Huawei Technologies Co Ltd, Agosto 27
2005, Version 1.00, Chen Jiawei 36034

[35] D-ITG. URL http://www.grid.unina.it/software/ITG/.

[36] IETF Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R.

Frederick, and V. Jacobson. RFC 1889: RTP:A transport protocol for real-time
applications, January 1996.

123
[37] Tomada documento de http://www.broadband-
forum.org/downloads/About_DSL.pdf. DSL Technology Evolution.

[38] Tomada MA5600 ACL & QoS Technology, Huawei Technologies Co Ltd,
Agosto 27 2005.

[39] Tomada de la ITU-T Y.1540 (03/2011). Eventos de retardo de transferencia de

paquetes IP. Transferencia ‘extremo a extremo’ de un paquete IP

[40] Tomada de la ITU-T Y.1540 (03/2011). Variación del retardo de paquetes IP

entre dos puntos.

[41] Tomada de la ITU-T Y.1541 (02/2006). Trayecto de referencia UNI a UNI para
los objetivos QoS de la red.

[42] Diseño basado Tomada de la “Thesis submitted to the Faculty of the Virginia
Polytechnic Institute and State University”. Assessment of Voice over IP as a
Solution for Voice over ADSL. Abhishek Ram (2002).

[43] Tomada de la ITU-T Y.1541 (02/2006). Definiciones de clases de QoS de las

redes IP y objetivos de calidad de funcionamiento de la red.

[44] . Tomada de la ITU-T. Directriz para las clases QoS IP. Recomendación ITU-T
Y.1541.

[45] Tomada de DSL Forum TR-101 (April 2006). Migration to Ethernet Based DSL
Aggregation.

[46] Tomada Cisco 7200 Series Design Library: ATM Traffic Management, Cisco
Systems, December 2005.

[47] Tomada Capitulo 13 Managing Cell Switching Modules (CSMs), ftp://ftp.uni-

duisburg.de/Hardware/Alcatel/OmniSwitch/UserManual-3.2/CH13.pdf

[48] Tomada Technical Report DSL Forum TR-039 Requirements for Voice over
DSL.

[49] Tomada de Tik-110.501 Seminar on Network Security (2000). Real-time

Transport Protocol (RTP) security.

124
[50] Tomada del sistema de gestión N2000, Huawei Technologies Co Ltd.

[51] Tomada del sistema de gestión NETNUMEN, ZTE CORPORATION.

[52] Tomada de la ITU-T Y.1540 (03/2011). Eventos de referencia de transferencia

de paquetes IP.

[53] Tomada adsl Instalación, configuración y mantenimiento. Telefonica España,

Dirección de Desarrollo y Formación. Malaga, marzo 2008.

[54] Tomada de la ITU-T Y.1540 (03/2011). Alcance de la Recomendación ITU-T

Y.1540.

125
 11. LISTA DE ANEXOS

ANEXO A. Descriptores de Tráfico ...................................................................... 127

ANEXO B. Especificaciones Técnicas ZXR10 T64G-LE ..................................... 128
ANEXO C. Especificaciones Técnicas ZXMSG 5200 .......................................... 130
ANEXO D. Especificaciones Técnicas Echo Life HG520c ................................... 133
ANEXOE.Especificaciones Técnicas ZXV10 B700 .............................................. 134
ANEXO G.Tablas .log Decodificados en D-ITG con ITGDec ............................... 137
ANEXO H.Arquitectura de hardware del MA5600................................................ 141

126
 ANEXO A. Descriptores de Tráfico
(ATM Forum ATM Traffic Management - EE6364)

127
ANEXO B. Especificaciones Técnicas ZXR10 T64G-LE
(Manual de especificaciones del proveedor ZTE)

128
129
ANEXO C. Especificaciones Técnicas ZXMSG 5200
(Manual de especificaciones del proveedor Huawei)

Gabinete 19D06H20

130
Variedad de Tarjetas

131
132
ANEXO D. Especificaciones Técnicas Echo Life HG520c
(Manual de especificaciones del proveedor Huawei)

133
ANEXOE.Especificaciones Técnicas ZXV10 B700
(Manual de especificaciones del proveedor ZTE)

134
 F. Tablas de Tráfico
(Resultados de las tablas de trafico en el DSLAM MA5600 de Huawei)

Tabla de tráfico implementada para Best Effort

Tabla de tráfico implementada para CAR o Politica de Ancho de Banda

135
Tabla de tráfico implementada para prioridad de colas.

Resumen parametros de tráfico en el DSLAM MA5600.

136
 ANEXO G.Tablas .log Decodificados en D-ITG con ITGDec
(Resultados de las medidas de laboratorio con el software D-ITG)

Resumen decodificados de los tráficos del Escenario No1. en el DSLAM MA5600.

137
Resumen decodificados de los tráficos del Escenario No. 2 en el DSLAM MA5600.

138
Resumen decodificados de los tráficos CLPNoTaggingNoScr del Escenario No. 3 con en el
DSLAM MA5600.

139
Resumen decodificados de los tráficos CLPTaggingNoScr del Escenario No. 3 con en el
DSLAM MA5600.

140
ANEXO H.Arquitectura de hardware del MA5600.
(Manual de especificaciones del proveedor Huawei)

Tipos y apariencia de los gabinetes MA5600.

141
Configuración de hardware y capacidad de los gabinetes de MA5600.

Parámetros de la operación ambiente de MA5600.

142
 Parámetros de fuente de alimentación del MA5600.

Parámetros de consumo de energía del MA5600 (64-port non-combo board).

Parámetros de consumo de energía del MA5600 (64-port combo board).

143