Calidad de Servicio en aplicaciones multimedia sobre redes de ...

Aunque en el estudio que en este documento sepresenta no estén incluidas, la arquitecturaPacketCable soporta más funciones extremoextremo,además de la provisión de Calidad deServicio, entre las cuales se encuentran, laseguridad [4], facturación y otras funciones degestión de la red.Junto a estas especificaciones de PacketCableque definen una arquitectura a nivel IP, esnecesario tener en cuenta también el medio en elque nos encontramos, una red de cable, endonde el enlace upstream es un mediocompartido (con un sistema de acceso al medioTDMA y con tasa de transmisión máxima de10Mbps). Esto se traduce en la necesidad demecanismos de provisión de QoS dentro de lared de cable misma para permitir nuevosservicios a nuevos clientes sin disminuir lacalidad de los ya existentes. De la definición delas características de QoS, así como de otrasfuncionalidades, en la red de acceso de cable seocupan las especificaciones DOCSIS 1.1 (DataOver Cable Service Interface Specifications)[5]. Y por tanto, hay que tener en cuenta laexistencia de una integración entre losprotocolos a nivel IP definidos por PacketCablecon la capa de enlace (DOCSIS).Así, DOCSIS provee cinco tipos de servicio enel upstream (sentido cable modem- CMTS ocabecera de cable):- Unsolicited Grant Service (UGS).- Real-Time Polling Service (rtPS).- Unsolicited Grant Service with ActivityDetection (UGS-AD).- Non-Real Time Polling ServiceFigura 1. Modelo de arquitectura dePacketCable en OPNET.- MTA (Multimedia Terminal Adapter ,equipo de usuario)- CM (Cable Modem, módem cable en elusuario)- CMTS (Cable Modem TeminationSystem, cabecera de cable)- CMS (Call Management Server, gestorde acceso de usuarios)Estos componentes de red han sido diseñados apartir de elementos disponibles en OPNET, sinembargo, han tenido que ser modificadosprincipalmente para introducir laimplementación de los protocolos necesariospara proveer QoS y que no estabanimplementados en la herramienta de simulación.Estos protocolos que se han implementado en laherramienta OPNET para modelar laarquitectura de PacketCable desempeñan unaserie de funcionalidades en la red:(nrtPS). - autorización de los usuarios- Best Effort Service (BE).- autorización de los recursos que demandan- reserva de los recursos- activación de los recursosPor ello en este documento también se presentala evaluación de algunos de estos tipos deservicio en la herramienta de simulaciónOPNET.CMSPDP3. Descripción del trabajo.COPS DQoSPara abordar el estudio de la arquitecturaPacketCable se ha modelado la misma dentro dela herramienta de simulación OPNET. En dichomodelo se identifican los componentes de redbásicos de las especificacionesPacketCable/IPCableCom (Figura 1), que son:CMTSPEPFigura 2. Jerarquía CMTS-CMS, a través delprotocolo COPS.Esta arquitectura tiene una jerarquía, basada enel protocolo COPS [6] (figura 2), porque estasfuncionalidades deben ser desempeñadas porsus componentes siguiendo una cierta secuencia2

para llegar a proveer calidad de servicio. Enprimer lugar se hace una autorización de losusuarios (esta función la desempeña el CMS(Call Manager Server)), elemento que gestionalas diferentes aplicaciones. Una vez que unusuario ha sido autorizado, se deben autorizarlos recursos que demanda, es decir, comprobarque no demanda más cantidad de recursos de losque tiene en su SLA (de lo cual también tienecontrol el CMS). Es decir, el CMS realiza unagestión a alto nivel. El siguiente paso (siguientenivel en la jerarquía) es comprobar que existanrecursos suficientes en la red de cable paraproveer la QoS que demanda el cliente (de locual tiene el control el CMTS, porque es quientiene el conocimiento de los recursos que sonempleados y los que quedan libres en cadamomento). Con este modelo jerárquico, sialguna de estas autorizaciones no essatisfactoria hace que no se continúe con elestablecimiento de la comunicación, y por tantono se llegaría a autorizar o a reservar recursos.De esta forma, la comunicación se corta encuanto se sabe que no hay posibilidad deejecutarla con las garantías solicitadas y no semalgastan los recursos.Una vez que la autorización de los recursos hasido satisfactoria, los clientes de lacomunicación pueden reservar los recursos en lared de cable para poder transmitir con losparámetros de QoS demandados en el inicio delestablecimiento de la comunicación. Estapetición de reserva por parte de los clientes esefectuada al CMTS, que como ya se ha dicho, esel elemento que tiene el control de los recursosexistentes y disponibles para su utilización. Deesta forma, si existen los recursos demandados,se los reserva al cliente. Además también secontrola que no se demanden en la reserva másrecursos de los que fueron autorizados en laetapa de autorización, de lo cual también tieneun control el CMTS. Es decir, el CMTS realizauna gestión de los recursos físicamente dentrode la jerarquía.- COPS PacketCable (basado en el protocoloCOPS estándar, [6]): se ocupa de laautorización de los usuarios, así como de laautorización de los recursos en la red.- RSVP+ (basado en el protocolo RSVPestándar, [7]): se ocupa de la reserva y de laactivació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 elmecanismo de autorización, así como el dela reserva.4. Resultados.Las simulaciones en OPNET realizadas tienendos objetivos diferentes, por una parte, sepretende testear el uso de la arquitectura dePacketCable para extraer conclusiones sobre laCalidad de Servicio dispensada. Y por otraparte, se han realizado simulaciones para ver elpropio comportamiento de una red de cableDOCSIS, así como los resultados que ofrecenlos diferentes tipos de servicio en el upstreamque son ofrecidos por ella misma a nivel de capafísica.4.1. Configuración arquitecturaPacketCable.Se han realizado simulaciones de la arquitecturaen OPNET (Figura 1) creada con el objetivo decomprobar el establecimiento de la señalizaciónadecuada, acorde con la descrita en la figura 3.Así como para comprobar el comportamientoobtenido por una aplicación que deba serautorizada, y para la que se realicen reservas derecursos a través de RSVP+ y se hagan cumplircon el planificador WFQ (Weighted FairQueueing). Y todo ello comparándolo con elcomportamiento de una aplicación que no haganingún tipo de petición de QoS.Finalmente, en el modelo de PacketCable existeuna última etapa, que es la de la activación delos recursos. Esta etapa tiene su razón porquelos recursos han sido reservados por el CMTS,pero hasta que el cliente no los activa no tomaposesión de ellos. Esto hace posible que entre lareserva y la activación pueda ser posible queotros clientes hagan uso de los recursos de lared, permitiendo hacer un uso más eficiente delos limitados recursos.Las funcionalidades son resueltas por lossiguientes protocolos:3

MTAo CMTSsocketclient_openclient_acceptclient_requestCMSMTAdprotocolo RSVP ni el RSVP+. Por tanto, sólo sevan a hacer reservas y activaciones de losrecursos en la sección de red donde se haconfigurado el protocolo RSVP+.ncs_initgate_setgate_set_ackncs_initncs_init4.2. Conclusiones arquitectura PacketCable.ncs_init_ackrsvp_pathrsvp_resvrsvp_commitrsvp_commit_ackrsvp_tearrsvp_tear_ackncs_finishgate_setgate_set_ackgate_opengate_openstart communicationgate_closefinish communicationncs_init_ackrsvp_pathrsvp_resvrsvp_commitrsvp_commit_ackncs_finishEl tiempo total que pasa desde que la aplicacióninicia su autorización (envío del mensaje Ncs-Init) hasta que recibe el mensaje RSVP+Commit-Ack (significa que los recursos han sidoactivados) es de 0,2347 segundos. Este tiempoes el que debe transcurrir hasta que la aplicaciónrealmente recibe la calidad de servicio que se leasignó (cuyo cumplimiento es misión delplanificador WFQ).Figura 3. Señalización.En particular las simulaciones realizadas hantenido una duración de 300 segundos y se hanconfigurado dos aplicaciones de VoIP (Voiceover IP). Los parámetros son:(1) una aplicación de VoIP con RSVP+ yNCS habilitados:- norma G.723.1 que implica una tasa detransmisión de 5,3Kbps.- la longitud de los silencios sigue unadistribución exponencial de media 0,65segundos.- Tipo de servicio Interactive Voice.- RSVP parameters activados- Señalización NCS.- La aplicación se establece entre loselementos del escenario MTA y destination.(2) una aplicación de VoIP sin RSVP+ niNCS habilitados:- norma G.711 que implica una tasa detransmisión de 64Kbps- la longitud de los silencios sigue unadistribución exponencial de media 0,65segundos.- Tipo de servicio Interactive Voice.- RSVP parameters no activados.- Sin ningún tipo de señalización.- Esta aplicación se establece entre elelemento llamado Embedded_MTA ydestination_no_RSVP.En este escenario sólo soportan dos nodos elprotocolo RSVP+: el MTA y el CMTS en suinterfaz con el medio compartido. Esto esporque es entre estos elementos en donde sedebe establecer la reserva de recursos en unescenario de cable PacketCable. El resto deelementos de la arquitectura no soportan ni elTabla 1. Resultados de delay de lasaplicaciones.Aplicación Delay Jitter delay DesviaciónVoz conRSVP+Voz sinRSVP+estándar0,0126 5,4728E-5 1,4696E-50,6033 1,6576 0,4511En la tabla 1 se presentan los resultados encuanto al comportamiento de las aplicacionessobre el escenario. Para ello se presenta el delayo retardo extremo-extremo, el jitter delay y ladesviación estándar del delay.Atendiendo a estos resultados de la tabla 1, laaplicación de voz con RSVP+ tiene mejorcomportamiento que la de voz sin RSVP+ encuanto a delay, jitter delay, así como desviciónestándar del delay.Por tanto, se ha comprobado que la aplicación ala que se le reservan y activan los recursos quenecesita para su ejecución obtiene unos valoresde delay, jitter delay, y desviación estándar deldelay mucho mejores que una que no disfrutadel modelo PacketCable. Es decir, se haconseguido proporcionar a esta aplicación ciertonivel de Calidad de Servicio gracias al modelocontrolado IntServ [2] que provee OPNET.Este modelo es implementado en OPNETgracias al planificador de paquetes WFQ que seha configurado en los nodos de la arquitectura,en especial en el CMTS. Este permite asegurarun determinado comportamiento a los flujos dedatos.4.3. DOCSIS, tipos de servicio en elupstream, configuración.4

El modelo de DOCSIS 1.1 provee 5 tipos deservicios, que ya se han mencionadoanteriormente. En OPNET sólo es posiblerealizar simulaciones de los tipos UGS y BE,por ello sólo se han podido estudiar estos dostipos de servicios.Los mini-slots en los que está dividido el enlaceupstream del cable pueden ser empleados comoasignaciones para los usuarios para podertransmitir información, como slots decompetición, para que otras estaciones nuevasse puedan unir al medio y como de control. Yexisten unos mensajes llamados MAP (enviadospor el enlace dowstream), mediante los cuales,el CMTS realiza las asignaciones de mini-slots alos diferentes usuarios y define los mini-slots decontrol (no son asignaciones para latransmisión de usuarios) a través de elementosde información.Cada elemento de información representa untipo de mini-slot. Así, los posibles tipos deelementos de información que puede transportarun mensaje MAP son: Request (petición),Request/data (petición con piggybacking), Shortgrant (asignación), Long grant (asignación),Pending (asignación), Initial maintenance(aparecen cada mucho tiempo), Stationmaintenance (aparecen cada mucho tiempo).Los tipos de elementos de información másimportantes son los de petición (con los que sedefinen los mini-slots que se dedicarán en latrama TDMA para la competición de todos losusuarios, que emplearán para demandar minislotspara poder transmitir su información). Ypor otra parte, los de asignación, es decir, losmini-slots asignados para la transmisión a cadausuario.- Frecuencia central: 8MHz- Bytes por mini-slot: 4También se deben configurar una serie deparámetros relacionados con los mensajes MAP,que se pueden ver a continuación:- tiempo entre MAPs: se define en cadasimulació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 serenviados en los elementos de informaciónreducidos: 128 bytes- tamaño límite de bytes que pueden serenviados en los elementos de informacióngrandes: 1000 bytes- Mini-slots de mantenimiento inicial: 4mini-slots/segundo- Mini-slots de mantenimiento de la estación:2 mini-slots/segundoPor otra parte, se deben presentar los diferentestipos de servicio que han sido objeto de estudio:UGS y BE.El tipo de servicio UGS se caracteriza poreliminar el overhead y la latencia queintroducen las peticiones de los CMs para podertransmitir, porque el CMTS hace asignacionesperiódicas de forma que asegura o reserva undeterminado ancho de banda en el upstreampara cada cable modem que tiene configuradoeste tipo de servicio. En cambio, para el tipoBest-Effort (BE) no se dispensan asignacionesperiódicas, sino que debe emplear los mini-slotsde competición para solicitar al CMTS que leasigne mini-slots en el siguiente MAP, y asípoder transmitir.Los parámetros de configuración para cadaenlace, y los valores particulares que se hanempleado en las simulaciones son lossiguientes:Estos tipos de servicio también poseen unosparámetros que deben ser configurados. Éstosson:(1) Best-Effort (BE):(1) Downstream (sentido CMTS-CM):- identificador de canal sobre el que se- modulación: 64QAMquiere transmitir = 0,- tasa datos: 27Mbps - parámetros DOCSIS 1.1- ancho de banda del canal: 6MHz - fragmentación habilitada (sólo es- Frecuencia central: 500MHzconfigurable en DOCSIS 1.1)- Latencia entrelazador: profundidad deentrelazado: 32 e incremento :4(2) Unsolicited Grant (UGS):(2) Upstream (sentido CM-CMTS): - identificador de canal sobre el que sequiere transmitir = 0- modulación para un canal: QPSK - versión DOCSIS 1.1- tasa máxima del enlace: 640Kbps - Grant Size para cada CM- ancho de banda del canal: 800KHz“configurable en cada simulación”=5

- Nominal Grant Interval : “configurableen cada simulación”- Fragmentación no habilitada (no esposible habilitarla en estaimplementación de OPNET).Hay que hacer una serie de consideraciones paraconfigurar los parámetros Nominal GrantInterval y Grant Size para el servicio UGS:- El Nominal Grant Interval debe seralgo superior al tiempo entre MAPs.Este tiempo entre MAPs define latrama básica en tiempo del TDMA- El Grant Size viene dado en generalpor [eq.1].Grant Size = tamaño del paquete generado porel cliente + cabecera IP[eq.1]Se puede calcular el número de mini-slotsdisponibles entre dos mensajes MAPs, es decir,el número de mini-slots de la trama TDMA através de la siguiente fórmula [eq.2].tasa enlace x intervalo entre MAPs [eq.2]nº mini - slots =8 (bits/byte)x(bytes/mini - slot)Pero no todos estos mini-slots pueden serempleados por los usuarios para transmitir; losque realmente se pueden emplear para este tipode servicio resultan de restarle a [eq.2] elnúmero de mini-slots de competiciónconfigurados en el upstream.nºmini-slots disponibles =tasa enlace x intervaloentre MAPs8 (bits/byte)x(bytes/mini -slot)– 16 (competición)(1) para un tamaño de paquete DOCSIS (antesde añadir el código de corrección) inferiora 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(2) Para un tamaño de paquete superior a 66bytes:- Preamble length: 56 bits- FEC Error Correction: 16 bytes- FEC Codeword Length: 226 bytes- Guard time: 40 bits- Last Codeword Mode: Fixe-lengthPara calcular el tamaño del paquete DOCSISfinal se tiene que efectuar los siguientescálculos:Nº palabras código: tamaño del paquete sincorrección de errores/(FEC Code Word Length-FEC Parity)El tamaño final del paquete es: número depalabras x DEC Code Word + (Preamble +Guard Time)/8[eq.5]Se han realizado múltiples simulaciones condiferente número de usuarios, diferentescombinaciones de tipos de servicios, y deconfiguraciones de los mismos. Pero elescenario de simulación más general sobre elque se han efectuado simulaciones es el de lafigura 4.[eq.3]También es importante tener en cuenta eltamaño de los paquetes DOCSIS para calcular elnúmero de mini-slots necesarios para enviar unpaquetes DOCSIS. Este cálculo se realiza con lafórmula [eq.4].Nºmini-slots para paquete = tamaño paqueteDOCSIS /(nºbytes/mini-slot)[eq.4]Para calcular el tamaño del paquete DOCSIS esnecesario conocer: el tamaño de las cabecerasque son añadidas a los paquetes creados por elcliente (20 bytes de cabecera IP y 26 bytes decabecera DOCSIS) y los bytes añadidos por elcódigo de corrección de errores que poseeDOCSIS. Los parámetros del código decorrección de errores son:Figura 4. Escenario de simulación DOCSIS.Se van a detallar los parámetros particulares deuna prueba, sin embargo, no se va a dar unainformación tan exhaustiva del resto de pruebas6

ealizadas para no incrementar en excesivo lalongitud de este artículo. Simplemente seexpondrán las conclusiones generales obtenidasde todas las simulaciones.until _ map =nºmin i − slotsocupadosDatosEnMAP)Parámetros:nºmin i − slotsDisponiblesParaDatosEnMAP- Tiempo entre MAPs: 0,02 segundos- Nº mini-slots por MAP, de [eq.2] : 400 [eq.7] es la utilización de la trama TDMA, en %- Nº mini-slots disponibles por MAP, de[f.3]: 384tasa _ gen =- Tasa total del enlace uspstream:paqueteDOCSIS(bytes)*8(bits/byte)640Kbps∑- Tasa disponible del enlace upstream,nº clientes intervalo_generación_paquetesde [eq.6]: 614.400bps[eq.8][eq.7]tasa_util =[f.3]*4( bytes/ minislot)*8(bits/byte)intervalo−MAPs[eq.6]La fórmula [eq.6] especifica la tasa detransferencia máxima que es posible obtener enel enlace upstream, debido a que no es posibleemplear toda la trama TDMA para transmitirinformación útil.Los parámetros de los usuarios son los de latabla 2:Tabla 2. Tasa de generación de clientes ytipos de servicio.Tasa generación depaquetes IP(bytes/seg)Clientes1, 2,3Cliente4Cliente5393 /0,03(109.800bps)39 /0,03(10.400bps)39 /0,03(10.400bps)Tipo deservicioNominalIntervalGrant(seg)GrantSize(bytes)CM [1]UGS 0,03 393UGS 0,03 39BE _ _Según los parámetros configurados en losclientes se puede calcular el número de minislotsnecesarios para transmitir, la utilizaciónmáxima de un intervalo entre MAPs y el total detasa generada por todos los clientes, así como lautilización del enlace. Para ello consultar tabla3.Tabla 3. Parámetros de los clientes.Clientes[5] [4] [7] [8] [9] [10]1, 2, 3 464 1164 86 225 86 22100 418.133,3 68,165,33[eq.8] es la tasa de generación de paquetesDOCSIS, en bits/segutil _ upstream _ del _ disponible =tasa _ generada _ clientes ( bps ) x100 [eq.9]tasa _ util _ upstream ( bps )[eq.9] es la utilización del upstream, dentro delefectivo para poder transmitir datos.util _ upstream _ total =tasa _ generada _ clientes(bps)x100tasa _ total _ upstream(640bps)[eq.10][eq.10] es la utilización del upstream en total,incluidos los mini-slots de competiciónEn este escenario se completaban el número demini-slots disponibles pero sólo en ciertosmomentos, luego no se generaba una tasa deinformación superior a la capacidad útil delenlace.4.4. DOCSIS, conclusionesLos resultados particulares para la pruebadescrita con detalle son los que a continuaciónse presentan.Tabla 4. Retardos de espera en cola en losCMs.Retardoen coladelCM_1(seg)Retardoen coladel CM_2(seg)Retardoen coladel CM_3(seg)Retardoen coladel CM_4(seg)Retardoen coladel CM_5(seg)0,0226 0,0063 0,0121 0,01813 0,09578El retardo (tabla 4) que se obtiene en la cola delCM_5 (que tiene un tipo de servicio Best-Effort) es el tiempo que transcurre hasta queconsigue que se le asignen mini-slots. Estetiempo es debido en parte al tiempo entre MAPs(tiempo entre posibles peticiones) y a que7

cuando realiza una petición es posible que elCMTS no tenga recursos suficientes para él enese momento; en este caso debe quedar enespera hasta que el CMTS tenga mini-slotsdisponibles para su petición. Por tanto, lospaquetes irán acumulando retardo hasta quepuedan ser transmitidos.Sin embargo, para el tipo de servicio UGS, elCMTS asigna periódicamente los mini-slots quenecesitan, por eso si llega una petición de Best-Effort cuando ya han sido asignados los recursosa los flujos UGS y no quedan suficientes para lapetición Best-Effort, se queda en espera.El retardo que obtienen estas transmisiones bajoun tipo de servicio UGS es debido a la suma deltiempo de transmisión por el enlace DOCSIS deun paquete generado por el cliente (0,001segundos para los paquetes del CM_4 y 0,0058segundos para los paquetes de los CM 1, 2 Y 3)más el tiempo de espera en cola correspondienteen cada caso. Este es diferente para cada CMdebido a que depende del orden en el que elCMTS asigna los mini-slots a los CMs para eltipo de servicio UGS, como se puede ver en losdatos de la tabla 4.Viendo los tiempos de espera en cola de losCMs se puede decir en qué orden son asignadoslos mini-slots a los CMs:(1) CM_3(2) CM_4(3) CM_2(4) CM_1Tabla 5. Delay medio de las transmisiones.upDelaymedio0,029 0,01275EnlaceTransmisión 1Transmisión 2Transmisión3Transmisión4Transmisión50,01855 0,01935 0,097Y en cuanto a los resultados de retardo mediopara cada transmisión (tabla 5), se puedeobservar que la comunicación de la transmisión5 (entre cliente_5 y destino_5), que tiene un tipode servicio Best-Effort asociado, genera unacomunicación con mayor delay medio, si locomparamos con el de las otras comunicaciones.Esto no es sorprendente, sino que era algoesperable si se recuerdan los resultados deretardo en colas de los CMs.Otras conclusiones generales que se puedenobtener de todas las simulaciones efectuadasson:- El retardo que experimentan lospaquetes que se transmiten en elupstream depende del tiempo entreMAPs que se estipule. Si este tiempoes pequeño, el retardo será menordebido a que los CMs podrán efectuarpeticiones (en el caso de tipo deservicio BE) cada menor tiempo ypodrán transmitir datos cada menortiempo, reduciendo el tiempo quedeben esperar en sus colas esos datos.- Es necesario que la fragmentación estéhabilitada si se quiere transmitir unpaquete que no cabe en un intervalo deMAP. Esta fragmentación sólo estáimplementada en la versión DOCSIS1.1 y sólo es posible seleccionarla enOPNET para el tipo de servicio Best-Effort. Por tanto, no es posibletransmitir paquetes que tengan unaduración superior a la de un intervalode MAP para un tipo de servicio UGS,porque no se van a poder fragmentar.- Se ha podido observar que la carga quesuponen las cabeceras IP y DOCSIS(cabecera y corrección de errores) esmuy elevada, siendo muy pequeño elporcentaje de información útil que setransmite. De esta forma se gana eninmunidad frente a ruido, aunque sedesperdicia parte de la capacidad delenlace para transmisión de informaciónútil.- Se ha podido comparar elcomportamiento del servicio Best-Effort frente al UGS, y como era deesperar, el retardo obtenido para elservicio UGS ha sido inferior que elobtenido para el servicio Best-Effort.Esto se debe a que el tipo de servicioBest-Effort no da garantías de QoS,porque sólo se le permite transmitircuando hay recursos libres y el CMTSse los asigna previa petición por partedel CM. Sin embargo, en el servicioUGS esto no es necesario ya que elCMTS asigna periódicamente minislots,según la configuración inicial delCM, para que pueda transmitir. Esto setraduce en un menor tiempo de esperaen cola para los paquetes que recibenun tipo de servicio UGS.- El retardo que perciben los paquetesbajo un tipo de servicio UGS en elupstream depende básicamente deltiempo de transmisión de los paquetesy del tiempo que debe esperar cadapaquete para encontrar sus mini-slots,pero siempre dentro del mismointervalo de MAP.8

- Además para el tipo UGS se ha podidocomprobar que en cada CM, el tiempode espera es diferente (en una situaciónen la que a todos los CMs llegan lospaquetes en los mismos instantes detiempo), debido a que depende delorden en el que el CMTS emita lasasignaciones de los mini-slots en cadaMAP.- Cuando el enlace upstream seencuentra saturado, se produce unincremento del retardo en lastransmisiones, incluso por parte deaquellas que tienen un tipo de servicioUGS. Sin embargo, no es unincremento sustancial y se mantienedentro de unos márgenes, porque estetipo de servicio debe garantizar unascaracterísticas de QoS.- Se ha podido observar que cuandoexisten varios CMs con un tipo deservicio Best-Effort, deben competirpor realizar sus peticiones sobre losmismos mini-slots. Por ello en muchasocasiones tienen lugar colisiones,produciéndose de esta forma unincremento en el tiempo de espera encola.- La transmisión sobre el enlacedownstream obtiene un menor retardoque para el upstream debido a que tieneuna mayor tasa de transmisión(27Mbps) y además no tiene técnica deacceso TDMA, luego no hay tiemposde espera producidos por la forma de latrama TDMA.5. Conclusiones y líneas futuras.Este estudio de la arquitectura PacketCable hasido el punto de partida para generalizar su usoa una arquitectura heterogénea. De esta forma,se han asentado las bases para crear unaarquitectura jerárquica que sea capaz deasegurar que las aplicaciones multimedia quesobre ella se desarrollen reciban una calidad deservicio, y todo ello que se pueda realizar conindependencia de qué red de acceso o redtroncal se tenga a disposición.La arquitectura heterogénea en la que se estátrabajando actualmente (dentro del proyectoQUAR2) comprende la integración de red deacceso de cable, xDSL e incluso de redes deacceso EPON. Y para asegurar la calidad deservicio se está estableciendo una señalizaciónbasada en la de la figura 3, con alguna salvedad.La primera diferencia es que se intentaráintroducir SIP como protocolo de señalizaciónde aplicación puesto que es el más empleadohoy en día en aplicaciones multimedia.Por otra parte, hay que tener en cuenta que unared de acceso de cable es muy diferente de unalínea xDSL. En una red de cable hay que haceruna reserva de recursos incluso dentro de ellamisma porque el enlace upstream es un mediocompartido, luego se hacen necesarias laautorización y reserva de recursos en el CMTS.Sin embargo, en la red xDSL cada usuario tieneun ancho de banda para él, luego no tiene quecompetir con otros usuarios por el medio y portanto se hace innecesaria una reservaequivalente a la de cable en el router fronteraxDSL.Teniendo muy en cuenta sus diferencias perotambién intentando llegar a una arquitecturagenérica basada en la de PacketCable se estándirigiendo los esfuerzos del proyecto QUAR2.Referencias.[1] http://projects.celticinitiative.org/QUAR2/description.htm[2] Z.Wang, “Internet QoS: Architectures andMechanisms for Quality of Service, MorganKaufmann Publishers, 2001.[3] Dynamic QoS PacketCable 1.0 spec. I02 00-08 DVB 01-04, ITU-T J.163, ETSI TS 101 909-5[4] Security PacketCable 1.0 spec. I01 99-12DVB 01-04, ITU-T draft J.170 ETSI TS 101909-11[5] DOCSIS 1.1 RFI spec.I05 00-07, ITU-TJ.112 Annex B (part) ETSI ES 201 488 v1.1.1[6] RFC 2748, The COPS (Common OpenPolicy Service) Protocol[7] RFC 2205, Resource ReSerVation Protocol(RSVP). Version 1 Functional Specification.[8] NCS PacketCable 1.0 spec. I02, Diciembre19999