Tecniche per il mobile data offloading

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Protocolli per reti mobili
Tecniche per il mobile data offloading
Anno Accademico 2013/2014
Candidato:
Federica Aprea
matr. N46/000952
Alla mia famiglia.
Indice
Indice .................................................................................................................................................. III
Introduzione ......................................................................................................................................... 4
Capitolo 1: Mobile data offloading ...................................................................................................... 5
1.1 Mobile data offloading tramite Wi-Fi ........................................................................................ 5
1.2 Mobile data offloading tramite femtocell .................................................................................. 7
1.3 Mobile data offloading tramite IP flow mobility ....................................................................... 8
1.4 Valutare gli effetti ...................................................................................................................... 9
Capitolo 2: Tecniche per il mobile data offloading ........................................................................... 10
2.1 IP flow mobility ....................................................................................................................... 10
2.1.1 Soluzione client-based ...................................................................................................... 11
2.1.2 Soluzione network-based .................................................................................................. 14
2.1.3 IP flow mobility in architetture 3G/4G ............................................................................. 17
2.2 Local IP access ......................................................................................................................... 21
2.3 Selected IP traffic offload ........................................................................................................ 24
2.3.1 Selected IP traffic offload MACRO.................................................................................. 25
Conclusioni ........................................................................................................................................ 28
Bibliografia ........................................................................................................................................ 29
Introduzione
Negli ultimi anni, il traffico dati sulle reti cellulari ha visto una crescita esponenziale, in
particolar modo a seguito dell’enorme diffusione di smartphones, tablets e laptops. Questo
incremento di traffico sulle reti cellulari ha spinto gli operatori di rete verso la ricerca di
una soluzione in grado di ottimizzare le performances dei servizi offerti. L’obiettivo è
quello di mantenere una certa qualità di servizio agli utenti e ridurre l’impatto sulla rete
mobile
di
servizi
che
richiedono
un
gran
numero
di
risorse.
Mobile data offloading consiste nell’utilizzare tecnologie di rete complementari e tecniche
innovative per trasferire dati originariamente destinati alle reti mobili/cellulari, in modo da
alleviare la congestione e permettere un uso migliore delle risorse di rete disponibili. Ci si
aspetta che il mobile data offloading diventi un segmento chiave nel prossimo futuro,
considerando la continua e rapida crescita del traffico dati sulle reti mobili.
Lo scopo di questo elaborato è quello di presentare alcune delle tecniche chiave
nell’ambito del mobile data offloading; in particolar modo, dopo aver fornito una
panoramica generale delle possibili soluzioni, verranno presentati nel dettaglio IP Flow
Mobility, Selected IP Traffic Offload e Local IP Access.
4
Capitolo 1: Mobile data offloading
Con il continuo incremento del consumo dati, le reti cellulari si trovano ad operare al
limite delle loro capacità; per tale motivo, gli operatori sono alla continua ricerca di idee e
strategie per evitare il sovraccarico delle proprie reti. Tra i metodi proposti, il mobile data
offloading si presenta come una valida soluzione. Esso, basandosi su specifiche regole e
condizioni, re-direziona in maniera intelligente una parte del traffico utente nella rete, con
lo scopo di evitare un possibile sovraccarico e migliorare l’esperienza complessiva
dell’utente. Ad oggi, molti operatori di reti mobili hanno volto la propria attenzione verso
strategie di Mobile data offloading. Nei paragrafi successivi, sono mostrate tre delle
soluzioni di maggiore diffusione.
1.1 Mobile data offloading tramite Wi-Fi
Il Wi-Fi, confrontato con le convenzionali tecnologie di comunicazione mobile (UMTS,
HSPA, LTE), fornisce elevati data-rates ma una copertura ed una mobilità limitate.
Attualmente, ha subito una notevole evoluzione grazie alla diffusione delle reti Wi-Fi
all’aperto. Questa tecnologia si presenta come un valido appoggio alle strategie di data
offloading, dato che le funzionalità Wi-Fi sono integrate in tutti gli smartphone. Inoltre,
nelle aree che presentano sovraccarico dal punto di vista dei servizi cellulare, un crescente
numero di utenti ha scelto di utilizzare la rete Wi-Fi per accedere ai servizi Internet. In
aggiunta, anche i service providers vedono nell’utilizzo del Wi-Fi una possibilità per
espandere le proprie reti con costi meno elevati; questa tecnologia consente di spostare il
5
traffico dati dalle costose bande con licenza, alle bande prive di licenza e gratuite.
Vi sono tre approcci principali che consentono agli operatori di rete mobile di scaricare
traffico dati nelle reti Wi-Fi: network bypass o unmanaged data offloading, managed data
offloading e integrated data offloading. Il primo consiste nello spostare il traffico dati
verso la rete Wi-Fi ogni volta che gli utenti si trovano nel suo raggio di copertura, ed il
tutto in maniera totalmente trasparente. Ovviamente, il vantaggio principale è quello di
avere una soluzione che risulta essere di facile attuazione; l’operatore può pensare di
realizzare questa strategia di offload dei dati semplicemente installando un applicazione
sul telefono cellulare, che permetta lo spostamento sull’interfaccia Wi-Fi ogni volta che ne
è individuata una copertura. Purtroppo, questa strategia presenta comunque degli
svantaggi; in particolar modo, questi riguardano l’operatore che perde visibilità e, quindi,
il controllo dei suoi abbonati ogni volta che questi si trovano in una rete Wi-Fi. Inoltre,
perde la possibilità di inviare qualsiasi tipo di contenuto sottoscritto ai propri utenti.
L’approccio managed data offloading è adottato dagli operatori che non vogliono perdere
il controllo dei propri abbonati ed è realizzato, semplicemente, sfruttando un particolare
gateway. Nonostante questa soluzione permetta di mantenere visibilità degli abbonati, gli
operatori non sono ancora in grado di poter inviare loro contenuti sottoscritti.
L’ultimo approccio prevede il pieno controllo dell’operatore sui propri utenti; ciò è
realizzato attraverso una completa integrazione tra le reti cellulare e Wi-Fi, costituendo un
ponte sul quale possa essere stabilito un flusso dati. Esistono due tipi di architetture che
consentono di realizzare questo accoppiamento. Possiamo avere un accoppiamento lasco
in cui le reti sono indipendenti e non vi è alcun bisogno di cooperazione tra le due; la rete
Wi-Fi è connessa indirettamente a quella cellulare attraverso una rete IP esterna, come
Internet. In alternativa vi è la possibilità di avere un accoppiamento forte, dove le due reti
condividono un core comune e una buona parte delle funzioni di rete sono gestite in
maniera centralizzata.
Il Wi-Fi opera nella banda priva di licenza, quindi gli operatori hanno a disposizione un
ampiezza di spettro maggiore; inoltre, è l’unica tecnologia in grado di raggiungere rate
elevati,
come
600
6
Mb/s.
Un numero sempre crescente di operatori ha preso in considerazione la possibilità del WiFi offloading per alleviare la congestione della rete. L’accesso Wi-Fi è gratuito in molti
luoghi pubblici e gran parte delle case e degli uffici possiedono, al giorno d’oggi, una rete
Wi-Fi. Una possibile opzione è quella di spingere i propri abbonati verso l’uso di questa
tecnologia, cosa che non presenta alcun tipo di problema considerando il gran numero di
utenti che già la utilizza per usufruire di un servizio migliore; questo approccio alla
realizzazione dell’offloading è il più semplice da mettere in atto, ma il meno efficiente. Un
approccio efficace consiste nell’espansione, da parte dell’operatore, della propria rete
d’accesso con hotspots di propria gestione; oppure, integrare la copertura delle macrocelle
3G con picocelle Wi-Fi nelle aree ad alta densità di utenti. Quest’ultimo approccio è
quello che sta acquisendo maggiore popolarità.
Tuttavia, per l’utente non è conveniente avere contemporaneamente attive sia l’interfaccia
Wi-Fi che quella cellulare perché causa di un forte consumo di batteria, specialmente
quando l’interfaccia Wi-Fi si trova in modalità idle. Inoltre, la rete non può forzare un
dispositivo a spostarsi sull’interfaccia Wi-Fi; questo crea un problema per tutti quegli
operatori che scelgono di implementare una soluzione di Wi-Fi offloading. Non da meno è
il problema che deriva dalle interferenze generate sia dalle altre interfacce Wi-Fi, sia dalle
interfacce non-Wi-Fi; per tale motivo, per creare un’effettiva soluzione di offloading
devono essere utilizzate differenti tecnologie, quali beamforming, space-division multiple
access e dynamic channel selection. Quindi, ad oggi, vi sono ancora alcune questioni da
dover risolvere per poter immaginare una diffusione su larga scala di questa tecnica.
1.2 Mobile data offloading tramite femtocell
Un alternativa al Wi-Fi è la femtocell; anche attraverso quest’ultima è possibile realizzare
una strategia di mobile data offloading. La femtocell è una piccola base station cellulare,
generalmente utilizzata in ambienti chiusi. Essa, permette di collegarsi alla rete di un
operatore mobile via broadband e, allo stesso tempo, consente al service provider di
estendere la copertura della rete ad ambienti interni, specialmente in quelle aree dove
altrimenti la copertura sarebbe limitata; le femtocell consentono all’operatore di migliorare
7
la capacità e la copertura della propria rete.
Utilizzare le femtocells per consentire il data offloading è una buona strategia. In primo
luogo, è stato dimostrato che buona parte dell’uso dei dati mobili si ha in ufficio o in casa,
ovvero nei luoghi in cui le femtocells sono generalmente utilizzate, e quindi l’operatore ha
la possibilità di gestire il traffico, che presenta un carico pesante, attraverso quest’ultime;
inoltre, le femtocell possono essere implementate facilmente.
Quando un abbonato entra nella copertura della femtocell, l’user equipment (UE)
automaticamente vi si associa e il traffico che prima fluiva tra la macrocell e l’UE, adesso,
scorre
tra
la
femtocell
e
la
connessione
broadband
dell’abbonato.
L’utilizzo delle femtocells consente di catturare tutte le tipologie di traffico, voce o dati,
sia esso generato da un laptop che da uno smartphone; inoltre, non incide sul consumo
della batteria del dato device. Tuttavia, tale tecnologia richiede un’attenta pianificazione
perché opera nelle bande con licenza e con uno spettro limitato.
La sfida maggiore nell’utilizzo delle femtocells è la gestione delle interferenze.
L’implementazione di questa tecnologia introduce una rete a due livelli, che consente,
quindi, di distinguere le interferenze in co-tier o cross-tier. Nel primo caso, una femtocell
causa interferenza ad un'altra vicina. Nel secondo caso, la femtocell causa interferenza al
downlink di un utente di una macrocella vicina; allo stesso modo, un utente può causare
interferenza sull’uplink di una vicina femtocell.
Quindi, come per il Wi-Fi, anche per le femtocells vi sono dei problemi da risolvere per
poter
usufruire
a
pieno
della
soluzione
del
mobile
offloading.
Esistono due principali tecniche basate sull’utilizzo di femtocell: Selected IP traffic
offload e Local IP access.
1.3 Mobile data offloading tramite IP flow mobility
IP flow mobility è una recente tecnologia che consente all’operatore di trasferire un
singolo flusso dati ad un differente accesso radio, senza creare alcun problema alle
comunicazioni in corso. Consideriamo un utente connesso ad una cellular base station alle
8
prese con una chiamata vocale e il download di un file, che entra nel raggio di copertura di
una rete Wi-Fi. Il terminale, una volta rilevato l’accesso Wi-Fi, decide di spostare il
download del file sulla rete Wi-Fi. Quando l’utente si allontana da questa zona di
copertura, il download è nuovamente trasferito alla rete cellulare, senza alcuna perdita di
continuità.
IP flow mobility fornisce all’operatore una gestione del traffico migliore, che consente
quindi di alleviare la congestione sulla rete; allo stesso tempo, l’utente può usufruire di
una
connessione
ad
elevata
banda
e
un’esperienza
migliore.
Tale tecnica verrà approfondita nel capitolo successivo.
1.4 Valutare gli effetti
Un quesito importante nell’ambito del mobile data offloading è come valutarne gli effetti.
Per dare una risposta, possiamo considerare due punti di vista differenti : il punto di vista
della rete (e quindi dell’operatore) e quello dell’utente.
Dal punto di vista della rete, l’offload degli utenti dalla rete cellulare ha lo scopo di
evitarne la congestione e migliorare le performance sia del servizio voce che di quello dati.
L’effetto principale dovrebbe essere quello della riduzione del traffico che può essere
valutata tramite differenti key performance indicators (KPIs), ad esempio comparando
quello che è il carico sulla rete un’ora prima e dopo l’offloading. Inoltre, possono essere
utilizzate metriche come l’offloading efficiency. Dal punto di vista dell’utente, l’offloading
dovrebbe fornire un esperienza migliore; anche in questo caso possono essere utilizzati
differenti KPIs che descrivono la qualità dell’esperienza (QoE) dell’utente.
9
Capitolo 2: Tecniche per il mobile data offloading
2.1 IP flow mobility
IP Flow Mobility è una delle tecniche di offloading standardizzata dall’IETF. In
particolare l’Internet Engineering Task Force si focalizza su due possibili approcci, uno
client-based e l’altro network-based. Il primo estende quelle che sono le esistenti soluzioni
al problema della mobilità a livello IP client-based, in cui il terminale utente risulta essere
completamente coinvolto nel processo di mobilità ; il secondo, invece, è basato sulle
soluzioni network-based per la mobilità a livello IP, caso in cui l’utente non risulta
coinvolto.
IP flow mobility è stata adottata dal Third Generation Partnership Project per il 3G
offload.
Consideriamo un utente equipaggiato con un telefono mobile dual-mode, che integra
quindi 3G/4G e Wi-Fi, e che sia in grado di collegarsi alle reti disponibili simultaneamente
o in maniera sequenziale ; l’utente connesso alla 3GPP base station può possedere più di
un flusso dati simultaneamente, come una chiamata vocale e il download di un file.
Quando l’utente si sposta e il terminale rileva la possibilità di accedere ad una WLAN, la
rete o il terminale stesso può valutare la possibilità di effettuare un’operazione di offload,
ad esempio spostando il download sulla rete d’accesso WLAN, in modo da alleviare la
congestione nella rete 3GPP e fornire all’utente un download più veloce.
10
Quindi, lo scopo di questa tecnica è quello di fornire ad un operatore di rete la possibilità
di spostare un flusso IP da una rete d’accesso ad un'altra differente, senza ovviamente
perdere le altre connessioni attive.
L’operatore può, quindi, avere un maggiore controllo della rete, potendo gestire al meglio
utenti che presentano un carico molto elevato. Inoltre, ha la possibilità di attuare adeguate
politiche di gestione dei servizi che variano al variare della tipologia di traffico, delle
tariffe e dell’utente. Quest’ultimo, a sua volta, può fruire delle connessioni ad elevata
banda in prossimità degli hotspots WLAN. In conclusione, l’obiettivo è quello di fornire
all’utente una certa QoE (Quality of Experience). Ovviamente, non è conveniente attuare
la tecnica del data offloading su una qualsiasi tipologia di traffico : re-direzionare il
traffico introduce generalmente del ritardo dovuto alle fasi di elaborazione ed inoltro. Per
tale motivo, IP flow mobility si propone come soluzione applicabile solo al traffico dati
non sensibile ai ritardi.
2.1.1 Soluzione client-based
La gestione della mobilità client-based coinvolge totalmente il terminale utente, basandosi
su di una soluzione che pone al centro l’host. Introduce un mobility agent nella core
network ed un mobility client nell’host. Questa soluzione fa uso di uno stack specializzato
che è in grado di individuare, segnalare e reagire quando si verifica un cambiamento del
punto di accesso alla rete.
L’IETF ha standardizzato Dual Stack for Mobile IPv6 (DSMIPv6) per fornire supporto
alla mobilità client-based. Dual Stack for Mobile IPv6 estende Mobile IPv6 (MIPv6) in
modo da poter supportare scenari dual-stack IPv4/IPv6. MIPv6 permette ad un nodo
mobile (Mobile node - MN), che si sposta dalla propria Home Network (HN) verso un'altra
rete, di essere sempre raggiungibile. Per far sì che questo accada, è introdotto una specifica
entità all’interno della HN chiamata Home Agent (HA) ; il nodo mobile è identificato da
un indirizzo IP permanente, legato alla propria HN, chiamato Home Address (HoA) e da
un indirizzo IP temporaneo, assegnatogli quando si allontana dalla propria rete e quindi
legato alla nuova rete visitata, chiamato Care-of Address (CoA). Ogni qual volta il nodo
11
mobile si sposta, l’Home Agent deve essere informato ; infatti il compito dell’HA è quello
di intercettare i pacchetti diretti al nodo mobile, quando questo si trova in una rete
differente dalla HN, e indirizzarli verso la sua nuova posizione. A tale scopo, è costruito
un tunnel IP bidirezionale che collega il nodo mobile all’HA. In alternativa, vi è la
cosiddetta Routing Optimization (RO) che consente al nodo mobile di scambiare dati
direttamente con i propri peers, chiamati Correspondent Nodes (CNs) senza che vi sia
l’HA ad assumere il ruolo di intermediario ; in questo caso, il MN ha la possibilità di
informare direttamente i suoi CNs riguardo la sua nuova posizione.
Le funzionalità introdotte da DSMIPv6, in generale, danno la possibilità al nodo mobile di
spostarsi tra reti d’accesso IPv6 e IPv4 ; prevede, quindi, la registrazione di indirizzi IPv4
e la possibilità di trasferire all’interno del canale costituito dall’HA sia pacchetti IPv4 che
IPv6.
I protocolli di base MIPv6 forniscono gli strumenti per collegare un HoA ad un singolo
CoA, quindi questa soluzione fornisce un supporto veramente molto limitato al
multihoming ; infatti, l’unico scenario in cui un nodo mobile può possedere più di un CoA
contemporaneamente è il caso in cui il MN utilizza più di un HoA. Quindi, potendo
associare ciascun indirizzo permanente ad un solo indirizzo temporaneo, non è prevista la
possibilità di instradare differenti flussi di traffico a diversi Care-of Address e, allo stesso
modo, non è possibile raggiungere il nodo mobile attraverso il suo Home Address facendo
uso di diverse interfacce fisiche.
IP flow mobility richiede la possibilità di registrare differenti CoA con lo stesso HoA ; per
tale motivo, MIPv6 prevede l’estensione ‘Multiple Care-of Address Registration’,
standardizzata dall’IETF in RFC 5648, che consente di ricevere traffico destinato allo
stesso HoA attraverso differenti CoA.
L’HA possiede una binding cache all’interno della quale conserva la corrispondenza che
vi è tra l’HoA e il CoA del relativo nodo mobile ; l’estensione menzionata in precedenza
fa sì che all’interno di questa cache si creino le relative entry che identificano le
associazioni tra l’HA e i vari CoAs. Inoltre il messaggio Binding Update (BU) è
modificato opportunamente in modo da contenere, oltre ad un CoA, un ID che identifichi
12
univocamente la binding entry, chiamato binding identification (BID) number. La RO,
come specificato in precedenza, consente al nodo mobile di comunicare direttamente con i
propri CNs, quindi in questo caso la registrazione dei differenti CoAs relativi al singolo
HoA avviene presso i CNs.
Prendiamo ad esempio il caso di un nodo mobile connesso contemporaneamente alle reti
d’accesso WLAN e 3G ; in questo caso, il nodo mobile, grazie all’estensione introdotta da
questo protocollo, potrà registrare presso l’HA i due CoA relativi alle due reti.
Un ulteriore estensione a MIPv6 è ‘Flow Bindings in MIPv6 and Network Mobility
(NEMO) Basic Support’, standardizzata in RFC 6088. Questa aggiunge, alla possibilità di
collegare molteplici CoA ad un singolo HoA, la capacità di gestire simultaneamente tali
associazioni. Consente di collegare uno o più flussi dati ad un determinato CoA ; a tal
proposito, sono definite una serie di opzioni per permettere al MN di associare ad un CoA
un particolare flusso IP, cui è anche assegnato un identificativo (Flow ID - FID). Queste
associazioni sono contenute all’interno di una flow bindings cache, mantenuta dall’HA ; in
particolare, vi sono specificati il BID, il FID, un traffic selector utilizzato per assegnare
pacchetti ad un determinato flusso e una FID priority (FID-pri) ; una bassa FID-pri indica
un’alta priorità. Questa cache è utilizzata per determinare l’entry cui inoltrare un pacchetto
dati. L’HA (o il correspondent) all’arrivo di un pacchetto consulterà la binding cache per
individuare il CoA cui i pacchetti di uno specifico flusso devono essere inviati. Inoltre, il
MN deve essere in grado di instradare pacchetti in uscita attraverso differenti CoA.
Ultima estensione per poter abilitare flow mobility è la definizione dei cosiddetti traffic
selector, standardizzati in RFC 6089. Il traffic selector deve essere utilizzato
congiuntamente all’estensione flow binding, descritta in precedenza, così che i vari flussi
IP possano essere identificati sulla base di differenti criteri quali : source address,
destination address, il valore dell’IPsec security parameter index (SPI), porto sorgente,
porto destinazione, classe di traffico, o tipo del next header.
L’uso delle estensioni IP flow mobility permette, per esempio, di definire quale percorso
dati debba essere seguito dal traffico ricevuto/inviato dal/al Nodo mobile.
13
In aggiunta a queste estensioni, deve essere fornito ulteriore supporto per poter
implementare IP flow mobility in una rete gestita da un operatore. Access Network
Discovery and Selection Function (ANDSF) definita da 3GPP o Policy and Charging
Control (PCC) possono essere utilizzati e/o estesi per questo scopo.
FIGURA 1- DSMIPv6 & PMIPv6
2.1.2 Soluzione network-based
Nella modalità network-based, la mobilità è gestita in maniera del tutto trasparente al
terminale utente, è gestita dalla rete stessa. Quindi, ogni volta che il terminale si sposta
cambiando il proprio punto di accesso alla rete, non dovrà preoccuparsi di effettuare alcun
tipo di segnalazione. L’IETF ha standardizzato il protocollo ‘Proxy MIPv6’ per fornire
supporto alla mobilità network-based.
PMIPv6 è un protocollo di gestione della mobilità network-based. Quindi, i nodi mobili
non sono coinvolti nella gestione della mobilità; in particolare, le operazioni di movement
detection e di signaling sono di competenza del Mobile Access Gateway (MAG), una
nuova entità funzionale introdotta nella rete e che generalmente risiede sul router utilizzato
dal nodo mobile per l’accesso. Compito del MAG è quello di individuare un eventuale
14
spostamento del nodo mobile, attraverso l’utilizzo di operazioni standard, come router
discovery e neighbor discovery. Una volta riconosciuto lo spostamento ed individuata la
sua nuova posizione, il MAG coordina l’aggiornamento del routing state. L’area in cui è
fornito il supporto alla mobilità prende il nome di Localized Mobility Domain (LMD) e
all’interno di questa si possono trovare più di un MAG. In questo dominio, una nuova
entità chiamata Local Mobility Anchor (LMA) assume il ruolo di HA ; il suo compito è
quello di memorizzare gli indirizzi IP della Home Network relativi ai nodi mobili che si
spostano all’interno dell’LMD. Il MN è ignaro del proprio spostamento, in quanto tra il
LMA ed i MAG sono costituiti tunnel bidirezionali, permettendo al nodo mobile di
mantenere l’IP originale anche se la sua posizione all’interno dell’LMD è cambiata.
Quindi, L’LMD si assume l’onere di incanalare i pacchetti, diretti al dato nodo mobile,
verso il MAG appropriato entro il dominio.
Il protocollo PMIPv6 fornisce supporto al multihoming : il MN ha la possibilità di
collegarsi alla rete utilizzando molteplici interfacce. Il LMA può assegnare a ciascuna
interfaccia uno o più home network prefixes (HNPs) e per ognuno di questi collegamenti
può creare una differente mobility session.
PMIPv6 prevede che il LMA possa spostare l’intero set di HNPs associati ad una certa
interfaccia ad un'altra, ma non consente di trasferirne un numero arbitrario e, tantomeno,
un singolo flusso IP. Quindi, per poter fornire un supporto completo ad IP flow mobility,
PMIPv6 deve essere esteso. Una serie di estensioni sono state standardizzate dall’ IETF
NETEXT Working Group. Una prima estensione consente, proprio, di spostare flussi di
dati selezionati da una tecnologia d’accesso ad un’altra.
Flow mobility consente di stabilire connessioni simultanee nello stesso dominio PMIPv6
attraverso differenti interfacce. Utilizzare contemporaneamente molteplici collegamenti
alla rete incrementa la complessità della soluzione. In primo luogo, per poter supportare
l’utilizzo di flow mobility, il MN deve essere in grado di inviare e ricevere traffico a/da
una qualsiasi delle sue interfaccia, cui vi è associato un particolare prefisso. L’IETF
propone due meccanismi con lo scopo di fornire questa funzionalità : weak host model e il
logical interface (LIF). In un nodo mobile che implementa weak host model, lo stack IP
15
accetta ciascun pacchetto, indifferentemente dall’interfaccia di rete sulla quale è stato
ricevuto. Invece, LIF è un entità software che presenta una singola interfaccia verso lo
stack IP, nascondendo le reali implementazioni fisiche dell’interfaccia. Quindi, lo stack IP
collega le proprie sessioni a questa logical interface restando all’oscuro circa la reale
interfaccia fisica che sta inviando o ricevendo il pacchetto dati. In questo modo, lo stack
IP non è coinvolto nella gestione della mobilità ed è proprio questo l’obiettivo che
PMIPv6 si pone di raggiungere. Per tale motivo l’IETF ha scelto di focalizzarsi sul
concetto di LIF.
La logical interface è un’entità software che consente al nodo mobile di configurarsi come
un’unica interfaccia a livello IP e superiori. Attraverso questa interfaccia si ha la
possibilità
di
stabilire
una
qualsiasi
connessione
remota.
La
LIF
nasconde
l’implementazione di diverse funzionalità, quali l’intertecnology handover, multihoming o
flow mobility, mantenendo per i livelli superiori sempre lo stesso indirizzo IP (o set di
indirizzi IP). Per poter implementare la LIF sono richiesti alcuni cambiamenti al lato
client, ma questi andranno ad intaccare un unico componente che già risiede nei terminali
mobili ; infatti, la LIF è comunemente implementata come parte del connection manager,
che è responsabile della gestione e della configurazione automatica delle diverse interfacce
di rete. In conclusione, l’implementazione della logical interface non ha alcun impatto
sullo stack IP che resta nella sua configurazione standard.
La LIF è implementata come un’entità logica che lega differenti interfacce fisiche (ad es.
Wi-Fi e 3G) in un'unica interfaccia, utilizzata da IP e i livelli superiori ; la LIF nasconde a
livello IP l’interfaccia fisica realmente utilizzata per inviare qualsiasi tipo di dato. Quindi,
un eventuale spostamento di un particolare flusso di dati da un interfaccia ad un'altra è
trasparente ad IP ed ai livelli superiori.
Come detto in precedenza, utilizzare collegamenti alla rete simultanei incrementa la
complessità. Attraverso l’uso del flow mobility, il nodo mobile ha la possibilità di ricevere
qualsiasi tipo di traffico destinato a ciascuno dei suoi indirizzi IPv6, mediante ciascuna
delle sue interfacce. Questo rappresenta un problema al livello dei MAG, i quali devono
poter inoltrare qualsiasi pacchetto dati verso ciascun prefisso associato al dato nodo
16
mobile, anche se questo prefisso era stato assegnato da un altro MAG. Infatti, un MAG
non inoltrerà traffico da/a un prefisso che non ha personalmente affidato al nodo mobile.
L’IETF si propone di risolvere questo problema utilizzando un ulteriore scambio di
messaggi, rispetto allo standard PMIPv6, in modo che i MAG possano essere configurati
in maniera appropriata.
In particolare, l’IETF si concentra su due scenari : ‘handover with full flow granularity’ e
‘partial handover‘. Il primo consiste nello spostamento di uno specifico flusso da un
interfaccia ad un'altra, mentre il secondo nel trasferire totalmente il prefisso e tutte le
comunicazioni che lo utilizzano verso un'altra interfaccia.
Entrambi i casi mettono in evidenza lo stesso problema : il MAG deve conoscere i prefissi
attraverso cui il nodo mobile sta ricevendo del traffico dati.
Ogni volta che il LMA decide di spostare un data flow da un accesso ad un altro, ha inizio
una procedura di signaling ; l’IETF ha definito nuovi messaggi che consentono al LMA di
notificare al MAG il nuovo prefisso cui inoltrare. Se, quando si verifica lo spostamento, il
MAG conosce già il nuovo prefisso, il LMA semplicemente sposta il flusso verso lo
specifico MAG e, in questo caso, non è richiesta alcuna ulteriore segnalazione.
Il mapping del flusso con il rispettivo MAG è specificato all’interno di una particolare
struttura dati posseduta dal LMA, chiamata flow mobility cache.
2.1.3 IP flow mobility in architetture 3G/4G
Il 3GPP SA2 WG ha definito quella che è l’architettura del sistema che fornisce il
supporto a connessioni PDN attraverso differenti accessi radio, mediante l’utilizzo di
dispositivi mobili che possiedono interfacce multiple. Ovvero, un’architettura che
consente un utilizzo simultaneo di accessi radio 3GPP e non-3GPP. Un utente mobile è,
quindi, in grado di ricevere ed inviare dati su di un canale cellulare 3GPP e, allo stesso
tempo, può sfruttare reti non-3GPP, come il Wi-Fi.
Consideriamo un utente connesso simultaneamente alla rete cellulare 3GPP e alla rete WiFi domestica ; il terminale utente può possedere differenti flussi dati che possono essere
17
instradati sia sull’una che sull’altra rete, sulla base di una politica decisa dall’operatore o
dall’utente stesso. Inoltre, se l’utente si sposta dalla zona di copertura della rete Wi-Fi, il
flusso IP su questo accesso radio è spostato verso l’accesso 3GPP per garantire la
continuità del servizio. Se, in seguito, l’utente dovesse tornare nella rete domestica, il
flusso dati può essere trasferito nuovamente sull’accesso Wi-Fi.
La core network può, inoltre, implementare meccanismi per bilanciare il carico della rete e
ottimizzare il traffico, re-direzionando determinati flussi IP verso una rete meno
sovraccaricata o comunque verso quella che risulta essere la rete d’accesso più
appropriata. Generalmente, un parametro cui si fa riferimento è la QoE (Quality of
Experience). In altre parole, il nodo mobile deve essere in grado di sfruttare i diversi
accessi radio per migliorare, qualora sia possibile, le sue performance; deve essere fornita
continuità del servizio quando il nodo mobile si sposta su diversi accessi, flussi dati
dovrebbero essere spostati da un accesso ad un altro in caso di perdita di connettività e
cambiamenti nelle capacità dei differenti accessi, come ad esempio la congestione della
rete, dovrebbero innescare il meccanismo del flow mobility. Per poter soddisfare questi
requisiti, 3GPP considera le alternative descritte in precedenza: DSMIPv6 (soluzione
client-based) e PMIPv6 (soluzione network-based).
DSMIPv6 è stato adottato in 3GPP Release 10 per attuare l’offload dei dati, senza alcuna
perdita di continuità. La 3GPP Evolved Packet Core (EPC) è in grado di interfacciarsi con
reti d’accesso non-3GPP ; quest’ultime possono essere classificate in trusted network e
non-trusted network. Le prime si connettono direttamente al PDN-GW, mentre le seconde
si connettono al PDN-GW attraverso l’ePDG (evolved Packet Data Gateway) e sono
soggette a controlli addizionali di sicurezza e autenticazione. Le interfacce EPC verso le
reti d’accesso non-3GPP sono classificate in base al proprio modo di gestire la mobilità :
S2a fa uso di meccanismi di gestione della mobilità trusted network-based, S2b fa uso di
meccanismi non-trusted network-based e S2c fa uso di meccanismi trusted/non-trusted
client-based. In questo caso, IP flow mobility, basato su DSMIPv6, coinvolge l’UE nella
gestione del problema relativo alla mobilità per cui l’interfaccia che assume maggiore
rilievo è S2c.
18
All’interno della rete d’accesso 3GPP, il ruolo dell’Home Agent è generalmente assunto
dal PDN-GW. Quando l’UE si trova in una rete differente dalla propria Home Network
invia i propri CoA, HoA e FID all’interno di un messaggio Binding Update (BU) diretto
all’HA ; quest’ultimo conserva queste informazioni e risponde con un Binding
Acknowledgement
(BA).
Questo
scambio
di
informazioni
è
utilizzato
per
aggiungere/rimuovere flussi dati e gestire al meglio la mobilità. IP flow mobility offre la
possibilità di scaricare flussi di dati selezionati, appartenenti alla stessa PDN connection,
su di un accesso differente. In breve, prevede il supporto di un offload selettivo tra le reti
d’accesso 3GPP e WLAN per flussi dati appartenenti ad una certa PDN connection e
supporto alla procedura di handover tra Evolved Packet System (EPS) e sistemi WLAN,
garantendo la continuità della sessione dati.
FIGURA 2 - IP flow mobility
La fig. 2 mostra attraverso un Message Sequence Chart un esempio di mobilità tra le reti
d’accesso LTE e WLAN. Nello step 1, l’UE effettua il primo accesso sulla rete LTE dove
viene settata la PDN Connection. L’UE e l’EPC si comunicano a vicenda la capacità di
supportare IP flow mobility utilizzando Internet Key Exchange v2 (IKEv2) o il parametro
Protocol Configuration Options (PCO) inserito nella procedura PDN Connectivity. Inoltre,
l’UE comunica il proprio indirizzo IP (HoA) e l’Home Network Prefix (HNP) ;
19
quest’ultimo è utilizzato dall’UE per identificare se si trova nella Home Network o meno.
La rete d’accesso 3GPP è sempre considerata la Home Network in IP flow mobility ;
quindi, nel caso in cui è stabilita una connessione PDN nella rete d’accesso WLAN, l’UE
invia un messaggio Binding Update per far sì che l’HA conosca il suo CoA. Nello step 2,
l’UE si accorge di trovarsi all’interno della zona di copertura di una rete WLAN e si
registra su di essa. L’UE individua l’HA della nuova rete e riceve un ulteriore indirizzo IP
e il HNP. Valutando l’HNP, l’UE si accorge di essere su di un foreign link e invia un
messaggio Binding Update all’HA con il suo CoA (l’indirizzo IP sulla WLAN), il FID e
specifica che in quel determinato momento vi sono due collegamenti attivi, uno con l’HoA
ed un altro con il CoA. L’HA mappa il CoA con il rispettivo HoA e invia un Binding
Acknowledgement. A questo punto, l’UE possiede due flussi di dati attivi, rispettivamente
sulla rete WLAN e quella LTE, all’interno della stessa connessione PDN. Nello step 3, si
fa riferimento all’effettivo funzionamento di IP flow mobility all’interno di una
connessione PDN. Stabilito il collegamento con entrambe le reti, è possibile aggiungere,
modificare ed eliminare flussi dati a seconda di ciò che la situazione richiede. E’ sempre
l’UE a richiedere un’operazione di aggiunta, modifica o cancellazione di un flusso, ma le
modifiche richieste da tali azioni possono essere attuate sia dall’UE che dalla rete stessa.
L’UE dà il via a queste operazioni inviando un BU con una nuova regola di routing, sulla
cui base assegnare un particolare flusso di traffico (FID) ad un altro accesso (BID). Una
volta effettuate tutte le modifiche e aggiornati tutti i collegamenti, l’HA risponde con un
BA.
IP flow mobility può essere configurato dinamicamente dall’operatore di rete utilizzando
meccanismi come Access Network Discovery and Selection Functions (ANDSF), oppure
in maniera statica attraverso una pre-configurazione. ANDSF è un metodo utilizzato dai
service provider per direzionare in maniera ottimale il traffico, fornendo politiche di
routing inter-sistema per ciascun APN utilizzato sul terminale. 3GPP Release 10 definisce
l’uso di ANSDF per DSMIPv6 in associazione con un traffic selector su di una certa rete
d’accesso. Ovviamente, nel caso di IP flow mobility lo stesso APN è configurato
contemporaneamente su LTE e Wi-Fi.
20
2.2 Local IP access
Local IP access è stato introdotto nella 3GPP Release 9 e successivamente ripresa nelle
Release 10 e 11. LIPA consente ad un UE connesso ad un H(e)NB (Home node B o Home
enode B) di trasferire dati verso una rete locale connessa allo stesso H(e)NB, senza dover
attraversare la rete macro-cellulare. Inoltre, offre la possibilità di accedere ad una qualsiasi
rete esterna purché sia connessa alla rete locale. Local IP access può essere utilizzato solo
per H(e)NB access, non per macrocell access e solo sulle reti private.
FIGURA 3 – Architettura Local IP Access
Consideriamo una rete aziendale all’interno della quale più dispositivi hanno necessità di
comunicare tra loro e di connettersi ad internet. La rete è implementata utilizzando un
femtocell gateway ed uno privato, cui sono connessi tutti questi dispositivi. LIPA permette
di gestire questa comunicazione interna tra i vari device attraverso il gateway privato. Il
flusso dati di una connessione LIPA non deve coinvolgere alcun elemento della cellular
network, ma deve attraversare la rete privata e giungere agli altri dispositivi che si trovano
all’interno di questa ; oppure, se esiste una connessione ad una rete esterna, il percorso dei
dati potrà terminare anche nella rete internet pubblica. Inoltre, L’UE è in grado,
utilizzando Local IP access, di effettuare accessi simultanei : può accedere alla rete
21
privata, attraverso la connessione LIPA, e alla rete pubblica, tramite la cellular core
network.
Nell’architettura LIPA definita da 3GPP possiamo trovare una nuova ed importante
funzionalità rappresentata dal cosiddetto Local Gateway (L-GW) ; Si tratta essenzialmente
di un Packet Data Network- Gateway (PDN-GW), quindi implementa funzionalità quali
l’allocazione dell’indirizzo IP per l’UE e packet filtering. Il L-GW è co-locato con
l’H(e)NB ed è, quindi, connesso con i dispositivi della rete privata e con la rete pubblica
attraverso l’interfaccia SGi. Inoltre, comunica con il macro Serving-Gateway (S-GW)
attraverso S5. La macro core network è responsabile dello scambio di messaggi per la
registrazione e delle procedure richieste per poter settare la connessione LIPA. Quando
quest’ultima è attiva, sarà compito del L-GW implementare il data path. Ovviamente, una
volta stabilita la connessione LIPA, l’UE potrà ancora interagire con la macro core
network, utilizzando connessioni PDN differenti ; l’utilizzo di un'unica connessione PDN
per LIPA consente di gestire in maniera differente il relativo flusso dati.
L’Home Subscriber Server (HSS) è modificato per includere le informazioni relative alla
sottoscrizione LIPA. In particolare, deve essere specificato se un particolare APN è
accessibile attraverso LIPA all’interno di un particolare CSG ID (Closed Subscriber
Group ID) ; in caso di roaming, deve essere mantenuta una lista dei PLMN su cui l’UE
può utilizzare LIPA ; ed infine, devono essere fornite le autorizzazioni LIPA, che
specificano se quel determinato APN è destinato solo ad accessi LIPA, se l’accesso LIPA
è proibito sul dato APN, o se è opzionale.
La funzione di selezione del Local Gateway è simile a quella del PDN Gateway all’interno
della macro network, ovviamente questa selezione dovrà tenere in conto anche la
sottoscrizione LIPA.
Generalmente, l’H(e)NB invia, durante la procedura di connessione PDN, l’indirizzo IP
del L-GW alla Mobile Management Entity (MME). La MME controlla con l’HSS se quel
particolare L-GW può essere selezionato dall’UE ed in caso affermativo invia l’indirizzo
del L-GW al S-GW (Serving Gateway); Se nel HSS è settata l’opzione ‘LIPA only’,
l’H(e)NB deve sempre fornire l’APN, se è settata l’opzione ‘LIPA conditional’ e non è
22
specificato alcun APN dall’H(e)NB, l’MME è libero di scegliere un altro PDN gateway
per effettuare una connessione PDN non-LIPA.
Nella fig. 4 è mostrato il settaggio della connessione LIPA e la costituzione del data path.
L’UE invia un messaggio PDN Connectivity Request con lo specifico APN per LIPA;
l’H(e)NB aggiunge a questo messaggio l’indirizzo IP del L-GW. Alla ricezione, l’MME
controlla nell’HSS la sottoscrizione dell’UE per determinare se quest’ultimo possiede il
FIGURA 4 – PDN Connection & Data path setup
permesso di accedere a quel particolare APN per LIPA; inoltre controlla anche le
autorizzazioni LIPA prima di selezionare il L-GW.
Una volta selezionato il L-GW, il suo indirizzo è comunicato al S-GW nel messaggio
Create Session Request ; il S-GW utilizza l’indirizzo del L-GW per poter richiedere la
creazione di un EPS (Evolved Packet System) Bearer attraverso il quale i due gateway
possono comunicare. Il L-GW risponde con un Create Session Response inserendo un
indirizzo PDN per l’UE e il L-GW TEID (Tunnel Endpoint ID). Questo crea
23
l’associazione tra L-GW, S-GW ed MME per l’interazione dati. Alla fine, l’MME
stabilisce il canale di default con l’UE, utilizzando l’APN LIPA e al termine di questa
operazione si ottiene quello che è il data-path tra l’UE, il L-GW e tutti gli altri dispositivi
o reti connesse a quest’ultimo.
Una volta stabilita la connessione PDN, le funzioni di upload e download dei dati
proseguono seguendo le regolari procedure descritte in 3GPP. Un pacchetto dati UL
innesca l’invio di una Service Request dall’UE all’ MME; quest’ultimo invia un Initial
Context Setup Request contenente il L-GW TEID al H(e)NB; quest’ultimo utilizza questo
parametro principalmente per mappare l’RB (Radio Bearer) ID e creare il tunnel diretto
con il L-GW per il percorso dati.
Nel caso di un pacchetto dati DL, la ricezione da parte del L-GW scatena l’invio di un
pacchetto di prova al S-GW; quest’ultimo invia un DL Data Notification Message al
MME e l’MME convoca l’UE. L’UE risponde con una Service Request e la procedura, da
questo punto in poi, è simile a quella del caso UL.
Non ci sono molte differenze per quanto riguarda la procedura di Connection Release. Se
la richiesta di rilascio della connessione proviene dalla macro connection e l’UE sta per
assumere lo stato Idle, l’H(e)NB informa il L-GW.
Fino a questo momento, non è ancora stata definita una tecnica che consenta di ottenere
una continuità nella connessione LIPA a seguito della mobilità; la connessione LIPA è
infatti rilasciata ogni qual volta l’UE si sposta al di fuori della copertura dell’H(e)NB.
2.3 Selected IP traffic offload
SIPTO è una tecnica introdotto nella 3GPP Release 10, che consente di scaricare una parte
del traffico IP verso una rete locale, in modo da ridurre il carico sul sistema. La rete di
destinazione può essere un H(e)NB o un altro gateway nella rete cellulare che deve essere
vicino all’UE. SIPTO può essere utilizzato a seguito di uno spostamento dell’UE (quindi
nell’ambito della mobilità), oppure in caso di congestione della rete. Un operatore che
copre una certa area può pensare di scaricare tutto il traffico internet di quell’area verso un
24
gateway locale; in questo modo si può facilmente evitare una potenziale condizione di
sovraccarico della rete e gli utenti potranno usufruire di migliori prestazioni.
3GPP definisce due differenti architetture che si basano sul punto di breakout ; in questo
contesto, questo punto individua il luogo in cui avviene il data offloading. Il breakout può
avvenire a livello delle reti private (caso femto SIPTO) o a livello RAN (casi femto e
macro SIPTO). Selected IP traffic offload è, quindi, definito sia per macrocell che per
femtocell ; in entrambi i casi, l’accesso e il rilascio delle funzionalità SIPTO può essere
dinamicamente controllato attraverso molteplici meccanismi dall’operatore mobile,
l’H(e)NB e l’UE ; SIPTO può essere attivato senza l’intervento di alcun utente. Inoltre, la
continuità del servizio dati durante lo spostamento tra macro e micro networks o
all’interno della stessa macro network è gestito utilizzando le normali procedure definite
da 3GPP. Infine, SIPTO deve essere supportato mentre l’UE è in roaming; per far sì che
ciò accada, deve essere garantito uno scambio di informazioni tra la Home Public
Landline and Mobile Network (HPLMN) e la Visited Public Landline and Mobile Network
(VPLMN).
Ovviamente, il requisito fondamentale che permette il funzionamento di SIPTO, nel caso
femtocell, è quello di utilizzare il meccanismo del data offloading senza utilizzare alcun
elemento della rete macro cellulare.
2.3.1 Selected IP traffic offload MACRO
SIPTO, operante nelle macrocell, consente di scaricare traffico PS (packet switched)
selezionato verso una particolare rete IP ; questo implica la possibilità di scaricare
particolari flussi di dati, mentre contemporaneamente altri proseguono con il loro normale
corso. Inoltre, per gestire meglio l’operazione di offload, l’operatore può pensare di
abilitare/disabilitare SIPTO solo in determinate zone della rete.
L’idea base di Selected IP traffic offload è quella di selezionare un S-GW e un PDN-GW
topologicamente vicini alla rete radio (4G e 3G) e alla MME e di utilizzarli per scaricare
dati. Il Local PDN-GW è un normale PDN-GW, con l’unica variante di essere il più vicino
alla RAN.
25
FIGURA 5 – SIPTO macro
L’HSS contiene la lista dei dati APN sui quali SIPTO è supportato ; inoltre, questa
informazione è contenuta anche tra i dati della MME. Se SIPTO è supportato per quel
particolare APN, la selezione del S-GW e del PDN-GW, per stabilire una PDN connection
verso il relativo APN, include lo scambio di informazioni relative alla posizione, come ad
esempio il Tracking Area Identify (TAI). I gateway sono selezionati sia nel momento in
cui è stabilita la connessione PDN iniziale, sia successivamente a seguito di spostamenti.
A tal proposito, procedure come PDN Disconnect, EPS Bearer Deactivation o EPS
Detach sono utilizzate per assicurare che la MME possa selezionare gateway che
rispecchino i requisiti richiesti da SIPTO.
La fig. 6 mostra la tecnica SIPTO data offload. Nello scenario 1 è stabilita la connessione
PDN; la MME riceve una PDN Connectivity Request al cui interno è contenuto un APN e
una volta controllato che questo sia in grado di supportare SIPTO, sono scelti il S-GW e il
PDN- GW più vicini alla posizione dell’UE. Nello scenario 2, durante un Tracking Area
Update (TAU) / Routing Area Update (RAU), se la rete determina che i flussi dati
associati ad una specifica PDN hanno bisogno di essere scaricati su di un set di Gateways
più vicini, la relativa connessione PDN può essere terminata per poi essere
successivamente riattivata. In alternativa, la MME può disattivare un canale EPS in una
particolare connessione PDN definendo un particolare valore per poterne innescare la
26
FIGURA 6 – SIPTO data offload
riattivazione. Nello scenario 3 è preso in considerazione il caso in cui l’UE cambia la sua
area di registrazione; se tutte le connessioni PDN attive verso la MME supportano SIPTO,
può essere effettuata una riselezione dei gateway. La MME sceglie, allora, di disconnettere
l’UE e tutte le relative connessioni; successivamente, al momento di ristabilire la
connessione PDN, la MME sceglierà nuovamente quelli che sono i gateway più vicini a sé
stesso.
27
Conclusioni
I tre meccanismi sopra descritti forniscono una soluzione per il data offloading,
presentando tuttavia alcune differenze. Possiamo individuare quelli che sono gli aspetti
positivi e quelli negativi di ciascuna di queste tecnologie. Local IP Access si presenta
come una soluzione ben definita per le reti locali, ma non applicabile alle macro networks.
Selected IP traffic offload è applicabile sia su macro che femto celle ed ha un impatto
minimo; sfortunatamente, questa tecnica non fornisce alcun supporto alla congestione
radio. Ed infine, IP flow mobility risolve il problema sia della congestione radio che della
core network, ma necessita del supporto di una rete d’accesso non 3GPP e risulta più
complicata
da
implementare.
Questi meccanismi sono sottoposti a continui processi di ottimizzazione.
Con l’incremento dei data-rates e dell’utilizzo dei mobile data, l’importanza dei
meccanismi di offloading è in continua crescita e lo sarà soprattutto nei prossimi anni,
assumendo quindi un ruolo chiave. Ci si aspetta che i service provider adotteranno un
sempre più ampio numero di strategie per riuscire a gestire al meglio quello che può essere
definito come uno ‘tsunami’ del traffico dati sulle proprie reti.
28
Bibliografia
[1]
Adnan Aijaz, Hamid Aghvami, and Mojdeh Amani, King’s College London, “A
Survey on Mobile Data Offloading: Technical and Business Perspectives”, IEEE Wireless
Communications, April 2013.
[2]
C.B. Sankaran, Motorola Mobility India, “Data Offloading Techniques in 3GPP
Rel-10 Networks: A tutorial”, IEEE Communications Magazine, June 2012.
[3]
Antonio De la Oliva, Carlos J. Bernardos, and Maria Calderon, Universidad Carlos
III de Madrid, Telemaco Melia, Alcatel-Lucent Bell Labs, Juan Carlos Zuniga,
InterDigital LLC, “IP Flow Mobility: Smart Traffic Offload for Future Wireless
Networks”, IEEE Communications Magazine, October 2011.
[4]
“Mobile
IPv6
Support
for
Dual
Stack
Hosts
and
Routers”,
https://tools.ietf.org/html/rfc5555
[5]
“Proxy Mobile IPv6”, https://tools.ietf.org/html/rfc5213
[6]
3GPP TS 22.220 v11.2.0, Service requirements for Home Node B (HNB) and Home
eNode B (HeNB) Release 11.
[7]
3GPP TR 23.829 v10.0.0, Local IP Access and Selected IP Traffic Offload (LIPA-
SIPTO) (Release 10).
29