MECANISMO ÚNICO DE SELECCIÓN DE TRAFFIC FLOW TEMPLATES PARA LOS PROTOCOLOS DE MOVILIDAD IP SOPORTANDO MULTIHOMING E IP FLOW MOBILITY SOBRE LAS REDES DE PRÓXIMA GENERACIÓN MÓVIL

Gustavo A. Jiménez Correa

UNIVERSIDAD DE LOS ANDES

FACULTAD DE INGENIERÍADEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN

BOGOTÁ D.C.2011

MECANISMO ÚNICO DE SELECCIÓN DE TRAFFIC FLOW TEMPLATES PARA LOS PROTOCOLOS DE MOVILIDAD IP SOPORTANDO MULTIHOMING E IP FLOW MOBILITY SOBRE LAS REDES DE PRÓXIMA GENERACIÓN MÓVIL

Gustavo A. Jiménez Correa

Tesis de Grado presentada como requisito para optar al título de Magister en Ingeniería de Sistemas y Computación

AsesorPh.D. Yezid E. Donoso Meisel

UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA

DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓNBOGOTÁ D.C.

2011

TABLA DE CONTENIDO

RESUMEN1. INTRODUCCIÓN

1.1 OBJETIVO GENERAL1.2 OBJETIVOS ESPECÍFICOS1.3 CONTRIBUCIONES

2. MARCO TEÓRICO2.1 EVOLVED PACKET SYSTEM (EPS)

2.1.1 Origen2.1.2 Arquitectura

2.1.2.1 Long Term Evolution2.1.2.2 Evolved Packet Core (EPC)

2.1.3 Entidades, Protocolos e Interfaces2.1.3.1 Entidades Principales

2.1.3.2 Interfaces2.2 PACKET DATA NETWORK

2.2.1 Multihoming2.3 PROTOCOLOS DE MOVILIDAD IP

2.3.1 MIPv4, MIPv6 y Dual Stack Mobile IPv6 (DSMIPv6)2.3.1.1 Bootstraping2.3.1.2 Extensiones a IPv6

2.3.2 Proxy Mobile IPv6 (PMIPV6)2.4 IP FLOW MOBILITY (IFOM)

2.4.1 Requerimientos y Escenarios Planteados por la 3GPP para IP Flow2.4.2 Mejoras en los Protocolos de Movilidad para Soportar IP Flow Mobility.

2.4.2.1 Mejoras En DSMIPv62.4.2.2 Mejoras En DSPMIPv6

3. ESTADO DEL ARTE4. ANÁLISIS DE PROTOCOLOS DE MOVILIDAD IP

4.1 ANÁLISIS CUALITATIVO4.2 ANÁLISIS CUANTITATIVO

5. PROPUESTA5.1 ESTRUCTURA DEL TRAFFIC FLOW TEMPLATE REFERENCE MOBILITY OPTION5.2 PROCEDIMIENTOS

5.2.1 Establecimiento de un TFT Reference ID5.2.2 Actualización y Eliminación del TFT Reference ID

6. RESULTADOS7. CONCLUSIONES Y TRABAJOS FUTUROS

7.1 CONCLUSIONES7.2 TRABAJOS FUTUROS

8. BIBLIOGRAFÍA

LISTA DE FIGURAS

Figura 1. Evolución de las Redes Celulares.Figura 2. Modelo o Arquitectura planteada para el EPS.Figura 3. Vista Simplificada de Sistema Celuares.Figura 4. Arquitectura de Dominios de la 3GPP.Figura 5. Diferencia Red de Acceso Red Celular Generacion 3G y LTE.Figura 6. Evolución de la arquitectura de la red hacia la conmutación por paquetes. Figura 7. Arquitectura General de EPS. Figura 8. a) Principales Protocolos e Interfaces en EPS. b) Arquitectura Simplificada EPS.Figura 9. a) UE Realizando Múltiples Conexiones PDN’s b) UE Soportando Multi Access Data Network Conectivity y IP Flow Mobilty.Figura 10. Descripción de como un Nodo se vuelve Inancalzable con su Dirección IP Original cuando ste se mueve a otra Subred. Figura 11. a) Procedimiento de bootstraping y registración de un UE b) enrutamiento de paquetes en MIPVx. c) movimiento del UE a una subred, mecanismo de registración y deregistración de nuevo CoA d) movimiento del UE hacia la Home Network.Figura 12. Escenarios DSMIPV6. Figura 13. a) Protocol stacks para el plano de control y usuarios cuando se usa S2x sobre trusted non-3GPP access. b) Untrusted non-3GPP access. Figura 14. a) Mobility Header (MIH) b) mensaje Binding Update c) MIH Header para el Binding Update.Figura 15. Arquitectura de Proxy Mobile IP.Figura 16. a) UE conectándose mediante PMIP b) Proceso de Handover en PMIP.Figura 17. Escenarios Dual Stack Proxy Mobile IP.Figura 18. a) y c) Protocol Stacks paa el plano de control y usuarios cuando se usa S2a sobre trusted non-3GPP access. b)y d) S2b sobre un-trusted non-3GPP access.Figura 19. Casos de Usos de IP Flow y Conectividad Multi-Acceso.Figura 20. Escenario para el Estudio del IP Flow Mobility.Figura 21. Comparación de Conectividad para DSMIPv6 y DSPMIPv6 utilizando de número de secuencia de los paquete entrantes. Evaluando Casos Multihoming (2 interfaces) y IFOM vs Modelo Original (una interfaz).Figura 23. Impacto de IFOM en la Perdida de Paquetes para DSMIPv6 y DSPMIPv6.Figura 24. Impacto de IFOM en el Consumo del Ancho de Banda para DSMIPv6 y DSPMIPv6.Figura 25. a) IPv4 b)IPv6 Binary Traffic Selector c)Tratamiento de Flow Binding, d) Relación bid y CoA’s. Figura 26. Traffic Flow Template Reference Mobility Option.Figura 27. Procedimiento de Implementación del TFRID en el EPS. Figura 28. Comparación de Conectividad para DSMIPv6 y DSPMIPv6 utilizando de Número de Secuencia de los Paquetes Entrantes. Evaluando Uso de TFTRID.Figura 29. Impacto de IFOM y el TFTRID en la Latencia Generada a) por el Handover y b) el Movimiento de Flujo de un Acceso a otro.Figura 30. Comparación Ancho de Banda Normalizado.Figura 31. Comparación Tasa de Perdida de Paquetes Normalizado.Figura 32. Comparación Costo Total de Señalización Normalizado.

LISTA DE TABLAS

Tabla 1. Requerimientos Básicos para Soporte de IP Flow.Tabla 2. Binding Cache en HA soportando la registración de múltiple CoAs.Tabla 3. Binding Cache en HA soportando FID.Tabla 4. Análisis Cualitativo de Dual Stack Mobile IP v6 y Dual Stack Proxy Mobile IP v6.Tabla 5. Promedio de Retraso de Paquetes entre el MN y el CN.Tabla 6. Resumen de Troughput Promedio para Trafico TCP y UDP sobre Una y Dos Interfaces.Tabla 7. Propuesta de Binding Cache en HA soportando TFRID.Tabla 8. Descripción de Parámetros del TFT Reference Mobilty Option.

GLOSARIO

3GPP Third Generation Partnership Project3GPP2 Third Generation Partnership ProjectAAA Authentication, Authorization and AccountingANDSF Access Network Discovery and Selection FunctionBA Binding AcknowledgementBBERF Bearer Binding and Event Reporting FunctionBU Binding UpdateCDMA Code Division Multiple AccessCN Core Network; Correspondent NodeCoA Care-of AddressCS Circuit-SwitchedDHCP Dynamic Host Configuration ProtocolDL DownLinkDNS Domain Name SystemDSL Digital Subscriber LineDSMIPv6 Dual Stack Mobile IPv6DSPMIv6 Dual Stack Proxy Pobile Ipv6EAP Extensible Authentication ProtocolEDGE Enhanced Data rates for GSM EvolutioneHRPD Evolved High Rate Packet DataEMM EPS Mobility ManagementeNB E-UTRAN NodeBEPC Evolved Packet CoreePDG Evolved Packet Data GatewayEPS Evolved Packet SystemE-UTRAN Evolved Universal Terrestrial Radio Access NetworkFA Foreign AgentFDD Frequency Division DuplexGERAN GSM EDGE Radio Access NetworkGGSN Gateway GPRS Support NodeGPRS General Packet Radio ServiceGSM Global System for Mobile communicationsGW GatewayHA Home AgentHLR Home Location RegisterHO HandoverHoA Home AddressH-PCRF Home PCRFHRPD High Rate Packet DataHSDPA High Speed Downlink Packet AccessHSPA High Speed Packet AccessHSS Home Subscriber ServerIFOM IP Flow MobilityIKEv1 Internet Key Exchange version 1IKEv2 Internet Key Exchange version 2IMT-Advanced International Mobile Telecommunications-AdvancedIP-CAN IP Connectivity Access NetworkIPSec IP SecurityI-WLAN Interworking Wireless LANLAN Local Area NetworkLBO Local BreakoutLMA Local Mobile AnchorLTE Long-Term EvolutionMAG Mobile Access GatewayMH Mobility HeaderMIP Mobile IPMIPv4 Mobile IPv4MIPv6 Mobile IPv6MME Mobility Management EntityMN Mobile NodeMS Mobile StationMSC Mobile Switching Center

NAT Network Address TranslationOCF Online Charging FunctionOCS Online Charging SystemOFDM Orthogonal Frequency Division MultiplexingOFCS Offline Charging SystemOMA Open Mobile AlliancePBA Proxy Binding AcknowledgementPBU Proxy Binding UpdatePCC Policy and Charging ControlPCEF Policy and Charging Enforcement FunctionPCO Protocol Configuration OptionsPCRF Policy and Charging Rules FunctionPDN Packet Data NetworkPDN GW Packet Data Network GatewayPDP Packet Data ProtocolPLMN Public Land Mobile NetworkPMIP Proxy Mobile IPPS Packet-SwitchedQoS Quality of ServiceRAN Radio Access NetworkRAT Radio Access TechnologyRNC Radio Network ControllerRO Route OptimizationSAE System Architecture EvolutionSGSN Serving GPRS Support NodeS-GW Serving GWSLA Service Level AgreementSPR Subscription Profile RepositoryTDD Time Division DuplexTFT Traffic Flow TemplateTISPAN Telecommunications and Internet converged Services and Protocols for Advanced NetworkingTOS Type of ServiceUE User EquipmentUL UpLinkUMTS Universal Mobile Telecommunications SystemUTRAN Universal Terrestrial Radio Access NetworkVPLMN Visited Public Land Mobile NetworkWCDMA Wideband Code Division Multiple AccessWiMAX Worldwide Interoperability for Microwave AccessWLAN Wireless Local Area Networ

RESUMEN

El mercado de las comunicaciones móviles ha crecido rápidamente en los últimos diez años, ocasionando que los niveles de servicios ofrecidos sean cada vez más exigentes y planteando la necesidad de diseñar redes móviles más flexibles que puedan satisfacer las demandas de los diversos usuarios y crear nuevos modelos de mercados. Movilidad sin interrupción, acceso a redes heterogéneas desde un mismo equipo, además de la posibilidad de acceder simultáneamente a múltiples redes, son algunas de las especificaciones que la 3GPP junto con otras organizaciones (IETF, IANA, OMA, 3GPP2, WiMAX Forum etc.) han consolidado desde el Release 8, en lo que se ha denominado como Evolved Packet System (EPS), el cual representa el núcleo para la integración de nuevos y viejos estándares y el conjunto de redes existentes (WiFi, WiMAX, UMTS. WCDMA, LTE, Redes Cableadas, PSTN etc). Este documento realiza una exposición del nuevo esquema propuesto por la 3GPP enfocándose en el estudio del desempeño de los protocolos para la movilidad IP (MIP) en un ambiente que permite la conectividad a distintos acceso simultáneamente y ofrezce servicios basados en la movilidad de flujo IP (IFOM). El trabajo parte de identificar mediante un análisis cualitativo y cuantitativo las características y problemas más relevantes de un entorno como el evaluado y propone una solución que permite mejorar el desempeño de los MIP, al implementar un mecanismo simple y efectivo para la diferenciación de servicios y aplicación de políticas de QoS sobre el EPS. De esta forma, el mecanismo permite a los Mobile Nodes hacer referencia a los Traffic Flow Templates (TFT) definidos sobre la red de acceso y utilizarlos como filtros de enrutamiento dentro de los mensajes de control de Binding Update (BU), por medio de la agregación del Traffic Flow Template Reference Mobility Option (TFTR) junto con el Traffic Flow Template Reference Identification (TFTRID). a los BU’s. Palabras Claves: Redes Heterogéneas, Evolved Packet System, Protocolos de Movilidad IP, Conectividad Multiacceso Simultánea, IP Flow Mobility, Traffic Flow Templates.

1. INTRODUCCIÓN

Desde los inicios de las redes celulares a mediados de los años 70-80 se ha marcado como una tendencia para estas el crecimiento exponencial del número de abonados, lo cual a su vez ha obligado a que dichas redes estén en una continua evolución (ver Figura 1) desde las antiguas tecnologías análogas como AMPS (Advance Mobile Phone System) en Estados Unidos o NTM (Nordic Mobile Telephone) en el Norte de Europa, pasando por las redes 2G como CDMA y GSM con sus respectivas mejoras como GPRS y EDGE donde ya hablamos de una red conmutada de paquetes y mejoras en las tasas de transferencias. Finalizando con las redes 3G como UMTS y WCDMA las cuales no solo mejoraron el uso del espectro y las velocidades de transferencias sino que además lograron ofrecer una amplia gama de servicios que mejoraron la experiencia del usuario final. Figura 1. Evolución de las Redes Celulares.

Tomado de [37]. Asimismo, con la evolución y crecimiento de las redes celulares también han aumentado y cambiado las expectativas de los abonados en relación a la tecnología celular, siendo estos cada vez más exigentes en cuanto a la confiabilidad, desempeño y disponibilidad de los servicios además de la cantidad y calidad de aplicaciones a las que pueden acceder. Los usuarios de hoy día hablan de requerimientos como [12]:

● Altas tasas de transferencias de datos, baja latencia, altos niveles de seguridad y QoS (Quality of service).

● Soporte y acceso a distintas redes desde un mismo equipo (existentes y futuras), asegurando movilidad y continuidad de servicios entre los distintos sistemas de acceso.

● Soporte a la selección del sistema de acceso (WiFi, WiMAX, UMTS etc.) basados en las preferencias del usuarios y condiciones de las redes de acceso o las políticas definidas por el operador.

● Equipos con mejores características que permitan acceder a diferentes redes o sistemas de acceso (UMTS, GSM, WiMAX,WiFi, DSL’s).

Lo antes descrito redunda en el desarrollo de nuevas aplicaciones basadas o enfocadas hacia el consumo de servicios remotos ubicados en la nube (Grid Computing, Cloud Computing, Mashups) [38]. Por otra parte, el crecimiento y adopción de los equipos móviles como herramientas para consumo e intercambio de información (Iphones's, Blackberry, Droids, Tablets etc.), conllevan a que el tráfico de las redes móviles se vea afectado deteriorando el desempeño de la misma debido a los aumentos en el consumo de vídeo, audio y datos por parte de los usuarios, aplicaciones y servicios hasta tal punto, que la plataformas celulares actuales (2G y 3G) puedan llegar a saturarse ante las nuevas exigencias del medio [39]. La 3GPP, desde el Release 8 en asocio con otras organizaciones (OMA, WiMAX Forum, 3GPP2, IETF, IANA) han planteado bajo el estudio del SAE (System Architecture Evolution) lo que será la nueva arquitectura de las redes de próxima generación móvil (NGMN). EPS (Evolution Packet System) es el nombre que se le ha dado a esta arquitectura la 3GPP [1]. Entre sus principales características ofrece una estandarización de los protocolos y comunicación orientada a paquetes desde los sistemas de acceso, pasando por el Core Network, hasta la capa de aplicación y servicios, tal como se presenta en la siguiente figura. Figura 2. Modelo o Arquitectura planteada para el EPS.

Tomado de [40]. EPS (Evolved Packet System) representa la nueva evolución de la red celular en torno a estándares y arquitectura; no sólo evoluciona aspectos como eficiencia espectral, tasas de transferencias o la unificación de los dominios de procesamiento y conmutación de voz y datos [41], sino que permite acoplar distintas tecnologías de acceso: 3GPP (e.g. LTE, GSM, UMTS), Trusted non-3GPP (WCDMA, HRPD), non-Trusted non-3GPP (WiFi y WiMAX) y cableadas (ATM, PSTN, Ethernet, DSL’s) [40] en una única y nueva plataforma, haciendo posible que puedan comunicarse e intercambiar información y movilidad sin interrupciń soportando todo esto bajo el protocolo IP, razón por lo cual es considerada una ALL- IP Network [42].

Esta arquitectura está conformada por dos nuevas plataformas (ver Figura 2): LTE (Long Term Evolution) diseñada para la evolución de la interfaz de radio siendo una capa de acceso para el control de las tecnologías de banda ancha en las redes de

acceso [43]. Por otro lado, EPC (Evolved Packet Core) enfocada en la evolución de arquitectura central, ofreciendo soporte y gestión para la movilidad IP de servicios, aplicaciones, y usuarios sin interrupción entre las diferentes redes de acceso [3], facilitando el control y definición de políticas basadas en QoS y Charging [4], [5], ofrece además alta disponibilidad, confiabilidad, escalabilidad y un mejor el desempeño de la red, así como un uso eficiente del ancho de banda y reducción de costos tanto para los usuarios como los operadores [44]. Lo anterior y muchas otras características son logradas dado que los dispositivos móviles poseen en la actualidad múltiples interfaces con las cuales pueden comunicarse, sin embargo, las especificaciones presentadas desde el Release 8 aún no dan soporte total al hecho de que un abonado puede comunicarse usando múltiples redes de acceso simultáneamente [6], [7], es decir, según las especificaciones un Mobile Node puede establecer una o múltiples conexiones simultáneas a distintas PDN’s (Packet Data Network), pero todo el tráfico generado e intercambiado entre estas y el dispositivo móvil es enrutado a través de una misma red o sistema de acceso, lo cual no representa las caracteristicas ofrecidas por IP Flow Mobility (IFOM) [6]. La importancia de lo anterior nace de dos eventos mencionados previamente, el incremento de la demanda de datos (búsquedas por Internet, videos, VoIP, TvIP etc.) junto con los distintos tipos de aplicaciones que corren sobre un dispositivo móvil, y el incremento de redes inalámbricas disponibles (WiFi) y equipos móviles que soportan el acceso a estos tipos de redes. Como resultado, un abonado cuando se encuentra bajo la cobertura de una red WiFi, podría descargar o redirigir parte del tráfico (i.e. best effort, ftp, videos) por este medio, manteniendo al mismo tiempo el tráfico (e.g. flujo de VoIP) en el acceso celular (3G/2G) [6], [45]. Por medio de esta fragmentación del flujo normal IP, el operador podría reducir los costos de acceso e incrementar la capacidad de la red, además de minimizar los costos de conectividad a los abonados y permitir un mayor consumo de ancho de banda (para algunas aplicaciones) sin ningún tipo de interrupción del servicio, al usar las redes inalámbricas (WiFi, WiMAX) como una extensión de la red celular. Los estudios realizados hasta el momento se han basado en analizar y estudiar los distintos protocolos de movilidad IP (MIP) y esquemas para permitir handover verticales con mínimos requerimientos de latencia, perdida de paquetes etc. El objetivo de este trabajo es estudiar los protocolos de movilidad IP definidos por la 3GPP junto con la IETF (DSMIPv6 y DPMIPv6) sobre escenarios que permitan evaluar el Multihoming (Equipos con múltiples interfaces) y la movilidad de flujo IP (enrutamiento del flujo IP dependiendo de los sistemas de acceso disponibles) y presentar una solución que mejore el desempeño de los protocolos de Movilidad IP ante los problemas de perdidas de paquetes, el costo de señalización y alto consumo de ancho de banda. Los resultados serán analizados utilizando valores normalizados de lás métricas evaluadas, con el fin de obtener los indicadores de desempeño de la propuesta realizada.

1.1 OBJETIVO GENERAL

Proponer un mecanismo único para la selección de filtros de paquetes o Traffic Flow Templates (TFT) para los protocolos de movilidad IP sobre las redes de próxima generación móvil en entornos que soporten Multihoming, Multi Access Data Newtwork Conectivity e IP Flow Mobility.

1.2 OBJETIVOS ESPECÍFICOS

● Explorar EPS como la arquitectura para la implementación de redes móviles de próxima generación (NGMN).

● Realizar un análisis cuantitativo y cualitativo de los protocolos para movilidad IP DSMIPv6 (Dual Stack Mobile IPv6) y DSPMIPv6 (Dual Stack Proxy Mobile IPv6) sobre entornos heterogéneas (UMTS y WiFi) que soporten Mutihoming. Multi Access Data Network Conectivity e IP Flow Mobility (IFOM).

● Analizar e identificar los requerimientos críticos a mejorar y proponer una solución que mejore el desempeño y rendimiento de los protocolos ante los escenarios establecidos.

1.3 CONTRIBUCIONES

●Un Análisis de la Arquitectura EPS, exponiendo sus principales características, entidades y protocolos.

● Un Cuadro Comparativo de los principales protocolos de movilidad existentes.● Un Análisis Cuantitativo y Comparativo de los protocolos de movilidad IP

implementando Mutihoming. Multi Access Data Network Conectivity e IP Flow Mobility (IFOM)

● Una propuesta para reducir el tamaño y cantidad de mensajes de señalización por cambios en los sistemas de acceso o por políticas de QoS.

● Un mecanismo de selección que permite hacer referencia a los Traffic Flow Templates (TFT) definidos sobre la red de acceso.

2. MARCO TEÓRICO

En las siguientes secciones se describirán los conceptos y generalidades más relevantes sobre los protocolos de movilidad IP y la arquitectura EPS.

2.1 EVOLVED PACKET SYSTEM (EPS)

2.1.1 Origen

Evolved Packet System (EPS) nace principalmente de la necesidad de muchos grupos y organizaciones de definir una arquitectura que permita la convergencia de los servicios de TI y la interoperabilidad entre los distintos protocolos e interfaces propuestos por el gran número de proveedores existentes [1], [8], [46]. Lo anterior, puede ser resumido como la necesidad de definir estándares globales, los cuales beneficiarían tanto los operadores como a los proveedores dado que aseguraría la competencia en el mercado, y evitaría de esta forma la dependencia hacia ciertos productos por problemas de interoperabilidad y reduciría los costos de producción e implementación de redes, plataformas para ambos sectores etc. Establecida la necesidad y marcada la tendencia general de las redes de comunicaciones de proveer arquitecturas basadas en IP como protocolo de comunicación entre las distintas entidades [47], conllevó a que los diferentes grupos y organizaciones encargados de la definición de estándares y arquitecturas como la 3GPP, la 3GPP2, la IETF, el WiMAX Forum y el OMA, trabajaran en conjunto para la definición y especificación de una nueva arquitectura la cual denominaron como SAE (System Architecture Evolution), que luego paso a llamarse Evolved Packet System (EPS) al ser definida tanto la arquitectura como los protocolos a implementar.

2.1.2 Arquitectura

Una vista simplificada de los sistemas celulares actuales como GSM, UMTS se muestra en la Figura 3, en esta se puede observar que estos sistemas se encuentran conformados por tres componentes principales [37]:

● Terminal del Usuario Final: Corresponde a los equipos o dispositivos utilizados por los abonados para acceder, interactuar e intercambiar información con la red.

● Red o Sistema de Acceso: Se encarga de las tareas relacionadas con el radio enlace como proveer transmisiones seguras y confiables sobre la interfaz de radio, la administración de los recursos de radio (Frecuencias, Timeslot etc.), el control de los mecanismos para asegurar la ejecución de los procesos de Handover (medición de señales, procesamiento y los cálculos de asignación de nuevas celdas, cambios de frecuencia etc.).

● Core Network o Núcleo de la Red: Es responsable de la administración de la información de los usuarios (Autenticación, Autorización y Sesión),

implementación de políticas de Qos, tarifas y control para la interoperabilidad con redes externas, entre otras funciones.

Figura 3. Vista Simplificada de los Sistemas Celulares.

Tomada de [37]. EPS desde el diseño mantuvo esta visión (construida basada en la arquitectura de los sistemas GSM/GPRS [9] y WCDMA/HSPA) definiendo a EPC (Evolved Packet Core) y LTE (Long Term Evolution) como piedras angulares de la evolución de las redes móviles en el Core Network y sistemas de acceso respectivamente (Ver Figura 2), encargadas de brindar y soportar todo tipo de servicios, permitiendo como se muestra en la Figura 4, soportar la interoperabilidad entre los distintos sistemas de accesos y dominios existentes (Packet Core Domain, Circuit Core Domain y IMS), y enfocánda en que la comunicación entre sus entidades sea realizada bajo un dominio orientado a paquetes, utilizando IP como protocolo base para todas las comunicaciones, por lo que juntas son reconocidas como una ALL IP Network. Figura 4. Arquitectura de Dominios de la 3GPP.

Tomada de [47].

2.1.2.1 Long Term EvolutionLTE representa la antesala a las redes 4G (son consideradas 3.9G) [43], ésta abarca y define todos los temas relacionados con la interfaz de radio de las redes celulares, vistos en [37]. Como se observa en la Figura 2, LTE define entre sus características velocidades de transferencia de 100Mbps (Downlink) y 50Mbps (Uplink), anchos de bandas de hasta 20MHz, throughput por MHz 3 a 4 veces mejor que a los encontrados con HSDPA (High-Speed Downlink Packet Access) y 2 a 3 veces mejor que Enhanced Uplink, latencias de alrededor 5ms entre el gateway de acceso del E-UTRAN y los UE (User Equipment), anchos de banda escalables entre 1.25-20MHz, conectividad estable a velocidades hasta los 500Km/h y con

alto desempeño a velocidades entre los 15 y 120Km/h, calidad de servicios (QoS) end to end, esquemas de acceso múltiple como OFDM (Orthogonal Frequency Division Multiplexing) para downlink y SC-FDMA (Single Carrier FDMA) para uplink, modulación adaptativa QPSK (Quadrature Phase Shift Keying), 16QAM (Quadrature Amplitude Modulation) y 64QAM, asignación espectral mediante FDD (Frequency Division Duplex) o TDD (Time Division Duplex), entre otras [37], [38], [39], [41]. [42] y [43]. Una característica importante del EPS con respecto a previas generaciones móviles (2G/3G), es que proporciona una conexión end to end ALL-IP, es decir, desde los equipos móviles, con capacidades embebidas para comunicarse mediante IP, a través de los ENodeBs (Evolved NodeBs o estaciones bases LTE), pasando por la EPC hasta la capa de servicio (IMS and non-IMS); toda la comunicación es realizada usando el protocolo IP, lo que permite que tanto la voz como los datos sean transmitidos por un mismo canal y no sea necesario usar canales de circuit-switched (CS) para transportar la voz y canales de packet-switched (PS) para los datos, como en las anteriores generaciones tal como se muestra en la Figura 5. Figura 5. Diferencia Red de Acceso Red Celular Generación 3G y LTE.

Tomado de [47]. Actualmente la 3GPP2 junto con otras organizaciones como la IEEE y el BroadBand Forum trabajan en la definición de LTE Advanced [43], la cual promete mejorar aún más los requerimientos anteriormente mencionados.

2.1.2.2 Evolved Packet Core (EPC)EPC surge por la necesidad de interoperabilidad que deben tener las aplicaciones móviles desplegadas sobre las distintas tecnologías de acceso (LTE, 2G/3G etc). Para esto es definido un sistema basado únicamente en conmutación de paquetes (Ver Figura 6), tanto para voz como datos, que usa IP como el esquema de comunicación general (end to end). Algunas de sus especificaciones son:

● Una arquitectura simplificada con un Single Core Network compatible con múltiples dominios de aplicación, incluyendo IMS y plataformas de Internet.

● Convergencia de información sin problemas de conectividad entre distintas

tecnologías de acceso inalámbrico.● Funciones de control de acceso a la red, administración de ésta y de recursos

de radio.● Movilidad sin interrupción (Handover entre redes heterogéneas) y funciones

para administración esta.● QoS, políticas de control, carga y autenticación a través de múltiples redes

de acceso IP; incluyendo 3GPP, non-3GPP (WiMAX, CDMA2000/HRPD etc.) y untrusted Non-3GPP Access (WLAN).

● Prestación de servicios consistentes y optimizados, independientes del tipo de red de acceso.

Figura 6. Evolución de la Arquitectura de la Red hacia un Núcleo Orientado a la Conmutación por Paquetes.

Tomado de [37].

De lo anterior, se extrae que EPC es una arquitectura de red novedosa que elimina las deficiencias de comunicación IP para el entorno inalámbrico basado en protocolos estándar de la IETF. Por otro lado, al igual que otras arquitecturas el EPC define una variedad de entidades con múltiples componentes funcionales que incluyen entidades de datos de suscripción, entidades de control y los gateways [40]:

● Las entidades de datos de suscripción: El Home Subscriber Server (HSS) y el AAA Server Store, cuyas funciones son actualizar y transmitir las notificaciones sobre el perfil de suscripción de los usuarios y facilitar la información para la autenticación y la autorización de los dispositivos móviles.

● Las entidades de control: Policy and Charging Rules Function (PCRF), the Mobility Management Entity (MME) and the Access Network Discovery and Selection Function (ANDSF) toman decisiones de políticas basadas en la conectividad, el control de acceso y los recursos asignados para dispositivos móviles, este ultimo asiste al UE para selección óptima de una tecnología de acceso en un escenario heterogéneo.

● Las puertas de enlace (gateways): Representan los gateways de acceso

a redes específicas (Serving GW-S-GW), el Evolved Packet Data Gateway (ePDG) y el Generic Access Network Gateway (ANGw) proporcionan interconexión con las diferentes tecnologías de red de acceso. El Packet Data Network Gateway (PDN Gw) lleva a cabo la asignación de IP de los UE (User Equipment), la aplicación de políticas de filtrado de paquetes para cada usuario de acuerdo a las normas establecidas por las entidades de control, la interceptación legal y detección de paquetes, se comunica con los distintos gateways para determinar el destino de la información hacia redes de acceso 3GPP y non-3GPP o hacia la capa de servicios IP (IMS, Internet o otra).

2.1.3 Entidades, Protocolos e Interfaces

La Figura 7 da a conocer la arquitectura lógica desarrollada para el EPS, en esta se expone tanto el diseño, como las interfaces, entidades y conexiones propuestas desde el Release 8 por parte de la 3GPP y demás organizaciones; las cajas de color negro representan las entidades del antiguo core 3GPP (GSM) y son referenciadas debido a que el EPS mantiene la operatividad con los sistemas de legado (2G y 3G). Figura 7. Arquitectura General de EPS.

Tomado de [47].

2.1.3.1 Entidades PrincipalesA continuación se realizará una descripción más detallada de las entidades más relevantes del EPS (Evolved Packet System), sus funciones y como se encuentran interconectadas entre ellas [4], [5], [10], [37] y [47]:

● Evolved NodeB (eNodeB): Proporciona y gestiona las interfaces y recursos de radio para LTE, entre los cuales se tiene: control de radio bearers,

asignación y administración de radio enlaces uplink y downlink para cada UE (User Equipment). Se comunica con el MME (tráfico plano de control) y el Serving Gateway (tráfico plano de usuario) a través de las interfaces S1-MME y S1-U respectivamente.

● Mobility Management Entity (MME): Representa el nodo principal para el control de LTE desde el Core Network, se encarga de seleccionar el Serving GW y el PDN Gw para los UE’s durante los mecanismos de ingreso y handover, coordina la movilidad entre LTE y redes 2G/3G, interactúa con el HSS para coordinar los mecanismos de autenticación del usuario final. Se comunica con el HSS, Serving Gw, eNodeB y el SGSN (para interoperabilidad con redes 2G y 3G).

● Packet Data Network Gateway (PDN Gw): Proporciona conectividad con PDN’s (LAN’s, Redes Corporativas, internet etc.) externas, por lo que es el punto de entrada y salida para el tráfico de datos de los UE’s. Se encarga además de asignar la dirección IP al UE, inspección y filtrado de paquetes. Se comunica con el ePDG, Serving Gw, SGSN (Serving GPRS Support Node), UE, y el PCRF.

● Serving Gateway (S-Gw): Interconecta los UE’s con las Interfaz E-UTRAN (WCDMA, 2G/3G), administra los Handover inter-eNodeB, y proporciona conexión entre las redes 2G/3G y el PDN Gw en los procesos de Handover Inter RAT (Radio Access Technology). Todo UE que se conecta al EPS le es asignado un S-GW. Se comunica con el PDN Gw, SGSN, las entidades del E-UTRAN (Evolved UMTS Terrestrial Radio Access Network), el PCRF y el MME.

● Evolved Packet Data Gateway (ePDG): Debido a que muchas de las redes untrusted non-3GPP (WiFi) no proveen de un mecanismo seguro para la comunicación se construyó el ePDG, este gateway que sólo es de interconexión se encarga de crear de crear un canal seguro (túnel IPSec) entre el UE y el PDN Gw para el paso de mensajes de señalización y datos de usuario. Además usa protocolos EAP-AKA (Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement) para la autenticación de los nodos involucrados.

● Policy and Charging Rules Function (PCRF): El PCRF ofrece una interfaz de señalización en base a Diameter que permite a las plataformas de servicios y a distintas aplicaciones compartir información intercambiando flujos de datos con los dispositivos móviles, la gestión de QoS dinámico y también la adaptación a las condiciones de servicio de conexión inalámbrica basado en la información suministrada por el AF (Application Function) y otras entidades. El PCRF hace parte de una entidad superior denominada PCC (Policy and Charging Control) que se encuentra compuesta por el PCEF (Policy and Chargind Enforcement Function) encargado de la administración del flujo y aseguramiento de QoS sobre éste, de acuerdo a las políticas suministradas por el PCRF. El BBEF (Bearer Binding and Event Reporting Function) que como su nombre lo indica sus principales funciones son las de Bearer Binding y reporte de eventos al PCRF, y el SPR (Subscription Profile Information) el cual contiene toda la información sobre los suscriptores y suscripciones realizadas en el EPS. Esta no es una entidad central sino un conjunto de base de datos distribuidas en la red. Por otra parte, el PCEF se encuentra a su vez conectado a dos entidades el OCS (Online Charging

System) y OFCS (Offline Charging System) encargadas de recolectar toda la información referente al Charging de usuarios por volumen, tiempo, eventos etc. que luego es utilizada para calcular las tarifas de consumo y otras estadísticas.

● Home Subscriber Server (HSS): Base de datos principal del EPS, se encarga de almacenar información de los abonados: Profiles, PDN’s en donde se haya conectado, información para identificación, etc.

● Authentication, Authorization, Acounting Server (AAA): Como su nombre lo indica se encarga de todos los mecanismos relacionados con AAA: generación de claves, comparación de llaves, validación y verificación de que el usuario es quien dice ser, etc.

● Access Network Discovery and Selection Function (ANDSF): Es una entidad encargada de brindar al operador control sobre como el usuario y sus dispositivos priorizan y acceden a las diferentes tecnologías de acceso basados en políticas definidas por la APN (Access Point Network) o tipo de flujo a transmitir, entre otras.

2.1.3.2 Interfaces

A continuación se describirá brevemente el conjunto de interfaces utilizadas en el EPS para intercambios de información, soporte de movilidad y definición de políticas [3], [8]:

● S2a: Transporta señalización, datos y proporciona soporte para movilidad IP entre sistemas de acceso Trusted non-3GPP (WCDMA) y el PDNGw. Implementa PMIPv6 como protocolo de comunicación.

● S2b: Transporta señalización, datos y proporciona soporte para movilidad IP entre el ePDG y el PDNGw. Es utilizada en untrusted non-3GPP (WiFi) accesos. Implementa PMIPv6 como protocolo de comunicación.

● S2c: Transporta señalización, datos y proporciona soporte para movilidad IP entre el UE (User Equipment) y el PDNGw. Implementa DSMIPv6 como protocolo de comunicación puede ser implementado sobre sistemas de acceso Trusted non-3GPP, unTrusted non-3GPP y 3GPP.

● S5: Es usada para comunicación entre el Serving Gw y el PDN Gw en escenarios de non-roaming donde el Serving GW se encuentra localizado en el home network, o en escenarios de roaming donde ambos: el Serving Gw y PDNGw están localizados en la Visitor Network. Implementa PMIPv6.

● S6a: Esta interface es utilizada entre el MME y el HSS para recuperar datos del subscriptor y ejecutar los mecanismos de autenticación y autorización. Implementa Diameter.

● S6b: Comunica a el PDN Gateway con el 3GPP AAA server/proxy y es usada por la PDN para recuperar datos de suscripción y almacenar información sobre usuarios conectados a el PDN.

● Gx: Es utilizada para transferir reglas de QoS desde el PCRF a el Policy and Charging Enforcement Function (PCEF) en el PDN Gw.

● Gxa: Transfiere información de políticas de QoS desde el PCRF a los Trusted non-3GPP accesos.

● Gxb: Utilizada para comunicar el ePDG con el PCRF e intercambiar información de políticas de control.

● Gxc: Transfiere información de políticas de QoS desde el PCRF a el Serving

Gateway.● S8: Ver S5. implementa GTP como protocolo de comunicación.● S9: Transfiere información de políticas de QoS y control entre el Home PCRF

y el Visited PCRF con el fin de soportar la función de local breakout (LBO).● SGi: Interface para comunicar el PDN Gateway y los Packet Data Network

(PDN).● SWa: Conecta los untrusted non-3GPP accesos con el 3GPP AAA Server/

Proxy y transporta información de autenticación, autorización y charging-related de manera segura.

● STa: Conecta los Trusted non-3GPP accesos con el 3GPP AAA Server/Proxy y transporta información de autenticación, autorización, parámetros de movilidad y charging de manera segura.

● SWd: Conecta al 3GPP AAA Proxy, posiblemente entre redes intermedias a el 3GPP AAA Server.

● SWm: Localizada entre el 3GPP AAA Server/Proxy y ePDG y es usada para señalización AAA.

● SWn: Localizada entre los untrusted non-3GPP accesos y el PDG. y permite la comunicación segura entre el UE y el ePDG.

● SWu: Se encuentra entre el UE y el ePDG y se encarga de administrar los túneles IPSec y el intercambio de información segura entre estas dos entidades.

● SWx: Conecta el 3GPP AAA Server y el HSS y es usada para transportar información de autenticación, suscripción y datos relacionados de las PDN.

La Figura 8a muestra un resumen de los principales protocolos implementados en el EPS y que interfaces utilizan para comunicarse. Mientras que la Figura 8b muestra de manera simplificada la interconexión entres las entidades e interfaces utilizadas. Figura 8. a) Principales Protocolos e Interfaces en EPS b) Arquitectura Simplificada EPS.

Tomados de [47].

2.2 PACKET DATA NETWORK

En el EPS así como en redes 2G/3G, las redes IP son denominadas “Packet Data Network” (PDN) y la conexión hacia una PDN es llamada “PDN connection” [3]. Una terminal o equipo puede realizar conexiones a una PDN o múltiples PDN’s

simultáneamente, como se muestra en la Figura 9a, por ejemplo puede acceder a internet y a servicios IMS simultáneamente, en los casos que estos servicios se encuentran desplegados sobre distintas PDN’s, por lo que el equipo deberá adquirir múltiples direcciones IP (IPV4 o IPV6 o ambas), una por cada conexión PDN. Figura 9. a) UE Realizando Múltiples Conexiones PDN’s b) UE Soportando Multi Access Data NetworkConectivity y IP Flow Mobilty.

Tomados de [47] y [4]. Proporcionar una PDN Connection no es solo tomar una dirección IP, es también transportar los paquetes IP entre el UE (User Equipment) y la PDN garantizando QoS (Quality of Service) sobre los servicios que están siendo usados. El EPS para asegurar que todos los requerimientos de servicio sean soportados (retraso, jitter, tasa de transferencia) implementa el uso de Bearer (para accesos 2G y 3G 3GPP) o contextos PDP (accesos LTE), el cual representa un canal de transporte lógico entre el UE y el PDN para transportar el tráfico IP. A cada EPS Bearer le es asignado un conjunto de políticas de QoS que describen las propiedades del canal, por lo que todo el tráfico cursado por este recibirá el mismo tratamiento. En resumen, la función principal de los EPS Bearer es proporcionar un tratamiento diferenciado para el tráfico cursado en el plano de usuario mediante la diferenciación de sus requerimientos de QoS. Los EPS Bearers son administrados por el PDN Gw el cual se encarga de activar, modificar y eliminar un EPS Bearer y decidir que paquetes son transportados por cada uno de estos. Para lograr esta diferenciación de paquetes a un EPS Bearer le es asociado un TFT (Traffic Flow template), el cual contiene información que le permite al UE y el PDN Gw identificar y transmitir los paquetes por los respectivos Bearers, el TFT está compuesto generalmente por la dirección origen y destino, el puerto origen y destino y el identificador del protocolo (UDP y TCP).

2.2.1 Multihoming

El Multihoming representa la capacidad de un sitio o equipo de conectarse a diferentes o una misma PDN utilizando distintos sistemas de acceso simultáneamente (ver Figura 9b). Por tal, el equipo debe tener múltiples interfaces, lo cual implica que cada interfaz tendrá su propia dirección IP, gateway, políticas de despliegue (DNS, ToS), métricas (i.e. Flujo Máximo, short spanning tree, etc). El IETF en [14], [25], [26] [27] y [28] resumió los modos de operación, características más relevantes, ventajas y desventajas de usar multihoming.

2.3 PROTOCOLOS DE MOVILIDAD IP

Al hablar de movilidad se hace referencia a la “habilidad para un usuario, o dispositivo móvil, para comunicarse y acceder a servicios independientemente de los cambios de localización (moviéndose a una velocidad, caminando o en automóvil) o medio técnico de acceso” [46]. A lo anterior también se debe añadir ofrecer continuidad de sesiones o aplicaciones sin interrupción incluso cuando los cambios son realizados entre redes de acceso (Handover Vertical). La Figura 10 expone los actuales inconvenientes presentados con el enrutamiento de paquetes cuando un equipo se mueve entre subredes sin cambiar su dirección IP original [11]. Un cambio de subred puede ocurrir cuando un UE al moverse se conecta a otra red usando la misma interfaz (e.g. entre WLAN’s) u otra tecnología de acceso (entre redes 3GPP y WLAN). Como se observa claramente el problema está asociado a las perdidas de paquetes debido a que los protocolos actualmente usados no soportan movilidad IP. Figura 10. Descripción de como un Nodo se vuelve Inalcalzable con su Dirección IP Original cuando este se mueve a otra Subred.

Tomado de [47].

La 3GPP ha definido distintos protocolos para soportar movilidad IP en el EPS Evolved Packet System) ante los distintos escenarios que se pueden encontrar en un ecosistema amplio como lo son las redes móviles. Dichos protocolos pueden clasificarse para un mejor estudio en protocolos Host-Based y Network-Based [15], [16]. Los protocolos de movilidad Host-Based o Client-Based se caracterizan por ser los UE (User Equipment) los encargados de realizar las operaciones relacionadas con la movilidad: detección de movimiento, señalización etc. Mobile IPv4 (MIPv4), MIPv6 y Dual Stack Mobile IPv6 (DSMIPv6) son ejemplos de protocolos de movilidad descritos por la IETF que soportan este tipo de movilidad [47]. En cambio, para los protocolos Network-Based, es la red la encargada de proporcionar los servicios de movilidad al UE. Proxy Mobile IPv6 (PMIPv6) y GPRS Tunnelling protocol (GTP) son ejemplos de protocolos que soportan este tipo de movilidad. En este documento sólo se trabajará con los protocolos que permiten la movilidad entre redes heterogéneas definidos por la IETF (Ver capitulo 5) específicamente entre redes 3GPP y non-3GPP (Trusted y Untrusted), es decir DSMIPv6 y DSPMIPv6 [15], [16].

2.3.1 MIPv4, MIPv6 y Dual Stack Mobile IPv6 (DSMIPv6)

Los modos de operación de estos tres protocolos son muy parecidos, dado que fueron basados en el desarrollo realizado por IETF. Como su nombre lo indica MIPv4 fue desarrollado para soportar movilidad en las redes que aún utilizan éste tipo de direcciones, MIPv6 [15] en cambio fue creado para soportar la aparición de estas redes y como se mencionó fue creado basado en MIPv4. No obstante, muchas diferencias existen entre estos protocolos, Dual Stack [17] fue creado con el fin de soportar la movilidad y el envió de paquetes entre redes IPv4 y IPv6. Mobile IP en general, permitirá a un usuario ser identificado por una misma IP incluso cuando éste se mueve entre distintas redes de acceso o subredes (ver Figura 10). Esta IP es denominada Home Address (HoA), la cual es asignada en la Home Network del UE (User Equipment), por lo tanto, cuando un UE esta posicionado sobre su Home Network este puede usar su HoA para acceder y ser localizado en la red, sin embargo, cuando éste se encuentra sobre una red diferente (Foreign Network) donde el HoA no es alcanzable, otra dirección IP es asignada al UE, denominada Care of Address (CoA) y es asignada por la Foreign Network. Para lograr una asociación entre el HoA, el CoA y los paquetes enviados a cada una de estas, una entidad llamada Home Agent (HA) se ha definido, éste es un router ubicado sobre la Home Network (en EPS el PDN GW asume esta función) que se encarga de realizar un binding entre el HoA y el CoA, interceptando los paquetes enviados al UE en la Home Network, encapsulándolos dependiendo del tipo de red destino (IPv6 o IPv4) y enviándolos a través de un túnel hacia el UE ubicado sobre la Foreign Network (ver Figura 11b), el cual se encargaría de desencapsularlos; cabe anotar, que el túnel creado entre el HoA y el CoA es bidireccional dado que sobre este se envían y reciben paquetes [15]. Otros mecanismos de comunicación entre el HoA y el CoA son soportados por MIPv4 y MIPv6 como el Triangular Routing y el Rounting Optimization [47], no obstante, no se describirán dado que no son soportados por el EPS. Otra entidad definida por [15] es el Correspondent Node (CN), el cual representa un equipo o nodo con el cual el UE se comunica e intercambia información (Video, FTP, Voz etc.).

2.3.1.1 BootstrapingAl encender un UE (User Equipment) este realiza un procedimiento denominado “Bootstraping” para determinar si el equipo se encuentra ubicado sobre la Home Network o Foreign Network, los pasos se describen a continuación:

● Localizar el HA (Home Agent) más cercano. Éste puede ser localizado mediante parámetros previamente establecidos en el UE o por medio DNS SEARCH. Al encontrar un HA, se procederá a asignar una dirección IP al UE, si no posee una por default.

● Establecer mediante IPSec y IKEv2 (autenticación y autorización) los medios seguros para intercambio de señalización de mobile IP entre el HA y el UE, para lo cual se crea un túnel IPSec [18].

● Entrega del HoA (Home Address) por parte del HA al UE.● Proceso de verificación del UE mediante mecanismo de Home Link Detection.

Este comprueba si el HoA asignado pertenece o no a la actual red.

● En caso de no pertenecer, el UE informa al HA sobre su actual CoA (Care of Address) enviando un mensaje de Binding Update (BU) que contiene el HoA y CoA mediante el túnel creado anteriormente.

● El HA registra en el Binding Cache (BC) la nueva información y notifica mediante un Binding Acknolegment (BA) al UE, la Figura 11a describe este procedimiento.

Por otro lado, La Figura 11c describe el escenario en que el UE se mueve entre Foreign Networks. En estos casos los mensajes intercambiados entre el UE y el HA son los mismos que los descritos anteriormente. Por último, la Figura 11d evidencia el evento en el cual el UE regresa a la Home Network, el UE por lo tanto, envía el BU para informar al HA el evento, luego este actualiza el BC y responde con un BA al UE. Finaliza dejando de interceptar los paquetes enviados a la Home Network y remueve el túnel creado (en caso de existir) para la comunicación entre el HA y el UE [15]. Figura 11. a) Procedimiento de Bootstraping y Registración de un UE b) Enrutamiento de Paquetes en MIPVx. c) Movimiento del UE a una Subred, Mecanismo de Registración y Deregistración de nuevo CoA d) Movimiento del UE hacia la Home Network.

Tomados de [47].

El modo de operación Dual Stack [17] es una mejora al MIPv6, la cual permite a un UE moverse entre redes IPv4 y IPv6 sin mayores inconvenientes. Por lo que el modo de operación, las entidades involucradas y mensajes intercambiados concuerdan con los anteriormente descritos a excepción de que ahora el HA deberá realizar un chequeo previo del tipo de red destino (IPv4 o IPV6) y encapsular los paquetes dependiendo de esta información. Por otra lado, este protocolo también soporta encapsulamiento sobre UDP cuando direcciones privadas y NAT transversales están presentes en la red. A continuación en la Figura 12 se identifican los distintos escenarios en los cuales este protocolo puede ser implementado [19], [20].

Figura 12. Escenarios para la Implementación de DSMIPV6.

Tomado de [47].

Este protocolo fue definido por la IETF como el protocolo predilecto para movilidad entre redes 3GPP (2G/3G) y untrusted non 3GPP (WLAN) y utiliza la interfaz S2c para comunicación con el PDNGw como se muestra en la Figura 13 a, b [12]. Figura 13. a) Protocol stacks para el Plano de Control y Usuarios cuando se usa S2c sobre Trusted non-3GPP Access. b) Untrusted non-3GPP access.

Tomado de [47].

2.3.1.2 Extensiones a IPv6Para soportar los mensajes de MIPv6 descritos previamente, fueron necesarias algunas modificaciones al protocolo IPv6, entre ellas un nuevo Extension Header fue agregado, denominado Mobility Header (MIH), todos los mensajes incluyendo el BU (Binding Update) y BA (Binding Acknowledgement) son de este tipo. La Figura 14a describe el header, los campos Next Header y Header Length no están especificados para el MIH, el campo MH Type indica el tipo mensaje (BA, BU etc), el checksum como su nombre lo indica contiene un cheksum de MIH, y el último campo contiene información específica de cada mensaje como se observa en la Figura 14b. La Figura 14c muestra el contenido de un mensaje BU, siendo el campo Mobility Option el lugar de almacenamiento de mensajes como el FID (Flow ID Mobility Option), BID (Binding ID) que se explicará más adelante (ver sección 5.2).

Figura 14. a) Mobility Header(MIH) b) mensaje Binding Update c) MIH Header para el Binding Update.

Tomado de [32].

2.3.2 Proxy Mobile IPv6 (PMIPV6)

PMIPV6 reutiliza mucho los conceptos y formatos de paquetes definidos para MIPv6 [16], este protocolo a diferencia de los anteriores encarga a la red de administrar los mensajes referentes de movilidad y continuidad de sesiones IP sobre el UE (User Equipment), por lo que éste no requerirá de algún software adicional para tal fin, como en los Host-Based protocolos; para tal fin, un agente de movilidad en la red se encargará de seguir los movimientos del UE e intercambiará los mensajes de señalización con las correspondientes entidades en nombre del UE, es decir, el agente actuará como un proxy entre el UE y las demás entidades para la señalización relacionada con movilidad IP, de ahí que el nombre sea Proxy Mobile IP. Dos nuevas entidades son agregadas a la red por este protocolo: el Mobile Access Gateway (MAG) y el Local Mobility Anchor (LMA). Las funciones del MAG (ubicado en la red de acceso) son las de actuar como cliente Mobile IP en nombre del UE, en cambio el LMA (ubicado en la red donde el HoA- Home Address este localizado) adquirirá las funcionalidades del HA (Home Agent) en MIPV6 (ver Figura 15). Figura 15. Arquitectura de Proxy Mobile IP.

Tomado de [47].

Además de detectar los movimientos del UE y ser el encargado de iniciar los

mensajes de señalización, el MAG debe realizar la tarea de emular una Home Network, con el fin que el UE no detecte cambio alguno sobre la capa 3 incluso cuando éste haya cambiado de subred [29]. Los procedimientos de localización, registración, deregistración y handover son mostrados en la Figura 16 a y b. En estos el MAG (Mobile Access Gateway) al recibir la notificación de que un UE ha iniciado una conexión, localiza un LMA (Local Mobility Anchor) mediante DNS u otro mecanismo. Al ser este seleccionado el MAG envía un Proxy Binding Update (PBU) al LMA; este contiene el Proxy CoA (Care of Address) el cual corresponde a la IP del MAG, con esta información el LMA crea un Binding entre el Proxy CoA y el HoA (Home Address) del UE. Este proceso es similar al realizado por el HA con el HoA y el CoA en el Binding Cache para los MIP, la diferencia es que el UE no es consciente de estos mensajes. Luego, el LMA envía un Proxy Binding Acknolegment (PBA) el cual permite al MAG proporcionar una dirección IP (HoA) al UE. Ya intercambiados estos mensajes, se crea un túnel bidireccional entre el LMA y el MAG para interceptar, encapsular y desencapsular los mensajes desde y hacia el UE. De este modo el UE siempre cree estar en la misma Home Network dado que siempre le es asignada la misma HoA y otros parámetros IP por medio de las distintas MAG’s. En los casos que el UE se mueva hacia otra subred u otra tecnología de acceso, el nuevo MAG detecta el movimiento e informa al LMA correspondiente mediante un PBU el nuevo Proxy CoA, el LMA actualiza en Binding y envía un PBA que le permita al nuevo MAG asignar la misma dirección al UE [16]. Figura 16. a) UE Conectándose mediante PMIPv6 b) Proceso de Handover en PMIPv6.

Tomados de [47].

Distintos mecanismos de seguridad son implementandos para el Proxy Mobile IPv6 (PMIPv6), los primeros son definidos entre el UE y los MAG (Mobility Access Gateway), sin embargo, entre las entidades de la red el LMA y el MAG se ha definido usar IPSec y Network Domain Security (NDS/IP); cabe anotar que los mensajes PBU (Proxy Binding Update) y PBA (Proxy Binding Acknowledgment) son los mismos BU y BA definidos en MIPv6, simplemente se agregó la P para indicar que utilizan un esquema de Proxy.

Figura 17. Escenarios Dual Stack Proxy Mobile IP.

Tomados de [37]. Las mejoras realizadas a PMIPv6 para soportar operación Dual Stack son bastante parecidas a las definidas para DSMIPv6: encapsulamiento IPv6, IPv4 y UDP sobre IPv4, por lo que los escenarios que se mostrarán en la Figura 18, y el funcionamiento detallado son especificados en [21]. A continuación se describen las interfaces y protocolos utilizados en cada uno de los niveles de PMIPV6. Figura 18. a) y c) Stacks Protocol para el Plano de Control y Usuarios cuando se usa S2a sobre Trusted non-3GPP Access. b)y d) S2b sobre Un-trusted non-3GPP Access.

Tomado de [47].

2.4 IP FLOW MOBILITY (IFOM)

El concepto de IP Flow Mobility viene de la mano de dos avances tecnológicos que tenemos hoy día, el primero asociado a la capacidad actual de los equipos de tener múltiples interfaces que pueden a su vez conectarse a distintas PDN’s simultáneamente o una misma, utilizando múltiples interfaces (ver sección 2.2

PDN’s y Multihoming [12], [30]), y el segundo relacionado con el crecimiento exponencial de aplicaciones instaladas sobre equipos móviles. Los anteriores avances muestran que los recursos disponibles no están siendo usados de manera adecuada, a ello se suma el hecho de que algunas aplicaciones se adaptan cómodamente sobre sistemas de acceso 3GPP (e.g. Voz sobre IP) mientras que otras, como FTP mejoran significativamente su desempeño al correr sobre otros sistemas de acceso (e.g. WiFi). IFOM ofrece una mejor distribución de carga y uso óptimo de los recursos de radio disponibles al realizar enrutamiento dinámico de los flujos IP generados por una o múltiples aplicaciones hacia sistemas de acceso (3GPP o non-3GPP) en donde el desempeño de estos no se vea afectado significativamente (ver Figura 9b).

2.4.1 Requerimientos y Escenarios Planteados por la 3GPP para IP Flow

La 3GPP desde el Release 9 en [6] ha definido 4 casos de usos en donde cualquier solución para IP Flow debe operar satisfactoriamente. En la Figura 19 se puede observar cada uno de los escenarios planteados: el primero describe el caso cuando se añade un nuevo IP Flow a una sesión establecida previamente; el segundo en cambio describe cuando se remueve un IP Flow; en el tercero vemos la distribución de flujo dependiendo de interfaces activas, la parte 19-IIIa muestra que el flujo (color verde) se mueve hacia el acceso WiFi, esto pude pasar en caso que tengamos mayor conectividad en esta red o el servicio requiera de un mayor ancho de banda, en la parte 19-IIIb, en cambio tenemos todo el tráfico sobre la red móvil y luego un flujo se mueve hacia el acceso WiFi (tal vez porque la red se encuentra diponible durante ese intervalo de tiempo); el cuarto y último caso describe los casos donde los flujos son intercambiados totalmente de un acceso a otro. Figura 19. Casos de Usos de IP Flow y Conectividad MultiAcceso.

Tomado de [45].

Algunos de los requerimientos propuestos por la 3GPP con el respecto al IFOM se muestran a continuación [7]:

● La continuidad de los servicios debe ser proporcionada cuando un UE se mueve de un acceso 3GPP a un acceso non-3GPP y viceversa.

● Sí el UE está bajo la cobertura de más de un acceso, incluyendo accesos 3GPP y non-3GPP, debe ser posible para el UE, comunicarse usando múltiples accesos simultáneamente, siempre y cuando el UE sea autorizado por suscripción a acceder a los servicios de las PDN’s.

● Debe ser posible seleccionar un acceso cuando un flujo ya haya sido iniciado y redistribuir los flujos entre las redes de accesos mientras el UE esté conectado.

● Debe ser posible para el operador, habilitar y controlar el uso simultáneo de múltiples accesos.

● Debe ser posible distribuir los flujos hacia/desde un UE entre los accesos disponibles basado en las características del flujo y las capacidades de los accesos disponibles, evaluando las preferencias del usuario y políticas del operador, por ejemplo si ambos 3GPP y non-3GPP accesos están disponibles, flujos con altos requerimientos de QoS (e.g. voz) no deben ser enrutados hacia accesos non-3GPP, con el fin de evitar la degradación del servicio.

● Debe ser posible para el operador definir políticas para el control de la distribución de IP Flows entre los accesos disponibles. Cada política deberá incluir una lista de accesos preferidos y preferencias del usuario.

○ Esta políticas pueden ser definidas por APN, por IP Flow Class bajo cualquier APN o por IP Flow Class bajo una específica APN. El IP Flow Class identifica un tipo de servicio (e.g. voz sobre IMS) o la agregación de servicios definidos por un operador.

La Tabla 1 especifica las mejoras que deben realizarse sobre algunas de las entidades de EPS para soportar IP Flow, el trabajo realizado al respecto aún se encuentra en la etapa dos [7] por lo que mucha de la información aquí planteada puede sufrir modificaciones en las siguientes etapas. Tabla 1. Requerimientos Básicos para Soporte de IP Flow.

RELEASE-8 3GPP SISTEMA CON IP FLOW MOBILITY

Movilidad Inter-Sistemas Por UE Por Flujo IP dentro de cada PDN conexión.

Logica PCC & IP-CAN Especificación para señalización

PCC

Por IP-CAN (Conectivity Access Network)

Por Flujo IP dentro IP-CAN

Políticas del ANDSF para Movilidad Inter-Sistemas

Por UE Por IP Flow Classes dentro del UE

Tomado de [6] y [7].

2.4.2 Mejoras en los Protocolos de Movilidad para Soportar IP Flow Mobility.

Como se muestra en la Tabla 1 actualmente la granularidad y movilidad entre sistemas de acceso es basada por UE (User Equipment), es decir cada UE poseé una sola conexión PDN (Packet Data Network) por lo que cuando se produce un traspaso (Handover’s), todos los flujos IP que pertenecen a la misma conexión PDN se mueven desde el sistema de acceso de origen hacia el sistema de acceso de destino. Con IFOM (IP Flow Mobility) es posible tener una mayor granularidad en la conectividad a los sistemas de acceso y la movilidad entre sistemas, implementando los procedimientos de Handover a uno o múltiples flujos IP que pertenecen a la misma conexión PDN; esto implica que algunos flujos IP de una conexión PDN se pueden enrutar a través de un sistema de acceso al mismo tiempo que otros flujos IP de la misma conexión PDN se pueden enrutar a través de otro sistema de acceso, como se muestra en los escenarios planteados Figura 13. Para soportar IFOM, los protocolos de movilidad anteriormente descritos (ver sección 2.3) han sido modificados [6], [7], [22], [29], [30], [31], [32], [33], con el fin de que puedan transportar filtros de enrutamiento para facilitar el análisis de los flujos IP transportados por los UE.

2.4.2.1 Mejoras En DSMIPv6De acuerdo a [15] un UE puede tener múltiples CoA’s (Care of Address) pero sólo una puede ser denominada como “Primary CoA” y ser registrada con el HA (Home Agent) y CN (Correspondent Node); lo anterior permite identificar el Default Gateway en el User Equipment. Debido a esta limitación cuando un UE tiene múltiples interfaces y utiliza MIPv6, no puede enviar y recibir paquetes simultáneamente por las múltiples interfaces. La IETF en [22] propone una solución para soportar la registración de múltiples CoA y manejar paralelamente la conectividad, permitiendo que si un UE posee múltiples interfaces, estas pueden adquirir direcciones IP y registrarlas como CoA’s con el correspondiente HA y CN. Para registrar varios enlaces, un UE generará un BID (Binding ID) por cada CoA requerido y almacena el BID en la Binding Update List del equipo, al enviar el mensaje BU (Binding Update) para la registración de CoA en el Binding Cache, éste agrega un Binding Mobility Option (BMO) al BU donde se incluye el BID; cuando el HA recibe el BU con el BMO este copia el BID dentro del BC en el campo respectivo, revisando primero si este existe previamente. En la Tabla 2 se muestra un ejemplo del contenido del BC soportando registración de múltiples CoA’s. Tabla 2. Binding Cache en HA soportando la registración de múltiple CoAs.

HOME ADDRESS CARE-OF ADDRESS BINDING ID PRIORITY

HoA1 CoA1 BID1 x

HoA1 CoA2 BID2 y

Tomado de [6].

Con el fin de soportar el enrutamiento de múltiples flujos IP a través de diferentes

sistemas de acceso, el UE necesita solicitar al HA que almacene los filtros de enrutamiento, tal que uno o mas flujos IP puedan ser asociados a un CoA previamente registrado, y así el HA pueda identificar un flujo en particular y enrutarlo por el acceso especificado. El par CoA-HoA representa una regla de enrutamiento (Routing Rule) dado que especifica una ruta que es aplicada a todos los paquetes destinados a este par, no obstante, al hablar de IFOM y múltiples PDN’s (Packet Data Networks), la regla de enrutamiento ya no es aplicada a todos los paquetes, sino a los paquetes identificados por un filtro de enrutamiento (Rounting Filter). Los filtros de enrutamiento corresponden a un conjunto de parámetros valor/rango usados para identificar uno o más flujos. Estos parámetros son descritos por el Trafic Flow Template [31]. (1) remote address and subnet mask (2) Protocol Number (IPv4) / Next Header (IPv6) (3) local port range (4) remote port range (5) IPsec Security Parameter Index (SPI) (6) Type of Service (TOS) (IPv4) / Traffic Class (IPv6) and mask, and (7) Flow Label (IPv6). De igual manera como se presentó en la sección 2.2 para el tratamiento de paquetes en los EPS Bearers. Por lo tanto como se especifica en [22] y [30], el UE incluye el Flow Identification (FID) mobility option dentro del BU. El FID contiene las reglas de enrutamiento la cual contiene los filtros de enrutamiento y la dirección de enrutamiento (Routing Address). Al usar el FID un UE puede enlazar uno o más flujos a un CoA, en el caso que los flujos IP no coincidan con los FID almacenados en el BC, estos son enrutados a un dirección de enrutamiento por default, la cual es determinada por el BID con mayor prioridad de los BID’s almacenados por el UE. Cabe anotar, que lo filtros de enrutamiento son unidireccionales, por lo que pueden ser diferentes tanto para el trafico de Uplink (UL) como de Downlink (DL) al igual que las políticas de QoS. La Tabla 3 muestra un ejemplo del BC al añadir el FID, en esta se observa que los FID son únicos por HoA, sin embargo, otro HoA puede reutilizar valores de FID. Tabla 3. Binding Cache en HA soportando FID

HOME ADDRESS

CARE-OF ADDRESS

BINDING ID FLOW ID ROUTING FILTER

PRIORITY

HoA1 CoA1 BID1 FID1FID2

Dscp IP flows…Decp IP flows…

xy

HoA1 CoA2 BID2 FID1 Decp IP flows y

Tomado de [6].

Cuando IFOM es implementado, la arquitectura del PCC (Policy and Charging Control) debe ser mejorada para manejar múltiples conexiones simultáneas para cada sesión IP CAN. Estas mejoras requieren que el PDN Gw (Packet Data Network Gateway) mantenga informando al PCRF (Policy and Charging Rules Function) sobre los valores de las direcciones de enrutamiento de cada flujo IP. La descripción detallada de estas mejoras puede encontrase en [4] y los cambios de los procedimientos de establecimientos, actualización y borrado de flujos IP en las PDN’s en [7].

2.4.2.2 Mejoras En DSPMIPv6Las soluciones implementadas en DSPMIPv6 están basadas en los mismos principios para el DSMIPv6 en la sección anterior. Algunas de las diferencias son presentadas [32], [33] y [45]:

● Debido a que PMIPV6 es un protocolo orientado a la administración de la movilidad por parte de la red, el intercambio de las reglas de los filtros de enrutamiento en el PBU (equivalente al BU) son realizados por el S-Gw (Serving Gateway) actuando como MAG (Mobility Access Gateway) y el PDN Gw actuando como LMA (Local Mobility Anchor), en vez del UE y el PDN GW como en el anterior caso.

● El UE notifica al MAG para iniciar las funcionalidades de PMIPv6 enviando unos mensajes de disparo (triggers), dado que es el UE el que define los filtros de enrutamiento; el intercambio de estos filtros puede ser realizado utilizando alguno de estos métodos:

a. Mediante los mensaje de señalización entre el UE y el S-Gw utilizados al agregarse y establecer conectividad a una PDN un UE.

b. Por medio de los mensajes de señalización de PMIPv6 del S-Gw a el PDN Gw.

c.Via PCO (Protocol Configuration Option) en los mensajes de señalización de PMIPv6 entre el S- Gw y el PDn GW.

3. ESTADO DEL ARTE

En la actualidad muchos trabajos han sido desarrollados con el fin de analizar los protocolos para movilidad IP: Estudios de latencia, perdida de paquetes ante handover verticales, comportamiento a altas velocidades, micromobilidad, entre otros. No obstante, ninguno de estos toman en cuenta el efecto de implementar IP Flow Mobility en el desempeño de los mismos. De igual forma, desde otros de puntos de vistas estudios de multihoming han sido realizados buscando la arquitectura ideal para proporcionar múltiples dominios (interfaces virtuales, físicas o lógicas) o el diseño de algoritmos para la selección de la mejor ruta para el enrutamiento de paquetes. En [35] el autor analiza los problemas actuales de los protocolos de movilidad IP propuestos por la IETF en [15] (DSMIPv6) y [16] (PMIPv6), para soportar IP Flow Mobility. Los autores proponen una serie mejoras añadiendo nuevos tipos paquetes (BID-Binding Identification y FID- Flow Identification) y extensiones al Binding cache para permitir la registración de múltiples CoA’s y el enrutamiento de los flujos IP basados en los filtros de enrutamiento. No obstante, aunque la mayor parte de estas ideas fueron luego tomadas por la IETF y difundidas en [22]. Este trabajo no realiza un análisis cuantitativo de la solución propuesta, por lo que no brinda información de como esta solución afecta el desempeño de los protocolos de movilidad. En [48] el autor propone el diseño de un sistema autónomo para la selección automática y eficiente de rutas que ofrezcan las mejores características para el trafico cursado por uno o más nodos multi-homed (con múĺtiples interfaces). El principal objetivo del sistema propuesto es que el algoritmo de selección sea independiente con respecto al mecanismo o el protocolo de movilidad implementado. Para esto el sistema fue construido y opera bajo tres módulos funcionales y acoplados entre si. El primero, el Módulo de Información y Recolección el cual se encarga de recolectar información automáticamente de una variedad de fuentes como lo son: los requerimientos de la aplicación, los parámetros del dispositivo, las características de la red, las características de los sistemas de acceso, las políticas de enrutamiento, las preferencias del usuario y las política de selección de direcciones de acuerdo a la interfaz. El Modulo de Toma de Decisiones, es el segundo módulo y es el responsable de generar las reglas de enrutamiento basado en el algoritmo de selección propuesto por el autor. El tercer módulo denominado Módulo de Ejecución de Decisiones realiza el despliegue de las reglas de enrutamiento e informa a los nodos correspondientes las rutas para el curso del tráfico. No obstante, no se implementa un mecanismo que valide que los flujos son transmitidos correctamente; los resultados solo muestran su funcionamiento para el MIPv6 y la propuesta fue desarrollada mediante ns-2 (Network Simulator) [70[, [71], [72]. En [49] el autor propone la creación de una arquitectura común como el EPS para

las redes moviles y fijas usando MIP (Mobile IP) y el NEMO (Network Mobility) Framework propuesto por la IETF. Define el concepto de “Virtual Home Network” en las cuales los Home Agents se comunican mediante OSPF, BGP u otro protocolo de enrutamiento para detectar la agregación de nuevos dispositivos o redes móviles y ejecutar la sincronización de las base de datos de los Home Agents. A su vez, implementa modificaciones sobre MIP y NEMO para permitir la registración múltiple de CoA’s y indicar las políticas de trasmisión de paquetes desde los Home Agents hasta los nodos multi-homed. En [50] se expone un nuevo mecanismo para soportar multihoming sobre 802.11b (WiFi). Para esto el autor realiza extensiones sobre el MIPv4 (Mobile IP v4) para soportar múltiples registraciones de CoA’s. Asimismo, hacen uso de métricas para definir las estrategias de selección de rutas para el encaminamiento y balanceo del flujo como la relación señal a ruido (SNR) y una métrica propuesta por éste, la cual basa sus cálculos para la selección del Default Gateway en tres factores: la desviación entre los tiempos de llegada de algunos mensajes como el binding update, el ancho de banda y la capacidad de los FA (Foreing Agents) para soportar el trafico cursado por los MN (Mobile Nodes). En [51] [52], [53]. [54] y [55] los autores enfocan sus trabajos en estudiar los protocolos de movilidad IP como mecanismos para soportar la continuidad de servicios entre redes heterogéneas, para lo cual analizan distintas métricas como: la perdidas de paquetes (FTP, Voz, etc.), la tasa de transferencia, la latencia de los handovers, el throughput, la velocidad del UE, etc. y comparan sus resultados con otros protocolos de movilidad existentes como: HMIPv6 (Hierarchical MIPv6), FMIPv6 (Fast MIPv6), etc. Sin embargo no estudian los escenarios de multihoming y IP Flow mobility, además, los autores sólo muestran el desempeño de los algoritmos ante un escenario de los 4 propuestos en la sección 2.4.1 (la mayoría de los casos solo estudian el presentado en la Figura 19a) y los resultados de las mediciones para uno o dos métricas (throughput, latencia o handover).

4. ANÁLISIS DE PROTOCOLOS DE MOVILIDAD IP

Los protocolos de Movilidad IP fueron diseñados para medios donde los MN (Mobile Nodes) cambian constantemente su ubicación en la red, por lo que muchos de los avances realizados con el fin de mejorar el desempeño de las redes actuales (cableadas e inalámbricas) ven la implementación de esta arquitectura (EPS) como un nuevo gran desafío debido al resurgimiento de problemas como:

● Degradación del desempeño de aplicaciones (e.g voz) a causa de los frecuentes handover entre redes heterogéneas.

● El establecimiento de nuevos túneles para asegurar mecanismos seguros de comunicación, incrementa los retrasos de paquetes y en casos como los procesos de handover pueden ocasionar perdidas de paquetes y retrasos en la entrega de datos, mensajes de señalización y control.

● Incremento del tamaño de los paquetes IP para soportar la movilidad IP.● Consumo de mayor de recursos de red debido a que el operador deberá

asegurarse que las entidades soporten ambos protocolos IP (Operación Dual Stack), con todas las consideraciones que esto conlleva [19].

● Incremento de los mensajes de señalización en la red, dado a que cada host al ser capaz de administrar múltiples interfaces (multihoming), establecerá mecanismos de autenticación y procedimientos de asignación IP (DNS, métricas de enrutamiento, Time Of Service-TOS) por cada interfaz [26].

En este capitulo se analizarán las características y desempeño de los protocolos de movilidad IP Dual Stack Mobile IPv6 (DSMIPv6), Dual Stack Proxy Mobile IPv6 (DSPMIPv6) propuestos por la IETF y aceptados por la 3GPP para la implementación sobre el EPS (Evolved Packet System). Como primera medida se realizará un análisis cualitativo con el fin de identificar las principales diferencias entres los dos protocolos y mostrar claramente las funcionalidades que necesitan ser mantenidas por los protocolos de movilidad de IP. Luego, mediante un análisis cuantitativo se estudiará los efectos de la introducción de mejoras como el IP Flow Mobility (IFOM) y la conectividad Multiacceso simultánea sobre el desempeño de los protocolos, lo cual nos permitirá obtener métricas (throughput, conectividad, retraso de paquetes, perdida de paquetes, etc) que luego se compararán con los mismos escenarios sin soportar estas dos últimas características y nuestra propuesta (ver sección 6) para determinar el factor o porcentaje de mejoramiento de los protocolos de movilidad IP en cada uno de los aspectos evaluados.

4.1 ANÁLISIS CUALITATIVO

A continuación se presentará el análisis cualitativo de los protocolos de movilidad IP mencionados previamente en la sección 2; los criterios escogidos para la comparación son producto de la retroalimentación encontrada de otros trabajos, IETF RFC’s y Draft’s .

Tabla 4. Análisis Cualitativo de Dual Stack Mobile IP v6 y Dual Stack Proxy Mobile IP v6.

CRITERIOS DSMIPV6 DSPMIPV6

Performance * Estudios como [56], [57] y [58] muestran problemas como: latencia de Handover, pérdida de paquetes, y saturación de los enlaces debido a la gran cantidad de mensajes de señalización.* Problemas de Suboptimal routing debido a que todos los paquetes son enviados por el Home Agent [57].* Intercambio de mayor número de mensajes en la red [59].* Micromovilidad mejora el desempeño al reducir los frecuentes mensajes BU [65].

* Reducción considerable de señalización en las redes de acceso.* Problemas con la continuidad de servicios, aplicaciones y sesiones al abandonar un dominio [58].* Reducción de requerimientos para el UE en términos de procesamiento y recursos.* Problemas para realizar procedimientos de handovers inter-domains [64].* Reduce la necesidad de crear túneles sobre los enlaces inalámbricos [24].* Incompatibiliad para trabajar con las actuales NEMO estándares (WiMAX) [23].

Security * Túneles IPSec y autenticación por medio IKEV2.• Túneles bidireccionales creados entre cada MN y HA. [25] .* Requiere de cambios en los firewall/VPN/DMZ para soportar movilidad sobre intranet’s.[20]* Renegociación de parámetros de IPSec cuando el MN se mueve [20], e.g. cambios de CoA’s.* Dificultades para la detección de salida de nodos de la intranet’s.*Utilizar encriptación aún cuando el MN esta dentro de la red ocasiona: Altos consumo de batería; procesamiento extra para el UE y los switches; los equipos que asumen como HA no integran típicamente funcionalidades de IPSec; IPsec requiere de autenticación del usuario, la cual puede ser solicitada interactivamente, por lo que la movilidad puede afectar la usabilidad, el aumento en la administración y las credenciales VPN por cada dispositivo [20].

* Implementa IKEV2 y Network Domain Security (NDS/IP) para el establecimiento de Túneles IPSec [20].* El UE es más vulnerable dado que los parámetros IP asignados son en la mayoría de casos los mismos [67].* El MAG puede verse comprometido cuando los MN’s se conectan desde sistemas de acceso untrusted non-3GPP. [66].* Túneles bidireccionales solo son creados entre el LMA y el MAG. Un túnel es compartido por lo que puede enrutar tráfico de los diferentes MN’s agregados a un MAG [66].

Deployment * No requiere cambios en los CN o DNS* Túneles pueden verse afectados por NAT y Firewalls, la transición completa a IPV6 solución + viable.* La Implementación de micromovilidad requiere de infraestructura adicional [65].

Requiere de proveer al LMA y MAG con mecanismos óptimos de detección de entidades y rastreos del UE [59].

Scalability * Requiere de múltiples HA’s para soportar muchos mobility bindings.* Operaciones por paquete pueden se realizadas en el UE reduciendo el número de mensajes [34].

Requiere de mecanismos óptimos de enrutamiento de mensajes en entre el LMA y el MAG, debido al aumento considerable de estas entidades.

Mobility Type Host Based, el equipo se encarga de detectar la movilidad y los mensajes de señalización relacionados [47].

Network Based, La red se encarga de realizar las operaciones de seguimiento y administrar los mensajes de señalización, el UE detecta siempre la misma Home Network [47].

Route Advertisement

BroadCast, debido a que utiliza un modelo de prefijo compartido por subred, por lo que

Unicast, utiliza un modelo de prefijo por MN, por lo que mecanismos de

es necesarios mecanismo de detección de movimiento y DAD, lo cual puede degradar el desempeño durante los de handover [59] .

detección de movimiento y asignación de direcciones duplicadas (DAD) no son necesario dentro de un dominio [59].

Mobility Scope Movilidad Global, las configuraciones y mensajes a los MN pueden ser realizadas de manera conjunta si estos se encuentra en una misma subred [58].

Movilidad Localizada. los mensajes de configuración son realizados por cada MN [58].

Handover Management

Sí (Limitada), Dependiendo de la capacidades del UE, si este no soporta ciertos mecanismos de movilidad esta fallará [64].

Sí, Dado que la red se encarga de estos procedimientos se hablan de algoritmos de Handover optimizado y no Optimizados dependiendo de las redes de acceso origen y destino [64].

Air interfaceTraffic Overhead

Alta, mucho tráfico de señalización de movilidad (BU) es cursado por las redes de acceso sino se implementan mecanismos como la Micromovilidad para su reducción [64].

Bajo, por ser un protocolo de movilidad basados en la red (Network-Based) [64].

TunnelingOverhead at UE

Alta, requiere de alto consumos de procesamiento y batería por parte del UE para el análisis de paquetes enviado a través de túneles [61], [62].

No, El consumo de recursos es realizado por la red [61], [62].

RequiredInfrastructure

HA/PDN GW, es el encargado de crear los bindings entre el HoA y el CoA para enrutamiento de paquetes cuando el UE se encuentra sobre una Visitor Network. estos binding son túneles IPSec para proteger los mensajes de señalización [66].

LMA- MAG, estas dos son dos nuevas entidades en la red encargadas de enviar los mensajes PBU y PBA para soportar la movilidad IP [66].

Support Intra-Network Traffic:

Sí, Intercambio de paquetes entre el UE y los nodos que se encuentran en la misma red usando la interfaz S2c para este fin [60].

Sí. la única diferencia es que los mensajes usarán las interfaces S2a o S2b dependiendo del tipo de red en la que se encuentre el UE [60].

MN Modification Sí, los UE requieren de un software cliente que es el encargado de soportar la movilidad [47].

No, el UE cree siempre estar sobre la misma Home Network, la cual es emulada por el MAG correspondiente, por lo que la misma IP y parámetros de acceso son entregados al UE [47].

Handover Latency

Mala, exceso de mensajes entre el UE y las entidades, debido a mecanismos de handover y IP Flow. Mecanismos como soporte a micromovilidad, Route Optimization, Triangular Routing son utilizados para reducir el número de mensajes; o mejoras en la arquitectura como Hierarchical Mobile IPv6 (HMIPv6) [68] y Fast Handovers for Mobile IPv6 (FMIPv6) [60]

Buena, dado que no se envían mensajes de señalización de movilidad sobre las redes de acceso hacia el UE, sino que los LMA’s y MAG’s se encargan de intercambiar estos mensajes.

Support MicroMobility

Sí, Se crean dóminos que permitan manejar la movilidad intra-domain (local) del UE sin comunicarse con los HA’s. Distintos protocolos son implementados como: HMIP, Cellular IP, Hawai etc [60], [61] y [62].

Sí, Dado que muy poco mensajes de señalización son enviados al UE. Mecanismos para mejorar el desempeño durante los procesos de handover como: la comunicación directa entre MAG‘s sin LMA de intermediario para intercambio de mensajes de BU’s [60], [61] y [62].

Support IP Flow No. Necesita de extensiones al protocolo, se añaden el FID (flowid), BID (Binding ID) y Routing Filter [6], [7].

No. Aún no es soportado, aunque ya se han realizado especificaciones, éstas no han sido aceptadas completamente por la IETF. como por ejemplo, el transporte de los filtros de enrutamiento entre el UE y el MAG [6], [7].

Requirement of New Header IPV6

Sí, el MIH fue desarrollado con este propósito, los mensajes BU y BA son de estos tipo [15].

Sí, el MIH fue desarrollado con este propósito , los mensajes PBU y PBA son de estos tipo [16].

Support Dual Stack

Sí, soporta direccionamiento IPv4 CoA, IPv4 HoA y IPv4 HA sobre señalización MIPv6 No obstante requiere que el UE siempre le sea asignada un HoA IPV6 [17].

Sí, las características son igual al DSMIPV6 a excepción que no es obligatorio que el UE le sea asignada un HoA IPV6 [10].

Multi-Homming No nativamente, requiere de modificaciones al protocolo para permitir al UE utilizar múltiples direcciones, dado que se requiere que configuraciones independiente por cada interfaz. Cada interface puede administrarse como un HoA independiente o usar un mismo HoA pero diferente BID y FID. y compartir un mismo Binding Cache [26].

Sí nativamente, no requiere modificaciones del protocolo, dado que el MAG se encargará de la asignación de los diferentes HoA. soporta los escenarios de: i) prefijo único por interface ii) mismo prefijo pero direcciones globales diferentes por interface. y el iii) compartir direcciones través de múltiples interfaces, debido a la complejidad de este.Cada interface representará un Home Network en el UR, porque cada una será tratada como una sesión independiente, es decir, un propio Binding Cache [32], [33].

De la anterior tabla se podría inferir fácilmente que DSPMIPv6 ofrece mejores características en muchos aspectos, por lo que debería ser el protocolo ampliamente utilizado para soportar movilidad IP entre los diferentes sistemas de acceso (3GPP, trusted non-3GPP y untrusted non-3GPP), sin embargo, los problemas de continuidad de sesión entre dominios y sobre NEMO’s (Networks Mobile) [24], entre otros no permite esta estandarización.

4.2 ANÁLISIS CUANTITATIVO

El escenario propuesto es tomado de [6] y mostrado en la Figura 20. consta de dos sistemas de acceso: el primero una red 3GPP (UMTS) y el segundo una red Untrusted non-3GPP proporcionado por un hotspot WiFi doméstico, representando por la red WiFi de una casa. El UE (User Equipment) posee dos interfaces, cada una con la capacidad de conectarse a uno de los sistemas de acceso mencionados y a los siguientes servicios disponibles sobre el escenario desplegado y siguiendo estos pasos:

● Iniciar una sesión en un Web Browser (IP Flow 1-IPF!).● Ver video clip a través de la web Browser (IP Flow 2-IPF2)● Realizar una llamada, la cual requiere de un flujo de voz IP (IP Flow 3-IPF3)● Descarga de un archivo mediante FTP en un servidor de Backup externo vía

WiFi (IP Flow 5-IPF4).

El UE al ubicarse sobre la red WiFi inicia una sesión en su navegador y comienza a ver un video clip alojado sobre la internet. Todo el tráfico generado por estos 2 flujos (IPF1 y IPF2) es enrutado por el acceso WiFi, simultáneamente realiza una llamada (VoIP) utilizando un aplicativo cliente alojado en el UE, enrutando el tráfico (IPF3) a través del acceso 3GPP. La selección de rutas para la transmisión de los servicios, es tomada teniendo en cuenta las políticas definidas por el usuario (alojadas en el UE) y el operador (Qos y BW). Luego el UE comienza la descarga de un archivo FTP (IPF4), el cual ocasiona que el acceso WiFi se congestione por lo que el Flujo generado por el video clip (IPF2) es trasladado al acceso 3GPP debido a los bajos requerimientos de QoS de este. Al finalizar la descarga, el IP Flow 2 es retornado hacia el acceso WiFi. Finalmente, el UE sale y pierde conectividad WiFi por lo que todos los flujos son enrutados hacia el acceso 3GPP inmediatamente. Figura 20. Escenario para el Estudio del IP Flow Mobility.

Como se logra observar, el escenario planteado permite analizar todos lo casos de uso planteado en la Figura 19 enfocándose en el estudio de la continuidad de los servicios, la movilidad del flujo IP y como este último puede mejorar el desempeño de los protocolos de movilidad IP; entre las características más relevantes del escenario tenemos:

● 50 metros de cobertura de la estación base (NodeB), ancho de banda de 128kbps.

● 10 metros de cobertura del access point en la red WiFi, ancho de banda 512kbps.

● Tiempo de la simulación 120 segundos.● 30 segundos después de iniciar la simulación comienza de la descarga del

archivo FTP finalizando a los 70 segundos, por lo que la congestión del canal y el traspaso del servicio del video clip se dará en este lapso de tiempo.

● La velocidad promedio del UE es 1m/s y su movimiento comienza a los 80 seg.

● Para la llamada se generan paquetes de VoIP de 50kB que son transmitidos cada segundo, para el video 3KB Frames de video son transmitidos cada 5fps, por otro lado, los tamaños de las páginas web son 20Kb y son actualizadas cada segundo, y el tamaño del archivo FTP descargado es de

15MB.● La Estación Base y el Hotspot esta conectados a el CN y a internet

(conexiones cableadas) a través de un Router de Acceso mediante enlaces duplex de 1Gbps y retrasos de 10ms.

● Los puntos o resultados mostrados en las gráficas mostradas a continuación son el resultado del promedio de 500 simulaciones con el fin de asegurar un intervalo de confianza de 95% con respecto al valor promedio

Asimismo, un escenario sin soporte a IP Flow Mobility fue planteado para poder comparar los resultados obtenidos; éste es similar al planteado con anterioridad diferenciándose en que durante la primera parte transmite todos los flujos sobre la red WiFi, y cuando el MN (Mobile Node) comienza a moverse y pierde conexión con el acceso WiFi, todos los flujos son transladados hacia el acceso 3GPP. Para construir los escenarios y simular el comportamiento del UE y los protocolos DSMIPv6 y DSPMIPv6 se utilizará el software ns-2 (Network Simulator) [70[, [71], [72] y las extensiones para soportar MIPv6, PMIPv6 y multihomming realizadas por [73], [74] y [75], además de algunas modificaciones que fueron realizadas con el fin de extender el código para cumplir con varias de las propuestas del IETF en [6], [15], [16], [17] y [22] como:

● Múltiple registración de CoA’s● Conectividad Multiacceso.● Extensión al Binding Cache para manejar el BID y FID.● Extensión al BU para soportar el uso de BID y FID y administrar IP Flows.

Para la evaluación de desempeño distintas pruebas fueron requeridas, entre las cuales tenemos:

● Conectividad: Esta puede ser observada por medio de los números de secuencia (sequence number) de los paquetes entrantes, en caso de fallas en la conectividad este número no incrementará indicando las perdidas de paquetes.

● Latencia: Este parámetro es definido como el intervalo de tiempo entre el último paquete recibido por el MN a través de una antigua ruta y el primer paquete de la nueva, se evaluarán los casos de handover vertical y enrutamiento de flujo.

● Retraso de paquetes: Es el intervalo de tiempo desde que el paquete es enviado desde el CN y es recibido por el MN.

● Throughput: Representa el número promedio de bytes que el MN recibe o transmite en un determinado intervalo de tiempo durante la simulación.

● Perdida de Paquete: Como su nombre lo indica representa la cantidad de paquetes perdidos, borrados o deteriorados durante los mecanismos de handover, y enrutamiento de flujos.

● Ancho de Banda por acceso: Es el ancho de banda consumido por cada uno de los servicios corriendo sobre el MN y que son enrutados sobre los sistemas de acceso propuestos.

Las Figuras 21 a y b presentan los resultados de la simulación del escenario para cada uno de los protocolos de movilidad IP propuestos, comparando los resultados de implementar o no IP Flow Mobility. Figura 21. Comparación de Conectividad para DSMIPv6 y DSPMIPv6 utilizando el Número de Secuencia de los Paquetes Entrantes. Evaluando Casos Multihoming (2 interfaces) y IFOM vs Modelo Original (una interfaz).

La primero que se observar es la degradación del servicio de video clip (IPF2), al momento de iniciar la descarga del archivo FTP a los 30seg ocasionando la perdida de paquetes (líneas punteadas rosada-Figura 21a, punteadas verdes-Figura 21b) entre los 30seg y 70seg, por el contrario, al implementarse IFOM se observa que la degradación es leve debido a las características ofrecidas por el acceso 3GPP (menor ancho de banda, menor velocidad de transferencia, etc.), sin embargo esto no genera pérdidas de paquetes (línea amarilla-Figura 21a, línea roja-Figura 21b). Lo anterior, muestra que la conectividad alcanzada en un sistema con soporte a IFOM es mejor, dado que permite enrutamiento inmediato de los flujos generados por nuestras aplicaciones, en caso de saturación o fallas de los sistemas de acceso por los cuales están siendo transmitidos. Sin embargo, todas estas perdidas son generadas por los mensajes de Binding Update (BU) y los tiempos de actualización de los FID en los Binding Cache en el Home Agent (HA) y el Correspondent Node (CN). Cabe aclarar, que para definir el enrutamiento de los flujos IP son tomadas en cuenta las políticas de QoS y los Traffic Flow Templates definidos por el usuario previamente en su dispositivo y las establecidas por el operador en sus sistemas acceso, es decir, el enrutamiento del flujo es evaluado dos veces (ver sección 6). Por otro lado, desde los 80seg en el momento que el UE inicia su movimiento, los flujos que ocupan el acceso WiFi son trasladados hacia el acceso 3GPP debido al poco alcance que esta ofrece. Para el caso del tráfico Web (IPF1) se observa que ambos protocolos no presentan perdidas de paquetes al momento del Handover vertical por lo que emplean TCP como capa de transporte y TCP retransmite los

paquetes perdidos. No obstante, para los casos de VoIP (IPF3) y el video clip (IPF2) que utilizan UDP, se muestra una considerable discontinuidad de ambos servicios entres los 80seg y 90seg cuando IFOM no es implementado (con IFOM las perdidas solo se presentan IPF2, dado que éste previamente se ejecuta sobre el acceso WiFi), dado que los servicios operan por único acceso y una mayor cantidad de flujo es enrutado al momento del cambio. Como se mencionó en la Tabla 4, las características de DSPMIPv6 muestran que el desempeño de éste al ser un protocolo Network-Based es mejor que el presentado por DSMIPv6 (Host-Based, ver Sección 2.3). De la anterior gráfica, se logra evidenciar que los tiempos de respuesta y perdidas de paquetes mostrado por DSPMIPv6 ante los casos de movilidad estudiados son menores debido a la reducción de mensajes de señalización y al no uso de túneles (IPSec’s) para la transmisión de paquetes en las redes de acceso, consumiendo un menor ancho de banda. Lo anterior permite que en caso de saturación de un acceso, los servicios disponibles no se vean afectados por el consumo del canal generado por el mismo protocolo, logrando que la pérdida de paquetes se reduzca en equipos con una sóla interfaz. La Figura 22 muestra claramente la diferencia entre los tiempos de respuesta o latencia generados por los dos protocolos durante el Handover Vertical y el enrutamiento de flujos por saturación del acceso WiFi. Figura 22. Impacto de IFOM en la Latencia Generada a) por el Handover y b) el Movimiento de Flujo de un Acceso a otro.

Una diferencia notable en los tiempos de respuesta de aproximadamente 1.06s (DSMIPv6) y 394ms (DSPMIPv6), es vista cuando analizamos la latencia durante el Handover en los casos comparados. Esta diferencia es generada por la reducción de los tiempos requeridos para la actualización del Binding Cache (BC) al usar dos interfaces, dado que muchos de estos procesos pueden ejecutarse paralelamente sobre los dos accesos, reduciendo la carga producida por estos. De modo similar, las diferencias presentadas entre los tiempos de ambos protocolos son ocasionadas

por la reducción del tráfico de señalización para cada acceso, lo que evita la congestión de mensajes y por consiguiente una menor competencia por los recursos disponibles. Cabe resaltar, que el uso de dos interfaces genera una cantidad mayor de mensajes de señalización en el EPC (Evolved packet Core), debido a que cada una de éstas es tratada de manera independiente, cada una generará mensajes de solicitud de parámetros de configuración (Subred, Gateway, DNS, TTL etc.), además de nuevos mensajes de control para resolver conflictos de selección y enrutamiento de tráfico a través de otras interfaces, como la selección de dominios o el sobrelapamiento de los espacios de nombre. Las tablas 5 y 6 muestra un resumen del tiempo promedio que tarda un paquete TCP y UDP en ser transmitido entre el MN (Mobile Node) y el CN (Correpondent Node) y el throughput promedio generado durante un intervalo de tiempo. Tabla 5. Promedio de Retraso de paquetes entre el MN y el CN.

UDP-No Paquetes

DSMIPv6-IFOMRETRASO (ms)

DSMIPv6RETRASO (ms)

DSPMIIPv6-IFOMRETRASO (ms)

DSPMIPv6RETRASO (ms)

1 3 7 1 4

10 27 49 10 20

100 305 512 98 213

1000 1050 5134 605 2080

TCP-No Paquetes

1 4 7 2 5

10 22 36 18 58

100 296 423 78 92

1000 9000 27000 825 1700

Tabla 6. Resumen de Troughput Promedio para Trafico TCP y UDP sobre Una y Dos Interfaces.

TROUGHPUT PROMEDIO(kbps)UNA INTERFAZ

TROUGPUT PROMEDIO(kbps)DOS INTERFACES

DSMIPv6-IPF1 1842 4945

DSMIPv6-IPF2 1203 6820

DSPMIPv6-IPF1 3016 6781

DSPMIPv6-IPF2 2930 7943

Por medio de estas pruebas se pretende analizar el comportamiento de los protocolos de movilidad IP como balanceadores de carga. Los resultados

demuestran efectivamente que los tiempos de respuesta se reducen y el throughput generado es mayor. Por ejemplo, se encontró que al transmitir 1000 paquetes TCP (Conexión web-IPF1), el tiempo promedio de respuesta si utilizamos dos interfaces es 18seg más rápido que implementar un sola interfaz (ver Tabla 5). Las diferencias de tiempos entre ambos protocolos es generada, por el mayor número de mensajes de señalización y por el cuello de botella generado por el mayor consumo de recursos de CPU y memoria del MN (Mobile Node) cuando se implementa DSMIPv6, dado que éste gestiona todas las operaciones referentes a la movilidad desde el mismo equipo. Por otro lado, el throughput nos brinda una referencia del tráfico cursado en la red y como éste se puede hasta triplicar al implementar IFOM. Figura 23. Impacto de IFOM en la Perdida de Paquetes para DSMIPv6 y DSPMIPv6.

Un parámetro de gran importancia de medir es la perdida de paquetes, la Figura 23 muestra el resultado de este parámetro. Como se definió anteriormente, la perdidas de paquetes solo es observada sobre los servicios soportados sobre UDP, la Figura 23 muestra la perdida de paquetes sólo para los flujos IPF2 y IPF3 (una interfaz) y IPF3 (dos interfaces) durante el Handover vertical y la saturación del acceso WiFi. Una primera observación es que un 82% de la perdida de paquetes fue generada al momento de UE moverse y generar el Handover entre las redes heterogéneas utilizando DSMIPv6; por el contrario, con DSPMIPv6 se obtuvo un 94% de perdidas por la misma causa, lo que muestra que es un área que aún presenta problemas para el esquema de movilidad sin interrupciones propuesto en el EPS. Gran parte de estas pérdidas son causada por la falta de mecanismos de enrutamiento de paquetes entre las entidades encargadas de gestionar la movilidad en cada uno de los protocolos. Por ejemplo, para PMIPv6 al momento de realizarse un handover, el MAG actual primero informa al LMA correspondiente que el MN está dejando su área de cobertura, el LMA luego se encarga de encontrar otro MAG cercano al cual asignar la administración del MN, al encontrarlo el LMA procede a coordinar el enrutamiento de mensajes entre los dos MAG a través de éste [16]. Lo anterior, evidencia los problemas de optimización de enrutaminto de paquetes, dado que los dos MAG podrían comunicarse directamente mediante un túnel IPSec y realizar

el intercambio de paquetes entre ellos, luego de que el LMA haya identificado el MAG destino. Para resolver problemas como los anteriores, la IETF ha desarrollado extensiones como [68] y [69] o la activación de la micromovilidad, las cuales no se tratará en este documento. Figura 24. Impacto de IFOM en el Consumo del Ancho de Banda para DSMIPv6 y DSPMIPv6.

La Figura 24 permite exponer como el uso de IFOM y multihoming mejora el consumo de ancho de banda, logrando una mayor disponibilidad de los recursos ofrecidos, mejorando de esta forma el rendimiento, confiabilidad y disponibilidad de la plataforma. Contrario a los escenarios que evaluan el comportamiento con una sóla interfaz, en donde se presentan altos consumos sobre cada acceso, causando la degradación de los servicios mientras el otro acceso se encuentra totalmente disponible y sin carga alguna. Es importante resaltar que aunque IFOM y multihoming permiten mejorar el desempeño de la red móvíl como se mostró anteriormente. Éstos generan a su vez un mayor consumo de las baterías de los MN, lo cual puede ser un impedimento para aprovechar al máximo estas características si el equipo es un celular, tablets etc.

5. PROPUESTA

Hasta este punto el enfoque del documento ha sido evaluar y presentar las mejoras en cuanto al desempeño de los protocolos de movilidad IP al utilizar múltiples interfaces (multihoming) y implementar movilidad de flujo IP (IP Flow Mobility). No obstante, un escenario multiservicio como el presentado, es importante que el EPS proporcione una solución eficiente que garantice el QoS y asegure que la experiencia el usuario final sobre cada servicio sea aceptable. Actualmente, las especificaciones para las políticas de QoS de cada flujo no están muy bien definidas dentro los mensajes intercambiados entre el UE y el PCC (Policy and Charging Control), y por el contrario lo que se tiene es un conjunto de políticas para el enrutamiento del flujo sobre cada interfaz (reglas de enrutamiento y filtros de enrutamiento, ver sección 2.4.2.1) que son enviadas junto el FID (Flow identifier Mobility Option) dentro del Traffic Selector Sub-Option en el BU (Binding Update). Estas especificaciones son descritas por medio de un formato binario presentado en [31] y presentado en las Figuras 25a y 25b. Las Figuras 25c y 25d muestran como estas políticas y el Traffic Selector determinan, por ejemplo que todo el tráfico TCP que corresponde a la IP3 sea enviado al BID2 y el tráfico UDP a los CoA’s IP1 y IP2. Figura 25. a) IPv4 b) IPv6 Binary Traffic Selector c) Tratamiento de Flow Bindings, d) Relación bid y CoA’s.

Tomados de [31]. Al seleccionar la interfaz por el cual se va transmitir los flujos, nuevamente mecanismos de TFT’s u otro mecanismos (accesos non-3GPP) son implementados para identificar el EPS Bearer (2G/3G 3GPP) o PDP contextos (LTE), sobre los cuales transportar los flujos y garantizar el tratamiento apropiado de QoS (ver sección 2.2). Teniendo en cuenta lo anterior y con el fin de implementar un mecanismo simple y efectivo para la diferenciación de servicios y aplicación de políticas de QoS, y dado que muchas veces los mecanismos de selección (TFT’s) son idénticos en ambas etapas (selección de interfaz y selección de canal). Se propone la implementación de un mecanismo para que los MN hagan referencia a los TFT’s o filtros de paquetes definidos sobre la red de acceso, y utilizar estos como filtros de enrutamiento dentro de los mensajes de Binding Update (BU). Para esto se propone, el uso de un nuevo paquete denominado TFTR (Traffic Flow Template Reference Mobility Option) junto a un TFTRID (Traffic Flow Template Reference Identification) que remplace el actual FID (Flow ID Mobility Option) como se muestra en la Tabla 7. Tabla 7. Propuesta de Binding Cache en HA soportando TFRID.

HOME ADDRESS CARE-OF ADDRESS BINDING ID TFTRID

HoA1 CoA1 BID1 TFTRID1TFTRID2

HoA1 CoA2 BID2 TFTRID1

Esta modificación ofrece ventajas como:

● Reducción del número de mensajes BU realizados dado que el TFTRID solo se modificará cuando se remueve, actualice o por adicción de nuevos flujos y no cuando características de QoS (tasa de transferencia, ancho de banda) sean modificadas.

● Reducción del tamaño de los mensaje BU, lo cual junto a la anterior pueden llegar a solucionar los problemas de congestión en el plano de control y del usuario.

A continuación se describirán los cambios más relevantes en el EPS para la implementación del TFTR.

5.1 ESTRUCTURA DEL TRAFFIC FLOW TEMPLATE REFERENCE MOBILITY OPTION

Para la creación de la estructura fue tomado como ejemplo el esquema del Traffic Selector Sub-Option en [31]. Figura 26. Traffic Flow Template Reference Mobility Option.

Modificado de [31]. Tabla 8. Descripción de Parámetros del TFT Reference Mobilty Option.

PARÁMETROS DESCRIPCIÓN

Option Type 3 definido por [31]

Opt Length Variable, pero generalmente es de 8 bits y representa el tamaña del TFTR Mobility Option

TFT Format Es un campo de 8 bits y es utilizado para identificar el formato del mecanismo seleccionado para filttrado de paquetes, 1-TFT EPS Bearer, 2-TFT PDP Contexto, 3-Mecanismo de WiFi, 4-Mecanismo WiMAX, etc.

Reserved Un campo de 8 bits y debe ser cero para que el receptor y emisor lo ignoren.

TFT Reference ID Es un campo de longitud variable y almacena el ID del mecanismo seleccionado para el filtrado de paquetes,

en el caso de ser el TFT EPS Bearer almacenaría el Bearer ID.

5.2 PROCEDIMIENTOS

Los mecanismos utilizados para actualizar, remover y agregar el TFTRID son basados en los procedimientos propuestos en [22] y planteados a continuación:

5.2.1 Establecimiento de un TFT Reference ID

A continuación se describirá paso a paso el procedimiento para el establecimiento del TFTRID sobre el EPS; la Figura 27 muestra detalladamente la evolución del procedimiento sobre el EPS.

1. El UE solicita al ANDSF una lista de los accesos disponibles desde su ubicación

2. El ANDSF retorna un lista con los accesos disponibles.3. El UE inicia un servicio, por ejemplo por una llamada IMS, la señalización del

servicio utiliza SIP (Session Initiation Protocol). Una descripción del servicio

es proporcionada como parte del mensaje SIP, por medio del SDP (Session Description Protocol) y es recibida por el AF (Application Function) o P-CSCF (Proxy-Call Session control Function-visto desde la arquitectura IMS).

4. El P-CSCF se encarga de extraer la información suministrada por el servicio relacionada con las políticas de QoS requeridas.

5. El P_CSCF se comunica con el PCRF (Police Charging and Rules Function), el cual con la información extraída del servicio junto con: los datos de accesos disponibles, las políticas de servicios definidas por el operador, la información de suscripción solicitada y proporcionada por el SPR (Subscriber Profile Repository) y otros datos, construye una regla PCC (Policy and Charging Control) y la regla de QoS.

6. La regla de QoS es enviada al BBERF por el PCRF, para la posterior activación y Bearer Binding.

7.La regla PCC es enviada por el PCRF al PCEF (Policy and Charging Enforcement Function) localizado en el PDN-Gw que se encargará de la activación de la regla y la creación o modificación de los EPS Bearers, contextos PDP u otro con las políticas definidas en la regla PCC, asegurando que el tráfico cursado por el servicio solicitado le sea proporcionada las características solicitadas de QoS.

8. La información con el EPS Bearer es transmitida al UE indicando el TFTRID proporcionado (Bearer ID) y sobre que acceso debe operar.

9. Luego el UE envía el mensaje BU para agregar esta información al Binding Cache en el HA (Home Agent) o LMA (Local Mobility Anchor) dependiendo del protocolo que implemente; cabe recordar que éste es el mismo PDN-Gw.

10.Se inicia el tráfico del flujo requerido mientras que el HA se encarga de vigilar que el tráfico esta siendo transmitido por el acceso correcto.

Figura 27. Procedimiento de Implementación del TFRID en el EPS.

Modificado de [47].

5.2.2 Actualización y Eliminación del TFT Reference ID

Las actualizaciones de un TFTRID pueden darse en caso de degradación de unos de los accesos por una alta congestión o saturación del ancho de banda. En estos casos el PCRF informa al HA sobre el problema presentado y le indica cual es el acceso a donde debe enrutar los flujos IP, basado en las reglas PCC establecidas anteriormente. Luego, el HA se encarga de informar al UE cual es el nuevo TFTRID y éste mediante un BU (Binding Update) actualiza la información almacenada en el cache para los BID (Binding ID) relacionados con el antiguo TFTRID. Cuando se presenta el caso en que el EPS bearer es cerrado o colapsa, el UE detecta el evento y envía un BU al HA solicitando remover el TFTRID. Como mencionamos en la sección 2.4.2 las mejoras realizadas en este contexto de un protocolo son aplicables para ambos protocolos (DSMIPv6 y DSPMIPv6) sin ningún problema, teniendo en cuenta simplemente las diferencias entre las entidades (MGA y LMA) y los mensajes (PBU-Proxy Binding Update) utilizados.

6. RESULTADOS

Se ha mencionado en la sección 5 que la implementación del TFT Reference Mobility Option como descriptor para el enrutamiento de los flujos IP en remplazo del Flow ID Mobility Option ofrece mejoras significativas debido a la reducción del número de Binding Updates y la reducción del tamaño de estos mensajes. Es de especial interés cuantificar estas mejoras, para lo cual basado en el escenario y las métricas propuestas en la sección 5.2, se medirán el costo total generado por el tráfico de señalización, la tasa de paquetes perdidos y el ancho de banda consumido. Figura 28. Comparación de Conectividad para DSMIPv6 y DSPMIPv6 utilizando de Número de Secuencia de los Paquetes Entrantes. Evaluando Uso de TFTRID.

Figura 29. Impacto de IFOM y el TFTRID en la Latencia Generada a) por el Handover y b) el Movimiento de Flujo de un Acceso a otro.

Las Figuras 28 y 29 muestran dos claros resultados de mejoras en la movilidad de un Mobile Node cuando realiza un handover entre redes heterogéneas. Como se observa al implementar la propuesta realizada, los problemas de conectividad mostrados anteriormente al trasladar todos los flujos a un solo acceso son reducidos al orden de la década milisegundos. Asimismo, la latencia comparada con los tiempos presentados en la sección 5.2 que eran del orden del centenar de milisegundos, arroja una reducción de aproximadamente 78% en los tiempos para ambos protocolos. En gran medida, estos resultados son logrados debido a la disminución de los tamaños de los mensajes de Binding Updates, dado que solo el Traffic Selector Sub-Option definido por la IETF para el Flow Identification Mobility Option en IPv4 tiene un tamaño de 33 bytes mientras que el TFTRID propuesto tiene un tamaño de sólo 4 bytes. A diferencia del escenario propuesto con anterioridad en la sección 5.2, en el cual se analizó el comportamiento de los 2 protocolos de movilidad IP (DSMIPv6 y DSPMIPv6) ante los escenarios de IP Flow Mobility y multihoming planteados. En éste sección se evaluará el desempeño de los protocolos ante la degradación de las métricas de desempeño propuestas simulando mediante ns-2 (Network Simulator) un MN (Mobile Node) operando bajo interferencia, generada por un número variables de MN (máximo 100) que siguen un modelo de movilidad aleatoria denominado RWP (Random Waypoint Mobility), que permitirá estudiar tanto la escalabilidad del ambiente propuesto como la simulación de un ambiente más realista al emular el movimiento común de un grupo de usuarios dentro de una red. Con el fin de comparar los resultados obtenidos con el uso de TFTRID Versus los modelos anteriormente propuestos (Soportando y no IP Flow Mobility) por la 3GPP y la IETF en [15] y [16], valores normalizados de las métricas serán calculados utilizando la siguiente función:

Donde MPModeloTFTRID representa la métrica evaluada del modelo propuesto y MPModeloOriginal equivale a la misma métrica evaluada sobre los modelos presentados previamente. Estos cálculos normalizados permitirán determinar claramente los incrementos o reducción entre cada una de las métricas de desempeño de los modelos estudiados. La Figura 30 muestra el comportamiento del Ancho de Banda en el acceso WiFi ante el incremento del número de Mobiles Nodes interfiriendo y consumiendo recursos de éste. Se puede observar que el modelo propuesto (MTFTRID) implementado sobre ambos protocolos reduce en un 25% (DSMIPv6) y 15% (DSPMIPv6) el consumo del Ancho de Banda con respecto a los protocolos implementando sólo IP Flow Mobility y un 34% y 27% con el modelo original, en donde todo el tráfico es cursado por una sola interfaz. Esta reducción es lograda en gran parte por la reducción del tráfico de señalización generada por los mensajes de BU (Binding

Update) y BA (Binding Acknowledgment). Figura 30. Comparación Ancho de Banda Normalizado.

Figura 31. Comparación Tasa de Perdida de Paquetes Normalizado.

La Figura 31 presenta como la tasa de perdida de paquetes es reducida en un 30% (DSMIPv6) y 20% (DSPMIPv6) en relación a IFOM. Esta reducción también se puede prever dada la reducción en la latencia durante el Handover evidenciada en la Figura 28. Comparada con el Modelo Normal (Una Interfaz) se logra observar que la reducción es del 40% al 60% cuando se utiliza DSMIPv6 como protocolo para la movilidad IP y del 30% al 42% si es DSPMIPv6 el escogido. Los anteriores resultados permiten asegurar que el comportamiento del protocolo DSPMIPv6 en escenarios de alta movilidad intra-domain brinda un mejor desempeño que el DSMIPv6.

Figura 32. Comparación Costo Total de Señalización Normalizado.

Por medio de la Figura 32 se puede ver como por un lado el tráfico de señalización es reducido en un 40% (DSMIPv6) y 15% (DSPMIPv6) con respecto al modelo que solo implementa IFOM, lo cual es un resultado ya esperado por la reducción del tamaño de los paquetes de BU y la disminución de las actualizaciones constantes sobre el Binding Cache. No obstante, el tráfico sigue siendo mayor en un 30% (DSMIPv6) y 15% (DSPMIPv6) si lo comparamos con el modelo original que no soporta registración múltiple de CoA’s y políticas de QoS sobre cada flujo.

7. CONCLUSIONES Y TRABAJOS FUTUROS

7.1 CONCLUSIONES

● El EPS (Evolved Packet System) representa el nuevo marco para las redes de telecomunicaciones de próxima generación, el cual ofrece entre sus principales características un modelo de comunicación ALL-IP y conectividad sin interrupciones entre redes heterogéneas.

● Mediante este trabajo se han presentado resultados cualitativos y cuantitativos que evidencian que la implementación de IP Flow Mobility y Multihoming sobre los Mobile Nodes mejora en gran medida el desempeño de los protocolos de movilidad IP estudiados.

● Se determinó que la implementación de IP Flow Mobility y multihoming aumenta el tráfico de señalización cursado sobre la red, al incrementar el número mensajes de Binding Updates, dado que cada interfaz es tratada de manera independiente.

● Se identificó que los mecanismos de selección de rutas y aplicación de políticas de QoS eran implementados dos veces, por los Mobiles Nodes y los Sistemas de acceso. El primero utilizando filtros y reglas de enrutamiento junto con Traffic Flow Templates (TFT) para la selección de la interfaz por la cual transmitir y el segundo implementan mecanismos propios de la red de acceso junto con TFT’s para la selección del EPS Bearer o contextos PDP (Packet Data Protocol).

● La implementación del TFT Reference Mobility Option (TFTR) en remplazo del Flow ID Mobility Option como esquema de filtrado de paquetes en el EPS. permite la reducción de los mensajes de señalización (Binding Update) y su tamaño.

● Los resultados encontrados al utilizar el TFTR demuestran que muchas de las métricas de desempeño evaluadas como la conectividad y la latencia son reducidas significativamente, mejorando la experiencia del usuario final y ofreciendo conectividad sin interrupción a un nivel imperceptible para los usuarios.

● Las métricas evaluadas presentaron mejoras es sus valores desde un 10% hasta un 60% para ambos protocolos, siendo el Dual Stack Proxy Mobile IPv6 el protocolo que mostró un mejor desempeño ante los escenarios propuestos.

● La reducción del costo de señalización evidencia que la implementación del modelo TFTR disminuye la cantidad de mensajes de Binding Update generados. Sin embargo, al ser comparado con el Modelo Normal, sigue siendo mayor el tráfico cursado debido a que este último enfoca la movilidad sobre el Mobile Node y no sobre los flujos IP.

7.2 TRABAJOS FUTUROS

● Simulación de escenarios que permitan analizar la incidencia del Dual Stack en el desempeño de los protocolos de movilidad y IP Flow Mobility.

● Determinar y especificar los cambios necesarios en la plataforma EPS para

soportar la asignación de Bearer o contextos PDP por flujo y no por acceso, con el fin de poder asegurar políticas de QoS por flujo.

● Estudiar el efecto de la implementación de Interfaces Virtuales vs Interfaces Lógicas [34] y [35] sobre los protocolos de movilidad IP y IP Flow Mobility.

● Implementación de un prototipo para el estudio de la propuesta realizada utilizando Mobile IPv6 For Linux y las extensiones a Proxy Mobile IPv6, tal como se plantea en [54] y [67] o una herramienta como el OpenEPC [46].

8. BIBLIOGRAFÍA

3GPP TECHNICAL REPORT AND SPECIFICATIONS[1] 3GPP TS 22.278 V.10.1.; “Service requirements for the Evolved Packet System (EPS)”. Rel 10. Mar 2010. x[2] 3GPP TS 22.101 V.10.2.; “Service aspects Service principles Release 10”. Rel 10. Mar 2010. x[3] 3GPP TS 23.327 V.9.0.; “Mobility between 3GPP-Wireless Local Area Network (WLAN) interworking and 3GPP systems”. Rel 9. Dec 2009.[4] 3GPP TS 23.203 v.10.0.; "Policy and Charging Control Architecture.”Rel 10.Aug 2010.[5] 3GPP TS 32.240 v.9.1.0.; "Charging architecture and principles”. Rel 9. Aug 2010.[6] 3GPP TR 23.861 V1.3.0.; “Multi access PDN connectivity and IP flow mobility”. Rel 9. Sep 2009.[7] 3GPP TR 23.261 V1.0.0.; “IP Flow Mobility and seamless WLAN offload Stage 2”. Rel 10. Mar 2010.[8] 3GPP TS 23.402 v.10.0.; "Architecture enhancements for non-3GPP accesses”. Rel 10. Aug 2010.[9] 3GPP TS 23.060 v9.3.0.; "General Packet Radio Service (GPRS); Service Description; Stage 2 (Release 9)", Dec. 2009.[10] 3GPP TS 24.312 v.9.1.0.;"Access Network Discovery and Selection Function (ANDSF)”. Rel 9. Mar 2010.[11] 3GPP TS 24.304 v.9.1.0.; "Mobility management based on Mobile IPv4;Stage 3”. Rel 9. Mar 2010.[12] 3GPP TS 24.303 v.9.2.0.;"Mobility management based on Dual-Stack Mobile IPv6 Stage 3”. Rel 9. Aug 2010.[13] 3GPP TR 23.829 V1.0.1.; “Local IP Access and Selected IP Traffic Offload”. Rel 10. Mar 2010. IETF RFCs[14] IETF Network WG; "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, Aug. 2003.[15] IETF Network WG; "Mobility Support in IPv6", RFC 3775, Jun 2004.[16] IETF Network WG; "Proxy Mobile IPv6", RFC 5213, Aug. 2008.[17] IETF Network WG; "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, Jun 2009.[18] IETF Network WG; "Authentication Protocol for Mobile IPv6", RFC 4285, Jan. 2006.[19] IETF Network WG; "Problem Statement: Dual stack Mobility", RFC 4977, Aug. 2007.[20] IETF Network WG; "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, Jun. 2008.[21] IETF Network WG; "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May. 2010.[22] IETF Network WG; "Multiple Care-of Addresses Registration", RFC 5648, Oct. 2009.[23] IETF Network WG; "Goals for Network-Based Localized Mobility Management (NETLMM)", RFC 4831, Apr. 2007.[24] IETF Network WG; "Problem Statement for Network-Based Localized Mobility Management (NETLMM)", RFC 4830, Ape. 2007. IETF INTERNET DRAFTS[25] IETF Internet Engineering Task Force; "Current Practices for Multiple Interface Hosts", Internet Draft(work in progress),draft-ietf-mif-current-practices-03, Aug. 2010 (Expires:

Feb 2011).[26] IETF Network WG; "Multiple Interfaces and Provisioning Domains Problem Statement", Internet Draft (work in progress),draft-ietf-mif-problem-statement-09.txt, Oct. 2010 (Expires: Apr 2011).[27] IETF Monami6 WG; “Motivations and Scenarios for Using Multiple Interfaces and Global Addresses”, Internet Draft, draft-ietf-monami6-multihoming-motivation-scenario-03.txt, May 2008 (Expires: Nov 2008).[28] IETF Network WG; "IP Mobility and Multi-homing Interactions and Architectural Cosiderations",Internet Draft,draft-vidya-ip-mobility-multihoming-interactions-01, Jul. 2007 (Expires: Jan 2008).[29] IETF Network WG; ”PMIPv6 and Network Mobility Problem Statement”.Internet Draft, draft-bernardos-netext-pmipv6-nemo-ps-01. Oct. 2009 (Expires: Apr 2010).[30] IETF MEXT WG; "Flow Bindings in Mobile IPv6 and Nemo Basic Support", Internet Draft (work in progress), draft-ietf-mext-flowbinding-10.txt, Sep. 2010 (Expires: Mar 2010).[31] IETF Network WG; "Traffic Selectors for Flow Bindings ", Internet Draft (work in progress),draft-ietf-mext-binary-ts-05.txt , Oct. 2010 (Expires: Apr 2011).[32] IETF Network WG; "PMIPv6 Multihoming Support for Flow Mobility", Internet Draft, draft-ietf-mext-flowbinding-10.txt, Feb. 2010 (Expires: Aug 2010).[33] IETF Network WG; "Multihoming Extensions for Proxy Mobile IPv6", Internet Draft, draft-bernardos-mif-pmip-02, Mar. 2010 (Expires: Sep 2010).[34] IETF Internet Draft;”A Comparasion of IP Mobility-Related Protocols", Internet Draft, draft-thaler-mobility-comparison-02.txt, Oct. 2006 (Expires: Apr 2007).[35] IETF NETEXT WG; "Logical Interface Support for multi-mode IP Hosts", Internet Draft (work in progress),draft-ietf-netext-logical-interface-support-00.txt, Aug. 2010 (Expires:Feb 2011).[36] IETF Network WG; "Virtual interface for multiple interfaces in a host", Internet Draft (work in progress),Virtual interface for multiple interfaces in a host, Jul 2010 (Expires: Jan 2011). LIBROS, PÁGINAS WEBS, DOCUMENTOS Y ARTÍCULOS[37] Lescuyer P.; Lucidarme T.;“Evolved Packet System EPS(the LTE and SAE Evolution of 3GUMTS”; 2008. Firt Edition.Jhon Wiley & Sons Ltd. Page(s):353. x[38] Chan M.; "Seis tendencias clave guían la evolución a LTE "; Disponible en http://www2.alcatel-lucent.com/enrich/es/v3i2/6-key-trends-driving-the-evolution-to-lte/.[39] Lescuyer P. ; Lucidarme T. ;"Evolved packet system EPS the LTE and SAE evolution of 3G UMTS"; Ed jhon wiley & sons. 2008, Page(s):20.[40] Fraunhofer Fokus.; “OpenEPC Product Info- Understanding NGMN and Related Technologies- LTE, EPC and IMS”; Tutorial 4. 2009. Page(s):171.[41] Alcatel Lucent Documents.; "Las Redes Móviles de Última Generación- LTE : Long Term Evolution"; 2009. Page(s):27[42] Myung, H.; "Technical Overview of 3GPP LTE. 3GPP LTE/SAE"; 2008. Page(s):1-53.[43] Yom, P.; “LTE Update”; IEEE Comunication Magazine. Feb 2010. Page(s):78.[44] 3GPP Documents.; "UTRA-UTRAN Long Term Evolution (LTE) and 3GPP System Architecture Evolution (SAE)"; 2008. Page(s) 1-8[45] Ahmed T.; Antoine S.; “Multi Access Data Network Connectivity and IP Flow Mobility in Evolved Packet System (EPS)”; Wireless Communications and Networking Conference (WCNC), 2010 IEEE. Page(s): 1-6.[46] Fraunhofer Fokus.; "Web Page Framework y Software OpenEPC". Disponible en: http://www.openepc.net/en/openepc/index.html.[47] Olsson, M.; Suitana S.; “SAE and the Evolved Packet Core: Driving the Mobile Broadband Revolution”; 2009. First Edition. Elsevier Ltd. Page(s):444 [48] Xiaoli G.; Yuhong L.;Weiqi H.; ”An Automic Flow Bases Path Selection Method For Multi-Home Nodes.” IC-BNMT ’09 .2009. Page(s):85-89

[49] Esaki H.; ”Multi-Homing and Multi-Path Architecture Using Mobile IP and NEMO Framework.” 2004. Page(s):6. [50] Åhlund C. , Brännström, R. ;“Multihoming approach to Mobile IP”; CiteSeerx 2009. Page(s):4.[51] Jaeho J. ; Jinsung C. ;”A Cross-layer Vertical Handover between Mobile WiMAX and 3G Networks”; IWCMC ‘08. 2008 Page(s):644-649.[52] Marques H.;Ribeiro J.;“Simulation of 802.21 Handovers Using ns-2”; Hindawi Journal of Computer System, Network and Communications . 2010. Page(s):11. [53] Diab A.; Mitschele-Thiel A.; “Comparative Analysis of Proxy MIPv6 and Fast MIPv6”; MObiwac ‘09. 2009. Page(s):9.[54] Seung-Il H.; Youn-Hee H.; “Empirical Performance Evaluation of IETF Mobile IPv6 and Proxy Mobile IPv6”; Mibility ‘08. 2008. Page(s):7.[55] Lei J.; Xiaoming F.; “Evaluating the Benefits of Introducing PMIPv6 for Localized Mobility Management”;IWCMC ‘08. 2008 Page(s):74 - 80.[56] Galli, S.; McAuley, A.; Morera, R.; “An analytical approach to the performance evaluation of mobility protocols: the overall mobility cost case”; PIMRC ‘04. 2004 , Page(s): 3019 - 3024 Vol.4[57] Galli, S.; Morera, R.; McAuley, A.; “An analytical approach to the performance evaluation of mobility protocols: the handoff delay case”;VTC ‘04. 2004 , Page(s): 2389 - 2393 Vol.4[58] Åhlund C. , Brännström, R. ; ”Multimedia Flow Mobility in Heterogeneus Networks using Multihomed Mobile IPv6”; MoMM ‘06. 2006. Page(s):10. [59] Sun P.; Sung S.;“Performance Evaluation and Analysis of Protocols for IP MobilitySupport: A Quantitative Study”;ss, pp.0219, 35th Annual Simulation Symposium, 2002. Page(s):8.[60] Bo H.; Shanzhi C.; Xiaoyan J.; “A Performance Evaluation of IP Mobility Support Protocols”.MMIT 2010. Page(s):17-20.[61] Eardley P.; Mihailovic A.; Suihko T.; “A Framework for the Evaluation of IP Mobility Protocols”;PIMRC 2010. Page(s): 451-457 vol.1.[62] Makaya C.; Pierre S.; “An Analytical Framework for Performance Evaluation of IPv6-Based Mobility Management Protocols”; IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, 2008. Page(s): 972-983 Vol. 7, No. 3 .[63] Jianfeng G.; HuaChun Z.; “Implementation and Analysis of Network-based MobilityManagement Protocol in WLAN Environments”; Mobility '08. Page(s):9.[64] Khanh-Toan Tran Gondi, V.K. Agoulmine, N. “Analysis of Client-based and Network-based Mobility Protocols”; ICC ‘10. 2010. Page(s): 1-5.[65] Johnson T.; Prado R.;Zagari E.;Badan T.;“Considerations on Performance Evaluation of Micro-Mobility Architectures for IP Networks”; PIMRC ‘08. 2008. Page(s):6.[66] Huu-Nghia N.;Bonnet C. “Scalable Proxy Mobile IPv6 For Heterogeneous Wireless Networks”; Mobility ‘08. 2008. Page(s):7.[67] Rodríguez M.; Galán F.;”A 3GPP System Architecture Evolution Virtualized Experimentation Infrastructure for Mobility Prototyping”;TridentCom '08 .2008.Pages(s):10.[68] Castelluccia C. ;“HMIPv6: A Hierarchical Mobile IPv6 Proposal”; ACM Mobile Computing and Communications Review, Jan. 2000. Page(s):48–59 Vol. 4.[69] Dimopoulou L.; Leoleis G.; “Fast Handover Support in a WLAN Environment: Challenges and Perspectives”; IEEE Network, May-June 2005. Pages(s):14–20. Vol. 3, No 19.[70] The network simulator - ns-2: Disponible en: http://www.isi.edu/nsnam/ns (Jun 2009).[71] Fall K.; Varadhan K.; “The ns Manual”; Disponible en: http://www.isi.edu/nsnam/ns/doc/index.html”. (May 2010).[72] Greis M.; “Tutorial for the Network Simulator- cap X. Creating Wired-cum-Wireless and MobileIP Simulations in ns”; Disponible en: http://www.isi.edu/nsnam/ns/tutorial/

index.html[73] Motorola Labs Paris; “Mobiwan: ns-2 extensions to study mobility in Wide-Area IPv6 Networks,” Disponible en : http://www.inrialpes.fr/planete/mobiwan.[74] Wang Q.; “NS2-MIUN- A Multi-homing Extension of Wireless Node Implementation in NS-2”. Disponible en: in www.miun.se/personal/qinghua.wang/resources.htm. 2009.[75] HyonYoung C.; “Proxy Mobile IPv6 for Ns-2”; Disponible en: http://commani.net/pmip6ns/