Universidad Rey Juan Carlos

Escuela Superior de Ciencias Experimentales y Tecnologa

Proyecto Fin de Carrera
Computaci on ubicua
Diego Chaparro Gonzalez
dchaparro@[Link]
Tutor: Pedro de las Heras Quir os
pheras@[Link]
30 de Junio de 2003
Resumen
La tecnologa de comunicaciones inal ambricas es cada da m as importante y
empieza a estar tan extendida que empezamos a olvidarnos de la conexi on por
cables que hasta ahora era fundamental en algunos dispositivos, como telefonos
m oviles u ordenadores port atiles. Esta tecnologa ha experimentado un gran
avance en los ultimos tiempos, y su desarrollo sigue en aumento.
Los avances en comunicaciones inal ambricas han llevado a la creaci on de
un nuevo campo en la computaci on, denominado computaci on ubicua. Tambien
est an aprovech andose los avances en el campo de los componentes electr onicos,
que llevan a la reducci on del tama no de los dispositivos y al aumento de su
potencia. El desarrollo de la tecnologa radioelectrica, as como la difusi on y
abaratamiento de los dispositivos utilizados. El desarrollo de los protocolos de
movilidad de dispositivos entre redes y los avances en el campo de los nuevos
materiales.
Este nuevo sector de la computaci on, denominado computaci on ubicua o
pervasiva, pretende incorporar a los objetos de la vida cotidiana capacidad de
c omputo, de comunicaciones inal ambricas y de interacci on entre ellos para crear
un nuevo modelo de la realidad en la que estos objetos interoperan entre ellos
para facilitar la realizaci on de las tareas a las personas.
Para poder investigar acerca de este campo de la computaci on ubicua, se ha
realizado un estudio desde diversos enfoques te oricos y pr acticos de los campos
m as importantes en los que se basa esta tecnologa.
En primer lugar se han estudiado las bases de la tecnologa inal ambrica,
y se han hecho experimentos reales sobre esta tecnologa utilizando diversos
dispositivos: conexiones entre PDAs mediante 802.11 e infrarrojos, conexi on
inal ambrica entre ordenadores con dispositivos dongles, ... En segundo lugar,
despues de haber estudiado la tecnologa inal ambrica, se ha estudiado el segundo
de los campos clave para la computaci on ubicua, es el campo de los protocolos de
movilidad. Se ha estudiado y se han montado maquetas de redes de dispositivos
inal ambricos para estudiar el funcionamiento de varias implementaciones de
estos protocolos, se han hecho pruebas con estas maquetas realizadas y se han
hecho experimentos para medir el rendimiento de los mismos.
Y por ultimo, aplicando los dos campos estudiados anteriormente, junto con
otros aspectos de las tecnologas de la comunicaciones, como redes ad-hoc, se han
montado simulaciones de algunos escenarios reales que propone la computaci on
ubicua utilizando las maquetas montadas en los captulos anteriores adaptadas
a estas situaciones, se ha implementado un protocolo de redes ad-hoc para los
robots legos Mindstorm para comprobar el funcionamiento real de estas redes
y se ha realizado una comparaci on de protocolos de movilidad sobre diferentes
protocolos de red (IPv4 vs IPv6) entre otros experimentos.
1

Indice general
1. Introducci on 6
1.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Organizaci on del proyecto . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Lenguajes, herramientas y tecnologa . . . . . . . . . . . . . . . . 10
1.5. La documentaci on . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2. Tecnologa inalambrica 13
2.1. Historia de la tecnologa inal ambrica . . . . . . . . . . . . . . . . 13
2.1.1. La revoluci on de la telefona inal ambrica . . . . . . . . . . 13
2.1.2. Globalizaci on de las redes de telefona . . . . . . . . . . . 14
2.1.3. El siguiente paso . . . . . . . . . . . . . . . . . . . . . . . 15
2.2. Bases de la tecnologa inal ambrica . . . . . . . . . . . . . . . . . 16
2.2.1. Transmisi on de datos anal ogicos y digitales . . . . . . . . 16
2.2.2. Espectro, medio de transmisi on . . . . . . . . . . . . . . . 17
2.3. Redes locales inal ambricas . . . . . . . . . . . . . . . . . . . . . . 19
2.4. 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2. Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.3. Especicaciones de 802.11 . . . . . . . . . . . . . . . . . . 23
2.4.4. Conguraci on de una tarjeta inal ambrica 802.11b . . . . . 23
2.5. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.1. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5.2. Est andares . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6. IrDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.1. IrDA Data . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6.2. IrDA Control . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.3. Conguraci on de un dispositivo dongle . . . . . . . . . . . 30
2.6.4. Conguraci on de IrDA en un HP Jornada 548 . . . . . . . 32
2.6.5. Conguraci on del puerto de infrarrojos en una Ipaq . . . 34
2.7. Otras tecnologas . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.8. Redes ad-hoc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.8.1. Heterogeneidad de dispositivos m oviles . . . . . . . . . . . 36
2.8.2. Caractersticas especiales de las redes ad-hoc . . . . . . . 37
2.8.3. Protocolos para redes ad-hoc . . . . . . . . . . . . . . . . 38
2.8.4. Pr acticas con redes ad-hoc . . . . . . . . . . . . . . . . . 42
2

INDICE GENERAL

INDICE GENERAL
3. Movilidad 50
3.1. Introducci on a la movilidad sobre TCP/IP . . . . . . . . . . . . . 50
3.2. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.1. Fundamentos de Mobile IP . . . . . . . . . . . . . . . . . 53
3.2.2. Infraestructura de Mobile IP . . . . . . . . . . . . . . . . 54
3.3. Cellular IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.1. Fundamentos de Cellular IP . . . . . . . . . . . . . . . . . 56
3.3.2. Descripci on del protocolo . . . . . . . . . . . . . . . . . . 56
3.4. IPv4 vs IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.5. Pr acticas sobre protocolos de movilidad en IPv4 . . . . . . . . . 63
3.5.1. Montaje de Mobile IPv4 en la maqueta . . . . . . . . . . 63
3.5.2. Montaje de Cellular IPv4 en la maqueta . . . . . . . . . . 65
3.6. Medida de prestaciones de Mobile IPv4 . . . . . . . . . . . . . . 66
3.6.1. Herramientas utilizadas para las pruebas de Mobile IPv4 66
3.6.2. Pruebas ancho de banda en Mobile IPv4 . . . . . . . . . . 66
3.6.3. Pruebas perdida de paquetes UDP en Mobile IP . . . . . 69
3.7. Pr acticas sobre protocolos de movilidad en IPv6 . . . . . . . . . 78
3.7.1. Montaje de la maqueta con IPv6 . . . . . . . . . . . . . . 78
3.7.2. Instalaci on de la implementaci on de Mobile IPv6 . . . . . 82
3.7.3. Instalaci on de la implementaci on de Cellular IPv6 . . . . 84
4. Computaci on ubicua 88
4.1. Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.2. Motivaciones para la computaci on ubicua . . . . . . . . . . . . . 90
4.2.1. La ley de Moore . . . . . . . . . . . . . . . . . . . . . . . 90
4.2.2. Nuevos materiales . . . . . . . . . . . . . . . . . . . . . . 90
4.2.3. Avances en la tecnologa de la comunicaci on . . . . . . . . 91
4.2.4. Desarrollo de los sensores . . . . . . . . . . . . . . . . . . 91
4.3. Escenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3.1. Seguimiento de personas . . . . . . . . . . . . . . . . . . . 92
4.3.2. Informaci on seg un la situaci on . . . . . . . . . . . . . . . 93
4.3.3. Contin ua la videoconferencia . . . . . . . . . . . . . . . . 93
4.3.4. Charla en sala pervasiva . . . . . . . . . . . . . . . . . . 94
4.4. Pr acticas sobre Computaci on Ubicua . . . . . . . . . . . . . . . . 94
4.4.1. Seguimiento de personas . . . . . . . . . . . . . . . . . . . 94
4.4.2. Movilidad de personas . . . . . . . . . . . . . . . . . . . . 97
5. Conclusiones 99
5.1. Desarrollo del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 101
A. Glosario 103
3

Indice de cuadros
2.1. Espectro electromagnetico para telecomunicaciones inal ambricas 18
2.2. Servicios de IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . 22
2.3. Caractersticas de algunos dispositivos existentes . . . . . . . . . 37
3.1. Implementaciones de protocolos de micro/macro movilidad . . . 52
4

Indice de guras
2.1. Capas de protocolos de IEEE 802 y modelo de referencia OSI . . 21
2.2. Maqueta red ad-hoc. Situaci on inicial . . . . . . . . . . . . . . . . 46
2.3. Maqueta red ad-hoc. Situaci on 2 . . . . . . . . . . . . . . . . . . 47
2.4. Maqueta red ad-hoc. Situaci on 3 . . . . . . . . . . . . . . . . . . 49
3.1. Infraestructura de nodos en Mobile IP . . . . . . . . . . . . . . . 54
3.2. Ejemplo de red Cellular IP . . . . . . . . . . . . . . . . . . . . . 57
3.3. Maqueta para pruebas de movilidad en IPv4 . . . . . . . . . . . 63
3.4. Dise no de red para pruebas de Mobile IPv4 . . . . . . . . . . . . 64
3.5. Dise no de red para pruebas de Cellular IPv4 . . . . . . . . . . . 65
3.6. Maqueta para pruebas de movilidad en IPv6 . . . . . . . . . . . 78
3.7. Dise no de red de la maqueta IPv6 . . . . . . . . . . . . . . . . . 80
3.8. Maqueta jer arquica para pruebas sobre Cellular IPv6 . . . . . . 85
4.1. Maqueta para la simulaci on de seguimiento . . . . . . . . . . . . 95
4.2. Maqueta para la simulaci on de movilidad . . . . . . . . . . . . . 97
5
Captulo 1
Introducci on
En este captulo se presenta una introducci on al contenido del proyecto. Se
introducen las bases del estudio que se va a realizar en los siguientes captulos,
los objetivos que se pretenden conseguir en este estudio y la forma en la que se
ha realizado.
6
Captulo 1. Introducci on Introducci on
1.1. Introducci on
Las redes inal ambricas son una realidad hoy en da, estamos acostumbrados
a ver ordenadores port atiles conectados a Internet sin necesidad de cables, pe-
que nos ordenadores de mano conectados con los ordenadores de la ocina, cada
da aumenta m as la creaci on de redes inal ambricas ciudadanas, en la que volun-
tariamente y sin buscar benecio m as all a del uso de las tecnologas disponibles
y el af an de aprender y practicar con ellas, hay ciudadanos que van poniendo a
disposici on de los dem as puntos de acceso a una red que cada da va creciendo
m as, y que cada voluntario ayuda a que esta crezca.
Y todo esto que cada da estamos y estaremos m as acostumbrados a ver
no es m as que el inicio de un mundo de posibilidades que se abren con este
nuevo modelo de computaci on, denominado computaci on pervasiva o ubicua.
Este modelo de computaci on ubicua signica b asicamente la omnipresencia de
computadores muy peque nos interconectados sin cables que se incorporan de
forma casi invisible a cualquier objeto de uso cotidiano, y usando peque nos
sensores unidos a estos computadores pueden detectar el entorno que les rodea
y tienen capacidades tanto de procesar informaci on como de comunicaci on.
A partir de este modelo de computaci on son muchas las posibilidades que
se pueden aprovechar, ya que estos dispositivos pueden no solo computar in-
formaci on y comunicarse con los dem as sino que pueden detectar el entorno
mediante diversos tipos de sensores, lo que les proporciona una interactividad
continua con el entorno y les proporciona la capacidad de poder adaptarse a la
diversas situaciones del entorno e incluso a cooperar con el resto de dispositivos
disponibles en ese entorno para simular comportamientos casi inteligentes.
Todas las posibles aplicaciones de estas tecnologas pueden verse aplicadas
a la realidad gracias a los avances en diversos campos:
La computaci on
La microelectr onica
La tecnologa de la comunicaci on
La ciencia de los materiales
...
Pero uno de los avances que m as ha contribuido a ello son los avances en
microelectr onica, que permiten que la capacidad de los micro-chips crezca de
forma exponencial desde hace mucho tiempo y la tendencia contin ua, como pro-
nosticaba la Ley de Moore, por eso es normal que la capacidad de procesamiento
de estos micro-chips se vaya multiplicando cada cierto tiempo y eso hace que
cada da tengamos mayor capacidad de procesamiento por centmetro cuadrado
de micro-chip. Al igual que sucede con la capacidad de procesamiento, tambien
ocurre con otros factores de los dispositivos electr onicos, como la capacidad de
almacenamiento, el ancho de banda de las comunicaciones y otros factores, que
avanzan a un ritmo similar que dicha capacidad, con lo que conseguimos reducir
cada da m as el tama no de los dispositivos con una gran capacidad de procesa-
miento, almacenamiento, ancho de banda y memoria sin aumentar el precio de
los mismos.
7
Captulo 1. Introducci on Introducci on
Adem as, aparte de estos dispositivos de procesamiento cada vez m as pe-
que nos tambien se van desarrollando otro tipo de dispositivos que ayudan a
aumentar las posibilidades en este campo, como son los micro-sensores que per-
miten recibir informaci on, procesarla y devolver una respuesta con tan solo unos
milmetros cuadrados de tama no.
Tambien se han realizado avances signicativos en el campo de las comuni-
caciones sin cables, cuyos logros que m as interesan en el modelo de computa-
ci on ubicua son los de comunicaciones de corta distancia y con un bajo consumo
de energa. Algunos de estos logros conseguidos es la tecnologa WLAN, que per-
mite la creaci on de redes locales con un alcance aproximado de unos 100-200
metros y con un ancho de banda de unos 10 Mb/s. Tambien es importante la
creaci on de redes de area personal (PAN), tambien llamadas redes de habitaci on
sin cables, de las que el protocolo m as importante es Bluetooth que permite un
alcance de unos 10 metros con un ancho de banda aproximado de 1 Mb/s. Y la
tecnologa por infrarrojos, con el est andar Irda, que puede ser usado para recibir
informaci on sobre el entorno mediante sensores que perciben informaci on sobre
el mismo.
Con toda esta tecnologa ya casi tenemos el entorno que pretende el mode-
lo de computaci on ubicua, pero falta algo. Seg un el modelo del que dispo-
nemos actualmente para realizar comunicaciones entre dispositivos (protocolo
TCP/IP), todo dispositivo est a conectado a la red desde una localizaci on de-
terminada y se comunica con los dem as mediante un identicador (direcci on
IP) que representa su situaci on actual, y si un dispositivo cambia de localiza-
ci on geogr aca porque es un dispositivo m ovil y tiene la capacidad para ello,
entonces debe adquirir un identicador nuevo para comunicarse con los dem as.
Entonces, si no aplicamos nada durante este proceso, un dispositivo no puede ser
localizado mediante un solo identicador si se mueve de un sitio a otro, porque
este identicador cambia.
Y en este punto es donde entra en juego otra tecnologa muy importante para
que este modelo de computaci on siga adelante, y es la tecnologa que proporciona
la movilidad para dispositivos con los protocolos de micro y macro movilidad.
Este tipo de protocolos permite que un dispositivo pueda utilizar su capacidad
de movilidad entre redes sin que esto sea percibido por los dem as dispositivos.
Cualquier dispositivo podr a comunicarse con cualquier otro mediante los identi-
cadores (direcciones IP) originales de los mismos independientemente del lugar
de conexi on a la red que tenga cada dispositivo en cada momento, y siempre
podr an continuar con las comunicaciones en curso mientras se mueven de un si-
tio a otro. El protocolo m as utilizado actualmente para realizar esta tarea es un
protocolo estandarizado por el IETF llamado Mobile IP[Sol], que com unmente
es usado de forma conjunta con otros protocolos de micro-movilidad como por
ejemplo Cellular IP.
8
Captulo 1. Introducci on Objetivos
1.2. Objetivos
En primer lugar, uno de los objetivos del presente trabajo es el de realizar
un estudio sobre diferentes tecnologas que actualmente se est an desarrollan-
do a gran velocidad, y que en un futuro posiblemente cercano pueden hacer
que cambie el modo de percibir el mundo de la computaci on actual que se ba-
sa en ordenadores personales conectados entre s, a otro modo en el que las
personas dejar an de percibir este modo de computaci on porque estos peque nos
computadores estar an presentes en la mayora de objetos cotidianos y pasar an
desapercibidos.
Estos objetivos est an escalonados. Primero se pretende realizar un estudio
sobre la tecnologa inal ambrica, estudiaremos las bases de esta tecnologa y sus
caractersticas m as importantes. Una vez que hayamos hecho esto, el siguiente
paso sera hacer experimentos sobre esta tecnologa, debemos hacer pruebas con
diversos dispositivos: PDA, ordenadores port atiles y de sobremesa, dispositivos
de comunicaci on inal ambrica (dongles, beacons, ...), y otros dispositivos de co-
municaci on inal ambrica poco frecuentes como los robots de Lego Mindstorms.
Y realizar pruebas de conexiones entre estos dispositivos sobre las diferentes tec-
nologas inal ambricas estudiadas anteriormente, como infrarrojos y 802.11. De
esta forma podremos observar la interacci on entre diferentes dispositivos sobre
diversos medios de comunicaci on y comprobar su rendimiento.
Una vez que hemos realizado estos experimentos, esto nos servir a de base
para la realizaci on del estudio y experimentos sobre el siguiente campo de in-
teres: la movilidad entre redes. Despues de realizar un estudio de los diferentes
protocolos de movilidad entre redes existentes, seleccionaremos varias imple-
mentaciones de estos protocolos (Mobile IP, Cellular IP, ...) y las llevaremos
a la pr actica. Crearemos maquetas de redes en las que podamos instalar es-
tas implementaciones, y probar su funcionamiento, comprobar su rendimiento
e incluso probar la interacci on entre varios de estos protocolos.
Despues de esto, debemos agrupar todo el estudio y los experimentos rea-
lizados en los apartados anteriores para realizar el estudio y los experimentos
sobre el principal campo de interes, que se basa en los anteriores, el campo de la
computaci on ubicua. Utilizando las maquetas creadas y utilizadas para los expe-
rimentos en los apartados anteriores, deberemos adaptarlas para la simulaci on
de escenarios reales del modelo propuesto por la computaci on ubicua: debemos
mezclar los dispositivos y las redes inal ambricas, la posibilidad de movilidad
que nos ofrece lo estudiado en segundo lugar y aplicarlo a situaciones reales.
De esta forma, podremos comprobar si el modelo propuesto de computaci on
ubicua hoy en da es lo sucientemente maduro para su uso, y si disponemos de
la tecnologa necesaria para llevarlo a cabo.
Y por ultimo, como no poda ser de otro modo, el objetivo fundamental es
obtener conclusiones sobre el modelo estudiado, observar su desarrollo, el estado
actual y el posible desarrollo futuro.
9
Captulo 1. Introducci on Organizaci on del proyecto
1.3. Organizaci on del proyecto
En este primer captulo se presenta una introducci on a la tem atica general
sobre la que versar an las distintas partes del proyecto, as como una lista inicial
de los objetivos que se pretenden cubrir. Tambien se presentan otros aspec-
tos relacionados con la realizaci on del trabajo, como herramientas y lenguajes
utilizados tanto para la realizaci on de la documentaci on como de los ensayos
pr acticos relacionados con la tem atica del proyecto.
En el segundo captulo se muestran las bases sobre las que se sustenta la
tecnologa inal ambrica, presentando sus aspectos m as importantes y la diversi-
dad de este tipo de tecnologas. Despues se describen algunos de los protocolos
m as utilizados en este campo, y se denen algunos de los experimentos rea-
lizados sobre el, usando diversos dispositivos y sobre diferentes protocolos de
comuncaci on inal ambrica.
En el tercer captulo se describen las tecnologas que permiten dotar a
los dispositivos de la movilidad necesaria para el campo de la computaci on
ubicua, protocolos de macro/micro movilidad. Y se describen los experimentos
y pr acticas realizadas sobre estos protocolos mediante el montaje de maquetas
de redes en las que poder probar estas protocolos.
En el cuarto captulo se desarrolla el modelo de computaci on ubicua en
base a los campos de investigaci on descritos en los captulos anteriores. Se des-
criben algunos escenarios propuestos por este modelo de computaci on, y se ex-
perimenta con alguno de estos escenarios llev andolos a la pr actica real.
Y por ultimo, en el quinto captulo se presentan las conclusiones extradas
de los estudios y de los experimentos realizados durante el desarrollo del pro-
yecto.
1.4. Lenguajes, herramientas y tecnologa
Como las bases sobre las que se sustenta el trabajo forman parte de los ulti-
mos avances en diversas tecnologas, para el desarrollo del mismo as como para
los diversos ensayos pr acticos realizados se ha decidido la utilizaci on de siste-
mas que permitan un control total sobre el estado de los dispositivos utilizados,
as como la posibilidad de acceder a las fuentes de todo el software utilizado,
tanto para realizar estudios sobre el como para poder ser modicado o mejorado
para adaptarlo a las necesidades del entorno, y todo esto encaja perfectamente
con el modelo de software libre existente en la actualidad. Por ello casi la totali-
dad de los dispositivos utilizados (ordenadores personales, PDAs, port atiles, ...)
utilizan un sistema operativo libre, como Debian GNU/Linux, y todo el software
utilizado tambien est a enmarcado dentro de esta categora del software libre.
Ha sido necesario el conocimiento y estudio de diversa tecnologa de progra-
maci on para la puesta en pr actica de los ensayos, programaci on en C, C++ sobre
la que est an desarrollados la mayora de los protocolos de movilidad estudiados,
programaci on de shell (GNU Bourne-Again Shell) y perl para la realizaci on de
scripts de automatizaci on de pruebas. As como programaci on sobre tcl para la
mejora de cierto software de comunicaciones multimedia.
Por supuesto, tambien han sido necesarios amplios conocimientos sobre la
administraci on de sistemas, administraci on de redes e instalaci on y conguraci on
de dispositivos, ya que los ensayos han requerido la instalaci on de gran cantidad
10
Captulo 1. Introducci on Lenguajes, herramientas y tecnologa
de software de comunicaciones, dise no e implementaci on de redes adaptadas a
dichos ensayos, instalaci on y conguraci on de dispositivos de comunicaciones no
convencionales (como beacons, dongles, ...) y puesta en pr actica de los ensayos
dise nados.
Para todo ello se ha utilizado una gran cantidad de software, desde el software
de los protocolos estudiados, herramientas de dise no, control y monitorizaci on
de redes, software multimedia para las pruebas, software para la creaci on de la
documentaci on, ...
A continuaci on se puede ver un sumario de toda la tecnologa utilizada:
Hardware usado:
Compaq Ipaq
HP Jornada
Tarjetas inal ambricas 802.11b
Dongle
Beacon
Ordenadores port atiles y de sobremesa
C amaras de videoconferencia
Material para creaci on de redes: hubs, cables de red, ...
Robots Legos Mindstorms
Sistemas operativos usados:
Debian GNU/Linux
Familiar
Windows CE
LegOS
Lenguajes de programaci on utilizados:
C
C++
perl
shell script
tcl
Tecnologas usadas:
802.11b
Irda
Mobile IP
Cellular IP
IPv6, IPv4
HTTP
11
Captulo 1. Introducci on La documentaci on
1.5. La documentaci on
La documentaci on del proyecto se ha realizado utilizando el sistema de com-
posici on de textos T
E
X de Donald E. Knuth con la ayuda de los macros L
A
T
E
X2e
de Leslie Lamport, utilizando la versi on teT
E
X versi on 1.0 bajo Debian GNU/-
Linux Sarge.
Para la edici on del documento se han utilizado los editores vim versi on 6.1
y xemacs versi on 21.4.
Este documento se distribuye con las condiciones de la licencia GFDL
[Fun02].
12
Captulo 2
Tecnologa inalambrica
2.1. Historia de la tecnologa inalambrica
Los primeros inicios de la tecnologa inal ambrica se produjeron sobre 1896,
cuando Gublielmo Marconi invent o el telegrafo y en 1901 se produjo el primer
envo sobre el Oce ano Atl antico. Este fue el primer momento en el que se uti-
liz o una tecnologa para poder enviar caracteres codicados mediante se nales
anal ogicas sin cables. A partir de entonces han surgido muchos dispositivos que
utilizan este tipo de tecnologa: radio, televisi on, telefono m ovil, satelites de
comunicaciones, ...

Ultimamente los avances y estudios m as signicativos est an
centrados en los satelites de comunicaciones, la tecnologa celular y las redes
inal ambricas.
En 1960 se lanzaron por primera vez satelites de comunicaciones, que en
aquel entonces podan manejar un escaso volumen de tr aco, y hoy en da es-
tos satelites son capaces de soportar el tr aco de comunicaciones de voz y de
televisi on entre pases.
Las redes inal ambricas est an permitiendo el desarrollo de redes WAN, MAN
y LAN inal ambricas. En estas redes los protocolos m as usados son 802.11 y
Bluetooth
Los telefonos m oviles permiten comunicaciones duales entre dos extremos,
como el telegrafo de Marconi. La primera generaci on de telefonos m oviles uti-
lizaba tecnologa anal ogica, con terminales muy pesados y con poco ancho de
banda para las comunicaciones. Actualmente se utiliza tecnologa digital, lo que
permite mayor ancho de banda, mayor calidad de recepci on y mayor seguridad.
Los est andares que denen la interacci on entre dispositivos inal ambricos
est an avanzando muy r apidamente, lo que nos llevar a de forma r apida a la
creaci on de redes inal ambricas globales que permitir an acceso desde diferentes
dispositivos con tecnologa diferente y ofrecer an una amplia gama de servicios.
2.1.1. La revoluci on de la telefona inalambrica
Una de los mayores progresos en tecnologa inal ambrica en los ultimos tiem-
pos, ha sido sin duda la revoluci on de los telefonos m oviles. En 1990 el n umero
de usuarios de esta tecnologa en todo el mundo era aproximadamente de 11
millones, y en 1996 el n umero de nuevos usuarios de telefonos m oviles superaba
al n umero de nuevos usuarios de telefona ja.
13
Captulo 2. Tecnologa inal ambrica Historia de la tecnologa inal ambrica
Las razones para justicar el exito de esta tecnologa son claras:
Los telefonos se mueven junto con las personas, y son independientes de la
situaci on geogr aca, por tanto permiten toda la movilidad que los usuarios
necesitan.
Los telefonos cada vez son m as peque nos, con mayores funcionalidades y
tienen bateras m as duraderas.
Por otro lado, hay ciertos lugares apartados de centros urbanos en los que
implantar servicios de tecnologa ja por cable es muy costoso, mientras
que la implantaci on de estaciones base de telefona m ovil es mucho m as
barato.
Adem as de esto, est an apareciendo nuevos dispositivos de telefona m ovil con
los que se puede tener acceso a Internet, aunque con una prestaciones muy ba-
jas. Con estos dispositivos se pueden tener sistemas de mensajera instant anea,
correo electr onico, y otras funcionalidades cada da m as importantes.
2.1.2. Globalizaci on de las redes de telefona
Hoy en da no existe una unica red de telefona m ovil, los dispositivos sopor-
tan una o dos de las tecnologas existentes y se conectan mediante un operador
de telefona. Para que esto no ocurra en el futuro y exista una compatibilidad
entre la variedad de tecnologas es necesario la denici on de est andares que
regulen todo esto.
La primera generaci on de redes digitales inal ambricas apareca en Norte
America bajo el nombre de Sistema de telefona m ovil avanzada (AMPS:
Advanced Mobile Phone System), que utilizaba un servicio de comunicaciones
(CDPD: Cellular Digital Packet Data) que ofreca un ancho de banda para
comunicaciones de datos de 19.2 kbps. El CDPD utiliza los momentos de inac-
tividad en las transmisiones por los canales de voz para ofrecer el servicio de
comunicaciones de datos.
La segunda generaci on de sistemas inal ambricos se corresponde con el Siste-
ma Global de Comunicaciones M oviles (GSM: Global System for Mobile Com-
munications), el Servicio de Comunicaciones Personales ( PCS: Personal Com-
munications Service ) IS-136 y el IS-95.
Como hemos dicho, es necesario que para las pr oximas generaciones de sis-
temas inal ambricos esten denidos los est andares que permitan el acceso glo-
bal mediante los dispositivos inal ambricos. Para ello, la Uni on Internacional de
Telecomunicaciones (ITU: International Telecommunication Union) est a desa-
rrollando el IMT-2000 (textitInternational Mobile Telecommunications-2000),
que es una familia de est andares, desarrollado en la banda de frecuencia de los
2 Ghz, cuya intenci on es proporcionar una red de comunicaciones inal ambri-
ca global, deniendo las frecuencias de uso, los metodos de codicaci on y las
transmisiones.
Adem as de esto, los est andares necesitan denir la interacci on de los dis-
positivos inal ambricos con Internet. Para ello el WAP (Wireless Application
Protocol ) Forum est a desarrollando un protocolo com un que permita a los dis-
positivos con una pantalla y unos dispositivos de entrada limitados el acceso a
Internet.
14
Captulo 2. Tecnologa inal ambrica Historia de la tecnologa inal ambrica
Y por ultimo, el IETF (Internet Engineering Task Force) est a desarrollan-
do el est andar Mobile IP para adaptar el protocolo IP al nuevo entorno de
dispositivos m oviles.
2.1.3. El siguiente paso
El primer reto, por tanto, de la tecnologa inal ambrica se ha centrado en las
comunicaciones por voz, y como podemos observar hoy en da ha tenido un gran
exito y un desarrollo muy r apido.
El siguiente reto para esta tecnologa consiste en las comunicaciones de da-
tos, con la que se pretende que el acceso a Internet pueda realizarse al igual que
hoy se realiza mediante las redes de cables. En realidad, no se pretende que el
acceso sea el mismo, porque los dispositivos con los que se va a realizar ese ac-
ceso no son iguales: los dispositivos inal ambricos poseen pantallas de capacidad
limitada y posibilidad de interacci on con el usuario tambien m as limitada que
las disponibles mediante un ordenador personal.
15
Captulo 2. Tecnologa inal ambrica Bases de la tecnologa inal ambrica
2.2. Bases de la tecnologa inalambrica
En las siguientes secciones se presentan algunas de las bases sobre las que se
sustenta el campo de las comunicaciones inal ambricas.
2.2.1. Transmisi on de datos anal ogicos y digitales
Primero, algunas deniciones. Denimos datos como entidades que tienen
signicado o informaci on. Las se nales son electricas o electromagneticas y son
la representaci on de los datos. Y por ultimo una trasmisi on es el proceso de
comunicaci on de datos mediante la propagaci on y procesamiento de las se nales.
Datos digitales y anal ogicos
La transmisi on de los datos se puede hacer de forma anal ogica o digital.
B asicamente los datos anal ogicos son valores continuos en un intervalo de
tiempo. Por ejemplo, el audio y el vdeo son datos anal ogicos, as como la mayora
de los datos que son recogidos por los sensores, como temperatura o presi on.
Por otra parte los datos digitales son aquellos que corresponden a valores
discretos, como por ejemplo un texto de caracteres y n umeros.
Se nales anal ogicas y digitales
Una se nal anal ogica es una variaci on electromagnetica continua de onda
que puede ser propagada sobre una diversidad de medios dependiendo de la
frecuencia ( cable coaxial, cable cruzado, el aire, ...) .
Una se nal digital es una secuencia de pulsos de voltaje, que pueden ser
representados mediante ceros y unos.
La principal ventaja de las se nales digitales es que suele ser mucho m as barata
y es menos susceptible a interferencia por ruidos. Y la principal desventaja es
que las se nales digitales ofrecen mayor atenuaci on que las se nales anal ogicas.
Tanto los tipos de datos anal ogicos como digitales pueden ser representados
y propagados mediante se nales anal ogicas o digitales:
Los datos digitales pueden ser representados mediante se nales digitales
mediante el uso de un m odem. Un m odem convierte una serie de pulsos
binarios en una se nal anal ogica modulando la frecuencia. La mayora de
los m odem tradicionales representan datos digitales en el espectro de voz
y permiten que estos datos sean propagados sobre las lineas tradicionales
de telefona. En el otro extremo, otro m odem demodula la se nal para
recuperar los datos originales.
Los datos anal ogicos pueden ser representados por se nales digitales me-
diante una operaci on muy similar. El dispositivo que realiza esta funci on
para datos de voz se denomina codec. Esencialmente, lo que hace un co-
dec es recoger una se nal anal ogica que representa datos de voz, muestrea
peri odicamente esa onda y convierte su amplitud en una unidad numerica
que es representada digitalmente. En el otro lado de la lnea otro codec
usa la se nal digital para decodicarla en la se nal anal ogica original.
16
Captulo 2. Tecnologa inal ambrica Bases de la tecnologa inal ambrica
Transmisiones anal ogicas y digitales
Tanto las se nales anal ogicas como las digitales deben ser transmitidas me-
diante un medio adecuado, y la forma de tratarlas depender a del sistema de
transmisi on.
La transmisi on anal ogica consiste en transmitir se nales anal ogicas inde-
pendiente del contenido ( pueden ser datos digitales o anal ogicos ). Pero en
ambos casos la se nal anal ogica sufrir a atenuaciones que limitan la distan-
cia del transporte de dicha se nal en el medio empleado. Para aumentar la
distancia de transmisi on se usan amplicadores que aumentan la energa
de la se nal, pero tambien aumenta la cantidad de ruido en la misma. En
datos anal ogicos, como la voz, un poco de ruido en la transmisi on es ad-
misible, pero en los datos digitales esto no es v alido.
Sin embargo, la transmisi on digital est a relacionada con el contenido de
la se nal. Y la se nal digital tambien posee un lmite de distancia antes
de que se pierda la integridad de los datos, por ello, para aumentar la
distancia de transmisi on, se usan repetidores. Un repetidor recibe una
se nal digital, vuelve a crear la cadena de patrones de unos y ceros, y vuelve
a transmitir la nueva se nal creada. Con esta soluci on, la atenuaci on en este
tipo de transmisi on est a superada. Esta misma se nal puede ser utilizada
si una se nal anal ogica contiene datos digitales. Se usan dispositivos para
retransmitir la se nal, los cuales reciben la se nal anal ogica, recuperan los
datos digitales y crean una nueva se nal anal ogica sin ruido.
2.2.2. Espectro, medio de transmisi on
Capacidad del canal
Una variedad de razones pueden ser las causas para distorsionar o atenuar
una se nal. Una de las m as usuales suele ser la inclusi on de ruido en la se nal,
por la que la se nal se distorsiona. Para los datos digitales, lo que realmente nos
interesa es: cu anto de importante son estas limitaciones para la tasa de datos
que se puede conseguir?.
La tasa m axima a la que los datos pueden ser transmitidos sobre un determi-
nado canal de comunicaci on bajo determinadas circunstancias es la capacidad
del canal.
Conceptos importantes:
Tasa de datos: Es la tasa, en bits por segundo (bps) a los que pueden
ser transmitidos los datos.
Ancho de banda: Es el ancho de banda de la se nal transmitida debido al
emisor y a la naturaleza del medio de comunicaci on. Se expresa en ciclos
por segundo ( Hertz ).
Ruido: Es el nivel medio de ruido sobre el medio de comunicaci on.
Tasa de ruido: Es la tasa en la que suceden los errores: se transmite un
uno y se recibe un cero, y viceversa.
17
Captulo 2. Tecnologa inal ambrica Bases de la tecnologa inal ambrica
Rango de frecuencia
Radio 30MHz - 1GHz
Micro-ondas 1GHz - 40GHz
Infrarrojos 3x10
1
1 - 2x10
1
4 Hz
Cuadro 2.1: Espectro electromagnetico para telecomunicaciones inal ambricas
El problema que nos encontramos es que las mejoras en las comunicaciones
son costosas, a mayor ancho de banda disponible mayor es el coste asociado.
Por eso, lo que buscamos es obtener la mayor tasa de datos posible con un
determinada tasa de error para un ancho de banda dado. Y el principal problema
para conseguir esto es el ruido.
Si tuvieramos un canal que estuviera libre de ruido, la limitaci on de la tasa
de datos sera simplemente el ancho de banda de la se nal.
Si las se nales a ser transmitidas son binarias, cada elemento de la se nal puede
representar un bit, pero podemos tener se nales que en cada elemento tengan m as
de dos niveles, por tanto cada elemento representar a m as de un bit. Y con este
metodo, dado un ancho de banda, podemos aumentar la tasa de datos. Pero el
n umero de niveles de cada elemento de la se nal viene impuesto por el ruido y
las caractersticas del medio de transmisi on.
Con esto podemos observar que si aumentamos el ancho de banda, aumen-
tamos la tasa de datos. Pero el problema es que si aumentamos la tasa de datos,
los bits ocupan menos espacio en la se nal, y por tanto hay m as bits que pueden
ser afectados por el ruido. Y con esto tenemos que con un determinado nivel de
ruido, a mayor tasa de datos mayor es la tasa de errores.
Medio de transmisi on
En un sistema de transmisi on de datos, el medio de transmisi on es el camino
fsico entre el emisor y el receptor. Este medio de transmisi on puede ser guiado o
no guiado. En el primer caso las ondas electromagneticas son transportadas por
un componente s olido, como un cable coaxial, bra optica, ... Y en el segundo
caso, las transmisiones no guiadas se realizan por la atm osfera y el espacio
exterior, estas son las transmisiones inalambricas.
Las calidad de la transmisi on depende de las caractersticas del medio y
de las caractersticas de la se nal. En el caso de los medios guiados, el factor
m as importante para determinar las limitaciones de la transmisi on es el medio
empleado. Sin embargo, en el caso de las transmisiones por medios inal ambricos
lo m as importante es el ancho de banda de la se nal que produce la antena
emisora. Esta se nal suele ser omnidireccional a frecuencias bajas, y direccional
a frecuencias m as altas.
En la tabla 2.1 se muestra una clasicaci on de tecnologas inal ambricas en
funci on del rango de frecuencias en el que operan.
18
Captulo 2. Tecnologa inal ambrica Redes locales inal ambricas
2.3. Redes locales inalambricas
En los ultimos tiempos, las redes locales inal ambricas han ocupado un gran
lugar dentro del mercado de las redes locales. Las empresas se han dado cuenta
de que las WLAN (Wireless Local Area Network) son un elemento indispen-
sable junto con sus redes cableadas, porque con ellas se pueden satisfacer las
necesidades de movilidad, redes ad-hoc o accesibilidad en lugares difciles de
cablear [Sta01].
Seg un [PC95] hay 4 areas principales de aplicaci on de las redes inal ambricas:
Extensi on de LAN
Hay situaciones en las que realizar el cableado de algunos lugares es una
tarea muy complicada, por razones como edicios con grandes areas abiertas,
edicios antiguos que no tienen la infraestructura necesaria o peque nas ocinas
en las que cablearlas no es econ omico.
Para estas situaciones las redes locales inal ambricas son la soluci on, pero
normalmente estas WLAN son solamente una parte de la red local, siempre hay
otra parte de la red que contiene elementos que est an mejor cableados: servidores
y algunas estaciones de trabajo.
Interconexi on de edicios
La interconexi on de edicios cercanos tambien es una buena aplicaci on de las
redes locales inal ambricas, porque permiten enlazar varios edicios sin necesidad
de tener cableado entre ellos mediante enlaces punto a punto inal ambricos.
Acceso n omada o ubicuo
La computaci on ubicua tambien es otro de los servicios que se pueden ofrecer
mediante las redes locales inal ambricas. Con ella los usuarios pueden conectar-
se a la red local mediante sus dispositivos m oviles ( port atiles, PDAs, ...) y
esto lo pueden hacer desde diversos lugares fsicos gracias a la cobertura que
proporcione la red inal ambrica.
Redes Ad-hoc
Las redes ad-hoc son redes que se generan entre dispositivos que se unen a
esta red descentralizada sin necesidad de una infraestructura creada anterior-
mente. Suelen ser redes temporales que se crean para situaciones concretas. Por
ejemplo, una reuni on de trabajadores en un despacho en la que estos disponen
de dispositivos m oviles que forman una red para intercambiar datos.
Las redes inal ambricas se clasican dependiendo de las tecnicas de transmi-
si on que usan, y todas estas redes se pueden enmarcar en alguna de las siguientes
categoras:
Redes de area local por infrarrojos:
Las comunicaciones inal ambricas mediante infrarrojos est an extendidas en
los hogares en los dispositivos de control remoto, como mandos a distancia
por ejemplo.
19
Captulo 2. Tecnologa inal ambrica Redes locales inal ambricas
Pero las comunicaciones por infrarrojos tambien pueden ser usadas para
crear redes locales. Estas redes ofrecen algunas ventajas con respecto al
resto de redes inal ambricas:
El espectro de comunicaciones inal ambricas es ilimitado porque no
est a regulado, con lo que podemos conseguir altas tasas de datos.
Los infrarrojos comparten algunas propiedades de la luz que son muy
interesantes para crear redes locales, como la propiedad de reejarse
sobre algunos objetos que hace que los infrarrojos emitidos lleguen a
m as lugares.
No penetran las paredes ni los objetos opacos, lo que ofrece ventajas
para tener redes seguras dentro de espacios cerrados y posibilidad
de crear diferentes redes en diferentes espacios sin problemas por las
posibles interferencias.
Adem as, crear este tipo de redes es m as econ omico que otras redes inal ambri-
cas y m as sencillo.
Por otro lado, estas redes tambien tienen desventajas, como el ruido que
se puede producir en entornos con mucha luz o elementos luminosos, y que
la potencia de transmisi on est a limitada ya que puede ser da nino para los
ojos y aumenta el consumo de energa.
Redes de area local de espectro expandido:
La mayora de redes locales inal ambricas usan tecnicas de espectro ex-
pandido. Estas redes, excepto las que son muy peque nas, suelen usar un
esquema de varias celdas con diferentes frecuencias para evitar interferen-
cias.
Dentro de cada celda se puede usar un sistema de conexi on punto a pun-
to o tipo hub. En las conexiones tipo hub hay un elemento central que
proporciona la conexi on inal ambrica a los dispositivos y todas las comu-
nicaciones se realizan entre este elemento central y estos dispositivos, no
hay comunicaci on directa entre dispositivos entre s. Por otro lado, las
conexiones punto a punto se utilizan usualmente para crear redes ad-hoc.
Las bandas de frecuencia dependen de cada pas. En EEUU hay tres rangos
de frecuencia que no est an regulados: la banda de los 915 MHz, la banda
de 2.4-2.4835 GHz y la banda de los 5.8GHz.
Redes de area local de banda estrecha:
La tecnologa de microondas de banda estrecha es el uso de la banda de
radiofrecuencia para enviar se nales, con un ancho de banda muy estrecho,
lo justo para poder enviar la se nal.
Hasta ahora este tipo de tecnologa operaba en frecuencias licenciadas,
es decir, no liberadas para uso com un. Pero recientemente han aparecido
dispositivos que operan en frecuencias liberadas. En 1995 apareci o Ra-
dioLAN, que opera en el espectro liberado ISM (Industrial, Scientic,
Medical ), y opera a baja energa (0.5 watios) y en la banda de los 5.8
GHz, con un alcance de unos 50-100 metros.
En las siguientes secciones se presentan los protocolos m as usados actual-
mente para la creaci on de redes inal ambricas.
20
Captulo 2. Tecnologa inal ambrica 802.11
2.4. 802.11
Las redes 802.11 son hoy en da una realidad, y su uso es muy frecuente al
contrario de otro tipo de tecnologas inal ambricas de las que se espera un gran
futuro pero que todava no son usadas com unmente.
En las siguientes secciones se presentan las caractersticas y usos m as comu-
nes de estas redes, as como un ejemplo pr actico de como congurar este tipo
de dispositivos.
2.4.1. Arquitectura
Seg un el modelo OSI [Zim80] las capas superiores ( nivel 3, 4 y superiores )
) son independientes de la arquitectura de red, por tanto en este apartado para
estudiar la arquitectura del protocolo solo nos interesan las capas inferiores.
En la gura 2.1 se muestra la arquitectura de protocolos para redes inal ambri-
cas que ha sido adoptado para la realizaci on de est andares con la tecnologa
802.11. Se denomina modelo de referencia IEEE 802.11.
Medio Medio
Aplicacin
Presentacin
Sesin
Transporte
Red
Enlace
Fsico Fsico
Logical link
control
Medium access
control
Capas
superiores
Modelo de
referencia
OSI
Modelo de
referencia
IEEE 802
mbito de los estndares
IEEE 802
Figura 2.1: Capas de protocolos de IEEE 802 y modelo de referencia OSI
Las capa m as baja del modelo de referencia 802 corresponde a la capa fsica
del modelo OSI, y tiene la funcionalidad de esta ultima:
Codicaci on/decodicaci on de se nales
Transmisi on/recepci on de bits
Pero adem as, el nivel fsico del modelo 802 incluye la especicaci on para el
medio de transmisi on y la topologa, considerado como funciones por debajo de
las tpicas del nivel fsico del modelo OSI.
Por encima de la capa fsica est a el nivel de enlace, que proporciona servicio
a los clientes de la red inal ambrica. Las funciones de este nivel son:
Cuando transmite, empaquetar los datos en una trama que incluye campos
para la direcci on y la detecci on de errores
21
Captulo 2. Tecnologa inal ambrica 802.11
Asociaci on
Autenticaci on
Des-autenticaci on
Disociaci on
Distribuci on
Integraci on
Entrega MSDU
Privacidad
Reasociaci on
Cuadro 2.2: Servicios de IEEE 802.11
Cuando recibe, desempaquetar los datos y realizar la detecci on de errores.
Controlar el acceso al medio de transmisi on de la red local
Proporcionar un interfaz a las capas superiores y realizar control de ujo
y de errores.
En el modelo 802 los tres primeros se agrupan en un subnivel llamado Control
de Acceso al Medio (MAC) y el ultimo en un subnivel llamado Control de Enlace
L ogico (LLC). Se puede ver el esquema en la gura 2.1.
Estos dos subniveles est an diferenciados por dos razones. La primera es por-
que normalmente en el nivel de enlace no se encuentran las funciones para
controlar el acceso al medio compartido. Y el segundo es que para el mismo
LLC se pueden usar diferentes MAC, por eso deben estar separados.
2.4.2. Servicios
El IEEE 802.11 dene nueve servicios que deben proporcionar las redes lo-
cales inal ambricas para prestar la misma funcionalidad que las redes locales
cableadas. Estos nueve servicios son los siguientes:
Distribuci on: Es el principal servicio usado por las estaciones para in-
tercambiar el MAC cuando un paquete debe ser transferido a otra zona.
Integraci on: Proporciona la transferencia de datos entre una estaci on de
una red local 802.11 y otra de una red local 802.x
Entrega MSDU: El MSDU (MAC Service Data Unit) es un bloque de
datos que se entrega desde el Control de acceso al medio de usuario al
nivel de control de acceso al medio.
Asociaci on: Establece una relaci on inicial entre un punto de acceso (AP:
Access Point) y una estaci on para que esta pueda enviar o recibir frames
de/desde la red WLAN.
Reasociaci on: Habilita una asociaci on creada para ser transferida desde
un punto de acceso a otro para permitir movilidad.
Disociaci on: Noticaci on por parte del punto de acceso o de la estaci on
para comunicar que la asociaci on ha terminado.
22
Captulo 2. Tecnologa inal ambrica 802.11
Autenticaci on: Se usa para establecer la identidad de cada estaci on. Es
necesario para que una estaci on pueda conectarse con un punto de acceso.
Des-autenticaci on: Cuando la autenticaci on debe ser terminada.
Privacidad: Para prevenir que el contenido de los mensajes transferidos
pueda ser ledo por otros que no sean el receptor. El algoritmo especicado
en el est andar es WEP.
2.4.3. Especicaciones de 802.11
Existen varias especicaciones de 802.11, entre ellas las m as usadas hoy en
da son:
IEEE 802.11a: Usa la banda de los 5 GHz, y puede alcanzar una tasa de
datos de 54 Mbps.
IEEE 802.11b: Funciona en la banda de los 2.4GHz y puede proporcionar
una tasa de datos de hasta 11 Mbps.
2.4.4. Conguraci on de una tarjeta inalambrica 802.11b
A continuaci on se va a presentar un ejemplo real de uso de la tecnologa
802.11b, para ello se va a congurar y usar una tarjeta que proporciona comu-
nicaciones a dispositivos usando este est andar.
La conguraci on de una tarjeta inal ambrica 802.11b, como con el resto de
dispositivos, depende del modelo de la tarjeta, del sistema operativo usado y de
la conguraci on del sistema. Pero como dijimos en el apartado 1.4, los sistemas
usados para la realizaci on de ensayos pr acticos han sido equipos con sistema
operativo GNU/Linux, en especial Debian GNU/Linux, por eso todas las con-
guraciones y pr acticas que se expliquen se referir an a dicho sistemas.
Las tarjetas 802.11b utilizadas durante las pruebas han sido tarjetas PCM-
CIA Lucent Technologies y Compaq, pero todas ellas tenan chipset de Lucent.
Para instalar una de estas tarjetas hay que seguir los siguientes pasos:
1. Instalar las fuentes del kernel de linux en /usr/src/linux sino est an insta-
ladas.
2. Instalar las fuentes del paquete PCMCIA en /usr/src/pcmcia
3. Congurar y recompilar las fuentes PCMCIA: usa congure y make en
/usr/src/pcmcia.
4. Recompilar el kernel antes del paso anterior solo si es necesario.
5. Los cheros de conguraci on se encuentran en /etc/pcmcia
Es aconsejable instalar las wireless tools para poder congurarla correcta-
mente. Despues de haberla instalado es necesario congurarla para adaptarla al
entorno que necesitemos.
23
Captulo 2. Tecnologa inal ambrica 802.11
Conguraci on del nivel de enlace
Debemos denir el tipo de arquitectura de la red a la que pertenece la tarjeta.
Existen varios modos, los m as comunes son el modo infraestructura y modo ad-
hoc, aunque ultimamente tambien es muy com un el poder poner estas tarjetas
en modo master. En el modo infraestructura todos los dispositivos se conectan
a un dispositivo central, normalmente un Punto de Acceso (AP), y todos estos
dispositivos se comunican unica y exclusivamente a traves de este dispositivo.
Sin embargo el modo ad-hoc se utiliza para que todos los dispositivos puedan
establecer comunicaciones con cualquier otro, pueden hablar todos con todos.
Esta ultimo modo es aconsejable cuando no existen muchos nodos, o cuando las
situaciones lo requieran: computaci on m ovil, redes ad-hoc, ... Y el modo master
sirve para que un dispositivo con una tarjeta congurada de esta forma pueda
hacer de punto de acceso para que otros dispositivos se conecten a el.
Para cambiar el modo de una tarjeta se utilizan las aplicaciones que pro-
porciona el paquete textitwireless tools. Si el interfaz de la tarjeta inal ambrica
es eth0, y queremos cambiar el modo a modo infraestructura debemos ejecutar
como superusuario:
> iwconfig eth0 mode managed
Tambien se puede denir que canal se quiere utilizar. La banda de frecuencia
utilizada por estas tarjetas va desde los 2.4 GHz hasta los 2.4835, y este rango
est a dividido en 13 canales, que se pueden utilizar para no solapar redes y evitar
interferencias. Por eso podemos elegir el canal en el que queremos que trabaje
la tarjeta:
> iwconfig eth0 channel 10
\end{vebatim}
Tambi en se puede definir el ESSID, que no es m as que un identificador
de la red a la que queremos conectarnos. Para configurar el ESSID:
\begin{verbatim}
> iwconfig eth0 essid nombre_red
Y tambien podemos denir el algoritmo de cifrado, la longitud de la clave,
...
Conguraci on del nivel IP
Aqu se debe congurar el nivel de red de la tarjeta. Esto puede ser algo
trivial o algo complejo dependiendo del dise no de red que queramos montar.
Para el caso m as sencillo en el que la tarjeta se va a conectar a una red en la
que existe un AP con el que debe de comunicarse, basta con asignarle los datos
de red a la interfaz de la tarjeta. Por ejemplo:
24
Captulo 2. Tecnologa inal ambrica 802.11
> ifconfig eth0 [Link] netmask [Link]
> route add -net default gw [Link]
Claro, que toda esta conguraci on no es necesario hacerla cada vez que
utilicemos la tarjeta. Toda esta conguraci on se puede almacenar en los cheros
de conguraci on del sistema para que no sea necesario repetir estas operaciones.
En el chero de conguraci on /etc/pcmcia/[Link] se pueden congurar
muchas de estas opciones.
25
Captulo 2. Tecnologa inal ambrica Bluetooth
2.5. Bluetooth
El objetivo de la tecnologa Bluetooth es proporcionar una capacidad de
comunicaci on universal de corto alcance. Funciona en la banda de los 2.4
GHz, como 802.11b, y puede alcanzar tasas de datos de hasta 720 kbps entre
dos dispositivos a una distancia de unos 10 metros.
Bluetooth puede ofrecer a los usuarios servicios como:
Utilizar unos cascos inal ambricos conectados a un telefono mediante Blue-
tooth.
Eliminar cables entre el ordenador y los perifericos como impresoras, te-
clados, ratones, ...
Hacer una llamada telef onica a casa para activar servicios como alarmas
o servicios de calefacci on.
2.5.1. Aplicaciones
Bluetooth est a dise nado para funcionar en entornos con muchos usuarios.
Se pueden crear peque nas redes de hasta 8 dispositivos llamadas piconet, y
pueden coexistir 10 de estas piconets en el mismo espacio de cobertura de Blue-
tooth. Cada una de estas redes codican sus datos y los protegen contra posibles
intrusiones e interferencias.
Proporciona soporte para tres areas de aplicaci on:
Puntos de acceso de voz y datos: Proporciona transmisiones en tiempo
real de voz y datos entre diferentes dispositivos.
Reemplazo de cables: Elimina los cables, incluso propietarios, para co-
nectar pr acticamente cualquier tipo de dispositivo. La distancia m axima
es de unos 10 metros, pero puede aumentarse hasta los 100 usando ampli-
cadores.
Redes ad-hoc: Dos dispositivos Bluetooth pueden establecer una cone-
xi on ad-hoc si se encuentran en el mismo rango de cobertura.
2.5.2. Estandares
Los est andares de Bluetooth son muy extensos, y est an divididos en dos
grupos:
Las especicaciones del n ucleo: describen los detalles de la arquitectura
de capas del protocolo Bluetooth, desde el interfaz radio hasta el control
de enlace
Las especicaciones de perles: cada perl describe el uso de la tecno-
loga descrita en el grupo anterior de especicaciones para adaptarla a un
modelo de uso concreto. Estos perles intentan especicar un est andar
de interoperabilidad para que cualquier dispositivo pueda interactuar con
cualquier otro.
26
Captulo 2. Tecnologa inal ambrica Bluetooth
Cada modelo de uso implementa una determinada aplicaci on basada en Blue-
tooth. Algunos de estos son:
Transferencia de cheros
Puente a Internet: Un ordenador est a conectado inal ambricamente a un
telefono o m odem inal ambrico que le proporciona acceso a Internet, fax,
...
Conexi on a red de area local: Cuando los dispositivos est an conectados a
una piconet.
Sincronizaci on: sincronizaci on de informaci on entre diversos dispositivos,
agenda de telefono, calendario, ...
Cascos de m usica inal ambricos.
Como hemos dicho antes, una piconet es una red de dispositivos inal ambri-
cos que contiene un nodo maestro y hasta 7 dispositivos esclavos. El maestro
selecciona el canal ( secuencia de frecuencias de salto ) y la fase de transmisi on
que deben utilizar todos los dispositivos de esa piconet.
Y una scatternet es cuando uno de los dispositivos pertenece a varias pi-
conet, ya sea como esclavo o maestro de cualquiera de ellas. De esta forma, una
gran cantidad de dispositivos pueden compartir el mismo espacio fsico y aprove-
char ecientemente el ancho de banda porque cada piconet tiene una frecuencia
distinta del resto asignada.
27
Captulo 2. Tecnologa inal ambrica IrDA
2.6. IrDA
IrDA es un est andar denido por el IrDA Consorcio[Ass93], y especica un
tipo de comunicaciones inal ambricas por medio de radiaciones de infrarrojos.
Es el protocolo por infrarrojos m as extendido en la actualidad.
Las comunicaciones por infrarrojos ofrecen un servicio de bajo coste y able
para conectar ordenadores y perifericos sin el uso de cables. Hoy en da todos
los ordenadores port atiles poseen dispositivo de infrarrojos IrDA integrado, y
tambien muchos dispositivos como telefonos m oviles o PDA.
IrDA presenta dos especicaciones b asicas dentro de las cuales existen unos
cuantos est andares para diversos dispositivos, que son IrDA Data e IrDA Con-
trol, y se describen a continuaci on.
2.6.1. IrDA Data
IrDA Data tiene como objetivo facilitar comunicaciones de alta velocidad
a corto alcance, con visi on directa y punto a punto para comunicaciones entre
un ordenador y diversos dispositivos, como c amaras digitales, dispositivos de
almacenamiento, ...
Consiste en una serie de protocolos obligatorios y algunos opcionales, que se
describen a continuaci on:
Nivel fsico
Rango: Normalmente el rango m aximo est a entre uno y dos metros, pero
hay modos especiales en los que si la distancia est a entre los 20 o 30
centmetros se puede reducir el consumo hasta unas 10 veces menos.
Comunicaciones bidireccionales
Transmisi on de datos desde los 9600 bps hasta los 115 kbps con una base
de precio/coste, pero puede alcanzar una velocidad m axima de 4 Mbps
Los paquetes de datos contienen c odigo de detecci on de errores.
Protocolo de acceso de enlace (IrLAP)
Proporciona comunicaci on able y ordenada entre dos dispositivos.
Proporciona servicios de descubrimiento de dispositivos
Maneja nodos ocultos
Protocolo de control de enlace (IrLMP)
Proporciona multiplexaci on de la capa anterior (IrLAP). Pueden existir
varios canales sobre una conexi on IrLAP
Proporciona un protocolo de descubrimiento de servicios.
28
Captulo 2. Tecnologa inal ambrica IrDA
Protocolos opcionales
Los protocolos anteriores son los b asicos que debe tener toda comunicaci on
de IrDA Data, pero existen otros protocolos especcos para diversos dispositivos
o modos de operaci on:
Tiny TP
IrCOMM
OBEX
IrDA Lite
IrTran-P
IrMC
IrLAN
2.6.2. IrDA Control
IrDA Control est a dise nado para permitir comunicaciones entre perifericos
como teclados, ratones o joystick y numerosos dispositivos como ordenadores,
televisiones, consolas de videojuegos, ...
Al igual que IrDA Data posee una pila de protocolos base:
Nivel Fsico
Distancia de unos cinco metros
Comunicaciones bidireccionales
Transmisi on de datos de hasta 75 Kbps
Los paquetes de datos contienen c odigo de detecci on de errores. Adem as la
capa fsica est a optimizaba para un bajo consumo y para poder realizarlo
a bajo coste
Control de Acceso al Medio (MAC)
Permite a un dispositivo comunicarse con m ultiples dispositivos, hasta 8
simult aneamente.
Proporciona tiempo de acceso muy r apido y baja latencia.
Control de enlace l ogico (LLC)
Proporciona caractersticas ables para asegurar la secuencia de paquetes y
las retransmisiones cuando se detectan errores.
En las siguientes secciones se van a describir algunos experimentos realizados
sobre la tecnologa IrDA utilizando diversos dispositivos.
29
Captulo 2. Tecnologa inal ambrica IrDA
2.6.3. Conguraci on de un dispositivo dongle
Normalmente, los ordenadores de sobremesa no cuentan con dispositivos de
infrarrojos integrados como los ordenadores port atiles, por tanto, es necesario el
uso de perifericos que provean de este tipo de conexi on al ordenador. El dispo-
sitivo que hemos utilizado para realizar esta labor ha sido un dongle ACTISYS
IR 220L plus, este dispositivo se conecta al puerto serie del ordenador.
Para congurarlo hay que realizar varias tareas:
Conguraci on del kernel
El kernel utilizado para la pruebas ha sido un kernel de la serie 2.4.x, aunque
con la serie 2.2.x debera funcionar, pero en este ultimo caso quiz as haya que
aplicar alg un parche al kernel.
Es necesario activar ciertas opciones en el kernel, en el apartado IrDA (infra-
red) Support, y lo mejor es introducir estas opciones como m odulos, y cargarlos
solo cuando vayamos a usar el dispositivo infrarrojos. Las opciones b asicas de
IrDA que se deben activar son las siguiente:
CONFIG IRDA
CONFIG IRLAN
CONFIG IRCOMM
CONFIG IRDA ULTRA
CONFIG IRDA OPTIONS
Las opciones para usar un dispositivo de infrarrojos conectado al puerto
serie:
CONFIG IRTTY SIR
CONFIG IRPORT SIR
Y la opci on especca para el dispositivo que hemos utilizado nosotros es el
siguiente:
CONFIG ACTISYS DONGLE
Software
Despues de esto, lo siguiente sera instalar el software necesario. Lo b asico
sera el paquete irda-common, que nos proporciona algunas herramientas como
irmanager o irattach, que nos ayudar an despues a congurar nuestro dispositivo.
Tambien se debe instalar el paquete irda-tools, que nos proporciona herra-
mientas como irdadump o irdaping, que nos ayudar an a depurar y a comprobar
el funcionamiento del dispositivo.
30
Captulo 2. Tecnologa inal ambrica IrDA
Conguraci on de los m odulos
Lo siguiente sera congurar los m odulos para que se carguen solos cuando
el kernel los necesite. Para ello hay que congurar los alias para el /etc/modu-
[Link].
Creamos un chero, por ejemplo, /etc/modutils/irda y metemos lo siguiente:
#modutils/irda
alias tty-ldisc-11 irtty
alias char-major-161 ircomm-tty
alias char-major-60 ircomm_tty
alias char-major-10-187 irnet
#for dongle
alias irda-dongle-2 actisys
alias irda-dongle-3 actisys+
Despues de esto hay que ejecutar update-modules para que se actualice el
chero /etc/[Link]
Creaci on de los dispositivos
A continuaci on necesitamos crear los dispositivos que va a utilizar el dispo-
sitivo para comunicarse. Para ello ejecutamos los siguientes comandos:
mknod /dev/ircomm0 c 161 0
mknod /dev/ircomm1 c 161 1
mknod /dev/irlpt0 c 161 10
mknod /dev/irlpt1 c 161 11
mknod /dev/irnet c 10 187
Funcionamiento del dispositivo de infrarrojos
Una vez que hemos seguido todos estos pasos ya tenemos el PC congurado
para poder usar el dispositivo de infrarrojos.
Para comprobar que hemos seguido todos los pasos bien, y que est a bien
congurado debemos ejecutar el siguiente comando.
irattach /dev/ttyS0 -d actisys -s
donde /dev/ttyS0 indica el puerto serie al que tenemos conectado el dis-
positivo, si lo tenemos conectado a otro puerto serie debemos cambiar este
par ametro.
Despues de esto podemos ejecutar lsmod y comprobar que los siguiente
m odulos se han cargado bien:
actisys
irtty
irda
Para hacer esto ultimo tambien se puede utilizar el script creado en /etc/i-
nit.d/irda, para poder cargar los m odulos cuando los necesitamos y descargarlos
cuando ya no nos hagan falta.
31
Captulo 2. Tecnologa inal ambrica IrDA
Y despues para comprobar si estos dispositivos emiten o reciben algo po-
demos congurar dos PCs, poner los dos dispositivos uno enfrente del otro, y
ejecutar irdadump en cada uno de los dos PCs. Con esto veremos los mensajes
que emite y que recibe cada uno de los dispositivos ...
Conexi on de dos ordenadores mediante TCP/IP sobre IrDA
La conexi on de los dos ordenadores mediante TCP/IP sobre Irda es muy sen-
cilla. Debemos tener cargados los m odulos necesarios para usar los dispositivos
como se indicaba en los apartados anteriores, y se deben poner un dispositivo
enfrente del otro, cada uno conectado a uno de los dos ordenadores.
Primero debemos asegurarnos de que tenemos disponibles las siguientes op-
ciones en el kernel, bien incluidas dentro de el o como m odulos :
IRNET
PPP GENERIC
PPP ASYNC
PPP DEFLATE
Y despues de esto se ejecuta lo siguiente en el ordenador uno:
pppd /dev/irnet 9600 local noauth dirIPpc1:dirIPpc2
Y esto en el ordenador dos:
pppd /dev/irnet 9600 local noauth dirIPpc2:dirIPpc1
Se sustituir a dirIPpc1 y dirIPpc2 por las direcciones IP del ordenador uno
y del ordenador dos respectivamente.
Cuando hemos ejecutado estos comandos se debe haber creado un dispositivo
de red llamado ppp0 con la direcci on IP que le hemos puesto en cada uno de los
PCs. El par ametro 9600 indica la velocidad de la conexi on, podemos cambiar
este par ametro y ponerle mayor velocidad, hasta 115200 ...
Y una vez que ya tenemos esto, tenemos disponible una conexi on TCP/IP
entre los dos PCs mediante los dispositivos infrarrojos.
Podemos probar a hacer ping entre las dos m aquinas, conexiones ssh, cone-
xiones http, y todo lo que se nos ocurra ...
2.6.4. Conguraci on de IrDA en un HP Jornada 548
Para las pruebas hemos utilizados dos PDAs distintos, uno de ellos es un
HP Jornada 548, que dispone de procesador a 133MHz 32-bit Hitachi, 32 Mb de
memoria RAM, pantalla de 240x320 pixels en color, puerto IrDA, USB, Serie,
... Este PDA corre sistema operativo Windows CE.
Las pruebas con este dispositivo han sido las de conectarlo a un ordenador
con una conexi on TCP/IP sobre Irda. Para ello son necesarios los siguientes
pasos:
Conguraci on del ordenador
En esta ocasi on, el ordenador equipado y congurado como se explica en
la secci on 2.6.3, debe congurarse especialmente para hacer de servidor de la
conexi on ppp (Point-to-point) que se va a crear entre el y el PDA. Los pasos
necesarios son los siguientes:
32
Captulo 2. Tecnologa inal ambrica IrDA
1. Crear un chero /usr/sbin/[Link] que contenga lo siguiente:
#!/bin/sh
pppd call cebox
Este chero ser a el que tendremos que ejecutar para lanzar el servidor de
la conexi on en el ordenador.
2. Crear un chero /etc/ppp/[Link] con lo siguiente:
AT OK
AT OK
AT OK
AT OK
AT OK
ATDT CONNECT
En este chero se indican las opciones de autenticaci on entre ambos (PC
y Jornada).
3. Y por ultimo hay que crear un enlace de /dev/irnine a /dev/ircomm0,
para ello:
ln /dev/ircomm0 -s /dev/irnine
4. Y crear el siguiente archivo /etc/ppp/peers/cebox con lo siguiente:
/dev/irnine 115200 nocrtscts
connect /usr/sbin/chat -v -f /etc/ppp/[Link]
noauth
local
dirIPpc:dirIPjornada
ms-dns servidorDNS
Y en este ultimo chero se indican algunas opciones de la conexi on. Habr a que
sustituir dirIPpc y dirIPjornada por las direcciones IP del ordenador y de
la HP Jornada respectivamente. Y tambien sustituir servidorDNS por la
direcci on IP del servidor de DNS disponible.
Conguraci on de la HP Jornada 548
Para la conguraci on del HP Jornada se deben seguir los siguiente pasos:
1. Primero se crea una nueva conexi on por m odem, para ello seleccionar la
opci on Start/Settings del men u, y dentro de esta opci on seleccionar la
pesta na que pone Connections. Se selecciona Modem.
2. Despues se selecciona New Connection ...
3. Se selecciona como m odem el Generic Irda Modem
4. Se elige la velocidad del m odem a 115200, y se selecciona la opci on advan-
ced ...
33
Captulo 2. Tecnologa inal ambrica IrDA
5. Se deja todo como est a excepto el ow control que se pone en software, y
se pulsa OK.
6. Se selecciona Next ...
7. En el apartado de n umero de telefono se pone todo a 0.
8. Se selecciona Next y despues Finish ...
Con esto ya hemos congurado el Jornada para que pueda hacer de cliente
de la conexi on ppp sobre TCP.
Funcionamiento de la conexi on
Cuando hemos realizado los pasos anteriores ya tenemos preparados el PC
y el Jornada para la conexi on TCP/IP.
Primero ejecutamos /usr/sbin/[Link], y ya estara dispuesto el ordenador
con GNU/Linux para hacer de servidor de la conexi on ppp.
Despues de esto ejecutamos el cliente de la conexi on en el Jornada, para ello
seleccionamos la opci on Start/programs del men u y seleccionamos el icono de
Connections. Ah aparecer a la conexi on que hemos creado anteriormente y solo
deberemos pulsar sobre esta conexi on para que se inicie la conexi on por ppp.
Y una vez terminado todo esto tenemos conectados al PC y al Jornada
mediante TCP.
Para hacer pruebas podemos poner por ejemplo un servidor web en el PC,
y probar a navegar por sus p aginas desde el Jornada con el Internet Explorer,
tambien podemos probar otras conexiones como ftp, telnet, ...
2.6.5. Conguraci on del puerto de infrarrojos en una Ipaq
El otro tipo de dispositivos PDAs utilizado han sido varios Compaq Ipaq
H3100, equipados con procesador StrongARM a 206 MHz, 64 Mb de memoria,
pantalla a color de alta calidad (320x240), puerto IrDA, ... En estos dispositivos
viene de serie el sistema operativo Windows CE, pero nosotros hemos instalado
el sistema operativo Familiar [Fam01], que es un sistema operativo basado en
Debian GNU/Linux pero para equipos sobre plataforma StrongARM.
La distribuci on de Familiar 0.4 que hemos usado tiene kernel 2.4.3, y junto
con la distribuci on vienen unos paquetes para usar Irda.
Estos paquetes son: irda-common e irda-modules-2.4.3.rmk2-np1
Y para instalarlos hay que hacer:
ipkg install irda-common
ipkg install irda-modules-2.4.3.rmk2-np1
Despues de esto habra que ejecutar depmod -ae porque el segundo de los
paquetes a nade al kernel los m odulos necesarios para usar Irda.
Y solamente con esto ya tenemos preparado el Compaq Ipaq para que utilice
el puerto de infrarrojos. Para activarlo haremos:
ifcong irda0 up; echo 1 /proc/sys/net/irda/discovery
Y para desactivarlo:
ifcong irda0 down; echo 0 /proc/sys/net/irda/discovery
34
Captulo 2. Tecnologa inal ambrica Otras tecnologas
2.7. Otras tecnologas
Adem as de estos tres tipos de tecnologa descritos en los apartados anteriores
( 802.11, Bluetooth e Irda ), existen muchos m as protocolos para proporcionar
comunicaciones inal ambricas, pero estos tres anteriores son los m as usados y los
que parecen tener un mayor futuro.
Los siguientes protocolos tambien facilitan la comunicaci on inal ambrica entre
dispositivos:
HiperLAN: Soporta canales de datos de 23.5 Mbps
HiperLAN2: funciona en la banda de frecuencia de los 5 Ghz, que puede
ser usada libremente en Estados Unidos y Asia, pero no en Europa. En
Europa utiliza otra frecuencia de libre uso.
DECT: Soporta canales b asicos de 64 o 96 kbps.
RadioLAN: Opera en la banda de frecuencia de los 5.8 Ghz.
35
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
2.8. Redes ad-hoc
Una red inal ambrica ad-hoc es una colecci on de dos o m as dispositivos equi-
pados con posibilidad de realizar comunicaciones inal ambricas para crear redes.
Estos dispositivos se pueden comunicar con los dem as, si est an en su rango de
cobertura o incluso si no est a en el. En este ultimo caso otro dispositivo debe
hacer de intermediario.
Una red ad-hoc es auto-organizada y adaptativa. Esto signica que la red
puede crearse o deshacerse sin necesidad de ning un sistema de administraci on.
El termino ad-hoc signica que puede tener diversas formas y puede ser m ovil,
individual o en red. Los nodos o dispositivos ad-hoc deben ser capaces de de-
tectar la presencia de otros dispositivos y de realizar el protocolo de bienvenida
a estos dispositivos para permitir la comunicaci on con ellos y poder compartir
informaci on y servicios.
Los dispositivos ad-hoc puede ser muy diversos ( PDAs, ordenadores port ati-
les, telefonos con conexi on inal ambrica, ... ), por tanto la capacidad de alma-
cenamiento, de computaci on y las caractersticas tecnicas de cada uno de ellos
pueden varias muchsimo. Los dispositivos ad-hoc no solamente deben detectar
la presencia de sus dispositivos colindantes, sino que debe identicar de que tipo
de dispositivos se trata y cu ales son sus atributos.
Como la red ad-hoc inal ambrica no se centra en ninguna entidad cableada,
estos tipos de redes no poseen ninguna infraestructura creada anteriormente
para poder realizar estas redes. Pero la informaci on para encaminar paquetes
a cada uno de los nodos debe cambiar y actualizarse para reejar la posible
movilidad de los dispositivos.
2.8.1. Heterogeneidad de dispositivos m oviles
Como hemos dicho, los atributos de cada uno de los dispositivos de la red
ad-hoc es importante, y estos dispositivos pueden tener variadas caractersticas,
lo que afectar a al rendimiento de las comunicaciones y al dise no de los protocolos
de comunicaci on entre ellos.
La tabla 2.3 muestra las caractersticas de alguno de estos dispositivos. Hay
diferencias en tama no, capacidad de c omputo, memoria, disco, capacidad de las
bateras, ...
La capacidad de un nodo ad-hoc para actuar como servidor o para ofrecer un
servicio determinado depender a de su capacidad de procesamiento, memoria y
otros factores. Por esta raz on habr a dispositivos en una red ad-hoc que podr an
actuar como servidores o proveedores de servicios mientras que otros solo podr an
actuar como clientes.
Uno de los factores m as importantes de estos dispositivos es la capacidad de
almacenar energa, porque normalmente las bateras de estos dispositivos son
de poca duraci on, y las comunicaciones inal ambricas normalmente a nade m as
consumo de energa. Por eso, cada dispositivo debe valorar su estado general
antes de realizar tareas para otros nodos, como encaminador intermedio entre
dos nodos o para ofrecer otros servicios.
36
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
Dispositivo Tama no(cm) CPU Memoria(Mb) Disco Batera
Palm Pilot 3.5x4.7 2.7 4-32 Ninguno 3-5.5
Telefono m ovil 2.5x5.5 16 1 Ninguno 3.6 V
Pocket PC 13x7.8 130-224 32-128 32 (ROM) 3.5
PC port atil 40x30 2000-2600 128-512 20-80 374-66
Cuadro 2.3: Caractersticas de algunos dispositivos existentes
2.8.2. Caractersticas especiales de las redes ad-hoc
Encaminamiento
La posibilidad de movilidad implica que los enlaces entre nodos pueden crear-
se y deshacerse a menudo y de forma no determinada. Por tanto, aunque se han
desarrollado muchos algoritmos de encaminamiento para redes ad-hoc, muchos
de estos protocolos no son ecientes cuando introducimos esta posibilidad de
movilidad en los nodos, que puede ser muy frecuente y de forma no denida.
Es necesario desarrollar nuevos protocolos que sean adaptables a entornos
en los que los nodos se mueven a menudo.
Multicast
El aumento del n umero de usuarios en Internet tambien se ha visto inuido
por la posibilidad de realizar conferencias de audio y de vdeo entre usuarios.
Para la realizaci on de estas conferencias entre varios usuarios son necesarios los
protocolos de multicast. Este protocolo se basa en el backbone, que lo forman
una serie de encaminadores multicast interconectados que son capaces de en-
caminar los paquetes multicast mediante t uneles por los encaminadores que no
son multicast.
La mayora de protocolos multicast se basan en el hecho de que los enca-
minadores son est aticos, y que los nodos no se van a mover cuando se han
establecido las comunicaciones. Por eso es necesario adaptar estos protocolos a
las redes ad-hoc.
Disponibilidad de energa
La mayora de los protocolos de red no consideran el consumo de energa
como un factor de dise no, ya que asumen que los encaminadores y nodos son
est aticos y por tanto est an conectados a la red electrica.
Pero los nodos m oviles utilizan bateras, y el campo de las bateras de energa
no ha avanzado a la velocidad del campo de la computaci on y proporcionan un
tiempo de vida muy limitado.
Por eso, es necesario tomar decisiones para el ahorro de energa en los dis-
positivos de redes ad-hoc, sobretodo cuando estos dispositivos no act uan como
clientes de las acciones realizadas por los usuarios sino cuando deben actuar
como intermediarios entre otros dispositivos.
Rendimiento de TCP
TCP es un protocolo punto a punto, dise nado para el control de ujo y
congesti on en la red. TCP es un protocolo orientado a conexi on, lo que implica
37
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
que hay una fase de establecimiento de conexi on antes de transmitir los datos.
TCP asume que los nodos entre el origen y destino son est aticos, y solo realiza
control de ujo y congesti on en el nodo origen y destino.
Desafortunadamente, TCP es incapaz de distinguir la presencia de movilidad
y de congesti on en la red. Por tanto la movilidad en los nodos puede provocar
perdida de paquetes y largos periodos de RTT (round-trip time ). Por eso es
necesario realizar algunos cambios para asegurar que el protocolo de transporte
realiza correctamente su labor sin afectar el rendimiento de las conexiones punto
a punto.
Servicios de localizaci on y acceso
Al igual que los protocolos son importantes para el rendimiento de la red
ad-hoc, los servicios que se pueden prestar en la red tambien son importantes,
como servicio de localizaci on y acceso.
Para la realizaci on de estos servicios es necesario que se realice todava mu-
cha investigaci on, porque la infraestructura que ahora se utiliza en otras redes
puede no ser la m as adecuada. Probablemente la arquitectura tradicional clien-
te/servidor no es v alida en estas redes, porque los clientes inician una petici on
de un servicio a otro nodo, y todos los nodos debido a sus caractersticas no
est an disponibles para realizar estas acciones.
2.8.3. Protocolos para redes ad-hoc
Como hemos dicho, las redes ad-hoc est an formadas por una colecci on de
nodos m oviles que cooperan entre ellos, sin la necesidad de intervenci on de
ning un punto de acceso centralizado. A continuaci on voy a mostrar el modo de
funcionamiento de estas redes ad-hoc.
La idea b asica de dise no de estas redes es que cada nodo act ua como un
encaminador, y peri odicamente anuncia la visi on que el tiene sobre la topologa
de conexi on de la red a los dem as nodos m oviles. Esta idea nos lleva a un nuevo
tipo de protocolo de encaminamiento para estas redes ad-hoc.
Desde un punto de vista te orico, una red ad-hoc es un grafo [Per01], que
est a formado por los nodos ( dispositivos m oviles ) y arcos entre estos nodos (
cobertura para la comunicaci on entre dos nodos ). La topologa que puede tener
este grafo puede ser arbitraria, porque no existen limitaciones sobre la situaci on
de cada nodo con respecto a los dem as.
Los protocolos dise nados para estas redes pueden ser clasicados en varias
categoras [RT99] [Toh02] que presentamos a continuaci on junto con algunos
ejemplos de protocolos de cada categora:
Dirigido por tablas de encaminamiento
Los protocolos de encaminamiento de redes ac-hoc dirigidos por tablas in-
tentan mantener consistente y actualizada la informaci on de encaminamiento de
las rutas desde cada nodo a los otros nodo de la red. Estos protocolos requieren
que cada nodo mantenga una o m as tablas con informaci on de encaminamiento,
y que respondan a los cambios de la topologa de red propagando las rutas a
traves de la red para mantener la consistencia.
38
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
La diferencia entre ellos consiste en el n umero de las tablas de encaminamien-
to necesarias y el modo de actualizar la informaci on con los cambios producidos
en la red.
DSDV ( Destination Sequenced Distance Vector ): Est a basado en el
algoritmo cl asico de encaminamiento distribuido Bellman-Ford [Bel58]. La
mejora realizada es evitar la creaci on de bucles en la red de encaminadores
m oviles (nodos). Cada nodo de la red mantiene una tabla de rutas con los
posibles nodos destinos y el n umero de saltos hasta ellos.
Las actualizaciones de las tablas son enviadas a la red para mantener
la consistencia, pero para que estas operaciones no consuman m as ancho
de banda del necesario existen dos tipos de paquetes de actualizaci on de
rutas. Uno de ellos enva toda la informaci on disponible sobre encamina-
miento, y suele enviarse espor adicamente cuando hay escasos movimientos
de red. El otro tipo de paquetes con actualizaci on de rutas contiene solo
la informaci on que ha cambiado desde el envo del ultimo paquete de este
tipo.
WRP ( Wireless Routing Protocol ):
WRP mantiene cuatro tablas:
Tabla de distancia: indica el n umero de saltos entre un nodo y su
destino
Tabla de encaminamiento: indica el siguiente salto hacia el destino
Tabla de coste de enlace: retardo asociado a una determinada ruta
Tabla de lista de retransmisi on de mensajes: contiene un n umero de
secuencia del mensaje de actualizaci on, un contador de retransmi-
siones, un vector de conrmaciones y una lista de actualizaciones
enviadas en un mensaje de actualizaci on.
Los nodos envan mensajes de actualizaci on peri odicamente. El mensaje
contiene una lista de actualizaciones, y una lista de respuestas indicando
que nodos deben conrmar la actualizaci on. Un nodo enva un mensaje
de actualizaci on despues de procesar los mensajes de actualizaci on de sus
vecinos o cuando detecta cambios en alg un enlace.
Una parte original de este protocolo es la forma que tiene de encargarse de
los bucles. En WRP los nodos anuncian la distancia y la informaci on sobre
el segundo salto para cada destino en la red inal ambrica. WRP pertenece
a la clase de algoritmos de b usqueda de caminos pero con una importante
excepci on, evita el problema de cuenta hasta el innito forzando a cada
nodo a realizar comprobaciones de la informaci on que le enva el nodo
predecesor acerca de los vecinos.
CSGR (Cluster Switch Gateway Routing ): Los nodos son agrupados y
cada grupo contiene un director. Con la creaci on de estos grupos se esta-
blece una forma de jerarqua, en los que cada director puede controlar su
grupo de nodos ad-hoc.
El director es elegido mediante un algoritmo distribuido, y cuando un
director se mueve fuera del grupo, se elige otro director. El problema
39
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
puede surgir cuando el director cambia frecuentemente porque los nodos
gastan mucho tiempo y recursos eligiendo al nuevo director.
CSGR usa DSDV como algoritmo base de encaminamiento, pero modi-
cado para utilizar la jerarqua introducida de los directores y los grupos.
Por demanda iniciada en origen
Este tipo de encaminamiento crea rutas solamente cuando es solicitado por
un nodo origen. Cuando un nodo necesita una ruta hacia un destino, inicia
un proceso de descubrimiento de rutas dentro de la red. Este proceso termina
cuando se han examinado todas las posibles rutas y se encuentra una ruta
disponible. Cuando se ha establecido una ruta entre dos nodos, esta informaci on
es mantenida hasta que el destino pasa a ser inalcanzable desde el origen o
cuando la ruta ya no es necesaria.
AODV(Ad Hoc On Demand Distance Vector Routing ): Este protocolo
es una mejora del protocolo DSDV, porque AODV minimiza el n umero de
mensajes broadcast por la red mediante el metodo de creaci on de rutas
cuando son solicitadas por un nodo origen, en lugar de mantener una lista
completa de rutas como en DSDV.
Cuando un nodo quiere mandar un mensaje a un destino y no posee una
ruta v alida inicia un procedimiento de descubrimiento de ruta: enva un
broadcast solicitando ruta (RREQ: Route request ) a sus vecinos, estos
reenvan el mensaje a sus vecinos, y as sucesivamente hasta que la solicitud
llega al destino o a un nodo con informaci on able de la ruta solicitada.
Cuando el nodo destino o el nodo con informaci on able recibe la solicitud
enva un paquete de respuesta (RREP: Route reply ) al nodo origen. Este
paquete es enviado al nodo origen y es encaminado por el mismo camino
que lleg o el RREQ, porque cada nodo intermedio al que le lleg o este primer
mensaje almacen o el nodo por el que le haba llegado, por tanto se puede
reconstruir el camino inverso del RREQ para hacer llegar el RREP al nodo
emisor. Cuando el nodo origen recibe el RREP ya puede mandar los datos
al destino porque los nodos intermedios han aprendido la ruta.
Cada paquete RREQ contiene un n umero de secuencia para evitar bucles
si los nodos intermedios lo reciben m as de una vez, y de este modo no los
vuelven a reenviar. Los enlaces son simetricos, porque el RREP vuelve por
donde lleg o el RREQ, y los nodos intermedios guardan informaci on sobre
el siguiente salto para un destino en su tabla de rutas.
DSR ( Dynamic source routing ): Este protocolo tambien est a basado en
el concepto de encaminamiento en origen. Los nodos deben mantener una
cache de rutas que contienen las rutas en origen que conciernen a ese nodo.
El protocolo consiste en dos fases:
Descubrimiento de rutas: Cuando un nodo quiere mandar un men-
saje a otro y no posee una ruta v alida, inicia un procedimiento de
descubrimiento de rutas enviando mediante broadcast un paquete
RREQ, este paquete contiene el nodo origen, el nodo destino y un
identicador. Cuando los otros nodos reciben el paquete comprueban
40
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
si conocen la ruta solicitada, si no la conocen a naden su direcci on al
paquete y lo reenvan a sus vecinos.
Si el nodo que recibe el paquete conoce la ruta, coloca esta ruta
en el paquete RREP y se lo enva al origen. Si el nodo que recibe
el paquete es el destino, a nade su direcci on a la lista de nodos del
RREQ, la copia en el paquete RREP y se la enva al origen. Para
enviar el RREP hay dos opciones: si est an disponibles los caminos
simetricos se utiliza el camino inverso por el que ha llegado el RREQ,
y sino se inicia un nuevo RREQ para hallar la ruta hacia el origen
del primer RREQ.
Mantenimiento de rutas: El mantenimiento de rutas se realiza me-
diante paquetes de errores en rutas (RERR) y conrmaciones. Cuan-
do un nodo detecta error en un enlace enva un RERR, y los nodos
que lo reciben borran las rutas que almacenan en sus caches hacia ese
nodo, o las truncan en la parte que aparece el enlace que no funciona.
Los paquetes de conrmaci on son usados para vericar el estado de
los enlaces entre nodos.
TORA (Temporally Ordered Routing Algorithm ): Este protocolo es muy
adaptable, libre de bucles basado en los enlaces inversos. Est a dise nado
para funcionar en entornos muy din amicos con alta movilidad en los no-
dos de la red. Es iniciado en origen y facilita m ultiples rutas para un
determinado origen-destino.
La clave de este protocolo es la localizaci on de mensajes de control en un
conjunto muy reducido de nodos cercanos al cambio en la topologa. Los
nodos mantienen informaci on de encaminamiento sobre los nodos vecinos
m as pr oximos, un solo salto.
La clave de este protocolo es la reacci on ante fallos de enlaces. La reacci on
ante este hecho es organizada mediante la difusi on de secuencias de enlaces
inversos. Cada enlace inverso consiste en la b usqueda de rutas alternativas
para el destino. Esta b usqueda a menudo solo necesita la ejecuci on del
procedimiento una sola vez, con lo que se reduce el n umero de mensajes
necesarios para actualizar las rutas.
Hbridos
ZRP(Zone Routing Protocol ):

Este es un protocolo hbrido, que incorpora
las ventajas de los protocolos por demanda y de los protocolos pro-activos.
Cada zona de encaminamiento es similar a un grupo con la excepci on de
que cada nodo act ua como director y como miembro de otros grupos, las
zonas se pueden superponer. El tama no de las zonas afecta al rendimiento
de las comunicaciones en la red.
Cada zona contiene unos pocos nodos m oviles con uno, dos o m as sal-
tos hasta el nodo central de la zona, dentro de cada zona el protocolo de
encaminamiento utilizado es un protocolo dirigido por tablas de encami-
namiento. Por tanto las actualizaciones de rutas se realizan dentro de la
zona, y cada nodo tiene una ruta hacia todos los nodos dentro de la zona.
41
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
Cuando un nodo quiere comunicarse con otro que no est a dentro de su
zona, debe iniciar una b usqueda mediante un protocolo de encaminamiento
por demanda.
2.8.4. Practicas con redes ad-hoc
Como hemos dicho en los apartados anteriores, las redes ad-hoc est an forma-
das por dispositivos m oviles. Estos dispositivos m oviles pueden ser ordenadores
port atiles, PDAs, ... Pero tambien existen otro tipos de dispositivos m oviles
que pueden coexistir con los anteriores y que est an provistos de funcionalidades
totalmente distintas pero muy interesantes, y son los que se han utilizado para
realizar pr acticas sobre redes ad-hoc.
Estos dispositivos son peque nos robots, comercialmente conocidos como Le-
gos Mindstorms, que disponen de un peque no procesador (Hitachi 8300), mo-
tores y varios sensores. El sistema operativo de estos dispositivos es bastante
limitado a la hora de programar sobre ellos aplicaciones con cierto grado de
complejidad, por ello, existe otro sistema operativo alternativo llamado LegOS,
que se puede instalar en estos robots y tiene las siguientes caractersticas:
Capacidades para ejecutar varias tareas
Mecanismos de ahorro de energa
Gesti on din amica de memoria
Uso de sem aforos
Acceso a los cada uno de los elementos de los robots:
Display
Botones del RCX
Motores
Sensores
Comunicaci on por Infrarrojos
Precisamente el ultimo punto, la comunicaci on por infrarrojos, va a permi-
tir a los robots ejecutar un protocolo de encaminamiento ad-hoc simplicado
de forma que desde cualquier robot se puedan establecer comunicaciones con
cualquier otro robot dentro de la red ad-hoc.
Dise no de la practica con redes ad-hoc
Lo que se ha pretendido con la pr actica es lo siguiente: Tenemos un con-
junto de robots con capacidad de comunicaciones por infrarrojos, y vamos a
implementar un protocolo para redes ad-hoc de los que hemos descrito en la
secci on 2.8.3, para que este grupo de robots sea capaz de comunicarse entre
ellos, puedan crear una red ad-hoc solamente descubriendo cada uno de ellos a
sus vecinos, y permitan la movilidad de los mismos, con lo que se crear an nuevas
rutas y se eliminar an otras existentes.
Ya que la interacci on con estos robots es compleja, porque el sistema de
entrada/salida es muy limitado, se va a crear tambien una capa de software
42
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
sobre el protocolo implementado para su posible uso desde un ordenador, y
poder interactuar con estos robots desde el. Se va a crear un interfaz web en el
ordenador, para que desde el se pueda transmitir informaci on a los nodos que
esten en la red ad-hoc.
Por tanto, el objetivo nal va a ser, que a cada nodo se le va a asignar un
identicador, que va a ser la direcci on que les va a identicar unvocamente en
la red. Desde el interfaz web del ordenador se le van a enviar datos a uno de los
robos que este en la red y mediante el protocolo de comunicaciones implemen-
tado los datos le llegar an al dispositivo y lo mostrar a por la peque na pantalla
de que disponen.
El protocolo elegido para la implementaci on ha sido DSR.
Implementaci on del protocolo DSR
Las funciones implementadas del protocolos son las siguientes:
Route Discovery:
Mediante esta funci on, el nodo que quiere enviar un mensaje inicia el pro-
ceso para calcular la ruta hacia el destino. Mediante el envo de paquetes
RREQ por la red, y mediante el reenvo de este paquete por los nodos
intermedios al nal recibir a un mensaje RREP con la informaci on de la
ruta que necesitaba.
Las rutas utilizadas son simetricas, por tanto el mensaje RREP vuelve por
el mismo camino por el que lleg o el RREQ.
Route Maintenance:
Al originarse o encaminar un paquete utilizando una ruta en origen, cada
nodo que transmite el paquete es responsable de la conrmaci on de que el
paquete ha sido recibido por el siguiente salto de la ruta en origen. En el
ejemplo siguiente, el nodo A desea enviar un paquete al nodo E utilizando
ruta en origen a traves de los nodos intermedios B, C y D.
+-----+ +-----+ +-----+ +-----+ +-----+
| A |---->| B |---->| C |--x | D | | E |
+-----+ +-----+ +-----+ +-----+ +-----+
En este caso, el nodo A es responsable de la recepci on del paquete en el
nodo B, el nodo B es responsable de la entrega del paquete en el nodo C,
el nodo C de la recepci on en el nodo D, y el nodo D es responsable de la
recepci on nal en el nodo destino E.
Si no se recibe conrmaci on de que el paquete ha sido recibido en el nodo
siguiente de la ruta, tras un n umero m aximo de intentos, el nodo que es
responsable de la entrega del paquete en el siguiente nodo debera devolver
un Route Error al nodo emisor del paquete indicando el enlace por el cual
no ha podido ser encaminado el paquete. En el ejemplo anterior, el nodo
C no puede entregar el paquete en el siguiente nodo, el D, y devuelve un
Route Error a A indicando que el enlace entre C y D est a cado. El nodo
A eliminar a de su Route Cache el enlace para ese nodo.
43
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
Actualizaci on de Route Caches en nodos intermedios
Un nodo que est a en la ruta en origen de un paquete, puede a nadir in-
formaci on de encaminamiento al encaminar los paquetes hacia el nodo
destino a su propia Route Cache de cara a poder utilizarla en futuros
envos.
Por ejemplo, el nodo A utiliza una ruta en origen para comunicarse con
E.
+-----+ +-----+ +-----+ +-----+ +-----+
| A |---->| B |---->| C |---->| D |---->| E |
+-----+ +-----+ +-----+ +-----+ +-----+
Como el nodo C encamina el paquete en la ruta desde A hasta E, puede
actualizar su cache con la informaci on de las rutas hacia A y hacia E.
Respuestas a las Route Requests
Cuando un nodo recibe un Route Request para la cual el no es el destino
de la misma, busca en su Route Cache a ver si existe una ruta para el nodo
destino de la petici on. Si la encuentra, el nodo generalmente devuelve un
Route Reply al emisor en vez de continuar enviando la solicitud hasta el
nodo destino. En la Route Reply, este nodo actualiza la lista de nodos que
tiene que seguir el paquete en su camino hasta el destino, concatenando
los que ya traa con los de la ruta que tena en su cache.
Sin embargo, antes de transmitir la Route Reply, el nodo debe vericar que
la lista resultante a enviar en la Route Reply no contenga nodos duplicados.
Por ejemplo, la siguiente gura ilustra una situaci on en la que la Route
Request para el destino E ha sido recibida por el nodo F, y el nodo F ya
tiene en su Route Cache una ruta de el mismo hasta el nodo E:
+-----+ +-----+ +-----+ +-----+
| A |---->| B |- >| D |---->| E |
+-----+ +-----+ \ / +-----+ +-----+
\ /
\ +-----+ /
>| C |-
+-----+
| ^
v |
Route Request +-----+
Route: A - B - C - F | F | Cache: C - D - E
+-----+
La concatenaci on de la lista de nodos que traa la Route Reply con la ruta
que el nodo F tena en su Route Cache produce un nodo duplicado al
pasar de C a F y de F a C nuevamente.
44
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
Implementaci on del interfaz web
El ordenador va a ser el encargado de interactuar a traves de infrarrojos con
la red ad hoc que formen los Lego Mindstorms. El PC va formar parte de la red,
siendo un nodo especial encargado de iniciar las peticiones al resto de nodos.
Las interacci on del PC con el usuario se realizar an a traves de HTTP, por
lo que el programa que se ejecute en el PC ser a un servidor que responda a
peticiones HTTP.
Adem as el ordenador tiene que utilizar tambien el protocolo utilizado para
comunicarse con los robots de la red ad-hoc, ya que el tambien forma parte de
esta red. Y este nivel de protocolo ad-hoc en el ordenador ir a acompa nado de la
librera que proporcionan los legos para la comunicaci on por infrarrojos desde
el ordenador.
En el PC por tanto vamos a tener los siguientes elementos:
Servidor HTTP.
Nivel DSR.
Demonio LNP.
Por tanto el funcionamiento ser a: El ordenador recibe una petici on a traves
del servidor web, la procesa y efect ua las llamadas pertinentes al protocolo DSR
implementado para comunicarse con los robots.
Maqueta de pruebas
Dados una serie de Legos Mindstorm (5 o 6 aproximadamente) separados por
distancias considerablemente signicativas, se han de poder comunicar todos con
todos usando la versi on simplicada del protocolo DSR.
La gura 2.2 ilustra un posible escenario en el que se desarrollaran las
pruebas y el ujo de control que seguira cada elemento:
Inicialmente, cada robot est a identicado con un n umero que se utilizar a en
los paquetes, en los campos de direcci on origen y de direcci on destino (a modo
de direcci on IP).
El ordenador conoce a priori cu antos nodos pueden formar la red Ad Hoc,
de forma que en cualquier momento, desde el interfaz web se puede enviar
informaci on a cualquiera de ellos.
Cada robot posee un radio de acci on limitado, por lo que mediante los me-
canismos de encaminamiento Ad Hoc de la versi on simplicada del protocolo
DSR, se puede alcanzar cualquier nodo (siempre que estos esten disponibles).
Al comenzar, todos los robots tienen sus Route Caches vacas. Desde la
interfaz web se solicita, por ejemplo, mandar informaci on al robot n umero 5.
Esta petici on le llega al ordenador que se la hace llegar al robot n umero 1 que
es el que hace de enlace entre la red Ad Hoc y el ordenador.
El primer paso para el robot 1 es consultar su Route Cache. Como no tiene
ninguna entrada para el nodo 5 solicitado, inicia el mecanismo de Route Disco-
very y enva un mensaje de broadcast con el Route Request Packet. En la parte
de datos indicar a, aparte del identicador de solicitud y el nodo destino, la lista
de nodos por los que ha pasado el mensaje y que inicialmente solo contendr a un
elemento, el 1 correspondiente al nodo solicitante de la ruta.
45
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
1
2
3 4
5
Figura 2.2: Maqueta red ad-hoc. Situaci on inicial
Este paquete es recibido por el nodo 2, que al no ser el nodo destino solici-
tado retransmitir a el paquete. De esta forma, con sucesivas retransmisiones, el
paquete se difundir a por la red, y cada nodo que no sea el nodo destino de la
solicitud, se a nadir a a la lista de nodos y retransmitir a el paquete.
De esta forma, la retransmisi on de la solicitud del robot 2, alcanzar a al robot
5.

Este, al ser el nodo destino de la solicitud enviar a un Route Reply al nodo 1
utilizando la ruta recien creada para hacerle llegar el paquete. Por tanto, en la
parte de datos se indicar a el identicador de la solicitud a la que se contesta y
la ruta que ha de seguir.
La nueva ruta creada (1-2-5) ser a utilizada por los nodos que la componen
y a traves de los cuales pasar a el Route Reply Packet, para actualizar sus Route
Caches. De esta forma, se tienen las siguientes entradas en cada uno de estos
nodos:
Robot #1:
Nodo destino Ruta
2 1
5 2
Robot #2:
Nodo destino Ruta
1 2
5 2
Robot #5:
46
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
Nodo destino Ruta
1 2
2 5
En la gura 2.3, el robot 5 ha cambiado de situaci on y ya no est a bajo el
radio de acci on del robot 2.
1
2
3 4
5
Figura 2.3: Maqueta red ad-hoc. Situaci on 2
Nuevamente se desea mandar informaci on al robot 5. El nodo 1 consulta su
Route Cache y ve que para enviar un paquete al nodo5 tiene que pasar por el
nodo 2, por lo que enva un paquete dirigido al nodo siguiente en la lista de
nodos a atravesar (2) para hacerle llegar la informaci on junto con dicha lista
(1-2-5).
Al llegar el mensaje al robot 2, este lo enva al siguiente nodo que es a la vez
el nodo destino, el robot 5. Sin embargo, dicho robot ya no recibe el mensaje
porque ya no est a en el radio de acci on del nodo 2, por lo que tras no una
serie de reintentos del nodo 2 de hacerle llegar el mensaje y ver que no obtiene
el Route ACK Packet correspondiente (que informa de que el paquete ha sido
entregado correctamente), enva un Route Error Packet al nodo origen, el 1,
para indicarle que el nodo 5 ya no es alcanzable desde el nodo 2.
Al recibir el Route Error el nodo 1, iniciar a nuevamente el proceso de Route
Discovery, siguiendo los mismos pasos que para la gura 2.2.
En este caso, el robot 3 es el nuevo (y unico) enlace hacia el nodo destino
5. Las Route Caches de los nodos son nuevamente actualizadas quedando como
sigue:
Robot #1:
47
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
Nodo destino Ruta
2 1
3 2
5 2-3
Robot #2:
Nodo destino Ruta
1 2
3 2
5 3
Robot #3:
Nodo destino Ruta
1 2
2 3
5 3
Robot #5:
Nodo destino Ruta
1 3-2
2 3
3 5
Otra posible situaci on representara la que se muestra en la gura 2.4:
Las Route Caches quedaran de la siguiente manera:
Robot #1:
Nodo destino Ruta
2 1
3 2
4 2-3
5 2-3-4
Robot #2:
Nodo destino Ruta
1 2
3 2
4 3
5 3-4
Robot #3:
Nodo destino Ruta
1 2
2 3
4 3
5 4
48
Captulo 2. Tecnologa inal ambrica Redes ad-hoc
1
2
3 4
5
Figura 2.4: Maqueta red ad-hoc. Situaci on 3
Robot #4:
Nodo destino Ruta
1 3-2
2 3
3 4
5 4
Robot #5:
Nodo destino Ruta
1 4-3-2
2 4-3
3 4
4 5
49
Captulo 3
Movilidad
3.1. Introducci on a la movilidad sobre TCP/IP
Como hemos explicado en el captulo anterior, el aumento de uso de los dis-
positivos inal ambricos cada da es m as frecuente y nos ofrece otra perspectiva de
uso de los dispositivos electr onicos, ordenadores personales, agendas electr onicas
y otros dispositivos m oviles.
En esta nueva perspectiva uno de los factores m as relevantes es que el uso
de estos dispositivos ya no se debe realizar desde un lugar est atico, como ante-
riormente, sino que ahora nos ofrecen la posibilidad de moverse con nosotros,
nos ofrecen una posibilidad de movilidad de dispositivos junto con los usuarios.
Para que esta movilidad ofrezca un servicio realmente util para los usuarios
no debe ser solamente que los dispositivos puedan moverse de un lugar a otro,
sino que la posibilidad de movimiento se realiza junto con las comunicaciones
que este llevando a cabo el dispositivo. Necesitamos que los dispositivos tengan
la posibilidad de movilidad entre redes.
Las redes sobre las que se mueven estos dispositivos son redes que funcionan
sobre la pila de protocolos TCP/IP, y por eso el proporcionar movilidad a los
dispositivos sobre estas redes no es algo inmediato. La base de las comunica-
ciones sobre TCP/IP es que cada nodo dispone de una direcci on con la que
se le identica unvocamente, y esta direcci on sirve para encaminar todas las
comunicaciones que se generan desde y hacia el.
Esta direcci on que cada nodo posee es asignada dependiendo de la red a
la que este conectado, y depende directamente de ella. Si un nodo cambia de
red a la que est a conectado y contin ua con la direcci on IP de la otra red no
podr a comunicarse m as, porque las paquetes de datos son encaminados hacia la
red a la que pertenece esa direcci on.
Por todo ello, necesitamos alg un mecanismo que proporcione la posibilidad
de moverse entre redes para estos dispositivos inal ambricos y que puedan se-
guir comunic andose normalmente y de forma transparente para el usuario y
las aplicaciones independientemente de la red a la que este conectado en cada
momento.
Estos mecanismos son los mecanismos de movilidad, que se pueden englobar
en dos tipos:
Micro-movilidad: la movilidad que se realiza entre varios puntos de acceso
50
Captulo 3. Movilidad Introducci on a la movilidad sobre TCP/IP
Macro-movilidad: la movilidad que se realiza entre varias subredes de una
misma organizaci on
Estos dos tipos de protocolos de movilidad intentan solucionar el mismo
problema, pero desde diferentes grados de la movilidad necesaria por los no-
dos m oviles. Existen diferentes protocolos para cada uno de estos grupos de
movilidad:
Protocolos de micro-movilidad:
Mobile IP
Protocolos de macro-movilidad:
Cellular IP
Hawaii
Hierarchical Mobile IP
De estos protocolos existen varias implementaciones, pero los protocolos m as
usados y que parece que ser a los que pasar an a ser usados son: Mobile IP y
Cellular IP. Estos protocolos ser a los que describire en las pr oximas secciones,
y los que hemos usado para realizar los ensayos pr acticos.
En la tabla 3.1 se muestran algunas de las implementaciones de estos proto-
colos y sus caractersticas.
51
C
a
p

t
u
l
o
3
.
M
o
v
i
l
i
d
a
d
I
n
t
r
o
d
u
c
c
i
o
n
a
l
a
m
o
v
i
l
i
d
a
d
s
o
b
r
e
T
C
P
/
I
P
Protocolo Proyecto Sistema
operativo

Ultima versi on
Licencia Lenguaje de prog
MobileIPv4
Mobile IP at NUS Linux 2.0.34 3.0beta GPL C
Monarch NetBSD 1.1
FreeBSD 2.2.2
1.1.0 FreeBSD-like C
Secure Mobile FreeBSD 4.5
Linux 2.2.12-20
4.5 FreeBSD-like C
Solaris Solaris 2.5.1, 2.6 ? Solaris License C
Linux Mob IP Linux 2.2.x 2.0.2beta FreeBSD-like C
MobileIPv6
Mobile IP at NUS Linux 2.1.59 1.0alpha GPL C
Monarch FreeBSD 2.2.2 1.0 BSD-like C
MIPL Linux 2.4.x 0.9.1 GPL C
Lancaster Linux 2.1.9x 0.4beta Non libre ?
CellularIP
Columbia Linux 2.2.14
FreeBSD 3.2
1.1(Linux)
1.0(FreeBSD)
Prop C
Hierarquical Mobile IP
Dynamics Linux 2.2.x,
2.4.x
0.8.1 GPL C
Hierarchical Mobile IPv6
Inria FreeBSD 3.4 2.0 BSD-like C
Cuadro 3.1: Implementaciones de protocolos de micro/macro movilidad
5
2
Captulo 3. Movilidad Mobile IP
3.2. Mobile IP
3.2.1. Fundamentos de Mobile IP
Mobile IP [Per96] es una modicaci on del protocolo IP que permite a los
nodos continuar recibiendo datagramas independientemente de la red a la que
esten conectados, esto conlleva mensajes de control adicionales que permiten
manejar el encaminamiento de los datagramas. Este protocolo ha sido dise nado
con la premisa de que debe ser escalable, porque se espera que en el futuro un
gran porcentaje de los nodos conectados a Internet sea m ovil.
El protocolo IP asume que una direcci on IP identica unvocamente el punto
de conexi on a la red de un nodo. Antes de que un nodo pueda recibir datagra-
mas, ese nodo debe ser identicado en la red en la que est a conectado, sino el
nodo ser a inalcanzable. Si no utilizamos Mobile IP, uno de los dos mecanismos
siguientes podra ser utilizado para que un nodo cambie de punto de conexi on
a la red sin perder la conexi on a la red:
Un nodo puede cambiar su direcci on IP cada vez que cambia de punto de
conexi on a la red
Rutas especcas para cada nodo pueden ser propagadas por la parte de
infraestructura de red relevante
En general, cualquiera de estas soluciones son inaceptables. Con la primera
es imposible que el nodo mantenga la conexi on del nivel de transporte y supe-
riores cuando el nodo cambia el punto de conexi on. Y la segunda soluci on tiene
claros problemas para poder escalar, m as a un cuando aumente el n umero de
dispositivos m oviles.
Los siguientes objetivos son los b asicos que cualquier implementaci on de
Mobile IP [Per97] debe cumplir:
Un nodo m ovil debe ser capaz de comunicarse con otros nodos despues de
cambiar su punto de conexi on a la red, incluso sin cambiar su direcci on
IP.
Un nodo m ovil debe ser capaz de comunicarse con otros nodos que no co-
rren ninguna implementaci on de Mobile IP. No es necesario que los nodos
o encaminadores que no cumplen alguno de las funciones del mecanismo
de Mobile IP tengan ninguna caracterstica especca en su pila de proto-
colos.
Los mensajes que se envan para informar del punto de conexi on a la red
de un nodo deben ser autenticados, para protegerse contra ataques por
redirecciones.
Normalmente el medio de enlace de los dispositivos m oviles es inal ambrico,
lo que conlleva un menor ancho de banda y una mayor tasa de errores que
un enlace por cable. Por tanto, el n umero de mensajes de control que son
enviados al nodo m ovil debe ser minimizado al m aximo, y el tama no de
estos mensajes debe ser tan peque no como sea posible.
Mobile IP no debe poner restricciones a la hora de asignar direcciones IP
a los nodos m oviles, cada organizaci on debe asignar las direcciones que le
pertenezcan.
53
Captulo 3. Movilidad Mobile IP
FA
Internet
Nodo C
Subred A
Subred B
Subred C
HA: Home Agent
FA: Foreign Agent
HA
FA FA
Mobile node
Mobile node
Mobile nodes
Figura 3.1: Infraestructura de nodos en Mobile IP
Mobile IP habilita a los nodos m oviles para moverse de una subred a otra,
y esta operaci on puede realizarse entre medios heterogeneos u homogeneos. Es
decir, un nodo puede moverse de una red Ethernet a otra, de una red Ethernet
a otra inal ambrica, ...
3.2.2. Infraestructura de Mobile IP
Mobile IP necesita que una serie de nodos tengan una funcionalidad especial
para que tener la infraestructura necesaria:
Mobile Node: Es un nodo m ovil que cambia su punto de conexi on de una
red o subred a otra. Puede cambiar su posici on sin cambiar su direcci on.
Puede comunicarse con otros nodos desde cualquier punto de conexi on
usando su direcci on IP.
Home Agent: Es un encaminador de la red original (home network) a la
que pertenece el mobile node, que se encarga de encaminar los paquetes
hacia el cuando este no se encuentra en su home network, porque mantiene
la informaci on de la posici on actual del mobile node
Foreign Agent: Es un encaminador de la red a la que se mueve el mobile
node, llamada visited network, que le proporciona servicios de encamina-
miento mientras este se est a registrando. El foreign agent recoge los da-
tagramas que enva por un t unel el home agent y se los entrega al mobile
node
En la gura 3.1 se muestra un ejemplo de una infraestructura creada para
el uso de Mobile IP.
El mobile node siempre posee una direcci on de su red original (home ad-
dress). Cuando est a fuera de su home network, una direcci on de la red que
visita le es asignada (care-of address) y reeja en cada momento el punto de
conexi on actual del mobile node. El mobile node usa su home address como la
direcci on origen de todos los datagramas que enva, excepto durante el proceso
de registro si tiene que adquirir una nueva direcci on.
54
Captulo 3. Movilidad Mobile IP
El protocolo Mobile IP se basa fundamentalmente en la realizaci on de las
siguientes funciones:
Agent discovery: home agents y foreign agents pueden advertir su dispo-
nibilidad por cada uno de los enlaces por los que prestan servicio. Y tam-
bien un mobile node puede mandar solicitar informaci on sobre los agentes
que existen.
Registro: Cuando el mobile node se encuentra fuera de su home network,
este registra su direcci on adquirida al home agent. Dependiendo del meto-
do de conexi on, se registrar a directamente con el home agent o lo har a a
traves del foreign agent.
T uneles: Para que los datagramas puedan ser entregados al mobile node
cuando este no se encuentra en su home network, el home agent debe
crear un t unel hacia su care-of address para enviarle todos los datagramas
dirigidos hacia el.
Con todos estos conceptos anteriores ya podemos describir el modo de fun-
cionamiento habitual de Mobile IP:
1. Los home agents y foreign agents advierten su presencia mediante envos
de mensajes de aviso. En cualquier caso, un mobile node puede solicitar
informaci on sobre los agentes disponibles mediante el envo de mensajes
de solicitud.
2. Un nodo m ovil recibe un mensaje de aviso, y comprueba si est a en su
home network o no.
3. Cuando un nodo m ovil detecta que se encuentra en su home network, este
funciona sin utilizar los servicios de movilidad. Si el nodo vuelve a su home
network desde otro punto de conexi on, des-registra su anterior posici on en
el home agent
4. Cuando un nodo m ovil detecta que se ha movido a una foreign network,
obtiene una care-of address de esa red.
5. El nodo m ovil, si se encuentra fuera de su home network, registra su nueva
care-of address en el home network para informar de su actual punto de
acceso a la red.
6. Todos los datagramas enviados a la home address del nodo en su home
network son interceptados por el home agent y enviados a traves de un
t unel. Estos datagramas son entregados en el otro extremo del t unel al
mobile node.
7. En el otro sentido, los datagramas pueden ser enviados por el mobile node
utilizando mecanismos de encaminamiento en IP tradicionales, sin necesi-
dad de su paso por el home agent.
55
Captulo 3. Movilidad Cellular IP
3.3. Cellular IP
3.3.1. Fundamentos de Cellular IP
Como hemos explicado en el apartado 3.2, las bases de los protocolos de
micro/macro movilidad son que los paquetes dirigidos a un nodo m ovil son
entregados usando encaminamiento IP tradicional hacia la direcci on asociada
a este nodo m ovil dependiendo del punto de conexi on a la red. Este enfoque
proporciona una soluci on simple y escalable para proporcionar una movilidad
global. Pero Mobile IP no es apropiado, para ofrecer soluciones en entornos en
los que el cambio de posici on de un nodo es muy r apido, ya que en cada cambio
el nodo debe obtener una direcci on de la foreign network y debe comunic arselo
a su, probablemente lejano, home agent.
Sin embargo, los sistemas de telefona tradicionales est an basados en un
concepto diferente al de Mobile IP. En lugar de ofrecer un servicio de movilidad
global, los sistemas telef onicos est an optimizados para ofrecer handos A r apidos
y suaves dentro de determinadas areas geogr acas restringidas.
Incluso en areas geogr acas reducidas, el n umero de usuario puede crecer
hasta un punto en el que hacer b usquedas sobre la situaci on actual de cada nodo
puede no ser viable. Adem as, la gesti on de la movilidad de Mobile IP requiere
que los nodos m oviles manden informaci on actualizada sobre su posici on a su
home agent cuando cambien de lugar, lo que signica una sobrecarga en el ancho
de banda en las redes inal ambricas. Para solucionar este problema, las redes de
telefona, lo que hacen es que los nodos m oviles solo se deben registrar despues
de un cambio de posici on cuando esten teniendo transferencias o comunicaciones
activas, en caso contrario, los nodos libres de comunicaciones mandan mensajes
de informaci on menos frecuentemente, con lo que pueden cambiar r apidamente
de situaci on sin sobrecargar el sistema de gesti on de la movilidad. De este modo,
la situaci on de estos nodos libres solo es conocida aproximadamente, y si se
necesita establecer una conexi on con el solo se debe realizar su b usqueda por un
limitado n umero de estaciones base.
Las redes de telefona ofrecen una serie de caractersticas que si fueran aplica-
das correctamente a las redes IP inal ambricas, podran aumentar enormemente
el rendimiento de estas redes sin perder la escalabilidad, exibilidad y robustez
que caracteriza a las redes IP. Pero la aplicaci on de estas caractersticas no es
trivial, porque hay diferencias estructurales fundamentales entre los dos tipos
de redes: los sistemas de telefona requieren un modelo de encaminamiento por
circuitos en los que debe crearse un camino de comunicaci on previo a realizarse
las comunicaciones, y las redes IP poseen encaminamiento basado en paquetes.
Por todo ello, es necesaria la utilizaci on de un protocolo como Cellular IP,
para adaptar las caractersticas de las redes de telefona a las redes IP inal ambri-
cas.
3.3.2. Descripci on del protocolo
Caractersticas
Cellular IP hereda los principios de los sistemas de telefona para gestionar
la movilidad, las conexiones pasivas y el control de hando, pero adaptado a las
redes IP.
56
Captulo 3. Movilidad Cellular IP
Host
Home
Agent
BS1
Internet
Gateway
BS3
BS4
BS2
Encaminamiento IP
Tnel sobre IP
Encaminamiento Cellular IP
Figura 3.2: Ejemplo de red Cellular IP
El componente b asico de una red Cellular IP es la Estaci on Base, el cu al
sirve de punto de conexi on a la red inal ambrica para los nodos pero tambien
encamina los paquetes IP e integra el control de la funcionalidad de movilidad
que proporciona el protocolo. Las estaciones base se basan en el encaminamiento,
pero reemplazan el encaminamiento IP por el encaminamiento Cellular IP y
gestionan la localizaci on de nodos.
Una red Cellular IP est a conectada a Internet mediante un Gateway, que
es otro de los componentes b asicos de estas redes.
La movilidad entre diferentes gateways, es decir, entre diferentes redes Ce-
llular IP es gestionada por Mobile IP, mientras que la movilidad dentro de las
areas de los gateways es gestionada por Cellular IP. Los nodos m oviles dentro
de las redes Cellular IP usan la direcci on del gateway como su direcci on care-of
address de Mobile IP.
En el caso general, los paquetes dirigidos al nodo m ovil son recogidos por por
el home agent, enviados a traves de un t unel hasta el gateway, y este los encamina
hacia las estaciones base. Dentro de las redes Cellular IP, los nodos m oviles
son identicados por su home address y los paquetes de datos son entregados
desde las estaciones base sin necesidad de t uneles ni conversi on de direcciones.
Los datos transmitidos desde el nodo m ovil primero son encaminados hasta el
gateway y despues hacia Internet. Se puede observar un ejemplo en la gura 3.2.
La gesti on de localizaci on y el soporte para handos est a integrado en el
encaminamiento. Para minimizar los mensajes de control, los paquetes de da-
tos normales transmitidos por los nodos m oviles son usados para establecer la
57
Captulo 3. Movilidad Cellular IP
localizaci on de los mismos. Los paquetes transferidos desde el nodo m ovil hasta
el gateway son encaminados paso a paso por las estaciones base, y estas apun-
tan en tablas cache el camino para llegar a estos nodos m oviles. Cuando llegan
paquetes hacia el nodo m ovil las estaci on base usan esa informaci on que tienen
guardada en las tablas cache para entregarle los paquetes.
Cuando un nodo m ovil no transmite datos durante un periodo de tiempo,
enva datagramas IP vacos al gateway para mantener activas las rutas en las
estaciones base. Cuando un nodo ha estado inactivo durante un largo periodo de
tiempo, las rutas hacia ese nodo son borradas de las tablas cache, y para poder
encaminar paquetes de nuevo hacia ese nodo hace falta usar un mecanismo
llamado paginaci on.
Encaminamiento
El gateway de una red Cellular IP peri odicamente enva mediante broadcast
mensajes para informar de su presencia. Las estaciones base, cuando reciben
estos mensajes, registran el interfaz por el que lo han recibido, y lo usan para
encaminar los paquetes hacia el. Todos los paquetes transmitidos desde los nodos
m oviles independientemente de su destino siempre son encaminados hacia el
gateway usando estas rutas.
Seg un van pasando estos paquetes por cada uno de los nodos intermedios ha-
cia el gateway, la informaci on de encaminamiento es almacenada de la siguiente
forma:
Cada estaci on base mantiene una tabla cache de encaminamiento
Cuando un paquete de datos originado por un nodo m ovil entra en una
estaci on base, esta almacena la direcci on IP del nodo m ovil y el interfaz
de red por el que le ha llegado el paquete.
Esta informaci on permanece v alida durante un periodo de tiempo (route-
timeout) y es actualizada cada vez que un paquete de datos entra por el
mismo interfaz con el mismo nodo m ovil de origen.
Hay veces en las que un nodo quiere que la informaci on de estas tablas
no sea borrada aunque se haya cumplido el periodo de tiempo m aximo,
como por ejemplo un nodo que sea receptor de una conexi on UDP en la
que el no enva paquetes de datos, solo los recibe. Para conseguir esto, el
nodo m ovil debe enviar paquetes de actualizaci on de rutas (route-update-
packets) cada cierto tiempo (route-update-time).
Hando
En Cellular IP existen dos algoritmos para la realizaci on de los handos:
hard hando : Este algoritmo se basa en un enfoque simple de la gesti on
de la movilidad para dar soporte a r apidos y sencillos handos, pero con
el precio de la potencial perdida de paquetes.
El hando es iniciado por el nodo m ovil.

Este recibe mensajes (beacons)
de las estaciones base, y realiza un hando en funci on de la intensidad
de la se nal de los mensajes que recibe de cada estaci on base. Cuando
58
Captulo 3. Movilidad Cellular IP
el nodo decide hacer un hando, se conecta a la nueva estaci on base y
le manda un paquete para actualizar las rutas (route-update).

Esto va
creando nuevas entradas en las tablas cache de las estaciones base hasta
toda la informaci on se ha actualizado. Durante el tiempo de latencia del
hando, los paquetes dirigidos al nodo pueden perderse porque hay rutas
que no est an actualizadas.
semisoft hando : Hay un periodo de tiempo en el que las rutas antiguas
no se han borrado, porque no ha expirado el periodo de tiempo necesario,
y durante este tiempo los datos son entregados desde las dos estaciones
base, la nueva y la antigua. Gracias a esta caracterstica este algoritmo
consigue mejorar el rendimiento de los handos.
Este algoritmo tiene dos partes:
Para reducir la latencia del hando, las nuevas rutas deben ser crea-
das antes de que se produzca el cambio real del nodo a la nueva
estaci on. Para ello, cuando el nodo m ovil inicia el hando, este man-
da un paquete (semisoft packet) a la nueva estaci on base y vuelve a
la antigua para seguir recibiendo paquetes. Mientras que contin ua co-
nectado a la antigua estaci on base, las rutas se van actualizando hacia
la nueva. Despues de que se han actualizado, ya puede cambiarse a
la nueva estaci on base.
Durante el tiempo que las dos estaciones envan los datos al nodo, es-
tos datos no est an sincronizados, y por tanto podra haber problemas
porque la estaci on nueva fuera m as r apida que la antigua, y entonces
perdera algunos paquetes al hacer el cambio real. Para solucionarlo,
el paquete que envi o el nodo por la nueva estaci on al comienzo del
hando, lo que hace es introducir un retardo en los paquetes que van
por esa nueva ruta. De esta forma, nos aseguramos que no se van
a perder paquetes, en todo caso podremos recibirlos repetidos, pero
eso no es problema.
Paginaci on
Un nodo inactivo en Cellular IP es aquel que no ha recibido paquetes de
datos durante un determinado periodo de tiempo (active-state-timeout), y des-
pues de cumplirse ese tiempo las entradas de ese nodo en las tablas cache de
encaminamiento de las estaciones base son borradas.
Estos nodos inactivos envan paquetes (paging-update) cada determinado
tiempo (paging-update-time) a la estaci on base de la que reciben una mejor
calidad de se nal. Estos paquetes son enviados hasta el gateway, y las estaciones
base pueden almacenar entradas con esta informaci on en las tablas cache de
paginaci on.
Una tabla cache de paginaci on tiene el mismo formato y funciones que una
tabla cache de encaminamiento, excepto por dos diferencias: el periodo de tiem-
po que permanecen las entradas en las tablas de paginaci on es mayor que en
las tablas de encaminamiento, y las entradas de las tablas de paginaci on son
actualizaci on con cualquier paquete que sea enviado por el nodo m ovil. Con
este modo de funcionamiento, tenemos que los nodos inactivos tienen entradas
en las tablas de paginaci on, pero no en las tablas de encaminamiento.
59
Captulo 3. Movilidad Cellular IP
La paginaci on ocurre cuando un paquete tiene que ser enviado a un nodo y
el gateway o las estaciones base no disponen de rutas de encaminamiento v alidas
hacia ese nodo:
Si la estaci on no tiene tabla cache de paginaci on, entonces reenva ese
paquete por todos sus interfaces de red, exceptuando por el que lo recibi o.
Si la estaci on base tiene tabla cache de paginaci on, entonces solo reenva
el paquete si el nodo tiene una entrada v alida en la tabla, y solo lo reenva
por el interfaz que est a en la entrada de la tabla.
Si no se usan tablas cache de paginaci on, el primer paquete con destino a
un nodo inactivo es enviado por toda la red mediante broadcast, lo que genera
una sobrecarga en la red. Si se usan tablas cache de paginaci on el n umero de
mensajes enviados se reduce.
Cuando un nodo inactivo recibe el paquete, cambia su estado a activo me-
diante el envo de un paquete de actualizaci on de rutas (route-update).
60
Captulo 3. Movilidad IPv4 vs IPv6
3.4. IPv4 vs IPv6
IPv6 es un protocolo que ha sido desarrollado por el IETF, y pretende ser el
reemplazo de la actual versi on del protocolo IP ( IPv4 ). De momento todava
no ha sido implantado como el protocolo a usar actualmente, pero est a previsto
que en un futuro cercano sea el protocolo del nivel de red usado por todas las
m aquinas en Internet.
Las principales restricciones que el protocolo IPv4 impone al actual creci-
miento de Internet son:
N umero limitado de direcciones IP, 2
32
Dicultad para manejar las tablas de encaminamiento
Pero IPv6 introduce muchas m as mejoras con respecto a IPv4, y soluciona
muchos problemas que existen en la actualidad. Y como no, en IPv6 el soporte
para la movilidad, que es el tema que nos interesa, es mucho m as util, y tambien
ha sido dise nado teniendo en cuenta estos objetivos.
Las principales diferencias entre Mobile IPv4 y Mobile IPv6 son:
Lo que se conoca en Mobile IPv4 como Route optimization ahora forma
parte del protocolo en Mobile IPv6. Esto signica que los paquetes dirigi-
dos desde el correspondent node hasta el nodo m ovil lo hacen directamente
y no tienen que pasar por el home agent y luego ser reenviados hasta el
nodo m ovil.
En este protocolo los paquetes que manda el nodo m ovil llevan como
direcci on origen la care-of address en la cabecera IP, y luego llevan una
opci on para el destino con la direcci on home address. Esto, a diferencia
de Mobile IPv4, hace que sea transparente para todos los encaminadores
y para las capas superiores.
El uso de la care-of address como la direcci on origen de los paquetes IP
simplica el encaminamiento de paquetes multicast enviados por el nodo
m ovil. En Mobile IPv4, el nodo m ovil tena que hacer un t unel hasta
su home agent para poder usar de forma transparente su home address
como direcci on origen de los paquetes multicast. En Mobile IPv6, con
la opci on de destino de la home address permite ser compatible con el
encaminamiento multicast, que en parte est a basado en la direcci on origen
del paquete.
Ya no hace falta tener encaminadores especiales que hagan de foreign agent
como en Mobile IPv4. Ahora, el nodo m ovil usa las caractersticas que le
proporciona IPv6, tales como auto-conguraci on de direcci on y neighbor
discovery.
La mayora de los paquetes que se envan a un nodo m ovil cuando no
est a en la home network se hace usando una cabecera de encaminamien-
to IPv6 (IPv6 Routing Header) en lugar de encapsulaci on de IP (como
en Mobile IPv4), y esto hace que se reduzcan los bytes necesarios en la
cabecera.
61
Captulo 3. Movilidad IPv4 vs IPv6
Cuando un nodo m ovil no est a en la home network, el home agent in-
tercepta cualquier paquete que se dirige hacia el nodo m ovil usando IPv6
Neighbor Discovery en lugar de ARP como en Mobile IPv4. Esto simplica
la implementaci on de Mobile IP al ser independiente de la capa de enlace,
cosa que no ocurre con ARP.
El mecanismo de descubrimiento de la direcci on del home agent din amica
en Mobile IPv6 usa IPv6 anycast y devuelve una sola respuesta al nodo
m ovil, al contrario de Mobile IPv4 que usaba mensajes de broadcast y una
respuesta de cada uno de los home agents. El mecanismo de Mobile IPv6
es m as eciente y m as seguro.
62
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv4
3.5. Practicas sobre protocolos de movilidad en
IPv4
En esta secci on se van a describir todos los detalles de las pruebas realizadas
sobre varias implementaciones de protocolos de micro/macro movilidad sobre
IPv4:
Implementaci on Dynamics de Mobile IPv4, de la Helsinki University of
Technology [HUT99]
Implementaci on de Cellular IPv4 desarrollada por la universidad de Co-
lumbia [Uni99]
Para las pruebas de estos protocolos se ha construido una maqueta de orde-
nadores, con un dise no de red especco para cada una de las pruebas. La parte
fundamental de la maqueta se basa en el esquema de la gura 3.3.
Proxy-ARP
Tarjeta
802.11b
Tarjeta
802.11b
Subred 1
Tarjeta
802.11b
Subred 2
Subred 3
Subred 4
Subred 5
Figura 3.3: Maqueta para pruebas de movilidad en IPv4
El objetivo de este esquema es poder tener el mayor n umero de subredes, con
el menor n umero de ordenadores. Tenemos 5 ordenadores, y tambien tenemos
5 subredes. Solamente 1 ordenador est a conectado directamente a Internet, y
hace de ProxyARP para que los dem as tambien puedan acceder.
Las direcciones IP que usamos para las subredes tienen la siguiente estruc-
tura: 29 bits para la direcci on de red, y 3 bits para la direcci on de m aquina. Por
tanto podemos tener 6 m aquinas en cada una de las subredes, lo que es m as que
suciente ..
3.5.1. Montaje de Mobile IPv4 en la maqueta
La implementaci on de Mobile IP utilizada para el montaje sobre la maqueta
es la de la universidad de Helsinki [HUT99].
63
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv4
Para la instalaci on de Mobile IP sobre la maqueta la conguramos de la
siguiente manera:
Tenemos las 5 subredes:
Subred 1: [Link] / [Link]
Subred 2: [Link] / [Link]
Subred 3: [Link] / [Link]
Subred 4: [Link] / [Link]
Subred 5: [Link] / [Link]
Tenemos un nodo m ovil, con direcci on [Link], tiene una tarjeta inal ambri-
ca 802.11b mediante la que se conecta a los foreign agents (FA3, FA4 y FA2)
que tambien tienen tarjetas 802.11b, y todas ellas est an conguradas de modo
Ad-Hoc.
El nodo m ovil se va moviendo por las subredes, y va cambiando de foreign
agent sin cambiar su direcci on IP, ya que usamos foreign agent encapsulation.
De este modo los paquetes que van desde el correspondent node al nodo m ovil
pasan por el home agent, que encapsula los paquetes y se los enva al foreign
agent mediante un t unel, y despues es el foreign agent el que des-encapsula el
paquete y se lo entrega al nodo m ovil.
Con la maqueta que tenemos tambien hacemos uso de los foreign agents
jer arquicos. Esto ocurre entre el FA1 y los FA3 y FA4. Esto proporciona cambios
de subred para el nodo m ovil m as r apidos, ya que el t unel que tiene el home
agent siempre lo tiene con el FA1, y despues dependiendo de si el nodo m ovil
est a en el FA3 o el FA4, existir a otro t unel entre el FA1 y el FA3, o entre el FA1
y el FA4. Por eso cuando el nodo m ovil cambia por ejemplo del FA3 al FA4, lo
unico que cambia es que el t unel entre FA1-FA3 se elimina y se crea otro entre
FA1-FA4.
Proxy-ARP
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
FA1 FA2
FA4 FA3
HA
[Link]
Nodo mvil
[Link]
Figura 3.4: Dise no de red para pruebas de Mobile IPv4
64
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv4
En el caso de no usar foreign agents jer arquicos, como por ejemplo al cambiar
del FA3 al FA2, el establecimiento de conexi on del nodo m ovil tiene un mayor
retardo, ya que se debe establecer un t unel entre el home agent y el FA2 y eso
es m as lento que el caso que se comentaba antes.
3.5.2. Montaje de Cellular IPv4 en la maqueta
La implementaci on de Cellular IP utilizada es la de la Universidad de Co-
lumbia [Uni99].
La conguraci on de la maqueta para el uso de Cellular IP es que se muestra
en la gura 3.5.
Proxy-ARP
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
[Link]/
[Link]
Gateway Cellular IP
Estacin base 2 Estacin base 1
Nodo mvil
[Link]
Figura 3.5: Dise no de red para pruebas de Cellular IPv4
Con Cellular IP, el nodo m ovil pertenece a las subredes de las estaciones
base para poder conectarse a ellos.
En este caso el nodo m ovil tiene una tarjeta inal ambrica, al igual que las
estaciones base. Todas estas tarjetas est an conguradas en modo ad-hoc.
Con Cellular IP, en todo momento el gateway sabe a que estaci on base
est a conectado el nodo m ovil, y lo que hace es encaminar los paquetes des-
de/hacia el nodo m ovil por la estaci on base adecuada en cada momento.
Los cambios de estaci on base son m as r apidos que los cambios de foreign
agent en Mobile IP, ya que aqu solo hay que cambiar una ruta en el gateway de
CellularIP y no hace falta establecer t uneles ni encapsular paquetes que luego
hay que des-encapsular.
65
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
3.6. Medida de prestaciones de Mobile IPv4
Una vez que tenemos instalada la implementaci on de Mobile IPv4 sobre la
maqueta como comentamos en la secci on 3.5.1, hemos realizado unas pruebas
para medir el rendimiento de la implementaci on utilizada.
Hemos realizado dos tipos de pruebas, que describimos en las siguientes
secciones, as como las herramientas utilizadas.
3.6.1. Herramientas utilizadas para las pruebas de Mobile
IPv4
Las pruebas sobre Mobile IP en la maqueta se han realizado con algunas
herramientas existentes para este n, y otras herramientas implementadas para
algunas pruebas. Para automatizar las pruebas se han realizado scripts en perl.
En estos scripts se dene el tipo de pruebas, se lanza el proceso, y se generan
algunos cheros con los resultados.
B asicamente existe un scripts principal en el que se dene el tipo de prue-
bas, la duraci on, el n umero de repeticiones, el programa utilizado para realizar
la medici on, ... Y luego existen tantos scripts como herramientas de medici on
existen, en el que se indica la forma de ejecutar el programa de medici on, y la
forma de recoger sus resultados. Los programas utilizados para las mediciones
son netperf, y una implementaci on de un programa cliente/servidor que b asica-
mente consiste en la medida de los paquetes que se pierden en una transferencia
de paquetes entre el cliente/servidor.
3.6.2. Pruebas ancho de banda en Mobile IPv4
Estas pruebas realizadas consisten en medir el ancho de banda que se con-
sigue entre el nodo m ovil (MN) y el Correspondent Node (CN), sobre distintos
escenarios.
Para las pruebas se ha utilizado la herramienta netperf. Esta herramienta
consiste en un modelo cliente/servidor, ejecutamos el servidor en el CN y el
cliente en el MN. Durante el tiempo que dura cada prueba este programa realiza
una transferencia entre ambos y mide el ancho de banda que se consigue...
Para la automatizaci on de las pruebas se han construido unos scripts en perl,
que realizan todas las pruebas que se le indiquen durante el tiempo que se le
indique.
Las pruebas con netperf consisten en medir el ancho de banda conseguido
entre ambos nodos, cuando el n umero de handos del MN vara. Se han tomado
medidas cuando el MN no hace handos, y tambien se han hecho medidas
cuando el MN hace unos handos de 8, 5, 4, 3 y 2 segundos. Los handos
consisten en que el MN va cambiando de FA al que se conecta.
Tambien se han hecho pruebas utilizando FA jer arquicos y sin utilizarlos
para comprobar cual es la mejora que proporcionan los FA jer arquicos, en el
que el t unel entre el HA y el FA superior no vara.
Tambien se ha utilizado el programa nistnet, que sirve para variar el com-
portamiento de ciertos paquetes en la red. Por ejemplo para nuestras pruebas
hemos hecho que el nistnet retrase todos los paquetes desde/hacia el HA 1 se-
gundo, para simular cual sera la situaci on en la que el HA se encontrara lejos
del MN.
66
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Resultados con FA jerarquicos
Sobre TCP
Ancho de banda:
Handos (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 3.20125 2.9025 3.06625 3.13875 2.8025
1
1.5
2
2.5
3
3.5
4
2 3 4 5 6 7 8
A
n
c
h
o
d
e
b
a
n
d
a
(M
b
/s
e
g
)
Tiempo de Handoff (seg)
Tuneles Jerarquicos - TCP
Ancho de banda alejando al HA:
Handos (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 0.8875 0.83 0.7325 0.5875 0.19
0
0.5
1
1.5
2
2.5
3
3.5
4
2 3 4 5 6 7 8
A
n
c
h
o
d
e
b
a
n
d
a
(M
b
/s
e
g
)
Tiempo de Handoff (seg)
Tuneles Jerarquicos - TCP - HA alejado
Sobre UDP
Ancho de banda:
Handos (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.5325 2.56 2.65125 2.665 2.7
1
1.5
2
2.5
3
3.5
4
2 3 4 5 6 7 8
A
n
c
h
o
d
e
b
a
n
d
a
(M
b
/s
e
g
)
Tiempo de Handoff (seg)
Tuneles Jerarquicos - UDP
67
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Ancho de banda alejando al HA:
Handos (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 3.23 3.195 3.1825 3.15 2.89
1
1.5
2
2.5
3
3.5
4
2 3 4 5 6 7 8
A
n
c
h
o
d
e
b
a
n
d
a
(M
b
/s
e
g
)
Tiempo de Handoff (seg)
Tuneles Jerarquicos - UDP - HA alejado
Resultados sin FA jerarquicos
Sobre TCP
Ancho de banda:
Handos (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.40125 2.20125 2.50875 2.65625 2.7675
1
1.5
2
2.5
3
3.5
4
2 3 4 5 6 7 8
A
n
c
h
o
d
e
b
a
n
d
a
(M
b
/s
e
g
)
Tiempo de Handoff (seg)
Tuneles No Jerarquicos - TCP
Ancho de banda alejando al HA:
Handos (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 0.1525 0.0575 0.03 0.0275 0.1075
0
0.5
1
1.5
2
2.5
3
3.5
4
2 3 4 5 6 7 8
A
n
c
h
o
d
e
b
a
n
d
a
(M
b
/s
e
g
)
Tiempo de Handoff (seg)
Tuneles No Jerarquicos - TCP - HA alejado
68
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Sobre UDP
Ancho de banda:
Handos (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.595 2.683 2.73625 2.5475 2.5537
1
1.5
2
2.5
3
3.5
4
2 3 4 5 6 7 8
A
n
c
h
o
d
e
b
a
n
d
a
(M
b
/s
e
g
)
Tiempo de Handoff (seg)
Tuneles No Jerarquicos - TCP
Ancho de banda alejando al HA:
Handos (seg.) 10 5 4 3 2
Ancho de banda (Mb/seg) 2.69 2.455 2.3875 2.4175 2.32
1
1.5
2
2.5
3
3.5
4
2 3 4 5 6 7 8
A
n
c
h
o
d
e
b
a
n
d
a
(M
b
/s
e
g
)
Tiempo de Handoff (seg)
Tuneles No Jerarquicos - TCP - HA alejado
3.6.3. Pruebas perdida de paquetes UDP en Mobile IP
Otro tipo de pruebas realizado consiste en medir el n umero de paquetes que
se pierden entre el MN y el CN, con diferentes par ametros de conguraci on de
la maqueta.
Para las pruebas de perdida de paquetes se han realizado unos simples pro-
gramas en Ada, utilizando la librera de comunicaciones Lower Layer, que consis-
ten en un modelo cliente/servidor en el que se envan paquetes UDP de distinto
tama no, y se mide el n umero de paquetes perdidos.
En las pruebas de perdidas de paquetes el metodo es el mismo pero se han
realizado con tiempos de handos de 15, 12, 10, 8, 6, 5, 4, 3 y 2 segundos.
Tambien se han usado FA jer arquicos y FA no jer arquicos, y tambien se ha
utilizado la herramienta nistnet para alejar al HA.
69
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Resultados con FA jerarquicos
Con tama no de paquete de 32 bytes
Perdida de paquetes:
Handos (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos ( %) 0 0 2 2 2 2 4 2 7
0
20
40
60
80
100
2 4 6 8 10 12 14
%
d
e
p
a
q
u
e
te
s
p
e
rd
id
o
s
Tiempo de Handoff (seg)
Tuneles Jerarquicos -UDP (32b)
Muestra de los mensajes que se pierden en el tiempo que duran las pruebas
con alguno de los handos:
Con handos de 15 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 1000 2000 3000 4000 5000 6000 7000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles Jerarquicos - UDP (Paquete: 32b, Handoff: 15 seg)
Con handos de 5 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 1000 2000 3000 4000 5000 6000 7000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles Jerarquicos - UDP (Paquete: 32b, Handoff: 5 seg)
70
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Perdida de paquetes alejando al HA:
Handos (seg.) 15 12 10 8 6 5
Paquetes perdidos ( %) 17 26 26 33 42 54
0
20
40
60
80
100
6 8 10 12 14
%
d
e
p
a
q
u
e
te
s
p
e
rd
id
o
s
Tiempo de Handoff (seg)
Tuneles Jerarquicos - UDP (32b)- HA alejado
Muestra de los mensajes que se pierden en el tiempo que duran las pruebas
con alguno de los handos:
Con handos de 15 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 1000 2000 3000 4000 5000 6000 7000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles Jerarquicos - UDP (Paquete: 32b, Handoff: 15 seg) - HA alejado
Con handos de 5 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 1000 2000 3000 4000 5000 6000 7000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles Jerarquicos - UDP (Paquete: 32b, Handoff: 5 seg) - HA alejado
71
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Con tama no de paquete de 512 bytes
Perdida de paquetes:
Handos (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos ( %) 0 0 7 7 5 2 5 7 1
0
20
40
60
80
100
2 4 6 8 10 12 14
%
d
e
p
a
q
u
e
te
s
p
e
rd
id
o
s
Tiempo de Handoff (seg)
Tuneles Jerarquicos - UDP (512b)
Muestra de los mensajes que se pierden en el tiempo que duran las pruebas
con alguno de los handos:
Con handos de 15 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 500 1000 1500 2000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles Jerarquicos - UDP (Paquete: 512b, Handoff: 15 seg)
Con handos de 5 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 500 1000 1500 2000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles Jerarquicos - UDP (Paquete: 512b, Handoff: 5 seg)
72
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Perdida de paquetes alejando al HA:
Handos (seg.) 15 12 10 8 6 5
Paquetes perdidos ( %) 3 3 2 7 4 6
0
20
40
60
80
100
6 8 10 12 14
%
d
e
p
a
q
u
e
te
s
p
e
rd
id
o
s
Tiempo de Handoff (seg)
Tuneles Jerarquicos - UDP (512b) - HA alejado
Muestra de los mensajes que se pierden en el tiempo que duran las pruebas
con alguno de los handos:
Con handos de 15 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 500 1000 1500 2000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles Jerarquicos - UDP (Paquete: 512b, Handoff: 15 seg) - HA alejado
Con handos de 5 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 500 1000 1500 2000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles Jerarquicos - UDP (Paquete: 512b, Handoff: 5 seg) - HA alejado
73
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Resultados sin FA jerarquicos
Con tama no de paquete de 32 bytes
Perdida de paquetes:
Handos (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos ( %) 12 16 20 24 29 26 11 3 4
0
20
40
60
80
100
2 4 6 8 10 12 14
%
d
e
p
a
q
u
e
te
s
p
e
rd
id
o
s
Tiempo de Handoff (seg)
Tuneles No Jerarquicos -UDP (32b)
Muestra de los mensajes que se pierden en el tiempo que duran las pruebas
con alguno de los handos:
Con handos de 15 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 1000 2000 3000 4000 5000 6000 7000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles No Jerarquicos - UDP (Paquete: 32b, Handoff: 15 seg)
Con handos de 5 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 1000 2000 3000 4000 5000 6000 7000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles No Jerarquicos - UDP (Paquete: 32b, Handoff: 5 seg)
74
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Perdida de paquetes alejando al HA:
Handos (seg.) 15 12 10 8 6 5
Paquetes perdidos ( %) 31 46 57 73 83 83
0
20
40
60
80
100
6 8 10 12 14
%
d
e
p
a
q
u
e
te
s
p
e
rd
id
o
s
Tiempo de Handoff (seg)
Tuneles No Jerarquicos - UDP (32b) - HA alejado
Muestra de los mensajes que se pierden en el tiempo que duran las pruebas
con alguno de los handos:
Con handos de 15 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 1000 2000 3000 4000 5000 6000 7000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles No Jerarquicos - UDP (Paquete: 32b, Handoff: 15 seg) - HA alejado
Con handos de 5 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 1000 2000 3000 4000 5000 6000 7000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles No Jerarquicos - UDP (Paquete: 32b, Handoff: 5 seg) - HA alejado
75
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Con tama no de paquete de 512 bytes
Perdida de paquetes:
Handos (seg.) 15 12 10 8 6 5 4 3 2
Paquetes perdidos ( %) 14 17 19 23 26 31 25 11 4
0
20
40
60
80
100
2 4 6 8 10 12 14
%
d
e
p
a
q
u
e
te
s
p
e
rd
id
o
s
Tiempo de Handoff (seg)
Tuneles No Jerarquicos - UDP (512b)
Muestra de los mensajes que se pierden en el tiempo que duran las pruebas
con alguno de los handos:
Con handos de 15 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 500 1000 1500 2000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles No Jerarquicos - UDP (Paquete: 512b, Handoff: 15 seg)
Con handos de 5 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 500 1000 1500 2000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles No Jerarquicos - UDP (Paquete: 512b, Handoff: 5 seg)
76
Captulo 3. Movilidad Medida de prestaciones de Mobile IPv4
Perdida de paquetes alejando al HA:
Handos (seg.) 15 12 10 8 6 5
Paquetes perdidos ( %) 24 29 36 39 41 52
0
20
40
60
80
100
6 8 10 12 14
%
d
e
p
a
q
u
e
te
s
p
e
rd
id
o
s
Tiempo de Handoff (seg)
Tuneles No Jerarquicos - UDP (512b) - HA alejado
Muestra de los mensajes que se pierden en el tiempo que duran las pruebas
con alguno de los handos:
Con handos de 15 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 500 1000 1500 2000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles No Jerarquicos - UDP (Paquete: 512b, Handoff: 15 seg) - HA alejado
Con handos de 5 segundos:
-0.2
0
0.2
0.4
0.6
0.8
1
1.2
0 500 1000 1500 2000
P
a
q
u
e
te
: 1
->
re
c
ib
id
o
, 0
->
p
e
rd
id
o
Nmero de paquete
Tuneles No Jerarquicos - UDP (Paquete: 512b, Handoff: 5 seg) - HA alejado
77
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv6
3.7. Practicas sobre protocolos de movilidad en
IPv6
En esta secci on se van a describir todos los detalles de las pruebas realizadas
sobre varias implementaciones de protocolos de micro/macro movilidad sobre
IPv6:
Implementaci on MIPL de Mobile IPv6, de la Helsinki University of Tech-
nology [TL00]
Implementaci on de Cellular IPv6 desarrollada por Sanghyo Kim y Javier
Gomez [SK01]
Para las pruebas de estos protocolos se ha construido una maqueta de orde-
nadores, con un dise no de red especco para cada una de las pruebas.
B asicamente la maqueta 3.6 consiste en un conjunto de ordenadores a los que
se conecta el nodo m ovil dependiendo de su localizaci on actual, y el objetivo es
que este nodo pueda seguir teniendo conectividad independientemente del nodo
al que se conecte y de manera transparente para el usuario.
Internet
Home Agent
Nodo mvil
Correspondent
Node
Figura 3.6: Maqueta para pruebas de movilidad en IPv6
Para la comunicaci on entre el nodo m ovil y los nodos a los que se conecta
se utiliza tecnologa wireless con tarjetas inal ambricas 802.11b.
Primero detallare el proceso de montaje de la maqueta para que funcione
en IPv6, y despues explicare la instalaci on de las implementaciones de Mobile
IPv6 y Cellular IPv6.
3.7.1. Montaje de la maqueta con IPv6
La maqueta consta de unos cuantos ordenadores de sobremesa (7), y un
port atil que actuar a como nodo m ovil. Todas estas m aquinas tienen sistema
operativo Debian GNU/Linux (woody) con kernel 2.4.7.
78
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv6
Algunas de estas m aquinas (nodo m ovil y nodos a los que se conecta) est an
provistas de tarjetas wireless 802.11b para darle mayor libertad de movimiento
al nodo m ovil. Todas estas tarjetas son PCMCIA, y en el caso de los ordenadores
de sobremesa poseen un bridge PCI-PCMCIA para poder utilizarlas.
Conguraci on del kernel con soporte para IPv6
A partir de la versi on 2.2.19, el kernel de Linux incorpora soporte para
IPv6. Con las series 2.4, se empiezan a incorporar nuevas funcionalidades hasta
alcanzar el estado actual del m odulo IPv6 del kernel, en estado experimental.
Entre las caractersticas que proporciona el m odulo est an:
Espacio de direcciones ampliado
Mecanismos de autenticaci on y privacidad
Interoperabilidad con IPv4
Para tener soporte para IPv6 y para la posterior instalaci on de las imple-
mentaci on de los protocolos de movilidad necesitamos tener compilado un kernel
que nos facilite los siguientes m odulos:
Packet socket (Y)
Kernel/User netlink socket (Y)
Routing messages (Y)
Networking packet ltering (replace ipchains) (Y)
Socket ltering (Y)
Unix domain sockets (Y)
TCP/IP networking (Y)
IP: multicasting (Y)
IP: advanced router (Y)
IP: policy routing (Y)
IP: tunneling (Y)
The IPv6 protocolo (EXPERIMENTAL) (m)
Conguraci on de las tarjetas PCMCIA 802.11b
Las tarjetas utilizadas en la maqueta son varias Lucent Technologies, y algu-
nas Compaq pero que tambien tienen el chip de Lucent. Se utilizar an en modo
ad-hoc (secci on 2.8) porque no disponemos de Puntos de Acceso y necesitamos
que las tarjetas puedan comunicarse entre ellas directamente.
La conguraci on de las tarjetas se realiza como se detalla en la secci on 2.4.4,
m as las siguientes modicaciones que se realizan para congurar el modo de
funcionamiento por defecto.
79
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv6
Para congurar las tarjetas en modo Ad-Hoc necesitamos editar el chero
/etc/pcmcia/[Link], en ese chero hay varios apartados para congurar
la tarjeta dependiendo del modelo (en realidad depende de la direcci on MAC),
y el que nos interesa a nosotros es el siguiente:
# Lucent Wavelan IEEE
# Note : wvlan_cs driver only, and version 1.0.4+ for encryption support
# Nota: Anado la ultima direccion MAC para las Compaq
*,*,*,[Link]*|*,*,*,[Link]*|*,*,*,[Link]*)
INFO="Wavelan IEEE example (Lucent default settings)"
ESSID="MINIRED"
MODE="Ad-Hoc"
RATE="auto"
Dise no de la maqueta
Para la construcci on de la maqueta necesitamos denir las subredes que
queremos crear, los prejos de red que vamos a usar, las direcciones de cada
subred ...
Con la maqueta que hemos dise nado tenemos 6 subredes distintas 3.7, lo que
nos permitir a posteriormente bastantes posibilidades para desarrollar nuestras
pruebas:
Subred 1
Subred 2
Subred 3
Subred 4
Subred 5
Subred 6
Internet
Figura 3.7: Dise no de red de la maqueta IPv6
Y les asignamos las siguientes direcciones de red a cada una de ellas:
Subred 1: [Link]/64
Subred 2: [Link]/64
Subred 3: [Link]/64
Subred 4: [Link]/64
Subred 5: [Link]/64
80
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv6
Subred 6: [Link]/64
Conguraci on de las direcciones IPv6
Cada una de las m aquinas de la maqueta (excepto el nodo m ovil) tiene varias
interfaces de red, uno de ellos le conecta con la parte superior del arbol y otra
interfaz con las m aquinas que hay por debajo. Gracias a esta estructura hemos
denido las direcciones de la siguiente forma:
Interfaz superior (la que le conecta al nodo padre): Adquiere la direcci on
IPv6 que le asigna el padre mediante radvd.
Interfaz inferior: Tiene una direcci on IPv6 ja, y tiene funcionando radvd
para asignar direcciones a las m aquinas que se conecten a esa subred.
El radvd (Router advertisment) es un demonio que informa a los nodos que
se conectan a la subred cu al es la direcci on de esa subred, y cu al es su prejo.
Un ejemplo de un mensaje que manda el radvd es el siguiente:
Router advertisement from fe80::250:4ff:fe47:d29a (hoplimit 255)
AdvCurHopLimit: 64
AdvManagedFlag: off
AdvOtherConfigFlag: off
AdvHomeAgentFlag: off
AdvReachableTime: 0
AdvRetransTimer: 0
Prefix [Link]/64
AdvValidLifetime: 2592000
AdvPreferredLifetime: 604800
AdvOnLink: on
AdvAutonomous: on
AdvRouterAddr: off
AdvSourceLLAddress: 00 50 04 47 D2 9A
Este mensaje nos indica que lo est a mandando una m aquina con direcci on
fe80::250:4:fe47:d29a y que est a avisando de que la subred tiene una direcci on
de tipo: [Link]/64. Y el chero de conguraci on del radvd en /etc/[Link]
para que mande ese tipo de mensajes sera el siguiente:
interface eth0
{
AdvSendAdvert on;
MaxRtrAdvInterval 10;
#AdvSourceLLAddress off;
prefix [Link]/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
Cuando una m aquina que se conecta a esa subred recibe un mensaje de
ese tipo se congura autom aticamente una direcci on adecuada para esa subred.
Y para ello lo que hace es coger la parte de direcci on de red que recibe y
81
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv6
despues le adjunta la direcci on MAC de su tarjeta. Por ejemplo una m aquina
con direcci on MAC [Link] obtiene la siguiente direcci on en esa
subred: fec0::1:250:da:fe4f:a787.
La conguraci on de las direcciones de red que queremos poner jas se indican
en el chero /etc/network/interfaces, y la estructura que tienen las m aquina de
la maqueta es la siguiente (ejemplo en la subred 4):
iface eth2 inet6 static
address fec0::5:202:a5ff:fe6e:5209
netmask 64
Conguraci on de las rutas IPv6
Para la conguraci on de las rutas he utilizado un scripts que se ejecuta en el
arranque en el que le indicamos todas las rutas IPv6 que tiene cada m aquina.
La forma de indicar las rutas en IPv6 es similar a como se hace en IPv4. Un
ejemplo:
route add -A inet6 [Link]/64 gw
fec0::2:2e0:4cff:fe39:146b dev eth1
3.7.2. Instalaci on de la implementaci on de Mobile IPv6
El primer paso es bajarse las fuentes del kernel y dejarlas en un lugar habitual
para compilarlo posteriormente.
A continuaci on hay que descargarse la versi on de Mobile IPv6 de la imple-
mentaci on que estamos usando [TL00], dependiendo de la versi on del kernel que
nos hayamos bajado anteriormente (2.4.7). Este software descargado contiene
un parche que hay que aplicar a los fuentes del kernel. Para ello se copia el
parche ([Link]) al directorio donde est an esos fuentes y se
aplica el parche de la siguiente forma:
# patch -p1 < [Link]
Con esto ya est an modicados los fuentes del kernel para soportar Mobile
IPv6, y lo que hay que hacer despues es compilar las fuentes del kernel con
soporte para los siguientes m odulos:
IPv6: Mobility Support (EXPERIMENTAL) (m)
MIPv6: Debug Messages (m)
Compilamos el kernel, y lo instalamos de la manera habitual en la distribu-
ci on que usamos con la herramienta make-kpkg.
Despues de esto lo unico que falta es crear un dispositivo que necesita la
implementaci on de Mobile IPv6:
# mknod /dev/mipv6_dev c 0xf9 0
82
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv6
Conguraci on de la maqueta para Mobile IPv6
En cada uno de los nodos que realizan funciones de Mobile IP ( nodo m ovil,
home agent y foreign agents) debemos tener instalados correctamente el m odulo
de Mobile IPv6. Para la conguraci on de dicho m odulo existen varios cheros
de conguraci on:
/etc/syscong/[Link]: Fichero principal de conguraci on
/etc/mipv6 [Link]: Lista de control de acceso de nodos m oviles.
/etc/mipv6 [Link]: Seguridad de Mobile IPv6.
La conguraci on de cada unos de los nodos sera la siguiente:
Nodo m ovil. El chero /etc/syscong/[Link] contiene lo si-
guiente:
# MIPL Mobile IPv6 Configuration file
FUNCTIONALITY=mn
DEBUGLEVEL=7
# TUNNEL_SITELOCAL=yes
HOMEADDRESS=fec0::1:260:1dff:fef1:2be8/64
HOMEAGENT=fec0::1:250:4ff:fe47:d29a
# MOBILENODEFILE=/etc/mipv6_acl.conf
RTR_SOLICITATION_INTERVAL=1
RTR_SOLICITATION_MAX_SENDTIME=5
Home Agent. El chero /etc/syscong/[Link] contiene lo
siguiente:
# MIPL Mobile IPv6 Configuration file
FUNCTIONALITY=ha
DEBUGLEVEL=1
TUNNEL_SITELOCAL=yes
# HOMEADDRESS=fec0::1:260:1dff:fef1:2be8
# HOMEAGENT=fec0::1:250:4ff:fe47:d29a
MOBILENODEFILE=/etc/mipv6_acl.conf
# RTR_SOLICITATION_INTERVAL=1
# RTR_SOLICITATION_MAX_SENDTIME=5
Y el chero /etc/syscong/mipv6 [Link] :
ALLOW fec0::1:260:1dff:fef1:2be8/64
Correspondent Node. El chero /etc/syscong/[Link] con-
tiene:
# MIPL Mobile IPv6 Configuration file
FUNCTIONALITY=cn
83
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv6
DEBUGLEVEL=2
# TUNNEL_SITELOCAL=yes
# Home address for mobile node with prefix length. Example:
# HOMEADDRESS=[Link]
# HOMEAGENT=[Link]
# MOBILENODEFILE=/etc/mipv6_acl.conf
# MD5KEY=
# SHA1KEY=
# RTR_SOLICITATION_INTERVAL=1
# RTR_SOLICITATION_MAX_SENDTIME=5
Aparte de estos elementos necesitamos que los encaminadores de las subredes
a las que se conecte el nodo m ovil dispongan de un radvd ejecutando, como se
explic o en la secci on 3.7.1.
Funcionamiento de Mobile IPv6 en la maqueta
Una vez congurados todos los nodos, solamente debemos activar los m odu-
los de Mobile IPv6. Para ello en cada una de las m aquinas (nodo m ovil, home
agent y correspondent node) debemos hacer lo siguiente:
/etc/init.d/mobile-ip6 start
Y con esto ya estar an los nodos preparados para empezar a funcionar.
Si el nodo m ovil se encuentra en la home network el funcionamiento de
este ser a el normal, podr a enviar y recibir paquetes como si fuera un nodo
convencional.
Cuando el nodo m ovil no se encuentra en la home network lo primero que
hace es adquirir una nueva direcci on de la subred a la que se conecta (care-
of address). Despues de esto necesita que su home agent conozca esa nueva
direcci on, y para ello le manda un binding registration (paquete con opci on para
el destino Binding Update), y el home agent le responde con una paquete con
opci on para el destino binding acknowledgement. A partir de ese momento esa
nueva direcci on ser a la primary care-of address, y el home agent interceptar a los
paquetes dirigidos hacia el nodo m ovil mediante proxy Neighbor Discovery, y se
los enviar a mediante IPv6 encapsulation. Cada vez que el nodo m ovil se cambie
de subred mandar a al home agent un binding update.
Podemos probar a conectar el nodo m ovil a cualquiera de las subredes que
tenemos y veremos que va adquiriendo nuevas direcciones y puede seguir co-
munic andose con el correspondent node mediante alg un programa que tenga
soporte para IPv6 (ssh, ping6, ...).
3.7.3. Instalaci on de la implementaci on de Cellular IPv6
La instalaci on de Cellular IPv6 es m as sencilla que la de Mobile IPv6. La
maqueta sobre la que se puede probar esta implementaci on debe tener una
estructura jer arquica como la que se muestra en la gura 3.8
Los requerimientos del sistema son los siguientes:
Kernel a partir de 2.2.12. Nosotros hemos utilizado el 2.4.7.
Tener instalado el paquete iproute.
Tener instaladas las libreras libpcap con soporte ipv6.
84
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv6
G1 G3
G2
BS1 BS3
BS2 BS4 BS6 BS5 BS7 BS9 BS8
Figura 3.8: Maqueta jer arquica para pruebas sobre Cellular IPv6
Se pueden usar tarjetas wireless que soporten funciones SPY, para medir
la calidad de la se nal.
Lo primero que hay que hacer es bajarse la implementaci on que vamos a
usar [SK01].
La instalaci on es muy sencilla. Primero se descomprimen los fuentes. Una
vez descomprimidos los fuentes vemos que se crean dos directorios: cipmobile6
y cipnode6. En el primero de ellos est a el c odigo que se ejecutar a en el nodo
m ovil y en el segundo est a el c odigo que se ejecutar a en todos los dem as nodos,
estaciones base y gateway. Despues entramos en el directorio correspondiente,
ejecutamos: make y ya se compilar an los fuentes necesarios.
Conguraci on de los nodos
La conguraci on de los nodos es la siguiente:
En el nodo m ovil:
La conguraci on del nodo m ovil se especica en el chero [Link],
en este chero se especica la interfaz que usa el nodo m ovil y algunos
par ametros de tiempo. En nuestro caso:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
wireless interface= eth0
air interface name= wavelan
route-update-time= 3000 %in milliseconds
paging-update-time= 30000 %in milliseconds
active-state-timeout= 9000 %in milliseconds
handoff= 1 %forced (=0) or SNR based (=1)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
En las estaciones base:
85
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv6
La conguraci on de las estaciones base se especica en el chero cipno-
[Link]. La conguraci on de las estaciones base de la maqueta es la si-
guiente:
Estaci on base 1
GW: NO
IF YES, default routers IP address: \%(wire, eth0, [Link])
IF NO, neighbor, uplink direction: (wire, eth0, fec0::3:2e0:4cff:fe69:15bd)
leaf neighbours(s): (wireless, eth2)
paging cache: YES
route-timeout: 1000 \%in milliseconds
paging-timeout: 60000 \%in milliseconds
max number of mobiles in cache: 100
max number of node interfaces: 10
Base Station ID: 1
Paging Area ID: 1
CIP Network ID: 1
Estaci on base 2
GW: NO
IF YES, default routers IP address:
IF NO, neighbor, uplink direction: (wire, eth0, fec0::3:2e0:4cff:fe69:15bd)
leaf neighbours(s): (wireless, eth1)
paging cache: YES
route-timeout: 1000 \%in milliseconds
paging-timeout: 60000 \%in milliseconds
max number of mobiles in cache: 100
max number of node interfaces: 10
Base Station ID: 2
Paging Area ID: 1
CIP Network ID: 1
En el gateway:
La conguraci on del gateway se especica en el chero [Link] :
GW: YES
IF YES, default routers IP address: (wire, eth0,fec0::2:2a0:24ff:feaa:c3b2)
IF NO, neighbor, uplink direction:
leaf neighbours(s): (wire, eth1, fec0::3:2e0:4cff:fe69:2d78)
(wire, eth1, fec0::3:2e0:4cff:fe49:1bcc)
paging cache: YES
route-timeout: 1000 %in milliseconds
paging-timeout: 60000 %in milliseconds
max number of mobiles in cache: 100
max number of node interfaces: 10
Base Station ID:
Paging Area ID: 1
CIP Network ID: 1
Funcionamiento de Cellular IPv6 en la maqueta
Como hemos dicho anteriormente, Cellular IP es un protocolo de micro-
movilidad, por lo tanto debera ir acompa nado de un protocolo de macro-
86
Captulo 3. Movilidad Pr acticas sobre protocolos de movilidad en IPv6
movilidad como Mobile IP. Por tanto en nuestra maqueta se usa Mobile IPv6
junto con Cellular IPv6, pero para su correcto funcionamiento deberan intero-
perar perfectamente y las implementaciones que estamos probando de ambos
protocolos no lo hacen.
Para que interoperen entre los dos hemos tenemos que hacer algunas ope-
raciones extra al ponerlos en funcionamiento. Una de las razones por las que
no interoperan correctamente es la siguiente: el gateway de Cellular IP emite
unos paquetes (Gateway Broadcast Packet) que permiten a las estaciones base
conocer el prejo de subred del gateway y utilizar esta informaci on a la hora
de enviar los beacons que reciben los nodos m oviles y que les permite auto-
congurar sus direcciones. Esto lo hace correctamente. Pero a la vez que ocurre
esto, MobileIP debera darse cuenta de esa nueva direcci on y hacer que esa di-
recci on fuera su care-of address, pero esto no ocurre as. Para solucionar esto lo
que hago es poner en las estaciones base un radvd para que emitan el prejo de
subred del gateway.
interface eth2
{
AdvSendAdvert on;
MaxRtrAdvInterval 10;
#AdvSourceLLAddress off;
prefix [Link]/64
{
AdvOnLink on;
AdvAutonomous on;
};
};
Con esto ya conseguimos que el m odulo de Mobile IP en el nodo m ovil se
entere de esa nueva direcci on, la use como su care-of address y se registre en el
home agent correctamente.
Los pasos a seguir para poner la maqueta en funcionamiento son los siguien-
tes:
Arrancar la maqueta de Cellular IP sin radvds en las estaciones base
Arrancar Mobile IP en el nodo m ovil y llevarlo a la home network para
que adquiera la direcci on home address.
Llevarlo de nuevo a la foreign network.
Arrancar los radvds en las estaciones base.
Despues de esto el nodo m ovil debe registrarse correctamente en el home
agent, y ya podemos hacer handos entre las estaciones base.
87
Captulo 4
Computaci on ubicua
Mark Weiser, en Septiembre de 1991 [Wei91] describi o su visi on de lo que el
llamaba computaci on ubicua, hoy llamada computaci on pervasiva. La esencia
de su visi on era la creaci on de entornos repletos de computaci on y de capacidad
de comunicaci on, todo integrado de forma inapreciable junto a los personas. La
visi on de Weiser estaba bastante alejada de su epoca, entre otras razones porque
no exista la tecnologa necesaria para llevarlo a cabo.
Pero despues de m as de una decada de progreso en el campo de los dispo-
sitivos hardware, las criticadas ideas de Weiser en 1991 ahora son productos
comercialmente viables:
Ordenadores de bolsillo
Redes inal ambricas
Sensores muy avanzados
Computaci on vestible
Hoy en da existen muchos proyectos de investigaci on sobre computaci on per-
vasiva, tanto en las universidades como en las empresas: Oxygen en el MIT[MIT],
Aura en el CMU[CMU], CoolTown en HP[HP], ... Cada uno de estos proyectos
se centran en diferentes aspectos de la computaci on ubicua, y persiguen diferen-
tes objetivos tanto a largo como a corto plazo, pero todos ellos intentan hacer
de la computaci on pervasiva una realidad [Sat95].
88
Captulo 4. Computaci on ubicua Principios
4.1. Principios
Uno de los principales objetivos de la computaci on ubicua es hacer desapare-
cer a los dispositivos computacionales haciendolos situarse en un segundo plano.
Este objetivo de crear dispositivos que se mezclen en la vida cotidiana hasta que
lleguen a ser indistinguibles supone una potencial revoluci on que puede hacer
cambiar el modo de vida diario. Las personas se centrar an en las tareas que
deben hacer, no en las herramientas que utilizan, porque se pretende que esas
herramientas pasen desapercibidas.
El signicado de enviar la computaci on a un segundo plano, est a referido
a dos conceptos diferentes pero relacionados [Ara95]. El primero es el signicado
literal de que la tecnologa de la computaci on se debe integrar en los objetos,
cosas, tareas y entornos cotidianos. Y la segunda es que esta integraci on se
debe realizar de forma que la introducci on de computaci on en estas cosas u
objetos no intereran con las actividades para las que son usadas, y que siempre
proporcionen un uso m as c omodo, sencillo y util de esos objetos.
Estos objetos cotidianos en los que se integra la tecnologa de la computaci on
pasan a tener una serie de propiedades que permiten la creaci on del entorno
ubicuo buscado. Estas son algunas de esas propiedades:
Comunicaci on entre dispositivos: todos estos objetos dotados de capa-
cidad de computaci on tambien tienen capacidad de comunicaci on, y no
solo con el usuario, sino con los dem as objetos integrados que haya a su
alrededor
Estos objetos tienen memoria: Adem as de poder comunicarse entre ellos
e interactuar con los usuarios, estos dispositivos tienen capacidad de me-
moria y pueden utilizar esta memoria para una mejor interacci on con el
resto de dispositivos.
Son sensibles al contexto: estos objetos son sensibles al contexto, es
decir, se adaptan a las posibles situaciones, como la situaci on geogr aca,
los dispositivos que hay a su alrededor, las preferencias de los usuarios, ...
y act uan dependiendo de ese entorno que los rodea.
Son reactivos: estos objetos reaccionan a ocurrir determinados eventos,
que pueden percibir en su entorno mediante sensores o a traves de la
interacci on con otros dispositivos.
89
Captulo 4. Computaci on ubicua Motivaciones para la computaci on ubicua
4.2. Motivaciones para la computaci on ubicua
Existen algunos factores que hacen que la computaci on ubicua sea posible
hoy en da, y que hacen que las expectativas sean que cada da que pasa es
m as viable. Algunas de estos factores por separado tambien han ayudado al
desarrollo de otros campos de investigaci on, pero la uni on de todos ellos hacen
que la computaci on ubicua pueda ser realidad [Mat02]:
4.2.1. La ley de Moore
En 1965 Gordon Moore arm o que el n umero de transistores por pulgada
en circuitos integrados se duplicaba cada a no y que la tendencia continuara
durante las siguientes dos decadas.
Algo m as tarde modic o su propia ley al armar que el ritmo bajara, y la
densidad de los datos se doblaran aproximadamente cada 18 meses. Esta progre-
si on de crecimiento exponencial: doblar la capacidad de los microprocesadores
cada a no y medio, es lo que se considera la Ley de Moore.
Y esta ley se ha venido cumpliendo hasta el da de hoy, la capacidad de
c omputo de los procesadores avanza muy r apidamente. Pero no solo la capacidad
de c omputo de los procesadores, sino tambien la capacidad de almacenamiento,
el ancho de banda para las comunicaciones, ... En resumen, cada poco tiempo
tenemos dispositivos m as baratos, m as peque nos y m as potentes. Y no parece
que se vaya a parar este crecimiento, sino todo lo contrario, la previsi on para
los pr oximos tiempos es que siga ocurriendo lo mismo.
Pero hay un problema, y es que no todos los factores aumentan al ritmo de
la ley de Moore, este es el caso de la capacidad de almacenar energa median-
te bateras. Esto supone un gran problema para estos dispositivos de los que
hablamos, porque la capacidad de procesamiento, de almacenamiento,... crecen
exponencialmente, y tambien, aunque no al mismo ritmo crece el consumo de
energa, pero la capacidad para dotar a estos dispositivos de la energa necesaria
crece muy lentamente. Este es un campo en el que todava es necesario que se
produzcan muchos avances.
4.2.2. Nuevos materiales
El desarrollo en el campo de los materiales tambien es muy importante. Hay
muchos desarrollos en nuevos materiales que ya son estables y usados actual-
mente , pero tambien hay otro tipo de materiales que est a actualmente en pleno
desarrollo y que pueden presentar grandes avances para la computaci on ubicua:
Displays exibles: el uso de polmeros emisores de luz permite crear
pantallas formadas por l aminas de pl astico muy nas, exibles y plegables.
Tinta electr onica y papel inteligente: que pretenden conseguir que el bolgra-
fo y el papel se conviertan en dispositivos verdaderamente m oviles.
El desarrollo de bras informatizadas que se pueden entremezclar con los
tejidos, con lo cual se pueden insertar transistores, sensores y unidades de
procesamiento entre la estructura de la bra.
90
Captulo 4. Computaci on ubicua Motivaciones para la computaci on ubicua
Pero todava queda algo de tiempo para que estas tecnologas puedan ser
llevadas al campo de la pr actica, lo cual supondr a un gran avance para el mundo
de la computaci on ubicua.
4.2.3. Avances en la tecnologa de la comunicaci on
Otro gran avance, como ya hemos comentado en los captulos anteriores, es
el avance en el sector de las comunicaciones:
La bra optica ha aumentado la capacidad de las lneas de comunicaciones
hasta poder establecer transmisiones de hasta Gigabits por segundo
Tecnologa de redes inal ambrica. Tambien se han producido grandes avan-
ces en la telefona m ovil (GSM, UMTS) y en las redes locales inal ambricas
( secci on 2.3 ).
Redes de area personal: ofrece la creaci on de peque nas redes alrededor de
los usuarios ( secci on 2.5 ).
4.2.4. Desarrollo de los sensores
El campo de los sensores tambien se ha desarrollado bastante en los ultimos
tiempos, tanto tecnol ogicamente como fsicamente por el reducido tama no que
se ha conseguido en estos sensores. Algunos de estos avances son:
C amaras y micr ofonos de muy reducido tama no acompa nado de recono-
cimientos de patrones y de tecnicas de reconocimiento de voz
Detectores de huellas digitales en objetos m oviles
Sensores de localizaci on
Dispositivos RFID: dispositivos para identicaci on por radiofrecuencia sin
necesidad de contacto con el lector.
91
Captulo 4. Computaci on ubicua Escenarios
4.3. Escenarios
C omo ser an las situaciones en las que hipoteticamente se implantar a la
computaci on ubicua en un futuro? Pues no es f acil adivinar, pero para intentar
comprender mejor en que consiste este mundo de computaci on ubicua vamos a
exponer algunas situaciones que se pueden dar ahora mismo o en un futuro, en
las que se muestran las aportaciones de la computaci on pervasiva a la vida real,
o a las posibles situaciones futuras. Algunas de estas situaciones puede que hoy
en da ya sean reales.
Algunas de estas situaciones han sido simuladas dentro de las limitaciones
que impone la tecnologa actual, y de la disponibilidad de hardware con la que
cont abamos. Y el resto solamente son descritas planteando posibles situaciones
futuras.
4.3.1. Seguimiento de personas
Tenemos la siguiente situaci on:
Situamos el escenario en una guardera que ofrece un servicio especial a los
padres de los ni nos que entran en esta guardera. El servicio ofrecido, es que
en todo momento los padres podr an ver a sus hijos mediante una p agina web,
independientemente de donde se encuentren los peque nos.
Esta situaci on se puede dar hoy en da perfectamente, porque tenemos la tec-
nologa necesaria para realizarlo. Una de las posibles soluciones a esta situaci on
sera la siguiente:
En cada sala de la guardera tenemos un ordenador con una videoc amara
conectada, el ordenador est a encendido 24 horas al da y la c amara est a conti-
nuamente grabando y preparada para transmitir por videoconferencia cuando
sea necesario.
Cuando un cliente quiere comenzar a recibir vdeo, se realiza una conexi on
entre el cliente y el servidor de vdeo, que es el ordenador de la sala en la que se
encuentra el ni no en ese momento. Cuando el ni no cambia de habitaci on, hay
que cambiar de servidor de la transmisi on, para esto utilizamos el protocolo de
movilidad Mobile IP ( secci on 3.2 ), teniendo en cuenta que en todo momento
el servidor que enva el vdeo es el nodo m ovil, aunque en este caso lo que se
mueve no es el ordenador, pero podemos hacer una aplicaci on para simular ese
movimiento y hacer que la conexi on entre el correspondent node (cliente de la
transmisi on de vdeo) y el nodo m ovil sea continua en todo momento.
En realidad, en esta situaci on, lo que se mueve realmente es una persona,
y necesitamos alguna forma de localizar en todo momento a esa persona ( el
ni no ) para poder utilizar el ordenador de la sala actual como nodo m ovil de
la comunicaci on mediante Mobile IP. Para localizar a esta persona se pueden
utilizar varias tecnicas, una de ellas puede ser que la persona lleve consigo un
dispositivo RFID, que transmite se nales inal ambricas por radiofrecuencia y tener
receptores en las salas para recibir estas se nales y saber en cada momento donde
se encuentra el ni no.
De este modo tenemos en todo momento localizado al ni no y se puede utilizar
el dispositivo de grabaci on de la sala en la que se encuentre para envi arsela a
los padres.
Esta misma situaci on puede aplicarse a muchos casos m as, como por ejemplo
para hacer el seguimiento de vehculos en una cadena de montaje, seguimiento
92
Captulo 4. Computaci on ubicua Escenarios
de presos en una prisi on, ...
Esta situaci on la hemos simulado, con la tecnologa con la que contamos y
est a desarrollada en la secci on 4.4.1.
4.3.2. Informaci on seg un la situaci on
Tenemos la siguiente situaci on:
Nos situamos en un museo en el que la direcci on del museo ha decidido subs-
tituir los actuales guas que van proporcionando informaci on sobre el contenido
de cada sala o cada objeto, por dispositivos que llevar an los visitantes y en los
que se les mostrar a y podr an conseguir toda la informaci on necesaria de cada
sala sin tener que hacer nada m as que ir visitando el museo. Cuando cambien
de sala o se sit uen enfrente de un objeto se les mostrar a y podr an escuchar la
informaci on pertinente.
Esta situaci on tambien es viable hoy en da con la tecnologa con la que
contamos.
Los dispositivos que proporciona el museo a los visitantes son PDAs con
tecnologa 802.11b ( secci on 2.4 ) para las comunicaciones inal ambricas y tam-
bien receptor de infrarrojos ( 2.6 ). Todo el museo est a cubierto con puntos de
acceso para que desde cualquier sala haya conexi on a la red de museo, o incluso
a Internet.
En cada sala, y quiz a en cada objeto, hay un dispositivo denominado beacon.
Este dispositivo es un dispositivo muy peque no que posee capacidad de comu-
nicaciones inal ambricas, y que se utiliza usualmente para el envo de peque nas
cantidades de datos cada cierto periodo de tiempo. Normalmente la informaci on
enviada es una URL que se congura previamente en el dispositivo.
De esta forma en cada sala u objeto estos dispositivos envan una URL,
que es captada por el receptor de infrarrojos del dispositivo m ovil que llevan
los visitantes, y a partir de esta URL, mediante HTTP y la red inal ambrica
disponible con 802.11, los PDAs hacen una solicitud de esa informaci on a un
servidor web que est a disponible en el museo y le muestran esta informaci on a
los visitantes, en forma de p aginas HTML, vdeo o audio.
4.3.3. Contin ua la videoconferencia
La situaci on sera la siguiente:
Un ejecutivo necesita tener videoconferencias muy a menudo con personas
de otras ciudades, pero es una persona muy ocupada y necesita una movilidad
continua dentro de la empresa en la que trabaja. Por eso necesita estar siem-
pre disponible y poder realizar una videoconferencia en cualquier momento, y
cambiar de sala o de ordenador mientras est a teniendo estas videoconferencias.
La soluci on tecnol ogica podra ser la siguiente. El ejecutivo lleva siempre con-
sigo un dispositivo PDA, con posibilidad de comunicaciones inal ambricas para
conectarse a la red de la empresa y con software para realizar videoconferen-
cias. Este dispositivo ser a el nodo m ovil para utilizar la tecnologa de movilidad
Mobile IP, por tanto aunque se este moviendo podr a seguir teniendo la video-
conferencia.
Pero tambien necesita que cuando llegue a su despacho, o sala similar, la
videoconferencia pase a tener lugar desde el ordenador de sobremesa del que
dispone la sala. Para ello esos ordenadores de sobremesa cuentan con dispositivos
93
Captulo 4. Computaci on ubicua Pr acticas sobre Computaci on Ubicua
dongles (secci on 2.6.3), que detectan que el PDA est a al lado de ellos mediante
el puerto de infrarrojos, y se simula el cambio del nodo m ovil a ese ordenador
de sobremesa para poder seguir con la videoconferencia desde el.
De esta forma, puede utilizar ordenadores de sobremesa cuando tenga dis-
ponible alguno, y si esto no ocurre utilizar a su dispositivo m ovil.
Esta situaci on se puede modelar con la informaci on disponible en el apendice
4.4.2.
4.3.4. Charla en sala pervasiva
Situaci on:
Un profesor en una universidad ha improvisado una charla para unos es-
tudiantes. El profesor lleva un PDA en el que lleva toda la informaci on para la
charla, la presentaci on, unos apuntes, ... y necesita compartir esta informaci on
con los alumnos, necesita proyectar las diapositivas con el proyector disponible
en la sala, ...
Para esta situaci on hay que hacer uso de las redes ad-hoc (secci on 2.8).
Gracias a este tipo de tecnologa, se puede crear una red local al momento entre
el dispositivo inal ambrico del profesor, los que dispongan los alumnos y los
elementos ubicuos que existan en la sala se puedan comunicar sin problemas.
Esta red ad-hoc se puede crear entre dispositivos con tecnologa 802.11, u otros
tipos de tecnologa como Irda (secci on 2.6).
Por tanto, dependiendo de los dispositivos que tengan cada uno de ellos uti-
lizar an uno de estos tipos de comunicaci on o incluso ambos. Si tienen port atiles
con tarjetas 802.11b crear an la red local con ellas, que sera la opci on recomen-
dada porque sera m as f acil crear cobertura para todos ellos en esta red, o sino
pues tambien podran usar los dispositivos infrarrojos de los port atiles o PDAs.
La sala contara con otros dispositivos ubicuos, como una pizarra electr oni-
ca o un proyector en la que se podran mostrar las diapositivas del profesor, u
otro tipo de informaci on, porque estos dispositivos ubicuos tambien formaran
parte de la red ad-hoc creada en la sala que estuvieran para facilitar las comu-
nicaciones entre todos ellos.
4.4. Practicas sobre Computaci on Ubicua
A continuaci on se denir an algunas de las simulaciones realizadas de posibles
escenarios de computaci on ubicua. Al ser simulaciones, algunos de los dispositi-
vos utilizados no se corresponden con los que se usaran en la aplicaci on real de
estos escenarios, pero estos dispositivos son similares en cuanto a funcionalidad.
4.4.1. Seguimiento de personas
Planteamiento
La simulaci on consiste en lo siguiente: Hay una m aquina que est a recibien-
do una videoconferencia, y hay otras m aquinas transmiten este tr aco. Estas
m aquinas se supone que realizan un seguimiento de un objeto o persona y se
intercambian el papel de emisor dependiendo de donde se encuentre el supuesto
objetivo.
94
Captulo 4. Computaci on ubicua Pr acticas sobre Computaci on Ubicua
Para ello se utiliza la implementaci on de Mobile IPv4 instalada de la forma
explicada en la secci on 3.5.1, pero sobre la maqueta de la gura 4.1
Router
Home Agent
Emisor
video 1
Emisor
video 2
Foreign Agent
Receptor vdeo
Figura 4.1: Maqueta para la simulaci on de seguimiento
Como podemos ver en la gura 4.1, tenemos un ordenador que recibe el
vdeo, en este caso se encuentra en la home network de Mobile IP, pero podra
estar en cualquier otra red. En esta misma red tenemos al home agent, y a
uno de los nodos que actuar an como receptores de la transmisi on. En la otra
red (foreign network de Mobile IP) tenemos un foreign agent y al otro nodo
encargado de la transmisi on de vdeo.
Cada uno de los emisores de vdeo poseen una videoc amara grabando conti-
nuamente, y tanto los emisores como el receptor tienen un software para reali-
zaci on de videoconferencias llamado vic.
Procedimiento
El funcionamiento sera el siguiente: Inicialmente hay una videoconferencia
entre el receptor y el emisor 2. Este emisor 2 posee la direcci on IP del nodo
m ovil que act ua en el protocolo Mobile IP. Cuando queremos cambiar el emisor
deberamos dejar de transmitir por el emisor 2 y empezar a recibir vdeo del
emisor 1.
Para ello se hace una simulaci on de lo que sera el movimiento de un nodo
m ovil de una red a otra en Mobile IP, pero en esta ocasi on no movemos el nodo,
sino que intercambiamos las direcciones IP entre las m aquinas emisoras para
que el protocolo Mobile IP crea que el nodo se ha cambiado de red.
De esta forma cuando queramos recibir de uno de los emisores necesitamos
que le sea asignada la direcci on IP del nodo m ovil, y de esta forma contin ue la
transmisi on de vdeo hacia el receptor. Para realizar esta simulaci on de movi-
miento de nodo m ovil en el que se intercambian las direcciones IP, hemos reali-
zado unos programas en el lenguaje de programaci on Ada usando la librera de
comunicaciones Lower Layer.
95
Captulo 4. Computaci on ubicua Pr acticas sobre Computaci on Ubicua
Implementaci on
La arquitectura de los programas sigue el modelo cliente/servidor:
Servidor: El servidor es lanzado en la m aquina que act ua como receptora de
vdeo. La funci on del servidor es esperar hasta recibir un mensaje de alguno
de los emisores de vdeo, cuando recibe el mensaje de uno de ellos ( lo enva
porque quiere transmitir ) enva un mensaje al emisor que actualmente
est a emitiendo para que intercambie las direcciones IP con el que nodo
que lo ha solicitado. Despues de esto sigue esperando a que otro nodo
solicite transmitir.
Cliente: El cliente se lanza en cada uno de las m aquinas que est an listas
para transmitir, en nuestro caso los dos emisores. Este programa espera
hasta que recibe una se nal, esta se nal podra ser la recepci on de alg un
mensaje por infrarrojos o alg un tipo de sensor. En nuestro caso la se nal
que recibe el cliente es la pulsaci on de la tecla Enter.
Cuando un cliente recibe esta se nal enva un mensaje al servidor para que
le indique al nodo que transmite actualmente que deje de hacerlo y que
intercambie las direcciones IP con el. De esta forma el emisor que estaba
transmitiendo deja de hacerlo y el nuevo emisor sigue transmitiendo al
servidor.
Hay que tener en cuenta que el uso de Mobile IP es imprescindible, por-
que el receptor de vdeo en todo momento est a teniendo una videoconferencia
supuestamente con una sola m aquina en todo momento, pero gracias a este
protocolo podemos cambiar la direcci on a otra m aquina en otra red y que la
videoconferencia siga en curso.
Simulaci on
Pasos a seguir para realizar la simulaci on:
En el home agent es necesario arrancar el software de Mobile IP:
# dynhad --fg --debug
En el foreign agent es necesario arrancar tambien el software de Mobile
IP:
# dynhad --fg --debug
En el receptor de vdeo hay que arrancar el software de la aplicaci on
servidor y el software para recibir el vdeo ( indicando la direcci on IP del
nodo m ovil de Mobile IP ):
# ./servidor
# vic [Link]/8888
96
Captulo 4. Computaci on ubicua Pr acticas sobre Computaci on Ubicua
En el emisor que comienza retransmitiendo vdeo hay que arrancar el
software de Mobile IP, el software de videoconferencia ( con la direcci on
IP del servidor ) y el software cliente de la aplicaci on:
# dynmnd --fg --debug
# vic [Link]/8888
# ./cliente -mn
En los dem as emisores hay que arrancar el software cliente de la aplicaci on:
# ./cliente
Una vez realizados estos pasos el servidor estar a recibiendo del emisor que
hayamos congurado. Para cambiar de emisor bastar a con pulsar la tecla En-
ter del ordenador que queremos que siga transmitiendo.
4.4.2. Movilidad de personas
Planteamiento
En este caso, la simulaci on consiste en lo siguiente: hay una m aquina en una
determinada red que est a transmitiendo vdeo, y hay otra m aquina o dispositivo
que quiere recibir esa transmisi on mientras se mueve por varias redes diferentes.
Para la simulaci on de este escenario se ha utilizado la implementaci on de
Mobile IPv6 congurada tal cual se muestra en la secci on 3.7.1, y se ha utilizado
la misma maqueta, podemos verla de nuevo en la gura 4.2.
Subred 1
Subred 2
Subred 3
Subred 4
Subred 5
Subred 6
Internet
Figura 4.2: Maqueta para la simulaci on de movilidad
Habr a un nodo emisor de vdeo en una de las subredes de la maqueta o en
otra red de fuera de la maqueta, ya que esta maqueta est a conectada a Internet
mediante el gateway de la subred 1.
97
Captulo 4. Computaci on ubicua Pr acticas sobre Computaci on Ubicua
Y habr a un nodo receptor que es un ordenador port atil, que estar a en alguna
de las subredes de la maqueta que recibir a la transmisi on de vdeo. Estos dos
nodos disponen del software para videoconferencia llamado vic.
Procedimiento
El procedimiento sera el siguiente: Inicialmente el nodo emisor ( correspon-
dent node de Mobile IPv6) est a transmitiendo vdeo hacia el nodo receptor.
Este nodo receptor act ua como nodo m ovil de Mobile IPv6, y estar a por alguna
de las foreign networks 3, 4, 5 o 6, que son las que disponen de foreign agents
para dar conexi on a los nodos m oviles. El home agent est a situado en alguna
red de fuera de la maqueta, aunque tambien podra estar en alguna de las de la
maqueta.
Cuando el nodo m ovil se mueva de una subred a otra, informar a al home
agent de su nueva situaci on y de esta forma podr a seguir recibiendo el la se nal
de vdeo independientemente de la red a la que se conecte.
Simulaci on
Para la simulaci on de este escenario es necesario seguir los pasos que se
describen en la secci on 3.7.2 para iniciar el funcionamiento de Mobile IPv6 en la
maqueta, y arrancar el software de videoconferencia en el cliente y en el servidor
de la transmisi on:
Cliente:
# vic fec0::3:2e0:4cff:fe69:2d78/8888
Servidor:
# vic fec0::7:260:1dff:fef1:2be9/8888
Despues de esto, solamente con ir moviendo el ordenador port atil que act ua
como nodo m ovil entre las diferentes subredes podremos ver que podemos seguir
con la videoconferencia independientemente de donde estemos.
98
Captulo 5
Conclusiones
La computaci on ubicua, como hemos visto a lo largo de todo el estudio
realizado, ofrece una visi on de futuro con una gran cantidad de posibilidades en
la vida cotidiana de las personas. La idea de computaci on ubicua se extiende
sobre todos los dispositivos u objetos que nos rodean y plantea nuevas formas
de entender nuestro entorno, y nuevos modos de interactuar con todos estos
objetos, tanto nosotros con ellos como ellos con nosotros.
Como hemos visto, la computaci on ubicua todava es un campo muy joven,
un campo por descubrir en el que todava queda mucho por investigar, pero
no solo en el campo de la computaci on ubicua en s, sino en todos los campos
en los que se basa: tecnologa de componentes, sensores, comunicaciones, nuevos
materiales, y muchos m as. Por tanto, aunque ciertos aspectos de la computaci on
pervasiva ya pueden ser llevados a la pr actica, el futuro de esta tecnologa depen-
de del desarrollo de todos estos campos mencionados, seg un vayan avanzando
estos campos ir an abriendo nuevas posibilidades de expansi on a la computaci on
ubicua.
Pero el objetivo nal, no es solamente que esta tecnologa se desarrolle y se
introduzca en todos los objetos cotidianos. El objetivo nal es que la computa-
ci on ubicua pase desapercibida, es decir, que la gente que usa estos dispositivos
ubicuos no sepa realmente toda la tecnologa que se encuentra detr as de los
dispositivos u objetos que usan, que los usuarios se centren solamente en las
acciones que deben realizar y no en las herramientas que usan para ello. En
resumen, que la computaci on ubicua pase a un segundo plano dejando en el
primer plano a los usuarios y a las tareas que realizan, no a los dispositivos que
utilizan.
Hay muchos factores que inuyen en el futuro de este campo, y no solo son
factores tecnol ogicos, hay otro tipo de factores que inuyen m as que estos ulti-
mos, son los factores econ omicos y sociales. Es imposible predecir si todos estos
avances ser an viables econ omicamente, y si ser an socialmente bien aceptados.
Hay que tener en cuenta que la computaci on ubicua introduce muchos avances
que pueden inuir en la privacidad y en la intimidad de las personas si no se
hace un buen uso de ellos.
Por tanto, el factor social y econ omico, e incluso poltico debe ser tenido en
cuenta a la hora de valorar el futuro de esta tecnologa, porque ya se han dado
hechos en la historia de tecnologa superior a otra existente ( sistemas Beta vs
VHF, por ejemplo) que no tuvieron exito por razones no tecnol ogicas.
99
Captulo 5. Conclusiones
En cualquier caso, tanto si se extiende en un futuro como si no lo hace,
lo que est a claro es que la computaci on ubicua o pervasiva ofrece un cambio
de percepci on de las tareas realizadas diariamente que proporcionara grandes
avances para los usuarios nales, que sera todo el mundo, facilit andole todas
estas tareas y ofreciendo nuevas posibilidades hoy difciles de predecir.
Al nalizar el proyecto, bas andonos en los objetivos planteados en la secci on
1.2, puedo armar que se ha conseguido la realizaci on de todos estos objeti-
vos. Se ha realizado un estudio te orico de toda la tecnologa propuesta, se han
realizado las pruebas pr acticas sobre toda esta tecnologa sin demasiadas dicul-
tades y se ha experimentado con una amplia variedad de diversos dispositivos.
Especcamente, podramos destacar las siguientes conclusiones:
La tecnologa inal ambrica est a muy avanzada, sobre todo el est andar
802.11b, y se puede introducir en la mayora de los dispositivos m ovi-
les de los que disponemos en la actualidad de forma sencilla, quiz a por
esto parece que a da de hoy es el est andar que est a siendo socialmente
m as aceptado, y por ello en muchas empresas se crean redes con esta tec-
nologa, y tambien se est an desarrollando mucho las redes inal ambricas
ciudadanas con tecnologa 802.11b.
Los PDA tambien est an siendo desarrollados muy r apidamente, y pro-
porcionan muchas posibilidades para a los usuarios. Pero claramente, la
ventaja entre los dos tipos de PDA que hemos probado durante los expe-
rimentos, ha sido que uno de ellos (Compaq Ipaq) nos permita cambiar el
sistema operativo, lo que le a nada muchas m as posibilidades de uso, un
aumento del rendimiento y de la funcionalidad del mismo. Adem as estos
dispositivos vienen cada da mejor equipados, sobre todo en el aspecto
de las comunicaciones, proporcionan posibilidad de comunicaci on por el
puerto de infrarrojos, puerto serie, puerto usb e incluso la inclusi on de
dispositivos para comuncaciones por 802.11 o Bluetooth.
Las implementaciones de Mobile IPv4 y Mobile IPv6 que hemos utilizado
en las maquetas est an bastante desarrolladas y su estado de desarrollo
es muy estable, adem as el desarrollo de las mismas sigue muy activo. La
implantaci on de la movilidad usando estas implementaciones es relativa-
mente sencillo y su rendimiento es bastante aceptable, pero en la vida real
parece que no es muy usado. As como las redes inal ambricas 802.11b son
muy usadas y su uso sigue creciendo, el uso de la tecnologa de movilidad
no es usado pr acticamente en ambientes que sean de investigaci on.
Las implementaciones de Cellular IPv4 y Cellular IPv6 no son tan estables
como las de Mobile IP, y su desarrollo no est a tan avanzado, quiz a por-
que el uso de estas implementaciones est a menos extendido, incluso en el
ambito de la investigaci on. Durante la implantanci on que nosotros hicimos
de esta tecnologa en las maquetas montadas tuvimos algunos problemas,
que sin ser problemas graves que pudimos arreglar, demostraban que el
desarrollo de estas implementaciones no est a tan avanzado.
Cellular IP y Mobile IP deben ser implementados como denen los est anda-
res para proporcionar compatibilidad entre ellos para poder interactuar,
pero las pruebas realizadas en este aspecto no fueron nada satisfactorias
100
Captulo 5. Conclusiones Desarrollo del proyecto
porque las implementaciones probadas entre Cellular IP y Mobile IP no
interactuaban entre ellas, y hubo que hacer una gran cantidad de cambios
para que pudieran interactuar mnimamente, sin conseguir los resultados
deseados con el uso de ambas tecnologas.
La implementaci on del protocolo DSR para la arquitectura de los robots
Legos se desarroll o bajo la arquitectura i386, por tanto hubo que utilizar
compilaci on cruzada para su desarrollo, pero esta forma de desarrollo es
muy habitual y est a bien preparada, por lo que no hubo mayores diculta-
des al realizar este desarrollo. Algunos inconvenientes fueron que, al tener
que desarrollar el protocolo para la arquitectura legos y para la arquitec-
tura i386, algunas partes de la implementaci on eran dependientes de la
arquitectura (como el tema de threads o las libreras de comunicaciones
inal ambricas) y se tuvieron que realizar estas dos implementaciones casi
en paralelo para poder funcionar sobre las dos arquitecturas.
La experimentaci on sobre las redes ad-hoc desarrolladas con los robots
Legos fue muy interesante, y nos mostr o el funcionamiento real de este
tipo de redes, y tambien pudimos observar algunos de los problemas con
los que nos encontramos, como las colisiones en las comunicaciones por
infrarrojos o el aumento del consumo de energa cuando las comunicaciones
inal ambricas aumentan.
Despues de todo esto se puede armar que el nivel de desarrollo de toda esta
tecnologa est a muy avanzado, ya que hemos conseguido realizar experimentos
sobre los temas que hemos elegido sin grandes problemas, aunque todava queda
mucha investigaci on y desarrollo por realizar para mejorarlos.
Personalmente, con el desarrollo del proyecto he conseguido varias cosas.
Una de ellas ha sido consolidar los conocimientos adquiridos durante los a nos
de estudio en la universidad, sobre todo en el campo de las redes y las comuni-
caciones, pero en general me ha servido para aprender a estudiar sobre temas
nuevos en base a los conocimientos adquiridos durante los estudios en las asigna-
turas. Otro logro interesante ha sido el poder realizar estudios sobre tecnologa
que se encuentra en plena investigaci on en la actualidad, y el poder haber rea-
lizado experimentos con dispositivos que todava no son muy frecuentes porque
forman parte de esas investigaciones actuales. Es decir, me ha permitido realizar
una labor de investigaci on sobre campos de actualidad.
5.1. Desarrollo del proyecto
El proyecto se ha realizado durante aproximadamente 2 a nos, aunque du-
rante estos dos a nos ha habido periodos de m as actividad y otros periodos con
actividad escasa.
El tiempo real estimado para la realizaci on del proyecto es de unas 600 horas,
aproximadamente repartidas entre las siguientes tareas:
Estudio te orico de la tecnologa inal ambrica (5 % del total)
Conguraci on y pr acticas de dispositivos inal ambricos: Infrarrojos y 802.11
de los Compaq Ipaq, infrarrojos en el HP Jornada, dongles, beacons, ...
(10 % del total)
101
Captulo 5. Conclusiones Desarrollo del proyecto
Estudio te orico de los protocolos de movilidad (5 % del total)
Montaje de maqueta de pruebas para Mobile IPv4 (15 % del total)
Instalaci on y pruebas con Cellular IPv4 (5 % del total)
Montaje de maqueta de pruebas para Mobile IPv6 y pruebas de rendi-
miento (20 % del total)
Instalaci on y pruebas con Cellular IPv6 (5 % del total)
Estudio te orico de la computaci on ubicua (5 % del total)
Implementaci on del protocolo DSR para la arquitectura de robots Legos
(10 % del total).
Simulaciones de escenarios del modelo de computaci on ubicua (10 % del
total)
Generaci on de la documentaci on del proyecto (10 % del total)
Algunas de las labores realizadas durante el proyecto se han realizado conjun-
tamente con otras personas. Por ejemplo, el montaje de maquetas de redes para
pruebas de protocolos de movilidad se ha realizado junto con Ra ul Rodrguez
Aparicio. Y la implementaci on del protocolo DSR para los robots Legos se ha
realizado junto con: Jose Pelegrn y Ra ul Rodrguez.
102
Apendice A
Glosario
Beacon: Dispositivo de comunicaciones inal ambricas por infrarrojos con
una capacidad de enviar datos con ancho de banda muy reducido. Usual-
mente utilizado para emitir una URL.
Computaci on ubicua: Campo de la computaci on que se basa en la idea
de introducir la capacidad de computaci on y comunicaci on en todos los
objetos cotidianos, e intentar que el mundo de la computaci on pase a un
segundo plano, para que los usuarios se centren en las tareas a realizar y
no en las herramientas utilizadas.
Dongle: Dispositivo para comunicaciones inal ambricas. Normalmente se
conecta a un ordenador mediante el puerto serie o USB para dotar al
ordenador de posibilidades de comunicaciones inal ambricas mediante IrDA
(secci on 2.6 ).
ISM: En ingles: Industrial, Scientic, Medical. Se corresponde con un ran-
go de frecuencia del espectro de comunicaciones por radio que est a liberado
para uso libre sin necesidad de licencias.
LAN: En ingles: Local Area Network: Es una red de ordenadores o dispo-
sitivos computaciones dentro de un area reducida.
LLC: En ingles: Logical Link Control : Es una de las dos subcapas que
forman la capa de control de acceso de datos en la pila de protocolos de
IEEE 802. Se encarga de: gestionar el enlace de datos en la comunicaci on,
denir los servicios de los punto de acceso, ...
MAC: En ingles: Media Access Control Es una de las dos subcapas que
forman la capa de control de acceso de datos en la pila de protocolos OSI.
Se encarga de mover los datos desde una tarjeta de interfaz de red a otro.
MAN: En ingles: Metropolitan Area Network: Es una red de datos di-
se nada para una ciudad. En terminos de tama no es m as grande que una
LAN, pero m as peque na que una WAN. Est a dise nada para disponer de
conexiones de alta velocidad.
PAN: En ingles: Personal Area Network: Es una tecnologa dise nada para
que una persona se pueda comunicar de forma inal ambrica con los dispo-
sitivos que le rodean: telefono, PDA, cascos para oir m usica, ...
103
Captulo A. Glosario
PDA: En ingles: Personal Digital Assistant. Es un dispositivo de ma-
no, de reducidas dimensiones, que puede incorporar: telefono, conexi on a
internet, comunicaciones inal ambricas, ... Adem as de poseer software de
caractersticas limitadas, aunque cada da est an m as desarrollados.
RFID: En ingles: Radio Frecuency Identication: Peque no dispositivo que
emite se nales de radiofrecuencia. Suele ser usado para los mismos nes
que los c odigos de barras, pero tiene la ventaja de que no es necesaria una
visi on directa del lector, y puede realizarse a mayores distancias.
WAN: En ingles: Wide Area Network: Consiste en una red localizada
en un area geogr aca muy extensa, normalmente est a formada por unas
cuantas LAN.
WEP: En ingles Wired Equivalent Privacy: Protocolo de seguridad para
WLAN denido en el est andar 802.11b. Se basa en el cifrado de datos que
son enviados por la red. Se ha comprobado que no es tan seguro como se
dise n o.
WLAN: En ingles Wireless Local Area Network: Es un tipo de LAN que
utiliza comunicaciones inal ambricas en lugar de cableado.
104
Bibliografa
[Ara95] Agustin A. Araya. Questioning ubiquitous computing. In Proceedings
of the 1995 ACM 23rd annual conference on Computer science, pages
230237. ACM Press, 1995.
[Ass93] Infrarred Data Association. Irda, 1993. [Link]
[Bel58] R. Bellman. On a routing problem. Quarterly of Applied Mathematics,
16(1):8790, 1958.
[CMU] Carnegie Mellon University CMU. Project aura. [Link]
[Link]/ aura/.
[Fam01] Familiar distribution, 2001. [Link]
[Fun02] Free Software Fundation. Gfdl license, November 2002.
[Link]
[HP] Hewlett Packard HP. Cooltown. [Link]
[HUT99] Helsinki University Of Technology HUT. Dynamics - hut mobile ip,
1999. [Link]
[Mat02] Friedemann Mattern. Ubiquitous & pervasive com-
puting: A technology-driven motivation. 8 2002.
[Link]
[MIT] Massachusetts Institute Technology MIT. Oxygen.
[Link]
[PC95] T.; Pahlavan, K.; Probert and M. Chase. Trends in local wireless
networks. IEEE Communications Magazine, Marzo 1995.
[Per96] Charles E. Perkins. Ip mobility support, 1996.
[Per97] Charles E. Perkins. Mobile IP; Design Principles and Practices.
Addison-Wesley Longman Publishing Co., Inc., 1997.
[Per01] Charles E. Perkins. Ad-hoc networking. Addison-Wesley Longman
Publishing Co., Inc., 2001.
[RT99] E. Royer and C. Toh. A review of current routing protocols for ad-hoc
mobile wireless networks. IEEE Personal Communications Magazine,
6(2):4666, 4 1999.
105
BIBLIOGRAF

IA BIBLIOGRAF

IA
[Sat95] M. Satyanarayanan. Pervasive computing: Vision and challenges.
IEEE Personal Communications, 8(4), 8 1995.
[SK01] Javier Gomez Sanghyo Kim. Cellular ipv6, 2001.
[Link] [Link].
[Sol] James D. Solomon. Mobile IP: The Internet Unplugged. Prentice Hall.
[Sta01] William Stallings. Wireless Communications and Networks. Prentice
Hall Professional Technical Reference, 2001.
[TL00] HUT Telecommunications and Multimedia Lab. Mipl mobile ipv6 for
linux, 2000. [Link]
[Toh02] C.-K. Toh. Ad hoc mobile wireless networks: protocols and systems.
Prentice Hall, 2002.
[Uni99] Comet Group In Columbia University. Cellular ip for linux, 1999.
[Link]
[Wei91] Mark Weiser. The computer for the 21st century. Sci. Amer., Sep-
tiembre 1991.
[Zim80] H. Zimmerman. Osi reference model the iso model of architecture
for open systems interconnection. IEEE Transactions on Communi-
cations, 28(4):425432, Abril 1980.
106