Aleon Tesis

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.

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 59
APLICACIÓN
i
Índice de la Memoria
2.8 RESUMEN DEL CAPÍTULO 61
3. PROPUESTA DE SISTEMA DE 65
MICROMOVILIDAD BASADO EN MULTICAST
3.2 ARQUITECTURA 67
3.3 PROTOCOLO DE MICRO-MOVILIDAD BASADO EN 70
MULTICAST
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 86
SISTEMA DE MICROMOVILIDAD PRESENTADO
3.4.1 Introducción a la seguridad en entornos 86
móviles
3.4.2 Seguridad en el Sistema de Micro-movilidad 87
Multicast
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 102
TRANSMISIÓN MULTICAST EN EL SISTEMA DE
MICROMOVILIDAD
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 108
sistema de micro-movilidad
3.7 TABLA COMPARATIVA CON OTRAS PROPUESTAS 112
DE MICRO-MOVILIDAD
3.8 CONCLUSIONES DEL CAPÍTULO 114
ii
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 123
temporal, Care-of Address
4.2.3 Retardo de reestablecimiento de la ruta 125
4.3 COOPERACIÓN DE LA CAPA 2 DURANTE EL 126
HANDOVER
4.4 SOLUCIONES EXISTENTES DE HANDOVER EN 130
SISTEMAS DE MOVILIDAD IP
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 151

MÓVILES

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 157
DEL PROTOCOLO ‘MOBILE IP’
5.3 ESTUDIO DEL HANDOVER CERCANO DEL 158
PROTOCOLO MOBILE IP
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 174
PROTOCOLO ‘MOBILE IP’
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
iii
5.5 ESTUDIO DE PRESTACIONES DE LOS SISTEMAS 194

DE MICRO - MOVILIDAD
5.5.1 Estudio del tráfico UDP en Sistemas de Micro- 196
Movilidad
5.5.2 Estudio del tráfico TCP en Sistemas de Micro- 200
Movilidad
5.5.3 Conclusiones sobre los sistemas de micro- 203
movilidad
5.6 IMPLEMENTACIÓN DE UN BANCO DE PRUEBAS 204
DEL PROTOCOLO MOBILE IP
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 212
calidad
5.6.4 Prueba subjetiva sobre el efecto del handover 215
5.6.5 Conclusiones de la implementación del banco 218
de pruebas
6. ESPECIFICACIÓN DE MECANISMOS DE 221

HANDOVER INTRA-DOMINIO PARA UN
SISTEMA DE MICRO-MOVILIDAD BASADO EN
MULTICAST

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 232
Suave
6.5 ESQUEMA DE HANDOVER SUAVE CON 235
FINALIZACIÓN CONTROLADA
6.5.1 Formato del mensaje ‘Handover Switch 238
Indication’
6.5.2 Coexistencia de los esquemas de handover 240
6.6 ESQUEMA DE HANDOVER CON 242
REDIRECCIONAMIENTO
iv
6.6.1 Solución a los problemas del esquema 244

6.6.2 Formato de los mensajes utilizados en este 248
esquema
6.7 ESQUEMA DE HANDOVER INDIRECTO CON PRE- 252
REGISTRO
6.8 RESUMEN Y CONCLUSIONES DE LOS ESQUEMAS 255
DE HANDOVER PROPUESTOS
7. EVALUACIÓN ANALÍTICA DE LOS MECANISMOS 263

DE HANDOVER INTRA-DOMINIO

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 273
desconexión de oBS
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.3 Paquetes duplicados sin desconexión de oBS 285
7.3.4 Paquetes duplicados con desconexión de oBS 288
7.3.5 Conclusiones del handover Semi Suave 293
7.4 ESQUEMA SUAVE CON FINALIZACION 295
CONTROLADA
7.4.1 Análisis de los paquetes perdidos 296
7.4.2 Análisis del retardo de los paquetes entregados 302
v
vía nBS
7.4.3 Análisis de la limitación del mecanismo de 315
handover con Finalización Controlada
7.4.4 Conclusiones 319
7.5 ESQUEMA DE HANDOVER CON 321
REDIRECCIONAMIENTO
7.5.3 Consideraciones finales sobre el Handover con 330
Redireccionamiento
7.5.3.1 Posible duplicación de paquetes 331
7.6 ESQUEMA DE HANDOVER INDIRECTO CON PRE- 333

REGISTRO
7.6.1.1 Paquetes perdidos 336
7.6.1.2 Paquetes duplicados 339
7.6.3 Conclusiones 345
7.7 CONCLUSIONES DEL CAPÍTULO 346
8. CONCLUSIONES Y LÍNEAS FUTURAS DE 351

INVESTIGACIÓN
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
vi
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
1
Introducción y Objetivos
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
2
Introducción Objetivos
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 naturalezabest

‘
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
3
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.
4
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.
5
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
6
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
7
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
8
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
9
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.
10
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
11
Sistemas de Movilidad en redes IP
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:
12
Sistemas de movilidad en redes IP
• 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.
13
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.
Directorio de
Localización
Home Network
Agente de
traducción de
direcciones Nodo móvil en
una Foreign
f Network
Fuente g
Foreign Network
Agente de Envío
f: Home Address → Forwarding Address

g: Forwarding Address → Home Address
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
14
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
15
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].
16
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.
17
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
18
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).
19
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
20
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.
21
• 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.
22
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.
Nodo móvil en
una Foreign
Network Foreign Agent Nodo móvil
“at Home”
Home Agent
Foreign Network
Home Network
Foreign Network Foreign Agent
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].
23
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.
Fuente = Punto de entrada del túnel

Destino = Punto de salida del túnel
Fuente = Fuente original
Destino = Último destino
Cabecera Cabec. Payload

exterior
Modo móvil Foreign Agent Home Agent
Figura 2.3 Túnel IP
24
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.
25
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
26
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.
27
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
28
enviará una respuesta indicando el resultado de la solicitud. En caso de no

recibir respuesta el nodo retransmitirá la solicitud.
Registro Descubrimiento
de agente
UDP [RFC768] ICMP [RFC792]

Internet Protocol [RFC791]
Figura 2.4 Utilización de UDP como protocolo de Transporte
Nodo móvil en una

Foreign Network
1 Registration Request 2
Home
Agent
Foreign Network
Foreign
Agent
3
4 Registration Reply
Registration Request
Home Agent
Foreign Network
Registration Reply
Figura 2.5 Escenarios de Registro
29
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.
30
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
31
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.
Nodo móvil con

Foreign Agent Host
Care-of Address
Foreign Agent
Router
Nodo móvil con
Co-located Care- Home Agent
of Address
Paquetes originales
Paquetes en túnel
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).
32
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
33
(‘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
34
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.
35
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.
Nodo móvil en
una Foreign Foreign Agent Home
Network Agent
Foreign Network
Host a Nodo Móvil

Nodo Móvil a Host Host
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,
36
[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,
37
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.
38
• 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.
39
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
40
el GFA, mediante un Registro Regional, para que este pueda redirigir los
paquetes recibidos desde el Home Agent hasta el nodo.
Reg. Req.
Foreign Home
Agent Agent
Reg. Req.
DOMINIO
GFA
Reg. Req. Reg. Reply Reg. Reply

Foreign
Agent
Reg. Reply
GFA: Gateway Foreign Agent
Nodo móvil en
una Foreign
Network
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.
41
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).
Regional Registration Regional Registration

Request Request
GFA
Nodo móvil en Gateway
una Foreign Foreign
Network Agent
Foreign
Regional Registration Agent
Reply Regional Registration
Reply
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].
42
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
43
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.
44
Home Agent
Estación Estación
Base A Base B
MA
Estación
Host Fuente Base C
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
45
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.
46
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.
47
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.
48
TMA
Subred 2
TMA
FA FA
Subred 1
Nodo
Móvil
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.
49
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
50
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,
51
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
52
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.
53
• 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).
54
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
55
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
56
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
Mobile Node en Foreign Agent

una Foreign
Home Agent
Network
Foreign Network
Binding Update
Paquetes de datos Host
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.
57
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.
58
• 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
59
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.
60
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
61
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.
62
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.
63
64
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.
65
Sistema de micro-movilidad basado en multicast.
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
66
Sistema de micro-movilidad basado en multicast
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
67
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.
MMA
Router
Router Multicast
Multicast
Subred 3
BS
Subred 1 BS
BS
Nodo
Subred 2 Móvil
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.
68
BS
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
69
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
70
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.
71
• 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.
Transmisión
Home Agent multicast
Host Fuente
Subred 1
MMA
Subred 2
Dominio
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.
72
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
73
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.
74
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.
MN BS MMA HA
Reg. Req. con extensiones
Registration Reply
Reg. Reply con extensiones
Registration Reply
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
75
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.
76
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.
77
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
78
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.
Agente de Movilidad
Multicast (MMA)
Router
Estación Base (BS)
Nodo móvil (MN)

2 3
(1) Intra-Domanin Registration Request

(2) Multicast Join
1 (3) Multicast Ack Join
4
(4) Intra-Domain Registration Reply
Figura 3.5 Handover Intra-dominio.
79
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
80
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.
81
M.H
H.A (2) (4)
Host (3)
BS
(1) Subred
MMA
(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.
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
82
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.
83
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
28
dominio. El direccionamiento IP dispone de 2 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.
84
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
85
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.
86
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
87
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.
MN BS MMA HA
(1)
(2)
(3)
(4)
(5)
(6)
(1) Reg.Request Ext. Aut. MN-HA
(2) Reg.Request Ext. Aut. MN-HA Base Station. NAI Ext. Aut. FA-FA
(3) Reg.Request Ext. Aut. MN-HA
(4) Reg.Reply Ext. Aut. MN-HA
(5) Reg.Reply Ext. Aut. MN-HA MAE Ext. Aut. FA-FA
(6) Reg.Reply Ext. Aut. MN-HA MAE Ext. Aut. MN-FA
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
88
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.
(3) Reg.Request Ext. Aut. MN-HA MAE Ext. Aut. FA-HA
(4) Reg.Reply MAE Ext. Aut. MN-HA Ext. Aut. FA-HA
(5) Reg.Reply MAE Ext. Aut. MN-HA Ext. Aut. FA-FA
(6) Reg.Reply MAE Ext. Aut. MN-HA
Figura 3.8 Modificaciones propuestas al proceso de registro.
89
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
90
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.
Local Domain Home Domain
AAAL AAAH
MN: Nodo Móvil

FA: Foreign Agent
FA AAAL: Autoridad Local
MN AAAH: Autoridad del nodo
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.
91
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
92
comunicándose con las demás Estaciones Base de una forma

autentificada.
MN BS MMA HA
(1)
(2)
(3)
(4)
(5)
(6)
(4) Reg.Reply Key M. MN-FA Ext. MN-HA Key Mat. MN-FA Ext. FA-HA
(5) Reg.Reply Key M. MN-FA Ext. MN-HA MAE Key M. MN-FA FA-FA
(6) Reg.Reply Key M. MN-FA Ext. MN-HA MAE Ext. MN-FA
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.
93
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’.
94
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].
95
3.5.2 Mensajes en el registro en un nuevo Dominio
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
96
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.
97
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.
98
• 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.
99
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 DMG 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’.
100
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.
101
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
102
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
103
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
104
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.
105
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
106
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.
107
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'.
108
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].
109
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.
110
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
111
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
112
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].
Sistema basado
MIP-RR Cellular IP
en Multicast.
Direccionamien Utilización de Encaminamiento Encapsulación en
to de los túneles, de basado en la paquetes
paquetes en manera dirección multicast.
sentido secuencial. permanente del
descendente MN.
Actualización MIP + extensiones Mensaje de Mensajes
de rutas de registro actualización multicast Join y
regional. especiales AckJoin.
Nodos del Routers Nodos especiales Routers con
Dominio Cellular IP. capacidad
multicast.
Capacidades Sí, capacidad de Sí, soporte Sí, MIP +
avanzadas del registro regional. completo de capacidad de
MN Cellular IP. registro
intradominio.
Seguridad Sí. Según MIP, Sí. Los paquetes Sí, los paquetes de
con extensiones de actualización registro van
de MIP_RO. de rutas van autenticados.
autenticados.
Definición Sí No Sí
formal de
paquetes
Gestión del Igual que MIP. Handover abrupto 5 posibles
Handover y semisuave. esquemas.
Escalabilidad Utilización de No, el Gateway Sí, múltiples
varios niveles de soporta todo el MMAs.
jerarquía. tráfico.
Tabla 1. Comparación de sistemas de micro-movilidad.
113
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
114
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.
115
116
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.
117
Proceso de Handover en redes IP
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.
118
• 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.
119
• 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
120
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.
121
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
122
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.
123
• 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
124
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
125
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.
126
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
127
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.
128
L2 Trigger Evento Receptor Parámetros
nFA -> Dirección L2

del MN
Link Up Se ha establecido en MN
(L2-LU) enlace L2 nFA MN -> Dirección del
nFA.
Link Down Se ha desmantelado

oFA Dirección L2 del MN
(L2-LD) un enlace L2
Dirección L2 del nFA

que puede ser
Source Trigger Va a producirse un traducida a una
handover L2 oFA
(L2-ST) dirección IP .
Dirección L2 del MN
Dirección L2 del oFA

que puede ser
Target Trigger Va a producirse un traducida a una
handover L2 nFA
(L2-TT) dirección IP.
Dirección L2 del MN
Dirección L2 del nFA

Mobile Trigger Va a producirse un que puede ser
handover L2 MN traducida a una
(L2-MT)
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.
129
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.
130
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.
131
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’.
132
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
133
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
134
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’).
135
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.
MN oFA nFA HA
L2 Trigger
Proxy Agent Solicitation
Proxy Agent
Advertisement Registration Request
Registration Reply
Registration Reply
Figura 4.1 Proceso de handover iniciado por el MN.
136
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
137
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].
138
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
139
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.
Macro-Movilidad
Router Raíz (RR)
Dominio Router
HBR
Estación Base (BS)
X Nodo móvil (MN)
BS1 BS2
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.
140
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
141
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.
MN oBS nBS Router Cruce
Datos
Beacon
Paquete Actualización Ruta, S=1
Datos (Copia)
Datos
Paquete Actualización Ruta, S=0
Datos
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
142
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
143
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
144
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
145
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.
146
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).
147
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
148
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.
149
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.
150
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
151
Prestaciones del Handover en redes IP móviles
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
152
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).
153
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.
154
• 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,
155
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.
156
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
157
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
158
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.
Host
5
Mbps
5 5
Mbps Router Mbps
Home Agent Foreign Agent
IEEE 802.11b
Nodo Móvil
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.
159
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.
160
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.
MN FA HA
Paquete vía HA
Agent Advertisement
Tiempo Medido
Registration Request Registration Request
Registration Reply
Registration Reply
Paquete vía FA
Figura 5.3 Handover L3 empleado.
161
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
162
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.
163
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.
164
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.
Router
V m/s 250 m
Home Agent Foreign Agent
Zona de
solape 20m
Figura 5.6 Movimiento del Nodo Móvil entre las dos celdas.
165
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
166
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.
167
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.
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
168
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
169
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
170
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
171
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
172
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.
173
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
174
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.
Home Agent Host
Retardo 5 Mbps
variable 20ms
Router
5 Mbps 5 Mbps
2 ms 2 ms
Foreign Agent 1 Foreign Agent 2
Nodo Móvil
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
175
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.
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
176
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 Tiempo medio de

Agent 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.
177
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.
178
Figura 5.15 Eventos en un Handover lejano con tasa 800Kbps y distintos retardos.
179
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.
180
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.
181
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
182
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
183
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
184
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.
185
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
186
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.
187
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
188
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.
189
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
190
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.
191
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
192
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
193
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
194
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.
195
CH W0
5 Mbps W1 W2
2 ms
W3 W4 W5
AP1 AP2 AP3 AP4
IEEE 802.11b
Nodo Móvil
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.
196
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.
2
1,8
Hard
1,6
SemiSoft
1,4
Paquetes Perdidos
1,2
1
0,8
0,6
0,4
0,2 0 0 0
0
1 2 3
Distancia al nodo de cruce
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
197
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
198
5.31, y como en anteriores ocasiones está realizada a partir de 100

simulaciones independientes.
2,5
Cellular IP Hard
Hawaii UNF
2 MIPHH
MIP RR
Paquetes perdidos
1,5
0,5
0
1 2 3
Distancia al nodo de cruce
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
199
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.
Handover FA3-
FA4
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
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
200
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.
201
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
202
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.
203
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.
204
Transmisor CN
IP: 20.0.0.1/24
IP: 20.0.0.254/24
IP: 30.0.0.254/24 IP: 40.0.0.254/24
IP: 30.0.0.2/24 IP: 40.0.0.5/24; CoA

Foreign
Home Agent Agent
IP: 50.0.0.3/24 IP: 60.0.0.7/24
IP: 50.0.0.4/24
Nodo Móvil
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.
205
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.
206
HA HA
1 seg.
FA FA FA
1 seg.
Inicio del Registro con el

1 2 FA
Instante de handover
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.
207
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.
208
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.
209
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.
210
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.
211
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.
212
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.
213
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.
214
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.
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
Figura 5.47 Test para la evaluación subjetiva.
215
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.
16
14
Sí
12
No
Observadores
10
8
6
4
2
0
Video MJPEG Videoconferencia
Figura 5.48. Pregunta 1. ¿Es capaz de apreciar algún efecto cuando visiona el
vídeo?
1 0 1 2
3
Despreciable
Apreciable
6
Molesto
Muy molesto 6
11
Vídeo MJPEG Videoconferencia
Figura 5.49. Pregunta 2. ¿Cómo evaluaría el efecto percibido?
216
14
Sí
12
No
10 No estoy seguro
Observadores
0
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 12 Se aprecia un corte en la 14

película. película
Se aprecia un corte de x 6 Se aprecia un corte de x 6
seg. seg.
No aprecio nada 3 El corte del audio es más 3
perceptible que el de vídeo
Falta de sincronización 2
entre voz e imagen
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
217
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].
218
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.
219
220
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.
221
Mecanismos de Handover para el sistema basado en multicast
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-
222
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.
223
• 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.
224
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
225
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.
MN oBS nBS Nodo

Cruce
Datos en Multicast
Datos
Beacon
Intra-Domain Registration
Request
Join
ACK Join
Intra-Domain Registration
Reply
Datos en Multicast
Datos
Multicast Prune Request

Leave Group
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
226
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.
227
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.
228
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].
229
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
230
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’).
MN oBS nBS Nodo

Cruce
Datos en Multicast
Datos
Beacon
Intra-Domanin Registration
Request
Join
ACK Join
Reply
Datos en Multicast
Datos
Multicast Prune
Request
Leave Group
Figura 6.4. Esquema del proceso de Handover Semi Suave.
231
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,
232
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.
(a) (b)
Nodo de Nodo de
Cruce Cruce
5
7 7
4 6
3 5
2 oBS nBS 4 oBS nBS
1
3
MN MN
(c) (d)
Nodo de Nodo de
Cruce Cruce
8 8 11
7 10
6 9
5 oBS nBS oBS nBS
MPR 8
4 7
MN MN
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
233
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.
Nodo de
11 Cruce
10
9
8
7
6
4 11
oBS
nBS
3
MN
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.
234
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
235
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.
MN oBS nBS Nodo

Cruce
Datos en Multicast
Datos
Beacon
Request
Join
Intra-Domain Registration ACK Join

Reply
Datos en Multicast
Datos
Futura pérdida de
conexión con oBS
Multicast Prune
Request Leave Group
Handover Switch
Indication
Datos
Almacenados
Datos en Multicast
Datos
Figura 6.7 Esquema del proceso de Handover Suave con Finalización Controlada.
236
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
237
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.
(c) (d)
Nodo de Nodo de
Cruce Cruce
10 10 Prune 11
9 9 10
8 8 9
7 oBS nBS 7 oBS nBS 8
HSI (6)
MPR 7
6
MN MN
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
238
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
239
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.
240
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.
241
6.6 ESQUEMA DE HANDOVER CON

REDIRECCIONAMIENTO
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.
242
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
MN oBS nBS Nodo

Cruce
Datos en Multicast
Datos
Beacon
Request
Join
ACK Join
Leave Group
Multicast Handover Reply
Datos almacenados
Reply
Datos reencaminados
Datos en Multicast
Datos
Figura 6.11. Esquema del proceso de Handover con Redireccionamiento.
243
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
244
paquete 9 ya lo ha recibido nBS por el árbol multicast, por lo que el nodo

móvil acabaría recibiéndolo por duplicado.
Nodo de
Cruce
10 10
9 MPR 9
8
7
oBS nBS
MN
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
245
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.
Nodo de
Cruce
Paquetes recibidos y no
transmitidos
9 MPR
8
7
6
5 oBS nBS
Paquetes ya transmitidos
pero almacenados MN
temporalmente 7
6
5
Paquetes recibidos por el
nodo móvil
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
246
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.
Nodo de
Cruce
10
9
8
7
oBS nBS
9
MN
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
247
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.
248
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.
249
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
250
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
251
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.
6.7 ESQUEMA DE HANDOVER INDIRECTO CON PRE-

REGISTRO
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
252
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.
253
MN oBS nBS Nodo

Cruce
Datos en Multicast
Datos
TriggerL2-MT
Proxy Agent
Solicitation
Proxy Agent
Advertisement
Request
Join
ACK Join
TriggerL2-LU
Reply

Leave Group
Datos en Multicast
Datos
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).
254
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.
255
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
256
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
257
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.
Nodo de Nodo de
Cruce Cruce
3 Ack Join 3 Ack Join

6 Leave 6 Leave
Group Group
2 Join 2 Join
5 MPRq
oBS nBS oBS 4 IDRRp nBS

1 IDRRq
4 IDRRp 1 IDRRq
5 MPRq
MN MN
(a) Handover Abrupto (b) Handover Semi Suave
Nodo de Nodo de
Cruce Cruce
3 Ack Join 3 Ack Join

6 Leave 6 Leave
Group Group
2 Join 5 MPRq 2 Join
7 MHRp
oBS 4 IDRRp nBS oBS nBS
1 IDRRq 1 IDRRq
4 IDRRp
5 MPRq 7 HSI
MN MN
(c) Handover Suave con Finalización Controlada (d) Handover con Redireccionamiento
258
Nodo de
Cruce
IDRRq: ‘Intra Domain Registration Request’
5 Ack Join IDRRp: ‘Intra Domain Registration Reply’
8 Leave MPRq: ‘Multicast Prune Request’
Group
4 Join
HSI: ‘Handover Switch Indication’
MHRp: ‘Multicast Handover Reply’
7 MPRq
PAS: ‘Proxy Agent Solicitation’
PAA: ‘Proxy Agent Advertisement’
oBS 3 IDRRq nBS
1 PAS 6 IDRRp
2 PAA
MN
(d) Handover con Pre-registro
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.
259
Comunicación
Mecanismo de Handover Handover Mensajes
simultanea
Handover Suave Rápido utilizados
con las 2 BS.
IDDRq con
extensión
Abrupto No No Si IDDRp
MPRq opcional
IDDRq
Si con IDDRp
Semi Suave Si Si
limitaciones
MPRq
IDDRq
IDDRp
Suave con MPRq
finalización Si Si No
controlda HSI
Exten. de Agent
Adv.
IDDRq con
extensión
IDDRp
Con
No Si No
Redireccionamiento MPRq con
extensión
MHRp opcional
IDDRq con
extensión
IDDRp
Con Pre-registro No No Si
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.
260
Mecanismo de
Ventajas Inconvenientes
Handover
Sencillo
Rápido Se pierden paquetes
Abrupto
Buenas prestaciones al Tiempo de interrupción
basarse en multicast.
Sencillo
Rápido
En situaciones especiales se
Semi Suave En muchas situaciones pierden o duplican paquetes
no se pierden paquetes
(suave)
Complejo
Necesario comunicación
Suave con Handover suave sin
entre BS
finalización controlda pérdida de paquetes
Retardo en paquetes
almacenados.
Complejo
Necesario comunicación
Con Handover suave sin
entre BS
Redireccionamiento pérdida de paquetes
Retardo elevado en paquetes
almacenados.
Handover sencillo Necesidad de comunicación

Con Pre-registro entre capas (triggers)
Rápido
Tabla 6.2 Ventajas e Inconvenientes de los diferentes esquemas de Handover.
261
262
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 R A 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 (R X , RY ) . 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
263
Evaluación analítica.
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.
a) Nodo de b) Nodo de
Cruce CN Cruce CN
R2 R2
R1 R1
R3
oBS nBS
oBS nBS
MN MN
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 t ho 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 t1 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
264
Evaluación analítica
nodo móvil después del instante t ho . Por último definimos t 2 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 t1 como sigue:
t1 = t ho − [CN + (CN , R1 ) + R1 + ( R1 , oBS ) + oBS ] (7.1)
En la ecuación anterior el valor t1 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:
t1 = t ho − [X + c ] (7.2)
siendo c = (CN , R1 ) + ( R1 , oBS ) una constante y X una variable aleatoria con

función de densidad de distribución f X (t ) , 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.
β 3t 2
f X (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
2
Del mismo modo podemos describir t 2 como sigue:
t 2 = t ho + ∆h + nBS + (nBS , R2 ) + R2 + ( R2 , CN ) (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
265
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 t1 :
t 2 = t ho + ∆h + Y + d (7.4)
con
d = (nBS , R2 ) + ( R2 , CN )
f Y (t ) = β 2 te − β t para t ≥ 0 y con β = µ (1 − ρ )
Con el fin facilitar el desarrollo analítico podemos, sin perder

generalidad, asignar a t1 el valor 0:
t1 = t ho − [X + c ] = 0 ⇒ t ho = X + c (7.5)
Así el valor t 2 quedaría, tras sustituir (7.5) en (7.4) y simplificar:
t 2 = ∆h + Z + e (7.6)
con:
e=c+d
β 5t 4
f Z (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ ) (7.7)
4!
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 t1 = 0 , 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].
266
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 Pper − k . Esta
probabilidad es igual a la probabilidad de que el instante de tiempo en el
que llega el paquete sea mayor que t1 y menor que t 2 :
Pper −k = Prob[t1 < (k − 1)T + u < t 2 ] =
= Prob[0 < (k − 1)T + u < ∆h + Z + e] =
= Prob[Z > (k − 1)T + u − ∆h − e] =
= 1 − Prob[Z ≤ (k − 1)T + u − ∆h − e] (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, W = u − ∆h . En el caso de T < ∆ho esta nueva v.a. tiene la
función de densidad de distribución siguiente:
(t + ∆ho ) T∆ho − ∆ho < t < − ∆ho + T

 1 ∆ho − ∆ho + T ≤ t ≤ 0 (7.9)

f w (t ) = 
 ( − t + T ) T∆ho 0<t <T
 0 resto
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:
Pper − k = 1 −
∫ Prob[Z ≤ (k − 1)T − e + W W = wo] f w ( wo ) dwo (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 f w (t ) 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 (k − 1)T − e > ∆ho ⇒ límite inferior = - ∆ho

Si (k − 1)T − e ≤ ∆ho ⇒ límite inferior = e-(k-1)T
267
Es decir:
[ ]
T
Pper − k = 1 − ∫ max [− ∆ho, e − ( k −1)T ]
Pr ob Z ≤ (k − 1)T − e + W W = wo f w ( wo) dwo
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 Fz (t ) . A partir de (7.7)
hemos obtenido dicha función:
4
(t β ) n
Fz (t ) = 1 − e − β t ∑
n =0
n!
(7.11)
Por tanto, la probabilidad de que el paquete k-ésimo se pierda

puede representarse finalmente como:
T
Pper − k = 1 − ∫ max [− ∆ho , e − ( k −1)T ]
Fz ((k − 1)T − e + W W = wo) f w ( wo) dwo (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 ∆ho = 100
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.
268
Figura 7.2 Probabilidad de pérdida del paquete k-ésimo.
269
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).
Qk = Pper k (1 − Pper k +1 ) (7.13)
N= ∑ kQ
k ≥1
k (7.14)
270
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.
271
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
272
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:
273
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 t1 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.
t1 = t AB − [CN + (CN , R1 ) + R1 + ( R1 , oBS ) + oBS ] (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 t AB , 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 t m , y del tiempo que necesita en atravesar dicha zona σ.
σ
t AB = t m + (7.16)
2
Simplificando (7.15) tendríamos:
t1 = t AB − [X + c ] (7.17)
siendo
c = (CN , R1 ) + ( R1 , oBS )
β 3t 2
X = v.a con fdd: f X (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
2
Con respecto a la segunda condición, ésta también se daba en el

handover abrupto (punto 7.2). Definimos t 2 como el instante de tiempo en
274
el que el nodo de cruce recibe, vía nBS, la información de que se ha

producido un handover.
t 2 = t m + ∆h + nBS + (nBS , R2 ) + R2 + ( R2 , CN ) (7.18)
En la ecuación anterior ∆h se corresponde con el tiempo, tras el

instante t m , 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:
t 2 = t m + ∆h + Y + d (7.19)
con
d = (nBS , R2 ) + ( R2 , CN )
Y = v.a con fdd: f Y (t ) = β 2 te − β t para t ≥ 0 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).
Pper − k = Pr ob[t1 < (k − 1)T + u < t 2 ] (7.20)
Idealmente t 2 < t1 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
275
t1 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
Pper − k = 1 − ∫ max [− ∆ho ,e −( k −1)T ]
Fz ((k − 1)T − e + W W = wo) f w ( wo) dwo (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 t m :
σ
e = (CN , R1 ) + ( R1 , oBS ) + (nBS , R2 ) + ( R2 , CN ) − (7.22)
2
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
276
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.
277
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
278
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.
Para realizar este análisis partimos de los cálculos realizados a

principio de este punto. Definimos t 3 como el instante de tiempo en el que
el nodo móvil recibe el mensaje ‘Intra-Domain Registration Reply’ desde
nBS.
t 3 = t 2 + CN + (CN , R 2 ) + R 2 + ( R 2 , nBS ) + nBS =
= t 2 + Y '+ d ' (7.23)
siendo:
d ' = (CN , R2 ) + ( R2 , nBS )
β 3t 2
Y’ = v.a. con fdd: f Y ' (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
2
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 t 3 :
t 4 = t 3 − [CN + (CN , R1 ) + R1 + ( R1 , oBS ) + oBS ]
t 4 = t 3 − [X '+ c'] (7.24)
siendo:
c' = (CN , R1 ) + ( R1 , oBS )
β 3t 2
X’ = v.a con fdd: f X ' (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
2
279
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 t 4 pero antes de t 2 .
Pper − k = Pr ob[t 4 < (k − 1)T + u < t 2 ] (7.25)
Como en cálculos anteriores normalizamos con uno de los tiempos

implicados en el análisis. En este caso igualamos t 4 =0, de manera que el
primer paquete susceptible de pérdida será el que llega en el instante u.
t 4 = t 3 − [X '+ c'] = t 2 + Y '+ d '−[X '+c'] = 0 ⇒ t 2 = X '−Y '+ c'− d ' (7.26)
Pper − k = Pr ob[0 < (k − 1)T + u < X '−Y '+e'] (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 ∞ 3 2
Pper − k =
1
T
[Fy ( z'−u o + xo )] β 2xo e − β xo dx o du o (7.28)
0 max(0,u o - z')
siendo
z ' = e'−(k − 1)T = (CN , R1 ) + ( R1 , oBS ) − (CN , R2 ) − ( R2 , nBS ) − (k − 1)T
280
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 k = 1 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
281
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

CNoBS y CNnBS.
282
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
283
fdd f X ' (t ) , que equivalía a los routers de la ruta CNoBS, 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 CNnBS con valor ρ = 0.8 y
variar la carga del enlace CNoBS 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.
284
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.
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:
t 2 < t < t1 .
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, t 2 = 0 . Así el primer paquete que
285
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 Pdup − k es por tanto:
Pdup − k = Pr ob[t 2 < (k − 1)T + u < t1 ] (7.29)
Igualamos a cero la expresión (7.19) y sustituimos en (7.17).
t 2 = t m + ∆h + Y + d = 0 ⇒ t m = − ∆h − Y − d
σ
t1 = − ∆h − Y − d + − X −c
2
La probabilidad de recibir el paquete k-ésimo por duplicado es entonces:
 σ 
Pdup − k = Pr ob 0 < (k − 1)T + u < −∆h − Y − d + − X − c  (7.30)
 2 
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 T < ∆ho esta nueva v.a. tiene la función de densidad de
distribución siguiente:
 1 T∆ho 0<t <T

 1 ∆ho T ≤ t ≤ ∆ho
 (7.31)
f Q (t ) = 
( − t + ∆ho + T ) T∆ho ∆ho < t < ∆ho + T
 0 resto
Igualmente podemos definir la variable aleatoria Z que ya se ha

utilizado en desarrollos anteriores, Z = X + Y , que tiene la función de
densidad de distribución calculada en (7.7). Finalmente definimos una
nueva constante e = σ − c − d . Así la ecuación (7.30) queda:
2
Pdup − k = Pr ob[Z ≤ e − (k − 1)T − Q ] (7.32)
286
Podemos rescribir esta ecuación de la siguiente manera:
[ ]
∆ho +T
Pdup − k = ∫
0
Prob Z ≤ e − (k − 1)T − Q Q = q f Q (q )dq (7.33)
Por último utilizando la función de distribución FZ (t ) , tenemos:
∆ho +T
Pdup − k = ∫ 0
Fz ( Z ≤ e − (k − 1)T − Q Q = q) f Q (q ) dq (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.
287
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 CNoBS es sensiblemente inferior al retardo
CNnBS, 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.
288
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’.
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: t 2 < t < t 4 . La probabilidad de que el paquete k-
ésimo llegue duplicado es, por tanto:
Pdup − k = Pr ob[t 2 < (k − 1)T + u < t 4 ] (7.35)
Igualamos t 2 = 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:
Pdup − k = Pr ob[0 < (k − 1)T + u < Y '− X '−c'+ d '] (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á:
289
∫∫
T ∞
y o 2 − β yo
3
Pdup − k =
1
[Fx ( z '−u o + y o )] β e dy o du o (7.37)
T 2
0 max(0,u o - z')
siendo
z ' = e' '−(k − 1)T = (CN , R2 ) + ( R2 , nBS ) − (CN , R1 ) − ( R1 , oBS ) − (k − 1)T
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.
290
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: CNoBS - CNnBS. 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 CNoBS y CNnBS.
En la figura se observa que cuando retardo entre el nodo de cruce y

la estación base antigua CNoBS es sensiblemente inferior al retardo
CNnBS, lo que se corresponde con valores negativos de la gráfica, se
producen multitud de paquetes duplicados.
291
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 CNnBS. 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 CNnBS se producirá un aumento de paquetes duplicados en manera
similar al efecto que se estudió en la figura 7.10.
Nodo de
Cruce
6
5
6 Ack Join
oBS nBS
MN
Figura 7.14 duplicación de paquetes en handover Semi Suave.
292
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 CNoBS y
CNnBS. Así el eje horizontal se corresponde con la resta (CNoBS)-
(CNnBS), de manera que cuando la ruta hacia la estación base antigua
293
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 (CNoBS) y (CNnBS).
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.
294
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.
295
7.4.1 Análisis de los paquetes perdidos
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 t 5 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 ϕ.
t5 = t3 + ϕ (7.38)
Podemos calcular el instante de tiempo t 6 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 t 5
t 6 = t 5 − [CN + (CN , R1 ) + R1 + ( R1 + oBS ) + oBS ] = (7.39)
= t 5 − [X '+c']
siendo X’ y c’ las utilizadas en la ecuación (7.24):
c' = (CN , R1 ) + ( R1 , oBS )
296
β 3t 2
X’ = v.a. con fdd: f X ' (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
2
Los paquetes perdidos son los que llegan al CN en un instante de

tiempo posterior a t 6 pero anterior a t 2 , 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:
Pper − k = Prob[t 6 < (k − 1)T + u < t 2 ] (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 t 6 y t 4 , el desarrollo de la ecuación será similar al
ya realizado. Así igualando t 6 = 0 y simplificando la ecuación (7.40) la
podemos rescribir de la siguiente forma:
Pper − k = Pr ob[0 < (k − 1)T + u < X '−Y '+e'−ϕ ] (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 ∞
x o 2 − β xo
3
Pper − k =
1
[FY ( z '−u o + xo )] β e dx o du o (7.42)
T 2
0 max(0,u o -z')
siendo ahora z’ :
z ' = e'−ϕ − (k − 1)T =
= (CN , R1 ) + ( R1 , oBS ) − (CN , R2 ) − ( R2 , nBS ) − ϕ − (k − 1)T
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.
297
Utilizando las ecuaciones (7.23) y (7.19) podemos rescribir el

instante t 5 , 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:
t 5 = t m + ∆h + Y + d + Y '+ d '+ϕ (7.43)
Como hemos comentado, el instante t 5 , 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:
σ
t AB = t m +
2
Por tanto, tomando como referencia t m = 0 , la probabilidad de que

el handover ocurra de manera correcta es:
σ
Prob[t 5 < t AB ] = Prob [Y + Y ' ≤ − d − d '− ∆h − ϕ ] =
2
σ
= Prob [ Z ≤ − d − d '−∆h − ϕ ] (7.44)
2
Siendo Fz (t ) 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:
Z = Y +Y' :
4
(t β ) n
Fz (t ) = 1 − e − β t ∑
n =0
n!
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:
1 ∆ho σ
Prob[t 5 < t AB ] = ∫ Pr ob [ Z ≤ − d − d '−ϕ − ∆H | ∆H = ∆h]d∆h =
∆ho 0 2
1 ∆ho σ
=
∆ho ∫ 0
Fz (
2
− d − d '−ϕ − ∆h)d∆h (7.45)
298
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 (CNoBS) que es x mseg. más lento que el

(CNnBS), 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.
299
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
300
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
‘ σ 2 − d − d '−ϕ − ∆h ’ 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 FZ (10) = 1 .
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 (CNoBS) y la ruta (CNnBS). 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.
301
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 t 2 . 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.
302
A continuación realizamos un desarrollo analítico para estudiar la

probabilidad de que un paquete determinado pertenezca a las tres clases
anteriores.
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 t 2 = 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 t 6 (instante del envío del mensaje
‘Multicast Prune Request’), que fue calculado en la ecuación (7.39).
Pk −cl .1 = Prob[paq. k ∈ clase 1] = Prob[t 2 < (k − 1)T + u < t 6 ] (7.46)
Una expresión similar fue desarrollada en (7.35). Así, desarrollando

(7.46) igual que se hizo entonces podemos rescribirla como:
∫∫
T ∞
y o 2 − β yo
3
Pk −cl.1 =
1
[F ' X ( z '−u o + y o )] β e dy o du o (7.47)
T 2
0 max(0,u o - z')
siendo
z ' = d '−c'+ϕ − (k − 1)T =
303
= (CN , R2 ) + ( R2 , nBS ) − (CN , R1 ) − ( R1 , oBS ) + ϕ − (k − 1)T
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.
[ ]
Prob retardo > τ paq. k ∈ clase 1 = 0 (7.48)
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 t 5 . Además el mensaje
no puede haber sido recibido por oBS, es decir no pertenece a la clase 1.
Podemos definir el instante t 7 como aquel a partir del cual los

paquetes que alcancen CN llegarán a nBS más tarde que t 5 .
t 7 = t 5 − [CN + (CN , R2 ) + R2 + ( R2 , nBS ) + nBS ] = (7.49)
= t 5 − (Y '+ d ' )
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).
Pk −cl .2 = Prob[paq. k ∈ clase 2] = Prob[t 6 < (k − 1)T + u < t 7 ] (7.50)
Utilizando las ecuaciones (7.49), (7.39), (7.38) y (7.23) podemos

rescribir la probabilidad anterior como:
304
Pk −cl .2 = Prob[Y '+ d '+ϕ − X '−c' < (k − 1)T + u < Y '−Y1 '+ϕ ] (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 t 7 y t 6 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.
1 T ∞
Pk − cl.2 =
T ∫ ∫
0 (k -1)T + uo -ϕ
(1 - FZ ( zo − ( K − 1)T + a − uo)) f Z ' ( zo)dzoduo (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, t A se corresponde con el tiempo desde que el paquete

llega a nBS y ésta recibe el paquete ‘Handover Switch Indication’:
t A = t 5 − [(k − 1)T + u + CN + (CN , R2 ) + R2 + ( R2 , nBS )] =
= (Y '+ d '+ϕ ) − [(k − 1)T + u + CN + R2 + d '] =
= Y '−Y ' '−(k − 1)T − u + ϕ (7.53)
con Y’’ = v.a. con fdd: f Y '' (t ) = β 2 te − β t para t ≥ 0 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.
305
Así los paquetes que se transmiten desde CN antes de t 6 (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
Púltimo = j = Prob[( j − 1)T + u < t 6 < jT + u ] (7.54)
Por tanto podríamos escribir el tiempo t B , 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
k − 1 − j paquetes restantes.
k −1
(k − j − 1)
tB = ∑P j =1
último = j
µ
(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:
[ ]
Prob retardo > τ paq. k ∈ clase 2 = Prob[t A + t B > τ ] (7.56)
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 t 7 definido en (7.49):
Pk −cl .3 = Prob[paq. k ∈ clase 3] = Prob[t 7 < (k − 1)T + u ] =
= Prob[Y'-Y1 '+ϕ < (k - 1)T + u ] (7.57)
La resolución de la ecuación (7.57) se ha realizado en el Anexo 2.3,

dando como resultado:
306
∫∫
T ∞
y o 2 − β yo
3
Pk −cl.3 =
1
[FY ' ( z + u o + y o )] β e dy o du o (7.58)
T 2
0 max(0,-uo − z)
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.
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
307
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.
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
308
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 t 6 y t 7 .
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
309
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.
310
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 t A . 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.
311
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.
312
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:
Pk −cl .1 + Pk −cl.2 + Pk −cl .3 = 1 ∀k > 0
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’.
313
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.
314
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.
315
Nodo de
Cruce
11
10
9
11
8
oBS nBS 7
6
Handover Switch
Indication (10)
MN
Figura 7.25 Funcionamiento incorrecto del esquema de handover.
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 t 5 . 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’.
Prob error = ∑ Prob[(k − 1)T + u < t

∀k
6 < kT + u ] Prob[(k − 1)T + u > t 7 ] (7.59)
El desarrollo de la primera probabilidad, que se muestra en el

Anexo 2.4, da como resultado:
316
Prob[(k − 1)T + u < t 6 < kT + u ] =
∫∫
T ∞
=
1
T
[Fy ' ( xo + u o − ϕ + e'+kT ) − FY ' ( xo + u o − ϕ + e'+(k − 1)T ) f x' ( xo )dx o du o ]
0 0
(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 t 6 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.
317
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.
318
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
319
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
320
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.
321
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
322
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.
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.
Nodo de
Cruce CN
R1 R2
R3
oBS nBS
MN
Figura 7.28 Esquema de la red para el modelado analítico.
323
Definimos los siguientes tiempos:
• t ho : 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.
• t1 : 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 t ho .
• t 2 : 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.
• t 3 : 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 t1 , t 2 y t 3 como sigue:
t1 = t ho − [CN + (CN , R1 ) + R1 + ( R1 , oBS ) + oBS ] (7.61)
t 2 = t ho + ∆h + nBS + (nBS , R2 ) + R2 + ( R2 , CN ) (7.62)
t 3 = t ho + ∆h + nBS + (nBS , R3 ) + R3 + ( R3 , oBS ) (7.63)
Donde CN, oBS, nBS, R1 , R2 y R3 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 t1 y t 2 ,
en este estudio vamos a considerar ∆h como un valor constante.
324
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 t 2 .

En caso contrario el paquete sería entregado al nodo móvil vía nBS.
2. El paquete alcanza CN después del instante t1 . Los paquetes que

llegan antes de este tiempo son transmitidos al nodo móvil antes de
t ho , 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 t 3 )
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:
Prob[Perd.] = Prob[(t CN < t 2 )AND(t CN > t1 )AND(t CN + X + c + bT < t 3 )] (7.64)
En la ecuación anterior t CN 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.

CN + R1 + oBS . Su función de densidad de distribución f X (t ) , 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.
β 3t 2
f X (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ ) (7.65)
2
325
Por último, c es un valor constante c = (CN , R1 ) + ( R1 , oBS ) 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.
t1 = t ho − [X + c ] (7.66)
t 2 = t ho + ∆h + Y + d (7.67)
t 3 = t ho + ∆h + Z + e (7.68)
con
d = (nBS , R2 ) + ( R2 , CN )
e = (nBS , R3 ) + ( R3 , oBS )
f Y (t ) = β 2 te − β t para t ≥ 0 y con β = µ (1 − ρ )
f Z (t ) = β 2 te − β t para t ≥ 0 y con β = µ (1 − ρ )
Podemos normalizar el tiempo haciendo t ho = 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 t ho , 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:
t CN < t 2 ⇒ t CN < ∆h + Y + d
t CN > t1 ⇒ t CN > − X − c
326
t CN + X + c + bT < t 3 ⇒ t CN + X + c + bT < ∆h + Z + e
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:
Prob[Perd.] = Prob[t CN < ∆h + Y + d ]* Prob[− X − c < t CN < ∆h + Z + e − X − c − bT ]
(7.69)
La primera probabilidad de la ecuación (7.69) es inmediata:
Prob[t CN < ∆h + Y + d ] = 1 − FY (t CN − ∆h − d ) (7.70)
Con respecto a la segunda:
Prob[− X − c < t CN < ∆h + Z + e − X − c − bT ] =
= Prob[0 < t CN + X + c < ∆h + Z + e − bT ] =

∞
= ∫ Prob[0 < t
0
CN + X + c < a + zo] f Z ( zo) dzo (7.71)
con a = ∆h + e − bT
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:
∞
∫ Prob[− t CN − c < X < a + zo − t CN − c ] f Z ( zo) dzo =
max( 0, − a )
∞
= ∫ [FX (a + zo − t CN − c) − FX (−t CN − c)] f Z ( zo) dzo (7.72)
max(0,-a)
327
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 t ho ha sido normalizado a 0, de manera que
hay que tener en cuenta también paquetes generados en un tiempo t CN
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:
t CN − k = −100 + (k − 1)T (7.73)
El cálculo del número medio de paquetes perdidos se realiza como:

∞
N= ∑ Prob[perd., t
k =1
CN = −100 + (k − 1)T ] (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.
328
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.
329
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,
330
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
331
estudiado, esto equivaldría a eliminar la ruta que pasa por R3 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.
332
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).
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
333
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 t ho 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 t LD y t LU respectivamente, de manera que siempre se
cumplirá: t ho < t LD < t LU . El tiempo que transcurre entre t LD y t LU 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:
• t1 : 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 t LD .
• t 2 : 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 t1 y t 2 como sigue:
334
t1 = t LD − [CN + (CN , R1 ) + R1 + ( R1 , oBS ) + oBS ] (7.75)
t 2 = t ho + oBS + (oBS , R3 ) + R3 + ( R3 , nBS ) + nBS + (nBS , R 2) + R2 + ( R 2, CN )
(7.76)
Donde CN, oBS, nBS, R1 , R2 y R3 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.
t1 = t LD − [X + c] (7.77)
t 2 = t ho + W + g (7.78)
con
c = (CN , R1 ) + ( R1 , oBS )
g = (oBS , R3 ) + ( R3 , nBS ) + (nBS , R2 ) + ( R2 , CN )
β 3t 2
f X (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
2
335
β 4t 3
f W (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
3!
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 t1 que marca
el límite de los paquetes que pueden entregarse vía oBS:
Prob[perd.] = Pr ob[t1 < t CN < t 2 ] (7.79)
Podemos normalizar el tiempo haciendo t ho = 0 . Es decir el tiempo

comienza en el momento en que se produce el trigger en el nodo móvil. Así
el valor t LD 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 t ho sea
de interés en el análisis que estamos realizando. Para no limitar de
ninguna forma el tiempo mínimo de t LD comenzamos el estudio de los
paquetes que llegan en un tiempo negativo. Así los instantes t CN en que
los paquetes alcanzan el nodo de cruce los podemos escribir como:
t CN = −30 + (k − 1)T + u (7.80)
336
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 t1 y t 2 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:
Pperd − k = Prob[t1 < t CN −k ]* Prob[t CN − k < t 2 ] (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:
Prob[t1 < t CN −k ] = Prob[t LD − X − c < −30 + (k − 1)T + u ] =
1 T
= ∫ Prob[t LD − X − c < −30 + (k − 1)T + uo]duo =
T 0
1 T
=
T ∫ 0
1 − FX (−t CN − k _ uo − c + t LD )duo (7.82)
Prob[t CN −k < t 2 ] = Prob[− 30 + (k − 1)T + u < W + g ] =
1 T
= ∫ Prob[− 30 + (k − 1)T + uo < W + g ]duo =
T 0
1 T
=
T ∫ 0
1 − FW (t CN − k _ uo − g )duo (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.
337
Denominamos t 3 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 t LD .
t 3 = t LU − [CN + (CN , R2 ) + R2 + ( R2 , nBS ) + nBS ] =
= t LU − Y − d (7.84)
con
d = (CN , R2 ) + ( R2 , nBS )
β 3t 2
f Y (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
2
Así, la probabilidad de que un paquete se descarte es:
Pdescartar − k = Prob[t 2 < t CN − k < t 3 ] =
= Prob[t 2 < t CN −k ] * Prob[t CN − k < t 3 ] (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 t1 ,
t 2 y t 3 son independientes, la probabilidad de que el paquete se pierda es:
Pperd −k = Prob[t 2 < t CN − k ] * Prob[t CN −k < t 3 ] * Prob[t CN −k > t1 ] (7.86)
Las tres probabilidades de la ecuación anterior son inmediatas:
Prob[t 2 < t CN −k ] = Prob[W + g < t CN −k ] =
1 T
=
T ∫ 0
FW (t CN −k _ uo − g )duo (7.87)
Prob[t CN −k < t 3 ] = Prob[t CN − k < t LU − Y − d ] =
1 T
=
T ∫ 0
FY (t LU − t CN − k _ uo − d )duo (7.88)
338
Prob[t CN −k > t1 ] = Prob[t CN − k > t LD − X − c ] =
1 T
=
T ∫ 0
(1 − FX (t LD − c − t CN − k _ uo ))duo (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 t1 , de

manera que es recibido por MN vía oBS.
• El paquete es generado después de t 2 , de marea que es transmitido

también a nBS
• El paquete es generado después de t 3 , de manera que no es

descartado por nBS.
Es decir:
Prob[dupl.] = Pr ob[(t CN − k < t1 ) AND(t CN − k > t 2 ) AND(t CN −k > t 3 )] (7.90)
Como ya se ha comentado los tiempos t1 , t 2 y t 3 son independiente

de manera que la ecuación anterior queda:
Prob[dupl.] = Pr ob[t CN −k < t1 ] * Pr ob[t CN −k > t 2 ] * Pr ob[t CN −k > t 3 ] (7.91)
339
Las tres probabilidades de la ecuación anterior son inmediatas:
Prob[t CN − k < t1 ] = Prob[t CN − k < t LD − X − c ] =
1 T
=
T ∫ 0
FX (t LD − c − t CN − k _ uo )duo (7.92)
Pr ob[t CN −k > t 2 ] = Pr ob[t CN −k > W + g ] =
1 T
=
T ∫ 0
FW (t CN − k _ uo − g )duo (7.93)
Pr ob[t CN − k > t 3 ] = Pr ob[t CN − k > t LU − Y − d ] =
1 T
=
T ∫ 0
(1 − FY (t LU − t CN − k _ uo − d ))duo (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 t LD . 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 t LD 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 t ho = 0 , 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.
340
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
341
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 t LU − t LD , es decir, el eje nos muestra el tiempo necesario para
realizar el handover de capa 2. En particular se ha ido variando el valor
t LU , mientras el valor t LD 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.
342
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 t LU , los paquetes duplicados deben llegar a oBS antes de t LD y a
nBS después de t LU . Como las rutas entre CN y las estaciones base tienen
el mismo retardo fijo, y siempre se va a cumplir que t LU > t LD , la
probabilidad de que se produzcan limitaciones es mínima.
343
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 t LU , sino del instante de tiempo
t 2 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 t LD como del
retardo ‘g’.
Anteriormente observamos como el valor del instante t LD 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
344
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
345
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.
346
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.
347
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
348
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
349
mucho más conveniente utilizar el esquema semi suave analizado

previamente.
350
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
351
Conclusiones y Líneas futuras de investigación
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
352
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
353
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
354
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
355
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.
356
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.
357
Bibliografía
[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.
358
Bibliografía
[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
359
Bibliografía
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 ‘Wirweless LAN Medium Access Control (MAC) and Physical

802.11] Layer (PHY) Specifications’. IEEE std. 802.11, 1999.
[IEEE ‘Recommended Practice for Multi-Vendor Access Point
360
Bibliografía
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
361
Bibliografía
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
362
Bibliografía
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
363
Bibliografía
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
364
Bibliografía
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
365
Bibliografía
[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
366
Bibliografía
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.
367
Bibliografía
[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.
368
Bibliografía
[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.
369
Bibliografía
[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.
370
Bibliografía
[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/MobileI
P/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/
371
Bibliografía
[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
372
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)
373
Anexo1. Acrónimos y Definiciones
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]
374
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 Mensaje utilizado por los Agentes para informar

Advertisement’: al MN de la red donde se encuentra. Se crea
añadiendo extensiones a un mensaje ICMP, [RFC
1256]
Agente de Movilidad Agente pasarela utilizado en el sistema de micro-

Multicast (MMA): mobilidad basado en multicast propuesto.
Árbol Basado en Método de elaboración del árbol multicast, que

Fuente (SRT): 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 Algoritmo que obtiene ruta de menor coste desde
más corto (SPT): una fuente a un destino.
Care-of Address Dirección temporal que utiliza el MN cuando se
375
(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 Asociación compuesta por el mecanismo de

Seguridad (SPI): seguridad y clave a emplear, que comparten dos
elementos del sistema IP móvil.
Encaminamiento Solución empleada en algunos sistemas de micro-

Basado en Host movilidad en los que el encaminamiento se
(HBR): 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 Cualquier otra red diferente a la Home Network y

(FN): 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 Handover en el que no se produce cambio en la

Degradación: 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.
376
‘Handover Switch Mensaje propuesto para el sistema de micro-

Indication’: 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 Mensaje del sistema de micro-movilidad basado

Registration en multicast utilizado para realizar un handover
Request’: 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
377
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 Extensión del mensaje ‘Registration Reply’

Extension’ (MAE): 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 Tecnología multicast novedosa en la que se utiliza

Fuente Específica concepto de ‘canal’ que está definido por el par
(SSM): ‘fuente’-‘grupo’.
‘Multicast Handover Mensaje propuesto para el sistema de micro-

Reply’: movilidad basado en multicast que se utiliza,
opcionalmente, para confirmar un mensaje
‘Multicast Prune Request’.
‘Multicast Prune Mensaje propuesto para el sistema de micro-

Request’: 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 Mecanismo bajo estudio que permite a los nodos

Ruta: 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].
378
‘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 Mensaje utilizado por el MN para informar al HA

Request’: 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 Nodo central del árbol multicast utilizado en

(RP): protocolos de ‘modo disperso’ como PIM-SM.
Session Initiation Protocolo de control para la creación,

Protocol (SIP): 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.
379
380
ANEXO 2. DESARROLLO DE LAS ECUACIONES
DEL CAPÍTULO 7
A2.1. Desarrollo de la ecuación 7.27
Pper − k = Prob[0 < (k − 1)T + u < X '−Y '+e'] (7.27)
con:
β 3t 2
2
β 3t 2
2
e' = (CN , R1 ) + ( R1 , oBS ) − (CN , R 2 ) − ( R 2 , nBS )
La ecuación (7.27) la podemos rescribir de la siguiente manera:
Pper − k = Pr ob[Y '− X '+u ≤ e'−(k − 1)T ] =

T 1
= ∫ Prob[Y '− X ' ≤ z '−u o ] du o (7.27a)
0 T
con z ' = e'−(k − 1)T
La probabilidad que aparece como parte de la ecuación (7.27a)

podemos, a su vez, desarrollarla como sigue:
∞
Prob[Y'-X' ≤ z' − u o ] = ∫ Prob[Y ' ≤ z '−u o + x o ] f X ' ( x o )dx o (7.27b)
0
La probabilidad de que Y’ sea menor que un valor puede escribirse

por medio de su función de distribución. Sustituyendo, además, f X ' ( x) , la
ecuación anterior nos queda:
381
Anexo 2. Desarrollo de ecuaciones.
∫
∞
 2
( z '−u o + x o ) j β j 
Prob[Y'-X' ≤ z' − u o ] = 1 − e − β ( z '−uo + xo )

∑ j!
*

max(0, uo − z ')  j =0
β 3 x o 2 − β xo
* e dx o (7.27c)
2
Es interesante observar el limite inferior de la ecuación anterior.

f X ' ( x) es distinto de cero sólo para valores de xo mayores que cero. Pero,
además, a probabilidad Prob[Y ' ≤ z '−u o + x o ] 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 ∞
1  2
( z '−u o + x o ) j β j  β 3 x o 2 − β xo
∑
− β ( z ' − u o + xo )
Pper − k = 1 − e  e dx o du o
T 0

max(0,u o - z')  j =0
j!  2
(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 w = e − β xo , dw = − β wdx o , y
operando, tenemos finalmente:
min(1,e β ( z ' − u o ) )
∫∫
T
1  2
( z '−u o − ( Ln( w) / β )) j β j 
Pper − k =
T 
∑
1 − e − β ( z '−uo ) w
j =0
j!
*

0 0
2
Ln( w)
* dwdu o (7.27e)
2
382
Pk −cl .2 = Prob[Y '+ d '+ϕ − X '−c' < (k − 1)T + u < Y '−Y1 '+ϕ ] (7.51)
con
β 3t 2
2
β 3t 2
2
β 3t 2
Y’1 = v.a. con fdd: f Y1 ' (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
2
Llamando a = ϕ + d '−c' la ecuación anterior la podemos rescribir como:
Pk −cl .2 = Prob[X '−a ≥ Y '−( K − 1)T − u ≥ Y '1 −ϕ ] =
Pk −cl .2 = Prob[X '−Y '1 −a ≥ Y '−Y '1 −( K − 1)T − u ≥ −ϕ ] = (7.51a)
Podemos simplificar la ecuación anterior definiendo dos nuevas

variable aleatorias Z = X '−Y '1 , Z ' = Y '−Y '1 cuyas fdd se han desarrollado en
el punto 2.2.1 de este anexo.
j
e − β |t| β 3  2  2− j  1 
∑
2
Z , Z’ = v.a. con fdd: f Z (t ) = f Z ' (t ) =  |t |   (2 + j )!
j =0  j 
32    2β 
(7.51b)
[
Pk −cl .2 = Prob Z − a ≥ Z ' − ( K − 1)T − u ≥ −ϕ = ]
= ∫
T
u =0
[
Prob Z − a + ϕ ≥ Z ' − ( K − 1)T + ϕ − uo ≥ 0 ]T1 duo =
1 T ∞
= ∫ ∫ Prob[Z − a + ϕ ≥ zo − ( K − 1)T + ϕ − uo] f Z ' ( zo)dzo duo =
T 0 (k -1)T + uo -ϕ
383
1 T ∞
= ∫ ∫ Prob[Z ≥ zo − ( K − 1)T + a − uo] f Z ' ( zo)dzo duo =
T 0 (k -1)T + uo -ϕ
1 T ∞
=
T ∫ ∫
0 (k -1)T + uo -ϕ
(1 - FZ ( zo − ( K − 1)T + a − uo)) f Z ' ( zo)dzo duo
(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.
(t β ) n −1 − β t
X, Y = v.a. con ffd f X (t ) = f Y (t ) = β e para t ≥ 0
(n − 1)!
Al ser dos funciones positivas e idénticas, la función de densidad de

la resta entre ellas la podemos escribir como:
∞
f Z (t ) = ∫ 0
f X (| t | +τ ) f Y (τ )dτ
con:
(| t | + τ ) n −1 − β (| t |+τ )
f X (| t | +τ ) = β n e
(n − 1)!
τ n −1
f Y (τ ) = β n e − βτ
(n − 1)!
β 2n ∞
f Z (t ) =
[(n − 1)!]
e − |t | β ∫ 0
(| t | +τ ) n −1τ n −1e − 2τβ dτ (7.51d)
Para simplificar la ecuación anterior definimos una nueva integral Ik como:
∞ k!
Ik = ∫ 0
τ k e − 2τβ dτ =
( 2 β ) k +1
(7.51e)
384
Parte del integrando de la ecuación (7.51d) puede desarrollarse

según el binomio de Newton:
n −1  n − 1 j
(| t | +τ ) n −1τ n −1 = τ n −1 ∑ 
j =0  j 
τ | t |n −1− j =
n −1  n − 1 j + n −1
= ∑ 
j =0  j 
τ | t |n −1− j (7.51f)
Sustituyendo (7.51f) en la ecuación de la función de densidad de

distribución tenemos:
β 2n ∞ n −1  n − 1
e − |t | β ∫ ∑ | t |n −1− j e − 2τβ dτ
j + n −1
f Z (t ) =  τ (7.51g)
[(n − 1)!] 0 j =0  j 
Ahora podemos utilizar la definición de Ik de la ecuación (7.51e) de

manera que nos queda:
β 2n n −1  n − 1
f Z (t ) =
[(n − 1)!]
e − |t | β ∑ 
j =0  j
 |t |

n −1− j
I j + n −1 =
β 2n n −1  n − 1 (n − 1 + j )!
=
[(n − 1)!]
e − |t | β ∑ 
j =0  j
|t |

n −1− j
2β j + n
=
n j
e − |t | β  β  n −1  n − 1 n −1− j  1 
=
[(n − 1)!]  2  ∑   |t |
j =0  j 
  (n − 1 + j )!
 2β 
(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].
385
Pk −cl .3 = Prob[Y '−Y1 '+ϕ < (k − 1)T + u ] (7.57)
con:
β 3t 2
Y1’ = v.a. con fdd: f Y1 ' (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
2
β 3t 2
2
La ecuación (7.57) la podemos rescribir de la siguiente manera:
T 1
Pk −cl .3 = ∫ Prob[Y '−Y1 ' ≤ z + u o ] du o (7.57a)
0 T
con z = (k − 1)T − ϕ
La probabilidad que aparece como parte de la ecuación (7.57a)

podemos, a su vez, desarrollarla como sigue:
∞
Prob[Y'-Y1' ≤ z + u o ] = ∫ Prob[Y ' ≤ z + u o + y o ] f Y1 ' ( y o )dy o (7.57b)
0
La probabilidad de que Y’ sea menor que un valor puede escribirse

por medio de su función de distribución. Sustituyendo, además, f Y1 ' ( y ) , la
ecuación anterior nos queda:
∫
∞
 2
( z + u o + y o ) j β j  β 3 y o 2 − β yo
Prob[Y'-Y1' ≤ z + u o ] = 1 − e − β ( z +uo + yo )

∑ j!

 2
e dy o
max(0, -uo − z )  j =0
(7.57c)
386
Es interesante observar el limite inferior de la ecuación anterior.

f Y1 ' ( y ) es distinto de cero sólo para valores de yo mayores que cero. Pero,
además, a probabilidad Prob[Y ' ≤ z + u o + y o ] 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 ∞
1  2
( z − u o + y o ) j β j  β 3 y o 2 − β yo
∑
− β ( z −uo + y o )
Pk −cl .3 = 1 − e  e dy o du o
T
0

max(0,-uo - z)  j =0
j!  2
(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.
Prob[(k − 1)T + u < t 6 < kT + u ] (7.59a)
Utilizando las ecuaciones (7.39), (7.38), y (7.23) podemos sustituir

el valor de t 6 , de manera que la ecuación anterior queda:
Prob[(k − 1)T + u < Y '− X '+ϕ − e' < kT + u ] (7.59b))
con:
β 3t 2
X’, Y’ = v.a. con fdd: f X ' (t ) = f Y ' (t ) = e − β t para t ≥ 0 y con β = µ (1 − ρ )
2
e' = (CN , R1 ) + ( R1 , oBS ) − (CN , R2 ) − ( R2 , nBS )
La ecuación (7.59b) la podemos rescribir de la siguiente manera:
387
∫
T
1
Prob[(0 < Y '− X '−u + a < T ] = Prob[Y '− X '−u o + a ≤ T ] du o (7.59c)
0 T
con a = ϕ − e'−(k − 1)T
Fijando ahora la v.a X’ :
∫∫
T ∞
1
= Prob[Y '− x o − u o + a ≤ T ] f X ' ( xo )dx o du o (7.59d)
T 0 0
A continuación desarrollamos la probabilidad que aparece en la

ecuación anterior, denominando b = xo + u o − a :
Prob[(0 < Y '−b < T ] =
= Prob[b < Y ' < T + b] =
= Prob[Y ' < T + b] - Prob[Y ' < b] =
= FY ' (T + b) − FY ' (b) (7.59e)
Finalmente sustituimos (7.59e) en (7.59d), de manera que la

probabilidad queda:
∫∫
T ∞
1
FY ' ( x o + u o − ϕ + e'+ kT ) − FY ' ( x o + u o − ϕ + e'+(k − 1)T ) f X ' ( x o )dxo du o
T 0 0
(7.59f)
388

Aleon Tesis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aleon Tesis

Uploaded by

Copyright:

Available Formats

TESIS DOCTORAL

ANTONIO LEÓN FERNÁNDEZ

DIRECTOR: DR. D. MANUEL ESTEVE DOMINGO

UNIVERSIDAD POLITÉCNICA DE VALENCIA

Nowadays, mobility is one of the most interesting research topics in

While Mobile IP offers significant advantages  which converted it

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

A complete protocol has been designed in order to include the

In addition, five different handover schemes have been designed to

Uno de los campos de investigación más interesante actualmente es

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

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

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

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

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

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

En aquesta tesi doctoral es presenta un sistema innovador de

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

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

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

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

A mis compañeros de trabajo por sus consejos y su inestimable

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

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

2. SISTEMAS DE MOVILIDAD EN REDES IP 11

2.8 RESUMEN DEL CAPÍTULO 61

4. PROCESO DE HANDOVER EN REDES IP 117

4.1 INTRODUCCIÓN 117

5. PRESTACIONES DEL HANDOVER EN REDES IP 151

5.1 INTRODUCCIÓN 151

5.5 ESTUDIO DE PRESTACIONES DE LOS SISTEMAS 194

6. ESPECIFICACIÓN DE MECANISMOS DE 221

6.1 INTRODUCCIÓN 221

6.6.1 Solución a los problemas del esquema 244

7. EVALUACIÓN ANALÍTICA DE LOS MECANISMOS 263

7.1 INTRODUCCIÓN 263

7.6 ESQUEMA DE HANDOVER INDIRECTO CON PRE- 333

8. CONCLUSIONES Y LÍNEAS FUTURAS DE 351

8.1 INTRUCCIÓN 351

ANEXO 1. ACRÓNIMOS Y GLOSARIO 373

ANEXO 2. DESARROLLO DE ECUACIONES 381

En la sociedad de la información actual dos tecnologías sobresalen

La segunda tecnología sobresaliente sería la tecnología de

De lo anterior podemos deducir la importancia que en un futuro va

En este sentido, la movilidad dentro de una subred es un tema

de seguridad y de calidad de servicio. Sin embargo la movilidad entre

Podemos tomar el ejemplo de las redes UMTS actuales. Cuando un

Como observamos del ejemplo anterior, los sistemas de tercera

El siguiente paso sería pues la convergencia total entre la

• Los sistemas de telefonía serían más baratos, debido a economías

• Se podrían ofrecer un conjunto de nuevos servicio basados en las

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

• Como IP es un protocolo que puede funcionar sobre cualquier

integrar otras tecnologías de acceso, como WLAN, con las

Sin embargo, la arquitectura basada en IP también tiene

• Dificultad para poder ofrecer QoS, debido a la naturalezabest

• Dificultad para poder ofrecer movilidad, debido a que el protocolo

Para poder ofrecer calidad de servicio (QoS) se requiere del control

La solución a este problema pasa, evidentemente, por que la red

diferenciados se basan en una configuración de QoS estática de manera

En los trabajos que se están desarrollando para los nuevos

El segundo problema fundamental de la arquitectura basada en IP

La solución de cambiar de dirección IP por parte del nodo móvil