Capitolo 6 Risultati delle simulazioni

Capitolo 6
Risultati delle simulazioni
In questo capitolo sono presentati i risultati delle simulazioni effettuate per delineare
il comportamento del sistema UMTS. Con le prove effettuate si vuole sia testare il
corretto funzionamento del livello RRC implementato sia valutare le prestazioni
degli algoritmi realizzati per gestire in modo efficiente le risorse di sistema. Le
simulazioni sono condotte variando in particolare le classi di traffico, la qualità del
canale radio e i canali di trasporto utilizzati.
6.1 Parametri delle simulazioni
I parametri principali misurati nelle simulazioni sono:
Numero di connessioni RRC instaurate: indica il numero di connessioni RRC
che sono state instaurate con successo durante l’intero arco della
simulazione.
Numero di connessioni RRC rifiutate: rappresenta il numero di richieste di
connessioni RRC rifiutate nel periodo temporale simulato. Una connessione
è rifiutata se a tutti i messaggi di RRC_Connection_Setup appartenenti alla
medesima richiesta di connessione segue un messaggio di
RRC_Connection_Release. La modalità e le tempistiche con cui questi
messaggi si susseguono sono definite nel capitolo 3.
Probabilità di blocco: fornisce una stima della probabilità con cui un UE non
riesce ad instaurare una connessione RRC con la rete. E’ definita dal
seguente rapporto:
Pb
n _ conn _ reject
n _ conn _ reject n _ conn _ setup
157
§6 - Risultati delle simulazioni
dove n_conn_reject e n_conn_setup indicano il numero di connessioni RRC
rispettivamente rifiutate ed accettate.
Tempo di attività della sorgente: rappresenta il periodo temporale in cui una
generica sorgente di traffico è mantenuta attiva. Questo parametro coincide
con la durata della sessione di sorgente.
Tempo di connessione RRC: rappresenta la durata della connessione RRC.
Questo parametro misura l’intervallo temporale che intercorre tra la ricezione
da parte dell’UTRAN del messaggio di RRC_Connection_Setup_Complete
inviato dall’UE e il momento in cui l’UTRAN invia il messaggio di
RRC_Connection_Release all’utente in questione.
Poichè ad ogni
connessione corrisponde una sola sessione di sorgente, questo parametro
permette di misurare il tempo necessario a smaltire i dati generati dalla
sorgente; si può inoltre valutare, mediante il confronto tra tale parametro e il
tempo di attività della sorgente, la reattività del sistema nel gestire un certo
tipo di traffico.
Tempo per instaurare la connessione: definisce il periodo temporale che
intercorre tra l’invio della prima richiesta di RRC_Connection_Request
dall’utente alla rete e la ricezione da parte dell’utente del messaggio di
RRC_Connection_Setup speditogli dall’UTRAN.
Questo intervallo
comprende il tempo necessario al messaggio di RRC_Connection_Request
per transitare sull’interfaccia “Uu” usando il canale di trasporto RACH e il
tempo impiegato dal messaggio di RRC_Connection_Setup per arrivare a
destinazione usando il FACH come canale di trasporto.
Traffico offerto per sessione: è definito come il rapporto tra i dati generati
dalla sorgente nella sessione e il tempo di attività della sorgente.
Traffico smaltito su un canale di trasporto: permette di analizzare la capacità
di un canale di trasporto al variare del carico offerto da una sorgente di
traffico. Questo parametro è calcolato come il rapporto, espresso in bit/s, tra
i dati smaltiti con successo su “Uu” e la durata della connessione RRC. Tale
statistica viene effettuata a livello RLC considerando il numero di SDU che
sono ricevute correttamente durante il periodo di connessione e che devono
essere trasmesse ai livelli superiori.
Occupazione dei buffer di livello RLC: fornisce un’indicazione sulla Buffer
Occupancy (BO) di livello RLC. La BO è espressa come numero di PDU
presenti trama per trama nel buffer di trasmissione (e di ritrasmissione per la
sola modalità AMD di trasferimento) del Radio Link Control. Per
risparmiare risorse dell’elaboratore, non si memorizza l’andamento della BO
in funzione del tempo ma si registra il numero di occorrenze per ogni
possibile valore della BO.
I valori di tempo, traffico e occupazione dei buffer appena definiti sono poi
mediati sul numero totale di connessioni instaurate e in funzione del tipo di traffico
che ogni singola connessione ha supportato. Questo permette di derivare il
158
§6 - Risultati delle simulazioni
comportamento del sistema simulato in presenza di traffici differenti, anche
simultaneamente.
Sorgente UDD
Dati generati in media
per sessione [kbyte]
100
Numero di stati della
sorgente
3
Stati della sorgente
UDD 64
UDD 144
UDD 384
Tempo medio di ON [s]
1.6
0.7
0.26
Tempo medio di OFF [s]
3.0
3.0
3.0
480
480
480
0.0625
0.027
0.0104
Dimensione media dei
pacchetti [byte]
Tempo di interarrivo tra
pacchetti [s]
Tabella 6.1 : Parametri della sorgente UDD
Sorgente STREAMING
Durata media della
sessione Streaming [s]
Numero di stati della
sorgente
180
3
Stati della sorgente
Signalling
State 64
State 384
Velocità [kbit/s]
64
64
384
2
10
4
480
80
480
0.0625
0.0625
0.0104
Tempo medio di
permanenza nello stato
[frame]
Dimensione media dei
pacchetti [byte]
Tempo di interarrivo tra
pacchetti [s]
Tabella 6.2 : Parametri della sorgente Streaming
159
§6 - Risultati delle simulazioni
Nel simulatore sono definite due sorgenti di traffico per emulare i servizi video e
UDD, appartenenti rispettivamente alle classi di servizio Streaming e Interactive.
Questi modelli sono stati descritti in dettaglio al paragrafo 4.10 del capitolo 4. Le
tabelle 6.1 e 6.2 riportano i parametri di configurazione degli stati delle due sorgenti.
Tali valori sono inseriti nel file dati sources.dat e sono stati utilizzati per condurre le
simulazioni.
La trasmissione dei dati attraverso l’interfaccia radio è garanti ta dal Radio
Access Bearer Service (RABS) , instaurato dal RRC nell’UTRAN in seguito ad una
richiesta di servizio da parte di un utente. I RABS presentano caratteristiche distinte
a seconda del servizio che devono garantire. Le informazioni, usate dal Radio
Resource Control per configurare i Radio Access Bearer Service, sono inserite nel
file di ingresso services.dat e si differenziano in funzione del servizio che si vuole
instaurare. Questa soluzione permette di caratterizzare i livelli protocollari in modo
diverso in base al tipo di traffico; eventualmente si può agire su tali parametri per
condurre simulazioni con servizi di trasporto configurati differentemente. Si può per
esempio cambiare il canale di trasporto, la modalità di trasferimento e i parametri di
protocollo di livello RLC. La tabella 6.3 illustra una possibile configurazione degli
attributi dello Streaming RABS e dell’Interactive RABS usati per realizzare le
simulazioni.
MAC Info
RLC Info
Interactive RABS
Streaming RABS
Canale di trasporto
CPCH
DCH
Identificativo del
canale logico
0
1
Priorità
1
0
Velocità garantita
[kbit/s]
Not Defined
384
Modalità RLC di
trasferimento
Acknowledged
Transparent
Valore del Timer
Discard [s]
7.5
0.5
File con parametri
di protocollo di
livello RLC
am_parameters.dat
tm_parameters.dat
Tabella 6.3 : Parametri di configurazione dei RABS
160
§6 - Risultati delle simulazioni
L’albero dei codici OVSF ( Orthogonal Variable Spreading Factor), inserito nel
simulatore e descritto al paragrafo 5.3.2.1.3 del capitolo 5, è configurato secondo i
parametri impostati nel file dati ovsf_code.dat. Per effettuare le simulazioni si sono
scelti i seguenti attributi (tabella 6.4):
Albero dei codici
Profondità dell’albero [numero di livelli]
5
Bit Rate minimo assegnato alle foglie [kbit/s]
120
Numero di codici dell’ultimo livello riservati al RACH [%]
12,5
Codici COMMON riservati alla massima velocità del sistema [%]
25
Tabella 6.4 : Parametri di configurazione dell’albero dei codici
Il modello di canale radiomobile, definito dalla catena di Markov a tempo
discreto nel paragrafo 4.7 del capitolo 4, consente di variare la qualità del mezzo
trasmissivo modificando i parametri inclusi nel file di ingresso channel.dat e
riportati nella tabella 6.5 sottostante.
Canale radiomobile
Probabilità di permanenza nello stato di GOOD
PGG
Probabilità di permanenza nello stato di BAD
PBB
Tabella 6.5 : Parametri del canale radiomobile
Diversi valori di queste probabilità di permanenza producono differenti valori di
probabilità di errore media sul blocco trasmesso (Perr). Ricordando infatti il legame
tra PGG e PBB e i tempi medi TG e TB di permanenza negli stati della catena, si ottiene
la seguente formula per la probabilità di errore:
Perr
TB
TB
TG
Alcuni possibili valori di Perr usati per caratterizzare la qualità del canale nelle
simulazioni sono elencati nella tabella 6.6.
161
§6 - Risultati delle simulazioni
PBB
PGG
Perrore
0.000252
0.999895
0.000105
0.635365
0.970313
0.075287
0.681957
0.953261
0.128128
0.740855
0.935502
0.199287
0.773953
0.906202
0.293261
0.813819
0.889287
0.372904
0.865943
0.823822
0.567886
Tabella 6.6 : Valori della Probabilità di errore media sul blocco
Il livello RRC svolge un importante ruolo di controllo e gestione delle risorse
radio disponibili. Per fare questo, esso deve gestire parecchie procedure di livello
RRC, come descritto nel sotto-paragrafo 3.7.5 del capitolo 3. Queste operazioni
necessitano di un insieme di parametri per poter essere condotte. Tali parametri
devono essere impostati a priori in opportuni file di ingresso.
Per la procedura di instaurazione della connessione RRC, si sono scelti i valori
riportati in tabella 6.7 per i Timer e le costanti coinvolte nell’operazione.
RRC lato UE
N300
5
Timer T300 [s]
5
RRC lato Utran
wait time [s]
2
Tabella 6.7 : Timer e costanti per la procedura di RRC Connection Request
Per cambiare i valori indicati, si devono modificare i file dati
RRC_UE_parameters.dat e RRC_UTRAN_parameters.dat, usati rispettivamente dai
Radio Resource Control nell’UE e nell’UTRAN.
Per eseguire le procedure di misurazione, il RRC deve supervisionare i livelli
comunicanti, delegando a questi ultimi diversi compiti di controllo. Per riuscire in
questo intento, deve fornire agli stati protocollari interessati i parametri utili per
condurre le misure. In tabella 6.8 e 6.9 si riportano i parametri usati dal RRC per
eseguire il monitoraggio del volume di traffico nelle pile protocollari, mediante
l’interazione con il MAC. Si deve notare (tabella 6.8) come si possa ordinare al
Radio Resource Control di controllare differentemente il traffico in uplink e in
downlink, configurando diversamente i file di ingresso trafficVolumeSetup.dat e
162
§6 - Risultati delle simulazioni
trafficVolumeSetupUtran.dat.
Questi file definiscono infatti gli attributi per
monitorare le pile rispettivamente nell’UE e nell’UT RAN. La tabella 6.9 illustra
invece le soglie e i tempi che il MAC deve ricevere dal RRC, per eseguire la
procedura di misura del volume di traffico. Tali valori sono impostati nel file dati
criteria.dat.
RRC lato UE
RRC lato UTRAN
Modalità per effettuare i REPORT
Event Trigger
Periodical
Canale di trasporto da monitorare
all
DSCH
Stato RRC in cui è valida la misura
all
Not Defined
Tempo di aggiornamento della stima [s]
0.2
0.2
Tabella 6.8 : Parametri di livello RRC per monitorare il volume di traffico
Soglia
Soglia inferiore
superiore(ThU)
(ThL)[numero
[numero di PDU]
di PDU]
Pending Time
per ThU [s]
Pending Time
per ThL [s]
Reporting Time
[s]
RACH
150
100
0.5
0.5
0.25
CPCH
100
20
0.25
0.5
0.25
DCH_UL
50
10
0.25
0.25
0.25
DCH_DL
100
20
0.25
0.5
0.25
DSCH
100
50
0.25
0.5
0.25
Tabella 6.9 : Parametri per monitorare il canale di trasporto nel MAC
RRC lato UE
RRC lato UTRAN
Modalità per effettuare i REPORT
Event Trigger
Event Trigger
Tempo di campionamento del canale [s]
0.1
0.15
Tabella 6.10 : Parametri per la stima della qualità del canale radiomobile
In tabella 6.10 si illustrano alcuni valori per i parametri di configurazione della
procedura di stima della qualità del canale radiomobile, eseguita a livello 2 e che
consente al RRC di interrompere la trasmissione dei dati sull’interfaccia “Uu”.
Anche in questo caso è possibile diversificare la gestione della misurazione in
esame, a seconda che tale operazione sia eseguita nell’UE o nell’UTRAN. I file che
163
§6 - Risultati delle simulazioni
contengono i valori dei parametri da utilizzare per avviare la procedura nel terminale
e nell’UTRAN sono rispettivamente intraFrequency.dat e intraFrequencyUtran.dat.
Il file di ingresso simul_service.dat deve invece fissare le percentuali dei servizi
richiesti dagli utenti nelle varie celle dello scenario simulativo. Questa soluzione
consente ad uno stesso utente di richiedere talvolta un servizio dati talvolta un
servizio video nell’arco della medesima simulazione. In tabella 6.11 si illustra la
struttura del file appena citato.
Percentuale del servizio in ogni cella
Servizio UDD [%]
80
Servizio STREAMING [%]
20
Tabella 6.11 : Parametri per la scelta del servizio da parte di un utente
6.2 Studio delle procedure di livello RRC
In questo paragrafo vengono presentati alcuni risultati che hanno lo scopo di
verificare il corretto funzionamento delle procedure di livello RRC nel simulatore
UMTS realizzato. Si vuole in particolare mostrare come varia il comportamento del
sistema al variare dei parametri di configurazione di dette procedure. Le prove sono
state eseguite ipotizzando che tutti gli utenti coinvolti nelle simulazioni richiedano
sempre il servizio dati UDD. Nella configurazione dell’Interactive RABS, riportata
in tabella 6.3, è stato cambiato il canale di trasporto per verificare le procedure di
riallocazione delle risorse radio, di riconfigurazione del Radio Bearer e di
monitoraggio del traffico su tutti i canali di trasporto.
6.2.1 RACH
Il canale di trasporto RACH, descritto nel capitolo 3, è un canale a contesa utilizzato
per le trasmissioni in uplink dei mobili. Tale canale utilizza la metodologia di
accesso slotted-aloha ed è quindi caratterizzato dalla possibilità di collisione in
uplink. Al variare del numero di codici riservati per questo canale e del numero di
utenti che tentano l’accesso alla rete, si ha una variazione del numero di collisioni e
quindi del ritardo. In particolare, a parità di utenti, un numero maggiore di codici
tende a far diminuire le collisioni; a parità di codici, invece, un numero maggiore di
utenti causa un aumento delle collisioni. Nel simulatore, questo è l’unico canale al
quale viene riservato a priori un numero fissato di sequenze dell’albero dei codici.
Ricordando i parametri di configurazione dell’albero riportati in tabella 6.4, sono
due le sequenze condivise da tutti gli utenti che usano questo canale per trasmettere i
dati. Attualmente il RACH viene utilizzato dai terminali per inviare alla rete il solo
messaggio di instaurazione di connessione RRC.
164
§6 - Risultati delle simulazioni
Ipotizzando di eseguire una simulazione con 12 utenti che richiedono tutti un
servizio dati su un canale dedicato, si può tracciare l’andamento del traffico sul
RACH in funzione del tempo. La figura 6.1 rappresenta infatti il numero di richieste
di connessione RRC inviate sul RACH dai vari utenti alla rete per ogni trama
temporale.
Carico del sistema sul RACH
2
1.8
1.6
Tenativi di accesso al canale
1.4
1.2
1
0.8
0.6
0.4
0.2
0
0
1000
2000
3000
4000
5000
6000
tempo [frame]
7000
8000
9000
10000
Figura 6.1 : Numero delle richieste di connessione RRC, inviate sul RACH, in funzione del tempo
6.2.2 CPCH
Il canale di trasporto CPCH è utilizzato per trasmettere in uplink dei dati che
richiedono una capacità di canale superiore a quella del RACH. Questo canale è
caratterizzato dalla possibilità di collisione in accesso. A differenza del RACH, in
questo caso è prevista una fase di contesa del canale radio che porta ad evitare le
collisioni in trasmissione una volta che al mobile è stato assegnato un codice
ortogonale. Nel momento in cui la rete ha concesso al mobile l’utilizzo di una
sequenza particolare, non si ha più il rischio di collisione. Un utente, abilitato a
trasmettere, mantiene il possesso del codice fino al completamento della
trasmissione dei dati o fino a quando non supera il limite massimo (NF_max) di
trame in cui ha trasmesso consecutivamente. Nelle simulazioni si è posto NF_max
uguale a 64 trame temporali.
6.2.2.1 Monitoraggio del volume di traffico
Il controllo dinamico dei Radio Bearer è gestito dal Radio Resource Control, per
mezzo delle misure sul volume di traffico effettuate dal MAC. Ovvero il MAC
165
§6 - Risultati delle simulazioni
raccoglie e misura la quantità di traffico che deve transitare attraverso il livello 2 e
consegna i risultati al RRC. Quest’ultimo, in base alle informazioni ricevute e alla
disponibilità di risorse radio, può decidere di cambiare il rate dell’utente assegnando
un nuovo codice con uno spreading factor diverso. Appare quindi evidente come
variare i parametri di configurazione della procedura di misura nel MAC possa
influire sulla gestione complessiva delle risorse radio.
Come già descritto nel paragrafo 3.3.3.1 del capitolo 3, esistono due diverse
modalità di recapito delle misure sul volume di traffico: una periodica ed una ad
eventi.
6.2.2.1.1 Modalità di misura ad eventi (Event_Trigger)
I parametri principali che caratterizzano l’algoritmo di misura in questa modalità
sono: le soglie e il pending time after trigger. Si vuole analizzare il comportamento
del sistema al variare di questi attributi separatamente.
Le soglie
Si consideri un ambiente di simulazione con le seguenti caratteristiche:
numero di utenti presenti nello scenario uguale ad 1;
canale fisico ipotizzato ideale (Perr = 0);
servizio simulato di tipo UDD;
Interactive RABS che prevede il CPCH come canale di trasporto;
valor medio dei dati generati dalla sorgente UDD ad ogni sessione costante e
pari a 100 kbyte.
Quando l’utente invia una richiesta di connessione RRC alla rete, il RAB_negotiator
del RRC nell’UTRAN accetta il nuovo servizio, assegnando alla sorgente di traffico
la massima velocità di generazione dei dati (la sorgente entra cioè nello stato
UDD384 che prevede una velocità di picco di 384 kbit/s). Essendo presente un solo
utente nell’ambiente di simulazione, la sorgente dei dati rimane nello stato indicato
per tutta la durata della sua sessione. La velocità di trasmissione dei dati
sull’interfaccia “Uu” non è invece costante, in quanto essa dipende sia dalla
momentanea disponibilità di risorse sia dal volume di traffico accodato nei buffer
del livello RLC. Il RAB_fulfiller nell’UTRAN può assegnare rate differenti
all’utente solo quando è avvisato che l’occupazione dei buffer (BO) a livello RLC
ha superato le soglie. Spostando pertanto il valore delle soglie, cambia il tempo con
cui il RRC nell’UTRAN riorganizza l’allocazione dei codici ortogonali.
Le figure 6.2, 6.3, 6.4 e 6.5 illustrano l’occupazione dei buffer di livello RLC
mediata su tutte le sessioni per diverse coppie di valori delle soglie. Con ThL si
indica la soglia inferiore mentre con ThU si indica quella superiore.
166
§6 - Risultati delle simulazioni
Numero di occorrenze medie per
sessione
Buffer Occupancy media di livello RLC
12
10
8
6
ThL = 20, ThU = 100
4
2
0
1
51 101 151 201 251 301 351 401 451
valore della BO [numero di PDU]
Figura 6.2 : Occupazione dei buffer di livello RLC in media per sessione, con valori delle soglie pari
a ThL = 20 PDU e ThU = 100 PDU
Numero di occorrenze medie per sessione
Buffer Occupancy media di livello RLC
14
12
10
8
ThL = 50, ThU = 200
6
4
2
0
1
51 101 151 201 251 301 351 401 451
valore della BO [numero di PDU]
Figura 6.3 : Occupazione dei buffer di livello RLC in media per sessione, con valori delle soglie pari
a ThL = 50 PDU e ThU = 200 PDU
167
§6 - Risultati delle simulazioni
Numero di occorrenze medie per sessione
Buffer Occupancy media di livello RLC
16
14
12
10
8
ThL = 100, ThU = 400
6
4
2
0
1
51 101 151 201 251 301 351 401 451
valore della BO [numero di PDU]
Figura 6.4 : Occupazione dei buffer di livello RLC in media per sessione, con valori delle soglie pari
a ThL = 100 PDU e ThU = 400 PDU
Numero di occorrenze medie per
sessione
Buffer Occupancy media di livello RLC
16
14
12
10
8
ThL = 200, ThU = 600
6
4
2
0
1
51 101 151 201 251 301 351 401 451
valore della BO [numero di PDU]
Figura 6.5 : Occupazione dei buffer di livello RLC in media per sessione, con valori delle soglie pari
a ThL = 200 PDU e ThU = 600 PDU
168
§6 - Risultati delle simulazioni
Throughput medio per sessione
[kbit/s]
Traffico smaltito medio al variare delle soglie dell'algoritmo di
misura nel MAC (Canale di trasporto monitorato = CPCH,
num_UE = 1)
26,8
26,7
26,6
26,5
26,4
26,3
26,2
26,1
Event_Trigger
20 / 100
50 / 200
100 / 400
200 / 600
valore delle soglie (ThL / ThU)
Figura 6.6 : Traffico smaltito in media per sessione al variare dei valori delle soglie
Durata media [s]
Durata media della connessione RRC al variare delle soglie
dell'algoritmo di misura nel MAC (Canale di trasporto = CPCH,
num_UE = 1)
30,6
30,5
30,4
30,3
30,2
30,1
30
29,9
29,8
Event_Trigger
20 / 100
50 / 200
100 / 400
200 / 600
valore delle soglie (ThL /ThU)
Figura 6.7 : Durata media della connessione RRC al variare dei valori delle soglie
169
§6 - Risultati delle simulazioni
Nei primi due casi si nota come il valore della BO sia tale da salire sopra la
soglia superiore. Questo evento consente al RAB_fulfiller di assegnare all’UE
interessato una velocità di trasmissione maggiore di quella attuale, fino a quando la
BO non scende sotto il valore della soglia inferiore. Nei secondi due casi invece il
valore della soglia superiore è talmente elevato da non essere mai valicato. Di
conseguenza ogni volta che la BO scende sotto la soglia inferiore, all’utente viene
assegnato un rate sempre più basso fino a quando non si arriva al minimo previsto
dal sistema (64 kbit/s). Il tempo impiegato in questi ultimi casi per smaltire tutti i
dati sarà quindi maggiore di quello nei primi due. Queste osservazioni sono
giustificate dalle curve riportate in figura 6.6 e 6.7, che rappresentano il traffico
medio smaltito e la durata media di connessione RRC al variare delle coppie delle
soglie.
Il pending time after trigger
Questo tempo viene utilizzato per limitare i recapiti consecutivi, dopo che un
resoconto è già stato spedito al livello RRC.
Le figure 6.8 e 6.9 rappresentano la durata media della connessione RRC e il
traffico smaltito in media per connessione al variare del tempo di pending. Il valore
delle soglie inferiore e superiore è invece fissato rispettivamente a 20 e 100 PDU.
Analizzando il grafico della durata della connessione, si osserva che per valori
crescenti del pending time la curva aumenta lentamente. Un passaggio del tempo di
sospensione dei resoconti da 0.25 a 4 s provoca però una variazione di circa 2 s nella
durata della connessione RRC. Questo è dovuto al fatto che il MAC impiega
sempre più tempo a comunicare al livello RRC eventuali variazioni del volume di
traffico sul canale monitorato e quindi la velocità dell’utente viene cambiata meno
frequentemente.
Rappresentazione della durata media della connessione RRC al
variare del pending time after trigger
32
Durata media [s]
31,5
31
30,5
THl = 20, ThU = 100,
Event_Trigger
30
29,5
29
28,5
0,25
0,5
0,75
1
1,5
2
4
pending time [s]
Figura 6.8 : Durata media della connessione RRC al variare del pending time after trigger
170
§6 - Risultati delle simulazioni
Traffico smaltito in media per sessione
27,5
Throughput medio [kbit/s]
27
26,5
ThL = 20, ThU = 100, Event
Trigger
26
25,5
25
24,5
0,25 0,5 0,75
1
1,5
2
4
pending time [s]
Figura 6.9 : Traffico smaltito in media per sessione al variare del pending time after trigger
6.2.2.1.2 Modalità di misura periodica (Periodical)
Questa modalità di misura prevede che il MAC fornisca i risultati delle misure dopo
che è trascorso un intervallo temporale fissato dal RRC.
In figura 6.10 e 6.11 si rappresentano le curve della durata della connessione
RRC e del traffico smaltito in media per connessione al variare del periodo di invio
delle misure (reporting time).
Rappresentazione della durata media della connessione RRC al
variare del reporting time
32
Durata media [s]
31,5
31
30,5
Periodical
30
29,5
29
28,5
0,25
0,5
0,75
1
1,5
2
4
reporting time [s]
Figura 6.10 : Durata media della connessione RRC al variare del reporting time
171
§6 - Risultati delle simulazioni
Traffico smaltito in media per sessione
Throughput medio [kbit/s]
27,5
27
26,5
26
Periodical
25,5
25
24,5
0,25
0,5
0,75
1
1,5
2
4
reportring time [s]
Figura 6.11 : Traffico smaltito in media per sessione al variare del reporting time
L’andamento c he si osserva in questi diagrammi è simile a quello osservato nelle
figure 6.8 e 6.9. La spiegazione è giustificata dal fatto che aumentando il reporting
time cresce anche il tempo con cui il RRC riceve le misure in base alle quali può
decidere se riconfigurare il Radio Bearer (assegnando per esempio un codice con
spreading factor differente).
6.2.2.2 Stima della qualità del canale radiomobile
Il canale radiomobile può trovarsi alternativamente nello stato GOOD o BAD con
dei tempi di permanenza negli stati che determinano la qualità del mezzo trasmissivo
(valutata in termini di probabilità di errore media sul blocco trasmesso Perr). Se il
canale è nello stato BAD, si ipotizza che le informazioni transitate sul canale siano
alterate ad un punto tale da non essere più recuperabili. I pacchetti devono quindi
essere scartati.
La procedura di livello RRC sulla stima della qualità del mezzo (misurazione
intra-frequency) consente al Radio Resource Control di interrompere la trasmissione
dei dati quando la stima indica uno stato cattivo del mezzo trasmissivo. Questa
operazione di sospensione della trasmissione è però possibile solo in quei Radio
Bearer che utilizzano la modalità RLC Unacknowledged o Acknowledged. L’entità
RLC operante in queste due modalità prevede infatti uno stato denominato Local
Suspend in cui non è più possibile inviare PDU al livello sottostante. La
sospensione della trasmissione a livello RLC porta conseguentemente ad arrestare la
trasmissione dei dati anche a livello MAC.
172
§6 - Risultati delle simulazioni
Il vantaggio di questa soluzione consiste nella possibilità di ridurre notevolmente
il numero di pacchetti scartati con un conseguente decremento del numero di
ritrasmissioni.
Il parametro che caratterizza l’algoritmo di stima della qualità del canale
radiomobile è l’intervallo di campionamento. All’aumentare di questo periodo il
RRC si accorge sempre più lentamente delle variazioni del canale; tale situazione è
tanto più evidente quanto più grande è la probabilità di errore sul mezzo trasmissivo.
Inoltre aumenta anche il tempo di permanenza del Radio Bearer dell’utente nello
stato di suspend. Nelle figure 6.12, 6.13, 6.14 e 6.15 si riporta l’andamento della
qualità del canale radiomobile visto da un utente e l’andamento della stima effettuata
per diversi valori del tempo di campionamento in funzione del tempo. La
probabilità media di errore sul canale è invece tenuta costante e pari a Perr = 0.2.
Per valutare gli effetti di questa procedura sulle prestazioni del sistema, si
tracciano nei grafici 6.16 e 6.17 rispettivamente l’andamento del traffico medio
smaltito per connessione e la durata media della connessione RRC al variare del
tempo di campionamento del canale. Le curve sono parametrizzate in base a diversi
valori della probabilità di errore sul canale. Le simulazioni sono state condotte in un
ambiente così caratterizzato:
numero di utenti presenti nello scenario uguale a 2;
servizio simulato di tipo UDD;
Interactive RABS che prevede il CPCH come canale di trasporto e la
modalità Acknowledged come tipologia di trasferimento a livello RLC;
Dalle curve in figura 6.16 e 6.17 si osserva come la variazione del throughput
medio e della durata media della connessione RRC sia piuttosto piccola per valori
bassi della Perr e al variare del tempo di campionamento (Tc). Per valori più grandi
della probabilità di errore invece (0.293 e 0.373) si ha una diminuzione più netta del
traffico smaltito (in kbit/s) all’aumentare del T c. Questa situazione è giustificata dal
fatto che:
una Perr più alta comporta una maggiore probabilità di permanenza del canale
nello stato di BAD;
un Tc più elevato porta a campionare meno frequentemente il canale.
Pertanto nel caso in cui si sospenda la trasmissione, aumenta il tempo di
permanenza del livello 2 nello stato di Local Suspend. I pacchetti sono
quindi costretti a rimanere nei buffer di trasmissione per un tempo più lungo,
con una conseguente crescita del ritardo di consegna degli stessi al ricevitore.
Tende inoltre ad aumentare la durata media della connessione RRC.
Se in più si sceglie come criterio di scarto delle SDU per l’entità RLC quello basato
sul ritardo massimo con cui le SDU possono arrivare al ricevitore, appare evidente
173
§6 - Risultati delle simulazioni
Reporting Time = 0.1 [sec]
1
Sample
Real_UL
Channel Quality
0.8
0.6
0.4
0.2
0
2050 2100 2150 2200 2250 2300 2350 2400 2450 2500 2550
time [frame number]
Figura 6.12 : Diagramma della qualità reale e stimata del canale fisico in funzione del tempo con un
passo di campionamento pari a 0.1 s e Perr = 0.2
Reporting Time = 0.2 [sec]
1
Sample
Real_UL
Channel Quality
0.8
0.6
0.4
0.2
0
2050 2100 2150 2200 2250 2300 2350 2400 2450 2500 2550
time [frame number]
Figura 6.13 : Diagramma della qualità reale e stimata del canale fisico in funzione del tempo con un
passo di campionamento pari a 0.2 s e Perr = 0.2
174
§6 - Risultati delle simulazioni
Reporting Time = 0.3 [sec]
1
Sample
Real_UL
Channel Quality
0.8
0.6
0.4
0.2
0
2050 2100 2150 2200 2250 2300 2350 2400 2450 2500 2550
time [frame number]
Figura 6.14 : Diagramma della qualità reale e stimata del canale fisico in funzione del tempo con un
passo di campionamento pari a 0.3 s e Perr = 0.2
Reporting Time = 0.4 [sec]
1
Sample
Real_UL
Channel Quality
0.8
0.6
0.4
0.2
0
2050 2100 2150 2200 2250 2300 2350 2400 2450 2500 2550
time [frame number]
Figura 6.15 : Diagramma della qualità reale e stimata del canale fisico in funzione del tempo con un
passo di campionamento pari a 0.4 s e Perr = 0.2
175
§6 - Risultati delle simulazioni
che aumentando il Tc e quindi il tempo di permanenza dei pacchetti nei buffer, si
arriva ad una situazione in cui le SDU incominciano ad essere eliminate per la
scadenza del Timer Discard. Per risolvere questo problema e rendere la procedura
di misura della qualità del canale vantaggiosa anche in presenza di entità RLC che
utilizzano un criterio di scarto basato sul Timer Discard, conviene definire due
diversi tempi di campionamento Tc_GOOD e Tc_BAD a seconda che l’ultima stima
indichi rispettivamente uno stato GOOD e BAD del mezzo trasmissivo. In questo
modo
un Tc_GOOD anche piuttosto elevato (per esempio di 0.3 s), sebbene non
consenta al RRC di rilevare numerose transizioni di stato da GOOD a BAD,
non costringe il Radio Bearer a restare sospeso per lungo tempo. Inoltre
all’inconveniente di inviare pacchetti quando lo stato del canale è “cattivo”
pone rimedio il meccanismo di ritrasmissione dell’entità RLC;
tenendo il Tc_BAD piuttosto basso (per esempio di 0.1 s) si campiona più
spesso il canale e si rileva più rapidamente una transizione del canale nello
stato GOOD. Di conseguenza, se da un lato si riduce il tempo di sospensione
della trasmissione dei dati, dall’altro si impedisce al Radio Bearer di inviare
i dati per un tempo che è effettivamente più simile al tempo di permanenza
nello stato BAD del canale.
Traffico smaltito medio per sessione (canale di trasporto = CPCH)
Throughput medio [kbit/s]
30
25
20
P_err = 0,0001
P_err = 0,075
15
P_err = 0,293
10
P_err = 0,373
5
0
0,01 0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4
tempo di campionamento del canale fisico [s]
Figura 6.16 : Traffico smaltito in media per sessione al variare del tempo di campionamento del
canale radiomobile e per diversi valori della probabilità di errore sul canale
176
§6 - Risultati delle simulazioni
Durata media [s]
Durata media della connessione RRC (canale di trasporto =
CPCH)
37
36
35
34
33
32
31
30
29
P_err = 0,0001
P_err = 0,075
P_err = 0,293
P_err = 0,373
0,01 0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4
tempo di campionamento del canale fisico [s]
Figura 6.17 : Durata media della connessione RRC al variare del tempo di campionamento del canale
radiomobile e per diversi valori della probabilità di errore sul canale
6.2.3 DSCH
Il DSCH è il canale a commutazione di pacchetto utilizzato per le trasmissioni in
downlink. Gli utenti sfruttano in modalità condivisa le sequenze ortogonali
disponibili nell’albero dei codici per poter utilizzare questo canale. Per scegliere le
precedenze tra gli utenti in attesa di inviare i dati sul DSCH, si ricorre ad un
algoritmo di schedulazione di tipo Round Robin, basato sul tempo trascorso
dall’ultima trasmissione. Il numero di utenti scelti è quindi funzione della
disponibilità dei codici OVSF. Di conseguenza all’aumentare del numero di utenti
presenti nel sistema, decresce la frequenza con cui un generico utente viene
schedulato.
Nei punti che seguono si vuole verificare il corretto funzionamento delle
procedure di livello RRC che controllano la trasmissione dei dati sul canale di
trasporto DSCH. La traccia seguita per detta verifica ricalca quella utilizzata per
studiare il controllo della trasmissione delle informazioni sul CPCH.
Le procedure di controllo del Downlink Shared Channel, a differenza del CPCH,
sono gestite direttamente dall’entità RRC nell’UTRAN; quest’ultima non deve
quindi delegare allo svolgimento del compito la pari entità nell’UE.
6.2.3.1 Monitoraggio del volume di traffico
Anche in questo caso si vogliono testare le due diverse modalità di recapito delle
misure del volume di traffico sul DSCH: quella a eventi e quella periodica.
177
§6 - Risultati delle simulazioni
6.2.3.1.1 Modalità di misura ad eventi (Event_Trigger)
Le soglie
Lo scenario simulativo è configurato secondo le caratteristiche indicate nel sottoparagrafo 6.2.2.1.1 del presente capitolo. L’unica differenza riguarda i parametri
dell’Interactive RABS che ora prevede il DSCH come canale di trasporto.
Le figure 6.18, 6.19 rappresentano l’occupazione dei buffer di livello RLC,
mediata su tutte le connessioni RRC instaurate, per due coppie di possibili valori
delle soglie.
Anche in questo caso, all’aumentare delle soglie, cresce il numero medio di
occorrenze a parità di valore della BO. In particolare, osservando la figura 6.19, si
nota un andamento piuttosto regolare della curva. Concentrando l’attenzione su un
dettaglio della Buffer Occupancy quando le soglie inferiore e superiore valgono 200
e 600 (vedere figura 6.20), si possono trarre alcune importanti considerazioni.
Alla richiesta di connessione RRC inviata alla rete dall’utente, il RAB_negotiator
risponde instaurando un RAB che prevede una velocità trasmissiva iniziale (ovvero
il bit rate a livello 1 e 2 della pila) di 384 kbit/s, data la completa disponibilità di
risorse nel sistema. Analogamente configura la sorgente di traffico presente
nell’Upper_layer della pila in downlink in modo tale da far entrare detta sorgente
nello stato UDD384, quello cioè che prevede la massima velocità di generazione dei
dati (con un valore di picco di 384 kbit/s). Per convenienza, si indica con vtx e vsource
rispettivamente la velocità di trasmissione e la velocità di generazione dei dati della
sorgente. La sorgente rimarrà nello stato indicato per tutta la durata della sua
sessione. L’assenza infatti di altre richieste di servizi in contemporanea, non
costringe il “negoziatore” ad abbassare la velocità v source dell’unico servizio presente
nel sistema.
vtx [kbit/s]
SDU_size [bit]
PDU_size [bit]
N_PDU per trama
64
3840
320
2
144
3840
360
4
384
3840
320
12
Tabella 6.12 : Relazione tra le SDU e le RLC PDU per caratterizzare la trasmissione a livello 2
Tenendo presente che:
la modalità di monitoraggio del traffico sul canale è ad eventi con un time to
trigger di 0.2 s (vedere tabella 6.8);
178
§6 - Risultati delle simulazioni
la sorgente UDD384 prevede un tempo medio di ON di 0.26 s, un tempo di
generazione dei pacchetti di 0.0104 s e una dimensione delle SDU costante e
pari a 480 byte;
la soglia inferiore è elevata (ThL = 250);
la relazione tra le SDU e le RLC PDU è specificata in tabella 6.12. In
particolare, fissata a priori la dimensione delle PDU in cui vengono
segmentate le SDU dei livelli superiori, si ottiene la seguente formula per
determinare il numero di PDU che il RLC deve inviare al MAC e il MAC a
sua volta deve combinare insieme per creare il Transport Block Set (TBS) da
inviare sul canale, ad ogni trama e con una precisa velocità trasmissiva:
v tx t trama
PDU _ size
N _ PDU
dove
N_PDU = numero di PDU da inviare al livello sottostante per trama;
vtx = velocità trasmissiva in bit/s;
ttrama = durata della trama temporale in s;
PDU_size = dimensione in bit della PDU di livello RLC.
il RAB_fulfiler nell’UTRAN arriva abbastanza rapidamente ad assegnare all’utente
la vtx minima prevista dal sistema (64 kbit/s). Infatti, nel tempo di ON, la sorgente
genera mediamente 25 SDU, che vengono segmentate in circa 300 PDU. Di queste
una parte viene già trasmessa mentre la sorgente è nel sottostato ON del macrostato
UDD384. Pertanto il valore della BO oscilla intorno a 200. Durante il tempo di
OFF (mediamente sui 3 s), la Buffer Occupancy (BO) scende sicuramente sotto la
soglia inferiore che causa un abbassamento del rate trasmissivo. Analizzando la
figura 6.20 si vede inoltre che il valore della BO non supera mai la soglia superiore
(ThU) posta per questa simulazione uguale a 600 PDU. Di conseguenza l’utente
manterrà, una volta assegnata, una vtx di 64 kbit/s fino al termine della connessione
con la rete. Questo permette di spiegare la regolarità che si riscontra nel diagramma
in esame. Infatti quando la sorgente è ON genera in media una SDU per ogni trama.
Tale SDU viene segmentata in 12 PDU e di queste 2 vengono passate al MAC che le
usa per creare il TBS da inviare a destinazione sull’interfaccia “Uu”. Questo
giustifica la regolarità del numero di occorrenze per quei valori della BO che distano
tra loro di 10 PDU. Poichè inoltre, ad ogni trama, vengono spediti (sempre con
successo avendo ipotizzato ideale il canale) TBS formati da 2 RLC PDU, si spiega
subito l’uniformità di altezza dei valori della BO che distano tra loro con un passo di
2 PDU.
179
§6 - Risultati delle simulazioni
Numero di occorrenze medie per
sessione
Buffer Occupancy media di livello RLC (num_UE = 1)
14
12
10
8
ThL = 20, ThU = 100
6
4
2
298
271
244
217
190
163
136
109
82
55
28
1
0
valore della BO [numero di PDU]
Figura 6.18 : Occupazione dei buffer di livello RLC in media per sessione, con valori delle soglie pari
a ThL = 20 PDU e ThU = 100 PDU
257
241
225
209
193
177
161
145
129
113
97
81
65
49
33
17
18
16
14
12
10
8
6
4
2
0
1
Numero di occorrenze medio per
sessione
Buffer Occupancy media di livello RLC
(num_UE = 1, ThL = 200, ThU = 600)
valore della BO [num ero di PDU]
Figura 6.19 : Occupazione dei buffer di livello RLC in media per sessione, con valori delle soglie pari
a ThL = 200 PDU e ThU = 600 PDU
180
§6 - Risultati delle simulazioni
80
78
76
74
72
70
68
66
64
62
60
58
56
54
52
18
16
14
12
10
8
6
4
2
0
50
Numero di occorrenze medio per
sessione
Ingrandimento della Buffer Occupancy media per valori della BO
compresi tra 50 e 80 PDU (ThL = 200, ThU = 600)
valore della BO [numero di PDU]
Figura 6.20 : Ingrandimento dell’occupazione dei buffer di livello RLC in media per sessione, con
valori delle soglie pari a ThL = 200 PDU e ThU = 600 PDU
Si ripetono adesso le simulazioni, cambiando però il numero di utenti presenti
nel sistema. Si pone num_UE = 14. Tutti gli altri parametri vengono mantenuti
invariati.
Le figure 6.21 e 6.22 rappresentano l’occupazione dei buffer di li vello RLC
mediata su tutte le connessioni RRC instaurate per due coppie di possibili valori
delle soglie e con num_UE = 14.
Dall’analisi dei grafici si nota che:
un valore sempre più grande della soglia inferiore costringe l’utente ad
utilizzare un codice associato ad un basso bit rate per un tempo maggiore.
Questo porta di conseguenza ad un incremento del numero di occorrenze per
valori della BO minori della soglia ThL;
un valore della soglia superiore sempre più elevato ritarda invece l’istante in
cui il Radio Resource Control si accorge che è necessario riconfigurare il
Radio Bearer al fine di aumentare la velocità trasmissiva dell’utente. Di
conseguenza i buffer di livello RLC tendono ad aumentare la loro
occupazione, con il rischio di costringere la sorgente dei dati ad interrompere
la generazione dei dati entrando nello stato di Suspend (paragrafo 4.10.1 del
capitolo 4).
Inoltre l’aumento dell’occupazione dei buffer anche per valori bassi delle soglie
(figura 6.21) è giustificato dalla condivisione dei codici tra un numero maggiore di
utenti e dalla schedulazione Round Robin a cui questi ultimi sono sottosposti. Un
181
§6 - Risultati delle simulazioni
utente, infatti, viene schedulato molto più raramente all’aumentare del numero di
servizi che usano questo canale.
12
10
8
6
ThL = 20, ThU = 100
4
2
651
601
551
501
451
401
351
301
251
201
151
51
101
0
1
Numero di occorrenze medie per sessione
Buffer Occupancy media di livello RLC
valore della BO [numero di PDU]
Figura 6.21 : Occupazione dei buffer di livello RLC in media per sessione, con valori delle soglie pari
a ThL = 20 PDU e ThU = 100 PDU
Numero di occorrenze medio per
sessione
Buffer Occupancy media di livello RLC
14
12
10
8
ThL = 200, ThU = 600
6
4
2
1
51
101
151
201
251
301
351
401
451
501
551
601
651
701
751
801
851
0
valore della BO [numero di PDU]
Figura 6.22 : Occupazione dei buffer di livello RLC in media per sessione, con valori delle soglie pari
a ThL = 200 PDU e ThU = 600 PDU
182
§6 - Risultati delle simulazioni
Durata media [s]
Rappresentazione della durata media della connessione RRC al
variare del pending time after trigger
32
31,5
31
30,5
30
29,5
29
28,5
ThL = 20, ThU = 100,
Event_Trigger
0,25
0,5
0,75
1
1,5
2
4
pending time [s]
Figura 6.23 : Durata media della connessione RRC al variare del pending time after trigger relativo al
monitoraggio del canale di trasporto DSCH
Traffico smaltito in media per sessione
Throughput medio [kbit/s]
27,5
27
26,5
26
25,5
ThL = 20, ThU = 100,
Event_Trigger
25
24,5
24
0,25
0,5
0,75
1
1,5
2
4
pending time [s]
Figura 6.24 : Traffico smaltito in media per sessione al variare del pending time after trigger relativo
al monitoraggio del canale di trasporto DSCH
183
§6 - Risultati delle simulazioni
Il pending time after trigger
Le figure 6.23 e 6.24 illustrano l’andamento della durata media della connessione
RRC e del traffico smaltito in media per connessione al variare del tempo di
pending. Le soglie inferiore e superiore sono fissate ad un valore di 20 e 100 PDU
rispettivamente. Le curve presentano un andamento simile a quello tracciato per il
canale di trasporto CPCH. Infatti riducendo i recapiti consecutivi delle misure
effettuate dal MAC per il RRC, aumenta il tempo impiegato dal sistema a variare la
velocità trasmissiva in base all’andamento dell’occupazione dei buffer.
6.2.3.1.2 Modalità di misura periodica (Periodical)
Le figure 6.25 e 6.26 mostrano la durata media della connessione RRC e il traffico
smaltito in media per sessione al variare del reporting time, quando il canale
utilizzato per la trasmissione dei dati è il DSCH.
Come già per il CPCH (paragrafo 6.2.2.1.2 del presente capitolo), anche in questo
caso il traffico smaltito decresce all’aumentare del periodo di invio delle misure. In
particolare lo scarto relativo tra le durate medie delle connessioni RRC
corrispondenti rispettivamente ad un reporting time di 0.25 s e di 4 s vale circa 2
secondi.
Rappresentazione della durata media della connessione RRC al
variare del reporting time
32
Durata media [s]
31,5
31
30,5
Periodical
30
29,5
29
28,5
0,25
0,5
0,75
1
1,5
2
4
reporting time [s]
Figura 6.25 : Durata media della connessione RRC al variare del reporting time
184
§6 - Risultati delle simulazioni
Traffico smaltito in media per sessione al variare del reporting
time
Throughput medio [kbit/s]
27,5
27
26,5
26
Periodical
25,5
25
24,5
24
0,25
0,5
0,75
1
1,5
2
4
reporting time [s]
Figura 6.26 : Traffico smaltito in media per connessione RRC al variare del reporting time
6.2.3.2 Stima della qualità del canale radiomobile
Le figure 6.27 e 6.28 rappresentano il traffico smaltito in media per connessione e la
durata media della connessione RRC al variare del tempo di campionamento, che
caratterizza l’algoritmo di stima della qualità del canale.
Le curve sono
parametrizzate in base a diversi valori della probabilità di errore medio sul blocco.
Traffico smaltito medio per sessione (canale di trasporto DSCH)
Throughput medio [kbit/s]
30
25
20
P_err = 0,0001
P_err = 0,075
15
P_err = 0,293
P_err = 0,373
10
5
0
0,01 0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4
tempo di campionamento del canale fisico [s]
Figura 6.27 : Traffico smaltito in media per sessione al variare del tempo di campionamento del
canale radiomobile e per diversi valori della probabilità di errore sul canale
185
§6 - Risultati delle simulazioni
Durata media della connessione RRC (canale di trasporto DSCH)
37
Durata media [s]
36
35
P_err = 0,0001
34
P_err = 0,075
33
P_err = 0,293
32
P_err = 0,373
31
30
29
0,01 0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4
tempo di campionamento del canale fisico [s]
Figura 6.28 : Durata media della connessione RRC al variare del tempo di campionamento del canale
radiomobile e per diversi valori della probabilità di errore sul canale
Le simulazioni sono condotte in un ambiente in cui sono presenti due utenti che
richiedono sempre un servizio UDD sul canale di trasporto in downlink DSCH.
Dalle curve si nota un comportamento analogo a quello osservato per il canale in
uplink CPCH. Ciò è dovuto al fatto che il modello di canale, utilizzato dai Node_B
per simulare la qualità del mezzo trasmissivo in downlink, è uguale al modello usato
negli UE per emulare il canale radiomobile in uplink. Valgono quindi tutte le
considerazioni descritte nel paragrafo 6.2.2.2.
6.2.4 DCH
Il DCH è il canale utilizzato per la trasmissione a circuito dei dati. La richiesta di un
servizio su questo canale viene accettata solo se è possibile allocare in modo
esclusivo all’utente richiedente un codice per tutta la durata della sua connessione.
Al contrario, se dopo eventuali operazioni di rinegoziazione di servizi UDD già
attivati, non ci sono più codici disponibili da assegnare in modo dedicato, la
richiesta del nuovo servizio viene rifiutata. Dal momento che il comportamento del
canale è uguale per la trasmissione sia in uplink che in downlink, si riportano le
prove effettuate usando il DCH solo in uplink.
La traccia seguita per la verifica delle procedure di controllo della trasmissione
su questo canale è uguale a quella seguita per i canali di trasporto già studiati.
186
§6 - Risultati delle simulazioni
6.2.4.1 Monitoraggio del volume di traffico
6.2.4.1.1 Modalità di misura ad eventi (Event_Trigger): le soglie
14
12
10
8
ThL = 20, ThU = 100
6
4
2
287
261
235
209
183
157
131
105
79
53
27
0
1
Numero di occorrenze medie per sessione
Buffer Occupancy media di livello RLC
valore della BO [numero di PDU]
Figura 6.29 : Occupazione dei buffer di livello RLC in media per sessione, con valori delle soglie pari
a ThL = 20 PDU e ThU = 100 PDU
286
267
248
229
210
191
172
153
134
115
96
77
58
39
20
18
16
14
12
10
8
6
4
2
0
1
Numero di occorrenze medie per sessione
Buffer Occupancy media di livello RLC (ThL = 200, ThU = 600)
valore della BO [numero di PDU]
Figura 6.30 : Occupazione dei buffer di livello RLC in media per sessione, con valori delle soglie pari
a ThL = 200 PDU e ThU = 600 PDU
187
§6 - Risultati delle simulazioni
Le curve in figura 6.29 e 6.30 mostrano l’occupazione media dei buffer di livello
RLC per due diversi valori delle coppie di soglie, usate dall’algoritmo di
monitoraggio del canale DCH nella modalità Event_Trigger. Le considerazioni che
si traggono dall’analisi dei grafici sono simili a quelle riportate per il canale DSCH,
quando è presente un solo utente nello scenario simulativo.
6.2.4.1.2 Modalità di misura ad eventi (Event_Trigger) e periodica (Periodical)
In questo sotto-paragrafo si vogliono confrontare le due diverse modalità di
monitoraggio del traffico sul canale DCH, a parità di valori del pending time e del
reporting time.
Nelle figure 6.31 e 6.32 si presenta la durata media della connessione RRC e il
traffico smaltito medio per connessione al variare del pending time e del reporting
time rispettivamente per la modalità Event_trigger e Periodical. Le simulazioni
sono state condotte considerando un solo utente nel sistema, che richiede sempre un
servizio UDD usando il DCH come canale di trasporto. Si è ipotizzato un
trasferimento privo di errori sul mezzo trasmissivo (ovvero il canale rimane GOOD
per tutta la durata della simulazione). L’analisi delle due curve mostra come le
diverse modalità di monitoraggio del canale non producano differenze sostanziali
sulle prestazioni del sistema.
Durata media della connessione RRC in base alla modalità di
misura del traffico sul canale DCH
32
Durata media [s]
31,5
31
30,5
Event_Trigger
Periodical
30
29,5
29
28,5
0,25
0,5
0,75
1
1,5
2
4
pending time [s] - reporting time [s]
Figura 6.31 : Confronto della durata media della connessione RRC a parità di valori del pending time
e del reporting time delle rispettive modalità Event_Trigger e Periodical
188
§6 - Risultati delle simulazioni
Throughput medio [kbit/s]
Confronto del traffico smaltito in media per sessione
parametrizzato in base alla modalità di monitoraggio del canale
DCH
27,5
27
26,5
26
25,5
25
24,5
24
Event_Trigger
Periodical
0,25
0,5
0,75
1
1,5
2
4
pending time [s] - reporting time [s]
Figura 6.32 : Confronto del traffico medio smaltito a parità di valori del pending time e del reporting
time delle rispettive modalità Event_Trigger e Periodical
Traffico smaltito in media per sessione
Throughput medio [kbit/s]
30
25
20
P_err = 0,0001
P_err = 0,075
15
P_err = 0,293
P_err = 0,373
10
5
0
0,01 0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4
tempo di campionamento del canale fisico [s]
Figura 6.33 : Traffico smaltito in media per sessione al variare del tempo di campionamento del
canale radiomobile e per diversi valori della probabilità di errore sul canale
189
§6 - Risultati delle simulazioni
Durata media della connessione RRC
37
Durata media [s]
36
35
P_err = 0,0001
34
P_err = 0,075
33
P_err = 0,293
32
P_err = 0,373
31
30
29
0,01 0,05
0,1
0,15
0,2
0,25
0,3
0,35
0,4
tempo di campionamento del canale fisico [s]
Figura 6.34 : Durata media della connessione RRC al variare del tempo di campionamento del canale
radiomobile e per diversi valori della probabilità di errore sul canale
6.2.4.2 Stima della qualità del canale radiomobile
Le figure 6.33 e 6.34 rappresentano il traffico smaltito in media per connessione e la
durata media della connessione RRC al variare del tempo di campionamento, che
caratterizza l’algoritmo di stima della qualità del canale. Anche in questo caso
valgono le stesse considerazioni fatte per l’analisi della procedura con gli altri canali
di trasporto.
6.3 Servizi STREAMING
In questo paragrafo si vogliono delineare le prestazioni del sistema UMTS in
presenza di utenti che richiedono esclusivamente servizi della classe Streaming di
QoS. Le simulazioni sono state effettuate variando alternativamente i parametri qui
elencati:
tempo medio di attività della sorgente Streaming;
numero di utenti presenti nel sistema.
Le prove sono state ripetute per due diversi valori della probabilità di errore media
sul canale radiomobile (Perr). Questo ha permesso di parametrizzare i grafici sulla
base della qualità del mezzo trasmissivo.
Quando il Radio Resource Control nell’UTRAN accetta una richiesta di servizio
da parte di un utente, instaura uno Streaming RABS che presenta le caratteristiche
190
§6 - Risultati delle simulazioni
elencate in tabella 6.3. Essendo la classe Streaming usata per il trasporto di traffico
real time unidirezionale sia audio che video, tale RABS deve garantire un certo bit
rate e un ritardo di trasferimento contenuto. Per questo conviene utilizzare il DCH
come canale di trasporto e la modalità Transparent come modo di trasferimento a
livello RLC. Se si desidera anche conservare la relazione temporale tra le varie
entità che compongono il flusso dati, è invece conveniente ricorrere alla modalità
Unacknowledged del Radio Link Control.
6.3.1 Tempo costante di attività della sorgente
I risultati presentati in questo primo sotto-paragrafo sono stati ricavati mantenendo il
tempo medio di attività della sorgente costante e pari a 60 s. Si è invece variato il
numero di utenti presenti nel sistema e la qualità del mezzo trasmissivo.
Dal confronto tra traffico offerto e smaltito in media per sessione (figura 6.35), si
osserva come il throughput segue l’andamento del traffico offerto sia a l variare del
numero di utenti sia per diversi valori della Perr. Questo comportamento è
giustificato dalla configurazione impostata per lo Streaming RABS. La scelta in
particolare del DCH come canale di trasporto costringe il RAB_negotiator ad
ammettere un nuovo servizio, solo se si può assegnare all’utente in modo esclusivo
un codice capace di garantire una velocità trasmissiva massima di 384 kbit/s.
Ricordando i parametri di configurazione dell’albero delle sequenze OVSF (tabella
6.4), sono al più due i servizi Streaming su canale dedicato che la rete può accettare
contemporaneamente. Pertanto all’aumentare del numero di UE che richiedono
questo servizio, solo due riescono ad instaurare la connessione RRC con la rete; gli
altri invece vedono respinta la domanda di connessione. Questo spiega anche
l’andamento della probabilità di blocco (P b) di figura 6.36. Si nota come per un
numero di UE al più uguale a due la Pb valga zero. Al crescere degli utenti nel
sistema, cresce anche il valore di questa probabilità. La curva 6.35 mostra infine
come all’aumentare della P err sul canale diminuisca il traffico medio smaltito.
Questo fenomeno è dovuto al maggior numero di blocchi persi per il cattivo stato del
mezzo trasmissivo.
In figura 6.37 si illustra il tempo medio impiegato da un utente per instaurare la
connessione RRC con l’UTRAN. Per spiegare l’andamento raffigurato, è necessario
ricordare che l’utente può ricevere al più N300 messaggi di rifiuto dalla rete (e di
conseguenza rispedire al massimo N300 volte le richieste di connessione), prima di
considerare definitivamente fallito il tentativo di connessione (N300 è un parametro
di livello RRC posto uguale a 5 per le simulazioni). Pertanto, al crescere del numero
di utenti, aumenta il tempo di instaurazione della connessione. Dalla curva si nota in
particolare che, fino a quando il numero di utenti è minore o uguale ai codici
disponibili, il tempo in esame assume valori molto piccoli (dell’ordine di poche
decine di millisecondi); quando gli UE superano il numero delle sequenze ortogonali
a disposizione, il periodo di instaurazione tende a crescere (ovvero gli utenti
191
§6 - Risultati delle simulazioni
mediamente non riescono ad instaurare la connessione RRC con i primi tentativi
della medesima richiesta).
Confronto tra traffico offerto e traffico smaltito in media per sessione
al variare del numero di utenti e della probabilità di errore sul canale
Traffico medio [kbit/s]
200
190
Traffico offerto
180
traffico smaltito,
P_err=0.0001
170
traffico smaltito,
P_err=0.075
160
150
1
2
3
4
5
num_UE
Figura 6.35 : Traffico offerto e traffico smaltito in media per connessione al variare del numero di
utenti e della probabilità di errore sul canale
P_blocco
Probabilità di blocco al variare del numero di utenti e della
probabilità di errore sul canale
1
0,9
0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
P_err = 0.0001
P_err = 0.075
1
2
3
4
5
num_UE
Figura 6.36 : Probabilità di blocco al variare del numero di utenti e della probabilità di errore sul
canale
192
§6 - Risultati delle simulazioni
Tempo medio [s]
Tempo medio di instaurazione della connessione RRC al variare
del numero di utenti e della probabilità di errore sul canale
4
3,5
3
2,5
2
1,5
1
0,5
0
P_err = 0.0001
P_err = 0.075
1
2
3
4
5
num_UE
Figura 6.37 : Tempo medio per instaurare la connessione RRC al variare del numero di utenti e della
probabilità di errore sul canale
Durata media [s]
Durata media della connessione RRC al variare del numero di utenti
e della probabilità di errore sul canale
70
68
66
64
62
60
58
56
54
52
50
P_err = 0.0001
P_err = 0.075
1
2
3
4
5
num_UE
Figura 6.38 : Durata media della connessione RRC al variare del numero di utenti e della probabilità
di errore sul canale
193
§6 - Risultati delle simulazioni
La figura 6.38 mostra infine l’andamento della durata media della connessione
RRC al variare del numero di utenti e di Perr. Si nota come il tempo medio della
connessione sia confrontabile con il tempo medio di attività della sorgente (60 s),
anche al variare della probabilità di errore sul canale. Questo è dovuto al fatto che la
modalità Transparent, usata per trasmettere i dati, non prevede alcun meccanismo di
controllo sul flusso delle informazioni (vedere capitolo 3 per maggiori dettagli su
questa modalità di trasferimento del livello RLC).
6.3.2 Numero costante di utenti nel sistema
Si vuole adesso valutare il comportamento del sistema al variare del tempo di
attività della sorgente. Si è pertanto deciso di mantenere costante ed uguale a due il
numero di utenti presenti nello scenario simulativo. Le prove sono inoltre state
effettuate per due diversi valori della probabilità di errore sul canale radiomobile.
In figura 6.39 si confronta l’andamento del traffico medio offerto con il traffico
smaltito in media per connessione, al variare del tempo medio di attività della
sorgente e al variare della qualità del mezzo trasmissivo. Si osserva come il
throughput segua l’andamento del traffico offerto, per entrambi i v alori della Perr; al
crescere di quest’ultimo parametro però lo scarto tra il traffico offerto e quello
smaltito tende ad aumentare. Questo è dovuto al fatto che valori crescenti della
probabilità di errore sul blocco causano una perdita sempre maggiore di
informazioni (figura 6.40).
Traffico smaltito in media per sessione al variare del tempo di attività
della sorgente e della probabilità di errore sul canale (num_UE = 2)
Traffico medio [kbit/s]
190
180
traffico offerto
170
traffico smaltito,
P_err=0.0001
160
traffico smaltito,
P_err=0.075
150
140
30
60
90
120
150
180
tempo medio di attività della sorgente [s]
Figura 6.39 : Confronto tra traffico offerto e smaltito, al variare del tempo medio di attività della
sorgente e della probabilità di errore sul canale
194
§6 - Risultati delle simulazioni
Dati medi per sessione [kbyte]
Confronto tra dati generati dalla sorgente e dati smaltiti con
successo su "Uu" parametrizzati in base alla probabilità di errore
sul canale
4500
4000
3500
3000
2500
2000
1500
1000
500
dati generati
dati smaltiti, P_err=0,0001
dati smaltiti, P_err=0,075
30
60
90
120
150
180
tempo medio di attività della sorgente [s]
Figura 6.40 : Confronto tra dati generati dalla sorgente e dati smaltiti, al variare del tempo medio di
attività della sorgente e della probabilità di errore sul canale
6.4 Servizi UDD
In questo paragrafo si analizzano le prestazioni del sistema in presenza di utenti che
richiedono esclusivamente servizi UDD della classe Interactive. I risultati sono stati
ottenuti variando alternativamente i seguenti parametri di sistema:
numero di utenti;
dimensione media dei dati generati dalla sorgente;
probabilità di errore sul canale radiomobile.
Le stesse simulazioni sono poi state ripetute cambiando il canale di trasporto
previsto dall’Interactive RABS. Tutti gli altri parametri di sistema, se non
espressamente indicato, assumono i valori riportati nelle tabelle del paragrafo 6.2.
6.4.1 CPCH
L’obiettivo di questo sotto-paragrafo è quello di stabilire il comportamento del
simulatore quando si sceglie il CPCH come canale per trasmettere i dati degli utenti.
195
§6 - Risultati delle simulazioni
6.4.1.1 Dimensione fissa dei dati generati dalla sorgente
I risultati riportati nei punti che seguono sono stati ricavati mantenendo la
dimensione media dei dati generati dalla sorgente UDD pari a 100 kbyte.
6.4.1.1.1 Probabilità di errore media sul canale fissata
Si è a questo punto scelto di tracciare l’andamento di diversi parametri di
simulazione al variare del numero di utenti presenti nel sistema. Le prove sono state
eseguite per diversi valori della Perr.
Probabilità di errore Perr = 0.0001
Il diagramma in figura 6.41 mette a confronto il traffico offerto dalla sorgente e il
traffico smaltito mediamente per connessione RRC, al variare del numero di utenti
presenti nel sistema. L’andamento del traffico offerto è giustificato dai requisiti del
servizio che si vuole simulare. L’UDD è infatti un servizio best effort che non
presenta particolari requisiti sui tempi di consegna. Di conseguenza la sorgente di
questo tipo di traffico possiede una velocità di generazione dei dati, che è funzione
del carico attuale della rete. Il RAB_negotiator nel RRC dell’UTRAN all’aumentare
del numero di richieste di servizio tende ad abbassare la velocità delle sorgenti già
attive al fine di accettare un maggior numero di nuovi servizi. In particolare la
scelta di utilizzare un canale a commutazione di pacchetto come il CPCH non pone
limiti sul numero massimo di utenti che possono essere ammessi.
Confronto tra traffico offerto e traffico smaltito in media per
sessione
Throughput medio [kbit/s]
35
30
25
20
traffico offerto
15
traffico smaltito
10
5
0
1
2
4
6
8
10 12 14 16 18 20 22
num UE
Figura 6.41 : Confronto tra traffico offerto e smaltito in media per sessione, usando il CPCH come
canale di trasporto
196
§6 - Risultati delle simulazioni
Il fatto di non dover assegnare codici in modo esclusivo agli utenti permette al RRC
di marcare con COMMON i codici OVSF dell’albero, fino a quando sono
disponibili. Una volta poi che non ci sono più sequenze libere, la rete può
continuare ad accettare nuovi utenti, assegnando loro una velocità di sorgente
minima. Per fornire una spiegazione più chiara di questo algoritmo di riduzione del
rate della sorgente al sopraggiungere di nuove richieste, si illustra come viene
gestito l’albero dei codici dal RAB_negotiator con un esempio.
Supponiamo che ci siano 12 utenti che chiedono un servizio UDD alla rete.
Ricordando le regole di allocazione dei codici e il significato dell’etichetta
COMMON usata per marcare i nodi dell’albero (vedere capitolo 5), si verifica la
situazione descritta nei punti che seguono.
Per facilitare la comprensione
dell’algoritmo, si indi ca con Ci il codice che viene etichettato con C (COMMON)
nel sistema in seguito all’ammissione della richiesta dell’utente i-esimo.
a) L’UE 1 invia la richiesta alla rete di voler instaurare la connessione RRC. Il
RAB_negotiator, ricevuto il messaggio, accetta sicuramente la domanda
essendo il primo utente ad instaurare la connessione RRC. La situazione
dell’albero diventa la seguente (figura 6.42):
N = NOT_AVAILABLE
R = RACH
F = FREE
C = COMMON
D = DEDICATED
T = TAKEN
N
C
N
C1
F
F
F
F
F
C
C
F
F
C
C
C
C
N
C
C
C
C
C
C
F
C
F
N
F
R
R
Figura 6.42 : Albero dei codici con un solo utente ammesso
b) L’UE 2 cerca di instaurare una connessione con la rete. Data la disponibilità
di codici, si verifica la situazione rappresentata in figura 6.43.
197
§6 - Risultati delle simulazioni
N = NOT_AVAILABLE
R = RACH
F = FREE
C = COMMON
D = DEDICATED
T = TAKEN
N
C
N
C
C2
C
C
C
C
C
C
C
C
C
C
C
C
C
C
N
C
C
C
F
C
C
N
F
F
R
R
Figura 6.43 : Albero dei codici con due utenti ammessi
c) Supponiamo adesso che l’UE 3 invia all’UTRAN una richiesta di ins taurare
la connessione RRC. Una volta ricevuta, la rete configura l’albero come
rappresentato in figura 6.44.
N = NOT_AVAILABLE
R = RACH
F = FREE
C = COMMON
D = DEDICATED
T = TAKEN
N
C
N
C
C
C
C
C
C
C
C
C
C
C
C
C
C
N
C
C
C
C3
C
C
C
C
C
C
N
R
R
Figura 6.44 : Albero dei codici con tre utenti ammessi
d) L’UE 4 vuole adesso instaurare la connessione RRC. Il RAB_negotiator deve
prima rinegoziare il servizio dell’utente 1, che possiede la maggior velocità
di sorgente, per poter ammettere il nuovo utente. Assegnando così all’UE 1
una velocità di sorgente più bassa, corrispondente ad un valore di spreading
superiore rispetto a quello relativo alla precedente velocità, si libera un
codice nell’albero che permette alla rete di garantire un nuovo servizio. Il
rate della sorgente del nuovo terminale risulta uguale alla nuova velocità di
generazione della sorgente riconfigurata, presente nell’UE 1.
198
§6 - Risultati delle simulazioni
UE 1 viene
momentaneamente messo
da parte
N = NOT_AVAILABLE
R = RACH
F = FREE
C = COMMON
D = DEDICATED
T = TAKEN
N
C
N
C
F
F
F
F
F
C
C
F
F
C
C
C
C
C
C
N
C
C
C
C
C
C
C
N
C
R
R
Figura 6.45 : Albero dei codici quando si rinegozia un servizio
viene accettata la richiesta del
nuovo utente (UE 4) con un rate
di sorgente minore di quello della
sorgente rinegoziata (UE 1)
N = NOT_AVAILABLE
R = RACH
F = FREE
C = COMMON
D = DEDICATED
T = TAKEN
N
C
N
C
C
F
F
C4
F
C
C
C
C
C
C
C
C
C
C
N
C
C
C
C
C
C
C
N
C
R
R
Figura 6.46 : Albero dei codici con tre utenti ammessi e il quarto deve rientrare
N = NOT_AVAILABLE
R = RACH
F = FREE
C = COMMON
D = DEDICATED
T = TAKEN
N
UE 1 viene reinserito con
servizio rinegoziato dal
RAB_fulfiller
C
N
C
C
C4
C1
C
C
C
C
C
C
C
C
C
C
N
C
C
C
C
C
C
C
C
C
Figura 6.47 : Albero dei codici con quattro utenti ammessi
199
N
C
R
R
§6 - Risultati delle simulazioni
Durante l’esecuzione di tale operazione l’albero dei codici assume la configurazione
illustrata in figura 6.45, 6.46 e 6.47.
Si procede in questo modo fino a quando non sono stati presi tutti i codici e non è
più possibile rinegoziare alcun servizio (abbassando la velocità di sorgente). Se ci
sono ancora utenti che chiedono la connessione e se il canale usato è a pacchetto
(CPCH o DSCH), si instaura ugualmente la connessione.
Tornando ora alla figura 6.41, quanto appena detto spiega perchè il traffico
offerto dalla sorgente decresce da 30 kbit/s fino a 20 kbit/s per un numero di utenti
che passa da 1 a 10. Poi si assesta intorno ai 20 kbit/s per un numero di terminali
maggiore di 10. Si nota inoltre come il traffico smaltito segua quello offerto per un
numero di UE anche superiore a venti.
La figura 6.48 rappresenta la durata media della connessione RRC al variare del
numero di utenti. La crescita della curva per un numero di utenti che passa da 1 a 10
è dovuta al fatto che la velocità della sorgente diminuisce. Poi il tempo della
connessione si assesta intorno ai 40 secondi, quando i terminali variano da 12 a 22.
In figura 6.49 e 6.50 si rappresenta infine la probabilità di blocco e il tempo
medio impiegato ad instaurare la connessione. Per come è stato pensato l’algoritmo
di allocazione delle risorse radio, la probabilità di blocco deve valere zero al variare
del numero di utenti. Per evitare anomalie nella gestione dei codici, può capitare
che il RRC vada a controllare la configurazione dell’albe ro; se si verificano i
presupposti per tale situazione, la rete rifiuta momentaneamente nuove richieste di
connessione. Il fatto comunque di non rifiutare praticamente mai richieste di
connessione giustifica l’andamento del tempo di instaurazione.
Durata media della connessione RRC con attività media della sorgente
UDD di 100 kbyte
Durata media [s]
45
40
35
30
25
20
1
2
4
6
8
10
12
14
16
18
20
22
num UE
Figura 6.48 : Durata media della connessione RRC al variare del numero di utenti e con probabilità di
errore media pari a 0.0001
200
§6 - Risultati delle simulazioni
P_blocco
Probabilità di blocco
1
0,9
0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
1
2
4
6
8
10
12
14
16
18
20
22
num UE
Figura 6.49 : Probabilità di blocco al variare del numero di utenti e con probabilità di errore media
pari a 0.0001
Tempo medio per instaurare una connessione RRC
0,12
Tempo medio [s]
0,1
0,08
0,06
0,04
0,02
0
1
2
4
6
8
10
12
14
16
18
20
22
num UE
Figura 6.50 : Tempo medio per instaurare la connessione RRC al variare del numero di utenti e con
probabilità di errore media pari a 0.0001
201
§6 - Risultati delle simulazioni
Probabilità di errore Perr = 0.075
Si ripetono le prove effettuate al punto precedente, ma impostando una diversa
probabilità di errore sul canale radiomobile.
La figura 6.51 illustra il confronto tra traffico offerto e traffico smaltito in media per
connessione al variare del numero di utenti. Il grafico evidenzia una diminuzione
generale del throughput medio rispetto al caso precedente, dovuta alla maggiore
probabilità di errore sul canale. Si osserva inoltre una riduzione progressiva del
traffico smaltito per un numero di utenti maggiore di 20. Questo comportamento è
da imputare sia alle caratteristiche del canale CPCH sia alla probabilità di errore
maggiore rispetto al caso precedente. Infatti, nel caso in cui il numero di utenti
diventi piuttosto elevato, aumenta la probabilità di collisione per ottenere il
permesso di usare il canale. Inoltre l’insieme dei codici viene condiviso da un
numero più grande di utenti. Infine valori maggiori della Perr causano un numero
maggiore di ritrasmissioni. Tutto questo causa un incremento del tempo di
permanenza dei dati nei buffer del trasmettitore e di conseguenza anche della durata
media della connessione RRC (figura 6.52). Si deve notare però che mentre il
traffico smaltito incomincia a diminuire in corrispondenza di 20 utenti, la durata
media della connessione continua ad oscillare intorno ai 40 s. Tale fenomeno è
giustificato dall’uso del Timer discard, impostato su un valore di 7.5 s, come criterio
per scartare le SDU a livello RLC. Infatti lo scarto relativo che si registra tra la
durata della connessione corrispondente ad un utente e quello che si registra per 20
terminali è proprio di 7.5 secondi. La scelta invece di usare come modalità di scarto
delle SDU il numero massimo di ritrasmissioni (maxR) consentite per la stessa
SDU, se per il throughput farebbe registrare un andamento simile a quello indicato
in figura 6.51, per la durata della connessione dovrebbe causare una continua
crescita all’aumentare degli utenti che richiedono il servizio. Solo nel momento in
cui si supera la soglia massima delle ritrasmissioni consentite, l’andamento della
durata si dovrebbe fermare assumendo un andamento costante al variare del numero
dei terminali nel sistema. Il numero di utenti presso cui si devono verificare gli
eventi citati è comunque funzione del valore impostato per il parametro maxR.
Le figure 6.53 e 6.54 illustrano la curva della probabilità di errore e del tempo
medio di instaurazione della connessione al crescere del numero di utenti nel
sistema. L’analisi dei grafici porta a confermare le osservazioni fatte per un sistema
caratterizzato da una probabilità di errore sul canale Perr = 0.0001.
202
§6 - Risultati delle simulazioni
Confronto tra traffico offerto e traffico smaltito su Uu in media per
sessione (canale di trasporto CPCH)
Traffico medio [kbit/s]
35
30
25
20
traffico offerto
15
traffico smaltito
10
5
0
1
2
4
6
8
10 12 14 16 18 20 22
num UE
Figura 6.51 : Confronto tra traffico offerto e smaltito in media per sessione, usando il CPCH come
canale di trasporto
Durata media della connessione RRC con dimensione media dei
dati generati dalla sorgente UDD di 100 kbyte
Durata media [s]
50
40
30
P_errore = 0,075
20
10
0
1
2
4
6
8
10 12 14 16 18 20 22
num UE
Figura 6.52 : Durata media della connessione RRC al variare del numero di utenti e con probabilità di
errore media pari a 0.075
203
§6 - Risultati delle simulazioni
Probabilità di blocco
0,5
P_blocco
0,4
0,3
0,2
0,1
0
1
2
4
6
8
10
12
14
16
18
20
22
num UE
Figura 6.53 : Probabilità di blocco al variare del numero di utenti e con probabilità di errore media
pari a 0.075
Tempo medio per instaurare una connessione RRC
0,12
Tempo medio [s]
0,1
0,08
0,06
P_errore = 0,075
0,04
0,02
0
1
2
4
6
8 10 12 14 16 18 20 22
num UE
Figura 6.54 : Tempo medio per instaurare la connessione RRC al variare del numero di utenti e con
probabilità di errore media pari a 0.075
204
§6 - Risultati delle simulazioni
Confronto dei risultati parametrizzati in base alla probabilità di errore sul canale
Si rappresentano nelle figure 6.55 e 6.56 il traffico medio smaltito e la durata media
della connessione RRC in funzione del numero di utenti, per diversi valori della Perr.
Il comportamento delle curve giustifica le osservazioni fatte nei punti precedenti.
Throughput medio per sessione
[kbit/s]
Traffico smaltito al variare della probabilità di errore sul canale
fisico e del numero di utenti (canale di trasporto = CPCH - attività
media della sorgente per sessione = 100 kbyte)
35
30
25
20
15
10
5
0
P_errore = 0,0001
P_errore = 0,075
P_errore = 0,2
1
2
4
6
8 10 12 14 16 18 20 22
num UE
Figura 6.55 : Confronto del traffico smaltito dal sistema al variare del numero di utenti per diversi
valori della probabilità di errore media sul canale
Durata media della connessione RRC al variare della Probabilità
di errore sul canale fisico e del numero di utenti
50
Durata media [s]
45
40
P_errore = 0,0001
35
P_errore = 0,075
P_errore = 0,2
30
25
20
1
2
4
6
8
10 12 14 16 18 20 22
num UE
Figura 6.56 : Durata media della connessione RRC al variare del numero di utenti per diversi valori
della probabilità di errore media sul canale
205
§6 - Risultati delle simulazioni
6.4.1.1.2 Numero di utenti fissato
Per fornire maggiori dettagli sul comportamento del sistema, si rappresentano i
parametri misurati utilizzando come ascissa dei grafici la probabilità di errore media
sul mezzo trasmissivo. Si tiene invece fissato il numero di utenti che richiedono il
servizio sul CPCH.
Traffico medio per sessione [kbit/s]
Confronto tra traffico offerto e traffico smaltito in media per
sessione (canale di trasporto = CPCH, num UE = 2)
35
30
25
20
traffico offerto
15
traffico smaltito
10
5
0
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore
Figura 6.57 : Confronto tra traffico offerto e traffico smaltito dal sistema al variare della probabilità
di errore media sul canale radiomobile, usando il CPCH per trasmettere i dati generati da 2 utenti
Durata media [s]
Durata media della connessione RRC
50
45
40
35
30
25
20
15
10
5
0
num UE = 2
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore sul canale
Figura 6.58 : Durata media della connessione RRC al variare della probabilità di errore media sul
canale radiomobile, usando il CPCH per trasmettere i dati generati da 2 utenti
206
§6 - Risultati delle simulazioni
Numero di utenti uguale a 2
Le figure 6.57 e 6.58 mostrano rispettivamente il confronto tra traffico offerto e
traffico smaltito e la durata media della connessione RRC al variare della probabilità
di errore media sul blocco. Il numero di utenti presenti nel sistema è invece costante
e pari a 2. Dalle curve si nota che:
il traffico offerto medio è praticamente costante al variare di Perr. La piccola
diminuzione che però si osserva in corrispondenza di elevati valori della
probabilità di errore può essere imputata al passaggio della sorgente dati
nello stato di Suspend. Quando infatti il RRC nell’UTRAN rileva una
situazione di congestione nella trasmissione dei dati sull’interfaccia “Uu”,
ordina ai livelli superiori dell’utente interessat o di interrompere la
generazione dei dati da inoltrare verso gli strati inferiori della pila
protocollare.
il traffico smaltito decresce all’aumentare della probabilità di errore sul
canale. Questo dipende esclusivamente dalla diretta proporzionalità tra
tempo di permanenza dei dati nei buffer del trasmettitore e Perr, per un
numero di UE uguale a due. Il peggiorare delle qualità del canale infatti
provoca sia un aumento del tempo di sospensione della trasmissione sia un
incremento del numero di ritrasmissioni, essendo il tempo di
campionamento del canale impostato ad un valore di 0.2 s per le simulazioni
sul CPCH. Di conseguenza si allunga il tempo medio della connessione
RRC, necessario a trasferire i dati della sorgente a destinazione. Avendo
inoltre scelto come criterio di scarto delle SDU il Timer Discard, capita che
per elevati valori della Perr una parte delle informazioni venga scartata.
Questo fenomeno influisce a sua volta ad abbassare il throughput medio.
La disponibilità dei codici in questo caso non influisce sui risultati in quanto
consente al sistema di allocare per ogni richiesta degli utenti una sequenza
con lo spreading factor adeguato per trasmettere le informazioni.
Numero di utenti uguale a 12
Le figure 6.59 e 6.60 illustrano rispettivamente il confronto tra traffico offerto e
traffico smaltito e la durata media della connessione RRC al variare della probabilità
di errore media sul blocco, con un numero di utenti presenti nel sistema pari a 12.
Per l’analisi delle curve valgono le osservazioni fatte nell’esempio precedente.
In questo caso però, dato il maggior numero di utenti che richiedono l’accesso al
canale, aumenta la probabilità di collisione sul CPCH; i mobili, che tentano
l’accesso per l’assegnazione del codice, trovano qu indi con più difficoltà risorse
libere da sfruttare per la loro trasmissione.
207
§6 - Risultati delle simulazioni
Traffico medio per sessione [kbit/s]
Confronto tra traffico offerto e traffico smaltito in media per
sessione (canale di trasporto = CPCH, num UE = 12)
25
20
15
traffico offerto
traffico smaltito
10
5
0
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore
Figura 6.59 : Confronto tra traffico offerto e traffico smaltito dal sistema al variare della probabilità
di errore media sul canale radiomobile, usando il CPCH per trasmettere i dati generati da 12 utenti
Durata media della connessione RRC
60
Durata media [s]
50
40
30
num UE = 12
20
10
0
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore sul canale
Figura 6.60 : Durata media della connessione RRC al variare della probabilità di errore media sul
canale radiomobile, usando il CPCH per trasmettere i dati generati da 12 utenti
208
§6 - Risultati delle simulazioni
Confronto dei risultati ottenuti parametrizzati in base al numero di utenti
Si rappresentano nelle figure 6.61 e 6.62 il traffico smaltito e la durata media della
connessione RRC in funzione della probabilità di errore media sul canale
radiomobile, per un numero diverso di utenti presenti nel sistema.
L’andamento delle curve conferma le osservazioni dei punti precedenti.
Traffico smaltito in media per sessione
Throughput medio [kbit/s]
35
30
25
num UE = 2
20
num UE = 12
15
num UE = 16
10
5
0
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore
Figura 6.61 : Confronto del traffico smaltito dal sistema al variare della probabilità di errore media
sul canale
Durata media della connessione RRC
60
Durata media [s]
50
40
num UE = 2
30
num UE = 12
num UE = 16
20
10
0
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore
Figura 6.62 : Durata media della connessione RRC al variare della probabilità di errore media sul
canale
209
§6 - Risultati delle simulazioni
6.4.1.2 Dimensione variabile dei dati generati dalla sorgente
Nelle figure 6.63 e 6.64 si rappresenta il traffico smaltito e la durata media della
connessione RRC al variare della dimensione media dei dati generati dalla sorgente.
Le curve sono parametrizzate in base a diversi valori della probabilità di errore sul
canale; il numero di utenti che usano il CPCH come canale di trasporto è pari a 12.
Traffico smaltito al variare della quantità media dei dati generati
dalla sorgente UDD (Canale di trasporto = CPCH - num UE = 12)
Traffico medio [kbit/s]
22
20
traffico offerto
18
traffico smaltito,
P_err=0,0001
16
traffico smaltito,
P_err=0,075
14
traffico smaltito, P_err=0,2
12
10
100
500
1000
2000
Dimensione media dei dati generati dalla
sorgente [kbyte]
Figura 6.63 : Confronto tra traffico offerto e traffico smaltito al variare della quantità media di dati
generati dalla sorgente, per diversi valori della probabilità di errore sul canale
Durata media della connessione RRC (num UE = 12)
800
Durata media [s]
700
600
500
P_err = 0.0001
400
P_err = 0.075
300
P_err = 0.2
200
100
0
100
500
1000
2000
Dimensione media dei dati generati dalla sorgente [kbyte]
Figura 6.64 : Durata media della connessione RRC al variare della quantità media di dati generati
dalla sorgente, per diversi valori della probabilità di errore sul canale
210
§6 - Risultati delle simulazioni
L’analisi dei grafici evidenzia un diverso comportamento del sistema al variare
della dimensione dei dati generati e al mutare della qualità del mezzo trasmissivo.
In particolare per valori molto bassi della probabilità di errore (Perr = 0.0001), si nota
che il sistema è in grado di smaltire con un rate prossimo a quello del traffico offerto
un carico variabile da 100 a 2000 kbyte. Al peggiorare delle condizioni del canale
radiomobile invece l’uso del CPCH fa registrare un progressivo decremento del
traffico smaltito all’aumentare della dimensione dei dati generati dalla sorgente.
Questo comportamento è dovuto al fatto che l’aumento della quantità dei dati
generati non consente più al mobile di trasmettere tutte le informazioni entro il
limite massimo di trame per cui ha ottenuto il possesso del codice (NF_max). Di
conseguenza, l’UE deve iniziare una nuova fase di contesa, p rima di ottenere una
nuova abilitazione a trasmettere. La crescita della Perr a sua volta incrementa
ulteriormente il tempo necessario per portare a termine la trasmissione, in seguito al
maggior numero di ritrasmissioni.
6.4.2 DSCH
In questo paragrafo si vogliono valutare le prestazioni del sistema quando
l’Interactive RAB di tutti gli utenti nel sistema utilizza il DSCH come canale di
trasporto. I punti che seguono ricalcano la traccia seguita per lo studio del CPCH.
6.4.2.1 Dimensione fissa dei dati generati dalla sorgente
I risultati riportati nei punti che seguono sono stati ricavati mantenendo la
dimensione media dei dati generati dalla sorgente UDD pari a 100 kbyte.
6.4.2.1.1 Probabilità di errore media sul canale fissata
I diagrammi rappresentati nelle figure 6.65, 6.66, 6.67 e 6.68 delineano il
comportamento del sistema al variare del numero di utenti che utilizzano il DSCH
come canale di trasporto. Per questo si è scelto di utilizzare come ascissa dei grafici
il numero di UE e di parametrizzare le curve in base alla probabilità di errore media
sul canale radiomobile.
Le figure 6.65 e 6.66 illustrano rispettivamente il confronto tra traffico offerto e
traffico smaltito e la durata media della connessione RRC al variare del numero di
utenti, per differenti valori della Perr. Le osservazioni sull’andamento del traffico
offerto rispecchiano perfettamente quelle fatte per lo studio del CPCH (vedere il
punto 6.4.1.1.1 del presente capitolo). Per quanto riguarda il traffico smaltito, si
osserva un comportamento che segue il traffico offerto fino a quando la rete è in
grado di garantire le risorse necessarie agli utenti, ogni volta che hanno informazioni
da trasmettere. Se il numero di UE diventa eccessivo, si presentano invece i tipici
problemi di condivisione delle risorse.
211
§6 - Risultati delle simulazioni
Throughput medio per sessione
[kbit/s]
Traffico smaltito al variare della probabilità di errore sul canale fisico
e del numero di utenti (canale di trasporto = DSCH - attività media
della sorgente per sessione = 100 kbyte)
30
25
traffico offerto
20
P_errore = 0,0001
15
P_errore = 0,075
10
P_errore = 0,2
5
0
1
2
4
6
8 10 12 14 16 18 20 22
num UE
Figura 6.65 : Confronto tra traffico offerto e traffico smaltito dal sistema al variare del numero di UE
e per diversi valori della probabilità di errore sul blocco
Durata media della connessione RRC al variare della Probabilità di
errore sul canale fisico
50
Durata media [s]
45
40
P_errore = 0,0001
35
P_errore = 0,075
30
P_errore = 0,2
25
20
1
2
4
6
8
10 12 14 16 18 20 22
num UE
Figura 6.66 : Durata media della connessione RRC al variare del numero di UE e per diversi valori
della probabilità di errore sul blocco
212
§6 - Risultati delle simulazioni
Dalla figura 6.65 si osserva come tale numero di UE sia funzione della qualità del
mezzo trasmissivo. In particolare più è alto il valore della Perr più è basso il numero
totale di utenti che riescono in media a smaltire i dati in un tempo confrontabile con
quello della sorgente. Questo comportamento è dovuto al fatto che una probabilità
di errore sul canale più elevata produce un maggior accodamento dei dati nei buffer
di trasmissione dei vari utenti; cresce di conseguenza la richiesta di codici con basso
spreading factor, che a sua volta riduce il numero complessivo di sequenze
ortogonali a disposizione degli altri utenti. Pertanto aumenta il tempo medio della
connessione RRC e se si sceglie come criterio di scarto delle SDU quello basato sul
Timer Discard, diverse SDU vengono scartate prima che siano arrivate a
destinazione.
Le figure 6.67 e 6.68 mostrano rispettivamente la probabilità di blocco e il tempo
medio impiegato per instaurare la connessione RRC al variare del numero di utenti
che usano il DSCH. Le curve sono sempre parametrizzate in base a diversi valori
della Perr. Il grafico 6.66 mostra come la probabilità di blocco (Pb) valga sempre
zero sia al variare degli UE sia al variare della qualità del canale. Questo è dovuto al
fatto che attualmente per la trasmissione sui canali comuni non è implementata
alcuna politica di ammissione. La curva in figura 6.68 presenta un comportamento
che in parte è legato alla probabilità di blocco. Il valore zero per la Pb però vuol
dire che la richiesta di connessione inviata dall’utente viene sempre accettata, una
volta giunta all’UTRAN. Pertanto in questo caso l’unico fenomeno che influisce sul
tempo di instaurazione della connessione è la probabilità di collisione sul RACH.
Probabilità di blocco
0,5
P_blocco
0,4
P_errore = 0.0001
0,3
P_errore = 0.075
0,2
P_errore = 0.2
0,1
0
1
2
4
6
8 10 12 14 16 18 20 22
num UE
Figura 6.67 : Probabilità di blocco al variare del numero di utenti per diversi valori della probabilità
di errore media sul blocco
213
§6 - Risultati delle simulazioni
Tempo medio per instaurare una connessione RRC
0,3
Tempo medio [s]
0,25
0,2
P_errore = 0.0001
0,15
P_errore = 0.075
P_errore = 0.2
0,1
0,05
0
1
2
4
6
8 10 12 14 16 18 20 22
num UE
Figura 6.68 : Tempo medio per instaurare la connessione RRC al variare del numero di utenti per
diversi valori della probabilità di errore media sul blocco
6.4.2.1.2 Numero di utenti fissato
Per fornire una visione alternativa delle prestazioni del sistema, si rappresentano i
parametri misurati in precedenza utilizzando come ascissa dei grafici la probabilità
di errore media sul mezzo trasmissivo. Le curve sono ora parametrizzate in base al
numero di utenti che richiedono il servizio sul DSCH.
Nelle figure 6.69 e 6.70 si confronta il traffico offerto e il traffico smaltito in
media per connessione al variare della qualità del canale radiomobile, per un numero
di utenti nel sistema uguale rispettivamente a 2 e 12. I grafici 6.71 e 6.72 mostrano
invece il traffico medio smaltito e la durata media della connessione RRC al
crescere della Perr; queste curve sono parametrizzate in base a diversi valori del
numero di utenti. Per l’analisi dei grafici valgono le osservazioni fatte al punto
6.6.2.1.1.
214
§6 - Risultati delle simulazioni
Traffico medio per sessione [kbit/s]
Confronto tra traffico offerto e traffico smaltito in media per
sessione (canale di trasporto = DSCH, num UE = 2)
30
25
20
traffico offerto
15
traffico smaltito
10
5
0
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore
Figura 6.69 : Confronto tra traffico offerto e traffico smaltito dal sistema al variare della probabilità
di errore media sul canale radiomobile, usando il DSCH per trasmettere i dati generati da 2 utenti
Traffico medio per sessione [kbit/s]
Confronto tra traffico offerto e traffico smaltito in media per
sessione (canale di trasporto = DSCH, num UE = 12)
25
20
15
traffico offerto
traffico smaltito
10
5
0
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore
Figura 6.70 : Confronto tra traffico offerto e traffico smaltito dal sistema al variare della probabilità
di errore media sul canale radiomobile, usando il DSCH per trasmettere i dati generati da 12 utenti
215
§6 - Risultati delle simulazioni
Traffico smaltito in media per sessione
Throughput medio [kbit/s]
30
25
20
num UE = 2
15
num UE = 12
num UE = 16
10
5
0
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore
Figura 6.71 : Confronto del traffico smaltito dal sistema al variare della probabilità di errore media
sul canale
Durata media della connessione RRC
60
Durata media [s]
50
40
num UE = 2
30
num UE = 12
num UE = 16
20
10
0
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore
Figura 6.72 : Durata media della connessione RRC al variare della probabilità di errore media sul
canale
216
§6 - Risultati delle simulazioni
6.4.2.2 Dimensione variabile dei dati generati dalla sorgente
Nelle figure 6.73 e 6.74 si rappresenta il traffico smaltito medio e la durata media
della connessione RRC al variare della dimensione media dei dati generati dalla
sorgente. Il numero di utenti che utilizza il DSCH come canale di trasporto è
costante ed uguale a 12.
Traffico medio [kbit/s]
Confronto tra traffico offerto e traffico smaltito in media per
sessione (num UE fisso = 12 - canale di trasporto = DSCH)
23
21
19
17
15
13
11
9
7
5
traffico offerto
traffico smaltito,
P_err=0.0001
traffico smaltito,
P_err=0.075
traffico smaltito, P_err=0.2
100
500
1000
2000
Dimensione media dei dati generati dalla
sorgente UDD [kbyte]
Figura 6.73 : Confronto tra traffico offerto e traffico smaltito al variare della quantità media di dati
generati dalla sorgente, per diversi valori della probabilità di errore sul canale
Durata media [s]
Durata media della connessione RRC
800
700
600
500
400
300
200
100
0
P_err = 0.0001
P_err = 0.075
P_err = 0.2
100
500
1000
2000
Dimensione media dei dati generati dalla sorgente per
sessione [kbyte]
Figura 6.74 : Durata media della connessione RRC al variare della quantità media di dati generati
dalla sorgente, per diversi valori della probabilità di errore sul canale
217
§6 - Risultati delle simulazioni
L’analisi dei grafici mostra come il throughput medio segua il traffico offerto al
variare del carico, per valori della Perr minori o uguali a 0.075. Al peggiorare della
qualità del canale, il traffico smaltito presenta una forte diminuzione all’aumentare
del carico. Questa è dovuta sia all’aumento della durata della connessione sia allo
scadere del Timer Discard, scelto come criterio per scartare le SDU.
6.4.3 DCH
L’obiettivo di questo paragrafo è quello di delineare il comportamento del sistema
quando tutti gli utenti utilizzano il DCH come canale di trasporto. Dal momento che
il DCH presenta caratteristiche equivalenti se usato per trasmettere dati in uplink
oppure in downlink, si considerano le simulazioni effettuate con il DCH in uplink.
6.4.3.1 Dimensione fissa dei dati generati dalla sorgente
I risultati riportati nei punti che seguono sono stati ricavati mantenendo la
dimensione media dei dati generati dalla sorgente UDD pari a 100 kbyte.
6.4.3.1.1 Probabilità di errore media sul canale fissata
A questo punto si è scelto di tracciare l’andamento dei parametri descritti al
paragrafo 6.1 in funzione del numero di utenti presenti nel sistema. Le prove sono
state eseguite per diversi valori della probabilità di errore media sul blocco.
Le figure 6.75 e 6.76 rappresentano il confronto tra il traffico offerto e il traffico
smaltito e la durata media della connessione RRC al variare del numero di utenti.
Le curve sono parametrizzate in base a diversi valori della Perr. Il grafico 6.75
mostra come il throughput medio segua il traffico offerto al crescere del numero
degli utenti. Questo comportamento è dovuto al fatto che il sistema, nel caso di
Interactive RAB che prevede il DCH come canale di trasporto, accetta una richiesta
di connessione solo se è in grado di assegnare in modo esclusivo all’utente una
sequenza ortogonale per tutta la durata del servizio richiesto. Ricordando la
configurazione dell’albe ro usata per condurre le simulazioni (tabella 6.4), sono al
massimo 10 gli utenti che possono instaurare una connessione che utilizza il DCH
come canale. Di conseguenza per un numero di utenti maggiore di 10 si registrano
delle probabilità di blocco non più nulle (figura 6.77), che crescono all’aumentare
degli utenti che richiedono un canale dedicato. Il fatto che la Pb assuma dei valori
molto piccoli ma non nulli per un numero di UE compreso tra 4 e 8 è legato a
meccanismi di controllo dell’albero dei co dici, che, quando diventano attivi,
impediscono agli UE di instaurare la connessione. L’andamento della probabilità di
blocco spiega anche il comportamento del tempo medio per instaurare la
connessione RRC (figura 6.78). Tale tempo di setup, come già evidenziato, dipende
inoltre dalla probabilità di collisione sul RACH.
218
§6 - Risultati delle simulazioni
Throughput medio per sessione
[kbit/s]
Traffico smaltito al variare della probabilità di errore sul canale fisico
e del numero di utenti (canale di trasporto = DCH - attività media
della sorgente per sessione = 100 kbyte)
30
25
traffico offerto
20
P_errore = 0,0001
15
P_errore = 0,075
10
P_errore = 0,2
5
0
1
2
4
6
8
10
12
14
num UE
Figura 6.75 : Confronto tra traffico medio offerto e traffico smaltito in media per connessione per
diversi valori della probabilità di blocco al variare del numero di utenti presenti nel sistema
Durata media della connessione RRC al variare della Probabilità di
errore sul canale fisico
Durata media [s]
45
40
P_errore = 0,0001
35
P_errore = 0,075
30
P_errore = 0,2
25
20
1
2
4
6
8
10
12
14
num UE
Figura 6.76 : Durata media della connessione RRC in funzione del numero di utenti, per diversi
valori della probabilità di errore media sul canale
219
§6 - Risultati delle simulazioni
Probabilità di blocco al variare della probabilità di errore sul canale
fisico
0,6
P_blocco
0,5
0,4
P_err = 0,0001
0,3
P_err = 0,075
0,2
P_err = 0,2
0,1
0
1
2
4
6
8
10
12
14
num UE
Figura 6.77 : Probabilità di blocco in funzione del numero di utenti, per diversi valori della
probabilità di errore media sul canale
Tempo medio per instaurare una connessione RRC
1,4
Tempo medio [s]
1,2
1
P_errore = 0.0001
0,8
P_errore = 0.075
0,6
P_errore = 0.2
0,4
0,2
0
1
2
4
6
8
10
12
14
num UE
Figura 6.78 : Tempo medio per instaurare la connessione RRC al variare del numero di utenti, per
diversi valori della probabilità di errore media sul canale
220
§6 - Risultati delle simulazioni
6.4.3.1.2 Numero di utenti fissato
Si rappresentano adesso i risultati esaminati al punto precedente ponendo in ascissa
la probabilità di errore media sul blocco e parametrizzando le curve sulla base del
numero di utenti presenti nel sistema.
Confronto tra traffico medio offerto e traffico smaltito in media
per connessione RRC
Throughput medio [kbit/s]
30
25
20
traffico offerto numUE=2
traffico smaltito numUE=2
15
traffico offerto numUE=12
10
traffico smaltito numUE=12
5
0
1E-04 0,075 0,128
0,2
0,293 0,373
probabilità di errore
Figura 6.79 : Confronto tra traffico offerto e traffico smaltito dal sistema al variare della probabilità
di errore media sul canale radiomobile, usando il DCH per trasmettere i dati generati dagli utenti
Durata media [s]
Durata media della connessione RRC
50
45
40
35
30
25
20
15
10
5
0
num UE = 2
num UE = 12
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore
Figura 6.80 : Durata media della connessione RRC al variare della probabilità di errore media sul
canale radiomobile, usando il DCH per trasmettere i dati generati dagli utenti
221
§6 - Risultati delle simulazioni
Probabilità di blocco al variare della probabilità di errore sul canale
fisico
0,6
P_blocco
0,5
0,4
num_UE = 2
0,3
num_UE = 12
0,2
0,1
0
0,0001
0,075
0,128
0,2
0,293
0,373
probabilità di errore
Figura 6.81 : Probabilità di blocco al variare della probabilità di errore media sul canale radiomobile,
usando il DCH per trasmettere i dati generati dagli utenti
In figura 6.79 si confronta il traffico medio offerto e il traffico smaltito in media
per connessione al variare della qualità del canale radiomobile; le simulazioni sono
state condotte considerando un numero di utenti presenti nel sistema pari
rispettivamente a 2 e 12. Si osserva come al crescere della Perr aumenti lo scarto
relativo tra traffico offerto e traffico smaltito sia con 2 sia con 12 UE. In particolare
per elevati valori della probabilità di errore lo scarto è maggiore per un sistema con
12 terminali che richiedono un servizio sul DCH. Questo è dovuto al fatto che,
sebbene gli utenti con una connessione RRC con l’UTRAN dispongano di un codice
che garantisce un rate trasmissivo minimo, quando essi hanno bisogno di
incrementare la loro velocità trasmissiva, devono condividere le risorse destinate al
cambio del rate con un numero maggiore di terminali ammessi. Aumenta di
conseguenza il tempo impiegato per trasmettere tutti i dati a destinazione (figura
6.80). L’incremento della durata della connessione dipende anche dalla qualità del
canale; più è grande infatti il valore della Perr, maggiore è il numero di ritrasmissioni
e il tempo di sospensione della trasmissione.
Il grafico 6.81 mostra la probabilità di blocco in funzione della probabilità di errore
media sul mezzo trasmissivo, con un numero di utenti presenti nel sistema uguale a
2 e 12. L’andamento della curva relativa ad un numero di utenti pari a 12 mostra
come la probabilità di blocco cresca al crescere del valore della Perr. Questo
comportamento è giustificato dalla proporzionalità diretta che esiste tra probabilità
di errore sul canale, durata della connessione RRC e probabilità di blocco. Un
incremento della Perr infatti produce un aumento della durata della connessione
RRC; questa a sua volta aumenta il tempo di attesa di quegli utenti che non hanno
potuto instaurare una connessione RRC con la rete per mancanza di risorse radio.
222
§6 - Risultati delle simulazioni
6.5 Servizi UDD e STREAMING
In questo paragrafo si vogliono esaminare le prestazioni del sistema UMTS in
presenza di utenti che richiedono servizi appartenenti a due classi di QoS differenti:
quella Streaming e quella Interactive. Poichè si considera uno scenario di
simulazione dotato di una sola cella, si è scelto di impostare i parametri del file dati
“simul_service.dat” in modo da:
avere sempre due utenti che chiedono un servizio Streaming;
variare solo il numero di UE che richiedono il servizio Interactive.
In tabella 6.13 sono indicate le percentuali utilizzate per configurare il file citato, al
variare del numero di utenti.
Numero di UE nel sistema
4
6
8
10
12
14
Servizio UDD [%]
50
66
75
80
85
87.5
Servizio STREAMING [%]
50
34
25
20
15
12.5
Tabella 6.13 : Configurazione del file simul_service.dat al variare del numero di utenti
L’Interactive RABS e lo Streaming RABS instaurati dal Radio Resource Control
per garantire rispettivamente il servizio dati e il servizio video, presentano le
caratteristiche elencate in tabella 6.3. In particolare si è scelto di trasmettere sul
CPCH le informazioni degli utenti che hanno richiesto un servizio UDD e di
instaurare un canale dedicato per quei UE che hanno richiesto un servizio video.
La dimensione media dei dati generati dalla sorgente UDD è stata posta uguale a
100 kbyte; il tempo medio di attività della sorgente Streaming invece è stato posto
uguale a 60 s. Le prove sono state effettuate al variare della qualità del mezzo
trasmissivo.
In figura 6.82 e 6.83 si confronta il traffico offerto con il traffico smaltito in
media per connessione RRC al variare del numero di utenti totali presenti nel
sistema, rispettivamente per i servizi video e dati. Le curve sono parametrizzate in
base a diversi valori della probabilità di errore media sul canale. Si nota come
l’andamento del throughput relativo al servizio Streaming sia costante sia al variare
degli UE che chiedono un servizio dati sia al peggiorare delle condizioni del canale
radiomobile. Al contrario, per il servizio Interactive, si osserva un decremento del
traffico smaltito medio al crescere del numero degli utenti. Tale comportamento è
tanto più evidente quanto più grande è il valore della Perr.
223
§6 - Risultati delle simulazioni
Confronto tra traffico offerto e traffico smaltito in media per sessione al
variare del numero di utenti (servizio Streaming)
Traffico medio [kbit/s]
185
180
Traffico offerto
175
170
traffico smaltito,
P_err=0.0001
165
traffico smaltito,
P_err=0.075
160
155
4
6
8
10
12
14
num_UE totali nel sistema
Figura 6.82 : Confronto tra traffico offerto e traffico smaltito al variare del numero di utenti totali nel
sistema (servizio STREAMING)
Confronto tra traffico offerto e traffico smaltito in media per sessione
al variare del numero di utenti (servizio Interactive)
Traffico medio [kbit/s]
24
22
Traffico offerto
20
18
16
traffico smaltito,
P_err=0.0001
14
traffico smaltito,
P_err=0.075
12
10
4
6
8
10
12
14
num_UE totali nel sistema
Figura 6.83 : Confronto tra traffico offerto e traffico smaltito al variare del numero di utenti totali nel
sistema (servizio UDD)
224
§6 - Risultati delle simulazioni
Durata media [s]
Durata media della connessione RRC al variare del numero di utenti e
della probabilità di errore sul canale (servizio Streaming)
65
64
63
62
61
60
59
58
57
56
55
P_err = 0.0001
P_err = 0.075
4
6
8
10
12
14
num_UE
Figura 6.84 : Durata media della connessione RRC al variare del numero di utenti totali nel sistema
(servizio STREAMING)
Durata media [s]
Durata media della connessione RRC al variare del numero di utenti e
della probabilità di errore sul canale (servizio Interactive)
45
44
43
42
41
40
39
38
37
36
35
P_err = 0.0001
P_err = 0,075
4
6
8
10
12
14
num_UE
Figura 6.85 : Durata media della connessione RRC al variare del numero di utenti totali nel sistema
(servizio UDD)
225
§6 - Risultati delle simulazioni
Le differenti prestazioni sono dovute al fatto che i servizi video hanno priorità sui
servizi dati, in quanto i primi appartengono alla classe Streaming mentre i secondi
appartengono alla classe Interactive di QoS. Il RAB_fulfiller pertanto quando si
accorge che gli utenti con un servizio video hanno bisogno di un rate trasmissivo
maggiore, deve sempre fare il possibile per assegnare loro un codice con spreading
factor (SF) più basso, a discapito eventualmente degli utenti con un servizio dati. Se
infatti non ci sono più sequenze per garantire la velocità trasmissiva richiesta
dall’UE con servizio Streaming, il RAB_fulfiller deve abbassare (fino addirittura ad
annullare) il rate degli utenti dati in modo da procurarsi un codice con lo SF
desiderato da allocare all’utente in esame. Questa spiegazione giustifica anche
l’andamento della durata media della connessione RRC al variare del numero totale
di utenti nel sistema per servizi video e servizi dati (figure 6.84 e 6.85). Mentre
infatti il tempo medio della connessione per gli utenti con servizio video rimane
costante al crescere del numero di utenti dati, la durata media della connessione
RRC per UE con servizio UDD tende ad aumentare al crescere dei valori riportati in
ascissa in figura 6.85.
Le figure 6.86 e 6.87 illustrano la probabilità di blocco al variare del numero
totale di utenti presenti nel sistema, rispettivamente per servizi video e servizi dati.
Si osserva che la probabilità di blocco per gli utenti che richiedono un servizio dati è
nulla. Questo è dovuto all’utilizzo del canale di trasporto CPCH per trasmettere i
dati degli UE con servizio UDD. La probabilità di blocco per gli utenti con servizio
video invece non è nulla. Ciò è giustificato dall’uso di un canale dedicato per
configurare lo Streaming RABS. Inoltre si nota come al crescere del numero di
utenti con servizio UDD nel sistema, aumenti il valore di questa probabilità di
blocco. Il motivo di tale comportamento è legato alla maggior difficoltà con cui la
rete riesce a garantire un servizio Streaming. Pertanto il RRC nell’UTRAN deve più
spesso rifiutare l’instaurazione della connessione RRC.
226
§6 - Risultati delle simulazioni
P_blocco
Probabilità di blocco al variare del numero di utenti e della probabilità
di errore sul canale (servizio Streaming)
1
0,9
0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
P_err = 0.0001
P_err = 0.075
4
6
8
10
12
14
num_UE
Figura 6.86 : Probabilità di errore al variare del numero di utenti totali nel sistema (servizio
STREAMING)
P_blocco
Probabilità di blocco al variare del numero di utenti e della probabilità
di errore sul canale (servizio Interactive)
1
0,9
0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
P_err = 0.0001
P_err = 0.075
4
6
8
10
12
14
num_UE
Figura 6.87 : Probabilità di errore al variare del numero di utenti totali nel sistema (servizio UDD)
227