Metodologie di autoconfigurazione, integrazione e testing di sistemi in reti wireless per applicazioni critiche

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Metodologie di autoconfigurazione, integrazione e testing di sistemi in reti wireless per applicazioni critiche"

Transcript

1 Università degli Studi di Firenze Dipartimento di Elettronica e Telecomunicazioni Dottorato di Ricerca in Ingegneria Informatica, Multimedialità e Telecomunicazioni XXIII Ciclo Metodologie di autoconfigurazione, integrazione e testing di sistemi in reti wireless per applicazioni critiche Tesi di Ing. Matteo Rosi Coordinatore: Tutori: Prof. Giacomo Bucci Prof. Romano Fantacci Ing. Laura Pierucci Anno Accademico 2009/2010

2 Indice Elenco delle figure Elenco delle tabelle Pubblicazioni Introduzione v ix xi xiii I Rete MANET autoformante ed integrazione con lo standard TETRA-DMO 1 1 CADAE: Channel Assignment DAEmon La generazione automatica della rete MANET Il problema del interference detection Assegnazione dei canali basato su una topologia ad albero Sviluppo demone CADAE Macchina a stati Risultati prestazionali TWNET: Tetra Wireless NETwork Lo standard Tetra Architettura DMO i

3 ii Indice Canale a trama temporale Indirizzi ed identità Scenari di servizio TETRA DMO La sicurezza nel Tetra DMO Integrazione rete Tetra DMO con rete wireless mesh Elementi costitutivi la rete TWNET Soluzione integrata Tetra/IP Nodo TWNET Sviluppo software di intercomunicazione Pe2Ne: Pei to Network Risultati II Testing funzionale per la sicurezza dell implementazione di protocolli di rete S.T.R.E.S.S Black-Box Testing Concetti di base Testing per la sicurezza del software Tecnologie di Black-box testing e stato dell arte Stato dell arte degli strumenti esistenti Sviluppo piattaforma S.T.R.E.S.S Generalità dei protocolli utilizzabili Componenti principali Utilizzo della piattaforma CLI: command line interface Risultati

4 Indice iii SIP DNS XMPP Sviluppi Futuri Conclusioni 205 Appendices 209 Definizione di ABNF in ABNF 211 Bibliografia 215

5 iv Indice

6 Elenco delle figure 1.1 Primo grafo di esempio Secondo grafo di esempio Terzo grafo di esempio Profondità media dell albero per blocchi di 200 simulazioni con numero di nodi variabili in area 300x Profondità media dell albero per blocchi di 200 simulazioni con numero di nodi variabili in area 400x Numero di ripetizioni di canali, con scenario 300x300 al variare del numero di nodi Numero di ripetizioni di canali, con scenario 400x400 al variare del numero di nodi Metri quadri della zona di interferenza in un area 300x Metri quadri della zona di interferenza in un area 400x State machine dell algoritmo implementato Caso di ricostruzione dell albero Struttura della trama temporale nel set-up di una chiamata senza presence check tramite repeater Call setup senza presence check v

7 vi ELENCO DELLE FIGURE 2.3 Struttura della trama temporale nel set-up di una chiamata con presence check tramite repeater Call setup con presence check Struttura temporale set-up chiamata di gruppo tramite DM- GATEway Sequenza degli scambi di PDU nel set-up della chiamata Diagramma temporale della segnalazione di set-up di chiamata con DM-GATE Struttura temporale set-up chiamata di gruppo tramite DM- GATEway Occupazione slot durante una chiamata in DMO Occupazione trama temporale durante pre-emption con la presenza di DM-Repeater Occupazione trama temporale durante la richiesta di pre-emption con DM-GATEway Scambio di messaggi durante la pre-emption al livello DMCC Scambio di messaggi durante la pre-emption al livello DMCC in presenza di DM-GATEway Occupazione trama temporale durante una richiesta di changeover Occupazione trama temporale durante una richiesta di changeover in chiamate di gruppo Occupazione trama temporale durante una richiesta di changeover in presenza di DM-REPeater Occupazione trama temporale durante una richiesta di changeover in presenza di DM-GATEway Scambio di messaggi durante changeover al livello DMCC... 67

8 ELENCO DELLE FIGURE vii 2.19 Scambio di messaggi durante changeover al livello DMCC in presenza di DM-GATEway Occupazione della trama per l invio di un SDS Occupazione della trama per l invio di un SDS in presenza di DM-REPeater Scambio di messaggi a livello DMCC durante l invio di SDS Diagramma funzionale dei meccanismi di encryption e decryption Schema dello scenario TWNET Interfacce e PDU presenti nello scenario integrato Macchina a stati finiti del Mobile Node sull isola origine Macchina a stati finiti del Mobile Node sull isola destinataria TWNET Call Setup Sequenza dei messaggi scambiati durante una chiamata senza presence check Diagramma delle classi Diagramma sequenziale Passaggio dei dati in ingresso lato rete multihop Modello a V del processo di sviluppo software Schema del funzionamento della piattaforma S.T.R.E.S.S Creazione dei messaggi utilizzando l albero ABNF Modello ABNF del protocollo POP3: creazione di traffico valido Esempio di inserimento di anomalie all interno del modello ABNF Esempio di pacchetto di login inviato durante una sessione valida del protocollo POP Diagramma delle classi del modello ABNF

9 viii ELENCO DELLE FIGURE 3.8 Rappresentazione della definizione ABNF del messaggio di login del POP Diagramma delle classi della componente Parser Diagramma sequenziale della procedura di parsing La classe Symbol Diagramma delle classi previsto secondo il pattern Strategy Esempio: come vengono associate le classi del pattern Strategy La classe ActionFactory Diagramma delle classi del sistema di inserimento automatico di anomalie Schema di funzionamento del monitor e scambio di messaggi con le componenti Diagramma delle classi del sistema di analisi del comportamento Diagramma delle classi delle risposte alle azioni dei test Esempio di State risultanti dall invio del pacchetto di login del POP Diagramma delle classi della parte di scrittura dell output Schema generale del funzionamento del dissector Diagramma delle classi del Dissector Diagramma di sequenza del Dissector Diagramma delle classi della componente di gestione dei test case

10 Elenco delle tabelle 1.1 Risultati delle simulazioni per un numero di nodi crescente Numero di canali riutilizzati, per un numero di nodi crescente, con possibilità di marcare canali occupati Profondità media dell albero Struttura degli indirizzi Tetra Occupazione di frame e slot nella chiamata diretta senza presence check Occupazione di frame e slot nella chiamata con presence check Schema del Header delle PDU TWNET Struttura dei pacchetti TWNET Campi del PDU CALL SETUP Valori dei campi del PDU CALL SETUP Valori degli attributi di TwnetCallData Campi del TRAFFIC PDU Valori dei campi del TRAFFIC PDU Campi del CALL TERMIANTED PDU Valori degli attributi del TERMINATED CALL PDU ix

11 x ELENCO DELLE TABELLE

12 Pubblicazioni 1. Rosi, M, Maccari, L, and Fantacci, R, S.T.R.E.S.S. : Stress Testing and Reverse Engineering for System Security, IEEE International Conference on Communications, Glasgow, Leonardo Maccari, Matteo Rosi, Romano Fantacci, Luca Maria Aiello, Marco Milanesio, Security analysis and improvement for Kademlia DHT, IEEE 2009 Internation conference on communications, Dresda, Luca Maria Aiello, Leonardo Maccari, Marco Milanesio, Matteo Rosi, Eclipse attacks in Kad networks, Italian Networking Workshop, Cortina, Luca Adamo, Romano Fantacci, Matteo Rosi, Daniele Tarchi, Federico Frosali, Analysis and Design of a TETRA-DMO and IEEE integrated network, Emergency Management-Communication and Computing Platforms Workshop Documentazione per il software C.A.Dae. Implementazione dell algoritmo di Network Auto-Forming 6. Report per Selex-Comms sullo studio di un algoritmo di Network Auto- Forming e risultati di simulazioni xi

13 xii Pubblicazioni 7. Maccari, L, Mando, G, Piccinocchi, L, and Rosi, M, EPO Patent Request PCT/IT/2008/000359: Modified Ad-Hoc On-Demand Distance- Vector Routing Protocol (2008) 8. Richiesta di brevetto Nodo TWNET 9. Richiesta di brevetto Trasmissione su seriale del traffico TETRA DMO 10. Richiesta di brevetto Estensione delle funzionalità Changeover e Preemption tipiche dello standard DMO allo scenario multi isola TWNET 11. Richiesta di brevetto Soluzione di sicurezza per la negoziazione di chiavi crittografiche per applicazioni Tetra DMO su reti etorgenee 12. N.3 Report per la Convenzione con Selex-Comms su: Design ed implementazione di un sistema di AAA e provisioning convergente per reti multifunzione Tetra WiMAX basato su RADIUS 13. Report per progetto europeo NI 2 S 3 D1.1: NEC/SOA state of the art 14. Report per progetto europeo NI 2 S 3 D4.1: Analysis and classification of software insecurities 15. Report per progetto europeo NI 2 S 3 D4.2: Definition of a suitable grammar to express networking protocols and design of the testing platform

14 Introduzione Il lavoro di ricerca svolto in questi anni si può suddividere in due filoni, il primo, in collaborazione con Selex-Communications, è incentrato sulla realizzazione di un infrastruttura di rete sicura e dinamica in grado di configurarsi autonomamente, al fine di fornire supporto a sistemi di comunicazioni professionali. Il secondo filone di ricerca invece è incentrato sulla realizzazione di una piattaforma di testing per la verifica della sicurezza in applicativi di rete. Nel contesto delle reti professionali i moderni sistemi di telecomunicazioni hanno riportato importanti risultati per quanto riguarda affidabilità, copertura ed ampiezza di banda, permettendone l uso in un ampia varietà di applicazioni e servizi. Tra le opzioni disponibili all interno nel mercato professionale il sistema Tetra ed in particolare modo la sua opzione DMO (modalità che permette la comunicazione diretta half duplex fra utenti senza il supporto di alcuna infrastruttura) ricopre un ruolo di rilevo. Questa modalità di comunicazione è stata oggetto di una collaborazione fra Università di Firenze e Selex-Comms per individuare una soluzione ai limiti tecnici e di design che da cui è limitata, il Tetra-DMO infatti non supporta comunicazioni multi hop, con vincoli sia sulla copertura che sulla scalabilità dell intera rete. L obiettivo di fondo raggiunto durante la tesi è stato quindi quella di integrare il Tetra-DMO con un sistema di comunicazioni wireless più flessibile xiii

15 xiv Introduzione (per esempio basato su IEEE ), dove la tecnologia DMO costituisse l accesso al servizio e che quindi permettesse l interoperabilità con gli altri terminali Tetra-DMO, mentre la tecnologia IEEE potesse essere utilizzata per fornire una flessibile e scalabile rete di backbone multi hop per interconnettere diverse isole Tetra-DMO. Uno scenario applicativo preso in considerazione è quello di situazioni di emergenza in caso di disastro naturale per fornire supporto alle unità di soccorso. In questi scenari gli operatori devono agire in situazioni ambientali critiche, come per esempio all interno di una metropolitana, dove le comunicazioni giocano un ruolo chiave per permettere soccorsi ed interventi tempestivi. Spesso però per fornire tali servizi non è possibile disporre, per impedimenti ambientali, di infrastrutture presenti. La rete integrata oggetto della tesi andrebbe a fornire quel supporto alle telecomunicazioni fondamentale per le procedure di emergenza. Il deployment di una rete multi hop permetterebbe quindi la creazione di un backbone di comunicazione per coprire luoghi difficilmente raggiungibili, in modo da fornire copertura wireless a banda larga per trasmissioni video e permettendo, tramite l integrazione con il Tetra-DMO, la comunicazione con un isola DMO all interno del luogo delle operazioni con le isole all esterno e con il centro operativo. Vedremo quindi il lavoro svolto in collaborazione con Selex- Comms che vedrà per prima cosa lo sviluppo di una rete wireless multi hop auto configurante, che ne permette il dispiegamento e l attivazione facilitata e completamente automatica, con particolare attenzione all ottimizzazione della banda dati e alla minimizzazione delle interferenze elettromagnetiche tipiche delle reti MANET. Successivamente verrà presentata la soluzione di integrazione TWNET (Tetra Wireless NETwork) per permettere il collegamento fra isole DMO differenti tramite la backbone multi hop. Il secondo filone di ricerca, sviluppato all interno del progetto europeo NI 2 S 3,

16 xv è stato incentrato sullo sviluppo di una metodologia di testing funzionale per implementazioni di protocolli di rete e sulla creazione di una piattaforma per l esecuzione di testing di robustezza. Informatica e telecomunicazioni stanno sempre più diffondendosi nella società moderna, diventando parte integrante di un gran numero di attività, molto comuni sia in quelle commerciali sia nella pubblica amministrazione, Certamente questo ha portato moltissimi vantaggi, sia da un punto di vista economico, per esempio aumentando la produttività dei lavoratori, sia da un punto di vista dei servizi forniti, aumentandone l accessibilità e la fruibilità. Il numero di utenti di tipologie diverse, dal professionista al ragazzo delle scuole medie che usufruiscono di sistemi di comunicazione ed accedono alla rete aumentano sempre di più. I mezzi con cui ci si connette cambiano, prima si utilizzavano prevalentemente PC, oggi si utilizzano smartphone, notebook, netbook, tablet pc, ebook reader ed addirittura le televisioni; anche gli elettrodomestici sono dotati di schede di rete wireless o ethernet per poter essere integrati in un sistema di domotica. Quindi è logico aspettarsi che nel portare l utilizzo della rete al centro di ogni aspetto della società moderna ci siano molti aspetti che richiedono particolare attenzione soprattutto dal punto di vista della sicurezza. A conferma di questo è sufficientepensare ad applicazioni di home banking, ma anche più semplicemente ai database centralizzati a livello regionale contenenti tutti i dati sensibili sanitari di tutti i cittadini italiani. Fondamentale diventa una corretta gestione della sicurezza dei sistemi e delle informazioni in essi contenuti, con un attenta configurazione ed analisi delle componenti coinvolte. Per compromettere la sicurezza dei sistemi infatti basta un dettaglio, un solo anello debole per rendere inutili tutte le precauzione prese. Si rende quindi necessario assicurarsi che gli applicativi utilizzati non presentino alcun tipo di vulnerabilità che possa essere sfruttata de un eventuale attaccante. Quindi

17 xvi Introduzione si rende fondamentale la necessità di eseguire dei test per assicurare che non vi siano errori nei componenti software e soprattutto in quei programmi che vanno ad implementare delle funzionalità di comunicazione via rete. Errori che se si manifestano, possono venir sfruttati da attaccanti e quindi produrre quelle vulnerabilità dei sistemi che causano danni sia economici che lesivi dei diritti personali (per esempio violazione della privacy). Durante l attività di ricerca svolta in questi anni è stata ideata una metodologia per svolgere attività di testing di robustezza su varie implementazioni di protocollo e che potesse essere utilizzata con standard differenti ed in differenti layer della pila ISO/OSI, inoltre illustreremo lo sviluppo di una piattaforma per permettere l esecuzione dei test, introducendo elementi di automazione ed analisi del comportamento delle componenti sotto test per agevolare il processo.

18 Parte I Rete MANET autoformante ed integrazione con lo standard TETRA-DMO

19

20 Capitolo 1 CADAE: Channel Assignment DAEmon La prima parte del progetto di collaborazione prevede la creazione di un sistema per il deploy facilitato di una rete mesh in grado di ovviare a problemi di interferenze elettromagnetiche sia con altre reti wireless già presenti sia con rami della medesima rete di backbone; verrà quindi presentato sia l algoritmo ideato per l auto forming di tale rete che il prototipo di software che andrà ad implementare tale algoritmo e che girerà sui nodi della rete mesh di backbone. La rete auto formante sarà costituita da router dotati di 4 interfacce wireless, 3 di queste saranno dedicate alla costruzione della rete di backbone e saranno interfacce wi-fi di tipo IEEE a quindi con portante a 5 Ghz mentre la quarta sarà un interfaccia wi-fi di tipo IEEE g per la fornitura del servizio di connettività dati. I router saranno dotati di una particolare versione sistema operativo GNU/Linux specifica dei dispositivi embedded, per l esattezza OpenWRT Kamikaze 8.09 [1]. Questi device necessitano di una alimentazione Power over Ethernet e saranno dotati di sistema di alimentazione a batteria in modo da poter essere facilmente dislocati senza 3

21 4 Capitolo 1. CADAE: Channel Assignment DAEmon alcun problema. Le schede di rete wireless sono tutte basate su chipset atheros ed il loro funzionamento sarà gestito dai driver presenti nel kernel linux MadWIFI [2] 1.1 La generazione automatica della rete MANET L assegnazione dei canali su una rete mesh, con lo scopo di minimizzare il grado di interferenza tra due link della stessa rete è un tema su cui si sta sviluppando un filone di ricerca nuovo ed attivo. Il problema del channelassignment, da un punto di vista teorico rimane un problema irrisolto, se non con soluzioni parziali o che fanno leva su euristiche non applicabili a tutti i contesti, visto che le implicazioni teoriche del problema stesso sono particolarmente difficili da affrontare. Da un punto di vista generale, il problema di scegliere i canali su una rete mesh è assimilabile ad una delle varianti del problema teorico di colorazione di un grafo. Tale problema è ben noto in letteratura, e può essere descritto come segue: dato un grafo, e un insieme finito di colori, associare ad ogni arco del grafo un colore preso dall insieme a disposizione in modo che non esista un nodo della rete collegato a due archi dello stesso colore. Calato nella pratica delle reti mesh, ogni arco è un link, ogni colore è un canale, in questo modo si garantisce che ogni nodo non possieda due link sulla stessa frequenza, e quindi che si fanno interferenza. Alcune precisazioni sono necessarie: il miglior algoritmo per la risoluzione del problema della colorazione del grafo è dimostrato essere NP-completo, quindi non esiste un algoritmo efficiente per trovare una soluzione. Inoltre, non sempre esiste una soluzione al problema;

22 1.1. La generazione automatica della rete MANET 5 il modello della colorazione del grafo non descrive efficacemente il problema in tutti i suoi lati. Un nodo può provocare interferenza anche verso un altro nodo con cui non condivide nessun link, per il noto problema del nodo nascosto; gli algoritmi di colorazione del grafo, presuppongono la conoscenza a priori di tutto il grafo ed agiscono come un entità centralizzata. In una rete mesh non si può fare un assunzione di questo tipo, ma l algoritmo dovrebbe funzionare in modo distribuito e cooperativo tra i nodi; una volta trovata una soluzione, l assegnazione dei colori agli archi non è indipendente, ma cambiare il colore di un solo arco può implicare una riconfigurazione di altri archi del grafo. In altre parole, una volta trovata una soluzione per un dato grafo, non è detto che trovare una soluzione per lo stesso grafo leggermente modificato (ad esempio per la caduta di un link) sia più facile che trovare una partendo da zero. Inoltre, la riassegnazione di un canale non può essere effettuata in modo efficiente utilizzando le informazioni posseduta da un singolo nodo, perché si rischia sempre di produrre l effetto del nodo nascosto. Da queste basi, esistono articoli in letteratura che presentano soluzioni particolari, applicabili in contesti limitati, o che prevedono grossi interventi sullo strato MAC. Ad esempio, Raniwala [3] introduce un algoritmo centralizzato per la channel-assignment in reti mesh. In un successivo articolo si introduce anche la possibilità di realizzarne una variante distribuita, ma con un notevole aumento di complessità. Altre tecniche si concentrano sull assegnazione di un set di canali in cui ogni scheda di rete viene collegata sempre allo stesso canale, ed all utilizzo di tecniche per la decisione del link da utilizzare per ogni pacchetto [4], o ad euristiche basate sui dati di una

23 6 Capitolo 1. CADAE: Channel Assignment DAEmon parte limitata della rete [5]. Dovendo realizzare una soluzione attuabile nella pratica sugli apparati mesh forniti, si è scelto un algoritmo che non prevede cambiamenti ai livelli MAC (condizione necessaria per poter essere applicato), e che pur rappresentando una soluzione sub ottima nel contesto generale, fornisce buone prestazioni nel contesto di rete identificato dalla convenzione. Tale contesto è il seguente: rete di piccole dimensioni (5 nodi fissi più un gateway) ma estendibile ad un numero di nodi superiore nodi equipaggiati con 3 schede di rete per la formazione del backbone assenza di mobilità necessità di riconfigurazione solo temporanea. L ultimo punto deriva da quanto detto in precedenza sulla riorganizzazione di una rete già formata. Una volta stabilita una configurazione iniziale ottima, questa non viene rimessa in discussione se un link si rende indisponibile. Quello che succede è che un nodo che si ritrova momentaneamente isolato si appoggerà su un canale già occupato da altri nodi, almeno fino a quando il link iniziale non viene ripristinato. L algoritmo descritto nella sezione successiva è stato realizzato su un simulatore, con lo scopo di verificare la bontà dello schema di allocazione dei canali scelto. Lo scenario simulato è un astrazione di una rete mesh reale, quindi serve a giudicare la distribuzione dei canali, nella fase implementativa si verificheranno le prestazioni e le modifiche necessarie perché sia funzionante sulle piattaforme hardware scelta per lo sviluppo del prototipo.

24 1.2. Il problema del interference detection Il problema del interference detection Algoritmi avanzati di interference detection esistono in letteratura, ma possono essere utilizzati avendo il controllo dei parametri di basso livello della comunicazione. Il driver madwifi maschera il comportamento dei componenti di basso livello della scheda di rete e si interfaccia con un modulo proprietario chiamato hal, che include tutta la parte di elaborazione del segnale. Le uniche informazioni che vengono restituite allo spazio utente sono i risultati delle scansioni prodotte dalla scheda di rete. Le scansioni restituiscono il numero di altre reti trovate nel raggio di copertura dell apparato, insieme al rapporto segnale/rumore per ciascuna di esse. Avendo a disposizione solo questi dati, l algoritmo di interference detection si riduce ad un semplice ranking dei canali a disposizione, escludendo quelli già occupati da altri access point ordinati per la potenza del segnale ricevuto. La funzione di scan fornita dal driver madwifi infatti restituisce una lista degli AP il cui segnale è ricevuto dalla stazione client, insieme al valore dell intensità del segnale ricevuto. Con questi strumenti a disposizione, dopo la scansione si dà un giudizio sul grado di interferenza relativo al canale prescelto, tale valore può essere calcolato come la somma delle potenze ricevute dagli AP circostanti. Considerato che il traffico all interno di una rete wifi può essere molto variabile nel tempo, a seconda del numero di utenti e del tipo di traffico che essi generano, non sembra plausibile introdurre una fase di scansione temporale limitata, in cui su ogni canale il nodo prescelto ascolta in modalità monitor per un periodo prolungato, con lo scopo di stimare il carico della rete con cui si fa interferenza. Con una strategia simile, infatti, un nodo potrebbe spenderebbe alcuni secondi per ogni canale prescelto, ascoltare tutto il traffico su quel canale e stimare con più precisione il livello di interferenza che incontrerebbe su quella frequenza. Tale stima deve essere ripetuta nel tempo, altrimenti perde di

25 8 Capitolo 1. CADAE: Channel Assignment DAEmon significato, ma per poterla realizzare è necessario cambiare la modalità usata dalla scheda (che viene spostata in modalità monitor), interrompendo così il suo normale funzionamento. Durante la fase di scansione, che può essere effettuata anche in background, ovvero senza che la scheda cambi modalità o si disconnetta dal proprio access point (se viene utilizzata in modalità client), la scheda non rimane un tempo sufficiente sullo stesso canale per poter ricevere sufficiente traffico e poter realizzare una stima del carico sulla rete. L unica soluzione rimane quella di basare il ranking delle frequenze su due parametri, il numero di AP che vengono individuati su un determinato canale, e la potenza del segnale ricevuto da quegli AP. La potenza è un valore in db che viene esportato dalle schede di rete attraverso le interfacce standard wireless extension del kernel di linux, quindi una somma normalizzata del valore di potenza riportato per ogni AP su quel canale sembra essere la stima migliore per definire il livello di occupazione del canale Assegnazione dei canali basato su una topologia ad albero Il tipico scenario di rete associabile all utilizzo degli apparati mesh è quello di una rete in cui un gateway, equipaggiato con una o due schede di rete fornisce connettività verso l esterno, e gli altri nodi vengono utilizzati per costruire una magliatura che copra la maggiore superficie possibile. Più che di una vera rete mesh, si può parlare di una topologia ad albero, in cui il nodo gateway divide la rete in due tronconi. Si immagina anche che la maggior parte del traffico sia diretto da e verso i nodi della rete all esterno, e che venga comunque instradato dal gateway stesso. L algoritmo sfrutta questa naturale gerarchia della rete suddividendo l insieme dei canali utilizzabili in

26 1.2. Il problema del interference detection 9 due sottoinsiemi e introducendo delle politiche di fail-over in caso di problemi di connessione. L algoritmo può essere descritto brevemente come segue: ogni nodo, gateway escluso, utilizzerà una scheda di rete in modalità managed, con cui si lega al suo padre, e due schede di rete in modalità master a cui si legheranno i suoi figli. Ogni scheda in modalità master accetta un unico figlio come client, l albero che si crea è binario. Il nodo gateway, se equipaggiato con due schede di rete, le utilizza entrambe in modalità master, e nel pacchetto di beacon specifica due parametri: il primo indica la sua profondità nell albero (che sarà ovviamente 0), il secondo è il sotto albero a cui è associata la scheda di rete (destro o sinistro). Da notare che se il gateway è equipaggiato con una sola scheda di rete, lo stesso principio può essere applicato usando due sotto reti virtuali appoggiate sulla stessa scheda. Il gateway quindi divide la rete in due tronconi, sulla sotto rete destra si useranno i canali pari, su quella sinistra si useranno i canali dispari. I nodi che non sono gateway, inizieranno una scansione con la scheda in modalità client. In questo modo riceveranno la presenza dei beacon del gateway e tenteranno di connettersi ad una delle sue schede, ma solo uno per scheda di rete (reale o virtuale) sarà in grado di autenticarsi. Inoltre la scansione serve a capire se ci sono altri nodi che utilizzano altri canali nella stessa zona. Un nodo associato al gateway sponsorizzerà nei propri beacon una profondità pari a 1. se un nodo non riesce a collegarsi al gateway perché non riceve i suoi beacon o perché non viene autenticato, ripeterà la procedura di scan per cercare dei nodi a profondità 1, e tentare di connettersi. Una volta trovato un padre, il risultato della ultima scansione viene utilizzato

27 10 Capitolo 1. CADAE: Channel Assignment DAEmon anche per scegliere i canali più liberi su cui impostare le schede master a cui si connettono i propri figli. Preferibilmente, il nodo sceglierà un canale libero, superiore a quello usato dal padre. In questo modo scendendo nell albero si scelgono canali con indice più alto, e si evita il fenomeno del nodo nascosto. Una volta arrivati in fondo alla lista dei canali utilizzabili si riparte dal primo. Figura 1.1: Primo grafo di esempio La suddivisione dei canali in pari e dispari fa sì che avvenga una distribuzione migliore delle frequenze. Due nodi che sono in range di trasmissione infatti si accorgono della presenza reciproca e possono evitare di scegliere lo stesso canale. Se i due nodi non sono in range invece non possono accordarsi, quindi potrebbero produrre interferenza su un terzo nodo che è nel range di entrambi, per il problema del nodo nascosto. L impatto di tale problema può essere limitato se nodi in posizioni geografiche diverse utilizzano canali diversi. Questo viene garantito nella profondità dell albero utilizzando i canali in modo incrementale, e viene reso più efficace anche discriminando i canali tra la metà destra e sinistra dell albero. Lo schema così descritto realizza in mo-

28 1.2. Il problema del interference detection 11 Figura 1.2: Secondo grafo di esempio Figura 1.3: Terzo grafo di esempio

29 12 Capitolo 1. CADAE: Channel Assignment DAEmon do molto semplice un allocazione dei canali che per reti di piccole dimensioni si rivela, secondo le simulazioni effettuate molto efficiente. In reti di piccole dimensioni basate su IEEE a [6] (in cui esistono 12 canali separati in frequenza) il problema della colorazione del grafo si riduce di complessità visto che aumentando i canali a disposizione in relazione al grado del grafo (il numero massimo di vicini di ogni nodo) si alleggeriscono i vincoli. Le modifiche necessarie al MAC per realizzare l algoritmo sono minime, le informazioni aggiuntive nel beacon possono essere inserite in un campo ad-hoc se il driver lo permette, o più semplicemente direttamente nel nome della rete (essid). Il fail-over viene gestito utilizzando una scheda virtuale di backup per ogni nodo. Può succedere infatti che se un link diviene inutilizzabile un nodo si trovi isolato dalla rete. Ad esempio, se il suo unico vicino ha già due figli e quindi non accetta più connessioni. Questa situazione, che si genera molto raramente nella fase di deployment (le simulazioni mostrano che per 1000 topologie differenti con 5 nodi più un gateway solo 9 nodi rimangono isolati) può avvenire in presenza di cambi di topologia (per qualche motivo un link diventa inutilizzabile). La situazione viene risolta aggiungendo per ogni scheda di rete in modalità master un essid virtuale, di backup. Su questo essid non c è limite di client connessi contemporaneamente, quindi se un client rimane orfano in un dato istante, può connettersi ad un essid di backup che riesce a trovare. L essid di backup condivide il canale con una scheda in modalità master, quindi la banda a disposizione è condivisa tra due client, due osservazioni sono necessarie: In un contesto di rete ad albero, la condivisione dello stesso link non implica automaticamente limitazione di banda. Per comprendere questa affermazione si osservino le figure 1.1, 1.2 e 1.3. Il link tra il nodo gateway e il nodo 1 rappresenta comunque un collo di bottiglia per

30 1.2. Il problema del interference detection 13 Nodi Nodi orfani Altezza media Tabella 1.1: Risultati delle simulazioni per un numero di nodi crescente il traffico da e verso la rete, quindi la disposizione dei nodi nel sotto albero sinistro non influisce realmente sulle prestazioni della rete nel traffico di ingresso e uscita. Chiaramente però aumentare il numero di nodi sullo stesso link può rendere il MAC più inefficiente, quindi è consigliabile tornare, quando possibile alla configurazione iniziale. Per questo motivo, il client può produrre delle scansioni in background alla ricerca del suo vecchio link e ricollegarcisi nel caso in cui il link ritorni disponibile. Risultati delle simulazioni L algoritmo è stato valutato utilizzando il framework Omnet++ su piattaforma GNU/Linux. Le simulazioni hanno dimostrato che in reti fino a 7 nodi di backbone più un gateway l algoritmo è molto efficiente. In tabella 1.1 si riportano alcuni risultati prodotti su 100 simulazioni con topologie random. Dalla tabella si evidenzia che all aumentare dei nodi di backbone il numero di nodi orfani (nella seconda colonna della tabella è riportata la somma totale su tutte e 100 le simulazioni) non è rilevante, i nodi avrebbero comunque la possibilità di connettersi ad una interfaccia di backup (possibilità che nella simulazione non è stata implementata). La terza colonna riporta l altezza media dell albero nelle simulazioni effettuate. Una ulteriore valutazione è stata effettuata permettendo ai nodi della backbone di

31 14 Capitolo 1. CADAE: Channel Assignment DAEmon Tabella 1.2: Numero di canali riutilizzati, per un numero di nodi crescente, con possibilità di marcare canali occupati Tabella 1.3: Profondità media dell albero scegliere, in modo casuale fino a tre canali che non possono essere utilizzati. In questo modo si simula la possibilità di un nodo di non poter utilizzare un dato canale per l interferenza generata da parte di reti terze. Nel momento in cui deve scegliere i canali da assegnare alle proprie schede di rete master, oltre ai risultati della scansione si scelgono anche fino a tre canali marcati come occupati. Il numero di nodi orfani che si misurano dopo 1000 simulazioni di questo tipo è inferiore allo 0.5% del totale dei nodi utilizzati. In tabella 1.2 si riporta il numero di volte che un canale viene riutilizzato (in media) per ogni simulazione, all aumentare (sulle colonne) del numero massimo di canali marcati occupati da un nodo. Si vede che le interferenze anche dovute al nodo nascosto, con un tasso di riutilizzo delle frequenze così basso non producono un danno rilevante, in ogni caso, ci si aspetta che la scelta incrementale del numero di canale minimizzi l effetto del nodo nascosto. Aumentando il numero di nodi, si aumenta anche la profondità media dell albero, come riportato nella tabella 1.3.

32 1.2. Il problema del interference detection 15 Sono poi stati valutati degli scenari più generali, in particolare sono state considerate situazioni con un numero maggiore di nodi e una area geografica maggiore. Lo scopo delle simulazioni era verificare la scalabilità dell algoritmo. Utilizzando un numero di nodi maggiore il numero di volte che lo stesso canale viene riutilizzato aumenta, ma aumenta anche la superficie totale coperta dalla rete quindi usare più volte lo stesso canale non significa automaticamente generare interferenze. Per valutare l ampiezza delle zone di sovrapposizione quindi è stato necessario modificare il codice delle simulazioni per produrre un analisi più dettagliata sul numero di metri quadri in cui c è sovrapposizione, piuttosto che sul numero di riutilizzi del canale stesso. Sono state effettuate prove con un numero di nodi da 5 a 15, in aree di quadrate di lato 300m e 400m. Per ogni nodo si considera una zona di copertura circolare di raggio 150m, secondo le stime effettuate con il simulatore. Per ogni scenario sono state effettuate 200 simulazioni, ognuna con topologia casuale. Dai risultati sono state eliminate le simulazioni che rappresentavano un caso irrisolvibile, ovvero quelle simulazioni in cui un nodo, per via della disposizione casuale, cascava all esterno della zona di copertura di ogni altro nodo, rimanendo isolato. Le grandezze misurate sono: i metri quadrati dell area di copertura ovvero la somma delle aree coperte da ogni AP, senza contare più volte le intersezioni; l area totale della zona di interferenza, ovvero la somma delle aree di intersezione in cui gli AP che si sovrappongono usano lo stesso canale. Questa grandezza ci dà una stima della percentuale della superficie totale in cui possono avvenire collisioni; la profondità media dell albero che si viene a creare;

33 16 Capitolo 1. CADAE: Channel Assignment DAEmon il numero di ripetizioni nell utilizzo di un determinato canale, per tutti i canali; il numero di nodi orfani, ovvero nodi che hanno come unico punto di attacco alla rete un altro nodo che ha già le sue interfacce occupate con altri, quindi non accetta più connessioni. Il primo valore significativo è quello che riguarda i nodi orfani che è minore dello 1% in ogni simulazione effettuata. Nello scenario 400x400, per un blocco di 200 simulazioni con una media di 10 nodi per simulazione, si ha una media di 11 nodi orfani, quindi immaginando di avere 200 deployment diversi della stessa rete contenente mediamente 10 nodi, solo 11 non riescono a collegarsi, con una percentuale dello 0.55%. Nello scenario 300x300 la percentuale è ancora inferiore. Per quello che riguarda la profondità dell albero, il grafico 1.4 mostra la distribuzione delle profondità al variare del numero dei nodi della simulazione. La profondità massima è di 5 hop, e la maggioranza delle simulazioni producono una profondità tra 3 e 4 hop, con la simulazione con 9 nodi a fare da elemento intermedio. In figura 1.5 si riporta lo stesso grafico per la superficie 400x400, in cui i risultati sono molto simili, si nota però un lieve spostamento verso sinistra del grafico, aumenta il numero di simulazioni con profondità 5 e la simulazione con 9 nodi ha una maggioranza di risultati con profondità 4. Lo spostamento è dovuto all incremento dell area, che dispone i nodi mediamente più lontani, quindi non sempre è possibile costruire un albero bilanciato. La figura 1.6 mostra il numero di volte che nella stessa rete viene riutilizzato un canale per la topologia 300x300. Ogni volta che un canale viene riutilizzato, anche in zone diverse della rete si incrementa questo valore di uno. Non vengono considerati i canali scelti dalle foglie dell albero per le schede in modalità master, perché pur occupando un canale,

34 1.2. Il problema del interference detection 17 non producono traffico non avendo figli. Avendo a disposizione molti canali (12) il numero di ripetizioni rimane molto basso. Per la topologia 400x400 l effetto è lo stesso che per la profondità dell albero, aumentando la profondità c è anche un maggiore riuso dei canali. Infine, nella figura 1.8 viene riportata l area totale coperta dagli AP, e l area totale di sovrapposizione dei canali. Si osservi che su una superficie totale di MQ, già con 10 nodi si ha una copertura quasi totale della zona ed aumentando il numero di nodi, l unico effetto è quello di aumentare la superficie in cui avvengono collisioni. Nella figura 1.9 lo stesso grafico viene riportato per un area di MQ. Anche in questo caso aumentando il numero di nodi si aumenta il numero totale di MQ di copertura ma si aumenta anche il numero di MQ di interferenza, anche se le distanze mediamente maggiori allontanano i nodi tra loro e quindi diminuisce l area di sovrapposizione. Conclusioni Le simulazioni dimostrano che l area di interferenza su superfici di 300x300 e 400x400 metri rimane comunque limitata specialmente nel caso della superficie maggiore. Questo ha come conseguenza l aumento della profondità dell albero, quindi l aumento del numero di hop medi di un pacchetto verso il gateway. Da notare anche come l aumento della profondità dell albero comporta anche maggiore spesa di riconfigurazione nel caso di cambio di topologia, ma una maggiore densità di AP nella stessa area permette collegamenti migliori tra gli AP stessi. Dalle simulazioni non è possibile stimare le prestazioni in termini di traffico. Appare chiaro che deve essere trovato un trade-off sul numero di nodi utilizzati, visto che aumentalo significa garantire maggiore copertura e migliori collegamenti, ma anche maggiore delay e maggiore interferenza.

35 18 Capitolo 1. CADAE: Channel Assignment DAEmon Figura 1.4: Profondità media dell albero per blocchi di 200 simulazioni con numero di nodi variabili in area 300x300 Figura 1.5: Profondità media dell albero per blocchi di 200 simulazioni con numero di nodi variabili in area 400x400

36 1.2. Il problema del interference detection 19 Figura 1.6: Numero di ripetizioni di canali, con scenario 300x300 al variare del numero di nodi. Figura 1.7: Numero di ripetizioni di canali, con scenario 400x400 al variare del numero di nodi.

37 20 Capitolo 1. CADAE: Channel Assignment DAEmon Figura 1.8: Metri quadri della zona di interferenza in un area 300x300. Figura 1.9: Metri quadri della zona di interferenza in un area 400x400.

38 1.3. Sviluppo demone CADAE Sviluppo demone CADAE Una prima implementazione dell algoritmo è stata sviluppata in ruby e implementata sulle macchine costituenti la rete mesh, in un testbed composto da un nodo fisso con una sola interfaccia (il gateway) e tre nodi equipaggiati con 4 interfacce di rete, di cui tre per il backbone e una per la copertura. Inoltre iè stato scelto di utilizzare per comunicare e pilotare le schede wireless solamente strumenti di sistema presenti in tutte le distribuzioni linux, in modo da assicurarci un funzionamento delle schede omogeneo anche su macchine diverse. Per la precisione sono stati usati i seguenti pacchetti software: wireless-tools: una serie di tool per configurare la modalità di configurazione delle schede, il canale di ascolto e tutte le configurazioni base della scheda; wpa-supplicant: tool per lo scanning dei canali e per l autenticazione verso access point utilizzando i vari algoritmi di comunicazione previsti dallo standard; hostapd: software di emulazione di access point e autenticator, implementa funzionalità avanzate che non vengono fornite da una scheda in modalità master, come ad esempio il numero massimo di client associati e autenticazioni WPA. L implementazione dell algoritmo è quella descritta nella macchina a stati di figura 1.10, nella fase attuale non sono state implementate le procedure di backup.

39 22 Capitolo 1. CADAE: Channel Assignment DAEmon SEARCH_PARENT scan found_ap connect_timeout retry_max go_search CONNECTING connect to best AP ENABLE_BK enable_bk_ssid found_parent found_bk CONNECTED set_params BK set no_params_bk reconnect_timeout go_watch go_watch WATCH_CONNECTION watch_loop lost reconnected LOST retry_and_check Figura 1.10: State machine dell algoritmo implementato

40 1.3. Sviluppo demone CADAE Macchina a stati L applicazione se avviata con il parametro gateway si aspetta di trovare una sola scheda di rete, fa una scansione dei canali liberi, una volta effettuato il ranking basandosi sul numero e sulla potenza degli AP presenti in ogni canale, sceglie un canale e fissa tre essid virtuali, 0 L, 0 R, backup. Per ogni essid si fa partire un istanza di hostapd, impostando il parametro max num sta ad 1 in modo che ad ogni ssid non si possa collegare più di una stazione. Se avviato senza tale parametro, una scheda di rete viene avviata in modalità managed e si inizializza una macchina a stati composta da 7 stati: SEARCH PARENT: In questo stato si richiamano le funzioni di scan, utilizzando l applicativo wpa cli. Si fa il ranking delle risposte, e si configura wpa supplicant attraverso wpa cli rendendo enabled le reti migliori e rispettando il ranking realizzato nella scansione, tra le risposte ricevute si eliminano gli essid backup. A quel punto si va nello stato CONNECTING. Se non si trovano essid validi dopo un numero parametrizzabile di tentativi ci si sposta nello stato ENABLE BK ENABLE BK Questo stato è uno stato fittizio, realizzato solo per chiarezza e per esigenze di logging. In questo stato vengono abilitati anche gli ssid backup e si torna allo stato SEARCH PARENT. CONNECTING: attraverso wpa cli si iniziano i tentativi di connessione alle reti identificate nella fase di scan. Se dopo 5 secondi la scheda non è ancora connessa, si setta a disable l essid scelto e si passa al successivo. Se tutta la lista fallisce si torna a SEARCH PARENT, se si ottiene una connessione si passa a CONNECTED, se la connessione ottenuta è su un essid backup si passa a BK.

41 24 Capitolo 1. CADAE: Channel Assignment DAEmon CONNECTED: si impostano le 2 interfacce master su due canali liberi, dopo aver effettuato una nuova scansione, e gli si assegnano degli essid del tipo X L, X R dove X è la profondità del padre aumentata di uno. Si passa in WATCH CONNECTION. BK: senza impostare le schede in modalità master si passa allo stato WATCH CONNECTION. Un nodo collegato ad un interfaccia di backup infatti è il terzo nodo collegato al genitore, altrimenti avrebbe trovato libero uno degli altri due essid. Si vuole evitare che altri nodi scelgano questo nodo come genitore a loro volta, sovraccaricando quel ramo. Dalle simulazioni effettuate risulta comunque che il caso in cui un nodo abbia bisogno di un interfaccia di backup è molto raro. WATCH CONNECTION: in questo stato, periodicamente si controlla lo stato della connessione verso il padre, se la connessione viene persa, si passa nello stato LOST LOST: per tre tentativi intervallati da un secondo si controlla se la connessione è stata recuperata, alternativamente, si abbattono le schede in modalità master, si aspetta un secondo per dare il tempo ai propri figli di scollegarsi e si ritorna nello stato SEARCH PARENT Risultati prestazionali Sono state effettuate dieci prove in sequenza per validare l approccio e le prestazioni del codice, che è tuttora sperimentale. L instabilità delle macchine utilizzate nel testbed ha reso più difficile lo svolgimento dei test stessi. Durante le prove effettuate l albero viene sempre costruito correttamente, a differenza delle simulazioni però le scansioni sono più imprevedibili, non sempre dopo una scansione un nodo riesce a riconoscere tutti i suoi vicini,

42 1.3. Sviluppo demone CADAE 25 il numero di scansioni è quindi stato aumentato a 3 consecutive prima di passare nello stato connecting. Inoltre, il figlio destro di un nodo aspetta sempre un secondo, per permettere all eventuale figlio sinistro di collegarsi per primo. Altrimenti i due nodi faranno scansioni contemporaneamente e non si troveranno a vicenda. Su 10 test effettuati il primo nodo a connettersi alla rete impiega mediamente circa 12 secondi, il secondo nodo intorno ai 40, perché generalmente prova a connettersi allo stesso ssid già occupato dal primo fallendo. Il terzo, fallisce due volte di seguito, perché prova prima gli ssid a livello 0 che sono già occupati, quindi cercherà di connettersi ad un nodo di livello 1, mediamente impiega un minuto per connettersi. I fallimenti sono dovuti al fatto che altri nodi potrebbero già essere collegati all AP scelto, quindi l AP non permetterà altre connessioni per mantenere l albero al più in forma binaria. Durante le prove sono stati effettuati dei tentativi di disconnessione e riconnessione di un nodo intermedio nell albero, come descritto in figura Come ci si attendeva, dalla situazione iniziale (1) per un evento di disconnessione (spegnimento della macchina) la macchina L2 diventa la L1 ovvero il secondo figlio del GW (2), nel momento in cui la macchina viene riaccesa non trovando più libere le interfacce del GW che vengono scelte con preferenza sulle altre, il nodo diventa figlio di uno dei due nodi già connessi all albero (3).

43 26 Capitolo 1. CADAE: Channel Assignment DAEmon Figura 1.11: Caso di ricostruzione dell albero

44 Capitolo 2 TWNET: Tetra Wireless NETwork La seconda parte della collaborazione con Selex-comms prevede l utilizzo della rete mesh auto configurata dal software CADAE per estendere il sistema di comunicazione Tetra DMO. Il protocollo Tetra [7] fornisce un sistema di telecomunicazioni in gradi di garantire sia sicurezza che affidabilità delle comunicazioni, a testimonianza di ciò questi sistemi sono in dotazione alle principali forze dell ordine e militari italiane ed estere. La sicurezza delle trasmissioni viene garantita da due livelli di sicurezza implementati in due livelli protocollari distinti; il grado di affidabilità invece viene determinato principalmente da quanta copertura del segnale viene data ad i vari terminali, per questo il Tetra fornisce due tipi diversi di funzionamento: Trunked Mode (TMO): modalità infrastrutturale dove il servizio viene garantito sotto la copertura di una Base Station Tetra, Direct Mode (DMO): modalità non infrastrutturale dove i vari terminali comunicano direttamente l uno con l altro senza l ausilio di una BS. 27

45 28 Capitolo 2. TWNET: Tetra Wireless NETwork L obbiettivo del progetto TWNET è quindi quello di superare alcuni limiti della modalità di comunicazione DMO per poter ampliare ulteriormente la possibilità di copertura per riuscire a garantire affidabilità delle comunicazioni anche in situazioni ambientali difficili o in scenari di emergenza. Per far questo si è pensato di ampliare il funzionamento dei terminali DMO con l adattabilità e la facilita di deploy delle reti mesh presentate precedentemente, in modo da fornire una backbone di supporto alle normali comunicazioni Tetra. L idea è quindi quella di dotare i nodi mesh di un interfaccia Tetra per poter esportare e importare segnalazioni e traffico voce fra i due mezzi di telecomunicazioni, da una parte una rete mesh basata su IP e dall altra isole Tetra DMO. Per far questo è necessario avere un interfaccia in grado di accedere in ricezione ed invio al mezzo Tetra per poi riuscire a tradurre queste informazioni in traffico IP e viceversa. Presenteremo quindi i servizi che saranno interessati dal nostro sistema, la nuova struttura dei nodi mesh con l interfaccia Tetra/IP scelta ed eventuali estensioni che dovranno essere implementate per garantirne la corretta funzionalità, ed infine il software che è stato sviluppato per permettere lo sviluppo del prototipo di questa rete mista. 2.1 Lo standard Tetra Nell ambito dei sistemi radio professionale l ETSI ha sviluppato il protocollo di comunicazione TETRA (TErrestrial Trunked RAdio), protocollo che per completezza e funzionalità può essere paragonato al più famoso GSM utilizzato per i sistemi pubblici di radiocomunicazione mobile. A differenza delle reti pubbliche, TETRA va a soddisfare esigenze più specifiche e prevede fun-

46 2.1. Lo standard Tetra 29 zionalità avanzate andando così a coprire il settore di mercato delle utenze professionali. Infatti va a soddisfare specifiche esigenze di sicurezza, privacy, flessibilità e soprattutto affidabilità tanto da essere considerato protocollo di riferimento per le telecomunicazione da parte degli enti governativi europei. I sistemi TETRA sono in grado di inviare simultaneamente sia dati che traffico voce, il collegamento radio è dotato di 4 canali indipendenti in grado di garantire la trasmissione contemporanea delle due tipologie di traffico. Un altra caratteristica che permette questa trasmissione simultanea è la separazione in slot temporali di una singola portante e la possibilità, da parte di un device, di farsi allocare più slot temporali per l invio dei dati. Secondo lo standard ETSI, si prevede l uso di una tecnologia digitale in grado di garantire una buona qualità audio paragonabile al GSM ed un basso rate di errori per le trasmissioni dati. Queste caratteristiche sono abbinate ad alti livelli di sicurezza paragonabili ai sistemi di telefonia fissa, grazie a diversi livelli di autenticazione: l utente con la radio; la radio con la rete; la rete con la radio; fra reti diverse; fra gli utenti; Queste feature rendono questa tecnologia il principale punto di riferimento nelle comunicazioni radio professionali. TETRA è in gradi di lavorare in 3 principali modalità: 1. DMO (Direct Mode Operation): che permette la comunicazione fra i terminali quando si è fuori copertura della rete;

47 30 Capitolo 2. TWNET: Tetra Wireless NETwork 2. V+D (Voice + Data): in modalità trunked permette l invio simultaneo dei due tipi di traffico; 3. PDO (Packet Data Optimized): permette di raggiungere le massime velocità di trasmissione dati. Vi sono alcuni ruoli fondamentali ed alcuni concetti base indispensabili per la corretta comprensione dello standard: Master: ruolo ricoperto dal terminale che è in possesso del canale Slave: tutti gli altri terminali presenti sul canale; le modalità operative di utilizzo del canale sono due: 1. normal mode: solamente una chiamata può essere eseguita su una certa frequenza, indipendentemente dal tipo di chiamata se di gruppo o individuale; 2. frequency efficient mode: in questa modalità si possono attivare al massimo due chiamate su una stessa frequenza; in modalità DMO sono premesse solo chiamate simplex sia che siano di gruppo o individuali; nel DMO non vi è alcuna correlazione fra indirizzi e frequenze di trasmissione, per esempio possono essere attivate chiamate ad uno stesso destinatario ma su frequenze diverse; in modalità DMO un terminale può ricevere una chiamata solo se ha selezionato la frequenza sulla quale viene effettuata tale chiamata;

48 2.1. Lo standard Tetra 31 gli indirizzi identificano un terminale o un gruppo di terminali, un indirizzo è costituito da una prima parte chiamata MNI (Mobile Network Identity) che rappresenta l identificativo di rete a cui appartiene il terminale e da una seconda parte univoca che identifica il device; su un terminale sono configurati vari indirizzi: 1. un ITSI Address; 2. due Open Group GTSI: indirizzi di gruppo che consentono di identificare tutti i terminali presenti su di una frequenza o tutti quelli aventi uno stesso MNI; oltre a questi tre indirizzi possono essere configurati altri indirizzi di tipo GTSI; un terminale può ricevere una chiamata solo se questa è indirizzata ad uno degli indirizzi in esso configurati Architettura DMO Lo stack protocollare DMO ha tre layer che implementano varie funzionalità a basso livello, andremo adesso a presentarle in modo da chiarire le varie entità che vengono coinvolte durante il funzionamento del sistema di telecomunicazione. Air interface layer 1 Il primo e il più basso layer nello stack protocollare si occupa della comunicazione del mezzo fisico ed in particolar modo gestisce la definizione della modulazione, sincronizzazione radio del TDMA, codifica del canale e multiplexing dello stesso. Il progetto TWNET prevede la conservazione della

49 32 Capitolo 2. TWNET: Tetra Wireless NETwork struttura di comunicazione del DMO originale, sorvoliamo quindi su approfondimenti tecnici poiché non è stato argomento di studio al fine del progetto. Air interface layer 2 Il secondo livello dello stack è paragonabile al livello data link della pila ISO/OSI, si occupa cioè della parte di accesso al canale; questo layer può essere suddiviso in due parti principali: la prima, definita user plane adibita al trasporto delle informazioni, sia dati che voce, utilizzate dalle applicazioni utente, la seconda, control plane a cui viene delegata la gestione del traffico per la segnalazione. L obbiettivo di questo livello di protocollo è quello di gestire le connessione logiche delle comunicazioni fornendo un interfaccia agli strati superiori per un accesso semplificato al mezzo fisico. Codifica di canale e schemi di scrambling/de-scrambling interleaving/deinterleaving; Controllo di accesso al canale: sincronizzazione dei frame tenendo traccia del Frame Number e dello Slot Number controllo di accesso al canale DM con rilevazione dello stato dello stesso (libero occupato o riservato) rilevamento di collisione con i terminali slave durante gli stati del canale riservati o occupati tramite un sistema di accesso casuale frammentazione di un SDU in più PDU e la successiva ricomposizione multiplexing dei canali logici all interno di un burst di livello 2

50 2.1. Lo standard Tetra 33 creazione e sincronizzazione della struttura multiframe. Ogni frame viene numerato in modo ciclico ed ogni blocco di sincronizzazione deve indicare i numeri di frame di time slot. Gestione della radio: gestione indirizzi per le chiamate controllo di potenza creazione del collegamento radio gestione di un buffer per il traffico dell utente e di controllo fino a quando non avviene l effettiva trasmissione interfacciare le applicazioni a commutazione di circuito con lo strato fisico scambiare le informazioni con lo strato superiore Crittografia: il DMO è in grado di garantire la sicurezza delle comunicazioni tramite un sistema di cifratura basato sull utilizzo di chiavi crittografiche statiche (SCKs) e l uso di una sincronizzazione di un parametro dipendente dal tempo (TVP) contro gli attacchi di replica dei pacchetti cifrati. Air interface layer 3 In questo livello protocollare sono previste soltanto le funzionalità riferite al control plane, quindi gestione del traffico e la segnalazione. La componente principale di questo layer è il Direct Mode Call Control (DMCC) che implementa le seguenti funzionalità: Inizializzazione, mantenimento e rilascio dei servizi di base per le chiamate

51 34 Capitolo 2. TWNET: Tetra Wireless NETwork Indirizzamento delle chiamate (destinazione, repeater e gateway) Short Data Service (SDS): brevi messaggi di testo simili agli SMS del GSM Supporto per servizi correlati alle chiamate: livello di priorità dell utente, identificazione pre-emption e late entry. Un altro aspetto che viene gestito dal control plane è la Security Management che si occupa di: Identity Management e le procedure di autenticazione, anche se nel DMO non esistono vere e proprie procedure di autenticazione perché l autenticità del chiamante viene garantita dalla conoscenza di un segreto condiviso, cioè la chiave SCK usata per la cifratura della chiamata; Enable/Disable Mechanism: un terminale autorizzato può abilitare o disabilitare l accesso al canale radio di un secondo terminale. Inoltre se un terminale deve poter comunicare anche con una rete Tetra TMO tramite un DM-GATEway, dobbiamo aggiungere alle funzionalità di questo layer anche la componente che implementa le procedure di registrazione verso la rete infrastrutturale, componente denominata Direct Mode Mobility Management (DMMM) Canale a trama temporale Il sistema Tetra DMO utilizza due diversi metodi di suddivisione ed accesso al canale, il primo metodo è un Time Division Multiplexing (TDM) come anche il secondo, più nuovo, che però utilizza due frequenze portanti. Al fine di garantire la massima compatibilità possibile, anche con terminali Tetra di

52 2.1. Lo standard Tetra 35 vecchia fattura, il progetto TWNET si appoggerà al primo metodo e quindi verrà utilizzata solo una frequenza portante. Il canale non viene scelto automaticamente ma viene impostato sul terminale che si vuole utilizzare, una volta attivo sulla frequenza questo verrà utilizzato per trasmettere tutte le tipologie di dato: segnalazione, voce, messaggi e dati. Lo standard DMO utilizza per ogni banda una struttura fissa di allocazione del canale suddivisa in tre sotto trame: 1. la separazione più grande è organizzata in multi frame, 2. ciascuno dei quali e suddiviso in 18 frame, 3. ogni frame è ulteriormente suddiviso in 4 frame slot Indirizzi ed identità I terminali e i gruppi di device Tetra vengono identificati all interno della rete tramite indirizzi di diverso tipo. Tali indirizzi di suddividono in categorie differenti in base alla lunghezza ed all utilizzo: MCC : Mobile Country Code di 10 bit identifica la nazione di appartenenza dell operatore Tetra MNC : Mobile Network Code di 14 bit identifica l operatore stesso MNI : Mobile Network Identity di 24 bit è formato da MCC+MNC SSI : Short Subscriber Identity di 24 bit identifica un terminale e deve essere univoco all interno di una sotto rete Tetra TSI : Tetra Subscriber Identity di 48 bit è formato da MNI+SSI identificando univocamente il terminale

53 36 Capitolo 2. TWNET: Tetra Wireless NETwork TEI : Tetra Equipment Identity si 15 bit Indirizzi di device Tetra tipo repeater e gateway sono di 10 bit Gli indirizzi di gruppo hanno la stessa lunghezza e struttura di quelli individuali e vengono utilizzati nello stesso modo e negli stessi campi del protocollo durante le comunicazioni, per chiarire potremmo paragonare questo tipo di indirizzamento a quello IP, in questo caso ci riferiremmo all indirizzamento unicast nel caso di indirizzi di terminale o a quello multicast nel caso di quelli di gruppo. Si distingue quindi l ITSI ed il GTSI come indirizzi individuali o di gruppo, e conseguentemente possiamo parlare dell ISSI o nel secondo caso del GSSI. Ogni terminale Tetra ha assegnato un TSI individuale ed un numero variabile di TSI di gruppo, l insieme di questi indirizzi costituiscono la TSI Family. Fra tutti i gruppi disponibili ve ne è uno che è associato a tutti i terminali, chiamato open group; i device che trasmettono a questo gruppo comunicano con tutte le stazioni presenti su quel canale. L indirizzo di questo gruppo è identificato dal SSI con i bit settati tutti a 1, se invece vogliamo chiamare in broadcast tutte le stazioni anche all esterno della sotto-rete Tetra anche i bit del MNI devono essere settati a 1. Il sistema di indirizzamento viene utilizzato sia dal livello 2 che dal livello 3, la destinazione può essere sia un indirizzo Unicast che uno di gruppo, mentre quello di mittente può essere solamente un indirizzo ISSI. Un caso particolare sono gli indirizzi associati a differenti device Tetra: repeater e gateway hanno degli address lunghi 10 bit che però non hanno il vincolo dell univocità all interno di una rete Tetra ma solamente all interno della stessa isola DMO. Un terminale DMO riconosce la presenza di questi device tramite la segnalazione periodica che questi trasmettono sul canale su cui sono attivi. In questo caso tali indirizzi di 10 bit non vengono utilizzati

54 2.1. Lo standard Tetra 37 Tetra Subscriber Identity (TSI) 48 bit Mobile Network Identity (MNI) 24 bit Short Subscriber Identity Mobile Country Code Mobile Network Code (SSI) 24 bit (MCC) 10 bit (MNC) 14 bit Tabella 2.1: Struttura degli indirizzi Tetra per destinare il traffico ma bensì solo per indicare il tramite cui veicolare tali dati, per fare un esempio possiamo paragonare tale sistema al funzionamento nelle reti IP dei gateway e il differente uso di indirizzi IPv4 e ARP Scenari di servizio TETRA DMO Il Tetra DMO è in grado di trasmettere due tipologie di informazioni: traffico dati e traffico voce. Entrambe vengono fornite dei servizi di sicurezza tramite cifratura del canale di trasmissione utilizzando i due principali sistemi previsti dallo standard: AIE: Air Interface Encryption E2EE: End-to-End Encryption La modalità DMO rappresenta una delle caratteristiche più importanti del TETRA ed è anche l oggetto del progetto TWNET, in questa modalità sono previsti due tipi principali di servizi: bearer: questo tipo di servizio per l invio di informazioni fra le interfacce di rete interessa i livelli più bassi della pila protocollare, per esattezza i 3 livelli inferiori. L utente utilizza per accedere alle funzionalità del

55 38 Capitolo 2. TWNET: Tetra Wireless NETwork device radio un protocollo di livello superiore il quale utilizza i servizi bearer per trasmettere sulla rete le informazioni, sia dati che voce; teleservice: il servizio che fornisce la capacità di comunicazione fra gli utenti tramite lo standard TETRA, si tratta dei servizi che vengono forniti all utilizzatore tramite le varie applicazioni del device che si appoggiano ai servizi bearer per il trasposto dei dati sulla rete. Come accennato precedentemente, il progetto TWNET prevede l utilizzo del canale fisico con modalità normale quindi con la possibilità di attivare una sola chiamata simplex su un canale e tale chiamata può essere stabilita soltanto fra terminali operanti su quella frequenza. Andiamo quindi a analizzare i meccanismi di funzionamento dei vari servizi Tetra DMO che dovranno essere supportati dalla rete TWNET. Chiamata diretta senza presence check In modalità normale ogni MS può operare su di un solo canale configurato dall utente, tale portante viene utilizzata per tutte le tipologia di trasferimento: dati, voce o segnalazione. Nel Tetra DMO il mezzo di comunicazione viene suddiviso in una struttura fissa descritta nel capitolo che prevede 4 time slot per frame e 18 frame costituiscono un hyperframe. Il canale può risultare libero (quando cioè non viene rilevata alcuna attività), occupato, riservato o in uno stato sconosciuto. Durante una chiamata vengono utilizzati gli slot 1 e 3 all interno del frame. Quando una radio vuole effettuare una chiamata su un canale libero, ne prenota l utilizzo ed inizia la procedura per attivare la chiamata voce: Il master trasmette i burst di sincronizzazione (DSBs: Direct Mode Synchronization Bursts) nei frame numero 6, 12 e 18 mentre viene allocato il traffico (DNBs: Direct Mode Normal Bursts) nei

56 2.1. Lo standard Tetra 39 frame dal 1 al 17. Nella fase di prenotazione del canale il master usa i frame per: indicare che il canale è riservato; indicare per quale gruppo o terminale è riservato; segnalare la durata della prenotazione. L occupazione del canale da parte del master risulta conclusa dopo il termine della chiamata, dopo un changeover (procedura che cambia il ruolo del master quindi il canale risulterà occupato da un altro terminale) o dopo che il timer della prenotazione è scaduto. Quando un canale è occupato, vengono usati per la chiamata i seguenti frame: il frame 18 è usato per la sincronizzazione con un DSB negli slot 1 e 3 i frame 6 e 12 hanno un DSB nello slot 3 e possono trasportare traffico con un DNB nello slot 1 nei frame 6 e 12 vengono anche allocate anche informazioni sulla prenotazione del canale con un DSB negli slot 1 e 3 la segnalazione di pre-emption si trova negli slot 3 dei frame 2, 5, 8, 11, 14 e 17 durante una chiamata i frame dal 1 al 17 trasportano il traffico DNB nello slot 1 Un terminale che vuole effettuare una chiamata, per prima cosa effettua un monitoraggio sul canale per verificarne lo stato: nel caso la frequenza sia libera, la radio diventa il master della chiamata e inizia a sincronizzare

57 40 Capitolo 2. TWNET: Tetra Wireless NETwork Frame # Slot # Channel su su su su su su su su tc tc p? tc ich tc Frame # Slot # Channel tc p? tc occ tc tc p? tc tc Tabella 2.2: Occupazione di frame e slot nella chiamata diretta senza presence check il canale inviando burst DSP (su nella tabella 2.2) che informano i terminali slave su quale numero di frame sta avvenendo la chiamata così da poter allineare le strutture multi frame. Successivamente nel primo frame libero il master inizia a trasmettere il traffico (tc nella tabella 2.2). Nella trama temporale vengono rilasciati alcuni slot liberi per eventuali richieste di preemption sul canale (p? nella tabella 2.2) e vengono trasmessi burst di sincronia sullo slot 3 dei frame 6, 12 e 18 per indicare che il canale è attualmente occupato (occ nella tabella 2.2). Ogni scambio di dati in una comunicazione in DMO consiste in una trasmissione indipendente con un master e vari slave coinvolti. In questo esempio, le opportunità di pre-emption sono nello slot 3 dei frame 2, 5 e 8 del link slave. Una richiesta di questo tipo fatta nello slot 3 del frame 2 sul link slave sarebbe ritrasmessa 5 slot dopo nello slot 3 del frame 4 del link master. La figura mostra inoltre la trasmissione del segnale di presenza da parte del DM-REP nello slot 3 del frame 7 sul master link (questo slot potrebbe venir utilizzato per la ritrasmissione di una richiesta di pre-emption eventualmente ricevuta nello slot 3 del frame 5 del link slave). La procedura per passare da una trasmissione della chiamata ad un altra prende il nome di Changeover. Per prima cosa il chiamante, che vuole rilas-

58 2.1. Lo standard Tetra 41 ciare il ruolo di master, invia una segnalazione transmit ceased message nello stesso formato del traffico DNB nello slot 1 in almeno due frame consecutivi indicando così che sta per concludere la comunicazione. Una radio slave che vuole eleggersi nuovo master della nuova transazione di chiamata, invia un changeover request message in uno slot 3 riservato. Nell eventualità di collisioni di richieste di changeover o pre-emption, queste vengono risolte tramite un meccanismo di ritrasmissione con intervallo casuale. Una volta che una richiesta viene ricevuta con successo, il master rilascia il canale tramite un changeover acknowledgement al termine del quale diviene a tutti gli effetti uno slave per la successiva transazione. In caso si utilizzi il protocollo MS-REP la procedura di call set-up senza presence check è modificata come in figura 2.1 Figura 2.1: Struttura della trama temporale nel set-up di una chiamata senza presence check tramite repeater Dopo essersi assicurato che lo stato del canale è libero, il terminale DM- MS può linearizzare il trasmettitore. Quindi stabilisce la sincronizzazione al canale e il suo ruolo di master trasmettendo una sequenza di messaggi di call set-up sul master link inviati su un numero appropriato di frame. I burst di sincronizzazione contengono le informazioni sul conteggio del frame (in

59 42 Capitolo 2. TWNET: Tetra Wireless NETwork figura 2.1 i 17 e 18 del master-link) e dello slot di appartenenza (in figura 2.1 da 1 a 4). Il terminale DM-MS master quindi si mette in ascolto dei burst di sincronizzazione ritrasmessi dal DM-REP sul link slave a conferma che la sua segnalazione è stata ricevuta e gestita con successo dal dispositivo. Il DM-REP può variare il numero di frame ritrasmessi sul link slave, in questo esempio invia i burst di sincronizzazione in 2 frame per un totale di 8 burst. Il terminale DM-MS master quindi trasmette il traffico (tc in figura 2.1) nel successivo frame disponibile che nell esempio è il frame 3 del master link. La figura illustra inoltre la posizione degli slot allocati alle richieste di pre-emption (p? in figura 2.1 vedi anche capitolo 2.1.4), gli slot per la linearizzazione (lch in figura 2.1) e i burst di sincronizzazione che indicano l occupazione del canale (occ in figura 2.1) inviati nello slot 3 dei frame 6 e 12, e negli slot 1 e 3 del frame 18. Ai livelli più alti della pila, la chiamata inizia con l invocazione della primitiva DMCC-SETUP request da parte dell applicazione utente. Se il canale risulta libero il Direct Mode Call Control (DMCC) inizia la procedura di attivazione della chiamata creando ed inviando al livello MAC un messaggio di DM-SETUP. Se i livelli inferiori riescono con successo a stabilire la chiamata questa informazione viene comunicata all applicazione utente con un messaggio di conferma e con l avvio del timer DT311 (300ms) in modo che la comunicazione non superi il tempo della prenotazione del canale. Nel caso le procedure di attivazione della chiamata non vadano a buon fine per la presenza di una chiamata già attiva sul canale, la procedura può essere interrotta tramite l invio di un messaggio di DMCC-RELEASE o può essere invocata la procedura per il pre-emption. Nel caso in cui il canale risulti libero, il DMCC degli altri terminali viene allertato della presenza di una chiamata entrante con la ricezione del DM-SETUP PDU, questi reagisce inviando al-

60 2.1. Lo standard Tetra 43 l applicazione utente una segnalazione tramite il messaggio DMCC-SETUP e si mette in attesa di una risposta. Se l applicazione è in grado di ricevere la chiamata invia come replica un messaggio di DMCC-SETUP response, il quale configura il livello MAC per la ricezione del traffico e quindi assume il ruolo di slave. In caso contrario l applicazione segnala la sua impossibilità di ricevere la chiamata inviando un DMCC-RELEASE request, in questo caso il DMCC configura lo stato del MAC come idle ed abbandona la procedura di set-up. Figura 2.2: Call setup senza presence check In presenza di un DM-REP intermedio la messaggistica scambiata a livello di processi è analoga; il DM-REP si limita infatti a re-inoltrare quanto ricevuto seguendo lo schema aria visto in precedenza.

61 44 Capitolo 2. TWNET: Tetra Wireless NETwork Frame # Slot # Master sup sup sup sup sup sup sup sup sup sup sup cnk cnk Slave lch cn cn cn Frame # Slot # Master tc tc p? tc occ tc tc p? tc Slave Tabella 2.3: Occupazione di frame e slot nella chiamata con presence check Chiamata individuale con presence check Le chiamate di gruppo possono essere stabilite soltanto tramite la modalità descritta precedentemente mentre, per le chiamate dirette ad un destinatario singolo, esiste la possibilità di attivare la comunicazione voce solo con terminali che riscontrino la propria presenza. La procedura per stabilire una chiamata con il presence check è simile a quella senza il riscontro ma successivamente al burst di frame dedicati al set-up della chiamata (sup in figura 2.3) il master attende una risposta da parte del destinatario per poter trasmettere i primi dati di traffico. Il destinatario della chiamata, che assumerà inizialmente il ruolo di slave, risponde trasmettendo un messaggio di connect (cn in figura 2.3) su più frame per segnalare la propria presenza sul canale di trasmissione. Dopo la segnalazione il master risponde inviando un messaggio di ack (cnk in figura 2.3) per convalidare la creazione effettiva della connessione fra i due terminali. L opzione del presence check a fronte di un ritardo nei tempi di setup della chiamata permette di ottimizzare l utilizzo del canale e il risparmio energetico dei terminali impedendo di iniziare chiamate senza la presenza del destinatario. Analizziamo adesso il comportamento della procedura in caso di presenza di un repeater considerando la trama in aria.

62 2.1. Lo standard Tetra 45 Figura 2.3: Struttura della trama temporale nel set-up di una chiamata con presence check tramite repeater La procedura inizia in maniera simile al caso di set-up senza presence check, ma il messaggio di set-up nel burst di sincronizzazione (sup in figura 2.3, con 7 inviati in questo esempio) ora richiede una risposta indicante la presenza della DM-MS che è destinatario della chiamata. Lo slave per la comunicazione risponde sul link slave con il messaggio connect (cn in figura 2.3) che indica la sua disponibilità a ricevere la trasmissione. In questo esempio, lo slave linearizza il trasmettitore nello slot 1 del frame 2 del link slave, inviando un messaggio di connect nello slot 3 di questo frame e ripetendo poi il messaggio di connect nel frame seguente. Tale messaggio è ritrasmesso dal DM-REP alla master DM-MS nel frame apposito sul link master (in questo caso i frame 4 e 5). Al ricevimento del connect il master risponde con un messaggio di riscontro della connessione (cnk in figura 2.3) inviandolo in almeno un frame e quindi inizia la trasmissione del traffico nel frame 7 del link master. La procedura di call set-up con presence check al livello superiore viene avviata se il DMCC-SETUP request indica che è richiesto il controllo di presenza. Il DMCC converte la richiesta di set-up in un messaggio DM-

63 46 Capitolo 2. TWNET: Tetra Wireless NETwork SETUP PRES PDU, lo invia ed entra nello stato CALL SETUP PRES- CHECK ORIGINATING. Dopo la trasmissione aspetta un DMAREPORT indication dal livello 2 che lo informa del progresso della procedura. Se il DM- SETUP PRES PDU è stato trasmesso correttamente il DMCC avvia il timer DT303 (250ms) ed aspetta una risposta. Se infine riceve una DM-CONNECT PDU, accetta la richiesta di servizio e: invia come risposta un DM-CONNECT ACK PDU; entra nello stato CALL ACTIVE TX OCCUPATION; invia all applicazione utente DMCC-SETUP confirm; crea un DMC-CONFIGURE request; interrompe il timer DT303 (250ms); avvia il DT311 (300ms). Quando invece si riceve un DM-DISCONNECT PDU viene inviato un DM- RELEASE PDU e si ritorna in uno stato IDLE. Anche nel caso che termini il timer DT303 il DMCC invia un DM-RELEASE PDU; successivamente potrà inviare di nuovo un DM-SETUP PRES PDU oppure notificare all applicazione utente un DMCC-RELEASE indication. La notifica di una chiamata in entrata ad un DMCC sarà fatta dalla ricezione di un DM-SETUP PRES PDU. Se l applicazione utente non può ricevere la chiamata sarà immediatamente inviato un DMCC-RELEASE request: il DMCC invierà un DM-DISCONNECT PDU indicando la causa del rifiuto e ritornerà nello stato IDLE. Altrimenti se il DMCC desidera ricevere la chiamata: risponderà con un DMCC-SETUP response;

64 2.1. Lo standard Tetra 47 invia un DM-CONNECT PDU contenente le informazioni del servizio offerto; avvia il timer DT307 (350ms) e aspetta la risposta dal DM-MS chiamante. Se entro il tempo fissato dal timer riceve un DM-CONNECT ACK PDU allora notifica un DMCC- COMPLETE indication ed entra nel nuovo stato CALL ACTIVE RX OCCU- PATION. Altrimenti il timer DT307 termina, il DMCC notifica un DMCC- RELEASE indication e ritorna allo stato IDLE. Figura 2.4: Call setup con presence check Anche in questo caso, in presenza di repeater, la procedura è sostanzialmente identica; si noti però che i timer hanno un valore (consigliato) maggiore: 550 ms per il DT303 e 450 ms per il DT 307.

65 48 Capitolo 2. TWNET: Tetra Wireless NETwork Chiamata tramite DM-GATEway Nel caso sia presente un DM-GATE la procedura di set-up si differenzia nel caso di chiamata individuale o di gruppo e se generata lato TMO o DMO. Se generata dal lato TMO è con presence check, se individuale, e senza presence check, se di gruppo; non considereremo in seguito tali procedure poiché non coinvolte nel progetto oggetto di questa tesi. Ci soffermeremo invece sulle procedure di set-up di chiamata sia di gruppo che individuale generate lato DMO: in tal caso le chiamate sono senza presence check anche se una procedura implicita fra DM-MS e DM-GATE è presente come sarà più chiaro in seguito. Chiamata di gruppo da DM-MS attraverso il DM-GATE Il diagramma temporale in figura 2.5 mostra la call set-up da un DM-MS attraverso il DM-GATE. Il disallineamento iniziale tra lo slot 1 della trama DMO e lo slot 1 del down link TMO è supposto essere di 3 slot. Dopo aver seguito le procedure per la verifica dello stato del canale, e supposto che sia stato trovato libero, il terminale DM-MS chiamante può linearizzare il trasmettitore. Fatto ciò, invia il messaggio di richiesta di set-up gsu sul canale DMO indirizzandolo al gateway. In questo esempio il gateway invia il messaggio USETUP usu sull uplink TMO, 3 slot dopo aver decodificato con successo il primo burst di set-up dalla DM-MS. E una scelta del gateway se inviare o no delle DM-GACK intermedie alla DM-MS chiamante durante la gestione del set-up di chiamata lato TMO (usu + dscn). La SwMI ha immediatamente risorse disponibili e risponde inviando la D-SETUP e la D-CONNECT ai membri del gruppo TMO e al gateway, rispettivamente, nello stesso slot (dscn). Al tempo stesso richiede anche un riscontro di livello 2 (l2a) dal gateway in un sub slot riservato sul canale di

66 2.1. Lo standard Tetra 49 Figura 2.5: Struttura temporale set-up chiamata di gruppo tramite DM-GATEway traffico allocato (slot 3). Se la SwMI risponde velocemente non c è necessità di un riscontro intermedio alla DM-MS e quindi il gateway può rispondere alla DM-MS chiamante con il messaggio DM-GCONNECT. Il messaggio è anche usato per riallineare lo slot e la numerazione dei frame sul canale DMO. Nel frattempo, in assenza di traffico reale, il gateway genera PDU nulle nell uplink TMO. La DM-MS, dopo aver ricevuto il DM-GCONNECT dal gateway, assume il ruolo di master, applica la nuova temporizzazione stabilita dal gateway e genera i messaggi di DM-SETUP sul canale DMO per avvertire i membri del gruppo chiamato; infine procede ad inviare il suo traffico che è trasmesso dal gateway sul canale TM uplink 3 slot dopo e dalla SwMI sul canale TM downlink dopo altri 2 slot. La figura 2.5 illustra, lato DMO, la posizione degli slot allocati alle richieste di pre-emption (p? in figura 2.5) ed ai burst di sincronizzazione che denotano l occupazione del canale (occ in figura 2.5) che sono gli slot 3 del frame 6 e 12 e gli slot 1

67 50 Capitolo 2. TWNET: Tetra Wireless NETwork e 3 del frame 18. E mostrato anche, nello slot 3 del frame 1 sul canale DMO, il segnale di presenza che viene trasmesso dal gateway nello slot 3 dei frame 1, 7 e 13 durante l occupazione da parte di una DM-MS come master. In generale, una chiamata di gruppo iniziata da una DM-MS verso membri presenti sia sul canale DMO che nel sistema TMO deve tenere conto del tempo di risposta del sistema TMO, poiché può impiegare anche molto tempo per rispondere ad un set-up di chiamata: lato DMO il DM-GATE deve mantenere aperta la procedura di set-up mediante l invio delle DM-GACK e abilitare la conclusione del set-up stesso (invio su) solo quando l apertura della chiamata lato TMO gli viene confermata. La figura 2.6 mostra le PDU inviate in aria lato DMO e TMO durante un set-up di chiamata via DM- GATE. Figura 2.6: Sequenza degli scambi di PDU nel set-up della chiamata

68 2.1. Lo standard Tetra 51 L approccio di base della sequenza dei messaggi per una richiesta di chiamata (individuale o di gruppo) originata da una DM-MS prevede la richiesta iniziale, un riscontro intermedio opzionale ed un riscontro positivo o negativo finale. Durante la call set-up il gateway è il master del canale, la DM-MS chiamante inizia la procedura con il messaggio DM-GSETUP che è inviato sul canale DMO verso il gateway. Questo inoltra una U-SETUP al SwMI e aspetta per un D-CONNECT in risposta che contiene l allocazione del canale, in attesa del messaggio può essere inviato un riscontro alla DM-MS chiamante (DM-GACK) per prevenire il ripetersi delle richieste di call set-up e quindi la generazione della segnalazione di prenotazione. Alla ricezione del D-CONNECT il gateway invia un DM-GCONNECT alla DM-MS chiamante che quindi assume il ruolo di master e inizia la chiamata seguita dal traffico. I messaggi di DM-SETUP e il traffico sono ricevuti sia dal gateway che dai membri DMO del gruppo. Chiamata individuale da DM-MS attraverso il DM-GATE Il diagramma temporale in figura 2.7 mostra la segnalazione per il set-up di una chiamata individuale da una DM-MS ad una MS nel sistema TMO. Il processo inizia quando la DM-MS invia la richiesta di chiamata DM- GSETUP (gsu in figura 2.8) dopo aver determinato la numerazione di frame e di slot sul link stabilito dal segnale di presenza del gateway. La richiesta di set-up viene inoltrata alla SwMI che a sua volta contatta la TM-MS (è una scelta del gateway se, durante la procedura, inviare un riscontro intermedio alla DM-MS chiamante prima di inviare la call set-up alla SwMI). In questo esempio, la richiesta è inviata al sistema TMO (usu) prima che il riscontro intermedio del gateway (gak) sia inviato alla DM-MS. Alla ricezione di un U-CONNECT dalla TM-MS contattata, la SwMI invia un D-CONNECT e

69 52 Capitolo 2. TWNET: Tetra Wireless NETwork Figura 2.7: Diagramma temporale della segnalazione di set-up di chiamata con DM-GATE

70 2.1. Lo standard Tetra 53 un D-CONNECT ACKNOWLEDGE (dcnk in figura 2.8) al gateway ed alla TM-MS rispettivamente inviando così l allocazione di canale nello slot 3 della stessa portante (in questo esempio). Il gateway quindi invia il riscontro finale, DM-GCONNECT (gcn), alla DM-MS chiamante ridefinendo la numerazione di slot se necessario per l allineamento con il canale TM. In questo caso, il messaggio ritarda la numerazione di slot di due, mantenendo la differenza di tre slot fra canali DM e TM. Il gateway invia anche PDU nulle alla SwMI finché la DM-MS chiamante non è pronta ad inviare traffico. Dopo la ricezione del riscontro finale, il terminale chiamante diventa master del canale DM, e quindi segue lo standard DM per le procedure di call set-up inviando i messaggi di DM-SETUP seguiti dal traffico. Figura 2.8: Struttura temporale set-up chiamata di gruppo tramite DM-GATEway

71 54 Capitolo 2. TWNET: Tetra Wireless NETwork Chiamata di emergenza L interfaccia aria DM supporta le chiamate di emergenza: un terminale DM- MS che inizia una chiamata di emergenza può usare un canale DM e, se necessario, fare la pre-emption di qualunque comunicazione a più bassa priorità eventualmente presente sul canale. Il servizio DMO permette ad una comunicazione DM di essere inibita per supportare il servizio di chiamate di emergenza. Pre-emption Durante una chiamata DM un terminale DM-MS, che può o non può essere implicato nella chiamata corrente, potrebbe voler accedere al canale per una ragione di priorità come una chiamata di emergenza. In questo caso esiste un meccanismo di pre-emption del canale già occupato come illustrato in figura 2.9. Figura 2.9: Occupazione slot durante una chiamata in DMO La prima sequenza master mostra il normale progresso di una chiamata con burst di traffico nello slot 1. Un terminale DM-MS che vuole usare il canale deve, se non partecipante alla chiamata, aver prima determinato il suo stato scoprendo così la chiamata in corso. Successivamente deve sincronizzarsi con il terminale DM-MS master e determinarne poi lo stato temporale, incluso i numeri di frame e di slot. Quindi per eseguire la pre-emption, il ter-

72 2.1. Lo standard Tetra 55 minale DM-MS trasmette un messaggio di richiesta (prq in figura 2.9) in uno degli slot allocati per questo scopo (durante l occupazione, la pre-emption è permessa nello slot 3 dei frame 2, 5, 8, 11, 14, e 17). Quando il master decodifica con successo la richiesta, assunto che sia una richiesta valida, annuncia la sua accettazione e la conseguente chiusura della chiamata in corso sia al terminale DM-MS che ne ha fatto richiesta sia agli altri terminali coinvolti nella chiamata. Questo annuncio è fatto per mezzo del messaggio di riscontro specifico della procedura (par e pa in figura 2.9), successivamente al suo invio il master cede il proprio ruolo e rilascia il canale. Il terminale che ha richiesto la pre-emption con successo trasmette i messaggi di set-up per la nuova chiamata, con un nuovo indirizzo di gruppo o individuale, e ne diventa il master. In figura 2.10 è illustrata tale procedura in presenza di DM-REP. Figura 2.10: Occupazione trama temporale durante pre-emption con la presenza di DM-Repeater La prima sequenza master mostra il normale progresso di una chiamata attraverso un DM-REP con burst di traffic nello slot 1 di ogni frame (dal 1 al 17) sul link master ritrasmessi poi dal DM-REP sul link slave. Una

73 56 Capitolo 2. TWNET: Tetra Wireless NETwork DM-MS che vuole usare il canale deve, se non partecipante alla chiamata, per prima cosa determinare lo stato del canale e in questo caso identificare che è presente una chiamata in corso attraverso un DM-REP. La DM-MS che fa pre-emption si deve quindi sincronizzare con la trasmissione del DM-REP sul link slave e determinare lo stato temporale del canale, incluso il numero di frame e di slot del link slave. Per effettuare la pre-emption, la DM-MS trasmette un messaggio di richiesta (prq in figura 2.10) in una posizione appropriata della struttura a frame nel link slave (durante l occupazione, la procedura è permessa solo nello slot 3 nei frame 2, 5, 8, 11, 14 e 17). Quando la stazione master decodifica con successo la richiesta di pre-emption ripetuta dal DM-REP sul link master, assumendo sia una richiesta valida, informa che il canale è stato prenotato sia alla DM-MS che esegue la richiesta che alle altre DM-MS, che erano parte della chiamata in corso. Questa informazione è inviata attraverso il messaggio di riscontro (par e pa in figura 2.10) inviati sul link master e quindi ripetuti sul link slave, una volta inviati i messaggi di riscontro il master cessa il suo ruolo e rilascia il canale. La DM-MS che ha avviato la procedura con successo trasmette i messaggi di set-up al DM- REP usando il link master per la nuova chiamata, con un nuovo indirizzo di gruppo o individuale, e diventa master per la sua transazione iniziale. In questo esempio la trasmissione del traffico inizia allo slot 1 del frame 15 del link master. Si noti che in questo esempio la DM-MS che fa pre-emption non include un aggiustamento temporale all interno della richiesta e quindi, nella nuova set-up, mantiene lo stesso riferimento temporale e numerazione dei frame usati dalla vecchia DM-MS master. Durante la chiamata attraverso un gateway una DM-MS, indipendentemente dal fatto che stia o no partecipando alla chiamata in corso, può voler accedere al canale DMO per ragioni di priorità come un emergenza. Anche

74 2.1. Lo standard Tetra 57 in questo caso esiste un meccanismo di pre-emption per il canale attualmente occupato. E illustrato in figura mostrando il caso in cui una TM-MS stia trasmettendo attraverso il gateway e una DM-MS debba fare pre-emption. Analizzando il comportamento in aria, per effettuare la pre-emption la DM-MS invia un messaggio di richiesta (gprq in figura 2.11) in una posizione apposita della struttura a frame DM (durante l occupazione la procedura è permessa solo nello slot 3 dei frame 2, 5, 8, 11, 14 e 17). Al ricevimento della richiesta il gateway invia il messaggio U-TX DEMAND alla SwMI nello slot 3 del frame 7 sul TM uplink, questo è il primo frame possibile poiché lo slot 3 del frame 6 non avrebbe avuto un tempo sufficiente per decodificare la richiesta di pre-emption ricevuta nello slot precedente. In questo esempio la SwMI ordina alla TM-MS trasmittente di fermare la trasmissione e contemporaneamente assegna il permesso di trasmettere al gateway (dtgi in figura 2.11), chiedendo un riscontro di livello 2 da ambedue le parti. Il gateway quindi informa la DM-MS che fa pre-emption di questo usando il messaggio DM-GPRE ACCEPT che viene inviato negli slot di traffico (slot 1) dei frame 8 e 9 sul canale DM insieme con il messaggio DM-TX CEASED (gpac). Il messaggio DM-GPRE ACCEPT è ripetuto nello slot 3 di ambedue i frame per incrementarne l affidabilità (gpa). Alla ricezione di questi frame di riscontro la DM-MS richiedente trasmette una sequenza di messaggi di set-up come master (su in figura 2.11). Si noti che, dopo l assegnazione della trasmissione da parte della SwMI, il gateway invia PDU nulle fino a che non viene ricevuto traffico dalla DM-MS. Analizzando il diagramma temporale di scambio dei messaggi di livello superiore, la pre-emption viene usata quando un terminale C vuole interrompere o subentrare ad una chiamata fra un terminale A e un terminale B. La chiamata con pre-emption può essere fatta unicamente se la chiama-

75 58 Capitolo 2. TWNET: Tetra Wireless NETwork Figura 2.11: Occupazione trama temporale durante la richiesta di pre-emption con DM-GATEway

76 2.1. Lo standard Tetra 59 ta in corso è ad una priorità minore o non ha la priorità settata. Nel caso in cui la pre-emption sia valida, il DMCC invia un DM-PREEMPT alla stazione master ed entra nello stato PRE-EMPTION attendendo la risposta. Se riceve un DM-PRES ACCEPT PDU, il terminale C procede con una call setup in maniera analoga a quanto visto precedentemente. Se invece riceve un DM-REJECT PDU il DMCC informa l applicazione utente con un DMCC-RELEASE indication e ritorna allo stato IDLE. Figura 2.12: Scambio di messaggi durante la pre-emption al livello DMCC In presenza di un repeater la sequenza temporale di scambio dei messaggi sostanzialmente non varia, limitandosi il repeater a re-inoltrare in aria i messaggi ricevuti. In presenza di gateway una DM-MS può sempre fare pre-emption ad un altra DM-MS. Si noti comunque che, tranne il caso in cui un altra DM- MS stia parlando, in presenza di gateway quest ultimo è sempre il master. In questo caso, infatti, la DM-MS dovrà inviare una PDU particolare, la

77 60 Capitolo 2. TWNET: Tetra Wireless NETwork DM-GPREEMPT PDU. Il gateway risponde la DM-GACK PDU indicando che la richiesta è stata ricevuta e quindi la DM-MS si mette in attesa per DT308 (30 s). Entro tale tempo deve ricevere una DM-GPRE ACCEPT PDU o una DM-GREJECT PDU che indicano l accettazione o meno della richiesta. Diverso il caso in cui sia il gateway a fare pre-emption: in questo caso la DM-MS master deve sempre rispettare la richiesta di pre-emption del gateway indipendentemente dalla sua priorità. Figura 2.13: Scambio di messaggi durante la pre-emption al livello DMCC in presenza di DM-GATEway In questo esempio una TM-MS sta inviando traffico che è poi trasmesso dal gateway sul canale DM, il quale agisce come master. Per fare la pre-emption, la DM-MS invia un messaggio DM-GPREEMPT. Quando il

78 2.1. Lo standard Tetra 61 gateway decodifica con successo la richiesta, assumendo sia una richiesta valida, invia una richiesta di trasmissione alla SwMI usando un U-TX DE- MAND PDU con la priorità fissata in modo appropriato. E una scelta del gateway se riscontrate il ricevimento della richiesta di pre-emption usando un messaggio intermedio di riscontro (DM-GACK) prima di inviare la U-TX DEMAND alla SwMI. La SwMI ordina alla TM-MS trasmittente di fermarsi usando il messaggio D-TX INTERRUPT e, in questo esempio, contemporaneamente assegna il permesso di trasmettere al gateway usando il messaggio D-TX GRANTED. Alla ricezione di questo messaggio il gateway consegna il canale alla DM-MS usando il messaggio DM-GPRE ACCEPT e inviando anche il messaggio DM-TX CEASED. La DM-MS richiedente quindi invia un DM-SETUP come master seguito dal traffico. In figura 2.13 è illustrata la temporizzazione della procedura di pre-emption. Changeover Una chiamata DM è costituita da una o più call transaction ognuna delle quali avente un suo master (che può anche rimanere lo stesso) e uno o più slave. La procedura che consente di effettuare un cambio di ruoli, che permette cioè ad uno slave di diventare il nuovo master, è denominata changeover ed è illustrata in figura Figura 2.14: Occupazione trama temporale durante una richiesta di changeover

79 62 Capitolo 2. TWNET: Tetra Wireless NETwork Giunti al termine del periodo di trasmissione del traffico voce, il master DM-MS indica che la sua call transaction è arrivata alla fine, inviando un messaggio di cessazione della fase di trasmissione (txc in figura 2.14). Questo messaggio è inviato almeno due volte nello slot 1 in frame consecutivi e usando lo stesso formato di burst del traffico normale. I riceventi della chiamata sono quindi a conoscenza della terminazione della chiamata e che il master DM-MS sta riservando il canale DM per la stessa chiamata per un certo periodo di tempo. Durante questo periodo, uno qualunque degli slave della chiamata può richiedere di diventare il nuovo master mediante l invio del messaggio di richiesta di changeover (txr in figura 2.14) che è inviato in uno degli slot 3 allocati dal protocollo a questo tipo di richieste. Le collisioni fra messaggi di richiesta di changeover e di pre-emption può talvolta avvenire, ma il protocollo è progettato per controllare tale contesa con un meccanismo di ritrasmissione con accesso casuale. Alla ricezione di una richiesta valida di changeover, il master rilascia il canale al richiedente usando una serie di messaggi di riscontro di changeover (txa in figura 2.14). Al termine della trasmissione dei messaggi di riscontro, il richiedente trasmette una sequenza di messaggi di set-up in burst di sincronizzazione (su in figura 2.14), il cui effetto è di far diventare il terminale il nuovo master della chiamata e dare inizio ad una nuova call transaction. La figura 2.14 si applica sia a chiamate di gruppo che a quelle individuali ma, nelle chiamate di gruppo, ci potrebbe essere una collisione fra più terminali DM-MS che richiedono contemporaneamente di effettuare questo procedimento. In questo caso una procedura di riprova casuale del controllo a contesa è effettuata come illustrato nella figura In questo esempio due slave DM-MS trasmettono una richiesta di changeover contemporaneamente. Queste richieste possono interferire e produrre un

80 2.1. Lo standard Tetra 63 Figura 2.15: Occupazione trama temporale durante una richiesta di changeover in chiamate di gruppo risultato illeggibile. Il master pertanto non riceve nessuna richiesta chiara e mantiene il canale nella modalità riservata, trasmettendo il segnale apposito (rsv in figura 2.15), fino a che un altra richiesta di changeover viene ricevuta con successo o il timer di prenotazione scade e il canale è rilasciato totalmente. Nell esempio lo slave 1 trasmette una seconda richiesta di changeover, che in questo caso ha successo e diventa quindi il nuovo master. Analizziamo adesso il caso in cui sia presente un terminale DM-REP. In figura 2.16 è illustrata la procedura di changeover in questo caso. Figura 2.16: Occupazione trama temporale durante una richiesta di changeover in presenza di DM-REPeater

81 64 Capitolo 2. TWNET: Tetra Wireless NETwork Per cambiare il mittente di una chiamata, il master indica prima che la sua chiamata è terminata, usando un messaggio di cessazione chiamata (txc in figura 2.16). Questo messaggio è inviato almeno due volte nello slot 1 di frame consecutivi sul link master e usando lo stesso formato dei burst del traffico normale, questi messaggi vengono quindi ritrasmessi dal DM-REP sul link slave (tcx ). I destinatari della chiamata che sono in ascolto sul link slave sono quindi a conoscenza del termine della chiamata e possono quindi richiedere al master, attraverso il DM-REP di continuare con una nuova chiamata. Il messaggio di richiesta di changeover (txr in figura 2.16) in questo esempio è inviato dalla DM-MS richiedente nel prossimo slot 3 disponibile sul link slave seguente la ricezione del txc. Questa richiesta viene ritrasmessa dal DM-REP nel frame appropriato sul link master. Alla ricezione di una richiesta di changeover valida (txr ), il master consegna il canale al richiedente usando una serie di messaggi di riscontro (txa in figura 2.16), trasmessi i riscontro sul link master, il master diventa slave e non ha più responsabilità sul canale. Alla ricezione del messaggio di riscontro di changeover ripetuto (txa ), il richiedente trasmette una sequenza di messaggi di set-up nei burst di sincronizzazione (su in figura 2.16) sul link master usando in questo caso la stessa temporizzazione di frame e di slot del precedente master. L azione di inviare la sequenza di set-up mette in atto il changeover con il richiedente che diventa il nuovo master della prossima chiamata. La numerazione di frame in figura 2.16 è stata scelta arbitrariamente come esempio ma, in questa figura, il primo burst di traffico nel nuovo master deve essere nel frame 5 (non mostrato in figura 2.16) sul link master. Si noti che la procedura di changeover quando operante con un DM-REP impiega più tempo che nel caso di link diretto MS-MS. Consideriamo adesso la procedura in presenza di gateway. In figura 2.17

82 2.1. Lo standard Tetra 65 è illustrata la temporizzazione del processo di changeover. La TM-MS indica che la sua chiamata è arrivata a fine, usando il messaggio U-TX CEASED (utxc in figura 2.17). La SwMI informa il gateway e riscontra la TM-MS usando i messaggi D-TX CEASED e richiede un riscontro di livello 2 ad ambedue, il gateway a turno informa la DM-MS usando il messaggio DM- TX CEASED (txc in figura 2.17). Il messaggio di richiesta di changeover (gtxr in figura 2.17) in questo esempio è inviato da un terminale richiedente nel prossimo slot 3 disponibile sul canale DM seguente la ricezione del txc, assumendo che il gateway renda lo slot 3 del frame 7 disponibile per l accesso random del DM-TX CEASED. Il gateway quindi effettua la richiesta di trasmissione alla SwMI (utxd) prima di aver riscontrato la ricezione del messaggio di richiesta di changeover sul canale DM (gak in figura 2.17). Successivamente la SwMI dà il permesso di trasmettere e ricevere al gateway e alla TM-MS rispettivamente usando i messaggi D-TX GRANTED e chiedendo un riscontro di livello 2 ad ambedue. Alla ricezione di questo permesso dalla SwMI, il gateway quindi rilascia il canale alla DM-MS usando una serie di messaggi finali di riscontro (gtxa in figura 2.17), alla ricezione dei messaggi di riscontro, la DM-MS richiedente trasmette una sequenza di messaggi di set-up come master. Si noti che dopo la trasmissione concessa dalla SwMI, il gateway invia PDU nulle fino a che non riceve traffico dalla DM-MS. Analizziamo adesso la procedura dallo scambio di messaggi a livello più alto. Quando un terminale DM-MS ha finito una comunicazione invia una DM-TX CEASED PDU in broadcast per avvertire della fine della comunicazione. Tale PDU viene ricevuta dagli altri terminali DM-MS coinvolti nella chiamata. Un altro terminale DM-MS, che si suppone voglia richiedere il changeover, una volta ricevuta la PDU, invia una DM-TX REQUEST al-

83 66 Capitolo 2. TWNET: Tetra Wireless NETwork Figura 2.17: Occupazione trama temporale durante una richiesta di changeover in presenza di DM-GATEway l attuale master che, nel caso in cui il primo terminale accetti la richiesta di changeover, invierà un DM-TX ACCEPT verso lo slave. La procedura continua quindi con la procedura di call set-up discussa precedentemente. In presenza di un DM-REP la procedura rimane sostanzialmente analoga. Nel caso di gateway, per la procedura di changeover sono necessarie le seguenti precisazioni. Innanzitutto c è da dire che a termine di una chiamata il gateway assume sempre il ruolo di master, pertanto non sarà possibile avere una DM-MS master. Analizziamo adesso il caso di una procedura di changeover richiesta da un DM-MS slave in presenza di gateway. Questi deve inviare una DM-GTX REQUEST PDU diretta al gateway che risponderà con una DM-GACK PDU, a questo punto la DM-MS setterà il timer DT309 (10 s) entro il quale deve ricevere una DM-GTX ACCEPT PDU o una DM- GREJECT PDU. Nel caso in cui il change-over venga accettato il terminale

84 2.1. Lo standard Tetra 67 Figura 2.18: Scambio di messaggi durante changeover al livello DMCC

85 68 Capitolo 2. TWNET: Tetra Wireless NETwork potrà inviare una DM-SETUP PDU come master. In presenza di gateway, in una chiamata DM, ognuna costituisce una chiamata separata, con un certo master e uno o più slave, analogamente, in TMO, ogni chiamata comprende trasmissioni separate. Figura 2.19: Scambio di messaggi durante changeover al livello DMCC in presenza di DM-GATEway In questo esempio, il traffico è inviato come una chiamata individuale di una MS nel sistema TMO. Per fare il changeover il chiamante prima indica

86 2.1. Lo standard Tetra 69 che la sua chiamata è terminata, usando un messaggio U-TX CEASED, la SwMI informa il gateway usando in messaggio D-TX CEASED e successivamente il gateway a turno informa la DM-MS usando il messaggio DM-TX CEASED. In questo esempio la DM-MS vuole trasmettere e richiede il permesso dal gateway inviando il messaggio DM-GTX REQUEST, la ricezione di questo messaggio di richiesta di changeover può opzionalmente essere riscontrato dal gateway con il messaggio DM-GACK. Il gateway inoltra la richiesta alla SwMI usando il messaggio U-TX DEMAND, La SwMI quindi dà il permesso di trasmettere al gateway e riceve allo stesso tempo il permesso dalla TM-MS usando i messaggi D-TX GRANTED. Alla ricezione di questo permesso dalla SwMI, il gateway come master rilascia il canale alla DM-MS usando il messaggio DM-GTX ACCEPT, la DM-MS richiedente ora diventa il master, inviando il messaggio DM-SETUP seguito dal traffico. Servizi dati narrowband Il TETRA DM SDS supporta sia servizi punto-punto che punto-multipunto. L SDS punto-punto offre l opzione dei riscontri mentre il punto-multipunto è solo senza riscontri. L SDS è essenzialmente un servizio di messaggistica ottimizzato al fine di garantire un servizio veloce per lo scambio di brevi messaggi di testo o di un breve messaggio predefinito come un messaggio di emergenza. Il messaggio è veicolato all interno del canale di segnalazione e può essere inviato o ricevuto in parallelo con una chiamata voce o dati in corso. L SDS può essere anche utilizzato per applicazioni come la localizzazione automatica dei veicoli (LIP) o per il supporto della sicurezza (OTAR). L S- DS in DM supporta l invio di messaggi la cui lunghezza in bit non superi i I messaggi possono essere inviati su canale libero oppure tramite stealing (solo STATUS) o call transaction all interno di una chiamata. Possono

87 70 Capitolo 2. TWNET: Tetra Wireless NETwork essere inviati attraverso un DM-REP ed essere diretti verso o ricevuti dal sistema V+D tramite un DM-GATE. Un messaggio breve punto-punto è inviato da una MS mittente ad una MS ricevente utilizzando la frequenza radio portante DM selezionata. La MS destinataria è indirizzata attraverso il suo ITSI usando lo schema di indirizzamento standard, la ricevente riscontra la ricezione del messaggio, se è stato richiesto, e la MS mittente può riprovare l invio un certo numero di volte se il riscontro è atteso e non viene ricevuto. Un messaggio breve punto-multipunto è inviato da una MS mittente a un gruppo di una o più MS riceventi usando la frequenza radio portante DM selezionata. Il gruppo è indirizzato attraverso il suo GTSI utilizzando lo schema di indirizzamento standard. Non ci sarà riscontro dalle MS riceventi in questo caso, ma la MS mittente potrà ritrasmettere il messaggio un certo numero di volte per aumentare il livello di affidabilità dell invio. Una DM-MS che vuole inviare un messaggio breve senza riscontro segue le procedure per accertarsi dello stato del canale, se il canale è nello stato free, la DM-MS può linearizzare il suo trasmettitore. Quindi stabilisce la sincronizzazione con il canale e contemporaneamente si pone come master trasmettendo una sequenza di intestazioni DM-SDS UDATA usando la struttura DSB (sdu in figura 2.20, dove sono 8 i messaggi inviati in questo esempio). Il messaggio intestazione DM-SDS UDATA contiene le informazioni sul conteggio del frame che, in questo esempio, definisce la loro posizione nella struttura temporale nei frame 17 e 18 della struttura multi frame ciclica a 18 frame. La stazione master DM-MS trasmette quindi le parti rimanenti del messaggio breve (sd in figura 2.20), senza la ripetizione e usando la struttura DNB, nello slot 1 dei frame successivi. In questo esempio le parti rimanenti del messaggio occupano tre slot e sono inviate nei frame da 1 a 3. Per affidabilità, la stazione DM-MS può ripetere l invio del messaggio completo

88 2.1. Lo standard Tetra 71 immediatamente, senza ricontrollare che il canale sia libero, e iniziando di nuovo con le DSB. In esempio c è la ripetizione completa di un messaggio, con le DSB inviate nei frame 4 e 5, e le tre DNB inviate nei frame 6 e 8. La figura 2.20 illustra inoltre dove la segnalazione di pre-emption è permessa durante la trasmissione di un SDS. Brevi DSB di occupazione sono inviati nello slot 3 dei frame 6, 12 e 18 durante la trasmissione dei DNB. Figura 2.20: Occupazione della trama per l invio di un SDS Si considera adesso il caso di un SDS inviato attraverso un DM-REP. Una DM-MS che vuole inviare un SDS senza riscontro attraverso un DM- REP segue le procedure per accertarsi dello stato del canale, a condizione che il canale sia trovato libero la DM-MS può linearizzare il trasmettitore. Quindi stabilisce la sincronizzazione con il canale e contemporaneamente il suo ruolo a master inviando una sequenza di intestazioni DM-SDS UDATA sul link master, in un appropriato numero di frame. Le intestazioni DM- SDS UDATA contengono informazioni sul conteggio dei frame, che definisce la loro posizione nella struttura temporale ciclica multi frame a 18 frame, nell esempio mostrato in figura 2.21, sono inviati 7 burst di sincronizzazione (sdu in figura 2.21) contenenti informazioni sul conteggio di frame e definendo la loro posizione nei frame 17 e 18. Il master DM-MS quindi rimane in ascolto di DM-SDS UDATA ritrasmesso dal DM-REP sul link slave come conferma che la sua segnalazione al DM- REP è avvenuta con successo. Il DM-REP può trasmettere in un numero

89 72 Capitolo 2. TWNET: Tetra Wireless NETwork diverso di frame dal numero usato dal master DM-MS. Comunque, in questo esempio, invia i burst di sincronizzazione in 2 frame per un totale di 8 burst. Il master DM-MS quindi trasmette la parte rimanente dell SDS (sd in figura 2.21), senza ripetizione nello slot 1 del seguente frame. In questo esempio le parti rimanenti del messaggio occupano due slot e sono inviate nel frame 3 e 4. Per affidabilità, la master DM-MS può ripetere il messaggio completo immediatamente (senza verificare di nuovo che il canale sia libero), in esempio c è una ripetizione del messaggio, inviato nei frame 5 e 6. La figura 2.21 illustra anche dove il segnale di pre-emption è permesso durante la trasmissione di un SDS. Figura 2.21: Occupazione della trama per l invio di un SDS in presenza di DM- REPeater Il protocollo per l invio di DM SDS in presenza di un gateway è simile a quello base, in presenza di sole DM-MS. Gli SDS possono essere inviati in tutti i modi consentiti e le PDU sono le stesse. Esistono però alcune differenze infatti gli SDS sono riscontrati solo a livello 2 sul sistema TMO. Per coerenza quando una DM-MS invia un SDS attraverso un gateway usando il servizio con riscontro, il riscontro è generato dal gateway come equivalente del riscontro a livello 2 del TMO. I gateway quindi inoltrano gli SDS alla

90 2.1. Lo standard Tetra 73 SwMI usando le procedure appropriate definite per il caso base. Gli SDS possono essere inviati anche da utenti TMO a una o più DM-MS attraverso il gateway: questo riceve l SDS dalla SwMI e genera un riscontro di livello 2 se richiesto, quindi inoltra l SDS sul canale DM verso la o le DM-MS. Analizziamo adesso la procedura di invio di SDS senza riscontro dal punto di vista dello scambio di messaggi ad alto livello. Tale procedura può essere avviata solo in caso di canale libero e prevede l invio di un certo numero di DM-SDS UDATA consecutivi. Poiché tale procedura è senza riscontro, maggiore è il numero di DM-SDS UDATA PDU che vengono inviate e maggiore è l affidabilità della procedura. Figura 2.22: Scambio di messaggi a livello DMCC durante l invio di SDS Status messages Gli status messages sono inviati dai terminali al fine di comunicare in automatico lo stato del nodo. Gli status messages sono caratterizzati da: i dati sono inviati come valori numerici a 16 bit; valori sono liberi mentre il resto sono riservati al sistema; sono convertiti in testo al terminale e workstation ricevente;

91 74 Capitolo 2. TWNET: Tetra Wireless NETwork veloci ed efficienti; facili da usare. Text messages I messaggi di testo sono invece messaggi inviati dagli operatori che utilizzano i terminali. Sono caratterizzati da: ne esistono 4 tipi diversi: SDS-1, SDS-2, SDS-3 and SDS-4; SDS-1, -2 e -3 sono a lunghezza fissa (16, 32, 64 bits); SDS-4 è a lunghezza variabile (massimo 2047 bits). L identificatore di protocollo definisce come SDS-4 è usato; l uso più comune e messaggio di testo (140/160 caratteri) e Authomatic Vehicle Location; il testo è inserito attraverso la tastiera del telefono, dispositivo unico per voce e dati. Servizi dati a circuito Una connessione bearer è una comunicazione dati punto-punto o punto-multipunto fra una MS chiamante e una o più MS chiamate. Può essere effettuata solo fra MS che hanno selezionato la stessa frequenza portante radio DM con modo di operazione simplex. TETRA DMO offre tre tipi di connessioni dati a circuito dipendentemente dal fatto che i dati siano meno protetti, dal livello di protezione desiderato. La differenza fra servizi bearer protetti e non protetti è che il servizio bearer protetto fornisce la protezione di errore come definito nella clause 8 di [8]. Il risultato è un canale più affidabile e robusto a spesa di una riduzione del data rate effettivo di utente.

92 2.1. Lo standard Tetra 75 Servizi a circuito non protetti I servizi a circuito non protetti supportano connessioni punto-punto (chiamate individuali) e punto-multipunto (chiamate di gruppo). Il throughput dati all interfaccia utente è 7,2 kbit/s. Servizi a circuito protetti I servizi a circuito protetti supportano connessioni punto-punto e punto-multi punto. Sono definiti sei tipi di servizi protetti in TETRA DMO offrendo due livelli differenti di protezione contro gli errori usando una protezione di tipo forward nello stream di dati trasmessi. La protezione agli errori è come definita in [8] e i sei servizi offrono throughput dati all interfaccia utente con 4,8 kbit/s o 2,4 kbit/s con rate di protezione agli errori di approssimativamente 2/3 e 1/3, rispettivamente. Per avere una protezione ulteriore contro gli errori, interleaving con profondità 1, 4 o 8 possono essere usati insieme ai due livelli di protezione dell errore, risultando così sei opzioni di servizio. La trasmissione della voce attraverso connessioni a circuito protette non è standardizzata ma il suo uso non è specificatamente escluso La sicurezza nel Tetra DMO La modalità DMO permette agli utenti Tetra di parlare e scambiare dati sfruttando il collegamento radio diretto senza la gestione delle BS Tetra. Le stazioni vengono organizzate in gruppi, all interno dei quali ogni utente è implicitamente autenticato attraverso la conoscenza dei parametri di cifratura comuni al gruppo. Esistono due ulteriori modalità di utilizzo del Tetra DMO: la modalità Repeater e Gateway. La prima modalità viene utilizzata per connettere all interno del gruppo un device Tetra con un altro sfruttando un nodo intermedio (il repeater), qualora la copertura radio del singolo dispositivo non dovesse essere sufficiente a raggiungere il destinatario. La

93 76 Capitolo 2. TWNET: Tetra Wireless NETwork seconda invece viene utilizzata per interfacciare la rete Tetra TMO con un gruppo DMO che potrebbe non trovarsi sotto copertura delle BS. Air interface encription Nella modalità DMO, Tetra offre quattro possibili livelli di sicurezza: DM-1: E il livello base, in cui non vengono implementate primitive crittografiche e tutto il contenuti informativo viene fatto passare in chiaro sulla rete. DM-2-A: Viene criptato il traffico utente e segnalazione. La parte del pacchetto contenente gli indirizzi è in chiaro. Questa classe permette di usare un repeater con address check indipendentemente che questo sia in possesso delle chiavi crittografiche. DM-2-B: Viene criptato anche la parte dell indirizzo di destinazione (SSI) e tutto il traffico SDU. La funzione di repeater non è compromessa (il repeater non deve possedere le chiavi) ma non viene verificato l indirizzo di destinazione. La sorgente del messaggio è in chiaro, quindi un eventuale terzo terminale può effettuare pre-emption. DM-2-C: Viene criptato tutto il pacchetto di sincronismo e tutto il traffico SDU e PDU, in particolare tutti gli indirizzi. Eventuali dispositivi intermedi devono essere a conoscenza delle chiavi. Il primo compito dei terminali Tetra quando vogliono iniziare una chiamata è quello di stabilire e concordare il livello di sicurezza da usare. La classe di sicurezza usata dovrà essere mantenuta per tutta la durata della comunicazione. Ogni MS deve mantenere un profilo di sicurezza associato a ciascun indirizzo destinatario. Ogni singolo profilo di sicurezza consta di:

94 2.1. Lo standard Tetra 77 Un Identificativo del KSG usato per la cifratura (KSG-Identifier) L identificativo della chiave (Static Cipher Key) SCK usata per la trasmissione (SCKN) L identificativo della chiave SCK in ricezione La classe sicurezza di preferenza e quella minima usata per la trasmissione La minima classe accettata per la ricezione La classe minima accettata da parte del master della chiamata per le operazioni di pre-emption. Nella fase di set-up della chiamata vengono comunicati, da parte del master, i parametri di sicurezza contenuti nel frame DMAC-SYNC. Il destinatario della chiamata confronta tali parametri di sicurezza con quelli propri predefiniti per la comunicazione con quell indirizzo chiamante: se risultano essere identici i KSG usati, le chiavi appartenenti allo stesso Key Association Group (KAG) e il livello di sicurezza uguale o superiore a quello minimo, la chiamata viene accettata. In caso contrario viene inviato un messaggio di security parameter mismatch se si sta usando la modalità presence-check, altrimenti viene semplicemente ignorata la richiesta. Lo stesso procedimento viene usato anche da parte del master qualora gli venga fatta una richiesta di pre-emption da parte dello slave. In modalità DMO una procedura di autenticazione esplicita non è prevista, la conoscenza delle chiavi SCK per un determinato gruppo DMO prova implicitamente l autenticità della MS. Le chiavi SCK possono essere installate, fino ad un massimo di 30, direttamente sui singoli terminali con procedure off-line o alternativamente possono

95 78 Capitolo 2. TWNET: Tetra Wireless NETwork essere distribuite utilizzando l infrastruttura Tetra TMO attraverso il protocollo OTAR. Ogni MS dispone di 30 Static Cipher Keys utilizzabili, per far si che la comunicazione possa avvenire, tra due dispositivi deve esistere almeno una chiave in comune da poter usare per la cifratura. Lo stesso vale nel caso in cui per la comunicazione venga usato un repeater con address check o un gateway. Ogni chiave ha un durata di utilizzo, al termine del quale viene sostituita da un altra chiave scelta all interno del set di chiavi di quel gruppo DMO. Per facilitare tali procedure di gestione delle chiavi durante una chiamata, è previsto un ulteriore sotto-raggruppamento delle chiavi, associando uno o più identificativi SCKN con un Group Short Subscriber Identity GSSI. Ogni sottogruppo di chiavi SCK associati ad un GSSI, prende il nome di Key Association Group KAG, ogni MS individua una chiave di default in un KAG per la trasmissione, mentre potrà utilizzare le altre per la ricezione. Ogni GSSI associato ad un SCKN avrà tante corrispondenti chiavi associate quante sono i subset, cioè uno per ogni subset, per esempio, se vengono creati tre subset, ciascuno sarà formato da 10 chiavi e se un determinato GSSI era associato al numero SCKN 3, dopo la suddivisione, sarà associato alla chiave 3 di ciascun subset ovvero la SCKN 13 e la SCKN 23. Oltre alla suddivisione statica delle chiavi in sottogruppi esiste anche una procedura dinamica. Il meccanismo OTAR può essere utilizzato se il terminale ha un accesso TMO per associare una determinata chiave di cifratura ad un certo indirizzo destinatario. E2E encryption Questo meccanismo di cifratura viene applicato solo al traffico e alla segnalazione proveniente dallo strato dell utente (U-plane). Lo standard ETSI non si occupa di descrivere gli algoritmi di cifratura da usare o come gestire le chiavi cifratura, ma definisce un meccanismo di sincronia

96 2.1. Lo standard Tetra 79 quando vengono usati degli stream cipher per criptare il traffico. La cifratura end-to-end ha i seguenti requisiti: lo stesso meccanismo deve essere usato in entrambe le direzioni i processi di sincronizzazione nelle due tratte devono risultare indipendenti la cifratura E2E fa parte dell user plane (è quindi indipendente dall AIE) il trasporto dell informazione in chiaro e cifrata devono mantenere la struttura temporale Assumiamo che il processo di cifratura avvenga attraverso un KSG che in questo caso prenderà il nome di End-to-End KSG (EKSG). Il KSG ha due input: una chiave di cifratura (CK) ed un vettore di inizializzazione (IV). Il blocco funzionale F1 cifra il testo in chiaro con il bit stream in uscita dall EKSS (un generatore di numeri pseudo random), generando il testo cifrato. Dall altro lato la funzione F1 inversa decifra il testo in chiaro utilizzando il bit stream sincronizzato. La funzione F2 introduce delle informazioni di sincronia che al ricevitore verranno estratte dalla funzione F3 per sincronizzare l EKSS. Collegato al blocco funzionale per le cifratura/decifratura, sarà presente un interfaccia di controllo che avrà i compiti di: selezione della chiave CK selezione dell algoritmo KSG gestire l encryption state (on/off)

97 80 Capitolo 2. TWNET: Tetra Wireless NETwork Figura 2.23: Diagramma funzionale dei meccanismi di encryption e decryption Per evitare la ripetizione nella generazione dello streaming del KSG, il parametro IV può essere reso variabile in base al tempo. Nell architettura TETRA il blocco funzionale dell E2EE trova posto nell User Plain allo strato superiore dell AIE, che svolge le sue funzionalità in modo indipendente. Non esistono quindi requisiti sugli strati inferiori, se non il trasporto del bit di informazione negli header necessario a segnalare che il traffico è cifrato con cifratura E2E. 2.2 Integrazione rete Tetra DMO con rete wireless mesh L obbiettivo prefissato del progetto TWNET è quello di creare una rete di accesso wireless basata sullo standard Tetra DMO per applicazioni di enti istituzionali in ambiti di emergenza. La rete sfrutta la modalità di comunicazione diretta dello standard e viene estesa utilizzando una rete wireless di

98 2.2. Integrazione rete Tetra DMO con rete wireless mesh 81 tipo ad-hoc, creando così un infrastruttura con i requisiti: auto instradante; non gerarchica; facilmente collocabile; adatta per applicazioni di emergenza. Inoltre la rete ad-hoc deve essere in grado di supportare connessioni multihop, aumentando la copertura della rete DMO che da standard non supporta questa funzionalità. Per garantire tali feature abbiamo selezionato una soluzione che prevede l integrazione, nel sistema di telecomunicazione Tetra, di una rete MANET: Mesh Ad-hoc NETwork. Questo tipo di reti hanno la caratteristica di essere costituite da terminali dotati delle medesime funzionalità, in grado di auto organizzarsi rendendo superflua una qualsiasi infrastruttura fissa per fornire supporto alle comunicazioni. Il sistema risulterà quindi autonomo con sia i terminali utente Tetra che i nodi di accesso della rete MANET liberi di muoversi ed in grado di auto configurarsi dinamicamente per la creazione della rete TWNET. Gli scenari di rete che sono stati presi in considerazione sono principalmente due: scenario isolato; scenario interconnesso tramite gateway. La rete di supporto MANET viene fornita tramite il sistema di autoforming CADAE presentato nel capitolo 1 che garantirà una rete di supporto il più efficiente possibile, in grado di ridurre al minimo le interferenze elettromagnetiche per ottimizzare le comunicazioni wireless; quindi sarà garantita

99 82 Capitolo 2. TWNET: Tetra Wireless NETwork una estensione dei servizi Tetra su tale infrastruttura affrontando problematiche con complessità crescente col numero di terminali mobili che andranno ad utilizzare tale rete Elementi costitutivi la rete TWNET Lo scenario preso in considerazione per questo progetto, presentato in figura 2.24, costituisce l obbiettivo ultimo del lavoro. Figura 2.24: Schema dello scenario TWNET Nella figura 2.24 si possono distinguere i tre agenti principali presenti nella rete TWNET: 1. Mobile Node 2. Terminale Tetra 3. Gateway Mobile Node Il Mobile Node è l elemento costituente la rete ad-hoc ed ha il compito di interconnettere le varie isole Tetra DMO con la rete MANET, per far

100 2.2. Integrazione rete Tetra DMO con rete wireless mesh 83 questo deve essere in grado di trasportare la segnalazione DMO da e verso la rete di backbone. Quindi il fulcro dell integrazione Tetra/Wi-fi risiede nelle caratteristiche eterogenee del nodo, che sarà, inoltre, in grado di svolgere sia il ruolo del comune terminale Tetra che di router mesh IP. Il Mobile Node deve quindi essere in grado di connettersi all isola DMO come terminale ed implementare le funzionalità di controllo dei servizi di telefonia, deve avere funzionalità di routing così da poter gestire l instradamento dei pacchetti nella rete mesh ed infine essere in grado di connettersi sia con gli altri nodi mobili che con device IP, come per esempio un telefono VoIP o un Laptop. Inoltre devono essere implementate funzionalità per permettere ai nodi mobili di gestire la sicurezza delle comunicazioni, con particolare attenzione al supporto dei sistemi di cifratura forniti dallo standard Tetra DMO. Il Gateway Mobile Node è in tutti gli effetti un Mobile Node, dal quale eredita tutte le funzionalità, ma con alcune particolarità aggiuntive: infatti deve essere in grado di connettersi ad una rete integrata Tetra e comunicare con una Base Station. Infine il Terminale Tetra costituito da un device Tetra DMO standard che senza alcuna modifica deve essere in grado di comunicare con gli altri elementi della rete in maniera completamente trasparente, senza cioè accorgersi della presenza dell infrastruttura TWNET. Quindi i macro-requisiti che il sistema TWNET deve rispettare sono: L interfaccia aria fra TETRA Terminal e Mobile Node deve essere conforme allo standard TETRA DMO al fine di rendere interoperabile il nodo mobile con TETRA Terminal di altri produttori. Deve supportare la presenza di eventuali DM-REP (repeater secondo lo standard TETRA DMO) nelle isole.

101 84 Capitolo 2. TWNET: Tetra Wireless NETwork Deve supportare la presenza di eventuali DM-GATE (gateway fra reti TETRA DMO e reti TETRA TMO) all interno della rete. La rete TwNET dovrà essere non gerarchica di tipo ad-hoc, fast-deployable, self-forming and self-configuring. La rete TwNET deve sfruttare la modalità di comunicazione diretta (DMO) dello standard TETRA, interoperante con tecnologie Wireless LAN. La rete TwNET dovrà esporre un interfaccia di gestione per le funzioni di: Fault, Configuration, Accounting, Performance and Security. La rete TwNET deve essere costituita da Nodi Mobili trasportabili su veicoli attrezzati (nodi di accesso trasportabili), pertanto facilmente dispiegabili nel territorio in condizioni di emergenza. I Nodi Mobili trasportabili devono supportare modalità di comunicazione diretta Single hop e Multihop. La rete TwNET deve prevedere l utilizzo di Nodi Mobili Gateways trasportabili su veicoli attrezzati (nodi gateway trasportabili), pertanto facilmente dispiegabili nel territorio in condizioni di emergenza. I Nodi Gateway devono supportare modalità di comunicazione verso infrastrutture GPRS/GSM, WiFi, WiMAX Soluzione integrata Tetra/IP Una delle possibili soluzione per l integrazione fra due sistemi così diversi come il Tetra DMO e una rete IP è quella di adottare una rete eterogenea. Infatti un sistema DMO non permette comunicazioni multihop ma soltanto

102 2.2. Integrazione rete Tetra DMO con rete wireless mesh 85 singlehop, l unica estensione prevista da standard è costituita dall adozione di DM-REP (Repeater) che permettono di estendere il raggio di copertura ma che non costituisce un nodo attivo della rete. Quindi la nostra soluzione permette di separare la rete di accesso che supporta lo standard DMO mentre la parte di trasporto dati e segnalazione (backbone) viene implementata su protocollo IP che risulterà però completamente trasparente alla rete di accesso. In questo modo riusciremo ad ottenere una rete ad-hoc multihop a banda larga sul lato di backbone, e una rete di accesso in grado di fornire gli stessi servizi implementati dalle reti Tetra DMO (chiamata, changeover, pre-emption, SDS). La scelta, lato backbone, di appoggiarci ad una rete WiFi permette l utilizzo di una tecnologia molto diffusa ed a basso costo che però permette l estensione dei servizi di rete DMO in ambienti dove fino ad ora non era possibile. Le caratteristiche delle reti WiFI sono principalmente: basso costo di realizzazione; la possibilità di creare reti mesh costituite da nodi multi-interfaccia; alta diffusione; interfacce con protocolli di routing: in ambito IEEE sono state sviluppate metriche ed interfacce che permettono una gestione efficiente delle politiche di instradamento [9]; ampiezza di banda diversi ordini di grandezza superiore rispetto a quella fornita dal Tetra DMO 50kbps contro 54Mbps dello standard IEEE variante a o g; il supporto a meccanismi di sicurezza avanzati forniti dallo standard IEEE802.11i;

103 86 Capitolo 2. TWNET: Tetra Wireless NETwork la Quality of service fornita tramite il supporto a code di pacchetti differenziate per tipologia di servizio per supportare differenti priorità di traffico secondo lo standard IEEE e Nodo TWNET Il nodo mobile risulta essere l elemento base di tutto il sistema TWNET, come abbiamo visto deve integrare sia le funzionalità di un terminale Tetra che quelle di un router mesh. Le funzionalità che devono essere implementate sono derivate dall implementazione DM-MS, inoltre non può essere introdotta alcuna modifica nell interfaccia aria prevista dallo standard ETSI. Quindi per rendere possibile l interfacciamento con la rete MANET si rende necessaria un estensione dell implementazione DMO sui terminali DM-MS che permetta lo scambio delle informazioni legate al progetto TWNET. Il Mobile Node può essere visto come costituito da due componenti fondamentali: 1. Mobile Terminal (MT): si sviluppa dal DM-MS standard che gestisce i servizi lato DMO 2. Terminal Equipment (TE): che realizza la connessione fra DM-MS e la rete TWNET Ogni nodo mobile può ricoprire tre macro stati: Idle: il nodo non è coinvolto nel routing di una chiamata o di un sds, quindi nell isola DMO di appartenenza non è attiva alcuna chiamata. Master: il nodo mobile è attivo nel routing di una chiamata TWNET dove l isola di appartenenza è destinataria.

104 2.2. Integrazione rete Tetra DMO con rete wireless mesh 87 Slave: il nodo mobile è attivo nel routing di una chiamata TWNET, in questo caso la sorgente della chiamata proviene dall isola di appartenenza. Il nodo mobile è attivo nel indirizzamento della chiamata ma non è in grado di parteciparvi come destinatario, ne di attivarne una; i suoi compiti si limitano alla gestione del traffico ed alla sua esportazione/importazione verso/dalla rete TWNET. I suoi compiti dipendono strettamente dallo stato in cui si trova il nodo: quando questi è il Master della chiamata, il suo compito è quello di memorizzare le informazioni contenute nelle PDU ricevute dalla rete multihop per ricostruire i dati da inviare sull isola DMO; inoltre deve accertare la presenza nella propria isola di competenza di device Tetra, come repeater o gateway, per poter stabilire correttamente il protocollo da utilizzare. Nel caso in cui il nodo mobile sia Slave deve elaborare le informazioni esportate dall isola DMO, prelevare i campi delle PDU, creare il pacchetto di comunicazione TWNET per inviarlo all interno della rete IP. Il protocollo TWNET Per permettere il corretto invio e ricezione delle informazioni prelevate da un isola DMO e per renderne possibile il re-invio all interno delle isole destinatarie si è reso necessario la definizione di un protocollo di trasmissione per coordinare i vari cambiamenti di stato dei nodi mobili all interno della nostra rete. La comunicazione delle segnalazioni e dei dati (voice + data) tipici del DMO verranno così incapsulati in pacchetti IP/UDP composti a livello applicativo da due sezioni: header TWNET e payload TWNET. Header TWNET Sono stati definiti vari tipi di pacchetti TWNET, per poter distinguere le segnalazione dal traffico voce e per meglio gestire le fasi

105 88 Capitolo 2. TWNET: Tetra Wireless NETwork di start-up di una chiamata. L header (Tabella 2.4) risulta essere uguale per tutti i vari tipi di frame ed è costituito da vari campi: PDU Type: lunghezza 8 bit, distingue le varie tipologie di PDU. AIE settings: lunghezza 40 bit, contiene i campi necessari per ricostruire la cifratura AIE nell isola di destinazione; è costituito da 4 sotto campi: 1. Air interface encryption state (2 bit); 2. Time variant parameter (29 bit); 3. KSG number (4 bit); 4. Encryption key number (5 bit). Unique ID: lunghezza 8 bit, identifica in maniera univoca la PDU all interno della rete TWNET per evitare ambiguità e risolvere problemi generati da eventuale replicazione dei messaggi a livello della rete IP. Tale campo è costruito nel seguente modo: se è possibile ricavare il numero del frame contenuto nella PDU proveniente dall isola DMO (numero compreso fra 1 e 18) il campo sarà costituito da: 1. 3 bit impostati a 0; 2. 5 bit contenenti il Frame Number esportato dal DMO. Se il numero non permette un identificazione univoca (nel caso degli SDS la stessa PDU viene ripetuta su più frame non rendendo univoco il Frame Number), tale campo sarà del tipo: 1. 1 bit impostato a 1;

106 2.2. Integrazione rete Tetra DMO con rete wireless mesh bit generati a partire dal frame number e da altre informazioni presenti in modo da generare un numero che possa essere associato univocamente con la PDU. In questo modo associando lo Unique ID insieme ai campo Called party TSI e Calling party TSI è possibile identificare in modo quasi univoco la PDU. Resta l ambiguità in cui venga inviata una stessa PDU dallo stesso mittente, allo stesso destinatario, nello stesso Frame Number ma in un superframe diverso. Destination address type: lunghezza 4 bit, identifica il tipo di indirizzo del destinatario e viene utilizzato a livello 2. Indica se l SSI è o true o pseudo. Called party TSI: contiene il GTSI o l ITSI del destinatario della chiamata o del SDS. Si tratta, rispettivamente, o di indirizzo di gruppo o individuale. Source address type: identifica il tipo dell indirizzo del mittente. Calling party TSI: contiene l indirizzo del mittente. Area selection area master: lunghezza 48 bit, identifica l isola chiamante, potrebbe corrispondere all ITSI del Mobile Node dell isola chiamante. Area selection isola slave flag: lunghezza 8 bit, indica se il campo Area selection isola slave: è inserito. Area selection isola slave: lunghezza 48 bit, identifica il Mobile Node dell isola destinataria della chiamata. Questo è un campo opzionale non è sempre presente in tutte le PDU.

107 90 Capitolo 2. TWNET: Tetra Wireless NETwork Information Elements Lenght Type PDU type 8 M AIE settings 40 M Unique ID 8 M Destination address type 4 M Called party TSI 48 M Source address type 4 M Calling party TSI 48 M Area selection isola master 48 M Area selection isola slave flag 4 M Area selection isola slave 48 C Reserved 16 M Header TWNET 280 M Tabella 2.4: Schema del Header delle PDU TWNET Reserved: lunghezza 16 bit, e destinato ad usi futuri. Struttura dei pacchetti TWNET Abbiamo visto che vi sono due tipi di pacchetti che vengono generati dai sistemi Tetra DMO, e si distinguono dalla componente che li ha generati (Capitolo 2.1.1): i pacchetti di segnalazione vengono creati dal control plane, mentre i pacchetti traffico voce e dati sono generati a livello utente dallo user plane. Nel sistema integrato TWNET i pacchetti a livello 1 e 2 lato DM-MS vengono definiti dallo standard Tetra, mentre i pacchetti a livello superiore possono essere costituiti da un header TWNET a livello di rete e protocollo UDP a livello trasporto. In tabella 2.5 sono rappresentati gli schemi di incapsulamento dei pacchetti TWNET.

108 2.2. Integrazione rete Tetra DMO con rete wireless mesh 91 Call Control Tetra voice SDS UDP IP Tabella 2.5: Struttura dei pacchetti TWNET Struttura Hardware La soluzione TWNET prevede quindi l integrazione di un terminale Tetra DMO con un router wireless mesh per creare il Mobile Node. Questi due elementi devono essere in grado di scambiarsi dati e informazioni di controllo tramite un interfaccia interna al nodo secondo un protocollo di segnalazione. Quasi tutti i terminali Tetra in commercio implementano lo standard ETSI PEI(Peripherical Equipment Interface) [10], che fornisce un interfaccia di comunicazione che può essere collegata a diversi connettori fra cui una porta seriale RS-232 o USB; solitamente lo standard PEI viene utilizzato per inviare e ricevere comandi AT, abbiamo quindi scelto di usare questa interfaccia per connettere il Terminal Equipment al Mobile Terminal. Nello sviluppo del nostro prototipo è stata usata una connessione seriale RS-232 per poter utilizzare anche terminale Tetra più datati e non dotati di connettore USB Sviluppo software di intercomunicazione Pe2Ne: Pei to Network Si è reso indispensabile lo sviluppo lato TE di un software per ricevere ed inviare dati da e verso l interfaccia PEI, tradurre i comandi AT ed incapsularli in pacchetti UDP per inviarli nella backbone multihop. I requisiti di tale software sono:

109 92 Capitolo 2. TWNET: Tetra Wireless NETwork Figura 2.25: Interfacce e PDU presenti nello scenario integrato Portabilità: deve poter girare sia su router mesh wireless equipaggiati con processore ARM big-endian, sia su workstation x86 little-endian. Real Time: il software deve essere in grado di gestire sia la segnalazione su seriale, sia il traffico di rete con vincoli temporali stringenti, in modo da poter garantire un servizio di comunicazione di tipo voce molto sensibile ai ritardi di trasmissione. Efficienza: le piattaforme su cui girerà il software saranno, fra le altre, dei router mesh embedded caratterizzati dai bassi consumi, alimentate Power over Ethernet, ma dotate di scarse capacità di calcolo e con poche risorse di memoria. Particolare attenzione è stata quindi posta per sviluppare un software leggero, in grado di utilizzare il minor quantitativo possibile di risorse di sistema, garantendo però le funzionalità necessarie allo scopo. Affidabilità: si è prestato attenzione in fase di design e sviluppo per garantire la disponibilità del servizio, sia tramite un attento processo di testing del codice sia nella creazione della macchina a stati che deve

110 2.2. Integrazione rete Tetra DMO con rete wireless mesh 93 essere dotata di procedure di recovery per evitare blocchi del servizio e monitorare il funzionamento del Mobile Terminal. La scelta quindi è ricaduta sullo sviluppo di un software C++, denominato pe2ne (PEI to NEtwork), utilizzando solo librerie standard, disponibili per entrambe le architetture in oggetto, e sviluppato con particolare attenzione verso la portabilità del codice. Il software girerà come demone sulle macchine che andranno a costituire il nostro prototipo di rete, queste saranno dotate di sistema operativo GNU/Linux ed in particolar modo di distribuzione Open- WRT [1] e Ubuntu [11]: la prima una distribuzione specifica per piattaforme embedded, che fornisce una completa toolchain per lo sviluppo di applicativi e la loro integrazione con il sistema operativo; la seconda è una delle più diffuse distribuzioni linux per desktop. L obiettivo principale del progetto è quindi quello di creare un estensione per il Tetra DMO: questa modalità di funzionamento, come visto nel capitolo 2.1.1, prevede una sola comunicazione contemporanea che quindi coinvolge anche i terminali non direttamente interessati dalla chiamata (saranno impossibilitati ad effettuare chiamate poiché il canale di trasmissione risulterà occupato). Tutte le segnalazioni e i dati che verranno quindi esportati da un isola DMO verso la rete devono essere propagati verso tutti i Mobile Node presenti nella rete multihop, per preservare il corretto comportamento dei servizi di una rete DMO. Per questo motivo i pacchetti entro la rete mesh saranno inviati con indirizzo di destinazione di Broadcast, le problematiche di loop nelle trasmissioni di frame e ricezioni multiple sono risolte sia da politiche di rilevamento loop che da controlli implementati nel software per il riconoscimento di pacchetti replicati; inoltre la particolare struttura ad albero binario creata dal sistema CADAE (presentata nel capitolo 1) permette una maggiore resistenza a problemi del genere.

111 94 Capitolo 2. TWNET: Tetra Wireless NETwork Lato rete IP il demone deve agire come un modem software fra il Tetra e la rete multihop, affrontando tutte le problematiche di sistemi di questo tipo, deve cioè essere in grado di esportare correttamente tutte le informazioni da un dominio DMO, inviarle nella rete correttamente incapsulate in un frame IP/UDP ed infine riuscire ad importare tali informazioni nelle altre aree DMO. Deve quindi comportarsi come un interfaccia in grado di: leggere e scrivere i campi dei pacchetti Tetra sulla porta seriale; leggere e scrivere i campi dei pacchetti Tetra nei datagrammi UDP che verranno usati nella rete di backbone; leggere e scrivere gli appropriati comandi AT sull interfaccia PEI. Le interfacce che sono coinvolte nelle comunicazioni fra due isole tramite l infrastruttura TWNET sono schematizzate in figura Come abbiamo già visto i terminali Tetra sono in grado di esportare informazione e segnali di controllo attraverso l interfaccia PEI: tale standard definisce sia la sintassi di comandi AT per inviare istruzioni finalizzate alla lettura e scrittura di dati sul terminale, ma definisce anche la sintassi di alcuni messaggi non sollecitati inviati dal terminale al manifestarsi di un certo evento lato radio (per esempio una chiamata entrante o un SDS). Permette inoltre la generazione di chiamate, trasmissione di SDS o la richiesta di changeover senza coinvolgere la componente MMI del terminale (Man Machine Interface). Il software Pe2ne, girando come demone sul TE, legge le notifiche AT non sollecitate da un lato e utilizzerà i comandi AT di set e read per riprodurre lo stesso evento negli altri punti della rete multihop. Anche i dati voce vengono trasportati nello stesso modo, infatti le informazioni sulle chiamate vengono esportate sulla PEI come comandi AT e formattate secondo lo standard ISI [12]. In questo modo il Mobile Node che gestisce l isola DMO originante la chiamata preleva i dati,

112 2.2. Integrazione rete Tetra DMO con rete wireless mesh 95 tramite i messaggi non sollecitati sulla seriale, questi vengono incapsulati ed inviati sulla backbone; dall altra parte i pacchetti, decapsulati, permettono la creazione di comandi AT che vengono inviati sulla seriale all interfaccia PEI degli altri Mobile Node coinvolti nella chiamata. Eventuali problematiche di questa soluzione derivano esclusivamente dalla banda disponibile per la connessione verso la PEI: infatti la connessione scelta per i prototipi, una seriale RS-232, ha come transfer rate massimo bit/s che rappresenta un collo di bottiglia nel flusso di dati scambiati fra due isole (il percorso del flusso dati è sintetizzato in figura 2.25). Nonostante i terminali Tetra forniti per la creazione del prototipo di rete TWNET implementino la libreria standard ETSI AT, questa presenta delle lacune di funzionalità per gli obiettivi del progetto. Infatti pe2ne necessita l accesso ad un ampio numero di parametri, sia sotto forma di messaggi non sollecitati che tramite l uso di comandi di set e read, rendendo così necessaria un estensione alla libreria per implementare dei nuovi tipi di comandi e segnalazioni. Per esempio un nodo mobile in un isola destinataria di una chiamata deve essere in grado di cambiare l indirizzo del terminale chiamante che deve infatti risultare quello del mittente che ha iniziato la procedura all interno di un altra isola; mentre, utilizzando le librerie fornite, la chiamata nell isola destinatario risulterebbe come originata dal suo nodo mobile master. Un ulteriore estensione ai comandi AT è l implementazione dei messaggi per l estrazione e l inserimento dei frame di voce da e verso il Mobile Terminal. Quindi molte modifiche sono state eseguite anche su firmware e software del Tetra MT all interno del Mobile Node, che dovranno gestire quindi comandi ed esportare notifiche non sollecitate non standard, mantenendo contemporaneamente la retro compatibilità con la libreria standard ETSI AT.

113 96 Capitolo 2. TWNET: Tetra Wireless NETwork Finite State Machine Uno dei principali problemi è mantenere la macchina a stati finiti del software sul TE sincronizzata con quella interna del MT, infatti non è in grado di prelevare, tramite PEI, lo stato attuale del terminale Tetra; conseguentemente la macchina a stati di pe2ne deve essere rigidamente vincolata ai messaggi inviati ed alle risposte ricevute dall interfaccia PEI. Ogni volta che viene inviato un comando, viene ricevuto un messaggio di risposta, OK, se il messaggio è sintatticamente corretto, o un messaggio ERROR se non corretto o incompleto. Inoltre i passaggi di stato saranno vincolati non solo dalle risposte di verifica sintattica ma anche da messaggi di risposta alle read o dalle notifiche non sollecitate, quindi la macchina a stati deve prevedere ogni tipo di trasmissione effettuate nei passaggi da uno stato all altro. In figura 2.26 e in figura 2.27 vengono presentate le macchine a stati di una chiamata senza presence check sia dal lato dell isola originante la chiamata, sia dal lato dell isola destinataria; si può notare lo scambio di comandi sulla seriale e le rispettive risposte che vincolano i vari passaggi di stato. Le procedure schematizzate in queste FSM verranno presentate ed illustrate successivamente al paragrafo Il software inoltre gestisce l esportazione real time dei frame voce inviati dal MT sulla PEI in modo asincrono per soddisfare i requisiti tipici di questa tipologia di traffico: tali dati devono essere forniti ed inviati secondo stretti requisiti in termine di latenza, jitter e error rate. In particolar modo il jitter è il parametro più importante per garantire una buona qualità del servizio [13]; solitamente una buona soluzione per ridurre il jitter è implementare un buffer per i frame voce, ma visto anche i particolari vincoli sulle risorse di sistema il buffer non deve superare una certa dimensione per evitare l esaurimento delle risorse sul TE. Per ovviare a ciò abbiamo optato per una soluzione con due

114 2.2. Integrazione rete Tetra DMO con rete wireless mesh 97 IDLE +CTICN WAIT_SLAVE_CTCC +CTCR/SEND_UDP_RELEASE TIMEOUT SLAVE_RESERVED ERROR +CTCC +CTCR/SEND_UDP_RELEASE +TWNCSD TIMEOUT TIMEOUT TIMEOUT +CDTXG WAIT_TWNCSD SLAVE +TWNCALL/SEND_UDP_CALL WAIT_TWNCALL +CDTXC +TWNBLK/SEND_UDP_DATA Figura 2.26: Macchina a stati finiti del Mobile Node sull isola origine READ_UDP_CALL/AT+TWNCALL +OK/AT+CTSDC IDLE SENT_TWNCALL SENT_CTSDC +CTCR TIMEOUT TIMEOUT READ_UDP_CALL_DROP/ATH MASTER_RESERVED WAIT_ACK_RELEASE TIMEOUT ERROR +OK/ATD +OK/AT+CUTXC READ_PTT_PRESS/AT+CUTXD READ_UDP_CALL_DROP/ATH TIMEOUT TIMEOUT +OK READ_PTT_REL/AT+TWNCSD TIMEOUT SENT_TWNCSD MASTER WAIT_ACK_DATA READ_UDP_DATA/AT+TWNBLK SENT_ATD +CTCC TIMEOUT WAIT_MASTER_CTCC +CTOCP WAIT_CTOCP +OK Figura 2.27: Macchina a stati finiti del Mobile Node sull isola destinataria

115 98 Capitolo 2. TWNET: Tetra Wireless NETwork buffer di dimensioni dell ordine dei 10 frame, uno implementato dal software pe2ne sul TE ed il secondo quello già presente all interno del software del MT. La soluzione del doppio buffer si è resa necessaria, nonostante la presenza di una struttura analoga all interno dei terminali Tetra, vista l impossibilità di avere informazioni lato TE sullo stato di riempimento dello stesso e quindi l impossibilità di controllare il flusso dei dati voce verso il MT. Chiamata voce senza presence check In questo contesto operativo il Mobile Node deve fornire le seguenti funzionalità: il MT deve essere in grado di ricevere tutte le chiamate dell isola, includendo chiamate di gruppo e chiamate singole con identificativo TETRA destinatario diverso dal proprio il MT deve essere in grado di processare il traffico aria ed esportare sulla PEI i comandi AT in forma di Unsolicited Read Codes (comandi di lettura informazioni asincroni) il MT deve essere in grado, una volta instaurata la chiamata, di esportare la voce sulla seriale PEI secondo il formato descritto dalla definizione ISI [12] il MT deve essere in grado di processare i comandi AT provenienti dal TE e tradurli in segnalazione aria al fine di realizzare il setup e la successiva gestione della chiamata secondo lo standard DMO il MT deve essere in grado di variare la propria TETRA Identity il TE deve essere in grado di inviare verso il MT i comandi AT (standard ed aggiuntivi) necessari a trasmettere in aria la giusta segnalazione DMO

116 2.2. Integrazione rete Tetra DMO con rete wireless mesh 99 il TE deve essere in grado di leggere il flusso voce dalla PEI e tradurlo in stream di pacchetti UDP da inviare sul backbone Wi-Fi il TE deve essere in grado di rilevare segnalazione duplicata e gestirla evitando loop il TE deve essere in grado di gestire la segnalazione in banda trasmessa durante l invio del flusso voce Call Setup La prima fase analizzata è quella di Call Setup. In questa fase sull isola sorgente il MN deve ricevere la segnalazione aria ed esportare sulla PEI i comandi AT necessari a veicolare tutti i parametri che serviranno a valorizzare i campi delle PDU backbone. La procedura TWNET per segnalare la presenza di una Call Setup prevede l invio di un pacchetto dal MN dell isola mittente ai MN delle isole di destinazione (vedi figura 2.28); tale pacchetto del tipo PDU CALL SETUP è formato dall header TWNET più alcuni campi specifici (schematizzati nella tabella 2.6). Figura 2.28: TWNET Call Setup Tale PDU, in relazione alla Figura 2.28, dovrà essere composta a partire dai dati inoltrati sulla PEI all interno del MN sull isola sorgente e, dopo aver attraversato la rete multihop, sarà utilizzata dal TE del MN dell isola

117 100 Capitolo 2. TWNET: Tetra Wireless NETwork Information Elements Lenght Type PDU type 8 M AIE settings 40 M Unique ID 8 M Destination address type 4 M Called party TSI 48 M Source address type 4 M Calling party TSI 48 M Area selection isola master 48 M Area selection isola slave flag 4 M Area selection isola slave 48 C Reserved 16 M Pre-emption flag 1 M Circuit mode type 4 M Priority level 2 M End to end encryption flag 1 M Call type flag 1 M Tabella 2.6: Campi del PDU CALL SETUP

118 2.2. Integrazione rete Tetra DMO con rete wireless mesh 101 destinazione per valorizzare i parametri dei comandi AT necessari ad eseguire il setup della chiamata. Dal lato dell isola sorgente il MN riceve segnalazione aria indicante che uno dei terminali attivi nella propria zona di copertura intende effettuare una chiamata voce. Si assume che nessuna altra chiamata sia in corso e che non ci sia nessun terminale nello stato di master reservation (caso in cui la procedura corretta non è la call-setup ma la preemption od il changeover). Il MT all interno del TWNET MN dovrà quindi essere in grado di ricevere segnalazione aria proveniente dal terminale TETRA dell utente e provvedere a creare la CALL SETUP PDU i cui campi sono stati forniti in tabella 2.6. In corrispondenza della ricezione di una chiamata entrante, sia essa di gruppo che individuale, il MT esporterà in modo non sollecitato sulla PEI i comandi elencati sotto. <CR><LF> +CTICN: <CC instance>,<call status>,<ai service> <calling party identity type>,<calling party identity>, <priority level> <CR><LF> <CR><LF> +CTCC: <CC instance>,<hook>,<simplex>,<ai service>, <e to encryption>,<comms type>,<slots/codec>, <proprietary>,<tx Grant> <CR><LF> <CR><LF> +TWNCALL: <called party identity type>,<called party identity>, <call frame number> <CR><LF>

119 102 Capitolo 2. TWNET: Tetra Wireless NETwork Originariamente nelle librerie standard vengono esportati solamente i primi due comandi +CTICN e +CTCC di cui il primo con soltanto i primi tre campi obbligatori e i restanti facoltativi; nella nostra soluzione forzeremo l esportazione di tutti i parametri facoltativi rendendoli di fatto mandatori. Il valore assunto dal campo <CC instance>, che solitamente in DMO è sempre uguale a 0, per l utilizzo in TWNET è modificato per assumere i seguenti possibili valori: (binario) = 128 (decimale): per notificare la comunicazione tramite gateway; (binario) = 64 (decimale): per notificare la comunicazione con repeater; (binario) = 0 (decimale): per notificare la comunicazione con protocollo MS-MS. Il comando +TWNCALL invece è completamente nuovo alle librerie standard e permette, in fase di setup, di esportare l indirizzo destinatario, elemento fondamentale per l instaurarsi della chiamata ma che da librerie non poteva essere ottenuto via PEI. Il PDU CALL SETUP viene valorizzato come descritto in tabella 2.7 Per settare il valore del campo Call type flag si osserva il parametro <comms type>. Nel mondo DMO esso può assumere tre soli valori: 0 chiamata punto-punto senza presence check 1 chiamata di gruppo 3 chiamata punto-punto con presence check

120 2.2. Integrazione rete Tetra DMO con rete wireless mesh 103 Information Elements Lenght Details PDU type 8 2 AIE settings 40 0(non usato) Unique ID 8 <call frame number> da +TWNCALL Destination address type 4 <called party identity type> da +TWNCALL Called party TSI 48 <called party identity> da +TWNCALL Source address type 4 <calling party identity type> da +CTICN Calling party TSI 48 <calling party identity> da +CTICN Area selection isola master 48 autogenerato Area selection isola slave flag 4 0 Area selection isola slave 48 0 (non utilizzato) Reserved 16 0 Pre-emption flag 1 1 Circuit mode type 4 0 (fonia) Priority level 2 <priority level> da +CTICN End to end encryption flag 1 <e to encryption> da +CTCC Call type flag 1 <comms type> da +CTCC Tabella 2.7: Valori dei campi del PDU CALL SETUP

121 104 Capitolo 2. TWNET: Tetra Wireless NETwork Information Elements Lenght Details CC Instance 8 da +CTCC Destination address type 4 da +TWNCALL Called party TSI 48 da +TWNCALL Source address type 4 da +CTICN Calling party TSI 48 da +CTICN Isola partner 48 NULL Pre-emption flag 1 1 Circuit mode type 4 0 (fonia) Priority level 2 da +CTICN End to end encryption flag 1 da +CTCC Call type flag 1 da +CTCC Tabella 2.8: Valori degli attributi di TwnetCallData Per questo motivo si opera come segue: <comms type> = 1 o 3 Call type flag = 0 altrimenti Call type flag = 1 Al termine dell invio della CALL SETUP PSU il software pe2ne provvederà ad immagazzinare in una struttura dati apposita i dettagli sulla chiamata di cui sta facendo il routing verso la rete in modo da evitare di dover ricevere nuovamente via PEI le informazioni già esportate durante la setup e necessarie per la trasmissione delle successive segnalazioni e del traffico voce. Dato che per design il Mobile Node può gestire solo una chiamata per volta, la struttura in oggetto viene re-inizializzata ad ogni procedura di CALL SETUP. Questa struttura dati nominata TwnetCallData viene definita come una classe C++ con gli attributi privati presenti in tabella 2.8 e i rispettivi metodi di set e get. Sull isola destinataria la CALL SETUP PDU ricevuta viene tradotta nei

122 2.2. Integrazione rete Tetra DMO con rete wireless mesh 105 seguenti comandi AT: AT+TWNCALL=<Calling address type>, <Calling party identity> <CR><LF> AT+CTSDC=<AI Service>,<Called party identity type>, <Area>, <Hook>, <Simplex>, <e-to-e encryption>, <Comms type>, <Slot/Codec>, <RqTx>, <Priority> <CR><LF> ATD<called party identity> <CR><LF> Anche in questo caso è stato necessario proporre un estensione alle librerie standard, il comando AT+TWNET permette di settare nell isola di destinazione il corretto mittente della chiamata. Successivamente all invio del comando ATD il TE che origina la chiamata sull isola destinazione riceve due comandi non sollecitati tramite i quali vengono ricavati i parametri necessari alla successiva gestione della chiamata <CR><LF> +CTOCP: <CC instance >,<call status>,<ai service>,<hook>,<simplex> <CR><LF> <CR><LF> +CTCC: <CC instance>,<hook>,<simplex>,<ai service>,<e to encryption> <comms type>,<slots/codec>,<proprietary>,<tx Grant> <CR><LF> Se il parametro <Tx Grant> ha valore 0 significa che il MN ha il permesso di trasmettere traffico nell ambito della chiamata half duplex appena

123 106 Capitolo 2. TWNET: Tetra Wireless NETwork instaurata e che quindi può iniziare ad inviare in aria le trame voce. Il processing della CALL SETUP PDU include anche la creazione di una struttura dati TwnetCallData con contenuto uguale a quella creata sull isola sorgente, per mantenere in memoria tutti i parametri necessari per la creazione successiva di altri comandi AT. In riferimento a tale struttura dati il campo Isola Partner dovrà però in questo caso essere settato facendo riferimento al campo Area Isola Master ricevuto con la CALL SETUP PDU. Gestione del traffico voci A valle di una CALL SETUP il terminale TETRA inizia immediatamente ad inviare trame voce verso il MT del MN della propria isola. In realtà il terminale TETRA dell utente invierà traffico voce in aria con destinatario il nodo od il gruppo con il quale desidera parlare, sarà il MT a dover intercettare il traffico voce diretto a qualunque terminale e, nel caso che sia destinato ad un terminale TETRA non in diretta copertura del chiamante, esportare sulla PEI i frame voce codificati secondo lo standard ISI. Per trasportare i dati voce sulla rete TWNET viene definita la TRAFFIC PDU, il cui contenuto viene descritto in tabella 2.9 La dimensione del payload ISI è variabile e dipendente dalla PDU ISI trasmessa in aria, comunque da standard la lunghezza non può superare i 336 bit. Sull isola sorgente il traffico voce viene inviato in aria dal terminale utente che riveste il ruolo di master e viene intercettato dal MN che afferisce a quell isola DMO. In questo contesto il MN, che svolge il ruolo di slave, dovrà esportare sulla PEI un messaggio non sollecitato contente una serie di trame voce formattate secondo lo standard ISI: <CR><LF>

124 2.2. Integrazione rete Tetra DMO con rete wireless mesh 107 Information Elements Lenght Type PDU type 8 M AIE settings 40 M Unique ID 8 M Destination address type 4 M Called party TSI 48 M Source address type 4 M Calling party TSI 48 M Area selection isola master 48 M Area selection isola slave flag 4 M Area selection isola slave 48 C Reserved 16 M Payload ISI < 336 M Tabella 2.9: Campi del TRAFFIC PDU

125 108 Capitolo 2. TWNET: Tetra Wireless NETwork Information Elements Lenght Details PDU type 8 3 AIE settings 40 0 Unique ID 8 Autogenerato Destination address type 4 da TwnetCallData Called party TSI 48 da TwnetCallData Source address type 4 da TwnetCallData Calling party TSI 48 da TwnetCallData Area selection isola master 48 Autogenerato Area selection isola slave flag 4 0 Area selection isola slave 48 0 Reserved 16 0 Payload ISI < 336 da +TWNBLK Tabella 2.10: Valori dei campi del TRAFFIC PDU +TWNBLK: <stringa ASCII del pacchetto ISI in formato HEX> <CR><LF> Questo tipo di messaggio è stato aggiunto alle librerie standard poiché non era prevista la possibilità di esportare i dati voce durante una chiamata. Sull isola di destinazione il MN avrà completato la procedura di CALL SETUP e andrà a ricoprire il ruolo di master della chiamata instaurata, quindi alla ricezione del TRAFFIC PDU andrà ad estrarre il payload ISI ed utilizzerà i dati per alimentare il MT in modo che questo possa tradurre tali dati in PDU di traffico voce in aria. Per alimentare il MT il demone pe2ne dovrà inviare verso la PEI il messaggio AT: AT+TWNBLK= <stringa ASCII del pacchetto ISI in formato HEX>

126 2.2. Integrazione rete Tetra DMO con rete wireless mesh 109 Information Elements Lenght Type PDU type 8 M AIE settings 40 M Unique ID 8 M Destination address type 4 M Called party TSI 48 M Source address type 4 M Calling party TSI 48 M Area selection isola master 48 M Area selection isola slave flag 4 M Area selection isola slave 48 C Reserved 16 M Reservation time remaning 6 M Request flag 1 M Changheover request flag 1 M Cease cause 4 M Tabella 2.11: Campi del CALL TERMIANTED PDU <CR><LF> Call Termination Al termine della chiamata, il terminale originante invia in aria una DM-TX CEASED PDU, ovvero un frame che indica che il traffico voce è terminato e notifica quanto a lungo il canale resterà nello stato reservation. A livello di rete TWNET alla ricezione della DM-TX CEASED PDU per la chiamata, il MN creerà una CALL TERMINATED PDU i cui campi sono elencati nella tabella 2.11.

127 110 Capitolo 2. TWNET: Tetra Wireless NETwork Figura 2.29: Sequenza dei messaggi scambiati durante una chiamata senza presence check

128 2.2. Integrazione rete Tetra DMO con rete wireless mesh 111 La CALL TERMINATED PDU, in relazione alla figura 2.29, dovrà essere composta a partire dai dati inoltrati sulla PEI e, dopo aver attraversato la rete multihop, sarà utilizzata dal TE del MN dell isola destinazione per valorizzare i parametri dei comandi AT necessari ad eseguire la terminazione della chiamata. Sull isola sorgente l invio della CALL TERMINATED PDU dovrà essere eseguito appena si riceva dal lato aria la segnalazione che il terminale di origine ha cessato di inviare la trama voce, cioè quando è stato rilasciato il tasto PTT (Press To Talk) del device fisico. La segnalazione aria viene intercettata dal MN che invia sull interfaccia PEI i messaggi non sollecitati: <CR><LF> +CDTXC: <CC instance>,<txrqprmsn> <CR><LF> <CR><LF> +TWNCSD: <CC instance>,<rsv time remaining>,<request Flag> <Chgvr Request Flag>,<Cease cause>,<call frame number> <CR><LF> Il MN una volta ricevuta in aria questa segnalazione dovrà provvedere ad inviare verso la rete TWNET la CALL TERMINATED PDU assegnando ai campi previsti i valori secondo quanto indicato nella tabella Per alcuni dei campi è necessario che il MN acceda ai valori della struttura dati TwnetCallData che aveva creato durante la fase di Call Setup. Sull isola di destinazione il MN che riceverà la CALL TERMINATED PDU, confronterà i campi con quelli della struttura dati TwnetCallData che ha istanziato alla ricezione della CALL SETUP PDU e, in caso ci sia un match invierà dal TE verso il MT i seguenti due comandi AT:

129 112 Capitolo 2. TWNET: Tetra Wireless NETwork Information Elements Lenght Details PDU type 8 4 AIE settings 40 0 Unique ID 8 <call frame number> da +TWNCSD Destination address type 4 da TwnetCallData Called party TSI 48 da TwnetCallData Source address type 4 da TwnetCallData Calling party TSI 48 da TwnetCallData Area selection isola master 48 autogenerato Area selection isola slave flag 4 0 Area selection isola slave 48 0 (non utilizzato) Reserved 16 0 Reservation time remaning 6 <Rsv time remaing> da +TWNCSD Request flag 1 <Request Flag> da +TWNCSD Changheover request flag 1 <Chgvr request flag> da +TWNCSD Cease cause 4 <Cease cause> da +TWNCSD Tabella 2.12: Valori degli attributi del TERMINATED CALL PDU

130 2.2. Integrazione rete Tetra DMO con rete wireless mesh 113 AT+TWNCSD=<CC instance>,<rsv time remaining>,<request Flag> <Chgvr Request Flag>,<Cease cause><chgvr Request Flag>, <Cease cause> <CR><LF> AT+CUTXC=<CC Instance> <CR><LF> I valori dei parametri dovranno essere estratti dalla CALL TERMINAT- ED PDU eccezion fatta per il campo <CC Instance> che sarà invece estratto dalla struttura dati TwnetCallData. Il secondo comando era già previsto dalla libreria standard mentre si è reso necessario definire il primo per andare a settare quei parametri che devono essere trasposti dall isola sorgente a quella destinataria. Design software Come precedentemente accennato, abbiamo sviluppato il software pe2ne utilizzando il linguaggio ad oggetti C++ ed utilizzando solamente le librerie standard libstdc++ fornite sia per le comuni distribuzioni linux per desktop che per le distribuzioni per piattaforme embedded. Il programma è stato sviluppato per girare su sistema operativo GNU/Linux e progettato per essere un demone che, una volta caricato all avvio del servizio, resta in memoria in background in attesa di reagire al manifestarsi di un evento (per esempio la ricezione di dati su rete o su seriale). Andiamo ora a presentare le componenti principali: class IOMultiplex: gestione eventi concorrenti e accesso ai socket; class Session e class State: implementazione macchina a stati finiti;

131 114 Capitolo 2. TWNET: Tetra Wireless NETwork class UdpBuffer: buffer dati provenienti dalla rete multihop. Figura 2.30: Diagramma delle classi class IOMultiplex Il principale problema da risolvere in software che forniscono servizi di rete è come riuscire a gestire gli eventi concorrenti quali: comunicazione in lettura e scrittura sulla seriale comunicazione in lettura e scrittura sulla socket UDP timer della macchina a stati

132 2.2. Integrazione rete Tetra DMO con rete wireless mesh 115 Figura 2.31: Diagramma sequenziale

133 116 Capitolo 2. TWNET: Tetra Wireless NETwork Tali funzionalità sono state delegate alla classe IOMulitplex con un approccio sincrono al problema utilizzando la funzione select(): su un sistema Linux quando viene aperto un file o una socket, questa viene resa disponibile tramite un file descriptor, che ne permette l utilizzo sia in scrittura che in lettura; le operazioni sui file descriptor di default sono bloccanti, cioè quando vi si accede per eseguire una certa operazione, se questi non è pronto si interrompe l esecuzione del programma fino a quando il descrittore di file non diventa nuovamente in grado di essere utilizzato. Il nostro software deve poter contemporaneamente stare in ascolto di due socket in ricezione, uno lato rete IP/UDP e l altro verso la connessione seriale PEI, in questo caso l utilizzo della chiamataread() di una delle due socket bloccherebbe l esecuzione del programma impedendo di fatto la ricezione Real Time sull altra socket, la cui invocazione avverrebbe solo a lettura avvenuta dal primo socket. Per risolvere questo problema si utilizza la funzione select() che prende in input la lista dei file descriptor aperti che vogliamo utilizzare e, quando viene richiamata, blocca l esecuzione del programma fino al verificarsi di due condizioni: 1. uno o più di un file descriptor è pronto per ricevere dati e vi sono dati da leggere (nel nostro caso o è arrivato un pacchetto UDP o è stato ricevuto un messaggio dalla PEI); 2. è scaduto il timeout della select(). In questo modo ci assicuriamo di poter ricevere ed elaborare i dati quando raggiungono il TE permettendoci di garantire le tempistiche richieste. Per abilitare il controllo sui socket e contemporaneamente avviare il timer viene richiamato il metodo pubblico wait() che invoca la select e che ritorna un intero contenente quanti file descriptor sono attivi con dati pronti per essere letti, in caso ritorni 0 allora significa che il timer è scaduto. Succes-

134 2.2. Integrazione rete Tetra DMO con rete wireless mesh 117 sivamente la classe chiamante potrà notificare l evento alla macchina a stati che eseguirà le azioni dipendenti dallo stato in cui si trova in quel momento il TE (si può vedere la sequenza delle chiamate in figura 2.31). Un altra funzionalità delegata a IOMultiplex è fornire l accesso alle classi che gestiscono a basso livello le socket Linux per prelevare o inviare i dati sia verso la rete che verso la PEI. Le operazioni di trasmissione e ricezione vengono pilotate dagli stati della FSM e quindi devono poter essere richiamate da un grande numero di classi diverse; è importante avere un interfaccia comune a tutte le classi che implementano i vari stati ed è necessario che questa venga implementata dalla medesima istanza della classe IOMultiplex, è quindi stato scelto di sviluppare questo oggetto secondo il pattern Singleton [14] che garantisce queste caratteristiche. class Session e class State La macchina a stati finiti è stata sviluppata utilizzando il pattern State [14]: gli algoritmi che implementano le azioni che devono essere eseguite al manifestarsi di un certo tipo di evento in un determinato stato sono stati incapsulati all interno di metodi di un interfaccia. La classe State, astratta, crea tale interfaccia, definendo i 5 metodi corrispondenti agli eventi di invio e ricezione dati su udp o seriale e di scadenza del timeout; le classi istanziate, rappresentanti un certo stato della FSM, andranno a reimplementare i metodi che devono gestire le azioni previste per il proprio ruolo. É importante che nessun dato venga memorizzato all interno della classe State, ma che tutte le informazioni vengano copiate all interno della classe Session; quest ultima rappresenta la sessione di comunicazione TWNET ed è l entità che gestisce i parametri di comunicazione (per esempio la struttura dati TwnetCallData come da figura 2.30) ed include dentro di se la FSM. Conseguentemente è la Session che, al manifestarsi di un certo-

135 118 Capitolo 2. TWNET: Tetra Wireless NETwork evento, va a richiamare il metodo corrispondente sull interfaccia State (vedi figura 2.31) class UdpBuffer La ricezione dei messaggi sulla seriale deve avvenire immediatamente, con priorità maggiore rispetto alla ricezione lato rete multihop, poiché è requisito fondamentale che la macchina a stati della TE sia sincronizzata con quella del proprio MT: se infatti, per esempio, il MT invia un messaggio di errore o di chiusura chiamata durante una comunicazione voce, la TE deve smettere di inviare frame voce verso il terminale, scartare le TRAFFIC PDU che ha ricevuto e gestire questo cambiamento di stato per evitare di entrare in situazioni di blocco. Sempre per garantire la sincronia fra le due macchine a stati, in presenza di stati di transizione in attesa di una risposta dalla seriale, si forza il blocco dell invio dei pacchetti UDP alla Session, blocco che, come vedremo in seguito, non causerà la perdita del pacchetto ma solo un ritardo nella sua elaborazione. Inoltre lato seriale, visto che si comunica direttamente col device Tetra, non ci sono problemi di mancata ricezione di dati o di ricezione di messaggi fuori ordine. Queste però sono tutte problematiche che possono manifestarsi nelle trasmissioni via rete, in particolare se ci troviamo ad usare una rete mesh. Quindi per risolvere problemi di: perdita pacchetti UDP; arrivo pacchetti fuori ordine; jitter; è stato implementato un buffer di ricezione dei pacchetti IP. Il funzionamento è semplice, la ricezione dei dati dalla socket udp è sempre attiva, quando un pacchetto viene ricevuto, questo non passa per la classe Session e quindi

136 2.2. Integrazione rete Tetra DMO con rete wireless mesh 119 per la macchina a stati, ma viene direttamente passato all interno del buffer che è implementato all interno della classe UdpBuffer. All inserimento del pacchetto viene controllato il suo unique id e nel caso sia un frame precedente all ultimo aggiunto, viene cercato e collocato nel posto di competenza, altrimenti viene accodato in fondo al buffer. Per fare in modo che i pacchetti raggiungano la FSM viene definita una pipe: un canale dati unidirezionale, solitamente usato per le comunicazioni fra processi, che consiste in una struttura con due file descriptor, il primo fa riferimento alla cima della coda e l altro alla fine; i dati che vengono inviati usando la funzione write() nel secondo file descriptor, vengono resi disponibili per la lettura utilizzando la read() sul primo file descriptor come se si trattasse di un normale socket (vedi figura 2.32). Questo meccanismo viene utilizzato per integrare l invio dei dati dal buffer alla FSM col meccanismo della select presentato al capitolo Quando il buffer non è vuoto e presenta dati in attesa di essere elaborati, automaticamente viene prelevato il primo pacchetto della coda e trasmesso all interno della pipe; a questo punto il primo file descriptor della pipe presenterà dati pronti per essere letti ed andrà a sbloccare la select() che gestisce la notifica degli eventi alla Session. Questo passaggio attraverso la pipe ci permette inoltre di mettere in pausa l elaborazione dei pacchetti UDP, per permettere la corretta comunicazione col MT, vista anche la lentezza del canale di comunicazione seriale. Infatti nella definizione dell interfaccia State, viene anche implementato il metodo enableudpbuffer() che ritorna sempre true e vincoliamo a questo valore di ritorno la possibilità che la pipe possa essere o meno inserita fra i file descriptor che permettono di sbloccare la select(). Negli stati di transizione, dove il software deve aspettare la risposta dal MT, questo metodo viene sovrascritto in modo che ritorni false, disabilitando così il passaggio dei dati dalla pipe

137 120 Capitolo 2. TWNET: Tetra Wireless NETwork alla macchina a stati ma permettendo comunque l inserimento di nuove PDU all interno del buffer (entro i limiti di ampiezza dello stesso). Figura 2.32: Passaggio dei dati in ingresso lato rete multihop 2.3 Risultati L attività svolta all interno del progetto di collaborazione con Selex-Comms ha portato quindi all integrazione del sistema di telecomunicazioni professionali Tetra DMO con una rete wireless multihop: è stato identificato un metodo per importare all interno di una rete IP le segnalazioni ed i dati provenienti da un isola DMO e un sistema per reinserire tali informazioni in un altra isola. Per permettere ciò è stato inoltre ideato un protocollo di trasmissione dati su UDP per veicolare le informazioni Tetra e permettere le comunicazioni fra i nodi costituenti la rete multihop. Sono stati progettati e creati dei prototipi di Mobile Node unendo le componenti hardware di un terminale Tetra ed un router wireless dotato di sistema operativo GNU/Linux embedded; inoltre per la creazione di questi nodi è stato necessario estendere lo standard ETSI per la comunicazione su seriale tramite PEI e quindi modificare software e firmware dei device Tetra. Infine è stato sviluppato un software in grado di poter gestire la comunicazione tramite le interfacce di rete IP e seriale PEI per interagire con le varie componenti del sistema e tradurre le segnalazioni

138 2.3. Risultati 121 ed i dati ricevuti su di un interfaccia in informazioni valide per l altra, il tutto rispettando importanti vincoli real time dettati dalla necessità di gestire traffico voce. Sono stati prodotti 3 prototipi di Mobile Node ed è stato creato un testbed per validare il nostro approccio e valutarne le funzionalità. La rete di test permette quindi di andare ad analizzare il comportamento delle componenti in un percorso a due hop: è stato studiato il funzionamento dei sistemi DMO puri che non sono in grado di rilevare la presenza della rete TWNET, ma che comunque vengono influenzati dalla sua presenza che inserisce dei ritardi nella propagazione della segnalazione Tetra. Sono stati valutati i vari servizi DMO di: Chiamata individuale senza presence check; Chiamata individuale con presence check; Chiamata di gruppo; Chiamata di emergenza; Chiamata con cifratura di tipo end to end encryption attivata; Chiamata con cifratura di tipo AIE attivata; Chiamata individuale senza presence check in presenza di DM-REPeater; Chiamata individuale con presence check in presenza di DM-REPeater; Chiamata di gruppo in presenza di DM-REPeater; Chiamata di emergenza in presenza di DM-REPeater; Chiamata con cifratura di tipo end to end encryption attivata in presenza di DM-REPeater;

139 122 Capitolo 2. TWNET: Tetra Wireless NETwork Chiamata con cifratura di tipo AIE attivata in presenza di DM-REPeater; Chiamata individuale senza presence check in presenza di DM-GATEway; Chiamata individuale con presence check in presenza di DM-GATEway; Chiamata di gruppo in presenza di DM-GATEway; Chiamata di emergenza in presenza di DM-GATEway; Chiamata con cifratura di tipo end to end encryption attivata in presenza di DM-GATEway; Chiamata con cifratura di tipo AIE attivata in presenza di DM-GATEway; Changeover per tutte le precedenti tipologie di chiamata; Invio di SDS di testo a diversa priorità in tutte le varie configurazioni di rete precedenti; Invio di SDS di stato a diversa priorità in tutte le varie configurazioni di rete precedenti; In tutti questi casi non si sono riscontrate anomalie, i servizi sono stati verificati e testati garantendone la conformità con le specifiche di funzionamento; inoltre i ritardi che la rete inserisce nella propagazione di segnalazioni e dati voce non vanno ad influire sul comportamento del sistema. Infatti non si è mai verificato che uno dei vari contatori, definiti dalle specifiche Tetra DMO, scadesse a causa dei ritardi generati dalla rete IP o dalla comunicazione via seriale causando l impossibilità di usufruire di un servizio. Questa attività di ricerca ha prodotto la pubblicazione di un articolo [15], la proposta di 4 brevetti [16] [17] [18] [19] ed è stato insignito del premio innovazione Selex-Communications 2009.

140 Parte II Testing funzionale per la sicurezza dell implementazione di protocolli di rete

141

142 Capitolo 3 S.T.R.E.S.S. L attività di software testing risulta essere di fondamentale importanza nei processi di sviluppo software proprio perché mira a ridurre il più possibile la presenza di bug all interno del codice, anche se uno dei principali problemi è che nessuna metodologia di testing può dare la certezza matematica di assenza di errori. Il costo economico di questa attività inoltre risulta essere molto oneroso arrivando fino ad equivalere quello dello sviluppo del codice. Si cerca quindi di ridurre il più possibile i tempi ed i costi derivati da questa attività senza però comprometterne il risultato finale, sviluppando metodologie e strumenti in grado di automatizzare il più possibile il processo cercando di diminuire i costi e minimizzando gli errori umani. L obbiettivo di questa parte dello studio di dottorato ha mirato alla creazione di una metodologia di testing ed allo sviluppo di un framework flessibile, generico e dinamico capace di adattarsi ad ambiti diversi e fornire supporto ed automazione in tutte le fasi del processo di testing del software di rete. Vedremo quindi aspetti generici del black box testing, in particolare riguardanti quelli di ricerca delle vulnerabilità e robustness testing, sarà pre- 125

143 126 Capitolo 3. S.T.R.E.S.S. sentata la metodologia che abbiamo sviluppato e la piattaforma con le varie componenti e strumenti che la costituiscono. Infine andremo ad illustrare le prove sul campo che sono state effettuate per presentare i risultati ottenuti. 3.1 Black-Box Testing Ormai l utilizzo del software ha permeato moltissimi se non tutte le infrastrutture della società moderna, computer e le reti di telecomunicazioni permettono di fornire servizi che ormai sono divenuti fondamentali ed indispensabili. La dipendenza che si è venuta a generare rende un eventuale malfunzionamento del software un problema di entità maggiore rispetto al passato. Inoltre la maggiore accessibilità a tali sistemi, non solo permette a più persone di usufruire di un servizio, ma aumenta il rischio che eventuali vulnerabilità possano venir introdotte in qualche software e possano venir sfruttate per attacchi, quindi l attività di testing risulta essere fondamentale per tutte queste componenti, soprattutto per quelle che prevedono una connessione con la rete. Spesso gli errori nel software vengono scoperti e notificati a partire dall uso che ne fanno le utenze, viene segnalato un malfunzionamento ed in seguito si indaga sull origine del fallimento, questo soprattutto nei software proprietari dove non si ha accesso al codice sorgente e quindi non c è alcun mezzo per gli utenti finali di valutare quale sia il livello di sicurezza del software in oggetto. Diventa così necessario sviluppare una metodologia di tipo funzionale che permetta di verificare lo stato dei software utilizzati ed il loro livello di sicurezza senza però avere a disposizione dettagli implementativi come il codice sorgente. Il software testing prevede un attività, non solo in fase di post implementazione, ma anche durante la stesura delle specifiche di funzionamento e nella fase di progettazione, è quindi parte

144 3.1. Black-Box Testing 127 integrante di tutto il processo di sviluppo del software. Una prima grossa distinzione può essere fatta in base alle informazioni ed ai dettagli di cui si è a conoscenza o su cui si vuole basare il processo di testing [20]. Si può quindi parlare di testing funzionale se il sistema da analizzare viene visto come una black box: non si ha conoscenza di alcun dettaglio implementativo e quindi possono essere utilizzate solo le specifiche di funzionamento. L esecuzione dei test prevede di inviare determinati input al sistema per poterne analizzare i comportamenti e valutare la loro attinenza con le specifiche. Un approccio di questo tipo solitamente viene utilizzato quando i dettagli implementativi non sono di libero accesso o quando comunque si ha una conoscenza limitata dell oggetto sotto test, andandosi conseguentemente a basare su ciò che è a disposizione: analisi dei requisiti, specifiche dei protocolli e le definizioni di interfacce. Diversamente, nel testing strutturale, l analisi si basa su dettagli implementativi come il codice sorgente, e viene quindi adottato un approccio di tipo white box. Vi è poi un livello intermedio fra questi due tipi, il grey box testing [21]: in questo approccio si ha una limitata conoscenza della componentistica interna del sistema, per esempio si può avere accesso solo ad una parte del codice sorgente mentre altre componenti sono software proprietario, oppure più semplicemente si ha un accesso ai documenti di design più dettagliati delle specifica dei requisiti. Per quanto riguarda la metodologia di testing è analoga a quella del black box testing, cioè si opera una comunicazione dall esterno con la scatola analizzandone il comportamento per valutare i risultati dei test. Il nostro lavoro si soffermerà principalmente sulla parte di testing funzionale, detto anche black-box testing, ed in particolar modo sull analisi della sicurezza delle implementazioni a partire dalle specifiche di funzionamento.

145 128 Capitolo 3. S.T.R.E.S.S Concetti di base Il testing viene definito come il processo che fa operare un sistema o una componente sotto particolari condizioni, osservando e memorizzando i risultati ed infine valutando alcuni aspetti dell oggetto analizzato alternativamente come il processo di analizzare un software per rilevare le differenze fra il suo funzionamento e ciò che viene descritto nelle specifiche ed infine per valutarne le caratteristiche [22]. Vengono identificate cinque diverse fasi del testing [20] in base agli obiettivi preposti: Fase 0: il testing coincide con l attività di debugging. Fase 1: l obiettivo del testing è verificare il corretto funzionamento del codice. Fase 2: verificare che il software non funziona correttamente. Fase 3: il testing non deve più dimostrare qualcosa, ma deve ridurre il rischio di non funzionamento fino ad un livello accettabile (ovviamente in base alle caratteristiche e allo scopo del software sotto analisi). Fase 4: il testing non è più un attività a sé stante ma un approccio per lo sviluppo del software. Queste fasi in realtà sono i 5 obbiettivi che devono essere tutti soddisfatti dal processo dello sviluppo del software che deve comprendere anche quelle attività necessarie a determinare se il prodotto soddisfa le specifiche e individuare eventuali malfunzionamenti. La IEEE definisce i concetti di errore, guasto e fallimento [22]: il programmatore scrivendo codice può commettere un errore, questo se si manifesta può causare un guasto, che rappresenta un espressione errata o uno

146 3.1. Black-Box Testing 129 stato della memoria non corretto, cioè quello che più comunemente chiamiamo bug. Quando vi è un guasto questo può generare una condizione tale che il software non si comporti in modo coerente con quello che ci si aspetta, cioè non rispetta le sue specifiche di funzionamento e si ha quindi un fallimento. Il processo di testing prevede alcune fasi, la cui automatizzazione può velocizzare ed agevolare il lavoro: come prima cosa devono essere creati i test case, sono l unità base del testing ed hanno lo scopo di valutare certi comportamenti o verificare la realizzazione di una determinata funzionalità del sistema o, come nel nostro caso, valutare la robustezza ad un certo tipo di sollecitazioni. I vari test case possono essere raggruppati in test group ed a loro volta, più gruppi formano una test suite. L obbiettivo del test case prende il nome di test purpose e solitamente i gruppi di test case vengono creati in base ad uno scopo comune che prende il nome di test group objective. Successivamente alla creazione, i test case vengono eseguiti sulla componente sotto analisi, si ha quindi un test run; ad ogni test case possono corrispondere diverse esecuzioni e quindi diversi test run. Durante questa fase il sistema sotto test deve essere monitorato senza però che venga modificato il suo funzionamento o il suo stato; inoltre spesso è necessario sviluppare stub o driver specifici per interfacciarsi col sistema e per eseguire le varie run. Infine si ha il verdetto dell oracolo (oracle verdict): si definisce oracolo il meccanismo che permette di valutare l output del test case con le specifiche ed emettere quindi il verdetto che può essere: pass, fail o inconclusive. Un verdetto di pass significa che in risposta al test case il sistema ha reagito come ci si aspettava e che quindi non manifesta malfunzionamenti; contrariamente se è fail vi sono delle palesi violazioni delle specifiche nell implementazione dell aspetto sotto test e che quindi saranno necessarie ulteriori analisi per comprenderne le cause. Se invece non si è in grado di assegnare uno dei due precedenti

147 130 Capitolo 3. S.T.R.E.S.S. verdetti, definiremo il risultato del test case come inconclusive, e quindi non utile ai nostri scopi. Come detto precedentemente, in caso di verdetto fail, si eseguirà il debug del codice per andare a risalire la catena dell errore, guasto, fallimento, partendo dalla failure generata dal test run per trovare il fault che l ha causato. Livelli di testing Una ulteriore distinzione può esser fatta in base al livello della componente sotto test [20]: Unit testing: la unit è la più piccola parte di software che può essere analizzata, cioè la più piccola porzione di codice che può essere compilata e venir caricata in memoria. Component testing: testing su un aggregato di due o più unit. Integration testing: l integrazione è il processo per il quale si vanno a generare elementi complessi aggregando diversi component; dopo aver controllato i singoli elementi è necessario valutare anche le loro combinazioni. System testing: un sistema è un componente complesso, il testing di sistema riguarda il comportamento dell intero oggetto integrato e quindi si va a controllare la sua conformità rispetto al design dell architettura. Acceptance testing: il software terminato viene controllato per valutarne l attinenza con i requisiti funzionali. Ogni livello di test è associato alle varie fasi di sviluppo software, secondo il modello a V rappresentato in figura 3.1 [23].

148 3.1. Black-Box Testing 131 Figura 3.1: Modello a V del processo di sviluppo software Conformance Testing La ISO in collaborazione con la ITU-T ha sviluppato uno standard per fornire una metodologia per il conformance testing delle implementazioni dei protocolli: è lo standard ISO 9646, OSI conformance testing methodology and framework [24] [25]. Lo scopo del conformance testing [26] [27] è verificare che il comportamento di una implementazione di un protocollo rispetti i requisiti dello stesso, questo permette di validare sia il corretto funzionamento che l interoperabilità fra implementazioni diverse del medesimo protocollo. Questa tipologia di testing utilizza un approccio funzionale, viene valutato solo il comportamento del sistema senza alcun interesse per la sua struttura interna. Questa caratteristica permette quindi di poter riutilizzare le test suite per più implementazioni diverse dello stesso protocollo. Solitamente il processo di conformance testing procede in parallelo con lo

149 132 Capitolo 3. S.T.R.E.S.S. sviluppo dell implementazione del protocollo, infatti entrambi queste procedure prendono come input la stesura delle specifiche: queste vengono utilizzate per la generazione dei test case in maniera indipendente dall implementazione dello standard. Successivamente i test case vengono implementati per andare infine ad essere eseguiti sulla IUT (Implementation Under Test) per ottenere il verdetto sulla conformità della stessa rispetto alle specifiche. Completezza del livello di testing Oltre al problema dell oracolo, un altro elemento estremamente complesso del testing è la completezza. Per definizione il software testing è in grado di dimostrare la presenza di bug, non è in grado invece di dimostrarne l assenza [20]. Infatti nel testing funzionale il numero degli input possibili è infinito, ciò fa capire che è impossibile, sia teoricamente che praticamente, eseguire un testing completo su tutto lo spazio degli ingressi. Quindi l unica possibilità è quella di eseguire un numero limitato di test, cioè eseguire un campionamento degli ingressi per cercare di coprire più tipologie di input possibili Testing per la sicurezza del software Come accennato precedentemente, la diffusione e l uso del software ha coinvolto ogni aspetto della società moderna, dai più frivoli a quelli critici, tanto che un fallimento di questi sistemi può causare conseguenze molto gravi. A peggiorare la situazione è la continua esportazione dei vari servizi su internet migliorandone si l accessibilità ma esponendoli a maggiori rischi di attacchi: chi sviluppa software deve quindi tener conto di questo e assumere che il loro prodotto non verrà usato solo dagli utenti destinatari ma anche da eventuali attaccanti [28].

150 3.1. Black-Box Testing 133 Diventa quindi importante valutare la sicurezza dei sistemi sia per chi produce software, sia per coloro che lo adottano, per avere una valutazione della sicurezza delle proprie strutture IT. La maggior parte delle violazioni della sicurezza dei sistemi informatici vengono causate da errori nel software che vengono sfruttati come vettori di attacco. C è una distinzione da fare su queste vulnerabilità, si può parlare di design vulnerability se deriva da un errore inserito in fase di progettazione del sistema; contrariamente si parla di implementation vulnerability quando vengono inserite in fase di implementazione e quindi derivano da errori di programmazione. Per esempio, anche se un design è privo di errori e quindi il sistema è privo di difetti da un punto di vista di progettazione questo può essere costituito da componenti difettose che vanno quindi a compromettere un impianto teoricamente sicuro. Per quanto riguarda i primi tipi di vulnerabilità, in fase di design si possono produrre modelli formali per dimostrarne la correttezza e la sicurezza, contrariamente all altra tipologia poiché la complessità dell implementazione supera la capacità dell analisi formale; inoltre una maggiore complessità del codice aumenta anche la probabilità che vi siano inseriti errori. Robustness testing La robustezza è una caratteristica fondamentale per le componenti software ed è definita come: la capacità di resistere ad un input anomalo e mirato ad ottenere un comportamento non previsto nelle specifiche. I problemi di robustezza rappresentano anche problemi alla sicurezza del sistema, infatti le vulnerabilità che sono presenti in un software possono essere utilizzate da un attaccante per la sua compromissione, con impatto ovviamente maggiore nei casi di componenti con accesso ad internet. Il testing di robustezza si discosta

151 134 Capitolo 3. S.T.R.E.S.S. dai test tradizionali poiché quest ultimi hanno come obiettivo verificare che il comportamento dell oggetto sotto analisi sia conforme alle specifiche, mentre i test per la robustezza mirano ad analizzare le reazioni ad ingressi anomali ed a valutare la capacità del software di gestire eventuali attacchi con l obiettivo ultimo di cercare le implementation vulnerability. Conseguentemente cambia anche l approccio alla macchina sotto test, infatti non ci interessa solamente se le risposte sono attinenti allo standard ma deve essere valutato se si sono manifestati fallimenti o se le politiche di sicurezza sono state rispettate. Un ulteriore differenza fra questa tipologia di test e quella per la conformità consiste nel numero di test case generati, infatti si passa da un ordine delle centinaia ad un ordine delle migliaia [29] Tecnologie di Black-box testing e stato dell arte Affrontiamo ora una panoramica delle varie metodologie di testing funzionale utilizzate per attuare testing di robustezza, considerando anche che le varie tecniche non sono mai esclusive anzi spesso un particolare approccio può rientrare in più di una di queste categorie. Fuzzing Il termine fuzzing è stato introdotto per la prima volta da Miller [30] creando uno strumento anonimo che eseguiva dei test per la robustezza di applicazioni inviando dati random sulle loro interfacce, per poi valutare la reazione del sistema e se erano presenti vulnerabilità o errori software. Concettualmente la tecnica del fuzzing consiste nell introdurre rumore sulle interfacce interne o esterne fornite da un programma. Successivamente l approccio tramite fuzzing si è evoluto ed ampliato andando a sovrapporsi con altre metodologie come il domain testing, syntax testing e fault injection; nella sua accezione

152 3.1. Black-Box Testing 135 più attinente al termine, il fuzzing consiste in una ricerca alla cieca di problemi nella gestione degli input nei vari programmi, ma questo tipo di approccio risulta molto spesso inadeguato. Per esempio nel caso del test di un server POP3, inviare dati casuali difficilmente permetterà di superare il primo scambio di messaggi, col risultato che soltanto una piccola parte dell implementazione del protocollo verrà controllato, tralasciando gran parte del codice. Quindi, il più delle volte la tecnica del fuzzing totalmente casuale risulterà di scarsa efficacia, per questo motivo vi è stata un evoluzione e sono stati implementati approcci più intelligenti: gli strumenti possono essere specifici di un determinato protocollo da testare e permettono di andare ad inserire dati random in una parte specifica dello scambio di messaggi oppure possono utilizzare un range di dati anomali da inserire invece di affidarsi al generatore random. Questo approccio permette quindi di andare più in profondità nelle macchine a stati del protocollo di fatto sovrapponendosi con la metodologia tipica del syntax testing. Un importante aspetto del fuzzing è il controllo sul trust boundary: cioè quando in un sistema l esecuzione o i dati passano da un trust level ad un altro e quindi vengono cambiate le loro risorse ed i loro permessi. Un esempio di trust boundary che viene attraversato si ha quando i dati ricevuti in rete vengono trasmessi ad un applicazione per il parsing e per l elaborazione. Lo spazio degli input che possono essere inviati al sistema è costituito da tutte le possibili combinazioni di dati ed è ovviamente infinito, quindi per limitarlo è necessario scegliere un subset di valori da utilizzare nei test. Per facilitarne la selezione, vengono usate delle euristiche: le euristiche di attacco sono tecniche finalizzate alla ricerca di specifiche tipologie di bug nelle applicazioni, per esempio se vogliamo cercare errori che causano buffer overflow si inviano input particolarmente lunghi oppure se vogliamo sfruttare errori di format bug si inviano caratteri speciali di controllo all interno degli

153 136 Capitolo 3. S.T.R.E.S.S. input stinghe. I test case vengono quindi generati a partire dallo spazio degli input e da un euristica di attacco, ma come vengono generati dipende dal tipo di fuzzer che viene utilizzato: un generation fuzzer è un programma autonomo che produce delle sessioni semi valide: è in grado di creare le informazioni da inviare in base ad un modello, può essere più semplice e creare dati casuali o più complesso ed utilizzare una rappresentazione del protocollo; un mutation fuzzer preleva una sessione valida, ne muta i dati creando così il test case. I primi tendono ad essere specifici per un particolare standard o applicazione mentre i secondi sono fuzzer generici poiché non hanno bisogno di modelli ma si basano su comunicazioni prelevate precedentemente al test. L azione del fuzzer può essere suddivisa in tre fasi 1. La tokenization: le comunicazioni protocollari vengono suddivise in parti variabili o costanti, le prime sono quelle che saranno oggetto del fuzzing (siano esse interi stringhe o dati binari), mentre le seconde sono la parte costante del protocollo come gli header. 2. Vengono generati in modo manuale o automatico i test case, partendo da un modello del protocollo oppure da traffico precedentemente catturato. Questa fase è importante perché un errore nella generazione dei case può portare l applicazione in esame ad ignorare gran parte del traffico facendo risultare i test inutili. 3. Il traffico generato viene trasformato in traffico malformato in modo da portare alla luce problemi nell implementazione sfruttabili per un

154 3.1. Black-Box Testing 137 eventuale attacco. Questo può essere effettuato in modo banale, semplicemente invertendo il valore di alcuni bit oppure con approcci più sofisticati anche in base al tipo di dato. In questa fase entrano in gioco le euristiche di attacco. Un ulteriore accorgimento deve essere preso perché quando si va a modificare i dati a volte è necessario modificare altre parti del messaggio da inviare per assicurarci che il pacchetto non venga scartato per altri motivi. Ad esempio, nel caso di controlli di checksum o anche più semplicemente nel ricalcolo dei campi della lunghezza. Domain Testing e Syntax Testing Si definiscono gli input domain come intervalli uniformi di valori che possono essere ricevuti in ingresso da un applicazione, valori appartenenti allo stesso dominio probabilmente verranno processati in modo simile. Quindi un domain testing preleva alcuni valori dai vari domini, con attenzione a prelevare almeno un input da tutti i range, per valutare come vengono elaborati dal sistema in esame; i test case dovrebbero concentrarsi particolarmente sui confini dei domini dove è maggiore la probabilità di una errata gestione. Questo tipo di testing viene solitamente utilizzato per verificare il comportamento del sistema in risposta ai valori validi, ma è necessario, al fine dell analisi della sicurezza, integrarlo con l invio di input non validi. Il syntax testing è un altro approccio di testing funzionale, prevede l utilizzo di dati in ingresso che vanno a violare la sintassi del protocollo [20]: l oggetto del nostro test riceve così input con caratteri casuali o elementi inseriti in ordine non previsto o con campi omessi, possono venir utilizzati limitatori non legali e così via. L obiettivo di questa tipologia di test è quello di controllare se gli input vengono controllati in modo robusto dall implementazione del protocollo.

155 138 Capitolo 3. S.T.R.E.S.S. Tutti gli input che vengono passati ad un applicativo sfruttano un interfaccia che questo fornisce, essa può essere un socket di rete ma anche il prompt da riga di comando o variabili di ambiente o qualsiasi altro mezzo di prelievo di dati; ogni interfaccia utilizza un linguaggio secondo il quale un determinato input può risultare legale o meno, questi linguaggi possono essere o nascosti o aperti. Un linguaggio nascosto non viene definito esplicitamente dagli sviluppatori ma è il protocollo intrinseco di un interfaccia che utilizza l applicazione per leggere dei dati che vengono inviati da una componente software all altra. Un linguaggio aperto invece è esplicitamente specificato dalla documentazione come per esempio un protocollo di rete come POP3 o IP. La base teorica del syntax testing è che ogni interfaccia ha associato un linguaggio, aperto o nascosto che sia, la cui implementazione può essere analizzata con uno sforzo relativamente limitato [31]. Per automatizzare la generazione dei test case per questo tipo di testing è necessario fornire un modello del linguaggio di input che può essere utilizzato dalla macchina: un esempio di grammatica formale per la definizione di una specifica è il BNF (Backus-Naur form) o le espressioni regolari [32]: entrambe queste notazioni definiscono dei linguaggi liberi dal contesto. Una frase di un linguaggio è una sequenza di simboli inseriti secondo delle regole sintattiche, i linguaggi liberi dal contesto vengono utilizzati per definire tali regole e per verificare se un espressione è sintatticamente corretta per quel linguaggio; questi particolari linguaggi vengono utilizzati per esempio nei parser per validare le espressioni in ingresso. Nel testing possiamo utilizzare tali linguaggi descrittivi per creare delle sequenze da mandare in input al sistema sotto analisi per valutarne il comportamento. La generazione dei test case può inizialmente produrre delle sequenze contenenti solo un errore, cioè un punto in cui non vengono rispettate le regole del linguaggio, per poi successivamente

156 3.1. Black-Box Testing 139 inserire doppi errori, tripli e così via; quindi il numero dei test case prodotti aumenterà esponenzialmente al numero degli errori che verranno introdotti. Possiamo poi introdurre vari tipologie di errori: Errori di sintassi: violazioni della grammatica del linguaggio, vengono creati rimuovendo un elemento, aggiungendone uno non previsto o inserendoli in ordine scorretto. Delimiter error: i delimitatori rappresentano la separazione fra diversi campi della sequenza; nei linguaggi human readable, codificati in ASCII, i campi vengono sperati o da spazi (space o tab) oppure da simboli di delimitazione come virgole o punto e virgola. Per introdurre questo tipo di errore si può rimuovere uno di questi simboli o inserirlo più volte o sostituirlo con un altro analogo. Nel caso di limitatori che vengono usati a coppie come le parentesi possono essere inseriti in modo non bilanciato. Field-value error: solitamente il valore di un campo risulta valido quando rientra in un certo intervallo, si possono quindi introdurre valori errati fuori dagli intervalli di validità. Context-dependent error: violano delle regole che definiscono i valori che possono essere assunti dai campi in base al contesto, sono proprietà che non possono essere descritte dale grammatiche libere dal contesto. State dependency error: non tutte le espressioni sono valide ma dipendono dallo stato in cui si trova il sistema: errori di questo tipo consistono nell inviare un espressione non valida nello stato in cui si trova in quel momento.

157 140 Capitolo 3. S.T.R.E.S.S. Solitamente è possibile automatizzare il processi di creazione delle sequenze corrette, per poi andare ad inserire gli errori per generare i test case. I tool di test che implementano questa tipologia di approccio possono permettere la definizione di una specifica della sintassi, per creare la test suite in modo automatico. Questa fase di generazione automatica può essere molto complessa perché può avvenire che le informazioni da inviare all interfaccia siano miste: per esempio una richiesta HTTP può avere al suo interno script SQL o Javascript. Proprio questa caratteristica di alcuni protocolli causa vulnerabilità di tipo injection, per esempio la possibilità da parte dell utente di inserire dati in alcune posizioni come una query SQL all interno di una URI. Un ulteriore esempio di vulnerabilità causata da una injection che può essere rivelata dal syntax test è il cross-site scripting (XSS) [33]: questo tipo di attacco prevede l inserimento da parte dell attaccante di codice all interno della pagina web in modo che venga successivamente eseguito sulla macchina delle vittime. In questo caso il codice inserito viene interpretato dal client della vittima, ma la vulnerabilità è nel server che ha permesso l injection di codice per la mancanza di un corretto controllo dell input (la URI è un input per i server web). Exploratory Testing Quando parliamo di test per la sicurezza a volte può essere utile procedere a vista senza avere aspettative sull esito delle risposte. Questo perché il tester può rivelare anomalie nel comportamento o spostare l attenzione su particolari elementi del sistema da analizzare più approfonditamente con un approccio più standard. Questo tipo di metodologia di testing è sensibilmente differente rispetto alle precedenti, solitamente infatti quando si procede con l esecuzione dei test si hanno informazioni precise sul tipo di risposta atte-

158 3.1. Black-Box Testing 141 sa. Però può essere utile procedere con l analisi senza pattern predefiniti, facendo in modo che il passo successivo venga guidato da quello precedente. Quindi il tester esplora il comportamento dell oggetto sotto test: soprattutto quando viene rivelata un anomalia è utile indagare tramite nuovi test case. La maggior parte delle tecniche di testing possono essere usate per questo tipo di approccio, ma alcune si prestano particolarmente, come per esempio il fuzzing (capitolo 3.1.3), e generalmente vengono utilizzate quando è difficile dire quali siano le anomalie che possono presentarsi nel comportamento del sistema. Ovviamente il limite maggiore per un approccio del genere è la mancanza di una metodologia vera e propria, di fatto non si tratta di un vero e proprio sistema di testing: la sua esecuzione non può essere oggetto di pianificazione e risulta profondamente dipendente dall esperienza del utente che ne guida l avanzamento. Penetration Test Un particolare approccio che può essere classificato come exploratory testing è il penetration testing: si parla di una metodologia per ricercare le vulnerabilità all interno di un software o di una infrastruttura per successivamente sfruttarla ed attaccare effettivamente il sistema, simulando un attacco reale. Durante questo tipo di procedura, il tester può ricercare nel sistema delle vulnerabilità conosciute per poterle sfruttare, tale ricerca può avvenire in modo manuale o automatico: nel secondo caso vi sono tool specifici (security scanner) che aiutano l operatore andando a cercare eventuali problematiche appoggiandosi ad un database contenente le vulnerabilità segnalate in passato. Inoltre spesso si possono creare input potenzialmente dannosi da inviare al sistema, anche in questo caso aiutati da tool automatici.

159 142 Capitolo 3. S.T.R.E.S.S. Stress Testing L obiettivo di questo metodo di testing è valutare il comportamento del sistema quando è sottoposto ad un pesante carico di richieste, per esempio possono essere fatte richieste multiple o molto complesse o trasferimenti ingenti di dati; quindi si cerca di creare delle condizioni estreme per simulare particolari eventi quali risorse esaurite o guasti hardware. Come prima cosa durante lo stress test si cerca di evidenziare se l applicazione è in grado di continuare a fornire il servizio e con che livello di qualità, mentre se vogliamo concentrarci su aspetti di sicurezza si cercano di individuare anomalie di tipo diverso; per esempio si cerca di far eseguire le routine per la gestione degli errori per valutarne la correttezza e la robustezza oppure si può cercare di rallentare il sistema per sfruttare problematiche di race condition. Per quanto riguarda il testing della sicurezza questo tipo di approccio si basa sull idea che un attaccante è in grado di riprodurre ogni tipo di situazione, anche la più estrema per riuscire a sfruttare qualche vulnerabilità per compromettere il sistema [21]. Fault Injection Procedura ereditata dal testing applicato a piattaforme hardware, prevede la manomissione volontaria di certe componenti per valutare la resistenza delle altre ad eventuali guasti. Mutuando questo tipo di approccio al testing del software si inseriscono dei guasti volontari all interno della comunicazione o in dati che vengono inviati ad un interfaccia valutandone così il comportamento. Visto che in una filosofia black box non possiamo andare a modificare componenti interne del codice, necessariamente l inserimento del guasto deve avvenire su un interfaccia esterna, come nel nostro caso per analizzare le implementazioni di protocolli di rete. Questa metodologia può essere utilizzata

160 3.1. Black-Box Testing 143 sia per eseguire stress test che per valutare la robustezza del software ad anomalie nelle comunicazioni di rete, ma anche per esempio per un syntax testing. Monitoring Una componente fondamentale di tutte queste procedure è la capacità di osservare il comportamento della componente sotto analisi per valutare il risultato dei vari test case. Questo è ancora più difficile nel testing per la sicurezza di un sistema poiché, a differenza del conformance testing, non ci si può basare esclusivamente sui messaggi di risposta o sull assenza di essi; devono essere valutati anche altri aspetti che possono essere sintomi di una vulnerabilità anche in presenza di risposte corrette secondo lo standard. Infatti, là dove possibile, in un approccio black box, si deve cercare di monitorare parametri spesso invisibili al normale utente, tipo l utilizzo delle risorse del sistema o il proliferare di processi figli. Automatizzare questo aspetto del testing può essere estremamente utile soprattutto quando vengono utilizzati approcci come il fuzzing che operano con alti volumi di dati procedendo alla cieca Stato dell arte degli strumenti esistenti Come accennato precedentemente, l attività di software testing è molto onerosa, la stima ci dice che il 50% dei costi dello sviluppo vengono assorbiti da questa attività, costi che aumentano nel caso di applicazioni critiche [34]. Ovviamente lo sviluppo di strumenti automatici per il testing può permettere un agevolazione del lavoro da parte del tester, velocizzandone l attività. Vi sono vari tipi di strumenti che variano per la generalità e per il grado di automazione: ce ne sono di disponibili sia specifici per un singolo protocollo

161 144 Capitolo 3. S.T.R.E.S.S. che sotto forma di framework, o librerie per dare supporto per lo sviluppo di applicativi veri e propri. Andiamo a presentare alcuni di questi strumenti, prevalentemente non specifici ma che possono essere usati per più protocolli. I progetti PROTOS e PROTOS protocol genome Il progetto PRO- TOS [29] nasce nel 1999 come collaborazione fra la VTT Electronics e l Università di Oulu, come attività di ricerca per valutare differenti approcci al testing funzionale di protocolli, con particolare attenzione alla robustezza del software. Viene sviluppato un metodo che prevede la produzione di un gran numero di test case con l inserimento all interno di un pacchetto di uno o due elementi modificati mentre le restanti parti risultano intatte e quindi valide. Per prima cosa viene scritto un modello formale del linguaggio dell interfaccia da analizzare tramite l utilizzo di una grammatica libera dal contesto (BNF); successivamente questa specifica viene semplificata ed arricchita tramite regole che aggiungono elementi semantici alla specifica del linguaggio. Una volta creato il modello di base vengono prodotti alcuni test case senza l inserimento di componenti eccezionali per validare la rappresentazione prodotta dello standard e, solo successivamente, si andrà a stilare manualmente una lista di anomalie che verranno inserite all interno dei pacchetti durante la generazione automatica dei vari test case. Infine si andrà ad eseguire i vari test sull implementazione sotto analisi. Va fatta una considerazione, una volta generati i test case, nel caso si voglia andare ad aggiungere delle anomalie, sarà necessario riavviare da principio la fase automatica per la loro generazione. Questo metodologia permette senza problemi di andare a testare protocolli stateless, mentre per quelli stateful i test in BNF devono essere valutati in modo da poter raggiungere lo stato da analizzare e poi inserire le anomalie. La fase successiva ai test di analisi dei risul-

162 3.1. Black-Box Testing 145 tati si basa sui log prodotti. Per le caratteristiche di questo approccio viene prevalentemente utilizzato per applicazioni di tipo client server con protocolli request-response, fra gli altri LDAP, SNMP, H.323 e SIP [35]. PROTOS Protocol Genome Come evoluzione di PROTOS nel 2003 nasce il progetto PROTOS Protocol Genome con lo scopo di creare una serie di strumenti per produrre automaticamente i test case partendo da dati validi per aiutare e completare la fase di creazione manuale dei test. L idea alla base di questo progetto consiste nell identificare dei blocchi strutturali che solitamente vengono usati nei vari protocolli, che quindi possono contenere tipi di vulnerabilità simili, anche in diverse implementazioni di differenti protocolli. Questi blocchi prendono il nome di protocol gene [36]. La metodologia di generazione automatica dei test case prende il nome di model inference assisted fuzzing e prevede l analisi di un certo quantitativo di dati di training di traffico valido da utilizzare come modello per la produzione dei frame per il testing di robustezza. Questo approccio rappresenta una via di mezzo fra il design manuale e un fuzzing completamente casuale. Una sostanziale differenza rispetto al progetto originario è che questa metodologia non viene applicata solamente a protocolli di rete ma a tutta una serie di linguaggi implementati da varie interfacce e quindi da applicativi diversi; per esempio è stato utilizzato per valutare come gli antivirus trattavano formati di compressione file differenti. Partendo da data set di training costituiti da alcuni file compressi con un certo algoritmo, è stato prodotto un modello per ogni formato e da questo una gran quantità di file modificati da far analizzare ai vari antivirus. Gli autori hanno evidenziato un limite in questo approccio; vi è nel modello una mancanza di conoscenza sul dominio, manca cioè ogni tipo di significato semantico dei dati.

163 146 Capitolo 3. S.T.R.E.S.S. Codenomicon Defensic Da una spin-off del progetto PROTOS, Codenomicon, nasce un software commerciale denominato Defensic che prevede una serie di strumenti per eseguire testing di robustezza, ognuno dei quali è specifico per un singolo protocollo. Applicativi per il fuzzing All interno del fuzzing rientrano un gran numero di strumenti, ognuno specifico per un certo formato di file o per un protocollo di rete, che possono essere utilizzati per analizzare ogni tipo di applicazione che implementa tale linguaggio. Inoltre vi sono fuzzer più semplici che effettuano delle mutazioni partendo da dati validi, e che quindi possono essere utilizzati con più protocolli differenti. Infine vi sono i fuzzing framework che forniscono un ambiente per gli sviluppatori di fuzzer per fornire maggiore flessibilità e permettere di produrre strumenti per protocolli proprietari o non ancora testati [37], fornendo delle API per velocizzare o astrarre alcune procedure quali: assistenza nella creazione del modello del linguaggio, per esempio un programma di conversione che prende in input del traffico di rete traducendoli in un formato leggibile dal framework; ricalcolo automatico della lunghezza dei campi di un pacchetto in modo da poter modificare dei dati ma automaticamente mantenere coerente e valido il frame; calcolo dei checksum; metodo per generare dati random; fornire alcune euristiche d attacco; fornire strumenti per rilevare la presenza di guasti nel software;

164 3.1. Black-Box Testing 147 strumenti e convenzioni per lo sviluppo degli strumenti permettendone la riusabilità per progetti futuri e garantendone l evoluzione. SPIKE Sviluppato da Dave Aitel, SPIKE [38], è un fuzzing framework scritto in C che fornisce una serie di API per lo sviluppo di fuzzer per protocolli di rete, include delle primitive molto frequenti nei vari protocolli e include anche alcuni moduli per i quelli più usati. Utilizza un approccio block-based [39], la sintassi del protocollo viene divisa in blocchi di dati che successivamente vengono mutati. Questi blocchi vengono definiti tramite strutture denominate spike (da questo il nome del framework) che contengono sia i dati binari che la loro lunghezza. Per utilizzarlo è necessario catturare traffico valido ed immetterlo nel framework andando a definire i vari campi usando le sue librerie, andando così a creare i vari blocchi; dopodiché i blocchi vengono mutati con valori casuali o con valori presi da set di stringhe o interi (euristiche d attacco). Il difetto di questo progetto è la mancanza di documentazione e dell organizzazione dei moduli distribuiti, ogni piccolo cambiamento, anche l aggiunta di una stringa in un euristica richiede la ricompilazione dell intero pacchetto ed infine manca di strumenti che facilitino la riusabilità delle componenti realizzate. Riscritto in Python è stato integrato nel framework per penetration test CANVAS. Peach Peach è un framework multi piattaforma scritto in Python sotto licenza MIT, permette la definizione dei dati da sottoporre al fuzzing tramite XML, ed è in grado di modellare: informazioni sui tipi; relazioni fra i campi come dimensioni o contatori; checksum;

165 148 Capitolo 3. S.T.R.E.S.S. trasformazioni di dati come la compressione; modellazione basi di una macchina a stati. Questo framwork è in grado di produrre i test case sia tramite generazione che mutazione. GPF: General Purpose Fuzzer GPF [40] è un tool opensource per piattaforme Unix, progettato come fuzzer generico può essere utilizzato sia come fuzzer casuale, ma può anche effettuare mutazioni di dati empirici o modellare manualmente un protocollo, tramite file scritti in C denominati tokaids. L utilizzo di questo framwork è molto complesso: infatti la modellazione degli standard usando i tokaids non è semplice [37]. É stato integrato nel progetto Evolutionary Fuzzing System che si prefissa di utilizzare algoritmi genetici per produrre gli input da inviare alle componenti software. Si basa sull utilizzo di sessioni di dati semi valide che vengono inviate alla componente monitorata con un debugger (in questo caso si può parlare di grey testing); i risultati vengono inseriti in un database e tramite un algoritmo genetico si cercano di modificare le sessioni facendole evolvere per le interazioni successive. Autodafè Un framework fuzzing sviluppato sotto GPL per piattaforma Unix [41] utilizza un approccio basato su strutture a blocchi; si prefissa come scopo principale quello di ridurre le dimensioni dello spazio di fuzzing, andando a modificare quelle aree del pacchetti che possono portare con maggior probabilità alla scoperta di vulnerabilità. I blocchi sono i marker che vanno a definire un certo dato del pacchetto, associandogli un peso che servirà per generare una scala di priorità con cui verranno processati i vari campi. Anche in questo framework possiamo parlare di grey testing, poiché

166 3.2. Sviluppo piattaforma S.T.R.E.S.S. 149 integra un debugger che va a monitorare le chiamate alle API che vengono ritenute pericolose come fprintf() e che utilizzano delle stringhe generate dal framework. Sulley Un altro framework scritto in Python utilizzato per sviluppo di fuzzer e costituito da vari componenti estendibili. La maggior parte dei fuzzer si concentrano sulle modalità di generazione dei dati, sulley invece si concentra anche sulla parte di invio dei dati e sul monitoraggio del target [37]. Inoltre vengono affrontate le problematiche inerenti allo sviluppo di modelli per protocolli stateful: raccogliendo le varie richieste da inviare ad un target viene creato un grafo che successivamente verrà esplorato per analizzare i vari percorsi interni. Sulley è l unico framework che cerca di affrontare in maniera differente la problematica degli stati in cui può trovarsi la IUT, solitamente infatti vengono mandati messaggi in sequenza senza tener conto dello stato attuale. Conseguentemente la maggior parte dei fuzzer vanno a testare solo una parte dell implementazione del protocollo, quella più superficiale, senza considerare gli stati più nascosti. 3.2 Sviluppo piattaforma S.T.R.E.S.S. Abbiamo presentato diverse soluzioni che vengono fornite per agevolare l attività di testing funzionale, sia come supporto che come automazione; lo scopo dell attività di questo dottorato di ricerca è quella di studiare una metodologia di testing funzionale per la robustezza delle implementazioni di protocolli di rete tramite un approccio di fault injection e sviluppare una piattaforma per la generazione automatica dei test case, la loro esecuzione e l analisi del comportamento dell oggetto sotto analisi. L idea alla base della nostra piattaforma rientra nell intersezione fra syntax testing e fuzzing,

167 150 Capitolo 3. S.T.R.E.S.S. quindi si cerca di valutare le reazioni delle componenti in risposta a guasti inviati in input, ma nonostante tutto la flessibilità del framwork ci permette di utilizzarlo anche per valutare la conformità delle IUT alle specifiche dei vari protocolli. Inoltre gli standard, che possono essere oggetti dello studio, sono dislocati in differenti livelli della pila ISO/OSI permettendo quindi un analisi sia a basso livello che a livello delle applicazioni utente. I software sviluppati possono essere utilizzati come supporto per attività quali stress test, testing di esplorazione. Infine, le particolari caratteristiche di espandibilità e di analisi del comportamento agevola anche attività di reverse engineering per la ricostruzione del funzionamento di implementazioni proprietarie [42]. S.T.R.E.S.S. è stato ideato per lavorare con software di rete ma non è vincolato a nessun protocollo, infatti è in grado di riprodurre un qualsiasi linguaggio, previa sua definizione formale tramite linguaggio libero dal contesto. Nel nostro caso abbiamo scelto di utilizzare l Augumented Backus- Naur Form (ABNF) [43], una versione modificata del BNF, definita nel RFC 5234, espressamente ideata per la definizione di specifiche di protocolli di rete. Il funzionamento del framework è schematizzato in figura 3.2, l utente fornisce un modello del protocollo in ABNF, questo modello viene utilizzato per creare in memoria il motore dei test case, la piattaforma inserisce automaticamente delle anomalie secondo un euristica di attacco ed inizia l esecuzione dei test. Durante i test run viene monitorato l apparato o il software oggetto dell analisi per poi produrre degli output in vari formati (per esempio in XML) contenenti sia i messaggi scambiati sia le informazioni prelevate dai sensori di monitoring. Inoltre stiamo tutt ora lavorando sulla parte di post processing degli output per la rilevazione automatica dell esito dei test case. La parte principale del framework è stata sviluppata in C/C++ per poter operare agevolmente anche a basso livello, mentre altri componenti come il

168 3.2. Sviluppo piattaforma S.T.R.E.S.S. 151 parser dell output per fini statistici, editor di file ABNF e GUI sono state sviluppate usando il linguaggio Ruby. Figura 3.2: Schema del funzionamento della piattaforma S.T.R.E.S.S Generalità dei protocolli utilizzabili Uno delle feature principali del framework è l assoluta generalità del suo utilizzo, la possibilità di eseguire test su diversi protocolli anche indipendentemente dal layer della pila ISO/OSI. Si è quindi resa necessaria la creazione

169 152 Capitolo 3. S.T.R.E.S.S. di un sistema per rappresentare un linguaggio comprensibile alla piattaforma che le permetta di parlare e comunicare in modo corretto seguendo tale sintassi. Dopo l analisi di varie soluzioni tipo ASN.1 o SDL si è deciso di adottare una grammatica libera dal contesto, cioè una meta sintassi dove ogni regola sintattica viene espressa tramite una derivazione, cioè un equivalenza fra un simbolo non terminale a sinistra di un simbolo di uguaglianza e uno o più simboli terminali o non a destra. Formalmente può essere definita come una quadrupla: G =< N, Σ, P, S > dove N è un insieme finito di simboli non terminali Σ è un insieme finito di simboli terminali P è un insieme di regole di derivazione S N è un elemento dei simboli non terminali e costituisce il simbolo di partenza. Gli elementi di P sono nella forma N = (Σ N) Le regole di derivazione trasformano una stringa composta da alcuni simboli terminali e altri non terminali in un altra stringa e così via fino ad ottenere una stringa di soli simboli terminali. Quindi un linguaggio descritto da una grammatica di questo tipo è tutto l insieme di stringhe costituite da simboli appartenenti a Σ che possono essere derivati con una sequenza di passaggi di riscrittura, partendo dal simbolo di partenza S. Linguaggio di definizione dei protocolli: ABNF Fra le possibili grammatiche libere dal contesto ve ne è una, derivata dal BNF, specifica per rappresentare protocolli di rete bidirezionali, standardiz-

170 3.2. Sviluppo piattaforma S.T.R.E.S.S. 153 zata dall IETF definita nel RFC 5234 [43]. Una specifica in ABNF è costituita da un insieme di regole (chiamate nella specifica rule) costituite da: rulename = elements rulename N elements (Σ N) dove rulename è il nome della regola e gli elements sono uno o più simboli terminali o non terminali. I simboli appartenenti all insieme Σ possono essere o stringhe o valori numerici: le stringhe vengono definite fra virgolette mentre i valori numerici avranno una notazione specifica: saranno indicati dal simbolo % seguito da una lettera che rappresenta la base con cui viene rappresentato il valore: %d rappresenta base decimale quindi il numero 34 sarà espresso dal simbolo %d34 %x rappresenta base esadecimale quindi il numero 10 sarà espresso dal simbolo %x0a o %xa %b rappresenta base binaria quindi il numero 9 sarà espresso dal simbolo %b101 o %b0101 o Fra i simboli che possono essere introdotti nel lato destro delle regole vi sono alcuni operatori che permettono di combinare gli altri elementi presenti alla destra dell uguaglianza: l operatore di concatenazione permette di definire una serie di elementi che, in fase di lettura, produrranno un simbolo terminale formato dalla loro successione. Per esempio la seguente definizione:

171 154 Capitolo 3. S.T.R.E.S.S. elemento1 = Ciao elemento2 = elemento3 = mondo saluto = elemento1 elemento2 elemento3 Produrrà la stringa Ciao mondo che corrisponde alla regola saluto. L altro operatore di alternativa è il simbolo / che separa i possibili valori di sostituzione: saluto = ciao / mondo In questo caso la regola saluto può corrispondere sia alla stringa ciao che alla stringa mondo. Inoltre vi sono altri tipi di operatori per indicare intervalli di valori, ripetizioni di elementi, sequenza opzionali o gruppi di elementi. Il modello del protocollo viene quindi creato tramite una serie di regole di conversione, queste andranno a costruire una struttura ad albero, dove la radice rappresenta il simbolo iniziale S N, ogni nodo dell albero sarà rappresentato da un elemento non terminale dell ABNF, mentre le foglie saranno gli elementi terminali. Per riprodurre la stringa valida per il linguaggio modellato si deve percorrere l albero in profondità da sinistra verso destra (in figura 3.3 un esempio con riferimento all albero ABNF descritto precedentemente). Per definire quindi uno scambio di pacchetti secondo un linguaggio si vanno a creare delle regole di derivazione con la descrizione dei contenuti dei pacchetti previsti dallo standard, per esempio nel caso del protocollo POP3 [44] la fase di connessione ed autenticazione prevede inizialmente la ricezione del banner del server, poi l invio di un pacchetto contenente il nome utente, e successivamente un secondo con la password; in risposta il

172 3.2. Sviluppo piattaforma S.T.R.E.S.S. 155 Figura 3.3: Creazione dei messaggi utilizzando l albero ABNF server dovrà inviare degli acknowledge ed alla fine della procedura, l esito dell autenticazione. Tale scambio di pacchetti può essere definito con: protocollo_pop3 = connect autenticazione connect = <%TCP_read%> descrizione descrizione = "+OK Dovecot ready." %x0d0a autenticazione = login read_ok password read_ok_login login = <%TCP_send%> User guest %x0d0a read_ok = <%TCP_read%> +OK %x0d0a password = <%TCP_send%> Pass guest %x0d0a read_ok_login = <%TCP_read%> +OK Logged in. %x0d0a I simboli terminali fra parentesi angolari < e > rappresentano le istruzioni per l invio e la ricezione dei pacchetti e verranno illustrati più approfonditamente nella sezione Quindi percorrendo l albero del protcollo POP3 (figura 3.4) otterremo: <%TCP_read%> "+OK Dovecot ready." %x0d0a <%TCP_send%> User guest %x0d0a

173 156 Capitolo 3. S.T.R.E.S.S. <%TCP_read%> +OK %x0d0a <%TCP_send%> Pass guest %x0d0a <%TCP_read%> +OK Logged in. %x0d0a che corrisponde allo scambio di messaggi fra un client ed un server che implementano tale standard per l accesso remoto alle caselle di posta elettronica. Figura 3.4: Modello ABNF del protocollo POP3: creazione di traffico valido L esempio preso in considerazione è piuttosto semplice e rappresenta lo scambio di un numero limitato di pacchetti; attraverso le definizioni in ABNF siamo in grado di rappresentare modelli molto più complessi. L operatore di alternativa rappresenta la possibilità di avere due o più possibili scelte e quindi avremo due o più possibili sequenze di messaggi rappresentati dal nostro modello. Questo operatore viene utilizzato nell ambito del nostro framework per inserire delle anomalie: partendo dal modello del protocollo si vanno ad immettere dei valori dei campi errati o non previsti, come alternativa ai dati corretti andando così a creare situazioni non previste dallo standard per valutare la robustezza della IUT (l esempio in figura 3.5 prevede l inserimento di alcune guasti rappresentati dall elemento Anomalies nella richiesta di login).

174 3.2. Sviluppo piattaforma S.T.R.E.S.S. 157 Figura 3.5: Esempio di inserimento di anomalie all interno del modello ABNF Estensione del linguaggio per l uso nella piattaforma di testing Abbiamo visto che la potenza espressiva dell ABNF è in grado di descrivere un protocollo di rete, ma, per poterlo utilizzare per la creazione dei test suite per il framework, è stata inserita la possibilità di immettere dei comandi: delle azioni che la piattaforma S.T.R.E.S.S. elabora durante l esecuzione dei test case. Quindi per aggiungere questi comandi è stata utilizzata la sintassi dell ABNF in modo da includere tali azioni nel modello stesso del protocollo, ma non andando a modificare in alcun modo le specifiche del metalinguaggio: secondo lo standard, fra i simboli terminali sono previsti alcuni elementi racchiusi dalle parentesi angolari < e >, che vengono utilizzati per inserire delle descrizioni testuali; in questo caso vengono utilizzate per istruire la piattaforma sulle azioni da compiere o sulle eventuali elaborazioni da effettuare. La sintassi utilizzata prevede che il primo simbolo della regola di derivazione sia quello del comando seguito da eventuali argomenti: nodo_comando = <%comando%> argomento1 argomento2... argomenton In questo modo, quando viene percorso l albero ABNF il primo nodo terminale che viene letto sarà quello del comando e quindi permetterà di continuare l esplorazione utilizzando i nodi fratelli come argomenti. Come verrà illus-

175 158 Capitolo 3. S.T.R.E.S.S. trato nella sezione 3.2.2, il framework è stato pensato per permettere una facile espandibilità ed agile implementazione di nuove azioni. Comandi per la comunicazione Fra le azioni sviluppate, quelle di fondamentale importanza sono le istruzioni per l invio e la ricezione dei pacchetti di rete, indispensabili per l esecuzione dei vari test case che vengono generati. Attualmente sono state implementate: < %T CP send% > e < %T CP read% > invio e ricezione di un pacchetto di tipo TCP, all inizio di un test case il framework si occuperà di instaurare automaticamente la connessione TCP con la IUT ed al termine si disconnetterà chiudendo la socket di comunicazione; < %UDP send% > e < %UDP read% > invio e ricezione di un pacchetto di tipo UDP; < %RAW send% > e < %RAW read% > invio e ricezione di un pacchetto a livello collegamento dati (livello 2 della pila ISO/OSI). Comandi di comunicazione di rete che utilizzano diversi protocolli a livello trasporto o socket a diversa profondità della pila ISO/OSI permettono di garantire la generalità della descrizione di protocolli utilizzando il linguaggio ABNF. Infatti, in protocolli di alto livello, viene demandata la costruzione dei pacchetti dei layer più bassi al sistema dei socket del sistema operativo, altrimenti può essere creato il modello degli incapsulamenti, andando così ad utilizzare i vari standard protocollari permettendo l analisi delle IUT dei vari livelli ISO/OSI. Quindi il comando < %T CP send% >, visto precedentemente nel modello dello standard POP3, permette l invio di un pacchetto su una socket TCP (senza quindi definirne l header dei livelli inferiori): il

176 3.2. Sviluppo piattaforma S.T.R.E.S.S. 159 pacchetto da inviare viene definito dalla concatenazione di simboli a destra del comando di invio: login = <%TCP_send%> User guest %x0d0a piloterà la piattaforma per inviare un pacchetto TCP contenente la stringa User guest con alla fine il terminatore cr-nl. Figura 3.6: Esempio di pacchetto di login inviato durante una sessione valida del protocollo POP3 Invece il comando < %T CP read% > pilota il framework perché si metta in ascolto sulla socket TCP in attesa di pacchetti in arrivo: alla ricezione il contenuto viene memorizzato e successivamente vengono eseguiti i nodi rappresentati dai simboli alla destra del comando di lettura. <%TCP_read%> +OK %x0d0a In questo caso non sono presenti ulteriori azioni da eseguire sui dati ma, nei log in output al test case, verrà associate al messaggio ricevuto le informazioni

177 160 Capitolo 3. S.T.R.E.S.S. attese ( +OK %x0d0a) utili per un analisi successiva. Sono stati inoltre implementati alcuni comandi (capitolo 3.2.1) per permettere un controllo al momento della ricezione e quindi valutare se il messaggio ricevuto è quello atteso o si continuerà a rimanere in ascolto fino alla ricezione del frame o fino alla scadenza del timeout. Il funzionamento dei comandi per UDP e RAW è analogo a quelli appena presentati, l unica differenza riguarda l invio e la ricezione tramite il socket RAW, oltre ad avere la necessità di avviare il framework con permessi di amministratore, la definizione del pacchetto risulterà diversa e poiché è necessario andare a definire un frame di contenuti binari. Comandi di controllo dei dati Come accennato precedentemente, quando si ha un azione di ricezione di un pacchetto, si possono eseguire alcuni controlli per valutare se il frame era quello atteso o meno. Questa possibilità non è particolarmente utile per quanto riguarda la ricezione su socket TCP o UDP ma risulta fondamentale nell utilizzo di quelli RAW: infatti quando si attiva in lettura una socket su un interfaccia di rete di tipo wireless, non riceviamo solamente i frame diretti alla stazione che esegue i test, ma vengono letti i frame di tutte le macchine presenti, i frame di controllo e di gestione del canale, fra cui i beacon. Si è reso quindi indispensabile lo sviluppo di un sistema che ci permetta di filtrare tali informazioni per prelevare ed analizzare solo quelle interessanti al fine dei test. I comandi attualmente implementati sono: < %M askcheck% >: prevede la presenza obbligatoria di due informazioni. La prima deve contenere la maschera per il confronto e la seconda i dati da confrontare; il funzionamento è analogo alle operazioni che vengono eseguite per capire se due indirizzi IP appartengono

178 3.2. Sviluppo piattaforma S.T.R.E.S.S. 161 alla stessa sottorete tramite l uso della netmask. Il framework esegue un and bit a bit fra la maschera ed i dati, poi fra la maschera ed il pacchetto ricevuto e se il risultato è lo stesso il pacchetto supera il controllo. controllo = <%MaskCheck%> mask data mask = %xff data = %x80 Nell esempio viene valutato se il primo byte del pacchetto ha un valore, in esadecimale, uguale ad 80. (nello standard IEEE [45] corrisponde a verificare che il pacchetto ricevuto sia un beacon). < %V aluecheck% >: prevede la presenza obbligatoria di tre informazioni, la prima il byte che indica la posizione della campo del pacchetto da controllare, la seconda la lunghezza del campo, e la terza il valore con cui confrontarlo. controllo = <%ValueCheck%> start size data start = %d0 size = %d4 data = HTTP Nell esempio viene controllato che il pacchetto appena arrivato inizi (byte alla posizione 0) con una stringa di 4 caratteri che deve essere uguale ad HTTP. Comandi di elaborazione dei dati Per rappresentare molti protocolli è necessario prevedere delle direttive per effettuare alcune operazioni sui

179 162 Capitolo 3. S.T.R.E.S.S. dati: per esempio delle funzioni che possano dinamicamente calcolare checksum, codificare e decodificare informazioni, e così via in modo da andare a riprodurre le varie primitive che vengono utilizzate all interno degli standard di rete. Per l utilizzo del framework sono stati implementati i comandi di: < %Base64Encode% >: prevede almeno un informazione che rappresenti i dati di input alla funzione di codifica base64, l azione prevede il prelievo dei dati e la conversione nella stringa base64. encoded = <%Base64Encode%> "prova" < %Base64Decode% >: prevede almeno un informazione che rappresenti la stringa in base64 da decodificare, viene prelevata e convertita nei dati originali. decoded = <%Base64Decode%> "chjvdme=" < %M D5% >: prevede almeno un informazione che contenga l input di cui deve essere calcolato la funzione di hash MD5. encoded = <%MD5%> "prova" < %Sum% >: prevede due o più informazioni che contengano dei valori numerici che verranno sommati, se saranno presenti delle stringhe non convertibili in numero saranno equiparati al valore 0. dieci = <%Sum%> %d5 %d2 %x3 Nell esempio viene sommato il valore in base decimale 5 più 2 più 3 in base esadecimale (che corrisponde a 3 in base decimale) ottenendo il risultato 10.

180 3.2. Sviluppo piattaforma S.T.R.E.S.S. 163 Comandi di memorizzazione Per poter produrre traffico valido secondo molto protocolli, è necessario elaborare molte informazioni che devono essere prelevate dai pacchetti ricevuti precedentemente. Si rende quindi indispensabile un sistema per estrarre delle informazioni al momento della ricezione di un pacchetto e per la loro successiva memorizzazione. Il comando ideato a questo scopo: < %V ariable% >: prevede due modalità di utilizzo, nel caso in cui sia stata precedentemente memorizzata una variabile con il nome indicato oppure viene richiamata per la prima volta per quella variabile. Se deve essere memorizzato un valore il comando prevede tre informazioni che contengano in ordine, una stringa che indichi il nome della variabile, un valore numerico contenente il byte iniziale da cui leggere ed infine un valore numerico contenente la lunghezza delle informazioni da prelevare. var1 = <%Variable%> "NomeVar1" start size start = %d10 size = %d4 In questo esempio si comanda il framework di prelevare dall ultimo pacchetti ricevuto una variabile, di nome NomeVar1 contenente i dati, dal decimo byte per una lunghezza di 4 byte. Se invece è già presente in memoria una variabile con quel nome è necessario introdurre solo la stringa identificativa in modo che il comando ritorni le informazioni in memoria.

181 164 Capitolo 3. S.T.R.E.S.S Componenti principali Per permettere l esecuzione dei test case secondo un protocollo espresso in ABNF dobbiamo rappresentare in memoria l albero prodotto dal meta linguaggio, per far questo è stato scelto di implementare tale struttura dati utilizzando il pattern Composite che permette la realizzazione di un albero costituito da oggetti di tipo diverso ma che possono venir utilizzati in modo uniforme [14]. In particolar modo i vari elementi dell ABNF vengono rappresentati con oggetti differenti corrispondenti al simbolo terminale o non terminale del metalinguaggio: Composite: rappresenta il nodo generico OrComposite: reppresenta l operatore alternativa RepeatComposite: indica l operatore per ripetizioni di un campo Leaf: classe astratta che rappresenta la foglia dell albero e quindi un nodo terminale dell ABNF. Da questa classe ereditano gli oggetti che rappresentano i vari nodi terminali previsti: StringLeaf: rappresenta una stringa HexLeaf: rappresenta un valore numerico in base esadecimale DecLeaf: rappresenta un valore numerico in base decimale BinLeaf: rappresenta un valore numerico in base binaria CommandComposite: è il nodo che corrisponde ad un comando, quindi ai simboli terminali racchiusi fra parentesi angolari Quindi la classe Composite viene creata da un simbolo non terminale dell ABNF, da questa ereditano gli altri oggetti che andranno a sostituire

182 3.2. Sviluppo piattaforma S.T.R.E.S.S. 165 Figura 3.7: Diagramma delle classi del modello ABNF gli eventuali operatori e simboli terminali (figura 3.7). Con riferimento all esempio in figura 3.5 il sotto albero raffigurante l inserimento di anomalie nel pacchetto di login del protocollo POP3 verrà rappresentato in memoria dall albero in figura 3.8. Figura 3.8: Rappresentazione della definizione ABNF del messaggio di login del POP3

183 166 Capitolo 3. S.T.R.E.S.S. Parser ABNF La componente del framework che va a costruire il modello ad albero è il parser ABNF, creato tramite la struttura rappresentata in figura 3.9. La classe ABNFParser costituisce l interfaccia esposta verso il core della piattaforma; se l esecuzione del parsing ha esito positivo allora viene creato l albero ABNF e memorizzato un puntatore all oggetto Composite che ne costituisce la radice. La classe yy::parser è il risultato prodotto da Bison (capitolo 3.2.2), l oggetto ParserDriver è usato per effettuare delle operazioni ausiliarie al parsing: istanzia il parser, apre il file, mantiene in memoria le strutture intermedie. Tale driver riporta al parser eventuali errori e l esito dell analisi del file di input. La creazione dei nodi dell albero è delegata alla classe CompositeFactory. Figura 3.9: Diagramma delle classi della componente Parser Il parser utilizza alcune strutture intermedie per rappresentare i dati durante il processo, in particolare durante l analisi sintattica vengono valutate le

184 3.2. Sviluppo piattaforma S.T.R.E.S.S. 167 Figura 3.10: Diagramma sequenziale della procedura di parsing regole grammaticali che definiscono l ABNF e quindi saranno gestiti i simboli di tale linguaggio (che differiscono dai simboli della grammatica del protocollo che viene definito per mezzo dell ABNF). Infatti i simboli che rappresentano il protocollo definito dal metalinguaggio sono quelli terminali dell ABNF, ma nel processo di creazione dell albero il parser deve valutare anche i simboli non terminali: per questo abbiamo creato la classe Symbol che rappresenta un qualunque simbolo della grammatica di specifica. Figura 3.11: La classe Symbol

185 168 Capitolo 3. S.T.R.E.S.S. A ciascun simbolo terminale corrisponde esattamente un simbolo della grammatica del protocollo e quindi un nodo dell albero ma ad uno non terminale possono corrispondere più simboli della grammatica dello standard, infatti la regola di derivazione generica viene definita: rulename = elements con elements unione di uno o più elementi appartenenti agli insiemi dei simboli terminali e non. Se ci troviamo ad analizzare una riga del tipo: protocollo_pop3 = connect autenticazione possiamo far corrispondere il simbolo protocollo pop3 a rulename ed i due connect ed autenticazione ad elements; quindi all elemento non terminale dell ABNF elements corrispondono due simboli della grammatica che stiamo analizzando. La classe Symbol quindi ha un vettore di Composite in modo da mantenere legata ad i simboli dell ABNF l informazione necessaria per la costruzione dell albero quando si va a ricostruire la struttura di derivazione descritta nel file in input. Quindi per ogni simbolo che il parser incontra, viene creato un oggetto Symbol e, se questo rappresenta una rulename, un valore numerico o un comando, viene richiamata la factory per istanziare l oggetto Composite corrispondente. Alla fine, quando si trova la struttura base della regola, viene creato il sotto albero relativo, la radice corrisponde al nome della regola ed i figli rappresentano gli elementi che la costituiscono. I vari sotto alberi vengono inseriti in una mappa ed indicizzati in base al nome della radice, così che, quando viene richiamato il processo di costruzione dell albero, questo viene ricostruito in modo ricorsivo a partire dalla sua radice: ogni nodo cerca il suo identificativo nella mappa e aggiunge ai suoi figli quelli del sotto albero nella mappa, richiamando poi la costruzione per ognuno di quei nodi inseriti.

186 3.2. Sviluppo piattaforma S.T.R.E.S.S. 169 Successivamente abbiamo creato una serie di controlli da eseguire durante la creazione dell albero, per validare alcune regole semantiche che non potevano essere espresse con una grammatica libera dal contesto: una rule non può essere definita tramite se stessa, cioè il simbolo alla sinistra dell uguale non può essere presente anche a destra; tutti i nodi eccetto la radice devono avere un padre; il controllo viene fatto alla fine della creazione dell albero consultando se tutti i nodi della mappa sono stati richiamati o meno. In caso contrario avremo un errore di unreference symbol; le foglie dell albero devono essere simboli terminali del linguaggio; il controllo viene eseguito dopo la creazione dell albero assicurandoci che tutte le foglie siano rappresentate da classi derivanti dalla classe astratta Leaf. In caso contrario avremo un errore di undefined symbol. Bison e Flex La costruzione di un parser può essere un operazione complicata, esistono però degli strumenti che ne facilitano la creazione. Per il framework S.T.R.E.S.S. è stato adottato GNU Bison [46], utilizzato insieme al generatore di analizzatori lessicali Flex [47]. Bison è un progetto open source dello GNU Project, si tratta di un generatore di parser che converte una grammatica libera dal contesto in un parser per tale linguaggio, producendo codice C/C++. Flex è un generatore di scanner che produce codice C. Per la generazione di un parser per prima cosa è necessario descrivere la grammatica in un formato riconosciuto da Bison e definire l azione che deve essere eseguita quando viene trovata una determinata regola sintattica. Successivamente si deve creare un analizzatore sintattico, tramite Flex, che prenda in input il file di descrizione del modello ABNF, ne estragga i vari elementi

187 170 Capitolo 3. S.T.R.E.S.S. costituenti, definiti token, per poi passarli al parser. La comunicazione dei token dall analizzatore alla componente per la loro interpretazione avviene inserendo delle chiamate esplicite nel suo codice di controllo che richiama anche le funzioni per la gestione degli errori. La grammatiche viene descritta in un file (parser.yy) dove vengono rappresentate le regole sintattiche in un linguaggio BNF, le azioni associate alle varie regole sono porzioni di codice C/C++ che verranno richiamate dal parser ogni volta che una certa regola viene applicata. Analogamente Flex prende le regole lessicali di un linguaggio definite in un file (scanner.ll), descritte tramite espressioni regolari, sono associate ad una eventuale porzione di codice. L utilizzo delle utility bison e flex con questi file producono come output dei file C e C++ che verranno inclusi nella componente del parser. Modularità delle operazioni Abbiamo visto che in memoria la struttura grammaticale dell ABNF viene riprodotta da un albero di oggetti Composite, l utilizzo di questo pattern permette di trattare ogni nodo dell albero come un oggetto uniforme nonostante il differente significato sintattico. L interfaccia esposta dalla classe Composite fornisce l azione runtest() che permette l esecuzione di un test case, ma questa distinzione sintattica non è sufficiente per riprodurre una completa procedura di testing. Infatti se consideriamo i vari comandi che vengono inseriti nella definizione ABNF, questi sono tutti tradotti come oggetti CommandComposite, senza alcun tipo di riferimento al comando effettivo, cioè non viene valutato il valore semantico del simbolo stesso. Per questo è stato necessario ampliare la struttura creata sull ABNF con un sistema per associare a nodi dello stesso tipo delle funzionalità differenti. Quindi è stato incapsulato all interno di una classe le azioni che vengono eseguite durante

188 3.2. Sviluppo piattaforma S.T.R.E.S.S. 171 i test case, in modo da creare un sistema che permettesse di avere delle azioni intercambiabili, facilmente mantenibili ed espandibili. La struttura che è stata creata segue i dettami del pattern Strategy [14]: definisce una classe astratta Action che fornisce un interfaccia unica per tutti gli oggetti, composta da un metodo runaction(composite*) che verrà richiamato dalla runtest() dei nodi dell albero. Al primo metodo vengono delegate tutte le operazioni necessarie per l invio e la ricezione dei pacchetti, l inserimento delle anomalie, le varie funzionalità di elaborazione dati. Le classi che imple- Figura 3.12: Diagramma delle classi previsto secondo il pattern Strategy mentano Action vengono prelevate dalla ActionFactory nella fase successiva al parsing; alla factory viene delegato il riconoscimento delle azioni da istanziare in base al tipo di oggetto richiamante o in base ai suoi nodi figli. In particolare l azione collegata ad un CommandComposite, non deve essere assegnata al nodo rappresentante quel simbolo ABNF, ma a quello padre che dovrà interpretare in maniera differente i risultati delle azioni degli altri nodi figli. Per esempio in figura 3.13 al nodo login verrà associata l azione

189 172 Capitolo 3. S.T.R.E.S.S. TcpSendAction, definita questa dal suo primo nodo figlio, e quindi andrà ad utilizzare gli altri figli per costruire il pacchetto TCP da inviare. Figura 3.13: Esempio: come vengono associate le classi del pattern Strategy Nel dettaglio, ogni comando è identificato da una stringa che rappresenta il simbolo terminale che viene indicata nel file ABNF, quindi tale stringa determina il tipo di oggetto Action che dovrà venir istanziato ed associato al nodo competente. Quindi si rende necessario creare in memoria un database che permetta l associazione fra la chiave che indica il comando con l oggetto da utilizzare come azione. Viene quindi creata una mappa all interno della ActionFactory dove sono inseriti i comandi disponibili con gli oggetti corrispondenti e si utilizza, come metodologia per la creazione di nuove istanze, il pattern Builder [14]. Per rendere più semplice la procedura di espansione del framework e di inserimento dei comandi nella mappa, abbiamo creato una classe astratta Command che deve venir implementata da tutte le classi dei comandi, fornendo così l interfaccia utilizzata per il pattern Builder per la creazione di nuovi oggeti ed il metodo per l auto-registrazione nella mappa dell oggetto stesso. Inoltre, per velocizzare ulteriormente l aggiunta di nuovi comandi, è stato creata una classe ad-hoc (chiamata SkelCommand) con i suoi file di codice e di header contenenti la struttura vuota dell oggetto che implementa un azione; la procedura per inserire nuove istruzioni prevede:

190 3.2. Sviluppo piattaforma S.T.R.E.S.S la creazione dei nuovi file di codice e di header copiando e rinominando quelli dello SkelCommand; 2. lo sviluppo del metodo runaction(composite*) che implementa l azione da inserire; 3. indicare la stringa che rappresenta il comando nella definizione ABNF, che deve quindi essere racchiusa fra parentesi ancolate; 4. inserire all interno dell apposito file header include-actions.h l include del nuovo file.h che si è andato a creare. In questo modo alla successiva ricompilazione, sarà automaticamente riconosciuto il nuovo comando ed all avvio del programma, quando verrà creato il database, sarà inserita anche la nuova funzionalità. Figura 3.14: La classe ActionFactory Injector automatico di anomalie La specifica in ABNF prevede la possibilità di inserire manualmente le anomalie nel traffico di rete. Questa possibilità è essenziale quando vogliamo andare ad analizzare particolari aspetti ed alcuni punti precisi del protocollo, quindi in una fase più avanzata del processo di testing; risulta invece lungo e macchinoso operare un inserimento del genere nelle prime fasi, quando ci interessa

191 174 Capitolo 3. S.T.R.E.S.S. mettere sotto stress tutta la IUT. Per agevolare e velocizzare questo procedimento è stato progettato un sistema per permettere l implementazione di euristiche di attacco per automatizzare l inserimento delle anomalie favorendo il riutilizzo di tali euristiche per l implementazione di protocolli diversi. Figura 3.15: anomalie Diagramma delle classi del sistema di inserimento automatico di Nella fase successiva al parsing ed alla creazione del modello, viene invocato l AnomalyInjector, la classe che va ad implementare le procedure di ricerca all interno dell albero Composite, dei nodi dove andare ad inserire le anomalie, cioè quelli deputati all invio dei pacchetti. Una volta identificati, questa richiama la classe InjectorPerformer che opererà sui figli di tali nodi ed andrà a modificare la parte del sotto albero contenente le informazioni che devono essere inserite all interno del pacchetto da inviare. In base alle euristiche abilitate, i nodi foglia contenenti le informazioni corrette verranno sostituiti da un OrComposite (il nodo collegato all operatore alternativa

192 3.2. Sviluppo piattaforma S.T.R.E.S.S. 175 e quindi alla presenza di anomalie) con vari figli contenenti il valore originale ed altri valori anomali. La selezione delle anomalie viene delegata alle classi Injector, che implementano le varie euristiche; nel nostro studio abbiamo implementato una semplice euristica che inserisce valori anomali solo nei campi stringa, ma possono essere implementate logiche più complesse che, analizzando la struttura dell albero, possono inserire anomalie più raffinate (per esempio riconoscere campi di lunghezza o simboli terminatori). Attualmente l unica euristica inserita opera solo sulle StringLeaf, quindi su i nodi che contengono il simbolo terminale ABNF di stringa operando le seguenti mutazioni: Inserimento all interno della stringa originale di alcuni byte speciali: Terminatore: simbolo ABNF %x00; Carriage Return: simbolo ABNF %x0d; New Line: simbolo ABNF %x0a; creazione di una stringa di input molto lunga ottenuta concatenando 512 volte la stringa originale; sostituzione con una serie di byte non ASCII di uguale lunghezza; un valore completamente casuale come in un fuzzer; inserimento di una stringa nulla. Utilizzando questa euristica su un modello del protocollo POP3 che prevede l invio di 5 messaggi di testo verranno prodotti il totale di test case. Per implementare nuove euristiche è necessario creare un nuovo oggetto che implementi l interfaccia Injector, andando a produrre solo i metodi inject che mutano quel tipo di informazione, tralasciando gli altri; l InjectorPerformer

193 176 Capitolo 3. S.T.R.E.S.S. quando andrà a modificare l albero del modello richiederà a tutti gli Injector presenti di modificare i nodi interessati. Monitoring Aspetto fondamentale in tutte le procedure di testing funzionale è l analisi del comportamento della IUT, per permettere il riconoscimento dell esito del test case. Il problema dell oracolo (presentato nel capitolo 3.1.1) è una delle problematiche principali quando si parla di black box testing, perché non avendo alcuna informazione aggiuntiva, salvo le specifiche di funzionamento, è estremamente difficoltoso capire quando si viene a manifestare un guasto che non sfocia in un fallimento del sistema. Per cercare quindi di agevolare l analisi del comportamento della componente sotto test si è sviluppato il supporto per una serie di sensori che andranno a prelevare informazioni durante l esecuzione dei vari test case. Abbiamo innanzitutto identificato le fasi di interesse durante i test case a cui vincolare eventuali segnali da inviare ai sensori per le rilevazioni: 1. all inizio di ogni test case per la procedura di setup e l inizio delle misurazioni; 2. al momento dell invio di un pacchetto; 3. al momento della ricezione di un pacchetto; 4. alla fine di ogni test case per compiere una misurazione finale e disabilitare l osservazione; 5. successivamente alla fine del test case per prelevare i dati raccolti. Deleghiamo la comunicazione con i vari sensori alla classe che gestisce l evoluzione della test suite, l oggetto TestCaseManager che, come si vede in figura 3.17,

194 3.2. Sviluppo piattaforma S.T.R.E.S.S. 177 Figura 3.16: Schema di funzionamento del monitor e scambio di messaggi con le componenti

Classificazione delle tecniche di accesso multiplo

Classificazione delle tecniche di accesso multiplo Classificazione delle tecniche di accesso multiplo Le tecniche di accesso multiplo si dividono in tre classi: Protocolli deterministici o senza contesa: evitano la possibilità che due utenti accedano al

Dettagli

Parte II: Reti di calcolatori Lezione 23

Parte II: Reti di calcolatori Lezione 23 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 23 Giovedì 22-05-2014 1 Reti wireless Una

Dettagli

Parte II: Reti di calcolatori Lezione 23

Parte II: Reti di calcolatori Lezione 23 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Pietro Frasca Parte II: Reti di calcolatori Lezione 23 Martedì 26-05-2015 1 Confronto tra switch

Dettagli

MobiMESH. Presentazione tecnico-commerciale. Ing. Stefano Napoli Product Manager

MobiMESH. Presentazione tecnico-commerciale. Ing. Stefano Napoli Product Manager MobiMESH Presentazione tecnico-commerciale Ing. Stefano Napoli Product Manager Un paradigma di networking Architettura di rete MobiMESH Rete Cablata: integrata nel routing Backbone: infrastruttura wireless

Dettagli

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto)

C) supponendo che la scuola voglia collegarsi in modo sicuro con una sede remota, valutare le possibili soluzioni (non risolto) PROGETTO DI UNA SEMPLICE RETE Testo In una scuola media si vuole realizzare un laboratorio informatico con 12 stazioni di lavoro. Per tale scopo si decide di creare un unica rete locale che colleghi fra

Dettagli

Protocolli di accesso multiplo

Protocolli di accesso multiplo Protocolli di accesso multiplo Quando l accesso ad una risorsa può avvenire da parte di più utenti indipendenti, si parla di risorsa condivisa ed è necessaria l implementazione di particolari protocolli

Dettagli

INTEGRAZIONE ED ESPANSIONE DEL SISTEMA DI VIDEOSORVEGLIANZA DEL COMUNE DI CASTELLAMMARE DI STABIA TITOLO ELABORATO: MODULO ISOLE WI-FI HOT SPOT

INTEGRAZIONE ED ESPANSIONE DEL SISTEMA DI VIDEOSORVEGLIANZA DEL COMUNE DI CASTELLAMMARE DI STABIA TITOLO ELABORATO: MODULO ISOLE WI-FI HOT SPOT INTEGRAZIONE ED ESPANSIONE DEL SISTEMA DI VIDEOSORVEGLIANZA DEL COMUNE DI CASTELLAMMARE DI STABIA TITOLO ELABORATO: MODULO ISOLE WI-FI HOT SPOT INDICE 1. PREMESSA 4 2. ARCHITETTURA RETI MESH 5 3. DISPOSITIVI

Dettagli

INTRODUZIONE A RETI E PROTOCOLLI

INTRODUZIONE A RETI E PROTOCOLLI PARTE 1 INTRODUZIONE A RETI E PROTOCOLLI Parte 1 Modulo 1: Introduzione alle reti Perché le reti tra computer? Collegamenti remoti a mainframe (< anni 70) Informatica distribuita vs informatica monolitica

Dettagli

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com A cura di: Dott. Ing. Elisabetta Visciotti e.visciotti@gmail.com Il termine generico rete (network) definisce un insieme di entità (oggetti, persone, ecc.) interconnesse le une alle altre. Una rete permette

Dettagli

Centralino telefonico OfficeServ 7400

Centralino telefonico OfficeServ 7400 Centralino telefonico OfficeServ 7400 Samsung OfficeServ 7400 è il sistema di comunicazione all-in-one dedicato alle aziende di medie e grandi dimensioni che necessitano di soluzioni semplici ed integrate

Dettagli

150 Piazze Wi-Fi. Unidata S.p.A. Una iniziativa Unidata e Wired

150 Piazze Wi-Fi. Unidata S.p.A. Una iniziativa Unidata e Wired Allegato 4 all Accordo di adesione alla fase sperimentale del progetto "150 Piazze Wi-Fi" relativo alla fornitura a titolo di comodato gratuito di apparecchiature hardware e correlato software di gestione

Dettagli

MobiMESH. Wireless Mesh a banda larga. Ing. Stefano Napoli Product Manager

MobiMESH. Wireless Mesh a banda larga. Ing. Stefano Napoli Product Manager MobiMESH Wireless Mesh a banda larga Ing. Stefano Napoli Product Manager Un paradigma di networking Architettura di rete MobiMESH Rete Cablata: integrata nel routing Backbone: infrastruttura wireless multihop

Dettagli

Centralino telefonico OfficeServ 7200

Centralino telefonico OfficeServ 7200 Centralino telefonico OfficeServ 7200 Samsung OfficeServ 7200 costituisce un unica soluzione per tutte le esigenze di comunicazione di aziende di medie dimensioni. OfficeServ 7200 è un sistema telefonico

Dettagli

Music Everywhere with BT

Music Everywhere with BT Music Everywhere with BT Acquaviva Luca 231767 luca.acquaviva@studio.unibo.it Colombini Gabriele 231491 gabriele.colombini@studio.unibo.it Manservisi Alberto 258370 alberto.manservisi@studio.unibo.it Abstract

Dettagli

Applicazione di algoritmi di routing dinamico su reti wireless in ambiente portuale

Applicazione di algoritmi di routing dinamico su reti wireless in ambiente portuale 1 Applicazione di algoritmi di routing dinamico su reti wireless in ambiente portuale Tesi svolta presso il Fantuzzi Reggiane Electronic Department (FRED) Relatore: Prof. G. Dodero Candidato: Daniele Venzano

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Reti di Calcolatori Claudio Marrocco Componenti delle reti Una qualunque forma di comunicazione avviene: a livello hardware tramite un mezzo fisico che

Dettagli

1.4.1 Architettura protocollare 802.15. 1.4.2 Architettura Core System

1.4.1 Architettura protocollare 802.15. 1.4.2 Architettura Core System Introduzione Capitolo 1: Le Reti Wireless 1.1 Introduzione 1.2 Le reti Cellulari 1.2.1 Struttura di una rete cellulare 1.2.2 Stabilimento e mantenimento di una chiamata 1.3 Panoramica sulle diverse generazioni

Dettagli

Tecnologie per il web e lo sviluppo multimediale. Reti di Calcolatori e Internet

Tecnologie per il web e lo sviluppo multimediale. Reti di Calcolatori e Internet Tecnologie per il web e lo sviluppo multimediale Reti di Calcolatori e Internet Luca Pulina Corso di Laurea in Scienze della Comunicazione Università degli Studi di Sassari A.A. 2015/2016 Luca Pulina (UNISS)

Dettagli

Anno Accademico 2013-2014. Lucidi del corso di Reti di Calcolatori e Comunicazione Digitale. Introduzione ( parte II) Topologie di rete

Anno Accademico 2013-2014. Lucidi del corso di Reti di Calcolatori e Comunicazione Digitale. Introduzione ( parte II) Topologie di rete INFORMATICA e COMUNICAZIONE DIGITALE Anno Accademico 2013-2014 Lucidi del corso di Reti di Calcolatori e Comunicazione Digitale Introduzione ( parte II) Prof. Sebastiano Pizzutilo Dipartimento di Informatica

Dettagli

Informatica Generale Andrea Corradini. 10 - Le reti di calcolatori e Internet

Informatica Generale Andrea Corradini. 10 - Le reti di calcolatori e Internet Informatica Generale Andrea Corradini 10 - Le reti di calcolatori e Internet Cos è una rete di calcolatori? Rete : È un insieme di calcolatori e dispositivi collegati fra loro in modo tale da permettere

Dettagli

Modello OSI e architettura TCP/IP

Modello OSI e architettura TCP/IP Modello OSI e architettura TCP/IP Differenza tra modello e architettura - Modello: è puramente teorico, definisce relazioni e caratteristiche dei livelli ma non i protocolli effettivi - Architettura: è

Dettagli

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice Indice 1. Definizioni essenziali 2. Modelli di rete 3. Reti fisiche 4. Protocolli di rete 5. Modelli di riferimento 6. Raffronto tra modelli Architettura degli Elaboratori 2 - T. Vardanega Pagina 275 Definizioni

Dettagli

Progettazione di reti AirPort

Progettazione di reti AirPort apple Progettazione di reti AirPort Indice 1 Per iniziare con AirPort 5 Utilizzo di questo documento 5 Impostazione Assistita AirPort 6 Caratteristiche di AirPort Admin Utility 6 2 Creazione di reti AirPort

Dettagli

Elementi di Reti per Telecomunicazioni

Elementi di Reti per Telecomunicazioni Elementi di Reti per Telecomunicazioni (Parte II) Topologie ed Interfacciamento di Reti Corso di Telecomunicazioni Anno Accademico 2004/2005 Contenuti Introduzione alle reti di TLC. Topologie di Reti per

Dettagli

1 Descrizione del sistema satellitare D-STAR.

1 Descrizione del sistema satellitare D-STAR. 1 Descrizione del sistema satellitare D-STAR. Il sistema satellitare D-STAR è una rete di terminali VSAT (Very Small Aperture Terminal) con topologia a stella, al centro della quale è presente un HUB satellitare

Dettagli

MotoTRBO IPSC: le chiamate.!

MotoTRBO IPSC: le chiamate.! MotoTRBO IPSC: le chiamate. Versione del documento v1.0 Aggiornato a Febbraio 2014 Realizzazione a cura di Armando Accardo, IK2XYP Email: ik2xyp@ik2xyp.it Team ircddb-italia http://www.ircddb-italia.it

Dettagli

Sistemi informatici in ambito radiologico

Sistemi informatici in ambito radiologico Sistemi informatici in ambito radiologico Dott. Ing. Andrea Badaloni A.A. 2015 2016 Reti di elaboratori, il modello a strati e i protocolli di comunicazione e di servizio Reti di elaboratori Definizioni

Dettagli

Prefazione all edizione italiana

Prefazione all edizione italiana Sommario Prefazione all edizione italiana XIII Capitolo 1 Introduzione 1.1 Applicazioni delle reti di calcolatori 2 1.1.1 Applicazioni aziendali 3 1.1.2 Applicazioni domestiche 5 1.1.3 Utenti mobili 8

Dettagli

Laboratorio di Informatica. Le reti telematiche e Internet

Laboratorio di Informatica. Le reti telematiche e Internet Le reti telematiche e Internet Lezione 6 1 Insieme di cavi, protocolli, apparati di rete che collegano tra loro computer distinti i cavi trasportano fisicamente le informazioni opportunamente codificate

Dettagli

Reti di computer- Internet- Web. Concetti principali sulle Reti Internet Il Web

Reti di computer- Internet- Web. Concetti principali sulle Reti Internet Il Web Reti di computer- Internet- Web Concetti principali sulle Reti Internet Il Web Condivisione di risorse e comunicazione con gli altri utenti n n n Anni 70: calcolatori di grandi dimensioni, modello timesharing,

Dettagli

Reti di calcolatori. Condivisione di risorse e comunicazione con gli altri utenti

Reti di calcolatori. Condivisione di risorse e comunicazione con gli altri utenti Reti di calcolatori Condivisione di risorse e comunicazione con gli altri utenti Reti di calcolatori Anni 70: calcolatori di grandi dimensioni, modello time-sharing, centri di calcolo Anni 80: reti di

Dettagli

Programmazione in Rete

Programmazione in Rete Programmazione in Rete a.a. 2005/2006 http://www.di.uniba.it/~lisi/courses/prog-rete/prog-rete0506.htm dott.ssa Francesca A. Lisi lisi@di.uniba.it Orario di ricevimento: mercoledì ore 102 Sommario della

Dettagli

PACKET TRACER 4.0 Cisco Networking Academy Program

PACKET TRACER 4.0 Cisco Networking Academy Program PACKET TRACER 4.0 Cisco Networking Academy Program 1.0 Cosa è Packet Tracer? Packet Tracer (PT) è uno software didattico distribuito liberamente agli studenti ed istruttori del Programma Cisco Networking

Dettagli

Reti di computer. Agostino Lorenzi - Reti di computer - 2008

Reti di computer. Agostino Lorenzi - Reti di computer - 2008 Reti di computer Telematica : termine che evidenzia l integrazione tra tecnologie informatiche e tecnologie delle comunicazioni. Rete (network) : insieme di sistemi per l elaborazione delle informazioni

Dettagli

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1 Introduzione Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio Livello applicativo Principi delle applicazioni di rete 2-1 Pila di protocolli Internet Software applicazione: di

Dettagli

Utilizzare 4CBOX come centralino significa avere un sistema all inclusive oltre a

Utilizzare 4CBOX come centralino significa avere un sistema all inclusive oltre a Utilizzare 4CBOX come centralino significa avere un sistema all inclusive oltre a IVR risponditore, VoiceMail e gestione delle code operatore. Utilizzare oltre alle tradizionali linee telefoniche, anche

Dettagli

Reti e Linux. Andrea Bontempi. Corsi Linux 2012. POuL

Reti e Linux. Andrea Bontempi. Corsi Linux 2012. POuL POuL Corsi Linux 2012 Una breve introduzione: le reti Una rete di calcolatori è un mezzo fisico sul quale è possibile inviare e ricevere messaggi o flussi di dati. La prima rete a commutazione di pacchetto

Dettagli

Reti di calcolatori. Lezione del 10 giugno 2004

Reti di calcolatori. Lezione del 10 giugno 2004 Reti di calcolatori Lezione del 10 giugno 2004 Internetworking I livelli 1 fisico e 2 data link si occupano della connessione di due host direttamente connessi su di una rete omogenea Non è possibile estendere

Dettagli

Reti di Calcolatori. Lezione 2

Reti di Calcolatori. Lezione 2 Reti di Calcolatori Lezione 2 Una definizione di Rete Una moderna rete di calcolatori può essere definita come: UN INSIEME INTERCONNESSO DI CALCOLATORI AUTONOMI Tipi di Rete Le reti vengono classificate

Dettagli

Reti di calcolatori. Permettono la condivisione di risorse (hardware e software) e la comunicazione con gli altri utenti. Reti di calcolatori

Reti di calcolatori. Permettono la condivisione di risorse (hardware e software) e la comunicazione con gli altri utenti. Reti di calcolatori Reti di calcolatori Permettono la condivisione di risorse (hardware e software) e la comunicazione con gli altri utenti Reti di calcolatori Anni 70: calcolatori di grandi dimensioni, modello time-sharing,

Dettagli

Sicurezza delle reti wireless. Alberto Gianoli alberto.gianoli@fe.infn.it

Sicurezza delle reti wireless. Alberto Gianoli alberto.gianoli@fe.infn.it Sicurezza delle reti wireless Alberto Gianoli alberto.gianoli@fe.infn.it Concetti di base IEEE 802.11: famiglia di standard tra cui: 802.11a, b, g: physical e max data rate spec. 802.11e: QoS (traffic

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Finalità delle Reti di calcolatori. Le Reti Informatiche. Una definizione di Rete di calcolatori. Schema di una Rete

Finalità delle Reti di calcolatori. Le Reti Informatiche. Una definizione di Rete di calcolatori. Schema di una Rete Finalità delle Reti di calcolatori Le Reti Informatiche Un calcolatore isolato, anche se multiutente ha a disposizione solo le risorse locali potrà elaborare unicamente i dati dei propri utenti 2 / 44

Dettagli

Prof.ssa Sara Michelangeli. Computer network

Prof.ssa Sara Michelangeli. Computer network Prof.ssa Sara Michelangeli Computer network Possiamo definire rete di computer (Computer network) un sistema in cui siano presenti due o più elaboratori elettronici ed i mezzi per connetterli e che consenta

Dettagli

Modulo 8 Ethernet Switching

Modulo 8 Ethernet Switching Modulo 8 Ethernet Switching 8.1 Ethernet Switching 8.1.1 Bridging a livello 2 Aumentando il numero di nodi su un singolo segmento aumenta la probabilità di avere collisioni e quindi ritrasmissioni. Una

Dettagli

Università degli Studi di Napoli Federico II

Università degli Studi di Napoli Federico II Università degli Studi di Napoli Federico II Ottimizzazione del traffico P2P nelle Wireless Community Network Stefano Avallone, Roberto Canonico, Giorgio Ventre, Francesco Paolo D'Elia Conferenza GARR

Dettagli

Simulazione prova scritta di sistemi Abacus per l Esame di Stato. Traccia n 1

Simulazione prova scritta di sistemi Abacus per l Esame di Stato. Traccia n 1 Simulazione prova scritta di sistemi Abacus per l Esame di Stato Traccia n 1 La condivisione delle informazioni e lo sviluppo delle risorse informatiche tramite cui esse possono venire memorizzate e scambiate

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Reti di calcolatori: Introduzione

Reti di calcolatori: Introduzione Reti di calcolatori: Introduzione Vittorio Maniezzo Università di Bologna Reti di computer e Internet Rete: sistema di collegamento di più computer mediante una singola tecnologia di trasmissione Internet:

Dettagli

La rete è una componente fondamentale della

La rete è una componente fondamentale della automazioneoggi Attenti alle reti La telematica si basa prevalentemente sulle reti come mezzo di comunicazione per cui è indispensabile adottare strategie di sicurezza per difendere i sistemi di supervisione

Dettagli

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche Il Cloud Computing La visualizzazione nella Cloud Problematiche Virtualizzazione della GPU Front end Virtualization

Dettagli

802.11... cosa??? Configuriamo una rete wireless per condividere l'adsl. 2007 04 14 Sciarada Bolzano Daniele Gobbetti

802.11... cosa??? Configuriamo una rete wireless per condividere l'adsl. 2007 04 14 Sciarada Bolzano Daniele Gobbetti 802.11... cosa??? Configuriamo una rete wireless per condividere l'adsl. Sommario Cos'è una rete wireless Alternative a disposizione 802.11 e sicurezza Condividere l'accesso ADSL FAQ Cos'è una rete wireless

Dettagli

A Palazzo Madama la sicurezza è di casa

A Palazzo Madama la sicurezza è di casa A Palazzo Madama la sicurezza è di casa di Giovanni Contardi, Responsabile Security & Safety del Senato della Repubblica e Fabio Garzia, Docente di Sistemi di Sicurezza Anticrimine nel corso di laurea

Dettagli

Networking Wireless con Windows XP

Networking Wireless con Windows XP Networking Wireless con Windows XP Creare una rete wireless AD HOC Clic destro su Risorse del computer e quindi su Proprietà Clic sulla scheda Nome computer e quindi sul pulsante Cambia Digitare il nome

Dettagli

FRITZ!WLAN Repeater 300E. Come estendere la copertura della rete Wi-Fi

FRITZ!WLAN Repeater 300E. Come estendere la copertura della rete Wi-Fi Come estendere la copertura della rete Wi-Fi 1 Introduzione La crescente diffusione di dispositivi portatili per il collegamento ad Internet ha reso la connettività senza fili una caratteristica imprescindibile

Dettagli

Capitolo 1 - parte 1. Corso Reti ed Applicazioni Mauro Campanella

Capitolo 1 - parte 1. Corso Reti ed Applicazioni Mauro Campanella Capitolo 1 - parte 1 Corso Reti ed Applicazioni Mauro Campanella Precisazione Noi ci occuperemo solo della trasmissione di informazione in formato digitale. Un segnale analogico è basato su una variazione

Dettagli

La classificazione delle reti

La classificazione delle reti La classificazione delle reti Introduzione Con il termine rete si intende un sistema che permette la condivisione di informazioni e risorse (sia hardware che software) tra diversi calcolatori. Il sistema

Dettagli

CASE STUDY N#1. Deploy e automazione di un applicazione scalabile con il supporto di SaltStack per Corley

CASE STUDY N#1. Deploy e automazione di un applicazione scalabile con il supporto di SaltStack per Corley CASE STUDY N#1 Deploy e automazione di un applicazione scalabile con il supporto di SaltStack per Corley Enter srl - ISO 9001/27001 Quality System Certification - All rights reserved - www.entercloudsuite.it

Dettagli

MANUALE DELLA QUALITA SCHEDA DI PROGETTAZIONE DELLE ATTIVITÀ DIDATTICHE EDUCATIVE PER DISCIPLINA AL. 2.1.2

MANUALE DELLA QUALITA SCHEDA DI PROGETTAZIONE DELLE ATTIVITÀ DIDATTICHE EDUCATIVE PER DISCIPLINA AL. 2.1.2 Pag 1 di 7 MINISTERO DELL ISTRUZIONE,DELL UNIVERSITA E DELLA RICERCA UFFICIO SCOLASTICO REGIONALE PER L ABRUZZO I.I.S. Crocetti - Cerulli - Giulianova SCHEDA DI PROGRAMMAZIONE DELLE ATTIVITA EDUCATIVE

Dettagli

La virtualizzazione dell infrastruttura di rete

La virtualizzazione dell infrastruttura di rete La virtualizzazione dell infrastruttura di rete La rete: la visione tradizionale La rete è un componente passivo del processo che trasporta i dati meglio che può L attenzione è sulla disponibilità di banda

Dettagli

Capitolo 6. Wireless LAN: via i fili!

Capitolo 6. Wireless LAN: via i fili! Capitolo 6 Wireless LAN: via i fili! Spesso la realizzazione di una rete impone maggiori problemi nella realizzazione fisica che in quella progettuale: il passaggio dei cavi all interno di apposite guide

Dettagli

Laboratorio di Informatica Corso di laurea in Lingue e Studi interculturali. AA 2010-2011. Paola Zamperlin. Internet. Parte prima

Laboratorio di Informatica Corso di laurea in Lingue e Studi interculturali. AA 2010-2011. Paola Zamperlin. Internet. Parte prima Laboratorio di Informatica Corso di laurea in Lingue e Studi interculturali. AA 2010-2011 Paola Zamperlin Internet. Parte prima 1 Definizioni-1 Una rete di calcolatori è costituita da computer e altri

Dettagli

I protocolli wireless della famiglia IEEE 802

I protocolli wireless della famiglia IEEE 802 I protocolli wireless della famiglia IEEE 802 Davide Quaglia Reti di Calcolatori - Ethernet e 802.X 1 Problemi delle wireless LAN Interferenza e caduta di potenza del segnale Alta probabilità che il frame

Dettagli

10 argomenti a favore dell over IP

10 argomenti a favore dell over IP Quello che i fornitori di telecamere analogiche non dicono 10 argomenti a favore dell over IP Le telecamere di rete non sono certo una novità, infatti il primo modello è stato lanciato nel 1996. Nei primi

Dettagli

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto Università degli studi di Salerno Laurea in Informatica I semestre / Commutazione di Pacchetto Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Svantaggi della Commutazione

Dettagli

WiFi: Connessione senza fili. di Andreas Zoeschg

WiFi: Connessione senza fili. di Andreas Zoeschg WiFi: Connessione senza fili di Andreas Zoeschg Introduzione Le tecnologie wireless risultano particolarmente adatte qualora sia necessario supportare la mobilità dei dispositivi utenti o per il deployment

Dettagli

ProCurve Radio Port 230

ProCurve Radio Port 230 La ProCurve Radio Port 230, con integrato il supporto per le funzioni wireless IEEE 802.11a e IEEE 802.11g, è in grado di lavorare congiuntamente ai moduli ProCurve Wireless Edge Services xl e zl, per

Dettagli

CONVENZIONE CONSIP RETI LOCALI 5 - RICHIESTA PROGETTO PRELIMINARE

CONVENZIONE CONSIP RETI LOCALI 5 - RICHIESTA PROGETTO PRELIMINARE CONVENZIONE CONSIP RETI LOCALI 5 - RICHIESTA PROGETTO PRELIMINARE AMMINISTRAZIONE IC CF. 90008940612 CM ceic84000d Spett.le Telecom Italia S.p.A. ICT Solutions & Service Platforms Gestione Convenzioni

Dettagli

Indice generale. Introduzione...xiii. Nota del revisore...xvii. Introduzione alle reti...1. Introduzione alle reti wireless...11

Indice generale. Introduzione...xiii. Nota del revisore...xvii. Introduzione alle reti...1. Introduzione alle reti wireless...11 Introduzione...xiii Nota del revisore...xvii Capitolo 1 Capitolo 2 Introduzione alle reti...1 Trasferimento di dati... 2 Bit e byte... 2 Controllo di errore... 3 Handshaking... 3 Trovare la destinazione...

Dettagli

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30 Protocolli di rete Vittorio Maniezzo Università di Bologna Vittorio Maniezzo Università di Bologna 02 Protocolli - 1/30 Strati di protocolli (Protocol Layers) Le reti sono complesse Molti elementi: host

Dettagli

Dipartimento di Scienze Applicate

Dipartimento di Scienze Applicate DIPARTIMENTO DI SCIENZE APPLICATE Università degli Studi di Napoli Parthenope Centro Direzionale di Napoli Isola C4 80143 Napoli dsa@uniparthenope.it P. IVA 01877320638 Dipartimento di Scienze Applicate.

Dettagli

Reti di Calcolatori. Master "Bio Info" Reti e Basi di Dati Lezione 4

Reti di Calcolatori. Master Bio Info Reti e Basi di Dati Lezione 4 Reti di Calcolatori Sommario Software di rete Livello Trasporto (TCP) Livello Rete (IP, Routing, ICMP) Livello di Collegamento (Data-Link) Software di rete Livello Rete (IP, Routing, ICMP) Se i protocolli

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Parte II: Reti di calcolatori Lezione 11

Parte II: Reti di calcolatori Lezione 11 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II: Reti di calcolatori Lezione 11 Martedì 14-04-2015 1 Esempio di uso di proxy Consideriamo

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Centro Nazionale per l informatica nella Pubblica Amministrazione. Allegato A CAPITOLATO TECNICO. 1 di 23

Centro Nazionale per l informatica nella Pubblica Amministrazione. Allegato A CAPITOLATO TECNICO. 1 di 23 Centro Nazionale per l informatica nella Pubblica Amministrazione Allegato A CAPITOLATO TECNICO 1 di 23 INDICE PREMESSA... 4 RIFERIMENTI... 4 1. Servizi di Trasporto Always On Flat Accessi Asimmetrici

Dettagli

Centralino Telefonico Samsung OfficeServ 7030

Centralino Telefonico Samsung OfficeServ 7030 Centralino Telefonico Samsung OfficeServ 7030 Il centralino telefonico OfficeServ 7030 pur provvisto di un ampio insieme di funzionalità vuole coprire principalmente le esigenze delle piccole realtà aziendali.

Dettagli

Packet Tracer: simulatore di RETE

Packet Tracer: simulatore di RETE Packet Tracer: simulatore di RETE Packet Tracer è un software didattico per l'emulazione di apparati di rete CISCO. http://www.cisco.com/web/it/training_education/networking_academy/packet_tracer.pdf PT

Dettagli

App Android Client 1

App Android Client 1 App Android Client 1 Agenda Oggetto della presentazione Perchè GEG presenta questo prodotto? Come viene implementato ed integrato? Come può essere utilizzato il concetto di TetraFlex Broadband? Requisiti

Dettagli

Le Reti LAN: componenti attivi

Le Reti LAN: componenti attivi Le Reti LAN: componenti attivi Descrizione dei principali componenti attivi di rete: Livello1: Repeater, Hub Livello 2: Bridge, Switch Livello 3: Router Componenti di una rete Nelle reti informatiche alcuni

Dettagli

Reti di elaboratori. Reti di elaboratori. Reti di elaboratori INFORMATICA PER LE DISCIPLINE UMANISTICHE 2 (13042)

Reti di elaboratori. Reti di elaboratori. Reti di elaboratori INFORMATICA PER LE DISCIPLINE UMANISTICHE 2 (13042) Reti di elaboratori Rete di calcolatori: insieme di dispositivi interconnessi Modello distribuito INFORMATICA PER LE DISCIPLINE UMANISTICHE 2 (13042) Funzioni delle reti: comunicazione condivisione di

Dettagli

Informatica per la comunicazione" - lezione 8 -

Informatica per la comunicazione - lezione 8 - Informatica per la comunicazione - lezione 8 - Esercizio Convertire i seguenti numeri da base 10 a base 2: 8, 23, 144, 201. Come procedere per risolvere il problema? Bisogna ricordarsi che ogni sistema,

Dettagli

pod Guida all installazione di rete del Solstice Pod Introduzione Solstice Pod Collaborazione Visuale Wireless Solstice sulla vostra rete

pod Guida all installazione di rete del Solstice Pod Introduzione Solstice Pod Collaborazione Visuale Wireless Solstice sulla vostra rete Introduzione Solstice Pod Collaborazione Visuale Wireless Una volta installato, il Solstice Pod permette a più utenti di condividere simultaneamente il proprio schermo su un display tramite la rete Wi-Fi

Dettagli

VPN (OpenVPN - IPCop)

VPN (OpenVPN - IPCop) VPN (OpenVPN - IPCop) Davide Merzi 1 Sommario Indirizzo IP Reti Pubbliche Private Internet Protocollo Firewall (IPCop) VPN (OpenVPN IPsec on IPCop) 2 Indirizzo IP L'indirizzo IP (Internet Protocol address)

Dettagli

Reti di Calcolatori. Telematica: Si occupa della trasmissione di informazioni a distanza tra sistemi informatici, attraverso reti di computer

Reti di Calcolatori. Telematica: Si occupa della trasmissione di informazioni a distanza tra sistemi informatici, attraverso reti di computer Reti di Calcolatori 1. Introduzione Telematica: Si occupa della trasmissione di informazioni a distanza tra sistemi informatici, attraverso reti di computer Reti di calcolatori : Un certo numero di elaboratori

Dettagli

Reti di Calcolatori: nozioni generali il modello a livelli

Reti di Calcolatori: nozioni generali il modello a livelli Reti di Calcolatori: nozioni generali il modello a livelli Percorso di Preparazione agli Studi di Ingegneria Università degli Studi di Brescia Docente: Massimiliano Giacomin Elementi di Informatica e Programmazione

Dettagli

APPARATI DI INTERNETWORKING

APPARATI DI INTERNETWORKING APPARATI DI INTERNETWORKING Prof. Ing. Maurizio Casoni Dipartimento di Ingegneria Enzo Ferrari Università degli Studi di Modena e Reggio Emilia REPEATERS Apparato attivo che collega 2 o più mezzi di trasmissione

Dettagli

Sicurezza a livello IP: IPsec e le reti private virtuali

Sicurezza a livello IP: IPsec e le reti private virtuali Sicurezza a livello IP: IPsec e le reti private virtuali Davide Cerri Sommario L esigenza di proteggere l informazione che viene trasmessa in rete porta all utilizzo di diversi protocolli crittografici.

Dettagli

Centralino telefonico OfficeServ 7200

Centralino telefonico OfficeServ 7200 Centralino telefonico OfficeServ 7200 Samsung OfficeServ 7200 Lite è un sistema di comunicazione ideale per aziende di medie dimensioni. OfficeServ 7200 Lite introduce una soluzione All-in-One che realizza

Dettagli

Realizzazione e gestione di Local Area Network

Realizzazione e gestione di Local Area Network Realizzazione e gestione di Local Area Network Ceracchi Fabiana Mansi Luigi Tutor Angelo Veloce NETWORK La rete è un insieme di sistemi per l elaborazione delle informazioni messi in comunicazione tra

Dettagli

Principi fondamentali

Principi fondamentali Principi fondamentali Elementi di base Definizione di rete di calcolatori Tipologia di connessioni Architettura di rete Prestazioni di una rete di calcolatori Conclusioni 1 1 Bit e Byte BIT = BInary digit

Dettagli

Centralino telefonico Samsung Officeserv 7030

Centralino telefonico Samsung Officeserv 7030 Centralino telefonico Samsung Officeserv 7030 Modularità Il design del sistema OfficeServ 7030 è basato su un unico Cabinet espandibile a due. Equipaggiamento OfficeServ 7030 introduce una soluzione All-in-One

Dettagli

CLASSIFICAZIONE DELLE RETI

CLASSIFICAZIONE DELLE RETI CLASSIFICAZIONE DELLE RETI A seconda dei ruoli dei computer le reti si classificano in: Reti Client Server in cui sono presenti computer con ruoli diversi, alcuni funzionano da client e uno o più da server

Dettagli

Sistemi Di Elaborazione Dell informazione

Sistemi Di Elaborazione Dell informazione Sistemi Di Elaborazione Dell informazione Dott. Antonio Calanducci Lezione III: Reti di calcolatori Corso di Laurea in Scienze della Comunicazione Anno accademico 2009/2010 Reti di calcolatori Una rete

Dettagli

Wireless LAN. Scritto da BigDaD

Wireless LAN. Scritto da BigDaD Una Wireless local area network, WLAN, è un sistema di comunicazione flessibile e implementabile nella sua estensione, o alternativo, ad una rete fissa (wired LAN). In una W-LAN viene utilizzata una tecnologia

Dettagli

Evoluzione dei sistemi informatici

Evoluzione dei sistemi informatici Evoluzione dei sistemi informatici Cos è una rete? Insieme di calcolatori autonomi tra loro collegati mediante una rete di comunicazione Gli utenti sono in grado di interagire in modo esplicito con la

Dettagli

Introduzione. Capitolo 1: Introduzione al WiMAX

Introduzione. Capitolo 1: Introduzione al WiMAX Introduzione Questa tesi sarà organizzata in quattro capitoli dedicati interamente al WiMAX (Worldwide Interoperability for Microwave Access). Nel primo capitolo illustrerò i concetti generali della tecnologia,

Dettagli