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 53 - Percentuale di collisioni [25 Contention Slots] ................................................. 119
Figura 54 - Lunghezza media della coda [25 Contention Slots]........................................... 119
Figura 55 - Percentuale di collisioni [45 Contention Slots] ................................................. 120
Figura 56 - Lunghezza media della coda [45 Contention Slots]........................................... 120
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)
61
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)
%
% T : lunghezza del periodo di osservazione;
% N : numero di sorgenti;
% 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
78
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)
%
% T : lunghezza del periodo di osservazione;
% 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;
% T : lunghezza del periodo di osservazione;
% N : numero di sorgenti;
% S : matrice (TxN) di sorgente;
% 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)
%
% T : lunghezza del periodo di osservazione;
% N : numero di sorgenti;
% S : matrice (TxN) di sorgente;
% 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
fprintf('\n\nERRORE: la sorgente %d è stata gia'' assegnata alla
classe Real Time.\n',BE(i));
c=0;
while ((c==1)|(c==2))==0
fprintf('\nPremere:\n- [ 1 ] per sostituire la sorgente %d
nella classe Real Time;',BE(i));
fprintf('\n- [ 2 ] per sostituire la sorgente %d nella classe
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
fprintf('\n\nERRORE: la sorgente %d è stata gia'' assegnata alla
classe Non Real Time.\n',BE(i));
c=0;
while ((c==1)|(c==2))==0
88
fprintf('\nPremere:\n- [ 1 ] per sostituire la sorgente %d
nella classe Non Real Time;',BE(i));
fprintf('\n- [ 2 ] per sostituire la sorgente %d nella classe
Best Effort.\n\n',BE(i));
c=input('');
end
if c==1
fprintf('\n\nClasse Non Real Time:\nSostituire la sorgente %d
con la Sorgente n° ',BE(i));
NRT(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
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.
% T : lunghezza del periodo di osservazione;
% S : matrice (TxN) di sorgente;
%
%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)
%
% T : lunghezza del periodo di osservazione;
% N : numero di sorgenti;
% S : matrice (TxN) di sorgente;
% 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
%troncamento in caso di eccesso delle permutazioni
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);
%numero righe della matrice di riempimento
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
%completamento matrice di permutazioni
M_NRT((rip_nrt*p_nrt+1):T,:)=REST_NRT(1:rest_nrt,:);
end
%MATRICE DI PERMUTAZIONI SORGENTI BEST EFFORT
95
%troncamento in caso di eccesso delle permutazioni
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);
%numero righe della matrice di riempimento
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
%completamento matrice di permutazioni
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
outR=input('\nOutput Rate: '); %Output Rate del buffer
%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');
Posto l’output rate outR=250, la Figura 44 mostra l’andamento della coda d’attesa
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)
%
% S : matrice (TxN) di sorgente;
% N : numero di sorgenti;
% T : lunghezza del periodo di osservazione;
% 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;
% 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.
%
%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');
outR=input('\nOutput Rate: '); %Output Rate del buffer
%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
Posto l’output rate outR=250, la Figura 45 mostra l’andamento della coda d’attesa
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)
%
% S : matrice (TxN) di sorgente;
% N : numero di sorgenti;
% T : lunghezza del periodo di osservazione;
% bitR : vettore riga (1xN) contenente i bit rates delle singole sorgenti;
% 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;
% 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.
%Restituisce: [Q]
%
% Q : matrice (TxN) le cui colonne contengono le allocazioni
% istantanee dei buffers associati alle singole sorgenti.
fprintf('\nWeighted Fair Queueing\n');
outR=input('\nOutput Rate: '); %Output Rate del buffer
%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
Figura 54 - Percentuale di collisioni [25 Contention Slots]
Figura 55 - Lunghezza media della coda [25 Contention Slots]
120
Figura 56 - Percentuale di collisioni [45 Contention Slots]
Figura 57 - Lunghezza media della coda [45 Contention Slots]
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.
Top Related