Tesi Primo Livello - Studio delle prestazioni di un sistema UMTS e Proosta di Campagne di Simulazione

Streaming Class

Tale classe di servizi riguarda la ricezione da parte dell’utente U.M.T.S., di

video presenti su internet, questi si dividono in due categorie:

video presenti sul web “diffusi” in broadcast;

video trasmessi su specifica richiesta da parte di un utente o un gruppo di

essi;

Come tecnica per il trasferimento dati si usa la steaming multimedia, che

permette di cominciare a vedere il video sul display dell’apparecchio U.M.T.S.

prima che sia scaricato l’intero file.

Tuttavia è necessario garantire il trasferimento dei dati, che devono essere

processati in ricezione, come un flusso continuo e costante, ciò si traduce in

termini applicativi nel garantire una banda costante a tale classe di servizi.

Interactive Class

Tale classe comprende esempi di interazione umana con apparecchiature remote,

tali esempi sono Web Browsing, recupero di database, ed accesso al server.

Sarà pertanto possibile richiedere informazioni su internet, per quanto concerne

località, hotel, ristoranti dal proprio cellulare, senza contare che, come

applicazione interattiva, possiamo considerare anche quella di consultazione del

proprio conto corrente tramite il “portale” della propria banca e la possibilità di

eseguire operazioni bancarie, come effettuare il trading sui mercati azionari,

direttamente dal proprio cellulare senza intermediari.

Relazione dello studente: Michele Nava 7

Background Class

A questa classe appartengono i servizi detti best effort, che riguardano il traffico

dati come SMS (Short Message Service), consegna di e-mail, download di

database e ricezione di documenti. Tali applicazioni non sono sensibili al

ritardo, il quale può essere pochi secondi o alcuni minuti, visto che per tali

servizi si mettono a disposizione risorse in termini di banda, solo se queste non

servono a nessun’altra applicazione di classe “superiore”, secondo l’ordine

seguito nella descrizione delle classi di servizi.

Tuttavia è molto importante che tali dati arrivino a destinazione, totalmente privi

di errori.

Descrizione dell’ambiente di simulazione.

Una volta studiata la complessità della situazione reale, si è passati allo studio

della topologia del sistema cellulare multistrato ed a come tale topologia può

essere “rappresentata” in uno studio emulativo, al fine di comprendere meglio

l’implementazione del simulatore a disposizione.

Considerando un sistema cellulare multistrato come il sistema U.M.T.S., si deve

tenere conto che oltre alle macrocelle (con un raggio di qualche chilometro) e le

microcelle (con un raggio di alcune centinaia di metri), presenti anche nel

G.S.M., qui vi sono anche celle satellitari che hanno una copertura di gran lunga

maggiore anche rispetto alle macrocelle.

Tali strati di celle oltre che per copertura e capacità, si differenziano anche per le

caratteristiche di propagazione del segnale, infatti per quanto riguarda le cellule

Relazione dello studente: Michele Nava 8

satellitari bisogna tener presente che il ritardo, di andata e ritorno del segnale, è

di 250 msec, il ritardo tipico dei satelliti geostazionari, che si pensa di utilizzare.

Tuttavia, come accennato, del sistema reale da “creare” in un programma da

eseguire al calcolatore, è necessario coglierne gli aspetti essenziali, i quali

devono essere utilizzati al fine di costruire il modello che rappresenti l’ambiente

di simulazione in maniera corretta, ma senza aumentare eccessivamente la

complessità computazionale del programma di simulazione, saranno pertanto

necessarie molte approssimazioni e semplificazioni.

Detto ciò è impensabile simulare la divisione in celle di un’intera nazione, per

quel che riguarda il numero delle celle da usare, in questo ambiente di

simulazione si è usato un raggruppamento di celle che preveda la presenza di

quattro microcelle per ogni macrocella.

Tale struttura, seppur semplice, consente di simulare in modo efficace la

mobilità degli utenti nelle quattro direzioni identificabili in un sistema di

riferimento planare ed inoltre, grazie alla sua simmetria, è facilmente

estendibile: basta quadruplicare la struttura, disponendo le repliche ottenute in

modo da preservare la simmetria “a quadrato”.

Il tutto è racchiuso nell’ambito di copertura di un’unica cella satellitare che, con

la sua estensione, copre tutte le celle terrestri. Pertanto il modello di

simulazione, come si può osservare in figura 1, è rappresentato da 16 microcelle,

4 macrocelle ed una cella satellitare.

Relazione dello studente: Michele Nava 9

Figura 1. Modello di Simulazione.

Tuttavia, bisogna sottolineare che, per non appesantire troppo la simulazione,

non viene considerata la mobilità degli utenti all’interno della cella, si suppone

che si abbia un meccanismo di fast power control (basato su un controllo a ciclo

chiuso della potenza trasmessa a 1,5 KHz) che riesca a mitigare notevolmente il

fading (dato dai differenti percorsi che può subire il segnale), lo shadowing

(l’effetto ombra dei palazzi) ed il path loss dovuti al movimento.

Tale controllo di potenza non è stato effettivamente implementato nel

programma di simulazione, ma supponendo che sia già presente nello strato

fisico, si può pensare di usufruire dei suoi benefici effetti.

Al contrario, è importante descrivere il passaggio degli utenti da una cella

all’altra, così come l’inizio e la fine di una trasmissione. Tenendo conto che il

moto può svilupparsi nelle quattro direzioni planari, c’è da dire che per le zone

che sono ai margini dell’intera struttura, e che quindi non hanno una cella

adiacente in una o due direzioni, si considera una continuità toroidale con le

celle del margine opposto, com’è possibile vedere in figura.

Relazione dello studente: Michele Nava 10

Figura 2. Rappresentazione della continuità toroidale delle celle.

Alla luce di quanto detto, si evince che la mobilità degli utenti viene solo

considerata in termini di cambiamenti di microcella, a cui si potrebbe non

accompagnare un evento di handoff, si pensi al caso in cui si abbia uno

spostamento fra due microcelle di una stessa macrocella, di un utente “veloce”

già allocato nello strato macrocellulare.

Pertanto nel simulatore, come si vedrà meglio più avanti, è molto importante la

distinzione degli utenti in base alla velocità nelle due classi utenti veloci e lenti.

Analisi effettuata sul simulatore del sistema U.M.T.S.

Il simulatore studiato è stato implementato, da alcuni tesisti della Facoltà di

Ingegneria Informatica dell’Università di Cosenza, in linguaggio C++. Di tale

linguaggio object oriented, sono state sfruttate pienamente le sue caratteristiche

principali:

Relazione dello studente: Michele Nava 11

la programmazione modulare, che permette di “scomporre” un programma

anche molto complesso in sottoparti, al fine di migliorarne la leggibilità e

facilitarne la manutenzione ed eventuali modifiche in alcune classi, oltre che

renderne più agevole l’implementazione;

la derivazione, che permette di creare oggetti, o meglio classi, aventi le stesse

caratteristiche dei “genitori”, ma con qualcosa in più che li caratterizza. Nelle

successive figure sono raffigurate le varie classi, presenti nel simulatore, con le

rispettive classi derivate. Inoltre, a dimostrazione di quanto detto in precedenza,

è possibile considerare la classe “Cella”, dalla quale derivano le due classi

“Cella Terrestre” e “Cella Satellitare”, che rappresentano le due tipologie di

celle presenti nel sistema cellulare U.M.T.S. (poiché nel G.S.M., si usano solo

celle terrestri). Ovviamente le due classi derivate, sopra citate, hanno entrambe

le caratteristiche generali ereditate dalla classe “Cella”, ma hanno funzioni e dati

aggiuntivi, fra i quali il ritardo di 250 msec per quanto riguarda la cella

satellitare, poichè si sta considerando l’uso di un satellite geostazionario.

Tale parametro è molto importante, poiché sapendo ciò il sistema cerca di non

allocare, nello strato satellitare, degli utenti che richiedono servizi non tolleranti

al ritardo.

Analogo discorso può essere fatto per le classi derivate di “Cella Terrestre”,

nelle quali la differenza sta nell’ampiezza delle celle, che si suddividono in

macro – celle e micro – celle, poiché in questo modello di simulazione non

vengono considerate le pico – celle, che hanno una copertura dell’ordine di

decine di metri e si usano in ambienti ad alta densità di traffico, al fine di

aumentare la capacità del sistema cellulare stesso.

Relazione dello studente: Michele Nava 12

Bearer

Bearer Audio Bearer Video Bearer Dati Bearer Web

Figura 3. Albero di derivazione di Bearer, portatore di servizio per l'utente.

Event

HO_Event FineHO_Event Request_Event NewPacket_Event

Figura 4. Albero di Derivazione degli eventi, che possono avere luogo

in questa simulazione del sistema cellulare U.M.T.S..

Relazione dello studente: Michele Nava 13

Lista

Nodo

ListaPacchetti ListaEventi ListaMisure ListaPBearer

NodoListaPacchetti NodoListaEventi NodoListaMisure NodoListaPBearer

Figura 5. Albero di derivazione di Lista, con l'oggetto contenuto "nodo".

Cella

Cella Terrestre Cella Satellitare

Macro_Cella Micro_Cella

Figura 6. Albero di derivazione di Cella.

Relazione dello studente: Michele Nava 14

Service

Service Audio Service Multi Service Web

Figura 7. Albero di derivazione di Service, nel quale vi sono

i vari servizi che possono essere forniti.

Generatore

di Eventi

Generatore Generatore Generatore

di Eventi RT di Eventi NRT Utenti

Generatore

di Eventi RT

Video

Low High

Figura 8. Albero di derivazione di Generatore di Eventi.

Relazione dello studente: Michele Nava 15

Canale Condiviso Simula

(contiene il main)

Global Simulatore di Canale

Preemptati HandlerEvent

Figura 9. Classi del simulatore, che usano i "tipi", intesi come oggetti definiti nelle altre classi,

ma che non hanno rapporti di derivazione.

Come già detto in precedenza, tale simulatore è ad eventi discreti, pertanto è

molto importante considerare “l’albero di classi” che riguarda gli eventi.

In questa gerarchia di classi sono definiti, o meglio creati, gli oggetti che

rappresentano i vari eventi che possono accadere in un sistema cellulare, il più

importante di essi è sicuramente l’handoff, che permette di attraversare diverse

zone di copertura senza far cadere la chiamata in corso, o almeno ciò avviene se

nella nuova cella ci sono risorse sufficienti per allocare il nuovo utente con i

suoi servizi.

Questo è proprio uno dei problemi cruciali dell’U.M.T.S., che sono stati

affrontati nel simulatore, poiché tale sistema fornisce molti più servizi , rispetto

Relazione dello studente: Michele Nava 16

ai vecchi sistemi cellulari, che vanno dalla chiamata tradizionale alla

navigazione web, dalla video chiamata ai servizi best effort come SMS e posta

elettronica, e per tale motivo è più difficile trovare un modo efficace per evitare

che cada la chiamata.

Al fine di ridurre al minimo tale rischio, si usano due tecniche:

1. si effettua un controllo sulle risorse disponibili in ogni cella;

2. in caso di necessità, per allocare il nuovo utente con i suoi servizi, si

“scalano”, finché consentito, le risorse assegnate ai bearer già presenti nella

cella. Ad ogni caso, in questa fase di handoff, c’è sempre una rinegoziazione

della qualità di servizio (Q.o.S.) offerta dal sistema all’utente.

Nonostante ciò accade ugualmente, che qualche chiamata in corso debba

necessariamente essere interrotta, perciò si può elaborare una statistica sulla

probabilità di caduta, ed è proprio questa che fa parte dei parametri più

importanti, che si considera in fase di simulazione, per valutare la qualità del

sistema, in particolare quanto traffico può gestire.

Un’altra caratteristica che emerge dall’analisi del codice sorgente, è che nel

nuovo sistema di telefonia, così come simulato, si cerca sempre di evitare di far

cadere le chiamate, nell’accezione più generale possibile, ed è per tale motivo

che se le risorse non sono sufficienti o sono al “limite” la chiamata non viene

accettata in partenza.

E’ importante ricordare che in questo lavoro di simulazione si è considerato

come handoff, soltanto il soft handoff, nel quale la chiamata in corso viene

mantenuta con le due stazioni radiobase, sia della vecchia cella, che della nuova,

al fine di stabilire se è possibile cambiare cella, ed il momento opportuno per

farlo, ovvero quando la potenza ricevuta dalla nuova radiobase supera

1

nettamente quella ricevuta dalla vecchia.

1

1 al posto di questo termine generico, sarebbe più giusto dire quando il rapporto fra la potenza del segnale ricevuto dalla

radio base della nuova cella e le interferenze supera, di un fattore di proporzionalità da stabilire, il rapporto fra la

potenza del segnale ricevuto dalla radio base della vecchia cella e le interferenze.

Relazione dello studente: Michele Nava 17

Inoltre, così come nella realtà eventi come l’handoff, possono avvenire solo tra

un frame e l’altro, la cui durata è 10 msec.

Un altro albero di derivazione di classi, oltre ai due considerati, è quello che

riguarda i portatori (bearer) dei servizi, in fig.3, che tiene conto dei vari servizi

che il sistema può offrire, pertanto vi saranno quattro classi che definiranno i

portatori dei quattro servizi disponibili, ovvero:

audio, video, web e dati.

Analogamente sono presenti delle classi, il cui albero di derivazione è riportato

in fig. 6, che definiscono i servizi che può fornire il sistema associati ai portatori

di tali servizi.

E’ bene notare che per quanto riguarda i servizi, sono specificati solo audio, web

e multi, poiché in quest’ultimo vengono definite applicazioni come la video

telefonata, la quale non comprende solo video ma anche audio, ed in generale il

servizio di solo video non è considerato.

Bisogna aggiungere che in una prima versione del simulatore si era considerato

l’approccio Monobearer, che permette di assegnare tutti i servizi di un utente,

video, audio, web, in un solo strato, successivamente, al fine di sfruttare al

massimo le risorse del sistema e diminuire sia la probabilità di caduta che di

blocco della chiamata, si è passati ad uno studio emulativo di un allocazione

multistrato, detta Multibearer.

Tale allocazione permette di assegnare i vari servizi associati ad un utente in

diversi strati, per fare un esempio ad un utente che sta effettuando una video

telefonata, gli si può allocare il video nello strato macrocellulare, e l’audio nello

stato microcellulare, e se nel frattempo tale utente desidera “scaricare” la posta

elettronica dal suo account, gli si può allocare tale servizio nello strato

satellitare.

Continuando l’analisi del codice, una volta definiti gli eventi come oggetti,

bisogna considerare la gerarchia di classi di fig. 8 nella quale vi sono le classi

Relazione dello studente: Michele Nava 18

che gestiscono la generazione degli eventi appena definiti, in maniera non

totalmente random, dato che sono inseriti dei dati, come costanti, che riguardano

la velocità degli utenti o meglio la percentuale di utenti veloci e di utenti lenti

(dalla quale dipende il numero di handoff e la difficoltà nell’allocare i loro

servizi nello strato ottimo, macrocellulare per gli utenti veloci e microcellulare

per i lenti) e la percentuale delle componenti audio, video e dati delle varie

chiamate.

Una volta generati gli eventi, ed anche gli utenti, bisogna ora gestirli e ciò viene

fatto con la classe principale del simulatore, che viene avviata dal main di

simul.cpp.

Tale classe, in fig. 9, è la “HandlerEvent”, nella quale vi sono la maggior parte

delle funzioni per far “scorrere” il tempo della simulazione ad ogni evento

significativo, pertanto l’avanzamento temporale è svolto a passi discreti di 10

msec., che è la durata del frame.

Tale classe deve necessariamente fare riferimento alle classi dell’ultimo albero

di derivazione da considerare, quello delle liste di nodi, in fig. 5.

Tale albero di derivazione tiene conto con la classe Lista pacchetti, dei

“pacchetti” che sono stati ricevuti, per quanto riguarda il servizio associato

all’utente. Un’altra lista riguarda quella degli eventi, la quale è strettamente

correlata con la gestione degli stessi, e stabilisce l’ordine con il quale la classe

handlervent deve “pescare” gli eventi.

Analisi dei risultati ottenuti

Una volta studiato il codice “sorgente” in C++, è stato necessario testarlo e

valutare i risultati ottenuti alla fine delle campagne di simulazione, le quali

Relazione dello studente: Michele Nava 19

avendo diversi input permettono di valutare il sistema U:M.T.S., o meglio il

modello considerato, al variare di determinate situazioni.

Campagne di Simulazione

Prima di procedere alla visualizzazione dei risultati ottenuti durante le

simulazioni, è bene precisare che non è stata rappresentata la dinamica della

realtà istante per istante, ma solo gli eventi che portano ad una variazione dello

stato del sistema. La generazione della storia degli stati avviene, come già

accennato, mediante l’uso di funzioni random e generatori di numeri casuali.

Nel caso del modello di sistema U.M.T.S. esaminato sono presenti dodici

tipologie di eventi che determinano l’evoluzione nel tempo della simulazione:

la fine di una chiamata multimediale real-time;

la fine di un burst dati ;

la fine di un soft handoff;

l’inizio di una fase di low del bit rate del video;

l’inizio di una fase di high del bit rate del video;

l’inizio di una fase di handoff;

l’inizio di una nuova chiamata;

l’inizio di un burst dati;

Relazione dello studente: Michele Nava 20

l’arrivo di un nuovo pacchetto WEB;

l’inizio di una trama UMTS (evento ciclico che si ripete ogni 10 ms, che è la

durata del frame);

l’evento di fine batch;

l’evento di fine simulazione.

Ognuno di tali eventi è caratterizzato da un tempo di accadimento, tale tempo è

dato dall’orologio virtuale della simulazione, implementato in un’apposita

classe.

Lo scheduling degli eventi, che abbiamo visto essere effettuato dalla classe

handlerevent, avviene in base al tempo, solo a parità di questo, in base al tipo di

evento, seguendo l’ordine prima usato.

A questo punto alla fine delle simulazioni, risultati ottenuti sono stati inviati ai

tesisti dell’Università di Cosenza per essere elaborati, al fine di ottenere dei

grafici più facili da commentare.

Tali elaborazioni sono esposte facendo il paragone fra le tre tecniche di gestione

delle risorse radio che possono essere utilizzate, ovvero le tre strategie di

allocazione nello strato:

(BQ)

Better QoS (TBS)

Tier by Speed (FVFM)

Fast Video For Macro

Le grandezze considerate sono:

Relazione dello studente: Michele Nava 21

1. probabilità di blocco, definita in relazione all’eventualità che un nuovo utente

in ingresso al sistema venga rifiutato;

2. la probabilità di caduta, relativa al fatto che una chiamata possa essere

abbattuta durante un handoff, poiché nelle nuova cella non ci sono risorse

necessarie per garantire i requisiti minimi di QoS;

3. il numero di handoff per servizio, calcolato come la somma di tutti gli

handoff di tutte le componenti di un servizio:

4. la percentuale di soddisfacimento del QoS richiesta dal servizio.

La distribuzione dei vari servizi è considerata secondo i due profili, che

permettono di valutare situazioni di traffico differenti, ed il conseguente diverso

comportamento del sistema U.M.T.S. considerato:

1. 70% di servizi multimediali, 15% di telefonate vocali (ovvero le chiamate

tradizionali), 15% di Web browsing;

2. 35% di servizi multimediali, 15% di telefonate vocali, 50% di Web

browsing;

Per quanto concerne la quantità di utenti veloci, è supposta essere il 25%, tranne

in alcuni casi di confronto, nei quali è posta al 2%.

Blocco .

Dall’analisi delle figure, dalla 10 alla 13, è facile intuire che le migliori prestazioni,

per quel che riguarda la minore probabilità di blocco, sono date dall’algoritmo Fast

Video For Macro (FVFM) per entrambi i profili, sia quello con il 70% di utenti

multimediali, che quello con il 35%.

Relazione dello studente: Michele Nava 22

Ciò perché la strategia di allocazione nello strato FVFM, introduce il vincolo che

soltanto i bearer video degli utenti veloci possano usufruire dello strato

macrocellulare. Infatti, il video è la componente che richiede maggior banda e

quindi, se è caratterizzata da elevata mobilità, può causare i maggiori sprechi.

Poiché, bisogna ricordare che in tale modello di simulazione stiamo considerando

come handoff, il soft handoff, e durante quest’ultimo le risorse occupate dal

servizio sono il doppio di quelle necessarie, perché occupate in due celle.

E’ facile intuire che se i bearer video degli utenti fast sono allocati nello strato

microcellulare si ha un enorme spreco di risorse, a causa dei numerosi soft handoff

che si sarà costretti ad effettuare nel corso della durata della chiamata.

Questo spreco inoltre non serve nemmeno a preservare gli utenti fast dalla caduta

della chiamata, in quanto non viene data alcuna garanzia sul fatto che al successivo

handover troveranno le risorse loro necessarie.

Al contrario, le componenti audio e dati degli utenti veloci possono essere inviate

nello strato microcellulare, e ciò non costituisce un grosso spreco di risorse, perché

la prima componente richiede poca banda e la seconda è a burst, non trasmette in

modo continuo nel tempo.

Gli altri due algoritmi di allocazione dello strato presi in considerazione, BQ e

TBS, non applicano lo stesso vincolo del FVFM sullo strato macrocellulare, e

consentono il suo l’utilizzo anche ai bearer audio e dati, anche degli utenti lenti.

Particolarmente disastroso è il BQ, che pone in secondo piano il problema della

velocità degli utenti nella scelta dello strato.

Relazione dello studente: Michele Nava 23

Figura 10. Grafico tratto dalla tesi di laurea di Francesco Appratto

" Gestione innovativa delle risorse radio in ambiente UMTS wCDMA multitier

basata sulla trasmissione multibearer con adaptative QoS ",

raffigurante la probabilità di blocco per gli utenti fast Multimediali (utenti: 70% multimedia, 25% fast).

Relazione dello studente: Michele Nava 24

Figura 11. Grafico tratto dalla tesi di laurea di Francesco Appratto

" Gestione innovativa delle risorse radio in ambiente UMTS wCDMA multitier

basata sulla trasmissione multibearer con adaptative QoS ",

raffigurante la probabilità di blocco per gli utenti slow Multimediali (utenti: 70% multimedia, 25% fast).

Relazione dello studente: Michele Nava 25