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

More documents

Recommendations

Info

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
Page 2 and 3: Aunque en el estudio que en este do
Page 4 and 5: MTAo CMTSsocketclient_openclient_ac
Page 6 and 7: - Nominal Grant Interval : “confi

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?