movilidad ip basado en transmisión multicast - Universidad ...
movilidad ip basado en transmisión multicast - Universidad ...
movilidad ip basado en transmisión multicast - Universidad ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
TESIS DOCTORAL<br />
ESPECIFICACIÓN Y EVALUACIÓN DE<br />
UN PROTOCOLO DE MICRO-<br />
MOVILIDAD IP BASADO EN<br />
TRANSMISIÓN MULTICAST<br />
ANTONIO LEÓN FERNÁNDEZ<br />
DIRECTOR: DR. D. MANUEL ESTEVE DOMINGO<br />
Departam<strong>en</strong>to de Comunicaciones<br />
Escuela Técnica Superior de Ing<strong>en</strong>ieros de Telecomunicación<br />
UNIVERSIDAD POLITÉCNICA DE VALENCIA<br />
Abril 2004
ABSTRACT<br />
Nowadays, mobility is one of the most interesting research topics in<br />
the context of IP networks. Although several approaches have be<strong>en</strong><br />
proposed to deal with mobility, most of them are based on the Mobile IP<br />
protocol [RFC 3344].<br />
While Mobile IP offers significant advantages ⎯ which converted it<br />
in a key refer<strong>en</strong>ce for curr<strong>en</strong>t research ⎯ it also pres<strong>en</strong>ts important<br />
limitations. In order to overcome those limitations several improvem<strong>en</strong>ts<br />
have be<strong>en</strong> proposed, which are g<strong>en</strong>erally based on a division of the<br />
network into zones or domains. This concept is named micro-mobility and<br />
allows to manage handovers in a local way.<br />
In this Ph.D. dissertation we pres<strong>en</strong>t a new micro-mobility system<br />
based on <strong>multicast</strong>. The use of <strong>multicast</strong> technology offers, among others,<br />
two important advantages: the inher<strong>en</strong>t capability of simultaneously data<br />
transmission to several locations, which helps to achieve lossless<br />
handovers, and its degree of maturity, that allows an easy integration into<br />
mobile systems.<br />
A complete protocol has be<strong>en</strong> designed in order to include the<br />
format of the messages, as well as solutions to possible scalability and<br />
security problems.<br />
In addition, five differ<strong>en</strong>t handover schemes have be<strong>en</strong> designed to<br />
be implem<strong>en</strong>ted in the <strong>multicast</strong> based micro-mobility system. These<br />
schemes include a wide range of possibilities, both with regard to the<br />
capacities that are offered by the network (simultaneous communication<br />
with two stations or only with one of them) and with the handover<br />
requirem<strong>en</strong>ts (null packages loss, minimum lat<strong>en</strong>cy, etc.). These five<br />
schemes have be<strong>en</strong> analytically evaluated, relying on the number of lost<br />
packets, time of interruption, or time of buffers delays, with the purpose of<br />
analyzing the advantages to use one or another.
RESUMEN<br />
Uno de los campos de investigación más interesante actualm<strong>en</strong>te es<br />
la <strong>movilidad</strong> <strong>en</strong> redes IP. Aunque exist<strong>en</strong> distintas soluciones para abordar<br />
el problema, la mayoría de las contribuciones giran <strong>en</strong> torno al protocolo<br />
Mobile IP [RFC 3344].<br />
Sin esconder las v<strong>en</strong>tajas que aporta, y que lo han convertido <strong>en</strong> la<br />
refer<strong>en</strong>cia básica para toda la investigación actual, hay que indicar que<br />
Mobile IP ti<strong>en</strong>e importantes limitaciones. Se han realizado diversas<br />
propuestas de mejora que, <strong>en</strong> g<strong>en</strong>eral, se basan <strong>en</strong> la división espacial <strong>en</strong><br />
zonas o dominios. Este concepto es d<strong>en</strong>ominado micro-<strong>movilidad</strong> y permite<br />
que el handover pueda ser tratado de manera local.<br />
En esta Tesis Doctoral se pres<strong>en</strong>ta un novedoso sistema de micro<strong>movilidad</strong><br />
<strong>basado</strong> <strong>en</strong> la capacidad de transmisión <strong>multicast</strong>. La utilización<br />
de esta tecnología nos va ofrecer v<strong>en</strong>tajas, como la facilidad intrínseca de<br />
transmitir datos simultáneam<strong>en</strong>te a dos localizaciones, lo que favorece los<br />
handovers sin pérdidas, o la madurez actual de la tecnología, que permite<br />
su fácil incorporación a <strong>en</strong>tornos móviles.<br />
Se ha diseñado un protocolo completo, incluy<strong>en</strong>do el formato de<br />
todos los m<strong>en</strong>sajes propuestos, así como soluciones a posibles problemas<br />
de escalabilidad y de seguridad necesarias <strong>en</strong> este t<strong>ip</strong>o de redes.<br />
Se propon<strong>en</strong>, además, cinco esquemas de handover difer<strong>en</strong>tes,<br />
diseñados para implem<strong>en</strong>tarse <strong>en</strong> el sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong><br />
<strong>multicast</strong>. Éstos abarcan todo un abanico de posibilidades, tanto <strong>en</strong> lo<br />
refer<strong>en</strong>te a las capacidades que le ofrece la red (capacidad de<br />
comunicación simultanea con dos estaciones base o sólo con una), como<br />
<strong>en</strong> requisitos del handover (pérdida nula de paquetes, lat<strong>en</strong>cia mínima,<br />
etc.). Los cinco esquemas anteriores han sido evaluados analíticam<strong>en</strong>te,<br />
con el fin de analizar las v<strong>en</strong>tajas de utilizar uno u otro esquema, <strong>en</strong><br />
función del número de paquetes perdidos, tiempo de interrupción o tiempo<br />
de espera <strong>en</strong> ‘buffers’.
RESUM<br />
Un dels camps d’investigació més interessant actualm<strong>en</strong>t és la<br />
mobilitat <strong>en</strong> xarxes IP. Encara que hi ha distintes solucions per a abordar<br />
el problema, la majoria de les contribucions vers<strong>en</strong> <strong>en</strong>torn del protocol<br />
Mobile IP [RFC 3344].<br />
S<strong>en</strong>se amagar els avantatges que aporta, i que l’han convertit <strong>en</strong> la<br />
referència bàsica per a tota la investigació actual, cal indicar que Mobile IP<br />
té importants limitacions. S’han realitzat diverses propostes de millora<br />
que, <strong>en</strong> g<strong>en</strong>eral, es bas<strong>en</strong> <strong>en</strong> la divisió espacial <strong>en</strong> zones o dominis. Aquest<br />
concepte és d<strong>en</strong>ominat micro-mobilitat i permet que el handover puga ser<br />
tractat de manera local.<br />
En aquesta tesi doctoral es pres<strong>en</strong>ta un sistema innovador de<br />
micro-mobilitat basat <strong>en</strong> la capacitat <strong>multicast</strong>. La utilització d’aquesta<br />
tecnologia <strong>en</strong>s oferirà avantatges, com ara la facilitat intrínseca de<br />
transmetre dades simultàniam<strong>en</strong>t a dues localitzacions, cosa que afavoreix<br />
els handovers s<strong>en</strong>se pèrdues, o la maduresa actual de la tecnologia, que <strong>en</strong><br />
permet la fàcil incorporació a <strong>en</strong>torns mòbils.<br />
S’ha diss<strong>en</strong>yat un protocol complet, que inclou el format de tots els<br />
missatges proposats, així com solucions a possibles problemes de<br />
escalabilitat i de seguretat necessàries <strong>en</strong> aquest t<strong>ip</strong>us de xarxes.<br />
Es propos<strong>en</strong>, a més, cinc esquemes de handover difer<strong>en</strong>ts,<br />
diss<strong>en</strong>yats per a implem<strong>en</strong>tar-se <strong>en</strong> el sistema de micro-mobilitat basat <strong>en</strong><br />
<strong>multicast</strong>. Aquests abrac<strong>en</strong> tot un v<strong>en</strong>tall de possibilitats, tant pel que fa a<br />
les capacitats que li ofereix la xarxa (capacitat de comunicació simultània<br />
amb dos estacions base o solam<strong>en</strong>t amb una), com <strong>en</strong> requisits del<br />
handover (pèrdua nul·la de paquets, latència mínima, etc.). Els cinc<br />
esquemes anteriors han sigut avaluats analíticam<strong>en</strong>t, amb la finalitat<br />
d’analitzar els avantatges d’utilitzar un o un altre esquema, <strong>en</strong> funció del<br />
nombre de paquets perduts, temps d’interrupció o temps d’espera <strong>en</strong><br />
buffers.
AGRADECIMIENTOS<br />
Me gustaría dar las gracias, <strong>en</strong> primer lugar, a mi mis padres<br />
Antonio y Pilar, y a hermana Paloma, por todo el cariño que me han dado<br />
durante estos años.<br />
A Manuel Esteve por su confianza y apoyo constante, más allá del<br />
simple trabajo de director de esta Tesis.<br />
A mis compañeros de trabajo por sus consejos y su inestimable<br />
ayuda a lo largo de todo este tiempo. A José Enrique, Oscar, Ana, Juan<br />
Carlos y Carlos. Gracias especialm<strong>en</strong>te a Vic<strong>en</strong>t, por sus útiles consejos y<br />
por su siempre interesante conversación.<br />
A mis bu<strong>en</strong>os amigos Oscar y Antonio, por hacerme reír y poder<br />
disfrutar con ellos de todos esos mom<strong>en</strong>tos irrepetibles.<br />
Muy especialm<strong>en</strong>te a María José. Gracias por compartir tu vida conmigo.
INDICE DE LA MEMORIA<br />
1. INTRODUCCIÓN Y OBJETIVOS 1<br />
1.1 INTRODUCCIÓN 1<br />
1.2 OBJETIVOS DE LA TESIS 6<br />
1.3 ORGANIZACIÓN DE LA MEMORIA 8<br />
2. SISTEMAS DE MOVILIDAD EN REDES IP 11<br />
2.1 INTRODUCCIÓN 11<br />
2.2 PRIMEROS TRABAJOS 17<br />
2.2.1 Esquema de Columbia 17<br />
2.2.2 Esquema Sony 18<br />
2.2.3 Esquema LSR 19<br />
2.3 MOBILE IP 21<br />
2.3.1 Visión G<strong>en</strong>eral del Modo de Funcionami<strong>en</strong>to 25<br />
2.3.2 Descubrimi<strong>en</strong>to del Ag<strong>en</strong>te 26<br />
2.3.3 Registro 28<br />
2.3.4 Envío de datos 31<br />
2.3.5 Consideraciones relativas a la Seguridad 33<br />
2.3.6 Optimización de la Ruta 35<br />
2.3.7 Mobile IP con Registro Regional 40<br />
2.4 SISTEMAS DE MICROMOVILIDAD 42<br />
2.4.1 CELLULAR IP 44<br />
2.4.2 HAWAII 46<br />
2.4.3 TeleMIP 48<br />
2.4.4 Edge Mobility Architecture, EMA 50<br />
2.5 SISTEMA DE MOVILIDAD BASADO EN MULTICAST 51<br />
2.5.1 J. Mysore. MSM-IP 52<br />
2.5.2 Daedalus 54<br />
2.6 IP MOBILE v6 55<br />
2.7 SOLUCIONES DE MOVILIDAD A NIVEL DE<br />
APLICACIÓN<br />
59<br />
i
Índice de la Memoria<br />
2.8 RESUMEN DEL CAPÍTULO 61<br />
3. PROPUESTA DE SISTEMA DE<br />
MICROMOVILIDAD BASADO EN MULTICAST<br />
65<br />
3.1 INTRODUCCIÓN 65<br />
3.2 ARQUITECTURA 67<br />
3.3 PROTOCOLO DE MICRO-MOVILIDAD BASADO EN 70<br />
MULTICAST<br />
3.3.1 Descubrimi<strong>en</strong>to de la red actual 73<br />
3.3.2 Registro <strong>en</strong> un nuevo Dominio 74<br />
3.3.3 Registro <strong>en</strong> una nueva BS d<strong>en</strong>tro del Dominio 78<br />
3.3.4 Transmisión y Recepción de datos 80<br />
3.3.5 Escalabilidad 83<br />
3.4 ASPECTOS RELATIVOS A LA SEGURIDAD EN EL<br />
SISTEMA DE MICROMOVILIDAD PRESENTADO<br />
3.4.1 Introducción a la seguridad <strong>en</strong> <strong>en</strong>tornos<br />
móviles<br />
3.4.2 Seguridad <strong>en</strong> el Sistema de Micro-<strong>movilidad</strong><br />
Multicast<br />
86<br />
86<br />
87<br />
3.5 FORMATO DE LOS MENSAJES 94<br />
3.5.1 M<strong>en</strong>sajes para el descubrimi<strong>en</strong>to de la red 94<br />
3.5.2 M<strong>en</strong>sajes <strong>en</strong> el registro <strong>en</strong> un nuevo Dominio 96<br />
3.5.3 M<strong>en</strong>sajes para el registro Intra-Dominio 99<br />
3.5.4 Otros m<strong>en</strong>sajes no detallados 101<br />
3.6 CONSIDERACIONES SOBRE EL USO DE<br />
102<br />
TRANSMISIÓN MULTICAST EN EL SISTEMA DE<br />
MICROMOVILIDAD<br />
3.6.1 Introducción a la transmisión <strong>multicast</strong> 102<br />
3.6.2 Selección de la tecnología <strong>multicast</strong> a emplear 103<br />
3.6.3 Incorporación del protocolo PIM-SM / SSM al 108<br />
sistema de micro-<strong>movilidad</strong><br />
3.7 TABLA COMPARATIVA CON OTRAS PROPUESTAS<br />
DE MICRO-MOVILIDAD<br />
112<br />
3.8 CONCLUSIONES DEL CAPÍTULO 114<br />
ii
Índice de la Memoria<br />
4. PROCESO DE HANDOVER EN REDES IP 117<br />
4.1 INTRODUCCIÓN 117<br />
4.2 Lat<strong>en</strong>cia del proceso de Handover <strong>en</strong> redes IP 121<br />
4.2.1 Retardo <strong>en</strong> la detección del movimi<strong>en</strong>to 122<br />
4.2.2 Retardo <strong>en</strong> la recuperación de una dirección 123<br />
temporal, Care-of Address<br />
4.2.3 Retardo de reestablecimi<strong>en</strong>to de la ruta 125<br />
4.3 COOPERACIÓN DE LA CAPA 2 DURANTE EL<br />
HANDOVER<br />
126<br />
4.4 SOLUCIONES EXISTENTES DE HANDOVER EN 130<br />
SISTEMAS DE MOVILIDAD IP<br />
4.4.1 Soluciones para Handovers suaves 132<br />
4.4.2 Handover de baja lat<strong>en</strong>cia utilizando triggers 134<br />
4.4.3 Handovers <strong>en</strong> sistemas de micro-<strong>movilidad</strong> 139<br />
4.4.4 Handovers <strong>basado</strong>s <strong>en</strong> transmisión <strong>multicast</strong> 145<br />
4.5 RESUMEN Y CONCLUSIONES DEL CAPÍTULO 147<br />
5. PRESTACIONES DEL HANDOVER EN REDES IP<br />
MÓVILES<br />
151<br />
5.1 INTRODUCCIÓN 151<br />
5.1.1 Simulador de red NS-2 153<br />
5.1.2 Metodología de trabajo 156<br />
5.2 INTRODUCCIÓN AL ESTUDIO POR SIMULACIÓN<br />
DEL PROTOCOLO ‘MOBILE IP’<br />
157<br />
5.3 ESTUDIO DEL HANDOVER CERCANO DEL<br />
158<br />
PROTOCOLO MOBILE IP<br />
5.3.1 Estudio del tráfico UDP <strong>en</strong> Handover Cercano 159<br />
5.3.2 Estudio del tráfico TCP <strong>en</strong> Handover Cercano 168<br />
5.3.3 Conclusiones sobre el Handover Cercano 173<br />
5.4 ESTUDIO DEL HANDOVER LEJANO DEL<br />
174<br />
PROTOCOLO ‘MOBILE IP’<br />
5.4.1 Estudio del tráfico UDP <strong>en</strong> Handover Lejano 175<br />
5.4.2 Estudio del tráfico TCP <strong>en</strong> Handover Lejano 183<br />
5.4.3 Conclusiones sobre el Handover Lejano 192<br />
iii
Índice de la Memoria<br />
5.5 ESTUDIO DE PRESTACIONES DE LOS SISTEMAS<br />
DE MICRO - MOVILIDAD<br />
5.5.1 Estudio del tráfico UDP <strong>en</strong> Sistemas de Micro-<br />
Movilidad<br />
5.5.2 Estudio del tráfico TCP <strong>en</strong> Sistemas de Micro-<br />
Movilidad<br />
5.5.3 Conclusiones sobre los sistemas de micro<strong>movilidad</strong><br />
5.6 IMPLEMENTACIÓN DE UN BANCO DE PRUEBAS<br />
DEL PROTOCOLO MOBILE IP<br />
194<br />
196<br />
200<br />
203<br />
204<br />
5.6.1 Transmisión CBR con protocolo UDP 207<br />
5.6.2 Transmisión con protocolo TCP 208<br />
5.6.3 Transmisión de tráfico multimedia con RTP 210<br />
5.6.3.1 Transmisión multimedia con calidad media 211<br />
5.6.3.2 Transmisión de videoconfer<strong>en</strong>cia de baja<br />
calidad<br />
212<br />
5.6.4 Prueba subjetiva sobre el efecto del handover 215<br />
5.6.5 Conclusiones de la implem<strong>en</strong>tación del banco 218<br />
de pruebas<br />
6. ESPECIFICACIÓN DE MECANISMOS DE<br />
HANDOVER INTRA-DOMINIO PARA UN<br />
SISTEMA DE MICRO-MOVILIDAD BASADO EN<br />
MULTICAST<br />
221<br />
6.1 INTRODUCCIÓN 221<br />
6.2 PROPUESTA DE ESQUEMAS DE HANDOVER 223<br />
6.3 ESQUEMA DE HANDOVER ABRUPTO 225<br />
6.4 ESQUEMA DE HANDOVER SEMI SUAVE 230<br />
6.4.1 Limitaciones del mecanismo de Handover Semi 232<br />
Suave<br />
6.5 ESQUEMA DE HANDOVER SUAVE CON<br />
235<br />
FINALIZACIÓN CONTROLADA<br />
6.5.1 Formato del m<strong>en</strong>saje ‘Handover Switch<br />
238<br />
Indication’<br />
6.5.2 Coexist<strong>en</strong>cia de los esquemas de handover 240<br />
6.6 ESQUEMA DE HANDOVER CON<br />
REDIRECCIONAMIENTO<br />
242<br />
iv
Índice de la Memoria<br />
6.6.1 Solución a los problemas del esquema 244<br />
6.6.2 Formato de los m<strong>en</strong>sajes utilizados <strong>en</strong> este 248<br />
esquema<br />
6.7 ESQUEMA DE HANDOVER INDIRECTO CON PRE-<br />
REGISTRO<br />
6.8 RESUMEN Y CONCLUSIONES DE LOS ESQUEMAS<br />
DE HANDOVER PROPUESTOS<br />
7. EVALUACIÓN ANALÍTICA DE LOS MECANISMOS<br />
DE HANDOVER INTRA-DOMINIO<br />
252<br />
255<br />
263<br />
7.1 INTRODUCCIÓN 263<br />
7.2 ESQUEMA DE HANDOVER ABRUPTO 264<br />
7.2.1 Desarrollo analítico 264<br />
7.2.2 Resultados 268<br />
7.3 ESQUEMA DE HANDOVER SEMI SUAVE 272<br />
7.3.1 Pérdida de paquetes del handover sin<br />
273<br />
desconexión de oBS<br />
7.3.1.1 Desarrollo analítico 273<br />
7.3.1.2 Resultados 276<br />
7.3.2 Pérdida de paquetes con desconexión de oBS 278<br />
7.3.2.1 Desarrollo analítico 279<br />
7.3.2.2 Resultados 281<br />
7.3.3 Paquetes duplicados sin desconexión de oBS 285<br />
7.3.3.1 Desarrollo analítico 285<br />
7.3.3.2 Resultados 287<br />
7.3.4 Paquetes duplicados con desconexión de oBS 288<br />
7.3.4.1 Desarrollo analítico 289<br />
7.3.4.2 Resultados 290<br />
7.3.5 Conclusiones del handover Semi Suave 293<br />
7.4 ESQUEMA SUAVE CON FINALIZACION<br />
295<br />
CONTROLADA<br />
7.4.1 Análisis de los paquetes perdidos 296<br />
7.4.1.1 Desarrollo analítico 296<br />
7.4.1.2 Resultados 299<br />
7.4.2 Análisis del retardo de los paquetes <strong>en</strong>tregados 302<br />
v
Índice de la Memoria<br />
vía nBS<br />
7.4.2.1 Desarrollo analítico 303<br />
7.4.2.2 Resultados 307<br />
7.4.3 Análisis de la limitación del mecanismo de 315<br />
handover con Finalización Controlada<br />
7.4.3.1 Desarrollo analítico 316<br />
7.4.3.2 Resultados 317<br />
7.4.4 Conclusiones 319<br />
7.5 ESQUEMA DE HANDOVER CON<br />
321<br />
REDIRECCIONAMIENTO<br />
7.5.1 Desarrollo analítico 323<br />
7.5.2 Resultados 328<br />
7.5.3 Consideraciones finales sobre el Handover con 330<br />
Redireccionami<strong>en</strong>to<br />
7.5.3.1 Posible duplicación de paquetes 331<br />
7.6 ESQUEMA DE HANDOVER INDIRECTO CON PRE- 333<br />
REGISTRO<br />
7.6.1 Desarrollo analítico 333<br />
7.6.1.1 Paquetes perdidos 336<br />
7.6.1.2 Paquetes duplicados 339<br />
7.6.2 Resultados 340<br />
7.6.3 Conclusiones 345<br />
7.7 CONCLUSIONES DEL CAPÍTULO 346<br />
8. CONCLUSIONES Y LÍNEAS FUTURAS DE<br />
INVESTIGACIÓN<br />
351<br />
8.1 INTRUCCIÓN 351<br />
8.2 CONCLUSIONES 351<br />
8.3 LÍNEAS FUTURAS DE INVESTIGACIÓN 355<br />
BIBLIOGRAFÍA. 357<br />
ANEXO 1. ACRÓNIMOS Y GLOSARIO 373<br />
ANEXO 2. DESARROLLO DE ECUACIONES 381<br />
vi
1. INTRODUCCIÓN Y OBJETIVOS<br />
1.1 INTRODUCCIÓN<br />
En la sociedad de la información actual dos tecnologías sobresal<strong>en</strong><br />
claram<strong>en</strong>te del resto. La primera sería la arquitectura TCP/IP, base de<br />
Internet. El auge social que ti<strong>en</strong>e esta red, unido a la s<strong>en</strong>cillez y flexibilidad<br />
de los protocolos, han posibilitado la supremacía de esta arquitectura<br />
sobre todas las demás, si<strong>en</strong>do, por ejemplo, la base de la gran mayoría de<br />
las redes corporativas actuales.<br />
La segunda tecnología sobresali<strong>en</strong>te sería la tecnología de<br />
transmisión inalámbrica, <strong>en</strong> todas sus variantes, que proporciona la base<br />
para poder ofrecer <strong>movilidad</strong>. Ésta ha crecido <strong>en</strong> importancia a medida<br />
que los avances tecnológicos han dado una mayor portabilidad a los<br />
equ<strong>ip</strong>os, sin que disminuya por ello las prestaciones de los mismos. Un<br />
ejemplo de la importancia que actualm<strong>en</strong>te está t<strong>en</strong>i<strong>en</strong>do la capacidad de<br />
<strong>movilidad</strong> sería el desarrollo de las redes de área local inalámbricas,<br />
WLAN, cuya pres<strong>en</strong>cia <strong>en</strong> el mercado de las RAL aum<strong>en</strong>ta de manera<br />
vertiginosa. El otro ejemplo clave sería la evolución de la telefonía móvil, y<br />
de toda la inversión que se ha realizado <strong>en</strong> el desarrollo de la tercera<br />
g<strong>en</strong>eración, por ejemplo UMTS, que permite ofrecer no sólo servicios de<br />
voz, sino también <strong>en</strong>vío de datos a velocidades razonables.<br />
De lo anterior podemos deducir la importancia que <strong>en</strong> un futuro va<br />
a t<strong>en</strong>er la converg<strong>en</strong>cia de estas dos tecnologías. Es decir, tanto la<br />
capacidad de poder ofrecer <strong>movilidad</strong> <strong>en</strong> redes basadas <strong>en</strong> TCP/IP, como la<br />
integración de la arquitectura IP <strong>en</strong> los sistemas de telefonía móvil.<br />
En este s<strong>en</strong>tido, la <strong>movilidad</strong> d<strong>en</strong>tro de una subred es un tema<br />
resuelto con las redes de área local inalámbricas com<strong>en</strong>tadas<br />
anteriorm<strong>en</strong>te. En esta línea se sigue trabajando hoy <strong>en</strong> día <strong>en</strong> cuestiones<br />
1
Introducción y Objetivos<br />
de seguridad y de calidad de servicio. Sin embargo la <strong>movilidad</strong> <strong>en</strong>tre<br />
subredes <strong>en</strong> una red con arquitectura TCP/IP pres<strong>en</strong>ta importantes<br />
dificultades como detallamos a continuación.<br />
Podemos tomar el ejemplo de las redes UMTS actuales. Cuando un<br />
terminal quiere realizar una comunicación de datos crea un contexto PDP<br />
(Packet Data Protocol) por el que adquiere una dirección IP. Sin embargo,<br />
los paquetes IP que transmite el terminal son <strong>en</strong>capsulados tanto cuando<br />
viajan por la red de acceso (UTRAN UMTS Radio Access Network), como<br />
cuando lo hac<strong>en</strong> por <strong>en</strong> la red de transporte troncal. Así, <strong>en</strong> la red de<br />
acceso los paquetes que llegan al RNC (Radio Network Controler) son<br />
<strong>en</strong>capsulados con un protocolo d<strong>en</strong>ominado GTP (GPRS Tunnelling<br />
Protocol), que ha su vez viaja sobre AAL2/ATM. En la red trocal los<br />
paquetes GTP suel<strong>en</strong> ser a transportados también sobre ATM, aunque aquí<br />
existe la posibilidad de hacerlo <strong>en</strong>capsulados <strong>en</strong> UDP sobre IP.<br />
Como observamos del ejemplo anterior, los sistemas de tercera<br />
g<strong>en</strong>eración actuales no están <strong>basado</strong>s <strong>en</strong> una arquitectura IP de manera<br />
nativa, requiri<strong>en</strong>do, por tanto, complejos y caros dispositivos.<br />
El sigui<strong>en</strong>te paso sería pues la converg<strong>en</strong>cia total <strong>en</strong>tre la<br />
arquitectura basada <strong>en</strong> IP y los sistemas de telefonía móvil. Es lo que se<br />
llama usualm<strong>en</strong>te sistemas 4G. Esto produciría b<strong>en</strong>eficios tanto para los<br />
usuarios como para los operadores. Algunos de estos serían:<br />
• Los sistemas de telefonía serían más baratos, debido a economías<br />
de escala que se producirían al ser dispositivos similares a los de<br />
red fija ya exist<strong>en</strong>tes.<br />
• Se podrían ofrecer un conjunto de nuevos servicio <strong>basado</strong>s <strong>en</strong> las<br />
capacidades de la red IP, como por ejemplo los <strong>basado</strong>s <strong>en</strong><br />
transmisión ‘<strong>multicast</strong>’ o ‘anycast’.<br />
• La administración de las redes de telefonía móvil sería más s<strong>en</strong>cilla,<br />
ahorrando costes de mant<strong>en</strong>imi<strong>en</strong>to.<br />
• Como IP es un protocolo que puede funcionar sobre cualquier<br />
tecnología de capa 2, para los operadores sería mucho más s<strong>en</strong>cillo<br />
2
Introducción Objetivos<br />
integrar otras tecnologías de acceso, como WLAN, con las<br />
tecnologías celulares de área amplia.<br />
Sin embargo, la arquitectura basada <strong>en</strong> IP también ti<strong>en</strong>e<br />
importantes limitaciones. Dos destacan claram<strong>en</strong>te de las demás:<br />
• Dificultad para poder ofrecer QoS, debido a la naturaleza best ‘<br />
effort’ del servicio que ofrece el protocolo IP.<br />
• Dificultad para poder ofrecer <strong>movilidad</strong>, debido a que el protocolo<br />
se diseño asumi<strong>en</strong>do que los dispositivos eran fijos.<br />
Para poder ofrecer calidad de servicio (QoS) se requiere del control<br />
de una serie de parámetros como pued<strong>en</strong> ser la pérdida de paquetes, el<br />
retardo de los mismos, o la sincronización de distintos flujos. Algunos de<br />
estos aspectos son controlados por el terminal a través de protocolos<br />
extremo a extremo bi<strong>en</strong> conocidos. Así, por ejemplo, el protocolo TCP se<br />
<strong>en</strong>carga de recuperar los errores, mi<strong>en</strong>tras que el RTP [RFC 1989] se<br />
utiliza para controlar el jitter y para sincronizar los distintos flujos. Sin<br />
embargo ninguno de las protocolos extremo a extremo puede garantizar el<br />
retardo que experim<strong>en</strong>ta un paquete <strong>en</strong> atravesar la red, aspecto<br />
fundam<strong>en</strong>tal para poder ofrecer aplicaciones de tiempo real.<br />
La solución a este problema pasa, evid<strong>en</strong>tem<strong>en</strong>te, por que la red<br />
sea capaz de ofrecer un mejor servicio, más allá de la simple <strong>en</strong>trega de<br />
paquetes. Existe una gran cantidad de trabajo realizado es este campo.<br />
Tradicionalm<strong>en</strong>te las soluciones se divid<strong>en</strong> <strong>en</strong> soluciones de ‘Servicios<br />
Integrados’ (IntServ) [RFC 2215], <strong>en</strong> los que se asegura QoS para cada flujo<br />
individual, o bi<strong>en</strong> ‘Servicios Difer<strong>en</strong>ciados’ (DiffServ) [RFC 2475], que busca<br />
una difer<strong>en</strong>ciación de servicios de una manera escalable. Los servicios<br />
integrados ti<strong>en</strong><strong>en</strong> problemas de escalabilidad, al hacerse necesario que<br />
cada router disponga de información de cada flujo que transmite. Además<br />
es necesario un protocolo que reserve los recursos a lo largo de al ruta (por<br />
ejemplo RSVP [RFC 2205]) y que refresque estas reservas cada cierto<br />
tiempo, lo que añade sobrecarga <strong>en</strong> al red. Por el contrario los servicios<br />
3
Introducción y Objetivos<br />
difer<strong>en</strong>ciados se basan <strong>en</strong> una configuración de QoS estática de manera<br />
que no pued<strong>en</strong> garantizar la calidad extremo a extremo.<br />
En los trabajos que se están desarrollando para los nuevos<br />
sistemas móviles de cuarta g<strong>en</strong>eración, y que se basarán completam<strong>en</strong>te<br />
<strong>en</strong> IP, la t<strong>en</strong>d<strong>en</strong>cia es el uso de las dos soluciones de manera combinada.<br />
En la red de acceso, donde aparec<strong>en</strong> los princ<strong>ip</strong>ales problemas de<br />
recursos, se utiliza IntServ, mi<strong>en</strong>tras que <strong>en</strong> el núcleo, donde es más<br />
s<strong>en</strong>cillo sobredim<strong>en</strong>sionar la red, se emplea DiffServ. Esta solución mixta<br />
proporciona un bu<strong>en</strong> compromiso <strong>en</strong>tre coste y efici<strong>en</strong>cia [WIS02].<br />
El segundo problema fundam<strong>en</strong>tal de la arquitectura basada <strong>en</strong> IP<br />
es la capacidad para ofrecer <strong>movilidad</strong>. Esta arquitectura se diseñó<br />
asumi<strong>en</strong>do que los hosts eran estacionarios, y se utiliza la dirección<br />
destino IP, no sólo para id<strong>en</strong>tificar tanto al nodo como a la conexión TCP,<br />
sino también para <strong>en</strong>caminar los paquetes. Por tanto, y según el protocolo<br />
IP clásico, cuando un móvil, que posee una dirección IP pert<strong>en</strong>eci<strong>en</strong>te a la<br />
subred donde se <strong>en</strong>cu<strong>en</strong>tra, realiza un handover a una subred difer<strong>en</strong>te<br />
dejaría de recibir paquetes, pues estos se <strong>en</strong>caminarían hacia la red<br />
correspondi<strong>en</strong>te con su dirección IP.<br />
La solución de cambiar de dirección IP por parte del nodo móvil<br />
ocasionaría el cierre de las conexiones TCP, ya que este protocolo utiliza,<br />
junto con los números de puerto, las direcciones IP orig<strong>en</strong> y destino para<br />
definir una conexión. La propuesta de realizar un <strong>en</strong>caminami<strong>en</strong>to por<br />
host a los nodos móviles, aunque posible, claram<strong>en</strong>te no es escalable.<br />
La solución más ext<strong>en</strong>dida es el protocolo Mobile IP [RFC 3344],<br />
que soluciona el problema asignando al nodo móvil dos direcciones IP. La<br />
primera se utiliza como id<strong>en</strong>tificador perman<strong>en</strong>te del nodo, mi<strong>en</strong>tras que la<br />
segunda es una dirección temporal <strong>en</strong>rutable. Así un ag<strong>en</strong>te situado <strong>en</strong> la<br />
red orig<strong>en</strong> del nodo móvil almac<strong>en</strong>a esta segunda dirección temporal, que<br />
utilizará para re<strong>en</strong>caminar los paquetes dirigidos al nodo móvil utilizando<br />
un túnel.<br />
4
Introducción Objetivos<br />
El protocolo Mobile IP es fuerte y robusto, y parece una bu<strong>en</strong>a<br />
solución a la hora de proporcionar <strong>movilidad</strong> <strong>en</strong>tre difer<strong>en</strong>tes operadores.<br />
Así <strong>en</strong> el sistema de 3G CDMA2000 promovido por 3GPP2 <strong>en</strong> EE.UU. se<br />
utiliza el protocolo Mobile IP para ofrecer <strong>movilidad</strong> <strong>en</strong>tre distintas redes de<br />
acceso radio, aunque d<strong>en</strong>tro de ellas la <strong>movilidad</strong> se sigue implem<strong>en</strong>tando<br />
basándose <strong>en</strong> ATM.<br />
En realidad, el protocolo Mobile IP ti<strong>en</strong>e importantes impedim<strong>en</strong>tos<br />
que lo limitan <strong>en</strong> exceso. Los princ<strong>ip</strong>ales serían:<br />
• Los handovers van a ser l<strong>en</strong>tos, incapacitando al protocolo para<br />
aplicaciones de tiempo real. El motivo es que el nodo móvil debe<br />
señalizar el cambio de dirección a su ag<strong>en</strong>te, lo que puede<br />
consumir mucho tiempo si el nodo móvil se <strong>en</strong>cu<strong>en</strong>tra alejado de él.<br />
• La necesidad de este intercambio de m<strong>en</strong>sajes provoca una<br />
sobrecarga de la red, que se increm<strong>en</strong>ta, como <strong>en</strong> el caso anterior,<br />
a medida que aum<strong>en</strong>ta la distancia <strong>en</strong>tre el nodo móvil y su ag<strong>en</strong>te.<br />
En la actualidad se han realizado varias propuestas para resolver<br />
los problemas m<strong>en</strong>cionados. La idea básica consiste <strong>en</strong> dividir la red <strong>en</strong><br />
regiones o dominios. Ahora la <strong>movilidad</strong> <strong>en</strong>tre dominios, poco frecu<strong>en</strong>te, se<br />
sigue realizando con el protocolo Mobile IP, pero d<strong>en</strong>tro de un dominio se<br />
buscan soluciones particulares para poder ofrecer <strong>movilidad</strong> con altas<br />
prestaciones <strong>en</strong> cuanto a tiempo de handover.<br />
Podemos realizar una s<strong>en</strong>cilla clasificación de las propuestas de<br />
micro-<strong>movilidad</strong> aparecidas <strong>en</strong> la bibliografía:<br />
• Esquemas de ag<strong>en</strong>tes de <strong>movilidad</strong> jerárquicos, donde se divide la<br />
red <strong>en</strong> dominios cada vez más pequeños, de manera que un<br />
movimi<strong>en</strong>to d<strong>en</strong>tro de un dominio es transpar<strong>en</strong>te para los<br />
superiores.<br />
• Esquemas de <strong>en</strong>caminami<strong>en</strong>to <strong>basado</strong> <strong>en</strong> host (HBR), <strong>basado</strong>s <strong>en</strong><br />
que el <strong>en</strong>caminami<strong>en</strong>to del dominio se realiza <strong>en</strong> función de la<br />
dirección única de cada host.<br />
5
Introducción y Objetivos<br />
Así el futuro de los sistemas de telefonía móvil, d<strong>en</strong>ominado de<br />
cuarta g<strong>en</strong>eración 4G, estará <strong>basado</strong> completam<strong>en</strong>te <strong>en</strong> IP. En este<br />
esc<strong>en</strong>ario es donde los sistemas de micro <strong>movilidad</strong> IP, base de esta Tesis<br />
Doctoral, cobrarán una especial importancia, como mecanismo que<br />
complem<strong>en</strong>tará y mejorará de las prestaciones del protocolo Mobile IP.<br />
1.2 OBJETIVOS DE LA TESIS<br />
La realización de la pres<strong>en</strong>te Tesis se puede considerar como una<br />
contribución al estudio y evaluación de los sistemas de micro-<strong>movilidad</strong> IP.<br />
Como hemos com<strong>en</strong>tado anteriorm<strong>en</strong>te los sistemas de micro-<strong>movilidad</strong><br />
publicados hasta la fecha pued<strong>en</strong> dividirse <strong>en</strong> dos grandes grupos:<br />
aquellos <strong>basado</strong>s <strong>en</strong> <strong>en</strong>rutami<strong>en</strong>to por host, y aquellos que utilizan<br />
soluciones jerárquicas. En esta Tesis Doctoral se pres<strong>en</strong>ta un sistema de<br />
micro-<strong>movilidad</strong> novedoso, que podría <strong>en</strong>cuadrarse <strong>en</strong> un tercer grupo:<br />
sistemas <strong>basado</strong>s <strong>en</strong> transmisión <strong>multicast</strong>.<br />
Por tanto, el objetivo princ<strong>ip</strong>al de la Tesis es desarrollar un sistema<br />
de micro-<strong>movilidad</strong> viable, que utilice las capacidades de transmisión<br />
<strong>multicast</strong> de las redes IP actuales, y que simultáneam<strong>en</strong>te también<br />
incorpore innovaciones que mejor<strong>en</strong> las prestaciones durante el handover.<br />
Hasta alcanzar este objetivo princ<strong>ip</strong>al, <strong>en</strong> el desarrollo de la Tesis se<br />
ha llevado a cabo un conjunto de tareas que también pued<strong>en</strong> considerarse<br />
como objetivos. En primer lugar, se aporta una visión g<strong>en</strong>eral de las<br />
princ<strong>ip</strong>ales contribuciones <strong>en</strong> el área de los sistemas de <strong>movilidad</strong> IP.<br />
Puesto que este es un campo de constante innovación y relativam<strong>en</strong>te<br />
nuevo, es fundam<strong>en</strong>tal realizar un comp<strong>en</strong>dio de las aportaciones que<br />
hasta el mom<strong>en</strong>to se han realizado <strong>en</strong> otros trabajos.<br />
El desarrollo del sistema de micro-<strong>movilidad</strong> ha de ser realizado<br />
defini<strong>en</strong>do perfectam<strong>en</strong>te los m<strong>en</strong>sajes que se utilic<strong>en</strong>. Puesto que un<br />
objetivo prioritario es hacer que este esquema sea completam<strong>en</strong>te<br />
compatible con el protocolo Mobile IP, se utilizarán las ext<strong>en</strong>siones<br />
6
Introducción Objetivos<br />
definidas tanto <strong>en</strong> la [RFC 3344] como <strong>en</strong> distintos trabajos el IETF que a<br />
día de hoy están <strong>en</strong> progreso.<br />
Para no limitar el sistema de micro-<strong>movilidad</strong> pres<strong>en</strong>tado, un<br />
objetivo es realizar el diseño de manera que sea perfectam<strong>en</strong>te escalable.<br />
Otro objetivo es desarrollar los mecanismos de seguridad necesarios,<br />
sigui<strong>en</strong>do las últimas propuestas que se han publicado sobre este tema.<br />
El sistema de micro-<strong>movilidad</strong> que pres<strong>en</strong>tamos se basa <strong>en</strong> la<br />
<strong>en</strong>capsulación <strong>en</strong> paquetes IP <strong>multicast</strong>. Marcamos como objetivo el<br />
estudiar tanto la tecnología <strong>multicast</strong> <strong>en</strong> g<strong>en</strong>eral, como los protocolos de<br />
<strong>en</strong>rutami<strong>en</strong>to <strong>multicast</strong> <strong>en</strong> particular. El fin es, primero, asegurarse que es<br />
una solución adecuada, y que ofrece v<strong>en</strong>tajas con respecto a otras<br />
soluciones de micro-<strong>movilidad</strong>, y segundo, seleccionar el protocolo más<br />
adecuado a nuestro sistema.<br />
Se realizará un estudio del proceso de handover <strong>en</strong> redes IP,<br />
dividi<strong>en</strong>do la lat<strong>en</strong>cia total <strong>en</strong> difer<strong>en</strong>tes compon<strong>en</strong>tes. Se analizarán los<br />
distintos esquemas de handover propuestos <strong>en</strong> la bibliografía, realizando<br />
una clasificación y obt<strong>en</strong>i<strong>en</strong>do conclusiones. El objetivo es estudiar todos<br />
los parámetros que intervi<strong>en</strong><strong>en</strong> <strong>en</strong> el proceso de handover, con el fin de<br />
poder buscar soluciones adaptadas a nuestro sistema de micro-<strong>movilidad</strong><br />
IP. Así, para buscar los puntos débiles de los esquemas de handover<br />
estandarizados, se analizarán las prestaciones del handover del protocolo<br />
Mobile IP. La evaluación se va a realizar tanto por simulación como<br />
realizando un banco de pruebas. También se evaluarán las prestaciones de<br />
los princ<strong>ip</strong>ales sistemas de micro-<strong>movilidad</strong> pres<strong>en</strong>tes <strong>en</strong> la bibliografía.<br />
Un objetivo básico <strong>en</strong> la pres<strong>en</strong>te Tesis Doctoral es el diseño de<br />
esquemas de handover que cumplan unos requisitos tanto de tiempo de<br />
interrupción como de pérdida de paquetes. En este s<strong>en</strong>tido se<br />
desarrollarán esquemas suaves, donde no se pierd<strong>en</strong> paquetes, y también<br />
esquemas rápidos, donde el interés se ha c<strong>en</strong>trado <strong>en</strong> lograr un tiempo de<br />
interrupción mínimo. Asimismo se van a diseñar soluciones tanto para<br />
sistemas donde el nodo móvil ti<strong>en</strong>e capacidad de comunicarse<br />
simultáneam<strong>en</strong>te con dos estaciones base, como para aquellos donde el<br />
7
Introducción y Objetivos<br />
nodo ti<strong>en</strong>e que cortar la comunicación con la estación previa antes de<br />
poder establecerla con la nueva.<br />
Por último un objetivo importante es la realización de un estudio de<br />
las prestaciones de los esquemas de handover propuestos para el sistema<br />
de micro-<strong>movilidad</strong> diseñado. Se ha optado por una evaluación analítica<br />
que será validada con otras publicaciones similares realizadas para otros<br />
sistemas de micro-<strong>movilidad</strong>.<br />
1.3 ORGANIZACIÓN DE LA MEMORIA<br />
Después de realizar una introducción a las princ<strong>ip</strong>ales cuestiones<br />
que han motivado la pres<strong>en</strong>te Tesis, así como una descr<strong>ip</strong>ción de sus<br />
objetivos, el resto de la memoria se organiza de la sigui<strong>en</strong>te forma.<br />
En el Capítulo 2 se describe las princ<strong>ip</strong>ales contribuciones<br />
realizadas sobre el tema de la <strong>movilidad</strong> <strong>en</strong> redes IP. Se ha descrito con<br />
mayor profundidad el protocolo Mobile IP, al ser la base de la mayoría de<br />
las propuestas actuales. También se han clasificado y descrito los sistemas<br />
de micro-<strong>movilidad</strong> donde se <strong>en</strong>cuadra el trabajo realizado.<br />
En el Capítulo 3 se pres<strong>en</strong>ta el sistema de micro-<strong>movilidad</strong> <strong>basado</strong><br />
<strong>en</strong> <strong>multicast</strong> que proponemos <strong>en</strong> esta Tesis Doctoral. En primer lugar se<br />
describe la arquitectura de la red propuesta. El sigui<strong>en</strong>te punto se realiza<br />
una descr<strong>ip</strong>ción del modo de funcionami<strong>en</strong>to del protocolo de micro<strong>movilidad</strong>,<br />
distingui<strong>en</strong>do difer<strong>en</strong>tes mecanismos como el registro, la<br />
transmisión de datos, la escalabilidad, etc. En todo mom<strong>en</strong>to se muestra la<br />
compatibilidad con el protocolo Mobile IP. Se realiza un estudio de la<br />
seguridad <strong>en</strong> el sistema propuesto, analizando la problemática de la<br />
seguridad <strong>en</strong> redes móviles. También se muestran los formatos de todos<br />
los m<strong>en</strong>sajes definidos para el sistema propuesto, que se han diseñado de<br />
acuerdo a las recom<strong>en</strong>daciones del propio Mobile IP [RFC 3344], como de<br />
algunas propuestas actualm<strong>en</strong>te <strong>en</strong> investigación. Debido a que nuestro<br />
sistema se basa <strong>en</strong> la transmisión <strong>multicast</strong>, se ha realizado un estudio<br />
8
Introducción Objetivos<br />
para seleccionar la tecnología que más se ajusta a nuestras necesidades.<br />
Asimismo se describe como puede incorporarse el protocolo PIM-SM / SSM<br />
a nuestro sistema de micro-<strong>movilidad</strong>. Para finalizar se ha realizado una<br />
comparación cualitativa del sistema propuesto con las difer<strong>en</strong>tes<br />
soluciones de micro-<strong>movilidad</strong> que se mostraron <strong>en</strong> el capítulo anterior.<br />
Con el Capítulo 4 comi<strong>en</strong>za el segundo gran bloque <strong>en</strong> que<br />
podríamos dividir esta Tesis, y que trata sobre el proceso de handover. En<br />
este capítulo se realiza un estudio del proceso de handover <strong>en</strong> redes IP<br />
móviles. También se ha realizado una clasificación de las soluciones de<br />
handover exist<strong>en</strong>tes <strong>en</strong> la bibliografía, prestando especial at<strong>en</strong>ción a los<br />
handovers propuestos para difer<strong>en</strong>tes sistemas de micro-<strong>movilidad</strong>, así<br />
como aquellos handovers que se basan <strong>en</strong> la utilización de transmisión<br />
<strong>multicast</strong>.<br />
El princ<strong>ip</strong>al inconv<strong>en</strong>i<strong>en</strong>te del protocolo Mobile IP son sus pobres<br />
prestaciones durante el handover. En el Capítulo 5 se realiza una<br />
evaluación de las prestaciones del handover <strong>en</strong> las difer<strong>en</strong>tes redes IP<br />
móviles, utilizando herrami<strong>en</strong>tas de simulación. El trabajo se ha c<strong>en</strong>trado<br />
<strong>en</strong> analizar el protocolo Mobile IP, donde se ha distinguido la situación <strong>en</strong><br />
la que el nodo móvil se <strong>en</strong>cu<strong>en</strong>tra cerca de su red orig<strong>en</strong> (que hemos<br />
d<strong>en</strong>ominado handover cercano), y situaciones donde el nodo móvil se<br />
<strong>en</strong>cu<strong>en</strong>tra desplazado de ella (handover lejano). También se ha realizado<br />
una evaluación de los difer<strong>en</strong>tes esquemas de handover de sistemas de<br />
micro-<strong>movilidad</strong> pres<strong>en</strong>tados <strong>en</strong> el capítulo anterior. Para finalizar se ha<br />
realizado un banco de pruebas, donde se ha evaluado el comportami<strong>en</strong>to<br />
de un esquema de handover de Mobile IP bajo tráfico multimedia.<br />
En el Capítulo 6 se muestran cinco esquemas de handover<br />
difer<strong>en</strong>tes, propuestos para el sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong><br />
<strong>multicast</strong> pres<strong>en</strong>tado <strong>en</strong> el Capítulo 3. Las cinco soluciones aprovechan las<br />
facilidades de la transmisión <strong>multicast</strong>, y abarcan todo un abanico de<br />
posibilidades, tanto <strong>en</strong> lo refer<strong>en</strong>te a las capacidades que le ofrece la red<br />
(capacidad de comunicación simultanea con dos estaciones base o sólo con<br />
una), como <strong>en</strong> los requisitos del handover (pérdida nula de paquetes,<br />
lat<strong>en</strong>cia mínima, etc.). Se han propuesto nuevas ext<strong>en</strong>siones para los<br />
9
Introducción y Objetivos<br />
m<strong>en</strong>sajes que se diseñaron <strong>en</strong> el Capítulo 3, así como otros nuevos.<br />
Además se describe el mecanismo por el cual varios esquemas de handover<br />
pued<strong>en</strong> funcionar simultáneam<strong>en</strong>te <strong>en</strong> una misma red. Finalizamos el<br />
capítulo con una comparación de los esquemas propuestos.<br />
En el Capítulo 7 se ha realizado una evaluación analítica de las<br />
prestaciones de los cinco esquemas de handover descritos <strong>en</strong> el punto<br />
anterior. El fin es realizar una comparación de las difer<strong>en</strong>tes soluciones, a<br />
la vez que investigar la influ<strong>en</strong>cia de algunos parámetros de diseño, como<br />
puede ser el tamaño de los ‘buffers’. Los estudios se han c<strong>en</strong>trado <strong>en</strong> el<br />
número de paquetes perdidos debido al mecanismo de handover, así como<br />
el retardo adicional que se introduce <strong>en</strong> los paquetes que, por el modo de<br />
funcionami<strong>en</strong>to del esquema, deb<strong>en</strong> ser redireccionados o almac<strong>en</strong>ados.<br />
En el octavo y último capítulo se expon<strong>en</strong> las conclusiones finales,<br />
tanto del sistema de micro-<strong>movilidad</strong> y de los esquemas de handover<br />
propuestos, como de los resultados obt<strong>en</strong>idos. Además se apuntan las<br />
líneas futuras de trabajo.<br />
La memoria finaliza con las refer<strong>en</strong>cias bibliográficas citadas <strong>en</strong> el<br />
texto, ord<strong>en</strong>adas alfabéticam<strong>en</strong>te.<br />
Por último se incorporan dos anexos. El Anexo 1 conti<strong>en</strong>e una lista<br />
de los princ<strong>ip</strong>ales acrónimos utilizados, así como un glosario. El Anexo 2<br />
conti<strong>en</strong>e el desarrollo de algunas ecuaciones utilizadas <strong>en</strong> el capítulo 7,<br />
que se sacaron del mismo para facilitar la compr<strong>en</strong>sión del mismo.<br />
10
2. SISTEMAS DE MOVILIDAD EN REDES IP<br />
2.1 INTRODUCCIÓN<br />
Los protocolos IP [RFC 791], UDP [RFC768] y TCP [RFC793], base<br />
de la actual Internet, se diseñaron asumi<strong>en</strong>do que los sistemas finales<br />
eran estacionarios. Estos nodos se id<strong>en</strong>tifican de manera única por medio<br />
de una dirección que a su vez es utilizada, tanto para indicar la red a la<br />
que está conectado, como para una id<strong>en</strong>tificar las conexiones TCP<br />
establecidas. Es esta doble función de las direcciones IP, id<strong>en</strong>tificación y<br />
<strong>en</strong>caminami<strong>en</strong>to, la que causa dificultades para la integración de nodos<br />
móviles <strong>en</strong> la arquitectura original. En esta tesis <strong>en</strong>t<strong>en</strong>demos como nodo<br />
móvil a cualquier nodo que ti<strong>en</strong>e capacidad de cambiar su conexión de un<br />
<strong>en</strong>lace a otro, mant<strong>en</strong>i<strong>en</strong>do todas las comunicaciones exist<strong>en</strong>tes, y usando<br />
la misma dirección IP <strong>en</strong> su nuevo <strong>en</strong>lace.<br />
Los routers IP utilizan información cont<strong>en</strong>ida <strong>en</strong> la cabecera de los<br />
paquetes IP para realizar el <strong>en</strong>caminami<strong>en</strong>to de la información.<br />
Específicam<strong>en</strong>te, las decisiones de <strong>en</strong>caminami<strong>en</strong>to se toman <strong>en</strong> función<br />
de la parte de id<strong>en</strong>tificativo de red de la dirección IP destino, lo que<br />
provoca la necesidad de que todos los hosts conectados a un <strong>en</strong>lace deban<br />
t<strong>en</strong>er obligatoriam<strong>en</strong>te idéntico id<strong>en</strong>tificativo de red <strong>en</strong> su dirección IP. De<br />
esta manera si un host móvil cambia de situación y se conecta a un nuevo<br />
<strong>en</strong>lace, con un id<strong>en</strong>tificativo de red difer<strong>en</strong>te, no podrá recibir información,<br />
puesto que los paquetes dirigidos a él se <strong>en</strong>caminarán hacia el router que<br />
da conexión a la red indicada <strong>en</strong> su id<strong>en</strong>tificativo de red.<br />
Una solución sería realizar un <strong>en</strong>caminami<strong>en</strong>to <strong>basado</strong> <strong>en</strong> Host.<br />
Esto es, que las tablas de <strong>en</strong>caminami<strong>en</strong>to de los routers cont<strong>en</strong>gan<br />
información de cómo <strong>en</strong>caminar paquetes destinados a un nodo móvil. La<br />
escalabilidad de la solución, el número de routers implicados, y la<br />
seguridad, son algunas de las causas que la hac<strong>en</strong> inabordable aún <strong>en</strong> el<br />
11
Sistemas de Movilidad <strong>en</strong> redes IP<br />
caso de que solo se utilice <strong>en</strong> las situaciones <strong>en</strong> las que el nodo móvil no se<br />
<strong>en</strong>cu<strong>en</strong>tre <strong>en</strong> su red orig<strong>en</strong>.<br />
Esta red orig<strong>en</strong> se d<strong>en</strong>omina comúnm<strong>en</strong>te Home Network, y la<br />
podemos <strong>en</strong>t<strong>en</strong>der como la red <strong>en</strong> el que un nodo debería estar localizado;<br />
esto es, la red que ti<strong>en</strong>e asignado el mismo id<strong>en</strong>tificativo de red que el que<br />
existe <strong>en</strong> la dirección IP del nodo. En contraposición a esto nos<br />
<strong>en</strong>contramos con la Foreign Network que es cualquier otra red difer<strong>en</strong>te a<br />
la Home Network y que por tanto su id<strong>en</strong>tificativo de red difiere del de la<br />
red IP del nodo.<br />
Otra posible solución sería simplem<strong>en</strong>te cambiar la dirección IP del<br />
nodo <strong>en</strong> el mom<strong>en</strong>to <strong>en</strong> que cambia de un <strong>en</strong>lace a otro. Sin embargo el<br />
protocolo TCP utiliza, junto con los números de puerto, las direcciones IP<br />
de la fu<strong>en</strong>te y destino para id<strong>en</strong>tificar la conexión, y no permite el cambio<br />
de las direcciones IP durante la misma. La solución de rediseñar<br />
completam<strong>en</strong>te el protocolo TCP para permitir que los nodos móviles<br />
actualic<strong>en</strong> su dirección mi<strong>en</strong>tras dura su conexión no se considera<br />
apropiada, a pesar de ser una posibilidad interesante desde el punto de<br />
vista de la investigación, ya que implicaría una modificación de millones de<br />
nodos. Aún así <strong>en</strong> [SNO00] se propone modificar el protocolo de transporte<br />
TCP [RFC 793], de manera que una conexión ya establecida pueda ser<br />
susp<strong>en</strong>dida por un extremo y reactivada con otra dirección IP.<br />
Aún <strong>en</strong> este supuesto existiría otro contratiempo adicional,<br />
consist<strong>en</strong>te <strong>en</strong> el mecanismo necesario para averiguar la dirección del<br />
nodo móvil con qui<strong>en</strong> queremos comunicarnos. Al t<strong>en</strong>er una dirección IP<br />
cambiante, los servidores DNS deberían ser actualizados constantem<strong>en</strong>te<br />
con los problemas de sobrecarga, sincronización y de seguridad que ello<br />
conlleva. En este campo B. Awerbuch propuso <strong>en</strong> 1991 un servicio de<br />
directorio de localización distribuido [AWE91].<br />
Por tanto la <strong>movilidad</strong> de los nodos <strong>en</strong> la arquitectura TCP/IP<br />
ocasiona los sigui<strong>en</strong>tes contratiempos:<br />
12
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
• Si el nodo adquiere una nueva dirección IP, el id<strong>en</strong>tificativo de la<br />
conexión TCP cambia, lo que ocasiona que todas las conexiones<br />
TCP que ti<strong>en</strong>e abiertas el nodo se pierdan.<br />
• Si el nodo manti<strong>en</strong>e su dirección IP cuando cambia de red el<br />
sistema de <strong>en</strong>caminami<strong>en</strong>to no será capaz de hacer llegar los<br />
paquetes a la nueva localización.<br />
Exist<strong>en</strong> varias soluciones para el problema anteriorm<strong>en</strong>te expuesto<br />
[ALT02]. La primera sería solucionar el problema <strong>en</strong> un nivel superior,<br />
típicam<strong>en</strong>te <strong>en</strong> el nivel de aplicación. En este s<strong>en</strong>tido todas las propuestas<br />
giran <strong>en</strong> torno al protocolo SIP [RFC 2543] que está ganando rápidam<strong>en</strong>te<br />
aceptación como protocolo de control <strong>en</strong> aplicaciones multimedia y de<br />
telefonía <strong>en</strong> Internet.<br />
Como ya se ha com<strong>en</strong>tado, exist<strong>en</strong> también algunos estudios, como<br />
[CAC94], [BAL96] o [STA98] que defi<strong>en</strong>d<strong>en</strong> la necesidad de modificar el<br />
protocolo de transporte TCP para adecuarlo a un <strong>en</strong>torno donde los nodos<br />
son móviles. Básicam<strong>en</strong>te se c<strong>en</strong>tran <strong>en</strong> la limitación del TCP, que asume<br />
que los paquetes perdidos lo son únicam<strong>en</strong>te debido a la exist<strong>en</strong>cia de<br />
congestión <strong>en</strong> la red. En [SNO00] se propone una arquitectura <strong>en</strong> la que la<br />
<strong>movilidad</strong> se maneja como un servicio extremo a extremo, y es gestionada<br />
por el nivel de Transporte de manera que se realiza una modificación de<br />
los protocolos de este nivel mant<strong>en</strong>i<strong>en</strong>do invariable el protocolo de Red IP.<br />
Sin embargo es la tercera solución, consist<strong>en</strong>te <strong>en</strong> abordar el<br />
problema de la <strong>movilidad</strong> directam<strong>en</strong>te <strong>en</strong> el Nivel de Red, la que se está<br />
desarrollando con más fuerza. La princ<strong>ip</strong>al v<strong>en</strong>taja es que este mecanismo<br />
hace que el problema de la <strong>movilidad</strong> sea completam<strong>en</strong>te transpar<strong>en</strong>te a<br />
los niveles superiores (nivel de transporte y por supuesto nivel de<br />
aplicación). En este s<strong>en</strong>tido se han realizado numerosas propuestas. La<br />
mayoría se basan <strong>en</strong> una arquitectura de direcciones <strong>en</strong> dos niveles, de tal<br />
manera que existe una dirección perman<strong>en</strong>te y otra temporal que cambia<br />
<strong>en</strong> función de la red <strong>en</strong> la que se <strong>en</strong>cu<strong>en</strong>tra situada el nodo móvil.<br />
13
Sistemas de Movilidad <strong>en</strong> redes IP<br />
En [BHA96] se realiza un estudio de los princ<strong>ip</strong>ales aspectos que<br />
permit<strong>en</strong> realizar una clasificación de las difer<strong>en</strong>tes soluciones de Nivel de<br />
Red propuestas: los compon<strong>en</strong>tes específicos que se añad<strong>en</strong> a la<br />
arquitectura de Internet, los mecanismos que se propon<strong>en</strong> para realizar<br />
una traducción de la dirección perman<strong>en</strong>te a la dirección temporal<br />
asociada y la política empleada para t<strong>en</strong>er actualizada la información de<br />
localización del nodo móvil. En la sigui<strong>en</strong>te figura se muestra los<br />
compon<strong>en</strong>tes de la arquitectura g<strong>en</strong>érica propuesta, que puede emplearse<br />
para comparar las difer<strong>en</strong>tes soluciones particulares pres<strong>en</strong>tadas <strong>en</strong> la<br />
bibliografía.<br />
Ag<strong>en</strong>te de<br />
traducción de<br />
direcciones<br />
f<br />
Directorio de<br />
Localización<br />
Home Network<br />
Nodo móvil <strong>en</strong><br />
una Foreign<br />
Network<br />
Fu<strong>en</strong>te<br />
Ag<strong>en</strong>te de Envío<br />
g<br />
Foreign Network<br />
f: Home Address → Forwarding Address<br />
g: Forwarding Address → Home Address<br />
Figura 2.1 Arquitectura g<strong>en</strong>érica<br />
Según este esquema al nodo móvil ti<strong>en</strong>e asignada una dirección<br />
permante (Home Address) utilizada cuando el nodo está situado <strong>en</strong> la red a<br />
la que está asignado (Home Network). Además de forma temporal y cuando<br />
está localizado <strong>en</strong> una red difer<strong>en</strong>te se utiliza una segunda dirección,<br />
d<strong>en</strong>ominada Forwarding Address, que pert<strong>en</strong>ece a un ag<strong>en</strong>te de <strong>en</strong>vío.<br />
Existe un Ag<strong>en</strong>te de Traducción de Direcciones que se <strong>en</strong>carga de<br />
modificar los paquetes de tal manera que puedan ser <strong>en</strong>caminados hacia<br />
14
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
el ag<strong>en</strong>te de <strong>en</strong>vío. El compon<strong>en</strong>te que almac<strong>en</strong>a la asociación <strong>en</strong>tre las<br />
direcciones perman<strong>en</strong>te y temporal de cada nodo móvil se d<strong>en</strong>omina<br />
Directorio de Localización. Una solución c<strong>en</strong>tralizada para la<br />
implem<strong>en</strong>tación de este directorio no es realizable <strong>en</strong> una red donde el<br />
número de nodos es elevado. Exist<strong>en</strong> trabajos [ANA93] donde se propon<strong>en</strong><br />
modelos de directorios <strong>en</strong> función de los patrones de acceso, aunque no<br />
son directam<strong>en</strong>te aplicables a una red como Internet al no t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta<br />
factores como la seguridad. Una solución ampliam<strong>en</strong>te aceptada, aunque<br />
no la única, es que exista <strong>en</strong> cada Home Network un compon<strong>en</strong>te de<br />
direcctorio <strong>en</strong>cargado de mant<strong>en</strong>er las asociaciones de los nodos que<br />
pert<strong>en</strong>ec<strong>en</strong> a dicha red.<br />
La operación de traducción de direcciones puede realizarse de<br />
diversas formas, aunque tradicionalm<strong>en</strong>te se utilizan princ<strong>ip</strong>alm<strong>en</strong>e dos<br />
soluciones: Encapsulación o Loose Source Routing (LSR).<br />
• Encapsulación: Consiste <strong>en</strong> añadir una nueva cabecera al<br />
comi<strong>en</strong>zo del datagrama original. Esta nueva cabecera conti<strong>en</strong>e<br />
como dirección destino la del ag<strong>en</strong>te de <strong>en</strong>vío, mi<strong>en</strong>tras que se<br />
manti<strong>en</strong>e la dirección del nodo móvil perman<strong>en</strong>te como dirección<br />
destino de la cabecera original interior. En la actualidad exist<strong>en</strong><br />
diversosas mecanismos de <strong>en</strong>capsulación normalizados:<br />
Encapsulación IP sobre IP [RFC2003], <strong>en</strong>capsulación mínima<br />
[RFC2004] y <strong>en</strong>capsulación de <strong>en</strong>caminami<strong>en</strong>to g<strong>en</strong>érica (GRE)<br />
[RFC1701], aunque el primero es el más utilizado.<br />
• Loose Source Routing (LSR): LSR es una opción que permite<br />
especificar una lista de direcciones de tal manera que los routers<br />
<strong>en</strong>rutarán los datagramas hacia todas las direcciones una tras<br />
otra. Cuando un datagrama llega a un destino, éste modifica la<br />
dirección destino con la sigui<strong>en</strong>te dirección de la lista y modifica un<br />
puntero utilizado para indicar a los destinatarios la sigui<strong>en</strong>te<br />
dirección.<br />
Además de estas soluciones han aparecido algunos trabajos que<br />
utilizan las características de la transmisión <strong>multicast</strong> para lograr las<br />
15
Sistemas de Movilidad <strong>en</strong> redes IP<br />
necesidades de la <strong>movilidad</strong> de los nodos. Estas soluciones varían <strong>en</strong>tre<br />
seguir mant<strong>en</strong>i<strong>en</strong>do la arquitectura de direcciones de dos niveles hasta<br />
directam<strong>en</strong>te asignar unicam<strong>en</strong>te una dirección <strong>multicast</strong> a cada nodo<br />
móvil. El sistema de <strong>movilidad</strong> propuesto <strong>en</strong> esta tesis se puede <strong>en</strong>cuadrar<br />
d<strong>en</strong>tro de este grupo de soluciones.<br />
Es importante destacar aquí que los difer<strong>en</strong>tes compon<strong>en</strong>tes que<br />
aparec<strong>en</strong> (Ag<strong>en</strong>te de Traducción de Direcciones, Ag<strong>en</strong>te de Envío y<br />
Directorio de Localización) sólo repres<strong>en</strong>tan funciones que necesitan ser<br />
implem<strong>en</strong>tadas, no elem<strong>en</strong>tos físicos que deb<strong>en</strong> ser instaladas <strong>en</strong> la red.<br />
Así las difer<strong>en</strong>tes soluciones que se han propuesto <strong>en</strong> la bibliografía varían<br />
considerablem<strong>en</strong>te de unas a otras, lo que da muestra del alto grado de<br />
flexibilidad exist<strong>en</strong>te.<br />
A continuación se pres<strong>en</strong>tan las soluciones de <strong>movilidad</strong> <strong>en</strong> redes<br />
IP que se consideran más significativas. En el punto 2.2 se muestran<br />
algunos de los primeros trabajos pres<strong>en</strong>tados: Esquema de Columbia<br />
[IOA91], esquema Sony [TER91], y esquemas <strong>basado</strong>s <strong>en</strong> LSR [PER94]. El<br />
punto 2.3 se c<strong>en</strong>tra <strong>en</strong> el protocolo Mobile IP [RFC 3344] com<strong>en</strong>tándose<br />
con cierto detalle pues actualm<strong>en</strong>te es la base y el punto de comparación<br />
de todos los estudios realizados. Además se com<strong>en</strong>tarán algunas de las<br />
propuestas de mejora de este protocolo publicadas reci<strong>en</strong>tem<strong>en</strong>te, como la<br />
optimización de ruta o el registro regional. En el punto 2.4 se estudian<br />
algunos sistemas que se han diseñado para solucionar las limitaciones de<br />
Mobile IP basándose <strong>en</strong> el concepto de micro<strong>movilidad</strong>. El punto 2.5<br />
detalla los dos estudios que se han realizado para ofrecer capacidad de<br />
<strong>movilidad</strong> a los nodos basándose <strong>en</strong> las capacidades de la transmisión<br />
<strong>multicast</strong> [SES97], [MYS97], [MYS98]. En el punto 2.6 detalla los trabajos<br />
que se están realizando para ofrecer <strong>movilidad</strong> <strong>en</strong> redes basadas <strong>en</strong> el<br />
protocolo IPv6. Para finalizar, <strong>en</strong> el punto 2.7 se estudian las propuestas<br />
que basan <strong>en</strong> realizar la gestión de la <strong>movilidad</strong> <strong>en</strong> el nivel de aplicación<br />
[WED99], [SCH00].<br />
16
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
2.2 PRIMEROS TRABAJOS<br />
A continuación van a describirse, muy brevem<strong>en</strong>te, algunos de los<br />
primeros trabajos pres<strong>en</strong>tados para ofrecer <strong>movilidad</strong> <strong>en</strong> redes TCP/IP. No<br />
se int<strong>en</strong>ta ofrecer una visión exhaustiva de todos los sistemas que se<br />
propusieron sino, simplem<strong>en</strong>te, mostrar la gran flexibilidad exist<strong>en</strong>te<br />
mostrando las difer<strong>en</strong>tes t<strong>en</strong>d<strong>en</strong>cias que han sido más refer<strong>en</strong>ciadas. Así,<br />
por ejemplo, el protocolo IMHP [PER94b], [JOH94] y los primeros trabajos<br />
de Perkins [PER94] no se com<strong>en</strong>tan, pues son la base del protocolo Mobile<br />
IP [RFC 3344] que se muestran con más detalle <strong>en</strong> el punto 2.3.<br />
Comparaciones más profundas sobre estos primeros esquemas pued<strong>en</strong><br />
<strong>en</strong>contrarse <strong>en</strong> [MYL93] o el ya m<strong>en</strong>cionado [BHA96].<br />
Los esquemas que se van a com<strong>en</strong>tar son: esquema de Columbia<br />
[IOA91], [IOA93]; Esquema Sony [TER91], [TER93], [TER94]; y esquemas<br />
<strong>basado</strong>s <strong>en</strong> LSR [PER94].<br />
2.2.1 Esquema de Columbia<br />
El esquema propuesto por Ioannidis [IOA91],[IOA93] está diseñado<br />
para ofrecer <strong>movilidad</strong> a los usuarios <strong>en</strong> un <strong>en</strong>torno de campus. La técnica<br />
básica consiste <strong>en</strong> la creación de una subred virtual de manera que a cada<br />
nodo móvil se le asigna una dirección d<strong>en</strong>tro de esta subred.<br />
Existe un grupo de routers (Mobile Support Routers MSR) que<br />
anuncian la alcanzabilidad de la subred al resto de la red de campus<br />
creando la ilusión de que la subred virtual de nodos móviles es una red<br />
real conectada al resto de la red por medio de estos routers. Los MSR<br />
proporcionan un punto de acceso a través del cual los nodos móviles<br />
pued<strong>en</strong> conectarse a la red troncal del campus, además de <strong>en</strong>cargarse de<br />
dirigir el tráfico desde y hacia los nodos móviles.<br />
17
Sistemas de Movilidad <strong>en</strong> redes IP<br />
Cada nodo móvil es siempre alcanzable por uno de estos MSRs,<br />
indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de su ubicación d<strong>en</strong>tro del campus. Cuando un host<br />
<strong>en</strong>vía un datagrama a un nodo móvil el mecanismo <strong>en</strong>rutami<strong>en</strong>to IP<br />
<strong>en</strong>trega el paquete al MSR más cercano a la fu<strong>en</strong>te. Si el nodo móvil se<br />
<strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la celda del MSR, éste le <strong>en</strong>trega el paquete directam<strong>en</strong>te. En<br />
caso contrario lo <strong>en</strong>camina al MSR responsable utilizando <strong>en</strong>capsulación.<br />
Si un MSR no conociera cual es el router actualm<strong>en</strong>te responsable del<br />
nodo móvil se <strong>en</strong>viaría un m<strong>en</strong>saje (‘who_has’) a todos los MSR del campus<br />
esperando que alguno respondiera.<br />
La técnica propuesta ofrece la v<strong>en</strong>taja de que no se requiere<br />
ninguna modificación de los protocolos exist<strong>en</strong>tes <strong>en</strong> los hosts ni <strong>en</strong> el<br />
mecanismo de <strong>en</strong>caminami<strong>en</strong>to IP. Sin embargo sólo es aplicable a<br />
<strong>en</strong>tornos de campus pues el mecanismo de búsqueda de nodo móvil<br />
<strong>en</strong>viando m<strong>en</strong>sajes de consulta a todos los MSR no es escalable.<br />
2.2.2 Esquema Sony<br />
La propuesta de Sony [TER91], [TER93], [TER94] pres<strong>en</strong>ta un<br />
<strong>en</strong>foque más agresivo para incorporar la <strong>movilidad</strong> de los nodos <strong>en</strong> la<br />
arquitectura de Internet, puesto que implica una modificación de los<br />
protocolos exist<strong>en</strong>tes.<br />
En esta propuesta cada nodo móvil ti<strong>en</strong>e asignadas una dirección<br />
perman<strong>en</strong>te (d<strong>en</strong>ominada por los autores Virtual Network, VIP) y una<br />
dirección temporal dep<strong>en</strong>di<strong>en</strong>te de la red donde se <strong>en</strong>cu<strong>en</strong>tra (d<strong>en</strong>ominada<br />
Physical Network, PIP). Cada vez que un nodo móvil obti<strong>en</strong>e una dirección<br />
temporal nueva informa a un router de su Home Network indicándole esta<br />
dirección por medio de un m<strong>en</strong>saje de control.<br />
Los paquetes dirigidos hacia el nodo móvil, además de incluir como<br />
dirección destino la dirección perman<strong>en</strong>te, pued<strong>en</strong> incluir también la<br />
dirección temporal. Los paquetes <strong>en</strong>viados desde el nodo móvil, cuando se<br />
<strong>en</strong>cu<strong>en</strong>tra fuera de su Home Network, incluy<strong>en</strong> siempre ambas direcciones<br />
18
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
<strong>en</strong> el campo de dirección fu<strong>en</strong>te. Así, los routers que <strong>en</strong>caminan estos<br />
paquetes pued<strong>en</strong> examinar el campo de dirección fu<strong>en</strong>te y actualizar las<br />
tablas de traducción de direcciones.<br />
Una fu<strong>en</strong>te que desea <strong>en</strong>viar paquetes a un nodo móvil incluirá la<br />
dirección temporal <strong>en</strong> el campo destino si dispone de la <strong>en</strong>trada del nodo<br />
móvil <strong>en</strong> la tabla de traducción de direcciones. En caso contrario los<br />
paquetes son <strong>en</strong>caminados hacia la dirección perman<strong>en</strong>te. Durante este<br />
<strong>en</strong>caminami<strong>en</strong>to puede que algún router disponga de una <strong>en</strong>trada <strong>en</strong> su<br />
tabla de traducción con la dirección temporal del nodo móvil destino. En<br />
este caso interceptará el paquete y lo re<strong>en</strong>caminará hacia la situación<br />
actual del móvil; <strong>en</strong> caso contrario el paquete llegará al router de la Home<br />
Network que re<strong>en</strong>viará el paquete.<br />
Cuando un móvil cambia de red <strong>en</strong>vía una notificación a su Home<br />
Network de manera que se actualice las <strong>en</strong>tradas de las tablas de todos los<br />
routers que atraviesa. Además estas tablas son mant<strong>en</strong>idas por medio de<br />
temporizadores que borran las <strong>en</strong>tradas si no son actualizadas.<br />
Esta propuesta ti<strong>en</strong>e varios inconv<strong>en</strong>i<strong>en</strong>tes: la necesidad de<br />
modificación del paquete IP para que cont<strong>en</strong>ga dos direcciones fu<strong>en</strong>te, lo<br />
que equivale a la modificación del software de red de todos los equ<strong>ip</strong>os que<br />
forman la red; problemas de escalabilidad puesto que el tamaño de las<br />
tablas de traducción de direcciones de los routers crece al aum<strong>en</strong>tar el<br />
número de nodos móviles; y el mecanismo de handover que ofrece<br />
prestaciones muy bajas, puesto que asume que el paquete de control que<br />
indica el cambio de celda no se pierde, y una perdida ocasionaría una<br />
interrupción <strong>en</strong> la transmisión elevada.<br />
2.2.3 Esquema LSR<br />
En contraste con las propuestas com<strong>en</strong>tadas anteriorm<strong>en</strong>te,<br />
basadas <strong>en</strong> técnicas de <strong>en</strong>capsulación, las propuestas LSR [PER94]<br />
utilizan una opción del protocolo IP d<strong>en</strong>ominada LSR (Loose Source Route).<br />
19
Sistemas de Movilidad <strong>en</strong> redes IP<br />
El esquema LSR también permite a cada nodo móvil mant<strong>en</strong>er su dirección<br />
IP indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de su localización. Para ello se establece una<br />
arquitectura <strong>en</strong> la que <strong>en</strong> cada Home Network existe un router<br />
d<strong>en</strong>ominado MR (Mobile Router) que es el responsable de almac<strong>en</strong>ar y<br />
mant<strong>en</strong>er la localización actual de cada nodo móvil que ha sido asignado a<br />
esa red. Los nodos móviles se conectan a Internet por medio de estaciones<br />
base inalámbricas d<strong>en</strong>ominadas <strong>en</strong> la literatura MAS (Mobile Access<br />
Station). Cuando un nodo móvil se introduce <strong>en</strong> una celda controlada por<br />
una MAS informa de la dirección IP de la misma a su MR. El router MR<br />
almac<strong>en</strong>a esta información <strong>en</strong> la tabla a la vez que informa a la estación<br />
base previa que el nodo se ha movido de celda.<br />
Los paquetes dirigidos al nodo móvil primero se dirig<strong>en</strong> al router<br />
MR por el proceso normal de <strong>en</strong>rutami<strong>en</strong>to. Para dirigir un datagrama a la<br />
situación actual del nodo móvil, el MR inserta la opción LSR <strong>en</strong> el paquete,<br />
especificando la dirección de la estación base actual (MAS) como un router<br />
de transición. Esta opción provoca que los paquetes sean <strong>en</strong>caminados al<br />
nodo móvil vía el MAS. Cuando el nodo móvil contesta a la fu<strong>en</strong>te de los<br />
datagramas también inserta la opción LSR, especificando la estación base<br />
actual. Así, cuando el host fu<strong>en</strong>te recibe este datagrama, almac<strong>en</strong>a la ruta<br />
indicada y la utiliza, <strong>en</strong> s<strong>en</strong>tido inverso (según está definido <strong>en</strong> [RFC1122]),<br />
para <strong>en</strong>viar los sigui<strong>en</strong>tes paquetes, de manera que a partir de ese<br />
mom<strong>en</strong>to los paquetes <strong>en</strong>viados por el host fu<strong>en</strong>te al nodo móvil serán<br />
<strong>en</strong>caminados a través de la ruta óptima, sin necesidad de que se<br />
<strong>en</strong>camin<strong>en</strong> previam<strong>en</strong>te hacia el MR.<br />
Esta propuesta se basa <strong>en</strong> la capacidad de los hosts de<br />
implem<strong>en</strong>tar el <strong>en</strong>caminami<strong>en</strong>to inverso de los paquetes que recibe con la<br />
opción LSR. Sin embargo la gran mayoría de los hosts no desarrollan esta<br />
tarea de forma correcta, incluso llegan a descartar los paquetes recibidos<br />
con esta opción debido a los problemas de seguridad que acarrean. Otro<br />
problema es el pobre servicio que los paquetes IP con está opción recib<strong>en</strong><br />
de los routers. Éstos están optimizados para trabajar con paquetes IP con<br />
cabecera simple y cuando recib<strong>en</strong> uno con opciones <strong>en</strong> la cabecera<br />
directam<strong>en</strong>te lo introduc<strong>en</strong> <strong>en</strong> una cola de baja prioridad. Debido a estas<br />
20
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
limitaciones el IETF ya no acepta los esquemas que utilic<strong>en</strong> la opción de<br />
LSR.<br />
2.3 MOBILE IP<br />
Fruto de los trabajos desarrollados por C. Perkins y D. Johnson<br />
[PER94b](Protocolo IMHP), [JOH94] y [PER94], junto a los trabajos que se<br />
han mostrado <strong>en</strong> el punto anterior, apareció el protocolo Mobile IP [RFC<br />
2002] <strong>en</strong> 1996. Desde <strong>en</strong>tonces este protocolo ha sido el punto de<br />
refer<strong>en</strong>cia para todos los trabajos sobre <strong>movilidad</strong> <strong>en</strong> redes IP pres<strong>en</strong>tados.<br />
Por esto, y porque también aquí se va a utilizar este protocolo como punto<br />
de partida, se va a realizar un estudio con cierto detalle del modo de<br />
funcionami<strong>en</strong>to. Una primera aproximación al mismo puede <strong>en</strong>contrarse<br />
<strong>en</strong> [SOL98]. Actualm<strong>en</strong>te el estándar original ha pasado al estado<br />
‘Obsoleto’ pues ha sido actualizado <strong>en</strong> [RFC 3344]. En este trabajo vamos<br />
a refer<strong>en</strong>ciar siempre esta última versión. Las difer<strong>en</strong>cias <strong>en</strong>tre ambas<br />
versiones no son especialm<strong>en</strong>te destacables. En la propia [RFC 3344] se<br />
realiza una descr<strong>ip</strong>ción detallada de dichos cambios.<br />
Mobile IP puede verse como un protocolo de nivel de red que<br />
soluciona los problemas de <strong>movilidad</strong> de los nodos <strong>en</strong> Internet. Así el<br />
propósito es permitir que los paquetes IP puedan ser <strong>en</strong>caminados a los<br />
nodos móviles, los cuales pot<strong>en</strong>cialm<strong>en</strong>te pued<strong>en</strong> cambiar su localización<br />
rápidam<strong>en</strong>te.<br />
Exist<strong>en</strong> una serie de requerimi<strong>en</strong>tos necesarios sobre los que se ha<br />
trabajado para el desarrollo de Mobile IP:<br />
• Un nodo móvil debe ser capaz de comunicarse con todos los nodos<br />
después de cambiar su punto de conexión <strong>en</strong> Internet, es decir,<br />
debe seguir mant<strong>en</strong>i<strong>en</strong>do conectividad global.<br />
21
Sistemas de Movilidad <strong>en</strong> redes IP<br />
• Un nodo móvil debe ser capaz de comunicarse utilizando su<br />
dirección IP perman<strong>en</strong>te (d<strong>en</strong>ominada también Home Address)<br />
indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de su punto de conexión con la red.<br />
• Un nodo móvil debe ser capaz de comunicarse con cualquier nodo<br />
indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de que no implem<strong>en</strong>te las funciones de<br />
<strong>movilidad</strong> de Mobile IP.<br />
• Un nodo móvil no debe estar expuesto a ninguna am<strong>en</strong>aza <strong>en</strong><br />
temas de seguridad a la que no este expuesto cualquier nodo fijo de<br />
la red.<br />
Mobile IP define tres <strong>en</strong>tidades funcionales donde deb<strong>en</strong> ser<br />
implem<strong>en</strong>tados los protocolos de <strong>movilidad</strong>.<br />
• Nodo Móvil: un nodo que puede cambiar su punto de acceso a la<br />
red desde un <strong>en</strong>lace a otro mant<strong>en</strong>i<strong>en</strong>do cualquier comunicación y<br />
utilizando sólo su dirección IP perman<strong>en</strong>te (Home Address). Esta<br />
dirección es asignada de forma perman<strong>en</strong>te de la misma forma que<br />
se asigna una dirección a un host fijo o a un router.<br />
• Home Ag<strong>en</strong>t: un router con un interfaz a la red local, Home<br />
Network 1 , que manti<strong>en</strong>e información de la situación actual del nodo<br />
móvil (repres<strong>en</strong>tada, como veremos a continuación por su Care-of<br />
Address). Además <strong>en</strong>vía m<strong>en</strong>sajes de información de la red<br />
(Advertises Reachability) y se <strong>en</strong>carga de capturar los paquetes<br />
destinados al nodo móvil y <strong>en</strong>viarlos por medio de un túnel a su<br />
localización actual.<br />
• Foreign Ag<strong>en</strong>t: un router con un interfaz a una red externa,<br />
Foreign Network 2 , donde está situado el nodo móvil <strong>en</strong> la<br />
actualidad. Este ag<strong>en</strong>te se <strong>en</strong>carga de ayudar al nodo móvil<br />
informando al Home Ag<strong>en</strong>t de la Care-of Address asignada al nodo;<br />
<strong>en</strong> algunos casos proporciona dicha dirección y actúa como punto<br />
1 Home Network, red correspondi<strong>en</strong>te al indicador de red de la dirección IP perman<strong>en</strong>te<br />
(Home Address) del nodo móvil.<br />
2 Foreign Network, cualquier red difer<strong>en</strong>te de la Home Network, donde se puede <strong>en</strong>contrar<br />
temporalm<strong>en</strong>te el nodo móvil.<br />
22
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
de salida del túnel, aunque como veremos posteriorm<strong>en</strong>te no es<br />
obligatorio; por último actúa como router de salida <strong>en</strong>caminando<br />
los paquetes g<strong>en</strong>erados por el nodo móvil mi<strong>en</strong>tras se <strong>en</strong>cu<strong>en</strong>tra<br />
conectado <strong>en</strong> la Foreign Network.<br />
En la sigui<strong>en</strong>te figura se muestran estas <strong>en</strong>tidades y como se<br />
relacionan <strong>en</strong>tre ellas.<br />
Nodo móvil <strong>en</strong><br />
una Foreign<br />
Network<br />
Foreign Network<br />
Foreign Ag<strong>en</strong>t<br />
Home Ag<strong>en</strong>t<br />
Nodo móvil<br />
“at Home”<br />
Home Network<br />
Foreign Network<br />
Foreign Ag<strong>en</strong>t<br />
Figura 2.2 Entidades <strong>en</strong> Mobile IP<br />
Care-of Address.<br />
Se ha nombrado anteriorm<strong>en</strong>te el concepto de Care-of Address.<br />
Ésta es una dirección IP que se asocia a un nodo móvil cuando está <strong>en</strong><br />
una red externa (Foreign Network) y g<strong>en</strong>eralm<strong>en</strong>te cambia cuando el móvil<br />
se traslada de una red a otra. Así, los paquetes dirigidos al nodo móvil se<br />
<strong>en</strong>viarán desde el Home Ag<strong>en</strong>t por medio de un túnel utilizando esta<br />
dirección como punto de salida. En la figura 2.3 se muestra el proceso de<br />
‘tunneling’ de los paquetes dirigidos hacia el nodo móvil. Exist<strong>en</strong> diversos<br />
procedimi<strong>en</strong>tos para realizarlo: Encapsulación IP sobre IP [RFC2003],<br />
<strong>en</strong>capsulación mínima [RFC2004] y <strong>en</strong>capsulación de <strong>en</strong>caminami<strong>en</strong>to<br />
g<strong>en</strong>érica (GRE) [RFC1701].<br />
23
Sistemas de Movilidad <strong>en</strong> redes IP<br />
Exist<strong>en</strong> dos t<strong>ip</strong>os de Care-of Address:<br />
1. Foreign Ag<strong>en</strong>t Care-of Address: es una dirección IP de un Foreign<br />
Ag<strong>en</strong>t que ti<strong>en</strong>e un interfaz <strong>en</strong> la red externa (Foreign Network) <strong>en</strong><br />
la que está actualm<strong>en</strong>te el nodo móvil.<br />
2. Co-located Care-of Address: es una dirección IP asignada<br />
temporalm<strong>en</strong>te al nodo móvil. Evid<strong>en</strong>tem<strong>en</strong>te, el prefijo de<br />
id<strong>en</strong>tificación de red de esta dirección asignada debe coincidir con<br />
el de la red (Foreign Network). Este t<strong>ip</strong>o de direcciones suele<br />
utilizarse cuando no existe un Foreign Ag<strong>en</strong>t <strong>en</strong> la red y no puede<br />
ser utilizada por más de un nodo al mismo tiempo.<br />
Fu<strong>en</strong>te = Punto de <strong>en</strong>trada del túnel<br />
Destino = Punto de salida del túnel<br />
Fu<strong>en</strong>te = Fu<strong>en</strong>te original<br />
Destino = Último destino<br />
Cabecera<br />
exterior<br />
Cabec.<br />
Payload<br />
Modo móvil Foreign Ag<strong>en</strong>t Home Ag<strong>en</strong>t<br />
Figura 2.3 Túnel IP<br />
24
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
2.3.1 Visión G<strong>en</strong>eral del Modo de Funcionami<strong>en</strong>to<br />
Podemos resumir el modo de trabajo de Mobile IP <strong>en</strong> 7 puntos<br />
g<strong>en</strong>erales:<br />
1. Tanto los Home Ag<strong>en</strong>t como los Foreign Ag<strong>en</strong>ts informan de su<br />
pres<strong>en</strong>cia a cualquier nodo móvil que se <strong>en</strong>cu<strong>en</strong>tre conectado a<br />
cualquiera de sus interfaces difundi<strong>en</strong>do un m<strong>en</strong>saje especial<br />
d<strong>en</strong>ominado <strong>en</strong> [RFC 3344] Ag<strong>en</strong>t Advertisem<strong>en</strong>t.<br />
2. Los nodos móviles que escuchan estos m<strong>en</strong>sajes analizan su<br />
cont<strong>en</strong>ido para decidir si se <strong>en</strong>cu<strong>en</strong>tran <strong>en</strong> su red local (Home<br />
Network) o <strong>en</strong> otra externa (Foreign Network). Mi<strong>en</strong>tras se<br />
<strong>en</strong>cu<strong>en</strong>tr<strong>en</strong> conectados <strong>en</strong> la red local actúan como cualquier nodo<br />
estacionario, esto es, sin hacer uso de las capacidades de Mobile IP.<br />
3. Un nodo móvil conectado a una Foreign Network adquiere una<br />
Care-of Address. Ésta puede ser adquirida bi<strong>en</strong> leyéndola de los<br />
m<strong>en</strong>sajes Ag<strong>en</strong>t Advertisem<strong>en</strong>t <strong>en</strong>viados por el ag<strong>en</strong>te o bi<strong>en</strong> (<strong>en</strong><br />
caso de una dirección co-located Care-of Address) por cualquier<br />
procedimi<strong>en</strong>to de asignación como DHCP, IPCP (Protocolo de<br />
Control IP de PPP) [RFC1332] o incluso de una configuración<br />
manual.<br />
4. El nodo móvil registra la dirección adquirida <strong>en</strong> el paso anterior.<br />
Para este registro el nodo se valdrá del Foreign Ag<strong>en</strong>t si éste está<br />
pres<strong>en</strong>te.<br />
5. El Home Ag<strong>en</strong>t o cualquier router con conexión a la red local del<br />
nodo (Local Network) intercepta los paquetes destinados al nodo y<br />
los <strong>en</strong>vía por medio de un túnel hacia la dirección Care-of Address<br />
registrada <strong>en</strong> el paso anterior.<br />
6. Una vez esto, indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de que la dirección se<br />
corresponda con la de un Foreign Ag<strong>en</strong>t o la haya adquirido el nodo<br />
se des<strong>en</strong>capsula el paquete original y se <strong>en</strong>trega al nodo.<br />
7. En la dirección contraria los paquetes <strong>en</strong>viados por el nodo son<br />
<strong>en</strong>caminados directam<strong>en</strong>te a su destino sin necesidad de realizar<br />
un túnel.<br />
25
Sistemas de Movilidad <strong>en</strong> redes IP<br />
Observando los pasos anteriores podemos resumir que una<br />
transmisión de un nodo móvil sigue tres fases que numeramos a<br />
continuación y que describiremos con cierto detalle <strong>en</strong> los próximos<br />
puntos:<br />
• Descubrimi<strong>en</strong>to del ag<strong>en</strong>te, el proceso por el cual un nodo móvil<br />
determina su situación actual y obti<strong>en</strong>e una Care-of Address.<br />
• Registro, procedimi<strong>en</strong>to por el cual el nodo solicita un servicio<br />
desde una red externa (Foreign Network) e informa a su ag<strong>en</strong>te local<br />
(Home Ag<strong>en</strong>t) de su dirección externa actual (Care-of Address).<br />
• Los mecanismos específicos por los que los paquetes son<br />
<strong>en</strong>caminados desde y hacia un nodo móvil conectado <strong>en</strong> una red<br />
externa.<br />
2.3.2 Descubrimi<strong>en</strong>to del Ag<strong>en</strong>te<br />
Como se ha com<strong>en</strong>tado anteriorm<strong>en</strong>te el descubrimi<strong>en</strong>to del ag<strong>en</strong>te<br />
es el proceso por el cual un nodo móvil es capaz de determinar si<br />
actualm<strong>en</strong>te está conectado a su Home Network o está <strong>en</strong> un Foreign<br />
Network, o si se ha movido de una red a otra, y de obt<strong>en</strong>er una Care-of<br />
Address <strong>en</strong> caso necesario.<br />
Exist<strong>en</strong> dos m<strong>en</strong>sajes para averiguar la situación <strong>en</strong> que se<br />
<strong>en</strong>cu<strong>en</strong>tra el nodo. El primero es la ya com<strong>en</strong>tado ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>ts’<br />
<strong>en</strong>viado de forma periódica por los ag<strong>en</strong>tes, <strong>en</strong> forma de paquetes de<br />
difusión (broadcast) o multidestino (<strong>multicast</strong>). El segundo t<strong>ip</strong>o de<br />
m<strong>en</strong>sajes se d<strong>en</strong>omina ‘Ag<strong>en</strong>t Solicitation’ y es <strong>en</strong>viado por el nodo móvil<br />
con el único propósito de forzar a los ag<strong>en</strong>tes a <strong>en</strong>viar un m<strong>en</strong>saje ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>ts’. Esto es útil <strong>en</strong> el caso de que el nodo se mueva de forma<br />
rápida de una red a otra.<br />
El formato de estos m<strong>en</strong>sajes es similar a los m<strong>en</strong>sajes de<br />
descubrimi<strong>en</strong>to de ruta ICMP definidos <strong>en</strong> [RFC1256]. El id<strong>en</strong>tificativo de<br />
26
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
red de la dirección orig<strong>en</strong> del los paquetes ‘Ag<strong>en</strong>t Advetisem<strong>en</strong>t’ es utilizado<br />
por el nodo para determinar si se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la ‘Home Network’ o si está<br />
<strong>en</strong> una externa o ha cambiado de ubicación. Además existe un campo <strong>en</strong><br />
el que se <strong>en</strong>cu<strong>en</strong>tran las direcciones Care-of disponibles, pudi<strong>en</strong>do los<br />
nodos utilizar cualquiera de ellas si es necesario.<br />
Para determinar si un nodo ha cambiado de red exist<strong>en</strong> varias<br />
posibilidades. La primera es estudiar los prefijos de red de las direcciones<br />
fu<strong>en</strong>te de los m<strong>en</strong>sajes de anuncio recibidos. Así, si recibe dos m<strong>en</strong>sajes<br />
con prefijos de red difer<strong>en</strong>tes supone que se ha cambiado de red por lo que<br />
debe obt<strong>en</strong>er una nueva dirección. Otro mecanismo es utilizar el campo de<br />
tiempo de vida que existe <strong>en</strong> los m<strong>en</strong>sajes <strong>en</strong>viados por el ag<strong>en</strong>te. Estos<br />
paquetes pued<strong>en</strong> perderse o llegar con errores debido princ<strong>ip</strong>alm<strong>en</strong>te que<br />
se transmit<strong>en</strong> por un medio radio con una mayor probabilidad de error,<br />
por lo que la recom<strong>en</strong>dación [RFC 3344] indica que los m<strong>en</strong>sajes ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>ts’ deb<strong>en</strong> <strong>en</strong>viarse por parte del ag<strong>en</strong>te a un ritmo 3 veces<br />
superior al indicado <strong>en</strong> su campo Tiempo de vida. Si el nodo no recibe<br />
ningún nuevo m<strong>en</strong>saje <strong>en</strong> ese tiempo supone que se ha movido a otra red<br />
por lo que int<strong>en</strong>tará registrarse con un nuevo ag<strong>en</strong>te del que reciba un<br />
m<strong>en</strong>saje, <strong>en</strong>viando solicitudes si no recibe ninguno.<br />
Puede suceder que un nodo conectado a una red no reciba<br />
m<strong>en</strong>sajes de anuncio por parte de los ag<strong>en</strong>tes aún cuando el nodo los<br />
solicite. La primera suposición que hace el nodo es suponer que se<br />
<strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> su red local (Home Network) pero que el ag<strong>en</strong>te está muerto.<br />
En este caso el nodo simplem<strong>en</strong>te int<strong>en</strong>ta averiguar si está conectado su<br />
red, por ejemplo <strong>en</strong>viando un m<strong>en</strong>saje ICMP de solicitud de eco al router<br />
que utiliza por defecto. Si responde es que está conectado y, por tanto,<br />
transmite normalm<strong>en</strong>te. En caso de no recibir respuesta el nodo asume<br />
que se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> una red externa (Foreign Network) e int<strong>en</strong>ta obt<strong>en</strong>er<br />
una dirección (d<strong>en</strong>ominada Co-located Care-of Address) por ejemplo<br />
utilizando un servidor DHCP [RFC 2131]. Si tampoco <strong>en</strong>cu<strong>en</strong>tra un<br />
servidor DHCP siempre queda la configuración manual de una dirección<br />
IP.<br />
27
Sistemas de Movilidad <strong>en</strong> redes IP<br />
En esta situación <strong>en</strong> la que no exist<strong>en</strong> ag<strong>en</strong>tes, aún <strong>en</strong> el caso de<br />
que el nodo haya sido capaz de obt<strong>en</strong>er una Co-located Care-of Address<br />
queda p<strong>en</strong>di<strong>en</strong>te el hecho de determinar si ha cambiado de una red a otra.<br />
Exist<strong>en</strong> dos posibles mecanismos para detectar esto. El primero es realizar<br />
una monitorización de las conexiones TCP que ti<strong>en</strong>e establecidas, de<br />
manera que si no se advierte un progreso se puede concluir con que se ha<br />
movido desde la última vez que se registró. La segunda solución es poner<br />
el interfaz de red <strong>en</strong> modo promiscuo de manera que pueda examinar<br />
todos los paquetes que se transmit<strong>en</strong> por el <strong>en</strong>lace no sólo los que van<br />
dirigidos a él. De esta forma es capaz de determinar si está <strong>en</strong> la misma<br />
red de la que ha obt<strong>en</strong>ido su Co-located Care-of Address o se ha movido a<br />
otra, <strong>en</strong> cuyo caso int<strong>en</strong>tará obt<strong>en</strong>er una nueva sigui<strong>en</strong>do el proceso ya<br />
m<strong>en</strong>cionado. Hay que indicar que <strong>en</strong> ambos métodos se requiere de la<br />
cooperación de otros niveles adicionales al nivel de red (Transporte y<br />
Enlace de datos respectivam<strong>en</strong>te).<br />
2.3.3 Registro<br />
El registro es el proceso por el cual se solicitan los servicios de un<br />
Foreign Ag<strong>en</strong>t y se informa al Home Ag<strong>en</strong>t de la dirección care-of actual.<br />
Éste se realiza cada vez que el nodo móvil cambia de red o incluso cuando<br />
no ha cambiado pero el tiempo de vida del registro actual está apunto de<br />
expirar.<br />
El registro consiste <strong>en</strong> el intercambio de dos m<strong>en</strong>sajes, solicitud de<br />
registro y contestación (‘Registration Request’ y ‘Registration Reply’). Ambos<br />
m<strong>en</strong>sajes se <strong>en</strong>vían d<strong>en</strong>tro de la parte de datos de un m<strong>en</strong>saje UDP. En la<br />
figura 2.4 puede observarse esto.<br />
El proceso empieza con el <strong>en</strong>vío por parte del nodo de un m<strong>en</strong>saje<br />
de solicitud de registro. Como puede verse <strong>en</strong> la figura 2.5 son posibles<br />
varios esc<strong>en</strong>arios. Puede observarse como <strong>en</strong> el primero está implicado el<br />
Foreign Ag<strong>en</strong>t y <strong>en</strong> el segundo, <strong>en</strong> el que se ha obt<strong>en</strong>ido una Co-located<br />
Care-of Address, no. Como contestación a este m<strong>en</strong>saje el Home Ag<strong>en</strong>t<br />
28
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
<strong>en</strong>viará una respuesta indicando el resultado de la solicitud. En caso de no<br />
recibir respuesta el nodo retransmitirá la solicitud.<br />
Registro<br />
Descubrimi<strong>en</strong>to<br />
de ag<strong>en</strong>te<br />
UDP [RFC768] ICMP [RFC792]<br />
Internet Protocol [RFC791]<br />
Figura 2.4 Utilización de UDP como protocolo de Transporte<br />
Nodo móvil <strong>en</strong> una<br />
Foreign Network<br />
1 Registration Request 2<br />
Home<br />
Ag<strong>en</strong>t<br />
Foreign Network<br />
4<br />
Foreign<br />
Ag<strong>en</strong>t<br />
Registration Reply<br />
3<br />
Registration Request<br />
Home Ag<strong>en</strong>t<br />
Foreign Network<br />
Registration Reply<br />
Figura 2.5 Esc<strong>en</strong>arios de Registro<br />
29
Sistemas de Movilidad <strong>en</strong> redes IP<br />
Registro utilizando un Foreign Ag<strong>en</strong>t.<br />
En este caso el m<strong>en</strong>saje de solicitud de registro se <strong>en</strong>capsula <strong>en</strong> un<br />
paquete IP, con la dirección perman<strong>en</strong>te del nodo (Home Address) <strong>en</strong> el<br />
campo dirección fu<strong>en</strong>te y la del ag<strong>en</strong>te (Foreign Ag<strong>en</strong>t) <strong>en</strong> el campo de<br />
dirección destino.<br />
El ag<strong>en</strong>te analizará el m<strong>en</strong>saje, y si por cualquier motivo no es<br />
válido le <strong>en</strong>viará un m<strong>en</strong>saje de rechazo de registro. Algunos de los motivos<br />
que pued<strong>en</strong> ocasionar este rechazo son: el campo de aut<strong>en</strong>tificación no es<br />
valido; el nodo requiere un t<strong>ip</strong>o de túnel que no es soportado por el ag<strong>en</strong>te;<br />
el ag<strong>en</strong>te no ti<strong>en</strong>e sufici<strong>en</strong>tes recursos para aceptar el registro; o el nodo<br />
requiere un tiempo de vida que excede el máximo permitido por le ag<strong>en</strong>te.<br />
Si el m<strong>en</strong>saje es válido el ag<strong>en</strong>te lo re<strong>en</strong>viará, sustituy<strong>en</strong>do,<br />
respectivam<strong>en</strong>te, los campos de IP fu<strong>en</strong>te y destino por la dirección del<br />
ag<strong>en</strong>te <strong>en</strong> el interfaz por el que lo <strong>en</strong>vía y la dirección del ag<strong>en</strong>te local del<br />
nodo (Home Ag<strong>en</strong>t). Además el ‘Foreign Ag<strong>en</strong>t’ almac<strong>en</strong>ará cierta<br />
información (por ejemplo, dirección física, dirección IP y puerto del nodo)<br />
para posteriorm<strong>en</strong>te poder <strong>en</strong>tregar los paquetes de datos.<br />
El Home Ag<strong>en</strong>t recibe el m<strong>en</strong>saje de solicitud y actualiza la base de<br />
datos donde almac<strong>en</strong>a la información del nodo. Es importante destacar<br />
aquí que dep<strong>en</strong>di<strong>en</strong>do de un campo de la solicitud de registro (d<strong>en</strong>ominado<br />
bit S) el nuevo <strong>en</strong>lace sustituye a los anteriores o crea uno nuevo<br />
mant<strong>en</strong>i<strong>en</strong>do los exist<strong>en</strong>tes. Un proceso similar es utilizado para eliminar<br />
<strong>en</strong>laces de la tabla.<br />
Por último el Foreign Ag<strong>en</strong>t recibe la contestación de la solicitud de<br />
registro (‘Registration Reply’) y se la <strong>en</strong>vía al nodo utilizando la información<br />
almac<strong>en</strong>ada previam<strong>en</strong>te. A partir de ese mom<strong>en</strong>to el ag<strong>en</strong>te empieza a<br />
extraer del túnel paquetes <strong>en</strong>viados al nodo y a actuar como <strong>en</strong>caminador<br />
por defecto de la información g<strong>en</strong>erada por él. En la figura 2.5 puede<br />
observarse gráficam<strong>en</strong>te todo el proceso descrito.<br />
30
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
Registro sin utilizar ag<strong>en</strong>te.<br />
En el caso <strong>en</strong> que estemos trabajando sin un ag<strong>en</strong>te externo la<br />
dirección IP fu<strong>en</strong>te de los paquetes <strong>en</strong>viados será la dirección temporal<br />
obt<strong>en</strong>ida de manera autónoma (Co-located Care-of Address), y la dirección<br />
destino la del ag<strong>en</strong>te local (Home Ag<strong>en</strong>t). En este caso todo el proceso se<br />
realiza directam<strong>en</strong>te <strong>en</strong>tre el nodo móvil y su ag<strong>en</strong>te local.<br />
2.3.4 Envío de datos<br />
Los paquetes <strong>en</strong>viados a un nodo móvil que se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> su red<br />
local (Home Network) son <strong>en</strong>tregados de la misma manera que serían<br />
<strong>en</strong>tregados a un nodo fijo, sin que sea necesario ningún procedimi<strong>en</strong>to<br />
especial. En este punto vamos a tratar como los datos son <strong>en</strong>caminados al<br />
nodo móvil que se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> una Foreign Network, una vez éste ha<br />
realizado el proceso de registro.<br />
El proceso se inicia con la intercepción de los paquetes destinados<br />
al nodo móvil por parte del ag<strong>en</strong>te local. Este proceso se realiza tanto si el<br />
transmisor se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> propia red local como fuera de ella.<br />
Posteriorm<strong>en</strong>te los re<strong>en</strong>vía por medio de un túnel a cada una de las<br />
Care-of Address almac<strong>en</strong>adas <strong>en</strong> la base de datos. Como puede verse <strong>en</strong> la<br />
figura sigui<strong>en</strong>te el proceso variará ligeram<strong>en</strong>te <strong>en</strong> función del t<strong>ip</strong>o de<br />
dirección que ha adquirido el nodo (Foreign Ag<strong>en</strong>t Care-of Address o Colocated<br />
Care-of Address). En ambos casos el ag<strong>en</strong>te local intercepta los<br />
paquetes destinados hacia un nodo y lo <strong>en</strong>vía por medio de un túnel a la<br />
dirección care-of destino. En el caso de que esta dirección pert<strong>en</strong>ezca a un<br />
ag<strong>en</strong>te, éste elimina la cabecera exterior para recuperar el paquete original<br />
y <strong>en</strong>viárselo al nodo. En caso de una Co-located address será el propio<br />
nodo el que realiza el des<strong>en</strong>capsulado del paquete.<br />
Hasta ahora hemos com<strong>en</strong>tado como se realiza la transmisión de<br />
información desde un host hasta el nodo móvil. Para estudiar la<br />
31
Sistemas de Movilidad <strong>en</strong> redes IP<br />
transmisión desde al nodo a un host podemos distinguir dos situaciones.<br />
En el caso de que el nodo se <strong>en</strong>cu<strong>en</strong>tre <strong>en</strong> su red local el <strong>en</strong>vío de paquetes<br />
se realiza como lo hace cualquier nodo fijo, esto es, por medio de un router<br />
de salida que se obti<strong>en</strong>e vía DHCP [RFC 2131], IPCP de PPP o incluso por<br />
configuración manual.<br />
Nodo móvil con<br />
Foreign Ag<strong>en</strong>t<br />
Care-of Address<br />
Host<br />
Foreign Ag<strong>en</strong>t<br />
Nodo móvil con<br />
Co-located Careof<br />
Address<br />
Router<br />
Paquetes originales<br />
Paquetes <strong>en</strong> túnel<br />
Home Ag<strong>en</strong>t<br />
Figura 2.6 Encaminami<strong>en</strong>to de los paquetes al nodo móvil<br />
Cuando el nodo móvil se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> una Foreign Network es<br />
necesario un mecanismo para determinar un router por el que <strong>en</strong>caminar<br />
los paquetes g<strong>en</strong>erados por el nodo. En el caso de que haya utilizado un<br />
Foreign Ag<strong>en</strong>t puede utilizarse este mismo ag<strong>en</strong>te (la dirección se obti<strong>en</strong>e<br />
del campo dirección IP fu<strong>en</strong>te de los m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>ts’) o<br />
bi<strong>en</strong> cualquier router indicado <strong>en</strong> el campo Router Address de la porción<br />
de m<strong>en</strong>saje ‘ICMP Router Advertisem<strong>en</strong>ts’ [RFC 1256] que aparece tanto <strong>en</strong><br />
los m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ como ‘Router Advertisem<strong>en</strong>t’. Hay que<br />
indicar que un nodo móvil no puede, bajo ninguna circunstancia, <strong>en</strong>viar<br />
paquetes ARP cont<strong>en</strong>i<strong>en</strong>do su dirección perman<strong>en</strong>te (Home Address)<br />
cuando se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> alguna red difer<strong>en</strong>te a su Home Network. Por<br />
tanto será necesario algún mecanismo alternativo para obt<strong>en</strong>er la<br />
dirección física del router seleccionando (por ejemplo estudiando los<br />
m<strong>en</strong>sajes de anuncio del router).<br />
32
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
En el caso de que no exista un Foreign Ag<strong>en</strong>t también es posible<br />
seleccionar un router para poder transmitir paquetes. Una opción es<br />
escuchar un router que <strong>en</strong>víe m<strong>en</strong>sajes ‘ICMP Router Advertisem<strong>en</strong>ts’. Si no<br />
recibe ningún paquete de este t<strong>ip</strong>o el nodo debe utilizar el mismo<br />
mecanismo que utilizó para obt<strong>en</strong>er una Co-located Care-of Address:<br />
DHCP, IPCP o configuración manual.<br />
2.3.5 Consideraciones relativas a la Seguridad<br />
Los sistemas, como el que estamos estudiando, que permit<strong>en</strong> la<br />
<strong>movilidad</strong> de los nodos necesitan solucionar una serie de limitaciones que<br />
pued<strong>en</strong> afectar a la seguridad. Así, por ejemplo, <strong>en</strong> el protocolo Mobile IP el<br />
procedimi<strong>en</strong>to de registro ofrece un área particular de vulnerabilidad<br />
porque se utiliza para indicar al Home Ag<strong>en</strong>t a que dirección debe <strong>en</strong>viar<br />
los paquetes, a fin de que el nodo móvil correspondi<strong>en</strong>te pueda recibirlos.<br />
Simplem<strong>en</strong>te con que un ‘bad guy’ [KAU95] <strong>en</strong>víe un m<strong>en</strong>saje de este t<strong>ip</strong>o<br />
lograría redirigir todos los paquetes hacia la dirección elegida.<br />
Para evitar ataques a la seguridad de este t<strong>ip</strong>o Mobile IP requiere<br />
que todos los m<strong>en</strong>sajes de registro <strong>en</strong>tre un nodo y su Home Ag<strong>en</strong>t sean<br />
aut<strong>en</strong>tificados. La aut<strong>en</strong>tificación consiste <strong>en</strong> un proceso por el cual el<br />
nodo transmisor asegura su id<strong>en</strong>tidad al nodo que recibe. El campo de<br />
estudio de la aut<strong>en</strong>tificación y de la seguridad <strong>en</strong> g<strong>en</strong>eral es muy ext<strong>en</strong>so<br />
(una visión detallada podría <strong>en</strong>contrarse <strong>en</strong> [SCH95] o <strong>en</strong> [KAU95]). Este<br />
punto se va a c<strong>en</strong>trar exclusivam<strong>en</strong>te <strong>en</strong> ofrecer una visión g<strong>en</strong>eral de los<br />
mecanismos definidos <strong>en</strong> la [RFC 3344] y <strong>en</strong> algunas incorporaciones a la<br />
misma que actualm<strong>en</strong>te están bajo estudio.<br />
En [RFC 3344] se indica que la aut<strong>en</strong>tificación se realiza utilizando<br />
ext<strong>en</strong>siones de aut<strong>en</strong>tificación <strong>en</strong> los m<strong>en</strong>sajes intercambiados. De las tres<br />
ext<strong>en</strong>siones que han sido definidas <strong>en</strong> la norma la más importante es, sin<br />
duda, la ext<strong>en</strong>sión de aut<strong>en</strong>tificación Mobile-Home puesto que es<br />
obligatorio que se incluya <strong>en</strong> todos m<strong>en</strong>sajes de solicitud de registro<br />
33
Sistemas de Movilidad <strong>en</strong> redes IP<br />
(‘Registration Request’) y respuesta (‘Registration Reply’) que intercambian<br />
un nodo móvil y su Home Ag<strong>en</strong>t.<br />
Esta ext<strong>en</strong>sión de aut<strong>en</strong>tificación puede observarse <strong>en</strong> la sigui<strong>en</strong>te<br />
figura. El valor de aut<strong>en</strong>tificación calculado se obti<strong>en</strong>e computando<br />
mediante un mecanismo de aut<strong>en</strong>tificación los campos de carga UDP (es<br />
decir el m<strong>en</strong>saje de Solicitud o Respuesta de Registro), todas las<br />
ext<strong>en</strong>siones anteriores, y el t<strong>ip</strong>o y longitud de la ext<strong>en</strong>sión de<br />
aut<strong>en</strong>tificación. Por defecto el mecanismo de aut<strong>en</strong>tificación a emplear es<br />
el d<strong>en</strong>ominado MD5 [RFC 1321] <strong>en</strong> el d<strong>en</strong>ominado modo ‘prefijo+sufijo’,<br />
que obti<strong>en</strong>e un valor de 128 bits como resultado de las operaciones<br />
realizadas sobre la información indicada anteriorm<strong>en</strong>te y utilizando una<br />
clave secreta compartida.<br />
0 7 8 15 16 23 24 31<br />
T<strong>ip</strong>o = 32 Longitud SPI<br />
SPI (cont.)<br />
Aut<strong>en</strong>tificador<br />
…………………………<br />
Figura 2.7 Ext<strong>en</strong>sión de Aut<strong>en</strong>tificación Mobile-Home<br />
La clave compartida que se utiliza está definida por la asociación de<br />
seguridad que se ha establecido previam<strong>en</strong>te <strong>en</strong>tre los dos nodos, y que<br />
vi<strong>en</strong>e indicada por el valor del campo de la ext<strong>en</strong>sión SPI. El valor SPI<br />
(Security Parameter Index) define el contexto de seguridad utilizado y, <strong>en</strong><br />
particular, define el mecanismo de aut<strong>en</strong>tificación y la clave a emplear.<br />
Además de la ext<strong>en</strong>sión de aut<strong>en</strong>tificación Mobile-Home el estándar<br />
define dos ext<strong>en</strong>siones adicionales (Mobile-Foreign y Foreign-Home), cuyo<br />
formato es similar al mostrado <strong>en</strong> la figura 2.7<br />
El tema de la seguridad <strong>en</strong> redes basadas <strong>en</strong> el protocolo Mobile IP<br />
está actualm<strong>en</strong>te <strong>en</strong> desarrollo. Por ejemplo <strong>en</strong> [RFC 3012] se defin<strong>en</strong> las<br />
ext<strong>en</strong>siones para que un Foreign Ag<strong>en</strong>t pueda desarrollar mecanismos de<br />
34
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
interrogación-respuesta (Chall<strong>en</strong>ge/Response) (por ejemplo CHAP [RFC<br />
1994]) como mecanismos de aut<strong>en</strong>tificación del nodo móvil.<br />
Otro ejemplo es la utilización de servidores AAA (Auth<strong>en</strong>tication,<br />
Authorization, Accounting) [PER02] para obt<strong>en</strong>er asociaciones seguras <strong>en</strong>tre<br />
el nodo móvil y el Home Ag<strong>en</strong>t, o incluso con el Foreign Ag<strong>en</strong>t, utilizando<br />
para ello la exist<strong>en</strong>cia de una asociación de seguridad previa <strong>en</strong>tre el nodo<br />
y un servidor AAA como RADIUS [RFC 2865] o DIAMETER [CAL01]. El<br />
funcionami<strong>en</strong>to básico consiste <strong>en</strong> que un nodo móvil que desea una<br />
asociación segura con un host (Home Ag<strong>en</strong>t o Foreign Ag<strong>en</strong>t) hace una<br />
solicitud de material para crear claves a un servidor AAA. Esta clave se<br />
distribuirá al host implicado vía el protocolo AAA correspondi<strong>en</strong>te.<br />
Tanto <strong>en</strong> estudio anterior de utilización de servidores AAA como <strong>en</strong><br />
otras propuestas, como pued<strong>en</strong> ser los mecanismos de Optimización de<br />
Ruta o de Registro Regional, que se estudiarán <strong>en</strong> los sigui<strong>en</strong>tes puntos,<br />
puede que sea necesario un intercambio de información de material para<br />
formar asociaciones seguras. Para normalizar el proceso de distribución de<br />
claves <strong>en</strong>tre los difer<strong>en</strong>tes host implicados <strong>en</strong> una transmisión con Mobile<br />
IP, reci<strong>en</strong>tem<strong>en</strong>te, <strong>en</strong> [PER02] se ha definido los formatos de las<br />
ext<strong>en</strong>siones g<strong>en</strong>eralizados para cualquier distribución de claves, de<br />
manera que este t<strong>ip</strong>o de transmisiones quede normalizado.<br />
2.3.6 Optimización de la Ruta<br />
El protocolo Mobile IP soluciona los problemas que supone la<br />
exist<strong>en</strong>cia de nodos móviles que cambian de situación conectándose a<br />
distintos <strong>en</strong>laces mi<strong>en</strong>tras manti<strong>en</strong>e conexiones abiertas. Sin embargo el<br />
mecanismo empleado, y que podemos resumir <strong>en</strong> el <strong>en</strong>vío de los paquetes<br />
al nodo, desde un ag<strong>en</strong>te situado <strong>en</strong> su red original, utilizando túneles y<br />
direcciones temporales adquiridas (Care-of Address), ti<strong>en</strong>e algunas<br />
limitaciones.<br />
35
Sistemas de Movilidad <strong>en</strong> redes IP<br />
La princ<strong>ip</strong>al limitación se produce al forzar que todos los<br />
datagramas que se dirig<strong>en</strong> hacia el nodo móvil sean <strong>en</strong>caminados<br />
utilizando el Home Ag<strong>en</strong>t. Este problema se conoce <strong>en</strong> la literatura como<br />
<strong>en</strong>caminami<strong>en</strong>to <strong>en</strong> triángulo y se muestra <strong>en</strong> la figura sigui<strong>en</strong>te.<br />
Nodo móvil <strong>en</strong><br />
una Foreign<br />
Network<br />
Foreign Ag<strong>en</strong>t<br />
Home<br />
Ag<strong>en</strong>t<br />
Foreign Network<br />
Host a Nodo Móvil<br />
Nodo Móvil a Host<br />
Host<br />
Figura 2.8 Encaminami<strong>en</strong>to <strong>en</strong> triángulo<br />
El mecanismo de <strong>en</strong>caminami<strong>en</strong>to de Mobile IP provoca que los<br />
datagramas que se dirijan al nodo móvil sean <strong>en</strong>caminados, a m<strong>en</strong>udo, por<br />
rutas que son significativam<strong>en</strong>te más largas que la ruta óptima. Por<br />
ejemplo, si un nodo móvil está visitando una red, incluso los paquetes que<br />
le <strong>en</strong>víe un host que esté situado <strong>en</strong> esa misma red deberán ser<br />
<strong>en</strong>caminados por la Internet hasta el Home Ag<strong>en</strong>t desde donde serán<br />
redirigidos, por medio de un túnel, a la red original para ser <strong>en</strong>tregados al<br />
nodo móvil. Este <strong>en</strong>caminami<strong>en</strong>to provoca retardos <strong>en</strong> la <strong>en</strong>trega,<br />
inaceptables para aplicaciones <strong>en</strong> tiempo real, así como un innecesario<br />
desperdicio de ancho de banda <strong>en</strong> la red y recursos de los routers.<br />
La solución a este problema se basa <strong>en</strong> lograr que el host fu<strong>en</strong>te<br />
conozca la dirección temporal del nodo móvil, de manera que pueda<br />
<strong>en</strong>caminar los datagramas directam<strong>en</strong>te. Exist<strong>en</strong> varios trabajos<br />
publicados que int<strong>en</strong>tan lograr este objetivo, algunos inclusos previos a la<br />
estandarización del protocolo Mobile IP, [JOH95] y [MYL95]. En este punto<br />
vamos a com<strong>en</strong>tar las ext<strong>en</strong>siones al protocolo Mobile IP más reci<strong>en</strong>tes,<br />
36
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
[PER01], conocidas como “Optimización de Ruta”, y actualm<strong>en</strong>te <strong>en</strong> formato<br />
de Draft (Work in Progress).<br />
La Optimización de Ruta ofrece un mecanismo que permite a los<br />
nodos almac<strong>en</strong>ar información de la situación de un nodo móvil Care-of (<br />
Address), y que permitirá al host <strong>en</strong>viar los datagramas, por medio de un<br />
túnel, directam<strong>en</strong>te a esta dirección. De esta manera se elimina el paso de<br />
los datagramas por el Home Ag<strong>en</strong>t.<br />
Así, un host dispone de una memoria donde almac<strong>en</strong>a la<br />
información de difer<strong>en</strong>tes nodos móviles. Si <strong>en</strong> un instante de tiempo dado<br />
no ti<strong>en</strong>e <strong>en</strong> memoria información sobre el nodo móvil al que desea <strong>en</strong>viar<br />
datos, los datagramas son <strong>en</strong>caminados hacia la Home Network, de la<br />
misma manera que cualquier otro datagrama IP, con el fin de que el Home<br />
Ag<strong>en</strong>t los re<strong>en</strong>víe por medio de un túnel hacia la dirección temporal del<br />
nodo móvil (Care-of Address). Además este ag<strong>en</strong>te se da cu<strong>en</strong>ta de que la<br />
fu<strong>en</strong>te del datagrama no ti<strong>en</strong>e información sobre la dirección temporal del<br />
nodo, y por tanto, le <strong>en</strong>vía un m<strong>en</strong>saje de actualización d<strong>en</strong>ominado <strong>en</strong> la<br />
literatura ‘Binding Update’. Al recibir el m<strong>en</strong>saje, el host fu<strong>en</strong>te actualiza la<br />
información almac<strong>en</strong>ada <strong>en</strong> memoria con el fin de que los datagramas<br />
posteriores puedan <strong>en</strong>viarse utilizando la dirección Care-of Address<br />
realizando un <strong>en</strong>caminami<strong>en</strong>to óptimo.<br />
Un host debe introducir o actualizar información sobre un nodo<br />
móvil <strong>en</strong> su memoria sólo cuando ésta ha sido recibida de una forma<br />
correctam<strong>en</strong>te aut<strong>en</strong>tificada. Además, la información recibida ti<strong>en</strong>e<br />
asociada un tiempo de vida de manera que, una vez concluido este periodo<br />
de tiempo, la información sobre la situación del nodo móvil debe ser<br />
eliminada de la memoria.<br />
Puede ocurrir el caso de que un ag<strong>en</strong>te (Foreign Ag<strong>en</strong>t) reciba un<br />
datagrama dirigido a un nodo móvil que <strong>en</strong> la actualidad ya no se<br />
<strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la red. Esto es debido a que el host que <strong>en</strong>vió el paquete por<br />
medio de un túnel no ti<strong>en</strong>e <strong>en</strong> la memoria la situación del nodo móvil<br />
actualizada. Para resolver la situación el ag<strong>en</strong>te manda un m<strong>en</strong>saje de<br />
alerta (Binding Warning) hacia el Home Ag<strong>en</strong>t del nodo móvil implicado,<br />
37
Sistemas de Movilidad <strong>en</strong> redes IP<br />
solicitándole que le <strong>en</strong>víe un m<strong>en</strong>saje de actualización de situación al host<br />
fu<strong>en</strong>te que mandó el m<strong>en</strong>saje a un destino incorrecto. A difer<strong>en</strong>cia de los<br />
m<strong>en</strong>sajes de actualización de información (Binding Update), los m<strong>en</strong>sajes<br />
de alerta (Binding Warning) no necesitan ser aut<strong>en</strong>tificados porque no<br />
afectan directam<strong>en</strong>te al cambio de ruta de <strong>en</strong>caminami<strong>en</strong>to de la<br />
información.<br />
Podemos resumir el proceso de optimización de ruta com<strong>en</strong>tando<br />
los cuatro t<strong>ip</strong>os de m<strong>en</strong>sajes que se añadirían a los m<strong>en</strong>sajes especificados<br />
<strong>en</strong> el protocolo Mobile IP.<br />
• M<strong>en</strong>saje de Alerta (Binding warning Message): Se utiliza para<br />
indicar que es necesario una actualización de la información sobre<br />
la situación de un nodo móvil por parte del host fu<strong>en</strong>te. Este<br />
m<strong>en</strong>saje es <strong>en</strong>viado por el Foreign Ag<strong>en</strong>t cuando recibe un m<strong>en</strong>saje<br />
que va dirigido para un nodo móvil que ya no está localizado <strong>en</strong> esa<br />
red.<br />
El m<strong>en</strong>saje también es <strong>en</strong>viado por el nodo móvil a su Home Ag<strong>en</strong>t<br />
<strong>en</strong> el mom<strong>en</strong>to que recibe una nueva Care-of Address. De esta<br />
forma solicita que <strong>en</strong>víe m<strong>en</strong>sajes de actualización (Binding<br />
Updates) a uno o más hosts fu<strong>en</strong>te.<br />
• M<strong>en</strong>saje de Solicitud de Información (Binding Request Message):<br />
Se utiliza por un host para solicitar al nodo móvil o a su Home<br />
Ag<strong>en</strong>t información sobre la dirección temporal actual.<br />
• M<strong>en</strong>saje de Actualización de Información (Binding Update<br />
Message): Se utiliza para notificar la dirección temporal de un nodo<br />
móvil. Este m<strong>en</strong>saje debe ser <strong>en</strong>viado por el Home Ag<strong>en</strong>t <strong>en</strong> las<br />
sigui<strong>en</strong>tes situaciones:<br />
o En respuesta a un m<strong>en</strong>saje de solicitud de información.<br />
o En respuesta a un m<strong>en</strong>saje de alerta.<br />
o En respuesta a la recepción de un m<strong>en</strong>saje para un nodo<br />
móvil que se <strong>en</strong>cu<strong>en</strong>tra fuera de la Home Network.<br />
38
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
• M<strong>en</strong>saje de reconocimi<strong>en</strong>to (Binding Acknowledge Message): Se<br />
utiliza para reconocer un m<strong>en</strong>saje de actualización. Sólo es<br />
necesario <strong>en</strong>viarlo si dicho m<strong>en</strong>saje solicitaba respuesta.<br />
El princ<strong>ip</strong>al problema que conlleva este proceso es la<br />
aut<strong>en</strong>tificación de los m<strong>en</strong>sajes relacionados con el cambio de ruta de los<br />
paquetes <strong>en</strong>viados hacia <strong>en</strong> nodo móvil. En el protocolo Mobile IP [RFC<br />
3344], sólo el Home Ag<strong>en</strong>t debe t<strong>en</strong>er información sobre la nueva ubicación<br />
del nodo móvil, pues todo <strong>en</strong> <strong>en</strong>caminami<strong>en</strong>to de los paquetes hacia el<br />
nodo móvil, mi<strong>en</strong>tras está fuera de su red original, se realiza a través de<br />
él. En este caso la aut<strong>en</strong>tificación se alcanza estableci<strong>en</strong>do una asociación<br />
de seguridad <strong>en</strong>tre el Home Ag<strong>en</strong>t y el nodo móvil. Como ambos pert<strong>en</strong>ec<strong>en</strong><br />
a la misma organización (los dos ti<strong>en</strong><strong>en</strong> asignada una dirección IP d<strong>en</strong>tro<br />
de la misma subred), puede realizarse fácilm<strong>en</strong>te una configuración<br />
manual de esta asociación.<br />
Sin embargo, con las ext<strong>en</strong>siones de Optimización de Ruta el<br />
proceso de aut<strong>en</strong>tificación es más complejo, puesto que el intercambio de<br />
información para la gestión de la ruta puede realizarse con cualquier host<br />
de la red. Así, es necesario una asociación de seguridad <strong>en</strong>tre cada host<br />
que desea <strong>en</strong>viar información y el nodo móvil (o Home Ag<strong>en</strong>t) receptor. Al<br />
no existir <strong>en</strong> la actualidad un protocolo de distribución de claves se<br />
manti<strong>en</strong>e la distribución de claves de forma manual utilizada <strong>en</strong> Mobile IP.<br />
La asociación puede ser creada utilizando ISAKMP [RFC 2408] o<br />
cualquiera de los métodos de establecimi<strong>en</strong>to de claves especificado <strong>en</strong><br />
[PER00].<br />
Por otra parte el cálculo del campo de aut<strong>en</strong>tificación es el mismo<br />
que el especificado <strong>en</strong> el protocolo Mobile IP. Exist<strong>en</strong> métodos más efectivos<br />
como el HMAC [RFC 2104] que podría utilizarse una vez sea incorporado al<br />
Mobile IP.<br />
39
Sistemas de Movilidad <strong>en</strong> redes IP<br />
2.3.7 Mobile IP con Registro Regional<br />
Utilizando el protocolo Mobile IP, un nodo móvil se registra con su<br />
Home Ag<strong>en</strong>t cada vez que se mueve de red y, por tanto, modifica su<br />
dirección temporal (Care-of Address). Si la distancia <strong>en</strong>tre la red <strong>en</strong> la que<br />
se <strong>en</strong>cu<strong>en</strong>tra actualm<strong>en</strong>te el nodo y la Home Network es grande, el retardo<br />
ocasionado durante estos registros será demasiado elevado.<br />
Para evitar este problemas reci<strong>en</strong>tem<strong>en</strong>te se han realizado varias<br />
propuestas que que se basan <strong>en</strong> el concepto de micro-<strong>movilidad</strong> y que son<br />
analizadas <strong>en</strong> el punto 2.4. Una de ellas, sin embargo, la ha realizado la<br />
propia IETF actualm<strong>en</strong>te <strong>en</strong> estado de Draft (Work in Progress) [GUS02], y<br />
se ha considerado conv<strong>en</strong>i<strong>en</strong>te estudiarla aquí por estar íntimam<strong>en</strong>te<br />
relacionada con el funcionami<strong>en</strong>to del protocolo Mobile IP.<br />
La propuesta, d<strong>en</strong>ominada Mobile IP con Registro Regional, consiste<br />
básicam<strong>en</strong>te <strong>en</strong> dividir la red <strong>en</strong> agrupaciones de redes que se van a<br />
d<strong>en</strong>ominar Dominios. En cada Dominio habrá una serie de Foreign Ag<strong>en</strong>ts<br />
que se van a estructurar <strong>en</strong> una jerarquía de dos niveles, de manera que<br />
<strong>en</strong> la parte superior existirá al m<strong>en</strong>os un Ag<strong>en</strong>te Pasarela (GFA Gateway<br />
Foreign Ag<strong>en</strong>t) con dirección IP pública y funcionalidades ext<strong>en</strong>didas.<br />
Cuando un nodo móvil llega a un Dominio nuevo debe realizar un<br />
registro con su Home Ag<strong>en</strong>t. La dirección temporal (Care-of Address) que<br />
va a registrar va a ser la dirección pública de un GFA, de manera que se va<br />
a evitar realizar un nuevo registro <strong>en</strong> el Home Ag<strong>en</strong>t mi<strong>en</strong>tras el nodo móvil<br />
permanezca d<strong>en</strong>tro del Dominio. En la figura 2.9 se muestra el mecanismo<br />
de registro que se produce cada vez que el nodo se introduce <strong>en</strong> un nuevo<br />
dominio.<br />
Los nodos móviles pued<strong>en</strong> moverse librem<strong>en</strong>te d<strong>en</strong>tro del dominio<br />
pasando de un Foreign Ag<strong>en</strong>t a otro sin necesidad de t<strong>en</strong>er que realizar un<br />
nuevo registro con el Home Ag<strong>en</strong>t. Al <strong>en</strong>trar <strong>en</strong> una Foreign Network los<br />
nodos obti<strong>en</strong><strong>en</strong> una dirección temporal, ya sea una dirección del Foreign<br />
Ag<strong>en</strong>t (Care-of Address) o una dirección temporal por cualquier otro<br />
método (Co-located Care-of Address). Esta dirección debe ser registrada <strong>en</strong><br />
40
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
el GFA, mediante un Registro Regional, para que este pueda redirigir los<br />
paquetes recibidos desde el Home Ag<strong>en</strong>t hasta el nodo.<br />
Foreign<br />
Ag<strong>en</strong>t<br />
Reg. Req.<br />
Home<br />
Ag<strong>en</strong>t<br />
DOMINIO<br />
Reg. Req.<br />
GFA<br />
Reg. Req.<br />
Foreign<br />
Ag<strong>en</strong>t<br />
Reg. Reply<br />
Reg. Reply<br />
Reg. Reply<br />
Nodo móvil <strong>en</strong><br />
una Foreign<br />
Network<br />
GFA: Gateway Foreign Ag<strong>en</strong>t<br />
Figura 2.9 Registro <strong>en</strong> el Home Ag<strong>en</strong>t<br />
Así los paquetes destinados al nodo serán <strong>en</strong>viados por medio de<br />
un túnel desde el Home Ag<strong>en</strong>t hasta el GFA (sigui<strong>en</strong>do el procedimi<strong>en</strong>to<br />
establecido <strong>en</strong> Mobile IP). Este elem<strong>en</strong>to será el <strong>en</strong>cargado de recibirlos y<br />
de hacerlos llegar al nodo móvil utilizando la información que el nodo ha<br />
proporcionado <strong>en</strong> el nombrado Registro Regional. Es necesario, por tanto,<br />
realizar un nuevo registro regional cada vez que el nodo cambia de red<br />
d<strong>en</strong>tro del dominio. Sin embargo este registro es mucho más rápido que el<br />
registro tradicional hasta el Home Ag<strong>en</strong>t, que podía estar arbitrariam<strong>en</strong>te<br />
lejos.<br />
Para poder realizar este Registro Regional se han definido dos<br />
nuevos t<strong>ip</strong>os de m<strong>en</strong>sajes: ‘Regional Registration Request’ y ‘Regional<br />
Registration reply’. En la figura sigui<strong>en</strong>te se muestra el proceso de este t<strong>ip</strong>o<br />
de registro.<br />
41
Sistemas de Movilidad <strong>en</strong> redes IP<br />
En el estudio [GUS02] se ofrec<strong>en</strong> soluciones para mant<strong>en</strong>er la<br />
seguridad durante todo el proceso mediante el uso de las oportunas<br />
ext<strong>en</strong>siones de aut<strong>en</strong>tificación que utilizan claves obt<strong>en</strong>idas por<br />
mecanismos como la conexión a servidores AAA (punto 2.3.5).<br />
Nodo móvil <strong>en</strong><br />
una Foreign<br />
Network<br />
Regional Registration<br />
Request<br />
Regional Registration<br />
Request<br />
GFA<br />
Gateway<br />
Foreign<br />
Ag<strong>en</strong>t<br />
Regional Registration<br />
Reply<br />
Foreign<br />
Ag<strong>en</strong>t<br />
Regional Registration<br />
Reply<br />
Figura 2.10 Registro Regional.<br />
Por último indicar que aunque hasta ahora se ha supuesto una<br />
jerarquía de Ag<strong>en</strong>tes a dos niveles, la estructura puede ser ext<strong>en</strong>dida para<br />
incluir múlt<strong>ip</strong>les niveles por debajo de GFA.<br />
2.4 SISTEMAS DE MICROMOVILIDAD<br />
La propuesta más conocida para una red IP móvil es la basada <strong>en</strong><br />
el protocolo IP Mobile [RFC 3344] estudiado <strong>en</strong> el punto 2.3. Este<br />
protocolo, sin negar las v<strong>en</strong>tajas ya com<strong>en</strong>tadas que aporta al problema de<br />
la <strong>movilidad</strong>, ti<strong>en</strong>e muchas limitaciones. Algunas de estas limitaciones son<br />
la necesidad de un Registro cada vez que el nodo móvil cambia de red, la<br />
incapacidad para soportar el movimi<strong>en</strong>to rápido de los nodos, o los<br />
problemas que surg<strong>en</strong> para ofrecer QoS utilizando protocolos tradicionales<br />
como RSVP [RFC 2205].<br />
42
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
Para solucionar estas limitaciones <strong>en</strong> la actualidad han surgido un<br />
conjunto de soluciones que se basan <strong>en</strong> el concepto de dividir el problema<br />
de la <strong>movilidad</strong> <strong>en</strong> dos partes: macro-<strong>movilidad</strong> y micro-<strong>movilidad</strong>. Así<br />
podemos definir micro-<strong>movilidad</strong> como el movimi<strong>en</strong>to de los nodos móviles<br />
d<strong>en</strong>tro de un nivel local, que se puede d<strong>en</strong>ominar dominio. El concepto de<br />
macro-<strong>movilidad</strong> se refiere al movimi<strong>en</strong>to de los nodos <strong>en</strong>tre estos<br />
dominios.<br />
Los protocolos de micro-<strong>movilidad</strong> ti<strong>en</strong><strong>en</strong> pues como objetivo el<br />
superar las limitaciones de Mobile IP: limitar las interrupciones <strong>en</strong> el flujo<br />
de datos durante el handover; aum<strong>en</strong>tar la efici<strong>en</strong>cia <strong>en</strong> el uso de la red,<br />
eliminando <strong>en</strong>rutami<strong>en</strong>tos innecesarios; mejorar la escalabilidad,<br />
reduci<strong>en</strong>do las actualizaciones hacia el Home Ag<strong>en</strong>t; y proporcionar un<br />
soporte para QoS, por ejemplo limitando el número de reservas que deb<strong>en</strong><br />
de ser reestablecidas cuando el nodo móvil se mueve.<br />
La mayoría de las soluciones que se van a mostrar se basan <strong>en</strong><br />
Mobile IP para soportar la macro-<strong>movilidad</strong>, difer<strong>en</strong>ciándose <strong>en</strong> la forma de<br />
implem<strong>en</strong>tar la micro-<strong>movilidad</strong>. Puede hacerse una s<strong>en</strong>cilla clasificación<br />
de estas soluciones:<br />
• Esquemas de ag<strong>en</strong>tes de <strong>movilidad</strong> jerárquicos, como pued<strong>en</strong> ser<br />
el ya com<strong>en</strong>tado Mobile IP con Registro Regional MIP-RR, [GUS02],<br />
o la arquitectura TeleMIP [DAS00].<br />
• Esquemas de <strong>en</strong>caminami<strong>en</strong>to <strong>basado</strong> <strong>en</strong> host (HBR). Ejemplos<br />
de estos son: Cellular IP [VAL99], [CAM00], HAWAII [RAM99], MMP<br />
[DUT01] o EMA [ONE00].<br />
A continuación se van a com<strong>en</strong>tar las propuestas Cellular IP,<br />
HAWAII, TeleMIP y EMA por ser las más significativas y las más<br />
refer<strong>en</strong>ciadas <strong>en</strong> la bibliografía. Como <strong>en</strong> puntos anteriores el objetivo es<br />
mostrar la variedad de propuestas exist<strong>en</strong>tes. Estudios más detallados<br />
sobre éstas y sobre MMP (que detalla un protocolo de <strong>movilidad</strong> para<br />
<strong>en</strong>tornos militares) pued<strong>en</strong> <strong>en</strong>contrarse <strong>en</strong> la bibliografía m<strong>en</strong>cionada.<br />
Indicar que la propuesta MIP-RR ya fue estudiada <strong>en</strong> el punto 2.3.7<br />
43
Sistemas de Movilidad <strong>en</strong> redes IP<br />
Existe, además, diversa bibliografía donde puede <strong>en</strong>contrarse<br />
comparaciones y análisis de prestaciones de las difer<strong>en</strong>tes propuestas,<br />
como por ejemplo: [REI01], [WON01] y [EAR00].<br />
2.4.1 CELLULAR IP<br />
Cellular IP [VAL99], [CAM00] es un protocolo de micro-<strong>movilidad</strong><br />
que ha sido desarrollado <strong>en</strong> la universidad de Columbia. Proporciona<br />
soporte de <strong>movilidad</strong> <strong>en</strong> áreas geográficas limitadas, incorporando<br />
numerosos princ<strong>ip</strong>ios de diseño de los sistemas celulares como puede ser<br />
la conexión pasiva, la gestión de la <strong>movilidad</strong> o <strong>en</strong> control del handover.<br />
La arquitectura de Cellular IP consta de un ag<strong>en</strong>te de <strong>movilidad</strong><br />
(MA) que actúa como pasarela a la red IP y como Foreign Ag<strong>en</strong>t de Mobile<br />
IP. Este ag<strong>en</strong>te es el <strong>en</strong>cargado de gestionar un dominio que está<br />
compuesto por un conjunto de estaciones base (BS, Base Station). Las<br />
estaciones base, además de funcionar como punto de acceso inalámbrico,<br />
<strong>en</strong>camina los paquetes IP, e integra las funcionalidades de control de celda<br />
que <strong>en</strong> los sistemas celulares tradicionales (como GSM) están asignadas a<br />
los C<strong>en</strong>tros de Conmutación Móvil (MSC Mobile Switching C<strong>en</strong>ters) y los<br />
Controladores de Estación Base (BSC Base Station Controllers). En la<br />
figura 2.11 se muestre esta arquitectura.<br />
La <strong>movilidad</strong> <strong>en</strong>tre dominios (macro-<strong>movilidad</strong>) se realiza por medio<br />
de Mobile IP, mi<strong>en</strong>tras que d<strong>en</strong>tro de un dominio se utiliza el protocolo de<br />
<strong>en</strong>caminami<strong>en</strong>to propio de Cellular IP. Así, suponi<strong>en</strong>do Mobile IPv4 y sin<br />
optimización de ruta (punto 2.3.6), los paquetes son dirigidos hacia el<br />
Home Ag<strong>en</strong>t que los <strong>en</strong>vía por medio de un túnel hacia el Ag<strong>en</strong>te de<br />
Movilidad (MA) que realiza las funciones de un Foreign Ag<strong>en</strong>t. Éste<br />
des<strong>en</strong>capsula los paquetes originales y los dirige a las estaciones base.<br />
Puesto que d<strong>en</strong>tro de la red Cellular IP los nodos móviles son id<strong>en</strong>tificados<br />
por su Home Address, los paquetes son <strong>en</strong>caminados sin ningún t<strong>ip</strong>o de<br />
<strong>en</strong>capsulación o conversión de direcciones.<br />
44
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
Home Ag<strong>en</strong>t<br />
MA<br />
Estación<br />
Base A<br />
Estación<br />
Base B<br />
Host Fu<strong>en</strong>te<br />
Estación<br />
Base C<br />
Figura 2.11 Arquitectura Cellular IP<br />
En Cellular IP, tanto la gestión de la localización del nodo móvil<br />
como el soporte del handover están integrados junto al <strong>en</strong>caminami<strong>en</strong>to.<br />
Periódicam<strong>en</strong>te el MA <strong>en</strong>vía por difusión un m<strong>en</strong>saje de control que inunda<br />
el dominio. Las estaciones base almac<strong>en</strong>an el interfaz por el que recib<strong>en</strong><br />
este m<strong>en</strong>saje, de manera que lo utilizan para <strong>en</strong>caminar todos los paquetes<br />
<strong>en</strong>viados por los nodos móviles hacia el MA.<br />
Para minimizar el tráfico de control, los paquetes de datos son<br />
utilizados para establecer la localización del nodo d<strong>en</strong>tro del dominio.<br />
Estos paquetes son <strong>en</strong>caminados hacia el MA y el camino recorrido es<br />
almac<strong>en</strong>ado por las estaciones base para <strong>en</strong>caminar los paquetes que van<br />
dirigidos a ese nodo móvil. Esta información ti<strong>en</strong>e un tiempo de vida, de tal<br />
manera que si no existe un refresco la Estación Base la elimina.<br />
En ocasiones un nodo desea que se mant<strong>en</strong>ga la información de<br />
<strong>en</strong>caminami<strong>en</strong>to <strong>en</strong> los routers y estaciones base aún cuando el no está<br />
transmiti<strong>en</strong>do. Un ejemplo sería cuando el móvil está recibi<strong>en</strong>do un flujo<br />
de paquetes UDP y no ti<strong>en</strong>e datos que transmitir. En este caso, si un nodo<br />
no tuviera información a transmitir periódicam<strong>en</strong>te <strong>en</strong>viaría paquetes<br />
45
Sistemas de Movilidad <strong>en</strong> redes IP<br />
vacíos hacia el Ag<strong>en</strong>te de Movilidad para mant<strong>en</strong>er la información de<br />
<strong>en</strong>caminami<strong>en</strong>to d<strong>en</strong>tro de la red Cellular IP.<br />
Por último m<strong>en</strong>cionar que este protocolo se ha pres<strong>en</strong>tado<br />
reci<strong>en</strong>tem<strong>en</strong>te para <strong>en</strong>tornos IPv6. En la actualidad está <strong>en</strong> estado ‘Draft’<br />
(Work in Progress) [SHE01].<br />
2.4.2 HAWAII<br />
El protocolo HAWAII (Handover-Aware Wireless Access Internet<br />
Infrastructure) [RAM99] fue propuesto por los investigadores de los<br />
laboratorios Luc<strong>en</strong>t Bell <strong>en</strong> 1999. Al igual que Cellular IP, HAWAII es un<br />
protocolo de micro-<strong>movilidad</strong> que se implem<strong>en</strong>ta d<strong>en</strong>tro de un dominio,<br />
basándose <strong>en</strong> Mobile IP para soportar macro-<strong>movilidad</strong>.<br />
Los princ<strong>ip</strong>ios de funcionami<strong>en</strong>to son similares a Cellular IP,<br />
utilizando esquemas de establecimi<strong>en</strong>to de rutas que actualizan las tablas<br />
de <strong>en</strong>rutami<strong>en</strong>to basadas <strong>en</strong> host de los routers del dominio. Sin embargo<br />
Cellular IP se basa <strong>en</strong> una pasarela que actúa como FA (Foreign Ag<strong>en</strong>t)<br />
des<strong>en</strong>capsulando los paquetes antes de <strong>en</strong>tregarlos al Dominio mi<strong>en</strong>tras<br />
que <strong>en</strong> HAWAII el móvil obti<strong>en</strong>e una Co-located Address, que manti<strong>en</strong>e<br />
durante toda su estancia <strong>en</strong> el dominio, y los paquetes son <strong>en</strong>rutados<br />
directam<strong>en</strong>te hasta el nodo móvil.<br />
La arquitectura de red está formada por dominios, cada uno de los<br />
cuales consta de estaciones base con capacidad de <strong>en</strong>caminami<strong>en</strong>to. Estas<br />
estaciones están organizadas <strong>en</strong> un esquema jerárquico y <strong>en</strong> la parte<br />
superior de la jerarquía existe un router raíz (d<strong>en</strong>ominado DRR, Domain<br />
Root Router) que actúa como pasarela hacia la Internet.<br />
Cada nodo móvil consta de una dirección perman<strong>en</strong>te (Home<br />
Address). Mi<strong>en</strong>tras el nodo se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> su dominio los paquetes son<br />
<strong>en</strong>caminados hasta el DRR utilizando el id<strong>en</strong>tificativo de subred del<br />
dominio.<br />
46
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
Evid<strong>en</strong>tem<strong>en</strong>te el nodo móvil puede cambiar de dominio. Cuando el<br />
nodo se sitúa <strong>en</strong> un dominio HAWAII difer<strong>en</strong>te al suyo obti<strong>en</strong>e una Colocated<br />
Care-of Address pert<strong>en</strong>eci<strong>en</strong>te al rango de direcciones de este<br />
dominio que utilizará el HA (Home Ag<strong>en</strong>t) para <strong>en</strong>viar los paquetes<br />
utilizando un túnel, exactam<strong>en</strong>te igual que <strong>en</strong> Mobile IP. El nodo móvil no<br />
necesita cambiar esta nueva dirección que acaba de adquirir mi<strong>en</strong>tras se<br />
mueve d<strong>en</strong>tro del dominio y la conectividad se mant<strong>en</strong>drá utilizando rutas<br />
establecidas dinámicam<strong>en</strong>te.<br />
HAWAII gestiona la <strong>movilidad</strong> de los nodos de una manera similar a<br />
Cellular IP utilizando un mecanismo de salto a salto (hop-by-hop). De esta<br />
manera cada estación manti<strong>en</strong>e una tabla <strong>en</strong> memoria donde se indica<br />
hacia donde <strong>en</strong>caminar los paquetes destinados a los distintos nodos<br />
móviles. Para establecer y mant<strong>en</strong>er estas rutas dinámicas se utilizan tres<br />
t<strong>ip</strong>os de m<strong>en</strong>sajes: Establecimi<strong>en</strong>to (Power-Up), Actualización (Update) y<br />
Refresco (Refresh).<br />
Cuando un móvil se conecta a un nuevo dominio <strong>en</strong>vía un m<strong>en</strong>saje<br />
de Establecimi<strong>en</strong>to. Este m<strong>en</strong>saje hace que se añada una <strong>en</strong>trada <strong>en</strong> las<br />
tablas de las estaciones base que están situadas <strong>en</strong> el camino hacia el<br />
DRR. Las demás estaciones base no t<strong>en</strong>drán conocimi<strong>en</strong>to, por ahora, de<br />
la exist<strong>en</strong>cia de este nodo móvil <strong>en</strong> el dominio.<br />
Para mant<strong>en</strong>er la conectividad extremo-extremo mi<strong>en</strong>tras el nodo<br />
móvil se mueve librem<strong>en</strong>te por el dominio se utiliza el m<strong>en</strong>saje de<br />
Actualización que se traducirá <strong>en</strong> la modificación de las <strong>en</strong>tradas de las<br />
tablas de las estaciones base. Exist<strong>en</strong> diversos esquemas de actualización<br />
que especifican cuando y a quién se <strong>en</strong>vían estos m<strong>en</strong>sajes. El primer<br />
mecanismo se d<strong>en</strong>omina Dirigido (Forwarding) y se utiliza cuando el nodo<br />
móvil sólo ti<strong>en</strong>e capacidad para comunicarse con un transceiver (por<br />
ejemplo terminales <strong>en</strong> redes GPRS). El segundo, d<strong>en</strong>ominado No Dirigido<br />
(Non-Forwarding), suele preferirse <strong>en</strong> casos <strong>en</strong> las que el nodo ti<strong>en</strong>e<br />
capacidad para comunicarse con más de un transceiver (por ejemplo redes<br />
basadas <strong>en</strong> CDMA como UMTS). Estos esquemas serán com<strong>en</strong>tados con<br />
más detalle <strong>en</strong> el tema <strong>en</strong> el que se trate el mecanismo de Handover.<br />
47
Sistemas de Movilidad <strong>en</strong> redes IP<br />
Por último para mant<strong>en</strong>er la información de las rutas <strong>en</strong> las<br />
estaciones periódicam<strong>en</strong>te es necesario <strong>en</strong>viar m<strong>en</strong>sajes de Refresco que se<br />
transmitirán hasta el DRR. Además <strong>en</strong> [RAM00] se incorpora, al protocolo<br />
HAWAII original, un sistema de mant<strong>en</strong>imi<strong>en</strong>to (Paging) similar al exist<strong>en</strong>te<br />
<strong>en</strong> Cellular IP, de manera que el nodo puede estar <strong>en</strong> reposo y sólo <strong>en</strong>vía<br />
un m<strong>en</strong>saje de mant<strong>en</strong>imi<strong>en</strong>to cuando cambia de área<br />
Los últimos trabajos publicados [RAM00b] pres<strong>en</strong>tan una<br />
arquitectura de red de acceso basada <strong>en</strong> IP (Mobile IP y HAWAII) que puede<br />
funcionar sobre tecnologías celulares exist<strong>en</strong>tes como GPRS.<br />
2.4.3 TeleMIP<br />
TeleMIP [DAS00] es una propuesta s<strong>en</strong>cilla para gestionar la micro<strong>movilidad</strong><br />
y bi<strong>en</strong> adaptada para funcionar <strong>en</strong> redes CDMA. Como las<br />
soluciones anteriores se basa <strong>en</strong> la utilización de Mobile IP para ofrece<br />
macro-<strong>movilidad</strong>.<br />
La red TeleMIP está compuesta por routers y estaciones base con<br />
capacidad de conmutación. La red se divide <strong>en</strong> subredes cada una de las<br />
cuales compuesta por estaciones base y al m<strong>en</strong>os un router que actúa<br />
como FA (Foreign Ag<strong>en</strong>t). Además se define un nuevo t<strong>ip</strong>o de host<br />
d<strong>en</strong>ominado Ag<strong>en</strong>te de Movilidad TeleMIP (TMA, TeleMIP Mobility Ag<strong>en</strong>t).<br />
Cada FA debe poder conectar con al m<strong>en</strong>os un TMA de la red. En la figura<br />
2.12 puede observarse la arquitectura.<br />
Cuando un nodo móvil se conecta a una red TeleMIP obti<strong>en</strong>e dos<br />
direcciones temporales del FA local. La primera es la conocida Care-of<br />
Address que se registra <strong>en</strong> un TMA y permanecerá válida mi<strong>en</strong>tras el móvil<br />
se mant<strong>en</strong>ga <strong>en</strong> la red TeleMIP. Esta dirección es la que se registrará <strong>en</strong> el<br />
HA (Home Ag<strong>en</strong>t) utilizando el conocido protocolo Mobile IP. Además existe<br />
una segunda dirección temporal que sólo es válida para la subred donde se<br />
<strong>en</strong>cu<strong>en</strong>tra y, por tanto, cambiará cada vez que el nodo móvil cambie de<br />
subred.<br />
48
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
TMA<br />
Subred 2<br />
TMA<br />
FA<br />
Subred 1<br />
FA<br />
Nodo<br />
Móvil<br />
Figura 2.12 Arquitectura TeleMIP<br />
Así, cada vez que un nodo móvil cambia de subred obti<strong>en</strong>e una<br />
segunda dirección temporal e informa a su TMA asociado. Para realizar<br />
este registro los nodos móviles utilizan un protocolo d<strong>en</strong>ominado IDMP<br />
(Intra-Domain Mobility Managem<strong>en</strong>t Protocol) definido <strong>en</strong> [MIS00]. La<br />
asignación de un TMA a un nodo móvil <strong>en</strong> particular es irrelevante<br />
(aunque se manti<strong>en</strong>e constante durante toda la estancia del nodo <strong>en</strong> la<br />
red) y se suele utilizar algoritmos para equilibrar la carga de gestión <strong>en</strong>tre<br />
todos los TMAs exist<strong>en</strong>tes. Hay que recordar que el TMA funcionará como<br />
pasarela y FA del protocolo Mobile IP para ese nodo.<br />
El funcionami<strong>en</strong>to es bastante s<strong>en</strong>cillo. Sigui<strong>en</strong>do el protocolo<br />
Mobile IP los paquetes dirigidos a un nodo se <strong>en</strong>viarán por medio de un<br />
túnel utilizando la dirección Care-of Address. Una vez llega a la red<br />
TeleMIP, el TMA asociado a ese nodo intercepta ese paquete y lo redirige a<br />
la subred donde está situado el nodo móvil <strong>en</strong> ese mom<strong>en</strong>to. Para este<br />
proceso se utiliza un túnel con la segunda dirección temporal del nodo<br />
móvil que el TMA ti<strong>en</strong>e almac<strong>en</strong>ada. Por último el FA de esa subred<br />
<strong>en</strong>trega el paquete al nodo móvil.<br />
49
Sistemas de Movilidad <strong>en</strong> redes IP<br />
La arquitectura TeleMIP ofrece algunas v<strong>en</strong>tajas con respecto a<br />
otros esquemas como son: lograr actualizaciones de <strong>movilidad</strong> rápidas;<br />
posibilidad de utilizar un rango de direcciones privadas d<strong>en</strong>tro de un<br />
dominio, superando la limitación de direcciones exist<strong>en</strong>tes IPv4 [RFC 791];<br />
o proporcionar transmisión con QoS, ya que protocolos como RSVP [RFC<br />
2205] no trabajan bi<strong>en</strong> si la dirección destino de un flujo cambia<br />
frecu<strong>en</strong>tem<strong>en</strong>te.<br />
Indicar que la base de TeleMIP fue anteriorm<strong>en</strong>te propuesta <strong>en</strong> un<br />
draft [JON99], (actualizada <strong>en</strong> [GUS02]) donde se desarrollaba un<br />
mecanismo para realizar los registros localm<strong>en</strong>te cuando el móvil se<br />
situaba <strong>en</strong> redes difer<strong>en</strong>tes de su Home Network (punto 2.3.6). La<br />
propuesta, igual que TeleMIP, utiliza una pasarela d<strong>en</strong>ominada GFA<br />
(Gateway Foreign Ag<strong>en</strong>t) situada <strong>en</strong> un nivel más alto de una jerarquía de<br />
FA y se <strong>en</strong>carga de proporcionar una dirección útil mi<strong>en</strong>tras el nodo se<br />
mant<strong>en</strong>ga <strong>en</strong> ese dominio. Aún así exist<strong>en</strong> algunas difer<strong>en</strong>cias como por<br />
ejemplo que TeleMIP ofrece una arquitectura completa, no sólo un<br />
protocolo, además de proponer un modelo de seguridad más s<strong>en</strong>cillo y<br />
viable que el registro regional propuesto por el IETF.<br />
Por último indicar que esta arquitectura se <strong>en</strong>cu<strong>en</strong>tra actualm<strong>en</strong>te<br />
<strong>en</strong> desarrollo. Así, <strong>en</strong> [CHA01] se puede <strong>en</strong>contrar un primer estudio de las<br />
prestaciones, basándose <strong>en</strong> un banco de pruebas <strong>en</strong> el que no existe una<br />
implem<strong>en</strong>tación completa de todas las funcionalidades. Además se han<br />
desarrollado un mecanismo para soportar handovers rápidos y paging<br />
[MIS01], y un marco de trabajo para incorporar garantías QoS <strong>en</strong> la red<br />
TeleMIP [MIS00b].<br />
2.4.4 Edge Mobility Architecture, EMA<br />
EMA [ONE00] define un marco de trabajo para gestionar la<br />
<strong>movilidad</strong> d<strong>en</strong>tro de un dominio que trabaja sobre IP, y puede utilizar<br />
difer<strong>en</strong>tes redes de acceso radio (TDMA, CDMA, ...). EMA se compone de<br />
dos partes: Una arquitectura g<strong>en</strong>érica, y una particularización de esos<br />
50
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
princ<strong>ip</strong>ios utilizando el protocolo de <strong>en</strong>caminami<strong>en</strong>to TORA [PAR97]. TORA<br />
es un protocolo de <strong>en</strong>caminami<strong>en</strong>to adaptativo diseñado para redes<br />
móviles ad-doc (MANET Mobile Ad-hoc NETwork) que <strong>en</strong> EMA se adapta<br />
para el caso especial de redes de acceso inalámbricas.<br />
EMA define una arquitectura de red similar a las otras propuestas<br />
de micro-<strong>movilidad</strong>. El elem<strong>en</strong>to base es el d<strong>en</strong>ominado Router de Acceso<br />
(AR, Access Router) que pot<strong>en</strong>cialm<strong>en</strong>te puede estar conectado a estaciones<br />
radio base de cualquier tecnología. Cada AR está conectado a una subred<br />
compuesta por estas estaciones base y maneja un bloque de direcciones<br />
IP. La <strong>movilidad</strong> de los móviles d<strong>en</strong>tro de una subred está gestionada por<br />
los niveles radio (nivel 2), y por tanto EMA se <strong>en</strong>carga de gestionar la<br />
<strong>movilidad</strong> <strong>en</strong>tre ARs de un dominio. Por último algunos de los routers que<br />
están <strong>en</strong> el límite del dominio actúan como pasarela a la Internet. La<br />
<strong>movilidad</strong> inter-dominios se realiza, como <strong>en</strong> todos los casos anteriores,<br />
utilizando Mobile IP.<br />
Cuando un nodo móvil se conecta a una red de acceso inalámbrica<br />
contacta con el AR que está conectado a la estación base utilizada. Este<br />
router asigna una dirección IP al nodo que será utilizada durante la<br />
estancia <strong>en</strong> el dominio. Mi<strong>en</strong>tras el nodo está situado <strong>en</strong> esa subred local,<br />
podrá recibir paquetes <strong>en</strong>caminados utilizando el id<strong>en</strong>tificativo de red,<br />
exactam<strong>en</strong>te igual que cualquier nodo fijo. Cuando el nodo cambie de<br />
subred se incorporarán rutas específicas <strong>en</strong> los routers que permitan<br />
alcanzarlo, utilizando para ello el m<strong>en</strong>cionado protocolo TORA,<br />
conv<strong>en</strong>i<strong>en</strong>tem<strong>en</strong>te modificado.<br />
2.5 SISTEMA DE MOVILIDAD BASADO EN MULTICAST<br />
Hasta el mom<strong>en</strong>to todos los sistemas de <strong>movilidad</strong> de Nivel de Red<br />
estudiados utilizaban técnicas de ‘Tunneling’ como Mobile IP o bi<strong>en</strong> de<br />
‘Enrutami<strong>en</strong>to Basado <strong>en</strong> Host’ como algunos de los sistemas de micro<strong>movilidad</strong>.<br />
En este punto se van a com<strong>en</strong>tar algunos estudios que utilizan<br />
las capacidades de transmisión <strong>multicast</strong> para ofrecer <strong>movilidad</strong>,<br />
51
Sistemas de Movilidad <strong>en</strong> redes IP<br />
recordando que la solución de <strong>movilidad</strong> propuesta <strong>en</strong> esta tesis se<br />
<strong>en</strong>cuadraría <strong>en</strong> este apartado.<br />
La utilización de capacidades de transmisión <strong>multicast</strong> para ofrecer<br />
<strong>movilidad</strong> aporta numerosas v<strong>en</strong>tajas. Estas v<strong>en</strong>tajas son debidas,<br />
princ<strong>ip</strong>alm<strong>en</strong>te, a que ambas tecnologías ti<strong>en</strong><strong>en</strong> <strong>en</strong> común la necesidad de<br />
resolver problemas similares, como el proporcionar una abstracción de la<br />
localización indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de la dirección, el <strong>en</strong>caminami<strong>en</strong>to de los<br />
paquetes, y la gestión de la localización.<br />
2.5.1 J. Mysore. MSM-IP (Mobility Support using Multicast in IP)<br />
En [MYS97] se describe las equival<strong>en</strong>cias exist<strong>en</strong>tes <strong>en</strong>tre la<br />
transmisión <strong>multicast</strong> y la <strong>movilidad</strong>. Utilizando esta característica se<br />
propone la implem<strong>en</strong>tación de la <strong>movilidad</strong>, asignando a cada nodo móvil<br />
una dirección <strong>multicast</strong> única que permita la utilización de la<br />
infraestructura <strong>multicast</strong> exist<strong>en</strong>te sin necesidad de realizar cambios<br />
importantes.<br />
La propuesta de la utilización de las capacidades <strong>multicast</strong> como<br />
mecanismo para proporcionar <strong>movilidad</strong> difiere de otros mecanismos como<br />
Mobile IP <strong>en</strong> varios aspectos que mostramos a continuación:<br />
• Direccionami<strong>en</strong>to: Asignamos a cada nodo móvil una dirección<br />
<strong>multicast</strong> única e invariante. Esto elimina la necesidad de la<br />
exist<strong>en</strong>cia del Home Ag<strong>en</strong>t, así como de todos los mecanismos de<br />
traducción de direcciones.<br />
• Encaminami<strong>en</strong>to de los paquetes: Se elimina la limitación del<br />
<strong>en</strong>caminami<strong>en</strong>to triangular típico de Mobile IP. Por el contrario es<br />
necesario la exist<strong>en</strong>cia de routers que soport<strong>en</strong> <strong>multicast</strong> <strong>en</strong> todas<br />
las subredes.<br />
• Gestión de la Localización: Tradicionalm<strong>en</strong>te cuando un host<br />
quería transmitir información a un nodo móvil utilizaba su<br />
52
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
dirección perman<strong>en</strong>te. Los paquetes eran interceptados por el<br />
Home Ag<strong>en</strong>t que conocía <strong>en</strong> todo mom<strong>en</strong>to la situación actual del<br />
nodo. Con el esquema propuesto no existe este concepto y para<br />
localizar el nodo móvil es necesario utilizar un algoritmo<br />
distribuido. Aquí se propone la utilización de servidores de<br />
localización que almac<strong>en</strong>an la información del router <strong>multicast</strong> a<br />
utilizar para alcanzar el nodo móvil. Por ejemplo si se utilizara el<br />
protocolo PIM-SM [RFC 2362] se indicaría el ‘R<strong>en</strong>dezvous Point’.<br />
Esta solución ti<strong>en</strong>e algunas v<strong>en</strong>tajas, las cuales han sido<br />
determinantes para la elección de este t<strong>ip</strong>o de transmisión <strong>en</strong> el modelo de<br />
<strong>movilidad</strong> desarrollado <strong>en</strong> esta tesis. Por ejemplo podríamos indicar la<br />
posibilidad de utilizar RSVP [RFC 2205] para garantizar QoS o de<br />
desarrollar mecanismos de handover muy efectivos. Sin embargo el<br />
sistema tal cual lo propone J. Mysore ti<strong>en</strong>e algunos problemas tanto de<br />
escalabilidad (por la limitación de direcciones <strong>multicast</strong>) como de<br />
implem<strong>en</strong>tación. Algunos de estos últimos se com<strong>en</strong>tan a continuación:<br />
• Respuesta a los m<strong>en</strong>sajes ARP. Cuando un nodo móvil <strong>en</strong>vía una<br />
solicitud ARP [RFC 826] recibirá una contestación con su dirección<br />
<strong>multicast</strong> como dirección destino. Por defecto estos paquetes no<br />
son procesados por lo que habría que modificar esto.<br />
• Funcionami<strong>en</strong>to del protocolo TCP. Debido a la complejidad que<br />
implicaría, TCP no puede trabajar sobre <strong>multicast</strong>. Sin embargo <strong>en</strong><br />
el esquema propuesto la dirección <strong>multicast</strong> está asignada a un<br />
nodo móvil concreto, por lo que la exist<strong>en</strong>cia de un único destino<br />
está garantizada. Esto conlleva que no exista ninguna difer<strong>en</strong>cia<br />
real con una dirección unicast y que la solución simplem<strong>en</strong>te<br />
consista <strong>en</strong> modificar el protocolo TCP de los nodos móviles para<br />
que acept<strong>en</strong> paquetes TCP con su dirección <strong>multicast</strong> como<br />
dirección destino. En la actualidad han sido propuestas numerosas<br />
soluciones al problema de las transmisiones fiables <strong>multicast</strong> como<br />
podría ser RMTP [LIN96] que <strong>en</strong> caso de prosperar podría<br />
introducirse <strong>en</strong> este esquema.<br />
53
Sistemas de Movilidad <strong>en</strong> redes IP<br />
• M<strong>en</strong>sajes ICMP: Cuando un router detecta un error <strong>en</strong> una<br />
transmisión de un paquete <strong>en</strong>vía un m<strong>en</strong>saje ICMP de error a la<br />
fu<strong>en</strong>te para informarle de dicho suceso. Sin embargo esto no podrá<br />
realizarse debido a que la dirección destino es ahora una dirección<br />
<strong>multicast</strong>.<br />
Una solución propuesta por el autor para estos y otros problemas<br />
de implem<strong>en</strong>tación es la de hacer que los nodos móviles obt<strong>en</strong>gan una<br />
dirección unicast temporal d<strong>en</strong>tro de la subred donde se <strong>en</strong>cu<strong>en</strong>tran, por<br />
ejemplo vía DHCP [RFC 2131], para utilizarla <strong>en</strong> los mecanismos propios<br />
de la gestión del nivel de red ya com<strong>en</strong>tados.<br />
Las limitaciones com<strong>en</strong>tadas han sido resueltas <strong>en</strong> [MYS98]<br />
modificando los protocolos antes m<strong>en</strong>cionados, y se ha realizado un<br />
análisis de prestaciones del esquema implem<strong>en</strong>tando un banco de pruebas<br />
<strong>en</strong> laboratorio.<br />
Otro trabajo interesante se detalla <strong>en</strong> [HEL00]. De igual manera<br />
que J. Mysore, Ahmed Helmy asigna a cada usuario móvil una dirección<br />
<strong>multicast</strong>, utilizando como protocolo PIM-SM [RFC 2362]. La princ<strong>ip</strong>al<br />
aportación que ofrece este autor es el de haber realizado un análisis de<br />
prestaciones utilizando simulaciones de un <strong>en</strong>torno como Internet. Estos<br />
estudios demuestran unas mejoras muy significativas con respecto a los<br />
sistemas tradicionales de <strong>movilidad</strong> como Mobile IP <strong>en</strong> aspectos tan<br />
importantes como ancho de banda consumido, o retardos durante el<br />
handover.<br />
2.5.2 Daedalus<br />
En el proyecto Daedalus [SES97] se utiliza también<br />
direccionami<strong>en</strong>to <strong>multicast</strong>, pero se manti<strong>en</strong>e una arquitectura a dos<br />
niveles similar a Mobile IP. Los paquetes son <strong>en</strong>viados hacia la Home<br />
Network de manera tradicional, puesto que cada nodo móvil sigue<br />
disponi<strong>en</strong>do de una dirección perman<strong>en</strong>te (Home Address).<br />
54
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
El Home Ag<strong>en</strong>t interceptará los paquetes dirigidos hacia el nodo,<br />
utilizando un mecanismo Proxy ARP, y los re<strong>en</strong>viará a una o más<br />
estaciones base donde se <strong>en</strong>cu<strong>en</strong>tre el nodo móvil. Este <strong>en</strong>vío se realizará<br />
utilizando las capacidades <strong>multicast</strong>. Así, cada nodo móvil ti<strong>en</strong>e asignada<br />
una dirección <strong>multicast</strong>, que será utilizada por el Home Ag<strong>en</strong>t para<br />
<strong>en</strong>capsular los paquetes y <strong>en</strong>viarlos hacia las estaciones base <strong>en</strong> las que se<br />
<strong>en</strong>cu<strong>en</strong>tra el nodo. Estas estaciones deberán, por tanto, haberse subscrito<br />
al grupo <strong>multicast</strong> de la dirección del nodo móvil.<br />
Las estaciones son capaces de conocer que nodos móviles están <strong>en</strong><br />
la celda controladas por ellas <strong>en</strong>viando periódicam<strong>en</strong>te señales indicativas.<br />
El nodo las recibe, y <strong>en</strong> función de la pot<strong>en</strong>cia y calidad de estas señales,<br />
decide solicitar a la estación base que se subscriba al grupo <strong>multicast</strong> de<br />
su dirección. De esta manera la estación base empezará a almac<strong>en</strong>ar<br />
paquetes dirigidos al nodo. Un nuevo m<strong>en</strong>saje del nodo indicará que ha<br />
ingresado completam<strong>en</strong>te <strong>en</strong> la celda y que, por tanto, puede hacerse cargo<br />
del <strong>en</strong>vío de los paquetes hacia él. Con este esquema de Handover se<br />
minimiza las pérdidas y el retardo del proceso de cambio de celda.<br />
2.6 IP MOBILE v6<br />
Como se ha estudiado, Mobile IP [RFC 3344] está diseñado para<br />
trabajar con la versión 4 del protocolo IP [RFC 791]. La estandarización de<br />
una nueva versión de este protocolo [RFC 2460] ha llevado al grupo de<br />
trabajo Mobile IP del IETF a realizar una adaptación del protocolo para que<br />
trabaje con esta nueva versión del famoso protocolo de red. En este s<strong>en</strong>tido<br />
el protocolo Mobile IPv6 está todavía <strong>en</strong> estado de Draft (Work in Progress)<br />
[JOH03] a pesar de que la primera versión apareció <strong>en</strong> Septiembre 1994<br />
incluso antes de que IPv6 estuviera estandarizado.<br />
El protocolo IPv6 incorpora una serie de v<strong>en</strong>tajas que hac<strong>en</strong> muy<br />
s<strong>en</strong>cillo el proceso de la incorporación de la <strong>movilidad</strong>. Por ejemplo, el<br />
aum<strong>en</strong>to sustancial del espacio de direcciones (128 bits <strong>en</strong> lugar de los 32<br />
55
Sistemas de Movilidad <strong>en</strong> redes IP<br />
de IPv4) [RFC 2373] va a hacer innecesario el uso de Foreign Ag<strong>en</strong>ts, de<br />
manera que a los nodos móviles siempre se les asignarán, cuando visit<strong>en</strong><br />
difer<strong>en</strong>tes redes, direcciones únicas. Este mecanismo se conoce, <strong>en</strong> Mobile<br />
IP, como asignación de una Co-located Care-of Address, (punto 2.3.). Otra<br />
de las princ<strong>ip</strong>ales incorporaciones del protocolo, la definición de difer<strong>en</strong>tes<br />
cabeceras de ext<strong>en</strong>sión <strong>en</strong> el paquete IP es utilizada, por la nueva<br />
propuesta de <strong>movilidad</strong> <strong>en</strong> IP, para facilitar su implem<strong>en</strong>tación y<br />
solucionar los ya com<strong>en</strong>tados inconv<strong>en</strong>i<strong>en</strong>tes de Mobile IP, como puede ser<br />
el problema del <strong>en</strong>caminami<strong>en</strong>to triangular.<br />
Aunque exist<strong>en</strong> difer<strong>en</strong>cias importantes <strong>en</strong>tre la nueva propuesta<br />
Mobile IPv6 con respecto al protocolo Mobile IP original [RFC 3344], la base<br />
del funcionami<strong>en</strong>to permanece constante. Así cuando un nodo está <strong>en</strong> una<br />
red distinta a la de orig<strong>en</strong> obti<strong>en</strong>e una dirección temporal d<strong>en</strong>ominada <strong>en</strong><br />
la propuesta Care-of Address (que se corresponde con las direcciones Colocated<br />
Care-of Address de la versión 4). Esta dirección puede obt<strong>en</strong>erse<br />
bi<strong>en</strong> por un servidor DHCP (mecanismo d<strong>en</strong>ominado Stateful Address<br />
Autoconfiguration) o bi<strong>en</strong> mediante la recepción de m<strong>en</strong>sajes de<br />
información ‘Router Advertisem<strong>en</strong>ts’ (mecanismo Stateless Address<br />
Autoconfiguration [RFC 2462]). Como <strong>en</strong> la versión anterior esta dirección<br />
temporal debe ser <strong>en</strong>viada al Home Ag<strong>en</strong>t, con el fin de que sea capaz de<br />
redireccionar los paquetes dirigidos al nodo móvil.<br />
Este proceso se realiza <strong>en</strong>viándole un paquete IPv6 con una<br />
ext<strong>en</strong>sión de cabecera de Opciones de Destino especial d<strong>en</strong>ominada<br />
‘Binding Update’ que deberá ser aut<strong>en</strong>tificada utilizando una Cabecera de<br />
Aut<strong>en</strong>tificación [RFC 2402] o bi<strong>en</strong> con una cabecera ESP (Encapsulating<br />
Security Payload) [RFC 2406]. El Home Ag<strong>en</strong>t reconocerá el registro<br />
utilizando otra Opción de Destino d<strong>en</strong>ominada ‘Binding Acknowledgem<strong>en</strong>t’<br />
e igualm<strong>en</strong>te aut<strong>en</strong>tificada.<br />
Cuando el nodo móvil ti<strong>en</strong>e que transmitir lo hace directam<strong>en</strong>te al<br />
destino poni<strong>en</strong>do su dirección temporal como dirección fu<strong>en</strong>te. Además se<br />
añade una Opción de destino d<strong>en</strong>ominada ‘Home Address’ donde se indica<br />
la dirección perman<strong>en</strong>te del nodo móvil. Como esta dirección es fija es<br />
56
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
posible hacer transpar<strong>en</strong>te a los niveles superiores del nodo fijo el uso de<br />
direcciones temporales (Care-of Address) por parte del nodo móvil.<br />
La nueva versión del protocolo ha solucionado el problema del<br />
<strong>en</strong>caminami<strong>en</strong>to triangular que ocurría <strong>en</strong> Mobile IP. Ahora el nodo móvil<br />
puede <strong>en</strong>viar Binding Updates a cualquier nodo fijo o estacionario con el<br />
que se comunica. Todos los nodos <strong>en</strong> IPv6 dispon<strong>en</strong> de una memoria de<br />
vínculos (Binding Cache) para mant<strong>en</strong>er esta información. Esto permite a<br />
los nodos <strong>en</strong>viar los paquetes directam<strong>en</strong>te a los nodos móviles sin t<strong>en</strong>er<br />
que realizar el <strong>en</strong>vío a la dirección perman<strong>en</strong>te (Home Address). Figura<br />
2.13<br />
Mobile Node <strong>en</strong><br />
una Foreign<br />
Network<br />
Foreign Ag<strong>en</strong>t<br />
Home Ag<strong>en</strong>t<br />
Foreign Network<br />
Binding Update<br />
Paquetes de datos<br />
Host<br />
Figura 2.13 Optimización de Ruta <strong>en</strong> Mobile IPv6<br />
Cualquier nodo que desea <strong>en</strong>viar un paquete primero consulta su<br />
memoria de vínculos <strong>en</strong> busca de la dirección destino. Si la <strong>en</strong>cu<strong>en</strong>tra<br />
<strong>en</strong>vía el paquete utilizando una ext<strong>en</strong>sión de ‘Cabecera de<br />
Encaminami<strong>en</strong>to’. La ruta especificada por esta cabecera ti<strong>en</strong>e dos saltos.<br />
El primero es la dirección temporal (Care-of Address) y el segundo la<br />
dirección perman<strong>en</strong>te (Home Address). De esta manera el paquete se<br />
<strong>en</strong>camina hasta la dirección temporal del nodo móvil y este internam<strong>en</strong>te<br />
se lo <strong>en</strong>vía al mismo de manera que finalm<strong>en</strong>te se procesa de la misma<br />
manera que si el nodo estuviera <strong>en</strong> su red.<br />
57
Sistemas de Movilidad <strong>en</strong> redes IP<br />
Si no existiera ninguna <strong>en</strong>trada <strong>en</strong> la memoria el paquete sería<br />
<strong>en</strong>viado normalm<strong>en</strong>te a la dirección perman<strong>en</strong>te del nodo móvil. Así sería<br />
recibido por el Home Ag<strong>en</strong>t y re<strong>en</strong>viado, por medio de un túnel, a la<br />
dirección temporal del nodo. Cuando un nodo recibe un paquete de esta<br />
manera <strong>en</strong>vía un m<strong>en</strong>saje de ‘Binding Update’ para que el host<br />
correspondi<strong>en</strong>te actualice su memoria y a partir de ese mom<strong>en</strong>to <strong>en</strong>víe los<br />
paquetes directam<strong>en</strong>te a la dirección temporal evitando el <strong>en</strong>caminami<strong>en</strong>to<br />
triangular.<br />
También se posibilita a los nodos preguntar por la dirección<br />
temporal de un nodo móvil, por ejemplo con el fin de refrescar su memoria<br />
de vínculos. Esto se realiza <strong>en</strong>viado una Opción de Destino d<strong>en</strong>ominada<br />
‘Binding Request’ al que se contestará con un m<strong>en</strong>saje de t<strong>ip</strong>o ‘Bindig<br />
Update’.<br />
Por último podemos concluir realizando una breve comparación<br />
<strong>en</strong>tre el protocolo Mobile IP [RFC 3344] y la nueva propuesta com<strong>en</strong>tada <strong>en</strong><br />
este punto [JOH03].<br />
• La ext<strong>en</strong>sión del protocolo Mobile IP estudiada <strong>en</strong> el punto<br />
2.3.6, Optimización de Ruta, [PER01] ha sido incorporada al<br />
nuevo protocolo como una parte fundam<strong>en</strong>tal del mismo. Esta<br />
integración ha permitido solucionar uno de los princ<strong>ip</strong>ales<br />
inconv<strong>en</strong>i<strong>en</strong>tes del protocolo original y que se conoce como<br />
Encaminami<strong>en</strong>to triangular.<br />
• El uso de las ext<strong>en</strong>siones de cabecera ‘Opciones de Destino’<br />
permite <strong>en</strong>viar la información de control insertada <strong>en</strong> un<br />
paquete IPv6 de datos (técnica ‘Piggybacking’).<br />
• Desaparece la necesidad de utilizar Foreign Ag<strong>en</strong>ts. En Mobile<br />
IPv6 los nodos móviles hac<strong>en</strong> uso de nuevas características<br />
como el descubrimi<strong>en</strong>to de vecino, Neighbor Discovery [RFC<br />
2461] o Autoconfiguración de direcciones [RFC 2462] para<br />
funcionar <strong>en</strong> cualquier red sin la necesidad de un soporte<br />
especial por parte de un router local.<br />
58
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
• Ahora la mayoría de los paquetes <strong>en</strong>viados a un nodo móvil<br />
cuando se <strong>en</strong>cu<strong>en</strong>tra fuera de su Home Network se <strong>en</strong>vían<br />
utilizando una Cabecera de Enrutami<strong>en</strong>to <strong>en</strong> vez de utilizar<br />
<strong>en</strong>capsulación. Esto reduce la cantidad de bytes adicionales que<br />
deb<strong>en</strong> ser añadidos a cada paquete.<br />
• Los paquetes que se <strong>en</strong>vían a la red local cuando el nodo está<br />
fuera de ella son interceptados por el Home Ag<strong>en</strong>t utilizando<br />
técnicas de Descubrimi<strong>en</strong>to de Vecino [RFC 2461] <strong>en</strong> vez del<br />
utilizar ARP [RFC826] como <strong>en</strong> IP Mobile v4.<br />
• La nueva versión añade mecanismos para descubrir<br />
dinámicam<strong>en</strong>te la dirección del Home Ag<strong>en</strong>t de un nodo. Se<br />
utilizan las funcionalidades del direccionami<strong>en</strong>to Anycast [RFC<br />
2526] de manera que el nodo recibe una única contestación con<br />
todos los posibles Home Ag<strong>en</strong>t y su nivel de prefer<strong>en</strong>cia. En la<br />
versión 4 se utilizaba una transmisión ‘broadcast’ y se recibían<br />
múlt<strong>ip</strong>les respuestas.<br />
2.7 SOLUCIONES DE MOVILIDAD A NIVEL DE<br />
APLICACIÓN<br />
Ya se ha com<strong>en</strong>tado que una de las posibles soluciones para ofrecer<br />
<strong>movilidad</strong> <strong>en</strong> redes IP es implem<strong>en</strong>tarla a Nivel de Aplicación. Esto<br />
permitiría indep<strong>en</strong>dizarla de la tecnología inalámbrica y de los elem<strong>en</strong>tos<br />
de red exist<strong>en</strong>tes, solución especialm<strong>en</strong>te interesante para proveedores de<br />
servicio que no dispon<strong>en</strong> de su propia red. En este campo el protocolo SIP<br />
se ha convertido <strong>en</strong> la solución preferida hasta el punto que grupos de<br />
trabajo como 3GPP, 3GPP2 y MWIF han propuesto SIP como base para la<br />
gestión de la <strong>movilidad</strong> <strong>en</strong> Internet [DUT01b]<br />
SIP (Session Initiation Protocol) es un protocolo de control para la<br />
creación, modificación y finalización de sesiones con uno o más<br />
partic<strong>ip</strong>antes [RFC 2543]. SIP es un protocolo cli<strong>en</strong>te-servidor que trabaja<br />
a nivel de aplicación. Las peticiones son emitidas por el cli<strong>en</strong>te y las<br />
59
Sistemas de Movilidad <strong>en</strong> redes IP<br />
respuestas son devueltas por el servidor. Así se reutiliza mucha de la<br />
sintaxis y semántica de HTTP [RFC 1945], incluy<strong>en</strong>do su arquitectura de<br />
código de respuesta o muchas cabeceras de m<strong>en</strong>saje.<br />
Es interesante destacar que aunque este trabajo esta c<strong>en</strong>trado <strong>en</strong> la<br />
<strong>movilidad</strong> de terminal, SIP ofrece facilidades para poder ofrecer <strong>movilidad</strong><br />
personal, de sesión y de servicio [SCH00], lo que resulta muy interesante<br />
para proveedores de aplicaciones como telefonía IP.<br />
Básicam<strong>en</strong>te soportar <strong>movilidad</strong> de terminal consiste <strong>en</strong> poder<br />
ofrecer la capacidad de que un terminal pueda estar <strong>en</strong> movimi<strong>en</strong>to<br />
mant<strong>en</strong>i<strong>en</strong>do <strong>en</strong> todo mom<strong>en</strong>to las conexiones que <strong>en</strong> ese instante<br />
estuvieran establecidas. Con SIP no se requiere que los nodos móviles<br />
t<strong>en</strong>gan que realizar modificaciones <strong>en</strong> su software de red. En el caso de<br />
que aún no se hay establecido una conexión la <strong>movilidad</strong> basada <strong>en</strong> SIP es<br />
muy s<strong>en</strong>cilla y consiste, simplem<strong>en</strong>te, <strong>en</strong> volverse a registrar <strong>en</strong> su<br />
servidor de registro SIP cada vez que se adquiere una nueva dirección IP.<br />
Por otro lado, si un nodo se mueve durante una sesión activa<br />
primero recibe una dirección de un servidor DHCP [RFC2131] y,<br />
posteriorm<strong>en</strong>te, <strong>en</strong>vía un m<strong>en</strong>saje de ‘Invitación’ al host con el que se está<br />
comunicando utilizando el mismo id<strong>en</strong>tificativo de llamada que el utilizado<br />
<strong>en</strong> el establecimi<strong>en</strong>to de la conexión, y poni<strong>en</strong>do la nueva dirección IP <strong>en</strong> el<br />
campo ‘Contacto’ del m<strong>en</strong>saje SIP, [WED99]. Para tratar de disminuir el<br />
retardo <strong>en</strong> realizar esta operación [SCH00] propone la incorporación de<br />
mecanismos similares a los protocolos de micro-<strong>movilidad</strong> estudiados <strong>en</strong> el<br />
punto 2.4. También <strong>en</strong> [DUT01b] se propone el protocolo de micro<strong>movilidad</strong><br />
MMP [DUT01] como alternativa para disminuir la necesidad de<br />
actualización <strong>en</strong> los servidores SIP.<br />
También se ha estudiado la inclusión de métodos de Registro<br />
Jerárquico, similar al desarrollado para Mobile IP [GUS02], para disminuir<br />
los retardos producidos al registrar el movimi<strong>en</strong>to del nodo <strong>en</strong> su Registro<br />
que se realiza cada vez que se cambia de dirección IP.<br />
60
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
En g<strong>en</strong>eral, las soluciones propuestas <strong>en</strong> la bibliografía [WED99] se<br />
basan <strong>en</strong> utilizar sistemas de <strong>movilidad</strong> <strong>basado</strong>s <strong>en</strong> SIP para<br />
comunicaciones multimedia que trabajan sobre UDP y utilizar soluciones<br />
de Nivel de Red (típicam<strong>en</strong>te el protocolo Mobile IP o alguna de sus<br />
variaciones, punto 2.4) para conexiones TCP. Se propone incluso que<br />
algunas aplicaciones TCP, como navegadores Web o aplicaciones de correo<br />
electrónico, puedan utilizarse sin la necesidad de protocolos que permitan<br />
la <strong>movilidad</strong> ya que requier<strong>en</strong> conexiones lo sufici<strong>en</strong>tem<strong>en</strong>te cortas como<br />
para poder asumir el coste de realizar de nuevo toda la conexión. Además<br />
algunos de estos protocolos como http/1.1 [RFC 2616] o FTP [ELZ01]<br />
incorporan capacidades para minimizar el impacto de esta desconexión.<br />
Para implem<strong>en</strong>tar esta solución utilizaría una tabla (ya propuesta <strong>en</strong><br />
[ZHA98]) de políticas con la que se decidiría, para cada aplicación, que<br />
solución utilizar.<br />
Por último indicar que <strong>en</strong> la actualidad ya exist<strong>en</strong> propuestas que<br />
también utilizan el protocolo SIP para aplicaciones No-Tiempo-Real que<br />
trabajan sobre TCP. Para ello utilizan <strong>en</strong>capsulación y un nuevo t<strong>ip</strong>o de<br />
m<strong>en</strong>saje SIP d<strong>en</strong>ominado ‘Info’ [RFC 2976].<br />
2.8 RESUMEN DEL CAPÍTULO<br />
La incorporación de facilidades de <strong>movilidad</strong> de terminal <strong>en</strong> redes<br />
basadas <strong>en</strong> la arquitectura TCP/IP no es un problema con solución<br />
evid<strong>en</strong>te. Los nodos que forman la red se id<strong>en</strong>tifican de manera única por<br />
medio de una dirección que a su vez es utilizada para id<strong>en</strong>tificar la red a la<br />
que está conectado. Esta doble función de la dirección de un nodo,<br />
id<strong>en</strong>tificación y <strong>en</strong>caminami<strong>en</strong>to ocasiona numerosos problemas para<br />
permitir la <strong>movilidad</strong> de los nodos.<br />
Exist<strong>en</strong> numerosas t<strong>en</strong>d<strong>en</strong>cias a la hora de proponer soluciones. La<br />
solución de abordar el problema directam<strong>en</strong>te a nivel de red es la que ti<strong>en</strong>e<br />
más propuestas. En este s<strong>en</strong>tido <strong>en</strong> el punto 2.2 se han estudiado las<br />
primeras propuestas que se publicaron. Sin embargo la solución más<br />
61
Sistemas de Movilidad <strong>en</strong> redes IP<br />
difundida y punto de refer<strong>en</strong>cia <strong>en</strong> todos los sistemas de <strong>movilidad</strong><br />
actuales es el protocolo Mobile IP [RFC 3344] que ha sido explicado <strong>en</strong> el<br />
punto 2.3. En este punto también se han estudiado dos de las ext<strong>en</strong>siones<br />
más populares a este protocolo: Optimización de Ruta y Registro Regional.<br />
Ambas están, actualm<strong>en</strong>te, bajo de estudio. Sin embargo el protocolo<br />
Mobile IP ti<strong>en</strong>e algunas limitaciones que indicamos a continuación:<br />
• Los handovers no pued<strong>en</strong> considerarse ‘rápidos’ ni ‘suaves’ (ver<br />
capítulo 4), ya que el nodo móvil debe indicar al Home Ag<strong>en</strong>t cada<br />
cambio de su dirección temporal.<br />
• En caso de que el nodo móvil se <strong>en</strong>cu<strong>en</strong>tre lejos de su Home<br />
Network los m<strong>en</strong>sajes de control del protocolo introduc<strong>en</strong><br />
sobrecarga <strong>en</strong> la red.<br />
• Mobile IP puede afectar a los protocolos de QoS, haci<strong>en</strong>do que su<br />
implem<strong>en</strong>tación sea problemática. Por ejemplo Mobile IP utiliza<br />
túneles, de manera que la cabecera de los paquetes, que pued<strong>en</strong><br />
cont<strong>en</strong>er información QoS, queda oculta a los dispositivos de<br />
interconexión.<br />
Se han realizado propuestas que se basan dividir el problema de la<br />
<strong>movilidad</strong> <strong>en</strong> dos partes: macro-<strong>movilidad</strong> y micro-<strong>movilidad</strong>. Así podemos<br />
definir micro-<strong>movilidad</strong> como el movimi<strong>en</strong>to de los nodos móviles d<strong>en</strong>tro de<br />
un nivel local, que se puede d<strong>en</strong>ominar dominio. El concepto de macro<strong>movilidad</strong><br />
se refiere al movimi<strong>en</strong>to de los nodos <strong>en</strong>tre estos dominios. En<br />
este s<strong>en</strong>tido <strong>en</strong> el punto 2.4 se han estudiado algunas de las propuestas de<br />
micro-<strong>movilidad</strong> más ext<strong>en</strong>didas como Cellular IP [VAL99], HAWAI<br />
[RAM99], EMA [ONE00] o TeleMIP [DAS00].<br />
Se han estudiado también algunas soluciones que se basaban <strong>en</strong> la<br />
utilización de transmisión <strong>multicast</strong> para solucionar el problema de la<br />
<strong>movilidad</strong>, como por ejemplo [MYS98] o [HEL00]. Estas soluciones, sin<br />
embargo, no están planteadas para <strong>en</strong>tornos de micro-<strong>movilidad</strong>, por lo<br />
que ti<strong>en</strong><strong>en</strong> importantes limitaciones <strong>en</strong> cuanto a la escalabilidad y<br />
prestaciones durante el handover.<br />
62
Sistemas de <strong>movilidad</strong> <strong>en</strong> redes IP<br />
Por último, y para terminar las soluciones a nivel de red, <strong>en</strong> el<br />
punto 2.6 se ha com<strong>en</strong>tado la nueva versión del protocolo Mobile IP,<br />
actualm<strong>en</strong>te bajo estudio, que se basa <strong>en</strong> el protocolo de nivel de red IPv6<br />
[RFC 2460].<br />
Otra de las posibles soluciones para ofrecer <strong>movilidad</strong> <strong>en</strong> redes IP<br />
es implem<strong>en</strong>tarla a Nivel de Aplicación. Casi todas las propuestas utilizan<br />
el protocolo SIP (Session Initiation Protocol) [RFC 2543]. En el punto 2.7 se<br />
han estudiado algunas de las posibles soluciones de <strong>movilidad</strong> utilizando<br />
SIP [DUT01], [WED99].<br />
Podemos concluir indicando que es una idea g<strong>en</strong>eralizada el que la<br />
mejor solución para mejorar las prestaciones del protocolo Mobile IP es la<br />
utilización de protocolos de micro-<strong>movilidad</strong>. Las propuestas <strong>en</strong> este<br />
aspecto pued<strong>en</strong> ser agrupadas <strong>en</strong> dos grandes grupos: esquemas de<br />
<strong>movilidad</strong> jerárquicos y <strong>en</strong>caminami<strong>en</strong>to <strong>basado</strong> <strong>en</strong> host. Ambos grupos<br />
ti<strong>en</strong><strong>en</strong> sus v<strong>en</strong>tajas y limitaciones sin poder concluir que una solución es<br />
mejor que otra.<br />
Por otro lado, las soluciones basadas <strong>en</strong> <strong>multicast</strong> ofrec<strong>en</strong> algunas<br />
soluciones que merece la p<strong>en</strong>a ser consideradas, princ<strong>ip</strong>alm<strong>en</strong>te <strong>en</strong> las<br />
cuestiones relativas a las prestaciones durante el handover. En esta tesis<br />
se propone un sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong> que nos va<br />
a ofrecer, tanto las v<strong>en</strong>tajas de los sistemas de micro-<strong>movilidad</strong> <strong>en</strong> g<strong>en</strong>eral,<br />
como las específicas de utilizar la tecnología <strong>multicast</strong>.<br />
63
Sistemas de Movilidad <strong>en</strong> redes IP<br />
64
3. PROPUESTA DE SISTEMA DE<br />
MICROMOVILIDAD BASADO EN MULTICAST<br />
3.1 INTRODUCCIÓN<br />
Como ya se ha com<strong>en</strong>tado el protocolo Mobile IP [RFC 2002] y<br />
alguna de sus variaciones, como la Optimización de Ruta [PERK01], ti<strong>en</strong><strong>en</strong><br />
varias limitaciones. Algunas de estas limitaciones son la necesidad de un<br />
registro cada vez que el nodo móvil cambia de red, la incapacidad para<br />
soportar el movimi<strong>en</strong>to rápido de los nodos, o los problemas que surg<strong>en</strong><br />
para ofrecer QoS utilizando protocolos tradicionales como RSVP [RFC<br />
2205].<br />
En la actualidad han surgido un conjunto de soluciones basadas<br />
<strong>en</strong> el concepto de dividir el problema de la <strong>movilidad</strong> <strong>en</strong> dos partes: macro<strong>movilidad</strong><br />
y micro-<strong>movilidad</strong> (punto 2.4). Así, podemos definir micro<strong>movilidad</strong><br />
como el movimi<strong>en</strong>to de los nodos móviles d<strong>en</strong>tro de un nivel<br />
local, que se puede d<strong>en</strong>ominar dominio 1 . Por otra parte el concepto de<br />
macro-<strong>movilidad</strong> se refiere al movimi<strong>en</strong>to de los nodos <strong>en</strong>tre estos<br />
dominios.<br />
La primera implicación de distinguir <strong>en</strong>tre macro-<strong>movilidad</strong> y<br />
micro-<strong>movilidad</strong> es que la mayor parte de los movimi<strong>en</strong>tos de los nodos<br />
móviles puede ser gestionada localm<strong>en</strong>te por el protocolo de micro<strong>movilidad</strong>.<br />
Esto es interesante desde el punto de vista de la escalabilidad,<br />
puesto que se evita la señalización al Home Ag<strong>en</strong>t cada vez que el nodo<br />
móvil cambia de subred.<br />
1<br />
Los términos suel<strong>en</strong> variar dep<strong>en</strong>di<strong>en</strong>do de la bibliografía. Por ejemplo <strong>en</strong> [MAN02]<br />
(Work in progress) se recomi<strong>en</strong>da utilizar el término ‘Red de Acceso’ (Access Network,<br />
AN). En este trabajo se va a mant<strong>en</strong>er, sin embargo, el término ‘dominio’ por ser el más<br />
ext<strong>en</strong>dido.<br />
65
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
En el punto 2.5 se ha estudiado la aparición de propuestas que se<br />
basan <strong>en</strong> la utilización de las capacidades <strong>multicast</strong> para permitir la<br />
<strong>movilidad</strong> de los nodos. El direccionami<strong>en</strong>to <strong>multicast</strong> ti<strong>en</strong>e mucho <strong>en</strong><br />
común con la <strong>movilidad</strong>, ya que ambas tecnologías se <strong>en</strong>fr<strong>en</strong>tan al<br />
problema de la localización del nodo indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de la dirección.<br />
Sin embargo, los esquemas de asignación de una dirección<br />
<strong>multicast</strong> global y perman<strong>en</strong>te a cada nodo móvil, como los pres<strong>en</strong>tados <strong>en</strong><br />
el punto 2.5 ([MYS98], [HEL00]), ti<strong>en</strong><strong>en</strong> serios inconv<strong>en</strong>i<strong>en</strong>tes que hac<strong>en</strong><br />
que su implantación real sea inabordable. Algunas de estas dificultades se<br />
detallan a continuación:<br />
• La utilización de una dirección <strong>multicast</strong> única y perman<strong>en</strong>te para<br />
cada nodo requiere un esquema de asignación de direcciones<br />
global, y una cantidad de recursos <strong>multicast</strong>, por ejemplo<br />
direcciones <strong>multicast</strong> libres, que <strong>en</strong> la actualidad no está<br />
disponible.<br />
• La arquitectura requeriría que toda la red soportara esta tecnología.<br />
Hoy <strong>en</strong> día la capacidad de transmisión <strong>multicast</strong> <strong>en</strong> Internet está<br />
soportada sólo parcialm<strong>en</strong>te.<br />
• A medida que el número de direcciones <strong>multicast</strong> (nodos) crece<br />
aum<strong>en</strong>ta la información que deb<strong>en</strong> almac<strong>en</strong>ar los routers<br />
implicados. Esto puede ocasionar problemas de desbordami<strong>en</strong>to <strong>en</strong><br />
los routers o la necesidad de aum<strong>en</strong>tar la complejidad de los<br />
mismos.<br />
Una de las aportaciones de esta tesis consiste <strong>en</strong> un esquema de<br />
gestión de <strong>movilidad</strong> escalable, <strong>basado</strong> <strong>en</strong> una arquitectura de micro<strong>movilidad</strong><br />
que explota las capacidades de la transmisión <strong>multicast</strong>. Este<br />
esquema solucionará las limitaciones m<strong>en</strong>cionadas de los sistemas de<br />
<strong>movilidad</strong> <strong>basado</strong>s <strong>en</strong> una dirección única y global <strong>multicast</strong>, sin perder,<br />
sin embargo, ninguna de las cualidades que ofrece este t<strong>ip</strong>o de esquemas.<br />
El modelo propuesto actuará d<strong>en</strong>tro de un domino y, por tanto,<br />
funcionará <strong>en</strong> conjunción con otros protocolos <strong>en</strong>cargados de implem<strong>en</strong>tar<br />
66
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
la macro-<strong>movilidad</strong>, como Mobile IP o sus difer<strong>en</strong>tes variaciones. Es decir,<br />
el sistema propuesto coopera con Mobile IP de manera similar a como lo<br />
hac<strong>en</strong> todos los sistemas de micro-<strong>movilidad</strong> estudiados anteriorm<strong>en</strong>te<br />
(punto 2.4).<br />
En el punto 3.2 se va a pres<strong>en</strong>tar la arquitectura, mi<strong>en</strong>tras que el<br />
sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong> se detalla <strong>en</strong> el punto 3.3.<br />
Algunos conceptos refer<strong>en</strong>tes a la seguridad del sistema propuesto se<br />
abordan <strong>en</strong> el punto 3.4. El formato de los difer<strong>en</strong>tes paquetes<br />
intercambiados se muestra <strong>en</strong> el punto 3.5. En el punto 3.6 se aborda la<br />
tecnología <strong>multicast</strong> empleada. Finalm<strong>en</strong>te una comparación de este<br />
protocolo con las otras propuestas exist<strong>en</strong>tes se realiza <strong>en</strong> el punto 3.7.<br />
Las conclusiones del capítulo se muestran <strong>en</strong> el punto 3.8.<br />
3.2 ARQUITECTURA<br />
Se propone una arquitectura jerárquica similar a los modelos de<br />
micro-<strong>movilidad</strong> exist<strong>en</strong>tes <strong>en</strong> la actualidad. Según esta arquitectura existe<br />
un nivel inferior, que d<strong>en</strong>ominamos ‘dominio’, donde se produce la micro<strong>movilidad</strong><br />
y un nivel superior, que abarca toda la red, donde se producirá<br />
una <strong>movilidad</strong> global o macro-<strong>movilidad</strong>.<br />
La arquitectura de estos dominios está formada por un Ag<strong>en</strong>te de<br />
Movilidad Multicast (MMA) que actúa como pasarela a la red IP y como<br />
Foreign Ag<strong>en</strong>t de Mobile IP. Este ag<strong>en</strong>te es, <strong>en</strong> cierto s<strong>en</strong>tido, similar al<br />
ag<strong>en</strong>te de <strong>movilidad</strong> TeleMIP [DAS00] o a la pasarela GFA de Mobile IP con<br />
Registro Regional [GUS02], y es el <strong>en</strong>cargado de gestionar un dominio que<br />
está compuesto por un conjunto de subredes conectadas por medio de<br />
routers con capacidad <strong>multicast</strong>. La arquitectura de un dominio puede<br />
observarse <strong>en</strong> la sigui<strong>en</strong>te figura.<br />
Además existe un conjunto de Estaciones Base (BS) que serán las<br />
<strong>en</strong>cargadas de intercambiar información de control con el nodo móvil (MN).<br />
Estas estaciones ti<strong>en</strong><strong>en</strong> capacidades de nivel tres, es decir, son routers<br />
67
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
modificados para implem<strong>en</strong>tar las tareas asignadas por el sistema de<br />
micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>. Las Estaciones Base van a heredar<br />
también las tareas que realizaban los Foreign Ag<strong>en</strong>ts de Mobile IP.<br />
MMA<br />
Router<br />
Multicast<br />
Router<br />
Multicast<br />
Subred 3<br />
BS<br />
Subred 1<br />
BS<br />
BS<br />
Subred 2<br />
Nodo<br />
Móvil<br />
Figura 3.1 Arquitectura de un Dominio.<br />
Cada una de las regiones que controla una Estación Base puede<br />
verse como una subred. La conexión del nodo móvil con la estación base se<br />
realiza por medio de ant<strong>en</strong>as que aquí d<strong>en</strong>ominaremos Puntos de Acceso.<br />
Es posible que cada región esté controlada sólo por una ant<strong>en</strong>a, <strong>en</strong> cuyo<br />
caso la tecnología puede integrarse con la Estación Base. Otra solución es<br />
la exist<strong>en</strong>cia de múlt<strong>ip</strong>les Puntos de Acceso conectados por medio de una<br />
red de área local. En este caso los Puntos de Acceso trabajan a nivel dos y<br />
podría tratarse, por ejemplo, de una red WLAN IEEE 802.11. En la<br />
sigui<strong>en</strong>te figura se muestra esta opción.<br />
Hay que indicar que un movimi<strong>en</strong>to del nodo móvil <strong>en</strong>tre estas<br />
microceldas controladas por Puntos de Acceso se realiza a nivel dos y, por<br />
tanto, de forma transpar<strong>en</strong>te a los niveles superiores de la jerarquía.<br />
68
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
BS<br />
Figura 3.2 Subred controlada por una Estación Base.<br />
Utilizando esta arquitectura es posible difer<strong>en</strong>ciar distintos t<strong>ip</strong>os de<br />
<strong>movilidad</strong>:<br />
• Movilidad Local d<strong>en</strong>tro de una subred.<br />
• Micro-<strong>movilidad</strong> d<strong>en</strong>tro de un dominio.<br />
• Movilidad global o Macro-<strong>movilidad</strong>.<br />
La <strong>movilidad</strong> local consiste <strong>en</strong> el movimi<strong>en</strong>to de un nodo d<strong>en</strong>tro de<br />
una zona limitada como puede ser un <strong>en</strong>torno de oficinas, o una fábrica.<br />
En esta situación la conexión del nodo móvil a la red se realiza por medio<br />
de puntos de acceso conectados a la misma subred, utilizando por ejemplo<br />
una red Ethernet conmutada. Esta <strong>movilidad</strong> está gestionada a nivel dos, y<br />
por tanto va a ser transpar<strong>en</strong>te al trabajo desarrollado <strong>en</strong> esta Tesis.<br />
Ejemplos de esta gestión pued<strong>en</strong> ser los mecanismos de ‘roaming’<br />
implem<strong>en</strong>tados <strong>en</strong> las redes IEEE 802.11, y actualm<strong>en</strong>te estandarizados<br />
bajo el nombre de IEEE802.11f, o el trabajo de handovers rápidos<br />
propuesto <strong>en</strong> [CAC96].<br />
El segundo nivel d<strong>en</strong>tro de la jerarquía de <strong>movilidad</strong> es la <strong>movilidad</strong><br />
d<strong>en</strong>tro de un dominio. Es el caso típico de movimi<strong>en</strong>to d<strong>en</strong>tro de un<br />
69
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
campus, un aeropuerto o la <strong>movilidad</strong> d<strong>en</strong>tro de una ruta preestablecida<br />
(línea de tr<strong>en</strong>, metro o autopista). Como ya se ha estudiado, según un<br />
protocolo de <strong>movilidad</strong> tradicional como Mobile IP sería necesario que este<br />
movimi<strong>en</strong>to fuera indicado al Home Ag<strong>en</strong>t con la consigui<strong>en</strong>te p<strong>en</strong>alización<br />
<strong>en</strong> las prestaciones. En el punto 2.4 se estudió los difer<strong>en</strong>tes sistemas de<br />
micro-<strong>movilidad</strong> que proponían distintas soluciones a este problema. La<br />
solución que ofrecemos <strong>en</strong> esta Tesis se detalla <strong>en</strong> los puntos sigui<strong>en</strong>tes.<br />
Por último el tercer nivel de la jerarquía ofrece <strong>movilidad</strong> global, es<br />
decir, <strong>en</strong>tre difer<strong>en</strong>tes dominios. En este caso es necesario informar al<br />
Home Ag<strong>en</strong>t. Esta comunicación se realiza por medio del Foreign Ag<strong>en</strong>t del<br />
dominio, que <strong>en</strong> nuestra arquitectura se d<strong>en</strong>omina MMA (Ag<strong>en</strong>te de<br />
Movilidad Multicast), y empleando el protocolo Mobile IP. La utilización de<br />
este protocolo no excluye, sin embargo, el uso de las diversas variaciones<br />
propuestas <strong>en</strong> la bibliografía como, por ejemplo, la Optimización de Ruta<br />
[PER01].<br />
3.3 PROTOCOLO DE MICRO-MOVILIDAD BASADO EN<br />
MULTICAST<br />
En el punto 2.4 se realizó una breve clasificación de los sistemas de<br />
micro-<strong>movilidad</strong>, difer<strong>en</strong>ciando los <strong>basado</strong>s <strong>en</strong> ag<strong>en</strong>tes de <strong>movilidad</strong><br />
jerárquicos y los esquemas que utilizaban <strong>en</strong>caminami<strong>en</strong>to <strong>basado</strong> <strong>en</strong><br />
Host. El sistema propuesto podría <strong>en</strong>cuadrarse <strong>en</strong> un t<strong>ip</strong>o distinto a los<br />
dos anteriores d<strong>en</strong>ominándose, por ejemplo, Esquemas Basados <strong>en</strong><br />
Multicast.<br />
El funcionami<strong>en</strong>to básico consiste sustituir las direcciones<br />
temporales (Care-of Address), que va adquiri<strong>en</strong>do el nodo cuando cambia<br />
de red <strong>en</strong> el protocolos Mobile IP, por una dirección <strong>multicast</strong> que se va a<br />
mant<strong>en</strong>er constante mi<strong>en</strong>tras el nodo permanece <strong>en</strong> el dominio.<br />
La <strong>movilidad</strong> <strong>en</strong>tre dominios (macro-<strong>movilidad</strong>) se realiza por medio<br />
de Mobile IP, mi<strong>en</strong>tras que d<strong>en</strong>tro de un dominio se utiliza un protocolo de<br />
70
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
<strong>en</strong>caminami<strong>en</strong>to <strong>multicast</strong>. Así, suponi<strong>en</strong>do Mobile IPv4 y sin Optimización<br />
de Ruta (punto 2.3.6), los paquetes son dirigidos hacia el Home Ag<strong>en</strong>t que<br />
los <strong>en</strong>vía por medio de un túnel hacia el Ag<strong>en</strong>te de Movilidad Multicast<br />
(MMA) que realiza las funciones de un Foreign Ag<strong>en</strong>t y de <strong>en</strong>capsulación<br />
<strong>multicast</strong>. Éste des<strong>en</strong>capsula los paquetes originales y los redirige<br />
utilizando como dirección destino la dirección <strong>multicast</strong> asignada al nodo<br />
móvil.<br />
Podemos resumir el modo <strong>en</strong> que funciona el protocolo <strong>en</strong> los<br />
sigui<strong>en</strong>tes puntos:<br />
• Todas las subredes que forman un dominio dispon<strong>en</strong> de un Ag<strong>en</strong>te<br />
(implem<strong>en</strong>tado <strong>en</strong> la Estación Base) que informa tanto de la subred<br />
actual y del dominio a la que pert<strong>en</strong>ece como de la/s dirección/es del<br />
MMA de ese dominio a cualquier nodo móvil que se <strong>en</strong>cu<strong>en</strong>tre<br />
conectado. Para ello difunde un m<strong>en</strong>saje especial d<strong>en</strong>ominado Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t.<br />
• Los nodos móviles que escuchan estos m<strong>en</strong>sajes analizan su<br />
cont<strong>en</strong>ido para decidir si se <strong>en</strong>cu<strong>en</strong>tran <strong>en</strong> una nueva red externa<br />
(Foreign Network) o incluso <strong>en</strong> un nuevo dominio.<br />
• En caso de que el nodo móvil se <strong>en</strong>cu<strong>en</strong>tre situado <strong>en</strong> un nuevo<br />
dominio se ha producido caso de macro-<strong>movilidad</strong>. Según el modelo<br />
propuesto esto se traduce <strong>en</strong> un registro <strong>en</strong> el Home Ag<strong>en</strong>t (HA)<br />
utilizando el protocolo Mobile IP. En este registro se <strong>en</strong>vía la dirección<br />
IP del MMA al HA que la interpretará como la nueva dirección Care-of<br />
Address del nodo móvil. Este proceso de handover inter-dominio<br />
implicará, <strong>en</strong>tre otros aspectos, la obt<strong>en</strong>ción de una nueva dirección<br />
<strong>multicast</strong>.<br />
• En caso de permanecer <strong>en</strong> el mismo dominio y de haber cambiado de<br />
red estamos <strong>en</strong> un caso de micro-<strong>movilidad</strong> que se traduce <strong>en</strong> un<br />
proceso de handover intra-dominio. Este se resolvería simplem<strong>en</strong>te<br />
realizando una petición, por parte del ag<strong>en</strong>te de la Estación Base,<br />
para la incorporación al árbol <strong>multicast</strong>. A partir de ese mom<strong>en</strong>to la<br />
Estación Base com<strong>en</strong>zaría a recibir los paquetes destinados a ese<br />
nodo móvil.<br />
71
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
• Como <strong>en</strong> el protocolo Mobile IP, el Home Ag<strong>en</strong>t intercepta los<br />
paquetes destinados al nodo y los <strong>en</strong>vía, por medio de un túnel, a la<br />
dirección del Ag<strong>en</strong>te de Movilidad Multicast (MMA).<br />
• Finalm<strong>en</strong>te este ag<strong>en</strong>te des<strong>en</strong>capsula los paquetes y los re<strong>en</strong>vía<br />
<strong>en</strong>capsulándolos con la dirección <strong>multicast</strong> asignada al nodo móvil<br />
<strong>en</strong> cuestión.<br />
Home Ag<strong>en</strong>t<br />
Transmisión<br />
<strong>multicast</strong><br />
Host Fu<strong>en</strong>te<br />
Subred 1<br />
MMA<br />
Dominio<br />
Subred 2<br />
Figura 3.3 Sistema de Movilidad utilizando Mobile IP <strong>en</strong> macro-<strong>movilidad</strong>.<br />
La mayoría de las soluciones com<strong>en</strong>tadas <strong>en</strong> el capítulo anterior,<br />
exceptuando el Registro Regional [GUS02], se limitan a dar una visión<br />
g<strong>en</strong>eral de la propuesta, sin abordar una descr<strong>ip</strong>ción global y profunda del<br />
sistema de <strong>movilidad</strong>. Por el contrario <strong>en</strong> este trabajo se describe con<br />
detalle el funcionami<strong>en</strong>to del sistema. Se ha int<strong>en</strong>tado realizar un sistema<br />
totalm<strong>en</strong>te compatible con el protocolo Mobile IP, de manera que el<br />
Intercambio de información <strong>en</strong>tre los difer<strong>en</strong>tes elem<strong>en</strong>tos se realiza<br />
princ<strong>ip</strong>alm<strong>en</strong>te utilizando ext<strong>en</strong>siones que están acorde con los trabajos<br />
desarrollados por el IETF.<br />
Observando los pasos anteriores podemos resumir que realiza tres<br />
fases: descubrimi<strong>en</strong>to de la red actual; conexión al árbol <strong>multicast</strong>,<br />
obt<strong>en</strong>i<strong>en</strong>do una nueva dirección <strong>multicast</strong> <strong>en</strong> caso necesario; y <strong>en</strong>vío de<br />
datos.<br />
72
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
3.3.1 Descubrimi<strong>en</strong>to de la red actual<br />
El descubrimi<strong>en</strong>to de la red es el proceso por el cual un nodo móvil<br />
es capaz de determinar si actualm<strong>en</strong>te está conectado a su Home Network<br />
o está <strong>en</strong> una Foreign Network o si se ha movido de una red a otra o de un<br />
Dominio a otro.<br />
El proceso es similar al ejecutado <strong>en</strong> el protocolo Mobile IP<br />
existi<strong>en</strong>do dos m<strong>en</strong>sajes para averiguar la situación <strong>en</strong> que se <strong>en</strong>cu<strong>en</strong>tra el<br />
nodo. El primero es Ag<strong>en</strong>t Advertisem<strong>en</strong>t <strong>en</strong>viado de forma periódica por<br />
los ag<strong>en</strong>tes, <strong>en</strong> forma de paquetes de difusión. El m<strong>en</strong>saje se formará<br />
ext<strong>en</strong>di<strong>en</strong>do un m<strong>en</strong>saje ICMP de descubrimi<strong>en</strong>to de ruta [RFC1256] con<br />
una ext<strong>en</strong>sión de <strong>movilidad</strong> como la descrita <strong>en</strong> el protocolo Mobile IP<br />
(Mobility Ag<strong>en</strong>t Advertisem<strong>en</strong>t Ext<strong>en</strong>sion). Adicionalm<strong>en</strong>te <strong>en</strong> este m<strong>en</strong>saje<br />
se debe indicar un id<strong>en</strong>tificativo de dominio y un id<strong>en</strong>tificativo de la<br />
subred, de forma que el nodo móvil pueda averiguar si se ha movido (o ha<br />
regresado) a su Home Network, o si ha cambiado de subred d<strong>en</strong>tro de un<br />
dominio o incluso <strong>en</strong>tre dominios.<br />
Debido a que ahora las direcciones Care-of Address indicadas <strong>en</strong> el<br />
m<strong>en</strong>saje correspond<strong>en</strong> al MMA es necesario que la Estación Base indique,<br />
<strong>en</strong> el m<strong>en</strong>saje Ag<strong>en</strong>t Advertisem<strong>en</strong>t, la red correspondi<strong>en</strong>te. La solución<br />
propuesta es la de obligar a que <strong>en</strong> los m<strong>en</strong>sajes aparezca la ext<strong>en</strong>sión<br />
‘Prefix-L<strong>en</strong>gths Ext<strong>en</strong>sion’. Esta ext<strong>en</strong>sión está definida <strong>en</strong> el protocolo<br />
Mobile IP como opcional, e indica el número de bits que forman el prefijo<br />
de la red <strong>en</strong> las direcciones indicadas <strong>en</strong> la porción ‘ICMP Router<br />
Advertisem<strong>en</strong>t’ del m<strong>en</strong>saje Ag<strong>en</strong>t Advertisem<strong>en</strong>t.<br />
Con respecto a la id<strong>en</strong>tificación del dominio, la solución de utilizar<br />
la dirección IP del Ag<strong>en</strong>te de Movilidad Multicast (MMA) que se indica <strong>en</strong> el<br />
m<strong>en</strong>saje Ag<strong>en</strong>t Advertisem<strong>en</strong>t no es una propuesta útil, pues limita las<br />
soluciones de escalabilidad que se describ<strong>en</strong> <strong>en</strong> el punto 3.3.5. La opción<br />
pres<strong>en</strong>tada se basa <strong>en</strong> la utilización de Id<strong>en</strong>tificativos de Acceso a Red, NAI<br />
[RFC 2486]. La utilización del NAI <strong>en</strong> sistemas de <strong>movilidad</strong> <strong>basado</strong>s <strong>en</strong><br />
Mobile IP se describe <strong>en</strong> [RFC 2794] limitándose a un id<strong>en</strong>tificativo del<br />
nodo móvil. La propuesta definida aquí de asignar un NAI al dominio puede<br />
73
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
observarse como una ext<strong>en</strong>sión al trabajo expuesto <strong>en</strong> [KHA01] donde se<br />
g<strong>en</strong>eraliza la utilización de id<strong>en</strong>tificativos NAI para nombrar Foreign y<br />
Home Ag<strong>en</strong>ts.<br />
El segundo t<strong>ip</strong>o de m<strong>en</strong>sajes se d<strong>en</strong>omina Ag<strong>en</strong>t Solicitation y es<br />
<strong>en</strong>viado por el nodo móvil con el único propósito de forzar a los ag<strong>en</strong>tes a<br />
<strong>en</strong>viar un m<strong>en</strong>saje Ag<strong>en</strong>t Advertisem<strong>en</strong>t. Esto es útil <strong>en</strong> el caso de que el<br />
nodo se mueva de forma rápida de una red a otra. Con el fin de asegurar la<br />
recepción del m<strong>en</strong>saje, por parte de los ag<strong>en</strong>tes correspondi<strong>en</strong>tes la<br />
transmisión, se puede realizar a la dirección <strong>multicast</strong> 224.0.0.11, que se<br />
corresponde, según definición <strong>en</strong> [IANA], con 'Todos los Ag<strong>en</strong>tes de<br />
Movilidad'. El formato de ambos m<strong>en</strong>sajes puede observarse <strong>en</strong> el punto<br />
3.5.<br />
Es importante indicar que no es necesario ningún mecanismo de<br />
aut<strong>en</strong>tificación <strong>en</strong> estos dos m<strong>en</strong>sajes. Aún así podría emplearse los<br />
mecanismos de aut<strong>en</strong>tificación de la cabecera IP descritos <strong>en</strong> [RFC 2402].<br />
Este mecanismo queda fuera de este estudio.<br />
3.3.2 Registro <strong>en</strong> un nuevo Dominio<br />
Cuando un Nodo Móvil detecta que ha cambiado de dominio<br />
necesita realizar un nuevo registro que implicará, además de al nodo<br />
móvil, al Ag<strong>en</strong>te de Movilidad Multicast (MMA) del nuevo dominio, y al<br />
Home Ag<strong>en</strong>t del nodo móvil.<br />
Como ya se ha com<strong>en</strong>tado, la arquitectura propuesta se basa <strong>en</strong> la<br />
utilización del Protocolo Mobile IP [RFC 3344] para realizar el mecanismo<br />
de macro-<strong>movilidad</strong>. Por tanto, la <strong>en</strong>trada del nodo móvil <strong>en</strong> un nuevo<br />
dominio va a ocasionar, además de los procesos necesarios para poder<br />
gestionar la micro-<strong>movilidad</strong>, el registro de una dirección Care-of Address<br />
<strong>en</strong> el Home Ag<strong>en</strong>t del nodo, sigui<strong>en</strong>do completam<strong>en</strong>te el protocolo Mobile<br />
IP.<br />
74
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
El proceso comi<strong>en</strong>za al detectar que se ha producido un cambio de<br />
dominio según el procedimi<strong>en</strong>to explicado anteriorm<strong>en</strong>te. En este punto el<br />
nodo necesita obt<strong>en</strong>er una dirección <strong>multicast</strong> que utilizará durante toda<br />
su estancia <strong>en</strong> el dominio, así como realizar un registro de la Care-of<br />
Address <strong>en</strong> su Home Ag<strong>en</strong>t. En la figura 3.4 se muestra este proceso que<br />
se describe a continuación.<br />
MN BS MMA HA<br />
Registration Request<br />
Reg. Req. con ext<strong>en</strong>siones<br />
Registration Request<br />
Registration Reply<br />
Reg. Reply con ext<strong>en</strong>siones<br />
Registration Reply<br />
Figura 3.4 Registro del nodo móvil <strong>en</strong> el Ag<strong>en</strong>te de Movilidad Multicast.<br />
Con el fin de mant<strong>en</strong>er la compatibilidad con el protocolo Mobile IP<br />
el m<strong>en</strong>saje empleado por el MN (Nodo móvil) va a ser similar al<br />
d<strong>en</strong>ominado Registration Request. Este m<strong>en</strong>saje ti<strong>en</strong>e como destino final<br />
el Home Ag<strong>en</strong>t, pues se utiliza para registrar la dirección del Ag<strong>en</strong>te de<br />
Movilidad Multicast (MMA) como dirección Care-of Address del nodo móvil.<br />
Puesto que el nodo móvil no cambia de MMA mi<strong>en</strong>tras se mueve por<br />
difer<strong>en</strong>tes estaciones Base (BS) d<strong>en</strong>tro de un dominio (micro-<strong>movilidad</strong>), no<br />
será necesario informar a su Home Ag<strong>en</strong>t de estos futuros movimi<strong>en</strong>tos.<br />
El m<strong>en</strong>saje Registration Request es <strong>en</strong>viado a la dirección IP de la<br />
Estación Base que el nodo móvil ha obt<strong>en</strong>ido del paquete ICMP de los<br />
m<strong>en</strong>sajes Ag<strong>en</strong>t Advertisem<strong>en</strong>t explicados anteriorm<strong>en</strong>te. Esta estación<br />
75
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
insertará una <strong>en</strong>trada <strong>en</strong> una lista que conti<strong>en</strong>e todos los móviles que<br />
actualm<strong>en</strong>te se <strong>en</strong>cu<strong>en</strong>tran <strong>en</strong> su área de cobertura. Esta lista incluye,<br />
además de la dirección IP perman<strong>en</strong>te del nodo móvil y de los parámetros<br />
ya especificados <strong>en</strong> el protocolo Mobile IP (dirección MAC del nodo móvil,<br />
puerto UDP fu<strong>en</strong>te del Registro, campo de Id<strong>en</strong>tificación, y un<br />
temporizador que indica la validez de la <strong>en</strong>trada), la dirección IP del MMA,<br />
y la dirección <strong>multicast</strong> que se le ha asignado al nodo móvil y que se<br />
obt<strong>en</strong>drá posteriorm<strong>en</strong>te <strong>en</strong> un m<strong>en</strong>saje de respuesta.<br />
La estación base debe re<strong>en</strong>viar el m<strong>en</strong>saje de registro hacia el<br />
Ag<strong>en</strong>te de Movilidad Multicast (MMA) indicado <strong>en</strong> el m<strong>en</strong>saje de registro.<br />
Con el fin de no inutilizar el mecanismo de aut<strong>en</strong>tificación del registro<br />
(Mobile-Home Auth<strong>en</strong>tication Ext<strong>en</strong>sion [RFC 3344]) la Estación Base no<br />
puede modificar ningún campo del m<strong>en</strong>saje recibido. Para que el MMA<br />
pueda almac<strong>en</strong>ar la Estación Base <strong>en</strong> la que actualm<strong>en</strong>te está el nodo, el<br />
m<strong>en</strong>saje es <strong>en</strong>viado con una ext<strong>en</strong>sión que id<strong>en</strong>tifica la estación Base<br />
[KHA01]. Esta ext<strong>en</strong>sión debe ser añadida detrás de todas las ext<strong>en</strong>siones<br />
que lleva incluidas el m<strong>en</strong>saje de Registro cuando se recibe por la estación<br />
base, y debería ir protegida por un m<strong>en</strong>saje de aut<strong>en</strong>tificación FA-FA [RFC<br />
3012]. Los aspectos relativos a la seguridad se abordan <strong>en</strong> el punto 3.4.2<br />
Este modo de funcionami<strong>en</strong>to es completam<strong>en</strong>te compatible con el<br />
sistema de <strong>movilidad</strong> original. Si la estación base recibe un m<strong>en</strong>saje de<br />
registro con el campo Care-of Address rell<strong>en</strong>o con su propia dirección, ésta<br />
<strong>en</strong>vía el registro directam<strong>en</strong>te al Home Ag<strong>en</strong>t. De esta manera la BS está<br />
funcionando como un Foreign Ag<strong>en</strong>t original, sin implem<strong>en</strong>tar el sistema<br />
de micro-<strong>movilidad</strong> <strong>multicast</strong> pres<strong>en</strong>tado <strong>en</strong> este punto.<br />
Al recibir el m<strong>en</strong>saje, el Ag<strong>en</strong>te de Movilidad Multicast se <strong>en</strong>carga<br />
de re<strong>en</strong>viarlo al Home Ag<strong>en</strong>t, apoyándose <strong>en</strong> el hecho de que la dirección<br />
del mismo vi<strong>en</strong>e indicada <strong>en</strong> el m<strong>en</strong>saje Registration Request. Cualquier<br />
ext<strong>en</strong>sión incorporada por la Estación Base es eliminada por el Ag<strong>en</strong>te de<br />
Movilidad (figura 3.4). Así, el m<strong>en</strong>saje de registro que <strong>en</strong>vió el nodo móvil<br />
llega sin alteración al Home Ag<strong>en</strong>t que lo aut<strong>en</strong>tificará utilizando la<br />
ext<strong>en</strong>sión de aut<strong>en</strong>tificación MN-HA.<br />
76
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
El MMA añade una <strong>en</strong>trada a la lista de nodos móviles que ti<strong>en</strong>e a<br />
su cargo. Cada <strong>en</strong>trada indica la dirección IP perman<strong>en</strong>te del nodo, la<br />
dirección del Home Ag<strong>en</strong>t, el id<strong>en</strong>tificador de la Estación Base que ha<br />
<strong>en</strong>viado la solicitud de registro, un temporizador que indica la validez de la<br />
<strong>en</strong>trada, y la dirección <strong>multicast</strong> que se le asigna al nodo móvil.<br />
El Home Ag<strong>en</strong>t procesa el m<strong>en</strong>saje de registro de la misma manera<br />
que lo hace con los m<strong>en</strong>sajes que se <strong>en</strong>vían según [RFC 3344]. Este<br />
proceso consiste <strong>en</strong> el <strong>en</strong>vío de un m<strong>en</strong>saje de Registration Reply hacia la<br />
dirección Care-of Address que <strong>en</strong> este caso se corresponde con la dirección<br />
del Ag<strong>en</strong>te de <strong>movilidad</strong> MMA. Como <strong>en</strong> el protocolo original este m<strong>en</strong>saje<br />
conti<strong>en</strong>e un campo donde se introduce un código para informar al nodo<br />
móvil del estado de su solicitud.<br />
Al recibir esta contestación, el Ag<strong>en</strong>te de Movilidad Multicast asigna<br />
una dirección <strong>multicast</strong> al nodo móvil de las que se <strong>en</strong>cu<strong>en</strong>tran libres. La<br />
asignación puede realizarse, bi<strong>en</strong> porque el propio MMA dispone de un<br />
servidor de direcciones <strong>multicast</strong> para asignar o bi<strong>en</strong> conectándose, por<br />
cualquier mecanismo, a un servidor de direcciones.<br />
El m<strong>en</strong>saje Request Reply es re<strong>en</strong>viado a la Estación Base<br />
correspondi<strong>en</strong>te añadi<strong>en</strong>do al final una nueva ext<strong>en</strong>sión que conti<strong>en</strong>e la<br />
dirección asignada y que d<strong>en</strong>ominamos Multicast Address Ext<strong>en</strong>sión<br />
(MAE). Para realizar un protocolo totalm<strong>en</strong>te compatible con el estándar se<br />
ha optado por desarrollar esta ext<strong>en</strong>sión según las estructuras de<br />
ext<strong>en</strong>sión descritas <strong>en</strong> [RFC 3344]. En particular se ha seleccionado el<br />
formato de ext<strong>en</strong>sión corto y se describe con detalle <strong>en</strong> el punto 3.5.2 Para<br />
asegurar la aut<strong>en</strong>ticidad el m<strong>en</strong>saje debería ir terminado por una<br />
ext<strong>en</strong>sión de aut<strong>en</strong>ticidad FA-FA. La recepción del m<strong>en</strong>saje provoca que la<br />
estación base se una al grupo <strong>multicast</strong> indicando <strong>en</strong> la ext<strong>en</strong>sión MAE. El<br />
estudio de la tecnología empleada a la hora de implem<strong>en</strong>tar el árbol<br />
<strong>multicast</strong> se realiza <strong>en</strong> el punto 3.6<br />
Para finalizar el m<strong>en</strong>saje de respuesta es <strong>en</strong>tregado por la Estación<br />
Base al nodo móvil adjuntando la dirección <strong>multicast</strong> asignada al mismo.<br />
77
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
Esto se realiza utilizando la ext<strong>en</strong>sión MAE y aut<strong>en</strong>tificándola, punto<br />
3.4.2, con una ext<strong>en</strong>sión MN-FA.<br />
Actualización de las tablas.<br />
Sigui<strong>en</strong>do el modelo del protocolo Mobile IP, el registro realizado<br />
tanto <strong>en</strong> el Home Ag<strong>en</strong>t como <strong>en</strong> la Estación Base y el Ag<strong>en</strong>te de Movilidad<br />
Multicast (MMA) (que actúan como Foreign Ag<strong>en</strong>ts del modelo original)<br />
ti<strong>en</strong>e un tiempo de vida limitado que está especificado <strong>en</strong> el campo<br />
‘Lifetime’ del m<strong>en</strong>saje de registro. Esto provoca que aún cuando el nodo<br />
móvil no modifique su situación t<strong>en</strong>ga que re-registrarse antes de que este<br />
tiempo v<strong>en</strong>za.<br />
El mecanismo de re-registro no difiere <strong>en</strong> nada del mecanismo de<br />
registro explicado anteriorm<strong>en</strong>te. El nodo móvil <strong>en</strong>vía el m<strong>en</strong>saje de<br />
registro que alcanzará el Home Ag<strong>en</strong>t vía MMA. Este ag<strong>en</strong>te detecta <strong>en</strong> la<br />
tabla que conti<strong>en</strong>e la lista de los nodos que el originario del m<strong>en</strong>saje ya<br />
existe por lo que no le asigna una dirección <strong>multicast</strong> nueva. Al recibir el<br />
m<strong>en</strong>saje de registro todos los elem<strong>en</strong>tos implicados (Estación Base, MMA y<br />
Home Ag<strong>en</strong>t) actualizan su <strong>en</strong>trada del temporizador correspondi<strong>en</strong>te al<br />
nodo móvil.<br />
3.3.3 Registro <strong>en</strong> una nueva BS d<strong>en</strong>tro del Dominio<br />
Según el procedimi<strong>en</strong>to explicado <strong>en</strong> el punto 3.3.1 el nodo móvil es<br />
capaz de detectar que se ha producido un cambio de estación base.<br />
Cuando este cambio implica además un cambio de dominio estamos <strong>en</strong> un<br />
handover Inter-domino, y se resuelve como se ha explicado <strong>en</strong> el punto<br />
3.3.2. En caso contrario se trata de un handover intra-dominio que no<br />
debe implicar al Home Ag<strong>en</strong>t.<br />
En este segundo caso el nodo móvil <strong>en</strong>vía un nuevo m<strong>en</strong>saje, que<br />
hemos d<strong>en</strong>ominado Intra-Domain Registration Request, hacia la nueva<br />
Estación Base. Este m<strong>en</strong>saje conti<strong>en</strong>e la dirección <strong>multicast</strong> utilizada por<br />
78
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
el móvil, la dirección de la estación base anterior y la dirección del MMA<br />
con el que se realizó el registro.<br />
La recepción de un m<strong>en</strong>saje de este t<strong>ip</strong>o por parte de la Estación<br />
Base provoca que la misma se conecte al árbol <strong>multicast</strong> que corresponde<br />
al nodo móvil (figura 3.5). Típicam<strong>en</strong>te el proceso se realiza utilizando<br />
m<strong>en</strong>sajes ‘Join’, aunque el mecanismo exacto dep<strong>en</strong>de del protocolo de<br />
<strong>en</strong>rutami<strong>en</strong>to <strong>multicast</strong> empleado (punto 3.6). Una vez la Estación Base ha<br />
recibido una confirmación positiva de la incorporación al árbol, vía ‘Ack<br />
Join’, se lo comunicará al nodo por medio de un m<strong>en</strong>saje que hemos<br />
d<strong>en</strong>ominado Intra-Domain Registration Reply.<br />
Este intercambio de m<strong>en</strong>sajes <strong>en</strong>tre el nodo móvil y la estación base<br />
deberían ser aut<strong>en</strong>tificados por medio de una nueva ext<strong>en</strong>sión de<br />
seguridad MH-FA. La opción seleccionada para poder realizar esta<br />
aut<strong>en</strong>tificación es que el Home Ag<strong>en</strong>t del nodo g<strong>en</strong>ere inicialm<strong>en</strong>te una<br />
llave de registro, por ejemplo utilizando [PER02], y que ésta sea distribuida<br />
<strong>en</strong>tre el nodo móvil y las estaciones base del dominio.<br />
Ag<strong>en</strong>te de Movilidad<br />
Multicast (MMA)<br />
Router<br />
Estación Base (BS)<br />
2<br />
3<br />
Nodo móvil (MN)<br />
(1) Intra-Domanin Registration Request<br />
(2) Multicast Join<br />
1<br />
4<br />
(3) Multicast Ack Join<br />
(4) Intra-Domain Registration Reply<br />
Figura 3.5 Handover Intra-dominio.<br />
79
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
Es importante destacar como el proceso de handover se ha limitado<br />
a la incorporación de la nueva estación base al árbol <strong>multicast</strong>, afectado<br />
sólo hasta el primer router común <strong>en</strong> la ruta hacia el núcleo (R<strong>en</strong>dezvous<br />
Point <strong>en</strong> el protocolo PIM-SM [RFC 2362]). Como se detallará<br />
posteriorm<strong>en</strong>te este proceso es s<strong>en</strong>siblem<strong>en</strong>te más rápido que realizar un<br />
nuevo registro <strong>en</strong> el Home Ag<strong>en</strong>t como indica el protocolo Mobile IP original<br />
o utilizar la solución del Registro Regional (Work in Progress) [GUS02].<br />
Exist<strong>en</strong> diversas soluciones posibles a la hora de realizar este<br />
handover intra-dominio. El princ<strong>ip</strong>al elem<strong>en</strong>to difer<strong>en</strong>ciador es si una vez<br />
com<strong>en</strong>zado la comunicación del nodo con la nueva estación base se pierde<br />
el contacto con la estación base antigua o no.<br />
El primer caso se d<strong>en</strong>omina ‘handover abrupto’ (Hard Handover).<br />
Se han propuesto distintas soluciones para lograr minimizar la pérdida de<br />
información <strong>en</strong> este t<strong>ip</strong>o de handovers. Un ejemplo es el propuesto <strong>en</strong><br />
[PER01] (Work in Progress) donde la estación base antigua, previa<br />
indicación de la nueva, le <strong>en</strong>vía los paquetes que ti<strong>en</strong>e <strong>en</strong> la cola dirigidos<br />
al nodo móvil.<br />
El segundo caso se d<strong>en</strong>ominado <strong>en</strong> la literatura ‘handover blando’<br />
(Soft Handover) y permite la comunicación con las dos estaciones. La<br />
utilización de la tecnología <strong>multicast</strong> <strong>en</strong> este t<strong>ip</strong>o de handovers permite<br />
soluciones de registro avanzado [LEO99], [MYS97] que eliminan la pérdida<br />
de paquetes durante el proceso.<br />
El estudio de las diversas soluciones de implem<strong>en</strong>tación del<br />
handover <strong>en</strong> el sistema propuesto se pres<strong>en</strong>ta <strong>en</strong> el capítulo 6. En el<br />
capítulo 7 se realiza, además, un estudio de las prestaciones.<br />
3.3.4 Transmisión y Recepción de datos<br />
La transmisión de datos hacia el nodo móvil puede realizarse una<br />
vez se ha realizado el registro de la nueva dirección Care-of Address <strong>en</strong> el<br />
80
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
Home Ag<strong>en</strong>t, como se ha explicado <strong>en</strong> el punto 3.3.2. Como <strong>en</strong> el protocolo<br />
Mobile IP, el Home Ag<strong>en</strong>t realizará una <strong>en</strong>capsulación de los datos que<br />
captura dirigidos hacia el nodo móvil <strong>en</strong>viándolos hacia la dirección<br />
registrada. Para ello, el Home Ag<strong>en</strong>t interceptará cualquier datagrama <strong>en</strong><br />
su red dirigido hacia el nodo móvil utilizando, por ejemplo funcionando<br />
como Proxy ARP. El método de <strong>en</strong>capsulación seleccionado dep<strong>en</strong>de del<br />
Home Ag<strong>en</strong>t pudi<strong>en</strong>do elegir <strong>en</strong>tre <strong>en</strong>capsulación IP <strong>en</strong> IP [RFC 2003],<br />
<strong>en</strong>capsulación mínima [RFC 2004] o <strong>en</strong>capsulación GRE [RFC 1701].<br />
Como se ha estudiado anteriorm<strong>en</strong>te los paquetes son<br />
<strong>en</strong>capsulados hacia la dirección IP de un Ag<strong>en</strong>te de Movilidad Multicast<br />
(MMA) de un dominio. Este ag<strong>en</strong>te, al recibir el datagrama, debe<br />
des<strong>en</strong>capsularlo y comparar la dirección IP destino del datagrama interior<br />
con las direcciones IP de la lista de nodos móviles visitantes del dominio.<br />
Una vez <strong>en</strong>contrada lo <strong>en</strong>capsula hacia la dirección <strong>multicast</strong> asignada al<br />
nodo y lo <strong>en</strong>vía al árbol <strong>multicast</strong>. En caso de que la dirección del<br />
datagrama no estuviera <strong>en</strong> su lista debe descartarlo, puesto que otras<br />
opciones, como <strong>en</strong>rutarlo a la dirección destino (Home Address del nodo),<br />
ocasionarían bucles <strong>en</strong> la red.<br />
Finalm<strong>en</strong>te las estaciones base que están conectadas al árbol<br />
<strong>multicast</strong> <strong>en</strong> ese mom<strong>en</strong>to recibirían los datagramas y tras<br />
des<strong>en</strong>capsularlos los <strong>en</strong>viarían al nodo móvil, utilizando para ello la<br />
dirección MAC que han almac<strong>en</strong>ado desde el <strong>en</strong>vío del m<strong>en</strong>saje<br />
‘Registration Request’. En la figura 3.6 se puede apreciar este proceso.<br />
Con respecto a la transmisión de datos desde el nodo móvil, éste<br />
selecciona la Estación Base como su router de salida. La dirección MAC<br />
del mismo la apr<strong>en</strong>de de los m<strong>en</strong>sajes ‘Advertisem<strong>en</strong>t’ recibidos. Es<br />
importante destacar que, como se justifica <strong>en</strong> [RFC 3344], <strong>en</strong> ningún<br />
mom<strong>en</strong>to el Nodo Móvil puede utilizar paquetes ARP para <strong>en</strong>contrar la<br />
dirección MAC de otro nodo de Internet.<br />
81
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
Host<br />
H.A<br />
(2)<br />
(3)<br />
(4)<br />
M.H<br />
(1)<br />
BS<br />
Subred<br />
MMA<br />
(1). Transmisión del datagrama original.<br />
(2). Transmisión del datagrama <strong>en</strong>capsulado. Dirección IP destino es MMA.<br />
(3). Transmisión <strong>en</strong>capsulada. La dirección destino es la dirección <strong>multicast</strong> asignada al M.H.<br />
(4). Transmisión del datagrama original <strong>en</strong> la red. La dirección física destino es la del M.H.<br />
Figura 3.6 Transmisión de datos hacia el Nodo móvil.<br />
La Estación Base ti<strong>en</strong>e la obligación de <strong>en</strong>rutar, al m<strong>en</strong>os, los<br />
paquetes de los nodos que ha registrado (bi<strong>en</strong> por medio de un<br />
‘Registration Request’ o bi<strong>en</strong> por un ‘Intra-Domanin Registration Request’).<br />
Esto significa que como mínimo deberá verificar la campo de control de<br />
errores (‘Checksum’) de la cabecera IP, decrem<strong>en</strong>tar el campo ‘Tiempo de<br />
Vida’, recalcular el campo de la cabecera y dirigir los datagramas al<br />
sigui<strong>en</strong>te router.<br />
Algunos routers <strong>en</strong> redes TCP/IP pued<strong>en</strong> utilizar políticas de<br />
seguridad como ‘filtrado a la <strong>en</strong>trada’ que descartan los paquetes cuya<br />
dirección IP fu<strong>en</strong>te no coincide con la topología de la red [RFC 2827]. Es<br />
decir, los routers descartan los paquetes cuyo prefijo de red de la dirección<br />
IP fu<strong>en</strong>te no coincide con ninguno de los prefijos de las redes que exist<strong>en</strong><br />
<strong>en</strong> dirección al <strong>en</strong>lace por el que se ha recibido el paquete.<br />
Este mecanismo de seguridad es un problema <strong>en</strong> <strong>en</strong>tornos <strong>basado</strong>s<br />
<strong>en</strong> Mobile IP, puesto que los paquetes <strong>en</strong>viados por el nodo móvil t<strong>en</strong>drán<br />
como dirección IP fu<strong>en</strong>te su dirección perman<strong>en</strong>te. D<strong>en</strong>tro de un dominio<br />
es de suponer que no existe ningún problema, pues el operador del<br />
82
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
dominio simplem<strong>en</strong>te no debe activar este t<strong>ip</strong>o de mecanismo <strong>en</strong> su red.<br />
Sin embargo una vez los paquetes abandonan el dominio puede que sean<br />
rechazados por alguno de los routers que atraviesa. Para solucionar el<br />
problema es necesario utilizar ‘Reverse Tunneling’ [RFC 3024].<br />
Específicam<strong>en</strong>te lo que se hace es que el router de salida del dominio,<br />
típicam<strong>en</strong>te un Ag<strong>en</strong>te de Movilidad Multicast MMA (aunque no<br />
necesariam<strong>en</strong>te) realiza un <strong>en</strong>capsulado del datagrama de manera que la<br />
dirección IP fu<strong>en</strong>te sea ahora la suya y la dirección destino la del Home<br />
Ag<strong>en</strong>t. Con esta solución los paquetes podrán atravesar perfectam<strong>en</strong>te la<br />
red, aunque ahora el problema del <strong>en</strong>caminami<strong>en</strong>to <strong>en</strong> triángulo también<br />
ocurre <strong>en</strong> la transmisión desde el MH.<br />
3.3.5 Escalabilidad<br />
La guía de conducta de IETF [RFC 3184] indica refiriéndose a la<br />
escalabilidad: “La escalabilidad es el último problema. Muchas ideas<br />
abordables <strong>en</strong> <strong>en</strong>tornos pequeños fallan este test crucial”. El desarrollo de<br />
este protocolo de micro-<strong>movilidad</strong> no ha sido aj<strong>en</strong>o a este problema,<br />
difer<strong>en</strong>ciándose la mayoría de los sistemas de micro-<strong>movilidad</strong> pres<strong>en</strong>tes<br />
<strong>en</strong> la bibliografía (punto 2.4). Solo el sistema TeleMIP [DAS00] com<strong>en</strong>tado<br />
<strong>en</strong> el punto 2.4.3 ofrece una solución escalable.<br />
Podemos distinguir tres t<strong>ip</strong>os de escalabilidad [EAR02]:<br />
• Escalabilidad geográfica: Relativo al área que abarca la red. En la<br />
arquitectura propuesta se refiere a la ext<strong>en</strong>sión geográfica que<br />
puede abarcar un dominio.<br />
• Escalabilidad de capacidad: Relativo a la capacidad de la red para<br />
soportar un volum<strong>en</strong> alto de tráfico.<br />
• Escalabilidad de terminales: Indica la capacidad de la red para<br />
soportar muchos dispositivos. En nuestro sistema se refiere al<br />
número de nodos móviles que pued<strong>en</strong> t<strong>en</strong>er servicio<br />
simultáneam<strong>en</strong>te d<strong>en</strong>tro <strong>en</strong> un dominio.<br />
83
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
Respecto a la escalabilidad geográfica no existe ninguna limitación<br />
ni <strong>en</strong> la arquitectura ni <strong>en</strong> el protocolo pres<strong>en</strong>tado. La separación <strong>en</strong><br />
dominios puede deberse tanto a criterios administrativos como a criterios<br />
meram<strong>en</strong>te geográficos, pudi<strong>en</strong>do abarcar desde un campus universitario<br />
hasta una ciudad <strong>en</strong>tera.<br />
Tampoco existe ninguna limitación <strong>en</strong> cuanto a la capacidad del<br />
sistema pues dep<strong>en</strong>de únicam<strong>en</strong>te de la tecnología a emplear. La mayoría<br />
de las redes móviles ti<strong>en</strong><strong>en</strong> la limitación <strong>en</strong> el ‘<strong>en</strong>torno radio’, <strong>en</strong> particular<br />
<strong>en</strong> el ancho de banda que puede ofrecer, que queda fuera de este estudio.<br />
En cuanto a la infraestructura fija, la capacidad dep<strong>en</strong>derá de la<br />
tecnología de los equ<strong>ip</strong>os empleados.<br />
El aspecto más importante sería la capacidad del dominio para<br />
soportar un número creci<strong>en</strong>te de usuarios. Estudiando la arquitectura<br />
propuesta se puede observar como exist<strong>en</strong> dos aspectos que pued<strong>en</strong><br />
limitar la escalabilidad:<br />
• Direcciones <strong>multicast</strong> disponibles<br />
• Sobrecarga del Ag<strong>en</strong>te de Movilidad Multicast.<br />
La asignación de direcciones <strong>multicast</strong> pres<strong>en</strong>taba un problema <strong>en</strong><br />
sistemas de <strong>movilidad</strong> <strong>multicast</strong> globales, <strong>en</strong> las que cada nodo móvil<br />
necesitaba una dirección <strong>multicast</strong> única [MYS98]. Sin embargo <strong>en</strong> el<br />
sistema pres<strong>en</strong>tado este aspecto pierde casi toda su importancia, pues las<br />
direcciones <strong>multicast</strong> son locales y, por tanto, son reutilizadas <strong>en</strong> cada<br />
dominio. El direccionami<strong>en</strong>to IP dispone de 2 28 direcciones <strong>multicast</strong><br />
(clase D), la mayoría de las cuales son libres [IANA]. Por ejemplo, el rango<br />
compr<strong>en</strong>dido <strong>en</strong>tre la dirección 238.0.0.0 hasta la dirección<br />
238.255.255.255 (238/8) está actualm<strong>en</strong>te libre y ofrece más de 16<br />
millones de direcciones. Además, <strong>en</strong> el caso de emplear tecnología SSM<br />
(Source-Specific Multicast) (ver punto 3.6), las direcciones <strong>multicast</strong> pued<strong>en</strong><br />
ser utilizadas simultáneam<strong>en</strong>te por todos los MMA.<br />
84
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
El aspecto más problemático del sistema propuesto es la<br />
sobrecarga del MMA, puesto que <strong>en</strong> un princ<strong>ip</strong>io es el <strong>en</strong>cargado de<br />
realizar todas las asignaciones de direcciones <strong>multicast</strong>, realizar la<br />
des<strong>en</strong>capsulación de los datos dirigidos a todos los nodos móviles y una<br />
nueva <strong>en</strong>capsulación con la dirección <strong>multicast</strong> asignada, y <strong>en</strong> g<strong>en</strong>eral<br />
realizar todas las funciones que el protocolo Mobile IP asigna a los Foreign<br />
Ag<strong>en</strong>ts. Para solucionar este problema se ha prestado un especial interés<br />
<strong>en</strong> permitir la coexist<strong>en</strong>cia de más de un Ag<strong>en</strong>te de Movilidad Multicast <strong>en</strong><br />
un mismo dominio.<br />
Las Estaciones Base indican, <strong>en</strong> el m<strong>en</strong>saje ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’,<br />
la dirección IP del MMA que se ofrece como Care-of Address. La elección<br />
del MMA ofrecido se debería realizar utilizando algoritmos para equilibrar<br />
la carga de gestión <strong>en</strong>tre todos los MMA exist<strong>en</strong>tes. Esta elección se realiza<br />
localm<strong>en</strong>te <strong>en</strong> cada Estación Base a partir de la información recibida de los<br />
difer<strong>en</strong>tes MMA. Para ello los MMA podrían <strong>en</strong>viar, de forma periódica,<br />
m<strong>en</strong>sajes sobre su estado a la dirección <strong>multicast</strong> 224.0.0.11 ('Todos los<br />
Ag<strong>en</strong>tes de Movilidad' según [IANA]). La aut<strong>en</strong>ticidad de estos m<strong>en</strong>sajes<br />
estaría garantizada pues las difer<strong>en</strong>tes Estaciones Base y el MMA<br />
compart<strong>en</strong> un contexto de seguridad (punto 3.4).<br />
Desde el punto de vista del Nodo Móvil la asignación a un MMA o a<br />
otro es irrelevante, aunque se manti<strong>en</strong>e constante durante toda la estancia<br />
del nodo <strong>en</strong> el dominio. Así cuando el nodo debe r<strong>en</strong>ovar su registro con su<br />
Home Ag<strong>en</strong>t <strong>en</strong>vía un m<strong>en</strong>saje de registro indicando la dirección Care-of<br />
Address que está utilizando, indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de la que está <strong>en</strong>viando<br />
la Estación Base que controla la red donde está situado <strong>en</strong> ese mom<strong>en</strong>to.<br />
Por último indicar que cuando un nodo móvil cambia de red puede<br />
recibir m<strong>en</strong>sajes de anuncio ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ anunciando otro MMA.<br />
En el caso de que sólo existiera un MMA por dominio, esto indicaría que se<br />
ha producido un cambio de dominio y por tanto que estamos <strong>en</strong> un<br />
handover Inter-dominio. Sin embargo ahora es posible recibir m<strong>en</strong>sajes<br />
anunciando otros MMA y sin embargo permanecer <strong>en</strong> el mismo dominio.<br />
Para que el nodo móvil sepa si debe realizar un handover intra o inter<br />
85
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
dominio los m<strong>en</strong>sajes de anuncio incorporan una ext<strong>en</strong>sión de indicador<br />
de dominio.<br />
3.4 ASPECTOS RELATIVOS A LA SEGURIDAD EN EL<br />
SISTEMA DE MICROMOVILIDAD PRESENTADO<br />
3.4.1 Introducción a la seguridad <strong>en</strong> <strong>en</strong>tornos móviles<br />
Como se com<strong>en</strong>tó <strong>en</strong> el punto 2.3.5 los sistemas que permit<strong>en</strong> la<br />
<strong>movilidad</strong> de los nodos son particularm<strong>en</strong>te vulnerables a escuchas y otros<br />
ataques. Un ejemplo de la vulnerabilidad puede verse estudiando el<br />
protocolo Mobile IP <strong>en</strong> su etapa de registro. En este caso un registro falso<br />
por parte de un atacante se traduciría <strong>en</strong> que el Home Ag<strong>en</strong>t registrará una<br />
dirección Care-of falsa, y que <strong>en</strong>viará todos los datos a ella <strong>en</strong> vez de a la<br />
original.<br />
Para evitar estos problemas es necesario que los sistemas móviles<br />
incorpor<strong>en</strong> mecanismos de ‘aut<strong>en</strong>tificación’, que consiste <strong>en</strong> un proceso<br />
por el cual el nodo transmisor asegura su id<strong>en</strong>tidad al nodo que recibe. En<br />
el protocolo Mobile IP todos los elem<strong>en</strong>tos que forman el sistema<br />
incorporan mecanismos para realizar aut<strong>en</strong>tificación de los m<strong>en</strong>sajes<br />
intercambiados. En este protocolo, el mecanismo de seguridad por defecto<br />
es HMAC-MD5 [RFC 2104] con una llave de 128 bits distribuida<br />
manualm<strong>en</strong>te. Opcionalm<strong>en</strong>te, también se permit<strong>en</strong> otros algoritmos de<br />
aut<strong>en</strong>tificación, tamaño de claves, o mecanismos de distribución de las<br />
mismas con el fin de aum<strong>en</strong>tar la seguridad.<br />
Dos elem<strong>en</strong>tos del sistema que quier<strong>en</strong> aut<strong>en</strong>tificar los m<strong>en</strong>sajes<br />
que se intercambian establec<strong>en</strong> una asociación segura utilizando uno o<br />
más contextos de seguridad disponibles. Cada contexto de seguridad<br />
incluye una clave secreta y un algoritmo de aut<strong>en</strong>tificación.<br />
86
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
Como se estudió <strong>en</strong> 2.3.5 el protocolo Mobile IP define una serie de<br />
ext<strong>en</strong>siones de aut<strong>en</strong>tificación con el fin de aut<strong>en</strong>tificar los m<strong>en</strong>sajes de<br />
registro y de respuesta de registro. Ambos m<strong>en</strong>sajes incorporan,<br />
obligatoriam<strong>en</strong>te, una ext<strong>en</strong>sión de aut<strong>en</strong>tificación Mobile-Home al final del<br />
mismo, que permite al otro extremo asegurar la autoría del m<strong>en</strong>saje. Un<br />
campo d<strong>en</strong>tro de esta cabecera d<strong>en</strong>ominado SPI (Security Parameter Index)<br />
indica el contexto de seguridad a emplear.<br />
Exist<strong>en</strong>, además, dos ext<strong>en</strong>siones de aut<strong>en</strong>tificación adicionales<br />
(Mobile-Foreign y Foreign-Home), cuyo uso no es obligatorio. El princ<strong>ip</strong>al<br />
impedim<strong>en</strong>to para la utilización de estas ext<strong>en</strong>siones de aut<strong>en</strong>tificación es<br />
la necesidad de que exista, previam<strong>en</strong>te, una asociación segura <strong>en</strong>tre los<br />
elem<strong>en</strong>tos que quier<strong>en</strong> comunicarse. El estándar original indica que por<br />
defecto el intercambio de claves se realiza de forma manual. Esto es<br />
factible para la aut<strong>en</strong>tificación <strong>en</strong>tre el nodo móvil y su Home Ag<strong>en</strong>t pero<br />
no lo es cuando se trata de realizar <strong>en</strong>tre los nodos y todos los Foreign<br />
Ag<strong>en</strong>ts que pued<strong>en</strong> visitar. Como se com<strong>en</strong>ta a continuación, <strong>en</strong> la<br />
actualidad se está trabajando estandarizar mecanismos de intercambio de<br />
claves utilizando servidores AAA (Auth<strong>en</strong>tication, Autorization, Accounting).<br />
3.4.2 Seguridad <strong>en</strong> el Sistema de Micro-<strong>movilidad</strong> Multicast<br />
Los problemas de seguridad que existían <strong>en</strong> el protocolo Mobile IP, y<br />
que han llevado a la utilización de ext<strong>en</strong>siones de aut<strong>en</strong>tificación <strong>en</strong> el<br />
proceso de registro, se manifiestan <strong>en</strong> mayor medida <strong>en</strong> el sistema de<br />
micro-<strong>movilidad</strong> <strong>multicast</strong> propuesto.<br />
Una fu<strong>en</strong>te de problemas es el registro del nodo móvil al <strong>en</strong>trar <strong>en</strong><br />
un nuevo dominio. Una vez el Home Ag<strong>en</strong>t ha recibido el m<strong>en</strong>saje de<br />
registro contesta con un m<strong>en</strong>saje de respuesta aut<strong>en</strong>tificado con la<br />
ext<strong>en</strong>sión de aut<strong>en</strong>tificación Mobile-Home ya com<strong>en</strong>tada. El MMA recibe<br />
este m<strong>en</strong>saje de respuesta de registro que <strong>en</strong>vía hacia la Estación Base<br />
(punto 3.3.2) añadi<strong>en</strong>do una nueva ext<strong>en</strong>sión que conti<strong>en</strong>e la dirección<br />
<strong>multicast</strong> asignada (Multicast Address Ext<strong>en</strong>sión, MAE). Para asegurar la<br />
87
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
aut<strong>en</strong>ticidad de esta ext<strong>en</strong>sión el m<strong>en</strong>saje se termina con una ext<strong>en</strong>sión de<br />
aut<strong>en</strong>ticidad FA-FA. Esta ext<strong>en</strong>sión de seguridad no existe <strong>en</strong> el protocolo<br />
Mobile IP, pero ha sido ya definida y utilizada <strong>en</strong> [GUS02]. En un princ<strong>ip</strong>io<br />
esto no es problemático pues las estaciones base y los MMA forman un<br />
sistema estable <strong>en</strong> el tiempo, donde no es difícil establecer una asociación<br />
segura de forma perman<strong>en</strong>te.<br />
MN BS MMA HA<br />
(1)<br />
(2)<br />
(3)<br />
(6)<br />
(5)<br />
(4)<br />
(1)<br />
Reg.Request<br />
Ext. Aut. MN-HA<br />
(2)<br />
Reg.Request Ext. Aut. MN-HA Base Station. NAI<br />
Ext. Aut. FA-FA<br />
(3)<br />
Reg.Request<br />
Ext. Aut. MN-HA<br />
(4)<br />
Reg.Reply<br />
Ext. Aut. MN-HA<br />
(5)<br />
(6)<br />
Reg.Reply Ext. Aut. MN-HA MAE Ext. Aut. FA-FA<br />
Reg.Reply Ext. Aut. MN-HA MAE Ext. Aut. MN-FA<br />
Figura 3.7 Registro del nodo mostrando las ext<strong>en</strong>siones de aut<strong>en</strong>tificación.<br />
El problema aparece cuando la Estación Base debe transmitir el<br />
m<strong>en</strong>saje de respuesta de registro al nodo móvil, adjuntando la ext<strong>en</strong>sión<br />
MAE para que el nodo conozca la dirección <strong>multicast</strong> asignada. El m<strong>en</strong>saje<br />
debería, según Mobile IP, terminado con una ext<strong>en</strong>sión de aut<strong>en</strong>tificación<br />
Mobile-Foreign para lo que es necesario que exista una asociación segura<br />
88
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
<strong>en</strong>tre el nodo móvil y la Estación Base correspondi<strong>en</strong>te. En la figura 3.7 se<br />
muestra este proceso.<br />
Existe una solución para no necesitar las asociaciones <strong>en</strong>tre el<br />
nodo móvil y las Estaciones Base. El MMA podría <strong>en</strong>viar la petición del<br />
registro del nodo móvil (Registration Request) hacia el Home Ag<strong>en</strong>t<br />
anexando la ext<strong>en</strong>sión MAE (Multicast Address Ext<strong>en</strong>sión). Esta ext<strong>en</strong>sión<br />
va aut<strong>en</strong>tificada con una ext<strong>en</strong>sión de aut<strong>en</strong>ticidad Foreign-Home. El Home<br />
Ag<strong>en</strong>t se modifica para que <strong>en</strong>ti<strong>en</strong>da la ext<strong>en</strong>sión MAE de manera que la<br />
incorpore <strong>en</strong> el m<strong>en</strong>saje de respuesta (Registration Reply). Evid<strong>en</strong>tem<strong>en</strong>te<br />
esta ext<strong>en</strong>sión estará aut<strong>en</strong>tificada con la ext<strong>en</strong>sión Mobile-Home que<br />
obligatoriam<strong>en</strong>te incorpora el Home Ag<strong>en</strong>t al final del m<strong>en</strong>saje, y por ello<br />
podrá llegar hasta el nodo móvil sin la necesidad de la aut<strong>en</strong>tificación<br />
Mobile-Foreign. En la figura 3.8 se muestran las modificaciones realizadas.<br />
El proceso ha sustituido la necesidad de establecer asociaciones<br />
seguras <strong>en</strong>tre todos los nodos y todas las estaciones base a cambio de la<br />
exist<strong>en</strong>cia de una asociación segura <strong>en</strong>tre el MMA y el Home Ag<strong>en</strong>t. Sin<br />
embargo, como se detalla a continuación, exist<strong>en</strong> otros problemas<br />
asociados al sistema de micro-<strong>movilidad</strong> que hac<strong>en</strong> necesario la exist<strong>en</strong>cia<br />
de las asociaciones <strong>en</strong>tre el móvil y las Estaciones Base. Esto, unido a que<br />
la solución pres<strong>en</strong>tada obliga a la modificación del Home Ag<strong>en</strong>t, que ahora<br />
debería <strong>en</strong>t<strong>en</strong>der las ext<strong>en</strong>siones MAE, hace que la solución sea<br />
desestimada de ahora <strong>en</strong> adelante.<br />
(3)<br />
Reg.Request<br />
Ext. Aut. MN-HA<br />
MAE<br />
Ext. Aut. FA-HA<br />
(4)<br />
Reg.Reply<br />
MAE<br />
Ext. Aut. MN-HA<br />
Ext. Aut. FA-HA<br />
(5)<br />
Reg.Reply<br />
MAE<br />
Ext. Aut. MN-HA<br />
Ext. Aut. FA-FA<br />
(6)<br />
Reg.Reply<br />
MAE<br />
Ext. Aut. MN-HA<br />
Figura 3.8 Modificaciones propuestas al proceso de registro.<br />
89
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
En el sistema pres<strong>en</strong>tado se realiza, aparte del registro al <strong>en</strong>trar <strong>en</strong><br />
un nuevo dominio, un registro intra-dominio que no afecta al Home Ag<strong>en</strong>t.<br />
En esta fase la Estación Base que recibe el m<strong>en</strong>saje de registro intradominio<br />
debe conectarse al árbol <strong>multicast</strong> del nodo móvil (punto 3.3.3).<br />
La Estación Base debe asegurarse que el nodo móvil que solicita el registro<br />
es el nodo que realm<strong>en</strong>te ti<strong>en</strong>e asignada esa dirección <strong>multicast</strong>. En caso<br />
contrario se estaría transmiti<strong>en</strong>do la información al atacante, e incluso<br />
dep<strong>en</strong>di<strong>en</strong>do del mecanismo de handover empleado, impedir que el nodo<br />
auténtico la recibiera. En definitiva es necesario que los m<strong>en</strong>sajes Intra-<br />
Domain Registration Request, intercambiados <strong>en</strong>tre el nodo móvil y la<br />
Estación Base, estén aut<strong>en</strong>tificados por medio de una ext<strong>en</strong>sión de<br />
aut<strong>en</strong>tificación.<br />
La necesidad de la exist<strong>en</strong>cia de asociaciones de seguridad <strong>en</strong>tre el<br />
nodo móvil y otros elem<strong>en</strong>tos del sistema no es exclusiva del sistema<br />
pres<strong>en</strong>tado, al contrario, es el princ<strong>ip</strong>al problema con el que se han<br />
<strong>en</strong>contrado los princ<strong>ip</strong>ales trabajos que han int<strong>en</strong>tado superar las<br />
limitaciones del protocolo Mobile IP. Así, el mecanismo de Optimización de<br />
Ruta [PER01] que se com<strong>en</strong>tó <strong>en</strong> el punto 2.3.6 necesita la exist<strong>en</strong>cia de<br />
una asociación segura <strong>en</strong>tre el nodo móvil y todos los hosts con quién se<br />
va a comunicar. La utilización de Mobile IP con Registro Regional [GUS02],<br />
como se estudió <strong>en</strong> el punto 2.3.7, también necesita estas asociaciones<br />
seguras para poder aut<strong>en</strong>tificar los m<strong>en</strong>sajes de registro regional.<br />
Utilización de servidores AAA.<br />
La creación de una asociación de seguridad <strong>en</strong>tre dos elem<strong>en</strong>tos de<br />
la red conlleva la exist<strong>en</strong>cia de una clave conocida por ambos elem<strong>en</strong>tos.<br />
En el caso de la asociación <strong>en</strong>tre el nodo móvil y su Home Ag<strong>en</strong>t, esta<br />
asociación puede configurarse de una forma manual, como se suponía <strong>en</strong><br />
el protocolo Mobile IP. Otras asociaciones de seguridad como la de los<br />
difer<strong>en</strong>tes elem<strong>en</strong>tos que forman un dominio (Estaciones Base y Ag<strong>en</strong>tes de<br />
Movilidad Multicast) también son factibles al ser perman<strong>en</strong>tes. Sin<br />
embargo, la solución no es operativa cuando la asociación de seguridad es<br />
<strong>en</strong>tre el nodo móvil y otros los elem<strong>en</strong>tos del sistema como Estaciones<br />
90
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
Base, pues no sería escalable tanto geográficam<strong>en</strong>te como <strong>en</strong> número de<br />
terminales (punto 3.3.5).<br />
La idea princ<strong>ip</strong>al para solucionar el problema se <strong>en</strong>cu<strong>en</strong>tra<br />
actualm<strong>en</strong>te <strong>en</strong> desarrollo y se basa <strong>en</strong> la utilización de servidores AAA<br />
(Auth<strong>en</strong>tication, Authorization, Accounting) como RADIUS [RFC 2865] o<br />
DIAMETER [CAL01]. La utilización de servidores AAA para lograr<br />
asociaciones seguras <strong>en</strong>tre los difer<strong>en</strong>tes elem<strong>en</strong>tos que forman un sistema<br />
de <strong>movilidad</strong> se describe <strong>en</strong> [RFC 2977], donde se define un modelo básico<br />
a seguir.<br />
Según el modelo, que se pres<strong>en</strong>ta <strong>en</strong> la figura 3.9, <strong>en</strong> cada Dominio<br />
Administrativo existe una autoridad local (AAAL) que puede establecer<br />
comunicaciones seguras con la autoridad del nodo móvil que solicita<br />
cred<strong>en</strong>ciales (AAAH). Los Foreign Ag<strong>en</strong>ts del dominio dispon<strong>en</strong>, a su vez, de<br />
conexiones seguras con el AAAL del Dominio. Por tanto, los Foreign Ag<strong>en</strong>ts<br />
solicitan al AAAL que verifique las cred<strong>en</strong>ciales del nodo. Esta autoridad<br />
no ti<strong>en</strong>e sufici<strong>en</strong>te información local para realizar la tarea pero es capaz de<br />
comunicarse con la autoridad del nodo quién realizará la verificación.<br />
Local Domain<br />
Home Domain<br />
AAAL<br />
AAAH<br />
MN<br />
FA<br />
MN: Nodo Móvil<br />
FA: Foreign Ag<strong>en</strong>t<br />
AAAL: Autoridad Local<br />
AAAH: Autoridad del nodo<br />
Figura 3.9. Modelo básico para la utilización de servidores AAA <strong>en</strong> Mobile IP.<br />
Podemos adaptar el modelo g<strong>en</strong>eral a nuestro sistema de micro<strong>movilidad</strong>,<br />
simplificándolo al máximo. Suponemos que el Home Ag<strong>en</strong>t<br />
funciona como servidor de aut<strong>en</strong>tificación de los nodos móviles a su cargo.<br />
91
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
Cuando recibe una solicitud de registro (‘Registration Request’), contesta<br />
incorporando al m<strong>en</strong>saje de respuesta (‘Registration Reply’) una ext<strong>en</strong>sión<br />
que aporta al nodo móvil información para establecer una asociación de<br />
seguridad con las Estaciones Base del Dominio donde se <strong>en</strong>cu<strong>en</strong>tra. Puede<br />
tomarse, como base para el diseño de la ext<strong>en</strong>sión, la detallada <strong>en</strong> [PER02]<br />
d<strong>en</strong>ominada ‘Unsolicited MN-FA Key Material From AAA’.<br />
Es necesario, además, hacer llegar la información necesaria para<br />
construir la asociación de seguridad a los difer<strong>en</strong>tes elem<strong>en</strong>tos del<br />
dominio. Los trabajos que actualm<strong>en</strong>te tratan de la utilización de<br />
servidores AAA <strong>en</strong> <strong>en</strong>tornos de redes IP móviles dejan esto fuera de<br />
estudio, pues dep<strong>en</strong>de de los aspectos particulares de la infraestructura<br />
AAA utilizada. Sin embargo <strong>en</strong> la versión simplificada que se está<br />
proponi<strong>en</strong>do, donde el Home Ag<strong>en</strong>t actúa de servidor de aut<strong>en</strong>tificación, es<br />
posible realizar esta transmisión de manera s<strong>en</strong>cilla.<br />
El primer paso es suponer que existe una asociación de seguridad<br />
<strong>en</strong>tre el MMA y el Home Ag<strong>en</strong>t y otra <strong>en</strong>tre los difer<strong>en</strong>tes elem<strong>en</strong>tos que<br />
forman un dominio. El Home Ag<strong>en</strong>t incorporará, al final del m<strong>en</strong>saje de<br />
respuesta de registro, una ext<strong>en</strong>sión con un formato similar a la<br />
anteriorm<strong>en</strong>te com<strong>en</strong>tada que cont<strong>en</strong>ga la información necesaria para la<br />
creación de la asociación de seguridad <strong>en</strong>tre el nodo móvil y las Estaciones<br />
Base. Esta ext<strong>en</strong>sión estará aut<strong>en</strong>tificada por una ext<strong>en</strong>sión de<br />
aut<strong>en</strong>ticidad FA-HA. El Ag<strong>en</strong>te de Movilidad Multicast (MMA) elimina estas<br />
dos ext<strong>en</strong>siones del final del m<strong>en</strong>saje antes de re<strong>en</strong>viarlo a la Estación<br />
Base correspondi<strong>en</strong>te.<br />
En la sigui<strong>en</strong>te figura se muestra como quedaría finalm<strong>en</strong>te el<br />
registro que se describió anteriorm<strong>en</strong>te <strong>en</strong> la figura 3.7. Es interesante<br />
observar como se ha vuelto a incorporar material para que la Estación<br />
Base que ti<strong>en</strong>e conectado <strong>en</strong> ese mom<strong>en</strong>to al nodo móvil pueda crear de la<br />
asociación de seguridad con el nodo.<br />
Adicionalm<strong>en</strong>te es necesario que el MMA <strong>en</strong>víe un nuevo m<strong>en</strong>saje a<br />
todos los elem<strong>en</strong>tos del dominio con esta información, de manera que a<br />
partir de ese mom<strong>en</strong>to el nodo móvil pueda realizar registros intra-dominio<br />
92
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
comunicándose con las demás Estaciones Base de una forma<br />
aut<strong>en</strong>tificada.<br />
MN BS MMA HA<br />
(1)<br />
(2)<br />
(3)<br />
(6)<br />
(5)<br />
(4)<br />
(4)<br />
Reg.Reply<br />
Key M. MN-FA<br />
Ext. MN-HA Key Mat. MN-FA Ext. FA-HA<br />
(5)<br />
(6)<br />
Reg.Reply Key M. MN-FA Ext. MN-HA MAE Key M. MN-FA FA-FA<br />
Reg.Reply Key M. MN-FA Ext. MN-HA MAE Ext. MN-FA<br />
Figura 3.10 Proceso de registro con transmisión de material para la creación de<br />
asociaciones de seguridad MN-FA.<br />
Es importante destacar que la solución aquí mostrada es una<br />
versión simplificada de los mecanismos de aut<strong>en</strong>tificación utilizando<br />
servidores AAA. Los problemas que se han pres<strong>en</strong>tado <strong>en</strong> el sistema de<br />
micro-<strong>movilidad</strong> propuesto no difier<strong>en</strong> de los que han aparecido <strong>en</strong> otras<br />
variaciones del protocolo Mobile IP, o incluso <strong>en</strong> el mismo protocolo, donde<br />
tan solo propon<strong>en</strong> la distribución manual de claves. Esto significa que<br />
cualquier solución que actualm<strong>en</strong>te se <strong>en</strong>cu<strong>en</strong>tra bajo estudio será<br />
utilizable <strong>en</strong> el sistema de micro-<strong>movilidad</strong>.<br />
93
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
3.5 FORMATO DE LOS MENSAJES<br />
Como se ha explicado anteriorm<strong>en</strong>te, el sistema de micro-<strong>movilidad</strong><br />
<strong>multicast</strong> se ha desarrollado sigui<strong>en</strong>do las directrices de diseño<br />
establecidas por el protocolo Mobile IP (MIP), [RFC 3344]. De esta manera<br />
ha sido posible utilizar este protocolo para realizar la macro-<strong>movilidad</strong> de<br />
una forma fluida y transpar<strong>en</strong>te para el nodo móvil. En este punto se va a<br />
mostrar los nuevos m<strong>en</strong>sajes y las ext<strong>en</strong>siones desarrolladas.<br />
3.5.1 M<strong>en</strong>sajes para el descubrimi<strong>en</strong>to de la red<br />
En el punto 3.3.1 se indicó la utilización de un m<strong>en</strong>saje Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t que es <strong>en</strong>viado de forma periódica por las Estaciones Base<br />
para indicar su pres<strong>en</strong>cia.<br />
El m<strong>en</strong>saje es similar al definido por Mobile IP, utilizando un<br />
paquete ICMP Router Discovery [RFC 1256] con una ext<strong>en</strong>sión de<br />
<strong>movilidad</strong> d<strong>en</strong>ominada <strong>en</strong> [RFC 3344] como ‘Mobility Ag<strong>en</strong>t Advertisem<strong>en</strong>t’.<br />
El único cambio realizado ha sido la incorporación de un flag que<br />
d<strong>en</strong>ominamos ‘X’. En la figura 3.11 podemos observar como ha sido<br />
introducido después de los definidos <strong>en</strong> [RFC 3344], [RFC 3024], [PER01] y<br />
[GUS02]. El flag se utiliza para indicar al nodo móvil que el dominio<br />
soporta el sistema de micro-<strong>movilidad</strong> <strong>multicast</strong>.<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o Longitud Número de secu<strong>en</strong>cia<br />
Tiempo de vida R B H F M G R T S I X Reserv.<br />
Dirección de la Estación Base.<br />
Care-of Address (Dirección del MMA )<br />
...................................<br />
Figura 3.11 Ext<strong>en</strong>sión ‘Mobility Ag<strong>en</strong>t Advertisem<strong>en</strong>t’.<br />
94
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
La ext<strong>en</strong>sión anterior va seguida, obligatoriam<strong>en</strong>te, por una<br />
ext<strong>en</strong>sión de prefijo de red definida <strong>en</strong> [RFC 3344], que se utilizará, junto<br />
con la dirección del Ag<strong>en</strong>te de la Estación Base, para que el móvil sepa si<br />
ha cambiado de subred o no.<br />
Es importante com<strong>en</strong>tar que se ha introducido la dirección de la<br />
Estación Base como primera dirección Care-of Address. El motivo de esto<br />
es la compatibilidad. Una de los cambios que se produjo <strong>en</strong>tre el estándar<br />
de Mobile IP original [RFC 2002] y el actual fue el de indicar que los nodos<br />
móviles deberían tomar como Care-of Address la primera de la lista. De<br />
esta manera si un nodo móvil no soporta el sistema de micro-<strong>movilidad</strong><br />
propuesto tomaría como Care-of Address, la dirección de la Estación Base.<br />
En esta situación la Estación Base actuaría como un Foreign Ag<strong>en</strong>t<br />
tradicional. Si el nodo soporta el sistema propuesto sabe que la dirección<br />
que debe tomar como Care-of Address es la segunda que se corresponde<br />
con el MMA asignado.<br />
El m<strong>en</strong>saje irá finalizado por una ext<strong>en</strong>sión que d<strong>en</strong>ominamos<br />
‘Domain NAI Ext<strong>en</strong>sion’. Esta ext<strong>en</strong>sión ha sido creada a partir de la<br />
ext<strong>en</strong>sión NAI G<strong>en</strong>eralizada (NAI, G<strong>en</strong>eralized Network Access Id<strong>en</strong>tifier)<br />
expuesta <strong>en</strong> [KHA01]. A la ext<strong>en</strong>sión, que se muestra <strong>en</strong> la figura 3.12, le<br />
podríamos asignar el valor de subt<strong>ip</strong>o 5, que <strong>en</strong> la actualidad se <strong>en</strong>cu<strong>en</strong>tra<br />
libre, o cualquier otro valor asignado por la IANA.<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o Longitud Subt<strong>ip</strong>o =5 NAI.......<br />
Figura 3.12 Ext<strong>en</strong>sión ‘Domain NAI’.<br />
El segundo t<strong>ip</strong>o de m<strong>en</strong>saje que se utiliza <strong>en</strong> el descubrimi<strong>en</strong>to de<br />
la red es el d<strong>en</strong>ominada ‘Ag<strong>en</strong>t Solicitation’, y es idéntico al expuesto <strong>en</strong> el<br />
protocolo original [RFC 3344].<br />
95
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
3.5.2 M<strong>en</strong>sajes <strong>en</strong> el registro <strong>en</strong> un nuevo Dominio<br />
Registration Request<br />
El proceso de registro <strong>en</strong> un nuevo dominio se realiza utilizando un<br />
mecanismo totalm<strong>en</strong>te compatible con el protocolo Mobile IP. Así, el<br />
m<strong>en</strong>saje ‘Registration Request’ que el nodo <strong>en</strong>vía a la Estación Base es el<br />
mismo que el definido <strong>en</strong> [RFC 3344], incluy<strong>en</strong>do la ext<strong>en</strong>sión de<br />
aut<strong>en</strong>tificación obligatoria MN-HA. La estación Base lo re<strong>en</strong>vía al Ag<strong>en</strong>te de<br />
Movilidad Multicast que vi<strong>en</strong>e definido por dirección Care-of Address<br />
elegida por el Nodo Móvil.<br />
Como se explicó <strong>en</strong> el punto 3.3.2, la Estación Base añade al<br />
m<strong>en</strong>saje de registro una ext<strong>en</strong>sión de id<strong>en</strong>tificación de la estación base que<br />
está definida <strong>en</strong> [KHA01] y que se d<strong>en</strong>omina ‘FA NAI’. Esta ext<strong>en</strong>sión<br />
v<strong>en</strong>drá aut<strong>en</strong>tificada por una ext<strong>en</strong>sión de aut<strong>en</strong>tificación FA-FA. La<br />
ext<strong>en</strong>sión de aut<strong>en</strong>tificación com<strong>en</strong>tada no vi<strong>en</strong>e definida <strong>en</strong> el estándar<br />
original [RFC 3344]. Sin embargo <strong>en</strong> [RFC 3012] se define un formato<br />
g<strong>en</strong>eral para la creación de ext<strong>en</strong>siones de aut<strong>en</strong>tificación. En particular la<br />
ext<strong>en</strong>sión FA-FA ya ha sido utilizada <strong>en</strong> [GUS02] de manera que el valor<br />
del campo ‘Subt<strong>ip</strong>o’ sería el asignado por la IANA. En la figura 3.13 se<br />
observa esta ext<strong>en</strong>sión.<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o = 36 Subt<strong>ip</strong>o Longitud<br />
SPI<br />
Aut<strong>en</strong>tificador.........<br />
Figura 3.13 Ext<strong>en</strong>sión de aut<strong>en</strong>tificación FA-FA.<br />
Registration Reply.<br />
Una vez el Home Ag<strong>en</strong>t registra la nueva dirección <strong>en</strong>vía un<br />
m<strong>en</strong>saje ‘Registration Reply’ idéntico al definido <strong>en</strong> [RFC 3344]. Dicho<br />
m<strong>en</strong>saje es aut<strong>en</strong>tificado con la ext<strong>en</strong>sión obligatoria MN-HA. El Ag<strong>en</strong>te<br />
96
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
MMA re<strong>en</strong>vía el m<strong>en</strong>saje a la Estación Base correspondi<strong>en</strong>te añadi<strong>en</strong>do<br />
una nueva ext<strong>en</strong>sión que d<strong>en</strong>ominamos ‘Multicast Address Ext<strong>en</strong>sión’<br />
(MAE), que irá aut<strong>en</strong>tificada por una ext<strong>en</strong>sión de aut<strong>en</strong>tificación FA-FA<br />
como la explicada anteriorm<strong>en</strong>te.<br />
La ext<strong>en</strong>sión MAE se muestra <strong>en</strong> la figura 3.14, y ha sido diseñada<br />
según las estructuras de ext<strong>en</strong>sión descritas <strong>en</strong> [RFC 3344]. En particular<br />
se ha seleccionado el formato de ext<strong>en</strong>sión corto. El campo ‘T<strong>ip</strong>o’ tomaría<br />
el valor asignado por la IANA. El campo ‘Longitud’ toma el valor 5 y el<br />
campo ‘subt<strong>ip</strong>o’ no es necesario, tomando por tanto el valor 0.<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o Longitud = 5 Subt<strong>ip</strong>o = 0 Reservado<br />
Dirección Multicast Asignada<br />
Figura 3.14 Ext<strong>en</strong>sión de Dirección Multicast, MAE.<br />
Finalm<strong>en</strong>te la Estación Base re<strong>en</strong>vía el m<strong>en</strong>saje al nodo móvil<br />
eliminando la ext<strong>en</strong>sión de aut<strong>en</strong>tificación FA-FA y añadi<strong>en</strong>do una<br />
ext<strong>en</strong>sión de aut<strong>en</strong>tificación MN-FA definida <strong>en</strong> [RFC 3344].<br />
Cuestiones relativas a la seguridad.<br />
En el punto 3.4.2 se estudió el problema de la creación de una<br />
asociación de seguridad <strong>en</strong>tre el nodo móvil y la Estación Base. La<br />
solución ofrecida se basaba <strong>en</strong> el empleo de ext<strong>en</strong>siones al m<strong>en</strong>saje de<br />
respuesta de registro, con el fin de proporcionar el material necesario para<br />
poder establecer dicha asociación. A continuación se pres<strong>en</strong>ta el formato<br />
propuesto para estas ext<strong>en</strong>siones. Es importante destacar que ésta es una<br />
posible solución para el establecimi<strong>en</strong>to de una asociación <strong>en</strong>tre el nodo y<br />
las Estaciones Base, y que no se descartan otras soluciones. Por este<br />
motivo se ha preferido mostrar la solución por separado, <strong>en</strong> lugar de<br />
integrarlo <strong>en</strong> la explicación anterior del proceso de registro.<br />
97
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
La ext<strong>en</strong>sión pres<strong>en</strong>tada se basa, ligeram<strong>en</strong>te, <strong>en</strong> las ideas<br />
propuestas <strong>en</strong> [PER02], y se muestra <strong>en</strong> la figura 3.15. El campo t<strong>ip</strong>o<br />
estaría definido por la IANA, al igual que el campo ‘Subt<strong>ip</strong>o’ que se utiliza<br />
para difer<strong>en</strong>ciar las difer<strong>en</strong>tes ext<strong>en</strong>siones que se utilizan para el<br />
establecimi<strong>en</strong>to de asociaciones seguras (figura 3.10).<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o Subt<strong>ip</strong>o Longitud<br />
Id<strong>en</strong>tificador de Algoritmo<br />
Tiempo de Vida<br />
SPI a emplear<br />
SPI resultante<br />
Material para clave.................<br />
Figura 3.15. Ext<strong>en</strong>sión para el <strong>en</strong>vío de información para la g<strong>en</strong>eración de<br />
asociaciones seguras.<br />
El ‘SPI (Security Parameters Index) resultante’ es el SPI de la<br />
asociación <strong>en</strong>tre el nodo móvil y la Estación Base que se crea como<br />
resultado del proceso. De igual manera el Id<strong>en</strong>tificador de algoritmo será el<br />
algoritmo que se empleará <strong>en</strong> la asociación resultante.<br />
Sin embargo, el campo ‘SPI a emplear’ varía <strong>en</strong> función de los<br />
elem<strong>en</strong>tos <strong>en</strong>tre los que se intercambia el material.<br />
• En la ext<strong>en</strong>sión que se utiliza para <strong>en</strong>viar el material hasta el nodo<br />
móvil (ver figura 3.10), el ‘SPI a emplear’ sería el HA SPI, que indica<br />
el SPI de la asociación de seguridad que manti<strong>en</strong>e con el Home<br />
Ag<strong>en</strong>t, y que el que el nodo móvil debe usar para determinar el<br />
algoritmo con el que establecer la asociación con la Estación Base.<br />
• En la ext<strong>en</strong>sión utilizada para <strong>en</strong>viar el material desde el Home<br />
Ag<strong>en</strong>t hasta el MMA, este valor indica el SPI de la asociación de<br />
seguridad que manti<strong>en</strong><strong>en</strong> Home Ag<strong>en</strong>t y MMA, y que el que al MMA<br />
debe usar para determinar el algoritmo con el que obt<strong>en</strong>er el<br />
material que se transmite.<br />
98
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
• Finalm<strong>en</strong>te, <strong>en</strong> la ext<strong>en</strong>sión utilizada para <strong>en</strong>viar el material desde<br />
el MMA hasta la estación base, este valor indica el SPI de la<br />
asociación de seguridad que manti<strong>en</strong><strong>en</strong> el MMA con las estaciones,<br />
y que se debe usar para determinar el algoritmo con el que obt<strong>en</strong>er<br />
el material para establecer la asociación de seguridad con el nodo.<br />
3.5.3 M<strong>en</strong>sajes para el registro Intra-Dominio<br />
Como se estudió <strong>en</strong> el punto 3.3.3, cuando un nodo detecta que se<br />
ha producido un cambio de subred d<strong>en</strong>tro de un dominio <strong>en</strong>vía un nuevo<br />
m<strong>en</strong>saje que se ha d<strong>en</strong>ominado ‘Intra-Domain Registration Request’. Este<br />
m<strong>en</strong>saje sustituye al tradicional m<strong>en</strong>saje de registro con el Home Ag<strong>en</strong>t<br />
que no debe ser utilizado.<br />
En la figura 3.16 se observa el formato propuesto para este<br />
m<strong>en</strong>saje. Los primeros 32 bits (la primera fila de la figura) son idénticos al<br />
m<strong>en</strong>saje ‘Registration Request’ de [RFC 3344]. El valor del campo t<strong>ip</strong>o debe<br />
ser asignado por la IANA. Las tres direcciones que aparec<strong>en</strong> <strong>en</strong> los<br />
sigui<strong>en</strong>tes campos son las necesarias para crear una tabla con la misma<br />
información que la explicada <strong>en</strong> el punto 3.3.2. Utilizando la dirección<br />
Multicast, la estación Base se conectará al árbol correspondi<strong>en</strong>te. Por<br />
último el campo ‘Id<strong>en</strong>tificador’ se utiliza como mecanismo de seguridad<br />
para asociar peticiones de registro con respuestas. Su uso se detalla <strong>en</strong><br />
[RFC 3344].<br />
El m<strong>en</strong>saje ‘Intra-Domain Registration Request’ debe ir finalizado por<br />
una ext<strong>en</strong>sión de aut<strong>en</strong>tificación MN-FA también definida <strong>en</strong> el estándar<br />
original.<br />
99
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o S B D M G r T x Tiempo de vida<br />
Home Address<br />
Care-of Address<br />
Dirección Multicast<br />
Id<strong>en</strong>tificador<br />
Ext<strong>en</strong>siones................<br />
Figura 3.16 Formato del m<strong>en</strong>saje ‘Intra-Domain Registration Request’.<br />
Una vez la Estación Base se ha conectado al árbol <strong>multicast</strong> se lo<br />
comunica al nodo móvil por medio de un m<strong>en</strong>saje ‘Intra-Domain<br />
Registration Reply’. El m<strong>en</strong>saje se muestra <strong>en</strong> la figura 3.17. El campo<br />
‘T<strong>ip</strong>o’ tomará el valor asignado por la IANA a este t<strong>ip</strong>o de m<strong>en</strong>saje. El<br />
campo ‘Código’ informará del éxito o error <strong>en</strong> la conexión de la Estación<br />
Base al árbol <strong>multicast</strong>. Como <strong>en</strong> el caso anterior, este m<strong>en</strong>saje debe ir<br />
acabado por una ext<strong>en</strong>sión de seguridad MN-FA definida <strong>en</strong> [RFC 3344].<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o Código Tiempo de vida<br />
Home Address<br />
Multicast Address<br />
Id<strong>en</strong>tificador<br />
Ext<strong>en</strong>siones................<br />
Figura 3.17 Formato del m<strong>en</strong>saje ‘Intra-Domain Registration Reply’.<br />
100
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
3.5.4 Otros m<strong>en</strong>sajes no detallados<br />
En el punto 3.3.5 se describió como los difer<strong>en</strong>tes Ag<strong>en</strong>tes de<br />
Movilidad Multicast (MMA) difundían m<strong>en</strong>sajes a las Estaciones Base<br />
indicando su disponibilidad. Exist<strong>en</strong> múlt<strong>ip</strong>les posibilidades con respecto<br />
al formato de los mismos, que dep<strong>en</strong>derá del t<strong>ip</strong>o de información que las<br />
estaciones base emple<strong>en</strong> para la selección, <strong>en</strong> un instante de tiempo dado,<br />
de un MMA u otro. Se sugiere que los m<strong>en</strong>sajes estén <strong>en</strong>capsulados <strong>en</strong><br />
UDP y transmitidos a la dirección <strong>multicast</strong> 224.0.0.11 (‘Todos los Ag<strong>en</strong>tes<br />
de Movilidad’).<br />
Durante un handover Intra-Dominio, la Estación Base que recibe el<br />
m<strong>en</strong>saje ‘Intra-Domain Registration Request’ debe realizar una conexión al<br />
árbol <strong>multicast</strong> correspondi<strong>en</strong>te. El formato de los m<strong>en</strong>sajes que se<br />
emplean, típicam<strong>en</strong>te m<strong>en</strong>sajes ‘Join’ y ‘Ack Join’, dep<strong>en</strong>d<strong>en</strong> del protocolo<br />
de <strong>en</strong>rutami<strong>en</strong>to <strong>multicast</strong> utilizado. Este aspecto se describe con mayor<br />
detalle <strong>en</strong> el punto 3.6.<br />
Por último, <strong>en</strong> el punto 3.4.2 se estudio el concepto de seguridad <strong>en</strong><br />
el sistema de micro-<strong>movilidad</strong> propuesto. Con el fin poder obt<strong>en</strong>er una<br />
asociación segura <strong>en</strong>tre los nodos móviles y las estaciones base se relató<br />
una simplificación, <strong>en</strong> la que el Home Ag<strong>en</strong>t realizaba la tarea de<br />
suministrar el material necesario. En el ejemplo propuesto el MMA obt<strong>en</strong>ía<br />
dicha información y debía hacérsela llegar a todas las estaciones base del<br />
dominio. El mecanismo particular por el que esto se realiza no se describe.<br />
Típicam<strong>en</strong>te se realizaría por medio de m<strong>en</strong>sajes <strong>multicast</strong> donde se<br />
transmitiría la dirección del nodo móvil, el material necesario para poder<br />
formar la asociación segura (por ejemplo la ext<strong>en</strong>sión estudiada <strong>en</strong> el<br />
punto 3.5.2), y una aut<strong>en</strong>tificación FA-FA para aut<strong>en</strong>tificar el m<strong>en</strong>saje. Sin<br />
embargo los trabajos que se están desarrollando <strong>en</strong> este mom<strong>en</strong>to, y que<br />
se basan <strong>en</strong> la utilización de servidores AAA, dejan estos aspectos al<br />
marg<strong>en</strong>, razonando que dep<strong>en</strong>d<strong>en</strong> de la tecnología particular empleada.<br />
101
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
3.6 CONSIDERACIONES SOBRE EL USO DE<br />
TRANSMISIÓN MULTICAST EN EL SISTEMA DE<br />
MICROMOVILIDAD<br />
3.6.1 Introducción a la transmisión <strong>multicast</strong><br />
El protocolo de micro-<strong>movilidad</strong> propuesto está <strong>basado</strong> <strong>en</strong> la<br />
utilización de la tecnología <strong>multicast</strong> <strong>en</strong> redes IP. Este paradigma de<br />
comunicación apareció a princ<strong>ip</strong>ios de los años 90 a partir de los trabajos<br />
realizados por Steph<strong>en</strong> Deering [DEE90], definiéndose las ext<strong>en</strong>siones al<br />
protocolo IP <strong>en</strong> [RFC 1112].<br />
La transmisión <strong>multicast</strong> permite transmitir datagramas desde una<br />
o más fu<strong>en</strong>tes a un grupo de receptores que partic<strong>ip</strong>an <strong>en</strong> la sesión<br />
<strong>multicast</strong> utilizando un único flujo de datos, <strong>en</strong> vez de t<strong>en</strong>er que re<strong>en</strong>viar<br />
la misma información de forma indep<strong>en</strong>di<strong>en</strong>te a cada receptor. Esto se<br />
traduce <strong>en</strong> una reducción del ancho de banda total, utilizado sobre todo <strong>en</strong><br />
las nuevas aplicaciones multimedia <strong>en</strong> las que el volum<strong>en</strong> de la<br />
información transmitida es considerable.<br />
Se ha considerado que la tecnología <strong>multicast</strong> es una solución<br />
idónea para <strong>en</strong>tornos de micro-<strong>movilidad</strong>. Algunos de los motivos más<br />
destacables son los sigui<strong>en</strong>tes:<br />
• Reducción de ancho de banda. La trasmisión <strong>multicast</strong> permite<br />
realizar una utilización efici<strong>en</strong>te del ancho de banda al realizar una<br />
única transmisión de los datos mi<strong>en</strong>tras estos sigu<strong>en</strong> una ruta común.<br />
Esto es importante desde el punto de vista de la escalabilidad. Otras<br />
soluciones mucho más s<strong>en</strong>cillas, como realizar una inundación de los<br />
datos por el dominio, no son abordables a gran escala.<br />
• Velocidad <strong>en</strong> el proceso de handover. El tiempo que dura el proceso<br />
de handover es un aspecto fundam<strong>en</strong>tal <strong>en</strong> cualquier sistema de<br />
<strong>movilidad</strong>, si<strong>en</strong>do incluso el princ<strong>ip</strong>al motivo que ha llevado al<br />
desarrollo de propuestas de micro-<strong>movilidad</strong>. La utilización de la<br />
102
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
trasmisión <strong>multicast</strong> ofrece unos tiempos de handover m<strong>en</strong>ores que<br />
otras soluciones propuestas. Por ejemplo, soluciones como Mobile IP<br />
con Registro Regional implican que <strong>en</strong> cada handover se obt<strong>en</strong>ga una<br />
nueva dirección temporal y que se le notifique al GFA. En nuestro caso<br />
el proceso de handover se resume <strong>en</strong> conectarnos al árbol <strong>multicast</strong> del<br />
grupo utilizado. Adicionalm<strong>en</strong>te, la utilización de la tecnología<br />
<strong>multicast</strong> ofrecerá la posibilidad de realizar handover sin pérdida de<br />
información de una manera simple [LEO98].<br />
• Tecnología desarrollada. La tecnología <strong>multicast</strong> ti<strong>en</strong>e una<br />
antigüedad de más de 10 años, y ha sido sufici<strong>en</strong>tem<strong>en</strong>te estudiada.<br />
En la actualidad exist<strong>en</strong> numerosos productos <strong>en</strong> el mercado que<br />
ofrec<strong>en</strong> capacidades <strong>multicast</strong>, por lo que es posible implem<strong>en</strong>tar<br />
dominios que soport<strong>en</strong> el sistema de micro-<strong>movilidad</strong> propuesto más<br />
fácilm<strong>en</strong>te. La mayoría de los restantes sistemas de micro-<strong>movilidad</strong><br />
(Cellular IP, Hawaii o MMP) utilizan protocolos de <strong>en</strong>caminami<strong>en</strong>to<br />
propietarios <strong>basado</strong>s <strong>en</strong> <strong>en</strong>caminami<strong>en</strong>to por Host. Los routers<br />
actuales no están diseñados para este propósito, y sería necesario la<br />
actualización de los mismos.<br />
3.6.2 Selección de la tecnología <strong>multicast</strong> a emplear<br />
La tecnología <strong>multicast</strong> se ha desarrollado ampliam<strong>en</strong>te <strong>en</strong> los<br />
últimos años, existi<strong>en</strong>do <strong>en</strong> la actualidad una gran variedad de algoritmos<br />
y protocolos de <strong>en</strong>rutami<strong>en</strong>to disponibles.<br />
Para que los usuarios puedan conectarse al árbol <strong>multicast</strong> se ha<br />
desarrollado el protocolo IGMP (Internet Group Managem<strong>en</strong>t Protocol). La<br />
primera implem<strong>en</strong>tación fue publicada a mediados de 1989 [RFC1112].<br />
Éste fue reemplazado <strong>en</strong> 1997 por la versión 2 (IGMPv2) [RFC 2236], y <strong>en</strong><br />
la actualidad se ha pres<strong>en</strong>tado una tercera versión [RFC 3376]. El<br />
protocolo permite a un host informar a la red que es miembro de un<br />
determinado grupo <strong>multicast</strong>. Así, un router designado de cada subred<br />
t<strong>en</strong>drá la tarea conectarse al árbol <strong>multicast</strong> correspondi<strong>en</strong>te, utilizando<br />
103
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
para ello un protocolo de <strong>en</strong>caminami<strong>en</strong>to <strong>multicast</strong>. Como se estudiará a<br />
continuación, el nodo móvil utilizará las características del protocolo IGMP<br />
para comunicarse con la Estación Base indicándole que se debe conectar<br />
al grupo <strong>multicast</strong> asignado a dicho nodo.<br />
Tradicionalm<strong>en</strong>te los protocolos de <strong>en</strong>caminami<strong>en</strong>to <strong>multicast</strong> se<br />
han dividido <strong>en</strong> protocolos de modo d<strong>en</strong>so y protocolos de modo disperso.<br />
Los protocolos de modo d<strong>en</strong>so asum<strong>en</strong> que los miembros del grupo<br />
<strong>multicast</strong> están distribuidos de forma d<strong>en</strong>sa <strong>en</strong> la red, con muchas<br />
subredes cont<strong>en</strong>i<strong>en</strong>do usuarios. Estos protocolos suel<strong>en</strong> utilizar algoritmos<br />
de “Árbol Basados <strong>en</strong> Fu<strong>en</strong>te” (SRT), que forman un árbol de<br />
<strong>en</strong>caminami<strong>en</strong>to por cada fu<strong>en</strong>te y que utilizan mecanismos más o m<strong>en</strong>os<br />
elaborados de inundación para propagar la información hasta todos los<br />
routers. Ejemplos de estos protocolos serían DVMRP [RFC 1075], MOSPF<br />
[RFC 1584] o PIM-DM.<br />
Por su parte los protocolos de modo disperso están p<strong>en</strong>sados para<br />
grupos <strong>multicast</strong> <strong>en</strong> los que los usuarios están distribuidos por la red. Se<br />
basan <strong>en</strong> algoritmos de árbol compartido (Shared Tree, ST) [RFC 2201] <strong>en</strong><br />
los que existe un router c<strong>en</strong>tral que recibe los paquetes del grupo y los<br />
re<strong>en</strong>vía hacia todo el árbol. Aquí los usuarios ti<strong>en</strong><strong>en</strong> que explícitam<strong>en</strong>te<br />
unirse al grupo que dese<strong>en</strong> para com<strong>en</strong>zar a recibir los datos. Ejemplos de<br />
estos protocolos son CBT [RFC 2189] y PIM-SM [RFC 2362].<br />
En el desarrollo del sistema de micro-<strong>movilidad</strong> se ha propuesto la<br />
utilización de un protocolo <strong>basado</strong> <strong>en</strong> árbol compartido. Para usuarios<br />
dispersos (y <strong>en</strong> nuestro caso esto llega al extremo al existir, normalm<strong>en</strong>te,<br />
solam<strong>en</strong>te uno) la inundación no está justificada, puesto que la<br />
probabilidad de que los paquetes sean <strong>en</strong>tregados a redes donde no<br />
exist<strong>en</strong> miembros del grupo es muy elevada. Además, los protocolos de<br />
modo d<strong>en</strong>so manti<strong>en</strong><strong>en</strong> información de los grupos <strong>multicast</strong> exist<strong>en</strong>tes <strong>en</strong><br />
todos los routers de la red, lo que se traduce <strong>en</strong> un consumo de recursos<br />
no justificado que puede afectar a la escalabilidad del sistema.<br />
Los protocolos PIM-SM y CBT ti<strong>en</strong><strong>en</strong> muchas cosas <strong>en</strong> común.<br />
Ambos están <strong>basado</strong>s <strong>en</strong> la exist<strong>en</strong>cia de un árbol compartido que se<br />
104
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
realiza de una manera indep<strong>en</strong>di<strong>en</strong>te del protocolo unicast exist<strong>en</strong>te.<br />
Además compart<strong>en</strong> muchos mecanismos de procedimi<strong>en</strong>to, como el modo<br />
<strong>en</strong> que se recorta el árbol compartido o las soluciones empleadas para<br />
seleccionar cual es el núcleo del árbol.<br />
Sin embargo también exist<strong>en</strong> difer<strong>en</strong>cias significativas. PIM-SM<br />
forma un árbol compartido unidireccional, por el que los datos se<br />
transmit<strong>en</strong> desde el núcleo (d<strong>en</strong>ominado 'R<strong>en</strong>dezvous Point’ RP) hasta los<br />
routers extremos. Las fu<strong>en</strong>tes <strong>en</strong>vían los datos hacia el RP mediante<br />
m<strong>en</strong>sajes ‘PIM-Register’ y, posteriorm<strong>en</strong>te, utilizando una ruta <strong>multicast</strong><br />
SPT (Shorted Path Tree). Además, los routers que dan conexión a los hosts<br />
adscritos al árbol <strong>multicast</strong> pued<strong>en</strong> crear una conexión con una fu<strong>en</strong>te de<br />
manera que ésta forma la raíz de un SPT. Así la transmisión se realiza<br />
ahora evitando pasar por el RP, reduci<strong>en</strong>do la lat<strong>en</strong>cia y la posible<br />
congestión del RP.<br />
En el protocolo CBT esto no es posible. CBT utiliza un árbol<br />
compartido bidireccional por el que se transmit<strong>en</strong> y recib<strong>en</strong> los datos. Si la<br />
fu<strong>en</strong>te no es un miembro del grupo <strong>multicast</strong> no está conectada al árbol y<br />
debe <strong>en</strong>viar los datos hasta el núcleo utilizando <strong>en</strong>capsulación IP (<strong>en</strong> la<br />
versión CBTv2), no si<strong>en</strong>do posible la optimización de rutas utilizando SPT<br />
con raíz <strong>en</strong> las fu<strong>en</strong>tes.<br />
La princ<strong>ip</strong>al difer<strong>en</strong>cia afecta al mecanismo por el que las fu<strong>en</strong>tes<br />
del grupo transmit<strong>en</strong> los datos. Como se estudia a continuación nuestro<br />
sistema de micro-<strong>movilidad</strong> utiliza unas capacidades simplificadas, donde<br />
estos aspectos no son relevantes.<br />
El protocolo CBT lleva mucho tiempo <strong>en</strong> desarrollo. La primera<br />
versión CBTv1 fue modificada por una segunda, CBTv2 [RFC 2189], con la<br />
que no es compatible. En la actualidad se está trabajando con una tercera<br />
versión [BALL98] que de nuevo será incompatible con las anteriores. Esto<br />
puede explicar la poca implantación que ha t<strong>en</strong>ido el protocolo hasta el<br />
mom<strong>en</strong>to. Por contra, el protocolo PIM-SM ha t<strong>en</strong>ido mucha aceptación <strong>en</strong><br />
la industria y multitud de fabricantes como, Sprint o Cisco, ofrec<strong>en</strong><br />
equ<strong>ip</strong>os que lo implem<strong>en</strong>tan.<br />
105
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
Podemos resumir el protocolo PIM-SM muy brevem<strong>en</strong>te <strong>en</strong> los<br />
sigui<strong>en</strong>tes puntos:<br />
1. Es necesario definir un núcleo (también llamado ‘R<strong>en</strong>dezvous Point’ RP)<br />
para cada grupo <strong>multicast</strong>.<br />
2. Los routers de la red que desean incorporarse a un grupo deb<strong>en</strong><br />
descubrir que router es su nodo RP. Para realizar esto se utiliza un<br />
protocolo de iniciación (Bootstrap Protocol). Este protocolo no estaba<br />
definido <strong>en</strong> la especificación 1 del protocolo (PIM-SM v1, [RFC 2117]) y<br />
cada fabricante desarrollaba el suyo. La versión 2 incluye la<br />
especificación del protocolo de iniciación. Además de para <strong>en</strong>contrar el<br />
nodo RP, el protocolo se utiliza como mecanismo de seguridad,<br />
incluy<strong>en</strong>do mecanismos para la selección de un RP alternativo <strong>en</strong> caso<br />
de que el primario fallase. Adicionalm<strong>en</strong>te algunas empresas como<br />
Cisco ti<strong>en</strong><strong>en</strong> sus propios mecanismos de descubrimi<strong>en</strong>to [WILL00].<br />
3. Los receptores <strong>en</strong>vían m<strong>en</strong>sajes explícitos de incorporación (‘Join<br />
Messages’) hacia el RP. Estos m<strong>en</strong>sajes sigu<strong>en</strong> un direccionami<strong>en</strong>to<br />
desde los receptores hacia el núcleo, por lo que, de manera similar a<br />
otros protocolos <strong>multicast</strong>, se crea un árbol <strong>multicast</strong> ‘Reverse Shortest<br />
Path Tree’ (árbol por el camino de vuelta más corto) con raíz <strong>en</strong> el RP.<br />
4. Cada fu<strong>en</strong>te <strong>en</strong>vía los paquetes <strong>multicast</strong>, <strong>en</strong>capsulados <strong>en</strong> paquetes<br />
unicast (m<strong>en</strong>sajes ‘PIM-Register’), hacia el nodo RP. El nodo RP<br />
des<strong>en</strong>capsula los paquetes <strong>multicast</strong> y los <strong>en</strong>vía a través del árbol<br />
compartido. Además <strong>en</strong>viará un m<strong>en</strong>saje de incorporación hacia la<br />
fu<strong>en</strong>te. Esto hará que los routers <strong>en</strong>tre la fu<strong>en</strong>te y el nodo RP se<br />
establezcan <strong>en</strong> modo de direccionami<strong>en</strong>to <strong>multicast</strong> y el nodo RP pueda<br />
a partir de <strong>en</strong>tonces recibir los datos de la fu<strong>en</strong>te como tráfico<br />
<strong>multicast</strong> evitando la <strong>en</strong>capsulación.<br />
En la actualidad se está trabajando <strong>en</strong> una variación de la<br />
tecnología <strong>multicast</strong> que se d<strong>en</strong>omina Multicast con Fu<strong>en</strong>te Específica<br />
(Source-Specific Multicast SSM) [BHA03],[HOL03], ambos catalogados como<br />
‘Work in Progress’. Aquí se sustituye la idea tradicional de grupo <strong>multicast</strong>,<br />
caracterizado por una dirección G [RFC 1112], por el concepto de ‘canal’<br />
que está definido por el par (S,G), donde G es una dirección <strong>multicast</strong>, y S<br />
106
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
la dirección del host fu<strong>en</strong>te. Para poder trabajar simultáneam<strong>en</strong>te con la<br />
tecnología <strong>multicast</strong> exist<strong>en</strong>te hasta el mom<strong>en</strong>to [IANA] ha reservado el<br />
espacio de direcciones 232/8 (232.0.0.0 hasta 232.255.255.255) como<br />
direcciones IPv4 destino G de la tecnología SSM.<br />
En SSM las estaciones se suscrib<strong>en</strong> a canales (S,G) por medio del<br />
protocolo IGMPv3 [RFC3376], o bi<strong>en</strong> utilizando el protocolo ‘Multicast<br />
List<strong>en</strong>er Discovery, MLDv2 [VID03] si estamos trabajando <strong>en</strong> un <strong>en</strong>torno<br />
IPv6. En contraste al servicio ASM (Any-Source Multicast) definido <strong>en</strong> [RFC<br />
1112], SSM ofrece únicam<strong>en</strong>te un servicio ‘uno-a-varios’, de manera que<br />
las estaciones subscritas al canal sólo recib<strong>en</strong> paquetes transmitidos por<br />
la fu<strong>en</strong>te S hacia la dirección G.<br />
Aunque actualm<strong>en</strong>te no exist<strong>en</strong> protocolos específicos SSM, se<br />
plantea como solución una simplificación del protocolo PIM-SM, como se<br />
describe <strong>en</strong> [FEN03].<br />
El planteami<strong>en</strong>to SSM se ajusta perfectam<strong>en</strong>te a los requerimi<strong>en</strong>tos<br />
de <strong>multicast</strong> del sistema de micro-<strong>movilidad</strong> propuesto. Sin embargo, dado<br />
que no exist<strong>en</strong> actualm<strong>en</strong>te protocolos SSM específicos y que se está<br />
trabajando <strong>en</strong> simplificaciones del protocolo PIM-SM, <strong>en</strong> este trabajo nos<br />
vamos a referir a este último protocolo.<br />
A pesar de esto, y como se verá a continuación, los requerimi<strong>en</strong>tos<br />
<strong>multicast</strong> necesarios por el sistema de micro-<strong>movilidad</strong> son inferiores a las<br />
capacidades que ofrece el protocolo PIM-SM. Así cuando SSM esté más<br />
desarrollada podrá integrarse perfectam<strong>en</strong>te <strong>en</strong> el sistema de micro<strong>movilidad</strong><br />
pres<strong>en</strong>tado.<br />
Por último indicar que el sistema de micro-<strong>movilidad</strong> es totalm<strong>en</strong>te<br />
compatible con cualquier algoritmo de <strong>en</strong>rutami<strong>en</strong>to <strong>multicast</strong> y de<br />
cualquier protocolo concreto, incluidos los protocolos de modo d<strong>en</strong>so como<br />
DVMRP, MOSPF o PIM-DM. La elección de uno <strong>en</strong> concreto se realiza<br />
simplem<strong>en</strong>te con el fin de profundizar <strong>en</strong> el conocimi<strong>en</strong>to de como los<br />
mecanismos de <strong>movilidad</strong> interactúan con los de <strong>en</strong>rutami<strong>en</strong>to <strong>multicast</strong>.<br />
107
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
3.6.3 Incorporación del protocolo PIM-SM / SSM al sistema de<br />
micro-<strong>movilidad</strong><br />
Debido a las características del sistema de micro-<strong>movilidad</strong><br />
diseñado, el protocolo de <strong>en</strong>rutami<strong>en</strong>to PIM-SM / SSM puede incorporarse<br />
<strong>en</strong> nuestro sistema de una manera s<strong>en</strong>cilla. El proceso comi<strong>en</strong>za cuando<br />
una Estación Base recibe un m<strong>en</strong>saje de registro del nodo móvil. Si se<br />
trata de un registro intra-dominio (m<strong>en</strong>saje 'Intra-Domain Registration<br />
Request') la BS actúa como si hubiera recibido un m<strong>en</strong>saje 'IGMP<br />
Membersh<strong>ip</strong> Report'. Esto no es ningún inconv<strong>en</strong>i<strong>en</strong>te pues estos m<strong>en</strong>sajes<br />
sólo indican el grupo <strong>multicast</strong> al que se desea conectar, y esta<br />
información también es aportada por el m<strong>en</strong>saje de registro. En el caso de<br />
que se trate de un m<strong>en</strong>saje de registro por <strong>en</strong>trar <strong>en</strong> un nuevo dominio<br />
(m<strong>en</strong>saje 'Registration Request') se debería esperar hasta recibir el m<strong>en</strong>saje<br />
de respuesta vía MMA. Este m<strong>en</strong>saje 'Registration Reply' incorpora la<br />
ext<strong>en</strong>sión MAE (Multicast Address Ext<strong>en</strong>sión), que nos indica la dirección<br />
<strong>multicast</strong> asignada al nodo. Una vez la BS obti<strong>en</strong>e la dirección el proceso<br />
es el mismo que <strong>en</strong> el registro intra-dominio, y se supone que se ha<br />
recibido un m<strong>en</strong>saje IGMP Membersh<strong>ip</strong> Report’.<br />
La eliminación de la necesidad de que los nodos móviles <strong>en</strong>ví<strong>en</strong><br />
m<strong>en</strong>sajes 'IGMP Membersh<strong>ip</strong> Report' no significa que el nodo pueda<br />
des<strong>en</strong>t<strong>en</strong>derse completam<strong>en</strong>te de que está utilizando una dirección<br />
<strong>multicast</strong>. El protocolo IGMPv1 especifica que los routers deb<strong>en</strong> <strong>en</strong>viar<br />
periódicam<strong>en</strong>te m<strong>en</strong>sajes 'IGMP Query' para actualizar la tablas y<br />
asegurarse que todavía exist<strong>en</strong> hosts pert<strong>en</strong>eci<strong>en</strong>tes al grupo <strong>multicast</strong>.<br />
Esto obliga a los nodos móviles a contestar a dichos m<strong>en</strong>sajes <strong>en</strong> el caso<br />
de que fuera necesario. Sin embargo, el protocolo Mobile IP ti<strong>en</strong>e un<br />
proceso similar para mant<strong>en</strong>er las direcciones Care-of. Es decir, cada<br />
cierto tiempo el nodo móvil debe <strong>en</strong>viar un nuevo m<strong>en</strong>saje de registro al<br />
Home Ag<strong>en</strong>t para indicar que la dirección sigue si<strong>en</strong>do válida. Para la<br />
Estación Base (desde el punto de vista de ser un router <strong>multicast</strong>) ese<br />
m<strong>en</strong>saje de registro significa que existe miembros del grupo <strong>multicast</strong>, por<br />
lo que le permitiría actualizar el temporizador pudi<strong>en</strong>do evitar, o al m<strong>en</strong>os<br />
minimizar, el <strong>en</strong>vío de m<strong>en</strong>sajes 'IGMP Query'.<br />
108
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
Por último, <strong>en</strong> el capítulo 6 de esta Tesis, donde se trata con mayor<br />
profundidad el tema del handover, se estudiará el posible uso de m<strong>en</strong>sajes<br />
'IGMP Leave Group' que se incluyeron a partir de la versión 2 del protocolo<br />
[RFC 2236].<br />
Una vez la estación base ha interpretado la recepción de un<br />
m<strong>en</strong>saje IGMP de incorporación a un grupo <strong>multicast</strong> debe realizar una<br />
conexión al árbol compartido de dicho grupo. En nuestro sistema, el router<br />
que actúa de ‘R<strong>en</strong>dezvous Point’ será el Ag<strong>en</strong>te de Movilidad Multicast<br />
(MMA). Esta el la solución más s<strong>en</strong>cilla, pues es este ag<strong>en</strong>te el que debe<br />
realizar la <strong>en</strong>capsulación de los paquetes <strong>multicast</strong>. Si propusiéramos otra<br />
opción el MMA se comportaría como una fu<strong>en</strong>te <strong>multicast</strong> y, sigui<strong>en</strong>do el<br />
protocolo, debería volver a <strong>en</strong>capsular los paquetes para hacerlos llegar el<br />
RP elegido. Evid<strong>en</strong>tem<strong>en</strong>te esta última opción consume tiempo y recursos<br />
innecesariam<strong>en</strong>te por lo que no es considerada. La tecnología SSM (Source-<br />
Specific Multicast) propone una solución idéntica para g<strong>en</strong>erar el árbol,<br />
pues al trabajar con una sola fu<strong>en</strong>te (<strong>en</strong> nuestro caso sería el MMA), ésta<br />
actúa como raíz del árbol y se puede prescindir del RP.<br />
Llegados a este punto, y sigui<strong>en</strong>do el protocolo PIM-SM, la Estación<br />
Base <strong>en</strong>viará un m<strong>en</strong>saje 'PIM Join' hacia el RP (el mecanismo por el que<br />
los routers conoc<strong>en</strong> cual es RP asignado a un grupo <strong>multicast</strong> se com<strong>en</strong>ta<br />
posteriorm<strong>en</strong>te). En el caso de que se estuviera produci<strong>en</strong>do un registro <strong>en</strong><br />
un nuevo dominio, el árbol no existe todavía y, por tanto, el m<strong>en</strong>saje<br />
alcanzará hasta el MMA (actuando como RP) creando una <strong>en</strong>trada <strong>en</strong> las<br />
tablas <strong>multicast</strong> <strong>en</strong> todos los routers que atraviese. Si estamos <strong>en</strong> un<br />
registro intra-dominio es de esperar que el m<strong>en</strong>saje alcance rápidam<strong>en</strong>te<br />
una de las ramas del árbol compartido, lográndose un handover<br />
s<strong>en</strong>siblem<strong>en</strong>te más rápido que el definido <strong>en</strong> cualquier otra propuesta.<br />
Hay que indicar que debido a la forma <strong>en</strong> que utilizamos la<br />
transmisión <strong>multicast</strong> d<strong>en</strong>tro del sistema de micro-<strong>movilidad</strong>, donde la<br />
única fu<strong>en</strong>te al grupo <strong>multicast</strong> es el propio RP, el árbol compartido creado<br />
es un árbol SPT (Shorted Path Tree). Esto significa que no será necesario la<br />
utilización de los mecanismos de registro de la fu<strong>en</strong>te o de conmutación<br />
<strong>en</strong>tre árbol compartido y SPT definidos <strong>en</strong> el protocolo PIM-SM [RFC 2362].<br />
109
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
Como se ha com<strong>en</strong>tado, la propuesta SSM se corresponde con esta<br />
simplificación.<br />
Como se estudio <strong>en</strong> el punto 3.3.3 <strong>en</strong> caso de tratarse de un<br />
handover intra-dominio, y como respuesta al m<strong>en</strong>saje ’Intra-Domain<br />
Registration Request', la nueva Estación Base <strong>en</strong>viaba un m<strong>en</strong>saje 'Intra-<br />
Domain Registration Reply', confirmando que el proceso había finalizado.<br />
Este m<strong>en</strong>saje se transmitía una vez la Estación Base recibía respuesta a<br />
su m<strong>en</strong>saje de incorporación al árbol <strong>multicast</strong>, por ejemplo por medio de<br />
un 'Multicast Ack Join' (figura 3.5). A difer<strong>en</strong>cia de otros protocolos como<br />
CBT, el protocolo PIM-SM no implem<strong>en</strong>ta esta clase de m<strong>en</strong>sajes. Sin<br />
embargo el problema no es excesivam<strong>en</strong>te complejo de resolver, puesto que<br />
la mínima información necesaria para poder <strong>en</strong>viar este m<strong>en</strong>saje se<br />
<strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> las tablas de <strong>en</strong>rutami<strong>en</strong>to <strong>multicast</strong> PIM.<br />
Selección del R<strong>en</strong>dezvous Point de un grupo <strong>multicast</strong>.<br />
Una de las consecu<strong>en</strong>cias que produce la elección del MMA como<br />
R<strong>en</strong>dezvous Point es la manera <strong>en</strong> que los routers del dominio consigu<strong>en</strong><br />
conocer cual es el RP para un grupo <strong>multicast</strong>. El protocolo PIM-SMv2<br />
definía un mecanismo de iniciación para designar este punto. Sin embargo<br />
ahora el RP se corresponde con el MMA que le fue asignado al nodo móvil<br />
cuando se registro <strong>en</strong> el dominio, que a su vez dep<strong>en</strong>día de los m<strong>en</strong>sajes<br />
‘Mobility Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ que <strong>en</strong>viaba la Estación Base <strong>en</strong> la que el<br />
nodo móvil se conectaba al dominio. La estación Base (recordemos que <strong>en</strong><br />
el fondo es un router modificado que soporta también <strong>multicast</strong>) no va a<br />
t<strong>en</strong>er problemas para conocer cual es el RP, pues v<strong>en</strong>drá indicado <strong>en</strong> el<br />
m<strong>en</strong>saje de registro, indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de que se trate de un nuevo<br />
registro <strong>en</strong> el dominio (m<strong>en</strong>saje ‘Registration Request’, punto 3.5.2), o bi<strong>en</strong><br />
de un registro intra-dominio (m<strong>en</strong>saje ‘Intra-Domain Registration Request’).<br />
Sin embargo los distintos routers que compon<strong>en</strong> el dominio no<br />
sab<strong>en</strong>, <strong>en</strong> princ<strong>ip</strong>io, cual de los difer<strong>en</strong>tes MMA exist<strong>en</strong>tes <strong>en</strong> el dominio<br />
actúa como RP para un grupo <strong>multicast</strong> <strong>en</strong> concreto. Se han p<strong>en</strong>sado<br />
distintas soluciones para esto.<br />
110
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
La primera consiste <strong>en</strong> utilizar el mecanismo de inicialización<br />
propuesto <strong>en</strong> el protocolo. En este caso deberíamos habilitar un dispositivo<br />
d<strong>en</strong>ominado Router de Inicialización (Boot Strap Router BSR). Los RP<br />
candidatos, <strong>en</strong> nuestro caso los difer<strong>en</strong>tes MMAs, <strong>en</strong>viarían hacia el BSR<br />
m<strong>en</strong>sajes definidos <strong>en</strong> [RFC 2362] como ‘Candidate-RP-Advertisem<strong>en</strong>t’,<br />
indicando que son un candidato a RP para la dirección <strong>multicast</strong> que<br />
previam<strong>en</strong>te ha asignado a un nodo móvil. El BSR <strong>en</strong>viaría,<br />
periódicam<strong>en</strong>te, el RP propuesto para cada grupo hacia todos los routers<br />
del dominio (utilizando la dirección <strong>multicast</strong> ‘All-PIM-Routers’ definida <strong>en</strong><br />
[IANA]) mediante un m<strong>en</strong>saje PIM d<strong>en</strong>ominado ‘Bootstrap’. Sin embargo<br />
este mecanismo está p<strong>en</strong>sado para que los difer<strong>en</strong>tes routers se ofrezcan<br />
como candidatos a un conjunto de grupos <strong>multicast</strong> y no para uno <strong>en</strong><br />
concreto. Esto provoca un consumo de recursos, al t<strong>en</strong>er que <strong>en</strong>viar<br />
excesivos paquetes, así como un retardo <strong>en</strong> el procedimi<strong>en</strong>to, que puede<br />
p<strong>en</strong>alizar las prestaciones del sistema.<br />
Otra solución mucho más s<strong>en</strong>cilla consiste simplem<strong>en</strong>te <strong>en</strong> que<br />
cada MMA del dominio t<strong>en</strong>ga asignado un rango de direcciones <strong>multicast</strong><br />
de manera exclusiva. Esta opción no limita <strong>en</strong> exceso la escalabilidad del<br />
sistema, pues como ya se ha com<strong>en</strong>tado las direcciones <strong>multicast</strong> se<br />
reutilizan <strong>en</strong> cada dominio, y la asignación estática de un rango a cada<br />
MMA no debe ser una limitación si existe un grupo sufici<strong>en</strong>tem<strong>en</strong>te<br />
elevado de direcciones disponibles para la implem<strong>en</strong>tación del sistema de<br />
micro-<strong>movilidad</strong> propuesto.<br />
Aún así existe una tercera solución que permite el mant<strong>en</strong>imi<strong>en</strong>to<br />
de las direcciones <strong>multicast</strong> se realice de forma c<strong>en</strong>tralizada <strong>en</strong> el dominio,<br />
es decir, que exista un servidor de direcciones al que se conectan los<br />
difer<strong>en</strong>tes MMAs para obt<strong>en</strong>er una dirección <strong>multicast</strong> libre, que será<br />
asignada al nuevo nodo móvil. En este caso la dirección <strong>multicast</strong> no<br />
aportará información del MMA que la ofreció, y por consigui<strong>en</strong>te,<br />
información del RP asignado a ella. Será necesario, por tanto, el añadir<br />
esta información <strong>en</strong> los m<strong>en</strong>sajes ‘Join’ que los routers <strong>en</strong>vían para<br />
conectarse al árbol <strong>multicast</strong>. El formato de los m<strong>en</strong>sajes ‘Join’ definidos<br />
<strong>en</strong> PIM-SMv2 incorpora un campo d<strong>en</strong>ominado 'Joined Source Address'<br />
que se utiliza para realizar un árbol SPT con una fu<strong>en</strong>te determinada, pero<br />
111
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
que también puede utilizarse para indicar la dirección del RP (existe un<br />
flag para seleccionar esto). Así los distintos routers <strong>multicast</strong> podrían<br />
averiguar el RP asignado antes de re<strong>en</strong>viar el m<strong>en</strong>saje hacia él.<br />
La discusión anterior carece de s<strong>en</strong>tido <strong>en</strong> el caso de estar<br />
trabajando con tecnología SSM. En este caso se utiliza el protocolo IGMPv3<br />
para realizar la conexión al canal de manera que se indica la fu<strong>en</strong>te S de la<br />
que recibiremos los datos <strong>multicast</strong>, y que <strong>en</strong> nuestro caso será el MMA.<br />
Debido a las características de SSM el conocimi<strong>en</strong>to, por parte de los<br />
routers, de la fu<strong>en</strong>te a la que conectarse para g<strong>en</strong>erar el árbol <strong>multicast</strong><br />
vi<strong>en</strong>e implícito <strong>en</strong> el mecanismo de conexión.<br />
3.7 TABLA COMPARATIVA CON OTRAS PROPUESTAS<br />
DE MICRO-MOVILIDAD<br />
En el punto 2.4 se indicó que se podía hacer una s<strong>en</strong>cilla<br />
clasificación de las propuestas de micro-<strong>movilidad</strong> pres<strong>en</strong>tes <strong>en</strong> la<br />
bibliografía:<br />
• Esquemas de ag<strong>en</strong>tes de <strong>movilidad</strong> jerárquicos. Como pued<strong>en</strong><br />
ser el Mobile IP con Registro Regional MIP-RR, [GUS02].<br />
• Esquemas de <strong>en</strong>caminami<strong>en</strong>to <strong>basado</strong> <strong>en</strong> host (HBR). Ejemplos<br />
de estos son: Cellular IP [CAM00], y HAWAII [RAM99].<br />
En este capítulo hemos pres<strong>en</strong>tado un nuevo esquema, totalm<strong>en</strong>te<br />
novedoso, <strong>basado</strong> <strong>en</strong> la utilización de direccionami<strong>en</strong>to <strong>multicast</strong> de las<br />
redes IP actuales. Este esquema podría añadirse como una tercera opción<br />
<strong>en</strong> la clasificación anterior.<br />
Con el fin de comparar, de manera cualitativa, nuestra solución<br />
con las ya com<strong>en</strong>tadas, <strong>en</strong> este punto se va a mostrar una tabla que<br />
muestra las princ<strong>ip</strong>ales características de las princ<strong>ip</strong>ales propuestas. La<br />
idea es realizar un estudio del sistema de micro-<strong>movilidad</strong> <strong>en</strong> g<strong>en</strong>eral, sin<br />
112
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
abordar profundam<strong>en</strong>te los aspectos relativos al handover, que serán<br />
tratados con mucha mayor profundidad <strong>en</strong> los capítulos sigui<strong>en</strong>tes de esta<br />
Tesis Doctoral.<br />
En esta comparación vamos a estudiar, además de nuestra<br />
propuesta, los sistemas de micro-<strong>movilidad</strong> Cellular IP, y MIP-RR, por ser<br />
repres<strong>en</strong>tativos de sus respectivas categorías. Estudios de los sistemas de<br />
micro-<strong>movilidad</strong> pued<strong>en</strong> <strong>en</strong>contrarse <strong>en</strong> [EAR00], [WON01] o [REI01].<br />
MIP-RR<br />
Cellular IP<br />
Sistema <strong>basado</strong><br />
<strong>en</strong> Multicast.<br />
Direccionami<strong>en</strong><br />
to de los<br />
paquetes <strong>en</strong><br />
s<strong>en</strong>tido<br />
desc<strong>en</strong>d<strong>en</strong>te<br />
Utilización de<br />
túneles, de<br />
manera<br />
secu<strong>en</strong>cial.<br />
Encaminami<strong>en</strong>to<br />
<strong>basado</strong> <strong>en</strong> la<br />
dirección<br />
perman<strong>en</strong>te del<br />
MN.<br />
Encapsulación <strong>en</strong><br />
paquetes<br />
<strong>multicast</strong>.<br />
Actualización<br />
de rutas<br />
MIP + ext<strong>en</strong>siones<br />
de registro<br />
regional.<br />
M<strong>en</strong>saje de<br />
actualización<br />
especiales<br />
M<strong>en</strong>sajes<br />
<strong>multicast</strong> Join y<br />
AckJoin.<br />
Nodos del<br />
Dominio<br />
Routers<br />
Nodos especiales<br />
Cellular IP.<br />
Routers con<br />
capacidad<br />
<strong>multicast</strong>.<br />
Capacidades<br />
avanzadas del<br />
MN<br />
Sí, capacidad de<br />
registro regional.<br />
Sí, soporte<br />
completo de<br />
Cellular IP.<br />
Sí, MIP +<br />
capacidad de<br />
registro<br />
intradominio.<br />
Seguridad<br />
Sí. Según MIP,<br />
con ext<strong>en</strong>siones<br />
de MIP_RO.<br />
Sí. Los paquetes<br />
de actualización<br />
de rutas van<br />
aut<strong>en</strong>ticados.<br />
Sí, los paquetes de<br />
registro van<br />
aut<strong>en</strong>ticados.<br />
Definición<br />
formal de<br />
paquetes<br />
Sí No Sí<br />
Gestión del<br />
Handover<br />
Igual que MIP.<br />
Handover abrupto<br />
y semisuave.<br />
5 posibles<br />
esquemas.<br />
Escalabilidad<br />
Utilización de<br />
varios niveles de<br />
jerarquía.<br />
No, el Gateway<br />
soporta todo el<br />
tráfico.<br />
Sí, múlt<strong>ip</strong>les<br />
MMAs.<br />
Tabla 1. Comparación de sistemas de micro-<strong>movilidad</strong>.<br />
113
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
3.8 CONCLUSIONES DEL CAPÍTULO<br />
En el capítulo anterior se detalló como el protocolo Mobile IP ti<strong>en</strong>e<br />
ciertas limitaciones debidas, princ<strong>ip</strong>alm<strong>en</strong>te, a la necesidad de un registro<br />
cada vez que se produce un handover. Una solución ampliam<strong>en</strong>te<br />
aceptada es dividir la <strong>movilidad</strong> <strong>en</strong> dos partes, de manera que d<strong>en</strong>tro de<br />
un dominio se emplean protocolos específicos de <strong>movilidad</strong>, mant<strong>en</strong>iéndose<br />
el protocolo Mobile IP para la <strong>movilidad</strong> <strong>en</strong>tre dominios.<br />
En este capítulo se ha pres<strong>en</strong>tado un sistema de micro-<strong>movilidad</strong> IP<br />
<strong>basado</strong> <strong>en</strong> la tecnología <strong>multicast</strong>. La idea princ<strong>ip</strong>al ha sido incorporar las<br />
v<strong>en</strong>tajas que nos ofrece este t<strong>ip</strong>o de tecnología, y que han sido com<strong>en</strong>tadas<br />
<strong>en</strong> el punto 3.1, a la solución de dividir la red <strong>en</strong> dominios.<br />
A difer<strong>en</strong>cia de la mayoría de las soluciones pres<strong>en</strong>tadas <strong>en</strong> la<br />
literatura, se ha desarrollado, no sólo una arquitectura, sino un protocolo<br />
completo, incluy<strong>en</strong>do el formato de todos los m<strong>en</strong>sajes que proponemos.<br />
Estos m<strong>en</strong>sajes han sido realizados sigui<strong>en</strong>do las estructuras de ext<strong>en</strong>sión<br />
del propio protocolo Mobile IP [RFC 3444], así como los trabajos que se<br />
están realizando actualm<strong>en</strong>te [KHA01], [GUS02], [PER02]. El objetivo es<br />
que el sistema propuesto pueda integrarse perfectam<strong>en</strong>te <strong>en</strong> un sistema<br />
<strong>basado</strong> <strong>en</strong> Mobile IP.<br />
El sistema pres<strong>en</strong>tado ha sido realizado t<strong>en</strong>i<strong>en</strong>do pres<strong>en</strong>te los<br />
posibles problemas de escalabilidad. El punto crítico <strong>en</strong> cualquier sistema<br />
de micro-<strong>movilidad</strong> es la pasarela del dominio. En un sistema Cellular IP<br />
sería el MA, y el router raíz DRR <strong>en</strong> el sistema HAWAII. El sistema<br />
pres<strong>en</strong>tado <strong>en</strong> este capítulo se ha diseñado de manera que no exista<br />
limitación <strong>en</strong> cuanto al número de MMAs (Ag<strong>en</strong>te de Movilidad Multicast)<br />
que pued<strong>en</strong> instalarse. Así los m<strong>en</strong>sajes se han diseñado de manera que<br />
aportan información sobre el MMA que está utilizando el nodo móvil. Esta<br />
información es necesaria para que las estaciones puedan realizar<br />
correctam<strong>en</strong>te el handover intra-dominio.<br />
A difer<strong>en</strong>cia de los demás sistemas de micro-<strong>movilidad</strong> pres<strong>en</strong>tados<br />
<strong>en</strong> la bibliografía, el sistema propuesto <strong>en</strong> este capítulo se ha realizado<br />
114
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
incluy<strong>en</strong>do todos los mecanismos de seguridad necesarios <strong>en</strong> este t<strong>ip</strong>o de<br />
redes. En particular se ha ampliado las ext<strong>en</strong>siones de aut<strong>en</strong>tificación del<br />
protocolo Mobile IP incluy<strong>en</strong>do una aut<strong>en</strong>tificación FA-FA (ver punto 3.5.2).<br />
Además se abordado el problema del establecimi<strong>en</strong>to de la asociación de<br />
seguridad <strong>en</strong>tre el nodo móvil y las estaciones base, tema actualm<strong>en</strong>te bajo<br />
estudio <strong>en</strong> el grupo de trabajo ‘m<strong>ip</strong>v4’ del IETF.<br />
Por último se ha realizado una evaluación de las difer<strong>en</strong>tes<br />
tecnologías <strong>multicast</strong>, con el fin de decidir cual es la más adecuada para<br />
incluirla <strong>en</strong> el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong> propuesto. Se ha optado por<br />
protocolos que utilizan algoritmos de árbol compartido, ya que la<br />
inundación utilizada <strong>en</strong> los protocolos de modo d<strong>en</strong>so no está justificada.<br />
Se propon<strong>en</strong> dos opciones para incorporar al sistema de micro-<strong>movilidad</strong>.<br />
La primera es el protocolo PIM-SM, de gran aceptación por la industria<br />
[RFC 2362]. Debido a las características particulares del sistema de<br />
micro<strong>movilidad</strong> (una única fu<strong>en</strong>te que coincide, además, con el<br />
R<strong>en</strong>dezvous Point), muchas de las características de este protocolo no son<br />
necesarias, por lo que el protocolo podría simplificarse. La segunda opción<br />
es la tecnología SSM (Source-Specific Multicast) [BHA03],[HOL03]. Esta<br />
tecnología se ajusta perfectam<strong>en</strong>te a nuestro sistema, ya que está p<strong>en</strong>sado<br />
<strong>en</strong> transmisiones de uno a varios. Sin embargo actualm<strong>en</strong>te no exist<strong>en</strong><br />
aún protocolos específicos SSM, ya que es una tecnología que actualm<strong>en</strong>te<br />
se <strong>en</strong>cu<strong>en</strong>tra bajo estudio.<br />
En los sigui<strong>en</strong>tes capítulos nos vamos a c<strong>en</strong>trar <strong>en</strong> el estudio de los<br />
esquemas de Handover. Así vamos a analizar, tanto las prestaciones de los<br />
sistemas de <strong>movilidad</strong> pres<strong>en</strong>tados <strong>en</strong> la bibliografía, como una evaluación<br />
analítica de las prestaciones de los distintos esquemas de handover que se<br />
han desarrollado para el sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
pres<strong>en</strong>tado <strong>en</strong> este capítulo.<br />
115
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
116
4. PROCESO DE HANDOVER EN REDES IP<br />
4.1 INTRODUCCIÓN<br />
Las aplicaciones de tiempo real, como audio o video confer<strong>en</strong>cias,<br />
ti<strong>en</strong><strong>en</strong> unos requerimi<strong>en</strong>tos elevados <strong>en</strong> relación al límite de la lat<strong>en</strong>cia,<br />
indicativo del retardo extremo a extremo. Los paquetes perdidos durante la<br />
transmisión se traducirán <strong>en</strong> interrupciones <strong>en</strong> el flujo de datos <strong>en</strong> el<br />
receptor, el cual g<strong>en</strong>eralm<strong>en</strong>te no t<strong>en</strong>drá tiempo de esperar una<br />
retransmisión de los mismos desde el emisor. Así, <strong>en</strong> este t<strong>ip</strong>o de<br />
aplicaciones, los paquetes válidos que llegan más tarde del retardo máximo<br />
permitido son descartados.<br />
En una red que soporta la <strong>movilidad</strong> los aspectos relativos a la<br />
<strong>en</strong>trega de datos hacia los nodos móviles pued<strong>en</strong> dividirse <strong>en</strong> dos tareas<br />
difer<strong>en</strong>ciadas:<br />
• Mi<strong>en</strong>tras el nodo móvil permanece bajo la cobertura de un Punto de<br />
Acceso, el problema es similar a la tarea, no trivial, de proporcionar<br />
calidad de servicio a nodos fijos <strong>en</strong> una red de conmutación de<br />
paquetes. La ruta <strong>en</strong>tre el nodo móvil y el nodo con el que se comunica<br />
debe seleccionarse cuidadosam<strong>en</strong>te para que el retardo total se<br />
mant<strong>en</strong>ga d<strong>en</strong>tro de los límites aceptables. Como ya se ha estudiado,<br />
algunos protocolos como Mobile IP introduc<strong>en</strong> serias limitaciones <strong>en</strong><br />
este s<strong>en</strong>tido, al <strong>en</strong>viar los paquetes vía un ag<strong>en</strong>te de <strong>movilidad</strong>, y por<br />
tanto, utilizando una ruta no óptima. Varios trabajos [PER01], [JOH03]<br />
han pres<strong>en</strong>tado distintas soluciones que int<strong>en</strong>tan lograr una ruta lo<br />
más directa posible.<br />
• Cuando un nodo se mueve desde una zona cubierta por un punto de<br />
acceso a otra cubierta por otro se producirá un proceso de handover.<br />
117
Proceso de Handover <strong>en</strong> redes IP<br />
Podemos definir el ‘handover’ 1 como el procedimi<strong>en</strong>to por el cual nodo<br />
móvil activo cambia su conexión de un Punto de Acceso a otro a través<br />
de la red. Los puntos de acceso son los extremos de la red fija y vía<br />
radio se comunican con el móvil transmitiéndole la información. Así,<br />
por medio del procedimi<strong>en</strong>to de handover los datos que se transmit<strong>en</strong><br />
por la red fija desde un servidor deb<strong>en</strong> de re<strong>en</strong>rutarse sin que ello<br />
produzca una interrupción <strong>en</strong> la comunicación <strong>en</strong>tre los dos extremos.<br />
Es deseable realizar el proceso de handover rápidam<strong>en</strong>te. Si el tiempo<br />
de handover es elevado <strong>en</strong> relación la zona común a las dos zonas se<br />
producirán interrupciones <strong>en</strong> el flujo de datos aún cuando el retardo<br />
total sea bajo.<br />
El tráfico producido <strong>en</strong> la red por el handover es función de varios<br />
factores [POL96], como el número de móviles, su función de <strong>movilidad</strong>,<br />
velocidad, el tamaño de las celdas, t<strong>ip</strong>o de conexión, etc. La transmisión de<br />
servicios multimedia determina que el tamaño de las celdas sea pequeño,<br />
con el fin de lograr una reutilización de frecu<strong>en</strong>cias efici<strong>en</strong>te. Esta<br />
reducción de tamaño trae consigo, sin embargo, que el número de<br />
handovers sea mayor y, por tanto, habrá que lograr minimizar la<br />
señalización por handover con el fin de no sobrecargar demasiado la red.<br />
Por otra parte, celdas pequeñas hac<strong>en</strong> que la zona de solapami<strong>en</strong>to <strong>en</strong>tre<br />
dos celdas contiguas sea también pequeña. Como resultado de esto, el<br />
tiempo <strong>en</strong> el que debe de producirse el handover disminuye y será<br />
necesario que el diseño de los protocolos de señalización permita<br />
mecanismos rápidos con el fin de que no se pierdan conexiones.<br />
Exist<strong>en</strong> difer<strong>en</strong>tes t<strong>ip</strong>os de clasificaciones de handover de acuerdo a<br />
difer<strong>en</strong>tes aspectos involucrados <strong>en</strong> el mismo. A continuación se va a<br />
com<strong>en</strong>tar alguna de estas clasificaciones, siempre desde el <strong>en</strong>foque de la<br />
<strong>movilidad</strong> <strong>en</strong> redes IP. Estas clasificaciones son indep<strong>en</strong>di<strong>en</strong>tes, de manera<br />
que cada handover podría clasificarse <strong>en</strong> cada uno de estos t<strong>ip</strong>os.<br />
1 Los términos Handover y Handoff son equival<strong>en</strong>tes y <strong>en</strong> la bibliografía son utilizados<br />
indistintam<strong>en</strong>te.<br />
118
Proceso de Handover <strong>en</strong> redes IP<br />
• Capa implicada <strong>en</strong> el Handover: Podemos distinguir <strong>en</strong>tre un<br />
handover de capa dos (L2) y uno de capa tres (L3). Un handover L2<br />
ocurre cuando el nodo móvil (MN) se mueve desde un Punto de Acceso<br />
(AP) a otro que está conectado a un mismo Router de Acceso (Access<br />
Router, AR). Este t<strong>ip</strong>o de handover es transpar<strong>en</strong>te a la capa de red y,<br />
por tanto, no implica al protocolo de <strong>movilidad</strong> IP. Así el handover L2<br />
sería manejado por el protocolo de <strong>en</strong>lace correspondi<strong>en</strong>te, por ejemplo<br />
IEEE 802.11, y no sería necesario obt<strong>en</strong>er una nueva dirección Care-of<br />
Address (CoA), ni <strong>en</strong> g<strong>en</strong>eral utilizar ningún mecanismo de <strong>movilidad</strong> o<br />
micro-<strong>movilidad</strong> de capa de red.<br />
Por otro lado t<strong>en</strong>emos el handover L3 que se produce cuando el MN<br />
cambia de AR. En este caso se produce un cambio de subred y será<br />
necesario utilizar un protocolo de <strong>movilidad</strong> a nivel 3 como los que<br />
estamos estudiando <strong>en</strong> esta Tesis.<br />
• Nodo que inicia el Handover: Podemos distinguir dos t<strong>ip</strong>os de<br />
handover <strong>en</strong> función de quién toma la decisión inicial de com<strong>en</strong>zar el<br />
proceso de handover. Así t<strong>en</strong>dremos por un lado el d<strong>en</strong>ominado<br />
handover ‘Iniciado por el Nodo Móvil’, y por otro el handover ‘Iniciado<br />
por la Red’ que se refiere a cuando es algún elem<strong>en</strong>to que forma la red<br />
(por ejemplo puntos de acceso o Foreign Ag<strong>en</strong>t) quién lo inicia.<br />
• Nodo que controla el handover: El handover puede ser controlado por<br />
el nodo móvil o por algún elem<strong>en</strong>to de la red. Tanto <strong>en</strong> el protocolo<br />
Mobile IP como <strong>en</strong> todos los sistemas de micro-<strong>movilidad</strong> publicados se<br />
opta por un handover controlado por el nodo móvil. La princ<strong>ip</strong>al razón<br />
es que el nodo móvil es el mejor lugar para <strong>en</strong>t<strong>en</strong>der las necesidades<br />
del usuario <strong>en</strong> términos de las aplicaciones que se están utilizando,<br />
los requerimi<strong>en</strong>tos de QoS, etc. Por el contrario, <strong>en</strong> los sistemas<br />
celulares tradicionales no se necesita dar un control final al usuario,<br />
porque sólo se proporciona un único servicio (voz), y éste se puede<br />
proporcionar fácilm<strong>en</strong>te por la red. Por tanto <strong>en</strong> este t<strong>ip</strong>o de redes el<br />
handover está controlado por la red.<br />
119
Proceso de Handover <strong>en</strong> redes IP<br />
• Nodo por el que se realiza el handover: Podemos distinguir dos t<strong>ip</strong>os<br />
de handover <strong>en</strong> función del nodo de la red por el que se realiza. Así el<br />
handover puede ser hacia atrás (‘Backward Handover’) cuando es<br />
iniciado por el AR actual (oAR) o cuando el nodo móvil inicia el<br />
handover por él. Por otra parte el handover puede ser hacia delante<br />
(‘Forward Handover’) cuando es iniciado por el nuevo nAR o bi<strong>en</strong><br />
cuando el nodo móvil inicia el handover vía el este nuevo nAR.<br />
• Modo esperado o no esperado: Cuando un handover utiliza alguna<br />
señalización previa a la conexión del nodo al nuevo AR se d<strong>en</strong>omina<br />
handover esperado o planeado (‘Expected o Planned Handover’). Un<br />
ejemplo sería cuando se construye un túnel temporal <strong>en</strong>tre los dos AR<br />
para transmitir los paquetes p<strong>en</strong>di<strong>en</strong>tes. Por otra parte definimos<br />
handover no esperado o no planeado cuando no se realiza ninguna<br />
señalización previa al movimi<strong>en</strong>to del MN desde un oAR a un nAR.<br />
• Conectividad simultánea: Un nodo móvil puede comunicarse<br />
simultáneam<strong>en</strong>te con los dos Routers de Acceso (oAR y nAR) durante el<br />
handover. Este modo de funcionami<strong>en</strong>to se d<strong>en</strong>omina ‘Make-Before-<br />
Break’ (MBB) y no debería ser confundido con el término handover<br />
blando (‘Soft Handover’) relativo a la macro diversidad [KEM01].<br />
La macro diversidad se refiere a la capacidad de ciertos nodos móviles<br />
de recibir y transmitir simultáneam<strong>en</strong>te sobre dos canales radio<br />
indep<strong>en</strong>di<strong>en</strong>tes, de manera que se puede comparar <strong>en</strong> que canal se<br />
recibe la información con mejor calidad y pasar ésta a las capas<br />
superiores. La macro diversidad se refiere a nivel de <strong>en</strong>lace radio y<br />
puede utilizarse para mejorar el handover L2. Un ejemplo de este<br />
mecanismo sería los sistemas móviles 3G <strong>basado</strong>s <strong>en</strong> CDMA como<br />
UMTS. La mayoría de la bibliografía utiliza, sin embargo, ambos<br />
términos indistintam<strong>en</strong>te.<br />
La otra opción sería la d<strong>en</strong>ominada ‘Break-Before-Make’ (BBM) donde el<br />
MN no puede comunicarse simultáneam<strong>en</strong>te con los dos AR.<br />
En este capítulo se va a profundizar <strong>en</strong> los difer<strong>en</strong>tes t<strong>ip</strong>os del<br />
proceso handover. La int<strong>en</strong>ción última es estudiar las soluciones que han<br />
120
Proceso de Handover <strong>en</strong> redes IP<br />
sido aportadas a la mejora del proceso de handover <strong>en</strong> redes IP móviles,<br />
por ser éste el marco de trabajo de la pres<strong>en</strong>te Tesis. No se trata, por tanto,<br />
el tema del handover <strong>en</strong> otro t<strong>ip</strong>o de redes como ATM o sistemas celulares<br />
donde existe una bibliografía sufici<strong>en</strong>tem<strong>en</strong>te ext<strong>en</strong>sa. Así, por ejemplo,<br />
una visión de conjunto las difer<strong>en</strong>tes soluciones propuestas para realizar<br />
el handover <strong>en</strong> redes ATM se podría obt<strong>en</strong>er a partir de [ACA94], [YUA96],<br />
[AKY97] y [LEO98]. Una clasificación de handovers <strong>en</strong> sistemas celulares<br />
puede <strong>en</strong>contrarse <strong>en</strong> [POL96].<br />
El resto del capítulo se divide <strong>en</strong> los sigui<strong>en</strong>tes puntos: En el punto<br />
4.2 se hace un estudio de la lat<strong>en</strong>cia que produce el proceso de handover.<br />
Además se va a recordar el proceso especificado <strong>en</strong> el protocolo Mobile IP,<br />
que nos va a servir, como <strong>en</strong> anteriores situaciones, como base para<br />
posibles mejoras. El punto 4.3 trata la separación que existe <strong>en</strong>tre el<br />
handover <strong>en</strong> la capa dos y <strong>en</strong> la capa tres, y como una cooperación <strong>en</strong>tre<br />
ambos puede traducirse <strong>en</strong> una mejora de prestaciones. En el punto 4.4 se<br />
realiza una clasificación de las difer<strong>en</strong>tes propuestas que se han<br />
pres<strong>en</strong>tado para mejoras el handover <strong>en</strong> redes IP móviles. Para finalizar,<br />
las conclusiones obt<strong>en</strong>idas de estas soluciones se muestran <strong>en</strong> el punto<br />
4.5.<br />
4.2 Lat<strong>en</strong>cia del proceso de Handover <strong>en</strong> redes IP<br />
Desde el punto de vista del estudio de un proceso de handover de<br />
capa tres podemos estudiar la lat<strong>en</strong>cia como la suma de tres tiempos<br />
difer<strong>en</strong>ciados [VAT98]: Retardo <strong>en</strong> la detección de movimi<strong>en</strong>to, (T move-detect );<br />
Retardo <strong>en</strong> la recuperación de una dirección temporal, Care-of Address,<br />
(T co-retrieval ); y el Retardo de reestablecimi<strong>en</strong>to de la ruta (T redirect ).<br />
T handover =fh (T move-detect, T co-retrieval, T redirect )<br />
A continuación se detallan estos tres compon<strong>en</strong>tes.<br />
121
Proceso de Handover <strong>en</strong> redes IP<br />
4.2.1 Retardo <strong>en</strong> la detección del movimi<strong>en</strong>to<br />
El retardo <strong>en</strong> la detección de movimi<strong>en</strong>to se refiere al tiempo<br />
necesario para detectar que se ha producido un cambio de subred y que es<br />
necesario iniciar un handover de capa tres.<br />
En el protocolo Mobile IP [RFC 3344] esta detección la realiza el<br />
nodo móvil estudiando los m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ que recibe. La<br />
recepción de estos paquetes del nuevo Foreign Ag<strong>en</strong>t implica que se ha<br />
t<strong>en</strong>ido que producir previam<strong>en</strong>te un handover de capa dos, el cual se ha<br />
traducido <strong>en</strong> un cambio de conectividad de un Punto de Acceso a otro que<br />
pert<strong>en</strong>ece a otra subred.<br />
Por tanto, el proceso de handover L2 va a afectar directam<strong>en</strong>te a las<br />
prestaciones del handover de la capa de red, puesto que, <strong>en</strong> un princ<strong>ip</strong>io,<br />
hasta que no finalice el primero no es posible detectar que es necesario<br />
que se produzca el segundo.<br />
El tiempo necesario para que se realice un handover de capa dos, y<br />
que lo podemos incluir <strong>en</strong> el retardo de detección de movimi<strong>en</strong>to, dep<strong>en</strong>de<br />
del t<strong>ip</strong>o de red que se está utilizando. Para minimizarlo sería deseable que<br />
el nodo móvil pudiera detectar que ha <strong>en</strong>trado <strong>en</strong> una nueva celda y<br />
desarrollar el handover antes de perder la conectividad con el punto de<br />
acceso previo. El desarrollo este t<strong>ip</strong>o de handover implica la necesidad que<br />
la zona de solape <strong>en</strong>tre las dos celdas sea sufici<strong>en</strong>tem<strong>en</strong>te amplia <strong>en</strong><br />
relación a la lat<strong>en</strong>cia del proceso y a la velocidad del nodo móvil. El<br />
proceso se facilita si el nodo móvil puede comunicarse simultáneam<strong>en</strong>te<br />
con los dos AP, por ejemplo utilizando técnicas de espectro <strong>en</strong>sanchado<br />
(DSSS) con múlt<strong>ip</strong>les códigos [KER94]. Otra alternativa sería la de utilizar<br />
múlt<strong>ip</strong>les interfaces inalámbricos [ZHA98].<br />
La detección del cambio de celda se realiza midi<strong>en</strong>do los niveles de<br />
señal <strong>en</strong> el interfaz. Cuando el nivel de relación señal ruido (SNR) baja de<br />
cierto nivel se iniciaría el proceso de handover, utilizando por ejemplo un<br />
mecanismo de histéresis para eliminar problemas con los nodos que se<br />
muev<strong>en</strong> <strong>en</strong>tre las dos zonas [LIU96]. Las medidas pued<strong>en</strong> realizarse bi<strong>en</strong><br />
122
Proceso de Handover <strong>en</strong> redes IP<br />
midi<strong>en</strong>do señales de anuncio (beacon), o bi<strong>en</strong> cualquier otro t<strong>ip</strong>o de<br />
señales <strong>en</strong>viadas por el AP.<br />
A pesar que <strong>en</strong> un princ<strong>ip</strong>io se puede p<strong>en</strong>sar que el proceso de<br />
handover L2 queda fuera de nuestro estudio, ya que estamos trabajando<br />
con soluciones de capa tres, la realidad es que las prestaciones que se<br />
pued<strong>en</strong> obt<strong>en</strong>er <strong>en</strong> un handover L3 dep<strong>en</strong>d<strong>en</strong>, <strong>en</strong> gran medida, de las<br />
facilidades que ofrece el nivel inferior. Así <strong>en</strong> el punto 4.3 se estudiará<br />
como una cooperación <strong>en</strong>tre ambas capas mejora las prestaciones del<br />
handover L3, mi<strong>en</strong>tras que algunas de las soluciones que se detallan <strong>en</strong> el<br />
punto 4.4 presupon<strong>en</strong> la capacidad de la capa de <strong>en</strong>lace de comunicarse<br />
simultáneam<strong>en</strong>te con los dos AP implicados.<br />
4.2.2 Retardo <strong>en</strong> la recuperación de una dirección temporal,<br />
Care-of Address<br />
En la gran mayoría de los sistemas de <strong>movilidad</strong> IP estudiados cada<br />
nodo móvil dispone de una dirección perman<strong>en</strong>te (Home Address) asignada<br />
a una (posiblem<strong>en</strong>te virtual) Home Network. Cuando un nodo móvil visita<br />
una red distinta utiliza para su id<strong>en</strong>tificación una dirección adicional que<br />
se d<strong>en</strong>omina Care-of Address (CoA) y que puede ser asignada directam<strong>en</strong>te<br />
al nodo móvil (Co-located Care-of Address), o bi<strong>en</strong> puede ser la dirección de<br />
un ag<strong>en</strong>te (Foreign Ag<strong>en</strong>t) que se dedica a dar conectividad a múlt<strong>ip</strong>les<br />
nodos móviles (ver punto 2.3 o [RFC 3344]).<br />
Exist<strong>en</strong> varias soluciones que permit<strong>en</strong> a un nodo móvil obt<strong>en</strong>er<br />
una dirección temporal (Co-located Care-of Address):<br />
• Asignación estática. Si el grupo de redes que puede visitar el nodo<br />
móvil es conocido de antemano y las direcciones IP no son<br />
consideradas un recurso escaso, cada estación puede t<strong>en</strong>er<br />
preasignadas una serie de direcciones IP que utilizará cuando visite<br />
esas redes.<br />
123
Proceso de Handover <strong>en</strong> redes IP<br />
• Configuración predeterminada. Es posible asignar a un nodo<br />
móvil una dirección IP cuando visita una nueva red de un modo<br />
controlado, por ejemplo utilizando un servidor DHCP [RFC 2131].<br />
En Mobile IPv6 esta solución se conoce como configuración ‘Stateful’<br />
[JOH03]. También sería posible la utilización de otros mecanismos<br />
de configuración como el uso de servidores BOOTP [RFC 1542]. Sin<br />
embargo la utilización de servidores DHCP aporta v<strong>en</strong>tajas sobre<br />
estas últimas soluciones, un ejemplo sería el mecanismo de<br />
asignación de direcciones, realizando asignaciones que sólo son<br />
válidas durante un cierto tiempo, permiti<strong>en</strong>do una reutilización de<br />
las mismas.<br />
• Configuración sin interv<strong>en</strong>ción. En IPv6 aparece el concepto de<br />
autoconfiguración sin interv<strong>en</strong>ción ‘Stateless’ [RFC 1971]. Así, el<br />
nodo g<strong>en</strong>era un id<strong>en</strong>tificador único del interfaz, conocido como<br />
‘Interface Tok<strong>en</strong>’. Este id<strong>en</strong>tificativo se une al prefijo de la red donde<br />
está situado el nodo para formar una dirección global válida y<br />
única. El prefijo de la red lo obt<strong>en</strong>dría de los anuncios realizados<br />
por los routers de la red. Un ejemplo para construir el id<strong>en</strong>tificativo<br />
único sería partir de una dirección IEEE MAC de 48 bits como se<br />
indica <strong>en</strong> [RFC 2373]<br />
En [BAK96] se han realizado estudios del retardo de handover<br />
cuando el nodo móvil ti<strong>en</strong>e asignadas de antemano un grupo de<br />
direcciones IP asociadas a las redes que va a visitar. En [VAT98] se realiza<br />
un estudio porm<strong>en</strong>orizado de este retardo cuando se utilizan servidores<br />
DHCP obt<strong>en</strong>i<strong>en</strong>do valores <strong>en</strong> torno a los 103 ms. para la obt<strong>en</strong>ción de una<br />
dirección temporal.<br />
Por último indicar que algunos sistemas de micro-<strong>movilidad</strong>, <strong>en</strong><br />
particular los <strong>basado</strong>s <strong>en</strong> <strong>en</strong>caminami<strong>en</strong>to por host como pued<strong>en</strong> ser<br />
HAWAII o Cellular IP, eliminan este compon<strong>en</strong>te de la lat<strong>en</strong>cia durante los<br />
handovers intra-dominio, al mant<strong>en</strong>er constante la dirección CoA.<br />
También el protocolo de micro-<strong>movilidad</strong> <strong>multicast</strong> propuesto <strong>en</strong> el<br />
capítulo 3 elimina este retardo puesto que utiliza una dirección <strong>multicast</strong><br />
124
Proceso de Handover <strong>en</strong> redes IP<br />
que permanece constante durante la perman<strong>en</strong>cia del nodo móvil <strong>en</strong> el<br />
dominio.<br />
4.2.3 Retardo de reestablecimi<strong>en</strong>to de la ruta<br />
Una vez el nodo móvil (MN) ha adquirido la nueva dirección IP es<br />
necesario una serie de pasos hasta que el flujo de datos alcanza al nodo <strong>en</strong><br />
su nueva localización. Este proceso influye de manera importante <strong>en</strong><br />
tiempo total del proceso del handover, y varía dep<strong>en</strong>di<strong>en</strong>do del esquema de<br />
<strong>movilidad</strong> implem<strong>en</strong>tado.<br />
Hay que indicar que este retardo afecta al flujo de datos que fluye<br />
<strong>en</strong> s<strong>en</strong>tido host corresponsal (CN) hacia el nodo móvil. En s<strong>en</strong>tido<br />
contrario el MN transmite directam<strong>en</strong>te los datos hacia el destino<br />
utilizando siempre su dirección perman<strong>en</strong>te para que no existan<br />
problemas con las conexiones <strong>en</strong> curso. La excepción a esto se produce<br />
cuando los routers filtran los paquetes cuya dirección fu<strong>en</strong>te no es<br />
correcta según la topología, es decir, cuando la dirección fu<strong>en</strong>te no<br />
coincide con las redes que <strong>en</strong>tran por ese interfaz del router. En este caso<br />
el nodo móvil debería re<strong>en</strong>viar los datos al Home Ag<strong>en</strong>t utilizando un túnel<br />
para que este a su vez los re<strong>en</strong>viara desde la Home Network. Este proceso<br />
se conoce como ‘Reverse tunneling’, estandarizado <strong>en</strong> [RFC 3024].<br />
En el protocolo Mobile IP, el MN <strong>en</strong>vía el conocido m<strong>en</strong>saje de<br />
solicitud de registro hacia <strong>en</strong> HA (Home Ag<strong>en</strong>t) para que este actualice la<br />
<strong>en</strong>trada correspondi<strong>en</strong>te <strong>en</strong> su tabla. El HA contesta con un m<strong>en</strong>saje de<br />
respuesta de registro, a partir del cual empezaría a <strong>en</strong>viar los datos<br />
utilizando la nueva dirección.<br />
El tiempo que lleva este proceso dep<strong>en</strong>de del mecanismo por el que<br />
el MN ha obt<strong>en</strong>ido la dirección temporal. Así, <strong>en</strong> el caso estar utilizando<br />
una dirección Care-of Address de un Ag<strong>en</strong>te (FA), habrá que t<strong>en</strong>er <strong>en</strong><br />
cu<strong>en</strong>ta que el m<strong>en</strong>saje de registro es <strong>en</strong>viado por el MN hasta el Foreign<br />
Ag<strong>en</strong>t, quién deberá procesarlo antes de re<strong>en</strong>viarlo al Home Ag<strong>en</strong>t. De la<br />
125
Proceso de Handover <strong>en</strong> redes IP<br />
misma manera el m<strong>en</strong>saje de confirmación es <strong>en</strong>viado desde el HA hacia el<br />
FA, quién lo re<strong>en</strong>viará finalm<strong>en</strong>te al nodo móvil.<br />
Cuando un nodo móvil se <strong>en</strong>cu<strong>en</strong>tra lejos de su red original (Home<br />
Network) los m<strong>en</strong>sajes de registro experim<strong>en</strong>tarán un mayor retardo. Con<br />
el fin de reducir el tiempo de reestablecimi<strong>en</strong>to de ruta se han propuesto<br />
diversas mejoras y que nosotros conocemos como sistemas de micro<strong>movilidad</strong>.<br />
Así t<strong>en</strong>emos los 'Esquemas con ag<strong>en</strong>tes de <strong>movilidad</strong><br />
jerárquicos' como el Registro Regional [GUS02] (ver punto 2.3.7). La idea<br />
aquí es que los handovers que se realizan d<strong>en</strong>tro de un dominio se<br />
traduzcan <strong>en</strong> un registro realizado <strong>en</strong> un Ag<strong>en</strong>te Pasarela (GFA Gateway<br />
Foreign Ag<strong>en</strong>t) situado <strong>en</strong> el dominio y provocando retardos m<strong>en</strong>ores. Por<br />
otro lado, <strong>en</strong> los 'Esquemas de <strong>en</strong>caminami<strong>en</strong>to <strong>basado</strong> <strong>en</strong> host (HBR)' (ver<br />
punto 2.4) el establecimi<strong>en</strong>to de ruta sólo afecta a unos pocos routers<br />
situados por debajo del Nodo de Cruce, por lo que también se reduce<br />
mucho el retardo de reestablecimi<strong>en</strong>to.<br />
Por último <strong>en</strong> el sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
propuesto <strong>en</strong> el capítulo 3 el tiempo de reestablecimi<strong>en</strong>to de ruta sería<br />
simplem<strong>en</strong>te el tiempo que necesita el nFA <strong>en</strong> conectarse al árbol<br />
<strong>multicast</strong>. Un estudio detallado de la lat<strong>en</strong>cia total de este sistema se<br />
muestra <strong>en</strong> el capítulo 6.<br />
4.3 COOPERACIÓN DE LA CAPA 2 DURANTE EL<br />
HANDOVER<br />
Con el fin de ofrecer una solución lo más g<strong>en</strong>eral posible, el<br />
protocolo Mobile IP se diseñó sin suponer nada del nivel de <strong>en</strong>lace de datos<br />
(L2) que trabaja por debajo de él. Esta solución pres<strong>en</strong>ta la v<strong>en</strong>taja de<br />
ofrecer una clara separación <strong>en</strong>tre los niveles L2 y L3 <strong>en</strong> la pila de<br />
protocolos, pero ti<strong>en</strong>e una consecu<strong>en</strong>cia negativa <strong>en</strong> la lat<strong>en</strong>cia del proceso<br />
de handover.<br />
126
Proceso de Handover <strong>en</strong> redes IP<br />
En el protocolo original, un nodo móvil (MN) sólo puede<br />
comunicarse con un Foreign Ag<strong>en</strong>t con el que ti<strong>en</strong>e una conexión directa.<br />
Esto implica que el MN sólo puede com<strong>en</strong>zar el proceso de registro con el<br />
nuevo Foreign Ag<strong>en</strong>t (nFA) una vez que el handover de nivel dos ha sido<br />
completado con éxito. Además, <strong>en</strong> ningún mom<strong>en</strong>to se especifica un<br />
mecanismo por el que el protocolo de nivel dos indique a la capa superior<br />
que este handover L2 se ha producido, lo que se traduce <strong>en</strong> que el<br />
protocolo Mobile IP debe detectar, de manera totalm<strong>en</strong>te autónoma, si se<br />
ha producido un cambio de subred que origine el inicio del proceso de<br />
handover L3.<br />
Como se estudiará <strong>en</strong> el sigui<strong>en</strong>te punto, reci<strong>en</strong>tem<strong>en</strong>te han<br />
aparecido distintos trabajos [ELM02], [KOO02] (ambos catalogados como<br />
‘Work in Progress’) que int<strong>en</strong>tan disminuir la lat<strong>en</strong>cia del proceso de<br />
handover de nivel de red, utilizando información sobre el estado <strong>en</strong> que se<br />
<strong>en</strong>cu<strong>en</strong>tra el handover L2.<br />
Para mejorar la cooperación de los procesos de handover a nivel L2<br />
y L3 <strong>en</strong> [YEG02] (‘Work in Progress’) se ha definido el concepto de ‘trigger’.<br />
Éste puede <strong>en</strong>t<strong>en</strong>derse como una abstracción de una notificación desde el<br />
nivel dos (L2), que indica que cierto ev<strong>en</strong>to ha ocurrido o se va a producir.<br />
Estos triggers no están asociados a un nivel de <strong>en</strong>lace <strong>en</strong> concreto, sino<br />
que se basan <strong>en</strong> la t<strong>ip</strong>o de información que puede estar disponible <strong>en</strong> la<br />
mayoría de los protocolos de <strong>en</strong>lace radio.<br />
Podemos indicar tres t<strong>ip</strong>os de información que están involucradas<br />
<strong>en</strong> la definición de un trigger L2:<br />
• El ev<strong>en</strong>to que causa que el trigger se lance.<br />
• La <strong>en</strong>tidad IP que recibirá la señalización.<br />
• Los parámetros <strong>en</strong>tregados con el trigger.<br />
La <strong>en</strong>tidad IP que recibirá el trigger dep<strong>en</strong>derá del protocolo de<br />
<strong>movilidad</strong> IP particular que estemos utilizando. En protocolos <strong>basado</strong>s <strong>en</strong><br />
127
Proceso de Handover <strong>en</strong> redes IP<br />
Mobile IP estas <strong>en</strong>tidades podrían ser tanto el nodo móvil como uno de los<br />
Foreign Ag<strong>en</strong>t implicados.<br />
Dos ejemplos de trigger podrían ser el que indica que se ha<br />
establecido un <strong>en</strong>lace L2, y el que indica que el <strong>en</strong>lace L2 se ha<br />
desmantelado. Así la recepción del trigger de ‘Enlace L2 Establecido’ podría<br />
forzar al protocolo Mobile IP de un nodo móvil a <strong>en</strong>viar un m<strong>en</strong>saje Ag<strong>en</strong>t<br />
Solicitation [RFC 3344]. De esta manera se reduce el tiempo de detección<br />
de movimi<strong>en</strong>to, T move-detect , estudiado <strong>en</strong> el punto 4.2.<br />
Otro ev<strong>en</strong>to para el que se ha definido un trigger es la inmin<strong>en</strong>cia<br />
de la realización de un handover L2, que puede indicarse tanto <strong>en</strong> el nodo<br />
móvil como <strong>en</strong> alguno de los Foreign Ag<strong>en</strong>t involucrados, bi<strong>en</strong> el nuevo FA<br />
(nFA) o bi<strong>en</strong> el antiguo (oFA)<br />
En la tabla 4.1 se muestra lista con los triggers definidos con los<br />
que se trabaja hasta este mom<strong>en</strong>to. En la tabla se especifica una<br />
descr<strong>ip</strong>ción del trigger, el ev<strong>en</strong>to del handover L2 que causa el lanzami<strong>en</strong>to<br />
del mismo, que <strong>en</strong>tidades pued<strong>en</strong> recibir el trigger y los parámetros que se<br />
<strong>en</strong>tregan.<br />
El receptor del trigger sería el protocolo de <strong>movilidad</strong> de nivel 3 del<br />
propio nodo IP, realizándose la comunicación por mecanismos internos.<br />
Sin embargo, y como se estudió <strong>en</strong> el punto 3.2, es posible que el nodo no<br />
t<strong>en</strong>ga funcionalidad de nivel dos inalámbrico, por ejemplo un Foreign<br />
Ag<strong>en</strong>t que no ti<strong>en</strong>e directam<strong>en</strong>te interfaz inalámbrico y que se conecta con<br />
un conjunto de Puntos de Acceso (figura 3.1). En este caso será necesario<br />
un protocolo que transmita el triggers desde el nodo donde se produce el<br />
handover L2 hasta el nodo IP donde se sitúa el protocolo de <strong>movilidad</strong> L3<br />
implicado. En [YEG02b] (‘Work in Progress’) se está trabajando <strong>en</strong> un<br />
protocolo <strong>basado</strong> <strong>en</strong> una arquitectura cli<strong>en</strong>te servidor sobre UDP para el<br />
<strong>en</strong>vío de estos triggers L2.<br />
128
Proceso de Handover <strong>en</strong> redes IP<br />
L2 Trigger Ev<strong>en</strong>to Receptor Parámetros<br />
Link Up<br />
(L2-LU)<br />
Se ha establecido <strong>en</strong><br />
<strong>en</strong>lace L2<br />
MN<br />
nFA<br />
nFA -> Dirección L2<br />
del MN<br />
MN -> Dirección del<br />
nFA.<br />
Link Down<br />
(L2-LD)<br />
Se ha desmantelado<br />
un <strong>en</strong>lace L2<br />
oFA<br />
Dirección L2 del MN<br />
Source Trigger<br />
(L2-ST)<br />
Va a producirse un<br />
handover L2<br />
oFA<br />
Dirección L2 del nFA<br />
que puede ser<br />
traducida a una<br />
dirección IP .<br />
Dirección L2 del MN<br />
Target Trigger<br />
(L2-TT)<br />
Va a producirse un<br />
handover L2<br />
nFA<br />
Dirección L2 del oFA<br />
que puede ser<br />
traducida a una<br />
dirección IP.<br />
Dirección L2 del MN<br />
Mobile Trigger<br />
(L2-MT)<br />
Va a producirse un<br />
handover L2<br />
MN<br />
Dirección L2 del nFA<br />
que puede ser<br />
traducida a una<br />
dirección IP<br />
Tabla 4.1 Triggers L2<br />
Podemos estudiar como se implem<strong>en</strong>tarían los triggers <strong>en</strong> una red<br />
real tomando como ejemplo las redes de área local inalámbricas [IEEE<br />
802.11]. El protocolo dispone de una trama de gestión d<strong>en</strong>ominada<br />
‘Reasociación_petición’. Esta trama la <strong>en</strong>vía un MN cuando desea cambiar<br />
su asociación de un AP a otro nuevo. El nodo móvil determina que un<br />
nuevo Punto de Acceso está disponible utilizando las tramas de<br />
señalización ‘beacon’ <strong>en</strong>viadas por éste. El m<strong>en</strong>saje de reasociación<br />
conti<strong>en</strong>e la dirección física del AP actual y la del nodo móvil, y es <strong>en</strong>viada a<br />
la dirección del nuevo AP deseado.<br />
129
Proceso de Handover <strong>en</strong> redes IP<br />
Una vez recibida la trama, el nuevo AP determina si el nodo puede<br />
asociarse y contesta con una trama de ‘Reasociación_respuesta’ aceptando<br />
o d<strong>en</strong>egando la petición.<br />
Los m<strong>en</strong>sajes de reasociación conti<strong>en</strong><strong>en</strong> sufici<strong>en</strong>te información para<br />
la implem<strong>en</strong>tación de los sigui<strong>en</strong>tes triggers.<br />
• Establecimi<strong>en</strong>to de <strong>en</strong>lace, Link Up: Cuando el driver 802.11 del<br />
MN recibe la trama de confirmación de la reasociación puede<br />
<strong>en</strong>tregar este trigger al Mobile IP (o a un ‘demonio’ que se comunica<br />
con el protocolo de red y está monitorizando el driver) cont<strong>en</strong>i<strong>en</strong>do<br />
la dirección física del nuevo AP. La recepción de este trigger forzaría<br />
al <strong>en</strong>vío de un m<strong>en</strong>saje ‘Ag<strong>en</strong>t Solicitation’ [RFC 3344].<br />
• Cuando el AP determina que puede <strong>en</strong>viar una confirmación<br />
positiva al MN, puede g<strong>en</strong>erar un trigger Link UP dirigido al<br />
protocolo de <strong>movilidad</strong> IP del nFA con las direcciones físicas del MN<br />
y del AP anterior. Si el AP está actuando como un pu<strong>en</strong>te<br />
transpar<strong>en</strong>te será necesario un protocolo para <strong>en</strong>viar el trigger<br />
hasta el router de acceso (que conti<strong>en</strong>e el FA). Esto puede realizarse<br />
bi<strong>en</strong> añadi<strong>en</strong>do prestaciones al protocolo IAPP (InterAccess Point<br />
Protocol) [IEEE 802.11f], que actualm<strong>en</strong>te se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong><br />
desarrollo, o bi<strong>en</strong> mediante la creación de un protocolo específico<br />
como se com<strong>en</strong>tó anteriorm<strong>en</strong>te.<br />
4.4 SOLUCIONES EXISTENTES DE HANDOVER EN<br />
SISTEMAS DE MOVILIDAD IP<br />
En el punto 2.3 se estudió el protocolo de <strong>movilidad</strong> Mobile IP (MIP).<br />
La necesidad de realizar un registro con el Home Ag<strong>en</strong>t cada vez que el<br />
nodo móvil cambia de red hace que la lat<strong>en</strong>cia del proceso de handover<br />
aum<strong>en</strong>te hasta cotas inaceptables <strong>en</strong> aplicaciones de tiempo real, como<br />
videoconfer<strong>en</strong>cias o tecnologías de VoIP. Con el fin de disminuir este<br />
tiempo se estudió las v<strong>en</strong>tajas de implem<strong>en</strong>tar sistemas de micro<strong>movilidad</strong><br />
que reduc<strong>en</strong> la lat<strong>en</strong>cia, la pérdida de paquetes, y la sobrecarga<br />
de señalización durante el handover.<br />
130
Proceso de Handover <strong>en</strong> redes IP<br />
El fin último es mejorar las prestaciones del proceso de handover.<br />
En este s<strong>en</strong>tido <strong>en</strong> [MAN02] ('Work in Progress') se distingu<strong>en</strong> los sigui<strong>en</strong>tes<br />
términos:<br />
• Handover Suave (Smooth Handover): Proceso de handover <strong>en</strong> el<br />
que el objetivo es minimizar la pérdida de paquetes, sin una<br />
preocupación explícita del retardo <strong>en</strong> la <strong>en</strong>trega de los paquetes.<br />
• Handover Rápido (Fast Handover): Proceso de handover <strong>en</strong> el que<br />
su princ<strong>ip</strong>al motivación es la <strong>en</strong>trega de paquetes con retardo<br />
mínimo sin interés explícito <strong>en</strong> la pérdida de paquetes.<br />
• Handover Sin Degradación (Seamless Handover): Handover <strong>en</strong> el<br />
que no se produce cambio <strong>en</strong> capacidad de servicio, seguridad o<br />
calidad. En la práctica siempre se producirá una cierta<br />
degradación, por lo que una definición realista sería la de un<br />
handover <strong>en</strong> el que las aplicaciones, protocolos o usuarios finales<br />
no detectaran cambios que afectara a su funcionami<strong>en</strong>to normal.<br />
Con el fin de <strong>en</strong>marcar las soluciones al proceso de handover que<br />
ofrece el protocolo de micro-<strong>movilidad</strong> <strong>multicast</strong> pres<strong>en</strong>tado, a<br />
continuación se van a com<strong>en</strong>tar brevem<strong>en</strong>te los princ<strong>ip</strong>ales trabajos<br />
realizados <strong>en</strong> este ámbito.<br />
Debido a la variedad de trabajos publicados <strong>en</strong> los últimos años<br />
nos vamos a c<strong>en</strong>trar <strong>en</strong> las soluciones más relacionadas de alguna manera<br />
con nuestro protocolo. Así hemos resaltado cuatro grupos, aunque las<br />
soluciones que ofrec<strong>en</strong> no son excluy<strong>en</strong>tes: <strong>en</strong> el punto 4.4.1 se com<strong>en</strong>ta<br />
algunas soluciones que se c<strong>en</strong>tran <strong>en</strong> conseguir handovers suaves que<br />
minimizan las perdidas de datos; posteriorm<strong>en</strong>te <strong>en</strong> 4.4.2 estudiaremos<br />
alguna de las propuestas que se basan <strong>en</strong> la utilización de triggers L2; <strong>en</strong><br />
el punto 4.4.3 estudiaremos las soluciones que se ofrec<strong>en</strong> <strong>en</strong> los distintos<br />
sistemas de micro-<strong>movilidad</strong> que se pres<strong>en</strong>taron <strong>en</strong> el tema 2.3; y<br />
finalizaremos com<strong>en</strong>tando los procesos de handover que se basan <strong>en</strong> la<br />
utilización de la transmisión <strong>multicast</strong>.<br />
131
Proceso de Handover <strong>en</strong> redes IP<br />
4.4.1 Soluciones para Handovers suaves<br />
Se han propuesto varias soluciones para lograr un handover suave<br />
que minimice la pérdida de paquetes durante el proceso. El protocolo<br />
Mobile IP original no contempla una notificación del MN al oFA. Así, los<br />
paquetes interceptados por el HA tras el nuevo registro serán <strong>en</strong>viados al<br />
nFA y se asume que el nivel superior solucionará el problema de la pérdida<br />
de los paquetes que hasta ese mom<strong>en</strong>to van <strong>en</strong> tránsito hacia el oFA.<br />
El princ<strong>ip</strong>al trabajo realizado para solucionar este tema es [PER01]<br />
('Work in Progress') <strong>en</strong> el que, además de definir los princ<strong>ip</strong>ios de la<br />
optimización de ruta (punto 2.3.6), se detalla los m<strong>en</strong>sajes y los<br />
mecanismos necesarios para lograr un handover suave utilizando como<br />
base el protocolo Mobile IP.<br />
Como la gran mayoría de las soluciones se basa <strong>en</strong> una<br />
comunicación <strong>en</strong>tre los dos Foreign Ag<strong>en</strong>t implicados, de manera que el<br />
oFA le transmite al nFA los datagramas que no ha podido <strong>en</strong>viar el nodo<br />
móvil por haberse cambiado de subred. Además está comunicación<br />
permitirá la liberación inmediata de los recursos consumidos por el nodo<br />
móvil <strong>en</strong> el FA antiguo, sin t<strong>en</strong>er que esperar que expire el tiempo de vida<br />
del m<strong>en</strong>saje de registro.<br />
La comunicación se realiza bajo petición del MN, empleando para<br />
ello una nueva ext<strong>en</strong>sión <strong>en</strong> el m<strong>en</strong>saje de registro. En nuevo FA le <strong>en</strong>viará<br />
un m<strong>en</strong>saje ‘M<strong>en</strong>saje de Actualización de Información’ (Binding Update) al<br />
otro FA implicado, con el fin de que le transmita los paquetes dirigidos<br />
hacia el MN que aún están p<strong>en</strong>di<strong>en</strong>tes o los que llegu<strong>en</strong> <strong>en</strong> un futuro.<br />
Aún utilizando esta solución, los datagramas que llegu<strong>en</strong> al oFA<br />
antes que la notificación de re<strong>en</strong>vío, y que ya han sido <strong>en</strong>viados por el<br />
<strong>en</strong>lace inalámbrico, se perderán. Está pérdida será tanto más importante<br />
cuanto mayor sea el tiempo <strong>en</strong> el que el MN no ti<strong>en</strong>e contacto con ningún<br />
FA, debido princ<strong>ip</strong>alm<strong>en</strong>te a que se está produci<strong>en</strong>do el handover L2, y al<br />
tiempo que le cuesta al MN detectar el nuevo FA utilizando los conocidos<br />
m<strong>en</strong>sajes de aviso ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’.<br />
132
Proceso de Handover <strong>en</strong> redes IP<br />
La solución que se ha aportado <strong>en</strong> algunos trabajos [PER99] es el<br />
utilizar algún mecanismo de almac<strong>en</strong>ami<strong>en</strong>to de los últimos paquetes que<br />
el FA <strong>en</strong>vía al nodo móvil. Así, <strong>en</strong> el caso de recibir una notificación de<br />
re<strong>en</strong>vío por parte del nFA, no sólo <strong>en</strong>viaría las tramas que se reciban a<br />
partir de ese instante, sino que también se <strong>en</strong>viarían las previam<strong>en</strong>te<br />
almac<strong>en</strong>adas. Con una correcta configuración de estos buffers se lograría<br />
evitar la pérdida de paquetes durante el handover.<br />
El mayor problema que ti<strong>en</strong>e este mecanismo de almac<strong>en</strong>ami<strong>en</strong>to<br />
de paquetes, aparte de los recursos necesarios, es la duplicación de<br />
paquetes <strong>en</strong> el receptor (<strong>en</strong> este caso el MN). Aunque es posible la<br />
duplicación de paquetes <strong>en</strong> redes IP, las implem<strong>en</strong>taciones de TCP asum<strong>en</strong><br />
que la recepción de reconocimi<strong>en</strong>tos TCP duplicados es debida a una<br />
pérdida de paquetes y, por tanto, se traducirá <strong>en</strong> el lanzami<strong>en</strong>to de los<br />
mecanismos de control de congestión [JAC88]. Más concretam<strong>en</strong>te, <strong>en</strong> las<br />
primeras versiones del protocolos TCP (TCP Tahoe) la recepción de tres<br />
ACK iguales configuraban la v<strong>en</strong>tana de congestión con tamaño uno e<br />
iniciaban el mecanismo conocido como ‘inicio l<strong>en</strong>to’. Otras versiones más<br />
modernas, como ‘TCP R<strong>en</strong>o’, lo sustituy<strong>en</strong> por una reducción de la v<strong>en</strong>tana<br />
de congestión a la mitad y la ejecución del mecanismo de ‘recuperación<br />
rápida’. Han aparecido distintas modificaciones posteriores, [RFC 2582],<br />
pero todas las soluciones afectan, de alguna medida, a las prestaciones del<br />
protocolo. El problema es que la duplicación se produce por el sistema de<br />
<strong>movilidad</strong> y no por una congestión real de la red.<br />
Durante los últimos años se han propuesto numerosas soluciones<br />
que modifican <strong>en</strong> mayor o m<strong>en</strong>or medida el protocolo TCP para adaptarlo a<br />
los requerimi<strong>en</strong>tos de <strong>movilidad</strong> (un ejemplo sería [YAV94]). Sin embargo<br />
está opción provoca la necesidad de modificar todos los nodos de Internet,<br />
lo que no es factible.<br />
Un mecanismo mucho más s<strong>en</strong>cillo para evitar los problemas<br />
ocasionados por la duplicación de paquetes debido al almac<strong>en</strong>ami<strong>en</strong>to<br />
sería el diseñar un mecanismo que evitara esa transmisión duplicada. En<br />
algunos trabajos se propone que el FA almac<strong>en</strong>e, junto con el datagrama,<br />
una id<strong>en</strong>tificación del mismo. De esta manera cuando el MN solicita el<br />
133
Proceso de Handover <strong>en</strong> redes IP<br />
handover suave incluye los id<strong>en</strong>tificativos de los últimos datagramas<br />
recibidos, con el fin de que esa información se haga llegar al oFA y éste no<br />
los re<strong>en</strong>víe por duplicado. En [PER99] se propone que el id<strong>en</strong>tificativo sea<br />
la dirección IP fu<strong>en</strong>te del paquete junto con el campo de id<strong>en</strong>tificación de<br />
IP (utilizado originalm<strong>en</strong>te para la fragm<strong>en</strong>tación). Una opción similar se<br />
detalla <strong>en</strong> [BAL95].<br />
4.4.2 Handover de baja lat<strong>en</strong>cia utilizando triggers<br />
En el punto 4.3 se estudió como la implem<strong>en</strong>tación de triggers L2<br />
favorecía el desarrollo de mecanismos de handover con baja lat<strong>en</strong>cia. El<br />
princ<strong>ip</strong>al trabajo relacionado <strong>en</strong> este campo es [ELM02], titulado<br />
'Handovers de baja lat<strong>en</strong>cia <strong>en</strong> Mobile IPv4' y actualm<strong>en</strong>te catalogado como<br />
‘Work in Progress’. Este trabajo es el resultado de la integración de<br />
numerosos trabajos realizados hasta la fecha (como por ejemplo [ELM00],<br />
[KEM00] o [DOM01] ) y <strong>en</strong> él se describ<strong>en</strong> dos soluciones que disminuy<strong>en</strong><br />
la lat<strong>en</strong>cia del handover.<br />
La primera solución se d<strong>en</strong>omina handover pre-registro y se basa<br />
<strong>en</strong> permitir al nodo móvil comunicarse con el nFA (nuevo Foreign Ag<strong>en</strong>t)<br />
cuando todavía se <strong>en</strong>cu<strong>en</strong>tra conectado al oFA.<br />
Una segunda solución pres<strong>en</strong>tada se d<strong>en</strong>omina handover postregistro<br />
y permite la <strong>en</strong>trega de datos a un nodo situado <strong>en</strong> un nFA antes<br />
de que se realice el proceso de registro. Esto permitirá una continuidad <strong>en</strong><br />
el servicio ofrecido mi<strong>en</strong>tras se procesa el handover <strong>en</strong> la red. Finalm<strong>en</strong>te<br />
también se pres<strong>en</strong>ta una combinación de ambos métodos.<br />
Handover Pre-Registro.<br />
Este método permite al nodo iniciar un handover a nivel de red<br />
antes de que concluya el handover de nivel dos. El proceso puede ser<br />
iniciado por la red o por el nodo móvil y se basa <strong>en</strong> el handover original del<br />
protocolo Mobile IP, de manera que no se propon<strong>en</strong> nuevos m<strong>en</strong>sajes si<br />
134
Proceso de Handover <strong>en</strong> redes IP<br />
exceptuamos una ext<strong>en</strong>sión al m<strong>en</strong>saje ‘Ag<strong>en</strong>t Solicitation’. La<br />
compatibilidad con el protocolo original es una v<strong>en</strong>taja, pues nos va a<br />
permitir utilizar este mecanismo <strong>en</strong> conjunción con otras soluciones como<br />
los sistemas de micro-<strong>movilidad</strong> jerárquicos.<br />
El funcionami<strong>en</strong>to básicam<strong>en</strong>te consiste <strong>en</strong> comunicarse con el<br />
futuro FA mediante el FA actual, de manera que pueda iniciarse el proceso<br />
de handover de nivel tres antes de que ocurra el de nivel dos. A<br />
continuación se resume el mecanismo <strong>en</strong> una serie de puntos:<br />
• Previam<strong>en</strong>te a que comi<strong>en</strong>ce el proceso de handover los difer<strong>en</strong>tes<br />
Foreign Ag<strong>en</strong>ts se intercambian m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’,<br />
solicitados mediante m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Solicitation’ y almac<strong>en</strong>ados<br />
temporalm<strong>en</strong>te <strong>en</strong> memoria.<br />
• El nodo móvil puede recibir un trigger L2 (‘MT-L2’ de la tabla 4.1)<br />
indicando que se va a producir, <strong>en</strong> un futuro cercano, un handover<br />
a nivel dos. En ese instante el MN <strong>en</strong>vía un m<strong>en</strong>saje del t<strong>ip</strong>o ‘Proxy<br />
Ag<strong>en</strong>t Solicitation’ al FA con el que manti<strong>en</strong>e aún la conexión (oFA).<br />
Este m<strong>en</strong>saje es idéntico al tradicional excepto por una ext<strong>en</strong>sión<br />
que indica que la solicitud es para un FA <strong>en</strong> particular (nFA).<br />
• En respuesta a esta petición el oFA <strong>en</strong>vía el m<strong>en</strong>saje ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t’ del nFA almac<strong>en</strong>ado. Este m<strong>en</strong>saje podría ser<br />
<strong>en</strong>viado sin la necesidad de una petición previa <strong>en</strong> el caso <strong>en</strong> que el<br />
proceso de handover hubiera sido iniciado por el oFA (vía ‘ST-L2’<br />
trigger) o incluso por el nFA (<strong>en</strong> este caso se utiliza un túnel).<br />
• El nodo móvil detecta si es necesario un handover de nivel 3<br />
estudiando el m<strong>en</strong>saje del nFA (como <strong>en</strong> el protocolo original). En<br />
caso afirmativo se <strong>en</strong>vía el ‘Registration Request’ definido <strong>en</strong> [RFC<br />
3344]. Este m<strong>en</strong>saje deberá ser <strong>en</strong>caminado vía oFA puesto que el<br />
nodo móvil aún no ti<strong>en</strong>e una conexión directa con nFA.<br />
• El m<strong>en</strong>saje de respuesta al registro ‘Registration Reply’ que <strong>en</strong>vía el<br />
Home Ag<strong>en</strong>t lo recibirá el nFA (ya que es éste el FA implicado <strong>en</strong> el<br />
nuevo registro), quién lo transmitirá al MN tan pronto se complete<br />
el handover L2 (trigger ‘L2-UP’).<br />
135
Proceso de Handover <strong>en</strong> redes IP<br />
Como puede observarse el tiempo de antelación con el que se<br />
produce el trigger, que indica de forma antic<strong>ip</strong>ada que se va a producirse<br />
un handover L2, es importante para que el proceso de handover logre el<br />
objetivo de baja lat<strong>en</strong>cia. En el caso óptimo, el primer paquete redirigido<br />
desde el HA hacia el nFA alcanzará al MN <strong>en</strong> el instante <strong>en</strong> que se<br />
completa el handover L2, lográndose que no se produzcan interrupciones<br />
debido al handover L3. Para lograr este objetivo pued<strong>en</strong> ser necesarias<br />
técnicas adicionales a nivel 2, como almac<strong>en</strong>ami<strong>en</strong>to <strong>en</strong> buffers o<br />
transmisión simultánea, aunque <strong>en</strong> un princ<strong>ip</strong>io quedan fuera de estudio.<br />
Por último, serían necesarias consideraciones adicionales para<br />
lograr handovers suaves, que elimin<strong>en</strong> la pérdida de paquetes (desde el HA<br />
al oFA) mi<strong>en</strong>tras el MN realiza el proceso de handover. Estas quedan<br />
también fuera de estudio.<br />
En la figura 4.1 se muestra un diagrama que resume el proceso de<br />
pre-registro cuando el handover es iniciado por el MN. Los handovers<br />
iniciados por la red (tanto por el oFA como por el nFA) son similares y<br />
pued<strong>en</strong> <strong>en</strong>contrarse <strong>en</strong> la bibliografía.<br />
MN oFA nFA HA<br />
L2 Trigger<br />
Proxy Ag<strong>en</strong>t Solicitation<br />
Proxy Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t<br />
Registration Request<br />
Registration Request<br />
Registration Reply<br />
Registration Reply<br />
Figura 4.1 Proceso de handover iniciado por el MN.<br />
136
Proceso de Handover <strong>en</strong> redes IP<br />
Handover Post-Registro<br />
El método de handover post-registro propone una ext<strong>en</strong>sión al<br />
protocolo Mobile IP que, utilizando un túnel <strong>en</strong>tre el oFA y el nFA, permite<br />
al MN seguir utilizando el oFA mi<strong>en</strong>tras se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona cubierta<br />
por el nFA. De esta manera el MN puede ir cambiando el punto de acceso<br />
con la red sin necesidad de realizar un nuevo registro con el Home Ag<strong>en</strong>t,<br />
lo que minimiza el impacto del handover <strong>en</strong> aplicaciones con restricciones<br />
temporales.<br />
Una vez el nodo móvil realiza un registro con un Foreign Ag<strong>en</strong>t<br />
(oFA), éste se convierte <strong>en</strong> un punto ancla, aFA. Así, cuado el nodo se<br />
mueve de un oFA hacia un nFA, el nodo móvil aplaza la realización de un<br />
handover L3, mant<strong>en</strong>i<strong>en</strong>do el aFA y utilizando un túnel para recibir los<br />
datos desde el m<strong>en</strong>cionado aFA. Podemos resumir el proceso <strong>en</strong> los<br />
sigui<strong>en</strong>tes puntos:<br />
• El oFA, o el nFA, recib<strong>en</strong> un trigger L2 (ver punto 4.3) informando<br />
que el nodo móvil va a moverse de un FA a otro.<br />
• El Foreign Ag<strong>en</strong>t (FA) que recibe el trigger estudiará el cont<strong>en</strong>ido<br />
del mismo, para averiguar el otro FA implicado <strong>en</strong> el proceso, y le<br />
<strong>en</strong>viará un m<strong>en</strong>saje d<strong>en</strong>ominado ‘Solicitud de Handover’ (HRqst).<br />
La información que se incluye <strong>en</strong> este m<strong>en</strong>saje <strong>en</strong>viado difiere<br />
ligeram<strong>en</strong>te dep<strong>en</strong>di<strong>en</strong>do de quién es el FA que lo <strong>en</strong>vía (oFA o<br />
nFA).<br />
• El FA que recibe el m<strong>en</strong>saje contesta utilizando un nuevo m<strong>en</strong>saje<br />
d<strong>en</strong>ominado ‘Respuesta de Handover’ (HRply).<br />
• Así, cuando el oFA recibe el trigger L2-LD indicando la desconexión<br />
del nodo comi<strong>en</strong>za a dirigir los paquetes a través del túnel hacia el<br />
nFA.<br />
• Cuando el nFA recibe un trigger L2-LU, indicando el<br />
establecimi<strong>en</strong>to de una conexión con el MN, comi<strong>en</strong>za a <strong>en</strong>tregar<br />
los paquetes recibidos hacia el MN. También se va a <strong>en</strong>cargar de<br />
<strong>en</strong>caminar los paquetes recibidos desde el nodo móvil utilizando<br />
137
Proceso de Handover <strong>en</strong> redes IP<br />
mecanismos normales de <strong>en</strong>caminami<strong>en</strong>to, aunque también está<br />
previsto la utilización de un túnel inverso hacia el oFA o el HA.<br />
• Finalm<strong>en</strong>te cuando el MN recibe un trigger L2-LU de<br />
establecimi<strong>en</strong>to de la conexión L2 podría iniciar el proceso de<br />
registro solicitando un ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ al nFA.<br />
Cuando los triggers L2 se produc<strong>en</strong> de manera óptima el túnel se<br />
establece al comi<strong>en</strong>zo del handover L2 y la transmisión de datos se iniciará<br />
inmediatam<strong>en</strong>te se conoce la caída del <strong>en</strong>lace. Con el fin de proporcionar<br />
un handover suave <strong>en</strong> algunas situaciones sería necesario incorporar<br />
algún mecanismo de retransmisión de datos adicional que actualm<strong>en</strong>te no<br />
está definido.<br />
Se ha definido un mecanismo similar para realizar un handover<br />
cuando el nodo móvil ya ti<strong>en</strong>e establecido un túnel desde el aFA y se<br />
mueve a un tercer FA sin haber realizado aún el proceso de registro con el<br />
HA. La solución incluye un nuevo m<strong>en</strong>saje d<strong>en</strong>ominado ‘Handover a un<br />
tercero’ (HTT) que se intercambian los FA afectados. El método exacto de<br />
funcionami<strong>en</strong>to puede <strong>en</strong>contrarse <strong>en</strong> la bibliografía.<br />
Adicionalm<strong>en</strong>te también se define un mecanismo conjunto que<br />
permite la utilización combinada de los dos mecanismos de handover<br />
com<strong>en</strong>tados (pre-handover y post-handover), así como procesos para<br />
solucionar posibles errores de señalización durante el handover.<br />
Por último indicar que la utilización de triggers es también la<br />
solución adoptada <strong>en</strong> los trabajos que se están realizando actualm<strong>en</strong>te<br />
para de acortar el tiempo de handover <strong>en</strong> el protocolo Mobile IPv6,<br />
[KOO02].<br />
138
Proceso de Handover <strong>en</strong> redes IP<br />
4.4.3 Handovers <strong>en</strong> sistemas de micro-<strong>movilidad</strong><br />
Previam<strong>en</strong>te se estudió como la división de la red <strong>en</strong> dominios<br />
permite implem<strong>en</strong>tar las soluciones de <strong>movilidad</strong> <strong>en</strong> dos niveles, lo que se<br />
traduce <strong>en</strong> una mejora de prestaciones cuando se produc<strong>en</strong> handovers<br />
d<strong>en</strong>tro de un dominio. Aparec<strong>en</strong> así los protocolos de micro-<strong>movilidad</strong> cuyo<br />
fin es gestionar esta <strong>movilidad</strong> intra-dominio de una manera local,<br />
produci<strong>en</strong>do m<strong>en</strong>ores tiempos de lat<strong>en</strong>cia.<br />
En el punto 2.4 se realizó una s<strong>en</strong>cilla clasificación de estas<br />
soluciones distingui<strong>en</strong>do los esquemas con ag<strong>en</strong>tes de <strong>movilidad</strong><br />
jerárquicos y esquemas de <strong>en</strong>caminami<strong>en</strong>to <strong>basado</strong> <strong>en</strong> host (HBR).<br />
Los esquemas con ag<strong>en</strong>tes de <strong>movilidad</strong> jerárquicos no suel<strong>en</strong><br />
aportar soluciones específicas al proceso handover. Estos esquemas<br />
permit<strong>en</strong> la utilización d<strong>en</strong>tro del dominio de cualquier solución<br />
compatible con el protocolo Mobile IP y, al describir posibles mejoras <strong>en</strong> las<br />
prestaciones del handover, hac<strong>en</strong> refer<strong>en</strong>cia a algoritmos ya exist<strong>en</strong>tes,<br />
como las soluciones pres<strong>en</strong>tadas <strong>en</strong> los puntos 4.4.1 y 4.4.2.<br />
Por otro lado t<strong>en</strong>emos los esquemas HBR que, al utilizar<br />
mecanismos de <strong>en</strong>rutami<strong>en</strong>to propios, ofrec<strong>en</strong> soluciones novedosas. Estos<br />
esquemas HBR van a ser, por lo g<strong>en</strong>eral, muy rápidos, ya que el número<br />
de nodos implicados <strong>en</strong> el mismo es pequeño. En la figura 4.2 puede<br />
observarse un handover producido por el movimi<strong>en</strong>to del MN que cambia<br />
de la estación base 1 (BS1) a la estación base 2 (BS2). El nodo marcado<br />
como X se d<strong>en</strong>omina Nodo de Cruce y puede definirse como el nodo más<br />
bajo que es común <strong>en</strong>tre las dos rutas de las BS al Router Raíz (RR) del<br />
dominio.<br />
G<strong>en</strong>éricam<strong>en</strong>te, <strong>en</strong> los esquemas HBR el handover comi<strong>en</strong>za con<br />
un m<strong>en</strong>saje de actualización de ruta que es <strong>en</strong>viado por el nodo móvil (MN)<br />
a través de la nueva estación base. Este m<strong>en</strong>saje viaja hacia el RR y logra<br />
que todos los routers situados por debajo del Nodo de Cruce introduzcan<br />
una nueva <strong>en</strong>trada <strong>en</strong> su tabla de <strong>en</strong>rutami<strong>en</strong>to por host relativa al MN, ya<br />
que estos no ti<strong>en</strong><strong>en</strong> información del mismo. El Nodo de Cruce ya posee<br />
139
Proceso de Handover <strong>en</strong> redes IP<br />
una <strong>en</strong>trada para ese nodo y simplem<strong>en</strong>te modifica el interfaz para que, a<br />
partir de ese instante, los paquetes se <strong>en</strong>camin<strong>en</strong> hacia la nueva BS2. El<br />
paquete de actualización puede seguir hacia el RR pero ya no modificará<br />
ninguna tabla y no afectará a las prestaciones del handover.<br />
Macro-Movilidad<br />
Router Raíz (RR)<br />
Dominio<br />
HBR<br />
Router<br />
Estación Base (BS)<br />
X<br />
Nodo móvil (MN)<br />
BS1<br />
BS2<br />
Figura 4.2 Handover <strong>en</strong> un sistema de micro-<strong>movilidad</strong> HBR.<br />
A pesar de que el handover <strong>en</strong> los sistemas de micro-<strong>movilidad</strong><br />
HBR es rápido, debido a que las actualizaciones se realizan a nivel local, es<br />
posible que se produzcan pérdidas de paquetes durante el mismo. Para<br />
eliminar estas pérdidas de paquetes y lograr un handover sin degradación<br />
(Seamless Handover) los difer<strong>en</strong>tes sistemas de micro<strong>movilidad</strong> han<br />
propuesto distintos esquemas.<br />
A continuación se van a pres<strong>en</strong>tar, muy brevem<strong>en</strong>te, las propuestas<br />
de los sistemas Cellular IP y HAWAII (ver puntos 2.4.1 y 2.4.2). Estos dos<br />
sistemas son los que más han trabajado el mecanismo de handover, y<br />
también los más refer<strong>en</strong>ciados <strong>en</strong> la actualidad. En el capítulo sigui<strong>en</strong>te se<br />
realizará un estudio de las prestaciones de los mecanismos de handover<br />
pres<strong>en</strong>tados a continuación, que servirá como base para analizar las<br />
prestaciones de los mecanismos propuestos <strong>en</strong> el capítulo 6.<br />
140
Proceso de Handover <strong>en</strong> redes IP<br />
El protocolo Cellular IP [CAM00] ofrece tres algoritmos difer<strong>en</strong>tes<br />
para realizar el proceso de handover. Una primera solución, muy s<strong>en</strong>cilla,<br />
es el d<strong>en</strong>ominado Handover Duro (Hard Handover) donde no se int<strong>en</strong>ta<br />
garantizar la <strong>en</strong>trega de todos los paquetes. En este caso el nodo móvil<br />
escucha las señales de anuncio (beacons) de las distintas estaciones base<br />
y, <strong>en</strong> función de la pot<strong>en</strong>cia, decide cuando realizar el handover. Éste se<br />
traduce <strong>en</strong> el <strong>en</strong>vío de un paquete de actualización de ruta, que se <strong>en</strong>vía a<br />
través de la nueva estación base, y que sirve para crear <strong>en</strong>tradas <strong>en</strong> las<br />
memorias de <strong>en</strong>rutami<strong>en</strong>to de los dispositivos que forman la ruta hacia la<br />
pasarela del dominio.<br />
La segunda solución es un algoritmo adicional que mejora las<br />
prestaciones durante el handover y que se d<strong>en</strong>omina Handover Semi-suave<br />
(Semisoft Handover). Se basa <strong>en</strong> suponer que los nodos móviles pued<strong>en</strong><br />
comunicarse con las dos estaciones base. El nodo móvil, antes de moverse<br />
a una nueva BS, se comunica con ella y le transmite un m<strong>en</strong>saje<br />
indicándole la int<strong>en</strong>ción de cambiarse. Este paquete viaja <strong>en</strong> s<strong>en</strong>tido<br />
asc<strong>en</strong>d<strong>en</strong>te hasta que alcanza el Nodo de Cruce creando <strong>en</strong>tradas <strong>en</strong> las<br />
tablas de <strong>en</strong>rutami<strong>en</strong>to de los elem<strong>en</strong>tos que atraviesa, de manera que se<br />
g<strong>en</strong>era una nueva ruta llegar al nodo móvil. Sin embargo, el Nodo de Cruce<br />
no elimina la <strong>en</strong>trada anterior, de manera que el MN sigue recibi<strong>en</strong>do<br />
paquetes conectado a la BS antigua. Así, tras esperar un cierto tiempo,<br />
para asegurar que la nueva BS ha realizado la conexión, el MN inicia un<br />
handover tradicional. Durante un pequeño intervalo de tiempo las dos<br />
estaciones base recib<strong>en</strong> los paquetes dirigidos hacia el MN, minimizando la<br />
pérdida de los mismos. La figura 4.3 muestra claram<strong>en</strong>te el proceso.<br />
El problema de la solución anterior es que no todas las tecnologías<br />
permit<strong>en</strong> que el MN pueda recibir simultáneam<strong>en</strong>te información de dos<br />
BS. En [SHE01] se propone un tercer mecanismo, d<strong>en</strong>ominado Handover<br />
Indirecto, que permite mejorar las prestaciones aún cuando el nodo móvil<br />
sólo puede comunicarse con una estación. Ahora cuando el móvil decide<br />
realizar el handover <strong>en</strong>vía un paquete especial a la oBS (ya que no puede<br />
comunicarse con la nueva). Este paquete conti<strong>en</strong>e la dirección IP de la<br />
nueva estación base a la que se va mover el nodo móvil, de manera que<br />
puede ser <strong>en</strong>viado hasta ella. La nueve estación, nBS, crea un paquete de<br />
141
Proceso de Handover <strong>en</strong> redes IP<br />
actualización de ruta con la dirección del nodo móvil que se <strong>en</strong>viará hacia<br />
la red de manera similar al Handover Semi-suave. Esta propuesta es<br />
similar al mecanismo de handover de baja lat<strong>en</strong>cia por pre-registro<br />
estudiado <strong>en</strong> 4.4.2.<br />
MN oBS nBS Router Cruce<br />
Datos<br />
Beacon<br />
Paquete Actualización Ruta, S=1<br />
Datos (Copia)<br />
Datos<br />
Paquete Actualización Ruta, S=0<br />
Datos<br />
Figura 4.3 Señalización durante un handover Semi-suave de Cellular IP.<br />
También el protocolo Hawai [RAM99] propone cuatro esquemas<br />
difer<strong>en</strong>tes para establecer la nueva ruta cuando ocurre un handover.<br />
Podemos agrupar estos esquemas <strong>en</strong> dos grandes t<strong>ip</strong>os, basándonos <strong>en</strong><br />
como se realiza la <strong>en</strong>trega de paquetes durante el handover: Un primer<br />
método, que se podría d<strong>en</strong>ominar ‘Por Redireccionami<strong>en</strong>to’ (Forwarding),<br />
consiste <strong>en</strong> retransmitir los paquetes desde la estación base antigua a la<br />
nueva. Aquí se contemplan dos posibilidades MSF y SSF. El segundo<br />
método se d<strong>en</strong>omina esquema ‘Sin Redireccionami<strong>en</strong>to’ (Non Fordwarding),<br />
y consiste <strong>en</strong> que los paquetes son desviados <strong>en</strong> el punto de cruce. En este<br />
142
Proceso de Handover <strong>en</strong> redes IP<br />
caso, y dep<strong>en</strong>di<strong>en</strong>do de si el nodo móvil sólo puede escuchar y transmitir<br />
por una estación base o puede hacerlo con dos estaciones base<br />
simultáneam<strong>en</strong>te, se establec<strong>en</strong> dos mecanismos difer<strong>en</strong>tes, d<strong>en</strong>ominados<br />
MNF y UNF respectivam<strong>en</strong>te.<br />
A continuación se describ<strong>en</strong> brevem<strong>en</strong>te los cuatro esquemas<br />
propuestos <strong>en</strong> la literatura:<br />
• Envío por Múlt<strong>ip</strong>les Flujos (Múlt<strong>ip</strong>le Stream Forwarding, MSF): La<br />
estación base previa recibe un m<strong>en</strong>saje de handover y se comunica con<br />
la nueva para transmitirle los paquetes que pueda t<strong>en</strong>er almac<strong>en</strong>ados.<br />
Utilizando esta solución es posible que algunos paquetes llegu<strong>en</strong><br />
desord<strong>en</strong>ados, pues paquetes previos que redirecciona la BS antigua<br />
pued<strong>en</strong> llegar más tarde que paquetes más modernos que <strong>en</strong>vía el<br />
Nodo de cruce.<br />
• Envío por un Único Flujos (Single Stream Forwarding, SSF): Para<br />
solucionar el problema anterior se define una nueva solución basada<br />
<strong>en</strong> MSF pero más sofisticada. Ahora la BS antigua informa al Nodo de<br />
Cruce que ha acabado de <strong>en</strong>viar las tramas p<strong>en</strong>di<strong>en</strong>tes para que a<br />
partir de ese mom<strong>en</strong>to éste pueda <strong>en</strong>viar también tramas hacia la<br />
nueva BS. Para lograr esto las <strong>en</strong>tradas para el <strong>en</strong>caminami<strong>en</strong>to de los<br />
routers incorporan un campo adicional que indica el interfaz por el que<br />
se recibe el paquete. El resultado práctico es un funcionami<strong>en</strong>to<br />
similar al com<strong>en</strong>tado <strong>en</strong> el punto 4.4.1.<br />
• Transmisión Unicast sin Redireccionami<strong>en</strong>to (Unicast Non-<br />
Forwarding, UNF): Ahora no contempla el re<strong>en</strong>vío de datos <strong>en</strong>tre las<br />
dos BS. La solución minimiza las pérdidas durante el handover, ya que<br />
se plantea para redes como CDMA o WaveLAN <strong>en</strong> las que el MN es<br />
capaz de comunicarse con las dos BS simultáneam<strong>en</strong>te.<br />
Adicionalm<strong>en</strong>te se permite el <strong>en</strong>vío de un m<strong>en</strong>saje a la BS anterior para<br />
indicarle que el nodo móvil ha cambiado de celda.<br />
• Transmisión Multicast sin Redireccionami<strong>en</strong>to (Multicast Non-<br />
Forwarding, MNF): Esta solución resuelve el handover suave<br />
empleando un esquema d<strong>en</strong>ominado ‘dual-cast’ por el que, durante un<br />
143
Proceso de Handover <strong>en</strong> redes IP<br />
breve periodo de tiempo, el Nodo de Cruce transmite los paquetes<br />
dirigidos a al MN a ambas estaciones base.<br />
Para finalizar es interesante com<strong>en</strong>tar uno de los primeros trabajos<br />
que aborda el proceso de handover <strong>en</strong> redes IP es [CAC96], que también se<br />
puede <strong>en</strong>cuadrar <strong>en</strong> los sistemas de micro-<strong>movilidad</strong>. Aquí se pres<strong>en</strong>ta un<br />
mecanismo para el handover a nivel más bajo de la jerarquía (movimi<strong>en</strong>to<br />
del MN <strong>en</strong>tre Estaciones Base de la misma subred y conectadas por una<br />
red cableada rápida), mi<strong>en</strong>tras que se plantea la utilización de Mobile IP<br />
para los niveles más altos de la jerarquía.<br />
El handover propuesto se basa <strong>en</strong> su s<strong>en</strong>cillez y evita la utilización<br />
de mecanismos de handover antic<strong>ip</strong>ados o transmisión <strong>multicast</strong>. Por el<br />
contrario se detalla un intercambio de paquetes <strong>en</strong>tre el nodo móvil (quién<br />
inicia el proceso) y la nueva estación base, y de está con la estación base<br />
anterior. Debido a la simplicidad y a que el handover se produce d<strong>en</strong>tro de<br />
una misma subred se logran retardos muy pequeños. Por último indicar<br />
que se ofrece la posibilidad de lograr un handover suave utilizando una<br />
retransmisión de paquetes utilizando pequeños buffers <strong>en</strong> las estaciones<br />
base.<br />
Conclusiones sobre el handover <strong>en</strong> sistemas de micro-<strong>movilidad</strong><br />
Como se ha com<strong>en</strong>tado los sistemas de micro-<strong>movilidad</strong> ofrec<strong>en</strong><br />
handovers rápidos al afectar solam<strong>en</strong>te a un número limitado de nodos de<br />
la red. Para lograr que se realice de una forma suave, minimizando el<br />
número de paquetes se han ofrecido una serie de soluciones que podemos<br />
clasificar <strong>en</strong> dos grandes grupos. El primero sería los que realizan un<br />
re<strong>en</strong>vío de paquetes, produciéndose una comunicación <strong>en</strong>tre las dos<br />
estaciones base. Esta solución, que hemos estudiado <strong>en</strong> el protocolo<br />
Hawaii, aparece <strong>en</strong> otros sistemas de micro-<strong>movilidad</strong> como el protocolo<br />
TORA (ver el punto 2.4.4). El planteami<strong>en</strong>to no es nuevo y ya lo hemos<br />
com<strong>en</strong>tado <strong>en</strong> el punto 4.4.1. Además esta solución también ha sido<br />
planteada <strong>en</strong> otro t<strong>ip</strong>o de redes como ATM [ENG95], o incluso d<strong>en</strong>tro de<br />
una subred [CAC96]. La segunda solución aportada ha sido la de lograr<br />
una transmisión de los datos desde dos estaciones base de forma<br />
144
Proceso de Handover <strong>en</strong> redes IP<br />
simultanea. Esta opción se emplea <strong>en</strong> las soluciones <strong>multicast</strong> (ver 4.4.4),<br />
y también ha sido propuesta <strong>en</strong> redes ATM [RAM96].<br />
Por último indicar que tan solo se ha <strong>en</strong>contrado un trabajo que<br />
int<strong>en</strong>ta dar una visión de conjunto de los sistemas de micro-<strong>movilidad</strong><br />
c<strong>en</strong>trándose <strong>en</strong> los mecanismos de handover [CAM01]. Sin embargo, es<br />
importante com<strong>en</strong>tar que los mecanismos de handover que int<strong>en</strong>tan<br />
minimizar la lat<strong>en</strong>cia o la pérdida de paquetes están <strong>en</strong> investigación <strong>en</strong><br />
estos mom<strong>en</strong>tos, y que <strong>en</strong> la actualidad algunas de las soluciones que se<br />
contemplaban <strong>en</strong> este trabajo han sido modificadas, reagrupadas o incluso<br />
descartadas.<br />
4.4.4 Handovers <strong>basado</strong>s <strong>en</strong> transmisión <strong>multicast</strong><br />
La utilización de las capacidades <strong>multicast</strong> va a facilitar la<br />
implem<strong>en</strong>tación de algoritmos de handover con bajos tiempos de lat<strong>en</strong>cia y<br />
sin pérdidas de paquetes (el d<strong>en</strong>ominado ‘Seamless Handover’).<br />
La solución común de todos los trabajos que abordan la utilización<br />
de transmisión <strong>multicast</strong> para mejorar las prestaciones del handover es el<br />
de lograr que las Estaciones Base (los Foreign Ag<strong>en</strong>t <strong>en</strong> Mobile IP) estén<br />
conectadas al árbol <strong>multicast</strong> cuando el nodo móvil comi<strong>en</strong>za a dep<strong>en</strong>der<br />
de ella.<br />
Un ejemplo de esta solución lo <strong>en</strong>contramos <strong>en</strong> [HEL00], donde se<br />
sugiere la utilización de una ‘conexión avanzada al árbol <strong>multicast</strong>’<br />
(Advanced Join). Como hemos com<strong>en</strong>tado se pret<strong>en</strong>de que la sigui<strong>en</strong>te BS<br />
se conecte al árbol <strong>multicast</strong> antes de que el MN deje de comunicarse con<br />
la Estación Base previa. Aquí no se contempla el problema de que la<br />
estación reciba paquetes duplicados, ni como se inicia este mecanismo de<br />
conexión avanzada. Además, al no utilizar el Mobile IP (pues cada nodo<br />
ti<strong>en</strong>e asignada una dirección <strong>multicast</strong> perman<strong>en</strong>te, ver punto 2.5.1), y no<br />
necesitar de un mecanismo de registro con ningún HA, este método es<br />
145
Proceso de Handover <strong>en</strong> redes IP<br />
mucho más s<strong>en</strong>cillo que el handover pre-registro [ELM02] estudiado<br />
anteriorm<strong>en</strong>te <strong>en</strong> el punto 4.4.2.<br />
Otro ejemplo, mucho más refer<strong>en</strong>ciado, es el proyecto Daedalus<br />
[SES97] (ver punto 2.5.2), donde también se define un mecanismo de<br />
handover que pret<strong>en</strong>de reducir tanto el retardo como la pérdida de<br />
paquetes. En esta propuesta varias estaciones cercanas al móvil pued<strong>en</strong><br />
conectarse al árbol <strong>multicast</strong> y com<strong>en</strong>zar a almac<strong>en</strong>ar una pequeña<br />
cantidad de paquetes <strong>en</strong> memoria, aunque no las transmit<strong>en</strong> por el <strong>en</strong>lace<br />
inalámbrico. Así cuando se produce el handover se retransmitan las<br />
tramas almac<strong>en</strong>adas, de manera que se minimiza la pérdida de tramas.<br />
Como ya se com<strong>en</strong>tó <strong>en</strong> el punto 4.4.1 el MN indica cuales son sus últimos<br />
paquetes recibidos, con el fin de evitar duplicaciones. Es importarte<br />
indicar que el modelo implem<strong>en</strong>tado permitía la comunicación de la<br />
estación móvil con todas las estaciones base implicadas <strong>en</strong> el proceso de<br />
handover, lo que permite algoritmos mucho más s<strong>en</strong>cillos pero no siempre<br />
aplicables a todas los protocolos L2 inalámbricos exist<strong>en</strong>tes <strong>en</strong> la<br />
actualidad.<br />
Por último estaría una solución más s<strong>en</strong>cilla que sería el asignar<br />
previam<strong>en</strong>te un conjunto de estaciones base al árbol <strong>multicast</strong> de manera<br />
que el handover puede realizarse sin interrupciones debidas al nivel 3.<br />
Esta solución que se podría d<strong>en</strong>ominar Reserva Antic<strong>ip</strong>ada ti<strong>en</strong>e el<br />
inconv<strong>en</strong>i<strong>en</strong>te de no aprovechar efici<strong>en</strong>tem<strong>en</strong>te los recursos, y para un<br />
funcionami<strong>en</strong>to correcto se debería t<strong>en</strong>er información sobre las zonas que<br />
el nodo móvil va a visitar. Exist<strong>en</strong> algunos trabajos sobre reservas<br />
antic<strong>ip</strong>adas <strong>en</strong> <strong>en</strong>tornos móviles [PAJ97]. Sin embargo éstos abordan el<br />
tema c<strong>en</strong>trándose <strong>en</strong> la reserva de recursos para proporcionar QoS, y no<br />
desde el punto de vista del handover, ni utilizando las características de la<br />
transmisión <strong>multicast</strong>.<br />
146
Proceso de Handover <strong>en</strong> redes IP<br />
4.5 RESUMEN Y CONCLUSIONES DEL CAPÍTULO<br />
Hemos estudiado como el tiempo que dura el proceso de handover<br />
<strong>en</strong> las redes IP móviles puede separarse <strong>en</strong> tres compon<strong>en</strong>tes: retardo <strong>en</strong> la<br />
detección de movimi<strong>en</strong>to, retardo de la obt<strong>en</strong>ción de una dirección<br />
temporal y retardo <strong>en</strong> el restablecimi<strong>en</strong>to de la ruta.<br />
T<strong>en</strong>i<strong>en</strong>do <strong>en</strong> m<strong>en</strong>te esta división temporal, podemos indicar que la<br />
lat<strong>en</strong>cia del handover que ofrece el protocolo Mobile IP puede ser<br />
inaceptable para aplicaciones, como las multimedia, que ti<strong>en</strong><strong>en</strong><br />
restricciones temporales. Así, a continuación se muestra las<br />
contribuciones a los difer<strong>en</strong>tes tiempos que g<strong>en</strong>era el protocolo Mobile IP<br />
original:<br />
• La detección del movimi<strong>en</strong>to se realiza estudiando los m<strong>en</strong>sajes de<br />
aviso que transmite el nuevo Foreign Ag<strong>en</strong>t. Esta recepción implica<br />
el desarrollo completo y previo de un handover de nivel dos (L2),<br />
indep<strong>en</strong>di<strong>en</strong>te del protocolo Mobile IP. Desde el punto de vista del<br />
nivel de red, y con el fin de simplificar la clasificación de las<br />
soluciones, el tiempo de handover L2 puede incluirse <strong>en</strong> el tiempo<br />
de detección de movimi<strong>en</strong>to. Así, la indep<strong>en</strong>d<strong>en</strong>cia y no cooperación<br />
de ambos procesos se traduce <strong>en</strong> un aum<strong>en</strong>to de este retardo.<br />
• Los protocolos de <strong>movilidad</strong> IP suel<strong>en</strong> basarse <strong>en</strong> la utilización, por<br />
parte del nodo móvil, de una dirección temporal. El protocolo<br />
Mobile IP ofrece dos variantes de este mecanismo: empleo de una<br />
dirección Care-of Address (CoA) pert<strong>en</strong>eci<strong>en</strong>te a un FA, o bi<strong>en</strong> el<br />
empleo de una asignada personalm<strong>en</strong>te al nodo, Co-located Care-of<br />
Address. En este segundo caso (única solución propuesta <strong>en</strong><br />
MIPv6) es necesario un tiempo para la obt<strong>en</strong>ción de la dirección,<br />
por ejemplo, utilizando un servidor DHCP.<br />
• En Mobile IP el MN debe indicar a su Home Ag<strong>en</strong>t su nueva<br />
dirección CoA, con el fin de éste redirija los datos hacia la nueva<br />
ubicación del nodo. Este tiempo aum<strong>en</strong>ta de manera proporcional a<br />
la distancia exist<strong>en</strong>te <strong>en</strong>tre la situación el nodo y su red original<br />
(HN).<br />
147
Proceso de Handover <strong>en</strong> redes IP<br />
Se han publicado numerosas propuestas que mejoran las<br />
prestaciones del handover pres<strong>en</strong>tado <strong>en</strong> Mobile IP. Estas propuestas<br />
int<strong>en</strong>tan solucionar dos problemas difer<strong>en</strong>ciados: por un lado reducir el<br />
elevado tiempo de lat<strong>en</strong>cia ya com<strong>en</strong>tado. En una clasificación previa estas<br />
soluciones se han d<strong>en</strong>ominado ‘Handovers rápidos’. Por otro lado existe el<br />
problema de la pérdida de paquetes durante el proceso. Los mecanismos<br />
que int<strong>en</strong>tan minimizar este inconv<strong>en</strong>i<strong>en</strong>te se d<strong>en</strong>ominan ‘Handovers<br />
suaves’. A continuación se resum<strong>en</strong> las soluciones aportadas a estos dos<br />
problemas.<br />
Handovers Rápidos.<br />
Exist<strong>en</strong> múlt<strong>ip</strong>les soluciones que int<strong>en</strong>tan reducir la lat<strong>en</strong>cia de<br />
handover que se produce <strong>en</strong> el protocolo Mobile IP. Con el fin de reducir el<br />
tiempo de detección de movimi<strong>en</strong>to, se han pres<strong>en</strong>tado soluciones basadas<br />
<strong>en</strong> una cooperación <strong>en</strong>tre el los niveles 2 y 3. Así mediante la utilización de<br />
‘triggers’ se puede lograr, por ejemplo, que el handover L3 comi<strong>en</strong>ce antes<br />
de concluir el de nivel 2. Adicionalm<strong>en</strong>te, también podrían incluirse aquí<br />
todas las soluciones que mejoran las prestaciones de los handovers L2,<br />
como las que permit<strong>en</strong> una comunicación con los dos Puntos de Acceso<br />
simultáneam<strong>en</strong>te. Un ejemplo sería la solución pres<strong>en</strong>tada <strong>en</strong> el protocolo<br />
de micro-<strong>movilidad</strong> Cellular IP bajo el nombre de handover semi-suave.<br />
También el retardo de la obt<strong>en</strong>ción de una dirección temporal<br />
puede disminuirse. Tanto los sistemas de micro-<strong>movilidad</strong> HBR, como los<br />
sistemas <strong>basado</strong>s <strong>en</strong> la utilización de direcciones <strong>multicast</strong>, eliminan este<br />
retardo, al no cambiar de dirección mi<strong>en</strong>tras permanec<strong>en</strong> <strong>en</strong> el interior del<br />
dominio.<br />
Quizás el mayor compon<strong>en</strong>te a la lat<strong>en</strong>cia del handover <strong>en</strong> el<br />
protocolo Mobile IP es el retardo <strong>en</strong> el restablecimi<strong>en</strong>to de la ruta, puesto<br />
que es directam<strong>en</strong>te proporcional a la distancia <strong>en</strong>tre la red original del<br />
nodo (Home Network, HN) y la situación actual del mismo. Con el objetivo<br />
de reducir este tiempo apareció la idea de dividir la red <strong>en</strong> dominios y el<br />
concepto de protocolos de micro-<strong>movilidad</strong>. Tanto los sistemas jerárquicos,<br />
como el Registro Regional, como los sistemas de Encaminami<strong>en</strong>to Basado<br />
148
Proceso de Handover <strong>en</strong> redes IP<br />
<strong>en</strong> Host (HBR), logran disminuir este retardo, ya que ahora los m<strong>en</strong>sajes<br />
de registro sólo deb<strong>en</strong> viajar hasta la raíz del dominio. En particular, los<br />
sistemas HBR son muy rápidos, ya que la información del handover sólo<br />
modificará tablas hasta el d<strong>en</strong>ominado Punto de Cruce. También los<br />
sistemas que utilizan direccionami<strong>en</strong>to <strong>multicast</strong> son particularm<strong>en</strong>te<br />
rápidos, ya que el retardo se limita al tiempo necesario para que la nueva<br />
estación base se conecte al árbol <strong>multicast</strong>.<br />
Handovers Suaves.<br />
Existe un problema difer<strong>en</strong>te, pero no m<strong>en</strong>os importante, al de<br />
int<strong>en</strong>tar mejorar la lat<strong>en</strong>cia del handover del protocolo Mobile IP. El<br />
protocolo original no contempla ningún mecanismo para int<strong>en</strong>tar<br />
disminuir la pérdida de paquetes durante el proceso de handover. Por<br />
ejemplo, los paquetes interceptados por el HA tras el nuevo registro son<br />
<strong>en</strong>viados al nuevo FA, y se asume que el nivel superior solucionará el<br />
problema de la pérdida de los paquetes que hasta ese mom<strong>en</strong>to van <strong>en</strong><br />
tránsito hacia el FA antiguo.<br />
El concepto de conseguir minimizar, o incluso eliminar, la pérdida<br />
de paquetes durante el proceso de handover se conoce como ‘Handover<br />
Suave’, existi<strong>en</strong>do numerosos trabajos al respecto. De un estudio de estos<br />
trabajos se deduc<strong>en</strong>, princ<strong>ip</strong>alm<strong>en</strong>te, dos posibles soluciones: La<br />
utilización de túneles para retransmitir los paquetes; y la transmisión<br />
simultánea a las dos Estaciones Base implicadas (transmisión dualcast).<br />
La solución de emplear túneles se basa <strong>en</strong> una comunicación <strong>en</strong>tre<br />
los dos Foreign Ag<strong>en</strong>t implicados, de manera que el oFA le transmite al<br />
nFA los datagramas que no ha podido <strong>en</strong>viar al nodo móvil por haberse<br />
cambiado de subred. Además esta comunicación ofrece mejoras<br />
adicionales, como la liberación inmediata de los recursos consumidos por<br />
el nodo móvil <strong>en</strong> el FA antiguo, sin t<strong>en</strong>er que esperar que expire el tiempo<br />
de vida del m<strong>en</strong>saje de registro. Ejemplos de trabajos que propon<strong>en</strong> esta<br />
solución son los relativos a la optimización de ruta, algunas soluciones del<br />
sistema de micro-<strong>movilidad</strong> HAWAII (MSF y SSF), o el handover suave<br />
[PER01] estudiado <strong>en</strong> el punto 4.4.1.<br />
149
Proceso de Handover <strong>en</strong> redes IP<br />
La solución anterior puede completarse, adicionalm<strong>en</strong>te, con el<br />
almac<strong>en</strong>ami<strong>en</strong>to, por parte del oFA, de los últimos paquetes que se han<br />
transmitido hacia el nodo móvil. De esta manera se rescatan los paquetes<br />
que, al ser ya <strong>en</strong>viados por el oFA, se habrían perdido.<br />
La utilización de túneles <strong>en</strong>tre Foreign Ag<strong>en</strong>ts ti<strong>en</strong>e el inconv<strong>en</strong>i<strong>en</strong>te<br />
del retardo que éste provoca <strong>en</strong> los paquetes retransmitidos, y que <strong>en</strong><br />
aplicaciones de tiempo real puede no ser aceptable.<br />
Una segunda solución aportada por la bibliografía para lograr un<br />
handover suave es la transmisión de los paquetes a las dos Estaciones<br />
Base de manera simultánea. Propuestas <strong>en</strong> este s<strong>en</strong>tido pued<strong>en</strong><br />
<strong>en</strong>contrarse <strong>en</strong> los sistemas de micro-<strong>movilidad</strong> Cellular IP (Handover Semi<br />
suave) y Hawai MNF, y <strong>en</strong> los sistemas <strong>basado</strong>s <strong>en</strong> <strong>multicast</strong>.<br />
Las prestaciones de esta última solución dep<strong>en</strong>derán de la<br />
capacidad del sistema para poder transmitir a la nueva Estación Base<br />
antes de que el nodo móvil pierda conexión con la previa. Una opción para<br />
lograr esto sería el empleo de los triggers ya com<strong>en</strong>tados anteriorm<strong>en</strong>te.<br />
Evid<strong>en</strong>tem<strong>en</strong>te, si el nodo móvil dispone de la capacidad de comunicarse<br />
de manera simultánea con las dos Estaciones Base, el mecanismo se<br />
simplifica de manera considerable.<br />
150
5. PRESTACIONES DEL HANDOVER EN<br />
REDES IP MÓVILES<br />
5.1 INTRODUCCIÓN<br />
En el capítulo anterior se realizó una valoración cualitativa del<br />
proceso de handover, concluy<strong>en</strong>do que el protocolo Mobile IP no ofrecía las<br />
prestaciones necesarias para las aplicaciones con requisitos temporales.<br />
Como solución se estudiaron un conjunto de variaciones, que han sido la<br />
base para el desarrollo de nuevos sistemas de micro-<strong>movilidad</strong>.<br />
En este capítulo se va a completar el trabajo anterior, realizando un<br />
estudio sobre las prestaciones del handover, tanto <strong>en</strong> el protocolo Mobile<br />
IP, como <strong>en</strong> algunos de los sistemas de micro-<strong>movilidad</strong> que se trataron<br />
anteriorm<strong>en</strong>te.<br />
Tradicionalm<strong>en</strong>te se citan tres técnicas difer<strong>en</strong>tes de evaluación de<br />
prestaciones [JAI91]: modelado analítico, simulación, y realización de<br />
mediciones, preferiblem<strong>en</strong>te, sobre un sistema real implantado. La elección<br />
de una u otra técnica dep<strong>en</strong>de de una serie de factores que se pued<strong>en</strong><br />
resumir <strong>en</strong> los sigui<strong>en</strong>tes puntos:<br />
• Situación del sistema. Las mediciones sólo serán posibles si ya<br />
existe algún sistema similar al de estudio. Así, si es un concepto<br />
nuevo sólo se puede usar el modelado analítico o la simulación.<br />
En el caso de los protocolos de <strong>movilidad</strong> IP exist<strong>en</strong>, <strong>en</strong> la<br />
actualidad, distintos ‘drivers’ que implem<strong>en</strong>tan el protocolo Mobile<br />
IP. Por ejemplo, podemos destacar las versiones para Linux de la<br />
universidad de Stanford (MosquitoNet [MOS]), o la de los<br />
laboratorios de HP <strong>en</strong> Bristol [HP], la versión para BSD de la<br />
universidad de Portland [POR], o la de Sun Microsystem [SUN]<br />
para Solaris. Sin embargo algunos de los sistemas de micro<strong>movilidad</strong><br />
y la mayoría de las modificaciones para conseguir<br />
151
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
handovers rápidos que se estudiaron <strong>en</strong> el tema anterior se<br />
<strong>en</strong>cu<strong>en</strong>tran <strong>en</strong> fase de desarrollo y no exist<strong>en</strong> implem<strong>en</strong>taciones<br />
reales de los mismos.<br />
• Nivel de detalle. El modelado analítico requiere unas<br />
suposiciones y simplificaciones que hac<strong>en</strong> que la precisión<br />
disminuya. En la simulación, por el contrario, la exactitud de las<br />
medidas dep<strong>en</strong>derá del nivel de detalle con el que se ha<br />
implem<strong>en</strong>tado las simulaciones. La realización de medidas<br />
también ti<strong>en</strong>e sus limitaciones, y la exactitud dep<strong>en</strong>derá, tanto de<br />
los parámetros introducidos, como de la semejanza del banco de<br />
pruebas con el <strong>en</strong>torno real de utilización.<br />
• El coste del proyecto y la disponibilidad de las herrami<strong>en</strong>tas<br />
necesarias. La toma de medida requiere equ<strong>ip</strong>os reales,<br />
instrum<strong>en</strong>tos de mediada y tiempo. Es, normalm<strong>en</strong>te, la más cara<br />
de las tres. La realización de simulaciones requiere la<br />
disponibilidad de herrami<strong>en</strong>tas de simulación, y conocimi<strong>en</strong>to de<br />
l<strong>en</strong>guajes de simulación o programación. Por último, las medidas<br />
analíticas no requier<strong>en</strong> de equ<strong>ip</strong>os, pero si de sufici<strong>en</strong>tes<br />
conocimi<strong>en</strong>tos matemáticos.<br />
• Credibilidad. La credibilidad de los resultados es mayor cuando<br />
se realizas medidas, ya que es mucho más fácil conv<strong>en</strong>cer a los<br />
demás si exist<strong>en</strong> unas medidas reales. En este aspecto el<br />
modelado es el que peor se <strong>en</strong>cu<strong>en</strong>tra.<br />
Reci<strong>en</strong>tem<strong>en</strong>te se han pres<strong>en</strong>tado una serie de trabajos [BLO02],<br />
[BLO03], [BLO03b] que realizan un estudio de las prestaciones de<br />
handover, por modelado analítico, de algunos de los mecanismos<br />
pres<strong>en</strong>tados <strong>en</strong> el capítulo anterior. Estos trabajos se utilizarán como base<br />
para realizar el modelado analítico de los mecanismos de handover de<br />
nuestro sistema de micro-<strong>movilidad</strong> que se pres<strong>en</strong>tarán <strong>en</strong> el próximo<br />
capítulo.<br />
Sin embargo, <strong>en</strong> este capítulo nos hemos decantado por realizar un<br />
estudio de prestaciones utilizando simulación. Esta técnica nos va a dar la<br />
oportunidad de comparar, de una manera homogénea, las prestaciones del<br />
152
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
handover de distintos sistemas ya pres<strong>en</strong>tados. Así veremos las<br />
limitaciones del protocolo Mobile IP y las mejoras que ofrec<strong>en</strong> los sistemas<br />
de micro-<strong>movilidad</strong>. Con el fin de confrontar los valores así obt<strong>en</strong>idos, se<br />
ha desarrollado, adicionalm<strong>en</strong>te, un banco de pruebas donde se estudiará<br />
con medidas reales las prestaciones del protocolo Mobile IP.<br />
En el resto del pres<strong>en</strong>te capítulo se van a tratar los sigui<strong>en</strong>tes<br />
puntos: A continuación, <strong>en</strong> este mismo punto de introducción, se va a<br />
com<strong>en</strong>tar la herrami<strong>en</strong>ta de simulación seleccionada, así como la<br />
metodología de trabajo. En los puntos 5.2 a 5.4 se detalla el estudio que se<br />
ha realizado sobre el proceso de handover del protocolo Mobile IP. En el<br />
punto 5.5 se realiza el estudio del handover de alguno de los princ<strong>ip</strong>ales<br />
sistemas de micro-<strong>movilidad</strong> tratados anteriorm<strong>en</strong>te (Hawaii, Cellular IP y<br />
Sistema Jerárquico). Por último <strong>en</strong> 5.6 se evalúa el protocolo Mobile IP<br />
utilizando medidas reales.<br />
5.1.1 Simulador de red NS-2<br />
El simulador NS-2 [NS2] es una herrami<strong>en</strong>ta de simulación de<br />
ev<strong>en</strong>tos discretos, c<strong>en</strong>trada <strong>en</strong> la investigación de redes de computadores,<br />
que proporciona un gran soporte para el estudio de algoritmos de<br />
<strong>en</strong>caminami<strong>en</strong>to, protocolos <strong>multicast</strong>, variaciones del protocolo TCP, y de<br />
redes inalámbricas, incluy<strong>en</strong>do protocolos de <strong>en</strong>caminami<strong>en</strong>to <strong>en</strong> redes Ad<br />
hoc.<br />
El simulador forma parte de un programa d<strong>en</strong>ominado VINT<br />
(Virtual InterNetwork Testbed) realizado por el Instituto de Ci<strong>en</strong>cias de la<br />
Información (ISI) de la <strong>Universidad</strong> del Sur de California (USC), <strong>en</strong><br />
colaboración con XeroxParc, el laboratorio LBNL (Lawr<strong>en</strong>ce Berkeley<br />
National Laboratory) y la <strong>Universidad</strong> de California Berkeley (UCB).<br />
Actualm<strong>en</strong>te, el simulador se <strong>en</strong>cu<strong>en</strong>tra patrocinado por la ag<strong>en</strong>cia DARPA<br />
y por la fundación NSF (National Sci<strong>en</strong>ce Foundation).<br />
153
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
En la versión 2 del simulador NS, el núcleo del simulador se<br />
<strong>en</strong>cu<strong>en</strong>tra programado <strong>en</strong> C++, mi<strong>en</strong>tras que el interfaz de configuración<br />
emplea OTCL, una ext<strong>en</strong>sión del l<strong>en</strong>guaje TCL (Tool Command Language)<br />
p<strong>en</strong>sada para la programación ori<strong>en</strong>tada a objetos.<br />
La utilización de dos l<strong>en</strong>guajes difer<strong>en</strong>tes (C++ y OTCL) permite<br />
combinar la velocidad de ejecución propia de un programa compilado con<br />
la s<strong>en</strong>cillez de OTCL. Así mediante OTCL es posible crear el interfaz de<br />
usuario de forma fácil e intuitiva, definir la topología de la red, configurar<br />
las fu<strong>en</strong>tes y sumideros de tráfico, e invocar la simulación.<br />
El simulador, como consecu<strong>en</strong>cia, debe soportar una jerarquía de<br />
clases <strong>en</strong> C++, o jerarquía compilada, y una jerarquía de clases equival<strong>en</strong>te<br />
<strong>en</strong> OTCL, o jerarquía interpretada. Cuando el usuario crea un nuevo objeto<br />
de simulación mediante el intérprete, este objeto es primeram<strong>en</strong>te<br />
instanciado <strong>en</strong> OTCL y, posteriorm<strong>en</strong>te, reflejado por su correspondi<strong>en</strong>te<br />
objeto <strong>en</strong> la clase compilada, que es la que intervi<strong>en</strong>e directam<strong>en</strong>te <strong>en</strong> la<br />
ejecución. En [NS02] puede <strong>en</strong>contrarse más información sobre el<br />
funcionami<strong>en</strong>to del simulador.<br />
Evid<strong>en</strong>tem<strong>en</strong>te exist<strong>en</strong> más herrami<strong>en</strong>tas de simulación además de<br />
NS-2. La elección de ésta, <strong>en</strong> detrim<strong>en</strong>to de soluciones comerciales como<br />
Opnet [OPN], se ha realizado porque a nuestro <strong>en</strong>t<strong>en</strong>der ofrece las<br />
sigui<strong>en</strong>tes v<strong>en</strong>tajas:<br />
• Su código fu<strong>en</strong>te es abierto, lo que facilita su depuración y la<br />
ampliación a campos no contemplados actualm<strong>en</strong>te <strong>en</strong> la<br />
herrami<strong>en</strong>ta. Es decir, permite el estudio del funcionami<strong>en</strong>to del<br />
simulador y la posibilidad de modificarlo para perfeccionarlo. Una<br />
de los princ<strong>ip</strong>ales inconv<strong>en</strong>i<strong>en</strong>tes que se pon<strong>en</strong> al desarrollo de<br />
estudios <strong>basado</strong>s <strong>en</strong> la simulación es que los sistemas<br />
implem<strong>en</strong>tados no se ajustan completam<strong>en</strong>te a la realidad. La<br />
forma directa de solucionar este problema es t<strong>en</strong>er controlados<br />
todos los elem<strong>en</strong>tos que intervi<strong>en</strong><strong>en</strong> <strong>en</strong> la simulación, y el acceso<br />
al código es un elem<strong>en</strong>to fundam<strong>en</strong>tal para este control.<br />
154
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
• El carácter abierto del código se traduce <strong>en</strong> la exist<strong>en</strong>cia de<br />
numerosos grupos de investigación <strong>en</strong> todo el mundo que realizan<br />
trabajos con la herrami<strong>en</strong>ta (<strong>en</strong> la actualidad se calcula más de<br />
10.000 usuarios <strong>en</strong> más de 1000 instituciones <strong>en</strong> 50 países).<br />
Esto, unido al carácter abierto y cooperante, permite comp<strong>en</strong>sar<br />
ciertas limitaciones, como falta de manuales o servicio de<br />
mant<strong>en</strong>imi<strong>en</strong>to, que los paquetes comerciales no sufr<strong>en</strong>.<br />
• Su programación está ori<strong>en</strong>tada a objetos, lo que flexibiliza y<br />
simplifica la tarea de programación, tanto de su código fu<strong>en</strong>te<br />
como de su interfaz.<br />
• NS-2 está optimizado para el funcionami<strong>en</strong>to <strong>en</strong> sistemas<br />
operativos UNIX, incluy<strong>en</strong>do el popular LINUX. Existe,<br />
adicionalm<strong>en</strong>te, una versión para los S.O. Windows.<br />
• Su distribución es gratuita.<br />
Sin embargo, la princ<strong>ip</strong>al v<strong>en</strong>taja que aporta esta herrami<strong>en</strong>ta, y<br />
que ha llevado a seleccionarla sin ningún lugar a dudas, ha sido que es la<br />
elegida por todos los grupos de investigación que actualm<strong>en</strong>te trabajan <strong>en</strong><br />
la simulación de protocolos de <strong>movilidad</strong> IP. Como princ<strong>ip</strong>ales ejemplos<br />
destacamos el grupo ‘Comet’ de la <strong>Universidad</strong> de Columbia [COM], el<br />
proyecto ‘Mobins2’ dirigido por el propio Charles E. Perkins [MOB] y,<br />
princ<strong>ip</strong>alm<strong>en</strong>te, el grupo ‘Monarch’ [MON] dirigido por D. Johnson,<br />
anteriorm<strong>en</strong>te situado <strong>en</strong> la <strong>Universidad</strong> de Carnegie Mellon y,<br />
actualm<strong>en</strong>te, trasladado a la <strong>Universidad</strong> de Rice.<br />
La utilización del simulador NS-2 trae consigo una serie de<br />
limitaciones. La princ<strong>ip</strong>al es que se trata de un producto que<br />
perman<strong>en</strong>tem<strong>en</strong>te se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> fase de desarrollo, por lo que su código<br />
no está totalm<strong>en</strong>te depurado, y aún exist<strong>en</strong> multitud de pequeños errores<br />
<strong>en</strong> los códigos que forman el simulador. Además, la mayoría de las<br />
aportaciones de los difer<strong>en</strong>tes c<strong>en</strong>tros de investigación están validadas sólo<br />
para una versión, y es probable que no funcion<strong>en</strong> de forma correcta con<br />
versiones anteriores o posteriores. Por último, al no ser un producto<br />
comercial la ayuda no está conv<strong>en</strong>i<strong>en</strong>tem<strong>en</strong>te desarrollada. Esto hace que,<br />
155
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
aunque el desarrollo de pequeñas simulaciones con objetos ya exist<strong>en</strong>tes<br />
sea s<strong>en</strong>cillo, la realización de simulaciones complejas como la<br />
implem<strong>en</strong>tación de nuevos protocolos sea complicada.<br />
5.1.2 Metodología de trabajo<br />
Las simulaciones pres<strong>en</strong>tadas <strong>en</strong> este capítulo han sido realizadas<br />
con distintas versiones del simulador NS-2 [NS2]. En particular se han<br />
empleado la versión ns-2.1b6 bajo Sistema Operativo Linux (versión Red<br />
Hat 7.2), la versión ns-2.1b9a con Windows 2000, y la versión ns-2.26<br />
bajo Cygwin [CYG]. La utilización de distintas versiones se ha debido a que<br />
diversos módulos utilizados sólo están validados para trabajar con una<br />
versión determinada.<br />
El simulador NS-2 necesita, obligatoriam<strong>en</strong>te, la instalación de<br />
algunos compon<strong>en</strong>tes adicionales para poder trabajar. Por ejemplo, los<br />
compon<strong>en</strong>tes obligatorios para la última versión son: Tcl/Tk 8.3.2, otcl<br />
1.0a8, TclCL 1.0b12. En el caso de utilizar Windows se necesita el<br />
compilador Visual C++. Además, exist<strong>en</strong> algunos compon<strong>en</strong>tes opcionales<br />
como puede ser nam, xgraph, perl, tcl debugg, etc. Algunos de estos<br />
compon<strong>en</strong>tes no dispon<strong>en</strong> de versión para Windows.<br />
Las simulaciones se diseñan <strong>en</strong> TCL, y es posible modificar los<br />
distintos módulos como ag<strong>en</strong>tes, <strong>en</strong>laces o nodos, ya que el código es<br />
abierto y están programados <strong>en</strong> C++. Las modificaciones de estos módulos<br />
obligan a recompilar el simulador.<br />
Una vez ejecutada la simulación se obti<strong>en</strong>e un fichero (con<br />
ext<strong>en</strong>sión 'tr') que conti<strong>en</strong>e información de todos ev<strong>en</strong>tos que han sucedido<br />
<strong>en</strong> la red simulada. Así cada una de las trazas incluidas <strong>en</strong> este fichero<br />
ofrece información sobre el instante de tiempo <strong>en</strong> que ha ocurrido, sobre<br />
los nodos implicados, información sobre la trama MAC, sobre el paquete<br />
IP, e información adicional que dep<strong>en</strong>de del ev<strong>en</strong>to que se ha producido o<br />
del t<strong>ip</strong>o de paquete del que se trata.<br />
156
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Debido a la complejidad, tamaño, y no homog<strong>en</strong>eidad del fichero de<br />
trazas es necesario procesarlo. Para ello se utilizan scr<strong>ip</strong>s realizados <strong>en</strong><br />
l<strong>en</strong>guaje Perl (Practical Extraction and Report Language). La elección de este<br />
l<strong>en</strong>guaje se ha debido a que dispone de facilidades para procesar texto,<br />
que provi<strong>en</strong><strong>en</strong> de su orig<strong>en</strong> como herrami<strong>en</strong>ta para la administración de<br />
sistemas UNIX. Otra de las v<strong>en</strong>tajas que ofrece es que está disponible de<br />
manera gratuita para todos los sistemas operativos.<br />
Por último, tras procesar los datos estos se repres<strong>en</strong>tan utilizando<br />
el programa Matlab [MAT], disponible tanto para S.O. Windows como para<br />
Linux.<br />
5.2 INTRODUCCIÓN AL ESTUDIO POR SIMULACIÓN<br />
DEL PROTOCOLO ‘MOBILE IP’<br />
Se ha considerado interesante com<strong>en</strong>zar realizando un estudio de<br />
las prestaciones del esquema de handover pres<strong>en</strong>tado <strong>en</strong> el protocolo<br />
original Mobile IP. El fin es estudiar como las prestaciones que ofrece lo<br />
hace inservible para aplicaciones de tiempo real, como pued<strong>en</strong> ser<br />
aplicaciones multimedia.<br />
Para realizar el estudio del protocolo Mobile IP se ha partido de las<br />
facilidades que ofrec<strong>en</strong> las últimas versiones del simulador NS-2 para<br />
trabajar con este protocolo. Desde la versión ns-2.1b6, de <strong>en</strong>ero de 2000,<br />
el simulador incluye el modelo inalámbrico <strong>basado</strong>, fundam<strong>en</strong>talm<strong>en</strong>te, <strong>en</strong><br />
el trabajo desarrollado por el grupo Monarch [MON]. Este modulo ha sido<br />
ampliado con trabajos de diversas universidades, de manera que<br />
actualm<strong>en</strong>te el simulador implem<strong>en</strong>ta el protocolo Mobile IP.<br />
Adicionalm<strong>en</strong>te existe otra implem<strong>en</strong>tación desarrollada por el grupo<br />
‘Mobins2’ [MOB]. Ésta última simplifica el <strong>en</strong>lace inalámbrico (y el<br />
protocolo de nivel dos WLAN) c<strong>en</strong>trándose <strong>en</strong> el protocolo de nivel tres.<br />
Con el fin de estudiar la pérdida de prestaciones que se produce<br />
cuando el Nodo Móvil se <strong>en</strong>cu<strong>en</strong>tra lejos de su Home Network, se han<br />
157
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
planteado dos situaciones distintas, que serán detalladas <strong>en</strong> los sigui<strong>en</strong>tes<br />
puntos.<br />
Además se han realizado estudios distingui<strong>en</strong>do el t<strong>ip</strong>o de tráfico,<br />
bi<strong>en</strong> si es s<strong>en</strong>sible a la lat<strong>en</strong>cia, <strong>en</strong> cuyo caso se utiliza el protocolo UDP,<br />
bi<strong>en</strong> si no es s<strong>en</strong>sible a la lat<strong>en</strong>cia, pero si a la pérdida de información,<br />
utilizando <strong>en</strong> este caso el protocolo TCP.<br />
Por último se han realizado distintas comparativas para estudiar la<br />
posible mejora de prestaciones al implem<strong>en</strong>tar mecanismos blandos de<br />
handover ‘make-before-break’, <strong>en</strong> vez de mecanismos abruptos ‘breakbefore-make’,<br />
(ver punto 4.1).<br />
5.3 ESTUDIO DEL HANDOVER CERCANO DEL<br />
PROTOCOLO MOBILE IP<br />
Para estudiar el proceso de handover cuando el nodo móvil se<br />
<strong>en</strong>cu<strong>en</strong>tra cerca de su Home Ag<strong>en</strong>t (HA) se ha implem<strong>en</strong>tado la situación<br />
que se muestra <strong>en</strong> la figura 5.1. En ella puede observarse las dos<br />
estaciones base que actúan como Home Ag<strong>en</strong>t y como Foreign Ag<strong>en</strong>t, y que<br />
incluy<strong>en</strong> un interfaz radio implem<strong>en</strong>tando el protocolo IEEE 802.11.<br />
Además, están conectadas <strong>en</strong>tre si por medio de un router. Se han situado<br />
a una distancia lo sufici<strong>en</strong>tem<strong>en</strong>te cercana para que las zonas de<br />
cobertura t<strong>en</strong>gan cierto solape. El valor de este solape será configurado <strong>en</strong><br />
las simulaciones.<br />
Al nodo móvil se le ha asignado una dirección IP perman<strong>en</strong>te<br />
pert<strong>en</strong>eci<strong>en</strong>te a la subred controlada por el Home Ag<strong>en</strong>t. Se ha configurado<br />
un movimi<strong>en</strong>to como el indicado <strong>en</strong> la figura, de manera que se desplaza<br />
<strong>en</strong> dirección al Foreign Ag<strong>en</strong>t.<br />
El Host que establece la comunicación con el nodo móvil también<br />
se <strong>en</strong>cu<strong>en</strong>tra conectado al router, por medio de un <strong>en</strong>lace con 20 mseg. de<br />
retardo. El valor de este retardo del <strong>en</strong>lace es un compon<strong>en</strong>te de la lat<strong>en</strong>cia<br />
158
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
de transmisión de los paquetes pero no afecta, particularm<strong>en</strong>te, a las<br />
prestaciones del handover analizadas.<br />
A continuación se detallan los trabajos realizados para estudiar el<br />
comportami<strong>en</strong>to del handover tanto <strong>en</strong> aplicaciones basadas <strong>en</strong> el<br />
protocolo UDP como de aquellas que utilizan el protocolo TCP.<br />
Host<br />
5<br />
Mbps<br />
5<br />
Mbps<br />
Router<br />
5<br />
Mbps<br />
Home Ag<strong>en</strong>t<br />
Foreign Ag<strong>en</strong>t<br />
IEEE 802.11b<br />
Nodo Móvil<br />
Figura 5.1 Configuración para estudiar el handover cercano <strong>en</strong> MIP.<br />
5.3.1 Estudio del tráfico UDP <strong>en</strong> Handover Cercano<br />
Las aplicaciones multimedia <strong>en</strong> tiempo real, como videoconfer<strong>en</strong>cia<br />
o voz sobre IP, suel<strong>en</strong> t<strong>en</strong>er restricciones temporales, de manera que los<br />
datos que se recib<strong>en</strong> con un retraso superior a una cota determinada son<br />
descartados. En estas aplicaciones se suele utilizar como protocolo de<br />
transporte UDP, que al ofrecer un servicio no confirmado funciona con<br />
m<strong>en</strong>ores retardos.<br />
159
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Para analizar estas situaciones se ha conectado un ag<strong>en</strong>te UDP al<br />
Host fijo. Sobre este ag<strong>en</strong>te se ha instalado un g<strong>en</strong>erador de tráfico CBR.<br />
Los m<strong>en</strong>sajes UDP ti<strong>en</strong><strong>en</strong> un tamaño constante de 500 bytes y se va a<br />
modificar el tiempo <strong>en</strong>tre los mismos. Los paquetes IP son dirigidos hacia<br />
el nodo móvil.<br />
Handover ‘Break before Make’<br />
El estudio comi<strong>en</strong>za con un análisis del handover abrupto (‘Break<br />
before Make’) donde una vez el nodo móvil (MH) no puede recibir de dos<br />
puntos de acceso simultáneam<strong>en</strong>te. Así cuando se realiza la conexión con<br />
el Foreign Ag<strong>en</strong>t se deja de recibir tramas de la estación base anterior.<br />
En la figura 5.2 se observa el número de paquetes perdidos durante<br />
este handover <strong>en</strong> función de la tasa del g<strong>en</strong>erador CBR. Se han tomado<br />
valores <strong>en</strong>tre 80Kbps y 2Mbps para abarcar todo el rango de aplicaciones<br />
multimedia [BHA95]. Cada medida se ha realizado <strong>en</strong> 100 ocasiones<br />
utilizando difer<strong>en</strong>tes semillas.<br />
Figura 5.2 Estudio de segm<strong>en</strong>tos UDP perdidos <strong>en</strong> el protocolo MIP.<br />
160
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
En la gráfica se ha incluido la recta de mínimos cuadrados, que<br />
ayuda a comprobar como el número de paquetes perdidos aum<strong>en</strong>ta<br />
directam<strong>en</strong>te con la tasa. Este aum<strong>en</strong>to lineal es debido a que no existe<br />
carga adicional <strong>en</strong> la red, y que por tanto las colas de los difer<strong>en</strong>tes nodos,<br />
<strong>en</strong> especial la de las estaciones base, están vacías. De esta manera no se<br />
va a producir una pérdida de los paquetes que estuvieran almac<strong>en</strong>ados <strong>en</strong><br />
dichas colas, a la espera de una posterior transmisión por el medio<br />
inalámbrico.<br />
El bajo número de paquetes perdidos es debido a la proximidad<br />
<strong>en</strong>tre las dos estaciones implicadas <strong>en</strong> el handover (Home Ag<strong>en</strong>t y Foreign<br />
Ag<strong>en</strong>t.). Se ha realizado un estudio del tiempo de handover de nivel tres<br />
tomando la difer<strong>en</strong>cia <strong>en</strong>tre el instante de tiempo <strong>en</strong> que el Foreign Ag<strong>en</strong>t<br />
<strong>en</strong>vía el m<strong>en</strong>saje Ag<strong>en</strong>t Advertisem<strong>en</strong>t y el instante <strong>en</strong> que el Nodo Móvil<br />
recibe finalm<strong>en</strong>te el m<strong>en</strong>saje Registration Reply. El valor medio resultante<br />
de analizar más de 500 procesos de handover ha dado un valor de 16.99<br />
mseg, con un coefici<strong>en</strong>te de variación CV = 0.16. En la figura 5.3 puede<br />
observarse gráficam<strong>en</strong>te el valor empleado como medida del tiempo de<br />
handover.<br />
MN FA HA<br />
Paquete vía HA<br />
Ag<strong>en</strong>t Advertisem<strong>en</strong>t<br />
Tiempo Medido<br />
Registration Request<br />
Registration Reply<br />
Registration Request<br />
Registration Reply<br />
Paquete vía FA<br />
Figura 5.3 Handover L3 empleado.<br />
161
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Por último se ha medido el tiempo exist<strong>en</strong>te <strong>en</strong>tre el último paquete<br />
recibido vía el Home Ag<strong>en</strong>t y el primero que se ha recibido utilizando el<br />
Foreign Ag<strong>en</strong>t una vez ha terminado el proceso de handover. En la figura<br />
5.4 puede observarse estos tiempos utilizando como base la tasa de<br />
transmisión CBR.<br />
Figura 5.4 Tiempo <strong>en</strong> mseg. <strong>en</strong>tre paquetes durante el handover.<br />
Puede observarse como con tasas de transmisión bajas se obti<strong>en</strong><strong>en</strong><br />
retardos elevados, que dep<strong>en</strong>d<strong>en</strong> directam<strong>en</strong>te del tiempo <strong>en</strong>tre<br />
transmisión de tramas. Por ejemplo, una tasa de 80Kbps, que se<br />
corresponde con un tiempo de g<strong>en</strong>eración de paquetes de 50 mseg,<br />
provoca un retardo medio <strong>en</strong>tre el último paquete <strong>en</strong>viado directam<strong>en</strong>te a<br />
través del HA y el primero <strong>en</strong>viado utilizando el FA de 71 mseg. Este valor<br />
es debido a que el handover a esta tasa producía una pérdida media de<br />
0.31 paquetes (figura 5.2), y que la pérdida de un paquete provocará un<br />
tiempo mínimo de 100 mseg.<br />
Sin embargo, a medida que la tasa aum<strong>en</strong>ta y, por tanto, el tiempo<br />
<strong>en</strong>tre paquetes <strong>en</strong>viados disminuye, este factor deja de ser tan<br />
determinante, y se ti<strong>en</strong>de a un valor cercano a los 22 mseg. Este tiempo<br />
162
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
puede ser estudiado como la suma de dos hechos difer<strong>en</strong>ciados. Por un<br />
lado se ti<strong>en</strong>e el tiempo debido al intercambio de m<strong>en</strong>sajes de señalización<br />
del protocolo Mobile IP durante el handover (los 16.99 mseg. de media que<br />
hemos com<strong>en</strong>tado anteriorm<strong>en</strong>te). Por otro lado hay que t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta el<br />
tiempo necesario <strong>en</strong> re<strong>en</strong>viar ese primer paquete desde el HA hacia el FA<br />
(figura 5.1).<br />
La figura 5.5 muestra la temporización de los ev<strong>en</strong>tos que se<br />
produc<strong>en</strong> durante un handover cercano. Las tres subfiguras muestran el<br />
comportami<strong>en</strong>to <strong>en</strong> función de la tasa: 80, 800 y 2000 Kbps. En las figuras<br />
se muestra el instante de tiempo cuando se transmite el paquetes desde el<br />
host, los instantes de tiempo <strong>en</strong> que dichos paquetes son recibidos por el<br />
nodo móvil, ya sea desde HA como de FA, así como los paquetes que no<br />
son recibidos por tratarse de un handover abrupto, <strong>en</strong> el que el nodo móvil<br />
no puede comunicase con dos estaciones base de manera simultánea.<br />
El estudio de estas figuras corrobora lo indicado anteriorm<strong>en</strong>te: el<br />
número de paquetes perdidos aum<strong>en</strong>ta con la carga, y los paquetes que se<br />
recib<strong>en</strong> vía FA sufr<strong>en</strong> un mayor retardo. El tiempo transcurrido desde el<br />
inicio de handover a nivel 3 hasta que el proceso se da por finalizado está<br />
<strong>en</strong> torno a los 17 mseg, com<strong>en</strong>tados anteriorm<strong>en</strong>te.<br />
163
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.5 Ev<strong>en</strong>tos <strong>en</strong> handover con protocolo de transporte UDP a difer<strong>en</strong>tes<br />
tasas: 80, 800 y 2000 Kbps.<br />
Con respecto al tiempo <strong>en</strong>tre el último paquete recibido vía HA y el<br />
primero recibido por el FA, las difer<strong>en</strong>tes gráficas de la figura 5.5 muestran<br />
como al aum<strong>en</strong>tar la tasa este tiempo ti<strong>en</strong>de a estabilizarse <strong>en</strong> valores<br />
ligeram<strong>en</strong>te superiores a 22 mseg. De la misma manera los segm<strong>en</strong>tos<br />
UDP perdidos (marcados <strong>en</strong> rojo <strong>en</strong> las figuras) concuerdan con los valores<br />
medios mostrados <strong>en</strong> la figura 5.2.<br />
164
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Handover ‘Make Before Break’<br />
Adicionalm<strong>en</strong>te se han realizado un conjunto de simulaciones para<br />
estudiar la mejora <strong>en</strong> las prestaciones de handover cuando el Nodo Móvil<br />
es capaz de comunicarse simultáneam<strong>en</strong>te con las dos Estaciones Base.<br />
Este t<strong>ip</strong>o de handover se d<strong>en</strong>omina ‘Make Before Break’ (también llamado<br />
‘handover blando’ <strong>en</strong> difer<strong>en</strong>te bibliografía), y va a permitir la recepción de<br />
paquetes vía la Estación Base previa, <strong>en</strong> este caso el HA, mi<strong>en</strong>tras se<br />
produce el intercambio de m<strong>en</strong>sajes del protocolo Mobile IP <strong>en</strong>tre el nuevo<br />
FA y el Nodo Móvil.<br />
El factor determinante <strong>en</strong> este t<strong>ip</strong>o de handover será la zona de<br />
solape <strong>en</strong>tre las coberturas de las dos Estaciones Base. Para establecer<br />
dicha cobertura es necesario la configuración de algunos parámetros,<br />
tanto <strong>en</strong> las estaciones como <strong>en</strong> el nodo móvil. En concreto, se ha definido<br />
la utilización de ant<strong>en</strong>as omnidireccionales, el uso del modelo de<br />
propagación radio de dos rayos sobre tierra plana, una pot<strong>en</strong>cia <strong>en</strong><br />
transmisión de 0.282 W, y un límite <strong>en</strong> recepción de 3.652e-10 W.<br />
Router<br />
V m/s<br />
250 m<br />
Home Ag<strong>en</strong>t<br />
Foreign Ag<strong>en</strong>t<br />
Zona de<br />
solape 20m<br />
Figura 5.6 Movimi<strong>en</strong>to del Nodo Móvil <strong>en</strong>tre las dos celdas.<br />
165
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Se ha realizado un estudio previo y estos valores de configuración<br />
dan como resultado una distancia máxima de 250 metros. En la figura 5.6<br />
puede observarse como las Estaciones Base (HA y FA) se han separado<br />
una distancia de 480 metros de manera que la zona de solape es de 20<br />
metros <strong>en</strong> la recta que une ambas estaciones.<br />
El número de paquetes perdidos está directam<strong>en</strong>te relacionado con<br />
el tiempo <strong>en</strong> que el Nodo Móvil permanece d<strong>en</strong>tro de la zona de influ<strong>en</strong>cia<br />
de las dos estaciones. Este tiempo de perman<strong>en</strong>cia dep<strong>en</strong>de del tamaño de<br />
la zona, que, como ya se ha com<strong>en</strong>tado, es de 20 metros <strong>en</strong> la dirección de<br />
desplazami<strong>en</strong>to del móvil, y de la velocidad de desplazami<strong>en</strong>to del mismo.<br />
Se ha tomado como posibles velocidades 10, 20 y 30 metros por segundo.<br />
Al igual que <strong>en</strong> casos anteriores se han realizado múlt<strong>ip</strong>les medidas con<br />
difer<strong>en</strong>tes semillas.<br />
Todas las simulaciones realizadas (más de 100) con distintas tasas<br />
CBR y el móvil desplazándose a 10 o a 20 m/seg. han dado como<br />
resultado la <strong>en</strong>trega de todos los paquetes. El motivo de que no se pierda<br />
ningún paquete es que el móvil va a estar <strong>en</strong> la zona de solape uno o dos<br />
segundos, dep<strong>en</strong>di<strong>en</strong>do de la velocidad empleada. En [RFC 3344] se indica<br />
que el Foreign Ag<strong>en</strong>t debe <strong>en</strong>viar m<strong>en</strong>sajes Ag<strong>en</strong>t Advertisem<strong>en</strong>t a una<br />
velocidad de uno por segundo, por lo que el nodo móvil siempre recibirá<br />
como mínimo uno de estos m<strong>en</strong>sajes y podrá lanzar el proceso de<br />
handover mi<strong>en</strong>tras está <strong>en</strong> la zona de solape. Como el Foreign Ag<strong>en</strong>t está<br />
muy cerca del Home Ag<strong>en</strong>t, el <strong>en</strong>vío del m<strong>en</strong>saje Registration Request desde<br />
el FA hacia el HA no dura más de 6-8 mseg y, por tanto, la única<br />
posibilidad de que se pierdan paquetes sería que el Nodo Móvil perdiera la<br />
cobertura del HA durante ese tiempo. La probabilidad de que suceda esto<br />
sería aproximadam<strong>en</strong>te de 8/1000 <strong>en</strong> el caso de una velocidad de<br />
desplazami<strong>en</strong>to de 20 m/seg. En el caso de una velocidad de 10 m/seg. se<br />
recibirán dos m<strong>en</strong>sajes de aviso durante la estancia del Nodo Móvil <strong>en</strong> la<br />
zona de solape, y por tanto la probabilidad de pérdida es nula.<br />
La figura 5.7 muestra una gráfica donde aparec<strong>en</strong> los paquetes<br />
perdidos cuando el Nodo Móvil se desplaza por la recta que une ambas<br />
estaciones a una velocidad de 30 m/seg. Al igual que la figura 5.2 se toma<br />
166
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
como base la tasa de paquetes de tráfico CBR. Cada punto de la figura se<br />
ha obt<strong>en</strong>ido a partir de 100 simulaciones indep<strong>en</strong>di<strong>en</strong>tes.<br />
Figura 5.7 Paquetes perdidos con MH a 30 m/s y zona de solape de 20 metros.<br />
Debido a la elevada velocidad del móvil, el tiempo que éste<br />
permanece <strong>en</strong> la zona de solape (666 mseg.) es m<strong>en</strong>or que el tiempo <strong>en</strong>tre<br />
m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ <strong>en</strong>viados por el FA. Por tanto existe la<br />
posibilidad de que el nodo reciba este m<strong>en</strong>saje cuando ya ha dejado la<br />
zona de solape y se ha ad<strong>en</strong>trado <strong>en</strong> la zona de cobertura exclusiva de FA.<br />
Evid<strong>en</strong>tem<strong>en</strong>te este hecho provoca una pérdida de los paquetes que el<br />
Home Ag<strong>en</strong>t ha <strong>en</strong>viado directam<strong>en</strong>te a su interfaz radio, a causa de no<br />
haber recibido aún ningún m<strong>en</strong>saje de registro y desconocer la nueva<br />
situación del móvil. Como se vio <strong>en</strong> el punto 4.3 una solución sería realizar<br />
una cooperación <strong>en</strong>tre la capa dos y tres, de manera que se pudiera forzar<br />
el <strong>en</strong>vío de un m<strong>en</strong>saje Ag<strong>en</strong>t Solicitation por parte del MH.<br />
167
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
5.3.2 Estudio del tráfico TCP <strong>en</strong> Handover Cercano<br />
Se han realizado una serie de estudios para comprobar como el<br />
proceso de handover de Mobile IP degrada de las prestaciones del protocolo<br />
TCP. Para ello se ha utilizado el mismo sistema que el mostrado <strong>en</strong> la<br />
figura 5.1.<br />
En este caso se ha sustituido el ag<strong>en</strong>te UDP del host fijo por uno<br />
TCP. El simulador nos ofrece distintas versiones del protocolo TCP. Debido<br />
a que para nuestro estudio no es excesivam<strong>en</strong>te relevante el uso de una<br />
versión u otra, nos hemos decantado por una de las últimas versiones,<br />
TCP Vegas [BRA94], que modifica el control de congestión del emisor para<br />
adaptarse de manera efici<strong>en</strong>te a la capacidad de la red disponible. El<br />
emisor transmite segm<strong>en</strong>tos de datos con tamaño fijo de 1020 Bytes<br />
(incluy<strong>en</strong>do la cabecera TCP de 20 Bytes). Sobre este ag<strong>en</strong>te se ha<br />
instalado una aplicación FTP que va a estar activa mi<strong>en</strong>tras se produce el<br />
proceso de handover.<br />
Handover ‘Break before Make’<br />
El estudio comi<strong>en</strong>za con un análisis del handover abrupto (‘Break<br />
before Make’) donde una vez el nodo móvil (MH) no puede recibir de dos<br />
puntos de acceso simultáneam<strong>en</strong>te. Así cuando se realiza la conexión con<br />
el Foreign Ag<strong>en</strong>t se deja de recibir tramas de la estación base anterior.<br />
La figura 5.8 muestra los paquetes transmitidos y recibidos<br />
durante un proceso de handover, así como el instante <strong>en</strong> el que el FA <strong>en</strong>vía<br />
el m<strong>en</strong>saje ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ y el instante <strong>en</strong> el que el m<strong>en</strong>saje<br />
‘Registration Reply’ llega al nodo móvil. Como vemos, a partir del mom<strong>en</strong>to<br />
<strong>en</strong> el que el MN pierde la conexión con HA se produce una pérdida<br />
temporal de paquetes, que no volverán a retransmitirse hasta que no pase<br />
un periodo de ‘time-out’ de aproximadam<strong>en</strong>te un segundo. El m<strong>en</strong>saje de<br />
anuncio desde FA se <strong>en</strong>vía con una periodicidad de un segundo [RFC<br />
168
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
3344], y por tanto, el nodo móvil ti<strong>en</strong>e tiempo sufici<strong>en</strong>te para registrarse<br />
antes de re<strong>en</strong>vío de los paquetes.<br />
La retransmisión de paquetes perdidos se produce por el<br />
mecanismo de ‘Slow Start’. Así la v<strong>en</strong>tana de transmisión empieza si<strong>en</strong>do<br />
pequeña (2 paquetes) y cada dos transmisiones correctas se duplica, hasta<br />
alcanzar el máximo de transmisión.<br />
Figura 5.8 Handover abrupto durante una transmisión TCP.<br />
La figura 5.9 muestra el caudal recibido (‘throughput’) por el nodo<br />
móvil durante el handover. La parte de la izquierda de la gráfica muestra el<br />
‘throughput’ antes del handover, cuando los datos se recib<strong>en</strong> directam<strong>en</strong>te<br />
desde el HA. Tras el handover este valor baja desde 350 Kbps. hasta un<br />
valor de 150 Kbps. Esta disminución se debe, además de por los<br />
mecanismos de control de congestión y arranque l<strong>en</strong>to, al hecho de que los<br />
paquetes viajan desde el nodo que transmite hacia el HA y luego son<br />
redirigidos, por el mismo <strong>en</strong>lace hacia el FA para su transmisión hacia el<br />
MN. Esto provoca primero que el <strong>en</strong>lace <strong>en</strong>tre el router y el HA soporte el<br />
doble de tráfico, y segundo a que el retardo total de la ruta CN-MN<br />
169
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
aum<strong>en</strong>ta de manera que el mecanismo de control de flujo del TCP se<br />
ral<strong>en</strong>tiza.<br />
Figura 5.9 ‘Throughput’ <strong>en</strong> bytes/seg. un handover abrupto cercano.<br />
Handover ‘Make Before Break’<br />
Hemos realizado un conjunto de simulaciones para estudiar la<br />
mejora <strong>en</strong> las prestaciones de handover cuando el Nodo Móvil es capaz de<br />
comunicarse simultáneam<strong>en</strong>te con las dos Estaciones Base. Así se permite<br />
la recepción de paquetes vía la Estación Base previa (<strong>en</strong> este caso el HA)<br />
mi<strong>en</strong>tras se produce el intercambio de m<strong>en</strong>sajes del protocolo Mobile IP<br />
<strong>en</strong>tre el nuevo FA y el Nodo Móvil.<br />
Como <strong>en</strong> los estudios realizados con la transmisión UDP, el factor<br />
determinante <strong>en</strong> al pérdida de paquetes será el tiempo que el nodo móvil<br />
permanece <strong>en</strong> la zona de solape. En nuestros estudios las estaciones base<br />
se han separado una distancia de 480 y de 470 metros. De esta manera la<br />
zona de solape es, <strong>en</strong> la recta que une ambas estaciones y por la que va a<br />
170
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
moverse el MN, de 20 y 30 metros respectivam<strong>en</strong>te. Se han tomado, como<br />
posibles velocidades del nodo móvil, 20 y 30 metros por segundo.<br />
La figura 5.10 muestra como se transmit<strong>en</strong> y recib<strong>en</strong> los paquetes<br />
cuando el MN se mueve a una velocidad relativam<strong>en</strong>te baja de 20m/s con<br />
una zona de cobertura común de 30 metros. Puede observarse como la<br />
transmisión es perfectam<strong>en</strong>te fluida y no se produce ninguna<br />
retransmisión de segm<strong>en</strong>tos por parte del CN.<br />
Figura 5.10 Handover blando durante una transmisión TCP.<br />
Como se estudió anteriorm<strong>en</strong>te, esta relación velocidad del MN<br />
tamaño de la zona de cobertura nos da un tiempo de perman<strong>en</strong>cia <strong>en</strong><br />
dicha zona superior a un segundo. Así el nodo recibirá, al m<strong>en</strong>os, un<br />
m<strong>en</strong>saje ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ que permitirá registrarse con la nueva<br />
estación base mi<strong>en</strong>tras se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona de cobertura de HA y sigue<br />
mant<strong>en</strong>i<strong>en</strong>do comunicación con ella.<br />
La figura muestra como un paquete (numerado <strong>en</strong> al simulación<br />
como 3066) ha sido <strong>en</strong>tregado vía HA cuando ya se ha completado el<br />
registro con la nueva estación base (FA). Esto ha ocurrido porque el<br />
171
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
paquete fue <strong>en</strong>viado antes de que llegara el m<strong>en</strong>saje de registro al HA y<br />
porque además el nodo móvil sigue <strong>en</strong> la zona de solape lo que permite su<br />
recepción.<br />
Para realizar la figura 5.11 se ha modificado la velocidad de<br />
desplazami<strong>en</strong>to del MN (ahora 30m/seg.) y el área de solape de las<br />
estaciones base (20 metros), de nabera que ahora el tiempo de<br />
perman<strong>en</strong>cia del nodo es tan solo de 666 mseg. Como se m<strong>en</strong>cionó <strong>en</strong> el<br />
apartado dedicado al UDP (5.3.1) esto provoca una cierta probabilidad de<br />
que el proceso de handover se realice total o parcialm<strong>en</strong>te fuera de la zona<br />
de solape.<br />
Figura 5.11Handover blando rápido durante una transmisión TCP.<br />
La figura muestra como los paquetes numerados a partir el 2067, y<br />
que fueron transmitidos por el CN <strong>en</strong> los instantes cercanos a 58.3, no<br />
fueron recibidos por el nodo móvil, ya que éste abandonó la zona de<br />
cobertura del HA. Mi<strong>en</strong>tras el nodo transmisor espera el reconocimi<strong>en</strong>to de<br />
estos paquetes el nodo móvil recibe el m<strong>en</strong>saje ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ y<br />
procede a implem<strong>en</strong>tar el handover según el protocolo Mobile IP. Tras<br />
v<strong>en</strong>cer el temporizador de retransmisión el protocolo TCP re<strong>en</strong>viará estos<br />
172
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
paquetes, que alcanzarán finalm<strong>en</strong>te al modo móvil vía la nueva estación<br />
base.<br />
Es interesante destacar lo sucedido con los paquetes 2065 y 2066.<br />
Estos paquetes fueron correctam<strong>en</strong>te recibidos por el nodo móvil pero la<br />
confirmación positiva no llegó al CN ya que el nodo había abandonado la<br />
zona de cobertura del HA. Como puede observarse esto ha provocado una<br />
retransmisión innecesaria de los mismos y una ligera pérdida de<br />
prestaciones.<br />
5.3.3 Conclusiones sobre el Handover Cercano<br />
Tras el estudio de las prestaciones del mecanismo de handover<br />
especificado por el protocolo Mobile IP, podemos observar que el<br />
comportami<strong>en</strong>to es correcto cuando el handover se produce cerca de la red<br />
original del nodo móvil. En particular <strong>en</strong> este estudio se ha llevado el caso<br />
al límite produci<strong>en</strong>do el handover desde esta misma estación base a un<br />
‘Foreig Ag<strong>en</strong>t’ adyac<strong>en</strong>te.<br />
El estudio de aplicaciones que se basan <strong>en</strong> el protocolo de<br />
transporte UDP muestra que el número de paquetes perdidos es mínimo,<br />
incluso <strong>en</strong> el caso de trabajar sobre un handover abrupto que no permite<br />
una comunicación simultánea con las dos estaciones base. En esta<br />
situación se logra un tiempo de handover <strong>en</strong>tre 16 y 17 mseg.<br />
perfectam<strong>en</strong>te asumible por la mayoría de las aplicaciones multimedia.<br />
Es destacable el hecho de que <strong>en</strong> handovers blandos la pérdida de<br />
paquetes es nula a no ser que se fuerce el protocolo hasta puntos <strong>en</strong> los<br />
que el nodo móvil permanece m<strong>en</strong>os del tiempo <strong>en</strong> la zona de solape que el<br />
tiempo exist<strong>en</strong>te <strong>en</strong>tre m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’. Ante esta situación<br />
el protocolo perderá paquetes de manera proporcional a la tasa (figura<br />
5.7). Unas posible solución a esta circunstancia sería una disminución del<br />
tiempo <strong>en</strong>tre <strong>en</strong>vío de estos m<strong>en</strong>sajes de anuncio o bi<strong>en</strong> una comunicación<br />
<strong>en</strong>tre la capa dos y tres para forzar este <strong>en</strong>vío.<br />
173
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
También las aplicaciones que trabajan sobre TCP ti<strong>en</strong><strong>en</strong> un<br />
funcionami<strong>en</strong>to relativam<strong>en</strong>te correcto. Si trabajamos con redes que<br />
ofrec<strong>en</strong> un handover abrupto la pérdida de conexión provoca una<br />
retransmisión de paquetes. El protocolo TCP supone que el v<strong>en</strong>cimi<strong>en</strong>to de<br />
temporizadores de retransmisión se debe a que la red está congestionada<br />
por lo que se lanza el mecanismo de ‘arranque l<strong>en</strong>to’ (fig. 5.8). En todo<br />
caso el número máximo de retransmisiones debidas al handover será de<br />
una.<br />
En el caso de trabajar con handovers blandos, el comportami<strong>en</strong>to<br />
es excel<strong>en</strong>te cuando el tiempo de perman<strong>en</strong>cia es sufici<strong>en</strong>te para la<br />
recepción de los m<strong>en</strong>sajes de anuncio y el desarrollo del handover. Si<br />
disminuimos considerablem<strong>en</strong>te este tiempo de perman<strong>en</strong>cia el<br />
comportami<strong>en</strong>to es similar al del handover abrupto, produciéndose errores<br />
<strong>en</strong> la recepción de segm<strong>en</strong>tos TCP que serán retransmitidos tras el<br />
v<strong>en</strong>cimi<strong>en</strong>to del temporizador correspondi<strong>en</strong>te.<br />
5.4 ESTUDIO DEL HANDOVER LEJANO DEL<br />
PROTOCOLO ‘MOBILE IP’<br />
Los resultados, razonablem<strong>en</strong>te satisfactorios, obt<strong>en</strong>idos <strong>en</strong> el<br />
punto anterior están condicionados a la proximidad <strong>en</strong>tre el Home Ag<strong>en</strong>t y<br />
el Foreign Ag<strong>en</strong>t destino del nodo móvil. En particular esto se ha llevado al<br />
extremo pues, una de las dos estaciones base implicadas <strong>en</strong> el handover es<br />
el propio HA. Sin embargo hay ocasiones <strong>en</strong> las que el nodo móvil se<br />
<strong>en</strong>contrará situado lejos de su Home Ag<strong>en</strong>t, y <strong>en</strong> estos casos el protocolo<br />
Mobile IP va a ofrecer unas prestaciones muy defici<strong>en</strong>tes. Como ya se ha<br />
estudiado, el motivo fundam<strong>en</strong>tal de esto es que cada proceso de<br />
handover, indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de la frecu<strong>en</strong>cia con que se produzca,<br />
implica un <strong>en</strong>vío de m<strong>en</strong>sajes de registro hacia el HA.<br />
En este punto va a realizarse un estudio de prestaciones del<br />
protocolo cuando el nodo móvil se <strong>en</strong>cu<strong>en</strong>tra alejado del HA. La<br />
implem<strong>en</strong>tación realizada se muestra <strong>en</strong> la figura 5.12. En ella puede<br />
174
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
observarse como el nodo móvil realiza un handover <strong>en</strong>tre dos estaciones lo<br />
sufici<strong>en</strong>tem<strong>en</strong>te cercanas <strong>en</strong>tre si para que exista solape de coberturas,<br />
pero alejados del HA. En particular se han realizado mediciones con<br />
distintos retardos <strong>en</strong>tre el router que da conectividad a las estaciones base<br />
y el Home Ag<strong>en</strong>t.<br />
A continuación se detallan los trabajos realizados para estudiar el<br />
comportami<strong>en</strong>to del handover, tanto <strong>en</strong> aplicaciones basadas <strong>en</strong> el<br />
protocolo UDP, como de aquellas que utilizan el protocolo TCP.<br />
Home Ag<strong>en</strong>t<br />
Host<br />
Retardo<br />
variable<br />
5 Mbps<br />
20ms<br />
5 Mbps<br />
2 ms<br />
Router<br />
5 Mbps<br />
2 ms<br />
Foreign Ag<strong>en</strong>t 1<br />
Foreign Ag<strong>en</strong>t 2<br />
Nodo Móvil<br />
Figura 5.12 Configuración para estudiar el handover lejano <strong>en</strong> MIP.<br />
5.4.1 Estudio del tráfico UDP <strong>en</strong> Handover Lejano<br />
Con el fin de poder comparar los resultados con los obt<strong>en</strong>idos <strong>en</strong> el<br />
estudio del handover cercano se han mant<strong>en</strong>ido las condiciones de<br />
contorno. Es decir, se ha conectado un ag<strong>en</strong>te UDP al Host fijo de la<br />
175
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
figura, sobre el que se ha instalado un g<strong>en</strong>erador CBR con tamaño de<br />
paquete fijo igual a 500 bytes, modificándose el tiempo <strong>en</strong>tre los mismos.<br />
Handover ‘Break before Make’<br />
En la figura sigui<strong>en</strong>te se muestra el número de paquetes perdidos<br />
durante un handover abrupto, donde el nodo móvil no es capaz de<br />
comunicarse simultáneam<strong>en</strong>te con las dos estaciones base. Se han<br />
realizado distintas simulaciones variando el retardo <strong>en</strong>tre el Home Ag<strong>en</strong>t y<br />
el router que da conectividad a las Estaciones Base implicadas <strong>en</strong> el<br />
handover. Las variaciones <strong>en</strong> este retardo han ido desde 60 mseg. a 300,<br />
pasando por 120 y 180 mseg. Cada valor de la gráfica es el resultado de<br />
100 simulaciones con distintas semillas, obt<strong>en</strong>iéndose siempre un<br />
coefici<strong>en</strong>te de variación CV m<strong>en</strong>or que 0.06.<br />
Figura 5.13 Estudio de segm<strong>en</strong>tos UDP perdidos <strong>en</strong> un handover abrupto lejano.<br />
Puede observarse como el número de paquetes perdidos crece de<br />
manera lineal a la tasa y a la distancia <strong>en</strong> la que se <strong>en</strong>cu<strong>en</strong>tra el Home<br />
176
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Ag<strong>en</strong>t. El primer factor m<strong>en</strong>cionado, la tasa, ya fue detallado cuando se<br />
estudió el handover cercano. Durante el tiempo de handover el nodo móvil<br />
no puede recibir paquetes ya que estamos ante un handover abrupto. El<br />
número de paquetes perdidos (suponi<strong>en</strong>do las colas vacías) será los<br />
trasmitidos <strong>en</strong> ese tiempo, lo que evid<strong>en</strong>tem<strong>en</strong>te dep<strong>en</strong>de directam<strong>en</strong>te de<br />
la tasa a la que se transmite.<br />
La dep<strong>en</strong>d<strong>en</strong>cia del número de paquetes perdidos con la distancia<br />
del HA también es directa. El tiempo de handover de capa tres, calculado<br />
como la difer<strong>en</strong>cia <strong>en</strong>tre el tiempo <strong>en</strong> que se <strong>en</strong>vía el Ag<strong>en</strong>t Advertisem<strong>en</strong>t<br />
y el instante <strong>en</strong> que el Nodo Móvil recibe el m<strong>en</strong>saje Registration Reply (ver<br />
figura 5.3), aum<strong>en</strong>ta a medida que el HA se <strong>en</strong>cu<strong>en</strong>tra más alejado del FA<br />
que recibe al nodo móvil. En la tabla 5.1 se muestran los tiempos medios<br />
de handover para las cuatro situaciones de la tabla 5.13. Cada uno de los<br />
valores se ha realizado a partir de 100 simulaciones.<br />
Distancia del Home<br />
Ag<strong>en</strong>t<br />
Tiempo medio de<br />
Handover<br />
60 mseg. 134.52 mseg.<br />
120 mseg. 254.38 mseg.<br />
180 mseg. 374.37 mseg.<br />
300 mseg. 614.37 mseg<br />
Tabla 5.1 Tiempo de Handover.<br />
En la gráfica 5.14 se observa el tiempo exist<strong>en</strong>te <strong>en</strong>tre el último<br />
paquete recibido vía el Foreign Ag<strong>en</strong>t 1 y el primero que se ha recibido<br />
utilizando el Foreign Ag<strong>en</strong>t 2 una vez ha terminado el proceso de handover.<br />
Como hemos demostrado anteriorm<strong>en</strong>te este tiempo medio dep<strong>en</strong>de<br />
de dos factores, la tasa de transmisión y el tiempo medio de handover. En<br />
tasas de transmisión bajas se observa retardos ligeram<strong>en</strong>te más elevados.<br />
Por ejemplo la simulación con 60mseg. de retardo a una tasa de 80 Kbps.<br />
177
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
provoca un tiempo <strong>en</strong>tre paquetes de 18 mseg. Este valor lo podemos<br />
<strong>en</strong>t<strong>en</strong>der como la suma de dos factores, el primero el tiempo de g<strong>en</strong>eración<br />
del paquete (50 mseg), el segundo el provocado por la pérdida de paquetes,<br />
que <strong>en</strong> este caso este caso es, según la figura 5.13 de 2.71 paquetes.<br />
Figura 5.14 Tiempo <strong>en</strong> mseg. <strong>en</strong>tre paquetes durante el handover.<br />
A medida que la tasa aum<strong>en</strong>ta las gráficas se estabilizan. Por<br />
ejemplo, la del retardo de 60 mseg. ti<strong>en</strong>de a un tiempo medio de 140 mseg.<br />
Ahora el tiempo <strong>en</strong>tre paquetes deja de ser tan determinante, y el valor al<br />
que se ti<strong>en</strong>de es debido, fundam<strong>en</strong>talm<strong>en</strong>te, al tiempo de intercambio de<br />
m<strong>en</strong>sajes de señalización del protocolo ‘Mobile IP’ durante el handover<br />
(134.52 mseg. según la tabla 5.1). La difer<strong>en</strong>cia <strong>en</strong>tre los dos valores es<br />
porque hay que t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta el tiempo necesario para <strong>en</strong>viar el primer<br />
paquete vía FA2.<br />
La figura 5.15 muestra la temporización secu<strong>en</strong>cia de m<strong>en</strong>sajes de<br />
señalización del proceso de handover. En este caso la tasa es de 800 Kbps.<br />
y se muestra el comportami<strong>en</strong>to para retardos de 60, 180 y 300 mseg.<br />
178
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.15 Ev<strong>en</strong>tos <strong>en</strong> un Handover lejano con tasa 800Kbps y distintos retardos.<br />
179
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Las figuras anteriores muestran claram<strong>en</strong>te como, al aum<strong>en</strong>tar el<br />
retardo <strong>en</strong>tre el HA y la zona donde se produce el handover, el intercambio<br />
de m<strong>en</strong>sajes del protocolo Mobile IP se alarga <strong>en</strong> el tiempo aum<strong>en</strong>tando de<br />
manera alarmante el número de paquetes perdidos, aunque la tasa de<br />
transmisión se manti<strong>en</strong>e constante. También puede comprobarse la<br />
variación del retardo <strong>en</strong>tre la transmisión desde el CN y recepción final por<br />
el nodo móvil. Hay que indicar que los m<strong>en</strong>sajes marcado <strong>en</strong> rojo nunca<br />
llegan al receptor, y que se han incluido <strong>en</strong> la gráfica simplem<strong>en</strong>te por<br />
claridad.<br />
La figura 5.16 muestra la temporización de los m<strong>en</strong>sajes cuando<br />
variamos la tasa de transmisión (400 y 1600 Kbps) mant<strong>en</strong>i<strong>en</strong>do constante<br />
el resto de parámetros.<br />
Figura 5.16 a. Ev<strong>en</strong>tos <strong>en</strong> un Handover lejano con retardo 120mseg y 400 Kbps.<br />
180
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.16 b. Ev<strong>en</strong>tos <strong>en</strong> un Handover lejano con retardo 120mseg y 1600 Kbps.<br />
La figura anterior muestra claram<strong>en</strong>te que el número de paquetes<br />
perdidos aum<strong>en</strong>ta linealm<strong>en</strong>te con la tasa, si<strong>en</strong>do el tiempo de realización<br />
del handover constante <strong>en</strong> torno a los 250 mseg.<br />
Handover ‘Make before Break’<br />
Tras comprobar el empeorami<strong>en</strong>to de los resultados <strong>en</strong> el handover<br />
lejano respecto del handover cercano, pasamos a utilizar una posible<br />
solución para mejorar estas prestaciones. Realizamos un estudio sobre la<br />
utilización de un handover blando que permitirá, como se ha visto<br />
anteriorm<strong>en</strong>te, la conexión del nodo móvil con más de una estación base<br />
simultáneam<strong>en</strong>te.<br />
Para comparar resultados hemos utilizado los mismos parámetros<br />
empleados anteriorm<strong>en</strong>te <strong>en</strong> las simulaciones. En la figura 5.17 hemos<br />
simulado la situación <strong>en</strong> la cual el nodo móvil se desplazaba a 20 m/seg. a<br />
través de una zona de solape de 30m. La gráfica se ha obt<strong>en</strong>ido a partir de<br />
100 simulaciones.<br />
181
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.17: Paquetes perdidos con 300 ms de retardo, 20 m/s y 30 m de solape.<br />
A pesar de que el nuevo Foreign Ag<strong>en</strong>t <strong>en</strong>vía un m<strong>en</strong>saje ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t’ cada segundo, y que <strong>en</strong> este caso el nodo móvil tarda 1.5<br />
segundos <strong>en</strong> atravesar la zona de solape se produc<strong>en</strong> pérdidas de<br />
paquetes. El motivo es el tiempo necesario para realizar el registro, que<br />
para este retardo está <strong>en</strong> torno a los 614 mseg. Existe una probabilidad de<br />
que el nodo móvil reciba el m<strong>en</strong>saje de anuncio <strong>en</strong> un instante de tiempo<br />
<strong>en</strong> el que no puede completarse el registro d<strong>en</strong>tro de la zona de solape.<br />
Con los valores anteriores esta probabilidad se sitúa <strong>en</strong> torno al 7.6 %. Sin<br />
embargo, comparando está gráfica con la obt<strong>en</strong>ida <strong>en</strong> caso de handover<br />
abrupto (figura 5.13), puede deducirse que la mejora es muy significativa.<br />
En la sigui<strong>en</strong>te figura 5.18 variamos las condiciones de la<br />
simulación. Ahora el nodo móvil se desplaza a una velocidad de 30 m/s a<br />
través de una zona de solape de 20 m, por lo que sólo permanecerá 666<br />
mseg. <strong>en</strong> el área de solape.<br />
Esta situación provoca que, aunque se utilice handover blando,<br />
siga habi<strong>en</strong>do una pérdida de paquetes. El escaso tiempo de perman<strong>en</strong>cia<br />
<strong>en</strong> la zona de solape unido al retardo <strong>en</strong>tre el Home Ag<strong>en</strong>t y las estaciones<br />
182
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
base, provoca que las pérdidas no disminuyan tanto con respecto al<br />
handover abrupto como el caso anterior, obt<strong>en</strong>i<strong>en</strong>do reducciones alrededor<br />
del 35.8 % para retardos elevados, 180 mseg. y 300 mseg., y del 40 %<br />
para retardos de 60 mseg. y 120 mseg.<br />
Figura 5.18: Paquetes perdidos a 30 m/s con 20 m de solape.<br />
5.4.2 Estudio del tráfico TCP <strong>en</strong> Handover Lejano<br />
En el sigui<strong>en</strong>te punto se describe los trabajos realizados para<br />
estudiar el comportami<strong>en</strong>to de las aplicaciones que funcionan sobre TCP,<br />
<strong>en</strong> el caso de que se produzca un handover lejano. El sistema simulado es<br />
el mismo que se mostró <strong>en</strong> la figura 5.12. Con respecto al trabajo<br />
pres<strong>en</strong>tado <strong>en</strong> el punto anterior simplem<strong>en</strong>te se ha sustituido los ag<strong>en</strong>tes<br />
UDP por ag<strong>en</strong>tes TCP Vegas. Sobre el ag<strong>en</strong>te del nodo transmisor se ha<br />
instalado una aplicación FTP que estará activa mi<strong>en</strong>tras se produzca el<br />
proceso de handover.<br />
183
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Handover ‘Break before Make’<br />
Como <strong>en</strong> los estudios anteriores com<strong>en</strong>zamos estudiando el<br />
comportami<strong>en</strong>to durante un handover abrupto. Se han realizado dos<br />
grupos de simulaciones variando el retardo exist<strong>en</strong>te <strong>en</strong>tre el Home Ag<strong>en</strong>t y<br />
el router que <strong>en</strong>laza a los Foreign Ag<strong>en</strong>t que van a dar conectividad al nodo<br />
móvil.<br />
La figura 5.19 muestra los m<strong>en</strong>sajes de señalización y los paquetes<br />
transmitidos y recibidos durante un handover abrupto, cuando el retardo<br />
<strong>en</strong>tre el Home Ag<strong>en</strong>t y el router que conecta a los FA es de 60 mseg.<br />
Figura 5.19 Handover abrupto lejano (60mseg) durante una transmisión TCP.<br />
En la gráfica puede observarse el retardo <strong>en</strong>tre la transmisión y la<br />
recepción de los segm<strong>en</strong>tos, y la interrupción que produce el transmisor<br />
tras el paquete 1612 debido al tamaño de la v<strong>en</strong>tana de transmisión. Al<br />
igual que ocurría <strong>en</strong> el handover cercano (figura 5.8), el intercambio de<br />
m<strong>en</strong>sajes del protocolo Mobile IP se produce durante el tiempo de espera de<br />
retransmisión del protocolo TCP. Una vez el nodo móvil ha recuperado la<br />
conexión vía FA2, comi<strong>en</strong>za a recibir los segm<strong>en</strong>tos re<strong>en</strong>viados por el<br />
184
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
transmisor utilizando el conocido mecanismo de ‘arranque l<strong>en</strong>to’,<br />
claram<strong>en</strong>te visible <strong>en</strong> la parte derecha de al figura.<br />
La figura 5.20 muestra el ‘throughput’ medido <strong>en</strong> el receptor<br />
durante el handover. Observamos como disminuye y se recupera tras el<br />
proceso volvi<strong>en</strong>do a alcanzar los valores previos, esta vez recibi<strong>en</strong>do desde<br />
FA2. La difer<strong>en</strong>cia de valores ante y después del handover que observamos<br />
<strong>en</strong> el handover cercano (figura 5.9) no se muestra aquí, ya que las rutas<br />
CN-HA-FA1 y CN-HA-FA2 son idénticas (figura 5.12).<br />
Figura 5.20. ‘Throughput’ <strong>en</strong> bytes/seg. <strong>en</strong> un handover abrupto lejano (60 mseg.)<br />
Para finalizar repetimos las simulaciones aum<strong>en</strong>tando el retardo<br />
<strong>en</strong>tre el HA y la zona del handover a 300 mseg. La figura 5.21 muestra los<br />
resultados donde apreciamos difer<strong>en</strong>cia del aum<strong>en</strong>to de tiempo <strong>en</strong>tre<br />
transmisión y recepción de los paquetes que pasa a ser de poco más de<br />
620 mseg. Esta circunstancia provoca que el registro con el nuevo ‘Foreign<br />
Ag<strong>en</strong>t’ no se efectúe d<strong>en</strong>tro del tiempo de ‘time out’ que espera el<br />
transmisor para re<strong>en</strong>viar por primera vez los paquetes no reconocidos.<br />
185
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.21 Handover abrupto lejano (300mseg) durante una transmisión TCP.<br />
Figura 5.22 Ampliación de la figura 5.21.<br />
En la figura 5.22 se muestra ampliado el intercambio de m<strong>en</strong>sajes<br />
que se produce <strong>en</strong> el handover de la figura 5.21. Como se aprecia, el<br />
186
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
m<strong>en</strong>saje ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ de FA2 se recibe después de finalizar el<br />
primer ‘Time Out’, lo que provoca la espera de un segundo tiempo de<br />
retransmisión, que <strong>en</strong> este caso es de dos segundos. Podemos indicar que<br />
estamos ante la peor situación pues han pasado tres segundos desde el<br />
<strong>en</strong>vío del último paquete recibido antes del handover y la recepción del<br />
primer segm<strong>en</strong>to vía FA2.<br />
En el otro extremo t<strong>en</strong>emos la figura 7.23 donde el m<strong>en</strong>saje de<br />
anuncio de FA2 se recibe prácticam<strong>en</strong>te después de que el nodo móvil<br />
abandona la zona de cobertura de FA1. Esto permite que el registro se<br />
realice mi<strong>en</strong>tras CN espera el primer ‘Time Out’ agilizándose todo el<br />
proceso.<br />
Figura 5.23 Handover abrupto lejano (300mseg) durante una transmisión TCP.<br />
Situación óptima.<br />
Las figura 5.24 y 5.25 muestran el ‘throughput’ de las simulaciones<br />
que se han mostrado anteriorm<strong>en</strong>te (fig. 5.21 y 5.23 respectivam<strong>en</strong>te). En<br />
ellas se observa la disminución debida al handover y como se va<br />
recuperando l<strong>en</strong>tam<strong>en</strong>te a causa del mecanismo de inicio l<strong>en</strong>to.<br />
187
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.24. ‘Throughput’ <strong>en</strong> un handover abrupto lejano (300 mseg.) con TCP.<br />
Figura 5.25. ‘Throughput’ <strong>en</strong> un handover abrupto lejano (300 mseg.) con TCP.<br />
Situación óptima.<br />
En comparación con la figura 7.20 observamos como los valores de<br />
‘Throughput’ alcanzados ahora son inferiores. La causa de este f<strong>en</strong>óm<strong>en</strong>o<br />
es la distancia del HA de la zona de handover. Debido a que el CN debe<br />
<strong>en</strong>viar al HA y éste re<strong>en</strong>viar al FA correspondi<strong>en</strong>te, al aum<strong>en</strong>tar la<br />
distancia aum<strong>en</strong>ta lat<strong>en</strong>cia de los paquetes. Esto provoca que los<br />
188
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
reconocimi<strong>en</strong>tos tard<strong>en</strong> más <strong>en</strong> llegar, fr<strong>en</strong>ando la capacidad de<br />
transmisión del CN.<br />
El razonami<strong>en</strong>to anterior también explica que ahora el ‘Throughput’<br />
tarda más <strong>en</strong> volver a los valores iniciales. El proceso de arranque l<strong>en</strong>to<br />
tarda más <strong>en</strong> completarse pues los paquetes y los reconocimi<strong>en</strong>tos tardan<br />
más <strong>en</strong> llegar al MN y CN respectivam<strong>en</strong>te.<br />
Handover ‘Make before Break’<br />
Hemos realizado un conjunto de simulaciones para estudiar la<br />
mejora <strong>en</strong> las prestaciones de handover lejano cuando el Nodo Móvil es<br />
capaz de comunicarse simultáneam<strong>en</strong>te con las dos Estaciones Base. Se<br />
ha empleado la misma configuración que la utilizada <strong>en</strong> las simulaciones<br />
anteriores, t<strong>en</strong>i<strong>en</strong>do ahora <strong>en</strong> cu<strong>en</strong>ta el tiempo <strong>en</strong> el que el móvil<br />
permanece <strong>en</strong> la zona de cobertura de ambas estaciones base.<br />
La figura 5.26 nos muestra una simulación <strong>en</strong> la que el nodo se<br />
desplaza a una velocidad de 30 m/seg. con una zona de solape de 20<br />
metros. El retardo <strong>en</strong>tre el HA y el router que da conectividad a los FA es<br />
de 60 mseg.<br />
Se puede apreciar a que debido a la pérdida de cobertura por parte<br />
del Foreign Ag<strong>en</strong>t 1 antes de efectuar el registro, tres paquetes no son<br />
recibidos por el MN y deb<strong>en</strong> ser retransmitidos. Es interesante destacar<br />
que ahora los tres segm<strong>en</strong>tos son retransmitidos sin t<strong>en</strong>er que esperar el<br />
‘Time Out’, pues el NM indica la pérdida tras recibir el m<strong>en</strong>saje numerado<br />
como 1404. La transmisión MN-CN se realiza sin necesidad de pasar por el<br />
HA lo que permite tiempos muy bajos <strong>en</strong>tre la recepción del paquete 1404<br />
por parte del MN y la retransmisión del paquete 1401.<br />
El ‘throughput’ que se muestra <strong>en</strong> la figura 5.27 se corresponde con<br />
la simulación anterior, donde se observa como la recuperación se realiza<br />
<strong>en</strong> tan solo dos segundos.<br />
189
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.26 Handover blando lejano (60mseg) durante una transmisión TCP.<br />
Figura 5.27 ‘Throughput’ <strong>en</strong> bytes/seg. <strong>en</strong> un handover lejano (60 mseg) blando.<br />
Para finalizar realizamos otra simulación aum<strong>en</strong>tando el retardo<br />
<strong>en</strong>tre el Home Ag<strong>en</strong>t y el router hasta un valor de 300 mseg. para<br />
comprobar el efecto que produce <strong>en</strong> un handover blando. La figura 5.28<br />
muestra la transmisión de paquetes y <strong>en</strong> la figura 5.29 está ampliado el<br />
190
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
periodo de tiempo <strong>en</strong> el que sucede el intercambio de m<strong>en</strong>sajes del<br />
protocolo ‘Mobile IP’.<br />
Figura 5.28 Handover blando lejano (300mseg) durante una transmisión TCP.<br />
Figura 5.29 Handover blando lejano (300mseg) detalle.<br />
191
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Como se aprecia <strong>en</strong> estas figuras, aunque el proceso de registro se<br />
inicia <strong>en</strong> la zona de solape de ambos FA, y debido al elevado retardo de<br />
más de 612 mseg que introduce el registro, se pierd<strong>en</strong> multitud de<br />
paquetes. Al igual que <strong>en</strong> el caso anterior, la recepción por el transmisor<br />
de segm<strong>en</strong>tos de reconocimi<strong>en</strong>to que indican este hecho produce la<br />
retransmisión de los segm<strong>en</strong>tos perdidos, sin esperar el v<strong>en</strong>cimi<strong>en</strong>to del<br />
temporizador.<br />
5.4.3 Conclusiones sobre el Handover Lejano<br />
En este punto se han estudiado las prestaciones de handover que<br />
ofrece el protocolo Mobile IP cuando el nodo móvil se <strong>en</strong>cu<strong>en</strong>tra alejado de<br />
su ‘Home Network’ (situación que hemos d<strong>en</strong>ominado ‘handover lejano’). Se<br />
han realizado un conjunto de simulaciones para estudiar el<br />
comportami<strong>en</strong>to, tanto <strong>en</strong> el caso de trabajar con el protocolo de<br />
transporte TCP, como cuando lo hacemos con el protocolo UDP.<br />
Con respecto al protocolo UDP se realizado un primer estudio <strong>en</strong> el<br />
que el handover se produce de manera abrupta, de manera que el nodo<br />
móvil sólo puede comunicarse con una estación. En este caso se ha<br />
demostrado como el aum<strong>en</strong>to de la distancia HA-FAs provoca un aum<strong>en</strong>to<br />
lineal del número de segm<strong>en</strong>tos UDP perdidos. Como ejemplo, <strong>en</strong> la figura<br />
5.13 se observa una pérdida de más de 250 paquetes cuando se transmite<br />
a tasas de 1600Kbps con un retardo de 300 mseg. Además debido a que el<br />
protocolo obliga a un registro <strong>en</strong> el HA cada vez que el móvil cambia la red,<br />
se produc<strong>en</strong> interrupciones <strong>en</strong> el nodo móvil de aproximadam<strong>en</strong>te el doble<br />
de la distancia que separa el FA del HA, ya que el registro implica un<br />
m<strong>en</strong>saje de ida y vuelta.<br />
En caso de implem<strong>en</strong>tar un handover ‘Make before Break’, donde el<br />
nodo móvil puede comunicarse simultáneam<strong>en</strong>te con las dos FAs, los<br />
resultados mejoran, siempre <strong>en</strong> situaciones <strong>en</strong> las que el nodo permanece<br />
<strong>en</strong> la zona de cobertura un tiempo sufici<strong>en</strong>te. Aun <strong>en</strong> este caso no se<br />
eliminan completam<strong>en</strong>te las pérdidas (figura 5.17). En caso de un<br />
192
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
handover rápido la pérdida de segm<strong>en</strong>tos UDP no experim<strong>en</strong>ta una mejoría<br />
importante con respecto al handover abrupto. El ejemplo anterior (tasa<br />
1600 Kbps, 300 mseg), ocasiona, con un handover blando rápido, una<br />
pérdida de 188 paquetes.<br />
Con respecto al protocolo TCP también hemos realizado estudios<br />
con los dos t<strong>ip</strong>os de tecnologías de handover (abrupto y blando). Los<br />
esquemas de handover abrupto obligan a que el nodo comi<strong>en</strong>ce el registro<br />
vía FA2 una vez perdida la conexión con FA1, lo que ocasiona una pérdida<br />
de paquetes. Como ya ocurría <strong>en</strong> el handover cercano (figura 5.8), ahora<br />
también es posible que el registro sea realizado durante el tiempo de<br />
retransmisión (Time Out) del protocolo TCP. Sin embargo, <strong>en</strong> función del<br />
retardo del HA y del mom<strong>en</strong>to <strong>en</strong> el que el MN recibe el m<strong>en</strong>saje ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t’ prov<strong>en</strong>i<strong>en</strong>te de FA2, es posible que los paquetes deban ser<br />
transmitidos una tercera vez antes de que nodo móvil los reciba. El motivo,<br />
como se apreciaba <strong>en</strong> la figura 5.21, es que el registro se completa cuando<br />
el temporizador de retrasmisión del CN ya ha v<strong>en</strong>cido.<br />
Las prestaciones estudiadas a través del ‘throughput’ también<br />
disminuy<strong>en</strong> al trabajar <strong>en</strong> situaciones de handover lejano. Adicionalm<strong>en</strong>te<br />
a la disminución de los valores máximos, que son debidas al aum<strong>en</strong>to de<br />
retardo de la ruta CN-HA-FAx, se produce una disminución considerable<br />
<strong>en</strong> el mom<strong>en</strong>to del handover. El tiempo necesario para volver a la situación<br />
de partida dep<strong>en</strong>de, princ<strong>ip</strong>alm<strong>en</strong>te, del retardo HA-FA2. Así con un<br />
retardo de 60 mseg. el ‘throughput’ alcanzaba los valores iniciales <strong>en</strong> un<br />
tiempo aproximado de 4.5 segundos (figura 5.20), mi<strong>en</strong>tras que si se<br />
aum<strong>en</strong>ta el retardo hasta 300 mseg. el tiempo de recuperación puede<br />
llegar a ser de 15 segundos (figura 5.24). El motivo es el mecanismo de<br />
arranque l<strong>en</strong>to que TCP utiliza para prev<strong>en</strong>ir la congestión. Un retardo<br />
elevado <strong>en</strong> la ruta HA-FA2 provoca un aum<strong>en</strong>to <strong>en</strong> el tiempo de recepción<br />
de los paquetes, por los que los reconocimi<strong>en</strong>tos llegan de forma más l<strong>en</strong>ta<br />
a CN, y el tamaño máximo de su v<strong>en</strong>tana de transmisión tarda más<br />
aum<strong>en</strong>tar.<br />
Por último se estudia el comportami<strong>en</strong>to del handover blando <strong>en</strong><br />
una trasmisión TCP. Es destacable el hecho de que, aun si<strong>en</strong>do probable<br />
193
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
las pérdidas de paquetes, debidas a que el proceso de registro <strong>en</strong> la nueva<br />
red puede terminar después de que el MN abandona la zona de solape,<br />
estos paquetes pued<strong>en</strong> ser recibidos por el nodo móvil sin que t<strong>en</strong>ga que<br />
v<strong>en</strong>cer el temporizador de retransmisión del transmisor. El motivo es que<br />
aum<strong>en</strong>ta la probabilidad de que el proceso de handover termine antes de<br />
que el transmisor haya transmitido toda su v<strong>en</strong>tana de transmisión. Esto<br />
provoca que el MN reciba segm<strong>en</strong>tos desord<strong>en</strong>ados, de manera que puede<br />
solicitar el <strong>en</strong>vío de los paquetes p<strong>en</strong>di<strong>en</strong>tes al CN, agilizándose todo el<br />
proceso (figura 5.26).<br />
Por tanto podemos concluir indicando que el protocolo ‘Mobile IP’<br />
introduce una pérdida de prestaciones muy importante cuando el nodo<br />
móvil se <strong>en</strong>cu<strong>en</strong>tra alejado de su red original. En el caso de aplicaciones<br />
que se basan <strong>en</strong> UDP la pérdida de segm<strong>en</strong>tos puede ser de más de 200, y<br />
<strong>en</strong> el caso de TCP puede que algunos los segm<strong>en</strong>tos llegu<strong>en</strong> al nodo móvil<br />
con más de 3 segundos de retardo adicional, t<strong>en</strong>i<strong>en</strong>do un tiempo de<br />
recuperación del handover que puede ser de hasta 15 segundos.<br />
Las prestaciones aum<strong>en</strong>tan <strong>en</strong> el caso de implem<strong>en</strong>tar tecnologías<br />
de capa 2 que permitan el handover blando, con conexión simultánea del<br />
MN con los dos FAs implicados. Aun <strong>en</strong> este caso se pierd<strong>en</strong> segm<strong>en</strong>tos<br />
UDP y se retrasa <strong>en</strong> exceso la recepción de segm<strong>en</strong>tos TCP, aunque <strong>en</strong> este<br />
caso el comportami<strong>en</strong>to va a dep<strong>en</strong>der, además del retardo HA-FA, del<br />
tiempo de perman<strong>en</strong>cia <strong>en</strong> la zona de solape.<br />
5.5 ESTUDIO DE PRESTACIONES DE LOS SISTEMAS<br />
DE MICRO - MOVILIDAD.<br />
Como acabamos de estudiar, la necesidad de realizar un registro<br />
con el Home Ag<strong>en</strong>t cada vez que el nodo móvil cambia de red hace que la<br />
lat<strong>en</strong>cia del proceso de handover aum<strong>en</strong>te hasta cotas inaceptables <strong>en</strong><br />
aplicaciones de tiempo real. Con el fin de reducir este tiempo <strong>en</strong> el punto<br />
2.4 se explicó como actualm<strong>en</strong>te se ti<strong>en</strong>de a soluciones consist<strong>en</strong>tes <strong>en</strong><br />
dividir la red <strong>en</strong> dominios. Esto permite implem<strong>en</strong>tar las soluciones de<br />
194
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
<strong>movilidad</strong> <strong>en</strong> dos (o varios) niveles. Las difer<strong>en</strong>tes soluciones para realizar<br />
el proceso de handover que ofrec<strong>en</strong> los sistemas de micro-<strong>movilidad</strong><br />
propuestos hasta la fecha fueron descritos <strong>en</strong> el punto 4.4.3.<br />
A continuación se va a realizar un estudio por simulación sobre las<br />
prestaciones de alguno de estos sistemas. Para realizar el trabajo partimos<br />
de la misma herrami<strong>en</strong>ta de simulación que la utilizada para el estudio del<br />
Mobile IP del punto anterior. En concreto utilizamos la versión ns-2.1b7<br />
del simulador NS-2 [NS2] bajo Sistema Operativo Linux. Sobre el<br />
simulador se ha instalado las librerías CMIS (Columbia IP Micro-Mobility<br />
Suite) [COM] que incluye las implem<strong>en</strong>taciones de los sistemas de micro<strong>movilidad</strong><br />
más refer<strong>en</strong>ciados (Cellular IP [CAM00], Hawaii [RAM99], y<br />
Mobile IP con registro regional [GUS02]).<br />
Más que realizar una comparación de los difer<strong>en</strong>tes sistemas de<br />
micro-<strong>movilidad</strong> exist<strong>en</strong>tes <strong>en</strong> la actualidad, el objetivo es simplem<strong>en</strong>te<br />
obt<strong>en</strong>er unos valores de refer<strong>en</strong>cia que nos sirvan para comprobar las<br />
mejoras que ofrec<strong>en</strong> estos sistemas <strong>en</strong> comparación con el protocolo Mobile<br />
IP, así como para compararlos con el sistema de micro-<strong>movilidad</strong> <strong>multicast</strong><br />
que pres<strong>en</strong>tamos <strong>en</strong> el capítulo 3. Un estudio más detallado realizado con<br />
estas mismas herrami<strong>en</strong>tas puede <strong>en</strong>contrarse <strong>en</strong> [CAM02].<br />
Para realizar el estudio se ha implem<strong>en</strong>tado la situación mostrada<br />
<strong>en</strong> la figura 5.30. En Cellular IP cada Wi y APi corresponde con un nodo<br />
Cellular IP, actuando W0 como ‘Gateway’ del dominio. En Hawaii estos<br />
nodos son routers son capacidad de <strong>en</strong>rutami<strong>en</strong>to Hawaii, mi<strong>en</strong>tras que<br />
W0 es el d<strong>en</strong>ominado ‘Router Raíz del Dominio’. Para finalizar cuando<br />
estudiemos el protocolo Mobile IP con registro regional la función GFA se<br />
implem<strong>en</strong>ta <strong>en</strong> W0, los nodos Wi restantes son routers tradicionales y los<br />
APi implem<strong>en</strong>tan la capacidad de Foreign Ag<strong>en</strong>t. En todas las situaciones<br />
vamos a asumir que esta red es la red original del MN (Home Network), de<br />
manera que los paquetes son <strong>en</strong>viados desde el CN sin ningún t<strong>ip</strong>o de<br />
<strong>en</strong>capsulación.<br />
195
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
CH<br />
W0<br />
5 Mbps<br />
2 ms<br />
W1<br />
W2<br />
W3 W4 W5<br />
AP1 AP2 AP3 AP4<br />
IEEE 802.11b<br />
Nodo Móvil<br />
Figura 5.30 Situación implem<strong>en</strong>tada para el estudio de los protocolos de micro<strong>movilidad</strong>.<br />
Como <strong>en</strong> puntos anteriores de este capítulo se va a realizar el<br />
estudio <strong>en</strong> dos situaciones distintas dep<strong>en</strong>di<strong>en</strong>do de si se emplea, a nivel<br />
de transporte, el protocolo UDP o el protocolo TCP.<br />
5.5.1 Estudio del tráfico UDP <strong>en</strong> Sistemas de Micro-Movilidad<br />
Con el fin de poder comparar los resultados con los obt<strong>en</strong>idos <strong>en</strong><br />
los puntos 5.3 y 5.4 de este mismo capítulo se va a utilizar el mismo t<strong>ip</strong>o<br />
de tráfico que el empleado <strong>en</strong>tonces. Es decir, conectamos un ag<strong>en</strong>te UDP<br />
sobre el <strong>en</strong> CN de la figura anterior. Sobre este ag<strong>en</strong>te se ha instalado un<br />
g<strong>en</strong>erador de tráfico CBR que va a permitir estudiar, de manera s<strong>en</strong>cilla,<br />
las prestaciones durante el handover. Los m<strong>en</strong>sajes UDP ti<strong>en</strong><strong>en</strong> un tamaño<br />
constante de 500 bytes y se va a modificar el tiempo <strong>en</strong>tre los mismos. Los<br />
paquetes IP son dirigidos, evid<strong>en</strong>tem<strong>en</strong>te, hacia el nodo móvil.<br />
196
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
La figura 5.31 muestra el número de paquetes perdidos por el<br />
protocolo Cellular IP cuando se realiza tanto el caso de ‘Hard Handover’<br />
como <strong>en</strong> ‘SemiSoft Handover’ (ver punto 4.4.3). Para la realización de esta<br />
figura se ha tomado una tasa de transmisión CBR de 400 Kbps, una zona<br />
de solape <strong>en</strong>tre estaciones de 30 metros y una velocidad del nodo móvil de<br />
20 m/seg. El eje horizontal muestra la distancia hasta el nodo de cruce<br />
<strong>en</strong>tre estaciones base donde se realiza el handover. Así, y según la figura<br />
5.30, un handover <strong>en</strong>tre AP1 y AP2 ti<strong>en</strong>e una distancia de 1, <strong>en</strong>tre AP2 y<br />
AP3 una distancia de 2, y <strong>en</strong>tre AP3 y AP4 una distancia de 3. La figura se<br />
ha obt<strong>en</strong>ido a partir de 100 simulaciones indep<strong>en</strong>di<strong>en</strong>tes, <strong>en</strong> cada una de<br />
la cuales el MN viaja de un extremo al otro del dominio.<br />
2<br />
Paquetes Perdidos<br />
1,8<br />
1,6<br />
1,4<br />
1,2<br />
1<br />
0,8<br />
0,6<br />
0,4<br />
0,2<br />
0<br />
Hard<br />
SemiSoft<br />
0 0 0<br />
1 2 3<br />
Distancia al nodo de cruce<br />
Figura 5.31 Paquetes perdidos <strong>en</strong> Cellular IP.<br />
La figura anterior muestra como las pérdidas nulas <strong>en</strong> el handover<br />
‘SemiSoft’ y muy bajas <strong>en</strong> al ‘Hard Handover’. Estos valores del handover<br />
abrupto son totalm<strong>en</strong>te comparables a los obt<strong>en</strong>idos <strong>en</strong> el protocolo ‘Mobile<br />
IP’ cuando el handover se producía directam<strong>en</strong>te <strong>en</strong>tre <strong>en</strong> HA y un FA (ver<br />
figura 5.2). Por otra parte debido al funcionami<strong>en</strong>to del handover<br />
semisuave las pérdidas son nulas cuando el tiempo del MN <strong>en</strong> la zona<br />
solape está <strong>en</strong> valores normales (<strong>en</strong> torno a ci<strong>en</strong>tos de milisegundos). Tan<br />
197
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
solo <strong>en</strong> simulaciones donde el tiempo de estancia <strong>en</strong> la zona de solape es<br />
mínimo se han logrado perder paquetes utilizando este esquema.<br />
La figura 5.32 muestra el comportami<strong>en</strong>to de este sistema cuando<br />
aum<strong>en</strong>tamos la tasa de transmisión mant<strong>en</strong>i<strong>en</strong>do constantes los restantes<br />
parámetros. El número de paquetes perdido es la media de todos los<br />
handovers producidos (indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de la distancia al nodo de<br />
cruce). Como <strong>en</strong> el caso anterior se observa que el handover abrupto es<br />
comparable al realizado <strong>en</strong> ‘Mobile IP’ cercano, mi<strong>en</strong>tras que utilizando el<br />
handover semisuave las pérdidas sigu<strong>en</strong> nulas, aunque se produc<strong>en</strong><br />
duplicaciones <strong>en</strong> el nodo móvil.<br />
Figura 5.32 Paquetes perdidos <strong>en</strong> Cellular IP <strong>en</strong> función de la Tasa.<br />
Se han realizado simulaciones equival<strong>en</strong>tes para un sistema<br />
Hawaii. En el caso de realizar un handover UNF (Transmisión Unicast sin<br />
Reconocimi<strong>en</strong>to, ver punto 4.4.3), los resultados obt<strong>en</strong>idos son<br />
equival<strong>en</strong>tes a los que se obtuvieron para el esquema abrupto de Cellular<br />
IP. La figura 5.33 nos muestra el número de paquetes perdidos <strong>en</strong> los<br />
sistemas Cellular IP, Hawaii UNF y como Mobile IP con registro regional.<br />
Los parámetros utilizados son los mismos que los empleados para la figura<br />
198
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
5.31, y como <strong>en</strong> anteriores ocasiones está realizada a partir de 100<br />
simulaciones indep<strong>en</strong>di<strong>en</strong>tes.<br />
2,5<br />
2<br />
Cellular IP Hard<br />
Hawaii UNF<br />
MIP HH RR<br />
Paquetes perdidos<br />
1,5<br />
1<br />
0,5<br />
0<br />
1 2 3<br />
Distancia al nodo de cruce<br />
Figura 5.33 Paquetes perdidos <strong>en</strong> Cellular IP, Hawaii UNF, y MIP RR.<br />
De la figura anterior es interesante destacar que, a pesar de que el<br />
número de paquetes perdidos es muy bajo <strong>en</strong> todos los casos, el protocolo<br />
Mobile IP con Registro Regional es el que peor comportami<strong>en</strong>to ti<strong>en</strong>e<br />
cuando el handover se realiza <strong>en</strong>tre FAs con distancia hasta el nodo de<br />
cruce de valor 1. Esto se debe a que según este esquema el m<strong>en</strong>saje de<br />
registro debe alcanzar el GFA, no bastando con llegar al nodo de cruce.<br />
Para finalizar el breve estudio sobre comportami<strong>en</strong>to de los<br />
protocolos de micro-<strong>movilidad</strong> bajo el protocolo UDP, estudiamos el<br />
comportami<strong>en</strong>to del sistema Hawaii cuando se produce un handover MSF<br />
(Envío por múlt<strong>ip</strong>les flujos). Según se estudio anteriorm<strong>en</strong>te, este esquema<br />
la estación base previa recibe un m<strong>en</strong>saje de handover y re<strong>en</strong>camina los<br />
paquetes almac<strong>en</strong>ados <strong>en</strong> un buffer hacia al nueva estación base para su<br />
posterior retransmisión al MN. Esta solución puede provocar que algunos<br />
paquetes llegu<strong>en</strong> al nodo móvil duplicados o desord<strong>en</strong>ados. La figura 3.34<br />
nos muestra el número medio de paquetes duplicados cuando se emplea<br />
este proceso. La tasa de transmisión es de 400 Kbps y se ha realizado sólo<br />
199
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
<strong>en</strong> el handover <strong>en</strong>tre las estaciones AP3 y AP4 (distancia 3 hasta el nodo<br />
de cruce), ya que <strong>en</strong> los otros handovers las pérdidas eran despreciables.<br />
El eje horizontal nos muestra el tiempo <strong>en</strong> mseg. que oBS almac<strong>en</strong>a los<br />
paquetes <strong>en</strong> un buffer.<br />
Handover FA3-<br />
FA4<br />
Figura 5.34 Paquetes duplicados <strong>en</strong> Hawaii MSF.<br />
5.5.2 Estudio del tráfico TCP <strong>en</strong> Sistemas de Micro-Movilidad<br />
De manera similar se ha realizado un breve estudio con el fin de<br />
estudiar el comportami<strong>en</strong>to de los difer<strong>en</strong>tes sistemas de micro-<strong>movilidad</strong><br />
cuando se trabaja con el protocolo TCP. Como <strong>en</strong> estudios anteriores<br />
hemos optado por la versión TCP Vegas [BRA94], y sobre este ag<strong>en</strong>te se ha<br />
instalado una aplicación FTP que va a estar activa mi<strong>en</strong>tras se produce el<br />
proceso de handover.<br />
La figura 5.35 muestra el handover abrupto del sistema ‘Cellular IP’<br />
<strong>en</strong>tre las estaciones AP1 y AP2 de la figura 5.30. Se ha tomado un tiempo<br />
de <strong>en</strong>vío de paquetes de actualización (route-update time) de 100 mseg.<br />
[CAM00]. En la figura observamos como el handover abrupto se traduce <strong>en</strong><br />
200
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
un tiempo de interrupción m<strong>en</strong>or de 500 mseg. Este valor es inferior a los<br />
1000 mseg. que se obtuvieron <strong>en</strong> el protocolo ‘Mobile IP’ (ver figura 5.8), y<br />
esto es debido a que <strong>en</strong> ese caso periodo de <strong>en</strong>vío de m<strong>en</strong>sajes ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t’ era de un segundo. Como <strong>en</strong> anteriores simulaciones se<br />
observa el ‘arranque l<strong>en</strong>to’ tradicional del protocolo TCP.<br />
Se han realizado simulaciones similares con el sistema Hawaii<br />
utilizando el mecanismo de handover UNF, y los resultados son totalm<strong>en</strong>te<br />
equival<strong>en</strong>tes.<br />
Figura 5.35 Hard Handover de Cellular IP con transmisión TCP.<br />
La figura 5.36 muestra una transmisión TCP <strong>en</strong> un sistema Cellular<br />
IP cuando se emplea el handover semisuave. En concreto se muestra al<br />
handover <strong>en</strong>tre las estaciones AP1 y AP2. Se ha tomado un tiempo de<br />
retardo para realizar la conexión final con AP2 de 300 mseg [CAM00].<br />
Claram<strong>en</strong>te se observa la mejora con respecto a la figura anterior, ya que<br />
ahora no se produce interrupción alguna <strong>en</strong> el handover.<br />
201
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.36 SemiSoft Handover <strong>en</strong> Cellular IP con transmisión TCP.<br />
Figura 5.37 Handover MSF <strong>en</strong> Hawaii con transmisión TCP.<br />
Para finalizar mostramos una simulación sobre un handover <strong>en</strong> un<br />
sistema Hawaii con mecanismo de handover MSF. La figura 5.37 muestra<br />
202
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
el handover <strong>en</strong>tre las estacione AP3 y AP4 y se ha tomado un tiempo de<br />
almac<strong>en</strong>ami<strong>en</strong>to <strong>en</strong> el buffer de 10 mseg. Se observa que el<br />
comportami<strong>en</strong>to es similar al Cellular IP con una ligera interrupción debida<br />
al intercambio de m<strong>en</strong>sajes del protocolo [RAM99]. Puede observarse como<br />
el paquete 59 ha sido re<strong>en</strong>viado <strong>en</strong>tre las dos estaciones base y por esto<br />
alcanza el MN ligeram<strong>en</strong>te retrasado.<br />
5.5.3 Conclusiones sobre los sistemas de micro-<strong>movilidad</strong><br />
En este punto se ha realizado un breve estudio sobre los sistemas<br />
de micro-<strong>movilidad</strong> más populares actualm<strong>en</strong>te. Hemos observado como<br />
las prestaciones de estos sistemas son mucho mejores que las que ofrece<br />
el protocolo Mobile IP cuando el nodo móvil se <strong>en</strong>cu<strong>en</strong>tra lejos del la red<br />
orig<strong>en</strong> del nodo.<br />
En transmisiones haci<strong>en</strong>do uso del protocolo UDP el número de<br />
paquetes perdidos se manti<strong>en</strong>e <strong>en</strong> unos valores muy bajos<br />
indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te del sistema que se emplee. Incluso si se utilizan<br />
esquemas de handover avanzados, bi<strong>en</strong> <strong>basado</strong>s <strong>en</strong> la capacidad del nodo<br />
de recibir de las dos estaciones base de manera simultanea (Semisoft<br />
Handover <strong>en</strong> Cellular IP), o bi<strong>en</strong> utilizando redireccionami<strong>en</strong>to de paquetes<br />
<strong>en</strong>tre estaciones (MSF <strong>en</strong> Hawaii), se logra no perder un solo paquete,<br />
indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te del punto del dominio donde se realice el handover.<br />
En TCP los resultados también experim<strong>en</strong>tan una gran mejora con<br />
respecto al protocolo Mobile IP. En el caso de realizar un handover abrupto<br />
los resultados son ligeram<strong>en</strong>te mejores que el handover cercano del<br />
protocolo Mobile IP y evid<strong>en</strong>tem<strong>en</strong>te mucho mejores que el handover<br />
lejano. En el caso de utilizar handover semisuave o con<br />
redireccionami<strong>en</strong>to, la transición <strong>en</strong>tre estaciones se produce de manera<br />
perfecta, siempre que los parámetros del sistema estén correctam<strong>en</strong>te<br />
ajustados a la topología de la red y al t<strong>ip</strong>o de tráfico.<br />
203
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Estudios detallados sobre el análisis de prestaciones de estos<br />
sistemas de micro-<strong>movilidad</strong> pued<strong>en</strong> <strong>en</strong>contrarse <strong>en</strong> [CAM00] y [CAM02].<br />
5.6 IMPLEMENTACIÓN DE UN BANCO DE PRUEBAS<br />
DEL PROTOCOLO MOBILE IP<br />
En los puntos anteriores se realizaron una serie de simulaciones<br />
que nos han permitido evaluar las limitaciones del protocolo Mobile IP <strong>en</strong><br />
comparación con algunas soluciones de micro-<strong>movilidad</strong>. Con el fin de<br />
comparar los resultados anteriores con medidas reales se ha<br />
implem<strong>en</strong>tado un banco de pruebas, donde se ha evaluado las<br />
prestaciones del protocolo Mobile IP durante un handover cercano.<br />
La implem<strong>en</strong>tación se ha realizado utilizando el paquete de<br />
Movilidad IP ‘Dynamics’ [DYN] de la universidad de Helsinki. La elección de<br />
este <strong>en</strong> detrim<strong>en</strong>to de otros (MosquitoNet [MOS], o la de los laboratorios de<br />
HP [HP] ) se ha debido a ser la versión más popular <strong>en</strong> la actualidad, por<br />
ser la que está más actualizada para adaptarse a las nuevas distribuciones<br />
de Linux, y por ser la que dispone de más opciones de configuración.<br />
En la figura 5.38 se muestra el sistema instalado. Todos los nodos<br />
son PC’s con sistema operativo Linux Suse 8.1. Esta distribución era la<br />
que mejor se adaptaba a las necesidades del driver ‘Dynamic’, hasta el<br />
punto que no fue necesario recompilar el Kernel.<br />
La transmisión inalámbrica se realiza utilizando tarjetas WLAN<br />
IEEE802.11b <strong>en</strong> modo de funcionami<strong>en</strong>to Ad hoc. En concreto utilizamos<br />
tarjetas Compaq WL110. El sistema cableado se ha realizado utilizando<br />
tarjetas IEEE 802.3 (de la marca Realtek). En la figura puede observarse<br />
las direcciones y mascaras de red de los interfaces de todos los nodos.<br />
204
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Transmisor CN<br />
IP: 20.0.0.1/24<br />
IP: 20.0.0.254/24<br />
IP: 30.0.0.254/24<br />
IP: 30.0.0.2/24<br />
Home Ag<strong>en</strong>t<br />
IP: 50.0.0.3/24<br />
IP: 40.0.0.254/24<br />
IP: 40.0.0.5/24; CoA<br />
Foreign<br />
Ag<strong>en</strong>t<br />
IP: 60.0.0.7/24<br />
IP: 50.0.0.4/24<br />
Nodo Móvil<br />
Figura 5.38. Montaje realizado.<br />
Es importante destacar que los dos ag<strong>en</strong>tes (HA y FA) están<br />
funcionando <strong>en</strong> modo Ad hoc <strong>en</strong> el misma red local (mismo BBS). Es decir,<br />
ti<strong>en</strong><strong>en</strong> el mismo SSID y transmit<strong>en</strong> <strong>en</strong> el mismo canal. Esto se traduce <strong>en</strong><br />
que realm<strong>en</strong>te no existe un handover a nivel 2. El handover <strong>en</strong> Mobile IP se<br />
ejecuta a partir de una herrami<strong>en</strong>ta incluida <strong>en</strong> el paquete de <strong>movilidad</strong><br />
(dynmn_tool), que nos ofrece una gran versatilidad <strong>en</strong> la configuración del<br />
t<strong>ip</strong>o de handover a realizar. Así por ejemplo sería posible incluso<br />
configurar un handover blando.<br />
Sin embargo el modo de funcionami<strong>en</strong>to del paquete Dynamic<br />
también pres<strong>en</strong>ta algunas desv<strong>en</strong>tajas. El objetivo es implem<strong>en</strong>tar un<br />
sistema lo más real posible donde se produce un handover abrupto <strong>basado</strong><br />
<strong>en</strong> IEEE 802.11f. El handover lo realizamos desactivando el interfaz<br />
inalámbrico del HA. Esto hace que el MN deje de recibir del HA y realice el<br />
handover registrándose vía FA.<br />
205
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
El princ<strong>ip</strong>al problema es que, según el estándar Mobile IP, exist<strong>en</strong><br />
dos soluciones a la hora de realizar la detección del movimi<strong>en</strong>to, [RFC<br />
3344] punto 2.4.2. La primera solución es la utilizada por Dynamics, y se<br />
basa <strong>en</strong> que los m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ ti<strong>en</strong><strong>en</strong> un tiempo de vida.<br />
Así, si el tiempo de vida del último m<strong>en</strong>saje recibido v<strong>en</strong>ce, se puede<br />
suponer que ya no estamos <strong>en</strong> la red, y se debe int<strong>en</strong>tar el registro <strong>en</strong> una<br />
nueva subred. La conclusión de esta solución es que el nodo móvil no va a<br />
iniciar el proceso de registro hasta que no v<strong>en</strong>za la validez del último<br />
recibido vía HA, empeorando las prestaciones del handover.<br />
En las simulaciones anteriores se ha implem<strong>en</strong>tado la segunda<br />
solución ofrecida por Mobile IP, basada <strong>en</strong> la detección del cambio de red<br />
utilizando las direcciones de red de los m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’<br />
recibidos. En esta situación, <strong>en</strong> una red ‘Break Before Make’, al recibir de<br />
un nuevo FA, el proceso de registro se ejecutaba inmediatam<strong>en</strong>te, pues si<br />
se recibe vía un nuevo FA ya no ti<strong>en</strong>e ninguna validez el m<strong>en</strong>saje de<br />
anuncio del FA previo.<br />
La conclusión es que el comportami<strong>en</strong>to del sistema real<br />
implem<strong>en</strong>tado será peor que los resultados obt<strong>en</strong>idos por simulación. En<br />
la figura 5.39 se muestra un diagrama de tiempos <strong>en</strong> el que se reproduc<strong>en</strong><br />
los ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ <strong>en</strong>viados por HA y FA. En función del instante <strong>en</strong><br />
el que se realice el handover abrupto éste puede llegar a durar más de un<br />
segundo (zona 1), que es el tiempo <strong>en</strong>tre anuncios, y el mínimo que se le<br />
puede dar como tiempo de validez del m<strong>en</strong>saje.<br />
Se han realizado distintas pruebas para evaluar las prestaciones.<br />
En concreto se ha realizado transmisiones CBR basadas <strong>en</strong> UDP,<br />
transmisión con TCP, y <strong>en</strong>vío de distintos t<strong>ip</strong>os de vídeo utilizando RTP<br />
[RFC1889].<br />
El modo de trabajo ha sido similar <strong>en</strong> todos los estudios: se ha<br />
capturado los datos <strong>en</strong> los distintos nodos utilizando la aplicación<br />
‘tcpdump’ [TCP], y posteriorm<strong>en</strong>te se han procesado utilizando pequeños<br />
programas realizados <strong>en</strong> leguaje Perl.<br />
206
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
HA<br />
HA<br />
1 seg.<br />
FA FA FA<br />
1 seg.<br />
1 2<br />
Inicio del Registro con el<br />
FA<br />
Instante de handover<br />
Figura 5.39 Handover abrupto.<br />
5.6.1 Transmisión CBR con protocolo de transporte UDP<br />
Para la transmisión de datos con UDP hemos utilizado una<br />
aplicación de libre distribución d<strong>en</strong>ominada MGEN [MGE], diseñada por el<br />
NRL (Naval Research Laboratory).<br />
Se ha evaluado el número de paquetes perdidos <strong>en</strong> función de la<br />
tasas de transmisión CBR. En concreto se ha transmitido a 80, 400, 800,<br />
1200, 1600 y 2000 kbps., utilizando siempre un tamaño de paquete de<br />
500 Bytes.<br />
La figura 5.40 muestra los resultados obt<strong>en</strong>idos. Cada punto se ha<br />
realizado a partir de 20 realizaciones indep<strong>en</strong>di<strong>en</strong>tes. Puede observarse<br />
como el número de paquetes perdidos es muy superior al obt<strong>en</strong>ido <strong>en</strong> la<br />
simulación del handover cercano (figura 5.2). La razón, ya com<strong>en</strong>tada, es<br />
que el tiempo de handover es ahora mucho mayor, situándose <strong>en</strong> valores<br />
ligeram<strong>en</strong>te superiores a 1 segundo.<br />
207
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.40 paquetes perdidos durante el handover.<br />
5.6.2 Transmisión con protocolo TCP<br />
En la g<strong>en</strong>eración de tráfico TCP se empleó el programa de la<br />
universidad técnica de Munich, nttcp (New Test TCP), <strong>en</strong> su versión 1.47<br />
[NTT]. La figura 5.41 nos muestra los segm<strong>en</strong>tos TCP transmitidos y<br />
recibidos durante un proceso de handover, así como el instante <strong>en</strong> el que<br />
el FA <strong>en</strong>vía m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’, y el instante <strong>en</strong> el que el<br />
m<strong>en</strong>saje ‘Registration Reply’ llega al nodo móvil.<br />
Podemos observar como el último segm<strong>en</strong>to transmitido por HA se<br />
retransmite varias veces, a pesar de que fue recibido correctam<strong>en</strong>te por el<br />
MN. El motivo es que el reconocimi<strong>en</strong>to ACK del segm<strong>en</strong>to no pudo<br />
alcanzar al HA, por estar produciéndose el handover abrupto. El HA, por<br />
tanto, lo retransmite el cada vez que v<strong>en</strong>ce el periodo de ‘time-out’. Puede<br />
observarse como este temporizador dobla su duración cada vez.<br />
208
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.41. Handover abrupto durante una transmisión TCP.<br />
El primer ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ transmitido por el FA es descartado<br />
por el MN, debido a que aun no ha v<strong>en</strong>cido la duración del que recibió del<br />
HA. Tras recibir un segundo m<strong>en</strong>saje de anuncio el MN se registra con el<br />
Foreign Ag<strong>en</strong>t, restaurándose completam<strong>en</strong>te la comunicación.<br />
Por último la reanudación de la transmisión, vía FA, se produce por<br />
el mecanismo de ‘Slow Start’. Así la v<strong>en</strong>tana de transmisión empieza<br />
si<strong>en</strong>do pequeña aum<strong>en</strong>tándose al ir recibi<strong>en</strong>do los reconocimi<strong>en</strong>tos<br />
positivos. La figura 5.42 nos muestra una ampliación de la figura anterior,<br />
donde se puede apreciar mejor este hecho.<br />
209
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Figura 5.42. Ampliación del ‘inicio l<strong>en</strong>to’ tras el Handover.<br />
5.6.3 Transmisión de tráfico multimedia con RTP<br />
Hemos realizado diversos estudios para evaluar el comportami<strong>en</strong>to<br />
del handover abrupto bajo tráfico multimedia. Para ello se ha utilizado una<br />
aplicación (JMStudio) basada <strong>en</strong> las librerías JMF 2.0 (Java Media<br />
Framework) de la empresa SUN [JMF]. Esta aplicación se ha utilizado<br />
tanto para la transmisión como para la visualización <strong>en</strong> recepción.<br />
La transmisión se realiza utilizando dos flujos indep<strong>en</strong>di<strong>en</strong>tes de<br />
datos (audio y vídeo) transportados por RTP [RFC 1889]. Con el fin de<br />
evaluar las difer<strong>en</strong>cias se han evaluado dos t<strong>ip</strong>os de tráfico multimedia:<br />
• Transmisión multimedia con calidad media. La transmisión de<br />
vídeo se realiza con codificación MJPEG (Motion JPEG), mi<strong>en</strong>tras<br />
que el audio se transmite <strong>en</strong> PCM a 64 Kbps con codificación µ-law.<br />
• Transmisión de videoconfer<strong>en</strong>cia. En este caso el vídeo es<br />
transmitido según el estándar H.263, mi<strong>en</strong>tras que el audio es<br />
transmitido a 6.4 Kbps codificado <strong>en</strong> G.723.<br />
210
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
5.6.3.1 Transmisión multimedia con calidad media<br />
En este caso el vídeo original ti<strong>en</strong>e un formato ‘.mov’, de manera<br />
que el transmisor lo recodifica para su transmisión, obt<strong>en</strong>i<strong>en</strong>do dos flujos<br />
que transmitirá utilizando RTP.<br />
El flujo de vídeo es codificado <strong>en</strong> MJPEG con tamaño de imag<strong>en</strong><br />
360x198. Así cada trama es transmitida <strong>en</strong> un conjunto de paquetes RTP<br />
de longitud 980 bytes, m<strong>en</strong>os el último de cada imag<strong>en</strong>, que ti<strong>en</strong>e longitud<br />
variable. El resultado es una tasa variable <strong>en</strong> torno a los 1.1 Mbps.<br />
El flujo de audio es codificado <strong>en</strong> PCM a 64 Kbps. La transmisión<br />
se realiza a tasa constante con paquetes de 480 bytes.<br />
La figura 5.43 muestra el ‘throughput’ del flujo de vídeo durante el<br />
handover. Se aprecia las variaciones debidas a la propia codificación de la<br />
señal, y la caída brusca durante el handover. Hay que t<strong>en</strong>er pres<strong>en</strong>te el<br />
tamaño de la v<strong>en</strong>tana utilizada para realizar la gráfica, motivo por el que la<br />
caída no es inmediata.<br />
5.43 Tasa de vídeo durante el handover.<br />
211
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
En la gráfica sigui<strong>en</strong>te se muestra el número de paquetes de vídeo<br />
perdidos durante el handover. El eje horizontal muestra distintas pruebas<br />
realizadas. La dispersión observada es debida a dos motivos: El tiempo de<br />
duración del handover que varía <strong>en</strong>tre 0 y 2 segundos; y el t<strong>ip</strong>o ratio de<br />
compresión de la imag<strong>en</strong>. Así imág<strong>en</strong>es s<strong>en</strong>cillas como títulos o con<br />
grandes superficies de color constante ti<strong>en</strong><strong>en</strong> un m<strong>en</strong>or tamaño, lo que se<br />
traduce <strong>en</strong> un m<strong>en</strong>or número de paquetes por imag<strong>en</strong>. Esto es<br />
especialm<strong>en</strong>te apreciable <strong>en</strong> la medida 4 <strong>en</strong> la que han coincidido un<br />
handover de corta duración (0.5 seg.) junto con el hecho de que el<br />
handover se produjo mi<strong>en</strong>tras se transmitían imág<strong>en</strong>es con grandes<br />
títulos.<br />
Figura 5.44 Paquetes perdidos de vídeo durante el handover.<br />
Por otro lado el número de paquetes de audio perdidos dep<strong>en</strong>de<br />
sólo de la duración del handover, ya que se transmit<strong>en</strong> de manera<br />
constante. El valor de paquetes perdidos medio es de 21, que se<br />
corresponde con un handover de 1.2 segundos.<br />
212
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
5.6.3.2 Transmisión de videoconfer<strong>en</strong>cia de baja calidad<br />
Se han repetido el análisis anterior realizando una transmisión de<br />
una videoconfer<strong>en</strong>cia previam<strong>en</strong>te almac<strong>en</strong>ada, y utilizando la misma<br />
aplicación de transmisión (JMStudio). La codificación del vídeo se ha<br />
realizado utilizando H.263, con un tamaño de pantalla de 160x120 puntos,<br />
y resultando una tasa media de 90 kbps. El audio va codificado <strong>en</strong><br />
formato G.723 con tasa constante de 6.4 Kbps.<br />
La figura 5.45 muestra el ‘throughput’ del flujo de vídeo durante el<br />
handover. Puede observarse que antes y después del handover la tasa es<br />
relativam<strong>en</strong>te constante. H.263 ti<strong>en</strong>e codificación temporal, y, debido al<br />
t<strong>ip</strong>o de vídeo <strong>en</strong>viado (el busto de una persona hablando) con poco<br />
movimi<strong>en</strong>to, la información transmitida es siempre similar. La codificación<br />
temporal puede apreciarse, ligeram<strong>en</strong>te, <strong>en</strong> la variación de la tasa del vídeo<br />
antes y después del handover.<br />
Figura 5.45 Tasa del vídeo de una videoconfer<strong>en</strong>cia.<br />
213
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
La figura 5.46 nos muestra el número de paquetes de vídeo<br />
perdidos durante el handover. El eje horizontal muestra las distintas<br />
muestras realizadas. Puede apreciarse como la dispersión ahora es m<strong>en</strong>or<br />
que <strong>en</strong> las pruebas de vídeo con calidad media. El motivo es que ahora la<br />
mayoría de las imág<strong>en</strong>es de vídeo se transmit<strong>en</strong> <strong>en</strong> un único paquete RTP.<br />
Por tanto las pérdidas dep<strong>en</strong>derán princ<strong>ip</strong>alm<strong>en</strong>te de la duración del<br />
handover. El ratio medio de paquetes por imag<strong>en</strong> de la transmisión es<br />
cercano a 1.2.<br />
Figura 5.46 Paquetes de vídeo perdidos durante el handover <strong>en</strong> videoconfer<strong>en</strong>cia.<br />
Con respecto al flujo de audio, el número medio de paquetes<br />
perdidos es de 21. Como <strong>en</strong> el caso anterior, la variación de las medidas se<br />
debe exclusivam<strong>en</strong>te al tiempo de handover, ya que la trasmisión se realiza<br />
a una tasa constante.<br />
214
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
5.6.4 Prueba subjetiva sobre el efecto del handover<br />
Las transmisiones multimedia, evaluadas <strong>en</strong> el punto anterior, se<br />
<strong>en</strong>cu<strong>en</strong>tran dirigidas, <strong>en</strong> g<strong>en</strong>eral, a un observador humano. Es interesante<br />
estudiar como la realización de un handover afecta a la calidad subjetiva<br />
que recibe el receptor.<br />
Para medir esta calidad subjetiva se ha realizado una prueba a<br />
distintas personas. La prueba subjetiva consiste <strong>en</strong> el visionado de un<br />
breve trozo de película o de videoconfer<strong>en</strong>cia durante el cual se produce un<br />
handover para que el espectador califique después su efecto. El test que<br />
los espectadores han t<strong>en</strong>ido que rell<strong>en</strong>ar una vez visionado cada vídeo se<br />
muestra <strong>en</strong> la figura sigui<strong>en</strong>te.<br />
1. ¿Es capaz de apreciar algún efecto cuando visiona el<br />
vídeo<br />
Opciones: Si, No<br />
2. ¿Cómo evaluaría el efecto percibido, <strong>en</strong> caso de haberlo<br />
percibido<br />
Opciones: Despreciable, Apreciable, Molesto, Muy molesto<br />
3. ¿Ti<strong>en</strong>e la s<strong>en</strong>sación de que se ha perdido alguna parte<br />
importante de la película Opciones: Sí, No, No estoy<br />
seguro/a<br />
4. Describa muy brevem<strong>en</strong>te (una o dos frases) qué es lo que<br />
ha percibido<br />
Figura 5.47 Test para la evaluación subjetiva.<br />
215
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Las gráficas que se muestran a continuación son el resultado de<br />
realizar la prueba subjetiva a 15 personas. A todas ellas se les ha pasado<br />
tanto el vídeo de calidad media como la videoconfer<strong>en</strong>cia. El ord<strong>en</strong> de<br />
visionado ha sido elegido aleatoriam<strong>en</strong>te para cada uno de los<br />
observadores.<br />
16<br />
Observadores<br />
14<br />
12<br />
10<br />
8<br />
6<br />
4<br />
Sí<br />
No<br />
2<br />
0<br />
Video MJPEG<br />
Videoconfer<strong>en</strong>cia<br />
Figura 5.48. Pregunta 1. ¿Es capaz de apreciar algún efecto cuando visiona el<br />
vídeo<br />
1 0<br />
3<br />
1<br />
2<br />
Despreciable<br />
Apreciable<br />
Molesto<br />
Muy molesto<br />
6<br />
6<br />
11<br />
Vídeo MJPEG<br />
Videoconfer<strong>en</strong>cia<br />
Figura 5.49. Pregunta 2. ¿Cómo evaluaría el efecto percibido<br />
216
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Observadores<br />
14<br />
12<br />
10<br />
8<br />
6<br />
4<br />
2<br />
Sí<br />
No<br />
No estoy seguro<br />
0<br />
Vídeo MJPEG<br />
Videoconfer<strong>en</strong>cia<br />
Figura 5.50. Pregunta 3 ¿Ti<strong>en</strong>e la s<strong>en</strong>sación de que se ha perdido alguna parte<br />
importante de la película<br />
Vídeo MJPEG<br />
Videoconfer<strong>en</strong>cia<br />
Se aprecia un corte <strong>en</strong> la<br />
película.<br />
Se aprecia un corte de x<br />
seg.<br />
12 Se aprecia un corte <strong>en</strong> la<br />
película<br />
6 Se aprecia un corte de x<br />
seg.<br />
No aprecio nada 3 El corte del audio es más<br />
perceptible que el de vídeo<br />
Falta de sincronización<br />
<strong>en</strong>tre voz e imag<strong>en</strong><br />
14<br />
6<br />
3<br />
2<br />
Figura 5.51. Pregunta 4. Describe muy brevem<strong>en</strong>te qué es lo que ha percibido.<br />
Como se aprecia de las figuras anteriores la gran mayoría de los<br />
sujetos percib<strong>en</strong> el handover. El hecho de que el vídeo de calidad media<br />
MJPEG fuera de una película de ‘dibujos animados’ y <strong>en</strong> idioma inglés ha<br />
favorecido que un pequeño porc<strong>en</strong>taje de personas no llegara a detectar el<br />
handover de este vídeo.<br />
El efecto percibido es mucho m<strong>en</strong>os aceptado <strong>en</strong> la<br />
videoconfer<strong>en</strong>cia. Esto se debe princ<strong>ip</strong>alm<strong>en</strong>te a dos motivos. El primero es<br />
217
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
que la codificación del video <strong>en</strong> la videoconfer<strong>en</strong>cia se realiza con H.263,<br />
que emplea redundancia temporal para reducir la tasa. Esto se realiza<br />
codificando los movimi<strong>en</strong>tos <strong>en</strong>tre macrobloques de unas tramas a otras.<br />
Por tanto, tras finalizar el handover, el receptor necesita una trama<br />
refer<strong>en</strong>cia para poder mostrar la imag<strong>en</strong> de nuevo. El efecto es que se<br />
alarga la duración efectiva del handover, y el corte percibido es mayor. La<br />
segunda razón es que la interrupción del audio es más perceptible que la<br />
interrupción del vídeo. En la videoconfer<strong>en</strong>cia toda la at<strong>en</strong>ción se c<strong>en</strong>tra <strong>en</strong><br />
el audio, ya que el vídeo es siempre similar, y la interrupción del audio se<br />
hace más molesta.<br />
Podemos concluir dici<strong>en</strong>do que la detección del handover ha sido<br />
casi unánime, aunque ha sido catalogada como ‘aceptable’. Esta<br />
aceptación puede deberse a que ha sido un único handover, y que se<br />
puede haber aceptado por ser un hecho aislado. Es de esperar que <strong>en</strong> una<br />
situación real <strong>en</strong> la que se produc<strong>en</strong> múlt<strong>ip</strong>les handovers, y que además<br />
están añadidos a la pérdida de calidad de la recepción de la señal debido al<br />
propio movimi<strong>en</strong>to, empeorará la evaluación subjetiva de los sujetos.<br />
5.6.5 Conclusiones de la implem<strong>en</strong>tación del banco de pruebas<br />
La implem<strong>en</strong>tación del banco de pruebas ha mostrado como el<br />
protocolo de Mobile IP funciona correctam<strong>en</strong>te con redes inalámbricas<br />
IEEE 802.11b. Es decir la misión del <strong>en</strong>caminami<strong>en</strong>to hacia nodos<br />
móviles, así como la compatibilidad con el protocolo IP clásico, se han<br />
resuelto a la perfección por este protocolo.<br />
Debido al mecanismo de handover implem<strong>en</strong>tado por el paquete<br />
Dynamics, la duración de un handover es superior a las medidas<br />
realizadas por simulación. Este hecho no es debido a una incorrecta<br />
implem<strong>en</strong>tación del estándar de Mobile IP, ya que ambas opciones están<br />
recogidas <strong>en</strong> [RFC 3344].<br />
218
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
Como se ha apreciado <strong>en</strong> las distintas pruebas realizadas, el tiempo<br />
medio necesario para la realización del handover se ha situado <strong>en</strong> 1.2<br />
segundos. Ese tiempo hace que se pierdan gran número de paquetes<br />
trabajando <strong>en</strong> UDP, y que el protocolo TCP necesite retransmitir <strong>en</strong> varias<br />
ocasiones algunos paquetes <strong>en</strong> concreto.<br />
Un aspecto importante observado ha sido la gran variación de la<br />
duración del tiempo de handover. Esto desaconseja el protocolo para<br />
cualquier aplicación que necesariam<strong>en</strong>te t<strong>en</strong>ga que garantizar la <strong>en</strong>trega<br />
de información bajo unas condiciones temporales estrictas. En<br />
aplicaciones de tiempo real que no sean críticas, fundam<strong>en</strong>talm<strong>en</strong>te audio<br />
y vídeo, Mobile IP ofrece prestaciones aceptables siempre que los requisitos<br />
de pérdidas no son muy exig<strong>en</strong>tes.<br />
219
Prestaciones del Handover <strong>en</strong> redes IP móviles<br />
220
6. ESPECIFICACIÓN DE MECANISMOS DE<br />
HANDOVER INTRA-DOMINIO PARA UN<br />
SISTEMA DE MICRO-MOVILIDAD BASADO EN<br />
MULTICAST<br />
6.1 INTRODUCCIÓN<br />
En el capítulo 4 de esta Tesis se realizó un estudio de los<br />
mecanismos de handover <strong>en</strong> redes IP móviles. Allí se detalló las pobres<br />
prestaciones que ofrece el protocolo Mobile IP, y se pres<strong>en</strong>taron un<br />
conjunto de soluciones que int<strong>en</strong>tan solv<strong>en</strong>tar estas limitaciones. En<br />
concreto, se estudiaron soluciones para lograr disminuir el retardo <strong>en</strong> la<br />
<strong>en</strong>trega de paquetes <strong>en</strong> el handover (handover rápido), y limitar la pérdida<br />
durante el mismo (handover suave). Además, se estudió como los sistemas<br />
de micro-<strong>movilidad</strong>, que habían sido descritos <strong>en</strong> el capítulo 2, mejoraban<br />
las prestaciones del mecanismo de handover de manera considerable. Los<br />
resultados de un conjunto de simulaciones que analizan las prestaciones<br />
durante el handover tanto del protocolo Mobile IP como de distintos<br />
sistemas de micro-<strong>movilidad</strong> fueron pres<strong>en</strong>tados <strong>en</strong> el capítulo 5.<br />
Una de las aportaciones de esta Tesis es la pres<strong>en</strong>tación de un<br />
sistema de <strong>movilidad</strong> escalable, <strong>basado</strong> <strong>en</strong> una arquitectura de micro<strong>movilidad</strong>,<br />
que explota las capacidades de la transmisión <strong>multicast</strong><br />
(capítulo 3). La unión de las características de los sistemas de micro<strong>movilidad</strong>,<br />
junto con las de la tecnología <strong>multicast</strong>, va a traducirse, <strong>en</strong>tre<br />
otros aspectos, <strong>en</strong> mecanismos de handover intra-dominio s<strong>en</strong>cillos y de<br />
altas prestaciones. A continuación se muestran los b<strong>en</strong>eficios que aporta el<br />
empleo de estás tecnologías con el fin de lograr tanto handovers rápidos<br />
como suaves.<br />
221
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
En el punto 4.2 se realizó un estudio de los tiempos implicados <strong>en</strong><br />
un proceso de handover. Así se definió el ‘Retardo <strong>en</strong> la Recuperación de<br />
una Dirección Temporal’ (T co-retrieval ), como el tiempo necesario para que el<br />
nodo móvil obtuviera una dirección temporal (Care-of Address) acorde con<br />
la red que visita. El sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
propuesto elimina completam<strong>en</strong>te este retardo, pues no es necesario<br />
cambiar de dirección mi<strong>en</strong>tras se permanece <strong>en</strong> el interior del dominio.<br />
En el protocolo Mobile IP el mayor compon<strong>en</strong>te de la lat<strong>en</strong>cia es el<br />
‘Tiempo de Restablecimi<strong>en</strong>to de Ruta’, puesto que es directam<strong>en</strong>te<br />
proporcional a la distancia <strong>en</strong>tre la situación actual del nodo móvil y su<br />
Home Ag<strong>en</strong>t. Para solucionar este problema aparece el concepto de dividir<br />
la red <strong>en</strong> dominios, y la idea de los sistemas de micro-<strong>movilidad</strong>. En el<br />
sistema propuesto este retardo se limita al tiempo necesario para que la<br />
nueva estación se conecte al árbol <strong>multicast</strong>.<br />
El sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong> también ofrece<br />
una base perfecta para lograr un handover suave, donde se minimiza la<br />
pérdida de paquetes. Una de las soluciones que g<strong>en</strong>eralm<strong>en</strong>te se emplea<br />
para este fin es la de utilizar una transmisión simultánea a las dos<br />
estaciones base implicadas <strong>en</strong> el handover. Esta solución ha sido<br />
empleada, por ejemplo, <strong>en</strong> el sistema de micro-<strong>movilidad</strong> ‘Cellular IP’<br />
(Handover Semi-suave) o <strong>en</strong> el sistema ‘HAWAII MNF’ (punto 4.4.3). El<br />
sistema de micro-<strong>movilidad</strong> pres<strong>en</strong>tado se basa <strong>en</strong> la conexión de las<br />
estaciones base a un árbol <strong>multicast</strong> asociado al nodo móvil, lo que lleva<br />
implícito una transmisión de paquetes hacia las dos estaciones de manera<br />
simultánea.<br />
Sin embargo, las facilidades que el sistema pres<strong>en</strong>tado ofrece para<br />
lograr un mecanismo de handover suave, por medio de la transmisión<br />
simultánea, no descartan la posibilidad de incorporar otro t<strong>ip</strong>o de<br />
soluciones, como puede ser el redireccionami<strong>en</strong>to de los paquetes<br />
p<strong>en</strong>di<strong>en</strong>tes descrito <strong>en</strong> el punto 4.4.1.<br />
En el pres<strong>en</strong>te capítulo se van a proponer y analizar distintos<br />
mecanismos de handover, que hemos diseñado para el sistema de micro-<br />
222
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong> que se detalló <strong>en</strong> el capítulo 3. Así <strong>en</strong> el<br />
punto 6.2 se realiza una breve descr<strong>ip</strong>ción de los cinco esquemas de<br />
handover propuestos. Un estudio profundo se realiza <strong>en</strong> los puntos 6.3 a<br />
6.7, donde se indica el modo de funcionami<strong>en</strong>to y el formato de los<br />
paquetes intercambiados que proponemos. En el capítulo sigui<strong>en</strong>te se<br />
realizará un estudio analítico de las prestaciones de estos esquemas.<br />
6.2 PROPUESTA DE ESQUEMAS DE HANDOVER<br />
A continuación se van a describir cinco mecanismos de handover<br />
que hemos diseñado para el sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong><br />
<strong>multicast</strong>. Todos ellos compart<strong>en</strong> las virtudes de baja lat<strong>en</strong>cia y bu<strong>en</strong>a<br />
predisposición a lograr handovers suaves que se han com<strong>en</strong>tado <strong>en</strong> el<br />
punto anterior.<br />
son:<br />
Los cinco esquemas que se van a estudiar <strong>en</strong> el pres<strong>en</strong>te capítulo<br />
• Handover Abrupto. Es la primera solución, muy s<strong>en</strong>cilla, donde no<br />
se int<strong>en</strong>ta garantizar la <strong>en</strong>trega de los paquetes. Se basa <strong>en</strong> confiar<br />
<strong>en</strong> la bu<strong>en</strong>a predisposición del sistema de micro-<strong>movilidad</strong><br />
<strong>multicast</strong> para realizar un handover con baja lat<strong>en</strong>cia con bajas<br />
pérdidas.<br />
• Handover Semi Suave. P<strong>en</strong>sados para sistemas <strong>en</strong> los que el nodo<br />
móvil ti<strong>en</strong>e capacidad para comunicarse con las dos estaciones<br />
base de manera simultánea. Mi<strong>en</strong>tras se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona de<br />
solape de las coberturas de las dos estaciones base, el nodo móvil<br />
se comunica con nBS, indicándole que se conecte al árbol<br />
<strong>multicast</strong>. En función del tiempo que el MN permanezca <strong>en</strong> la zona<br />
de solape, y del tiempo de creación de la nueva rama del árbol<br />
<strong>multicast</strong>, se lograrán prestaciones altas, con un tiempo de lat<strong>en</strong>cia<br />
nulo y muy bajo número de paquetes perdidos.<br />
223
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
• Handover Suave con Finalización Controlada. Para lograr un<br />
handover totalm<strong>en</strong>te suave, sin perdida de paquetes, se propone<br />
una ligera variación del esquema anterior. Se basa <strong>en</strong> una técnica<br />
novedosa que combina la transmisión <strong>multicast</strong> a las dos<br />
estaciones base, junto con m<strong>en</strong>sajes, transmitidos por el MN, que<br />
controlan completam<strong>en</strong>te el proceso de handover.<br />
• Handover con Redireccionami<strong>en</strong>to. Con el fin de lograr un<br />
handover suave se pres<strong>en</strong>ta un handover con redireccionami<strong>en</strong>to.<br />
En este caso se establece una comunicación <strong>en</strong>tre las dos<br />
estaciones base implicadas <strong>en</strong> el handover, de manera que la<br />
estación antigua puede re<strong>en</strong>caminar los paquetes recibidos que<br />
aún no han sido <strong>en</strong>viados al nodo móvil.<br />
Este t<strong>ip</strong>o de handover está p<strong>en</strong>sado para sistemas donde, <strong>en</strong> un<br />
instante de tiempo, el nodo móvil puede comunicarse únicam<strong>en</strong>te<br />
con una estación base. Esto no impide utilizar este esquema <strong>en</strong><br />
sistemas con capacidad de recepción simultánea de dos BS,<br />
aunque, para estos sistemas es más s<strong>en</strong>cillo lograr un handover<br />
suave por medio de los esquemas anteriores <strong>basado</strong>s <strong>en</strong> la<br />
transmisión simultánea de paquetes por ambas estaciones base.<br />
• Handover Indirecto con Pre-registro. Por último, para lograr un<br />
handover rápido <strong>en</strong> sistemas donde el nodo sólo se comunica con<br />
una BS, se define un handover con pre-registro <strong>basado</strong> <strong>en</strong> la<br />
utilización de ‘triggers’. La idea es <strong>en</strong>viar un m<strong>en</strong>saje a la nBS<br />
(utilizando para ello a la oBS) para que comi<strong>en</strong>ce su incorporación<br />
al árbol <strong>multicast</strong> mi<strong>en</strong>tras se está realizando el handover de nivel<br />
2. La int<strong>en</strong>ción es disminuir los compon<strong>en</strong>tes de la lat<strong>en</strong>cia del<br />
handover, tanto el tiempo de detección de movimi<strong>en</strong>to, como el<br />
tiempo de redireccionami<strong>en</strong>to, adelantándolo y solapándolo al<br />
primero.<br />
224
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
6.3 ESQUEMA DE HANDOVER ABRUPTO<br />
El mecanismo de Handover Abrupto está p<strong>en</strong>sado para sistemas<br />
donde el MN no puede comunicarse con más de una estación base de<br />
manera simultánea. Se basa <strong>en</strong> el princ<strong>ip</strong>io simple de que algunos<br />
paquetes se perderán <strong>en</strong> el proceso y, <strong>en</strong> vez de tratar de solucionarlo, se<br />
deja esta tarea a los niveles superiores. El número de paquetes perdidos<br />
será proporcional a la lat<strong>en</strong>cia total del handover y a la tasa de<br />
transmisión de los paquetes.<br />
En realidad este procedimi<strong>en</strong>to es la forma de trabajar del protocolo<br />
original Mobile IP [RFC 3344]. Sin embargo, las prestaciones que van a<br />
lograrse al aplicar el mecanismo al sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong><br />
<strong>multicast</strong> van a ser muy superiores que las obt<strong>en</strong>idas con el protocolo<br />
Mobile IP (ver capítulo 5). El motivo es, que aún t<strong>en</strong>i<strong>en</strong>do un handover<br />
abrupto, las características del sistema propuesto (sistema de micro<strong>movilidad</strong><br />
y tecnologías <strong>multicast</strong>) reduc<strong>en</strong> considerablem<strong>en</strong>te la lat<strong>en</strong>cia<br />
del handover.<br />
Como se detalló <strong>en</strong> el punto 3.3.1, el nodo móvil escucha los<br />
m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ (ver 3.3.1), que <strong>en</strong>vían las estaciones base<br />
de manera periódica, con objeto de descubrir si se ha producido un cambio<br />
de estación base. Otra posibilidad sería que el nodo móvil <strong>en</strong>viara un<br />
m<strong>en</strong>saje ‘Ag<strong>en</strong>t Solicitation’ para forzar a la estación base a que transmita<br />
el m<strong>en</strong>saje de anuncio. Este segundo caso sería interesante,<br />
especialm<strong>en</strong>te, si existe una cooperación <strong>en</strong>tre los niveles dos y tres del<br />
nodo móvil. Típicam<strong>en</strong>te se realizaría utilizando un trigger Link UP<br />
[YEG02], de manera que nada más finalizar el handover de nivel dos se<br />
lanzara el mecanismo de nivel tres. En [BLO03] se realiza un estudio de<br />
prestaciones del protocolo Mobile IP cuando se utiliza este trigger y una red<br />
IEEE 802.11.<br />
Tras detectar la necesidad de realizar un handover intra-dominio, el<br />
nodo móvil transmite un m<strong>en</strong>saje d<strong>en</strong>ominado ‘Intra-Domanin Registration<br />
Request’ (punto 3.5.3) hacia la nueva Estación Base. Este m<strong>en</strong>saje<br />
conti<strong>en</strong>e la dirección <strong>multicast</strong> utilizada por el móvil, la dirección de la<br />
225
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
estación base anterior, y la dirección del MMA con el que se realizó el<br />
registro. La figura 6.1 muestra un diagrama del proceso donde se puede<br />
observar este m<strong>en</strong>saje.<br />
MN oBS nBS Nodo<br />
Cruce<br />
Datos<br />
Datos <strong>en</strong> Multicast<br />
Beacon<br />
Intra-Domain Registration<br />
Request<br />
Join<br />
Intra-Domain Registration<br />
Reply<br />
ACK Join<br />
Datos <strong>en</strong> Multicast<br />
Datos<br />
Multicast Prune Request<br />
Leave Group<br />
Figura 6.1 Esquema del proceso de Handover Abrupto.<br />
La nueva estación base <strong>en</strong>ti<strong>en</strong>de este m<strong>en</strong>saje de petición de<br />
registro como si recibiera un m<strong>en</strong>saje IGMP. Como respuesta, la estación<br />
se va a conectar al árbol <strong>multicast</strong> utilizando un m<strong>en</strong>saje ‘Join’ que se<br />
transmitirá de manera asc<strong>en</strong>d<strong>en</strong>te. En el caso de emplear el protocolo PIM-<br />
SM, el m<strong>en</strong>saje se transmitiría hacia el MMA, que actuaría como<br />
‘R<strong>en</strong>dezvous Point’ del árbol <strong>multicast</strong>. Debido a las especiales<br />
226
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
características del mecanismo, <strong>en</strong> las que existe únicam<strong>en</strong>te un<br />
transmisor, y que por tanto va a actuar como RP (R<strong>en</strong>dezvous Point), el<br />
protocolo PIM podría simplificarse. En particular las necesidades de<br />
nuestro sistema se adaptan perfectam<strong>en</strong>te a la tecnología ‘Multicast con<br />
Fu<strong>en</strong>te Específica’ (SSM) que actualm<strong>en</strong>te se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> investigación<br />
[BHA03], [HOL03]. Aún así el sistema podría funcionar perfectam<strong>en</strong>te con<br />
cualquier protocolo <strong>multicast</strong>, incluidos los protocolos de modo d<strong>en</strong>so.<br />
De esta manera el m<strong>en</strong>saje ‘Join’ sería el definido <strong>en</strong> el protocolo<br />
[RFC 2362] o <strong>en</strong> [FEN03]. Para mant<strong>en</strong>er la seguridad del sistema, este<br />
m<strong>en</strong>saje ‘Join’ podría ir finalizado por una ext<strong>en</strong>sión de aut<strong>en</strong>tificación FA-<br />
FA diseñada <strong>en</strong> el punto 3.5.2 a partir de [RFC 3012].<br />
El m<strong>en</strong>saje ‘Join’ se transmitirá hasta que se alcance un router que<br />
pert<strong>en</strong>ezca al árbol <strong>multicast</strong>, es decir, hasta el primer router común <strong>en</strong> la<br />
ruta hacia el núcleo. Este router, que d<strong>en</strong>ominaremos Nodo de Cruce,<br />
sería <strong>en</strong> cierta manera similar a los nodos de cruce de los sistema de<br />
micro-<strong>movilidad</strong> HBR.<br />
La Estación Base nBS recibirá una confirmación positiva de la<br />
incorporación al árbol por medio de un m<strong>en</strong>saje ‘ACK Join’. Como se<br />
discutió <strong>en</strong> el punto 3.6 este m<strong>en</strong>saje no está definido <strong>en</strong> el protocolo PIM-<br />
SM, aunque si existe <strong>en</strong> otros protocolos como CBT [RFC 2189]. Esto no es<br />
ningún problema, puesto que la mínima información necesaria para poder<br />
<strong>en</strong>viar este m<strong>en</strong>saje se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> las tablas de <strong>en</strong>rutami<strong>en</strong>to <strong>multicast</strong><br />
PIM. Como <strong>en</strong> el caso anterior el m<strong>en</strong>saje ‘ACK Join’ debería finalizarse con<br />
una ext<strong>en</strong>sión de aut<strong>en</strong>tificación.<br />
Por último, y como se observa <strong>en</strong> la figura 6.1, tras recibir este<br />
m<strong>en</strong>saje ‘ACK Join’, la estación base le comunica al nodo móvil la<br />
incorporación al árbol mediante un m<strong>en</strong>aje ‘Intra-Domain Registration<br />
Reply’ (punto 3.5.3). La recepción de este m<strong>en</strong>saje da por concluido el<br />
proceso de handover abrupto, ya que a partir de ese mom<strong>en</strong>to, el nodo<br />
móvil puede recibir datos por medio de la nueva Estación Base.<br />
227
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
En este instante el nodo móvil está transmiti<strong>en</strong>do y recibi<strong>en</strong>do por<br />
medio de la nueva Estación Base. Sin embargo, la Estación Base anterior<br />
no ha recibido ningún t<strong>ip</strong>o de notificación que le informe sobre este hecho,<br />
y, por tanto, sigue conectada al árbol <strong>multicast</strong> del móvil, y continúa<br />
transmiti<strong>en</strong>do los paquetes por el interfaz inalámbrico. Esta circunstancia<br />
es temporal. La conexión de una estación base al árbol <strong>multicast</strong> vi<strong>en</strong>e<br />
determinado por la recepción cada cierto tiempo de m<strong>en</strong>sajes de re-registro<br />
que serían equival<strong>en</strong>tes a los m<strong>en</strong>sajes de Informe de Filiación<br />
(‘Membersh<strong>ip</strong> Report’) del protocolo IGMP. La aus<strong>en</strong>cia de estos m<strong>en</strong>sajes<br />
indica a oBS que el nodo ya no se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> su zona de cobertura, por<br />
lo que debería iniciar el proceso para abandonar el árbol <strong>multicast</strong>.<br />
La perman<strong>en</strong>cia temporal de la Estación Base antigua <strong>en</strong> el árbol<br />
<strong>multicast</strong>, cuando el nodo ya ha realizado el handover, no ti<strong>en</strong>e graves<br />
consecu<strong>en</strong>cias <strong>en</strong> las prestaciones del sistema cableado, pues se supone<br />
que la red ti<strong>en</strong>e la sufici<strong>en</strong>te ancho de banda. Sin embargo sí puede afectar<br />
negativam<strong>en</strong>te el hecho de transmitir los paquetes por el interfaz<br />
inalámbrico, ya que éste suele t<strong>en</strong>er limitaciones de capacidad.<br />
Para solucionar el problema se propone un nuevo m<strong>en</strong>saje, que<br />
d<strong>en</strong>ominamos ‘Multicast Prune Request’. Este m<strong>en</strong>saje lo <strong>en</strong>vía la nueva<br />
estación base a la antigua, cuando la primera recibe la confirmación de la<br />
conexión al árbol <strong>multicast</strong>, vía ‘ACK Join’. Para que la nueva estación<br />
base t<strong>en</strong>ga conocimi<strong>en</strong>to de la dirección IP a donde <strong>en</strong>viar el paquete, es<br />
necesario añadir esta información al m<strong>en</strong>aje ‘Intra-Domain Registration<br />
Request’ definido <strong>en</strong> el punto 3.5.3. Para ello se define una nueva<br />
ext<strong>en</strong>sión, mostrada <strong>en</strong> la figura 3.2, que se incorporará al m<strong>en</strong>saje de<br />
registro cuando se emplee este t<strong>ip</strong>o de handover.<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o Longitud Dirección de la estación base anterior<br />
Dirección de la estación base anterior<br />
Figura 6.2 Ext<strong>en</strong>sión para ‘Intra-Domain Registration Request’ <strong>en</strong> Handover<br />
Abrupto.<br />
228
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
En la figura 6.3 se muestra el formato del m<strong>en</strong>saje ‘Multicast Prune<br />
Request’ propuesto. El campo ‘T<strong>ip</strong>o’ se utiliza para difer<strong>en</strong>ciar los distintos<br />
m<strong>en</strong>sajes del protocolo de micro-<strong>movilidad</strong> propuesto, y su valor estaría<br />
definido por la IANA. El bit ‘A’ indica que estamos ante un handover<br />
abrupto de manera que se puede reutilizar este m<strong>en</strong>saje <strong>en</strong> posteriores<br />
mecanismos de handover. Así, los bits ‘S’, ‘R’ y ‘P’ se utilizan <strong>en</strong> esquemas<br />
de handover posteriores. Las direcciones <strong>multicast</strong> y del MMA se utilizan<br />
para poder abandonar el árbol <strong>multicast</strong>. Por último, el campo<br />
‘Id<strong>en</strong>tificador’ se emplea como mecanismo de seguridad para asociar<br />
peticiones con respuesta <strong>en</strong> caso necesario, aunque por ahora no lo<br />
utilizaremos. Por motivos de seguridad este m<strong>en</strong>saje debería ir protegido<br />
por una ext<strong>en</strong>sión de aut<strong>en</strong>tificación FA-FA definida <strong>en</strong> [RFC 3344].<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o A S R P<br />
Dirección Multicast<br />
Care-of Address (Dirección del MMA)<br />
Id<strong>en</strong>tificador<br />
Ext<strong>en</strong>siones................<br />
Figura 6.3 Formato m<strong>en</strong>saje ‘Multicast Prune Request’ para el Handover Abrupto.<br />
Tras la recepción del m<strong>en</strong>saje de petición de abandono del árbol<br />
<strong>multicast</strong>, la Estación Base antigua actúa como si recibiera un m<strong>en</strong>saje<br />
‘Leave Group’ del protocolo IGMPv2 [RFC 2236]. El comportami<strong>en</strong>to, a<br />
partir de este mom<strong>en</strong>to, dep<strong>en</strong>derá del protocolo <strong>multicast</strong> con el que se<br />
trabaje. En el caso de PIM-SM, la estación base transmitirá, <strong>en</strong> caso de<br />
que fuera necesario, un m<strong>en</strong>saje de recorte d<strong>en</strong>ominado ‘Prune’ [RFC<br />
2362].<br />
229
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
6.4 ESQUEMA DE HANDOVER SEMI SUAVE<br />
Este esquema está p<strong>en</strong>sado para sistemas <strong>en</strong> los que el nodo móvil<br />
ti<strong>en</strong>e capacidad para comunicarse con las dos estaciones base de manera<br />
simultánea, y sería el equival<strong>en</strong>te a las soluciones sin redireccionami<strong>en</strong>to<br />
de ‘Hawai’ y al handover semi suave de ‘Cellular IP’, (ver punto 4.4.3).<br />
El modo de funcionami<strong>en</strong>to es bastante similar al Handover<br />
Abrupto detallado <strong>en</strong> el punto anterior, explotando ahora la capacidad de<br />
comunicación simultanea. Así, el nodo móvil, tras t<strong>en</strong>er constancia de que<br />
ha <strong>en</strong>trado <strong>en</strong> la zona de cobertura de la nueva estación base, se comunica<br />
con ella, transmitiéndole un m<strong>en</strong>saje ‘Intra-Domain Registration Request’.<br />
Sin embargo, y a difer<strong>en</strong>cia del esquema anterior, el nodo móvil sigue<br />
recibi<strong>en</strong>do paquetes vía la Estación Base antigua.<br />
La nueva estación base se conecta con el árbol <strong>multicast</strong>, por<br />
ejemplo utilizando un m<strong>en</strong>saje ‘Join’ de PIM-SM o SSM. Al igual que <strong>en</strong> el<br />
Handover Abrupto, el m<strong>en</strong>saje se transmitirá hasta que se alcance el Nodo<br />
de Cruce, y será confirmado por medio de un m<strong>en</strong>saje ‘ACK Join’. Cuando<br />
ti<strong>en</strong>e la confirmación de la correcta conexión al árbol <strong>multicast</strong>, la nueva<br />
Estación Base <strong>en</strong>vía al móvil un m<strong>en</strong>saje ‘Intra-Domain Registration Reply’,<br />
indicativo de la finalización del proceso de handover y de la posibilidad de<br />
recibir paquetes a través de esa estación.<br />
Idealm<strong>en</strong>te el nodo móvil permanece <strong>en</strong> la zona de solape mi<strong>en</strong>tras<br />
se produce el proceso de handover, por lo que <strong>en</strong> ningún mom<strong>en</strong>to ha<br />
perdido la posibilidad de <strong>en</strong>viar o recibir paquetes. Una vez se ha realizado<br />
el proceso de handover, el nodo móvil va a utilizar a la nueva estación base<br />
para comunicarse, por lo que ya no es necesario que oBS permanezca<br />
conectada al árbol <strong>multicast</strong>.<br />
El nodo móvil le <strong>en</strong>viará un m<strong>en</strong>saje ‘Multicast Prune Request’ a la<br />
estación antigua indicándole que puede iniciar el mecanismo para<br />
abandonar el grupo <strong>multicast</strong>. Como puede observarse el proceso es<br />
ligeram<strong>en</strong>te difer<strong>en</strong>te al visto anteriorm<strong>en</strong>te, pues ahora es el nodo móvil<br />
quién transmite directam<strong>en</strong>te el m<strong>en</strong>saje a la estación, <strong>en</strong> vez de realizarse<br />
230
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
a través de nBS. Esta solución, posible gracias a la comunicación<br />
simultanea del MN con las dos estaciones, permite un mayor control por<br />
parte del MN. Así se que podría, por ejemplo, retardar ligeram<strong>en</strong>te el <strong>en</strong>vío<br />
del m<strong>en</strong>saje logrando un cierto mecanismo de histéresis.<br />
El m<strong>en</strong>saje ‘Multicast Prune Request’ empleado <strong>en</strong> este esquema es<br />
el mismo que el mostrado <strong>en</strong> la figura 6.2, difer<strong>en</strong>ciándose únicam<strong>en</strong>te <strong>en</strong><br />
la activación de un bit ‘S’ indicativo del Handover Semi Suave y <strong>en</strong> la no<br />
activación de los bits restantes (‘A’, ‘R’ y ‘P’).<br />
MN oBS nBS Nodo<br />
Cruce<br />
Datos <strong>en</strong> Multicast<br />
Datos<br />
Beacon<br />
Intra-Domanin Registration<br />
Request<br />
Join<br />
Intra-Domanin Registration<br />
Reply<br />
ACK Join<br />
Datos <strong>en</strong> Multicast<br />
Datos<br />
Multicast Prune<br />
Request<br />
Leave Group<br />
Figura 6.4. Esquema del proceso de Handover Semi Suave.<br />
231
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
La figura 6.4 muestra el proceso de handover descrito, donde puede<br />
observarse las similitudes con el handover abrupto del punto anterior. Es<br />
destacable la capacidad del nodo móvil de comunicarse simultáneam<strong>en</strong>te<br />
con las dos estaciones base mi<strong>en</strong>tras dura todo el proceso.<br />
6.4.1 Limitaciones del mecanismo de Handover Semi Suave<br />
Idealm<strong>en</strong>te, el nodo móvil no va a perder <strong>en</strong> ningún mom<strong>en</strong>to la<br />
conectividad con la red, pues logra finalizar el handover con una nBS<br />
cuando aún puede comunicarse con oBS. Sin embargo, esto no garantiza<br />
un handover suave, sin pérdida ni duplicidad de paquetes, <strong>en</strong> todas las<br />
situaciones.<br />
Así, podemos suponer que la zona controlada por la Estación Base<br />
antigua soporta un tráfico elevado. En esta situación la estación t<strong>en</strong>drá<br />
almac<strong>en</strong>ados un conjunto de paquetes dirigidos hacia el nodo móvil, a la<br />
espera de poder se transmitidos por el <strong>en</strong>lace radio. Al producirse un<br />
handover la nueva Estación Base se conecta al árbol <strong>multicast</strong>, y comi<strong>en</strong>za<br />
a recibir paquetes que redirige hacia al nodo móvil. Ahora el nodo móvil<br />
puede haber recibido paquetes (vía nBS) mi<strong>en</strong>tras que aún no habría<br />
recibido paquetes anteriores por estar a la espera <strong>en</strong> la cola de oBS.<br />
Incluso podría salir de la zona de cobertura (o desconectarse de oBS) y<br />
esos paquetes no los recibiría. En el mejor de los casos los paquetes<br />
llegarían al nodo móvil de manera desord<strong>en</strong>ada, o incluso duplicados.<br />
En la figura 6.5 se muestra este caso. En (a) el MN está recibi<strong>en</strong>do<br />
datos de oBS, pues aun no se ha iniciado el proceso de handover. La<br />
estación oBS ti<strong>en</strong>e <strong>en</strong> memoria los paquetes 2, 3 y 4 y recibe el 5. En (b)<br />
puede observarse como nBS se ha conectado al árbol <strong>multicast</strong> y empieza<br />
a recibir el paquete 7. En ese mom<strong>en</strong>to <strong>en</strong>vía al MN un m<strong>en</strong>saje ‘Intra-<br />
Domanin Registration Reply’. En (c) el nodo móvil <strong>en</strong>vía un m<strong>en</strong>saje a oBS<br />
indicándole que se desconecte del árbol <strong>multicast</strong> pues se ha realizado un<br />
handover. A partir de ese instante no recibe paquetes de esta estación. Por<br />
tanto, los paquetes 5 y 6 nunca serán recibidos por el MN, y el paquete 4,<br />
232
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
puede que llegue desord<strong>en</strong>ado (posterior al paquete 7), o que tampoco sea<br />
recibido. En (d) se muestra el sistema una vez el handover ha finalizado.<br />
(a)<br />
Nodo de<br />
Cruce<br />
(b)<br />
Nodo de<br />
Cruce<br />
5<br />
7<br />
7<br />
4<br />
3<br />
2<br />
oBS<br />
nBS<br />
6<br />
5<br />
4<br />
oBS<br />
nBS<br />
1<br />
3<br />
MN<br />
MN<br />
(c)<br />
Nodo de<br />
Cruce<br />
(d)<br />
Nodo de<br />
Cruce<br />
8<br />
8<br />
11<br />
7<br />
6<br />
5<br />
oBS<br />
nBS<br />
oBS<br />
nBS<br />
10<br />
9<br />
MPR<br />
8<br />
4<br />
7<br />
MN<br />
MN<br />
Figura 6.5. Handover Semi Suave con pérdida de paquetes.<br />
Una situación similar podría ocurrir si el retardo <strong>en</strong>tre la Estación<br />
Base antigua y el Nodo de Cruce y es s<strong>en</strong>siblem<strong>en</strong>te superior al exist<strong>en</strong>te<br />
<strong>en</strong>tre este último y la nueva Estación Base. Aquí paquetes <strong>en</strong> tránsito<br />
233
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
hacia oBS podrían se transmitidos más tarde que paquetes posteriores que<br />
son transmitidos vía nBS.<br />
La figura 6.6. muestra esta situación, justo <strong>en</strong> el instante <strong>en</strong> que la<br />
nBS se ha conectado al árbol <strong>multicast</strong> y ha recibido el m<strong>en</strong>saje ‘ACK<br />
Join’. El retardo <strong>en</strong> el <strong>en</strong>lace oBS-NC es mayor que <strong>en</strong> el <strong>en</strong>lace nBS-NC.<br />
Así cuando la nueva estación se conecta al árbol <strong>multicast</strong> recibe paquetes<br />
a partir del 11, mi<strong>en</strong>tras que los anteriores aún no han llegado a la<br />
estación antigua. Como <strong>en</strong> el caso anterior esto se traduce <strong>en</strong> una posible<br />
pérdida de paquetes.<br />
4<br />
6<br />
7<br />
8<br />
9<br />
10<br />
11<br />
Nodo de<br />
Cruce<br />
11<br />
oBS<br />
nBS<br />
3<br />
MN<br />
Figura 6.6 Handover Semi Suave con pérdida de paquetes (b).<br />
Las situaciones com<strong>en</strong>tadas no son habituales y el número de<br />
paquetes perdidos <strong>en</strong> un Handover Semi Suave es muy bajo. Las<br />
soluciones para lograr un handover suave completo, sin pérdida de<br />
paquetes, ti<strong>en</strong><strong>en</strong> el inconv<strong>en</strong>i<strong>en</strong>te que aum<strong>en</strong>tan el tiempo de lat<strong>en</strong>cia del<br />
proceso handover. La princ<strong>ip</strong>al característica del Handover Semi Suave es<br />
lograr, de forma s<strong>en</strong>cilla, un bu<strong>en</strong> comportami<strong>en</strong>to con respecto al número<br />
de paquetes perdidos, con un tiempo de lat<strong>en</strong>cia nulo. Por esto, <strong>en</strong> la<br />
mayoría de las situaciones no convi<strong>en</strong>e buscar soluciones a esta pequeña<br />
perdida de paquetes, ya que se realiza a costa de complicar el esquema y<br />
de introducir un tiempo de interrupción <strong>en</strong> la comunicación.<br />
234
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
6.5 ESQUEMA DE HANDOVER SUAVE CON<br />
FINALIZACIÓN CONTROLADA<br />
Exist<strong>en</strong> situaciones <strong>en</strong> las que se necesita un handover que<br />
garantice la <strong>en</strong>trega de todos los paquetes. Para estos casos es posible<br />
modificar ligeram<strong>en</strong>te el protocolo anterior. Se puede optar <strong>en</strong>tre dos<br />
soluciones difer<strong>en</strong>tes, com<strong>en</strong>tadas a continuación.<br />
La primera solución sería introducir algún mecanismo de<br />
retransmisión de paquetes desde oBS a nBS. Esta solución se aplica,<br />
g<strong>en</strong>eralm<strong>en</strong>te, <strong>en</strong> sistemas <strong>en</strong> los que el nodo móvil no puede comunicarse<br />
con las dos estaciones de manera simultánea, aunque también sería<br />
posible aplicar esta técnica <strong>en</strong> el Handover Semi Suave. Desde mi punto de<br />
vista, la lat<strong>en</strong>cia que introduce no lo hace aconsejable <strong>en</strong> este caso. En el<br />
punto sigui<strong>en</strong>te se estudia el esquema de handover con retransmisión.<br />
Una segunda solución, totalm<strong>en</strong>te novedosa, consiste <strong>en</strong> retrasar<br />
consci<strong>en</strong>tem<strong>en</strong>te la finalización del proceso de handover. Con esto le<br />
damos tiempo a la estación antigua para transmitir los paquetes<br />
p<strong>en</strong>di<strong>en</strong>tes. El handover podría d<strong>en</strong>ominarse ‘Handover Suave con<br />
Finalización Controlada’ y está gestionado completam<strong>en</strong>te por el nodo<br />
móvil.<br />
Como se ve <strong>en</strong> la figura 6.7, el inicio del proceso de handover es<br />
idéntico al estudiado hasta ahora. Cuando la nueva estación base recibe el<br />
m<strong>en</strong>saje ‘ACK Join’, transmite el correspondi<strong>en</strong>te ‘Intra-Domanin<br />
Registration Reply’ al MN. A partir de ahora nBS empieza a recibir los<br />
paquetes dirigidos al nodo móvil, pues la estación está conectada al árbol<br />
<strong>multicast</strong>. Sin embargo, esos paquetes no van a ser transmitidos por el<br />
interfaz radio, si no que se almac<strong>en</strong>an temporalm<strong>en</strong>te <strong>en</strong> la estación.<br />
El nodo móvil, por su parte, puede transmitir a través de nBS, pero<br />
sigue recibi<strong>en</strong>do paquetes desde oBS, retardando el <strong>en</strong>vío del m<strong>en</strong>saje<br />
‘Multicast Prune Request’. De esta manera se permite recibir los paquetes<br />
que ev<strong>en</strong>tualm<strong>en</strong>te ti<strong>en</strong>e almac<strong>en</strong>ada la estación base antigua. Tras un<br />
235
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
cierto tiempo configurable, o bi<strong>en</strong> cuando la señal de la estación base<br />
antigua baja de cierto umbral crítico (por ejemplo utilizando un ‘trigger’), el<br />
nodo móvil finaliza el proceso de handover. Para ello <strong>en</strong>vía el m<strong>en</strong>cionado<br />
m<strong>en</strong>saje de recorte <strong>multicast</strong> a oBS y transmite un nuevo m<strong>en</strong>saje, que<br />
d<strong>en</strong>ominamos ‘Handover Switch Indication’ a nBS.<br />
MN oBS nBS Nodo<br />
Cruce<br />
Datos<br />
Beacon<br />
Intra-Domanin Registration<br />
Request<br />
Datos <strong>en</strong> Multicast<br />
Join<br />
Intra-Domain Registration<br />
Reply<br />
ACK Join<br />
Datos<br />
Datos <strong>en</strong> Multicast<br />
Futura pérdida de<br />
conexión con oBS<br />
Multicast Prune<br />
Request<br />
Leave Group<br />
Handover Switch<br />
Indication<br />
Datos<br />
Almac<strong>en</strong>ados<br />
Datos<br />
Datos <strong>en</strong> Multicast<br />
Figura 6.7 Esquema del proceso de Handover Suave con Finalización Controlada.<br />
236
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
El m<strong>en</strong>saje ‘Handover Switch Indication’ ti<strong>en</strong>e la finalidad de<br />
indicarle a nBS que puede com<strong>en</strong>zar a transmitir paquetes hacia él. Es<br />
importante indicar, de alguna manera, qué paquetes IP ya ha recibido el<br />
MN. En caso contrario es probable que el nodo móvil reciba paquetes por<br />
duplicado, lo cual es casi tan negativo como perderlos (punto 4.4.1). El<br />
formato del m<strong>en</strong>saje que proponemos se explica <strong>en</strong> el punto 6.5.1 (figura<br />
6.9).<br />
Cuando la nueva estación base recibe el m<strong>en</strong>saje ‘Handover Switch<br />
Indication’ se da por concluido el proceso de handover. La estación<br />
utilizará el m<strong>en</strong>saje para localizar el último paquete recibido por el nodo<br />
móvil. Éste y todos los paquetes anteriores son descartados. Los paquetes<br />
posteriores no han sido recibidos por el nodo móvil, y por tanto, deb<strong>en</strong> ser<br />
transmitidos por nBS hacia al nodo móvil. En caso de que la nueva<br />
estación base no disponga del último paquete recibido por el móvil, se<br />
supone que éste era previo a los almac<strong>en</strong>ados por la estación, de manera<br />
que se transmitirán todos los almac<strong>en</strong>ados.<br />
Si el nodo móvil puede permanecer <strong>en</strong> la zona de cobertura el<br />
tiempo sufici<strong>en</strong>te para que oBS vacíe las colas de paquetes dirigidos hacia<br />
él se logra un handover suave con lat<strong>en</strong>cia nula.<br />
El <strong>en</strong>vío del m<strong>en</strong>saje ‘Handover Switch Indication’ podría ser<br />
confirmado por medio de un m<strong>en</strong>saje de reconocimi<strong>en</strong>to <strong>en</strong>viado por nBS.<br />
Sin embargo se ha optado por utilizar los datos recibidos como<br />
confirmación de que el m<strong>en</strong>saje ha llegado correctam<strong>en</strong>te a nBS. En caso<br />
de no recibir paquetes vía nBS, un temporizador forzaría al MN a re<strong>en</strong>vío<br />
del m<strong>en</strong>saje. No obstante, <strong>en</strong> el esquema de handover sigui<strong>en</strong>te se describe<br />
la utilización de un m<strong>en</strong>saje de respuesta que también podría utilizarse<br />
como confirmación <strong>en</strong> este esquema.<br />
En la figura 6.8 puede observarse las fases (c) y (d) de la figura 6.5<br />
com<strong>en</strong>tada anteriorm<strong>en</strong>te. Las dos primeras fases, (a) y (b), no se<br />
muestran al ser idénticas al protocolo anterior. En la fase (c) ambas<br />
estaciones están conectadas al árbol <strong>multicast</strong>, por lo que recib<strong>en</strong> los<br />
237
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
paquetes dirigidos hacia el nodo móvil. Sólo oBS transmite por el interfaz<br />
inalámbrico.<br />
La figura (d) muestra el proceso de finalización del handover. El<br />
nodo móvil <strong>en</strong>vía un m<strong>en</strong>saje ‘Multicast Prune Request’ a oBS y un m<strong>en</strong>saje<br />
‘Handover Switch Indication’ a nBS, indicándole el último paquete recibido,<br />
6. En ese instante la estación nueva empezará a <strong>en</strong>viar los m<strong>en</strong>sajes<br />
almac<strong>en</strong>ados a partir del indicado, mi<strong>en</strong>tras que oBS iniciará el proceso de<br />
abandono del árbol <strong>multicast</strong>.<br />
(c)<br />
Nodo de<br />
Cruce<br />
(d)<br />
Nodo de<br />
Cruce<br />
10<br />
10<br />
Prune<br />
11<br />
9<br />
8<br />
7<br />
oBS<br />
nBS<br />
9<br />
8<br />
7 oBS<br />
nBS<br />
10<br />
9<br />
8<br />
6<br />
MPR<br />
HSI (6)<br />
7<br />
MN<br />
MN<br />
Figura 6.8 Funcionami<strong>en</strong>to sin pérdidas.<br />
6.5.1 Formato del m<strong>en</strong>saje ‘Handover Switch Indication’<br />
El formato del m<strong>en</strong>saje que proponemos puede observarse <strong>en</strong> la<br />
figura 6.9. El campo ‘T<strong>ip</strong>o’ sería el correspondi<strong>en</strong>te a este m<strong>en</strong>saje,<br />
asignado por IANA. Los campos de ‘Dirección Multicast’ y ‘Care-of<br />
Address’ se utilizan para id<strong>en</strong>tificar la pila de paquetes donde ha<br />
almac<strong>en</strong>ado los paquetes dirigidos al nodo móvil. Los sigui<strong>en</strong>tes tres<br />
campos ti<strong>en</strong><strong>en</strong> el objetivo de id<strong>en</strong>tificar unívocam<strong>en</strong>te el último paquete<br />
238
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
que el nodo móvil ha recibido. En concreto son la dirección IP fu<strong>en</strong>te, y los<br />
campos ‘Id<strong>en</strong>tificador’ y ‘Fragm<strong>en</strong>to’ de la cabecera IP.<br />
Los campos ‘Id<strong>en</strong>tificador’ y ‘Fragm<strong>en</strong>to’ se utilizan <strong>en</strong> redes IP para<br />
poder fragm<strong>en</strong>tar los paquetes IP y adaptarlos al MTU (Unidad de<br />
Transfer<strong>en</strong>cia Máxima) de los <strong>en</strong>laces que atraviesa. Así los difer<strong>en</strong>tes<br />
paquetes IP que se <strong>en</strong>vían a un destino ti<strong>en</strong><strong>en</strong> números de Id<strong>en</strong>tificador<br />
sucesivos. En el caso de fragm<strong>en</strong>tar el paquete ese número no cambia,<br />
pero se utiliza el campo ‘Fragm<strong>en</strong>to’ para especificar el ord<strong>en</strong> y poder<br />
reconstruir el paquete original. El resultado es que no existirán dos<br />
paquetes IP de una fu<strong>en</strong>te a un destino con estos dos campos iguales. Para<br />
evitar la probabilidad que difer<strong>en</strong>tes fu<strong>en</strong>tes <strong>en</strong>ví<strong>en</strong> paquetes a un mismo<br />
MN, con igual número de ‘Id<strong>en</strong>tificador’ y de ‘Fragm<strong>en</strong>to’, se <strong>en</strong>vía también<br />
la dirección IP de la fu<strong>en</strong>te. Por motivos de seguridad, el m<strong>en</strong>saje<br />
‘Handover Switch Indication’ irá terminado por una ext<strong>en</strong>sión de seguridad<br />
MN-FA definida <strong>en</strong> [RFC 3344].<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o<br />
Longitud<br />
Dirección Multicast<br />
Care-of Address (Dirección del MMA)<br />
Dirección Fu<strong>en</strong>te del último paquete<br />
Id<strong>en</strong>tificador del último paquete<br />
Fragm<strong>en</strong>to del último paquete<br />
Ext<strong>en</strong>siones................<br />
Figura 6.9 Formato m<strong>en</strong>saje ‘Handover Switch Indication’.<br />
La utilización de los campos de la cabecera IP no es la única<br />
solución, aunque, desde nuestro punto de vista, sí la más s<strong>en</strong>cilla. Otras<br />
opciones serían: utilizar información de protocolos de nivel superior, como<br />
el campo de número de secu<strong>en</strong>cia del protocolo TCP, o incluso emplear el<br />
protocolo RTP; añadir un número de secu<strong>en</strong>cia <strong>en</strong> el campo opciones de la<br />
cabecera IP; añadir el número de secu<strong>en</strong>cia <strong>en</strong> el campo de opciones de la<br />
239
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
cabecera <strong>multicast</strong> y transmitir ésta hasta el nodo móvil; o finalm<strong>en</strong>te<br />
añadir número de secu<strong>en</strong>cia <strong>en</strong> la cabecera <strong>multicast</strong> y hacer que el<br />
m<strong>en</strong>saje ‘Handover Switch Indication’ lo <strong>en</strong>víe oBS a nBS. Todas las<br />
soluciones, pese a ser más clarificadoras por disponer de un campo de<br />
número de secu<strong>en</strong>cia, y por tanto más atractivas, afectan a las<br />
prestaciones del handover, por lo que han sido finalm<strong>en</strong>te descartadas.<br />
6.5.2 Coexist<strong>en</strong>cia de los esquemas de handover<br />
El esquema mostrado <strong>en</strong> este punto puede ofrecer una v<strong>en</strong>taja con<br />
respecto al Handover Semi Suave pres<strong>en</strong>tado anteriorm<strong>en</strong>te. Sin embargo<br />
hay situaciones <strong>en</strong> que esto no es así, y sería preferible no utilizar el<br />
handover con finalización controlada. Un ejemplo de esto sería cuando el<br />
<strong>en</strong>lace nBS-CN es mucho más l<strong>en</strong>to que el <strong>en</strong>lace oBS-CN.<br />
Se ha diseñado un mecanismo que permite que ambos esquemas<br />
coexistan <strong>en</strong> un mismo sistema de micro-<strong>movilidad</strong>. Para ello se modifica<br />
ligeram<strong>en</strong>te el m<strong>en</strong>saje ‘Intra-Domain Registration Request’ (ver figura<br />
3.16). Así, <strong>en</strong> los dos primeros octetos del m<strong>en</strong>saje, exist<strong>en</strong> una serie de<br />
bits, que se han mant<strong>en</strong>ido por compatibilidad con [RFC 3344], y que no<br />
ti<strong>en</strong><strong>en</strong> utilidad <strong>en</strong> caso de un handover intra dominio. Sería posible utilizar<br />
alguno de estos bits, como por ejemplo el bit ‘x’ o el ‘r’, que están siempre a<br />
0, para indicar cual de los dos esquemas de handover se solicita.<br />
Se ha dado al nodo móvil la capacidad de indicar el esquema de<br />
handover que desea realizar, puesto que es él qui<strong>en</strong> ti<strong>en</strong>e información<br />
sobre su velocidad, calidad de la señal recibida de las distintas estaciones<br />
base, etc. Sin embargo, la información más importante para decidir el<br />
mecanismo a emplear es el estado de la red, y esta información está <strong>en</strong><br />
manos de las estaciones base. Por ello se necesita un instrum<strong>en</strong>to para<br />
<strong>en</strong>viar esta información al MN. Se ha optado por incluir la información <strong>en</strong><br />
el m<strong>en</strong>saje ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ de manera que el nodo obti<strong>en</strong>e la<br />
información nada más cambiar de zona.<br />
240
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
El m<strong>en</strong>saje ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ (ver figura 3.11) ha sido<br />
ligeram<strong>en</strong>te modificado, añadiéndole la ext<strong>en</strong>sión que se muestra <strong>en</strong> la<br />
figura 6.10. El campo t<strong>ip</strong>o sería asignado por la IANA, mi<strong>en</strong>tras que la<br />
longitud de la ext<strong>en</strong>sión v<strong>en</strong>dría indicada <strong>en</strong> el campo correspondi<strong>en</strong>te. A<br />
continuación se pres<strong>en</strong>ta una serie de <strong>en</strong>tradas para los posibles oBS<br />
(estaciones base vecinas de donde puede prov<strong>en</strong>ir el nodo móvil). Para<br />
cada una de estas estaciones se adjunta la información necesaria para que<br />
el nodo móvil decida que t<strong>ip</strong>o de handover desea realizar. Esta información<br />
puede ser tan s<strong>en</strong>cilla como indicar si para un handover desde esa oBS es<br />
preferible realizar el ‘Handover Semi Suave’ o el ‘Handvover Suave con<br />
finalización controlada’, o bi<strong>en</strong> incluir información más compleja, como por<br />
ejemplo, información sobre el tiempo que se debería retrasar la finalización<br />
del handover controlado.<br />
Si la información que <strong>en</strong>vía nBS <strong>en</strong> estos m<strong>en</strong>sajes es dinámica,<br />
por ejemplo porque dep<strong>en</strong>de de la carga actual de las estaciones base, será<br />
necesario un mecanismo de intercambio de información <strong>en</strong>tre las<br />
difer<strong>en</strong>tes estaciones base. Este esquema queda fuera de estudio.<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o Longitud Dirección de la Estación Base vecina (1)<br />
Dirección de la Estación Base vecina (1) Datos para selección de Handover BS (1)<br />
........................................<br />
Figura 6.10 Ext<strong>en</strong>sión de Información para Handover.<br />
241
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
6.6 ESQUEMA DE HANDOVER CON<br />
REDIRECCIONAMIENTO<br />
Con el fin de lograr un handover suave proponemos un handover<br />
con redireccionami<strong>en</strong>to. Aquí se establece una comunicación <strong>en</strong>tre las dos<br />
estaciones base implicadas <strong>en</strong> el handover, de manera que la estación<br />
antigua puede re<strong>en</strong>caminar, hacia nBS, los paquetes recibidos que aún no<br />
han sido <strong>en</strong>viados al nodo móvil.<br />
Este t<strong>ip</strong>o de handover está p<strong>en</strong>sado para sistemas donde, <strong>en</strong> un<br />
instante de tiempo, el nodo móvil puede comunicarse únicam<strong>en</strong>te con una<br />
estación base. Esto no impediría utilizar este esquema <strong>en</strong> sistemas con<br />
capacidad de recepción simultánea de dos BS. De todas formas, para estos<br />
sistemas, sería más s<strong>en</strong>cillo implem<strong>en</strong>tar una red con las sufici<strong>en</strong>tes<br />
prestaciones para que no se perdieran paquetes durante el ‘Handover Semi<br />
Suave’, o <strong>en</strong> su defecto, realizar un ‘Handover Suave con Finalización<br />
Controlada’.<br />
Como <strong>en</strong> el caso del handover abrupto el nodo móvil no puede<br />
comunicarse simultáneam<strong>en</strong>te con las dos estaciones base. Así, cuando el<br />
MN recibe m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ desde la nueva estación base<br />
detecta la necesidad de realizar un handover intra-dominio, y transmite el<br />
ya conocido m<strong>en</strong>saje d<strong>en</strong>ominado ‘Intra-Domanin Registration Request’<br />
hacia la nueva Estación Base.<br />
Como se detallará a continuación, el princ<strong>ip</strong>al problema de este<br />
esquema, <strong>basado</strong> <strong>en</strong> el redireccionami<strong>en</strong>to de paquetes, es que ral<strong>en</strong>tiza el<br />
proceso de handover, por lo que no es aconsejable <strong>en</strong> aquellas situaciones<br />
<strong>en</strong> las que se desea un handover lo más rápido posible. Por esto es<br />
interesante permitir al MN que decida se desea realizar un handover suave<br />
(handover con redireccionami<strong>en</strong>to) o uno rápido (handover abrupto). Al<br />
igual que <strong>en</strong> el esquema estudiado <strong>en</strong> el punto anterior, la elección del<br />
mecanismo a emplear podría realizarse incluy<strong>en</strong>do la opción <strong>en</strong> el m<strong>en</strong>saje<br />
de registro intra-dominio.<br />
242
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
De manera similar a todos los esquemas de handover propuestos<br />
anteriorm<strong>en</strong>te, cuando nBS recibe el m<strong>en</strong>saje de registro intra-dominio<br />
debe conectarse al árbol <strong>multicast</strong>. Adicionalm<strong>en</strong>te, y de manera<br />
simultánea, debe comunicarse con oBS para pedir el redireccionami<strong>en</strong>to<br />
de los paquetes p<strong>en</strong>di<strong>en</strong>tes. La comunicación <strong>en</strong>tre las dos estaciones base<br />
sólo se puede producir si nBS dispone de la información sobre la id<strong>en</strong>tidad<br />
de la estación base anterior. Esto se realiza de la misma manera que se<br />
propuso cuando se detalló <strong>en</strong> el handover abrupto. Es decir, incorporando<br />
la información al m<strong>en</strong>saje ‘Intra-Domanin Registration Request’. El formato<br />
de éste se muestra <strong>en</strong> el punto 6.6.2<br />
MN oBS nBS Nodo<br />
Cruce<br />
Datos<br />
Datos <strong>en</strong> Multicast<br />
Beacon<br />
Intra-Domanin Registration<br />
Request<br />
Multicast Prune Request<br />
Join<br />
ACK Join<br />
Leave Group<br />
Multicast Handover Reply<br />
Datos almac<strong>en</strong>ados<br />
Intra-Domanin Registration<br />
Reply<br />
Datos re<strong>en</strong>caminados<br />
Datos <strong>en</strong> Multicast<br />
Datos<br />
Figura 6.11. Esquema del proceso de Handover con Redireccionami<strong>en</strong>to.<br />
243
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
Tras la recepción del paquete de registro, nBS transmite un<br />
m<strong>en</strong>saje a oBS para que le re<strong>en</strong>camine los paquetes que ti<strong>en</strong>e p<strong>en</strong>di<strong>en</strong>tes<br />
de <strong>en</strong>vío hacia el nodo móvil. Adicionalm<strong>en</strong>te, la Estación Base antigua<br />
aprovecha el m<strong>en</strong>saje como indicación para que se desconecte del árbol<br />
<strong>multicast</strong>. Por este motivo se ha decidido aprovechar el m<strong>en</strong>saje ‘Multicast<br />
Prune Request’ que ya está definido <strong>en</strong> esquemas anteriores. En particular<br />
nBS le <strong>en</strong>vía a oBS un m<strong>en</strong>saje de recorte similar al mostrado <strong>en</strong> la figura<br />
6.3. La única difer<strong>en</strong>cia sería que ahora activamos el bit ‘R’, indicativo que<br />
estamos ante un handover con redireccionami<strong>en</strong>to, y desactivando el resto<br />
de bits. Este m<strong>en</strong>saje sería equival<strong>en</strong>te al m<strong>en</strong>saje ‘Binding Update<br />
Message’ sugerido <strong>en</strong> [PER01] (Work in Progress).<br />
Cuando oBS recibe el paquete ‘Multicast Prune Request’ se<br />
desconecta del árbol <strong>multicast</strong> y re<strong>en</strong>vía, por medio de un túnel, todos los<br />
paquetes almac<strong>en</strong>ados con destino al MN. La nueva estación base obti<strong>en</strong>e<br />
los paquetes y se los re<strong>en</strong>vía al MN como si fueran paquetes recibidos del<br />
árbol <strong>multicast</strong>.<br />
6.6.1 Solución a los problemas del esquema<br />
El esquema pres<strong>en</strong>tado ti<strong>en</strong>e algunos inconv<strong>en</strong>i<strong>en</strong>tes. El primero<br />
sería que, mi<strong>en</strong>tras el m<strong>en</strong>saje ‘Multicast Prune Request’ se transmite <strong>en</strong>tre<br />
las dos estaciones base, ambas están incorporadas al árbol <strong>multicast</strong>, por<br />
lo que pued<strong>en</strong> recibir por duplicado un pequeño número de paquetes. Esos<br />
paquetes serían retransmitidos, junto con los demás, de oBS a nBS, y por<br />
tanto <strong>en</strong>viados dos veces al nodo móvil.<br />
La solución puede ser que nBS almac<strong>en</strong>e, temporalm<strong>en</strong>te,<br />
información del primer paquete recibido del árbol <strong>multicast</strong>. Así, si recibe<br />
ese paquete re<strong>en</strong>viado desde oBS lo descarta junto con todos los que<br />
reciba de oBS posteriorm<strong>en</strong>te. Por ejemplo la figura 6.12 se muestra a<br />
situación cuando oBS acaba de recibir el m<strong>en</strong>saje ‘Multicast Prune<br />
Request’. oBS ti<strong>en</strong>e <strong>en</strong> el buffer los paquetes 7, 8 y 9 que re<strong>en</strong>viará hacia<br />
nBS, para que a su vez se transmitan al nodo móvil. El problema es que el<br />
244
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
paquete 9 ya lo ha recibido nBS por el árbol <strong>multicast</strong>, por lo que el nodo<br />
móvil acabaría recibiéndolo por duplicado.<br />
Nodo de<br />
Cruce<br />
10<br />
10<br />
9<br />
8<br />
7<br />
MPR<br />
9<br />
oBS<br />
nBS<br />
MN<br />
Figura 6.12 Problema por duplicación de paquetes <strong>en</strong> el handover indirecto.<br />
Un segundo problema sería que pued<strong>en</strong> existir paquetes perdidos<br />
durante el proceso de handover. En particular, cuando el nodo móvil<br />
com<strong>en</strong>zó el proceso de handover vía nBS ya había perdido conexión con la<br />
estación base anterior. Eso significa que existe un tiempo de lat<strong>en</strong>cia,<br />
donde el nodo móvil no ti<strong>en</strong>e conexión con oBS, y nBS aún no se ha<br />
conectado al árbol <strong>multicast</strong>. Durante este tiempo la Estación Base<br />
antigua ha estado transmiti<strong>en</strong>do paquetes por el interfaz radio, que no han<br />
sido recibidos por el nodo móvil, y que por tanto se han perdido.<br />
La propuesta de que las estaciones base almac<strong>en</strong><strong>en</strong> los últimos<br />
paquetes transmitidos es una bu<strong>en</strong>a solución, siempre que el tamaño de<br />
esta memoria se dim<strong>en</strong>sione adecuadam<strong>en</strong>te. En caso contrario puede que<br />
se continú<strong>en</strong> perdi<strong>en</strong>do paquetes, o bi<strong>en</strong> que paquetes <strong>en</strong>tregados<br />
realm<strong>en</strong>te al nodo móvil estén todavía <strong>en</strong> el buffer, <strong>en</strong> cuyo caso se<br />
transmitirían hacia nBS y, como <strong>en</strong> el problema anterior, acabarían<br />
duplicados <strong>en</strong> el MN. La figura 6.13 muestra el mecanismo de<br />
almac<strong>en</strong>ami<strong>en</strong>to temporal de paquetes ya transmitidos. En este ejemplo el<br />
paquete 5 sigue almac<strong>en</strong>ado <strong>en</strong> oBS a pesar de que ha sido recibido por<br />
245
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
MN. Un redireccionami<strong>en</strong>to de los paquetes hacia nBS se traducirá <strong>en</strong> una<br />
recepción duplicada, por parte del nodo móvil, del paquete número 5.<br />
La solución que proponemos a este segundo problema es similar a<br />
la que se empleó <strong>en</strong> el ‘Handover Suave con Finalización Controlada’<br />
estudiado <strong>en</strong> el punto anterior. Consiste <strong>en</strong> que el nodo móvil indique, <strong>en</strong><br />
el m<strong>en</strong>saje ‘Intra-Domanin Registration Request’, el último paquete recibido.<br />
En el punto 6.6.2 se muestra como queda finalm<strong>en</strong>te dicho m<strong>en</strong>saje.<br />
Nodo de<br />
Cruce<br />
Paquetes recibidos y no<br />
transmitidos<br />
9<br />
8<br />
7<br />
6<br />
5<br />
Paquetes ya transmitidos<br />
pero almac<strong>en</strong>ados<br />
temporalm<strong>en</strong>te<br />
MPR<br />
oBS<br />
nBS<br />
7<br />
6<br />
5<br />
Paquetes recibidos por el<br />
nodo móvil<br />
MN<br />
Figura 6.13 Problema por almac<strong>en</strong>ami<strong>en</strong>to <strong>en</strong> exceso de paquetes.<br />
La nueva estación base debe incluir esta información, recibida del<br />
MN, <strong>en</strong> el m<strong>en</strong>saje ‘Multicast Prune Request’ que <strong>en</strong>vía a oBS para que se<br />
produzca el redireccionami<strong>en</strong>to. Ahora la Estación Base antigua<br />
simplem<strong>en</strong>te re<strong>en</strong>caminará los paquetes que ti<strong>en</strong>e almac<strong>en</strong>ados para el<br />
MN, y que son posteriores al paquete que se indica el m<strong>en</strong>saje ‘Multicast<br />
Prune Request’ recibido. El formato final que proponemos para este<br />
m<strong>en</strong>saje también se muestra <strong>en</strong> el punto 6.6.2.<br />
Para simplificar el proceso, el m<strong>en</strong>saje ‘Multicast Prune Request’ no<br />
es confirmado. La estación base antigua, tras recibir el m<strong>en</strong>saje, contesta<br />
simplem<strong>en</strong>te <strong>en</strong>viando los paquetes p<strong>en</strong>di<strong>en</strong>tes. Es decir, se está utilizando<br />
el re<strong>en</strong>vío de los paquetes como mecanismo de reconocimi<strong>en</strong>to. Si, tras la<br />
246
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
espera de un cierto tiempo, nBS no recibe ningún paquete, se supone que<br />
el m<strong>en</strong>saje ‘Multicast Prune Request’ se ha perdido, por lo que lo <strong>en</strong>viaría de<br />
nuevo.<br />
Si se desea puede implem<strong>en</strong>tarse un mecanismo de confirmación<br />
explícito, simplem<strong>en</strong>te incorporando un m<strong>en</strong>saje de reconocimi<strong>en</strong>to que<br />
<strong>en</strong>viaría oBS. Este m<strong>en</strong>saje lo d<strong>en</strong>ominamos ‘Multicast Handover Reply’, y<br />
la propuesta del formato se muestra <strong>en</strong> el sigui<strong>en</strong>te punto.<br />
Como se aprecia <strong>en</strong> la figura 6.14, durante el handover los<br />
paquetes pued<strong>en</strong> llegar al nodo móvil de manera desord<strong>en</strong>ada. En concreto<br />
los paquetes temporalm<strong>en</strong>te almac<strong>en</strong>ados <strong>en</strong> oBS, y que están si<strong>en</strong>do<br />
redireccionados hacia nBS, puede que sean transmitidos al nodo móvil<br />
más tarde que otros paquetes que recibe nBS por estar conectado al árbol<br />
<strong>multicast</strong>.<br />
Nodo de<br />
Cruce<br />
10<br />
9<br />
8<br />
7<br />
oBS<br />
nBS<br />
9<br />
MN<br />
Figura 6.14 Posible desord<strong>en</strong> de paquetes durante el Handover.<br />
En la bibliografía donde se propon<strong>en</strong> soluciones de handover<br />
similares al ‘Handover con redireccionami<strong>en</strong>to’, por ejemplo [PER01],<br />
[PER99], no se plantea ningún mecanismo que evite el desord<strong>en</strong> de los<br />
paquetes. Tan solo el sistema Hawaii, donde los routers ti<strong>en</strong><strong>en</strong> ext<strong>en</strong>didas<br />
sus capacidades, soluciona el problema, haci<strong>en</strong>do que el<br />
247
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
redireccionami<strong>en</strong>to este controlado por el Nodo de Cruce (ver mecanismo<br />
SSF de Hawaii <strong>en</strong> el punto 4.4.3).<br />
En mecanismo de handover propuesto <strong>en</strong> este punto se podría<br />
modificar para int<strong>en</strong>tar solucionar el problema. La idea básica sería que<br />
oBS <strong>en</strong>viara el m<strong>en</strong>saje de confirmación ‘Multicast Handover Reply’ hacia<br />
nBS una vez ha acabado el redireccionami<strong>en</strong>to de los paquetes<br />
almac<strong>en</strong>ados. Mi<strong>en</strong>tras nBS, <strong>en</strong> vez de transmitir los paquetes que recibe<br />
del árbol <strong>multicast</strong>, podría almac<strong>en</strong>arlos a la espera del m<strong>en</strong>saje de oBS.<br />
Esta solución se complica <strong>en</strong> el caso de que el m<strong>en</strong>saje ‘Multicast Handover<br />
Reply’ se pierda o llegue con errores, pues <strong>en</strong> este desafortunado caso, la<br />
nueva Estación Base no com<strong>en</strong>zaría nunca su transmisión.<br />
Las posibles complicaciones de la solución al problema del<br />
desord<strong>en</strong> de los paquetes, junto al hecho de que el problema no es tan<br />
grave como una pérdida o una duplicación de paquetes, hac<strong>en</strong> que<br />
finalm<strong>en</strong>te no nos decantemos por la implem<strong>en</strong>tación de la misma. Es<br />
decir, el desord<strong>en</strong> de los paquetes será solucionado por las capas<br />
superiores. Al fin y al cabo, el protocolo IP es un protocolo no ori<strong>en</strong>tado a<br />
la conexión y se asume que los paquetes que viajan por la red pued<strong>en</strong><br />
desord<strong>en</strong>arse. Así, <strong>en</strong> el caso de utilizar el protocolo TCP será este quién<br />
solucione el problema, mi<strong>en</strong>tras que si se utiliza el protocolo de transporte<br />
UDP, la solución se dará a nivel de aplicación, por ejemplo basándose <strong>en</strong> la<br />
numeración de los m<strong>en</strong>sajes que proporciona el protocolo RTP [RFC 1889].<br />
6.6.2 Formato de los m<strong>en</strong>sajes utilizados <strong>en</strong> este esquema<br />
M<strong>en</strong>saje ‘Intra-Domanin Registration Request’<br />
En m<strong>en</strong>saje ‘Intra-Domanin Registration Request’ se ha incorporado<br />
información sobre la id<strong>en</strong>tidad de la estación base anterior, necesaria para<br />
que nBS pueda comunicarse con ella.<br />
248
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
Se ha modificado el segundo octeto del m<strong>en</strong>saje que se proponía <strong>en</strong><br />
el capítulo 3 (ver figura 3.16). Ahora existe un campo que indica el t<strong>ip</strong>o de<br />
handover que se desea realizar, de manera que se unifica los difer<strong>en</strong>tes<br />
esquemas de handover propuestos <strong>en</strong> este capítulo.<br />
Con el fin de indicar la dirección de la Estación Base anterior se<br />
podría optar por añadir la ext<strong>en</strong>sión que se propuso <strong>en</strong> el handover<br />
abrupto (figura 6.2) donde también hacía falta conocer la dirección de oBS.<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o S B D M G Hand. Tiempo de vida<br />
Home Address<br />
Care-of Address<br />
Dirección Multicast<br />
Id<strong>en</strong>tificador<br />
T<strong>ip</strong>o Longitud Dirección de la estación base anterior<br />
Dirección de la estación base anterior<br />
Ext<strong>en</strong>siones................<br />
Figura 6.15 Formato del m<strong>en</strong>saje ‘Intra-Domanin Registration Request’ para el<br />
esquema de Handover abrupto.<br />
Sin embargo, hemos com<strong>en</strong>tado que <strong>en</strong> éste esquema de handover<br />
el nodo móvil necesita indicar a nBS información sobre el último paquete<br />
recibido de oBS. La figura 6.16 muestra como se ha modificado la<br />
ext<strong>en</strong>sión de la figura 6.15, ampliada para cont<strong>en</strong>er esta información.<br />
249
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o Longitud Dirección de la estación base anterior<br />
Dirección de la estación base anterior<br />
Dirección Fu<strong>en</strong>te del último paquete<br />
Id<strong>en</strong>tificador del último paquete<br />
Fragm<strong>en</strong>to del último paquete<br />
Figura 6.16 Ext<strong>en</strong>sión del m<strong>en</strong>saje ‘Intra-Domanin Registration Request’ para el<br />
esquema de Handover con redireccionami<strong>en</strong>to.<br />
M<strong>en</strong>saje ‘Multicast Prune Request’<br />
El m<strong>en</strong>saje ‘Multicast Prune Request’ que se mostró <strong>en</strong> la figura 6.3<br />
para el handover abrupto ha sido modificado para que incorpore<br />
información sobre el último m<strong>en</strong>saje recibido por el MN.<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o A S R P<br />
Dirección Multicast<br />
Care-of Address (Dirección del MMA)<br />
Id<strong>en</strong>tificador<br />
Dirección Fu<strong>en</strong>te del último paquete<br />
Id<strong>en</strong>tificador del último paquete<br />
Fragm<strong>en</strong>to del último paquete<br />
Ext<strong>en</strong>siones................<br />
Figura 6.17 Formato del m<strong>en</strong>saje ‘Multicast Prune Request’.<br />
Así el m<strong>en</strong>saje quedaría como el mostrado <strong>en</strong> la figura 6.17. El bit<br />
‘R’ indica que estamos ante un handover con redireccionami<strong>en</strong>to. Como ya<br />
se ha com<strong>en</strong>tado con anterioridad, los campos Dirección fu<strong>en</strong>te,<br />
Id<strong>en</strong>tificador del último paquete y número de fragm<strong>en</strong>to permit<strong>en</strong> a oBS<br />
id<strong>en</strong>tificar unívocam<strong>en</strong>te el último paquete recibido por MN. De esta<br />
250
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
manera oBS re<strong>en</strong>viaría hacia nBS sólo los paquetes almac<strong>en</strong>ados que son<br />
posteriores.<br />
‘Multicast Handover Reply’<br />
En la figura 6.18 se muestra la propuesta del m<strong>en</strong>saje ‘Multicast<br />
Handover Reply’ que <strong>en</strong> el mecanismo de handover es opcional. Como <strong>en</strong><br />
todos los m<strong>en</strong>sajes anteriores, el campo ‘T<strong>ip</strong>o’ sería asignado por la IANA.<br />
El campo ‘Estado’ indicaría la respuesta al m<strong>en</strong>saje ‘Multicast Prune<br />
Request’. Posibles respuestas, además de la confirmación positiva, serían<br />
que la dirección <strong>multicast</strong> del móvil no aparece <strong>en</strong> sus tablas, o bi<strong>en</strong><br />
simplem<strong>en</strong>te que no exist<strong>en</strong> paquetes p<strong>en</strong>di<strong>en</strong>tes. El campo ‘Id<strong>en</strong>tificador’<br />
conti<strong>en</strong>e el mismo valor que el recibido <strong>en</strong> el m<strong>en</strong>saje ‘Multicast Prune<br />
Request’, y sirve para asociar peticiones a respuestas. Como <strong>en</strong> todos los<br />
m<strong>en</strong>sajes propuestos anteriorm<strong>en</strong>te, el m<strong>en</strong>saje debe terminar con una<br />
ext<strong>en</strong>sión de aut<strong>en</strong>tificación FA-FA.<br />
0 1 2 3<br />
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<br />
T<strong>ip</strong>o<br />
Estado<br />
Dirección Multicast<br />
Care-of Address (Dirección del MMA)<br />
Id<strong>en</strong>tificador<br />
Ext<strong>en</strong>siones................<br />
Figura 6.18 Formato del m<strong>en</strong>saje ‘Multicast Handover Reply’.<br />
Es interesante com<strong>en</strong>tar que este m<strong>en</strong>saje ‘Multicast Handover<br />
Reply’ propuesto puede ser utilizado también <strong>en</strong> los otros esquemas de<br />
handover detallados <strong>en</strong> puntos anteriores. Así, podría utilizarse <strong>en</strong> el<br />
‘Handover Suave con Finalización Controlada’, para confirmar el la<br />
recepción del m<strong>en</strong>saje ‘Handover Switch Indication’ <strong>en</strong>viado del nodo móvil<br />
a nBS. La confirmación de otros m<strong>en</strong>sajes, como los m<strong>en</strong>sajes ‘Multicast<br />
Prune Request’ de los esquemas de handover ‘Abrupto’ o ‘Semi Suave’, no<br />
251
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
es necesaria, pues la pérdida de los mismos no afecta de manera<br />
importante al bu<strong>en</strong> funcionami<strong>en</strong>to del esquema.<br />
La figura 6.11 mostraba un diagrama temporal del ‘Handover con<br />
Redireccionami<strong>en</strong>to’, donde se ha incluido el m<strong>en</strong>saje ‘Multicast Handover<br />
Reply’ que hemos definido como opcional.<br />
6.7 ESQUEMA DE HANDOVER INDIRECTO CON PRE-<br />
REGISTRO<br />
El esquema anterior int<strong>en</strong>taba obt<strong>en</strong>er un handover suave, donde<br />
primara la <strong>en</strong>trega de todos los paquetes. Por el contrario, exist<strong>en</strong><br />
determinadas situaciones, como cuando se ejecutan aplicaciones de<br />
tiempo real, donde el objetivo fundam<strong>en</strong>tal es conseguir un handover con<br />
baja lat<strong>en</strong>cia.<br />
En sistemas donde el nodo se puede comunicar con las dos<br />
estaciones base de manera simultanea, el handover será siempre con baja<br />
lat<strong>en</strong>cia, ya que si la zona de solape es lo sufici<strong>en</strong>tem<strong>en</strong>te amplia, el nodo<br />
no t<strong>en</strong>drá interrupción <strong>en</strong> la comunicación. En los puntos 6.4 y 6.5 se han<br />
estudiado ejemplos de handovers que trabajan con esta situación.<br />
En este punto se va a proponer un handover de baja lat<strong>en</strong>cia para<br />
sistemas donde, <strong>en</strong> un instante de tiempo, el nodo móvil solo se puede<br />
comunicar con una estación base. El esquema, d<strong>en</strong>ominado ‘Handover con<br />
Pre-registro’ está <strong>basado</strong> <strong>en</strong> la utilización de ‘triggers’ [YEG02] (Work in<br />
Progress). Actualm<strong>en</strong>te existe alguna solución semejante <strong>en</strong> proceso de<br />
investigación, [ELM02], [KOO02], aunque tan solo están aplicadas al<br />
protocolo Mobile IP original, y a sistemas con Registro Regional (RR-MIP,<br />
ver punto 2.3.7).<br />
La idea es <strong>en</strong>viar un m<strong>en</strong>saje a nBS (utilizando para ello a oBS)<br />
para que comi<strong>en</strong>ce su incorporación al árbol <strong>multicast</strong> instantes antes de<br />
realizar el handover de nivel 2. El fin es disminuir los compon<strong>en</strong>tes de la<br />
252
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
lat<strong>en</strong>cia del handover (punto 4.2), tanto el tiempo de detección de<br />
movimi<strong>en</strong>to, T move-detect , utilizando para ello ‘triggers’, como el tiempo de<br />
redireccionami<strong>en</strong>to, T redirect , adelantándolo y solapándolo al primero.<br />
Como se propone <strong>en</strong> [ELM02], previam<strong>en</strong>te al inicio del proceso de<br />
handover las difer<strong>en</strong>tes Estaciones Base intercambian m<strong>en</strong>sajes ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t’, solicitados mediante m<strong>en</strong>sajes ‘Ag<strong>en</strong>t Solicitation’ y<br />
almac<strong>en</strong>ados temporalm<strong>en</strong>te <strong>en</strong> memoria.<br />
El nodo móvil, tras recibir un trigger L2 indicando que se va a<br />
producir, <strong>en</strong> un futuro próximo, un handover a nivel dos (ver tabla 4.1),<br />
<strong>en</strong>vía un m<strong>en</strong>saje del t<strong>ip</strong>o ‘Proxy Ag<strong>en</strong>t Solicitation’ a oBS, con quién<br />
evid<strong>en</strong>tem<strong>en</strong>te ti<strong>en</strong>e conexión. Este m<strong>en</strong>saje es idéntico al m<strong>en</strong>saje<br />
tradicional, que según se define <strong>en</strong> [RFC 3344] se corresponde con un<br />
m<strong>en</strong>saje ‘ICMP Router Solicitation’, excepto por una ext<strong>en</strong>sión que indicaría<br />
que la solicitud es para nBS.<br />
oBS responde a la petición <strong>en</strong>viando el m<strong>en</strong>saje ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t’ que t<strong>en</strong>ía previam<strong>en</strong>te almac<strong>en</strong>ado de nBS. Dep<strong>en</strong>di<strong>en</strong>do de<br />
quién inicia el proceso de handover, este m<strong>en</strong>saje podría haber sido<br />
<strong>en</strong>viado directam<strong>en</strong>te por oBS aunque no existiera solicitud previa.<br />
El nodo móvil detecta la necesidad de realizar el handover intradominio,<br />
y por tanto <strong>en</strong>vía un m<strong>en</strong>saje ‘Intra-Domanin Registration Request’<br />
dirigido hacia nBS. Sin embargo, el móvil no ti<strong>en</strong>e conectividad con esta<br />
estación, pues el proceso de handover a nivel 2 no se ha producido. Así el<br />
m<strong>en</strong>saje de registro deberá ser transmitido vía oBS. La figura 6.19 muestra<br />
el diagrama temporal del Handover con Pre-registro.<br />
Tras la recepción del m<strong>en</strong>saje, nBS se comporta como si hubiera<br />
recibido directam<strong>en</strong>te el m<strong>en</strong>saje por el interfaz inalámbrico, es decir,<br />
realizando la incorporación al árbol <strong>multicast</strong>. El m<strong>en</strong>saje ‘Intra-Domanin<br />
Registration Reply’, indicativo de que se ha realizado correctam<strong>en</strong>te el<br />
proceso de handover L3, será <strong>en</strong>tregado al nodo móvil tan pronto se<br />
complete el handover de nivel dos. Esta detección se realizará típicam<strong>en</strong>te<br />
utilizando un trigger ‘L2-UP’ <strong>en</strong> nBS.<br />
253
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
MN oBS nBS Nodo<br />
Cruce<br />
Datos<br />
Datos <strong>en</strong> Multicast<br />
TriggerL2-MT<br />
Proxy Ag<strong>en</strong>t<br />
Solicitation<br />
Proxy Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t<br />
Intra-Domanin Registration<br />
Request<br />
Join<br />
TriggerL2-LU<br />
Intra-Domanin Registration<br />
Reply<br />
ACK Join<br />
Multicast Prune Request<br />
Leave Group<br />
Datos<br />
Datos <strong>en</strong> Multicast<br />
Figura 6.19 Esquema del proceso de Handover con Pre-registro.<br />
Como <strong>en</strong> los esquemas anteriores, tan solo quedaría avisar a oBS<br />
del handover que ha realizado el nodo móvil, a fin de que pueda liberar<br />
recursos. Una opción es que la propia oBS detecte que el nodo móvil ha<br />
realizado un handover, utilizando para ello un trigger ‘L2-LD’ (ver tabla<br />
4.1).<br />
254
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
Otra solución es que nBS informe a oBS. Así, nBS transmite, de<br />
manera simultanea al <strong>en</strong>vío del m<strong>en</strong>saje de reconocimi<strong>en</strong>to de registro<br />
hacia NM, el m<strong>en</strong>saje d<strong>en</strong>ominado ‘Multicast Prune Request’ con dirección<br />
oBS. Este m<strong>en</strong>saje sería similar al mostrado <strong>en</strong> la figura 6.3, con la<br />
difer<strong>en</strong>cia de que ahora se activa el bit ‘P’. Como <strong>en</strong> el caso del ‘Handover<br />
Abrupto’, para que la nueva Estación Base t<strong>en</strong>ga conocimi<strong>en</strong>to de la<br />
dirección IP a donde <strong>en</strong>viar el paquete, será necesario añadir al m<strong>en</strong>saje<br />
‘Intra-Domain Registration Request’ la ext<strong>en</strong>sión mostrada <strong>en</strong> la figura 6.2.<br />
6.8 RESUMEN Y CONCLUSIONES DE LOS ESQUEMAS<br />
DE HANDOVER PROPUESTOS<br />
Al estudiar el concepto de handover se indicó que exist<strong>en</strong> dos<br />
características fundam<strong>en</strong>tales. La primera es el número de paquetes que<br />
se pierd<strong>en</strong> durante el proceso. Aparece así el término de ‘Handover Suave’<br />
[MAN02], relativo al esquema que ti<strong>en</strong>e por objetivo minimizar la pérdida<br />
de paquetes. Tradicionalm<strong>en</strong>te se utilizan dos técnicas para lograr la<br />
<strong>en</strong>trega de todos los paquetes. Una opción sería introducir algún<br />
mecanismo de retransmisión de paquetes p<strong>en</strong>di<strong>en</strong>tes desde oBS a nBS.<br />
Otra posibilidad sería realizar una transmisión dualcast temporal de<br />
manera que las dos estaciones implicadas recib<strong>en</strong> los paquetes dirigidos al<br />
nodo móvil.<br />
La segunda característica de los esquemas de handover es el<br />
retardo que sufr<strong>en</strong> los paquetes. Así t<strong>en</strong>emos el concepto de ‘Handover<br />
Rápido’, referido a los procesos de handover que ti<strong>en</strong><strong>en</strong> como su princ<strong>ip</strong>al<br />
motivación la <strong>en</strong>trega de paquetes con retardo mínimo. También aquí la<br />
bibliografía pres<strong>en</strong>ta distintas soluciones que int<strong>en</strong>tan minimizar este<br />
retardo. Una solución sería minimizar la lat<strong>en</strong>cia del proceso de handover,<br />
por ejemplo adelantando el inicio basándonos <strong>en</strong> la utilización de ‘triggers’.<br />
Otra solución sería no interrumpir la <strong>en</strong>trega de paquetes mi<strong>en</strong>tras dura el<br />
handover, por ejemplo implem<strong>en</strong>tando <strong>en</strong> los nodos móviles la capacidad<br />
de hablar simultáneam<strong>en</strong>te con las dos estaciones base.<br />
255
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
El sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>, pres<strong>en</strong>tado <strong>en</strong><br />
el capítulo 3, ofrece unas propiedades intrínsecas idóneas para lograr,<br />
tanto handovers intra-dominio rápidos, como suaves.<br />
En particular, el tiempo de lat<strong>en</strong>cia del handover se reduce al<br />
mínimo. Así, el compon<strong>en</strong>te del tiempo de lat<strong>en</strong>cia que d<strong>en</strong>ominamos<br />
‘Retardo <strong>en</strong> la Recuperación de una Dirección Temporal’ (T co-retrieval ), se<br />
elimina por completo. Además, el tiempo ‘Retardo de reestablecimi<strong>en</strong>to de<br />
la ruta’ (T redirect ) se reduce al tiempo necesario para la conexión de la nueva<br />
Estación Base al árbol <strong>multicast</strong>.<br />
Con respecto a la transmisión sin pérdidas de paquetes, el sistema<br />
de micro-<strong>movilidad</strong> pres<strong>en</strong>tado se basa <strong>en</strong> la conexión de las estaciones<br />
base a un árbol <strong>multicast</strong> asociado al nodo móvil. Esto lleva implícito una<br />
transmisión de paquetes hacia las dos estaciones de manera simultánea,<br />
facilitando <strong>en</strong>ormem<strong>en</strong>te la implem<strong>en</strong>tación de handovers suaves.<br />
En este punto hemos elaborado cinco esquemas de handover<br />
difer<strong>en</strong>tes, diseñados para implem<strong>en</strong>tarse <strong>en</strong> el sistema de micro-<strong>movilidad</strong><br />
propuesto <strong>en</strong> el capítulo 3. Podemos hacer una clasificación t<strong>en</strong>i<strong>en</strong>do <strong>en</strong><br />
cu<strong>en</strong>ta la capacidad que ofrece la red para permitir al nodo móvil de<br />
comunicarse o no con las dos estaciones base de manera simultánea.<br />
Por un lado t<strong>en</strong>emos los esquemas de handover, d<strong>en</strong>ominados <strong>en</strong> la<br />
bibliografía ‘Break-Before-Make’, <strong>en</strong> los cuales el nodo móvil no es capaz de<br />
mant<strong>en</strong>er la comunicación con oBS cuando se realiza el handover con<br />
nBS. En este <strong>en</strong>torno se han propuestos tres esquemas difer<strong>en</strong>tes. El<br />
primero ha sido d<strong>en</strong>ominado ‘Handover Abrupto’, y aquí nos basamos <strong>en</strong><br />
las facilidades intrínsecas del sistema de micro-<strong>movilidad</strong> para diseñar un<br />
esquema lo más simple posible. El segundo esquema se ha d<strong>en</strong>ominado<br />
‘Handover con Redireccionami<strong>en</strong>to’ y logra minimizar las pérdidas de<br />
paquetes recurri<strong>en</strong>do a la retransmisión de los paquetes p<strong>en</strong>di<strong>en</strong>tes <strong>en</strong>tre<br />
estaciones base. En este esquema se han realizado propuestas novedosas<br />
para eliminar la duplicidad de paquetes <strong>en</strong> el receptor, aunque no se<br />
int<strong>en</strong>ta evitar el posible desord<strong>en</strong> de los paquetes. Por último, el tercer<br />
handover se ha d<strong>en</strong>ominado ‘Handover Indirecto con Pre-registro’, y su<br />
256
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
objetivo es ofrecer un handover rápido, minimizando el retardo de <strong>en</strong>trega<br />
de los paquetes, basándose <strong>en</strong> la utilización de ‘triggers’.<br />
Los otros dos handovers propuestos se basan <strong>en</strong> la capacidad del<br />
nodo móvil de comunicarse simultáneam<strong>en</strong>te con las dos BS. Estos<br />
esquemas se suel<strong>en</strong> d<strong>en</strong>ominar ‘Make-Before-Break’. El primer esquema,<br />
llamado ‘Handover Semi-suave’, funciona sobre la base de que mi<strong>en</strong>tras<br />
nBS se está conectando al árbol <strong>multicast</strong> el nodo móvil sigue recibi<strong>en</strong>do<br />
paquetes vía oBS. De esta manera, t<strong>en</strong>i<strong>en</strong>do una zona de solape de<br />
coberturas lo sufici<strong>en</strong>tem<strong>en</strong>te amplia, se consigue un handover sin retardo<br />
y con muy pocas pérdidas. El último esquema, d<strong>en</strong>ominado ‘Handover<br />
Suave con Finalización Controlada’, es una solución novedosa que ofrece<br />
un handover rápido y suave, d<strong>en</strong>ominado ‘Sin Degradación’ o ‘Seamless’<br />
<strong>en</strong> la literatura. Este mecanismo se basa <strong>en</strong> dar capacidad al nodo móvil<br />
para retrasar la finalización de la comunicación con oBS, y la capacidad<br />
de nBS de almac<strong>en</strong>ar paquetes hasta que son solicitados por MN.<br />
Para la implem<strong>en</strong>tación de estos esquemas se ha t<strong>en</strong>ido que<br />
diseñar distintos m<strong>en</strong>sajes de control, a la vez que modificar o ampliar<br />
algunos de los formatos de los m<strong>en</strong>sajes que fueron creados <strong>en</strong> el capítulo<br />
3. En este desarrollo ha primado el concepto de integración y la visión<br />
única del sistema, de manera que los mismos paquetes pued<strong>en</strong> ser<br />
utilizados <strong>en</strong> los difer<strong>en</strong>tes esquemas.<br />
En concreto se ha diseñado el m<strong>en</strong>saje ‘Multicast Prune Request’<br />
(figuras 6.3 y 6.17) que, con diversas ext<strong>en</strong>siones, es utilizado <strong>en</strong> los cinco<br />
esquemas de handover. La confirmación a este m<strong>en</strong>saje, <strong>en</strong> caso de que el<br />
esquema lo requiriera, se realizaría con el m<strong>en</strong>saje ‘Multicast Handover<br />
Reply’ (fig. 6.18).<br />
Adicionalm<strong>en</strong>te se ha diseñado el m<strong>en</strong>saje ‘Handover Switch<br />
Indication’ empleado <strong>en</strong> el esquema ‘Handover Suave con Finalización<br />
Controlada’ (fig. 6.9)<br />
El m<strong>en</strong>saje ‘Intra-Domain Registration Request’ ha sido ampliado<br />
con dos ext<strong>en</strong>siones difer<strong>en</strong>tes utilizadas dep<strong>en</strong>di<strong>en</strong>do del esquema de<br />
257
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
handover (fig. 6.2 y 6.16). Finalm<strong>en</strong>te el m<strong>en</strong>saje ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ se<br />
ha ampliado incluy<strong>en</strong>do una ext<strong>en</strong>sión de información que puede<br />
observarse <strong>en</strong> la figura 6.10.<br />
La figura 6.20 resume los cinco esquemas de handover propuestos.<br />
Nodo de<br />
Cruce<br />
Nodo de<br />
Cruce<br />
6 Leave<br />
Group<br />
5 MPRq<br />
3 Ack Join<br />
2 Join<br />
6 Leave<br />
Group<br />
3 Ack Join<br />
2 Join<br />
oBS<br />
nBS<br />
1 IDRRq<br />
oBS<br />
4 IDRRp<br />
nBS<br />
4 IDRRp<br />
5 MPRq<br />
1 IDRRq<br />
MN<br />
MN<br />
(a) Handover Abrupto<br />
(b) Handover Semi Suave<br />
Nodo de<br />
Cruce<br />
Nodo de<br />
Cruce<br />
6 Leave<br />
Group<br />
3 Ack Join<br />
2 Join<br />
6 Leave<br />
Group<br />
5 MPRq<br />
3 Ack Join<br />
2 Join<br />
oBS<br />
4 IDRRp<br />
nBS<br />
1 IDRRq<br />
oBS<br />
7 MHRp<br />
nBS<br />
1 IDRRq<br />
5 MPRq<br />
7 HSI<br />
4 IDRRp<br />
MN<br />
MN<br />
(c) Handover Suave con Finalización Controlada<br />
(d) Handover con Redireccionami<strong>en</strong>to<br />
258
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
8 Leave<br />
Group<br />
oBS<br />
1 PAS<br />
2 PAA<br />
Nodo de<br />
Cruce<br />
7 MPRq<br />
3 IDRRq<br />
5 Ack Join<br />
MN<br />
4 Join<br />
6 IDRRp<br />
nBS<br />
IDRRq: ‘Intra Domain Registration Request’<br />
IDRRp: ‘Intra Domain Registration Reply’<br />
MPRq: ‘Multicast Prune Request’<br />
HSI: ‘Handover Switch Indication’<br />
MHRp: ‘Multicast Handover Reply’<br />
PAS: ‘Proxy Ag<strong>en</strong>t Solicitation’<br />
PAA: ‘Proxy Ag<strong>en</strong>t Advertisem<strong>en</strong>t’<br />
(d) Handover con Pre-registro<br />
Figura 6.20 Resum<strong>en</strong> de esquemas de Handover.<br />
La tabla 6.1 muestra un estudio de los cinco mecanismos de<br />
handover que hemos propuesto <strong>en</strong> este capítulo. El significado de las<br />
siglas que se han empleado para nombrar los distintos m<strong>en</strong>sajes se puede<br />
<strong>en</strong>contrar <strong>en</strong> la figura anterior. En la tabla se puede observar como<br />
algunos esquemas están p<strong>en</strong>sados para redes <strong>en</strong> las que el MN ti<strong>en</strong>e la<br />
capacidad de comunicarse con las dos estaciones base directam<strong>en</strong>te.<br />
Además puede apreciarse como exist<strong>en</strong> soluciones tanto para handovers<br />
suaves como rápidos. Se ha habilitado un mecanismo para permitir la<br />
elección de un esquema u otro. Esto lo realiza el nodo móvil a partir de los<br />
campos habilitados <strong>en</strong> el m<strong>en</strong>saje ‘Intra Domain Registration Request’. A su<br />
vez hemos diseñado una ext<strong>en</strong>sión al m<strong>en</strong>saje ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ para<br />
el caso de que el MN necesitara información de la red.<br />
259
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
Mecanismo de<br />
Handover<br />
Comunicación<br />
simultanea<br />
con las 2 BS.<br />
Handover<br />
Suave<br />
Handover<br />
Rápido<br />
Abrupto No No Si<br />
M<strong>en</strong>sajes<br />
utilizados<br />
IDDRq con<br />
ext<strong>en</strong>sión<br />
IDDRp<br />
MPRq opcional<br />
IDDRq<br />
Semi Suave<br />
Si<br />
Si con<br />
limitaciones<br />
Si<br />
IDDRp<br />
MPRq<br />
IDDRq<br />
Suave con<br />
finalización<br />
controlda<br />
Si Si No<br />
IDDRp<br />
MPRq<br />
HSI<br />
Ext<strong>en</strong>. de Ag<strong>en</strong>t<br />
Adv.<br />
Con<br />
Redireccionami<strong>en</strong>to<br />
No Si No<br />
IDDRq con<br />
ext<strong>en</strong>sión<br />
IDDRp<br />
MPRq con<br />
ext<strong>en</strong>sión<br />
MHRp opcional<br />
IDDRq con<br />
ext<strong>en</strong>sión<br />
Con Pre-registro No No Si<br />
IDDRp<br />
MPRq<br />
Triggers.<br />
Tabla 6.1 Características básicas de los difer<strong>en</strong>tes esquemas de Handover<br />
propuestos.<br />
Para finalizar la taba 6.2 muestra las v<strong>en</strong>tajas e inconv<strong>en</strong>i<strong>en</strong>tes de<br />
los cinco mecanismos de handover que proponemos <strong>en</strong> este capítulo.<br />
260
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong><br />
Mecanismo de<br />
Handover<br />
Abrupto<br />
Semi Suave<br />
Suave con<br />
finalización controlda<br />
Con<br />
Redireccionami<strong>en</strong>to<br />
V<strong>en</strong>tajas<br />
S<strong>en</strong>cillo<br />
Rápido<br />
Bu<strong>en</strong>as prestaciones al<br />
basarse <strong>en</strong> <strong>multicast</strong>.<br />
S<strong>en</strong>cillo<br />
Rápido<br />
En muchas situaciones<br />
no se pierd<strong>en</strong> paquetes<br />
(suave)<br />
Handover suave sin<br />
pérdida de paquetes<br />
Handover suave sin<br />
pérdida de paquetes<br />
Inconv<strong>en</strong>i<strong>en</strong>tes<br />
Se pierd<strong>en</strong> paquetes<br />
Tiempo de interrupción<br />
En situaciones especiales se<br />
pierd<strong>en</strong> o duplican paquetes<br />
Complejo<br />
Necesario comunicación<br />
<strong>en</strong>tre BS<br />
Retardo <strong>en</strong> paquetes<br />
almac<strong>en</strong>ados.<br />
Complejo<br />
Necesario comunicación<br />
<strong>en</strong>tre BS<br />
Retardo elevado <strong>en</strong> paquetes<br />
almac<strong>en</strong>ados.<br />
Con Pre-registro<br />
Handover s<strong>en</strong>cillo<br />
Rápido<br />
Necesidad de comunicación<br />
<strong>en</strong>tre capas (triggers)<br />
Tabla 6.2 V<strong>en</strong>tajas e Inconv<strong>en</strong>i<strong>en</strong>tes de los difer<strong>en</strong>tes esquemas de Handover.<br />
261
262<br />
Mecanismos de Handover para el sistema <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>
7. EVALUACIÓN ANALÍTICA DE LOS<br />
MECANISMOS DE HANDOVER INTRA-DOMINIO<br />
7.1 INTRODUCCIÓN<br />
En este capítulo se va a desarrollar un modelado analítico de los<br />
difer<strong>en</strong>tes esquemas de handover para el sistema de micro<strong>movilidad</strong><br />
<strong>basado</strong> <strong>en</strong> <strong>multicast</strong> que se propuso <strong>en</strong> el capítulo anterior. El fin es<br />
realizar una comparación de las difer<strong>en</strong>tes soluciones, a la vez que<br />
investigar la influ<strong>en</strong>cia de algunos parámetros de diseño, como puede ser<br />
el tamaño de los ‘buffers’. Los estudios se c<strong>en</strong>trarán <strong>en</strong> el número de<br />
paquetes perdidos debido al mecanismo de handover, así como el retardo<br />
adicional que se introduce <strong>en</strong> los paquetes que, por el modo de<br />
funcionami<strong>en</strong>to del handover, deb<strong>en</strong> ser redireccionados o almac<strong>en</strong>ados.<br />
Con el fin de lograr un modelado relativam<strong>en</strong>te simple vamos a<br />
optar por modelar los routers como colas M/M/1. Esta suposición ya ha<br />
sido utilizada por C. Blondia, quién ha realizado un modelado analítico de<br />
algunos sistemas de micro<strong>movilidad</strong> como Hawaii y Cellular IP [BLO02],<br />
[BLO02b].<br />
Así, asumimos que el tiempo de servicio de un paquete <strong>en</strong> un<br />
router está distribuido expon<strong>en</strong>cialm<strong>en</strong>te, e incluye el tiempo de<br />
procesami<strong>en</strong>to y el tiempo de transmisión. Si llamamos µ a la tasa de<br />
servicio de un router A, y ρ a la carga, este tiempo de respuesta R A estará<br />
distribuido expon<strong>en</strong>cialm<strong>en</strong>te con una tasa de µ(1-ρ), [KLE75]. El retardo<br />
de propagación <strong>en</strong>tre dos routers se considerará fijo y se indicará mediante<br />
el formato ( R X , R Y ). Finalm<strong>en</strong>te el retardo <strong>en</strong>tre la estación base y el nodo<br />
móvil lo consideramos despreciable.<br />
Para estandarizar los cálculos, los modelos analíticos de todos los<br />
esquemas de handover van a considerar arquitecturas de red como las<br />
mostradas <strong>en</strong> la figura 7.1. En particular, para aquellos mecanismos de<br />
263
Evaluación analítica.<br />
handover <strong>en</strong> los que se requiere una comunicación <strong>en</strong>tre las dos<br />
estaciones base, se optará por la figura 7.1b, que indep<strong>en</strong>diza la<br />
estructura del árbol <strong>multicast</strong> de la estructura de la red (handover con<br />
redireccionami<strong>en</strong>to y handover con pre-registro). Para todos los demás<br />
casos se utilizará la arquitectura 7.1a.<br />
a)<br />
Nodo de<br />
Cruce CN<br />
b)<br />
Nodo de<br />
Cruce CN<br />
R1<br />
R2<br />
R1<br />
R2<br />
oBS<br />
R3<br />
nBS<br />
oBS<br />
nBS<br />
MN<br />
MN<br />
Figura 7.1 Esquema de la Red para el modelado analítico.<br />
7.2 ESQUEMA DE HANDOVER ABRUPTO<br />
7.2.1 Desarrollo analítico<br />
Para analizar el handover abrupto estudiado <strong>en</strong> el punto 6.3<br />
partimos de la figura 7.1a. Definimos t ho como el instante de tiempo <strong>en</strong> el<br />
que comi<strong>en</strong>za el proceso de handover. En este esquema ese instante se<br />
corresponde con el instante de tiempo <strong>en</strong> el que el nodo móvil deja de<br />
recibir paquetes de la estación antigua oBS.<br />
Definimos t 1 como el instante de tiempo a partir del cual los<br />
paquetes que alcanc<strong>en</strong> el nodo de cruce CN se perderán porque llegarán al<br />
264
Evaluación analítica<br />
nodo móvil después del instante t ho . Por último definimos t 2 como el<br />
instante de tiempo <strong>en</strong> el que el nodo de cruce recibe, vía nBS, la<br />
información de que se ha producido un handover (m<strong>en</strong>saje ‘Join’ de la<br />
figura 6.1). Por tanto, a partir de este instante se restablecería la<br />
comunicación, dejándose de perder paquetes.<br />
Sigui<strong>en</strong>do la nom<strong>en</strong>clatura explicada anteriorm<strong>en</strong>te podemos<br />
calcular t 1 como sigue:<br />
[ CN + CN,<br />
R ) + R + ( R , oBS oBS]<br />
t1 = tho − ( 1 1 1 ) +<br />
(7.1)<br />
En la ecuación anterior el valor t 1 es igual al tiempo <strong>en</strong> el que se<br />
produce el handover al que le restamos unos retardos fijos y los tiempos de<br />
procesami<strong>en</strong>to de los difer<strong>en</strong>tes dispositivos, que seguirán una<br />
distribución expon<strong>en</strong>cial. Podemos simplificar la ecuación de la sigui<strong>en</strong>te<br />
manera:<br />
[ X c]<br />
t1 = tho − +<br />
(7.2)<br />
si<strong>en</strong>do c = ( CN,<br />
R1 ) + ( R1<br />
, oBS)<br />
una constante y X una variable aleatoria con<br />
función de d<strong>en</strong>sidad de distribución f X (t)<br />
, que ha sido calculada como la<br />
convolución de las d<strong>en</strong>sidades de distribución de los dispositivos<br />
implicados, y que se corresponde con una d<strong>en</strong>sidad de distribución Erlang.<br />
f<br />
X<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
Del mismo modo podemos describir t 2 como sigue:<br />
t2 = tho + ∆h<br />
+ nBS + ( nBS,<br />
R2<br />
) + R2<br />
+ ( R2,<br />
CN)<br />
(7.3)<br />
En esta expresión, ∆ h se corresponde con el tiempo que le cuesta<br />
al nodo móvil detectar que se ha producido el handover y que ha pasado a<br />
dep<strong>en</strong>der de nBS. Ya que el mecanismo de handover abrupto no ofrece la<br />
utilización de ‘triggers’ [YEG02] que agilic<strong>en</strong> la detección, este tiempo de<br />
detección dep<strong>en</strong>derá del periodo de <strong>en</strong>vío los m<strong>en</strong>sajes ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t’, que <strong>en</strong> el protocolo Mobile IP [RFC 3344] se realiza cada<br />
265
Evaluación analítica.<br />
segundo. Así ∆ h es una variable aleatoria con una función de d<strong>en</strong>sidad de<br />
distribución uniforme <strong>en</strong>tre 0 y el periodo de <strong>en</strong>vío de m<strong>en</strong>sajes ∆ ho .<br />
Simplificando la expresión como se hizo anteriorm<strong>en</strong>te con t 1 :<br />
t2 = tho + ∆h<br />
+ Y + d<br />
(7.4)<br />
con<br />
d = ( nBS,<br />
R2 ) + ( R2,<br />
CN)<br />
f<br />
Y<br />
2<br />
−β<br />
t<br />
( t)<br />
= β te para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
Con el fin facilitar el desarrollo analítico podemos, sin perder<br />
g<strong>en</strong>eralidad, asignar a t 1 el valor 0:<br />
[ X + ] 0<br />
t ho ⇒ t ho = X + c<br />
(7.5)<br />
1 = t − c =<br />
Así el valor t 2 quedaría, tras sustituir (7.5) <strong>en</strong> (7.4) y simplificar:<br />
t 2 = ∆h<br />
+ Z + e<br />
(7.6)<br />
con:<br />
e = c + d<br />
f<br />
Z<br />
5 4<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
(7.7)<br />
4!<br />
Consideremos ahora un flujo de paquetes que, g<strong>en</strong>erados por un<br />
host, llegan al nodo de cruce con un tiempo <strong>en</strong>tre llegadas constante de T<br />
mseg. Al haber normalizado el tiempo t 0 , los paquetes que pued<strong>en</strong><br />
perderse serán aquellos que llegan al nodo de cruce CN <strong>en</strong> un tiempo<br />
positivo. Para eliminar cualquier dep<strong>en</strong>d<strong>en</strong>cia con el instante <strong>en</strong> que se<br />
produce el handover, el instante <strong>en</strong> que llega el primer paquete susceptible<br />
de que se pierda durante el proceso de handover lo d<strong>en</strong>ominamos u, y es<br />
un valor aleatorio uniformem<strong>en</strong>te distribuido <strong>en</strong>tre [0,T].<br />
1 =<br />
266
Evaluación analítica<br />
La probabilidad de que el paquete k-ésimo, que llega a CN <strong>en</strong> el<br />
instante de tiempo (k-1)T+u, se pierda, la d<strong>en</strong>ominamos Pper<br />
− k . Esta<br />
probabilidad es igual a la probabilidad de que el instante de tiempo <strong>en</strong> el<br />
que llega el paquete sea mayor que t 1 y m<strong>en</strong>or que t 2 :<br />
P<br />
= Prob[ t1 < ( k −1)<br />
T + u < t ]=<br />
= Prob [ 0 < ( k −1)T<br />
+ u < ∆h<br />
+ Z + e]=<br />
= Prob [ Z > ( k −1)<br />
T + u − ∆h<br />
− e]=<br />
per −k<br />
2<br />
[ Z ≤ ( k −1<br />
T + u − ∆h<br />
− e]<br />
= 1 − Prob )<br />
(7.8)<br />
Tanto u como ∆ h son dos variables aleatorias completam<strong>en</strong>te<br />
indep<strong>en</strong>di<strong>en</strong>tes. Por tanto podemos definir una nueva variable como la<br />
resta de las dos, W = u − ∆h<br />
. En el caso de T < ∆ho<br />
esta nueva v.a. ti<strong>en</strong>e la<br />
función de d<strong>en</strong>sidad de distribución sigui<strong>en</strong>te:<br />
f w<br />
⎧(<br />
t + ∆ho)<br />
T∆ho<br />
⎪<br />
1 ∆ho<br />
( t)<br />
= ⎨<br />
⎪ ( − t + T ) T∆ho<br />
⎪<br />
⎩ 0<br />
− ∆ho<br />
< t < −∆ho<br />
+ T<br />
− ∆ho<br />
+ T ≤ t ≤ 0<br />
0 < t < T<br />
resto<br />
(7.9)<br />
Así, la ecuación (7.8) dep<strong>en</strong>de tan sólo de dos variables aleatorias.<br />
Podemos por tanto rescribir esta ecuación de la sigui<strong>en</strong>te manera:<br />
[ Z ≤ ( k −1)<br />
T − e + W W wo] f ( wo)<br />
dwo<br />
Pper−<br />
k = 1 − Prob<br />
= w<br />
(7.10)<br />
∫<br />
Según (7.9) los límites de la integral anterior estarían <strong>en</strong>tre - ∆ho<br />
y<br />
T, puesto que la función de d<strong>en</strong>sidad de distribución f w (t)<br />
es 0 fuera de<br />
este intervalo. Sin embargo, la v.a. Z no puede ser m<strong>en</strong>or que cero, ya que<br />
se corresponde con la suma de los tiempos de respuesta de los difer<strong>en</strong>tes<br />
dispositivos. Así el límite inferior de la integral sería:<br />
Si<br />
Si<br />
( k − 1)<br />
T − e > ∆ho<br />
⇒ límite inferior = - ∆ ho<br />
( k − 1)<br />
T − e ≤ ∆ho<br />
⇒ límite inferior = e-(k-1)T<br />
267
Evaluación analítica.<br />
Es decir:<br />
P<br />
Pr ob<br />
[ −∆ho,<br />
e−(<br />
k −1)<br />
T ]<br />
[ Z ≤ ( k −1)<br />
T − e + W W wo]<br />
T<br />
per ∫<br />
− k = 1 −<br />
=<br />
max<br />
f ( wo)<br />
dwo<br />
Por último, la probabilidad de que la v.a. Z sea m<strong>en</strong>or que un valor<br />
dado es equival<strong>en</strong>te a la función de distribución F z (t)<br />
. A partir de (7.7)<br />
hemos obt<strong>en</strong>ido dicha función:<br />
F ( t)<br />
= 1−<br />
e<br />
z<br />
−β<br />
t<br />
4<br />
∑<br />
n=<br />
0<br />
( t β )<br />
n!<br />
n<br />
w<br />
(7.11)<br />
Por tanto, la probabilidad de que el paquete k-ésimo se pierda<br />
puede repres<strong>en</strong>tarse finalm<strong>en</strong>te como:<br />
P<br />
T<br />
per − k<br />
=<br />
∫<br />
= 1 −<br />
Fz<br />
(( k − 1) T − e + W W wo)<br />
fw(<br />
wo)<br />
dwo (7.12)<br />
max[ −∆ho,<br />
e−(<br />
k −1)<br />
T ]<br />
7.2.2 Resultados<br />
Las sigui<strong>en</strong>tes gráficas muestran los resultados obt<strong>en</strong>idos a partir<br />
de (7.12). Así <strong>en</strong> la figura 7.2 observamos la probabilidad de pérdida de los<br />
paquetes que alcanzan el nodo de cruce tras el instante t1, cuando<br />
variamos el retardo de propagación <strong>en</strong>tre los distintos nodos. Para realizar<br />
esta gráfica se ha tomado constantes los sigui<strong>en</strong>tes valores: tasa de<br />
servicio µ = 10 paquetes por mseg., carga ρ = 0.8, tiempo de llegada de<br />
paquetes T = 20 mseg y un tiempo de detección del handover ∆ho = 100<br />
mseg. El valor del retardo <strong>en</strong>tre dos routers se ha tomado de 5, 10 y 20<br />
mseg.<br />
En la figura puede se muestra como, evid<strong>en</strong>tem<strong>en</strong>te, la<br />
probabilidad de pérdida disminuye a medida que aum<strong>en</strong>ta el número del<br />
paquete. Así el primer paquete se pierde con una probabilidad del 100% <strong>en</strong><br />
todos los casos, pero, <strong>en</strong> el caso de t<strong>en</strong>er un retardo de 5 mseg., el séptimo<br />
paquete siempre llegará al nodo móvil vía nBS.<br />
268
Evaluación analítica<br />
Figura 7.2 Probabilidad de pérdida del paquete k-ésimo.<br />
Figura 7.3 Probabilidad de pérdida del paquete k-ésimo.<br />
269
Evaluación analítica.<br />
En la figura 7.3 se muestra la probabilidad de pérdida cuando<br />
variamos el tiempo de llegada <strong>en</strong>tre paquetes. En este caso se ha tomado<br />
un retardo de 5 mseg. <strong>en</strong>tre nodos y para los restantes parámetros se han<br />
mant<strong>en</strong>ido los mismos valores que los utilizados para realizar la gráfica<br />
anterior.<br />
Se observa como la probabilidad de pérdida aum<strong>en</strong>ta de manera<br />
muy significativa al disminuir el tiempo <strong>en</strong>tre paquetes. Es decir,<br />
mant<strong>en</strong>i<strong>en</strong>do un tiempo de handover constante, cuantos más rápido se<br />
transmita, más paquetes están involucrados con una probabilidad de<br />
pérdida elevada.<br />
Podemos relacionar el comportami<strong>en</strong>to del esquema de handover <strong>en</strong><br />
función del tiempo <strong>en</strong>tre llegadas T y el retardo de los <strong>en</strong>laces. En la figura<br />
7.4 se muestra el número medio de paquetes perdidos <strong>en</strong> función de T<br />
para varios valores de retardo del <strong>en</strong>lace. Para obt<strong>en</strong>erla hemos partido de<br />
(7.12), que indicaba la probabilidad de la pérdida del paquete k-ésimo.<br />
Dicha pérdida implica la pérdida de los (k-1) paquetes anteriores. Por tanto<br />
la probabilidad de que se produzca la pérdida de exactam<strong>en</strong>te k paquetes<br />
se obti<strong>en</strong>e a partir de (7.13), y el número de medio de paquetes perdidos se<br />
calcula mediante (7.14).<br />
Q P 1 − P )<br />
(7.13)<br />
k = per k ( per k+<br />
1<br />
∑<br />
N = kQ k<br />
(7.14)<br />
k≥1<br />
270
Evaluación analítica<br />
Figura 7.4 Número medio de paquetes perdidos vs. retardo.<br />
Por último podríamos estudiar lo que sucedería si aum<strong>en</strong>táramos el<br />
tiempo <strong>en</strong> que el nodo móvil tarda <strong>en</strong> detectar que se ha producido un<br />
handover. En las gráficas anteriores se ha definido este tiempo como una<br />
distribución uniforme <strong>en</strong>tre 0 y 100 mseg. Hemos supuesto un valor<br />
m<strong>en</strong>or que el especificado <strong>en</strong> [RFC 3344], que sugería un valor de 1 seg. La<br />
razón de esto es simple. El protocolo Mobile IP está p<strong>en</strong>sado para macro<strong>movilidad</strong><br />
donde no se busca unas altas prestaciones <strong>en</strong> el handover.<br />
Sin embargo, con los sistemas de micro-<strong>movilidad</strong> se int<strong>en</strong>ta lograr,<br />
princ<strong>ip</strong>alm<strong>en</strong>te, bu<strong>en</strong>as prestaciones durante el handover. Así es necesario<br />
buscar soluciones para disminuir este tiempo, bi<strong>en</strong> utilizando ‘triggers’ o<br />
bi<strong>en</strong> transmiti<strong>en</strong>do los m<strong>en</strong>sajes de ‘Ag<strong>en</strong>t Advertisem<strong>en</strong>t’ con una<br />
frecu<strong>en</strong>cia elevada. En la gráfica 7.5 se muestra el comportami<strong>en</strong>to del<br />
esquema de handover cuando se varía el valor ∆ ho y se manti<strong>en</strong><strong>en</strong> los<br />
restantes parámetros con los valores sigui<strong>en</strong>tes: tasa de servicio µ = 10<br />
paquetes por mseg., carga ρ = 0.8, tiempo de llegada de paquetes T = 20<br />
mseg y retardo de 5 mseg. Evid<strong>en</strong>tem<strong>en</strong>te al aum<strong>en</strong>ta el tiempo de<br />
detección aum<strong>en</strong>ta el tiempo <strong>en</strong> el que el MN no ti<strong>en</strong>e cobertura de<br />
ninguna BS, aum<strong>en</strong>tando la probabilidad de perder paquetes.<br />
271
Evaluación analítica.<br />
Figura 7.5 Probabilidad de pérdida del paquete k-ésimo.<br />
7.3 ESQUEMA DE HANDOVER SEMI SUAVE<br />
En este punto se va a analizar el handover Semi Suave estudiado<br />
<strong>en</strong> el punto 6.4. En este esquema el nodo móvil es capaz de comunicarse<br />
simultáneam<strong>en</strong>te con dos estaciones base. Así, mi<strong>en</strong>tras se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong><br />
la zona de solape de las coberturas de las dos estaciones, el nodo móvil se<br />
comunica con nBS, indicándole que se conecte al árbol <strong>multicast</strong>.<br />
A difer<strong>en</strong>cia del esquema anterior, <strong>en</strong> esta solución los paquetes,<br />
además de perderse, pued<strong>en</strong> llegar al nodo móvil duplicados. Es necesario,<br />
por tanto, realizar el análisis separado de estas dos circunstancias.<br />
Basándose <strong>en</strong> la capacidad de comunicación simultánea del nodo<br />
móvil, éste podría comportarse de dos maneras difer<strong>en</strong>tes. La primera<br />
sería aceptar todos los paquetes que se recib<strong>en</strong> de ambas estaciones base<br />
mi<strong>en</strong>tras se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona de solape. Bajo esta situación es<br />
previsible que una zona de solape sufici<strong>en</strong>tem<strong>en</strong>te grande permitirá que la<br />
272
Evaluación analítica<br />
perdida de paquetes sea mínima, aunque se producirá una elevada<br />
duplicación de paquetes.<br />
El segundo modo de operación sería el detallado <strong>en</strong> el punto 6.4, <strong>en</strong><br />
el que el nodo móvil, tras recibir el m<strong>en</strong>saje ‘Intra-Domain Registration<br />
Reply’, supone la finalización del proceso de handover, <strong>en</strong>viando un<br />
m<strong>en</strong>saje ‘Multicat Prune Request’ a oBS y desechando cualquier paquete<br />
posterior de esta estación base.<br />
Para realizar la evaluación analítica de este esquema se va a partir,<br />
como <strong>en</strong> el caso anterior, de la figura 7.1a. Igualm<strong>en</strong>te vamos a optar por<br />
modelar los routers como colas M/M/1. Por tanto asumimos que el tiempo<br />
de servicio de un paquete <strong>en</strong> un router está distribuido expon<strong>en</strong>cialm<strong>en</strong>te,<br />
con la tasa de servicio µ y carga ρ.<br />
7.3.1 Pérdida de paquetes del handover sin desconexión de oBS<br />
Como se ha com<strong>en</strong>tado anteriorm<strong>en</strong>te, un posible modo de<br />
funcionami<strong>en</strong>to permite que el nodo móvil sigua recibi<strong>en</strong>do paquetes de<br />
oBS mi<strong>en</strong>tras permanece <strong>en</strong> la zona de solape. Idealm<strong>en</strong>te el handover se<br />
completa antes de que el MN pierda cobertura de la estación base antigua<br />
y, por tanto, no se debe perder ningún paquete.<br />
A pesar de que <strong>en</strong> situaciones normales esta solución no pierde<br />
ningún paquete, circunstancias excepcionales, como una zona de solape<br />
mínima, pued<strong>en</strong> provocar una cierta probabilidad de pérdida. A<br />
continuación vamos a estudiar esta posible situación.<br />
7.3.1.1 Desarrollo analítico<br />
En este esquema para que un paquete dirigido al nodo móvil se<br />
pierda, debido al mecanismo de handover, deb<strong>en</strong> cumplirse las dos<br />
propiedades sigui<strong>en</strong>tes:<br />
273
Evaluación analítica.<br />
1. El paquete se transmite desde el oBS <strong>en</strong> un instante de tiempo<br />
posterior al instante de tiempo <strong>en</strong> el que el MN ha abandonado la<br />
zona de cobertura.<br />
2. El paquete alcanza el nodo de cruce antes de que lo haga el<br />
m<strong>en</strong>saje ‘Join’ prov<strong>en</strong>i<strong>en</strong>te de nBS (ver figura 6.4).<br />
Con respecto a la primera condición necesaria para la pérdida de<br />
un paquete, definimos t 1<br />
como el instante de tiempo a partir del cual los<br />
paquetes que alcanc<strong>en</strong> el nodo de cruce nunca llegarán al nodo móvil vía<br />
oBS. El motivo de esto será que oBS transmitirá estos paquetes<br />
posteriorm<strong>en</strong>te al abandono la zona de cobertura por parte del nodo móvil.<br />
[ CN + CN,<br />
R ) + R + ( R , oBS oBS]<br />
t1 = t AB − ( 1 1 1 ) +<br />
(7.15)<br />
Es evid<strong>en</strong>te la analogía <strong>en</strong>tre (7.15) y la ecuación (7.1) del esquema<br />
de handover abrupto. La única difer<strong>en</strong>cia es que <strong>en</strong> este caso trabajamos<br />
con t AB , definido como el tiempo <strong>en</strong> el que el nodo móvil abandona la zona<br />
de cobertura de oBS. A su vez éste tiempo de abandono podemos escribirlo<br />
<strong>en</strong> función del tiempo <strong>en</strong> el que el nodo móvil atraviesa el punto medio de<br />
la zona de solape t m , y del tiempo que necesita <strong>en</strong> atravesar dicha zona σ.<br />
σ<br />
t AB = t m +<br />
(7.16)<br />
2<br />
Simplificando (7.15) t<strong>en</strong>dríamos:<br />
[ X c]<br />
t1 = t AB − +<br />
(7.17)<br />
si<strong>en</strong>do<br />
c = ( CN,<br />
R1 ) + ( R1<br />
, oBS)<br />
X = v.a con fdd:<br />
f<br />
X<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
Con respecto a la segunda condición, ésta también se daba <strong>en</strong> el<br />
handover abrupto (punto 7.2). Definimos t 2 como el instante de tiempo <strong>en</strong><br />
274
Evaluación analítica<br />
el que el nodo de cruce recibe, vía nBS, la información de que se ha<br />
producido un handover.<br />
t2 = tm + ∆h<br />
+ nBS + ( nBS,<br />
R2<br />
) + R2<br />
+ ( R2,<br />
CN)<br />
(7.18)<br />
En la ecuación anterior ∆ h se corresponde con el tiempo, tras el<br />
instante t m , que le cuesta al nodo móvil detectar que debe pasar a<br />
dep<strong>en</strong>der de nBS. Simplificado la ecuación, como ya se ha realizado<br />
anteriorm<strong>en</strong>te, queda:<br />
t2 = tm + ∆h<br />
+ Y + d<br />
(7.19)<br />
con<br />
d = ( nBS,<br />
R2 ) + ( R2<br />
, CN)<br />
Y = v.a con fdd:<br />
f<br />
Y<br />
2<br />
−β<br />
t<br />
( t)<br />
= β te para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
Suponi<strong>en</strong>do que al nodo de cruce le llegan paquetes con un tiempo<br />
<strong>en</strong>tre llegadas fijo de valor T, podemos calcular la probabilidad de que un<br />
paquete se pierda a partir de la ecuación (7.20).<br />
P<br />
[ < ( k −1<br />
T + u t ]<br />
per − k = Pr ob t1 ) < 2<br />
(7.20)<br />
Idealm<strong>en</strong>te t 2 < t1<br />
y, por tanto, cuando el nodo móvil abandona la<br />
zona de cobertura ya ha recibido todos los paquetes previos al primero que<br />
va a recibir nBS. En este caso la probabilidad de pérdida del paquete será<br />
nula.<br />
Sin embargo, podemos trabajar con la ecuación (7.20) para estudiar<br />
el comportami<strong>en</strong>to del esquema de handover <strong>en</strong> circunstancias extremas,<br />
como cuando la zona de cobertura de las dos estaciones base es muy<br />
pequeña.<br />
Se puede observar que esta expresión es exactam<strong>en</strong>te la empleada<br />
<strong>en</strong> el punto anterior (ecuación (7.8)). La única difer<strong>en</strong>cia es que el instante<br />
275
Evaluación analítica.<br />
t 1 incorpora ahora el término σ/2. Sin embargo, podemos simplificar<br />
suponi<strong>en</strong>do este valor constante, e introduciéndolo <strong>en</strong> la constante ‘c’. Así<br />
el desarrollo matemático será idéntico al ya realizado, con una solución<br />
igual a la <strong>en</strong>contrada <strong>en</strong>tonces (7.12).<br />
P<br />
T<br />
per − k<br />
=<br />
∫<br />
= 1 −<br />
Fz<br />
(( k −1)<br />
T − e + W W wo)<br />
f w ( wo)<br />
dwo (7.21)<br />
max[ −∆ho,<br />
e−(<br />
k−1)<br />
T ]<br />
La única difer<strong>en</strong>cia que existe es respecto a la constante ‘e’. En este<br />
caso el parámetro incluye, además de los retardos de los <strong>en</strong>laces, el tiempo<br />
que le cuesta al MN salir de la zona de solape tras el instante t m<br />
:<br />
σ<br />
e = ( CN,<br />
R1<br />
) + ( R1<br />
, oBS)<br />
+ ( nBS,<br />
R2<br />
) + ( R2<br />
, CN)<br />
−<br />
(7.22)<br />
2<br />
7.3.1.2 Resultados<br />
En la figura 7.6 se muestra el comportami<strong>en</strong>to del handover Semi<br />
Suave <strong>en</strong> función del tiempo que tarda el nodo móvil <strong>en</strong> atravesar la zona<br />
de solape <strong>en</strong>tre las dos estaciones base, σ. Para realizar esta gráfica se ha<br />
tomado constantes los sigui<strong>en</strong>tes valores: tasa de servicio µ = 10 paquetes<br />
por mseg., tiempo de llegada de paquetes T = 5 mseg, tiempo de detección<br />
del handover ∆ ho = 50 mseg, y un retardo <strong>en</strong>tre dos routers de 5 mseg. El<br />
valor de la carga de los dispositivos de interconexión modelados ρ se ha<br />
tomado de 0.8 y 0.95.<br />
En la figura puede observarse que el esquema de handover<br />
funciona perfectam<strong>en</strong>te a no ser que los sometamos a condiciones<br />
excepcionales. Así, con un tiempo <strong>en</strong> la zona de cobertura de 180 mseg. no<br />
se pierde ningún paquete. Un valor σ de 180 mseg. es un tiempo muy<br />
pequeño. Por ejemplo si un nodo móvil se mueve a una velocidad de 20<br />
m/seg (72Km/h), 180 mseg. equivale a t<strong>en</strong>er un área de cobertura de tan<br />
solo 3.6 metros.<br />
En la figura también se puede apreciar como las prestaciones<br />
empeoran al cargar más los dispositivos de interconexión. Al aum<strong>en</strong>tar el<br />
parámetro ρ aum<strong>en</strong>ta el tiempo de espera <strong>en</strong> colas y por tanto aum<strong>en</strong>ta la<br />
276
Evaluación analítica<br />
probabilidad de que un paquete se transmita cuando el nodo móvil ya<br />
haya abandonado la zona de cobertura.<br />
Hay que indicar que el valor de ρ corresponde a la carga total del<br />
dispositivo, y no a la carga g<strong>en</strong>erada por la comunicación con el nodo<br />
móvil estudiado. Por tanto, la carga del dispositivo no varía aunque se<br />
disminuya considerablem<strong>en</strong>te el tiempo <strong>en</strong>tre llegadas de los paquetes<br />
dirigidos al móvil T.<br />
Figura 7.6 Paquetes perdidos vs. tiempo <strong>en</strong> la zona de cobertura σ.<br />
En la figura 7.7 se muestra el comportami<strong>en</strong>to del handover <strong>en</strong> el<br />
caso de disminuir T hasta un valor de 1 mseg., mant<strong>en</strong>i<strong>en</strong>do constantes<br />
los restantes valores de la simulación anterior. Podemos observar como el<br />
tamaño de la zona necesario para que no se pierdan paquetes no ha<br />
variado. Evid<strong>en</strong>tem<strong>en</strong>te <strong>en</strong> caso de t<strong>en</strong>er una zona de cobertura mínima se<br />
ti<strong>en</strong>e una media de paquetes perdidos mayor, pues para un tiempo dado<br />
de disrupción se transmit<strong>en</strong> (pierd<strong>en</strong>) más paquetes.<br />
277
Evaluación analítica.<br />
Figura 7.7 Paquetes perdidos vs. tiempo <strong>en</strong> la zona de cobertura σ. T=1mseg.<br />
7.3.2 Pérdida de paquetes con desconexión de oBS<br />
Existe una segunda solución a la hora de implem<strong>en</strong>tar el esquema<br />
de handover Semi Suave. En el capítulo 6.4 se explicó como <strong>en</strong> nodo móvil,<br />
tras recibir el m<strong>en</strong>saje ‘Intra-Domain Registration Reply’, supone la<br />
finalización del proceso de handover, <strong>en</strong>viando un m<strong>en</strong>saje ‘Multicat Prune<br />
Request’ a oBS.<br />
Vamos a realizar un estudio de paquetes perdidos suponi<strong>en</strong>do<br />
ahora que el nodo móvil descarta todos los paquetes recibidos desde oBS<br />
tras la recepción del m<strong>en</strong>saje ‘Intra-Domain Registration Reply’. Esta idea<br />
puede parecer, <strong>en</strong> un princ<strong>ip</strong>io, m<strong>en</strong>os efici<strong>en</strong>te que la anterior, pues se<br />
están descartando paquetes recibidos <strong>en</strong> la zona de solape.<br />
Sin embargo, para estudiar las prestaciones de un esquema de<br />
handover se ha que t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta la suma de diversos parámetros. Así, y<br />
278
Evaluación analítica<br />
como se verá <strong>en</strong> el sigui<strong>en</strong>te punto, la aceptación por parte del MN de<br />
todos los paquetes prov<strong>en</strong>i<strong>en</strong>tes de oBS mi<strong>en</strong>tras éste permanece d<strong>en</strong>tro<br />
de la zona de solape provoca multitud de paquetes duplicados.<br />
7.3.2.1 Desarrollo analítico<br />
Para realizar este análisis partimos de los cálculos realizados a<br />
princ<strong>ip</strong>io de este punto. Definimos t 3 como el instante de tiempo <strong>en</strong> el que<br />
el nodo móvil recibe el m<strong>en</strong>saje ‘Intra-Domain Registration Reply’ desde<br />
nBS.<br />
t = t + CN + CN,<br />
R ) + R + ( R , nBS)<br />
+ nBS =<br />
3<br />
2<br />
( 2 2 2<br />
= t + Y ' + '<br />
(7.23)<br />
2 d<br />
si<strong>en</strong>do:<br />
d ' = ( CN,<br />
R2 ) + ( R2<br />
, nBS)<br />
Y’ = v.a. con fdd:<br />
f<br />
Y '<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
Podemos calcular el instante de tiempo a partir del cual los<br />
paquetes que alcanc<strong>en</strong> el nodo de cruce llegarán al nodo móvil, vía oBS,<br />
más tarde del instante t 3 :<br />
[ CN + CN,<br />
R ) + R + ( R , oBS oBS]<br />
t = t −<br />
) +<br />
4<br />
3<br />
[ X ' ']<br />
4 t3<br />
− c<br />
( 1 1 1<br />
t = +<br />
(7.24)<br />
si<strong>en</strong>do:<br />
c ' = ( CN,<br />
R1 ) + ( R1<br />
, oBS)<br />
X’ = v.a con fdd:<br />
f<br />
X '<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
279
Evaluación analítica.<br />
Para estudiar la pérdida de paquetes que ocasiona este modo de<br />
funcionami<strong>en</strong>to hay que suponer, evid<strong>en</strong>tem<strong>en</strong>te, que la zona de cobertura<br />
es lo sufici<strong>en</strong>tem<strong>en</strong>te grande como para que el proceso de handover se<br />
pueda realizar correctam<strong>en</strong>te. En otras palabras, suponemos que cuando<br />
el nodo móvil recibe el m<strong>en</strong>saje ‘Intra-Domain Registration Reply’ aún se<br />
<strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona de solape y que, por tanto, todavía no se ha perdido<br />
ningún paquete. Como se comprobó <strong>en</strong> la figura 7.6 esta suposición se<br />
cumple <strong>en</strong> cuanto la zona de solape ti<strong>en</strong>e una dim<strong>en</strong>sión mínimam<strong>en</strong>te<br />
aceptable.<br />
Los paquetes perdidos serán aquellos que son descartados por el<br />
MN por haber dado la comunicación con oBS por finalizada, pero que no<br />
se han transmitido hacia nBS. Es decir los que llegan al CN después del<br />
instante t 4 pero antes de t 2 .<br />
P<br />
[ < ( k −1<br />
T + u t ]<br />
per − k = Pr ob t4 ) < 2<br />
(7.25)<br />
Como <strong>en</strong> cálculos anteriores normalizamos con uno de los tiempos<br />
implicados <strong>en</strong> el análisis. En este caso igualamos t 4 =0, de manera que el<br />
primer paquete susceptible de pérdida será el que llega <strong>en</strong> el instante u.<br />
[ X + c'<br />
] = t + Y ' + d'<br />
−[ X ' + '] 0<br />
t = t<br />
c ⇒ t = X ' −Y<br />
' + c'<br />
− '<br />
(7.26)<br />
4 3 − ' 2<br />
=<br />
P<br />
[ 0 < ( k −1)<br />
T + u < X ' −Y<br />
' e'<br />
]<br />
2 d<br />
− k = Pr ob<br />
(7.27)<br />
per +<br />
Para aligerar este punto, la ecuación (7.27) está desarrollada <strong>en</strong> el<br />
Anexo 2.1. La expresión final obt<strong>en</strong>ida es la sigui<strong>en</strong>te:<br />
P<br />
1<br />
T<br />
T<br />
∫ ∫<br />
∞<br />
[ F ( z'<br />
−u<br />
x )]<br />
per− k =<br />
y o +<br />
0 max(0,uo<br />
-z')<br />
o<br />
β<br />
3 2<br />
xo<br />
2<br />
e<br />
−β<br />
xo<br />
dx<br />
o<br />
du<br />
o<br />
(7.28)<br />
si<strong>en</strong>do<br />
z = e'<br />
−(<br />
k −1)<br />
T = ( CN,<br />
R ) + ( R , oBS)<br />
− ( CN,<br />
R ) − ( R , nBS)<br />
− ( k 1)<br />
T<br />
' 1 1<br />
2 2 −<br />
280
Evaluación analítica<br />
7.3.2.2 Resultados<br />
La figura 7.8 muestra el comportami<strong>en</strong>to del esquema cuando los<br />
caminos desde el nodo de cruce a las dos estaciones base ti<strong>en</strong><strong>en</strong> el mismo<br />
retardo. Así la constante e’ ti<strong>en</strong>e un valor cero. Los parámetros que defin<strong>en</strong><br />
los routers se han tomado los mismos que los utilizados <strong>en</strong> gráficas<br />
anteriores, es decir, tasa de servicio µ = 10 paquetes por mseg. y carga ρ =<br />
0.8<br />
Figura 7.8 Probabilidad de pérdida del paquete k-ésimo con e’= 0.<br />
La gráfica muestra la probabilidad de que el paquete k-ésimo se<br />
pierda <strong>en</strong> función del tiempo <strong>en</strong>tre llegadas T. Hay que indicar que el<br />
paquete k = 1 es primero susceptible de perderse, pues es el primero que<br />
llegaría al nodo móvil, vía oBS, posterior a la recepción del m<strong>en</strong>saje ‘Intra-<br />
Domain Registration Reply’. Podemos observar como dicha probabilidad<br />
disminuye rápidam<strong>en</strong>te de manera que <strong>en</strong> todos los casos la probabilidad<br />
de que el segundo paquete se pierda es nula.<br />
En el capítulo 6.4.1 se planteó las limitaciones de este esquema. En<br />
particular se estudió como difer<strong>en</strong>cias <strong>en</strong>tre las cargas de los router que<br />
281
Evaluación analítica.<br />
forman las dos rutas (CN-oBS y CN-nBS), o bi<strong>en</strong> difer<strong>en</strong>cias <strong>en</strong> el retardo<br />
de estas rutas, podían ocasionar una pérdida de paquetes elevada (figura<br />
6.6).<br />
A continuación vamos a estudiar esta situación haci<strong>en</strong>do el retardo<br />
<strong>en</strong>tre la estación base antigua y el nodo de cruce y s<strong>en</strong>siblem<strong>en</strong>te superior<br />
al exist<strong>en</strong>te <strong>en</strong>tre este último y la nueva Estación Base. La figura 7.9<br />
muestra el número medio de paquetes que se pierd<strong>en</strong> <strong>en</strong> función de esta<br />
difer<strong>en</strong>cia <strong>en</strong> mseg. Valores positivos indican que el retardo de la ruta<br />
antigua es superior al de la nueva ruta. Como se puede observar esta<br />
difer<strong>en</strong>cia se corresponde exactam<strong>en</strong>te con el valor e’ de la ecuación (7.28).<br />
Los restantes valores se han mant<strong>en</strong>ido constantes: tasa de servicio<br />
µ = 10 paquetes por mseg., carga ρ = 0.8, y tiempo medio <strong>en</strong>tre paquetes<br />
<strong>en</strong> CN, T = 10 mseg. El número medio de paquetes perdidos se ha obt<strong>en</strong>ido<br />
como se explicó <strong>en</strong> la figura 7.4.<br />
Figura 7.9 Paquetes perdidos <strong>en</strong> función de la difer<strong>en</strong>cia de retardos de las rutas<br />
CNoBS y CNnBS.<br />
282
Evaluación analítica<br />
La gráfica muestra como aum<strong>en</strong>ta de forma lineal el número de<br />
paquetes perdidos <strong>en</strong> función de la difer<strong>en</strong>cia de retardo. Como se estudió<br />
<strong>en</strong> el punto 6.4, un retardo CN-oBS elevado, <strong>en</strong> comparación con el retardo<br />
de la ruta CN-nBS, se traduce <strong>en</strong> que muchos paquetes que han sido<br />
<strong>en</strong>viados por CN hacia oBS se <strong>en</strong>cu<strong>en</strong>tran todavía <strong>en</strong> tránsito cuando se<br />
produce el handover.<br />
Cuando el paquete ‘Join’ llega a CN indicando que nBS se ha<br />
conectado al árbol <strong>multicast</strong> estos paquetes ya han sido transmitidos a<br />
oBS y, por tanto, nunca se transmitirán a nBS. Debido al elevado retardo,<br />
los paquetes no alcanzan oBS antes de que el móvil reciba confirmación de<br />
nBS indicando la conexión al árbol (m<strong>en</strong>saje ‘Intra-Domain Registration<br />
Reply’). Recordemos que éste es el instante <strong>en</strong> el que el nodo móvil se<br />
desvincula de oBS y deja de aceptar paquetes que el oBS <strong>en</strong>vía.<br />
Podemos comparar este esquema con la solución <strong>en</strong> la cual se<br />
aceptan todos los paquetes que se recib<strong>en</strong> de ambas estaciones mi<strong>en</strong>tras el<br />
nodo móvil se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona de solape. Como se vio <strong>en</strong> la figura 7.6,<br />
el número de paquetes perdidos dep<strong>en</strong>día, fundam<strong>en</strong>talm<strong>en</strong>te, del tamaño<br />
de la zona de solape, y para zonas de tamaño lógico no se perdía ningún<br />
paquete.<br />
Ahora el tamaño de la zona es no se ha t<strong>en</strong>ido <strong>en</strong> cu<strong>en</strong>ta, pues se<br />
ha supuesto que es lo sufici<strong>en</strong>tem<strong>en</strong>te grande, y la cantidad de paquetes<br />
perdidos dep<strong>en</strong>de de la difer<strong>en</strong>cia de las rutas <strong>en</strong>tre el nodo de cruce y las<br />
estaciones base. Cuando el <strong>en</strong>lace con oBS es más l<strong>en</strong>to el esquema Semi<br />
Suave propuesto <strong>en</strong> este punto no funciona correctam<strong>en</strong>te. Por el<br />
contrario, la solución funciona perfectam<strong>en</strong>te <strong>en</strong> el caso de que la ruta<br />
más l<strong>en</strong>ta fuera la que une CN con nBS. Esto puede observarse mirando la<br />
zona de la gráfica 7.9 donde la difer<strong>en</strong>cia de retardos es negativa.<br />
Para finalizar se estudia el comportami<strong>en</strong>to del esquema cuando<br />
modificamos la carga de los routers que forman las dos rutas, y que hasta<br />
ahora habíamos tomado como un valor constante ρ = 0.8. A partir de la<br />
ecuación (7.28) hemos distinguido el valor de β que prov<strong>en</strong>ía de la función<br />
283
Evaluación analítica.<br />
fdd ( ) , que equivalía a los routers de la ruta CNoBS, del valor β de los<br />
f X ' t<br />
routers que compon<strong>en</strong> la ruta hacia nBS.<br />
La figura 7.10 muestra el número medio de paquetes perdidos al<br />
mant<strong>en</strong>er la carga de los routers del <strong>en</strong>lace CNnBS con valor ρ = 0.8 y<br />
variar la carga del <strong>en</strong>lace CNoBS <strong>en</strong>tre 0.75 y 0.95. El resto de<br />
parámetros se manti<strong>en</strong><strong>en</strong> constante: tasa de servicio µ = 10 paquetes por<br />
mseg., tiempo medio <strong>en</strong>tre paquetes <strong>en</strong> CN de 10 mseg. y la constante e’<br />
con valor cero.<br />
En la figura se observa que el número de paquetes perdidos<br />
aum<strong>en</strong>ta al aum<strong>en</strong>tar la carga de los routers del <strong>en</strong>lace con oBS. Como se<br />
explicó <strong>en</strong> el tema anterior, esto es debido a que al aum<strong>en</strong>tar la carga<br />
aum<strong>en</strong>ta el tiempo <strong>en</strong> cola de los paquetes que viajan por esta ruta, y es<br />
más probable que los paquetes se transmitan hacia el MN cuando éste ya<br />
se ha desconectado de la estación base, por lo que se perderán.<br />
Figura 7.10 Número medio de paquetes perdidos <strong>en</strong> función de la carga de los<br />
routers de la ruta CN-oBS.<br />
284
Evaluación analítica<br />
También es interesante observar que el número de paquetes<br />
perdidos no es muy significativo, a no ser que la carga de los router<br />
aum<strong>en</strong>te hasta valores de congestión. Así, <strong>en</strong> comparación a los 0.4-0.5<br />
paquetes que se pued<strong>en</strong> llegar a perder cuando aum<strong>en</strong>temos la carga, la<br />
figura 7.9 mostraba que para valores razonables de e’, <strong>en</strong> torno a los 10-20<br />
mseg., se perdían 1 o 2 paquetes.<br />
7.3.3 Paquetes duplicados sin desconexión de oBS<br />
Como se estudió <strong>en</strong> el punto 6.4, el esquema de handover Semi<br />
Suave se basa <strong>en</strong> que el nodo móvil es capaz de recibir paquetes de las dos<br />
estaciones base mi<strong>en</strong>tras se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona de solape.<br />
Si el MN acepta todos los paquetes que recibe de las dos estaciones<br />
base, una zona de solape grande ocasionará, inevitablem<strong>en</strong>te, la recepción<br />
de paquetes duplicados. A continuación vamos a estudiar esta limitación<br />
del esquema de handover.<br />
7.3.3.1 Desarrollo analítico<br />
Los paquetes duplicados serán aquellos que son transmitidos por el<br />
CN <strong>en</strong> un instante posterior a la recepción del m<strong>en</strong>saje ‘Join’ (instante <strong>en</strong> el<br />
que nBS queda conectada al árbol <strong>multicast</strong>), y que son recibidos por el<br />
nodo móvil, vía oBS, antes de abandonar la zona de cobertura. Es decir,<br />
utilizando los tiempos definidos <strong>en</strong> 7.3.1, los paquetes duplicados son<br />
aquellos que alcanzan CN <strong>en</strong> un instante de tiempo t que cumple:<br />
t < t < .<br />
2 t 1<br />
Como <strong>en</strong> los estudios anteriores suponemos que los paquetes llegan<br />
con un tiempo <strong>en</strong>tre llegadas fijo de valor T. Por tanto los paquetes llegan a<br />
CN <strong>en</strong> los instantes (k-1)T+u, si<strong>en</strong>do u un valor aleatorio uniformem<strong>en</strong>te<br />
distribuido <strong>en</strong>tre [0,T]. Tomamos como inicio temporal el instante <strong>en</strong> que el<br />
m<strong>en</strong>saje ‘Join’ alcanza el nodo de cruce, t 2 = 0 . Así el primer paquete que<br />
285
Evaluación analítica.<br />
alcanza CN susceptible de ser recibido por duplicado será aquel con valor<br />
k = 1.<br />
duplicado<br />
P<br />
La probabilidad de que el paquete k-ésimo llegue al nodo móvil por<br />
P − es por tanto:<br />
dup<br />
k<br />
[ < ( k −1<br />
T + u t ]<br />
dup − k = Pr ob t2 ) < 1<br />
(7.29)<br />
Igualamos a cero la expresión (7.19) y sustituimos <strong>en</strong> (7.17).<br />
t2 = tm + ∆h<br />
+ Y + d = 0 ⇒ t m = −∆h<br />
− Y − d<br />
t<br />
1<br />
σ<br />
= −∆h<br />
− Y − d + − X − c<br />
2<br />
La probabilidad de recibir el paquete k-ésimo por duplicado es <strong>en</strong>tonces:<br />
P<br />
dup−k<br />
⎡<br />
σ ⎤<br />
= Pr ob⎢0<br />
< ( k −1)<br />
T + u < −∆h<br />
− Y − d + − X − c⎥<br />
⎣<br />
2 ⎦<br />
(7.30)<br />
Para simplificar la expresión anterior definimos una nueva variable<br />
aleatoria Q como suma de las variables aleatorias indep<strong>en</strong>di<strong>en</strong>tes u y ∆ h .<br />
En el caso de T < ∆ho<br />
esta nueva v.a. ti<strong>en</strong>e la función de d<strong>en</strong>sidad de<br />
distribución sigui<strong>en</strong>te:<br />
f Q<br />
⎧ 1 T∆ho<br />
⎪<br />
1 ∆ho<br />
( t)<br />
= ⎨<br />
⎪(<br />
− t + ∆ho<br />
+ T )<br />
⎪<br />
⎩ 0<br />
T∆ho<br />
0 < t < T<br />
T ≤ t ≤ ∆ho<br />
∆ho<br />
< t < ∆ho<br />
+ T<br />
resto<br />
(7.31)<br />
Igualm<strong>en</strong>te podemos definir la variable aleatoria Z que ya se ha<br />
utilizado <strong>en</strong> desarrollos anteriores, Z = X + Y , que ti<strong>en</strong>e la función de<br />
d<strong>en</strong>sidad de distribución calculada <strong>en</strong> (7.7). Finalm<strong>en</strong>te definimos una<br />
nueva constante e = σ − c − d . Así la ecuación (7.30) queda:<br />
2<br />
P<br />
dup<br />
[ Z ≤ e − ( k −1<br />
T − Q]<br />
− k = Pr ob<br />
)<br />
(7.32)<br />
286
Evaluación analítica<br />
Podemos rescribir esta ecuación de la sigui<strong>en</strong>te manera:<br />
P<br />
[ Z ≤ e − ( k −1)<br />
T − Q Q q]<br />
∆ho+<br />
T<br />
dup− k =<br />
∫<br />
=<br />
0<br />
Prob f ( q)<br />
dq<br />
(7.33)<br />
Por último utilizando la función de distribución F Z (t)<br />
, t<strong>en</strong>emos:<br />
P<br />
∆ho+<br />
T<br />
dup− k =<br />
∫<br />
Fz<br />
Z ≤ e − ( k −1)<br />
T − Q Q =<br />
0<br />
Q<br />
Q<br />
( q)<br />
f ( q)<br />
dq<br />
(7.34)<br />
7.3.3.2 Resultados<br />
La figura (7.11) muestra el número de paquetes duplicados que<br />
provoca el esquema de handover Semi Suave <strong>en</strong> función del tiempo σ que<br />
tarda el MN <strong>en</strong> atravesar la zona de solape. Como <strong>en</strong> gráficas anteriores se<br />
han tomado constantes los sigui<strong>en</strong>tes valores: tasa de servicio µ = 10<br />
paquetes por mseg., tiempo de llegada de paquetes T = 10 mseg., tiempo<br />
de detección del handover ∆ ho = 50 mseg, y un retardo <strong>en</strong>tre dos routers<br />
cualquiera de 5 mseg. El valor de la carga de los dispositivos de<br />
interconexión modelados ρ se ha tomado de 0.8.<br />
Se observa como el número medio de paquetes duplicados aum<strong>en</strong>ta<br />
con el tamaño de la zona de solape. Por ejemplo, con una velocidad de<br />
desplazami<strong>en</strong>to del MN de 20m/seg., una zona de solape de 20 metros<br />
produciría más de 130 paquetes duplicados.<br />
El número de paquetes duplicado dep<strong>en</strong>de de la tasa T a la que se<br />
recib<strong>en</strong> <strong>en</strong> el nodo de cruce. Es evid<strong>en</strong>te p<strong>en</strong>sar que al disminuir esta tasa<br />
aum<strong>en</strong>taría el número de duplicaciones.<br />
Sin embargo, más interesante que conocer valores exactos es<br />
comprobar como el mecanismo de handover Semi Suave necesita limitar la<br />
aceptación de paquetes de las dos estaciones base mi<strong>en</strong>tras el nodo se<br />
<strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona de cobertura.<br />
287
Evaluación analítica.<br />
Figura 7.11 número medio de paquetes duplicados.<br />
7.3.4 Paquetes duplicados con desconexión de oBS<br />
Como se com<strong>en</strong>tó anteriorm<strong>en</strong>te existe una segunda solución a la<br />
hora de implem<strong>en</strong>tar el esquema de handover Semi Suave. La solución<br />
consiste <strong>en</strong> que el MN, tras recibir el m<strong>en</strong>saje ‘Intra-Domain Registration<br />
Reply’, supone la finalización del proceso de handover, <strong>en</strong>viando un<br />
m<strong>en</strong>saje ‘Multicat Prune Request’ a oBS, y no aceptando más paquetes de<br />
esta estación base.<br />
En esta situación la recepción de paquetes duplicados será m<strong>en</strong>os<br />
probable aunque no imposible. Así, si el retardo <strong>en</strong>tre el nodo de cruce y la<br />
estación base antigua CNoBS es s<strong>en</strong>siblem<strong>en</strong>te inferior al retardo<br />
CNnBS, o bi<strong>en</strong> si exist<strong>en</strong> difer<strong>en</strong>cias <strong>en</strong> cuanto a la carga que soportan<br />
los routers de las dos rutas, también será posible la recepción de paquetes<br />
duplicados.<br />
288
Evaluación analítica<br />
Vamos a realizar una evaluación de paquetes duplicados,<br />
suponi<strong>en</strong>do que el nodo móvil descarta todos los paquetes recibidos desde<br />
oBS tras la recepción del m<strong>en</strong>saje ‘Intra-Domain Registration Reply’.<br />
7.3.4.1 Desarrollo analítico<br />
En la situación actual los paquetes duplicados serán aquellos que<br />
se recib<strong>en</strong> <strong>en</strong> el nodo de cruce después de haber recibido el m<strong>en</strong>saje ‘Join’,<br />
y que son recibidos por el nodo móvil, vía oBS, antes de que éste reciba el<br />
m<strong>en</strong>saje ‘Intra-Domain Registration Reply’.<br />
Parti<strong>en</strong>do de los cálculos realizados anteriorm<strong>en</strong>te podemos indicar<br />
que los paquetes duplicados son aquellos que alcanzan CN <strong>en</strong> un instante<br />
de tiempo t que cumple: t 2 < t < t4<br />
. La probabilidad de que el paquete k-<br />
ésimo llegue duplicado es, por tanto:<br />
P<br />
[ < ( k −1<br />
T + u t ]<br />
dup − k = Pr ob t2 ) < 4<br />
(7.35)<br />
Igualamos t 2 = 0, de manera que ahora el primer paquete que<br />
puede llegar duplicado sea k = 1, que alcanza CN <strong>en</strong> el instante u.<br />
Simplificando como se ha realizado <strong>en</strong> desarrollos anteriores, <strong>en</strong> particular<br />
utilizando las ecuaciones (7.23) y (7.24), la ecuación (7.35) nos queda:<br />
[ 0 < ( k −1)<br />
T + u < Y ' −X<br />
' −c'<br />
d'<br />
]<br />
Pdup − k = Pr ob<br />
+<br />
(7.36)<br />
Podemos observar como esta ecuación es casi idéntica a la obt<strong>en</strong>ida<br />
para el número de paquetes perdidos <strong>en</strong> este mismo esquema, ecuación<br />
(7.27). Únicam<strong>en</strong>te los signos de las variables aleatorias Y’ y X’ están<br />
cambiados, de la misma manera que ahora a la constante la llamaríamos<br />
e’’ y sería igual a e’’= d’-c’=-e’.<br />
Por tanto, el desarrollo matemático es el mismo que el que se<br />
realizó con anterioridad (ver 2.1), y la expresión final será:<br />
289
Evaluación analítica.<br />
P<br />
1<br />
T<br />
T<br />
∫ ∫<br />
∞<br />
[ F ( z'<br />
−u<br />
y )]<br />
dup− k =<br />
x o +<br />
si<strong>en</strong>do<br />
0 max(0,uo<br />
-z')<br />
o<br />
3<br />
β y<br />
2<br />
2<br />
o<br />
e<br />
−β<br />
yo<br />
dy<br />
o<br />
du<br />
o<br />
(7.37)<br />
z = e''<br />
−(<br />
k −1)<br />
T = ( CN,<br />
R ) + ( R , nBS)<br />
− ( CN,<br />
R ) − ( R , oBS)<br />
− ( k 1)<br />
T<br />
' 2 2<br />
1 1 −<br />
7.3.4.2 Resultados<br />
La figura 7.12 muestra el número de paquetes duplicados al aplicar<br />
las mismas condiciones que <strong>en</strong> los estudios anteriores: tasa de servicio µ =<br />
10 paquetes por mseg. y carga constante para todos los routers de la red<br />
de valor ρ = 0.8. El retardo de los caminos del nodo de cruce a las dos<br />
estaciones base es el mismo, de manera que e’’ = 0.<br />
Figura 7.12 Probabilidad de que el paquete k-ésimo llegue duplicado al MN.<br />
Podemos observar que la figura 7.12 es idéntica a la figura 7.8,<br />
pues como hemos com<strong>en</strong>tado las expresiones analíticas obt<strong>en</strong>idas eran<br />
similares. Así, el número de paquetes duplicados dep<strong>en</strong>derá del valor de T,<br />
pero siempre estará <strong>en</strong> valores muy próximos a 0.<br />
290
Evaluación analítica<br />
Para completar el análisis de la duplicidad de paquetes hemos<br />
variado el retardo de los <strong>en</strong>laces de las estaciones base al CN. La figura<br />
7.13 muestra el número de paquetes perdidos <strong>en</strong> función de la difer<strong>en</strong>cia<br />
de retardo de los <strong>en</strong>laces. Con el fin de poder comparar esta gráfica con<br />
otras obt<strong>en</strong>idas anteriorm<strong>en</strong>te (por ejemplo la fig. 7.9), el eje horizontal<br />
indica el retardo de la ruta hasta oBS m<strong>en</strong>os el retardo de la ruta hacia<br />
nBS: CNoBS - CNnBS. Es decir, el eje horizontal se corresponde con el<br />
valor negado de la constante e’’ que aparece <strong>en</strong> la ecuación (7.37).<br />
Los restantes valores se han mant<strong>en</strong>ido constantes: tasa de servicio<br />
µ = 10 paquetes por mseg., carga ρ = 0.8 y tiempo medio <strong>en</strong>tre paquetes <strong>en</strong><br />
CN de 10 mseg.<br />
Figura 7.13 Paquetes duplicados <strong>en</strong> función de la difer<strong>en</strong>cia de retardos de las<br />
rutas CNoBS y CNnBS.<br />
En la figura se observa que cuando retardo <strong>en</strong>tre el nodo de cruce y<br />
la estación base antigua CNoBS es s<strong>en</strong>siblem<strong>en</strong>te inferior al retardo<br />
CNnBS, lo que se corresponde con valores negativos de la gráfica, se<br />
produc<strong>en</strong> multitud de paquetes duplicados.<br />
291
Evaluación analítica.<br />
El razonami<strong>en</strong>to del comportami<strong>en</strong>to es claro, el nodo móvil acepta<br />
todos los paquetes de oBS hasta que recibe, vía nBS, el m<strong>en</strong>saje ‘Intra-<br />
Domain Registration Request’. Pero para que se <strong>en</strong>víe este m<strong>en</strong>saje nBS ha<br />
debido recibir, previam<strong>en</strong>te, un m<strong>en</strong>saje ‘ACK Join’ desde el nodo de cruce.<br />
Ahora el m<strong>en</strong>saje ‘ACK Join’ va a costar más tiempo llegar, pues se ha<br />
aum<strong>en</strong>tado el retardo CNnBS. Durante todo este tiempo CN ya está<br />
transmiti<strong>en</strong>do nuevos paquetes hacia las dos estaciones. Estos paquetes<br />
llegarán al MN vía oBS (que ti<strong>en</strong>e un <strong>en</strong>lace con poco retardo) pero<br />
también a nBS que los retransmitirá hacia MN cuando finalm<strong>en</strong>te le<br />
llegu<strong>en</strong>. La figura 7.14 muestra esta situación.<br />
Un análisis similar puede realizarse variando la carga de los<br />
distintos routers. Así, si se aum<strong>en</strong>ta la carga de los routers que forman la<br />
ruta CNnBS se producirá un aum<strong>en</strong>to de paquetes duplicados <strong>en</strong> manera<br />
similar al efecto que se estudió <strong>en</strong> la figura 7.10.<br />
Nodo de<br />
Cruce<br />
6<br />
6<br />
5<br />
Ack Join<br />
oBS<br />
nBS<br />
5<br />
MN<br />
Figura 7.14 duplicación de paquetes <strong>en</strong> handover Semi Suave.<br />
292
Evaluación analítica<br />
7.3.5 Conclusiones del handover Semi Suave<br />
En este punto se ha realizado un estudio del handover Semi Suave<br />
descrito <strong>en</strong> 6.4. Basándonos <strong>en</strong> la capacidad de comunicación simultánea<br />
del nodo móvil se han descrito dos modos difer<strong>en</strong>tes de implem<strong>en</strong>tar este<br />
protocolo. El primero sería aceptar todos los paquetes que se recib<strong>en</strong> de<br />
ambas estaciones base mi<strong>en</strong>tras se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona de solape. En el<br />
segundo modo de actuación, el nodo móvil, tras recibir un m<strong>en</strong>saje de nBS<br />
indicándole la conexión al árbol <strong>multicast</strong>, supone la finalización del<br />
proceso de handover, <strong>en</strong>viando un m<strong>en</strong>saje indicativo a oBS y desechando<br />
cualquier paquete posterior de esta estación base.<br />
Se ha realizado un análisis de ambos modos. Si se aceptan todos<br />
los paquetes que recibe el nodo móvil cuando se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona de<br />
solape es posible lograr que no se pierda ningún paquete, simplem<strong>en</strong>te<br />
dándole a la zona de solape unas dim<strong>en</strong>siones mínimas (ver figura 7.7). El<br />
problema de esta solución es que el número de paquetes duplicados<br />
aum<strong>en</strong>ta directam<strong>en</strong>te con el tiempo <strong>en</strong> que el nodo móvil permanece <strong>en</strong> la<br />
zona de solape, como puede observarse <strong>en</strong> la figura 7.11. El tiempo de<br />
perman<strong>en</strong>cia del nodo móvil dep<strong>en</strong>de, evid<strong>en</strong>tem<strong>en</strong>te, del tamaño de la<br />
zona aum<strong>en</strong>ta, pero también de la velocidad o de ruta que sigue el nodo.<br />
Por tanto el número de paquetes duplicados es poco previsible y toma<br />
valores elevados.<br />
Para solucionar el problema de la duplicación de paquetes que<br />
hemos observado proponemos el segundo modo de funcionami<strong>en</strong>to, <strong>en</strong> el<br />
que la aceptación de paquetes de oBS vi<strong>en</strong>e controlada por la recepción del<br />
m<strong>en</strong>saje ‘Intra-Domain Registration Request’. Según se observó <strong>en</strong> las<br />
figuras 7.8 y 7.12 el esquema funciona perfectam<strong>en</strong>te, sin pérdida ni<br />
duplicidad de paquetes, siempre que las rutas <strong>en</strong>tre las estaciones base y<br />
el nodo de cruce parecidas.<br />
La figura 7.15 muestra como aum<strong>en</strong>ta el número de paquetes<br />
duplicados y perdidos al hacer difer<strong>en</strong>te el retardo de las rutas CNoBS y<br />
CNnBS. Así el eje horizontal se corresponde con la resta (CNoBS)-<br />
(CNnBS), de manera que cuando la ruta hacia la estación base antigua<br />
293
Evaluación analítica.<br />
ti<strong>en</strong>e un retardo mayor se produce pérdida de paquetes (valores positivos<br />
del eje horizontal), y <strong>en</strong> caso contrario el resultado es una duplicidad de<br />
paquetes.<br />
Figura 7.15 Paquetes perdidos y duplicados <strong>en</strong> función de la difer<strong>en</strong>cia de retardos<br />
de las rutas (CNoBS) y (CNnBS).<br />
Por tanto podemos concluir dici<strong>en</strong>do que el esquema de handover<br />
funciona correctam<strong>en</strong>te <strong>en</strong> situaciones <strong>en</strong> que las rutas <strong>en</strong>tre las<br />
estaciones base implicadas <strong>en</strong> el handover y el nodo de cruce son<br />
similares. En caso contrario se produce pérdida o duplicación de paquetes.<br />
Como se estudió <strong>en</strong> el capítulo anterior, el problema se ha solucionado<br />
pres<strong>en</strong>tando un nuevo esquema de handover que d<strong>en</strong>ominamos ‘Handover<br />
Suave con Finalización Controlada’ , y que vamos a evaluar analíticam<strong>en</strong>te<br />
<strong>en</strong> el sigui<strong>en</strong>te punto.<br />
294
Evaluación analítica<br />
7.4 ESQUEMA SUAVE CON FINALIZACION<br />
CONTROLADA<br />
En el punto 6.5 se detalló el esquema de handover Suave con<br />
Finalización Controlada. Este esquema logra evitar los problemas de<br />
pérdida y duplicidad de paquetes que pres<strong>en</strong>ta el esquema Semi Suave, y<br />
que fueron estudiados <strong>en</strong> el punto anterior.<br />
El mecanismo de handover se basa <strong>en</strong> que el nodo móvil no da por<br />
finalizada la comunicación con oBS nada más recibir la confirmación de<br />
que la nueva estación base se ha conectado con éxito al árbol <strong>multicast</strong>.<br />
Por el contrario, MN retrasa premeditadam<strong>en</strong>te el <strong>en</strong>vío del m<strong>en</strong>saje de<br />
desconexión con oBS, con el fin de que ésta pueda transmitir los paquetes<br />
p<strong>en</strong>di<strong>en</strong>tes <strong>en</strong> colas. Antes de perder la cobertura el nodo móvil se<br />
desconecta de oBS, a la vez que indica a nBS que comi<strong>en</strong>ce la transmisión<br />
de los paquetes que ha ido almac<strong>en</strong>ando. Para evitar recibir paquetes<br />
duplicados, el nodo móvil le indica a nBS a partir de que paquete debe<br />
transmitir, de manera que la estación base descartará los paquetes<br />
previos.<br />
Se va a estudiar tres aspectos difer<strong>en</strong>tes del protocolo.<br />
Com<strong>en</strong>zaremos por un estudio de los paquetes perdidos, similar a los ya<br />
realizados anteriorm<strong>en</strong>te. Se realizará también un estudio del retardo<br />
adicional que sufr<strong>en</strong> los paquetes que, según el procedimi<strong>en</strong>to detallado <strong>en</strong><br />
el punto 6.5, deb<strong>en</strong> ser almac<strong>en</strong>ados temporalm<strong>en</strong>te antes de su<br />
transmisión. Para finalizar estudiaremos las posibles limitaciones que<br />
ti<strong>en</strong>e el esquema de handover con finalización controlada.<br />
Para realizar el desarrollo analítico partimos del hecho que este<br />
mecanismo de handover se basa <strong>en</strong> el esquema Semi Suave analizado <strong>en</strong> el<br />
punto 7.3. Por lo tanto vamos a tomar como base el desarrollo matemático<br />
realizado <strong>en</strong> ese punto, evitando así repetir cálculos.<br />
295
Evaluación analítica.<br />
7.4.1 Análisis de los paquetes perdidos<br />
7.4.1.1 Desarrollo analítico<br />
Com<strong>en</strong>zamos el desarrollo estudiando la probabilidad de que el<br />
esquema de handover pierda algún paquete. Según el esquema descrito <strong>en</strong><br />
6.5, tras la recepción del m<strong>en</strong>saje ‘Intra-Domain Registration Reply’, el nodo<br />
móvil retrasa int<strong>en</strong>cionadam<strong>en</strong>te el <strong>en</strong>vío del m<strong>en</strong>saje ’Multicast Prune<br />
Request’ hacia oBS. De esta manera oBS t<strong>en</strong>drá más tiempo de transmitir<br />
los paquetes p<strong>en</strong>di<strong>en</strong>tes, y el número de paquetes perdidos será m<strong>en</strong>or que<br />
el estudiado <strong>en</strong> el esquema Semi Suave (ver figura 7.9).<br />
Como <strong>en</strong> el esquema anterior, los únicos paquetes que se pierd<strong>en</strong><br />
son aquellos que llegan al nodo móvil una vez éste ha <strong>en</strong>viado el m<strong>en</strong>saje<br />
de desconexión a oBS, pero que además el CN no los ha transmitido hacia<br />
nBS. Definimos t 5<br />
como el instante de tiempo <strong>en</strong> el que el nodo móvil<br />
<strong>en</strong>vía el m<strong>en</strong>saje ’Multicast Prune Request’. La ecuación (7.38) muestra que<br />
este tiempo es igual al tiempo <strong>en</strong> que recibe el m<strong>en</strong>saje de confirmación<br />
‘Intra-Domain Registration Reply’ más un tiempo de retraso que<br />
d<strong>en</strong>ominamos ϕ.<br />
t 5 = t 3 + ϕ<br />
(7.38)<br />
Podemos calcular el instante de tiempo t 6<br />
a partir del cual los<br />
paquetes que alcanc<strong>en</strong> el nodo de cruce llegarán al nodo móvil, vía oBS,<br />
más tarde del instante t 5<br />
t 6 = t5<br />
− [ CN + ( CN,<br />
R1<br />
) + R1<br />
+ ( R1<br />
+ oBS)<br />
+ oBS]=<br />
(7.39)<br />
[ X ' ']<br />
= t +<br />
5 − c<br />
si<strong>en</strong>do X’ y c’ las utilizadas <strong>en</strong> la ecuación (7.24):<br />
c ' = ( CN,<br />
R1 ) + ( R1<br />
, oBS)<br />
296
Evaluación analítica<br />
X’ = v.a. con fdd:<br />
f<br />
X '<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1 − ρ)<br />
2<br />
Los paquetes perdidos son los que llegan al CN <strong>en</strong> un instante de<br />
tiempo posterior a t 6 pero anterior a t 2 , que se corresponde con el<br />
instante de la recepción del m<strong>en</strong>saje ‘Join’ , ver ecuación (7.18). Por tanto<br />
la probabilidad de que un paquete se pierda es:<br />
P<br />
[ t < ( k −1<br />
T + u t ]<br />
per − k = Prob 6 ) < 2<br />
(7.40)<br />
Es interesante observar la gran analogía exist<strong>en</strong>te <strong>en</strong>tre esta<br />
ecuación y la obt<strong>en</strong>ida para la pérdida de paquetes <strong>en</strong> el handover Semi<br />
Suave (7.25). Debido a que la única difer<strong>en</strong>cia es el valor constante ϕ que<br />
difer<strong>en</strong>cia los valores de t 6 y t 4 , el desarrollo de la ecuación será similar al<br />
ya realizado. Así igualando t 6 = 0 y simplificando la ecuación (7.40) la<br />
podemos rescribir de la sigui<strong>en</strong>te forma:<br />
[ 0 < ( k −1)<br />
T + u < X ' −Y<br />
' + e'<br />
−ϕ ]<br />
Pper k = Pr ob<br />
(7.41)<br />
−<br />
Dado que la única difer<strong>en</strong>cia es una constante, el desarrollo de la<br />
ecuación (7.41) es idéntico al ya desarrollado <strong>en</strong> el Anexo 2.1 y la<br />
expresión final será:<br />
P<br />
T<br />
∫ ∫<br />
∞<br />
1<br />
per− k =<br />
Y o +<br />
T<br />
si<strong>en</strong>do ahora z’ :<br />
0 max(0,uo<br />
-z')<br />
[ F ( z'<br />
−u<br />
x )]<br />
o<br />
β<br />
3 2<br />
xo<br />
2<br />
e<br />
−β<br />
xo<br />
dx<br />
o<br />
du<br />
o<br />
(7.42)<br />
z ' = e'<br />
−ϕ<br />
− ( k −1)<br />
T =<br />
= CN , R ) + ( R , oBS)<br />
− ( CN,<br />
R ) − ( R , nBS)<br />
−ϕ<br />
− ( k 1)<br />
T<br />
( 1 1<br />
2 2<br />
−<br />
La ecuación anterior es válida siempre que el tiempo de retardo ϕ<br />
no provoque que el nodo móvil se salga de la zona de solape antes de<br />
<strong>en</strong>viar el m<strong>en</strong>saje ‘Multicast Prune Request’. A continuación vamos a<br />
estudiar este hecho.<br />
297
Evaluación analítica.<br />
Utilizando las ecuaciones (7.23) y (7.19) podemos rescribir el<br />
instante t 5 , <strong>en</strong> que el MN <strong>en</strong>vía el m<strong>en</strong>saje, <strong>en</strong> función del tiempo <strong>en</strong> el que<br />
el nodo móvil atraviesa el punto medio de la zona de solape:<br />
t = tm + ∆h<br />
+ Y + d + Y ' + ' +ϕ<br />
(7.43)<br />
5 d<br />
Como hemos com<strong>en</strong>tado, el instante t 5 , <strong>en</strong> el que el nodo móvil<br />
<strong>en</strong>vía el m<strong>en</strong>saje, debe producirse antes de que se abandone la zona de<br />
cobertura. Según (7.16) este abandono ocurre <strong>en</strong> el instante:<br />
t<br />
AB<br />
= t m<br />
σ<br />
+<br />
2<br />
Por tanto, tomando como refer<strong>en</strong>cia t m = 0 , la probabilidad de que<br />
el handover ocurra de manera correcta es:<br />
Prob 5<br />
[ < t ] = Prob [ Y + Y ' ≤ − d − d'<br />
−∆h<br />
− ϕ]<br />
=<br />
t AB<br />
σ<br />
2<br />
σ<br />
= Prob [ Z ≤ − d − d'<br />
−∆h<br />
− ϕ]<br />
(7.44)<br />
2<br />
Si<strong>en</strong>do F z (t)<br />
la función de distribución de la v.a. Z que se ha<br />
obt<strong>en</strong>ido como suma de las dos v.a. que aparecían <strong>en</strong> la ecuación:<br />
Z = Y + Y ' :<br />
F ( t)<br />
= 1 − e<br />
z<br />
−β<br />
t<br />
4<br />
∑<br />
n=<br />
0<br />
( t β )<br />
n!<br />
n<br />
Recordemos que ∆ h es una variable aleatoria con una función de<br />
d<strong>en</strong>sidad de distribución uniforme <strong>en</strong>tre 0 y el periodo de <strong>en</strong>vío de<br />
m<strong>en</strong>sajes ∆ ho . Así la ecuación (7.44) podemos desarrollarla como sigue:<br />
Prob<br />
1<br />
<<br />
∆ ∫ ∆ho<br />
AB<br />
ho 0<br />
σ<br />
2<br />
[ t t ] = Pr ob [ Z ≤ − d − d'<br />
−ϕ<br />
− ∆H<br />
| ∆H<br />
= ∆h<br />
d∆h<br />
=<br />
5 ]<br />
1<br />
=<br />
∆ho 0<br />
∫ ∆ ho<br />
σ<br />
Fz<br />
( − d − d'<br />
−ϕ<br />
− ∆h)<br />
d∆h<br />
2<br />
(7.45)<br />
298
Evaluación analítica<br />
7.4.1.2 Resultados<br />
Como se ha com<strong>en</strong>tado <strong>en</strong> el desarrollo analítico, la ecuación (7.42),<br />
que muestra la probabilidad de que el paquete k-ésimo se pierda, es<br />
idéntica a la desarrollada para el handover Semi Suave (7.28), con la única<br />
salvedad de la constante z’. Por tanto, los valores que se vamos a obt<strong>en</strong>er<br />
<strong>en</strong> este punto deb<strong>en</strong> estar relacionados, <strong>en</strong> cierta manera, con los que se<br />
obtuvieron el punto 7.3.2.<br />
Así, la figura 7.9 mostraba el número medio de paquetes perdidos<br />
<strong>en</strong> función del valor de la constante e’, que se corresponde con la<br />
difer<strong>en</strong>cia <strong>en</strong>tre las rutas CN-oBS y CN-nBS. En esta gráfica se podía<br />
comprobar como valores positivos de e’ provocaban un aum<strong>en</strong>to<br />
importante de los paquetes que se perdían durante el handover, mi<strong>en</strong>tras<br />
que valores negativos de esta constante aseguraban la <strong>en</strong>trega de todos los<br />
paquetes al nodo móvil. En la expresión de la constante z’ de la ecuación<br />
(7.42) se observa como ahora el tiempo de retraso ϕ comp<strong>en</strong>sa este valor<br />
positivo de e’.<br />
Es decir, el esquema de ‘Handover Semi Suave’ provocaba una<br />
pérdida de paquetes cuando la ruta desde el CN a oBS es más l<strong>en</strong>ta que la<br />
ruta a la estación base nueva. Para solucionar este problema se retrasa de<br />
forma int<strong>en</strong>cionada el <strong>en</strong>vío del m<strong>en</strong>saje ‘Multicast Prune Request’ durante<br />
un tiempo que d<strong>en</strong>ominamos ϕ. Este tiempo se resta directam<strong>en</strong>te a la<br />
difer<strong>en</strong>cia de caminos.<br />
Por ejemplo, un <strong>en</strong>lace (CNoBS) que es x mseg. más l<strong>en</strong>to que el<br />
(CNnBS), lo que equivale a e’ = x, quedaría comp<strong>en</strong>sado por un retraso ϕ<br />
= x mseg. Ahora el valor e’-ϕ sería igual a 0, y la probabilidad de que el<br />
paquete se perdiera sería casi nula, como se demostró <strong>en</strong> la figura 7.8.<br />
La figura 7.16 muestra el número medio de paquetes perdidos <strong>en</strong><br />
función de la difer<strong>en</strong>cia e’-ϕ. Como se aprecia esta gráfica coincide<br />
exactam<strong>en</strong>te con la figura 7.9.<br />
299
Evaluación analítica.<br />
Figura 7.16 Número medio de paquetes perdidos <strong>en</strong> función de la constante e’-ϕ.<br />
Como hemos demostrado <strong>en</strong> el desarrollo anterior, no cualquier<br />
difer<strong>en</strong>cia de retardo <strong>en</strong> las rutas a las estaciones base puede ser<br />
comp<strong>en</strong>sada retrasando el m<strong>en</strong>saje ‘Multicast Prune Request’ un tiempo ϕ<br />
adecuado. Esto es cierto únicam<strong>en</strong>te <strong>en</strong> el caso de que el nodo móvil se<br />
<strong>en</strong>cu<strong>en</strong>tre <strong>en</strong> la zona de cobertura cuando finalm<strong>en</strong>te desea <strong>en</strong>viar el<br />
m<strong>en</strong>saje.<br />
La figura 7.17 muestra la probabilidad de que el handover se<br />
realice correctam<strong>en</strong>te, obt<strong>en</strong>ida a partir de la ecuación (7.45). Para su<br />
realización se han tomado constante el retardo del <strong>en</strong>lace <strong>en</strong>tre dos routers<br />
= 5 mseg. y el retardo máximo de detección de handover ∆ ho = 100 mseg.<br />
El eje horizontal se corresponde con el tiempo de retraso <strong>en</strong> g<strong>en</strong>erar el<br />
m<strong>en</strong>saje ‘Multicast Prune Request’ ϕ, y se han realizado mediciones para<br />
distintos valores del tiempo que necesita el nodo para atravesar la zona de<br />
cobertura σ.<br />
En la gráfica se observa como la probabilidad de que el handover se<br />
realice correctam<strong>en</strong>te desci<strong>en</strong>de de manera muy abrupta, de manera que<br />
300
Evaluación analítica<br />
con una variación pequeña del retardo ϕ se pasa de una probabilidad de<br />
valor 1 a una de valor 0.<br />
Figura 7.17 Probabilidad de que el Handover se realice de manera correcta <strong>en</strong><br />
función del tiempo de retraso ϕ.<br />
Observemos por ejemplo la curva obt<strong>en</strong>ida con una zona de<br />
cobertura σ de 1000 mseg. La función de distribución de la v.a. Z es cero<br />
para valores negativos, pues repres<strong>en</strong>ta el tiempo de procesado de un<br />
conjunto de routers. Así, la probabilidad de éxito será 0 cuando<br />
‘ σ 2 − d − d'<br />
−ϕ<br />
− ∆h<br />
’ sea negativo. Con los valores de los parámetros<br />
utilizados, la probabilidad es nula para valores de ϕ superiores a 480. La<br />
curva sube de una manera tan abrupta debido a que la función F Z cambia<br />
de 0 a 1 <strong>en</strong> 10 unidades. Es decir F ( 10) = 1.<br />
Z<br />
Podemos concluir este análisis indicando que el protocolo funciona<br />
perfectam<strong>en</strong>te cuando se retrasa el <strong>en</strong>vío del m<strong>en</strong>saje ‘Multicast Prune<br />
Request’ un tiempo ϕ igual o superior a la difer<strong>en</strong>cia de retardos <strong>en</strong>tre la<br />
ruta (CNoBS) y la ruta (CNnBS). El mecanismo funciona correctam<strong>en</strong>te<br />
siempre que cuando el nodo finalm<strong>en</strong>te desee <strong>en</strong>viar el m<strong>en</strong>saje aún se<br />
<strong>en</strong>cu<strong>en</strong>tre <strong>en</strong> la zona de solape de ambas estaciones base.<br />
301
Evaluación analítica.<br />
7.4.2 Análisis del retardo de los paquetes <strong>en</strong>tregados vía nBS<br />
Una vez el m<strong>en</strong>saje ‘Join’ ha alcanzado el nodo de cruce la nueva<br />
estación base queda incorporada al árbol <strong>multicast</strong> y, por tanto, los<br />
paquetes son dirigidos desde el CN hacia ella.<br />
Según el esquema de handover estudiado <strong>en</strong> 6.5 los m<strong>en</strong>sajes que<br />
son transmitidos vía nBS ti<strong>en</strong><strong>en</strong> una cierta probabilidad de t<strong>en</strong>er que<br />
esperar <strong>en</strong> la estación base antes de poder ser transmitidos hacía el nodo<br />
móvil. En este punto se va a realizar un análisis de este retardo adicional<br />
que sufr<strong>en</strong> los paquetes.<br />
Hay que t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta que sólo estamos considerando los<br />
paquetes que se transmit<strong>en</strong> hacia nBS. Es decir, aquellos que son<br />
recibidos por el nodo de cruce <strong>en</strong> un instante posterior a t 2 . Los paquetes<br />
anteriores no pued<strong>en</strong> sufrir este retraso, sino tan sólo una cierta<br />
probabilidad de pérdida que ya fue analizada <strong>en</strong> el punto 7.4.1.<br />
Los paquetes que llegan a nBS se pued<strong>en</strong> clasificados <strong>en</strong> una de las<br />
tres clases sigui<strong>en</strong>tes:<br />
• Clase 1: Aquellos paquetes que llegan a nBS pero que<br />
posteriorm<strong>en</strong>te son descartados. Estos paquetes ya han sido<br />
recibidos por el MN vía oBS, y por tanto la nueva estación base no<br />
los transmite.<br />
• Clase 2: Aquellos paquetes que son almac<strong>en</strong>ados por el nBS y<br />
posteriorm<strong>en</strong>te transmitidos hacia el nodo móvil. Estos paquetes no<br />
han sido recibidos por MN vía oBS y, por eso, cuando la nueva<br />
estación recibe el m<strong>en</strong>saje ‘Handover Switch Indication’ comi<strong>en</strong>za a<br />
transmitirlos.<br />
• Clase 3: Aquellos paquetes que llegan a la nueva estación base<br />
cuando ya ha recibido el m<strong>en</strong>saje ‘Handover Switch Indication’ del<br />
nodo móvil. Estos paquetes no son almac<strong>en</strong>ados, transmitiéndose<br />
tan pronto se pueda.<br />
302
Evaluación analítica<br />
A continuación realizamos un desarrollo analítico para estudiar la<br />
probabilidad de que un paquete determinado pert<strong>en</strong>ezca a las tres clases<br />
anteriores.<br />
7.4.2.1 Desarrollo analítico<br />
El objetivo de este desarrollo es calcular la probabilidad de que el<br />
paquete k-ésimo pert<strong>en</strong>ezca a una de las tres clases.<br />
Como <strong>en</strong> los estudios anteriores suponemos que los paquetes llegan<br />
al nodo de cruce cada T mseg. normalizamos con t 2 = 0, de manera que el<br />
primer paquete que alcanza el nodo de cruce cuando nBS está incorporada<br />
al árbol <strong>multicast</strong> se corresponde con k = 1 y llega <strong>en</strong> el instante:<br />
(k-1)T+u=u.<br />
Paquetes pert<strong>en</strong>eci<strong>en</strong>tes a la clase 1.<br />
La probabilidad de que el paquete k-ésimo pert<strong>en</strong>ezca a la clase 1<br />
es la probabilidad de que dicho paquete haya sido recibido por <strong>en</strong> nodo<br />
móvil vía oBS. Para que se cumpla esto el paquete debe haber llegado al<br />
nodo de cruce antes del instante t 6 (instante del <strong>en</strong>vío del m<strong>en</strong>saje<br />
‘Multicast Prune Request’), que fue calculado <strong>en</strong> la ecuación (7.39).<br />
[ paq. k ∈clase1] = Prob[ t < ( k −1<br />
T + u t ]<br />
P k − cl . 1 = Prob<br />
2 ) < 6<br />
(7.46)<br />
Una expresión similar fue desarrollada <strong>en</strong> (7.35). Así, desarrollando<br />
(7.46) igual que se hizo <strong>en</strong>tonces podemos rescribirla como:<br />
P<br />
1<br />
T<br />
T<br />
∫ ∫<br />
∞<br />
[ F'<br />
( z'<br />
−u<br />
y )]<br />
k − cl.1<br />
=<br />
X o +<br />
si<strong>en</strong>do<br />
0 max(0,uo<br />
-z')<br />
o<br />
3<br />
β y<br />
2<br />
2<br />
o<br />
e<br />
−β<br />
yo<br />
dy<br />
o<br />
du<br />
o<br />
(7.47)<br />
z ' = d'<br />
−c'<br />
+ ϕ − ( k −1)<br />
T =<br />
303
Evaluación analítica.<br />
= CN , R ) + ( R , nBS)<br />
− ( CN,<br />
R ) − ( R , oBS)<br />
+ ϕ − ( k 1)<br />
T<br />
( 2 2<br />
1 1<br />
−<br />
Evid<strong>en</strong>tem<strong>en</strong>te estos paquetes no sufr<strong>en</strong> ningún retardo adicional<br />
al de cualquier otro paquete no involucrado <strong>en</strong> el mecanismo de handover.<br />
El motivo es que estos paquetes han sido <strong>en</strong>viados por oBS sin haber<br />
sufrido el almac<strong>en</strong>ami<strong>en</strong>to temporal, y serán descartados <strong>en</strong> nBS.<br />
[ retardo paq. k ∈clase1] 0<br />
Prob > τ =<br />
(7.48)<br />
Paquetes pert<strong>en</strong>eci<strong>en</strong>tes a la clase 2.<br />
La probabilidad de que un paquete k pert<strong>en</strong>ezca a esta clase se<br />
corresponde con la probabilidad de que el paquete llegue a la nueva<br />
estación base antes de que lo haga el m<strong>en</strong>saje ‘Handover Switch<br />
Indication’. Suponi<strong>en</strong>do que este m<strong>en</strong>saje se <strong>en</strong>vía simultáneam<strong>en</strong>te que el<br />
m<strong>en</strong>saje ‘Multicast Prune Request’, esto pasará <strong>en</strong> t 5 . Además el m<strong>en</strong>saje<br />
no puede haber sido recibido por oBS, es decir no pert<strong>en</strong>ece a la clase 1.<br />
Podemos definir el instante t 7 como aquel a partir del cual los<br />
paquetes que alcanc<strong>en</strong> CN llegarán a nBS más tarde que t 5 .<br />
t 7 = t5<br />
− [ CN + ( CN,<br />
R2<br />
) + R2<br />
+ ( R2,<br />
nBS)<br />
+ nBS]=<br />
(7.49)<br />
= t 5 − ( Y ' + d'<br />
)<br />
La ecuación anterior ha sido simplificada utilizando las definiciones<br />
de Y’ y d’ que fueron calculadas <strong>en</strong> la ecuación (7.23).<br />
Por tanto la probabilidad de que el paquete k-ésimo pert<strong>en</strong>ezca a la<br />
clase 2 es la mostrada <strong>en</strong> (7.50).<br />
[ paq. k ∈clase 2] = Prob[ t < ( k −1<br />
T + u t ]<br />
P k − cl . 2 = Prob<br />
6 ) < 7<br />
(7.50)<br />
Utilizando las ecuaciones (7.49), (7.39), (7.38) y (7.23) podemos<br />
rescribir la probabilidad anterior como:<br />
304
P − cl<br />
[ Y ' + d'<br />
+ ϕ − X ' −c'<br />
< ( k −1)<br />
T + u < Y ' − ' +ϕ ]<br />
Evaluación analítica<br />
k . 2 = Prob Y1<br />
(7.51)<br />
En la ecuación anterior hemos distinguido dos variedades de la v.a<br />
Y’, puesto que se corresponde con el tiempo de procesami<strong>en</strong>to de dos<br />
paquetes difer<strong>en</strong>tes. Los tiempos t 7 y t 6 que se han desglosado <strong>en</strong> la<br />
ecuación 7.51 no son completam<strong>en</strong>te indep<strong>en</strong>di<strong>en</strong>tes, lo que complica el<br />
desarrollo de la ecuación. El desarrollo completo para alcanzar la<br />
expresión (7.52) se muestra <strong>en</strong> el Anexo 2.2.<br />
1 T<br />
P<br />
∫ ∫ ∞ k −cl. 2 =<br />
(1- FZ<br />
( zo − ( K −1)<br />
T + a − uo))<br />
f Z ' ( zo)<br />
dzoduo (7.52)<br />
T 0 (k-1)T+<br />
uo-ϕ<br />
El cálculo analítico del retardo que sufr<strong>en</strong> los paquetes que<br />
pert<strong>en</strong>ec<strong>en</strong> a esta clase se complica <strong>en</strong> exceso. Este tiempo se corresponde<br />
con la difer<strong>en</strong>cia <strong>en</strong>tre el instante de tiempo <strong>en</strong> el cual el paquete alcanza<br />
nBS, almac<strong>en</strong>ándose <strong>en</strong> el buffer, y el instante de tiempo <strong>en</strong> el que<br />
finalm<strong>en</strong>te se transmite el paquete anterior. Podemos dividir este tiempo<br />
<strong>en</strong> dos compon<strong>en</strong>tes.<br />
El primero, t A se corresponde con el tiempo desde que el paquete<br />
llega a nBS y ésta recibe el paquete ‘Handover Switch Indication’:<br />
t A<br />
= t5 − [( k −1)<br />
T + u + CN + ( CN,<br />
R2<br />
) + R2<br />
+ ( R2<br />
, nBS)<br />
]=<br />
= ( Y ' + d'<br />
+ ϕ ) − [(<br />
k −1)<br />
T + u + CN + R2 + d'<br />
]=<br />
= Y ' −Y<br />
'' −(<br />
k −1)<br />
T − u + ϕ<br />
(7.53)<br />
con Y’’ = v.a. con fdd:<br />
f<br />
t<br />
Y ''<br />
( )<br />
2<br />
−β<br />
t<br />
= β te para t ≥ 0 y con β = µ ( 1 − ρ)<br />
El segundo compon<strong>en</strong>te es el tiempo necesario para trasmitir las<br />
tramas que han sido almac<strong>en</strong>adas antes que él <strong>en</strong> el buffer, y que no han<br />
sido descartadas. Para poder conocer este tiempo necesitamos t<strong>en</strong>er<br />
conocimi<strong>en</strong>to sobre el número de paquetes que se van a descartar.<br />
305
Evaluación analítica.<br />
Así los paquetes que se transmit<strong>en</strong> desde CN antes de t 6 (7.36) son<br />
recibidos por el nodo móvil vía oBS y por tanto se descartan del buffer de<br />
nBS. La probabilidad de que el último paquete recibido por oBS (y por<br />
tanto el último que se descarta <strong>en</strong> nBS) sea el paquete j-ésimo podemos<br />
escribirla como<br />
P<br />
[(<br />
j −1)<br />
T + u < t < jT u]<br />
último = j =<br />
6 +<br />
Prob (7.54)<br />
Por tanto podríamos escribir el tiempo t B , necesario para transmitir<br />
las tramas almac<strong>en</strong>adas, como se muestra <strong>en</strong> la ecuación (7.55), donde se<br />
ha realizado una suma de las probabilidades de descartar j paquetes,<br />
mult<strong>ip</strong>licando cada una de ellas por el tiempo necesario para transmitir los<br />
k −1 − j paquetes restantes.<br />
t<br />
B<br />
=<br />
k 1<br />
∑ − Púltimo=<br />
j<br />
j=1<br />
( k − j −1)<br />
µ<br />
(7.55)<br />
Finalm<strong>en</strong>te, la probabilidad de que el paquete k-ésimo,<br />
pert<strong>en</strong>eci<strong>en</strong>te a la clase 2, sufra un retardo adicional superior al valor τ, se<br />
puede describir como:<br />
[ retardo τ paq. k ∈clase 2] = Prob[ t A + t > τ ]<br />
> B<br />
Prob (7.56)<br />
Paquetes pert<strong>en</strong>eci<strong>en</strong>tes a la clase 3.<br />
Para finalizar, la probabilidad de que un paquete k pert<strong>en</strong>ezca a<br />
esta clase se corresponde con la probabilidad de que el paquete llegue a la<br />
nueva estación base después de que lo haga el m<strong>en</strong>saje ‘Handover Switch<br />
Indication’. Utilizando el instante t 7 definido <strong>en</strong> (7.49):<br />
[ paq. k ∈clase 3] = Prob[ t < ( k −1<br />
T + u] =<br />
P k − cl . 3 = Prob 7 )<br />
[ Y'-Y ' + < (k -1)T u]<br />
= Prob 1 ϕ +<br />
(7.57)<br />
La resolución de la ecuación (7.57) se ha realizado <strong>en</strong> el Anexo 2.3,<br />
dando como resultado:<br />
306
Evaluación analítica<br />
P<br />
1<br />
T<br />
T<br />
∫ ∫<br />
∞<br />
0 max(0,-uo<br />
−z)<br />
[ F ( z + u y )]<br />
k − cl.3<br />
=<br />
Y ' o +<br />
con z =(k-1)T-ϕ<br />
o<br />
3<br />
β y<br />
2<br />
2<br />
o<br />
e<br />
−β<br />
yo<br />
dy<br />
o<br />
du<br />
o<br />
(7.58)<br />
Los paquetes que pert<strong>en</strong>ec<strong>en</strong> a la clase 3 también pued<strong>en</strong> sufrir un<br />
pequeño retardo adicional debido al mecanismo de handover. Cuando nBS<br />
recibe el m<strong>en</strong>saje que le permite transmitir datos al nodo móvil le cuesta<br />
un tiempo vaciar el buffer. Los paquetes que se recib<strong>en</strong> mi<strong>en</strong>tras se realiza<br />
este proceso se almac<strong>en</strong>an retrasándose ligeram<strong>en</strong>te la transmisión.<br />
7.4.2.2 Resultados<br />
A continuación vamos a mostrar la probabilidad de que un paquete<br />
k-ésimo pert<strong>en</strong>ezca a cada una de las clases definidas anteriorm<strong>en</strong>te.<br />
Paquetes pert<strong>en</strong>eci<strong>en</strong>tes a la clase 1.<br />
La figura 7.18 nos muestra la probabilidad de que el paquete<br />
pert<strong>en</strong>ezca a la clase 1, y por consigui<strong>en</strong>te que no sufra ningún retardo<br />
adicional al ser <strong>en</strong>tregado por oBS y no por nBS.<br />
Se ha variado el retardo ‘Multicast Prune Request’ ϕ, mi<strong>en</strong>tras que<br />
los restantes valores se han mant<strong>en</strong>ido constantes: tasa de servicio µ = 10<br />
paquetes por mseg., carga ρ = 0.8 y tiempo medio <strong>en</strong>tre paquetes <strong>en</strong> CN de<br />
10 mseg. Suponemos también que las rutas hacia las dos estaciones base<br />
son iguales, de manera que la expresión c’-d’, d<strong>en</strong>ominada <strong>en</strong> todo este<br />
estudio e’, vale 0.<br />
Se observa claram<strong>en</strong>te como la probabilidad disminuye al aum<strong>en</strong>tar<br />
el número del paquete, ya que es más probable de que ese paquete no hay<br />
sido recibido vía oBS y que por tanto no pert<strong>en</strong>ezca a la clase 1. Al<br />
aum<strong>en</strong>tar el retardo <strong>en</strong> <strong>en</strong>viar el m<strong>en</strong>saje ‘Multicast Prune Request’ estamos<br />
alargando el tiempo <strong>en</strong> el que me mant<strong>en</strong>go conectado a la estación<br />
307
Evaluación analítica.<br />
anterior, y por esto también aum<strong>en</strong>ta el número de paquetes recibidos sin<br />
retardo.<br />
Figura 7.18 Probabilidad de pert<strong>en</strong><strong>en</strong>cia a la clase 1.<br />
También es interesante destacar que <strong>en</strong> la ecuación (7.47) el valor<br />
del retardo ϕ está asociado al valor e’. Es decir, lo que realm<strong>en</strong>te influye es<br />
la resta ϕ-e’. Así el valor de la gráfica ϕ=30 de la figura anterior será el<br />
obt<strong>en</strong>ido para cualquier combinación ϕ-e’=30. Esto equivale a decir que<br />
cuanto más grande es la ruta CN-oBS <strong>en</strong> comparación con la ruta CN-nBS<br />
(valor de e’ mayor), m<strong>en</strong>or es la probabilidad de que el paquete sea <strong>en</strong>viado<br />
vía oBS.<br />
Paquetes pert<strong>en</strong>eci<strong>en</strong>tes a la clase 2.<br />
Para que un paquete pert<strong>en</strong>ezca a la clase 2 es necesario que llegue<br />
a nBS antes que el m<strong>en</strong>saje ‘Handover Switch Indication’, pero que,<br />
además, haya llegado a oBS después de que el MN haya abandonado la<br />
conexión con esta estación. Es decir a la clase 2 pert<strong>en</strong>ec<strong>en</strong> los paquetes<br />
308
Evaluación analítica<br />
que, almac<strong>en</strong>ados temporalm<strong>en</strong>te <strong>en</strong> nBS, finalm<strong>en</strong>te son transmitidos por<br />
esta estación tras recibir el m<strong>en</strong>saje correspondi<strong>en</strong>te del MN.<br />
Según la ecuación (7.50) la probabilidad de pert<strong>en</strong>ecer a esta clase<br />
se traduce <strong>en</strong> la probabilidad de que los paquetes se g<strong>en</strong>er<strong>en</strong> <strong>en</strong>tre t 6 y t 7 .<br />
Estos tiempos se difer<strong>en</strong>cian, fundam<strong>en</strong>talm<strong>en</strong>te, <strong>en</strong> el tiempo que tardan<br />
los paquetes <strong>en</strong> ir del CN a oBS (valor c’ ) y a nBS (valor d’ )<br />
respectivam<strong>en</strong>te. Así, si los retardos hasta las dos estaciones base son<br />
idénticos, e’=c’-d’ =0, la probabilidad de que los paquetes pert<strong>en</strong>ezcan a<br />
esta clase es prácticam<strong>en</strong>te nula.<br />
La figura 7.19 muestra el comportami<strong>en</strong>to del sistema cuando las<br />
rutas ti<strong>en</strong><strong>en</strong> una difer<strong>en</strong>cia e’= 30 mseg. Es decir la ruta CN-oBS es 30<br />
mseg. más larga que al ruta CN-nBS. Los restantes valores se han<br />
mant<strong>en</strong>ido constantes: tasa de servicio µ = 10 paquetes por mseg., carga ρ<br />
= 0.8 y tiempo medio <strong>en</strong>tre paquetes <strong>en</strong> CN de 10 mseg.<br />
Figura 7.19 Probabilidad de pert<strong>en</strong><strong>en</strong>cia a la clase 2, e’=30 mseg.<br />
Se observa como las gráficas crec<strong>en</strong> a medida aum<strong>en</strong>ta el número<br />
de paquete hasta un máximo, a partir del cual vuelve a decrecer. Así para<br />
309
Evaluación analítica.<br />
cada gráfica los valores bajos de k ti<strong>en</strong><strong>en</strong> una probabilidad muy pequeña<br />
de pert<strong>en</strong>ecer a la clase 2. Esto es debido a que ti<strong>en</strong><strong>en</strong> una gran<br />
probabilidad de pert<strong>en</strong>ecer a la clase 1.<br />
Como se aprecia <strong>en</strong> la figura al aum<strong>en</strong>tar el valor de ϕ las gráficas<br />
se desplazan a la derecha, lo que equivale a que son más los paquetes que<br />
pued<strong>en</strong> ser <strong>en</strong>tregados vía oBS y, por tanto, no son deb<strong>en</strong> ser almac<strong>en</strong>ados<br />
<strong>en</strong> la nueva estación base.<br />
Hay que t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta que ahora no se logra las mismas gráficas<br />
mant<strong>en</strong>i<strong>en</strong>do el valor ϕ-e’ = constante (ver fórmula 7.52). Así la figura 7.20<br />
nos muestra la probabilidad de pert<strong>en</strong>ecer a la clase 2, tomando un valor<br />
e’=10 mseg., y mant<strong>en</strong>i<strong>en</strong>do los valores utilizados <strong>en</strong> la figura anterior.<br />
Puede observarse claram<strong>en</strong>te como la probabilidad de pert<strong>en</strong>ecer a esta<br />
clase disminuye al hacer las rutas <strong>en</strong>tre las estaciones base más<br />
parecidas.<br />
Figura 7.20 Probabilidad de pert<strong>en</strong><strong>en</strong>cia a la clase 2, e’=10 mseg.<br />
310
Evaluación analítica<br />
Por último la figura 7.21 nos muestra la probabilidad de que el<br />
tiempo que pasa desde que el paquete k-ésimo alcanza la nueva estación<br />
base y llega el paquete ‘Handover Switch Indication’ sea superior a un valor<br />
. Es decir, el tiempo que el paquete permanece almac<strong>en</strong>ado, y que <strong>en</strong> la<br />
ecuación 7.53 hemos d<strong>en</strong>ominado t A . Para la realización de esta figura<br />
hemos tomado un valor ϕ = 40 mseg., mant<strong>en</strong>iéndose los restantes<br />
parámetros con los mismos valores que anteriorm<strong>en</strong>te.<br />
Figura 7.21 Probabilidad de que el paquete k espere un tiempo tA > .<br />
En la figura anterior puede observarse como cuanto m<strong>en</strong>or es el<br />
número del paquete mayor es la posibilidad de esperar tiempos elevados.<br />
Esto sucede simplem<strong>en</strong>te porque llegan antes a nBS y el tiempo de espera<br />
al m<strong>en</strong>saje ‘Handover Switch Indication’ es mayor. Es importante destacar<br />
que, como se mostró <strong>en</strong> las figuras anteriores, no todos los paquetes ti<strong>en</strong><strong>en</strong><br />
la misma probabilidad de pert<strong>en</strong>ecer a la clase 2 y, por tanto, los tiempo de<br />
espera deb<strong>en</strong> ser ponderados por la probabilidad del paquete k-ésimo de<br />
pert<strong>en</strong>ecer a esta clase.<br />
311
Evaluación analítica.<br />
Paquetes pert<strong>en</strong>eci<strong>en</strong>tes a la clase 3.<br />
Los paquetes que pert<strong>en</strong>ec<strong>en</strong> a la clase 3 son aquellos que alcanzan<br />
la nueva estación base <strong>en</strong> un instante posterior a la recepción del m<strong>en</strong>saje<br />
‘Handover Switch Indication’.<br />
Figura 7.22 Probabilidad de pert<strong>en</strong><strong>en</strong>cia a la clase 3.<br />
Como se aprecia <strong>en</strong> la fórmula (7.58), la probabilidad de pert<strong>en</strong>ecer<br />
a esta clase no dep<strong>en</strong>de de la ruta CN-oBS ni, incluso, del retardo fijo d’<br />
exist<strong>en</strong>te <strong>en</strong> la ruta CN-nBS. Por tanto el valor de la constante e’,<br />
indicativa de la difer<strong>en</strong>cia <strong>en</strong>tre las rutas, y parámetro fundam<strong>en</strong>tal para<br />
estudiar la probabilidad de que un paquete k-ésimo pert<strong>en</strong>eciera a una de<br />
las dos clases anteriores, es <strong>en</strong> este caso intransc<strong>en</strong>d<strong>en</strong>te.<br />
La figura 7.22 nos muestra la probabilidad de pert<strong>en</strong><strong>en</strong>cia a la<br />
clase 3 <strong>en</strong> función del retardo ϕ introducido por MN <strong>en</strong> la transmisión del<br />
m<strong>en</strong>saje ‘Handover Switch Indication’. Los valores de los distintos<br />
parámetros utilizados para la realización de la figura son los ya conocidos:<br />
tasa de servicio µ = 10 paquetes por mseg., carga ρ = 0.8 y tiempo medio<br />
<strong>en</strong>tre paquetes <strong>en</strong> CN de 10 mseg.<br />
312
Evaluación analítica<br />
De la gráfica se deduce que, al aum<strong>en</strong>tar ϕ disminuye el número de<br />
paquetes que pert<strong>en</strong>ec<strong>en</strong> a esta clase. Es decir, para un paquete k-ésimo<br />
dado, al aum<strong>en</strong>tar el tiempo ϕ disminuye la probabilidad de que el paquete<br />
pert<strong>en</strong>ezca a esta clase. El motivo es que al retrasar el <strong>en</strong>vío del m<strong>en</strong>saje<br />
‘Handover Switch Indication’ aum<strong>en</strong>ta la probabilidad de que los paquetes<br />
pert<strong>en</strong>ezcan a una de las dos clases anteriores.<br />
Probabilidad conjunta de un paquete k-ésimo.<br />
Para realizar este estudio hemos normalizado con t 2 =0, de manera<br />
que el primer paquete (k=1) es el primero que es dirigido hacia nBS. Por<br />
tanto, cualquier paquete con k ¥ 1 debe pert<strong>en</strong>ecer obligatoriam<strong>en</strong>te a una<br />
de las tres clases estudiadas:<br />
P<br />
k −cl<br />
. 1 Pk<br />
cl.2<br />
+ Pk<br />
cl.3<br />
= 1 ∀k<br />
> 0<br />
+ − −<br />
Las figuras 7.23 y 7.24 nos muestran las probabilidades de<br />
pert<strong>en</strong>ecer a una de las tres clases, fijando todos los parámetros. Como <strong>en</strong><br />
casos anteriores: tasa de servicio µ = 10 paquetes por mseg., carga ρ = 0,8<br />
y tiempo medio <strong>en</strong>tre paquetes <strong>en</strong> CN de 10 mseg. Además tomamos un<br />
valor ϕ = 70 mseg. y una difer<strong>en</strong>cia <strong>en</strong> los retardos a las estaciones base e’<br />
= 30 mseg. <strong>en</strong> la primera figura y e’ = 50 mseg. <strong>en</strong> la segunda.<br />
Observamos como, para cualquier paquete k-ésimo, la suma de las<br />
probabilidades de las tres clases suma 1. Es interesante destacar que la<br />
probabilidad de pert<strong>en</strong>ecer a la clase 3 es indep<strong>en</strong>di<strong>en</strong>te del valor e’.<br />
Sin embargo la probabilidad de pert<strong>en</strong><strong>en</strong>cia a las otras dos clases si<br />
vi<strong>en</strong>e determinado directam<strong>en</strong>te por este calor. Como se aprecia<br />
comparando las dos figuras anteriores al aum<strong>en</strong>tar la difer<strong>en</strong>cia de<br />
retardos <strong>en</strong>tre las dos rutas del router de cruce a las estaciones base (ruta<br />
CN-oBS mayor que CN-nBS) se aum<strong>en</strong>ta la probabilidad de que el paquete<br />
pert<strong>en</strong>ezca a la clase 2 y t<strong>en</strong>ga que esperar <strong>en</strong> la nueva estación antes de<br />
ser transmitido al nodo móvil. El motivo de esto ya se estudió<br />
anteriorm<strong>en</strong>te, indicando que la clase 1, dep<strong>en</strong>de del parámetro ϕ-e’.<br />
313
Evaluación analítica.<br />
Figura 7.23 Suma de probabilidades de las 3 clases. ϕ=70 mseg. e’=30 mseg.<br />
Figura 7.24 Suma de probabilidades de las 3 clases. ϕ=70 mseg. e’=50 mseg.<br />
314
Evaluación analítica<br />
7.4.3 Análisis de la limitación del mecanismo de handover con<br />
Finalización Controlada<br />
En el punto 6.5.2 se com<strong>en</strong>tó como <strong>en</strong> determinadas ocasiones no<br />
es útil utilizar este esquema de handover. Sigui<strong>en</strong>do el mecanismo que se<br />
propuso, es posible que el número del último paquete recibido que el nodo<br />
móvil <strong>en</strong>vía <strong>en</strong> el m<strong>en</strong>saje ‘Handover Switch Indication’ a la nueva estación<br />
base no sea conocido por ésta. El protocolo presupone que si nBS no<br />
conoce este número es debido a que el paquete es previo al primero que<br />
ti<strong>en</strong>e almac<strong>en</strong>ado y re<strong>en</strong>vía todo el buffer.<br />
Así <strong>en</strong> una situación <strong>en</strong> la que el <strong>en</strong>lace nBS-CN es mucho más<br />
l<strong>en</strong>to que el <strong>en</strong>lace oBS-CN el mecanismo anterior fallará. En este caso<br />
puede que el paquete indicado <strong>en</strong> el m<strong>en</strong>saje que <strong>en</strong>vía el MN no haya sido<br />
recibido aún por nBS. nBS supondrá erróneam<strong>en</strong>te que el m<strong>en</strong>saje es<br />
previo a los disponibles <strong>en</strong> su buffer realizando la transmisión total del<br />
mismo. La realidad es que todos esos m<strong>en</strong>sajes almac<strong>en</strong>ados ya han sido<br />
recibidos por el nodo móvil y los va a recibir por duplicado.<br />
La situación estudiada se muestra <strong>en</strong> la figura 7.25, donde se<br />
observa como el m<strong>en</strong>saje que el nodo móvil <strong>en</strong>vía a nBS, para que<br />
comi<strong>en</strong>ce la transmisión de los paquetes almac<strong>en</strong>ados, indica que se<br />
comi<strong>en</strong>ce la transmisión con el paquete 10. Éste todavía está <strong>en</strong> camino y<br />
por tanto, el MN realizará una transmisión de todos los paquetes<br />
almac<strong>en</strong>ados <strong>en</strong> su memoria, de manera que el MN recibirá, por duplicado,<br />
los paquetes 6, 7 y 8.<br />
Como solución se desarrolló un mecanismo que, basándose <strong>en</strong><br />
diversos m<strong>en</strong>sajes, permite al nodo móvil obt<strong>en</strong>er información sobre al red<br />
y decidir el esquema de handover a emplear.<br />
315
Evaluación analítica.<br />
Nodo de<br />
Cruce<br />
11<br />
10<br />
11<br />
9<br />
oBS<br />
nBS<br />
8<br />
7<br />
6<br />
MN<br />
Handover Switch<br />
Indication (10)<br />
Figura 7.25 Funcionami<strong>en</strong>to incorrecto del esquema de handover.<br />
7.4.3.1 Desarrollo analítico<br />
A continuación se realiza un s<strong>en</strong>cillo desarrollo analítico que nos<br />
indica <strong>en</strong> que situaciones el esquema de handover produce el error<br />
com<strong>en</strong>tado anteriorm<strong>en</strong>te.<br />
Según (7.38) el m<strong>en</strong>saje ‘Handover Switch Indication’ con el número<br />
del último paquete recibido alcanza nBS <strong>en</strong> el instante t 5 . La probabilidad<br />
de que se produzca un error se corresponde con la probabilidad de que el<br />
paquete indicado <strong>en</strong> dicho m<strong>en</strong>saje no haya sido aún recibido <strong>en</strong> nBS. En<br />
(7.59) se muestra este error, obt<strong>en</strong>ido a través de la suma de<br />
probabilidades de que el paquete k-ésimo fuera el último <strong>en</strong> alcanzar el<br />
nodo móvil vía oBS, pero que, además, no llegara a nBS antes de la<br />
recepción del m<strong>en</strong>saje ‘Handover Switch Indication’.<br />
∑<br />
∀k<br />
[(<br />
−1)<br />
T + u < t < kT + u] Prob[ ( k −1<br />
T + u > t ]<br />
Prob = Prob<br />
(7.59)<br />
error<br />
k 6 )<br />
7<br />
El desarrollo de la primera probabilidad, que se muestra <strong>en</strong> el<br />
Anexo 2.4, da como resultado:<br />
316
Evaluación analítica<br />
[(<br />
k − 1) T + u < t < kT + ] =<br />
Prob 6 u<br />
1<br />
=<br />
T<br />
T<br />
∫∫<br />
0 0<br />
∞<br />
[ F ( x + u −ϕ<br />
+ e'<br />
+ kT)<br />
− F ( x + u −ϕ<br />
+ e'<br />
+ ( k −1)<br />
T ) f ( x dx du ]<br />
y' o o<br />
Y ' o o<br />
x'<br />
o )<br />
o<br />
o<br />
(7.60)<br />
Con respecto a la segunda probabilidad que aparece <strong>en</strong> la ecuación<br />
(7.59), indicar simplem<strong>en</strong>te que ya fue calculada <strong>en</strong> la ecuación (7.57).<br />
7.4.3.2 Resultados<br />
De la primera probabilidad de la ecuación (7.59) podemos indicar lo<br />
que sigue. Como sabemos, el valor t 6 es directam<strong>en</strong>te proporcional al<br />
parámetro ϕ, e inversam<strong>en</strong>te proporcional al valor de e’. Esto es, al<br />
aum<strong>en</strong>tar ϕ, o disminuir e’, aum<strong>en</strong>ta la probabilidad de que el último<br />
paquete recibido <strong>en</strong> oBS t<strong>en</strong>ga un número más alto.<br />
La segunda probabilidad que aparece <strong>en</strong> la ecuación coincide con<br />
(7.57), y ya se com<strong>en</strong>tó que el único parámetro que le afecta es ϕ, si<strong>en</strong>do<br />
indep<strong>en</strong>di<strong>en</strong>te de la variación de caminos (ver figura 7.22). Esta variación<br />
de la probabilidad <strong>en</strong> función de ϕ comp<strong>en</strong>sa exactam<strong>en</strong>te la variación que<br />
producía este parámetro <strong>en</strong> la primera probabilidad de la ecuación, de<br />
manera que, como se muestra a continuación, el retardo ϕ no afectará a la<br />
probabilidad de que el mecanismo de handover funcione de manera<br />
correcta.<br />
La figura 7.26 muestra la ecuación (7.59), separando ambas<br />
probabilidades. Para su realización hemos mant<strong>en</strong>ido constante la tasa de<br />
servicio µ = 10 paquetes por mseg., la carga ρ = 0,8 y el tiempo medio <strong>en</strong>tre<br />
paquetes <strong>en</strong> CN de 10 mseg. En el eje horizontal se muestra el paquete k-<br />
ésimo. Se ha repres<strong>en</strong>tado los valores de la primera probabilidad de la<br />
ecuación para distintos valores de e’. También se ha repres<strong>en</strong>tado el valor<br />
de la segunda probabilidad que, como se estudió anteriorm<strong>en</strong>te, no<br />
dep<strong>en</strong>de de este parámetro e’. El valor de ϕ permanece también constante<br />
con valor 80 mseg.<br />
317
Evaluación analítica.<br />
Figura 7.26 Desarrollo de la probabilidad total de fallo.<br />
En la figura se observa como al disminuir el valor de e’ la<br />
probabilidad de que el paquete k-ésimo sea el último (primera<br />
probabilidad) se desplaza hacia mayores valores de k. Esta probabilidad<br />
hay que mult<strong>ip</strong>licarla por la segunda probabilidad, de manera que para<br />
algunos valores altos de e’ el producto será 0.<br />
La sigui<strong>en</strong>te figura muestra la probabilidad total, tras hacer el<br />
producto y el sumatorio. Se muestra para un valor de ϕ de 80 mseg., pero<br />
la gráfica es exactam<strong>en</strong>te la misma para cualquier valor de ϕ. Como hemos<br />
com<strong>en</strong>tado, al variar ϕ, las gráficas de la primera probabilidad se<br />
desplazan hacia la derecha, de la misma forma que lo hace la segunda<br />
probabilidad, resultando constante el producto.<br />
El eje horizontal muestra la difer<strong>en</strong>cia de retardos <strong>en</strong>tre los<br />
caminos desde CN hasta cada una de las estaciones base. Mant<strong>en</strong>emos la<br />
terminología de repres<strong>en</strong>tar e’ que se corresponde con [oBS-CN]-[nBS-CN],<br />
de manera que los valores negativos repres<strong>en</strong>tados indican que la ruta a la<br />
estación base nueva es más l<strong>en</strong>ta.<br />
318
Evaluación analítica<br />
Figura 7.27 Probabilidad de fallo <strong>en</strong> el mecanismo de handover.<br />
Como se observa valores negativos del parámetro e’ se traduc<strong>en</strong> <strong>en</strong><br />
que el protocolo no va a funcionar correctam<strong>en</strong>te, mi<strong>en</strong>tras que valores de<br />
e’ positivos hac<strong>en</strong> que el mecanismo funcione bi<strong>en</strong>. Como se ha com<strong>en</strong>tado<br />
la gráfica se obti<strong>en</strong>e exactam<strong>en</strong>te igual indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te del valor del<br />
retardo <strong>en</strong> la transmisión del m<strong>en</strong>saje ‘Multicast Prune Request’ ϕ. Esto es<br />
debido a que al aum<strong>en</strong>tar el retardo aum<strong>en</strong>ta el valor del último paquete<br />
que llega a oBS, pero de la misma manera también aum<strong>en</strong>tan los paquetes<br />
que llegan a nBS impidi<strong>en</strong>do el error.<br />
7.4.4 Conclusiones del handover suave con finalización<br />
controlada<br />
En este punto se ha realizado un análisis del handover Suave con<br />
Finalización Controlada descrito <strong>en</strong> 6.5. Basándonos <strong>en</strong> la capacidad de<br />
comunicación simultanea del nodo móvil, se ha modificado el mecanismo<br />
Semi Suave permiti<strong>en</strong>do al nodo móvil que retrase un tiempo ϕ el <strong>en</strong>vío del<br />
m<strong>en</strong>saje de desconexión. Con este mecanismo permitimos a oBS la<br />
319
Evaluación analítica.<br />
transmisión de los paquetes que están <strong>en</strong> camino o p<strong>en</strong>di<strong>en</strong>tes <strong>en</strong> colas.<br />
Para evitar paquetes duplicados <strong>en</strong> el nodo móvil adicionalm<strong>en</strong>te se ha<br />
añadido la capacidad de que éste indique a nBS el a partir de que paquete<br />
de los almac<strong>en</strong>ados debe empezar su transmisión.<br />
Se ha realizado un análisis de tres aspectos difer<strong>en</strong>tes del<br />
protocolo. Para com<strong>en</strong>zar se ha realizado una evaluación de los paquetes<br />
perdidos utilizado este mecanismo de handover. En el esquema Semi<br />
Suave que se estudió <strong>en</strong> el punto anterior se mostraba como valores<br />
positivos del parámetro e’ (que repres<strong>en</strong>ta la difer<strong>en</strong>cia <strong>en</strong>tre la ruta [CNoBS]<br />
y la ruta [CN-nBS) ) provocaban una pérdida de paquetes. Se ha<br />
demostrado que el retraso del tiempo ϕ <strong>en</strong> el <strong>en</strong>vío del m<strong>en</strong>saje ‘Multicast<br />
Prune Request’ comp<strong>en</strong>sa directam<strong>en</strong>te esta pérdida (figura 7.16).<br />
Los paquetes que son recibidos por nBS no son dirigidos<br />
directam<strong>en</strong>te al nodo móvil. Por el contrario estos se almac<strong>en</strong>an<br />
temporalm<strong>en</strong>te <strong>en</strong> una cola a la espera de recibir el m<strong>en</strong>saje ‘Handover<br />
Switch Indication’, el cual indica a partir de que paquete debe<br />
retransmitirse al nodo móvil. Algunos paquetes serán descartados, pues el<br />
nodo móvil ya los ha recibido vía oBS (clase 1). Otros paquetes sí se<br />
re<strong>en</strong>vían al MN, pero como se recib<strong>en</strong> antes que el m<strong>en</strong>saje ‘Handover<br />
Switch Indication’ sufr<strong>en</strong> un tiempo de espera (clase 2). Finalm<strong>en</strong>te un<br />
tercer grupo de paquetes alcanzan a nBS <strong>en</strong> un instante posterior al<br />
m<strong>en</strong>saje ‘Handover Switch Indication’ y, por tanto, no deb<strong>en</strong> esperar mas<br />
que el tiempo <strong>en</strong> la cola de salida de nBS.<br />
Se ha realizado un análisis de las probabilidades de que un paquete<br />
k-ésimo pert<strong>en</strong>ezca a las tres clases anteriores (figuras 7.18, 7.19 y 7.22),<br />
así como el tiempo que debe esperar un paquete que llega antes del<br />
m<strong>en</strong>saje ‘Handover Switch Indication’, y que debe retransmitirse vía nBS.<br />
Así, la probabilidad de que el paquete llegue vía oBS dep<strong>en</strong>de de la<br />
difer<strong>en</strong>cia ϕ-e’, de manera que al aum<strong>en</strong>tar ésta disminuye la probabilidad<br />
de que el paquete pert<strong>en</strong>ezca a la clase 1. La probabilidad de que el<br />
paquete t<strong>en</strong>ga que esperar por alcanzar nBS antes del m<strong>en</strong>saje de control<br />
de handover (clase 2) dep<strong>en</strong>de de la difer<strong>en</strong>cia de las rutas hasta las dos<br />
320
Evaluación analítica<br />
estaciones base. Al hacer las rutas más difer<strong>en</strong>tes (e’ toma un valor<br />
positivo mayor) aum<strong>en</strong>ta la probabilidad de esperar. Por último la<br />
probabilidad de que el paquete llegue <strong>en</strong> un instante posterior al m<strong>en</strong>saje<br />
de control dep<strong>en</strong>de exclusivam<strong>en</strong>te del parámetro ϕ, de manera que al<br />
aum<strong>en</strong>tar éste disminuye el número de paquetes que pert<strong>en</strong>ec<strong>en</strong> a esta<br />
clase (es decir que pert<strong>en</strong>ec<strong>en</strong> a una las dos clases anteriores). Las figuras<br />
7.23 y 7.24 nos muestran un estudio de la probabilidad conjunta de un<br />
paquete cualquiera.<br />
Para finalizar se ha estudiado como <strong>en</strong> algunas situaciones el<br />
mecanismo de handover propuesto no funciona de manera totalm<strong>en</strong>te<br />
correcta. En concreto, cuando la ruta hacia nBS es mayor que la ruta a<br />
oBS (valor e’ negativo), el protocolo puede fallar de manera que algunos<br />
paquetes son <strong>en</strong>viados desde las dos estaciones base, produciéndose una<br />
duplicación <strong>en</strong> el MN. La probabilidad de que esto suceda se muestra <strong>en</strong> la<br />
figura 7.27.<br />
Como solución a este problema <strong>en</strong> el punto 6.5.2 se diseñó un<br />
mecanismo que permite que el nodo móvil seleccione el esquema de<br />
handover adecuado a la topología de la red. Para ello se modificaron<br />
ligeram<strong>en</strong>te los m<strong>en</strong>sajes ‘Intra-Domain Registration Request’ y ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t’. Así el nodo móvil t<strong>en</strong>dría la información necesaria para<br />
decidir el esquema emplear, de manera que cuando e’ toma un valor<br />
negativo se utilizaría el handover Semi Suave, optándose por el esquema<br />
explicado aquí cuando e’ es cercana a 0 o positiva.<br />
7.5 ESQUEMA DE HANDOVER CON<br />
REDIRECCIONAMIENTO<br />
En el punto 6.6 explicamos el esquema de handover <strong>basado</strong> <strong>en</strong><br />
redireccionami<strong>en</strong>to. Este esquema está p<strong>en</strong>sado, princ<strong>ip</strong>alm<strong>en</strong>te, para<br />
sistemas donde el nodo móvil puede comunicarse con una sola estación<br />
base <strong>en</strong> un instante de tiempo.<br />
321
Evaluación analítica.<br />
Como <strong>en</strong> el ‘Handover Abrupto’ estudiado previam<strong>en</strong>te, el proceso<br />
comi<strong>en</strong>za cuando el MN detecta la necesidad de iniciar el handover y<br />
transmite el ya conocido m<strong>en</strong>saje ‘Intra-Domain Registration Request’ hacia<br />
nBS. Tras la recepción del mismo la nueva estación base se conecta al<br />
árbol <strong>multicast</strong> y, de manera simultanea, se comunica con oBS para<br />
solicitar el redireccionami<strong>en</strong>to de los paquetes p<strong>en</strong>di<strong>en</strong>tes. oBS<br />
transmitirá, por medio de un túnel, los paquetes dirigidos al MN que ti<strong>en</strong>e<br />
todavía almac<strong>en</strong>ados, y se desconectará del árbol <strong>multicast</strong>.<br />
Al ser una handover abrupto existe un tiempo <strong>en</strong> que el nodo móvil<br />
no ti<strong>en</strong>e conexión con oBS, y <strong>en</strong> el que nBS todavía no se ha conectado al<br />
árbol <strong>multicast</strong>. Evid<strong>en</strong>tem<strong>en</strong>te esto se traduce <strong>en</strong> una pérdida de<br />
paquetes. Para solucionar el problema propusimos un almac<strong>en</strong>ami<strong>en</strong>to<br />
temporal de los paquetes <strong>en</strong> oBS, de manera que se manti<strong>en</strong><strong>en</strong> <strong>en</strong><br />
memoria después de haber sido transmitidos por el <strong>en</strong>lace inalámbrico, y<br />
están disponibles para su redireccionami<strong>en</strong>to a nBS.<br />
Para evitar paquetes duplicados <strong>en</strong> el MN, se emplea la misma<br />
solución que la diseñada <strong>en</strong> el esquema anterior, consist<strong>en</strong>te <strong>en</strong> que el<br />
nodo móvil indica, <strong>en</strong> el proceso de registro, el último paquete recibido vía<br />
oBS. De la misma manera nBS almac<strong>en</strong>a el primer paquete recibido del<br />
árbol <strong>multicast</strong>, por lo que rechaza todos los paquetes posteriores a éste<br />
recibidos de oBS. Es decir, los paquetes almac<strong>en</strong>ados <strong>en</strong> el buffer de oBS<br />
se recortan tanto <strong>en</strong> su límite inferior, con la información del último<br />
paquete recibido por MN, como por su parte superior, descartando nBS<br />
todos los paquetes posteriores al primer paquete que recibe por su<br />
incorporación al árbol <strong>multicast</strong>.<br />
Aún con la solución anterior es posible la pérdida de paquetes. Esto<br />
se produce si los paquetes son finalm<strong>en</strong>te descartados <strong>en</strong> oBS antes de ser<br />
re<strong>en</strong>viados a nBS, debido, típicam<strong>en</strong>te, a un desbordami<strong>en</strong>to de la<br />
memoria circular donde se almac<strong>en</strong>an los paquetes recibidos por oBS. A<br />
continuación va a realizarse un análisis del problema.<br />
Por otro lado, según el esquema anterior, durante el handover<br />
algunos paquetes pued<strong>en</strong> alcanzar al NM de manera desord<strong>en</strong>ada. Sin<br />
322
Evaluación analítica<br />
embargo este problema ya lo incorpora la propia naturaleza del protocolo<br />
IP, de manera que, al igual que la demás bibliografía exist<strong>en</strong>te [PER01], no<br />
va a ser solucionado.<br />
7.5.1 Desarrollo analítico<br />
Para analizar el handover con redireccionami<strong>en</strong>to estudiado <strong>en</strong> el<br />
punto 6.6 partimos de la figura 7.1b, que reproducimos a continuación.<br />
Puede apreciarse como se ha incorporado una conexión <strong>en</strong>tre las dos<br />
estaciones base (utilizando un router R3). Así indep<strong>en</strong>dizamos el árbol<br />
<strong>multicast</strong> de la comunicación <strong>en</strong>tre las dos estaciones, puesto que <strong>en</strong><br />
algunas topologías, como la de la figura, el túnel formado para la<br />
retransmisión de los paquetes no ti<strong>en</strong>e por que seguir los <strong>en</strong>laces que<br />
forman el árbol <strong>multicast</strong>.<br />
Se va a realizar el estudio analítico como se hizo <strong>en</strong> esquemas<br />
anteriores, modelando los routers como colas M/M/1. De esta manera el<br />
tiempo de servicio de cada Router Ri estará distribuido expon<strong>en</strong>cialm<strong>en</strong>te,<br />
µ 1− ρ , e incluirá tanto el tiempo de procesami<strong>en</strong>to como el de<br />
con tasa ( )<br />
transmisión.<br />
Nodo de<br />
Cruce CN<br />
R1<br />
R2<br />
oBS<br />
R3<br />
nBS<br />
MN<br />
Figura 7.28 Esquema de la red para el modelado analítico.<br />
323
Evaluación analítica.<br />
Definimos los sigui<strong>en</strong>tes tiempos:<br />
• t ho : instante de tiempo <strong>en</strong> el que comi<strong>en</strong>za el proceso de handover.<br />
Es decir, el instante de tiempo <strong>en</strong> el que el nodo móvil deja de<br />
recibir paquetes de la estación antigua oBS.<br />
• t 1 : instante de tiempo a partir del cual los paquetes que alcanc<strong>en</strong> el<br />
nodo de cruce CN se perderán porque llegarán al nodo móvil<br />
después del instante t ho .<br />
• t 2 : instante de tiempo <strong>en</strong> el que el nodo de cruce recibe, vía nBS, la<br />
información de que nBS desea incorporarse al árbol <strong>multicast</strong>. A<br />
partir de este instante los paquetes serían también re<strong>en</strong>caminados<br />
a nBS, dejándose de perder paquetes.<br />
• t 3 : instante de tiempo <strong>en</strong> el que oBS recibe el m<strong>en</strong>saje de<br />
redireccionami<strong>en</strong>to desde nBS. En ese instante oBS empezará a<br />
retransmitir los paquetes almac<strong>en</strong>ados <strong>en</strong> el buffer que no han sido<br />
recibidos por el nodo móvil.<br />
Sigui<strong>en</strong>do la nom<strong>en</strong>clatura utilizada <strong>en</strong> los análisis anteriores<br />
podemos calcular t 1 , t 2 y t 3 como sigue:<br />
[ CN + CN,<br />
R ) + R + ( R , oBS oBS]<br />
t1 = tho − ( 1 1 1 ) +<br />
(7.61)<br />
t2 = tho + ∆h<br />
+ nBS + ( nBS,<br />
R2<br />
) + R2<br />
+ ( R2,<br />
CN)<br />
(7.62)<br />
t3 = tho + ∆h<br />
+ nBS + ( nBS,<br />
R3<br />
) + R3<br />
+ ( R3,<br />
oBS)<br />
(7.63)<br />
Donde CN, oBS, nBS, R 1 , R 2 y R 3 son variables aleatorias con<br />
función de d<strong>en</strong>sidad de distribución expon<strong>en</strong>cial. ∆ h se corresponde con el<br />
tiempo que le cuesta al nodo móvil detectar que se ha producido el<br />
handover y que ha pasado a dep<strong>en</strong>der de nBS. Hasta ahora ∆ h era una<br />
variable aleatoria con una función de d<strong>en</strong>sidad de distribución uniforme,<br />
sin embargo, con el fin de indep<strong>en</strong>dizar completam<strong>en</strong>te los tiempos t 1 y t 2 ,<br />
<strong>en</strong> este estudio vamos a considerar ∆h<br />
como un valor constante.<br />
324
Evaluación analítica<br />
Como se ha com<strong>en</strong>tado anteriorm<strong>en</strong>te, vamos a c<strong>en</strong>trarnos <strong>en</strong> el<br />
estudio de la pérdida de paquetes durante el handover, que se produce por<br />
desbordami<strong>en</strong>to del buffer <strong>en</strong> la estación antigua oBS. Para que ocurra<br />
esto deb<strong>en</strong> cumplirse todas las sigui<strong>en</strong>tes condiciones:<br />
1. El paquete llega al nodo de cruce CN, <strong>en</strong> un instante anterior a t 2 .<br />
En caso contrario el paquete sería <strong>en</strong>tregado al nodo móvil vía nBS.<br />
2. El paquete alcanza CN después del instante t 1 . Los paquetes que<br />
llegan antes de este tiempo son transmitidos al nodo móvil antes de<br />
t ho , y por tanto se recib<strong>en</strong> correctam<strong>en</strong>te vía oBS.<br />
3. El m<strong>en</strong>saje ‘Multicast Prune Request’, indicativo de que el nodo<br />
móvil dep<strong>en</strong>de ahora de una nueva BS, alcanza oBS (instante t 3 )<br />
cuando el paquete ya no está <strong>en</strong> el buffer circular, debido a que ha<br />
sido sustituido por otro más reci<strong>en</strong>te.<br />
Según estas condiciones la probabilidad de que un paquete se<br />
pierda puede repres<strong>en</strong>tarse como:<br />
Prob<br />
[ Perd. ] Prob[ ( t < t ) AND( t > t ) AND( t + X + c + bT < t )]<br />
= (7.64)<br />
CN<br />
2<br />
CN<br />
1<br />
CN<br />
3<br />
En la ecuación anterior t CN repres<strong>en</strong>ta el instante <strong>en</strong> el que el<br />
paquete llega al nodo de cruce. Como <strong>en</strong> todos los análisis anteriores<br />
suponemos que los paquetes llegan a intervalos constantes de valor T<br />
mseg. Es decir, despreciamos el jitter que puede introducir la red desde el<br />
transmisor al nodo de cruce.<br />
Por otra parte, X es una variable aleatoria suma de las v.a.<br />
CN + R 1 + oBS . Su función de d<strong>en</strong>sidad de distribución (t)<br />
, que ha sido<br />
calculada como la convolución de las d<strong>en</strong>sidades de distribución de los<br />
dispositivos implicados, se corresponde con una distribución de d<strong>en</strong>sidad<br />
Erlang.<br />
f<br />
X<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1 − ρ)<br />
(7.65)<br />
2<br />
f X<br />
325
Evaluación analítica.<br />
Por último, c es un valor constante c = ( CN,<br />
R1 ) + ( R1<br />
, oBS)<br />
y b se<br />
corresponde con el tamaño del buffer medido <strong>en</strong> número de paquetes<br />
almac<strong>en</strong>ables, si<strong>en</strong>do el parámetro que estamos int<strong>en</strong>tando dim<strong>en</strong>sionar.<br />
Para simplificar el desarrollo podemos rescribir las ecuaciones<br />
(7.61), (7.62) y (7.639) defini<strong>en</strong>do variables aleatorias que se correspond<strong>en</strong><br />
con las sumas de los tiempos de proceso de los routers individuales.<br />
[ X c]<br />
t1 = tho − +<br />
(7.66)<br />
t2 = tho + ∆h<br />
+ Y + d<br />
(7.67)<br />
t3 = tho + ∆h<br />
+ Z + e<br />
(7.68)<br />
con<br />
d = ( nBS,<br />
R2 ) + ( R2,<br />
CN)<br />
e = ( nBS,<br />
R3 ) + ( R3,<br />
oBS)<br />
f<br />
f<br />
Y<br />
Z<br />
2<br />
−β<br />
t<br />
( t)<br />
= β te para t ≥ 0 y con β = µ ( 1 − ρ)<br />
2<br />
−β<br />
t<br />
( t)<br />
= β te para t ≥ 0 y con β = µ ( 1 − ρ)<br />
Podemos normalizar el tiempo haci<strong>en</strong>do t ho = 0. En los desarrollos<br />
de los puntos anteriores siempre se normalizaba el tiempo de manera que<br />
el primer paquete susceptible de perderse era el correspondi<strong>en</strong>te a k=0.<br />
Esto se traducía <strong>en</strong> que, <strong>en</strong> el intervalo bajo estudio, el tiempo de llegada<br />
de paquetes era siempre positivo. Sin embargo, <strong>en</strong> esta evaluación hay que<br />
t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta paquetes que se transmit<strong>en</strong> desde CN antes de que se<br />
produzca el instante de handover t ho , y según la normalización empleada,<br />
ahora esto sucede <strong>en</strong> tiempos m<strong>en</strong>ores que 0.<br />
Los tres elem<strong>en</strong>tos que forman parte de la probabilidad que aparece<br />
a la derecha de la ecuación (7.64) podemos escribirlos como:<br />
tCN < t ⇒ tCN<br />
< ∆h<br />
+ Y + d<br />
2<br />
t<br />
CN<br />
> t<br />
1<br />
⇒ t<br />
CN<br />
> −X<br />
− c<br />
326
Evaluación analítica<br />
tCN + X + c + bT < t ⇒ tCN<br />
+ X + c + bT < ∆h<br />
+ Z + e<br />
3<br />
Al haber tomado la v.a ∆h<br />
como un valor constante, el primer<br />
miembro de la parte derecha de la ecuación [7.64] es indep<strong>en</strong>di<strong>en</strong>te de los<br />
otros dos. Así podemos rescribir dicha ecuación como:<br />
Prob<br />
[ Perd. ] = Prob[ t < ∆h<br />
+ Y + d] * Prob[ − X − c < t < ∆h<br />
+ Z + e − X − c − bT ]<br />
CN<br />
CN<br />
(7.69)<br />
La primera probabilidad de la ecuación (7.69) es inmediata:<br />
Prob<br />
[ t ∆h<br />
+ Y + d] = 1 − F ( t − ∆h<br />
− d)<br />
CN<br />
< (7.70)<br />
Y<br />
CN<br />
Con respecto a la segunda:<br />
Prob [ − X − c < t < ∆h<br />
+ Z + e − X − c − bT ]=<br />
CN<br />
= Prob [ 0 < + X + c < ∆h<br />
+ Z + e − bT ]=<br />
t CN<br />
[ 0 < t + X + c < a zo]<br />
=<br />
∫ ∞ Prob CN + f Z ( zo)<br />
dzo<br />
(7.71)<br />
0<br />
con<br />
a = ∆h<br />
+ e − bT<br />
Para que la ecuación anterior t<strong>en</strong>ga s<strong>en</strong>tido ‘a + zo’ ti<strong>en</strong>e que ser<br />
mayor que 0. Así deberemos modificar el límite inferior de la ecuación<br />
anterior quedando finalm<strong>en</strong>te:<br />
∫ ∞<br />
max( 0, −a)<br />
=<br />
∫ ∞<br />
max(0,-a)<br />
Prob<br />
[ − t − c < X < a + zo − t − c]<br />
CN<br />
CN<br />
[ F a + zo − t − c)<br />
− F ( −t<br />
− c)<br />
]<br />
f<br />
Z<br />
( zo)<br />
dzo =<br />
X ( CN<br />
X CN f Z ( zo)<br />
dzo<br />
(7.72)<br />
327
Evaluación analítica.<br />
7.5.2 Resultados<br />
A continuación se muestra el comportami<strong>en</strong>to del esquema de<br />
handover con redireccionami<strong>en</strong>to. Como hemos explicado anteriorm<strong>en</strong>te, el<br />
instante de inicio de handover t ho<br />
ha sido normalizado a 0, de manera que<br />
hay que t<strong>en</strong>er <strong>en</strong> cu<strong>en</strong>ta también paquetes g<strong>en</strong>erados <strong>en</strong> un tiempo t CN<br />
m<strong>en</strong>or que 0. Así partimos de un tiempo sufici<strong>en</strong>tem<strong>en</strong>te negativo, de<br />
manera que, suponi<strong>en</strong>do tasa constante, el paquete k-ésimo alcanzará el<br />
nodo de cruce <strong>en</strong>:<br />
t<br />
− k = −100 + ( k −1<br />
T<br />
(7.73)<br />
CN )<br />
El cálculo del número medio de paquetes perdidos se realiza como:<br />
∑ ∞<br />
k=<br />
1<br />
[ perd., t = −100<br />
+ ( k −1)<br />
T ]<br />
N = Prob CN (7.74)<br />
La figura 7.29 muestra el número de paquetes perdidos <strong>en</strong> función<br />
del tamaño del buffer ‘b’ de la estación base previa Para su realización<br />
hemos mant<strong>en</strong>ido constante el tiempo medio <strong>en</strong>tre paquetes <strong>en</strong> CN, T = 10<br />
mseg, la tasa de servicio µ = 10 paquetes por mseg., la carga ρ = 0.8 y<br />
tiempo para la detección del handover por el nodo móvil ∆ h = 50 mseg. Los<br />
retardos fijos que suman los <strong>en</strong>laces <strong>en</strong>tre CN y las estaciones base,<br />
parámetros ‘c’ y ‘d’ de las ecuaciones (7.66) y (7.67), son, <strong>en</strong> ambos casos,<br />
de 10 mseg. Se ha variado el retardo <strong>en</strong>tre las estaciones oBS y nBS<br />
(parámetro ‘e’ de la ecuación (7.68)), para estudiar la dep<strong>en</strong>d<strong>en</strong>cia de este<br />
factor.<br />
De la figura se comprueba como, evid<strong>en</strong>tem<strong>en</strong>te, al aum<strong>en</strong>tar el<br />
tamaño del buffer disminuy<strong>en</strong> los paquetes perdidos. Además se puede<br />
analizar el funcionami<strong>en</strong>to del esquema <strong>en</strong> función de la distancia<br />
exist<strong>en</strong>te <strong>en</strong>tre las estaciones base (retardos fijos <strong>en</strong> la ruta nBS-oBS). Al<br />
disminuir este valor el m<strong>en</strong>saje de redireccionami<strong>en</strong>to llega antes a oBS,<br />
de manera no se da el tiempo necesario para que se produzca un<br />
desbordami<strong>en</strong>to del buffer, perdiéndose m<strong>en</strong>os paquetes para un tamaño<br />
de buffer dado.<br />
328
Evaluación analítica<br />
Figura 7.29 Paquetes perdidos <strong>en</strong> función del ‘buffer’ de oBS.<br />
Si la ruta <strong>en</strong>tre las dos estaciones base no existiera, el m<strong>en</strong>saje<br />
debería seguir la ruta nBS-CN-oBS que t<strong>en</strong>drá un retardo de 20 mseg + el<br />
tiempo extra de procesami<strong>en</strong>to de los routers adicionales que atraviesa. En<br />
esta situación el comportami<strong>en</strong>to del esquema de handover sería cercano<br />
al de la gráfica con valor e = 25 mseg.<br />
Para comprobar la relación respecto al esquema de handover<br />
abrupto visto <strong>en</strong> el punto 7.2, se ha calculado el número de paquetes<br />
pedidos <strong>en</strong> el caso de no t<strong>en</strong>er buffer y hacer la ruta <strong>en</strong>tre estaciones<br />
(parámetro ‘e’ ) lo sufici<strong>en</strong>tem<strong>en</strong>te elevada para que la pérdida de paquetes<br />
no v<strong>en</strong>ga influ<strong>en</strong>ciada por éste. Bajo estas circunstancias el valor de<br />
paquetes perdidos es de 8, lo que se corresponde con el valor obt<strong>en</strong>ido <strong>en</strong><br />
el handover abrupto (ver figura 7.4).<br />
Por último indicar que el tamaño <strong>en</strong> concreto del buffer ti<strong>en</strong>e una<br />
importancia relativa, ya que se ha obt<strong>en</strong>ido bajo unas determinadas<br />
condiciones. Así si disminuimos el tiempo <strong>en</strong>tre paquetes T, o aum<strong>en</strong>tamos<br />
el tiempo necesario para detectar el handover ∆ h , el tamaño necesario del<br />
buffer para evitar pérdidas aum<strong>en</strong>taría.<br />
329
Evaluación analítica.<br />
7.5.3 Consideraciones finales sobre el Handover con<br />
Redireccionami<strong>en</strong>to<br />
El análisis desarrollado nos demuestra como un dim<strong>en</strong>sionado<br />
adecuado del buffer de oBS permite un handover sin pérdida de paquetes.<br />
La utilización de métodos de re<strong>en</strong>vío de paquetes <strong>en</strong>tre estaciones<br />
base durante el proceso de Handover ya ha sido propuesto <strong>en</strong> la<br />
bibliografía exist<strong>en</strong>te [PER01] y [RAM99]. Sin embargo es interesante<br />
indicar las v<strong>en</strong>tajas que aporta el implem<strong>en</strong>tar este t<strong>ip</strong>o de soluciones <strong>en</strong> el<br />
sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong> que propusimos <strong>en</strong> el<br />
capítulo 3 de esta Tesis.<br />
Según el esquema de direccionami<strong>en</strong>to clásico [PER01], los<br />
paquetes redirigidos por oBS que alcanzan la nueva estación base antes de<br />
que lo haga la respuesta a la petición de registro deb<strong>en</strong> ser descartados.<br />
En [BLO02c] se estudia este hecho, comprobando como una distancia<br />
<strong>en</strong>tre estaciones base m<strong>en</strong>or que la distancia <strong>en</strong>tre el la raíz del dominio y<br />
la nueva estación base provoca este t<strong>ip</strong>o de pérdidas, que empeoran<br />
considerablem<strong>en</strong>te las prestaciones del Handover. Como posibles<br />
soluciones estarían, bi<strong>en</strong> almac<strong>en</strong>ar estos paquetes <strong>en</strong> nBS hasta la<br />
recepción del m<strong>en</strong>saje ‘Registration Reply’, o bi<strong>en</strong> la solución propuesta <strong>en</strong><br />
el esquema Hawaii, donde el <strong>en</strong>vío del m<strong>en</strong>saje de nBS a oBS, necesario<br />
para iniciar el re<strong>en</strong>vío, se <strong>en</strong>camina por la raíz, de manera que siempre es<br />
posterior la retransmisión de los paquetes a la recepción de la respuesta<br />
de registro.<br />
En nuestro esquema de micro-<strong>movilidad</strong> <strong>multicast</strong> el registro de la<br />
nueva estación base se reduce a la incorporación al árbol <strong>multicast</strong> que se<br />
corresponde a la dirección conocida del nodo móvil. Por tanto, nBS está <strong>en</strong><br />
disposición de re<strong>en</strong>viar m<strong>en</strong>sajes al MN <strong>en</strong> cuanto <strong>en</strong>vía el m<strong>en</strong>saje ‘Join’<br />
sin la necesidad de recibir el reconocimi<strong>en</strong>to. Aquí no es necesario la<br />
utilización de buffers <strong>en</strong> nBS aunque, evid<strong>en</strong>tem<strong>en</strong>te, es una opción<br />
posible si se desea transmitirle el m<strong>en</strong>saje de respuesta al registro antes<br />
que ningún paquete re<strong>en</strong>caminado. Este incorporación soluciona,<br />
330
Evaluación analítica<br />
adicionalm<strong>en</strong>te, el problema de duplicación de paquetes que se com<strong>en</strong>ta a<br />
continuación.<br />
7.5.3.1 Posible duplicación de paquetes<br />
A pesar de que <strong>en</strong> nuestro handover con redireccionami<strong>en</strong>to no es<br />
posible una pérdida de paquetes (siempre que el tamaño del buffer de oBS<br />
esté correctam<strong>en</strong>te dim<strong>en</strong>sionado), sí puede darse la circunstancia de que<br />
algunos paquetes llegu<strong>en</strong> duplicados al nodo móvil.<br />
Así, cuando la ruta CN-nBS es comparativam<strong>en</strong>te grande con<br />
respecto a la suma de CN-oBS + oBS-nBS es posible que nBS, antes de<br />
recibir el primer paquete del árbol <strong>multicast</strong>, haya recibido y retransmitido<br />
algunos, o incluso todos, los paquetes prov<strong>en</strong>i<strong>en</strong>tes de oBS. En este caso<br />
algún paquete recibido <strong>en</strong> nBS puede que ya hubiera sido <strong>en</strong>viado al MN<br />
prov<strong>en</strong>i<strong>en</strong>te de la retransmisión de oBS. En un princ<strong>ip</strong>io la nueva estación<br />
base no ti<strong>en</strong>e conocimi<strong>en</strong>to de ello y por tanto el paquete será <strong>en</strong>viado al<br />
nodo móvil por duplicado.<br />
El problema exist<strong>en</strong>te es que el mecanismo está p<strong>en</strong>sado de manera<br />
que el primer paquete prov<strong>en</strong>i<strong>en</strong>te del árbol es utilizado por nBS para<br />
recortar el final de la retrasmisión de oBS. Si el retardo del <strong>en</strong>lace CN-nBS<br />
es mayor que la suma de los retardos CN-oBS + oBS-nBS es posible que<br />
este primer paquete prov<strong>en</strong>i<strong>en</strong>te del árbol se retrase <strong>en</strong> exceso, provocando<br />
la circunstancia com<strong>en</strong>tada.<br />
Exist<strong>en</strong> varias soluciones al respecto. La primera sería lograr que la<br />
ruta CN-nBS fuera m<strong>en</strong>or que la ruta CN-oBS + oBS-nBS. Una opción<br />
para lograr esto es que los paquetes que viajan por el túnel oBS-nBS pas<strong>en</strong><br />
por el nodo de cruce. Evid<strong>en</strong>tem<strong>en</strong>te de esta manera cualquier paquete<br />
prov<strong>en</strong>i<strong>en</strong>te de oBS llega más tarde que el mismo dirigido directam<strong>en</strong>te a<br />
nBS. A difer<strong>en</strong>cia de otros sistemas de micro-<strong>movilidad</strong>, aquí el túnel <strong>en</strong>tre<br />
las dos estaciones se realiza según el <strong>en</strong>rutami<strong>en</strong>to IP, lo que hace<br />
necesario modificar la topología física de la red. Así, <strong>en</strong> el sistema analítico<br />
331
Evaluación analítica.<br />
estudiado, esto equivaldría a eliminar la ruta que pasa por R<br />
3<br />
de la figura<br />
7.28.<br />
Otra solución sería almac<strong>en</strong>ar <strong>en</strong> nBS los paquetes prov<strong>en</strong>i<strong>en</strong>tes de<br />
oBS. Cuando llega el primer paquete del árbol <strong>multicast</strong> podemos<br />
descartar ese y todos los posteriores de los <strong>en</strong>viados desde oBS. La<br />
limitación de esta solución es que necesitamos recursos <strong>en</strong> nBS y que,<br />
además, ral<strong>en</strong>tizamos la <strong>en</strong>trega de los paquetes redirigidos. Esto último<br />
no debería ser un obstáculo, ya que el princ<strong>ip</strong>al objetivo de este<br />
mecanismo de handover es lograr un handover suave (Smooth Handover) y<br />
no un handover rápido.<br />
Por último indicar que <strong>en</strong> el estudio analítico no hemos tratado el<br />
caso de la duplicación de paquetes que detallados aquí. El motivo es que<br />
los problemas que ocasiona el t<strong>en</strong>er retardos inadecuados <strong>en</strong> las rutas CNoBS<br />
y CN-nBS ya han sido evaluados con profundidad <strong>en</strong> el esquema<br />
anterior (punto 7.4.3). Los resultados sobre la degradación de las<br />
prestaciones del handover que se obtuvieron allí son totalm<strong>en</strong>te<br />
extrapolables al esquema de handover con redireccionami<strong>en</strong>to analizado<br />
<strong>en</strong> este punto.<br />
Podemos concluir indicando que un correcto dim<strong>en</strong>sionado de la<br />
memoria de almac<strong>en</strong>ami<strong>en</strong>to temporal de oBS permite un handover Suave,<br />
ver punto 4.4, <strong>en</strong> el que se minimiza la pérdida de paquetes.<br />
Adicionalm<strong>en</strong>te puede incorporarse una memoria similar <strong>en</strong> nBS de<br />
manera que los paquetes redirigidos son almac<strong>en</strong>ados hasta la recepción<br />
del m<strong>en</strong>saje ‘Ack Join’, que confirma la incorporación de la estación al<br />
árbol <strong>multicast</strong>. Este aportación no evitará la posible alteración del ord<strong>en</strong><br />
de los datagramas IP transmitidos, pero si evita el <strong>en</strong>vío duplicado de<br />
paquetes al nodo móvil.<br />
332
Evaluación analítica<br />
7.6 ESQUEMA DE HANDOVER INDIRECTO CON PRE-<br />
REGISTRO<br />
El último esquema de handover propuesto, para el sistema de<br />
micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>, está pesando para int<strong>en</strong>tar ofrecer<br />
un handover rápido <strong>en</strong> sistemas donde el nodo móvil no es capaz de<br />
comunicarse, simultáneam<strong>en</strong>te, con las dos estaciones base implicadas.<br />
Como se describió <strong>en</strong> el punto 6.7, el esquema se basa <strong>en</strong> la<br />
utilización de ‘triggers’ [YEG02], de manera el nodo móvil conoce de<br />
antemano que se va a producir un handover de nivel dos. El esquema es<br />
una adaptación del handover pre-registro que ha sido definido <strong>en</strong> [ELM02],<br />
aunque ha t<strong>en</strong>ido que ser adaptado al sistema de micro-<strong>movilidad</strong><br />
pres<strong>en</strong>tado <strong>en</strong> esta Tesis. Un estudio del esquema original ha sido<br />
realizado, tanto analíticam<strong>en</strong>te como por simulación, <strong>en</strong> [BLO03].<br />
En este esquema el mecanismo que permite a nBS conectarse al<br />
árbol <strong>multicast</strong> comi<strong>en</strong>za antes de que MN t<strong>en</strong>ga una conexión directa con<br />
ella. Para que esto sea posible MN deberá <strong>en</strong>viar el m<strong>en</strong>saje ‘Intra-Domain<br />
Registration Request’ dirigido a nBS a través de oBS. Tras la recepción del<br />
m<strong>en</strong>saje ‘Ack Join’, que confirma la suscr<strong>ip</strong>ción al árbol <strong>multicast</strong><br />
correspondi<strong>en</strong>te al nodo móvil, nBS <strong>en</strong>tregará el paquete de respuesta de<br />
registro <strong>en</strong> cuanto el nodo móvil concluya el handover L2 y, por tanto,<br />
t<strong>en</strong>ga una conexión directa con la nueva estación. La detección de este<br />
hecho se realiza típicam<strong>en</strong>te utilizando un trigger ‘L2-UP’ (ver tabla 4.1).<br />
7.6.1 Desarrollo analítico<br />
Para analizar el handover con pre-registro, descrito <strong>en</strong> el punto 6.7,<br />
partimos de la figura 7.1b, <strong>en</strong> la que se incorporó una conexión <strong>en</strong>tre las<br />
dos estaciones base (utilizando un router R3). Se va a realizar la<br />
evaluación sigui<strong>en</strong>do las mismas consideraciones utilizadas <strong>en</strong> esquemas<br />
anteriores. Es decir, modelamos los routers como colas M/M/1, de esta<br />
manera el tiempo de servicio de cada Router Ri estará distribuido<br />
333
Evaluación analítica.<br />
expon<strong>en</strong>cialm<strong>en</strong>te, con tasa ( 1 ρ)<br />
procesami<strong>en</strong>to como el de transmisión.<br />
µ − , e incluirá tanto el tiempo de<br />
Asumimos que el proceso de handover comi<strong>en</strong>za cuando ocurre el<br />
trigger ‘L2-MT’ <strong>en</strong> el nodo móvil, anunciando la inmin<strong>en</strong>cia del handover a<br />
nivel 2. Definimos este instante como t ho que será, idealm<strong>en</strong>te, el instante<br />
<strong>en</strong> el que el nodo <strong>en</strong>tra <strong>en</strong> la zona de solape. Aunque estamos suponi<strong>en</strong>do<br />
que el handover es iniciado por un trigger <strong>en</strong> el MN, el esquema y la<br />
evaluación son perfectam<strong>en</strong>te válidos si el handover fuera iniciado<br />
mediante un trigger ‘L2-ST’ <strong>en</strong> oBS, ver punto 4.3.<br />
Exist<strong>en</strong> dos tiempos fundam<strong>en</strong>tales para el análisis del handover.<br />
El primero es el instante <strong>en</strong> que el nodo comi<strong>en</strong>za el handover L2 con la<br />
nueva estación base, y se corresponde con el trigger ‘L2-LD’ <strong>en</strong> oBS. El<br />
segundo es el instante <strong>en</strong> que ha finalizado el handover L2 con nBS, de<br />
manera que ya se ti<strong>en</strong>e una conexión directa <strong>en</strong>tre MN y la nueva estación.<br />
Este tiempo se corresponde con un trigger ‘L2-LU’ <strong>en</strong> nBS. D<strong>en</strong>ominamos a<br />
estos dos instantes t LD y t LU respectivam<strong>en</strong>te, de manera que siempre se<br />
cumplirá: t ho < t LD < t LU . El tiempo que transcurre <strong>en</strong>tre t LD y t LU es el<br />
tiempo que dura un handover a nivel 2, y durante ese breve intervalo de<br />
tiempo, evid<strong>en</strong>tem<strong>en</strong>te, el nodo móvil no podrá recibir paquetes.<br />
Para realizar una evaluación de la pérdida que paquetes definimos<br />
también los sigui<strong>en</strong>tes tiempos:<br />
• t 1 : instante de tiempo a partir del cual los paquetes que alcanc<strong>en</strong> el<br />
nodo de cruce CN no llegarán al nodo móvil vía oBS, pues lo harían<br />
después del instante t LD .<br />
• t 2 : instante de tiempo <strong>en</strong> el que el nodo de cruce recibe, vía nBS, la<br />
información de que nBS desea incorporarse al árbol <strong>multicast</strong>. A<br />
partir de este instante los paquetes serían también re<strong>en</strong>caminados<br />
a nBS, de manera que el MN podría recibirlos por esta estación.<br />
Sigui<strong>en</strong>do la nom<strong>en</strong>clatura utilizada <strong>en</strong> los análisis anteriores<br />
podemos calcular t 1 y t 2 como sigue:<br />
334
Evaluación analítica<br />
[ CN + CN,<br />
R ) + R + ( R , oBS oBS]<br />
t1 = tLD − ( 1 1 1 ) +<br />
(7.75)<br />
t2 = tho + oBS + ( oBS,<br />
R3<br />
) + R3<br />
+ ( R3,<br />
nBS)<br />
+ nBS + ( nBS,<br />
R2)<br />
+ R2<br />
+ ( R2,<br />
CN)<br />
(7.76)<br />
Donde CN, oBS, nBS, R 1 , R 2 y R 3 son variables aleatorias con<br />
función de d<strong>en</strong>sidad de distribución expon<strong>en</strong>cial. Es interesante observar<br />
como <strong>en</strong> la ecuación [7.76] se han despreciado el tiempo que transcurre<br />
hasta que oBS recibe el m<strong>en</strong>saje de registro dirigido a nBS. Como se<br />
com<strong>en</strong>tó, los tiempos de transmisión del nodo móvil y de propagación <strong>en</strong> el<br />
<strong>en</strong>lace inalámbrico han sido despreciados <strong>en</strong> todos los análisis de este<br />
capítulo. Además <strong>en</strong> este estudio <strong>en</strong> concreto, hemos despreciado el tiempo<br />
que tarda oBS <strong>en</strong> procesar el m<strong>en</strong>saje “Proxy Ag<strong>en</strong>t Solicitation” (si<br />
existiera), y tiempo de <strong>en</strong>vío del “Proxy Ag<strong>en</strong>t Advertisem<strong>en</strong>t”. El motivo es<br />
que el tiempo de transmisión <strong>en</strong> el <strong>en</strong>lace inalámbrico es mucho m<strong>en</strong>or<br />
que <strong>en</strong> la red fija y, princ<strong>ip</strong>alm<strong>en</strong>te, que dep<strong>en</strong>dería de si el handover es<br />
iniciado por un trigger <strong>en</strong> el nodo móvil o <strong>en</strong> oBS.<br />
Rescribimos las ecuaciones (7.75) y (7.76) defini<strong>en</strong>do variables<br />
aleatorias que se correspond<strong>en</strong> con las sumas de los tiempos de proceso de<br />
los routers individuales.<br />
[ X c]<br />
t1 = t LD − +<br />
(7.77)<br />
t2 = tho + W + g<br />
(7.78)<br />
con<br />
c = ( CN,<br />
R1 ) + ( R1<br />
, oBS)<br />
g = ( oBS,<br />
R3 ) + ( R3,<br />
nBS)<br />
+ ( nBS,<br />
R2<br />
) + ( R2,<br />
CN)<br />
f<br />
X<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
335
Evaluación analítica.<br />
f<br />
W<br />
4 3<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
3!<br />
A continuación vamos a analizar tanto las posibles pérdidas de<br />
paquetes, como la probabilidad de que el nodo móvil reciba paquetes por<br />
duplicado.<br />
7.6.1.1 Paquetes perdidos<br />
Con el fin de acelerar el proceso de handover, este esquema se basa<br />
<strong>en</strong> la utilización de triggers que permit<strong>en</strong> adelantar el proceso de registro<br />
que provoca la incorporación de nBS al árbol <strong>multicast</strong>. Aún así es fácil<br />
<strong>en</strong>t<strong>en</strong>der que un paquete se perderá si alcanza el nodo de cruce antes de<br />
que lo haga el m<strong>en</strong>saje ‘Join’ de nBS, y después del instante t 1 que marca<br />
el límite de los paquetes que pued<strong>en</strong> <strong>en</strong>tregarse vía oBS:<br />
Prob<br />
[ perd. ] Pr ob[ t < tCN < t ]<br />
= (7.79)<br />
1<br />
2<br />
Podemos normalizar el tiempo haci<strong>en</strong>do t ho = 0 . Es decir el tiempo<br />
comi<strong>en</strong>za <strong>en</strong> el mom<strong>en</strong>to <strong>en</strong> que se produce el trigger <strong>en</strong> el nodo móvil. Así<br />
el valor t LD se corresponderá, también, con el tiempo transcurrido desde<br />
que sucede el trigger <strong>en</strong> el nodo móvil y éste comi<strong>en</strong>za el proceso de<br />
handover L2.<br />
Los paquetes alcanzan el nodo de cruce a intervalos fijos T.<br />
Dep<strong>en</strong>di<strong>en</strong>do del tiempo <strong>en</strong> que el nodo móvil comi<strong>en</strong>za el handover L2, es<br />
posible (aunque improbable) que algún paquete g<strong>en</strong>erado antes de t ho sea<br />
de interés <strong>en</strong> el análisis que estamos realizando. Para no limitar de<br />
ninguna forma el tiempo mínimo de t LD com<strong>en</strong>zamos el estudio de los<br />
paquetes que llegan <strong>en</strong> un tiempo negativo. Así los instantes t CN <strong>en</strong> que<br />
los paquetes alcanzan el nodo de cruce los podemos escribir como:<br />
t CN = −30 + ( k −1)<br />
T + u<br />
(7.80)<br />
336
Evaluación analítica<br />
Para eliminar cualquier dep<strong>en</strong>d<strong>en</strong>cia con el instante <strong>en</strong> que se<br />
produce el handover, el instante <strong>en</strong> que llega el paquete ti<strong>en</strong>e un<br />
compon<strong>en</strong>te aleatorio, u, uniformem<strong>en</strong>te distribuido <strong>en</strong>tre [0,T].<br />
Como los tiempos t 1 y t 2 son indep<strong>en</strong>di<strong>en</strong>tes, la ecuación (7.79) es<br />
fácilm<strong>en</strong>te desarrollable. Así la probabilidad de que el paquete k-ésimo se<br />
pierda la podemos escribir como:<br />
P<br />
[ t < t ]*<br />
[ t t ]<br />
perd − k<br />
= Prob<br />
1 CN −k<br />
Prob<br />
CN −k<br />
<<br />
2<br />
(7.81)<br />
Sustituy<strong>en</strong>do (7.77) y (7.78) <strong>en</strong> la ecuación anterior, y<br />
desarrollando como lo hemos hecho <strong>en</strong> análisis anteriores, las dos<br />
probabilidades nos quedan finalm<strong>en</strong>te:<br />
Prob 1<br />
[ t < t − ] = Prob[ t − X − c < −30<br />
+ ( k −1<br />
T + u]=<br />
CN k<br />
LD<br />
)<br />
1 T<br />
=<br />
∫<br />
Prob[ tLD<br />
− X − c < −30<br />
+ ( k −1)<br />
T + uo]<br />
duo =<br />
T 0<br />
1 T<br />
FX<br />
tCN<br />
k uo c t<br />
T ∫<br />
1−<br />
( − − +<br />
0<br />
= − _ LD )<br />
duo<br />
(7.82)<br />
[ t < t ] = Prob[ − 30 + ( k −1<br />
T + u < W + g]=<br />
Prob 2<br />
CN −k<br />
)<br />
1 T<br />
=<br />
∫<br />
Prob[ − 30 + ( k −1)<br />
T + uo < W + g]<br />
duo =<br />
T 0<br />
1 T<br />
= FW<br />
tCN<br />
T ∫<br />
1−<br />
( −<br />
0<br />
− g duo<br />
k _ uo )<br />
(7.83)<br />
Adicionalm<strong>en</strong>te a la perdida de paquetes analizada anteriorm<strong>en</strong>te<br />
existe otra posible fu<strong>en</strong>te de pérdidas. Una vez nBS se ha conectado al<br />
árbol <strong>multicast</strong> comi<strong>en</strong>za a recibir paquetes dirigidos hacia MN. Si el nodo<br />
móvil no ha finalizado el handover L2, esos paquetes que alcanzan nBS no<br />
podrán ser transmitidos y deberán ser descartados.<br />
337
Evaluación analítica.<br />
D<strong>en</strong>ominamos t 3 al instante de tiempo a partir del cual los<br />
paquetes que alcanc<strong>en</strong> el nodo de cruce CN podrían llegar al nodo móvil<br />
vía nBS, pues lo harán después del instante t LD .<br />
[ CN + CN,<br />
R ) + R + ( R , nBS nBS]<br />
t = t LU −<br />
) +<br />
3 ( 2 2 2<br />
=<br />
= − Y − d<br />
(7.84)<br />
t LU<br />
con<br />
d = ( CN,<br />
R2 ) + ( R2<br />
, nBS)<br />
f<br />
Y<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
Así, la probabilidad de que un paquete se descarte es:<br />
P<br />
Prob[ t < t < t ]=<br />
descartar −k<br />
= 2 CN −k<br />
3<br />
[ t < t ]*<br />
[ t t ]<br />
= Prob 2 CN − k Prob CN −k<br />
< 3<br />
(7.85)<br />
Finalm<strong>en</strong>te el paquete k-ésimo se perderá por este motivo<br />
solam<strong>en</strong>te si el paquete es descartado <strong>en</strong> nBS (7.85), pero si, además, ese<br />
paquete no es recibido por el nodo móvil vía oBS. Ya que los instantes t 1 ,<br />
t 2 y t 3 son indep<strong>en</strong>di<strong>en</strong>tes, la probabilidad de que el paquete se pierda es:<br />
P<br />
[ t < t ]* Prob[ t < t ]*<br />
[ t t ]<br />
perd − k = Prob 2 CN −k<br />
CN −k<br />
3 Prob CN −k<br />
> 1<br />
(7.86)<br />
Las tres probabilidades de la ecuación anterior son inmediatas:<br />
Prob 2<br />
[ t t ] = Prob[ W + g < t ]=<br />
< CN −k<br />
CN −k<br />
1 T<br />
= FW<br />
tCN<br />
T ∫<br />
( −<br />
0<br />
− g duo<br />
k _ uo )<br />
(7.87)<br />
[ t t ] = Prob[ t < t − Y − d ]=<br />
Prob CN −k<br />
< 3<br />
CN −k<br />
1<br />
T<br />
LU<br />
T<br />
=<br />
∫<br />
−<br />
0<br />
FY ( t LU − tCN<br />
k _ uo − d)<br />
duo<br />
(7.88)<br />
338
Evaluación analítica<br />
[ t t ] = Prob[ t > t − X − c]=<br />
Prob CN −k<br />
> 1<br />
CN −k<br />
1<br />
=<br />
T<br />
∫<br />
0<br />
T<br />
(1 − F<br />
X<br />
LD<br />
( t<br />
LD<br />
− c − t<br />
CN −k<br />
_ uo )) duo<br />
(7.89)<br />
7.6.1.2 Paquetes duplicados<br />
El sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> <strong>multicast</strong>, favorece la<br />
<strong>en</strong>trega de paquetes sin pérdidas, ya que, durante parte del tiempo que<br />
dura el handover, las dos estaciones base implicadas están conectadas de<br />
manera simultánea al árbol <strong>multicast</strong>. Pero por este mismo motivo, sin<br />
embargo, el sistema ti<strong>en</strong>e el inconv<strong>en</strong>i<strong>en</strong>te de que se favorece la<br />
duplicación de paquetes <strong>en</strong> el nodo móvil.<br />
En este esquema <strong>en</strong> particular el nodo móvil recibirá un paquete<br />
duplicado si se cumpl<strong>en</strong> las sigui<strong>en</strong>tes tres condiciones:<br />
• El paquete se transmite desde CN <strong>en</strong> un instante anterior a t 1 , de<br />
manera que es recibido por MN vía oBS.<br />
• El paquete es g<strong>en</strong>erado después de t 2 , de marea que es transmitido<br />
también a nBS<br />
• El paquete es g<strong>en</strong>erado después de t 3 , de manera que no es<br />
descartado por nBS.<br />
Es decir:<br />
[ dupl. ] Pr ob [(<br />
t < t ) AND(<br />
t > t ) AND(<br />
t )]<br />
Prob = CN − k 1 CN −k<br />
2 CN −k<br />
> t3<br />
(7.90)<br />
Como ya se ha com<strong>en</strong>tado los tiempos t 1 , t 2 y t 3 son indep<strong>en</strong>di<strong>en</strong>te<br />
de manera que la ecuación anterior queda:<br />
Prob<br />
[ dupl. ] Pr ob[ t < t ]* Pr ob[ t > t ]* Pr [ t t ]<br />
= CN − k 1 CN −k<br />
2 ob CN −k<br />
> 3<br />
(7.91)<br />
339
Evaluación analítica.<br />
Las tres probabilidades de la ecuación anterior son inmediatas:<br />
[ t t ] = Prob[ t < t − X − c]=<br />
Prob CN −k<br />
< 1<br />
CN −k<br />
LD<br />
1<br />
=<br />
T<br />
∫<br />
0<br />
T<br />
F<br />
X<br />
( t<br />
LD<br />
− c − t<br />
CN −k<br />
_ uo )<br />
duo<br />
(7.92)<br />
[ t t ] = Pr ob[ t > W + g]=<br />
Pr ob CN −k<br />
> 2<br />
CN −k<br />
1<br />
T<br />
T<br />
=<br />
∫<br />
−<br />
0<br />
FW ( tCN<br />
k _ uo − g)<br />
duo<br />
(7.93)<br />
[ t t ] = Pr ob[ t > t − Y − d]=<br />
Pr ob CN −k<br />
> 3<br />
CN −k<br />
1<br />
T<br />
LU<br />
T<br />
=<br />
∫<br />
−<br />
0<br />
(1 − FY ( t LU − tCN<br />
k _ uo − d))<br />
duo<br />
(7.94)<br />
7.6.2 Resultados<br />
Com<strong>en</strong>zamos con la evaluación de los paquetes perdidos. La figura<br />
7.30 muestra el número de paquetes perdidos <strong>en</strong> función del instante de<br />
tiempo t LD . Hemos mant<strong>en</strong>ido constante el tiempo medio <strong>en</strong>tre paquetes<br />
<strong>en</strong> CN, T = 10 mseg, la tasa de servicio µ = 10 paquetes por mseg. y la<br />
carga ρ = 0.8. Los retardos fijos que suman los <strong>en</strong>laces <strong>en</strong>tre el nodo de<br />
cruce y oBS, parámetro ‘c’ ecuación (7.77), es de 10 mseg. Se ha variado el<br />
retardo <strong>en</strong>tre las estaciones oBS y nBS (que forma parte del parámetro ‘g’<br />
de la ecuación (7.78)), para estudiar la dep<strong>en</strong>d<strong>en</strong>cia de este factor.<br />
En la figura observamos como el número de paquetes perdidos es<br />
nulo cuando el valor del tiempo t LD<br />
toma valores superiores a 60 mseg.<br />
Recordemos que estamos normalizando <strong>en</strong> el instante <strong>en</strong> que se produce el<br />
trigger ‘L2-MT’ <strong>en</strong> el nodo móvil t = 0 , por lo que le eje horizontal de la<br />
ho<br />
gráfica también puede ser <strong>en</strong>t<strong>en</strong>dido como la difer<strong>en</strong>cia de tiempo desde<br />
que el nodo móvil detecta que se va a producir un handover hasta que,<br />
finalm<strong>en</strong>te, pierde la conexión con oBS.<br />
340
Evaluación analítica<br />
Figura 7.30 Número medio de paquetes perdidos <strong>en</strong> función del trigger ‘L2-LD’.<br />
En la figura anterior también observamos la dep<strong>en</strong>d<strong>en</strong>cia con la<br />
ruta oBS-nBS-CN. Suponemos que mant<strong>en</strong>emos constante el valor del<br />
retardo nBS-CN <strong>en</strong> 10 mseg., que coincide con el retardo oBS-CN. La<br />
gráfica nos muestra tres situaciones con distintos retardos oBS-nBS: 4, 10<br />
y 30 mseg. Los retardos de 4 y 10 mseg. nos permit<strong>en</strong> estudiar el<br />
comportami<strong>en</strong>to cuando las dos estaciones base están conectadas<br />
directam<strong>en</strong>te, mi<strong>en</strong>tras que la situación <strong>en</strong> el que el retardo es de 30 mseg.<br />
int<strong>en</strong>ta simular el comportami<strong>en</strong>to <strong>en</strong> el caso de que la ruta <strong>en</strong>tre las dos<br />
estaciones no existiera y los m<strong>en</strong>sajes tuvieran que pasar por el nodo de<br />
cruce. Es fácil deducir que rutas más pequeñas permit<strong>en</strong> que el registro de<br />
nBS <strong>en</strong> el árbol se realice más rápidam<strong>en</strong>te, disminuy<strong>en</strong>do la pérdida de<br />
paquetes.<br />
La figura 7.31 nos muestra la pérdida de paquetes que puede<br />
suceder <strong>en</strong> caso de que los paquetes sean recibidos <strong>en</strong> nBS antes de que<br />
se haya finalizado el handover de nivel 2. Para la realización de la figura se<br />
ha partido de la ecuación (7.86), y se han mant<strong>en</strong>ido constantes los<br />
sigui<strong>en</strong>tes valores: retardos CN-oBS y oBS-nBS de 10 mseg., tiempo medio<br />
341
Evaluación analítica.<br />
<strong>en</strong>tre paquetes <strong>en</strong> CN T = 10 mseg., y los valores que defin<strong>en</strong> los routers<br />
que los utilizados <strong>en</strong> las gráficas anteriores.<br />
El eje horizontal de la gráfica nos muestra le difer<strong>en</strong>cia <strong>en</strong>tre los<br />
tiempos t LU − t LD , es decir, el eje nos muestra el tiempo necesario para<br />
realizar el handover de capa 2. En particular se ha ido variando el valor<br />
t LU , mi<strong>en</strong>tras el valor t LD se ha mant<strong>en</strong>ido constante con valor 60 mseg.<br />
Este valor ha sido elegido ya que según la figura 7.30 aseguraba que no se<br />
perdieran paquetes por no detectar el handover con la antelación<br />
sufici<strong>en</strong>te. Sin embargo, otros valores de este tiempo no modificarían la<br />
figura.<br />
Figura 7.31 Paquetes perdidos <strong>en</strong> función del tiempo de handover L2.<br />
En la gráfica se observa que el número de paquetes perdidos<br />
aum<strong>en</strong>ta al aum<strong>en</strong>tar la duración del handover de capa 2. Como hemos<br />
analizado los paquetes que llegan antes de que el handover se complete<br />
deb<strong>en</strong> ser descartados. Puede observarse como al aum<strong>en</strong>tar el retardo de<br />
la ruta CN-nBS, parámetro ‘d’, disminuy<strong>en</strong> las pérdidas. Simplem<strong>en</strong>te se<br />
logra que los paquetes estén más tiempo de camino a nBS, dando tiempo a<br />
que el handover L2 se complete.<br />
342
Evaluación analítica<br />
La solución a estas perdidas puede lograrse añadi<strong>en</strong>do un buffer <strong>en</strong><br />
la nueva estación base. Así los paquetes que alcanzan la nueva estación<br />
base son almac<strong>en</strong>ados a la espera del trigger ‘L2-LU’. El tamaño necesario<br />
del buffer dep<strong>en</strong>dería, obviam<strong>en</strong>te, de la tasa a la que los paquetes son<br />
transmitidos (parámetro T).<br />
Ya se ha analizado como la utilización de soluciones <strong>multicast</strong><br />
conlleva la posibilidad de que algunos paquetes llegu<strong>en</strong> duplicados al nodo<br />
móvil. La figura 7.32 muestra el número medio de paquetes duplicados,<br />
realizada a partir de la ecuación (7.91). En ella las rutas CN-oBS, CN-nBS<br />
y oNS-nBS ti<strong>en</strong><strong>en</strong> un retardo fijo de 10 mseg., y los restantes parámetros<br />
toman los mismos valores que los utilizados <strong>en</strong> la figura anterior.<br />
Figura 7.32 Paquetes duplicados <strong>en</strong> función del tiempo de handover L2.<br />
Puede observarse como la probabilidad de que se dupliqu<strong>en</strong><br />
paquetes es prácticam<strong>en</strong>te nula. Al descartar nBS los paquetes que llegan<br />
antes de t LU<br />
, los paquetes duplicados deb<strong>en</strong> llegar a oBS antes de t LD y a<br />
. Como las rutas <strong>en</strong>tre CN y las estaciones base ti<strong>en</strong><strong>en</strong><br />
nBS después de t LU<br />
el mismo retardo fijo, y siempre se va a cumplir que<br />
probabilidad de que se produzcan limitaciones es mínima.<br />
t LU<br />
> t LD<br />
, la<br />
343
Evaluación analítica.<br />
Sin embargo, podríamos p<strong>en</strong>sar <strong>en</strong> almac<strong>en</strong>ar los paquetes que le<br />
llegan a nBS con el fin de que no se produjeran las pérdidas de paquetes<br />
que se mostraron <strong>en</strong> la figura 7.31. En este caso la duplicación de<br />
paquetes ya no dep<strong>en</strong>derá del instante t LU , sino del instante de tiempo<br />
t2<br />
<strong>en</strong> el que la nueva estación base se une al grupo <strong>multicast</strong>.<br />
La figura 7.33 nos muestra el comportami<strong>en</strong>to del esquema de<br />
handover <strong>en</strong> esta situación. La gráfica se ha realizado eliminando el último<br />
término de la ecuación (7.91). El valor del retardo CN-oBS se ha mant<strong>en</strong>ido<br />
constante <strong>en</strong> 10 mseg., y se ha variado el retardo de la ruta oBS-nBS-CN.<br />
Figura 7.33 Paquetes duplicados <strong>en</strong> función del trigger ‘L2-LD’.<br />
En la gráfica anterior se observa claram<strong>en</strong>te como, <strong>en</strong> caso de<br />
almac<strong>en</strong>ar paquetes <strong>en</strong> nBS para evitar pérdidas, se producirá una<br />
duplicación de paquetes que dep<strong>en</strong>derá tanto del instante t LD como del<br />
retardo ‘g’.<br />
Anteriorm<strong>en</strong>te observamos como el valor del instante t LD equivalía<br />
al tiempo <strong>en</strong> el que adelantábamos el proceso de registro de la nueva<br />
estación base al inicio del handover L2. Así al aum<strong>en</strong>tar este tiempo<br />
344
Evaluación analítica<br />
favorecemos que nBS se una antes al árbol <strong>multicast</strong> y por tanto que<br />
empiece la retransmisión de paquetes. De la misma manera, al disminuir<br />
el retardo que sufre la conexión al árbol <strong>multicast</strong>, favorecemos que se una<br />
antes y, por tanto, que se retransmitan más paquetes que terminarán<br />
duplicados <strong>en</strong> el nodo móvil.<br />
7.6.3 Conclusiones del handover indirecto con pre-registro<br />
En este punto hemos evaluado el proceso de handover cuando el<br />
nodo móvil, basándose <strong>en</strong> la utilización de triggers, adelanta el proceso de<br />
incorporación de nBS al árbol <strong>multicast</strong> al desarrollo del handover de capa<br />
2.<br />
Hemos observado como la pérdida de paquetes puede producirse <strong>en</strong><br />
dos situaciones bi<strong>en</strong> difer<strong>en</strong>ciadas. La primera es cuando el trigger ‘L2-MT’<br />
no se produce con sufici<strong>en</strong>te antelación a la pérdida de conexión con oBS<br />
(inicio del handover L2). La figura 7.30 nos muestra estas pérdidas que<br />
dep<strong>en</strong>d<strong>en</strong>, además, de la topología de la red.<br />
La segunda situación que ocasiona una pérdida de paquetes es<br />
cuando el handover L2 tarda demasiado <strong>en</strong> completarse. En este caso nBS<br />
no puede <strong>en</strong>tregar los nuevos paquetes que está recibi<strong>en</strong>do para el nodo<br />
móvil, por lo que ti<strong>en</strong>e que despreciarlos (figura 7.31). La solución a este<br />
problema consistiría <strong>en</strong> disponer de un buffer <strong>en</strong> la estación que<br />
almac<strong>en</strong>ara estos paquetes, con el fin de que puedan ser <strong>en</strong>tregados <strong>en</strong><br />
cuanto el handover se complete.<br />
Finalm<strong>en</strong>te se ha estudiado como, debido a la utilización de<br />
tecnologías <strong>multicast</strong>, es posible la duplicación de paquetes. En particular<br />
la duplicación sólo se va a producir <strong>en</strong> caso de que optemos por incluir el<br />
buffer <strong>en</strong> nBS para evitar la pérdida de paquetes com<strong>en</strong>tada, figura 7.33, y<br />
es proporcional al tiempo de adelanto del trigger ‘L2-MT’. Analizando<br />
conjuntam<strong>en</strong>te las figuras 7.30 y 7.33 podemos concluir dici<strong>en</strong>do que un<br />
diseño cuidadoso de la topología de la red, o un control del tiempo de inicio<br />
345
Evaluación analítica.<br />
de los mecanismos de handover de ambas capas, nos van a permitir que el<br />
esquema de handover se realice de manera rápida y sin pérdidas.<br />
7.7 CONCLUSIONES DEL CAPÍTULO<br />
En este capítulo se han evaluado, analíticam<strong>en</strong>te, los cinco<br />
esquemas de handover que se propusieron para el sistema de micro<strong>movilidad</strong><br />
<strong>basado</strong> <strong>en</strong> <strong>multicast</strong>.<br />
Se han modelado los routers de forma s<strong>en</strong>cilla, asumi<strong>en</strong>do que se<br />
comportan como colas M/M/1, de manera que el tiempo de servicio de un<br />
paquete está distribuido expon<strong>en</strong>cialm<strong>en</strong>te e incluye el tiempo de<br />
procesami<strong>en</strong>to y el de transmisión [BLO02], [BLO02b]. El objetivo es<br />
analizar las v<strong>en</strong>tajas de utilizar uno u otro esquema, <strong>en</strong> función del<br />
número de paquetes perdidos, tiempo de interrupción o tiempo de espera<br />
<strong>en</strong> ‘buffers’. A la vez hemos evaluado como afecta a las prestaciones del<br />
esquema de handover la modificación de distintos parámetros, como puede<br />
ser la topología de la red.<br />
Se ha partido del esquema más s<strong>en</strong>cillo, d<strong>en</strong>ominado ‘Handover<br />
Abrupto’. Hemos comprobado la relación directa del número de paquetes<br />
perdidos con la distancia (medida <strong>en</strong> términos de retardo) exist<strong>en</strong>te <strong>en</strong>tre<br />
las estaciones y el nodo de cruce, que es el nodo que conectará nBS al<br />
árbol <strong>multicast</strong>. También se ha comprobado como, al ser un handover<br />
abrupto, el tiempo <strong>en</strong> el que el nodo necesita para detectar la conexión a la<br />
nueva estación ti<strong>en</strong>e vital importancia. Éste vi<strong>en</strong>e determinado,<br />
fundam<strong>en</strong>talm<strong>en</strong>te, por la frecu<strong>en</strong>cia de <strong>en</strong>vío de m<strong>en</strong>sajes ‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t’ desde nBS.<br />
Con el fin de mejorar las prestaciones del esquema anterior se<br />
propusieron dos esquemas alternativos, también diseñados para sistemas<br />
donde el nodo móvil no es capaz de comunicarse simultáneam<strong>en</strong>te con las<br />
dos estaciones base implicadas <strong>en</strong> el handover.<br />
346
Evaluación analítica<br />
El primero, d<strong>en</strong>ominado ‘Handover con Redirecionami<strong>en</strong>to’, logra<br />
un handover suave a base de almac<strong>en</strong>ar temporalm<strong>en</strong>te los últimos<br />
paquetes que las estaciones <strong>en</strong>vían a los nodos móviles. Así, si se produce<br />
un handover, esos paquetes pued<strong>en</strong> ser retransmitidos a la nueva<br />
estación, evitando la pérdida <strong>en</strong> caso de no hubieran sido recibidos por el<br />
MN.<br />
Se ha estudiado el tamaño necesario de los ‘buffers’ de<br />
almac<strong>en</strong>ami<strong>en</strong>to, que evitan la pérdida de paquetes por desbordami<strong>en</strong>to.<br />
En este s<strong>en</strong>tido un tamaño debe ser consecu<strong>en</strong>te con el número medio de<br />
paquetes perdidos <strong>en</strong> el esquema abrupto. Además se ha comprobado<br />
como la distancia <strong>en</strong>tre las estaciones base afecta negativam<strong>en</strong>te al<br />
comportami<strong>en</strong>to del esquema.<br />
A pesar de que un correcto dim<strong>en</strong>sionado de los ‘buffers’ elimina la<br />
posibilidad de pérdida de paquetes, es posible que el nodo móvil reciba<br />
paquetes duplicados. Esto se produce cuando la ruta CN-oBS es<br />
comparativam<strong>en</strong>te grande <strong>en</strong> relación a la ruta CN-oBS-nBS. En este caso<br />
se ha comprobado como paquetes redirigidos desde oBS a nBS han sido<br />
<strong>en</strong>tregados por la nueva estación de manera duplicada. La solución<br />
propuesta ha sido realizar un almac<strong>en</strong>ami<strong>en</strong>to temporal de los paquetes<br />
redirigidos <strong>en</strong> nBS hasta que se recibe el primer paquete vía CN. Esta<br />
solución es empleada, aunque por otros motivos, <strong>en</strong> la bibliografía<br />
[PER01]. En caso de no disponer de esta capacidad de almac<strong>en</strong>ami<strong>en</strong>to, la<br />
duplicación de paquetes <strong>en</strong> este esquema dep<strong>en</strong>dería directam<strong>en</strong>te<br />
topología de la red.<br />
La segunda propuesta para mejorar las prestaciones del handover<br />
abrupto es el d<strong>en</strong>ominado ‘Handover Indirecto con pre-registro’. Este<br />
esquema se basa <strong>en</strong> la utilización de ‘triggers’ para disminuir el tiempo <strong>en</strong><br />
el que el nodo no ti<strong>en</strong>e conexión con las estaciones base. La idea básica es<br />
que si conozco con sufici<strong>en</strong>te antelación que se va a producir un handover<br />
<strong>en</strong> la capa dos puedo adelantar el proceso de conexión de la nueva<br />
estación base al árbol <strong>multicast</strong>.<br />
347
Evaluación analítica.<br />
En este esquema se han detectado y evaluado dos situaciones <strong>en</strong><br />
las que pued<strong>en</strong> producirse una pérdida de paquetes. La primera es la<br />
misma situación que ocurre <strong>en</strong> el handover abrupto. Si no conocemos con<br />
sufici<strong>en</strong>te antelación que va a producirse un handover no habrá tiempo de<br />
que se realice el handover <strong>en</strong> la capa tres, y habrá un tiempo de<br />
interrupción <strong>en</strong> el que se perderán paquetes. Se ha evaluado esta pérdida<br />
concluy<strong>en</strong>do que hac<strong>en</strong> falta valores de tiempo de antelación <strong>en</strong> torno a los<br />
60 mseg. para las condiciones utilizadas <strong>en</strong> todo este capítulo.<br />
La segunda fu<strong>en</strong>te de error se produce cuando el handover de capa<br />
dos ti<strong>en</strong>e una duración excesiva de manera que los paquetes que llegan a<br />
nBS dirigidos al MN no pued<strong>en</strong> ser <strong>en</strong>tregados. Se ha propuesto la<br />
utilización de ‘buffers’ de almac<strong>en</strong>ami<strong>en</strong>to temporal para solv<strong>en</strong>tar el<br />
problema.<br />
Un problema derivado de la utilización de tecnología <strong>multicast</strong> es<br />
que es más probable que se d<strong>en</strong> situaciones que provoqu<strong>en</strong> una<br />
duplicación de paquetes <strong>en</strong> el nodo móvil. En este esquema la duplicación<br />
se produce <strong>en</strong> el caso del almac<strong>en</strong>ami<strong>en</strong>to de paquetes <strong>en</strong> nBS com<strong>en</strong>tado<br />
anteriorm<strong>en</strong>te. Se ha analizado conjuntam<strong>en</strong>te las prestaciones del<br />
esquema concluy<strong>en</strong>do que una adecuada relación <strong>en</strong>tre el tiempo de<br />
antelación con el que se produce el ‘trigger’ y la topología de la red<br />
permit<strong>en</strong> un handover sin ninguna degradación.<br />
Exist<strong>en</strong> sistemas que permit<strong>en</strong> al nodo móvil comunicarse<br />
simultáneam<strong>en</strong>te con las dos estaciones base involucradas <strong>en</strong> el esquema<br />
de handover. En este capítulo se han analizado los dos esquemas que,<br />
propuestos <strong>en</strong> el capítulo 6, funcionaban de esta forma.<br />
El primero de los esquemas se d<strong>en</strong>omina ‘Handover Semi Suave’.<br />
Se han analizado dos posibles implem<strong>en</strong>taciones de este esquema. En la<br />
primera el MN acepta todos los paquetes que recibe de ambas estaciones<br />
base mi<strong>en</strong>tras se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> la zona de solape. En esta situación no se<br />
van a producir pérdida de paquetes, pero si una duplicación que<br />
dep<strong>en</strong>derá, directam<strong>en</strong>te, del tiempo <strong>en</strong> el que el nodo móvil permanece <strong>en</strong><br />
la zona de cobertura de las dos estaciones. La otra implem<strong>en</strong>tación hace<br />
348
Evaluación analítica<br />
que el MN rechace los paquetes de oBS una vez se ha recibido<br />
confirmación del registro con nBS. En este caso se ha comprobado como el<br />
esquema funciona perfectam<strong>en</strong>te <strong>en</strong> caso de que las rutas <strong>en</strong>tre el nodo de<br />
cruce y las dos estaciones sean similares. En caso contrario se producirá<br />
una perdida o duplicación de paquetes dep<strong>en</strong>di<strong>en</strong>do de si la ruta a la<br />
estación base antigua es mayor o m<strong>en</strong>or que la ruta a nBS<br />
respectivam<strong>en</strong>te.<br />
Para solucionar los problemas que introduce una topología de red<br />
inadecuada <strong>en</strong> el esquema de handover anterior se propuso el esquema<br />
‘Handover Suave con Finalización Controlada’. Este esquema propone<br />
dos mejoras con respecto al anterior. La primera consiste <strong>en</strong> retrasar la<br />
desconexión con oBS aun cuando ya se ha registrado correctam<strong>en</strong>te con<br />
nBS. Esto permite eliminar la pérdida de paquetes que se producían <strong>en</strong><br />
topologías donde la ruta a oBS era mayor que la ruta a nBS. Los<br />
resultados demuestran que un retraso <strong>en</strong> cortar la conexión con oBS del<br />
mismo tiempo que la difer<strong>en</strong>cia de caminos es sufici<strong>en</strong>te para evitar<br />
pérdidas <strong>en</strong> el MN.<br />
Se ha analizado una segunda v<strong>en</strong>taja consist<strong>en</strong>te <strong>en</strong> que el nodo<br />
móvil almac<strong>en</strong>a información del último paquete recibido con el fin de evitar<br />
también las duplicaciones. nBS comi<strong>en</strong>za almac<strong>en</strong>ando los paquetes que<br />
recibe del árbol <strong>multicast</strong>, hasta que MN le <strong>en</strong>vía un m<strong>en</strong>saje indicando el<br />
último paquete recibido. De esta manera nBS descarta los paquetes<br />
duplicados. Se ha analizado las repercusiones que ti<strong>en</strong>e esta solución, <strong>en</strong><br />
cuanto al retardo que sufr<strong>en</strong> algunos paquetes. Así la probabilidad de que<br />
un paquete sufra un retardo adicional dep<strong>en</strong>derá del retardo <strong>en</strong> la<br />
desconexión con oBS y de la difer<strong>en</strong>cia de rutas.<br />
También se ha analizado las limitaciones que ti<strong>en</strong>e este mecanismo.<br />
En concreto, si la ruta hacia nBS es más l<strong>en</strong>ta que la ruta a oBS es muy<br />
probable que se retransmitan un gran número de paquetes. Además el<br />
número de paquetes duplicados dep<strong>en</strong>de del tiempo que el nodo móvil ha<br />
ret<strong>en</strong>ido la conexión con oBS. Como solución a esta limitación <strong>en</strong> el punto<br />
6.5.2 se diseñó un mecanismo que permitía al MN decidir el esquema de<br />
handover adecuado a la topología de la red, ya que <strong>en</strong> esta situación es<br />
349
Evaluación analítica.<br />
mucho más conv<strong>en</strong>i<strong>en</strong>te utilizar el esquema semi suave analizado<br />
previam<strong>en</strong>te.<br />
350
8. CONCLUSIONES Y LÍNEAS FUTURAS DE<br />
INVESTIGACIÓN<br />
8.1 INTRODUCCIÓN<br />
En este capítulo se expon<strong>en</strong> las princ<strong>ip</strong>ales conclusiones de la Tesis<br />
Doctoral, y se apuntan las posibles líneas de continuación de la misma.<br />
Dado que al final de cada capítulo ya se resumieron las<br />
conclusiones y disertaciones sobre los resultados y el trabajo desarrollado,<br />
<strong>en</strong> este capítulo se pres<strong>en</strong>tan dichas conclusiones desde una perspectiva<br />
global y más amplia, destacando de modo particular los aspectos más<br />
importantes.<br />
Respecto a las posibles vías futuras de investigación, se citarán<br />
aquellas líneas que ti<strong>en</strong><strong>en</strong> una relación directa con este trabajo, y que<br />
pued<strong>en</strong> ser abordadas como una continuación del mismo, o como una<br />
profundización de algunos aspectos aquí tratados sin mucha profundidad.<br />
Asimismo se citarán nuevos campos de investigación d<strong>en</strong>tro del área de la<br />
<strong>movilidad</strong> <strong>en</strong> redes IP.<br />
8.2 CONCLUSIONES GLOBALES<br />
El trabajo desarrollado <strong>en</strong> esta Tesis Doctoral se ha c<strong>en</strong>trado <strong>en</strong> el<br />
campo de la <strong>movilidad</strong> <strong>en</strong> redes IP. Aunque exist<strong>en</strong> distintas soluciones<br />
para abordar el problema, actualm<strong>en</strong>te la mayoría de las contribuciones<br />
giran <strong>en</strong> torno al protocolo Mobile IP [RFC 3344].<br />
Sin esconder las v<strong>en</strong>tajas que aporta, y que lo han convertido <strong>en</strong> la<br />
refer<strong>en</strong>cia básica para toda la investigación actual, hay que indicar que<br />
Mobile IP ti<strong>en</strong>e importantes limitaciones que no lo hac<strong>en</strong> útil para <strong>en</strong>tornos<br />
351
Conclusiones y Líneas futuras de investigación<br />
con requerimi<strong>en</strong>tos de QoS, como pued<strong>en</strong> ser su utilización para tráfico<br />
multimedia, o para incorporarlo a los sistemas móviles de cuarta<br />
g<strong>en</strong>eración.<br />
Como se demostró <strong>en</strong> el capítulo 5 de esta Tesis, uno de los<br />
princ<strong>ip</strong>ales problemas es el tiempo necesario para realizar un handover,<br />
ya que el nodo móvil debe indicar al Home Ag<strong>en</strong>t cada cambio de su<br />
dirección temporal.<br />
Se han realizado algunas propuestas para solucionar esta<br />
limitación, y todas se basan <strong>en</strong> la división espacial <strong>en</strong> zonas o dominios, de<br />
manera que el handover pueda ser tratado de manera local.<br />
En esta Tesis Doctoral hemos pres<strong>en</strong>tado un novedoso sistema de<br />
micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> la capacidad de transmisión <strong>multicast</strong>. Aunque<br />
previam<strong>en</strong>te ya existían algunas publicaciones que proponían la utilización<br />
de las capacidades <strong>multicast</strong> [MYS98], [HEL00], estas soluciones no<br />
estaban planteadas para <strong>en</strong>tornos de micro-<strong>movilidad</strong>, por lo que adolec<strong>en</strong><br />
de importantes limitaciones <strong>en</strong> cuanto a la escalabilidad y prestaciones<br />
durante el handover.<br />
La elección de la tecnología <strong>multicast</strong> como base para realizar un<br />
sistema de micro-<strong>movilidad</strong> totalm<strong>en</strong>te novedoso se ha debido,<br />
princ<strong>ip</strong>alm<strong>en</strong>te, a que <strong>en</strong>t<strong>en</strong>demos que el direccionami<strong>en</strong>to <strong>multicast</strong> ti<strong>en</strong>e<br />
mucho <strong>en</strong> común con la <strong>movilidad</strong>, ya que ambas tecnologías se <strong>en</strong>fr<strong>en</strong>tan<br />
al problema de la localización del nodo indep<strong>en</strong>di<strong>en</strong>tem<strong>en</strong>te de la<br />
dirección. Además consideramos que aporta otras v<strong>en</strong>tajas, como la<br />
facilidad intrínseca de transmitir datos simultáneam<strong>en</strong>te a dos<br />
localizaciones, lo que favorece los handovers sin pérdidas, o la madurez<br />
actual de la tecnología, que permite su fácil incorporación a <strong>en</strong>tornos<br />
móviles.<br />
A difer<strong>en</strong>cia de la mayoría de las soluciones pres<strong>en</strong>tadas <strong>en</strong> la<br />
literatura, se ha desarrollado, no sólo una arquitectura, sino un protocolo<br />
completo, incluy<strong>en</strong>do el formato de todos los m<strong>en</strong>sajes propuestos. Estos<br />
m<strong>en</strong>sajes han sido realizados sigui<strong>en</strong>do las estructuras de ext<strong>en</strong>sión del<br />
352
Conclusiones y Líneas futuras de investigación<br />
propio protocolo Mobile IP [RFC 3444], así como los trabajos que se están<br />
realizando actualm<strong>en</strong>te [KHA01], [GUS02], [PER02]. El objetivo ha sido que<br />
el sistema propuesto pueda integrarse perfectam<strong>en</strong>te <strong>en</strong> un sistema<br />
<strong>basado</strong> <strong>en</strong> Mobile IP.<br />
El protocolo especificado ti<strong>en</strong>e pres<strong>en</strong>te los posibles problemas de<br />
escalabilidad. También se ha incluido todos los mecanismos de seguridad<br />
necesarios <strong>en</strong> este t<strong>ip</strong>o de redes, incluso se ha abordado el problema del<br />
establecimi<strong>en</strong>to de la asociación de seguridad <strong>en</strong>tre el nodo móvil y las<br />
estaciones base, tema actualm<strong>en</strong>te bajo estudio <strong>en</strong> el grupo de trabajo<br />
‘m<strong>ip</strong>v4’ del IETF [MIPv4].<br />
Una vez diseñado el sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong><br />
<strong>multicast</strong> se ha abordado el estudio detallado del proceso de handover <strong>en</strong><br />
redes IP. Hemos difer<strong>en</strong>ciado tres compon<strong>en</strong>tes que increm<strong>en</strong>tan el tiempo<br />
de lat<strong>en</strong>cia total del handover. El objetivo de este estudio ha sido dotar a<br />
nuestro sistema de esquemas de handover que super<strong>en</strong> las limitaciones de<br />
las soluciones clásicas.<br />
Se han publicado numerosas propuestas que mejoran las<br />
prestaciones del handover pres<strong>en</strong>tado <strong>en</strong> Mobile IP. Estas propuestas<br />
int<strong>en</strong>tan solucionar dos problemas difer<strong>en</strong>ciados: por un lado reducir el<br />
elevado tiempo de lat<strong>en</strong>cia (Handovers rápidos), por otro lado solucionar el<br />
problema de la pérdida de paquetes (Handovers suaves).<br />
Con respecto a reducir el retardo, hemos comprobado que la<br />
bibliografía pres<strong>en</strong>ta distintas soluciones que int<strong>en</strong>tan minimizar este<br />
retardo. Una solución sería minimizar la lat<strong>en</strong>cia del proceso de handover,<br />
por ejemplo adelantando el inicio basándonos <strong>en</strong> la utilización de ‘triggers’.<br />
Otra solución sería no interrumpir la <strong>en</strong>trega de paquetes mi<strong>en</strong>tras dura el<br />
handover, por ejemplo implem<strong>en</strong>tando <strong>en</strong> los nodos móviles la capacidad<br />
de hablar simultáneam<strong>en</strong>te con las dos estaciones base.<br />
Con respecto a la <strong>en</strong>trega de todos los paquetes, tradicionalm<strong>en</strong>te<br />
se utilizan dos técnicas. Una opción sería introducir algún mecanismo de<br />
retransmisión de paquetes p<strong>en</strong>di<strong>en</strong>tes desde oBS a nBS. Otra posibilidad<br />
353
Conclusiones y Líneas futuras de investigación<br />
sería realizar una transmisión dualcast temporal de manera que las dos<br />
estaciones implicadas recib<strong>en</strong> los paquetes dirigidos al nodo móvil.<br />
El estudio detallado de todas las propuestas anteriores nos<br />
demuestra que el sistema de micro-<strong>movilidad</strong> que proponemos ofrece unas<br />
propiedades intrínsecas idóneas para lograr, tanto handovers intradominio<br />
rápidos, como suaves.<br />
En particular, el tiempo de lat<strong>en</strong>cia del handover se reduce al<br />
mínimo. Así, el compon<strong>en</strong>te del tiempo de lat<strong>en</strong>cia que d<strong>en</strong>ominamos<br />
‘Retardo <strong>en</strong> la Recuperación de una Dirección Temporal’, se elimina por<br />
completo. Además, el tiempo ‘Retardo de reestablecimi<strong>en</strong>to de la ruta’ se<br />
reduce al tiempo necesario para la conexión de la nueva Estación Base al<br />
árbol <strong>multicast</strong>.<br />
Con respecto a la transmisión sin pérdidas de paquetes, el sistema<br />
de micro-<strong>movilidad</strong> pres<strong>en</strong>tado se basa <strong>en</strong> la conexión de las estaciones<br />
base a un árbol <strong>multicast</strong> asociado al nodo móvil. Esto lleva implícito una<br />
transmisión de paquetes hacia las dos estaciones de manera simultánea,<br />
facilitando <strong>en</strong>ormem<strong>en</strong>te la implem<strong>en</strong>tación de handovers suaves.<br />
Con todo lo anterior hemos propuesto cinco esquemas de handover<br />
difer<strong>en</strong>tes, diseñados para implem<strong>en</strong>tarse <strong>en</strong> el sistema de micro-<strong>movilidad</strong><br />
<strong>basado</strong> <strong>en</strong> <strong>multicast</strong>. Esos esquemas son adecuados tanto para sistemas<br />
<strong>en</strong> los cuales el nodo móvil no es capaz de mant<strong>en</strong>er la comunicación con<br />
dos estaciones base simultáneam<strong>en</strong>te, como para aquellos <strong>en</strong> los que el<br />
nodo móvil puede comunicarse con ambas.<br />
Los cinco esquemas anteriores han sido evaluados analíticam<strong>en</strong>te.<br />
El objetivo es analizar las v<strong>en</strong>tajas de utilizar uno u otro esquema, <strong>en</strong><br />
función del número de paquetes perdidos, tiempo de interrupción o tiempo<br />
de espera <strong>en</strong> ‘buffers’.<br />
A la vez hemos evaluado como afecta a las prestaciones del<br />
esquema de handover la modificación de distintos parámetros, como puede<br />
ser la topología de la red. En este último aspecto, la flexibilidad a la hora<br />
354
Conclusiones y Líneas futuras de investigación<br />
de seleccionar un mecanismo de handover u otro ha favorecido<br />
<strong>en</strong>ormem<strong>en</strong>te la obt<strong>en</strong>ción de bu<strong>en</strong>os resultados aun <strong>en</strong> topologías de red<br />
poco propicias.<br />
Podemos concluir indicando que se ha especificado un sistema de<br />
micro-<strong>movilidad</strong> IP novedoso <strong>basado</strong> <strong>en</strong> la capacidad <strong>multicast</strong>. Este<br />
sistema ofrece unas prestaciones <strong>en</strong> seguridad, escalabilidad y simplicidad<br />
iguales o superiores a todos los exist<strong>en</strong>tes actualm<strong>en</strong>te. Además se han<br />
diseñado cinco esquemas de handover para el protocolo anterior,<br />
obt<strong>en</strong>i<strong>en</strong>do una solución global. Esta solución se adapta a todas las<br />
tecnologías de acceso a red, y se obti<strong>en</strong>e altas prestaciones tanto <strong>en</strong> la<br />
lat<strong>en</strong>cia del proceso de handover como <strong>en</strong> el número de paquetes perdidos.<br />
8.3 LÍNEAS FUTURAS DE INVESTIGACIÓN<br />
El campo de la <strong>movilidad</strong> <strong>en</strong> redes IP es muy amplio y, a pesar de<br />
que ciertos protocolos, como Mobile IP, están consolidados, los grupos de<br />
trabajo relacionados con este campo sigu<strong>en</strong> t<strong>en</strong>i<strong>en</strong>do mucha actividad<br />
[MIPv4], [MIPv6].<br />
En la introducción de esta Tesis Doctoral se hizo m<strong>en</strong>ción a que los<br />
dos problemas que limitaban la incorporación de la arquitectura IP a<br />
sistemas móviles eran, por un lado, que el protocolo IP se había planteado<br />
para <strong>en</strong>tornos con hosts fijos y, por otro lado, las limitaciones de esta<br />
arquitectura para ofrecer QoS. A lo largo de esta memoria se ha<br />
demostrado como el problema de ofrecer <strong>movilidad</strong> se ha resuelto<br />
correctam<strong>en</strong>te, con el trabajo conjunto del protocolo Mobile IP junto con<br />
soluciones de micro-<strong>movilidad</strong> como la pres<strong>en</strong>tada aquí.<br />
Sin embargo la incorporación de QoS <strong>en</strong> <strong>en</strong>tornos IP móviles es un<br />
tema por resolver y, desde mi punto de vista, la línea de investigación más<br />
interesante. En este s<strong>en</strong>tido es interesante consultar la [RFC 3583], donde<br />
se indican los requerimi<strong>en</strong>tos que deb<strong>en</strong> cumplir los mecanismos de QoS<br />
para poder funcionar correctam<strong>en</strong>te <strong>en</strong> <strong>en</strong>tornos de Mobile IP. La<br />
355
Conclusiones y Líneas futuras de investigación<br />
incorporación de QoS puede verse como una continuación directa de esta<br />
Tesis, si se incorpora al sistema de micro-<strong>movilidad</strong> pres<strong>en</strong>tado aquí, o<br />
como un nuevo campo de investigación.<br />
Otro tema de investigación, relacionado con el anterior sería el<br />
problema de cómo transferir el contexto de una comunicación durante el<br />
procedimi<strong>en</strong>to de handover. En este s<strong>en</strong>tido el grupo de trabajo del IETF<br />
‘seamoby’ [SEA] está actualm<strong>en</strong>te trabajando <strong>en</strong> un protocolo para la<br />
transfer<strong>en</strong>cia del contexto [LOO04], <strong>en</strong>t<strong>en</strong>di<strong>en</strong>do por contexto parámetros<br />
como información AAA, características QoS, mecanismo de compresión<br />
empleados, contextos de seguridad utilizados, etc.<br />
Otro de los campos con gran proyección es el tema de la seguridad,<br />
y <strong>en</strong> particular el uso de servidores AAA <strong>en</strong> redes IP móviles. Esta línea de<br />
investigación podría verse, tanto como continuación directa de esta Tesis,<br />
como abordándolo como un nuevo campo de investigación. Así <strong>en</strong> esta<br />
Tesis se ha propuesto una solución s<strong>en</strong>cilla para el intercambio de claves<br />
<strong>en</strong>tre los distintos elem<strong>en</strong>tos que forman el sistema. Sin embargo sería<br />
aconsejable un mecanismo de acuerdo con las últimas propuestas<br />
pres<strong>en</strong>tadas [PER04].<br />
La última gran línea de investigación futura es el protocolo Mobile<br />
IPv6. A pesar del tiempo desde la primera versión borrador del mismo, y de<br />
que se han realizado 24 versiones, aún no se ha estandarizado<br />
completam<strong>en</strong>te. En la actualidad son muchas las áreas d<strong>en</strong>tro de la<br />
versión Mobile IPv6 donde se está trabajando int<strong>en</strong>sam<strong>en</strong>te: seguridad <strong>en</strong><br />
los mecanismos de optimización de ruta, utilización de IPsec <strong>en</strong>tre el nodo<br />
móvil y el HA, handover rápidos, funcionami<strong>en</strong>to de protocolo <strong>en</strong> pres<strong>en</strong>cia<br />
de ‘firewalls’, etc.<br />
356
BIBLIOGRAFÍA<br />
ARTÍCULOS<br />
[ABR72]<br />
[ACA94]<br />
[AKY97]<br />
[ALT02]<br />
[ANA93]<br />
[AWE91]<br />
[BAK96]<br />
[BAL95]<br />
[BAL96]<br />
M. Abramowitz, y I. Stergun. ‘Handbook of Mathematical<br />
Functions with Formulas, Graphs, and Mathematical Table’,<br />
Pag. 930. Dover Publications, 1972.<br />
A.S. Acampora, M. Naghshineh. ‘An Architecture and<br />
Methodology for Mobile-Executed Handoff in Cellular ATM<br />
Networks’. IEEE J.S.A.C. Octubre 1994.<br />
B.A. Akyol, D.C. Cox. ‘Signaling Alternatives in a Wireless<br />
ATM Network’. IEEE J.S.A.C. Special Issue on Wireless<br />
ATM, Enero 1997.<br />
O. Altintas, A. Dutta, y H. Schulzrinne. ‘Mobility Approaches<br />
for All IP Wireless Networks’. Proc. of IEEE Wireless<br />
Communications and Networking Confer<strong>en</strong>ce (WCNC),<br />
Marzo 2002.<br />
V. Anantharam, M. L. Honing, U. Madhow y V.K. Wei.<br />
‘Optimization of a Database Hierarchy for Mobility Tracking<br />
in a Personal Communications Network’. Proc. of Perfomance<br />
93, Septiembre 1993.<br />
B. Awerbuch y D. Peled. ‘Online Tracking on mobile users’.<br />
Proc. of ACM SIGCOMM, 1991.<br />
M.G. Baker, X. Zhao, S. Cheshire, y J, Stone. ‘Supporting<br />
Mobility in MosquitoNet’. Proc. of 1996 USENIX Technical<br />
Confer<strong>en</strong>ce, Enero 19996.<br />
H. Balakrishnan, S. Seshan, y R. H. Katz. ‘Improving<br />
Reliable Transport ad Handoff Performance in Cellular<br />
Wireless Networks’. ACM Wireless Networks, Diciembre<br />
1995.<br />
H. Balakrishnan, V.N. Padmanabhan, S. Seshan, y R.H.<br />
Katz. ‘A Comparison of Mechanisms for Improving TCP<br />
Perfomance over Wireless Links’. Proc. of ACM SIGCOMM,<br />
Agosto 1996.<br />
357
Bibliografía<br />
[BALL98]<br />
[BHA03]<br />
[BHA95]<br />
[BHA96]<br />
[BLA96]<br />
[BLO02]<br />
[BLO02b]<br />
[BLO02c]<br />
A. Ballardie, B. Cain, Z. Zhang. ‘Core Based Trees (CBT<br />
version 3) Multicast Routing’. Internet Draft. Draft-ietf-idmrcbt-spec-v3-01.txt.<br />
(Work in Progress), Agosto 1998.<br />
S. Bhattacharyya et al. ‘An Overview of Source-Specific<br />
Multicast (SSM’). Internet Draft. Draft-ietf-ssm-overview-<br />
05.txt. (Work in Progress), Mayo 2003<br />
V. Bhaskaran, y K. Konstantinides. ‘Image and Video<br />
Compresión Standards. Algorithms and Architectures’.<br />
Kluwer Academic Publishers, 1995.<br />
P. Bhagwat, C. Perkins y S. K. Tr<strong>ip</strong>athi. ‘Network Layer<br />
Mobility : an Architecture and Survey’. IEEE Personal<br />
Communication v.3 no.3, Junio 1996.<br />
G. Blakowski, R. Steinmetz, ‘A Media Synchronization<br />
Survey: Refer<strong>en</strong>ce Model, Specification, and Case Studies’,<br />
IEEE J.S.A.C, Vol. 14, Nº. 1, Enero 1996.<br />
C. Blondia, O. Casals, P. De Cleyn, y G. Willems.<br />
‘Performance Analysis of IP Micro-Mobility Handoff Protocols’.<br />
Proc. of Protocols for High Speed Networks 2002 (PfHSN<br />
2002), Berlín 2002.<br />
C. Blondia, O. Casals, P. De Cleyn, y G. Willems.<br />
‘Performance Analysis of a Forwarding Scheme for Handoff<br />
in HAWAII’. Proc. of Networking 2002, Pisa 2002.<br />
C. Blondia, N. Van d<strong>en</strong> Wijngaert, G. Willems, y O. Casals.<br />
‘Performance Analysis of Optimized Smooth Handoff in<br />
Mobile IP’. Proc. of MSWiM, Atlanta 2002.<br />
[BLO03] C. Blondia, O. Casals, Ll. Cerdá, N. Van d<strong>en</strong> Wijngaert, G.<br />
Willems, P. De Cleyn. ‘Performance Comparison of Low<br />
Lat<strong>en</strong>cy Mobile IP schemes’. Proc. of WiOpt, Marzo 2003.<br />
[BRA94]<br />
[CAC94]<br />
L. Brakmo, S. O'Malley, and L. Peterson. ‘TCP Vegas: New<br />
techniques for congestion detection and avoidance’. Proc. of<br />
the SIGCOMM '94 Symposium, Agosto 1994.<br />
R. Caceres y L. Iftode. ‘Improving the Performance of Reliable<br />
Transport Protocols in Mobile Computing Environm<strong>en</strong>ts’.<br />
IEEE Journal on Selected Areas in Communications, 1994.<br />
358
Bibliografía<br />
[CAC96]<br />
[CAL01]<br />
[CAM00]<br />
[CAM01]<br />
[CAM02]<br />
[CHA01]<br />
[DAS00]<br />
[DEE90]<br />
[DOM01]<br />
R. Caceres, y V. N. Padmanabhan. ‘Fast and Scalable<br />
Handoffs for Wireless Internetworks’. Proc of ACM<br />
MobiCom’96, Noviembre 1996.<br />
P. Calhoun, A. Rub<strong>en</strong>s, H. Akhtar, y E. Guttman.<br />
‘DIAMETER Base Protocol’. Internet Draft. Draft-ietf-aaadiameter-07.txt.<br />
(Work in Progress), Julio 2001.<br />
A. T. Campbell, J. Gomez, S. Kim, A. G. Valko, C-Y. Wan, y<br />
Z. Turanyi. ‘Design, Implem<strong>en</strong>tation, and Evaluation of<br />
Cellular IP’. IEEE Personal Communications, vol. 7, no. 4,<br />
Agosto 2000.<br />
A. T. Campbell, J. Gomez. ‘IP Micro-Mobility Protocols’. ACM<br />
SIGMOBILE Mobile Computer and Communication Review<br />
(MC2R), Vol. 4, No. 4, pp 45-54, Octubre 2001.<br />
A. T. Campbell, J. Gomez, S. Kim, C-Y. Wan , Z. Turanyi y<br />
A. G. Valko. ‘Comparison of IP Micromobility Protocols’. IEEE<br />
Wireless Communications Magazine, Vol. 9, No. 1, Febrero<br />
2002.<br />
K. Chakraborty et al. ‘Implem<strong>en</strong>tation and Performance<br />
Evaluation of TeleMIP’. Proc. of IEEE International<br />
Confer<strong>en</strong>ce on Communications, ICC, 2001.<br />
S. Das et al. ‘TeleMIP: Telecommunication-Enhanced Mobile<br />
IP Architecture for Fast Intradomain Mobility’. IEEE Personal<br />
Communications, vol. 7, no. 4, Agosto 2000.<br />
S.Deering, D. Cheriton. ‘Multicast routing in datagram<br />
internetworks and ext<strong>en</strong>ded LAN’s’. ACM Transactions on<br />
Computer Systems, pp. 85-111, Mayo 1990.<br />
G. Dommety, y T. Ye. ‘Local and Indirect Registration for<br />
Anchoring Handoffs’. Internet Draft. Draft-dommetymobile<strong>ip</strong>-anchor-handoff-03.txt<br />
(Work in Progress), Julio<br />
2001.<br />
[DUT01] A. Dutta, R. Jain, K.D. Wong, J. Burns, K. Young y H.<br />
Schulzrinne. ‘Multilayered Mobility Managem<strong>en</strong>t for<br />
Survivable Network’. Proc. of Milcom, Octubre 2001.<br />
[DUT01b]<br />
A. Dutta, F. Vakil, J. Ch<strong>en</strong>, y M. Tauil. ‘Application Layer<br />
Mobility Managem<strong>en</strong>t Scheme for Wireless Internet’. Proc. of<br />
359
Bibliografía<br />
IEEE 3Gwireless01, Mayo 2001.<br />
[EAR00]<br />
[EAR02]<br />
[ELM00]<br />
[ELM02]<br />
[ELZ01]<br />
[ENG95]<br />
[FEN03]<br />
[GUS02]<br />
[HEL00]<br />
[HOL03]<br />
[IEEE<br />
802.11]<br />
[IEEE<br />
P. Eardley, A. Mihailovic, y T. Suihko. ‘A Framework for the<br />
Evaluation of IP Mobility Protocols’. Proc. of PIMRC,<br />
Septiembre 2000.<br />
P. Eardley, N. Georganopoulos, M.A. West. On the<br />
Scalability of IP Micro-Mobility Managem<strong>en</strong>t Protocols.<br />
Proceedings of MWCN, Septiembre 2002.<br />
K. El Maki, y H. Soliman. Fast Hand-offs in Mobile Ipv4.<br />
Internet Draft. Draft-elmalki-mobile<strong>ip</strong>-fast-handoffs-03.txt.<br />
(Work in Progress), Septiembre 2000.<br />
K. El Malki, et al. ‘Low Lat<strong>en</strong>cy Handoffs in Mobil IPv4’.<br />
Internet Draft. draft-ietf-mobile<strong>ip</strong>-lowlat<strong>en</strong>cy-handoffs-v4-<br />
04.txt. (Work in Progress), Junio 2002.<br />
R. Elz y P. Hethmon. Ext<strong>en</strong>sions to FTP. Internet Draft.<br />
draft-ietf-ftpext-mlst-13.txt. (Work in Progress), Mayo 2001.<br />
K.Y. Eng, et al. ‘BAHAMA : A Broadband Ad-Hoc Wireless<br />
ATM Local Area Networks’. ACM/Baltzer Journal on<br />
Wireless Networks, vol. 1, Nº 2, 1995.<br />
B. F<strong>en</strong>ner, M. Handley, H. Holbrook, y I. Kouvelas. ‘Protocol<br />
Indep<strong>en</strong>d<strong>en</strong>t Multicast - Sparse Mode (PIM-SM): Protocol<br />
Specification (Revised)’. Internet Draft. draft-ietf-pim-sm-v2-<br />
new-07.txt . (Work in Progress), Marzo 2003<br />
E. Gustafsson, A. Jonsson, y C. Perkins. ‘Mobile IP Regional<br />
Registration’. Internet Draft. draft-ietf-mobile<strong>ip</strong>-reg-tunnel-<br />
06.txt. (Work in Progress), Marzo 2002.<br />
A. Helmy. ‘Multicast-based Architecture for IP Mobility:<br />
Simulation Analysis and Comparision with Basic Mobile IP’.<br />
Technology Research News Journal, Nº1, Junio 2000.<br />
H. Holbrook y B. Cain. ‘Source-Specific Multicast for IP’.<br />
Internet Draft. Draft-ietf-ssm-arch-03.txt. (Work In<br />
Progress), Mayo 2003<br />
‘Wirweless LAN Medium Access Control (MAC) and Physical<br />
Layer (PHY) Specifications’. IEEE std. 802.11, 1999.<br />
‘Recomm<strong>en</strong>ded Practice for Multi-V<strong>en</strong>dor Access Point<br />
360
Bibliografía<br />
802.11f]<br />
[IOA91]<br />
[IOA93]<br />
[JAC88]<br />
[JAI91]<br />
[JOH03]<br />
[JOH94]<br />
[JOH95]<br />
[JON99]<br />
[KAU95]<br />
[KEM00]<br />
[KEM01]<br />
Interoperability via an Inter-Access Point Protocol Across<br />
Distribution Systems Supporting 802.11 Operation’. IEEE<br />
Std 802.11f/D3, Draft. Enero 2002.<br />
J. Ioannidis, D. Duchamp, y G.Q. Maguire Jr. ‘Ip-based<br />
Protocols for Mobile Internetworking’. Proc. of ACM<br />
SIGCOMM, 1991.<br />
J. Ioannidis, G.Q. Maguire Jr. ‘The Design and<br />
Implem<strong>en</strong>tation of a Mobile Internetworking Architecture’.<br />
Proc. of Winter USENIX, Enero 1993.<br />
V. Jacobson. ‘Congestion Avoidance and Control’. ACM<br />
SIGCOMM’88, Agosto 1988<br />
R. Jain. ‘The Art of Computer Systems Performance Analysis<br />
: Techniques for Experim<strong>en</strong>tal Design, Measurem<strong>en</strong>t,<br />
Simulation, and Modeling’. Ed. John Wiley & Sons, Abril<br />
1991. ISBN: 0471503363<br />
D.B. Johnson, C. Perkins, y J. Arkko. ‘Mobility Support in<br />
IPv6’. Internet Draft, Draft-ietf-mobile<strong>ip</strong>-<strong>ip</strong>v6-24.txt. (Work<br />
in Progress), Junio 2003.<br />
D.B. Johnson. ‘Scalable and Robust Internetwork Routing for<br />
Mobile Hosts’. Proc. of the 14 th International Confer<strong>en</strong>ce on<br />
Distributed Computing Systems, junio 1994<br />
D.B. Johnson. ‘Scalable Support for Transpar<strong>en</strong>t Mobile Host<br />
Internetworking’. ACM/Baltzer Wireless Networks, vol. 1,<br />
no. 3, 1995.<br />
A. Jonsson, E. Gustafsson, y C. Perkins. ‘Mobile IP Regional<br />
Tunnel Managem<strong>en</strong>’t. Internet Draft, draft-ietf-mobile<strong>ip</strong>-regtunnel-01.txt.<br />
(Work in Progress), Agosto 1999.<br />
C. Kaufman, R. Perlman, y M. Sp<strong>en</strong>cer. ‘Network Security:<br />
Private Communication in a Public World’. Ed. Pr<strong>en</strong>tice Hall,<br />
1995.<br />
J. Kempf, P.R. Calhoun, y C. Pairla. ‘Foreign Ag<strong>en</strong>t Assisted<br />
Hand-off’. Internet Draft. Draft-calhoun-mobile<strong>ip</strong>-proactivefa-01.txt.<br />
(Work in Progress), Junio 2000.<br />
J.Kempf, P. McCann, y P. Roberts. ‘IP Mobility and the<br />
CDMA Radio Access Network: Applicability Statem<strong>en</strong>t for Soft<br />
361
Bibliografía<br />
Handoff’. Internet Draft. Draft-kempf-cdma-appl-02.txt<br />
(Work in Progress), Septiembre 2001.<br />
[KER94]<br />
[KHA01]<br />
[KLE75]<br />
[KOO02]<br />
[LAM96]<br />
[LEO98]<br />
[LEO99]<br />
[LI96]<br />
[LIN96]<br />
[LIT90]<br />
[LIU96]<br />
D. Kerek, H.T<strong>en</strong>hun<strong>en</strong>, G.Q.Maguire, y F.Reichert. ‘Direct<br />
Sequ<strong>en</strong>ce CDMA Technology and its Application to Future<br />
Portable Multimedia Communication Systems’. Proc. of IEEE<br />
ISSTA, Julio 1994<br />
M. Khalil, E. Qaddoura, H. Akhtar y P. Calhoun.<br />
‘G<strong>en</strong>eralizad NAI (GNAI) Ext<strong>en</strong>sion for Mobile IPv4’. Internet<br />
Draft. draft-ietf-mobile<strong>ip</strong>-gnaie-05.txt. (Work in Progress),<br />
Octubre 2001.<br />
L. Kleinrock. ‘Queueing Systems, Volum<strong>en</strong> 1, Theory’. Ed.<br />
John Wiley & Sons. ISBN: 0471491101, 1975.<br />
R. Koodli (Ed.). ‘Fast Handovers for Mobile IPv6’. Internet<br />
Draft. draft-ietf-mobile<strong>ip</strong>-fast-m<strong>ip</strong>v6-05.txt. (Work in<br />
Progresss), Septiembre 2002.<br />
L. Lamont, L. Li, R. Brimont, D. Georganas,<br />
‘Synchronization of Multimedia Data for a Multimedia<br />
News-on-Demand Application’. IEEE J.S.A.C., Vol. 14, Nº.<br />
1, Enero 1996.<br />
A. León, M. Esteve, J.C. Guerri, C. Palau ‘A New Hand-Off<br />
Protocol for an ATM Based Wireless Network’, Proc. Of<br />
16th.IASTED International Confer<strong>en</strong>ce Applied Informatics,<br />
Febrero 1998.<br />
A. León, A. Pajares, M.Esteve, J.C. Guerri, C.Palau ‘Handoff<br />
and Synchronization Protocols for Supporting Multimedia<br />
Communications in an ATM Wirteless Network’ Proc. of IEEE<br />
ICATM, Junio 1999.<br />
J. Li, R. Yuan. ‘Handoff Control in Wireless ATM Networks:<br />
An Experim<strong>en</strong>tal Study’. ICUPC’ 96. Boston 1996.<br />
J.C. Lin y S. Paul. ‘RMTP: A Reliable Multicast Transport<br />
Protocol’. Proc. of IEEE Infocom, Abril 1996.<br />
T.D.C. Little, A. Ghafoor, ‘Synchronization and Storage<br />
Models for Multimedia Objects’, IEEE J.S.A.C., Vol. 8, Nº. 3,<br />
Abril 1990.<br />
J.Liu, G.Q.Maguire, y G.Liu. ‘Enhancing the Effici<strong>en</strong>cy and<br />
362
Bibliografía<br />
Reliability of Handover and Routing Performance in Wireless<br />
Mobile Internetworking Envirom<strong>en</strong>ts’. Proc. of IFIP TC62,<br />
1996<br />
[LOU04]<br />
[MAN02]<br />
[MIS00]<br />
[MIS00b]<br />
[MIS01]<br />
[MOH94]<br />
[MYL93]<br />
[MYL95]<br />
[MYS97]<br />
[MYS98]<br />
J. Loughney, M. Nakhjiri, C. Perkins, y R. Koodli. ‘Contex<br />
Transfer Protocol’. Internet Draft. Draft-ietf-seamoby-ctp-<br />
08.txt (Work in Progress), Enero 2004.<br />
J. Manner, M. Kojo. ‘Mobility related Terminology’. Internet<br />
Draft. Draft-ietf-seamoby-mobility-terminology-01.txt.<br />
(Work in Progress), Noviembre 2002.<br />
A. Misra, S. Das, A. Mcauley, A. Dutta, y S.K. Das. ‘IDMP:<br />
An Intra-Domain Mobility Mangem<strong>en</strong>t Protocol Using Mobility<br />
Ag<strong>en</strong>ts’. Internet Draft. draft-misra-mobile<strong>ip</strong>-idmp-00.txt.<br />
(Work in Progress), Julio 2000<br />
A. Misra, S. Das, A. Mcauley, A. Dutta, y S.K. Das.<br />
‘Intregating QoS support in TeleMIP’s Mobility Architecture’.<br />
Proc. 2000 IEEE International Confer<strong>en</strong>ce on Personal<br />
Wireless Communications, ICPWC, Diciembre 2000.<br />
A. Misra, S. Das, A. Dutta, y S.K. Das. ‘IDMP-based Fast<br />
Handoffs and Paging in <strong>ip</strong>-based Cellular Networks’. Proc.<br />
IEEE 3-G Wireless Confer<strong>en</strong>ce, 2001.<br />
S. Mohan, Y. Lin, A. Noerpel. ‘PCS Channel Assignm<strong>en</strong>ts<br />
Strategies For Handoff Initial Access’. IEEE Personal<br />
Communications Magazine, 3-1994.<br />
A. Myles y D. Skellern. ‘Comparing four IP based Mobile<br />
Host Protocols’. Computer Networks and ISDN Systems<br />
V.26, 1993.<br />
A. Myles, D.B. Johnson, y C. Perkins. ‘A Mobile Host<br />
Protocol supporting Route Optimization and Auth<strong>en</strong>tication’<br />
Journal on Selected Areas <strong>en</strong> Communications, junio 1995.<br />
J. Mysore, V. Bharghavan. ‘A New Multicasted-based<br />
Architecture for Internet Host Mobility’. Proc. of ACM<br />
Mobicom, Septiembre 1997.<br />
J. Mysore, V. Bharghavan. ‘Perfomance of Transport<br />
Protocols over a Multicasting-based Architecture for Internet<br />
Host MobilityA New Multicasted-based Architecture for<br />
Internet Host Mobility’. Proc. of ACM Mobicom, Septiembre<br />
363
Bibliografía<br />
1997.<br />
[ONE00]<br />
[PAJ99]<br />
[PAR97]<br />
[PER00]<br />
[PER01]<br />
[PER02]<br />
[PER04]<br />
[PER94]<br />
[PER94b]<br />
[PER99]<br />
[POL96]<br />
[RAM00]<br />
A. O'Neill, G. Tsirtsis, y S. Corson. ‘Edge Mobility<br />
Architecture’. Internet Draft. draft-oneill-ema-01.txt. (Work<br />
in Progress), Marzo 2000.<br />
A. Pajares, N. Berier, L. Wolf, R. Steinmetz. ‘An Approach to<br />
Suppport Mobile QoS in an Integrated Services Packet<br />
Network’. Proc. of IQWiM, Mayo 1999.<br />
V. Park y M.S. Corson. ‘A Highly Adaptative Distributed<br />
Routing Algorithm for Mobile Wireless Networks’. IEEE Proc.<br />
of Infocom, Abril 1997.<br />
C. Perkins , D. Johnson, y N. Asokan. ‘Registration Keys for<br />
Route Optimization’.Internet draft. draft-ietf-mobile<strong>ip</strong>regkey-03.txt.<br />
(Work in Progress), Julio 2000.<br />
C. Perkins y D.B. Johnson. ‘Route Optimization in Mobile IP’.<br />
Internet Draft. draft-ietf-mobile<strong>ip</strong>-optim-11.txt. (Work in<br />
Progress), Septiembre 2001.<br />
C. Perkins y P. Calhoun. ‘AAA Registration Keys for Mobile<br />
IP’. Internet Draft. draft-ietf-mobile<strong>ip</strong>-aaa-key-09.txt. (Work<br />
in Progress), Febrero 2002.<br />
C. Perkins y P. Calhoun. ‘AAA Registration Keys for Mobile<br />
Ipv4’. Internet Draft. draft-ietf-m<strong>ip</strong>4-key-03.txt. (Work in<br />
Progress), Febrero 2004.<br />
C. Perkins y P. Bhagwat. ‘A Mobile Networking System<br />
based on Internet Protocol’. IEEE Personal Communicaation<br />
Magazine, febrero 1994.<br />
C. Perkins, A.Myles y D. Johnson. ‘IMHP: A Mobile Hosts<br />
Protocol for the Internet’. Computer Networks and ISDN<br />
Systems V.27, 1994<br />
C. Perkins y K. Wang. ‘Optimized Smooth Handoffs in Mobile<br />
IP’. Proc. of the IEEE Symposium on Computers and<br />
Communications, Julio 1999.<br />
G. P. Pollini. ‘Tr<strong>en</strong>ds in Handover Design’. IEEE<br />
Communications Magazine, Marzo 1996.<br />
R. Ramjee, T.L. Porta, y L. Li. ‘Paging Support for IP<br />
364
Bibliografía<br />
Mobility’. Internet Draft. draft-ietf-mobile<strong>ip</strong>-paging-hawaii-<br />
01.txt. (Work in Progress), Julio 2000.<br />
[RAM00b]<br />
[RAM96]<br />
[RAM99]<br />
[REI01]<br />
[SCH00]<br />
[SCH95]<br />
[SES97]<br />
[SHE01]<br />
[SNO00]<br />
[SOL98]<br />
R. Ramjee, T.L. Porta, L. Salgarelli, S. Thuel, K. Varadhan,<br />
y L. Li. ‘IP Based Access Network Infrastructure for Next<br />
G<strong>en</strong>eration Wireless Data Networks’. IEEE Personal<br />
Communications Mag. Vol 7, Agosto 2000.<br />
R. Ramjee, T. La Porta, J. Kurose, y D. Towsley.<br />
‘Performance Evaluation of Connection Rerouting Schemes for<br />
ATM-based Wireless Networks’. IEEE/ACM Transactions on<br />
Networking. Vol. 6, Nº 2, Junio 1998.<br />
R. Ramjee, T.L. Porta, S. Thuel, K. Varadhan, S.Y Wang.<br />
‘Hawaii: A Domain-based Approach for Suporting Mobility in<br />
Wide-area Wireless Networks’. Proc. IEEE International<br />
Confer<strong>en</strong>ce of Network Protocols, 1999<br />
P. Reinbold y O. Bonav<strong>en</strong>ture. ‘A Comparison of IP Mobility<br />
Protocol’. Tech. Rep. Infonet-TR-2001-07, University of<br />
Namur, Infonet Group, Junio 2001.<br />
H. Schulzrinne, y E. Wedlund. ‘Application Layer Mobility<br />
Support using SIP’. ACM Mobile Computing and<br />
Communications Review, vol. 4, no. 3, Julio 2000.<br />
B. Schneier. ‘Applied Cryptography: Protocols, Algorithms,<br />
and Source Code in C, 2 ed.’Ed. Fohn Wiley & Soons, 1995.<br />
S. Seshan, H. Balakrishnan, y R.H. Katz. ‘Handoffs in<br />
Cellular Wireless Networks: The Daedalus Implem<strong>en</strong>tation<br />
and Experi<strong>en</strong>ce’. Kluwer Journal on Wireless Networks,<br />
1995<br />
Z.D. Shelby, D. Gatzounas, A. Campbell, Ch. Wan. ‘Cellular<br />
IPv6’. Internet Draft. draft-shelby-cellular<strong>ip</strong>v6-01.txt. (Work<br />
in Progress), Julio 2001.<br />
A.C. Snoer<strong>en</strong> y H. Balakrishnan. ‘An End-toEnd Approach to<br />
Host Mobility’. 6 th ACM/IEEE International Confer<strong>en</strong>ce on<br />
Mobile Computing and Networking (MobiCom’00), Agosto<br />
2000.<br />
J.D. Solomon. ‘Mobile IP: The Internet Unplugged’. Ed.<br />
Pr<strong>en</strong>tice Hall, 1998<br />
365
Bibliografía<br />
[STA98]<br />
[STE90]<br />
[TER91]<br />
[TER93]<br />
[TER94]<br />
[VAL99]<br />
[VAT98]<br />
M. Stangel y V. Bharghavan. ‘Improving TCP Performance in<br />
Mobile Computing Environm<strong>en</strong>ts’. Proc. of International<br />
Confer<strong>en</strong>ce on Communications, Junio 98.<br />
R. Steinmetz, ‘Synchronization Properties in Multimedia<br />
Systems’, IEEE J.S.A.C Vol. 8, Nº. 3, Abril 1990.<br />
F. Teraoka, Y. Yokote, y M. Tokoro. ‘A Network Architecture<br />
Providing Host Migration Transpar<strong>en</strong>cy’. Proc. of ACM<br />
SIGVCOMM, 1991.<br />
F. Teraoka y M.Tokoro. ‘Host Migration Transpar<strong>en</strong>cy in IP<br />
Networks’. Computer Communications Review, <strong>en</strong>ero 1993.<br />
F. Teraoka, K. Uehara, H. Sunahara, y J. Murai. ‘VIP: A<br />
Protocol Providing Host Mobility’. Communications of the<br />
ACM, agosto 1994.<br />
A.G. Valko. ‘Cellular IP: A New Approach to Internet Host<br />
Mobility’. ACM Computer Communication Review, Enero<br />
1999.<br />
J. Vatn y G.Q. Maguire Jr. ‘The effect of using co-located<br />
care-of address on macro handover lat<strong>en</strong>cy’. Proc. of the 14 th<br />
Nordic Tele-traffic Seminar, Agosto 1998.<br />
[VID03] R. Vida y L. Costa. ‘Multicast List<strong>en</strong>er Discovery Version 2<br />
(MLDv2) for IPv6’. Internet Draft. draft-vida-mld-v2-07.txt.<br />
(Work in Progress), Junio 2003<br />
[WED99]<br />
[WILL00]<br />
E. Wedlund, H. Schulzrinne. ‘Mobility Support Using SIP’.<br />
Proc. of the 2nd ACM International Workshop on Wireless<br />
Mobile Multimedia (WoWMoM'99), Agosto 1999.<br />
B. Williamson. ‘Developing IP Multicast Networks’. Cisco<br />
Press, 2000<br />
[WIS02]<br />
[WON01]<br />
D. Wisely, P. Eardley, y L. Burness. ‘IP for 3G: Networking<br />
Technologies for Mobil Communications’. John Wiley & Sons,<br />
2002<br />
K. D. Wong, H. Wei, A. Dutta, y K Young. ‘Performance of IP<br />
Micro-Mobility Managem<strong>en</strong>t Schemes using Host Based<br />
366
Bibliografía<br />
Routing’. Proc. of International Symposium on Wireless<br />
Personal Multimedia Communications WPMC '01,<br />
Septiembre 2001.<br />
[YAV94]<br />
[YEG02]<br />
[YEG02b]<br />
[YUA96]<br />
[ZHA98]<br />
R. Yavatkar y N. Bhagwat. ‘Improving <strong>en</strong>d-to-<strong>en</strong>d<br />
Performance of TCP Over Mobile Internetworks’. Workshop<br />
on Mobile Computing Systems and Applications, Diciembre<br />
1994<br />
A.E. Yegin (editor) et al. ‘Supporting Optimized Handover for<br />
IP Mobility - Requirem<strong>en</strong>ts for Underlying Systems’. Internet<br />
Draft. draft-manyfolks-l2-mobilereq02.txt. (Work in<br />
Progress), Junio 2002<br />
A.E. Yegin. ‘Link-Layer Triggers Protocol’. Internet Draft.<br />
draft-yegin-l2-triggers-00.txt (Work in Progress), Junio 2002<br />
R. Yuan, S. K. Biswas, D. Raychaudhuri. ‘A Signaling and<br />
Control Architecture for Mobility Support in Wireless ATM<br />
Networks’. Mobile Networks and Applications (MONET), nº3<br />
V.1, 1996<br />
X. Zhao, C. Castelluccia, y M. Baker. ‘Flexible Network<br />
Support for Mobility’. Proc. of Mobicom, Octubre 1998.<br />
REQUEST FOR COMMENTS, RFC<br />
[RFC 768] J. Postel. ‘User Datagram Protocol’, Agosto 1980.<br />
[RFC 791] J. Postel. ‘Internet Protocol’, Septiembre 1981.<br />
[RFC 793]<br />
[RFC 826]<br />
[RFC 1035]<br />
[RFC 1075]<br />
J. Postel. ‘Transmission Control Protocol’. Septiembre<br />
1981.<br />
D.C. Plummer. ‘Address Resolution Protocol’, Noviembre<br />
1982.<br />
P. Mockapetris. ‘Domain Names - Implem<strong>en</strong>tation and<br />
Specification’, Noviembre 1987.<br />
D. Waitzman, C. Partridge, y S. Deering. ‘Distance Vector<br />
Multicast Routing Protocol’, Noviembre 1988.<br />
367
Bibliografía<br />
[RFC 1112]<br />
S. Deering. ‘Host Ext<strong>en</strong>sions for IP Multicasting’, Agosto<br />
1989.<br />
[RFC 1122] R. Brad<strong>en</strong>. ‘Requirem<strong>en</strong>ts for Internet Host’, Octubre 1989.<br />
[RFC 1256]<br />
S. Deering. ‘ICMP Router Discovery Messages’, Septiembre<br />
1991.<br />
[RFC 1321] R. Rivest. ‘The MD5 Message-Direct Algorithm’, Abril 1992.<br />
[RFC 1332]<br />
G. McGregor. ‘The PPP Internet Protocol Control Protocol’,<br />
Mayo 1992.<br />
[RFC 1584] J. Moy. ‘Multicast Ext<strong>en</strong>sions to OSPF’, Marzo 1994.<br />
[RFC 1701]<br />
[RFC 1945]<br />
[RFC 1889]<br />
[RFC 1994]<br />
S. Hanks, T. Li, D. Farinacci, y P. Traina. ‘G<strong>en</strong>eric Routing<br />
Encapsulation (GRE)’, Octubre 1994.<br />
T. Berners-Lee, R. Fielding, y H. Frystyk. ‘Hypertext<br />
Transfer Protocol. HTTP/1.0’, Mayo 1996.<br />
H. Schulzrinne, S. Casner, R. Frederic, y V. Jacobson.<br />
‘RTP: A Transport Protocol for Real-Time Applications’,<br />
Junio 1996.<br />
W. Simpson. ‘PPP Chall<strong>en</strong>ge Handshake Auth<strong>en</strong>tication<br />
Protocol (CHAP)’, Agosto 1996.<br />
[RFC 2002] C. Perkins. ‘IP Mobility Support’, Octubre 1996.<br />
[RFC 2003] C. Perkins. ‘IP Encapsulation Within IP’, Octubre 1996.<br />
[RFC 2004]<br />
[RFC 2104]<br />
[RFC 2117]<br />
[RFC 2131]<br />
C. Perkins. ‘Minimal Encapsulation Within IP’, Octubre<br />
1996.<br />
H. Krawczyk, M. Bellare, y R. Canetti. ‘HMAC: Keyed-<br />
Hashing for Message Auth<strong>en</strong>tication’, Febrero 1997.<br />
D. Estrin et al. ‘Protocol Indep<strong>en</strong>d<strong>en</strong>t Multicast-Sparse<br />
Mode (PIM-SM): Protocol Specification’, Junio 1997.<br />
R. Droms. ‘Dynamic Host Configuration Protocol (DHCP)’,<br />
Marzo 1997.<br />
368
Bibliografía<br />
[RFC 2189]<br />
[RFC 2201]<br />
[RFC 2205]<br />
[RFC 2215]<br />
[RFC 2236]<br />
[RFC 2290]<br />
[RFC 2362]<br />
[RFC 2373]<br />
[RFC 2402]<br />
[RFC 2406]<br />
[RFC 2408]<br />
[RFC 2460]<br />
[RFC 2461]<br />
A. Ballardie. ‘Core Based Trees (CBT version 2) Multicast<br />
Routing’, Septiembre 1997.<br />
A. Ballardie. ‘Core Based Trees (CBT) Multicast Routing<br />
Architecture’, Septiembre 1997.<br />
R. Brad<strong>en</strong>, L. Zhang, S. Berson, S. Herzog, y S. Jamin.<br />
‘Resource Reservation Protocol (RSVP)’, Septiembre 1997.<br />
S. Sh<strong>en</strong>ker, y J.Wroclawski. ‘G<strong>en</strong>eral Characterization<br />
Parameters for Integrated Service Network Elem<strong>en</strong>ts’,<br />
Septiembre 1997.<br />
W. F<strong>en</strong>ner. ‘Internet Group Managem<strong>en</strong>t Protocol, Version<br />
2’, Noviembre 1997.<br />
J. Solomon, y S. Glass. ‘Mobile-IPv4 Configuration Option<br />
for PPP IPCP’, Febrero 1998.<br />
D. Estrin et al. ‘Protocol Indep<strong>en</strong>d<strong>en</strong>t Multicast-Sparce<br />
Mode (PIM-SM)’, Junio 1998.<br />
R. Hind<strong>en</strong>, S. Deering. ‘IP Version 6 Addressing<br />
Architecture’, Julio 1998.<br />
S. K<strong>en</strong>t, y R. Atkinson. ‘IP Auth<strong>en</strong>tication Header’,<br />
Noviembre 1998.<br />
S. K<strong>en</strong>t, y R. Atkinson. ‘IP Encapsulating Security Payload<br />
(ESP)’, Noviembre 1998.<br />
D. Maughan, M. Schertler, M. Schneider, y J. Turner.<br />
‘Internet Saecurity Association and Key Managem<strong>en</strong>t<br />
Protocol (ISAKMP)’, Noviembre 1998.<br />
S. Deering, R. Hind<strong>en</strong>. ‘Internet Protocol, version 6 IPv6<br />
Specification’, Diciembre 1998.<br />
T. Nart<strong>en</strong>, E. Nordmark, y W. Simpson. ‘Neighbor<br />
Discovery for IP Version 6 (IPv6)’, Diciembre 1998.<br />
[RFC 2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, y W.<br />
Weiss. ‘An Architecture for Differ<strong>en</strong>tiated Services’,<br />
Diciembre 1998.<br />
369
Bibliografía<br />
[RFC 2462]<br />
[RFC 2486]<br />
[RFC 2526]<br />
[RFC 2543]<br />
[RFC 2582]<br />
[RFC 2616]<br />
[RFC 2794]<br />
[RFC 2827]<br />
[RFC 2865]<br />
S. Thomson, y T. Nart<strong>en</strong>. ‘IPv6 Stateless Address<br />
Autoconfiguration’, Diciembre 1998.<br />
B. Aboba, y M. Beadles. ‘The Network Access Id<strong>en</strong>tifier’,<br />
Enero 1999.<br />
D. Johnson, y S. Deering. ‘Reserved IPv6 Subnet Anycast<br />
Addresses’, Marzo 1999.<br />
M. Handley, H. Schulzrinne, E. Schooler, y J. Ros<strong>en</strong>berg.<br />
‘SIP: Session Initiation Protocol’, Marzo 1999.<br />
S. Floyd, y T. H<strong>en</strong>derson. ‘The NewR<strong>en</strong>o Modification to<br />
TCP's Fast Recovery Algorithm’, Abril 1999.<br />
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,<br />
P. Leach, y T. Berners-Lee. ‘Hypertext Transfer Protocol,<br />
HTTP 1.1’, Junio 1999.<br />
P. Calhoun, y C. Perkins. ‘Mobile IP Network Access<br />
Id<strong>en</strong>tifier Ext<strong>en</strong>sion for Ipv4’, Marzo 2000.<br />
P. Ferguson, y D. S<strong>en</strong>ie. ‘Network Ingress Filtering:<br />
Defeating D<strong>en</strong>ial of Service Attacks which employ IP Source<br />
Address Spoofing’, Mayo 2000.<br />
C. Rigney, S. Will<strong>en</strong>s, A. Rub<strong>en</strong>s, y W. Simpson. ‘Remote<br />
Auth<strong>en</strong>tication Dial In User Service (RADIUS)’, Junio 2000.<br />
[RFC 2976] S. Donovan. ‘The SIP INFO Method’, Octubre 2000.<br />
[RFC 2977]<br />
[RFC 3012]<br />
[RFC 3024]<br />
S. Glass, T. Hiller, S. Jacobs, y C.Perkins. ‘Mobile IP<br />
Auth<strong>en</strong>tication, Authorization, and Accounting<br />
Requirem<strong>en</strong>ts’, Octubre 2000.<br />
C. Perkins, P. Calhoun. ‘Mobile IPv4 Chall<strong>en</strong>ge/Response<br />
Ext<strong>en</strong>sions’, Noviembre 2000.<br />
G. Mont<strong>en</strong>egro. ‘Reverse Tunneling for Mobile IP, revised’,<br />
Enero 2001.<br />
[RFC 3184] S. Harris. ‘IETF Guidelines for Conduct’, Octubre 2001.<br />
[RFC 3344] C. Perkins. ‘IP Mobility Support for IPv4’, Agosto 2002.<br />
370
Bibliografía<br />
[RFC 3376] B. Cain, S. Deering, I.Kouvelas, B. F<strong>en</strong>ner, y A.<br />
Thyagarajam. ‘Internet Group Managem<strong>en</strong>t Protocol,<br />
Version 3’, Octubre 2002.<br />
[RFC 3583]<br />
H. Chascar. ‘Requirem<strong>en</strong>ts of a Quality of Service (QoS)<br />
Solution for Mobile IP’. Septiembre 2003.<br />
RECURSOS EN INTERNET<br />
[COM]<br />
[COR]<br />
[DYN]<br />
[HP]<br />
[IANA]<br />
[JMF]<br />
[MGE]<br />
[MIPv4]<br />
[MIPv6]<br />
[MOB]<br />
[MON]<br />
[MOS]<br />
[NS2]<br />
[NTT]<br />
[OPN]<br />
http://www.comet.columbia.edu/<br />
http://www.isi.edu/conser/index.html<br />
http://dynamics.sourceforge.net/<br />
http://www.hpl.hp.com/personal/Jean_Tourrilhes/MobileI<br />
P/index.html<br />
Internet Assigned Number Authority.<br />
http://www.iana.org/numbers.html<br />
http://java.sun.com/products/java-media/jmf/<br />
http://manimac.itd.nrl.navy.mil/MGEN<br />
http://www.ietf.org/html.charters/m<strong>ip</strong>4-charter.html<br />
http://www.ietf.org/html.charters/m<strong>ip</strong>6-charter.html<br />
http://www.<strong>ip</strong>rg.nokia.com/~charliep/mobins2/<br />
http://www.monarch.cs.rice.edu/<br />
http://mosquitonet.stanford.edu/m<strong>ip</strong>/<br />
http://www.isi.edu/nsnam/ns<br />
http://www.leo.org/~elmar/nttcp/<br />
http://www.opnet.com/products/modeler/<br />
371
Bibliografía<br />
[POR]<br />
[SEA]<br />
[SAM]<br />
[SUN]<br />
[TCP]<br />
http://www.cs.pdx.edu/research/SMN/<br />
http://www.ietf.org/html.charters/seamoby-charter.html<br />
http://www.isi.edu/saman/index.html<br />
http://playground.sun.com/pub/mobile-<strong>ip</strong>/index.html<br />
http://www.tcpdump.org<br />
372
ANEXO1. ACRÓNIMOS Y GLOSARIO<br />
ACRÓNIMOS<br />
3GPP 3rd G<strong>en</strong>eration Partnersh<strong>ip</strong> Project.<br />
3GPP2 3rd G<strong>en</strong>eration Partnersh<strong>ip</strong> Project 2.<br />
AAA<br />
Auth<strong>en</strong>tication, Authorization, Accounting.<br />
AAL<br />
ATM Adaptation Layer.<br />
aFA<br />
Anchor Foreign Ag<strong>en</strong>t. (Handover con post registro).<br />
AP<br />
Access Point.<br />
AR<br />
Access Router.<br />
ATM<br />
Asynchronous Transfer Mode.<br />
BS<br />
Base Station.<br />
BSC<br />
Base Station Controllers. (Tecnología GSM)<br />
BSS<br />
Basic Service Set (tecnología WLAN).<br />
CBR<br />
Constant Bit Rate.<br />
CBT Core Based Trees. [RFC 2189]<br />
CDMA Code Division Mult<strong>ip</strong>le Access.<br />
CHAP Handshake Auth<strong>en</strong>tication Protocol. [RFC 1994]<br />
CN<br />
Correspond Node.<br />
COA<br />
Care-of Address.<br />
DHCP Dynamic Host Configuration Protocol. [RFC 2131]<br />
DNS Domain Name System. [RFC 0921]<br />
DRR<br />
Domain Root Router. (Esquema Hawaii)<br />
DVMRP Distance Vector Multicast Routing Protocol. [RFC 1075]<br />
ESP Encapsulating Security Payload. [RFC 1827]<br />
FA<br />
Foreign Ag<strong>en</strong>t.<br />
GFA<br />
Gateway Foreign Ag<strong>en</strong>t. (Esquema MIP-RR)<br />
GPRS G<strong>en</strong>eral Packet Radio Service.<br />
GTP<br />
GPRS Tunnelling Protocol.<br />
HA<br />
Home Ag<strong>en</strong>t.<br />
HBR<br />
Host Based Routing.<br />
HMAC Hashed Message Auth<strong>en</strong>tication Code. [RFC 2104]<br />
HN<br />
Home Network.<br />
IAPP<br />
InterAccess Point Protocol. (Tecnología IEEE 802.11f)<br />
373
Anexo1. Acrónimos y Definiciones<br />
ICMP Internet Control Message Protocol. [RFC1256]<br />
IDMP Intra-Domain Mobility Managem<strong>en</strong>t Protocol.<br />
IGMP Internet Group Managem<strong>en</strong>t Protocol. [RFC 3376]<br />
IP Internet Protocol. [RFC 791]<br />
IPCP<br />
PPP Internet Protocol Control Protocol. [RFC1332]<br />
ISAKMP Internet Security Association and Key Managem<strong>en</strong>t<br />
Protocol. [RFC 2408]<br />
LSR<br />
Loose Source Routing.<br />
MA<br />
Mobility Ag<strong>en</strong>t. (Esquema Cellular IP)<br />
MAE<br />
Multicast Address Ext<strong>en</strong>sión. (Esquema <strong>multicast</strong><br />
propuesto)<br />
MAS<br />
Mobile Access Station. (Tecnología LSR)<br />
MIP Mobile IP. [RFC 3344]<br />
MIP-RR Mobile IP with Regional Registration.<br />
MMA Multicast Mobility Ag<strong>en</strong>t. (Esquema <strong>multicast</strong> propuesto)<br />
MN<br />
Mobile Node.<br />
MNF<br />
Multicast Non-Forwarding. (Esquema Hawaii)<br />
MOSPF Multicast Ext<strong>en</strong>sion to OSPF. [RFC 1584]<br />
MR<br />
Mobile Router. (Tecnología LSR)<br />
MSC<br />
Mobile Switching C<strong>en</strong>tre. (Tecnología GSM)<br />
MSF<br />
Mult<strong>ip</strong>le Stream Forwarding. (Esquema Hawaii)<br />
MSR<br />
Mobile Support Routers. (Esquema Columbia)<br />
MWIF Mobile Wireless Internet Forum.<br />
NAI<br />
Network Access Id<strong>en</strong>tifier.<br />
nBS<br />
New Base Station.<br />
nFA<br />
New Foreign Ag<strong>en</strong>t.<br />
oBS<br />
Old Base Station.<br />
oFA<br />
Old Foreign Ag<strong>en</strong>t.<br />
OSPF Op<strong>en</strong> Shortest Path First Protocol. [RFC 1247]<br />
PDP Packet Data Protocol. (Tecnología 3G)<br />
PIM-SM Protocol Indep<strong>en</strong>d<strong>en</strong>t Multicast- Sparse Mode. [RFC<br />
2362]<br />
RADIUS Remote Auth<strong>en</strong>tication Dial In User Service. [RFC 2865]<br />
RNC Radio Network Controler. (Tecnología 3G)<br />
RP<br />
R<strong>en</strong>dezvous Point. (Tecnología <strong>multicast</strong>)<br />
RR<br />
Root Router. (Tecnología multicat)<br />
RSVP Resource Reservation Protocol. [RFC 2205]<br />
374
Anexo1. Acrónimos y Definiciones<br />
RTP<br />
SIP<br />
SPI<br />
SPT<br />
SRT<br />
SSF<br />
SSID<br />
SSM<br />
ST<br />
Transport Protocol for Real-Time Applications. [RFC<br />
1889]<br />
Session Initiation Protocol.<br />
Security Parameter Index.<br />
Shorted Path Tree.<br />
Source Based Tree. (Tecnología <strong>multicast</strong>)<br />
Single Stream Forwarding. (Esquema Hawaii)<br />
Service Set Id<strong>en</strong>tifier. (Tecnología WLAN)<br />
Source-Specific Multicast.<br />
Shared Tree. (Tecnología <strong>multicast</strong>)<br />
TCP Transmission Control Protocol. [RFC 793]<br />
TDMA Time Division Mult<strong>ip</strong>le Access.<br />
TMA<br />
TeleMIP Mobility Ag<strong>en</strong>t.<br />
UDP User Datagram Protocol. [RFC 768]<br />
UMTS Universal Mobile Telecommunications System.<br />
UNF<br />
Unicast Non-Forwarding. (Esquema Hawaii)<br />
UTRAN UMTS Radio Access Network. (Tecnología 3G)<br />
WLAN Wireless Local Area Networks.<br />
GLOSARIO<br />
‘Ag<strong>en</strong>t<br />
Advertisem<strong>en</strong>t’:<br />
Ag<strong>en</strong>te de Movilidad<br />
Multicast (MMA):<br />
Árbol Basado <strong>en</strong><br />
Fu<strong>en</strong>te (SRT):<br />
Árbol por el camino<br />
más corto (SPT):<br />
Care-of Address<br />
M<strong>en</strong>saje utilizado por los Ag<strong>en</strong>tes para informar<br />
al MN de la red donde se <strong>en</strong>cu<strong>en</strong>tra. Se crea<br />
añadi<strong>en</strong>do ext<strong>en</strong>siones a un m<strong>en</strong>saje ICMP, [RFC<br />
1256]<br />
Ag<strong>en</strong>te pasarela utilizado <strong>en</strong> el sistema de micromobilidad<br />
<strong>basado</strong> <strong>en</strong> <strong>multicast</strong> propuesto.<br />
Método de elaboración del árbol <strong>multicast</strong>, que<br />
parte de la fu<strong>en</strong>te y conecta a todos los miembros<br />
del grupo <strong>multicast</strong>. Técnica utilizada <strong>en</strong> los<br />
protocolos de ‘modo d<strong>en</strong>so’.<br />
Algoritmo que obti<strong>en</strong>e ruta de m<strong>en</strong>or coste desde<br />
una fu<strong>en</strong>te a un destino.<br />
Dirección temporal que utiliza el MN cuando se<br />
375
Anexo1. Acrónimos y Definiciones<br />
(CoA):<br />
Cellular IP:<br />
Contexto de<br />
Seguridad (SPI):<br />
Encaminami<strong>en</strong>to<br />
Basado <strong>en</strong> Host<br />
(HBR):<br />
Estación Base (BS):<br />
Foreign Ag<strong>en</strong>t (HA):<br />
Foreign Network<br />
(FN):<br />
Handover Rápido:<br />
Handover Sin<br />
Degradación:<br />
Handover Suave:<br />
<strong>en</strong>cu<strong>en</strong>tra fuera de su HN. El punto de salida del<br />
túnel que utiliza el HA para <strong>en</strong>viar los paquetes<br />
dirigidos al MN.<br />
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> HBR.<br />
Asociación compuesta por el mecanismo de<br />
seguridad y clave a emplear, que compart<strong>en</strong> dos<br />
elem<strong>en</strong>tos del sistema IP móvil.<br />
Solución empleada <strong>en</strong> algunos sistemas de micro<strong>movilidad</strong><br />
<strong>en</strong> los que el <strong>en</strong>caminami<strong>en</strong>to se<br />
realiza consultando <strong>en</strong> tablas la dirección del<br />
Host, <strong>en</strong> vez de utilizar el <strong>en</strong>caminami<strong>en</strong>to clásico<br />
de IP <strong>basado</strong> <strong>en</strong> redes.<br />
Nodos utilizadas <strong>en</strong> el sistema de micro-<strong>movilidad</strong><br />
<strong>basado</strong> <strong>en</strong> <strong>multicast</strong> propuesto. Ti<strong>en</strong><strong>en</strong> capacidad<br />
de nivel tres y además heredan las tareas de los<br />
FA de MIP, así como realizan las tareas propias<br />
del protocolo propuesto.<br />
Router con un interfaz a una red externa, Foreign<br />
Network, donde está situado el nodo móvil <strong>en</strong> la<br />
actualidad.<br />
Cualquier otra red difer<strong>en</strong>te a la Home Network y<br />
que, por tanto, su id<strong>en</strong>tificativo de red difiere del<br />
de la red IP del nodo.<br />
Proceso de Handover <strong>en</strong> el que su princ<strong>ip</strong>al<br />
motivación es la <strong>en</strong>trega de paquetes con retardo<br />
mínimo.<br />
Handover <strong>en</strong> el que no se produce cambio <strong>en</strong> la<br />
capacidad de servicio, seguridad o calidad. En la<br />
práctica se aplica a aquellos handovers <strong>en</strong> las<br />
que las aplicaciones o usuarios finales no<br />
detectan cambios que afectan a su normal<br />
funcionami<strong>en</strong>to.<br />
Proceso de Handover <strong>en</strong> el que el objetivo es<br />
minimizar la pérdida de paquetes, sin una<br />
preocupación explícita del retardo <strong>en</strong> la <strong>en</strong>trega<br />
de paquetes.<br />
376
Anexo1. Acrónimos y Definiciones<br />
‘Handover Switch<br />
Indication’:<br />
Handover:<br />
HAWAII:<br />
H.263:<br />
Home Ag<strong>en</strong>t (HA):<br />
Home Network (HN):<br />
IGMP:<br />
‘Intra-Doamin<br />
Registration<br />
Request’:<br />
‘Join’:<br />
M<strong>en</strong>saje propuesto para el sistema de micro<strong>movilidad</strong><br />
<strong>basado</strong> <strong>en</strong> <strong>multicast</strong> que se utiliza <strong>en</strong> el<br />
esquema de Handover con finalización<br />
controlada. Enviado por el MN indica al nBS que<br />
puede com<strong>en</strong>zar a transmitirle paquetes.<br />
Proceso <strong>en</strong> el que el nodo móvil cambia de una<br />
estación base a otra. En esta tesis, a no ser que<br />
se indique lo contrario, se <strong>en</strong>ti<strong>en</strong>de que es un<br />
handover de capa 3, que implica un cambio de<br />
subred.<br />
Sistema de micro-<strong>movilidad</strong> <strong>basado</strong> <strong>en</strong> HBR.<br />
Estándar de codificación de video de baja tasa<br />
diseñado para videoconfer<strong>en</strong>cia y videotelefonía.<br />
Utiliza redundancia temporal por lo que <strong>en</strong>vía<br />
‘intraframes’ para que se pueda codificar el<br />
movimi<strong>en</strong>to a partir de estas tramas. Los vectores<br />
de movimi<strong>en</strong>to indican el movimi<strong>en</strong>to de los<br />
macrobloques con respecto a la ‘intraframe’<br />
anterior.<br />
Un router con un interfaz a la red local, Home<br />
Network, que manti<strong>en</strong>e información de la<br />
situación actual del nodo móvil.<br />
Red <strong>en</strong> la que el nodo móvil debería estar<br />
localizado. Esto es, la red que ti<strong>en</strong>e asignado el<br />
mismo id<strong>en</strong>tificativo de red que el que existe <strong>en</strong> la<br />
dirección IP del nodo.<br />
Protocolo utilizado por los routers <strong>multicast</strong> para<br />
conocer la exist<strong>en</strong>cia de miembros de un grupo<br />
<strong>multicast</strong> <strong>en</strong> las subredes que ti<strong>en</strong>e directam<strong>en</strong>te<br />
conectadas.<br />
M<strong>en</strong>saje del sistema de micro-<strong>movilidad</strong> <strong>basado</strong><br />
<strong>en</strong> <strong>multicast</strong> utilizado para realizar un handover<br />
d<strong>en</strong>tro del dominio.<br />
M<strong>en</strong>saje utilizado <strong>en</strong> los protocolos <strong>multicast</strong><br />
empleado para que un nodo (BS) se conecte al<br />
árbol <strong>multicast</strong>.<br />
Lat<strong>en</strong>cia del Tiempo necesario para que se realice<br />
377
Anexo1. Acrónimos y Definiciones<br />
Handover:<br />
Mobile IP (MIP):<br />
‘Multicast Address<br />
Ext<strong>en</strong>sion’ (MAE):<br />
Multicast con<br />
Fu<strong>en</strong>te Específica<br />
(SSM):<br />
‘Multicast Handover<br />
Reply’:<br />
‘Multicast Prune<br />
Request’:<br />
Nodo Móvil (MN):<br />
Optimización de<br />
Ruta:<br />
completam<strong>en</strong>te el handover. Puede obt<strong>en</strong>erse<br />
como la suma de tres procesos: retardo de la<br />
detección de movimi<strong>en</strong>to; de la recuperación de la<br />
dirección temporal; y retardo del restablecimi<strong>en</strong>to<br />
de ruta.<br />
Protocolo de <strong>movilidad</strong> IP <strong>basado</strong> <strong>en</strong> la utilización<br />
de una dirección temporal (CoA) cuando el nodo<br />
no se <strong>en</strong>cu<strong>en</strong>tra <strong>en</strong> su HN, [RFC 3344].<br />
Ext<strong>en</strong>sión del m<strong>en</strong>saje ‘Registration Reply’<br />
utilizado <strong>en</strong> el sistema de micro-<strong>movilidad</strong> <strong>basado</strong><br />
<strong>en</strong> <strong>multicast</strong> propuesto. Es utilizada para que el<br />
MN recibiera la dirección <strong>multicast</strong> que le ha sido<br />
asignada <strong>en</strong> ese dominio.<br />
Tecnología <strong>multicast</strong> novedosa <strong>en</strong> la que se utiliza<br />
concepto de ‘canal’ que está definido por el par<br />
‘fu<strong>en</strong>te’-‘grupo’.<br />
M<strong>en</strong>saje propuesto para el sistema de micro<strong>movilidad</strong><br />
<strong>basado</strong> <strong>en</strong> <strong>multicast</strong> que se utiliza,<br />
opcionalm<strong>en</strong>te, para confirmar un m<strong>en</strong>saje<br />
‘Multicast Prune Request’.<br />
M<strong>en</strong>saje propuesto para el sistema de micro<strong>movilidad</strong><br />
<strong>basado</strong> <strong>en</strong> <strong>multicast</strong> que se utiliza para<br />
informar a la Estación Base antigua que el nodo<br />
móvil ha pasado a dep<strong>en</strong>der de otra BS.<br />
Nodo que puede cambiar su punto de conexión<br />
de una subred a otra, mant<strong>en</strong>i<strong>en</strong>do cualquier<br />
comunicación, y sin cambiar de dirección IP.<br />
Mecanismo bajo estudio que permite a los nodos<br />
almac<strong>en</strong>ar información de la situación de un<br />
nodo móvil (Care-of Address), y que permitirá al<br />
host <strong>en</strong>viar los datagramas, por medio de un<br />
túnel, directam<strong>en</strong>te a esta dirección, eliminando<br />
el paso de los datagramas por el HA.<br />
PIM-SM: Protocolo para g<strong>en</strong>erar el árbol <strong>multicast</strong>,<br />
utilizado <strong>en</strong> ambi<strong>en</strong>tes poco d<strong>en</strong>sos (los<br />
miembros del grupo están distribuidos por la<br />
red), [RFC 2362].<br />
378
Anexo1. Acrónimos y Definiciones<br />
‘Registration Reply’: M<strong>en</strong>saje transmitido por el HA hacia el MN<br />
aceptando o rechazando la petición de registro de<br />
la nueva dirección CoA.<br />
‘Registration<br />
Request’:<br />
Registro Regional:<br />
R<strong>en</strong>dezvous Point<br />
(RP):<br />
Session Initiation<br />
Protocol (SIP):<br />
M<strong>en</strong>saje utilizado por el MN para informar al HA<br />
de la nueva dirección CoA que va a utilizar.<br />
Esquema de micro-<strong>movilidad</strong>, <strong>basado</strong> <strong>en</strong> niveles,<br />
de manera que <strong>en</strong> cada Dominio existe un Ag<strong>en</strong>te<br />
Pasarela (GFA), cuya dirección se registrará como<br />
CoA <strong>en</strong> el HA, y que recibirá los registros de las<br />
direcciones que va obt<strong>en</strong>i<strong>en</strong>do el MN d<strong>en</strong>tro del<br />
dominio.<br />
Nodo c<strong>en</strong>tral del árbol <strong>multicast</strong> utilizado <strong>en</strong><br />
protocolos de ‘modo disperso’ como PIM-SM.<br />
Protocolo de control para la creación,<br />
modificación y finalización de sesiones con uno o<br />
más partic<strong>ip</strong>antes, [RFC 2543].<br />
Trigger: Abstracción de una notificación desde la capa 2<br />
que indica que cierto ev<strong>en</strong>to ha ocurrido o se va a<br />
producir.<br />
379
Anexo1. Acrónimos y Definiciones<br />
380
ANEXO 2. DESARROLLO DE LAS ECUACIONES<br />
DEL CAPÍTULO 7<br />
A2.1. Desarrollo de la ecuación 7.27<br />
[ 0 < ( k −1)<br />
T + u < X ' −Y<br />
' e'<br />
]<br />
Pper − k = Prob<br />
+<br />
(7.27)<br />
con:<br />
X’ = v.a. con fdd: f<br />
Y’ = v.a. con fdd: f<br />
X '<br />
Y '<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
3 2<br />
β t −β t<br />
e' = ( CN,<br />
R1 ) + ( R1<br />
, oBS)<br />
− ( CN,<br />
R2<br />
) − ( R2<br />
, nBS)<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
La ecuación (7.27) la podemos rescribir de la sigui<strong>en</strong>te manera:<br />
P<br />
= Pr ob[ Y ' −X<br />
' + u ≤ e'<br />
−(<br />
k −1<br />
T ]=<br />
per −k<br />
)<br />
∫<br />
= T 0<br />
1<br />
Prob[ Y ' −X<br />
' ≤ z'<br />
−uo<br />
] duo<br />
(7.27a)<br />
T<br />
con<br />
z ' = e'<br />
−(<br />
k −1)<br />
T<br />
La probabilidad que aparece como parte de la ecuación (7.27a)<br />
podemos, a su vez, desarrollarla como sigue:<br />
[ ≤ z' − u ] = Prob[ Y ' ≤ z'<br />
−u<br />
x ]<br />
Prob Y'-X'<br />
∫ ∞ o<br />
o + o f X ' ( xo<br />
) dxo<br />
(7.27b)<br />
0<br />
La probabilidad de que Y’ sea m<strong>en</strong>or que un valor puede escribirse<br />
por medio de su función de distribución. Sustituy<strong>en</strong>do, además, ( x)<br />
, la<br />
ecuación anterior nos queda:<br />
f X '<br />
381
Anexo 2. Desarrollo de ecuaciones.<br />
Prob<br />
[ Y'-X' ≤ z' − uo<br />
] =<br />
∫<br />
∞<br />
⎡ 2<br />
−β<br />
( z'<br />
−u<br />
+ x ) ( z'<br />
−uo<br />
+ xo<br />
)<br />
⎢<br />
o o<br />
1−<br />
e ∑<br />
⎢<br />
j!<br />
⎣<br />
max(0, u − z')<br />
j=<br />
0<br />
o<br />
3 2<br />
β xo<br />
−β xo<br />
*<br />
2<br />
e<br />
j<br />
dx<br />
j<br />
β ⎤<br />
⎥ *<br />
⎥<br />
⎦<br />
o<br />
(7.27c)<br />
f X '<br />
Es interesante observar el limite inferior de la ecuación anterior.<br />
( x)<br />
es distinto de cero sólo para valores de xo mayores que cero. Pero,<br />
además, a probabilidad [ Y ' ≤ z'−<br />
+ ]<br />
negativo.<br />
Prob u o x o también es nula si z′-uo+xo es<br />
Sustituy<strong>en</strong>do ahora el valor obt<strong>en</strong>ido <strong>en</strong> (7.27c) <strong>en</strong> la ecuación<br />
(7.27a), t<strong>en</strong>emos:<br />
P<br />
per−k<br />
T<br />
∫ ∫<br />
∞<br />
2<br />
1<br />
−β<br />
( z'<br />
− + )<br />
= ⎢1<br />
−<br />
u o<br />
xo<br />
e<br />
T<br />
∑<br />
⎢<br />
0 max(0,u -z')<br />
j=<br />
0<br />
o<br />
⎡ ( z'<br />
−u<br />
+ x )<br />
⎣<br />
o<br />
j!<br />
o<br />
j<br />
j ⎤ 3<br />
β β x<br />
⎥<br />
⎥ 2<br />
⎦<br />
2<br />
o<br />
e<br />
−β<br />
xo<br />
dx<br />
o<br />
du<br />
(7.27d)<br />
o<br />
Para finalizar, y sólo para facilitar la resolución numérica de la<br />
expresión anterior, podemos realizar un cambio de variable, de manera<br />
que logremos integrales definidas. Sustituy<strong>en</strong>do w<br />
operando, t<strong>en</strong>emos finalm<strong>en</strong>te:<br />
−β x<br />
o<br />
= e , dw −β wdxo<br />
= , y<br />
P<br />
per−k<br />
T<br />
∫ 0∫<br />
min(1, e<br />
β ( z'<br />
−uo<br />
)<br />
)<br />
⎡<br />
2<br />
1<br />
−β<br />
( z'<br />
−u<br />
) ( z'<br />
−u<br />
− ( ( ) / ))<br />
= ⎢<br />
o<br />
o Ln w β<br />
1−<br />
e w<br />
T<br />
∑<br />
⎢<br />
j!<br />
0 ⎣<br />
j=<br />
0<br />
2<br />
Ln(<br />
w)<br />
* dwdu o<br />
2<br />
j<br />
j<br />
β ⎤<br />
⎥ *<br />
⎥<br />
⎦<br />
(7.27e)<br />
382
Anexo 2. Desarrollo de ecuaciones.<br />
A2.2. Desarrollo de la ecuación 7.51<br />
P cl<br />
[ Y ' + d'<br />
+ ϕ − X ' −c'<br />
< ( k −1)<br />
T + u < Y ' − ' +ϕ ]<br />
k − . 2 = Prob Y1<br />
(7.51)<br />
con<br />
X’ = v.a. con fdd: f<br />
Y’ = v.a. con fdd: f<br />
Y’1 = v.a. con fdd:<br />
X '<br />
Y '<br />
f<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
Y '<br />
1<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
Llamando<br />
a = ϕ + d' −c'<br />
la ecuación anterior la podemos rescribir como:<br />
= Prob[ X ' −a<br />
≥ Y ' −(<br />
K −1)<br />
T − u ≥ Y −ϕ<br />
]=<br />
P k − cl . 2<br />
' 1<br />
. 2 = Prob[ X ' −Y<br />
' 1−a<br />
≥ Y ' −Y<br />
' 1−(<br />
K −1<br />
T − u ≥ −ϕ<br />
]=<br />
(7.51a)<br />
P k − cl<br />
)<br />
Podemos simplificar la ecuación anterior defini<strong>en</strong>do dos nuevas<br />
variable aleatorias Z = X ' −Y ' 1 , Z'<br />
= Y ' −Y<br />
' 1 cuyas fdd se han desarrollado <strong>en</strong><br />
el punto 2.2.1 de este anexo.<br />
−β|<br />
t|<br />
3<br />
e β 2 ⎛ 2⎞<br />
2−<br />
j ⎛ 1 ⎞<br />
Z , Z’ = v.a. con fdd: f Z ( t)<br />
= f Z ' ( t)<br />
= ∑ +<br />
= ⎜<br />
⎟ | t |<br />
⎜<br />
⎟ (2 j)!<br />
32 j 0<br />
⎝ j⎠<br />
⎝ 2β<br />
⎠<br />
(7.51b)<br />
j<br />
'<br />
= Prob[ Z − a ≥ Z − ( K −1<br />
T − u ≥ −ϕ<br />
]=<br />
P k − cl . 2<br />
)<br />
T<br />
=<br />
∫<br />
Prob<br />
u = 0<br />
1<br />
=<br />
T<br />
∫ ∫ ∞ (k-1)T+<br />
T 0 uo-ϕ<br />
' 1<br />
[ Z − a + ϕ ≥ Z − ( K −1)<br />
T + ϕ − uo ≥ 0] duo =<br />
Prob<br />
[ Z − a + ϕ ≥ zo − ( K −1)<br />
T + ϕ − uo]<br />
T<br />
f<br />
Z '<br />
( zo)<br />
dzo duo =<br />
383
Anexo 2. Desarrollo de ecuaciones.<br />
=<br />
T<br />
1 T<br />
∫ ∫ ∞ +<br />
0 (k-1)T uo-ϕ<br />
Prob<br />
[ Z ≥ zo − ( K −1)<br />
T + a − uo]<br />
f<br />
Z '<br />
( zo)<br />
dzo duo =<br />
1<br />
=<br />
T<br />
T<br />
∫ ∫ ∞ (k-1)T+<br />
0 uo-ϕ<br />
(1- F<br />
Z<br />
( zo − ( K −1)<br />
T + a − uo))<br />
f<br />
Z '<br />
( zo)<br />
dzo duo<br />
(7.51c)<br />
2.1 Desarrollo de fdd de la v.a Z(t)<br />
Para simplificar el desarrollo de la ecuación (7.51) se ha definido<br />
una variable aleatoria Z obt<strong>en</strong>ida como resta de dos variables aleatorias X<br />
e Y, con función de d<strong>en</strong>sidad de distribución idénticas de t<strong>ip</strong>o Erlang.<br />
X, Y = v.a. con ffd<br />
f<br />
X<br />
n−1<br />
( t β ) −β<br />
t<br />
( t)<br />
= fY<br />
( t)<br />
= β e para t ≥ 0<br />
( n −1)!<br />
Al ser dos funciones positivas e idénticas, la función de d<strong>en</strong>sidad de<br />
la resta <strong>en</strong>tre ellas la podemos escribir como:<br />
f<br />
Z<br />
con:<br />
( t)<br />
=<br />
∫ ∞ f (| t | + τ ) f ( τ ) dτ<br />
0<br />
X<br />
Y<br />
f<br />
X<br />
(| t | + τ ) = β<br />
n<br />
(| t | + τ )<br />
( n −1)!<br />
n−1<br />
e<br />
−β<br />
(| t|<br />
+ τ )<br />
f<br />
Y<br />
n−1<br />
n τ<br />
( τ ) = β e<br />
( n −1)!<br />
−βτ<br />
2n<br />
β t β<br />
n n 2τβ<br />
fZ ( t)<br />
=<br />
dτ<br />
(7.51d)<br />
−|<br />
|<br />
[ ] ∫ ∞ −1<br />
−1<br />
−<br />
e (| t | + τ ) τ e<br />
( n −1)!<br />
0<br />
Para simplificar la ecuación anterior definimos una nueva integral I k como:<br />
I<br />
k<br />
∞<br />
2 !<br />
=<br />
k − τβ k<br />
∫<br />
τ e dτ<br />
=<br />
0<br />
k<br />
(2β<br />
)<br />
+ 1<br />
(7.51e)<br />
384
Anexo 2. Desarrollo de ecuaciones.<br />
Parte del integrando de la ecuación (7.51d) puede desarrollarse<br />
según el binomio de Newton:<br />
(| t | + τ )<br />
n−1<br />
τ<br />
n−1<br />
= τ<br />
=<br />
n−1<br />
n<br />
∑ − 1<br />
j = 0<br />
n<br />
∑ − 1<br />
j = 0<br />
⎛<br />
⎜<br />
⎝<br />
⎛<br />
⎜<br />
⎝<br />
n − 1<br />
j<br />
n − 1<br />
j<br />
⎞ j<br />
⎟τ<br />
| t |<br />
⎠<br />
n−1−<br />
j<br />
=<br />
⎞ j + n−1<br />
n−1−<br />
j<br />
⎟τ | t |<br />
(7.51f)<br />
⎠<br />
Sustituy<strong>en</strong>do (7.51f) <strong>en</strong> la ecuación de la función de d<strong>en</strong>sidad de<br />
distribución t<strong>en</strong>emos:<br />
f<br />
Z<br />
( t)<br />
=<br />
2n<br />
β −|<br />
t|<br />
β<br />
e<br />
[ ] ∫ ∞<br />
( n −1)!<br />
∑<br />
0<br />
n−1<br />
j = 0<br />
⎛<br />
⎜<br />
⎝<br />
n − 1<br />
j<br />
⎞<br />
⎟<br />
⎠<br />
τ<br />
j + n−1<br />
| t |<br />
n−1−<br />
j<br />
e<br />
−2τβ<br />
dτ<br />
(7.51g)<br />
Ahora podemos utilizar la definición de I k de la ecuación (7.51e) de<br />
manera que nos queda:<br />
f<br />
Z<br />
( t)<br />
2n<br />
β −|<br />
t|<br />
β n−1<br />
n − −<br />
= ∑ − 1 n 1 j<br />
e<br />
I<br />
j=<br />
0<br />
j + n−1<br />
j<br />
[(<br />
n −1)!<br />
]<br />
⎛<br />
⎜<br />
⎝<br />
⎞<br />
⎟ | t |<br />
⎠<br />
=<br />
=<br />
β<br />
2n<br />
[(<br />
n −1)!<br />
]<br />
e<br />
−|<br />
t|<br />
β n−1<br />
n − −<br />
∑ − 1 n 1 j<br />
j = 0 j<br />
n<br />
⎛<br />
⎜<br />
⎝<br />
⎞<br />
⎟ | t |<br />
⎠<br />
( n −1+<br />
j)!<br />
=<br />
j +<br />
2β<br />
=<br />
e<br />
−|<br />
t|<br />
β<br />
[ n −1)!<br />
]<br />
⎛<br />
⎜<br />
⎝<br />
n<br />
β<br />
⎞ n−1<br />
⎛ n 1⎞<br />
n−1−<br />
j ⎛ 1 ⎞<br />
⎟ ∑ ⎜<br />
− ⎟ | t | ⎜ ⎟<br />
⎠<br />
j = 0⎝<br />
j ⎠ ⎝ β ⎠<br />
( 2<br />
2<br />
j<br />
( n −1+<br />
j)!<br />
(7.51h)<br />
Puede comprobarse como haci<strong>en</strong>do n=1, es decir, con X e Y v.a con<br />
fdd expon<strong>en</strong>cial, la v.a Z, resta de las dos, ti<strong>en</strong>e una fdd que sigue una<br />
distribución de Laplace [ABRA72].<br />
385
Anexo 2. Desarrollo de ecuaciones.<br />
A2.3. Desarrollo de la ecuación 7.57<br />
[ Y ' −Y<br />
' + < ( k −1<br />
T u]<br />
P k − cl 3 = Prob 1 ) +<br />
. ϕ (7.57)<br />
con:<br />
Y 1 ’ = v.a. con fdd:<br />
Y’ = v.a. con fdd:<br />
f<br />
f<br />
Y '<br />
1<br />
Y '<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
3 2<br />
β t −β t<br />
( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
La ecuación (7.57) la podemos rescribir de la sigui<strong>en</strong>te manera:<br />
T<br />
1<br />
P k−cl.3<br />
=<br />
∫<br />
Prob[ Y ' −Y1<br />
' ≤ z + uo<br />
] duo<br />
(7.57a)<br />
0<br />
T<br />
con<br />
z = ( k −1)<br />
T<br />
−ϕ<br />
La probabilidad que aparece como parte de la ecuación (7.57a)<br />
podemos, a su vez, desarrollarla como sigue:<br />
[ ' ≤ z + u ] = Prob[ Y ' ≤ z + u y ]<br />
Prob Y'-Y<br />
∫ ∞ 1 o<br />
o + o fY<br />
' ( y )<br />
1 o dyo<br />
(7.57b)<br />
0<br />
La probabilidad de que Y’ sea m<strong>en</strong>or que un valor puede escribirse<br />
por medio de su función de distribución. Sustituy<strong>en</strong>do, además, ( ) , la<br />
ecuación anterior nos queda:<br />
f Y 1'<br />
y<br />
Prob<br />
[ Y'-Y1'<br />
≤ z + uo<br />
] =<br />
∫<br />
∞<br />
max(0, -u<br />
o<br />
−z)<br />
⎡ 2<br />
−β<br />
( z+<br />
u + y ) ( z + uo<br />
+ y )<br />
⎢<br />
o o<br />
o<br />
1 − e ∑<br />
⎢<br />
j!<br />
⎣<br />
j=<br />
0<br />
j<br />
j ⎤ 3<br />
β β y<br />
⎥<br />
⎥ 2<br />
⎦<br />
2<br />
o<br />
e<br />
−β<br />
yo<br />
(7.57c)<br />
dy<br />
o<br />
386
Anexo 2. Desarrollo de ecuaciones.<br />
f Y 1'<br />
Es interesante observar el limite inferior de la ecuación anterior.<br />
( y)<br />
es distinto de cero sólo para valores de yo mayores que cero. Pero,<br />
además, a probabilidad [ Y '≤ z + + ]<br />
negativo.<br />
Prob u o y o también es nula si z+uo+yo es<br />
Sustituy<strong>en</strong>do ahora el valor obt<strong>en</strong>ido <strong>en</strong> (7.57c) <strong>en</strong> la ecuación<br />
(7.57a), t<strong>en</strong>emos:<br />
P<br />
k −cl.3<br />
T<br />
∫ ∫<br />
∞<br />
⎡ 2<br />
−β<br />
( z−<br />
u + y ) ( z − uo<br />
+<br />
o o<br />
1<br />
= ⎢1<br />
− e<br />
T<br />
∑<br />
⎢<br />
0 max(0,-u -z)<br />
⎣<br />
j=<br />
0<br />
o<br />
y<br />
j!<br />
o<br />
)<br />
j<br />
j ⎤ 3<br />
β β y<br />
⎥<br />
⎥ 2<br />
⎦<br />
2<br />
o<br />
e<br />
−β<br />
yo<br />
dy<br />
o<br />
du<br />
(7.57d)<br />
o<br />
A.2.4. Desarrollo de la ecuación 7.59<br />
A continuación vamos a desarrollar el primer término de la<br />
ecuación 7.59, que se muestra a continuación.<br />
[(<br />
k 1) T + u < t < kT + u]<br />
Prob (7.59a)<br />
− 6<br />
Utilizando las ecuaciones (7.39), (7.38), y (7.23) podemos sustituir<br />
el valor de t 6 , de manera que la ecuación anterior queda:<br />
[(<br />
k − 1) T + u < Y ' −X<br />
' + − e'<br />
< kT + u]<br />
Prob ϕ (7.59b))<br />
con:<br />
X’, Y’ = v.a. con fdd:<br />
f<br />
X '<br />
3 2<br />
β t −β t<br />
( t)<br />
= fY<br />
' ( t)<br />
= e para t ≥ 0 y con β = µ ( 1−<br />
ρ)<br />
2<br />
e' = ( CN,<br />
R1 ) + ( R1<br />
, oBS)<br />
− ( CN,<br />
R2<br />
) − ( R2,<br />
nBS)<br />
La ecuación (7.59b) la podemos rescribir de la sigui<strong>en</strong>te manera:<br />
387
Anexo 2. Desarrollo de ecuaciones.<br />
Prob<br />
∫<br />
[(0<br />
< ' −X<br />
' −u<br />
+ a < T ] = Prob[ Y ' −X<br />
' −u<br />
+ a ≤ T ]<br />
0<br />
T<br />
1<br />
Y o duo<br />
(7.59c)<br />
T<br />
con<br />
a = ϕ − e'<br />
−(<br />
k −1)<br />
T<br />
Fijando ahora la v.a X’ :<br />
1<br />
=<br />
T<br />
T<br />
∫∫ 0<br />
0<br />
∞<br />
Prob<br />
[ Y ' −x<br />
− u + a ≤ T ]<br />
o<br />
o<br />
f<br />
X '<br />
( x<br />
) dx du<br />
o<br />
o<br />
o<br />
(7.59d)<br />
A continuación desarrollamos la probabilidad que aparece <strong>en</strong> la<br />
ecuación anterior, d<strong>en</strong>ominando b = x + u − a :<br />
o<br />
o<br />
Prob [(0<br />
< Y ' −b<br />
< T ]=<br />
= Prob [ b < Y ' < T + b]=<br />
[ Y ' < T + b] - Prob[ Y ' < ]=<br />
= Prob<br />
b<br />
= F T + b)<br />
− F ( b)<br />
(7.59e)<br />
Y ' ( Y '<br />
Finalm<strong>en</strong>te sustituimos (7.59e) <strong>en</strong> (7.59d), de manera que la<br />
probabilidad queda:<br />
1<br />
T<br />
T<br />
∫∫<br />
0 0<br />
∞<br />
FY<br />
' ( xo<br />
+ uo<br />
− ϕ + e'<br />
+ kT)<br />
− FY<br />
' ( xo<br />
+ uo<br />
− ϕ + e'<br />
+ ( k −1)<br />
T ) f X ' ( xo<br />
) dxodu<br />
o<br />
(7.59f)<br />
388