Lo standard IEEE

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Protocolli per reti mobili Lo standard IEEE Anno Accademico 2013/2014 Candidato: Mariagrazia Cautiero matr. N

2

3 Indice Introduzione...4 Capitolo 1: Presentazione dello Standard Storia Finalità Modello di riferimento...7 Capitolo 2: Panoramica Tecnica Architettura generale Media-Indipendent Handover Services Media-Indipendent Event Service (MIES) Media-Indipendent Command Service (MICS) Media-Indipendent Information Service (MIIS) Service Management MIH capability discovery MIH registration MIH subscription Media-Indipendent Handover Protocol Acknowledgment service Esempio d uso...22 Conclusioni...25 Bibliografia...26

4 Introduzione Al giorno d oggi sono sempre più diffusi i dispositivi mobili come smartphone e palmari, i quali sono equipaggiati con interfacce di rete sempre più diverse (IEEE , IEEE , 3G). Questa condizione ha fatto sì che gli utenti vogliano sempre essere globalmente raggiungibili e sempre always best-connected. A tal fine si cerca costantemente di assicurare l interoperabilità tra reti eterogenee, in modo da ottimizzare l uso delle risorse di rete, riuscendo a selezionare efficientemente la migliore rete d accesso tra quelle disponibili basandosi su parametri definiti dall'utente, come il costo della connessione, la larghezza di banda e il consumo di batteria. Si pone questo obiettivo il gruppo di lavoro IEEE , il quale ha formulato lo standard che dovrebbe permettere all utente di trarre pieni vantaggi dalla sovrapposizione e diversificazione delle reti di accesso. Questo standard, il quale specifica una struttura che permette la continuità del servizio in modo trasparente mentre un nodo mobile si sposta tra tecnologie di accesso eterogenee, vuole aiutare i nodi mobili a prepararsi ad eventuali azioni di handover da un PoA 1 all altro, ma non specifica come debba avvenire la migrazione. 1 Point of Attachment 4

5 Capitolo 1: Presentazione dello Standard 1.1 Storia La figura 1.1, illustra il processo di sviluppo dello standard. Il working group ha iniziato a lavorare nel 2004, è stato accettato come un nuovo standard dal IEEE-SA Standard Board[6] nel Novembre del 2008 e la prima versione dello standard è stata pubblicata a Gennaio Figura 1.1 Timeline of the IEEE Standardization 1.2 Finalità Lo standard IEEE , anche conosciuto come Media-Indipendent Handover Services, è stato pensato per ottimizzare quello che viene definito Vertical Handover, o handover eterogeneo, cioè quello che avviene quando ci si sposta tra reti differenti (diversa tecnologia di accesso). L handover può essere inoltre di due tipi: Hard Handover e Soft Handover. L Hard Handover, anche chiamato break-before-make handover, prevede che la connessione attuale venga chiusa prima di aprirne una nuova. 5

6 Soft Handover, oppure make-before-break handover, prevede invece che la nuova connessione venga stabilita prima di chiudere quella in corso, il terminale avrà quindi per un breve periodo due connessioni aperte. Figura 1.2 Fasi dell' handover In figura 1.2 sono illustrate le fasi dell handover. In particolare lo standard si occupa di garantire i servizi di seguito elencati: Service continuity: si vuole garantire la continuità del servizio durante e dopo l handover minimizzando aspetti come la perdita di dati, senza richiedere l intervento dell utente che non dovrebbe rendersi conto del cambio di rete d accesso. Application class: vuole garantire handover application-aware che tengono conto delle diverse caratteristiche di tolleranza, ai ritardi o alle perdite di dati, delle applicazioni. Quality of Service: vuole fornire supporto per soddisfare i requisiti di QoS delle applicazioni, che dipendono dall accuratezza, velocità e disponibilità nel trasferimento di dati nel canale di comunicazione. 6

7 Network discovery: definisce le informazioni che aiutano nella ricerca delle reti e specifica il modo in cui tali informazioni possono essere ottenute e rese disponibili. Power Management: permette al nodo mobile di trovare differenti tipi di reti wireless, evitando di accendere piu interfacce radio. Per esempio un nodo mobile connesso ad una rete 802 come , sarà capace di ottenere informazioni sulla rete cellurare 3G all interno della specifica area geografica, senza il bisogno di accendere la determinata interfaccia per ottenere quest informazione. Questa caratteristica permette un uso ottimale della batteria. 1.3 Modello di riferimento Il modello di riferimento di questo standard è presentato in figura 1.3 e include le seguenti entità di rete oltre al nodo mobile multiaccesso: MIH Point of Service (MIH PoS): questa entità di rete scambia messaggi con il nodo mobile. Un nodo mobile può avere diversi PoS dal momento in cui può scambiare messaggi con più di una entità di rete. MIH non-pos: entità che non scambia messaggi con il nodo mobile, tuttavia un dato nodo di rete può essere un PoS per un nodo mobile con cui scambia messaggi e non-pos per un nodo con cui non lo fa. MIH Point of Attachment (PoA): rappresenta il PoS con il quale è collegato il nodo mobile. 7

8 Figura 1.3 Modello di riferimento Per rendere possibile la comunicazione tra queste entità di rete il modello specifica diversi reference point a seconda delle entità coinvolte: 1. Reference Point RP1 MN Serving PoA (PoS) : usato dal nodo mobile per comunicare con il suo PoA; 2. Reference Point RP2 MN Candidate PoA (PoS) : usato dal nodo mobile per comunicare con un candidate PoA; Figura 1.4 Communication Model 8

9 3. Reference Point RP3 MN non-poa (PoS) : usato dal nodo mobile per comunicare con un MIH PoS che si trova su un entità di rete non-poa; 4. Reference Point RP4 PoS non-pos : usato per comunicazioni tra un MIH PoS e un MIH non-pos; 5. Reference Point RP5 PoS PoS : usato tra due diversi MIH PoS situati su differenti entità di rete. 9

10 Capitolo 2 Panoramica tecnica 2.1 Architettura Generale L IEEE introduce tra il livello di collegamento e il livello di rete una nuova entità logica: Media-Indipendent Handover Function (MIHF). Si comporta come intermediario e fornisce servizi alle entità che si trovano a livello rete o sopra, chiamati MIH Users (MIHU). Questi ultimi sono tipicamente mobility management protocols che hanno il compito, quindi, di prendere le decisioni di handover e di selezionare la rete in base al contesto e alle informazioni ricevute dal MIHF. Quindi il ruolo primario del MIHF è di fornire tutte le informazioni necessarie al selettore di rete o alle entità di mobility management, senza prendere alcuna decisione per quanto riguarda la selezione della rete. Lo standard fornisce inoltre una serie di primitive di servizio, raggruppate in SAP (Service Access Point), per la comunicazione tra MIHF e le altre entità. L interfaccia che mette in comunicazione MIHF e MIHU è indipendente dalla tecnologia e viene chiamata MIH_SAP, mentre per ottenere servizi dagli strati inferiori c è bisogno di una molteplicità di interfacce che dipendono dalla tecnologia della rete d accesso con cui si vuole interagire le MIH_LINK_SAP. Inoltre lo standard specifica una ulteriore media-indipendent SAP (MIH_NET_SAP) che provvede allo scambio di messaggi con entità MIHF remote. 10

11 Figura 2.1 Architettura 2.2 Media-Indipendent Handover Services I servizi offerti dal MIHF possono essere divisi in tre categorie: Event Service (MIES) che provvede a classificare, filtrare e riportare gli eventi, per esempio cambiamenti dinamici nelle condizioni di rete e la qualità del collegamento. Tali eventi possono essere sia locali che remoti. Command Service (MICS) abilita i MIHU a gestire e controllare i parametri associati al comportamento del collegamento e degli handover. I comandi possono essere locali e remoti e l informazione ottenuta col MICS è dinamica. Information Service (MIIS) permette ai MIHU di ricevere informazioni statiche sulle caratterisciche e i servizi della rete ospitante e delle altre reti disponibili. 11

12 2.2.1 Media-Indipendent Event Service (MIES) Gli eventi previsti dal MIES indicano o anticipano cambiamenti nello stato e nel comportamento della trasmissione a livello fisico e data link. In generale gli eventi sono triggers per iniziare a candidare nuove reti per la procedura di handover, tuttavia un entità non è costretta a reagire agli eventi poichè essi fungono solo da avvertimento. Poichè molteplici entità possono essere interessate agli eventi generati, lo standard specifica un meccanismo di consegna a sottoscrizione, quindi tutte le entità interessate in un tipo di evento si possono registrare ad esso e, quando l evento è generato, sarà mandato alla lista degli iscritti. Gli eventi possono essere divisi in due categorie: Link Events e MIH Events, a seconda della loro origine. Link events sono generati dal livello data link e ricevuti dal MIHF, mentre i MIH Events provengono dal MIHF. I Link events che vengono poi propagati ai livelli superiori diventano MIH Events. Possono essere entrambi sia remoti che locali. Figura 2.2 MIH Events flow Il MIES al momento supporta diversi tipi di eventi: MAC e PHY State Change events, Link Parameter event, Predictive events, Link Handover events, e Link Transmission events. 12

13 MAC e PHY state change events corrispondono al cambiamento nello stato MAC e PHY. Gli eventi più caratteristici in questa categoria sono Link_up e Link_Down, che vengono generati quando una connessione a livello data link viene stabilita o chiusa. Un ulteriore evento chiamato Link_Detected, indica che un PoA è stato trovato ma non è stata stabilita ancora nessuna associazione. Link Parameter events sono generati in seguito ad un cambiamento dei parametri nel livello data link. Un Link_Parameters_Report può ad esempio essere inviato quando un determinato parametro oltrepassa la soglia stabilita dal MIHU per lo stesso. È inoltre usato per inviare periodicamente notifiche sulle condizioni del collegamento. Possono quindi essere generati sia in modo sincrono che in modo asincrono. Predictive events informano sulle probabilità di cambiamenti negativi nelle caratteristiche del collegamento nel prossimo futuro. Per esempio, un Link_Going_Down è inviato se viene osservata una forte caduta nella forza del segnale e ci si aspetta l imminente perdita del collegamento. I Predictive events possono inoltre includere informazioni temporali su quando ci si aspetta che un determinato evento avrà luogo. Link Handover event indicano il verificarsi di handover a livello data link. L evento Link_Handover_Imminent serve come notifica per un imminente handover a causa di cambiamenti delle condizioni del collegamento, mentre Link_Handover_Complete riporta il successo nel cambio di PoA. Questi eventi sono generati dal livello data link e sono basati esclusivamente su informazioni locali. 13

14 Link Trasmission events mostrano lo stato della trasmissione dei pacchetti a livello data link (PDU 2 ) tramite la primitiva Link_PDU_Transmit_Status. I livelli sovrastanti possono ad esempio adattarsi alla perdita di dati durante un handover migliorando la gestione del buffer Media-Indipendent Command Service (MICS) Il Media-Indipendent Command Service (MICS), abilita gli alti livelli a controllare il flusso degli eventi che hanno origine dai livelli bassi, così da determinare lo stato dei collegamenti e configurare il terminale per ottenere performance ottimali dalle politiche di handover. I comandi possono essere sia locali che remoti. Lo standard specifica una serie di comandi per permettere agli utenti di controllare la configurazione e il comportamento dei livelli bassi. A seconda che i comandi abbiano origine dai MIHU o dal MIHF si dividono in due categorie: MIH commands hanno origine dai MIHU e sono diretti al MIHF, che può essere sia locale che remoto. Nel caso in cui il comando sia indirizzato ad un MIHF remoto, sarà inviato prima al MIHF locale che poi invierà il comando alla destinazione appropriata attraverso il MIHF transport protocol. I MIH commands sono tipicamente usati per la selezione della rete e la gestione dell handover, poiché permettono ai livelli alti di inizializzare, preparare ed eseguire l'handover. MIH commands sono inoltre usati per configurare soglie relative a parametri di collegamento. Link commands hanno origine dal MIHF, per conto dei MIHU, in modo da configurare e controllare le operazioni dei livelli più in basso. Questi comandi possono essere solo locali. Per esempio, un MIHU può inviare un MIH_Link_Get_Parameters, il MIHF locale lo inoltrerà al MIHF remoto il quale invierà un Link_Get_Parameters locale. In questo modo il MIHF può acquisire 14

15 i valori dei parametri correnti dei collegamenti attivi per il MIHU, e poi inviare queste informazioni al MIHU che le ha richieste. Figura 2.3 MIH Command flow Media-Indipendent Information Service (MIIS) Il Media-Indipendent Information Service (MIIS), fornisce una struttura attraverso la quale il MIHF di un dispositivo multiaccesso può acquisire informazioni, prevalentemente statiche, sulle reti nelle vicinanze. L obiettivo quindi è di acquisire una conoscenza generale di tutte le reti nell area di interesse del terminale, il tutto mentre il terminale è connesso ad un altra rete. Quindi si possono ottenere informazioni non solo relative alle reti della stessa tecnologia di accesso a cui il nodo è collegato, ma relative a tutti i tipi di rete disponibili in zona, senza il bisogno di attivare la specifica interfaccia. Il MIIS si basa su una serie di Information Elements (IE) che forniscono informazioni essenziali per l algoritmo di selezione di rete. Le informazioni fornite dagli IE possono essere sia relative a livelli bassi, come mappa delle reti vicine o parametri di collegamento, sia a livelli alti come una mancanza di connettività internet in certe 15

16 zone o la disponibilità di determinati servizi. Gli Information Elements forniti dal MIIS possono essere suddivisi nei seguenti gruppi: General Information: forniscono una visione generale sulle reti disponibili con informazioni come la tecnologia di accesso, l identificativo dell operatore o del service provider. Access Network-Specific information: queste IE forniscono informazioni specifiche su ogni tecnologia e operatore. L informazione può essere relativa a caratteristiche di sicurezza, QoS e costi. Tramite queste informazioni si può stabilire che, se l operatore di una determinata rete applica una tariffa basata sul volume del traffico, il selettore di rete potrebbe scartare il corrispondente punto di accesso se sul dispositivo è attivo un servizio ad alto bitrate. PoA-Specific Information si riferiscono ad ogni PoA disponibile e riportano la locazione e le informazioni di indirizzamento, i data rate supportati, l indirizzo MAC e parametri del canale che possono ottimizzare la connettività a livello data link. Quindi un mobility manager avanzato sul nodo mobile può usare le informazioni sulla posizione geografica del PoA e, confrontandola con la posizione del PoA attuale e con la locazione del nodo mobile, può essere in grado di ridurre il numero di handover e ottimizzare l uso delle risorse di rete. Higher Layers services/information per PoA: L informazione fornita è relativa ai servizi disponibili in un determinato PoA. L informazione può includere 16

17 metodi di configurazione IP disponibili o anche una lista di tutti i servizi supportati dal PoA. Other Information possono infine essere aggiunte e includono dettagli sul rivenditore e sulla rete. Le IE e le loro relazioni sono collezionate in un Information Service schema che definisce anche la struttura dell informazione. L IEEE stabilisce che l informazione deve essere rappresentata in un formato comune e aperto come XML 2 o TLV 3. Il MIIS prevede quindi meccanismi per fornire e richiedere queste informazioni, che possono risiedere sia su un server separato che in un database locale. 2.3 Service Management Affinchè un MIHF sia in grado di fornire MIH services ad altre entità, è necessario che le entità MIHF siano configurate in modo opportuno. Questo avviene attraverso tre funzioni di service management. MIH capability discovery MIH registration MIH event subscription MIH capability discovery La procedura di MIH capability discovery, tramite la primitiva MIH_capability_Discover, viene usata da un MIHU per trovare entità MIHF e le loro capacità in termini di MIH services discussi nel precedente paragrafo. 2 extensible Markup Language 3 Type-Lenght-Value 17

18 In base all informazione ottenuta da questa procedura, il MIHF locale può determinare con quale peer MIHF si dovrebbe registrare. La MIH capability discovery function può usare sia il MIH protocol che meccanismi specifici del mezzo di trasmissione, come frame beacon di IEEE Un entità MIHF che risiede nelle rete può inoltre annunciare la sua esistenza e le sue capacità periodicamente MIH registration La MIH registration è una procedura simmetrica con la quale due peer MIHF si autenticano per poter poi comunicare tra loro in un modo più confidenziale. La registrazione ha inizio quando un MIHU invoca la primitiva MIH_Register, poichè ha bisogno che il MIHF locale si registri con un MIHF remoto. Attraverso la registrazione e l'autenticazione, i peer MIHF tipicamente avranno accesso a più informazioni rispetto a quelle cui hanno accesso MIHF non registrati. La primitiva MIH_DeRegister viene usata per annullare una registrazione MIH event subscription Infine MIH event subscription (MIH_Event_Subscribe, MIH_Event_Unsubscribe) abilita i MIHU ad abbonarsi a una particolare serie di eventi previsti dal MIES di un MIHF locale o remoto. La sottoscrizione ad eventi forniti da un MIHF remoto richiede prima la registrazione e la conoscenza delle sue capacità e contiene solo la lista di eventi a cui il MIHU è interessato. Ogni richiesta di abbonamento è associata ad un messaggio di conferma che indica gli eventi approvati alla sottoscrizione. 2.4 Media-Indipendent Handover Protocol Il media-indipendent handover protocol (MIHP) definisce lo scambio di messaggi tra due entità MIHF remote, le quali possono scambiarsi reports e altre informazioni. Il MIH protocol si occupa di incapsulare i dati in MIH frame e mandarli attraverso il 18

19 livello fisico. Una MIH transaction è composta da una serie di messaggi aventi lo stesso Transaction-ID, inviati o ricevuti da uno specifico MIHF ID. In ogni momento un MIH node deve avere non più di una transazione in attesa di essere inviata o ricevuta per ciascuna direzione. Il protocollo definisce il formato dei messaggi, dell header e il formato di codifica. Figura 2.4 MIH Protocol frame I MIH protocol message, o frame, includono un header e un TLV-encoded payload. L header consiste di otto byte. La figura illustra il MIH protocol header indicando la rispettiva lunghezza in bit per ogni campo mentre la tabella ne descrive il significato. Figura 2.5 MIH protocol frame header 19

20 Nome del campo Dimensione (bit) Descrizione Version 4 Specifica la versione del protocollo usato. Un nodo MIH che riceve un messaggio MIH con un numero di versione più alto di quello che supporta, scarterà la frame senza avvertire il nodo MIH mittente. ACK-Req 1 Questo campo è usato per richiedere un ACK ACK-Rsp 1 Questo campo è usato per rispondere ad un ACK- Request UIR(Unauthenticated information request) 1 Indica che il messaggio di risposta potrebbe essere inviato con una lunghezza limitata a causa della natura non autenticata dello scambio dei messaggi. È settato ad 1 in caso di stato non autenticato o non registrato, 0 negli altri casi. M(More fragment) 1 Se settato ad 1 indica che il messaggio è un frammento e che non è l ultimo della serie. Se settato a 0 puo indicare che è l ultimo frammento della serie o è un messaggio non frammentato. FN (Fragment number) 7 È usato per rappresentare il numero nel frammento nella sequenza. Se settato a 0 indica che il messaggio non è frammentato. Reserved1 1 Questo campo viene intenzionalmente tenuto riservato. Quando non è usato è settato a 0 MIH message ID (MID) 1.Service identifier(sid) 2.Operation code(opcode) È composto da 3 campi: Identifica la classe del servizio a cui appartiene il messaggio Specifica il tipo di operazione da eseguire, che può essere una risposta una richiesta o un indicazione 3.Action identifier(aid) 10 Indica lo scopo preciso. Ad esempio se il SID indica MIES, AID indica il tipo di evento. Reserved2 4 Questo campo è tenuto riservato. Quando non è usato tutti i bit sono settati a 0 Transaction ID 12 È usato per associare richieste e risposte, così come richieste, risposte e indicazioni ad un ACK Variable payload lenght 16 Indica la lunghezza totale del payload trasportato dal determinato messaggio, senza considerare la lunghezza del header 20

21 Il payload infine contiene messaggi specifici del servizio, codificati in formato TLV (figura 2.6). Nella codifica TLV il type field denota il tipo di parametro, il lenght field indica la lunghezza del campo value e quest ultimo trasporta il valore del parametro. I primi due campi TLV nel payload devono essere il "Source MIHF identifier" e "Destination MIHF Identifier", i quali sono entrambi di tipo MIHF ID. Ogni MIHF ha un unico MIHF ID che gli viene assegnato a tempo di configurazione. In caso di messaggi broadcast, il destination identifier TLV setta il campo lenght a zero. Figura 2.6 Struttura MIHP frame TLV Acknowledgement service L acknowledgement service può essere usato quando il trasporto MIH utilizzato per la comunicazione remota non prevede servizi affidabili. Al contrario quando il trasporto MIH è affidabile il servizio non è necessario. Il MIHF mittente può settare il flag ACK-req per richiedere un messaggio ACK al ricevente. Mentre il flag ACK-rsp è settato dalla destinazione. Il MIH message ID e il Transaction ID saranno gli stessi sia nel messaggio di richiesta che nell ACK di risposta ad esso. Un ACK message non contiene alcun payload. 21

22 2.5 Esempio d uso Di seguito (vedi figura 2.7) si mostra lo scambio di messaggi che avviene quando si vuole iniziare una fase di handover da una rete 3G ad una WLAN. Segue una dettagliata spiegazione dei passaggi e delle procedure: - La procedura di handover ha inizio dal MIH user del nodo mobile quando chiede al MIHF locale informazioni sulle reti circostanti (messaggio 1). Questa query è inoltrata dal MIHF al information server. La query ha inizio con il messaggio 1 ed ottiene risposta dal messaggio 4. Il nodo mobile ottiene così le informazioni richieste, in modo da avere una conoscenza delle potenziali reti con le quali eseguire un handover mentre si sposta attraverso la specifica area geografica. In questo caso la risposta contiene informazioni su una possibile rete WLAN, quindi il nodo mobile si sposta sulla sua interfaccia WLAN e inizia ad ascoltare per frame beacon. - Una volta che una frame beacon è stata ricevuta, il livello data link IEEE genererà un Link_Detected.indication event (messaggio 5). Questa indicazione è inoltrata poi dal MIHF al MIHU con il messaggio 6. - Quando un MIHU riceve la MIH_Link_detected.indication, incomincia la procedura di mobile-initiated handover mandando al suo PoS (nella rete 3G) le informazioni riguardo le potenziali reti candidate trovate. Quest informazione è inviata nel messaggio 7 al MIHF che inoltra la query al PoS (messaggio 8). - Dopo aver ricevuto il messaggio 8, il PoS attuale inizia ad interrogare le reti disponibili candidate, tenendo conto dell informazione fornita dal nodo mobile, chiedendo la lista delle risorse disponibili includendo le esigenze di QoS dell utente (scambio 9). Questo avviene attraverso uno scambio di Query_resources message con uno o più PoS candidati. Il risultato delle query è mandato al nodo mobile attraverso i messaggi 10 e 11. A questo punto il nodo mobile ha abbastanza 22

23 informazioni sulle reti circostanti per prendere una decisione sulla rete su cui spostarsi. - Una volta che il MIHU ha deciso la rete di destinazione, manda uno Switch command al MIHF (messaggio 12) il quale attiverà una connessione WLAN a livello 2 e invierà un evento al MIHU indicandogli l inizio della connessione (messaggio 13). Una volta che la connessione è stabillita, il livello MAC WLAN invia al MIHF un evento che riporta la fine dell handover a livello 2, che viene poi inoltrato al MIHU (messaggio 15). - Quando il messaggio 15 è ricevuto può iniziare una procedura di handover a livelli alti, ad esempio Mobile IP[6]. - Quando anche l handover a livelli alti è completato il MIHU manda un messaggio MIH_HO_complete al MIHF il quale informa il PoS destinatario che è divenuto il nuovo serving PoS. A questo punto il PoS informa tutte le entità di rete implicate della fine dell handover (messaggio 18). Il messaggio 19 chiude la procedura di handover, indicando al nodo mobile che la procedura è terminata e il messaggio 20 informa il MIHU. 23

24 Figura 2.7 Esempio di vertical handover con

25 Conclusioni In questo elaborato si è voluto presentare lo standard IEEE La sua adozione sui dispositivi mobili permetterà un miglior uso delle risorse di rete e di selezionare la rete di acesso che meglio si adatta ai propri bisogni. Ci si aspetta tuttavia che questo standard venga ampliamente sviluppato nel futuro. Inoltre nel 2012 è stata pubblicata un estensione del protocollo che si occupa della sicurezza (IEEE a [9]). Al momento sono disponibili diverse implementazioni dello standard IEEE , la più nota è ODTONE[7]. ODTONE fornisce un implementazione open-source realizzata in C++, resa multipiattaforma tramite la libreria Boost[8], in particolare è possibile eseguire ODTONE su sistemi GNU/Linux, Windows, Android e OpenWrt. Oltre ad un implementazione del MIHF, che supporta quindi tutti i servizi e i meccanismi definiti dallo standard, fornisce l implementazione di alcuni MIH User e LINK_SAP e dà la possibilità all utente di implementare i propri. Ad oggi però è ancora incerto se i venditori accetteranno di incorporare tale standard nei loro dispositivi. 25

26 Bibliografia [1]Esa Piri and Kostas Pentikousis, IEEE The Internet Protocol Journal, Volume 12, No.2, June 2009 [2]IEEE Computer Society. Ieee standard for information technology local and metropolitan area networks part 21: Media independent handover services. IEEE Std , Gennaio [3]Antonio de la Oliva, Telemaco Melia, Albert Banchs, Ignacio Soto and Albert Vidal, IEEE (Media Independent Handover services) Overview [4] IEEE , [5] IEEE-SA Standards Board, [6]Mobile ipv4. [7]ODTONE Team, Odtone, an open source multi-platform implementation of the ieee protocol. [8]Boost c++ libraries, [9]IEEE Computer Society, IEEE a IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services - Amendment for Security Extensions to Media Independent Handover Services and Protocol 26