Calidad de Servicio en aplicaciones multimedia sobre redes de

Calidad de Servicio para aplicaciones multimedia sobre
redes heterogéneas, redes de cable.
Elvira Narro, Rafael del Hoyo, David Abadía, Lorena Benedí, Pilar Fernández de Alarcón, Juan José
Navamuel
Departamento de Electrónica y Comunicaciones, Instituto Tecnológico de Aragón
Instituto Tecnológico de Aragón, C/ María de Luna, 7 (Pol. Actur) – 50018 Zaragoza.Telf: 976-716207,
Fax: 976-716539
E-mail: {enarro , rdelhoyo, dabadia, lbenedí, pfernandez, jnavamuel}@ita.es
Área II: Sistemas y Tecnologías de Red: Tecnologías y redes de acceso fijo: HFC
Otras áreas involucradas: Área III: Internet, Calidad de Servicio
Resumen
Este artículo pretende presentar los esfuerzos realizados dentro del marco del proyecto CELTIC Quar2
[1] para proveer Calidad de Servicio en redes heterogéneas, en especial dirigiéndonos hacia redes de
acceso de cable, para lo cual se propone una arquitectura basada en las especificaciones de
PacketCable/IPCablecom. El estudio e implementación del modelo de la arquitectura mencionada se
realiza en la herramienta de simulación OPNET.
A lo largo de este documento se mostrarán las funcionalidades de la arquitectura modelada, los
escenarios de simulación estudiados, así como los mecanismos de QoS empleados, tanto a nivel IP como
los propios de una red de cable. Se expondrán las conclusiones alcanzadas después de las simulaciones
de los escenarios y se plantearán las líneas en las que se continúa trabajando actualmente.
En especial este documento recoge parte del
trabajo realizado en el Proyecto CELTIC Quar2
de búsqueda de un modelo común para proveer
QoS en redes heterogéneas desde el punto de
vista IP, sin olvidar la tecnología subyacente. En
particular, la arquitectura base común para redes
heterogéneas que es objeto de estudio en este
documento
es
la
propuesta
en
las
especificaciones PacketCable/IPCablecom [3]
para las redes HFC (Hybrid Fiber Cable). Por
ello, el trabajo que se presenta aquí se centra en
este tipo de redes.
1. Introducción.
En la actualidad numerosas tecnologías
permiten acceder a los usuarios finales a las
redes de información, y en particular a la red
global Internet, tales como xDSL (Digital
Subscriber Line), RDSI (Red Digital de
Servicios Integrados), cable, fibra (fiber to the
home)... Además, en las redes troncales
podemos encontrar diferentes tecnologías que
también tienen que coexistir y que a veces son
complementarias (SDH, ATM, Ethernet etc.).
Por todo ello podemos decir que la arquitectura
de red global es heterogénea porque es la unión
de diferentes tecnologías y aunque cada
tecnologías tiene unas particularidades, el
pegamento de todas ellas es el protocolo de
Internet (IP). Por otra parte, la aparición de
nuevos servicios y aplicaciones multimedia
empiezan a demandar unos requerimientos
mucho más estrictos en cuanto a retardo, ancho
de banda y variación del retardo (jitter delay), es
decir, unos parámetros de Calidad de Servicio
(QoS) [2]. Esto ha suscitado la aparición de
diferentes arquitecturas que
tienen como
objetivo la gestión y satisfacción de los
requerimientos demandados por estos nuevos
servicios.
Para realizar este estudio se ha modelado esta
arquitectura basada en las mencionadas
especificaciones en la herramienta de
simulación OPNET.
2. Arquitectura PacketCable en
redes de cable.
PacketCable es la iniciativa creada por
Cablelabs para integrar servicios multimedia en
tiempo real sobre la arquitectura general HFC.
En sus especificaciones se identifican los
protocolos necesarios para hacer posible la
provisión de calidad de servicio a estos servicios
multimedia a nivel IP.
1
Aunque en el estudio que en este documento se
presenta no estén incluidas, la arquitectura
PacketCable soporta más funciones extremoextremo, además de la provisión de Calidad de
Servicio, entre las cuales se encuentran, la
seguridad [4], facturación y otras funciones de
gestión de la red.
Junto a estas especificaciones de PacketCable
que definen una arquitectura a nivel IP, es
necesario tener en cuenta también el medio en el
que nos encontramos, una red de cable, en
donde el enlace upstream es un medio
compartido (con un sistema de acceso al medio
TDMA y con tasa de transmisión máxima de
10Mbps). Esto se traduce en la necesidad de
mecanismos de provisión de QoS dentro de la
red de cable misma para permitir nuevos
servicios a nuevos clientes sin disminuir la
calidad de los ya existentes. De la definición de
las características de QoS, así como de otras
funcionalidades, en la red de acceso de cable se
ocupan las especificaciones DOCSIS 1.1 (Data
Over Cable Service Interface Specifications)
[5]. Y por tanto, hay que tener en cuenta la
existencia de una integración entre los
protocolos a nivel IP definidos por PacketCable
con la capa de enlace (DOCSIS).
Figura 1. Modelo de
PacketCable en OPNET.
-
arquitectura
de
MTA (Multimedia Terminal Adapter ,
equipo de usuario)
CM (Cable Modem, módem cable en el
usuario)
CMTS (Cable Modem Temination
System, cabecera de cable)
CMS (Call Management Server, gestor
de acceso de usuarios)
Estos componentes de red han sido diseñados a
partir de elementos disponibles en OPNET, sin
embargo, han tenido que ser modificados
principalmente
para
introducir
la
implementación de los protocolos necesarios
para proveer QoS y que no estaban
implementados en la herramienta de simulación.
Así, DOCSIS provee cinco tipos de servicio en
el upstream (sentido cable modem- CMTS o
cabecera de cable):
- Unsolicited Grant Service (UGS).
- Real-Time Polling Service (rtPS).
- Unsolicited Grant Service with Activity
Detection (UGS-AD).
- Non-Real Time Polling Service
(nrtPS).
- Best Effort Service (BE).
Estos protocolos que se han implementado en la
herramienta OPNET para modelar la
arquitectura de PacketCable desempeñan una
serie de funcionalidades en la red:
-
Por ello en este documento también se presenta
la evaluación de algunos de estos tipos de
servicio en la herramienta de simulación
OPNET.
autorización de los usuarios
autorización de los recursos que demandan
reserva de los recursos
activación de los recursos
CMS
PDP
D
PS
CO
3. Descripción del trabajo.
Para abordar el estudio de la arquitectura
PacketCable se ha modelado la misma dentro de
la herramienta de simulación OPNET. En dicho
modelo se identifican los componentes de red
básicos
de
las
especificaciones
PacketCable/IPCableCom (Figura 1), que son:
CMTS
S
Qo
PEP
Figura 2. Jerarquía CMTS-CMS, a través del
protocolo COPS.
Esta arquitectura tiene una jerarquía, basada en
el protocolo COPS [6] (figura 2), porque estas
funcionalidades deben ser desempeñadas por
sus componentes siguiendo una cierta secuencia
2
para llegar a proveer calidad de servicio. En
primer lugar se hace una autorización de los
usuarios (esta función la desempeña el CMS
(Call Manager Server)), elemento que gestiona
las diferentes aplicaciones. Una vez que un
usuario ha sido autorizado, se deben autorizar
los recursos que demanda, es decir, comprobar
que no demanda más cantidad de recursos de los
que tiene en su SLA (de lo cual también tiene
control el CMS). Es decir, el CMS realiza una
gestión a alto nivel. El siguiente paso (siguiente
nivel en la jerarquía) es comprobar que existan
recursos suficientes en la red de cable para
proveer la QoS que demanda el cliente (de lo
cual tiene el control el CMTS, porque es quien
tiene el conocimiento de los recursos que son
empleados y los que quedan libres en cada
momento). Con este modelo jerárquico, si
alguna de estas autorizaciones no es
satisfactoria hace que no se continúe con el
establecimiento de la comunicación, y por tanto
no se llegaría a autorizar o a reservar recursos.
De esta forma, la comunicación se corta en
cuanto se sabe que no hay posibilidad de
ejecutarla con las garantías solicitadas y no se
malgastan los recursos.
-
-
COPS PacketCable (basado en el protocolo
COPS estándar, [6]): se ocupa de la
autorización de los usuarios, así como de la
autorización de los recursos en la red.
RSVP+ (basado en el protocolo RSVP
estándar, [7]): se ocupa de la reserva y de la
activación de los recursos.
Protocolo de señalización de aplicación
(basado en el protocolo NCS estándar, [8]):
es necesario para que se inicie el
mecanismo de autorización, así como el de
la reserva.
4. Resultados.
Las simulaciones en OPNET realizadas tienen
dos objetivos diferentes, por una parte, se
pretende testear el uso de la arquitectura de
PacketCable para extraer conclusiones sobre la
Calidad de Servicio dispensada. Y por otra
parte, se han realizado simulaciones para ver el
propio comportamiento de una red de cable
DOCSIS, así como los resultados que ofrecen
los diferentes tipos de servicio en el upstream
que son ofrecidos por ella misma a nivel de capa
física.
Una vez que la autorización de los recursos ha
sido satisfactoria, los clientes de la
comunicación pueden reservar los recursos en la
red de cable para poder transmitir con los
parámetros de QoS demandados en el inicio del
establecimiento de la comunicación. Esta
petición de reserva por parte de los clientes es
efectuada al CMTS, que como ya se ha dicho, es
el elemento que tiene el control de los recursos
existentes y disponibles para su utilización. De
esta forma, si existen los recursos demandados,
se los reserva al cliente. Además también se
controla que no se demanden en la reserva más
recursos de los que fueron autorizados en la
etapa de autorización, de lo cual también tiene
un control el CMTS. Es decir, el CMTS realiza
una gestión de los recursos físicamente dentro
de la jerarquía.
4.1.
Configuración
PacketCable.
arquitectura
Se han realizado simulaciones de la arquitectura
en OPNET (Figura 1) creada con el objetivo de
comprobar el establecimiento de la señalización
adecuada, acorde con la descrita en la figura 3.
Así como para comprobar el comportamiento
obtenido por una aplicación que deba ser
autorizada, y para la que se realicen reservas de
recursos a través de RSVP+ y se hagan cumplir
con el planificador WFQ (Weighted Fair
Queueing). Y todo ello comparándolo con el
comportamiento de una aplicación que no haga
ningún tipo de petición de QoS.
Finalmente, en el modelo de PacketCable existe
una última etapa, que es la de la activación de
los recursos. Esta etapa tiene su razón porque
los recursos han sido reservados por el CMTS,
pero hasta que el cliente no los activa no toma
posesión de ellos. Esto hace posible que entre la
reserva y la activación pueda ser posible que
otros clientes hagan uso de los recursos de la
red, permitiendo hacer un uso más eficiente de
los limitados recursos.
Las funcionalidades son resueltas por los
siguientes protocolos:
3
CMTS
MTAo
protocolo RSVP ni el RSVP+. Por tanto, sólo se
van a hacer reservas y activaciones de los
recursos en la sección de red donde se ha
configurado el protocolo RSVP+.
MTAd
CMS
socket
client_open
client_accept
client_request
ncs_init
4.2. Conclusiones arquitectura PacketCable.
ncs_init
gate_set
gate_set_ack
ncs_init
gate_set
gate_set_ack
El tiempo total que pasa desde que la aplicación
inicia su autorización (envío del mensaje NcsInit) hasta que recibe el mensaje RSVP+
Commit-Ack (significa que los recursos han sido
activados) es de 0,2347 segundos. Este tiempo
es el que debe transcurrir hasta que la aplicación
realmente recibe la calidad de servicio que se le
asignó (cuyo cumplimiento es misión del
planificador WFQ).
ncs_init_ack
ncs_init_ack
rsvp_path
rsvp_resv
rsvp_path
rsvp_resv
rsvp_commit
gate_open
rsvp_commit_ack
rsvp_commit
rsvp_commit_ack
gate_open
start communication
rsvp_tear
gate_close
ncs_finish
rsvp_tear_ack
ncs_finish
finish communication
Tabla 1. Resultados
aplicaciones.
Figura 3. Señalización.
En particular las simulaciones realizadas han
tenido una duración de 300 segundos y se han
configurado dos aplicaciones de VoIP (Voice
over IP). Los parámetros son:
-
-
-
-
(1) una aplicación de VoIP con RSVP+ y
NCS habilitados:
norma G.723.1 que implica una tasa de
transmisión de 5,3Kbps.
la longitud de los silencios sigue una
distribución exponencial de media 0,65
segundos.
Tipo de servicio Interactive Voice.
RSVP parameters activados
Señalización NCS.
La aplicación se establece entre los
elementos del escenario MTA y destination.
de
delay
de
las
Aplicación
Delay
Jitter delay
Voz con
RSVP+
Voz sin
RSVP+
0,0126
5,4728E-5
Desviación
estándar
1,4696E-5
0,6033
1,6576
0,4511
En la tabla 1 se presentan los resultados en
cuanto al comportamiento de las aplicaciones
sobre el escenario. Para ello se presenta el delay
o retardo extremo-extremo, el jitter delay y la
desviación estándar del delay.
Atendiendo a estos resultados de la tabla 1, la
aplicación de voz con RSVP+ tiene mejor
comportamiento que la de voz sin RSVP+ en
cuanto a delay, jitter delay, así como desvición
estándar del delay.
Por tanto, se ha comprobado que la aplicación a
la que se le reservan y activan los recursos que
necesita para su ejecución obtiene unos valores
de delay, jitter delay, y desviación estándar del
delay mucho mejores que una que no disfruta
del modelo PacketCable. Es decir, se ha
conseguido proporcionar a esta aplicación cierto
nivel de Calidad de Servicio gracias al modelo
controlado IntServ [2] que provee OPNET.
(2) una aplicación de VoIP sin RSVP+ ni
NCS habilitados:
norma G.711 que implica una tasa de
transmisión de 64Kbps
la longitud de los silencios sigue una
distribución exponencial de media 0,65
segundos.
Tipo de servicio Interactive Voice.
RSVP parameters no activados.
Sin ningún tipo de señalización.
Esta aplicación se establece entre el
elemento llamado Embedded_MTA y
destination_no_RSVP.
Este modelo es implementado en OPNET
gracias al planificador de paquetes WFQ que se
ha configurado en los nodos de la arquitectura,
en especial en el CMTS. Este permite asegurar
un determinado comportamiento a los flujos de
datos.
En este escenario sólo soportan dos nodos el
protocolo RSVP+: el MTA y el CMTS en su
interfaz con el medio compartido. Esto es
porque es entre estos elementos en donde se
debe establecer la reserva de recursos en un
escenario de cable PacketCable. El resto de
elementos de la arquitectura no soportan ni el
4.3. DOCSIS, tipos de servicio en el
upstream, configuración.
4
El modelo de DOCSIS 1.1 provee 5 tipos de
servicios, que ya se han mencionado
anteriormente. En OPNET sólo es posible
realizar simulaciones de los tipos UGS y BE,
por ello sólo se han podido estudiar estos dos
tipos de servicios.
-
Los mini-slots en los que está dividido el enlace
upstream del cable pueden ser empleados como
asignaciones para los usuarios para poder
transmitir información, como slots de
competición, para que otras estaciones nuevas
se puedan unir al medio y como de control. Y
existen unos mensajes llamados MAP (enviados
por el enlace dowstream), mediante los cuales,
el CMTS realiza las asignaciones de mini-slots a
los diferentes usuarios y define los mini-slots de
control
(no son asignaciones para la
transmisión de usuarios) a través de elementos
de información.
-
-
También se deben configurar una serie de
parámetros relacionados con los mensajes MAP,
que se pueden ver a continuación:
-
Cada elemento de información representa un
tipo de mini-slot. Así, los posibles tipos de
elementos de información que puede transportar
un mensaje MAP son: Request (petición),
Request/data (petición con piggybacking), Short
grant (asignación), Long grant (asignación),
Pending (asignación), Initial maintenance
(aparecen cada mucho tiempo), Station
maintenance (aparecen cada mucho tiempo).
El tipo de servicio UGS se caracteriza por
eliminar el overhead y la latencia que
introducen las peticiones de los CMs para poder
transmitir, porque el CMTS hace asignaciones
periódicas de forma que asegura o reserva un
determinado ancho de banda en el upstream
para cada cable modem que tiene configurado
este tipo de servicio. En cambio, para el tipo
Best-Effort (BE) no se dispensan asignaciones
periódicas, sino que debe emplear los mini-slots
de competición para solicitar al CMTS que le
asigne mini-slots en el siguiente MAP, y así
poder transmitir.
Los parámetros de configuración para cada
enlace, y los valores particulares que se han
empleado en las simulaciones son los
siguientes:
Estos tipos de servicio también poseen unos
parámetros que deben ser configurados. Éstos
son:
(1) Best-Effort (BE):
(1) Downstream (sentido CMTS-CM):
-
-
modulación: 64QAM
tasa datos: 27Mbps
ancho de banda del canal: 6MHz
Frecuencia central: 500MHz
Latencia entrelazador: profundidad
entrelazado: 32 e incremento :4
tiempo entre MAPs: se define en cada
simulación
Grant Interval: se define en cada simulación
número de mini-slots para hacer peticiones
(de competición): 16
tamaño límite de bytes que pueden ser
enviados en los elementos de información
reducidos: 128 bytes
tamaño límite de bytes que pueden ser
enviados en los elementos de información
grandes: 1000 bytes
Mini-slots de mantenimiento inicial: 4
mini-slots/segundo
Mini-slots de mantenimiento de la estación:
2 mini-slots/segundo
Por otra parte, se deben presentar los diferentes
tipos de servicio que han sido objeto de estudio:
UGS y BE.
Los tipos de elementos de información más
importantes son los de petición (con los que se
definen los mini-slots que se dedicarán en la
trama TDMA para la competición de todos los
usuarios, que emplearán para demandar minislots para poder transmitir su información). Y
por otra parte, los de asignación, es decir, los
mini-slots asignados para la transmisión a cada
usuario.
-
Frecuencia central: 8MHz
Bytes por mini-slot: 4
-
de
identificador de canal sobre el que se
quiere transmitir = 0,
parámetros DOCSIS 1.1
fragmentación habilitada
(sólo es
configurable en DOCSIS 1.1)
(2) Unsolicited Grant (UGS):
(2) Upstream (sentido CM-CMTS):
-
modulación para un canal: QPSK
tasa máxima del enlace: 640Kbps
ancho de banda del canal: 800KHz
-
5
identificador de canal sobre el que se
quiere transmitir = 0
versión DOCSIS 1.1
Grant Size para cada CM =
“configurable en cada simulación”
-
(1) para un tamaño de paquete DOCSIS (antes
de añadir el código de corrección) inferior
a 66 bytes:
- Preamble length: 48 bits
- FEC Error Correction: 10 bytes
- FEC Codeword Length: 75 bytes
- Guard time: 40 bits
- Last Codeword Mode: Fixe-length
Nominal Grant Interval : “configurable
en cada simulación”
Fragmentación no habilitada (no es
posible
habilitarla
en
esta
implementación de OPNET).
Hay que hacer una serie de consideraciones para
configurar los parámetros Nominal Grant
Interval y Grant Size para el servicio UGS:
-
-
(2) Para un tamaño de paquete superior a 66
bytes:
- Preamble length: 56 bits
- FEC Error Correction: 16 bytes
- FEC Codeword Length: 226 bytes
- Guard time: 40 bits
- Last Codeword Mode: Fixe-length
El Nominal Grant Interval debe ser
algo superior al tiempo entre MAPs.
Este tiempo entre MAPs define la
trama básica en tiempo del TDMA
El Grant Size viene dado en general
por [eq.1].
Para calcular el tamaño del paquete DOCSIS
final se tiene que efectuar los siguientes
cálculos:
Nº palabras código: tamaño del paquete sin
corrección de errores/(FEC Code Word LengthFEC Parity)
Grant Size = tamaño del paquete generado por
el cliente + cabecera IP
[eq.1]
Se puede calcular el número de mini-slots
disponibles entre dos mensajes MAPs, es decir,
el número de mini-slots de la trama TDMA a
través de la siguiente fórmula [eq.2].
nº mini - slots =
tasa enlace x intervalo entre MAPs
8 (bits/byte)x(bytes/mini - slot)
El tamaño final del paquete es: número de
palabras x DEC Code Word + (Preamble +
Guard Time)/8
[eq.5]
[eq.2]
Pero no todos estos mini-slots pueden ser
empleados por los usuarios para transmitir; los
que realmente se pueden emplear para este tipo
de servicio resultan de restarle a [eq.2] el
número de mini-slots de competición
configurados en el upstream.
Se han realizado múltiples simulaciones con
diferente número de usuarios, diferentes
combinaciones de tipos de servicios, y de
configuraciones de los mismos. Pero el
escenario de simulación más general sobre el
que se han efectuado simulaciones es el de la
figura 4.
nºmini-slots disponibles =
tasa enlace x intervalo entre MAPs
8 (bits/byte)x(bytes/mini - slot)
– 16 (competición)
[eq.3]
También es importante tener en cuenta el
tamaño de los paquetes DOCSIS para calcular el
número de mini-slots necesarios para enviar un
paquetes DOCSIS. Este cálculo se realiza con la
fórmula [eq.4].
Nºmini-slots para paquete = tamaño paquete
DOCSIS /(nºbytes/mini-slot)
[eq.4]
Para calcular el tamaño del paquete DOCSIS es
necesario conocer: el tamaño de las cabeceras
que son añadidas a los paquetes creados por el
cliente (20 bytes de cabecera IP y 26 bytes de
cabecera DOCSIS) y los bytes añadidos por el
código de corrección de errores que posee
DOCSIS. Los parámetros del código de
corrección de errores son:
Figura 4. Escenario de simulación DOCSIS.
Se van a detallar los parámetros particulares de
una prueba, sin embargo, no se va a dar una
información tan exhaustiva del resto de pruebas
6
realizadas para no incrementar en excesivo la
longitud de este artículo. Simplemente se
expondrán las conclusiones generales obtenidas
de todas las simulaciones.
until _ map =
[eq.7]
nº min i − slotsocupadosDatosEnMAP)
n º min i − slotsDisponiblesParaDatosEnMAP
Parámetros:
- Tiempo entre MAPs: 0,02 segundos
- Nº mini-slots por MAP, de [eq.2] : 400
- Nº mini-slots disponibles por MAP, de
[f.3]: 384
- Tasa total del enlace uspstream:
640Kbps
- Tasa disponible del enlace upstream,
de [eq.6]: 614.400bps
[eq.7] es la utilización de la trama TDMA, en %
tasa _ gen =
paqueteDOCSIS (bytes) * 8(bits / byte)
int ervalo _ generación _ paquetes
n º clientes
∑
[eq.8]
[eq.8] es la tasa de generación de paquetes
DOCSIS, en bits/seg
tasa _ util =
[eq.6]
[f.3]* 4(bytes / minislot) * 8(bits / byte)
int ervalo − MAPs
util _ upstream _ del _ disponible =
tasa _ generada _ clientes (bps )
x100 [eq.9]
tasa _ util _ upstream (bps )
La fórmula [eq.6] especifica la tasa de
transferencia máxima que es posible obtener en
el enlace upstream, debido a que no es posible
emplear toda la trama TDMA para transmitir
información útil.
[eq.9] es la utilización del upstream, dentro del
efectivo para poder transmitir datos.
util _ upstream _ total =
[eq.10]
tasa _ generada _ clientes(bps)
x100
tasa _ total _ upstream(640bps)
Los parámetros de los usuarios son los de la
tabla 2:
Tabla 2. Tasa de generación de clientes y
tipos de servicio.
Tasa generación de
paquetes IP
(bytes/seg)
Tipo de
servicio
Clientes
1, 2,3
Cliente
4
Cliente
5
393 /0,03
(109.800
bps)
39 /0,03
(10.400
bps)
39 /0,03
(10.400
bps)
UGS
Nominal
Interval
Grant
(seg)
0,03
Grant
Size
(bytes)
CM [1]
393
UGS
0,03
39
BE
_
_
[eq.10] es la utilización del upstream en total,
incluidos los mini-slots de competición
En este escenario se completaban el número de
mini-slots disponibles pero sólo en ciertos
momentos, luego no se generaba una tasa de
información superior a la capacidad útil del
enlace.
4.4. DOCSIS, conclusiones
Los resultados particulares para la prueba
descrita con detalle son los que a continuación
se presentan.
Según los parámetros configurados en los
clientes se puede calcular el número de minislots necesarios para transmitir, la utilización
máxima de un intervalo entre MAPs y el total de
tasa generada por todos los clientes, así como la
utilización del enlace. Para ello consultar tabla
3.
Tabla 4. Retardos de espera en cola en los
CMs.
Retardo
en cola
del
CM_1
(seg)
0,0226
Tabla 3. Parámetros de los clientes.
Clientes
[5]
[4]
[7]
[8]
1, 2, 3
464
116 100 418.133,3
4
5
86
86
22
22
[9]
Retardo
en cola
del CM_2
(seg)
Retardo
en cola
del CM_3
(seg)
Retardo
en cola
del CM_4
(seg)
Retardo
en cola
del CM_5
(seg)
0,0063
0,0121
0,01813
0,09578
El retardo (tabla 4) que se obtiene en la cola del
CM_5 (que tiene un tipo de servicio BestEffort) es el tiempo que transcurre hasta que
consigue que se le asignen mini-slots. Este
tiempo es debido en parte al tiempo entre MAPs
(tiempo entre posibles peticiones) y a que
[10]
68, 65,33
1
7
cuando realiza una petición es posible que el
CMTS no tenga recursos suficientes para él en
ese momento; en este caso debe quedar en
espera hasta que el CMTS tenga mini-slots
disponibles para su petición. Por tanto, los
paquetes irán acumulando retardo hasta que
puedan ser transmitidos.
-
Sin embargo, para el tipo de servicio UGS, el
CMTS asigna periódicamente los mini-slots que
necesitan, por eso si llega una petición de BestEffort cuando ya han sido asignados los recursos
a los flujos UGS y no quedan suficientes para la
petición Best-Effort, se queda en espera.
-
El retardo que obtienen estas transmisiones bajo
un tipo de servicio UGS es debido a la suma del
tiempo de transmisión por el enlace DOCSIS de
un paquete generado por el cliente (0,001
segundos para los paquetes del CM_4 y 0,0058
segundos para los paquetes de los CM 1, 2 Y 3)
más el tiempo de espera en cola correspondiente
en cada caso. Este es diferente para cada CM
debido a que depende del orden en el que el
CMTS asigna los mini-slots a los CMs para el
tipo de servicio UGS, como se puede ver en los
datos de la tabla 4.
-
Viendo los tiempos de espera en cola de los
CMs se puede decir en qué orden son asignados
los mini-slots a los CMs:
(1) CM_3
(2) CM_4
(3) CM_2
(4) CM_1
-
Tabla 5. Delay medio de las transmisiones.
Enlace
up
Delay
medio
Transmisió
n1
0,029
Transmisió
n2
0,012
75
Transmisión
3
0,01855
Transmisión
4
0,01935
Transmisión
5
0,097
Y en cuanto a los resultados de retardo medio
para cada transmisión (tabla 5), se puede
observar que la comunicación de la transmisión
5 (entre cliente_5 y destino_5), que tiene un tipo
de servicio Best-Effort asociado, genera una
comunicación con mayor delay medio, si lo
comparamos con el de las otras comunicaciones.
Esto no es sorprendente, sino que era algo
esperable si se recuerdan los resultados de
retardo en colas de los CMs.
-
Otras conclusiones generales que se pueden
obtener de todas las simulaciones efectuadas
son:
8
El retardo que experimentan los
paquetes que se transmiten en el
upstream depende del tiempo entre
MAPs que se estipule. Si este tiempo
es pequeño, el retardo será menor
debido a que los CMs podrán efectuar
peticiones (en el caso de tipo de
servicio BE) cada menor tiempo y
podrán transmitir datos cada menor
tiempo, reduciendo el tiempo que
deben esperar en sus colas esos datos.
Es necesario que la fragmentación esté
habilitada si se quiere transmitir un
paquete que no cabe en un intervalo de
MAP. Esta fragmentación sólo está
implementada en la versión DOCSIS
1.1 y sólo es posible seleccionarla en
OPNET para el tipo de servicio BestEffort. Por tanto, no es posible
transmitir paquetes que tengan una
duración superior a la de un intervalo
de MAP para un tipo de servicio UGS,
porque no se van a poder fragmentar.
Se ha podido observar que la carga que
suponen las cabeceras IP y DOCSIS
(cabecera y corrección de errores) es
muy elevada, siendo muy pequeño el
porcentaje de información útil que se
transmite. De esta forma se gana en
inmunidad frente a ruido, aunque se
desperdicia parte de la capacidad del
enlace para transmisión de información
útil.
Se
ha
podido
comparar
el
comportamiento del servicio BestEffort frente al UGS, y como era de
esperar, el retardo obtenido para el
servicio UGS ha sido inferior que el
obtenido para el servicio Best-Effort.
Esto se debe a que el tipo de servicio
Best-Effort no da garantías de QoS,
porque sólo se le permite transmitir
cuando hay recursos libres y el CMTS
se los asigna previa petición por parte
del CM. Sin embargo, en el servicio
UGS esto no es necesario ya que el
CMTS asigna periódicamente minislots, según la configuración inicial del
CM, para que pueda transmitir. Esto se
traduce en un menor tiempo de espera
en cola para los paquetes que reciben
un tipo de servicio UGS.
El retardo que perciben los paquetes
bajo un tipo de servicio UGS en el
upstream depende básicamente del
tiempo de transmisión de los paquetes
y del tiempo que debe esperar cada
paquete para encontrar sus mini-slots,
pero siempre dentro del mismo
intervalo de MAP.
-
-
-
-
La primera diferencia es que se intentará
introducir SIP como protocolo de señalización
de aplicación puesto que es el más empleado
hoy en día en aplicaciones multimedia.
Además para el tipo UGS se ha podido
comprobar que en cada CM, el tiempo
de espera es diferente (en una situación
en la que a todos los CMs llegan los
paquetes en los mismos instantes de
tiempo), debido a que depende del
orden en el que el CMTS emita las
asignaciones de los mini-slots en cada
MAP.
Cuando el enlace upstream se
encuentra saturado, se produce un
incremento del retardo en las
transmisiones, incluso por parte de
aquellas que tienen un tipo de servicio
UGS. Sin embargo, no es un
incremento sustancial y se mantiene
dentro de unos márgenes, porque este
tipo de servicio debe garantizar unas
características de QoS.
Se ha podido observar que cuando
existen varios CMs con un tipo de
servicio Best-Effort, deben competir
por realizar sus peticiones sobre los
mismos mini-slots. Por ello en muchas
ocasiones tienen lugar colisiones,
produciéndose de esta forma un
incremento en el tiempo de espera en
cola.
La transmisión sobre el enlace
downstream obtiene un menor retardo
que para el upstream debido a que tiene
una mayor tasa de transmisión
(27Mbps) y además no tiene técnica de
acceso TDMA, luego no hay tiempos
de espera producidos por la forma de la
trama TDMA.
Por otra parte, hay que tener en cuenta que una
red de acceso de cable es muy diferente de una
línea xDSL. En una red de cable hay que hacer
una reserva de recursos incluso dentro de ella
misma porque el enlace upstream es un medio
compartido, luego se hacen necesarias la
autorización y reserva de recursos en el CMTS.
Sin embargo, en la red xDSL cada usuario tiene
un ancho de banda para él, luego no tiene que
competir con otros usuarios por el medio y por
tanto se hace innecesaria una reserva
equivalente a la de cable en el router frontera
xDSL.
Teniendo muy en cuenta sus diferencias pero
también intentando llegar a una arquitectura
genérica basada en la de PacketCable se están
dirigiendo los esfuerzos del proyecto QUAR2.
Referencias.
[1]
http://projects.celticinitiative.org/QUAR2/description.htm
[2] Z.Wang, “Internet QoS: Architectures and
Mechanisms for Quality of Service, Morgan
Kaufmann Publishers, 2001.
[3] Dynamic QoS PacketCable 1.0 spec. I02 0008 DVB 01-04, ITU-T J.163, ETSI TS 101 9095
5. Conclusiones y líneas futuras.
[4] Security PacketCable 1.0 spec. I01 99-12
DVB 01-04, ITU-T draft J.170 ETSI TS 101
909-11
Este estudio de la arquitectura PacketCable ha
sido el punto de partida para generalizar su uso
a una arquitectura heterogénea. De esta forma,
se han asentado las bases para crear una
arquitectura jerárquica que sea capaz de
asegurar que las aplicaciones multimedia que
sobre ella se desarrollen reciban una calidad de
servicio, y todo ello que se pueda realizar con
independencia de qué red de acceso o red
troncal se tenga a disposición.
[5] DOCSIS 1.1 RFI spec.I05 00-07, ITU-T
J.112 Annex B (part) ETSI ES 201 488 v1.1.1
[6] RFC 2748, The COPS (Common Open
Policy Service) Protocol
[7] RFC 2205, Resource ReSerVation Protocol
(RSVP). Version 1 Functional Specification.
[8] NCS PacketCable 1.0 spec. I02, Diciembre
1999
La arquitectura heterogénea en la que se está
trabajando actualmente (dentro del proyecto
QUAR2) comprende la integración de red de
acceso de cable, xDSL e incluso de redes de
acceso EPON. Y para asegurar la calidad de
servicio se está estableciendo una señalización
basada en la de la figura 3, con alguna salvedad.
9