Capitolo 4 Simulazioni
4.1 Scheduler Palermo
Di seguito vengono riportati i risultati delle simulazione utilizzando l’allo- catore LO. Essendo l’ algoritmo sviluppato e proposto in questo lavoro di Tesi, sono state eseguite diverse tipologie di simulazioni. Vengono analizzate quattro differenti casistiche, inerenti l’ utilizzo di un allocatore che prevede, o meno, il controllo sul check
X
k
Rmin(k) ≤ Rtot (4.1)
Nel caso in cui non vi sia il check su tale vincolo, il valore di Rmin(k) viene fissato a zero. Per ognuno di questi due casi vengono riportati i risultati delle simulazioni assumendo inizialmente un limite passimo della potenza trasmis- sibile pari a 10W, come inizialmente proposto nelle specifiche di progetto PRIMO, poi pari a 100W, essendo questo il valore proposto nella parte finale dei test considerando il primo valore troppo restrittivo.
Riassumendo, riguardo all’ allocatore OL, sono state effettuate le seguenti simulazioni:
• check sul primo vincolo, e Pmax=10W
• senza check sul primo vincolo, e Pmax=10W
• check sul primo vincolo, e Pmax=100W
• senza check sul primo vincolo, e Pmax=100W
Di seguito vengono riportati i dettagli delle singole simulazioni, evidenziando in una apposita tabella i valori di:
• Offered Load (OL), espresso in Mbps
• Throughput (TRP), espresso in Mbps
• Throughput per cella (TRPC), espresso in Mbps ed ottenuto tramite la formula T RP C=T RP /num celle=T RP /9, avendo assunto nella nos- tra configurazione un sistema a 9 celle.
• Request Acceptance Ratio (RAR)
• Accepted Load(AL), espresso in Mbps ed ottenuto tramite la formula AL=OL × RAR
• Mean Power per PBU (POWER e POWER-dB), espressa sia in W che in dB
• Power Throughput Ratio (P/TRPC e P/TRPC-dB), espressa sia in W/Mbps che in dB
Per ognuna delle simulazioni sopra elencate vengono riportati i grafici relativi a:
• AL su OL
• POWER-dB su AL
• P/TRPC-dB su AL
4.2 confronto fra le diverse simulazioni allo- catore LO
Di seguito vengo riportati in dettaglio i risultati delle simulazioni effettuate utilizzando l’ algoritmo di allocazione LO.
4.2.1 Simulazione Pmax=10W
10 8 6 Accepted Load [Mbps] 4
70 60
50 40
30 20
10
Offered Load [Mbps]
Fig. 4.1: System architecture
-6.0 -5.5 -5.0 -4.5 -4.0 -3.5
Power [dB]
10 8
6 4
Accepted Load [Mbps]
Fig. 4.2: System architecture
-16 -14 -12 -10 -8
Power/Throughput [dB]
10 8
6 4
Accepted Load [Mbps]
Fig. 4.3: System architecture
4.2.2 Simulazione senza check primo vincolo, e Pmax=10W
10 8 6 4 2
Accepted Load [Mbps]
70 60
50 40
30 20
10
Offered Load [Mbps]
Fig. 4.4: System architecture
-16 -14 -12 -10 -8
Power [dB]
10 8
6 4
Accepted Load [Mbps]
Fig. 4.5: System architecture
-16 -14 -12 -10 -8 -6
Power/Throughput [dB]
10 8
6 4
Accepted Load [Mbps]
Fig. 4.6: System architecture
4.2.3 Simulazione Pmax=100W
10
8
6
4
Accepted Load [Mbps]
70 60
50 40
30 20
10
Offered Load [Mbps]
Fig. 4.7: System architecture
-6 -5 -4 -3
Power [dB]
10 8
6 4
Accepted Load [Mbps]
Fig. 4.8: System architecture
4.2.4 Simulazione senza check primo vincolo,Pmax=100W
-12.5 -12.0 -11.5 -11.0 -10.5 -10.0 -9.5
Power/Throughput [dB]
10 8
6 4
Accepted Load [Mbps]
Fig. 4.9: System architecture
18 16 14 12 10 8 6 4
Accepted Load [Mbps]
70 60
50 40
30 20
10
Offered Load [Mbps]
Fig. 4.10: System architecture
4.2.5 Confronto Simulazioni allocatore LO
Analizzando i risultati ottenuti utilizzando l’ algoritmo di allocazione dinami- ca delle risorse di tipo LO nelle modalit´a sopra riportate, possiamo vedere che
-6.5 -6.0 -5.5 -5.0 -4.5
Power [dB]
18 16
14 12
10 8
6 4
Accepted Load [Mbps]
Fig. 4.11: System architecture
-8 -6 -4 -2 0
Power/Throughput [dB]
18 16
14 12
10 8
6 4
Accepted Load [Mbps]
Fig. 4.12: System architecture
l’ approccio senza controllo sul vincolo riguardante il rate minimo richiesto per la trasmissione, risulta essere il migliore. Nel caso di vincolo in cui
si assuma il valore massimo della potenza utilizzabile pari a Pmax= 10W le prestazioni dell’ allocatore che non effettua il check sul primo vincolo, mostra prestazioni simili a quelle ottenute dall’ allocatore che effettua il check sul primo vincolo, ma utilizzando un valore della potenza massima utilizzabile pari a Pmax= 100W. Risulta quindi che, scegliendo un algoritmo che non ef-
18 16 14 12 10 8 6 4
Accepted Load [Mbps]
70 60
50 40
30 20
10
Offered Load [Mbps]
Pi allocator 100W, con primo vincolo Pi allocator 100W, senza primo vincolo Pi allocator 10W, con primo vincolo Pi allocator 10W, senza primo vincolo
Fig. 4.13: System architecture
fettua il controllo sul primo vincolo, ´e possibile ottenere le stesse prestazioni che potrebbero essere ottenute solamente richiedendo una potenza di trasmis- sione 10 volte pi´u grande.
Dalla a Fig.4.13 possiamo vedere che le prestazioni, in termini di carico ac- cettato (accepted Load - AL) senza ombra di dubbio migliori si ottengono utilizzando l’ algoritmo di allocazione che effettua il check sul primo vincolo e che utilizza un valore della potenza massima utilizzabile pari a Pmax= 100W.
Un ulteriore confronto fra le simulazioni effettuate consiste nel confrontare gli andamenti della potenza e della potenza normalizzata rispetto al throughput
effettivo associato alla trasmissione in esame, come riportato in fig?? e in fig??. Anche da questi confronti appare avidente che le migliori prestazioni
-16 -14 -12 -10 -8 -6 -4
Power [dB]
18 16
14 12
10 8
6 4
Accepted Load [Mbps]
Pi allocator 100W, con primo vincolo Pi allocator 100W, senza primo vincolo Pi allocator 10W, con primo vincolo Pi allocator 10W, senza primo vincolo
Fig. 4.14: System architecture
vengono ottenute utilizzando un algoritmo di allocazione dinammica delle risorse di tipo OL con valore di potenza massima ammessa pari a 100W.
-16 -14 -12 -10 -8 -6 -4 -2 0
Power/Throughput [dB]
18 16
14 12
10 8
6 4
Accepted Load [Mbps]
Pi Allocator 100W, senza primo vincolo Pi Allocator 100W, con primo vincolo Pi Allocator 10W, senza primo vincolo Pi Allocator 10W, con primo vincolo
Fig. 4.15: System architecture
4.2.6 Allocatore EM
18 16 14 12 10 8 6 4
Accepted Load [Mbps]
70 60
50 40
30 20
10
Offered Load [Mbps]
Fig. 4.16: System architecture
2.5 2.0 1.5 1.0 0.5 0.0 -0.5
Power [dB]
18 16 14 12 10 8
6 4
Accepted Load [Mbps]
Fig. 4.17: System architecture
-10 -9 -8 -7 -6 -5 -4
Power/Throughput [dB]
18 16 14 12 10 8
6 4
Accepted Load [Mbps]
Pa Allocator Pd Allocator Pi Allocator
Fig. 4.18: System architecture
4.2.7 Allocatore GH
20 18 16 14 12 10 8 6
Accepted Load [Mbps]
70 60
50 40
30 20
10
Offered Load [Mbps]
Fig. 4.19: System architecture
8
7
6
5
Power [dB]
20 18
16 14
12 10
8 6
Accepted Load [Mbps]
Fig. 4.20: System architecture
-8 -6 -4 -2
Power/Throughput [dB]
20 18
16 14
12 10
8 6
Accepted Load [Mbps]
Fig. 4.21: System architecture
4.3 confronto fra i diversi allocatori
Ogni simulazione ´e costituita da 10 batch, a cui corrispondono 300 tempi di frame. In ogni batch la distribuzione delle MS viene rinnovata. I primi 100 frame di un batch vengono considerati come trasitorio, e non contribuiscono ai risultati della simulazione. Infine, viene assunto un tempo di simbolo pari a Tt =16 µs Nella tabella4.3 riassumiamo i settaggi considerati per lo scenario considerato Nello scenario proposto, i risultati ottenuti dalle simulazioni rias- sunti in Fig.?? indicano che l’ algoritmo GH presenta le migliori prestazioni in termini di numero di pacchetti trasmessi senza errori, o throughput, rispet- to al traffico offerto medio.
Si deve sottolineare il fatto che per ciascun algoritmo di allocazione utiliz- zato, il valore del throughput ottenuto risulta essere, in media, minore della met´a del carico offerto. Questo per´o non significa che il resto dei pacchetti subisca necessariamente errori di trasmissione: infatti il limite applicato alla
Tabella 4.1: Simulation parameters
Scenario BASE TDMA FDMA
Nt 256 256 256
Mt 32 32 256
Ns 128 128 128
Ms 16 128 16
B {512, 1024, 1536} {4096, 8192, 12388}
20
15
10
5
Accepted Load [Mbps]
70 60
50 40
30 20
10
Offered Load [Mbps]
Pa Allocator Pd Allocator Pi Allocator
Fig. 4.22: System architecture
potenza di trasmissione risulta essere un meccanismo di controllo implicito del traffico in quanto tramite questo controllo non vengono inviati sul mezzo wireless.
Analizzando il rapporto fra numero di pacchetti effettivamente trasmessi e il
numero dei pacchetti su cui si ´e verificato un errore nella fase di trasmissione possiamo notare che la probailit´a di succeso non risulta essere mai inferiore al 85%. Un parametro molto importante nel calcolo della bont´a di un algo-
8 6 4 2 0 -2 -4 -6
Power [dB]
20 15
10 5
Accepted Load [Mbps]
Pa Allocator Pd Allocator Pi Allocator
Fig. 4.23: System architecture
ritmo di allocazione ´e rappresentato dal valore della potenza utilizzata per la trasmissione. In Fig. ?? viene riportato l’ andamento di tale valore in funzione del carico effettivamente accettato. Confrontando i vari allocatori osserviamo che l’ approccio OL porta ad un valore medio molto pi´u basso degli altri due modelli, GH e EM.
4.4 Scheduler Roma
4.4.1 file di uscita
I risultati delle simulazioni eseguite vengono riepilogati nei file:
• bsgrid.trdelayandpower.tr
-10 -8 -6 -4 -2 0
Power/Throughput [dB]
20 15
10 5
Accepted Load [Mbps]
Pa Allocator Pd Allocator Pi Allocator
Fig. 4.24: System architecture
•• disposition.tr
• erroriinvii.trf airness.tr
•• interference.tr
• pbu.tr
• potenzaperMS.tr Tali file vengono appositamente creati da un apposito set di primitive in modo da poter essere facilmente utilizzati da un particolare visu- alizzatore di informazioni che prende il nome di ’Dimostratore grafico’ (DG).
DG fornisce per ogni simulazione effettuata 6 possibilit´a di visualizzazione dati, ed ognuna di esse consiste in 9 diverse rappresentazioni, indicante gli andamenti delle funzioni richieste per ogni cella, pi´u una riepilogativa, per un totale di 10 visualizzazioni grafiche per ognuna delle 6 possibilit´a.
Risulta quindi impossibile poter riportare i dati delle singole simulazioni ef- fettuate. A differenza della discussione sui risultati ottenuti utilizzando lo
scheduler PALERMO, riportiamo solamente i confronti fra i tre algoritmi di allocazione proposti.
4.4.2 confronto allocatori
Nella fase di confronto dei risultati ottenuti attraverso le simulazioni effet- tuate utilizzando lo scheduler Roma, viene preso inoltre in considerazione un algoritmo di allocazione casuale, denominato Random Allocator (RA). Tale algoritmo effettua una allocazione casuale delle risorse agli utenti cercando di rispettare i vincoli imposti dallo scheduler ma senza cercare una loro ot- timizzazione. Tale algoritmo viene preso come riferimento per fornire una stima sulla bont´a dell’ algoritmo di allocazione utilizzato.
In tutte le simulazioni effettuate, indipendentemente dal tipo di algoritmo di allocazione utilizzato, si suppone che le BS siano a conoscenza delle infor- mazioni inerenti lo stato del canale trasmissivo rispetto al frame precedente.
Nel caso di allocatore random questa informazione viene utilizzata per come parametro per il controllo della potenza totale necessaria alla trasmissione.
Per testare l’ abilit´a degli algoritmi proposti, in figura 4.25 viene riportato, per un numero variabile di utenti, il cunsumo medio di potenza per cella.
Questo grafico ´e stato ottenuto considerando un valore di Creq=0.8 e Cmax=1.6, e assumendo che su ogni cella sia verificata la condizione di saturazione.
In Fig4.25 viene mostrato come per ognuno degli algoritmi di allocazione pro- posti la potenza diminuisca all’ aumentare nel numero degli utenti, mentre l’
allocatore random non risente di questa variazione e presenta un consumo di potenza costante. Questo ´e dovuto alla flessibilit´a delle richieste provenienti dallo scheduler, che permettono agli algoritmi di allocazione intelligenti di
0 1 2 3 4 5 6 7 8 9 10 11 8
9 10 11 12 13 14 15 16
Average number of users per cell
dBW
Random EM
LO
GH
Fig. 4.25: Average cell power consumption
scegliere su ciascun frame gli utenti pi´u efficienti da allocare alle PBU che presentano le migliori condizioni per la trasmissione.
Dalla Fig4.25 si osserva inoltre che l’ approccio di ottimizzazione lineare su cui si basa l’ allocatore proposto dall’ Universit´a degli Studi di Pisa porta ad una allocazione pi´u efficiente in termini di potenza totale necessaria alla trasmissione.
Si deve notare, inoltre, che tutti e tre gli algoritmi proposti sono capaci di sfruttare la diversit´a multiutente.
Un parametro significativo per il confronto fra i diversi algoritmi di allo- cazione proposti consiste nel calcolo della potenza media di trasmissione in funzione del bitload della cella in esame. Per ottenere tale parametro abbi- amo effettuato delle simulazioni considerando di variare il valore di Creq in uno scenario multicellulare, con un numero di celle pari a 9, con un numero di utenti pari a 60. Le sorgenti di traffico vengono assunte in saturazione,
ossia ogni MS presenta sempre pacchetti da trasmettere. Settiamo inoltre Cmax=3xCreq.
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 0
10 20 30 40 50 60 70 80
Creq
Power (W)
Cmax = 3 C
req
Random allocator
EM
LO GH
Fig. 4.26: Mean transmission power vs Cell load
In Figura 4.26 viene riportato l’ andamento della potenza di trasmissione, ottenuta attraverso i 4 diversi algoritmi di allocazione, variando il carico del- la cella in esame.
Anche in questo caso utilizzando l’ algoritmo di allocazione proposto dall’
Universit´a di Pisa ´e possibile ottenere il minimo valore della potenza media di trasmissione richiesta. Inoltre, confrontato con l’algoritmo di allocazione
’greedy heurystic’ proposto dall’ Universit´a di Palermo, l’ algoritmo di ot- timizzazione lineare risulta significativamente pi´u efficiente con l’ aumentare del carico di cella.
La Figura 4.27 mostra l’ andamento della potenza di trasmissione media ot-
tenuta al variare del parametro Cmax. Come abbiamo notato in fig. 4.25 la potenza di trasmissione diminuisce all’ aumentare di Cmax. La Figura 4.27 ´e stata ottenuta utilizzando un canale caratterizzato da un delay spread di δτ
=500 ns. In Figura 4.28 viene invece riportato l’ andamento della potenza media trasmessa in funzione del variare di Cmax. Per ottenere tale risultato ´e stato per´o considerato un canale caratterizzato da un valore di delay spread pari a δτ =50 ns, ossia da un canale caratterizzato da una minorediversit´a in frequenza.
1 1.5 2 2.5 3 3.5 4
17 18 19 20 21 22 23 24
Cmax
Power (W)
Creq = 0.8
στ = 0.5 µ s GH
EM
LO
Fig. 4.27: Mean transmission power vs Cmax
Al diminuire del valore di δτ la diversit´a in frequenza tende ad annullarsi, mentre il consumo medio della potenza tende ad aumentare notevolmente. In
1 1.5 2 2.5 3 3.5 4 22
23 24 25 26 27 28 29 30 31 32
Cmax
Power (W)
Creq = 0.8
στ = 50ns GH
EM
LO
Fig. 4.28: Mean transmission power vs Cmax, with delay spread στ = 50 ns
questo caso l’ unica diversit´a ´e dovutaalla natura tempo variante del canale.
Al crescere del valore di δτ la diversit´a in frequenza aumenta, e dal momento che la maggior parte della diversit´a del canale viene gi’a sfruttata dall’ allo- catore, l’a umento del valore di Cmax non porta a vantaggi considerevoli.
In entrambi i casi per´o l’ algoritmo di allocazione basato sulla o ttimizzazione lineare risulta essere quello che consuma meno potenza. ´E importante sot- tolineare come tale allocatore sia l’ unico a mostrare il minimo aumento di efficienza al variare di Cmax.
Questo deriva dal fatto che l’ algoritmo di ottimizzazione lineare ´e il pi´u effi- ciente nella risoluzione del problema di selezione delle PBU da assegnare ad ogni flusso trasmissivo, quindi l’ unico ad utilizzare pienamente la diversit´a in frequenza.
La Fig.4.29 mostra i valori dell’ indice di fairnes secondo Jain, calcolato dopo
ogni frame prendendo in considerazione la quantit´a dei dati trasmessi da og- ni flusso dall’ inizio della simulazione. Da questa figura ´e possibile osservare che tutti e tre gli algoritmi di allocazione proposti hanno un comportamento pressoch´e simile.
I risultati delle simulazioni effettuate sono ben al di sopra del limite di fairness, che risulta perci´o essere conservativo.
0 20 40 60 80 100
0.2 0.4 0.6 0.8 1 1.2
Frame
Jain’s fairness index
Lower bound LO, GH, EM Random allocator
Fig. 4.29: Fairness achieved after each frame
4.5 Parametri di configurazione - Simulazioni Palermo
4.5.1 primo.config
In tabella [] vengono riportati i parametri di configurazione del simulatore utilizzati per la definizione del modello di sistema utilizzato
4.5.2 source.config
In tabella [] vengono riportati i parametri di configurazione delle sorgenti utilizzati per la definizione del modello di trasmissione utilizzata. Per ogni sorgente viene definito:
• la tipologia del flusso dati, in questo caso settato a DATA, in teoria erano state previste anche le modalit´a VIDEo e VOICE.
• la dimensione della pdu, pari ad un valore fissato di 12000 byte
• il tempo di interarrivo (TOA); nelle simulazioni effettuate vengono as- sunti i valori di TOA pari a 2000, 2142, 2307, 2500, 2727, 3000, 3333, 3750, 4285, 5000, 6000, 7500, 10000, 15000, 30000
• il tempo di vita (Time to live TTL), pari ad un valore prefissato di 15000
• il numero della MS
All’ inizio del file, inoltre, viene riportato il numero di utenti totale.
La forma del file di configurazione source.config risulta quindi essere del tipo:
Parametri Valori Unit´a
Scheduler 2
Allocatore 2
Numero utenti 108 MS
Xsta 3 m
Ysta 3 m
Raggio 500 m
Durata di simbolo 16
Numero di sottoportanti 128
Numero di simboli 256
Numero medio di simboli 256 Numero di sottoportanti per PBU 16
Numero di simboli per PBU 32 Numero medio di sottoportanti per PBU 16 Numero medio di simboli per PBU 32
Delay spread 10 µs
Lognormal fading 6 dB
Durata di transitorio 100 frame
Durata di batch 200 frame
Numero di batch 10
Potenza massima 10000 µW
Tabella 4.2: parametri primo.config
108
DATA 1 1 SPDU TOA TTL -1 MS
DATA 1 1 12000 2000 15000 -1 0 ...
DATA 1 1 12000 2000 15000 -1 107
Tabella 4.3: parametri source.config per un TOA pari a 2000 per una configurazione a 108 MS
4.6 Parametri di configurazione - Simulazioni Roma
4.6.1 primo.config
In tabella [] vengono riportati i parametri di configurazione del simulatore utilizzati per la definizione del modello di sistema utilizzato
4.6.2 source.config
In tabella [] vengono riportati i parametri di configurazione delle sorgenti utilizzati per la definizione del modello di trasmissione utilizzata. Per ogni sorgente viene definito:
• la tipologia del flusso dati, in questo caso settato a DATA, in teoria erano state previste anche le modalit´a VIDEo e VOICE.
• la dimensione della pdu, pari ad un valore fissato di 1534 byte
• il tempo di interarrivo (TOA)”pari ad un valore fissato di 10
• il tempo di vita (Time to live TTL), pari ad un valore prefissato di 50000
Parametri Valori Unit´a
Scheduler 1
Allocatore 2
Numero utenti 60 MS
Xsta 3 m
Ysta 3 m
Raggio 500 m
Durata di simbolo 16
Numero di sottoportanti 208
Numero di simboli 625
Numero medio di simboli 600 Numero di sottoportanti per PBU 26
Numero di simboli per PBU 60 Numero medio di sottoportanti per PBU 26 Numero medio di simboli per PBU 59
Delay spread 10 µs
Lognormal fading -30 dB
Durata di transitorio 100 frame
Durata di batch 200 frame
Numero di batch 10
Potenza massima 50000 µW
Tabella 4.4: parametri primo.config
• il numero della MS
All’ inizio del file, inoltre, viene riportato il numero di utenti totale.
La forma del file di configurazione source.config risulta quindi essere del tipo:
60
DATA 1 1 SPDU TOA TTL -1 MS
DATA 1 1 1534 10 50000 -1 0
...
DATA 1 1 12000 2000 15000 -1 107
Tabella 4.5: parametri source.config per una configurazione a 60 MS in DL
Si deve sottolineare il fatto che le simulazioni eseguite utilizzando lo sched- uler proposto dall’ Universit´a di Roma prevderela modalit´a di trasferimento dati sia in download che in upload. La tipologia di direzione di flusso uti- lizzata nella simulazione prevedeva inizialmente, oltre alla modifica del file di configurazione source.config come riportato in tabella [], anche il settag- gio del parametro DU TRESHOLD contenuto nel file globals.h, secondo lo schema sotto riportato Nelle simulaazioni finali, per non dover compilare og-
0.0 Upload 1.0 Download
Tabella 4.6: DUTRESHOLD
ni volta il codice utilizzato nelle simulazioni, ´e stato previsto un ulteriore campo informativo in primo.config tale da selezionare la direzione del traffico in esame.
4.6.3 confg Scheduler Roma.conf
Rispetto alle simulazioni eseguite utilizzando lo scheduler proposto dall’ Uni- versit´a di Palermo, in questo ciclo di simulazioni viene utilizzato un ulteriore file di configurazione, denominato confg Scheduler Roma.conf.
In tale file vengono riportati i principali parametri di configurazione dello
scheduler, come il valore di Cmax, la capacit´a massima corrispondente al nu- mero di richieste per frame, il valore di il valore di Creq, che corrisponde alla capacit´a richiesta, ossia al numero di richieste che devono essere servite, e il valore del ’weighted allocation’, che indica la modalit´a di allocazione secondo il criterio riportato in tabella []. L’ allocazione a due passi, denominata an-
1 Allocazione in due passi 0 Allocazione in un passo Tabella 4.7: weighted allocation
che ’allocazione pesata’, rappresenta la principale innovazione proposta dallo scheduler sviluppato dall’ Universit´a di Roma. In questa modalit´a, nella pri- ma fase denominata ’allocazione di test’, lo scheduler invia all’ allocatore una lista di richieste di prova. Sulla base delle informazioni contenute nella lista delle richieste ricevuta, l’ allocatore provvede ad effettuare una selezione delle richieste abilitate alla trasmissione basandosi su valori pesati della potenza.
In questa fase l’ allocatore modifica la lista delle richieste indicando quali di esse sarebbe potuta essere trasmessa, senza mdificare per´o la mappa delle allocazioni. Infine, l’ allocatore invia allo scheduler la lista aggiornata delle richieste. Nella seconda fase, invece, lo scheduler invia all’ allocatore la lista delle richieste che nella prima fase sono risultate abilitate ala trasmissione, sostituendo alle richieste scartate dall’ allocatore durante la fase di test even- tuali richieste presenti in coda. Sulla base delle informazioni presenti in questa lista delle richieste, l’ allocatore seleziona le richieste da trasmettere utilizzando come parametri di decisione i valori della potenza reale richiesta, e non pi´u un suo valore pesato. Al termine di tale fase viene modificata sia la lista delle richieste che la mappa delle allocazioni.
In tabella [] vengono riportati i parametri di configurazione delle sorgenti
utilizzati per la definizione del modello di trasmissione utilizzata. Per ogni sorgente viene definito:
• la tipologia del flusso dati, in questo caso settato a DATA, in teoria erano state previste anche le modalit´a VIDEo e VOICE.
• la dimensione della pdu, pari ad un valore fissato di 1534 byte
• il tempo di interarrivo (TOA)
”pari ad un valore fissato di 10
• il tempo di vita (Time to live TTL), pari ad un valore prefissato di 50000
• il numero della MS
All’ inizio del file, inoltre, viene riportato il numero di utenti totale.
La forma del file di configurazione source.config risulta quindi essere del tipo:
Maximum Capacity = 1.500 Target Capacity = 0.5 Minimum Capacity = 0 Persistent Allocation = 0
Weighted Allocation =1
Tabella 4.8: parametri confg Scheduler Roma.conf
