TESIS DOCTORAL ESPECIFICACIÓN Y EVALUACIÓN …personales.upv.es/aleon/pubs/aleon_tesis.pdf4.2...

TESIS DOCTORAL

ESPECIFICACIÓN Y EVALUACIÓN DE UN PROTOCOLO DE MICRO-MOVILIDAD IP BASADO EN TRANSMISIÓN MULTICAST

ANTONIO LEÓN FERNÁNDEZ

DIRECTOR: DR. D. MANUEL ESTEVE DOMINGO

Departamento de Comunicaciones Escuela Técnica Superior de Ingenieros de Telecomunicación

UNIVERSIDAD POLITÉCNICA DE VALENCIA

Abril 2004

ABSTRACT

Nowadays, mobility is one of the most interesting research topics in the context of IP networks. Although several approaches have been proposed to deal with mobility, most of them are based on the Mobile IP protocol [RFC 3344].

While Mobile IP offers significant advantages which converted it

in a key reference for current research it also presents important limitations. In order to overcome those limitations several improvements have been proposed, which are generally based on a division of the network into zones or domains. This concept is named micro-mobility and allows to manage handovers in a local way.

In this Ph.D. dissertation we present a new micro-mobility system

based on multicast. The use of multicast technology offers, among others, two important advantages: the inherent capability of simultaneously data transmission to several locations, which helps to achieve lossless handovers, and its degree of maturity, that allows an easy integration into mobile systems.

A complete protocol has been designed in order to include the

format of the messages, as well as solutions to possible scalability and security problems.

In addition, five different handover schemes have been designed to

be implemented in the multicast based micro-mobility system. These schemes include a wide range of possibilities, both with regard to the capacities that are offered by the network (simultaneous communication with two stations or only with one of them) and with the handover requirements (null packages loss, minimum latency, etc.). These five schemes have been analytically evaluated, relying on the number of lost packets, time of interruption, or time of buffers delays, with the purpose of analyzing the advantages to use one or another.

RESUMEN

Uno de los campos de investigación más interesante actualmente es la movilidad en redes IP. Aunque existen distintas soluciones para abordar el problema, la mayoría de las contribuciones giran en torno al protocolo Mobile IP [RFC 3344].

Sin esconder las ventajas que aporta, y que lo han convertido en la

referencia básica para toda la investigación actual, hay que indicar que Mobile IP tiene importantes limitaciones. Se han realizado diversas propuestas de mejora que, en general, se basan en la división espacial en zonas o dominios. Este concepto es denominado micro-movilidad y permite que el handover pueda ser tratado de manera local.

En esta Tesis Doctoral se presenta un novedoso sistema de micro-

movilidad basado en la capacidad de transmisión multicast. La utilización de esta tecnología nos va ofrecer ventajas, como la facilidad intrínseca de transmitir datos simultáneamente a dos localizaciones, lo que favorece los handovers sin pérdidas, o la madurez actual de la tecnología, que permite su fácil incorporación a entornos móviles.

Se ha diseñado un protocolo completo, incluyendo el formato de

todos los mensajes propuestos, así como soluciones a posibles problemas de escalabilidad y de seguridad necesarias en este tipo de redes.

Se proponen, además, cinco esquemas de handover diferentes,

diseñados para implementarse en el sistema de micro-movilidad basado en multicast. Éstos abarcan todo un abanico de posibilidades, tanto en lo referente a las capacidades que le ofrece la red (capacidad de comunicación simultanea con dos estaciones base o sólo con una), como en requisitos del handover (pérdida nula de paquetes, latencia mínima, etc.). Los cinco esquemas anteriores han sido evaluados analíticamente, con el fin de analizar las ventajas de utilizar uno u otro esquema, en función del número de paquetes perdidos, tiempo de interrupción o tiempo de espera en ‘buffers’.

RESUM Un dels camps d’investigació més interessant actualment és la

mobilitat en xarxes IP. Encara que hi ha distintes solucions per a abordar el problema, la majoria de les contribucions versen entorn del protocol Mobile IP [RFC 3344].

Sense amagar els avantatges que aporta, i que l’han convertit en la

referència bàsica per a tota la investigació actual, cal indicar que Mobile IP té importants limitacions. S’han realitzat diverses propostes de millora que, en general, es basen en la divisió espacial en zones o dominis. Aquest concepte és denominat micro-mobilitat i permet que el handover puga ser tractat de manera local.

En aquesta tesi doctoral es presenta un sistema innovador de

micro-mobilitat basat en la capacitat multicast. La utilització d’aquesta tecnologia ens oferirà avantatges, com ara la facilitat intrínseca de transmetre dades simultàniament a dues localitzacions, cosa que afavoreix els handovers sense pèrdues, o la maduresa actual de la tecnologia, que en permet la fàcil incorporació a entorns mòbils.

S’ha dissenyat un protocol complet, que inclou el format de tots els

missatges proposats, així com solucions a possibles problemes de escalabilitat i de seguretat necessàries en aquest tipus de xarxes.

Es proposen, a més, cinc esquemes de handover diferents,

dissenyats per a implementar-se en el sistema de micro-mobilitat basat en multicast. Aquests abracen tot un ventall de possibilitats, tant pel que fa a les capacitats que li ofereix la xarxa (capacitat de comunicació simultània amb dos estacions base o solament amb una), com en requisits del handover (pèrdua nul·la de paquets, latència mínima, etc.). Els cinc esquemes anteriors han sigut avaluats analíticament, amb la finalitat d’analitzar els avantatges d’utilitzar un o un altre esquema, en funció del nombre de paquets perduts, temps d’interrupció o temps d’espera en buffers.

AGRADECIMIENTOS

Me gustaría dar las gracias, en primer lugar, a mi mis padres

Antonio y Pilar, y a hermana Paloma, por todo el cariño que me han dado durante estos años.

A Manuel Esteve por su confianza y apoyo constante, más allá del

simple trabajo de director de esta Tesis. A mis compañeros de trabajo por sus consejos y su inestimable

ayuda a lo largo de todo este tiempo. A José Enrique, Oscar, Ana, Juan Carlos y Carlos. Gracias especialmente a Vicent, por sus útiles consejos y por su siempre interesante conversación.

A mis buenos amigos Oscar y Antonio, por hacerme reír y poder

disfrutar con ellos de todos esos momentos irrepetibles.

Muy especialmente a María José. Gracias por compartir tu vida conmigo.

i

INDICE DE LA MEMORIA

1. INTRODUCCIÓN Y OBJETIVOS 1

1.1 INTRODUCCIÓN 1

1.2 OBJETIVOS DE LA TESIS 6

1.3 ORGANIZACIÓN DE LA MEMORIA 8

2. SISTEMAS DE MOVILIDAD EN REDES IP 11

2.1 INTRODUCCIÓN 11

2.2 PRIMEROS TRABAJOS 17 2.2.1 Esquema de Columbia 17 2.2.2 Esquema Sony 18 2.2.3 Esquema LSR 19

2.3 MOBILE IP 21 2.3.1 Visión General del Modo de Funcionamiento 25 2.3.2 Descubrimiento del Agente 26 2.3.3 Registro 28 2.3.4 Envío de datos 31 2.3.5 Consideraciones relativas a la Seguridad 33 2.3.6 Optimización de la Ruta 35 2.3.7 Mobile IP con Registro Regional 40

2.4 SISTEMAS DE MICROMOVILIDAD 42 2.4.1 CELLULAR IP 44 2.4.2 HAWAII 46 2.4.3 TeleMIP 48 2.4.4 Edge Mobility Architecture, EMA 50

2.5 SISTEMA DE MOVILIDAD BASADO EN MULTICAST 51 2.5.1 J. Mysore. MSM-IP 52 2.5.2 Daedalus 54

2.6 IP MOBILE v6 55

2.7 SOLUCIONES DE MOVILIDAD A NIVEL DE APLICACIÓN

59

Índice de la Memoria

ii

2.8 RESUMEN DEL CAPÍTULO 61

3. PROPUESTA DE SISTEMA DE MICROMOVILIDAD BASADO EN MULTICAST

65


3.2 ARQUITECTURA 67

3.3 PROTOCOLO DE MICRO-MOVILIDAD BASADO EN MULTICAST

70

3.3.1 Descubrimiento de la red actual 73 3.3.2 Registro en un nuevo Dominio 74 3.3.3 Registro en una nueva BS dentro del Dominio 78 3.3.4 Transmisión y Recepción de datos 80 3.3.5 Escalabilidad 83

3.4 ASPECTOS RELATIVOS A LA SEGURIDAD EN EL SISTEMA DE MICROMOVILIDAD PRESENTADO

86

3.4.1 Introducción a la seguridad en entornos móviles

86

3.4.2 Seguridad en el Sistema de Micro-movilidad Multicast

87

3.5 FORMATO DE LOS MENSAJES 94 3.5.1 Mensajes para el descubrimiento de la red 94 3.5.2 Mensajes en el registro en un nuevo Dominio 96 3.5.3 Mensajes para el registro Intra-Dominio 99 3.5.4 Otros mensajes no detallados 101

3.6 CONSIDERACIONES SOBRE EL USO DE TRANSMISIÓN MULTICAST EN EL SISTEMA DE MICROMOVILIDAD

102

3.6.1 Introducción a la transmisión multicast 102 3.6.2 Selección de la tecnología multicast a emplear 103 3.6.3 Incorporación del protocolo PIM-SM / SSM al

sistema de micro-movilidad 108

3.7 TABLA COMPARATIVA CON OTRAS PROPUESTAS DE MICRO-MOVILIDAD

112

3.8 CONCLUSIONES DEL CAPÍTULO

114


iii

4. PROCESO DE HANDOVER EN REDES IP 117


4.2 Latencia del proceso de Handover en redes IP 121 4.2.1 Retardo en la detección del movimiento 122 4.2.2 Retardo en la recuperación de una dirección

temporal, Care-of Address 123

4.2.3 Retardo de reestablecimiento de la ruta 125

4.3 COOPERACIÓN DE LA CAPA 2 DURANTE EL HANDOVER

126

4.4 SOLUCIONES EXISTENTES DE HANDOVER EN SISTEMAS DE MOVILIDAD IP

130

4.4.1 Soluciones para Handovers suaves 132 4.4.2 Handover de baja latencia utilizando triggers 134 4.4.3 Handovers en sistemas de micro-movilidad 139 4.4.4 Handovers basados en transmisión multicast 145

4.5 RESUMEN Y CONCLUSIONES DEL CAPÍTULO 147

5. PRESTACIONES DEL HANDOVER EN REDES IP MÓVILES

151

5.1 INTRODUCCIÓN 151 5.1.1 Simulador de red NS-2 153 5.1.2 Metodología de trabajo 156

5.2 INTRODUCCIÓN AL ESTUDIO POR SIMULACIÓN DEL PROTOCOLO ‘MOBILE IP’

157

5.3 ESTUDIO DEL HANDOVER CERCANO DEL PROTOCOLO MOBILE IP

158

5.3.1 Estudio del tráfico UDP en Handover Cercano 159 5.3.2 Estudio del tráfico TCP en Handover Cercano 168 5.3.3 Conclusiones sobre el Handover Cercano 173

5.4 ESTUDIO DEL HANDOVER LEJANO DEL PROTOCOLO ‘MOBILE IP’

174

5.4.1 Estudio del tráfico UDP en Handover Lejano 175 5.4.2 Estudio del tráfico TCP en Handover Lejano 183 5.4.3 Conclusiones sobre el Handover Lejano 192


iv

5.5 ESTUDIO DE PRESTACIONES DE LOS SISTEMAS DE MICRO - MOVILIDAD

194

5.5.1 Estudio del tráfico UDP en Sistemas de Micro-Movilidad

196

5.5.2 Estudio del tráfico TCP en Sistemas de Micro-Movilidad

200

5.5.3 Conclusiones sobre los sistemas de micro-movilidad

203

5.6 IMPLEMENTACIÓN DE UN BANCO DE PRUEBAS DEL PROTOCOLO MOBILE IP

204

5.6.1 Transmisión CBR con protocolo UDP 207 5.6.2 Transmisión con protocolo TCP 208 5.6.3 Transmisión de tráfico multimedia con RTP 210

5.6.3.1 Transmisión multimedia con calidad media 211

5.6.3.2 Transmisión de videoconferencia de baja calidad

212

5.6.4 Prueba subjetiva sobre el efecto del handover 215 5.6.5 Conclusiones de la implementación del banco

de pruebas 218

6. ESPECIFICACIÓN DE MECANISMOS DE HANDOVER INTRA-DOMINIO PARA UN SISTEMA DE MICRO-MOVILIDAD BASADO EN MULTICAST

221


6.2 PROPUESTA DE ESQUEMAS DE HANDOVER 223

6.3 ESQUEMA DE HANDOVER ABRUPTO 225

6.4 ESQUEMA DE HANDOVER SEMI SUAVE 230 6.4.1 Limitaciones del mecanismo de Handover Semi

Suave 232

6.5 ESQUEMA DE HANDOVER SUAVE CON FINALIZACIÓN CONTROLADA

235

6.5.1 Formato del mensaje ‘Handover Switch Indication’

238

6.5.2 Coexistencia de los esquemas de handover 240

6.6 ESQUEMA DE HANDOVER CON REDIRECCIONAMIENTO

242


v

6.6.1 Solución a los problemas del esquema 244 6.6.2 Formato de los mensajes utilizados en este

esquema 248

6.7 ESQUEMA DE HANDOVER INDIRECTO CON PRE-REGISTRO

252

6.8 RESUMEN Y CONCLUSIONES DE LOS ESQUEMAS DE HANDOVER PROPUESTOS

255

7. EVALUACIÓN ANALÍTICA DE LOS MECANISMOS DE HANDOVER INTRA-DOMINIO

263


7.2 ESQUEMA DE HANDOVER ABRUPTO 264 7.2.1 Desarrollo analítico 264 7.2.2 Resultados 268

7.3 ESQUEMA DE HANDOVER SEMI SUAVE 272 7.3.1 Pérdida de paquetes del handover sin

desconexión de oBS 273

7.3.1.1 Desarrollo analítico 273

7.3.1.2 Resultados 276

7.3.2 Pérdida de paquetes con desconexión de oBS 278 7.3.2.1 Desarrollo analítico 279


7.3.3 Paquetes duplicados sin desconexión de oBS 285 7.3.3.1 Desarrollo analítico 285


7.3.4 Paquetes duplicados con desconexión de oBS 288 7.3.4.1 Desarrollo analítico 289


7.3.5 Conclusiones del handover Semi Suave 293

7.4 ESQUEMA SUAVE CON FINALIZACION CONTROLADA

295

7.4.1 Análisis de los paquetes perdidos 296 7.4.1.1 Desarrollo analítico 296


7.4.2 Análisis del retardo de los paquetes entregados 302


vi

vía nBS 7.4.2.1 Desarrollo analítico 303


7.4.3 Análisis de la limitación del mecanismo de handover con Finalización Controlada

315

7.4.3.1 Desarrollo analítico 316


7.4.4 Conclusiones 319


321

7.5.1 Desarrollo analítico 323 7.5.2 Resultados 328 7.5.3 Consideraciones finales sobre el Handover con

Redireccionamiento 330

7.5.3.1 Posible duplicación de paquetes 331


333

7.6.1 Desarrollo analítico 333 7.6.1.1 Paquetes perdidos 336

7.6.1.2 Paquetes duplicados 339

7.6.2 Resultados 340 7.6.3 Conclusiones 345

7.7 CONCLUSIONES DEL CAPÍTULO 346

8. CONCLUSIONES Y LÍNEAS FUTURAS DE INVESTIGACIÓN

351

8.1 INTRUCCIÓN 351

8.2 CONCLUSIONES 351

8.3 LÍNEAS FUTURAS DE INVESTIGACIÓN 355

BIBLIOGRAFÍA. 357

ANEXO 1. ACRÓNIMOS Y GLOSARIO 373

ANEXO 2. DESARROLLO DE ECUACIONES 381

1

1. INTRODUCCIÓN Y OBJETIVOS

1.1 INTRODUCCIÓN En la sociedad de la información actual dos tecnologías sobresalen claramente del resto. La primera sería la arquitectura TCP/IP, base de Internet. El auge social que tiene esta red, unido a la sencillez y flexibilidad de los protocolos, han posibilitado la supremacía de esta arquitectura sobre todas las demás, siendo, por ejemplo, la base de la gran mayoría de las redes corporativas actuales. La segunda tecnología sobresaliente sería la tecnología de transmisión inalámbrica, en todas sus variantes, que proporciona la base para poder ofrecer movilidad. Ésta ha crecido en importancia a medida que los avances tecnológicos han dado una mayor portabilidad a los equipos, sin que disminuya por ello las prestaciones de los mismos. Un ejemplo de la importancia que actualmente está teniendo la capacidad de movilidad sería el desarrollo de las redes de área local inalámbricas, WLAN, cuya presencia en el mercado de las RAL aumenta de manera vertiginosa. El otro ejemplo clave sería la evolución de la telefonía móvil, y de toda la inversión que se ha realizado en el desarrollo de la tercera generación, por ejemplo UMTS, que permite ofrecer no sólo servicios de voz, sino también envío de datos a velocidades razonables. De lo anterior podemos deducir la importancia que en un futuro va a tener la convergencia de estas dos tecnologías. Es decir, tanto la capacidad de poder ofrecer movilidad en redes basadas en TCP/IP, como la integración de la arquitectura IP en los sistemas de telefonía móvil. En este sentido, la movilidad dentro de una subred es un tema resuelto con las redes de área local inalámbricas comentadas anteriormente. En esta línea se sigue trabajando hoy en día en cuestiones

Introducción y Objetivos

2

de seguridad y de calidad de servicio. Sin embargo la movilidad entre subredes en una red con arquitectura TCP/IP presenta importantes dificultades como detallamos a continuación.

Podemos tomar el ejemplo de las redes UMTS actuales. Cuando un terminal quiere realizar una comunicación de datos crea un contexto PDP (Packet Data Protocol) por el que adquiere una dirección IP. Sin embargo, los paquetes IP que transmite el terminal son encapsulados tanto cuando viajan por la red de acceso (UTRAN UMTS Radio Access Network), como cuando lo hacen por en la red de transporte troncal. Así, en la red de acceso los paquetes que llegan al RNC (Radio Network Controler) son encapsulados con un protocolo denominado GTP (GPRS Tunnelling Protocol), que ha su vez viaja sobre AAL2/ATM. En la red trocal los paquetes GTP suelen ser a transportados también sobre ATM, aunque aquí existe la posibilidad de hacerlo encapsulados en UDP sobre IP.

Como observamos del ejemplo anterior, los sistemas de tercera

generación actuales no están basados en una arquitectura IP de manera nativa, requiriendo, por tanto, complejos y caros dispositivos.

El siguiente paso sería pues la convergencia total entre la arquitectura basada en IP y los sistemas de telefonía móvil. Es lo que se llama usualmente sistemas 4G. Esto produciría beneficios tanto para los usuarios como para los operadores. Algunos de estos serían:

• Los sistemas de telefonía serían más baratos, debido a economías de escala que se producirían al ser dispositivos similares a los de red fija ya existentes.

• Se podrían ofrecer un conjunto de nuevos servicio basados en las capacidades de la red IP, como por ejemplo los basados en transmisión ‘multicast’ o ‘anycast’.

• La administración de las redes de telefonía móvil sería más sencilla, ahorrando costes de mantenimiento.

• Como IP es un protocolo que puede funcionar sobre cualquier tecnología de capa 2, para los operadores sería mucho más sencillo

Introducción Objetivos

3

integrar otras tecnologías de acceso, como WLAN, con las tecnologías celulares de área amplia.

Sin embargo, la arquitectura basada en IP también tiene importantes limitaciones. Dos destacan claramente de las demás:

• Dificultad para poder ofrecer QoS, debido a la naturaleza ‘best effort’ del servicio que ofrece el protocolo IP.

• Dificultad para poder ofrecer movilidad, debido a que el protocolo se diseño asumiendo que los dispositivos eran fijos.

Para poder ofrecer calidad de servicio (QoS) se requiere del control de una serie de parámetros como pueden ser la pérdida de paquetes, el retardo de los mismos, o la sincronización de distintos flujos. Algunos de estos aspectos son controlados por el terminal a través de protocolos extremo a extremo bien conocidos. Así, por ejemplo, el protocolo TCP se encarga de recuperar los errores, mientras que el RTP [RFC 1989] se utiliza para controlar el jitter y para sincronizar los distintos flujos. Sin embargo ninguno de las protocolos extremo a extremo puede garantizar el retardo que experimenta un paquete en atravesar la red, aspecto fundamental para poder ofrecer aplicaciones de tiempo real.

La solución a este problema pasa, evidentemente, por que la red sea capaz de ofrecer un mejor servicio, más allá de la simple entrega de paquetes. Existe una gran cantidad de trabajo realizado es este campo. Tradicionalmente las soluciones se dividen en soluciones de ‘Servicios Integrados’ (IntServ) [RFC 2215], en los que se asegura QoS para cada flujo individual, o bien ‘Servicios Diferenciados’ (DiffServ) [RFC 2475], que busca una diferenciación de servicios de una manera escalable. Los servicios integrados tienen problemas de escalabilidad, al hacerse necesario que cada router disponga de información de cada flujo que transmite. Además es necesario un protocolo que reserve los recursos a lo largo de al ruta (por ejemplo RSVP [RFC 2205]) y que refresque estas reservas cada cierto tiempo, lo que añade sobrecarga en al red. Por el contrario los servicios


4

diferenciados se basan en una configuración de QoS estática de manera que no pueden garantizar la calidad extremo a extremo. En los trabajos que se están desarrollando para los nuevos sistemas móviles de cuarta generación, y que se basarán completamente en IP, la tendencia es el uso de las dos soluciones de manera combinada. En la red de acceso, donde aparecen los principales problemas de recursos, se utiliza IntServ, mientras que en el núcleo, donde es más sencillo sobredimensionar la red, se emplea DiffServ. Esta solución mixta proporciona un buen compromiso entre coste y eficiencia [WIS02]. El segundo problema fundamental de la arquitectura basada en IP es la capacidad para ofrecer movilidad. Esta arquitectura se diseñó asumiendo que los hosts eran estacionarios, y se utiliza la dirección destino IP, no sólo para identificar tanto al nodo como a la conexión TCP, sino también para encaminar los paquetes. Por tanto, y según el protocolo IP clásico, cuando un móvil, que posee una dirección IP perteneciente a la subred donde se encuentra, realiza un handover a una subred diferente dejaría de recibir paquetes, pues estos se encaminarían hacia la red correspondiente con su dirección IP. La solución de cambiar de dirección IP por parte del nodo móvil ocasionaría el cierre de las conexiones TCP, ya que este protocolo utiliza, junto con los números de puerto, las direcciones IP origen y destino para definir una conexión. La propuesta de realizar un encaminamiento por host a los nodos móviles, aunque posible, claramente no es escalable. La solución más extendida es el protocolo Mobile IP [RFC 3344], que soluciona el problema asignando al nodo móvil dos direcciones IP. La primera se utiliza como identificador permanente del nodo, mientras que la segunda es una dirección temporal enrutable. Así un agente situado en la red origen del nodo móvil almacena esta segunda dirección temporal, que utilizará para reencaminar los paquetes dirigidos al nodo móvil utilizando un túnel.


5

El protocolo Mobile IP es fuerte y robusto, y parece una buena solución a la hora de proporcionar movilidad entre diferentes operadores. Así en el sistema de 3G CDMA2000 promovido por 3GPP2 en EE.UU. se utiliza el protocolo Mobile IP para ofrecer movilidad entre distintas redes de acceso radio, aunque dentro de ellas la movilidad se sigue implementando basándose en ATM.

En realidad, el protocolo Mobile IP tiene importantes impedimentos que lo limitan en exceso. Los principales serían:

• Los handovers van a ser lentos, incapacitando al protocolo para aplicaciones de tiempo real. El motivo es que el nodo móvil debe señalizar el cambio de dirección a su agente, lo que puede consumir mucho tiempo si el nodo móvil se encuentra alejado de él.

• La necesidad de este intercambio de mensajes provoca una sobrecarga de la red, que se incrementa, como en el caso anterior, a medida que aumenta la distancia entre el nodo móvil y su agente. En la actualidad se han realizado varias propuestas para resolver

los problemas mencionados. La idea básica consiste en dividir la red en regiones o dominios. Ahora la movilidad entre dominios, poco frecuente, se sigue realizando con el protocolo Mobile IP, pero dentro de un dominio se buscan soluciones particulares para poder ofrecer movilidad con altas prestaciones en cuanto a tiempo de handover.

Podemos realizar una sencilla clasificación de las propuestas de

micro-movilidad aparecidas en la bibliografía:

• Esquemas de agentes de movilidad jerárquicos, donde se divide la red en dominios cada vez más pequeños, de manera que un movimiento dentro de un dominio es transparente para los superiores.

• Esquemas de encaminamiento basado en host (HBR), basados en que el encaminamiento del dominio se realiza en función de la dirección única de cada host.


6

Así el futuro de los sistemas de telefonía móvil, denominado de cuarta generación 4G, estará basado completamente en IP. En este escenario es donde los sistemas de micro movilidad IP, base de esta Tesis Doctoral, cobrarán una especial importancia, como mecanismo que complementará y mejorará de las prestaciones del protocolo Mobile IP.

1.2 OBJETIVOS DE LA TESIS La realización de la presente Tesis se puede considerar como una contribución al estudio y evaluación de los sistemas de micro-movilidad IP. Como hemos comentado anteriormente los sistemas de micro-movilidad publicados hasta la fecha pueden dividirse en dos grandes grupos: aquellos basados en enrutamiento por host, y aquellos que utilizan soluciones jerárquicas. En esta Tesis Doctoral se presenta un sistema de micro-movilidad novedoso, que podría encuadrarse en un tercer grupo: sistemas basados en transmisión multicast. Por tanto, el objetivo principal de la Tesis es desarrollar un sistema de micro-movilidad viable, que utilice las capacidades de transmisión multicast de las redes IP actuales, y que simultáneamente también incorpore innovaciones que mejoren las prestaciones durante el handover. Hasta alcanzar este objetivo principal, en el desarrollo de la Tesis se ha llevado a cabo un conjunto de tareas que también pueden considerarse como objetivos. En primer lugar, se aporta una visión general de las principales contribuciones en el área de los sistemas de movilidad IP. Puesto que este es un campo de constante innovación y relativamente nuevo, es fundamental realizar un compendio de las aportaciones que hasta el momento se han realizado en otros trabajos. El desarrollo del sistema de micro-movilidad ha de ser realizado definiendo perfectamente los mensajes que se utilicen. Puesto que un objetivo prioritario es hacer que este esquema sea completamente compatible con el protocolo Mobile IP, se utilizarán las extensiones


7

definidas tanto en la [RFC 3344] como en distintos trabajos el IETF que a día de hoy están en progreso.

Para no limitar el sistema de micro-movilidad presentado, un objetivo es realizar el diseño de manera que sea perfectamente escalable. Otro objetivo es desarrollar los mecanismos de seguridad necesarios, siguiendo las últimas propuestas que se han publicado sobre este tema.

El sistema de micro-movilidad que presentamos se basa en la

encapsulación en paquetes IP multicast. Marcamos como objetivo el estudiar tanto la tecnología multicast en general, como los protocolos de enrutamiento multicast en particular. El fin es, primero, asegurarse que es una solución adecuada, y que ofrece ventajas con respecto a otras soluciones de micro-movilidad, y segundo, seleccionar el protocolo más adecuado a nuestro sistema.

Se realizará un estudio del proceso de handover en redes IP, dividiendo la latencia total en diferentes componentes. Se analizarán los distintos esquemas de handover propuestos en la bibliografía, realizando una clasificación y obteniendo conclusiones. El objetivo es estudiar todos los parámetros que intervienen en el proceso de handover, con el fin de poder buscar soluciones adaptadas a nuestro sistema de micro-movilidad IP. Así, para buscar los puntos débiles de los esquemas de handover estandarizados, se analizarán las prestaciones del handover del protocolo Mobile IP. La evaluación se va a realizar tanto por simulación como realizando un banco de pruebas. También se evaluarán las prestaciones de los principales sistemas de micro-movilidad presentes en la bibliografía. Un objetivo básico en la presente Tesis Doctoral es el diseño de esquemas de handover que cumplan unos requisitos tanto de tiempo de interrupción como de pérdida de paquetes. En este sentido se desarrollarán esquemas suaves, donde no se pierden paquetes, y también esquemas rápidos, donde el interés se ha centrado en lograr un tiempo de interrupción mínimo. Asimismo se van a diseñar soluciones tanto para sistemas donde el nodo móvil tiene capacidad de comunicarse simultáneamente con dos estaciones base, como para aquellos donde el


8

nodo tiene que cortar la comunicación con la estación previa antes de poder establecerla con la nueva. Por último un objetivo importante es la realización de un estudio de las prestaciones de los esquemas de handover propuestos para el sistema de micro-movilidad diseñado. Se ha optado por una evaluación analítica que será validada con otras publicaciones similares realizadas para otros sistemas de micro-movilidad.

1.3 ORGANIZACIÓN DE LA MEMORIA Después de realizar una introducción a las principales cuestiones que han motivado la presente Tesis, así como una descripción de sus objetivos, el resto de la memoria se organiza de la siguiente forma. En el Capítulo 2 se describe las principales contribuciones realizadas sobre el tema de la movilidad en redes IP. Se ha descrito con mayor profundidad el protocolo Mobile IP, al ser la base de la mayoría de las propuestas actuales. También se han clasificado y descrito los sistemas de micro-movilidad donde se encuadra el trabajo realizado. En el Capítulo 3 se presenta el sistema de micro-movilidad basado en multicast que proponemos en esta Tesis Doctoral. En primer lugar se describe la arquitectura de la red propuesta. El siguiente punto se realiza una descripción del modo de funcionamiento del protocolo de micro-movilidad, distinguiendo diferentes mecanismos como el registro, la transmisión de datos, la escalabilidad, etc. En todo momento se muestra la compatibilidad con el protocolo Mobile IP. Se realiza un estudio de la seguridad en el sistema propuesto, analizando la problemática de la seguridad en redes móviles. También se muestran los formatos de todos los mensajes definidos para el sistema propuesto, que se han diseñado de acuerdo a las recomendaciones del propio Mobile IP [RFC 3344], como de algunas propuestas actualmente en investigación. Debido a que nuestro sistema se basa en la transmisión multicast, se ha realizado un estudio


9

para seleccionar la tecnología que más se ajusta a nuestras necesidades. Asimismo se describe como puede incorporarse el protocolo PIM-SM / SSM a nuestro sistema de micro-movilidad. Para finalizar se ha realizado una comparación cualitativa del sistema propuesto con las diferentes soluciones de micro-movilidad que se mostraron en el capítulo anterior. Con el Capítulo 4 comienza el segundo gran bloque en que podríamos dividir esta Tesis, y que trata sobre el proceso de handover. En este capítulo se realiza un estudio del proceso de handover en redes IP móviles. También se ha realizado una clasificación de las soluciones de handover existentes en la bibliografía, prestando especial atención a los handovers propuestos para diferentes sistemas de micro-movilidad, así como aquellos handovers que se basan en la utilización de transmisión multicast. El principal inconveniente del protocolo Mobile IP son sus pobres prestaciones durante el handover. En el Capítulo 5 se realiza una evaluación de las prestaciones del handover en las diferentes redes IP móviles, utilizando herramientas de simulación. El trabajo se ha centrado en analizar el protocolo Mobile IP, donde se ha distinguido la situación en la que el nodo móvil se encuentra cerca de su red origen (que hemos denominado handover cercano), y situaciones donde el nodo móvil se encuentra desplazado de ella (handover lejano). También se ha realizado una evaluación de los diferentes esquemas de handover de sistemas de micro-movilidad presentados en el capítulo anterior. Para finalizar se ha realizado un banco de pruebas, donde se ha evaluado el comportamiento de un esquema de handover de Mobile IP bajo tráfico multimedia. En el Capítulo 6 se muestran cinco esquemas de handover diferentes, propuestos para el sistema de micro-movilidad basado en multicast presentado en el Capítulo 3. Las cinco soluciones aprovechan las facilidades de la transmisión multicast, y abarcan todo un abanico de posibilidades, tanto en lo referente a las capacidades que le ofrece la red (capacidad de comunicación simultanea con dos estaciones base o sólo con una), como en los requisitos del handover (pérdida nula de paquetes, latencia mínima, etc.). Se han propuesto nuevas extensiones para los


10

mensajes que se diseñaron en el Capítulo 3, así como otros nuevos. Además se describe el mecanismo por el cual varios esquemas de handover pueden funcionar simultáneamente en una misma red. Finalizamos el capítulo con una comparación de los esquemas propuestos. En el Capítulo 7 se ha realizado una evaluación analítica de las prestaciones de los cinco esquemas de handover descritos en el punto anterior. El fin es realizar una comparación de las diferentes soluciones, a la vez que investigar la influencia de algunos parámetros de diseño, como puede ser el tamaño de los ‘buffers’. Los estudios se han centrado en el número de paquetes perdidos debido al mecanismo de handover, así como el retardo adicional que se introduce en los paquetes que, por el modo de funcionamiento del esquema, deben ser redireccionados o almacenados. En el octavo y último capítulo se exponen las conclusiones finales, tanto del sistema de micro-movilidad y de los esquemas de handover propuestos, como de los resultados obtenidos. Además se apuntan las líneas futuras de trabajo. La memoria finaliza con las referencias bibliográficas citadas en el texto, ordenadas alfabéticamente. Por último se incorporan dos anexos. El Anexo 1 contiene una lista de los principales acrónimos utilizados, así como un glosario. El Anexo 2 contiene el desarrollo de algunas ecuaciones utilizadas en el capítulo 7, que se sacaron del mismo para facilitar la comprensión del mismo.

11

2. SISTEMAS DE MOVILIDAD EN REDES IP

2.1 INTRODUCCIÓN Los protocolos IP [RFC 791], UDP [RFC768] y TCP [RFC793], base de la actual Internet, se diseñaron asumiendo que los sistemas finales eran estacionarios. Estos nodos se identifican de manera única por medio de una dirección que a su vez es utilizada, tanto para indicar la red a la que está conectado, como para una identificar las conexiones TCP establecidas. Es esta doble función de las direcciones IP, identificación y encaminamiento, la que causa dificultades para la integración de nodos móviles en la arquitectura original. En esta tesis entendemos como nodo móvil a cualquier nodo que tiene capacidad de cambiar su conexión de un enlace a otro, manteniendo todas las comunicaciones existentes, y usando la misma dirección IP en su nuevo enlace. Los routers IP utilizan información contenida en la cabecera de los paquetes IP para realizar el encaminamiento de la información. Específicamente, las decisiones de encaminamiento se toman en función de la parte de identificativo de red de la dirección IP destino, lo que provoca la necesidad de que todos los hosts conectados a un enlace deban tener obligatoriamente idéntico identificativo de red en su dirección IP. De esta manera si un host móvil cambia de situación y se conecta a un nuevo enlace, con un identificativo de red diferente, no podrá recibir información, puesto que los paquetes dirigidos a él se encaminarán hacia el router que da conexión a la red indicada en su identificativo de red.

Una solución sería realizar un encaminamiento basado en Host. Esto es, que las tablas de encaminamiento de los routers contengan información de cómo encaminar paquetes destinados a un nodo móvil. La escalabilidad de la solución, el número de routers implicados, y la seguridad, son algunas de las causas que la hacen inabordable aún en el

Sistemas de Movilidad en redes IP

12

caso de que solo se utilice en las situaciones en las que el nodo móvil no se encuentre en su red origen.

Esta red origen se denomina comúnmente Home Network, y la

podemos entender como la red en el que un nodo debería estar localizado; esto es, la red que tiene asignado el mismo identificativo de red que el que existe en la dirección IP del nodo. En contraposición a esto nos encontramos con la Foreign Network que es cualquier otra red diferente a la Home Network y que por tanto su identificativo de red difiere del de la red IP del nodo. Otra posible solución sería simplemente cambiar la dirección IP del nodo en el momento en que cambia de un enlace a otro. Sin embargo el protocolo TCP utiliza, junto con los números de puerto, las direcciones IP de la fuente y destino para identificar la conexión, y no permite el cambio de las direcciones IP durante la misma. La solución de rediseñar completamente el protocolo TCP para permitir que los nodos móviles actualicen su dirección mientras dura su conexión no se considera apropiada, a pesar de ser una posibilidad interesante desde el punto de vista de la investigación, ya que implicaría una modificación de millones de nodos. Aún así en [SNO00] se propone modificar el protocolo de transporte TCP [RFC 793], de manera que una conexión ya establecida pueda ser suspendida por un extremo y reactivada con otra dirección IP.

Aún en este supuesto existiría otro contratiempo adicional, consistente en el mecanismo necesario para averiguar la dirección del nodo móvil con quien queremos comunicarnos. Al tener una dirección IP cambiante, los servidores DNS deberían ser actualizados constantemente con los problemas de sobrecarga, sincronización y de seguridad que ello conlleva. En este campo B. Awerbuch propuso en 1991 un servicio de directorio de localización distribuido [AWE91]. Por tanto la movilidad de los nodos en la arquitectura TCP/IP ocasiona los siguientes contratiempos:

Sistemas de movilidad en redes IP

13

• Si el nodo adquiere una nueva dirección IP, el identificativo de la conexión TCP cambia, lo que ocasiona que todas las conexiones TCP que tiene abiertas el nodo se pierdan.

• Si el nodo mantiene su dirección IP cuando cambia de red el sistema de encaminamiento no será capaz de hacer llegar los paquetes a la nueva localización.

Existen varias soluciones para el problema anteriormente expuesto

[ALT02]. La primera sería solucionar el problema en un nivel superior, típicamente en el nivel de aplicación. En este sentido todas las propuestas giran en torno al protocolo SIP [RFC 2543] que está ganando rápidamente aceptación como protocolo de control en aplicaciones multimedia y de telefonía en Internet.

Como ya se ha comentado, existen también algunos estudios, como

[CAC94], [BAL96] o [STA98] que defienden la necesidad de modificar el protocolo de transporte TCP para adecuarlo a un entorno donde los nodos son móviles. Básicamente se centran en la limitación del TCP, que asume que los paquetes perdidos lo son únicamente debido a la existencia de congestión en la red. En [SNO00] se propone una arquitectura en la que la movilidad se maneja como un servicio extremo a extremo, y es gestionada por el nivel de Transporte de manera que se realiza una modificación de los protocolos de este nivel manteniendo invariable el protocolo de Red IP.

Sin embargo es la tercera solución, consistente en abordar el problema de la movilidad directamente en el Nivel de Red, la que se está desarrollando con más fuerza. La principal ventaja es que este mecanismo hace que el problema de la movilidad sea completamente transparente a los niveles superiores (nivel de transporte y por supuesto nivel de aplicación). En este sentido se han realizado numerosas propuestas. La mayoría se basan en una arquitectura de direcciones en dos niveles, de tal manera que existe una dirección permanente y otra temporal que cambia en función de la red en la que se encuentra situada el nodo móvil.


14

En [BHA96] se realiza un estudio de los principales aspectos que permiten realizar una clasificación de las diferentes soluciones de Nivel de Red propuestas: los componentes específicos que se añaden a la arquitectura de Internet, los mecanismos que se proponen para realizar una traducción de la dirección permanente a la dirección temporal asociada y la política empleada para tener actualizada la información de localización del nodo móvil. En la siguiente figura se muestra los componentes de la arquitectura genérica propuesta, que puede emplearse para comparar las diferentes soluciones particulares presentadas en la bibliografía.

Figura 2.1 Arquitectura genérica

Según este esquema al nodo móvil tiene asignada una dirección permante (Home Address) utilizada cuando el nodo está situado en la red a la que está asignado (Home Network). Además de forma temporal y cuando está localizado en una red diferente se utiliza una segunda dirección, denominada Forwarding Address, que pertenece a un agente de envío. Existe un Agente de Traducción de Direcciones que se encarga de modificar los paquetes de tal manera que puedan ser encaminados hacia

Agente de traducción de direcciones

Foreign Network

Home Network

Fuente

Agente de Envío

Nodo móvil en una Foreign Network f

g

Directorio de Localización

f: Home Address → Forwarding Address g: Forwarding Address → Home Address


15

el agente de envío. El componente que almacena la asociación entre las direcciones permanente y temporal de cada nodo móvil se denomina Directorio de Localización. Una solución centralizada para la implementación de este directorio no es realizable en una red donde el número de nodos es elevado. Existen trabajos [ANA93] donde se proponen modelos de directorios en función de los patrones de acceso, aunque no son directamente aplicables a una red como Internet al no tener en cuenta factores como la seguridad. Una solución ampliamente aceptada, aunque no la única, es que exista en cada Home Network un componente de direcctorio encargado de mantener las asociaciones de los nodos que pertenecen a dicha red. La operación de traducción de direcciones puede realizarse de diversas formas, aunque tradicionalmente se utilizan principalmene dos soluciones: Encapsulación o Loose Source Routing (LSR).

• Encapsulación: Consiste en añadir una nueva cabecera al comienzo del datagrama original. Esta nueva cabecera contiene como dirección destino la del agente de envío, mientras que se mantiene la dirección del nodo móvil permanente como dirección destino de la cabecera original interior. En la actualidad existen diversosas mecanismos de encapsulación normalizados: Encapsulación IP sobre IP [RFC2003], encapsulación mínima [RFC2004] y encapsulación de encaminamiento genérica (GRE) [RFC1701], aunque el primero es el más utilizado.

• Loose Source Routing (LSR): LSR es una opción que permite especificar una lista de direcciones de tal manera que los routers enrutarán los datagramas hacia todas las direcciones una tras otra. Cuando un datagrama llega a un destino, éste modifica la dirección destino con la siguiente dirección de la lista y modifica un puntero utilizado para indicar a los destinatarios la siguiente dirección.

Además de estas soluciones han aparecido algunos trabajos que

utilizan las características de la transmisión multicast para lograr las


16

necesidades de la movilidad de los nodos. Estas soluciones varían entre seguir manteniendo la arquitectura de direcciones de dos niveles hasta directamente asignar unicamente una dirección multicast a cada nodo móvil. El sistema de movilidad propuesto en esta tesis se puede encuadrar dentro de este grupo de soluciones.

Es importante destacar aquí que los diferentes componentes que

aparecen (Agente de Traducción de Direcciones, Agente de Envío y Directorio de Localización) sólo representan funciones que necesitan ser implementadas, no elementos físicos que deben ser instaladas en la red. Así las diferentes soluciones que se han propuesto en la bibliografía varían considerablemente de unas a otras, lo que da muestra del alto grado de flexibilidad existente.

A continuación se presentan las soluciones de movilidad en redes

IP que se consideran más significativas. En el punto 2.2 se muestran algunos de los primeros trabajos presentados: Esquema de Columbia [IOA91], esquema Sony [TER91], y esquemas basados en LSR [PER94]. El punto 2.3 se centra en el protocolo Mobile IP [RFC 3344] comentándose con cierto detalle pues actualmente es la base y el punto de comparación de todos los estudios realizados. Además se comentarán algunas de las propuestas de mejora de este protocolo publicadas recientemente, como la optimización de ruta o el registro regional. En el punto 2.4 se estudian algunos sistemas que se han diseñado para solucionar las limitaciones de Mobile IP basándose en el concepto de micromovilidad. El punto 2.5 detalla los dos estudios que se han realizado para ofrecer capacidad de movilidad a los nodos basándose en las capacidades de la transmisión multicast [SES97], [MYS97], [MYS98]. En el punto 2.6 detalla los trabajos que se están realizando para ofrecer movilidad en redes basadas en el protocolo IPv6. Para finalizar, en el punto 2.7 se estudian las propuestas que basan en realizar la gestión de la movilidad en el nivel de aplicación [WED99], [SCH00].


17

2.2 PRIMEROS TRABAJOS A continuación van a describirse, muy brevemente, algunos de los primeros trabajos presentados para ofrecer movilidad en redes TCP/IP. No se intenta ofrecer una visión exhaustiva de todos los sistemas que se propusieron sino, simplemente, mostrar la gran flexibilidad existente mostrando las diferentes tendencias que han sido más referenciadas. Así, por ejemplo, el protocolo IMHP [PER94b], [JOH94] y los primeros trabajos de Perkins [PER94] no se comentan, pues son la base del protocolo Mobile IP [RFC 3344] que se muestran con más detalle en el punto 2.3. Comparaciones más profundas sobre estos primeros esquemas pueden encontrarse en [MYL93] o el ya mencionado [BHA96].

Los esquemas que se van a comentar son: esquema de Columbia [IOA91], [IOA93]; Esquema Sony [TER91], [TER93], [TER94]; y esquemas basados en LSR [PER94].

2.2.1 Esquema de Columbia El esquema propuesto por Ioannidis [IOA91],[IOA93] está diseñado para ofrecer movilidad a los usuarios en un entorno de campus. La técnica básica consiste en la creación de una subred virtual de manera que a cada nodo móvil se le asigna una dirección dentro de esta subred.

Existe un grupo de routers (Mobile Support Routers MSR) que anuncian la alcanzabilidad de la subred al resto de la red de campus creando la ilusión de que la subred virtual de nodos móviles es una red real conectada al resto de la red por medio de estos routers. Los MSR proporcionan un punto de acceso a través del cual los nodos móviles pueden conectarse a la red troncal del campus, además de encargarse de dirigir el tráfico desde y hacia los nodos móviles.


18

Cada nodo móvil es siempre alcanzable por uno de estos MSRs, independientemente de su ubicación dentro del campus. Cuando un host envía un datagrama a un nodo móvil el mecanismo enrutamiento IP entrega el paquete al MSR más cercano a la fuente. Si el nodo móvil se encuentra en la celda del MSR, éste le entrega el paquete directamente. En caso contrario lo encamina al MSR responsable utilizando encapsulación. Si un MSR no conociera cual es el router actualmente responsable del nodo móvil se enviaría un mensaje (‘who_has’) a todos los MSR del campus esperando que alguno respondiera.

La técnica propuesta ofrece la ventaja de que no se requiere

ninguna modificación de los protocolos existentes en los hosts ni en el mecanismo de encaminamiento IP. Sin embargo sólo es aplicable a entornos de campus pues el mecanismo de búsqueda de nodo móvil enviando mensajes de consulta a todos los MSR no es escalable.

2.2.2 Esquema Sony La propuesta de Sony [TER91], [TER93], [TER94] presenta un enfoque más agresivo para incorporar la movilidad de los nodos en la arquitectura de Internet, puesto que implica una modificación de los protocolos existentes. En esta propuesta cada nodo móvil tiene asignadas una dirección permanente (denominada por los autores Virtual Network, VIP) y una dirección temporal dependiente de la red donde se encuentra (denominada Physical Network, PIP). Cada vez que un nodo móvil obtiene una dirección temporal nueva informa a un router de su Home Network indicándole esta dirección por medio de un mensaje de control.

Los paquetes dirigidos hacia el nodo móvil, además de incluir como dirección destino la dirección permanente, pueden incluir también la dirección temporal. Los paquetes enviados desde el nodo móvil, cuando se encuentra fuera de su Home Network, incluyen siempre ambas direcciones


19

en el campo de dirección fuente. Así, los routers que encaminan estos paquetes pueden examinar el campo de dirección fuente y actualizar las tablas de traducción de direcciones. Una fuente que desea enviar paquetes a un nodo móvil incluirá la dirección temporal en el campo destino si dispone de la entrada del nodo móvil en la tabla de traducción de direcciones. En caso contrario los paquetes son encaminados hacia la dirección permanente. Durante este encaminamiento puede que algún router disponga de una entrada en su tabla de traducción con la dirección temporal del nodo móvil destino. En este caso interceptará el paquete y lo reencaminará hacia la situación actual del móvil; en caso contrario el paquete llegará al router de la Home Network que reenviará el paquete. Cuando un móvil cambia de red envía una notificación a su Home Network de manera que se actualice las entradas de las tablas de todos los routers que atraviesa. Además estas tablas son mantenidas por medio de temporizadores que borran las entradas si no son actualizadas. Esta propuesta tiene varios inconvenientes: la necesidad de modificación del paquete IP para que contenga dos direcciones fuente, lo que equivale a la modificación del software de red de todos los equipos que forman la red; problemas de escalabilidad puesto que el tamaño de las tablas de traducción de direcciones de los routers crece al aumentar el número de nodos móviles; y el mecanismo de handover que ofrece prestaciones muy bajas, puesto que asume que el paquete de control que indica el cambio de celda no se pierde, y una perdida ocasionaría una interrupción en la transmisión elevada.

2.2.3 Esquema LSR

En contraste con las propuestas comentadas anteriormente, basadas en técnicas de encapsulación, las propuestas LSR [PER94] utilizan una opción del protocolo IP denominada LSR (Loose Source Route).


20

El esquema LSR también permite a cada nodo móvil mantener su dirección IP independientemente de su localización. Para ello se establece una arquitectura en la que en cada Home Network existe un router denominado MR (Mobile Router) que es el responsable de almacenar y mantener la localización actual de cada nodo móvil que ha sido asignado a esa red. Los nodos móviles se conectan a Internet por medio de estaciones base inalámbricas denominadas en la literatura MAS (Mobile Access Station). Cuando un nodo móvil se introduce en una celda controlada por una MAS informa de la dirección IP de la misma a su MR. El router MR almacena esta información en la tabla a la vez que informa a la estación base previa que el nodo se ha movido de celda.

Los paquetes dirigidos al nodo móvil primero se dirigen al router MR por el proceso normal de enrutamiento. Para dirigir un datagrama a la situación actual del nodo móvil, el MR inserta la opción LSR en el paquete, especificando la dirección de la estación base actual (MAS) como un router de transición. Esta opción provoca que los paquetes sean encaminados al nodo móvil vía el MAS. Cuando el nodo móvil contesta a la fuente de los datagramas también inserta la opción LSR, especificando la estación base actual. Así, cuando el host fuente recibe este datagrama, almacena la ruta indicada y la utiliza, en sentido inverso (según está definido en [RFC1122]), para enviar los siguientes paquetes, de manera que a partir de ese momento los paquetes enviados por el host fuente al nodo móvil serán encaminados a través de la ruta óptima, sin necesidad de que se encaminen previamente hacia el MR.

Esta propuesta se basa en la capacidad de los hosts de

implementar el encaminamiento inverso de los paquetes que recibe con la opción LSR. Sin embargo la gran mayoría de los hosts no desarrollan esta tarea de forma correcta, incluso llegan a descartar los paquetes recibidos con esta opción debido a los problemas de seguridad que acarrean. Otro problema es el pobre servicio que los paquetes IP con está opción reciben de los routers. Éstos están optimizados para trabajar con paquetes IP con cabecera simple y cuando reciben uno con opciones en la cabecera directamente lo introducen en una cola de baja prioridad. Debido a estas


21

limitaciones el IETF ya no acepta los esquemas que utilicen la opción de LSR.

2.3 MOBILE IP

Fruto de los trabajos desarrollados por C. Perkins y D. Johnson [PER94b](Protocolo IMHP), [JOH94] y [PER94], junto a los trabajos que se han mostrado en el punto anterior, apareció el protocolo Mobile IP [RFC 2002] en 1996. Desde entonces este protocolo ha sido el punto de referencia para todos los trabajos sobre movilidad en redes IP presentados. Por esto, y porque también aquí se va a utilizar este protocolo como punto de partida, se va a realizar un estudio con cierto detalle del modo de funcionamiento. Una primera aproximación al mismo puede encontrarse en [SOL98]. Actualmente el estándar original ha pasado al estado ‘Obsoleto’ pues ha sido actualizado en [RFC 3344]. En este trabajo vamos a referenciar siempre esta última versión. Las diferencias entre ambas versiones no son especialmente destacables. En la propia [RFC 3344] se realiza una descripción detallada de dichos cambios.

Mobile IP puede verse como un protocolo de nivel de red que

soluciona los problemas de movilidad de los nodos en Internet. Así el propósito es permitir que los paquetes IP puedan ser encaminados a los nodos móviles, los cuales potencialmente pueden cambiar su localización rápidamente. Existen una serie de requerimientos necesarios sobre los que se ha trabajado para el desarrollo de Mobile IP:

• Un nodo móvil debe ser capaz de comunicarse con todos los nodos después de cambiar su punto de conexión en Internet, es decir, debe seguir manteniendo conectividad global.


22

• Un nodo móvil debe ser capaz de comunicarse utilizando su dirección IP permanente (denominada también Home Address) independientemente de su punto de conexión con la red.

• Un nodo móvil debe ser capaz de comunicarse con cualquier nodo independientemente de que no implemente las funciones de movilidad de Mobile IP.

• Un nodo móvil no debe estar expuesto a ninguna amenaza en temas de seguridad a la que no este expuesto cualquier nodo fijo de la red.

Mobile IP define tres entidades funcionales donde deben ser

implementados los protocolos de movilidad.

• Nodo Móvil: un nodo que puede cambiar su punto de acceso a la red desde un enlace a otro manteniendo cualquier comunicación y utilizando sólo su dirección IP permanente (Home Address). Esta dirección es asignada de forma permanente de la misma forma que se asigna una dirección a un host fijo o a un router.

• Home Agent: un router con un interfaz a la red local, Home Network1, que mantiene información de la situación actual del nodo móvil (representada, como veremos a continuación por su Care-of Address). Además envía mensajes de información de la red (Advertises Reachability) y se encarga de capturar los paquetes destinados al nodo móvil y enviarlos por medio de un túnel a su localización actual.

• Foreign Agent: un router con un interfaz a una red externa, Foreign Network2, donde está situado el nodo móvil en la actualidad. Este agente se encarga de ayudar al nodo móvil informando al Home Agent de la Care-of Address asignada al nodo; en algunos casos proporciona dicha dirección y actúa como punto

1 Home Network, red correspondiente al indicador de red de la dirección IP permanente (Home Address) del nodo móvil. 2 Foreign Network, cualquier red diferente de la Home Network, donde se puede encontrar temporalmente el nodo móvil.


23

de salida del túnel, aunque como veremos posteriormente no es obligatorio; por último actúa como router de salida encaminando los paquetes generados por el nodo móvil mientras se encuentra conectado en la Foreign Network.

En la siguiente figura se muestran estas entidades y como se

relacionan entre ellas.

Figura 2.2 Entidades en Mobile IP

Care-of Address.

Se ha nombrado anteriormente el concepto de Care-of Address. Ésta es una dirección IP que se asocia a un nodo móvil cuando está en una red externa (Foreign Network) y generalmente cambia cuando el móvil se traslada de una red a otra. Así, los paquetes dirigidos al nodo móvil se enviarán desde el Home Agent por medio de un túnel utilizando esta dirección como punto de salida. En la figura 2.3 se muestra el proceso de ‘tunneling’ de los paquetes dirigidos hacia el nodo móvil. Existen diversos procedimientos para realizarlo: Encapsulación IP sobre IP [RFC2003], encapsulación mínima [RFC2004] y encapsulación de encaminamiento genérica (GRE) [RFC1701].

Foreign Network

Foreign Network

Home Network

Nodo móvil “at Home”

Home Agent

Foreign Agent

Foreign Agent

Nodo móvil en una Foreign Network


24

Existen dos tipos de Care-of Address:

1. Foreign Agent Care-of Address: es una dirección IP de un Foreign Agent que tiene un interfaz en la red externa (Foreign Network) en la que está actualmente el nodo móvil.

2. Co-located Care-of Address: es una dirección IP asignada temporalmente al nodo móvil. Evidentemente, el prefijo de identificación de red de esta dirección asignada debe coincidir con el de la red (Foreign Network). Este tipo de direcciones suele utilizarse cuando no existe un Foreign Agent en la red y no puede ser utilizada por más de un nodo al mismo tiempo.

Figura 2.3 Túnel IP

Modo móvil Foreign Agent Home Agent

Cabec. Payload Cabecera exterior

Fuente = Fuente original Destino = Último destino

Fuente = Punto de entrada del túnel Destino = Punto de salida del túnel


25

2.3.1 Visión General del Modo de Funcionamiento Podemos resumir el modo de trabajo de Mobile IP en 7 puntos generales:

1. Tanto los Home Agent como los Foreign Agents informan de su presencia a cualquier nodo móvil que se encuentre conectado a cualquiera de sus interfaces difundiendo un mensaje especial denominado en [RFC 3344] Agent Advertisement.

2. Los nodos móviles que escuchan estos mensajes analizan su contenido para decidir si se encuentran en su red local (Home Network) o en otra externa (Foreign Network). Mientras se encuentren conectados en la red local actúan como cualquier nodo estacionario, esto es, sin hacer uso de las capacidades de Mobile IP.

3. Un nodo móvil conectado a una Foreign Network adquiere una Care-of Address. Ésta puede ser adquirida bien leyéndola de los mensajes Agent Advertisement enviados por el agente o bien (en caso de una dirección co-located Care-of Address) por cualquier procedimiento de asignación como DHCP, IPCP (Protocolo de Control IP de PPP) [RFC1332] o incluso de una configuración manual.

4. El nodo móvil registra la dirección adquirida en el paso anterior. Para este registro el nodo se valdrá del Foreign Agent si éste está presente.

5. El Home Agent o cualquier router con conexión a la red local del nodo (Local Network) intercepta los paquetes destinados al nodo y los envía por medio de un túnel hacia la dirección Care-of Address registrada en el paso anterior.

6. Una vez esto, independientemente de que la dirección se corresponda con la de un Foreign Agent o la haya adquirido el nodo se desencapsula el paquete original y se entrega al nodo.

7. En la dirección contraria los paquetes enviados por el nodo son encaminados directamente a su destino sin necesidad de realizar un túnel.


26

Observando los pasos anteriores podemos resumir que una transmisión de un nodo móvil sigue tres fases que numeramos a continuación y que describiremos con cierto detalle en los próximos puntos:

• Descubrimiento del agente, el proceso por el cual un nodo móvil determina su situación actual y obtiene una Care-of Address.

• Registro, procedimiento por el cual el nodo solicita un servicio desde una red externa (Foreign Network) e informa a su agente local (Home Agent) de su dirección externa actual (Care-of Address).

• Los mecanismos específicos por los que los paquetes son encaminados desde y hacia un nodo móvil conectado en una red externa.

2.3.2 Descubrimiento del Agente Como se ha comentado anteriormente el descubrimiento del agente es el proceso por el cual un nodo móvil es capaz de determinar si actualmente está conectado a su Home Network o está en un Foreign Network, o si se ha movido de una red a otra, y de obtener una Care-of Address en caso necesario. Existen dos mensajes para averiguar la situación en que se encuentra el nodo. El primero es la ya comentado ‘Agent Advertisements’ enviado de forma periódica por los agentes, en forma de paquetes de difusión (broadcast) o multidestino (multicast). El segundo tipo de mensajes se denomina ‘Agent Solicitation’ y es enviado por el nodo móvil con el único propósito de forzar a los agentes a enviar un mensaje ‘Agent Advertisements’. Esto es útil en el caso de que el nodo se mueva de forma rápida de una red a otra. El formato de estos mensajes es similar a los mensajes de descubrimiento de ruta ICMP definidos en [RFC1256]. El identificativo de


27

red de la dirección origen del los paquetes ‘Agent Advetisement’ es utilizado por el nodo para determinar si se encuentra en la ‘Home Network’ o si está en una externa o ha cambiado de ubicación. Además existe un campo en el que se encuentran las direcciones Care-of disponibles, pudiendo los nodos utilizar cualquiera de ellas si es necesario. Para determinar si un nodo ha cambiado de red existen varias posibilidades. La primera es estudiar los prefijos de red de las direcciones fuente de los mensajes de anuncio recibidos. Así, si recibe dos mensajes con prefijos de red diferentes supone que se ha cambiado de red por lo que debe obtener una nueva dirección. Otro mecanismo es utilizar el campo de tiempo de vida que existe en los mensajes enviados por el agente. Estos paquetes pueden perderse o llegar con errores debido principalmente que se transmiten por un medio radio con una mayor probabilidad de error, por lo que la recomendación [RFC 3344] indica que los mensajes ‘Agent Advertisements’ deben enviarse por parte del agente a un ritmo 3 veces superior al indicado en su campo Tiempo de vida. Si el nodo no recibe ningún nuevo mensaje en ese tiempo supone que se ha movido a otra red por lo que intentará registrarse con un nuevo agente del que reciba un mensaje, enviando solicitudes si no recibe ninguno. Puede suceder que un nodo conectado a una red no reciba mensajes de anuncio por parte de los agentes aún cuando el nodo los solicite. La primera suposición que hace el nodo es suponer que se encuentra en su red local (Home Network) pero que el agente está muerto. En este caso el nodo simplemente intenta averiguar si está conectado su red, por ejemplo enviando un mensaje ICMP de solicitud de eco al router que utiliza por defecto. Si responde es que está conectado y, por tanto, transmite normalmente. En caso de no recibir respuesta el nodo asume que se encuentra en una red externa (Foreign Network) e intenta obtener una dirección (denominada Co-located Care-of Address) por ejemplo utilizando un servidor DHCP [RFC 2131]. Si tampoco encuentra un servidor DHCP siempre queda la configuración manual de una dirección IP.


28

En esta situación en la que no existen agentes, aún en el caso de que el nodo haya sido capaz de obtener una Co-located Care-of Address queda pendiente el hecho de determinar si ha cambiado de una red a otra. Existen dos posibles mecanismos para detectar esto. El primero es realizar una monitorización de las conexiones TCP que tiene establecidas, de manera que si no se advierte un progreso se puede concluir con que se ha movido desde la última vez que se registró. La segunda solución es poner el interfaz de red en modo promiscuo de manera que pueda examinar todos los paquetes que se transmiten por el enlace no sólo los que van dirigidos a él. De esta forma es capaz de determinar si está en la misma red de la que ha obtenido su Co-located Care-of Address o se ha movido a otra, en cuyo caso intentará obtener una nueva siguiendo el proceso ya mencionado. Hay que indicar que en ambos métodos se requiere de la cooperación de otros niveles adicionales al nivel de red (Transporte y Enlace de datos respectivamente).

2.3.3 Registro El registro es el proceso por el cual se solicitan los servicios de un Foreign Agent y se informa al Home Agent de la dirección care-of actual. Éste se realiza cada vez que el nodo móvil cambia de red o incluso cuando no ha cambiado pero el tiempo de vida del registro actual está apunto de expirar. El registro consiste en el intercambio de dos mensajes, solicitud de registro y contestación (‘Registration Request’ y ‘Registration Reply’). Ambos mensajes se envían dentro de la parte de datos de un mensaje UDP. En la figura 2.4 puede observarse esto.

El proceso empieza con el envío por parte del nodo de un mensaje de solicitud de registro. Como puede verse en la figura 2.5 son posibles varios escenarios. Puede observarse como en el primero está implicado el Foreign Agent y en el segundo, en el que se ha obtenido una Co-located Care-of Address, no. Como contestación a este mensaje el Home Agent


29

enviará una respuesta indicando el resultado de la solicitud. En caso de no recibir respuesta el nodo retransmitirá la solicitud.

Figura 2.4 Utilización de UDP como protocolo de Transporte

Figura 2.5 Escenarios de Registro

UDP [RFC768] ICMP [RFC792]Internet Protocol [RFC791]

Registro Descubrimiento de agente

Home Agent

Foreign Network

Registration Reply

Registration Request


Foreign Network

Home Agent

Registration Reply

Foreign Agent


1 2

3 4


30

Registro utilizando un Foreign Agent.

En este caso el mensaje de solicitud de registro se encapsula en un paquete IP, con la dirección permanente del nodo (Home Address) en el campo dirección fuente y la del agente (Foreign Agent) en el campo de dirección destino.

El agente analizará el mensaje, y si por cualquier motivo no es

válido le enviará un mensaje de rechazo de registro. Algunos de los motivos que pueden ocasionar este rechazo son: el campo de autentificación no es valido; el nodo requiere un tipo de túnel que no es soportado por el agente; el agente no tiene suficientes recursos para aceptar el registro; o el nodo requiere un tiempo de vida que excede el máximo permitido por le agente.

Si el mensaje es válido el agente lo reenviará, sustituyendo,

respectivamente, los campos de IP fuente y destino por la dirección del agente en el interfaz por el que lo envía y la dirección del agente local del nodo (Home Agent). Además el ‘Foreign Agent’ almacenará cierta información (por ejemplo, dirección física, dirección IP y puerto del nodo) para posteriormente poder entregar los paquetes de datos.

El Home Agent recibe el mensaje de solicitud y actualiza la base de

datos donde almacena la información del nodo. Es importante destacar aquí que dependiendo de un campo de la solicitud de registro (denominado bit S) el nuevo enlace sustituye a los anteriores o crea uno nuevo manteniendo los existentes. Un proceso similar es utilizado para eliminar enlaces de la tabla.

Por último el Foreign Agent recibe la contestación de la solicitud de

registro (‘Registration Reply’) y se la envía al nodo utilizando la información almacenada previamente. A partir de ese momento el agente empieza a extraer del túnel paquetes enviados al nodo y a actuar como encaminador por defecto de la información generada por él. En la figura 2.5 puede observarse gráficamente todo el proceso descrito.


31

Registro sin utilizar agente. En el caso en que estemos trabajando sin un agente externo la dirección IP fuente de los paquetes enviados será la dirección temporal obtenida de manera autónoma (Co-located Care-of Address), y la dirección destino la del agente local (Home Agent). En este caso todo el proceso se realiza directamente entre el nodo móvil y su agente local.

2.3.4 Envío de datos Los paquetes enviados a un nodo móvil que se encuentra en su red local (Home Network) son entregados de la misma manera que serían entregados a un nodo fijo, sin que sea necesario ningún procedimiento especial. En este punto vamos a tratar como los datos son encaminados al nodo móvil que se encuentra en una Foreign Network, una vez éste ha realizado el proceso de registro. El proceso se inicia con la intercepción de los paquetes destinados al nodo móvil por parte del agente local. Este proceso se realiza tanto si el transmisor se encuentra en propia red local como fuera de ella.

Posteriormente los reenvía por medio de un túnel a cada una de las Care-of Address almacenadas en la base de datos. Como puede verse en la figura siguiente el proceso variará ligeramente en función del tipo de dirección que ha adquirido el nodo (Foreign Agent Care-of Address o Co-located Care-of Address). En ambos casos el agente local intercepta los paquetes destinados hacia un nodo y lo envía por medio de un túnel a la dirección care-of destino. En el caso de que esta dirección pertenezca a un agente, éste elimina la cabecera exterior para recuperar el paquete original y enviárselo al nodo. En caso de una Co-located address será el propio nodo el que realiza el desencapsulado del paquete.

Hasta ahora hemos comentado como se realiza la transmisión de información desde un host hasta el nodo móvil. Para estudiar la


32

transmisión desde al nodo a un host podemos distinguir dos situaciones. En el caso de que el nodo se encuentre en su red local el envío de paquetes se realiza como lo hace cualquier nodo fijo, esto es, por medio de un router de salida que se obtiene vía DHCP [RFC 2131], IPCP de PPP o incluso por configuración manual.

Figura 2.6 Encaminamiento de los paquetes al nodo móvil

Cuando el nodo móvil se encuentra en una Foreign Network es

necesario un mecanismo para determinar un router por el que encaminar los paquetes generados por el nodo. En el caso de que haya utilizado un Foreign Agent puede utilizarse este mismo agente (la dirección se obtiene del campo dirección IP fuente de los mensajes ‘Agent Advertisements’) o bien cualquier router indicado en el campo Router Address de la porción de mensaje ‘ICMP Router Advertisements’ [RFC 1256] que aparece tanto en los mensajes ‘Agent Advertisement’ como ‘Router Advertisement’. Hay que indicar que un nodo móvil no puede, bajo ninguna circunstancia, enviar paquetes ARP conteniendo su dirección permanente (Home Address) cuando se encuentra en alguna red diferente a su Home Network. Por tanto será necesario algún mecanismo alternativo para obtener la dirección física del router seleccionando (por ejemplo estudiando los mensajes de anuncio del router).

Nodo móvil con Co-located Care-of Address

Nodo móvil con Foreign Agent Care-of Address

Router

Foreign Agent

Host

Home Agent

Paquetes originales

Paquetes en túnel


33

En el caso de que no exista un Foreign Agent también es posible seleccionar un router para poder transmitir paquetes. Una opción es escuchar un router que envíe mensajes ‘ICMP Router Advertisements’. Si no recibe ningún paquete de este tipo el nodo debe utilizar el mismo mecanismo que utilizó para obtener una Co-located Care-of Address: DHCP, IPCP o configuración manual.

2.3.5 Consideraciones relativas a la Seguridad

Los sistemas, como el que estamos estudiando, que permiten la movilidad de los nodos necesitan solucionar una serie de limitaciones que pueden afectar a la seguridad. Así, por ejemplo, en el protocolo Mobile IP el procedimiento de registro ofrece un área particular de vulnerabilidad porque se utiliza para indicar al Home Agent a que dirección debe enviar los paquetes, a fin de que el nodo móvil correspondiente pueda recibirlos. Simplemente con que un ‘bad guy’ [KAU95] envíe un mensaje de este tipo lograría redirigir todos los paquetes hacia la dirección elegida.

Para evitar ataques a la seguridad de este tipo Mobile IP requiere que todos los mensajes de registro entre un nodo y su Home Agent sean autentificados. La autentificación consiste en un proceso por el cual el nodo transmisor asegura su identidad al nodo que recibe. El campo de estudio de la autentificación y de la seguridad en general es muy extenso (una visión detallada podría encontrarse en [SCH95] o en [KAU95]). Este punto se va a centrar exclusivamente en ofrecer una visión general de los mecanismos definidos en la [RFC 3344] y en algunas incorporaciones a la misma que actualmente están bajo estudio.

En [RFC 3344] se indica que la autentificación se realiza utilizando

extensiones de autentificación en los mensajes intercambiados. De las tres extensiones que han sido definidas en la norma la más importante es, sin duda, la extensión de autentificación Mobile-Home puesto que es obligatorio que se incluya en todos mensajes de solicitud de registro


34

(‘Registration Request’) y respuesta (‘Registration Reply’) que intercambian un nodo móvil y su Home Agent.

Esta extensión de autentificación puede observarse en la siguiente figura. El valor de autentificación calculado se obtiene computando mediante un mecanismo de autentificación los campos de carga UDP (es decir el mensaje de Solicitud o Respuesta de Registro), todas las extensiones anteriores, y el tipo y longitud de la extensión de autentificación. Por defecto el mecanismo de autentificación a emplear es el denominado MD5 [RFC 1321] en el denominado modo ‘prefijo+sufijo’, que obtiene un valor de 128 bits como resultado de las operaciones realizadas sobre la información indicada anteriormente y utilizando una clave secreta compartida.

0 7 8 15 16 23 24 31

Tipo = 32 Longitud SPI

SPI (cont.) Autentificador

…………………………

Figura 2.7 Extensión de Autentificación Mobile-Home

La clave compartida que se utiliza está definida por la asociación de

seguridad que se ha establecido previamente entre los dos nodos, y que viene indicada por el valor del campo de la extensión SPI. El valor SPI (Security Parameter Index) define el contexto de seguridad utilizado y, en particular, define el mecanismo de autentificación y la clave a emplear.

Además de la extensión de autentificación Mobile-Home el estándar

define dos extensiones adicionales (Mobile-Foreign y Foreign-Home), cuyo formato es similar al mostrado en la figura 2.7

El tema de la seguridad en redes basadas en el protocolo Mobile IP

está actualmente en desarrollo. Por ejemplo en [RFC 3012] se definen las extensiones para que un Foreign Agent pueda desarrollar mecanismos de


35

interrogación-respuesta (Challenge/Response) (por ejemplo CHAP [RFC 1994]) como mecanismos de autentificación del nodo móvil.

Otro ejemplo es la utilización de servidores AAA (Authentication,

Authorization, Accounting) [PER02] para obtener asociaciones seguras entre el nodo móvil y el Home Agent, o incluso con el Foreign Agent, utilizando para ello la existencia de una asociación de seguridad previa entre el nodo y un servidor AAA como RADIUS [RFC 2865] o DIAMETER [CAL01]. El funcionamiento básico consiste en que un nodo móvil que desea una asociación segura con un host (Home Agent o Foreign Agent) hace una solicitud de material para crear claves a un servidor AAA. Esta clave se distribuirá al host implicado vía el protocolo AAA correspondiente.

Tanto en estudio anterior de utilización de servidores AAA como en

otras propuestas, como pueden ser los mecanismos de Optimización de Ruta o de Registro Regional, que se estudiarán en los siguientes puntos, puede que sea necesario un intercambio de información de material para formar asociaciones seguras. Para normalizar el proceso de distribución de claves entre los diferentes host implicados en una transmisión con Mobile IP, recientemente, en [PER02] se ha definido los formatos de las extensiones generalizados para cualquier distribución de claves, de manera que este tipo de transmisiones quede normalizado.

2.3.6 Optimización de la Ruta

El protocolo Mobile IP soluciona los problemas que supone la existencia de nodos móviles que cambian de situación conectándose a distintos enlaces mientras mantiene conexiones abiertas. Sin embargo el mecanismo empleado, y que podemos resumir en el envío de los paquetes al nodo, desde un agente situado en su red original, utilizando túneles y direcciones temporales adquiridas (Care-of Address), tiene algunas limitaciones.


36

La principal limitación se produce al forzar que todos los datagramas que se dirigen hacia el nodo móvil sean encaminados utilizando el Home Agent. Este problema se conoce en la literatura como encaminamiento en triángulo y se muestra en la figura siguiente.

Figura 2.8 Encaminamiento en triángulo

El mecanismo de encaminamiento de Mobile IP provoca que los

datagramas que se dirijan al nodo móvil sean encaminados, a menudo, por rutas que son significativamente más largas que la ruta óptima. Por ejemplo, si un nodo móvil está visitando una red, incluso los paquetes que le envíe un host que esté situado en esa misma red deberán ser encaminados por la Internet hasta el Home Agent desde donde serán redirigidos, por medio de un túnel, a la red original para ser entregados al nodo móvil. Este encaminamiento provoca retardos en la entrega, inaceptables para aplicaciones en tiempo real, así como un innecesario desperdicio de ancho de banda en la red y recursos de los routers.

La solución a este problema se basa en lograr que el host fuente conozca la dirección temporal del nodo móvil, de manera que pueda encaminar los datagramas directamente. Existen varios trabajos publicados que intentan lograr este objetivo, algunos inclusos previos a la estandarización del protocolo Mobile IP, [JOH95] y [MYL95]. En este punto vamos a comentar las extensiones al protocolo Mobile IP más recientes,

Foreign Network

Home Agent

Host

Foreign AgentNodo móvil en una Foreign Network

Host a Nodo Móvil

Nodo Móvil a Host


37

[PER01], conocidas como “Optimización de Ruta”, y actualmente en formato de Draft (Work in Progress). La Optimización de Ruta ofrece un mecanismo que permite a los nodos almacenar información de la situación de un nodo móvil (Care-of Address), y que permitirá al host enviar los datagramas, por medio de un túnel, directamente a esta dirección. De esta manera se elimina el paso de los datagramas por el Home Agent. Así, un host dispone de una memoria donde almacena la información de diferentes nodos móviles. Si en un instante de tiempo dado no tiene en memoria información sobre el nodo móvil al que desea enviar datos, los datagramas son encaminados hacia la Home Network, de la misma manera que cualquier otro datagrama IP, con el fin de que el Home Agent los reenvíe por medio de un túnel hacia la dirección temporal del nodo móvil (Care-of Address). Además este agente se da cuenta de que la fuente del datagrama no tiene información sobre la dirección temporal del nodo, y por tanto, le envía un mensaje de actualización denominado en la literatura ‘Binding Update’. Al recibir el mensaje, el host fuente actualiza la información almacenada en memoria con el fin de que los datagramas posteriores puedan enviarse utilizando la dirección Care-of Address realizando un encaminamiento óptimo. Un host debe introducir o actualizar información sobre un nodo móvil en su memoria sólo cuando ésta ha sido recibida de una forma correctamente autentificada. Además, la información recibida tiene asociada un tiempo de vida de manera que, una vez concluido este periodo de tiempo, la información sobre la situación del nodo móvil debe ser eliminada de la memoria. Puede ocurrir el caso de que un agente (Foreign Agent) reciba un datagrama dirigido a un nodo móvil que en la actualidad ya no se encuentra en la red. Esto es debido a que el host que envió el paquete por medio de un túnel no tiene en la memoria la situación del nodo móvil actualizada. Para resolver la situación el agente manda un mensaje de alerta (Binding Warning) hacia el Home Agent del nodo móvil implicado,


38

solicitándole que le envíe un mensaje de actualización de situación al host fuente que mandó el mensaje a un destino incorrecto. A diferencia de los mensajes de actualización de información (Binding Update), los mensajes de alerta (Binding Warning) no necesitan ser autentificados porque no afectan directamente al cambio de ruta de encaminamiento de la información. Podemos resumir el proceso de optimización de ruta comentando los cuatro tipos de mensajes que se añadirían a los mensajes especificados en el protocolo Mobile IP.

• Mensaje de Alerta (Binding warning Message): Se utiliza para indicar que es necesario una actualización de la información sobre la situación de un nodo móvil por parte del host fuente. Este mensaje es enviado por el Foreign Agent cuando recibe un mensaje que va dirigido para un nodo móvil que ya no está localizado en esa red.

El mensaje también es enviado por el nodo móvil a su Home Agent en el momento que recibe una nueva Care-of Address. De esta forma solicita que envíe mensajes de actualización (Binding Updates) a uno o más hosts fuente.

• Mensaje de Solicitud de Información (Binding Request Message): Se utiliza por un host para solicitar al nodo móvil o a su Home Agent información sobre la dirección temporal actual.

• Mensaje de Actualización de Información (Binding Update

Message): Se utiliza para notificar la dirección temporal de un nodo móvil. Este mensaje debe ser enviado por el Home Agent en las siguientes situaciones:

o En respuesta a un mensaje de solicitud de información. o En respuesta a un mensaje de alerta. o En respuesta a la recepción de un mensaje para un nodo

móvil que se encuentra fuera de la Home Network.


39

• Mensaje de reconocimiento (Binding Acknowledge Message): Se utiliza para reconocer un mensaje de actualización. Sólo es necesario enviarlo si dicho mensaje solicitaba respuesta.

El principal problema que conlleva este proceso es la autentificación de los mensajes relacionados con el cambio de ruta de los paquetes enviados hacia en nodo móvil. En el protocolo Mobile IP [RFC 3344], sólo el Home Agent debe tener información sobre la nueva ubicación del nodo móvil, pues todo en encaminamiento de los paquetes hacia el nodo móvil, mientras está fuera de su red original, se realiza a través de él. En este caso la autentificación se alcanza estableciendo una asociación de seguridad entre el Home Agent y el nodo móvil. Como ambos pertenecen a la misma organización (los dos tienen asignada una dirección IP dentro de la misma subred), puede realizarse fácilmente una configuración manual de esta asociación. Sin embargo, con las extensiones de Optimización de Ruta el proceso de autentificación es más complejo, puesto que el intercambio de información para la gestión de la ruta puede realizarse con cualquier host de la red. Así, es necesario una asociación de seguridad entre cada host que desea enviar información y el nodo móvil (o Home Agent) receptor. Al no existir en la actualidad un protocolo de distribución de claves se mantiene la distribución de claves de forma manual utilizada en Mobile IP. La asociación puede ser creada utilizando ISAKMP [RFC 2408] o cualquiera de los métodos de establecimiento de claves especificado en [PER00].

Por otra parte el cálculo del campo de autentificación es el mismo que el especificado en el protocolo Mobile IP. Existen métodos más efectivos como el HMAC [RFC 2104] que podría utilizarse una vez sea incorporado al Mobile IP.


40

2.3.7 Mobile IP con Registro Regional Utilizando el protocolo Mobile IP, un nodo móvil se registra con su Home Agent cada vez que se mueve de red y, por tanto, modifica su dirección temporal (Care-of Address). Si la distancia entre la red en la que se encuentra actualmente el nodo y la Home Network es grande, el retardo ocasionado durante estos registros será demasiado elevado.

Para evitar este problemas recientemente se han realizado varias propuestas que que se basan en el concepto de micro-movilidad y que son analizadas en el punto 2.4. Una de ellas, sin embargo, la ha realizado la propia IETF actualmente en estado de Draft (Work in Progress) [GUS02], y se ha considerado conveniente estudiarla aquí por estar íntimamente relacionada con el funcionamiento del protocolo Mobile IP.

La propuesta, denominada Mobile IP con Registro Regional, consiste básicamente en dividir la red en agrupaciones de redes que se van a denominar Dominios. En cada Dominio habrá una serie de Foreign Agents que se van a estructurar en una jerarquía de dos niveles, de manera que en la parte superior existirá al menos un Agente Pasarela (GFA Gateway Foreign Agent) con dirección IP pública y funcionalidades extendidas.

Cuando un nodo móvil llega a un Dominio nuevo debe realizar un registro con su Home Agent. La dirección temporal (Care-of Address) que va a registrar va a ser la dirección pública de un GFA, de manera que se va a evitar realizar un nuevo registro en el Home Agent mientras el nodo móvil permanezca dentro del Dominio. En la figura 2.9 se muestra el mecanismo de registro que se produce cada vez que el nodo se introduce en un nuevo dominio.

Los nodos móviles pueden moverse libremente dentro del dominio pasando de un Foreign Agent a otro sin necesidad de tener que realizar un nuevo registro con el Home Agent. Al entrar en una Foreign Network los nodos obtienen una dirección temporal, ya sea una dirección del Foreign Agent (Care-of Address) o una dirección temporal por cualquier otro método (Co-located Care-of Address). Esta dirección debe ser registrada en


41

el GFA, mediante un Registro Regional, para que este pueda redirigir los paquetes recibidos desde el Home Agent hasta el nodo.

Figura 2.9 Registro en el Home Agent

Así los paquetes destinados al nodo serán enviados por medio de

un túnel desde el Home Agent hasta el GFA (siguiendo el procedimiento establecido en Mobile IP). Este elemento será el encargado de recibirlos y de hacerlos llegar al nodo móvil utilizando la información que el nodo ha proporcionado en el nombrado Registro Regional. Es necesario, por tanto, realizar un nuevo registro regional cada vez que el nodo cambia de red dentro del dominio. Sin embargo este registro es mucho más rápido que el registro tradicional hasta el Home Agent, que podía estar arbitrariamente lejos.

Para poder realizar este Registro Regional se han definido dos

nuevos tipos de mensajes: ‘Regional Registration Request’ y ‘Regional Registration reply’. En la figura siguiente se muestra el proceso de este tipo de registro.

Reg. Req.

Foreign Agent

Home Agent

GFA


Foreign Agent

DOMINIO Reg. Req.

Reg. Req. Reg. ReplyReg. Reply

Reg. ReplyGFA: Gateway Foreign Agent


42

En el estudio [GUS02] se ofrecen soluciones para mantener la seguridad durante todo el proceso mediante el uso de las oportunas extensiones de autentificación que utilizan claves obtenidas por mecanismos como la conexión a servidores AAA (punto 2.3.5).

Figura 2.10 Registro Regional.

Por último indicar que aunque hasta ahora se ha supuesto una

jerarquía de Agentes a dos niveles, la estructura puede ser extendida para incluir múltiples niveles por debajo de GFA.

2.4 SISTEMAS DE MICROMOVILIDAD La propuesta más conocida para una red IP móvil es la basada en el protocolo IP Mobile [RFC 3344] estudiado en el punto 2.3. Este protocolo, sin negar las ventajas ya comentadas que aporta al problema de la movilidad, tiene muchas limitaciones. Algunas de estas limitaciones son la necesidad de un Registro cada vez que el nodo móvil cambia de red, la incapacidad para soportar el movimiento rápido de los nodos, o los problemas que surgen para ofrecer QoS utilizando protocolos tradicionales como RSVP [RFC 2205].

Regional Registration Request

GFA Gateway Foreign Agent

Regional Registration Reply

Foreign Agent


Regional Registration Request

Regional Registration Reply


43

Para solucionar estas limitaciones en la actualidad han surgido un conjunto de soluciones que se basan en el concepto de dividir el problema de la movilidad en dos partes: macro-movilidad y micro-movilidad. Así podemos definir micro-movilidad como el movimiento de los nodos móviles dentro de un nivel local, que se puede denominar dominio. El concepto de macro-movilidad se refiere al movimiento de los nodos entre estos dominios.

Los protocolos de micro-movilidad tienen pues como objetivo el superar las limitaciones de Mobile IP: limitar las interrupciones en el flujo de datos durante el handover; aumentar la eficiencia en el uso de la red, eliminando enrutamientos innecesarios; mejorar la escalabilidad, reduciendo las actualizaciones hacia el Home Agent; y proporcionar un soporte para QoS, por ejemplo limitando el número de reservas que deben de ser reestablecidas cuando el nodo móvil se mueve. La mayoría de las soluciones que se van a mostrar se basan en Mobile IP para soportar la macro-movilidad, diferenciándose en la forma de implementar la micro-movilidad. Puede hacerse una sencilla clasificación de estas soluciones:

• Esquemas de agentes de movilidad jerárquicos, como pueden ser el ya comentado Mobile IP con Registro Regional MIP-RR, [GUS02], o la arquitectura TeleMIP [DAS00].

• Esquemas de encaminamiento basado en host (HBR). Ejemplos de estos son: Cellular IP [VAL99], [CAM00], HAWAII [RAM99], MMP [DUT01] o EMA [ONE00].

A continuación se van a comentar las propuestas Cellular IP,

HAWAII, TeleMIP y EMA por ser las más significativas y las más referenciadas en la bibliografía. Como en puntos anteriores el objetivo es mostrar la variedad de propuestas existentes. Estudios más detallados sobre éstas y sobre MMP (que detalla un protocolo de movilidad para entornos militares) pueden encontrarse en la bibliografía mencionada. Indicar que la propuesta MIP-RR ya fue estudiada en el punto 2.3.7


44

Existe, además, diversa bibliografía donde puede encontrarse comparaciones y análisis de prestaciones de las diferentes propuestas, como por ejemplo: [REI01], [WON01] y [EAR00].

2.4.1 CELLULAR IP Cellular IP [VAL99], [CAM00] es un protocolo de micro-movilidad que ha sido desarrollado en la universidad de Columbia. Proporciona soporte de movilidad en áreas geográficas limitadas, incorporando numerosos principios de diseño de los sistemas celulares como puede ser la conexión pasiva, la gestión de la movilidad o en control del handover. La arquitectura de Cellular IP consta de un agente de movilidad (MA) que actúa como pasarela a la red IP y como Foreign Agent de Mobile IP. Este agente es el encargado de gestionar un dominio que está compuesto por un conjunto de estaciones base (BS, Base Station). Las estaciones base, además de funcionar como punto de acceso inalámbrico, encamina los paquetes IP, e integra las funcionalidades de control de celda que en los sistemas celulares tradicionales (como GSM) están asignadas a los Centros de Conmutación Móvil (MSC Mobile Switching Centers) y los Controladores de Estación Base (BSC Base Station Controllers). En la figura 2.11 se muestre esta arquitectura. La movilidad entre dominios (macro-movilidad) se realiza por medio de Mobile IP, mientras que dentro de un dominio se utiliza el protocolo de encaminamiento propio de Cellular IP. Así, suponiendo Mobile IPv4 y sin optimización de ruta (punto 2.3.6), los paquetes son dirigidos hacia el Home Agent que los envía por medio de un túnel hacia el Agente de Movilidad (MA) que realiza las funciones de un Foreign Agent. Éste desencapsula los paquetes originales y los dirige a las estaciones base. Puesto que dentro de la red Cellular IP los nodos móviles son identificados por su Home Address, los paquetes son encaminados sin ningún tipo de encapsulación o conversión de direcciones.


45

Figura 2.11 Arquitectura Cellular IP

En Cellular IP, tanto la gestión de la localización del nodo móvil

como el soporte del handover están integrados junto al encaminamiento. Periódicamente el MA envía por difusión un mensaje de control que inunda el dominio. Las estaciones base almacenan el interfaz por el que reciben este mensaje, de manera que lo utilizan para encaminar todos los paquetes enviados por los nodos móviles hacia el MA.

Para minimizar el tráfico de control, los paquetes de datos son

utilizados para establecer la localización del nodo dentro del dominio. Estos paquetes son encaminados hacia el MA y el camino recorrido es almacenado por las estaciones base para encaminar los paquetes que van dirigidos a ese nodo móvil. Esta información tiene un tiempo de vida, de tal manera que si no existe un refresco la Estación Base la elimina.

En ocasiones un nodo desea que se mantenga la información de

encaminamiento en los routers y estaciones base aún cuando el no está transmitiendo. Un ejemplo sería cuando el móvil está recibiendo un flujo de paquetes UDP y no tiene datos que transmitir. En este caso, si un nodo no tuviera información a transmitir periódicamente enviaría paquetes

Estación Base B

Estación Base A

Home Agent

Host Fuente

MA

Estación Base C


46

vacíos hacia el Agente de Movilidad para mantener la información de encaminamiento dentro de la red Cellular IP.

Por último mencionar que este protocolo se ha presentado

recientemente para entornos IPv6. En la actualidad está en estado ‘Draft’ (Work in Progress) [SHE01].

2.4.2 HAWAII El protocolo HAWAII (Handover-Aware Wireless Access Internet Infrastructure) [RAM99] fue propuesto por los investigadores de los laboratorios Lucent Bell en 1999. Al igual que Cellular IP, HAWAII es un protocolo de micro-movilidad que se implementa dentro de un dominio, basándose en Mobile IP para soportar macro-movilidad. Los principios de funcionamiento son similares a Cellular IP, utilizando esquemas de establecimiento de rutas que actualizan las tablas de enrutamiento basadas en host de los routers del dominio. Sin embargo Cellular IP se basa en una pasarela que actúa como FA (Foreign Agent) desencapsulando los paquetes antes de entregarlos al Dominio mientras que en HAWAII el móvil obtiene una Co-located Address, que mantiene durante toda su estancia en el dominio, y los paquetes son enrutados directamente hasta el nodo móvil. La arquitectura de red está formada por dominios, cada uno de los cuales consta de estaciones base con capacidad de encaminamiento. Estas estaciones están organizadas en un esquema jerárquico y en la parte superior de la jerarquía existe un router raíz (denominado DRR, Domain Root Router) que actúa como pasarela hacia la Internet. Cada nodo móvil consta de una dirección permanente (Home Address). Mientras el nodo se encuentra en su dominio los paquetes son encaminados hasta el DRR utilizando el identificativo de subred del dominio.


47

Evidentemente el nodo móvil puede cambiar de dominio. Cuando el nodo se sitúa en un dominio HAWAII diferente al suyo obtiene una Co-located Care-of Address perteneciente al rango de direcciones de este dominio que utilizará el HA (Home Agent) para enviar los paquetes utilizando un túnel, exactamente igual que en Mobile IP. El nodo móvil no necesita cambiar esta nueva dirección que acaba de adquirir mientras se mueve dentro del dominio y la conectividad se mantendrá utilizando rutas establecidas dinámicamente. HAWAII gestiona la movilidad de los nodos de una manera similar a Cellular IP utilizando un mecanismo de salto a salto (hop-by-hop). De esta manera cada estación mantiene una tabla en memoria donde se indica hacia donde encaminar los paquetes destinados a los distintos nodos móviles. Para establecer y mantener estas rutas dinámicas se utilizan tres tipos de mensajes: Establecimiento (Power-Up), Actualización (Update) y Refresco (Refresh). Cuando un móvil se conecta a un nuevo dominio envía un mensaje de Establecimiento. Este mensaje hace que se añada una entrada en las tablas de las estaciones base que están situadas en el camino hacia el DRR. Las demás estaciones base no tendrán conocimiento, por ahora, de la existencia de este nodo móvil en el dominio. Para mantener la conectividad extremo-extremo mientras el nodo móvil se mueve libremente por el dominio se utiliza el mensaje de Actualización que se traducirá en la modificación de las entradas de las tablas de las estaciones base. Existen diversos esquemas de actualización que especifican cuando y a quién se envían estos mensajes. El primer mecanismo se denomina Dirigido (Forwarding) y se utiliza cuando el nodo móvil sólo tiene capacidad para comunicarse con un transceiver (por ejemplo terminales en redes GPRS). El segundo, denominado No Dirigido (Non-Forwarding), suele preferirse en casos en las que el nodo tiene capacidad para comunicarse con más de un transceiver (por ejemplo redes basadas en CDMA como UMTS). Estos esquemas serán comentados con más detalle en el tema en el que se trate el mecanismo de Handover.


48

Por último para mantener la información de las rutas en las estaciones periódicamente es necesario enviar mensajes de Refresco que se transmitirán hasta el DRR. Además en [RAM00] se incorpora, al protocolo HAWAII original, un sistema de mantenimiento (Paging) similar al existente en Cellular IP, de manera que el nodo puede estar en reposo y sólo envía un mensaje de mantenimiento cuando cambia de área Los últimos trabajos publicados [RAM00b] presentan una arquitectura de red de acceso basada en IP (Mobile IP y HAWAII) que puede funcionar sobre tecnologías celulares existentes como GPRS.

2.4.3 TeleMIP TeleMIP [DAS00] es una propuesta sencilla para gestionar la micro-movilidad y bien adaptada para funcionar en redes CDMA. Como las soluciones anteriores se basa en la utilización de Mobile IP para ofrece macro-movilidad. La red TeleMIP está compuesta por routers y estaciones base con capacidad de conmutación. La red se divide en subredes cada una de las cuales compuesta por estaciones base y al menos un router que actúa como FA (Foreign Agent). Además se define un nuevo tipo de host denominado Agente de Movilidad TeleMIP (TMA, TeleMIP Mobility Agent). Cada FA debe poder conectar con al menos un TMA de la red. En la figura 2.12 puede observarse la arquitectura.

Cuando un nodo móvil se conecta a una red TeleMIP obtiene dos direcciones temporales del FA local. La primera es la conocida Care-of Address que se registra en un TMA y permanecerá válida mientras el móvil se mantenga en la red TeleMIP. Esta dirección es la que se registrará en el HA (Home Agent) utilizando el conocido protocolo Mobile IP. Además existe una segunda dirección temporal que sólo es válida para la subred donde se encuentra y, por tanto, cambiará cada vez que el nodo móvil cambie de subred.


49

Figura 2.12 Arquitectura TeleMIP

Así, cada vez que un nodo móvil cambia de subred obtiene una segunda dirección temporal e informa a su TMA asociado. Para realizar este registro los nodos móviles utilizan un protocolo denominado IDMP (Intra-Domain Mobility Management Protocol) definido en [MIS00]. La asignación de un TMA a un nodo móvil en particular es irrelevante (aunque se mantiene constante durante toda la estancia del nodo en la red) y se suele utilizar algoritmos para equilibrar la carga de gestión entre todos los TMAs existentes. Hay que recordar que el TMA funcionará como pasarela y FA del protocolo Mobile IP para ese nodo. El funcionamiento es bastante sencillo. Siguiendo el protocolo Mobile IP los paquetes dirigidos a un nodo se enviarán por medio de un túnel utilizando la dirección Care-of Address. Una vez llega a la red TeleMIP, el TMA asociado a ese nodo intercepta ese paquete y lo redirige a la subred donde está situado el nodo móvil en ese momento. Para este proceso se utiliza un túnel con la segunda dirección temporal del nodo móvil que el TMA tiene almacenada. Por último el FA de esa subred entrega el paquete al nodo móvil.

Subred 2

TMA

FA FASubred 1

TMA

Nodo Móvil


50

La arquitectura TeleMIP ofrece algunas ventajas con respecto a otros esquemas como son: lograr actualizaciones de movilidad rápidas; posibilidad de utilizar un rango de direcciones privadas dentro de un dominio, superando la limitación de direcciones existentes IPv4 [RFC 791]; o proporcionar transmisión con QoS, ya que protocolos como RSVP [RFC 2205] no trabajan bien si la dirección destino de un flujo cambia frecuentemente. Indicar que la base de TeleMIP fue anteriormente propuesta en un draft [JON99], (actualizada en [GUS02]) donde se desarrollaba un mecanismo para realizar los registros localmente cuando el móvil se situaba en redes diferentes de su Home Network (punto 2.3.6). La propuesta, igual que TeleMIP, utiliza una pasarela denominada GFA (Gateway Foreign Agent) situada en un nivel más alto de una jerarquía de FA y se encarga de proporcionar una dirección útil mientras el nodo se mantenga en ese dominio. Aún así existen algunas diferencias como por ejemplo que TeleMIP ofrece una arquitectura completa, no sólo un protocolo, además de proponer un modelo de seguridad más sencillo y viable que el registro regional propuesto por el IETF. Por último indicar que esta arquitectura se encuentra actualmente en desarrollo. Así, en [CHA01] se puede encontrar un primer estudio de las prestaciones, basándose en un banco de pruebas en el que no existe una implementación completa de todas las funcionalidades. Además se han desarrollado un mecanismo para soportar handovers rápidos y paging [MIS01], y un marco de trabajo para incorporar garantías QoS en la red TeleMIP [MIS00b].

2.4.4 Edge Mobility Architecture, EMA EMA [ONE00] define un marco de trabajo para gestionar la movilidad dentro de un dominio que trabaja sobre IP, y puede utilizar diferentes redes de acceso radio (TDMA, CDMA, ...). EMA se compone de dos partes: Una arquitectura genérica, y una particularización de esos


51

principios utilizando el protocolo de encaminamiento TORA [PAR97]. TORA es un protocolo de encaminamiento adaptativo diseñado para redes móviles ad-doc (MANET Mobile Ad-hoc NETwork) que en EMA se adapta para el caso especial de redes de acceso inalámbricas. EMA define una arquitectura de red similar a las otras propuestas de micro-movilidad. El elemento base es el denominado Router de Acceso (AR, Access Router) que potencialmente puede estar conectado a estaciones radio base de cualquier tecnología. Cada AR está conectado a una subred compuesta por estas estaciones base y maneja un bloque de direcciones IP. La movilidad de los móviles dentro de una subred está gestionada por los niveles radio (nivel 2), y por tanto EMA se encarga de gestionar la movilidad entre ARs de un dominio. Por último algunos de los routers que están en el límite del dominio actúan como pasarela a la Internet. La movilidad inter-dominios se realiza, como en todos los casos anteriores, utilizando Mobile IP. Cuando un nodo móvil se conecta a una red de acceso inalámbrica contacta con el AR que está conectado a la estación base utilizada. Este router asigna una dirección IP al nodo que será utilizada durante la estancia en el dominio. Mientras el nodo está situado en esa subred local, podrá recibir paquetes encaminados utilizando el identificativo de red, exactamente igual que cualquier nodo fijo. Cuando el nodo cambie de subred se incorporarán rutas específicas en los routers que permitan alcanzarlo, utilizando para ello el mencionado protocolo TORA, convenientemente modificado.

2.5 SISTEMA DE MOVILIDAD BASADO EN MULTICAST Hasta el momento todos los sistemas de movilidad de Nivel de Red estudiados utilizaban técnicas de ‘Tunneling’ como Mobile IP o bien de ‘Enrutamiento Basado en Host’ como algunos de los sistemas de micro-movilidad. En este punto se van a comentar algunos estudios que utilizan las capacidades de transmisión multicast para ofrecer movilidad,


52

recordando que la solución de movilidad propuesta en esta tesis se encuadraría en este apartado.

La utilización de capacidades de transmisión multicast para ofrecer movilidad aporta numerosas ventajas. Estas ventajas son debidas, principalmente, a que ambas tecnologías tienen en común la necesidad de resolver problemas similares, como el proporcionar una abstracción de la localización independientemente de la dirección, el encaminamiento de los paquetes, y la gestión de la localización.

2.5.1 J. Mysore. MSM-IP (Mobility Support using Multicast in IP)

En [MYS97] se describe las equivalencias existentes entre la transmisión multicast y la movilidad. Utilizando esta característica se propone la implementación de la movilidad, asignando a cada nodo móvil una dirección multicast única que permita la utilización de la infraestructura multicast existente sin necesidad de realizar cambios importantes. La propuesta de la utilización de las capacidades multicast como mecanismo para proporcionar movilidad difiere de otros mecanismos como Mobile IP en varios aspectos que mostramos a continuación:

• Direccionamiento: Asignamos a cada nodo móvil una dirección multicast única e invariante. Esto elimina la necesidad de la existencia del Home Agent, así como de todos los mecanismos de traducción de direcciones.

• Encaminamiento de los paquetes: Se elimina la limitación del encaminamiento triangular típico de Mobile IP. Por el contrario es necesario la existencia de routers que soporten multicast en todas las subredes.

• Gestión de la Localización: Tradicionalmente cuando un host quería transmitir información a un nodo móvil utilizaba su


53

dirección permanente. Los paquetes eran interceptados por el Home Agent que conocía en todo momento la situación actual del nodo. Con el esquema propuesto no existe este concepto y para localizar el nodo móvil es necesario utilizar un algoritmo distribuido. Aquí se propone la utilización de servidores de localización que almacenan la información del router multicast a utilizar para alcanzar el nodo móvil. Por ejemplo si se utilizara el protocolo PIM-SM [RFC 2362] se indicaría el ‘Rendezvous Point’.

Esta solución tiene algunas ventajas, las cuales han sido

determinantes para la elección de este tipo de transmisión en el modelo de movilidad desarrollado en esta tesis. Por ejemplo podríamos indicar la posibilidad de utilizar RSVP [RFC 2205] para garantizar QoS o de desarrollar mecanismos de handover muy efectivos. Sin embargo el sistema tal cual lo propone J. Mysore tiene algunos problemas tanto de escalabilidad (por la limitación de direcciones multicast) como de implementación. Algunos de estos últimos se comentan a continuación:

• Respuesta a los mensajes ARP. Cuando un nodo móvil envía una

solicitud ARP [RFC 826] recibirá una contestación con su dirección multicast como dirección destino. Por defecto estos paquetes no son procesados por lo que habría que modificar esto.

• Funcionamiento del protocolo TCP. Debido a la complejidad que implicaría, TCP no puede trabajar sobre multicast. Sin embargo en el esquema propuesto la dirección multicast está asignada a un nodo móvil concreto, por lo que la existencia de un único destino está garantizada. Esto conlleva que no exista ninguna diferencia real con una dirección unicast y que la solución simplemente consista en modificar el protocolo TCP de los nodos móviles para que acepten paquetes TCP con su dirección multicast como dirección destino. En la actualidad han sido propuestas numerosas soluciones al problema de las transmisiones fiables multicast como podría ser RMTP [LIN96] que en caso de prosperar podría introducirse en este esquema.


54

• Mensajes ICMP: Cuando un router detecta un error en una transmisión de un paquete envía un mensaje ICMP de error a la fuente para informarle de dicho suceso. Sin embargo esto no podrá realizarse debido a que la dirección destino es ahora una dirección multicast.

Una solución propuesta por el autor para estos y otros problemas

de implementación es la de hacer que los nodos móviles obtengan una dirección unicast temporal dentro de la subred donde se encuentran, por ejemplo vía DHCP [RFC 2131], para utilizarla en los mecanismos propios de la gestión del nivel de red ya comentados.

Las limitaciones comentadas han sido resueltas en [MYS98] modificando los protocolos antes mencionados, y se ha realizado un análisis de prestaciones del esquema implementando un banco de pruebas en laboratorio.

Otro trabajo interesante se detalla en [HEL00]. De igual manera que J. Mysore, Ahmed Helmy asigna a cada usuario móvil una dirección multicast, utilizando como protocolo PIM-SM [RFC 2362]. La principal aportación que ofrece este autor es el de haber realizado un análisis de prestaciones utilizando simulaciones de un entorno como Internet. Estos estudios demuestran unas mejoras muy significativas con respecto a los sistemas tradicionales de movilidad como Mobile IP en aspectos tan importantes como ancho de banda consumido, o retardos durante el handover.

2.5.2 Daedalus

En el proyecto Daedalus [SES97] se utiliza también direccionamiento multicast, pero se mantiene una arquitectura a dos niveles similar a Mobile IP. Los paquetes son enviados hacia la Home Network de manera tradicional, puesto que cada nodo móvil sigue disponiendo de una dirección permanente (Home Address).


55

El Home Agent interceptará los paquetes dirigidos hacia el nodo,

utilizando un mecanismo Proxy ARP, y los reenviará a una o más estaciones base donde se encuentre el nodo móvil. Este envío se realizará utilizando las capacidades multicast. Así, cada nodo móvil tiene asignada una dirección multicast, que será utilizada por el Home Agent para encapsular los paquetes y enviarlos hacia las estaciones base en las que se encuentra el nodo. Estas estaciones deberán, por tanto, haberse subscrito al grupo multicast de la dirección del nodo móvil.

Las estaciones son capaces de conocer que nodos móviles están en

la celda controladas por ellas enviando periódicamente señales indicativas. El nodo las recibe, y en función de la potencia y calidad de estas señales, decide solicitar a la estación base que se subscriba al grupo multicast de su dirección. De esta manera la estación base empezará a almacenar paquetes dirigidos al nodo. Un nuevo mensaje del nodo indicará que ha ingresado completamente en la celda y que, por tanto, puede hacerse cargo del envío de los paquetes hacia él. Con este esquema de Handover se minimiza las pérdidas y el retardo del proceso de cambio de celda.

2.6 IP MOBILE v6 Como se ha estudiado, Mobile IP [RFC 3344] está diseñado para

trabajar con la versión 4 del protocolo IP [RFC 791]. La estandarización de una nueva versión de este protocolo [RFC 2460] ha llevado al grupo de trabajo Mobile IP del IETF a realizar una adaptación del protocolo para que trabaje con esta nueva versión del famoso protocolo de red. En este sentido el protocolo Mobile IPv6 está todavía en estado de Draft (Work in Progress) [JOH03] a pesar de que la primera versión apareció en Septiembre 1994 incluso antes de que IPv6 estuviera estandarizado.

El protocolo IPv6 incorpora una serie de ventajas que hacen muy

sencillo el proceso de la incorporación de la movilidad. Por ejemplo, el aumento sustancial del espacio de direcciones (128 bits en lugar de los 32


56

de IPv4) [RFC 2373] va a hacer innecesario el uso de Foreign Agents, de manera que a los nodos móviles siempre se les asignarán, cuando visiten diferentes redes, direcciones únicas. Este mecanismo se conoce, en Mobile IP, como asignación de una Co-located Care-of Address, (punto 2.3.). Otra de las principales incorporaciones del protocolo, la definición de diferentes cabeceras de extensión en el paquete IP es utilizada, por la nueva propuesta de movilidad en IP, para facilitar su implementación y solucionar los ya comentados inconvenientes de Mobile IP, como puede ser el problema del encaminamiento triangular.

Aunque existen diferencias importantes entre la nueva propuesta

Mobile IPv6 con respecto al protocolo Mobile IP original [RFC 3344], la base del funcionamiento permanece constante. Así cuando un nodo está en una red distinta a la de origen obtiene una dirección temporal denominada en la propuesta Care-of Address (que se corresponde con las direcciones Co-located Care-of Address de la versión 4). Esta dirección puede obtenerse bien por un servidor DHCP (mecanismo denominado Stateful Address Autoconfiguration) o bien mediante la recepción de mensajes de información ‘Router Advertisements’ (mecanismo Stateless Address Autoconfiguration [RFC 2462]). Como en la versión anterior esta dirección temporal debe ser enviada al Home Agent, con el fin de que sea capaz de redireccionar los paquetes dirigidos al nodo móvil.

Este proceso se realiza enviándole un paquete IPv6 con una

extensión de cabecera de Opciones de Destino especial denominada ‘Binding Update’ que deberá ser autentificada utilizando una Cabecera de Autentificación [RFC 2402] o bien con una cabecera ESP (Encapsulating Security Payload) [RFC 2406]. El Home Agent reconocerá el registro utilizando otra Opción de Destino denominada ‘Binding Acknowledgement’ e igualmente autentificada.

Cuando el nodo móvil tiene que transmitir lo hace directamente al

destino poniendo su dirección temporal como dirección fuente. Además se añade una Opción de destino denominada ‘Home Address’ donde se indica la dirección permanente del nodo móvil. Como esta dirección es fija es


57

posible hacer transparente a los niveles superiores del nodo fijo el uso de direcciones temporales (Care-of Address) por parte del nodo móvil.

La nueva versión del protocolo ha solucionado el problema del

encaminamiento triangular que ocurría en Mobile IP. Ahora el nodo móvil puede enviar Binding Updates a cualquier nodo fijo o estacionario con el que se comunica. Todos los nodos en IPv6 disponen de una memoria de vínculos (Binding Cache) para mantener esta información. Esto permite a los nodos enviar los paquetes directamente a los nodos móviles sin tener que realizar el envío a la dirección permanente (Home Address). Figura 2.13

Figura 2.13 Optimización de Ruta en Mobile IPv6

Cualquier nodo que desea enviar un paquete primero consulta su

memoria de vínculos en busca de la dirección destino. Si la encuentra envía el paquete utilizando una extensión de ‘Cabecera de Encaminamiento’. La ruta especificada por esta cabecera tiene dos saltos. El primero es la dirección temporal (Care-of Address) y el segundo la dirección permanente (Home Address). De esta manera el paquete se encamina hasta la dirección temporal del nodo móvil y este internamente se lo envía al mismo de manera que finalmente se procesa de la misma manera que si el nodo estuviera en su red.

Foreign Network

Home Agent

Host

Foreign AgentMobile Node en una Foreign Network

Binding Update

Paquetes de datos


58

Si no existiera ninguna entrada en la memoria el paquete sería enviado normalmente a la dirección permanente del nodo móvil. Así sería recibido por el Home Agent y reenviado, por medio de un túnel, a la dirección temporal del nodo. Cuando un nodo recibe un paquete de esta manera envía un mensaje de ‘Binding Update’ para que el host correspondiente actualice su memoria y a partir de ese momento envíe los paquetes directamente a la dirección temporal evitando el encaminamiento triangular.

También se posibilita a los nodos preguntar por la dirección

temporal de un nodo móvil, por ejemplo con el fin de refrescar su memoria de vínculos. Esto se realiza enviado una Opción de Destino denominada ‘Binding Request’ al que se contestará con un mensaje de tipo ‘Bindig Update’.

Por último podemos concluir realizando una breve comparación

entre el protocolo Mobile IP [RFC 3344] y la nueva propuesta comentada en este punto [JOH03].

• La extensión del protocolo Mobile IP estudiada en el punto

2.3.6, Optimización de Ruta, [PER01] ha sido incorporada al nuevo protocolo como una parte fundamental del mismo. Esta integración ha permitido solucionar uno de los principales inconvenientes del protocolo original y que se conoce como Encaminamiento triangular.

• El uso de las extensiones de cabecera ‘Opciones de Destino’ permite enviar la información de control insertada en un paquete IPv6 de datos (técnica ‘Piggybacking’).

• Desaparece la necesidad de utilizar Foreign Agents. En Mobile IPv6 los nodos móviles hacen uso de nuevas características como el descubrimiento de vecino, Neighbor Discovery [RFC 2461] o Autoconfiguración de direcciones [RFC 2462] para funcionar en cualquier red sin la necesidad de un soporte especial por parte de un router local.


59

• Ahora la mayoría de los paquetes enviados a un nodo móvil cuando se encuentra fuera de su Home Network se envían utilizando una Cabecera de Enrutamiento en vez de utilizar encapsulación. Esto reduce la cantidad de bytes adicionales que deben ser añadidos a cada paquete.

• Los paquetes que se envían a la red local cuando el nodo está fuera de ella son interceptados por el Home Agent utilizando técnicas de Descubrimiento de Vecino [RFC 2461] en vez del utilizar ARP [RFC826] como en IP Mobile v4.

• La nueva versión añade mecanismos para descubrir dinámicamente la dirección del Home Agent de un nodo. Se utilizan las funcionalidades del direccionamiento Anycast [RFC 2526] de manera que el nodo recibe una única contestación con todos los posibles Home Agent y su nivel de preferencia. En la versión 4 se utilizaba una transmisión ‘broadcast’ y se recibían múltiples respuestas.

2.7 SOLUCIONES DE MOVILIDAD A NIVEL DE APLICACIÓN Ya se ha comentado que una de las posibles soluciones para ofrecer movilidad en redes IP es implementarla a Nivel de Aplicación. Esto permitiría independizarla de la tecnología inalámbrica y de los elementos de red existentes, solución especialmente interesante para proveedores de servicio que no disponen de su propia red. En este campo el protocolo SIP se ha convertido en la solución preferida hasta el punto que grupos de trabajo como 3GPP, 3GPP2 y MWIF han propuesto SIP como base para la gestión de la movilidad en Internet [DUT01b]

SIP (Session Initiation Protocol) es un protocolo de control para la creación, modificación y finalización de sesiones con uno o más participantes [RFC 2543]. SIP es un protocolo cliente-servidor que trabaja a nivel de aplicación. Las peticiones son emitidas por el cliente y las


60

respuestas son devueltas por el servidor. Así se reutiliza mucha de la sintaxis y semántica de HTTP [RFC 1945], incluyendo su arquitectura de código de respuesta o muchas cabeceras de mensaje. Es interesante destacar que aunque este trabajo esta centrado en la movilidad de terminal, SIP ofrece facilidades para poder ofrecer movilidad personal, de sesión y de servicio [SCH00], lo que resulta muy interesante para proveedores de aplicaciones como telefonía IP. Básicamente soportar movilidad de terminal consiste en poder ofrecer la capacidad de que un terminal pueda estar en movimiento manteniendo en todo momento las conexiones que en ese instante estuvieran establecidas. Con SIP no se requiere que los nodos móviles tengan que realizar modificaciones en su software de red. En el caso de que aún no se hay establecido una conexión la movilidad basada en SIP es muy sencilla y consiste, simplemente, en volverse a registrar en su servidor de registro SIP cada vez que se adquiere una nueva dirección IP.

Por otro lado, si un nodo se mueve durante una sesión activa primero recibe una dirección de un servidor DHCP [RFC2131] y, posteriormente, envía un mensaje de ‘Invitación’ al host con el que se está comunicando utilizando el mismo identificativo de llamada que el utilizado en el establecimiento de la conexión, y poniendo la nueva dirección IP en el campo ‘Contacto’ del mensaje SIP, [WED99]. Para tratar de disminuir el retardo en realizar esta operación [SCH00] propone la incorporación de mecanismos similares a los protocolos de micro-movilidad estudiados en el punto 2.4. También en [DUT01b] se propone el protocolo de micro-movilidad MMP [DUT01] como alternativa para disminuir la necesidad de actualización en los servidores SIP.

También se ha estudiado la inclusión de métodos de Registro Jerárquico, similar al desarrollado para Mobile IP [GUS02], para disminuir los retardos producidos al registrar el movimiento del nodo en su Registro que se realiza cada vez que se cambia de dirección IP.


61

En general, las soluciones propuestas en la bibliografía [WED99] se basan en utilizar sistemas de movilidad basados en SIP para comunicaciones multimedia que trabajan sobre UDP y utilizar soluciones de Nivel de Red (típicamente el protocolo Mobile IP o alguna de sus variaciones, punto 2.4) para conexiones TCP. Se propone incluso que algunas aplicaciones TCP, como navegadores Web o aplicaciones de correo electrónico, puedan utilizarse sin la necesidad de protocolos que permitan la movilidad ya que requieren conexiones lo suficientemente cortas como para poder asumir el coste de realizar de nuevo toda la conexión. Además algunos de estos protocolos como http/1.1 [RFC 2616] o FTP [ELZ01] incorporan capacidades para minimizar el impacto de esta desconexión. Para implementar esta solución utilizaría una tabla (ya propuesta en [ZHA98]) de políticas con la que se decidiría, para cada aplicación, que solución utilizar. Por último indicar que en la actualidad ya existen propuestas que también utilizan el protocolo SIP para aplicaciones No-Tiempo-Real que trabajan sobre TCP. Para ello utilizan encapsulación y un nuevo tipo de mensaje SIP denominado ‘Info’ [RFC 2976].

2.8 RESUMEN DEL CAPÍTULO

La incorporación de facilidades de movilidad de terminal en redes basadas en la arquitectura TCP/IP no es un problema con solución evidente. Los nodos que forman la red se identifican de manera única por medio de una dirección que a su vez es utilizada para identificar la red a la que está conectado. Esta doble función de la dirección de un nodo, identificación y encaminamiento ocasiona numerosos problemas para permitir la movilidad de los nodos.

Existen numerosas tendencias a la hora de proponer soluciones. La solución de abordar el problema directamente a nivel de red es la que tiene más propuestas. En este sentido en el punto 2.2 se han estudiado las primeras propuestas que se publicaron. Sin embargo la solución más


62

difundida y punto de referencia en todos los sistemas de movilidad actuales es el protocolo Mobile IP [RFC 3344] que ha sido explicado en el punto 2.3. En este punto también se han estudiado dos de las extensiones más populares a este protocolo: Optimización de Ruta y Registro Regional. Ambas están, actualmente, bajo de estudio. Sin embargo el protocolo Mobile IP tiene algunas limitaciones que indicamos a continuación:

• Los handovers no pueden considerarse ‘rápidos’ ni ‘suaves’ (ver capítulo 4), ya que el nodo móvil debe indicar al Home Agent cada cambio de su dirección temporal.

• En caso de que el nodo móvil se encuentre lejos de su Home Network los mensajes de control del protocolo introducen sobrecarga en la red.

• Mobile IP puede afectar a los protocolos de QoS, haciendo que su implementación sea problemática. Por ejemplo Mobile IP utiliza túneles, de manera que la cabecera de los paquetes, que pueden contener información QoS, queda oculta a los dispositivos de interconexión. Se han realizado propuestas que se basan dividir el problema de la

movilidad en dos partes: macro-movilidad y micro-movilidad. Así podemos definir micro-movilidad como el movimiento de los nodos móviles dentro de un nivel local, que se puede denominar dominio. El concepto de macro-movilidad se refiere al movimiento de los nodos entre estos dominios. En este sentido en el punto 2.4 se han estudiado algunas de las propuestas de micro-movilidad más extendidas como Cellular IP [VAL99], HAWAI [RAM99], EMA [ONE00] o TeleMIP [DAS00].

Se han estudiado también algunas soluciones que se basaban en la

utilización de transmisión multicast para solucionar el problema de la movilidad, como por ejemplo [MYS98] o [HEL00]. Estas soluciones, sin embargo, no están planteadas para entornos de micro-movilidad, por lo que tienen importantes limitaciones en cuanto a la escalabilidad y prestaciones durante el handover.


63

Por último, y para terminar las soluciones a nivel de red, en el punto 2.6 se ha comentado la nueva versión del protocolo Mobile IP, actualmente bajo estudio, que se basa en el protocolo de nivel de red IPv6 [RFC 2460].

Otra de las posibles soluciones para ofrecer movilidad en redes IP

es implementarla a Nivel de Aplicación. Casi todas las propuestas utilizan el protocolo SIP (Session Initiation Protocol) [RFC 2543]. En el punto 2.7 se han estudiado algunas de las posibles soluciones de movilidad utilizando SIP [DUT01], [WED99].

Podemos concluir indicando que es una idea generalizada el que la

mejor solución para mejorar las prestaciones del protocolo Mobile IP es la utilización de protocolos de micro-movilidad. Las propuestas en este aspecto pueden ser agrupadas en dos grandes grupos: esquemas de movilidad jerárquicos y encaminamiento basado en host. Ambos grupos tienen sus ventajas y limitaciones sin poder concluir que una solución es mejor que otra.

Por otro lado, las soluciones basadas en multicast ofrecen algunas

soluciones que merece la pena ser consideradas, principalmente en las cuestiones relativas a las prestaciones durante el handover. En esta tesis se propone un sistema de micro-movilidad basado en multicast que nos va a ofrecer, tanto las ventajas de los sistemas de micro-movilidad en general, como las específicas de utilizar la tecnología multicast.


64

65

3. PROPUESTA DE SISTEMA DE MICROMOVILIDAD BASADO EN MULTICAST

3.1 INTRODUCCIÓN Como ya se ha comentado el protocolo Mobile IP [RFC 2002] y

alguna de sus variaciones, como la Optimización de Ruta [PERK01], tienen varias limitaciones. Algunas de estas limitaciones son la necesidad de un registro cada vez que el nodo móvil cambia de red, la incapacidad para soportar el movimiento rápido de los nodos, o los problemas que surgen para ofrecer QoS utilizando protocolos tradicionales como RSVP [RFC 2205].

En la actualidad han surgido un conjunto de soluciones basadas en el concepto de dividir el problema de la movilidad en dos partes: macro-movilidad y micro-movilidad (punto 2.4). Así, podemos definir micro-movilidad como el movimiento de los nodos móviles dentro de un nivel local, que se puede denominar dominio1. Por otra parte el concepto de macro-movilidad se refiere al movimiento de los nodos entre estos dominios.

La primera implicación de distinguir entre macro-movilidad y

micro-movilidad es que la mayor parte de los movimientos de los nodos móviles puede ser gestionada localmente por el protocolo de micro-movilidad. Esto es interesante desde el punto de vista de la escalabilidad, puesto que se evita la señalización al Home Agent cada vez que el nodo móvil cambia de subred.

1 Los términos suelen variar dependiendo de la bibliografía. Por ejemplo en [MAN02] (Work in progress) se recomienda utilizar el término ‘Red de Acceso’ (Access Network, AN). En este trabajo se va a mantener, sin embargo, el término ‘dominio’ por ser el más extendido.

Sistema de micro-movilidad basado en multicast.

66

En el punto 2.5 se ha estudiado la aparición de propuestas que se basan en la utilización de las capacidades multicast para permitir la movilidad de los nodos. El direccionamiento multicast tiene mucho en común con la movilidad, ya que ambas tecnologías se enfrentan al problema de la localización del nodo independientemente de la dirección.

Sin embargo, los esquemas de asignación de una dirección

multicast global y permanente a cada nodo móvil, como los presentados en el punto 2.5 ([MYS98], [HEL00]), tienen serios inconvenientes que hacen que su implantación real sea inabordable. Algunas de estas dificultades se detallan a continuación:

• La utilización de una dirección multicast única y permanente para cada nodo requiere un esquema de asignación de direcciones global, y una cantidad de recursos multicast, por ejemplo direcciones multicast libres, que en la actualidad no está disponible.

• La arquitectura requeriría que toda la red soportara esta tecnología. Hoy en día la capacidad de transmisión multicast en Internet está soportada sólo parcialmente.

• A medida que el número de direcciones multicast (nodos) crece aumenta la información que deben almacenar los routers implicados. Esto puede ocasionar problemas de desbordamiento en los routers o la necesidad de aumentar la complejidad de los mismos. Una de las aportaciones de esta tesis consiste en un esquema de

gestión de movilidad escalable, basado en una arquitectura de micro-movilidad que explota las capacidades de la transmisión multicast. Este esquema solucionará las limitaciones mencionadas de los sistemas de movilidad basados en una dirección única y global multicast, sin perder, sin embargo, ninguna de las cualidades que ofrece este tipo de esquemas.

El modelo propuesto actuará dentro de un domino y, por tanto,

funcionará en conjunción con otros protocolos encargados de implementar

Sistema de micro-movilidad basado en multicast

67

la macro-movilidad, como Mobile IP o sus diferentes variaciones. Es decir, el sistema propuesto coopera con Mobile IP de manera similar a como lo hacen todos los sistemas de micro-movilidad estudiados anteriormente (punto 2.4). En el punto 3.2 se va a presentar la arquitectura, mientras que el sistema de micro-movilidad basado en multicast se detalla en el punto 3.3. Algunos conceptos referentes a la seguridad del sistema propuesto se abordan en el punto 3.4. El formato de los diferentes paquetes intercambiados se muestra en el punto 3.5. En el punto 3.6 se aborda la tecnología multicast empleada. Finalmente una comparación de este protocolo con las otras propuestas existentes se realiza en el punto 3.7. Las conclusiones del capítulo se muestran en el punto 3.8.

3.2 ARQUITECTURA Se propone una arquitectura jerárquica similar a los modelos de micro-movilidad existentes en la actualidad. Según esta arquitectura existe un nivel inferior, que denominamos ‘dominio’, donde se produce la micro-movilidad y un nivel superior, que abarca toda la red, donde se producirá una movilidad global o macro-movilidad.

La arquitectura de estos dominios está formada por un Agente de Movilidad Multicast (MMA) que actúa como pasarela a la red IP y como Foreign Agent de Mobile IP. Este agente es, en cierto sentido, similar al agente de movilidad TeleMIP [DAS00] o a la pasarela GFA de Mobile IP con Registro Regional [GUS02], y es el encargado de gestionar un dominio que está compuesto por un conjunto de subredes conectadas por medio de routers con capacidad multicast. La arquitectura de un dominio puede observarse en la siguiente figura.

Además existe un conjunto de Estaciones Base (BS) que serán las encargadas de intercambiar información de control con el nodo móvil (MN). Estas estaciones tienen capacidades de nivel tres, es decir, son routers


68

modificados para implementar las tareas asignadas por el sistema de micro-movilidad basado en multicast. Las Estaciones Base van a heredar también las tareas que realizaban los Foreign Agents de Mobile IP.

Figura 3.1 Arquitectura de un Dominio.

Cada una de las regiones que controla una Estación Base puede

verse como una subred. La conexión del nodo móvil con la estación base se realiza por medio de antenas que aquí denominaremos Puntos de Acceso. Es posible que cada región esté controlada sólo por una antena, en cuyo caso la tecnología puede integrarse con la Estación Base. Otra solución es la existencia de múltiples Puntos de Acceso conectados por medio de una red de área local. En este caso los Puntos de Acceso trabajan a nivel dos y podría tratarse, por ejemplo, de una red WLAN IEEE 802.11. En la siguiente figura se muestra esta opción.

Hay que indicar que un movimiento del nodo móvil entre estas

microceldas controladas por Puntos de Acceso se realiza a nivel dos y, por tanto, de forma transparente a los niveles superiores de la jerarquía.

Nodo Móvil

MMA

Router Multicast

Router Multicast

Subred 1

BS

Subred 2

Subred 3

BS

BS


69

Figura 3.2 Subred controlada por una Estación Base.

Utilizando esta arquitectura es posible diferenciar distintos tipos de

movilidad:

• Movilidad Local dentro de una subred.

• Micro-movilidad dentro de un dominio.

• Movilidad global o Macro-movilidad. La movilidad local consiste en el movimiento de un nodo dentro de

una zona limitada como puede ser un entorno de oficinas, o una fábrica. En esta situación la conexión del nodo móvil a la red se realiza por medio de puntos de acceso conectados a la misma subred, utilizando por ejemplo una red Ethernet conmutada. Esta movilidad está gestionada a nivel dos, y por tanto va a ser transparente al trabajo desarrollado en esta Tesis. Ejemplos de esta gestión pueden ser los mecanismos de ‘roaming’ implementados en las redes IEEE 802.11, y actualmente estandarizados bajo el nombre de IEEE802.11f, o el trabajo de handovers rápidos propuesto en [CAC96].

El segundo nivel dentro de la jerarquía de movilidad es la movilidad

dentro de un dominio. Es el caso típico de movimiento dentro de un

BS


70

campus, un aeropuerto o la movilidad dentro de una ruta preestablecida (línea de tren, metro o autopista). Como ya se ha estudiado, según un protocolo de movilidad tradicional como Mobile IP sería necesario que este movimiento fuera indicado al Home Agent con la consiguiente penalización en las prestaciones. En el punto 2.4 se estudió los diferentes sistemas de micro-movilidad que proponían distintas soluciones a este problema. La solución que ofrecemos en esta Tesis se detalla en los puntos siguientes.

Por último el tercer nivel de la jerarquía ofrece movilidad global, es

decir, entre diferentes dominios. En este caso es necesario informar al Home Agent. Esta comunicación se realiza por medio del Foreign Agent del dominio, que en nuestra arquitectura se denomina MMA (Agente de Movilidad Multicast), y empleando el protocolo Mobile IP. La utilización de este protocolo no excluye, sin embargo, el uso de las diversas variaciones propuestas en la bibliografía como, por ejemplo, la Optimización de Ruta [PER01].

3.3 PROTOCOLO DE MICRO-MOVILIDAD BASADO EN MULTICAST

En el punto 2.4 se realizó una breve clasificación de los sistemas de micro-movilidad, diferenciando los basados en agentes de movilidad jerárquicos y los esquemas que utilizaban encaminamiento basado en Host. El sistema propuesto podría encuadrarse en un tipo distinto a los dos anteriores denominándose, por ejemplo, Esquemas Basados en Multicast.

El funcionamiento básico consiste sustituir las direcciones

temporales (Care-of Address), que va adquiriendo el nodo cuando cambia de red en el protocolos Mobile IP, por una dirección multicast que se va a mantener constante mientras el nodo permanece en el dominio.

La movilidad entre dominios (macro-movilidad) se realiza por medio

de Mobile IP, mientras que dentro de un dominio se utiliza un protocolo de


71

encaminamiento multicast. Así, suponiendo Mobile IPv4 y sin Optimización de Ruta (punto 2.3.6), los paquetes son dirigidos hacia el Home Agent que los envía por medio de un túnel hacia el Agente de Movilidad Multicast (MMA) que realiza las funciones de un Foreign Agent y de encapsulación multicast. Éste desencapsula los paquetes originales y los redirige utilizando como dirección destino la dirección multicast asignada al nodo móvil.

Podemos resumir el modo en que funciona el protocolo en los

siguientes puntos:

• Todas las subredes que forman un dominio disponen de un Agente (implementado en la Estación Base) que informa tanto de la subred actual y del dominio a la que pertenece como de la/s dirección/es del MMA de ese dominio a cualquier nodo móvil que se encuentre conectado. Para ello difunde un mensaje especial denominado Agent Advertisement.

• Los nodos móviles que escuchan estos mensajes analizan su contenido para decidir si se encuentran en una nueva red externa (Foreign Network) o incluso en un nuevo dominio.

• En caso de que el nodo móvil se encuentre situado en un nuevo dominio se ha producido caso de macro-movilidad. Según el modelo propuesto esto se traduce en un registro en el Home Agent (HA) utilizando el protocolo Mobile IP. En este registro se envía la dirección IP del MMA al HA que la interpretará como la nueva dirección Care-of Address del nodo móvil. Este proceso de handover inter-dominio implicará, entre otros aspectos, la obtención de una nueva dirección multicast.

• En caso de permanecer en el mismo dominio y de haber cambiado de red estamos en un caso de micro-movilidad que se traduce en un proceso de handover intra-dominio. Este se resolvería simplemente realizando una petición, por parte del agente de la Estación Base, para la incorporación al árbol multicast. A partir de ese momento la Estación Base comenzaría a recibir los paquetes destinados a ese nodo móvil.


72

• Como en el protocolo Mobile IP, el Home Agent intercepta los paquetes destinados al nodo y los envía, por medio de un túnel, a la dirección del Agente de Movilidad Multicast (MMA).

• Finalmente este agente desencapsula los paquetes y los reenvía encapsulándolos con la dirección multicast asignada al nodo móvil en cuestión.

Figura 3.3 Sistema de Movilidad utilizando Mobile IP en macro-movilidad.

La mayoría de las soluciones comentadas en el capítulo anterior,

exceptuando el Registro Regional [GUS02], se limitan a dar una visión general de la propuesta, sin abordar una descripción global y profunda del sistema de movilidad. Por el contrario en este trabajo se describe con detalle el funcionamiento del sistema. Se ha intentado realizar un sistema totalmente compatible con el protocolo Mobile IP, de manera que el Intercambio de información entre los diferentes elementos se realiza principalmente utilizando extensiones que están acorde con los trabajos desarrollados por el IETF.

Observando los pasos anteriores podemos resumir que realiza tres

fases: descubrimiento de la red actual; conexión al árbol multicast, obteniendo una nueva dirección multicast en caso necesario; y envío de datos.

Subred 1

Home Agent

Host Fuente

MMA

Subred 2 Dominio

Transmisión multicast


73

3.3.1 Descubrimiento de la red actual El descubrimiento de la red es el proceso por el cual un nodo móvil

es capaz de determinar si actualmente está conectado a su Home Network o está en una Foreign Network o si se ha movido de una red a otra o de un Dominio a otro.

El proceso es similar al ejecutado en el protocolo Mobile IP

existiendo dos mensajes para averiguar la situación en que se encuentra el nodo. El primero es Agent Advertisement enviado de forma periódica por los agentes, en forma de paquetes de difusión. El mensaje se formará extendiendo un mensaje ICMP de descubrimiento de ruta [RFC1256] con una extensión de movilidad como la descrita en el protocolo Mobile IP (Mobility Agent Advertisement Extension). Adicionalmente en este mensaje se debe indicar un identificativo de dominio y un identificativo de la subred, de forma que el nodo móvil pueda averiguar si se ha movido (o ha regresado) a su Home Network, o si ha cambiado de subred dentro de un dominio o incluso entre dominios.

Debido a que ahora las direcciones Care-of Address indicadas en el

mensaje corresponden al MMA es necesario que la Estación Base indique, en el mensaje Agent Advertisement, la red correspondiente. La solución propuesta es la de obligar a que en los mensajes aparezca la extensión ‘Prefix-Lengths Extension’. Esta extensión está definida en el protocolo Mobile IP como opcional, e indica el número de bits que forman el prefijo de la red en las direcciones indicadas en la porción ‘ICMP Router Advertisement’ del mensaje Agent Advertisement.

Con respecto a la identificación del dominio, la solución de utilizar

la dirección IP del Agente de Movilidad Multicast (MMA) que se indica en el mensaje Agent Advertisement no es una propuesta útil, pues limita las soluciones de escalabilidad que se describen en el punto 3.3.5. La opción presentada se basa en la utilización de Identificativos de Acceso a Red, NAI [RFC 2486]. La utilización del NAI en sistemas de movilidad basados en Mobile IP se describe en [RFC 2794] limitándose a un identificativo del nodo móvil. La propuesta definida aquí de asignar un NAI al dominio puede


74

observarse como una extensión al trabajo expuesto en [KHA01] donde se generaliza la utilización de identificativos NAI para nombrar Foreign y Home Agents.

El segundo tipo de mensajes se denomina Agent Solicitation y es

enviado por el nodo móvil con el único propósito de forzar a los agentes a enviar un mensaje Agent Advertisement. Esto es útil en el caso de que el nodo se mueva de forma rápida de una red a otra. Con el fin de asegurar la recepción del mensaje, por parte de los agentes correspondientes la transmisión, se puede realizar a la dirección multicast 224.0.0.11, que se corresponde, según definición en [IANA], con 'Todos los Agentes de Movilidad'. El formato de ambos mensajes puede observarse en el punto 3.5. Es importante indicar que no es necesario ningún mecanismo de autentificación en estos dos mensajes. Aún así podría emplearse los mecanismos de autentificación de la cabecera IP descritos en [RFC 2402]. Este mecanismo queda fuera de este estudio.

3.3.2 Registro en un nuevo Dominio Cuando un Nodo Móvil detecta que ha cambiado de dominio necesita realizar un nuevo registro que implicará, además de al nodo móvil, al Agente de Movilidad Multicast (MMA) del nuevo dominio, y al Home Agent del nodo móvil. Como ya se ha comentado, la arquitectura propuesta se basa en la utilización del Protocolo Mobile IP [RFC 3344] para realizar el mecanismo de macro-movilidad. Por tanto, la entrada del nodo móvil en un nuevo dominio va a ocasionar, además de los procesos necesarios para poder gestionar la micro-movilidad, el registro de una dirección Care-of Address en el Home Agent del nodo, siguiendo completamente el protocolo Mobile IP.


75

El proceso comienza al detectar que se ha producido un cambio de dominio según el procedimiento explicado anteriormente. En este punto el nodo necesita obtener una dirección multicast que utilizará durante toda su estancia en el dominio, así como realizar un registro de la Care-of Address en su Home Agent. En la figura 3.4 se muestra este proceso que se describe a continuación.

Figura 3.4 Registro del nodo móvil en el Agente de Movilidad Multicast.

Con el fin de mantener la compatibilidad con el protocolo Mobile IP el mensaje empleado por el MN (Nodo móvil) va a ser similar al denominado Registration Request. Este mensaje tiene como destino final el Home Agent, pues se utiliza para registrar la dirección del Agente de Movilidad Multicast (MMA) como dirección Care-of Address del nodo móvil. Puesto que el nodo móvil no cambia de MMA mientras se mueve por diferentes estaciones Base (BS) dentro de un dominio (micro-movilidad), no será necesario informar a su Home Agent de estos futuros movimientos. El mensaje Registration Request es enviado a la dirección IP de la Estación Base que el nodo móvil ha obtenido del paquete ICMP de los mensajes Agent Advertisement explicados anteriormente. Esta estación

MN BS MMA HA


Reg. Req. con extensiones Registration Request

Registration Reply

Reg. Reply con extensiones

Registration Reply


76

insertará una entrada en una lista que contiene todos los móviles que actualmente se encuentran en su área de cobertura. Esta lista incluye, además de la dirección IP permanente del nodo móvil y de los parámetros ya especificados en el protocolo Mobile IP (dirección MAC del nodo móvil, puerto UDP fuente del Registro, campo de Identificación, y un temporizador que indica la validez de la entrada), la dirección IP del MMA, y la dirección multicast que se le ha asignado al nodo móvil y que se obtendrá posteriormente en un mensaje de respuesta. La estación base debe reenviar el mensaje de registro hacia el Agente de Movilidad Multicast (MMA) indicado en el mensaje de registro. Con el fin de no inutilizar el mecanismo de autentificación del registro (Mobile-Home Authentication Extension [RFC 3344]) la Estación Base no puede modificar ningún campo del mensaje recibido. Para que el MMA pueda almacenar la Estación Base en la que actualmente está el nodo, el mensaje es enviado con una extensión que identifica la estación Base [KHA01]. Esta extensión debe ser añadida detrás de todas las extensiones que lleva incluidas el mensaje de Registro cuando se recibe por la estación base, y debería ir protegida por un mensaje de autentificación FA-FA [RFC 3012]. Los aspectos relativos a la seguridad se abordan en el punto 3.4.2 Este modo de funcionamiento es completamente compatible con el sistema de movilidad original. Si la estación base recibe un mensaje de registro con el campo Care-of Address relleno con su propia dirección, ésta envía el registro directamente al Home Agent. De esta manera la BS está funcionando como un Foreign Agent original, sin implementar el sistema de micro-movilidad multicast presentado en este punto.

Al recibir el mensaje, el Agente de Movilidad Multicast se encarga de reenviarlo al Home Agent, apoyándose en el hecho de que la dirección del mismo viene indicada en el mensaje Registration Request. Cualquier extensión incorporada por la Estación Base es eliminada por el Agente de Movilidad (figura 3.4). Así, el mensaje de registro que envió el nodo móvil llega sin alteración al Home Agent que lo autentificará utilizando la extensión de autentificación MN-HA.


77

El MMA añade una entrada a la lista de nodos móviles que tiene a su cargo. Cada entrada indica la dirección IP permanente del nodo, la dirección del Home Agent, el identificador de la Estación Base que ha enviado la solicitud de registro, un temporizador que indica la validez de la entrada, y la dirección multicast que se le asigna al nodo móvil.

El Home Agent procesa el mensaje de registro de la misma manera

que lo hace con los mensajes que se envían según [RFC 3344]. Este proceso consiste en el envío de un mensaje de Registration Reply hacia la dirección Care-of Address que en este caso se corresponde con la dirección del Agente de movilidad MMA. Como en el protocolo original este mensaje contiene un campo donde se introduce un código para informar al nodo móvil del estado de su solicitud.

Al recibir esta contestación, el Agente de Movilidad Multicast asigna

una dirección multicast al nodo móvil de las que se encuentran libres. La asignación puede realizarse, bien porque el propio MMA dispone de un servidor de direcciones multicast para asignar o bien conectándose, por cualquier mecanismo, a un servidor de direcciones.

El mensaje Request Reply es reenviado a la Estación Base

correspondiente añadiendo al final una nueva extensión que contiene la dirección asignada y que denominamos Multicast Address Extensión (MAE). Para realizar un protocolo totalmente compatible con el estándar se ha optado por desarrollar esta extensión según las estructuras de extensión descritas en [RFC 3344]. En particular se ha seleccionado el formato de extensión corto y se describe con detalle en el punto 3.5.2 Para asegurar la autenticidad el mensaje debería ir terminado por una extensión de autenticidad FA-FA. La recepción del mensaje provoca que la estación base se una al grupo multicast indicando en la extensión MAE. El estudio de la tecnología empleada a la hora de implementar el árbol multicast se realiza en el punto 3.6

Para finalizar el mensaje de respuesta es entregado por la Estación

Base al nodo móvil adjuntando la dirección multicast asignada al mismo.


78

Esto se realiza utilizando la extensión MAE y autentificándola, punto 3.4.2, con una extensión MN-FA. Actualización de las tablas. Siguiendo el modelo del protocolo Mobile IP, el registro realizado tanto en el Home Agent como en la Estación Base y el Agente de Movilidad Multicast (MMA) (que actúan como Foreign Agents del modelo original) tiene un tiempo de vida limitado que está especificado en el campo ‘Lifetime’ del mensaje de registro. Esto provoca que aún cuando el nodo móvil no modifique su situación tenga que re-registrarse antes de que este tiempo venza. El mecanismo de re-registro no difiere en nada del mecanismo de registro explicado anteriormente. El nodo móvil envía el mensaje de registro que alcanzará el Home Agent vía MMA. Este agente detecta en la tabla que contiene la lista de los nodos que el originario del mensaje ya existe por lo que no le asigna una dirección multicast nueva. Al recibir el mensaje de registro todos los elementos implicados (Estación Base, MMA y Home Agent) actualizan su entrada del temporizador correspondiente al nodo móvil.

3.3.3 Registro en una nueva BS dentro del Dominio Según el procedimiento explicado en el punto 3.3.1 el nodo móvil es capaz de detectar que se ha producido un cambio de estación base. Cuando este cambio implica además un cambio de dominio estamos en un handover Inter-domino, y se resuelve como se ha explicado en el punto 3.3.2. En caso contrario se trata de un handover intra-dominio que no debe implicar al Home Agent. En este segundo caso el nodo móvil envía un nuevo mensaje, que hemos denominado Intra-Domain Registration Request, hacia la nueva Estación Base. Este mensaje contiene la dirección multicast utilizada por


79

el móvil, la dirección de la estación base anterior y la dirección del MMA con el que se realizó el registro. La recepción de un mensaje de este tipo por parte de la Estación Base provoca que la misma se conecte al árbol multicast que corresponde al nodo móvil (figura 3.5). Típicamente el proceso se realiza utilizando mensajes ‘Join’, aunque el mecanismo exacto depende del protocolo de enrutamiento multicast empleado (punto 3.6). Una vez la Estación Base ha recibido una confirmación positiva de la incorporación al árbol, vía ‘Ack Join’, se lo comunicará al nodo por medio de un mensaje que hemos denominado Intra-Domain Registration Reply. Este intercambio de mensajes entre el nodo móvil y la estación base deberían ser autentificados por medio de una nueva extensión de seguridad MH-FA. La opción seleccionada para poder realizar esta autentificación es que el Home Agent del nodo genere inicialmente una llave de registro, por ejemplo utilizando [PER02], y que ésta sea distribuida entre el nodo móvil y las estaciones base del dominio.

Figura 3.5 Handover Intra-dominio.

1 4

2 3

Agente de Movilidad Multicast (MMA) Router

Estación Base (BS)

Nodo móvil (MN)

(1) Intra-Domanin Registration Request

(2) Multicast Join

(3) Multicast Ack Join

(4) Intra-Domain Registration Reply


80

Es importante destacar como el proceso de handover se ha limitado a la incorporación de la nueva estación base al árbol multicast, afectado sólo hasta el primer router común en la ruta hacia el núcleo (Rendezvous Point en el protocolo PIM-SM [RFC 2362]). Como se detallará posteriormente este proceso es sensiblemente más rápido que realizar un nuevo registro en el Home Agent como indica el protocolo Mobile IP original o utilizar la solución del Registro Regional (Work in Progress) [GUS02]. Existen diversas soluciones posibles a la hora de realizar este handover intra-dominio. El principal elemento diferenciador es si una vez comenzado la comunicación del nodo con la nueva estación base se pierde el contacto con la estación base antigua o no.

El primer caso se denomina ‘handover abrupto’ (Hard Handover). Se han propuesto distintas soluciones para lograr minimizar la pérdida de información en este tipo de handovers. Un ejemplo es el propuesto en [PER01] (Work in Progress) donde la estación base antigua, previa indicación de la nueva, le envía los paquetes que tiene en la cola dirigidos al nodo móvil.

El segundo caso se denominado en la literatura ‘handover blando’

(Soft Handover) y permite la comunicación con las dos estaciones. La utilización de la tecnología multicast en este tipo de handovers permite soluciones de registro avanzado [LEO99], [MYS97] que eliminan la pérdida de paquetes durante el proceso.

El estudio de las diversas soluciones de implementación del

handover en el sistema propuesto se presenta en el capítulo 6. En el capítulo 7 se realiza, además, un estudio de las prestaciones.

3.3.4 Transmisión y Recepción de datos La transmisión de datos hacia el nodo móvil puede realizarse una

vez se ha realizado el registro de la nueva dirección Care-of Address en el


81

Home Agent, como se ha explicado en el punto 3.3.2. Como en el protocolo Mobile IP, el Home Agent realizará una encapsulación de los datos que captura dirigidos hacia el nodo móvil enviándolos hacia la dirección registrada. Para ello, el Home Agent interceptará cualquier datagrama en su red dirigido hacia el nodo móvil utilizando, por ejemplo funcionando como Proxy ARP. El método de encapsulación seleccionado depende del Home Agent pudiendo elegir entre encapsulación IP en IP [RFC 2003], encapsulación mínima [RFC 2004] o encapsulación GRE [RFC 1701].

Como se ha estudiado anteriormente los paquetes son

encapsulados hacia la dirección IP de un Agente de Movilidad Multicast (MMA) de un dominio. Este agente, al recibir el datagrama, debe desencapsularlo y comparar la dirección IP destino del datagrama interior con las direcciones IP de la lista de nodos móviles visitantes del dominio. Una vez encontrada lo encapsula hacia la dirección multicast asignada al nodo y lo envía al árbol multicast. En caso de que la dirección del datagrama no estuviera en su lista debe descartarlo, puesto que otras opciones, como enrutarlo a la dirección destino (Home Address del nodo), ocasionarían bucles en la red.

Finalmente las estaciones base que están conectadas al árbol

multicast en ese momento recibirían los datagramas y tras desencapsularlos los enviarían al nodo móvil, utilizando para ello la dirección MAC que han almacenado desde el envío del mensaje ‘Registration Request’. En la figura 3.6 se puede apreciar este proceso.

Con respecto a la transmisión de datos desde el nodo móvil, éste selecciona la Estación Base como su router de salida. La dirección MAC del mismo la aprende de los mensajes ‘Advertisement’ recibidos. Es importante destacar que, como se justifica en [RFC 3344], en ningún momento el Nodo Móvil puede utilizar paquetes ARP para encontrar la dirección MAC de otro nodo de Internet.


82

Figura 3.6 Transmisión de datos hacia el Nodo móvil.

La Estación Base tiene la obligación de enrutar, al menos, los

paquetes de los nodos que ha registrado (bien por medio de un ‘Registration Request’ o bien por un ‘Intra-Domanin Registration Request’). Esto significa que como mínimo deberá verificar la campo de control de errores (‘Checksum’) de la cabecera IP, decrementar el campo ‘Tiempo de Vida’, recalcular el campo de la cabecera y dirigir los datagramas al siguiente router.

Algunos routers en redes TCP/IP pueden utilizar políticas de

seguridad como ‘filtrado a la entrada’ que descartan los paquetes cuya dirección IP fuente no coincide con la topología de la red [RFC 2827]. Es decir, los routers descartan los paquetes cuyo prefijo de red de la dirección IP fuente no coincide con ninguno de los prefijos de las redes que existen en dirección al enlace por el que se ha recibido el paquete.

Este mecanismo de seguridad es un problema en entornos basados

en Mobile IP, puesto que los paquetes enviados por el nodo móvil tendrán como dirección IP fuente su dirección permanente. Dentro de un dominio es de suponer que no existe ningún problema, pues el operador del

H.A

Host

MMA

M.H

Subred BS

(1)

(2)(3)

(4)

(1). Transmisión del datagrama original. (2). Transmisión del datagrama encapsulado. Dirección IP destino es MMA. (3). Transmisión encapsulada. La dirección destino es la dirección multicast asignada al M.H. (4). Transmisión del datagrama original en la red. La dirección física destino es la del M.H.


83

dominio simplemente no debe activar este tipo de mecanismo en su red. Sin embargo una vez los paquetes abandonan el dominio puede que sean rechazados por alguno de los routers que atraviesa. Para solucionar el problema es necesario utilizar ‘Reverse Tunneling’ [RFC 3024]. Específicamente lo que se hace es que el router de salida del dominio, típicamente un Agente de Movilidad Multicast MMA (aunque no necesariamente) realiza un encapsulado del datagrama de manera que la dirección IP fuente sea ahora la suya y la dirección destino la del Home Agent. Con esta solución los paquetes podrán atravesar perfectamente la red, aunque ahora el problema del encaminamiento en triángulo también ocurre en la transmisión desde el MH.

3.3.5 Escalabilidad La guía de conducta de IETF [RFC 3184] indica refiriéndose a la

escalabilidad: “La escalabilidad es el último problema. Muchas ideas abordables en entornos pequeños fallan este test crucial”. El desarrollo de este protocolo de micro-movilidad no ha sido ajeno a este problema, diferenciándose la mayoría de los sistemas de micro-movilidad presentes en la bibliografía (punto 2.4). Solo el sistema TeleMIP [DAS00] comentado en el punto 2.4.3 ofrece una solución escalable.

Podemos distinguir tres tipos de escalabilidad [EAR02]:

• Escalabilidad geográfica: Relativo al área que abarca la red. En la arquitectura propuesta se refiere a la extensión geográfica que puede abarcar un dominio.

• Escalabilidad de capacidad: Relativo a la capacidad de la red para soportar un volumen alto de tráfico.

• Escalabilidad de terminales: Indica la capacidad de la red para soportar muchos dispositivos. En nuestro sistema se refiere al número de nodos móviles que pueden tener servicio simultáneamente dentro en un dominio.


84

Respecto a la escalabilidad geográfica no existe ninguna limitación ni en la arquitectura ni en el protocolo presentado. La separación en dominios puede deberse tanto a criterios administrativos como a criterios meramente geográficos, pudiendo abarcar desde un campus universitario hasta una ciudad entera.

Tampoco existe ninguna limitación en cuanto a la capacidad del

sistema pues depende únicamente de la tecnología a emplear. La mayoría de las redes móviles tienen la limitación en el ‘entorno radio’, en particular en el ancho de banda que puede ofrecer, que queda fuera de este estudio. En cuanto a la infraestructura fija, la capacidad dependerá de la tecnología de los equipos empleados.

El aspecto más importante sería la capacidad del dominio para

soportar un número creciente de usuarios. Estudiando la arquitectura propuesta se puede observar como existen dos aspectos que pueden limitar la escalabilidad:

• Direcciones multicast disponibles

• Sobrecarga del Agente de Movilidad Multicast. La asignación de direcciones multicast presentaba un problema en

sistemas de movilidad multicast globales, en las que cada nodo móvil necesitaba una dirección multicast única [MYS98]. Sin embargo en el sistema presentado este aspecto pierde casi toda su importancia, pues las direcciones multicast son locales y, por tanto, son reutilizadas en cada dominio. El direccionamiento IP dispone de 282 direcciones multicast (clase D), la mayoría de las cuales son libres [IANA]. Por ejemplo, el rango comprendido entre la dirección 238.0.0.0 hasta la dirección 238.255.255.255 (238/8) está actualmente libre y ofrece más de 16 millones de direcciones. Además, en el caso de emplear tecnología SSM (Source-Specific Multicast) (ver punto 3.6), las direcciones multicast pueden ser utilizadas simultáneamente por todos los MMA.


85

El aspecto más problemático del sistema propuesto es la sobrecarga del MMA, puesto que en un principio es el encargado de realizar todas las asignaciones de direcciones multicast, realizar la desencapsulación de los datos dirigidos a todos los nodos móviles y una nueva encapsulación con la dirección multicast asignada, y en general realizar todas las funciones que el protocolo Mobile IP asigna a los Foreign Agents. Para solucionar este problema se ha prestado un especial interés en permitir la coexistencia de más de un Agente de Movilidad Multicast en un mismo dominio.

Las Estaciones Base indican, en el mensaje ‘Agent Advertisement’,

la dirección IP del MMA que se ofrece como Care-of Address. La elección del MMA ofrecido se debería realizar utilizando algoritmos para equilibrar la carga de gestión entre todos los MMA existentes. Esta elección se realiza localmente en cada Estación Base a partir de la información recibida de los diferentes MMA. Para ello los MMA podrían enviar, de forma periódica, mensajes sobre su estado a la dirección multicast 224.0.0.11 ('Todos los Agentes de Movilidad' según [IANA]). La autenticidad de estos mensajes estaría garantizada pues las diferentes Estaciones Base y el MMA comparten un contexto de seguridad (punto 3.4).

Desde el punto de vista del Nodo Móvil la asignación a un MMA o a

otro es irrelevante, aunque se mantiene constante durante toda la estancia del nodo en el dominio. Así cuando el nodo debe renovar su registro con su Home Agent envía un mensaje de registro indicando la dirección Care-of Address que está utilizando, independientemente de la que está enviando la Estación Base que controla la red donde está situado en ese momento.

Por último indicar que cuando un nodo móvil cambia de red puede

recibir mensajes de anuncio ‘Agent Advertisement’ anunciando otro MMA. En el caso de que sólo existiera un MMA por dominio, esto indicaría que se ha producido un cambio de dominio y por tanto que estamos en un handover Inter-dominio. Sin embargo ahora es posible recibir mensajes anunciando otros MMA y sin embargo permanecer en el mismo dominio. Para que el nodo móvil sepa si debe realizar un handover intra o inter


86

dominio los mensajes de anuncio incorporan una extensión de indicador de dominio.

3.4 ASPECTOS RELATIVOS A LA SEGURIDAD EN EL SISTEMA DE MICROMOVILIDAD PRESENTADO

3.4.1 Introducción a la seguridad en entornos móviles Como se comentó en el punto 2.3.5 los sistemas que permiten la movilidad de los nodos son particularmente vulnerables a escuchas y otros ataques. Un ejemplo de la vulnerabilidad puede verse estudiando el protocolo Mobile IP en su etapa de registro. En este caso un registro falso por parte de un atacante se traduciría en que el Home Agent registrará una dirección Care-of falsa, y que enviará todos los datos a ella en vez de a la original. Para evitar estos problemas es necesario que los sistemas móviles incorporen mecanismos de ‘autentificación’, que consiste en un proceso por el cual el nodo transmisor asegura su identidad al nodo que recibe. En el protocolo Mobile IP todos los elementos que forman el sistema incorporan mecanismos para realizar autentificación de los mensajes intercambiados. En este protocolo, el mecanismo de seguridad por defecto es HMAC-MD5 [RFC 2104] con una llave de 128 bits distribuida manualmente. Opcionalmente, también se permiten otros algoritmos de autentificación, tamaño de claves, o mecanismos de distribución de las mismas con el fin de aumentar la seguridad. Dos elementos del sistema que quieren autentificar los mensajes que se intercambian establecen una asociación segura utilizando uno o más contextos de seguridad disponibles. Cada contexto de seguridad incluye una clave secreta y un algoritmo de autentificación.


87

Como se estudió en 2.3.5 el protocolo Mobile IP define una serie de extensiones de autentificación con el fin de autentificar los mensajes de registro y de respuesta de registro. Ambos mensajes incorporan, obligatoriamente, una extensión de autentificación Mobile-Home al final del mismo, que permite al otro extremo asegurar la autoría del mensaje. Un campo dentro de esta cabecera denominado SPI (Security Parameter Index) indica el contexto de seguridad a emplear.

Existen, además, dos extensiones de autentificación adicionales

(Mobile-Foreign y Foreign-Home), cuyo uso no es obligatorio. El principal impedimento para la utilización de estas extensiones de autentificación es la necesidad de que exista, previamente, una asociación segura entre los elementos que quieren comunicarse. El estándar original indica que por defecto el intercambio de claves se realiza de forma manual. Esto es factible para la autentificación entre el nodo móvil y su Home Agent pero no lo es cuando se trata de realizar entre los nodos y todos los Foreign Agents que pueden visitar. Como se comenta a continuación, en la actualidad se está trabajando estandarizar mecanismos de intercambio de claves utilizando servidores AAA (Authentication, Autorization, Accounting).

3.4.2 Seguridad en el Sistema de Micro-movilidad Multicast Los problemas de seguridad que existían en el protocolo Mobile IP, y

que han llevado a la utilización de extensiones de autentificación en el proceso de registro, se manifiestan en mayor medida en el sistema de micro-movilidad multicast propuesto.

Una fuente de problemas es el registro del nodo móvil al entrar en

un nuevo dominio. Una vez el Home Agent ha recibido el mensaje de registro contesta con un mensaje de respuesta autentificado con la extensión de autentificación Mobile-Home ya comentada. El MMA recibe este mensaje de respuesta de registro que envía hacia la Estación Base (punto 3.3.2) añadiendo una nueva extensión que contiene la dirección multicast asignada (Multicast Address Extensión, MAE). Para asegurar la


88

autenticidad de esta extensión el mensaje se termina con una extensión de autenticidad FA-FA. Esta extensión de seguridad no existe en el protocolo Mobile IP, pero ha sido ya definida y utilizada en [GUS02]. En un principio esto no es problemático pues las estaciones base y los MMA forman un sistema estable en el tiempo, donde no es difícil establecer una asociación segura de forma permanente.

Figura 3.7 Registro del nodo mostrando las extensiones de autentificación.

El problema aparece cuando la Estación Base debe transmitir el

mensaje de respuesta de registro al nodo móvil, adjuntando la extensión MAE para que el nodo conozca la dirección multicast asignada. El mensaje debería, según Mobile IP, terminado con una extensión de autentificación Mobile-Foreign para lo que es necesario que exista una asociación segura

MN BS MMA HA

(1) (2) (3)

(4) (5)

(6)

Reg.Request Ext. Aut. MN-HA

Reg.Request Ext. Aut. MN-HA Base Station. NAI


Reg.Reply Ext. Aut. MN-HA

Reg.Reply Ext. Aut. MN-HA MAE Ext. Aut. FA-FA

Reg.Reply Ext. Aut. MN-HA MAE Ext. Aut. MN-FA

(1)

(2)

(3)

(4)

(5)

(6)

Ext. Aut. FA-FA


89

entre el nodo móvil y la Estación Base correspondiente. En la figura 3.7 se muestra este proceso.

Existe una solución para no necesitar las asociaciones entre el

nodo móvil y las Estaciones Base. El MMA podría enviar la petición del registro del nodo móvil (Registration Request) hacia el Home Agent anexando la extensión MAE (Multicast Address Extensión). Esta extensión va autentificada con una extensión de autenticidad Foreign-Home. El Home Agent se modifica para que entienda la extensión MAE de manera que la incorpore en el mensaje de respuesta (Registration Reply). Evidentemente esta extensión estará autentificada con la extensión Mobile-Home que obligatoriamente incorpora el Home Agent al final del mensaje, y por ello podrá llegar hasta el nodo móvil sin la necesidad de la autentificación Mobile-Foreign. En la figura 3.8 se muestran las modificaciones realizadas.

El proceso ha sustituido la necesidad de establecer asociaciones

seguras entre todos los nodos y todas las estaciones base a cambio de la existencia de una asociación segura entre el MMA y el Home Agent. Sin embargo, como se detalla a continuación, existen otros problemas asociados al sistema de micro-movilidad que hacen necesario la existencia de las asociaciones entre el móvil y las Estaciones Base. Esto, unido a que la solución presentada obliga a la modificación del Home Agent, que ahora debería entender las extensiones MAE, hace que la solución sea desestimada de ahora en adelante.

Figura 3.8 Modificaciones propuestas al proceso de registro.




MAE

Ext. Aut. FA-HA


(3)

(4)

(5)

(6)

Ext. Aut. FA-FA

Ext. Aut. FA-HA

MAE

MAE

MAE


90

En el sistema presentado se realiza, aparte del registro al entrar en un nuevo dominio, un registro intra-dominio que no afecta al Home Agent. En esta fase la Estación Base que recibe el mensaje de registro intra-dominio debe conectarse al árbol multicast del nodo móvil (punto 3.3.3). La Estación Base debe asegurarse que el nodo móvil que solicita el registro es el nodo que realmente tiene asignada esa dirección multicast. En caso contrario se estaría transmitiendo la información al atacante, e incluso dependiendo del mecanismo de handover empleado, impedir que el nodo auténtico la recibiera. En definitiva es necesario que los mensajes Intra-Domain Registration Request, intercambiados entre el nodo móvil y la Estación Base, estén autentificados por medio de una extensión de autentificación.

La necesidad de la existencia de asociaciones de seguridad entre el

nodo móvil y otros elementos del sistema no es exclusiva del sistema presentado, al contrario, es el principal problema con el que se han encontrado los principales trabajos que han intentado superar las limitaciones del protocolo Mobile IP. Así, el mecanismo de Optimización de Ruta [PER01] que se comentó en el punto 2.3.6 necesita la existencia de una asociación segura entre el nodo móvil y todos los hosts con quién se va a comunicar. La utilización de Mobile IP con Registro Regional [GUS02], como se estudió en el punto 2.3.7, también necesita estas asociaciones seguras para poder autentificar los mensajes de registro regional. Utilización de servidores AAA. La creación de una asociación de seguridad entre dos elementos de la red conlleva la existencia de una clave conocida por ambos elementos. En el caso de la asociación entre el nodo móvil y su Home Agent, esta asociación puede configurarse de una forma manual, como se suponía en el protocolo Mobile IP. Otras asociaciones de seguridad como la de los diferentes elementos que forman un dominio (Estaciones Base y Agentes de Movilidad Multicast) también son factibles al ser permanentes. Sin embargo, la solución no es operativa cuando la asociación de seguridad es entre el nodo móvil y otros los elementos del sistema como Estaciones


91

Base, pues no sería escalable tanto geográficamente como en número de terminales (punto 3.3.5). La idea principal para solucionar el problema se encuentra actualmente en desarrollo y se basa en la utilización de servidores AAA (Authentication, Authorization, Accounting) como RADIUS [RFC 2865] o DIAMETER [CAL01]. La utilización de servidores AAA para lograr asociaciones seguras entre los diferentes elementos que forman un sistema de movilidad se describe en [RFC 2977], donde se define un modelo básico a seguir.

Según el modelo, que se presenta en la figura 3.9, en cada Dominio Administrativo existe una autoridad local (AAAL) que puede establecer comunicaciones seguras con la autoridad del nodo móvil que solicita credenciales (AAAH). Los Foreign Agents del dominio disponen, a su vez, de conexiones seguras con el AAAL del Dominio. Por tanto, los Foreign Agents solicitan al AAAL que verifique las credenciales del nodo. Esta autoridad no tiene suficiente información local para realizar la tarea pero es capaz de comunicarse con la autoridad del nodo quién realizará la verificación.

Figura 3.9. Modelo básico para la utilización de servidores AAA en Mobile IP.

Podemos adaptar el modelo general a nuestro sistema de micro-

movilidad, simplificándolo al máximo. Suponemos que el Home Agent funciona como servidor de autentificación de los nodos móviles a su cargo.

Local Domain Home Domain

AAAH AAAL

FA MN

MN: Nodo Móvil FA: Foreign Agent AAAL: Autoridad Local AAAH: Autoridad del nodo


92

Cuando recibe una solicitud de registro (‘Registration Request’), contesta incorporando al mensaje de respuesta (‘Registration Reply’) una extensión que aporta al nodo móvil información para establecer una asociación de seguridad con las Estaciones Base del Dominio donde se encuentra. Puede tomarse, como base para el diseño de la extensión, la detallada en [PER02] denominada ‘Unsolicited MN-FA Key Material From AAA’.

Es necesario, además, hacer llegar la información necesaria para

construir la asociación de seguridad a los diferentes elementos del dominio. Los trabajos que actualmente tratan de la utilización de servidores AAA en entornos de redes IP móviles dejan esto fuera de estudio, pues depende de los aspectos particulares de la infraestructura AAA utilizada. Sin embargo en la versión simplificada que se está proponiendo, donde el Home Agent actúa de servidor de autentificación, es posible realizar esta transmisión de manera sencilla.

El primer paso es suponer que existe una asociación de seguridad

entre el MMA y el Home Agent y otra entre los diferentes elementos que forman un dominio. El Home Agent incorporará, al final del mensaje de respuesta de registro, una extensión con un formato similar a la anteriormente comentada que contenga la información necesaria para la creación de la asociación de seguridad entre el nodo móvil y las Estaciones Base. Esta extensión estará autentificada por una extensión de autenticidad FA-HA. El Agente de Movilidad Multicast (MMA) elimina estas dos extensiones del final del mensaje antes de reenviarlo a la Estación Base correspondiente.

En la siguiente figura se muestra como quedaría finalmente el

registro que se describió anteriormente en la figura 3.7. Es interesante observar como se ha vuelto a incorporar material para que la Estación Base que tiene conectado en ese momento al nodo móvil pueda crear de la asociación de seguridad con el nodo.

Adicionalmente es necesario que el MMA envíe un nuevo mensaje a

todos los elementos del dominio con esta información, de manera que a partir de ese momento el nodo móvil pueda realizar registros intra-dominio


93

comunicándose con las demás Estaciones Base de una forma autentificada.

Figura 3.10 Proceso de registro con transmisión de material para la creación de

asociaciones de seguridad MN-FA.

Es importante destacar que la solución aquí mostrada es una

versión simplificada de los mecanismos de autentificación utilizando servidores AAA. Los problemas que se han presentado en el sistema de micro-movilidad propuesto no difieren de los que han aparecido en otras variaciones del protocolo Mobile IP, o incluso en el mismo protocolo, donde tan solo proponen la distribución manual de claves. Esto significa que cualquier solución que actualmente se encuentra bajo estudio será utilizable en el sistema de micro-movilidad.

MN BS MMA HA

(1)

(2) (3)

(4) (5)

(6)

Reg.Reply Key M. MN-FA

Reg.Reply MAE FA-FA

Reg.Reply MAE Ext. MN-FA

(4)

(5)

(6)

Ext. MN-HA Key Mat. MN-FA Ext. FA-HA

Key M. MN-FA Ext. MN-HA Key M. MN-FA

Key M. MN-FA Ext. MN-HA


94

3.5 FORMATO DE LOS MENSAJES

Como se ha explicado anteriormente, el sistema de micro-movilidad multicast se ha desarrollado siguiendo las directrices de diseño establecidas por el protocolo Mobile IP (MIP), [RFC 3344]. De esta manera ha sido posible utilizar este protocolo para realizar la macro-movilidad de una forma fluida y transparente para el nodo móvil. En este punto se va a mostrar los nuevos mensajes y las extensiones desarrolladas.

3.5.1 Mensajes para el descubrimiento de la red

En el punto 3.3.1 se indicó la utilización de un mensaje Agent Advertisement que es enviado de forma periódica por las Estaciones Base para indicar su presencia.

El mensaje es similar al definido por Mobile IP, utilizando un

paquete ICMP Router Discovery [RFC 1256] con una extensión de movilidad denominada en [RFC 3344] como ‘Mobility Agent Advertisement’. El único cambio realizado ha sido la incorporación de un flag que denominamos ‘X’. En la figura 3.11 podemos observar como ha sido introducido después de los definidos en [RFC 3344], [RFC 3024], [PER01] y [GUS02]. El flag se utiliza para indicar al nodo móvil que el dominio soporta el sistema de micro-movilidad multicast.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo Longitud Número de secuencia

Tiempo de vida R B H F M G R T S I X Reserv.

Dirección de la Estación Base.

Care-of Address (Dirección del MMA )

...................................

Figura 3.11 Extensión ‘Mobility Agent Advertisement’.


95

La extensión anterior va seguida, obligatoriamente, por una extensión de prefijo de red definida en [RFC 3344], que se utilizará, junto con la dirección del Agente de la Estación Base, para que el móvil sepa si ha cambiado de subred o no.

Es importante comentar que se ha introducido la dirección de la

Estación Base como primera dirección Care-of Address. El motivo de esto es la compatibilidad. Una de los cambios que se produjo entre el estándar de Mobile IP original [RFC 2002] y el actual fue el de indicar que los nodos móviles deberían tomar como Care-of Address la primera de la lista. De esta manera si un nodo móvil no soporta el sistema de micro-movilidad propuesto tomaría como Care-of Address, la dirección de la Estación Base. En esta situación la Estación Base actuaría como un Foreign Agent tradicional. Si el nodo soporta el sistema propuesto sabe que la dirección que debe tomar como Care-of Address es la segunda que se corresponde con el MMA asignado.

El mensaje irá finalizado por una extensión que denominamos

‘Domain NAI Extension’. Esta extensión ha sido creada a partir de la extensión NAI Generalizada (NAI, Generalized Network Access Identifier) expuesta en [KHA01]. A la extensión, que se muestra en la figura 3.12, le podríamos asignar el valor de subtipo 5, que en la actualidad se encuentra libre, o cualquier otro valor asignado por la IANA.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo Longitud Subtipo =5 NAI.......

Figura 3.12 Extensión ‘Domain NAI’.

El segundo tipo de mensaje que se utiliza en el descubrimiento de la red es el denominada ‘Agent Solicitation’, y es idéntico al expuesto en el protocolo original [RFC 3344].


96

3.5.2 Mensajes en el registro en un nuevo Dominio Registration Request El proceso de registro en un nuevo dominio se realiza utilizando un mecanismo totalmente compatible con el protocolo Mobile IP. Así, el mensaje ‘Registration Request’ que el nodo envía a la Estación Base es el mismo que el definido en [RFC 3344], incluyendo la extensión de autentificación obligatoria MN-HA. La estación Base lo reenvía al Agente de Movilidad Multicast que viene definido por dirección Care-of Address elegida por el Nodo Móvil. Como se explicó en el punto 3.3.2, la Estación Base añade al mensaje de registro una extensión de identificación de la estación base que está definida en [KHA01] y que se denomina ‘FA NAI’. Esta extensión vendrá autentificada por una extensión de autentificación FA-FA. La extensión de autentificación comentada no viene definida en el estándar original [RFC 3344]. Sin embargo en [RFC 3012] se define un formato general para la creación de extensiones de autentificación. En particular la extensión FA-FA ya ha sido utilizada en [GUS02] de manera que el valor del campo ‘Subtipo’ sería el asignado por la IANA. En la figura 3.13 se observa esta extensión.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo = 36 Subtipo Longitud

SPI

Autentificador.........

Figura 3.13 Extensión de autentificación FA-FA.

Registration Reply. Una vez el Home Agent registra la nueva dirección envía un mensaje ‘Registration Reply’ idéntico al definido en [RFC 3344]. Dicho mensaje es autentificado con la extensión obligatoria MN-HA. El Agente


97

MMA reenvía el mensaje a la Estación Base correspondiente añadiendo una nueva extensión que denominamos ‘Multicast Address Extensión’ (MAE), que irá autentificada por una extensión de autentificación FA-FA como la explicada anteriormente. La extensión MAE se muestra en la figura 3.14, y ha sido diseñada según las estructuras de extensión descritas en [RFC 3344]. En particular se ha seleccionado el formato de extensión corto. El campo ‘Tipo’ tomaría el valor asignado por la IANA. El campo ‘Longitud’ toma el valor 5 y el campo ‘subtipo’ no es necesario, tomando por tanto el valor 0.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo Longitud = 5 Subtipo = 0 Reservado

Dirección Multicast Asignada

Figura 3.14 Extensión de Dirección Multicast, MAE.

Finalmente la Estación Base reenvía el mensaje al nodo móvil eliminando la extensión de autentificación FA-FA y añadiendo una extensión de autentificación MN-FA definida en [RFC 3344]. Cuestiones relativas a la seguridad. En el punto 3.4.2 se estudió el problema de la creación de una asociación de seguridad entre el nodo móvil y la Estación Base. La solución ofrecida se basaba en el empleo de extensiones al mensaje de respuesta de registro, con el fin de proporcionar el material necesario para poder establecer dicha asociación. A continuación se presenta el formato propuesto para estas extensiones. Es importante destacar que ésta es una posible solución para el establecimiento de una asociación entre el nodo y las Estaciones Base, y que no se descartan otras soluciones. Por este motivo se ha preferido mostrar la solución por separado, en lugar de integrarlo en la explicación anterior del proceso de registro.


98

La extensión presentada se basa, ligeramente, en las ideas propuestas en [PER02], y se muestra en la figura 3.15. El campo tipo estaría definido por la IANA, al igual que el campo ‘Subtipo’ que se utiliza para diferenciar las diferentes extensiones que se utilizan para el establecimiento de asociaciones seguras (figura 3.10).

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo Subtipo Longitud

Tiempo de Vida

SPI a emplear

SPI resultante

Identificador de Algoritmo Material para clave.................

Figura 3.15. Extensión para el envío de información para la generación de

asociaciones seguras.

El ‘SPI (Security Parameters Index) resultante’ es el SPI de la

asociación entre el nodo móvil y la Estación Base que se crea como resultado del proceso. De igual manera el Identificador de algoritmo será el algoritmo que se empleará en la asociación resultante.

Sin embargo, el campo ‘SPI a emplear’ varía en función de los

elementos entre los que se intercambia el material.

• En la extensión que se utiliza para enviar el material hasta el nodo móvil (ver figura 3.10), el ‘SPI a emplear’ sería el HA SPI, que indica el SPI de la asociación de seguridad que mantiene con el Home Agent, y que el que el nodo móvil debe usar para determinar el algoritmo con el que establecer la asociación con la Estación Base.

• En la extensión utilizada para enviar el material desde el Home Agent hasta el MMA, este valor indica el SPI de la asociación de seguridad que mantienen Home Agent y MMA, y que el que al MMA debe usar para determinar el algoritmo con el que obtener el material que se transmite.


99

• Finalmente, en la extensión utilizada para enviar el material desde el MMA hasta la estación base, este valor indica el SPI de la asociación de seguridad que mantienen el MMA con las estaciones, y que se debe usar para determinar el algoritmo con el que obtener el material para establecer la asociación de seguridad con el nodo.

3.5.3 Mensajes para el registro Intra-Dominio Como se estudió en el punto 3.3.3, cuando un nodo detecta que se ha producido un cambio de subred dentro de un dominio envía un nuevo mensaje que se ha denominado ‘Intra-Domain Registration Request’. Este mensaje sustituye al tradicional mensaje de registro con el Home Agent que no debe ser utilizado.

En la figura 3.16 se observa el formato propuesto para este mensaje. Los primeros 32 bits (la primera fila de la figura) son idénticos al mensaje ‘Registration Request’ de [RFC 3344]. El valor del campo tipo debe ser asignado por la IANA. Las tres direcciones que aparecen en los siguientes campos son las necesarias para crear una tabla con la misma información que la explicada en el punto 3.3.2. Utilizando la dirección Multicast, la estación Base se conectará al árbol correspondiente. Por último el campo ‘Identificador’ se utiliza como mecanismo de seguridad para asociar peticiones de registro con respuestas. Su uso se detalla en [RFC 3344].

El mensaje ‘Intra-Domain Registration Request’ debe ir finalizado por

una extensión de autentificación MN-FA también definida en el estándar original.


100

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo S B D M G r T x Tiempo de vida

Home Address

Care-of Address

Dirección Multicast

Identificador

Extensiones................

Figura 3.16 Formato del mensaje ‘Intra-Domain Registration Request’.

Una vez la Estación Base se ha conectado al árbol multicast se lo comunica al nodo móvil por medio de un mensaje ‘Intra-Domain Registration Reply’. El mensaje se muestra en la figura 3.17. El campo ‘Tipo’ tomará el valor asignado por la IANA a este tipo de mensaje. El campo ‘Código’ informará del éxito o error en la conexión de la Estación Base al árbol multicast. Como en el caso anterior, este mensaje debe ir acabado por una extensión de seguridad MN-FA definida en [RFC 3344].

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo Código Tiempo de vida

Home Address

Multicast Address

Identificador


Figura 3.17 Formato del mensaje ‘Intra-Domain Registration Reply’.


101

3.5.4 Otros mensajes no detallados En el punto 3.3.5 se describió como los diferentes Agentes de Movilidad Multicast (MMA) difundían mensajes a las Estaciones Base indicando su disponibilidad. Existen múltiples posibilidades con respecto al formato de los mismos, que dependerá del tipo de información que las estaciones base empleen para la selección, en un instante de tiempo dado, de un MMA u otro. Se sugiere que los mensajes estén encapsulados en UDP y transmitidos a la dirección multicast 224.0.0.11 (‘Todos los Agentes de Movilidad’). Durante un handover Intra-Dominio, la Estación Base que recibe el mensaje ‘Intra-Domain Registration Request’ debe realizar una conexión al árbol multicast correspondiente. El formato de los mensajes que se emplean, típicamente mensajes ‘Join’ y ‘Ack Join’, dependen del protocolo de enrutamiento multicast utilizado. Este aspecto se describe con mayor detalle en el punto 3.6. Por último, en el punto 3.4.2 se estudio el concepto de seguridad en el sistema de micro-movilidad propuesto. Con el fin poder obtener una asociación segura entre los nodos móviles y las estaciones base se relató una simplificación, en la que el Home Agent realizaba la tarea de suministrar el material necesario. En el ejemplo propuesto el MMA obtenía dicha información y debía hacérsela llegar a todas las estaciones base del dominio. El mecanismo particular por el que esto se realiza no se describe. Típicamente se realizaría por medio de mensajes multicast donde se transmitiría la dirección del nodo móvil, el material necesario para poder formar la asociación segura (por ejemplo la extensión estudiada en el punto 3.5.2), y una autentificación FA-FA para autentificar el mensaje. Sin embargo los trabajos que se están desarrollando en este momento, y que se basan en la utilización de servidores AAA, dejan estos aspectos al margen, razonando que dependen de la tecnología particular empleada.


102

3.6 CONSIDERACIONES SOBRE EL USO DE TRANSMISIÓN MULTICAST EN EL SISTEMA DE MICROMOVILIDAD

3.6.1 Introducción a la transmisión multicast

El protocolo de micro-movilidad propuesto está basado en la utilización de la tecnología multicast en redes IP. Este paradigma de comunicación apareció a principios de los años 90 a partir de los trabajos realizados por Stephen Deering [DEE90], definiéndose las extensiones al protocolo IP en [RFC 1112].

La transmisión multicast permite transmitir datagramas desde una

o más fuentes a un grupo de receptores que participan en la sesión multicast utilizando un único flujo de datos, en vez de tener que reenviar la misma información de forma independiente a cada receptor. Esto se traduce en una reducción del ancho de banda total, utilizado sobre todo en las nuevas aplicaciones multimedia en las que el volumen de la información transmitida es considerable.

Se ha considerado que la tecnología multicast es una solución

idónea para entornos de micro-movilidad. Algunos de los motivos más destacables son los siguientes:

• Reducción de ancho de banda. La trasmisión multicast permite

realizar una utilización eficiente del ancho de banda al realizar una única transmisión de los datos mientras estos siguen una ruta común. Esto es importante desde el punto de vista de la escalabilidad. Otras soluciones mucho más sencillas, como realizar una inundación de los datos por el dominio, no son abordables a gran escala.

• Velocidad en el proceso de handover. El tiempo que dura el proceso de handover es un aspecto fundamental en cualquier sistema de movilidad, siendo incluso el principal motivo que ha llevado al desarrollo de propuestas de micro-movilidad. La utilización de la


103

trasmisión multicast ofrece unos tiempos de handover menores que otras soluciones propuestas. Por ejemplo, soluciones como Mobile IP con Registro Regional implican que en cada handover se obtenga una nueva dirección temporal y que se le notifique al GFA. En nuestro caso el proceso de handover se resume en conectarnos al árbol multicast del grupo utilizado. Adicionalmente, la utilización de la tecnología multicast ofrecerá la posibilidad de realizar handover sin pérdida de información de una manera simple [LEO98].

• Tecnología desarrollada. La tecnología multicast tiene una antigüedad de más de 10 años, y ha sido suficientemente estudiada. En la actualidad existen numerosos productos en el mercado que ofrecen capacidades multicast, por lo que es posible implementar dominios que soporten el sistema de micro-movilidad propuesto más fácilmente. La mayoría de los restantes sistemas de micro-movilidad (Cellular IP, Hawaii o MMP) utilizan protocolos de encaminamiento propietarios basados en encaminamiento por Host. Los routers actuales no están diseñados para este propósito, y sería necesario la actualización de los mismos.

3.6.2 Selección de la tecnología multicast a emplear La tecnología multicast se ha desarrollado ampliamente en los

últimos años, existiendo en la actualidad una gran variedad de algoritmos y protocolos de enrutamiento disponibles.

Para que los usuarios puedan conectarse al árbol multicast se ha

desarrollado el protocolo IGMP (Internet Group Management Protocol). La primera implementación fue publicada a mediados de 1989 [RFC1112]. Éste fue reemplazado en 1997 por la versión 2 (IGMPv2) [RFC 2236], y en la actualidad se ha presentado una tercera versión [RFC 3376]. El protocolo permite a un host informar a la red que es miembro de un determinado grupo multicast. Así, un router designado de cada subred tendrá la tarea conectarse al árbol multicast correspondiente, utilizando


104

para ello un protocolo de encaminamiento multicast. Como se estudiará a continuación, el nodo móvil utilizará las características del protocolo IGMP para comunicarse con la Estación Base indicándole que se debe conectar al grupo multicast asignado a dicho nodo.

Tradicionalmente los protocolos de encaminamiento multicast se

han dividido en protocolos de modo denso y protocolos de modo disperso. Los protocolos de modo denso asumen que los miembros del grupo multicast están distribuidos de forma densa en la red, con muchas subredes conteniendo usuarios. Estos protocolos suelen utilizar algoritmos de “Árbol Basados en Fuente” (SRT), que forman un árbol de encaminamiento por cada fuente y que utilizan mecanismos más o menos elaborados de inundación para propagar la información hasta todos los routers. Ejemplos de estos protocolos serían DVMRP [RFC 1075], MOSPF [RFC 1584] o PIM-DM.

Por su parte los protocolos de modo disperso están pensados para

grupos multicast en los que los usuarios están distribuidos por la red. Se basan en algoritmos de árbol compartido (Shared Tree, ST) [RFC 2201] en los que existe un router central que recibe los paquetes del grupo y los reenvía hacia todo el árbol. Aquí los usuarios tienen que explícitamente unirse al grupo que deseen para comenzar a recibir los datos. Ejemplos de estos protocolos son CBT [RFC 2189] y PIM-SM [RFC 2362].

En el desarrollo del sistema de micro-movilidad se ha propuesto la

utilización de un protocolo basado en árbol compartido. Para usuarios dispersos (y en nuestro caso esto llega al extremo al existir, normalmente, solamente uno) la inundación no está justificada, puesto que la probabilidad de que los paquetes sean entregados a redes donde no existen miembros del grupo es muy elevada. Además, los protocolos de modo denso mantienen información de los grupos multicast existentes en todos los routers de la red, lo que se traduce en un consumo de recursos no justificado que puede afectar a la escalabilidad del sistema.

Los protocolos PIM-SM y CBT tienen muchas cosas en común.

Ambos están basados en la existencia de un árbol compartido que se


105

realiza de una manera independiente del protocolo unicast existente. Además comparten muchos mecanismos de procedimiento, como el modo en que se recorta el árbol compartido o las soluciones empleadas para seleccionar cual es el núcleo del árbol.

Sin embargo también existen diferencias significativas. PIM-SM

forma un árbol compartido unidireccional, por el que los datos se transmiten desde el núcleo (denominado 'Rendezvous Point’ RP) hasta los routers extremos. Las fuentes envían los datos hacia el RP mediante mensajes ‘PIM-Register’ y, posteriormente, utilizando una ruta multicast SPT (Shorted Path Tree). Además, los routers que dan conexión a los hosts adscritos al árbol multicast pueden crear una conexión con una fuente de manera que ésta forma la raíz de un SPT. Así la transmisión se realiza ahora evitando pasar por el RP, reduciendo la latencia y la posible congestión del RP.

En el protocolo CBT esto no es posible. CBT utiliza un árbol

compartido bidireccional por el que se transmiten y reciben los datos. Si la fuente no es un miembro del grupo multicast no está conectada al árbol y debe enviar los datos hasta el núcleo utilizando encapsulación IP (en la versión CBTv2), no siendo posible la optimización de rutas utilizando SPT con raíz en las fuentes.

La principal diferencia afecta al mecanismo por el que las fuentes

del grupo transmiten los datos. Como se estudia a continuación nuestro sistema de micro-movilidad utiliza unas capacidades simplificadas, donde estos aspectos no son relevantes.

El protocolo CBT lleva mucho tiempo en desarrollo. La primera

versión CBTv1 fue modificada por una segunda, CBTv2 [RFC 2189], con la que no es compatible. En la actualidad se está trabajando con una tercera versión [BALL98] que de nuevo será incompatible con las anteriores. Esto puede explicar la poca implantación que ha tenido el protocolo hasta el momento. Por contra, el protocolo PIM-SM ha tenido mucha aceptación en la industria y multitud de fabricantes como, Sprint o Cisco, ofrecen equipos que lo implementan.


106

Podemos resumir el protocolo PIM-SM muy brevemente en los siguientes puntos:

1. Es necesario definir un núcleo (también llamado ‘Rendezvous Point’ RP)

para cada grupo multicast.

2. Los routers de la red que desean incorporarse a un grupo deben descubrir que router es su nodo RP. Para realizar esto se utiliza un protocolo de iniciación (Bootstrap Protocol). Este protocolo no estaba definido en la especificación 1 del protocolo (PIM-SM v1, [RFC 2117]) y cada fabricante desarrollaba el suyo. La versión 2 incluye la especificación del protocolo de iniciación. Además de para encontrar el nodo RP, el protocolo se utiliza como mecanismo de seguridad, incluyendo mecanismos para la selección de un RP alternativo en caso de que el primario fallase. Adicionalmente algunas empresas como Cisco tienen sus propios mecanismos de descubrimiento [WILL00].

3. Los receptores envían mensajes explícitos de incorporación (‘Join Messages’) hacia el RP. Estos mensajes siguen un direccionamiento desde los receptores hacia el núcleo, por lo que, de manera similar a otros protocolos multicast, se crea un árbol multicast ‘Reverse Shortest Path Tree’ (árbol por el camino de vuelta más corto) con raíz en el RP.

4. Cada fuente envía los paquetes multicast, encapsulados en paquetes unicast (mensajes ‘PIM-Register’), hacia el nodo RP. El nodo RP desencapsula los paquetes multicast y los envía a través del árbol compartido. Además enviará un mensaje de incorporación hacia la fuente. Esto hará que los routers entre la fuente y el nodo RP se establezcan en modo de direccionamiento multicast y el nodo RP pueda a partir de entonces recibir los datos de la fuente como tráfico multicast evitando la encapsulación.

En la actualidad se está trabajando en una variación de la

tecnología multicast que se denomina Multicast con Fuente Específica (Source-Specific Multicast SSM) [BHA03],[HOL03], ambos catalogados como ‘Work in Progress’. Aquí se sustituye la idea tradicional de grupo multicast, caracterizado por una dirección G [RFC 1112], por el concepto de ‘canal’ que está definido por el par (S,G), donde G es una dirección multicast, y S


107

la dirección del host fuente. Para poder trabajar simultáneamente con la tecnología multicast existente hasta el momento [IANA] ha reservado el espacio de direcciones 232/8 (232.0.0.0 hasta 232.255.255.255) como direcciones IPv4 destino G de la tecnología SSM.

En SSM las estaciones se suscriben a canales (S,G) por medio del

protocolo IGMPv3 [RFC3376], o bien utilizando el protocolo ‘Multicast Listener Discovery, MLDv2 [VID03] si estamos trabajando en un entorno IPv6. En contraste al servicio ASM (Any-Source Multicast) definido en [RFC 1112], SSM ofrece únicamente un servicio ‘uno-a-varios’, de manera que las estaciones subscritas al canal sólo reciben paquetes transmitidos por la fuente S hacia la dirección G.

Aunque actualmente no existen protocolos específicos SSM, se

plantea como solución una simplificación del protocolo PIM-SM, como se describe en [FEN03].

El planteamiento SSM se ajusta perfectamente a los requerimientos

de multicast del sistema de micro-movilidad propuesto. Sin embargo, dado que no existen actualmente protocolos SSM específicos y que se está trabajando en simplificaciones del protocolo PIM-SM, en este trabajo nos vamos a referir a este último protocolo.

A pesar de esto, y como se verá a continuación, los requerimientos

multicast necesarios por el sistema de micro-movilidad son inferiores a las capacidades que ofrece el protocolo PIM-SM. Así cuando SSM esté más desarrollada podrá integrarse perfectamente en el sistema de micro-movilidad presentado.

Por último indicar que el sistema de micro-movilidad es totalmente

compatible con cualquier algoritmo de enrutamiento multicast y de cualquier protocolo concreto, incluidos los protocolos de modo denso como DVMRP, MOSPF o PIM-DM. La elección de uno en concreto se realiza simplemente con el fin de profundizar en el conocimiento de como los mecanismos de movilidad interactúan con los de enrutamiento multicast.


108

3.6.3 Incorporación del protocolo PIM-SM / SSM al sistema de micro-movilidad

Debido a las características del sistema de micro-movilidad

diseñado, el protocolo de enrutamiento PIM-SM / SSM puede incorporarse en nuestro sistema de una manera sencilla. El proceso comienza cuando una Estación Base recibe un mensaje de registro del nodo móvil. Si se trata de un registro intra-dominio (mensaje 'Intra-Domain Registration Request') la BS actúa como si hubiera recibido un mensaje 'IGMP Membership Report'. Esto no es ningún inconveniente pues estos mensajes sólo indican el grupo multicast al que se desea conectar, y esta información también es aportada por el mensaje de registro. En el caso de que se trate de un mensaje de registro por entrar en un nuevo dominio (mensaje 'Registration Request') se debería esperar hasta recibir el mensaje de respuesta vía MMA. Este mensaje 'Registration Reply' incorpora la extensión MAE (Multicast Address Extensión), que nos indica la dirección multicast asignada al nodo. Una vez la BS obtiene la dirección el proceso es el mismo que en el registro intra-dominio, y se supone que se ha recibido un mensaje IGMP Membership Report’.

La eliminación de la necesidad de que los nodos móviles envíen

mensajes 'IGMP Membership Report' no significa que el nodo pueda desentenderse completamente de que está utilizando una dirección multicast. El protocolo IGMPv1 especifica que los routers deben enviar periódicamente mensajes 'IGMP Query' para actualizar la tablas y asegurarse que todavía existen hosts pertenecientes al grupo multicast. Esto obliga a los nodos móviles a contestar a dichos mensajes en el caso de que fuera necesario. Sin embargo, el protocolo Mobile IP tiene un proceso similar para mantener las direcciones Care-of. Es decir, cada cierto tiempo el nodo móvil debe enviar un nuevo mensaje de registro al Home Agent para indicar que la dirección sigue siendo válida. Para la Estación Base (desde el punto de vista de ser un router multicast) ese mensaje de registro significa que existe miembros del grupo multicast, por lo que le permitiría actualizar el temporizador pudiendo evitar, o al menos minimizar, el envío de mensajes 'IGMP Query'.


109

Por último, en el capítulo 6 de esta Tesis, donde se trata con mayor profundidad el tema del handover, se estudiará el posible uso de mensajes 'IGMP Leave Group' que se incluyeron a partir de la versión 2 del protocolo [RFC 2236].

Una vez la estación base ha interpretado la recepción de un

mensaje IGMP de incorporación a un grupo multicast debe realizar una conexión al árbol compartido de dicho grupo. En nuestro sistema, el router que actúa de ‘Rendezvous Point’ será el Agente de Movilidad Multicast (MMA). Esta el la solución más sencilla, pues es este agente el que debe realizar la encapsulación de los paquetes multicast. Si propusiéramos otra opción el MMA se comportaría como una fuente multicast y, siguiendo el protocolo, debería volver a encapsular los paquetes para hacerlos llegar el RP elegido. Evidentemente esta última opción consume tiempo y recursos innecesariamente por lo que no es considerada. La tecnología SSM (Source-Specific Multicast) propone una solución idéntica para generar el árbol, pues al trabajar con una sola fuente (en nuestro caso sería el MMA), ésta actúa como raíz del árbol y se puede prescindir del RP.

Llegados a este punto, y siguiendo el protocolo PIM-SM, la Estación

Base enviará un mensaje 'PIM Join' hacia el RP (el mecanismo por el que los routers conocen cual es RP asignado a un grupo multicast se comenta posteriormente). En el caso de que se estuviera produciendo un registro en un nuevo dominio, el árbol no existe todavía y, por tanto, el mensaje alcanzará hasta el MMA (actuando como RP) creando una entrada en las tablas multicast en todos los routers que atraviese. Si estamos en un registro intra-dominio es de esperar que el mensaje alcance rápidamente una de las ramas del árbol compartido, lográndose un handover sensiblemente más rápido que el definido en cualquier otra propuesta.

Hay que indicar que debido a la forma en que utilizamos la

transmisión multicast dentro del sistema de micro-movilidad, donde la única fuente al grupo multicast es el propio RP, el árbol compartido creado es un árbol SPT (Shorted Path Tree). Esto significa que no será necesario la utilización de los mecanismos de registro de la fuente o de conmutación entre árbol compartido y SPT definidos en el protocolo PIM-SM [RFC 2362].


110

Como se ha comentado, la propuesta SSM se corresponde con esta simplificación.

Como se estudio en el punto 3.3.3 en caso de tratarse de un

handover intra-dominio, y como respuesta al mensaje ’Intra-Domain Registration Request', la nueva Estación Base enviaba un mensaje 'Intra-Domain Registration Reply', confirmando que el proceso había finalizado. Este mensaje se transmitía una vez la Estación Base recibía respuesta a su mensaje de incorporación al árbol multicast, por ejemplo por medio de un 'Multicast Ack Join' (figura 3.5). A diferencia de otros protocolos como CBT, el protocolo PIM-SM no implementa esta clase de mensajes. Sin embargo el problema no es excesivamente complejo de resolver, puesto que la mínima información necesaria para poder enviar este mensaje se encuentra en las tablas de enrutamiento multicast PIM.

Selección del Rendezvous Point de un grupo multicast. Una de las consecuencias que produce la elección del MMA como

Rendezvous Point es la manera en que los routers del dominio consiguen conocer cual es el RP para un grupo multicast. El protocolo PIM-SMv2 definía un mecanismo de iniciación para designar este punto. Sin embargo ahora el RP se corresponde con el MMA que le fue asignado al nodo móvil cuando se registro en el dominio, que a su vez dependía de los mensajes ‘Mobility Agent Advertisement’ que enviaba la Estación Base en la que el nodo móvil se conectaba al dominio. La estación Base (recordemos que en el fondo es un router modificado que soporta también multicast) no va a tener problemas para conocer cual es el RP, pues vendrá indicado en el mensaje de registro, independientemente de que se trate de un nuevo registro en el dominio (mensaje ‘Registration Request’, punto 3.5.2), o bien de un registro intra-dominio (mensaje ‘Intra-Domain Registration Request’).

Sin embargo los distintos routers que componen el dominio no

saben, en principio, cual de los diferentes MMA existentes en el dominio actúa como RP para un grupo multicast en concreto. Se han pensado distintas soluciones para esto.


111

La primera consiste en utilizar el mecanismo de inicialización propuesto en el protocolo. En este caso deberíamos habilitar un dispositivo denominado Router de Inicialización (Boot Strap Router BSR). Los RP candidatos, en nuestro caso los diferentes MMAs, enviarían hacia el BSR mensajes definidos en [RFC 2362] como ‘Candidate-RP-Advertisement’, indicando que son un candidato a RP para la dirección multicast que previamente ha asignado a un nodo móvil. El BSR enviaría, periódicamente, el RP propuesto para cada grupo hacia todos los routers del dominio (utilizando la dirección multicast ‘All-PIM-Routers’ definida en [IANA]) mediante un mensaje PIM denominado ‘Bootstrap’. Sin embargo este mecanismo está pensado para que los diferentes routers se ofrezcan como candidatos a un conjunto de grupos multicast y no para uno en concreto. Esto provoca un consumo de recursos, al tener que enviar excesivos paquetes, así como un retardo en el procedimiento, que puede penalizar las prestaciones del sistema.

Otra solución mucho más sencilla consiste simplemente en que

cada MMA del dominio tenga asignado un rango de direcciones multicast de manera exclusiva. Esta opción no limita en exceso la escalabilidad del sistema, pues como ya se ha comentado las direcciones multicast se reutilizan en cada dominio, y la asignación estática de un rango a cada MMA no debe ser una limitación si existe un grupo suficientemente elevado de direcciones disponibles para la implementación del sistema de micro-movilidad propuesto.

Aún así existe una tercera solución que permite el mantenimiento

de las direcciones multicast se realice de forma centralizada en el dominio, es decir, que exista un servidor de direcciones al que se conectan los diferentes MMAs para obtener una dirección multicast libre, que será asignada al nuevo nodo móvil. En este caso la dirección multicast no aportará información del MMA que la ofreció, y por consiguiente, información del RP asignado a ella. Será necesario, por tanto, el añadir esta información en los mensajes ‘Join’ que los routers envían para conectarse al árbol multicast. El formato de los mensajes ‘Join’ definidos en PIM-SMv2 incorpora un campo denominado 'Joined Source Address' que se utiliza para realizar un árbol SPT con una fuente determinada, pero


112

que también puede utilizarse para indicar la dirección del RP (existe un flag para seleccionar esto). Así los distintos routers multicast podrían averiguar el RP asignado antes de reenviar el mensaje hacia él. La discusión anterior carece de sentido en el caso de estar trabajando con tecnología SSM. En este caso se utiliza el protocolo IGMPv3 para realizar la conexión al canal de manera que se indica la fuente S de la que recibiremos los datos multicast, y que en nuestro caso será el MMA. Debido a las características de SSM el conocimiento, por parte de los routers, de la fuente a la que conectarse para generar el árbol multicast viene implícito en el mecanismo de conexión.

3.7 TABLA COMPARATIVA CON OTRAS PROPUESTAS DE MICRO-MOVILIDAD En el punto 2.4 se indicó que se podía hacer una sencilla clasificación de las propuestas de micro-movilidad presentes en la bibliografía:

• Esquemas de agentes de movilidad jerárquicos. Como pueden ser el Mobile IP con Registro Regional MIP-RR, [GUS02].

• Esquemas de encaminamiento basado en host (HBR). Ejemplos de estos son: Cellular IP [CAM00], y HAWAII [RAM99].

En este capítulo hemos presentado un nuevo esquema, totalmente novedoso, basado en la utilización de direccionamiento multicast de las redes IP actuales. Este esquema podría añadirse como una tercera opción en la clasificación anterior. Con el fin de comparar, de manera cualitativa, nuestra solución con las ya comentadas, en este punto se va a mostrar una tabla que muestra las principales características de las principales propuestas. La idea es realizar un estudio del sistema de micro-movilidad en general, sin


113

abordar profundamente los aspectos relativos al handover, que serán tratados con mucha mayor profundidad en los capítulos siguientes de esta Tesis Doctoral. En esta comparación vamos a estudiar, además de nuestra propuesta, los sistemas de micro-movilidad Cellular IP, y MIP-RR, por ser representativos de sus respectivas categorías. Estudios de los sistemas de micro-movilidad pueden encontrarse en [EAR00], [WON01] o [REI01].

MIP-RR Cellular IP Sistema basado en Multicast.

Direccionamiento de los paquetes en sentido descendente

Utilización de túneles, de manera secuencial.

Encaminamiento basado en la dirección permanente del MN.

Encapsulación en paquetes multicast.

Actualización de rutas

MIP + extensiones de registro regional.

Mensaje de actualización especiales

Mensajes multicast Join y AckJoin.

Nodos del Dominio

Routers Nodos especiales Cellular IP.

Routers con capacidad multicast.

Capacidades avanzadas del MN

Sí, capacidad de registro regional.

Sí, soporte completo de Cellular IP.

Sí, MIP + capacidad de registro intradominio.

Seguridad Sí. Según MIP, con extensiones de MIP_RO.

Sí. Los paquetes de actualización de rutas van autenticados.

Sí, los paquetes de registro van autenticados.

Definición formal de paquetes

Sí No Sí

Gestión del Handover

Igual que MIP. Handover abrupto y semisuave.

5 posibles esquemas.

Escalabilidad Utilización de varios niveles de jerarquía.

No, el Gateway soporta todo el tráfico.

Sí, múltiples MMAs.

Tabla 1. Comparación de sistemas de micro-movilidad.


114

3.8 CONCLUSIONES DEL CAPÍTULO En el capítulo anterior se detalló como el protocolo Mobile IP tiene ciertas limitaciones debidas, principalmente, a la necesidad de un registro cada vez que se produce un handover. Una solución ampliamente aceptada es dividir la movilidad en dos partes, de manera que dentro de un dominio se emplean protocolos específicos de movilidad, manteniéndose el protocolo Mobile IP para la movilidad entre dominios.

En este capítulo se ha presentado un sistema de micro-movilidad IP basado en la tecnología multicast. La idea principal ha sido incorporar las ventajas que nos ofrece este tipo de tecnología, y que han sido comentadas en el punto 3.1, a la solución de dividir la red en dominios.

A diferencia de la mayoría de las soluciones presentadas en la

literatura, se ha desarrollado, no sólo una arquitectura, sino un protocolo completo, incluyendo el formato de todos los mensajes que proponemos. Estos mensajes han sido realizados siguiendo las estructuras de extensión del propio protocolo Mobile IP [RFC 3444], así como los trabajos que se están realizando actualmente [KHA01], [GUS02], [PER02]. El objetivo es que el sistema propuesto pueda integrarse perfectamente en un sistema basado en Mobile IP.

El sistema presentado ha sido realizado teniendo presente los

posibles problemas de escalabilidad. El punto crítico en cualquier sistema de micro-movilidad es la pasarela del dominio. En un sistema Cellular IP sería el MA, y el router raíz DRR en el sistema HAWAII. El sistema presentado en este capítulo se ha diseñado de manera que no exista limitación en cuanto al número de MMAs (Agente de Movilidad Multicast) que pueden instalarse. Así los mensajes se han diseñado de manera que aportan información sobre el MMA que está utilizando el nodo móvil. Esta información es necesaria para que las estaciones puedan realizar correctamente el handover intra-dominio.

A diferencia de los demás sistemas de micro-movilidad presentados

en la bibliografía, el sistema propuesto en este capítulo se ha realizado


115

incluyendo todos los mecanismos de seguridad necesarios en este tipo de redes. En particular se ha ampliado las extensiones de autentificación del protocolo Mobile IP incluyendo una autentificación FA-FA (ver punto 3.5.2). Además se abordado el problema del establecimiento de la asociación de seguridad entre el nodo móvil y las estaciones base, tema actualmente bajo estudio en el grupo de trabajo ‘mipv4’ del IETF.

Por último se ha realizado una evaluación de las diferentes

tecnologías multicast, con el fin de decidir cual es la más adecuada para incluirla en el sistema basado en multicast propuesto. Se ha optado por protocolos que utilizan algoritmos de árbol compartido, ya que la inundación utilizada en los protocolos de modo denso no está justificada. Se proponen dos opciones para incorporar al sistema de micro-movilidad. La primera es el protocolo PIM-SM, de gran aceptación por la industria [RFC 2362]. Debido a las características particulares del sistema de micromovilidad (una única fuente que coincide, además, con el Rendezvous Point), muchas de las características de este protocolo no son necesarias, por lo que el protocolo podría simplificarse. La segunda opción es la tecnología SSM (Source-Specific Multicast) [BHA03],[HOL03]. Esta tecnología se ajusta perfectamente a nuestro sistema, ya que está pensado en transmisiones de uno a varios. Sin embargo actualmente no existen aún protocolos específicos SSM, ya que es una tecnología que actualmente se encuentra bajo estudio.

En los siguientes capítulos nos vamos a centrar en el estudio de los

esquemas de Handover. Así vamos a analizar, tanto las prestaciones de los sistemas de movilidad presentados en la bibliografía, como una evaluación analítica de las prestaciones de los distintos esquemas de handover que se han desarrollado para el sistema de micro-movilidad basado en multicast presentado en este capítulo.


116

117

4. PROCESO DE HANDOVER EN REDES IP

4.1 INTRODUCCIÓN

Las aplicaciones de tiempo real, como audio o video conferencias, tienen unos requerimientos elevados en relación al límite de la latencia, indicativo del retardo extremo a extremo. Los paquetes perdidos durante la transmisión se traducirán en interrupciones en el flujo de datos en el receptor, el cual generalmente no tendrá tiempo de esperar una retransmisión de los mismos desde el emisor. Así, en este tipo de aplicaciones, los paquetes válidos que llegan más tarde del retardo máximo permitido son descartados.

En una red que soporta la movilidad los aspectos relativos a la

entrega de datos hacia los nodos móviles pueden dividirse en dos tareas diferenciadas:

• Mientras el nodo móvil permanece bajo la cobertura de un Punto de

Acceso, el problema es similar a la tarea, no trivial, de proporcionar calidad de servicio a nodos fijos en una red de conmutación de paquetes. La ruta entre el nodo móvil y el nodo con el que se comunica debe seleccionarse cuidadosamente para que el retardo total se mantenga dentro de los límites aceptables. Como ya se ha estudiado, algunos protocolos como Mobile IP introducen serias limitaciones en este sentido, al enviar los paquetes vía un agente de movilidad, y por tanto, utilizando una ruta no óptima. Varios trabajos [PER01], [JOH03] han presentado distintas soluciones que intentan lograr una ruta lo más directa posible.

• Cuando un nodo se mueve desde una zona cubierta por un punto de

acceso a otra cubierta por otro se producirá un proceso de handover.

Proceso de Handover en redes IP

118

Podemos definir el ‘handover’ 1 como el procedimiento por el cual nodo móvil activo cambia su conexión de un Punto de Acceso a otro a través de la red. Los puntos de acceso son los extremos de la red fija y vía radio se comunican con el móvil transmitiéndole la información. Así, por medio del procedimiento de handover los datos que se transmiten por la red fija desde un servidor deben de reenrutarse sin que ello produzca una interrupción en la comunicación entre los dos extremos.

Es deseable realizar el proceso de handover rápidamente. Si el tiempo de handover es elevado en relación la zona común a las dos zonas se producirán interrupciones en el flujo de datos aún cuando el retardo total sea bajo.

El tráfico producido en la red por el handover es función de varios

factores [POL96], como el número de móviles, su función de movilidad, velocidad, el tamaño de las celdas, tipo de conexión, etc. La transmisión de servicios multimedia determina que el tamaño de las celdas sea pequeño, con el fin de lograr una reutilización de frecuencias eficiente. Esta reducción de tamaño trae consigo, sin embargo, que el número de handovers sea mayor y, por tanto, habrá que lograr minimizar la señalización por handover con el fin de no sobrecargar demasiado la red. Por otra parte, celdas pequeñas hacen que la zona de solapamiento entre dos celdas contiguas sea también pequeña. Como resultado de esto, el tiempo en el que debe de producirse el handover disminuye y será necesario que el diseño de los protocolos de señalización permita mecanismos rápidos con el fin de que no se pierdan conexiones. Existen diferentes tipos de clasificaciones de handover de acuerdo a diferentes aspectos involucrados en el mismo. A continuación se va a comentar alguna de estas clasificaciones, siempre desde el enfoque de la movilidad en redes IP. Estas clasificaciones son independientes, de manera que cada handover podría clasificarse en cada uno de estos tipos.

1 Los términos Handover y Handoff son equivalentes y en la bibliografía son utilizados indistintamente.


119

• Capa implicada en el Handover: Podemos distinguir entre un handover de capa dos (L2) y uno de capa tres (L3). Un handover L2 ocurre cuando el nodo móvil (MN) se mueve desde un Punto de Acceso (AP) a otro que está conectado a un mismo Router de Acceso (Access Router, AR). Este tipo de handover es transparente a la capa de red y, por tanto, no implica al protocolo de movilidad IP. Así el handover L2 sería manejado por el protocolo de enlace correspondiente, por ejemplo IEEE 802.11, y no sería necesario obtener una nueva dirección Care-of Address (CoA), ni en general utilizar ningún mecanismo de movilidad o micro-movilidad de capa de red.

Por otro lado tenemos el handover L3 que se produce cuando el MN cambia de AR. En este caso se produce un cambio de subred y será necesario utilizar un protocolo de movilidad a nivel 3 como los que estamos estudiando en esta Tesis.

• Nodo que inicia el Handover: Podemos distinguir dos tipos de handover en función de quién toma la decisión inicial de comenzar el proceso de handover. Así tendremos por un lado el denominado handover ‘Iniciado por el Nodo Móvil’, y por otro el handover ‘Iniciado por la Red’ que se refiere a cuando es algún elemento que forma la red (por ejemplo puntos de acceso o Foreign Agent) quién lo inicia.

• Nodo que controla el handover: El handover puede ser controlado por

el nodo móvil o por algún elemento de la red. Tanto en el protocolo Mobile IP como en todos los sistemas de micro-movilidad publicados se opta por un handover controlado por el nodo móvil. La principal razón es que el nodo móvil es el mejor lugar para entender las necesidades del usuario en términos de las aplicaciones que se están utilizando, los requerimientos de QoS, etc. Por el contrario, en los sistemas celulares tradicionales no se necesita dar un control final al usuario, porque sólo se proporciona un único servicio (voz), y éste se puede proporcionar fácilmente por la red. Por tanto en este tipo de redes el handover está controlado por la red.


120

• Nodo por el que se realiza el handover: Podemos distinguir dos tipos de handover en función del nodo de la red por el que se realiza. Así el handover puede ser hacia atrás (‘Backward Handover’) cuando es iniciado por el AR actual (oAR) o cuando el nodo móvil inicia el handover por él. Por otra parte el handover puede ser hacia delante (‘Forward Handover’) cuando es iniciado por el nuevo nAR o bien cuando el nodo móvil inicia el handover vía el este nuevo nAR.

• Modo esperado o no esperado: Cuando un handover utiliza alguna

señalización previa a la conexión del nodo al nuevo AR se denomina handover esperado o planeado (‘Expected o Planned Handover’). Un ejemplo sería cuando se construye un túnel temporal entre los dos AR para transmitir los paquetes pendientes. Por otra parte definimos handover no esperado o no planeado cuando no se realiza ninguna señalización previa al movimiento del MN desde un oAR a un nAR.

• Conectividad simultánea: Un nodo móvil puede comunicarse

simultáneamente con los dos Routers de Acceso (oAR y nAR) durante el handover. Este modo de funcionamiento se denomina ‘Make-Before-Break’ (MBB) y no debería ser confundido con el término handover blando (‘Soft Handover’) relativo a la macro diversidad [KEM01].

La macro diversidad se refiere a la capacidad de ciertos nodos móviles de recibir y transmitir simultáneamente sobre dos canales radio independientes, de manera que se puede comparar en que canal se recibe la información con mejor calidad y pasar ésta a las capas superiores. La macro diversidad se refiere a nivel de enlace radio y puede utilizarse para mejorar el handover L2. Un ejemplo de este mecanismo sería los sistemas móviles 3G basados en CDMA como UMTS. La mayoría de la bibliografía utiliza, sin embargo, ambos términos indistintamente.

La otra opción sería la denominada ‘Break-Before-Make’ (BBM) donde el MN no puede comunicarse simultáneamente con los dos AR.

En este capítulo se va a profundizar en los diferentes tipos del proceso handover. La intención última es estudiar las soluciones que han


121

sido aportadas a la mejora del proceso de handover en redes IP móviles, por ser éste el marco de trabajo de la presente Tesis. No se trata, por tanto, el tema del handover en otro tipo de redes como ATM o sistemas celulares donde existe una bibliografía suficientemente extensa. Así, por ejemplo, una visión de conjunto las diferentes soluciones propuestas para realizar el handover en redes ATM se podría obtener a partir de [ACA94], [YUA96], [AKY97] y [LEO98]. Una clasificación de handovers en sistemas celulares puede encontrarse en [POL96]. El resto del capítulo se divide en los siguientes puntos: En el punto 4.2 se hace un estudio de la latencia que produce el proceso de handover. Además se va a recordar el proceso especificado en el protocolo Mobile IP, que nos va a servir, como en anteriores situaciones, como base para posibles mejoras. El punto 4.3 trata la separación que existe entre el handover en la capa dos y en la capa tres, y como una cooperación entre ambos puede traducirse en una mejora de prestaciones. En el punto 4.4 se realiza una clasificación de las diferentes propuestas que se han presentado para mejoras el handover en redes IP móviles. Para finalizar, las conclusiones obtenidas de estas soluciones se muestran en el punto 4.5.

4.2 Latencia del proceso de Handover en redes IP

Desde el punto de vista del estudio de un proceso de handover de capa tres podemos estudiar la latencia como la suma de tres tiempos diferenciados [VAT98]: Retardo en la detección de movimiento, (Tmove-detect); Retardo en la recuperación de una dirección temporal, Care-of Address, (Tco-retrieval); y el Retardo de reestablecimiento de la ruta (Tredirect).

Thandover=fh (Tmove-detect, Tco-retrieval, Tredirect )

A continuación se detallan estos tres componentes.


122

4.2.1 Retardo en la detección del movimiento El retardo en la detección de movimiento se refiere al tiempo necesario para detectar que se ha producido un cambio de subred y que es necesario iniciar un handover de capa tres.

En el protocolo Mobile IP [RFC 3344] esta detección la realiza el nodo móvil estudiando los mensajes ‘Agent Advertisement’ que recibe. La recepción de estos paquetes del nuevo Foreign Agent implica que se ha tenido que producir previamente un handover de capa dos, el cual se ha traducido en un cambio de conectividad de un Punto de Acceso a otro que pertenece a otra subred.

Por tanto, el proceso de handover L2 va a afectar directamente a las

prestaciones del handover de la capa de red, puesto que, en un principio, hasta que no finalice el primero no es posible detectar que es necesario que se produzca el segundo.

El tiempo necesario para que se realice un handover de capa dos, y

que lo podemos incluir en el retardo de detección de movimiento, depende del tipo de red que se está utilizando. Para minimizarlo sería deseable que el nodo móvil pudiera detectar que ha entrado en una nueva celda y desarrollar el handover antes de perder la conectividad con el punto de acceso previo. El desarrollo este tipo de handover implica la necesidad que la zona de solape entre las dos celdas sea suficientemente amplia en relación a la latencia del proceso y a la velocidad del nodo móvil. El proceso se facilita si el nodo móvil puede comunicarse simultáneamente con los dos AP, por ejemplo utilizando técnicas de espectro ensanchado (DSSS) con múltiples códigos [KER94]. Otra alternativa sería la de utilizar múltiples interfaces inalámbricos [ZHA98]. La detección del cambio de celda se realiza midiendo los niveles de señal en el interfaz. Cuando el nivel de relación señal ruido (SNR) baja de cierto nivel se iniciaría el proceso de handover, utilizando por ejemplo un mecanismo de histéresis para eliminar problemas con los nodos que se mueven entre las dos zonas [LIU96]. Las medidas pueden realizarse bien


123

midiendo señales de anuncio (beacon), o bien cualquier otro tipo de señales enviadas por el AP.

A pesar que en un principio se puede pensar que el proceso de handover L2 queda fuera de nuestro estudio, ya que estamos trabajando con soluciones de capa tres, la realidad es que las prestaciones que se pueden obtener en un handover L3 dependen, en gran medida, de las facilidades que ofrece el nivel inferior. Así en el punto 4.3 se estudiará como una cooperación entre ambas capas mejora las prestaciones del handover L3, mientras que algunas de las soluciones que se detallan en el punto 4.4 presuponen la capacidad de la capa de enlace de comunicarse simultáneamente con los dos AP implicados.

4.2.2 Retardo en la recuperación de una dirección temporal, Care-of Address En la gran mayoría de los sistemas de movilidad IP estudiados cada nodo móvil dispone de una dirección permanente (Home Address) asignada a una (posiblemente virtual) Home Network. Cuando un nodo móvil visita una red distinta utiliza para su identificación una dirección adicional que se denomina Care-of Address (CoA) y que puede ser asignada directamente al nodo móvil (Co-located Care-of Address), o bien puede ser la dirección de un agente (Foreign Agent) que se dedica a dar conectividad a múltiples nodos móviles (ver punto 2.3 o [RFC 3344]). Existen varias soluciones que permiten a un nodo móvil obtener una dirección temporal (Co-located Care-of Address):

• Asignación estática. Si el grupo de redes que puede visitar el nodo móvil es conocido de antemano y las direcciones IP no son consideradas un recurso escaso, cada estación puede tener preasignadas una serie de direcciones IP que utilizará cuando visite esas redes.


124

• Configuración predeterminada. Es posible asignar a un nodo móvil una dirección IP cuando visita una nueva red de un modo controlado, por ejemplo utilizando un servidor DHCP [RFC 2131]. En Mobile IPv6 esta solución se conoce como configuración ‘Stateful’ [JOH03]. También sería posible la utilización de otros mecanismos de configuración como el uso de servidores BOOTP [RFC 1542]. Sin embargo la utilización de servidores DHCP aporta ventajas sobre estas últimas soluciones, un ejemplo sería el mecanismo de asignación de direcciones, realizando asignaciones que sólo son válidas durante un cierto tiempo, permitiendo una reutilización de las mismas.

• Configuración sin intervención. En IPv6 aparece el concepto de autoconfiguración sin intervención ‘Stateless’ [RFC 1971]. Así, el nodo genera un identificador único del interfaz, conocido como ‘Interface Token’. Este identificativo se une al prefijo de la red donde está situado el nodo para formar una dirección global válida y única. El prefijo de la red lo obtendría de los anuncios realizados por los routers de la red. Un ejemplo para construir el identificativo único sería partir de una dirección IEEE MAC de 48 bits como se indica en [RFC 2373]

En [BAK96] se han realizado estudios del retardo de handover

cuando el nodo móvil tiene asignadas de antemano un grupo de direcciones IP asociadas a las redes que va a visitar. En [VAT98] se realiza un estudio pormenorizado de este retardo cuando se utilizan servidores DHCP obteniendo valores en torno a los 103 ms. para la obtención de una dirección temporal.

Por último indicar que algunos sistemas de micro-movilidad, en

particular los basados en encaminamiento por host como pueden ser HAWAII o Cellular IP, eliminan este componente de la latencia durante los handovers intra-dominio, al mantener constante la dirección CoA. También el protocolo de micro-movilidad multicast propuesto en el capítulo 3 elimina este retardo puesto que utiliza una dirección multicast


125

que permanece constante durante la permanencia del nodo móvil en el dominio.

4.2.3 Retardo de reestablecimiento de la ruta

Una vez el nodo móvil (MN) ha adquirido la nueva dirección IP es necesario una serie de pasos hasta que el flujo de datos alcanza al nodo en su nueva localización. Este proceso influye de manera importante en tiempo total del proceso del handover, y varía dependiendo del esquema de movilidad implementado.

Hay que indicar que este retardo afecta al flujo de datos que fluye

en sentido host corresponsal (CN) hacia el nodo móvil. En sentido contrario el MN transmite directamente los datos hacia el destino utilizando siempre su dirección permanente para que no existan problemas con las conexiones en curso. La excepción a esto se produce cuando los routers filtran los paquetes cuya dirección fuente no es correcta según la topología, es decir, cuando la dirección fuente no coincide con las redes que entran por ese interfaz del router. En este caso el nodo móvil debería reenviar los datos al Home Agent utilizando un túnel para que este a su vez los reenviara desde la Home Network. Este proceso se conoce como ‘Reverse tunneling’, estandarizado en [RFC 3024].

En el protocolo Mobile IP, el MN envía el conocido mensaje de

solicitud de registro hacia en HA (Home Agent) para que este actualice la entrada correspondiente en su tabla. El HA contesta con un mensaje de respuesta de registro, a partir del cual empezaría a enviar los datos utilizando la nueva dirección.

El tiempo que lleva este proceso depende del mecanismo por el que

el MN ha obtenido la dirección temporal. Así, en el caso estar utilizando una dirección Care-of Address de un Agente (FA), habrá que tener en cuenta que el mensaje de registro es enviado por el MN hasta el Foreign Agent, quién deberá procesarlo antes de reenviarlo al Home Agent. De la


126

misma manera el mensaje de confirmación es enviado desde el HA hacia el FA, quién lo reenviará finalmente al nodo móvil.

Cuando un nodo móvil se encuentra lejos de su red original (Home

Network) los mensajes de registro experimentarán un mayor retardo. Con el fin de reducir el tiempo de reestablecimiento de ruta se han propuesto diversas mejoras y que nosotros conocemos como sistemas de micro-movilidad. Así tenemos los 'Esquemas con agentes de movilidad jerárquicos' como el Registro Regional [GUS02] (ver punto 2.3.7). La idea aquí es que los handovers que se realizan dentro de un dominio se traduzcan en un registro realizado en un Agente Pasarela (GFA Gateway Foreign Agent) situado en el dominio y provocando retardos menores. Por otro lado, en los 'Esquemas de encaminamiento basado en host (HBR)' (ver punto 2.4) el establecimiento de ruta sólo afecta a unos pocos routers situados por debajo del Nodo de Cruce, por lo que también se reduce mucho el retardo de reestablecimiento.

Por último en el sistema de micro-movilidad basado en multicast

propuesto en el capítulo 3 el tiempo de reestablecimiento de ruta sería simplemente el tiempo que necesita el nFA en conectarse al árbol multicast. Un estudio detallado de la latencia total de este sistema se muestra en el capítulo 6.

4.3 COOPERACIÓN DE LA CAPA 2 DURANTE EL HANDOVER

Con el fin de ofrecer una solución lo más general posible, el

protocolo Mobile IP se diseñó sin suponer nada del nivel de enlace de datos (L2) que trabaja por debajo de él. Esta solución presenta la ventaja de ofrecer una clara separación entre los niveles L2 y L3 en la pila de protocolos, pero tiene una consecuencia negativa en la latencia del proceso de handover.


127

En el protocolo original, un nodo móvil (MN) sólo puede comunicarse con un Foreign Agent con el que tiene una conexión directa. Esto implica que el MN sólo puede comenzar el proceso de registro con el nuevo Foreign Agent (nFA) una vez que el handover de nivel dos ha sido completado con éxito. Además, en ningún momento se especifica un mecanismo por el que el protocolo de nivel dos indique a la capa superior que este handover L2 se ha producido, lo que se traduce en que el protocolo Mobile IP debe detectar, de manera totalmente autónoma, si se ha producido un cambio de subred que origine el inicio del proceso de handover L3.

Como se estudiará en el siguiente punto, recientemente han

aparecido distintos trabajos [ELM02], [KOO02] (ambos catalogados como ‘Work in Progress’) que intentan disminuir la latencia del proceso de handover de nivel de red, utilizando información sobre el estado en que se encuentra el handover L2.

Para mejorar la cooperación de los procesos de handover a nivel L2

y L3 en [YEG02] (‘Work in Progress’) se ha definido el concepto de ‘trigger’. Éste puede entenderse como una abstracción de una notificación desde el nivel dos (L2), que indica que cierto evento ha ocurrido o se va a producir. Estos triggers no están asociados a un nivel de enlace en concreto, sino que se basan en la tipo de información que puede estar disponible en la mayoría de los protocolos de enlace radio.

Podemos indicar tres tipos de información que están involucradas

en la definición de un trigger L2:

• El evento que causa que el trigger se lance.

• La entidad IP que recibirá la señalización.

• Los parámetros entregados con el trigger. La entidad IP que recibirá el trigger dependerá del protocolo de

movilidad IP particular que estemos utilizando. En protocolos basados en


128

Mobile IP estas entidades podrían ser tanto el nodo móvil como uno de los Foreign Agent implicados.

Dos ejemplos de trigger podrían ser el que indica que se ha

establecido un enlace L2, y el que indica que el enlace L2 se ha desmantelado. Así la recepción del trigger de ‘Enlace L2 Establecido’ podría forzar al protocolo Mobile IP de un nodo móvil a enviar un mensaje Agent Solicitation [RFC 3344]. De esta manera se reduce el tiempo de detección de movimiento, Tmove-detect, estudiado en el punto 4.2.

Otro evento para el que se ha definido un trigger es la inminencia

de la realización de un handover L2, que puede indicarse tanto en el nodo móvil como en alguno de los Foreign Agent involucrados, bien el nuevo FA (nFA) o bien el antiguo (oFA)

En la tabla 4.1 se muestra lista con los triggers definidos con los

que se trabaja hasta este momento. En la tabla se especifica una descripción del trigger, el evento del handover L2 que causa el lanzamiento del mismo, que entidades pueden recibir el trigger y los parámetros que se entregan.

El receptor del trigger sería el protocolo de movilidad de nivel 3 del

propio nodo IP, realizándose la comunicación por mecanismos internos. Sin embargo, y como se estudió en el punto 3.2, es posible que el nodo no tenga funcionalidad de nivel dos inalámbrico, por ejemplo un Foreign Agent que no tiene directamente interfaz inalámbrico y que se conecta con un conjunto de Puntos de Acceso (figura 3.1). En este caso será necesario un protocolo que transmita el triggers desde el nodo donde se produce el handover L2 hasta el nodo IP donde se sitúa el protocolo de movilidad L3 implicado. En [YEG02b] (‘Work in Progress’) se está trabajando en un protocolo basado en una arquitectura cliente servidor sobre UDP para el envío de estos triggers L2.


129

L2 Trigger Evento Receptor Parámetros

Link Up

(L2-LU)

Se ha establecido en enlace L2

MN

nFA

nFA -> Dirección L2 del MN

MN -> Dirección del nFA.

Link Down

(L2-LD)

Se ha desmantelado un enlace L2 oFA Dirección L2 del MN

Source Trigger

(L2-ST)

Va a producirse un handover L2 oFA

Dirección L2 del nFA que puede ser traducida a una dirección IP .

Dirección L2 del MN

Target Trigger

(L2-TT)

Va a producirse un handover L2 nFA

Dirección L2 del oFA que puede ser traducida a una dirección IP.

Dirección L2 del MN

Mobile Trigger

(L2-MT)

Va a producirse un handover L2 MN

Dirección L2 del nFA que puede ser traducida a una dirección IP

Tabla 4.1 Triggers L2 Podemos estudiar como se implementarían los triggers en una red real tomando como ejemplo las redes de área local inalámbricas [IEEE 802.11]. El protocolo dispone de una trama de gestión denominada ‘Reasociación_petición’. Esta trama la envía un MN cuando desea cambiar su asociación de un AP a otro nuevo. El nodo móvil determina que un nuevo Punto de Acceso está disponible utilizando las tramas de señalización ‘beacon’ enviadas por éste. El mensaje de reasociación contiene la dirección física del AP actual y la del nodo móvil, y es enviada a la dirección del nuevo AP deseado.


130

Una vez recibida la trama, el nuevo AP determina si el nodo puede asociarse y contesta con una trama de ‘Reasociación_respuesta’ aceptando o denegando la petición. Los mensajes de reasociación contienen suficiente información para la implementación de los siguientes triggers.

• Establecimiento de enlace, Link Up: Cuando el driver 802.11 del MN recibe la trama de confirmación de la reasociación puede entregar este trigger al Mobile IP (o a un ‘demonio’ que se comunica con el protocolo de red y está monitorizando el driver) conteniendo la dirección física del nuevo AP. La recepción de este trigger forzaría al envío de un mensaje ‘Agent Solicitation’ [RFC 3344].

• Cuando el AP determina que puede enviar una confirmación positiva al MN, puede generar un trigger Link UP dirigido al protocolo de movilidad IP del nFA con las direcciones físicas del MN y del AP anterior. Si el AP está actuando como un puente transparente será necesario un protocolo para enviar el trigger hasta el router de acceso (que contiene el FA). Esto puede realizarse bien añadiendo prestaciones al protocolo IAPP (InterAccess Point Protocol) [IEEE 802.11f], que actualmente se encuentra en desarrollo, o bien mediante la creación de un protocolo específico como se comentó anteriormente.

4.4 SOLUCIONES EXISTENTES DE HANDOVER EN SISTEMAS DE MOVILIDAD IP

En el punto 2.3 se estudió el protocolo de movilidad Mobile IP (MIP).

La necesidad de realizar un registro con el Home Agent cada vez que el nodo móvil cambia de red hace que la latencia del proceso de handover aumente hasta cotas inaceptables en aplicaciones de tiempo real, como videoconferencias o tecnologías de VoIP. Con el fin de disminuir este tiempo se estudió las ventajas de implementar sistemas de micro-movilidad que reducen la latencia, la pérdida de paquetes, y la sobrecarga de señalización durante el handover.


131

El fin último es mejorar las prestaciones del proceso de handover. En este sentido en [MAN02] ('Work in Progress') se distinguen los siguientes términos:

• Handover Suave (Smooth Handover): Proceso de handover en el

que el objetivo es minimizar la pérdida de paquetes, sin una preocupación explícita del retardo en la entrega de los paquetes.

• Handover Rápido (Fast Handover): Proceso de handover en el que su principal motivación es la entrega de paquetes con retardo mínimo sin interés explícito en la pérdida de paquetes.

• Handover Sin Degradación (Seamless Handover): Handover en el que no se produce cambio en capacidad de servicio, seguridad o calidad. En la práctica siempre se producirá una cierta degradación, por lo que una definición realista sería la de un handover en el que las aplicaciones, protocolos o usuarios finales no detectaran cambios que afectara a su funcionamiento normal.

Con el fin de enmarcar las soluciones al proceso de handover que

ofrece el protocolo de micro-movilidad multicast presentado, a continuación se van a comentar brevemente los principales trabajos realizados en este ámbito.

Debido a la variedad de trabajos publicados en los últimos años

nos vamos a centrar en las soluciones más relacionadas de alguna manera con nuestro protocolo. Así hemos resaltado cuatro grupos, aunque las soluciones que ofrecen no son excluyentes: en el punto 4.4.1 se comenta algunas soluciones que se centran en conseguir handovers suaves que minimizan las perdidas de datos; posteriormente en 4.4.2 estudiaremos alguna de las propuestas que se basan en la utilización de triggers L2; en el punto 4.4.3 estudiaremos las soluciones que se ofrecen en los distintos sistemas de micro-movilidad que se presentaron en el tema 2.3; y finalizaremos comentando los procesos de handover que se basan en la utilización de la transmisión multicast.


132

4.4.1 Soluciones para Handovers suaves

Se han propuesto varias soluciones para lograr un handover suave que minimice la pérdida de paquetes durante el proceso. El protocolo Mobile IP original no contempla una notificación del MN al oFA. Así, los paquetes interceptados por el HA tras el nuevo registro serán enviados al nFA y se asume que el nivel superior solucionará el problema de la pérdida de los paquetes que hasta ese momento van en tránsito hacia el oFA.

El principal trabajo realizado para solucionar este tema es [PER01] ('Work in Progress') en el que, además de definir los principios de la optimización de ruta (punto 2.3.6), se detalla los mensajes y los mecanismos necesarios para lograr un handover suave utilizando como base el protocolo Mobile IP.

Como la gran mayoría de las soluciones se basa en una comunicación entre los dos Foreign Agent implicados, de manera que el oFA le transmite al nFA los datagramas que no ha podido enviar el nodo móvil por haberse cambiado de subred. Además está comunicación permitirá la liberación inmediata de los recursos consumidos por el nodo móvil en el FA antiguo, sin tener que esperar que expire el tiempo de vida del mensaje de registro.

La comunicación se realiza bajo petición del MN, empleando para

ello una nueva extensión en el mensaje de registro. En nuevo FA le enviará un mensaje ‘Mensaje de Actualización de Información’ (Binding Update) al otro FA implicado, con el fin de que le transmita los paquetes dirigidos hacia el MN que aún están pendientes o los que lleguen en un futuro.

Aún utilizando esta solución, los datagramas que lleguen al oFA

antes que la notificación de reenvío, y que ya han sido enviados por el enlace inalámbrico, se perderán. Está pérdida será tanto más importante cuanto mayor sea el tiempo en el que el MN no tiene contacto con ningún FA, debido principalmente a que se está produciendo el handover L2, y al tiempo que le cuesta al MN detectar el nuevo FA utilizando los conocidos mensajes de aviso ‘Agent Advertisement’.


133

La solución que se ha aportado en algunos trabajos [PER99] es el utilizar algún mecanismo de almacenamiento de los últimos paquetes que el FA envía al nodo móvil. Así, en el caso de recibir una notificación de reenvío por parte del nFA, no sólo enviaría las tramas que se reciban a partir de ese instante, sino que también se enviarían las previamente almacenadas. Con una correcta configuración de estos buffers se lograría evitar la pérdida de paquetes durante el handover.

El mayor problema que tiene este mecanismo de almacenamiento

de paquetes, aparte de los recursos necesarios, es la duplicación de paquetes en el receptor (en este caso el MN). Aunque es posible la duplicación de paquetes en redes IP, las implementaciones de TCP asumen que la recepción de reconocimientos TCP duplicados es debida a una pérdida de paquetes y, por tanto, se traducirá en el lanzamiento de los mecanismos de control de congestión [JAC88]. Más concretamente, en las primeras versiones del protocolos TCP (TCP Tahoe) la recepción de tres ACK iguales configuraban la ventana de congestión con tamaño uno e iniciaban el mecanismo conocido como ‘inicio lento’. Otras versiones más modernas, como ‘TCP Reno’, lo sustituyen por una reducción de la ventana de congestión a la mitad y la ejecución del mecanismo de ‘recuperación rápida’. Han aparecido distintas modificaciones posteriores, [RFC 2582], pero todas las soluciones afectan, de alguna medida, a las prestaciones del protocolo. El problema es que la duplicación se produce por el sistema de movilidad y no por una congestión real de la red.

Durante los últimos años se han propuesto numerosas soluciones

que modifican en mayor o menor medida el protocolo TCP para adaptarlo a los requerimientos de movilidad (un ejemplo sería [YAV94]). Sin embargo está opción provoca la necesidad de modificar todos los nodos de Internet, lo que no es factible.

Un mecanismo mucho más sencillo para evitar los problemas

ocasionados por la duplicación de paquetes debido al almacenamiento sería el diseñar un mecanismo que evitara esa transmisión duplicada. En algunos trabajos se propone que el FA almacene, junto con el datagrama, una identificación del mismo. De esta manera cuando el MN solicita el


134

handover suave incluye los identificativos de los últimos datagramas recibidos, con el fin de que esa información se haga llegar al oFA y éste no los reenvíe por duplicado. En [PER99] se propone que el identificativo sea la dirección IP fuente del paquete junto con el campo de identificación de IP (utilizado originalmente para la fragmentación). Una opción similar se detalla en [BAL95].

4.4.2 Handover de baja latencia utilizando triggers En el punto 4.3 se estudió como la implementación de triggers L2 favorecía el desarrollo de mecanismos de handover con baja latencia. El principal trabajo relacionado en este campo es [ELM02], titulado 'Handovers de baja latencia en Mobile IPv4' y actualmente catalogado como ‘Work in Progress’. Este trabajo es el resultado de la integración de numerosos trabajos realizados hasta la fecha (como por ejemplo [ELM00], [KEM00] o [DOM01] ) y en él se describen dos soluciones que disminuyen la latencia del handover. La primera solución se denomina handover pre-registro y se basa en permitir al nodo móvil comunicarse con el nFA (nuevo Foreign Agent) cuando todavía se encuentra conectado al oFA.

Una segunda solución presentada se denomina handover post-registro y permite la entrega de datos a un nodo situado en un nFA antes de que se realice el proceso de registro. Esto permitirá una continuidad en el servicio ofrecido mientras se procesa el handover en la red. Finalmente también se presenta una combinación de ambos métodos. Handover Pre-Registro. Este método permite al nodo iniciar un handover a nivel de red antes de que concluya el handover de nivel dos. El proceso puede ser iniciado por la red o por el nodo móvil y se basa en el handover original del protocolo Mobile IP, de manera que no se proponen nuevos mensajes si


135

exceptuamos una extensión al mensaje ‘Agent Solicitation’. La compatibilidad con el protocolo original es una ventaja, pues nos va a permitir utilizar este mecanismo en conjunción con otras soluciones como los sistemas de micro-movilidad jerárquicos.

El funcionamiento básicamente consiste en comunicarse con el futuro FA mediante el FA actual, de manera que pueda iniciarse el proceso de handover de nivel tres antes de que ocurra el de nivel dos. A continuación se resume el mecanismo en una serie de puntos:

• Previamente a que comience el proceso de handover los diferentes Foreign Agents se intercambian mensajes ‘Agent Advertisement’, solicitados mediante mensajes ‘Agent Solicitation’ y almacenados temporalmente en memoria.

• El nodo móvil puede recibir un trigger L2 (‘MT-L2’ de la tabla 4.1) indicando que se va a producir, en un futuro cercano, un handover a nivel dos. En ese instante el MN envía un mensaje del tipo ‘Proxy Agent Solicitation’ al FA con el que mantiene aún la conexión (oFA). Este mensaje es idéntico al tradicional excepto por una extensión que indica que la solicitud es para un FA en particular (nFA).

• En respuesta a esta petición el oFA envía el mensaje ‘Agent Advertisement’ del nFA almacenado. Este mensaje podría ser enviado sin la necesidad de una petición previa en el caso en que el proceso de handover hubiera sido iniciado por el oFA (vía ‘ST-L2’ trigger) o incluso por el nFA (en este caso se utiliza un túnel).

• El nodo móvil detecta si es necesario un handover de nivel 3 estudiando el mensaje del nFA (como en el protocolo original). En caso afirmativo se envía el ‘Registration Request’ definido en [RFC 3344]. Este mensaje deberá ser encaminado vía oFA puesto que el nodo móvil aún no tiene una conexión directa con nFA.

• El mensaje de respuesta al registro ‘Registration Reply’ que envía el Home Agent lo recibirá el nFA (ya que es éste el FA implicado en el nuevo registro), quién lo transmitirá al MN tan pronto se complete el handover L2 (trigger ‘L2-UP’).


136

Como puede observarse el tiempo de antelación con el que se produce el trigger, que indica de forma anticipada que se va a producirse un handover L2, es importante para que el proceso de handover logre el objetivo de baja latencia. En el caso óptimo, el primer paquete redirigido desde el HA hacia el nFA alcanzará al MN en el instante en que se completa el handover L2, lográndose que no se produzcan interrupciones debido al handover L3. Para lograr este objetivo pueden ser necesarias técnicas adicionales a nivel 2, como almacenamiento en buffers o transmisión simultánea, aunque en un principio quedan fuera de estudio.

Por último, serían necesarias consideraciones adicionales para

lograr handovers suaves, que eliminen la pérdida de paquetes (desde el HA al oFA) mientras el MN realiza el proceso de handover. Estas quedan también fuera de estudio.

En la figura 4.1 se muestra un diagrama que resume el proceso de pre-registro cuando el handover es iniciado por el MN. Los handovers iniciados por la red (tanto por el oFA como por el nFA) son similares y pueden encontrarse en la bibliografía.

Figura 4.1 Proceso de handover iniciado por el MN.

MN oFA nFA HA

Proxy Agent Solicitation

Registration Request Registration Request

Registration Reply

Proxy Agent Advertisement

L2 Trigger

Registration Reply


137

Handover Post-Registro

El método de handover post-registro propone una extensión al protocolo Mobile IP que, utilizando un túnel entre el oFA y el nFA, permite al MN seguir utilizando el oFA mientras se encuentra en la zona cubierta por el nFA. De esta manera el MN puede ir cambiando el punto de acceso con la red sin necesidad de realizar un nuevo registro con el Home Agent, lo que minimiza el impacto del handover en aplicaciones con restricciones temporales.

Una vez el nodo móvil realiza un registro con un Foreign Agent

(oFA), éste se convierte en un punto ancla, aFA. Así, cuado el nodo se mueve de un oFA hacia un nFA, el nodo móvil aplaza la realización de un handover L3, manteniendo el aFA y utilizando un túnel para recibir los datos desde el mencionado aFA. Podemos resumir el proceso en los siguientes puntos:

• El oFA, o el nFA, reciben un trigger L2 (ver punto 4.3) informando que el nodo móvil va a moverse de un FA a otro.

• El Foreign Agent (FA) que recibe el trigger estudiará el contenido del mismo, para averiguar el otro FA implicado en el proceso, y le enviará un mensaje denominado ‘Solicitud de Handover’ (HRqst). La información que se incluye en este mensaje enviado difiere ligeramente dependiendo de quién es el FA que lo envía (oFA o nFA).

• El FA que recibe el mensaje contesta utilizando un nuevo mensaje denominado ‘Respuesta de Handover’ (HRply).

• Así, cuando el oFA recibe el trigger L2-LD indicando la desconexión del nodo comienza a dirigir los paquetes a través del túnel hacia el nFA.

• Cuando el nFA recibe un trigger L2-LU, indicando el establecimiento de una conexión con el MN, comienza a entregar los paquetes recibidos hacia el MN. También se va a encargar de encaminar los paquetes recibidos desde el nodo móvil utilizando


138

mecanismos normales de encaminamiento, aunque también está previsto la utilización de un túnel inverso hacia el oFA o el HA.

• Finalmente cuando el MN recibe un trigger L2-LU de establecimiento de la conexión L2 podría iniciar el proceso de registro solicitando un ‘Agent Advertisement’ al nFA.

Cuando los triggers L2 se producen de manera óptima el túnel se

establece al comienzo del handover L2 y la transmisión de datos se iniciará inmediatamente se conoce la caída del enlace. Con el fin de proporcionar un handover suave en algunas situaciones sería necesario incorporar algún mecanismo de retransmisión de datos adicional que actualmente no está definido.

Se ha definido un mecanismo similar para realizar un handover

cuando el nodo móvil ya tiene establecido un túnel desde el aFA y se mueve a un tercer FA sin haber realizado aún el proceso de registro con el HA. La solución incluye un nuevo mensaje denominado ‘Handover a un tercero’ (HTT) que se intercambian los FA afectados. El método exacto de funcionamiento puede encontrarse en la bibliografía.

Adicionalmente también se define un mecanismo conjunto que

permite la utilización combinada de los dos mecanismos de handover comentados (pre-handover y post-handover), así como procesos para solucionar posibles errores de señalización durante el handover. Por último indicar que la utilización de triggers es también la solución adoptada en los trabajos que se están realizando actualmente para de acortar el tiempo de handover en el protocolo Mobile IPv6, [KOO02].


139

4.4.3 Handovers en sistemas de micro-movilidad Previamente se estudió como la división de la red en dominios

permite implementar las soluciones de movilidad en dos niveles, lo que se traduce en una mejora de prestaciones cuando se producen handovers dentro de un dominio. Aparecen así los protocolos de micro-movilidad cuyo fin es gestionar esta movilidad intra-dominio de una manera local, produciendo menores tiempos de latencia.

En el punto 2.4 se realizó una sencilla clasificación de estas

soluciones distinguiendo los esquemas con agentes de movilidad jerárquicos y esquemas de encaminamiento basado en host (HBR).

Los esquemas con agentes de movilidad jerárquicos no suelen

aportar soluciones específicas al proceso handover. Estos esquemas permiten la utilización dentro del dominio de cualquier solución compatible con el protocolo Mobile IP y, al describir posibles mejoras en las prestaciones del handover, hacen referencia a algoritmos ya existentes, como las soluciones presentadas en los puntos 4.4.1 y 4.4.2.

Por otro lado tenemos los esquemas HBR que, al utilizar

mecanismos de enrutamiento propios, ofrecen soluciones novedosas. Estos esquemas HBR van a ser, por lo general, muy rápidos, ya que el número de nodos implicados en el mismo es pequeño. En la figura 4.2 puede observarse un handover producido por el movimiento del MN que cambia de la estación base 1 (BS1) a la estación base 2 (BS2). El nodo marcado como X se denomina Nodo de Cruce y puede definirse como el nodo más bajo que es común entre las dos rutas de las BS al Router Raíz (RR) del dominio.

Genéricamente, en los esquemas HBR el handover comienza con

un mensaje de actualización de ruta que es enviado por el nodo móvil (MN) a través de la nueva estación base. Este mensaje viaja hacia el RR y logra que todos los routers situados por debajo del Nodo de Cruce introduzcan una nueva entrada en su tabla de enrutamiento por host relativa al MN, ya que estos no tienen información del mismo. El Nodo de Cruce ya posee


140

una entrada para ese nodo y simplemente modifica el interfaz para que, a partir de ese instante, los paquetes se encaminen hacia la nueva BS2. El paquete de actualización puede seguir hacia el RR pero ya no modificará ninguna tabla y no afectará a las prestaciones del handover.

Figura 4.2 Handover en un sistema de micro-movilidad HBR.

A pesar de que el handover en los sistemas de micro-movilidad

HBR es rápido, debido a que las actualizaciones se realizan a nivel local, es posible que se produzcan pérdidas de paquetes durante el mismo. Para eliminar estas pérdidas de paquetes y lograr un handover sin degradación (Seamless Handover) los diferentes sistemas de micromovilidad han propuesto distintos esquemas.

A continuación se van a presentar, muy brevemente, las propuestas

de los sistemas Cellular IP y HAWAII (ver puntos 2.4.1 y 2.4.2). Estos dos sistemas son los que más han trabajado el mecanismo de handover, y también los más referenciados en la actualidad. En el capítulo siguiente se realizará un estudio de las prestaciones de los mecanismos de handover presentados a continuación, que servirá como base para analizar las prestaciones de los mecanismos propuestos en el capítulo 6.

X

Router Raíz (RR) Router

Estación Base (BS)

Nodo móvil (MN)

BS1 BS2

Dominio HBR

Macro-Movilidad


141

El protocolo Cellular IP [CAM00] ofrece tres algoritmos diferentes para realizar el proceso de handover. Una primera solución, muy sencilla, es el denominado Handover Duro (Hard Handover) donde no se intenta garantizar la entrega de todos los paquetes. En este caso el nodo móvil escucha las señales de anuncio (beacons) de las distintas estaciones base y, en función de la potencia, decide cuando realizar el handover. Éste se traduce en el envío de un paquete de actualización de ruta, que se envía a través de la nueva estación base, y que sirve para crear entradas en las memorias de enrutamiento de los dispositivos que forman la ruta hacia la pasarela del dominio.

La segunda solución es un algoritmo adicional que mejora las

prestaciones durante el handover y que se denomina Handover Semi-suave (Semisoft Handover). Se basa en suponer que los nodos móviles pueden comunicarse con las dos estaciones base. El nodo móvil, antes de moverse a una nueva BS, se comunica con ella y le transmite un mensaje indicándole la intención de cambiarse. Este paquete viaja en sentido ascendente hasta que alcanza el Nodo de Cruce creando entradas en las tablas de enrutamiento de los elementos que atraviesa, de manera que se genera una nueva ruta llegar al nodo móvil. Sin embargo, el Nodo de Cruce no elimina la entrada anterior, de manera que el MN sigue recibiendo paquetes conectado a la BS antigua. Así, tras esperar un cierto tiempo, para asegurar que la nueva BS ha realizado la conexión, el MN inicia un handover tradicional. Durante un pequeño intervalo de tiempo las dos estaciones base reciben los paquetes dirigidos hacia el MN, minimizando la pérdida de los mismos. La figura 4.3 muestra claramente el proceso.

El problema de la solución anterior es que no todas las tecnologías

permiten que el MN pueda recibir simultáneamente información de dos BS. En [SHE01] se propone un tercer mecanismo, denominado Handover Indirecto, que permite mejorar las prestaciones aún cuando el nodo móvil sólo puede comunicarse con una estación. Ahora cuando el móvil decide realizar el handover envía un paquete especial a la oBS (ya que no puede comunicarse con la nueva). Este paquete contiene la dirección IP de la nueva estación base a la que se va mover el nodo móvil, de manera que puede ser enviado hasta ella. La nueve estación, nBS, crea un paquete de


142

actualización de ruta con la dirección del nodo móvil que se enviará hacia la red de manera similar al Handover Semi-suave. Esta propuesta es similar al mecanismo de handover de baja latencia por pre-registro estudiado en 4.4.2.

Figura 4.3 Señalización durante un handover Semi-suave de Cellular IP.

También el protocolo Hawai [RAM99] propone cuatro esquemas

diferentes para establecer la nueva ruta cuando ocurre un handover. Podemos agrupar estos esquemas en dos grandes tipos, basándonos en como se realiza la entrega de paquetes durante el handover: Un primer método, que se podría denominar ‘Por Redireccionamiento’ (Forwarding), consiste en retransmitir los paquetes desde la estación base antigua a la nueva. Aquí se contemplan dos posibilidades MSF y SSF. El segundo método se denomina esquema ‘Sin Redireccionamiento’ (Non Fordwarding), y consiste en que los paquetes son desviados en el punto de cruce. En este

MN oBS nBS Router Cruce

Beacon

Datos (Copia)

Datos

Datos

Paquete Actualización Ruta, S=1

Datos

Paquete Actualización Ruta, S=0


143

caso, y dependiendo de si el nodo móvil sólo puede escuchar y transmitir por una estación base o puede hacerlo con dos estaciones base simultáneamente, se establecen dos mecanismos diferentes, denominados MNF y UNF respectivamente.

A continuación se describen brevemente los cuatro esquemas

propuestos en la literatura:

• Envío por Múltiples Flujos (Múltiple Stream Forwarding, MSF): La estación base previa recibe un mensaje de handover y se comunica con la nueva para transmitirle los paquetes que pueda tener almacenados. Utilizando esta solución es posible que algunos paquetes lleguen desordenados, pues paquetes previos que redirecciona la BS antigua pueden llegar más tarde que paquetes más modernos que envía el Nodo de cruce.

• Envío por un Único Flujos (Single Stream Forwarding, SSF): Para solucionar el problema anterior se define una nueva solución basada en MSF pero más sofisticada. Ahora la BS antigua informa al Nodo de Cruce que ha acabado de enviar las tramas pendientes para que a partir de ese momento éste pueda enviar también tramas hacia la nueva BS. Para lograr esto las entradas para el encaminamiento de los routers incorporan un campo adicional que indica el interfaz por el que se recibe el paquete. El resultado práctico es un funcionamiento similar al comentado en el punto 4.4.1.

• Transmisión Unicast sin Redireccionamiento (Unicast Non-Forwarding, UNF): Ahora no contempla el reenvío de datos entre las dos BS. La solución minimiza las pérdidas durante el handover, ya que se plantea para redes como CDMA o WaveLAN en las que el MN es capaz de comunicarse con las dos BS simultáneamente. Adicionalmente se permite el envío de un mensaje a la BS anterior para indicarle que el nodo móvil ha cambiado de celda.

• Transmisión Multicast sin Redireccionamiento (Multicast Non-Forwarding, MNF): Esta solución resuelve el handover suave empleando un esquema denominado ‘dual-cast’ por el que, durante un


144

breve periodo de tiempo, el Nodo de Cruce transmite los paquetes dirigidos a al MN a ambas estaciones base.

Para finalizar es interesante comentar uno de los primeros trabajos

que aborda el proceso de handover en redes IP es [CAC96], que también se puede encuadrar en los sistemas de micro-movilidad. Aquí se presenta un mecanismo para el handover a nivel más bajo de la jerarquía (movimiento del MN entre Estaciones Base de la misma subred y conectadas por una red cableada rápida), mientras que se plantea la utilización de Mobile IP para los niveles más altos de la jerarquía.

El handover propuesto se basa en su sencillez y evita la utilización

de mecanismos de handover anticipados o transmisión multicast. Por el contrario se detalla un intercambio de paquetes entre el nodo móvil (quién inicia el proceso) y la nueva estación base, y de está con la estación base anterior. Debido a la simplicidad y a que el handover se produce dentro de una misma subred se logran retardos muy pequeños. Por último indicar que se ofrece la posibilidad de lograr un handover suave utilizando una retransmisión de paquetes utilizando pequeños buffers en las estaciones base. Conclusiones sobre el handover en sistemas de micro-movilidad

Como se ha comentado los sistemas de micro-movilidad ofrecen handovers rápidos al afectar solamente a un número limitado de nodos de la red. Para lograr que se realice de una forma suave, minimizando el número de paquetes se han ofrecido una serie de soluciones que podemos clasificar en dos grandes grupos. El primero sería los que realizan un reenvío de paquetes, produciéndose una comunicación entre las dos estaciones base. Esta solución, que hemos estudiado en el protocolo Hawaii, aparece en otros sistemas de micro-movilidad como el protocolo TORA (ver el punto 2.4.4). El planteamiento no es nuevo y ya lo hemos comentado en el punto 4.4.1. Además esta solución también ha sido planteada en otro tipo de redes como ATM [ENG95], o incluso dentro de una subred [CAC96]. La segunda solución aportada ha sido la de lograr una transmisión de los datos desde dos estaciones base de forma


145

simultanea. Esta opción se emplea en las soluciones multicast (ver 4.4.4), y también ha sido propuesta en redes ATM [RAM96]. Por último indicar que tan solo se ha encontrado un trabajo que intenta dar una visión de conjunto de los sistemas de micro-movilidad centrándose en los mecanismos de handover [CAM01]. Sin embargo, es importante comentar que los mecanismos de handover que intentan minimizar la latencia o la pérdida de paquetes están en investigación en estos momentos, y que en la actualidad algunas de las soluciones que se contemplaban en este trabajo han sido modificadas, reagrupadas o incluso descartadas.

4.4.4 Handovers basados en transmisión multicast

La utilización de las capacidades multicast va a facilitar la implementación de algoritmos de handover con bajos tiempos de latencia y sin pérdidas de paquetes (el denominado ‘Seamless Handover’).

La solución común de todos los trabajos que abordan la utilización

de transmisión multicast para mejorar las prestaciones del handover es el de lograr que las Estaciones Base (los Foreign Agent en Mobile IP) estén conectadas al árbol multicast cuando el nodo móvil comienza a depender de ella.

Un ejemplo de esta solución lo encontramos en [HEL00], donde se

sugiere la utilización de una ‘conexión avanzada al árbol multicast’ (Advanced Join). Como hemos comentado se pretende que la siguiente BS se conecte al árbol multicast antes de que el MN deje de comunicarse con la Estación Base previa. Aquí no se contempla el problema de que la estación reciba paquetes duplicados, ni como se inicia este mecanismo de conexión avanzada. Además, al no utilizar el Mobile IP (pues cada nodo tiene asignada una dirección multicast permanente, ver punto 2.5.1), y no necesitar de un mecanismo de registro con ningún HA, este método es


146

mucho más sencillo que el handover pre-registro [ELM02] estudiado anteriormente en el punto 4.4.2.

Otro ejemplo, mucho más referenciado, es el proyecto Daedalus

[SES97] (ver punto 2.5.2), donde también se define un mecanismo de handover que pretende reducir tanto el retardo como la pérdida de paquetes. En esta propuesta varias estaciones cercanas al móvil pueden conectarse al árbol multicast y comenzar a almacenar una pequeña cantidad de paquetes en memoria, aunque no las transmiten por el enlace inalámbrico. Así cuando se produce el handover se retransmitan las tramas almacenadas, de manera que se minimiza la pérdida de tramas. Como ya se comentó en el punto 4.4.1 el MN indica cuales son sus últimos paquetes recibidos, con el fin de evitar duplicaciones. Es importarte indicar que el modelo implementado permitía la comunicación de la estación móvil con todas las estaciones base implicadas en el proceso de handover, lo que permite algoritmos mucho más sencillos pero no siempre aplicables a todas los protocolos L2 inalámbricos existentes en la actualidad.

Por último estaría una solución más sencilla que sería el asignar

previamente un conjunto de estaciones base al árbol multicast de manera que el handover puede realizarse sin interrupciones debidas al nivel 3. Esta solución que se podría denominar Reserva Anticipada tiene el inconveniente de no aprovechar eficientemente los recursos, y para un funcionamiento correcto se debería tener información sobre las zonas que el nodo móvil va a visitar. Existen algunos trabajos sobre reservas anticipadas en entornos móviles [PAJ97]. Sin embargo éstos abordan el tema centrándose en la reserva de recursos para proporcionar QoS, y no desde el punto de vista del handover, ni utilizando las características de la transmisión multicast.


147

4.5 RESUMEN Y CONCLUSIONES DEL CAPÍTULO Hemos estudiado como el tiempo que dura el proceso de handover en las redes IP móviles puede separarse en tres componentes: retardo en la detección de movimiento, retardo de la obtención de una dirección temporal y retardo en el restablecimiento de la ruta. Teniendo en mente esta división temporal, podemos indicar que la latencia del handover que ofrece el protocolo Mobile IP puede ser inaceptable para aplicaciones, como las multimedia, que tienen restricciones temporales. Así, a continuación se muestra las contribuciones a los diferentes tiempos que genera el protocolo Mobile IP original:

• La detección del movimiento se realiza estudiando los mensajes de aviso que transmite el nuevo Foreign Agent. Esta recepción implica el desarrollo completo y previo de un handover de nivel dos (L2), independiente del protocolo Mobile IP. Desde el punto de vista del nivel de red, y con el fin de simplificar la clasificación de las soluciones, el tiempo de handover L2 puede incluirse en el tiempo de detección de movimiento. Así, la independencia y no cooperación de ambos procesos se traduce en un aumento de este retardo.

• Los protocolos de movilidad IP suelen basarse en la utilización, por parte del nodo móvil, de una dirección temporal. El protocolo Mobile IP ofrece dos variantes de este mecanismo: empleo de una dirección Care-of Address (CoA) perteneciente a un FA, o bien el empleo de una asignada personalmente al nodo, Co-located Care-of Address. En este segundo caso (única solución propuesta en MIPv6) es necesario un tiempo para la obtención de la dirección, por ejemplo, utilizando un servidor DHCP.

• En Mobile IP el MN debe indicar a su Home Agent su nueva dirección CoA, con el fin de éste redirija los datos hacia la nueva ubicación del nodo. Este tiempo aumenta de manera proporcional a la distancia existente entre la situación el nodo y su red original (HN).


148

Se han publicado numerosas propuestas que mejoran las prestaciones del handover presentado en Mobile IP. Estas propuestas intentan solucionar dos problemas diferenciados: por un lado reducir el elevado tiempo de latencia ya comentado. En una clasificación previa estas soluciones se han denominado ‘Handovers rápidos’. Por otro lado existe el problema de la pérdida de paquetes durante el proceso. Los mecanismos que intentan minimizar este inconveniente se denominan ‘Handovers suaves’. A continuación se resumen las soluciones aportadas a estos dos problemas.

Handovers Rápidos.

Existen múltiples soluciones que intentan reducir la latencia de handover que se produce en el protocolo Mobile IP. Con el fin de reducir el tiempo de detección de movimiento, se han presentado soluciones basadas en una cooperación entre el los niveles 2 y 3. Así mediante la utilización de ‘triggers’ se puede lograr, por ejemplo, que el handover L3 comience antes de concluir el de nivel 2. Adicionalmente, también podrían incluirse aquí todas las soluciones que mejoran las prestaciones de los handovers L2, como las que permiten una comunicación con los dos Puntos de Acceso simultáneamente. Un ejemplo sería la solución presentada en el protocolo de micro-movilidad Cellular IP bajo el nombre de handover semi-suave.

También el retardo de la obtención de una dirección temporal

puede disminuirse. Tanto los sistemas de micro-movilidad HBR, como los sistemas basados en la utilización de direcciones multicast, eliminan este retardo, al no cambiar de dirección mientras permanecen en el interior del dominio.

Quizás el mayor componente a la latencia del handover en el

protocolo Mobile IP es el retardo en el restablecimiento de la ruta, puesto que es directamente proporcional a la distancia entre la red original del nodo (Home Network, HN) y la situación actual del mismo. Con el objetivo de reducir este tiempo apareció la idea de dividir la red en dominios y el concepto de protocolos de micro-movilidad. Tanto los sistemas jerárquicos, como el Registro Regional, como los sistemas de Encaminamiento Basado


149

en Host (HBR), logran disminuir este retardo, ya que ahora los mensajes de registro sólo deben viajar hasta la raíz del dominio. En particular, los sistemas HBR son muy rápidos, ya que la información del handover sólo modificará tablas hasta el denominado Punto de Cruce. También los sistemas que utilizan direccionamiento multicast son particularmente rápidos, ya que el retardo se limita al tiempo necesario para que la nueva estación base se conecte al árbol multicast. Handovers Suaves.

Existe un problema diferente, pero no menos importante, al de intentar mejorar la latencia del handover del protocolo Mobile IP. El protocolo original no contempla ningún mecanismo para intentar disminuir la pérdida de paquetes durante el proceso de handover. Por ejemplo, los paquetes interceptados por el HA tras el nuevo registro son enviados al nuevo FA, y se asume que el nivel superior solucionará el problema de la pérdida de los paquetes que hasta ese momento van en tránsito hacia el FA antiguo.

El concepto de conseguir minimizar, o incluso eliminar, la pérdida

de paquetes durante el proceso de handover se conoce como ‘Handover Suave’, existiendo numerosos trabajos al respecto. De un estudio de estos trabajos se deducen, principalmente, dos posibles soluciones: La utilización de túneles para retransmitir los paquetes; y la transmisión simultánea a las dos Estaciones Base implicadas (transmisión dualcast).

La solución de emplear túneles se basa en una comunicación entre

los dos Foreign Agent implicados, de manera que el oFA le transmite al nFA los datagramas que no ha podido enviar al nodo móvil por haberse cambiado de subred. Además esta comunicación ofrece mejoras adicionales, como la liberación inmediata de los recursos consumidos por el nodo móvil en el FA antiguo, sin tener que esperar que expire el tiempo de vida del mensaje de registro. Ejemplos de trabajos que proponen esta solución son los relativos a la optimización de ruta, algunas soluciones del sistema de micro-movilidad HAWAII (MSF y SSF), o el handover suave [PER01] estudiado en el punto 4.4.1.


150

La solución anterior puede completarse, adicionalmente, con el almacenamiento, por parte del oFA, de los últimos paquetes que se han transmitido hacia el nodo móvil. De esta manera se rescatan los paquetes que, al ser ya enviados por el oFA, se habrían perdido.

La utilización de túneles entre Foreign Agents tiene el inconveniente

del retardo que éste provoca en los paquetes retransmitidos, y que en aplicaciones de tiempo real puede no ser aceptable.

Una segunda solución aportada por la bibliografía para lograr un

handover suave es la transmisión de los paquetes a las dos Estaciones Base de manera simultánea. Propuestas en este sentido pueden encontrarse en los sistemas de micro-movilidad Cellular IP (Handover Semi suave) y Hawai MNF, y en los sistemas basados en multicast.

Las prestaciones de esta última solución dependerán de la

capacidad del sistema para poder transmitir a la nueva Estación Base antes de que el nodo móvil pierda conexión con la previa. Una opción para lograr esto sería el empleo de los triggers ya comentados anteriormente. Evidentemente, si el nodo móvil dispone de la capacidad de comunicarse de manera simultánea con las dos Estaciones Base, el mecanismo se simplifica de manera considerable.

151

5. PRESTACIONES DEL HANDOVER EN REDES IP MÓVILES

5.1 INTRODUCCIÓN En el capítulo anterior se realizó una valoración cualitativa del

proceso de handover, concluyendo que el protocolo Mobile IP no ofrecía las prestaciones necesarias para las aplicaciones con requisitos temporales. Como solución se estudiaron un conjunto de variaciones, que han sido la base para el desarrollo de nuevos sistemas de micro-movilidad.

En este capítulo se va a completar el trabajo anterior, realizando un

estudio sobre las prestaciones del handover, tanto en el protocolo Mobile IP, como en algunos de los sistemas de micro-movilidad que se trataron anteriormente.

Tradicionalmente se citan tres técnicas diferentes de evaluación de

prestaciones [JAI91]: modelado analítico, simulación, y realización de mediciones, preferiblemente, sobre un sistema real implantado. La elección de una u otra técnica depende de una serie de factores que se pueden resumir en los siguientes puntos:

• Situación del sistema. Las mediciones sólo serán posibles si ya

existe algún sistema similar al de estudio. Así, si es un concepto nuevo sólo se puede usar el modelado analítico o la simulación. En el caso de los protocolos de movilidad IP existen, en la actualidad, distintos ‘drivers’ que implementan el protocolo Mobile IP. Por ejemplo, podemos destacar las versiones para Linux de la universidad de Stanford (MosquitoNet [MOS]), o la de los laboratorios de HP en Bristol [HP], la versión para BSD de la universidad de Portland [POR], o la de Sun Microsystem [SUN] para Solaris. Sin embargo algunos de los sistemas de micro-movilidad y la mayoría de las modificaciones para conseguir

Prestaciones del Handover en redes IP móviles

152

handovers rápidos que se estudiaron en el tema anterior se encuentran en fase de desarrollo y no existen implementaciones reales de los mismos.

• Nivel de detalle. El modelado analítico requiere unas suposiciones y simplificaciones que hacen que la precisión disminuya. En la simulación, por el contrario, la exactitud de las medidas dependerá del nivel de detalle con el que se ha implementado las simulaciones. La realización de medidas también tiene sus limitaciones, y la exactitud dependerá, tanto de los parámetros introducidos, como de la semejanza del banco de pruebas con el entorno real de utilización.

• El coste del proyecto y la disponibilidad de las herramientas necesarias. La toma de medida requiere equipos reales, instrumentos de mediada y tiempo. Es, normalmente, la más cara de las tres. La realización de simulaciones requiere la disponibilidad de herramientas de simulación, y conocimiento de lenguajes de simulación o programación. Por último, las medidas analíticas no requieren de equipos, pero si de suficientes conocimientos matemáticos.

• Credibilidad. La credibilidad de los resultados es mayor cuando se realizas medidas, ya que es mucho más fácil convencer a los demás si existen unas medidas reales. En este aspecto el modelado es el que peor se encuentra.

Recientemente se han presentado una serie de trabajos [BLO02],

[BLO03], [BLO03b] que realizan un estudio de las prestaciones de handover, por modelado analítico, de algunos de los mecanismos presentados en el capítulo anterior. Estos trabajos se utilizarán como base para realizar el modelado analítico de los mecanismos de handover de nuestro sistema de micro-movilidad que se presentarán en el próximo capítulo.

Sin embargo, en este capítulo nos hemos decantado por realizar un

estudio de prestaciones utilizando simulación. Esta técnica nos va a dar la oportunidad de comparar, de una manera homogénea, las prestaciones del


153

handover de distintos sistemas ya presentados. Así veremos las limitaciones del protocolo Mobile IP y las mejoras que ofrecen los sistemas de micro-movilidad. Con el fin de confrontar los valores así obtenidos, se ha desarrollado, adicionalmente, un banco de pruebas donde se estudiará con medidas reales las prestaciones del protocolo Mobile IP.

En el resto del presente capítulo se van a tratar los siguientes

puntos: A continuación, en este mismo punto de introducción, se va a comentar la herramienta de simulación seleccionada, así como la metodología de trabajo. En los puntos 5.2 a 5.4 se detalla el estudio que se ha realizado sobre el proceso de handover del protocolo Mobile IP. En el punto 5.5 se realiza el estudio del handover de alguno de los principales sistemas de micro-movilidad tratados anteriormente (Hawaii, Cellular IP y Sistema Jerárquico). Por último en 5.6 se evalúa el protocolo Mobile IP utilizando medidas reales.

5.1.1 Simulador de red NS-2 El simulador NS-2 [NS2] es una herramienta de simulación de

eventos discretos, centrada en la investigación de redes de computadores, que proporciona un gran soporte para el estudio de algoritmos de encaminamiento, protocolos multicast, variaciones del protocolo TCP, y de redes inalámbricas, incluyendo protocolos de encaminamiento en redes Ad hoc.

El simulador forma parte de un programa denominado VINT

(Virtual InterNetwork Testbed) realizado por el Instituto de Ciencias de la Información (ISI) de la Universidad del Sur de California (USC), en colaboración con XeroxParc, el laboratorio LBNL (Lawrence Berkeley National Laboratory) y la Universidad de California Berkeley (UCB). Actualmente, el simulador se encuentra patrocinado por la agencia DARPA y por la fundación NSF (National Science Foundation).


154

En la versión 2 del simulador NS, el núcleo del simulador se encuentra programado en C++, mientras que el interfaz de configuración emplea OTCL, una extensión del lenguaje TCL (Tool Command Language) pensada para la programación orientada a objetos.

La utilización de dos lenguajes diferentes (C++ y OTCL) permite

combinar la velocidad de ejecución propia de un programa compilado con la sencillez de OTCL. Así mediante OTCL es posible crear el interfaz de usuario de forma fácil e intuitiva, definir la topología de la red, configurar las fuentes y sumideros de tráfico, e invocar la simulación.

El simulador, como consecuencia, debe soportar una jerarquía de

clases en C++, o jerarquía compilada, y una jerarquía de clases equivalente en OTCL, o jerarquía interpretada. Cuando el usuario crea un nuevo objeto de simulación mediante el intérprete, este objeto es primeramente instanciado en OTCL y, posteriormente, reflejado por su correspondiente objeto en la clase compilada, que es la que interviene directamente en la ejecución. En [NS02] puede encontrarse más información sobre el funcionamiento del simulador.

Evidentemente existen más herramientas de simulación además de

NS-2. La elección de ésta, en detrimento de soluciones comerciales como Opnet [OPN], se ha realizado porque a nuestro entender ofrece las siguientes ventajas:

• Su código fuente es abierto, lo que facilita su depuración y la

ampliación a campos no contemplados actualmente en la herramienta. Es decir, permite el estudio del funcionamiento del simulador y la posibilidad de modificarlo para perfeccionarlo. Una de los principales inconvenientes que se ponen al desarrollo de estudios basados en la simulación es que los sistemas implementados no se ajustan completamente a la realidad. La forma directa de solucionar este problema es tener controlados todos los elementos que intervienen en la simulación, y el acceso al código es un elemento fundamental para este control.


155

• El carácter abierto del código se traduce en la existencia de numerosos grupos de investigación en todo el mundo que realizan trabajos con la herramienta (en la actualidad se calcula más de 10.000 usuarios en más de 1000 instituciones en 50 países). Esto, unido al carácter abierto y cooperante, permite compensar ciertas limitaciones, como falta de manuales o servicio de mantenimiento, que los paquetes comerciales no sufren.

• Su programación está orientada a objetos, lo que flexibiliza y simplifica la tarea de programación, tanto de su código fuente como de su interfaz.

• NS-2 está optimizado para el funcionamiento en sistemas operativos UNIX, incluyendo el popular LINUX. Existe, adicionalmente, una versión para los S.O. Windows.

• Su distribución es gratuita.

Sin embargo, la principal ventaja que aporta esta herramienta, y

que ha llevado a seleccionarla sin ningún lugar a dudas, ha sido que es la elegida por todos los grupos de investigación que actualmente trabajan en la simulación de protocolos de movilidad IP. Como principales ejemplos destacamos el grupo ‘Comet’ de la Universidad de Columbia [COM], el proyecto ‘Mobins2’ dirigido por el propio Charles E. Perkins [MOB] y, principalmente, el grupo ‘Monarch’ [MON] dirigido por D. Johnson, anteriormente situado en la Universidad de Carnegie Mellon y, actualmente, trasladado a la Universidad de Rice.

La utilización del simulador NS-2 trae consigo una serie de

limitaciones. La principal es que se trata de un producto que permanentemente se encuentra en fase de desarrollo, por lo que su código no está totalmente depurado, y aún existen multitud de pequeños errores en los códigos que forman el simulador. Además, la mayoría de las aportaciones de los diferentes centros de investigación están validadas sólo para una versión, y es probable que no funcionen de forma correcta con versiones anteriores o posteriores. Por último, al no ser un producto comercial la ayuda no está convenientemente desarrollada. Esto hace que,


156

aunque el desarrollo de pequeñas simulaciones con objetos ya existentes sea sencillo, la realización de simulaciones complejas como la implementación de nuevos protocolos sea complicada.

5.1.2 Metodología de trabajo Las simulaciones presentadas en este capítulo han sido realizadas con distintas versiones del simulador NS-2 [NS2]. En particular se han empleado la versión ns-2.1b6 bajo Sistema Operativo Linux (versión Red Hat 7.2), la versión ns-2.1b9a con Windows 2000, y la versión ns-2.26 bajo Cygwin [CYG]. La utilización de distintas versiones se ha debido a que diversos módulos utilizados sólo están validados para trabajar con una versión determinada. El simulador NS-2 necesita, obligatoriamente, la instalación de algunos componentes adicionales para poder trabajar. Por ejemplo, los componentes obligatorios para la última versión son: Tcl/Tk 8.3.2, otcl 1.0a8, TclCL 1.0b12. En el caso de utilizar Windows se necesita el compilador Visual C++. Además, existen algunos componentes opcionales como puede ser nam, xgraph, perl, tcl debugg, etc. Algunos de estos componentes no disponen de versión para Windows. Las simulaciones se diseñan en TCL, y es posible modificar los distintos módulos como agentes, enlaces o nodos, ya que el código es abierto y están programados en C++. Las modificaciones de estos módulos obligan a recompilar el simulador.

Una vez ejecutada la simulación se obtiene un fichero (con extensión 'tr') que contiene información de todos eventos que han sucedido en la red simulada. Así cada una de las trazas incluidas en este fichero ofrece información sobre el instante de tiempo en que ha ocurrido, sobre los nodos implicados, información sobre la trama MAC, sobre el paquete IP, e información adicional que depende del evento que se ha producido o del tipo de paquete del que se trata.


157

Debido a la complejidad, tamaño, y no homogeneidad del fichero de trazas es necesario procesarlo. Para ello se utilizan scrips realizados en lenguaje Perl (Practical Extraction and Report Language). La elección de este lenguaje se ha debido a que dispone de facilidades para procesar texto, que provienen de su origen como herramienta para la administración de sistemas UNIX. Otra de las ventajas que ofrece es que está disponible de manera gratuita para todos los sistemas operativos.

Por último, tras procesar los datos estos se representan utilizando el programa Matlab [MAT], disponible tanto para S.O. Windows como para Linux.

5.2 INTRODUCCIÓN AL ESTUDIO POR SIMULACIÓN DEL PROTOCOLO ‘MOBILE IP’ Se ha considerado interesante comenzar realizando un estudio de las prestaciones del esquema de handover presentado en el protocolo original Mobile IP. El fin es estudiar como las prestaciones que ofrece lo hace inservible para aplicaciones de tiempo real, como pueden ser aplicaciones multimedia.

Para realizar el estudio del protocolo Mobile IP se ha partido de las facilidades que ofrecen las últimas versiones del simulador NS-2 para trabajar con este protocolo. Desde la versión ns-2.1b6, de enero de 2000, el simulador incluye el modelo inalámbrico basado, fundamentalmente, en el trabajo desarrollado por el grupo Monarch [MON]. Este modulo ha sido ampliado con trabajos de diversas universidades, de manera que actualmente el simulador implementa el protocolo Mobile IP. Adicionalmente existe otra implementación desarrollada por el grupo ‘Mobins2’ [MOB]. Ésta última simplifica el enlace inalámbrico (y el protocolo de nivel dos WLAN) centrándose en el protocolo de nivel tres.

Con el fin de estudiar la pérdida de prestaciones que se produce cuando el Nodo Móvil se encuentra lejos de su Home Network, se han


158

planteado dos situaciones distintas, que serán detalladas en los siguientes puntos.

Además se han realizado estudios distinguiendo el tipo de tráfico,

bien si es sensible a la latencia, en cuyo caso se utiliza el protocolo UDP, bien si no es sensible a la latencia, pero si a la pérdida de información, utilizando en este caso el protocolo TCP.

Por último se han realizado distintas comparativas para estudiar la

posible mejora de prestaciones al implementar mecanismos blandos de handover ‘make-before-break’, en vez de mecanismos abruptos ‘break-before-make’, (ver punto 4.1).

5.3 ESTUDIO DEL HANDOVER CERCANO DEL PROTOCOLO MOBILE IP Para estudiar el proceso de handover cuando el nodo móvil se encuentra cerca de su Home Agent (HA) se ha implementado la situación que se muestra en la figura 5.1. En ella puede observarse las dos estaciones base que actúan como Home Agent y como Foreign Agent, y que incluyen un interfaz radio implementando el protocolo IEEE 802.11. Además, están conectadas entre si por medio de un router. Se han situado a una distancia lo suficientemente cercana para que las zonas de cobertura tengan cierto solape. El valor de este solape será configurado en las simulaciones.

Al nodo móvil se le ha asignado una dirección IP permanente perteneciente a la subred controlada por el Home Agent. Se ha configurado un movimiento como el indicado en la figura, de manera que se desplaza en dirección al Foreign Agent.

El Host que establece la comunicación con el nodo móvil también se encuentra conectado al router, por medio de un enlace con 20 mseg. de retardo. El valor de este retardo del enlace es un componente de la latencia


159

de transmisión de los paquetes pero no afecta, particularmente, a las prestaciones del handover analizadas.

A continuación se detallan los trabajos realizados para estudiar el comportamiento del handover tanto en aplicaciones basadas en el protocolo UDP como de aquellas que utilizan el protocolo TCP.

Figura 5.1 Configuración para estudiar el handover cercano en MIP.

5.3.1 Estudio del tráfico UDP en Handover Cercano Las aplicaciones multimedia en tiempo real, como videoconferencia o voz sobre IP, suelen tener restricciones temporales, de manera que los datos que se reciben con un retraso superior a una cota determinada son descartados. En estas aplicaciones se suele utilizar como protocolo de transporte UDP, que al ofrecer un servicio no confirmado funciona con menores retardos.

Router

Foreign Agent

Host

Home Agent

Nodo Móvil

5 Mbps

5 Mbps

IEEE 802.11b

5 Mbps


160

Para analizar estas situaciones se ha conectado un agente UDP al Host fijo. Sobre este agente se ha instalado un generador de tráfico CBR. Los mensajes UDP tienen un tamaño constante de 500 bytes y se va a modificar el tiempo entre los mismos. Los paquetes IP son dirigidos hacia el nodo móvil. Handover ‘Break before Make’

El estudio comienza con un análisis del handover abrupto (‘Break before Make’) donde una vez el nodo móvil (MH) no puede recibir de dos puntos de acceso simultáneamente. Así cuando se realiza la conexión con el Foreign Agent se deja de recibir tramas de la estación base anterior.

En la figura 5.2 se observa el número de paquetes perdidos durante

este handover en función de la tasa del generador CBR. Se han tomado valores entre 80Kbps y 2Mbps para abarcar todo el rango de aplicaciones multimedia [BHA95]. Cada medida se ha realizado en 100 ocasiones utilizando diferentes semillas.

Figura 5.2 Estudio de segmentos UDP perdidos en el protocolo MIP.


161

En la gráfica se ha incluido la recta de mínimos cuadrados, que ayuda a comprobar como el número de paquetes perdidos aumenta directamente con la tasa. Este aumento lineal es debido a que no existe carga adicional en la red, y que por tanto las colas de los diferentes nodos, en especial la de las estaciones base, están vacías. De esta manera no se va a producir una pérdida de los paquetes que estuvieran almacenados en dichas colas, a la espera de una posterior transmisión por el medio inalámbrico.

El bajo número de paquetes perdidos es debido a la proximidad

entre las dos estaciones implicadas en el handover (Home Agent y Foreign Agent.). Se ha realizado un estudio del tiempo de handover de nivel tres tomando la diferencia entre el instante de tiempo en que el Foreign Agent envía el mensaje Agent Advertisement y el instante en que el Nodo Móvil recibe finalmente el mensaje Registration Reply. El valor medio resultante de analizar más de 500 procesos de handover ha dado un valor de 16.99 mseg, con un coeficiente de variación CV = 0.16. En la figura 5.3 puede observarse gráficamente el valor empleado como medida del tiempo de handover.

Figura 5.3 Handover L3 empleado.

MN FA HA

Registration Request Registration Request

Paquete vía HA

Registration Reply

Registration Reply

Agent Advertisement

Paquete vía FA

Tiem

po M

edid

o


162

Por último se ha medido el tiempo existente entre el último paquete recibido vía el Home Agent y el primero que se ha recibido utilizando el Foreign Agent una vez ha terminado el proceso de handover. En la figura 5.4 puede observarse estos tiempos utilizando como base la tasa de transmisión CBR.

Figura 5.4 Tiempo en mseg. entre paquetes durante el handover.

Puede observarse como con tasas de transmisión bajas se obtienen

retardos elevados, que dependen directamente del tiempo entre transmisión de tramas. Por ejemplo, una tasa de 80Kbps, que se corresponde con un tiempo de generación de paquetes de 50 mseg, provoca un retardo medio entre el último paquete enviado directamente a través del HA y el primero enviado utilizando el FA de 71 mseg. Este valor es debido a que el handover a esta tasa producía una pérdida media de 0.31 paquetes (figura 5.2), y que la pérdida de un paquete provocará un tiempo mínimo de 100 mseg.

Sin embargo, a medida que la tasa aumenta y, por tanto, el tiempo

entre paquetes enviados disminuye, este factor deja de ser tan determinante, y se tiende a un valor cercano a los 22 mseg. Este tiempo


163

puede ser estudiado como la suma de dos hechos diferenciados. Por un lado se tiene el tiempo debido al intercambio de mensajes de señalización del protocolo Mobile IP durante el handover (los 16.99 mseg. de media que hemos comentado anteriormente). Por otro lado hay que tener en cuenta el tiempo necesario en reenviar ese primer paquete desde el HA hacia el FA (figura 5.1).

La figura 5.5 muestra la temporización de los eventos que se producen durante un handover cercano. Las tres subfiguras muestran el comportamiento en función de la tasa: 80, 800 y 2000 Kbps. En las figuras se muestra el instante de tiempo cuando se transmite el paquetes desde el host, los instantes de tiempo en que dichos paquetes son recibidos por el nodo móvil, ya sea desde HA como de FA, así como los paquetes que no son recibidos por tratarse de un handover abrupto, en el que el nodo móvil no puede comunicase con dos estaciones base de manera simultánea.

El estudio de estas figuras corrobora lo indicado anteriormente: el número de paquetes perdidos aumenta con la carga, y los paquetes que se reciben vía FA sufren un mayor retardo. El tiempo transcurrido desde el inicio de handover a nivel 3 hasta que el proceso se da por finalizado está en torno a los 17 mseg, comentados anteriormente.


164

Figura 5.5 Eventos en handover con protocolo de transporte UDP a diferentes

tasas: 80, 800 y 2000 Kbps.

Con respecto al tiempo entre el último paquete recibido vía HA y el

primero recibido por el FA, las diferentes gráficas de la figura 5.5 muestran como al aumentar la tasa este tiempo tiende a estabilizarse en valores ligeramente superiores a 22 mseg. De la misma manera los segmentos UDP perdidos (marcados en rojo en las figuras) concuerdan con los valores medios mostrados en la figura 5.2.


165

Handover ‘Make Before Break’

Adicionalmente se han realizado un conjunto de simulaciones para estudiar la mejora en las prestaciones de handover cuando el Nodo Móvil es capaz de comunicarse simultáneamente con las dos Estaciones Base. Este tipo de handover se denomina ‘Make Before Break’ (también llamado ‘handover blando’ en diferente bibliografía), y va a permitir la recepción de paquetes vía la Estación Base previa, en este caso el HA, mientras se produce el intercambio de mensajes del protocolo Mobile IP entre el nuevo FA y el Nodo Móvil. El factor determinante en este tipo de handover será la zona de solape entre las coberturas de las dos Estaciones Base. Para establecer dicha cobertura es necesario la configuración de algunos parámetros, tanto en las estaciones como en el nodo móvil. En concreto, se ha definido la utilización de antenas omnidireccionales, el uso del modelo de propagación radio de dos rayos sobre tierra plana, una potencia en transmisión de 0.282 W, y un límite en recepción de 3.652e-10 W.

Figura 5.6 Movimiento del Nodo Móvil entre las dos celdas.

Zona de solape 20m

Home Agent Foreign Agent

Router

V m/s 250 m


166

Se ha realizado un estudio previo y estos valores de configuración dan como resultado una distancia máxima de 250 metros. En la figura 5.6 puede observarse como las Estaciones Base (HA y FA) se han separado una distancia de 480 metros de manera que la zona de solape es de 20 metros en la recta que une ambas estaciones. El número de paquetes perdidos está directamente relacionado con el tiempo en que el Nodo Móvil permanece dentro de la zona de influencia de las dos estaciones. Este tiempo de permanencia depende del tamaño de la zona, que, como ya se ha comentado, es de 20 metros en la dirección de desplazamiento del móvil, y de la velocidad de desplazamiento del mismo. Se ha tomado como posibles velocidades 10, 20 y 30 metros por segundo. Al igual que en casos anteriores se han realizado múltiples medidas con diferentes semillas. Todas las simulaciones realizadas (más de 100) con distintas tasas CBR y el móvil desplazándose a 10 o a 20 m/seg. han dado como resultado la entrega de todos los paquetes. El motivo de que no se pierda ningún paquete es que el móvil va a estar en la zona de solape uno o dos segundos, dependiendo de la velocidad empleada. En [RFC 3344] se indica que el Foreign Agent debe enviar mensajes Agent Advertisement a una velocidad de uno por segundo, por lo que el nodo móvil siempre recibirá como mínimo uno de estos mensajes y podrá lanzar el proceso de handover mientras está en la zona de solape. Como el Foreign Agent está muy cerca del Home Agent, el envío del mensaje Registration Request desde el FA hacia el HA no dura más de 6-8 mseg y, por tanto, la única posibilidad de que se pierdan paquetes sería que el Nodo Móvil perdiera la cobertura del HA durante ese tiempo. La probabilidad de que suceda esto sería aproximadamente de 8/1000 en el caso de una velocidad de desplazamiento de 20 m/seg. En el caso de una velocidad de 10 m/seg. se recibirán dos mensajes de aviso durante la estancia del Nodo Móvil en la zona de solape, y por tanto la probabilidad de pérdida es nula. La figura 5.7 muestra una gráfica donde aparecen los paquetes perdidos cuando el Nodo Móvil se desplaza por la recta que une ambas estaciones a una velocidad de 30 m/seg. Al igual que la figura 5.2 se toma


167

como base la tasa de paquetes de tráfico CBR. Cada punto de la figura se ha obtenido a partir de 100 simulaciones independientes.

Figura 5.7 Paquetes perdidos con MH a 30 m/s y zona de solape de 20 metros.

Debido a la elevada velocidad del móvil, el tiempo que éste

permanece en la zona de solape (666 mseg.) es menor que el tiempo entre mensajes ‘Agent Advertisement’ enviados por el FA. Por tanto existe la posibilidad de que el nodo reciba este mensaje cuando ya ha dejado la zona de solape y se ha adentrado en la zona de cobertura exclusiva de FA. Evidentemente este hecho provoca una pérdida de los paquetes que el Home Agent ha enviado directamente a su interfaz radio, a causa de no haber recibido aún ningún mensaje de registro y desconocer la nueva situación del móvil. Como se vio en el punto 4.3 una solución sería realizar una cooperación entre la capa dos y tres, de manera que se pudiera forzar el envío de un mensaje Agent Solicitation por parte del MH.


168

5.3.2 Estudio del tráfico TCP en Handover Cercano Se han realizado una serie de estudios para comprobar como el proceso de handover de Mobile IP degrada de las prestaciones del protocolo TCP. Para ello se ha utilizado el mismo sistema que el mostrado en la figura 5.1.

En este caso se ha sustituido el agente UDP del host fijo por uno TCP. El simulador nos ofrece distintas versiones del protocolo TCP. Debido a que para nuestro estudio no es excesivamente relevante el uso de una versión u otra, nos hemos decantado por una de las últimas versiones, TCP Vegas [BRA94], que modifica el control de congestión del emisor para adaptarse de manera eficiente a la capacidad de la red disponible. El emisor transmite segmentos de datos con tamaño fijo de 1020 Bytes (incluyendo la cabecera TCP de 20 Bytes). Sobre este agente se ha instalado una aplicación FTP que va a estar activa mientras se produce el proceso de handover. Handover ‘Break before Make’

El estudio comienza con un análisis del handover abrupto (‘Break before Make’) donde una vez el nodo móvil (MH) no puede recibir de dos puntos de acceso simultáneamente. Así cuando se realiza la conexión con el Foreign Agent se deja de recibir tramas de la estación base anterior.

La figura 5.8 muestra los paquetes transmitidos y recibidos

durante un proceso de handover, así como el instante en el que el FA envía el mensaje ‘Agent Advertisement’ y el instante en el que el mensaje ‘Registration Reply’ llega al nodo móvil. Como vemos, a partir del momento en el que el MN pierde la conexión con HA se produce una pérdida temporal de paquetes, que no volverán a retransmitirse hasta que no pase un periodo de ‘time-out’ de aproximadamente un segundo. El mensaje de anuncio desde FA se envía con una periodicidad de un segundo [RFC


169

3344], y por tanto, el nodo móvil tiene tiempo suficiente para registrarse antes de reenvío de los paquetes.

La retransmisión de paquetes perdidos se produce por el

mecanismo de ‘Slow Start’. Así la ventana de transmisión empieza siendo pequeña (2 paquetes) y cada dos transmisiones correctas se duplica, hasta alcanzar el máximo de transmisión.

Figura 5.8 Handover abrupto durante una transmisión TCP.

La figura 5.9 muestra el caudal recibido (‘throughput’) por el nodo

móvil durante el handover. La parte de la izquierda de la gráfica muestra el ‘throughput’ antes del handover, cuando los datos se reciben directamente desde el HA. Tras el handover este valor baja desde 350 Kbps. hasta un valor de 150 Kbps. Esta disminución se debe, además de por los mecanismos de control de congestión y arranque lento, al hecho de que los paquetes viajan desde el nodo que transmite hacia el HA y luego son redirigidos, por el mismo enlace hacia el FA para su transmisión hacia el MN. Esto provoca primero que el enlace entre el router y el HA soporte el doble de tráfico, y segundo a que el retardo total de la ruta CN-MN


170

aumenta de manera que el mecanismo de control de flujo del TCP se ralentiza.

Figura 5.9 ‘Throughput’ en bytes/seg. un handover abrupto cercano.

Handover ‘Make Before Break’

Hemos realizado un conjunto de simulaciones para estudiar la mejora en las prestaciones de handover cuando el Nodo Móvil es capaz de comunicarse simultáneamente con las dos Estaciones Base. Así se permite la recepción de paquetes vía la Estación Base previa (en este caso el HA) mientras se produce el intercambio de mensajes del protocolo Mobile IP entre el nuevo FA y el Nodo Móvil.

Como en los estudios realizados con la transmisión UDP, el factor

determinante en al pérdida de paquetes será el tiempo que el nodo móvil permanece en la zona de solape. En nuestros estudios las estaciones base se han separado una distancia de 480 y de 470 metros. De esta manera la zona de solape es, en la recta que une ambas estaciones y por la que va a


171

moverse el MN, de 20 y 30 metros respectivamente. Se han tomado, como posibles velocidades del nodo móvil, 20 y 30 metros por segundo.

La figura 5.10 muestra como se transmiten y reciben los paquetes

cuando el MN se mueve a una velocidad relativamente baja de 20m/s con una zona de cobertura común de 30 metros. Puede observarse como la transmisión es perfectamente fluida y no se produce ninguna retransmisión de segmentos por parte del CN.

Figura 5.10 Handover blando durante una transmisión TCP.

Como se estudió anteriormente, esta relación velocidad del MN

tamaño de la zona de cobertura nos da un tiempo de permanencia en dicha zona superior a un segundo. Así el nodo recibirá, al menos, un mensaje ‘Agent Advertisement’ que permitirá registrarse con la nueva estación base mientras se encuentra en la zona de cobertura de HA y sigue manteniendo comunicación con ella.

La figura muestra como un paquete (numerado en al simulación

como 3066) ha sido entregado vía HA cuando ya se ha completado el registro con la nueva estación base (FA). Esto ha ocurrido porque el


172

paquete fue enviado antes de que llegara el mensaje de registro al HA y porque además el nodo móvil sigue en la zona de solape lo que permite su recepción.

Para realizar la figura 5.11 se ha modificado la velocidad de

desplazamiento del MN (ahora 30m/seg.) y el área de solape de las estaciones base (20 metros), de nabera que ahora el tiempo de permanencia del nodo es tan solo de 666 mseg. Como se mencionó en el apartado dedicado al UDP (5.3.1) esto provoca una cierta probabilidad de que el proceso de handover se realice total o parcialmente fuera de la zona de solape.

Figura 5.11Handover blando rápido durante una transmisión TCP.

La figura muestra como los paquetes numerados a partir el 2067, y

que fueron transmitidos por el CN en los instantes cercanos a 58.3, no fueron recibidos por el nodo móvil, ya que éste abandonó la zona de cobertura del HA. Mientras el nodo transmisor espera el reconocimiento de estos paquetes el nodo móvil recibe el mensaje ‘Agent Advertisement’ y procede a implementar el handover según el protocolo Mobile IP. Tras vencer el temporizador de retransmisión el protocolo TCP reenviará estos


173

paquetes, que alcanzarán finalmente al modo móvil vía la nueva estación base.

Es interesante destacar lo sucedido con los paquetes 2065 y 2066.

Estos paquetes fueron correctamente recibidos por el nodo móvil pero la confirmación positiva no llegó al CN ya que el nodo había abandonado la zona de cobertura del HA. Como puede observarse esto ha provocado una retransmisión innecesaria de los mismos y una ligera pérdida de prestaciones.

5.3.3 Conclusiones sobre el Handover Cercano

Tras el estudio de las prestaciones del mecanismo de handover especificado por el protocolo Mobile IP, podemos observar que el comportamiento es correcto cuando el handover se produce cerca de la red original del nodo móvil. En particular en este estudio se ha llevado el caso al límite produciendo el handover desde esta misma estación base a un ‘Foreig Agent’ adyacente.

El estudio de aplicaciones que se basan en el protocolo de

transporte UDP muestra que el número de paquetes perdidos es mínimo, incluso en el caso de trabajar sobre un handover abrupto que no permite una comunicación simultánea con las dos estaciones base. En esta situación se logra un tiempo de handover entre 16 y 17 mseg. perfectamente asumible por la mayoría de las aplicaciones multimedia.

Es destacable el hecho de que en handovers blandos la pérdida de

paquetes es nula a no ser que se fuerce el protocolo hasta puntos en los que el nodo móvil permanece menos del tiempo en la zona de solape que el tiempo existente entre mensajes ‘Agent Advertisement’. Ante esta situación el protocolo perderá paquetes de manera proporcional a la tasa (figura 5.7). Unas posible solución a esta circunstancia sería una disminución del tiempo entre envío de estos mensajes de anuncio o bien una comunicación entre la capa dos y tres para forzar este envío.


174

También las aplicaciones que trabajan sobre TCP tienen un funcionamiento relativamente correcto. Si trabajamos con redes que ofrecen un handover abrupto la pérdida de conexión provoca una retransmisión de paquetes. El protocolo TCP supone que el vencimiento de temporizadores de retransmisión se debe a que la red está congestionada por lo que se lanza el mecanismo de ‘arranque lento’ (fig. 5.8). En todo caso el número máximo de retransmisiones debidas al handover será de una.

En el caso de trabajar con handovers blandos, el comportamiento

es excelente cuando el tiempo de permanencia es suficiente para la recepción de los mensajes de anuncio y el desarrollo del handover. Si disminuimos considerablemente este tiempo de permanencia el comportamiento es similar al del handover abrupto, produciéndose errores en la recepción de segmentos TCP que serán retransmitidos tras el vencimiento del temporizador correspondiente.

5.4 ESTUDIO DEL HANDOVER LEJANO DEL PROTOCOLO ‘MOBILE IP’ Los resultados, razonablemente satisfactorios, obtenidos en el punto anterior están condicionados a la proximidad entre el Home Agent y el Foreign Agent destino del nodo móvil. En particular esto se ha llevado al extremo pues, una de las dos estaciones base implicadas en el handover es el propio HA. Sin embargo hay ocasiones en las que el nodo móvil se encontrará situado lejos de su Home Agent, y en estos casos el protocolo Mobile IP va a ofrecer unas prestaciones muy deficientes. Como ya se ha estudiado, el motivo fundamental de esto es que cada proceso de handover, independientemente de la frecuencia con que se produzca, implica un envío de mensajes de registro hacia el HA. En este punto va a realizarse un estudio de prestaciones del protocolo cuando el nodo móvil se encuentra alejado del HA. La implementación realizada se muestra en la figura 5.12. En ella puede


175

observarse como el nodo móvil realiza un handover entre dos estaciones lo suficientemente cercanas entre si para que exista solape de coberturas, pero alejados del HA. En particular se han realizado mediciones con distintos retardos entre el router que da conectividad a las estaciones base y el Home Agent.

A continuación se detallan los trabajos realizados para estudiar el

comportamiento del handover, tanto en aplicaciones basadas en el protocolo UDP, como de aquellas que utilizan el protocolo TCP.

Figura 5.12 Configuración para estudiar el handover lejano en MIP.

5.4.1 Estudio del tráfico UDP en Handover Lejano Con el fin de poder comparar los resultados con los obtenidos en el estudio del handover cercano se han mantenido las condiciones de contorno. Es decir, se ha conectado un agente UDP al Host fijo de la

Router

Foreign Agent 2

Host

Foreign Agent 1

Nodo Móvil

5 Mbps 2 ms

5 Mbps 20ms

5 Mbps 2 ms

Home Agent

Retardo variable


176

figura, sobre el que se ha instalado un generador CBR con tamaño de paquete fijo igual a 500 bytes, modificándose el tiempo entre los mismos. Handover ‘Break before Make’

En la figura siguiente se muestra el número de paquetes perdidos durante un handover abrupto, donde el nodo móvil no es capaz de comunicarse simultáneamente con las dos estaciones base. Se han realizado distintas simulaciones variando el retardo entre el Home Agent y el router que da conectividad a las Estaciones Base implicadas en el handover. Las variaciones en este retardo han ido desde 60 mseg. a 300, pasando por 120 y 180 mseg. Cada valor de la gráfica es el resultado de 100 simulaciones con distintas semillas, obteniéndose siempre un coeficiente de variación CV menor que 0.06.

Figura 5.13 Estudio de segmentos UDP perdidos en un handover abrupto lejano.

Puede observarse como el número de paquetes perdidos crece de

manera lineal a la tasa y a la distancia en la que se encuentra el Home


177

Agent. El primer factor mencionado, la tasa, ya fue detallado cuando se estudió el handover cercano. Durante el tiempo de handover el nodo móvil no puede recibir paquetes ya que estamos ante un handover abrupto. El número de paquetes perdidos (suponiendo las colas vacías) será los trasmitidos en ese tiempo, lo que evidentemente depende directamente de la tasa a la que se transmite. La dependencia del número de paquetes perdidos con la distancia del HA también es directa. El tiempo de handover de capa tres, calculado como la diferencia entre el tiempo en que se envía el Agent Advertisement y el instante en que el Nodo Móvil recibe el mensaje Registration Reply (ver figura 5.3), aumenta a medida que el HA se encuentra más alejado del FA que recibe al nodo móvil. En la tabla 5.1 se muestran los tiempos medios de handover para las cuatro situaciones de la tabla 5.13. Cada uno de los valores se ha realizado a partir de 100 simulaciones.

Distancia del Home

Agent

Tiempo medio de

Handover

60 mseg. 134.52 mseg.

120 mseg. 254.38 mseg.

180 mseg. 374.37 mseg.

300 mseg. 614.37 mseg

Tabla 5.1 Tiempo de Handover.

En la gráfica 5.14 se observa el tiempo existente entre el último

paquete recibido vía el Foreign Agent 1 y el primero que se ha recibido utilizando el Foreign Agent 2 una vez ha terminado el proceso de handover.

Como hemos demostrado anteriormente este tiempo medio depende de dos factores, la tasa de transmisión y el tiempo medio de handover. En tasas de transmisión bajas se observa retardos ligeramente más elevados. Por ejemplo la simulación con 60mseg. de retardo a una tasa de 80 Kbps.


178

provoca un tiempo entre paquetes de 18 mseg. Este valor lo podemos entender como la suma de dos factores, el primero el tiempo de generación del paquete (50 mseg), el segundo el provocado por la pérdida de paquetes, que en este caso este caso es, según la figura 5.13 de 2.71 paquetes.

Figura 5.14 Tiempo en mseg. entre paquetes durante el handover.

A medida que la tasa aumenta las gráficas se estabilizan. Por ejemplo, la del retardo de 60 mseg. tiende a un tiempo medio de 140 mseg. Ahora el tiempo entre paquetes deja de ser tan determinante, y el valor al que se tiende es debido, fundamentalmente, al tiempo de intercambio de mensajes de señalización del protocolo ‘Mobile IP’ durante el handover (134.52 mseg. según la tabla 5.1). La diferencia entre los dos valores es porque hay que tener en cuenta el tiempo necesario para enviar el primer paquete vía FA2. La figura 5.15 muestra la temporización secuencia de mensajes de señalización del proceso de handover. En este caso la tasa es de 800 Kbps. y se muestra el comportamiento para retardos de 60, 180 y 300 mseg.


179

Figura 5.15 Eventos en un Handover lejano con tasa 800Kbps y distintos retardos.


180

Las figuras anteriores muestran claramente como, al aumentar el retardo entre el HA y la zona donde se produce el handover, el intercambio de mensajes del protocolo Mobile IP se alarga en el tiempo aumentando de manera alarmante el número de paquetes perdidos, aunque la tasa de transmisión se mantiene constante. También puede comprobarse la variación del retardo entre la transmisión desde el CN y recepción final por el nodo móvil. Hay que indicar que los mensajes marcado en rojo nunca llegan al receptor, y que se han incluido en la gráfica simplemente por claridad. La figura 5.16 muestra la temporización de los mensajes cuando variamos la tasa de transmisión (400 y 1600 Kbps) manteniendo constante el resto de parámetros.

Figura 5.16 a. Eventos en un Handover lejano con retardo 120mseg y 400 Kbps.


181

Figura 5.16 b. Eventos en un Handover lejano con retardo 120mseg y 1600 Kbps.

La figura anterior muestra claramente que el número de paquetes perdidos aumenta linealmente con la tasa, siendo el tiempo de realización del handover constante en torno a los 250 mseg. Handover ‘Make before Break’

Tras comprobar el empeoramiento de los resultados en el handover lejano respecto del handover cercano, pasamos a utilizar una posible solución para mejorar estas prestaciones. Realizamos un estudio sobre la utilización de un handover blando que permitirá, como se ha visto anteriormente, la conexión del nodo móvil con más de una estación base simultáneamente. Para comparar resultados hemos utilizado los mismos parámetros empleados anteriormente en las simulaciones. En la figura 5.17 hemos simulado la situación en la cual el nodo móvil se desplazaba a 20 m/seg. a través de una zona de solape de 30m. La gráfica se ha obtenido a partir de 100 simulaciones.


182

Figura 5.17: Paquetes perdidos con 300 ms de retardo, 20 m/s y 30 m de solape.

A pesar de que el nuevo Foreign Agent envía un mensaje ‘Agent Advertisement’ cada segundo, y que en este caso el nodo móvil tarda 1.5 segundos en atravesar la zona de solape se producen pérdidas de paquetes. El motivo es el tiempo necesario para realizar el registro, que para este retardo está en torno a los 614 mseg. Existe una probabilidad de que el nodo móvil reciba el mensaje de anuncio en un instante de tiempo en el que no puede completarse el registro dentro de la zona de solape. Con los valores anteriores esta probabilidad se sitúa en torno al 7.6 %. Sin embargo, comparando está gráfica con la obtenida en caso de handover abrupto (figura 5.13), puede deducirse que la mejora es muy significativa. En la siguiente figura 5.18 variamos las condiciones de la simulación. Ahora el nodo móvil se desplaza a una velocidad de 30 m/s a través de una zona de solape de 20 m, por lo que sólo permanecerá 666 mseg. en el área de solape. Esta situación provoca que, aunque se utilice handover blando, siga habiendo una pérdida de paquetes. El escaso tiempo de permanencia en la zona de solape unido al retardo entre el Home Agent y las estaciones


183

base, provoca que las pérdidas no disminuyan tanto con respecto al handover abrupto como el caso anterior, obteniendo reducciones alrededor del 35.8 % para retardos elevados, 180 mseg. y 300 mseg., y del 40 % para retardos de 60 mseg. y 120 mseg.

Figura 5.18: Paquetes perdidos a 30 m/s con 20 m de solape.

5.4.2 Estudio del tráfico TCP en Handover Lejano En el siguiente punto se describe los trabajos realizados para estudiar el comportamiento de las aplicaciones que funcionan sobre TCP, en el caso de que se produzca un handover lejano. El sistema simulado es el mismo que se mostró en la figura 5.12. Con respecto al trabajo presentado en el punto anterior simplemente se ha sustituido los agentes UDP por agentes TCP Vegas. Sobre el agente del nodo transmisor se ha instalado una aplicación FTP que estará activa mientras se produzca el proceso de handover.


184

Handover ‘Break before Make’ Como en los estudios anteriores comenzamos estudiando el comportamiento durante un handover abrupto. Se han realizado dos grupos de simulaciones variando el retardo existente entre el Home Agent y el router que enlaza a los Foreign Agent que van a dar conectividad al nodo móvil. La figura 5.19 muestra los mensajes de señalización y los paquetes transmitidos y recibidos durante un handover abrupto, cuando el retardo entre el Home Agent y el router que conecta a los FA es de 60 mseg.

Figura 5.19 Handover abrupto lejano (60mseg) durante una transmisión TCP.

En la gráfica puede observarse el retardo entre la transmisión y la

recepción de los segmentos, y la interrupción que produce el transmisor tras el paquete 1612 debido al tamaño de la ventana de transmisión. Al igual que ocurría en el handover cercano (figura 5.8), el intercambio de mensajes del protocolo Mobile IP se produce durante el tiempo de espera de retransmisión del protocolo TCP. Una vez el nodo móvil ha recuperado la conexión vía FA2, comienza a recibir los segmentos reenviados por el


185

transmisor utilizando el conocido mecanismo de ‘arranque lento’, claramente visible en la parte derecha de al figura.

La figura 5.20 muestra el ‘throughput’ medido en el receptor

durante el handover. Observamos como disminuye y se recupera tras el proceso volviendo a alcanzar los valores previos, esta vez recibiendo desde FA2. La diferencia de valores ante y después del handover que observamos en el handover cercano (figura 5.9) no se muestra aquí, ya que las rutas CN-HA-FA1 y CN-HA-FA2 son idénticas (figura 5.12).

Figura 5.20. ‘Throughput’ en bytes/seg. en un handover abrupto lejano (60 mseg.)

Para finalizar repetimos las simulaciones aumentando el retardo entre el HA y la zona del handover a 300 mseg. La figura 5.21 muestra los resultados donde apreciamos diferencia del aumento de tiempo entre transmisión y recepción de los paquetes que pasa a ser de poco más de 620 mseg. Esta circunstancia provoca que el registro con el nuevo ‘Foreign Agent’ no se efectúe dentro del tiempo de ‘time out’ que espera el transmisor para reenviar por primera vez los paquetes no reconocidos.


186


Figura 5.22 Ampliación de la figura 5.21.

En la figura 5.22 se muestra ampliado el intercambio de mensajes

que se produce en el handover de la figura 5.21. Como se aprecia, el


187

mensaje ‘Agent Advertisement’ de FA2 se recibe después de finalizar el primer ‘Time Out’, lo que provoca la espera de un segundo tiempo de retransmisión, que en este caso es de dos segundos. Podemos indicar que estamos ante la peor situación pues han pasado tres segundos desde el envío del último paquete recibido antes del handover y la recepción del primer segmento vía FA2. En el otro extremo tenemos la figura 7.23 donde el mensaje de anuncio de FA2 se recibe prácticamente después de que el nodo móvil abandona la zona de cobertura de FA1. Esto permite que el registro se realice mientras CN espera el primer ‘Time Out’ agilizándose todo el proceso.


Situación óptima.

Las figura 5.24 y 5.25 muestran el ‘throughput’ de las simulaciones

que se han mostrado anteriormente (fig. 5.21 y 5.23 respectivamente). En ellas se observa la disminución debida al handover y como se va recuperando lentamente a causa del mecanismo de inicio lento.


188

Figura 5.24. ‘Throughput’ en un handover abrupto lejano (300 mseg.) con TCP.

Figura 5.25. ‘Throughput’ en un handover abrupto lejano (300 mseg.) con TCP.

Situación óptima.

En comparación con la figura 7.20 observamos como los valores de

‘Throughput’ alcanzados ahora son inferiores. La causa de este fenómeno es la distancia del HA de la zona de handover. Debido a que el CN debe enviar al HA y éste reenviar al FA correspondiente, al aumentar la distancia aumenta latencia de los paquetes. Esto provoca que los


189

reconocimientos tarden más en llegar, frenando la capacidad de transmisión del CN.

El razonamiento anterior también explica que ahora el ‘Throughput’

tarda más en volver a los valores iniciales. El proceso de arranque lento tarda más en completarse pues los paquetes y los reconocimientos tardan más en llegar al MN y CN respectivamente. Handover ‘Make before Break’

Hemos realizado un conjunto de simulaciones para estudiar la mejora en las prestaciones de handover lejano cuando el Nodo Móvil es capaz de comunicarse simultáneamente con las dos Estaciones Base. Se ha empleado la misma configuración que la utilizada en las simulaciones anteriores, teniendo ahora en cuenta el tiempo en el que el móvil permanece en la zona de cobertura de ambas estaciones base.

La figura 5.26 nos muestra una simulación en la que el nodo se

desplaza a una velocidad de 30 m/seg. con una zona de solape de 20 metros. El retardo entre el HA y el router que da conectividad a los FA es de 60 mseg.

Se puede apreciar a que debido a la pérdida de cobertura por parte

del Foreign Agent 1 antes de efectuar el registro, tres paquetes no son recibidos por el MN y deben ser retransmitidos. Es interesante destacar que ahora los tres segmentos son retransmitidos sin tener que esperar el ‘Time Out’, pues el NM indica la pérdida tras recibir el mensaje numerado como 1404. La transmisión MN-CN se realiza sin necesidad de pasar por el HA lo que permite tiempos muy bajos entre la recepción del paquete 1404 por parte del MN y la retransmisión del paquete 1401. El ‘throughput’ que se muestra en la figura 5.27 se corresponde con la simulación anterior, donde se observa como la recuperación se realiza en tan solo dos segundos.


190

Figura 5.26 Handover blando lejano (60mseg) durante una transmisión TCP.

Figura 5.27 ‘Throughput’ en bytes/seg. en un handover lejano (60 mseg) blando.

Para finalizar realizamos otra simulación aumentando el retardo entre el Home Agent y el router hasta un valor de 300 mseg. para comprobar el efecto que produce en un handover blando. La figura 5.28 muestra la transmisión de paquetes y en la figura 5.29 está ampliado el


191

periodo de tiempo en el que sucede el intercambio de mensajes del protocolo ‘Mobile IP’.

Figura 5.28 Handover blando lejano (300mseg) durante una transmisión TCP.

Figura 5.29 Handover blando lejano (300mseg) detalle.


192

Como se aprecia en estas figuras, aunque el proceso de registro se inicia en la zona de solape de ambos FA, y debido al elevado retardo de más de 612 mseg que introduce el registro, se pierden multitud de paquetes. Al igual que en el caso anterior, la recepción por el transmisor de segmentos de reconocimiento que indican este hecho produce la retransmisión de los segmentos perdidos, sin esperar el vencimiento del temporizador.

5.4.3 Conclusiones sobre el Handover Lejano En este punto se han estudiado las prestaciones de handover que ofrece el protocolo Mobile IP cuando el nodo móvil se encuentra alejado de su ‘Home Network’ (situación que hemos denominado ‘handover lejano’). Se han realizado un conjunto de simulaciones para estudiar el comportamiento, tanto en el caso de trabajar con el protocolo de transporte TCP, como cuando lo hacemos con el protocolo UDP. Con respecto al protocolo UDP se realizado un primer estudio en el que el handover se produce de manera abrupta, de manera que el nodo móvil sólo puede comunicarse con una estación. En este caso se ha demostrado como el aumento de la distancia HA-FAs provoca un aumento lineal del número de segmentos UDP perdidos. Como ejemplo, en la figura 5.13 se observa una pérdida de más de 250 paquetes cuando se transmite a tasas de 1600Kbps con un retardo de 300 mseg. Además debido a que el protocolo obliga a un registro en el HA cada vez que el móvil cambia la red, se producen interrupciones en el nodo móvil de aproximadamente el doble de la distancia que separa el FA del HA, ya que el registro implica un mensaje de ida y vuelta.

En caso de implementar un handover ‘Make before Break’, donde el

nodo móvil puede comunicarse simultáneamente con las dos FAs, los resultados mejoran, siempre en situaciones en las que el nodo permanece en la zona de cobertura un tiempo suficiente. Aun en este caso no se eliminan completamente las pérdidas (figura 5.17). En caso de un


193

handover rápido la pérdida de segmentos UDP no experimenta una mejoría importante con respecto al handover abrupto. El ejemplo anterior (tasa 1600 Kbps, 300 mseg), ocasiona, con un handover blando rápido, una pérdida de 188 paquetes. Con respecto al protocolo TCP también hemos realizado estudios con los dos tipos de tecnologías de handover (abrupto y blando). Los esquemas de handover abrupto obligan a que el nodo comience el registro vía FA2 una vez perdida la conexión con FA1, lo que ocasiona una pérdida de paquetes. Como ya ocurría en el handover cercano (figura 5.8), ahora también es posible que el registro sea realizado durante el tiempo de retransmisión (Time Out) del protocolo TCP. Sin embargo, en función del retardo del HA y del momento en el que el MN recibe el mensaje ‘Agent Advertisement’ proveniente de FA2, es posible que los paquetes deban ser transmitidos una tercera vez antes de que nodo móvil los reciba. El motivo, como se apreciaba en la figura 5.21, es que el registro se completa cuando el temporizador de retrasmisión del CN ya ha vencido. Las prestaciones estudiadas a través del ‘throughput’ también disminuyen al trabajar en situaciones de handover lejano. Adicionalmente a la disminución de los valores máximos, que son debidas al aumento de retardo de la ruta CN-HA-FAx, se produce una disminución considerable en el momento del handover. El tiempo necesario para volver a la situación de partida depende, principalmente, del retardo HA-FA2. Así con un retardo de 60 mseg. el ‘throughput’ alcanzaba los valores iniciales en un tiempo aproximado de 4.5 segundos (figura 5.20), mientras que si se aumenta el retardo hasta 300 mseg. el tiempo de recuperación puede llegar a ser de 15 segundos (figura 5.24). El motivo es el mecanismo de arranque lento que TCP utiliza para prevenir la congestión. Un retardo elevado en la ruta HA-FA2 provoca un aumento en el tiempo de recepción de los paquetes, por los que los reconocimientos llegan de forma más lenta a CN, y el tamaño máximo de su ventana de transmisión tarda más aumentar. Por último se estudia el comportamiento del handover blando en una trasmisión TCP. Es destacable el hecho de que, aun siendo probable


194

las pérdidas de paquetes, debidas a que el proceso de registro en la nueva red puede terminar después de que el MN abandona la zona de solape, estos paquetes pueden ser recibidos por el nodo móvil sin que tenga que vencer el temporizador de retransmisión del transmisor. El motivo es que aumenta la probabilidad de que el proceso de handover termine antes de que el transmisor haya transmitido toda su ventana de transmisión. Esto provoca que el MN reciba segmentos desordenados, de manera que puede solicitar el envío de los paquetes pendientes al CN, agilizándose todo el proceso (figura 5.26).

Por tanto podemos concluir indicando que el protocolo ‘Mobile IP’ introduce una pérdida de prestaciones muy importante cuando el nodo móvil se encuentra alejado de su red original. En el caso de aplicaciones que se basan en UDP la pérdida de segmentos puede ser de más de 200, y en el caso de TCP puede que algunos los segmentos lleguen al nodo móvil con más de 3 segundos de retardo adicional, teniendo un tiempo de recuperación del handover que puede ser de hasta 15 segundos.

Las prestaciones aumentan en el caso de implementar tecnologías

de capa 2 que permitan el handover blando, con conexión simultánea del MN con los dos FAs implicados. Aun en este caso se pierden segmentos UDP y se retrasa en exceso la recepción de segmentos TCP, aunque en este caso el comportamiento va a depender, además del retardo HA-FA, del tiempo de permanencia en la zona de solape.

5.5 ESTUDIO DE PRESTACIONES DE LOS SISTEMAS DE MICRO - MOVILIDAD. Como acabamos de estudiar, la necesidad de realizar un registro con el Home Agent cada vez que el nodo móvil cambia de red hace que la latencia del proceso de handover aumente hasta cotas inaceptables en aplicaciones de tiempo real. Con el fin de reducir este tiempo en el punto 2.4 se explicó como actualmente se tiende a soluciones consistentes en dividir la red en dominios. Esto permite implementar las soluciones de


195

movilidad en dos (o varios) niveles. Las diferentes soluciones para realizar el proceso de handover que ofrecen los sistemas de micro-movilidad propuestos hasta la fecha fueron descritos en el punto 4.4.3. A continuación se va a realizar un estudio por simulación sobre las prestaciones de alguno de estos sistemas. Para realizar el trabajo partimos de la misma herramienta de simulación que la utilizada para el estudio del Mobile IP del punto anterior. En concreto utilizamos la versión ns-2.1b7 del simulador NS-2 [NS2] bajo Sistema Operativo Linux. Sobre el simulador se ha instalado las librerías CMIS (Columbia IP Micro-Mobility Suite) [COM] que incluye las implementaciones de los sistemas de micro-movilidad más referenciados (Cellular IP [CAM00], Hawaii [RAM99], y Mobile IP con registro regional [GUS02]). Más que realizar una comparación de los diferentes sistemas de micro-movilidad existentes en la actualidad, el objetivo es simplemente obtener unos valores de referencia que nos sirvan para comprobar las mejoras que ofrecen estos sistemas en comparación con el protocolo Mobile IP, así como para compararlos con el sistema de micro-movilidad multicast que presentamos en el capítulo 3. Un estudio más detallado realizado con estas mismas herramientas puede encontrarse en [CAM02]. Para realizar el estudio se ha implementado la situación mostrada en la figura 5.30. En Cellular IP cada Wi y APi corresponde con un nodo Cellular IP, actuando W0 como ‘Gateway’ del dominio. En Hawaii estos nodos son routers son capacidad de enrutamiento Hawaii, mientras que W0 es el denominado ‘Router Raíz del Dominio’. Para finalizar cuando estudiemos el protocolo Mobile IP con registro regional la función GFA se implementa en W0, los nodos Wi restantes son routers tradicionales y los APi implementan la capacidad de Foreign Agent. En todas las situaciones vamos a asumir que esta red es la red original del MN (Home Network), de manera que los paquetes son enviados desde el CN sin ningún tipo de encapsulación.


196

Figura 5.30 Situación implementada para el estudio de los protocolos de micro-

movilidad.

Como en puntos anteriores de este capítulo se va a realizar el estudio en dos situaciones distintas dependiendo de si se emplea, a nivel de transporte, el protocolo UDP o el protocolo TCP.

5.5.1 Estudio del tráfico UDP en Sistemas de Micro-Movilidad Con el fin de poder comparar los resultados con los obtenidos en los puntos 5.3 y 5.4 de este mismo capítulo se va a utilizar el mismo tipo de tráfico que el empleado entonces. Es decir, conectamos un agente UDP sobre el en CN de la figura anterior. Sobre este agente se ha instalado un generador de tráfico CBR que va a permitir estudiar, de manera sencilla, las prestaciones durante el handover. Los mensajes UDP tienen un tamaño constante de 500 bytes y se va a modificar el tiempo entre los mismos. Los paquetes IP son dirigidos, evidentemente, hacia el nodo móvil.

CH

5 Mbps2 ms

W0

W1 W2

W3 W4 W5

AP1 AP2 AP3 AP4

Nodo Móvil

IEEE 802.11b


197

La figura 5.31 muestra el número de paquetes perdidos por el protocolo Cellular IP cuando se realiza tanto el caso de ‘Hard Handover’ como en ‘SemiSoft Handover’ (ver punto 4.4.3). Para la realización de esta figura se ha tomado una tasa de transmisión CBR de 400 Kbps, una zona de solape entre estaciones de 30 metros y una velocidad del nodo móvil de 20 m/seg. El eje horizontal muestra la distancia hasta el nodo de cruce entre estaciones base donde se realiza el handover. Así, y según la figura 5.30, un handover entre AP1 y AP2 tiene una distancia de 1, entre AP2 y AP3 una distancia de 2, y entre AP3 y AP4 una distancia de 3. La figura se ha obtenido a partir de 100 simulaciones independientes, en cada una de la cuales el MN viaja de un extremo al otro del dominio.

Figura 5.31 Paquetes perdidos en Cellular IP. La figura anterior muestra como las pérdidas nulas en el handover

‘SemiSoft’ y muy bajas en al ‘Hard Handover’. Estos valores del handover abrupto son totalmente comparables a los obtenidos en el protocolo ‘Mobile IP’ cuando el handover se producía directamente entre en HA y un FA (ver figura 5.2). Por otra parte debido al funcionamiento del handover semisuave las pérdidas son nulas cuando el tiempo del MN en la zona solape está en valores normales (en torno a cientos de milisegundos). Tan

0 0 0 0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

1,8

2

1 2 3Distancia al nodo de cruce

Paqu

etes

Per

dido

s

HardSemiSoft


198

solo en simulaciones donde el tiempo de estancia en la zona de solape es mínimo se han logrado perder paquetes utilizando este esquema.

La figura 5.32 muestra el comportamiento de este sistema cuando

aumentamos la tasa de transmisión manteniendo constantes los restantes parámetros. El número de paquetes perdido es la media de todos los handovers producidos (independientemente de la distancia al nodo de cruce). Como en el caso anterior se observa que el handover abrupto es comparable al realizado en ‘Mobile IP’ cercano, mientras que utilizando el handover semisuave las pérdidas siguen nulas, aunque se producen duplicaciones en el nodo móvil.

Figura 5.32 Paquetes perdidos en Cellular IP en función de la Tasa.

Se han realizado simulaciones equivalentes para un sistema Hawaii. En el caso de realizar un handover UNF (Transmisión Unicast sin Reconocimiento, ver punto 4.4.3), los resultados obtenidos son equivalentes a los que se obtuvieron para el esquema abrupto de Cellular IP. La figura 5.33 nos muestra el número de paquetes perdidos en los sistemas Cellular IP, Hawaii UNF y como Mobile IP con registro regional. Los parámetros utilizados son los mismos que los empleados para la figura


199

5.31, y como en anteriores ocasiones está realizada a partir de 100 simulaciones independientes.

Figura 5.33 Paquetes perdidos en Cellular IP, Hawaii UNF, y MIP RR.

De la figura anterior es interesante destacar que, a pesar de que el número de paquetes perdidos es muy bajo en todos los casos, el protocolo Mobile IP con Registro Regional es el que peor comportamiento tiene cuando el handover se realiza entre FAs con distancia hasta el nodo de cruce de valor 1. Esto se debe a que según este esquema el mensaje de registro debe alcanzar el GFA, no bastando con llegar al nodo de cruce. Para finalizar el breve estudio sobre comportamiento de los protocolos de micro-movilidad bajo el protocolo UDP, estudiamos el comportamiento del sistema Hawaii cuando se produce un handover MSF (Envío por múltiples flujos). Según se estudio anteriormente, este esquema la estación base previa recibe un mensaje de handover y reencamina los paquetes almacenados en un buffer hacia al nueva estación base para su posterior retransmisión al MN. Esta solución puede provocar que algunos paquetes lleguen al nodo móvil duplicados o desordenados. La figura 3.34 nos muestra el número medio de paquetes duplicados cuando se emplea este proceso. La tasa de transmisión es de 400 Kbps y se ha realizado sólo

0

0,5

1

1,5

2

2,5

1 2 3

Distancia al nodo de cruce

Paqu

etes

per

dido

s

Cellular IP HardHawaii UNFMIP HHMIP RR


200

en el handover entre las estaciones AP3 y AP4 (distancia 3 hasta el nodo de cruce), ya que en los otros handovers las pérdidas eran despreciables. El eje horizontal nos muestra el tiempo en mseg. que oBS almacena los paquetes en un buffer.

Figura 5.34 Paquetes duplicados en Hawaii MSF.

5.5.2 Estudio del tráfico TCP en Sistemas de Micro-Movilidad

De manera similar se ha realizado un breve estudio con el fin de estudiar el comportamiento de los diferentes sistemas de micro-movilidad cuando se trabaja con el protocolo TCP. Como en estudios anteriores hemos optado por la versión TCP Vegas [BRA94], y sobre este agente se ha instalado una aplicación FTP que va a estar activa mientras se produce el proceso de handover.

La figura 5.35 muestra el handover abrupto del sistema ‘Cellular IP’

entre las estaciones AP1 y AP2 de la figura 5.30. Se ha tomado un tiempo de envío de paquetes de actualización (route-update time) de 100 mseg. [CAM00]. En la figura observamos como el handover abrupto se traduce en

Handover FA3-FA4


201

un tiempo de interrupción menor de 500 mseg. Este valor es inferior a los 1000 mseg. que se obtuvieron en el protocolo ‘Mobile IP’ (ver figura 5.8), y esto es debido a que en ese caso periodo de envío de mensajes ‘Agent Advertisement’ era de un segundo. Como en anteriores simulaciones se observa el ‘arranque lento’ tradicional del protocolo TCP.

Se han realizado simulaciones similares con el sistema Hawaii

utilizando el mecanismo de handover UNF, y los resultados son totalmente equivalentes.

Figura 5.35 Hard Handover de Cellular IP con transmisión TCP.

La figura 5.36 muestra una transmisión TCP en un sistema Cellular IP cuando se emplea el handover semisuave. En concreto se muestra al handover entre las estaciones AP1 y AP2. Se ha tomado un tiempo de retardo para realizar la conexión final con AP2 de 300 mseg [CAM00]. Claramente se observa la mejora con respecto a la figura anterior, ya que ahora no se produce interrupción alguna en el handover.


202

Figura 5.36 SemiSoft Handover en Cellular IP con transmisión TCP.

Figura 5.37 Handover MSF en Hawaii con transmisión TCP.

Para finalizar mostramos una simulación sobre un handover en un sistema Hawaii con mecanismo de handover MSF. La figura 5.37 muestra


203

el handover entre las estacione AP3 y AP4 y se ha tomado un tiempo de almacenamiento en el buffer de 10 mseg. Se observa que el comportamiento es similar al Cellular IP con una ligera interrupción debida al intercambio de mensajes del protocolo [RAM99]. Puede observarse como el paquete 59 ha sido reenviado entre las dos estaciones base y por esto alcanza el MN ligeramente retrasado.

5.5.3 Conclusiones sobre los sistemas de micro-movilidad En este punto se ha realizado un breve estudio sobre los sistemas de micro-movilidad más populares actualmente. Hemos observado como las prestaciones de estos sistemas son mucho mejores que las que ofrece el protocolo Mobile IP cuando el nodo móvil se encuentra lejos del la red origen del nodo. En transmisiones haciendo uso del protocolo UDP el número de paquetes perdidos se mantiene en unos valores muy bajos independientemente del sistema que se emplee. Incluso si se utilizan esquemas de handover avanzados, bien basados en la capacidad del nodo de recibir de las dos estaciones base de manera simultanea (Semisoft Handover en Cellular IP), o bien utilizando redireccionamiento de paquetes entre estaciones (MSF en Hawaii), se logra no perder un solo paquete, independientemente del punto del dominio donde se realice el handover. En TCP los resultados también experimentan una gran mejora con respecto al protocolo Mobile IP. En el caso de realizar un handover abrupto los resultados son ligeramente mejores que el handover cercano del protocolo Mobile IP y evidentemente mucho mejores que el handover lejano. En el caso de utilizar handover semisuave o con redireccionamiento, la transición entre estaciones se produce de manera perfecta, siempre que los parámetros del sistema estén correctamente ajustados a la topología de la red y al tipo de tráfico.


204

Estudios detallados sobre el análisis de prestaciones de estos sistemas de micro-movilidad pueden encontrarse en [CAM00] y [CAM02].

5.6 IMPLEMENTACIÓN DE UN BANCO DE PRUEBAS DEL PROTOCOLO MOBILE IP En los puntos anteriores se realizaron una serie de simulaciones que nos han permitido evaluar las limitaciones del protocolo Mobile IP en comparación con algunas soluciones de micro-movilidad. Con el fin de comparar los resultados anteriores con medidas reales se ha implementado un banco de pruebas, donde se ha evaluado las prestaciones del protocolo Mobile IP durante un handover cercano. La implementación se ha realizado utilizando el paquete de Movilidad IP ‘Dynamics’ [DYN] de la universidad de Helsinki. La elección de este en detrimento de otros (MosquitoNet [MOS], o la de los laboratorios de HP [HP] ) se ha debido a ser la versión más popular en la actualidad, por ser la que está más actualizada para adaptarse a las nuevas distribuciones de Linux, y por ser la que dispone de más opciones de configuración. En la figura 5.38 se muestra el sistema instalado. Todos los nodos son PC’s con sistema operativo Linux Suse 8.1. Esta distribución era la que mejor se adaptaba a las necesidades del driver ‘Dynamic’, hasta el punto que no fue necesario recompilar el Kernel.

La transmisión inalámbrica se realiza utilizando tarjetas WLAN IEEE802.11b en modo de funcionamiento Ad hoc. En concreto utilizamos tarjetas Compaq WL110. El sistema cableado se ha realizado utilizando tarjetas IEEE 802.3 (de la marca Realtek). En la figura puede observarse las direcciones y mascaras de red de los interfaces de todos los nodos.


205

Figura 5.38. Montaje realizado.

Es importante destacar que los dos agentes (HA y FA) están funcionando en modo Ad hoc en el misma red local (mismo BBS). Es decir, tienen el mismo SSID y transmiten en el mismo canal. Esto se traduce en que realmente no existe un handover a nivel 2. El handover en Mobile IP se ejecuta a partir de una herramienta incluida en el paquete de movilidad (dynmn_tool), que nos ofrece una gran versatilidad en la configuración del tipo de handover a realizar. Así por ejemplo sería posible incluso configurar un handover blando. Sin embargo el modo de funcionamiento del paquete Dynamic también presenta algunas desventajas. El objetivo es implementar un sistema lo más real posible donde se produce un handover abrupto basado en IEEE 802.11f. El handover lo realizamos desactivando el interfaz inalámbrico del HA. Esto hace que el MN deje de recibir del HA y realice el handover registrándose vía FA.

IP: 20.0.0.1/24

Foreign Agent

Transmisor CN

Home Agent

Nodo Móvil

IP: 50.0.0.3/24

IP: 20.0.0.254/24

IP: 40.0.0.254/24 IP: 30.0.0.254/24

IP: 40.0.0.5/24; CoA IP: 30.0.0.2/24

IP: 50.0.0.4/24

IP: 60.0.0.7/24


206

El principal problema es que, según el estándar Mobile IP, existen dos soluciones a la hora de realizar la detección del movimiento, [RFC 3344] punto 2.4.2. La primera solución es la utilizada por Dynamics, y se basa en que los mensajes ‘Agent Advertisement’ tienen un tiempo de vida. Así, si el tiempo de vida del último mensaje recibido vence, se puede suponer que ya no estamos en la red, y se debe intentar el registro en una nueva subred. La conclusión de esta solución es que el nodo móvil no va a iniciar el proceso de registro hasta que no venza la validez del último recibido vía HA, empeorando las prestaciones del handover.

En las simulaciones anteriores se ha implementado la segunda

solución ofrecida por Mobile IP, basada en la detección del cambio de red utilizando las direcciones de red de los mensajes ‘Agent Advertisement’ recibidos. En esta situación, en una red ‘Break Before Make’, al recibir de un nuevo FA, el proceso de registro se ejecutaba inmediatamente, pues si se recibe vía un nuevo FA ya no tiene ninguna validez el mensaje de anuncio del FA previo.

La conclusión es que el comportamiento del sistema real

implementado será peor que los resultados obtenidos por simulación. En la figura 5.39 se muestra un diagrama de tiempos en el que se reproducen los ‘Agent Advertisement’ enviados por HA y FA. En función del instante en el que se realice el handover abrupto éste puede llegar a durar más de un segundo (zona 1), que es el tiempo entre anuncios, y el mínimo que se le puede dar como tiempo de validez del mensaje.

Se han realizado distintas pruebas para evaluar las prestaciones.

En concreto se ha realizado transmisiones CBR basadas en UDP, transmisión con TCP, y envío de distintos tipos de vídeo utilizando RTP [RFC1889].

El modo de trabajo ha sido similar en todos los estudios: se ha

capturado los datos en los distintos nodos utilizando la aplicación ‘tcpdump’ [TCP], y posteriormente se han procesado utilizando pequeños programas realizados en leguaje Perl.


207

Figura 5.39 Handover abrupto.

5.6.1 Transmisión CBR con protocolo de transporte UDP Para la transmisión de datos con UDP hemos utilizado una aplicación de libre distribución denominada MGEN [MGE], diseñada por el NRL (Naval Research Laboratory).

Se ha evaluado el número de paquetes perdidos en función de la tasas de transmisión CBR. En concreto se ha transmitido a 80, 400, 800, 1200, 1600 y 2000 kbps., utilizando siempre un tamaño de paquete de 500 Bytes.

La figura 5.40 muestra los resultados obtenidos. Cada punto se ha

realizado a partir de 20 realizaciones independientes. Puede observarse como el número de paquetes perdidos es muy superior al obtenido en la simulación del handover cercano (figura 5.2). La razón, ya comentada, es que el tiempo de handover es ahora mucho mayor, situándose en valores ligeramente superiores a 1 segundo.

FA FA FA

1 seg.

HA HA

1 seg.

Instante de handover

Inicio del Registro con el FA 1 2


208

Figura 5.40 paquetes perdidos durante el handover.

5.6.2 Transmisión con protocolo TCP En la generación de tráfico TCP se empleó el programa de la

universidad técnica de Munich, nttcp (New Test TCP), en su versión 1.47 [NTT]. La figura 5.41 nos muestra los segmentos TCP transmitidos y recibidos durante un proceso de handover, así como el instante en el que el FA envía mensajes ‘Agent Advertisement’, y el instante en el que el mensaje ‘Registration Reply’ llega al nodo móvil.

Podemos observar como el último segmento transmitido por HA se

retransmite varias veces, a pesar de que fue recibido correctamente por el MN. El motivo es que el reconocimiento ACK del segmento no pudo alcanzar al HA, por estar produciéndose el handover abrupto. El HA, por tanto, lo retransmite el cada vez que vence el periodo de ‘time-out’. Puede observarse como este temporizador dobla su duración cada vez.


209

Figura 5.41. Handover abrupto durante una transmisión TCP.

El primer ‘Agent Advertisement’ transmitido por el FA es descartado

por el MN, debido a que aun no ha vencido la duración del que recibió del HA. Tras recibir un segundo mensaje de anuncio el MN se registra con el Foreign Agent, restaurándose completamente la comunicación.

Por último la reanudación de la transmisión, vía FA, se produce por

el mecanismo de ‘Slow Start’. Así la ventana de transmisión empieza siendo pequeña aumentándose al ir recibiendo los reconocimientos positivos. La figura 5.42 nos muestra una ampliación de la figura anterior, donde se puede apreciar mejor este hecho.


210

Figura 5.42. Ampliación del ‘inicio lento’ tras el Handover.

5.6.3 Transmisión de tráfico multimedia con RTP Hemos realizado diversos estudios para evaluar el comportamiento del handover abrupto bajo tráfico multimedia. Para ello se ha utilizado una aplicación (JMStudio) basada en las librerías JMF 2.0 (Java Media Framework) de la empresa SUN [JMF]. Esta aplicación se ha utilizado tanto para la transmisión como para la visualización en recepción. La transmisión se realiza utilizando dos flujos independientes de datos (audio y vídeo) transportados por RTP [RFC 1889]. Con el fin de evaluar las diferencias se han evaluado dos tipos de tráfico multimedia:

• Transmisión multimedia con calidad media. La transmisión de vídeo se realiza con codificación MJPEG (Motion JPEG), mientras que el audio se transmite en PCM a 64 Kbps con codificación µ-law.

• Transmisión de videoconferencia. En este caso el vídeo es transmitido según el estándar H.263, mientras que el audio es transmitido a 6.4 Kbps codificado en G.723.


211

5.6.3.1 Transmisión multimedia con calidad media En este caso el vídeo original tiene un formato ‘.mov’, de manera que el transmisor lo recodifica para su transmisión, obteniendo dos flujos que transmitirá utilizando RTP.

El flujo de vídeo es codificado en MJPEG con tamaño de imagen 360x198. Así cada trama es transmitida en un conjunto de paquetes RTP de longitud 980 bytes, menos el último de cada imagen, que tiene longitud variable. El resultado es una tasa variable en torno a los 1.1 Mbps.

El flujo de audio es codificado en PCM a 64 Kbps. La transmisión

se realiza a tasa constante con paquetes de 480 bytes. La figura 5.43 muestra el ‘throughput’ del flujo de vídeo durante el handover. Se aprecia las variaciones debidas a la propia codificación de la señal, y la caída brusca durante el handover. Hay que tener presente el tamaño de la ventana utilizada para realizar la gráfica, motivo por el que la caída no es inmediata.

5.43 Tasa de vídeo durante el handover.


212

En la gráfica siguiente se muestra el número de paquetes de vídeo perdidos durante el handover. El eje horizontal muestra distintas pruebas realizadas. La dispersión observada es debida a dos motivos: El tiempo de duración del handover que varía entre 0 y 2 segundos; y el tipo ratio de compresión de la imagen. Así imágenes sencillas como títulos o con grandes superficies de color constante tienen un menor tamaño, lo que se traduce en un menor número de paquetes por imagen. Esto es especialmente apreciable en la medida 4 en la que han coincidido un handover de corta duración (0.5 seg.) junto con el hecho de que el handover se produjo mientras se transmitían imágenes con grandes títulos.

Figura 5.44 Paquetes perdidos de vídeo durante el handover.

Por otro lado el número de paquetes de audio perdidos depende sólo de la duración del handover, ya que se transmiten de manera constante. El valor de paquetes perdidos medio es de 21, que se corresponde con un handover de 1.2 segundos.


213

5.6.3.2 Transmisión de videoconferencia de baja calidad Se han repetido el análisis anterior realizando una transmisión de una videoconferencia previamente almacenada, y utilizando la misma aplicación de transmisión (JMStudio). La codificación del vídeo se ha realizado utilizando H.263, con un tamaño de pantalla de 160x120 puntos, y resultando una tasa media de 90 kbps. El audio va codificado en formato G.723 con tasa constante de 6.4 Kbps. La figura 5.45 muestra el ‘throughput’ del flujo de vídeo durante el handover. Puede observarse que antes y después del handover la tasa es relativamente constante. H.263 tiene codificación temporal, y, debido al tipo de vídeo enviado (el busto de una persona hablando) con poco movimiento, la información transmitida es siempre similar. La codificación temporal puede apreciarse, ligeramente, en la variación de la tasa del vídeo antes y después del handover.

Figura 5.45 Tasa del vídeo de una videoconferencia.


214

La figura 5.46 nos muestra el número de paquetes de vídeo perdidos durante el handover. El eje horizontal muestra las distintas muestras realizadas. Puede apreciarse como la dispersión ahora es menor que en las pruebas de vídeo con calidad media. El motivo es que ahora la mayoría de las imágenes de vídeo se transmiten en un único paquete RTP. Por tanto las pérdidas dependerán principalmente de la duración del handover. El ratio medio de paquetes por imagen de la transmisión es cercano a 1.2.

Figura 5.46 Paquetes de vídeo perdidos durante el handover en videoconferencia.

Con respecto al flujo de audio, el número medio de paquetes perdidos es de 21. Como en el caso anterior, la variación de las medidas se debe exclusivamente al tiempo de handover, ya que la trasmisión se realiza a una tasa constante.


215

5.6.4 Prueba subjetiva sobre el efecto del handover Las transmisiones multimedia, evaluadas en el punto anterior, se encuentran dirigidas, en general, a un observador humano. Es interesante estudiar como la realización de un handover afecta a la calidad subjetiva que recibe el receptor.

Para medir esta calidad subjetiva se ha realizado una prueba a distintas personas. La prueba subjetiva consiste en el visionado de un breve trozo de película o de videoconferencia durante el cual se produce un handover para que el espectador califique después su efecto. El test que los espectadores han tenido que rellenar una vez visionado cada vídeo se muestra en la figura siguiente.

Figura 5.47 Test para la evaluación subjetiva.

1. ¿Es capaz de apreciar algún efecto cuando visiona el

vídeo?

Opciones: Si, No

2. ¿Cómo evaluaría el efecto percibido, en caso de haberlo

percibido?

Opciones: Despreciable, Apreciable, Molesto, Muy molesto

3. ¿Tiene la sensación de que se ha perdido alguna parte

importante de la película? Opciones: Sí, No, No estoy

seguro/a

4. Describa muy brevemente (una o dos frases) qué es lo que

ha percibido


216

Las gráficas que se muestran a continuación son el resultado de realizar la prueba subjetiva a 15 personas. A todas ellas se les ha pasado tanto el vídeo de calidad media como la videoconferencia. El orden de visionado ha sido elegido aleatoriamente para cada uno de los observadores.

0

2

4

6

8

10

12

14

16

Video MJPEG Videoconferencia

Obs

erva

dore

s

Sí

No

Figura 5.48. Pregunta 1. ¿Es capaz de apreciar algún efecto cuando visiona el

vídeo?

Figura 5.49. Pregunta 2. ¿Cómo evaluaría el efecto percibido?

2

6

6

13

11

1 0

Despreciable

Apreciable

Molesto

Muy molesto

Vídeo MJPEG Videoconferencia


217

0

2

4

6

8

10

12

14


Obs

erva

dore

s

Sí

NoNo estoy seguro

Figura 5.50. Pregunta 3 ¿Tiene la sensación de que se ha perdido alguna parte

importante de la película?


Se aprecia un corte en la película.

12 Se aprecia un corte en la película

14

Se aprecia un corte de x seg.

6 Se aprecia un corte de x seg.

6

No aprecio nada 3 El corte del audio es más perceptible que el de vídeo

3

Falta de sincronización entre voz e imagen

2

Figura 5.51. Pregunta 4. Describe muy brevemente qué es lo que ha percibido.

Como se aprecia de las figuras anteriores la gran mayoría de los sujetos perciben el handover. El hecho de que el vídeo de calidad media MJPEG fuera de una película de ‘dibujos animados’ y en idioma inglés ha favorecido que un pequeño porcentaje de personas no llegara a detectar el handover de este vídeo. El efecto percibido es mucho menos aceptado en la videoconferencia. Esto se debe principalmente a dos motivos. El primero es


218

que la codificación del video en la videoconferencia se realiza con H.263, que emplea redundancia temporal para reducir la tasa. Esto se realiza codificando los movimientos entre macrobloques de unas tramas a otras. Por tanto, tras finalizar el handover, el receptor necesita una trama referencia para poder mostrar la imagen de nuevo. El efecto es que se alarga la duración efectiva del handover, y el corte percibido es mayor. La segunda razón es que la interrupción del audio es más perceptible que la interrupción del vídeo. En la videoconferencia toda la atención se centra en el audio, ya que el vídeo es siempre similar, y la interrupción del audio se hace más molesta. Podemos concluir diciendo que la detección del handover ha sido casi unánime, aunque ha sido catalogada como ‘aceptable’. Esta aceptación puede deberse a que ha sido un único handover, y que se puede haber aceptado por ser un hecho aislado. Es de esperar que en una situación real en la que se producen múltiples handovers, y que además están añadidos a la pérdida de calidad de la recepción de la señal debido al propio movimiento, empeorará la evaluación subjetiva de los sujetos.

5.6.5 Conclusiones de la implementación del banco de pruebas La implementación del banco de pruebas ha mostrado como el protocolo de Mobile IP funciona correctamente con redes inalámbricas IEEE 802.11b. Es decir la misión del encaminamiento hacia nodos móviles, así como la compatibilidad con el protocolo IP clásico, se han resuelto a la perfección por este protocolo. Debido al mecanismo de handover implementado por el paquete Dynamics, la duración de un handover es superior a las medidas realizadas por simulación. Este hecho no es debido a una incorrecta implementación del estándar de Mobile IP, ya que ambas opciones están recogidas en [RFC 3344].


219

Como se ha apreciado en las distintas pruebas realizadas, el tiempo medio necesario para la realización del handover se ha situado en 1.2 segundos. Ese tiempo hace que se pierdan gran número de paquetes trabajando en UDP, y que el protocolo TCP necesite retransmitir en varias ocasiones algunos paquetes en concreto. Un aspecto importante observado ha sido la gran variación de la duración del tiempo de handover. Esto desaconseja el protocolo para cualquier aplicación que necesariamente tenga que garantizar la entrega de información bajo unas condiciones temporales estrictas. En aplicaciones de tiempo real que no sean críticas, fundamentalmente audio y vídeo, Mobile IP ofrece prestaciones aceptables siempre que los requisitos de pérdidas no son muy exigentes.


220

221

6. ESPECIFICACIÓN DE MECANISMOS DE HANDOVER INTRA-DOMINIO PARA UN

SISTEMA DE MICRO-MOVILIDAD BASADO EN MULTICAST

6.1 INTRODUCCIÓN En el capítulo 4 de esta Tesis se realizó un estudio de los

mecanismos de handover en redes IP móviles. Allí se detalló las pobres prestaciones que ofrece el protocolo Mobile IP, y se presentaron un conjunto de soluciones que intentan solventar estas limitaciones. En concreto, se estudiaron soluciones para lograr disminuir el retardo en la entrega de paquetes en el handover (handover rápido), y limitar la pérdida durante el mismo (handover suave). Además, se estudió como los sistemas de micro-movilidad, que habían sido descritos en el capítulo 2, mejoraban las prestaciones del mecanismo de handover de manera considerable. Los resultados de un conjunto de simulaciones que analizan las prestaciones durante el handover tanto del protocolo Mobile IP como de distintos sistemas de micro-movilidad fueron presentados en el capítulo 5.

Una de las aportaciones de esta Tesis es la presentación de un sistema de movilidad escalable, basado en una arquitectura de micro-movilidad, que explota las capacidades de la transmisión multicast (capítulo 3). La unión de las características de los sistemas de micro-movilidad, junto con las de la tecnología multicast, va a traducirse, entre otros aspectos, en mecanismos de handover intra-dominio sencillos y de altas prestaciones. A continuación se muestran los beneficios que aporta el empleo de estás tecnologías con el fin de lograr tanto handovers rápidos como suaves.

Mecanismos de Handover para el sistema basado en multicast

222

En el punto 4.2 se realizó un estudio de los tiempos implicados en un proceso de handover. Así se definió el ‘Retardo en la Recuperación de una Dirección Temporal’ (Tco-retrieval), como el tiempo necesario para que el nodo móvil obtuviera una dirección temporal (Care-of Address) acorde con la red que visita. El sistema de micro-movilidad basado en multicast propuesto elimina completamente este retardo, pues no es necesario cambiar de dirección mientras se permanece en el interior del dominio.

En el protocolo Mobile IP el mayor componente de la latencia es el

‘Tiempo de Restablecimiento de Ruta’, puesto que es directamente proporcional a la distancia entre la situación actual del nodo móvil y su Home Agent. Para solucionar este problema aparece el concepto de dividir la red en dominios, y la idea de los sistemas de micro-movilidad. En el sistema propuesto este retardo se limita al tiempo necesario para que la nueva estación se conecte al árbol multicast.

El sistema de micro-movilidad basado en multicast también ofrece

una base perfecta para lograr un handover suave, donde se minimiza la pérdida de paquetes. Una de las soluciones que generalmente se emplea para este fin es la de utilizar una transmisión simultánea a las dos estaciones base implicadas en el handover. Esta solución ha sido empleada, por ejemplo, en el sistema de micro-movilidad ‘Cellular IP’ (Handover Semi-suave) o en el sistema ‘HAWAII MNF’ (punto 4.4.3). El sistema de micro-movilidad presentado se basa en la conexión de las estaciones base a un árbol multicast asociado al nodo móvil, lo que lleva implícito una transmisión de paquetes hacia las dos estaciones de manera simultánea.

Sin embargo, las facilidades que el sistema presentado ofrece para

lograr un mecanismo de handover suave, por medio de la transmisión simultánea, no descartan la posibilidad de incorporar otro tipo de soluciones, como puede ser el redireccionamiento de los paquetes pendientes descrito en el punto 4.4.1.

En el presente capítulo se van a proponer y analizar distintos

mecanismos de handover, que hemos diseñado para el sistema de micro-


223

movilidad basado en multicast que se detalló en el capítulo 3. Así en el punto 6.2 se realiza una breve descripción de los cinco esquemas de handover propuestos. Un estudio profundo se realiza en los puntos 6.3 a 6.7, donde se indica el modo de funcionamiento y el formato de los paquetes intercambiados que proponemos. En el capítulo siguiente se realizará un estudio analítico de las prestaciones de estos esquemas.

6.2 PROPUESTA DE ESQUEMAS DE HANDOVER A continuación se van a describir cinco mecanismos de handover

que hemos diseñado para el sistema de micro-movilidad basado en multicast. Todos ellos comparten las virtudes de baja latencia y buena predisposición a lograr handovers suaves que se han comentado en el punto anterior.

Los cinco esquemas que se van a estudiar en el presente capítulo

son:

• Handover Abrupto. Es la primera solución, muy sencilla, donde no se intenta garantizar la entrega de los paquetes. Se basa en confiar en la buena predisposición del sistema de micro-movilidad multicast para realizar un handover con baja latencia con bajas pérdidas.

• Handover Semi Suave. Pensados para sistemas en los que el nodo móvil tiene capacidad para comunicarse con las dos estaciones base de manera simultánea. Mientras se encuentra en la zona de solape de las coberturas de las dos estaciones base, el nodo móvil se comunica con nBS, indicándole que se conecte al árbol multicast. En función del tiempo que el MN permanezca en la zona de solape, y del tiempo de creación de la nueva rama del árbol multicast, se lograrán prestaciones altas, con un tiempo de latencia nulo y muy bajo número de paquetes perdidos.


224

• Handover Suave con Finalización Controlada. Para lograr un handover totalmente suave, sin perdida de paquetes, se propone una ligera variación del esquema anterior. Se basa en una técnica novedosa que combina la transmisión multicast a las dos estaciones base, junto con mensajes, transmitidos por el MN, que controlan completamente el proceso de handover.

• Handover con Redireccionamiento. Con el fin de lograr un

handover suave se presenta un handover con redireccionamiento. En este caso se establece una comunicación entre las dos estaciones base implicadas en el handover, de manera que la estación antigua puede reencaminar los paquetes recibidos que aún no han sido enviados al nodo móvil.

Este tipo de handover está pensado para sistemas donde, en un instante de tiempo, el nodo móvil puede comunicarse únicamente con una estación base. Esto no impide utilizar este esquema en sistemas con capacidad de recepción simultánea de dos BS, aunque, para estos sistemas es más sencillo lograr un handover suave por medio de los esquemas anteriores basados en la transmisión simultánea de paquetes por ambas estaciones base.

• Handover Indirecto con Pre-registro. Por último, para lograr un

handover rápido en sistemas donde el nodo sólo se comunica con una BS, se define un handover con pre-registro basado en la utilización de ‘triggers’. La idea es enviar un mensaje a la nBS (utilizando para ello a la oBS) para que comience su incorporación al árbol multicast mientras se está realizando el handover de nivel 2. La intención es disminuir los componentes de la latencia del handover, tanto el tiempo de detección de movimiento, como el tiempo de redireccionamiento, adelantándolo y solapándolo al primero.


225

6.3 ESQUEMA DE HANDOVER ABRUPTO El mecanismo de Handover Abrupto está pensado para sistemas donde el MN no puede comunicarse con más de una estación base de manera simultánea. Se basa en el principio simple de que algunos paquetes se perderán en el proceso y, en vez de tratar de solucionarlo, se deja esta tarea a los niveles superiores. El número de paquetes perdidos será proporcional a la latencia total del handover y a la tasa de transmisión de los paquetes. En realidad este procedimiento es la forma de trabajar del protocolo original Mobile IP [RFC 3344]. Sin embargo, las prestaciones que van a lograrse al aplicar el mecanismo al sistema de micro-movilidad basado en multicast van a ser muy superiores que las obtenidas con el protocolo Mobile IP (ver capítulo 5). El motivo es, que aún teniendo un handover abrupto, las características del sistema propuesto (sistema de micro-movilidad y tecnologías multicast) reducen considerablemente la latencia del handover. Como se detalló en el punto 3.3.1, el nodo móvil escucha los mensajes ‘Agent Advertisement’ (ver 3.3.1), que envían las estaciones base de manera periódica, con objeto de descubrir si se ha producido un cambio de estación base. Otra posibilidad sería que el nodo móvil enviara un mensaje ‘Agent Solicitation’ para forzar a la estación base a que transmita el mensaje de anuncio. Este segundo caso sería interesante, especialmente, si existe una cooperación entre los niveles dos y tres del nodo móvil. Típicamente se realizaría utilizando un trigger Link UP [YEG02], de manera que nada más finalizar el handover de nivel dos se lanzara el mecanismo de nivel tres. En [BLO03] se realiza un estudio de prestaciones del protocolo Mobile IP cuando se utiliza este trigger y una red IEEE 802.11. Tras detectar la necesidad de realizar un handover intra-dominio, el nodo móvil transmite un mensaje denominado ‘Intra-Domanin Registration Request’ (punto 3.5.3) hacia la nueva Estación Base. Este mensaje contiene la dirección multicast utilizada por el móvil, la dirección de la


226

estación base anterior, y la dirección del MMA con el que se realizó el registro. La figura 6.1 muestra un diagrama del proceso donde se puede observar este mensaje.

Figura 6.1 Esquema del proceso de Handover Abrupto.

La nueva estación base entiende este mensaje de petición de registro como si recibiera un mensaje IGMP. Como respuesta, la estación se va a conectar al árbol multicast utilizando un mensaje ‘Join’ que se transmitirá de manera ascendente. En el caso de emplear el protocolo PIM-SM, el mensaje se transmitiría hacia el MMA, que actuaría como ‘Rendezvous Point’ del árbol multicast. Debido a las especiales

Leave Group

MN oBS nBS Nodo Cruce

Beacon

Join

ACK Join

Datos

Intra-Domain Registration Request

Datos en Multicast

Intra-Domain Registration Reply

Datos en Multicast

Datos

Multicast Prune Request


227

características del mecanismo, en las que existe únicamente un transmisor, y que por tanto va a actuar como RP (Rendezvous Point), el protocolo PIM podría simplificarse. En particular las necesidades de nuestro sistema se adaptan perfectamente a la tecnología ‘Multicast con Fuente Específica’ (SSM) que actualmente se encuentra en investigación [BHA03], [HOL03]. Aún así el sistema podría funcionar perfectamente con cualquier protocolo multicast, incluidos los protocolos de modo denso.

De esta manera el mensaje ‘Join’ sería el definido en el protocolo [RFC 2362] o en [FEN03]. Para mantener la seguridad del sistema, este mensaje ‘Join’ podría ir finalizado por una extensión de autentificación FA-FA diseñada en el punto 3.5.2 a partir de [RFC 3012].

El mensaje ‘Join’ se transmitirá hasta que se alcance un router que

pertenezca al árbol multicast, es decir, hasta el primer router común en la ruta hacia el núcleo. Este router, que denominaremos Nodo de Cruce, sería en cierta manera similar a los nodos de cruce de los sistema de micro-movilidad HBR.

La Estación Base nBS recibirá una confirmación positiva de la incorporación al árbol por medio de un mensaje ‘ACK Join’. Como se discutió en el punto 3.6 este mensaje no está definido en el protocolo PIM-SM, aunque si existe en otros protocolos como CBT [RFC 2189]. Esto no es ningún problema, puesto que la mínima información necesaria para poder enviar este mensaje se encuentra en las tablas de enrutamiento multicast PIM. Como en el caso anterior el mensaje ‘ACK Join’ debería finalizarse con una extensión de autentificación.

Por último, y como se observa en la figura 6.1, tras recibir este mensaje ‘ACK Join’, la estación base le comunica al nodo móvil la incorporación al árbol mediante un menaje ‘Intra-Domain Registration Reply’ (punto 3.5.3). La recepción de este mensaje da por concluido el proceso de handover abrupto, ya que a partir de ese momento, el nodo móvil puede recibir datos por medio de la nueva Estación Base.


228

En este instante el nodo móvil está transmitiendo y recibiendo por medio de la nueva Estación Base. Sin embargo, la Estación Base anterior no ha recibido ningún tipo de notificación que le informe sobre este hecho, y, por tanto, sigue conectada al árbol multicast del móvil, y continúa transmitiendo los paquetes por el interfaz inalámbrico. Esta circunstancia es temporal. La conexión de una estación base al árbol multicast viene determinado por la recepción cada cierto tiempo de mensajes de re-registro que serían equivalentes a los mensajes de Informe de Filiación (‘Membership Report’) del protocolo IGMP. La ausencia de estos mensajes indica a oBS que el nodo ya no se encuentra en su zona de cobertura, por lo que debería iniciar el proceso para abandonar el árbol multicast. La permanencia temporal de la Estación Base antigua en el árbol multicast, cuando el nodo ya ha realizado el handover, no tiene graves consecuencias en las prestaciones del sistema cableado, pues se supone que la red tiene la suficiente ancho de banda. Sin embargo sí puede afectar negativamente el hecho de transmitir los paquetes por el interfaz inalámbrico, ya que éste suele tener limitaciones de capacidad. Para solucionar el problema se propone un nuevo mensaje, que denominamos ‘Multicast Prune Request’. Este mensaje lo envía la nueva estación base a la antigua, cuando la primera recibe la confirmación de la conexión al árbol multicast, vía ‘ACK Join’. Para que la nueva estación base tenga conocimiento de la dirección IP a donde enviar el paquete, es necesario añadir esta información al menaje ‘Intra-Domain Registration Request’ definido en el punto 3.5.3. Para ello se define una nueva extensión, mostrada en la figura 3.2, que se incorporará al mensaje de registro cuando se emplee este tipo de handover.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo Longitud Dirección de la estación base anterior

Dirección de la estación base anterior

Figura 6.2 Extensión para ‘Intra-Domain Registration Request’ en Handover

Abrupto.


229

En la figura 6.3 se muestra el formato del mensaje ‘Multicast Prune

Request’ propuesto. El campo ‘Tipo’ se utiliza para diferenciar los distintos mensajes del protocolo de micro-movilidad propuesto, y su valor estaría definido por la IANA. El bit ‘A’ indica que estamos ante un handover abrupto de manera que se puede reutilizar este mensaje en posteriores mecanismos de handover. Así, los bits ‘S’, ‘R’ y ‘P’ se utilizan en esquemas de handover posteriores. Las direcciones multicast y del MMA se utilizan para poder abandonar el árbol multicast. Por último, el campo ‘Identificador’ se emplea como mecanismo de seguridad para asociar peticiones con respuesta en caso necesario, aunque por ahora no lo utilizaremos. Por motivos de seguridad este mensaje debería ir protegido por una extensión de autentificación FA-FA definida en [RFC 3344].

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo A S R P


Care-of Address (Dirección del MMA)

Identificador


Figura 6.3 Formato mensaje ‘Multicast Prune Request’ para el Handover Abrupto.

Tras la recepción del mensaje de petición de abandono del árbol multicast, la Estación Base antigua actúa como si recibiera un mensaje ‘Leave Group’ del protocolo IGMPv2 [RFC 2236]. El comportamiento, a partir de este momento, dependerá del protocolo multicast con el que se trabaje. En el caso de PIM-SM, la estación base transmitirá, en caso de que fuera necesario, un mensaje de recorte denominado ‘Prune’ [RFC 2362].


230

6.4 ESQUEMA DE HANDOVER SEMI SUAVE

Este esquema está pensado para sistemas en los que el nodo móvil tiene capacidad para comunicarse con las dos estaciones base de manera simultánea, y sería el equivalente a las soluciones sin redireccionamiento de ‘Hawai’ y al handover semi suave de ‘Cellular IP’, (ver punto 4.4.3).

El modo de funcionamiento es bastante similar al Handover

Abrupto detallado en el punto anterior, explotando ahora la capacidad de comunicación simultanea. Así, el nodo móvil, tras tener constancia de que ha entrado en la zona de cobertura de la nueva estación base, se comunica con ella, transmitiéndole un mensaje ‘Intra-Domain Registration Request’. Sin embargo, y a diferencia del esquema anterior, el nodo móvil sigue recibiendo paquetes vía la Estación Base antigua.

La nueva estación base se conecta con el árbol multicast, por

ejemplo utilizando un mensaje ‘Join’ de PIM-SM o SSM. Al igual que en el Handover Abrupto, el mensaje se transmitirá hasta que se alcance el Nodo de Cruce, y será confirmado por medio de un mensaje ‘ACK Join’. Cuando tiene la confirmación de la correcta conexión al árbol multicast, la nueva Estación Base envía al móvil un mensaje ‘Intra-Domain Registration Reply’, indicativo de la finalización del proceso de handover y de la posibilidad de recibir paquetes a través de esa estación.

Idealmente el nodo móvil permanece en la zona de solape mientras

se produce el proceso de handover, por lo que en ningún momento ha perdido la posibilidad de enviar o recibir paquetes. Una vez se ha realizado el proceso de handover, el nodo móvil va a utilizar a la nueva estación base para comunicarse, por lo que ya no es necesario que oBS permanezca conectada al árbol multicast.

El nodo móvil le enviará un mensaje ‘Multicast Prune Request’ a la

estación antigua indicándole que puede iniciar el mecanismo para abandonar el grupo multicast. Como puede observarse el proceso es ligeramente diferente al visto anteriormente, pues ahora es el nodo móvil quién transmite directamente el mensaje a la estación, en vez de realizarse


231

a través de nBS. Esta solución, posible gracias a la comunicación simultanea del MN con las dos estaciones, permite un mayor control por parte del MN. Así se que podría, por ejemplo, retardar ligeramente el envío del mensaje logrando un cierto mecanismo de histéresis. El mensaje ‘Multicast Prune Request’ empleado en este esquema es el mismo que el mostrado en la figura 6.2, diferenciándose únicamente en la activación de un bit ‘S’ indicativo del Handover Semi Suave y en la no activación de los bits restantes (‘A’, ‘R’ y ‘P’).

Figura 6.4. Esquema del proceso de Handover Semi Suave.

Beacon

Join

ACK Join

Datos

Intra-Domanin Registration Request

Datos en Multicast

Intra-Domanin Registration Reply

Datos en Multicast

Datos


Leave Group



232

La figura 6.4 muestra el proceso de handover descrito, donde puede observarse las similitudes con el handover abrupto del punto anterior. Es destacable la capacidad del nodo móvil de comunicarse simultáneamente con las dos estaciones base mientras dura todo el proceso.

6.4.1 Limitaciones del mecanismo de Handover Semi Suave

Idealmente, el nodo móvil no va a perder en ningún momento la conectividad con la red, pues logra finalizar el handover con una nBS cuando aún puede comunicarse con oBS. Sin embargo, esto no garantiza un handover suave, sin pérdida ni duplicidad de paquetes, en todas las situaciones.

Así, podemos suponer que la zona controlada por la Estación Base

antigua soporta un tráfico elevado. En esta situación la estación tendrá almacenados un conjunto de paquetes dirigidos hacia el nodo móvil, a la espera de poder se transmitidos por el enlace radio. Al producirse un handover la nueva Estación Base se conecta al árbol multicast, y comienza a recibir paquetes que redirige hacia al nodo móvil. Ahora el nodo móvil puede haber recibido paquetes (vía nBS) mientras que aún no habría recibido paquetes anteriores por estar a la espera en la cola de oBS. Incluso podría salir de la zona de cobertura (o desconectarse de oBS) y esos paquetes no los recibiría. En el mejor de los casos los paquetes llegarían al nodo móvil de manera desordenada, o incluso duplicados.

En la figura 6.5 se muestra este caso. En (a) el MN está recibiendo

datos de oBS, pues aun no se ha iniciado el proceso de handover. La estación oBS tiene en memoria los paquetes 2, 3 y 4 y recibe el 5. En (b) puede observarse como nBS se ha conectado al árbol multicast y empieza a recibir el paquete 7. En ese momento envía al MN un mensaje ‘Intra-Domanin Registration Reply’. En (c) el nodo móvil envía un mensaje a oBS indicándole que se desconecte del árbol multicast pues se ha realizado un handover. A partir de ese instante no recibe paquetes de esta estación. Por tanto, los paquetes 5 y 6 nunca serán recibidos por el MN, y el paquete 4,


233

puede que llegue desordenado (posterior al paquete 7), o que tampoco sea recibido. En (d) se muestra el sistema una vez el handover ha finalizado.

Figura 6.5. Handover Semi Suave con pérdida de paquetes.

Una situación similar podría ocurrir si el retardo entre la Estación

Base antigua y el Nodo de Cruce y es sensiblemente superior al existente entre este último y la nueva Estación Base. Aquí paquetes en tránsito

(c)

oBS

Nodo de Cruce

nBS

MN

7

3

654

7

(b)

oBS

Nodo de Cruce

nBS

MN

5

1

432

(a)

oBS

Nodo de Cruce

nBS

MN

8

4

765

8

7

MPR

oBS

Nodo de Cruce

nBS

MN

10 9

11

8

(d)


234

hacia oBS podrían se transmitidos más tarde que paquetes posteriores que son transmitidos vía nBS.

La figura 6.6. muestra esta situación, justo en el instante en que la

nBS se ha conectado al árbol multicast y ha recibido el mensaje ‘ACK Join’. El retardo en el enlace oBS-NC es mayor que en el enlace nBS-NC. Así cuando la nueva estación se conecta al árbol multicast recibe paquetes a partir del 11, mientras que los anteriores aún no han llegado a la estación antigua. Como en el caso anterior esto se traduce en una posible pérdida de paquetes.

Figura 6.6 Handover Semi Suave con pérdida de paquetes (b).

Las situaciones comentadas no son habituales y el número de

paquetes perdidos en un Handover Semi Suave es muy bajo. Las soluciones para lograr un handover suave completo, sin pérdida de paquetes, tienen el inconveniente que aumentan el tiempo de latencia del proceso handover. La principal característica del Handover Semi Suave es lograr, de forma sencilla, un buen comportamiento con respecto al número de paquetes perdidos, con un tiempo de latencia nulo. Por esto, en la mayoría de las situaciones no conviene buscar soluciones a esta pequeña perdida de paquetes, ya que se realiza a costa de complicar el esquema y de introducir un tiempo de interrupción en la comunicación.

oBS

Nodo de Cruce

nBS

MN

9

4

87

6

11

11

10

3


235

6.5 ESQUEMA DE HANDOVER SUAVE CON FINALIZACIÓN CONTROLADA

Existen situaciones en las que se necesita un handover que

garantice la entrega de todos los paquetes. Para estos casos es posible modificar ligeramente el protocolo anterior. Se puede optar entre dos soluciones diferentes, comentadas a continuación.

La primera solución sería introducir algún mecanismo de

retransmisión de paquetes desde oBS a nBS. Esta solución se aplica, generalmente, en sistemas en los que el nodo móvil no puede comunicarse con las dos estaciones de manera simultánea, aunque también sería posible aplicar esta técnica en el Handover Semi Suave. Desde mi punto de vista, la latencia que introduce no lo hace aconsejable en este caso. En el punto siguiente se estudia el esquema de handover con retransmisión.

Una segunda solución, totalmente novedosa, consiste en retrasar

conscientemente la finalización del proceso de handover. Con esto le damos tiempo a la estación antigua para transmitir los paquetes pendientes. El handover podría denominarse ‘Handover Suave con Finalización Controlada’ y está gestionado completamente por el nodo móvil.

Como se ve en la figura 6.7, el inicio del proceso de handover es

idéntico al estudiado hasta ahora. Cuando la nueva estación base recibe el mensaje ‘ACK Join’, transmite el correspondiente ‘Intra-Domanin Registration Reply’ al MN. A partir de ahora nBS empieza a recibir los paquetes dirigidos al nodo móvil, pues la estación está conectada al árbol multicast. Sin embargo, esos paquetes no van a ser transmitidos por el interfaz radio, si no que se almacenan temporalmente en la estación. El nodo móvil, por su parte, puede transmitir a través de nBS, pero sigue recibiendo paquetes desde oBS, retardando el envío del mensaje ‘Multicast Prune Request’. De esta manera se permite recibir los paquetes que eventualmente tiene almacenada la estación base antigua. Tras un


236

cierto tiempo configurable, o bien cuando la señal de la estación base antigua baja de cierto umbral crítico (por ejemplo utilizando un ‘trigger’), el nodo móvil finaliza el proceso de handover. Para ello envía el mencionado mensaje de recorte multicast a oBS y transmite un nuevo mensaje, que denominamos ‘Handover Switch Indication’ a nBS.

Figura 6.7 Esquema del proceso de Handover Suave con Finalización Controlada.

Beacon

Join

ACK Join

Datos


Datos en Multicast

Intra-Domain Registration Reply

Datos en Multicast

Datos

Multicast Prune Request Leave Group


Futura pérdida de conexión con oBS

Handover Switch Indication

Datos Almacenados

Datos en Multicast Datos


237

El mensaje ‘Handover Switch Indication’ tiene la finalidad de indicarle a nBS que puede comenzar a transmitir paquetes hacia él. Es importante indicar, de alguna manera, qué paquetes IP ya ha recibido el MN. En caso contrario es probable que el nodo móvil reciba paquetes por duplicado, lo cual es casi tan negativo como perderlos (punto 4.4.1). El formato del mensaje que proponemos se explica en el punto 6.5.1 (figura 6.9).

Cuando la nueva estación base recibe el mensaje ‘Handover Switch

Indication’ se da por concluido el proceso de handover. La estación utilizará el mensaje para localizar el último paquete recibido por el nodo móvil. Éste y todos los paquetes anteriores son descartados. Los paquetes posteriores no han sido recibidos por el nodo móvil, y por tanto, deben ser transmitidos por nBS hacia al nodo móvil. En caso de que la nueva estación base no disponga del último paquete recibido por el móvil, se supone que éste era previo a los almacenados por la estación, de manera que se transmitirán todos los almacenados. Si el nodo móvil puede permanecer en la zona de cobertura el tiempo suficiente para que oBS vacíe las colas de paquetes dirigidos hacia él se logra un handover suave con latencia nula.

El envío del mensaje ‘Handover Switch Indication’ podría ser

confirmado por medio de un mensaje de reconocimiento enviado por nBS. Sin embargo se ha optado por utilizar los datos recibidos como confirmación de que el mensaje ha llegado correctamente a nBS. En caso de no recibir paquetes vía nBS, un temporizador forzaría al MN a reenvío del mensaje. No obstante, en el esquema de handover siguiente se describe la utilización de un mensaje de respuesta que también podría utilizarse como confirmación en este esquema.

En la figura 6.8 puede observarse las fases (c) y (d) de la figura 6.5

comentada anteriormente. Las dos primeras fases, (a) y (b), no se muestran al ser idénticas al protocolo anterior. En la fase (c) ambas estaciones están conectadas al árbol multicast, por lo que reciben los


238

paquetes dirigidos hacia el nodo móvil. Sólo oBS transmite por el interfaz inalámbrico.

La figura (d) muestra el proceso de finalización del handover. El

nodo móvil envía un mensaje ‘Multicast Prune Request’ a oBS y un mensaje ‘Handover Switch Indication’ a nBS, indicándole el último paquete recibido, 6. En ese instante la estación nueva empezará a enviar los mensajes almacenados a partir del indicado, mientras que oBS iniciará el proceso de abandono del árbol multicast.

Figura 6.8 Funcionamiento sin pérdidas.

6.5.1 Formato del mensaje ‘Handover Switch Indication’

El formato del mensaje que proponemos puede observarse en la figura 6.9. El campo ‘Tipo’ sería el correspondiente a este mensaje, asignado por IANA. Los campos de ‘Dirección Multicast’ y ‘Care-of Address’ se utilizan para identificar la pila de paquetes donde ha almacenado los paquetes dirigidos al nodo móvil. Los siguientes tres campos tienen el objetivo de identificar unívocamente el último paquete

oBS

Nodo de Cruce

nBS

MN

10

6

987

10

(c)

987 oBS

Nodo de Cruce

nBS

MN

10 9 8

11

7

(d)

Prune

MPR HSI (6)


239

que el nodo móvil ha recibido. En concreto son la dirección IP fuente, y los campos ‘Identificador’ y ‘Fragmento’ de la cabecera IP.

Los campos ‘Identificador’ y ‘Fragmento’ se utilizan en redes IP para

poder fragmentar los paquetes IP y adaptarlos al MTU (Unidad de Transferencia Máxima) de los enlaces que atraviesa. Así los diferentes paquetes IP que se envían a un destino tienen números de Identificador sucesivos. En el caso de fragmentar el paquete ese número no cambia, pero se utiliza el campo ‘Fragmento’ para especificar el orden y poder reconstruir el paquete original. El resultado es que no existirán dos paquetes IP de una fuente a un destino con estos dos campos iguales. Para evitar la probabilidad que diferentes fuentes envíen paquetes a un mismo MN, con igual número de ‘Identificador’ y de ‘Fragmento’, se envía también la dirección IP de la fuente. Por motivos de seguridad, el mensaje ‘Handover Switch Indication’ irá terminado por una extensión de seguridad MN-FA definida en [RFC 3344].

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo Longitud



Dirección Fuente del último paquete

Identificador del último paquete Fragmento del último paquete


Figura 6.9 Formato mensaje ‘Handover Switch Indication’.

La utilización de los campos de la cabecera IP no es la única

solución, aunque, desde nuestro punto de vista, sí la más sencilla. Otras opciones serían: utilizar información de protocolos de nivel superior, como el campo de número de secuencia del protocolo TCP, o incluso emplear el protocolo RTP; añadir un número de secuencia en el campo opciones de la cabecera IP; añadir el número de secuencia en el campo de opciones de la


240

cabecera multicast y transmitir ésta hasta el nodo móvil; o finalmente añadir número de secuencia en la cabecera multicast y hacer que el mensaje ‘Handover Switch Indication’ lo envíe oBS a nBS. Todas las soluciones, pese a ser más clarificadoras por disponer de un campo de número de secuencia, y por tanto más atractivas, afectan a las prestaciones del handover, por lo que han sido finalmente descartadas.

6.5.2 Coexistencia de los esquemas de handover

El esquema mostrado en este punto puede ofrecer una ventaja con respecto al Handover Semi Suave presentado anteriormente. Sin embargo hay situaciones en que esto no es así, y sería preferible no utilizar el handover con finalización controlada. Un ejemplo de esto sería cuando el enlace nBS-CN es mucho más lento que el enlace oBS-CN. Se ha diseñado un mecanismo que permite que ambos esquemas coexistan en un mismo sistema de micro-movilidad. Para ello se modifica ligeramente el mensaje ‘Intra-Domain Registration Request’ (ver figura 3.16). Así, en los dos primeros octetos del mensaje, existen una serie de bits, que se han mantenido por compatibilidad con [RFC 3344], y que no tienen utilidad en caso de un handover intra dominio. Sería posible utilizar alguno de estos bits, como por ejemplo el bit ‘x’ o el ‘r’, que están siempre a 0, para indicar cual de los dos esquemas de handover se solicita. Se ha dado al nodo móvil la capacidad de indicar el esquema de handover que desea realizar, puesto que es él quien tiene información sobre su velocidad, calidad de la señal recibida de las distintas estaciones base, etc. Sin embargo, la información más importante para decidir el mecanismo a emplear es el estado de la red, y esta información está en manos de las estaciones base. Por ello se necesita un instrumento para enviar esta información al MN. Se ha optado por incluir la información en el mensaje ‘Agent Advertisement’ de manera que el nodo obtiene la información nada más cambiar de zona.


241

El mensaje ‘Agent Advertisement’ (ver figura 3.11) ha sido ligeramente modificado, añadiéndole la extensión que se muestra en la figura 6.10. El campo tipo sería asignado por la IANA, mientras que la longitud de la extensión vendría indicada en el campo correspondiente. A continuación se presenta una serie de entradas para los posibles oBS (estaciones base vecinas de donde puede provenir el nodo móvil). Para cada una de estas estaciones se adjunta la información necesaria para que el nodo móvil decida que tipo de handover desea realizar. Esta información puede ser tan sencilla como indicar si para un handover desde esa oBS es preferible realizar el ‘Handover Semi Suave’ o el ‘Handvover Suave con finalización controlada’, o bien incluir información más compleja, como por ejemplo, información sobre el tiempo que se debería retrasar la finalización del handover controlado. Si la información que envía nBS en estos mensajes es dinámica, por ejemplo porque depende de la carga actual de las estaciones base, será necesario un mecanismo de intercambio de información entre las diferentes estaciones base. Este esquema queda fuera de estudio.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo Longitud Dirección de la Estación Base vecina (1)

Dirección de la Estación Base vecina (1) Datos para selección de Handover BS (1)

........................................

Figura 6.10 Extensión de Información para Handover.


242


Con el fin de lograr un handover suave proponemos un handover con redireccionamiento. Aquí se establece una comunicación entre las dos estaciones base implicadas en el handover, de manera que la estación antigua puede reencaminar, hacia nBS, los paquetes recibidos que aún no han sido enviados al nodo móvil.

Este tipo de handover está pensado para sistemas donde, en un instante de tiempo, el nodo móvil puede comunicarse únicamente con una estación base. Esto no impediría utilizar este esquema en sistemas con capacidad de recepción simultánea de dos BS. De todas formas, para estos sistemas, sería más sencillo implementar una red con las suficientes prestaciones para que no se perdieran paquetes durante el ‘Handover Semi Suave’, o en su defecto, realizar un ‘Handover Suave con Finalización Controlada’.

Como en el caso del handover abrupto el nodo móvil no puede

comunicarse simultáneamente con las dos estaciones base. Así, cuando el MN recibe mensajes ‘Agent Advertisement’ desde la nueva estación base detecta la necesidad de realizar un handover intra-dominio, y transmite el ya conocido mensaje denominado ‘Intra-Domanin Registration Request’ hacia la nueva Estación Base.

Como se detallará a continuación, el principal problema de este

esquema, basado en el redireccionamiento de paquetes, es que ralentiza el proceso de handover, por lo que no es aconsejable en aquellas situaciones en las que se desea un handover lo más rápido posible. Por esto es interesante permitir al MN que decida se desea realizar un handover suave (handover con redireccionamiento) o uno rápido (handover abrupto). Al igual que en el esquema estudiado en el punto anterior, la elección del mecanismo a emplear podría realizarse incluyendo la opción en el mensaje de registro intra-dominio.


243

De manera similar a todos los esquemas de handover propuestos anteriormente, cuando nBS recibe el mensaje de registro intra-dominio debe conectarse al árbol multicast. Adicionalmente, y de manera simultánea, debe comunicarse con oBS para pedir el redireccionamiento de los paquetes pendientes. La comunicación entre las dos estaciones base sólo se puede producir si nBS dispone de la información sobre la identidad de la estación base anterior. Esto se realiza de la misma manera que se propuso cuando se detalló en el handover abrupto. Es decir, incorporando la información al mensaje ‘Intra-Domanin Registration Request’. El formato de éste se muestra en el punto 6.6.2

Figura 6.11. Esquema del proceso de Handover con Redireccionamiento.

Multicast Handover Reply

Beacon

Join

ACK Join

Datos almacenados


Datos en Multicast


Datos en Multicast

Datos

Datos

Leave Group



Datos reencaminados


244

Tras la recepción del paquete de registro, nBS transmite un mensaje a oBS para que le reencamine los paquetes que tiene pendientes de envío hacia el nodo móvil. Adicionalmente, la Estación Base antigua aprovecha el mensaje como indicación para que se desconecte del árbol multicast. Por este motivo se ha decidido aprovechar el mensaje ‘Multicast Prune Request’ que ya está definido en esquemas anteriores. En particular nBS le envía a oBS un mensaje de recorte similar al mostrado en la figura 6.3. La única diferencia sería que ahora activamos el bit ‘R’, indicativo que estamos ante un handover con redireccionamiento, y desactivando el resto de bits. Este mensaje sería equivalente al mensaje ‘Binding Update Message’ sugerido en [PER01] (Work in Progress).

Cuando oBS recibe el paquete ‘Multicast Prune Request’ se desconecta del árbol multicast y reenvía, por medio de un túnel, todos los paquetes almacenados con destino al MN. La nueva estación base obtiene los paquetes y se los reenvía al MN como si fueran paquetes recibidos del árbol multicast.

6.6.1 Solución a los problemas del esquema El esquema presentado tiene algunos inconvenientes. El primero sería que, mientras el mensaje ‘Multicast Prune Request’ se transmite entre las dos estaciones base, ambas están incorporadas al árbol multicast, por lo que pueden recibir por duplicado un pequeño número de paquetes. Esos paquetes serían retransmitidos, junto con los demás, de oBS a nBS, y por tanto enviados dos veces al nodo móvil.

La solución puede ser que nBS almacene, temporalmente, información del primer paquete recibido del árbol multicast. Así, si recibe ese paquete reenviado desde oBS lo descarta junto con todos los que reciba de oBS posteriormente. Por ejemplo la figura 6.12 se muestra a situación cuando oBS acaba de recibir el mensaje ‘Multicast Prune Request’. oBS tiene en el buffer los paquetes 7, 8 y 9 que reenviará hacia nBS, para que a su vez se transmitan al nodo móvil. El problema es que el


245

paquete 9 ya lo ha recibido nBS por el árbol multicast, por lo que el nodo móvil acabaría recibiéndolo por duplicado.

Figura 6.12 Problema por duplicación de paquetes en el handover indirecto.

Un segundo problema sería que pueden existir paquetes perdidos durante el proceso de handover. En particular, cuando el nodo móvil comenzó el proceso de handover vía nBS ya había perdido conexión con la estación base anterior. Eso significa que existe un tiempo de latencia, donde el nodo móvil no tiene conexión con oBS, y nBS aún no se ha conectado al árbol multicast. Durante este tiempo la Estación Base antigua ha estado transmitiendo paquetes por el interfaz radio, que no han sido recibidos por el nodo móvil, y que por tanto se han perdido. La propuesta de que las estaciones base almacenen los últimos paquetes transmitidos es una buena solución, siempre que el tamaño de esta memoria se dimensione adecuadamente. En caso contrario puede que se continúen perdiendo paquetes, o bien que paquetes entregados realmente al nodo móvil estén todavía en el buffer, en cuyo caso se transmitirían hacia nBS y, como en el problema anterior, acabarían duplicados en el MN. La figura 6.13 muestra el mecanismo de almacenamiento temporal de paquetes ya transmitidos. En este ejemplo el paquete 5 sigue almacenado en oBS a pesar de que ha sido recibido por

oBS

Nodo de Cruce

nBS

MN

10

987

10

9

MPR


246

MN. Un redireccionamiento de los paquetes hacia nBS se traducirá en una recepción duplicada, por parte del nodo móvil, del paquete número 5.

La solución que proponemos a este segundo problema es similar a la que se empleó en el ‘Handover Suave con Finalización Controlada’ estudiado en el punto anterior. Consiste en que el nodo móvil indique, en el mensaje ‘Intra-Domanin Registration Request’, el último paquete recibido. En el punto 6.6.2 se muestra como queda finalmente dicho mensaje.

Figura 6.13 Problema por almacenamiento en exceso de paquetes.

La nueva estación base debe incluir esta información, recibida del MN, en el mensaje ‘Multicast Prune Request’ que envía a oBS para que se produzca el redireccionamiento. Ahora la Estación Base antigua simplemente reencaminará los paquetes que tiene almacenados para el MN, y que son posteriores al paquete que se indica el mensaje ‘Multicast Prune Request’ recibido. El formato final que proponemos para este mensaje también se muestra en el punto 6.6.2. Para simplificar el proceso, el mensaje ‘Multicast Prune Request’ no es confirmado. La estación base antigua, tras recibir el mensaje, contesta simplemente enviando los paquetes pendientes. Es decir, se está utilizando el reenvío de los paquetes como mecanismo de reconocimiento. Si, tras la

Paquetes recibidos y no transmitidos

oBS

Nodo de Cruce

nBS

MN

765

98

765

Paquetes ya transmitidos pero almacenados temporalmente

Paquetes recibidos por el nodo móvil

MPR


247

espera de un cierto tiempo, nBS no recibe ningún paquete, se supone que el mensaje ‘Multicast Prune Request’ se ha perdido, por lo que lo enviaría de nuevo. Si se desea puede implementarse un mecanismo de confirmación explícito, simplemente incorporando un mensaje de reconocimiento que enviaría oBS. Este mensaje lo denominamos ‘Multicast Handover Reply’, y la propuesta del formato se muestra en el siguiente punto.

Como se aprecia en la figura 6.14, durante el handover los paquetes pueden llegar al nodo móvil de manera desordenada. En concreto los paquetes temporalmente almacenados en oBS, y que están siendo redireccionados hacia nBS, puede que sean transmitidos al nodo móvil más tarde que otros paquetes que recibe nBS por estar conectado al árbol multicast.

Figura 6.14 Posible desorden de paquetes durante el Handover.

En la bibliografía donde se proponen soluciones de handover

similares al ‘Handover con redireccionamiento’, por ejemplo [PER01], [PER99], no se plantea ningún mecanismo que evite el desorden de los paquetes. Tan solo el sistema Hawaii, donde los routers tienen extendidas sus capacidades, soluciona el problema, haciendo que el

oBS

Nodo de Cruce

nBS

MN

9

98

10

7


248

redireccionamiento este controlado por el Nodo de Cruce (ver mecanismo SSF de Hawaii en el punto 4.4.3).

En mecanismo de handover propuesto en este punto se podría

modificar para intentar solucionar el problema. La idea básica sería que oBS enviara el mensaje de confirmación ‘Multicast Handover Reply’ hacia nBS una vez ha acabado el redireccionamiento de los paquetes almacenados. Mientras nBS, en vez de transmitir los paquetes que recibe del árbol multicast, podría almacenarlos a la espera del mensaje de oBS. Esta solución se complica en el caso de que el mensaje ‘Multicast Handover Reply’ se pierda o llegue con errores, pues en este desafortunado caso, la nueva Estación Base no comenzaría nunca su transmisión.

Las posibles complicaciones de la solución al problema del

desorden de los paquetes, junto al hecho de que el problema no es tan grave como una pérdida o una duplicación de paquetes, hacen que finalmente no nos decantemos por la implementación de la misma. Es decir, el desorden de los paquetes será solucionado por las capas superiores. Al fin y al cabo, el protocolo IP es un protocolo no orientado a la conexión y se asume que los paquetes que viajan por la red pueden desordenarse. Así, en el caso de utilizar el protocolo TCP será este quién solucione el problema, mientras que si se utiliza el protocolo de transporte UDP, la solución se dará a nivel de aplicación, por ejemplo basándose en la numeración de los mensajes que proporciona el protocolo RTP [RFC 1889].

6.6.2 Formato de los mensajes utilizados en este esquema Mensaje ‘Intra-Domanin Registration Request’

En mensaje ‘Intra-Domanin Registration Request’ se ha incorporado información sobre la identidad de la estación base anterior, necesaria para que nBS pueda comunicarse con ella.


249

Se ha modificado el segundo octeto del mensaje que se proponía en el capítulo 3 (ver figura 3.16). Ahora existe un campo que indica el tipo de handover que se desea realizar, de manera que se unifica los diferentes esquemas de handover propuestos en este capítulo.

Con el fin de indicar la dirección de la Estación Base anterior se

podría optar por añadir la extensión que se propuso en el handover abrupto (figura 6.2) donde también hacía falta conocer la dirección de oBS.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo S B D M G Hand. Tiempo de vida

Home Address

Care-of Address


Identificador




Figura 6.15 Formato del mensaje ‘Intra-Domanin Registration Request’ para el

esquema de Handover abrupto.

Sin embargo, hemos comentado que en éste esquema de handover

el nodo móvil necesita indicar a nBS información sobre el último paquete recibido de oBS. La figura 6.16 muestra como se ha modificado la extensión de la figura 6.15, ampliada para contener esta información.


250

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1





Figura 6.16 Extensión del mensaje ‘Intra-Domanin Registration Request’ para el

esquema de Handover con redireccionamiento.

Mensaje ‘Multicast Prune Request’

El mensaje ‘Multicast Prune Request’ que se mostró en la figura 6.3 para el handover abrupto ha sido modificado para que incorpore información sobre el último mensaje recibido por el MN.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo A S R P



Identificador




Figura 6.17 Formato del mensaje ‘Multicast Prune Request’.

Así el mensaje quedaría como el mostrado en la figura 6.17. El bit ‘R’ indica que estamos ante un handover con redireccionamiento. Como ya se ha comentado con anterioridad, los campos Dirección fuente, Identificador del último paquete y número de fragmento permiten a oBS identificar unívocamente el último paquete recibido por MN. De esta


251

manera oBS reenviaría hacia nBS sólo los paquetes almacenados que son posteriores.

‘Multicast Handover Reply’ En la figura 6.18 se muestra la propuesta del mensaje ‘Multicast Handover Reply’ que en el mecanismo de handover es opcional. Como en todos los mensajes anteriores, el campo ‘Tipo’ sería asignado por la IANA. El campo ‘Estado’ indicaría la respuesta al mensaje ‘Multicast Prune Request’. Posibles respuestas, además de la confirmación positiva, serían que la dirección multicast del móvil no aparece en sus tablas, o bien simplemente que no existen paquetes pendientes. El campo ‘Identificador’ contiene el mismo valor que el recibido en el mensaje ‘Multicast Prune Request’, y sirve para asociar peticiones a respuestas. Como en todos los mensajes propuestos anteriormente, el mensaje debe terminar con una extensión de autentificación FA-FA.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tipo Estado



Identificador


Figura 6.18 Formato del mensaje ‘Multicast Handover Reply’.

Es interesante comentar que este mensaje ‘Multicast Handover Reply’ propuesto puede ser utilizado también en los otros esquemas de handover detallados en puntos anteriores. Así, podría utilizarse en el ‘Handover Suave con Finalización Controlada’, para confirmar el la recepción del mensaje ‘Handover Switch Indication’ enviado del nodo móvil a nBS. La confirmación de otros mensajes, como los mensajes ‘Multicast Prune Request’ de los esquemas de handover ‘Abrupto’ o ‘Semi Suave’, no


252

es necesaria, pues la pérdida de los mismos no afecta de manera importante al buen funcionamiento del esquema.

La figura 6.11 mostraba un diagrama temporal del ‘Handover con Redireccionamiento’, donde se ha incluido el mensaje ‘Multicast Handover Reply’ que hemos definido como opcional.


El esquema anterior intentaba obtener un handover suave, donde primara la entrega de todos los paquetes. Por el contrario, existen determinadas situaciones, como cuando se ejecutan aplicaciones de tiempo real, donde el objetivo fundamental es conseguir un handover con baja latencia.

En sistemas donde el nodo se puede comunicar con las dos

estaciones base de manera simultanea, el handover será siempre con baja latencia, ya que si la zona de solape es lo suficientemente amplia, el nodo no tendrá interrupción en la comunicación. En los puntos 6.4 y 6.5 se han estudiado ejemplos de handovers que trabajan con esta situación.

En este punto se va a proponer un handover de baja latencia para

sistemas donde, en un instante de tiempo, el nodo móvil solo se puede comunicar con una estación base. El esquema, denominado ‘Handover con Pre-registro’ está basado en la utilización de ‘triggers’ [YEG02] (Work in Progress). Actualmente existe alguna solución semejante en proceso de investigación, [ELM02], [KOO02], aunque tan solo están aplicadas al protocolo Mobile IP original, y a sistemas con Registro Regional (RR-MIP, ver punto 2.3.7).

La idea es enviar un mensaje a nBS (utilizando para ello a oBS)

para que comience su incorporación al árbol multicast instantes antes de realizar el handover de nivel 2. El fin es disminuir los componentes de la


253

latencia del handover (punto 4.2), tanto el tiempo de detección de movimiento, Tmove-detect, utilizando para ello ‘triggers’, como el tiempo de redireccionamiento, Tredirect, adelantándolo y solapándolo al primero.

Como se propone en [ELM02], previamente al inicio del proceso de

handover las diferentes Estaciones Base intercambian mensajes ‘Agent Advertisement’, solicitados mediante mensajes ‘Agent Solicitation’ y almacenados temporalmente en memoria.

El nodo móvil, tras recibir un trigger L2 indicando que se va a

producir, en un futuro próximo, un handover a nivel dos (ver tabla 4.1), envía un mensaje del tipo ‘Proxy Agent Solicitation’ a oBS, con quién evidentemente tiene conexión. Este mensaje es idéntico al mensaje tradicional, que según se define en [RFC 3344] se corresponde con un mensaje ‘ICMP Router Solicitation’, excepto por una extensión que indicaría que la solicitud es para nBS.

oBS responde a la petición enviando el mensaje ‘Agent Advertisement’ que tenía previamente almacenado de nBS. Dependiendo de quién inicia el proceso de handover, este mensaje podría haber sido enviado directamente por oBS aunque no existiera solicitud previa.

El nodo móvil detecta la necesidad de realizar el handover intra-dominio, y por tanto envía un mensaje ‘Intra-Domanin Registration Request’ dirigido hacia nBS. Sin embargo, el móvil no tiene conectividad con esta estación, pues el proceso de handover a nivel 2 no se ha producido. Así el mensaje de registro deberá ser transmitido vía oBS. La figura 6.19 muestra el diagrama temporal del Handover con Pre-registro.

Tras la recepción del mensaje, nBS se comporta como si hubiera

recibido directamente el mensaje por el interfaz inalámbrico, es decir, realizando la incorporación al árbol multicast. El mensaje ‘Intra-Domanin Registration Reply’, indicativo de que se ha realizado correctamente el proceso de handover L3, será entregado al nodo móvil tan pronto se complete el handover de nivel dos. Esta detección se realizará típicamente utilizando un trigger ‘L2-UP’ en nBS.


254

Figura 6.19 Esquema del proceso de Handover con Pre-registro.

Como en los esquemas anteriores, tan solo quedaría avisar a oBS del handover que ha realizado el nodo móvil, a fin de que pueda liberar recursos. Una opción es que la propia oBS detecte que el nodo móvil ha realizado un handover, utilizando para ello un trigger ‘L2-LD’ (ver tabla 4.1).

TriggerL2-LU

TriggerL2-MT

Join

ACK Join




Proxy Agent Solicitation

Proxy Agent Advertisement


Multicast Prune Request Leave Group



255

Otra solución es que nBS informe a oBS. Así, nBS transmite, de manera simultanea al envío del mensaje de reconocimiento de registro hacia NM, el mensaje denominado ‘Multicast Prune Request’ con dirección oBS. Este mensaje sería similar al mostrado en la figura 6.3, con la diferencia de que ahora se activa el bit ‘P’. Como en el caso del ‘Handover Abrupto’, para que la nueva Estación Base tenga conocimiento de la dirección IP a donde enviar el paquete, será necesario añadir al mensaje ‘Intra-Domain Registration Request’ la extensión mostrada en la figura 6.2.

6.8 RESUMEN Y CONCLUSIONES DE LOS ESQUEMAS DE HANDOVER PROPUESTOS

Al estudiar el concepto de handover se indicó que existen dos

características fundamentales. La primera es el número de paquetes que se pierden durante el proceso. Aparece así el término de ‘Handover Suave’ [MAN02], relativo al esquema que tiene por objetivo minimizar la pérdida de paquetes. Tradicionalmente se utilizan dos técnicas para lograr la entrega de todos los paquetes. Una opción sería introducir algún mecanismo de retransmisión de paquetes pendientes desde oBS a nBS. Otra posibilidad sería realizar una transmisión dualcast temporal de manera que las dos estaciones implicadas reciben los paquetes dirigidos al nodo móvil.

La segunda característica de los esquemas de handover es el

retardo que sufren los paquetes. Así tenemos el concepto de ‘Handover Rápido’, referido a los procesos de handover que tienen como su principal motivación la entrega de paquetes con retardo mínimo. También aquí la bibliografía presenta distintas soluciones que intentan minimizar este retardo. Una solución sería minimizar la latencia del proceso de handover, por ejemplo adelantando el inicio basándonos en la utilización de ‘triggers’. Otra solución sería no interrumpir la entrega de paquetes mientras dura el handover, por ejemplo implementando en los nodos móviles la capacidad de hablar simultáneamente con las dos estaciones base.


256

El sistema de micro-movilidad basado en multicast, presentado en el capítulo 3, ofrece unas propiedades intrínsecas idóneas para lograr, tanto handovers intra-dominio rápidos, como suaves.

En particular, el tiempo de latencia del handover se reduce al

mínimo. Así, el componente del tiempo de latencia que denominamos ‘Retardo en la Recuperación de una Dirección Temporal’ (Tco-retrieval), se elimina por completo. Además, el tiempo ‘Retardo de reestablecimiento de la ruta’ (Tredirect) se reduce al tiempo necesario para la conexión de la nueva Estación Base al árbol multicast.

Con respecto a la transmisión sin pérdidas de paquetes, el sistema

de micro-movilidad presentado se basa en la conexión de las estaciones base a un árbol multicast asociado al nodo móvil. Esto lleva implícito una transmisión de paquetes hacia las dos estaciones de manera simultánea, facilitando enormemente la implementación de handovers suaves.

En este punto hemos elaborado cinco esquemas de handover

diferentes, diseñados para implementarse en el sistema de micro-movilidad propuesto en el capítulo 3. Podemos hacer una clasificación teniendo en cuenta la capacidad que ofrece la red para permitir al nodo móvil de comunicarse o no con las dos estaciones base de manera simultánea.

Por un lado tenemos los esquemas de handover, denominados en la

bibliografía ‘Break-Before-Make’, en los cuales el nodo móvil no es capaz de mantener la comunicación con oBS cuando se realiza el handover con nBS. En este entorno se han propuestos tres esquemas diferentes. El primero ha sido denominado ‘Handover Abrupto’, y aquí nos basamos en las facilidades intrínsecas del sistema de micro-movilidad para diseñar un esquema lo más simple posible. El segundo esquema se ha denominado ‘Handover con Redireccionamiento’ y logra minimizar las pérdidas de paquetes recurriendo a la retransmisión de los paquetes pendientes entre estaciones base. En este esquema se han realizado propuestas novedosas para eliminar la duplicidad de paquetes en el receptor, aunque no se intenta evitar el posible desorden de los paquetes. Por último, el tercer handover se ha denominado ‘Handover Indirecto con Pre-registro’, y su


257

objetivo es ofrecer un handover rápido, minimizando el retardo de entrega de los paquetes, basándose en la utilización de ‘triggers’.

Los otros dos handovers propuestos se basan en la capacidad del

nodo móvil de comunicarse simultáneamente con las dos BS. Estos esquemas se suelen denominar ‘Make-Before-Break’. El primer esquema, llamado ‘Handover Semi-suave’, funciona sobre la base de que mientras nBS se está conectando al árbol multicast el nodo móvil sigue recibiendo paquetes vía oBS. De esta manera, teniendo una zona de solape de coberturas lo suficientemente amplia, se consigue un handover sin retardo y con muy pocas pérdidas. El último esquema, denominado ‘Handover Suave con Finalización Controlada’, es una solución novedosa que ofrece un handover rápido y suave, denominado ‘Sin Degradación’ o ‘Seamless’ en la literatura. Este mecanismo se basa en dar capacidad al nodo móvil para retrasar la finalización de la comunicación con oBS, y la capacidad de nBS de almacenar paquetes hasta que son solicitados por MN.

Para la implementación de estos esquemas se ha tenido que

diseñar distintos mensajes de control, a la vez que modificar o ampliar algunos de los formatos de los mensajes que fueron creados en el capítulo 3. En este desarrollo ha primado el concepto de integración y la visión única del sistema, de manera que los mismos paquetes pueden ser utilizados en los diferentes esquemas.

En concreto se ha diseñado el mensaje ‘Multicast Prune Request’

(figuras 6.3 y 6.17) que, con diversas extensiones, es utilizado en los cinco esquemas de handover. La confirmación a este mensaje, en caso de que el esquema lo requiriera, se realizaría con el mensaje ‘Multicast Handover Reply’ (fig. 6.18).

Adicionalmente se ha diseñado el mensaje ‘Handover Switch

Indication’ empleado en el esquema ‘Handover Suave con Finalización Controlada’ (fig. 6.9)

El mensaje ‘Intra-Domain Registration Request’ ha sido ampliado

con dos extensiones diferentes utilizadas dependiendo del esquema de


258

handover (fig. 6.2 y 6.16). Finalmente el mensaje ‘Agent Advertisement’ se ha ampliado incluyendo una extensión de información que puede observarse en la figura 6.10. La figura 6.20 resume los cinco esquemas de handover propuestos.

oBS

Nodo de Cruce

nBS

MN

1 IDRRq

2 Join

3 Ack Join

4 IDRRp

5 MPRq

6 Leave Group

(a) Handover Abrupto (b) Handover Semi Suave

oBS

Nodo de Cruce

nBS

MN

1 IDRRq

2 Join

3 Ack Join

4 IDRRp

5 MPRq

6 Leave Group

(c) Handover Suave con Finalización Controlada

oBS

Nodo de Cruce

nBS

MN

1 IDRRq

2 Join

3 Ack Join

4 IDRRp

5 MPRq

6 Leave Group

7 HSI

oBS

Nodo de Cruce

nBS

MN

1 IDRRq

2 Join

3 Ack Join

4 IDRRp

5 MPRq

6 Leave Group

(d) Handover con Redireccionamiento

7 MHRp


259

Figura 6.20 Resumen de esquemas de Handover.

La tabla 6.1 muestra un estudio de los cinco mecanismos de handover que hemos propuesto en este capítulo. El significado de las siglas que se han empleado para nombrar los distintos mensajes se puede encontrar en la figura anterior. En la tabla se puede observar como algunos esquemas están pensados para redes en las que el MN tiene la capacidad de comunicarse con las dos estaciones base directamente. Además puede apreciarse como existen soluciones tanto para handovers suaves como rápidos. Se ha habilitado un mecanismo para permitir la elección de un esquema u otro. Esto lo realiza el nodo móvil a partir de los campos habilitados en el mensaje ‘Intra Domain Registration Request’. A su vez hemos diseñado una extensión al mensaje ‘Agent Advertisement’ para el caso de que el MN necesitara información de la red.

IDRRq: ‘Intra Domain Registration Request’ IDRRp: ‘Intra Domain Registration Reply’ MPRq: ‘Multicast Prune Request’ HSI: ‘Handover Switch Indication’ MHRp: ‘Multicast Handover Reply’ PAS: ‘Proxy Agent Solicitation’ PAA: ‘Proxy Agent Advertisement’ oBS

Nodo de Cruce

nBS

MN

1 PAS

4 Join

5 Ack Join

7 MPRq

3 IDRRq

8 Leave Group

(d) Handover con Pre-registro

6 IDRRp

2 PAA


260

Mecanismo de Handover

Comunicación simultanea

con las 2 BS.

Handover Suave

Handover Rápido

Mensajes utilizados

Abrupto No No Si

IDDRq con extensión

IDDRp

MPRq opcional

Semi Suave Si Si con limitaciones Si

IDDRq

IDDRp

MPRq

Suave con finalización controlda

Si Si No

IDDRq

IDDRp

MPRq

HSI

Exten. de Agent Adv.

Con Redireccionamiento No Si No


IDDRp

MPRq con extensión

MHRp opcional

Con Pre-registro No No Si


IDDRp

MPRq

Triggers.

Tabla 6.1 Características básicas de los diferentes esquemas de Handover

propuestos.

Para finalizar la taba 6.2 muestra las ventajas e inconvenientes de los cinco mecanismos de handover que proponemos en este capítulo.


261

Mecanismo de Handover Ventajas Inconvenientes

Abrupto

Sencillo

Rápido

Buenas prestaciones al basarse en multicast.

Se pierden paquetes

Tiempo de interrupción

Semi Suave

Sencillo

Rápido

En muchas situaciones no se pierden paquetes (suave)

En situaciones especiales se pierden o duplican paquetes

Suave con finalización controlda

Handover suave sin pérdida de paquetes

Complejo

Necesario comunicación entre BS

Retardo en paquetes almacenados.

Con Redireccionamiento

Handover suave sin pérdida de paquetes

Complejo

Necesario comunicación entre BS

Retardo elevado en paquetes almacenados.

Con Pre-registro Handover sencillo

Rápido Necesidad de comunicación entre capas (triggers)

Tabla 6.2 Ventajas e Inconvenientes de los diferentes esquemas de Handover.


262

263

7. EVALUACIÓN ANALÍTICA DE LOS MECANISMOS DE HANDOVER INTRA-DOMINIO

7.1 INTRODUCCIÓN En este capítulo se va a desarrollar un modelado analítico de los diferentes esquemas de handover para el sistema de micromovilidad basado en multicast que se propuso en el capítulo anterior. El fin es realizar una comparación de las diferentes soluciones, a la vez que investigar la influencia de algunos parámetros de diseño, como puede ser el tamaño de los ‘buffers’. Los estudios se centrarán en el número de paquetes perdidos debido al mecanismo de handover, así como el retardo adicional que se introduce en los paquetes que, por el modo de funcionamiento del handover, deben ser redireccionados o almacenados. Con el fin de lograr un modelado relativamente simple vamos a optar por modelar los routers como colas M/M/1. Esta suposición ya ha sido utilizada por C. Blondia, quién ha realizado un modelado analítico de algunos sistemas de micromovilidad como Hawaii y Cellular IP [BLO02], [BLO02b]. Así, asumimos que el tiempo de servicio de un paquete en un router está distribuido exponencialmente, e incluye el tiempo de procesamiento y el tiempo de transmisión. Si llamamos µ a la tasa de servicio de un router A, y ρ a la carga, este tiempo de respuesta AR estará distribuido exponencialmente con una tasa de µ(1-ρ), [KLE75]. El retardo de propagación entre dos routers se considerará fijo y se indicará mediante el formato ( )YX RR , . Finalmente el retardo entre la estación base y el nodo móvil lo consideramos despreciable. Para estandarizar los cálculos, los modelos analíticos de todos los esquemas de handover van a considerar arquitecturas de red como las mostradas en la figura 7.1. En particular, para aquellos mecanismos de

Evaluación analítica.

264

handover en los que se requiere una comunicación entre las dos estaciones base, se optará por la figura 7.1b, que independiza la estructura del árbol multicast de la estructura de la red (handover con redireccionamiento y handover con pre-registro). Para todos los demás casos se utilizará la arquitectura 7.1a.

Figura 7.1 Esquema de la Red para el modelado analítico.

7.2 ESQUEMA DE HANDOVER ABRUPTO

7.2.1 Desarrollo analítico Para analizar el handover abrupto estudiado en el punto 6.3 partimos de la figura 7.1a. Definimos hot como el instante de tiempo en el que comienza el proceso de handover. En este esquema ese instante se corresponde con el instante de tiempo en el que el nodo móvil deja de recibir paquetes de la estación antigua oBS. Definimos 1t como el instante de tiempo a partir del cual los paquetes que alcancen el nodo de cruce CN se perderán porque llegarán al

MN MN

R2R1

oBS

Nodo de Cruce CN

nBS

a)

R1 oBS

Nodo de Cruce CN

nBS

R2

R3

b)

Evaluación analítica

265

nodo móvil después del instante hot . Por último definimos 2t como el instante de tiempo en el que el nodo de cruce recibe, vía nBS, la información de que se ha producido un handover (mensaje ‘Join’ de la figura 6.1). Por tanto, a partir de este instante se restablecería la comunicación, dejándose de perder paquetes. Siguiendo la nomenclatura explicada anteriormente podemos calcular 1t como sigue:

[ ]oBSoBSRRRCNCNtt ho ++++−= ),(),( 1111 (7.1) En la ecuación anterior el valor 1t es igual al tiempo en el que se produce el handover al que le restamos unos retardos fijos y los tiempos de procesamiento de los diferentes dispositivos, que seguirán una distribución exponencial. Podemos simplificar la ecuación de la siguiente manera:

[ ]cXtt ho +−=1 (7.2) siendo ),(),( 11 oBSRRCNc += una constante y X una variable aleatoria con función de densidad de distribución )(tf X , que ha sido calculada como la convolución de las densidades de distribución de los dispositivos implicados, y que se corresponde con una densidad de distribución Erlang.

tX ettf

23

2)( ββ −= para 0≥t y con )1( ρµβ −=

Del mismo modo podemos describir 2t como sigue:

),(),( 2222 CNRRRnBSnBShtt ho ++++∆+= (7.3) En esta expresión, h∆ se corresponde con el tiempo que le cuesta al nodo móvil detectar que se ha producido el handover y que ha pasado a depender de nBS. Ya que el mecanismo de handover abrupto no ofrece la utilización de ‘triggers’ [YEG02] que agilicen la detección, este tiempo de detección dependerá del periodo de envío los mensajes ‘Agent Advertisement’, que en el protocolo Mobile IP [RFC 3344] se realiza cada


266

segundo. Así h∆ es una variable aleatoria con una función de densidad de distribución uniforme entre 0 y el periodo de envío de mensajes ho∆ . Simplificando la expresión como se hizo anteriormente con 1t :

dYhtt ho ++∆+=2 (7.4) con

),(),( 22 CNRRnBSd +=

tY tetf 2)( ββ −= para 0≥t y con )1( ρµβ −=

Con el fin facilitar el desarrollo analítico podemos, sin perder generalidad, asignar a 1t el valor 0:

[ ] 01 =+−= cXtt ho ⇒ cXtho += (7.5) Así el valor 2t quedaría, tras sustituir (7.5) en (7.4) y simplificar:

eZht ++∆=2 (7.6) con:

dce +=

tZ ettf

45

!4)( ββ −= para 0≥t y con )1( ρµβ −= (7.7)

Consideremos ahora un flujo de paquetes que, generados por un host, llegan al nodo de cruce con un tiempo entre llegadas constante de T mseg. Al haber normalizado el tiempo 01 =t , los paquetes que pueden perderse serán aquellos que llegan al nodo de cruce CN en un tiempo positivo. Para eliminar cualquier dependencia con el instante en que se produce el handover, el instante en que llega el primer paquete susceptible de que se pierda durante el proceso de handover lo denominamos u, y es un valor aleatorio uniformemente distribuido entre [0,T].


267

La probabilidad de que el paquete k-ésimo, que llega a CN en el instante de tiempo (k-1)T+u, se pierda, la denominamos kperP − . Esta probabilidad es igual a la probabilidad de que el instante de tiempo en el que llega el paquete sea mayor que 1t y menor que 2t :

[ ] =<+−<=− 21 )1(Prob tuTktP kper

[ ] =++∆<+−<= eZhuTk )1(0Prob

[ ] =−∆−+−>= ehuTkZ )1(Prob

[ ]ehuTkZ −∆−+−≤−= )1(Prob1 (7.8) Tanto u como h∆ son dos variables aleatorias completamente independientes. Por tanto podemos definir una nueva variable como la resta de las dos, huW ∆−= . En el caso de hoT ∆< esta nueva v.a. tiene la función de densidad de distribución siguiente: (7.9) Así, la ecuación (7.8) depende tan sólo de dos variables aleatorias. Podemos por tanto rescribir esta ecuación de la siguiente manera:

[ ] odwwofwoWWeTkZP wkper ∫ =+−−≤−=− )( )1(Prob1 (7.10) Según (7.9) los límites de la integral anterior estarían entre - ho∆ y T, puesto que la función de densidad de distribución )(tfw es 0 fuera de este intervalo. Sin embargo, la v.a. Z no puede ser menor que cero, ya que se corresponde con la suma de los tiempos de respuesta de los diferentes dispositivos. Así el límite inferior de la integral sería: Si hoeTk ∆>−− )1( ⇒ límite inferior = - ho∆ Si hoeTk ∆≤−− )1( ⇒ límite inferior = e-(k-1)T

∆+−∆

∆∆+

=

0)(

1)(

)(hoTTt

hohoThot

tf w

restoTt

tThoThotho

<<≤≤+∆−

+∆−<<∆−

00


268

Es decir:

[ ][ ]∫ −−∆−

− =+−−≤−=T

Tkehowkper dwowofwoWWeTkZobP

)1(,max )( )1(Pr1

Por último, la probabilidad de que la v.a. Z sea menor que un valor dado es equivalente a la función de distribución )(tFz . A partir de (7.7) hemos obtenido dicha función:

∑=

−−=4

0n

! ) ( 1)(

ntetF

nt

zββ (7.11)

Por tanto, la probabilidad de que el paquete k-ésimo se pierda puede representarse finalmente como:

[ ]∫ −−∆−− =+−−−=

T

Tkehowzkper dwowofwoWWeTkFP

)1(,max )( ) )1((1 (7.12)

7.2.2 Resultados Las siguientes gráficas muestran los resultados obtenidos a partir de (7.12). Así en la figura 7.2 observamos la probabilidad de pérdida de los paquetes que alcanzan el nodo de cruce tras el instante t1, cuando variamos el retardo de propagación entre los distintos nodos. Para realizar esta gráfica se ha tomado constantes los siguientes valores: tasa de servicio µ = 10 paquetes por mseg., carga ρ = 0.8, tiempo de llegada de paquetes T = 20 mseg y un tiempo de detección del handover 100=∆ho mseg. El valor del retardo entre dos routers se ha tomado de 5, 10 y 20 mseg. En la figura puede se muestra como, evidentemente, la probabilidad de pérdida disminuye a medida que aumenta el número del paquete. Así el primer paquete se pierde con una probabilidad del 100% en todos los casos, pero, en el caso de tener un retardo de 5 mseg., el séptimo paquete siempre llegará al nodo móvil vía nBS.


269

Figura 7.2 Probabilidad de pérdida del paquete k-ésimo.



270

En la figura 7.3 se muestra la probabilidad de pérdida cuando variamos el tiempo de llegada entre paquetes. En este caso se ha tomado un retardo de 5 mseg. entre nodos y para los restantes parámetros se han mantenido los mismos valores que los utilizados para realizar la gráfica anterior. Se observa como la probabilidad de pérdida aumenta de manera muy significativa al disminuir el tiempo entre paquetes. Es decir, manteniendo un tiempo de handover constante, cuantos más rápido se transmita, más paquetes están involucrados con una probabilidad de pérdida elevada. Podemos relacionar el comportamiento del esquema de handover en función del tiempo entre llegadas T y el retardo de los enlaces. En la figura 7.4 se muestra el número medio de paquetes perdidos en función de T para varios valores de retardo del enlace. Para obtenerla hemos partido de (7.12), que indicaba la probabilidad de la pérdida del paquete k-ésimo. Dicha pérdida implica la pérdida de los (k-1) paquetes anteriores. Por tanto la probabilidad de que se produzca la pérdida de exactamente k paquetes se obtiene a partir de (7.13), y el número de medio de paquetes perdidos se calcula mediante (7.14).

)1( 1 +−= kperkperk PPQ (7.13)

∑≥

=1k

kkQN (7.14)


271

Figura 7.4 Número medio de paquetes perdidos vs. retardo.

Por último podríamos estudiar lo que sucedería si aumentáramos el tiempo en que el nodo móvil tarda en detectar que se ha producido un handover. En las gráficas anteriores se ha definido este tiempo como una distribución uniforme entre 0 y 100 mseg. Hemos supuesto un valor menor que el especificado en [RFC 3344], que sugería un valor de 1 seg. La razón de esto es simple. El protocolo Mobile IP está pensado para macro-movilidad donde no se busca unas altas prestaciones en el handover. Sin embargo, con los sistemas de micro-movilidad se intenta lograr, principalmente, buenas prestaciones durante el handover. Así es necesario buscar soluciones para disminuir este tiempo, bien utilizando ‘triggers’ o bien transmitiendo los mensajes de ‘Agent Advertisement’ con una frecuencia elevada. En la gráfica 7.5 se muestra el comportamiento del esquema de handover cuando se varía el valor ho∆ y se mantienen los restantes parámetros con los valores siguientes: tasa de servicio µ = 10 paquetes por mseg., carga ρ = 0.8, tiempo de llegada de paquetes T = 20 mseg y retardo de 5 mseg. Evidentemente al aumenta el tiempo de detección aumenta el tiempo en el que el MN no tiene cobertura de ninguna BS, aumentando la probabilidad de perder paquetes.


272


7.3 ESQUEMA DE HANDOVER SEMI SUAVE En este punto se va a analizar el handover Semi Suave estudiado en el punto 6.4. En este esquema el nodo móvil es capaz de comunicarse simultáneamente con dos estaciones base. Así, mientras se encuentra en la zona de solape de las coberturas de las dos estaciones, el nodo móvil se comunica con nBS, indicándole que se conecte al árbol multicast. A diferencia del esquema anterior, en esta solución los paquetes, además de perderse, pueden llegar al nodo móvil duplicados. Es necesario, por tanto, realizar el análisis separado de estas dos circunstancias. Basándose en la capacidad de comunicación simultánea del nodo móvil, éste podría comportarse de dos maneras diferentes. La primera sería aceptar todos los paquetes que se reciben de ambas estaciones base mientras se encuentra en la zona de solape. Bajo esta situación es previsible que una zona de solape suficientemente grande permitirá que la


273

perdida de paquetes sea mínima, aunque se producirá una elevada duplicación de paquetes. El segundo modo de operación sería el detallado en el punto 6.4, en el que el nodo móvil, tras recibir el mensaje ‘Intra-Domain Registration Reply’, supone la finalización del proceso de handover, enviando un mensaje ‘Multicat Prune Request’ a oBS y desechando cualquier paquete posterior de esta estación base. Para realizar la evaluación analítica de este esquema se va a partir, como en el caso anterior, de la figura 7.1a. Igualmente vamos a optar por modelar los routers como colas M/M/1. Por tanto asumimos que el tiempo de servicio de un paquete en un router está distribuido exponencialmente, con la tasa de servicio µ y carga ρ.

7.3.1 Pérdida de paquetes del handover sin desconexión de oBS Como se ha comentado anteriormente, un posible modo de funcionamiento permite que el nodo móvil sigua recibiendo paquetes de oBS mientras permanece en la zona de solape. Idealmente el handover se completa antes de que el MN pierda cobertura de la estación base antigua y, por tanto, no se debe perder ningún paquete. A pesar de que en situaciones normales esta solución no pierde ningún paquete, circunstancias excepcionales, como una zona de solape mínima, pueden provocar una cierta probabilidad de pérdida. A continuación vamos a estudiar esta posible situación.

7.3.1.1 Desarrollo analítico

En este esquema para que un paquete dirigido al nodo móvil se pierda, debido al mecanismo de handover, deben cumplirse las dos propiedades siguientes:


274

1. El paquete se transmite desde el oBS en un instante de tiempo posterior al instante de tiempo en el que el MN ha abandonado la zona de cobertura.

2. El paquete alcanza el nodo de cruce antes de que lo haga el mensaje ‘Join’ proveniente de nBS (ver figura 6.4).

Con respecto a la primera condición necesaria para la pérdida de un paquete, definimos 1t como el instante de tiempo a partir del cual los paquetes que alcancen el nodo de cruce nunca llegarán al nodo móvil vía oBS. El motivo de esto será que oBS transmitirá estos paquetes posteriormente al abandono la zona de cobertura por parte del nodo móvil.

[ ]oBSoBSRRRCNCNtt AB ++++−= ),(),( 1111 (7.15) Es evidente la analogía entre (7.15) y la ecuación (7.1) del esquema de handover abrupto. La única diferencia es que en este caso trabajamos con ABt , definido como el tiempo en el que el nodo móvil abandona la zona de cobertura de oBS. A su vez éste tiempo de abandono podemos escribirlo en función del tiempo en el que el nodo móvil atraviesa el punto medio de la zona de solape mt , y del tiempo que necesita en atravesar dicha zona σ.

2σ

+= mAB tt (7.16) Simplificando (7.15) tendríamos:

[ ]cXtt AB +−=1 (7.17) siendo

),(),( 11 oBSRRCNc +=

X = v.a con fdd: tX ettf

23


Con respecto a la segunda condición, ésta también se daba en el handover abrupto (punto 7.2). Definimos 2t como el instante de tiempo en


275

el que el nodo de cruce recibe, vía nBS, la información de que se ha producido un handover.

),(),( 2222 CNRRRnBSnBShtt m ++++∆+= (7.18) En la ecuación anterior h∆ se corresponde con el tiempo, tras el instante mt , que le cuesta al nodo móvil detectar que debe pasar a depender de nBS. Simplificado la ecuación, como ya se ha realizado anteriormente, queda:

dYhtt m ++∆+=2 (7.19)

con

),(),( 22 CNRRnBSd += Y = v.a con fdd: t

Y tetf 2)( ββ −= para 0≥t y con )1( ρµβ −= Suponiendo que al nodo de cruce le llegan paquetes con un tiempo entre llegadas fijo de valor T, podemos calcular la probabilidad de que un paquete se pierda a partir de la ecuación (7.20).

[ ]21 )1(Pr tuTktobP kper <+−<=− (7.20) Idealmente 12 tt < y, por tanto, cuando el nodo móvil abandona la zona de cobertura ya ha recibido todos los paquetes previos al primero que va a recibir nBS. En este caso la probabilidad de pérdida del paquete será nula. Sin embargo, podemos trabajar con la ecuación (7.20) para estudiar el comportamiento del esquema de handover en circunstancias extremas, como cuando la zona de cobertura de las dos estaciones base es muy pequeña. Se puede observar que esta expresión es exactamente la empleada en el punto anterior (ecuación (7.8)). La única diferencia es que el instante


276

1t incorpora ahora el término σ/2. Sin embargo, podemos simplificar suponiendo este valor constante, e introduciéndolo en la constante ‘c’. Así el desarrollo matemático será idéntico al ya realizado, con una solución igual a la encontrada entonces (7.12).

[ ]∫ −−∆−− =+−−−=

T

Tkehowzkper dwowofwoWWeTkFP

)1(,max )( ) )1((1 (7.21)

La única diferencia que existe es respecto a la constante ‘e’. En este caso el parámetro incluye, además de los retardos de los enlaces, el tiempo que le cuesta al MN salir de la zona de solape tras el instante mt :

2),(),(),(),( 2211

σ−+++= CNRRnBSoBSRRCNe (7.22)

7.3.1.2 Resultados En la figura 7.6 se muestra el comportamiento del handover Semi Suave en función del tiempo que tarda el nodo móvil en atravesar la zona de solape entre las dos estaciones base, σ. Para realizar esta gráfica se ha tomado constantes los siguientes valores: tasa de servicio µ = 10 paquetes por mseg., tiempo de llegada de paquetes T = 5 mseg, tiempo de detección del handover ho∆ = 50 mseg, y un retardo entre dos routers de 5 mseg. El valor de la carga de los dispositivos de interconexión modelados ρ se ha tomado de 0.8 y 0.95. En la figura puede observarse que el esquema de handover funciona perfectamente a no ser que los sometamos a condiciones excepcionales. Así, con un tiempo en la zona de cobertura de 180 mseg. no se pierde ningún paquete. Un valor σ de 180 mseg. es un tiempo muy pequeño. Por ejemplo si un nodo móvil se mueve a una velocidad de 20 m/seg (72Km/h), 180 mseg. equivale a tener un área de cobertura de tan solo 3.6 metros. En la figura también se puede apreciar como las prestaciones empeoran al cargar más los dispositivos de interconexión. Al aumentar el parámetro ρ aumenta el tiempo de espera en colas y por tanto aumenta la


277

probabilidad de que un paquete se transmita cuando el nodo móvil ya haya abandonado la zona de cobertura. Hay que indicar que el valor de ρ corresponde a la carga total del dispositivo, y no a la carga generada por la comunicación con el nodo móvil estudiado. Por tanto, la carga del dispositivo no varía aunque se disminuya considerablemente el tiempo entre llegadas de los paquetes dirigidos al móvil T.

Figura 7.6 Paquetes perdidos vs. tiempo en la zona de cobertura σ.

En la figura 7.7 se muestra el comportamiento del handover en el caso de disminuir T hasta un valor de 1 mseg., manteniendo constantes los restantes valores de la simulación anterior. Podemos observar como el tamaño de la zona necesario para que no se pierdan paquetes no ha variado. Evidentemente en caso de tener una zona de cobertura mínima se tiene una media de paquetes perdidos mayor, pues para un tiempo dado de disrupción se transmiten (pierden) más paquetes.


278

Figura 7.7 Paquetes perdidos vs. tiempo en la zona de cobertura σ. T=1mseg.

7.3.2 Pérdida de paquetes con desconexión de oBS Existe una segunda solución a la hora de implementar el esquema de handover Semi Suave. En el capítulo 6.4 se explicó como en nodo móvil, tras recibir el mensaje ‘Intra-Domain Registration Reply’, supone la finalización del proceso de handover, enviando un mensaje ‘Multicat Prune Request’ a oBS. Vamos a realizar un estudio de paquetes perdidos suponiendo ahora que el nodo móvil descarta todos los paquetes recibidos desde oBS tras la recepción del mensaje ‘Intra-Domain Registration Reply’. Esta idea puede parecer, en un principio, menos eficiente que la anterior, pues se están descartando paquetes recibidos en la zona de solape. Sin embargo, para estudiar las prestaciones de un esquema de handover se ha que tener en cuenta la suma de diversos parámetros. Así, y


279

como se verá en el siguiente punto, la aceptación por parte del MN de todos los paquetes provenientes de oBS mientras éste permanece dentro de la zona de solape provoca multitud de paquetes duplicados.

7.3.2.1 Desarrollo analítico Para realizar este análisis partimos de los cálculos realizados a principio de este punto. Definimos 3t como el instante de tiempo en el que el nodo móvil recibe el mensaje ‘Intra-Domain Registration Reply’ desde nBS.

=+++++= nBSnBSRRRCNCNtt ),(),( 22223

''2 dYt ++= (7.23) siendo:

),(),(' 22 nBSRRCNd +=

Y’ = v.a. con fdd: tY ettf

23

' 2)( ββ −= para 0≥t y con )1( ρµβ −=

Podemos calcular el instante de tiempo a partir del cual los paquetes que alcancen el nodo de cruce llegarán al nodo móvil, vía oBS, más tarde del instante 3t :

[ ]oBSoBSRRRCNCNtt ++++−= ),(),( 11134

[ ]''34 cXtt +−= (7.24) siendo:

),(),(' 11 oBSRRCNc +=

X’ = v.a con fdd: tX ettf

23

' 2)( ββ −= para 0≥t y con )1( ρµβ −=


280

Para estudiar la pérdida de paquetes que ocasiona este modo de funcionamiento hay que suponer, evidentemente, que la zona de cobertura es lo suficientemente grande como para que el proceso de handover se pueda realizar correctamente. En otras palabras, suponemos que cuando el nodo móvil recibe el mensaje ‘Intra-Domain Registration Reply’ aún se encuentra en la zona de solape y que, por tanto, todavía no se ha perdido ningún paquete. Como se comprobó en la figura 7.6 esta suposición se cumple en cuanto la zona de solape tiene una dimensión mínimamente aceptable. Los paquetes perdidos serán aquellos que son descartados por el MN por haber dado la comunicación con oBS por finalizada, pero que no se han transmitido hacia nBS. Es decir los que llegan al CN después del instante 4t pero antes de 2t .

[ ]24 )1(Pr tuTktobP kper <+−<=− (7.25) Como en cálculos anteriores normalizamos con uno de los tiempos implicados en el análisis. En este caso igualamos 4t =0, de manera que el primer paquete susceptible de pérdida será el que llega en el instante u.

[ ] [ ] 0'''''' 234 =+−++=+−= cXdYtcXtt ⇒ ''''2 dcYXt −+−= (7.26)

[ ]''')1(0Pr eYXuTkobP kper +−<+−<=− (7.27) Para aligerar este punto, la ecuación (7.27) está desarrollada en el Anexo 2.1. La expresión final obtenida es la siguiente:

[ ]∫ ∫∞

−− +−=

T

0

)z'-umax(0,

23

o2

)'(1oo

xoooykper dudxe

xxuzF

TP oββ

(7.28) siendo

TknBSRRCNoBSRRCNTkez )1(),(),(),(),()1('' 2211 −−−−+=−−=


281

7.3.2.2 Resultados La figura 7.8 muestra el comportamiento del esquema cuando los caminos desde el nodo de cruce a las dos estaciones base tienen el mismo retardo. Así la constante e’ tiene un valor cero. Los parámetros que definen los routers se han tomado los mismos que los utilizados en gráficas anteriores, es decir, tasa de servicio µ = 10 paquetes por mseg. y carga ρ = 0.8

Figura 7.8 Probabilidad de pérdida del paquete k-ésimo con e’= 0.

La gráfica muestra la probabilidad de que el paquete k-ésimo se pierda en función del tiempo entre llegadas T. Hay que indicar que el paquete 1=k es primero susceptible de perderse, pues es el primero que llegaría al nodo móvil, vía oBS, posterior a la recepción del mensaje ‘Intra-Domain Registration Reply’. Podemos observar como dicha probabilidad disminuye rápidamente de manera que en todos los casos la probabilidad de que el segundo paquete se pierda es nula. En el capítulo 6.4.1 se planteó las limitaciones de este esquema. En particular se estudió como diferencias entre las cargas de los router que


282

forman las dos rutas (CN-oBS y CN-nBS), o bien diferencias en el retardo de estas rutas, podían ocasionar una pérdida de paquetes elevada (figura 6.6). A continuación vamos a estudiar esta situación haciendo el retardo entre la estación base antigua y el nodo de cruce y sensiblemente superior al existente entre este último y la nueva Estación Base. La figura 7.9 muestra el número medio de paquetes que se pierden en función de esta diferencia en mseg. Valores positivos indican que el retardo de la ruta antigua es superior al de la nueva ruta. Como se puede observar esta diferencia se corresponde exactamente con el valor e’ de la ecuación (7.28). Los restantes valores se han mantenido constantes: tasa de servicio µ = 10 paquetes por mseg., carga ρ = 0.8, y tiempo medio entre paquetes en CN, T = 10 mseg. El número medio de paquetes perdidos se ha obtenido como se explicó en la figura 7.4.

Figura 7.9 Paquetes perdidos en función de la diferencia de retardos de las rutas

CN oBS y CN nBS.


283

La gráfica muestra como aumenta de forma lineal el número de paquetes perdidos en función de la diferencia de retardo. Como se estudió en el punto 6.4, un retardo CN-oBS elevado, en comparación con el retardo de la ruta CN-nBS, se traduce en que muchos paquetes que han sido enviados por CN hacia oBS se encuentran todavía en tránsito cuando se produce el handover. Cuando el paquete ‘Join’ llega a CN indicando que nBS se ha conectado al árbol multicast estos paquetes ya han sido transmitidos a oBS y, por tanto, nunca se transmitirán a nBS. Debido al elevado retardo, los paquetes no alcanzan oBS antes de que el móvil reciba confirmación de nBS indicando la conexión al árbol (mensaje ‘Intra-Domain Registration Reply’). Recordemos que éste es el instante en el que el nodo móvil se desvincula de oBS y deja de aceptar paquetes que el oBS envía. Podemos comparar este esquema con la solución en la cual se aceptan todos los paquetes que se reciben de ambas estaciones mientras el nodo móvil se encuentra en la zona de solape. Como se vio en la figura 7.6, el número de paquetes perdidos dependía, fundamentalmente, del tamaño de la zona de solape, y para zonas de tamaño lógico no se perdía ningún paquete. Ahora el tamaño de la zona es no se ha tenido en cuenta, pues se ha supuesto que es lo suficientemente grande, y la cantidad de paquetes perdidos depende de la diferencia de las rutas entre el nodo de cruce y las estaciones base. Cuando el enlace con oBS es más lento el esquema Semi Suave propuesto en este punto no funciona correctamente. Por el contrario, la solución funciona perfectamente en el caso de que la ruta más lenta fuera la que une CN con nBS. Esto puede observarse mirando la zona de la gráfica 7.9 donde la diferencia de retardos es negativa. Para finalizar se estudia el comportamiento del esquema cuando modificamos la carga de los routers que forman las dos rutas, y que hasta ahora habíamos tomado como un valor constante ρ = 0.8. A partir de la ecuación (7.28) hemos distinguido el valor de β que provenía de la función


284

fdd )(' tf X , que equivalía a los routers de la ruta CN oBS, del valor β de los routers que componen la ruta hacia nBS. La figura 7.10 muestra el número medio de paquetes perdidos al mantener la carga de los routers del enlace CN nBS con valor ρ = 0.8 y variar la carga del enlace CN oBS entre 0.75 y 0.95. El resto de parámetros se mantienen constante: tasa de servicio µ = 10 paquetes por mseg., tiempo medio entre paquetes en CN de 10 mseg. y la constante e’ con valor cero. En la figura se observa que el número de paquetes perdidos aumenta al aumentar la carga de los routers del enlace con oBS. Como se explicó en el tema anterior, esto es debido a que al aumentar la carga aumenta el tiempo en cola de los paquetes que viajan por esta ruta, y es más probable que los paquetes se transmitan hacia el MN cuando éste ya se ha desconectado de la estación base, por lo que se perderán.

Figura 7.10 Número medio de paquetes perdidos en función de la carga de los

routers de la ruta CN-oBS.


285

También es interesante observar que el número de paquetes perdidos no es muy significativo, a no ser que la carga de los router aumente hasta valores de congestión. Así, en comparación a los 0.4-0.5 paquetes que se pueden llegar a perder cuando aumentemos la carga, la figura 7.9 mostraba que para valores razonables de e’, en torno a los 10-20 mseg., se perdían 1 o 2 paquetes.

7.3.3 Paquetes duplicados sin desconexión de oBS Como se estudió en el punto 6.4, el esquema de handover Semi Suave se basa en que el nodo móvil es capaz de recibir paquetes de las dos estaciones base mientras se encuentra en la zona de solape. Si el MN acepta todos los paquetes que recibe de las dos estaciones base, una zona de solape grande ocasionará, inevitablemente, la recepción de paquetes duplicados. A continuación vamos a estudiar esta limitación del esquema de handover.

7.3.3.1 Desarrollo analítico Los paquetes duplicados serán aquellos que son transmitidos por el CN en un instante posterior a la recepción del mensaje ‘Join’ (instante en el que nBS queda conectada al árbol multicast), y que son recibidos por el nodo móvil, vía oBS, antes de abandonar la zona de cobertura. Es decir, utilizando los tiempos definidos en 7.3.1, los paquetes duplicados son aquellos que alcanzan CN en un instante de tiempo t que cumple:

12 ttt << . Como en los estudios anteriores suponemos que los paquetes llegan con un tiempo entre llegadas fijo de valor T. Por tanto los paquetes llegan a CN en los instantes (k-1)T+u, siendo u un valor aleatorio uniformemente distribuido entre [0,T]. Tomamos como inicio temporal el instante en que el mensaje ‘Join’ alcanza el nodo de cruce, 02 =t . Así el primer paquete que


286

alcanza CN susceptible de ser recibido por duplicado será aquel con valor k = 1. La probabilidad de que el paquete k-ésimo llegue al nodo móvil por duplicado kdupP − es por tanto:

[ ]12 )1(Pr tuTktobP kdup <+−<=− (7.29) Igualamos a cero la expresión (7.19) y sustituimos en (7.17).

02 =++∆+= dYhtt m ⇒ dYhtm −−∆−=

cXdYht −−+−−∆−=21σ

La probabilidad de recibir el paquete k-ésimo por duplicado es entonces:

−−+−−∆−<+−<=− cXdYhuTkobP kdup 2

)1(0Pr σ (7.30) Para simplificar la expresión anterior definimos una nueva variable aleatoria Q como suma de las variables aleatorias independientes u y h∆ . En el caso de hoT ∆< esta nueva v.a. tiene la función de densidad de distribución siguiente:

(7.31)

Igualmente podemos definir la variable aleatoria Z que ya se ha utilizado en desarrollos anteriores, YXZ += , que tiene la función de densidad de distribución calculada en (7.7). Finalmente definimos una nueva constante dce −−= 2

σ . Así la ecuación (7.30) queda:

[ ]QTkeZobP kdup −−−≤=− )1(Pr (7.32)

∆+∆+−∆∆

=

0)(

11

)(hoTThot

hohoT

tfQ

restoThotho

hotTTt

+∆<<∆∆≤≤

<<0


287

Podemos rescribir esta ecuación de la siguiente manera:

[ ]∫+∆

− =−−−≤=Tho

Qkdup dqqfqQQTkeZP0

)( )1(Prob (7.33) Por último utilizando la función de distribución )(tFZ , tenemos:

∫+∆

− =−−−≤=Tho

Qzkdup dqqfqQQTkeZFP

0 )() )1(( (7.34)

7.3.3.2 Resultados La figura (7.11) muestra el número de paquetes duplicados que provoca el esquema de handover Semi Suave en función del tiempo σ que tarda el MN en atravesar la zona de solape. Como en gráficas anteriores se han tomado constantes los siguientes valores: tasa de servicio µ = 10 paquetes por mseg., tiempo de llegada de paquetes T = 10 mseg., tiempo de detección del handover ho∆ = 50 mseg, y un retardo entre dos routers cualquiera de 5 mseg. El valor de la carga de los dispositivos de interconexión modelados ρ se ha tomado de 0.8. Se observa como el número medio de paquetes duplicados aumenta con el tamaño de la zona de solape. Por ejemplo, con una velocidad de desplazamiento del MN de 20m/seg., una zona de solape de 20 metros produciría más de 130 paquetes duplicados. El número de paquetes duplicado depende de la tasa T a la que se reciben en el nodo de cruce. Es evidente pensar que al disminuir esta tasa aumentaría el número de duplicaciones. Sin embargo, más interesante que conocer valores exactos es comprobar como el mecanismo de handover Semi Suave necesita limitar la aceptación de paquetes de las dos estaciones base mientras el nodo se encuentra en la zona de cobertura.


288

Figura 7.11 número medio de paquetes duplicados.

7.3.4 Paquetes duplicados con desconexión de oBS

Como se comentó anteriormente existe una segunda solución a la hora de implementar el esquema de handover Semi Suave. La solución consiste en que el MN, tras recibir el mensaje ‘Intra-Domain Registration Reply’, supone la finalización del proceso de handover, enviando un mensaje ‘Multicat Prune Request’ a oBS, y no aceptando más paquetes de esta estación base. En esta situación la recepción de paquetes duplicados será menos probable aunque no imposible. Así, si el retardo entre el nodo de cruce y la estación base antigua CN oBS es sensiblemente inferior al retardo CN nBS, o bien si existen diferencias en cuanto a la carga que soportan los routers de las dos rutas, también será posible la recepción de paquetes duplicados.


289

Vamos a realizar una evaluación de paquetes duplicados, suponiendo que el nodo móvil descarta todos los paquetes recibidos desde oBS tras la recepción del mensaje ‘Intra-Domain Registration Reply’.

7.3.4.1 Desarrollo analítico En la situación actual los paquetes duplicados serán aquellos que se reciben en el nodo de cruce después de haber recibido el mensaje ‘Join’, y que son recibidos por el nodo móvil, vía oBS, antes de que éste reciba el mensaje ‘Intra-Domain Registration Reply’. Partiendo de los cálculos realizados anteriormente podemos indicar que los paquetes duplicados son aquellos que alcanzan CN en un instante de tiempo t que cumple: 42 ttt << . La probabilidad de que el paquete k-ésimo llegue duplicado es, por tanto:

[ ]42 )1(Pr tuTktobP kdup <+−<=− (7.35) Igualamos 2t = 0, de manera que ahora el primer paquete que puede llegar duplicado sea k = 1, que alcanza CN en el instante u. Simplificando como se ha realizado en desarrollos anteriores, en particular utilizando las ecuaciones (7.23) y (7.24), la ecuación (7.35) nos queda:

[ ]'''')1(0Pr dcXYuTkobP kdup +−−<+−<=− (7.36) Podemos observar como esta ecuación es casi idéntica a la obtenida para el número de paquetes perdidos en este mismo esquema, ecuación (7.27). Únicamente los signos de las variables aleatorias Y’ y X’ están cambiados, de la misma manera que ahora a la constante la llamaríamos e’’ y sería igual a e’’= d’-c’=-e’. Por tanto, el desarrollo matemático es el mismo que el que se realizó con anterioridad (ver 2.1), y la expresión final será:


290

[ ]∫ ∫∞

−− +−=

T

0

)z'-umax(0,

y 23

o2

)'(1oo

oooxkdup dudye

yyuzF

TP oββ

(7.37) siendo

TkoBSRRCNnBSRRCNTkez )1(),(),(),(),()1(''' 1122 −−−−+=−−=

7.3.4.2 Resultados La figura 7.12 muestra el número de paquetes duplicados al aplicar las mismas condiciones que en los estudios anteriores: tasa de servicio µ = 10 paquetes por mseg. y carga constante para todos los routers de la red de valor ρ = 0.8. El retardo de los caminos del nodo de cruce a las dos estaciones base es el mismo, de manera que e’’ = 0.

Figura 7.12 Probabilidad de que el paquete k-ésimo llegue duplicado al MN.

Podemos observar que la figura 7.12 es idéntica a la figura 7.8, pues como hemos comentado las expresiones analíticas obtenidas eran similares. Así, el número de paquetes duplicados dependerá del valor de T, pero siempre estará en valores muy próximos a 0.


291

Para completar el análisis de la duplicidad de paquetes hemos variado el retardo de los enlaces de las estaciones base al CN. La figura 7.13 muestra el número de paquetes perdidos en función de la diferencia de retardo de los enlaces. Con el fin de poder comparar esta gráfica con otras obtenidas anteriormente (por ejemplo la fig. 7.9), el eje horizontal indica el retardo de la ruta hasta oBS menos el retardo de la ruta hacia nBS: CN oBS - CN nBS. Es decir, el eje horizontal se corresponde con el valor negado de la constante e’’ que aparece en la ecuación (7.37).

Los restantes valores se han mantenido constantes: tasa de servicio µ = 10 paquetes por mseg., carga ρ = 0.8 y tiempo medio entre paquetes en CN de 10 mseg.

Figura 7.13 Paquetes duplicados en función de la diferencia de retardos de las

rutas CN oBS y CN nBS.

En la figura se observa que cuando retardo entre el nodo de cruce y

la estación base antigua CN oBS es sensiblemente inferior al retardo CN nBS, lo que se corresponde con valores negativos de la gráfica, se producen multitud de paquetes duplicados.


292

El razonamiento del comportamiento es claro, el nodo móvil acepta todos los paquetes de oBS hasta que recibe, vía nBS, el mensaje ‘Intra-Domain Registration Request’. Pero para que se envíe este mensaje nBS ha debido recibir, previamente, un mensaje ‘ACK Join’ desde el nodo de cruce. Ahora el mensaje ‘ACK Join’ va a costar más tiempo llegar, pues se ha aumentado el retardo CN nBS. Durante todo este tiempo CN ya está transmitiendo nuevos paquetes hacia las dos estaciones. Estos paquetes llegarán al MN vía oBS (que tiene un enlace con poco retardo) pero también a nBS que los retransmitirá hacia MN cuando finalmente le lleguen. La figura 7.14 muestra esta situación. Un análisis similar puede realizarse variando la carga de los distintos routers. Así, si se aumenta la carga de los routers que forman la ruta CN nBS se producirá un aumento de paquetes duplicados en manera similar al efecto que se estudió en la figura 7.10.

Figura 7.14 duplicación de paquetes en handover Semi Suave.

oBS

Nodo de Cruce

nBS

MN

5

5

Ack Join 6

6


293

7.3.5 Conclusiones del handover Semi Suave En este punto se ha realizado un estudio del handover Semi Suave descrito en 6.4. Basándonos en la capacidad de comunicación simultánea del nodo móvil se han descrito dos modos diferentes de implementar este protocolo. El primero sería aceptar todos los paquetes que se reciben de ambas estaciones base mientras se encuentra en la zona de solape. En el segundo modo de actuación, el nodo móvil, tras recibir un mensaje de nBS indicándole la conexión al árbol multicast, supone la finalización del proceso de handover, enviando un mensaje indicativo a oBS y desechando cualquier paquete posterior de esta estación base.

Se ha realizado un análisis de ambos modos. Si se aceptan todos los paquetes que recibe el nodo móvil cuando se encuentra en la zona de solape es posible lograr que no se pierda ningún paquete, simplemente dándole a la zona de solape unas dimensiones mínimas (ver figura 7.7). El problema de esta solución es que el número de paquetes duplicados aumenta directamente con el tiempo en que el nodo móvil permanece en la zona de solape, como puede observarse en la figura 7.11. El tiempo de permanencia del nodo móvil depende, evidentemente, del tamaño de la zona aumenta, pero también de la velocidad o de ruta que sigue el nodo. Por tanto el número de paquetes duplicados es poco previsible y toma valores elevados.

Para solucionar el problema de la duplicación de paquetes que

hemos observado proponemos el segundo modo de funcionamiento, en el que la aceptación de paquetes de oBS viene controlada por la recepción del mensaje ‘Intra-Domain Registration Request’. Según se observó en las figuras 7.8 y 7.12 el esquema funciona perfectamente, sin pérdida ni duplicidad de paquetes, siempre que las rutas entre las estaciones base y el nodo de cruce parecidas.

La figura 7.15 muestra como aumenta el número de paquetes

duplicados y perdidos al hacer diferente el retardo de las rutas CN oBS y CN nBS. Así el eje horizontal se corresponde con la resta (CN oBS)-(CN nBS), de manera que cuando la ruta hacia la estación base antigua


294

tiene un retardo mayor se produce pérdida de paquetes (valores positivos del eje horizontal), y en caso contrario el resultado es una duplicidad de paquetes.

Figura 7.15 Paquetes perdidos y duplicados en función de la diferencia de retardos

de las rutas (CN oBS) y (CN nBS).

Por tanto podemos concluir diciendo que el esquema de handover funciona correctamente en situaciones en que las rutas entre las estaciones base implicadas en el handover y el nodo de cruce son similares. En caso contrario se produce pérdida o duplicación de paquetes. Como se estudió en el capítulo anterior, el problema se ha solucionado presentando un nuevo esquema de handover que denominamos ‘Handover Suave con Finalización Controlada’ , y que vamos a evaluar analíticamente en el siguiente punto.


295

7.4 ESQUEMA SUAVE CON FINALIZACION CONTROLADA En el punto 6.5 se detalló el esquema de handover Suave con Finalización Controlada. Este esquema logra evitar los problemas de pérdida y duplicidad de paquetes que presenta el esquema Semi Suave, y que fueron estudiados en el punto anterior. El mecanismo de handover se basa en que el nodo móvil no da por finalizada la comunicación con oBS nada más recibir la confirmación de que la nueva estación base se ha conectado con éxito al árbol multicast. Por el contrario, MN retrasa premeditadamente el envío del mensaje de desconexión con oBS, con el fin de que ésta pueda transmitir los paquetes pendientes en colas. Antes de perder la cobertura el nodo móvil se desconecta de oBS, a la vez que indica a nBS que comience la transmisión de los paquetes que ha ido almacenando. Para evitar recibir paquetes duplicados, el nodo móvil le indica a nBS a partir de que paquete debe transmitir, de manera que la estación base descartará los paquetes previos. Se va a estudiar tres aspectos diferentes del protocolo. Comenzaremos por un estudio de los paquetes perdidos, similar a los ya realizados anteriormente. Se realizará también un estudio del retardo adicional que sufren los paquetes que, según el procedimiento detallado en el punto 6.5, deben ser almacenados temporalmente antes de su transmisión. Para finalizar estudiaremos las posibles limitaciones que tiene el esquema de handover con finalización controlada. Para realizar el desarrollo analítico partimos del hecho que este mecanismo de handover se basa en el esquema Semi Suave analizado en el punto 7.3. Por lo tanto vamos a tomar como base el desarrollo matemático realizado en ese punto, evitando así repetir cálculos.


296

7.4.1 Análisis de los paquetes perdidos

7.4.1.1 Desarrollo analítico Comenzamos el desarrollo estudiando la probabilidad de que el esquema de handover pierda algún paquete. Según el esquema descrito en 6.5, tras la recepción del mensaje ‘Intra-Domain Registration Reply’, el nodo móvil retrasa intencionadamente el envío del mensaje ’Multicast Prune Request’ hacia oBS. De esta manera oBS tendrá más tiempo de transmitir los paquetes pendientes, y el número de paquetes perdidos será menor que el estudiado en el esquema Semi Suave (ver figura 7.9). Como en el esquema anterior, los únicos paquetes que se pierden son aquellos que llegan al nodo móvil una vez éste ha enviado el mensaje de desconexión a oBS, pero que además el CN no los ha transmitido hacia nBS. Definimos 5t como el instante de tiempo en el que el nodo móvil envía el mensaje ’Multicast Prune Request’. La ecuación (7.38) muestra que este tiempo es igual al tiempo en que recibe el mensaje de confirmación ‘Intra-Domain Registration Reply’ más un tiempo de retraso que denominamos ϕ.

ϕ+= 35 tt (7.38) Podemos calcular el instante de tiempo 6t a partir del cual los paquetes que alcancen el nodo de cruce llegarán al nodo móvil, vía oBS, más tarde del instante 5t

[ ] =+++++−= oBSoBSRRRCNCNtt )(),( 11156 (7.39)

[ ]''5 cXt +−= siendo X’ y c’ las utilizadas en la ecuación (7.24):

),(),(' 11 oBSRRCNc +=


297

X’ = v.a. con fdd: tX ettf

23

' 2)( ββ −= para 0≥t y con )1( ρµβ −=

Los paquetes perdidos son los que llegan al CN en un instante de tiempo posterior a 6t pero anterior a 2t , que se corresponde con el instante de la recepción del mensaje ‘Join’ , ver ecuación (7.18). Por tanto la probabilidad de que un paquete se pierda es:

[ ]26 )1(Prob tuTktP kper <+−<=− (7.40) Es interesante observar la gran analogía existente entre esta ecuación y la obtenida para la pérdida de paquetes en el handover Semi Suave (7.25). Debido a que la única diferencia es el valor constante ϕ que diferencia los valores de 6t y 4t , el desarrollo de la ecuación será similar al ya realizado. Así igualando 6t = 0 y simplificando la ecuación (7.40) la podemos rescribir de la siguiente forma:

[ ]ϕ−+−<+−<=− ''')1(0Pr eYXuTkobP kper (7.41) Dado que la única diferencia es una constante, el desarrollo de la ecuación (7.41) es idéntico al ya desarrollado en el Anexo 2.1 y la expresión final será:

[ ]∫ ∫∞

−− +−=

T

0

)z'-umax(0,

23

o2

)'(1oo

xoooYkper dudxe

xxuzF

TP oββ

(7.42) siendo ahora z’ :

=−−−= Tkez )1('' ϕ TknBSRRCNoBSRRCN )1(),(),(),(),( 2211 −−−−−+= ϕ La ecuación anterior es válida siempre que el tiempo de retardo ϕ no provoque que el nodo móvil se salga de la zona de solape antes de enviar el mensaje ‘Multicast Prune Request’. A continuación vamos a estudiar este hecho.


298

Utilizando las ecuaciones (7.23) y (7.19) podemos rescribir el instante 5t , en que el MN envía el mensaje, en función del tiempo en el que el nodo móvil atraviesa el punto medio de la zona de solape:

ϕ+++++∆+= ''5 dYdYhtt m (7.43) Como hemos comentado, el instante 5t , en el que el nodo móvil envía el mensaje, debe producirse antes de que se abandone la zona de cobertura. Según (7.16) este abandono ocurre en el instante:

2σ

+= mAB tt Por tanto, tomando como referencia 0=mt , la probabilidad de que el handover ocurra de manera correcta es:

[ ] =−∆−−−≤+=< ]'2

'[ ProbProb 5 ϕσ hddYYtt AB

]'2

[ Prob ϕσ−∆−−−≤= hddZ (7.44)

Siendo )(tFz la función de distribución de la v.a. Z que se ha obtenido como suma de las dos v.a. que aparecían en la ecuación:

'YYZ += :

∑=

−−=4

0n

! ) ( 1)(

ntetF

nt

zββ

Recordemos que h∆ es una variable aleatoria con una función de densidad de distribución uniforme entre 0 y el periodo de envío de mensajes ho∆ . Así la ecuación (7.44) podemos desarrollarla como sigue:

[ ] =∆∆=∆∆−−−−≤∆

=< ∫∆ho

AB hdhHHddZobho

tt

0 5 ]|'

2[ Pr1Prob ϕσ

∫∆

∆∆−−−−∆

=ho

z hdhddFho

0 )'

2(1 ϕσ (7.45)


299

7.4.1.2 Resultados Como se ha comentado en el desarrollo analítico, la ecuación (7.42), que muestra la probabilidad de que el paquete k-ésimo se pierda, es idéntica a la desarrollada para el handover Semi Suave (7.28), con la única salvedad de la constante z’. Por tanto, los valores que se vamos a obtener en este punto deben estar relacionados, en cierta manera, con los que se obtuvieron el punto 7.3.2. Así, la figura 7.9 mostraba el número medio de paquetes perdidos en función del valor de la constante e’, que se corresponde con la diferencia entre las rutas CN-oBS y CN-nBS. En esta gráfica se podía comprobar como valores positivos de e’ provocaban un aumento importante de los paquetes que se perdían durante el handover, mientras que valores negativos de esta constante aseguraban la entrega de todos los paquetes al nodo móvil. En la expresión de la constante z’ de la ecuación (7.42) se observa como ahora el tiempo de retraso ϕ compensa este valor positivo de e’. Es decir, el esquema de ‘Handover Semi Suave’ provocaba una pérdida de paquetes cuando la ruta desde el CN a oBS es más lenta que la ruta a la estación base nueva. Para solucionar este problema se retrasa de forma intencionada el envío del mensaje ‘Multicast Prune Request’ durante un tiempo que denominamos ϕ. Este tiempo se resta directamente a la diferencia de caminos. Por ejemplo, un enlace (CN oBS) que es x mseg. más lento que el (CN nBS), lo que equivale a e’ = x, quedaría compensado por un retraso ϕ = x mseg. Ahora el valor e’-ϕ sería igual a 0, y la probabilidad de que el paquete se perdiera sería casi nula, como se demostró en la figura 7.8. La figura 7.16 muestra el número medio de paquetes perdidos en función de la diferencia e’-ϕ. Como se aprecia esta gráfica coincide exactamente con la figura 7.9.


300

Figura 7.16 Número medio de paquetes perdidos en función de la constante e’-ϕ.

Como hemos demostrado en el desarrollo anterior, no cualquier diferencia de retardo en las rutas a las estaciones base puede ser compensada retrasando el mensaje ‘Multicast Prune Request’ un tiempo ϕ adecuado. Esto es cierto únicamente en el caso de que el nodo móvil se encuentre en la zona de cobertura cuando finalmente desea enviar el mensaje. La figura 7.17 muestra la probabilidad de que el handover se realice correctamente, obtenida a partir de la ecuación (7.45). Para su realización se han tomado constante el retardo del enlace entre dos routers = 5 mseg. y el retardo máximo de detección de handover ho∆ = 100 mseg. El eje horizontal se corresponde con el tiempo de retraso en generar el mensaje ‘Multicast Prune Request’ ϕ, y se han realizado mediciones para distintos valores del tiempo que necesita el nodo para atravesar la zona de cobertura σ. En la gráfica se observa como la probabilidad de que el handover se realice correctamente desciende de manera muy abrupta, de manera que


301

con una variación pequeña del retardo ϕ se pasa de una probabilidad de valor 1 a una de valor 0.

Figura 7.17 Probabilidad de que el Handover se realice de manera correcta en

función del tiempo de retraso ϕ. Observemos por ejemplo la curva obtenida con una zona de cobertura σ de 1000 mseg. La función de distribución de la v.a. Z es cero para valores negativos, pues representa el tiempo de procesado de un conjunto de routers. Así, la probabilidad de éxito será 0 cuando ‘ hdd ∆−−−− ϕσ '2 ’ sea negativo. Con los valores de los parámetros utilizados, la probabilidad es nula para valores de ϕ superiores a 480. La curva sube de una manera tan abrupta debido a que la función FZ cambia de 0 a 1 en 10 unidades. Es decir 1)10( =ZF . Podemos concluir este análisis indicando que el protocolo funciona perfectamente cuando se retrasa el envío del mensaje ‘Multicast Prune Request’ un tiempo ϕ igual o superior a la diferencia de retardos entre la ruta (CN oBS) y la ruta (CN nBS). El mecanismo funciona correctamente siempre que cuando el nodo finalmente desee enviar el mensaje aún se encuentre en la zona de solape de ambas estaciones base.


302

7.4.2 Análisis del retardo de los paquetes entregados vía nBS Una vez el mensaje ‘Join’ ha alcanzado el nodo de cruce la nueva estación base queda incorporada al árbol multicast y, por tanto, los paquetes son dirigidos desde el CN hacia ella. Según el esquema de handover estudiado en 6.5 los mensajes que son transmitidos vía nBS tienen una cierta probabilidad de tener que esperar en la estación base antes de poder ser transmitidos hacía el nodo móvil. En este punto se va a realizar un análisis de este retardo adicional que sufren los paquetes. Hay que tener en cuenta que sólo estamos considerando los paquetes que se transmiten hacia nBS. Es decir, aquellos que son recibidos por el nodo de cruce en un instante posterior a 2t . Los paquetes anteriores no pueden sufrir este retraso, sino tan sólo una cierta probabilidad de pérdida que ya fue analizada en el punto 7.4.1. Los paquetes que llegan a nBS se pueden clasificados en una de las tres clases siguientes:

• Clase 1: Aquellos paquetes que llegan a nBS pero que posteriormente son descartados. Estos paquetes ya han sido recibidos por el MN vía oBS, y por tanto la nueva estación base no los transmite.

• Clase 2: Aquellos paquetes que son almacenados por el nBS y posteriormente transmitidos hacia el nodo móvil. Estos paquetes no han sido recibidos por MN vía oBS y, por eso, cuando la nueva estación recibe el mensaje ‘Handover Switch Indication’ comienza a transmitirlos.

• Clase 3: Aquellos paquetes que llegan a la nueva estación base cuando ya ha recibido el mensaje ‘Handover Switch Indication’ del nodo móvil. Estos paquetes no son almacenados, transmitiéndose tan pronto se pueda.


303

A continuación realizamos un desarrollo analítico para estudiar la probabilidad de que un paquete determinado pertenezca a las tres clases anteriores.

7.4.2.1 Desarrollo analítico El objetivo de este desarrollo es calcular la probabilidad de que el paquete k-ésimo pertenezca a una de las tres clases. Como en los estudios anteriores suponemos que los paquetes llegan al nodo de cruce cada T mseg. normalizamos con 2t = 0, de manera que el primer paquete que alcanza el nodo de cruce cuando nBS está incorporada al árbol multicast se corresponde con k = 1 y llega en el instante:

(k-1)T+u=u.

Paquetes pertenecientes a la clase 1.

La probabilidad de que el paquete k-ésimo pertenezca a la clase 1 es la probabilidad de que dicho paquete haya sido recibido por en nodo móvil vía oBS. Para que se cumpla esto el paquete debe haber llegado al nodo de cruce antes del instante 6t (instante del envío del mensaje ‘Multicast Prune Request’), que fue calculado en la ecuación (7.39).

[ ] [ ]621. )1(Prob1 clase k paq.Prob tuTktP clk <+−<=∈=− (7.46) Una expresión similar fue desarrollada en (7.35). Así, desarrollando (7.46) igual que se hizo entonces podemos rescribirla como:

[ ]∫ ∫∞

−− +−=

T

0

)z'-umax(0,

y 23

1.

o2

)'('1oo

oooXclk dudye

yyuzF

TP oββ

(7.47) siendo

=−−+−= Tkcdz )1(''' ϕ


304

TkoBSRRCNnBSRRCN )1(),(),(),(),( 1122 −−+−−+= ϕ Evidentemente estos paquetes no sufren ningún retardo adicional al de cualquier otro paquete no involucrado en el mecanismo de handover. El motivo es que estos paquetes han sido enviados por oBS sin haber sufrido el almacenamiento temporal, y serán descartados en nBS.

[ ] 01 clase k paq. retardoProb =∈> τ (7.48)

Paquetes pertenecientes a la clase 2. La probabilidad de que un paquete k pertenezca a esta clase se corresponde con la probabilidad de que el paquete llegue a la nueva estación base antes de que lo haga el mensaje ‘Handover Switch Indication’. Suponiendo que este mensaje se envía simultáneamente que el mensaje ‘Multicast Prune Request’, esto pasará en 5t . Además el mensaje no puede haber sido recibido por oBS, es decir no pertenece a la clase 1. Podemos definir el instante 7t como aquel a partir del cual los paquetes que alcancen CN llegarán a nBS más tarde que 5t .

[ ] =++++−= nBSnBSRRRCNCNtt ),(),( 22257 (7.49)

)''(5 dYt +−= La ecuación anterior ha sido simplificada utilizando las definiciones de Y’ y d’ que fueron calculadas en la ecuación (7.23). Por tanto la probabilidad de que el paquete k-ésimo pertenezca a la clase 2 es la mostrada en (7.50).

[ ] [ ]762. )1(Prob2 clase k paq.Prob tuTktP clk <+−<=∈=− (7.50) Utilizando las ecuaciones (7.49), (7.39), (7.38) y (7.23) podemos rescribir la probabilidad anterior como:


305

[ ]ϕϕ +−<+−<−−++=− '')1(''''Prob 12. YYuTkcXdYP clk (7.51) En la ecuación anterior hemos distinguido dos variedades de la v.a Y’, puesto que se corresponde con el tiempo de procesamiento de dos paquetes diferentes. Los tiempos 7t y 6t que se han desglosado en la ecuación 7.51 no son completamente independientes, lo que complica el desarrollo de la ecuación. El desarrollo completo para alcanzar la expresión (7.52) se muestra en el Anexo 2.2.

∫ ∫∞

+− −+−−=

T

0

-uo1)T-(k '2. )()))1((-(1 1

ϕdzoduozofuoaTKzoF

TP ZZclk (7.52) El cálculo analítico del retardo que sufren los paquetes que pertenecen a esta clase se complica en exceso. Este tiempo se corresponde con la diferencia entre el instante de tiempo en el cual el paquete alcanza nBS, almacenándose en el buffer, y el instante de tiempo en el que finalmente se transmite el paquete anterior. Podemos dividir este tiempo en dos componentes. El primero, At se corresponde con el tiempo desde que el paquete llega a nBS y ésta recibe el paquete ‘Handover Switch Indication’:

[ ] =+++++−−= ),(),()1( 2225 nBSRRRCNCNuTktt A

[ ] =++++−−++= ')1()''( 2 dRCNuTkdY ϕ

ϕ+−−−−= uTkYY )1(''' (7.53) con Y’’ = v.a. con fdd: t

Y tetf 2'' )( ββ −= para 0≥t y con )1( ρµβ −=

El segundo componente es el tiempo necesario para trasmitir las tramas que han sido almacenadas antes que él en el buffer, y que no han sido descartadas. Para poder conocer este tiempo necesitamos tener conocimiento sobre el número de paquetes que se van a descartar.


306

Así los paquetes que se transmiten desde CN antes de 6t (7.36) son recibidos por el nodo móvil vía oBS y por tanto se descartan del buffer de nBS. La probabilidad de que el último paquete recibido por oBS (y por tanto el último que se descarta en nBS) sea el paquete j-ésimo podemos escribirla como

[ ]ujTtuTjP júltimo +<<+−== 6)1(Prob (7.54) Por tanto podríamos escribir el tiempo Bt , necesario para transmitir las tramas almacenadas, como se muestra en la ecuación (7.55), donde se ha realizado una suma de las probabilidades de descartar j paquetes, multiplicando cada una de ellas por el tiempo necesario para transmitir los

jk −−1 paquetes restantes.

)1(P1

1∑

−

==

−−=

k

jjúltimoB

jktµ

(7.55)

Finalmente, la probabilidad de que el paquete k-ésimo, perteneciente a la clase 2, sufra un retardo adicional superior al valor τ, se puede describir como:

[ ] [ ]ττ >+=∈> BA ttProb2 clase k paq. retardoProb (7.56)

Paquetes pertenecientes a la clase 3. Para finalizar, la probabilidad de que un paquete k pertenezca a esta clase se corresponde con la probabilidad de que el paquete llegue a la nueva estación base después de que lo haga el mensaje ‘Handover Switch Indication’. Utilizando el instante 7t definido en (7.49):

[ ] [ ] =+−<=∈=− uTktP clk )1(Prob3 clase k paq.Prob 73.

[ ]u1)T-(k'Y'-YProb 1 +<+= ϕ (7.57)

La resolución de la ecuación (7.57) se ha realizado en el Anexo 2.3, dando como resultado:


307

[ ]∫ ∫

∞

−

−− ++=

T

0

z)max(0,-u

y 23

'3.

o2

)(1oo

oooYclk dudye

yyuzF

TP oββ

(7.58) con z =(k-1)T-ϕ Los paquetes que pertenecen a la clase 3 también pueden sufrir un pequeño retardo adicional debido al mecanismo de handover. Cuando nBS recibe el mensaje que le permite transmitir datos al nodo móvil le cuesta un tiempo vaciar el buffer. Los paquetes que se reciben mientras se realiza este proceso se almacenan retrasándose ligeramente la transmisión.

7.4.2.2 Resultados A continuación vamos a mostrar la probabilidad de que un paquete k-ésimo pertenezca a cada una de las clases definidas anteriormente.

Paquetes pertenecientes a la clase 1. La figura 7.18 nos muestra la probabilidad de que el paquete pertenezca a la clase 1, y por consiguiente que no sufra ningún retardo adicional al ser entregado por oBS y no por nBS. Se ha variado el retardo ‘Multicast Prune Request’ ϕ, mientras que los restantes valores se han mantenido constantes: tasa de servicio µ = 10 paquetes por mseg., carga ρ = 0.8 y tiempo medio entre paquetes en CN de 10 mseg. Suponemos también que las rutas hacia las dos estaciones base son iguales, de manera que la expresión c’-d’, denominada en todo este estudio e’, vale 0. Se observa claramente como la probabilidad disminuye al aumentar el número del paquete, ya que es más probable de que ese paquete no hay sido recibido vía oBS y que por tanto no pertenezca a la clase 1. Al aumentar el retardo en enviar el mensaje ‘Multicast Prune Request’ estamos alargando el tiempo en el que me mantengo conectado a la estación


308

anterior, y por esto también aumenta el número de paquetes recibidos sin retardo.

Figura 7.18 Probabilidad de pertenencia a la clase 1.

También es interesante destacar que en la ecuación (7.47) el valor del retardo ϕ está asociado al valor e’. Es decir, lo que realmente influye es la resta ϕ-e’. Así el valor de la gráfica ϕ=30 de la figura anterior será el obtenido para cualquier combinación ϕ-e’=30. Esto equivale a decir que cuanto más grande es la ruta CN-oBS en comparación con la ruta CN-nBS (valor de e’ mayor), menor es la probabilidad de que el paquete sea enviado vía oBS.

Paquetes pertenecientes a la clase 2. Para que un paquete pertenezca a la clase 2 es necesario que llegue a nBS antes que el mensaje ‘Handover Switch Indication’, pero que, además, haya llegado a oBS después de que el MN haya abandonado la conexión con esta estación. Es decir a la clase 2 pertenecen los paquetes


309

que, almacenados temporalmente en nBS, finalmente son transmitidos por esta estación tras recibir el mensaje correspondiente del MN. Según la ecuación (7.50) la probabilidad de pertenecer a esta clase se traduce en la probabilidad de que los paquetes se generen entre 6t y 7t . Estos tiempos se diferencian, fundamentalmente, en el tiempo que tardan los paquetes en ir del CN a oBS (valor c’ ) y a nBS (valor d’ ) respectivamente. Así, si los retardos hasta las dos estaciones base son idénticos, e’=c’-d’ =0, la probabilidad de que los paquetes pertenezcan a esta clase es prácticamente nula. La figura 7.19 muestra el comportamiento del sistema cuando las rutas tienen una diferencia e’= 30 mseg. Es decir la ruta CN-oBS es 30 mseg. más larga que al ruta CN-nBS. Los restantes valores se han mantenido constantes: tasa de servicio µ = 10 paquetes por mseg., carga ρ = 0.8 y tiempo medio entre paquetes en CN de 10 mseg.

Figura 7.19 Probabilidad de pertenencia a la clase 2, e’=30 mseg.

Se observa como las gráficas crecen a medida aumenta el número de paquete hasta un máximo, a partir del cual vuelve a decrecer. Así para


310

cada gráfica los valores bajos de k tienen una probabilidad muy pequeña de pertenecer a la clase 2. Esto es debido a que tienen una gran probabilidad de pertenecer a la clase 1. Como se aprecia en la figura al aumentar el valor de ϕ las gráficas se desplazan a la derecha, lo que equivale a que son más los paquetes que pueden ser entregados vía oBS y, por tanto, no son deben ser almacenados en la nueva estación base. Hay que tener en cuenta que ahora no se logra las mismas gráficas manteniendo el valor ϕ-e’ = constante (ver fórmula 7.52). Así la figura 7.20 nos muestra la probabilidad de pertenecer a la clase 2, tomando un valor e’=10 mseg., y manteniendo los valores utilizados en la figura anterior. Puede observarse claramente como la probabilidad de pertenecer a esta clase disminuye al hacer las rutas entre las estaciones base más parecidas.

Figura 7.20 Probabilidad de pertenencia a la clase 2, e’=10 mseg.


311

Por último la figura 7.21 nos muestra la probabilidad de que el tiempo que pasa desde que el paquete k-ésimo alcanza la nueva estación base y llega el paquete ‘Handover Switch Indication’ sea superior a un valor

. Es decir, el tiempo que el paquete permanece almacenado, y que en la ecuación 7.53 hemos denominado At . Para la realización de esta figura hemos tomado un valor ϕ = 40 mseg., manteniéndose los restantes parámetros con los mismos valores que anteriormente.

Figura 7.21 Probabilidad de que el paquete k espere un tiempo tA > .

En la figura anterior puede observarse como cuanto menor es el número del paquete mayor es la posibilidad de esperar tiempos elevados. Esto sucede simplemente porque llegan antes a nBS y el tiempo de espera al mensaje ‘Handover Switch Indication’ es mayor. Es importante destacar que, como se mostró en las figuras anteriores, no todos los paquetes tienen la misma probabilidad de pertenecer a la clase 2 y, por tanto, los tiempo de espera deben ser ponderados por la probabilidad del paquete k-ésimo de pertenecer a esta clase.


312

Paquetes pertenecientes a la clase 3. Los paquetes que pertenecen a la clase 3 son aquellos que alcanzan la nueva estación base en un instante posterior a la recepción del mensaje ‘Handover Switch Indication’.

Figura 7.22 Probabilidad de pertenencia a la clase 3.

Como se aprecia en la fórmula (7.58), la probabilidad de pertenecer a esta clase no depende de la ruta CN-oBS ni, incluso, del retardo fijo d’ existente en la ruta CN-nBS. Por tanto el valor de la constante e’, indicativa de la diferencia entre las rutas, y parámetro fundamental para estudiar la probabilidad de que un paquete k-ésimo perteneciera a una de las dos clases anteriores, es en este caso intranscendente. La figura 7.22 nos muestra la probabilidad de pertenencia a la clase 3 en función del retardo ϕ introducido por MN en la transmisión del mensaje ‘Handover Switch Indication’. Los valores de los distintos parámetros utilizados para la realización de la figura son los ya conocidos: tasa de servicio µ = 10 paquetes por mseg., carga ρ = 0.8 y tiempo medio entre paquetes en CN de 10 mseg.


313

De la gráfica se deduce que, al aumentar ϕ disminuye el número de paquetes que pertenecen a esta clase. Es decir, para un paquete k-ésimo dado, al aumentar el tiempo ϕ disminuye la probabilidad de que el paquete pertenezca a esta clase. El motivo es que al retrasar el envío del mensaje ‘Handover Switch Indication’ aumenta la probabilidad de que los paquetes pertenezcan a una de las dos clases anteriores.

Probabilidad conjunta de un paquete k-ésimo. Para realizar este estudio hemos normalizado con t2=0, de manera que el primer paquete (k=1) es el primero que es dirigido hacia nBS. Por tanto, cualquier paquete con k ¥ 1 debe pertenecer obligatoriamente a una de las tres clases estudiadas:

0 13.2.1. >∀=++ −−− kPPP clkclkclk Las figuras 7.23 y 7.24 nos muestran las probabilidades de pertenecer a una de las tres clases, fijando todos los parámetros. Como en casos anteriores: tasa de servicio µ = 10 paquetes por mseg., carga ρ = 0,8 y tiempo medio entre paquetes en CN de 10 mseg. Además tomamos un valor ϕ = 70 mseg. y una diferencia en los retardos a las estaciones base e’ = 30 mseg. en la primera figura y e’ = 50 mseg. en la segunda.

Observamos como, para cualquier paquete k-ésimo, la suma de las probabilidades de las tres clases suma 1. Es interesante destacar que la probabilidad de pertenecer a la clase 3 es independiente del valor e’.

Sin embargo la probabilidad de pertenencia a las otras dos clases si

viene determinado directamente por este calor. Como se aprecia comparando las dos figuras anteriores al aumentar la diferencia de retardos entre las dos rutas del router de cruce a las estaciones base (ruta CN-oBS mayor que CN-nBS) se aumenta la probabilidad de que el paquete pertenezca a la clase 2 y tenga que esperar en la nueva estación antes de ser transmitido al nodo móvil. El motivo de esto ya se estudió anteriormente, indicando que la clase 1, depende del parámetro ϕ-e’.


314

Figura 7.23 Suma de probabilidades de las 3 clases. ϕ=70 mseg. e’=30 mseg.

Figura 7.24 Suma de probabilidades de las 3 clases. ϕ=70 mseg. e’=50 mseg.


315

7.4.3 Análisis de la limitación del mecanismo de handover con Finalización Controlada En el punto 6.5.2 se comentó como en determinadas ocasiones no es útil utilizar este esquema de handover. Siguiendo el mecanismo que se propuso, es posible que el número del último paquete recibido que el nodo móvil envía en el mensaje ‘Handover Switch Indication’ a la nueva estación base no sea conocido por ésta. El protocolo presupone que si nBS no conoce este número es debido a que el paquete es previo al primero que tiene almacenado y reenvía todo el buffer. Así en una situación en la que el enlace nBS-CN es mucho más lento que el enlace oBS-CN el mecanismo anterior fallará. En este caso puede que el paquete indicado en el mensaje que envía el MN no haya sido recibido aún por nBS. nBS supondrá erróneamente que el mensaje es previo a los disponibles en su buffer realizando la transmisión total del mismo. La realidad es que todos esos mensajes almacenados ya han sido recibidos por el nodo móvil y los va a recibir por duplicado. La situación estudiada se muestra en la figura 7.25, donde se observa como el mensaje que el nodo móvil envía a nBS, para que comience la transmisión de los paquetes almacenados, indica que se comience la transmisión con el paquete 10. Éste todavía está en camino y por tanto, el MN realizará una transmisión de todos los paquetes almacenados en su memoria, de manera que el MN recibirá, por duplicado, los paquetes 6, 7 y 8. Como solución se desarrolló un mecanismo que, basándose en diversos mensajes, permite al nodo móvil obtener información sobre al red y decidir el esquema de handover a emplear.


316

Figura 7.25 Funcionamiento incorrecto del esquema de handover.

7.4.3.1 Desarrollo analítico A continuación se realiza un sencillo desarrollo analítico que nos indica en que situaciones el esquema de handover produce el error comentado anteriormente. Según (7.38) el mensaje ‘Handover Switch Indication’ con el número del último paquete recibido alcanza nBS en el instante 5t . La probabilidad de que se produzca un error se corresponde con la probabilidad de que el paquete indicado en dicho mensaje no haya sido aún recibido en nBS. En (7.59) se muestra este error, obtenido a través de la suma de probabilidades de que el paquete k-ésimo fuera el último en alcanzar el nodo móvil vía oBS, pero que, además, no llegara a nBS antes de la recepción del mensaje ‘Handover Switch Indication’.

[ ] [ ]∑∀

>+−+<<+−=k

error tuTkukTtuTk 76 )1(Prob )1(ProbProb (7.59) El desarrollo de la primera probabilidad, que se muestra en el Anexo 2.4, da como resultado:

Handover Switch Indication (10)

Nodo de Cruce

nBS

MN

9

11

11

10

8 7 6

oBS


317

[ ] =+<<+− )1(Prob 6 ukTtuTk

[ ]

0

0 ''' )())1('()'( 1 ∫ ∫

∞

−++−+−++−+=T

oooxooYooy dudxxfTkeuxFkTeuxFT

ϕϕ

(7.60) Con respecto a la segunda probabilidad que aparece en la ecuación (7.59), indicar simplemente que ya fue calculada en la ecuación (7.57).

7.4.3.2 Resultados De la primera probabilidad de la ecuación (7.59) podemos indicar lo que sigue. Como sabemos, el valor 6t es directamente proporcional al parámetro ϕ, e inversamente proporcional al valor de e’. Esto es, al aumentar ϕ, o disminuir e’, aumenta la probabilidad de que el último paquete recibido en oBS tenga un número más alto. La segunda probabilidad que aparece en la ecuación coincide con (7.57), y ya se comentó que el único parámetro que le afecta es ϕ, siendo independiente de la variación de caminos (ver figura 7.22). Esta variación de la probabilidad en función de ϕ compensa exactamente la variación que producía este parámetro en la primera probabilidad de la ecuación, de manera que, como se muestra a continuación, el retardo ϕ no afectará a la probabilidad de que el mecanismo de handover funcione de manera correcta. La figura 7.26 muestra la ecuación (7.59), separando ambas probabilidades. Para su realización hemos mantenido constante la tasa de servicio µ = 10 paquetes por mseg., la carga ρ = 0,8 y el tiempo medio entre paquetes en CN de 10 mseg. En el eje horizontal se muestra el paquete k-ésimo. Se ha representado los valores de la primera probabilidad de la ecuación para distintos valores de e’. También se ha representado el valor de la segunda probabilidad que, como se estudió anteriormente, no depende de este parámetro e’. El valor de ϕ permanece también constante con valor 80 mseg.


318

Figura 7.26 Desarrollo de la probabilidad total de fallo.

En la figura se observa como al disminuir el valor de e’ la probabilidad de que el paquete k-ésimo sea el último (primera probabilidad) se desplaza hacia mayores valores de k. Esta probabilidad hay que multiplicarla por la segunda probabilidad, de manera que para algunos valores altos de e’ el producto será 0. La siguiente figura muestra la probabilidad total, tras hacer el producto y el sumatorio. Se muestra para un valor de ϕ de 80 mseg., pero la gráfica es exactamente la misma para cualquier valor de ϕ. Como hemos comentado, al variar ϕ, las gráficas de la primera probabilidad se desplazan hacia la derecha, de la misma forma que lo hace la segunda probabilidad, resultando constante el producto. El eje horizontal muestra la diferencia de retardos entre los caminos desde CN hasta cada una de las estaciones base. Mantenemos la terminología de representar e’ que se corresponde con [oBS-CN]-[nBS-CN], de manera que los valores negativos representados indican que la ruta a la estación base nueva es más lenta.


319

Figura 7.27 Probabilidad de fallo en el mecanismo de handover.

Como se observa valores negativos del parámetro e’ se traducen en que el protocolo no va a funcionar correctamente, mientras que valores de e’ positivos hacen que el mecanismo funcione bien. Como se ha comentado la gráfica se obtiene exactamente igual independientemente del valor del retardo en la transmisión del mensaje ‘Multicast Prune Request’ ϕ. Esto es debido a que al aumentar el retardo aumenta el valor del último paquete que llega a oBS, pero de la misma manera también aumentan los paquetes que llegan a nBS impidiendo el error.

7.4.4 Conclusiones del handover suave con finalización controlada

En este punto se ha realizado un análisis del handover Suave con Finalización Controlada descrito en 6.5. Basándonos en la capacidad de comunicación simultanea del nodo móvil, se ha modificado el mecanismo Semi Suave permitiendo al nodo móvil que retrase un tiempo ϕ el envío del mensaje de desconexión. Con este mecanismo permitimos a oBS la


320

transmisión de los paquetes que están en camino o pendientes en colas. Para evitar paquetes duplicados en el nodo móvil adicionalmente se ha añadido la capacidad de que éste indique a nBS el a partir de que paquete de los almacenados debe empezar su transmisión. Se ha realizado un análisis de tres aspectos diferentes del protocolo. Para comenzar se ha realizado una evaluación de los paquetes perdidos utilizado este mecanismo de handover. En el esquema Semi Suave que se estudió en el punto anterior se mostraba como valores positivos del parámetro e’ (que representa la diferencia entre la ruta [CN-oBS] y la ruta [CN-nBS) ) provocaban una pérdida de paquetes. Se ha demostrado que el retraso del tiempo ϕ en el envío del mensaje ‘Multicast Prune Request’ compensa directamente esta pérdida (figura 7.16). Los paquetes que son recibidos por nBS no son dirigidos directamente al nodo móvil. Por el contrario estos se almacenan temporalmente en una cola a la espera de recibir el mensaje ‘Handover Switch Indication’, el cual indica a partir de que paquete debe retransmitirse al nodo móvil. Algunos paquetes serán descartados, pues el nodo móvil ya los ha recibido vía oBS (clase 1). Otros paquetes sí se reenvían al MN, pero como se reciben antes que el mensaje ‘Handover Switch Indication’ sufren un tiempo de espera (clase 2). Finalmente un tercer grupo de paquetes alcanzan a nBS en un instante posterior al mensaje ‘Handover Switch Indication’ y, por tanto, no deben esperar mas que el tiempo en la cola de salida de nBS. Se ha realizado un análisis de las probabilidades de que un paquete k-ésimo pertenezca a las tres clases anteriores (figuras 7.18, 7.19 y 7.22), así como el tiempo que debe esperar un paquete que llega antes del mensaje ‘Handover Switch Indication’, y que debe retransmitirse vía nBS. Así, la probabilidad de que el paquete llegue vía oBS depende de la diferencia ϕ-e’, de manera que al aumentar ésta disminuye la probabilidad de que el paquete pertenezca a la clase 1. La probabilidad de que el paquete tenga que esperar por alcanzar nBS antes del mensaje de control de handover (clase 2) depende de la diferencia de las rutas hasta las dos


321

estaciones base. Al hacer las rutas más diferentes (e’ toma un valor positivo mayor) aumenta la probabilidad de esperar. Por último la probabilidad de que el paquete llegue en un instante posterior al mensaje de control depende exclusivamente del parámetro ϕ, de manera que al aumentar éste disminuye el número de paquetes que pertenecen a esta clase (es decir que pertenecen a una las dos clases anteriores). Las figuras 7.23 y 7.24 nos muestran un estudio de la probabilidad conjunta de un paquete cualquiera. Para finalizar se ha estudiado como en algunas situaciones el mecanismo de handover propuesto no funciona de manera totalmente correcta. En concreto, cuando la ruta hacia nBS es mayor que la ruta a oBS (valor e’ negativo), el protocolo puede fallar de manera que algunos paquetes son enviados desde las dos estaciones base, produciéndose una duplicación en el MN. La probabilidad de que esto suceda se muestra en la figura 7.27. Como solución a este problema en el punto 6.5.2 se diseñó un mecanismo que permite que el nodo móvil seleccione el esquema de handover adecuado a la topología de la red. Para ello se modificaron ligeramente los mensajes ‘Intra-Domain Registration Request’ y ‘Agent Advertisement’. Así el nodo móvil tendría la información necesaria para decidir el esquema emplear, de manera que cuando e’ toma un valor negativo se utilizaría el handover Semi Suave, optándose por el esquema explicado aquí cuando e’ es cercana a 0 o positiva.

7.5 ESQUEMA DE HANDOVER CON REDIRECCIONAMIENTO En el punto 6.6 explicamos el esquema de handover basado en redireccionamiento. Este esquema está pensado, principalmente, para sistemas donde el nodo móvil puede comunicarse con una sola estación base en un instante de tiempo.


322

Como en el ‘Handover Abrupto’ estudiado previamente, el proceso comienza cuando el MN detecta la necesidad de iniciar el handover y transmite el ya conocido mensaje ‘Intra-Domain Registration Request’ hacia nBS. Tras la recepción del mismo la nueva estación base se conecta al árbol multicast y, de manera simultanea, se comunica con oBS para solicitar el redireccionamiento de los paquetes pendientes. oBS transmitirá, por medio de un túnel, los paquetes dirigidos al MN que tiene todavía almacenados, y se desconectará del árbol multicast. Al ser una handover abrupto existe un tiempo en que el nodo móvil no tiene conexión con oBS, y en el que nBS todavía no se ha conectado al árbol multicast. Evidentemente esto se traduce en una pérdida de paquetes. Para solucionar el problema propusimos un almacenamiento temporal de los paquetes en oBS, de manera que se mantienen en memoria después de haber sido transmitidos por el enlace inalámbrico, y están disponibles para su redireccionamiento a nBS. Para evitar paquetes duplicados en el MN, se emplea la misma solución que la diseñada en el esquema anterior, consistente en que el nodo móvil indica, en el proceso de registro, el último paquete recibido vía oBS. De la misma manera nBS almacena el primer paquete recibido del árbol multicast, por lo que rechaza todos los paquetes posteriores a éste recibidos de oBS. Es decir, los paquetes almacenados en el buffer de oBS se recortan tanto en su límite inferior, con la información del último paquete recibido por MN, como por su parte superior, descartando nBS todos los paquetes posteriores al primer paquete que recibe por su incorporación al árbol multicast. Aún con la solución anterior es posible la pérdida de paquetes. Esto se produce si los paquetes son finalmente descartados en oBS antes de ser reenviados a nBS, debido, típicamente, a un desbordamiento de la memoria circular donde se almacenan los paquetes recibidos por oBS. A continuación va a realizarse un análisis del problema. Por otro lado, según el esquema anterior, durante el handover algunos paquetes pueden alcanzar al NM de manera desordenada. Sin


323

embargo este problema ya lo incorpora la propia naturaleza del protocolo IP, de manera que, al igual que la demás bibliografía existente [PER01], no va a ser solucionado.

7.5.1 Desarrollo analítico Para analizar el handover con redireccionamiento estudiado en el punto 6.6 partimos de la figura 7.1b, que reproducimos a continuación. Puede apreciarse como se ha incorporado una conexión entre las dos estaciones base (utilizando un router R3). Así independizamos el árbol multicast de la comunicación entre las dos estaciones, puesto que en algunas topologías, como la de la figura, el túnel formado para la retransmisión de los paquetes no tiene por que seguir los enlaces que forman el árbol multicast. Se va a realizar el estudio analítico como se hizo en esquemas anteriores, modelando los routers como colas M/M/1. De esta manera el tiempo de servicio de cada Router Ri estará distribuido exponencialmente, con tasa ( )ρ1µ − , e incluirá tanto el tiempo de procesamiento como el de transmisión.

Figura 7.28 Esquema de la red para el modelado analítico.

MN

R1

oBS

Nodo de Cruce CN

nBS

R2

R3


324

Definimos los siguientes tiempos:

• hot : instante de tiempo en el que comienza el proceso de handover. Es decir, el instante de tiempo en el que el nodo móvil deja de recibir paquetes de la estación antigua oBS.

• 1t : instante de tiempo a partir del cual los paquetes que alcancen el nodo de cruce CN se perderán porque llegarán al nodo móvil después del instante hot .

• 2t : instante de tiempo en el que el nodo de cruce recibe, vía nBS, la información de que nBS desea incorporarse al árbol multicast. A partir de este instante los paquetes serían también reencaminados a nBS, dejándose de perder paquetes.

• 3t : instante de tiempo en el que oBS recibe el mensaje de redireccionamiento desde nBS. En ese instante oBS empezará a retransmitir los paquetes almacenados en el buffer que no han sido recibidos por el nodo móvil.

Siguiendo la nomenclatura utilizada en los análisis anteriores podemos calcular 1t , 2t y 3t como sigue:

[ ]oBSoBSRRRCNCNtt ho ++++−= ),(),( 1111 (7.61)

),(),( 2222 CNRRRnBSnBShtt ho ++++∆+= (7.62)

),(),( 3333 oBSRRRnBSnBShtt ho ++++∆+= (7.63) Donde CN, oBS, nBS, 1R , 2R y 3R son variables aleatorias con función de densidad de distribución exponencial. h∆ se corresponde con el tiempo que le cuesta al nodo móvil detectar que se ha producido el handover y que ha pasado a depender de nBS. Hasta ahora h∆ era una variable aleatoria con una función de densidad de distribución uniforme, sin embargo, con el fin de independizar completamente los tiempos 1t y 2t , en este estudio vamos a considerar h∆ como un valor constante.


325

Como se ha comentado anteriormente, vamos a centrarnos en el estudio de la pérdida de paquetes durante el handover, que se produce por desbordamiento del buffer en la estación antigua oBS. Para que ocurra esto deben cumplirse todas las siguientes condiciones:

1. El paquete llega al nodo de cruce CN, en un instante anterior a 2t . En caso contrario el paquete sería entregado al nodo móvil vía nBS.

2. El paquete alcanza CN después del instante 1t . Los paquetes que llegan antes de este tiempo son transmitidos al nodo móvil antes de

hot , y por tanto se reciben correctamente vía oBS.

3. El mensaje ‘Multicast Prune Request’, indicativo de que el nodo móvil depende ahora de una nueva BS, alcanza oBS (instante 3t ) cuando el paquete ya no está en el buffer circular, debido a que ha sido sustituido por otro más reciente.

Según estas condiciones la probabilidad de que un paquete se pierda puede representarse como:

[ ] ( ) ( ) ( )[ ]3CN1CN2CN tANDtANDtProbPerd.Prob tbTcXtt <+++><= (7.64) En la ecuación anterior CNt representa el instante en el que el paquete llega al nodo de cruce. Como en todos los análisis anteriores suponemos que los paquetes llegan a intervalos constantes de valor T mseg. Es decir, despreciamos el jitter que puede introducir la red desde el transmisor al nodo de cruce. Por otra parte, X es una variable aleatoria suma de las v.a.

oBSRCN ++ 1 . Su función de densidad de distribución )(tf X , que ha sido calculada como la convolución de las densidades de distribución de los dispositivos implicados, se corresponde con una distribución de densidad Erlang.

tX ettf

23

2)( ββ −= para 0≥t y con )1( ρµβ −= (7.65)


326

Por último, c es un valor constante ),(),( 11 oBSRRCNc += y b se corresponde con el tamaño del buffer medido en número de paquetes almacenables, siendo el parámetro que estamos intentando dimensionar. Para simplificar el desarrollo podemos rescribir las ecuaciones (7.61), (7.62) y (7.639) definiendo variables aleatorias que se corresponden con las sumas de los tiempos de proceso de los routers individuales.

[ ]cXtt ho +−=1 (7.66)

dYhtt ho ++∆+=2 (7.67)

eZhtt ho ++∆+=3 (7.68) con

),(),( 22 CNRRnBSd +=

),(),( 33 oBSRRnBSe +=

tY tetf 2)( ββ −= para 0≥t y con )1( ρµβ −=

tZ tetf 2)( ββ −= para 0≥t y con )1( ρµβ −=

Podemos normalizar el tiempo haciendo hot = 0. En los desarrollos de los puntos anteriores siempre se normalizaba el tiempo de manera que el primer paquete susceptible de perderse era el correspondiente a k=0. Esto se traducía en que, en el intervalo bajo estudio, el tiempo de llegada de paquetes era siempre positivo. Sin embargo, en esta evaluación hay que tener en cuenta paquetes que se transmiten desde CN antes de que se produzca el instante de handover hot , y según la normalización empleada, ahora esto sucede en tiempos menores que 0. Los tres elementos que forman parte de la probabilidad que aparece a la derecha de la ecuación (7.64) podemos escribirlos como:

dYhttt CNCN ++∆<⇒< 2

cXttt CNCN −−>⇒> 1


327

eZhbTcXttbTcXt CNCN ++∆<+++⇒<+++ 3 Al haber tomado la v.a h∆ como un valor constante, el primer miembro de la parte derecha de la ecuación [7.64] es independiente de los otros dos. Así podemos rescribir dicha ecuación como:

[ ] [ ] [ ]bTcXeZhtcXdYht CNCN −−−++∆<<−−++∆<= Prob*ProbPerd.Prob

(7.69) La primera probabilidad de la ecuación (7.69) es inmediata:

[ ] )(1Prob dhtFdYht CNYCN −∆−−=++∆< (7.70) Con respecto a la segunda:

[ ] =−−−++∆<<−− bTcXeZhtcX CNProb

[ ] =−++∆<++<= bTeZhcXtCN0Prob

[ ]∫∞

+<++<=

0 )( 0Prob dzozofzoacXt ZCN (7.71)

con bTeha −+∆= Para que la ecuación anterior tenga sentido ‘a + zo’ tiene que ser mayor que 0. Así deberemos modificar el límite inferior de la ecuación anterior quedando finalmente:

[ ]∫∞

−=−−+<<−−

),0 max( )( Prob

aZCNCN dzozofctzoaXct

[ ]∫∞

−−−−−+=

max(0,-a) )( )()( dzozofctFctzoaF ZCNXCNX (7.72)


328

7.5.2 Resultados A continuación se muestra el comportamiento del esquema de handover con redireccionamiento. Como hemos explicado anteriormente, el instante de inicio de handover hot ha sido normalizado a 0, de manera que hay que tener en cuenta también paquetes generados en un tiempo CNt menor que 0. Así partimos de un tiempo suficientemente negativo, de manera que, suponiendo tasa constante, el paquete k-ésimo alcanzará el nodo de cruce en:

Tkt kCN )1(100 −+−=− (7.73) El cálculo del número medio de paquetes perdidos se realiza como:

[ ]∑∞

=

−+−==1k

)1(100 perd.,Prob TktN CN (7.74) La figura 7.29 muestra el número de paquetes perdidos en función del tamaño del buffer ‘b’ de la estación base previa Para su realización hemos mantenido constante el tiempo medio entre paquetes en CN, T = 10 mseg, la tasa de servicio µ = 10 paquetes por mseg., la carga ρ = 0.8 y tiempo para la detección del handover por el nodo móvil h∆ = 50 mseg. Los retardos fijos que suman los enlaces entre CN y las estaciones base, parámetros ‘c’ y ‘d’ de las ecuaciones (7.66) y (7.67), son, en ambos casos, de 10 mseg. Se ha variado el retardo entre las estaciones oBS y nBS (parámetro ‘e’ de la ecuación (7.68)), para estudiar la dependencia de este factor. De la figura se comprueba como, evidentemente, al aumentar el tamaño del buffer disminuyen los paquetes perdidos. Además se puede analizar el funcionamiento del esquema en función de la distancia existente entre las estaciones base (retardos fijos en la ruta nBS-oBS). Al disminuir este valor el mensaje de redireccionamiento llega antes a oBS, de manera no se da el tiempo necesario para que se produzca un desbordamiento del buffer, perdiéndose menos paquetes para un tamaño de buffer dado.


329

Figura 7.29 Paquetes perdidos en función del ‘buffer’ de oBS.

Si la ruta entre las dos estaciones base no existiera, el mensaje debería seguir la ruta nBS-CN-oBS que tendrá un retardo de 20 mseg + el tiempo extra de procesamiento de los routers adicionales que atraviesa. En esta situación el comportamiento del esquema de handover sería cercano al de la gráfica con valor e = 25 mseg. Para comprobar la relación respecto al esquema de handover abrupto visto en el punto 7.2, se ha calculado el número de paquetes pedidos en el caso de no tener buffer y hacer la ruta entre estaciones (parámetro ‘e’ ) lo suficientemente elevada para que la pérdida de paquetes no venga influenciada por éste. Bajo estas circunstancias el valor de paquetes perdidos es de 8, lo que se corresponde con el valor obtenido en el handover abrupto (ver figura 7.4). Por último indicar que el tamaño en concreto del buffer tiene una importancia relativa, ya que se ha obtenido bajo unas determinadas condiciones. Así si disminuimos el tiempo entre paquetes T, o aumentamos el tiempo necesario para detectar el handover h∆ , el tamaño necesario del buffer para evitar pérdidas aumentaría.


330

7.5.3 Consideraciones finales sobre el Handover con Redireccionamiento El análisis desarrollado nos demuestra como un dimensionado adecuado del buffer de oBS permite un handover sin pérdida de paquetes. La utilización de métodos de reenvío de paquetes entre estaciones base durante el proceso de Handover ya ha sido propuesto en la bibliografía existente [PER01] y [RAM99]. Sin embargo es interesante indicar las ventajas que aporta el implementar este tipo de soluciones en el sistema de micro-movilidad basado en multicast que propusimos en el capítulo 3 de esta Tesis. Según el esquema de direccionamiento clásico [PER01], los paquetes redirigidos por oBS que alcanzan la nueva estación base antes de que lo haga la respuesta a la petición de registro deben ser descartados. En [BLO02c] se estudia este hecho, comprobando como una distancia entre estaciones base menor que la distancia entre el la raíz del dominio y la nueva estación base provoca este tipo de pérdidas, que empeoran considerablemente las prestaciones del Handover. Como posibles soluciones estarían, bien almacenar estos paquetes en nBS hasta la recepción del mensaje ‘Registration Reply’, o bien la solución propuesta en el esquema Hawaii, donde el envío del mensaje de nBS a oBS, necesario para iniciar el reenvío, se encamina por la raíz, de manera que siempre es posterior la retransmisión de los paquetes a la recepción de la respuesta de registro. En nuestro esquema de micro-movilidad multicast el registro de la nueva estación base se reduce a la incorporación al árbol multicast que se corresponde a la dirección conocida del nodo móvil. Por tanto, nBS está en disposición de reenviar mensajes al MN en cuanto envía el mensaje ‘Join’ sin la necesidad de recibir el reconocimiento. Aquí no es necesario la utilización de buffers en nBS aunque, evidentemente, es una opción posible si se desea transmitirle el mensaje de respuesta al registro antes que ningún paquete reencaminado. Este incorporación soluciona,


331

adicionalmente, el problema de duplicación de paquetes que se comenta a continuación.

7.5.3.1 Posible duplicación de paquetes A pesar de que en nuestro handover con redireccionamiento no es posible una pérdida de paquetes (siempre que el tamaño del buffer de oBS esté correctamente dimensionado), sí puede darse la circunstancia de que algunos paquetes lleguen duplicados al nodo móvil. Así, cuando la ruta CN-nBS es comparativamente grande con respecto a la suma de CN-oBS + oBS-nBS es posible que nBS, antes de recibir el primer paquete del árbol multicast, haya recibido y retransmitido algunos, o incluso todos, los paquetes provenientes de oBS. En este caso algún paquete recibido en nBS puede que ya hubiera sido enviado al MN proveniente de la retransmisión de oBS. En un principio la nueva estación base no tiene conocimiento de ello y por tanto el paquete será enviado al nodo móvil por duplicado. El problema existente es que el mecanismo está pensado de manera que el primer paquete proveniente del árbol es utilizado por nBS para recortar el final de la retrasmisión de oBS. Si el retardo del enlace CN-nBS es mayor que la suma de los retardos CN-oBS + oBS-nBS es posible que este primer paquete proveniente del árbol se retrase en exceso, provocando la circunstancia comentada. Existen varias soluciones al respecto. La primera sería lograr que la ruta CN-nBS fuera menor que la ruta CN-oBS + oBS-nBS. Una opción para lograr esto es que los paquetes que viajan por el túnel oBS-nBS pasen por el nodo de cruce. Evidentemente de esta manera cualquier paquete proveniente de oBS llega más tarde que el mismo dirigido directamente a nBS. A diferencia de otros sistemas de micro-movilidad, aquí el túnel entre las dos estaciones se realiza según el enrutamiento IP, lo que hace necesario modificar la topología física de la red. Así, en el sistema analítico


332

estudiado, esto equivaldría a eliminar la ruta que pasa por 3R de la figura 7.28. Otra solución sería almacenar en nBS los paquetes provenientes de oBS. Cuando llega el primer paquete del árbol multicast podemos descartar ese y todos los posteriores de los enviados desde oBS. La limitación de esta solución es que necesitamos recursos en nBS y que, además, ralentizamos la entrega de los paquetes redirigidos. Esto último no debería ser un obstáculo, ya que el principal objetivo de este mecanismo de handover es lograr un handover suave (Smooth Handover) y no un handover rápido. Por último indicar que en el estudio analítico no hemos tratado el caso de la duplicación de paquetes que detallados aquí. El motivo es que los problemas que ocasiona el tener retardos inadecuados en las rutas CN-oBS y CN-nBS ya han sido evaluados con profundidad en el esquema anterior (punto 7.4.3). Los resultados sobre la degradación de las prestaciones del handover que se obtuvieron allí son totalmente extrapolables al esquema de handover con redireccionamiento analizado en este punto. Podemos concluir indicando que un correcto dimensionado de la memoria de almacenamiento temporal de oBS permite un handover Suave, ver punto 4.4, en el que se minimiza la pérdida de paquetes. Adicionalmente puede incorporarse una memoria similar en nBS de manera que los paquetes redirigidos son almacenados hasta la recepción del mensaje ‘Ack Join’, que confirma la incorporación de la estación al árbol multicast. Este aportación no evitará la posible alteración del orden de los datagramas IP transmitidos, pero si evita el envío duplicado de paquetes al nodo móvil.


333

7.6 ESQUEMA DE HANDOVER INDIRECTO CON PRE-REGISTRO El último esquema de handover propuesto, para el sistema de micro-movilidad basado en multicast, está pesando para intentar ofrecer un handover rápido en sistemas donde el nodo móvil no es capaz de comunicarse, simultáneamente, con las dos estaciones base implicadas. Como se describió en el punto 6.7, el esquema se basa en la utilización de ‘triggers’ [YEG02], de manera el nodo móvil conoce de antemano que se va a producir un handover de nivel dos. El esquema es una adaptación del handover pre-registro que ha sido definido en [ELM02], aunque ha tenido que ser adaptado al sistema de micro-movilidad presentado en esta Tesis. Un estudio del esquema original ha sido realizado, tanto analíticamente como por simulación, en [BLO03]. En este esquema el mecanismo que permite a nBS conectarse al árbol multicast comienza antes de que MN tenga una conexión directa con ella. Para que esto sea posible MN deberá enviar el mensaje ‘Intra-Domain Registration Request’ dirigido a nBS a través de oBS. Tras la recepción del mensaje ‘Ack Join’, que confirma la suscripción al árbol multicast correspondiente al nodo móvil, nBS entregará el paquete de respuesta de registro en cuanto el nodo móvil concluya el handover L2 y, por tanto, tenga una conexión directa con la nueva estación. La detección de este hecho se realiza típicamente utilizando un trigger ‘L2-UP’ (ver tabla 4.1).

7.6.1 Desarrollo analítico Para analizar el handover con pre-registro, descrito en el punto 6.7, partimos de la figura 7.1b, en la que se incorporó una conexión entre las dos estaciones base (utilizando un router R3). Se va a realizar la evaluación siguiendo las mismas consideraciones utilizadas en esquemas anteriores. Es decir, modelamos los routers como colas M/M/1, de esta manera el tiempo de servicio de cada Router Ri estará distribuido


334

exponencialmente, con tasa ( )ρ1µ − , e incluirá tanto el tiempo de procesamiento como el de transmisión. Asumimos que el proceso de handover comienza cuando ocurre el trigger ‘L2-MT’ en el nodo móvil, anunciando la inminencia del handover a nivel 2. Definimos este instante como hot que será, idealmente, el instante en el que el nodo entra en la zona de solape. Aunque estamos suponiendo que el handover es iniciado por un trigger en el MN, el esquema y la evaluación son perfectamente válidos si el handover fuera iniciado mediante un trigger ‘L2-ST’ en oBS, ver punto 4.3. Existen dos tiempos fundamentales para el análisis del handover. El primero es el instante en que el nodo comienza el handover L2 con la nueva estación base, y se corresponde con el trigger ‘L2-LD’ en oBS. El segundo es el instante en que ha finalizado el handover L2 con nBS, de manera que ya se tiene una conexión directa entre MN y la nueva estación. Este tiempo se corresponde con un trigger ‘L2-LU’ en nBS. Denominamos a estos dos instantes LDt y LUt respectivamente, de manera que siempre se cumplirá: LULDho ttt << . El tiempo que transcurre entre LDt y LUt es el tiempo que dura un handover a nivel 2, y durante ese breve intervalo de tiempo, evidentemente, el nodo móvil no podrá recibir paquetes. Para realizar una evaluación de la pérdida que paquetes definimos también los siguientes tiempos:

• 1t : instante de tiempo a partir del cual los paquetes que alcancen el nodo de cruce CN no llegarán al nodo móvil vía oBS, pues lo harían después del instante LDt .

• 2t : instante de tiempo en el que el nodo de cruce recibe, vía nBS, la información de que nBS desea incorporarse al árbol multicast. A partir de este instante los paquetes serían también reencaminados a nBS, de manera que el MN podría recibirlos por esta estación.

Siguiendo la nomenclatura utilizada en los análisis anteriores podemos calcular 1t y 2t como sigue:


335

[ ]oBSoBSRRRCNCNtt LD ++++−= ),(),( 1111 (7.75)

),2()2,(),(),( 23332 CNRRRnBSnBSnBSRRRoBSoBStt ho ++++++++=

(7.76) Donde CN, oBS, nBS, 1R , 2R y 3R son variables aleatorias con función de densidad de distribución exponencial. Es interesante observar como en la ecuación [7.76] se han despreciado el tiempo que transcurre hasta que oBS recibe el mensaje de registro dirigido a nBS. Como se comentó, los tiempos de transmisión del nodo móvil y de propagación en el enlace inalámbrico han sido despreciados en todos los análisis de este capítulo. Además en este estudio en concreto, hemos despreciado el tiempo que tarda oBS en procesar el mensaje “Proxy Agent Solicitation” (si existiera), y tiempo de envío del “Proxy Agent Advertisement”. El motivo es que el tiempo de transmisión en el enlace inalámbrico es mucho menor que en la red fija y, principalmente, que dependería de si el handover es iniciado por un trigger en el nodo móvil o en oBS. Rescribimos las ecuaciones (7.75) y (7.76) definiendo variables aleatorias que se corresponden con las sumas de los tiempos de proceso de los routers individuales.

[ ]cXtt LD +−=1 (7.77)

gWtt ho ++=2 (7.78) con

),(),( 11 oBSRRCNc +=

),(),(),(),( 2233 CNRRnBSnBSRRoBSg +++=

t

X ettf 23



336

tW ettf

34

!3)( ββ −= para 0≥t y con )1( ρµβ −=

A continuación vamos a analizar tanto las posibles pérdidas de paquetes, como la probabilidad de que el nodo móvil reciba paquetes por duplicado.

7.6.1.1 Paquetes perdidos Con el fin de acelerar el proceso de handover, este esquema se basa en la utilización de triggers que permiten adelantar el proceso de registro que provoca la incorporación de nBS al árbol multicast. Aún así es fácil entender que un paquete se perderá si alcanza el nodo de cruce antes de que lo haga el mensaje ‘Join’ de nBS, y después del instante 1t que marca el límite de los paquetes que pueden entregarse vía oBS:

[ ] [ ]21obPrperd.Prob ttt CN <<= (7.79) Podemos normalizar el tiempo haciendo 0=hot . Es decir el tiempo comienza en el momento en que se produce el trigger en el nodo móvil. Así el valor LDt se corresponderá, también, con el tiempo transcurrido desde que sucede el trigger en el nodo móvil y éste comienza el proceso de handover L2. Los paquetes alcanzan el nodo de cruce a intervalos fijos T. Dependiendo del tiempo en que el nodo móvil comienza el handover L2, es posible (aunque improbable) que algún paquete generado antes de hot sea de interés en el análisis que estamos realizando. Para no limitar de ninguna forma el tiempo mínimo de LDt comenzamos el estudio de los paquetes que llegan en un tiempo negativo. Así los instantes CNt en que los paquetes alcanzan el nodo de cruce los podemos escribir como:

uTktCN +−+−= )1(30 (7.80)


337

Para eliminar cualquier dependencia con el instante en que se produce el handover, el instante en que llega el paquete tiene un componente aleatorio, u, uniformemente distribuido entre [0,T]. Como los tiempos 1t y 2t son independientes, la ecuación (7.79) es fácilmente desarrollable. Así la probabilidad de que el paquete k-ésimo se pierda la podemos escribir como:

[ ] [ ]21 Prob*Prob ttttP kCNkCNkperd <<= −−− (7.81) Sustituyendo (7.77) y (7.78) en la ecuación anterior, y desarrollando como lo hemos hecho en análisis anteriores, las dos probabilidades nos quedan finalmente:

[ ] [ ] =+−+−<−−=< − uTkcXttt LDkCN )1(30ProbProb 1

[ ]∫ =+−+−<−−=T

0 )1(30Prob1 duouoTkcXt

T LD

duotctFT LDuokCNX∫ +−−−= −

T

0 _ )(11 (7.82)

[ ] [ ] =+<+−+−=<− gWuTktt kCN )1(30ProbProb 2

[ ]∫ =+<+−+−=T

0 )1(30Prob1 duogWuoTk

T

duogtF

T uokCNW∫ −−= −

T

0 _ )(11 (7.83)

Adicionalmente a la perdida de paquetes analizada anteriormente existe otra posible fuente de pérdidas. Una vez nBS se ha conectado al árbol multicast comienza a recibir paquetes dirigidos hacia MN. Si el nodo móvil no ha finalizado el handover L2, esos paquetes que alcanzan nBS no podrán ser transmitidos y deberán ser descartados.


338

Denominamos 3t al instante de tiempo a partir del cual los paquetes que alcancen el nodo de cruce CN podrían llegar al nodo móvil vía nBS, pues lo harán después del instante LDt .

[ ]nBSnBSRRRCNCNtt LU ++++−= ),(),( 2223 =

dYtLU −−= (7.84) con

),(),( 22 nBSRRCNd +=

tY ettf

23


Así, la probabilidad de que un paquete se descarte es:

[ ]=<<= −− 32Prob tttP kCNkdescartar [ ] [ ]32 Prob*Prob tttt kCNkCN <<= −− (7.85) Finalmente el paquete k-ésimo se perderá por este motivo solamente si el paquete es descartado en nBS (7.85), pero si, además, ese paquete no es recibido por el nodo móvil vía oBS. Ya que los instantes 1t ,

2t y 3t son independientes, la probabilidad de que el paquete se pierda es:

[ ] [ ] [ ]132 Prob*Prob*Prob ttttttP kCNkCNkCNkperd ><<= −−−− (7.86) Las tres probabilidades de la ecuación anterior son inmediatas:

[ ] [ ] =<+=< −− kCNkCN tgWtt ProbProb 2

duogtFT uokCNW∫ −= −

T

0 _ )(1 (7.87)

[ ] [ ] =−−<=< −− dYtttt LUkCNkCN ProbProb 3

∫ −−= −

T

0 _ )(1 duodttF

T uokCNLUY (7.88)


339

[ ] [ ] =−−>=> −− cXtttt LDkCNkCN ProbProb 1

duotctFT uokCNLDX∫ −−−−=

T

0 _ ))(1(1 (7.89)

7.6.1.2 Paquetes duplicados

El sistema de micro-movilidad basado en multicast, favorece la entrega de paquetes sin pérdidas, ya que, durante parte del tiempo que dura el handover, las dos estaciones base implicadas están conectadas de manera simultánea al árbol multicast. Pero por este mismo motivo, sin embargo, el sistema tiene el inconveniente de que se favorece la duplicación de paquetes en el nodo móvil. En este esquema en particular el nodo móvil recibirá un paquete duplicado si se cumplen las siguientes tres condiciones:

• El paquete se transmite desde CN en un instante anterior a 1t , de manera que es recibido por MN vía oBS.

• El paquete es generado después de 2t , de marea que es transmitido también a nBS

• El paquete es generado después de 3t , de manera que no es descartado por nBS.

Es decir:

[ ] [ ])()()(obPrdupl.Prob 321 ttANDttANDtt kCNkCNkCN >><= −−− (7.90) Como ya se ha comentado los tiempos 1t , 2t y 3t son independiente de manera que la ecuación anterior queda:

[ ] [ ] [ ] [ ]321 obPr*obPr*obPrdupl.Prob tttttt kCNkCNkCN >><= −−− (7.91)


340

Las tres probabilidades de la ecuación anterior son inmediatas:

[ ] [ ] =−−<=< −− cXtttt LDkCNkCN ProbProb 1 duotctF

T uokCNLDX∫ −−−=T

0 _ )(1 (7.92)

[ ] [ ] =+>=> −− gWttt kCNkCN obProbPr 2 ∫ −= −

T

0 _ )(1 duogtF

T uokCNW (7.93)

[ ] [ ] =−−>=> −− dYtttt LUkCNkCN obProbPr 3 ∫ −−−= −

T

0 _ ))(1(1 duodttF

T uokCNLUY (7.94)

7.6.2 Resultados Comenzamos con la evaluación de los paquetes perdidos. La figura 7.30 muestra el número de paquetes perdidos en función del instante de tiempo LDt . Hemos mantenido constante el tiempo medio entre paquetes en CN, T = 10 mseg, la tasa de servicio µ = 10 paquetes por mseg. y la carga ρ = 0.8. Los retardos fijos que suman los enlaces entre el nodo de cruce y oBS, parámetro ‘c’ ecuación (7.77), es de 10 mseg. Se ha variado el retardo entre las estaciones oBS y nBS (que forma parte del parámetro ‘g’ de la ecuación (7.78)), para estudiar la dependencia de este factor. En la figura observamos como el número de paquetes perdidos es nulo cuando el valor del tiempo LDt toma valores superiores a 60 mseg. Recordemos que estamos normalizando en el instante en que se produce el trigger ‘L2-MT’ en el nodo móvil 0=hot , por lo que le eje horizontal de la gráfica también puede ser entendido como la diferencia de tiempo desde que el nodo móvil detecta que se va a producir un handover hasta que, finalmente, pierde la conexión con oBS.


341

Figura 7.30 Número medio de paquetes perdidos en función del trigger ‘L2-LD’.

En la figura anterior también observamos la dependencia con la ruta oBS-nBS-CN. Suponemos que mantenemos constante el valor del retardo nBS-CN en 10 mseg., que coincide con el retardo oBS-CN. La gráfica nos muestra tres situaciones con distintos retardos oBS-nBS: 4, 10 y 30 mseg. Los retardos de 4 y 10 mseg. nos permiten estudiar el comportamiento cuando las dos estaciones base están conectadas directamente, mientras que la situación en el que el retardo es de 30 mseg. intenta simular el comportamiento en el caso de que la ruta entre las dos estaciones no existiera y los mensajes tuvieran que pasar por el nodo de cruce. Es fácil deducir que rutas más pequeñas permiten que el registro de nBS en el árbol se realice más rápidamente, disminuyendo la pérdida de paquetes. La figura 7.31 nos muestra la pérdida de paquetes que puede suceder en caso de que los paquetes sean recibidos en nBS antes de que se haya finalizado el handover de nivel 2. Para la realización de la figura se ha partido de la ecuación (7.86), y se han mantenido constantes los siguientes valores: retardos CN-oBS y oBS-nBS de 10 mseg., tiempo medio


342

entre paquetes en CN T = 10 mseg., y los valores que definen los routers que los utilizados en las gráficas anteriores. El eje horizontal de la gráfica nos muestra le diferencia entre los tiempos LDLU tt − , es decir, el eje nos muestra el tiempo necesario para realizar el handover de capa 2. En particular se ha ido variando el valor

LUt , mientras el valor LDt se ha mantenido constante con valor 60 mseg. Este valor ha sido elegido ya que según la figura 7.30 aseguraba que no se perdieran paquetes por no detectar el handover con la antelación suficiente. Sin embargo, otros valores de este tiempo no modificarían la figura.

Figura 7.31 Paquetes perdidos en función del tiempo de handover L2.

En la gráfica se observa que el número de paquetes perdidos aumenta al aumentar la duración del handover de capa 2. Como hemos analizado los paquetes que llegan antes de que el handover se complete deben ser descartados. Puede observarse como al aumentar el retardo de la ruta CN-nBS, parámetro ‘d’, disminuyen las pérdidas. Simplemente se logra que los paquetes estén más tiempo de camino a nBS, dando tiempo a que el handover L2 se complete.


343

La solución a estas perdidas puede lograrse añadiendo un buffer en la nueva estación base. Así los paquetes que alcanzan la nueva estación base son almacenados a la espera del trigger ‘L2-LU’. El tamaño necesario del buffer dependería, obviamente, de la tasa a la que los paquetes son transmitidos (parámetro T). Ya se ha analizado como la utilización de soluciones multicast conlleva la posibilidad de que algunos paquetes lleguen duplicados al nodo móvil. La figura 7.32 muestra el número medio de paquetes duplicados, realizada a partir de la ecuación (7.91). En ella las rutas CN-oBS, CN-nBS y oNS-nBS tienen un retardo fijo de 10 mseg., y los restantes parámetros toman los mismos valores que los utilizados en la figura anterior.

Figura 7.32 Paquetes duplicados en función del tiempo de handover L2.

Puede observarse como la probabilidad de que se dupliquen paquetes es prácticamente nula. Al descartar nBS los paquetes que llegan antes de LUt , los paquetes duplicados deben llegar a oBS antes de LDt y a nBS después de LUt . Como las rutas entre CN y las estaciones base tienen el mismo retardo fijo, y siempre se va a cumplir que LUt > LDt , la probabilidad de que se produzcan limitaciones es mínima.


344

Sin embargo, podríamos pensar en almacenar los paquetes que le llegan a nBS con el fin de que no se produjeran las pérdidas de paquetes que se mostraron en la figura 7.31. En este caso la duplicación de paquetes ya no dependerá del instante LUt , sino del instante de tiempo

2t en el que la nueva estación base se une al grupo multicast. La figura 7.33 nos muestra el comportamiento del esquema de handover en esta situación. La gráfica se ha realizado eliminando el último término de la ecuación (7.91). El valor del retardo CN-oBS se ha mantenido constante en 10 mseg., y se ha variado el retardo de la ruta oBS-nBS-CN.

Figura 7.33 Paquetes duplicados en función del trigger ‘L2-LD’.

En la gráfica anterior se observa claramente como, en caso de almacenar paquetes en nBS para evitar pérdidas, se producirá una duplicación de paquetes que dependerá tanto del instante LDt como del retardo ‘g’. Anteriormente observamos como el valor del instante LDt equivalía al tiempo en el que adelantábamos el proceso de registro de la nueva estación base al inicio del handover L2. Así al aumentar este tiempo


345

favorecemos que nBS se una antes al árbol multicast y por tanto que empiece la retransmisión de paquetes. De la misma manera, al disminuir el retardo que sufre la conexión al árbol multicast, favorecemos que se una antes y, por tanto, que se retransmitan más paquetes que terminarán duplicados en el nodo móvil.

7.6.3 Conclusiones del handover indirecto con pre-registro En este punto hemos evaluado el proceso de handover cuando el nodo móvil, basándose en la utilización de triggers, adelanta el proceso de incorporación de nBS al árbol multicast al desarrollo del handover de capa 2. Hemos observado como la pérdida de paquetes puede producirse en dos situaciones bien diferenciadas. La primera es cuando el trigger ‘L2-MT’ no se produce con suficiente antelación a la pérdida de conexión con oBS (inicio del handover L2). La figura 7.30 nos muestra estas pérdidas que dependen, además, de la topología de la red. La segunda situación que ocasiona una pérdida de paquetes es cuando el handover L2 tarda demasiado en completarse. En este caso nBS no puede entregar los nuevos paquetes que está recibiendo para el nodo móvil, por lo que tiene que despreciarlos (figura 7.31). La solución a este problema consistiría en disponer de un buffer en la estación que almacenara estos paquetes, con el fin de que puedan ser entregados en cuanto el handover se complete. Finalmente se ha estudiado como, debido a la utilización de tecnologías multicast, es posible la duplicación de paquetes. En particular la duplicación sólo se va a producir en caso de que optemos por incluir el buffer en nBS para evitar la pérdida de paquetes comentada, figura 7.33, y es proporcional al tiempo de adelanto del trigger ‘L2-MT’. Analizando conjuntamente las figuras 7.30 y 7.33 podemos concluir diciendo que un diseño cuidadoso de la topología de la red, o un control del tiempo de inicio


346

de los mecanismos de handover de ambas capas, nos van a permitir que el esquema de handover se realice de manera rápida y sin pérdidas.

7.7 CONCLUSIONES DEL CAPÍTULO En este capítulo se han evaluado, analíticamente, los cinco esquemas de handover que se propusieron para el sistema de micro-movilidad basado en multicast. Se han modelado los routers de forma sencilla, asumiendo que se comportan como colas M/M/1, de manera que el tiempo de servicio de un paquete está distribuido exponencialmente e incluye el tiempo de procesamiento y el de transmisión [BLO02], [BLO02b]. El objetivo es analizar las ventajas de utilizar uno u otro esquema, en función del número de paquetes perdidos, tiempo de interrupción o tiempo de espera en ‘buffers’. A la vez hemos evaluado como afecta a las prestaciones del esquema de handover la modificación de distintos parámetros, como puede ser la topología de la red. Se ha partido del esquema más sencillo, denominado ‘Handover Abrupto’. Hemos comprobado la relación directa del número de paquetes perdidos con la distancia (medida en términos de retardo) existente entre las estaciones y el nodo de cruce, que es el nodo que conectará nBS al árbol multicast. También se ha comprobado como, al ser un handover abrupto, el tiempo en el que el nodo necesita para detectar la conexión a la nueva estación tiene vital importancia. Éste viene determinado, fundamentalmente, por la frecuencia de envío de mensajes ‘Agent Advertisement’ desde nBS. Con el fin de mejorar las prestaciones del esquema anterior se propusieron dos esquemas alternativos, también diseñados para sistemas donde el nodo móvil no es capaz de comunicarse simultáneamente con las dos estaciones base implicadas en el handover.


347

El primero, denominado ‘Handover con Redirecionamiento’, logra un handover suave a base de almacenar temporalmente los últimos paquetes que las estaciones envían a los nodos móviles. Así, si se produce un handover, esos paquetes pueden ser retransmitidos a la nueva estación, evitando la pérdida en caso de no hubieran sido recibidos por el MN. Se ha estudiado el tamaño necesario de los ‘buffers’ de almacenamiento, que evitan la pérdida de paquetes por desbordamiento. En este sentido un tamaño debe ser consecuente con el número medio de paquetes perdidos en el esquema abrupto. Además se ha comprobado como la distancia entre las estaciones base afecta negativamente al comportamiento del esquema. A pesar de que un correcto dimensionado de los ‘buffers’ elimina la posibilidad de pérdida de paquetes, es posible que el nodo móvil reciba paquetes duplicados. Esto se produce cuando la ruta CN-oBS es comparativamente grande en relación a la ruta CN-oBS-nBS. En este caso se ha comprobado como paquetes redirigidos desde oBS a nBS han sido entregados por la nueva estación de manera duplicada. La solución propuesta ha sido realizar un almacenamiento temporal de los paquetes redirigidos en nBS hasta que se recibe el primer paquete vía CN. Esta solución es empleada, aunque por otros motivos, en la bibliografía [PER01]. En caso de no disponer de esta capacidad de almacenamiento, la duplicación de paquetes en este esquema dependería directamente topología de la red. La segunda propuesta para mejorar las prestaciones del handover abrupto es el denominado ‘Handover Indirecto con pre-registro’. Este esquema se basa en la utilización de ‘triggers’ para disminuir el tiempo en el que el nodo no tiene conexión con las estaciones base. La idea básica es que si conozco con suficiente antelación que se va a producir un handover en la capa dos puedo adelantar el proceso de conexión de la nueva estación base al árbol multicast.


348

En este esquema se han detectado y evaluado dos situaciones en las que pueden producirse una pérdida de paquetes. La primera es la misma situación que ocurre en el handover abrupto. Si no conocemos con suficiente antelación que va a producirse un handover no habrá tiempo de que se realice el handover en la capa tres, y habrá un tiempo de interrupción en el que se perderán paquetes. Se ha evaluado esta pérdida concluyendo que hacen falta valores de tiempo de antelación en torno a los 60 mseg. para las condiciones utilizadas en todo este capítulo. La segunda fuente de error se produce cuando el handover de capa dos tiene una duración excesiva de manera que los paquetes que llegan a nBS dirigidos al MN no pueden ser entregados. Se ha propuesto la utilización de ‘buffers’ de almacenamiento temporal para solventar el problema. Un problema derivado de la utilización de tecnología multicast es que es más probable que se den situaciones que provoquen una duplicación de paquetes en el nodo móvil. En este esquema la duplicación se produce en el caso del almacenamiento de paquetes en nBS comentado anteriormente. Se ha analizado conjuntamente las prestaciones del esquema concluyendo que una adecuada relación entre el tiempo de antelación con el que se produce el ‘trigger’ y la topología de la red permiten un handover sin ninguna degradación. Existen sistemas que permiten al nodo móvil comunicarse simultáneamente con las dos estaciones base involucradas en el esquema de handover. En este capítulo se han analizado los dos esquemas que, propuestos en el capítulo 6, funcionaban de esta forma. El primero de los esquemas se denomina ‘Handover Semi Suave’. Se han analizado dos posibles implementaciones de este esquema. En la primera el MN acepta todos los paquetes que recibe de ambas estaciones base mientras se encuentra en la zona de solape. En esta situación no se van a producir pérdida de paquetes, pero si una duplicación que dependerá, directamente, del tiempo en el que el nodo móvil permanece en la zona de cobertura de las dos estaciones. La otra implementación hace


349

que el MN rechace los paquetes de oBS una vez se ha recibido confirmación del registro con nBS. En este caso se ha comprobado como el esquema funciona perfectamente en caso de que las rutas entre el nodo de cruce y las dos estaciones sean similares. En caso contrario se producirá una perdida o duplicación de paquetes dependiendo de si la ruta a la estación base antigua es mayor o menor que la ruta a nBS respectivamente. Para solucionar los problemas que introduce una topología de red inadecuada en el esquema de handover anterior se propuso el esquema ‘Handover Suave con Finalización Controlada’. Este esquema propone dos mejoras con respecto al anterior. La primera consiste en retrasar la desconexión con oBS aun cuando ya se ha registrado correctamente con nBS. Esto permite eliminar la pérdida de paquetes que se producían en topologías donde la ruta a oBS era mayor que la ruta a nBS. Los resultados demuestran que un retraso en cortar la conexión con oBS del mismo tiempo que la diferencia de caminos es suficiente para evitar pérdidas en el MN. Se ha analizado una segunda ventaja consistente en que el nodo móvil almacena información del último paquete recibido con el fin de evitar también las duplicaciones. nBS comienza almacenando los paquetes que recibe del árbol multicast, hasta que MN le envía un mensaje indicando el último paquete recibido. De esta manera nBS descarta los paquetes duplicados. Se ha analizado las repercusiones que tiene esta solución, en cuanto al retardo que sufren algunos paquetes. Así la probabilidad de que un paquete sufra un retardo adicional dependerá del retardo en la desconexión con oBS y de la diferencia de rutas. También se ha analizado las limitaciones que tiene este mecanismo. En concreto, si la ruta hacia nBS es más lenta que la ruta a oBS es muy probable que se retransmitan un gran número de paquetes. Además el número de paquetes duplicados depende del tiempo que el nodo móvil ha retenido la conexión con oBS. Como solución a esta limitación en el punto 6.5.2 se diseñó un mecanismo que permitía al MN decidir el esquema de handover adecuado a la topología de la red, ya que en esta situación es


350

mucho más conveniente utilizar el esquema semi suave analizado previamente.

351

8. CONCLUSIONES Y LÍNEAS FUTURAS DE INVESTIGACIÓN

8.1 INTRODUCCIÓN En este capítulo se exponen las principales conclusiones de la Tesis Doctoral, y se apuntan las posibles líneas de continuación de la misma. Dado que al final de cada capítulo ya se resumieron las conclusiones y disertaciones sobre los resultados y el trabajo desarrollado, en este capítulo se presentan dichas conclusiones desde una perspectiva global y más amplia, destacando de modo particular los aspectos más importantes. Respecto a las posibles vías futuras de investigación, se citarán aquellas líneas que tienen una relación directa con este trabajo, y que pueden ser abordadas como una continuación del mismo, o como una profundización de algunos aspectos aquí tratados sin mucha profundidad. Asimismo se citarán nuevos campos de investigación dentro del área de la movilidad en redes IP.

8.2 CONCLUSIONES GLOBALES

El trabajo desarrollado en esta Tesis Doctoral se ha centrado en el campo de la movilidad en redes IP. Aunque existen distintas soluciones para abordar el problema, actualmente la mayoría de las contribuciones giran en torno al protocolo Mobile IP [RFC 3344].

Sin esconder las ventajas que aporta, y que lo han convertido en la

referencia básica para toda la investigación actual, hay que indicar que Mobile IP tiene importantes limitaciones que no lo hacen útil para entornos

Conclusiones y Líneas futuras de investigación

352

con requerimientos de QoS, como pueden ser su utilización para tráfico multimedia, o para incorporarlo a los sistemas móviles de cuarta generación.

Como se demostró en el capítulo 5 de esta Tesis, uno de los

principales problemas es el tiempo necesario para realizar un handover, ya que el nodo móvil debe indicar al Home Agent cada cambio de su dirección temporal.

Se han realizado algunas propuestas para solucionar esta

limitación, y todas se basan en la división espacial en zonas o dominios, de manera que el handover pueda ser tratado de manera local.

En esta Tesis Doctoral hemos presentado un novedoso sistema de

micro-movilidad basado en la capacidad de transmisión multicast. Aunque previamente ya existían algunas publicaciones que proponían la utilización de las capacidades multicast [MYS98], [HEL00], estas soluciones no estaban planteadas para entornos de micro-movilidad, por lo que adolecen de importantes limitaciones en cuanto a la escalabilidad y prestaciones durante el handover.

La elección de la tecnología multicast como base para realizar un

sistema de micro-movilidad totalmente novedoso se ha debido, principalmente, a que entendemos que el direccionamiento multicast tiene mucho en común con la movilidad, ya que ambas tecnologías se enfrentan al problema de la localización del nodo independientemente de la dirección. Además consideramos que aporta otras ventajas, como la facilidad intrínseca de transmitir datos simultáneamente a dos localizaciones, lo que favorece los handovers sin pérdidas, o la madurez actual de la tecnología, que permite su fácil incorporación a entornos móviles.

A diferencia de la mayoría de las soluciones presentadas en la

literatura, se ha desarrollado, no sólo una arquitectura, sino un protocolo completo, incluyendo el formato de todos los mensajes propuestos. Estos mensajes han sido realizados siguiendo las estructuras de extensión del


353

propio protocolo Mobile IP [RFC 3444], así como los trabajos que se están realizando actualmente [KHA01], [GUS02], [PER02]. El objetivo ha sido que el sistema propuesto pueda integrarse perfectamente en un sistema basado en Mobile IP.

El protocolo especificado tiene presente los posibles problemas de

escalabilidad. También se ha incluido todos los mecanismos de seguridad necesarios en este tipo de redes, incluso se ha abordado el problema del establecimiento de la asociación de seguridad entre el nodo móvil y las estaciones base, tema actualmente bajo estudio en el grupo de trabajo ‘mipv4’ del IETF [MIPv4].

Una vez diseñado el sistema de micro-movilidad basado en multicast se ha abordado el estudio detallado del proceso de handover en redes IP. Hemos diferenciado tres componentes que incrementan el tiempo de latencia total del handover. El objetivo de este estudio ha sido dotar a nuestro sistema de esquemas de handover que superen las limitaciones de las soluciones clásicas.

Se han publicado numerosas propuestas que mejoran las

prestaciones del handover presentado en Mobile IP. Estas propuestas intentan solucionar dos problemas diferenciados: por un lado reducir el elevado tiempo de latencia (Handovers rápidos), por otro lado solucionar el problema de la pérdida de paquetes (Handovers suaves).

Con respecto a reducir el retardo, hemos comprobado que la

bibliografía presenta distintas soluciones que intentan minimizar este retardo. Una solución sería minimizar la latencia del proceso de handover, por ejemplo adelantando el inicio basándonos en la utilización de ‘triggers’. Otra solución sería no interrumpir la entrega de paquetes mientras dura el handover, por ejemplo implementando en los nodos móviles la capacidad de hablar simultáneamente con las dos estaciones base.

Con respecto a la entrega de todos los paquetes, tradicionalmente

se utilizan dos técnicas. Una opción sería introducir algún mecanismo de retransmisión de paquetes pendientes desde oBS a nBS. Otra posibilidad


354

sería realizar una transmisión dualcast temporal de manera que las dos estaciones implicadas reciben los paquetes dirigidos al nodo móvil.

El estudio detallado de todas las propuestas anteriores nos

demuestra que el sistema de micro-movilidad que proponemos ofrece unas propiedades intrínsecas idóneas para lograr, tanto handovers intra-dominio rápidos, como suaves.

En particular, el tiempo de latencia del handover se reduce al

mínimo. Así, el componente del tiempo de latencia que denominamos ‘Retardo en la Recuperación de una Dirección Temporal’, se elimina por completo. Además, el tiempo ‘Retardo de reestablecimiento de la ruta’ se reduce al tiempo necesario para la conexión de la nueva Estación Base al árbol multicast.

Con respecto a la transmisión sin pérdidas de paquetes, el sistema

de micro-movilidad presentado se basa en la conexión de las estaciones base a un árbol multicast asociado al nodo móvil. Esto lleva implícito una transmisión de paquetes hacia las dos estaciones de manera simultánea, facilitando enormemente la implementación de handovers suaves.

Con todo lo anterior hemos propuesto cinco esquemas de handover

diferentes, diseñados para implementarse en el sistema de micro-movilidad basado en multicast. Esos esquemas son adecuados tanto para sistemas en los cuales el nodo móvil no es capaz de mantener la comunicación con dos estaciones base simultáneamente, como para aquellos en los que el nodo móvil puede comunicarse con ambas.

Los cinco esquemas anteriores han sido evaluados analíticamente.

El objetivo es analizar las ventajas de utilizar uno u otro esquema, en función del número de paquetes perdidos, tiempo de interrupción o tiempo de espera en ‘buffers’.

A la vez hemos evaluado como afecta a las prestaciones del

esquema de handover la modificación de distintos parámetros, como puede ser la topología de la red. En este último aspecto, la flexibilidad a la hora


355

de seleccionar un mecanismo de handover u otro ha favorecido enormemente la obtención de buenos resultados aun en topologías de red poco propicias. Podemos concluir indicando que se ha especificado un sistema de micro-movilidad IP novedoso basado en la capacidad multicast. Este sistema ofrece unas prestaciones en seguridad, escalabilidad y simplicidad iguales o superiores a todos los existentes actualmente. Además se han diseñado cinco esquemas de handover para el protocolo anterior, obteniendo una solución global. Esta solución se adapta a todas las tecnologías de acceso a red, y se obtiene altas prestaciones tanto en la latencia del proceso de handover como en el número de paquetes perdidos.

8.3 LÍNEAS FUTURAS DE INVESTIGACIÓN

El campo de la movilidad en redes IP es muy amplio y, a pesar de que ciertos protocolos, como Mobile IP, están consolidados, los grupos de trabajo relacionados con este campo siguen teniendo mucha actividad [MIPv4], [MIPv6].

En la introducción de esta Tesis Doctoral se hizo mención a que los dos problemas que limitaban la incorporación de la arquitectura IP a sistemas móviles eran, por un lado, que el protocolo IP se había planteado para entornos con hosts fijos y, por otro lado, las limitaciones de esta arquitectura para ofrecer QoS. A lo largo de esta memoria se ha demostrado como el problema de ofrecer movilidad se ha resuelto correctamente, con el trabajo conjunto del protocolo Mobile IP junto con soluciones de micro-movilidad como la presentada aquí.

Sin embargo la incorporación de QoS en entornos IP móviles es un tema por resolver y, desde mi punto de vista, la línea de investigación más interesante. En este sentido es interesante consultar la [RFC 3583], donde se indican los requerimientos que deben cumplir los mecanismos de QoS para poder funcionar correctamente en entornos de Mobile IP. La


356

incorporación de QoS puede verse como una continuación directa de esta Tesis, si se incorpora al sistema de micro-movilidad presentado aquí, o como un nuevo campo de investigación.

Otro tema de investigación, relacionado con el anterior sería el

problema de cómo transferir el contexto de una comunicación durante el procedimiento de handover. En este sentido el grupo de trabajo del IETF ‘seamoby’ [SEA] está actualmente trabajando en un protocolo para la transferencia del contexto [LOO04], entendiendo por contexto parámetros como información AAA, características QoS, mecanismo de compresión empleados, contextos de seguridad utilizados, etc.

Otro de los campos con gran proyección es el tema de la seguridad, y en particular el uso de servidores AAA en redes IP móviles. Esta línea de investigación podría verse, tanto como continuación directa de esta Tesis, como abordándolo como un nuevo campo de investigación. Así en esta Tesis se ha propuesto una solución sencilla para el intercambio de claves entre los distintos elementos que forman el sistema. Sin embargo sería aconsejable un mecanismo de acuerdo con las últimas propuestas presentadas [PER04].

La última gran línea de investigación futura es el protocolo Mobile IPv6. A pesar del tiempo desde la primera versión borrador del mismo, y de que se han realizado 24 versiones, aún no se ha estandarizado completamente. En la actualidad son muchas las áreas dentro de la versión Mobile IPv6 donde se está trabajando intensamente: seguridad en los mecanismos de optimización de ruta, utilización de IPsec entre el nodo móvil y el HA, handover rápidos, funcionamiento de protocolo en presencia de ‘firewalls’, etc.

357

BIBLIOGRAFÍA

ARTÍCULOS

[ABR72] M. Abramowitz, y I. Stergun. ‘Handbook of Mathematical Functions with Formulas, Graphs, and Mathematical Table’, Pag. 930. Dover Publications, 1972.

[ACA94] A.S. Acampora, M. Naghshineh. ‘An Architecture and Methodology for Mobile-Executed Handoff in Cellular ATM Networks’. IEEE J.S.A.C. Octubre 1994.

[AKY97] B.A. Akyol, D.C. Cox. ‘Signaling Alternatives in a Wireless ATM Network’. IEEE J.S.A.C. Special Issue on Wireless ATM, Enero 1997.

[ALT02] O. Altintas, A. Dutta, y H. Schulzrinne. ‘Mobility Approaches for All IP Wireless Networks’. Proc. of IEEE Wireless Communications and Networking Conference (WCNC), Marzo 2002.

[ANA93] V. Anantharam, M. L. Honing, U. Madhow y V.K. Wei. ‘Optimization of a Database Hierarchy for Mobility Tracking in a Personal Communications Network’. Proc. of Perfomance 93, Septiembre 1993.

[AWE91] B. Awerbuch y D. Peled. ‘Online Tracking on mobile users’. Proc. of ACM SIGCOMM, 1991.

[BAK96] M.G. Baker, X. Zhao, S. Cheshire, y J, Stone. ‘Supporting Mobility in MosquitoNet’. Proc. of 1996 USENIX Technical Conference, Enero 19996.

[BAL95] H. Balakrishnan, S. Seshan, y R. H. Katz. ‘Improving Reliable Transport ad Handoff Performance in Cellular Wireless Networks’. ACM Wireless Networks, Diciembre 1995.

[BAL96] H. Balakrishnan, V.N. Padmanabhan, S. Seshan, y R.H. Katz. ‘A Comparison of Mechanisms for Improving TCP Perfomance over Wireless Links’. Proc. of ACM SIGCOMM, Agosto 1996.

Bibliografía

358

[BALL98] A. Ballardie, B. Cain, Z. Zhang. ‘Core Based Trees (CBT version 3) Multicast Routing’. Internet Draft. Draft-ietf-idmr-cbt-spec-v3-01.txt. (Work in Progress), Agosto 1998.

[BHA03] S. Bhattacharyya et al. ‘An Overview of Source-Specific Multicast (SSM’). Internet Draft. Draft-ietf-ssm-overview-05.txt. (Work in Progress), Mayo 2003

[BHA95] V. Bhaskaran, y K. Konstantinides. ‘Image and Video Compresión Standards. Algorithms and Architectures’. Kluwer Academic Publishers, 1995.

[BHA96] P. Bhagwat, C. Perkins y S. K. Tripathi. ‘Network Layer Mobility : an Architecture and Survey’. IEEE Personal Communication v.3 no.3, Junio 1996.

[BLA96] G. Blakowski, R. Steinmetz, ‘A Media Synchronization Survey: Reference Model, Specification, and Case Studies’, IEEE J.S.A.C, Vol. 14, Nº. 1, Enero 1996.

[BLO02] C. Blondia, O. Casals, P. De Cleyn, y G. Willems. ‘Performance Analysis of IP Micro-Mobility Handoff Protocols’. Proc. of Protocols for High Speed Networks 2002 (PfHSN 2002), Berlín 2002.

[BLO02b] C. Blondia, O. Casals, P. De Cleyn, y G. Willems. ‘Performance Analysis of a Forwarding Scheme for Handoff in HAWAII’. Proc. of Networking 2002, Pisa 2002.

[BLO02c] C. Blondia, N. Van den Wijngaert, G. Willems, y O. Casals. ‘Performance Analysis of Optimized Smooth Handoff in Mobile IP’. Proc. of MSWiM, Atlanta 2002.

[BLO03] C. Blondia, O. Casals, Ll. Cerdá, N. Van den Wijngaert, G. Willems, P. De Cleyn. ‘Performance Comparison of Low Latency Mobile IP schemes’. Proc. of WiOpt, Marzo 2003.

[BRA94] L. Brakmo, S. O'Malley, and L. Peterson. ‘TCP Vegas: New techniques for congestion detection and avoidance’. Proc. of the SIGCOMM '94 Symposium, Agosto 1994.

[CAC94] R. Caceres y L. Iftode. ‘Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments’. IEEE Journal on Selected Areas in Communications, 1994.

Bibliografía

359

[CAC96] R. Caceres, y V. N. Padmanabhan. ‘Fast and Scalable Handoffs for Wireless Internetworks’. Proc of ACM MobiCom’96, Noviembre 1996.

[CAL01] P. Calhoun, A. Rubens, H. Akhtar, y E. Guttman. ‘DIAMETER Base Protocol’. Internet Draft. Draft-ietf-aaa-diameter-07.txt. (Work in Progress), Julio 2001.

[CAM00] A. T. Campbell, J. Gomez, S. Kim, A. G. Valko, C-Y. Wan, y Z. Turanyi. ‘Design, Implementation, and Evaluation of Cellular IP’. IEEE Personal Communications, vol. 7, no. 4, Agosto 2000.

[CAM01] A. T. Campbell, J. Gomez. ‘IP Micro-Mobility Protocols’. ACM SIGMOBILE Mobile Computer and Communication Review (MC2R), Vol. 4, No. 4, pp 45-54, Octubre 2001.

[CAM02] A. T. Campbell, J. Gomez, S. Kim, C-Y. Wan , Z. Turanyi y A. G. Valko. ‘Comparison of IP Micromobility Protocols’. IEEE Wireless Communications Magazine, Vol. 9, No. 1, Febrero 2002.

[CHA01] K. Chakraborty et al. ‘Implementation and Performance Evaluation of TeleMIP’. Proc. of IEEE International Conference on Communications, ICC, 2001.

[DAS00] S. Das et al. ‘TeleMIP: Telecommunication-Enhanced Mobile IP Architecture for Fast Intradomain Mobility’. IEEE Personal Communications, vol. 7, no. 4, Agosto 2000.

[DEE90] S.Deering, D. Cheriton. ‘Multicast routing in datagram internetworks and extended LAN’s’. ACM Transactions on Computer Systems, pp. 85-111, Mayo 1990.

[DOM01] G. Dommety, y T. Ye. ‘Local and Indirect Registration for Anchoring Handoffs’. Internet Draft. Draft-dommety-mobileip-anchor-handoff-03.txt (Work in Progress), Julio 2001.

[DUT01] A. Dutta, R. Jain, K.D. Wong, J. Burns, K. Young y H. Schulzrinne. ‘Multilayered Mobility Management for Survivable Network’. Proc. of Milcom, Octubre 2001.

[DUT01b] A. Dutta, F. Vakil, J. Chen, y M. Tauil. ‘Application Layer Mobility Management Scheme for Wireless Internet’. Proc. of

Bibliografía

360

IEEE 3Gwireless01, Mayo 2001.

[EAR00] P. Eardley, A. Mihailovic, y T. Suihko. ‘A Framework for the Evaluation of IP Mobility Protocols’. Proc. of PIMRC, Septiembre 2000.

[EAR02] P. Eardley, N. Georganopoulos, M.A. West. On the Scalability of IP Micro-Mobility Management Protocols. Proceedings of MWCN, Septiembre 2002.

[ELM00] K. El Maki, y H. Soliman. Fast Hand-offs in Mobile Ipv4. Internet Draft. Draft-elmalki-mobileip-fast-handoffs-03.txt. (Work in Progress), Septiembre 2000.

[ELM02] K. El Malki, et al. ‘Low Latency Handoffs in Mobil IPv4’. Internet Draft. draft-ietf-mobileip-lowlatency-handoffs-v4-04.txt. (Work in Progress), Junio 2002.

[ELZ01] R. Elz y P. Hethmon. Extensions to FTP. Internet Draft. draft-ietf-ftpext-mlst-13.txt. (Work in Progress), Mayo 2001.

[ENG95] K.Y. Eng, et al. ‘BAHAMA : A Broadband Ad-Hoc Wireless

ATM Local Area Networks’. ACM/Baltzer Journal on Wireless Networks, vol. 1, Nº 2, 1995.

[FEN03] B. Fenner, M. Handley, H. Holbrook, y I. Kouvelas. ‘Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)’. Internet Draft. draft-ietf-pim-sm-v2-new-07.txt . (Work in Progress), Marzo 2003

[GUS02] E. Gustafsson, A. Jonsson, y C. Perkins. ‘Mobile IP Regional Registration’. Internet Draft. draft-ietf-mobileip-reg-tunnel-06.txt. (Work in Progress), Marzo 2002.

[HEL00] A. Helmy. ‘Multicast-based Architecture for IP Mobility: Simulation Analysis and Comparision with Basic Mobile IP’. Technology Research News Journal, Nº1, Junio 2000.

[HOL03] H. Holbrook y B. Cain. ‘Source-Specific Multicast for IP’. Internet Draft. Draft-ietf-ssm-arch-03.txt. (Work In Progress), Mayo 2003

[IEEE 802.11]

‘Wirweless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications’. IEEE std. 802.11, 1999.

[IEEE ‘Recommended Practice for Multi-Vendor Access Point

Bibliografía

361

802.11f] Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting 802.11 Operation’. IEEE Std 802.11f/D3, Draft. Enero 2002.

[IOA91] J. Ioannidis, D. Duchamp, y G.Q. Maguire Jr. ‘Ip-based Protocols for Mobile Internetworking’. Proc. of ACM SIGCOMM, 1991.

[IOA93] J. Ioannidis, G.Q. Maguire Jr. ‘The Design and Implementation of a Mobile Internetworking Architecture’. Proc. of Winter USENIX, Enero 1993.

[JAC88] V. Jacobson. ‘Congestion Avoidance and Control’. ACM SIGCOMM’88, Agosto 1988

[JAI91] R. Jain. ‘The Art of Computer Systems Performance Analysis : Techniques for Experimental Design, Measurement, Simulation, and Modeling’. Ed. John Wiley & Sons, Abril 1991. ISBN: 0471503363

[JOH03] D.B. Johnson, C. Perkins, y J. Arkko. ‘Mobility Support in IPv6’. Internet Draft, Draft-ietf-mobileip-ipv6-24.txt. (Work in Progress), Junio 2003.

[JOH94] D.B. Johnson. ‘Scalable and Robust Internetwork Routing for Mobile Hosts’. Proc. of the 14th International Conference on Distributed Computing Systems, junio 1994

[JOH95] D.B. Johnson. ‘Scalable Support for Transparent Mobile Host Internetworking’. ACM/Baltzer Wireless Networks, vol. 1, no. 3, 1995.

[JON99] A. Jonsson, E. Gustafsson, y C. Perkins. ‘Mobile IP Regional Tunnel Managemen’t. Internet Draft, draft-ietf-mobileip-reg-tunnel-01.txt. (Work in Progress), Agosto 1999.

[KAU95] C. Kaufman, R. Perlman, y M. Spencer. ‘Network Security: Private Communication in a Public World’. Ed. Prentice Hall, 1995.

[KEM00] J. Kempf, P.R. Calhoun, y C. Pairla. ‘Foreign Agent Assisted Hand-off’. Internet Draft. Draft-calhoun-mobileip-proactive-fa-01.txt. (Work in Progress), Junio 2000.

[KEM01] J.Kempf, P. McCann, y P. Roberts. ‘IP Mobility and the CDMA Radio Access Network: Applicability Statement for Soft

Bibliografía

362

Handoff’. Internet Draft. Draft-kempf-cdma-appl-02.txt (Work in Progress), Septiembre 2001.

[KER94] D. Kerek, H.Tenhunen, G.Q.Maguire, y F.Reichert. ‘Direct Sequence CDMA Technology and its Application to Future Portable Multimedia Communication Systems’. Proc. of IEEE ISSTA, Julio 1994

[KHA01] M. Khalil, E. Qaddoura, H. Akhtar y P. Calhoun. ‘Generalizad NAI (GNAI) Extension for Mobile IPv4’. Internet Draft. draft-ietf-mobileip-gnaie-05.txt. (Work in Progress), Octubre 2001.

[KLE75] L. Kleinrock. ‘Queueing Systems, Volumen 1, Theory’. Ed. John Wiley & Sons. ISBN: 0471491101, 1975.

[KOO02] R. Koodli (Ed.). ‘Fast Handovers for Mobile IPv6’. Internet Draft. draft-ietf-mobileip-fast-mipv6-05.txt. (Work in Progresss), Septiembre 2002.

[LAM96] L. Lamont, L. Li, R. Brimont, D. Georganas, ‘Synchronization of Multimedia Data for a Multimedia News-on-Demand Application’. IEEE J.S.A.C., Vol. 14, Nº. 1, Enero 1996.

[LEO98] A. León, M. Esteve, J.C. Guerri, C. Palau ‘A New Hand-Off Protocol for an ATM Based Wireless Network’, Proc. Of 16th.IASTED International Conference Applied Informatics, Febrero 1998.

[LEO99] A. León, A. Pajares, M.Esteve, J.C. Guerri, C.Palau ‘Hand-off and Synchronization Protocols for Supporting Multimedia Communications in an ATM Wirteless Network’ Proc. of IEEE ICATM, Junio 1999.

[LI96] J. Li, R. Yuan. ‘Handoff Control in Wireless ATM Networks: An Experimental Study’. ICUPC’ 96. Boston 1996.

[LIN96] J.C. Lin y S. Paul. ‘RMTP: A Reliable Multicast Transport Protocol’. Proc. of IEEE Infocom, Abril 1996.

[LIT90] T.D.C. Little, A. Ghafoor, ‘Synchronization and Storage Models for Multimedia Objects’, IEEE J.S.A.C., Vol. 8, Nº. 3, Abril 1990.

[LIU96] J.Liu, G.Q.Maguire, y G.Liu. ‘Enhancing the Efficiency and

Bibliografía

363

Reliability of Handover and Routing Performance in Wireless Mobile Internetworking Enviroments’. Proc. of IFIP TC62, 1996

[LOU04] J. Loughney, M. Nakhjiri, C. Perkins, y R. Koodli. ‘Contex Transfer Protocol’. Internet Draft. Draft-ietf-seamoby-ctp-08.txt (Work in Progress), Enero 2004.

[MAN02] J. Manner, M. Kojo. ‘Mobility related Terminology’. Internet Draft. Draft-ietf-seamoby-mobility-terminology-01.txt. (Work in Progress), Noviembre 2002.

[MIS00] A. Misra, S. Das, A. Mcauley, A. Dutta, y S.K. Das. ‘IDMP: An Intra-Domain Mobility Mangement Protocol Using Mobility Agents’. Internet Draft. draft-misra-mobileip-idmp-00.txt. (Work in Progress), Julio 2000

[MIS00b] A. Misra, S. Das, A. Mcauley, A. Dutta, y S.K. Das. ‘Intregating QoS support in TeleMIP’s Mobility Architecture’. Proc. 2000 IEEE International Conference on Personal Wireless Communications, ICPWC, Diciembre 2000.

[MIS01] A. Misra, S. Das, A. Dutta, y S.K. Das. ‘IDMP-based Fast Handoffs and Paging in ip-based Cellular Networks’. Proc. IEEE 3-G Wireless Conference, 2001.

[MOH94] S. Mohan, Y. Lin, A. Noerpel. ‘PCS Channel Assignments Strategies For Handoff Initial Access’. IEEE Personal Communications Magazine, 3-1994.

[MYL93] A. Myles y D. Skellern. ‘Comparing four IP based Mobile Host Protocols’. Computer Networks and ISDN Systems V.26, 1993.

[MYL95] A. Myles, D.B. Johnson, y C. Perkins. ‘A Mobile Host Protocol supporting Route Optimization and Authentication’ Journal on Selected Areas en Communications, junio 1995.

[MYS97] J. Mysore, V. Bharghavan. ‘A New Multicasted-based Architecture for Internet Host Mobility’. Proc. of ACM Mobicom, Septiembre 1997.

[MYS98] J. Mysore, V. Bharghavan. ‘Perfomance of Transport Protocols over a Multicasting-based Architecture for Internet Host MobilityA New Multicasted-based Architecture for Internet Host Mobility’. Proc. of ACM Mobicom, Septiembre

Bibliografía

364

1997.

[ONE00] A. O'Neill, G. Tsirtsis, y S. Corson. ‘Edge Mobility Architecture’. Internet Draft. draft-oneill-ema-01.txt. (Work in Progress), Marzo 2000.

[PAJ99] A. Pajares, N. Berier, L. Wolf, R. Steinmetz. ‘An Approach to Suppport Mobile QoS in an Integrated Services Packet Network’. Proc. of IQWiM, Mayo 1999.

[PAR97] V. Park y M.S. Corson. ‘A Highly Adaptative Distributed Routing Algorithm for Mobile Wireless Networks’. IEEE Proc. of Infocom, Abril 1997.

[PER00] C. Perkins , D. Johnson, y N. Asokan. ‘Registration Keys for Route Optimization’.Internet draft. draft-ietf-mobileip-regkey-03.txt. (Work in Progress), Julio 2000.

[PER01] C. Perkins y D.B. Johnson. ‘Route Optimization in Mobile IP’. Internet Draft. draft-ietf-mobileip-optim-11.txt. (Work in Progress), Septiembre 2001.

[PER02] C. Perkins y P. Calhoun. ‘AAA Registration Keys for Mobile IP’. Internet Draft. draft-ietf-mobileip-aaa-key-09.txt. (Work in Progress), Febrero 2002.

[PER04] C. Perkins y P. Calhoun. ‘AAA Registration Keys for Mobile Ipv4’. Internet Draft. draft-ietf-mip4-key-03.txt. (Work in Progress), Febrero 2004.

[PER94] C. Perkins y P. Bhagwat. ‘A Mobile Networking System based on Internet Protocol’. IEEE Personal Communicaation Magazine, febrero 1994.

[PER94b] C. Perkins, A.Myles y D. Johnson. ‘IMHP: A Mobile Hosts Protocol for the Internet’. Computer Networks and ISDN Systems V.27, 1994

[PER99] C. Perkins y K. Wang. ‘Optimized Smooth Handoffs in Mobile IP’. Proc. of the IEEE Symposium on Computers and Communications, Julio 1999.

[POL96] G. P. Pollini. ‘Trends in Handover Design’. IEEE Communications Magazine, Marzo 1996.

[RAM00] R. Ramjee, T.L. Porta, y L. Li. ‘Paging Support for IP

Bibliografía

365

Mobility’. Internet Draft. draft-ietf-mobileip-paging-hawaii-01.txt. (Work in Progress), Julio 2000.

[RAM00b] R. Ramjee, T.L. Porta, L. Salgarelli, S. Thuel, K. Varadhan, y L. Li. ‘IP Based Access Network Infrastructure for Next Generation Wireless Data Networks’. IEEE Personal Communications Mag. Vol 7, Agosto 2000.

[RAM96] R. Ramjee, T. La Porta, J. Kurose, y D. Towsley. ‘Performance Evaluation of Connection Rerouting Schemes for ATM-based Wireless Networks’. IEEE/ACM Transactions on Networking. Vol. 6, Nº 2, Junio 1998.

[RAM99] R. Ramjee, T.L. Porta, S. Thuel, K. Varadhan, S.Y Wang. ‘Hawaii: A Domain-based Approach for Suporting Mobility in Wide-area Wireless Networks’. Proc. IEEE International Conference of Network Protocols, 1999

[REI01] P. Reinbold y O. Bonaventure. ‘A Comparison of IP Mobility Protocol’. Tech. Rep. Infonet-TR-2001-07, University of Namur, Infonet Group, Junio 2001.

[SCH00] H. Schulzrinne, y E. Wedlund. ‘Application Layer Mobility Support using SIP’. ACM Mobile Computing and Communications Review, vol. 4, no. 3, Julio 2000.

[SCH95] B. Schneier. ‘Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2 ed.’Ed. Fohn Wiley & Soons, 1995.

[SES97] S. Seshan, H. Balakrishnan, y R.H. Katz. ‘Handoffs in Cellular Wireless Networks: The Daedalus Implementation and Experience’. Kluwer Journal on Wireless Networks, 1995

[SHE01] Z.D. Shelby, D. Gatzounas, A. Campbell, Ch. Wan. ‘Cellular IPv6’. Internet Draft. draft-shelby-cellularipv6-01.txt. (Work in Progress), Julio 2001.

[SNO00] A.C. Snoeren y H. Balakrishnan. ‘An End-toEnd Approach to Host Mobility’. 6th ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom’00), Agosto 2000.

[SOL98] J.D. Solomon. ‘Mobile IP: The Internet Unplugged’. Ed. Prentice Hall, 1998

Bibliografía

366

[STA98] M. Stangel y V. Bharghavan. ‘Improving TCP Performance in Mobile Computing Environments’. Proc. of International Conference on Communications, Junio 98.

[STE90] R. Steinmetz, ‘Synchronization Properties in Multimedia Systems’, IEEE J.S.A.C Vol. 8, Nº. 3, Abril 1990.

[TER91] F. Teraoka, Y. Yokote, y M. Tokoro. ‘A Network Architecture Providing Host Migration Transparency’. Proc. of ACM SIGVCOMM, 1991.

[TER93] F. Teraoka y M.Tokoro. ‘Host Migration Transparency in IP Networks’. Computer Communications Review, enero 1993.

[TER94] F. Teraoka, K. Uehara, H. Sunahara, y J. Murai. ‘VIP: A Protocol Providing Host Mobility’. Communications of the ACM, agosto 1994.

[VAL99] A.G. Valko. ‘Cellular IP: A New Approach to Internet Host Mobility’. ACM Computer Communication Review, Enero 1999.

[VAT98] J. Vatn y G.Q. Maguire Jr. ‘The effect of using co-located care-of address on macro handover latency’. Proc. of the 14th Nordic Tele-traffic Seminar, Agosto 1998.

[VID03] R. Vida y L. Costa. ‘Multicast Listener Discovery Version 2 (MLDv2) for IPv6’. Internet Draft. draft-vida-mld-v2-07.txt. (Work in Progress), Junio 2003

[WED99] E. Wedlund, H. Schulzrinne. ‘Mobility Support Using SIP’. Proc. of the 2nd ACM International Workshop on Wireless Mobile Multimedia (WoWMoM'99), Agosto 1999.

[WILL00] B. Williamson. ‘Developing IP Multicast Networks’. Cisco Press, 2000

[WIS02]

D. Wisely, P. Eardley, y L. Burness. ‘IP for 3G: Networking Technologies for Mobil Communications’. John Wiley & Sons, 2002

[WON01] K. D. Wong, H. Wei, A. Dutta, y K Young. ‘Performance of IP Micro-Mobility Management Schemes using Host Based

Bibliografía

367

Routing’. Proc. of International Symposium on Wireless Personal Multimedia Communications WPMC '01, Septiembre 2001.

[YAV94] R. Yavatkar y N. Bhagwat. ‘Improving end-to-end Performance of TCP Over Mobile Internetworks’. Workshop on Mobile Computing Systems and Applications, Diciembre 1994

[YEG02] A.E. Yegin (editor) et al. ‘Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems’. Internet Draft. draft-manyfolks-l2-mobilereq02.txt. (Work in Progress), Junio 2002

[YEG02b] A.E. Yegin. ‘Link-Layer Triggers Protocol’. Internet Draft. draft-yegin-l2-triggers-00.txt (Work in Progress), Junio 2002

[YUA96] R. Yuan, S. K. Biswas, D. Raychaudhuri. ‘A Signaling and Control Architecture for Mobility Support in Wireless ATM Networks’. Mobile Networks and Applications (MONET), nº3 V.1, 1996

[ZHA98] X. Zhao, C. Castelluccia, y M. Baker. ‘Flexible Network Support for Mobility’. Proc. of Mobicom, Octubre 1998.

REQUEST FOR COMMENTS, RFC

[RFC 768] J. Postel. ‘User Datagram Protocol’, Agosto 1980.

[RFC 791] J. Postel. ‘Internet Protocol’, Septiembre 1981.

[RFC 793] J. Postel. ‘Transmission Control Protocol’. Septiembre 1981.

[RFC 826] D.C. Plummer. ‘Address Resolution Protocol’, Noviembre 1982.

[RFC 1035] P. Mockapetris. ‘Domain Names - Implementation and Specification’, Noviembre 1987.

[RFC 1075] D. Waitzman, C. Partridge, y S. Deering. ‘Distance Vector Multicast Routing Protocol’, Noviembre 1988.

Bibliografía

368

[RFC 1112] S. Deering. ‘Host Extensions for IP Multicasting’, Agosto 1989.

[RFC 1122] R. Braden. ‘Requirements for Internet Host’, Octubre 1989.

[RFC 1256] S. Deering. ‘ICMP Router Discovery Messages’, Septiembre 1991.

[RFC 1321] R. Rivest. ‘The MD5 Message-Direct Algorithm’, Abril 1992.

[RFC 1332] G. McGregor. ‘The PPP Internet Protocol Control Protocol’, Mayo 1992.

[RFC 1584] J. Moy. ‘Multicast Extensions to OSPF’, Marzo 1994.

[RFC 1701] S. Hanks, T. Li, D. Farinacci, y P. Traina. ‘Generic Routing Encapsulation (GRE)’, Octubre 1994.

[RFC 1945] T. Berners-Lee, R. Fielding, y H. Frystyk. ‘Hypertext Transfer Protocol. HTTP/1.0’, Mayo 1996.

[RFC 1889] H. Schulzrinne, S. Casner, R. Frederic, y V. Jacobson. ‘RTP: A Transport Protocol for Real-Time Applications’, Junio 1996.

[RFC 1994] W. Simpson. ‘PPP Challenge Handshake Authentication Protocol (CHAP)’, Agosto 1996.

[RFC 2002] C. Perkins. ‘IP Mobility Support’, Octubre 1996.

[RFC 2003] C. Perkins. ‘IP Encapsulation Within IP’, Octubre 1996.

[RFC 2004] C. Perkins. ‘Minimal Encapsulation Within IP’, Octubre 1996.

[RFC 2104] H. Krawczyk, M. Bellare, y R. Canetti. ‘HMAC: Keyed-Hashing for Message Authentication’, Febrero 1997.

[RFC 2117] D. Estrin et al. ‘Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification’, Junio 1997.

[RFC 2131] R. Droms. ‘Dynamic Host Configuration Protocol (DHCP)’, Marzo 1997.

Bibliografía

369

[RFC 2189] A. Ballardie. ‘Core Based Trees (CBT version 2) Multicast Routing’, Septiembre 1997.

[RFC 2201] A. Ballardie. ‘Core Based Trees (CBT) Multicast Routing Architecture’, Septiembre 1997.

[RFC 2205] R. Braden, L. Zhang, S. Berson, S. Herzog, y S. Jamin. ‘Resource Reservation Protocol (RSVP)’, Septiembre 1997.

[RFC 2215] S. Shenker, y J.Wroclawski. ‘General Characterization Parameters for Integrated Service Network Elements’, Septiembre 1997.

[RFC 2236] W. Fenner. ‘Internet Group Management Protocol, Version 2’, Noviembre 1997.

[RFC 2290] J. Solomon, y S. Glass. ‘Mobile-IPv4 Configuration Option for PPP IPCP’, Febrero 1998.

[RFC 2362] D. Estrin et al. ‘Protocol Independent Multicast-Sparce Mode (PIM-SM)’, Junio 1998.

[RFC 2373] R. Hinden, S. Deering. ‘IP Version 6 Addressing Architecture’, Julio 1998.

[RFC 2402] S. Kent, y R. Atkinson. ‘IP Authentication Header’, Noviembre 1998.

[RFC 2406] S. Kent, y R. Atkinson. ‘IP Encapsulating Security Payload (ESP)’, Noviembre 1998.

[RFC 2408] D. Maughan, M. Schertler, M. Schneider, y J. Turner. ‘Internet Saecurity Association and Key Management Protocol (ISAKMP)’, Noviembre 1998.

[RFC 2460] S. Deering, R. Hinden. ‘Internet Protocol, version 6 IPv6 Specification’, Diciembre 1998.

[RFC 2461] T. Narten, E. Nordmark, y W. Simpson. ‘Neighbor Discovery for IP Version 6 (IPv6)’, Diciembre 1998.

[RFC 2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, y W. Weiss. ‘An Architecture for Differentiated Services’, Diciembre 1998.

Bibliografía

370

[RFC 2462] S. Thomson, y T. Narten. ‘IPv6 Stateless Address Autoconfiguration’, Diciembre 1998.

[RFC 2486] B. Aboba, y M. Beadles. ‘The Network Access Identifier’, Enero 1999.

[RFC 2526] D. Johnson, y S. Deering. ‘Reserved IPv6 Subnet Anycast Addresses’, Marzo 1999.

[RFC 2543] M. Handley, H. Schulzrinne, E. Schooler, y J. Rosenberg. ‘SIP: Session Initiation Protocol’, Marzo 1999.

[RFC 2582] S. Floyd, y T. Henderson. ‘The NewReno Modification to TCP's Fast Recovery Algorithm’, Abril 1999.

[RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, y T. Berners-Lee. ‘Hypertext Transfer Protocol, HTTP 1.1’, Junio 1999.

[RFC 2794] P. Calhoun, y C. Perkins. ‘Mobile IP Network Access Identifier Extension for Ipv4’, Marzo 2000.

[RFC 2827] P. Ferguson, y D. Senie. ‘Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing’, Mayo 2000.

[RFC 2865] C. Rigney, S. Willens, A. Rubens, y W. Simpson. ‘Remote Authentication Dial In User Service (RADIUS)’, Junio 2000.

[RFC 2976] S. Donovan. ‘The SIP INFO Method’, Octubre 2000.

[RFC 2977] S. Glass, T. Hiller, S. Jacobs, y C.Perkins. ‘Mobile IP Authentication, Authorization, and Accounting Requirements’, Octubre 2000.

[RFC 3012] C. Perkins, P. Calhoun. ‘Mobile IPv4 Challenge/Response Extensions’, Noviembre 2000.

[RFC 3024] G. Montenegro. ‘Reverse Tunneling for Mobile IP, revised’, Enero 2001.

[RFC 3184] S. Harris. ‘IETF Guidelines for Conduct’, Octubre 2001.

[RFC 3344] C. Perkins. ‘IP Mobility Support for IPv4’, Agosto 2002.

Bibliografía

371

[RFC 3376] B. Cain, S. Deering, I.Kouvelas, B. Fenner, y A. Thyagarajam. ‘Internet Group Management Protocol, Version 3’, Octubre 2002.

[RFC 3583] H. Chascar. ‘Requirements of a Quality of Service (QoS) Solution for Mobile IP’. Septiembre 2003.

RECURSOS EN INTERNET

[COM] http://www.comet.columbia.edu/

[COR] http://www.isi.edu/conser/index.html

[DYN] http://dynamics.sourceforge.net/

[HP] http://www.hpl.hp.com/personal/Jean_Tourrilhes/MobileIP/index.html

[IANA] Internet Assigned Number Authority. http://www.iana.org/numbers.html

[JMF] http://java.sun.com/products/java-media/jmf/

[MGE] http://manimac.itd.nrl.navy.mil/MGEN

[MIPv4] http://www.ietf.org/html.charters/mip4-charter.html

[MIPv6] http://www.ietf.org/html.charters/mip6-charter.html

[MOB] http://www.iprg.nokia.com/~charliep/mobins2/

[MON] http://www.monarch.cs.rice.edu/

[MOS] http://mosquitonet.stanford.edu/mip/

[NS2] http://www.isi.edu/nsnam/ns

[NTT] http://www.leo.org/~elmar/nttcp/

[OPN] http://www.opnet.com/products/modeler/

Bibliografía

372

[POR] http://www.cs.pdx.edu/research/SMN/

[SEA] http://www.ietf.org/html.charters/seamoby-charter.html

[SAM] http://www.isi.edu/saman/index.html

[SUN] http://playground.sun.com/pub/mobile-ip/index.html

[TCP] http://www.tcpdump.org

373

ANEXO1. ACRÓNIMOS Y GLOSARIO

ACRÓNIMOS 3GPP 3rd Generation Partnership Project. 3GPP2 3rd Generation Partnership Project 2. AAA Authentication, Authorization, Accounting. AAL ATM Adaptation Layer. aFA Anchor Foreign Agent. (Handover con post registro). AP Access Point. AR Access Router. ATM Asynchronous Transfer Mode. BS Base Station. BSC Base Station Controllers. (Tecnología GSM) BSS Basic Service Set (tecnología WLAN). CBR Constant Bit Rate. CBT Core Based Trees. [RFC 2189] CDMA Code Division Multiple Access. CHAP Handshake Authentication Protocol. [RFC 1994] CN Correspond Node. COA Care-of Address. DHCP Dynamic Host Configuration Protocol. [RFC 2131] DNS Domain Name System. [RFC 0921] DRR Domain Root Router. (Esquema Hawaii) DVMRP Distance Vector Multicast Routing Protocol. [RFC 1075] ESP Encapsulating Security Payload. [RFC 1827] FA Foreign Agent. GFA Gateway Foreign Agent. (Esquema MIP-RR) GPRS General Packet Radio Service. GTP GPRS Tunnelling Protocol. HA Home Agent. HBR Host Based Routing. HMAC Hashed Message Authentication Code. [RFC 2104] HN Home Network. IAPP InterAccess Point Protocol. (Tecnología IEEE 802.11f)

Anexo1. Acrónimos y Definiciones

374

ICMP Internet Control Message Protocol. [RFC1256] IDMP Intra-Domain Mobility Management Protocol. IGMP Internet Group Management Protocol. [RFC 3376] IP Internet Protocol. [RFC 791] IPCP PPP Internet Protocol Control Protocol. [RFC1332] ISAKMP Internet Security Association and Key Management

Protocol. [RFC 2408] LSR Loose Source Routing. MA Mobility Agent. (Esquema Cellular IP) MAE Multicast Address Extensión. (Esquema multicast

propuesto) MAS Mobile Access Station. (Tecnología LSR) MIP Mobile IP. [RFC 3344] MIP-RR Mobile IP with Regional Registration. MMA Multicast Mobility Agent. (Esquema multicast propuesto) MN Mobile Node. MNF Multicast Non-Forwarding. (Esquema Hawaii) MOSPF Multicast Extension to OSPF. [RFC 1584] MR Mobile Router. (Tecnología LSR) MSC Mobile Switching Centre. (Tecnología GSM) MSF Multiple Stream Forwarding. (Esquema Hawaii) MSR Mobile Support Routers. (Esquema Columbia) MWIF Mobile Wireless Internet Forum. NAI Network Access Identifier. nBS New Base Station. nFA New Foreign Agent. oBS Old Base Station. oFA Old Foreign Agent. OSPF Open Shortest Path First Protocol. [RFC 1247] PDP Packet Data Protocol. (Tecnología 3G) PIM-SM Protocol Independent Multicast- Sparse Mode. [RFC

2362] RADIUS Remote Authentication Dial In User Service. [RFC 2865] RNC Radio Network Controler. (Tecnología 3G) RP Rendezvous Point. (Tecnología multicast) RR Root Router. (Tecnología multicat) RSVP Resource Reservation Protocol. [RFC 2205]


375

RTP Transport Protocol for Real-Time Applications. [RFC 1889]

SIP Session Initiation Protocol. SPI Security Parameter Index. SPT Shorted Path Tree. SRT Source Based Tree. (Tecnología multicast) SSF Single Stream Forwarding. (Esquema Hawaii) SSID Service Set Identifier. (Tecnología WLAN) SSM Source-Specific Multicast. ST Shared Tree. (Tecnología multicast) TCP Transmission Control Protocol. [RFC 793] TDMA Time Division Multiple Access. TMA TeleMIP Mobility Agent. UDP User Datagram Protocol. [RFC 768] UMTS Universal Mobile Telecommunications System. UNF Unicast Non-Forwarding. (Esquema Hawaii) UTRAN UMTS Radio Access Network. (Tecnología 3G) WLAN Wireless Local Area Networks.

GLOSARIO ‘Agent Advertisement’:

Mensaje utilizado por los Agentes para informar al MN de la red donde se encuentra. Se crea añadiendo extensiones a un mensaje ICMP, [RFC 1256]

Agente de Movilidad Multicast (MMA):

Agente pasarela utilizado en el sistema de micro-mobilidad basado en multicast propuesto.

Árbol Basado en Fuente (SRT):

Método de elaboración del árbol multicast, que parte de la fuente y conecta a todos los miembros del grupo multicast. Técnica utilizada en los protocolos de ‘modo denso’.

Árbol por el camino más corto (SPT):

Algoritmo que obtiene ruta de menor coste desde una fuente a un destino.

Care-of Address Dirección temporal que utiliza el MN cuando se


376

(CoA): encuentra fuera de su HN. El punto de salida del túnel que utiliza el HA para enviar los paquetes dirigidos al MN.

Cellular IP: Sistema de micro-movilidad basado en HBR.

Contexto de Seguridad (SPI):

Asociación compuesta por el mecanismo de seguridad y clave a emplear, que comparten dos elementos del sistema IP móvil.

Encaminamiento Basado en Host (HBR):

Solución empleada en algunos sistemas de micro-movilidad en los que el encaminamiento se realiza consultando en tablas la dirección del Host, en vez de utilizar el encaminamiento clásico de IP basado en redes.

Estación Base (BS): Nodos utilizadas en el sistema de micro-movilidad basado en multicast propuesto. Tienen capacidad de nivel tres y además heredan las tareas de los FA de MIP, así como realizan las tareas propias del protocolo propuesto.

Foreign Agent (HA): Router con un interfaz a una red externa, Foreign Network, donde está situado el nodo móvil en la actualidad.

Foreign Network (FN):

Cualquier otra red diferente a la Home Network y que, por tanto, su identificativo de red difiere del de la red IP del nodo.

Handover Rápido: Proceso de Handover en el que su principal motivación es la entrega de paquetes con retardo mínimo.

Handover Sin Degradación:

Handover en el que no se produce cambio en la capacidad de servicio, seguridad o calidad. En la práctica se aplica a aquellos handovers en las que las aplicaciones o usuarios finales no detectan cambios que afectan a su normal funcionamiento.

Handover Suave: Proceso de Handover en el que el objetivo es minimizar la pérdida de paquetes, sin una preocupación explícita del retardo en la entrega de paquetes.


377

‘Handover Switch Indication’:

Mensaje propuesto para el sistema de micro-movilidad basado en multicast que se utiliza en el esquema de Handover con finalización controlada. Enviado por el MN indica al nBS que puede comenzar a transmitirle paquetes.

Handover: Proceso en el que el nodo móvil cambia de una estación base a otra. En esta tesis, a no ser que se indique lo contrario, se entiende que es un handover de capa 3, que implica un cambio de subred.

HAWAII: Sistema de micro-movilidad basado en HBR.

H.263: Estándar de codificación de video de baja tasa diseñado para videoconferencia y videotelefonía. Utiliza redundancia temporal por lo que envía ‘intraframes’ para que se pueda codificar el movimiento a partir de estas tramas. Los vectores de movimiento indican el movimiento de los macrobloques con respecto a la ‘intraframe’ anterior.

Home Agent (HA): Un router con un interfaz a la red local, Home Network, que mantiene información de la situación actual del nodo móvil.

Home Network (HN): Red en la que el nodo móvil debería estar localizado. Esto es, la red que tiene asignado el mismo identificativo de red que el que existe en la dirección IP del nodo.

IGMP: Protocolo utilizado por los routers multicast para conocer la existencia de miembros de un grupo multicast en las subredes que tiene directamente conectadas.

‘Intra-Doamin Registration Request’:

Mensaje del sistema de micro-movilidad basado en multicast utilizado para realizar un handover dentro del dominio.

‘Join’: Mensaje utilizado en los protocolos multicast empleado para que un nodo (BS) se conecte al árbol multicast.

Latencia del Tiempo necesario para que se realice


378

Handover: completamente el handover. Puede obtenerse como la suma de tres procesos: retardo de la detección de movimiento; de la recuperación de la dirección temporal; y retardo del restablecimiento de ruta.

Mobile IP (MIP): Protocolo de movilidad IP basado en la utilización de una dirección temporal (CoA) cuando el nodo no se encuentra en su HN, [RFC 3344].

‘Multicast Address Extension’ (MAE):

Extensión del mensaje ‘Registration Reply’ utilizado en el sistema de micro-movilidad basado en multicast propuesto. Es utilizada para que el MN recibiera la dirección multicast que le ha sido asignada en ese dominio.

Multicast con Fuente Específica (SSM):

Tecnología multicast novedosa en la que se utiliza concepto de ‘canal’ que está definido por el par ‘fuente’-‘grupo’.

‘Multicast Handover Reply’:

Mensaje propuesto para el sistema de micro-movilidad basado en multicast que se utiliza, opcionalmente, para confirmar un mensaje ‘Multicast Prune Request’.

‘Multicast Prune Request’:

Mensaje propuesto para el sistema de micro-movilidad basado en multicast que se utiliza para informar a la Estación Base antigua que el nodo móvil ha pasado a depender de otra BS.

Nodo Móvil (MN): Nodo que puede cambiar su punto de conexión de una subred a otra, manteniendo cualquier comunicación, y sin cambiar de dirección IP.

Optimización de Ruta:

Mecanismo bajo estudio que permite a los nodos almacenar información de la situación de un nodo móvil (Care-of Address), y que permitirá al host enviar los datagramas, por medio de un túnel, directamente a esta dirección, eliminando el paso de los datagramas por el HA.

PIM-SM: Protocolo para generar el árbol multicast, utilizado en ambientes poco densos (los miembros del grupo están distribuidos por la red), [RFC 2362].


379

‘Registration Reply’: Mensaje transmitido por el HA hacia el MN aceptando o rechazando la petición de registro de la nueva dirección CoA.

‘Registration Request’:

Mensaje utilizado por el MN para informar al HA de la nueva dirección CoA que va a utilizar.

Registro Regional: Esquema de micro-movilidad, basado en niveles, de manera que en cada Dominio existe un Agente Pasarela (GFA), cuya dirección se registrará como CoA en el HA, y que recibirá los registros de las direcciones que va obteniendo el MN dentro del dominio.

Rendezvous Point (RP):

Nodo central del árbol multicast utilizado en protocolos de ‘modo disperso’ como PIM-SM.

Session Initiation Protocol (SIP):

Protocolo de control para la creación, modificación y finalización de sesiones con uno o más participantes, [RFC 2543].

Trigger: Abstracción de una notificación desde la capa 2 que indica que cierto evento ha ocurrido o se va a producir.


380

381

ANEXO 2. DESARROLLO DE LAS ECUACIONES DEL CAPÍTULO 7

A2.1. Desarrollo de la ecuación 7.27

[ ]''')1(0Prob eYXuTkP kper +−<+−<=− (7.27) con: X’ = v.a. con fdd: t

X ettf 23

' 2)( ββ −= para 0≥t y con )1( ρµβ −=

Y’ = v.a. con fdd: t

Y ettf 23

' 2)( ββ −= para 0≥t y con )1( ρµβ −=

),(),(),(),(' 2211 nBSRRCNoBSRRCNe −−+=

La ecuación (7.27) la podemos rescribir de la siguiente manera:

[ ] =−−≤+−=− TkeuXYobP kper )1('''Pr

[ ]∫ −≤−=T

0

1'''Prob oo duT

uzXY (7.27a) con Tkez )1('' −−=

La probabilidad que aparece como parte de la ecuación (7.27a) podemos, a su vez, desarrollarla como sigue:

[ ] [ ]∫∞

+−≤=−≤

0 ' )( ''ProbProb ooXooo dxxfxuzYuz'Y'-X' (7.27b)

La probabilidad de que Y’ sea menor que un valor puede escribirse

por medio de su función de distribución. Sustituyendo, además, )(' xf X , la ecuación anterior nos queda:

Anexo 2. Desarrollo de ecuaciones.

382

[ ] ∫

∞

− =

+−−

+−−=−≤ ∑

)' ,0max(

2

0

)'( *!

)'(1Prob

zou j

jjooxuz

o jxuz

euz'Y'-X' ooββ

oxo dxe

xo

23

2* ββ − (7.27c)

Es interesante observar el limite inferior de la ecuación anterior.

)(' xf X es distinto de cero sólo para valores de xo mayores que cero. Pero, además, a probabilidad [ ]oo xuzY +−≤ ''Prob también es nula si z′-uo+xo es negativo.

Sustituyendo ahora el valor obtenido en (7.27c) en la ecuación (7.27a), tenemos:

∫ ∫∞

−

=

+−−−

+−−= ∑

T

0

)z'-umax(0,

232

0

)'(

o2!

)'(11

ooxo

j

jjooxouz

kper dudxex

jxuz

eT

P oo ββ ββ

(7.27d) Para finalizar, y sólo para facilitar la resolución numérica de la

expresión anterior, podemos realizar un cambio de variable, de manera que logremos integrales definidas. Sustituyendo oxew β−= , owdxdw β−= , y operando, tenemos finalmente:

∫ ∫−

−−−= ∑

=

−−−

T

0

),1min(

0

2

0

)'( *!

))/)(('(11

)'( ouz

o

e

j

jjouz

kper jwLnuz

weT

P

β

βββ

odwduwLn2

)(*2

(7.27e)


383


[ ]ϕϕ +−<+−<−−++=− '')1(''''Prob 12. YYuTkcXdYP clk (7.51) con X’ = v.a. con fdd: t

X ettf 23

' 2)( ββ −= para 0≥t y con )1( ρµβ −=

Y’ = v.a. con fdd: t

Y ettf 23

' 2)( ββ −= para 0≥t y con )1( ρµβ −=

Y’1 = v.a. con fdd: t

Y ettf 23

' 2)(

1

ββ −= para 0≥t y con )1( ρµβ −= Llamando '' cda −+= ϕ la ecuación anterior la podemos rescribir como:

[ ] =−≥−−−≥−=− ϕ12. ')1(''Prob YuTKYaXP clk

[ ] =−≥−−−−≥−−=− ϕuTKYYaYXP clk )1(''''Prob 112. (7.51a)

Podemos simplificar la ecuación anterior definiendo dos nuevas variable aleatorias 1'' YXZ −= , 1''' YYZ −= cuyas fdd se han desarrollado en el punto 2.2.1 de este anexo.

Z , Z’ = v.a. con fdd: ∑ =−

−

+

==

2

02

3||

' )!2(21||

232

)()(j

jj

t

ZZ jtj

etftfβ

ββ

(7.51b)

[ ]=−≥−−−≥−=− ϕuTKZaZP clk )1(Prob '2.

[ ] =≥−+−−≥+−= ∫ =

T

0

' 10)1(Probu

duoT

uoTKZaZ ϕϕ

[ ]∫ ∫∞

+=−+−−≥+−=

TZ duodzozofuoTKzoaZ

T

0

-uo1)T-(k ' )()1(Prob 1

ϕϕϕ


384

[ ] )()1(Prob1 T

0

-uo1)T-(k '∫ ∫

∞

+=−+−−≥=

ϕduodzozofuoaTKzoZ

T Z

∫ ∫∞

+−+−−=

T

0

-uo1)T-(k ' )()))1((-(1 1

ϕduodzozofuoaTKzoF

T ZZ (7.51c)

2.1 Desarrollo de fdd de la v.a Z(t) Para simplificar el desarrollo de la ecuación (7.51) se ha definido una variable aleatoria Z obtenida como resta de dos variables aleatorias X e Y, con función de densidad de distribución idénticas de tipo Erlang. X, Y = v.a. con ffd t

n

YX ent

tftf 1

)!1() (

)()( βββ −

−

−== para 0≥t

Al ser dos funciones positivas e idénticas, la función de densidad de la resta entre ellas la podemos escribir como:

∫∞

+=

0 )()|(|)( τττ dftftf YXZ

con:

)| (|1

)!1() |(|

)|(| τβτβτ +−

−

−+

=+ tn

nX e

nt

tf

βττβτ −−

−= e

nf

nn

Y )!1()(

1

[ ] ∫∞ −−−− +

−=

0

211||2

)|(|)!1(

)( τττβ τββ deten

tf nntn

Z (7.51d)

Para simplificar la ecuación anterior definimos una nueva integral Ik como:

1

0

2

)2(!+

∞ − == ∫ kk

kkdeIβ

ττ τβ (7.51e)


385

Parte del integrando de la ecuación (7.51d) puede desarrollarse según el binomio de Newton:

∑ −

=−−−−− =

=+ −1

01111 ||)|(| 1n

jjnjnnn tt

jn ττττ

∑ −

=−−−+

= −1

011 ||1n

jjnnj t

jn τ (7.51f)

Sustituyendo (7.51f) en la ecuación de la función de densidad de distribución tenemos:

[ ] ∫ ∑∞ −−−−+−

=−

−= −

0

2111

0||

2||

)!1()( 1 ττβ τββ dete

ntf jnnjn

jt

n

Z jn (7.51g)

Ahora podemos utilizar la definición de Ik de la ecuación (7.51e) de manera que nos queda:

[ ] =

−= −+

−−−

=− ∑ −

111

0||

2||

)!1()( 1

njjnn

jt

n

Z Iten

tfj

nββ

[ ] =

+−

−= +

−−−

=− ∑ −

njjnn

jt

n jnten j

n

ββ β

2)!1(| |

)!1(11

0||

2 1 [ ] )!1(||

)!1( 2

11

211

0

||jnt

ne j

jnn

j

nt

jn +−

−= −−−

=

−

∑ −

β

ββ (7.51h)

Puede comprobarse como haciendo n=1, es decir, con X e Y v.a con fdd exponencial, la v.a Z, resta de las dos, tiene una fdd que sigue una distribución de Laplace [ABRA72].


386


[ ]uTkYYP clk +−<+−=− )1(''Prob 13. ϕ (7.57) con: Y1’ = v.a. con fdd: t

Y ettf 23

' 2)(

1

ββ −= para 0≥t y con )1( ρµβ −= Y’ = v.a. con fdd: t

Y ettf 23

' 2)( ββ −= para 0≥t y con )1( ρµβ −=

La ecuación (7.57) la podemos rescribir de la siguiente manera:

[ ]∫ +≤−=−

T

0 13.

1''Prob ooclk duT

uzYYP (7.57a) con ϕ−−= Tkz )1(

La probabilidad que aparece como parte de la ecuación (7.57a) podemos, a su vez, desarrollarla como sigue:

[ ] [ ]∫∞

++≤=+≤

0 '1 )( 'ProbProb

1 ooYooo dyyfyuzYuz'Y'-Y (7.57b)

La probabilidad de que Y’ sea menor que un valor puede escribirse por medio de su función de distribución. Sustituyendo, además, )('1

yfY , la ecuación anterior nos queda:

[ ] ∫∞

−

−

=

++−

++−=+≤ ∑

)- ,0max(

y 232

0

)(1 2!

)(1Prob

zouo

o

j

jjooyuz

o dyey

jyuz

euz'Y'-Y ooo ββ ββ

(7.57c)


387

Es interesante observar el limite inferior de la ecuación anterior. )('1yfY es distinto de cero sólo para valores de yo mayores que cero. Pero,

además, a probabilidad [ ]oo yuzY ++≤'Prob también es nula si z+uo+yo es negativo.

Sustituyendo ahora el valor obtenido en (7.57c) en la ecuación (7.57a), tenemos:

∫ ∫∞

−

=

+−−−

+−−= ∑

T

0

z)-max(0,-u

y 232

0

)(3.

o2!

)(11

ooo

j

jjooyouz

clk dudyey

jyuz

eT

P oo ββ ββ

(7.57d)

A.2.4. Desarrollo de la ecuación 7.59 A continuación vamos a desarrollar el primer término de la ecuación 7.59, que se muestra a continuación.

[ ]ukTtuTk +<<+− 6)1(Prob (7.59a) Utilizando las ecuaciones (7.39), (7.38), y (7.23) podemos sustituir el valor de 6t , de manera que la ecuación anterior queda:

[ ]ukTeXYuTk +<−+−<+− ''')1(Prob ϕ (7.59b)) con: X’, Y’ = v.a. con fdd: t

YX ettftf 23

'' 2)()( ββ −== para 0≥t y con )1( ρµβ −=

),(),(),(),(' 2211 nBSRRCNoBSRRCNe −−+=

La ecuación (7.59b) la podemos rescribir de la siguiente manera:


388

[ ] [ ]∫ ≤+−−=<+−−<

T

0

1''Prob''0(Prob oo duT

TauXYTauXY (7.59c)

con Tkea )1(' −−−= ϕ Fijando ahora la v.a X’ :

[ ]∫ ∫ ≤+−−=∞T

0 '

0 )( 'Prob1

oooXoo dudxxfTauxYT

(7.59d) A continuación desarrollamos la probabilidad que aparece en la ecuación anterior, denominando auxb oo −+= :

[ ] =<−< TbY '0(Prob

[ ] =+<<= bTYb 'Prob

[ ] [ ] =<+<= bYbTY 'Prob-'Prob

)()( '' bFbTF YY −+= (7.59e) Finalmente sustituimos (7.59e) en (7.59d), de manera que la probabilidad queda:

∫ ∫∞

−++−+−++−+T

0

0 ''' )( ))1('()'(1

oooXooYooY dudxxfTkeuxFkTeuxFT

ϕϕ (7.59f)

TESIS DOCTORAL ESPECIFICACIÓN Y EVALUACIÓN …personales.upv.es/aleon/pubs/aleon_tesis.pdf4.2...

Documents

Transcript of TESIS DOCTORAL ESPECIFICACIÓN Y EVALUACIÓN …personales.upv.es/aleon/pubs/aleon_tesis.pdf4.2...