Prestigiacomo Tesi I livello - Dipartimento Infocom - Il...

I

Indice

1. Introduzione al WiMAX........................................................................................................ 6

1.1. Le tecnologie 802.16 ................................................................................................ 6

1.2. Come lavorano le tecnologie 802.16 ........................................................................ 8

2. Progetto WEIRD ................................................................................................................. 18

2.1. Sintesi del Progetto................................................................................................. 19

2.2. Obiettivi del Progetto.............................................................................................. 21

2.3. Rilevanza degli obiettivi IST primari ..................................................................... 25

2.4. Stato di avanzamento.............................................................................................. 28

2.5. Progressi rispetto allo stato attuale ......................................................................... 33

2.6. Piano d’implementazione strutturale e logica di WEIRD....................................... 35

2.7. Attività di ricerca, sviluppo tecnologico e d’innovazione connesse al progetto..... 36

2.8. Progettazione ed implementazione della piattaforma di sperimentazione dell’infrastruttura (WP3000) .................................................................................. 39

2.9. Adapter ................................................................................................................... 50

3. Il Sistema Alcatel 7387 ....................................................................................................... 58

3.1. A7387 Base Station Equipment.............................................................................. 60

3.2. A7387 Management System (NMS) ...................................................................... 65

4. Algoritmi per l’allocazione di banda: analisi preliminare e procedure Matlab ................... 71

4.1. Generazione di N Sorgenti binarie ......................................................................... 71

4.2. Algoritmi base per l’allocazione di banda ......Errore. Il segnalibro non è definito.

4.3. Assegnazione della classe di servizio e dei limiti di allocazione di banda............. 85

4.4. Algoritmi di allocazione di banda per diverse QoS................................................ 89

5. Analisi dell’allocazione dinamica delle risorse in reti WMAN IEEE 802.16 ................... 107

5.1. Scenario ..........................................................Errore. Il segnalibro non è definito.

5.2. Approccio proposto .............................................................................................. 109

5.3. Risultati numerici.................................................................................................. 109

5.4. Conclusioni........................................................................................................... 121

Appendice A – Il Protocollo SNMP.......................................................................................... 122

A.1 La struttura delle informazioni di gestione ........................................................... 125

A.2. Uno sguardo al MIB-II ......................................................................................... 128

2

A.3. Funzionamento del protocollo SNMP .................................................................. 130

A.4. Formato di un messaggio SNMP.......................................................................... 131

Bibliografia ............................................................................................................................... 138

3

Indice delle figure

Figura 1 – Differenza tra LOS ed NLOS. .............................................................................. 7

Figura 2 – Range frequenziale per applicazioni 802.16 .......................................................... 9

Figura 3 – Rappresentazione temporale-frequenziale dell’OFDM ......................................... 10

Figura 4 – Schema del TDMA ........................................................................................... 10

Figura 5 – Schema della OFDMA ...................................................................................... 11

Figura 6 – Schema della SOFDMA .................................................................................... 12

Figura 7 – AMC in presenza di shadowing.......................................................................... 14

Figura 8 – Schema del TDD............................................................................................... 15

Figura 9 – Schema del FDD ............................................................................................... 16

Figura 10 – Adaptive Antenna System. ............................................................................... 18

Figura 11 – Scenario di monitoraggio sismico e vulcanico. .................................................. 20

Figura 12 – Scenario di video sorveglianza mobile. ............................................................. 20

Figura 13 – Scenario di tele-medicina (diagnosi remota). ..................................................... 21

Figura 14 – Uno scenario di applicazione di WEIRD ........................................................... 25

Figura 15 – Descrizione del sistema WEIRD....................................................................... 39

Figura 16 – Spazio 3D dei servizi per le applicazioni ........................................................... 40

Figura 17 – Dettaglio dell’asse della QoS ........................................................................... 41

Figura 18 - Architettura di contesto dell'Adapter ................................................................. 51

Figura 19 - Architettura dell’Adapter nell’ASN-GW............................................................ 53

Figura 20 - Implementazione del modulo Adapter. .............................................................. 55

Figura 21 - Interazioni su AI tra Adapter e Resource Controller ........................................... 56

Figura 22 - Interazioni SNMP tra Adapter ed SNMP Agent.................................................. 57

Figura 23 - Architettura del sistema Alcatel 7387 ................................................................ 59

Figura 24 - Customer Premise Equipment (CPE) ................................................................. 60

Figura 25 - RBS Access Units (a) ....................................................................................... 62

Figura 26 - RBS Access Units (b)....................................................................................... 63

Figura 27 - A7387-Micro DBS........................................................................................... 64

Figura 28 - A7387 Macro DBS .......................................................................................... 64

Figura 29 - A7387-Macro DBS-NPU (Network Processing Unit) ......................................... 64

Figura 30 - Menù principale del Monitor Program ............................................................... 67

Figura 31 - Menù Micro Base Station. ................................................................................ 67

Figura 32 - Emissione sorgenti ........................................................................................... 74

Figura 33 - Modello catena di Markov ................................................................................ 75

Figura 34 - Schema buffer condiviso .................................................................................. 77

Figura 35 - Allocazione buffer condiviso ............................................................................ 80

Figura 36 - Schema buffers indipendenti............................................................................. 80

Figura 37 - Allocazione buffers indipendenti....................................................................... 82

4

Figura 38 - Schema allocazione FIFO ................................................................................. 83

Figura 39 - Allocazione FIFO ............................................................................................ 84

Figura 40 - Allocazione FIFO individuale ........................................................................... 85

Figura 41 - Allocazione con separazione in classi di servizio................................................ 92

Figura 42 - Allocazione per classe di servizio...................................................................... 92

Figura 43 - Allocazione Round Robin................................................................................. 96

Figura 44 - Allocazione con Bandwidth Constraints .......................................................... 101

Figura 45 - Allocazione individuale con Bandwidth Constraints ......................................... 102

Figura 46 - Ritardo complessivo medio minimo ................................................................ 103

Figura 47 - Schema Weighted Fair Queueing .................................................................... 104

Figura 48 - Allocazione Weigthed Fair Queueing .............................................................. 106

Figura 49 - Struttura frame............................................................................................... 108

Figura 50 - Numero di messaggi generati per secondo ....................................................... 117

Figura 51 - Percentuale di collisioni [15 Contention Slots] ................................................. 118

Figura 52 - Lunghezza media della coda [15 Contention Slots]........................................... 118





Figura 57 - SNMP nella pila ISO-OSI............................................................................... 123

Figura 58 - Schema logico di un sistema di Network Management ..................................... 124

Figura 59 - Struttura ad albero dei MIBs ........................................................................... 126

Figura 60 - Struttura del MIB-II ....................................................................................... 129

Figura 61 - Struttura del pacchetto SNMP ......................................................................... 133

Figura 62 - Funzionamento del protocollo SNMP.............................................................. 134

Figura 63 - Messaggio GetRequestPDU............................................................................ 135

Figura 64 - Messaggio SetRequestPDU ............................................................................ 137

Figura 65 - Messaggio TrapPDU ...................................................................................... 138

5

Indice delle tabelle

Tabella 1 – Principali caratteristiche delle tecnologie 802.16.................................................. 8

Tabella 2 – Velocità di trasmissione supportate dalla OFDM con 256 sottoportanti ............... 13

Tabella 3 – Velocità di trasmissione supportate dalla OFDMA con 2048 sottoportanti ........... 13

Tabella 4 – Progressi introdotti daWEIRD allo stato attuale di avanzamento ......................... 35

Tabella 5 - Interfacce del modulo Adattatore. ...................................................................... 53

Tabella 6 - Scenario simulazione ........................................................................................ 89

Tabella 7 - Scenario simulazione ........................................................................................ 97

Tabella 8 - Nodi del MIB-II ............................................................................................. 130

6

1. Introduzione al WiMAX

Le tecnologie WiMAX sono tecnologie per l’accesso wireless a banda larga basate sullo

standard IEEE 802.16.

Esse possono essere utilizzate sia per il backhauling, ossia per estendere la connettività

broadband della rete dorsale alle zone limitrofe, sia per l’ultimo miglio, ovvero per

offrire servizi broadband agli utenti sia residenziali sia business locati nell’area

geografica coperta in modalità d’accesso fissa, nomadica, portatile e mobile.

Possono, inoltre, operare sia in bande licenziate sia in bande non licenziate: il

deployment nelle bande licenziate è indicato per coprire aree dense e competitive, ove

l’interferenza rappresenta il maggior problema da risolvere; il deployment nelle bande

non licenziate, invece, è indicato per coprire aree ristrette per limitare l’interferenza e

l’investimento iniziale.

Un vantaggio rilevante delle tecnologie WiMAX è la maggiore flessibilità nel

deployment dell’infrastruttura di rete, grazie alla possibilità di definire l’ampiezza del

canale, la tipologie del duplexing, le tecniche di trasmissione.

1.1. Le tecnologie 802.16

Le tecnologie 802.16 si basano sullo standard IEEE 802.16.

La prima versione dello standard IEEE 802.16, ratificata nel 2001 e concepita per

applicazioni FBWA (Fixed Broadband Wireless Access), supporta trasmissioni in

scenari LOS (Line Of Sight) nel range delle bande licenziate da 10 a 66 GHz e non

consente né la portabilità né la mobilità.

La successiva versione IEEE 802.16–2004 opera nella banda 2-11 GHz anche in scenari

NLOS (Non-Line Of Sight) e con accesso nomade, consentendo l’utilizzo di SU indoor;

supporta, inoltre, come opzione la sottocanalizzazione in uplink.

7

Figura 1 – Differenza tra LOS ed NLOS.

Infine la versione IEEE 802.16e, approvata il 7 Dicembre 2005, include le precedenti

versioni dello standard e aggiunge alcune funzionalità, quali l’handoff e il power saving,

per supportare l’accesso portatile e mobile, il MIMO, l’AAS e gli STC, per migliorare

le prestazioni del sistema. Per poter meglio supportare la mobilità, inoltre, è implementa

una nuova tecnica di trasmissione, la SOFDMA (Scalable Orthogonal Frequency

Division Multiple Access), che, però, non è compatibile né con la modulazione OFDM

né con la modulazione OFDMA (Orthogonal Frequency Division Multiple Access).

La

Tabella 1 riassume le principali caratteristiche tecniche delle tecnologie 802.16, basate

sia sulla versione 802.16-2004 sia sulla versione 802.16e. Per ogni tecnologia, è

indicato il range frequenziale e lo scenario operativo, la velocità di trasmissione in

corrispondenza di una determinata canalizzazione, la tecnica di trasmissione supportata,

il protocollo d’accesso multiplo, il formato del duplexing, le possibili ampiezze di

banda del canale e l’efficienza spettrale del sistema. Una descrizione dettagliata di tali

parametri è fornita nel seguito.

Come si evince dalla

Tabella 1, le tecnologie 802.16 consentono una maggiore flessibilità di deployment, in

quanto possono operare in diverse bande frequenziali e con una diversa canalizzazione

secondo la disponibilità dello spettro, supportano differenti tecniche di trasmissione in

8

funzione del tipo d’accesso e dello scenario, possono lavorare sia in TDD sia in FDD

(Frequency Division Duplexing) in relazione al range frequenziale in cui operano e al

tipo di servizio da offrire.

802.16-2004 802.16e

Approvato Giugno 2004 Dicembre 2005

Banda 2 – 11 GHz 2 – 11 GHz per l’accesso fisso

2 – 6 GHz per l’accesso mobile

Scenario operativo LOS/NLOS LOS/NLOS

Velocità di trasmissione 75 Mbps in 20 MHz 75 Mbps in 20 MHz per l’accesso fisso

15 Mbps in 5MHz per l’accesso mobile

Tecnica di trasmissione OFDM (256 sottoportanti),

OFDMA (2048 sottoportanti) OFDM, OFDMA, SOFDMA

Accesso multiplo TDMA, OFDMA TDMA, SOFDMA

Formato del duplexing TDD/FDD TDD/FDD

Ampiezza di banda del canale Variabile tra 1.25 MHz e 20 MHz Variabile tra 1.25 MHz e 20 MHz

Efficienza spettrale 3.75 bps/Hz in 20 MHz 3.75 bps/Hz in 20 MHz per l’accesso fisso

3 bps/Hz in 5MHz per l’accesso mobile

Compatibilità con 802.16-2004 No, se si usa la modulazione SOFDMA

Tabella 1 – Principali caratteristiche delle tecnologie 802.16

1.2. Come lavorano le tecnologie 802.16

1.2.1. Bande di frequenza

Come indicato nella

Tabella 1 e nella Figura 2, le tecnologie 802.16, basate sulla versione 802.16-2004,

operano nel range frequenziale tra 2GHz e 11GHz; le tecnologie 802.16, basate sulla

versione 802.16e, invece, operano nel range frequenziale compreso tra i 2GHz e gli

11GHz nel caso di accesso fisso e nel range frequenziale tra 2GHz e 6GHz nel caso di

accesso mobile.

9

Figura 2 – Range frequenziale per applicazioni 802.16

1.2.2. Tecnica di Trasmissione e Protocollo di Accesso

La tecnologia 802.16-2004 supporta due diverse tecniche di modulazione/accesso

multiplo:

OFDM con TDMA (Time Division Multiple Access)

La modulazione OFDM è una trasmissione multiportante: il segnale è suddiviso in più

sottocanali a banda stretta trasmessi simultaneamente su diverse sottoportanti, il cui

numero definisce la dimensione del simbolo OFDM, ossia della FFT (Fast Fourier

Transform). Come mostrato in Figura 3, tali sottocanali sono parzialmente sovrapposti

ma ortogonali in modo da ridurre l’interferenza tra canali adiacenti e massimizzare

l’efficienza spettrale. La modulazione OFDM introduce principalmente due vantaggi. In

primo luogo, poiché i sottocanali sono a banda stretta, essa consente di operare anche in

ambienti Near NLOS, ove il percorso diretto tra trasmettitore e ricevitore è parzialmente

occupato dalla presenza di ostacoli come alberi, edifici, montagne, colline e altre

strutture o oggetti naturali o artificiali, riducendo così il problema del multipath. In

secondo luogo, essa offre un maggior controllo delle richieste di potenza dell’utente e

una maggiore flessibilità per l’accesso degli utenti.

Nella tecnologia 802.16-2004, il simbolo OFDM è costituito da 256 sottoportanti di cui

8 sono pilota, 192 dati, e 56 virtuali.

10

Figura 3 – Rappresentazione temporale-frequenziale dell’OFDM

Nel TDMA l’accesso al canale radio è tipicamente diviso in time slot assegnati a utenti

diversi: ciascun utente trasmette esclusivamente durante il time slot che gli è stato

assegnato, con la modulazione OFDM, e utilizza l’intera banda del canale. Affinchè

vengano limitati i problemi di interferenza tra utenti che trasmettono in time slot

consecutivi, è necessario avere una sincronizzazione perfetta e considerare un intervallo

di guardia durante il quale nessuno può trasmettere, come mostrato in Figura 4.

Figura 4 – Schema del TDMA

L’approccio OFDM/TDMA ha il vantaggio di ridurre la complessità ed i costi dei

dispositivi, ma ha lo svantaggio di non supportare un numero elevato di utenti, per poter

contenere i ritardi tra due trasmissioni consecutive relative allo stesso utente.

OFDMA con TDMA

L’OFDMA ha lo stesso principio di funzionamento della FDMA (Frequency Division

Multiple Access), in quanto le sottoportanti sono assegnate ad utenti differenti in

funzione delle condizioni del canale e della domanda di capacità, come mostrato nella

Figura 5; ma a differenza della FDMA, essa consente di limitare l’interferenza tra gli

11

utenti grazie all’ortogonalità tra le sottoportanti. Le sottoportanti, escluse le virtuali,

sono divise in sottogruppi, il cui numero varia a seconda il caso si consideri il downlink

o l’uplink, e in ciascun sottogruppo le sottoportanti appartengono a sottocanali

differenti. Poiché ciascun sottocanale ha una sola sottoportante per ogni sottogruppo, il

numero totale di sottoportanti di un sottocanale è proprio pari al numero di sottogruppi.

Per ottenere una diversità frequenziale e, quindi, una maggiore immunità al multipath,

l’allocazione delle sottoportanti relative a ciascun sottocanale avviene mediante un

processo pseudo-casuale. Nella tecnologia 802.16-2004 il numero totale di sottoportanti

è 2048, il numero di sottocanali è 32 e il numero di sottogruppi è 48 in down link e 53

in up link.

Figura 5 – Schema della OFDMA

Nel TDMA l’accesso multiplo è esteso anche alla dimensione temporale, in quanto

l’utente può trasmettere esclusivamente nel time slot che gli è stato assegnato e può

usare solo le sottoportanti assegnate.

L’approccio OFDMA/TDMA consente di supportare un maggior numero di utenti con

ritardo minore rispetto all’approccio OFDM/TDMA. Grazie alla sottocanalizzazione

introdotta dalla modulazione OFDMA, inoltre, si ha una gestione più efficiente delle

risorse, in funzione delle esigenze degli utenti e delle condizioni del canale. In particolar

modo, in up link la sottocanalizzazione consente sia di ridurre la massima potenza

trasmessa da ciascun utente, poichè può trasmettere solo nel sottocanale assegnato, sia

di allocare la potenza all’utente a seconda le codizioni del canale, ossia un livello

12

elevato di potenza è allocato agli utenti più svantaggiati (posti ad una distanza maggiore

dalla BS oppure dotati di SU indoor).

Il principale neo dell’approccio OFDMA/TDMA sono i costi elevati dei dispositivi

dovuti ad una maggiore complessità realizzativa.

La tecnologia 802.16e, in aggiunta alle tecniche di trasmissione/accesso multiplo

previste per la tecnologia 802.16-2004, introduce la Scalable OFDMA (SOFDMA), che

consente di supportare meglio l’accesso mobile, con ottime prestazioni in diversi

scenari operativi. La modulazione SOFDMA è una variante della modulazione

OFDMA: essa, infatti, implemeta tutte le funzionalità della modulazione OFDMA e

aggiunge la scalabilità, in quanto il numero delle sottoportanti non è costante, come nel

caso della OFDMA, ma varia a seconda dell’ampiezza di banda del canale considerato,

in modo tale da mantenere costante la spaziatura tra le sottoportanti stesse, come

illustrato nella Figura 6. Questo da un lato consente di migliorare l’efficienza spettrale

nei canali con un’elevata ampiezza di banda, poiché si ha un numero di sottoportanti

maggiore; dall’altro lato permette di ridurre i costi dei dispositivi nel caso di

deployment in canali con una piccola ampiezza di banda, in quanto il numero di

sottoportanti è minore. E’ bene osservare che le modulazioni OFDMA e SOFDMA non

sono compatibili e, quindi, due terminali, uno basato sulla modulazione OFDMA e

l’altro sulla SOFDMA, non possono comunicare tra loro.

Figura 6 – Schema della SOFDMA

La Tabella 2 e la

13

Tabella 3 indicano le velocità di trasmissione supportate dalla OFDM, con 256

sottoportanti, e dalla OFDMA, con 2048 sottoportanti, al variare dell’ampiezza di banda

del canale, della modulazione e del rate del codice. In entrambi i casi, si è considerato

un rapporto di guardia, definito come il rapporto tra l’intervallo di guardia e l’intervallo

utile, pari a 1/32.

Velocità di trasmissione [Mbps] Ampiezza di

banda del

canale [MHz]

QPSK

LOW

(1/2)

QPSK

HIGH

(3/4)

16 QAM

LOW

(1/2)

16 QAM

HIGH

(3/4)

64 QAM

LOW

(2/3)

64 QAM

HIGH

(3/4)

3.5 2.08 4.37 5.82 8.73 11.88 13.09

7.0 4.15 8.73 11.64 17.45 23.75 26.18

10.0 8.31 12.47 16.63 24.94 33.25 37.40

Tabella 2 – Velocità di trasmissione supportate dalla OFDM con 256 sottoportanti

Velocità di trasmissione [Mbps] Ampiezza di

banda del

canale [MHz]

QPSK

LOW

(1/2)

QPSK

HIGH

(3/4)

16 QAM

LOW

(1/2)

16 QAM

HIGH

(3/4)

64 QAM

LOW

(2/3)

64 QAM

HIGH

(3/4)

3.5 2.91 4.36 5.82 8.73 11.64 13.09

7.0 5.92 8.73 11.64 17.45 23.27 26.19

10.0 8.38 12.57 16.76 25.13 33.51 37.70

Tabella 3 – Velocità di trasmissione supportate dalla OFDMA con 2048 sottoportanti

Come si evince dalla Tabella 2 e dalla

Tabella 3, la velocità di trasmissione aumenta all’aumentare dell’ampiezza del canale o

del livello della modulazione, ovvero fissata la canalizzazione, a modulazioni di ordine

maggiore corrispondono data rate più elevati; mentre fissata la modulazione, ad

ampiezze di banda maggiori corrispondono data rate più elevati.

Si prenda in esame il caso della tecnica di trasmissione OFDM (Tabella 2): considerata

un’ampiezza di banda di 7MHz, alla modulazione High 64QAM corrisponde una

velocià di trasmissione di 26.18Mbps, mentre alla Low QPSK corrisponde una velocità

di trasmissione di 4.15Mbps. Se, invece, si considera la modulazione Low QPSK, alla

canalizzazione di 3.5MHz corrisponde un data rate di 2.08 Mbps mentre alla

canalizzazione di 7MHz corrisponde un data rate di 4.15Mbps.

14

Tutte le tecnologie 802.16 utilizzano l’AMC (Adaptive Modulation and Coding).

Questa funzionalità permette di migliorare le prestazioni, ottimizzando sia il throughput

sia il range di copertura. L’AMC, infatti, prevede una scelta dinamica della

modulazione e del rate del codice per ogni utente, a seconda delle condizioni del link

radio. Quando il livello del segnale ricevuto è basso, come nel caso di utenti molto

distanti dalla BS, il sistema sceglie automaticamente una modulazione più robusta ma

meno efficiente in termini di capacità (ad esempio la QPSK Low), in modo da

mantenere la probabilità di errore pari al target fissato. Quando invece il livello del

segnale ricevuto è elevato, sono scelte modulazioni di ordine maggiore (come la

64QAM High) senza aumentare la probabilità di errore.

La Figura 7 descrive il concetto di AMC in presenza di shadowing. Lo shadowing tiene

conto della distribuzione casuale degli ostacoli tra il trasmettitore e il ricevitore e,

dunque, due punti posti ad una stessa distanza dal trasmettitore sperimentano un

differente canale di propagazione. Di qui, la forma irregolare delle zone di copertura

relative alle diverse modulazioni. È bene osservare che se, invece, non si tiene conto

dello shadowing, le zone di copertura relative alle diverse modulazioni altro non sono

che dei cerchi concentrici.

Figura 7 – AMC in presenza di shadowing

1.2.3. Formato di Duplexing

15

Le tecnologie 802.16 supportano sia il TDD sia il FDD, consentendo una maggiore

flessibilità nel deployment di rete.

Nel TDD la tratta in down link (riferita alla comunicazione tra BS e SU) e quella in up

link (riferita

alla comunicazione tra SU e BS) operano nella stessa banda frequenziale in differenti

tempi di connessione, alternando la trasmissione del frame di downlink e di uplink,

come è illustrato in Figura 8.

Poiché tale alternanza è molto rapida, si ha la percezione che il canale sia attivo sia in

up link che in down link allo stesso istante. Per quanto detto in precedenza, il TDD è

indicato per i servizi che hanno un volume di traffico di tipo asimmetrico nelle due

diverse tratte, come ad esempio l’accesso ad internet.

Figura 8 – Schema del TDD

Nel FDD i segnali in downlink e in uplink sono trasmessi simultaneamente su due

canali frequenziali differenti, come mostrato in Figura 9, e questo determina un uso

inefficiente delle risorse, qualora il traffico sia asimmetrico, poiché gli spettri down link

e up link sono inutilizzati per molto tempo.

16

Figura 9 – Schema del FDD

È doveroso, a questo punto, evidenziare le differenze tra il TDD e il FDD. Mentre il

TDD è più indicato nel caso di traffico asimmetrico (accesso ad internet), negli scenari

ove non è disponibile una coppia di canali oppure nel deployment in bande non

licenziate; il FDD, invece, è più opportuno nel caso di traffico simmetrico (VoIP) o nel

caso di deployment in bande licenziate che richiedono esplicitamente un suo utilizzo.

Ne consegue, dunque, che il FDD è una soluzione più costosa rispetto al TDD, sia per i

dispositivi più complessi sia per i costi di licenza.

1.2.4. Handoff e Roaming

Al fine di garantire la continuità delle applicazioni negli scenari mobili, la versione

802.16e implementa l’handoff. Con il termine “handoff” si designa il processo di

commutazione da una BS ad un’altra di una chiamata in corso o di una sessione dati,

quando l’utente è in movimento.

Questo meccanismo può essere sia soft sia hard. Nel primo caso la connessione alla

“vecchia” BS è interrotta soltanto dopo aver stabilito la connessione con la “nuova” BS

(make-before-break); nel secondo caso, invece, la connessione alla “vecchia” BS è

interrotta prima di avere stabilito la connessione con la “nuova” BS (break-before-

17

make). Poichè l’handoff soft riduce la latenza, esso è più indicato per servizi real time,

come il VoIP, mentre l’handoff hard è più idoneo per servizi non real time, quali i

servizi dati.

Una ulteriore funzionalità che le tecnologie 802.16 possono supportare è il roaming, che

consente ad un utente di connettersi alla rete di un operatore diverso da quello con cui

ha sottoscritto l’abbonamento, come avviene nelle reti cellulari.

1.2.5. Funzionalità opzionali

Le tecnologie 802.16, sia 802.16-2004 che 802.16e, supportano alcune funzionalità

opzionali, quali gli STC e l’AAS:

• Space Time Code (STC): l’informazione è codificata da più antenne in

trasmissione sia nella dimensione spaziale sia nella dimensione temporale in modo

da ottenere un guadagno di diversità e di codifica rispetto ad un sistema che utilizza

una sola antenna.

• Adaptive Antenna System (AAS): grazie alla combinazione di un array di antenne

e la capacità di processare segnali digitali, l’AAS può automaticamente cambiare la

direzione del fascio di radiazione a seconda delle condizioni in modo da

minimizzare dinamicamente l’interferenza, massimizzare la ricezione del segnale

voluto e migliorare la gestione della potenza del sistema e dell’allocazione

spettrale.

18

Figura 10 – Adaptive Antenna System.

La tecnologia 802.16e, inoltre, supporta anche il MIMO. Nei sistemi MIMO sia il

trasmettitore che il ricevitore sono equipaggiati con più antenne per migliorare la QoS

ed aumentare il throughput.

È bene osservare che le funzionalità descritte da un lato permettono di aumentare le

prestazioni di un sistema in termini di qualità del servizio e di throughput, ma dall’altro

lato determinano una maggiore complessità del sistema e, quindi, costi più elevati.

2. Progetto WEIRD

Titolo completo : WiMAX Extension to Isolated Research Data networks

Acronimo : WEIRD

Obiettivo strategico : IST- 5 - 2.5.6 Research Networking Testbed

19

2.1. Sintesi del Progetto

WEIRD è un progetto integrato della durata di 24 mesi volto all’implementazione di

piattaforme di sperimentazione utilizzando la tecnologia WiMAX con l’obiettivo di

permettere ad aree isolate e/o impervie di potersi connettere al network di ricerca

GEANT2.

Il consorzio del progetto è costituito da aziende leader nel settore delle

telecomunicazioni, comunità scientifiche - che testano il sistema -, e reti europee

nazionali di ricerca - che forniscono la connettività e supportano i risultati del progetto.

WEIRD punta a ricoprire un ruolo di primo piano nella standardizzazione

dell’integrazione del WiMAX nelle reti di nuova generazione. Questo risultato sarà

ottenuto attraverso la costruzione di 4 piattaforme europee di sperimentazione collegate

attraverso GEANT2. Il piano di attuazione prevede un’analisi dei requisiti operata

principalmente dalle comunità scientifiche, il mondo accademico e gli operatori di rete.

La domanda scenari richiesto dalla comunità di utenti e che sarà tra i principali driver

del sistema sono classificati in 3 gruppi:

20

• attività di monitoraggio sismico e vulcanico;

Figura 11 – Scenario di monitoraggio sismico e vulcanico.

• prevenzione degli incendi;

Figura 12 – Scenario di video sorveglianza mobile.

• tele-medicina.

21

Figura 13 – Scenario di tele-medicina (diagnosi remota).

WEIRD simulerà gli scenari di applicazione sulle piattaforme di sperimentazione

implementate, definendo prototipi e convalidando i progressi nel controllo e gestione di

rete, e le versioni perfezionate del WiMAX. Le caratteristiche che il sistema WEIRD

convaliderà nel corso del progetto comprendono:

- QoS: gestione delle risorse e di accesso;

- autenticazione, autorizzazione e accounting (AAA), e sicurezza;

- consapevolezza ambientale;

- sostegno alla piena mobilità.

Pertanto, lo stato di avanzamento della prossima generazione di reti sarà perfezionato e

gli strati specifici del WiMAX saranno analizzati a fondo e migliorati.

Il consorzio attende i risultati del progetto per avere un forte impatto sulle attività

internazionali in corso, per questo motivo è prevista un efficace piano di diffusione e

valorizzazione sia per le imprese interne che per il mondo esterno.

2.2. Obiettivi del Progetto

2.2.1. Portata del Progetto

Negli ultimi anni le Wireless Metropolitan Area Networks hanno registrato una forte

diffusione, a causa della necessità di raggiungere un numero sempre maggiore di

comunità di utenti - eventualmente isolate -, e di superare le barriere di costo delle

tecnologie cablate. Questa tendenza ha spianato la strada principalmente all'uso di

soluzioni proprietarie, alcune delle quali basate su sistemi WiFi aggiornati e potenziati,

altre incentrate su connessioni wireless punto-punto basate su tecnologie RF. Questa

progressione sub-ottimale ha stimolato gli organismi di normalizzazione pertinenti a

lavorare all'introduzione di nuovi standard aperti, facilitando grandi economie di scala e

di vasta accettazione da parte del mercato: in questo contesto sono stati definiti gli

standard IEEE 802.16 (noto anche come WirelessMAN) ed ETSI HiperMAN.

22

Al fine di sostenere le certificazioni dello standard IEEE 802.16-2004, è stato quindi

costituito un consorzio per l’interoperabilità a livello mondiale per l’accesso a

microonde - Worldwide Interoperability for Microwave Access (WiMAX).

Nel frattempo, la maggior parte delle iniziative di ricerca a livello mondiale ha iniziato a

concentrarsi sulle architetture di rete IP in grado di disaccoppiare gli strati di

Applicazione e Controllo da quello sottostante di Trasporto. L'obiettivo principale di

questi studi e sviluppi è la perfetta integrazione end-to-end delle diverse tecnologie di

rete: nelle più avanzate architetture di rete ciò è comunemente raggiunto attraverso

speciali "strati di convergenza". Per quanto riguarda lo strato di Trasporto, questi strati

di convergenza sono in grado di interfacciarsi con le diverse tecnologie di base per

mezzo di specifici drivers; verso lo strato di Controllo, offrono funzionalità specifiche

per la QoS /gestione delle risorse, l’autenticazione d'accesso, la sicurezza, ecc.

E’ stato dimostrato che i meccanismi di controllo attuati negli "strati di convergenza"

migliorano le prestazioni della rete, sia in termini di utilizzo/consumo delle risorse che

di soddisfazione degli utenti finali, in quanto semplificano la previsione della migliore

configurazione di rete per ciascuna richiesta di servizio in ingresso.

Il progetto WEIRD mira a valorizzare e migliorare la tecnologia WiMAX nello strato di

convergenza di architetture di rete eterogenee, al fine di far fronte alle esigenze future

della comunità di utenti di ricerca e di costruire piattaforme di sperimentazione che

consentano alle reti europee di ricerca GÈANT, GÈANT2 e alle reti nazionali per la

ricerca, di essere raggiungibili da zone remote o isolate.

2.2.2. Obiettivi scientifici e tecnologici

Il progetto WEIRD implementerà e convaliderà una piattaforma di sperimentazione con

i più avanzati strati di convergenza e di controllo e li migliorerà integrandoli con una

versione perfezionata della tecnologia WiMAX. Ciò fornirà alla comunità scientifica

una rete di accesso a banda larga basata sulla tecnologia WiMAX e direttamente

collegata al GÈANT.

23

Al fine di realizzare una tale infrastruttura di sperimentazione capace di integrarsi

agevolmente con la GÈANT e la NREN, WEIRD deve raggiungere i seguenti obiettivi

tecnici:

1. Migliorare la tecnologia WiMAX:

• Estensioni dello strato di convergenza per il supporto WiMAX (driver

WiMAX);

• Perfezionamento degli strati Data Link e PHY;

• Supporto alla QoS sia in bande con licenza, che in quelle esenti;

• Handover e meccanismi di controllo di accesso nello strato di convergenza per il

WiMAX;

• Interoperabilità con gestione della mobilità;

• Tecniche di Radio-on-fiber (RoF) per la rete di distribuzione WiMAX.

2. Migliorare lo strato di controllo della rete IP:

• Studio e simulazioni sulla pianificazione ottimale della rete, configurazione dei

dispositivi e degli accessori dello strato fisico per sistemi di antenne adattative,

capaci di garantire QoS in uno scenario di competizione tra reti di trasmissione

non cooperative in bande esenti da licenza, sia in condizioni di LOS che non-

LOS (NLOS);

• Definizione di un insieme di linee guida per la disposizione permanente

dell’architettura WEIRD in GÈANT/GÈANT2 e NREN.

3. Sostenere studi e divulgare raccomandazioni:

• Studio e simulazioni sulla pianificazione ottimale della rete, configurazione dei

dispositivi e delle procedure di controllo di accesso al mezzo distribuito, capaci

di garantire QoS in uno scenario di competizione tra reti di trasmissione non

cooperative in bande esenti da licenza, sia in condizioni di LOS che non-LOS

(NLOS);

• Definizione di un insieme di linee guida per la disposizione permanente

dell’architettura WEIRD in GÈANT/GÈANT2 e NREN.

24

4. Valutare gli scenari: le comunità scientifiche partners del progetto (Dipartimento di

prevenzione incedi dell’UoC, Associazione OASI Maria SS., sito scientifico di

monitoraggio del Vesuvio, ufficio meteorologico islandese, Università),

descriveranno i loro scenari di applicazione che guideranno i requisiti di sistema e

le specifiche:

• WiMAX come soluzione per reti di ricerca in aree remote;

• Accesso a banda larga per postazioni remote fisse di ricerca per le quali le

soluzioni cablate non sono efficaci in termini di costi;

• Accesso a banda larga per dispositivi personali nomadici e aggregazioni di

sistemi di raccolta dei dati da sensori in zone impervie (esempio: un vulcano);

• Accesso a banda larga per campus di ricerca estesi;

• Accesso a banda larga per la prevenzione degli incendi;

• Accesso a banda larga per il personale medico che richiede informazioni

mediche ad alta risoluzione in contesti nomadici di emergenza;

• Accesso a banda larga per applicazioni ad alta risoluzione di tele-ingegneria in

zone remote o pericolose (esempio: comando di robot a distanza e/o tele-

presenza);

25

Figura 14 – Uno scenario di applicazione di WEIRD

5. Confermare le applicazioni che la soluzione convergente di WEIRD può offrire,

compresi, tra gli altri:

• Audio e Video over IP:

o VoIP, video conferenza, e streaming video tra personale scientifico;

• Monitoraggio ambientale:

o Monitoraggio incendi e vulcani, compresi streaming dati e video da reti

di sensori e telecamere.

• Tele-medicina

o Streaming dati e video ad alta risoluzione da strumentazione medica.

2.3. Rilevanza degli obiettivi IST primari

Il progetto WEIRD si pone in primo luogo come obiettivo l’IST-5-2.5.6, una

piattaforma di sperimentazione di una rete di ricerca: essa mira a confermare lo stato

attuale della tecnologia wireless, ma anche al suo potenziamento e la sua integrazione,

al fine di prepararsi alla diffusione della prossima generazione di reti di informazione e

comunicazione in tutta Europa.

In sostanza, Il progetto WEIRD propone una connettività a banda larga basata su una

tecnologia wireless che fornisce dei mezzi di riempimento flessibili, economicamente

efficienti, e standardizzati, di quelle lacune esistenti nei servizi a banda larga, non

previsti nel mondo “cablato”.

Il presente lavoro è anche complementare e di sostegno delle attività svolte in materia di

infrastrutture di ricerca sulle reti di comunicazione ad alta capacità e ad alta velocità,

per tutti i ricercatori in Europa (GÉANT), che offre una vera e propria tecnologia di

connessione in grado di aggiungere nuovi NRNs alla rete GÉANT. Per esempio, un

backhaul senza fili è sicuramente la soluzione migliore, in termini di costi e tempi di

disposizione necessari, in presenza di ostacoli fisici, rispetto ad uno di tipo cablato. Con

la tecnologia wireless proposta, una NRN che è effettivamente isolata dal punto di vista

26

del cablaggio, o che appartiene ad un paese in via di sviluppo, può essere facilmente

integrata nella rete di ricerca GÉANT. Ciò consente a ricercatori di terze parti di

usufruire di infrastrutture di prova aperte, compresi gli ambienti di dimostrazione,

favorendo la sinergia e il confronto dei risultati di ricerca, facilitandone la loro

diffusione.

Come detto in precedenza, le reti di ricerca non sono gli unici soggetti ai quali il

progetto WEIRD si rivolge. Vi sono diversi scenari del mondo reale e attività produttive

che possono trarre vantaggio dalla tecnologia proposta. Prima di tutto i clienti

residenziali dei servizi a banda larga e le aree sotto-servite: limiti pratici impediscono

alla tecnologia DSL e via cavo di raggiungere molti potenziali clienti a banda larga,

pertanto molte aree urbane e suburbane non possono essere adeguatamente servite. La

stesura dei cavi ha un costo rilevante, non coperto successivamente se il servizio a

banda larga è offerto in una zona con bassa densità di abbonati. Una soluzione wireless

sembrerebbe più adatta, ma purtroppo l'attuale generazione di sistemi wireless è

relativamente costosa per le implementazioni di massa, in quanto, senza uno standard, è

difficile raggiungere economie di scala. Questa inefficienza di costo potrà essere risolta

tramite la promozione di sistemi basati su standard, come sostenuto nel progetto

WEIRD. Gli standard sono importanti per l'industria del wireless, perché consentono

economie di scala in grado di ridurre il costo degli apparati, garantire l'interoperabilità, e

la riduzione dei rischi di investimento per gli operatori.

Considerando gli ambienti di produzione, la connettività a banda larga ad Internet

rappresenta, per molte imprese, una missione critica nella misura in cui queste

organizzazioni possono effettivamente raggiungere e rendere disponibili i servizi a

banda larga in zone in cui la società telefonica locale potrebbe impiegare molto tempo

per farlo. Uno degli obiettivi del progetto WEIRD è quello di rimuovere questa

discriminazione geografica basata sulla disponibilità di servizi a banda larga, al fine di

incoraggiare la nascita e la crescita di nuovi settori di attività per le imprese. In questo

contesto, il progetto WEIRD, promuovendo le WMAN (Wireless Metropolitan Area

27

Network), mira anche a superare l’attuale copertura delle WLAN (Wireless Local Area

Network), consentendo così non solo una comunicazione all'interno di un singolo

edificio, ma anche tra le diverse sedi di una società presenti all’interno dell’area di

copertura del segnale.

Inoltre, il progetto WEIRD mira a integrare, testare, e dimostrare la validità della

tecnologia di accesso wireless WiMAX chiamata a risolvere le difficoltà nelle

implementazioni dell’ultimo miglio. I WISP (Wireless Internet Service Provider)

richiedono tecnologie wireless che rendono possibile l'accesso in area metropolitana. I

tre aspetti principali che compongono l'area metropolitana di accesso sono i backhaul,

l’ultimo miglio, e l’estensione dell’area di copertura. L’ultimo miglio wireless e

l’estensione dell’area di copertura di solito utilizzano uno standard opportunamente

modificato (IEEE 802.11), ma la necessità di uno specifico standard è evidente e il

progetto WEIRD contribuisce per la sua istituzione: tecnologie radio standard aperte

offrono vantaggi a WISP e utenti ; Molti settori dell’industria dell’innovazione sono alla

guida delle tecnologie di rete wireless a banda larga.

L'obiettivo di WEIRD è quello di integrare WiMAX in contesti di reti eterogenee,

definendo le interfacce con gli strati di convergenza. L'autenticazione, l'autorizzazione,

l’accounting, il roaming, la sicurezza, la QoS, e la gestione delle risorse saranno i

principali campi su cui il progetto WEIRD si concentrerà, e la linea che verrà seguita

per realizzare nuovi algoritmi sarà basata su avanzate teorie matematiche e di controllo,

che permetteranno per il raggiungimento di un alto grado di autonomia della rete.

Infine, considerando i contesti scientifici, il progetto WEIRD sostiene una tecnologia

che sarà molto utile in tutte quelle situazioni in cui la presenza umana non può essere

garantita con continuità. Questi scenari includono tutte le attività di monitoraggio in

zone remote o pericolose, come le postazioni di monitoraggio vulcaniche, di

prevenzione degli incendi, o semplicemente la comunicazione tra zone isolate, come le

piattaforme in mare aperto. Pertanto il progetto WEIRD promuove l'interoperabilità tra

le varie soluzioni scientifiche e industriali e questo significa anche la possibilità di

28

sperimentazione su larga scala con impostazioni reali per promuovere l'interoperabilità

tra i domini tecnologici eterogenei, con particolare attenzione alle nuove tecnologie

wireless.

2.4. Stato di avanzamento

Questo paragrafo descrive lo stato di avanzamento delle tecnologie d’interesse per il

progetto WEIRD: nella sezione 2.4.1 sono descritte le attività di standardizzazione in

corso; mentre nella sezione 2.4.2 è descritta brevemente l’attività accademica di ricerca

in corso.

Il paragrafo successivo, il 0, descrive alcune limitazioni dello stato della tecnica che

potranno essere superate col contributo di WEIRD.

2.4.1. Attività di standardizzazione in corso

IEEE 802.16 e il WiMAX Forum

IEEE 802.16 tratta di un gruppo di standard di comunicazione wireless a banda larga

per reti in area metropolitana (MAN). Lo standard 802.16 originale, pubblicato nel

dicembre 2001, ha precisato sistemi wireless a banda larga punto-multipunto fissi che

operano con licenza nello spettro 10-66GHz. Un emendamento, l’802.16a, approvato

nel gennaio 2003, ha specificato le estensioni NLOS (non-line-of-sight) nello spettro 2-

11 GHz, offrendo fino a 70 Mbps a distanze di 31 miglia per essere utilizzate in

applicazioni a bassa latenza come voce e video. Ufficialmente chiamato WirelessMAN

™, lo standard IEEE 802.16 fornisce una tecnologia valida per l’ultimo miglio,

consentendo un’alternativa wireless al cablaggio per i servizi a banda larga.

29

Sebbene i primi emendamenti allo standard riguardino soltanto le connessioni wireless

fisse, un ulteriore emendamento, IEEE 802.16e, consente connessioni per dispositivi

mobili.

Un consorzio di aziende del settore wireless, tra cui Intel, Proxim e Nokia, ha formato,

nell’aprile del 2001, un gruppo di difesa del WiMAX 802.16. Lo scopo

dell'organizzazione è quello di promuovere attivamente e certificare la compatibilità e

l'interoperabilità dei dispositivi basati sullo standard 802.16, e di sviluppare tali

dispositivi per il mercato.

La principale missione del consorzio WiMAX è quella di consentire una più ampia

penetrazione della banda larga nelle aree che per tempo, costo e raggiungibilità non

possono essere servite con soluzioni alternative. Tuttavia, esso contribuisce fornendo

ulteriori estensioni allo standard, come nel caso di IEEE 802.16e.

ETSI Broadband Radio Access Networks (BRAN) – HIPERACCESS

Lo standard HIPERACCESS è mirato all’accesso fisso wireless multimediale a banda

larga in alta frequenza (40,5-43,5 GHz). HIPERACCESS è stato definito per l’accesso

wireless punto-multipunto fisso ad alta velocità e ad alta qualità, fino a 120 Mbps (25

Mbps tipica velocità dati) di utenti residenziali e piccole imprese ad un'ampia varietà di

reti, comprese le reti UMTS, ATM, e reti basate su IP. Il sistema è in grado di

supportare applicazioni multimediali e sarà gestito con licenza in bande di frequenza

oltre gli 11GHz (26, 28, 32, 42 GHz) con alta efficienza spettrale sotto condizioni LOS

(Line Of Sight).

HIPERACCESS presenta diversi aspetti comuni con IEEE 802.16, ma si basa su PDU

di dimensione fissa (ottimizzazione per il traffico CES e ATM, nonché IP), mentre

IEEE 802.16 su PDU a dimensione variabile (ottimizzazione solo per stazioni IP).

Tuttavia, l'ETSI BRAN coopera strettamente con IEEE-SA (Gruppo di lavoro 802.16)

per armonizzare gli standard di interoperabilità di reti multimediali ad accesso wireless

fisso a banda larga.

30

ETSI Broadband Radio Access Networks (BRAN) – HIPERMAN

HIPERMAN sarà un sistema interoperabile di accesso wireless a banda larga fissa

operativo a frequenze radio tra 2 GHz e 11 GHz. Lo standard HIPERMAN è progettato

per rispondere alle esigenze di accesso wireless fisso delle PMI e degli utenti

residenziali, ed utilizza il MAC (DLC e CL) dello standard IEEE 802.16-2001. E 'stato

sviluppato in stretta collaborazione con IEEE 802.16, pertanto lo standard HIPERMAN

e un sottoinsieme di IEEE 802.16a-2003 interoperano senza problemi. HIPERMAN è in

grado di sostenere ATM, anche se l'obiettivo principale è il traffico IP. Esso offre varie

categorie di servizi, piena qualità di servizio, gestione veloce del controllo di acceso,

sicurezza, adattamento veloce della codifica, della modulazione, e della potenza di

trasmissione alle condizioni di propagazione, e la capacità di operare in NLOS.

HIPERMAN supporta inoltre l’allocazione di frequenze sia in FDD che in TDD. Tutto

questo è realizzato con un numero minimo di opzioni per semplificare

l'implementazione e l'interoperabilità. HIPERMAN può essere considerato un

concorrente equivalente al WiMAX in Europa. Tuttavia, i due gruppi si relazionano

attivamente per rendere possibile la loro piena interoperabilità.

3GPP IMS

Il sistema 3GPP nella sua prima versione (R99), è stato progettato per essere

compatibile con le attuali infrastrutture GSM a commutazione di circuito. Tuttavia, il

sistema 3GPP sta evolvendo lentamente verso una rete basata su IP, infatti le

infrastrutture a commutazione di circuito esistenti saranno superate e sostituite da

hardware basato su IP, in quanto scalabile e conveniente da installare e mantenere, a

causa della maggiore competitività del mercato. A tal proposito, attraverso le specifiche

REL-4 e REL-5, è stato introdotto il sottosistema multimediale IP (IMS), in primo

31

luogo per gestire i servizi classici ad acceso a circuito (come la voce) su IP, in secondo

luogo per gestire tutti i servizi multimediali forniti ad un abbonato. IMS utilizza il

Session Initiation Protocol (SIP) per instaurare, mantenere e terminare le sessioni

multimediali e voce. L'infrastruttura e il meccanismo di controllo del sistema WEIRD

saranno implementati tenendo conto della soluzione 3GPP.

ETSI TISPAN

TISPAN è il centro di competenza ETSI per le reti fisse e la migrazione da reti a

commutazione di circuito a reti a pacchetto con un'architettura comune. TISPAN è

responsabile per tutti gli aspetti di standardizzazione per il presente e il futuro, tra cui la

convergenza delle reti NGN (Next Generation Network), compresi gli aspetti di

servizio,quelli architetturali e di protocollo, studi sulla QoS, la sicurezza, su aspetti di

mobilità all'interno di reti fisse, utilizzando risorse esistenti e tecnologie emergenti.

ETSI EMTEL

Il concetto di telecomunicazioni di emergenza (EMTEL) è rivolto ad un ampio numero

di aspetti legati alla fornitura di servizi di telecomunicazioni in situazioni di emergenza.

Situazioni di emergenza possono variare da una ristretta percezione individuale di

pericolo (con la necessità di effettuare una chiamata di emergenza dovuta ad improvvisa

malattia, incidente stradale, focolaio d'incendio in casa, ecc.) a una prospettiva molto

ampia di gravi minacce alla sicurezza pubblica (situazioni di disastro a causa di eventi o

di processi, quali terremoti, inondazioni, attacchi terroristici su larga scala, ecc.).

Il concetto copre anche le esigenze di telecomunicazioni delle forze impiegate per

garantire la sicurezza pubblica, come le forze di polizia, unità antincendio, servizi di

ambulanza e di altri servizi medici e sanitari, oltre a servizi di protezione civile. Le

esigenze di telecomunicazioni da parte di tali servizi sono state finora soddisfatte da reti

32

ed apparati dedicati, spesso diversi per servizi diversi, ma con la tecnologia moderna è

sempre più possibile integrare tali servizi con i servizi pubblici di telecomunicazioni.

2.4.2. Ricerche in corso in ambito accademico

La competitività di WiMAX sul mercato e la sua effettiva realizzazione in reti di

accesso in gran parte dipendono dagli effettivi data rates raggiungibili. Tuttavia, allo

stato attuale è difficile giudicare a causa del gran numero di possibili opzioni e delle

esigenze di mercato. In realtà, a causa di tutte le potenziali opzioni (data rates,

prestazioni, ecc) descritte dagli standard, vi è attualmente una confusione significativa

circa il tipo di prestazioni che i sistemi WiMAX-compatibili debbano essere in grado di

conseguire, nonché una sostanziale mancanza di informazioni sugli aspetti relativi

all’insieme di servizi end-to-end richiesti nell’utilizzo o attraversamento di reti

WiMAX. Alcuni studi preliminari sui sistemi WiMAX-compatibili sono stati incentrati

sui reali valori di throughput e sulle prestazioni ottenute considerando soltanto una

specifica combinazione di MAC/PHY tra quelle messe a disposizione dallo standard.

Queste simulazioni e valutazioni analitiche delle prestazioni non consentono di

determinare la configurazione di sistema più adatta alle diverse condizioni di

funzionamento (backhaul WiMAX in LOS o NLOS, reti di accesso WiMAX,variante in

mobilità). Inoltre, le simulazioni e le valutazioni analitiche di queste diverse prestazioni

del sistema sono state condotte adottando modelli di traffico eccessivamente

semplificati (come processi Poissoniani di arrivo dei pacchetti di dimensioni fisse o

condizioni di saturazione), o soltanto uno altamente specifico (come un particolare

flusso video, una serie di chiamate VoIP, e così via). Inoltre, il principale obiettivo

prestazionale indagato dai diversi studi è in genere il throughput aggregato della rete;

dovrebbe dunque essere considerata una più ampia gamma di obiettivi prestazionali,

compresi il tasso perdita di pacchetti, il ritardo dei pacchetti e la sua varianza, e altri più

specifici.

33

2.5. Progressi rispetto allo stato attuale

La prevista realizzazione di tecnologia WiMAX in reti eterogenee alimentate con gli

strumenti e i meccanismi dello strato di convergenza costituisce il principale campo di

innovazione del progetto WEIRD. Il progetto cercherà di impattare il meno possibile sui

moduli architetturali maturi, concentrando l'attenzione, in questi casi, sugli aspetti di

interoperabilità necessari per costruire un sistema modulare coerente. Di conseguenza,

saranno evidenziati profondi intrecci e dipendenze tra le diverse procedure: QoS a strato

2 e strato 3, sicurezza con autenticazione e autorizzazione, accounting con misurazioni

continue dei parametri di rete, integrazione e coesistenza di diverse gerarchie di servizi

per reti private virtuali (VLAN, VPN, ecc.). La progettazione e lo sviluppo di questa

interfaccia, come pure dei drivers per lo strato di convergenza, apporteranno

miglioramenti significativi rientrando nelle specifiche dello standard.

Le dimostrazioni su piattaforme di sperimentazione distribuite delle funzionalità

progettate e realizzate coprono l'intera durata del progetto e forniranno progressive

conferme delle soluzioni WEIRD.

Il progetto WEIRD prevede di migliorare la qualità della tecnologia WiMAX e di

rafforzare il consenso del mercato. Le principali innovazioni del progetto WEIRD, o che

avranno un potenziale impatto in questo senso, comprendono:

• la definizione e l’implementazione di prototipi degli elementi di rete e

middleware necessari, fornendo soluzioni di connettività innovative per le

infrastrutture di ricerca basate su un’architettura dello strato di controllo IP

perfezionata;

• lo studio delle attuali e future tecnologie di rete e della possibilità di migliorare

le prestazioni di servizio della rete mediante soluzioni di monitoraggio. Il

monitoraggio e la definizione di profili di rete consentono la modifica dinamica dei

parametri di adattamento e, se necessario, il cambiamento della tecnologia di

accesso alla rete utilizzata, al fine di mantenere una buona esperienza dei servizi

multimediali da parte dell’utente finale;

34

• lo studio della sicurezza e della QoS sulla base di un’architettura end-to-end

IPv6: ciò è importante per sviluppare modelli e algoritmi per il supporto della QoS

e del routing, per l’autenticazione d'utente e di nodo, il rilevamento delle intrusioni,

applicati alla rete wireless di base, sia IPv4 che IPv6;

• la caratterizzazione degli scenari e delle applicazioni WiMAX inerenti le reti di

ricerca in collaborazione con i soggetti coinvolti nel progetto;

• l’implementazione di prototipi di elementi di rete secondo le applicazioni

selezionate.

Limiti dello stato attuale di avanzamento Contributo di WEIRD

Mancanza di standard per l’interazione di diversi meccanismi di segnalazione, in particolare ai confini dei domini di rete, che consentono diversi approcci alla gestione della QoS (DiffServ, priorità nello strato 2, ecc.) in scenari di accesso multi-dominio e multi-tecnologia.

Definizione di interfacce di rete generalizzate e di meccanismi (ad esempio per le interazioni tra lo strato di controllo e quello di convergenza) che consentono la negoziazione automatica degli SLA e l’invocazione di servizio ai confini dei domini di rete, basati sull’interoperabilità degli attuali meccanismi di segnalazione.

Manca l'armonizzazione tra i meccanismi di sicurezza disponibili nelle diverse tecnologie/architetture, e l’interoperabilità di procedure AAA in scenari multi-operatore.

Definizione di un quadro di riferimento per la completa integrazione di sicurezza end-to-end e procedure di AAA, al livello degli strati di controllo e di gestione, nelle sezioni di rete considerate.

Studi preliminari sui sistemi WiMAX-compatibili sono stati incentrati sui reali valori di throughput e sulle prestazioni ottenute considerando soltanto una specifica combinazione di MAC/PHY tra quelle messe a disposizione dallo standard.

Simulazioni sui possibili miglioramenti alla tecnologia WiMAX standardizzata per le applicazioni relative agli scenari selezionati saranno finalizzati a valutare le prestazioni non solo in termini di produttività, ma anche in termini di adempimento degli obblighi di servizio richiesto dalle applicazioni (VoIP, videoconferenze e streaming video , tele-medicina, e-learning, tele-ingegneria).

Reti fisse e mobili non sono pienamente integrate. L’integrazione tra reti fisse e mobili sarà perfezionata dal progetto WEIRD. Questo obiettivo sarà raggiunto tramite l'integrazione di funzioni di segnalazione estese allo strato di controllo e l’ottimizzazione dello strato di convergenza.

35

Le applicazioni non sono consapevoli dell’ambiente e delle infrastrutture.

L’adattamento delle applicazioni previsto dal progetto WEIRD ne migliora la consapevolezza ambientale. Ciò sarà ottenuto mediante l'integrazione di opportuni meccanismi per la gestione dell’allocazione di risorse.

Alcune comunità di ricerca che lavorano in zone remote o impervie, non hanno connettività a banda larga.

WEIRD comprende comunità di utenti che guidano i requisiti di sistema per permettere l'ottenimento di una soluzione in grado di estendere GEANT e risolvere il loro problema.

Architetture inesistenti o non efficaci in termini di costi per la diffusione delle reti di accesso WiMAX.

Concezione, progettazione, e convalida di sottosistemi per il massiccio dispiegamento di reti WiMAX a basso costo. Possibilità di estendere la copertura delle reti WiMAX ad ambienti di propagazione difficili, come la metropolitana.

Le attuali tecnologie internet non sono adatte all’utilizzo in situazioni di emergenza e alla copertura di aree remote.

WEIRD migliorerà l'offerta tecnologica per supportare applicazioni di emergenza e di copertura di aree remote. Il progetto fornirà connessione a banda larga e in mobilità per sperimentare la prevenzione degli incendi e il monitoraggio dei vulcani, e consente l'utilizzo di queste applicazioni in scenari di emergenza.

Tabella 4 – Progressi introdotti daWEIRD allo stato attuale di avanzamento

2.6. Piano d’implementazione strutturale e logica di WEIRD

Il piano di attuazione del progetto dura 24 mesi. Durante la prima fase è effettuata

un’analisi degli aspetti principali dello stato di avanzamento, tenendo in considerazione

le attuali attività di standardizzazione, i risultati ottenuti dalle più importanti industrie, e

dei progetti di ricerca pubblici e privati, passati e in corso. I partner del progetto che

hanno partecipato ai principali progetti di ricerca europei con risultati nel campo di

applicazione di WEIRD, analizzeranno e sfrutteranno i risultati prodotti, in modo tale da

evitare uno spreco di risorse in attività replicate.

36

Le prime attività di implementazione cominceranno in corrispondenza dal primo

pacchetto di risultati del lavoro di analisi e comporterà la consegna di una prima

versione di implementazioni al mese 12, con le applicazioni di tele-medicina e di

monitoraggio ambientale. A questo punto può iniziare l’integrazione di sistema e le

prove possono essere effettuate sulle piattaforme di test. In parallelo, le attività di

implementazione saranno sottoposte all'intera infrastruttura di test (strati di applicazione

e controllo), con funzionalità di QoS, di autenticazione e sicurezza. Il lavoro sugli strati

WiMAX specifici comprenderà l’implementazione di un adattatore WiMAX, al fine di

integrarlo in un sistema di reti eterogenee. Nel frattempo, saranno valutate e simulate

delle proposte di perfezionamento degli strati MAC e PHY.

Durante l'intero progetto, saranno promosse attività di diffusione e valorizzazione per garantire

un impatto sia all'interno che esterno del consorzio.

Infine, le attività di gestione faranno sì che gli obiettivi del progetto saranno soddisfatti in modo

efficace ed efficiente.

2.7. Attività di ricerca, sviluppo tecnologico e d’innovazione connesse

al progetto

2.7.1. Requisiti (AC2400)

Le attività descritte in precedenza portano a requisiti tecnici che dovranno essere

soddisfatti dal sistema proposto, secondo i servizi e delle applicazioni previsti nel

quadro del progetto. Nel presentare l'attività, i requisiti sono specificati e commentati.

Una vasta gamma di applicazioni (audio e video conferenza, trasferimento dei dati,

streaming multimediale, instant messaging, Web browsing) comporterà un certo numero

di requisiti diversi in termini di larghezza di banda e parametri di QoS. D'altra parte, le

condizioni al contorno in cui sarà sviluppato il sistema saranno molto variabili. Ciò

37

porterà alla definizione di una serie di requisiti che riguardano, tra gli altri, i seguenti

argomenti:

• utenti: i requisiti d’utente saranno guidati da comunità di utenti WEIRD;

• throughput: raggiungimento di un throughput elevato, con un alto livello di

efficienza spettrale e di tolleranza alle riflessioni del segnale, richiede una

tecnologia basata su un sistema di modulazione robusto;

• copertura: essendo previsto un utilizzo in condizioni ambientali avverse, sono

richieste tecnologie di ottimizzazione della copertura, tra cui le “smart antenna”.

• adattabilità dinamica alle condizioni ambientali: secondo le circostanze, il

throughput dovrebbe essere negoziato in modo dinamico (ad esempio, il passaggio

da 64 QAM a 16 QAM per aumentare la banda efficace);

• qualità del servizio: devono essere supportate caratteristiche per consentire

servizi a bassa latenza, come voce (TDM o VoIP) e video, ma anche servizi elastici,

come il trasferimento di file;

• affidabilità: deve essere garantita l’affidabilità per classe di trasporto, richiesta

dalla maggior parte dei servizi pubblici di rete;

• scalabilità: è necessario applicare un’allocazione flessibile della banda del

canale;

• sicurezza: autenticazione e la crittografia dei dati sono requisiti fondamentali

per un appalto pubblico di servizi wireless;

• mobilità: in numerosi scenari di applicazione la mobilità di utente e di

terminale sono requisiti fondamentali, che devono essere valutati tenendo conto

dello stato d’avanzamento della tecnologia WiMAX, ovvero dell'evoluzione verso

lo standard 802.16e.

38

2.7.2. Specifiche complessive di sistema (AC2500)

Quest’attività raffina il lavoro di WP2000 ed ha il ruolo importante di condurre ad

un'architettura generale che descriva la struttura WEIRD, basandosi sui risultati

consolidati di analisi dei requisiti delle attività precedentemente descritte. Nella Figura

15 è indicata una descrizione dei suoi componenti.

39

Figura 15 – Descrizione del sistema WEIRD

2.8. Progettazione ed implementazione della piattaforma di

sperimentazione dell’infrastruttura (WP3000)

Il Work Package 3000 punta a fornire la progettazione architetturale, l'integrazione dei

protocolli e dei meccanismi di controllo esistenti, e l'implementazione delle modifiche

necessarie alle applicazioni, negli strati di trasporto e di controllo di WiMAX, a

supporto dell'infrastruttura WEIRD di sperimentazione. WP3000 riceverà gli input di

base da WP2000, e in particolare da AC2200 sull'identificazione di scenari di sistema, e

da AC2500 sulle specifiche WEIRD. WP3000 conterà su cinque campi di attività:

applicazioni, strato di controllo, strato di trasporto, adattatore WiMAX, e strati specifici

WiMAX. Tutte queste attività saranno effettuate parallelamente per permettere, tramite

release progressive, le attività di test di WP5000.

2.8.1. Applicazioni (AC3100)

Questa attività definirà e adatterà le applicazioni e i relativi servizi al fine di utilizzarle

nell’infrastruttura WEIRD nelle prove definite delle comunità scientifiche. Le

applicazioni possono includere:

• applicazioni generiche come VoIP, videoconferenza su IP, incluso lo streaming

video per l'uso generico nel controllo e nella distribuzione di contenuti;

• applicazioni di tele-medicina compreso lo streaming video ad alta definizione e

streaming di dati dall'apparecchiatura medica, per le comunità di utenti clinici;

• applicazioni di monitoraggio ambientale comprese quelle per il monitoraggio

dell’attività vulcanica e la prevenzione incendi, e streaming video da reti di sensori

e videocamere per le rispettive comunità di utenti.

I requisiti finali del sistema e della rete di servizi (nel contesto fisso o mobile), basati su

tipi differenti di applicazioni software, possono essere rappresentati in una visione 3D

40

che influenzano sostanzialmente la scelta della appropriata tecnologia di rete. Le tre

dimensioni possono essere:

• grado di mobilità dell'utente;

• larghezza di banda necessaria;

• livello di QoS richiesto (per parametri come: perdita, ritardo, jitter, disponibilità,

affidabilità, ecc.).

Figura 16 – Spazio 3D dei servizi per le applicazioni

In termini di livelli di QoS garantita, la gamma di soluzioni può andare da “nessuna

garanzia" - come nei servizi IP classici di tipo Best Effort – a garanzie (dure)

deterministiche - simili ai servizi con linee dedicate virtuali. L'offerta di garanzie

statistiche quantitative o di garanzie deterministiche, richiede l’introduzione di funzioni

di controllo di ammissione nello strato di controllo per funzionare sulle interfacce di

accesso, nel momento in cui giungono nuove richieste di servizio.

41

Figura 17 – Dettaglio dell’asse della QoS

Il progetto WEIRD classificherà le applicazioni ed i servizi e considererà quelli

potenzialmente implementabili nella catena di comunicazione di un'infrastruttura

WiMAX. WEIRD studierà i livelli di QoS garantita richiesti e determinerà in quale

misura le possibili soluzioni WiMAX possono soddisfare questi requisiti.

Il lavoro di implementazione riguardo alle applicazioni comprenderà lo sviluppo di API

(Application Programming Interfaces) specifiche verso lo strato di controllo WEIRD.

Dal lato dell’applicazione, l'effetto di una tale attività provocherà un adattamento delle

applicazioni comuni disponibili per lo streaming video, la videoconferenza, la tele-

medicina, il traffico VoIP, ecc.. Dal lato della rete, questa API rappresenterà

un'interfaccia verso lo strato superiore necessaria per aprire lo strato di controllo

WEIRD al mondo esterno e in modo specifico, per permettere l’interoperabilità con le

applicazioni dell'utente finale.

Il metodo di adattamento dell’applicazione sarà incrementale. In primo luogo il progetto

realizzerà l'adattamento di base delle applicazioni selezionate approfittando della

tecnologia WiMAX per permettere un tempestivo inizio dei test. In seguito, i

42

cambiamenti più profondi saranno introdotti nelle applicazioni per incorporare la

mobilità ed una completa consapevolezza dell'ambiente con funzioni di handover e

roaming.

2.8.2. Strato di controllo (AC3200)

Questa attività mirerà a progettare, integrare e sviluppare prototipi necessari per fornire,

al livello dello strato di controllo, le funzionalità avanzate di rete definite in WP2000 e

richieste per sviluppare l'infrastruttura di sperimentazione WEIRD.

Gli obiettivi principali di questa attività saranno:

• la gestione e il controllo end-to-end coerente della QoS e delle risorse, che saranno

compatibili con le specifiche architetturali di WP2000 e con le relative attività di

standardizzazione (ETSI TISPAN, 3GPP IMS, IETF NSIS WG, IEEE 802);

particolare rilievo sarà dato all'applicazione delle teorie per lo sviluppo di algoritmi

di gestione delle risorse (controllo di ammissione e controllo di congestione);

• lo strato integrato di controllo end-to-end per i servizi di trasporto orientati alla

connessione; esso si baserà su un MPLS ibrido e su tecnologie DiffServ (una

miscela di specifiche DiffServ senza connessione di QoS e controllo centralizzato

delle risorse e controllo MPLS distribuito delle risorse orientato alla connessione);

• AAA (Autenticazione, Autorizzazione, e Accounting), nella prospettiva di una rete

multi-tecnologia e multi-regione. La soluzione WEIRD prevista per AAA

applicherà diverse tecnologie per soddisfare la necessità di dinamismo dei servizi di

trasporto della rete in contesti multi-operatore, analogamente a ciò che avviene per

la mobilità. L’AAA WEIRD supporterà la mobilità, il roaming e l’handover

verticale in reti basate su IPv6 integrandosi con il protocollo IP mobile;

• la sicurezza, sia hop-by-hop che end-to-end, nascondendo la struttura interna della

rete, proteggendo dagli attacchi (Denial of Service, furto di identità, ecc.), e

garantendo la riservatezza dei messaggi scambiati nello strato di controllo. Ciò

riguarderà l’infrastruttura di IEEE802.1x, il protocollo IPSec, e meccanismi

trasversali di firewall studiati nell’infrastruttura IETF NSIS;

43

• la pianificazione di rete e l’ingegneria del traffico per i servizi su base pacchetto in

condizioni di interoperabilità non-distruttiva di tecnologie differenti.

I risultati previsti da questa operazione sono: il dimensionamento della rete

compatibile con i risultati euristici di ingegneria del traffico; la configurazione della

rete per mezzo di meccanismi di amministrazione automatizzati; e la periodica

riottimizzazione della rete, innescata dai feedback di un sistema di misura della

rete;

• l'amministrazione di rete mediante meccanismi SNMP, compresa un'interfaccia

utente di configurazione di tutte le entità di controllo.

Alcuni degli aspetti più rilevanti nell'attività dello strato di controllo sono connessi

all’interoperazione tra MPLS e DiffServ, l’AAA e la sicurezza in contesti wireless

mobili. L’interoperazione di MPLS e DiffServ, specificata all'interno dello IETF (rif.

RFC 3270), è una funzionalità di base necessaria per un'integrazione completa fra le

tecnologie di reti eterogenee attraversate da un servizio end-to-end. Gli operatori di rete

considerano DiffServ una soluzione flessibile e scalabile, ma sono state proposte ed

esaminate anche soluzioni ibride (per esempio IntServ/DiffServ), puntando a sviluppare

servizi dinamici ent-to-end adatti a configurare la coarse-grained QoS per rispondere

alle richieste finer-grained QoS dell’utente.

D'altra parte, nella prospettiva di un'architettura di rete più controllabile e più trattabile,

la standardizzazione di MPLS ha portato alla definizione di protocolli rivolti ad ottenere

il paradigma di una rete intelligente orientata al circuito in un contesto di reti a

pacchetto senza connessione. L'integrazione delle due architetture comporta una fusione

ottimale dei rispettivi vantaggi.

Dal punto di vista di WEIRD, l'integrazione delle due architetture non conta soltanto a

livello di strato dati come principalmente richiamato dalle più recenti implementazioni,

ma risulta essere fondata in particolare sulla definizione di una struttura comune dello

strato di controllo in cui DiffServ ed MPLS possono completarsi e/o essere controllati

facilmente ed alternativamente secondo i requisiti dell'operatore di rete. In questa nuova

prospettiva DiffServ ed MPLS puri, ed i domini ibridi possono interoperare per mezzo

44

dello stesso strato di controllo, che ha in carica il giunto semantico fra la segnalazione

MPLS (strato puro di controllo) e la politica meccanismi/protocolli di DiffServ

(condivisa fra gli strati di controllo e amministrazione), in una combinazione

configurabile di approcci distribuiti e centralizzati.

Riguardo al sistema di AAA (autenticazione, autorizzazione, ed accounting),

l’approccio WEIRD conterà sul protocollo DIAMETER, che sarà esteso per aggiungere

i meccanismi di handover alle informazioni standard registrate ed inserire nuove

funzioni che controllino i dati aggiunti. DIAMETER è un protocollo innovatore di

AAA per le reti IP di prossima generazione, migliore dei protocolli usati comunemente

per AAA in termini di flessibilità, estensibilità, sicurezza, e supporto al roaming. Il

DIAMETER è flessibile ed estendibile in quanto si compone di un protocollo base e di

estensioni chiamate, negli standard DIAMETER, applicazioni, una delle quali è

dedicata al protocollo Mobile-IP (applicazione mobile-IPv4 di Diameter).

Riguardo alla sicurezza, l'ambiente WEIRD seguirà il metodo di controllo di accesso

rappresentato dagli standard IEEE 802.1x usando EAP (Extensible Authentication

Protocol), e 802.11i usando WPA (Wi-Fi Protected Access). Questi meccanismi di

sicurezza saranno integrati a livello di applicazione e a livello IP da IPSec.

2.8.3. Strato di trasporto (AC3300)

Lo strato di trasporto di WEIRD fornisce il data path per l'infrastruttura di

sperimentazione del progetto. Questo strato fornirà un'interfaccia indipendente dalla

tecnologia con soluzioni di strato MAC e PHY dipendenti dalla tecnologia a

sottosistemi WiMAX al fine di integrarlo completamente alla rete dorsale ad alta

velocità di GEANT. Lo strato di trasporto sarà implementato come una soluzione di

strato di convergenza che preveda un supporto a IPv6/IPv4 nativi, ai protocolli di

trasporto UDP e TCP, e fornisca i moduli API per:

• Gestione della QoS;

• Controllo di gestione della mobilità;

45

• Controllo d’accesso multiplo.

Lo scopo di questa operazione è di progettare ed implementare i meccanismi dello strato

di convergenza compresi i moduli API e le interfacce per driver di reti IPv6/v4 e di

dispositivi hardware all’interno delle Base Station (BS) e nelle stazioni radio mobili (ss)

del sistema WEIRD. Lo strato di convergenza è una soluzione middleware che fornisce

le interfacce per soluzioni hardware ed i protocolli di strato superiore. Lo strato di

convergenza sarà progettato un modo da essere indipendente dalla tecnologia consisterà

di un insieme di moduli che aumenteranno e renderanno uniformi le prestazioni della

rete di accesso. Tutte le funzioni dello strato di convergenza saranno dunque

indipendenti dalla tecnologia; l’interoperabilità con la tecnologia di rete di base è fornito

dallo strato di adattamento mediante un canale di segnalazione verticale, mentre strati di

convergenza di diverse entità fruiscono di un canale di segnalazione orizzontale.

Di seguito sono brevemente descritte alcune delle funzioni più rilevanti nell'attività

dello strato di trasporto.

IPv6 – lo strato di trasporto WEIRD includerà IPv6. Gli sforzi rivolti a IPv6 stanno

contribuendo a realizzarne una più veloce disiffusione, anche se ci sono ancora alcuni

aspetti, sia architetturali che implementativi, che richiedono lavoro. La mobilità è una di

questi. Mentre IPv4 non ha considerato la mobilità (parzialmente in quanto allora non

c’era l’esigenza di tali requisiti), IPv6 è stato progettato per supportare nativamente la

mobilità. Tuttavia i meccanismi di mobilità IPv6 devono ancora essere ottimizzati per

fornirla completamente. WiMAX porterà i nuovi requisiti di mobilità in IPv6, e ciò sarà

uno dei contributi di WEIRD. Inoltre il progetto contribuirà a capire come e se gli

specifici headers/campi IPv6 potranno essere utili per gli attuali modelli di QoS, e quali

sono le caratteristiche richieste per le soluzioni di segnalazione supportate, per renderle

IPv6-compatibili. Saranno poi identificate quali tecnologie attuali, o meglio quali

implementazioni MPLS permesse in IPv6, sono supportate in particolare in

un’infrastruttura di mobilità.

QoS - per garantire la qualità di servizio migliore possibile e per utilizzare in modo

efficiente la connessione ad alta velocità, alle SS e BS è richiesto di adattarsi

46

all’evoluzione del sistema WiMAX. Il modulo di QoS dello strato di convergenza

utilizza canali di segnalazione sia verticali che orizzontali, al fine di riunire i requisiti di

rete e le applicazioni e le informazioni sullo stato del canale.

In primo luogo la QoS si concentra sulla progettazione ed implementazione del

meccanismo di differenziazione di QoS nello strato di convergenza, fornendo

componenti quali classificatori, schedulers, meccanismi di gestione delle code di

traffico, all’architettura WEIRD.

In secondo luogo essa fornisce i mezzi per descrivere il traffico e configurare i

dispositivi di disciplina del traffico e di supporto alla QoS end-to-end di strato

superiore. L'architettura proposta permette al modulo di QoS di implementare alcune

procedure la cui efficacia e complessità dipendono dalle capacità della BS. Possono

essere definiti due modelli per le funzionalità della stazione base.

Nel caso di una BS standard, il modulo di QoS permette di effettuare la differenziazione

e la regolazione del traffico attraverso procedure di scheduling e policing; l’inoltro dei

pacchetti è garantito dall’adattatore. Perfezionando la BS possono essere effettuate

procedure di gestione delle risorse più complesse, quali il controllo di ammissione e di

congestione. Queste procedure di QoS sfrutteranno le informazioni sulle condizioni

della rete di accesso WiMAX.

Gestione della mobilità – Il supporto alla mobilità è fornito grazie a modifiche

apportate agli strati fisico e di controllo di accesso dello standard IEEE 802.16-2004. Le

soluzioni proposte forniranno un supporto efficiente alla mobilità soltanto per

handovers fra le BS all'interno di una singola sottorete. Ciò significa che, quando la SS

sta cambiando sottorete, il controllo di mobilità di WiMAX non è sufficiente e ne è

richiesto uno di strato superiore. Ciò accade in particolare per i servizi Voce e Video su

base IP, per i quali la mobilità dello IEEE 802.16e può non essere sufficiente, pertanto

saranno necessarie funzionalità di gestione della mobilità di strato superiore.

Sono considerati meccanismi di gestione della mobilità per IPv6 quali il mobile-IP

(MIP) ed l’Host Identity Protocol (HIP). Il MIP e il MIPv6 sono supportati in modo

47

particolarmente ampio nelle odierne reti dorsali e nella maggior parte delle soluzioni

router. L'HIP è un protocollo recente, che beneficia del supporto alla sicurezza e alla

mobilità di sessione forniti dal mobile-IP.

La mobilità di sessione è richiesta per esempio in servizi Video su base IP e in scenari

di streaming, in cui la sessione d'utente è trasferita ad una differente SS di altri utenti su

dominio wireless o cablato.

Al fine di aumentare le funzionalità di gestione della mobilità, lo strato di convergenza

del WiMAX introduce una politica basata su handover di sessione ed handover di

sottorete. L'operazione mira appunto a specificare ed implementare il meccanismo di

handover del WiMAX.

Multi-Access e multihoming - lo scopo del controllo di accesso è aumentare l'accesso

alla rete del sistema supportando interfacce multiple di ingreso/uscita. L’obiettivo è

specificare ed implementare una politica di selezione dell'interfaccia che utilizzi le

informazioni pervenute dalle entità di strato inferiore, le quali includono il rapporto

segnale-rumore (SNR) ed altre statistiche del canale radio generate dall’adattatore

WiMAX. In particolare, lo scopo del meccanismo di controllo d’accesso, in

collaborazione con il modulo di QoS dello strato di convergenza WEIRD e le

funzionalità di rate control dello strato di applicazione, è aumentare le prestazioni delle

applicazioni Voce e Video su base IP.

Il meccanismo di controllo d’accesso, fornisce dunque i meccanismi di bilanciamento

del carico e di controllo di accesso multiplo alle interfacce dello stesso tipo o di tipo

differente (per esempio WiMAX, WLAN). Il modulo di accesso multiplo nello strato di

convergenza utilizza meccanismi di monitoraggio del traffico e informazioni di stato del

canale al fine di selezionare l’interfaccia e la connessione migliori per il servizio

richiesto. Il modulo di controllo di accesso richiede inoltre API per l'adattatore dello

strato inferiore. Sono infine presi in considerazione componenti di controllo di accesso,

quali il controllo delle risorse e di ammissione compatibili con l’AAA ed i moduli di

sicurezza dello strato di controllo WEIRD.

48

2.8.4. Accessori degli strati WiMAX (AC3400)

Questa attività include gli studi di implementazione di due strati dipendenti dalla

tecnologia: gli strati PHY, DLC/MAC, e l'adattatore WiMAX da collegare mediante

interfaccia allo strato di convergenza.

2.8.4.1. Accessori dello strato PHY

Nello strato fisico le antenne multiple possono essere sfruttate per migliorare sia

l'efficienza spettrale che l'affidabilità del collegamento. Questa tecnica è detta “tecnica

in diversità di spazio”. Tradizionalmente, le antenne multiple sono state utilizzate alle

estremità del ricevitore per sopperire alle perdite causate dal multipath fading.

L'aumento di affidabilità del collegamento è attribuita alla ridotta intensità

dell’affievolimento confrontata ad un sistema single-input single-output (SISO). Se è

disponibile un canale di feedback, può essere effettuata una modulazione codificata

adattiva per migliorare l'efficienza spettrale. Tuttavia, risultati teorici/sperimentali sui

sistemi multiple-input multiple-output (MIMO) nelle comunicazioni wireless hanno

indicato che è possibile ottenere aumenti significativi della capacità di canale soltanto se

le antenne multiple sono utilizzate sia in trasmissione che in ricezione. Una

caratteristica dominante dei sistemi MIMO è che sono adatti all’utilizzo in contesti

fortemente dispersivi. Il multiplexing spaziale dei dati, ovvero la tecnica in base alla

quale flussi indipendenti di dati possono essere trasmessi da ciascuna antenna

trasmittente, può dunque essere sfruttato. Poiché più antenne trasmettenti generano

repliche spaziali differenti del segnale, il ricevitore può separare i diversi flussi di dati.

In un tal sistema, la capacità di canale aumenta linearmente piuttosto che

logaritmicamente, all’aumentare del rapporto segnale-rumore (SNR). Un altro beneficio

importante è che questo aumento della capacità avviene con nessun assorbimento di

energia o di larghezza di banda supplementare.

49

L'obiettivo della ricerca sullo strato PHY è sviluppare i metodi e le procedure che

aumentano le prestazioni dello strato fisico WiMAX. L’approccio WEIRD utilizza le

caratteristiche MIMO previste per OFDM ed OFDMA nello standard IEEE 802.16e per

aumentare le prestazioni del sistema, vale a dire la codifica spazio-tempo (STC), la

tecnica in diversità di spazio, i sistemi di antenne adattive (AAS), e il beamforming. Le

tecniche di STC sfruttano la diversità di spazio ed in alcuni casi offrono anche un

guadagno di codifica. I sistemi AAS aumentano le prestazioni riducendo l'interferenza

di accesso multiplo (MAI) e l'interferenza intersimbolica (ISI). Infine, l'uso di

beamforming aumenta la potenza del segnale ricevuto.

Inoltre, in trasmissione viene fatto uso di matrici di stato del canale MIMO, tenendo in

considerazione possibili modifiche allo strato MAC/DLC richieste dalle procedure

MIMO. L'implementazione fisica del sistema sarà effettuata valutando la complessità

delle funzionalità dello strato PHY. Per concludere, i risultati di simulazione saranno

confrontati con quelli raggiunti dalle piattaforme di sperimentazione reali.

2.8.4.2. Adapter

L’architettura WEIRD è stata progettata in modo da essere il più possibile indipendente

dalle apparecchiature WiMAX specifiche dei diversi fornitori. Al fine di raggiungere

questo livello di indipendenza è stato sviluppato un modulo software, chiamato Adapter

(AD), orizzontale rispetto all’architettura WEIRD, il cui obiettivo principale è quello di

separare gli apparati proprietari da quelli indipendenti dal fornitore. Di conseguenza, le

diverse apparecchiature WiMAX proprietarie possono essere perfettamente integrate e

supportate senza che ciò richieda delle modifiche ai moduli e alle interfacce circostanti.

In primo luogo saranno specificate le modifiche apportate per adattare WiMAX alle

funzionalità previste dello strato di convergenza WEIRD, in base alle quali sarà

50

progettato l’adattatore. Il lavoro sarà incentrato sulle API, sulla consegna allo strato di

convergenza delle informazioni circa lo stato del canale per il supporto della mobilità, il

monitoraggio del traffico, e il controllo d’accesso.

2.9. Adapter

L'adattatore svolge un ruolo di collegamento tra lo strato di convergenza e gli strati

delle reti di accesso WiMAX dipendenti dalla tecnologia (DLC/MAC e strati fisici).

Fondamentalmente l'adattatore WiMAX funziona come un driver dipendente dal

sistema operativo, fornendo l'interfaccia tra l’hardware WiMAX e il kernel del sistema

operativo, e la pila protocollare. L'adattatore fornisce i meccanismi di segnalazione

richiesti per lo strato di convergenza, la trasmissione di dati da e verso l’hardware

WiMAX, e i protocolli di strato superiore.

La

Figura 18 mostra una semplice descrizione dell'architettura e la composizione

dell'adattatore, il quale dispone di un modulo di interfaccia con il RC e un altro con la

BS WiMAX attraverso il protocollo SNMP. L'adattatore è ulteriormente suddiviso in

una parte generica, detta Generic Adapter (GA), e una serie di Vendor Specific

Adapters (VSA) per fornire un’interfaccia SNMP differenziata per ogni fornitore di BS

WiMAX.

Il GA è responsabile per l'elaborazione e l’inoltro delle richieste in ingresso al VSA

corretto. Quest’ultimo converte le richieste pervenute dal GA nei messaggi SNMP

corrispondenti e li invia all’SNMP Agent installato nella BS. Inoltre, per trasmettere

informazioni sulla topologia della rete, come allarmi e notifiche, sono supportati

messaggi SNMP-Trap inviati dagli apparati WiMAX.

Riassumendo, al fine di sostenere ulteriori fornitori di apparati WiMAX nell’architettura

WEIRD, è necessario progettare ed implementare un VSA, nonché la relativa

interfaccia SNMP, senza dover modificare nessun altro modulo o interfaccia.

51

Figura 18 - Architettura di contesto dell'Adapter

2.9.1. Descrizione del Modulo

L'adattatore è interfacciato nell’ASN-GW con l’Adapter Attendant presente nel modulo

RC attraverso l’AI, e all’SNMP Agent nella BS.

52

L’RC utilizza il servizio SNMP fornito dall’adattatore, il quale usa il protocollo SNMP

per comunicare con l’SNMP Agent. Tutte le comunicazioni con le apparecchiature

WiMAX sono effettuate attraverso questa interfaccia usando le primitive definite.

L'adattatore deve richiamare le informazioni sullo stato del collegamento necessarie ai

diversi scopi di adattamento attraverso richieste di tipo SNMP-GET. Inoltre esso è

utilizzato per attivare variazioni nella BS mediante richieste di tipo SNMP-SET ed

SNMP-TRAP.

L'adattatore gestisce richieste di tipo SNMP v2c - GET, -SET, -TRAP al modulo SNMP

Agent operante in una certa sottorete con un dato indirizzo IP.

Per rendere l’adattatore compatibile con le apparecchiature di differenti fornitori di

servizio, si è scelto di dividerlo in una parte comune (motore, ricevente e mittente) , e

una serie di librerie specifiche del fornitore per supportare un’elaborazione differenziata

delle richieste SNMP per ogni fornitore di BS.

Le funzionalità principali del modulo dell'adattatore in ASN-GW sono le seguenti:

• Ricevere sull’AI la primitiva di richiesta dal modulo di RC;

• Convertire la primitiva di richiesta nella corrispondente richiesta SNMP;

• Elaborare la PDU della richiesta SNMP;

• Trasmettere la richiesta SNMP-GET, -SET, -TRAP al modulo dello SNMP Agent

usando il protocollo SNMP;

• Ricevere la corrispondente PDU della risposta SNMP dall’SNMP Agent;

• Convertire la PDU della risposta SNMP ricevuta nella corrispondente primitiva

dell’AI;

• Inoltrare la risposta dell’ AI al modulo RC.

La Tabella 5 presenta le interfacce del modulo AD.

53

Il modulo AD è interfacciato con il RC attraverso l’AI (Adapter Interface), e interagisce

con l’SNMP Agent mediante protocollo SNMP v2c.

Modulo Interfaccia Modulo

Adapter Interface (AI) Resource Controller (RC) AD

SNMP Protocol v2c SNMP Agent

Tabella 5 - Interfacce del modulo Adattatore.

La

Figura 19 descrive l’architettura del modulo dell’Adapter nell’ASN-GW.

Figura 19 - Architettura dell’Adapter nell’ASN-GW.

54

Il modulo dell’SNMP client viene eseguito nello user program space di Linux. Questo

modulo, funzionante da entità SNMP, è utilizzato per richiamare i dati relativi agli OID

(Object IDentifier) necessari, e innescare gli eventi definiti nella BS WiMAX. Ciò viene

eseguito indirettamente attraverso l’SNMP Agent all'interno della BS interessata,

usando il protocollo SNMP e le primitive definite. Il modulo dell’SNMP client si

interfaccia al modulo RC attraverso l’AI. L’elaboratore della richiesta SNMP controlla

la comunicazione con l’SNMP Agent e le definizioni necessarie per ogni fornitore di

BS. Esso inoltra poi le richieste dall’SNMP request pool all’SNMP Agent e ritira le

risposte corrispondenti nell’SNMP delivery pool per il processo del mittente della

richiesta AI.

Come visto nella

Figura 19, il ricevente della richiesta AI converte la sua primitiva in una richiesta SNMP

per l’elaborazione. Il mittente della risposta AI converte i dati dell’SNMP delivery in

forma di primitiva AI, prima dell’inoltro al modulo RC.

55

Figura 20 - Implementazione del modulo Adapter.

Il modulo dell’SNMP Agent viene eseguito all'interno della BS WiMAX. Il protocollo

SNMP fornisce un modo di comunicare indirettamente con l’hardware WiMAX usando

le primitive SNMP definite.

Il MIB è una base di dati che, per gli scopi di controllo ed amministrazione della rete,

contiene sia gli OID generici, che quelli specifici del fornitore.

Le definizioni SNMP contengono le definizioni necessarie all’interoperabilità con

apparecchiature di fornitori differenti.

Il Resource Controller si interfaccia al modulo dell'adattatore usando il servizio SNMP

dell'interfaccia dell'adattatore (AI). Tutta la comunicazione SNMP con l’SNMP Agent è

effettuata attraverso questa interfaccia usando le primitive definite.

2.9.2. Descrizione e meccanismi di implementazione delle interfacce

2.9.2.1. Adapter ↔ Resource Controller

Questa interfaccia è usata per stabilire la comunicazione fra il Resource Controller (RC)

e l'adattatore.

I sockets UNIX sono utilizzati nell'implementazione dell'interfaccia AI nell’ ASN-GW.

La seguente tabella UML descrive le interazioni dell’AI fra RC ed i moduli

dell'adattatore.

56

Figura 21 - Interazioni su AI tra Adapter e Resource Controller

2.9.2.2. Adapter ↔ SNMP Agent

Questa interfaccia è utilizzata per stabilire la comunicazione tra l'adattatore nell’ASN-

GW e l'SNMP Agent presente nella BS. The Net - SNMP API C biblioteca è usato per

attuare l'interfaccia tra l'adattatore in ASN - GW e agente SNMP in BS. UML seguente

grafico descrive la sequenza SNMP interazioni tra adattatore e agente SNMP moduli.

La libreria delle API Net-SNMP è usata per implementare l'interfaccia tra l'adattatore

nell’ASN-GW e l’SNMP Agent nella BS.

La seguente tabella UML descrive le interazioni SNMP tra dell'Adapter e l’SNMP

Agent.

57

Figura 22 - Interazioni SNMP tra Adapter ed SNMP Agent

58

3. Il Sistema Alcatel 7387

L’A7387 è la prima piattaforma WiMAX Alcatel per la banda di frequenze con licenza

intorno a 3,5 GHz basata sullo standard IEEE 802.16/ETSI HIPERMAN.

Alcatel 7387 è progettato per soddisfare le specifiche esigenze delle Wireless

Metropolitan Area Network (MAN) e fornire servizi di accesso a banda larga a una

vasta gamma di clienti, tra cui residenziali, SOHO, PMI. Il suo protocollo di Media

Access Control (MAC) è stato progettato per applicazioni punto-multipunto di accesso

wireless a banda larga con alta efficienza spettrale, e per sostenere contesti utente

difficili.

I meccanismi di accesso e assegnazione di banda consentono di allocare centinaia CPE

per canale, con CPE che possono supportare diversi servizi a più utenti finali.

Il sistema utilizza la tecnologia OFDM, è robusto in condizioni di canale avverse, e

consente il funzionamento su link NLOS. Questo permette una facile Installazione e

migliora la copertura, pur mantenendo un alto livello di efficienza spettrale.

Modulazione e di codifica possono essere adattate, al fine di raggiungere un trade-off tra

robustezza ed efficienza, secondo le condizioni del collegamento.

A7387 supporta una vasta gamma di servizi di rete, incluso l'accesso a Internet (Tramite

IP o PPPoE di tunneling), VPN e Voice over IP.

Possono essere utilizzati il riconoscimento di servizio e i classificatori multipli per la

generazione di vari profili di servizio e consentire agli operatori di offrire SLA

differenziati con QoS per ogni profilo di servizio.

L'effettivo funzionamento delle frequenze utilizzate dal sistema può essere configurato

in base alla normativa per le comunicazioni radio applicabile, le condizioni di licenza, e

alle specifiche considerazioni di utilizzo.

59

Figura 23 - Architettura del sistema Alcatel 7387

La Base Station WiMAX Alcatel 7387 ha due moduli separati, che funzionano come segue:

• Unità Interna (IDU2CH-AC)

L’Indoor Unit (IDU) è incaricata di convertire i dati digitali nel formato dello standard

WiMAX IEEE 802.16d, di allocare il segnale di uscita ad una frequenza intermedia (IF),

e di inviarlo all’unità esterna. In uplink, l’IDU effettua l’operazione inversa, cioè

convertire il segnale IF in dati digitali.

• Unità esterna (ODU2CH-AC)

60

L’Outdoor Unit (ODU) è un’unità ad alta potenza, collegata all’antenna esterna. In

downlink l’ODU converte il segnale IF in un segnale a radio-frequenza (RF) a 3.5GHz,

mentre in uplink viene effettuato il processo inverso.

3.1. A7387 Base Station Equipment

3.1.1. Customer Premise Equipment (CPE)

La Customer Premise Unit (CPE) installato presso i locali del cliente, comprende un

terminale radio (RT) e un terminale di rete (NT).

Il CPE-RT comprende il modem, la radio, i componenti di elaborazione e gestione dei

dati del CPE.

Esso comprende anche un’antenna piatta ad alto guadagno.

La CPE-RT fornisce la connessione dati alla Access Unit (AU), fornendo funzioni di

bridging, shaping e classificazione del traffico. Essa è collegato al NT e

all’apparecchiatura dell’utente attraverso una porta Ethernet 10/100 BaseT, e può

supportare fino a 512 indirizzi MAC.

Figura 24 - Customer Premise Equipment (CPE)

62

3.1.2. DBS/RBS Access Units (AU)

L’unità radio RBS della MicroDBS è un’unità full duplex multi-carrier ad alto

guadagno per il collegamento all'antenna esterna. E’ progettato per ottenere un’elevata

robustezza alle interferenze utilizzando una trasmissione ad alta potenza e a bassa figura

di rumore. Supporta una larghezza di banda fino a 14MHz, che permetterà nel futuro di

aumentare la capacità attraverso l'uso di un Multiplexer o di canali più ampi (ad

esempio, 7/14MHz).

L’unità MicroDBS si connette alla radio-RBS attraverso un cavo IF di media frequenza,

il quale porta dati in full duplex, e segnali di controllo e gestione tra la MicroDBS e la

radio-RBS.

Le frequenze in trasmissione e ricezione sono 240 MHz e 140 MHz, rispettivamente. Il

canale DBS/RBS di servizio a 14MHz serve per il controllo bidirezionale, lo status e la

gestione della segnalazione.

Figura 25 - RBS Access Units (a)

63

Figura 26 - RBS Access Units (b)

3.1.3. A7387-Micro DBS

L’unità MicroDBS fornisce le funzionalità di base necessarie per servire un unico

settore.

Le funzioni della MicroDBS sono molto simili a quelle di una Base Station MacroDBS

con Network Processing Unit (NPU), e comprendono:

• connettività Ethernet tramite interfaccia di rete 10/100Base-T;

• classificazione del traffico e inizializzazione di connessione;

• commutazione basata su funzioni di policing;

• gestione dei Service Level Agreements ;

• agente centralizzato per la gestione dell’unità MicroDBS e di tutte le CPE;

• gestione degli allarmi, compresi gli ingressi esterni.

Un SNMP Agent incorporato nell’unità consente la gestione della MicroDBS e di tutte

le CPE.

Una porta seriale RS–232 supporta la configurazione locale, il monitoraggio e il

debugging.

64

Figura 27 - A7387-Micro DBS

Figura 28 - A7387 Macro DBS

Figura 29 - A7387-Macro DBS-NPU (Network Processing Unit)

65

3.2. A7387 Management System (NMS)

Tutti i componenti del sistema modulare associato ad una stazione base sono gestiti

tramite il modulo MacroDBS-NPU. Gli altri componenti del sistema (AUs

E CPEs) non sono direttamente accessibili: ciascuna configurazione di cambiamento di

stato o richiesta viene inviata alla MacroDBS-NPU che comunica con gli altri

componenti del sistema. Questo è vero anche per la MicroDBS, in cui tutti le CPE sono

gestite indirettamente tramite la MicroDBS.

Sono disponibili le seguenti opzioni di gestione:

• gestione basata su SNMP utilizzando A7387-SNM (o un altro sistema di

gestione della rete ad-hoc per supportare la gestione del A7387;

• utilizzo di Telnet per accedere al Monitor Program incorporato;

• accesso al Monitor Program localmente tramite la porta MON.

Tipicamente, i sistemi A7387 sono gestiti utilizzando A7387-SNM o un altro sistema di

gestione della rete basato su SNMP.

3.2.1. Il Monitor Program

Il Monitor Program consente di configurare i parametri di base del sistema durante

l'installazione per facilitare la comunicazione con l'AU, compresi tutti i parametri

richiesti per il completamento del processo di inserimento in rete.

66

Inoltre, consente di aggiornare il software, controllarne la versione installata, e il

download/upload dei file di configurazione, permettendo un più veloce processo di

configurazione.

Il Monitor Program prevede inoltre la selezione di funzioni per il monitoraggio delle

prestazioni, consentendo ad installatori e tecnici di visualizzare le informazioni sulla

qualità della connessione e sul traffico.

3.2.1.1. Accesso al Monitor Program

1. Il Monitor program utilizza l’indirizzo IP fisso 192.168.50.2 con una subnet mask

255.255.255.0. Il PC utilizzato per accedere al Monitor Program è configurato in

modo tale da utilizzare un indirizzo ip fisso 192.168.50.11, e un indirizzo di

Gateway 192.168.50.10;

2. Il Pc è collegato tramite cavo Ethernet crossato alla porta MNGT della MicroDBS;

3. E’ instaurata una connessione Telnet tramite la quale è possibile accedere al prompt

di autenticazione;

4. Inserita la password, si accede al menu principale del Monitor Program, dal quale

sarà possibile configurare i parametri e gestire le opzioni di monitoraggio delle

prestazioni.

67

Figura 30 - Menù principale del Monitor Program

3.2.2. Allarmi e Traps

La gestione degli eventi di sistema si basa su messaggi di tipo SNMP-TRAP, ognuno

dei quali è identificato da un proprio OID all’interno del MIB DB.

Per accedere alla consultazione delle istanze della base di dati è necessario selezionare

la voce (1-Micro-Base-Station) del menu principale.

Figura 31 - Menù Micro Base Station.

68

Selezionando la voce (4 – Alarms and Traps) è possibile consultare la lista degli allarmi

attivi e il file di log delle traps, con la possibilità di filtrare le traps e di

abilitarle/disabilitarle.

L’esplorazione dell’alberatura del MIB è possibile alternativamente mediante l’uso del

comando SNMP-walk, funzione della libreria net-SNMP, adibita proprio a questo tipo

di utilizzo.

La conoscenza delle corrispondenze tra le TRAP e i relativi OID è importante per la

corretta implementazione del modulo adattatore, perché la conversione dal formato

numerico del MIB a quello supportato dal sistema WEIRD avviene sostanzialmente

eseguendo un’operazione di cast del messaggio SNMP nella struttura del corrispondente

messaggio WEIRD.

69

4. Il Sistema Alcatel 7387

L’A7387 è la prima piattaforma WiMAX Alcatel per la banda di frequenze con licenza

intorno a 3,5 GHz basata sullo standard IEEE 802.16/ETSI HIPERMAN.

Alcatel 7387 è progettato per soddisfare le specifiche esigenze delle Wireless

Metropolitan Area Network (MAN) e fornire servizi di accesso a banda larga a una

vasta gamma di clienti, tra cui residenziali, SOHO, PMI. Il suo protocollo di Media

Access Control (MAC) è stato progettato per applicazioni punto-multipunto di accesso

wireless a banda larga con alta efficienza spettrale, e per sostenere contesti utente

difficili.

I meccanismi di accesso e assegnazione di banda consentono di allocare centinaia CPE

per canale, con CPE che possono supportare diversi servizi a più utenti finali.

Il sistema utilizza la tecnologia OFDM, è robusto in condizioni di canale avverse, e

consente il funzionamento su link NLOS. Questo permette una facile Installazione e

migliora la copertura, pur mantenendo un alto livello di efficienza spettrale.

Modulazione e di codifica possono essere adattate, al fine di raggiungere un trade-off tra

robustezza ed efficienza, secondo le condizioni del collegamento.

A7387 supporta una vasta gamma di servizi di rete, incluso l'accesso a Internet (Tramite

IP o PPPoE di tunneling), VPN e Voice over IP.

Possono essere utilizzati il riconoscimento di servizio e i classificatori multipli per la

generazione di vari profili di servizio e consentire agli operatori di offrire SLA

differenziati con QoS per ogni profilo di servizio.

L'effettivo funzionamento delle frequenze utilizzate dal sistema può essere configurato

in base alla normativa per le comunicazioni radio applicabile, le condizioni di licenza, e

alle specifiche considerazioni di utilizzo.

70

Figura 32 - Architettura del sistema Alcatel 7387

La Base Station WiMAX Alcatel 7387 ha due moduli separati, che funzionano come segue:

• Unità Interna (IDU2CH-AC)

L’Indoor Unit (IDU) è incaricata di convertire i dati digitali nel formato dello standard

WiMAX IEEE 802.16d, di allocare il segnale di uscita ad una frequenza intermedia (IF),

e di inviarlo all’unità esterna. In uplink, l’IDU effettua l’operazione inversa, cioè

convertire il segnale IF in dati digitali.

• Unità esterna (ODU2CH-AC)

71

L’Outdoor Unit (ODU) è un’unità ad alta potenza, collegata all’antenna esterna. In

downlink l’ODU converte il segnale IF in un segnale a radio-frequenza (RF) a 3.5GHz,

mentre in uplink viene effettuato il processo inverso.

4.1. A7387 Base Station Equipment

4.1.1. Customer Premise Equipment (CPE)

4.1.2. DBS/RBS Access Units (AU)

4.2. A7387 Management System (NMS)

5. Algoritmi per l’allocazione di banda: analisi preliminare e procedure Matlab

5.1. Generazione di N Sorgenti binarie

Si ipotizza che la richiesta di allocazione di banda provenga da N sorgenti binarie di cui

è possibile definire la probabilità di emissione e la lunghezza dei pacchetti.

La tipologia di sorgente, inoltre, può essere semplice o modellabile come una catena di

Markov a due stati del primo ordine.

72

L’asse dei tempi è considerato suddiviso in slots di durata pari al periodo di

segnalazione, uguale per tutte le sorgenti.

Prima di iniziare la simulazione vera e propria è possibile definire alcuni parametri di

ingresso lanciando lo script START.m .

START.m

N=input('Numero di Sorgenti: ');

T=input('\nLunghezza dell’intervallo d’’osservazione: ');

for i=1:N

fprintf('\nBit rate della Sorgente %d: ',i);

bitR(i)=input('');

end

for i=1:N

fprintf('\nProbabilità di emissione della Sorgente %d: ',i);

p(i)=input('');

end

Durante la simulazione sono considerati i seguenti dati in ingresso:

N=10; %numero di sorgenti

T=1000; %numero di slots

bitR=[10,15,40,40,40,50,50,80,80,100]; %vettore bit rates

p=[.7,.4,.3,.5,.3,.3,.3,.3,.3,.3]; %vettore probabilità

5.1.1. Sorgenti con assegnata probabilità di emissione

La funzione source.m genera una matrice S di dimensioni (TxN) le cui colonne

rappresentano l’evoluzione nel periodo d’osservazione T del traffico emesso dalle

singole sorgenti.

Vengono inoltre forniti in uscita alcuni parametri individuali e globali, caratterizzanti

del traffico generato.

73

source.m

function [exp,avg,peak,S,S_req,S_agg,S_avg]=source(N,T,bitR,p)

%Source

%Sintassi: [exp,avg,peak,S,S_req,S_agg,S_avg]=source(N,T,bitR,p);

%

%Dati in ingresso: (N,T,bitR,p)

%

% N : numero di sorgenti;

% T : lunghezza del periodo di osservazione;

% bitR : vettore riga (1xN) contenente i bit rates delle singole sorgenti;

% p : vettore riga (1xN) delle probabilità di emissione delle sorgenti.

%

%Restituisce: [exp,avg,peak,S,S_req,S_agg,S_avg]

%

% exp : vettore riga (1xN) valori attesi dei Bit Rate delle sorgenti;

% avg : carico medio complessivo atteso;

% peak : picco potenziale richiesta complessiva di banda;

% S : matrice (TxN) di sorgente;

% S_req : vettore riga (1xN) richieste individuali medie di banda;

% S_agg : vettore riga (1xN) richiesta istantenea complessiva di banda;

% S_avg : richiesta complessiva media di banda.

%PARAMETRI ATTESI

exp=bitR.*p;

avg=sum(exp);

peak=sum(bitR);

%MATRICE SORGENTE

S=zeros(T,N);

for j=1:N

S(:,j)=(rand(T,1)<=p(j)).*bitR(j);

end

%PARAMETRI ATTUALI

S_req=sum(S)/T;

S_agg=sum(S');

S_avg=sum(S_agg)/T;

In Figura 33 è mostrata l’evoluzione della richiesta di banda nei primi 50 Ts da parte

delle sorgenti considerate.

74

Figura 33 - Emissione sorgenti

75

5.1.2. Sorgenti markoviane del primo ordine

La funzione markov.m genera una matrice P delle probabilità di transizione di

dimensioni (2x2xN), i cui elementi rappresentano le probabilità di transizione tra i

diversi stati di una catena di Markov del primo ordine:

P(i,j,n) è la probabilità condizionata che il sistema transiti nello stato j trovandosi

attualmente nello stato i.

L'inserimento dei dati è controllato in modo da garantirne la coerenza.

Sulla base della matrice P, la funzione determina la matrice S delle sorgenti.

ON OFF

1111−−−−αααα

αααα 1111−−−−ββββ

ββββ

ON OFF

1111−−−−αααα

αααα 1111−−−−ββββ

ββββ

Figura 34 - Modello catena di Markov

La Figura 34 mostra le probabilità di transizione da uno stato all’altro della catena da

parte della sorgente.

markov.m

function [S,P] = markov(T,N,p,bitR)

%Markov Source

%

%Sintassi: [S,P] = markov(T,N,p,bitR);

%

%Dati in ingresso: (T,N,p,bitR)

%



% p : vettore riga (1xN) delle probabilità di emissione delle sorgenti;

% bitR : vettore riga (1xN) contenente i bit rates delle singole sorgenti.

%

%Restituisce: [S,P]

%

% S : matrice (T+1xN) delle sorgenti di Markov;

% P : matrice (2x2xN) delle probabilità di transizione delle sorgenti.

76

%MATRICE DI TRANSIZIONE

for n=1:N

for i=1:2

for j=1:2

fprintf('\n\nProbabilita'' di transizione dallo stato %d allo

stato %d della Sorgente %d: ',i-1,j-1,n);

P(i,j,n)=input('');

end

while sum(P(i,:,n))~=1

fprintf('\n\nERRORE: la somma degli elementi di una riga della

matrice di transizione deve essere pari a 1.\n');

for j=1:2

fprintf('\n\nProbabilita'' di transizione dallo stato %d allo

stato %d della Sorgente %d: ',i-1,j-1,n);

P(i,j,n)=input('');

end

end

end

end

%MATRICE DELLE SORGENTI DI MARKOV

S=zeros(T+1,N);

for i=1:N

S(1,i) = round(p(i));

end

for i=2:T+1

for j=1:N

if S(i-1,j) == 1

S(i,j) = (rand<=P(2,2,j)).*bitR(j);

else

S(i,j) = (rand<=P(1,2,j)).*bitR(j);

end

end

end

Mediante questo modello matematico è possibile descrivere la caratteristica emissione a

burst: una sorgente che si trovi in uno stato tende o meno a rimanervi in ragione della

distribuzione delle probabilità di transizione ad essa relative.

77

5.2. Algoritmi base per l’allocazione di banda

Gli algoritmi di scheduling presentati in questa sezione trascurano l’approccio per

aggregato di flussi, che presuppone l’assegnazione di una classe di servizio alle

sorgenti, costituendo un esempio di allocazione non equamente distribuita.

Viene considerato dapprima un approccio a buffer condiviso, poi a buffers indipendenti,

ed infine un esempio di questo tipo di approccio “non fair”, costituito dallo scheduling

FIFO.

5.2.1. Scheduling a buffer condiviso

Il traffico generato dalle sorgenti concorre complessivamente, istante per istante,

all’allocazione di un buffer condiviso, la cui occupazione iniziale è ipotizzata pari al

carico medio complessivo atteso.

Una volta fissato l’Output Rate, viene misurata la lunghezza della coda che si viene a

creare, la quale costituirà un parametro di confronto con gli altri algoritmi.

Figura 35 - Schema buffer condiviso

Sorgente 1

Sorgente 2

Sorgente N

Buffer

79

shared.m

function B=shared(T,avg,S_agg)

%Shared Buffer

%Sintassi: B=shared(T,avg,S_agg);

%

%Dati in ingresso: (T,avg,S_agg)

%


% avg : carico medio complessivo atteso;

% S_agg: vettore riga (1xN) richieste istantenee complessive di banda.

%

%Restituisce: [B]

%

% B : vettore colonna (T+1x1) contenente l'allocazione istantanea per sorgente

del buffer.

fprintf('\nBUFFER CONDIVISO\n');

outR=input('\nOutput Rate: '); %Output Rate del buffer

B=zeros(T+1,1);

B(1)=avg;

for i=2:T+1

if (S_agg(i-1)+B(i-1)-outR)>0

B(i)=S_agg(i-1)+B(i-1)-outR;

else

B(i)=0;

end

end

Posto l’output rate outR = 250, la

0 100 200 300 400 500 600 700 800 900 10000

50

100

150

200

250

300- Buffer allocation - Shared mode -

- Ts -

- D

ela

y [

Ts]

-

Figura 36 mostra l’andamento della coda d’attesa ottenuta:

80

0 100 200 300 400 500 600 700 800 900 10000

50

100

150

200

250

300- Buffer allocation - Shared mode -

- Ts -

- D

ela

y [

Ts]

-

Figura 36 - Allocazione buffer condiviso

5.2.2. Scheduling a buffers indipendenti

Si ipotizza di assegnare ad ogni sorgente un buffer indipendente il cui Output Rate è

dimensionato sulla base del valore atteso del Bit Rate della sorgente associata, tramite

un fattore di dimensionamento richiesto in ingresso.

L’occupazione iniziale dei buffers è ipotizzata pari al carico medio per sorgente.

Svuotandosi indipendentemente, gli N buffers concorrono a formare un’unica coda di

uscita.

S1

S2

S3

SN

S1

S2

S3

SN

Figura 37 - Schema buffers indipendenti

81

indip.m

function C_agg=indip(exp,T,N,S,S_req)

%Indipendent buffers

%

%Sintassi: C_agg=indip(exp,T,N,S);

%

%Dati in ingresso: (exp,T,N,S,S_req)

%

% exp : vettore riga (1xN) valori attesi dei Bit Rate delle

sorgenti;




% S_req : vettore riga (1xN) richieste individuali medie di

% banda.

%

%Restituisce: [C_agg]

%

% C_agg : vettore riga (T+1x1) contenente i valori istantanei

di attesa in uscita.

fprintf('\nBUFFERS INDIPENDENTI\n');

%fattore di dimensionamento

k=input('\nFattore di dimensionamento degli Output Rates: ');

dim=round(exp*k); %vettore riga Output Rates dei buffers

indipendenti

%matrice allocazione buffers

C=zeros(T+1,N);

C(1,:)=S_req;

for i=2:T+1

for j=1:N

if (S(i-1,j)+C(i-1,j)-dim(j))>0

C(i,j)=S(i-1,j)+C(i-1,j)-dim(j);

else

C(i,j)=0;

end

end

end

C_agg=sum(C');

Posto il fattore di dimensionamento k=1.22, la Figura 38 mostra l’andamento della coda

d’attesa ottenuta:

82

0 100 200 300 400 500 600 700 800 900 10000

500

1000

1500- Buffer allocation - Indipendent mode -

- Ts -

- D

ela

y [

Ts]

-

Figura 38 - Allocazione buffers indipendenti

5.2.3. Scheduling First In First Out

Lo scheduling FIFO trasferisce i pacchetti in base all’ordine di arrivo.

Il buffer è di tipo condiviso, e la sua occupazione iniziale è ipotizzata pari al carico

medio per sorgente.

Lo scheduling è “non fair”, in quanto non si ripartisce la capacità di trasferimento

egualmente tra i flussi, ma saranno le sorgenti che emettono più traffico ad allocare più

risorse.

Sorgente 1

Sorgente 2

Sorgente N

Scheduler FIFO

Buffer

Sorgente 1

Sorgente 2

Sorgente N

Scheduler FIFO

Buffer

83

Figura 39 - Schema allocazione FIFO

fifo.m

function [F,F_agg]=fifo(T,N,S,S_req)

%First In First Out Scheduling

%

%Sintassi: D=fifo(T,N,S,S_req);

%

%Dati in ingresso: (T,N,S,S_req)

%




% S_req : vettore riga (1xN) richieste individuali medie di

% banda.

%

%Restituisce: [F,F_agg]

%

% F : matrice (T+1xN) le cui colonne contengono le

% allocazioni istantanee dei buffers associati alle

% singole sorgenti;

% F_agg : vettore riga (1xT+1) contenente i valori complessivi

% istantanei di attesa in uscita.

%BUFFER CON SCHEDULING FIRST IN FIRST OUT

%sorgente 1: priorità max;

%sorgente N: priorità min.

fprintf('\nBUFFER CON SCHEDULING FIRST IN FIRST OUT\n');

outR1=input('\nOutput Rate: ');

F=zeros(T+1,N);

F(1,:)=S_req;

a=ones(1,N)*outR; %inizializzazione vettore riga risorsa disponibile

for i=2:T+1

for j=1:N

if (S(i-1,j)+F(i-1,j)-a(j))>0

F(i,j)=S(i-1,j)+F(i-1,j)-a(j);

else

F(i,j)=0;

end

if (a(j)-S(i-1,j)-F(i-1,j))>0

a(j+1)=a(j)-S(i-1,j)-F(i-1,j);

else

a(j+1)=0;

end

end

end

F_agg=sum(F');

84

Posto l’output rate outR=250, la

0 100 200 300 400 500 600 700 800 900 10000

50

100

150

200

250

300- Buffer allocation - FIFO mode - Total Delay -

- Ts -

- Delay [Ts] -

Fi

gura 40 mostra l’andamento della coda d’attesa ottenuta:

0 100 200 300 400 500 600 700 800 900 10000

50

100

150

200

250

300- Buffer allocation - FIFO mode - Total Delay -

- Ts -

- Delay [Ts] -

Fig

ura 40 - Allocazione FIFO

In particolare la Figura 41 mostra come l’attesa delle sorgenti con tasso di segnalazione

più basso sia maggiore.

85

Figura 41 - Allocazione FIFO individuale

5.3. Assegnazione della classe di servizio e dei limiti di allocazione di

banda

L’assegnazione di un Service Class Type consente un approccio per aggregati di flussi

aventi le stesse esigenze di QoS, in modo da garantirne il rispetto delle specifiche.

E’ possibile inoltre definire dei limiti percentuali di banda assegnabile alle classi di

servizio, in modo da garantirne l’isolamento. Nell’esposizione dei prossimi algoritmi

sarà possibile constatare, però, che questo può comportare un’allocazione meno

efficiente.

Nella funzione assignment.m l'inserimento delle assegnazioni è controllato da una

routine. Sono rilevati solo errori singoli (o lo stesso consecutivo).

Non sono rilevate ripetizioni del numero identificativo di una sorgente all'interno

dello stesso vettore, né errori consecutivi distinti.

86

assignment.m

function [RT,NRT,BE,rt,nrt,be,BC_RT,BC_NRT,BC_BE,class]=assignment(N)

%Assignment of Service Class Type

%

%Sintassi: [RT,NRT,BE,rt,nrt,be,BC_RT,BC_NRT,BC_BE]=assignment(N);

%

%Dati in ingresso: (N)

%

% N : numero di sorgenti.

%

%Restituisce: [RT,NRT,BE,rt,nrt,be,BC_RT,BC_NRT,BC_BE]

%

% RT : vettore contenente il numero identificativo delle

% sorgenti di traffico Real Time;

% NRT : vettore contenente il numero identificativo delle

% sorgenti di traffico Non Real Time;

% BE : vettore contenente il numero identificativo delle

% sorgenti di traffico Best Effort;

% rt : totale flussi Real Time;

% nrt : totale flussi Non Real Time;

% be : totale flussi Best Effort;

% BC_RT : Limite percentuale di banda assegnata alla classe Real Time;

% BC_NRT : Limite percentuale di banda assegnata alla classe Non Real Time;

% BC_BE : Limite percentuale di banda assegnata alla classe Best Effort;

% class : Vettore assegnazione dell'identificativo della classe

% d’appartenenza.

fprintf(‘ASSEGNAZIONE DELLE CLASSI DI SERVIZIO ALLE SORGENTI’);

rt=input('\nNumero di Sorgenti Real Time: ');

nrt=input('\nNumero di Sorgenti Non Real Time: ');

be=input('\nNumero di Sorgenti Best Effort: ');

%controllo di coerenza

while (rt+nrt+be)~=N

fprintf('\n\nERRORE: il numero totale di assegnazioni non

corrisponde\n');

fprintf(' a quello delle Sorgenti generate.\n\n');

rt=input('\nNumero di Sorgenti Real Time: ');

nrt=input('\nNumero di Sorgenti Non Real Time: ');

be=input('\nNumero di Sorgenti Best Effort: ');

end

%vettore riga Sorgenti Non Real Time

fprintf('\n\nElencare le Sorgenti di traffico Real Time.\n');

for i=1:rt

RT(i)=input('\nSorgente n° ');

end

%vettore riga Sorgenti Non Real Time

fprintf('\n\nElencare le Sorgenti di traffico Non Real Time.\n');

for i=1:nrt

NRT(i)=input('\nSorgente n° ');

for j=1:rt

87

while (NRT(i)==RT(j))>0

fprintf('\n\nERRORE: la sorgente %d è stata gia'' assegnata alla

classe Real Time.\n',NRT(i));

c=0;

while ((c==1)|(c==2))==0

fprintf('\nPremere:\n- [ 1 ] per sostituire la sorgente %d

nella classe Real Time;',NRT(i));

fprintf('\n- [ 2 ] per sostituire la sorgente %d nella classe

Non Real Time.\n\n',NRT(i));

c=input('');

end

if c==1

fprintf('\n\nClasse Real Time:\nSostituire la sorgente %d con

la Sorgente n° ',NRT(i));

RT(j)=input('');

elseif c==2

fprintf('\n\nClasse Non Real Time:\nSostituire la sorgente %d

con la Sorgente n° ',NRT(i));

NRT(i)=input('');

end

end

end

end

%vettore riga Sorgenti Best Effort

fprintf('\n\nElencare le Sorgenti di traffico Best Effort.\n');

for i=1:be

BE(i)=input('\nSorgente n° ');

for j=1:rt

while (BE(i)==RT(j))>0


classe Real Time.\n',BE(i));

c=0;

while ((c==1)|(c==2))==0


nella classe Real Time;',BE(i));


Best Effort.\n\n',BE(i));

c=input('');

end

if c==1

fprintf('\n\nClasse Real Time:\nSostituire la sorgente %d con

la Sorgente n° ',BE(i));

RT(j)=input('');

elseif c==2

fprintf('\n\nClasse Best Effort:\nSostituire la sorgente %d

con la Sorgente n° ',BE(i));

BE(i)=input('');

end

end

end

for j=1:nrt

while (BE(i)==NRT(j))>0


classe Non Real Time.\n',BE(i));

c=0;

while ((c==1)|(c==2))==0

88


nella classe Non Real Time;',BE(i));


Best Effort.\n\n',BE(i));

c=input('');

end

if c==1

fprintf('\n\nClasse Non Real Time:\nSostituire la sorgente %d


NRT(j)=input('');

elseif c==2

fprintf('\n\nClasse Best Effort:\nSostituire la sorgente %d


BE(i)=input('');

end

end

end

end

%Bandwidth Constraints

BC_RT=input('\nLimite percentuale di banda assegnata alla classe Real Time:

')/100;

BC_NRT=input('\nLimite percentuale di banda assegnata alla classe Non Real

Time: ')/100;

BC_BE=input('\nLimite percentuale di banda assegnata alla classe Best Effort:

')/100;

while (BC_RT+BC_NRT+BC_BE)*100~=100

fprintf('\n\nERRORE: la somma dei limiti percentuali di banda assegnata

deve essere pari a 100.\n');

BC_RT=input('\nLimite percentuale di banda assegnata alla classe Real

Time: ')/100;

BC_NRT=input('\nLimite percentuale di banda assegnata alla classe Non Real

Time: ')/100;

BC_BE=input('\nLimite percentuale di banda assegnata alla classe Best

Effort: ')/100;

end

%assegnazione identificativo classe d'appartenenza

for j=1:N

if sum(j==RT)

class(j)=1;

elseif sum(j==NRT)

class(j)=2;

else

class(j)=3;

end

end

89

5.4. Algoritmi di allocazione di banda per diverse QoS

Le priorità dei flussi provenienti dalle N sorgenti sono classificate in ordine decrescente

in base alla classe di servizio d'appartenenza:

• Real Time (RT) (es. una sessione video);

• Non Real Time (NRT) (es. una sessione audio);

• Best Effort (BE) (es. una sessione ftp).

In particolare il traffico di tipo Real Time non dovrebbe mai subire un ritardo maggiore

di quello d’attraversamento del tratto di rete considerato, ovvero:

( ) 0RT RTP W T≥ = .

Durante le simulazioni di seguito descritte è stato considerato uno scenario in cui le

classi di servizio e i limiti di banda fossero distribuiti come segue:

Service Class Type Sources Weights

Real Time 6, 8, 10 0.20

Non Real Time 1, 3, 5, 7, 9 0.35

Best Effort 2, 4 0.45

Tabella 6 - Scenario simulazione

90

5.4.1. Scheduling per Classe di Servizio

Le sorgenti appartenenti ad una stessa classe sono servite con buffer condiviso, la cui

occupazione iniziale è ipotizzata pari al carico medio per classe di servizio.

sct.m

function [G,G_agg]=sct(RT,NRT,BE,T,S)

%Scheduling by Service Class Type Assignment

%

%Sintassi: [G,G_agg]=sct(RT,NRT,BE,T,S);

%

%Dati in ingresso: (RT,NRT,BE,T,S)

%

% RT : vettore contenente il numero identificativo delle

% sorgenti di traffico Real Time;

% NRT : vettore contenente il numero identificativo delle

% sorgenti di traffico Non Real Time;

% BE : vettore contenente il numero identificativo delle

% sorgenti di traffico Best Effort.



%

%Restituisce: [G,G_agg]

%

% G : matrice (T+1x3) le cui colonne contengono le allocazioni istantanee

% dei buffers associati alle singole classi di servizio.

% G_agg : vettore riga (T+1x1) contenente i valori complessivi istantanei di

% attesa in uscita.

fprintf('\nSCHEDULING PER CLASSE DI SERVIZIO\n');

%VETTORI ALLOCAZIONE BUFFER CONDIVISI (per classe di servizio)

%vettore allocazione buffer sorgenti Real Time

S_rt=zeros(T,1);

for i=RT

S_rt=S_rt+S(:,i);

end

%vettore carico Real Time medio complessivo

rt_avg=round(sum(S_rt)/T);

%vettore allocazione buffer sorgenti Non Real Time

S_nrt=zeros(T,1);

for i=NRT

S_nrt=S_nrt+S(:,i);

end

91

%vettore carico Non Real Time medio complessivo

nrt_avg=round(sum(S_nrt)/T);

%vettore allocazione buffer sorgenti Best Effort

S_be=zeros(T,1);

for i=BE

S_be=S_be+S(:,i);

end

%vettore carico Best Effort medio complessivo

be_avg=round(sum(S_be)/T);

%PARAMETRI SORGENTI

SC=[S_rt S_nrt S_be];

%vettore riga carico medio per classe di servizio

meanload=[rt_avg nrt_avg be_avg];

%SCHEDULING PER CLASSE DI SERVIZIO

outR=input('\nOutput Rate: ');

G=zeros(T+1,3);

G(1,:)=meanload;

a=ones(1,3)*outR; %inizializzazione vettore riga risorsa disponibile

for i=2:T+1

for j=1:3

if (SC(i-1,j)+G(i-1,j)-a(j))>0

G(i,j)=SC(i-1,j)+G(i-1,j)-a(j);

else

G(i,j)=0;

end

if (a(j)-SC(i-1,j)-G(i-1,j))>0

a(j+1)=a(j)-SC(i-1,j)-G(i-1,j);

else

a(j+1)=0;

end

end

end

G_agg=sum(G');

Posto l’output rate outR=250, la Figura 42 mostra l’andamento della coda d’attesa

ottenuta:

92

0 100 200 300 400 500 600 700 800 900 10000

50

100

150

200

250

300

350

400

450- Buffer allocation - Scheduling by Service Class Type -

- Ts -

- D

ela

y [

Ts]

-

Figura 42 - Allocazione con separazione in classi di servizio

La Figura 43 mostra invece l’accodamento dal punto di vista delle singole classi di

servizio:

0 100 200 300 400 500 600 700 800 900 10000

20

40

60

80Buffer allocation - Scheduling by Service Class Type - Real Time flow

- Ts -

- D

ela

y [

Ts]

-

0 100 200 300 400 500 600 700 800 900 10000

50

100

150

200

250Buffer allocation - Scheduling by Service Class Type - Non Real Time flow

- Ts -

- D

ela

y [

Ts]

-

0 100 200 300 400 500 600 700 800 900 10000

50

100

150

200Buffer allocation - Scheduling by Service Class Type - Best Effort flow

- Ts -

- D

ela

y [

Ts]

-

Figura 43 - Allocazione per classe di servizio

93

5.4.1.1. Aggiunta della funzione Round Robin

La permutazione dell’ordine di servizio nell’ambito di una classe di servizio realizza un

approccio di tipo “fair” per l’allocazione di banda alle sorgenti ad essa appartenenti.

L’occupazione iniziale dei buffers è pari al carico medio per sorgente.

roundsct.m

function [H,H_agg]=roundsct(T,N,S,S_req,RT,NRT,BE,rt,nrt,be)

%Round Robin Scheduling by Service Class Type Assignment

%

%Sintassi: [H,H_agg]=roundsct(T,N,S,S_req,RT,NRT,BE,rt,nrt,be);

%

%Dati in ingresso: (T,N,S,S_req,RT,NRT,BE,rt,nrt,be)

%




% S_req : vettore riga (1xN) richieste individuali medie di banda;

% RT : vettore contenente il numero identificativo delle sorgenti di

% traffico Real Time;

% NRT : vettore contenente il numero identificativo delle sorgenti di

% traffico Non Real Time;

% BE : vettore contenente il numero identificativo delle sorgenti di

% traffico Best Effort;

% rt : totale flussi Real Time;

% nrt : totale flussi Non Real Time;

% be : totale flussi Best Effort.

%

%Restituisce: [H,H_agg]

%

% H : matrice (T+1xN) le cui colonne contengono le allocazioni

% istantanee dei buffers associati alle singole sorgenti;

% H_agg : vettore riga (1xT+1) contenente i valori complessivi istantanei di

% attesa in uscita.

%matrice (rt!xrt) base delle permutazioni del vettore RT

P_RT=perms(RT);

%matrice (nrt!xnrt) base delle permutazioni del vettore NRT

P_NRT=perms(NRT);

%matrice (be!xbe) base delle permutazioni del vettore BE

P_BE=perms(BE);

%numero righe matrice base delle permutazioni dei vettori RT, NRT, BE

p_rt=factorial(rt);

p_nrt=factorial(nrt);

p_be=factorial(be);

94

%MATRICE DI PERMUTAZIONI SORGENTI REAL TIME

%troncamento in caso di eccesso delle permutazioni

if p_rt>T

M_RT(1:T,:)=P_RT(1:T,:);

else

%numero di permutazioni complete della matrice RT

rip_rt=floor(T/p_rt);

%numero righe della matrice di riempimento

rest_rt=round(((T/p_rt)-rip_rt)*p_rt);

%inizializzazione matrice (Txrt) di permutazioni delle Sorgenti Real Time

M_RT=zeros(T,rt);

M_RT(1:p_rt,:)=P_RT;

for i=1:(rip_rt-1)

M_RT((i*p_rt+1):((i+1)*p_rt),:)=P_RT;

end

REST_RT=zeros(rest_rt,rt);

%matrice (rest_rt x rt) di riempimento

for i=1:rest_rt

REST_RT(i,:)=P_RT(i,:);

end

%completamento matrice di permutazioni

M_RT((rip_rt*p_rt+1):T,:)=REST_RT(1:rest_rt,:);

end

%MATRICE DI PERMUTAZIONI SORGENTI NON REAL TIME


if p_nrt>T

M_NRT(1:T,:)=P_NRT(1:T,:);

else

%numero di permutazioni complete della matrice NRT

rip_nrt=floor(T/p_nrt);


rest_nrt=round(((T/p_nrt)-rip_nrt)*p_nrt);

%inizializ. matrice (Txnrt) di permutazioni delle Sorgenti Non Real Time

M_NRT=zeros(T,nrt);

M_NRT(1:p_nrt,:)=P_NRT;

for i=1:(rip_nrt-1)

M_NRT((i*p_nrt+1):((i+1)*p_nrt),:)=P_NRT;

end

REST_NRT=zeros(rest_nrt,nrt);

%matrice (rest_nrt x nrt) di riempimento

for i=1:rest_nrt

REST_NRT(i,:)=P_NRT(i,:);

end


M_NRT((rip_nrt*p_nrt+1):T,:)=REST_NRT(1:rest_nrt,:);

end

%MATRICE DI PERMUTAZIONI SORGENTI BEST EFFORT

95


if p_be>T

M_BE(1:T,:)=P_BE(1:T,:);

else

%numero di permutazioni complete della matrice BE

rip_be=floor(T/p_be);


rest_be=round(((T/p_be)-rip_be)*p_be);

%inizializ. matrice (Txnrt) di permutazioni delle Sorgenti Best Effort

M_BE=zeros(T,be);

M_BE(1:p_be,:)=P_BE;

for i=1:(rip_be-1)

M_BE((i*p_be+1):((i+1)*p_be),:)=P_BE;

end

REST_BE=zeros(rest_be,be);

%matrice (rest_be x be) di riempimento

for i=1:rest_be

REST_BE(i,:)=P_BE(i,:);

end


M_BE((rip_be*p_be+1):T,:)=REST_BE(1:rest_be,:);

end

%MATRICE GLOBALE DI PERMUTAZIONI

M=[M_RT M_NRT M_BE];

%MAPPATURA DELLA MATRICE DI SORGENTE

S_map=zeros(T,N);

for i=1:T

for j=1:N

S_map(i,j)=S(i,M(i,j));

end

end

%MATRICE ALLOCAZIONE BUFFERS


%inizializ. matrice (T+1)xN allocazione buffer

H=zeros(T+1,N);

%vettore riga mappato delle richieste individuali medie di banda.

for i=1:N

req(i)=S_req(M(1,i));

end

H(1,:)=req;

a=ones(1,N)*outR; %inizializ. vettore riga risorsa disponibile

for i=2:T+1

for j=1:N

if (S_map(i-1,j)+H(i-1,j)-a(j))>0

H(i,j)=S_map(i-1,j)+H(i-1,j)-a(j);

96

else

H(i,j)=0;

end

%vettore riga risorsa disponibile per le sorgenti successive

if (a(j)-S_map(i-1,j)-H(i-1,j))>0

a(j+1)=a(j)-S_map(i-1,j)-H(i-1,j);

else

a(j+1)=0;

end

end

end

H_agg=sum(H');


ottenuta:

0 100 200 300 400 500 600 700 800 900 1000

0

50

100

150

200

250

300

350

400

450- Buffer allocation - Round Robin - Total Delay -

- Ts -

- Delay [Ts] -

Figura 44 - Allocazione Round Robin

97

5.4.2. Scheduling con allocazione pesata di banda

A ciascuna classe di servizio è assegnato un ritardo massimo consentito ed un peso, ovvero una percentuale di banda dedicata.

La banda è assegnata in modo equo e dinamico in base alla classe di appartenenza ed al

numero di sorgenti concorrenti.

Istante per istante, infatti, i pesi delle singole classi di servizio normalizzati sul numero

di code non vuote ad esse appartenenti, sono aggiornati in modo da minimizzare il

ritardo complessivo medio e garantire lo scostamento minimo dal ritardo massimo

consentito.

In questo modo le code a priorità maggiore sono in grado di prelazionare banda a quelle

che ne richiedono di meno, migliorando l’efficienza di allocazione a spese

dell’isolamento tra le sorgenti.

Nel caso peggiore, in cui tutte le code sono non vuote, al flusso Λ è comunque garantita

una banda minima ,minrΛ pari a

,mini

i

r outRM

ϕΛ = ⋅

dove iϕ è il peso assegnato all’ i-esima classe di servizio, e Mi rappresenta il numero di

sorgenti ad essa appartenenti.

Durante le simulazioni di seguito descritte si ipotizza uno scenario in cui le classi di

servizio, i pesi iniziali, e i ritardi massimi consentiti, sono distribuiti come segue:

Service Class Type Sources Weight Max Delay [Ts]

Real Time 6, 8, 10 0.20 20

Non Real Time 1, 3, 5, 7, 9 0.35 50

Best Effort 2, 4 0.45 100

Tabella 7 - Scenario simulazione

98

5.4.2.1. Algoritmo di minimizzazione del ritardo complessivo medio

Indicati con non_empty(i,k) il numero di code appartenenti alla classe k non vuote

all’istante i, e con maxdelay(k) il massimo ritardo consentito alla classe k, è possibile

esprimere, per ogni istante i, il ritardo complessivo medio E(i,k) come segue:

3 3

31 1

1

1 max ( )( , ) _ ( , ) 1 ( , )

( , )_ ( , ) k k

k

delay kE i k non empty i k w i k

w i knon empty i k

λ= =

=

= − −

∑ ∑

∑

in cui 3

1

1 ( , )k

w i kλ=

−

∑ rappresenta un termine di compensazione nel caso ci fossero

delle code vuote.

Volendo minimizzare questa funzione, è necessario ricavarne la derivata prima rispetto

al parametro peso w(i,k), e porla uguale a zero:

3 2

1

( , ) 1 _ ( ) max ( )0;

( , )_ ( )

k

E i k non empty k delay k

w w i knon empty k

λ

=

∂ −= ⋅ + =

∂∑

3

1

1 _ ( , ) max ( )( , )

_ ( , )k

non empty i k delay kw i k

non empty i kλ

=

⇒ = ⋅

∑ (1)

Il fattore di compensazione risulta esprimibile come segue:

3 2

1

1 _ ( )max ( )( , ) ;

( , )_ ( )

k

non empty k delay ki k

w i knon empty k

λ

=

= ⋅

∑

99

moltiplicando ambo i membri per

3

1

( , )k

w i k=

∑ si ottiene:

3 3

31 1

1

1 _ ( ) max ( )( , ) ;

( , )_ ( )k k

k

non empty k delay kw i k

w i knon empty k

λ= =

=

= ⋅∑ ∑∑

Sostituendo quanto ottenuto nella (1), si ottiene l’espressione istantanea del peso che

minimizza il ritardo complessivo medio:

3

133

11

3

1

_ ( , )_ ( ) max ( )

( , )_ ( ) max ( ) _ ( )

( , )

_ ( ) max ( )

_ ( ) max ( )( , )

k

kk

k

non empty i knon empty k delay k

w i knon empty k delay k

non empty kw i k

non empty k delay k

non empty k delay k

w i k

=

==

=

= ⋅ =

=

∑

∑∑

∑

L’unicità della soluzione può essere verificata studiando il segno della derivata seconda:

2

3 323 2

1 1

( , ) 2 _ ( ) max ( ) _ ( ) max ( )0;

( , ) _ ( ) ( , ) _ ( )k k

E i k non empty k delay k non empty k delay k

ww i k non empty k w i k non empty k

= =

∂= − >

∂∑ ∑

essendo convessa, l’espressione ricavata corrisponde ad un minimo assoluto.

L’algoritmo implementato nella funzione bwconstraint.m aggiorna ad ogni istante

i, il vettore dei pesi w(i,k), e lo normalizza al numero di code della classe k non vuote.

bwconstraint.m

function [L,E]=bwconstraint(S,N,T,RT,NRT,BE,BC_RT,BC_NRT,BC_BE,class)

100

%Weighted Scheduling for Delay Minimization.

%

%Sintassi: [L,E]=bwconstraint(S,N,T,RT,NRT,BE,BC_RT,BC_NRT,BC_BE,class);

%

%Dati in ingresso: (S,N,T,RT,NRT,BE,BC_RT,BC_NRT,BC_BE,class)

%











% BC_NRT : Limite percentuale di banda assegnata alla classe Non Real Time;

% BC_BE : Limite percentuale di banda assegnata alla classe Best Effort;

% class : Vettore assegnazione dell'identificativo della classe

% d'appartenenza.

%

%Restituisce: [L,E]

%

% L : matrice (TxN) le cui colonne contengono le allocazioni istantanee dei

% buffers associati alle singole sorgenti;

% E : ritardo complessivo medio minimo.

fprintf('\nScheduling by Bandwidth Constraints Assignment.\n');


%Ritardo massimo consentito per ciascuna classe di servizio

string=['Real Time '; 'Non Real Time'; 'Best effort '];

for k=1:3

fprintf('\nRitardo massimo consentito (in termini di slots)

… alla classe di servizio %s: ',string(k,:));

maxdelay(k)=input('');

end

%Vettore pesi

weight=[BC_RT BC_NRT BC_BE];

%Matrice delle code

%algoritmo di minimizzazione del ritardo complessivo medio

L=zeros(T,N);

non_empty=zeros(T,3);

L(1,:)=S(1,:);

for k=1:3

non_empty(1,k)=sum(((L(1,:)~=0).*class)==k);

w(1,k)=sqrt(non_empty(1,k)*maxdelay(k)/ …

… sum(non_empty(1,:).*maxdelay./weight(1,:)));

end

weight(1,:)=w(1,:)/sum(w(1,:));

for i=2:T

L(i,:)=L(i-1,:)+S(i,:);

for k=1:3

non_empty(i,k)=sum(((L(i,:)~=0).*class)==k);

101

end

if sum(non_empty(i,:)~=0)

for k=1:3

w(i,k)=sqrt(non_empty(i,k)*maxdelay(k)/ …

… sum(non_empty(i,:).*maxdelay./weight(1,:)));

end

weight(i,:)=w(i,:)/sum(w(i,:));

else

w(i,:)=0;

weight(i,:)=w(i,:);

end

for j=1:N

if L(i,j)~=0

if (L(i,j)-floor(weight(i,class(j))*outR/non_empty(i,class(j))))>0

L(i,j)=L(i,j)- …

… floor(weight(i,class(j))*outR/non_empty(i,class(j)));

else

L(i,j)=0;

end

end

end

end


ottenuta:

0 100 200 300 400 500 600 700 800 900 10000

200

400

600

800

1000

1200

1400

1600

1800- Buffer allocation - Bandwidth Constraints -

- Ts -

- D

ela

y [

Ts]

-

Figura 45 - Allocazione con Bandwidth Constraints

102

La Figura 46 mostra invece l’accodamento dal punto di vista delle singole sorgenti:

Figura 46 - Allocazione individuale con Bandwidth Constraints

Le attese sono sotto soglia soltanto per le classi NonReal Time e Best Effort.

A soffrire ritardi consistenti sono proprio le sorgenti Real Time.

Possibili cause:

• distribuzione dei bit rates: nell’assegnazione delle sorgenti alle diverse SCT è

stato tenuto conto del fatto che la richiesta di banda da parte delle sorgenti RT è

generalmente maggiore, quindi sono RT proprio quelle sorgenti con bit rates più

alti, ma per questo probabilmente più soggette ad accodamenti;

• ritardi massimi consentiti: potrebbero essere troppo stringenti rispetto alla

capacità di trasferimento imposta (outR=250);

103

La Figura 47 mostra il ritardo complessivo medio minimo:

0 100 200 300 400 500 600 700 800 900 100010

15

20

25

30

35

40- Minimum Weighted Mean Delay -

- Ts -

- D

ela

y [

Ts]

-

Figura 47 - Ritardo complessivo medio minimo

1.1.1. Weighted Fair Queueing

Per ogni pacchetto emesso si valuta il numero NR di round necessari a trasferirlo.

Tra quelli sottoposti allo scheduler viene trasferito il pacchetto avente il valore di NR

minore.

Le code sono servite in modalità Round Robin: in ciascun round si trasmettono φi bit da

ciascuna coda; si saltano le code vuote.

104

Classifier

Arriving

Packets

S1

S2

SN φN

φ1

φ2

Λi

Classifier

Arriving

Packets

S1

S2

SN φN

φ1

φ2

Λi

OutR

Classifier

Arriving

Packets

S1

S2

SN φN

φ1

φ2

Λi

Classifier

Arriving

Packets

S1

S2

SN φN

φ1

φ2

Λi

OutR

Classifier

Arriving

Packets

S1

S2

SN φN

φ1

φ2

Λi

Classifier

Arriving

Packets

S1

S2

SN φN

φ1

φ2

Λi

OutR

Classifier

Arriving

Packets

S1

S2

SN φN

φ1

φ2

Λi

Classifier

Arriving

Packets

S1

S2

SN φN

φ1

φ2

Λi

OutR

Figura 48 - Schema Weighted Fair Queueing

wfq.m

function [Q]=wfq(S,N,T,bitR,RT,NRT,BE,BC_RT,BC_NRT,BC_BE)

%Weighted Fair Queueing

%

%Sintassi: [Q]=wfq(S,N,T,bitR,RT,NRT,BE,BC_RT,BC_NRT,BC_BE);

%

%Dati in ingresso: (S,N,T,bitR,RT,NRT,BE,BC_RT,BC_NRT,BC_BE)

%




% bitR : vettore riga (1xN) contenente i bit rates delle singole sorgenti;








% BC_NRT: Limite percentuale di banda assegnata alla classe Non Real Time;

% BC_BE : Limite percentuale di banda assegnata alla classe Best Effort.

%Restituisce: [Q]

%

% Q : matrice (TxN) le cui colonne contengono le allocazioni

% istantanee dei buffers associati alle singole sorgenti.

fprintf('\nWeighted Fair Queueing\n');


%assegnazione dei pesi alle singole sorgenti in base alla SCT d'appartenenza

for j=1:N

if sum(j==RT)

phi(j)=BC_RT*outR;

elseif sum(j==NRT)

phi(j)=BC_NRT*outR;

else

105

phi(j)=BC_BE*outR;

end

end

%matrice istanti di arrivo dei pacchetti

arrival=zeros(T,N);

for i=1:T

for j=1:N

if S(i,j)~=0

arrival(i,j)=i-1;

end

end

end

%matrice marcatura pacchetti

NR=zeros(T,N);

for j=1:N

NR(1,j)=ceil(S(1,j)/phi(j));

end

for i=2:T

for j=1:N

if S(i,j)==0

NR(i,j)=0;

elseif isempty(nonzeros(NR(1:i-1,j)))

NR(i,j)=arrival(i,j)+ceil(S(i,j)/phi(j));

else

nozero=nonzeros(NR(1:i-1,j));

NR(i,j)=max(arrival(i,j),nozero(nnz(nozero)))+ …

… ceil(S(i,j)/phi(j));

end

end

end

%Matrice delle code in termini di numero di pacchetti

QUEUE=zeros(T,N);

NRcopy=NR;

for j=1:N

if NRcopy(1,j)==min(nonzeros(NRcopy(1,:)))

NRcopy(1,j)=0;

QUEUE(1,:)=NRcopy(1,:)~=0;

break

end

end

for iter=2:T

least=0;

columns=0;

for i=1:iter

for j=1:N

if isempty(nonzeros(NRcopy(i,:)))

break

elseif NRcopy(i,j)==min(nonzeros(NRcopy(i,:)))

columns(i)=j;

least(i)=NRcopy(i,j);

break

end

end

end

106

for k=1:size(least,2)

if least(k)==min(nonzeros(least))

NRcopy(k,columns(k))=0;

break

end

end

if k==iter

QUEUE(iter,:)=QUEUE(iter-1,:)+(NRcopy(k,:)~=0);

else

QUEUE(iter,:)=QUEUE(iter-1,:)+(NRcopy(iter,:)~=0);

QUEUE(iter,columns(k))=QUEUE(iter,columns(k))-1;

end

end

%Matrice delle code

for j=1:N

Q(:,j)=QUEUE(:,j).*bitR(j);

end

Come è possibile constatare dai grafici seguenti, l’algoritmo diverge anche piuttosto

rapidamente. E’ probabile che non sia possibile modellare in questo modo questo

specifico scenario, in quanto delle condizioni al contorno potrebbero non essere

verificate, o siano state erroneamente trascurate.

Posto l’output rate outR=250, la Figura 49 mostra l’andamento delle singole code

d’attesa ottenute:

0 100 200 300 400 500 600 700 800 900 10000

0.5

1

1.5

2

2.5x 10

4 Buffer allocation - Weighted Fair Queueing

- Ts -

- D

ela

y [

Ts]

-

Figura 49 - Allocazione Weigthed Fair Queueing

107

6. Algoritmi per l’allocazione di banda: analisi preliminare e procedure Matlab

5.1 Generazione di N Sorgenti binarie

Lo scenario è composto da una Base Station (BS) posta all’interno dell’area di copertura

di una WMAN, nella quale sono presenti un certo numero di dispositivi (PDA, Laptop).

Lo standard IEEE 802.16 suddivide il traffico offerto in quattro classi di servizio:

• Unsolicited Grant Services (UGS): flussi a bit-rate costante (CBR) che

necessitano di allocazione di banda garantita costante, senza richiesta;

• real-time Polling Services (rtPS): flussi real-time a bit-rate variabile (VBR) che

necessitano di una banda minima garantita, cui accedono previa richiesta accettata

dalla BS tramite un meccanismo di polling;

• non-real-time Polling Services (nrtPS): per questa tipologia di traffico il polling

delle richieste di allocazione di banda è previsto soltanto nel caso in cui ci sia

necessità di disporre di una banda minima, altrimenti la richiesta avviene per

contesa;

• Best Effort Services (BES): per questa topologia di traffico la richiesta di

allocazione di banda avviene esclusivamente per contesa, e non viene garantita

un’allocazione minima di risorse.

Nella presente analisi sono esaminate soltanto due classi di servizio:

108

• UGS: sono considerati 20 flussi VoIP;

• BES: sono considerati 50 flussi http.

Nel caso dei flussi BES, la richiesta di banda avviene tramite l’invio di una specifica

unità dati, costituita dal Connection IDentifier (CID), associato al singolo flusso. Ciò

significa che ad un singolo utente possono essere attribuiti più flussi

contemporaneamente (ad esempio potrebbe navigare in rete mentre partecipa ad una

conferenza VoIP).

L’analisi è condotta evitando di introdurre situazioni limite, come congestione e rete

scarica.

L’asse temporale è considerato slottato in frames della durata di 1ms, ognuno dei quali è

costituito da 5000 Slots fisici (Phy-Slots - PS).

Lo schema di modulazione adottato è un 16-QAM, mentre il bit-rate è 80 Mbps. Ciò

implica che in ogni PS siano presenti 4 simboli di modulazione da 4 bits l’uno.

Figura 50 - Struttura frame

109

1.2. Approccio proposto

Gli aspetti su cui l’analisi è focalizzata sono: l’algoritmo di richiesta a contesa per le

connessioni BES, la dimensione massima delle unità di trasmissione, e l’allocazione

dinamica delle risorse.

L’algoritmo di richiesta a contesa è realizzato mediante un protocollo ALOHA-like: in

ogni frame è presente una zona di contesa delimitata stabilendo di volta in volta una

soglia statica, all’interno della quale i CIDs trasmettono messaggi di richiesta

scegliendo un PS con probabilità uniforme; la BS è l’unica che può rilevare le collisioni,

in quanto il sistema è broadcast, quindi in seguito alle operazioni di rilevamento delle

collisioni e di scheduling, essa invia un messagio di ACK (contenente anche il valore

della banda allocata) o NACK ad ogni CID.

La risorsa disponibile, una volta allocato il traffico UGS e stabilita l'estensione della

contention zone,viene dunque condivisa dai soli flussi BES autorizzati dalla BS, ovvero

da quelli non coinvolti in collisioni.

La dimensione massima dell'unità di trasmissione (MTU) per flusso BES è comunque

fissata a 1500 Bytes.

Questa procedura interessa ovviamente soltanto i flussi BES, in quanto quelli VoIP

godono di una banda garantita tale che i ritardi siano inferiori al ritardo massimo

consentito di 200-250 ms, per consentire l’intelligibilità del segnale dopo la

ricostruzione dell’informazione.

1.3. Risultati numerici

110

Per eseguire l’analisi al calcolatore ed impostare i parametri iniziali, è necessario

lanciare lo script Fantacci.m , in cui vengono chiamate le funzioni descritte di

seguito.

Fantacci.m

N_voip=20; %sorgenti VoIP

BR_voip=64; %64 Kbps -> 64bit per frame

INTER_voip=3e3; %tempo medio di interarrivo [ms]

N_bes=50; %sorgenti Best Effort

MTU=12e3; %3GPP Maximum Transmission Unit 1500Byte -> 12Kb

INTER_bes=8.3; %tempo medio di interarrivo [ms]

N_frames=1e5; %100 secondi

outR=8e4; %80 Mps -> 80Kbit per frame

%dati distribuzione di Pareto

k=81.5*8; %location parameter (lunghezza minima messaggio) [bit]

m=66666*8; %lunghezza massima messaggio [bit]

a=1.1; %shape parameter

%vettore Contention Slots

%C_slot=[15 20 25 35 45];

C_slot = input('\n\nInserire il numero di Contention Slots: ');

%numero complessivo di bit/frame destinati al traffico VoIP

alloc_v = VoIP(N_frames,INTER_voip,N_voip,BR_voip);

%matrice delle code, # messaggi/frame, # collisioni/frame

[queue,N_msg,N_col] = …

… BES(N_frames,C_slot,k,m,a,N_bes,INTER_bes,MTU,outR,alloc_v);

% # messaggi/secondo

Mps=zeros(1,N_frames/1000);

for i = 0:(N_frames/1000 -1)

Mps(i+1)=sum(N_msg(1+i*1000:(i+1)*1000));

end

avg_MSG = mean(Mps)

% # medio di Byte in coda/secondo

avg_queue = (mean(queue,2))/8;

Qps=zeros(1,N_frames/1000);

for i = 0:(N_frames/1000 -1)

Qps(i+1)=sum(avg_queue(1+i*1000:(i+1)*1000));

end

avg_QUEUE = mean(Qps)

% (# collisioni/# slots)/secondo

Cps=zeros(1,N_frames/1000);

for i = 0:(N_frames/1000 -1)

111

Cps(i+1)=sum(N_col(1+i*1000:(i+1)*1000));

end

avg_COL = mean(Cps)/C_slot

1.3.1. Generazione di N sorgenti VoIP

I flussi VoIP sono modellati attraverso una catena di Markov a due stati del primo

ordine, con tempi di interarrivo esponenziali con valore medio 3 s, e bit-rate 64 Kbps.

VoIP.m

function alloc_v=VoIP(N_frames,INTER_voip,N_voip,BR_voip)

%

%Sintassi: alloc_v = VoIP(N_frames,INTER_voip,N_voip,BR_voip);

%

%Dati in ingresso: (N_frames,INTER_voip,N_voip,BR_voip)

%

% N_frames : lunghezza (in termini di frames) del periodo di

% osservazione;

% INTER_voip : tempo medio di interarrivo [ms];

% N_voip : numero di sorgenti VoIP;

% BR_voip : Bit-Rate delle sorgenti VoIP (ammesso costante

% per tutte);

%

%Restituisce: [alloc_v]

%

% alloc_v : vettore (1xN_frames) contenente il numero complessivo

% di bit/frame destinati al traffico VoIP.

%MATRICE SORGENTI VoIP

%inizializzazione vettore sorgenti voip

voip=zeros(1,N_voip);

%Inizializzazione vettore allocazione complessiva di risorse

alloc_v=zeros(1,N_frames);

%mediamente: sorgenti on = sorgenti off

voip(:)=(rand(1,N_voip)>=0.5)*BR_voip;

%allocazione complessiva di risorse

alloc_v(1) = sum(voip);

%inizializzazione vettore tempi di interarrivo voip a regime

tau_v=zeros(N_voip);

tau_v=exprnd(INTER_voip,1,N_voip)/2; %Esponenziale

stop_v=tau_v; %scadenza

112

for i=2:N_frames

for j=1:N_voip

if i > ceil(stop_v(j))

%commutazione sorgente voip

voip(j)=(voip(j)==0)*BR_voip;

%aggiornamento scadenza

tau_v(j)=exprnd(INTER_voip);

stop_v(j)=stop_v(j)+tau_v(j);

end

end

alloc_v(i)=sum(voip);

end

1.3.2. Generazione di N sorgenti BES

I flussi BES, presentano tempi di interarrivo basati su una distribuzione di Poisson, e

lunghezza dei pacchetti variabile secondo una distribuzione di Pareto troncata, avente la

seguente funzione di densità di probabilità:

In cui α = 1.1 rappresenta il parametro di forma, k = 81.5 Byte la lunghezza minima dei

pacchetti, ed m = 66666 Byte quella massima.

BES.m

function [queue,N_msg,N_col] = …

… BES(N_frames,C_slot,k,m,a,N_bes,INTER_bes,MTU,outR,alloc_v)

%Genera una matrice di traffico BES secondo le specifiche stabilite

%mediante la quale determina per ogni frame il numero di messaggi generati

%e il numero di collisioni avvenute,e una matrice delle code.

%

%Sintassi:

%[queue,N_msg,N_col] = …

… BES(N_frames,C_slot,k,m,a,N_bes,INTER_bes,MTU,outR,alloc_v);

%

1,

( ) ,

0 , ,

kk x m

x

kf x x m

m

x k x m

α

α

α

α

α+

≤ <

= =

< >

113

%Dati in ingresso: (N_frames,C_slot,k,m,a,N_bes,INTER_bes,MTU,outR,alloc_v)

%

% N_frames : lunghezza (in termini di frames) del periodo di osservazione;

% C_slot : ampiezza in termini di PHY-slots dell'intervallo di contesa;

% k : location parameter (lunghezza minima messaggio);

% m : lunghezza massima messaggio;

% a : shape parameter;

% N_bes : numero di sorgenti BES;

% INTER_bes : tempo di interarrivo tra i pacchetti BES;

% MTU : Maximum Transmission Unit;

% outR : Output Rate del sistema;

% alloc_v : vettore (1xN_frames) contenente il numero complessivo di

% bit/frame destinati al traffico VoIP;

%

%Restituisce: [queue,N_msg,N_col]

%

% queue : matrice (N_framesxN_bes) del numero di bit presenti in coda;

% N_msg : vettore (1xN_frames) del numero di messaggi pervenuti;

% N_col : vettore (1xN_frames) del numero di collisioni avvenute.

%viene trascurato l'overhead (header + CRC) dei pacchetti

%Bandwidth Request costituito solo dall'header:

% Header: 6Byte -> 48bit

% 1 Phy-slot = 16bit

% => BW request occupa 3 Phy-slots!

%per semplicità non considero la richiesta specifica di banda ma solo la

%prenotazione (l'assegnazione è di max 1 MTU o inferiore qualora il payload

%non fosse completo), costituita dal campo dell'header relativo

%all'identificativo di connessione.

% CID: 2Byte -> 16bit => 1 Phy-slot.

%Ogni frame presenta una contention zone di lunghezza variabile secondo i

%valori imposti nel vettore C_slot.

%L'accesso ad un contention slot da parte delle sorgenti richiedenti

%avviene con probabilità uniforme.

%Nel caso di collisione nessuna delle sorgenti coinvolte potrà

%trasmettere, e aggiornerà la coda di servizio.

%inizializzazione vettore contention slots di accesso delle sorgenti

%Le sorgenti si prenotano con due frames di anticipo per permettere alla

%stazione base di rispondere con un messaggio di consenso (ACK)

%o negazione (NACK)

CS=zeros(3,N_bes);

CS(2,:)=1+round(rand(1,N_bes)*(C_slot-1));

%inizializzazione vettore scadenze e tempi di interarrivo bes

stop_b=zeros(1,N_bes);

tau_b=zeros(1,N_bes);

%inizializzazione matrice delle code

queue=zeros(N_frames,N_bes);

%inizializzazione vettore allocazione complessiva di risorse

alloc_b=zeros(1,N_frames);

114

%inizializzazione vettore numero di collisioni/frame

N_col=zeros(1,N_frames);

%inizializzazione vettore numero di messaggi/frame

N_msg=zeros(1,N_frames);

%mediamente 1/8.3 sorgenti on

%a regime -> divido per 2

for j=1:N_bes

len(j) = (rand<=(1/INTER_bes))*round(Prnd(k,m,a)/2);

end

%risorsa disponibile per singolo flusso

if length(find(len))

available = (outR-alloc_v(1)-C_slot*16)/length(find(len));

else

available=MTU+1;

end

%massimizzata dalla Maximum Transmition Unit

rsc = min(MTU,available);

%primo frame

for j=1:N_bes

if len(j) <= rsc

queue(1,j)=0;

else

queue(1,j)=len(j)-rsc;

CS(3,j)=1+round(rand*(C_slot-1)); %backoff

end

%tempi di interarrivo a regime

tau_b(j)=poissrnd(INTER_bes,1)/2; %Poisson

stop_b(j)=tau_b(j); %scadenza

end

%restanti frames

for i=2:N_frames

%identificazione sorgenti coinvolte in collisioni

if mod(i,3)==0

k=3;

else

k=mod(i,3);

end

[involved,new_col] = find_collision(N_bes,CS(k,:));

%aggiornamento numero di collisioni

N_col(i)=new_col;

%# sorgenti effettivamente in tx

on_air = nnz(CS(k,:))-new_col;

for j=1:N_bes

if i > ceil(stop_b(j))

len(j)=Prnd(k,m,a);

%aggiornamento scadenza

tau_b(j)=poissrnd(INTER_bes);

stop_b(j)=stop_b(j)+tau_b(j);

115

else

len(j)=0;

end

end

%aggiornamento numero di messaggi pervenuti

N_msg(i)=nnz(len);

%risorsa disponibile per singolo flusso

if on_air

available = (outR-alloc_v(i)-C_slot*16)/on_air;

else

available=MTU+1;

end

%massimizzata dalla Maximum Transmition Unit

rsc = min(MTU,available);

for j=1:N_bes

%verifica collisione

if sum(j==involved)

queue(i,j)=queue(i-1,j)+len(j);

%colliso -> coda sicuramente non vuota -> BW REQ

if mod(i+2,3)==0

k=3;

else

k=mod(i+2,3);

end

%aggiornamento backoff

CS(k,j)=1+round(rand*(C_slot-1));

else

if queue(i-1,j)+len(j) <= rsc

queue(i,j)=0;

else

queue(i,j)=queue(i-1,j)+len(j)-rsc;

if mod(i+2,3)==0

k=3;

else

k=mod(i+2,3);

end

%aggiornamento backoff

CS(k,j)=1+round(rand*(C_slot-1));

end

end

end

end

1.3.3. Generazione di una variabile aleatoria con distribuzione di Pareto

troncata

Prnd.m

function msg_len=Prnd(k,m,a)

%generazione v.a. con distribuzione di Pareto troncata tramite

116

%trasformazione inversa della funzione di distribuzione

%

%Sintassi: msg_len = Prnd(k,m,a);

%

%Dati in ingresso: (k,m,a)

%

% k : location parameter, corrisponde alla lunghezza minima del

messaggio;

% m : massima lunghezza del messaggio;

% a : parametro di forma;

%

%Restituisce: [msg_len]

%

% msg_len : v.a. con distribuzione di Pareto troncata rappresentante la

% lunghezza del messaggio.

D=1-(k/m)^a;

U=rand*D;

msg_len=round(k*(1-U)^(-1/a));

1.3.4. Rilevamento delle collisioni

Find_collision.m

function [involved,new_col] = find_collision(N_bes,CS)

%Indica quali sorgenti hanno colliso.

%

%Sintassi: [involved,new_col] = find_collision(N_bes,CS);

%

%Dati in ingresso: (N_bes,CS)

%

% N_bes : numero di sorgenti Best Effort Service;

% CS : vettore (1xN_bes), estratto dalla matrice di registro omonima,

% dei contention slots;

%

%Restituisce: [involved,new_col]

%

% involved : vettore (1xN_col) degli indici delle sorgenti coinvolte in

collisioni;

% new_col : numero di sorgenti coinvolte in collisioni.

for j=1:N_bes

match(j,:) = CS(:)==CS(j);

end

involved = find(sum(match - eye(N_bes)));

new_col=length(involved);

117

1.3.5. Analisi grafica

In Figura 51 è mostrato l’evoluzione del numero di messaggi generati dal sistema

nel periodo di osservazione di 100 s.

Figura 51 - Numero di messaggi generati per secondo

L’analisi è svolta esaminando la lunghezza media complessiva della coda [Bytes/s] e la

percentuale di collisioni [Collisions#/s] al variare dell’estensione della zona di contesa.

I grafci seguenti mostrano gli andamenti delle grandezze osservate per zone di

collisione di 15, 25, e 45 slots, evidenziando i loro valori medi di riferimento.

118

Figura 52 - Percentuale di collisioni [15 Contention Slots]

Figura 53 - Lunghezza media della coda [15 Contention Slots]

119



120



121

1.4. Conclusioni

I risultati ottenuti suggeriscono che l’algoritmo di allocazione dinamica funziona

meglio fissando l’estensione della zona di contesa ad un numero di slots pari alla

metà del numero di flussi BES. Infatti è possibile notare che una zona di contesa di

15 PS risulta essere sottodimensionata, in quanto si osserva, istante per istante, un

gran numero di collisioni rispetto al numero di messaggi generati, e valori di ritardo

mediamente più alti che negli altri casi esaminati. Come ci si aspetta, aumentando

l’estensione della zona di contesa si osserva una diminuzione del numero medio di

collisioni occorse, mentre la lunghezza media complessiva della coda presenta un

minimo nel caso di 25 PS. Ciò è spiegabile considerando che al diminuire delle

collisioni aumenta il numero delle connessioni che ottengono l’accesso al mezzo,

causando una diminuzione della risorsa disponibile.

Si può concludere dunque, che un approccio di questo genere, benché garantisca

ottime prestazioni alle connessioni VoIP, potrebbe risultare poco efficiente dal

punto di vista della QoS offerta alle connessioni BES.

122

Appendice A – Il Protocollo SNMP

SNMP (Simple Network Management Protocol) è un protocollo a livello di applicazione

definito per introdurre una semplice architettura per la gestione di reti basate sulla suite

di protocolli UDP/IP, come si può osservare in Errore. L'origine riferimento non è

stata trovata.. Tale protocollo definisce le modalità di scambio di informazioni tra

apparecchiature di rete, consentendo agli amministratori di tenere sotto controllo le

performances della rete e di accorgersi in tempo reale del manifestarsi di

malfunzionamenti.

Attualmente il protocollo presenta tre definizioni successive: SNMPv1, SNMPv2,

SNMPv3.

La versione più recente introduce nel protocollo alcune nuove funzionalità e correzioni,

soprattutto nel campo della sicurezza.

Il protocollo SNMP è attualmente quello più diffuso per la gestione delle reti di

calcolatori ed è supportato praticamente da tutti i produttori di hardware ed

apparecchiature di rete.

L'architettura di cui il protocollo SNMP fa parte, è detta Internet Network Management

Framework (INMF).

123

Figura 58 - SNMP nella pila ISO-OSI

Tale architettura consente di gestire degli elementi di rete (che sono apparecchiature

come router, switch, hub, pc, etc.) usando degli agents, cioè moduli software che

risiedono sulle apparecchiature da gestire, come riportato in Errore. L'origine

riferimento non è stata trovata..

Tali agents comunicano con una stazione di gestione centralizzata (Network

Management Station) che, interagendo con i primi, può leggere o scrivere informazioni

e raccogliere eventuali segnalazioni di errore.

Le informazioni o caratteristiche che è possibile gestire per una particolare

apparecchiatura, mediante il protocollo SNMP, verranno indicati come oggetti gestiti.

L'insieme di questi oggetti costituisce un'astrazione di database detta Management

Information Base (MIB).

124

Figura 59 - Schema logico di un sistema di Network Management

125

A.1 La struttura delle informazioni di gestione

La “Structure of Management Information” (SMI) ha il compito di definire, in modo

standard, come devono essere strutturati gli oggetti gestiti e la loro gerarchia per essere

inseriti nel database MIB e quindi gestiti da una entità SNMP. La definizione degli

oggetti gestiti può essere vista secondo tre aspetti fondamentali:

• NOME - Il nome, o object identifier (OID), definisce unicamente un oggetto

gestito. I nomi vengono visualizzati comunemente in due forme: numerica e

letterale.

• TIPO E SINTASSI - Il tipo di dato associato ad un oggetto gestito viene definito

usando il Abstract Syntax Notation One (ASN.1). Tale sintassi risulta indipendente

dal tipo di macchina utilizzata e ciò rende tale notazione molto conveniente e

altamente portabile.

• ENCODING - Il meccanismo di codifica e decodifica del codice usato segue le

regole del Basic Encoding Rules (BER).

Un agent possiede una lista contenente tutti gli oggetti che dovrà gestire e che potranno

via via essere chiesti dalla stazione di gestione. Ad esempio un oggetto può

rappresentare lo stato di funzionamento di una interfaccia (up, down o testing).

La “Management Information Base” (MIB) può essere pensata come un database di

oggetti gestiti.

Ogni tipo di informazione alla quale può accedere un sistema di gestione è definita in

una MIB. In pratica come un dizionario raccoglie in sè tutte le parole con i relativi

significati, così una MIB definisce un nome per un oggetto e spiega il suo significato

usando la sintassi SMI.

126

Un esempio di oggetto gestito è il seguente, tratto da RFC 1213:

sysUpTime OBJECT-TYPE

SYNTAX TimeTicks

ACCESS read-only

STATUS mandatory

DESCRIPTION

"The time (in hundredths of a second)

since the network management portion of

the system was last re-initialized."

::= { system 3 }

L'esempio riportato riguarda l'oggetto sysUpTime, ovvero il tempo trascorso da quando

il sistema che lo gestisce è stato riavviato.

Gli oggetti gestiti sono organizzati secondo una gerarchia ad albero, come si può vedere

in Errore. L'origine riferimento non è stata trovata..

Figura 60 - Struttura ad albero dei MIBs

127

Il nodo da cui parte tutta la struttura dell'albero viene denominato “radice”, root, mentre

qualsiasi altro nodo all'interno dell'albero che non ha altri nodi sotto di sé viene detto

“nodo foglia” o leaf node.

Un OID è costituito da una serie di numeri interi identificanti i nodi dell'albero, separati

da punti.

Nella forma letterale di un OID al posto dei numeri interi troviamo delle parole, per cui

la leggibilità può risultare migliore. Si possono usare, indifferentemente, sequenze di

numeri o di parole.

Come si vede in Errore. L'origine riferimento non è stata trovata. ogni nodo ha un

riferimento sia numerico che letterale, per cui, volendo fare un esempio, l'OID

iso.org.dod.internet.mgmt è equivalente a 1.3.6.1.2.

Partendo dalla radice, possiamo individuare tre nodi:

• L’International Organization for Standardization (ISO), al quale è associato il

numero (1).

• Il Telecommunication Standardization Sector of the International

Telecommunication Union (ITU-T), numero (0).

• Il Joint ISO/ITU-T(2), che mette a comune i due organismi citati.

Sotto uno dei rami dell‘ISO, in particolare quello relativo all’ISO identified

organization (3), si possono trovare le entries per gli standards pubblicati dalle

organizzazioni dei vari paesi membri dell’ISO.

Uno di questi è rappresentato dal dod (6) (US DEPARTEMENT OF DEFENSE), dal

quale deriva il nodo internet (object identifier = 1.3.6.1).

Al di sotto del nodo internet troviamo sette nodi tra cui i più importanti per l’analisi di

rete sono:

• management: questo sottoalbero contiene le definizioni delle MIBs approvate dall’

IAB (Internal Activities Board). Osserviamo che attualmente esistono due versioni:

128

la MIB-I definita nella RFC 1156; e la MIB-II definita nella RFC 1213. Entrambe

sono identificate dallo stesso object identifier = 1.3.6.1.2.1.

• experimental: utilizzato per identificare oggetti che non sono ancora standard.

• private: utilizzato per identificare gli oggetti creati dai vendors (quali Juniper,

Cisco, IBM etc..) per gestire specifiche variabili presenti in un loro prodotto.

Esiste un’organizzazione, la Internet Assigned Numbers Authority (IANA), che gestisce

e regolamenta le concessioni di spazi all'interno dell'albero, sotto il nodo private, per

privati, istituzioni, organizzazioni e compagnie. Ad esempio Cisco ha uno spazio

privato dove poter sperimentare e sviluppare le proprie soluzioni per la gestione SNMP

sotto il ramo iso.org.dod. internet.private.enterprises.cisco o 1.3.6.1.4.1.9.

A.2. Uno sguardo al MIB-II

MIB-II è un gruppo molto importante all'interno dell'albero, in quanto ogni workstation

che supporta SNMP deve anche supportare MIB-II. Essa rappresenta, la seconda

versione della base di informazioni di gestione e il suo sottoramo è suddiviso in più

gruppi, ognuno dei quali presenta diverse informazioni per la gestione e l’analisi della

rete.

La sua definizione può essere consultata all'interno della RFC 1213. La struttura ad

albero contenente la MIB-II è riportata in Errore. L'origine riferimento non è stata

trovata., mentre la

Tabella 8 - Nodi del MIB-II descrive cosa rappresentano i nodi che la compongono.

129

Figura 61 - Struttura del MIB-II

130

Nomi dei MIB-II Groups OID Descrizione

System 1.3.6.1.2.1.1 Definisce una lista di oggetti riguardanti il

sistema operativo.

Interfaces 1.3.6.1.2.1.2

Riporta lo stato di ogni interfaccia di una

periferica gestita, raccogliendo informazioni

sul traffico inviato e ricevuto, sugli eventuali

errori verificatisi, ecc.

ip 1.3.6.1.2.1.4 Riguarda tutti gli aspetti relativi ad IP, incluso

il routing.

icmp 1.3.6.1.2.1.5 Raccoglie statistiche relative a ICMP.

tcp 1.3.6.1.2.1.6

Riguarda il protocollo TCP, e tra le altre cose

fornisce lo stato della connessione (closed,

listen, ecc.).

udp 1.3.6.1.2.1.7 Raccoglie statistiche relative al protocollo

UDP.

egp 1.3.6.1.2.1.8 Riguarda il protocollo EGP.

transmission 1.3.6.1.2.1.10 Non ci sono oggetti gestiti in questo gruppo.

snmp 1.3.6.1.2.1.11

Misura le performances e le statistiche

riguardanti l’utilizzo delle risorse di rete

necessarie al funzionamento del protocollo

SNMP sulla periferica gestita.

Tabella 8 - Nodi del MIB-II

A.3. Funzionamento del protocollo SNMP

Per poter “sfogliare” la MIB e i relativi oggetti gestiti, disponibili su un determinato

nodo della rete, e quindi far comunicare tra loro manager e agent, è necessario, come

detto utilizzare il protocollo SNMP. Con l'aumentare della complessità della rete, il

numero di managers e agents può crescere sensibilmente e con esso anche la

complessità delle relazioni tra le varie entità. Per tale motivo ogni agent deve proteggere

e regolare l'accesso alle proprie MIBs.

Vi sono, quindi, due aspetti che caratterizzano questo tipo di controllo:

131

• L'authentication service: ogni stazione da gestire limita l'accesso alle proprie

MIBs solo ad alcuni managers autorizzati.

• L'access policy: ogni agent fornisce ai vari managers differenti privilegi di

accesso alle informazioni di gestione.

La prima versione di SNMP [RFC 1157] introduce una prima protezione nella

comunicazione, introducendo il concetto di community. Una SNMP community

definisce sia il metodo di autenticazione sia la politica di controllo degli accessi. Ad

ogni community viene assegnato un nominativo unico (community name) che sarà noto

a tutte le stazioni (manager e agent) coinvolte in quella particolare relazione.

Per cui il community name svolge il ruolo di parola chiave nella comunicazione tra le

varie workstations, garantendo una limitata autenticazione nella richiesta di

informazioni.

Il community name è presente in ogni messaggio SNMP inviato e viene considerato

valido nel momento in cui siano compatibili il nominativo di comunità della stazione

trasmittente ed il nominativo di comunità della stazione ricevente. Ogni agent può,

inoltre, definire più comunità associate ad un particolare sottoinsieme di MIBs (SNMP

MIB view) caratterizzate da una particolare modalità di accesso: o di sola lettura, o di

lettura e scrittura.

A.4. Formato di un messaggio SNMP

Il Protocol Data Unit (PDU) rappresenta il messaggio che manager e agent utilizzano

per scambiarsi informazioni. Esiste un formato PDU standard per ognuna delle seguenti

operazioni SNMP:

• GetRequest

132

• GetNextRequest

• SetRequest

• GetResponse

• Trap

In particolare il messaggio SNMP, come si vede in Errore. L'origine riferimento non è

stata trovata., è costituito dai seguenti campi:

• Version: specifica la versione del formato SNMP.

• Community Name: contiene il nominativo della comunità.

• Request Id: fornisce ad ogni particolare richiesta un unico identificativo.

• Error Status: è utilizzato per indicare che si è verificato un errore mentre veniva

inviata o ricevuta una richiesta SNMP. I valori assumibili sono cinque:

noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly (4), genErr(5).

• Error Index: identifica quale variabile nel campo Variable Bindings è errata

quando il valore ricevuto nell'error status è diverso da zero.

• Variable Bindings: è una lista di vari nomi di oggetti con i rispettivi valori.

• Enterprise: identifica il sottosistema che ha generato un messaggio di tipo trap.

• Agent Addr: contiene l'indirizzo IP dell'agent che ha mandato un messaggio di

tipo trap.

• Generic Trap: specifica il tipo di messaggio trap generato.

• Specific Trap: racchiude informazioni più specifiche sulla natura del messaggio

di trap.

• Time-Stamp: è il tempo trascorso tra l'ultima reinizializzazione dell'entità che ha

generato il messaggio di trap ed il messaggio stesso.

133

Figura 62 - Struttura del pacchetto SNMP

Un'entità SNMP per poter trasmettere uno dei cinque possibili tipi di PDU deve

compiere delle operazioni secondo una determinata cronologia. In primo luogo è

importante definire la notazione con cui la PDU viene costruita, e questa è definita da

ASN.1 e può essere osservata nella RFC 1157. Tramite questa notazione è possibile,

dunque, descrivere e visualizzare vari tipologie di informazioni che un manager può

richiedere.

Dopo aver costruito la PDU, essa è passata, insieme agli indirizzi di sorgente, di

destinazione ed un community name, ad un servizio di autenticazione. Quest'ultimo

compie determinate operazioni (ad esempio l'inserimento di un codice di

autenticazione) e fornisce il risultato ottenuto, che verrà inserito nel messaggio SNMP

che conterrà inoltre sia la versione che il nominativo della comunità.

Infine il messaggio verrà codificato usando le regole base di cifratura e passato ad un

servizio di trasporto, come illustrato in Errore. L'origine riferimento non è stata

trovata..

134

Figura 63 - Funzionamento del protocollo SNMP

Per quanto riguarda la ricezione di un messaggio SNMP, verrà inizialmente effettuato

un controllo della sintassi e della versione del messaggio ricevuto, che può essere

scartato qualora siano riscontrati errori, e in seguito sarà passata ad un servizio di

autenticazione sia la porzione relativa al PDU che quella relativa agli indirizzi di

sorgente e di destinazione.

A.4.1 GetRequestPDU

Tale tipo di PDU viene inoltrato da una stazione di controllo ad un agent per ottenere il

valore di una o più variabili. I nomi delle variabili richieste sono contenute nel campo

variablebindings.

135

La stazione ricevente risponde inviando un messaggio di risposta chiamato

GetResponsePDU, contenente sia lo stesso campo request-id presente nella

GetRequestPDU inoltrata che il campo variablebindings, all'interno del quale sono

inseriti i valori delle variabili richieste, come illustrato in Errore. L'origine riferimento

non è stata trovata..

Figura 64 - Messaggio GetRequestPDU

Quando una di queste variabili non può essere fornita al manager, nessun valore delle

variabili richieste viene restituito; per questo motivo l'operazione GetRequestPDU viene

detta atomica.

I possibili errori che possono verificarsi sono i seguenti:

• Il nome di un oggetto incluso nel campo variablebindings non corrisponde ad

alcun object identifier all'interno delle MIB gestite dall'agent. In questo caso, la

PDU di risposta ha un error-status contenente il valore noSuchName, ed un

valore all'interno del campo error-index indicherà quale variabile ha generato

tale situazione di errore.

• La dimensione della PDU di risposta risulta essere maggiore di una limitazione

locale, in tal caso il campo error-status è impostato al valore toobig.

136

• La stazione ricevente non è capace di soddisfare tutte le richieste del manager

per un motivo ignoto, in questo caso l'error-status contiene il valore genErr.

A.4.2 GetNextRequestPDU

Questo tipo di PDU ha lo stesso formato della GetRequestPDU e si differenzia da

quest'ultima solo per il fatto che, per ogni variabile presente nella “lista” presente nel

campo variablebindings viene restituito il valore dell'elemento successivo nella MIB

considerata.

Attraverso l'utilizzo di questa PDU, il manager può scoprire qual'è la struttura di una

MIB senza doverla conoscere a priori, ed inoltre può ottenere tutti i valori all'interno di

una tabella, nonostante non conosca nulla a riguardo di essa, incluso il numero di righe

e di colonne che la compongono.

Il manager, infatti, si accorge della fine di una tabella nel momento in cui i nomi degli

oggetti inclusi nella lista della PDU di risposta risultano essere differenti da quelli

richiesti.

Anche l'operazione di GetNextRequest, così come quella di GetRequest, viene

dettaatomica, ovvero vengono restituiti tutti i valori contenuti nel campo

variablebindings, oppure, qualora si sia verificata una condizione di errore, nessuno di

essi.

A.4.3 SetRequestPDU

Questa PDU, viene utilizzata dalla stazione di controllo, per assegnare un valore ad un

elemento della MIB di un agent. Per svolgere questa operazione, il campo

variablebindings contiene i nomi ed i relativi valori delle variabili che il manager vuole

137

impostare. In Errore. L'origine riferimento non è stata trovata. è riportata la struttura

del messaggio SetRequestPDU.

La stazione ricevente risponde con una GetResponsePDU contenente anche in questo

caso, lo stesso request-id della PDU di richiesta. Nel caso in cui tutte le variabili

vengano impostate correttamente ai valori voluti dal manager, il campo

variablebindings conterrà i nomi delle variabili ed il rispettivo valore modificato,

altrimenti, se uno dei valori non può essere variato, allora nessuno di essi può essere

aggiornato, ed il campo variablebindings non conterrà alcun valore.

Figura 65 - Messaggio SetRequestPDU

Le possibili condizioni di errore sono le stesse delle altre PDU già descritte, con

l'aggiunta del valore badvalue, a cui viene impostato il campo error-status della PDU di

risposta nel caso in cui venga riscontrata un'incosistenza tra il nome della variabile ed il

relativo valore.

A.4.4 TrapPDU

Un messaggio di tipo Trap, rappresentato graficamente in Errore. L'origine riferimento

non è stata trovata., viene inviato dall'agent per avvisare il manager del verificarsi di

una condizione anomala. Questo tipo di notifica è definita asincrona proprio per

sottolineare la non periodicità di tali messaggi.

138

Figura 66 - Messaggio TrapPDU

Come già accennato, il servizio di trasporto dei messaggi SNMP è basato su un

protocollo non orientato alla connessione (UDP), è quindi possibile che un messaggio

venga perso; ciò risulta disastroso per la notifica di errori o guasti. Per questo motivo ad

una tecnica di tipo event reporting (come è appunto l'invio di messaggi Trap), viene

affiancata una procedura periodica di polling, che risulta ovviamente più affidabile.

Il campo generic-trap può assumere uno dei seguenti valori:

• coldstart(0): l'agent si sta inizializzando;

• warmstart(1): l'agent si sta reinizializzando;

• linkDown(2): un'interfaccia, di cui segue l'identificativo, è stata disattivata;

• linkUp(3): un'interfaccia è stata attivata;

• authenticationFailure(4): il messaggio ricevuto è stato inviato da un manager

con il campo community non valido;

• egpNeighborLoss(5): un host EGP, di cui segue l'indirizzo IP, è stato disattivato;

• enterpriseSpecific(6): si è verificato un evento particolare, specificato nel campo

specific-trap.

Bibliografia

[1] WiMAX Forum, Fixed, nomadic, portable and mobile applications for 802.16-

2004 and 802.16e WiMAX networks, November 2005.

139

[2] IEEE Std 802.16-2004, IEEE Standard for Local and Metropolitan Area

Networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems,

March 2004.

[3] IEEE P802.16e, Draft amendment to IEE standard for local and metropolitan area

networks, Part 16: air interface for fixed and mobile broadband wireless access

systems, amendment for physical and medium access control layers fro combined

fixed and mobile operation in Licentiate bands.

[4] H.R. Anderson, Fixed Broadband Wireless System Design, 2003.

[5] Intel, Scalable OFDMA Physical Layer in IEEE 802.16 WirelessMAN, Agosto

2004.

[6] H. Gowda, R. Lakshmaiah, A slot allocation mechanism for diverse QoS types in

OFDMA based IEEE 802.16e systems, Febbraio 2007.

[7] Intel, Deploying License-Exempt WiMAX Solutions.

[8] Telecom Italia Lab, E. Briola, B. Melis, A. Ruscitto, Sistemi di telecomunicazione

di tipo MIMO con Antenne Multiple in Trasmissione e in Ricezione, Marzo 2004.

[9] E. Guainella, E. Borcoci, M. Katz, P. Neves, L.M. Ribeiro, F. Andreotti, E.

Angori, A. Cimmino, J.Sà Silva, Extending WiMAX to novel and stringent

wireless scenarios: an introduction to the WEIRD Project.

[10] Sixth Framework Programme Priority IST FP6-2005-IST-5.

[11] M. Castrucci, I. Marchetti, C. Nardini, N. Ciulli, G. Landi, A. Ichimescu, P.

Neves, A Framework for Resource Control in WiMAX Networks, Marzo 2007.

[12] Alcatel 7387 user’s Manual - 3BK 10256 0002 TQBJA Ed.01.

[13] Alcatel, F. Sekules, WiMAX Sperimentation, Presentazione FUB, Giugno 2006.

[14] R. Fantacci, D. Tarchi, M. Bardazzi, QoS in IEEE 802.16 WMANs, Marzo 2006.

[15] http://www.ist-weird.eu/, WEIRD Project Intranet.

Prestigiacomo Tesi I livello - Dipartimento Infocom - Il...

Documents

Transcript of Prestigiacomo Tesi I livello - Dipartimento Infocom - Il...