Calidad de Servicio para aplicaciones multimedia sobre

redes heterogneas, redes de cable.

Elvira Narro, Rafael del Hoyo, David Abada, Lorena Bened, Pilar Fernndez de Alarcn, Juan Jos
Navamuel
Departamento de Electrnica y Comunicaciones, Instituto Tecnolgico de Aragn
Instituto Tecnolgico de Aragn, C/ Mara 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 Tecnologas de Red: Tecnologas y redes de acceso fijo: HFC
Otras reas involucradas: rea III: Internet, Calidad de Servicio
Resumen
Este artculo pretende presentar los esfuerzos realizados dentro del marco del proyecto CELTIC Quar2
[1] para proveer Calidad de Servicio en redes heterogneas, en especial dirigindonos hacia redes de
acceso de cable, para lo cual se propone una arquitectura basada en las especificaciones de
PacketCable/IPCablecom. El estudio e implementacin del modelo de la arquitectura mencionada se
realiza en la herramienta de simulacin OPNET.
A lo largo de este documento se mostrarn las funcionalidades de la arquitectura modelada, los
escenarios de simulacin estudiados, as como los mecanismos de QoS empleados, tanto a nivel IP como
los propios de una red de cable. Se expondrn las conclusiones alcanzadas despus de las simulaciones
de los escenarios y se plantearn las lneas en las que se contina trabajando actualmente.

En especial este documento recoge parte del

trabajo realizado en el Proyecto CELTIC Quar2
de bsqueda de un modelo comn para proveer
QoS en redes heterogneas desde el punto de
vista IP, sin olvidar la tecnologa subyacente. En
particular, la arquitectura base comn para redes
heterogneas 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. Introduccin.
En la actualidad numerosas tecnologas
permiten acceder a los usuarios finales a las
redes de informacin, 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)... Adems, en las redes troncales
podemos encontrar diferentes tecnologas que
tambin 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 heterognea porque es la unin
de diferentes tecnologas y aunque cada
tecnologas tiene unas particularidades, el
pegamento de todas ellas es el protocolo de
Internet (IP). Por otra parte, la aparicin de
nuevos servicios y aplicaciones multimedia
empiezan a demandar unos requerimientos
mucho ms estrictos en cuanto a retardo, ancho
de banda y variacin del retardo (jitter delay), es
decir, unos parmetros de Calidad de Servicio
(QoS) [2]. Esto ha suscitado la aparicin de
diferentes arquitecturas que
tienen como
objetivo la gestin y satisfaccin 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
simulacin 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
provisin de calidad de servicio a estos servicios
multimedia a nivel IP.

Aunque en el estudio que en este documento se

presenta no estn incluidas, la arquitectura
PacketCable soporta ms funciones extremoextremo, adems de la provisin de Calidad de
Servicio, entre las cuales se encuentran, la
seguridad [4], facturacin y otras funciones de
gestin de la red.
Junto a estas especificaciones de PacketCable
que definen una arquitectura a nivel IP, es
necesario tener en cuenta tambin 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 transmisin mxima de
10Mbps). Esto se traduce en la necesidad de
mecanismos de provisin 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 definicin de
las caractersticas 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 integracin 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, mdem 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 diseados a

partir de elementos disponibles en OPNET, sin
embargo, han tenido que ser modificados
principalmente
para
introducir
la
implementacin de los protocolos necesarios
para proveer QoS y que no estaban
implementados en la herramienta de simulacin.

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 desempean una
serie de funcionalidades en la red:
-

Por ello en este documento tambin se presenta

la evaluacin de algunos de estos tipos de
servicio en la herramienta de simulacin
OPNET.

autorizacin de los usuarios

autorizacin de los recursos que demandan
reserva de los recursos
activacin de los recursos

CMS
PDP

D
PS
CO

3. Descripcin del trabajo.

Para abordar el estudio de la arquitectura
PacketCable se ha modelado la misma dentro de
la herramienta de simulacin OPNET. En dicho
modelo se identifican los componentes de red
bsicos
de
las
especificaciones
PacketCable/IPCableCom (Figura 1), que son:

CMTS

S
Qo

PEP

Figura 2. Jerarqua CMTS-CMS, a travs del

protocolo COPS.
Esta arquitectura tiene una jerarqua, basada en
el protocolo COPS [6] (figura 2), porque estas
funcionalidades deben ser desempeadas por
sus componentes siguiendo una cierta secuencia

para llegar a proveer calidad de servicio. En

primer lugar se hace una autorizacin de los
usuarios (esta funcin la desempea 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 ms cantidad de recursos de los
que tiene en su SLA (de lo cual tambin tiene
control el CMS). Es decir, el CMS realiza una
gestin a alto nivel. El siguiente paso (siguiente
nivel en la jerarqua) 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 jerrquico, si
alguna de estas autorizaciones no es
satisfactoria hace que no se contine con el
establecimiento de la comunicacin, y por tanto
no se llegara a autorizar o a reservar recursos.
De esta forma, la comunicacin se corta en
cuanto se sabe que no hay posibilidad de
ejecutarla con las garantas solicitadas y no se
malgastan los recursos.

COPS PacketCable (basado en el protocolo

COPS estndar, [6]): se ocupa de la
autorizacin de los usuarios, as como de la
autorizacin de los recursos en la red.
RSVP+ (basado en el protocolo RSVP
estndar, [7]): se ocupa de la reserva y de la
activacin de los recursos.
Protocolo de sealizacin de aplicacin
(basado en el protocolo NCS estndar, [8]):
es necesario para que se inicie el
mecanismo de autorizacin, 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
fsica.

Una vez que la autorizacin de los recursos ha

sido satisfactoria, los clientes de la
comunicacin pueden reservar los recursos en la
red de cable para poder transmitir con los
parmetros de QoS demandados en el inicio del
establecimiento de la comunicacin. Esta
peticin 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 utilizacin. De
esta forma, si existen los recursos demandados,
se los reserva al cliente. Adems tambin se
controla que no se demanden en la reserva ms
recursos de los que fueron autorizados en la
etapa de autorizacin, de lo cual tambin tiene
un control el CMTS. Es decir, el CMTS realiza
una gestin de los recursos fsicamente dentro
de la jerarqua.

4.1.

Configuracin
PacketCable.

arquitectura

Se han realizado simulaciones de la arquitectura

en OPNET (Figura 1) creada con el objetivo de
comprobar el establecimiento de la sealizacin
adecuada, acorde con la descrita en la figura 3.
As como para comprobar el comportamiento
obtenido por una aplicacin que deba ser
autorizada, y para la que se realicen reservas de
recursos a travs de RSVP+ y se hagan cumplir
con el planificador WFQ (Weighted Fair
Queueing). Y todo ello comparndolo con el
comportamiento de una aplicacin que no haga
ningn tipo de peticin de QoS.

Finalmente, en el modelo de PacketCable existe

una ltima etapa, que es la de la activacin de
los recursos. Esta etapa tiene su razn porque
los recursos han sido reservados por el CMTS,
pero hasta que el cliente no los activa no toma
posesin de ellos. Esto hace posible que entre la
reserva y la activacin pueda ser posible que
otros clientes hagan uso de los recursos de la
red, permitiendo hacer un uso ms eficiente de
los limitados recursos.
Las funcionalidades son resueltas por los
siguientes protocolos:

CMTS

MTAo

protocolo RSVP ni el RSVP+. Por tanto, slo se

van a hacer reservas y activaciones de los
recursos en la seccin 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 aplicacin

inicia su autorizacin (envo 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 aplicacin
realmente recibe la calidad de servicio que se le
asign (cuyo cumplimiento es misin 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. Sealizacin.
En particular las simulaciones realizadas han
tenido una duracin de 300 segundos y se han
configurado dos aplicaciones de VoIP (Voice
over IP). Los parmetros son:

(1) una aplicacin de VoIP con RSVP+ y

NCS habilitados:
norma G.723.1 que implica una tasa de
transmisin de 5,3Kbps.
la longitud de los silencios sigue una
distribucin exponencial de media 0,65
segundos.
Tipo de servicio Interactive Voice.
RSVP parameters activados
Sealizacin NCS.
La aplicacin se establece entre los
elementos del escenario MTA y destination.

de

delay

de

las

Aplicacin

Delay

Jitter delay

Voz con
RSVP+
Voz sin
RSVP+

0,0126

5,4728E-5

Desviacin
estndar
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
desviacin estndar del delay.
Atendiendo a estos resultados de la tabla 1, la
aplicacin de voz con RSVP+ tiene mejor
comportamiento que la de voz sin RSVP+ en
cuanto a delay, jitter delay, as como desvicin
estndar del delay.
Por tanto, se ha comprobado que la aplicacin a
la que se le reservan y activan los recursos que
necesita para su ejecucin obtiene unos valores
de delay, jitter delay, y desviacin estndar del
delay mucho mejores que una que no disfruta
del modelo PacketCable. Es decir, se ha
conseguido proporcionar a esta aplicacin cierto
nivel de Calidad de Servicio gracias al modelo
controlado IntServ [2] que provee OPNET.

(2) una aplicacin de VoIP sin RSVP+ ni

NCS habilitados:
norma G.711 que implica una tasa de
transmisin de 64Kbps
la longitud de los silencios sigue una
distribucin exponencial de media 0,65
segundos.
Tipo de servicio Interactive Voice.
RSVP parameters no activados.
Sin ningn tipo de sealizacin.
Esta aplicacin 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 slo 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, configuracin.

El modelo de DOCSIS 1.1 provee 5 tipos de

servicios, que ya se han mencionado
anteriormente. En OPNET slo es posible
realizar simulaciones de los tipos UGS y BE,
por ello slo 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 informacin, como slots de
competicin, 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
transmisin de usuarios) a travs de elementos
de informacin.

Tambin se deben configurar una serie de

parmetros relacionados con los mensajes MAP,
que se pueden ver a continuacin:

Cada elemento de informacin representa un

tipo de mini-slot. As, los posibles tipos de
elementos de informacin que puede transportar
un mensaje MAP son: Request (peticin),
Request/data (peticin con piggybacking), Short
grant (asignacin), Long grant (asignacin),
Pending (asignacin), 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
peridicas 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
peridicas, sino que debe emplear los mini-slots
de competicin para solicitar al CMTS que le
asigne mini-slots en el siguiente MAP, y as
poder transmitir.

Los parmetros de configuracin para cada

enlace, y los valores particulares que se han
empleado en las simulaciones son los
siguientes:

Estos tipos de servicio tambin poseen unos

parmetros que deben ser configurados. stos
son:
(1) Best-Effort (BE):

(1) Downstream (sentido CMTS-CM):

modulacin: 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

simulacin
Grant Interval: se define en cada simulacin
nmero de mini-slots para hacer peticiones
(de competicin): 16
tamao lmite de bytes que pueden ser
enviados en los elementos de informacin
reducidos: 128 bytes
tamao lmite de bytes que pueden ser
enviados en los elementos de informacin
grandes: 1000 bytes
Mini-slots de mantenimiento inicial: 4
mini-slots/segundo
Mini-slots de mantenimiento de la estacin:
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 informacin ms

importantes son los de peticin (con los que se
definen los mini-slots que se dedicarn en la
trama TDMA para la competicin de todos los
usuarios, que emplearn para demandar minislots para poder transmitir su informacin). Y
por otra parte, los de asignacin, es decir, los
mini-slots asignados para la transmisin a cada
usuario.

Frecuencia central: 8MHz

Bytes por mini-slot: 4

de

identificador de canal sobre el que se

quiere transmitir = 0,
parmetros DOCSIS 1.1
fragmentacin habilitada
(slo es
configurable en DOCSIS 1.1)

(2) Unsolicited Grant (UGS):

(2) Upstream (sentido CM-CMTS):

modulacin para un canal: QPSK

tasa mxima del enlace: 640Kbps
ancho de banda del canal: 800KHz

identificador de canal sobre el que se

quiere transmitir = 0
versin DOCSIS 1.1
Grant Size para cada CM =
configurable en cada simulacin

(1) para un tamao de paquete DOCSIS (antes

de aadir el cdigo de correccin) 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 simulacin
Fragmentacin no habilitada (no es
posible
habilitarla
en
esta
implementacin de OPNET).

Hay que hacer una serie de consideraciones para

configurar los parmetros Nominal Grant
Interval y Grant Size para el servicio UGS:
-

(2) Para un tamao 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 bsica en tiempo del TDMA
El Grant Size viene dado en general
por [eq.1].

Para calcular el tamao del paquete DOCSIS

final se tiene que efectuar los siguientes
clculos:
N palabras cdigo: tamao del paquete sin
correccin de errores/(FEC Code Word LengthFEC Parity)

Grant Size = tamao del paquete generado por

el cliente + cabecera IP
[eq.1]
Se puede calcular el nmero de mini-slots
disponibles entre dos mensajes MAPs, es decir,
el nmero de mini-slots de la trama TDMA a
travs de la siguiente frmula [eq.2].
n mini - slots =

tasa enlace x intervalo entre MAPs

8 (bits/byte)x(bytes/mini - slot)

El tamao final del paquete es: nmero 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
nmero de mini-slots de competicin
configurados en el upstream.

Se han realizado mltiples simulaciones con

diferente nmero de usuarios, diferentes
combinaciones de tipos de servicios, y de
configuraciones de los mismos. Pero el
escenario de simulacin ms general sobre el
que se han efectuado simulaciones es el de la
figura 4.

nmini-slots disponibles =
tasa enlace x intervalo entre MAPs
8 (bits/byte)x(bytes/mini - slot)

16 (competicin)
[eq.3]

Tambin es importante tener en cuenta el

tamao de los paquetes DOCSIS para calcular el
nmero de mini-slots necesarios para enviar un
paquetes DOCSIS. Este clculo se realiza con la
frmula [eq.4].
Nmini-slots para paquete = tamao paquete
DOCSIS /(nbytes/mini-slot)
[eq.4]
Para calcular el tamao del paquete DOCSIS es
necesario conocer: el tamao de las cabeceras
que son aadidas a los paquetes creados por el
cliente (20 bytes de cabecera IP y 26 bytes de
cabecera DOCSIS) y los bytes aadidos por el
cdigo de correccin de errores que posee
DOCSIS. Los parmetros del cdigo de
correccin de errores son:

Figura 4. Escenario de simulacin DOCSIS.

Se van a detallar los parmetros particulares de
una prueba, sin embargo, no se va a dar una
informacin tan exhaustiva del resto de pruebas

realizadas para no incrementar en excesivo la

longitud de este artculo. Simplemente se
expondrn las conclusiones generales obtenidas
de todas las simulaciones.

until _ map =
[eq.7]
n min i slotsocupadosDatosEnMAP)
n min i slotsDisponiblesParaDatosEnMAP

Parmetros:
- 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 utilizacin de la trama TDMA, en %

tasa _ gen =
paqueteDOCSIS (bytes) * 8(bits / byte)
int ervalo _ generacin _ paquetes
n clientes

[eq.8]
[eq.8] es la tasa de generacin 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 frmula [eq.6] especifica la tasa de

transferencia mxima que es posible obtener en
el enlace upstream, debido a que no es posible
emplear toda la trama TDMA para transmitir
informacin til.

[eq.9] es la utilizacin del upstream, dentro del

efectivo para poder transmitir datos.

util _ upstream _ total =

[eq.10]
tasa _ generada _ clientes(bps)
x100
tasa _ total _ upstream(640bps)

Los parmetros de los usuarios son los de la

tabla 2:
Tabla 2. Tasa de generacin de clientes y
tipos de servicio.
Tasa generacin 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 utilizacin del upstream en total,

incluidos los mini-slots de competicin
En este escenario se completaban el nmero de
mini-slots disponibles pero slo en ciertos
momentos, luego no se generaba una tasa de
informacin superior a la capacidad til del
enlace.
4.4. DOCSIS, conclusiones

Los resultados particulares para la prueba

descrita con detalle son los que a continuacin
se presentan.

Segn los parmetros configurados en los

clientes se puede calcular el nmero de minislots necesarios para transmitir, la utilizacin
mxima de un intervalo entre MAPs y el total de
tasa generada por todos los clientes, as como la
utilizacin 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. Parmetros 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

cuando realiza una peticin 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 peticin. Por tanto, los
paquetes irn acumulando retardo hasta que
puedan ser transmitidos.

Sin embargo, para el tipo de servicio UGS, el

CMTS asigna peridicamente los mini-slots que
necesitan, por eso si llega una peticin de BestEffort cuando ya han sido asignados los recursos
a los flujos UGS y no quedan suficientes para la
peticin 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 transmisin 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)
ms 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

Transmisin
3
0,01855

Transmisin
4
0,01935

Transmisin
5
0,097

Y en cuanto a los resultados de retardo medio

para cada transmisin (tabla 5), se puede
observar que la comunicacin de la transmisin
5 (entre cliente_5 y destino_5), que tiene un tipo
de servicio Best-Effort asociado, genera una
comunicacin 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:

El retardo que experimentan los

paquetes que se transmiten en el
upstream depende del tiempo entre
MAPs que se estipule. Si este tiempo
es pequeo, el retardo ser menor
debido a que los CMs podrn efectuar
peticiones (en el caso de tipo de
servicio BE) cada menor tiempo y
podrn transmitir datos cada menor
tiempo, reduciendo el tiempo que
deben esperar en sus colas esos datos.
Es necesario que la fragmentacin est
habilitada si se quiere transmitir un
paquete que no cabe en un intervalo de
MAP. Esta fragmentacin slo est
implementada en la versin DOCSIS
1.1 y slo es posible seleccionarla en
OPNET para el tipo de servicio BestEffort. Por tanto, no es posible
transmitir paquetes que tengan una
duracin 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 correccin de errores) es
muy elevada, siendo muy pequeo el
porcentaje de informacin til que se
transmite. De esta forma se gana en
inmunidad frente a ruido, aunque se
desperdicia parte de la capacidad del
enlace para transmisin de informacin
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 garantas de QoS,
porque slo se le permite transmitir
cuando hay recursos libres y el CMTS
se los asigna previa peticin por parte
del CM. Sin embargo, en el servicio
UGS esto no es necesario ya que el
CMTS asigna peridicamente minislots, segn la configuracin 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 bsicamente del
tiempo de transmisin 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 sealizacin
de aplicacin puesto que es el ms empleado
hoy en da en aplicaciones multimedia.

Adems para el tipo UGS se ha podido

comprobar que en cada CM, el tiempo
de espera es diferente (en una situacin
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 mrgenes, porque este
tipo de servicio debe garantizar unas
caractersticas 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,
producindose de esta forma un
incremento en el tiempo de espera en
cola.
La transmisin sobre el enlace
downstream obtiene un menor retardo
que para el upstream debido a que tiene
una mayor tasa de transmisin
(27Mbps) y adems no tiene tcnica 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
lnea 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
autorizacin 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
tambin intentando llegar a una arquitectura
genrica basada en la de PacketCable se estn
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 lneas 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 heterognea. De esta forma,
se han asentado las bases para crear una
arquitectura jerrquica 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 disposicin.

[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 heterognea en la que se est

trabajando actualmente (dentro del proyecto
QUAR2) comprende la integracin 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 sealizacin
basada en la de la figura 3, con alguna salvedad.