Implementación de Mobile IP entre redes móviles y WLAN

UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS

DEPARTAMENTO DE INGENIERÍA ELÉCTRICA
IMPLEMENTACIÓN DE MOBILE IP ENTRE REDES

MÓVILES Y WLAN
MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL ELECTRICISTA
KAREN ANDREA SALVATIERRA LEÓN
SANTIAGO DE CHILE
MAYO 2012
UNIVERSIDAD DE CHILE
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA
IMPLEMENTACIÓN DE MOBILE IP ENTRE REDES

MÓVILES Y WLAN
MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL ELECTRICISTA
KAREN ANDREA SALVATIERRA LEÓN
PROFESOR GUÍA:
SR. ALBERTO CASTRO ROJAS
MIEMBROS DE LA COMISIÓN:
SR. JUAN PÉREZ RETAMALES
SR. CLAUDIO ESTÉVEZ MONTERO
SANTIAGO DE CHILE
MAYO 2012
RESUMEN DE LA MEMORIA
PARA OPTAR AL TÍTULO DE
INGENIERO CIVIL ELECTRICISTA
POR: KAREN SALVATIERRA LEÓN
FECHA: 09/05/2012
PROF. GUÍA: SR. ALBERTO CASTRO
IMPLEMENTACIÓN DE MOBILE IP ENTRE REDES MÓVILES Y

WLAN
La evolución de las redes de comunicaciones móviles avanza hacia la unificación de

un ambiente heterogéneo en el cual se interconectan entre sı́ redes de distintos accesos.
En este escenario, la mantención de sesiones de internet de los usuarios, cuando éstos
se mueven de una red a otra, emerge como uno de los principales desafı́os a enfrentar.
La introducción de un protocolo de movilidad en la red aparece como solución a este
problema, facilitando el roaming entre redes y evitando la reconexión de las sesiones
del usuario.
El despliegue de redes wireless de área local (WLAN) es un económico medio para
acceder a internet a diferencia de las redes celulares con soporte de redes de paquetes.
Mientras que las redes WLAN poseen un ancho de banda significativamente mayor al de
las redes móviles, estas redes poseen una amplia cobertura que incentiva la interconexión
entre ambas tecnologı́as.
En este trabajo se desarrolla un modelo de interconexión de redes celulares y WLANs
utilizando Mobile IP. Las simulaciones se realizan en el software computacional OPNET
y el soporte de movilidad se enfoca desde el nivel IP utilizando los protocolos Mobile
IP en un ambiente global; y Proxy Mobile IP en un ambiente localizado, ambos en su
versión IPv4.
Los resultados MIP muestran una asimetrı́a entre delays end-to-end producto del
camino triangular del tráfico de datos. Esto lleva a una ineficiencia en el ruteo que
afecta principalmente a aplicaciones en tiempo real. El roaming hacia la red WLAN
provoca una disminución en los delays end-to-end en ambas direcciones situándose entre
56 % y 71 % cuando el estado de la red de internet tiene asociado una baja latencia. El
establecimiento de sesiones TCP sube en un 7 % mientras que el control de aplicaciones
de descarga FTP baja en 29 %. En el caso de PMIP, el 3-way handshake disminuye
en un 14 % mientras que el control de aplicación FTP en un 41 %. Este protocolo no
evidencia ineficiencia en el ruteo, tendiéndose además una disminución de delays end-
to-end incluso con latencia de red de 100 ms.
Lo positivo de enfocar la movilidad desde el nivel IP se encuentra en la indiferencia
que supone el tipo de acceso a nivel de capa de enlace. La ventaja de PMIP sobre MIP
es que no requiere de software especializado en el cliente, reduciendo ası́ los costos de
señalización en el establecimiento del servicio de movilidad. MIP por su parte, es idóneo
de ser utilizado en un esquema de interconexión global, por lo que su integración con
PMIP puede ser vista de manera complementaria estableciendo un esquema jerárquico
con este último proveyendo movilidad a nivel local.
A mis padres...
Agradecimientos
Agradezco a mi familia, en especial a mis padres y hermanas, que con esfuerzo y

dedicación me entregaron el sustento vital durante estos años universitarios.
De igual forma, agradezco a Jorge por mantener siempre una sonrisa para mı́, incluso
en los tiempos más adversos.
Quiero dar las gracias también a los profesores de la comisión, en especial al profesor
guı́a Sr. Alberto Castro Rojas, por su constante apoyo y entrega de las principales
directrices para el desarrollo de este trabajo.
Finalmente, agradezco al laboratorio Optical Networking Research Group ONRG
perteneciente a la institución Georgia Institute of Technology por el uso de la licencia
del software OPNET Modeler, sin el cual no hubiese sido posible este trabajo.
v
Índice de contenidos
1. Introducción 1
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1. Objetivos generales . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2. Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Antecedentes 4
2.1. Introducción a las redes móviles . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Mercado móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Tendencias en el consumo . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Desafı́os para la Movilidad frente a las tendencias del mercado . 6
2.2. Arquitectura global Internet . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Direcciones IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1.1. Dirección IPv4 e IPv6 . . . . . . . . . . . . . . . . . . 7
2.2.1.2. Movilidad en Sesiones de Internet . . . . . . . . . . . . 8
2.3. Manejo de movilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Movilidad a nivel de Red . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1.1. Movilidad IP basada en el host . . . . . . . . . . . . . 10
2.3.1.2. Movilidad IP basada en la red . . . . . . . . . . . . . . 15
2.3.1.3. Diferencias entre la movilidad IP basada en el host y
basada en la red . . . . . . . . . . . . . . . . . . . . . 17
2.3.2. Movilidad a nivel de Transporte . . . . . . . . . . . . . . . . . . 18
2.3.3. Movilidad en la capa de sesión . . . . . . . . . . . . . . . . . . . 22
2.3.4. Movilidad en la capa de aplicación . . . . . . . . . . . . . . . . 23
2.4. Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.1. Métricas usuales en redes . . . . . . . . . . . . . . . . . . . . . . 24
2.4.2. Métricas para dispositivos de red . . . . . . . . . . . . . . . . . 25
2.4.3. Métricas de performance de señalización de sistemas . . . . . . . 25
2.4.3.1. Aplicaciones de benchmarking en NGN/IMS . . . . . . 26
vi
ÍNDICE DE CONTENIDOS
2.4.3.2. Aplicaciones en servicios AAA . . . . . . . . . . . . . . 27

2.5. Herramientas de simulación de redes . . . . . . . . . . . . . . . . . . . 28
2.5.1. Consideraciones generales . . . . . . . . . . . . . . . . . . . . . 28
2.5.2. DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5.2.1. Elementos comunes en sistemas DES . . . . . . . . . . 29
2.5.2.2. Principio de funcionamiento . . . . . . . . . . . . . . . 29
2.5.2.3. Algoritmo sistemas DES . . . . . . . . . . . . . . . . . 30
2.5.3. Simulaciones y modelos de sistemas de comunicaciones . . . . . 30
2.5.4. Software de simulación de redes disponibles . . . . . . . . . . . 31
3. Desarrollo 32
3.1. Selección de software simulación de redes . . . . . . . . . . . . . . . . . 32
3.1.1. ns-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2. NCTuns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.3. Omnet++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.3.1. INET Framework . . . . . . . . . . . . . . . . . . . . . 35
3.1.3.2. MiXiM Project . . . . . . . . . . . . . . . . . . . . . . 36
3.1.4. OPNET Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2. Descripción de OPNET Modeler . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1. Presentación software . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2. Arquitectura de OPNET Modeler . . . . . . . . . . . . . . . . . 38
3.2.3. Dominio a nivel de red . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.4. Dominio a nivel de nodo . . . . . . . . . . . . . . . . . . . . . . 39
3.2.5. Dominio a nivel de proceso . . . . . . . . . . . . . . . . . . . . . 40
3.2.5.1. Componentes de un modelo de proceso . . . . . . . . . 43
3.2.6. Construcción modelo de simulación en OPNET . . . . . . . . . 46
3.3. Mobile IP en OPNET . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4. Escenario de pruebas Mobile IP en ambiente WLAN . . . . . . . . . . 49
3.4.1. Topologı́a de Red . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.2. Servicios de aplicaciones y perfiles . . . . . . . . . . . . . . . . . 50
3.4.3. Configuración métricas de simulación . . . . . . . . . . . . . . . 51
3.4.4. Configuración simulación DES . . . . . . . . . . . . . . . . . . . 52
3.5. Nueva implementación de Mobile IP en
OPNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.5.1. Diseño estación dual . . . . . . . . . . . . . . . . . . . . . . . . 53
3.5.1.1. Modelo de proceso ksl pro switch client . . . . . . . . 54
3.5.1.2. Modificaciones en procesos desarrollados por OPNET . 55
3.5.2. Diseño agente móvil HA . . . . . . . . . . . . . . . . . . . . . . 55
3.5.2.1. Modelo de proceso ksl pro switch ha . . . . . . . . . . 56
3.5.3. Diseño configuración MIP . . . . . . . . . . . . . . . . . . . . . 57
3.5.3.1. Modelo de proceso nodo externo de configuración de
movilidad . . . . . . . . . . . . . . . . . . . . . . . . . 58
vii
3.5.4. Escenario de pruebas modelo de interconexión de redes 3G/UMTS-

WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.5.5. Configuración métricas . . . . . . . . . . . . . . . . . . . . . . . 60
3.6. Extensión simple de MIP a Proxy MIP . . . . . . . . . . . . . . . . . . 60
3.6.1. Diseño estación dual . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6.2. Diseño agente móvil LMA . . . . . . . . . . . . . . . . . . . . . 61
3.6.3. Diseño nodos de acceso 3G y MAG . . . . . . . . . . . . . . . . 62
3.6.4. Diseño configuración PMIP . . . . . . . . . . . . . . . . . . . . 62
3.6.5. Servicios de aplicaciones y perfiles . . . . . . . . . . . . . . . . . 63
3.6.6. Configuración métricas . . . . . . . . . . . . . . . . . . . . . . . 64
4. Discusión de Resultados 65
4.1. Resultados pruebas Mobile IP en ambiente
WLAN-WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.1.1. Resultados con aplicación FTP . . . . . . . . . . . . . . . . . . 65
4.1.1.1. Red local . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.1.1.2. Red visitada . . . . . . . . . . . . . . . . . . . . . . . 66
4.1.1.3. Roaming de red . . . . . . . . . . . . . . . . . . . . . . 67
4.1.2. Resultados con aplicación Video conferencia . . . . . . . . . . . 69
4.1.2.1. Red local . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.2.2. Red visitada . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.2.3. Roaming de red . . . . . . . . . . . . . . . . . . . . . . 70
3G/UMTS-WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.3. Roaming 3G/UMTS-WLAN usando MIP . . . . . . . . . . . . . 75
4.3. Resultados pruebas Proxy Mobile IP en ambiente 3G/UMTS-WLAN . 76
4.3.3. Roaming 3G/UMTS-WLAN usando PMIP . . . . . . . . . . . . 79
4.4. Resultados globales de Aplication Delay Tracking package . . . . . . . . 79
4.5. Comparación Mobile IP OPNET versus implementación propia en am-
biente WLAN-WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5. Conclusiones 86
5.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.3. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.4. Discusión y trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . 88
6. Bibliografı́a 90
viii
Anexo A. Protocolos y tecnologı́as disponibles en OPNET Modeler 94
Anexo B. Redes celulares 3G 96

B.1. Sistemas 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
B.1.1. Servicios UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
B.1.2. Arquitectura UMTS . . . . . . . . . . . . . . . . . . . . . . . . 97
B.1.2.1. Red de núcleo . . . . . . . . . . . . . . . . . . . . . . . 97
B.1.2.2. Red acceso de radio . . . . . . . . . . . . . . . . . . . 97
B.1.2.3. Equipo del usuario UE . . . . . . . . . . . . . . . . . . 98
Anexo C. Esquemas de interconexión entre redes de accesos 3G/UTMS

y WLAN 99
C.1. Esquema loose coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
C.2. Esquema tight coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Anexo D. Material Digital 101

D.1. Escenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
D.2. Modelo de Nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
D.3. Modelo de Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
D.4. Archivos Externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
ix
Índice de tablas
2.1. Comparación protocolo MIP y PMIP. . . . . . . . . . . . . . . . . . . . 18

2.2. Software de simulación de redes. . . . . . . . . . . . . . . . . . . . . . . 31
3.1. Librerı́a disponible para modelos wireless en OPNET Modeler. . . . . . 37

3.2. Principales componentes del menú del editor de nodo. . . . . . . . . . . 40
3.3. KPs principales agrupados por área de funcionalidad. . . . . . . . . . . 46
3.4. Tipos de Object Files incluidos en un programa de simulación. . . . . . 47
3.5. Configuración cliente MIP en OPNET. . . . . . . . . . . . . . . . . . . 48
3.6. Configuración HA en OPNET. . . . . . . . . . . . . . . . . . . . . . . . 48
3.7. Configuración FA en OPNET. . . . . . . . . . . . . . . . . . . . . . . . 49
3.8. Modelo de nodos para pruebas MIP en ambiente WLAN. . . . . . . . . 50
3.9. Configuración aplicaciones para pruebas MIP en ambiente WLAN. . . . 51
3.10. Configuración métricas aplicación FTP para pruebas MIP en ambiente
WLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.11. Configuración métricas aplicación Video Conferencia para pruebas MIP
en ambiente WLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.12. Configuración simulación DES para pruebas MIP en ambiente WLAN. 52
3.13. Modificaciones en procesos propios de OPNET. . . . . . . . . . . . . . 55
3.14. Configuración nodo KSL MIP Config. . . . . . . . . . . . . . . . . . . . 58
3.15. Estimación delay handoff interconexión redes 3G\UMTS y WLAN. . . 58
3.16. Configuración métricas para pruebas MIP en ambiente interconectado. 60
3.17. Configuración métricas para pruebas MIP en ambiente interconectado. 60
3.18. Registration Delay en PMIP . . . . . . . . . . . . . . . . . . . . . . . . 63
3.19. Configuración métricas para pruebas PMIP en ambiente interconectado. 64
3.20. Configuración métricas para pruebas PMIP en ambiente interconectado. 64
4.1. Delay registro MIP en red local usando OPNET. . . . . . . . . . . . . . 66

4.2. Delay stack TCP/IP en red local usando MIP OPNET. . . . . . . . . . 66
4.3. Delay stack TCP/IP en red local con MIP creado para este trabajo. . . 66
4.4. Delay registro MIP en red visitada usando OPNET. . . . . . . . . . . . 67
4.5. Delay stack TCP/IP en red visitada usando MIP OPNET. . . . . . . . 67
4.6. Delay stack TCP/IP en red visitada con MIP creado para este trabajo. 67
x
ÍNDICE DE TABLAS
4.7. Roaming de red en ambiente WLAN. . . . . . . . . . . . . . . . . . . . 68

4.8. Delay a nivel IP y Aplicación en red local usando MIP OPNET. . . . . 69
4.9. Delay a nivel IP y Aplicación en red local con MIP creado para este
trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.10. Delay a nivel IP y Aplicación en red visitada usando MIP OPNET. . . 69
4.11. Delay a nivel IP y Aplicación en red visitada con MIP creado para este
trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.12. Delay control aplicación video en ambiente WLAN-WLAN. . . . . . . . 70
4.13. Delay stack TCP/IP en red local 3G. . . . . . . . . . . . . . . . . . . . 72
4.14. Delay stack TCP/IP en red visitada WLAN. . . . . . . . . . . . . . . . 72
4.15. Delay a nivel IP y Aplicación en red local 3G. . . . . . . . . . . . . . . 73
4.16. Delay a nivel IP y Aplicación en red visitada WLAN. . . . . . . . . . . 73
4.17. Delay control aplicación video. . . . . . . . . . . . . . . . . . . . . . . . 74
4.18. Delay stack TCP/IP en red local 3G. . . . . . . . . . . . . . . . . . . . 76
4.19. Delay stack TCP/IP en red visitada WLAN usando PMIP. . . . . . . . 76
4.20. Delay a nivel IP y Aplicación en red local 3G. . . . . . . . . . . . . . . 77
4.21. Delay a nivel IP y Aplicación en red WLAN usando PMIP. . . . . . . . 78
4.22. Delay control aplicación video. . . . . . . . . . . . . . . . . . . . . . . . 78
4.23. Resultados ADT de OPNET promedio proporción red y aplicación. . . 80
4.24. Resultados ADT de OPNET desviación promedio proporción red y apli-
cación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
xi
Índice de figuras
2.1. Tráfico móvil global por contenido. . . . . . . . . . . . . . . . . . . . . 6

2.2. Registro MIPv4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Ruteo triangular en MIPv4. . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4. Reverse tunneling MIPv4. . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5. Señalización registro en Proxy Mobile IP. . . . . . . . . . . . . . . . . . 16
2.6. Dominio Proxy Mobile IP. . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7. Estructura protocolo SCTP. . . . . . . . . . . . . . . . . . . . . . . . . 19
2.8. Estructura protocolo MPTCP. . . . . . . . . . . . . . . . . . . . . . . . 21
2.9. Arquitectura TLM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.10. Registro y autentificación en LTE. . . . . . . . . . . . . . . . . . . . . . 27
2.11. Autentificación y autorización RADIUS. . . . . . . . . . . . . . . . . . 28
2.12. Principio funcionamiento DES. . . . . . . . . . . . . . . . . . . . . . . 30
2.13. Event-Scheduling Time-Advance Algorithm. . . . . . . . . . . . . . . . 30
3.1. Pantalla de inicio OPNET Modeler v.14.5. . . . . . . . . . . . . . . . . 37

3.2. Jerarquı́a de objetos en OPNET Modeler. . . . . . . . . . . . . . . . . 38
3.3. Editor de Proyecto en OPNET Modeler. . . . . . . . . . . . . . . . . . 39
3.4. Modelo de estación de trabajo WLAN desarrollada en el editor de nodo. 41
3.5. Estructura jerárquica de creación de procesos en OPNET. . . . . . . . 42
3.6. Arquitectura de memoria compartida en OPNET. . . . . . . . . . . . . 42
3.7. Esquema hı́brido de estados en OPNET. . . . . . . . . . . . . . . . . . 44
3.8. Esquema de transiciones dentro de un STD. . . . . . . . . . . . . . . . 45
3.9. Topologı́a de red pruebas MIP en ambiente WLAN. . . . . . . . . . . . 50
3.10. Modelo estación dual 3G\UMTS-WLAN. . . . . . . . . . . . . . . . . 54
3.11. Modelo de proceso ksl pro switch client. . . . . . . . . . . . . . . . . . 55
3.12. Modelo de nodo HA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.13. Modelo de proceso ksl pro switch ha. . . . . . . . . . . . . . . . . . . . 56
3.14. Modelo de proceso del nodo KSL MIP Config. . . . . . . . . . . . . . . 59
3.15. Modelo 3G\UMTS y WLAN a emular, y modelo real implementado en
OPNET con integración de MIP . . . . . . . . . . . . . . . . . . . . . . 59
3.16. Modelo 3G/UMTS-WLAN a emular y modelo real implementado en OP-
NET con integración de PMIP . . . . . . . . . . . . . . . . . . . . . . . 61
xii
ÍNDICE DE FIGURAS
3.17. Modelo de nodo HA en PMIP. . . . . . . . . . . . . . . . . . . . . . . . 62

3.18. Modelo de nodo acceso 3G y MAG en PMIP. . . . . . . . . . . . . . . . 63
4.1. Delays en roaming IP WLAN-WLAN bajo aplicación FTP usando OPNET. 68

4.2. Delay IP durante roaming de red en ambiente WLAN usando OPNET. 71
4.3. Variación porcentual delays stack TCP/IP con aplicación FTP. . . . . . 73
4.4. Variación porcentual delays stack TCP/IP con aplicación Video. . . . . 74
4.5. Roaming 3G/WLAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.6. Variacion porcentual de los delays stack TCP/IP con aplicación FTP. . 77
4.7. Variación porcentual delays stack TCP/IP con aplicación Video. . . . . 79
4.8. Roaming 3G\WLAN usando PMIP. . . . . . . . . . . . . . . . . . . . . 80
4.9. Comparación MIP OPNET versus MIP desarrollado para este trabajo
con aplicación FTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.10. Comparación MIP OPNET versus MIP desarrollado para este trabajo
con aplicación Video. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.11. Variación delay TCP/IP para aplicación FTP. . . . . . . . . . . . . . . 84
4.12. Variación delay TCP/IP para aplicación Video. . . . . . . . . . . . . . 85
C.1. Esquemas de interconexión 3G-WLAN. . . . . . . . . . . . . . . . . . . 100
xiii
Capı́tulo 1
Introducción
1.1. Motivación
La gran recepción del público experimentada por las redes de acceso móvil evidencia
la ventaja que presentan los dispositivos inalámbricos, tales como celulares o iPads, en
la vida de las personas. Hoy en dı́a los usuarios no solo acceden a comunicaciones de
voz y mensajerı́a instantánea, sino que también son capaces de participar en sesiones
de internet gracias al soporte IP proporcionado por los actuales sistemas celulares.
Más aún, las redes de próxima generación NGN basadas totalmente en IP, proveerán
un rango de servicios más amplio y mejorado, donde se incluyan factores como la
convergencia global, interoperabilidad y movilidad.
Por otro lado, los fabricantes de terminales móviles ya han incorporado al mercado
dispositivos multimodo con diferentes interfaces de radio integradas generando ası́ un
ambiente heterogéneo en lo que respecta a las tecnologı́as de acceso. Actualmente exis-
ten numerosas investigaciones que buscan proporcionar un esquema de interconexión
factible entre redes de diferentes tecnologı́as de acceso de tal forma que el usuario pueda
moverse entre las redes sin experimentar quiebres en sus sesiones actuales.
Hoy en dı́a, la mantención de las sesiones del usuario luego de un roaming de red no es
posible con el diseño original del internet. Esto se debe a que la asignación de la dirección
IP en cualquier máquina varı́a de un punto de acceso al otro haciéndola inalcanzable
luego del cambio. Más aún, las sesiones de transporte TCP ligadas directamente con
las direcciones IP involucradas, tampoco pueden ser mantenidas llevando finalmente al
quiebre de la conexiones.
El problema anterior puede ser abordado por medio de protocolos que integren la
movilidad de las sesiones en su diseño. Estos últimos pueden trabajar en las distintas
capas del stack TCP/IP e inclusive trabajar conjuntamente en una solución.
1
CAPÍTULO 1. INTRODUCCIÓN
En este trabajo se aborda el problema desde el nivel de red simulando una estructura
de IP móvil dentro de una interconexión entre redes celulares y WLANs. Particular-
mente se busca aprovechar las ventajas de ambas redes de tal forma que la amplia
cobertura entregada por la red celular le permita al usuario moverse pero que a la
vez se pueda hacer uso de velocidades de transmisión más altas proporcionadas por
los hotspots WLANs de menor cobertura. La implementación es a través del software
comercial OPNET Modeler capaz de simular redes de comunicaciones por medio de
distintas librerı́as que trabajan con el stack TCP/IP.
1.2. Estado del arte

El despliegue de redes heterogéneas con integración de servicios de movilidad IP
para usuarios no existe hoy en dı́a. Actualmente, esta área se remite a investigaciones
que datan del principio del 2000 basadas principalmente en simulaciones de ambientes
de redes de distintos accesos.
Dentro de los grupos de trabajos asociados, se encuentra el Proyecto de Asocia-
ción de tercera generación 3GPP, 3rd Generation Partnership Project, el cual provee
estándares de telecomunicaciones. 3GPP ha adoptado una arquitectura de intercone-
xión entre UMTS-WLAN sin especificar cómo introducir la movilidad IP. Las últimas
investigaciones han estudiado su soporte comparando protocolos en distintos niveles
del modelo TCP/IP ası́ como también enfoques comparativos basados en la red versus
basados en el host.
Entre trabajos revisados se destacan [17, 20, 31]. El primero de ellos realiza una
integración UMTS/GPRS-WLAN a gran escala con soporte del protocolo Mobile IP
utilizando OPNET. La propuesta consiste en asignar de manera dinámica el Home
Agent dentro del dominio. Se comparan 3 arquitecturas, de las cuales la que presenta
mejor rendimiento es aquella que asigna funcionalidades de Home Agent al nodo GGSN
de la red UMTS. El segundo trabajo realiza la simulación en base a OPNET. En ella se
comparan los esquemas de interconexión open coupling y loose coupling y se estudian
mecanismos de handover vertical a través de los protocolos Mobile IP, Mobile SCTP
y SIP. De los resultados, los autores afirman que no existe gran diferencia en términos
de throughput y tiempo de respuesta entre ambos esquemas adoptados por lo que se
recomienda el esquema loose coupling gracias a que éste requiere menos complejidad
en su despliegue. Finalmente, en el tercer trabajo se propone disminuir el delay del
handover WLAN-GPRS presentado por MIP minimizando las señalizaciones de control
en el establecimiento del PDP context a un paso. La simulación se realiza en NS-2.26
y muestra que para un paquete fijo de 500 bytes, el delay en el cambio de WLAN a
GPRS se reduce en un 18 %.
2
CAPÍTULO 1. INTRODUCCIÓN
1.3. Objetivos
1.3.1. Objetivos generales

Implementación de protocolos Mobile IP en ambientes heterogéneos de redes si-
muladas computacionalmente.
Análisis de la performance de protocolos para manejo de movilidad IP frente a

distintos escenarios de redes.
1.3.2. Objetivos especı́ficos

Implementación de Mobile IP en OPNET Modeler desde dos perspectivas: basado
en la red y basado en el host.
Simulación de interconexión entre redes de acceso móvil y WLAN utilizando pro-

tocolos mobile IP.
Comparación escenario actual sin movilidad versus con movilidad en base a métri-
cas predefinidas.
Comparación de movilidad IP con enfoque basado en la red y en el host en base

a métricas predefinidas.
1.4. Estructura del documento

En el capı́tulo 2 se exponen los principales antecedentes relacionados con el trabajo
para contextualizar el desarrollo de la memoria. En el capı́tulo 3 se explica la implemen-
tación realizada. En primer lugar se presenta la selección del ambiente computacional
a utilizar y posteriormente se muestran las implementaciones de los protocolos de mo-
vilidad IP en el software seleccionado. En el capı́tulo 4 se muestran los resultados
obtenidos ası́ como también la discusión de éstos. Finalmente el capı́tulo 5 contiene las
conclusiones finales y los posibles trabajos futuros a realizar en la misma lı́nea.
3
Capı́tulo 2
Antecedentes
2.1. Introducción a las redes móviles
2.1.1. Mercado móvil
La adopción masiva de los servicios celulares, tanto a nivel nacional como mundial,
ha dejado en manifiesto la gran aceptación del público frente a una experiencia móvil
de comunicaciones 1,2 . Esto último ha guiado la evolución del sistema celular desde
una primera generación análoga (1G), con acceso múltiple limitado, hasta una cuarta
generación (4G) basada totalmente en tecnologı́a IP.
La incompatibilidad de diferentes sistemas análogos 1G existentes en su época, lle-
varon en la década de los 90 al lanzamiento de la segunda generación (2G) basada en
tecnologı́a digital. En este punto, la capacidad del sistema se vió aumentada gracias a la
aplicación de avanzadas técnicas de compresión y a que el acceso múltiple no se encon-
traba limitado a técnicas por división de frecuencia [12]. 2G concibe el servicio de voz
desde la perspectiva de la conmutación de circuitos caracterizándose por los estándares
Sistema Global para comunicaciones Móviles Global System for Mobile Communica-
tions, GSM y Acceso Múltiple por División de Código Code Division Multiple Access,
CDMA.
La tercera generación (3G) data de la década del 2000 donde se integraron servicios
1
A nivel nacional, de acuerdo a datos de la Subsecretarı́a de Telecomunicaciones de Chile (Subtel),
a Diciembre del 2010 la cantidad de abonados móviles representó una penetración del 115 % por cada
100 habitantes.
2
A nivel mundial, el Grupo de Negocios de Internet de Cisco (IBSG) estimó para el año 2010, 35
mil millones de dispositivos conectados a Internet que representan casi 6 dispositivos por persona en
el planeta.
4
CAPÍTULO 2. ANTECEDENTES
IP basados en la tecnologı́a de conmutación de paquetes. 3G ofrece una transmisión

más óptima incorporando servicios de datos a través del Servicio General de Paquetes
de Radio General Packet Radio Service, GPRS o CDMA2000 [14].
Hoy en dı́a la tendencia muestra un acceso futuro a servicios IP preferentemente
móvil. Lo anterior se respalda con el creciente uso de teléfonos inteligentes y la banda
ancha móvil los cuales permiten acceder a Internet gracias al despliegue de servicios
móviles de banda ancha usando Acceso de Paquetes de Alta Velocidad High Speed
Packet Access, HSPA, EV-DO Evolution-Data Only, o LTE Long-Term Evolution. Esta
última tecnologı́a 4G se basa totalmente en IP.
Evidentemente, el futuro del mercado móvil está convergiendo a las llamadas redes
“All-IP ” caracterizándose por usuarios corriendo aplicaciones en dispositivos especiali-
zados capaces de soportar entre otros, Internet para media 3D, comunicaciones y juegos
interactivos.
2.1.2. Tendencias en el consumo
De acuerdo al ı́ndice de red visual Visual Network Index, VNI de Cisco Systems
[7, 8], el cual pronostica el crecimiento y uso de redes IP, las tendencias en el consumo
actual y futuro en el uso del servicio de redes destacan:
En el año 2010, sólo un 3 % del tráfico Internet fue originado a través de dispositi-
vos non-PC. Para el año 2015 se espera un crecimiento de este tipo de dispositivos
en un 15 %. Adicionalmente, el tráfico IP generado por PCs crecerá a una tasa de
crecimiento anual compuesto Compound Annual Growth Rate, CAGR del 33 %,
mientras que TVs, tablets, smartphones, y módulos máquina-máquina (M2M) ex-
perimentarán tasas del 101 %, 216 %, 144 % y 258 % respectivamente.
En el 2010 dispositivos cableados aportaron un 63 % del tráfico IP, sin embargo,
para el 2015 se espera que el tráfico proveniente desde dispositivos inalámbricos
exceda el tráfico desde dispositivos cableados. De esta forma, terminales wired
aportarán un 46 % del tráfico IP mientras que aquel originado desde dispositivos
móviles y Wi-Fi será de un 54 %.
El tráfico de datos móviles globales, tales como mensajes de texto, mensajes mul-
timedia y servicios de video, se incrementará 26 veces entre el 2010 y el 2015.
Este tráfico crecerá a una tasa CAGR del 92 %, llegando a alcanzar 6.3 exabytes
mensuales en el último año. En el caso de Latinoamérica, la tasa CAGR será del
111 %.
El tráfico de datos móviles globales [2010-2015] crecerá 3 veces más rápido que el
tráfico de datos IP fijo. En el 2010, el tráfico global de datos móviles correspon-
5
dió al 1 % del tráfico IP total y será del orden del 8 % de éste último para el año
2015.
La figura 2.1 ilustra el tráfico móvil global por contenido en el perı́odo [2010-2015].
Para el año 2015, el consumo de video móvil abarcará el 70.5 % de todo el tráfico móvil
mientras que el tráfico móvil de voz comprenderá solo el 4.7 % del total [8].
Tráfico Móvil Global
Mobile VoIP
12.000
Mobile Gaming
Mobile P2P
10.000 Mobile M2M
Mobile Web/Data
Mobile Video
8.000
PB/mes
6.000
4.000
2.000
2010 2011 2012 2013 2014 2015

Año
Figura 2.1: Tráfico móvil global por contenido.
2.1.3. Desafı́os para la Movilidad frente a las tendencias del

mercado
A partir del indicador VNI de Cisco, el incremento del tráfico de datos móviles
predicho requerirá del soporte de una plataforma móvil de Internet por parte de los
operadores móviles si es que se quiere brindar un buen servicio. Al dı́a de hoy, el
problema de la movilidad se ha abordado a través de la técnica de tunneling de paquetes
sobre IP. En este ámbito, los protocolos más destacados corresponden a GPRS tunneling
Protocol GTP, Mobile IP MIP, Control and Provising of Access Points CAPWAP y
Proxy Mobile IP PMIP.
Internet Móvil requiere de redes celulares eficientes en el manejo del espectro de tal
forma de brindar acceso múltiple a los distintos usuarios a una alta velocidad. El reuso
de la frecuencia debiese ser la principal técnica para enfrentar la creciente demanda del
servicio móvil a través de la división de una celda en múltiples celdas más pequeñas.
6
De acuerdo a [14], las tecnologı́as de redes deberán soportar:
Adopción escalable de tecnologı́as de celdas más pequeñas (por ejemplo usando

tecnologı́a IEEE 802.11).
Un número masivo de dispositivos “always-on”.
Acceso generalizado, incluyendo accesos nómades desde edificios ası́ como también
accesos móviles de área ancha para el consumo en movimiento.
Conexiones ininterrumpidas para una amplia gama de servicios móviles.
2.2. Arquitectura global Internet
2.2.1. Direcciones IP
Cualquier dispositivo conectado a la red Internet se identifica a través de una direc-

ción IP. Esta última corresponde a un conjunto de números que distingue de manera
única y global al nodo conectado. Esta dirección tiene un doble propósito: identificar
la red a la cual se ha conectado el host (localización) y distinguir al dispositivo de los
otros nodos que ya se encuentren conectados a la misma red (identificación terminal).
Actualmente los protocolos más destacados a nivel de la capa de red corresponden al
protocolo IPv4 e IPv6.
2.2.1.1. Dirección IPv4 e IPv6
Las direcciones IPv4 son construidas con 32 bits separados en grupos de a ocho.
IPv4 separa la dirección de manera flexible en dos partes: una alude a la dirección de
la red y la otra al host conectado a dicha red. Cada nodo conoce su propia dirección IP
y su número de enlace a través de su “máscara de red”. IPv6 por su parte determina
una nueva clase de direcciones en base a 128 bits. En teorı́a, IPv6 es una arquitectura
que soporta “plug and play” por lo que se está trabajando sobre un protocolo para
re-enumerar automáticamente [27, 34].
A la fecha, la transición del Internet hacia el direccionamiento IPv6 está tomando
fuerza de manera paulatina. Este proceso no ha sido rápido debido a iniciales modi-
ficaciones en IPv4 con el fin de alargar su vida. Entre estas modificaciones destacan
CIDR, DHCP y NAT. En IPv6, el mecanismo NAT de traducción de direcciones de red
privada-pública se vuelve innecesario, sin embargo durante el perı́odo de transición se
ha propuesto utilizarlo como un traductor IPv4-IPv6.
7
2.2.1.2. Movilidad en Sesiones de Internet
La estructura inicial de Internet no consideró la movilidad en su diseño. Más aún,

el hecho que las direcciones IP sean utilizadas tanto para localizar al nodo como para
identificar al host en sı́ mismo, no ha facilitado el despliegue del servicio móvil. A modo
de ejemplo, no es posible mantener una sesión ininterrumpida cuando al menos uno de
los nodos involucrados cambia su punto de conexión a la red y por consiguiente adquiere
una nueva IP.
Existen distintas técnicas implementadas para simular un ambiente móvil. Dentro
de estas estrategias se destacan [14]:
Aceptar que las sesiones de aplicaciones están atadas a la sesión de transporte
En este caso, el enfoque no es mantener una sesión ininterrumpida sino más bien
brindar un acceso sin problemas ni trabas administrativas a la hora de conectarse a
una nueva red (roaming access). Aplicaciones como descargas de correos electrónicos
son idóneas para este tipo de enfoque.
Introducir un mecanismo de sesión ininterrumpida en la capa de aplicación que

no esté ligado a la sesión de transporte
La idea es implementar un mecanismo de sesión ininterrumpida en la capa de apli-

cación desligándolo de la capa de transporte. Por ejemplo, que el browser guarde la
información necesaria para continuar corriendo la aplicación en caso de que se pierda
la conexión.
Mantener la misma IP durante el movimiento
La técnica implementada es el tunneling cuyo objetivo es simular que el nodo móvil

está ligado directamente al router pero que en la práctica los datos se transporten a
través de distintos nodos. La idea consiste en encapsular los paquetes de la capa 2 en
nuevos paquetes de capa 2 creando una única gran red a partir de múltiples redes fı́sicas.
Introducir una nueva capa que ayude a soportar la movilidad
La capa a diseñar debiese sitiarse entre las capas de transporte y aplicación, o entre
la capa de red y de transporte.
Rediseñar TCP/IP separando localizadores de los identificadores de host finales
En este caso se requiere de la modificación del stack de protocolos TCP/IP.
8
2.3. Manejo de movilidad

La explosión en el crecimiento del uso de ambientes inalámbricos o wireless para
conectarse a Internet, tiene su explicación en la ventaja que supone mantener una sesión
a través de algún dispositivo no limitado por un cable. Hoy en dı́a es común encon-
trar empresas de distintos rubros ofreciendo acceso a Internet, por ejemplo mediante
una WLAN. Más aún, existen diversos proyectos que intentan establecer una gran red
wireless para ciudades enteras [1, 3, 11].
El desafı́o de las redes NGN consiste en generar un ambiente móvil donde no solo los
usuarios puedan moverse sin problemas dentro del alcance de una red, sino más bien
que lo hagan dentro de un rango de redes interconectadas entre sı́. La convergencia
hacia mobile IP busca lo anterior: usuarios con sesiones ininterrumpidas de Internet
[15].
El manejo móvil de las sesiones, puede enfocarse a través de protocolos que trabajen
a nivel de una capa en particular o inclusive múltiples protocolos en diferentes capas
coordinándose conjuntamente para garantizar un servicio de movilidad. Investigaciones
en el área han mostrado interés principalmente en el desempeño de protocolos que
trabajan a nivel de las capas de red, transporte y aplicación [9, 10, 20, 23].
2.3.1. Movilidad a nivel de Red
Es sabido que la estructura jerarquizada de la direcciones IP hace bien su trabajo

cuando se trata de rutear paquetes a destino pero que falla cuando el terminal quiere
cambiarse de red. Un inconveniente adicional se presenta cuando no solo el problema
de movilidad se presenta a nivel de la capa de red sino también a nivel de transporte.
Particularmente lo anterior alude a TCP, protocolo muy común a nivel de capa 4, el
cual antes de transmitir datos entre los puntos finales establece una conexión entre
ambos utilizando las direcciones IP como un identificador para establecer y mantener
sesiones. Luego si el nodo móvil cambia su punto de conexión a la red, las conexiones
de transporte se rompen interrumpiendo la conexión.
Para abordar este problema, la estrategia que se ha implementado para mantener las
conexiones TCP, consiste en preservar la dirección IP original pero diseñando un nuevo
protocolo que trabaje a nivel de la capa de red. De esta forma, la capa de transporte no
percibe el cambio de conexión fı́sica experimentado por el nodo pues éste es identificado
todo el tiempo mediante una única dirección IP.
Las funciones del nuevo protocolo buscan proporcionar un identificador único por
cada nodo móvil, pero a la vez un identificador dinámico para éste, por cada red externa
visitada. Existen dos enfoques utilizados para lograr lo anterior: Movilidad IP basada
9
en el host y Movilidad IP basada en la red.
2.3.1.1. Movilidad IP basada en el host
El manejo de movilidad está centralizado principalmente en el terminal móvil el

cual es responsable de actualizar a la red cada vez que cambie su punto de conexión.
La actualización se hace mediante señalización con entidades de la red. Dentro de las
ventajas, se tiene la independencia para con las tecnologı́as de la capa de enlace de
datos. Entre las desventajas, se encuentra la necesidad de incorporar software tanto en
terminales como en routers para poder soportar el protocolo. Por otro lado se requiere
de configuraciones de seguridad que permitan autentificar los intercambios de señali-
zaciones entre el host móvil y la red con el fin de modificar y actualizar las tablas de
ruteo. Adicionalmente, el proceso de handoff entre redes visitadas por el nodo puede
resultar ineficiente producto de los costos de señalización involucrados. En ese sentido,
el protocolo pareciese no ser idóneo para aplicaciones en tiempo real debido a la latencia
presentada en el handoff [28]. Ejemplo de solución host-based presentada por el IETF
es el protocolo Mobile IP.
Mobile IP MIP
Desarrollado por el IETF tanto para IPv4 como IPv6. MIPv4, fue especificado por
primera vez en 1996 en la RFC 2002 mientras que MIPv6 se describió en el documento
RFC 3775. Hoy en dı́a MIPv4 aparece como uno de los protocolos de movilidad de capa 3
más ampliamente implementado en numerosas organizaciones, incluyendo 3GPP2 [14].
MIP especifica mejoras en el protocolo de internet permitiendo el ruteo transparente
de datagramas IP hacia nodos móviles independiente de su conexión fı́sica a la red.
Dentro de los nuevos elementos incorporados en la arquitectura IP, destaca la distinción
de las redes entre sı́ de acuerdo a su relación con el nodo móvil según:
Home network : red que entrega la dirección IP identificadora del nodo móvil.
Virtual network : red en la cual generalmente reside el home agent.
Foreign network : cualquier otra red distinta a la home network en la que se puede
conectar el nodo móvil.
En el caso de los nodos, estos se distinguen según:
Nodo móvil MN : puede ser un host o un router. Hace referencia a la entidad que
cambia su punto de conexión a la red.
10
Home agent HA: router en la home network. Dentro de sus funciones de destacan el
establecimiento de tunneling IP con el foreign agent para mandar tráfico destinado
al nodo móvil cuando éste se encuentra fuera, registro de los nodos móviles y el
mantenimiento de una tabla actualizada con la ubicación actual de ellos.
Foreign agent FA: router en la red visitada por el nodo móvil. Cumple las funcio-
nes de default gateway del nodo móvil mientras permanece en dicha red. Establece
un túnel hacia el home agent para hacer llegar el tráfico destinado hacia el nodo
móvil.
Correspondent node CN : cualquier tipo de nodo que se comunica con el cliente
móvil.
A grandes rasgos, MIP asigna una dirección home-address (HoA) al nodo móvil
a través de su home agent. Esta dirección es mantenida durante toda la sesión de
comunicación por lo que el terminal móvil es alcanzable a través de ella. Cada vez que
el nodo cambia su punto de conexión, se le asigna una dirección dinámica care-of-address
(CoA) la cual puede ser dada localmente por el foreign agent.
MIP establece en primer lugar el descubrimiento del agente Mobile IP por parte del
nodo. Luego existe un proceso de registro y autentificación AAA asociado. Finalmente
se establecen los túneles y bindings entre el home y el foreign agent para redireccionar
los paquetes dirigidos hacia el terminal móvil.
Funcionamiento MIPv4 sin autentificación AAA
Descubrimiento agente Mobile IPv4
Cada vez que un nodo móvil se conecta a la red MIP, debe conocer su dirección
IP local y su agente móvil. Ası́, el host sabe si se encuentra en su home network o
en alguna otra red externa. MIPv4 establece dos formas para conocer la información
anterior. La primera es que el terminal móvil reciba anuncios desde la red mientras que
la segunda consiste en que el mismo nodo envı́e solicitudes de agente MIPv4.
Registro Mobile IPv4
Estando el nodo móvil conectado a una foreign network, envı́a un requerimiento de

registro RRQ para hacer uso del foreign agent, registrar la CoA con el home agent,
renovar un registro que está a punto de expirar o des-registrarse. Si el nodo móvil se
registra a través del foreing agent, éste último actúa como un punto de conexión hacia
el home agent. Una vez que se envı́a el RRQ, el home agent envı́a una respuesta al
requerimiento RRP. La figura 2.2 ilustra ese proceso.
11
Foreign Agent Home Agent

192.168.1.254 10.1.1.254
Mobile Node Visited Network Home Network

192.168.1.0/24 10.1.1.0/16
Registration Request (RRQ)

Registration Request (RRQ)
Registration Reply (RRP)

Registration Reply (RRP)
Figura 2.2: Registro MIPv4.
Túneles, binding y envı́os de datagramas Mobile IPv4
Para que el terminal móvil pueda recibir paquetes desde el nodo correspondiente, un
proceso de encapsulamiento es necesario entre la CoA y el home agent. Esta encapsula-
ción puede ser: IP dentro de IP, encapsulación de ruteo genérico (GRE) o encapsulación
mı́nima. Por su parte el nodo móvil envı́a paquetes a través de su default gateway. Si se
usa la CoA del foreign agent, el default gateway puede ser la dirección CoA del foreign
agent o puede ser seleccionada desde una lista provista en los mensajes de anuncios que
ha enviado previamente el agente móvil. Si se está usando la dirección CoA, el default
gateway se selecciona sólo desde la lista provista en los mensajes de anuncios del agente
móvil siempre y cuando el prefijo de red del router seleccionado se ajuste al prefijo de
red del CoA del nodo móvil.
Tunneling y reverse tunneling
El proceso de tunneling establecido entre la CoA y el home agent es unidireccional

por defecto puesto que cuando el nodo móvil envı́a paquetes hacia el nodo corres-
pondiente lo hace directamente y no a través del home agent, estableciéndose ası́ un
“ruteo triangular”. Este proceso resulta ineficiente puesto que existen otros elementos
de la red que podrı́an descartar los paquetes dirigidos hacia el home agent por el nodo
correspondiente.
El reverse tunneling fue estandarizado para resolver el ruteo triangular en MIPv4.
En este caso, el tráfico es forzado a ser ruteado de manera simétrica, tal como muestran
las figuras 2.3 y 2.4.
12
Home Network
10.1.0.0/16
Home Agent
10.1.1.254
Co
rre
oA
en t to
sp o
nde
tC
Ag en
nt
No
gn Ag
de
to
Ho
rei e
me
Fo Hom
Ag
ent
Mobile Node to
Correspondent Node
Mobile Node Correspondent Node
Home Address 10.1.1.1 Foreign Network Local Network 172.16.1.1
192.168.1.0/24 Foreign Agent
192.168.1.254
Figura 2.3: Ruteo triangular en MIPv4.
Home Network
10.1.0.0/16
Home Agent
10.1.1.254
Co
rr
oA
e n t to
esp
Ho ond
t
tC
ent
en
Ag en
me No
Ag
Ag
gn Ag
ent de
to to
Ho
me
rei e
Co me
Fo Hom
rre Ag
sp o
Ho
nde ent
nt
to
No
de
FA
Mobile Node to FA
Mobile Node Correspondent Node

Home Address 10.1.1.1 Foreign Network Local Network 172.16.1.1
192.168.1.0/24 Foreign Agent
192.168.1.254
Figura 2.4: Reverse tunneling MIPv4.
Relación entre MIPv4 y capa de enlace de datos
En el caso que el nodo móvil y su host comunicante se encuentren en la home net-

work, se hará uso del protocolo ARP para poder entregar los paquetes. El problema
surge cuando el nodo móvil cambia su punto de conexión a otra red y el host comunican-
te, haciendo uso de su tabla cache ARP, sigue creyendo que el nodo móvil es alcanzable
a través de su dirección fı́sica. En este caso la comunicación falla.
13
Para evitar el problema anterior, las siguientes reglas deben ser seguidas por los
agentes y nodos móviles:
Un nodo móvil no debe entregar mensajes broadcast ARP mientras se en-

cuentre lejos de su home network.
El foreign agent no debe entregar mensajes broadcast ARP para determi-
nar la dirección fı́sica del nodo móvil sino que la debe obtener a través del
mensaje RRQ o la solicitación del agente móvil.
La tabla cache ARP del foreign agent no debe superar el tiempo de vida
RRP.
Si el nodo móvil está lejos de su home network, el home agent debe usar
Proxy ARP messages para replicar mensajes ARP enviados por los nodos
correspondientes.
Si el nodo móvil cambia su punto de conexión, el home agent envı́a un
mensaje ARP para actualizar a los nodos locales. De esta forma los nodos
locales asocian la dirección de la capa de enlace de datos con la dirección IP
del home agent.
Funcionamiento MIPv6
MIPv6 funciona de manera similar a MIPv4 pero aprovecha las ventajas de IPv6.
Las principales diferencias entre ambos protocolos es que MIPv6 no requiere de un
foreign agent, ni de encapsulamiento IP dentro de IP (utiliza el encabezado de ruteo
de IPv6) y tampoco de reglas para interactuar sin error con la capa 2 ya que usa IP
neighbor discovery en vez de ARP.
IPv6 neighbor discovery
MIPv6 permite descubrir la dirección de enlace de datos de los nodos ubicados en

una misma red ası́ como también el default gateway a través de IPv6 neighbor discovery.
Este último funciona sobre cualquier tecnologı́a de enlace de datos. Cada vez que el nodo
móvil cambia su punto de conexión, se registra con el home agent quien usa un proxy
neighbor discovery para avisarles a los nodos de la home network que el tráfico hacia el
nodo móvil debe ser enviado al home agent.
Modo de optimización de ruta
MIPv6 no fuerza al tráfico de paquetes a pasar por el home agent optimizando

ası́ el proceso de ruteo (el nodo correspondiente debe soportar MIPv6 también). Ma-
peando la home address del nodo móvil con su CoA, los paquetes originados en el nodo
correspondiente son ruteados directamente hacia la CoA.
14
Registro Mobile IPv6 sin AAA
El proceso a través del cual el nodo móvil obtiene la información necesaria para
registrarse con el home agent es conocido como Bootstrapping. Esta información es
básicamente la dirección IPv6, la dirección del home agent y la asociación de seguridad
con este último (lo cual debe hacerse integrando las funciones AAA). Dentro de las
propuestas que buscan facilitar el proceso de bootstrapping se encuentran:
DHCPv6 Dynamic Host Configuration Protocol

IEEE802.1x
PANA Protocol for carrying Authentication Network Access
Implementación de Mobile IPv6
Actualmente no existen grandes despliegues del protocolo puesto que su arquitectura

se encuentra basada en IPv6, sin embargo se destaca su estandarización a lo largo de
diversas organizaciones tales como 3GPP2 y WiMAX Forum NWG. En este último la
arquitectura soporta tanto Client Mobile IP CMIP y Proxy Mobile IP PMIP definiendo
las siguientes entidades: router de acceso, el cual corresponde al Gateway de acceso a
la red en una red MIPv6 WiMAX; home agent, encargado de mantener la sesión del
nodo móvil; y el servidor AAA.
2.3.1.2. Movilidad IP basada en la red
El enfoque basado en la red corresponde a una nueva alternativa para manejar la

movilidad. En este caso el protocolo a cargo no involucra al terminal móvil y a la vez
le permite mantener la misma dirección IP entre las distintas redes. Un ejemplo de
esto es Proxy Mobile IP, tanto en v4 como v6, para soportar movilidad en un ambiente
localizado basándose en la red.
Protocolo Proxy Mobile IP
Basándose en MIP, PMIP fue pensado para que la red mantuviese un tracking del
nodo móvil, con una dirección IP fija, dentro de un dominio de movilidad localizada
conocido como LMD Localized Mobility Domain. Para lograr esto, se definieron nuevos
“agentes” correspondientes a nodos en la red que advierten la presencia del nodo móvil.
Entre ellos destacan:
15
Entrada de acceso móvil MAG Mobile Access Gateway:

Generalmente el router de acceso para el nodo móvil. Se encarga de seguirle la
pista al host en el dominio local. Dentro de un LMD pueden existir múltiples
MAG.
Anclaje para Movilidad local LMA Local Mobility Anchor :

Corresponde a un punto de anclaje para las direcciones asignadas a los nodos
móviles. Todos los paquetes conteniendo como destino dichas direcciones, son
ruteadas hacia el LMA. El LMA provee la función del home agent en PMIP.
Funcionamiento de PMIP
El nodo móvil accede a la red PMIP a través de un MAG. La figura 2.5 ilustra la
señalización para crear el túnel PMIP en un dominio simple como el de la figura 2.6.
En ésta se establece un intercambio de mensajes PBU (Proxy Binding Update)/ PBA
(Proxy Binding Ack) entre nodos del dominio PMIP sin involucrar al cliente móvil en
la señalización.
MN CN
MAG 1 MAG 2 LMA
Solicitación router
PBU (MN-ID, MAG1)
PBA (Mobile Prefix)

Anuncio router
Configuración
dirección IP
TÚNEL PMIP
Solicitación router
PBU (MN-ID, MAG2)
PBA (Mobile Prefix)

Anuncio router
Retención
dirección IP
NUEVO TÚNEL PMIP
Figura 2.5: Señalización registro en Proxy Mobile IP.
16
LMA
MAG 1 MAG 2
MN
Figura 2.6: Dominio Proxy Mobile IP.
Escenarios de Despliegue PMIP
Dentro de los escenarios de despliegue de PMIP se encuentran:
Campus con redes basadas en WLAN.

Redes avanzadas 3G/4G: En este caso la principal ventaja radica en la re-
ducción de costos y manejos de la red en equipos que soporten la tecnologı́a;
una extensión más simple de soporte de movilidad para otras tecnologı́as; y
una integración más fácil con otras redes.
2.3.1.3. Diferencias entre la movilidad IP basada en el host y basada en la

red
En la arquitectura de PMIP, se establece el LMA como una entidad local que en

la mayorı́a de los casos presenta un alto rendimiento en términos de latencia. Com-
parándolo con el home agent, las actualizaciones hacia el LMA suelen presentar menor
tiempo, especialmente cuando el home agent se ubica muy lejos del nodo móvil. Por otro
lado el protocolo PMIP tiene un costo de señalización más bajo en el establecimiento
del servicio de movilidad en comparación con MIP. Adicionando a esto último, PMIP
no requiere software especializado en el cliente móvil. Una comparación más detallada
puede encontrarse en la tabla 2.1:
17
Aspectos MIPv4 MIPv6 PMIP

Alcance Movilidad Global Global Global/Local
Manejo Movilidad Basado en el host Basado en el host Basado en la red
Modificación nodo móvil Sı́ Sı́ No
Versión IP soportada IPv4 IPv4/v6 IPv4/v6
Optimización ruta No Sı́ No
Latencia transferencia Moderada Moderada Buena
Tabla 2.1: Comparación protocolo MIP y PMIP.
2.3.2. Movilidad a nivel de Transporte
El manejo de movilidad en la capa de transporte provee diversos beneficios entre los

cuales se destacan: optimización del ruteo evitando la triangulación del tráfico; ausencia
de problemas con los mecanismos tı́picos de seguridad, por ejemplo firewalls; capacidad
de pausar transmisiones durante desconexiones temporales; y la capacidad de utilizar
un único mecanismo de optimización de movilidad para diferentes flujos desde el mismo
nodo móvil.
La movilidad manejada desde las capas inferiores, por ejemplo usando MIP, conlleva
una lenta adaptación de la capa de transporte frente a cambios en la red. TCP por
ejemplo, se adapta de manera paulatina a los cambios inherentes que se presentan
cuando los nodos cambian sus puntos de conexiones a la red (abruptos cambios de
ancho de banda, delay, packet loss). El cambio de conexión fı́sica del nodo, puede
gatillar reacciones en el control de la ventana puesto que el packet loss es interpretado
como congestión de la red generándose ineficiencias en la transmisión.
La resolución del problema anterior, presente principalmente en ambientes wireless,
ha motivado a mejorar la capa de enlace de datos. Dentro de las propuestas se destacan
el establecimiento rápido de conexión a nivel de capa 2, técnicas de retransmisión en
la capa de enlace transparentando el delay en nivel TCP y soluciones IP multicast.
Adicionalmente se propone que exista un mecanismo de comunicación entre las capas
más bajas y TCP de tal forma que “le avisen” sobre cambios en la conectividad o fallas
wireless.
Aspectos a considerar en el manejo de movilidad desde la capa de transporte o
sesión comprenden la reconfiguración del host en su nueva red, por ejemplo DHCP;
asegurar alcanzabilidad para nuevas conexiones, por ejemplo DNS; y actualización de
las conexiones existentes haciendo rebinding de éstas a la nueva dirección IP. Dentro
de las técnicas propuestas se destacan SCTP, MPTCP y MSOCKS.
18
Stream Control Transmission Protocol SCTP
Corresponde a un protocolo de la capa de transporte de propósito general similar

a TCP pero con algunas diferencias importantes. Dentro de los servicios que provee se
destacan:
Conexiones punto a punto.
Servicios orientados a la conexión.
Entrega confiable de datos.
Mecanismos de control de congestión.
Recuperación de packet loss y adaptación de la tasa de transmisión de datos.
SCTP provee multistreaming, donde cada stream entre dos nodos es tratado de
manera independiente; y multihoming, que permite que una sesión persista usando
múltiples direcciones IP. Estas últimas pueden ser comunicadas al inicio de la sesión o
a través de actualizaciones de sesión. La figura 2.7 ilustra la estructura del protocolo
dentro del stack TCP/IP.
Cliente Servidor
Aplicación App App App App App App Aplicación
Sesión Sesión
Transporte SCTP Asociación SCTP SCTP Transporte
Red IP 1 IP 2 IP Red
Enlace Datos INT 1 INT 2 INT Enlace Datos
Camino de respaldo
Camino primario
Figura 2.7: Estructura protocolo SCTP.
19
En el contexto SCTP se definen las llamadas asociaciones que representan un set de

direcciones IP y puertos en cada uno de los nodos. Los paquetes intercambiados en una
asociación se denominan chunks. Cada asociación a su vez pasa por diferentes estados
conocidos como iniciación, transferencia de datos y corte.
En el caso del proceso de iniciación, se establecen las listas de direcciones IP que
serán parte de la asociación, número de secuencia de transmisión inicial, tag de iniciación
en cada paquete SCTP entrante, entre otros.
La transferencia de datos utiliza un esquema parecido al de TCP pero haciendo
uso de dos números de secuencia: número de secuencia de transmisión y número de
secuencia de stream. El proceso de multistreaming por su parte, permite mantener un
mecanismo de control de congestión más robusto al poder priorizar tipos de streams
especı́ficos dentro de una misma sesión, mientras que la caracterı́stica de multihoming
provee robustez en el transporte al permitir múltiples direcciones IP. Por último, el
proceso de corte o shutdown es realizado una vez que SCTP ha confirmado que ambos
extremos han recibido todos los chunks.
La propuesta de movilidad desde la capa de transporte propone usar una versión
modificada de SCTP denominada Mobile SCTP. Esta última hace uso de una extensión
de SCTP conocida como ADDIP definida a través de la reconfiguración dinámica de la
dirección IP.
Multipath TCP MPTCP
MPTCP es una modificación de TCP parecida a SCTP. Dentro de las extensiones del
protocolo se permite el uso de múltiples caminos para sesiones TCP. Esto último otorga
beneficios como: interconexión con la infraestructura existente del internet; estabilidad
en los caminos; y transparencia a los nodos de la red (al estilo NAT).
Al igual que TCP, MPTCP hace uso del principio de resource pooling a través
del cual los recursos fı́sicos se muestran como un único recurso lógico. Ejemplos de
aquello son el protocolo de control de agregación de link (LACP), que permite múltiples
interfaces fı́sicas como una única interfaz lógica; y el protocolo de ingenierı́a de tráfico
MPLS-TE, quien rutea tráfico a lo largo de múltiples caminos fı́sicos basándose en las
condiciones de la red y tráfico.
MPTCP propone separar el transporte en funciones orientadas a la aplicación y
funciones orientadas a la red. De esta forma, se puede controlar de manera simultánea
múltiples sesiones TCP y además distribuir información desde las capas superiores a las
sesiones TCP. La figura 2.8 ilustra la estructura del protocolo dentro del stack TCP/IP.
20
Cliente Servidor
MP-TCP MP-TCP
MP-TCP Sesión MPTCP MPTCP
Red IP1 IP2 IP1 IP2 Red
Enlace Datos INT1 INT2 INT1 INT2 Enlace Datos
Camino2
Camino1
Figura 2.8: Estructura protocolo MPTCP.
MSOCK: Movilidad para MPTCP
El protocolo MPTCP se presenta como posible solución al problema de movilidad

en las redes móviles de próxima generación. Sin embargo, al igual que STCP requiere
de mejoras en su diseño. Dentro de los enfoques que se han desarrollado para soportar
movilidad se destaca MSOCK el cual proporciona un esquema para la movilidad en
la capa de transporte. La arquitectura de MSOCK se conoce como Transport Layer
Mobility (TLM) y permite el uso simultáneo de múltiples interfaces en un nodo móvil.
Este último a su vez puede decidir por cual interfaz transmitir los flujos.
TLM se basa principalmente en el esquema proxy. La idea global es tener un nodo
intermedio llamado proxy entre el nodo móvil y el destino. Este proxy media la comu-
nicación entre ambos y provee distintos servicios dependiendo de la capa en la que se
encuentra.
TLM utiliza un proxy en la capa de transporte el cual soporta movilidad a través de
un mecanismo de migración de conexión entre el nodo móvil y el proxy hacia una nueva
interfaz manteniendo la conexión con el destino, siendo este último fijo. Adicionalmente,
el nodo móvil puede utilizar simultáneamente dos interfaces diferentes controlando por
cual interfaz mandar distintos tráficos.
21
Dentro de las principales objeciones a la arquitectura TLM es que al presentar un

proxy fijo, TLM no es adecuado para movilidad en inter-dominios. La figura 2.9 ilustra
la estructura del protocolo dentro del stack TCP/IP
Cliente Proxy Servidor
MSOCKET MSOCKET
TCP1
Librerı́a Librerı́a
Transporte TCP1 TCP1 TCP2 TCP1 Transporte
Red IP1 IP1 IP1 Red
Camino1
Figura 2.9: Arquitectura TLM.
2.3.3. Movilidad en la capa de sesión
El nivel de sesión permite la movilidad de manera simple debido al poco uso de

esta capa. SLM hace uso del “Manejo de Sesión SM” el cual provee control de conexión
entre la capa de aplicación y la interfaz de red.
Este enfoque incorpora una nueva entidad conocida como ULS User Location Server
la cual guarda los mensajes de actualización de locación enviados por el nodo móvil.
Los nodos comunicantes pueden conocer el paradero del cliente móvil preguntándole al
servidor sobre la ubicación de algún terminal que deseen contactar. Por ejemplo, ULS
podrı́a ser una extensión de servidores DNS y DNS dinámicos pueden ser utilizados
para actualizar la locación.
Dentro de las desventajas que puede presentar este enfoque es el delay que pue-
de existir en la actualización del ULS haciendo que el soporte de movilidad resulte
ineficiente en algunas aplicaciones sensibles al tiempo.
22
2.3.4. Movilidad en la capa de aplicación
Resolver la movilidad desde la capa de aplicación centra su atención no en el dis-

positivo en sı́ sino en el usuario o subscriptor del servicio. La movilidad es brindada
a nivel usuario, generando incluso movilidad a nivel multi-dispositivo. El protocolo de
la capa de aplicación mayormente usado corresponde a SIP Session Initation Proto-
col. Este último fue diseñado para establecer, mantener y terminar sesiones multimedia
[9, 10, 20].
Session Initiation Protocol SIP
SIP es un protocolo de la capa de aplicación capaz de mantener información sobre

la locación actual y disponibilidad de los usuarios. Dentro de las entidades definidas se
destacan:
User agents: Envı́an y reciben mensajes SIP.
Proxy servers y Redirect servers: Registran las nuevas locaciones de los usuarios.
Location servers: Reciben locaciones actualizadas de los usuarios desde los servi-
dores proxy y redirect.
La movilidad soportada por SIP es a través de las entidades definidas anteriormente.

Una vez que el terminal móvil se mueve desde su red original hacia alguna red externa,
el agente de usuario SIP del nodo móvil envı́a un mensaje de registro hacia el servidor
SIP de la red original. Ası́, cuando algún otro nodo quiera comunicarse con el terminal,
envı́a una invitación para comenzar una sesión SIP con éste y el servidor SIP de la red
original del host móvil responde con la actual locación. De esta forma, se permite que
el nodo correspondiente pueda invitar al terminal móvil a iniciar una sesión SIP.
2.4. Métricas
Existen diversas métricas estandarizadas que caracterizan el rendimiento de una red
IP. A través de ellas, es posible medir parámetros especı́ficos del sistema de tal forma
de aplicarlos a la calidad, performance y confiabilidad en los servicios de entrega de
datos de internet proporcionados por las redes.
Estas mediciones han sido documentadas por el grupo de trabajo de métricas de
rendimiento IP (IP performance metrics working group, IPPM WG) [16], diseñadas
23
para ser utilizadas tanto por operadores de redes como por usuarios finales o grupos de
trabajos independientes.
Las principales métricas se listan a continuación:
Conectividad
Delay y Loss one-way
Delay round-trip
Variación en el delay
Loss patterns
Reordenamiento de paquetes
Capacidad de transporte
Capacidad de ancho de banda
Duplicación de paquetes
2.4.1. Métricas usuales en redes
Dentro de las principales mediciones realizadas en redes, se destacan:
Latencia: Tiempo que le toma a un paquete en recorrer el camino entre el nodo

de origen y destino.
Packet Loss: Tasa de paquetes que no alcanzaron su destino.
Throughput: Tasa a la cual son transferidos los paquetes de un punto a otro.
En el caso del despliegue de redes que soporten algún mecanismo de mobile IP,
dentro de las métricas utilizadas para analizar el rendimiento de la red, se encuentran:
IP handoff latency
Mensajes de control señalización
Overhead de señalización
24
2.4.2. Métricas para dispositivos de red
El rendimiento de una red IP depende directamente de la performance de los dispo-

sitivos que conforman su infraestructura [6]. Estos dispositivos reciben y procesan los
paquetes constantemente a través de interfaces fı́sicas por lo que resulta muy impor-
tante a la hora de implementar una red tener en consideraciones las tasas a las cuales
estas acciones son llevadas a cabo. Las métricas que definen el comportamiento de los
dispositivos de red pueden ser resumidas según:
Conexiones por segundo (c/s)

Tasa a la cual un dispositivo puede establecer parámetros para nuevas conexio-
nes. Esto se relaciona directamente con la velocidad de procesamiento (CPU),
memoria, arquitectura, eficiencia en el stack TCP/IP.
Máximo número de conexiones simultáneas (mcc)

Corresponde al número total de conexiones que un dispositivo puede mantener
simultáneamente. Este valor se relaciona directamente con la cantidad de memoria
que se ha dispuesto para esto.
Transacciones por segundo (t/s)

Corresponde al número de ciclos terminados, relacionados con una aplicación en
especı́fico, por segundo. Este tipo de medida es muy común en el diseño de base de
datos mientras que en el área de redes IP es utilizado en dispositivos que trabajan
con procesos más complejos.
2.4.3. Métricas de performance de señalización de sistemas
Hoy en dı́a, los sistemas de telecomunicaciones involucran numerosos dispositivos

de red, bases de datos, control de sistemas, servidores AAA, sistemas de billing, entre
otros. Sus grandes tamaños, han llevado a separar en 3 unidades funcionales el manejo
de las telecomunicaciones [19]. Estas unidades corresponden a los planos de usuario,
manejo y control.
El plano de control es el encargado de establecer, mantener y liberar las conexiones
entre dos hosts. Funciones tales como entablar una sesión, preparar sistema de charging
y accounting, ejecutar handoff y la asignación de recursos, deben ser llevadas a cabo
dentro de plazos temporales fijos. Las señalizaciones utilizadas en el sistema están aco-
tadas a dichos plazos por lo que su performance se ve afectada por el acceso a las bases
de datos, autentificación y comunicaciones entre nodos de red.
25
Dentro de las herramientas usadas para estudiar el rendimiento de sistemas, se

encuentra el benchmarking, el cual es una técnica que cuantifica algún aspecto fun-
damental en la performance ya sea a nivel de hardware o software a través de un
set de programas. El rendimiento de las señalizaciones en telecomunicaciones puede
ser estudiado a través de SIPstone, IMS/NGN Performance Benchmark, CommBench,
NpBench, NetBench, entre otras [19]. Las siguientes secciones muestran aplicaciones
prácticas en el campo de las métricas de performance de señalizaciones.
2.4.3.1. Aplicaciones de benchmarking en NGN/IMS
IP Multimedia Subsystem (IMS) es una arquitectura diseñada por 3GPP para la

entrega de servicios multimedia basados en IP de manera confiable, segura y controlable.
Corresponde a un enfoque unificado de la industria de las telecomunicaciones hacia el
despliegue de redes all-IP, mezclando los paradigmas y tecnologı́as IP, con las redes
celulares y fijas [22].
IMS/NGN Performance Benchmark es el estándar en desarrollo del comité técni-
co TISPAN de ETSI. Su objetivo es mejorar la toma de decisiones en el despliegue
IMS/NGN [19] a través de la aplicación de tests para determinar el comportamiento
del sistema frente al incremento de carga. Dentro de las métricas especificadas para los
test de benchmarking se destacan:
Intento de escenarios por segundo (Scenario Attempts Per Second, SAPS)

Tasa promedio con la cual los escenarios, definidos a través del comportamiento
de los usuarios individuales interactuando con el sistema, son intentados.
Tiempo de respuesta por transacción (TRT)
Tiempo transcurrido desde el primer mensaje enviado para iniciar la transacción
hasta que el mensaje final de la transacción se recibe.
Razón de Uso CPU (CPU)
Porcentaje de uso de la CPU total disponible.
Razón de Uso Memoria (MEM)
Porcentaje de uso de la memoria total disponible.
Tasa de Retransmisión (RETR)
Aplicable al transporte UDP. Es la razón entre el número de retransmisiones y el
número de mensajes enviados.
Escenarios simultáneos (SIMS)
Número de escenarios activos al mismo tiempo.
26
Porcentaje de escenarios manejados inadecuadamente ( %IHS)

Porcentaje de escenarios fallidos respecto al número total de escenarios intentados.
Bajo carga nominal se establece una cota máxima de 1 %IHS y bajo sobrecarga
un máximo de 10 %IHS.
2.4.3.2. Aplicaciones en servicios AAA
Los servicios AAA son los mecanismos de autentificación, autorización y tarificación

que permiten a los usuarios acceder a las redes subscritas. Ejemplos del servicio se
encuentran en el acceso a LTE, tecnologı́a de red celular de próxima generación, o las
redes WLAN.
En el caso de LTE, el registro y autentificación es a través del nodo definido para el
manejo de movilidad MME, quien realiza un intercambio de mensajes de señalización
entre la base de datos central de subscriptores HSS siguiendo el protocolo de autenti-
ficación y acuerdo de clave AKA. La rapidez con que el usuario es registrado depende
del acceso a la base de datos alocada en el HSS. La figura 2.10 ilustra el proceso.
Access
Network
HSS
MME
Attach Request (IMSI)
Authentication Request (IMSI)
Authentication Response (AV’s)

AV Selec-
tion (RAND,
XRES, CK,
IK, AUTN)
Authenticate Request (RAND, AUTN)
Verify AUTN
Compute
RES
Authentication Response (RES)
Compute CK, IK Compare RES,XRES
Figura 2.10: Registro y autentificación en LTE.
27
El acceso a redes WLAN es realizado con uso de servidores RADIUS los cuales
proveen un modelo cliente/servidor capaz de brindar servicios AAA. Comúnmente es
utilizado por los ISPs y empresas para el acceso a Internet y sus redes internas (redes
wireless, servicios de e-mail, etc) ası́ como también para el manejo de movilidad IP.
RADIUS se basa en autentificación del tipo challenge/response (C/R) y realiza el che-
queo de información del usuario por medio de base de datos o servidores externos tales
como SQL. La figura 2.11 ilustra una tı́pica transacción en el modelo de RADIUS.
RADIUS RADIUS
Client Server
RADIUS: Access-Request -
RADIUS: Access-Accepted
RADIUS: Access-Reject
RADIUS: Access-Challange
Figura 2.11: Autentificación y autorización RADIUS.
Dentro de las métricas caracterı́sticas se destacan el número de transacciones por

segundo, cantidad máxima de conexiones simultáneas que el servidor puede mantener
y la tasa a la cual se establecen las conexiones.
2.5. Herramientas de simulación de redes
2.5.1. Consideraciones generales
Las herramientas de simulación de redes corresponden a desarrollos computacionales

que permiten a los diseñadores analizar el comportamiento de sistemas frente a nuevos
protocolos, algoritmos y/o arquitecturas. Su uso es considerado como una alternativa
poderosa y versátil que facilita el estudio de los actuales sistemas de comunicaciones.
Esto último muchas veces no puede realizarse por medio de una implementación real del
sistema debido a restricciones económicas y/o técnicas enfrentadas por el diseñador. A la
fecha, existen diversos software de simulación capaces de ofrecer un ambiente controlado
por el usuario, gracias al establecimiento previo de parámetros, escenarios de pruebas,
entre otros ı́tems.
28
Dentro de los aspectos generales a tomar en cuenta, se debe considerar que la con-
fiabilidad y calidad de los resultados observados vienen de un modelo previo diseñado
del sistema y no del sistema en sı́ mismo. Esto último puede representar una fuerte
desventaja si el modelo no ha considerado los detalles claves del sistema simulado. Por
otro lado, el énfasis del ambiente de simulación será puesto en general en la performance
del modelo más que en la interfaz gráfica (General User Interface, GUI) [26].
En el caso especı́fico del campo de redes de computadores, la técnica más utilizada [2,
13] corresponde a la simulación basada en eventos discretos Discrete-event simulation,
DES. Dentro de esto último, se destaca la propiedad de que el estado del modelo de
simulación solo cambia de manera discreta en el tiempo, nombrándose como eventos.
En la siguiente sección se especifica de manera más detallada el concepto de DES.
2.5.2. DES
2.5.2.1. Elementos comunes en sistemas DES
Si bien, no existen modelos estandarizados para los simuladores de eventos discretos,

los elementos comunes a los sistemas basados en DES [13] pueden resumirse según las
siguientes definiciones:
Entidad: Abstracción de un sujeto u objeto particular de interés. Ejemplo: Paquete

IP
Sistema: Conjuntos de entidades relacionadas entre sı́. Ejemplo: Red de comuni-

cación
Sistema discreto: Sistema cuyo estado solo cambia de manera discreta. Dicho
cambio es gatillado por un evento. Ejemplo: Enviar/recibir paquetes IP.
2.5.2.2. Principio de funcionamiento
Tal como se ha mencionado, los cambios en el estado del sistema se relacionan

directamente con la ocurrencia de un evento. Estos eventos son guardados como “eventos
anunciados” en una lista de eventos futuros (FEL, future event list). Cada fila de FEL
corresponde a un evento cuya estructura es de la forma (tiempo, tipo) donde tiempo
especifica el momento en que el evento ocurrirá y tipo entrega la naturaleza de éste. En
la medida en que se avanza en la lista, el computador guarda en memoria el estado del
sistema con el fin de progresar con la simulación. La figura 2.12 ilustra el principio de
funcionamiento de DES.
29
t1 t2 ti ti+1 ti+2
Figura 2.12: Principio funcionamiento DES.
2.5.2.3. Algoritmo sistemas DES
La base por la cual se rigen los sistemas basados en DES es conocido como event-
scheduling time-advance algorithm. Este proceso depende de FEL y consta de tres
partes principales: inicialización, procesamiento evento, loop y salida. La figura 2.13
ilustra el algoritmo utilizado en DES.
Start
Initialization
Select next event
Event routine 1 Event routine 2 Event routine 3
No
Terminate?
Yes
Output
End
Figura 2.13: Event-Scheduling Time-Advance Algorithm.
2.5.3. Simulaciones y modelos de sistemas de comunicaciones
El modelo del sistema en estudio corresponde a una abstracción de la realidad que

busca representar de la mejor manera los aspectos más relevantes del análisis. Muchas
veces no se cuenta con datos reales del sistema a simular [13], por lo que no es posible
30
validar la simulación. Frente a esto, es necesario contar con un buen modelo capaz de
entregar resultados confiables. Se plantean los siguientes pasos para modelar de manera
exitosa un sistema:
Formulación problema y definición modelo.
Elección de métricas, factores y niveles.
Elección de datos a recopilar.
Elección ambiente idóneo de simulación, implementación modelo y verificación.
Validación y análisis de sensibilidad.
Experimentación, análisis y presentación resultados.
2.5.4. Software de simulación de redes disponibles
Dentro de los software basados en DES, se destacan tanto de origen comercial como
de código libre. La siguiente tabla muestra los simuladores revisados durante el proceso
de selección del ambiente de simulación y descritos en el capı́tulo de Desarrollo.
Software Versión Sistema operativo Origen

NCTuns 6.0 Linux, Fedora 12 Código libre
Omnet++ 4.1 Linux, Ubuntu 11.04 Código libre
ns3 3.12 Linux, Ubuntu 11.04 Código libre
OPNET Modeler 14.5 Windows 7 Comercial
Tabla 2.2: Software de simulación de redes.
31
Capı́tulo 3
Desarrollo
3.1. Selección de software simulación de redes

El proceso de selección del software para desarrollar este trabajo se hace a través de
la revisión de diferentes programas de simulación disponibles. La elección se basa princi-
palmente en un análisis cualitativo de cada herramienta entre las cuales se encuentran:
ns-3, Omnet++, NCTuns y OPNET Modeler.
3.1.1. ns-3
ns-3 corresponde a un simulador de red de eventos discretos de acceso libre y gra-

tuito. Sus principales caracterı́sticas son listadas a continuación.
Desarrollado y distribuido completamente en C++. Su distribución incluye algu-

nos bindings en Phyton para la mayorı́a de las API disponibles.
ns-3 usa WAF como el build system.
Programas de simulación son ejecutables C++ o Python Scripts.
Actualización de modelos cada 3 meses por parte de comunidad.
Soporta simulación con sistemas reales (sockets, device driver interfaces).
Soporte para tracing, logging y estadı́sticas computacionales en resultados de la

simulación.
Extensa documentación API usa Doxigen.
32
CAPÍTULO 3. DESARROLLO
No tiene GUI, pero se puede instalar NetAnim, el cual puede animar una simula-
ción usando trace file offline (modo básico) o mientras la simulación está corriendo
(modo avanzado). Este último modo soporta recolección básica estadı́stica.
Módulos destacados en ns-3 1 :
1. Internet (ARP, TCP, UDP, IPv4v6, Global Routing, entre otros).

2. Wi-Fi
3. LTE
La versión con las cuales se estudió el software es la 3.12 dentro de un ambiente Linux
con soporte Ubuntu 11.04. El sitio de descarga es http://www.nsnam.org/ns-3-12/
download/.
3.1.2. NCTuns
NCTuns es simulador y emulador de redes para ambientes wireless móviles. Su

última versión ha sido comercializada bajo el nombre de EstiNet. Sus principales ca-
racterı́sticas se enumeran a continuación:
Usa directamente el protocolo stack de TCP/IP incorporado en Linux de manera

real, facilitando resultados de alta fidelidad.
Soporta distintos programas de aplicación basados en UNIX, por ejemplo una

aplicación UNIX puede ser corrida en un nodo en NCTUns con el fin de ser
testeado previo al lanzamiento.
Soporte para distintas redes y dispositivos. Entre ellos se destacan:
1. Ethernet-based IP con nodos fijos y enlaces P2P (Hubs Ethernet, switches,

routers, hosts).
2. IEEE 802.11 a, b WLAN Modos ad-hoc e insfraestructura (Tarjetas wireless
IEEE 802.11 a, b).
3. Redes celulares GPRS (Teléfonos GPRS, estaciones BASE, SGSN, GGSN).
4. Redes ópticas.
Soporte para diferentes protocolos:
1. IEEE 802.3 CSMA/CD MAC

1
Mayor información en http://www.nsnam.org/docs/release/3.12/doxygen/modules.html
33
2. IEEE 802.11 a, b, e, p
3. CSMA/CA MAC
4. IP, Mobile IP, RIP, OSPF, UDP, TCP, HTTP, FTP, Telnet
GUI Environment permite:
1. Crear topologı́as de red.

2. Configurar nodos, por ejemplo: establecer protocolos a soportar.
3. Configurar parámetros dentro de protocolos.
4. Graficar datos.
Se revisa la versión 6.0 bajo un ambiente Linux con soporte de Fedora 12.
3.1.3. Omnet++
Omnet++ es una herramienta de simulación de acceso libre y gratuito con área de

aplicación en redes de comunicaciones. No constituye un simulador de red en sı́ puesto
que no incluye ninguna componente especı́fica para redes de computadores, pero hace
uso de diversos frameworks diseñados para tales propósitos destacándose INET, MiXiM
y Castalia. A continuación se resumen sus principales caracterı́sticas.
Se basa en una arquitectura de componentes (módulos) para los modelos. Módulos

son programados en C++ y luego unidos entre sı́ a través del lenguaje NED.
Soporte de Interfaz Gráfica.
Librerı́a del kernel de simulación.
Compilador para lenguaje NED.
OMNet++ IDE basado en la plataforma Eclipse.
GUI para la ejecución de la simulación (Tkenv).
Interfaz de usuario por lı́nea de comandos (Cmdenv).
Soporte de ejecución paralela (MPI based).
Soporte stack TCP/IP (IP, TCP, UDP, PPP, . . . ).
Soporte documentación.
34
Proyectos destacados en OMNet++:
1. INET
2. InetManet
3. Oversim
4. xMIPv6
5. Rease
6. MiXiM
7. MF
8. Castalia
Se revisa la versión 4.1 en ambiente Linux con soporte Ubuntu 11.04. Las siguien-
tes secciones describen de manera más especı́fica dos de los proyectos destacados en
Omnet++ para el desarrollo de redes de comunicación.
3.1.3.1. INET Framework
Corresponde a un framework desarrollado para Omnet++ con aplicaciones en pro-

tocolos de red. Sus principales caracterı́sticas se listan a continuación.
Contiene modelos para distintos protocolos de red del tipo wired y wireless. Entre
ellos se destacan principalmente UDP, TCP, SCTP, IP, IPv6, Ethernet, PPP,
802.11, MPLS, OSPF 2
Extensiones INET Framework.
1. INETMANET: Soporte para redes móviles y ad-hoc.

2. OverSim: Soporte para redes peer-to-peer y overlay.
3. xMIPv6: Soporte para Mobile IPv6 (xMIPv6).
4. VoIP Tool: Soporte para la generación de tráfico VoIP creando streams de
paquetes VoIP de manera realista.
5. HTTP Tools: Soporte para simulación de tráfico HTTP.
La versión estudiada corresponde a INET 20110225 para OMNeT++ 4.2 / 4.1.

2
Mayor detalle protocolos desarrollados para INET pueden verse en el enlace http://inet.
omnetpp.org/index.php?n=Main.Status
35
3.1.3.2. MiXiM Project
MiXiM es un framework para Omnet++ que incorpora modelos para redes wireless
fijas y móviles tales como wireless sensor networks, body area networks, ad-hoc net-
works, vehicular networks, entre otras. Adicionalmente ofrece modelos en detalles de
propagación de ondas de radio, interferencia, consumo de potencia transmisor de radio
y protocolos MAC wireless, por ejemplo Zigbee.
3.1.4. OPNET Modeler
OPNET Modeler es uno de los simuladores comerciales de redes más populares

en investigación y desarrollo. Particularmente es utilizado para el estudio de redes de
comunicaciones, dispositivos, protocolos y aplicaciones. A grandes rasgos posee tres
funciones principales: modelación, simulación y análisis. Para la modelación, provee
una poderosa interfaz gráfica de soporte para sus usuarios donde se pueden construir
topologı́as de red y sus entidades desde la capa fı́sica hasta la de aplicación. Para la
simulación, provee 4 tipos de tecnologı́as, entre las que se incluye DES. Para el análisis,
los resultados de la simulación y datos, pueden ser analizados y desplegados fácilmente
usando gráficas, estadı́sticas y animaciones incorporadas en el software. Dentro de sus
rasgos principales se destacan 3 :
Simulación rápida DES.
Variedad de librerı́as con incorporación de su código fuente.
Modelación orientada a objetos.
Ambiente de modelación jerárquica (red, nodos, modelos, procesos basados en

FSM).
Soporte de simulación wireless escalable y customizable.
GUI 32, 64- bit con integración de debugging y análisis.
Kernel de simulación paralela 32, 64-bit.
Interfaz abierta para la integración de librerı́as y simuladores externos.
Dentro de las distintas librerı́as que incorpora OPNET Modeler, se muestran en la

tabla 3.1 y en el anexo A aquellas más relevantes para el desarrollo del trabajo.
3
Mayor detalle en el sitio oficial OPNET http://www.opnet.com/solutions/network_rd/
modeler.html
36
Wireless
Standard/Specialized Models Contributed
Wireless LAN (802.11a,b,e,g,n) WiMAX (802.16) Mesh Mode
WiMAX (802.16-2004 and 802.16e-2005) WiMedia (802.15.3b)
LTE (model development consortium) GPRS
UMTS GSM
SMART MAC Bluetooth
MAC
TDMA Ad hoc SMART MAC
Zibgee (802.15.4) AMPS
CDPD
Gilbert-Elliot BER
LSFM
MBMS-Enabled UMTS Network
Arbitrary trajectories Mobility Pattern Generators
Mobility HLA mobility updates Random Direction
Random Waypoint
Tabla 3.1: Librerı́a disponible para modelos wireless en OPNET Modeler.
3.2. Descripción de OPNET Modeler
3.2.1. Presentación software
OPNET Modeler es un software comercial

de OPNET Technologies Inc. utilizado para la
modelación y simulación de redes de comuni-
caciones, dispositivos, protocolos y aplicacio-
nes. Dentro de su estructura incluye distin-
tas herramientas para recolección de datos y
análisis posterior.
Figura 3.1: Pantalla de inicio OPNET

Modeler v.14.5.
37
3.2.2. Arquitectura de OPNET Modeler
OPNET Modeler soporta la especificación de modelos por medio de los llamados

Editores. Estos últimos son organizados de manera jerárquica con el fin de facilitar
la comprensión de la red. Principalmente se destaca el Editor de Proyectos (Project
Editor ), donde se definen los modelos de redes y nodos a utilizar además de simulaciones
básicas y análisis de resultados; el Editor de Nodos (Node Editor ), donde se especifica
la arquitectura interna de los nodos a través de módulos con procesos de modelos
integrados; y finalmente el Editor de Procesos (Process Editor ), donde se modela el
comportamiento de los procesos dentro de los módulos.
Adicionalmente OPNET Modeler ofrece más editores entre los cuales se destaca el
Editor de Modelo de Enlace (Link Model Editor ), donde se pueden crear, editar y ver
modelos de enlaces; el Editor de Formato de Paquetes (Packet Format Editor ), donde
se diseña la estructura interna de los paquetes transitando en la red; y el Editor de
Control de Información de Interfaz (ICI Editor ), donde se especifica la estructura de
paquetes utilizados por el software para comunicar información de control entre los
procesos.
subnet
Network
Domain pt-pt links bus links
nodes & taps subnets
Node
Domain
modules
statwires,
...)
( ...)
(
streams &
logical associations
subqueues receiver/transmiter channels

Process
Domain
states transitions
Figura 3.2: Jerarquı́a de objetos en OPNET Modeler.
OPNET Modeler utiliza el concepto de objeto para representar de manera única

cada componente de la estructura del sistema. Ejemplos de objetos pueden ser rou-
ters, servidores, clientes y enlaces. Estos objetos pueden ser caracterizados a través
de variables privadas o públicas. En el caso de que sean públicas, estas caracterı́sticas
son denominadas atributos y permiten que el usuario pueda personalizar el objeto de
acuerdo a sus necesidades. Similarmente, descomposiciones de un objeto (por ejemplo
un nodo del tipo router) pueden ser también objetos (por ejemplo el módulo que maneja
38
el ruteo IP dentro del router). La figura 3.2 ilustra el comportamiento jerárquico de los
objetos en OPNET Modeler.
3.2.3. Dominio a nivel de red
Dentro del dominio de red, se ubica el editor de proyecto a través del cual el usuario
puede definir la topologı́a de la red de comunicaciones que desea estudiar. Los objetos
en la red son referidos como nodos los cuales pueden ser obtenidos desde la librerı́a
disponible conocida como Object Pallete. Ésta última se encuentra provista de objetos
integrados por los mismos desarrolladores del software o por objetos diseñados directa-
mente por el usuario en cuestión. En este trabajo se hace uso de entidades relacionadas
con las arquitecturas UMTS y WLAN, ası́ como también de objetos creados a partir de
librerı́as de OPNET. El editor de proyectos ofrece además desarrollar el modelo de red
dentro de un contexto geográfico, proveyendo de diferentes locaciones del mundo para
el despliegue de WANs asi como también LANs en áreas dimensionadas. Los nodos se
comunican entre sı́ por medio de enlaces o links provistos por el software.
Figura 3.3: Editor de Proyecto en OPNET Modeler.
3.2.4. Dominio a nivel de nodo
Análogo al caso anterior, dentro de este dominio se encuentra el editor de nodo, que
permite especificar la estructura interna de los dispositivos por medio de los llamados
“módulos”. Estos últimos pueden ser configurados para controlar el comportamiento del
nodo a través de sus atributos. Los módulos se comunican entre sı́ mediante diferentes
conexiones dentro de las cuales se destaca principalmente el flujo de paquetes por medio
39
de los packet streams. La tabla 3.2 ilustra los objetos utilizados para construir un modelo
de nodo.
Representación
Tipo de Objeto Definición
Gráfica
Procesador Objeto programable definido a través de un
modelo de proceso.
Cola Objeto programable que provee funcionalida-
des de encolamiento de paquetes por medio
de subcolas.
Transmisor Permite enviar paquetes desde el nodo hacia
la red por medio de enlaces.
Receptor Permite recibir paquetes desde la red hacia
el nodo por medio de enlaces.
Packet Stream Conecta el puerto de salida del módulo fuente
al puerto de entrada del módulo de destino
con el fin de transmitir paquetes.
Statistic Wire Conecta la estadı́stica de salida del módulo
fuente a la de entrada del módulo de destino
con el fin de transmitir datos numéricos.
Asociación lógica Indica un acople entre módulos. La versión
usada lo soporta únicamente para el par
transmisor-receptor especificando que éstos
están juntos cuando el nodo se conecta a un
enlace.
Esys Module Objeto programable usado para especificar
el comportamiento del módulo definido por
medio de un sistema externo (ESD).
Tabla 3.2: Principales componentes del menú del editor de nodo.
3.2.5. Dominio a nivel de proceso
El editor de proceso permite modelar el comportamiento de los procesadores o colas,

también llamados de manera genérica como QP. El comportamiento de un módulo QP
puede representar distintos procesos tales como protocolos de comunicación (IP, ARP,
TCP, etc), algoritmos de encolamientos, software especializado, entre otros.
Los procesos son asignados a los módulos QP integrados a los nodos de la red. Si un
proceso particular es soportado por un módulo, entonces se genera una instancia de ese
modelo de proceso previamente definido en el editor. De esta forma, es posible que un
40
Figura 3.4: Modelo de estación de trabajo WLAN desarrollada en el editor de nodo.
mismo proceso sea asignado a muchos QP del sistema. Por ejemplo, varias estaciones
de trabajo en la red ejecutando los procesos que definen TCP/IP.
El modelo de un proceso se define a través de múltiples estados conectados entre
sı́. En un comienzo, OPNET genera una lista global de eventos representativa de la
simulación donde todos los módulos QP tienen sus procesos en sus estados iniciales.
La única forma de sacar a los procesos de sus estados iniciales es a través de eventos
agendados para los módulos que los alojan. En otras palabras, la transición entre los
estados que definen al proceso dependerá de la lista de eventos del software. Una vez
que un evento afecta a un proceso, éste último recibe una interrupción, concepto muy
importante en OPNET, que permite ejecutar los códigos asociados al estado en que se
encuentra. Cabe destacar que la ejecución de dichas acciones no representa un avance
en el tiempo de simulación, sino que este avanza en la medida que la lista de eventos
se va ejecutando. Una vez que termina de trabajar, el proceso se bloquea devolviéndole
el control al kernel de simulación que revisa la lista global de eventos de OPNET y
ejecuta los siguientes eventos.
Cada QP puede tener un solo proceso que se inicializa al comienzo de la simulación
y se especifica en el atributo “process model ”del QP. OPNET denomina a este proceso
como el proceso raı́z (root process) el cual a su vez puede invocar a sus procesos hijos
(child process) delegándoles tareas especı́ficas. Un ejemplo de esto es el root process ip
dispatch del módulo IP, que invoca a su child process mobile ip mgr, el cual a su vez
invoca a uno de sus dos child process mobile ip agent o mobile ip mn dependiendo del
caso.
41
Root Process
Primera generación
child process
Segunda generación
child process
Tercera generación
child process
Figura 3.5: Estructura jerárquica de creación de procesos en OPNET.
La generación de un child process es un proceso dinámico dentro de la simulación.

Esto último genera la estructura jerárquica tı́pica con la que trabaja OPNET, ilustrada
en la figura 3.5.
El mecanismo de comunicación entre los procesos se lleva a cabo mediante la Ar-
quitectura de memoria compartida proporcionada por el simulador. Existen diversas
formas de que los procesos compartan información de manera conjunta, entre ellas se
destacan principalmente: Memoria compartida a nivel QP, donde el módulo asigna un
bloque de memoria fijo donde todos los procesos de la jerarquı́a pueden acceder a la
información; y Memoria compartida padre-hijo, donde cada proceso par se le asigna un
bloque de memoria privado para acceder a la información. Las figuras 3.6a y 3.6b mues-
tran la arquitectura de memoria compartida a nivel QP y la arquitectua de memoria
compartida entre padre-hijo respectivamente.
shared
memory
QP
Root Process
the shared
memory block is Each parent-child
organized according pair establish an
to struct definition in independent block
external declaration file of memory for two-
way communication
/*sharedmem.h*/ The memory
typedef struct{ NIL address NIL
QP process
hierarchy
int n is installed
double x when parent-
common structure definition } shared mem child shared
reference via #include statement memory is
definitions file not used
(a) Nivel QP. (b) Padre-hijo.
Figura 3.6: Arquitectura de memoria compartida en OPNET.
42
3.2.5.1. Componentes de un modelo de proceso
Lenguaje Proto-C
Los procesos desarrollados en OPNET utilizan el lenguaje Proto-C soportado por el

editor de proceso. Proto-C es una herramienta basada en los lenguajes C y C++ muy
eficiente y poderosa para describir el comportamiento de sistemas de eventos discretos.
Dentro de sus principales rasgos destacan:
Esquema de Diagrama de Transición de Estados (STD):
También conocido como Máquina de Estado Finitas, permite describir la evolución

de sistemas de eventos discretos manteniendo la información de estado.
Representación gráfica/textual del proceso:
Combinación de la representación visual para la transición entre estados junto con el

uso de texto para la descripción de información más detallada integrada a cada estado.
Representación de la información de estado:
Los procesos pueden declarar la información de estado ya sea como variables que
pueden ser provistas por OPNET, lenguajes C y C++ o definidas directamente por el
usuario.
Diagrama de transición de estados
Estos diagramas son desarrollados mediante Proto-C. En ellos se especifican los

estados, situaciones en la que el proceso puede entrar; y sus transiciones, las que pueden
ejecutarse mediante el cumplimiento de ciertas condiciones.
Tipos de estados Existen dos tipos de estados en los cuales se puede encontrar
de manera única un proceso: estado forzado (forced state) y estado no forzado (unforced
state). Cada estado tiene asociado acciones a seguir descritas en C++. Estas acciones
son especificadas en los llamados executives, los cuales son divididos en dos partes
denominadas init y exit executives. El init executive se lleva acabo cuando un proceso
entra al estado mientras que el exit executive se procesa antes de abandonar el estado
y chequear las condiciones para transitar al siguiente.
43
Estado no forzado
Posee una pausa entre el init y exit executive modelando ası́ estados reales del
sistema. Una vez que se ejecuta el init executive, el estado se bloquea devolviéndole
el control al kernel de la simulación. En este punto, el proceso permanece suspendido
hasta ser nuevamente invocado y continuar con el exit executive del estado en el que se
encuentra.
Estado forzado
No posee una pausa entre los executives por lo que el proceso se ve obligado a ejecutar
su código y pasar directamente al siguiente estado. Los forced states no son usados para
emular procesos reales sino más bien para separar de manera gráfica acciones que se
llevan a cabo en el modelo.
st 4 st 6 st 7 st 8 st 5
La invocación comienza Se puede atravesar cualquier número La invocación termina al

en exit executive de forced states entre dos unforced final de los enter executives
del unforced state states durante una invocación del unforced state
Figura 3.7: Esquema hı́brido de estados en OPNET.
Transiciones entre estados
La forma en que los estados se comunican en OPNET es por medio de transiciones

que pueden ser condicionadas o no. En caso de que sean condicionadas, la transición
desde el estado inicial al final solo se lleva a cabo cuando la condición es evaluada ver-
dadera. En la transición condicionada es posible agregar una acción que será ejecutada
antes de entrar al init executive del siguiente estado. Adicionalmente, si ninguna tran-
sición condicionada se cumple, se puede crear una transición default de tal forma de
permanecer en el estado actual.
Definición de Macros
Con el fin de facilitar la construcción del código, el editor de proceso permite definir
expresiones más complejas a través de macros. La mayorı́a de las macros usadas en el
modelo Proto-C se definen en el editor de cabecera (Header Block HB ) usando códigos
44
Las transiciones
(Condition)/Executive con condición son
lı́neas discontı́nuas
(Condition)
st 0 st 3 st 1 st 2
/Executive
(!Condition)
Las transiciones pueden Las transiciones sin
volver al mismo estado condición son lı́neas
contı́nuas
Figura 3.8: Esquema de transiciones dentro de un STD.
C o C++ representando expresiones tales como constantes, transiciones condicionadas

u operaciones. Las macros son definidas por medio de la sentencia define dentro del
Header Block o dentro de archivos externos de extensión .h, los cuales se incluyen
usando el comando include. El siguiente código ejemplifica parte del HB de un modelo
de proceso en OPNET.
1 # include <ip addr v4.h>

2 # include <oms pr.h>
3 # include <oms tan.h>
4 # include <ip dgram sup.h>
5 # include <ip higher layer proto reg sup.h>
6 # include <ip notif log support.h>
7
8 # define FROM TRANSPORT op intrpt strm ()!= instrm from network
9 # define FROM NETWORK op intrpt strm ()== instrm from network
10 # define IPC INTF INDEX INVALID -50
Variables Existen tres tipos de variables utilizadas en los modelos de procesos:

variables de estado, variables temporales y variables globales. Estas variables pueden ser
del tipo int, double, boolean, definidas por el usuario o definidas por OPNET. En el caso
de las variables de estado, éstas se definen para mantener información que caracteriza al
modelo completo siendo sus valores accesibles solo dentro éste. Las variables temporales
por su parte, almacenan información que no requiere de persistencia por lo que no se
mantienen sus valores entre una invocación y otra del proceso. Este tipo de variable
generalmente es utilizada como variable auxiliar facilitando ası́ acciones repetitivas.
Finalmente las variables globales proporcionan un método para que diferentes procesos
guarden información en un área común, de esta forma si un proceso modifica una
variable global, entonces otros procesos pueden ver alteradas sus operaciones.
45
Procedimientos del Kernel de Simulación OPNET provee servicios al proceso

de simulación a través del Kernel de Simulación. La manera de acceder a estos servi-
cios es por medio de los llamados “procedimientos del kernel de simulación” (Kernel
Procedures KPs) los cuales pueden ser invocados desde los procesos de modelos iden-
tificándose a través de sus letras iniciales “op”. Los KPs son categorizados de acuerdo
al tipo de objeto que manipulan diferenciándose entre sı́ a través del package al cual
pertenecen. La tabla 3.3 destaca los principales packages utilizados en OPNET.
KP package Funcionalidad
Permite acceder/operar sobre los atributos de los
Attribute Access
objetos dentro de la simulación.
Distributions Provee manejo de distribuciones probabilı́sticas.
Dynamic Processes Provee manejo de procesos de simulación.
Events and Time Permite acceder/operar sobre la lista de eventos.
Permite la identifiación de objetos de la simula-
Identification and Discovery
ción.
Interface Control Information (ICIs) Permite acceder/operar sobre ICIs.
Provee manejo de interrupciones dentro de la
Iterrupt Processing
simulación.
Provee manejo de paquetes dentro de la simula-
Packet Generation and Processing
ción.
Provee manejo de estadı́sticas dentro de la simula-
Statistic Recording
ción.
Tabla 3.3: KPs principales agrupados por área de funcionalidad.
3.2.6. Construcción modelo de simulación en OPNET
OPNET corresponde a un simulador de redes basado en eventos discretos. Al igual

que cualquier software, requiere de un programa compilado con forma de código-objeto
(object code) escrito en lenguaje de máquina para poder ser ejecutado directamente
por el computador. La simulación de eventos discretos está conformada a partir de
distintas piezas de estos código-objeto dentro de las cuales existen aquellas provistas
directamente por OPNET mientras que otras pueden ser definidas por el usuario. La
tabla 3.4 muestra los distintos object files usados por la simulación.
En la medida que se obtiene la totalidad de estas partes que conforman la simulación,
OPNET genera un programa ejecutable idóneo para ser simulado.
46
Archivo Objeto Programa de simulación

Provee el marco para todas las simulaciones incluyendo servicos
básicos tales como la carga de modelos, planificación dinámica
Kernel de Simulación de eventos, recolección de estadı́sticas y asignación de reusos de
memoria. Adicionalmente contiene todos los KPs utilizados por
el usuario.
Los modelos de procesos incluidos en la simulación son compi-
lados a un archivo de lenguaje C de extension *.pr.c para luego
Modelos de procesos ,previo a la simulación, ser compilados con el compilador especı́fi-
co instalado en el computador del usuario. En este trabajo se ha
usado Microsoft Visual Studio generándose un archivo objeto de
extensión *.pr.o.
Se relacionan directamente con los links del sistema a través
de la transmisión de paquetes entre módulos transmisores y re-
Pipeline Stages
ceptores. Son incluidos en la simulación como ficheros *.ps.c y
posteriormente compilados a extensión *.ps.o.
Proporciona funciones a los modelos de proceso y pipeline stages
Archivo de Objeto Externo durante la simulación. Deben ser incluidos en los arhivos del
modelo de proceso que los utilice. Su extensión es del tipo *.ex.c
Similar a los archivos de objeto externo, pero empaquetado como
Archivo externo un archivo contenedor de múltiples archivos objetos, facilita el
manejo de archivos pertenecientes a uns mismo package.
Tabla 3.4: Tipos de Object Files incluidos en un programa de simulación.
3.3. Mobile IP en OPNET

En esta sección se describe la configuración del protocolo Mobile IP provisto por el
simulador. Los agentes móviles que soportan MIP corresponden al nodo móvil y a los
routers de acceso tanto para la red local como la visitada. El registro en la red foránea
es por medio del FA utilizando la dirección Care-of-Address, teniéndose el punto final
del túnel MIP en el FA.
Nodo móvil
La configuración de los parámetros MIP es asignada directamente en los atributos
de la estación de trabajo escogida. De manera transversal al tipo de estación
elegida para el despliegue de pruebas, la tabla 3.5 muestra la configuración en
OPNET de MIP para el cliente móvil.
En este caso se ha deshabilitado la opción de solicitación de agente por parte del
nodo móvil. Esta última sólo debe ser utilizada en caso de ausencia de agent ad-
47
Atributo Valor
Mobile IPv4 Parameters
—Home Agent IP Address 192.0.0.1
—Registration Parameters
——Interval (seconds) 4
——Retry (times) 4
——Lifetime Request (seconds) 3600
——Agent Solicitation Disabled
Tabla 3.5: Configuración cliente MIP en OPNET.
vertisements o la inexistencia de la dirección CoA de acuerdo a las especificaciones

RFC del protocolo MIP.
Home Agent
La configuración de los parámetros MIP es asignada por medio de los atributos
del router. La tabla 3.6 muestra la configuración MIP del agente móvil.
Atributo Valor
IP Routing Parameters
—Interface Information
——IF1
———Name IF1
———Address 192.0.0.1
———Routing Protocol RIP
———MTU (Bytes) WLAN
——IF1
———Interface IF1
———Agent Type Home Agent
———Agent Configuration
————IRDP Parameters
—————Max Interval (seconds) 16
—————Min Inteval (seconds) 12
—————Holdtime (seconds) 3*Max Interval
—————Lifetime Grant 3600
Tabla 3.6: Configuración HA en OPNET.
48
Foreign Agent
Análogo al caso anterior, la tabla 3.7 muestra la configuración MIP del agente
móvil. En este caso, la dirección IP de la interfaz por la cual se realiza el servicio
de Foreign Agent, es decir el punto final del túnel MIP, no es necesario definirla
por lo que se ha dejado en formato de autoasignación.
Atributo Valor
IP Routing Parameters
——IF1
———Name IF1
———Address Auto Assigned
———Routing Protocol RIP
———MTU (Bytes) WLAN
——IF1
———Interface IF1
———Agent Type Foreign Agent
———Agent Configuration
————IRDP Parameters
—————Max Interval (seconds) 16
—————Min Inteval (seconds) 12
—————Holdtime (seconds) 3*Max Interval
—————Lifetime Grant 3600
Tabla 3.7: Configuración FA en OPNET.
3.4. Escenario de pruebas Mobile IP en ambiente

WLAN
En esta sección se describe el escenario bajo el cual se realiza las pruebas de Mobile
IP en un ambiente WLAN. Para generar este último, se implementan dos redes de
acceso con estándar IEEE 802.11 a través de las cuales el cliente móvil establece una
conexión con el nodo correspondiente que reside en internet.
49
3.4.1. Topologı́a de Red
La red implementada se muestra en la figura 3.9. El cliente móvil tiene asignada una
trayectoria de rapidez tipo peatonal representada a través de una flecha color blanco. El
establecimiento de la conexión inicial es por medio del nodo Home Agent para luego ser
reestablecido con el Foreign Agent una vez que el nodo móvil detecta que se encuentra
dentro de la subred visitada. El backbone de internet es representado por la nube IP
quien incorpora una latencia a los paquetes en viaje. La tabla 3.8 detalla los modelos
de nodo y enlace escogidos para la simulación con la nomenclatura de OPNET.
Figura 3.9: Topologı́a de red pruebas MIP en ambiente WLAN.
Nombre nodo Modelo de nodo

Home/Foreing Agent mip wlan ethernet slip4 adv
Nodo móvil wlan wkstn adv
Servidor ppp server
Nube ip 32 cloud adv
Enlace servidor-nube Duplex PPP link con interfaz serial OC12
Enlace nube-HA Duplex PPP link con interfaz serial OC12
Enlace nube-FA Duplex PPP link con interfaz serial OC12
Tabla 3.8: Modelo de nodos para pruebas MIP en ambiente WLAN.
3.4.2. Servicios de aplicaciones y perfiles
La configuración del servicio de aplicaciones y perfiles en OPNET es realizada a

través de nodos externos a la red , es decir que no son estaciones de trabajo ni rou-
ters. Estos nodos se pueden encontrar en la librerı́a del simulador por los nombres de
Application Config y Profile Config.
50
En el nodo Application Config se especifican las aplicaciones a usar en la simulación,

mientras que en Profile Config se pueden mezclar diferentes aplicaciones conformando
un perfil de cliente. Particularmente en el escenario de pruebas de MIP en ambiente
WLAN, la sesión se establece entre el servidor de aplicación (nodo correspodiente) y el
nodo móvil. Los servicios requeridos por el cliente son FTP y Video conferencia de baja
resolución, el primero con transporte TCP tanto para el control como la transmisión
y el segundo con UDP. Las aplicaciones son soportadas de a una a la vez por lo que
se llevan a cabo en simulaciones independientes. La tabla 3.9 muestra en detalle las
aplicaciones utilizadas.
Aplicación Atributo Valor

File Size (MB) 1
FTP
Segment Size (B) 8000
Frame Interarrival Time Information (frames/sec) 10
Video Conferencia Frame Size Information (B) 128x120
Segment Size (B) 1440
Tabla 3.9: Configuración aplicaciones para pruebas MIP en ambiente WLAN.
3.4.3. Configuración métricas de simulación
Las métricas escogidas para el análisis de Mobile IP se detallan en la tabla 3.10 y

la tabla 3.11.
Nivel métrica Métrica

IP End-to-end Delay (seconds)
Segment Delay (seconds)
TCP
3-Way Handshake Delay (seconds)
Tunneled Traffic Received (bits/sec)
Mobile IP
Tunneled Traffic Sent (bits/sec)
Download Response Time (sec)
Cliente FTP
FTP Application Control Delay (bits/sec)
Tabla 3.10: Configuración métricas aplicación FTP para pruebas MIP en ambiente
WLAN.
Todas las métricas de la tabla anterior, a excepción de delay 3-way handshake y

delay de control de aplicación FTP, vienen integradas en el software. En el caso de
las métricas asociadas al establecimiento de la sesión de transporte y de aplicación,
el software no integra sus mediciones directamente por lo que se implementan por
código. La métrica Delay de control de aplicación FTP considera el delay desde que
51

IP End-to-end Delay (seconds)
Tunneled Traffic Received (bits/sec)
Mobile IP
Tunneled Traffic Sent (bits/sec)
Video conferencia Packet End-to-end Delay (sec)
Tabla 3.11: Configuración métricas aplicación Video Conferencia para pruebas MIP
en ambiente WLAN.
el requerimiento de descarga (“GET”) es enviado por la capa de aplicacion del cliente

hasta que su homóloga en el servidor lo recibe, comenzando ası́ a generar los mensajes
de aplicación a descargar. Para medir delay de aplicación del tipo “round trip time” se
invierten los roles cliente-servidor y se suman ambas mediciones.
3.4.4. Configuración simulación DES
Los parámetros de configuración de las simulaciones son detallados en la tabla 3.12.
Atributo Valor
Values per Statistic 1000 samples/sec
IP Dynamic Routing Protocol RIP
Mobile IP Activation Time (sec) 50
Application Delay Tracking Enabled
—Start Time Start of Simulation
—End Time End of Simulation
Tabla 3.12: Configuración simulación DES para pruebas MIP en ambiente WLAN.
OPNET provee una aplicación capaz de hacer un tracking de los mensajes generados
a nivel de aplicación por nodos de la red simulada. Esta aplicación es habilitada por
medio del atributo Application Delay Tracking en cada nodo de interés permitiendo
estudiar en detalle el camino que siguen los mensajes a través de los links y routers por
lo cuales son procesados. En este caso, se habilita la aplicación para el cliente móvil.
52
3.5. Nueva implementación de Mobile IP en

OPNET
En esta sección se describe la implementación propia de Mobile IP dentro de OPNET
para ser utilizada en un ambiente heterogéneo 3G/UMTS-WLAN. Esta implementa-
ción requiere diseñar un cliente dual MIP ası́ como también un agente móvil HA que
brinde servicios de movilidad. El protocolo MIP provisto por el simulador no es utili-
zado directamente pues no soporta un ambiente heterogéneo de manera nativa. Esto
último motiva entonces a diseñar el protocolo utilizando el lenguaje de programación
de OPNET.
3.5.1. Diseño estación dual
En esta sección se describe la estación dual diseñada en OPNET. Esta última

está basada en el modelo de nodo multihomed provisto por el simulador el cual so-
porta la asignación de múltiples direcciones IP gracias a la integración de diferentes
interfaces. Adicional a lo anterior se destaca también el soporte de distintas aplicacio-
nes de ruteo. La figura 3.10 ilustra el modelo de nodo dual creado utilizando el Editor
de Nodos del simulador.
El modelo dual incorpora dos interfaces del tipo WLAN con direcciones IP asociadas
topológicamente a diferentes redes de acceso IP. En este caso la interfaz de la izquierda
IF0 tiene asignada la dirección HoA provista por el HA, mientras que la de la derecha
IF1 es fijada por la red visitada siendo del tipo CCoA de acuerdo al protocolo MIP.
Tal como puede apreciarse en la figura, se ha optado por emular la interfaz 3G/UMTS
caracterı́stica de un teléfono celular a través de un acceso WLAN debido a que OPNET
no es capaz de integrar el modelo de interfaz 3G provisto con una del tipo WLAN
en una misma estación de trabajo. Esta emulación se realiza variando los parámetros
tanto de la tarjeta WLAN del router de acceso (2Mbps-40W) como de la tarjeta WLAN
asociada a la interfaz correspondiente a la estación dual (2Mbps-2W).
El diseño del modelo dual comprende la totalidad del stack TCP/IP donde cada QP
alude a alguna de las capas del stack anterior. Cabe destacar que los módulos poseen
un modelo de proceso programado por los desarrolladores del software pero que sin
embargo han tenido que ser modificados con el fin de poder integrar de manera exitosa
una nueva interfaz de acceso. Además se ha incorporado un QP extra (ksl switch client)
con un nuevo modelo de proceso diseñado exclusivamente para modificar la ruta de los
paquetes IP originados en el cliente móvil una vez que éste decida hacer roaming entre
la red local y la visitada emulando ası́ a un dispositivo dual mode La figura 3.11 muestra
el diagrama de estados del proceso asignado al QP ksl switch client.
53
Figura 3.10: Modelo estación dual 3G\UMTS-WLAN.
3.5.1.1. Modelo de proceso ksl pro switch client
El diagrama de estado del modelo de proceso ksl pro switch client consta de dos
estados no forzados y dos estados forzados. En el estado no forzado Init se inicializan
las variables globables que definen el proceso y las variables estadı́sticas a medir. Una
vez que se ingresa al estado Idle, el proceso permanece en éste a menos que se le pida
realizar alguna acción en concreto. En caso de que se reciba un interrupt del tipo stream,
es decir un paquete ingresa desde el módulo IP, el proceso se mueve al estado forzado
route mientras que si el interrupt es del tipo remoto se pasa al estado change route.
Dentro del estado route, el paquete IP entrante es capturado y procesado para
luego determinar por cual ruta default debe salir. Si es que el cliente se encuentra con
servicio MIP, el paquete es redireccionado por la interfaz IF1 previo cambio en el ICI
54
Figura 3.11: Modelo de proceso ksl pro switch client.
acompañante sin modificación alguna en su header IP, es decir el cliente sigue utilizando
su dirección HoA pero a través de un nuevo acceso. De lo contrario, el paquete continúa
su ruta original a través de la interfaz IF0 asociada a la red local.
En caso de que se solicite el servicio MIP, o equivalentemente se reciba un interrupt
del tipo remoto proveniente desde el nodo KSL MIP Config definido posteriormente
(ver sección 3.5.3), el proceso ingresa al estado change route actualizando la variable
global asociada al tipo de red por el cual el cliente se conecta a la red. El detalle del
código puede ser consultado en material digital adjunto, ver Anexo D.3.
3.5.1.2. Modificaciones en procesos desarrollados por OPNET
Los cambios incorporados a los modelos de procesos de OPNET son detallados en la

siguiente tabla. El detalle del código puede ser consultado en material digital adjunto,
ver Anexo D.4.
QP Modelo de Proceso Modificación

IP ip dispatch Archivo externo ip rte support.ex
ARP ip arp v4 Function Block
TCP Child Process tcp conn v3 Function Block
Tabla 3.13: Modificaciones en procesos propios de OPNET.
3.5.2. Diseño agente móvil HA
En esta sección se describe el agente móvil HA diseñado en OPNET. Este último

está basado en el modelo de router wlan ethernet slip4 adv provisto por el simulador.
55
La figura 3.12 ilustra el modelo de nodo creado utilizando el Editor de Nodos del
simulador. Se ha integrado un QP adicional (ksl switch HA) entre los módulos IP y
ARP con el fin de re-rutear los paquetes destinados hacia el cliente móvil en caso de
que éste se encuentre fuera de la red local. La figura 3.13 ilustra el modelo de proceso
asignado a este nuevo módulo.
Figura 3.12: Modelo de nodo HA.
Figura 3.13: Modelo de proceso ksl pro switch ha.
3.5.2.1. Modelo de proceso ksl pro switch ha
El modelo de proceso ksl pro switch ha consta de tres estados forzados y tres no
forzados. El proceso se inicializa en el estado Init además de la obtención de parámetros
relevantes del servicio MIP (tiempo de registro MIP estimado previamente, red inicial
56
de acceso local o visitada, etc.) y de la inicialización de las estadı́sticas asociadas al

proceso.
Para procesar los paquetes destinados hacia el cliente móvil, el proceso se mueve
entre los estados route y send pk, si es que la estación dual se encuentra accediendo a
través de su red local; o entre los estados tunnel y send pk, en caso de que el servicio
MIP ya esté activo. Si el cliente se encuentra en la red visitada, es el estado send pk el
encargado de rerutear los paquetes hacia la nueva dirección por la cual está alcanzable
la estación móvil. Este redireccionamiento consiste en una encapsulación del tipo IP-IP
de los paquetes del cliente estableciéndose ası́ el túnel entre el HA y el FA.
Un punto importante en el diseño de MIP es que la señalización en el registro del
servicio es modelado por medio del delay que supone el intercambio de mensajes entre
el nodo y el agente móvil. Es decir, en caso de que se active el servicio de movilidad, el
proceso entra en el estado drop donde se descartan los paquetes destinados al cliente
hasta que se complete el registro MIP y efectivamente el HA empiece a rerutear los
paquetes. Las estadı́sticas asociadas al descarte de paquetes son actualizadas en el
estado drop packet. La estimación de este delay de roaming 3G UMTS-WLAN se ha
obtenido desde [5]. Este delay de registro no incorpora costos y latencias asociados a las
demás capas del stack TCP/IP sino que asumen que ya existe establecimiento a nivel
de capas inferiores antes del requerimiento de movilidad IP. Mayor detalle del código
puede ser consultado en el material digital asociado, ver Anexo D.3.
3.5.3. Diseño configuración MIP
La configuración de MIP es integrada por medio del nodo externo KSL MIP Config
de manera análoga a como OPNET integra los nodos externos de aplicaciones y perfiles.
El nodo móvil y el HA se inicializan y gatillan el servicio a través de KSL MIP Config.
La tabla 3.14 muestra los atributos del nodo de configuración de movilidad.
En la tabla 3.14 se detallan las IPs relevantes para el acceso a la red tanto local como
en calidad de visita. Particularmente las IPs Home y Foreign Gateway son asignadas
a la interfaz del routers local (GGSN) y foráneo (Router acceso red WLAN) respecti-
vamente, quienes reciben los mensajes del cliente MIP cumpliendo ası́ el rol de Default
Gateway del nodo móvil. Las direcciones default anteriores son utilizadas por el QP
ksl switch client para modificar la ruta del paquete proveniente de IP. Los atributos
Starting Network y Swap Interval son integrados para emular el roaming entre la red
local y visitada. A través de Starting Network se puede seleccionar que el cliente se
inicie desde la red visitada (ie con el servicio MIP ya activo) o desde su red local sin
servicio. El atributo Swap Interval contiene el tiempo durante el cual el MN permanece
en la red local o visitada antes del roaming.
57
Atributo Valor
IP Foreign
—Foreign Broadcast 192.0.3.255
—Foreign Gateway 192.0.3.1
—Colocated Care-of-Address IF1 192.0.3.2/24
IP home
—Home Broadcast 192.0.2.255
—Home Gateway 192.0.2.1
—Home Address IF0 192.0.2.2/24
KSL MIP
—Registration Delay [ms] 18
—Starting Network Home
—Swap Interval [s] 300
Tabla 3.14: Configuración nodo KSL MIP Config.
El atributo Registration Delay es utilizado dentro del proceso ksl pro switch HA por
el HA, para estimar el costo de señalización asociado al proceso de handover entre ambas
redes. Este costo tiene que ver con los costos de transmisión involucrados entre los nodos
del sistema ya sea en la dirección WLAN-UMTS o UMTS-WLAN. En este trabajo, sólo
se utiliza la configuración HA en UMTS con roaming en la dirección 3G/UMTS-WLAN
estimado en 18 [ms]. La tabla 3.15 muestra la estimación del parámetro Registration
Delay.
Delay Handoff Delay Handoff

Ubicación HA en la red UMTS-WLAN WLAN-UMTS
[ms] [ms]
HA en WLAN 6 37.5
HA en UMTS 18 27.5
Tabla 3.15: Estimación delay handoff interconexión redes 3G\UMTS y WLAN.
3.5.3.1. Modelo de proceso nodo externo de configuración de movilidad
El modelo de proceso del nodo KSL MIP Config se ilustra en la figura 3.14. En
el primer estado no forzado Init se inician las variables a partir de los atributos de
configuración del nodo y luego se entra al estado loop donde se gatilla la activación del
servicio MIP a través de interrupts destinados hacia el cliente y agente móvil para que
actualicen sus estados una vez que se cumpla el Swap Interval.
58
Figura 3.14: Modelo de proceso del nodo KSL MIP Config.
3.5.4. Escenario de pruebas modelo de interconexión de redes

3G/UMTS-WLAN
El modelo de interconexión de redes que se pretende emular se muestra en la fi-

gura 3.15a. El modelo corresponde a un esquema de interconexión loose coupling (ver
Anexo C) donde la red WLAN es independiente de la arquitectura UMTS, sin reque-
rir modificaciones en los nodos GPRS. La figura 3.15b, muestra de qué forma se ha
implementado el modelo de interconexión dentro del simulador.
Server
Nube IP
Server
GGSN/HA
Nube IP
SGSN
GGSN/HA WLAN
Red acceso
3GPP
(a) (b)
Figura 3.15: Modelo 3G\UMTS y WLAN a emular, y modelo real implementado en

OPNET con integración de MIP
La configuración del servicio de aplicaciones y perfiles en este escenario es análogo

al de la sección 3.4.2.
59
3.5.5. Configuración métricas
Las tablas 3.16 y 3.17 muestran las métricas configuradas durante la simulación para
las dos aplicaciones. En este caso, aquellas asociadas a Mobile IP son implementadas
dentro del diseño propio de MIP por lo que no corresponden a las del software.
IP End-to-end Delay (sec)
Segment Delay (sec)
TCP
3-Way Handshake Delay (sec)
Tráfico con servicio MIP (bits/sec)
Mobile IP Tráfico sin servicio MIP (bits/sec)
Tráfico descartado durante delay registro (bits/sec)
Cliente FTP
Tabla 3.16: Configuración métricas para pruebas MIP en ambiente interconectado.

Video Conferencia Packet End-to-end Delay (sec)
Tabla 3.17: Configuración métricas para pruebas MIP en ambiente interconectado.
3.6. Extensión simple de MIP a Proxy MIP

En esta sección se presenta la implementación hecha para PMIP la cual incorpora
servicios de movilidad sin involucrar al cliente móvil en la señalización. La integración
de PMIP en OPNET está basada en el modelo propio de Mobile IP explicado en las
secciones anteriores. Al igual que antes, se utiliza un cliente dual capaz de comunicarse
por dos redes diferentes y agentes móviles capaces de proporcionar servicios de roaming
de red.
El esquema de interconexión 3G/UMTS-WLAN que se pretende emular se muestra
en la figura 3.16a [14]. El modelo representa un ambiente localizado donde el gateway
GGSN es mejorado con soporte de PMIP, es decir con funcionalidades de LMA. La
figura 3.16b muestra el esquema implementado en OPNET para emular la arquitectura
UMTS con integración de PMIP.
60
Server
Nube IP
Server
GTP Túnel GGSN/LMA
Nube IP
SGSN PMIP Túnel
GGSN/LMA
Acceso 3G MAG
Red acceso
3GPP
(a) (b)
Figura 3.16: Modelo 3G/UMTS-WLAN a emular y modelo real implementado en

OPNET con integración de PMIP
3.6.1. Diseño estación dual
El cliente móvil utilizado incorpora básicamente el mismo diseño del nodo de la

sección 3.5.1.El QP ksl switch se mantiene para poder emular el funcionamiento de una
estación dual. Al igual que antes, se varı́an los parámetros de la interfaz IF0 WLAN
con el fin de poder simular una tarjeta 3G/UMTS.
3.6.2. Diseño agente móvil LMA
El agente móvil LMA (de funcionalidad análoga al HA de MIP) corresponde al

punto de anclaje del MN siendo el encargado de encapsular los paquetes destinados
hacia el cliente una vez que ingresen al dominio. El LMA determina hacia donde crear
el túnel PMIP dependiendo de su tabla caché con información del nodo móvil con
servicios activos. El diseño de LMA se basa en el nodo slip16 gtwy adv e incorpora el
QP ksl switch con el proceso ksl pro switch ha usado en el diseño de HA pero extendido
para integrar PMIP. La figura 3.17 muestra el modelo de LMA creado.
El QP ksl switch HA recibe paquetes desde IP, determina dónde se encuentra ac-
tualmente el cliente, encapsula el paquete siguiendo el túnel hacia la red 3G o la red
WLAN y finalmente coloca el paquete en el stream correspondiente usando la función
61
Figura 3.17: Modelo de nodo HA en PMIP.
de OPNET op pk deliver. Mayores detalles del código pueden ser consultados en el

material digital adjunto, ver Anexo D.3.
3.6.3. Diseño nodos de acceso 3G y MAG
Los nodos de acceso 3G y MAG corresponden al modelo wlan ethernet slip4 adv de
OPNET (ver figura 3.18). Ambos incorporan una interfaz WLAN en su diseño con la
diferencia de que al primero se le varı́an los parámetros de la tarjeta WLAN para poder
emular un acceso 3G/UTMS.
Dentro del modelo implementado con integración de PMIP en el simulador, corres-
ponden a los default gateway de la estación dual. Estos nodos reciben los paquetes
tuneleados desde el LMA hacia el cliente y rutean los paquetes desde el cliente hacia el
LMA. Esto último se hace modificando el proceso asignado al QP ARP en su modelo.
Mayores detalles pueden obtenerse del material digital, ver Anexo D.3.
3.6.4. Diseño configuración PMIP
La configuración de PMIP es análoga al de la sección 3.5.3 por medio del nodo

externo KSL MIP Config. La estimación del atributo Registration Delay, el cual su-
pone el tiempo involucrado en el registro PMIP, no se ha obtenido desde la principal
bibliografı́a relacionada puesto que no se encuentra estudios experimentales que mues-
tren el delay asociado sólo a las señalizaciones PMIP [18],[21],[30],[32]. La estimación
62
Figura 3.18: Modelo de nodo acceso 3G y MAG en PMIP.
de este parámetro se hace midiendo diferentes pings entre el MAG y el LMA de la

figura 3.16a siguiendo las especificaciones en [16]. Los resultados obtenidos se muestran
en la tabla 3.18:
Medida Valor
Registration Delay [ms]
Promedio 1.9133
Desviación 0.7812
Tabla 3.18: Registration Delay en PMIP
3.6.5. Servicios de aplicaciones y perfiles
La configuración del servicio de aplicaciones y perfiles a utilizar es análogo al de la

sección 3.4.2.
63
3.6.6. Configuración métricas
Las tablas 3.19 y 3.20 muestran las métricas configuradas durante la simulación
para las dos aplicaciones. En este caso, aquellas asociadas a PMIP son implementadas
dentro del diseño propio.

Segment Delay (sec)
TCP
3-Way Handshake Delay (sec)
Cliente FTP
Tabla 3.19: Configuración métricas para pruebas PMIP en ambiente interconectado.

Proxy Mobile IP Tráfico descartado durante delay registro (bits/sec)
Video conferencia Packet End-to-end Delay (sec)
Tabla 3.20: Configuración métricas para pruebas PMIP en ambiente interconectado.
64
Capı́tulo 4
Discusión de Resultados
En este capı́tulo se exponen y analizan los resultados de Mobile IP obtenidos para

los ambientes implementados en el capı́tulo 3. En primer lugar se obtienen resultados en
ambiente WLAN-WLAN tanto con el protocolo MIP de OPNET como con el modelo
propio con el fin de validar este último. A continuación, se exponen los resultados
para un ambiente interconectado 3G/UMTS-WLAN utilizando el modelo MIP creado.
Finalmente se muestran los resultados para un ambiente interconectado utilizando el
modelo de PMIP. Todos los resultados obtenidos provienen de las simulaciones con
servicios de aplicación FTP y Video conferencia de manera independiente.

WLAN-WLAN
Los resultados obtenidos se han separado en tres partes: Análisis de la aplicación
sin servicio MIP, con servicio MIP y durante el roaming de red. El análisis durante el
roaming sólo se hace usando MIP de OPNET y no con la implementación hecha del
protocolo.
4.1.1. Resultados con aplicación FTP
4.1.1.1. Red local
En este caso el cliente móvil descarga el archivo a través de su red local por lo que
no existe servicio MIP activo a través del FA. El MN debe primero registrarse con su
HA utilizando la señalización MIP del tipo request/reply usando UDP. La tabla 4.1
65
CAPÍTULO 4. DISCUSIÓN DE RESULTADOS
muestra el delay asociado al registro para 4 latencias asignadas a la nube IP por medio
de distribuciones estadı́sticas normales.
Distribución Normal
Latencia Nube IP Delay Registro [ms]
µ [ms] σ 2 [ms2 ]
1 0,22 1.34127
10 22 1.34127
50 102 1.52127
100 202 1.52127
Tabla 4.1: Delay registro MIP en red local usando OPNET.
Las tablas 4.2 y 4.3 muestran los delays a nivel IP , TCP y de Aplicación para las
4 latencias asignadas.
Distribución Normal Delay Paquete IP

Delay TCP Delay APP
Latencia Nube IP [ms]
Cliente → Servidor → 3-way Handshake Control FTP
µ [ms] σ 2 [ms2 ]
Servidor Cliente [ms] [ms]
1 0,22 3.366 9.3582 4.4797 5.8223
10 22 11.3604 13.5842 31.1758 25.2267
50 102 51.8584 57.0171 152.013 114.0903
100 202 102.3467 110.7895 310.827 220.1059
Tabla 4.2: Delay stack TCP/IP en red local usando MIP OPNET.

Delay TCP Delay APP
µ [ms] σ 2 [ms2 ]
1 0,22 3.3784 9.3905 4.7584 6.1775
10 22 11.3957 14.3505 31.607 25.5579
50 102 51.8266 57.8916 153.3314 116.1003
100 202 102.6375 112.1652 306.4665 224.3346
Tabla 4.3: Delay stack TCP/IP en red local con MIP creado para este trabajo.
4.1.1.2. Red visitada
En este caso el cliente móvil descarga el archivo en la red visitada a través del FA.
El MN debe primero solicitar servicio MIP antes de iniciar la aplicación. La tabla 4.4
muestra el delay asociado al registro para 4 latencias asignadas a la nube IP.
Las tablas 4.5 y 4.6 muestran los delays a nivel IP, TCP y de Aplicación para las 4
latencias asignadas análogo al caso anterior.
66
Distribución Normal
Latencia Nube IP Delay Registro [ms]
µ [ms] σ 2 [ms2 ]
1 0,22 2.3669
10 22 17.8679
50 102 72.5276
100 202 144.4106
Tabla 4.4: Delay registro MIP en red visitada usando OPNET.

Delay TCP Delay APP
µ [ms] σ 2 [ms2 ]
1 0,22 2.6352 6.6668 5.3192 6.2034
10 22 10.92 23.6274 40.9971 35.5107
50 102 51.2009 108.9676 202.3133 169.6331
100 202 101.3446 214.4882 402.2567 334.0013
Tabla 4.5: Delay stack TCP/IP en red visitada usando MIP OPNET.

Delay TCP Delay APP
µ [ms] σ 2 [ms2 ]
1 0,22 3.3599 9.6248 5.8026 7.2877
10 22 11.3085 25.1293 41.9136 36.8939
50 102 51.4903 110.6336 202.8884 170.9396
100 202 101.5003 216.2407 397.1223 337.2904
Tabla 4.6: Delay stack TCP/IP en red visitada con MIP creado para este trabajo.
4.1.1.3. Roaming de red
En este caso el cliente móvil inicia y finaliza la descarga del archivo desde su red
local y visitada respectivamente. El inicio de la señalización MIP ocurre posterior a la
reconexión a nivel AP por lo que el cliente se encuentra durante un pequeño tiempo
desconectado teniendo un hard handover. La siguiente tabla detalla los hitos más
relevantes medidos durante el proceso de roaming. Se ha escogido mostrar el caso más
favorable con la menor latencia de red con media µ=1[ms] y desviación σ = 0,2[ms].
La figura 4.1 muestra de manera gráfica métricas durante el proceso de roaming.
Se evidencia que el cliente móvil permanece por varios segundos inalcanzable. Esto
último se debe a que OPNET no permite conexión simultánea a diferentes APs por
lo que el servicio MIP no puede ser solicitado sin cambiar la conectividad a nivel L2.
Adicionalmente, a pesar de que el reestablecimiento L2 se completa a los 10 [s], el
cliente móvil no envı́a la solicitud de movilidad IP antes de la expiración del holdtime
67
Tiempo Inicio [s] Delta Tiempo [s] Hito

0 0.00221 Establecimiento sesión TCP
0.0022 0.00363 Establecimiento sesión FTP
10 0.05 Reestablecimiento conexión AP
45.9 0.00168 Establecimiento servicio MIP
71.72 72 Finalización descarga FTP
Tabla 4.7: Roaming de red en ambiente WLAN.
definido en los mensajes IRDP permaneciendo sin servicio MIP por más de 30 [s]. De
esta forma, los costos asociados a los reestablecimientos de las conexiones a nivel AP,
Red, y Transporte generan pérdidas de paquetes de aplicación. Finalmente, se evidencia
un aumento notable en la desviación asociada a los tiempos de descarga del archivo
cuando el cliente se encuentra con servicio MIP (de 0.01 [s] a 2.23 [s]) además de una
disminución en el delay a nivel IP en ambos sentidos Cliente-Servidor.
Tiempo descarga aplicación FTP - Roaming WLAN Retransmisión TCP - Roaming WLAN
70
2
60
50
Tiempo (s)
Tiempo (s)
40
30 1
20
10
0 0
Red local Roaming de red Red Visitada Red local Roaming de red Red Visitada
(a) (b)
Delay IP - Roaming WLAN con aplicación FTP

160
Servidor-Cliente
140 Cliente-Servidor
120
100
Delay (ms)
80
60
40
20
0
Red local Roaming de red Red visitada
(c)
Figura 4.1: Delays en roaming IP WLAN-WLAN bajo aplicación FTP usando OP-
NET.
68
4.1.2. Resultados con aplicación Video conferencia
4.1.2.1. Red local
El cliente móvil mantiene la aplicación de Video conferencia a través de su red local

sin servicio de movilidad. Las tablas 4.8 y 4.9 exponen los resultados para las 4 latencias
asignadas.
Distribución Normal Delay Paquete IP Delay Paquete Video

Latencia Nube IP [ms] [ms]
Cliente → Servidor → Cliente → Servidor →
µ [ms] σ 2 [ms2 ]
Servidor Cliente Servidor Cliente
1 0,22 3.1545 4.6339 3.1549 4.6347
10 22 12.3111 12.2052 12.3118 12.2049
50 102 52.3964 51.8039 52.3979 51.8004
100 202 101.740 101.9425 101.7424 101.9351
Tabla 4.8: Delay a nivel IP y Aplicación en red local usando MIP OPNET.

µ [ms] σ 2 [ms2 ]
1 0,22 3.1248 4.4652 3.1251 4.4664
10 22 12.3069 12.3795 12.3068 12.3804
50 102 52.0236 52.1147 52.0217 52.1148
100 202 102.1883 101.7423 102.1842 101.7442
Tabla 4.9: Delay a nivel IP y Aplicación en red local con MIP creado para este trabajo.
4.1.2.2. Red visitada
El cliente móvil mantiene la Video conferencia a través del FA utilizando el servicio

MIP. Las tablas 4.10 y 4.11 exponen los resultados.

µ [ms] σ 2 [ms2 ]
1 0,22 3.1147 5.6378 3.1151 5.6390
10 22 12.1702 22.7425 12.1705 22.7423
50 102 51.9020 102.4440 51.9017 102.4355
100 202 102.4217 202.7868 102.4221 202.7945
Tabla 4.10: Delay a nivel IP y Aplicación en red visitada usando MIP OPNET.
69

µ [ms] σ 2 [ms2 ]
1 0,22 3.1222 5.6653 3.1226 5.6665
10 22 12.3386 22.9709 12.3394 22.9735
50 102 52.3281 102.8516 52.3303 102.8534
100 202 102.4787 202.8202 102.4827 202.8181
Tabla 4.11: Delay a nivel IP y Aplicación en red visitada con MIP creado para este
trabajo.
El delay de control de la aplicación de video se mide solo para el caso más favorable
con menor latencia. La tabla 4.12 compara los delays asociados al inicio y cierre de la
aplicacion de video ambos del tipo request/reply.
Delay inicio Delay cierre

[ms] [ms]
MIP OPNET 2.8096 2.8508
Red Local
MIP Propio 2.7599 2.7489
MIP OPNET 3.6238 4.0658
Red Visitada
MIP Propio 3.5503 3.5929
MIP OPNET 28.98 42.98
Variación [ %]
MIP Propio 28.64 30.70
Tabla 4.12: Delay control aplicación video en ambiente WLAN-WLAN.
4.1.2.3. Roaming de red
El cliente móvil inicia y finaliza la Video conferencia accediendo a través de su red

local y visitada respectivamente. Al igual que en el caso anterior, el requerimiento de
movilidad es enviado a través del FA posterior a la reconexión a nivel AP. La nube IP
tiene asignada la menor latencia correspondiendo al caso más favorable. La figura 4.2
muestra el delay a nivel IP durante el roaming de red utilizando el protocolo MIP
implementado por OPNET. El delay del paquete de video no se muestra puesto que no
existe diferencia significativa con el delay IP.
70
Delay IP - Roaming WLAN

10
Cliente - Servidor
9 Servidor - Cliente
8
7
Delay (ms) 6
5
4
3
2
1
0
Inicio video Roaming de red Fin video ...
Figura 4.2: Delay IP durante roaming de red en ambiente WLAN usando OPNET.
La figura 4.2 evidencia pérdidas en los paquetes de video debido a que el cliente
permanece inalcanzable durante un tiempo. A diferencia del caso FTP, se evidencia un
comportamiento opuesto en el delay a nivel IP: mientras que el delay Cliente-Servidor
disminuye con servicio MIP, el delay IP Servidor-Cliente aumenta.

3G/UMTS-WLAN
En esta sección se exponen los resultados de MIP en ambiente interconectado
3G/WLAN utilizando la implementación generada para este trabajo del protocolo. El
posicionamiento del HA se supone en la red 3G con el nodo GGSN con servicios de HA
teniéndose servicio MIP una vez que el cliente detecta cobertura de la red WLAN. El
roaming IP desde la red 3G hacia la red WLAN se estima en 18 [ms] correspondiendo
sólo a los costos asociados a la señalización MIP.
Las tablas 4.13 y 4.14 muestran los delays experimentados por los paquetes de
aplicación FTP en la red local 3G y visitada WLAN respectivamente para distintas
latencias de red. Utilizando sus valores, la figura 4.3 muestra la variación porcentual de
los delays del stack TCP/IP cuando el cliente utiliza el servicio MIP en la red visitada
WLAN con respecto a los delays obtenidos en la red local 3G sin servicio MIP.
71

Delay TCP Delay APP
µ [ms] σ 2 [ms2 ]
1 0,22 7.6898 33.22 5.3687 10.3322
10 22 15.4782 28.1383 32.3344 29.6783
50 102 53.0540 65.7145 151.3041 117.3420
100 202 103.3146 119.0751 300.4507 231.2424
Tabla 4.13: Delay stack TCP/IP en red local 3G.

Delay TCP Delay APP
µ [ms] σ 2 [ms2 ]
1 0,22 3.3596 9.6296 5.7122 7.3347
10 22 11.2994 25.1678 40.8229 36.5749
50 102 51.4819 110.5654 200.2056 173.3555
100 202 101.6002 216.1954 410.9712 325.5303
Tabla 4.14: Delay stack TCP/IP en red visitada WLAN.
A partir de la figura 4.3, se evidencia una disminución en el delay IP Cliente-Servidor

de hasta un 56 % para el caso de menor latencia de red. En la medida que aumenta
el tiempo de viaje de los paquetes, esta disminución es cada vez menor llegando a
obtenerse un delay casi igual que sin servicio MIP en la red local 3G. En el caso del
camino Servidor-Cliente, el roaming hacia la red WLAN provoca una disminución de
más de un 70 % en el delay IP para la menor latencia asignada. En la medida que
aumenta el tiempo de viaje de los paquetes producto de las condiciones de la red, el
servicio MIP provoca un aumento en el delay IP de incluso un 80 % para el caso menos
favorable de mayor latencia. Esto último resulta coherente debido a que los paquetes
desde el servidor hacia el cliente deben se reruteados desde el HA pasando dos veces
por la nube. Respecto a los delays asociados a la capas de transporte y aplicación, se
muestra un aumento en el establecimiento de la sesión TCP de un 6.4 % para el caso
de menor latencia. Evidentemente para mayores latencias de la nube IP, mayor es la
variación en el delay 3-way handshake llegando a ser de un 37 %. El delay de control de
aplicación FTP muestra una disminución de casi un 30 % en el caso de menor latencia,
lo que en comparación con el delay 3-way handshake se explica puesto que este último
requiere de 3 paquetes de control en vez de 2.
Las tablas 4.15 y 4.16 muestran los delays experimentados por los paquetes de
aplicación de video en la red local 3G y visitada WLAN respectivamente. La tabla 4.17
72
Variación Delay IP con aplicación FTP Variación Delay 3-way Handshake y APP con aplicación FTP
100 50
Cliente-Servidor 3-way Handshake
80 Servidor-Cliente 40 Control Aplicación
60 30
Variación Delay (%)
40
Variación (%)
20
20 10
0
0
-20
-10
-40
-20
-60
-30
-80
1 2 3 4 1 2 3 4
Latencia Nube IP Latencia Nube IP
(a) (b)
Figura 4.3: Variación porcentual delays stack TCP/IP con aplicación FTP.
muestra el delay de control asociado al inicio y cierre del video sólo obtenido para el
caso de menor latencia de red asignada.

µ [ms] σ 2 [ms2 ]
1 0,22 8.8860 13.7661 8.8875 13.7685
10 22 18.1015 20.6009 18.1030 20.6032
50 102 57.5584 57.5650 57.5597 57.5680
100 202 107.2199 107.1930 107.2211 107.1977
Tabla 4.15: Delay a nivel IP y Aplicación en red local 3G.

µ [ms] σ 2 [ms2 ]
1 0,22 3.1345 5.9389 3.1347 5.940
10 22 12.3566 22.9246 12.3565 22.9255
50 102 52.1246 102.8036 52.1222 102.8060
100 202 102.2283 202.8412 102.228 202.8412
Tabla 4.16: Delay a nivel IP y Aplicación en red visitada WLAN.
Utilizando los valores de las tablas 4.15 y 4.16, la figura 4.4 muestra la variación
porcentual de los delays del stack TCP/IP cuando el cliente utiliza el servicio MIP en
la red visitada WLAN con respecto a los delays obtenidos en la red local 3G sin servicio
MIP.
73

[ms] [ms]
Red Local 3G 3.1285 3.0245
Red Visitada WLAN 4.3374 3.9202
Variación [ %] 38.64 29.61
Tabla 4.17: Delay control aplicación video.
Variación Delay IP con aplicación video Variación Delay paquete video

100 100
80 80
60 60

40 40
20 Cliente-Servidor 20 Cliente-Servidor
Servidor-Cliente Servidor-Cliente
0 0
-20 -20
-40 -40
-60 -60
1 2 3 4 1 2 3 4
(a) (b)
Figura 4.4: Variación porcentual delays stack TCP/IP con aplicación Video.
A partir de los datos obtenidos se evidencia muy poca diferencia entre los delays
asociados a nivel IP y de paquetes de video. En particular, la figura 4.4 muestra que el
delay IP disminuye en ambos sentidos al igual que el delay IP asociado a los paquetes
FTP. En el caso de la dirección Cliente-Servidor, el delay disminuye en un 65 % mientras
que en el sentido contrario lo hace en un 57 %. En la medida que aumenta la latencia
asignada a la red, mayor es la variación del delay Servidor-Cliente debido a que los
paquetes en viaje deben ser reruteados desde el GGSN hasta la red actual en la que se
encuentra el nodo móvil. Con respecto a los delays asociados al control de la aplicación
de video (inicio y cierre), la tabla 4.17 muestra un aumento de hasta un 39 % para
el caso de menor latencia. Esta variación positiva ocurre a pesar de que los delays a
nivel IP y Video disminuyen. Lo anterior podrı́a deberse al tiempo involucrado en el
procesamiento de los paquetes de control a nivel de red. Estos paquetes son de 1 y 64
bytes mientras que los paquetes asociados con carga desde la aplicación son del orden
de 1440 bytes. Al utilizar el servicio MIP en la red visitada, todos los paquetes desde el
servidor hacia el cliente (incluidos los de control) debe ser encapsulados en un header de
20 bytes. Esto último ha de suponer una mayor variación en el tiempo de procesamiento
para los paquetes significativamente más pequeños.
74
4.2.3. Roaming 3G/UMTS-WLAN usando MIP
Los resultados más relevantes durante el proceso de roaming de red se muestran

en la figura 4.5. Estos resultados se obtienen sólo para el caso más favorable de menor
latencia asignada a la nube IP. De acuerdo a la figura 4.5, tanto el tiempo de descarga
promedio como su desviación asociada disminuyen en un 57 %. Esto último se explica
pues a pesar de que el cliente se encuentra con servicio de movilidad IP, su acceso es
a través de una red WLAN de mayor ancho de banda. Los delays IP asociados a la
aplicación FTP y Video siguen la misma tendencia disminuyendo el delay IP en los dos
sentidos Cliente-Servidor. En la medida que aumenta la latencia asociada a la nube IP
(no mostrado de manera gráfica), ambas aplicaciones dan cuenta de la asimetrı́a en el
ruteo de los paquetes al integrar MIP a la red. En el caso particular del roaming de
red, los resultados sólo arrojan la pérdida de un paquete de aplicación de video desde
el servidor hacia el cliente. Esta pérdida se produce durante el tiempo involucrado en
el establecimiento del servicio MIP estimado en 18 ms.
Tiempo de descarga archivo FTP roaming 3G-WLAN Delay IP - Roaming 3G-WLAN con aplicación FTP
7 70
Servidor - Cliente
6.5 Cliente - Servidor
60
6
50
5.5
Tiempo (s)
Delay (ms)
5 40
4.5 30
4
20
3.5
10
3
2.5 0
Sin MIP Con MIP Sin MIP Roaming de red Con MIP
(a) (b)
Delay IP - Roaming 3G-WLAN con aplicación video

25
Servidor - Cliente
Cliente - Servidor
20
Delay (ms)
15
10
0
Inicio video Roaming de red Fin video
(c)
Figura 4.5: Roaming 3G/WLAN.
75
4.3. Resultados pruebas Proxy Mobile IP en am-

biente 3G/UMTS-WLAN
En esta sección se exponen los resultados de PMIP en ambiente interconectado
3G/WLAN utilizando la implementación generada para este trabajo del protocolo MIP.
El posicionamiento del LMA se supone en la red 3G a través del GGSN con soporte
de protocolo GTP, pero además se le agrega funcionalidades de PMIP con soporte de
túnel PMIP. El cambio desde la red 3G hacia la red WLAN se estima en 1.9 [ms]
correspondiendo sólo al tiempo involucrado en la señalización entre el MAG y el LMA
para establecer el servicio PMIP. Se asume que la tarjeta WLAN del cliente se encuentra
en modo scan por lo que no existe desconexión a nivel L2 y por lo tanto no es necesario
incluir los costos de reestablecimiento de capas inferiores en el delay de handover.
Las tablas 4.18 y 4.19 exponen los resultados obtenidos para el escenario de Proxy
Mobile IP en la red 3G y WLAN respectivamente con la aplicación FTP.
Delay TCP Delay APP
µ [ms] σ 2 [ms2 ]
1 0,22 7.7828 33.5798 5.4099 10.6031
10 22 15.4945 28.4397 32.4997 29.3785
50 102 52.8938 65.8494 152.0368 118.9841
100 202 103.3193 119.4046 304.0917 226.4398
Tabla 4.18: Delay stack TCP/IP en red local 3G.

Delay TCP Delay APP
µ [ms] σ 2 [ms2 ]
1 0,22 3.4047 9.443 4.6589 6.205
10 22 11.4017 14.3785 31.6579 25.8446
50 102 51.8138 57.7664 153.1203 115.8188
100 202 102.4123 111.8679 302.9353 230.2909
Tabla 4.19: Delay stack TCP/IP en red visitada WLAN usando PMIP.
Utilizando los valores de las tablas 4.18 y 4.19, la figura 4.6 muestra la variación
porcentual de los delays del stack TCP/IP cuando el cliente utiliza el servicio PMIP en
la red visitada WLAN con respecto a los delays obtenidos en la red local 3G sin servicio
PMIP.
76
A partir de la figura 4.6 se tiene que el delay IP en ambos sentidos Cliente-Servidor

disminuye para todos los casos de latencia asignada a la red. Esto último es coherente
puesto que no existe un ruteo triangular en el caso de PMIP. Particularmente en el sen-
tido Cliente-Servidor se experimenta una baja del delay IP de hasta un 56[ %] mientras
que en el sentido contrario es de hasta un 72[ %]. En el caso de los delays asociados a
las capas de transporte y aplicación, la figura 4.6 muestra una disminución en ambos
casos, siendo más notorio en el delay de control de aplicación de 42[ %] para la latencia
más baja asignada a la red.
Variación Delay IP con aplicación FTP Variación Delay 3-way Handshake y APP con aplicación FTP
0 5
-10 0
-5
-20

-10
-30 -15
-40 Cliente-Servidor -20 3-way Handshake
Servidor-Cliente Control Aplicación
-50 -25
-30
-60
-35
-70 -40
-80 -45
1 2 3 4 1 2 3 4
(a) (b)
Figura 4.6: Variacion porcentual de los delays stack TCP/IP con aplicación FTP.
Las tablas 4.20 y 4.21 exponen los resultados obtenidos para el escenario de PMIP
en la red 3G y WLAN respectivamente con la aplicación de Video conferencia. La
tabla 4.22 muestra los delays asociados al control del inicio y cierre del video sólo para
el caso de menor latencia de red.
µ [ms] σ 2 [ms2 ]
1 0,22 13.9623 8.8246 13.9644 8.8270
10 22 20.6377 17.8625 20.6393 17.8649
50 102 57.6808 57.4783 57.6817 57.4779
100 202 107.1585 107.7563 107.1684 107.7566
Tabla 4.20: Delay a nivel IP y Aplicación en red local 3G.
77

µ [ms] σ 2 [ms2 ]
1 0,22 3.1688 4.6508 3.1690 4.6519
10 22 12.5218 12.4878 12.5218 12.4887
50 102 52.2045 52.3115 52.2031 52.3111
100 202 102.0115 102.2682 102.0157 102.2710
Tabla 4.21: Delay a nivel IP y Aplicación en red WLAN usando PMIP.

[ms] [ms]
Red Local 3G 3.6343 3.673
Red Visitada WLAN 2.9554 2.6952
Variación [ %] -19 -27
Tabla 4.22: Delay control aplicación video.
La figura 4.7 muestra la variación porcentual de los delays del stack TCP/IP cuando
el cliente utiliza el servicio PMIP en la red visitada WLAN con respecto a los delays
obtenidos en la red local 3G sin servicio PMIP. Las tablas 4.20 y 4.21 muestran poca
diferencia para los delays a nivel IP y de paquete de video. Particularmente la figura 4.7
expone una tendencia a disminuir el delay en ambos sentidos Cliente-Servidor cuando
se accede por medio de la red WLAN para las 4 latencias de red. En el caso de los
paquetes desde el servidor hacia el cliente se tiene una disminución de hasta un 47 %
mientras que en el sentido contrario llega a un 77 %, ambos para el caso más favorable
de menor latencia. Se evidencia también mayor simetrı́a en los delays para ambas direc-
ciones, puesto que a diferencia de MIP, PMIP no incorpora ruteo triangular siendo más
idoneo para aplicaciones en tiempo real. Respecto a los delays asociados al control de
la aplicación de video, para el caso de menor latencia de red se tiene una disminución
de hasta un 27 % que a diferencia de MIP, se debe a que el reply desde el servidor no
sufre de ruteo triangular por lo que no incorpora latencias adicionales.
78
Variación Delay IP con aplicación Video Variación Delay paquete video

0 0
-10 -10
-20 -20

-30 -30
-40 Cliente-Servidor -40 Cliente-Servidor
Servidor-Cliente Servidor-Cliente
-50 -50
-60 -60
-70 -70
-80 -80
1 2 3 4 1 2 3 4
(a) (b)
Figura 4.7: Variación porcentual delays stack TCP/IP con aplicación Video.
4.3.3. Roaming 3G/UMTS-WLAN usando PMIP
La figura 4.8 muestra los resultados en el roaming de red usando PMIP. Los re-
sultados muestran una disminución en los delays IP en ambas direcciones tanto para
la aplicación FTP como la de video. El promedio del tiempo de descarga disminuye
en un 58 [ %] mientras que su desviación baja en un 67 [ %]. Particularmente, con el
delay asignado para el roaming de red de 1.9 [ms] no existen pérdidas de paquetes de
aplicación.
4.4. Resultados globales de Aplication Delay Trac-

king package
En esta sección se presentan de manera global los resultados obtenidos con el ADT
de OPNET. Este package integrado en el simulador realiza un tracking de los mensajes
entre nodos comunicantes entregando una razón de tiempo que dichos mensajes expe-
rimentan a nivel de aplicación y de red. Los resultados se exponen en las tablas 4.23 y
4.24 para el caso de menor latencia sólo con aplicación FTP.
Las tablas 4.23 y 4.24 muestran una disminución en los porcentajes de tiempos
promedios de permanencia de los paquetes FTP a nivel IP y de aplicación cuando el
cliente descarga desde la red WLAN usando los servicios MIP y PMIP. En el caso
del roaming WLAN-WLAN, los resultados exponen un incremento de estos tiempos.
OPNET genera un aumento importante en el promedio y la desviación en comparación
79
Tiempo de descarga archivo FTP roaming 3G-WLAN usando PMIP Delay IP - Roaming 3G-WLAN usando PMIP con aplicación FTP
7 70
Servidor - Cliente
Cliente - Servidor
60
6
50
Tiempo (s)
Delay (ms)
5
40
30
4
20
3
10
2 0
Sin PMIP Con PMIP Sin MIP Roaming de red Con MIP
(a) (b)
Delay IP - Roaming 3G-WLAN usando PMIP con aplicación video

25
Servidor - Cliente
Cliente - Servidor
20
Delay (ms)
15
10
0
Inicio video Roaming de red Fin video
(c)
Figura 4.8: Roaming 3G\WLAN usando PMIP.
Red Local Red Visitada

Ambiente [ %] Nivel Red [ %] Nivel App [ %] Nivel Red [ %] Nivel App
MIP OPNET 61.34 38.66 84.92 15.08
WLAN-WLAN
MIP Propio 61.85 38.15 62.14 37.86
MIP 83.85 16.15 62.26 37.74
3G-WLAN
PMIP 84.00 16.00 62.01 37.99
Tabla 4.23: Resultados ADT de OPNET promedio proporción red y aplicación.
con MIP desarrollado para este trabajo. Esto último también puede verse relejado en
los tiempos de descarga asociados (ver figura 4.1a)
80
Red Local Red Visitada

Ambiente [ %] Desviación Proporción [ %] Desviación Proporción
MIP OPNET 2.5984 14.693
WLAN-WLAN
MIP Propio 0.1403 0.107
MIP 0.0806 0.1743
3G-WLAN
PMIP 0.0815 0.1769
Tabla 4.24: Resultados ADT de OPNET desviación promedio proporción red y apli-
cación.
4.5. Comparación Mobile IP OPNET versus imple-

mentación propia en ambiente WLAN-WLAN
En esta sección se comparan los resultados obtenidos con OPNET y con el diseño
creado para este trabajo de MIP para un ambiente WLAN-WLAN. Las figuras 4.9 y
4.10 exponen las comparaciones de manera gráfica. Las figuras 4.11 y 4.12 muestran la
variación de los delays del stack TCP/IP cuando el cliente utiliza el servicio MIP.
Los resultados con MIP desarrollado para este trabajo y el de OPNET evidencian
el ruteo triangular caracterı́stico del protocolo tanto para FTP como Video. De igual
forma se muestra un aumento en los delays de control asociados a las capas de transporte
y aplicación. En el caso de FTP sin servicio MIP existe una asimetrı́a en el delay IP
entre ambos sentidos lo cual se explicarı́a dada la diferencia en tamaño de los paquetes
que en el sentido Servidor-Cliente llevan carga mientras que en la otra dirección llevan
sólo el header TCP como payload.
Las mayores diferencias entre los resultados propios y de OPNET se observan en las
figuras 4.11 y 4.12. En el caso de la aplicación FTP con menor latencia asignada a la
red, OPNET disminuye el delay IP en un 20 % y en un 30 % para los sentidos Cliente-
Servidor y Servidor-Cliente respectivamente. La disminución en el delay IP Servidor-
Cliente no resulta lógico puesto que los paquetes en dicha dirección son reruteados desde
el HA.
En el caso de la aplicación de video, las mayores diferencias observadas en las va-
riaciones de los delays obtenidos con OPNET y la implementación propia, no superan
el 5 %.
81
Delay IP Red Local Delay IP Red Visitada

120 220
Cl-Sv MIP OPNET Cl-Sv MIP OPNET
Sv-Cl MIP OPNET 200 Sv-Cl MIP OPNET
100 Cl-Sv MIP Propio 180 Cl-Sv MIP Propio
Sv-Cl MIP Propio Sv-Cl MIP Propio
160
80
140
Delay (ms)
Delay (ms)
120
60
100
80
40
60
20 40
20
0 0
1 2 3 4 1 2 3 4
(a) Delay IP red local (b) Delay IP red visitada

Delay 3-way Handshake Red Local Delay 3-way Handshake Red Visitada
MIP OPNET 400 MIP OPNET

300
MIP Propio MIP Propio
350
250
300
200
Delay (ms)
Delay (ms)
250
150 200
150
100
100
50
50
0 0
1 2 3 4 1 2 3 4
(c) Delay 3-way Handshake red local (d) Delay 3-way Handshake red visitada
Delay control aplicación Red Local Delay control aplicación Red Visitada
250 350
MIP OPNET MIP OPNET
300
200
250
Delay (ms)
Delay (ms)
150 200
100 150
100
50
50
0 0
1 2 3 4 1 2 3 4
(e) Delay control aplicación red local (f ) Delay control aplicación red visitada
Figura 4.9: Comparación MIP OPNET versus MIP desarrollado para este trabajo con
aplicación FTP.
82
Delay IP Red Local Delay IP Red Visitada

120 220
160
80
140
Delay (ms)
Delay (ms)
120
60
100
80
40
60
20 40
20
0 0
1 2 3 4 1 2 3 4
(a) Delay IP red local (b) Delay IP red visitada

Delay Paquete Video Red Local Delay Paquete Video Red Visitada
120 220
160
80
140
Delay (ms)
Delay (ms)
120
60
100
80
40
60
20 40
20
0 0
1 2 3 4 1 2 3 4
(c) Delay Paquete Video red local (d) Delay Paquete Video red visitada
Figura 4.10: Comparación MIP OPNET versus MIP desarrollado para este trabajo
con aplicación Video.
83
Variación Delay IP Cliente-Servidor con aplicación FTP Variación Delay IP Servidor-Cliente con aplicación FTP
0 100
-2 90
-4 80
-6 70

-8 60
-10 50
-12 MIP OPNET 40 MIP OPNET
-14 MIP Propio 30 MIP Propio
-16 20
-18 10
0
-20
-10
-22
-20
-24
-30
1 2 3 4 1 2 3 4
(a) (b)
Variación Delay 3-way Handshake con aplicación FTP Variación Delay Control aplicación FTP
40 60
50
30 40

20 20
10
10 0
1 2 3 4 1 2 3 4
(c) (d)
Figura 4.11: Variación delay TCP/IP para aplicación FTP.
84
Variación Delay IP Cliente-Servidor con aplicación Video Variación Delay IP Servidor-Cliente con aplicación Video
100
90
80

0 70
50
40
30
20
-2
1 2 3 4 1 2 3 4
(a) (b)
Variación Delay Paquete Video Cliente-Servidor Variación Delay Paquete Video Servidor-Cliente
100
90
80
0 70
50
40
30
20
-2
1 2 3 4 1 2 3 4
(c) (d)
Figura 4.12: Variación delay TCP/IP para aplicación Video.
85
Capı́tulo 5
Conclusiones
5.1. Objetivos
En este trabajo se desarrolla un modelo de interconexión de redes móviles y WLANs
con integración de un protocolo de movilidad IP utilizando simulaciones de redes. Este
modelo permite que las sesiones de internet de un usuario puedan ser mantenidas a
pesar de existir un roaming de red.
En primer lugar se selecciona el software OPNET Modeler como ambiente de simu-
lación para llevar a cabo el trabajo. Luego se configura un esquema de movilidad IP con
roaming del tipo WLAN-WLAN utilizando el protocolo Mobile IP implementado por
OPNET. Posteriormente se desarrolla un modelo de interconexión de redes 3G\UMTS
y WLAN con incorporación de MIP. Esto último requiere el desarrollo de una estación
de trabajo dual que soporte ambas tecnologı́as de acceso de manera nativa. Debido a
la complejidad de integrar en un único modelo de nodo dos interfaces de acceso hete-
rogéneas, se opta por diseñar un cliente dual con dos interfaces WLANs variando los
parámetros de una de ellas para emular la interfaz UMTS. El protocolo MIP se diseña
para ser integrado en la estación dual. Finalmente se implementa un esquema de inter-
conexión 3G/UMTS-WLAN con integración de PMIP en base a los nodos desarrollados
previamente.
El estudio de la perfomance de los protocolos se hace con las aplicaciones: FTP, con
TCP en el control y transporte; y Video conferencia, de baja resolución con transporte
UDP. La variación del estado del backbone de internet se emula con asignaciones de
distintas latencias.
86
CAPÍTULO 5. CONCLUSIONES
5.2. Desarrollo
El desarrollo de la estación dual con integración de dos interfaces logra simular un
dispositivo multimodo capaz de decidir cuál acceso utilizar en un ambiente heterogéneo.
Esta estación presenta la limitante de usar sólo modelos de procesos programados para
emular interfaces WLAN. Esto último también limita la implementación de la red móvil
en base a modelos WLAN variando sus parámetros para lograr una emulación más real.
A pesar de lo anterior, la implementación y posterior integración de protocolos
Mobile IP, tanto en la red como en el cliente, entregan una plataforma simple en OPNET
para el análisis de protocolos de movilidad IP en base a métricas comunes dentro de un
ambiente interconectado.
5.3. Resultados
Los resultados en ambiente WLAN-WLAN incoporando MIP de OPNET muestran
que existen algunos problemas con la implementación del protocolo MIP en el software.
En particular la disminución del delay IP Servidor-Cliente en el caso de menor latencia
con FTP se interpreta como un resultado erróneo.
Por otro lado, los resultados del package ADT muestran gran desviación en la pro-
porción [tiempo red]/[tiempo aplicación] al incorporar el servicio MIP de OPNET.
Adicional a lo anterior, los resultados ADT también interpretan pérdidas inexistentes
de paquetes durante el servicio MIP 1 , lo que ha de suponer que la programación del
protocolo no fue bien integrada con el resto del software.
Respecto al uso de un protocolo de movilidad IP por parte de un cliente cambiándose
entre redes WLANs, los resultados evidencian el ruteo triangular y un aumento en
los delays de control de transporte y aplicación. Para el caso de menor latencia, el
establecimiento de la sesión TCP y FTP toman un 21.94 % y un 17.97 % adicional
mientras que el promedio en el control de video asociado a los requerimientos de inicio
y cierre aumentan en un 30 %.
Los resultados del modelo interconectado 3G-WLAN con servicio MIP muestran que
el cambio hacia la red WLAN de mayor ancho de banda disminuye los delay IPs de los
paquetes tanto de aplicación FTP como de video, en ambas direcciones, considerando
la menor latencia asignada. Esta disminución ocurre a pesar del reruteo de paquetes
situándose entre 56 % y 71 %. El delay asociado al control de la aplicación FTP de
descarga baja en un 29 %.
1
Esta interpretación errónea de pérdidas sólo ocurre cuando los paquetes requieren de particiones
a nivel IP producto del MTU de la capa de enlace.
87
El establecimiento de la sesión TCP en cambio, aumenta en un 7 % incluso en el caso

de menor latencia. En la medida que el backbone de internet retiene mayor tiempo a los
paquetes ruteados desde la red local a la visitada, la ineficiencia del ruteo triangular se
hace más evidente resultando completamente inadecuado en especial para aplicaciones
como la transmisión de video. Respecto a este último, con la mayor latencia asignada
a la nube IP, el delay IP Servidor-Cliente supera la recomendación G.114 de la ITU la
cual establece un máximo de 150 ms en el delay end-to-end para aplicaciones en tiempo
real.
Los resultados del modelo interconectado con PMIP muestran una disminución del
delay IP usando las dos aplicaciones incluyendo todas las latencias asignadas a la nube
IP. Esto último se debe al ambiente localizado con el que trabaja PMIP además de no
incorporar un ruteo triangular en su estructura. Los delays del establecimiento de la
sesión TCP y el control de la aplicación FTP también experimentan una disminución
en todos los casos. Particularmente para la menor latencia, el 3-way handshake baja
en un 14 % y establecimiento de la aplicación FTP en un 42 %. La incorporación del
protocolo PMIP, a diferencia de MIP, no provoca en ningún caso la superación de los
150 ms máximos permitidos en el delay end-to-end siendo esto último idóneo para la
aplicación de video.
5.4. Discusión y trabajos futuros

El roaming de sesiones a nivel IP resulta una propuesta atractiva de ser incorporada
en el internet del futuro. Una de las ventajas de enfrentar el problema desde el nivel
de red es la indiferencia para con la tecnologı́a de acceso utilizada. Esto último hace
viable interconexiones, por ejemplo, de redes móviles y WLANs.
La ineficiencia del ruteo triangular de MIP se evita en su versión IPv6, sin embargo
una de sus desventajas sigue siendo el involucramiento del cliente móvil en la señali-
zaciones del protocolo, haciéndolo ineficiente cuando el cliente tiene una alta tasa de
cambio. En ese sentido, PMIP aparece como una buena solución de ser usado en am-
bientes locales siguiendo una estructura jerarquizada con MIP en ambiente globalizado.
La incorporación de MIP en la red permite mantener las sesiones de los usuarios
a pesar del cambio fı́sico de conexión a la red, sin embargo su uso también ha dejado
en evidencia vulnerabilidades en el tema de seguridad de los datos. Esto último motiva
a proponer el estudio de mecanismos de defensas a ataques maliciosos como trabajo
futuro.
Por otro lado, el impacto sobre los dispositivos tı́picos de red como bases de datos,
servidores AAA, sistemas de billing, etc. al incorporar un protocolo de movilidad, pue-
de afectar el rendimiento global de funciones asociadas al plano de control de la red,
88
tales como el establecimiento, mantención y liberación de conexiones. Esto debido a

las señalizaciones involucradas en los distintos protocolos de movilidad, lo cual necesa-
riamente requiere de distintos accesos, por ejemplo, a servidores de autentificación. El
estudio de rendimientos de la red frente a diversos protocolos de movilidad constituye
un trabajo futuro a desarrollar en esta lı́nea.
Adicionalmente el entregar soluciones al problema de movilidad desde las capas su-
periores, tales como de transporte y aplicación, es una potencial arista de investigación
a desarrollar. La comparación entre estos procotolos, por ejemplo MIP, mSCTP, y SIP,
podrı́a determinar cuál conviene utilizar según el tipo de aplicación que se esté utili-
zando.
89
Capı́tulo 6
Bibliografı́a
[1] Wireless Application. Muniwireless wi-fi, lte, smartgrids applications. http://

www.muniwireless.com/category/city-county-wifi-networks/.
[2] Jerry Banks, John S. Carson II, Barry L. Nelson, and David M. Nicol. Discrete-
event system simulation. Prentice Hall, 2005.
[3] D. Cavalcanti, D. Agrawal, C. Cordeiro, Bin Xie, and A. Kumar. Issues in inte-
grating cellular networks wlans, and manets: a futuristic heterogeneous wireless
network. Wireless Communications, IEEE, 12(3):30 – 41, Junio 2005.
[4] A.C. Chen. The evolution of wireless mobile data communication technologies and
their market opportunities. In IECON 02 [Industrial Electronics Society, IEEE
2002 28th Annual Conference of the], volume 4, pages 3428 – 3433, Noviembre
2002.
[5] Jyh-Cheng Chen and Wei-Ming Chen. Design and analysis of a mobility gateway
for gprs-wlan integration. Vehicular Technology, IEEE Transactions on, 56(5):2603
– 2616, Septiembre 2007.
[6] Cisco.com. Bandwidth, packets per second, and other network perfor-
mance metrics. www.cisco.com/web/about/security/intelligence/network_
performance_metrics.html.
[7] Cisco.com. Cisco visual networking. http://www.cisco.com/en/US/solutions/

collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360_
ns827_Networking_Solutions_White_Paper.html.
[8] Cisco.com. Cisco visual networking. http://www.cisco.com/en/US/solutions/

collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-520862.
html.
90
BIBLIOGRAFÍA
[9] Ashutosh Dutta, Byungsuk Kim, Tao Zhang, S. Baba, K. Taniuchi, and Y. Ohba.
Experimental analysis of multi interface mobility management with sip and mip.
In Wireless Networks, Communications and Mobile Computing, 2005 International
Conference on, volume 2, pages 1301 – 1306, Junio 2005.
[10] Amr Ergawy. Multilayered mobility managment in next generation wireless. TKK
T-110.5190 Seminar on Internetworking, 2007.
[11] WiFi Foundation. Provider of networked wi-fi hot spots. http://www.

wififoundation.org/.
[12] Andrea Goldsmith. Wireless Communications. Stanford University, 2004.
[13] James Grass, Klaus Wehrle, and Mesut Günes. Modelling and Tools for network
simulation. Springer Heidelberg, 2010.
[14] Mark Grayson, Kevin Shatzkamer, and Klaas Wierenga. Building the Mobile In-
ternet. Cisco Press, 2011.
[15] Sri Gundavelli. Is network-based mobility management? IP NGN Architecture

Thought Leadership Journal, 2010.
[16] IETF.org. Ip performance metrics. http://www.ietf.org/dyn/wg/charter/

ippm-charter.
[17] Sibaram Khara and Asish K. Mukhopadhyay. An efficient method of mobile ip

based handoff mechanism for wlan. Journal of Theoretical and Applied Information
Technology, 2007.
[18] Ki-Sik Kong, Wonjun Lee, Youn-Hee Han, Myung-Ki Shin, and HeungRyeol You.
Mobility management for all-ip mobile networks: mobile ipv6 vs. proxy mobile
ipv6. Wireless Communications, IEEE, 15(2):36 –45, april 2008.
[19] Heikki Lindholm, Taneli Vähäkangas, and Kimmo Raatikainen. A control plane
benchmark for telecommunications signalling. Department of Computer Science,
University of Helsinki, Finland, ????
[20] Ismat Maarouf and Mohammed Aabed. A comparative analysis of different integra-
tion approaches between umts-wlan. COE587: PERFORMANCE EVALUATION
ANALYSIS, 1, 2006.
[21] L.A. Magagula, O.E. Falowo, and H.A. Chan. Pmipv6 and mih-enhanced pmipv6
for mobility management in heterogeneous wireless networks. In AFRICON, 2009.
AFRICON ’09., pages 1 –5, sept. 2009.
91
BIBLIOGRAFÍA
[22] T. Magedanz, P. Weik, D. Vingarzan, F. Carvalho de Gouveia, and S. Wahle.

Experiences on the establishment and provisioning of ngn/ims testbeds -the fokus
open ims playground and the related open source ims core. ????, ????
[23] A. Mahmoud, A.-A. Al-Helali, M. Abu-Amara, T. Al-Kharobi, and T. Sheltami.

Comparative performance study for integrated 3g/wlan networks using mobile ip,
sip, and m-sctp protocols. In Vehicular Technology Conference (VTC 2010-Spring),
2010 IEEE 71st, pages 1 – 5, Mayo 2010.
[24] Deepankar Medhi and Karthikeyan Ramasamy. Network Routing Algorithms Pro-
tocols and Architectures. Morgan-Kaufmann, 2007.
[25] OPNET. Opnet modeler. www.opnet.com/solutions/network_rd/modeler.

html.
[26] Jianli Pan. A survey of network simulation tools: Current status and future de-
velpments. ????, 2008.
[27] Radia Perlman. Interconnections: Bridges, Routers, Switches, and Internetworking

Protocols. Addison-Wesley Proffesional, 2000.
[28] M. Rahman, F. Harmantzis, and V. Gunasekaran. Qos for inter-wlan ip mobi-

lity with high speed accessed network server. In Wireless Communications and
Networking Conference, 2005 IEEE, volume 3, pages 1564 – 1569, Marzo 2005.
[29] M. Seltzer, D. Krinsky, K. Smith, and Zhang Xiaolan. The case of application-
specific benchmarking. ????, ????
[30] I. Soto, C. Bernardos, M. Calderón, T. Melia, and Alcatel Lucent Bell Labs.
PMIPv6: A Network-Based Localized Mobility Management Solution-The Internet
Protocol Journal - Volume 13, Number 3 - Cisco Systems. 2010.
[31] R. Surender, G. Sivaradje, and P. Dananjayan. Performance comparison of umts-

wlan integrated architectures. International Journal of Communication Networks
and Information Security (IJCNIS), 2009.
[32] D. Swain, S. Prasada Panigrahi, and P. Kumar Patra. A micro-mobility mana-

gement scheme for handover and roaming. International Journal of Computer
Science and Security (IJCSS), 2012.
[33] Jun Tian and A. Helal. Performance of mip/wlan in rapid mobility environments.
In Computer Systems and Applications, 2006. IEEE International Conference on.,
pages 919 – 927, Agosto 2006.
[34] Alper Yegin and Carl Williams. Ipv6: Necessary for mobile and wireless. Internet
Society, 2003.
92
BIBLIOGRAFÍA
[35] Christer Åhlund, Robert Brännström, and Arkady Zaslavsky. M-mip extended
mobile ip to maintain multiples connections. Springer Berlin Heidelberg, 2005.
93
Anexo A
Protocolos y tecnologı́as disponibles

en OPNET Modeler
Protocols and Technologies

CBR Remote login/TELNET Megaco (H.248)
Custom Self-Similar Traffic (RPG) cRTP
Database VBR MPEG-2
Application Email Voice SIP in the 3GPPP IMS
FTP VoIP-SIP,RTP,H.323AS-SIP SIP-MIP in IMS
HTTP Video Snoop
MOS Dejitter Buffer Video On Demand
UDP TCP (ECN,Reno, New Reno, Stop-N-Wait
Transport Accelerator 400 SACK, Tahoe)
SCPS-TP (TAO) Performance Enhancing Proxy (PEP)
BGP OSPF DSBM
EIGRP OSPFv3 Dynamic Distributed
IGRP RIPng DBGP+
Routing
ISIS Static Routes Static Distributed
IP Distance Vector (for ATM Networks)
PNNI
IPv4 Mobile IPv4 ASI
IPv6 Mobile IPv6 Multistage
Juniper DiffServ HSRP Interconnection
Network WRED RSVP Network
Network Initiated
Handover (NIHO)
REAP
94
ANEXO A. PROTOCOLOS Y TECNOLOGÍAS DISPONIBLES EN OPNET
MODELER
Protocols and Technologies

IMGP
Multicasting PIM-SM
Static RP / Auto RP
CSPF IGP Extensions (OSPF-TE / ISIS-TE)
MPLS Fast Reroute Signaling (LDP / RSVP-TE)
VPN Tunneling Over MPLS (6PE)
802.1p DWFQ/CBWFQ
CAR/Policing DWRR/MDRR/MWRR
QoS CQ LLQ with Rate Limit
FIFO TOS/DSCP - based classification
PQ WRED/RED
DSL Custom Link Models DVB-DAVIC
ISDN (OPNET Pipeline Stages) DVB-T
PPP Infiniband
Physical SLIP IrDA
SONET J1850
Linear Lightwave
UPnP
ATM (including IMA) Frame Relay Banyan Multistage
ATM Hierarch. PVP LANE Cell Switch
CSMA, CSMA/CA, LAPB CAN
CSMA/CD Link Aggregation (including CFDAMA-PB
DPT/SRP EtherChannel) DCCP
Ethernet (coax, SNA Delay-Sensitive
10baseT, 100baseT, Spanning Tree Polling Scheme
MAC 1000baseT, 10 Gbps) Token Ring DQDB WAN (802.6)
FDDI VLAN Port-based (PVSTP, Ethernet OAM
Fiber Channel MSTP, RSTP) Firewire IEEE 1394b
X.25 RPR (802.17)
Slotted ALOHA
DOCSIS
Media Redundancy
Protocol (MRP)
95
Anexo B
Redes celulares 3G
B.1. Sistemas 3G
Las redes 3G nacieron a través del estándar IMT-2000 International Mobile Tele-
communications definido por la asociación internacional de telecomunicaciones ITU.
Su principal objetivo es proveer la movilidad global integrando servicios de telefonı́a,
paging, mensajerı́a, banda ancha e Internet.
Las especificaciones técnicas de las redes 3G son realizadas por el grupo de trabajo
3GPP Third Generation Partnership Project conformado en 1998. 3GPP ha estandari-
zado 5 áreas UMTS definidas como: Red de acceso de radio, RAN; red de núcleo, Core
Network; terminales, servicios y la red de acceso de radio EDGE GSM, GERAN.
B.1.1. Servicios UMTS
La tasa de transmisión de datos ofrecidas por UMTS corresponden a 144 kbits/s,

para zonas rurales; 384 kbits/s para ambientes outdoor urbanos y 2040 kbits/s, pa-
ra ambientes indoor y de baja cobertura. Adicionalmente, UMTS distingue diferentes
clases de QoS para 4 tipos de tráfico. Estas clases corresponden a:
Clase Conversacional: voz, telefonı́a video y video gaming.
Clase Streaming: multimedia, video on demand y webcast.
Clase Interactiva: web browsing, network gaming y acceso a base de datos.
Clase Background: email, SMS y descargas.
96
ANEXO B. REDES CELULARES 3G
B.1.2. Arquitectura UMTS
La arquitectura de red UMTS puede ser descompuesta en tres dominios: Dominio

de red de núcleo (CN), Red de acceso de radio terrestre basada en UMTS (UTRAN) y
el equipo del usuario (UE).
El dominio de red de núcleo se basa en el servicio de radio para paquetes (GPRS)
implementado inicialmente sobre las redes 2G. El CN implementa la funciones relacio-
nadas con el manejo de la red. Es el encargado de proveer el switching, ruteo y tránsito
del tráfico de los usuarios, además de manejar las bases de datos.
La red de acceso de radio UTRAN provee la interfaz de aire para la transmisión de
la información. Se compone de estaciones bases denominadas Node-B, las cuales son
manejadas por un controlador de red de radio (RNC).
B.1.2.1. Red de núcleo
La red de núcleo comprende los dominios CS y PS. El dominio PS se constituye de

dos principales nodos: Nodo Gateway de Soporte GPRS (GGSN) y Nodo de Servicio
de Soporte GPRS (SGSN).
GGSN
Constituye el gateway que provee a los usuarios el acceso hacia las redes de datos
públicas o redes IP privadas
SGSN
Este nodo conecta la red de acceso de radio con la red de núcleo GPRS/UTMS. El
SGSN se encarga del tunneling de las sesiones del usuario hacia el GGSN usando el
protocolo GPRS Tunneling Protocol GTP. Adicionalmente contiene la información so-
bre la locación de las estaciones moóviles.
B.1.2.2. Red acceso de radio
La interfaz de aire UTRAN utiliza la tecnologı́a Wide band CDMA conocida como
WCDMA. Esta última opera con los modos de operación: Frequency Division Duplex,
FDD; y Time Division Duplex, TDD. Con respecto a los Nodos-B, estos últimos se
encargan principalmente de:
97
ANEXO B. REDES CELULARES 3G
Transmisión/Recepción de datos.
Técnicas de Modulación/Demodulación. Manejo de los códigos de canales fı́sicos.
Microdiversidad.
Manejo de errores.
Control de potencia en lazo cerrado.
Dentro de las funcionalidades del controlador de la red de radio RNC, se tienen:
Control de los recursos de radio.
Control de admisión y asignación de canales.
Establecimiento de los controles de potencia.
Control de handovers.
Macrodiversidad.
Cifrado, segmentación y reensamblamiento.
Señalización de broadcasting.
B.1.2.3. Equipo del usuario UE
El UE trabaja directamente con la interfaz de aire siendo la contraparte del Nodo-B.

Este terminal puede operar en tres modos: Modo PS/CS, en el cual el UE puede operar
simultáneamente los servicios PS y CS; Modo PS, en el cual el UE sólo opera en el
dominio PS; y CS, donde el terminal sólo usa los servicios CS.
98
Anexo C
Esquemas de interconexión entre

redes de accesos 3G/UTMS y
WLAN
Existen diversos esquemas de interconexión entre redes 3G y WLAN los cuales se

focalizan principalmente en los requerimientos de autentificación del usuario, control
de charging y data records; y procedimientos de handovers. El Instituto de Estándares
de Telecomunicaciones Europeo (ETSI) ha definido dos enfoques genéricos de inter-
conexión: loose coupling y tight coupling. En el caso loose coupling, ambas redes son
desplegadas de manera independiente por lo que no existe real integración. En el esque-
ma tight coupling la red WLAN se conecta directamente con el núcleo de red UMTS
pasando a ser otra red de acceso a la red 3G.
C.1. Esquema loose coupling

Las redes 3G y WLAN son desplegadas e interconectadas de manera independiente.
La red WLAN se conecta a la red IP manteniendo un enlace indirecto con la red UMTS.
Desde el punto de vista de esta última la red WLAN se encuentra más allá del GGSN. El
roaming entre ambas redes es soportado a través de algún protocolo de movilidad, por
ejemplo Mobile IP. La red WLAN puede conectarse con los servicios AAA permitiéndole
al proveedor del servicio UMTS generar un estado de billing integrado. La figura C.1
ilustra el equema loosing coupling.
Una de las principales ventajas de utilizar este esquema de interconexión es su bajo
costo. Esto último se debe a la independencia de las redes, tanto a nivel de despliegue
como de operación, sin requerir mejoras en los nodos de ambas redes. Dentro de las
99
ANEXO C. ESQUEMAS DE INTERCONEXIÓN ENTRE REDES DE ACCESOS
3G/UTMS Y WLAN
desventajas del esquema, se tiene la gran latencia que supone el tránsito del tráfico de
señalización y datos al tener las redes interconectadas a través del internet. Esto último
puede afectar directamente aplicaciones en tiempo real del usuario.
C.2. Esquema tight coupling

En este esquema la red WLAN se encuentra directamente conectada a la red UMTS
pasando a ser parte de otra red de acceso de radio. Los requerimientos de seguridad,
autentificación y manejo de la red son comunes con los de la red UMTS. La interconexión
de la red WLAN se muestra en la figura C.1.
La eficiencia en el manejo de la movilidad entre las redes constituye una de las
principales ventajas de este esquema. Esto último supone la reducción en el delay del
handover, ası́ como también el uso de los recursos de la red UMTS, bases de datos,
sistemas de billing, mecanismos de autentificación, entre otros.
La principal desventaja de este esquema supone el costo asociado a la mejora en
los nodos de ambas redes puesto que se requiere compatibilidad entre los diferentes
protocolos de red. Adicionalmente, dado que el tráfico WLAN viaja a través de la
red UMTS, podrı́a eventualmente existir una sobre carga en la red 3G, provocando
situaciones de cuellos de botella.
Server
Nube IP
GGSN
Tight coupling Loose coupling
SGSN
Red acceso
3GPP
Figura C.1: Esquemas de interconexión 3G-WLAN.
100
Anexo D
Material Digital
El material digital se encuentra organizado en 4 carpetas, que contienen los archi-

vos desarrollados para este trabajo. A continuación se describen los archivos por cada
carpeta.
D.1. Escenarios
Los tres escenarios desarrollados para este trabajo son listados abajo. Cada uno de
ellos tiene asociado 3 archivos de diferentes extensiones: *.nt.m, *.pb.m y *.seq.
Memoria4-MobileIP in 3G WLAN interworking.
Memoria4-MobileIP in WLAN WLAN using OPNET.
Memoria4-Proxy Mobile IP in 3G WLAN interworking.
Para ejecutar los escenarios se debe crear un proyecto en OPNET de nombre ”Memo-
ria4”. Dentro de éste, crear 3 escenarios con los nombres de los archivos antes nom-
brados, por ejemplo ”Mobile IP in 3G WLAN interworking”. Finalmente ubicar los
archivos que contiene la carpeta Escenarios en el directorio del proyecto.
D.2. Modelo de Nodos

Los modelos de nodos creados son listados abajo. Éstos deben ser copiados en el
directorio del proyecto para que la simulación pueda reconocerlos.
101
ANEXO D. MATERIAL DIGITAL
ksl mobile.nd.m
ksl wlan eth slip4 ha adv.nd.m
ksl wlan2 wkstn adv.nd.m
D.3. Modelo de Procesos

Los modelos de procesos son listados abajo. Análogo al caso anterior, deben ser
copiados en el directorio del proyecto antes de iniciar la simulación.
ksl pro ip arp v4.pr.m
ksl pro mobile.pr.m
ksl pro switch home.pr.m
ksl pro switch nodo.pr.m
D.4. Archivos Externos

Los siguientes archivos deben ser copiados en el directorio en el cual se ha instalado
OPNET de acuerdo al directorio descrito.
Archivo ip rte support.ex dentro del directorio: \OP N ET \14.5.A\models\std\ip
Archivo tcp conn v3.pr dentro del directorio: \OP N ET \14.5.A\models\std\tcp
102

Implementación de Mobile IP entre redes móviles y WLAN

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Implementación de Mobile IP entre redes móviles y WLAN

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE CHILE

FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS

IMPLEMENTACIÓN DE MOBILE IP ENTRE REDES

MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL ELECTRICISTA

KAREN ANDREA SALVATIERRA LEÓN

IMPLEMENTACIÓN DE MOBILE IP ENTRE REDES

MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL ELECTRICISTA

KAREN ANDREA SALVATIERRA LEÓN

IMPLEMENTACIÓN DE MOBILE IP ENTRE REDES MÓVILES Y

La evolución de las redes de comunicaciones móviles avanza hacia la unificación de

Agradezco a mi familia, en especial a mis padres y hermanas, que con esfuerzo y

2.4.3.2. Aplicaciones en servicios AAA . . . . . . . . . . . . . . 27

3.5.4. Escenario de pruebas modelo de interconexión de redes 3G/UMTS-

Anexo A. Protocolos y tecnologı́as disponibles en OPNET Modeler 94

Anexo B. Redes celulares 3G 96

Anexo C. Esquemas de interconexión entre redes de accesos 3G/UTMS

Anexo D. Material Digital 101

2.1. Comparación protocolo MIP y PMIP. . . . . . . . . . . . . . . . . . . . 18

3.1. Librerı́a disponible para modelos wireless en OPNET Modeler. . . . . . 37

4.1. Delay registro MIP en red local usando OPNET. . . . . . . . . . . . . . 66

4.7. Roaming de red en ambiente WLAN. . . . . . . . . . . . . . . . . . . . 68

2.1. Tráfico móvil global por contenido. . . . . . . . . . . . . . . . . . . . . 6

3.1. Pantalla de inicio OPNET Modeler v.14.5. . . . . . . . . . . . . . . . . 37

3.17. Modelo de nodo HA en PMIP. . . . . . . . . . . . . . . . . . . . . . . . 62

4.1. Delays en roaming IP WLAN-WLAN bajo aplicación FTP usando OPNET. 68

C.1. Esquemas de interconexión 3G-WLAN. . . . . . . . . . . . . . . . . . . 100

1.2. Estado del arte

1.3.1. Objetivos generales

Análisis de la performance de protocolos para manejo de movilidad IP frente a

1.3.2. Objetivos especı́ficos

Simulación de interconexión entre redes de acceso móvil y WLAN utilizando pro-

Comparación de movilidad IP con enfoque basado en la red y en el host en base

1.4. Estructura del documento

2.1. Introducción a las redes móviles

2.1.1. Mercado móvil

IP basados en la tecnologı́a de conmutación de paquetes. 3G ofrece una transmisión

2.1.2. Tendencias en el consumo

2010 2011 2012 2013 2014 2015

Figura 2.1: Tráfico móvil global por contenido.

2.1.3. Desafı́os para la Movilidad frente a las tendencias del

De acuerdo a [14], las tecnologı́as de redes deberán soportar:

Adopción escalable de tecnologı́as de celdas más pequeñas (por ejemplo usando

Un número masivo de dispositivos “always-on”.

Conexiones ininterrumpidas para una amplia gama de servicios móviles.

2.2. Arquitectura global Internet

Cualquier dispositivo conectado a la red Internet se identifica a través de una direc-

2.2.1.1. Dirección IPv4 e IPv6

2.2.1.2. Movilidad en Sesiones de Internet

La estructura inicial de Internet no consideró la movilidad en su diseño. Más aún,

Aceptar que las sesiones de aplicaciones están atadas a la sesión de transporte

Introducir un mecanismo de sesión ininterrumpida en la capa de aplicación que

La idea es implementar un mecanismo de sesión ininterrumpida en la capa de apli-

Mantener la misma IP durante el movimiento

La técnica implementada es el tunneling cuyo objetivo es simular que el nodo móvil

Introducir una nueva capa que ayude a soportar la movilidad

Rediseñar TCP/IP separando localizadores de los identificadores de host finales

En este caso se requiere de la modificación del stack de protocolos TCP/IP.

2.3. Manejo de movilidad

2.3.1. Movilidad a nivel de Red

Es sabido que la estructura jerarquizada de la direcciones IP hace bien su trabajo

en el host y Movilidad IP basada en la red.

2.3.1.1. Movilidad IP basada en el host

El manejo de movilidad está centralizado principalmente en el terminal móvil el

Un nodo móvil no debe entregar mensajes broadcast ARP mientras se en-

DHCPv6 Dynamic Host Configuration Protocol

Campus con redes basadas en WLAN.