verticale

Progetto e realizzazione di una soluzione di routing multi-hop per reti PLC

Testare le prestazioni della tecnologia
Homeplug AV in diversi scenari e progettare una soluzione di
routing basata su quelle già esistenti in campo wireless,
per la realizzazione di reti ad hoc PLC.

Scarica il PDF Scarica il PDF
Aggiungi ai preferiti Aggiungi ai preferiti


Articoli tecnico scientifici o articoli contenenti case history
Tesi di Laurea, Politecnico di Milano, Anno Accademico 2010- 2011

Pubblicato
da Alessia De Giosa




Settori: 

Parole chiave: 


Estratto del testo
POLITECNICO DI MILANO Facoltà di Ingegneria dell''Informazione Corso di Laurea Magistrale in Ingegneria delle Telecomunicazioni Dipartimento di Elettronica e Informazione Progetto e realizzazione di una soluzione di routing multi-hop per reti PLC Relatore: Prof. Antonio CAPONE Tesi di Laurea di: Simone SCREMIN Matricola n. 682497 Anno Accademico 2010''2011 Ringraziamenti a mia nonna. iii Riassunto Lo sviluppo delle tecnologie PLC le ha rese una soluzione appetibile e concorrenziale per la creazione di reti domestiche. Con la standardizzazione da parte di IEEE è auspicabile che diventino an- che una soluzione impiegata nella realizzazione di segmenti di reti ad-hoc a fianco delle collaudate soluzioni wireless. Per poter essere sfruttate a pieno in questo ambito è necessario poter utiliz- zare le PLC in modalità multi-hop, superando la trasmissione single-hop che le caratterizza negli impieghi standard domestici. Così come avvenuto per 802.11 è possibile pensare un sistema di trasmis- sione multi-hop affidabile sulla tecnologia PLC attualmente standard de fac- to , Homeplug AV. Obiettivo di questo lavoro di tesi è testare le prestazioni della tecnologia Homeplug AV in diversi scenari e progettare una soluzione di routing basa- ta su quelle già esistenti in campo wireless, per la realizzazione di reti ad- hoc PLC. Per ottenere questo risultato si è partiti dal testing delle prestazioni delle reti Homeplug AV e dalla scoperta delle loro funzionalità di controllo di rete, non ancora standardizzate e perciò non documentate in letteratura. Successivamente si è potuto realizzare una soluzione di routing multi-hop per reti Homeplug AV effettuandone il testing approfondito in diversi sce- nari di rete, in modo da valutarne le reali prestazioni. iv Indice 1 Introduzione 1 2 Le comunicazioni PLC e la tecnologia Homeplug AV 4 2.1 Comunicazioni PLC . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 PLC verso una standardizzazione . . . . . . . . . . . . . . . . 5 2.3 Vantaggi e svantaggi delle comunicazioni PLC . . . . . . . . 6 2.4 Sistemi di trasmissione PLC . . . . . . . . . . . . . . . . . . . 7 2.4.1 Reti PLC a basso voltaggio . . . . . . . . . . . . . . . 8 2.4.2 Lo standard industriale Homeplug AV . . . . . . . . 9 2.5 Sviluppi futuri della tecnologia PLC: lo standard IEEE P1901 15 2.5.1 Le aree di interesse dello standard P1901 . . . . . . . 16 2.5.2 Caratteristiche tecniche delle tecnologie P1901 In-Home e Access . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.6 Critiche alle tecnologie PLC e scenario futuro . . . . . . . . . 19 3 Protocolli e metriche di routing per reti multi-hop 21 3.1 Reti PLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2 Protocolli di routing . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2.1 Lo scenario ad-hoc . . . . . . . . . . . . . . . . . . . . 22 3.2.2 Protocolli reattivi . . . . . . . . . . . . . . . . . . . . . 24 3.2.3 Protocolli proattivi . . . . . . . . . . . . . . . . . . . . 25 3.2.4 Protocolli ibridi . . . . . . . . . . . . . . . . . . . . . . 25 v INDICE vi 3.2.5 Il protocollo OLSR . . . . . . . . . . . . . . . . . . . . 26 3.2.6 Metriche di routing . . . . . . . . . . . . . . . . . . . . 32 4 Routing multi-hop per reti Homeplug AV 35 4.1 La gestione di una rete Homeplug AV . . . . . . . . . . . . . 35 4.1.1 Interfaccia di controllo HPAV . . . . . . . . . . . . . . 36 4.1.2 Le prestazioni di una rete Homeplug AV . . . . . . . 39 4.2 Una soluzione di routing multi-hop . . . . . . . . . . . . . . 50 4.3 OLSR e il routing Multi-hop per reti PLC . . . . . . . . . . . 52 4.3.1 Calcolo della metrica ETT-PLC in reti Homeplug AV 52 4.3.2 Distribuzione delle associazioni IP-MAC_PLC . . . . 54 4.3.3 Integrazione in OLSR . . . . . . . . . . . . . . . . . . 54 5 Implementazione di PLC plugin per OLSR.org 55 5.1 L''architettura software di OLSR.org . . . . . . . . . . . . . . 55 5.1.1 Struttura a plugin e gestione della configurazione . . 55 5.1.2 Plugin link quality e componenti del core di OLSR.org 56 5.2 Realizzazione della soluzione di routing PLC . . . . . . . . . 57 5.2.1 PLC_plugin . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.2 plc_service . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.3 plc_distribution_service . . . . . . . . . . . . . . . . . 59 5.2.4 linklayer_plc_data . . . . . . . . . . . . . . . . . . . . 60 5.2.5 Plugin link quality lq_ETT-PLC . . . . . . . . . . . . . 60 5.2.6 Altri aspetti implementativi . . . . . . . . . . . . . . . 61 5.3 Evoluzioni future . . . . . . . . . . . . . . . . . . . . . . . . . 61 6 Risultati sperimentali 63 6.1 Descrizione del testbed . . . . . . . . . . . . . . . . . . . . . . 63 6.2 Implementazione del testbed . . . . . . . . . . . . . . . . . . 65 6.3 Presentazione dei risultati . . . . . . . . . . . . . . . . . . . . 67 6.3.1 Test: cambiamento multiplo nell''instradamento . . . 67 INDICE vii 6.3.2 Test: cambiamento di una singola rotta . . . . . . . . 70 6.4 Analisi dei risultati . . . . . . . . . . . . . . . . . . . . . . . . 73 7 Conclusioni 74 A Messaggi Homeplug AV 77 Elenco delle figure 2.1 Sviluppo delle tecnologie PLC negli anni ''90 [1, p. 2] . . . . . 6 2.2 Impedenza media di una linea PLC in funzione della frequenza 8 2.3 Organizzazione del periodo di Beacon in Homeplug AV [2, p. 6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4 Caratteristiche dei due livelli PHY previsti nello standard IEEE P1901 [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5 Architettura di IEEE P1901: due livelli PHY con livello di adattamento e MAC comune [3] . . . . . . . . . . . . . . . . . 19 3.1 Differenza tra flooding standard e flooding con il meccanis- mo di MPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1 Struttura generica di un messaggio Homeplug AV . . . . . . 36 4.2 Test 1: adattatori PLC collegati allo stessa multipresa . . . . . 41 4.3 Test 2: adattatori PLC collegati tramite una prolunga da 10 m 42 4.4 Test 3: adattatori PLC collegati tramite una prolunga da 100 m 43 4.5 Test 4: una foto del testbed con interruttore magnetotermico F82XD/16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.6 Test 5: caricabatterie per cellulare collegato in prossimità del trasmettitore PLC . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.7 Test 6: caricabatterie per cellulare collegato e scollegato du- rante la misurazione della latenza . . . . . . . . . . . . . . . . 46 viii ELENCO DELLE FIGURE ix 4.8 Test : throughput TCP in funzione del tempo collegando e scollegando il caricabatterie . . . . . . . . . . . . . . . . . . . 47 4.9 Test 6: asciugacapelli collegato tra i due dispositivi PLC . . . 48 4.10 Test 6: asciugacapelli acceso e spento durante la misurazione della latenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.11 Test : throughput TCP in funzione del tempo accendendo e spegnendo l''asciugacapelli . . . . . . . . . . . . . . . . . . . . 49 4.12 Interpolazione lineare della relazione tra stima Quality di Homeplug AV e il rate UDP effettivamente misurato . . . . . 53 6.1 Il testbed è realizzato con quattro terminali collegati di volta in volta in punti diversi dell''impianto elettrico . . . . . . . . 65 6.2 Prestazioni e topologia di rete. Instradamento diretto. (Valori espressi in [Mbit/s]) . . . . . . . . . . . . . . . . . . . . . . . 68 6.3 Prestazioni e instradamento con OLSR standard (Valori espres- si in [Mbit/s]) . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.4 Prestazioni e instradamento con OLSR ETT-PLC (Valori espres- si in [Mbit/s]) . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.6 Prestazioni e instradamento con OLSR standard (Valori espres- si in [Mbit/s]) . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.7 Prestazioni e instradamento con OLSR ETT-PLC (Valori espres- si in [Mbit/s]) . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Elenco delle abbreviazioni IP Internet Protocol IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force HPAV HomePlug AV AVLN AV Logical Network NID Network Identifier PLCP Physical Layer Convergence Protocol NMK Network Membership Key NPW Network Password NEK Network Encryption Key PB Physical Block PLC Power Line Communications BPL Broadband Power Line DSR Dynamic Source Routing DSDV Destination Sequence Distance Vector x ELENCO DELLE FIGURE xi AODV Ad-hoc On-demand Distance Vector TORA Temporally Ordered Routing Algorithm OLSR Optimized Link State Routing NHDP Neighborhood Discovery Protocol OSPF Open Shortest Path First IS-IS Intermediate System To Intermediate System MPR Multi Point Relay TC Topology Control IANA Internet Assigned Number Authority HNA Host and Network Association MID Multiple Interface Declaration RFC3626 Request For Comments 3626 ETX Expected Transmission Count ETT Expected Transmission Time ETT-PLC ETT-PLC RFC Request For Comments TTL Time to live OLSRv2 OLSRv2 DNS Domain Name Service Capitolo 1 Introduzione Le Power Line Communications (PLC) esistono ormai da decenni ma la loro diffusione si è sempre limitata ad applicazioni specifiche e relegate spesso all''interno delle reti di distribuzione dell''energia elettrica. Agli inizi degli anni ''90 tuttavia si è assistito al primo sviluppo della tec- nologia in ambito domestico con le prime applicazioni a basso rate impie- gate per l''automazione e la domotica. Negli anni 2000 grazie al progresso tecnologico e alla formazione del con- sorzio industriale Homeplug nasce la prima tecnologia di trasmissione PLC a medio-elevato rate dedicata al mercato consumer. Con Homeplug AV nel 2005, si assiste alla sua nuova iterazione, finalmente in grado di fornire prestazioni e affidabilità adeguate. Homeplug AV, che si affaccia su un mondo dominato dalle soluzioni wireless riesce a ritagliarsi una nicchia del mercato. Oggi, dopo che un lungo processo di standardizzazione da parte di IEEE ha portato alla pubblicazione del primo standard ufficiale per comunicazioni PLC domestiche a banda larga P1901, la tecnologia PLC sembra destinata a conoscere una nuova fase di sviluppo caratterizzata da dispositivi sempre meno costosi e dalla loro ubiquità all''interno di altri device elettrici. La prospettiva di una competizione con le tecnologie wireless sembra or- 1 CAPITOLO 1. INTRODUZIONE 2 mai tramontata e gli scenari più interessanti sono quelli che vedono le due tecnologie operare in maniera complementare l''una a fianco dell''altra. Dispositivi in grado di trasmettere sia su PLC che in wireless, reti ibride con segmenti powerline e segmenti radio catalizzano l''interesse di produttori e di costruttori di soluzioni di rete ad-hoc. In questo lavoro di tesi si analizza lo stato dell''arte delle tecnologie PLC, compiendo una fase di test e valutazione di Homeplug AV. L''obbiettivo è quello di proporre una soluzione di routing per reti PLC di tipo multi-hop. Homeplug AV non prevede la possibilità di effettuare trasmissioni multi- hop e quindi l''introduzione di un protocollo di routing che le supporti può contribuire a migliorare le prestazioni della rete. L''introduzione di un meccanismo di tramissione multi-hop è il punto man- cante nelle tecnologie di rete PLC per poter essere assimilate a quelle wire- less ad-hoc e per poter quindi trovare una soluzione comune per problemi simili che possa essere utilizzata anche in reti ibride. I protocolli di routing usati in ambito ad-hoc wireless costituiscono un ot- timo punto di partenza ma è necessario realizzare una soluzione che tenga conto delle caratteristiche della rete PLC e possa trarne il massimo vantag- gio. In questo lavoro di tesi si analizza nel capitolo 2 lo stato attuale delle soluzioni PLC diffuse e quali caratteristiche offrirà lo standard recentemente ratifica- to da IEEE. Nel capitolo 3 si approfondisce la conoscenza della tecnologia Homeplug AV attraverso la creazione e il testing di diversi scenari di rete. Homeplug AV non è una specifica aperta ne i device offrono la possibilità di essere programmati ma grazie all''uso del software open-source Faifa è stato pos- sibile ottenere informazioni sul funzionamento e le prestazioni della rete ed utilizzarle come base per la creazione della nuova metrica di routing. CAPITOLO 1. INTRODUZIONE 3 La metrica proposta è denominata ETT-PLC ed è di tipo capacity-aware. Rappresenta un importante passo avanti nel routing in campo PLC perché non si limita a misurare parametri della rete ''dall''esterno' ma si basa sui dati provenienti direttamente dai device PLC. Il processo di derivazione della metrica da questi dati è descritto e docu- mentato. Il capitolo 4 è dedicato alla descrizione dell''architettura software di OL- SR.org, l''implementazione del protocollo Optimized Link State Routing (OLSR) scelta come base per lo sviluppo della soluzione di routing PLC. Questa è costituita da un plugin generico per OLSR che si occupa prevalen- temente della comunicazione con i device Homeplug AV e delle funzioni accessorie di rete e da un plugin per il calcolo della metrica ETT-PLC. Nel capitolo 6 infine, si mette alla prova la soluzione di routing sviluppata con- frontandola con una rete Homeplug AV classica ed una che utilizza la ver- sione standard di OLSR. Il capitolo 7 trae le conclusioni sul lavoro svolto delineandone i possibili sviluppi futuri. Capitolo 2 Le comunicazioni PLC e la
tecnologia Homeplug AV
2.1 Comunicazioni PLC Il termine PLC (power line communication) denota un insieme di tec- nologie che utilizzano la rete elettrica a medio e basso voltaggio per fornire servizi di telecomunicazione. Nate come una tecnologia a basso rate per sistemi di controllo oggi si sono diffuse anche nel mercato di consumo nelle più recenti versioni che supportano rate elevati (Broadband Power Line (BPL)). La rete elettrica è impiegata da molto per il trasporto di dati di controllo e monitoraggio a basso rate. Proprio la necessità di sviluppare reti elettriche moderne e di connetterle le une alle altre ha portato ad uno sforzo con- giunto degli operatori del settore per la standardizzazione delle tecnologie PLC. Il primo organismo nato per occuparsi di questo processo è stato lo IEC (International Electrotechnical Commission). La nascita del concetto di PLC è da datare sino al 1838 quando l''inglese Ed- ward Davy propose una soluzione per permettere la misura del livello di carica delle batterie di sistemi lontani dalla rete telegrafica. Nel 1897 viene 4 CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 5 depositato il primo brevetto per una tecnica di misura dei livelli della rete elettrica con trasmissione sullo stesso cavo elettrico. Nel 1950 entrano in funzione i primi sistemi PLC noti come Ripple Control, progettati e sviluppati sulle reti elettriche a medio e basso voltaggio. Le fre- quenze delle portanti variavano tra 100 Hz e 1 KHz. Le esigenze principali erano la trasmissione di segnali unidirezionali per il controllo dei sistemi di illuminazione pubblica o per la gestione della tariffazione. Il primo sistema industriale chiamato Pulsadis viene sviluppato in Francia nel 1960. L''impulso per un reale sviluppo delle tecnologie PLC era stato dato dalle conseguenze della Seconda Guerra Mondiale. La devastazione della guerra aveva , lasciato le linee elettriche in uno stato migliore di quelle telefoniche e in generale atte alle comunicazioni, primo obbiettivo strategico. I primi sistemi PLC si svilupparono quindi per necessità e convenienza perché pre- sentavano una condizione di partenza vantaggiosa rispetto alla costruzione ex-novo di reti di telecomunicazione. Ancora oggi questo fattore è uno di quelli trainanti per lo sviluppo e la dif- fusione dei sistemi PLC. A partire dagli anni ''90 i sistemi PLC hanno iniziato a diffondersi anche in ambito privato e domestico per applicazioni di automazione e controllo. 2.2 PLC verso una standardizzazione Esistono diversi organismi che si occupano di standardizzare vari as- petti delle comunicazioni PLC a livello europeo e mondiale. In Europa il ruolo principale è svolto dallo IEC, storicamente responsabile delle tecnologie trasmissive su linee elettriche e dall''ETSI, l''organismo di standardizzazione delle telecomunicazioni. Gli sforzi di standardizzazione hanno permesso di definire dei principi tecnologici che sono poi stati adot- CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 6 Figura 2.1: Sviluppo delle tecnologie PLC negli anni ''90 [1, p. 2] tati dalle tecnologie che hanno di fatto iniziato l''espansione sul mercato. Tecnologie come Homeplug e il più recente Homeplug AV costituiscono uno standard industriale che ha saputo imporsi sul mercato diventando anche uno standard de facto. Non a caso il recentissimo sforzo di standardizzazione compiuto dall''Institute of Electrical and Electronics Engineers (IEEE) si basa proprio sui principi tecnologici di questi standard de facto. Come era già avvenuto per le tecnologie wireless Wi-Fi e la loro standard- izzazione in 802.11, per le BPL lo standard IEEE che canonizza le future tecnologie si chiama P1901 ed è stato pubblicato nel dicembre 2010. 2.3 Vantaggi e svantaggi delle comunicazioni PLC Come ogni sistema reale, PLC presenta sia vantaggi che svantaggi nei confronti delle tecnologie rivali. Tra gli svantaggi c''è la relativa immaturità della tecnologia per quanto riguarda la trasmissione in esterno e per reti di accesso. Nel caso di elevati throughput invece i problemi si manifestano in termini CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 7 di adeguatezza del mezzo trasmissivo e di emissioni elettromagnetiche che possono superare i limiti consentiti dalle norme vigenti e interferire con al- tre tecnologie (es: trasmissioni a medio raggio amatoriali e militari). I principali vantaggi delle PLC invece comprendono il riutilizzo della rete elettrica come mezzo trasmissivo riducendo drasticamente i costi infras- trutturali e la potenzialità di avere una copertura capillare su tutto il terri- torio. Il riutilizzo di apparati esistenti si riflette positivamente anche sulla velocità di realizzazione delle reti PLC che hanno bisogno della sola instal- lazione e configurazione degli apparati trasmissivi. Il fatto di essere una tecnologia cablata poi costituisce un vantaggio in ter- mini di sicurezza contro attacchi di tipo MIM (Man In the Middle), più comuni per le reti wireless. 2.4 Sistemi di trasmissione PLC Le reti elettriche su cui avvengono le trasmissioni PLC sono costituite per la maggior parte da segmenti di conduttori collegati nei modi più etero- genei e la cui principale funzione esula dal trasporto di dati. Per questo motivo il livello fisico di trasporto nelle PLC non è ottimizzato per le telecomunicazioni ed è necessario prevedere un sistema di trasmis- sione molto robusto. Le reti elettriche sono classificate a seconda del loro voltaggio in reti a voltaggio basso (tensioni inferiori ai 240V), medio (tensioni dell''ordine dei 20000V) e alto (superiori ai 65000V). Per realizzare comunicazioni PLC sui vari tipi di reti sono necessari sistemi di trasmissione anche molto diversi. Nell''interesse del nostro lavoro, focalizzato sulle tecnologie di trasmissione per il mercato privato analizzeremo più approfonditamente le comunicazioni PLC su reti a basso voltaggio. CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 8 Figura 2.2: Impedenza media di una linea PLC in funzione della frequenza 2.4.1 Reti PLC a basso voltaggio Il mezzo fisico di queste reti è costituito da linee elettriche che trasportano corrente elettrica a 110V e 60 Hz nei sistemi americani e 220V a 50 Hz nei sistemi europei. Le linee elettriche sono caratterizzate da un''impedenza Z che varia con- tinuamente in funzione della posizione nella rete e del tempo. I dispositivi elettrici vengono connessi e disconnessi causandone fluttuazioni continue e rendendo difficile la modellizzazione del canale. L''impedenza di un dispositivo inoltre può cambiare in funzione delle carat- teristiche progettuali, della modalità di utilizzo, dell''invecchiamento. La mancanza di adattamento tra le linee produce riflessioni e propagazioni multipath che causano fading e attenuazioni variabili. Ogni dispositivo elettrico presente sulla linea rappresenta anche una sorgente di rumore che si estende ad alte frequenze nelle bande utilizzate dai sistemi PLC. Lampade alogene e ad incandescenza, interruttori dimmer producono dis- turbi di tipo impulsivo e periodico. CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 9 I dispositivi a motore elettrico producono disturbi di tipo impulsivo con distribuzione casuale. La posizione delle sorgenti di rumore e l''attenuazione spaziale del rumore stesso causano forti asimmetrie nel canale PLC, che raramente quindi può offrire le stesse prestazioni in ambedue i sensi. Per le reti a basso voltaggio le bande utilizzate vanno dai 3 ai 148 KHz per le trasmissioni a basso rate e tra gli 1 e 30 Mhz per quelle ad alto rate. Queste bande sono libere da licenze ma possono essere utilizzate solo rispettando i limiti di potenza emissiva stabiliti da ETSI in Europa e da FCC negli Stati Uniti. Gli organismi di regolamentazione stabiliscono anche quali siano i livelli limite di disturbo radio che un device PLC può emettere per effetto di in- duzioni all''interno delle linee elettriche. Questi segnali radio possono interferire con sistemi di comunicazione ra- dio amatoriali e le trasmissioni broadcast di radio digitali. I dispositivi PLC venduti sul mercato sono già configurati per aderire a queste limitazioni e non prevedono la possibilità di modificare le emissioni all''interno delle bande protette dalla regolamentazione. I device Homeplug ad esempio, non permettono di accedere direttamente al canale fisico PLC ma offrono solo un''interfaccia di configurazione tramite lo scambio di trame ethernet che da accesso esclusivamente alle funzional- ità di rete, di crittografia e permette di consultare le impostazioni usate dal sistema di trasmissione sul canale PLC, senza però poterle modificare. 2.4.2 Lo standard industriale Homeplug AV Le reti elettriche vengono viste dalle comunicazioni PLC come un mez- zo condiviso utilizzabile da tutti i dispositivi per inviare e ricevere dati. Per implementare un sistema completo di trasmissione è necessario oc- cuparsi della trasmissione del canale fisico, del meccanismo di accesso al CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 10 mezzo trasmissivo e delle funzionalità di livello rete per mettere in comu- nicazione i dispositivi. Homeplug è lo standard industriale nato nel 2001 con l''obiettivo di soddis- fare questi requisiti e diffondere la tecnologia PLC a livello domestico. L''obiettivo è stato raggiunto ma lo standard, con un rate lordo a livello fisi- co di soli 14 Mb/s ha mostrato rapidamente le sue limitazioni nel soddis- fare la sempre maggiore richiesta di banda per applicazioni multimediali. L''ultima versione dello standard, rilasciata nel 2005 risolve queste limi- tazioni introducendo un livello fisico con rate di 200 Mb/s e modificando i meccanismi di gestione della rete per renderli più efficienti. 2.4.2.1 Il livello fisico Homeplug AV opera a livello fisico sul canale PLC nelle frequenze tra i 2 e i 30 MHz. Viene utilizzato un robusto meccanismo di modulazione OFDM che divide la banda in 1155 sottoportanti. Di queste però solo 917 sono attive e le al- tre vengono mascherate per ragioni di compatibilità con le normative sulle emissioni elettromagnetiche.[4] La configurazione delle diverse portanti è chiamata Tone Map ed è config- urabile nel firmware di ogni dispositivo.[2] Per la correzione degli errori a livello fisico è impiegato un codice FEC di tipo Turbo con lo scopo di recuperare le trame fino a rendere il livello MAC funzionale. Il recupero degli errori tramite ritrasmissione viene poi effet- tuato dal MAC stesso.[4] Ogni sottoportante OFDM può essere modulata con BPSK, QPSK, 8-QAM, 16-QAM, 64-QAM, 256-QAM o 1024-QAM a seconda del livello di SNR che viene riscontrato su di essa. In questo modo si ottiene un utilizzo dello spettro estremamente granulare ed efficiente. CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 11 N.Portanti * Bit Per Portante * FEC * Rate di Simbolo = 1155 * 10 * (3/4) * (1/Tempo di simbolo) Con 917 portanti attive nel Tone Map di Homeplug AV e considerando ognuna modulata con 1024 QAM (10 bit per simbolo). Il rate del canale diventa 10 * 917 = 9170 bit per tempo di simbolo. Il tempo di simbolo è l''inverso della spaziatura delle portanti (1/24400 Hz = 41 µs) sommato all''intervallo di guardia, pari a 5,5 µs. [5] Quindi il massimo bitrate raggiunto dal canale è: N. portanti ' bit per portante T empo di simbolo = 917 ' 10 46, 5 µs '' 197 M bps (2.1) Il sistema Homeplug utilizza la frequenza della portante elettrica come sistema di sincronizzazione tra stazioni. Il periodo di trasmissione occupa due cicli della portante elettrica e dura quindi 33,33 ms sulle reti Statuniten- si e 40 ms su reti Europee. 2.4.2.2 Il livello MAC Protocolli e servizi Il livello MAC in HomePlug AV (HPAV) fornisce un meccanismo di accesso privo di contesa (Contention Free, CF) in grado di garantire i requisiti minimi di jitter e latenza ad applicazioni Audio/Video. Se Homeplug prevedeva una comunicazione peer-to-peer tra stazioni con accesso al canale regolato dal protocollo CSMA/CA senza una organiz- zazione gerarchica della rete, in Homeplug AV invece la struttura della rete diventa centralizzata, con una delle stazioni che assume il ruolo di Central Coordinator (CCo). L''accesso al mezzo è regolato da un meccanismo TDMA usato per allo- cazioni di banda garantita in parallelo ad un sistema CSMA/CA usato per i servizi Best Effort e per la coesistenza con reti Homeplug 1.0. La sincronizzazione di questo schema è ottenuta attraverso trame di Beacon trasmesse dal Coordinatore della rete. Il Beacon stabilisce i limiti temporali CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 12 Figura 2.3: Organizzazione del periodo di Beacon in Homeplug AV [2, p. 6] della regione di accesso a contesa e di quella senza contesa e assegna le allocazioni di slot di trasmissione in quest''ultima. Le allocazioni possono durare per diversi periodi di Beacon in modo da poter garantire l''accesso anche in caso di mancata ricezione dei Beacon stessi. Per gestire la qualità del servizio il traffico viene classificato da un livel- lo superiore (Higher Level Entity) che assegna un''etichetta CSPEC (simile al TSPEC di 802.11) che descrive le caratteristiche che il trasporto deve sod- disfare per un particolare flusso (banda richiesta, jitter massimo, latenza, basso tasso d''errore). Il CCo riceve una richiesta di trasmissione e basandosi su CSPEC e sulla qualità rilevata sul canale assegna gli slot trasmissivi. Le comunicazioni tra stazioni avvengono in maniera diretta ma il CCo as- colta comunque i messaggi trasmessi in modo da poter tenere aggiornate le allocazioni di banda ed eventualmente modificarle se la coda di un flusso cresce troppo. CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 13 Data Plane Il livello MAC nelle comunicazioni PLC broadband non può usare lo stesso approccio applicato nelle comunicazioni narrowband. Ser- vono accorgimenti per ridurre l''overhead delle trame MAC e renderlo più robusto agli errore di carattere impulsivo in modo da aumentarne l''efficien- za. Il MAC di Homeplug AV presenta uno schema di incapsulamento a due livelli, in cui al primo livello i dati racchiusi nelle MAC Service Data Units (MSDUs) vengono inseriti in una trama con un minimo overhead e suc- cessivamente il flusso bitstream composto dalla sequenza di queste trame viene suddiviso e incapsulato in vere e proprie trame da passare al livello fisico. L''header di questi PHY Blocks (PB) garantisce la ricostruzione del flusso corretto in caso di dati trasmessi fuori ordine e la risincronizzazione in caso una parte del bitstream MAC sia andata persa.[6] Il ruolo del Coordinatore CCo In Homeplug AV esiste il concetto di AV Logical Network (AVLN), una associazione logica tra stazioni che opera- no sullo stesso canale PLC. Ogni rete logica è caratterizzata da una chiave di crittografia Network Membership Key (NMK). Una stazione per poter comunicare in una AVLN deve obbligatoriamente conoscere la NMK as- sociata. In ogni AVLN una delle stazioni assume il ruolo di Coordinatore (CCo), con le funzioni di scoprire e memorizzare la topologia della rete e di effettuare l''Admission Control per il traffco delle stazioni. Una stazione diventa CCo se è anche la stazione che crea la rete logica AVLN ma succes- sivamente in caso appaia una stazione con collegamento migliore alle altre è prevista una procedura di handover per trasferire il ruolo di Coordina- tore. Ogni stazione della rete mantiene una lista delle stazioni (Discovered Sta- tion List, DSL) e una delle AVLN che riesce a sentire sul canale. Periodica- mente e in momenti stabiliti dal CCo la stazione distribuisce queste infor- CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 14 mazioni con una trama di Beacon Discovery. Attraverso i Beacon Discovery ricevuti dalle altre stazioni il CCo impara la topologia della rete e la stima della qualità del canale tra le varie stazioni. Una stazione che non riesca a comunicare con il Coordinatore può lo stesso entrare a far parte di un AVLN dal momento che è prevista una funzione di proxy per i messaggi di controllo. Il ruolo di proxy viene assunto da una stazione intermedia che riesca a comunicare con entrambe. La funzione di proxy è prevista solo per i messaggi di controllo e per scam- biare dati due stazioni devono necessariamente essere in grado di sentirsi a vicenda. Sicurezza Per poter entrare in una AVLN una stazione deve conoscerne la chiave di rete NMK. NMK è una chiave AES a 128 bit ottenuta tramite hashing da una password Network Password (NPW). Una volta nota la NMK una stazione entra a far parte della rete logica e riceve la chiave di crittografia Network Encryption Key (NEK) che usa per lo scambio dati con altre stazioni. La crittografia è sempre basata su AES a 128 bit.[']
La specifica prevede anche la possibilità di ottenere NMK attraverso uno scambio protetto da crittografia a chiave pubblica senza conoscere la pass- word NPW. Questo meccanismo intrinsecamente meno sicuro dal momen- to che ogni stazione HPAV in grado di attivare questa procedura può en- trare a far parte della rete è solitamente realizzato con un pulsante presente su tutti i dispositivi. La pressione del pulsante su un dispositivo già associato alla rete e sul dispositivo che vuole associarsi attiva la procedura a chiave pubblica. Coesistenza di multiple reti Se più di una rete logica AVLN è presente sullo stesso canale PLC i Coordinatori delle rispettive reti comunicano per coordinare le diverse trasmissioni. Si stabilisce nel periodo di Beacon una CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 15 parte riservata ad ogni rete e un''allocazione del Contention Free Period di ogni rete in modo che non si sovrappongano e che la banda sia ugualmente ripartita. La regione di accesso a contesa rimane invece condivisa e le stazioni di diverse reti competono tra loro per trasmettere sul canale. Per un CCo è possibile allocare una banda superiore alla quota destinata alla sua AVLN se questa è disponibile ma deve immediatamente cercare di rinegoziare le sue allocazioni e rientrare nella quota qualora la bande in eccesso occupata fosse richiesta da un''altra AVLN a cui spetta. 2.5 Sviluppi futuri della tecnologia PLC: lo standard IEEE P1901 Come avvenuto per le tecnologie wireless sviluppatesi in campo do- mestico a partire da uno standard industriale e solo dopo standardizzate da IEEE in 802.11, anche le comunicazioni PLC hanno attraversato questo percorso. Il 30 dicembre 2010 il gruppo P1901 ha concluso il lungo percor- so iniziato nel 2005 ed ha pubblicato la versione definitiva dello standard P1901. Lo standard comprende le tecnologie PLC che riguardano il campo domes- tico ma anche sistemi BPL pensati per la realizzazione di reti di accesso PLC su reti di distribuzione elettrica. A supportare lo standard hanno contribuito le più grandi aziende oper- anti nel settore delle PLC (Panasonic, Intellon, DS2) garantendone l''au- torevolezza e la sicurezza del supporto del mercato. La presenza di grandi aziende che già sviluppano sistemi PLC ha però complicato la definizione dello standard viste le differenti spinte all''utilizzo delle proprie tecnologie che ogni azienda ha portato. Come vedremo questo si riflette soprattutto nelle scelte tecnologiche fatte per il livello fisico di P1901. CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 16 2.5.1 Le aree di interesse dello standard P1901 Per poter realizzare l''obbiettivo ambizioso di riunire in uno standard le tecnologie PLC a scopi diversi (reti domestiche, reti d''accesso, applicazioni di gestione delle reti elettriche) il Working Group P1901 si è diviso in tre aree di lavoro specifiche: ' In-home (IH): si occupa di definire i requisiti tecnologici per reti a basso voltaggio di tipo domestico. ' Access (AC): si occupa dei requisiti per le applicazioni a basso e medio voltaggio realizzate sulla rete di distribuzione elettrica. ' Coexistence (CX): realizza la tecnologia che permette a device PLC basati su diverse tecnologie di coesistere condividendo il mezzo fisico. 2.5.2 Caratteristiche tecniche delle tecnologie P1901 In-Home e Access 2.5.2.1 Il livello fisico in P1901 La definizione della tecnologia di trasmissione sul canale in P1901 è stata caratterizzata dallo scontro tra le tecnologie concorrenti sul mercato portate dal consorzio Homeplug Alliance e dal colosso giapponese Pana- sonic (HD-PLC). La versione definitiva dello standard pertanto non sceglie esplicitamente tra queste due tecnologie ma definisce due possibili livel- li PHY, uno basato su FFT-OFDM e derivante da Homeplug e uno basato sulla versione wavelet di OFDM modellato su HD-PLC. CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 17 Livello fisico basato su FFT OFDM La versione del livello fisico basato su FFT e OFDM inclusa in P1901 ricalca molto fedelmente quella usata in Homeplug AV. Le differenze principali sono dovute alla maggiore banda prevista per il canale PLC che ora si estende da 1.8 MHz a 48 MHz ed è diviso in 1893 sottoportanti. Le frequenze al di sopra dei 30 MHz sono opzionali e in successive versioni dello standard è prevista la possibilità di arrivare fino ad 80 MHz. Al momento esistono soluzioni commerciali in uscita sul mercato che implementano già questa estensione allargando il canale fino a 75 MHz.[7] Per ampliare ulteriormente la larghezza di banda è prevista la possibilità di usare in ogni sottoportante una modulazione fino a 4096-QAM, dove Homeplug AV supportava solo fino a 1024-QAM. In questo modo il rate lordo raggiungibile dal canale sale fino a 400-500 Mbps a seconda della banda considerata. Livello fisico basato su Wavelet OFDM Il livello fisico basato sulla trasfor- mata Wavelet e OFDM divide la banda tra 2 e 30 Mhz in 512 portanti spazi- ate uniformemente. Su ogni portante è impiegata una modulazione di tipo M-PAM (con M = 2, 4, 8, 16, 32). La trasformata Wavelet, grazie all''utilizzo di finestre non rettangolari, rag- giunge un maggiore grado di sovrapposizione spettrale e può impiegare modulazioni a rate più basso sulle singole portanti pur mantenendo la stes- sa efficienza spettrale del sistema FFT OFDM. Lo schema FEC obbligato- rio utilizzato è un codice convoluzione Reed-Solomon con la possibilità di implementare un codice LDPC lasciate come opzionale.[8] Il protocollo inter-PHY Il protocollo inter-PHY (IPP) è un framework di coesistenza pensato per il funzionamento in parallelo di device con livello fisico differente, non solo all''interno di P1901 ma anche per altre tecnologie PLC incompatibili. CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 18 Figura 2.4: Caratteristiche dei due livelli PHY previsti nello standard IEEE P1901 [3] E'' importante anche perché fornirà alle future generazioni di tecnologie P1901 che saranno basate verosimilmente su un livello fisico diverso (PHY NG) la modalità per interoperare con l''attuale versione di P1901. Il protocollo IPP definisce un insieme di semplici segnali usati dalle stazioni PLC per sincronizzarsi e segnalarsi le une alle altre. L''IPP definisce un sistema TDMA in cui il canale è usato da tecnologie PLC diverse in diverse finestre temporali. Le finestre temporali sono chiamate TDMU (TDM Unit) e sono a loro volta divise in slot. Ogni finestra temporale TDMU ha una durata sincronizzata con 2 cicli della portante elettrica. Il riutilizzo degli slot trasmissivi Una feature di P1901 che non è pre- sente in nessun precedente dispositivo PLC è la possibilità di utilizzare lo stesso slot di trasmissione contemporaneamente per due trasmissioni dis- tinte nella stesa rete logica o in reti distinte. Questo è reso possibile dalla caratteristica del canale PLC che a causa di at- CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 19 Figura 2.5: Architettura di IEEE P1901: due livelli PHY con livello di adattamento e MAC
comune [3] tenuazioni tra due parti distinte della rete può rendere le due trasmissioni contemporanee indipendenti e prive di collisione. Il livello MAC e il livello di adattamento Il livello MAC definito in P1901 è derivato direttamente da Homeplug AV e ne presenta tutte le caratteris- tiche già discusse in precedenza. La particolarità introdotta in P1901 è la presenza di un livello intermedio di adattamento Physical Layer Convergence Protocol (PLCP) tra il MAC e il livello fisico, diverso a seconda del livello fisico impiegato. I due livelli di adattamento prendono il nome di O-PLCP e W-PLCP. 2.6 Critiche alle tecnologie PLC e scenario futuro Con la fase di standardizzazione finalmente giunta a termine sembra che le comunicazioni PLC siano destinate a diffondersi nel mercato con- sumer e a espandersi oltre la nicchia che già occupano. CAPITOLO 2. LE COMUNICAZIONI PLC E LA TECNOLOGIA HOMEPLUG AV 20 Un altro possibile settore di espansione e il più interessante ai fine di questo lavoro di tesi è costituite dall''impiego delle PLC all''interno di reti mesh come complemento delle tecnologie wireless. Questa soluzione verrà det- tagliata nel capitolo 4. Oltre all''ottimismo sviluppatosi anche come conseguenza del processo di standardizzazione, non sono però mancate delle critiche. La versione 1.0 dello standard è vista da alcuni come un fallimento per l''incapacità di trovare un compromesso sul livello fisico da utilizzare e il conseguente inserimento di due tecnologie non in grado di interoperare tra loro. Altri notano invece come sia pratica comune per gli standard IEEE definire livelli fisici incompatibili e che le prestazioni e il mercato daranno la risposta su quale tecnologia potrà prevalere.[9] Capitolo 3 Protocolli e metriche di routing
per reti multi-hop
3.1 Reti PLC Come visto nel capitolo 2 4, le reti PLC utilizzano molte tecnologie (dal livello fisico all''accesso al mezzo) già impiegate nelle reti wireless. Anche a livello delle topologie di rete c''è un forte parallelismo tra le due tecnologie. Considerando infatti l''architettura che si crea nelle reti Home- plug AV e il ruolo svolto dalla stazione Coordinatore possiamo notare la forte analogia con un sistema 802.11e in modalità Infrastructure BSS e il relativo Access Point. In entrambe i sistemi le comunicazioni vengono regolate dal Coordinatore e dall''AP ma il traffico dati tra stazioni avviene in maniera diretta senza l''intermediazione di un entità centrale. La variabilità del canale PLC inoltre può portare a una continua modifica della topologia di rete richiamando scenari tipici delle reti wireless ad-hoc. Nelle reti PLC, per la realizzazione di topologie più complesse si ricorre a un sistema di ripetizione che può avvenire con un dispositivo che rigenera il segnale PLC solo a livello fisico (ripetitore attivo) oppure tramite l''utilizzo 21 CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 22 di due chip PLC in parallelo, uno usato per la ricezione del segnale pri- ma che sia troppo degradato e uno per ripeterlo in linea (ripetitore passivo). In quest''ultimo caso la ripetizione avviene sia a livello fisico che a livello MAC. [1, p. 145] Si può pensare un''altra forma di ripetizione passiva che invece di utilizzare due chip PLC ne impiega uno soltanto, portando il sistema di ripetizione ad un livello superiore nello stack, quello di rete. In questo modo la trasmissione presenta le stesse caratteristiche di una trasmissione multi-hop in reti ad-hoc wireless. Diventa quindi naturale riutilizzare tecnologie e soluzioni sviluppate per la trasmissione multi-hop in ambito radio anche sulle reti elettriche. In questo capitolo si analizzano queste tecnologie con particolare atten- zione per i protocolli di routing e le metriche per la valutazione dei link di una rete. 3.2 Protocolli di routing In questa sezione si descrivono gli aspetti fondamentali legati all''in- stradamento in una rete con percorsi multi-hop e topologia variabile. Si illustreranno i diversi approcci al problema dell''instradamento e si anal- izzerà in particolare il protocollo Optimized Link State Routing (OLSR). Successivamente si descriveranno le principali metriche per la valutazione dei link e l''impatto che possono avere sugli obbiettivi e le prestazioni del- l''instradamento. 3.2.1 Lo scenario ad-hoc Una rete ad-hoc è un''insieme magliato di nodi privo di una topolo- gia predeterminata. In PLC la forte attenuazione e il disturbo difficilmente prevedibile riscontrabile in rete spesso non permette la comunicazione di- CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 23 retta tra tutti i dispositivi. Per poter comunicare, coppie di dispositivi non in visibilità devono appoggiarsi a nodi intermedi, realizzando una comu- nicazione multi-hop. Il compito di determinare a quali nodi intermedi de- vono essere mandati i messaggi per l''inoltro è svolto dal protocollo di rout- ing. La necessità di trovare soluzioni al problema dell''instradamento diverse da quelle classiche nasce proprio dalle particolarità delle reti ad-hoc: ' Risorse di rete limitate: la limitata disponibilità di banda nel canale e la competizione per l''accesso al mezzo rendono di primaria im- portanza limitare l''impatto che i messaggi di controllo per realizzare l''instradamento hanno sulla rete. ' Trasmissione multi-hop: rispetto ad una rete tradizionale la trasmis- sione multi-hop presenta problemi maggiori dovuti alla difficoltà di determinare la rotta migliore nella rete, alla minore affidabilità dei link e ai maggiori ritardi introdotti da ogni singolo hop. Per questo motivo è importante che l''instradamento tenga conto della qualità dei link e non soltanto del numero di hop perché i link possono anche essere molto diversi l''uno dall''altro. ' Topologia variabile: la natura delle reti wireless e PLC è tale che un link può smettere di funzionare, rendendo necessario un meccanis- mo per determinare velocemente rotte alternative che consentano co- munque la comunicazione tra tutte le stazioni. Esistono diversi ap- procci a questo problema ma tutti devono tenere conto del trade- off che esiste tra la velocità di reazione ai cambiamenti della rete e l''economicità in termine di risorse richieste del protocollo di routing. ' Risorse degli apparati limitate: i dispositivi per ragioni di economic- ità e consumi energetici non dispongono di capacità di calcolo illimi- CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 24 tate. Alcuni dispositivi potrebbe essere alimentati a batteria rendendo ancora più rigidi i limiti di consumo del sistema. ' Scalabilità: la rete deve prevedere possibilità di ampliamento future ed è necessario che le prestazioni non ne risentano. In una rete PLC, in cui il mezzo condiviso è utilizzato a turno ma senza divisione in canali come nelle reti wireless, la scalabilità diventa un obbiettivo più difficile da raggiungere e tecnologie come il riuso degli slot trasmis- sivi previsto in P1901 [paragrafo nel capitolo 1] sono fondamentali per la sua realizzazione. Tutti i fattori esposti hanno determinato l''esistenza di due principali ap- procci al problema del trade-off tra prestazioni del protocollo di routing e sua onerosità in termini di risorse di rete. Queste due famiglie sono costituite da i protocolli reattivi e da quelli proat- tivi. 3.2.2 Protocolli reattivi Questi protocolli si occupano di ottenere una rotta di instradamento so- lo in seguito ad una richiesta di trasmissione. In questo modo solo le rotte realmente necessarie vengono calcolate, lasciando la rete completamente scarica, se non c''è necessità di trasmissione. Tuttavia in casi dove la topolo- gia di rete varia spesso ed in presenza di numerosi sessioni di traffico, per poter ottenere le rotte necessarie un protocollo di tipo reattivo potrebbe es- sere troppo oneroso. L''altro svantaggio dell''approccio reattivo è la maggiore latenza dovuta al calcolo della rotta che avviene prima di ogni trasmissione dati. Le prestazioni di un protocollo reattivo possono essere migliorate implementando un mec- canismo adeguato di caching delle rotte. I principali protocolli reattivi sono: Dynamic Source Routing (DSR), Ad- CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 25 hoc On-demand Distance Vector (AODV), BABEL, Temporally Ordered
Routing Algorithm (TORA). 3.2.3 Protocolli proattivi L''approccio proattivo è direttamente derivato dai protocolli di routing per reti tradizionali cablate. Il mantenimento di tutte le rotte per la real- izzazione dell''instradamento è effettuato grazie alla diffusione di infor- mazioni sulla topologia della rete. I messaggi di routing non contengono quindi singole rotte ma informazioni sullo stato dei link (protocolli link state) che permettono ad ogni singolo nodo di conoscere la topologia. Tutti i cammini possibili sono calcolati indipendentemente dal loro uso. Poiché le informazioni vengono generalmente memorizzate in tabelle di routing, questi protocolli vengono anche chiamati Table-Driven. I principali protocolli proattivi comprendono Destination Sequence Dis- tance Vector (DSDV) e l''ampia famiglia di protocolli link-state dei quali Optimized Link State Routing (OLSR) è senz''altro il più noto e diffuso. 3.2.4 Protocolli ibridi Le caratteristiche dei protocolli di routing reattivi e proattivi possono essere combinate in vari modi per ''costruire' protocolli di routing ibridi. Un nodo che impiega un protocollo ibrido effettua verso i nodi vicini una richiesta di routing attraverso un protocollo proattivo. Per i nodi lontani, invece, utilizza un protocollo reattivo. I protocolli ibridi cercano di limitare gli svantaggi peculiari sia dei protocolli reattivi sia dei protocolli proattivi: infatti, abbassano l''overhead introdotto dai protocolli proattivi per man- tenere aggiornate le tabelle di routing; limitano la latenza, dovuta ai proto- colli reattivi, che devono calcolare un nuovo percorso prima di iniziare una trasmissione. CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 26 3.2.5 Il protocollo OLSR Uno dei protocolli proattivi per reti ad-hoc più testati e diffusi nasce in Francia come progetto di ricerca del gruppo HINRIA con il nome di OLSR. [10] OLSR è un protocollo table-driven della famiglia link-state ma rispet- to ai protocolli per reti cablate come Open Shortest Path First (OSPF) e Intermediate System To Intermediate System (IS-IS) introduce delle ottimiz- zazioni fondamentali. Nei classici sistemi link state pensati per reti statiche, ogni link visto da un nodo viene incluso nei messaggi di controllo utilizzati per diffondere la topologia della rete. In OLSR invece solo i link verso una particolare categoria di nodi vicini, i Multi Point Relay (MPR), vengono diffusi. In questo modo si limita la dimensione dei messaggi di controllo e la complessità della loro elaborazione. L''altra ottimizzazione riguarda l''i- noltro dei messaggi di controllo, che non viene fatto da tutti nodi vicini ma solo da quelli eletti come MPR. In OLSR si utilizzano i concetti di Neighbor- hood , l''insieme dei vicini di un nodo e di Two Hop Neighborhood, costituito dai vicini dei vicini di un nodo. L''insieme degli MPR varia per ogni no- do ed è costituito da un sottoinsieme di Neighborhood tale da permettere di raggiungere tutti i nodi nel Two Hop Neighborhood del nodo considerato.[10] L''inoltro dei messaggi viene effettuato comunque con un meccanismo di flooding broadcast ma solo i nodi MPR li ritrasmettono. OLSR scambia continuamente le informazioni sulla topologia della rete e ogni nodo le utilizza per calcolare ed aggiornare la propria tabella di routing. 3.2.5.1 I messaggi di controllo di OLSR I messaggi di controllo sono mandati in broadcast, utilizzando UDP come trasporto sulla porta 698, riservata per OLSR da Internet Assigned CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 27 Figura 3.1: Differenza tra flooding standard e flooding con il meccanismo di MPR Number Authority (IANA). Le tipologie di messaggio previste sono: ' HELLO: A questo messaggio è demandata la fase di Network Sensing con la quale un nodo viene a conoscenza dei vicini. Una volta iniziata la Network Sensing un nodo può eleggere quali saranno i suoi MPR. ' Topology Control: ' un messaggio di tipo link state. La sua funzione è quella di dif- fondere in rete le informazioni sulle caratteristiche dei collegamenti e sull''identità dei nodi vicini al mittente. Grazie alla tecnica di inoltro MPR viene ricevuto da ogni nodo della rete stessa. ' Multiple Interface Declaration: E'' utilizzato nel caso OLSR sia attivo su più interfacce dello stesso nodo. Serve nella fase di link sensing per accomunare destinazioni con indirizzi diversi ma appartenenti allo stesso nodo. Terminato lo scambio MID un nodo rimane noto in rete per il suo Main Address , l''indirizzo IP di una delle sue interfacce. CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 28 Il Main Address è utilizzato quindi come unico indirizzo per la fase di routing. 3.2.5.2 Il funzionamento di OLSR La prima fase è quella di Neighbor Sensing ed è basato sullo scambio di messaggi HELLO. In ognuno di questi un nodo include i vicini già conosciu- ti. Una volta completato con successo lo scambio di messaggi HELLO tra due vicini, questi si conosceranno a vicenda e avranno stabilito che tra loro es- iste un link simmetrico. I messaggi HELLO svolgono anche la funzione di link sensing e pertanto vengono spediti distintamente su ogni interfaccia dove opera OLSR. Sem- pre attraverso i messaggi di HELLO un nodo può popolare il database dei Two Hop Neighbors . Un messaggio di HELLO non viene mai ritrasmesso. Nella seconda fase, quella di link-state flooding, le informazioni sulla topolo- gia della rete vengono diffuse per mezzo dei messaggi Topology Control (TC). A differenza di un protocollo classico come IS-IS, che utilizza l''ag- gregazione e diffonde appena possibile delle subnet al posto di singoli host, i messaggi TC di OLSR contengono una semplice lista di nodi. (flat rout- ing )[11] Il messaggi TC vengono inoltrati in broadcast e ritrasmessi dai propri MPR. In alcuni casi, per rendere la rete più robusta ed evitare la formazione di loop anche i nodi non selezionati come MPR possono ritrasmettere le in- formazioni di routing. La terza fase è costituita dal calcolo delle rotte mediante un algoritmo clas- sico dei cammini minimi in cui tutti i link hanno lo stesso costo.[10] Le funzionalità ausiliarie Quelle descritte fino ad ora costituiscono le funzionalità standard di OLSR che ogni implementazione valida deve possedere. CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 29 La RFC prevede anche una serie di funzionalità ausiliare che completano il protocollo e lo rendono robusto in scenari di applicazione reali: ' Accesso Esterno HNA: Un requisito molto importante per una rete ad-hoc è la possibilità di essere connessa ad altre reti anche di diverso tipo. Per annunciare le informazioni di routing relative a reti e host esterni al dominio di fun- zionamento di OLSR si impiegano dei messaggi di Host and Network Association (HNA). Un messaggio HNA è costituito da una lista di reti e maschere di rete e dall''indirizzo del nodo OLSR che si annuncia come gateway verso esse. ' Notifiche di livello Link-layer: OLSR basa la sua fase i link-sensing sugli scambi di messaggi a livello IP. Questa estensione prevede che si possano utilizzare informazioni di basso livello provenienti direttamente dalle interfacce del sistema come fonte per il link-sensing. ' Isteresi: Meccanismo basato su soglie stabilite sulla qualità dei link utile per rallentarne il cambiamento di stato ed evitare modifiche troppo re- pentine della topologia della rete. ' Ridondanza nei messaggi TC: Per rendere più robusta la topologia della rete è possibile per un no- do inserire nei messaggi di link-state (TC) anche dei vicini non eletti come MPR, di fatto rendendo la rete più densa e ridondante e quindi robusta a scapito della leggerezza del protocollo. ' Ridondanza dei MPR: Similmente alla funzionalità precedente, questa ridondanza garan- CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 30 tisce una maggiore robustezza della rete. In questo caso sono i no- di MPR a essere ridondanti, con più MPR del necessario eletti per diffondere più capillarmente la topologia della rete. 3.2.5.3 OLSRd: un''implementazione free software di OLSR L''implementazione attualmente più diffusa di OLSR è quella creata nel 2004 da Andreas Tønnesen per la sua tesi di dottorato presso l''università di Oslo. L''implementazione rilasciata immediatamente come codice open-source e disponibile presso http://OLSR.org ha attirato l''interesse delle comu- nità wireless mesh di un po'' tutto il mondo. Il progetto Freifunk, una comu- nità wireless tedesca estesa su centinaia di nodi, ha adottato questa imple- mentazione come propria principale soluzione di routing contribuendone allo sviluppo e fornendo il testbed fondamentale per dimostrare che OLSR fosse adatto anche a gestire reti di grandi dimensioni. Il lavoro svolto nello sviluppo di OLSR.org ha evidenziato come la sem- plice implementazione della RFC3626 non fosse sufficiente ad ottenere un protocollo performante e scalabile. L''implementazione di OLSR.org è quella utilizzata in questo lavoro di tesi e ne analizziamo pertanto le particolarità. Differenze tra la RFC3626 e l''implementazione di OLSR.org La comu- nità Freifunk dopo aver adottato OLSR ha potuto determinare che l''imple- mentazione della RFC3626 mostrava i seguenti problemi: ' Metrica Hop Count: l''utilizzo esclusivo di una metrica di hop count porta alla selezione di link a basse prestazioni massimizzando la probabilità di perdita. ' Isteresi e MPR: per minimizzare il numero di MPR vengono selezionati nodi lontani CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 31 e con alta probabilità di perdita che per il meccanismo di isteresi sono facilmente estromessi dalle tabelle di routing. A questo punto è necessario rinegoziare gli MPR e ricostruire le tabelle di routing. ' Routing Loops: possibile creazione di loop nella rete che rendono alcune destinazioni irraggiungibili. Le soluzioni trovate riguardano principalmente l''utilizzo di una nuova metrica in sostituzione del semplice hop count e alcune sostanziali modi- fiche al meccanismo di diffusione dei messaggi di link-state. La metrica di hop-count, inadeguata nel selezionare i percorsi ad elevato throughput è sostituita dalla metrica Expected Transmission Count (ETX).[12, p. 12] Il cambiamento nella distribuzione dei messaggi link-state nasce dai prob- lemi di loop riscontrati nel testbed Freifunk. I loop si formavano tra nodi adiacenti indicando una scarsa affidabilità dei messaggi TC. La soluzione banale sarebbe stata aumentare la frequenza dei messaggi TC ma questo avrebbe portato ad un livello di traffico di controllo inaccettabile dal mo- mento che questi messaggi vengono ritrasmessi in tutta la rete e sono generati con il TTL massimo (255). La soluzione attuata prevede di generare TC con TTL e frequenze diverse in modo da poter aggiornare le informazioni nei nodi adiacenti con maggiore frequenza senza sovraccaricare il resto della rete. La procedura prende il nome di Link Quality Fish Eye ed è implementato in OLSR.org a partire dal- la versione 0.4.10. [13] CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 32 3.2.5.4 Il futuro di OLSR: OLSRv2 Attualmente lo sviluppo del protocollo OLSR è in una fase di tran- sizione dal momento che la specifica per la nuova versione (OLSRv2 è in fase di rifinimento da parte di Internet Engineering Task Force (IETF). La nuova specifica rappresenta un evoluzione rispetto alla RFC originale e non ne stravolge gli aspetti fondamentali. Le modifiche più rilevanti sono costituite dalla modularizzazione delle varie componenti di OLSR. La fase di Neighbor Sensing verrà svolta da un nuovo protocollo chiamato Neighborhood Discovery Protocol (NHDP) mentre il formato di tutti i messaggi sarà basato sul nuovo standard packetbb. Entrambe i nuovi componenti sono pensati per il riutilizzo in tutte i proto- colli per reti ad-hoc standardizzati da IETF. Le altre modifiche più rilevanti riguardano la gestioni di nodi con multiple interfacce e indirizzi. OLSR e OLSRv2 pur comportandosi in maniera molto simile non saran- no interoperabili. L''implementazione OLSR.org baserà la sua futura major release 0.7 proprio su OLSRv2. 3.2.6 Metriche di routing Dopo aver visto come i protocolli di rete si distinguano per il loro tipo di approccio e come questo porti a soddisfare obbiettivi anche molto diversi analizziamo una componente fondamentale dei protocolli di tipo link-state, la metrica di routing. Nei diversi protocolli il ''peso' dei link può essere valutato a seconda di caratteristiche come distanza, probabilità di perdita, latenza, capacità, carico. CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 33 3.2.6.1 Hop-count La metrica più semplice che non distingue tra link è la hop-count. Hop-count sceglie sempre il percorso più breve in termine di numero di hop esistente tra i due estremi. Come visto questo porta a minimizzare il numero di link utilizzati a scapi- to della qualità dei link stessi. I link selezionati infatti sono spesso i più lunghi e quindi caratterizzati dalle maggiori probabilità di perdita, capac- ità e latenza. La metrica hop-count può essere sufficiente in reti cablate in cui la probabilità di perdita non è mai rilevante e la banda non è una risorsa scarsa. 3.2.6.2 ETX La metrica ETX nasce proprio dall''inadeguatezza di hop-count per l''impiego in reti ad-hoc wireless. ETX trova il cammino con il minor numero di trasmissioni atteso (comp- rese le ritrasmissioni). La metrica è calcolata usando le probabilità di trasmissione con successo in entrambe i versi di ogni link. La probabilità che un pacchetto venga trasmesso e riscontrato senza bisogno di ritrasmissione è data dal prodotto delle probabilità associate ai due versi. Poiché ogni tentativo di trasmissione può essere visto come un evento di Bernoulli, il numero medio di trasmissioni corrisponde a: ET X = 1 df ' dr (3.1) La metrica è di tipo additivo, per questo è adatta ad essere utilizzata con protocolli di tipo link state ed ha l''obbiettivo di selezionare percorsi con throughput maggiore.[14] Un link perfetto con probabilità di trasmissione di successo pari a 1 in en- trambe i versi avrà ETX pari a 1. Il valore e quindi il costo della metrica sale CAPITOLO 3. PROTOCOLLI E METRICHE DI ROUTING PER RETI MULTI-HOP 34 quando la probabilità di successo scende. La metrica ETX viene solitamente computata utilizzando dei pacchetti di probe e misurando il rate di successo delle trasmissioni. Viene implementata con la trasmissione dei probe in broadcast che soli- tamente utilizza il rate più basso della rete rendendo la trasmissione più robusta e misurando una probabilità di perdita più bassa di quella dei pac- chetti dati trasmessi in unicast. La dimensione dei pacchetti di probe inoltre è solitamente più piccola rispetto ai pacchetti dati e questo facilita ulterior- mente la loro trasmissione a confronto dei pacchetti dati. Per ovviare a queste limitazioni è stata sviluppata una nuova metrica, la ETT. 3.2.6.3 Expected Transmission Time (ETT) Per superare le limitazioni delle metriche usate in precedenza la metri- ca ETT tiene conto anche della capacità dei link considerati. La nuova metrica mantiene le proprietà di ETX essendo anch''essa una met- rica di tipo additivo legata al singolo link della rete. La probabilità di perdi- ta e la capacità stimata del link vengono incorporate direttamente nella metrica che rappresenta il tempo di trasmissione di un pacchetto di riferi- mento sul link considerato.[12] Questo tempo comprende anche le necessarie ritrasmissioni in caso di perdi- ta del pacchetto. La metrica è definita come: ET X ' Dati trasmessi Capacit` a canale (3.2) La stima della capacità permette di scegliere percorsi che offrono maggiori rate e quindi minore tempo di trasmissione complessivo. Questo è partico- larmente utile in reti in cui esiste disparità non tanto tra l''affidabilità dei link ma tra la banda disponibile su ognuno di essi. Vedremo nel prossimo capitolo come questa caratteristica di ETT potrà rivelarsi utile per il routing su reti PLC. Capitolo 4 Routing multi-hop per reti
Homeplug AV
In questo capitolo si descrive la gestione delle reti Homeplug AV e si ef- fettua una misura delle prestazioni di trasmissioni di vario tipo su di esse. La conoscenza derivata dallo studio, dai test e dall''utilizzo di questa tec- nologia permette di ipotizzare una soluzione di routing pensata per miglio- rarne le prestazioni. Nella seconda parte del capitolo viene presentata la soluzione di routing messa a punto, basata sul protocollo di routing proattivo OLSR e su una nuova metrica link-state. 4.1 La gestione di una rete Homeplug AV La tecnologia Homeplug è progettata in maniera da ''nascondere'' il canale PLC all''utilizzatore. Tutte le soluzioni Homeplug attualmente in commercio permettono il con- trollo dei device tramite un protocollo proprietario basato sullo scambio di trame ethernet. Questo protocollo espone una serie di funzionalità riguardanti prevalente- 35 CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 36 mente l''osservazione della topologia di rete e la qualità della trasmissione misurata su di essa. A differenza di tecnologie come 802.11, in cui attraverso il software ven- gono esposte funzionalità di basso livello come la possibilità di definire la potenza trasmissiva o forzare l''utilizzo di una determinata modulazione, in Homeplug questo non è possibile. Non esistono in commercio dispositivi con un firmware di cui sia stato ri- lasciato il codice ed è quindi, per il momento, impossibile modificarne o estenderne le funzionalità. Questa parte del lavoro di tesi è stata resa possibile dall''ottimo lavoro di re- verse engineering svolto dagli sviluppatori di Faifa[15], un tool free software per l''interrogazione e configurazione di dispositivi Homeplug. Dal codice di Faifa è stato possibile imparare molto sul funzionamento dei dispositivi PLC mentre l''implementazione è servita da pilastro per la soluzione sviluppata in questo lavoro. 4.1.1 Interfaccia di controllo HPAV Il protocollo utilizzato per interrogare i dispositivi Homeplug AV è basato sullo scambio di trame ethernet con ETHERTYPE pari a 88e1. La struttura
di un messaggio Homeplug AV è la seguente: Figura 4.1: Struttura generica di un messaggio Homeplug AV Il campo più rilevante del messaggio è MMTYPE. MMTYPE è costituito da due byte e determina il tipo di messaggio Home- CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 37 plug e la sua funzione. Il protocollo è basato su scambi richiesta/risposta con i messaggi di rispos- ta che hanno MMTYPE pari a quello del corrispondente messaggio di richi-
esta incrementato di uno. In molto messaggi di richiesta il campo MM- TYPE è l''unico rilevante. Altri messaggi invece includono campi aggiuntivi per completare la richiesta. I parametri aggiuntivi sono compresi nel cam- po DATA del messaggio generico, dal momento che non presentano una
strutturazione comune tra messaggi diversi. Esistono diverse versioni del protocollo proprietario e per questo motivo non tutti i messaggi offerti da Faifa sono riconosciuti da tutti i dispositivi. I messaggi di gestione più rilevanti sono: ' Network Info (MMTYPE: A038-A039): Fornisce la lista delle stazioni viste dal dispositivo PLC interrogato in- dicando quale di queste ha assunto il ruolo di Coordinatore. Fornisce anche informazioni sulla rete logica di appartenenza HPAV come il Network Identifier (NID) e sul numero totale di stazioni presenti. Comprende anche una stima della qualità della trasmissione verso ogni peer. ' Link Statistics (MMTYPE: A030-A031): Riporta informazioni dettagliate sulle statistiche globali di trasmis- sione e ricezione per la stazione considerata. Le informazioni più det- tagliate comprendono il numero di Physical Block (PB) trasmessi con successo, quelli che hanno subito collisione e il numero di dati recu- perati con successo o meno dal codice Turbo usato per la FEC. Queste statistiche sono cumulative per tutte le trasmissioni della stazione interrogata e non discriminabili per destinazione. ' Reset Device (MMTYPE: A01C): CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 38 Forza un reset del dispositivo azzerandone le statistiche. Il dispositi- vo riavviandosi deve rinegoziare l''appartenenza ad una AV Logical Network (AVLN) ' Tone Map Characteristics (MMTYPE: A070-A071): Permette di conoscere Il Tone Map, cioè la mappatura delle modu- lazioni in tutte le sottoportanti OFDM utilizzata nella trasmissione verso un determinato peer e in un determinato time slot. E'' uno dei messaggi più rilevanti perché fornisce dati sul canale PLC vero e pro- prio e permette di stimare una banda massima raggiungibile dalla trasmissione. [2.4.2.1] ' Quality estimation(MMTYPE: A074-A075): Fornisce una misura della qualità della trasmissione verso un deter- minato peer Homeplug. Le misure sono due, una per la qualità in trasmissione e una per la qualità in ricezione. La stima è fatta inter- namente ai device Homeplug e non è possibile conoscere come sia calcolata. ' Get Device Attributes (MMTYPE: A068): Ottiene dal device PLC le informazioni sulle versioni di hardware e software. ' Set Encryption Key (MMTYPE: A050-A051): Permette di impostare la chiave per la crittografia AES. Il messag- gio prevede sia un metodo per l''impostazione della chiave sul dis- positivo locale e uno per l''impostazione su dispositivi remoti. I test condotti hanno avuto successo solo con l''impostazione locale della chiave. Questo metodo di configurazione della sicurezza è preferibile allo scambio automatizzato offerto da tutti i dispositivi perché non si affida a uno scambio basato su chiavi crittografiche preimpostate in fase di produzione e quindi potenzialmente vulnerabili. CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 39 Nell''appendice A [A] è riportato un elenco dei messaggi Homeplug AV supportati da Faifa. 4.1.2 Le prestazioni di una rete Homeplug AV Per poter verificare sul campo che tipo di prestazioni sia possibile ot- tenere da una rete Homeplug AV sono stati condotti test estensivi in di- verse situazioni. Per questo lavoro era importante poter valutare le prestazione realistica- mente ottenibili da questa tecnologia ma soprattutto mettere a punto un metodo per stimare queste prestazioni prima della trasmissione. Sono stati condotti diversi tipi di test partendo da una singola coppia di de- vice PLC collegati attraverso un semplice segmento di rete elettrica in mo- do da isolare l''effetto che un singolo elemento presente su di esso potesse avere sulla trasmissione. I test sono stati ripetuti ricreando le stesse condizioni a distanza di tempo, in modo da osservare come le caratteristiche tempo-varianti della rete elet- trica possano influire sulle prestazioni delle comunicazioni PLC. Le mis- urazioni effettuate riguardano la latenza, il jitter e il rate massimo raggiunto da connessioni TCP e UDP nelle varie configurazioni del testbed. 4.1.2.1 Descrizione del testbed Sono state utilizzate diverse configurazioni di testbed per quanto riguar- da il segmento di rete elettrica da analizzare e la modalità di collegamento dei device PLC. Ogni test effettuato è descritto attraverso lo schema di col- legamento dei dispositivi e i risultati ottenuti. La latenza viene misurata effettuando PING con pacchetti da 150 bytes, una dimensione paragonabile a quella di pacchetti VoIP. Ogni iterazione ripor- tata nei test rappresenta il valor medio di una misurazione effettuata con 60 PING nell''arco di un minuto. CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 40 Jitter e rate massimo per connessioni TCP e UDP vengono calcolati con l''u- tilizzo del tool Iperf[16], un generatore di traffico e misuratore di prestazioni di rete free software. Il jitter considerato è quello di trasmissioni UDP ad un rate vicino al rate massimo ottenibile a percentuale di perdita di pacchetti nulla. Le apparecchiature utilizzate per il testbed sono le seguenti: ' PC desktop con processore Intel Core 2 Quad Q9500, 4 GB di RAM. Sistema operativo GNU/Linux (Ubuntu 10.10, kernel 2.6.35-27-generic) ' PC laptop Asus A8JC con processore Intel Core Duo T2300, 1 GB di RAM. Sistema operativo GNU/Linux (Ubuntu 10.10, kernel 2.6.35- 27-generic) ' 2 adattatori PLC Homeplug AV Bewan E200Plus ' Materiale elettrico generico: 1 ciabatta multipresa a 3 vie, cavo tripo- lare da 10 m (diametro conduttore 2,5 mm), 2 bobine conduttore da 100 m (diametro conduttore 2,5 mm) ' 1 caricabatterie per cellulare (Input: 200 mA a 240 V, Output: 1 A a 5V) ' 1 asciugacapelli (Potenza: 1800 W) ' 1 aspirapolvere (Potenza: 400 W) ' 1 interruttore differenziale Merlin-Gerin (Corrente nominale In: 25 A, Corrente differenziale nominale d''intervento: 30 mA) ' 1 interruttore magnetotermico F82XD16 (Corrente nominale max: 25 A, Potere massimo interruzione: 4500 A) 4.1.2.2 Impatto della distanza sulla trasmissione Test su singola multipresa Latenza CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 41 Figura 4.2: Test 1: adattatori PLC collegati allo stessa multipresa iterazione latenza (ms) 1 3.421 2 3.402 3 3.457 4 3.391 5 3.374 Valor medio 3.409 Jitter iterazione jitter (ms) 1 0.120 2 0.120 3 0.200 4 0.171 5 0.142 6 0.200 7 0.119 8 0.116 Valor medio 0.148 Rate trasmissioni CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 42 iterazione protocollo rate (Mbit/s) Stima rate HPAV [HEX] 1 TCP 81.90 93 2 TCP 82.25 93 3 TCP 82.89 93 4 TCP 80.40 92 5 TCP 86.57 95 6 UDP 93.30 94 7 UDP 91.43 93 8 UDP 95.05 95 9 UDP 94.06 96 10 UDP 93.70 94 Figura 4.3: Test 2: adattatori PLC collegati tramite una prolunga da 10 m Test cavo 10 m Latenza iterazione latenza (ms) 1 3.401 2 3.402 3 3.427 4 3.381 5 3.384 Valor medio 3.399 Jitter CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 43 iterazione jitter (ms) 1 0.113 2 0.121 3 0.117 4 0.150 5 0.161 6 0.210 7 0.134 8 0.116 Valor medio 0.140 Rate trasmissioni iterazione protocollo rate (Mbit/s) Stima rate HPAV [HEX] 1 TCP 83.84 93 2 TCP 84.85 93 3 TCP 84.08 93 4 TCP 80.61 92 5 TCP 86.57 95 6 UDP 93.30 94 7 UDP 91.43 93 8 UDP 94.05 95 9 UDP 94.06 96 10 UDP 93.70 94 Figura 4.4: Test 3: adattatori PLC collegati tramite una prolunga da 100 m Test cavo 100 m Latenza CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 44 iterazione latenza (ms) 1 3.441 2 3.405 3 3.437 4 3.401 5 3.384 Valor medio 3.414 Jitter iterazione jitter (ms) 1 0.120 2 0.120 3 0.200 4 0.171 5 0.142 6 0.200 7 0.119 8 0.116 Valor medio 0.148 Rate trasmissioni iterazione protocollo rate (Mbit/s) Stima rate HPAV [HEX] 1 TCP 81.90 93 2 TCP 82.25 93 3 TCP 82.89 93 4 TCP 80.40 92 5 TCP 86.57 95 6 UDP 93.30 94 7 UDP 91.43 93 8 UDP 94.05 95 9 UDP 94.06 96 10 UDP 93.70 94 4.1.2.3 Effetto dei disturbi di natura elettrica Test interruttore magnetotermico F82XD/16 Latenza iterazione latenza (ms) 1 3.451 2 3.415 3 3.427 4 3.411 5 3.394 Valor medio 3.420 CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 45 Figura 4.5: Test 4: una foto del testbed con interruttore magnetotermico F82XD/16 Jitter iterazione jitter (ms) 1 0.130 2 0.125 3 0.195 4 0.181 5 0.139 6 0.206 7 0.123 8 0.118 Valor medio 0.152 Rate trasmissioni iterazione protocollo rate (Mbit/s) Stima rate HPAV [HEX] 1 TCP 80.76 8f 2 TCP 80.03 8e 3 TCP 79.94 8f 4 TCP 76.01 8b 5 TCP 81.21 91 6 UDP 90.30 91 7 UDP 89.43 8f 8 UDP 89.05 8f 9 UDP 91.06 90 10 UDP 90.70 90 CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 46 Figura 4.6: Test 5: caricabatterie per cellulare collegato in prossimità del trasmettitore PLC 4.1.2.4 Test caricabatterie Risultati Latenza Per misurare l''effetto sulla latenza introdotto dal cari- cabatterie si è effettuato un test lungo 120 secondi, durante il quale il cari- cabatterie è collegato solo nell''intervallo 40-80 secondi. I risultati sono pre- sentati nel seguente grafico: Figura 4.7: Test 6: caricabatterie per cellulare collegato e scollegato durante la misurazione
della latenza Jitter CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 47 iterazione jitter (ms) 1 0.140 2 0.135 3 0.205 4 0.191 5 0.149 6 0.226 7 0.133 8 0.110 Valor medio 0.161 Rate trasmissioni Anche per il throughput della trasmissione si è osser- vato il comportamento nel tempo collegando e scollegando il caricabatterie. Figura 4.8: Test : throughput TCP in funzione del tempo collegando e scollegando il
caricabatterie 4.1.2.5 Test asciugacapelli Risultati Latenza Jitter CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 48 Figura 4.9: Test 6: asciugacapelli collegato tra i due dispositivi PLC Figura 4.10: Test 6: asciugacapelli acceso e spento durante la misurazione della latenza iterazione jitter (ms) 1 0.140 2 0.135 3 0.205 4 0.191 5 0.149 6 0.226 7 0.133 8 0.110 Valor medio 0.161 Rate trasmissioni CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 49 Figura 4.11: Test : throughput TCP in funzione del tempo accendendo e spegnendo
l''asciugacapelli 4.1.2.6 Analisi dei risultati I test effettuati hanno mostrato come la tecnologia Homeplug AV pos- sa fornire in condizioni ideali prestazione vicine a quelle di una comune trasmissione Fast Ethernet. Il throughput TCP misurato in condizioni ideali si avvicina ai 90 Mbit/s ed è un valore in linea con quanto misurato in altri studi.[17, p. 24] L''analisi dell''effetto della distanza sulla prestazione mostra che in con- dizioni ideali la trasmissione Homeplug AV a 100 m di distanza non subisce praticamente alcun degrado, raggiungendo gli stessi rate di una trasmis- sione a pochi centimetri di distanza sulla stessa ciabatta multipresa. Questo costituisce un segnale positivo e un punto a favore della tecnolo- gia PLC nei confronti per esempio di 802.11 che, anche in condizioni ideali, risente maggiormente dell''attenuazione dovuta alla distanza. Anche per quanto riguarda la latenza della rete si riscontra un andamento costante nonostante l''aumento notevole della distanza. Una caratteristica peculiare rilevata è che anche in caso di trasmissione a pochi centimetri di distanza e con pacchetti di PING ancora più piccoli dei CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 50 150 byte usati solitamente, è stato impossibile misurare una latenza inferi- ore ai 3 ms. Questo sembra suggerire un ritardo fisso introdotto da Home- plug AV ma è difficile determinare quale ne sia la causa senza poter avere accesso al software dei dispositivi o ad una specifica completa della tec- nologia. Gli effetti delle apparecchiature elettriche connesse in un segmento di rete in prossimità dei trasmettitori invece sono rilevanti sia sul throughput che sulla latenza. Il caricabatterie del cellulare rappresenta un carico induttivo in grado di disturbare notevolmente il throughput della trasmissione con effetti ap- prezzabili anche sulla latenza. L''asciugacapelli, carico che introduce anche rumore di tipo impulsivo sulla linea, ha effetti meno rilevanti sul throughput della trasmissione ma mag- giormente apprezzabili in termine della latenza della rete. Un componente come l''interruttore magnetotermico invece non presenta particolare impatto dal punto di vista del throughput e si dimostra del tutto ininfluente per quanto riguarda il ritardo della trasmissione. 4.2 Una soluzione di routing multi-hop La tecnologia Homeplug AV messa alla prova dai test effettuati ha di- mostrato di poter raggiungere buone performance anche a distanze notevoli su segmenti di rete elettrica relativamente semplici,con un numero limitato di sorgenti di rumore e interconnessioni. Questo rappresenta un risultato interessante in ottica di possibili appli- cazioni della tecnologia al di fuori della sfera domestica. Le comunicazioni PLC possono essere molto utili in grandi edifici che si sviluppano su più livelli dove le comunicazioni wireless tra un piano e l''al- tro subiscono un degrado delle prestazioni troppo elevato per essere van- CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 51 taggiose. E'' possibili immaginare l''impiego di PLC come mezzo per realizzare seg- menti di una rete wireless mesh in tutti quei casi dove non esistono le con- dizioni ideali per la trasmissione wireless(mancanza di visibilità, elevate interferenze). La onnipresenza delle reti elettriche sfruttabili come canale dalle PLC rende questo scenario senz''altro appetibile. Dai test effettuati sulle reti Homeplug emerge come anche in una rete di piccole dimensioni la visibilità tra stazioni appartenenti alla stessa rete non sia sempre garantita. Come visto nel capitolo 3, l''utilizzo di un paradigma di trasmissione multi- hop in una rete Homeplug AV può risolvere il problema della visibilità delle stazioni e migliorare le prestazioni della rete. L''utilizzo di un protocollo di routing come OLSR costituisce già un notev- ole miglioramento all''utilizzo di una rete Homeplug AV semplice. L''ulte- riore miglioramento che questo lavoro di tesi vuole introdurre è la messa a punto di un meccanismo di routing basato su una metrica più avanzata rispetto alla semplice metrica ETX impiegata di default da OLSR che sia in grado di sfruttare le informazioni ottenibile dai device PLC sulla qualità dei link per massimizzare il throughput della rete. Dalle misurazioni effettuate emerge come sia possibile ottenere dai dispos- itivo Homeplug AV una metrica che stima approssimativamente il rate rag- giungibile dalla trasmissione dati tra due stazioni appartenenti alla stessa rete logica. Si è deciso pertanto di basare la nuova metrica di routing su questa stima ed è risultato naturale utilizzare una metrica di tipo ETT, basa- ta in parte sulla metrica standard ETX impiegata da OLSR e in parte sulla stima del rate massimo del link computabile a partire dalle informazioni ottenute sul rate. [3.2.6.3] CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 52 4.3 OLSR e il routing Multi-hop per reti PLC I principali problemi da considerare nella realizzazione di questa soluzione di routing basata su OLSR sono stati l''interpretazione dei dati ottenuti dai dispositivi PLC con la conseguente messa a punto della metrica e la dis- tribuzione delle associazione tra MAC address dei device PLC e gli indi- rizzi IP dei nodi ad essi collegati utilizzando l''infrastruttura di OLSR. 4.3.1 Calcolo della metrica ETT-PLC in reti Homeplug AV La nuova metrica, che ricalca la metrica ETT è chiamata ETT-PLC ed è definita come: ET X ' Dati trasmessi Capacit` a canale (4.1) In questa espressione la metrica ETX è stimata tramite lo scambio di mes- saggi HELLO utilizzando il meccanismo standard di OLSR. La quantità di dati trasmessi può essere considerato come un fattore arbitrario di scala. Nell''implementazione realizzata è posta a 100 byte. La stima della capacità è calcolata basandosi sulle informazioni ottenute tramite lo scambio A038-A039 di Homeplug AV.
La stima della qualità del canale tra due peer HPAV è espressa tramite un byte e ne esiste una per ogni verso del canale. L''asimmetria nelle comunicazioni Homeplug AV come visto nei test si ver- ifica regolarmente in reti costituite anche da 2 peer solamente. Nella realizzazione della metrica ETT-PLC si è deciso di considerare co- munque la capacità del canale come simmetrica, utilizzando il verso di trasmissione con stima minima come rappresentativo del canale. Questo è dovuto all''impossibilità del protocollo OLSR di supportare la memoriz- zazione e la distribuzione di differenti metriche per ogni link. L''informazione sull''asimmetria del canale è comunque incorporata nella metrica ETX, su cui ETT si basa e che contiene la valutazione della proba- CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 53 bilità di successo della trasmissione in entrambe i versi. L''implementazione di un meccanismo di routing asimmetrico in OLSR richiederebbe considerevoli modifiche alla specifica [10] ed all''implementazione e non viene perciò considerata in questo lavoro di tesi. La possibilità di avere una stima della banda in entrambe i versi di trasmis- sione tra due peer in una rete Homeplug AV costituisce già una ottima base per la nuova soluzione di routing implementata. La stima della capacità del singolo link viene quindi calcolata come: C = c ' Quality 255 (4.2) dove Quality è la stima calcolata internamente ai device HPAV mentre c è un coefficiente di proporzionalità ottenuto per via sperimentale. Attraverso la misura delle massime prestazioni di una trasmissione UDP tra due peer Homeplug AV in svariati scenari di rete è stato possibile indi- viduare un andamento lineare della stima riportata dai device Homeplug in funzione del rate di trasmissione. Il risultato è riportato in figura: Figura 4.12: Interpolazione lineare della relazione tra stima Quality di Homeplug AV e il
rate UDP effettivamente misurato CAPITOLO 4. ROUTING MULTI-HOP PER RETI HOMEPLUG AV 54 4.3.2 Distribuzione delle associazioni IP-MAC_PLC Dal momento che il protocollo di gestione della rete Homeplug AV opera a livello MAC con i device che si comportano come dei bridge eth- ernet, non considera le associazioni con gli indirizzi IP dei dispositivi che utilizzano la rete PLC. E'' necessario quindi tenere traccia dell''associazione tra indirizzi IP dei nodi e gli indirizzi MAC PLC e distribuirle di modo che tutti i nodi della rete le conoscano e possano correttamente associare i dati provenienti dai device Homeplug AV con quelli del routing OLSR classico. Il sistema realizzato pertanto utilizza un messaggio OLSR che oltre agli header standard include l''indirizzo IP principale del nodo e l''indirizzo MAC del device PLC collegato. Ogni nodo costruisce grazie a messaggi ricevuti una tabella delle associ- azioni IP-MAC_PLC che viene utilizzata anche per memorizzare le infor- mazioni sulla qualità del canale rilevata dal device HPAV. Il messaggio OLSR è distribuito grazie ad una funzionalità dell''implemen- tazione OLSR.org che permette di definire messaggi aggiuntivi oltre a quel- li standard e di trasmetterli in rete con la cadenza desiderata. Compatibil- mente con i requisiti OLSR.org tenta di trasmettere i nuovi messaggi aggre- gandoli ad altre trasmissioni (per esempio in coda a pacchetti HELLO) in modo da risparmiare banda e risorse di rete. 4.3.3 Integrazione in OLSR La metrica ETT-PLC è distribuita in rete da OLSR seconda la stessa modalità con cui veniva distribuita ETX ed anche il calcolo delle rotte migliori e la compilazione delle tabelle di routing continua a essere svolto nello stes- so modo in maniera del tutto trasparente al cambiamento della metrica. La soluzione introdotta si integra perfettamente con il funzionamento di OLSR senza dover modificare alcuna delle procedure principali. Capitolo 5 Implementazione di PLC
plugin per OLSR.org
Nel capitolo precedente è stata presentata la soluzione di routing multi- hop proposta e sono state descritte le procedure che è necessario imple- mentare per poterla realizzare. In questo capitolo verrà descritta la fase di implementazione vera e propria della metrica con riferimenti alla architettura software di OLSR.org. 5.1 L''architettura software di OLSR.org Nel definire l''architettura di OLSR.org Andreas Tønnesen si è preoc- cupato di renderla fin dall''inizio modulare, progettando un''architettura a plugin. 5.1.1 Struttura a plugin e gestione della configurazione Le funzioni di base e anche quelle ausiliarie di OLSR descritte nel capi- tolo 3 sono implementate nel core del software mentre nei plugin sono state sviluppate, anche grazie al contributo degli utenti, funzionalità accessorie anche molte utili e complesse come un sistema di trasmissione multicast o 55 CAPITOLO 5. IMPLEMENTAZIONE DI PLC PLUGIN PER OLSR.ORG 56 un servizio DNS. Altri plugin come txtinfo e dot_draw invece realizzazione funzionalità di presentazione dei dati operativi di Optimized Link State Routing (OLSR) come ad esempio le tabelle di routing o le topologie di rete costruite e sono state ampiamente utilizzati in questo lavoro. Ogni plugin di OLSR è costituito da una libreria condivisa distinta che può essere caricata o meno nella fase di init del servizio sulla base del file di configurazione. Nel file di configurazione di OLSR è possibile oltre a determinare i plugin da caricare anche definire i loro parametri operativi, che verranno passati al plugin nella sua fase di init. Per quanto riguarda la gestione e il parsing della configurazione OLSR.org utilizza un parser basato su Flex e Bison.[18][19] Flex si occupa di interpretare i file di configurazione creando una grammat- ica le cui unità minime sono chiamate token. bison opera sulla grammatica generando il parser vero e proprio che fornirà i parametri a OLSR.org. Essendo i plugin librerie caricate dinamicamente, non è previsto un mec- canismo per comunicare tra loro. Per questo motivo l''unica interfaccia di comunicazione è costituita dall''interfaccia per plugin di OLSR.org, giunta nella versione 0.6.1 alla sua quinta iterazione. 5.1.2 Plugin link quality e componenti del core di OLSR.org Esiste una classe particolare di plugin che è quella dei plugin link quality (lq_plugin). I plugin link quality utilizzano un''interfaccia di OLSR.org con funzionalità più ristrette e fortemente specializzata per la gestione e l''elaborazione della metrica di routing, fondamentale per il funzionamento del protocollo. Le informazioni di link quality ricevute dai nodi della rete o ottenute di- CAPITOLO 5. IMPLEMENTAZIONE DI PLC PLUGIN PER OLSR.ORG 57 rettamente dall''istanza locale di OLSR vengono passate al plugin lq che le elabora e le utilizza per costruire la metrica di routing. Funzioni come il calcolo dei cammini minimi o la compilazione delle tabelle di routing vengono svolte nel core di OLSR.org proprio sulla base della link quality calcolata in questo plugin. Un''altra componente fondamentale è rappresentato dallo scheduler. Lo sched- uler si occupa di gestire tutti gli eventi di OLSR stabilendone la successione temporale. Permette di registrare delle funzioni aggiuntive da eseguire con la cadenza desiderata o di aggiungere socket che verranno gestiti insieme ai socket di rete standard di OLSR. In questo modo la temporizzazione degli eventi è centralizzata e più facile da controllare e ottimizzare. I messaggi che OLSR invia e riceve sono interpretati dal packet parser, una componente del core. Il packet parser permette di definire nuovi messaggi OLSR e di inviarli sul- la rete. Anche in questo caso la gestione delle risorse è efficiente poiché il coordinamento delle trasmissioni e delle ricezioni è unico. Nel core di OL- SR.org esistono diverse strutture per memorizzare i dati riguardanti i link, gli MPR, i vicini e le tabelle di routing. Non esiste però una struttura dati per ospitare eventuali misurazioni sulla qualità dei link effettuate a livello linklayer in modo da renderle disponibili a qualunque componente ed in particolare al sistema di plugin link quality. 5.2 Realizzazione della soluzione di routing PLC Per implementare la metrica ETT-PLC è necessario realizzare quattro funzionalità distinte: ' Servizio di interrogazione PLC: si occupa di comunicare con i device PLC collegati al nodo e ottenere CAPITOLO 5. IMPLEMENTAZIONE DI PLC PLUGIN PER OLSR.ORG 58 le informazioni riguardanti le altre stazioni HPAV presenti in rete. Memorizza i dati ottenuti nel database linklayer PLC. ' Servizio di distribuzione associazioni IP-MAC_PLC: registra un nuovo tipo di messaggio OLSR con cui la associazione IP-MAC_PLC locale viene distribuita agli altri nodi della rete. ' Database per informazioni linklayer PLC: struttura dati in cui vengono memorizzate le informazioni di livello 2 sulla qualità dei link HPAV. ' Plugin link quality per il calcolo di ETT-PLC: plugin link quality che utilizza le funzionalità offerte dagli altri com- ponenti realizzati per calcolare la nuova metrica ETT-PLC. La soluzione sviluppata prevede un plugin generico per OLSR.org (PLC_plugin) che implementa sia il servizio di interrogazione PLC che quello di dis- tribuzione delle associazioni IP-MAC_PLC, una struttura dati inserita nel core del programma chiamata linklayer_plc_data e il plugin link_quality per il calcolo di ETT-PLC. Tutte le componenti sono state sviluppate utilizzando come base la ver- sione 0.6.1 di OLSR.org, la più recente versione stabile al momento della realizzazione del lavoro. 5.2.1 PLC_plugin In questo plugin vengono raggruppate due funzionalità distinte. Le due parti del plugin che le realizzano sono: plc_service e plc_distribution_service. 5.2.2 plc_service Questo componente si occupa di comunicare con i device HPAV utiliz- zando le trame ethernet con ETHERTYPE pari a 88e1 come descritto nel CAPITOLO 5. IMPLEMENTAZIONE DI PLC PLUGIN PER OLSR.ORG 59 capitolo 4. La struttura delle trame è mutuata dal tool free software Faifa mentre per la trasmissione e la ricezione delle trame si utilizza la libraria pcap [20]. pcap permette di inviare in maniera semplice trame HPAV di richi- esta forgiate ad-hoc anche negli header e contemporaneamente di catturare le trame di risposta. La libreria è configurata in modo da catturare solo trame con ETHERTYPE 88e1 in modo da non influenzare le prestazioni complessive del servizio o peggio di causare la perdita di messaggi di gestione OLSR. Il servizio è in grado di gestire gli scambi HPAV A030-A031, A038-A039, A070-A071 ma può facilmente supportare l''aggiunta di ulteriori messaggi se richiesto. L''update delle informazioni sulla rete PLC è effettuato ogni 5 secondi gra- zie ad una funzione registrata attraverso lo scheduler di OLSR. Una volta elaborati i dati ottenuti dai messaggi HPAV, questi vengono memorizzati in linklayer_plc_data. 5.2.3 plc_distribution_service Il servizio di distribuzione PLC definisce un nuovo messaggio OLSR che viene diffuso in rete ogni 3 secondi. La spedizioni dei messaggi è effettuata con l''infrastruttura di OLSR e si verifica che con l''intervallo scelto il nuovo messaggio è sempre trasmesso in coda a messaggi di HELLO o TC. Le informazioni sulle associazioni IP-MAC_PLC ricevute dai vicini ven- gono inserite in linklayer_plc_data e vengono utilizzate da plc_service per interpretare correttamente i dati HPAV. CAPITOLO 5. IMPLEMENTAZIONE DI PLC PLUGIN PER OLSR.ORG 60 5.2.4 linklayer_plc_data La struttura dati creata è importante non tanto per la funzione di persis- tenza dei dati PLC offerta ma soprattutto perché rende possibile lo scambio di dati tra il plugin generico PLC_plugin e il plugin link quality ETT-PLC. Come visto la comunicazione diretta tra i due plugin entrambe costituiti da librerie dinamiche non è possibile. linklayer_plc_data è stata creata come struttura dati nel core di OLSR in mo- do da essere accessibile ai due plugin e rendere possibile lo scambio di dati. Un database per la memorizzazione delle informazioni di livello linklay- er è previsto nella roadmap di OLSR.org e potrebbe essere aggiunto nella prossima major release (0.7). linklayer_plc_data rappresenta una prima implementazione di questa idea. 5.2.5 Plugin link quality lq_ETT-PLC Il plugin link quality che realizza il calcolo della nuova metrica è realiz- zato sul modello di quello attualmente usato come default in OLSR.org e sviluppato originariamente dal progetto Freifunk. Il plugin si occupa di serializzare e deserializzare le informazioni sulla link quality all''interno di ogni messaggio HELLO o TC spedito e aggiorna le in- formazioni su ogni link attivo. I dati che descrivono ogni link comprendono quelli ottenuti tramite lo scam- bio di messaggi HELLO e TC e quelli relativi alla qualità dei link PLC ot- tenuti con delle query a linklayer_plc_data. Il plugin svolge poi la sua funzione centrale con il calcolo della metrica ETX che viene poi utilizzata per computare ETT-PLC, la metrica definitiva che viene utilizzata da OLSR per il routing. CAPITOLO 5. IMPLEMENTAZIONE DI PLC PLUGIN PER OLSR.ORG 61 5.2.6 Altri aspetti implementativi Altre modifiche minori sono state necessarie per garantire il funziona- mento dei nuovi componenti. 5.2.6.1 Modalità PLC per le interfacce Per poter distinguere la configurazioni di interfacce collegate a device PLC e comuni interfacce ethernet è stata introdotta una modifica al parser di OLSR.org in modo da aggiungere la modalità PLC a quelle già previste di ethernet e mesh. In questo modo è possibile per OLSR.org eseguire operazioni apposite a seconda del tipo di interfaccia. Questo parametro è indispensabile nella fase di calcolo della metrica per ef- fettuare operazioni diverse a seconda dell''interfaccia che si sta consideran- do. 5.2.6.2 Plugin txtinfo_PLC Il plugin txtinfo è presente nella codebase di OLSR.org ed è utilizzato per fornire, attraverso uno scambio http, informazioni su tutte le compo- nenti del servizio e sulla topologia e qualità della rete. txtinfo_PLC è una modifica del plugin originale che permette di ottenere anche le informazioni sulla rete HPAV che sono memorizzate in linklay- er_plc_data . Questo plugin è stato indispensabile nei test di OLSR.org con la nuova metrica che sono dettagliati nel capitolo 6. 5.3 Evoluzioni future L''implementazione di ETT-PLC è stata realizzata sfruttando il più pos- sibile le caratteristiche modulari di OLSR.org, introducendo nel codice del CAPITOLO 5. IMPLEMENTAZIONE DI PLC PLUGIN PER OLSR.ORG 62 core solo modifiche non intrusive come l''aggiunta della struttura linklay- er_plc_data e la modifica del parser della configurazione. In questo modo ci si è garantiti che la soluzione potrà essere facilmente portabile alle versioni successive di OLSR.org. Anche se la futura release 0.7 che implementa la versione 2 della specifica di OLSR introdurrà modifiche rilevanti al core del programma, non dovrebbe essere né difficile né dispendioso portare l''implementazione realizzata alla nuova versione. Capitolo 6 Risultati sperimentali La soluzione di routing multi-hop è stata testata intensamente attraver- so l''utilizzo di diverse configurazioni di rete in modo da ottenere dati in grado di rispecchiare il comportamento in situazioni reali. In questo capitolo vengono presentati i risultati ottenuti in tutte le fasi di testing, partendo dalla descrizione del testbed e delle tipologie di test effet- tuate. 6.1 Descrizione del testbed Per ricreare le condizioni di un ambiente di trasmissione multi-hop, è stato utilizzato l''impianto elettrico di un''abitazione domestica. La distanza, la presenza di interconnessioni, diramazioni, connettori etero- genei e un numero di apparecchiature elettriche sempre collegate, rappre- sentano un ottimo campo di prova in cui sono presenti forti attenuazioni nelle trasmissioni. In questo modo la qualità della comunicazioni tra coppie di device PLC collegati alla rete è molto variabile e si creano ''canali' notevolmente diver- si. 63 CAPITOLO 6. RISULTATI SPERIMENTALI 64 Il testbed è stato realizzato in modo da poter valutare per ogni link la per- formance della trasmissione in entrambe i sensi, la latenza e registrare di volta in volta la topologia della rete creata. Il testbed è costituito dalle seguenti apparecchiature: ' PC desktop 1: con processore Intel Core 2 Quad Q9500, 4 GB di RAM. Sistema operativo GNU/Linux (Ubuntu 10.10, kernel 2.6.35-27-generic) ' PC desktop 2: con processore Intel Core 2 Duo E8500, 4 GB di RAM. Sistema operativo GNU/Linux (Ubuntu 10.04.2 LTS, kernel 2.6.32-28- generic) ' PC laptop 1: Asus A8JC con processore Intel Core Duo T2300, 1 GB di RAM. Sistema operativo GNU/Linux (Ubuntu 10.10, kernel 2.6.35- 27-generic) ' PC desktop 3: HP con processore Intel Core 2 Duo E8500, 4 GB di RAM. Sistema operativo GNU/Linux (Ubuntu Server 10.10, kernel 2.6.35-22-generic-pae) ' 2 adattatori PLC Homeplug AV Bewan E200Plus ' 2 adattatori PLC Homeplug AV Zyxel PLA-401 ' Materiale elettrico generico: 2 ciabatta multipresa a 3 vie, cavo tripo- lare da 10 m (diametro conduttore 2,5 mm). Lo schema del testbed è riportato in figura. I terminale vengono di volta in volta collegati in diversi punti dell''impianto in modo da generare scenari di rete differenti. Il setting viene mantenuto invariato per la durata di ogni singolo esperimento. I PC sono tutti configurati con indirizzo IP statico e la mappatura degli indirizzi è riportata in figura: CAPITOLO 6. RISULTATI SPERIMENTALI 65 Figura 6.1: Il testbed è realizzato con quattro terminali collegati di volta in volta in punti
diversi dell''impianto elettrico 6.2 Implementazione del testbed Il processo di test si è concentrato sulla valutazione delle prestazioni e dei ritardi di tutte le parti della rete in tre scenari distinti: ' Semplice rete Homeplug AV: i terminali sono collegati tramite i de- vice Homeplug AV ma non viene impiegato nessuno protocollo di routing. ' Rete multi-hop OLSR 0.6.1: si utilizza l''ultima versione stabile rilasci- ata da OLSR.org che opera con metrica ETT ' Rete multi-hop OLSR con metrica ETT-PLC: realizzata con il software sviluppato in questo lavoro. Per la misurazioni della latenza della rete sono stati impiegati PING con pacchetti da 150 bytes come già effettuato nei test descritti nel capitolo 4. Le prestazioni del canale tra ogni coppia di terminali della rete è misurata con il tool Iperf[16] utilizzato in modalità TCP. Un altro dato importante raccolto è quello delle tabelle di routing fonda- mentali per tenere traccia della topologia e dell''instradamento nella rete CAPITOLO 6. RISULTATI SPERIMENTALI 66 e confrontare su questo punto OLSR ETT-PLC con la versione standard di OLSR. Ogni esperimento è costruito in modo che i tre scenari vengano testati sulla stessa configurazione di rete. Questo implica che i terminali siano collegati negli stessi punti della rete elettrica e che le condizioni del- l''impianto elettrico in termine di carichi collegati rimangano costanti. E'' importante anche che i tre scenari siano testati in successione, in modo da concentrare temporalmente i tre test e ottenere le condizioni di rete più omogenee possibili. Per ottenere queste condizioni è stato necessario automatizzare l''ambiente di testing attraverso uno script di shell. Lo script esegue in sequenza le operazioni: 1. Avvio di iperf su tutti i terminali 2. Simulazioni iperf TCP tra tutti i nodi 3. Avvio di OLSR 0.6.1 4. Recupero rotte 5. Misurazione latenza tra tutti i terminali 6. Simulazioni iperf TCP tra tutti i nodi 7. Spegnimento di OLSR 0.6.1 8. Avvio di OLSR ETT-PLC 9. Recupero rotte 10. Misurazione latenza tra tutti i terminali 11. Simulazioni iperf TCP tra tutti i nodi 12. Spegnimento di OLSR ETT-PLC Questo procedimento ha permesso di raccogliere un gran numero di simulazioni e di validare quindi i dati ottenuti. CAPITOLO 6. RISULTATI SPERIMENTALI 67 6.3 Presentazione dei risultati Vengono ora presentati i risultati di alcune delle più significative realiz- zazioni dei test raccolti. Di tutti i test svolti, un buon numero non ha rivelato differenze di prestazioni significative tra l''impiego di OLSR ETT-PLC e la versione standard. Sono questi i casi in cui le due metriche arrivano ad utilizzare lo stesso in- stradamento che è quindi ottimo sia dal punto di vista della probabilità di successo delle trasmissioni che da quello della capacità dei link utilizzati. I casi presentati invece rappresentano le configurazioni di rete più signi- ficative riscontrate, in cui a fronte di un instradamento differente tra le due istanze del protocollo di routing si ottengono guadagni sensibili sul rate delle trasmissioni. 6.3.1 Test: cambiamento multiplo nell''instradamento La topologia di rete e il throughput in condizioni di instradamento di- retto sono espressi in figura: Gli instradamenti realizzati dai due protocolli di routing sono esposti graficamente nelle figure: OLSR standard OLSR ETT-PLC Dai grafici si può notare come il cambiamento nel throughput dei seg- menti della rete sia rilevante in corrispondenza di un cambiamento dell''in- stradamento, tra i due protocolli. Si va da un aumento del 18% sulla rotta da ''37'' a '9'' fino ad un aumento di più del 560% sulla direzione inversa da '9'' a '37''. CAPITOLO 6. RISULTATI SPERIMENTALI 68 Figura 6.2: Prestazioni e topologia di rete. Instradamento diretto. (Valori espressi in
[Mbit/s]) Figura 6.3: Prestazioni e instradamento con OLSR standard (Valori espressi in [Mbit/s]) Le altre variazioni del throughput in rete sono di entità nettamente infe- riore e quindi imputabili alle normali fluttuazioni delle prestazioni della comunicazione PLC. E'' interessante analizzare la latenza della rete sui per- CAPITOLO 6. RISULTATI SPERIMENTALI 69 Figura 6.4: Prestazioni e instradamento con OLSR ETT-PLC (Valori espressi in [Mbit/s]) corsi in cui cambiano le rotte. sorgente destinazione latenza OLSR [ms] latenza OLSR ETT-PLC [ms] 192.168.1.2 192.168.1.3 3.762 3.470 192.168.1.2 192.168.1.9 3.652 3.570 192.168.1.2 192.168.1.37 3.240 3.304 192.168.1.3 192.168.1.2 4.021 3.531 192.168.1.3 192.168.1.9 6.357 5.152 192.168.1.3 192.168.1.37 4.383 6.037 192.168.1.9 192.168.1.2 3.360 3.423 192.168.1.9 192.168.1.3 3.523 3.601 192.168.1.9 192.168.1.37 4.146 5.074 192.168.1.37 192.168.1.2 3.247 3.287 192.168.1.37 192.168.1.3 3.574 3.668 192.168.1.37 192.168.1.9 3.674 6.584 Si può notare che dove OLSR ETT-PLC introduce rotte con più hop, ab- biamo un aumento di latenza rilevante e non semplicemente imputabile alla variabilità della rete. Come visto nel capitolo 4 non è la distanza il fattore determinante nell''au- mento della latenza quanto l''elaborazione e la ritrasmissione che avven- CAPITOLO 6. RISULTATI SPERIMENTALI 70 gono nel device PLC che fa da next-hop nel nuovo instradamento. I valori di latenza sono anche influenzati dal rate trasmissivo. Sulla rotta da '9'' a '37'' si può infatti notare come nonostante l''aumento di 1 hop, la latenza cresca meno che negli altri casi perché compensata dal notevole aumento (560%) del rate di trasmissione. 6.3.2 Test: cambiamento di una singola rotta La topologia di rete e il throughput in condizioni di instradamento di- retto sono espressi in figura: Figura 6.5 Gli instradamenti realizzati dai due protocolli di routing sono esposti graficamente nelle figure: OLSR standard OLSR ETT-PLC CAPITOLO 6. RISULTATI SPERIMENTALI 71 Figura 6.6: Prestazioni e instradamento con OLSR standard (Valori espressi in [Mbit/s]) Figura 6.7: Prestazioni e instradamento con OLSR ETT-PLC (Valori espressi in [Mbit/s]) Dai grafici si può notare come il cambiamento nel throughput dei seg- menti della rete sia rilevante in corrispondenza di un cambiamento dell''in- stradamento, tra i due protocolli. Entrambe aggiungono una rotta multi-hop da '9'' a '37'' dal momento che CAPITOLO 6. RISULTATI SPERIMENTALI 72 i due nodi non potevano comunicare nella rete Homeplug AV semplice. Questa modifica è determinata dalla necessità di completare la topologia ed infatti le performance dei due protocolli sulla rotta è identica. La rotta da '9'' a '3'' che in OLSR standard è di un singolo hop diventa di due hop in OLSR ETT-PLC. La modifica porta ad un miglioramento mas- simo del throughput nella direzione da '9'' a '3'' pari al 280%. Per quanto riguarda l''analisi della latenza: sorgente destinazione latenza OLSR [ms] latenza OLSR ETT-PLC [ms] 192.168.1.2 192.168.1.3 3.762 3.470 192.168.1.2 192.168.1.9 3.652 3.570 192.168.1.2 192.168.1.37 3.240 3.304 192.168.1.3 192.168.1.2 4.021 3.531 192.168.1.3 192.168.1.9 3.981 5.822 192.168.1.3 192.168.1.37 4.383 6.037 192.168.1.9 192.168.1.2 3.360 3.423 192.168.1.9 192.168.1.3 3.523 4.356 192.168.1.9 192.168.1.37 6.307 5.452 192.168.1.37 192.168.1.2 3.247 3.287 192.168.1.37 192.168.1.3 3.574 3.668 192.168.1.37 192.168.1.9 6.143 5.731 Anche in questo caso possiamo notare come l''aumento della latenza sia legato all''aumento del numero di hop nell''instradamento. Nei casi in cui all''aumento del numero di hop si accompagna un aumento considerevole del throughput della rotta allora l''aumento di latenza è con- tenuto e meno penalizzante. Anche nel caso peggiore con aumenti della latenza dell''ordine dei 3 ms per ogni hop, possiamo garantire che anche il traffico sensibile al ritardo come il VoIP possa mantenere un livello di qualità accettabile anche con instrada- menti caratterizzati da numerosi hop dal momento che le soglie di latenza accettabile sono comunque maggiori di 100 ms. CAPITOLO 6. RISULTATI SPERIMENTALI 73 6.4 Analisi dei risultati La casistica di test implementata ha riguardato un gran numero di sim- ulazioni con variazioni sulla posizione e le interconnessioni dei device PLC sull''impianto elettrico. Quelle riportate rappresentano gli esempi più rilevanti di quello che è pos- sibile ottenere dall''impiego della soluzione basata su OLSR ETT-PLC. In futuro per poter mettere alla prova il protocollo in ambienti ancora più vicini ad uno scenario reale potrebbe essere interessante utilizzare un testbed composto da un numero ancora maggiore di nodi. Capitolo 7 Conclusioni Con il livello tecnologico raggiunto, le comunicazioni PLC sono final- mente in grado di ricoprire un ruolo rilevante nel mondo del networking domestico ma non solo. La fase di standardizzazione appena conclusa da IEEE porterà un nuovo impulso alla loro diffusione e ne favorirà un ingresso più capillare nell''elet- tronica di consumo. Affinché questo accada è necessario che alcuni deipunti a sfavore della tec- nologia vengano superati nel più breve tempo possibile. La mancanza di documentazione è un punto fondamentale che ha senz''al- tro limitato fino ad ora l''impulso della ricerca in ambito accademico. Le cose dovrebbero migliorare una volta che lo standard sarà ampiamente diffuso e pubblicamente disponibile. L''incertezza derivata dalla presenza nello standard di due tecnologie di liv- ello fisico distinte e non interoperabili tra loro rappresenta un''altra vari- abile importante per il successo. Se una di queste tecnologie sarà in grado di prevalere ed affermarsi come standard sarà più facile per i produttori scommettere sulle comunicazioni PLC ed anche la disponibilità di hard- ware e di conseguenza il suo prezzo ne risentiranno positivamente. L''ultimo fattore determinante per lo sviluppo delle PLC è la disponibilità 74 CAPITOLO 7. CONCLUSIONI 75 di device programmabili dotati di software aperto e modificabile. La più grande limitazione nel lavorare con una tecnologia come Homeplug AV è costituita infatti proprio l''impossibilità di accedere al software, studiarlo e modificarne il comportamento. Si è costretti, per ora, a fare affidamento su un interfaccia di comunicazione limitate e anch''essa non documentata. Come avvenuto per 802.11 con la proliferazione dell''hardware e del soft- ware open-source, similmente potrebbe accadere per le PLC. Un possibile svantaggio di questo processo è la frammentazione che potrebbe introdursi nella tecnologia. Attualmente essendo un sistema proprietario e chiuso, si ha la certezza che i device funzionino in maniera uniforme e perfettamente interoperabile. Con la diffusione di hardware più aperto e software open-source si rischia di ripetere l''esperienza di 802.11 dove il software di dispositivi diversi offre funzionalità diverse e non standardiz- zate oltre a quelle di base necessarie alla realizzazione della comunicazione e documentate negli standard. Il rischio sembra comunque calcolato ed è auspicabile che già nell''anno in corso alcuni di questi cambiamenti si mettano in moto. Il lavoro svolto in questa tesi ha testato punti di forza e di debolezza della tecnologia PLC attuale, dimostrando come l''impiego di una soluzione di routing multi-hop sia possibile e addirittura auspicabile. Dai test effettuati è emerso quanto l''ambiente di utilizzo possa influenzare il comportamen- to della trasmissione e quanto l''impiego su segmenti di rete elettrica più controllati, dotati di un minor numero di interconnessioni e sorgenti di dis- turbo porti a delle ottime prestazioni. In queste situazioni è anche molto più facile prevedere il comportamento e le performance ottenibili dalle PLC. La soluzione di routing sviluppata ottiene buoni risultati anche in uno sce- nario non ottimale come quello dell''impianto elettrico domestico, proprio perché è sviluppate per sfruttare al meglio le capacità della rete, costruendo il routing su informazioni specifiche ottenute dalla rete PLC. CAPITOLO 7. CONCLUSIONI 76 In quest''ottica è facile immaginare come con una specifica e dei device aper- ti e programmabili si potrebbe sviluppare ulteriormente questa soluzione andando a raccogliere un numero maggiore di informazioni e ad un livello più basso, senza mediazioni. Un altro possibile sviluppo futuro del lavoro potrebbe essere quello di portare l''implementazione attuale alla nuova versione di OLSR, operazione di cui si è già valutata e discussa la fattibilità. Ancora più interessante potrebbe essere portare il concetto di routing capacity- aware per reti PLC anche su altri protocolli di routing. Un metrica di routing di questo tipo infatti non è vincolata all''utilizzo su protocolli link-state ma potrebbe essere interessante il suo impiego in protocolli di tipo distance vector come AODV e BABEL. Appendice A Messaggi Homeplug AV ' 0x0014 - Central Coordination Discover List Request: Mostra la lista delle stazioni memorizzata dal Coordinatore. Fornisce per ogni stazione MAC address, TEI, SNID. ' 0x6020 - Get Bridge Infos Request ' 0x6038 - Get Network Infos Request: Mostra la lista delle stazioni HPAV presenti in rete completa di TEI, NID, MAC address del Coordinatore e ruolo della stazione nella rete logica HPAV ' 0x6048 - Get Network Stats Request: Elenca le stazioni remote HPAV e dà un''informazione sintetica sulla qualità del canale tra ogni stazione e quella locale. ' 0xA000 - Get Device/SW Version Request: Interroga la ROM del device per determinare l''id del chip Homeplug, la versione del firmware e la modalità di operazione. ' 0xA004 - Write MAC Memory Request: Funzione di basso livello per scrivere fino a un 1 kbyte di dati nella memoria del MAC. 77 APPENDICE A. MESSAGGI HOMEPLUG AV 78 ' 0xA008 - Read MAC Memory Request: Funzione di basso livello per leggere nella memoria del MAC. ' 0xA00C - Start MAC Request: Validazione del checksum di una regione di memoria del MAC. ' 0xA01C - Reset Device Request: Reset del dispositivo e conseguente riavvio. ' 0xA020 - Write Module Data Request ' 0xA02C - Get Watchdog Report Request: Validazione di una richiesta di reset al circuito watchdog. ' 0xA030 - Get Link Statistics Request: Fornisce dettagliate statistiche di trasmissione del livello MAC verso una stazione remota scelta. ' 0xA034 - Sniffer Mode Request: Abilita il device HPAV a inviare al terminale informazioni sullo stato del livello MAC e della trasmissione. ' 0xA038 Network Info Request (Vendor-Specific): Elenca le stazioni remote HPAV dando anche informazioni generali sulla rete come NID, SNID e indirizzo del Coordinatore. Per ogni stazione dà un''informazione sintetica sulla qualità del canale da e verso di essa. ' 0xA040 - Check Points Request ' 0xA048 - Loopback Request: Messaggio per testare l''attività di un dispositivo. ' 0xA04C - Loopback Status Request: Messaggio per testare l''attività di un dispositivo. APPENDICE A. MESSAGGI HOMEPLUG AV 79 ' 0xA050 - Set Encryption Key Request: Permette di definire la chiave crittografica comune di una rete logica HPAV. ' 0xA054 - Get Manufacturing String Request: Informazioni sul produttore del chip HPAV. ' 0xA058 - Read Configuration Block Request: Informazioni sulla memoria ROM del dispositivo. ' 0xA068 - Get Device Attributes Request: Informazioni sulla versione del chip HPAV e sulla versione del firmware installato. ' 0xA06C - Get Ethernet PHY Settings Request ' 0xA070 - Get Tone Map Caracteristics Request: Fornisce informazioni sulle modulazioni utilizzate in ogni sottopor- tante OFDM nell''utilizzo del canale tra la stazione locale e una stazione remota a scelta. Bibliografia [1] Xavier Carcelle. Power Line Communications in Practice. Artech House, 1 edition, 1 2009. [2] H.P.P. Alliance. Homeplug av white paper. [3] S. Galli and O. Logvinov. Recent developments in the standardiza- tion of power line communications within the ieee. Communications Magazine, IEEE , 46(7):64''71, 2008. [4] K. H. Afkhamie, S. Katar, L. Yonge, and R. Newman. An overview of the upcoming homeplug av standard. In Proc. Int Power Line Communications and Its Applications Symp , pages 400''404, 2005. [5] M. E. Hazen. The technology behind homeplug av powerline communications. Computer, 41(6):90''92, 2008. [6] S. Katar, L. Yonge, R. Newman, and H. Latchman. Efficient fram- ing and arq for high-speed plc systems. In Proc. Int Power Line Communications and Its Applications Symp , pages 27''31, 2005. [7] Atheros Product Brief. Ieee 1901 compliant homeplug av mac/phy transceiver, 2010. [8] S. Goldfisher and S. Tanabe. IEEE 1901 access system: An overview of its uniqueness and motivation. Communications Magazine, IEEE, 48(10):150''157, 2010. 80 BIBLIOGRAFIA 81 [9] Brian Dipert. How to kill the home networking industry, 2009. [10] T. Clausen and P. Jacquet. RFC3626: Optimized Link State Routing Protocol (OLSR). RFC Editor United States, 2003. [11] A. Tønnesen. Implementing and extending the optimized link state routing protocol . A. Tønnesen, 2004. [12] M.E.M. Campista, P.M. Esposito, I.M. Moraes, LHM Costa, OCM Duarte, D.G. Passos, C.V.N. de Albuquerque, D.C.M. Saade, and M.G. Rubinstein. Routing metrics and protocols for wireless mesh networks. Network, IEEE, 22(1):6''12, 2008. [13] Elektra Wagenrad. The olsr story, 2007. [14] D.S.J.D. Couto, D. Aguayo, J. Bicket, and R. Morris. A high- throughput path metric for multi-hop wireless routing. Wireless Networks , 11(4):419''434, 2005. [15] X. Carcelle and F. Fainelli. Faifa, an open source tool to configure homeplug devices, 2010. [16] Iperf, a modern alternative for measuring maximum tcp and udp bandwidth performance, 2008. [17] S. Katar, M. Krishnam, R. Newman, and H. Latchman. Harnessing the potential of powerline communications using the HomePlug AV standard. RF DESIGN, 29(8):16, 2006. [18] flex: The fast lexical analyzer, 2010. [19] Bison - gnu parser generator, 2010. [20] pcap: packet capture library, 2010.

Document Outline

Introduzione Le comunicazioni PLC e la tecnologia Homeplug AV Comunicazioni PLC PLC verso una standardizzazione Vantaggi e svantaggi delle comunicazioni PLC Sistemi di trasmissione PLC Reti PLC a basso voltaggio Lo standard industriale Homeplug AV Sviluppi futuri della tecnologia PLC: lo standard IEEE P1901 Le aree di interesse dello standard P1901 Caratteristiche tecniche delle tecnologie P1901 In-Home e Access Critiche alle tecnologie PLC e scenario futuro Protocolli e metriche di routing per reti multi-hop Reti PLC Protocolli di routing Lo scenario ad-hoc Protocolli reattivi Protocolli proattivi Protocolli ibridi Il protocollo OLSR Metriche di routing Routing multi-hop per reti Homeplug AV La gestione di una rete Homeplug AV Interfaccia di controllo HPAV Le prestazioni di una rete Homeplug AV Una soluzione di routing multi-hop OLSR e il routing Multi-hop per reti PLC Calcolo della metrica ETT-PLC in reti Homeplug AV Distribuzione delle associazioni IP-MAC_PLC Integrazione in OLSR Implementazione di PLC plugin per OLSR.org L'architettura software di OLSR.org Struttura a plugin e gestione della configurazione Plugin link quality e componenti del core di OLSR.org Realizzazione della soluzione di routing PLC PLC_plugin plc_service plc_distribution_service linklayer_plc_data Plugin link quality lq_ETT-PLC Altri aspetti implementativi Evoluzioni future Risultati sperimentali Descrizione del testbed Implementazione del testbed Presentazione dei risultati Test: cambiamento multiplo nell'instradamento Test: cambiamento di una singola rotta Analisi dei risultati Conclusioni Messaggi Homeplug AV


© Eiom - All rights Reserved     P.IVA 00850640186