Provisión de Calidad de Servicio Basada en Reservas para Entornos Móviles

Provisión de Calidad de Servicio Basada en Reservas para Entornos Móviles Alberto López 1, Héctor Velayos 3, Tomás Robles 2, Nuria Villaseñor 3 1 Departamento de Ingeniería de la Información y las Comunicaciones, Universidad de Murcia, Facultad de Informática, Campus Universitario de Espinardo - 30071 Murcia Teléfono 968 364607, Fax: 968 364151 E-mail: alberto@dif.um.es 2 Departamento de Ingeniería de Sistemas Telemáticos, Universidad Politécnica de Madrid ETSI Telecomunicación, Ciudad Universitaria 28040 Madrid Teléfono: 91 336 7332, Fax: 91 336 7333 E-mail: robles@dit.upm.es 3 Agora Systems S.A. c/ Aravaca 12 3ºB - 28040 Madrid Teléfono: 91 533 5857, Fax: fax: 91 534 8477 E-mail: {hvelayos, nuria_villasenor}@agoratechnologies.com Abstract. With the fast adoption of IP-based communications for mobile computing, users are expecting a similar service in wireless and wired networks. This raises the need for setting guarantees to the quality of the offered service (QoS), despite the technology of the access network or the mobility of the terminal. This generates a new challenge for QoS provision, as it will have to deal with terminals changing their point of attachment to the network. In this paper an optimisation for the operation of reservation based QoS is given for mobile environments: the coupling of the reservation protocol RSVP with different per-host micromobility protocols. The micro-mobility and QoS signalling mechanism are coupled either loosely via a triggering mechanism, or more tightly so the QoS and mobility information is carried by the same protocol. Qualitative and quantitative results of this coupling is presented. The procedure includes the comparison of performance parameters such as delay, loss and throughput when protocols are coupled and de-coupled. 1 Introducción. El crecimiento de la industria de telefonía móvil en la última década ha sido exponencial, basado principalmente en sistemas existentes de 2ª generación como GSM y tráfico de voz. Con la llegada de sistemas de 3ª generación como UMTS se espera que aproximadamente en el año 2005 el número de subscriptores de servicios móviles en el mundo supere al número de usuarios de telefonía fija, si no antes. Por otro lado, la cantidad de tráfico de datos de las redes fijas ha sufrido un incremento explosivo, debido principalmente al crecimiento de Internet y a la proliferación de redes intranet corporativas. Las aplicaciones usadas en esos entornos están basadas principalmente en IP, como el Web y las aplicaciones multimedia de banda ancha. Las redes IP pronto soportarán un rango de servicios que van desde los tradicionales IP hasta las aplicaciones interactivas multimedia y servidores de voz. Todos esos servicios requerirán garantías de Calidad de Servicio (QoS) diferentes por parte de la red, y los mecanismos de calidad de servicio presentes deberán asegurar a los usuarios el servicio adecuado para sus datos de aplicación. Si tenemos en cuenta que los nuevos sistemas de 3ª generación están moviéndose hacia sistemas de transporte basados en IP, el siguiente paso lógico es el de extender ése transporte IP hacia el usuario final de esos servicios, ofreciendo por tanto la verdadera Internet móvil. Uno de los principales problemas a resolver en ese entorno es la provisión de QoS. Entre las propuestas para proporcionar un tratamiento privilegiado a ciertos flujos, el mecanismo de señalización estándar de-facto para reserva de recursos es el denominado Servicios Integrados [1] y el Protocolo de Reserva de Recursos (RSVP) [2]. Éstos fueron diseñados para proporcionar reservas de recursos explícitas basadas en flujos principalmente en redes fijas. Sin embargo, la provisión y mantenimiento de QoS en un entorno móvil dinámico no es una tarea sencilla. Además de las propias dificultades que podemos encontrar a la hora de proporcionar QoS en redes fijas nos encontramos con que el nodo móvil puede

cambiar potencialmente su punto de acceso a la red 1 numerosas veces durante una sesión, por lo que el verdadero desafío es poder mantener el nivel de servicio original (el solicitado) a medida que el terminal se mueve. Además existen otros problemas como los cambios de dirección IP (Mobile IP [3]) y la variabilidad y escasez de recursos en el enlace inalámbrico, que pueden crear situaciones en las que no se pueda garantizar ciertos niveles de servicio a los terminales, y por tanto se produzcan violaciones de la QoS. Una violación de la QoS puede resultar en retardos excesivos, pérdidas de paquetes o incluso en una total denegación del servicio. Por norma general los mecanismo de QoS y movilidad han evolucionado de manera independiente. El protocolo RSVP estándar puede reparar cambios producidos en el camino pero no es consciente del origen o la causa del cambio. La propuesta aquí presentada consiste en acoplar el protocolo de movilidad con RSVP. De esta manera se podría realizar un restablecimiento más rápido de la reserva tras el handover y se minimizaría el impacto causado a los flujos con recursos reservados. Nuestras simulaciones mostrarán cómo el acoplado de los protocolos junto con la priorización de la señalización de establecimiento de reservas reducen el impacto en el rendimiento de manera considerable. A lo largo del texto nos referiremos de manera implícita tan solo a mecanismos del tipo soft-state tales como RSVP, aunque estos métodos pueden ser aplicadados igualmente a mecanismos del tipo hard-state. 2. Acoplado de protocolos. La calidad de servicio basada en reservas asume, de manera implícita, un camino relativamente estable a lo largo de la red. Los cambios en las rutas sólo se reflejan en las reservas una vez que el mensaje de refresco ha recorrido todos los nodos del nuevo camino, lo cual puede introducir un retardo extremo a extremo muy elevado desde el nodo emisor hasta el nodo móvil. Mecanismos de refresco y soft-state en protocolos basados en reservas como RSVP se diseñaron originalmente para tratar casos de enlaces caídos, que por otro lado ocurren con poca frecuencia. Mecanismos más avanzados como el de reparación del camino local (Local Path Repair) se diseñaron para reparar de manera eficiente las reservas de RSVP tras un cambio en las rutas, pero su funcionamiento no es óptimo si el cambio en la ruta no es visible de manera explícita para los routers. La mayoría de los protocolos de movilidad más comunes tales como MobileIP o MobileIP 1 Este proceso se conoce con el nombre de handover. jerárquico [4] funcionan de esa manera. Además, dado que un cambio en la ruta suele implicar que el terminal móvil sea responsable de activar o parar el mecanismo de reparación de camino, se introduce una sobrecarga de señalización en el terminal móvil. 2.1 Cooperación entre protocolos. La solución aquí propuesta consiste en la colaboración entre los mecanismos de señalización de QoS los de movilidad local. Esta colaboración o acoplado se puede diseñar de formas muy diversas, aunque podemos identificar tres niveles fundamentales: No acoplados: Este es el estado actual, donde un protocolo no es consciente de la existencia del otro, aparte de por los efectos externos como por ejemplo el propio cambio en la ruta. Acoplado débil : Se utilizan mecanismos de disparo para informar a un protocolo sobre cambios o acciones del otro. Acoplado fuerte : La información de calidad de servicio y movilidad es transportada conjuntamente de alguna manera, por ejemplo añadiendo información de QoS en los mensajes del protocolo de movilidad. Un ejemplo claro de este acoplado aplicado a QoS es el protocolo INSIGNIA [5]. La elección de una de estas opciones es un compromiso entre aplicabilidad, complejidad y rendimiento. Si ambos protocolos conviven sin ningún tipo de información sobre el otro no es posible aprovecharse de algunas de sus características avanzadas, y por lo tanto no es posible obtener un aumento del rendimiento, aunque la transparencia se conserva. Esta transparencia hace posible el desarrollo libre e independiente de los protocolos. Por otro lado el acoplamiento fuerte tiene la ventaja de poder obtener un rendimiento óptimo a un mayor coste en aplicabilidad y desarrollo, ya que las soluciones existentes deben ser modificadas de manera más profunda. En general un mayor nivel de acoplamiento entre elementos de la red no es una buena práctica de diseño ya que puede violar algunos de los principios arquitectónicos de Internet, tales como la división en capas o el principio extremo a extremo [6]. 2.2 Acoplado débil de protocolos de QoS y movilidad. Entre las alternativas anteriores proponemos el acoplado débil de los mecanismos de QoS y los protocolos de movilidad local. Al mejorar le mecanismo de QoS en el entorno móvil la reparación del camino local es posible y los cambios en la reserva son tan solo locales al área

afectada por el cambio en la ruta, sin ninguna sobrecarga de procesamiento o señalización en los terminales móviles. En la aproximación débil, el cambio de posición del nodo móvil, y por lo tanto las actualizaciones de la información de encaminamiento en la propia red, disparan la generación de mensajes de reparación RSVP PATH. Éste mecanismo tan sólo repara la parte de la reserva que se ha perdido, provocando que la reserva extremo a extremo pueda instalarse de manera más rápida ya que no se necesita señalizar nuevamente desde el emisor hasta el receptor (con el retardo que ello supone). Hay que tener en cuenta que la señalización de reparación de la reserva no debe realizarse hasta que exista la seguridad de que la nueva ruta en la red es estable, por lo que existe un retardo fijo (el tiempo en que la nueva ruta se establece) que no puede ser reducido y depende directamente del mecanismo de movilidad subyacente. La implementación de este mecanismo implica cambios en todos los nodos envueltos en la provisión de QoS excepto en los nodos móviles. 2.3 Mecanismos complementarios. En un entorno móvil el acoplamiento débil proporciona una mejora en el rendimiento pero puede no ser suficiente. Existen una serie de mecanismos que complementan éste acoplado: Priorización de la señalización de QoS: El acoplado débil proporciona un mecanismo por el cual una reserva puede reinstalarse tan pronto como el nuevo camino es estable, permitiendo un uso más eficiente de los recursos y minimizando el impacto del handover. Sin embargo, si el nuevo camino contiene enlaces sobrecargados y los mensajes de QoS se pierden, el tiempo asignado al soft-state vencerá y los paquetes de datos pertenecientes al flujo de la reserva caerán a un prioridad best effort, pudiendo producirse una violación de la QoS. Si proporcionamos prioridad a los paquetes de señalización de QoS este efecto puede minimizarse y por lo tanto la nueva reserva puede instalarse. La priorización puede realizarse de diversas maneras, con mecanismos como DiffServ [7] o simplemente reservando una cierta cantidad de ancho de banda en los routers con colas del tipo CBQ [8]. Si no hay suficientes recursos en los nuevos enlaces (p. ej. ya existen otras reservas y no queda ancho de banda), entonces la reserva no podrá ser reinstalada. Esto puede resolverse con mecanismos de reserva anticipada como MRSVP [9] y otros, que quedan fuera del alcance de este documento. Priorizaciuón de paquetes en handover : Denominaremos paquetes en handover a aquellos paquetes pertenecientes a un flujo de datos que, a pesar de tener una reserva instalada en su camino de datos anterior, están pasando durante un periodo reducido de tiempo por unos nodos que no poseen (aún) información de reserva debido al cambio de ruta producida por un handover, y por lo tanto están siendo tratados como tráfico best-effort. Muchas modificaciones del protocolo RSVP han intentado establecer una reserva antes de que el handover ocurra. En esta propuesta nosotros evitamos esta opción primero porque no todos los handover son planeados y por lo tanto no hay tiempo de hacerlo, segundo por la carga de proceso y de señalización que imponen, así como la posible ineficiencia en el uso de los recursos de la red que son inevitables dado que la nueva ruta no puede ser determinada hasta que se ha producido el cambio en ella. Por lo tanto se hace necesario un mecanismo para tratar el tráfico que temporalmente carece de reserva. La priorización de estos paquetes proporcionan un mecanismo para el tráfico en handover basado en reservas acceda a unas bandas de guarda de ancho de banda, reservado únicamente para tráfico de alta prioridad proveniente de un handover. La priorización de los datos en handover que tiene que ser encaminada por un túnel hacia el nuevo destino proporciona una QoS mejorada sin necesidad de usar reservas temporales (que producen sobrecarga tanto en señalización como en tiempo de proceso) [10]. Esta priorización también puede usarse en procedimientos de reserva salto a salto (como RSVP) que son afectados por la movilidad. Permite a este tráfico tener una prioridad alta mientras la red espera a que el nuevo camino se estabilice antes de intentar reparar la reserva. Protocolos de transferencia de contexto: Un protocolo de transferencia de contexto transfiere la información de estado sobre los requisitos de QoS del nodo móvil desde el antiguo router de acceso hasta el nuevo. Este intercambio puede ser iniciado de varias maneras: por indicaciones de handover de la capa de enlace, o por ejemplo, en el caso de protocolos de movilidad local basados en túneles, podría ser iniciados por los nodos extremos de los túneles. El protocolo de transferencia de contexto requiere el soporte de todos los nodos que soportan la movilidad en la red de acceso. El protocolo necesario para activar este procedimiento, así como los parámetros a ser intercambiados, son un objeto de estudio hoy en día. Por ejemplo, el concepto de protocolo de transferencia de contexto está empezando a ser considerado por el grupo de trabajo Seamoby [11] (Seamless Mobility WG) del IETF. En particular, Seamoby propone un concepto de transferencia de contexto en unos términos más amplios que los aquí tratados (QoS), al transferir información sobre seguridad, compresión de cabeceras y otros conceptos además del ya comentado de QoS.

Router Acceso Emisor VoIP Internet Un protocolo de este tipo proporciona un soporte adecuado para los handovers eficientes y sin pérdidas 2, y en particular, también da soporte a otras posibles mejoras como la reparación local RSVP. Se asume que las reservas de QoS de la capa de enlace son restauradas también como resultado de este proceso de handover. El protocolo de transferencia de contexto proporciona al nuevo router de acceso suficiente información como para que todos los paquetes IP recibidos sean vinculados a las reservas inalámbricas adecuadas. De esta manera se puede restaurar de manera rápida en el enlace inalámbrico, que generalmente es el enlace más débil de todo el camino de datos. Por otro lado, si se utiliza un protocolo de transferencia de contexto junto con la reparación local de RSVP, se puede reducir la carga de señalización en el enlace inalámbrico como veremos a continuación De todos estos mecanismos, tan solo la priorización de la señalización de QoS es un requisito indispensable para la propuesta de acoplamiento débil. De todas formas, todos estos mecanismos proporcionan un marco para el seamless handover en entornos con QoS basada en reservas. 3. Simulaciones Gateway Figura 1: Escenario de Red. En este apartado se presentan diversas simulaciones que dan soporte a las propuestas teóricas planteadas anteriormente. Se pretende así comprobar la validez tanto cualitativa como cuantitativa de las propuestas Conversación de optimización expuestas, aplicándose a entornos reales significativos con protocolos actuales. Las simulaciones se han realizado con el simulador de nivel de red NS-2 [12]. En particular se presentan las simulaciones realizadas con el protocolo de micro-movilidad HAWAII [13] y el protocolo de señalización de calidad de servicio RSVP en el escenario mostrado en la figura 1. Entre los posibles escenarios de red de acceso hemos seleccionado uno que corresponde a una empresa pequeña típica. Es una topología de árbol básica. Proporciona un modelo inicial para la prueba de las mejoras así como otros protocolos de nivel de red, y se utilizó, entre otros, para la definición de la arquitectura mostrada en el proyecto BRAIN [14]. La topología se ha diseñado de tal forma que permita la existencia de diferentes distancias desde los routers de acceso al router de divergencia 3 (uno, dos y tres saltos). La red de acceso se compone de routers de acceso con interfaces inalámbricos y routers intermedios que conectan los distintos routers de acceso. Uno de estos routers intermedios actúa como puerta de enlace a otras redes. Los enlaces de la red de acceso están caracterizados como enlaces de 512 Kbytes de ancho de banda y 10 ms de retardo (en cada sentido). Hay que observar que el retardo depende en gran manera de la tecnología de red utilizada, de manera que este valor puede cambiar. Para los nodos inalámbricos se ha utilizado la tecnología HIPERLAN/2 [15]. Dado que el simulador ns-2 carece de soporte para esta capa de enlace, se ha modelado basándose en las simulaciones llevadas a cabo por por Nokia usando simuladores de nivel de enlace en el marco del proyecto BRAIN. Utilizamos una aproximación para cada celda usando una sala industrial sin paredes internas. Nokia ha evaluado el comportamiento del interfaz de aire HIPERLAN/2 para diferentes niveles de carga. El tamaño de la sala es de 250 metros cuadrados y tiene un nivel de carga similar a 5 nuevas transferencias FTP por segundo. En el simulador hemos caracterizado los enlaces HIPERLAN/2 mediante dos enlaces simplex (de subida y bajada) con dos parámetros: retardo, ancho de banda. Para el nivel de carga seleccionado en nuestras simulaciones y según las simulaciones de Conversación Silencio Figura 2: Tráfico de Voz sobre IP (VoIP) Tiempo 2 Comocidos como seamless handover.

Nokia, éstos parámetros corresponden a 3.2 Mbps de ancho de banda y a 15 ms de retardo. Situamos el nodo emisor fuera de la red de acceso. Tan sólo se encuentra a un salto del gateway aunque podría haberse situado en cualquier lugar de Internet. El nodo emisor envía tráfico de voz sobre IP (VoIP) hacia el nodo móvil en el interior del dominio. Consideraremos el caso en el que el nodo móvil cambia suposición entre dos celdas consecutivas mientras se está realizando la comunicación tal y como lo muestra la figura 1. La simulación se ha llevado a cabo de la siguiente manera: durante los 100 primeros segundos el emisor realiza la reserva con RSVP y comienza a transmitir paquetes de voz hacia el nodo móvil. Posteriormente se produce el handover entre dos celdas consecutivas. Esto implica la modificación de las tablas de rutas del protocolo HAWAII y la necesidad de establecer la reserva a través de la nueva ruta. En nuestro estudio sólo hemos contemplado el caso de handover planeado (aquel en el que el nodo móvil es consciente de que se va a producir el handover, y por tanto, puede reaccionar). El nodo móvil cambia su punto de acceso a la red y durante 20ms ambos enlaces inalámbricos están activos. Bien es cierto que, a pesar de ser un handover planeado, la cantidad de tiempo en el que ambos enlaces están activos es bastante corto, lo cual tiene su impacto sobre el rendimiento. Hemos introducido tráfico interferente en los enlaces que comunican el nodo de divergencia y los routers de acceso involucrados en el handover (en la figura 1 aparecen más gruesos). Este tráfico interferente utiliza el 100% de los citados enlaces y nos permite observar el efecto de las reservas de RSVP cuando deben reinstalarse a lo largo del nuevo camino. Observar que el tráfico interferente sólo ocupa un enlace del camino de la nueva ruta y que éste enlace es fijo. Por otro lado nos permite comparar la mejora de rendimiento obtenida cuando el protocolo de micro-movilidad se acopla con RSVP, y podemos observar la ventaja de reservar cierto ancho de banda para los paquetes de señalización de QoS. El tráfico interferente se caracteriza como tráfico con ancho de banda constante. El modelo de tráfico de VoIP extraído de [14] se puede describir como un proceso de nacimientomuerte con un modelo de recepción basado en una distribución de Poisson y una duración de llamada con distribución exponencial. Durante la conversación cada participante está o bien hablando o bien en silencio. Hemos simulado este tráfico de manera que los periodos de actividad y silencio son generados con una variable aleatoria con distribución exponencial. El valor medio de esta variable es igual a T_on durante los periodos de actividad y a T_off en los periodos de silencio. La figura 2 muestra un ejemplo gráfico de este modelo. Los parámetros principales principales del modelo de tráfico de VoIP son los siguientes: Intervalo de actividad: 50 % Duración media de llamada: 120 seg. Duración media de la fase de actividad T_on: 3 sec Duración media de la fase de silencio T_off: 3sec Tamaño de los datos del paquete IP: 32 Bytes. Los paquetes son de tamaño fijo. Ratio de transmisión: 12.2 Kbps Realizamos las medidas de retardo de los paquetes de VoIP tan sólo en un sentido. Esta aproximación es correcta dado que los enlaces tienen colas diferentes para ambos sentidos. Los paquetes que llegan del nodo emisor no interfieren con los paquetes que salen del nodo móvil, así que el retardo obtenido al medir tan sólo un sentido es significativo. Las simulaciones se han realizado usando la versión del simulador 2.1b5. Más detalles obre la implementación de los protocolos y de los generadores de tráfico pueden encontrarse en [14]. 3.1. Resultados de la simulación. En esta sección mostraremos el rendimiento de HAWAII y RSVP en el escenario comentado anteriormente, cuando éstos protocolos están acoplados de manera débil y cuando están desacoplados. En ambos casos hemos reservado 3 Conocido como crossover router en inglés. Es el router común más cercano a las rutas antigua y nueva tras un handover. Figura 3: Rendimiento del tráfico VoIP en el caso desacoplado.

una cantidad de ancho de banda fija para los paquetes de señalización de RSVP, tal y como se indica en la sección 2.4. Se añadió una cola WFQ (Weighted-Fair Queuing) para evitar la pérdida de paquetes de RSVP y por tanto favorecer la reparación rápida de las reservas tras el handover. La cantidad de ancho de banda reservada responde a la formula n*s*8/30 (donde n es el número de sesiones que van a instalarse en el enlace y s es el tamaño medio esperado del paquete. La formula representa 1/30 de todo el ancho de banda necesario para los paquetes RSVP en caso de que fueran refrescados cada Segundo: para un tiempo de refresco de 3 segundos supone el ancho de banda para acomodar el 10% de todos los paquetes RSVP). Este valor debería incrementarse si existiesen numerosos cambios en las reservas. Considerando un valor promedio del paquete de 100 bytes y 30 sesiones por celda obtenemos un valor de 750 bps en el enlace inalámbrico. Para la parte de la troncal que tienen en común ambos enlaces reservaremos 1500 bps (por agregación). En las siguientes figuras es necesario tener en cuenta que el handover ocurre en el segundo número 100. Caso desacoplado. Este caso muestra el rendimiento de los protocolos HAWAII y RSVP cuando no tienen constancia de la existencia del otro. La figura 3 muestra el rendimiento del tráfico VoIP en el caso desacoplado. Cuando se produce el handover (segundo 100), la nueva ruta tan sólo tiene reserva hasta el router de divergencia y el tráfico interferente, que es mucho mayor en proporción que el tráfico de VoIP, no permite que los paquetes de voz lleguen al terminal, de manera que es necesario esperar hasta que el refresco de RSVP se produce para que la nueva reserva se instale a lo largo de todo el camino. A los 105 Figura 5: Retardo de los paquetesde VoIP en el caso desacoplado segundos aproximadamente la nueva reserva es instalada y de nuevo los paquetes de VoIP llegan al terminal móvil, de manera que el rendimiento vuelve a la tasa sostenida previa al handover. Como podemos ver en la figura 4, los paquetes por segundo perdidos se disparan hasta que la nueva reserva es instalada. Hay que tener en cuenta que en ésta figura se miden los paquetes por segundo, y no los acumulados. Tras el handover llegan a perderse hasta 60 paquetes por segundo lo que implica que la llamada se ve seriamente afectada debido al movimiento del terminal. La ausencia de paquetes perdidos durante los dos picos es el resultado del propio patrón de tráfico de VoIP: simplemente no hay tráfico emitido en ese momento por lo que no hay pérdida de paquetes. Como consecuencia del handover, los paquetes de VoIP que no se pierden sufren un gran retardo durante un tiempo como muestra la figura 5. La Figura 4: Paquetes de VoIP perdidos por segundo en el caso desacoplado. Figura 6: Rendimiento del tráfico VoIP en el caso acoplado.

nueva ruta y por lo tanto sufrirán un retardo dependiendo del rendimiento del protocolo de movilidad local subyacente. El acoplamiento solamente optimiza la reinstalación de las reservas para minimizar el impacto del handover. Esto es independiente del mecanismo de movilidad usado, por lo que no afecta al tiempo que tarda la nueva ruta en ser establecida. Figura 7:Paquetes perdidos por segundo de VoIP en el caso acoplado. topología es simple por lo que podemos inferir que la causa del retardo es la ya comentada: la ausencia de reserva una vez que la nueva ruta se ha establecido. El enlace está saturado la cola de besteffort está llena, y los paquetes sufren un retardo proporcional a la longitud de la cola y, como hemos visto, algunos se pierden. Caso acoplado ( débil ) Este caso es idéntico al anterior salvo por el hecho de que los protocolos HAWAII y RSVP están acoplados de manera débil como hemos visto en la sección 2. Hemos diseñado un mecanismo de acoplamiento de ambos protocolos de tal forma que intercambian información en el handover. En el mismo instante que la nueva ruta es estable el agente RSVP procede a la reparación de RSVP. Así aseguramos que la reserva se instala lo antes posible. La figura 6 confirma nuestra hipótesis. El rendimiento del tráfico de VoIP tras el handover se ve afectado pero el impacto es mucho menor que en el caso desacoplado. La figura 7 muestra que las pérdidas de paquetes de VoIP durante el handover se han minimizado. Tan sólo 3-4 paquetes se han perdido, debido al handover propiamente dicho. El resto de pérdidas producto de la ausencia de reserva en la nueva ruta se ha eliminado dado que los mensajes de refresco de la reserva se envían tan pronto como la nueva ruta es estable, así que el impacto del tráfico interferente es mínimo. Por último, la figura 8 muestra el impacto del handover en el retardo. A pesar de que el retardo máximo no se reduce, el intervalo de tiempo en el que los paquetes se ven afectados sí disminuye considerablemente (comparar con la figura 5). Los únicos paquetes que se ven afectados y que tienen un retardo elevado son aquellos que estaban en vuelo en el momento en el que ocurre el handover. Estos paquetes deben esperar a que se actualice la 4. Conclusiones Presentamos una mejora para el funcionamiento de las reservas en entornos móviles basada en la colaboración de los protocolos de QoS y movilidad. Aunque se pueden concebir distintos tipos de colaboración hemos optado por el acoplamiento débil como el más prometedor, donde los protocolos de QoS y movilidad intercambian información mediante algún mecanismo de disparo cuando ocurre un handover. Hemos observado mediante las simulaciones que este acoplamiento proporciona una ventaja clara en algunos escenarios. A pesar de que el propio handover en sí no puede ser acelerado sí que se consigue que las reservas se reinstalen tan pronto como el nuevo camino es estable. Esto es especialmente interesante en escenarios como el aquí mostrado, donde tráfico interferente puede hacer que el tráfico con reserva pueda ser descartado. Hemos simulado también otro mecanismo complementario como la priorización de los paquetes de señalización que ofrecer un marco para el seamless handover cuando se utilizan mecanismos basados en reservas. En conclusión, el acoplado de los protocolos de micro-movilidad y protocolos de reserva tiene un coste reducido y las ventajas, al menos en el caso de protocolos de movilidad salto a salto (como es el caso de HAWAII, o Cellular IP [16]), combinado con la pre-reserva para la señalización de QoS son suficientes como para justificarlo. Figura 8: Retardo de los paquetes de VoIP en el caso acoplado

Agradecimientos This work has been performed in the framework of the IST project IST-1999-10050 BRAIN, which is partly funded by the European Union. The authors would like to acknowledge the contributions of their colleagues from Siemens AG, British Telecommunications PLC, Agora Systems S.A., Ericsson Radio Systems AB, France Télécom R&D, INRIA, King s College London, Nokia Corporation, NTT DoCoMo, Sony International (Europe) GmbH, and T-Nova Deutsche Telekom Innovationsgesellschaft mbh. Alberto López agradece en particular a la Fundación Séneca (Comunidad Autónoma de la Región de Murcia) su apoyo y la financiación para llevar acabo este trabajo. Referencias [1] Braden, R., Clark, D. Shenker, S., Integrated Services in the Internet Architecture: an Overview. Internet Engineering Task Force, Request for Comments (RFC) 1633, Junio 1994. [2] Braden, R., et. Al. Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification. Internet Engineering Task Force, Request for Comments (RFC) 2205, Septiembre 1997. [3] Perkins, C., "IP Mobility Support". Internet Engineering Task Force, Request for Comments (RFC) 2002, Octubre 1996. [4] Gustafsson, E., Jonsson, A., Perkins, C,. Mobile IP Regional Registration, Internet Draft (work in progress), Marzo 2001. [5] Lee, S.B., Gahng-Seop, A., Zhang, X., and A.T. Campbell, INSIGNIA: An IP-Based Quality of service Framework for Mobile Ad Hoc Networks, Journal of Parallel and Distributed Computing (Academic Press), Special issue on Wireless and Mobile Computing and Communications, Vol. 60 No.4. p.374-406, Abril 2000. Networking, Vol. 3, No. 4, 365-386, Agosto 1995. [9] A. Talukdar, B. Badrinath, A. Acharya, MRSVP: A Resource Reservation Protocol for an Integrated Services Packet Network with Mobile Hosts, In Proceedings of ACTS Mobile Summit 98, Junio 1998. [10] MSc Thesis Towards Full Quality of Service Support in a Mobile, Wireless Internet, Anne-Louise Burness, University of Essex, Enero 2001. [11] IETF Seamoby WG. http://www.ietf.org/ html.charters/seamoby-charter.html [12] L. Breslau, D. Estrin, K. Fall, S. Floyd, J. Heidemann, A. Helmy, P. Huang, S. McCanne, K. Varadhan, Y. Xu, and H. Yu. Advances in network simulation., IEEE Computer, 33(5):59(67), Mayo 2000. [13] Ramjee, R., La Porta, T., Thuel, S., Varadhan, K., Wang, S.Y., HAWAII: a domain-based approach for supporting mobility in wide-area wireless networks. Proceedings of the Seventh International Conference on Network Protocols (ICNP) 1999, pp. 283 292. [14]IST-1999-100050 BRAIN D2.2 BRAIN architecture specifications and models, BRAIN functionality and protocol specification, Marzo 2001. [15] ETSI TR 101 683 V1.1.1 (2000-02), Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; System Overview. [16] Campbell, A., Gomez, J., Kim, S., Valko, A., Chieh-Yih Wan, Turanyi, Z., Design, implementation, and evaluation of cellular IP. IEEE Personal Communications, Vol. 7, Agosto 2000, pp. 42-49.. [6] B. Carpenter, "Architectural Principles of the Internet," Internet Engineering Task Force, Request for Comments (RFC) 1958, Junio 1996. [7] M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies, An Architecture for Differentiated Services, Request for Comments (RFC) 2475, Deciembre 1998. [8] Floyd, S., Jacobson, V., Link Sharing and Resource Management Models for Packet Networks, IEEE/ACM Transactions on