Analisi e valutazione di reti UMTS - UniFI

Universita degli Studi di Firenze

FACOLTA DI SCIENZE MATEMATICHE, FISICHE E NATURALI

Corso di Laurea in Informatica

ANALISI E VALUTAZIONEDI RETI UMTS

Tesi di Laurea

Relatore:

Prof. Andrea Bondavalli

Correlatore:

Dott. Paolo Lollini

Candidato:

Leonardo Montecchi

Anno Accademico 2005/2006

Sommario

Questa tesi e il risultato dell’analisi e modellazione di una rete UMTS,tramite il formalismo delle Stochastic Activity Networks, con particolareattenzione alle problematiche di soft handover, outage e mobilita. Sonostati adottati inizialmente dei modelli preliminari, frutto di un prece-dente lavoro, al fine di estenderli, aggiornarli e riorganizzarli in mododa introdurre nuove caratteristiche e aumentare cosı gli scenari rappre-sentabili. Nella modellazione si e cercato di rivedere i modelli esistentitramite un approccio parametrico, per far fronte alla complessita delsistema. Le funzionalita aggiunte al modello comprendono gli outageparziali per le stazioni base e la mobilita per gli utenti, introdotta inmodo scalabile rispetto al numero di stazioni base presenti nel sistema.L’analisi e corredata infine dalla definizione di alcuni parametri di QoSper una rete UMTS, sia dal punto di vista dell’utente che del gestore. Ilmodello ottenuto viene utilizzato per il calcolo di queste misure, verifi-cando cosı il suo corretto funzionamento, sia in scenari che sfruttano lenuove caratteristiche, sia in quelli rappresentabili anche con il modellodi partenza.

Indice

Prefazione v

1 La rete UMTS 1

1.1 UMTS e i sistemi radio 3G . . . . . . . . . . . . . . . . . . . . 1

1.1.1 QoS in UMTS . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2 Classi di QoS . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Tecniche di accesso radio . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Accesso a divisione di frequenza (FDMA) . . . . . . . . 4

1.2.2 Accesso a divisione di tempo (TDMA) . . . . . . . . . . 5

1.2.3 Accesso a divisione di codice (CDMA) . . . . . . . . . . 5

1.2.4 Spreading e despreading . . . . . . . . . . . . . . . . . . 7

1.2.5 Capacita dei sistemi W-CDMA . . . . . . . . . . . . . . 9

1.2.6 Copertura dei sistemi W-CDMA . . . . . . . . . . . . . 11

1.3 Architettura di rete . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3.1 La rete di accesso UTRAN . . . . . . . . . . . . . . . . 13

1.3.2 Macrodiversita . . . . . . . . . . . . . . . . . . . . . . . 15

1.4 Procedure di Handover . . . . . . . . . . . . . . . . . . . . . . . 16

1.4.1 Hard Handover . . . . . . . . . . . . . . . . . . . . . . . 17

1.4.2 Inter-System Handover . . . . . . . . . . . . . . . . . . . 17

1.4.3 Soft e Softer Handover . . . . . . . . . . . . . . . . . . . 17

1.5 Gestione delle risorse radio . . . . . . . . . . . . . . . . . . . . 19

1.5.1 Procedura di accesso casuale (RACH Procedure) . . . . 19

1.5.2 Procedura di Admission Control . . . . . . . . . . . . . 19

1.5.3 Controllo del carico (Congestion Control) . . . . . . . . 20

2 Modellazione di sistemi complessi 23

2.1 Il concetto di Dependability . . . . . . . . . . . . . . . . . . . . 23

i

2.2 State-Based Models . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.1 Catene di Markov . . . . . . . . . . . . . . . . . . . . . 24

2.2.2 Reti di Petri (PN) . . . . . . . . . . . . . . . . . . . . . 25

2.2.3 Reti di Petri Stocastiche (SPN) . . . . . . . . . . . . . . 27

2.2.4 Reti di Petri Stocastiche Generalizzate (GSPN) . . . . . 28

2.2.5 Reti di Petri Stocastiche e Deterministiche (DSPN) . . 28

2.2.6 Stochastic Activity Networks (SAN) . . . . . . . . . . . 29

2.3 Il tool Mobius . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4 Esperienze precedenti: Modello di una rete UMTS . . . . . . . 31

2.4.1 Topografia della rete . . . . . . . . . . . . . . . . . . . . 31

2.4.2 Assunzioni . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.3 Misure di interesse . . . . . . . . . . . . . . . . . . . . . 32

2.4.4 Modulo Cella . . . . . . . . . . . . . . . . . . . . . . . . 33

2.4.5 Modulo Utente Generico . . . . . . . . . . . . . . . . . . 33

2.4.6 Modulo Utente in Soft Handover (SHO) . . . . . . . . . 34

2.4.7 Modulo Interazione Cella / Utente . . . . . . . . . . . . 34

2.4.8 Modulo Interazione Cella / Utente SHO . . . . . . . . . 35

2.4.9 Composizione . . . . . . . . . . . . . . . . . . . . . . . . 36

2.5 Esperienze precedenti: Modello della procedura RACH . . . . . 37

2.5.1 Il modello della stazione base . . . . . . . . . . . . . . . 37

3 Il modello della rete UMTS 39

3.1 Assunzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2 Misure di interesse . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3 Place estesi e tipi di dato strutturati . . . . . . . . . . . . . . . 41

3.4 Parametrizzazione dei modelli . . . . . . . . . . . . . . . . . . . 42

3.4.1 Motivazione . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4.2 Moduli utente . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4.3 Moduli di interazione . . . . . . . . . . . . . . . . . . . 44

3.4.4 Inizializzazione . . . . . . . . . . . . . . . . . . . . . . . 45

3.5 Procedure di Handover e allocazione canali . . . . . . . . . . . 47

3.6 Guasti parziali e parametrizzazione del modulo cella . . . . . . 49

3.7 Mobilita degli utenti . . . . . . . . . . . . . . . . . . . . . . . . 50

3.7.1 Posizionamento utente . . . . . . . . . . . . . . . . . . . 51

3.7.2 Richiesta ed esecuzione del servizio . . . . . . . . . . . . 52

3.7.3 Gestione risorse del servizio . . . . . . . . . . . . . . . . 54

ii

3.7.4 Gestione risorse della cella . . . . . . . . . . . . . . . . . 553.8 Generalizzazione della mobilita . . . . . . . . . . . . . . . . . . 56

3.8.1 Modello scalabile per il movimento . . . . . . . . . . . . 573.8.2 Modello scalabile per la gestione del servizio . . . . . . . 583.8.3 Modello scalabile per la gestione delle risorse di una

stazione base . . . . . . . . . . . . . . . . . . . . . . . . 593.9 Il modello finale . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.9.1 Composizione . . . . . . . . . . . . . . . . . . . . . . . . 613.10 Variabili di Reward . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.10.1 Carico di una stazione base . . . . . . . . . . . . . . . . 633.10.2 Numero di canali dedicati . . . . . . . . . . . . . . . . . 643.10.3 Numero di canali in soft handover . . . . . . . . . . . . 643.10.4 Numero totale di utenti in soft handover . . . . . . . . . 643.10.5 Throughput . . . . . . . . . . . . . . . . . . . . . . . . . 653.10.6 Probabilita di fallimento . . . . . . . . . . . . . . . . . . 653.10.7 Probabilita di interruzione . . . . . . . . . . . . . . . . . 653.10.8 Livello di insoddisfazione dell’utente . . . . . . . . . . . 66

4 Valutazione numerica 67

4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.1.1 Parametri di esecuzione . . . . . . . . . . . . . . . . . . 67

4.2 Utenti statici . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.2.1 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2.2 Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.3 Guasti parziali . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.3.1 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.4 Utenti in movimento . . . . . . . . . . . . . . . . . . . . . . . . 784.4.1 Scenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 794.4.2 Scenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5 Conclusioni e sviluppi futuri 85

5.1 Possibili sviluppi . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Bibliografia 89

Elenco degli Acronimi 93

Appendici

iii

A Implementazione del modello 97

A.1 Modello BaseStation . . . . . . . . . . . . . . . . . . . . . . . . 97A.2 Modello User . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101A.3 Modello UserMovement . . . . . . . . . . . . . . . . . . . . . . 103A.4 Modello Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 106A.5 Modello ServiceManager . . . . . . . . . . . . . . . . . . . . . . 109A.6 Modello CellManager . . . . . . . . . . . . . . . . . . . . . . . . 114A.7 Modello Startup . . . . . . . . . . . . . . . . . . . . . . . . . . 126A.8 Composizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

iv

Prefazione

Negli ultimi anni lo sviluppo tecnologico e informatico ha subıto un’accelera-zione vertiginosa, rivoluzionando il nostro modo di pensare e, soprattutto, dicomunicare. Due delle piu importanti innovazioni introdotte a partire daglianni ‘90 e diventate recentemente di pubblico utilizzo riguardano infatti lacomunicazione: la rete internet e la telefonia mobile.

Questi sono solamente due esempi dei numerosi sistemi tecnologici checircondano la nostra vita quotidiana e su cui facciamo affidamento in piuoccasioni. Per sistemi di questo tipo deve essere garantito il funzionamento o,almeno, si deve garantire che non arrechino danno a coloro che li utilizzano.Inoltre, essendo sistemi utilizzati da un’elevato numero di utenti, deve essereassicurato un adeguato livello di prestazione. Conciliare queste necessita none facile, considerando anche l’elevato numero di sottosistemi che formano unapparato ad alta tecnologia come puo essere una rete di telefonia mobile.Per questo motivo risulta necessario analizzare in dettaglio la loro struttura,creando dei modelli che ne riproducano il comportamento.

In questo lavoro e stato analizzato e modellizzato il comportamento di unarete UMTS, lo standard europeo per la telefonia mobile di terza generazione,con particolare attenzione alla mobilita degli utenti e alla funzione di softhandover, che sono strettamente connesse tra di loro e rappresentano uno degliaspetti piu importanti della telefonia di terza generazione. Abbiamo utilizzatocome punto di partenza una precedente analisi della rete UMTS, effettuata in[5] utilizzando il formalismo delle SAN, con lo scopo di aggiornare il modello edestendere gli scenari rappresentabili, introducendo nuove caratteristiche. Nelfare cio si e cercato di riorganizzare il modello, rendendolo quanto piu possibilescalabile rispetto al numero di componenti della rete. Grazie anche ad alcuneinnovazioni nello strumento di modellazione e stato possibile adottare unastrategia di modellazione parametrica, in modo da ridurre la duplicazione di

v

codice e di concentrarsi solamente sulla struttura del modello e sul flussodi azioni, indipendentemente dai valori numerici. Dopo aver spiegato cosasi intende qui per modellazione parametrica e aver mostrato come la si eapplicata al modello iniziale, vengono introdotte le nuove caratteristiche delmodello. La prima riguarda le stazioni base e permette che esse funzionino inuno stato degradato, considerando quindi dei guasti parziali. La seconda, piuimportante, riguarda gli utenti e permette che essi si spostino all’interno delsistema, attraversando le aree di copertura di piu stazioni. Questa modifica harichiesto un’ulteriore riorganizzazione del modello, per separare maggiormenteil livello di servizio da quello fisico e per mantenere un approccio modulare.

Successivamente il modello cosı ottenuto e stato utilizzato per valutare leprestazioni di una rete UMTS. Cosı facendo, oltre a ricavare delle misuredi QoS per la rete di telefonia, si e verificato il corretto funzionamento delmodello, sia negli scenari che utilizzano le nuove funzioni di mobilita e guastiparziali, sia nelle situazioni analizzabili anche con il modello di partenza.

La tesi e strutturata in quattro capitoli, il Capitolo 1 presenta una panorami-ca sulla tecnologia UMTS e sulle reti 3G in generale, dettagliando gli aspettiche vengono riportati nel modello. Il Capitolo 2 fornisce una panoramica sullamodellazione, descrive alcuni metodi utilizzati per creare e valutare modellidi sistemi complessi e presenta infine quello che e stato il punto di partenza diquesto lavoro, riassumendo brevemente il contenuto di due precedenti analisidella rete UMTS, [5] e [15]. La creazione del nuovo modello SAN e descrit-ta ampiamente nel Capitolo 3, insieme alle strategie adottate durante la fasedi modellazione. L’esposizione segue l’ordine cronologico delle modifiche, ac-compagnando il lettore dal modello iniziale a quello finale, ottenuto tramiteuna serie estensioni e affinamenti. Nel Capitolo 4 infine sono presentate alcu-ne valutazioni che hanno permesso di misurare alcuni parametri di QoS peruna rete UMTS e di verificare allo stesso tempo il corretto funzionamento delmodello ottenuto.

Come aiuto nella riproduzione del modello SAN, nell’Appendice A e ripor-tata la documentazione prodotta da Mobius per i modelli atomici creati, conun breve commento per aiutare la comprensione. Inoltre nella terza di coper-tina e allegato un CD-ROM che contiene una versione funzionante del modelloe la riproduzione di questo documento in formato elettronico.

vi

Capitolo 1

La rete UMTS

La telefonia mobile e la rete internet hanno rivoluzionato il modo in cui avven-gono le nostre comunicazioni e stanno continuando a farlo con la loro continuacrescita e diffusione a livello mondiale. Con l’aumento della domanda da partedegli utenti e apparso chiaro come queste due tecnologie non siano altro chedue forme diverse di un nuovo modo di concepire la comunicazione. Da tem-po si sta quindi lavorando per creare un’infrastruttura capace di conciliare larichiesta di servizi multimediali con la dinamicita dell’utente tipica della tele-fonia mobile. Con questo scopo gia negli ultimi anni la seconda generazione ditelefonia mobile (2G) si e evoluta, introducendo sistemi come GPRS e EDGEsulle normali reti GSM. Anche se ufficialmente non esiste una tale classifica-zione, questi sistemi vengono collocati tra la seconda e la terza generazione ditelefonia mobile, tanto che vengono spesso utilizzate le sigle 2.5G e 2.75G.

1.1 UMTS e i sistemi radio 3G

Nel 2002 e stato introdotto in Giappone il primo sistema cellulare di terza ge-nerazione (3G) e successivamente anche in Europa e stato adottato un sistemadi questo tipo, che prende il nome di UMTS.

Questo standard nasce con l’ambizione di far convergere i vari tipi di mediasu un unico sistema wireless che abbia la possibilita di veicolarli in modomolto flessibile e adatto alle singole esigenze di ciascun utente. Sotto questoaspetto, la terza generazione offre trasmissioni dati molto veloci (fino a 2Mbit/s), con servizi multipli, diverse classi di servizio e la possibilita di trafficoasimmetrico. Vengono supportate connessioni sia a commutazione di circuito

1

2 Capitolo 1: La rete UMTS

che di pacchetto, e vengono inoltre incorporate le funzionalita dei sistemi 2Ggarantendo un’alta flessibilita nell’introduzione di nuovi servizi.

I terminali progettati per UMTS supportano attualmente anche collega-menti 2G, oltre naturalmente a quelli che sfruttano la nuova rete di telefoniamobile. Cio consente una copertura maggiore del servizio, specialmente nelleprime fasi di implementazione della rete, nelle quali non e da subito copertala totalita del territorio. Opportune procedure di handover inter-sistema con-sentono ad un utente di migrare da una rete all’altra senza grossi probleminella comunicazione [6].

1.1.1 QoS in UMTS

Le reti di telefonia mobile di terza generazione sono state concepite per utiliz-zare lo stesso mezzo trasmissivo per tutte le applicazioni, siano esse a commu-tazione di pacchetto o di circuito. Cio rende possibile ottimizzare i costi di ma-nutenzione, ottimizzare l’utilizzo di banda e fornire nuovi servizi multimediali,permettendone l’integrazione con quelli esistenti.

Un’importante caratteristica della rete UMTS e che l’informazione prove-niente da diverse sorgenti puo essere recapitata efficientemente utilizzando lostesso mezzo di trasmissione. Il traffico dati e generalmente frammentato neltempo e difficilmente prevedibile, con un alto utilizzo di banda, ma per untempo ridotto. Questo tipo di traffico e sensibile agli errori di trasmissione,mentre e influenzato in modo molto minore dal ritardo di trasmissione. Allostesso tempo, il traffico voce richiede vincoli forti sul ritardo di trasmissio-ne, tollerando maggiormente la perdita di pacchetti. Ad esempio il ritardoend-to-end per un collegamento voce accettabile deve essere inferiore a 400ms, anche utilizzando algoritmi di cancellazione dell’eco [4]. La difficolta con-siste quindi nel trasmettere diversi tipi di applicazione sullo stesso mezzo ditrasmissione, riuscendo a soddisfare i vincoli di qualita di ciascun servizio.

1.1.2 Classi di QoS

Per soddisfare queste esigenze, il gruppo 3GPP ha definito quattro diverseclassi di servizio: conversazionale, streaming, interattiva e background. Cia-scuna e caratterizzata da diversi requisiti di QoS e l’elemento che piu le di-stingue e la sensibilia al ritardo, massima nella classe conversazionale, minimanella classe background [1].

1.1 UMTS e i sistemi radio 3G 3

Le diverse classi di servizio vengono differenziate grazie ad una nuova im-portante caratteristica presente in UMTS e nelle altre reti 3G: la negoziazionedelle caratteristiche del canale di trasporto. La caratteristiche richieste dalterminale (o dalle applicazioni) possono riguardare ad esempio throughput, lalatenza del collegamento, il tasso di errore. Il gruppo 3GPP fornisce un elencodi tipici radio bearer utilizzabili nella rete UMTS in [2].

Le massime velocita di trasferimento dati offerte da una UMTS dipendonodalla tipologia di ambiente e variano da 144 Kbps, per un utente all’apertocon la velocita di movimento di un veicolo, 384 Kbps all’aperto per un utentein movimento a passo d’uomo e 2048 Kbps per un utente statico al chiuso oall’aperto a distanza ravvicinata.

Classe Conversazionale

Come suggerisce il nome, l’impiego piu comune per questa classe e il normaleservizio di telefonia. Con l’introduzione delle nuove capacita multimedialipero anche altre applicazioni richiederanno lo stesso schema, ad esempio peri servizi di videoconferenza e di VoIP. Nelle conversazioni real time il tempodi trasferimento deve essere ridotto e allo stesso tempo deve essere preservatala relazione temporale fra i vari elementi del flusso di dati. In particolare,il ritardo massimo accettabile e determinato dalla percezione umana. Tipiciutilizzi di classe conversazionale prevedono un throughput fino a 64 Kbps suentrambe le tratte.

Classe Streaming

Questa classe si applica alla ricezione di contenuti multimediali in tempo rea-le, come ad esempio la visualizzazione di un video o l’ascolto di un file audio.A differenza della classe conversazionale, la trasmissione e unidirezionale. Ilrequisito fondamentale di questa classe e la preservazione delle relazioni tem-porali fra gli elementi del flusso, mentre il ritardo di trasmissione in questo casonon e critico, a patto che la sua varianza sia ridotta. Per la classe streaming so-no utilizzati, a seconda delle necessita, collegamenti simmetrici o asimmetriciin una sola delle due tratte.


Classe Interattiva

Quando un utente richiede dati a un apparato remoto viene utilizzata questaclasse. In questo caso viene data particolare importanza all’integrita dei datie al ritardo round trip, visto che l’applicazione attendera la risposta per untempo prestabilito. Tipici utilizzi di questo schema comprendono la naviga-zione web, l’accesso a basi di dati, la raccolta di dati di misura e le applicazioniclient/server in generale.

Classe Background

Questo schema si applica alla ricezione e invio di dati in background, in secon-do piano quindi rispetto ad altri processi piu importanti e in generale senzal’interazione da parte dell’utente. Alcuni esempi sono l’invio e la ricezione inbackground di e-mail, SMS, aggiornamenti software. La caratteristica princi-pale di questa classe e che il trasferimento non deve essere completato entroprecisi vincoli di tempo, percio il requisito principale riguarda l’integrita deidati trasmessi.

1.2 Tecniche di accesso radio

Tenendo presente che lo spettro radio e una risorsa limitata, appare neces-sario suddividere la banda a disposizione tra il maggior numero possibiledi utenti. Prima di analizzare in dettaglio la soluzione adottata nel siste-ma UMTS vengono descritte brevemente le modalita di accesso utilizzate neisistemi precedenti.

1.2.1 Accesso a divisione di frequenza (FDMA)

Questa tecnica consiste nella suddivisione della banda di frequenza disponibilein un numero di sottobande che occupino una banda piu piccola. Ognuno diquesti canali viene assegnato ad un utente, che lo utilizzera per tutta la duratadella connessione. In ricezione un’opportuna sequenza di filtri potra seleziona-re il segnale da cui si vuole estrarre l’informazione. La singola portante radiopotra essere riutilizzata solo una volta rilasciata dall’utente. Questa tecnicaveniva utilizzata nei sistemi radiomobili analogici di prima generazione.

1.2 Tecniche di accesso radio 5

1.2.2 Accesso a divisione di tempo (TDMA)

Un altro metodo per dividere la banda a disposizione in sottocanali e divide-re la durata di un intervallo di tempo Tf in un certo numero N di intervallidisgiunti (timeslot), ognuno della durata Tf/N [8]. In questo modo la stessaportante puo essere condivisa fra piu utenti, sebbene in istanti diversi. TDMAviene normalmente utilizzato in congiunzione con FDMA: ogni canale basatosu FDMA viene ulteriormente suddiviso utilizzando TDMA, facendo in modoche piu utenti possano trasmettere sullo stesso canale. Inoltre per la ricezio-ne e la trasmissione vengono utilizzati time slot diversi, cosı che il terminalenon trasmetta e riceva contemporaneamente, semplificando notevolmente l’e-lettronica. Questa tecnica viene utilizzata nella maggior parte dei sistemiradiomobili digitali di seconda generazione, come quelli basati sullo standardGSM.

1.2.3 Accesso a divisione di codice (CDMA)

Sia in FDMA che in TDMA la banda a disposizione e partizionata in singolicanali utente indipendenti tra di loro. Questo puo creare problemi se l’utilizzodella rete da parte degli utenti e intermittente, come spesso accade. Infattiun singolo utente che ha ottenuto un canale dedicato puo trasmettere cosıirregolarmente che i tempi di inattivita sono persino piu lunghi dei tempi diutilizzo effettivo della rete. Per esempio un dialogo puo contenere molte pauseoppure durante una navigazione web ci possono essere tempi di inattivita trala lettura di una pagina e l’altra. In questi casi FDMA e TDMA tendono adessere inefficienti perche una porzione della frequenza (o del timeslot) allocataall’utente non trasporta nessuna informazione.

Un sistema ad accesso multiplo inefficiente limita il numero di utenti chepossono essere serviti simultaneamente: un modo di risolvere questo problemae permettere agli utenti di trasmettere nello stesso istante sullo stesso canale,come avviene in CDMA. Ovviamente occorre un metodo per realizzare ladivisione tra gli utenti: in base a questo si distinguono diverse varianti, di cuiFH-CDMA e DS-CDMA sono le piu utilizzate.

La tecnica CDMA, adottata nelle reti di telefonia di terza generazione ein altri recenti sistemi di comunicazione radio, utilizza una serie di codici di-gitali per la separazione dei vari utenti. A ciascun utente viene assegnato unproprio codice, che sara utilizzato per codificarne il segnale, e solamente quel


ricevitore che conosce il codice utilizzato durante la trasmissione sara in gradodi decodificarlo. Per tutti gli altri utenti che non sono in possesso del codicecorretto il segnale trasmesso appare come rumore di fondo. Perche sia possi-bile decodificare il segnale e necessario pero mantenere il rumore generato datutti gli utenti sotto una certa soglia, che determina la capacita massima dellarete. Come analogia viene spesso portato l’esempio di un ricevimento a cuipartecipano persone di diversa nazionalita: ognuno parlera la propria linguae, ascoltando il brusio della sala, sara in grado di comprendere solamente idialoghi nella lingua che conosce, mentre gli altri non saranno altro che ru-more di fondo. Quando pero il rumore diventa eccessivo anche questi dialoghidiventano difficilmente comprensibili.

Contrariamente alle tecniche di accesso precedenti, CDMA offre un fatto-re di riuso uguale a 1, almeno teoricamente. Questo significa che la stessafrequenza puo essere utilizzata su tutte le celle, mentre nel passato veniva-no creati cluster di celle, ognuna delle quali utilizzava portanti con diversefrequenze. Questo schema veniva ripetuto poi per coprire aree piu vaste.

Grazie alla particolare tecnica di accesso non sarebbe necessario quindisuddividere la banda a disposizione in piu portanti, tuttavia per limitare l’usodi differenti codici, normalmente si opera una suddivisione in n sottobande cheserviranno un certo numero di utenti. Comunemente la copertura di un’areaavviene con la stessa sottobanda per tutte le celle e solo nel caso si debbaservire un eccessivo numero di utenti viene utilizzata un’ulteriore sottobanda.

W-CDMA

La modalita di accesso utilizzata attualmente nello standard UMTS vieneidentificata con la sigla W-CDMA, Wideband CDMA, per sottolineare lamaggiore ampiezza di banda rispetto ai sistemi precedenti. Essa utilizza unamodalita di comunicazione duplex di tipo FDD, dove vengono utilizzati duecanali separati per downlink e uplink. Successivamente parlando di UMTS ciriferiremo principalmente a questa tecnica di accesso, essendo quella adottatanei sistemi attuali.

TD-CDMA

W-CDMA non e comunque l’unica modalia standardizzata per UMTS e lespecifiche internazionali prevedono anche la possibilita di utilizzare una mo-


dalita duplex di tipo TDD, dove la divisione tra downlink e uplink e realizzatautilizzando uno schema a divisione di tempo sulla trama del CDMA.

1.2.4 Spreading e despreading

I sistemi CDMA sono detti anche a diffusione di spettro, perche per trasmette-re l’informazione viene utilizzata piu banda di quella che sarebbe normalmentenecessaria: in questo modo la densita spettrale del segnale e molto bassa el’interferenza generata e ridotta [20]. Infatti l’energia di ogni singolo bit (Eb)rimane costante, mentre aumenta il numero di chip su cui viene distribuita,con il risultato di avere meno potenza per unita di banda (Ec).

In W-CDMA la diffusione dell’informazione sullo spettro (spreading) vienerealizzata moltiplicando il segnale desiderato per una sequenza pseudo-casuale,determinata da un codice di canalizzazione, che individua il canale, e da un co-dice di scrambling, che identifica l’utente a cui e diretto. Perche il meccanismofunzioni correttamente e la trasmissione di ciascun utente sia isolabile dallealtre, e necessario che la funzione di correlazione tra i corrispondenti segnalisia nulla. Segnali con queste proprieta si dicono ortogonali, cosı come i codicicapaci di generarli. L’ortogonalita di due codici binari puo essere verificatacontrollando se, moltiplicati tra di loro, danno origine a una stringa che ha lastessa quantita di cifre 0 e 1. I codici utilizzati in W-CDMA (OVSF Codes)sono in realta pseudo-ortogonali, dato che la perfetta ortogonalita puo venirmeno nel caso vi siano dei ritardi nella ricezione di segnali multipli.

Quando viene codificata una sequenza di bit, ogni bit di informazione erappresentato da un certo numero di simboli che verranno effettivamente tra-smessi, chiamati chip. Il numero di chip utilizzato per bit e detto spreadingfactor. I bit di informazione sono moltiplicati con il codice, ciascun bit con lastessa sequenza di chip. In ricezione i segnali ricevuti sono moltiplicati nuova-mente con il codice utente. Come si puo vedere nella Figura 1.1, moltiplicareil segnale ricevuto con il proprio codice risulta in un aumento della potenzadel segnale di informazione, mentre i segnali di interferenza risultano segnalicon potenza ulteriormente ridotta. Questo effetto e conosciuto con il nomedi processing gain, viene generalmente misurato in decibel ed e definito comesegue:

PG|dB= 10 · log10

(chiprate

bitrate

)= 10 · log10 (SF ), (1.1)

dove SF rappresenta lo spreading factor.


Figura 1.1: Spreading e Despreading. Solamente il codice ortogonale utilizzato nellafase di codifica permette di ricavare correttamente le informazioni

Il processing gain e la caratteristica che garantisce ai sistemi W-CDMA larobustezza nei confronti dei segnali interferenti, rendendo possibile la trasmis-sione simultanea di piu utenti sullo stesso canale. Con un esempio possiamocapire meglio come questo sia possibile.

Nel sistema W-CDMA la qualita di un collegamento e misurata tramite ilrapporto tra l’energia per bit d’utente (Eb) e la densita spettrale dell’interfe-renza (N0), che include sia il rumore termico e ambientale che le interferenzegenerate dagli altri utenti. Questo rapporto infatti e in stretta relazione conil tasso di errore dei dati trasmessi. Tramite la seguente relazione e possibilericavare il minimo valore del rapporto C/I (Carrier to Interference, misuratoin decibel) che deve essere assicurato al collegamento.

C/I |dB= Eb/N0|dB

− PG|dB(1.2)

Supponiamo ad esempio di richiedere un rapporto Eb/N0 pari a 5 dB per unservizio voce con bitrate pari a 12,2 Kbit/s. Tramite la 1.1 si puo calcolare ilPG, che in questo caso e 25 dB, per poi ricavare il C/I richiesto che risultaessere –20 dB. Questo significa che la potenza del segnale utile potra essere


inferiore di 20 dB rispetto all’interferenza e il ricevitore sara ancora in gradodi decodificare il segnale rispettando i parametri di QoS richiesti.

1.2.5 Capacita dei sistemi W-CDMA

Nei sistemi di prima e di seconda generazione la capacita massima poteva esse-re determinata a priori, e dipendeva dalla quantita di risorse fisiche allocabili(numero di canali o numero di timeslot). Nei sistemi a divisione di codice inve-ce non esiste un numero prestabilito di utenti servibili, ma ogni volta che vieneaccettato un nuovo collegamento la qualita di tutte le connessioni presenti nelsistema e degradata leggermente.

Nuovi utenti possono quindi essere serviti fino a che l’interferenza generatae tale da poter garantire ad ogni collegamento la qualita richiesta, in terminidi rapporto segnale/rumore. Risulta quindi determinante la scelta del coeffi-ciente Eb/N0, che dipende da piu fattori come: la velocita di movimento delterminale, la velocita di trasmissione, l’ambiente di propagazione, il tipo diservizio richiesto, l’utilizzo o meno di soft handover.

Perche la capacita di una cella W-CDMA sia sfruttata al massimo e fonda-mentale il controllo di potenza. L’uso di una potenza di trasmissione eccessivada parte dei terminali ha l’effetto di ridurre il vantaggio dovuto al process gaine quindi di saturare rapidamente le capacita della cella. Un esempio pratico,noto come effetto near-far, si verifica quando un terminale si trova molto vici-no ad una stazione base: se trasmettesse alla massima potenza sovrasterebbei segnali degli altri utenti, che giungono affievoliti a causa della maggiore di-stanza dalla stazione. Questo problema e in particolare critico sulla trattauplink, mentre in downlink la cella trasmette con lo stesso livello di potenzaa tutti gli utenti.

Vediamo adesso come e possibile valutare il carico apportato alla stazionebase dagli utenti connessi ad essa, facendo in particolare riferimento a [7][18]. Irisultati seguenti sono validi se assumiamo che, grazie al controllo di potenza,ogni trasmissione avvenga alla minima potenza necessaria per mantenere ilrapporto Eb/N0 richiesto.

Capacita in uplink

Per calcolare il carico generato da un utente su di una cella W-CDMA enecessario tenere conto del rapporto Eb/N0 richiesto dal servizio utilizzato.


Servizi diversi contribuiranno infatti diversamente alla saturazione della cella.In generale per ogni utente j vale la seguente relazione:(Eb/N0

)j

= PGj ·potenza segnale utentej

potenza totale ricevuta (a meno del segnale utile),

che puo essere riscritta quindi come:(Eb/N0

)j

=W

υjRj· Pj

Ptotal − Pj, (1.3)

dove W e il chip rate, Rj e la velocita di trasmissione del servizio richiesto, υj

il coefficiente di attivita dell’utente, Pj e la potenza ricevuta del segnale prove-niente dall’utente j e Ptotal la potenza totale a banda larga ricevuta, che com-prende anche il rumore termico nella stazione base. Riscrivendo nuovamentela (1.3) otteniamo:

Pj =(

(Eb/N0)j · υjRj

W

)(Ptotal − Pj),

da cui:

Pj

(W

(Eb/N0)j · υjRj

)+ Pj = Ptotal.

Possiamo adesso definire il fattore di carico in uplink come rapporto tra lapotenza del segnale utente e la potenza totale ricevuta:

Lj =Pj

Ptotal=

1

1 +W(

Eb/N0

)j· υjRj

. (1.4)

Il fattore di carico della cella in uplink e dato dalla somma dei fattori di caricodei singoli utenti:

ηUL =N∑

j=1

Lj . (1.5)

Il noise rise e definito come il rapporto tra la potenza totale ricevuta e lapotenza del rumore termico nella stazione base.

NRUL =Ptotal

PN=

Ptotal

Ptotal −∑N

j=1 Pj

=1

1− ηUL

. (1.6)

Il concetto di noise rise si basa sul fatto che quando il fattore di carico ηUL

si avvicina a 1, il corrispondente incremento di rumore tende a infinito e ilsistema ha raggiunto la sua capacita limite (pole capacity).


Infine deve essere tenuta in considerazione anche l’interferenza provenienteda altre celle, considerando nel calcolo del fattore di carico una variabile i, cherappresenta il rapporto tra l’interferenza intercella e l’interferenza intracella.Quindi il fattore di carico in uplink puo essere riscritto come:

ηUL = (1 + i)N∑

j=1

1

1 +W(

Eb/N0

)j· υjRj

. (1.7)

Capacita in downlink

Il fattore di carico in downlink, ηDL puo essere definito in base agli stessi prin-cipi utilizzati per quello uplink [17][7], anche se i parametri sono leggermentedifferenti:

ηDL =N∑

j=1

(Eb/N0

)j· υjRj

W·[(

1− αj

)+ ij

]. (1.8)

Confrontata con l’equazione (1.7) del carico uplink, si nota il nuovo parame-tro αj , che rappresenta il fattore di ortogonalita sulla tratta downlink. IlW-CDMA infatti utilizza codici ortogonali per separare gli utenti, ma la per-fetta ortogonalita e mantenuta solamente quando il segnale viene ricevutosenza propagazione multipath. Nella ricezione di cammini multipli invece siverificano dei piccoli ritardi che fanno sı che il terminale veda parte del segnaledella stazione base come interferenza. Un’ortogonalia di 1 corrisponde a uten-ti perfettamente ortogonali. Inoltre notiamo che il parametro i e indicizzatorispetto all’utente, infatti in downlink il rapporto tra interferenza intercella eintracella e diversa per ogni utente, in funzione della sua posizione.

1.2.6 Copertura dei sistemi W-CDMA

La copertura di una cella W-CDMA e principalmente limitata in uplink, acausa della ridotta potenza di trasmissione dei terminali mobili rispetto allastazione base. Questo significa che generalmente un utente perdera la connes-sione ad una cella perche essa non riceve piu correttamente il segnale utente, enon viceversa. Inoltre in un sistema UMTS il carico della cella e la coperturasono strettamente legati tra loro.

Come esempio immaginiamo che vi siano molti utenti raggruppati nellazona centrale di una cella. La loro richiesta di servizi portera ad un incre-mento del rumore, costringendo gli utenti che si trovano sul bordo della cella


Servizio trasmissione dati in real time a 144 Kbit/s

Trasmettitore (mobile)Massima potenza di trasmissione [dBm] 24.0 aGuadagno di antenna [dBi] 2.0 bAttenuazione corpo umano [dB] 0.0 cEIRP [dBm] 26.0 d = a + b− c

Ricevitore (stazione base)Densita di rumore termico [dBm/Hz] –174.0 eCifra di rumore ricevitore [dBm] 5.0 fDensita di rumore ricevitore [dB] –169.0 g = e + fPotenza di rumore ricevitore [dBm] –103.2 h = g + 10 log10(3840000)Noise rise [dB] 3.0 i

Potenza di interferenza [dB] –103.2 j = 10 log10(10(h+i)/10 − 10h/10)

Rumore effettivo [dBm] –100.2 k = 10 log10(10h/10 + 10j/10)

Process gain [dB] 14.3 l = 10 log10(3840/144)Eb/N0 richiesto [dB] 1.5 mSensibilita ricevitore [dBm] –113.0 n = m− l + k

Guadagno di antenna stazione base [dBi] 18.0 oAttenuazione cavi nella stazione base [dB] 2.0 pMargine di fast fading [dB] 4.0 qAttenuazione di propagazione massima [dB] 151.0 r = d− n + o− p− q

Margine di fading log-normale [dB] 4.2 sGuadagno di soft-handover [dB] 2.0 tAttenuazione indoor [dB] 15.0 u

Attenuazione di propagazione [dB] 133.8 v = r − s + t− u

Tabella 1.1: Bilancio di tratta di riferimento per il servizio di trasmissione dai real timea 144 Kbit/s (3 Km/h, utente indoor, coperto da stazione base esterna,con soft handover)

ad aumentare la potenza di trasmissione. Se il rumore continua ad aumen-tare questi raggiungeranno presto la loro massima potenza di trasmissione,e i loro segnali verranno sovrastati dagli utenti piu vicini alla stazione base.Questi utenti non saranno quindi piu in grado di raggiungere la stazione basee saranno di fatto fuori dal raggio della cella [20].

In fase di pianificazione la copertura prevista viene determinata attraversoil bilancio di tratta [13][7], che prende in considerazione tutti i parametririlevanti come: tipo di servizio richiesto, interferenza presente sulla rete (noiserise), ambiente di propagazione, guadagno derivato dall’handover, velocitadi spostamento dell’utente, caratteristiche fisiche della stazione base e deiterminali mobili.

Il risultato del bilancio di tratta puo essere utilizzato con un opportu-no modello di propagazione per calcolare il raggio della cella nelle condizioniprestabilite. Il modello di propagazione descrive la propagazione media del se-gnale in quell’ambiente e permette di convertire l’attenuazione di propagazionemassima consentita nel raggio massimo della cella in chilometri. Prendiamo adesempio il modello di propagazione Okumura-Hata per una macrocella urbana,

1.3 Architettura di rete 13

considerando un’altezza dell’antenna della stazione base di 30 m, un’altezzadell’antenna del mobile di 1.5 m e una frequenza della portante di 1950 MHz.In tali condizioni si ha che:

L = 137.4 + 35.2 log10 R, (1.9)

dove L e l’attenuazione di propagazione in decibel e R il raggio della cellain chilometri. Applicando questo modello al bilancio di tratta riportato nellaTabella 1.1 otteniamo un raggio della cella pari a 1.7 km.

Come si vede anche dall’esempio riportato, il raggio massimo di una cellae influenzato da diversi fattori, due dei piu importanti sono il rapporto se-gnale/rumore e il processing gain. Entrambi sono influenzati dalla velocitadi trasmissione del servizio richiesto, infatti per elevate velocita di trasmissio-ne il valore Eb/N0 tende ad essere minore. Allo stesso tempo pero anche ilguadagno di processo dovuto all’operazione di spreading viene ridotto, dimi-nuendo l’energia per bit utente (Eb) ottenuta dopo la decodifica del segnale.La riduzione del rapporto Eb/N0 comunque compensa solo in parte la ridu-zione del processing gain e in generale a un servizio con un bitrate piu elevatocorrisponde una minore copertura.

1.3 Architettura di rete

Un sistema UMTS e caratterizzato dall’esistenza di due sottoinsiemi di rete iquali, oltre al trasporto dei servizi all’utente, svolgono le funzioni di controlloe gestione del traffico. La parte di rete deputata a svolgere tutte le funzionidi autenticazione, commutazione, tariffazione e interconnessione verso le altrereti mobili e fisse viene denominata Core Network (CN), mentre la parte direte che e deputata al collegamento dell’utente mobile e alla gestione dellerisorse radio prende il nome di UMTS Radio Access Network (UTRAN).

1.3.1 La rete di accesso UTRAN

La rete di accesso, schematizzata nella Figura 1.2, e costituita da un gruppodi sottosistemi di rete radio (RNS), che a loro volta sono costituiti da un con-trollore di rete (RNC) e da un gruppo di stazioni basi ricetrasmittenti, che inambito UMTS prendono il nome di Node-B. Ciascun Node-B gestisce un certonumero di celle, in media da 3 a 6, supportando trasmissioni in modalita FDD,TDD o entrambe [19]. Il collegamento con il terminale utente (UE) avviene


Figura 1.2: La rete di accesso UTRAN

per mezzo dell’interfaccia in aria, detta Uu, che ha il compito di trasportare,oltre ai sevizi utente, anche tutte le informazioni che servono per la gestionedella mobilita, delle risorse radio e dei controlli di rete. Il sottosistema diaccesso radio (RNS) si collega alla Core Network tramite l’interfaccia Iu epoiche le reti UMTS possono supportare servizi a commutazione di circuito edi pacchetto contemporaneamente, ciascuna interfaccia Iu viene specializza-ta per il tipo di servizio che trasporta. Iu-CS indica una connessione versoreti a commutazione di circuito, mentre Iu-PS verso reti a commutazione dipacchetto. All’interno di ciascun RNS, il collegamento con la Core Network,e realizzato attraverso il RNC, che rappresenta il confine tra il mondo radioe il resto della rete. Per quanto riguarda le connessioni tra i componenti in-terni alla UTRAN, ciascun RNC e collegato attraverso l’interfaccia Iub con iNode-B che esso controlla, mentre i vari RNC sono collegati tra di loro tramitel’interfaccia Iur.

L’elemento centrale della rete di accesso e quindi l’RNC, il quale gesti-sce tutte le funzionalita dell’interfaccia radio lato utente, e rende possibile iltrasporto dei servizi in modo trasparente verso la CN. In questo modo lamobilita dell’utente e controllata completamente dall’UTRAN. Utilizzandoquesta struttura di rete, la CN viene ad essere completamente separata nellefunzioni di trasporto dei servizi, mentre le funzioni di controllo e segnalazione

1.3 Architettura di rete 15

terminano nell’RNC stesso, che provvedera a convertirle nei formati di pro-tocollo radio necessari all’utente. Ai Node-B viene demandato il compito direalizzare le trasmissioni radio (modulazione, ricetrasmissione, alcuni controllidi potenza); in pratica il Node-B riceve dall’RNC le risorse che deve destinareai singoli utenti, ed esso dovra solamente trasmettere via radio quanto ricevu-to, aggiustandone pero i livelli di potenza. Un RNC puo lavorare in modalitaserving (SRNC) cosı come in modalita drift (DRNC). Nel primo caso esso con-trolla e gestisce le risorse dell’utente e la connessione verso la Core Network,mentre nel secondo caso non fa altro che reinstradare i segnali provenientidai propri Node-B verso il serving, avvalendosi del collegamento reso possibiledall’interfaccia Iur.

1.3.2 Macrodiversita

In una rete UMTS tutte le celle, appartenenti alla stessa gerarchia, operanosulla stessa portante. Questo fa sı che il segnale trasmesso da una stazionebase possa essere ricevuto da chiunque conosca i codici di spreading utiliz-zati e si trovi all’interno dell’area geografica dove i segnali sono ricevuti conuna adeguata potenza. Quindi, utilizzando la macrodiversita, il mobile nonsi limita a rimanere collegato ad una sola base station, ma coinvolge nel col-legamento tutte le BS da cui riceve un segnale di riferimento sufficientementeforte. Viene cosı definito il concetto di Active Set (AS) come l’insieme delle BSda cui il mobile riceve la stessa informazione utile. Occorre precisare che in unsistema CDMA, l’obiettivo principale e minimizzare la potenza trasmessa daimobili, per questo ogni utente viene attestato alla BS che permette di utiliz-zare la minore potenza (best choice). Non necessariamente le BS selezionatesono quelle il cui segnale e ricevuto con maggiore potenza, ossia le best servernella tecnologia GSM.

Quando un terminale opera in macrodiversita puo migliorare il segnale indownlink combinando trama per trama i segnali provenienti da celle appar-tenenti a Node-B e RNC diversi, limitando gli errori di trasmissione. Sullatratta uplink, il segnale trasmesso viene decodificato da tutte le BS appar-tenenti all’AS e il segnale viene ricombinato all’interno del Node-B, oppureall’interno del Serving RNC nel caso in cui le BS coinvolte appartengano aNode-B differenti. La ricostruzione dell’informazione nel terminale mobile eresa possibile grazie all’utilizzo dei ricevitori rake, che riescono a combinaresegnali con la stessa informazione provenienti da sorgenti differenti, conside-


randoli come differenti percorsi della stessa sorgente per effetto di camminimultipli. Di fatto per questi ricevitori non c’e differenza tra segnali prove-nienti da diverse BS e cammini multipli dello stesso segnale, ma si limitanoa ricombinare tutti i segnali ricevuti per ottenere il miglior livello qualitativopossibile.

L’utilizzo di questa funzionalita rende il sistema piu robusto contro lo sha-dowing, ossia l’attenuazione del segnale radio dovuta alla presenza di ostacolitra il mobile e la BS. Infatti se il mobile e collegato contemporaneamentea piu BS, sara molto meno probabile che si trovi ad avere degli ostacoli sututte le tratte possibili. Inoltre, avere a disposizione piu segnali provenienti dafonti diverse fornisce un elemento di ridondanza che diminuisce la probabilitadi avere errori di trasmissione. Tutto questo si traduce in una riduzione dellivello Eb/N0 richiesto dal servizio.

1.4 Procedure di Handover

Il concetto di handover (a volte detto anche handoff ) e fondamentale nelle retidi telefonia mobile, in particolare in quelle di terza generazione. Il concettobase e quello di permettere all’utente di muoversi attraverso la rete in modotrasparente, senza che si presentino interruzioni di servizio nel passaggio dauna cella all’altra. Per un terminale utente che sta effettuando una chiamatae sta varcando il confine di una cella e piu conveniente utilizzare le risorsedella nuova cella, piuttosto della vecchia da cui si sta allontanando. Di fat-to, muovendosi verso una nuova cella, il segnale della prima stazione base siattenuera fino a scomparire, mentre la seconda stazione sara ricevuta sem-pre piu facilmente. Inoltre allontanandosi da una stazione base il terminaledeve aumentare la potenza di trasmissione per essere ricevuto correttamente,aumentando cosı l’interferenza nel sistema.

Nelle reti di seconda generazione in molti casi la connessione esistente deveessere chiusa prima di poterne aprire una nuova, e questo puo causare l’inter-ruzione del servizio in corso. In un sistema W-CDMA invece, possono essereeseguite procedure di handover in modo completamente asincrono, sfruttandola macrodiversita. Viene infatti introdotto il concetto di Active Set (AS), chesemplificando, e l’insieme di stazioni base da cui l’utente riceve un segnalesufficientemente buono. Un terminale mobile puo mantenere la connessionecon tutte le stazioni base presenti nel suo active set, in questo modo la stessa

1.4 Procedure di Handover 17

informazione utente e trasportata attraverso tutti i canali che sono attivi conle diverse BS. Nella fase del cambio di cella la continuita e quindi garantitadalla molteplicita dei cammini, realizzata tra il mobile e il punto di control-lo della rete. In base ai componenti coinvolti, si distinguono diversi tipi diprocedure di handover [20].

1.4.1 Hard Handover

In questo tipo di procedure la connessione in corso viene interrotta prima diottenerne una nuova. Questo modalita e tipica dei sistemi TDMA come GSM,dove a ogni connessione viene assegnata una frequenza diversa. In UMTS in-vece questo tipo di handover e secondario e viene utilizzato solamente quandonon e possibile fare altrimenti (ad esempio nel passaggio da una frequenzaall’altra, nel caso l’operatore disponga di piu frequenze) o quando la rete nonsupporta la macrodiversita. Altri esempi di applicazione sono il passaggio frale diverse modalita di duplex (FDD e TDD).

1.4.2 Inter-System Handover

Questo tipo di handover coinvolge piu sistemi eterogenei ed avviene quando unterminale ha la necessita di trasferirsi da uno all’altro, cambiando la propriamodalita di funzionamento. L’handover inter sistema e prima di tutto neces-sario per supportare la compatibilita con le reti gia esistenti, come avviene inEuropa tra UMTS e GSM. Questo tipo di handover e ovviamente possibilesolo per i servizi che sono supportati dalla rete destinataria e solamente se ilterminale mobile e progettato per essere multistandard. Inoltre questo tipo dihandover e necessario nel caso vi siano zone non coperte sufficientemente dallarete di tipo 3G, ad esempio le zone agricole, specialmente nella fase inizialedi introduzione della nuova telefonia. Ovviamente l’utente risentira dei limitidella rete di destinazione, come una minore velocita di trasferimento per leconnessioni dati. L’handover inter-sistema puo essere considerato come uncaso particolare di hard handover, perche in generale richiede l’interruzionedella connessione esistente.

1.4.3 Soft e Softer Handover

Entrambe queste modalita sono tipiche del W-CDMA e permettono un han-dover “dolce” nel passaggio da una stazione radio all’altra.


Durante il softer handover, una stazione radio mobile si trova nella zonadi intersezione e sovrapposizione delle coperture di due celle, relative a duesettori di una stessa stazione radio base. La comunicazione tra il terminalemobile e la stazione radio base avviene utilizzando contemporaneamente duecanali di interfaccia radio, uno per ogni settore, con il conseguente utilizzo didue distinti codici nella direzione downlink, in modo che il terminale possadistinguere i due segnali. Nella tratta di uplink il segnale codificato relativoe ricevuto in entrambi i settori ed e instradato tramite un ricevitore rake. Latrasmissione in softer handover interessa tipicamente il 5-15% delle connessioniattive.

Nel soft handover invece, la connessione interessa piu celle appartenen-ti a due diverse stazioni radio base. Come nel caso del softer handover, lacomunicazione tra il terminale mobile e la stazione radio base avviene uti-lizzando contemporaneamente piu canali di interfaccia radio, uno per ognisettore delle diverse stazioni radio coinvolte. Dal punto di vista del terminalele differenza tra soft e softer handover sono minime. Nella tratta uplink inve-ce il soft handover e significativamente diverso dal softer handover. I segnalicodificati relativi al terminale mobile sono ricevuti indipendentemente dalledue stazioni radio base e i dati sono quindi instradati verso l’RNC per essereopportunamente combinati. Il soft handover riguarda tipicamente il 20-40%delle comunicazioni.

L’algoritmo per l’esecuzione di soft e softer handover si basa sulla potenzadel canale pilota ricevuto dalle diverse stazioni base e puo essere schematizzatocome segue, indicando con Pn il livello del segnale pilota della cella n, Pmax

e Pmin rispettivamente il migliore e il peggiore segnale pilota ricevuto tra lecelle presenti nell’active set e Ssho una soglia prefissata per l’aggiunta di unacella all’active set [7].

� Radio Link Addition

Se per un intervallo di tempo ∆T risulta Pn > Pmax − Ssho, la cella n

viene aggiunta all’active set, se questo non ha raggiunto la dimensionemassima.

� Radio Link Removal

Se per un intervallo di tempo ∆T risulta Pn < Pmax − Ssho, la cella n

viene rimossa dal’active set.

� Combined Radio Link Addition and Removal

1.5 Gestione delle risorse radio 19

Se l’active set e completo e per un certo intervallo di tempo ∆T risultaPn > Pmin, allora la cella piu debole dell’active set viene sostituita dallacella n.

1.5 Gestione delle risorse radio

1.5.1 Procedura di accesso casuale (RACH Procedure)

La procedura di accesso casuale (Random Access Procedure) e utilizzata dalterminale utente per il primo accesso alla rete, ad esempio per registrarsi do-po l’accensione, per informare la rete che si e spostato in una nuova areao per avviare una trasmissione utente. Per i messaggi relativi alla proce-dura di accesso, la rete mette a disposizione degli utenti un canale comunein uplink, detto canale RACH, che viene mappato sul canale fisico PRACH.Questo canale e suddiviso in 15 access slot che possono essere utilizzati perinviare il preambolo RACH. In ogni cella possono essere configurati diversicanali RACH/PRACH, in questo caso il terminale mobile ne seleziona unocasualmente.

Poiche la rete non puo sapere quando un’utente richiedera una connessionecon il Node-B, le risorse del canale PRACH non sono condivise tra gli utentiutilizzando rigidi meccanismi a divisione di tempo o di codice, ma durantela procedura vengono utilizzati una serie di algoritmi di randomizzazione chepermettono agli utenti di accedere alla risorsa condivisa [12][8].

Tramite la procedura di accesso casuale inoltre e possibile definire dellepriorita tra i vari servizi offerti dalla rete, assegnando un diverso numero diaccess slot ai vari servizi. Uno studio piu approfondito della procedura diaccesso casuale e del suo impatto sulle performance di una cella UMTS epresentato in [15].

1.5.2 Procedura di Admission Control

In un sistema basato su W-CDMA, se si consente che il carico sull’interfacciaradio cresca in modo eccessivo, l’area di copertura della cella si riduce al disotto dei valori previsti e la qualita del servizio per le connessioni esistentinon puo essere garantita. Prima di consentire una nuova chiamata, quindi,l’admission control verifica che tale accettazione non comporti una diminuzio-ne dell’area di copertura pianificata e della qualita di servizio delle connessioni


esistenti. L’admission control accetta o rifiuta la richiesta di nuove risorse daparte dell’utente. Il controllo viene eseguito quando un nuovo radio bearer einstaurato o modificato; esso stima l’effetto che la nuova connessione avrebbesulla rete, separatamente per le tratte uplink e downlink, e se il risultato eaccettabile per entrambe il radio bearer viene ammesso, in caso contrario essoviene rifiutato a causa dell’eccessiva interferenza che lo stesso produrrebbe. Ilimiti dell’admission control sono stabiliti in fase di pianificazione della rete.

La procedura di admission control puo essere implementata in piu modi,in base al tipo di controllo che viene effettuato. Un semplice algoritmo basatosul throughput accetta il nuovo collegamento se il carico stimato dopo la suacreazione e inferiore a un limite prefissato:

ηUL + ∆LUL ≤ ηmaxUL

, ηDL + ∆LDL ≤ ηmaxDL

, (1.10)

dove ∆LUL e ∆LDL sono i fattori di carico, uplink e downlink rispettivamente,calcolati tramite le equazioni (1.7) e (1.8). Una strategia alternativa, ma leg-germente piu complicata, e quella basata direttamente sulla potenza a bandalarga ricevuta, che accetta un nuovo collegamento solamente nel caso in cuiil nuovo livello di interferenza risulti inferiore al valore di soglia. Differentistrategie possono essere scelte per le due tratte, downlink e uplink [7][8].

1.5.3 Controllo del carico (Congestion Control)

Un compito importante della funzione di gestione delle risorse radio e garan-tire che il sistema non sia sovraccaricato e rimanga stabile. Se il sistema eprogettato in modo adeguato e l’admission control lavora sufficientemente be-ne, le situazioni di sovraccarico dovrebbero rappresentare eventi eccezionali.Tuttavia e sempre possibile che si verifichino situazioni di congestione in cuie necessario ridurre il carico sull’interfaccia radio. In situazioni particolari,come il guasto di una stazione base vicina o la presenza di un numero elevatodi utenti, puo essere desiderabile ammettere un numero maggiore di collega-menti, nello stesso limite di carico massimo. Inoltre, in base a precise politichedel gestore, la rete puo trovarsi nella situazione di dover eliminare alcuni col-legamenti, per lasciare spazio ad esempio a chiamate di emergenza o a clientiprivilegiati in attesa.

La funzione di congestion control ha lo scopo di riportare il sistema ra-pidamente e in modo controllato al valore di carico desiderato, definito in

1.5 Gestione delle risorse radio 21

fase di pianificazione. Per limitare il carico sull’interfaccia radio, la rete puointraprendere diverse azioni:

� Fast load control downlink : ignora le richieste da parte dei terminalimobili di aumentare la potenza di trasmissione sulla tratta downlink. Inquesto modo il carico sull’interfaccia radio non aumenta ulteriormentee allo stesso tempo una parte degli utenti che si trovano sul bordo dellacella verranno disconnessi, non riuscendo piu a ricevere il segnale dellastazione base ad una adeguata potenza.

� Fast load control uplink : riduce il valore di Eb/N0 utilizzato in uplink. Diconseguenza la trasmissione in uplink puo avvenire utilizzando una mino-re potenza di trasmissione, riducendo cosı l’interferenza totale generatadagli utenti.

� Handover su un’altra eventuale portante W-CDMA o su GSM. Spostar-si su di un altra portante UMTS significa di fatto cambiare la frequenzadi funzionamento. Nel caso siano presenti piu portanti, quindi, trasfe-rire alcuni utenti su di un’altra frequenza elimina l’interferenza che essigenerano sulla portante congestionata. Allo stesso modo, e possibile di-rottare temporaneamente alcuni servizi sulle reti di telefonia di secondagenerazione, che operano ad una diversa frequenza radio.

� Riduzione del throughput consentito per il traffico dati. Alcune serviziofferti dalla rete UMTS sono molto versatili per quanto riguarda il tempodi trasmissione. In particolare le classi interattiva e background possonotollerare una riduzione della velocita di trasferimento. In situazioni diemergenza e quindi possibile ridurre momentaneamente il throughput dialcune connessioni, per lasciare spazio a nuove chiamate voce.

� Abbattimento di alcune chiamate in modo controllato. Sebbene questastrategia sia la piu drastica, sotto alcune condizioni la rete puo decideredi troncare alcuni collegamenti per far posto a nuovi utenti. E ad esem-pio accettabile interrompere una connessione attiva da molto tempo perfar posto ad una chiamata di emergenza, che si ipotizza essere di brevedurata.

Capitolo 2

Modellazione di sistemi

complessi

Il rapido avanzamento tecnologico a cui assistiamo ogni giorno ha introdot-to nella nostra vita una serie di infrastrutture, sistemi e applicazioni su cuifacciamo affidamento per svolgere le nostre attivita quotidiane. Come utenti,diamo spesso per scontato il funzionamento di questi servizi e una loro even-tuale interruzione ci lascerebbe sorpresi, basti pensare al blackout elettricoin Italia nel 2003. Per sistemi complessi, come puo essere una rete UMTS,garantirne il corretto funzionamento risulta un compito sempre piu difficile, acausa dell’elevato numero di fattori in gioco.

Per questo motivo negli ultimi anni si e assistito ad un crescente interessenell’analisi di sistemi tramite metodi matematici e statistici, che consentonodi quantificare il corretto funzionamento tramite valori numerici.

2.1 Il concetto di Dependability

Con il crescere degli studi su questo argomento e stato introdotto il concetto didependability. La dependability misura la fiducia che un utente puo riporre sulcorretto funzionamento di un servizio. In altre parole quanto un utente puofare affidamento sul fatto che il sistema stia funzionando in modo corretto,proprio, completo. Il concetto di dependability e la sintesi di piu attributiche forniscono misure quantitative o qualitative del sistema [3]. Fra le misurepiu importanti, la reliability misura la continuita e correttezza del servizionel tempo, mentre l’availability misura l’alternanza fra il tempo trascorso dal

23

24 Capitolo 2: Modellazione di sistemi complessi

sistema in uno stato proprio e in uno improprio. La safety e invece unamisura dell’abilita del sistema di evitare conseguenze dannose sugli utenti esull’ambiente circostante, in caso di malfunzionamento. La misura di integrityrappresenta la capacita del sistema di mantenere uno stato che non sia alteratoin modo improprio, mentre la confidentiality misura la capacita del sistema dievitare la divulgazione non autorizzata di dati sensibili. Per quanto riguarda leprestazioni di un sistema siamo abituati a considerare la sua performance, cioecon quanta efficacia e efficienza un sistema e in grado di fornire un determinatoservizio; la performability integra il concetto di dependability nella misuradelle prestazioni e fornisce una misura non solo in situazioni nominali, maanche in presenza di eventuali malfunzionamenti.

In base all’oggetto dell’analisi, ognuno degli attributi puo avere maggiore ominore importanza ai fini di valutare la dependability, che e quindi una misurarelativa al sistema considerato e alla qualita del servizio desiderata.

Data la natura casuale degli eventi che portano al fallimento di un sistema,le misure di dependability possono essere espresse mediante funzioni di tipoprobabilistico. Ad esempio l’availability di un sistema al tempo t puo esserecalcolata come la probabilita che il sistema sia in grado di fornire il servizioin modo proprio al tempo t. Questo ci permette di utilizzare degli opportunimodelli matematici per ricavare le misure di dependability di un sistema.

2.2 State-Based Models

Un potente strumento per l’analisi della dependability e rappresentato daimetodi state-based , grazie ai quali e possibile modellizzare in modo dettagliatole interazioni fra i componenti del sistema. Con i modelli basati sullo statonon e infatti necessario assumere l’indipendenza tra i guasti o le riparazioni,come avviene nei piu semplici modelli combinatori come fault trees e reliabilitygraphs [16].

2.2.1 Catene di Markov

Se il tipo di analisi permette una rappresentazione dell’ambiente tale chegli eventi non dipendano dalla storia passata ma solamente dalle condizioniattuali, allora il sistema puu essere valutato utilizzando le catene di Markov.

Le catene di Markov sono un formalismo state-based che si avvicina moltoa quello degli automi; l’insieme dei possibili stati di una catena di Markov

2.2 State-Based Models 25

prende il nome di spazio degli stati ed e denotato con S. Se lo spazio deglistati S e discreto o numerabile si utilizza correttamente il termine catene diMarkov, mentre nel caso in cui esso sia invece continuo si parla di processi diMarkov.

Formalmente una catena di Markov e un processo stocastico X(t), t ≥ 0con spazio degli stati discreto tale che, per ogni n > 0 e ogni sequenza diistanti temporali 0 < t1 < . . . < tn < tn+1, vale la seguente proprieta:

P [X(tn+1) = j|X(tn) = in, X(tn−1) = in−1, . . . , X(t1) = i1] =

= P [X(tn+1 = j|X(tn) = in], ∀j, in+1, in, . . . , i1 ∈ S.(2.1)

Questa proprieta, conosciuta come memoryless, indica che la proabilita che ilsistema si trovi in un particolare stato j al tempo tn+1 non dipende dall’interastoria del sistema, ma solamente dallo stato in cui esso si trovava all’istantedi tempo precedente, tn.

Se il valore attuale del processo stocastico e indipendente anche dal tempocorrente, allora la catena di Markov si dice a tempo omogeneo, a tempo nonomogeneo altrimenti. Il tempo t in una catena di Markov puo appartenere adun insieme discreto o continuo, nel primo caso le transizioni tra gli stati delprocesso si verificano esclusivamente in punti definiti del tempo, mentre nellecatene a tempo continuo possono occorrere ad un istante qualsiasi.

Di particolare interesse alla modellazione sono le catene di Markov omo-genee a tempo continuo, nelle quali lo stato futuro di un sistema dipendesolamente dallo stato attuale e gli eventi possono occorrere in qualsiasi istantedi tempo t. L’unica distribuzione continua che soddisfa la proprieta di memo-ryless e la distribuzione esponenziale, percio le transizioni che identificano ilpassaggio da uno stato all’altro del sistema dovranno seguire una distribuzionedi tempo esponenziale. Questo rappresenta un vincolo che limita l’applicabi-lita delle catene di Markov. Infatti, nel caso in cui si utilizzi una distribuzioneesponenziale per approssimare attivita di tipo diverso, vengono introdotte nelmodello delle approssimazioni che devono essere tenute in considerazione nelgiudicare la validita dei risultati ottenuti.

2.2.2 Reti di Petri (PN)

Le reti di Petri sono un formalismo introdotto da Carl Adam Petri nel 1962.Esse offrono un discreto potere espressivo e allo stesso tempo il loro utilizzo e


molto intuitivo, essendo rappresentabili come grafi. Formalmente una rete diPetri e una quintupla (P, T,A, M, µ0), dove:

� P = p1, p2, . . . , pn e un insieme finito di place, rappresentati graficamentecon un cerchio;

� T = t1, t2, . . . , tn e un insieme finito di transizioni, rappresentate grafi-camente con una barra;

� A ⊆ (P × T ) ∪ (T × P ) e un insieme di archi che collegano un place auna transizione (archi di input), o viceversa (archi di output);

� M : A → N+ e la molteplicita di un arco, rappresentata da un numerointero positivo;

� µ : P → N e la funzione che associa ad ogni place il numero di tokenpresenti in esso, detto marking del place. I token vengono rappresentatigraficamente come dei punti all’interno dei place. Il marking inizialedella rete e indicato con µ0.

Lo stato di una rete di Petri e rappresentato puo essere descritto utilizzando unvettore (µ(p1), µ(p2), . . . , µ(pn)), che prende il nome di marking della rete ed edefinito indicando il numero di token µ(pi) presente in ogni place i del modello.Le transizioni rappresentano gli eventi che modificano lo stato del sistema escattano soltanto se abilitate. Una transizione e abilitata solamente se ogniplace di input a cui e connessa contiene un numero di token maggiore o ugualealla molteplcita del rispettivo arco di input. Quando una transizione scattarimuove token dai place di input e ne aggiunge ai place di output. Il numero ditoken aggiunti o rimossi varia in base alla molteplicita degli archi interessati.Un place di input puo essere collegato a piu transizioni, creando competizionetra quest’ultime nel caso non vi siano sufficienti token per entrambe; in questocaso il comportamento della rete e non deterministico, a meno che non venganoassegnate delle priorita alle transizioni. Il Reachability Set (RS) di una retedi Petri e l’insieme dei marking che sono raggiungibili da quello iniziale µ0;il Reachability Graph e un grafo orientato che ha come nodi gli elementi delreachability set: (RS, A), dove A = (x, y)|x → y e dove ogni arco (x, y) eetichettato con il nome della transizione che puo cambiare marking da x a y.

Un sistema puo essere rappresentato associando i suoi possibili stati aimarking di una rete di Petri. I token sono usati per identificare le entita del


sistema, come tasks in esecuzione o messaggi da inviare. Le transizioni model-lano le attivita o i vincoli di sincronizzazione del sistema. Nelle reti di Petrinon e rappresentato in alcun modo il tempo e cio non permette di analizzareaspetti quantitativi di un sistema. Principalmente questo formalismo e sta-to infatti introdotto per modellare aspetti qualitativi di un sistema, come laconcorrenza, e per verificare proprieta strutturali come ad esempio l’assenzadi deadlock.

2.2.3 Reti di Petri Stocastiche (SPN)

Le reti di Petri Stocastiche (SPN) sono un estensione delle reti di Petri epermettono di considerare l’aspetto temporale degli eventi che caratterizzanoil sistema considerato. In un modello SPN ogni transizione t e temporizzata,cioe una volta abilitata scatta dopo aver atteso un intervallo di tempo casuale,campionato utilizzando una funzione di distribuzione esponenziale associataalla transizione. Occorre precisare che t scatta soltanto se rimane abilitata pertutto l’intervallo di tempo campionato. Quando t scatta, i token sono rimossidai place di input e aggiunti ai place di output in una singola operazioneatomica e istantanea.

L’abilitazione di una transizione continua a rispettare le regole definiteper le reti di Petri, ma e interessante osservare che nell’intervallo di tempo chetrascorre tra l’abilitazione e l’esecuzione di t, altre transizioni, che condividonocon questa alcuni place di input, possono scattare disabilitandola. In caso diconflitto, scatta per prima la transizione che campiona il tempo piu piccolo.L’utilizzo di una distribuzione esponenziale libera l’utente dal dover specificareil comportamento per quelle transizioni che non scattano una volta abilitate.Questo perche, grazie alla proprieta di memoryless, il rate con il quale t scattae indipendente dal fatto che la transizione sia stata abilitata precedentemente.

Per risolvere una rete di Petri stocastica si utilizzano i processi di Mar-kov. Eticchettando infatti gli archi del reachability graph con il rate delletransizioni, anziche il nome, si ottiene un grafo isomorfo ad una catena diMarkov a tempo continuo omogenea. Risolvere una SPN si riconduce quindialla risoluzione della catena di Markov associata.


2.2.4 Reti di Petri Stocastiche Generalizzate (GSPN)

Le reti di Petri stocastiche generalizzate (GSPN) utilizzano, oltre alle transi-zioni temporizzate, le transizioni istantanee, le quali scattano appena abilitate.Occorre pero precisare, che per i modelli GSPN, gli elementi del reachabilityset non sono in una corrispondenza biunivoca con gli stati della catena diMarkov associata. Questo perche, a causa delle transizioni istantanee, alcunidei marking del reachability graph hanno un tempo nullo di permanenza, cioeil modello GSPN spende tempo zero in tale condizione. Questi marking pren-dono il nome di vanishing markings, o marking instabili. Tuttavia e possibileoperare un riduzione del reachability graph per eliminare i vanishing markingse ottenere un reachability graph ridotto, isomorfo ad una catena di Markova tempo continuo. Il processo di riduzione non ha alcun effetto sui risultatiprodotti, in quanto la probabilita di occupare un stato vanishing e nulla edquindi inutile considerarli al momento in cui e costruito il reachability graph.

2.2.5 Reti di Petri Stocastiche e Deterministiche (DSPN)

Lo standard definito dalle reti di Petri stocastiche generalizzate implica chetutte le attivita temporizzate di un sistema siano rappresentate utilizzandodelle transizioni che hanno una distribuzione esponenziale, cosı che dal mo-dello possa ricavata una catena di Markov omogenea a tempo continuo. Comegia evidenziato, cio implica l’introduzione di una approssimazione tutte levolte che deve essere rappresentata un attivita che non ha una durata espo-nenziale. Per risolvere questo tipo di problema sono state definite una serie diclassi di reti di Petri (reti di Petri non-Markovian) che utilizzano transizioniche hanno distribuzioni non esponenziali. Le reti di Petri deterministiche estocastiche (DSPN) fanno parte di queste classi. Le DSPN sono un’estensio-ne delle GSPN e permettono di modellizzare gli eventi che occorrono con untempo deterministico. Questo arricchimento dell’insieme delle possibili tran-sizioni offerto dalle DSPN permette di modellare in maniera corretta un setpiu vasto delle caratteristiche di un sistema, come il timeout e il ritardo dipropagazione di un messaggio, in un sistema sincrono.

Purtroppo, la soluzione analitica di un modello DSPN non e applicabilenella maggioranza dei casi. La distribuzione deterministica non gode infattidella proprieta di memoryless e lo sviluppo temporale del modello richiededi tenere conto di molte informazioni supplementari, che complicano notevol-


mente l’analisi. Tuttavia, la soluzione analitica e garantita per un sottoinsiemedi modelli DSPN in cui vi sia in ogni istante di tempo al piu una transizionedeterministica abilitata. Questa assunzione pero limita molto l’espressivita diun modello DSPN.

2.2.6 Stochastic Activity Networks (SAN)

Le Stochastic Activity Networks (SAN) sono state trattate per la prima voltanel 1985 e rappresentano un’ulteriore estensione delle reti di Petri. Gli ele-menti che compongono una SAN sono place, attivita, archi e gates. Le attivitacorrispondono alle transizioni delle reti di Petri e place e token mantengono lostesso significato. Le transizioni possono essere sia istantanee che temporizza-te; quelle istantanee scattano non appena abilitate, mentre ciascuna attivitatemporizzata ha associata una funzione continua detta activity time distribu-tion function, che determina il ritardo con il quale una transizione, una voltaabilitata, scatta. Le attivita presenti in una SAN possono avere dei case, acui sono associate delle probabilita e che rappresentano l’incertezza sull’azioneintrapresa dalla rete in seguito a un evento. I gate collegano le attivita e iplace e definiscono interazioni complesse tra le risorse e gli eventi del sistema.Gli input gate connettono i place alle transizioni e sono formati da un pre-dicato booleano e da una funzione di input; gli output gate invece colleganouna transizione a uno o piu place e sono formati solamente da una funzionedi output.

Un’attivita e abilitata se i predicati di tutti gli input gate a cui e connessasono soddisfatti e per ogni arco che connette un place all’attivita e presentealmeno un token nel place corrispondente. Quando un’attivita scatta vengonoeseguite le seguente azioni, nell’ordine descritto:

1. se un’attivita presenta piu case ne viene selezionato uno, in base allaprobabilita associata;

2. vengono tolti i token dai place connessi tramite archi di input, in baseal numero di archi;

3. vengono eseguite le funzioni di tutti gli input gate connessi all’attivita;

4. vengono aggiunti i token negli eventuali place di output, in base agliarchi presenti;


5. vengono eseguite le funzioni di tutti gli output gate connessi.

In base al tipo di modello costruito una SAN puo rientrare nelle classifica-zioni dei modelli precedenti e possono quindi essere utilizzati i corrispondentiprocedimenti analitici per la risoluzione. Se ad esempio una SAN e formatasolamente da transizioni esponenziali potra essere risolta come una GSPN,sfruttando la catena di Markov associata (vedi 2.2.4). Quando questo non epossibile, si devono cercare soluzioni su misura, ricorrendo se necessario allasimulazione del modello con strumenti appositi.

2.3 Il tool Mobius

Mobius e un software che permette di modellare il comportamento di sistemicomplessi attraverso l’utilizzo di diversi formalismi. La caratteristica prin-cipale di questo strumento e la sua modularita, che permette la massimainterazione tra i diversi componenti, e la portabilita. Infatti, oltre ad esseredisponibile per diverse piattaforme (Windows, Linux, Mac OS), potrebbe esse-re adattato anche agli altri sistemi che supportano Java e C++. Per maggioriinformazioni su questo framework e possibile consultare [14].

Tra i formalismi che Mobius mette a disposizione e fornito un ampio sup-porto per le SAN. Si possono infatti creare modelli basati su questo formali-smo, definire le misure di interesse che si intendono ricavare e infine risolvereil modello, utilizzando diversi parametri di esecuzione.

La risoluzione avviene per via analitica, quando possibile, oppure sfruttan-do la funzione di simulazione. Se si utilizzano distribuzioni diverse da quellaesponenziale per la temporizzazione delle attivita infatti, la risoluzione attra-verso metodi matematici diventa problematica. In questi casi la simulazioneci fornisce una strada alternativa, che presenta pero anche alcuni svantaggi.I risultati ottenuti tramite simulazione infatti non sono mai esatti, anche sepossono essere molto precisi, aumentando il livello di confidenza richiesto alsimulatore; inoltre la simulazione di un sistema molto esteso puo richiedereun elevato tempo di elaborazione e numerose risorse hardware. Tramite lasimulazione e pero possibile avere una maggiore liberta nella definizione delsistema e realizzare modelli piu realistici di quanto si farebbe rispettando ivincoli dati dai metodi di risoluzione analitici.

La versione corrente al momento di scrivere questa tesi e la 2.0.2, che e

2.4 Esperienze precedenti: Modello di una rete UMTS 31

stata utilizzata per la definizione dei modelli SAN e la loro risoluzione, tramitesimulazione.

2.4 Esperienze precedenti: Modello di una rete

UMTS

Il lavoro svolto in questa tesi ha come punto di partenza un precedente stu-dio e modellazione del sistema UMTS, esposto in [5]. Lo scopo di questaulteriore analisi e quello di estendere il modello in questione, rinnovarlo edespanderlo sfruttando le nuove possibilia offerte dall’evoluzione del sistema dimodellazione.

Nei paragrafi che seguono viene riassunto il lavoro gia svolto in [5], soffer-mandosi sulla struttura del modello SAN che e servito come base per l’analisidella rete UMTS condotta in questa tesi.

2.4.1 Topografia della rete

Possiamo definire una generica rete mobile come l’unione di molteplici areelocali. Un’area locale e un insieme di celle parzialmente sovrapposte, cioe uninsieme di celle che condividono frequenze e utenti [9][11]. Con il termine cellasi intende un’area in cui il segnale ricevuto da una stazione base predominarispetto a quello ricevuto dalle altre.

Ogni cella copre una parte di area locale ed e caratterizzata da un modelloarchitetturale che la descrive, da un modello utente generico, da un modelloutente in soft handover e dal modello di interazione tra le celle e gli utenti.

2.4.2 Assunzioni

Quando si crea un modello per un sistema reale non e possibile rappresentarefedelmente ogni aspetto, ma e necessario astrarre alcuni comportamenti, perconcentrarsi sugli aspetti a cui si e maggiormente interessati. Perche un mo-dello sia coerente e facilmente riproducibile e necessario rendere esplicite leassunzioni che si sono fatte sul comportamento del sistema.

1. Il sistema e costituito da celle che possono avere aree di coperturadisgiunte o sovrapposte;


2. le celle possono essere attive ed avere tutte le risorse allocabili, inattive e,quindi, non avere nessuna risorsa allocabile oppure parzialmente attive;

3. le celle contengono un numero di utenti costante, distribuiti in modouniforme all’interno della loro area di copertura;

4. gli utenti generici sono connessi ad un’unica cella;

5. gli utenti in soft handover possono essere connessi a due o piu celle;

6. tutti gli utenti vengono distinti in base al servizio da loro richiesto edhanno la stessa priorita;

7. le classi di servizio vengono distinte in base al throughput, al carico checomportano sulla cella e ai tempi di servizio;

8. un utente non puo passare da un servizio all’altro;

9. se la richiesta di servizio viene accettata, la cella alloca all’utente uncanale dedicato che sara rilasciato solo a fine servizio;

10. perche una richiesta venga accettata, questa non dovra apportare uncarico che causi sovraccarico nella cella stessa (algoritmo di AdmissionControl).

2.4.3 Misure di interesse

Tramite il modello che abbiamo utilizzato come base per questo lavoro possonoessere valutate diverse misure di interesse riguardanti una rete UMTS, tra cui:

� il numero di canali allocati in ciascuna cella, sommando il valore deiplace contatori;

� il carico della cella, sulle tratte downlink e uplink, moltiplicando il nu-mero di canali allocati a ciascun servizio per il relativo carico generatosull’interfaccia radio, calcolato come descritto nella sezione 1.2.5;

� il noise rise puo essere calcolato dal carico di una cella, sfruttando la(1.6);

� la probabilita che una richiesta di connessione, per una specifica classedi servizio, non sia soddisfatta puo essere calcolata come il rapporto tra


il numero di utenti nello stato di fallimento e il numero complessivo diutenti appartenenti alla classe di servizio e caratterizzati da una dataconnessione, il tutto riportato in percentuale.

Una descrizione dettagliata della misure di interesse ricavabili dal modellooriginale puo essere letta in [5].

2.4.4 Modulo Cella

Il modello della cella (Figura 2.1) e strutturato in modo tale da contenereinformazioni sia sulle risorse disponibili sia sullo stato di attivita della cellastessa. Il modello puo essere considerato come l’unione di due sottosistemi:uno che rappresenta la gestione delle risorse e la dinamica delle richieste, del-l’allocazione dei canali e dello smistamento degli utenti, e l’altra che modellizzala variazione degli stati in cui si puo trovare la cella. In questo modello vengo-no effettuate le procedure di admission control e congestion control, entramberealizzate dall’output gate Gestione Risorse.

Figura 2.1: Modello Cella

2.4.5 Modulo Utente Generico

Il modello per un utente generico (Figura 2.2) viene definito attraverso le azioniche esso puo compiere e gli eventi che puo subire. Inizialmente tutti gli utentisono idle, ovvero in attesa. Dopo aver atteso un tempo determinato da unadistibuzione esponenziale, ogni utente richiede un canale dedicato per poterusufruire del servizio. In seguito al controllo dello stato di attivita e del caricodella cella, la richiesta puo essere accettata o rifiutata. Se la richiesta vieneaccettata, l’utente avvia il servizio, altrimenti passa in uno stato di fallimento.Se si verifica un outage nella cella, il servizio puo venire interrotto e l’utente


passare nello stato dropped. In seguito a un fallimento o interruzione delservizio un utente attendera un certo periodo di tempo prima di tornare nellostato di idle, da cui ricomincia la sequenza di azioni utente. La transizioneTset up rappresenta l’esecuzione della procedura di accesso casuale (RACH,sezione 1.5.1) e l’instaurazione del nuovo radio bearer.

Figura 2.2: Modello Utente Generico

2.4.6 Modulo Utente in Soft Handover (SHO)

Questo modello descrive il comportamento di un UE che si trova nella zo-na di intersezione e sovrapposizione delle aree di copertura di due celle. Lacomunicazione tra il mobile e la stazione radio base avviene utilizzando con-temporaneamente due canali di interfaccia radio, uno da ogni stazione radiobase. Come si puo vedere nella Figura 2.3, il comportamento del modello emolto simile a quello per l’utente connesso ad una sola cella, con le opportunedifferenze per quanto riguarda la richiesta e l’esecuzione del servizio.

2.4.7 Modulo Interazione Cella / Utente

La classe Interazione Cella / Utente modellizza la comunicazione tra l’utentee la cella a cui e connesso. Questo modulo rappresenta il mezzo grazie al qualevengono smistate le richieste degli utenti. Nel modello finale viene posto adun livello intermedio tra cella e utente, in modo da permettere una conoscenzaminima tra i due moduli e il soddisfacimento della proprieta di incapsulamento.Questo modello si occupa infatti di allocare e rilasciare i canali in base allerichieste degli utenti, o di comunicare il fallimento della richiesta, in caso chenon sia possibile soddisfarla.


Figura 2.3: Modello Utente in Soft Handover

Figura 2.4: Modello di interazione Cella / Utente

2.4.8 Modulo Interazione Cella / Utente SHO

Il principio di funzionamento e lo stesso del modello precedente, con le dovutedifferenze date della diversa modalita di connessione da parte degli utenti(Figura 2.5). L’input gate Assegna Canali alloca i canali utente in base airisultati dell’algoritmo di admission control delle due celle. La proceduraimplementata nell’input gate assegna due canali all’utente solamente nel casoin cui entrambe le stazioni radio base abbiano dato risposta positiva. Se invece,


in seguito all’esecuzione dell’algoritmo, risultasse possibile utilizzare il canaledi una sola cella, verrebbe avviato il servizio su quella sola cella. Altrimenti, senessuna delle due celle puo supportare il carico relativo alla richiesta effettuata,viene segnalato all’utente il fallimento della richiesta, aggiungendo un tokennel place Fail.

Figura 2.5: Modello di interazione Cella / Utente in Soft Handover

2.4.9 Composizione

Il modello completo della rete UMTS viene realizzato componendo tra loroi moduli precedentemente descritti, utilizzando l’operatore di join [16][14].Ogni stazione base che vogliamo riprodurre sara rappresentata da un diver-so modello Cella, mentre svariati modelli di tipo Utente, Utente SHO e diinterazione rappresenteranno le diverse tipologie di utenti e servizi previsti.La composizione avviene tramite due livelli di join, il primo livello componei moduli Utente e Utente SHO con i relativi modelli di interazione, mentreil secondo realizza la composizione tra i modelli cosı ottenuti e le celle. Unesempio di modello composto creato seguendo questo schema e riportato nellaFigura 2.6 e rappresenta un’area locale formata da due stazioni base (A e B)e tre diverse tipologie di servizio.

2.5 Esperienze precedenti: Modello della procedura RACH 37

Figura 2.6: Modello composto per una rete con due celle e tre possibili servizi

2.5 Esperienze precedenti: Modello della

procedura RACH

Un altro importante lavoro di modellazione riguardante la tecnologia UMTSe presentato in [15] e riportato in [10]. In questo caso viene trattata in modomolto dettagliato la procedura di accesso casuale (sezione 1.5.1), ma vengonoconsiderati scenari composti da una singola stazione base. Da questo studioabbiamo preso spunto maggiormente per quanto riguarda gli aspetti teoricidella rete UMTS e per l’impostazione dei parametri, piuttosto che quantoriguarda i modelli SAN della procedura di accesso casuale. Per completezzariportiamo in questa sezione un breve riassunto del contenuto.

2.5.1 Il modello della stazione base

In [15] viene creato il modello di una stazione base UMTS, dettagliandonela procedura RACH fino al livello piu basso, in cui e possibile distinguere lastruttura della trama del segnale radio.

I modelli impiegati per valutare le prestazioni della cella UMTS sono ot-tenuti a partire da tre moduli base, realizzati utilizzando Stochastic ActivityNetworks, ed ognuno di essi cattura un aspetto diverso del comportamentodella rete UMTS. Nel primo dei tre moduli (Gestione Risorse) sono model-late le operazioni per la gestione delle risorse della cella, di cui fanno partel’allocazione dei canali dedicati e il controllo delle collisioni; inoltre per sin-cronizzare in modo corretto le richieste di accesso, e modellata la struttura


Figura 2.7: Modello per la procedura di accesso casuale

del canale fisico PRACH. Il secondo modulo (ProcAccesso1 UtentiServ 1,Figura 2.7) riproduce la procedura di accesso casuale determinando in pra-tica, in base al tipo di servizio richiesto, qual e lo slot di accesso che puoessere utilizzato dall’utente per inviare la richiesta di connessione. Il terzomodulo (Utenti Servizio 1) cattura il comportamento di un utente dellacella UMTS stabilendo la frequenza e la potenza con la quale sono inviate lerichieste di accesso, la durata del servizio e il numero massimo di tentativi cheil terminale mobile puo fare affinche gli venga assegnato un canale dedicato.Per ottenere i modelli che ci permettono di studiare il comportamento dellacella UMTS i moduli sono collegati sfruttando la condivisione di alcuni deiplace che fanno parte delle tre sotto reti.

Capitolo 3

Il modello della rete UMTS

In questo capitolo vengono presentate le novita introdotte nel modello SAN.L’obiettivo che ci siamo inizialmente posti e stato quello di affinare il modelloesistente, sfruttando anche le nuove potenzialita del framework di modella-zione Mobius. In particolare si e pensato di renderlo maggiormente flessibilee scalabile rispetto alle dimensioni della rete UMTS considerata, utilizzandouna metodologia di modellazione parametrica per sfruttare le simmetrie tra imoduli del sistema. In secondo luogo, si e voluto ampliare il numero di scenarirappresentabili, dettagliando maggiormente il modello e introducendo nuovefunzionalita. Tra le modifiche introdotte, le piu sostanziose sono due: la pri-ma riguarda le stazioni base e fa sı che esse possano funzionare in uno statodegradato, con una capacita massima ridotta; la seconda riguarda invece gliutenti e permette loro di muoversi all’interno del sistema, sfruttando di voltain volta le risorse delle diverse celle attraversate.

Per raggiungere questi obiettivi e stato necessario realizzare una maggioreindipendenza tra i livelli applicazione, collegamento e fisico dell’architettura direte. Nei paragrafi che seguono viene illustrato il processo di trasformazionedel modello SAN esistente, rispettando nell’esposizione l’ordine cronologicosecondo il quale le modifiche sono state introdotte nel sistema. In questomodo si avra una visione piu immediata delle problematiche riscontrate edelle metodologie adottate per risolverle, cosı da poter comprendere meglio lescelte progettuali che hanno portato al modello finale.

39

40 Capitolo 3: Il modello della rete UMTS

3.1 Assunzioni

Il modello che andremo a descrivere, cosı come quello originale, si basa su al-cune assunzioni che sono servite ad astrarre da alcuni aspetti dell’architetturaUMTS, per non rendere troppo complesso il sistema da analizzare:

1. il sistema e costituito da celle che possono avere aree di copertura par-zialmente sovrapposte, completamente sovrapposte, o disgiunte;

2. un utente puo richiedere diversi servizi nell’arco della sua presenza al-l’interno del sistema, ma solamente uno alla volta;

3. un utente puo ricevere il segnale di una o piu stazioni base;

4. la funzionalita di soft handover puo essere disabilitata (impostando ilparametro DisableHandover a 1), in tal caso viene scelta casualmenteuna stazione base tra quelle ricevute dall’utente;

5. per portare a termine l’esecuzione di un servizio sono necessari almenoun canale dedicato “normale” oppure due in soft handover;

6. l’allocazione e rilascio dei canali dedicati avviene istantaneamente;

7. se la funzione di soft handover e abilitata, un terminale mobile attendela risposta negativa da parte di tutte le stazioni base di cui riceve ilsegnale, prima di dichiarare fallita la richiesta;

8. gli utenti si possono spostare tra una zona e l’altra; le transizioni di mo-vimento rappresentano l’istante in cui all’active set del terminale mobileviene aggiunta o rimossa una stazione base;

9. gli utenti sono distribuiti in modo uniforme all’interno delle zone dicopertura delle celle e il carico generato su di una stazione base, a paritadi servizio, e lo stesso per tutti gli utenti;

10. il soft handover e asincrono; quando possibile un utente richiede la con-nessione a piu celle, ma se quando ottiene un canale dedicato le altrestazioni non hanno ancora risposto allora iniziera la trasmissione in mo-dalita normale, per poi trasmettere in handover, quando anche le altrecelle gli concederanno delle risorse.

3.2 Misure di interesse 41

3.2 Misure di interesse

Prima di proseguire elenchiamo brevemente alcune misure che caratterizzanole prestazioni di una rete UMTS e che possono essere ricavate dal modello cheandremo a descrivere:

1. il carico sulla tratta uplink e downlink di una stazione base, calcolatosecondo (1.7) e (1.8), rispettivamente;

2. il numero totale di canali dedicati allocati in una stazione base, perciascun servizio;

3. il numero di canali in soft handover allocati in una stazione base, perciascun servizio;

4. il numero totale di utenti connessi in soft handover;

5. il throughput di una stazione base, in un determinato istante oppureallo steady-state;

6. la probabilita di fallimento di una richiesta di connessione da partedell’utente;

7. la probabilita di interruzione del servizio, dovuta a guasti delle stazionibase o al fallimento dell’handover durante lo spostamento dell’utente trale celle della rete;

8. il livello di insoddisfazione dell’utente, misurato come la probabilita ditrovarsi in uno stato di attesa per essere stato scartato o rifiutato dallestazioni base.

Una descrizione dettagliata di come estrarre le misure dal modello SAN efornita alla fine di questo capitolo, nella sezione 3.10.

3.3 Place estesi e tipi di dato strutturati

Le modifiche apportate al modello originale sono state in parte possibili graziead alcune novita introdotte nelle ultime versioni di Mobius. Particolarmenterilevante e stato il maggior supporto fornito per i place estesi, un’estensionedelle normali SAN che permettono di avere nel modello dei place quanto piupossibile simili a variabili del linguaggio C. Normalmente infatti un place puo


contenere un numero intero di token, un place esteso invece contiene un valorein uno dei tipi primitivi del linguaggio C: short, int, float, double, char.

La versione attuale inoltre consente all’utente di definire dei tipi di datostrutturati a proprio piacimento, sebbene con alcune limitazioni. Pur essendoutile gia di per se utilizzare tali strutture nel codice dei gate, l’importan-za di questa funzione diviene assai piu evidente se utilizzata in congiunzio-ne con i place estesi. In questo modo si possono avere place che contengo-no una qualsiasi struttura dati, creata su misura per il sistema che si vuolerappresentare.

Per una rete UMTS ad esempio si puo definire una struttura dati cherappresenti il carico di una cella, equivalente al seguente codice C:

typedef struct Workload {double Downlink ;

double Uplink ;

} ;

Utilizzando dei place estesi di tipo Workload, ogni cella potra cosı memorizzareil proprio carico all’interno del modello che la rappresenta, anziche tramitedelle variabili globali.

3.4 Parametrizzazione dei modelli

La prima modifica e nata dalla considerazione che per modellizzare una re-te con diverse celle che supportano piu servizi, occorre creare un modello ditipo Utente (2.4.5) per ogni coppia cella/servizio. Ad esempio per due celle(A e B) e tre servizi dovranno essere costruiti i modelli UtenteA1, UtenteA2,UtenteA3, UtenteB1, UtenteB2 e UtenteB3. Ciascuno di questi modelli avralo stesso comportamento e seguira il flusso di azioni tipico del generico uten-te. Le diverse caratteristiche dei servizi e il numero di utenti considerato inognuno dei casi rendono tuttavia necessaria una tale diversificazione. Inoltre,anche in fase di definizione delle misure di interesse puo essere necessaria unadistinzione tra i singoli modelli.

3.4.1 Motivazione

Proprio a causa di questa somiglianza pero, dal punto di vista della program-mazione, la creazione di un modello diverso per ogni coppia cella/servizio por-

3.4 Parametrizzazione dei modelli 43

ta ad un’eccessiva duplicazione di codice. Come considerazione piu pratica,essendo un’operazione che viene eseguita manualmente, la duplicazione puoessere facile causa di errori o sviste non altrettanto facilmente individuabili,oltre ad essere un’operazione onerosa per l’utente.

Grazie alle nuove caratteristiche di Mobius, e stato possibile aggirare que-sto problema, utilizzando un diverso approccio alla duplicazione dei modelli.Il metodo utilizzato puo essere compreso meglio pensando ogni modello utentecome istanza di una classe di modelli utente, inizializzata alla sua creazionecon un diverso valore dei suoi attributi, che possono essere ad esempio la du-rata del servizio o il numero di utenti presenti. Utilizzando questi termini equasi immediato il richiamo alla programmazione a oggetti (OOP), si e cer-cato infatti di utilizzare un approccio che tenga in considerazione i concettidi incapsulamento e information hiding tipici della filosofia a oggetti. La con-seguenza di queste considerazioni e che un modello utente potrebbe essereduplicato senza conoscere i dettagli della sua implementazione, ma solamen-te una interfaccia ben definita attraverso la quale assegnare i parametri emetterlo in comunicazione con il resto del sistema.

3.4.2 Moduli utente

Per raggiungere lo scopo e prima di tutto necessario individuare quali siano icomportamenti comuni a tutti i modelli utente e quali sono invece determinatida valori che diventeranno i parametri del modello comune. La scelta deiparametri non e univoca, ma dipende anche dal grado di dettaglio che vogliamoadottare; nel nostro caso abbiamo considerato come parametri il tempo diservizio e il numero di utenti che utilizzano il servizio. Virtualmente qualsiasivalore numerico presente nel modello puo essere reso parametrico (ad esempioil tempo di inattivita o il tempo di setup), tuttavia per non complicare troppoil modello finale e bene farlo solamente quando necessario.

Una volta individuati i parametri, deve essere creato per ognuno di essi unplace (eventualmente esteso) che conterra il loro valore. Nel nostro caso unplace Utenti esiste gia e non e quindi necessario crearlo nuovamente, mentredovremo creare un place esteso di tipo double per il tempo di servizio. I valoridi questi parametri dovranno poi essere utilizzati al momento opportuno, alposto delle variabili globali. Ad esempio, se Inizio contiene il numero diutenti che sono in fase di esecuzione del servizio e ServiceTime e il parametro


Figura 3.1: Modello parametrico per l’utente in soft handover (UtenteSHO)

di durata, il rate della transizione che rappresenta la fine del servizio vienedefinito come:

I n i z i o−>Mark ( )/ ServiceTime−>Mark ( )

Lo stesso procedimento puo essere applicato anche al modello per l’utente insoft handover (Figura 3.1), con le dovute differenze per quanto riguarda ilflusso di azioni.

3.4.3 Moduli di interazione

Il processo di parametrizzazione non sarebbe stato completo se si fossero la-sciati i moduli di interazione nella loro versione originale. Questi dovrebberoancora essere duplicati, rendendo parzialmente inutili le modifiche apportate aimoduli utente. Anche i moduli di interazione possono essere resi parametrici,rendendo piu semplice la loro struttura.

Nel modello originale, per ogni cella viene creato un modello per ciascuntipo di interazione prevista, capace di gestire tutti i servizi. Vale a dire unoper ogni cella e uno per ogni tipo di handover previsto tra le celle. Ciascuno diquesti modelli puo essere visto come aggregazione di piu parti, ognuna dedicataalla gestione di un solo servizio. Individuando come parametro il numero diutenti, possiamo quindi considerare come moduli elementari la gestione di un

3.4 Parametrizzazione dei modelli 45

Figura 3.2: Modello parametrico di interazione cella/utente generico (GestioneUtente)

Figura 3.3: Modello parametrico di interazione cella/utente in soft handover(GestioneUtenteSHO)

servizio su di una cella e la gestione di un servizio in handover, ottenendole classi GestioneUtente (Figura 3.2) e GestioneUtenteSHO (Figura 3.3),rispettivamente.

Facendo un parallelo con il modello composto della Figura 2.6 ci possia-mo rendere conto dell’efficacia di questo metodo. Nel modello originale eranecessario creare un totale di 14 modelli atomici, celle comprese. Utilizzandola parametrizzazione ne sarebbero necessari solamente 6; oltre alle due stazio-ni base infatti basterebbero i modelli Utente, UtenteSHO, GestioneUtente,GestioneUtenteSHO, istanziati piu volte nella fase di composizione.

3.4.4 Inizializzazione

Fin qui ci siamo preoccupati di creare modelli che siano parametrici, ma nonabbiamo ancora accennato a come inizializzare ciascuna istanza degli stessicon i parametri desiderati. Vista la rappresentazione dei parametri tramiteplace, dovremo assegnare un valore iniziale diverso ai place di ciascuna istanzadel modello. Purtroppo la versione corrente di Mobius (v2.0.2) non permettedi farlo direttamente, percio sara necessario utilizzare un piccolo espediente.

Creiamo un nuovo modello destinato all’inizializzazione del sistema, de-nominato Startup. Questo modello conterra un place per ciascuno dei valori


Figura 3.4: Modello di inizializzazione (Startup)

che si intende assegnare come parametri. Tramite l’operazione di join, ognunodi questi place verra messo in corrispondenza con i place che devono essereinizializzati a tale valore. Successivamente nel modello Startup i place in que-stione ottengono il loro valore iniziale, che si propaghera anche nel modellodestinatario. Per assegnare il valore iniziale e possibile utilizzare la funzioneCustom Initialization, oppure una semplice transizione istantanea che assegnai valori tramite un output gate.

Sebbene l’utilizzo della funzione di inizializzazione sia la soluzione piu pu-lita, attraverso i nostri esperimenti ci e apparsa soffrire di qualche difetto,legato alla condivisione dei place tramite l’operazione di join. Abbiamo perciopreferito utilizzare una transizione istantanea in congiunzione con un outputgate. Utilizzando questa soluzione e bene ricordare che nel caso vi siano piuattivita istantanee abilitate, l’ordine di esecuzione non e definito e non e ga-rantito percio che l’attivita in questione sia la prima in assoluto a scattare.Nel nostro modello questo aspetto non e di particolare importanza, non es-sendoci al tempo zero altre attivita istantanee che utilizzano direttamente oindirettamente il valore dei parametri.

Per comprendere meglio il funzionamento, facciamo un semplice esempiocon il modello riportato nella Figura 3.4. Supponiamo di voler rappresentaretre servizi, forniti da due celle, A e B. Ogni servizio avra la propria durata,rappresentata dalle variabili globali tServizio1, tServizio2 e tServizio3.Anche per semplicita, ipotizziamo che ogni servizio sia richiesto dallo stesso nu-mero di utenti in ciascuna delle zone, numero indicato dalle variabili nUtentiA,nUtentiAB e nUtentiB. Attraverso il join, ogni place ServiceTimeN vienefatto corrispondere al place ServiceTime di un diverso modello User, mentreciascuno degli altri place avra la sua corrispondenza con un place Utenti. Infi-ne, i parametri verranno inizializzati con il seguente codice, contenuto nel gateOGInitialize o, eventualmente, inserito nella funzione di inizializzazione.

ServiceTime1−>Mark ( ) = tS e r v i z i o 1 ;

3.5 Procedure di Handover e allocazione canali 47

ServiceTime2−>Mark ( ) = tS e r v i z i o 2 ;ServiceTime3−>Mark ( ) = tS e r v i z i o 3 ;UtentiA1−>Mark ( ) = nUtentiA ;UtentiA2−>Mark ( ) = nUtentiA ;UtentiA3−>Mark ( ) = nUtentiA ;UtentiAB1−>Mark ( ) = nUtentiAB ;UtentiAB2−>Mark ( ) = nUtentiAB ;UtentiAB3−>Mark ( ) = nUtentiAB ;UtentiB1−>Mark ( ) = nUtentiB ;UtentiB2−>Mark ( ) = nUtentiB ;UtentiB3−>Mark ( ) = nUtentiB ;

Inoltre il processo di inizializzazione puo essere reso ancora piu automatico,considerando che Mobius permette di caricare i valori delle variabili globali daun file di configurazione testuale.

3.5 Procedure di Handover e allocazione canali

Il passo successivo e stato quello di affinare le procedure di handover, det-tagliando la loro esecuzione nel caso di fallimento o blocco da parte di unadelle celle coinvolte. Questo comprende la possibilita per un utente in softhandover di essere trattato come utente generico, nel caso in cui i canali nonsiano disponibili da entrambe le celle. In questo caso all’utente sara allocatoun canale normale, con il relativo carico, generalmente superiore rispetto alcollegamento in soft handover. Allo stesso modo, se si verifica il guasto diuna cella mentre un utente ha gia in esecuzione il proprio servizio, si dovrebbecercare di portare a termine quest’ultimo, allocando maggiori risorse sull’altracella, quando possibile.

Con lo scopo di modellizzare queste nuove strategie, il controllo di ammis-sione di carico viene spostato ad un livello intermedio fra la cella e l’utente,in modo da poter dialogare contemporaneamente con tutte le celle coinvoltenell’handover. Allo stesso tempo questa modifica consente di parametriz-zare ulteriormente i modelli di interazione, rispetto al carico del servizio, esemplificare il modello che descrive la stazione base.

I modelli GestioneUtente e GestioneUtenteSHO vengono cosı modifica-ti per eseguire l’allocazione e il rilascio dei canali dedicati. In particolare,vengono aggiunti dei place estesi di tipo Workload (paragrafo 3.3):


Figura 3.5: Modello di interazione per l’utente in soft handover (GestioneUtenteSHO).Versione modificata per eseguire le operazioni di allocazione e rilascio deicanali utente, su due celle

� LoadFactor: memorizza il carico di una cella, ne possono essere presentipiu di uno se si tratta del modello per la gestione dell’utente in softhandover;

� MaxLoad: uno per ciascuna cella coinvolta, memorizza il carico massimoaccettabile dalla cella;

� ServiceLoad: il fattore di carico del servizio considerato, anche in que-sto caso ne puo essere presente uno per ogni cella, nel caso i valori noncoincidessero;

� ServiceLoadSHO: il fattore di carico del servizio nel caso di trasmissionecon soft handover.

Per i dettagli sul carico di un servizio e la capacita di una stazione base UMTSsi veda il paragrafo 1.2.5.

Avendo a disposizione queste nuove informazioni, i modelli di interazionesono in grado di effettuare le operazioni necessarie alla allocazione e deal-locazione dei canali, tramite i gate AssegnaCanali e RilasciaCanali, giaesistenti. Lo spostamento della parte dedicata all’admission control permet-te di semplificare notevolmente il modello Cella. Inoltre l’impatto causa-to dall’aggiunta di un nuovo servizio e ridotto, considerando che gran par-

3.6 Guasti parziali e parametrizzazione del modulo cella 49

te del codice e distribuito nelle varie istanze dei modelli GestioneUtente eGestioneUtenteSHO.

Come conseguenza, deve essere spostata in questo modulo anche la parteche esegue l’abbattimento delle chiamate in caso di guasto della cella, pre-cedentemente collocata nel modulo Utente o UtenteSHO. Nel caso del softhandover questa parte (visibile in basso a sinistra nella Figura 3.5) si occupaanche di gestire il guasto di una cella in modo che il servizio possa proseguire,allocando piu risorse sull’altra.

3.6 Guasti parziali e parametrizzazione del

modulo cella

Una modifica che e venuta naturale pensare a questo punto riguarda lo statodi attivita di una cella. Pensando ad una rappresentazione piu generale delfallimento di una stazione base, abbiamo deciso di non considerare solamenteuno stato di tipo on/off, ma di consentire anche un funzionamento degradato,che consenta di avere a disposizione una percentuale delle risorse della cella.Per guasti parziali si intendono degli eventi in seguito ai quali per la cella none piu possibile sopportare il carico massimo, definito in fase di pianificazione.Questi eventi possono essere scatenati da diverse situazioni, sia dovute all’am-biente esterno che causate da scelte di progettazione della rete. Consideriamoad esempio il caso in cui un terminale mobile malfunzionante non rispon-da correttamente al controllo di potenza; esso iniziera a trasmettere ad unapotenza superiore a quella necessaria, generando interferenza in eccesso. Lerisorse a disposizione degli altri utenti saranno quindi ridotte. Questo scenariopuo essere modellato come un guasto parziale della cella, di intensita pari al-l’interferenza in eccesso generata dal terminale. Ancora, un’altra applicazionedei guasti parziali puo essere data dalla necessita di ridurre temporaneamenteil noise rise (e quindi il carico, in base alla formula 1.6), al fine di aumentarela copertura.

I guasti parziali possono essere modellati con delle piccole modifiche almodello cella e all’algoritmo di admission control. Innanzitutto, all’internodel nuovo modello BaseStation, il place Work contiene adesso un numeromassimo di 100 token, rappresentando cosı la percentuale di attivita dellastazione base. Di conseguenza, anche le transizioni di fallimento e riparazionedevono essere adeguate alla nuova rappresentazione dello stato della stazione


Figura 3.6: Modello parametrico per una cella, con l’aggiunta di guasti parziali(BaseStation)

base. Inoltre, nei moduli di interazione deve essere leggermente modificato ilmeccanismo di allocazione dei canali, in modo da tener conto dell’eventualedegradazione della cella. Il limite per l’admission control viene calcolato comepercentuale sul carico massimo pianificato, in base allo stato di attivita dellacella.

double dMaxDownlink = MaxLoad−>Downlink−>Mark ( ) *

Work−>Mark ( ) / 1 0 0 . 0 ;

double dMaxUplink = MaxLoad−>Uplink−>Mark ( ) *

Work−>Mark ( ) / 1 0 0 . 0 ;

Il modello cosı ottenuto, anche a seguito delle precedenti modifiche, si prestaad essere parametrizzato, utilizzando lo stesso procedimento adottato nel pa-ragrafo 3.4. Volendo modellare una rete che supporta tre diversi servizi, se siseleziona come parametri il tempo di fallimento, il tempo di ripristino, il cari-co massimo e la percentuale di degradazione si ottiene il modello parametricoriprodotto nella Figura 3.6.

3.7 Mobilita degli utenti

In previsione della necessita di far muovere gli utenti attraverso le celle, e sta-to necessario separare maggiormente la richiesta ed esecuzione di un serviziodall’allocazione delle risorse nelle stazioni base. La capacita di un utente dispostarsi rende infatti impossibile conoscere quante e quali celle saranno in

3.7 Mobilita degli utenti 51

grado di servirlo al momento di richiedere un servizio alla rete UMTS. Inol-tre, nello spostamento e verosimile che durante l’esecuzione di un servizio unutente si sposti dalla zona di copertura di una cella ad una di sovrapposizionetra piu celle, o viceversa. Queste situazioni rappresentano la normalita neisistemi di telefonia mobile e la capacita dei sistemi 3G di portare a termine ilservizio in modo trasparente, grazie al soft handover, e determinante. Per que-sto motivo, e stato necessario ripensare la suddivisione tra i moduli, astraendol’esecuzione del servizio dal tipo e numero di risorse a disposizione per sup-portarlo. Seguendo la nuova suddivisione a livello concettuale, si ottengonoquattro nuovi modelli, che sostituiscono i moduli utente e di interazione delmodello esistente:

� MovingUser

� Service

� ServiceManager

� ChannelSetup

Il modello MovingUser racchiude tutte le azioni relative all’utente, sia quelleriguardanti il suo spostamento che quelle per la richiesta dei servizi alla rete. Imodelli cosı creati, a differenza dei precedenti, sono relativi al comportamen-to di un singolo utente, mentre per descrivere sistemi piu ampi e necessarioutilizzare l’operazione di replica [16][14].

3.7.1 Posizionamento utente

Il posizionamento dell’utente all’interno della rete e realizzato dal modelloMovingUser (Figura 3.7). Una rete UMTS puo essere vista come una seriedi celle, con aree di copertura parzialmente sovrapposte. In base ai segnaliricevuti e alla loro potenza, l’area geografica che si vuole descrivere puo esseresuddivisa in una serie di zone, in ognuna delle quali predomina il segnale diuna o piu stazioni base. Come esempio, una rete dove sono attive due stazionibase, puo essere suddivisa in tre zone: ZoneA e ZoneB, dove il segnale di unasola cella e predominante, e ZoneAB, un’area di sovrapposizione dove i segnalidi entrambe le celle sono sufficientemente potenti ed e possibile trasmetterein soft handover.


Figura 3.7: Modello per un utente in movimento all’interno del sistema (MovingUser)

Per individuare il posizionamento dell’utente, ad ogni zona viene associatoun place, che contiene un token se l’utente si trova nella zona corrispondente.Una serie di transizioni tra le varie zone realizzano lo spostamento vero eproprio, togliendo il token dalla zona che l’utente sta lasciando per aggiungerneuno in quella di destinazione. La velocita di spostamento dell’utente e fattavariare cambiando il rate delle transizioni di spostamento. Inoltre, ogni voltache si verifica uno spostamento viene aggiunto un token in un particolareplace, chiamato Move, che segnala il cambiamento della zona di copertura e laconseguente necessita di verificare nuovamente la disponibilita delle risorse.

Per semplicita nello stesso modello e inclusa anche la parte di richiesta delservizio da parte dell’utente. Questa parte varia in base al comportamentodesiderato per l’utente: si puo pensare che un utente richieda con una certaprobabilita uno dei servizi disponibili (come nel modello in Figura 3.7), cherichieda ogni volta lo stesso servizio, che richieda una successione ben definitadi servizi, o altro ancora.

3.7.2 Richiesta ed esecuzione del servizio

La richiesta di un servizio da parte dell’utente viene presa in carico da unopportuno modello SAN, denominato Service (Figura 3.8). Il modello einizialmente in uno stato di attesa, determinato da un token posto nel pla-ce ServWait. Quando l’utente richiede il servizio, viene posto un token nelplace Req, facendo cosı scattare la transizione Process, che tramite il placeAskResources comunica al livello inferiore che sono necessarie delle risorseper l’esecuzione del servizio. La riposta avviene tramite i place AnswerOK, in


Figura 3.8: Modello di esecuzione di un servizio, indipendente dalle stazioni base cheforniscono le risorse necessarie (Service)

caso di esito positivo, e AnswerBlock in caso di esito negativo. Se sono dispo-nibili sufficienti risorse viene avviato il servizio, ponendo un token nel placeBegin, altrimenti si ha un fallimento e il modello passa nello stato Failed,dopo essersi assicurati di aver rilasciato eventuali risorse allocate e annulla-to ulteriori richieste, tramite il place Release. Se durante l’esecuzione delservizio si verifica uno spostamento dell’utente, notificato dalla presenza ditoken nel place Move, si ripete la procedura di richiesta di risorse, cioe vieneposto un token in AskResources. Se sono ancora disponibili sufficienti risorseil servizio prosegue senza interruzioni, altrimenti viene interrotto togliendo iltoken da Begin e il modello passa nello stato Dropped, dopo aver rilasciatotutte le risorse rimanenti. Una volta completato il servizio, vengono rilasciatetutte le risorse tramite il place Release, viene azzerato il place Req e vengonoripristinati i token in ServWait e Idle, riportando servizio e utente al lorostato iniziale. In fase di composizione viene istanziato un modello di questotipo per ogni servizio e il place Req viene fatto corrispondere ad uno dei placeReqN nel modello MovingUser.


3.7.3 Gestione risorse del servizio

Il modello ServiceManager intercetta la richiesta di risorse da parte del mo-dello Service, al livello superiore, e in base alla posizione dell’utente inoltrala domanda alle celle presenti nella zona, cercando di trasmettere in soft han-dover quando possibile. Il modello visualizzato nella Figura 3.9 si riferiscead una rete con due stazioni base. Con questo modello vengono condivisi iplace relativi alle zone del modello MovingUser, cosı da conoscere la posizionedell’utente.

La presenza di un token sia in Req che in AskResources indica che e ne-cessario assicurarsi della disponibilita delle risorse e permette alla transizioneAsk di scattare. In base alla zona occupata dall’utente, l’output gate di questatransizione aggiunge un token nel place PRACH X relativo alle celle interessate.La transizione SetupX scattando indica il completamento della procedura diaccesso, che puo concludersi con esito positivo o negativo. In caso di esitonegativo la procedura verra ripetuta dopo aver lasciato trascorrere un certointervallo di tempo. Se nessuna delle celle presenti nella zona utente forniscel’accesso, viene posto un token in AnswerBlock, segnalando cosı la mancanzadi risorse per eseguire il servizio. Quando la procedura di accesso ha inveceesito positivo, la transizione RequestX, tramite il suo output gate, richiede allacella il canale fisico appropriato. Un token nel place DoneX indica che la cellaha terminato l’elaborazione e la transizione Check scatta, controllando che visiano risorse necessarie all’esecuzione del servizio, ad esempio almeno due ca-nali in soft handover o un canale dedicato “normale”. In seguito al controlloviene eseguita, tramite la transizione Adjust, una procedura che assicura chesiano utilizzate sempre il minor numero di risorse possibili. Se ad esempio siha un canale normale e uno in soft handover allocati, si fa in modo di con-vertire anche l’altro in soft handover. Infine, la transizione RelChannels fa inmodo di chiedere il rilascio delle risorse a tutte le celle, una volta ricevuto ilsegnale da parte del modello Service. Se si verificano degli spostamenti, puosuccedere di avere gia a disposizione dei canali allo scattare della transizioneAsk; in tal caso la parte della procedura di accesso viene saltata e il tokenposto direttamente nel place RachOKX per la stazione base interessata. Nelcaso si verifichi il guasto di una delle celle coinvolte nel servizio, sara necessa-rio cercare di far proseguire la comunicazione tramite le altre stazioni base equesto lavoro viene svolto dalla transizione TryRecover.


Figura 3.9: Modello di gestione del servizio per una rete con due celle (ServiceManager)

3.7.4 Gestione risorse della cella

Il modello ChannelSetup si occupa semplicemente di allocare e rilasciarei canali su di una cella, per un certo utente. Esso riceve i comandi dalmodello ServiceManager, attraverso i place GetChannel, GetChannelSHO eUnloadChannel. Un tipo di collegamento esclude l’altro, ovvero l’allocazionedi un canale in soft handover implica il rilascio di un eventuale canale normalegia allocato, e viceversa. Inoltre, se e gia stato allocato un canale dello stessotipo, ogni nuova richiesta verra ignorata, in modo da avere sempre al massimoun canale allocato per utente, su una determinata cella. Per questo motivo,per assicurarsi di avere ancora a disposizione un canale o per chiederne unonuovo si utilizzano le stesse azioni. I canali, anch’essi condivisi con il modelloServiceManager, vengono allocati tenendo conto del carico del servizio, delcarico della cella, del carico massimo accettabile nonche dello stato di attivitadella cella stessa, come in 3.6. Ogni volta che viene allocato o rilasciato uncanale inoltre, viene aggiornato anche il corrispondente contatore, condivisocon il modulo cella. In caso di guasto della cella, segnalato tramite i placeOutage e OutageSHO, che indicano il numero di utenti scartati dalla stazio-ne base, vengono rilasciati i canali utente dedicati e si aggiunge un token inRecover, invitando il modello ServiceManager a tentare di far proseguire ilservizio.


Figura 3.10: Modello per l’allocazione dei canali dedicati (ChannelSetup)

3.8 Generalizzazione della mobilita

Il modello cosı concepito, ha come difetto la ridotta scalabilita nei confrontidel numero di celle. Infatti, il modello ServiceManager descritto nel paragrafo3.7.3 rappresenta solamente il caso in cui le celle coinvolte nella sovrapposizio-ne siano due. Per modellare una rete con un maggior numero di stazioni basee zone di sovrapposizione, andrebbe creato un modello sempre piu complessocon l’aumentare del numero di celle coinvolte. Utilizzando lo stesso approccioche abbiamo avuto con il modello originale, sarebbe ideale riuscire a scom-porre trasversalmente i modelli fin qui ottenuti, individuando parti che hannocomportamenti simili.

Osservando il modello ServiceManager in Figura 3.9, si notano delle si-militudini nel meccanismo di esecuzione della procedura di accesso delle duecelle e nella successiva richiesta di canali dedicati. Per ognuna delle due celleinfatti, il flusso di azioni da eseguire e lo stesso e si ha solo un cambiamentodei place interessati. Tenendo presenti queste considerazioni, si puo quindipensare di suddividere diversamente i modelli fin qui ottenuti, creando unmodello atomico che esegua la procedura di accesso e la richiesta canali diuna cella generica e modificando il modello di gestione in modo adeguato. In

3.8 Generalizzazione della mobilita 57

questo modo per ogni nuova cella non si farebbe altro che istanziare un nuovomodello gestione delle risorse e ancora una volta si risparmierebbe di duplicarecodice manualmente.

Nei prossimi paragrafi viene presentata questa riorganizzazione del model-lo, con lo scopo di renderlo piu scalabile rispetto al numero di stazioni basepresenti nel sistema. Il modello che si vuole ottenere ha lo stesso comporta-mento di quello fin qui descritto, ma non e legato ad un numero particolaredi stazioni base.

3.8.1 Modello scalabile per il movimento

Aumentando il numero di stazioni base presenti nel sistema, il numero di zonecresce in modo esponenziale, rendendo rapidamente ingestibile il posiziona-mento dell’utente tramite questo metodo, specialmente nella fase di richiestadelle risorse. La versione scalabile prevede di utilizzare un unico place perogni cella presente nel sistema: questo place, denominato SignalX, contieneun token se l’utente si trova in una zona raggiunta dal segnale della cella X.In questo caso, ad esempio, la zona di sovrapposizione tra le stazioni A e B erappresentata da un token in SignalA e uno in SignalB.

Per chiarezza, il modello per l’utente viene adesso suddiviso in due parti,una adibita alla richiesta dei servizi e una che realizza il movimento.

Richiesta servizio

Il modello User realizza la richiesta del servizio da parte dell’utente, e sioccupa inoltre di assegnargli una posizione iniziale, che in generale cambiaper ogni scenario che si vuole rappresentare. Solitamente, un place condivisocon il modello Startup contiene il numero di utenti che dovranno iniziare dauna determinata zona e una transizione all’interno di ciascun modello User,creata per scattare una sola volta, esegue l’inizializzazione.

Movimento utente

Un modulo denominato UserMovement modellizza lo spostamento dell’uten-te da una zona all’altra. Lo spostamento puo essere visto sia come semplicitransizioni che alterano lo stato dei place SignalX a intervalli di tempo pre-stabiliti, sia come transizioni tra diverse zone, come nella versione precedente.Nel secondo caso, ogni spostamento deve convertire il significato di zona con


Figura 3.11: Modello per il movimento dell’utente attraverso quattro stazioni base(UserMovement)

la rappresentazione mediante place Signal (Figura 3.11). Se a prima vistapuo sembrare un controsenso passare a questa nuova rappresentazione perpoi utilizzare nuovamente le zone, l’efficacia dei place Signal viene avvertitapienamente solo nella creazione del nuovo modello di gestione del servizio.

3.8.2 Modello scalabile per la gestione del servizio

La creazione di un modello scalabile rende necessario comunicare a tutti imodelli cella lo stesso messaggio, delegando a questi di verificare se la cel-la che rappresentano e nelle condizioni di fornire il servizio all’utente che loha richiesto. Questo modello e strutturato in modo da funzionare esatta-mente allo stesso modo qualsiasi sia il numero di celle coinvolte; in questomodo aggiungere una nuova stazione base al sistema non comporta partico-lari modifiche, se non quella di includerla nel modello composto. Osservandoil nuovo modello ServiceManager in Figura 3.12, si notano molte analogiecon la vecchia versione. Le attivita Ask, Check, TryRecover e RelChannels

hanno sostanzialmente lo stesso significato, anche se operano in modo legger-mente diverso. TryRecover e Check funzionano infatti controllando il valoredei place ServChannels e ServChannelsSHO, che sono dei contatori del nu-mero di canali, normali e in soft handover, allocati al servizio. Le transizioniAsk, TryRecover e Release alla loro esecuzione comunicano a tutti i modellicella la necessita di eseguire la determinata operazione, ponendo nel place a

3.8 Generalizzazione della mobilita 59

Figura 3.12: Modello scalabile per la gestione di un servizio (ServiceManager)

loro relativo un numero di token pari al valore di CellCount, che contiene ilnumero totale di stazioni base presenti nel sistema.

Una variabile globale, DisableHandover, permette inoltre di disabilitarela funzione di soft handover. In tal caso, la transizione SelRandom ha lo scopodi selezionare casualmente una cella per l’esecuzione del servizio. La transi-zione Check esegue il controllo delle risorse, ogni volta che e presente almenoun token in Done. Il place WaitTokens e un dettaglio di implementazione eindica quante celle attendere prima di dichiarare di non avere sufficienti risor-se, tramite AnswerBlock. Normalmente questo valore e impostato al valoredi CellCount, mentre disabilitando il soft handover viene posto a uno.

3.8.3 Modello scalabile per la gestione delle risorse di una

stazione base

Nel modulo CellManager (Figura 3.13) confluiscono il modello ChannelSetup

e parte del vecchio ServiceManager. In particolare come gia accennato, laparte di esecuzione della procedura di accesso e di richiesta delle risorse eidentica per tutte le celle coinvolte, qualsiasi sia il loro numero. Per questomotivo quella porzione di SAN trova la giusta collocazione in questo modello,di cui viene creata un’istanza per ogni stazione in grado di fornire il servizio.Al livello superiore, il modello di gestione del servizio invia adesso lo stessomessaggio a tutti i modelli CellManager, dopodiche e quest’ultimo a deciderese la stazione che rappresenta puo fornire il servizio, anche in base al valore


Figura 3.13: Modello per la gestione delle risorse di una cella (CellManager)

del place Signal.Per via di questa nuova configurazione alcune porzioni sono leggermente

modificate, ma altre sono rimaste sostanzialmente intatte, come la parte digestione dei guasti o l’esecuzione della procedura di accesso. Tra le novita,oltre al place Signal, vi e la transizione GetIndex e i place associati ad essa.Questa transizione serve per assegnare un indice al modello, al fine di distin-guerlo dagli altri, e per fornire al modello ServiceManager un’informazionesul numero di istanze presenti, tramite il place CellCount.

In AskCells vengono posti inizialmente un numero di token pari al totaledelle celle presenti. Per ogni singolo modello la transizione scatta quando ilvalore corrisponde al proprio indice, togliendo un token come conseguenza.In questo modo si e sicuri che tutte i modelli eseguiranno la transizione unaed una sola volta. Lo stesso principio vale anche per le altre transizioni,TryRecover, Adjust, Release e CellSelected. Quest’ultima transizione,cosı i place e i gate ad essa associati, servono per la selezione casuale di unacella in caso di disabilitazione del soft handover.

Viene inoltre introdotta una nuova variabile globale, MaxSHOLinks, che in-dica il massimo numero di connessioni in soft handover simultanee. Normal-mente questo valore viene impostato a due connessioni massime. Impostandoun numero maggiore si dovrebbe anche definire un carico per la connessionein soft handover con tre o piu celle, se si ritiene debba essere diverso da quelloin soft handover tra due sole stazioni.

3.9 Il modello finale 61

Figura 3.14: Corrispondenza tra i componenti del modello di partenza e quelli delmodello ottenuto dopo le modifiche

3.9 Il modello finale

Le modifiche apportate al modello esistente hanno portato ad una diversa sud-divisione delle funzionalita della rete UMTS, utilizzando piu livelli di astrazio-ne. I modelli atomici ottenuti incorporano comunque parti della struttura diquelli originali e siamo quindi in grado di trovare delle corrispondenze, eviden-ziate nella Figura 3.14. Il modello BaseStation e infatti ricavato dal moduloCella iniziale, considerando solamente la parte relativa allo stato di funzio-namento e al controllo di congestione, mentre l’allocazione dei canali formauna parte del modello CellManager. Quest’ultimo viene completato da unaparte dei modelli GestioneUtente e GestioneUtenteSHO, le cui funzioni sonosuddivise tra ServiceManager e CellManager. Il modello Service e ricavatodai precedenti moduli Utente e UtenteSHO, isolando la parte relativa all’ese-cuzione del servizio, mentre le parti rimanenti di questi due modelli vanno aformare il modello User. Il modello UserMovement e completamente nuovoe costituisce la parte relativa al movimento degli utenti. Occorre precisareche queste corrispondenze sono valide maggiormente ad un livello concettualepiuttosto che implementativo, visto che alcuni moduli rappresentano adessoil comportamento di un solo utente e devono percio essere replicati, comedescritto nella prossima sezione.

3.9.1 Composizione

Il modello finale della rete UMTS viene realizzato componendo i precedentimodelli SAN secondo uno schema ben preciso:

� Partendo dal basso, un primo livello di composizione vede un join perogni servizio che si desidera modellizzare. Ciascuno di questi e costitui-to da un’istanza del modulo Service (3.7.2), una di ServiceManager(3.8.2) e alcune di CellManager (3.8.3), una per ciascuna stazione base


presente nella rete. Oltre a condividere i place con lo stesso nome, in fasedi definizione del join si devono effettuare delle rinominazioni, in mododa distinguere ciascun modello CellManager dagli altri nella composi-zione ai livelli superiori. Per questo motivo, ad esempio, il place Signal

diviene SignalA in CellManagerA1 e SignalB in CellManagerA2. Allostesso modo nel modello CellManagerA1, i place Channel e ChannelSHOvengono rinominati in ChannelA1 e ChannelSHO A1, e cosı via.

� I prodotti di questi join vengono successivamente uniti tra loro, assiemeai modelli User (3.8.1) e UserMovement (3.8.1). Anche in questo caso,si devono effettuare delle rinominazioni. Ad esempio, e probabile che ladurata sia differente per ciascun servizio; in tal caso e necessario rinomi-nare i vari place ServiceTime in ServiceTime1, ServiceTime2, e cosıvia, anziche metterli in corrispondenza tra loro. Lo stesso ragionamentodeve essere fatto per i place che rappresentano il fattore di carico deiservizi.

� Il modello cosı ottenuto rappresenta un unico utente e deve quindi essereutilizzato l’operatore di rep, che permette di replicare la composizionefin qui ottenuta per rappresentare un certo numero di utenti. Ognuno diquesti utenti condividera i canali contatori e tutti gli altri place relativialle celle, come ad esempio il carico o il place Work che rappresenta lostato di attivita di una stazione base. Anche i vari parametri, come ladurata del servizio e il carico apportato alle celle viene condiviso tramitel’operatore di replica. Il numero di repliche da effettuare e dato da unavariabile globale, MaxUsers.

� L’ultimo livello di join prevede l’unione della replica con il modello diinizializzazione (Startup, 3.4.4) e un modello BaseStation (3.6) perogni stazione base che si desidera rappresentare.

In Figura 3.15 viene riportato un esempio di modello composto. Esso descriveuna rete UMTS in cui sono attive quattro stazioni base e in cui gli utentipossono richiedere due diversi servizi. I dettagli di implementazione dei singolimodelli sono riportati in Appendice A.

3.10 Variabili di Reward 63

Figura 3.15: Composizione dei modelli atomici, per una rete UMTS formata da quattrostazioni base, che forniscono due servizi

3.10 Variabili di Reward

Questa sezione descrive come ricavare le misure di interesse specificate nel-la sezione 3.2 e per facilitare il riferimento viene mantenuta la numerazioneutilizzata in precedenza.

3.10.1 Carico di una stazione base

Il carico sulla tratta uplink o downlink di una stazione base puo essere rica-vato semplicemente dal place LoadFactor del modello BaseStation. In basealla tratta che si vuole misurare infatti, e sufficiente definire una variabiledi guadagno che come funzione restituisce il valore del relativo campo dellastruttura Workload. Se ad esempio ci interessa il carico sulla tratta downlinkdella stazione base A, defineremo una variabile che ha la seguente funzione diguadagno:

return BaseStationA−>LoadFactor−>Downlink−>Mark();

e similmente per la tratta uplink:

return BaseStationA−>LoadFactor−>Uplink−>Mark();


3.10.2 Numero di canali dedicati

Questo valore puo essere ottenuto, per ogni singolo servizio, definendo unavariabile di guadagno che nella sua funzione restituisce il valore del placeChannelCount del relativo servizio, nulla cella a cui siamo interessati. Siricorda che i place contatore sono due per ciascun servizio, uno per i canalinormali e uno per quelli in soft handover, percio se si desidera misurare ilnumero totale di utenti serviti dalla stazione base per un determinato servizio,dovremo sommare le due quantita nella funzione di guadagno:

return BaseStationA−>ChannelCount1−>Mark() +

BaseStationA−>ChannelCountSHO 1−>Mark();

Se invece si desidera calcolare il numero totale di utenti serviti dalla stazionebase, si puo definire una variabile che sommi i canali contatore di tutti i serviziforniti dalla cella, oppure si possono sommare successivamente i valori ottenutiper ogni singolo servizio.

3.10.3 Numero di canali in soft handover

In modo simile, il numero di canali in soft handover allocati da una cella perun servizio puo essere ricavato definendo una variabile che nella sua funzionerestituisca il valore del place ChannelCountSHO relativo al servizio considerato.

3.10.4 Numero totale di utenti in soft handover

Il numero totale di utenti connessi in soft handover all’interno del sistema puoessere ricavato definendo una variabile di guadagno che accumuli il valore 1.0se il place ServChannelsSHO contiene almeno due token:

if (Service1−>ServChannels−>Mark() >= 2)

{return 1.0;

}

oppure anche, in modo piu conciso:

return (Service1−>ServChannels−>Mark() >= 2);

Ancora una volta, per ricavare il valore complessivo di tutti i servizi e suffi-ciente sommare i risultati ottenuti per i singoli servizi.

3.10 Variabili di Reward 65

3.10.5 Throughput

Il throughput di una stazione base su una delle due tratte, in un determina-to istante oppure allo steady-state, puo essere ricavato dal numero di canaliallocati. Moltiplicando il numero di canali allocati a ciascun servizio per lasua velocita di trasferimento nominale e sommando successivamente i valoriottenuti abbiamo il valore cercato.

3.10.6 Probabilita di fallimento

La probabilita di fallimento di una richiesta di connessione da parte dell’u-tente puo essere calcolata come il rapporto tra il numero di esecuzioni dellatransizione di fallimento e il numero di esecuzioni della transizione di richiesta,rispettivamente Fail e Process, entrambe nel modello Service. Definiamoquindi due variabili di impulso che accumulano il valore 1.0 quando scattala transizione associata. Se chiamiamo queste due variabili NumFail per ilfallimento e NumReq per la richiesta, la probabilita di fallimento puo esserericavata come rapporto tra queste due quantita:

P [fallimento] =NumFail

NumReq.

Ancora una volta, il risultato che si ottiene e valido per il singolo servizio, sesi desidera quello globale del sistema si possono sommare tra di loro i valoridi NumFail ottenuti dai vari modelli, cosı come quelli di NumReq, e calcolaresuccessivamente il rapporto tra i due totali. Si puo ottenere lo stesso risultatoanche scegliendo di definire le variabili di guadagno NumFail e NumReq inmodo da operare attraverso tutti i modelli Service, ma nel nostro caso questascelta rallenta molto l’esecuzione della simulazione. Infatti, nel caso venganodefinite variabili di guadagno su piu modelli atomici e questi vengano replicatinel modello composto, Mobius valuta la variabile una volta per ogni possibilecoppia di modelli atomici diversi, fra le repliche di quelli selezionati [14]. Nelnostro modello si ha una replica per ogni utente e quindi anche solamente con10 utenti e 3 servizi il simulatore dovrebbe valutare la variabile ben 310 volte.

3.10.7 Probabilita di interruzione

La probabilita che un servizio utente venga interrotto puo essere calcolatain modo simile a quanto fatto per la probabilita di fallimento. Ancora una


volta definiamo due variabili di impulso, una per la transizione di interruzio-ne del servizio e una per il corretto completamento, rispettivamente Drop eServiceFinished, entrambe nel modello Service. In questo caso il numerodi casi possbili e dato dalla somma dei servizi interrotti e completati, mentrei casi utili sono rappresentati dal numero di servizi interrotti. Identificandocon NumDrop il numero di interruzioni e con NumServed i servizi correttamentecompletati, la probabilita di interruzione e quindi data da:

P [interruzione] =NumDrop

NumDrop + NumServed.

3.10.8 Livello di insoddisfazione dell’utente

Il livello di insoddisfazione dell’utente viene misurato come la probabilita ditrovarsi in uno stato di attesa in conseguenza al fallimento o all’interruzionedi un servizio. Questa e una misura relativa ed e percio influenzata da moltifattori, come il tempo di servizio o di inattivita dell’utente. A pari condizioniinfatti un utente con un tempo di inattivita piu elevato avra una probabilita diinsoddisfazione minore semplicemente perche le sue richieste di servizio sonomeno frequenti. Questo e accettabile per quanto riguarda la misura, infatti unutente che utilizza meno spesso la rete sara disposto ad attendere un tempomaggiore, o comunque sara infastidito di meno dall’attesa. Basta pensaread un’attesa di 30 secondi nel caso di due utenti, uno che effettua chiamatemediamente ogni 5 minuti e l’altro che utilizza la rete in media una volta ogniora: l’insoddisfazione percepita dal primo sara sicuramente maggiore. Permisurare questa quantia viene definita una variabile di guadagno che accumulail valore 1.0 quando e presente un token in uno dei place Dropped o Failed

del modello Service. Con l’operatore di replica le variabili vengono valutateper ogni utente, quindi e necessario dividere per il numero totale di repliche,dato dalla variabile globale MaxUsers:

if (Service1−>Failed−>Mark() > 0 || Service1−>Dropped−>Mark() > 0)

{return 1.0/MaxUsers;

}

Capitolo 4

Valutazione numerica

4.1 Introduzione

In questo capitolo vengono analizzate le prestazioni di una rete UMTS, intermini di QoS percepita dagli utenti e dal gestore telefonico. La valutazionee stata eseguita in diversi scenari, con possibilita o meno per l’utente di spo-starsi dalla sua posizione iniziale, concentrando comunque l’attenzione sullafunzione di soft handover. I risultati sono stati ottenuti risolvendo, tramitesimulazione, il modello descritto nel capitolo precedente, che viene di voltain volto composto in modo opportuno, in base allo scenario che si vuole rap-presentare. Ciascuna misura ha un livello di confidenza del 95%, su di unintervallo di confidenza relativo pari a 0.05.

4.1.1 Parametri di esecuzione

L’ambiente analizzato e quello di una rete UMTS macrocellulare, che utilizzaun’unica portante FDD per tutti i collegamenti. Il noise rise massimo consen-tito, generato dai canali dedicati, e fissato a 7 dB per la tratta downlink e 4.5dB per la tratta uplink, che corrispondono ad un fattore di carico massimo paria 80% e 65%, rispettivamente. I parametri di esecuzione del simulatore sono ingran parte comuni ai diversi esperimenti e, dove non specificato diversamente,assumono i valori riportati nella Tabella 4.1. Il parametro MaxSHOLinks indicail numero massimo di connessioni in soft handover consentite per ogni utente,ovvero il numero di stazioni base che e possibile utilizzare contemporanea-mente per l’esecuzione di un servizio. OutagePercent indica la percentualedi degradazione della capacita di una cella in caso di guasto, e viene azzerato

67

68 Capitolo 4: Valutazione numerica

Parametro Descrizione Valore

MaxSHOLinks Connessioni in soft handover massime per utente 2OutagePercent Percentuale di degradazione della cella in caso di guasto

(0 = nessun guasto)100

MaxDownlink Carico massimo downlink 0.8MaxUplink Carico massimo uplink 0.65pFail Probabilita di fallimento della procedura di accesso 0.1tIdle Tempo di inattivita dell’utente 400 stBlock Intervallo richiesta in caso di blocco 50 stDrop Intervallo richiesta in caso di scarto 50 stSetup Tempo procedura di accesso e setup radio bearer 1 stRachDelay Tempo di attesa in caso di fallimento della procedura di

accesso casuale5 s

Tabella 4.1: Alcuni parametri di esecuzione del simulatore, con il corrispondente valoreutilizzato nella maggior parte degli esperimenti

nel caso in cui non si vogliano considerare i guasti nelle stazioni base.Per quanto riguarda i servizi, nelle valutazioni riportate nei prossimi para-

grafi sono state considerate tre tipiche classi di servizio, in modo da formareuna delle possibili configurazioni di rete UMTS. Ciascuna tipologia di servi-zio utilizza un collegamento radio con caratteristiche diverse, eventualmentediverse per downlink e uplink, secondo quanto suggerito in [2].

I parametri per il calcolo dei corrispondenti fattori di carico (paragrafo1.2.5) sono riportati nella Tabella 4.2. Per i collegamenti in soft handoverviene ipotizzata una riduzione del valore di Eb/N0 necessario per raggiungerela stessa qualita di servizio [8]. Il loro carico viene percio calcolato diminuendoil rapporto Eb/N0 di base di una quantita fissa, conosciuta come soft handovergain, guadagno di soft handover.

4.2 Utenti statici

La prima serie di valutazioni considera una popolazione di utenti statici, cherimangono posizionati nella stessa zona di copertura per tutta la durata dellasimulazione. Tramite questa prima sequenza di esperimenti possiamo verifi-care la generalita del modello ottenuto e accertarsi che esso sia effettivamenteun’estensione di [5].

4.2 Utenti statici 69

Servizio1 Servizio2 Servizio3

Classe Conversazionale Streaming Background

Throughput (R)Downlink

12.2 Kbit/s 57.6 Kbit/s384 Kbit/s

Uplink 64 Kbit/s

Chiprate W 3.84 Mcp/s 3.84 Mcp/s 3.84 Mcp/sOrtogonalita α 0.7 0.7 0.7Fattore di attivita υ 0.67 1 1Interferenza i 0.55 0.55 0.55

Eb/N0Downlink 7.5 dB 5.5 dB 3 dB

Uplink 5 dB 4 dB 2.5 dB

Carico (∆L)Downlink 0.01357 0.08774 0.21250

Uplink 0.01632 0.06675 0.06200

Carico con Soft Handover

SHO Gain = 1 dBDownlink 0.01176 0.06675 0.12750

Uplink 0.01309 0.04515 0.03781

SHO Gain = 1.5 dBDownlink 0.01086 0.05603

—Uplink 0.01146 0.03411

SHO Gain = 2 dBDownlink 0.00995

— —Uplink 0.00984

Tabella 4.2: Parametri utilizzati per il calcolo del fattore di carico

4.2.1 Scenario 1

Questo scenario analizza una rete formata da due stazioni base con aree dicopertura parzialmente sovrapposte (Figura 4.1) e una popolazione di utentiche richiedono il solo servizio voce (Servizio1). Si suppone che le due cellecontengano lo stesso numero di utenti, distribuiti uniformemente all’internodell’area di copertura, gli utenti nella zona di sovrapposizione siano il 20%rispetto a quelli raggiunti da una sola stazione base.Il numero di utenti presenti nel sistema

UtentiA 10 20 . . . 200

UtentiAB 4 8 . . . 80

UtentiB 10 20 . . . 200

Utenti Totali 24 48 . . . 480

viene fatto aumentare progressivamente,registrando il comportamento del sistemaa steady-state. Le misure di interesse so-no in questo caso rappresentate dal caricodelle celle coinvolte e dal numero di canali allocati, con particolare interesseagli utenti nell’area di sovrapposizione.

Come era lecito aspettarsi, il carico di entrambe le celle cresce in relazioneal numero di utenti presenti nel sistema, fino a raggiungere la sua capacitamassima. Poiche il numero di utenti e lo stesso in entrambe le celle, essesi comportano esattamente allo stesso modo e il loro carico ha l’andamento


Figura 4.1: Disposizione delle due stazioni base A e B e sovrapposizione dei loro segnali

0

0.2

0.4

0.6

0.8

1

0 20 40 60 80 100 120 140 160 180 200

Fat

tore

di c

aric

o

Utenti presenti nell’area di copertura di ciascuna cella

Downlink AUplink A

Carico Massimo DownlinkCarico Massimo Uplink

Figura 4.2: Carico della cella A, al crescere del numero di utenti

riportato nella Figura 4.2, relativa alla stazione base A.Vista la loro stretta correlazione con il carico delle celle, anche il numero

di canali dedicati allocati in ciascuna stazione base cresce progressivamentefino al raggiungimento di un valore limite. Un risultato interessante si hase si considera invece solamente le connessioni in soft handover. Come sivede nella Figura 4.3 infatti, esse tendono ad aumentare soltanto fino ad uncerto punto, per poi decrescere rapidamente quando il sistema comincia asovraccaricarsi, appiattendosi vicino allo zero. Quando il numero di utenticomincia ad essere troppo elevato, infatti, il sistema trascorre gran parte delsuo tempo vicino alla propria capacita limite ed e sempre piu difficile per unutente ottenere un canale da entrambe le celle. Come conseguenza, semprepiu utenti vengono serviti solamente da una delle due stazioni, pur trovandosinella zona di sovrapposizione dei segnali (Figura 4.4).

Questo comportamento e ancora piu evidente nella Figura 4.5, nella qualeviene visualizzata la percentuale di collegamenti effettivamente in soft hando-


0

10

20

30

40

50

0 20 40 60 80 100 120 140 160 180 200

Can

ali a

lloca

ti


Cella A (Normali)Cella B (Normali)

Soft Handover

Figura 4.3: Numero di canali allocati, al crescere del numero di utenti

0

2

4

6

8

10

0 20 40 60 80 100 120 140 160 180 200Can

ali a

lloca

ti ne

ll’ar

ea d

i sov

rapp

osiz

ione


Soft HandoverSolo ASolo B

Figura 4.4: Canali allocati agli utenti nella zona di sovrapposizione delle due celle

ver rispetto al totale di quelli che avvengono nell’area di sovrapposizione delsegnale delle due stazioni base.

I risultati cosı ottenuti ci ricordano che il dimensionamento della rete eimportante in fase di progettazione, per sfruttare al meglio le potenzialitadel sistema W-CDMA. Se vogliamo far sı che il soft handover sia sfruttatoappieno e necessario prevedere un numero di celle adeguato alla popolazionedi utenti prevista, per far sı che non si verifichino situazioni di questo tipo.

4.2.2 Scenario 2

Il secondo scenario analizza l’efficacia dell’handover nella riduzione della pro-babilita di fallimento. Anche in questo caso viene presa in considerazione


10

20

30

40

50

60

70

80

90

100

0 20 40 60 80 100 120 140 160 180 200

Han

dove

r su

l tot

ale

dei c

olle

gam

enti

(%)


Handover Riusciti

Figura 4.5: Percentuale di trasmissioni in soft handover, sul totale degli utenti nellazona di sovrapposizione

una popolazione di utenti statici, che richiede il solo servizio di telefonia(Servizio1). In particolare, si vuole evidenziare il guadagno dovuto alla “ri-dondanza” che si acquisisce trovandosi in una zona coperta da piu celle. Ilparametro su cui e incentrato questo scenario e pFail, ovvero la probabilitadi fallimento della procedura di accesso casuale (paragrafo 1.5.1).Questo esperimento si suddivide in tre parti:

1. nella prima parte viene variata la probabilita di fallimento della pro-cedura di accesso casuale, registrando la probabilita di fallimento dellarichiesta di servizio nel caso della presenza di un diverso numero distazioni base;

2. successivamente, viene ripetuto l’esperimento considerando l’area di so-vrapposizione di due stazioni base, mostrando la differenza fra soft han-dover abilitato e disabilitato;

3. come ultima valutazione viene considerata una situazione di sovracca-rico e si controlla la probabilita di fallimento, sotto diverse ipotesi diguadagno di soft handover.

La prima parte di questo esperimento (Figura 4.6) mostra come si abbia ef-fettivamente un beneficio nel trovarsi in un’area raggiunta da piu stazionibase. In particolare, nel caso di una sola cella, la probabilita di fallimento haun’andamento lineare rispetto alla probabilita di fallimento della proceduradi accesso, mentre aumentando il numero di stazioni base coinvolte si ha una


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Pro

babi

lità

di fa

llim

ento

del

laric

hies

ta d

i ser

vizi

o ut

ente

Probabilità di successo dellaprocedura RACH su una singola cella

50 Utenti

1 Cella2 Celle3 Celle

Figura 4.6: Probabilita di fallimento al variare di pFail, in zone con un diverso numerodi stazioni base

probabilita sempre maggiore che l’utente riesca ad avviare il servizio. Questocomportamento e dovuto semplicemente al fatto che, nel caso di piu celle,si ha un fallimento solamente nel caso che nessuna sia in grado di accettarel’utente.

La probabilita di successo della procedura di accesso casuale dipende davari fattori, tra cui vi e anche la possibilita da parte del gestore di assegnaredelle precedenze fra i vari servizi, assegnando un diverso numero di slot a cia-scuno [15]. Grazie all’utilizzo del soft handover, un gestore puo permettersi disacrificare alcuni servizi meno importanti, assegnando loro una bassa proba-bilita di accesso su una singola cella, sapendo che comunque la probabilita diesecuzione del servizio percepita dall’utente sara maggiore, grazie al utilizzodi piu stazioni base.

Nella seconda parte viene presa in considerazione una zona coperta dadue celle, esaminando le differenze tra una situazione normale e il caso incui la funzione di soft handover e disabilitata. I risultati, riportati in Figura4.7, mostrano come, disabilitando il soft handover, si venga ricondotti in unasituazione paragonabile a quella dove l’utente e raggiunto da una sola stazionebase. Anche in questo caso infatti la probabilita di fallimento ha un andamentolineare rispetto al parametro pFail.

In base ai risultati fin qui ottenuti sembrerebbe che l’utilizzo del soft han-dover porti sempre ad una riduzione dei fallimenti per quanto riguarda le ri-chieste di servizio. La terza ed ultima parte di questo scenario invece ci mostrache non e in realta sempre cosı. Se consideriamo una situazione di sovracca-


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Pro

babi

lità

di fa

llim

ento

del

laric

hies

ta d

i ser

vizi

o ut

ente


50 Utenti, 2 Celle

NormaleSHO Disabilitato

Figura 4.7: Probabilita di fallimento al variare di pFail, nell’area di sovrapposizionedi due stazioni base, con e senza soft handover

rico, cioe una configurazione per la quale le richieste degli utenti superanola capacita delle celle coinvolte, gioca un ruolo importante il carico generatodalle connessioni in handover tra piu celle. Verrebbe immediato pensare cheun terminale connesso in soft handover tra due stazioni basi generi su ciascunaun carico pari alla meta di quello generato da una connessione normale, men-tre esso dipende da vari fattori, fra i quali la posizione dell’utente rispetto altrasmettitore, che non lo rendono facilmente calcolabile. Tale situazione poi edel tutto inverosimile, considerando che in situazioni reali si ha in media unoverhead dovuto al soft handover del 20% circa, che si traduce in un’aumentodell’interferenza totale sull’interfaccia radio. Scenari piu verosimili si ottengo-no utilizzando un carico in soft handover calcolato ipotizzando un guadagnosul rapporto Eb/N0 del collegamento (paragrafo 4.1.1).

Se si considerano situazioni di carico elevato, la probabilita di fallimentodel servizio e influenzata non solo da pFail, ma anche dal sovraccarico dellestazioni base che rende sempre piu difficile ottenere un canale dedicato. Laprobabilita che vi sia un canale dedicato disponibile e influenzata anche dal-l’overhead generato dal soft handover. Causando una maggiore interferenzainfatti, si riducono le risorse a disposizione degli altri utenti, escludendoneun numero maggiore. In base all’entita dell’overhead e alla probabilita difallimento della procedura di accesso, si puo arrivare anche ad annullare ilbeneficio dell’handover, in termini di probabilita di fallimento.

La Figura 4.8 mostra un esempio, nel quale sono riportate le probabilita difallimento di una popolazione di 150 utenti in un’area coperta da due stazioni

4.3 Guasti parziali 75

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Pro

babi

lità

di fa

llim

ento

del

laric

hies

ta d

i ser

vizi

o ut

ente


150 Utenti

Gain = 2 dBGain = 1.5 dB

Gain = 1 dBSHO Disabilitato

ηsho = η/2

Figura 4.8: Probabilita di fallimento in una situazione di sovraccarico, sotto diverseipotesi di carico in soft handover

base, considerando diverse ipotesi di carico per l’handover e infine disabilitan-dolo completamente. La curva piu bassa mostra il caso in cui non vi e alcunsovraccarico, ovvero il caso in cui si considera il carico in soft handover comela meta di una connessione normale. Questo e il caso migliore e rispecchiainfatti i valori ottenuti nei due precedenti casi con un basso numero di utenti.Aumentando progressivamente il carico per il soft handover, si ha un aumentodella probabilita di fallimento delle richieste degli utenti, fino a superare ilvalore ottenuto disabilitando la funzione di handover. In particolare questosuccede quando la probabilita di successo della procedura di accesso e alta:e in questo caso infatti che le stazioni base lavorano piu vicine al loro limitemassimo. Se la procedura di accesso fallisce molto spesso invece, il livellodel carico rimane basso perche gran parte delle richieste vengono rifiutate ela probabilita di fallimento e maggiormente influenzata dal fallimento dellaprocedura RACH che dal livello di carico sulle stazioni base.

4.3 Guasti parziali

In questa sezione consideriamo una valutazione che utilizzi la nuova possibilitadi avere dei guasti parziali per una stazione base. La valutazione mostra ilfunzionamento degradato di una stazione base e gli effetti sul resto del sistema.


4.3.1 Scenario 1

Questo scenario analizza una’area locale composta da due stazioni base conaree di copertura sovrapposte e un numero costante di utenti nella zona di so-vrapposizione dei segnali radio. Analizziamo una situazione in cui vi siano 50utenti all’interno del sistema, tutti situati nella zona di sovrapposizione. Que-sto signfica che sono tutti in grado di ricevere il segnale di entrambe le stazioniradio, ad esempio perche esse sono molto vicine tra loro, come puo accadere inun ambiente urbano o indoor. Supponiamo inoltre che gli utenti siano capacidi richiedere tre diverse tipologie di servizio: Servizio1, Servizio2 e Servizio3, icui parametri relativi al carico sono riportati nella Tabella 4.2 a pagina 69. Perquesto scenario supponiamo che i tre servizi abbiano una diversa durata e checiascuno venga richiesto con una certa probabilita, secondo quanto riportatonella Tabella 4.3. In dettaglio, supponiamo che il servizio voce (Servizio1) sia

Servizio Servizio1 Servizio2 Servizio3

Probabilita 0.6 0.1 0.3Durata 300 s 1200 s 60 s

Tabella 4.3: Probabilita di richiesta e durata media dei tre servizi

il piu richiesto ed abbia una durata media di 5 minuti. Il servizio di streaming(Servizio2) e invece quello richiesto meno frequentemente, ma ha una duratamedia piu lunga, pari a 20 minuti. Il servizio di background (Servizio3) in-fine e mediamente richiesto ma ha una durata molto breve, pari in media a1 minuto. Supponiamo che a tempo t0 = 10000 il sistema sia stabile e stialavorando a regime. Dopo 5 minuti, al tempo toutage = 10300 la stazione baseA subisce un guasto che ne degrada le prestazioni del 50% per un’ora, per poirecuperare il suo stato di normale funzionamento al tempo trecover = 13900(Figura 4.9).

Osserviamo quindi l’andamento del carico nelle due stazioni base e il livellodi insoddisfazione degli utenti, prima durante e dopo il guasto della cella A.La Figura 4.10 mostra il carico su entrambe le tratte delle due stazioni base.Il risultato piu evidente e che in corrispondenza del guasto si ha una riduzionedel carico nella stazione A, dovuto all’abbattimento di un certo numero dicollegamenti. Come conseguenza si ha un aumento del carico sull’interfac-cia radio della seconda cella, che si attenua in corrispondenza dell’istante diripristino. Analizzando piu attentamente i due grafici notiamo un picco di

4.3 Guasti parziali 77

Figura 4.9: Disposizione delle due stazioni base e percentuale di funzionamentonell’intervallo di tempo [toutage, trecover]

0

0.2

0.4

0.6

0.8

1

10000 11000 12000 13000 14000 15000

Car

ico

Tempo (sec)

Cella A

DownlinkUplink

0

0.2

0.4

0.6

0.8

1

10000 11000 12000 13000 14000 15000

Car

ico

Tempo (sec)

Cella B

DownlinkUplink

Figura 4.10: Fattore di carico delle stazioni base nel tempo

0

0.05

0.1

0.15

0.2

0.25

0.3

10000 11000 12000 13000 14000 15000

Pro

babi

lità

che

l’ute

nte

si tr

ovi i

n un

o st

ato

di fa

llim

ento

Tempo (sec)

50 Utenti

Servizio1Servizio2Servizio3

0

0.002

0.004

0.006

0.008

0.01

10000 11000 12000 13000 14000 15000

Pro

babi

lità

che

l’ute

nte

si tr

ovi i

n un

o st

ato

di fa

llim

ento

Tempo (sec)

50 Utenti

Servizio1Servizio2

Figura 4.11: Livello di insoddisfazione degli utenti prima, durante e dopo il guasto

breve durata nella stazione base B, negli istanti immediatamente successivial momento del guasto di A. Questo effetto e dovuto molto probabilmenteagli utenti che riescono con successo a proseguire il loro servizio solamentesulla seconda stazione base, aumentando di colpo il carico che questa devesopportare.

Per quanto riguarda la probabilita che un utente si trovi in uno stato difallimento, essa viene misurata per ciascun servizio come la probabilita che un


utente si trovi in uno stato di attesa, perche la sua richiesta e stata respinta oil servizio interrotto dalla rete. Il risultato e mostrato nei due grafici in Figura4.11. Il primo mostra la probabilita ottenuta per tutti e tre i servizi e vediamoche il servizio di background ha la probabilita piu alta, mentre gli altri, essendodi ordine di grandezza piu piccolo, sono appena visibili in questa immagine.Il servizio di background infatti, essendo quello che richiede piu ampiezzadi banda e genera quindi piu carico, trova piu difficolta nel momento delguasto, quando le risorse sono limitate. Per chiarezza nel secondo grafico sonoriportate le sole probabilita dei primi due servizi, che sono di grandezza simile.Dei due il servizio di telefonia risente appena del guasto della prima cella, conquesta configurazione, mentre il servizio di streaming mostra probabilita unpo’ piu significative, passando da una probabilita dell’ordine del 2� a unadell’ordine del 1%.

L’aumento del numero di fallimenti e determinato dalla minore disponi-bilita di risorse e puo essere verificato anche confrontando i livelli di caricodelle due stazioni, nella precedente Figura 4.10. Notiamo infatti che il caricosmaltito da A in conseguenza dell’outage risulta molto minore rispetto all’in-cremento che si verifica sulla stazione base B. Essa sta funzionando vicino allimite gia prima del guasto ed e quindi costretta a scartare un certo numero diutenti, nel momento in cui essi richiedono l’aumento del carico per far fronteal guasto di A. Da qui l’aumento del numero di fallimenti, specialmente per ilServizio3, che richiede un carico downlink molto elevato. Con la riparazionedella prima stazione base anche la probabilita che l’utente si trovi in uno statodi insoddisfazione torna rapidamente ai valori iniziali.

4.4 Utenti in movimento

Questa sezione valuta le prestazioni della rete UMTS in situazioni in cui gliutenti hanno la capacita di spostarsi all’interno della rete. Il tempo medioche un utente impiega ad attraversare una cella viene calcolato in base alladimensione ipotizzata per la cella e alla velocita di spostamento dell’utente.Come esempio, se si ipotizzano celle di raggio pari a 2 Km e una velocitautente di 100 Km/h, attraversare una cella da un’estremita all’altra richiedein media 144 secondi. In base alla distribuzione desiderata per il tempo dispostamento dell’utente, si dovranno quindi impostare i relativi parametridella transizione che modella lo spostamento in base a questo valore: esso sara

4.4 Utenti in movimento 79

il rate, nel caso di un’esponenziale, il valore medio, nel caso di una normale,o il centro dell’intervallo nel caso di una uniforme. Tale valore comprendepero anche il tempo trascorso nelle aree di sovrapposizione; in base alla loroestensione deve quindi essere ripartito tra le zone che si vogliono considerare.Proseguendo con l’esempio, supponiamo di voler attraversare una cella perspostarsi poi in una adiacente, alla velocita media di 100 Km/h. Se si ritienedi dover percorrere, cosı facendo, 3 Km nella prima cella e 1 Km in una zonadi sovrapposizione del segnale radio, si devono prevedere due transizioni esuddividere l’intervallo di tempo in due parti: 108 secondi per lo spostamentoverso l’area di sovrapposizione e i restanti 36 per spostarsi nella zona copertaunicamente dalla seconda cella.

In questa sezione vengono considerati due diversi scenari in cui gli utentisi muovono all’interno del sistema, con due diversi itinerari prestabiliti. Nelprimo si considera una situazione transiente che mostra l’effetto degli spo-stamenti sul carico delle stazioni radio, mentre nel secondo si considera unasituazione a regime dove viene valutato l’impatto del movimento sulla qualitadel servizio percepita dall’utente.

4.4.1 Scenario 1

Per questa valutazione consideriamo un’area locale formata da quattro stazionibase A, B, C e D disposte in modo tale che la A risulti essere al centro e le altredisposte attorno ad essa (Figura 4.12). La cella A si sovrappone parzialmentealle altre tre celle, mentre esse sono tra di loro disgiunte. Ipotizziamo che siverifichi un evento nella zona coperta da A e per questo motivo vi sia un flussodi utenti in arrivo dalle zone B e C che si spostano verso A, vi stazionano perun certo periodo di tempo e si allontanano poi in direzione della cella D, adesempio per seguire un nuovo evento o perche l’evento stesso si sta spostando,come nel caso di una manifestazione o di una parata.

Supponiamo che oltre agli utenti in movimento, ve ne siano normalmente10 per ciascuna stazione base, per un totale di 40 utenti statici. Oltre a questi,inizialmente vi sono 50 utenti nella zona B e 50 nella zona C, per un totaledi 140 utenti all’interno del sistema. Dopo un tempo distribuito secondo unauniforme e compreso tra i 20 e i 40 minuti, gli utenti iniziano a muoversiverso la stazione base A, impiegando dai 10 ai 15 minuti per arrivare nellazona di sovrapposizione e altri 3-5 minuti per raggiungere il centro della cella.Una volta giunti nella zona coperta solamente da A essi vi rimangono per un


Figura 4.12: Movimento degli utenti nel sistema, in relazione all’evento nella cella A

0

0.2

0.4

0.6

0.8

1

0 2000 4000 6000 8000 10000 12000 14000

Car

ico

Tempo (sec)

Cella A

DownlinkUplink

0

0.2

0.4

0.6

0.8

1

0 2000 4000 6000 8000 10000 12000 14000

Car

ico

Tempo (sec)

Cella B

DownlinkUplink

0

0.2

0.4

0.6

0.8

1

0 2000 4000 6000 8000 10000 12000 14000

Car

ico

Tempo (sec)

Cella C

DownlinkUplink

0

0.2

0.4

0.6

0.8

1

0 2000 4000 6000 8000 10000 12000 14000

Car

ico

Tempo (sec)

Cella D

DownlinkUplink

Figura 4.13: Fattore di carico delle stazioni base nel tempo

tempo variabile dai 50 ai 70 minuti, per poi muoversi verso D impiegandoancora una volta dai 13 ai 20 minuti per raggiungere la zona centrale dellacella. Questa situazione puo essere modellizzata utilizzando una versione sumisura del modello UserMovement, descritta in A.3.

La misura a cui siamo interessati e il carico su entrambe le tratte del-le quattro stazioni base coinvolte e la Figura 4.13 mostra i risultati di questo


Figura 4.14: Traiettoria degli utenti attraverso l’area di copertura delle quattro celle

esperimento. Gli istanti di tempo evidenziati nei grafici con delle linee vertica-li corrispondono a intervalli di tempo particolarmente rilevanti. Le prime duelinee identificano l’intervallo di tempo nel quale gli utenti iniziano il loro spo-stamento verso la stazione base A, mentre le altre due sono in corrispondenzadell’intervallo nel quale gli utenti ripartono verso D, dopo aver stazionato nellacella A. Le curve del carico hanno il comportamento atteso, con quelle di Be C che si comportano allo stesso modo. Esse iniziano a decrescere quandogli utenti iniziano a spostarsi verso la stazione A, il cui carico aumenta infatticontemporaneamente. Si ha un picco di carico in A in corrispondenza dei 60minuti in cui gli utenti vi stazionano, per poi diminuire rapidamente quandoiniziano a spostarsi verso D.

Il modello SAN utilizzato per questa valutazione, che mostra un’utilizzoarticolato della funzionalita di movimento, e incluso nel CD-ROM allegato.

4.4.2 Scenario 2

In questo scenario si osservano quattro stazioni base consecutive e una popo-lazione di utenti che le attraversa in modo sequenziale. Inizialmente essi sitrovano nell’area di copertura della cella A e si spostano in direzione della D,attraversando B, C e le rispettive zone di sovrapposizione dei segnali radio.Le misure che ci interessa calcolare sono la probabilita di fallimento o inter-ruzione di un servizio in queste condizioni, al variare della velocita dell’utentee della durata del servizio. Per semplicita, supponiamo che il movimento siacontinuo, cioe che gli utenti una volta arrivati nella stazione base D invertanola loro direzione per tornare nella posizione di partenza, da cui proseguononuovamente per la stazione D (Figura 4.14). Cosı facendo, sostanzialmentee come se gli utenti si stessero spostando attraverso un numero arbitrario distazioni base consecutive. Negli esperimenti effettuati viene ipotizzato un rag-gio di copertura per le stazioni base di 2 Km, di cui 500 metri si trovano insovrapposizione con la cella adiacente.


0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300

Pro

babi

lità

diin

terr

uzio

ne d

el s

ervi

zio

Velocità Utente (Km/h)

20 Utenti

5 min10 min15 min

Figura 4.15: Probabilita di interruzione del servizio al variare della velocita dell’utente

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

0 5 10 15 20 25 30

Pro

babi

lità

diin

terr

uzio

ne d

el s

ervi

zio

Durata Servizio (min)

20 Utenti

50 Km/h90 Km/h

130 Km/h200 Km/h300 Km/h

Figura 4.16: Probabilita di interruzione del servizio al variare della durata del servizio

In questo scenario si utilizzano delle transizioni esponenziali per model-lizzare lo spostamento degli utenti. Valutando una situazione a regime e unmovimento continuo si puo considerare il rate secondo cui l’utente entra nel-l’area di copertura di una nuova cella. La valutazione viene condotta in duefasi, nella prima viene variata la velocita media dell’utente a intervalli di 20Km/h, fino a un massimo di 300 Km/h e verificando l’effetto su servizi didiversa durata. Nella seconda viene fatto il contrario, ovvero viene variata ladurata del servizio, a intervalli di 5 minuti, e viene osservato l’effetto su utentiche si muovono a diverse velocita. In entrambi i casi la misura che ci interessaricavare e la probabilita che il servizio venga interrotto a causa del fallimentodell’handover. Le Figure 4.15 e 4.16 mostrano i risultati ottenuti variando la


velocita di movimento dell’utente e la durata del servizio. Per velocita mol-to basse la probabilita di interruzione e praticamente nulla, mentre con valoripiu elevati il valore ottenuto comincia a crescere tanto piu rapidamente quantomaggiore e la durata del servizio. Quando un utente entra in una nuova cellae necessario infatti un certo tempo, se pur piccolo, per eseguire la proceduradi accesso casuale e instaurare il radio bearer. Se l’utente si sposta moltorapidamente pero, il tempo che trascorre nell’area di copertura potrebbe nonessere sufficiente e puo accadere che lasci la cella senza ancora aver ottenutole risorse necessarie per far proseguire il servizio. Con l’aumento del tempo diservizio, si devono effettuare un numero sempre maggiore di cambi di stazionebase e la probabilita di interruzione aumenta quindi di conseguenza.

Capitolo 5

Conclusioni e sviluppi futuri

L’obiettivo di questo lavoro e stato quello di aggiornare, rivedere e ampliareun modello per una rete di telefonia mobile di terza generazione, esposto in[5]. Si e cercato di sfruttare al meglio le nuove caratteristiche introdotte nelframework di modellazione Mobius e di utilizzare una strategia che automatizzial massimo la costruzione del modello e che sia abbastanza generale da poteressere riutilizzata in altri contesti. La metodologia adottata si basa sullaparametrizzazione dei modelli SAN, anche attraverso l’utilizzo di tipi di datostrutturati.

Nella prima fase abbiamo riorganizzato il modello della rete esistente, cercandosimmetrie tra le componenti del sistema e sfruttandole per ridurre la duplica-zione di codice, in modo da ottenere un modello piu scalabile e piu sempliceda riprodurre. Questo e stato possibile grazie a una strategia di modellazioneparametrica che permette di integrare piu modelli, con comportamenti similitra loro, in un’unica struttura SAN. Le sue istanze vengono poi differenziatein fase di composizione grazie ai suoi parametri, identificabili nel valore dialcuni place particolari. Procedere in questo modo ci ha permesso di definireuna sola volta il codice per una classe di modelli, senza dover duplicare laloro struttura per riflettere la variazione di qualche valore numerico o diversemodalita di funzionamento. Volendo fare un paragone, si ha una similitudinecon quanto avviene nella programmazione a oggetti: ogni prototipo di modelloviene istanziato piu volte nella fase di composizione, assegnandogli parametriiniziali diversi. Sebbene ogni modello abbia la stessa definizione quindi, sicomportera in modo leggermente diverso in base ai parametri assegnati.

L’introduzione delle nuove caratteristiche ha richiesto poi una completa

85

86 Capitolo 5: Conclusioni e sviluppi futuri

rivisitazione del modello di partenza, del quale sono comunque riconoscibilialcune parti rimaste pressoche invariate. Per realizzare lo spostamento degliutenti da una stazione base all’altra e stato infatti necessario realizzare unacompleta separazione tra i livelli fisico e di applicazione, rendendo l’esecuzionedel servizio indipendente dalla stazione che fornisce le risorse.

La versione preliminare di questo nuovo modello, pensata per due stazionibase, e stata in seguito ottimizzata e resa il piu possibile scalabile rispettoal numero di celle che si vuole considerare. Nella prima fase di modellazioneinfatti e spesso piu semplice catturare il comportamento di un sistema conun ridotto numero di componenti, per poi andare a generalizzare i risultatiottenuti. In questa fase abbiamo tenuto in considerazione anche la possibileevoluzione del modello, rendendo il piu possibile indipendenti tra di loro le va-rie funzioni delle stazioni base, handover compreso. Questo comprende ancheuna definizione scalabile del movimento dell’utente, basata sulla sua posizionein relazione a ciascuna stazione base, anziche sulla definizione di zone, cheaumentano esponenzialmente con l’aumentare delle celle considerate.

Infine sono state eseguite delle valutazioni numeriche, per verificare il cor-retto funzionamento del modello e l’aderenza con il modello iniziale, valu-tando allo stesso tempo alcuni parametri di QoS di una rete UMTS. Questiesperimenti hanno mostrato il corretto funzionamento del sistema, sia nellesituazioni originali, con un numero di utenti costante in ogni zona del sistema,sia nei nuovi scenari possibili, in cui gli utenti hanno la possibilita di spostarsie le stazioni base possono funzionare in uno stato degradato. Nell’osservazio-ne di scenari diversi tra loro si e constatata anche la versatilita del modelloottenuto che, grazie alla parametrizzazione dei modelli atomici, richiede unosforzo ridotto per creare di volta in volta la rete a proprio piacimento.

5.1 Possibili sviluppi

Utilizzando un modellazione di tipo parametrico, per mezzo di place estesi estrutture dati avanzate, e quindi possibile creare modelli piu modulari e sca-labili, che riescano a fronteggiare meglio la complessita generata dall’aumentodel numero di componenti di un sistema. Per questo motivo, secondo quantosperimentato nella realizzazione di questo lavoro, ci sentiamo di proporre unanuova funzione di Mobius che faciliterebbe la fase di composizione in situa-zioni in cui si utilizzano modelli parametrici. Creando un modello composto

5.1 Possibili sviluppi 87

a partire da modelli parametrici, e spesso necessario infatti rinominare unsottoinsieme dei place, in modo da differenziare diverse istanze di uno stessomodello atomico. Nei modelli del servizio ad esempio, il place che rappresentala durata viene rinominato, aggiungendo in coda un indice diverso per ogniservizio. Potrebbe quindi essere utile una funzione che permette di definirein ogni modello atomico un sottoinsieme di place, che vengono poi rinominatiquando in fase di composizione si crea una nuova istanze dello stesso modelloatomico, aggiungendo ogni volta un indice diverso al nome originale dei place.

Per quanto riguarda la rete UMTS, la complessita della sua architettura lasciaspazio a eventuali estensioni del modello presentato in questo lavoro.

In questa analisi, come anche nelle precedenti, si e assunto che il caricoapportato da un terminale mobile su di una stazione base dipenda solamentedal servizio richiesto e viene percio considerato uguale per tutti gli utentiall’interno dell’area di copertura di una cella. Nel W-CDMA in realta il caricodipende anche da altri fattori, uno su tutti la posizione dell’utente nella rete.La distanza infatti influenza la potenza di trasmissione necessaria al terminaleper raggiungere la stazione base e, allo stesso tempo, la sua posizione rispettoalle altre celle influenza la potenza di trasmissione necessaria alle stazioni baseper raggiungerlo, in virtu dell’interferenza intercella. Una direzione in cui epossibile estendere questo lavoro e quindi quella di introdurre nel modelloun calcolo piu accurato del carico generato da ciascun utente, in relazionedella sua posizione nella rete. Volendo procedere in questa direzione si puosfruttare l’indipendenza realizzata tra i modelli di allocazione e riutilizzare ilplace Signal, per esprimere la potenza del segnale ricevuto dall’utente.

Un altro aspetto della rete che meriterebbe un maggiore approfondimento erappresentato dalla procedura di accesso casuale, vista anche la sua influenzanella corretta esecuzione dell’handover. Il comportamento della proceduracasuale per quanto riguarda una singola stazione base e stato gia analizzatoin [15] utilizzando le SAN e potrebbe percio essere interessante integrare i duelavori per ottenere il modello di una rete UMTS composta da piu stazioni basecon soft handover, utenti mobili, guasti parziali e una procedura di accessocasuale dettagliata.

Ringraziamenti

Desidero ringraziare tutte le persone che, in un modo o nell’altro, mi hannoaiutato in questi anni. Un dovuto ringraziamento alla mia famiglia, che hareso possibile tutto cio e finalmente vedra qualche risultato. Un grazie aicolleghi e amici di corso, per la compagnia di questi anni e soprattutto peri momenti di pausa dallo studio. Fra questi, un doppio ringraziamento aicolleghi di laurea, che hanno condiviso con me le ansie e i problemi burocraticie non del laureando. Anche se non li conosco personalmente, desidero inoltreringraziare Elisa e Gabriele, che con i loro precedenti lavori sull’UMTS hannodato il loro contributo. Una parola anche per i miei ex colleghi della Vivido,che hanno atteso questa laurea quasi piu di me e verso i quali adesso non hopiu scuse.

Un grazie di cuore poi agli amici di una vita, a tutte le persone che mi hannovoluto e mi vogliono bene e a chi mi e stato vicino quando ne ho avuto bisogno,dandomi la forza per andare avanti.

Ringrazio infine il Prof. Bondavalli e il Dott. Lollini per la loro disponibilita e ilsostegno nello svolgimento di questo lavoro e, consapevole di aver sicuramentedimenticato qualcuno nello scrivere questi ringraziamenti a notte fonda, sperocomunque che nessuno si offenda!

Bibliografia

[1] 3GPP TS 23.107. Quality of Service (QoS) concept and architecture.Technical Report 23.107 (v6.4.0), 3rd Generation Partnership Project, 032006. http://www.3gpp.org.

[2] 3GPP TR 25.993. Typical examples of Radio Access Bearers (RABs) andRadio Bearers (RBs) supported by Universal Terrestrial Radio Access(UTRA). Technical Report 25.993 (v7.1.0), 3rd Generation PartnershipProject, 12 2006. http://www.3gpp.org.

[3] Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, Carl Landwehr.Basic Concepts and Taxonomy of Dependable and Secure Computing.IEEE Transactions on Dependable and Sicure Computing, 1(1):11–23,January-March 2004.

[4] S. Baudet, C. Besset-Bathias, P. Frene, N. Giroux. QoS implementationin UMTS networks. Alcatel Telecommunications Review, pages 41–49, 1st

Quarter 2001.

[5] Elisa Culicchi. Modellazione ed Analisi dell’Infrastruttura UMTS e dellePolitiche di Handover. Master’s thesis, Universita degli Studi di Firenze.Corso di Laurea in Informatica, 2004.

[6] L. Giugno, M. Luise. Introduzione al sistema UMTS, Dicembre 2006.Materiale per il corso di Apparati di Telecomunicazione, Corso di Laureain Ingegneria Informatica, Univesita di Pisa.

[7] Harry Holma, Antti Toskala, Flavio Muratore, Sergio Barberis. UMTS:Accesso Radio ed Architetture di Rete. Telecom Italia Lab, 2002.

[8] Jaana Laiho, Achim Wacker, Tomas Novosad. Radio Network Planningand Optimisation for UMTS, Second Edition. Wiley, 2006.

89

http://www.3gpp.org

http://www.3gpp.org

[9] Paolo Lollini, Andrea Bondavalli, Felicita Di Giandomenico. A generalmodeling approach and its application to a UMTS network with soft-handover mechanism. Technical Report RCL060501, Universita degliStudi di Firenze – Dipartimento Sistemi e Informatica, Maggio 2005.

[10] Paolo Lollini, Andrea Bondavalli, Felicita Di Giandomenico. QoS Ana-lysis of a UMTS cell with different Service Classes. In CSN-2005 TheFourth IASTED International Conference on Communication Systemsand Networks, September 12-14 2005.

[11] Paolo Lollini, Felicita Di Giandomenico, Andrea Bondavalli, Stefano Por-carelli. Congestion analysis in a general GPRS network. In Mobile Venue’04 (informal proceedings), Athens, Greece, May 27-28 2004.

[12] Maciej J. Nawrocki, Mischa Dohler, A. Hamid Aghvami. UnderstandingUMTS Radio Network Modelling, Planning and Automated Optimization.Wiley, 2006.

[13] R. Owen, S. Burley, P. Jones, V. Messer. Considerations for UMTSCapacity and Range Estimation. 2000.

[14] PERFORM – Performability Engineering Research Group, University ofIllinois at Urbana-Champaign. Mobius User Manual, 2.0 edition.http://www.mobius.uiuc.edu.

[15] Gabriele Petruzzi. Modellizzazione ed analisi della QoS offerta da unacella UMTS. Master’s thesis, Universita degli Studi di Firenze. Corso diLaurea in Informatica, 2004.

[16] William H. Sanders. Computer System Analisys – Lecture Slides.http://www.crhc.uiuc.edu/Faculty/whs.html.

[17] Kari Sipila, Zhi-Chun Honkasalo, Jaana Laiho-Steffens, Achim Wacker.Estimation of Capacity and Required Transmission Power of WCDMADownlink Based on a Downlink Pole Equation. In Vehicular TechnologyConference Proceedings, 2000, volume 2, pages 1002–1005, Spring 2000.

[18] Thrasivoulos (Sakis) Griparis, Tristan Lee – Bechtel Corporation.The Capacity of a WCDMA Network: A Case Study. BechtelTelecommunications Technical Journal, 3(1):73–78, August 2005.

90

http://www.mobius.uiuc.edu

http://www.crhc.uiuc.edu/Faculty/whs.html

[19] http://www.reteumts.info/. UMTS – Descrizione della rete per latelefonia mobile di terza generazione (3G) UMTS. Ultimo Accesso: Marzo2007.

[20] Stijn N. P. Van Cauwenberge. Study of soft handover in UMTS. Ma-ster’s thesis, Master Thesis. Danmarks Tekniske Universitet – COMDepartment, 2003.

91

http://www.reteumts.info/

Elenco degli Acronimi

2G Second Generation

3G Third Generation

3GPP 3rd Generation Partnership Project

AS Active Set

BS Base Station

CDMA Code Division Multiple Access

CD-ROM Compact Disc Read Only Memory

CN Core Network

DRNC Drift RNC

DS-CDMA Direct Sequence Code Division Multiple Access

DSPN Deterministic and Stochastic Petri Nets

EDGE Enhanced Data rates for GSM Evolution

EIRP Equivalent Isotropically Radiated Power

GSM Global System for Mobile Communications

GPRS General Packet Radio Service

FDD Frequency Division Duplex

FDMA Frequency Division Multiple Access

FH-CDMA Frequency Hopping Code Division Multiple Access

93

GSPN Generalized Stochastic Petri Nets

IP Internet Protocol

OOP Object-Oriented Programming

OVSF Orthogonal Variable Spreading Factor

PN Petri Nets

PRACH Physical RACH

QoS Quality of Service

RACH Random Access Channel

RNC Radio Network Controller

RNS Radio Network Subsystem

RS Reachability Set

SAN Stochastic Activity Network

SHO Soft Handover

SMS Short Message Service

SRNC Serving RNC

SPN Stochastic Petri Nets

TDMA Time Division Multiple Access

TD-CDMA Time Division Code Division Multiple Access

TDD Time Division Duplex

UE User Equipment

UMTS Universal Mobile Telecommunications System

UTRAN UMTS Radio Access Network

VoIP Voice over IP

W-CDMA Wideband Code Division Multiple Access

94

Appendici

Appendice A

Implementazione del modello

In questa appendice e riportata la documentazione prodotta da Mobius perciascuno dei modelli atomici che formano il modello della rete UMTS. I modelliUser, UserMovement e Startup variano leggermente in base al tipo di scenarioche si vuole rappresentare; di questi modelli vengono qui riportati degli esempisignificativi, che non necessariamente devono essere utilizzati insieme nellostesso modello di rete UMTS.

Infine e mostrato un esempio di modello composto, con la relativa docu-mentazione Mobius.

A.1 Modello BaseStation

In questa sezione riportiamo la documentazione prodotta dal tool Mobius peril modello BaseStation.

97

98 Appendice A: Implementazione del modello

Bucket Attributes:

Place Names Initial Markings

ChannelCount1 0

ChannelCount2 0

ChannelCount3 0

ChannelCountSHO 1 0

ChannelCountSHO 2 0

ChannelCountSHO 3 0

LoadFactor 0

MaxLoad 0

Down 0

FailTime 0

Failed 0

Outage1 0

Outage2 0

Outage3 0

OutageSHO 1 0

OutageSHO 2 0

OutageSHO 3 0

PercOutage 0

RecoverTime 0

Work 100

Timed Activity: Fail

Distribution Parameters Value

FailTime−>Mark()

Activation Predicate (none)

Reactivation Predicate (none)

Timed Activity: Recover

Distribution Parameters Value

RecoverTime−>Mark()



Instantaneous Activities Without Cases:

CongControl

Input Gate: IGDown

Predicate

Down−>Mark() >= PercOutage−>Mark() && PercOutage−>Mark() > 0

Function

Down−>Mark() −= PercOutage−>Mark();

A.1 Modello BaseStation 99

Input Gate: IGFail

Predicate

Work−>Mark() >= PercOutage−>Mark() && PercOutage−>Mark() > 0

Function

Work−>Mark() −= PercOutage−>Mark();

if (Work−>Mark() < 0)

{Work−>Mark() = 0;

}

Output Gate: OGCongControl

Function

double max dl = MaxLoad−>Downlink−>Mark() * (Work−>Mark() / 100.0);

double max ul = MaxLoad−>Uplink−>Mark() * (Work−>Mark() / 100.0);

int iUsers = ChannelCount1−>Mark() + ChannelCountSHO 1−>Mark() +

ChannelCount2−>Mark() + ChannelCountSHO 2−>Mark() +

ChannelCount3−>Mark() + ChannelCountSHO 3−>Mark();

if (LoadFactor−>Downlink−>Mark() > max dl || LoadFactor−>Uplink−>Mark() > max ul)

{double dDifference = 0;

double dDropped = 0;

if (LoadFactor−>Uplink−>Mark() > max ul)

{dDifference = LoadFactor−>Uplink−>Mark() − max ul;

dDropped = (iUsers * dDifference) / LoadFactor−>Uplink−>Mark();

}else

{dDifference = LoadFactor−>Downlink−>Mark() − max dl;

dDropped = (iUsers * dDifference) / LoadFactor−>Downlink−>Mark();

}double dPerc = dDropped / iUsers;

Outage1−>Mark() += ceil(dPerc * ChannelCount1−>Mark());



OutageSHO 1−>Mark() += ceil(dPerc * ChannelCountSHO 1−>Mark());



}

Output Gate: OGFail

Function

Down−>Mark() += PercOutage−>Mark();


Output Gate: OGRecover

Function

Work−>Mark() += PercOutage−>Mark();

if (Work−>Mark() > 100)

{Work−>Mark() = 100;

}

Lo stato di attivita della stazione base e rappresentato dal place Work, cheinizialmente contiene un numero di token pari a 100. Il valore di questo placeindica la percentuale di degradazione delle risorse della cella: un valore pari azero indica che la cella e completamente inattiva. La transizione fail rappre-senta l’occorrenza di outage, di entita pari al valore del place OutagePercent

e la sua funzione di input non fa altro che togliere il numero specificato ditoken al place Work e assicurarsi che questo non scenda sotto il valore zero.

Il gate OGFail semplicemente incrementa i token presenti in Down del valoredel place OutagePercent. La transizione Recover rappresenta la riparazioneo comunque il ripristino a una situazione di normale funzionamento, ha uncomportamento speculare a quello di Fail ed e attivata quando sono presentidei token nel place Down. In seguito al verificarsi di un outage, la transizioneFail inserisce un token in CellFailed, che segnala la necessita di control-lare il livello di congestione nella cella. Questo place attiva la transizioneCongestionControl che scarta gli utenti in eccesso e aggiorna il carico dellacella, tramite l’output gate RefreshLoadFactor.

Una volta calcolato il carico massimo supportabile in quel momento dallacella, si controlla che il carico non superi tale valore, su entrambe le tratte.Se almeno una delle tratte eccede il carico massimo, si devono scartare alcuniutenti e viene quindi calcolata la differenza tra il carico attuale e quello mas-simo supportabile. Il numero di utenti da scartare viene calcolato in base alrapporto tra questo scarto e il carico totale. Una volta individuata la per-centuale di utenti da scartare, ne viene calcolato il numero per ogni servizio,arrotondando per eccesso e il valore cosı ricavato viene posto nel corrispon-dente place Outage. I place LoadFactor e MaxLoad sono di tipo Workload

e rappresentano rispettivamente il carico attuale della cella e il carico mas-simo; FailTime e RecoverTime sono di tipo double e rappresentano inveceil tempo di fallimento e ripristino, rispettivamente. Questi place, insieme aOutagePercent, rappresentano i parametri del modello BaseStation.

A.2 Modello User 101

A.2 Modello User

Il modello User puo variare leggermente per ogni scenario rappresentato, in ba-se ai servizi che un’utente puo richiedere alla rete e in base alla posizione inizia-le degli utenti all’interno del sistema. Di seguito riportiamo la documentazioneprodotta dal tool Mobius per un particolare modello User.

Bucket Attributes:


Disabled 1

Idle 0

Move 0

Req1 0

Req2 0

Req3 0

UpdateSignal 0

UserStartA 0

UserStartAB 0

UserStartB 0

ZoneA 0

ZoneAB 0

ZoneB 0

Timed Activity: Request

Distribution Parameters Rate

1.0/tSetup



Case Distributions Case 1

pSelService1

Case 2


pSelService2

Case 3

pSelService3


InitA

InitAB

InitB

Input Gate: IGRequest

Predicate

Idle−>Mark() > 0

Function

Idle−>Mark()−−;

Move−>Mark() = 0;

Il modello di esempio condivide con il modello di inizializzazione (Startup)i place UsersStartA, UsersStartB e UsersStartAB, che indicano quanti uten-ti si trovano inizialmente nella zona coperta dalla cella A, B o da entrambe,rispettivamente. Una transizione istantanea preleva un token da uno di questiplace e si occupa di inizializzare l’utente e posizionarlo nella zona corrisponden-te. Per assicurarsi che scatti solo una transizione per utente il place Disabledcontiene un inizialmente un solo token, che viene rimosso durante l’inizializ-zazione. Il place UpdateSignal e condiviso con il modello UserMovement e fasi che vengano ricalcolati i valori dei place Signal, in base alla zona dove sitrova l’utente.

Una volta inizializzato, l’utente ha un token nel place Idle che rende latransizione Request abilitata. Questa transizione rappresenta la richiesta diservizio da parte dell’utente e in base alla configurazione che si desidera ana-lizzare puo avere piu case con diverse probabilita, come nell’esempio. QuandoRequest scatta, essa toglie il token in Idle e, in base al servizio richiesto, neaggiunge uno in uno dei place ReqN. Ciascuno di questi place e condiviso con ilplace Req di un diverso modello Service. Il place Move indica che l’utente haeffettuato uno spostamento e si devono aggiornare le risorse, e condiviso conService e UserMovement e viene azzerato quando viene richiesto un nuovoservizio, tramite il gate IGRequest. I place ZoneXY vengono condivisi con ilmodello UserMovement.

A.3 Modello UserMovement 103

A.3 Modello UserMovement

Il modello UserMovement cambia in base allo scenario che si vuole rappresen-tare e al tipo di movimento che si prevede per gli utenti. Quello qui riportatoe utilizzato nella valutazione numerica nella sezione 4.4.1.

Bucket Attributes:


ACount 0

EnterB 0

EnterC 0

Leave 0

Move 0

SignalA 0

SignalB 0

SignalC 0

SignalD 0

Start 1

UpdateSignal 0

ZoneA 0

ZoneAB 0

ZoneAC 0

ZoneAD 0

ZoneB 0

ZoneC 0

ZoneD 0

Timed Activity: BeginEnter

Distribution Parameters LowerBound

1200

UpperBound

2400




Timed Activity: BeginLeave


3000

UpperBound

4200



Timed Activity: MoveAB A


180

UpperBound

300



Timed Activity: MoveAC A


180

UpperBound

300



Timed Activity: MoveAD D


180

UpperBound

300



Timed Activity: MoveA AD


600

UpperBound

900



A.3 Modello UserMovement 105

Timed Activity: MoveB AB


600

UpperBound

900



Timed Activity: MoveC AC


600

UpperBound

900




Refresh

Input Gate: OGRefresh

Function

SignalA−>Mark() = 0;

SignalB−>Mark() = 0;

SignalC−>Mark() = 0;

SignalD−>Mark() = 0;

if (ZoneA−>Mark() || ZoneAB−>Mark() || ZoneAC−>Mark() || ZoneAD−>Mark())

{SignalA−>Mark() = 1;

}if (ZoneB−>Mark() || ZoneAB−>Mark())

{SignalB−>Mark() = 1;

}if (ZoneC−>Mark() || ZoneAC−>Mark())

{SignalC−>Mark() = 1;

}if (ZoneD−>Mark() || ZoneAD−>Mark())

{SignalD−>Mark() = 1;

}

Questo modello contiene un place SignalX per ogni stazione base presentenel sistema, condiviso con il corrispondente modello di tipo CellManager.


In base allo scenario analizzato, saranno presenti un certo numero di placeZoneXY, collegati tra di loro da delle transizioni di movimento, MoveXY Z.Queste transizioni non fanno altro che togliere il token dalla zona di partenzae aggiungerne uno in quella di destinazione e in UpdateSignal. Il token inUpdateSignal fa scattare la transizione istantanea Refresh, che aggiunge untoken in Move per segnalare l’avvenuto spostamento e aggiorna il valore deiplace SignalX, tramite l’output gate OGRefresh. Il place Move e condivisocon i modelli User e Service, il place UpdateSignal con il solo modello User.

In questo caso il modello e leggermente piu complicato del normale, perla particolare situazione da modellizzare (per la sua descrizione si veda 4.4.1).In questo caso gli utenti si muovono inizialmente nelle zone A o B, ma nonsi muovono fino ad aver raggiunto un certo istante di tempo. Questo e rap-presentato tramite una transizione deterministica, BeginEnter, che scattandoabilita le altre transizioni di movimento esponenziali. Successivamente gliutenti si muovono normalmente fino a giungere nella zona A, nella quale de-vono rimanere un periodo di tempo ben definito. Anche in questo caso vieneutilizzata una transizione deterministica, BeginLeave, che scattando abilitala transizione di movimento verso la stazione base D.

A.4 Modello Service

In questa sezione riportiamo la documentazione prodotta dal tool Mobius peril modello Service.

A.4 Modello Service 107

Bucket Attributes:


AnswerBlock 0

AnswerOK 0

AskResources 0

Begin 0

Dropped 0

End 0

Failed 0

Idle 0

Move 0

RelDropped 0

RelFailed 0

Release 0

ReleaseOK 0

Req 0

ServWait 1

ServiceTime 0

WaitResources 0

Timed Activity: Block


1.0/tBlock



Timed Activity: Drop


1.0/tDrop



Timed Activity: ServiceFinished


1.0/ServiceTime−>Mark()




Drop

Fail

Process

RequestFailed

Reset

Start

Update


UpdateFailed

UpdateOK

Input Gate: IGProcess

Predicate

ServWait−>Mark() > 0 && Req−>Mark() > 0

Function

ServWait−>Mark()−−;

Input Gate: IGUpdate

Predicate

Move−>Mark() > 0 && Req−>Mark() > 0

Function

Move−>Mark()−−;

Output Gate: OGUpdate

Function

if (Begin−>Mark() > 0)

{AskResources−>Mark()++;

}

Il modello Service inizia la sua attivita in uno stato di attesa, indicato daun token nel place ServWait. Quando il modello User richiede un servizio, vie-ne posto un token in Req, che fa scattare la transizione Process. Questa tran-sizione pone un token in AskResources, condiviso con ServiceManager, e spo-sta il modello nello stato di attesa delle risorse, con un token in WaitResources.A questo punto il modello e in attesa di una risposta da parte del modello sot-tostante, ServiceManager e si possono verificare due situazioni. Nel primocaso, le risorse sono disponibili e viene posizionato un token in AnswerOK,altrimenti viene aggiunto un token al place AnswerBlock. Se le risorse sonodisponibili, la transizione Start scatta e avvia il servizio, ponendo un tokennel place Begin. In caso contrario si abilita la transizione RequestFailed chescatta, togliendo il token da AnswerBlock e aggiungendone uno in Release

e uno in RelFailed, il primo per segnalare la necessita di rilasciare tutte lerisorse e il secondo per attendere il rilascio. Quando questo rilascio avviene siha un token in ReleaseOK e la transizione Fail porta il modello nello stato difallimento della richiesta, aggiungendo un token nel place Failed. Trascorso

A.5 Modello ServiceManager 109

un tempo esponenzialmente distribuito, la transizione Block riporta il modellonello stato iniziale, togliendo il token da Failed e aggiungendone nuovamenteuno a ServWait.

Se l’utente si sposta, viene posizionato un token nel place Move. Questo fascattare la transizione Update, se anche il place Req contiene un token. Se ilservizio e in esecuzione, ovvero se il place Begin contiene un token, l’outputgate OGUpdate segnala la necessita di controllare che le risorse siano ancoradisponibili, mettendo un token nel place AskResources. Se le risorse sonodisponibili, il token in AnswerkOK fa scattare la transizione UpdateOK, che inpratica lascia inalterato il servizio, visto che toglie il token in Begin e lo rimetteistantaneamente. In caso contrario scatta la transizione UpdateFailed, cheaggiunge un token in Release e uno in RelDropped, oltre a togliere il tokendal place Begin, interrompendo cosı il servizio. Una volta rilasciate tutte lerisorse, scatta la transizione Drop che, ponendo un token nel place Dropped,porta il sistema nello stato in cui il servizio e stato interrotto senza esserecompletato. Dopo un periodo di tempo la transizione DropDelay riporta ilmodello nello stato iniziale, ripristinando il token in ServWait e togliendoloda Dropped.

La transizione ServiceFinished e distribuita esponenzialmente con ra-te pari all’inverso del tempo medio di servizio, dato dal place ServiceTime.Quando essa scatta significa che il servizio e terminato senza interruzioni,percio viene tolto il token da Begin, aggiunto uno in End e uno inRelease,per rilasciare le risorse assegnate. Una volta rilasciate le risorse, la transizio-ne Reset riporta il modello nella configurazione di partenza, aggiungendo dinuovo un token in ServWait, e l’utente nello stato di inattivita, aggiungendoun token in Idle.

A.5 Modello ServiceManager

In questa sezione riportiamo la documentazione prodotta dal tool Mobius peril modello ServiceManager.


Bucket Attributes:


AnswerBlock 0

AnswerOK 0

AskCells 0

AskResources 0

CellAdjust 0

CellCount 0

CellRecover 0

CellRelease 0

CellsRandom 0

Checked 0

Done 0

Recover 0

Release 0

ReleaseOK 0

Req 0

SelectRandom 0

ServChannels 0

ServChannelsSHO 0

WaitRelease 0

WaitTokens 0


Ask

Check

RelChannels

RelEnd

SelRandom

TryRecover


Input Gate: IGAsk

Predicate

AskResources−>Mark() > 0 && Req−>Mark() > 0 &&

(AnswerBlock−>Mark() + AnswerOK−>Mark() == 0) && Release−>Mark() == 0

Function

AskResources−>Mark()−−

Input Gate: IGCheck

Predicate

Req−>Mark() && Done−>Mark() && !WaitRelease−>Mark()

&& !AskCells−>Mark() && !CellRecover−>Mark() && !Recover−>Mark()

Function

Done−>Mark()−−;

Input Gate: IGRelEnd

Predicate

WaitRelease−>Mark() == CellCount−>Mark()

Function

WaitRelease−>Mark() = 0;

Done−>Mark() = 0;

Checked−>Mark() = 0;

AnswerOK−>Mark() = 0;

AnswerBlock−>Mark() = 0;

Input Gate: IGSelRandom

Predicate

SelectRandom−>Mark() == CellCount−>Mark() && CellCount−>Mark() > 0

Function

SelectRandom−>Mark() = 0;

Output Gate: OGAsk

Function

AskCells−>Mark() = CellCount−>Mark();

if (DisableHandover)

{WaitTokens−>Mark() = 1;

}else{

WaitTokens−>Mark() = CellCount−>Mark();

}

Output Gate: OGCheck

Function


Checked−>Mark()++;

if (ServChannels−>Mark() > 0 || ServChannelsSHO−>Mark() > 1)

{AnswerOK−>Mark()++;

CellAdjust−>Mark() = CellCount−>Mark();


WaitTokens−>Mark() = 0;

}else

{if (Checked−>Mark() >= WaitTokens−>Mark())

{AnswerBlock−>Mark()++;



}}

Output Gate: OGRelease

Function

CellRelease−>Mark() = CellCount−>Mark();

WaitRelease−>Mark() = 0;

AskCells−>Mark() = 0;

CellAdjust−>Mark() = 0;

CellRecover−>Mark() = 0;

AskResources−>Mark() = 0;


Done−>Mark() = 0;


Output Gate: OGSelRandom

Function

CellsRandom−>Mark() = (rand() % CellCount−>Mark()) + 1;

Output Gate: OGTryRecover

Function

CellRecover−>Mark() = CellCount−>Mark();

WaitTokens−>Mark() += CellCount−>Mark();

Il modello ServiceManager viene messo in join con un certo numero dimodelli CellManager, in base al numero di celle presenti nel sistema. Il placeCellCount e condiviso con questi modelli e ne indica il loro numero. I placeServChannels e ServChannelsSHO indicano il numero di canali totale allocati


per il servizio su tutte le celle, di tipo normale o in soft handover rispetti-vamente. In questo modello e inoltre definita una variabile globale booleana,DisableHandover, che indica se disabilitare la funzione di soft handover.

La transizione Ask prende in consegna le richieste da parte del modelloservizio. Il controllo su AnswerBlock, AnswerOK e Release nel suo predicato diattivazione serve per dare la precedenza alle altre operazioni istantanee, primadi prendere in carico una nuova richiesta. L’output gate OGAsk posiziona nelplace AskCells un numero di token pari alle celle presenti nel sistema e inbase al valore della variabile DisableHandover indica se si deve attendere larisposta di tutte le celle o solamente di una, se l’handover e disabilitato.

Ogni volta che uno dei modelli CellManager ha effettuato i calcoli e l’e-ventuale allocazione del canale, aggiunge un token nel place Done. Se non visono altre transizioni abilitate e non si e nella fase di rilascio dei canali, untoken in Done abilita la transizione Check. Questa transizione ha il compitodi controllare la disponibilita di risorse per l’esecuzione del servizio e di da-re una risposta al modello Service, utilizzando i place condivisi AnswerOKe AnswerBlock. Cio viene fatto tramite il codice incluso nell’output gateOGCheck. Inizialmente viene aumentato di uno il valore di Checked, che in-dica quanti modelli CellManager hanno fino ad ora completato i loro calcoli.Se si dispone gia di sufficienti risorse, viene data risposta positiva al modelloService, viene impostato il valore di CellAdjust a CellCount e vengono az-zerati i place Checked e WaitTokens. Il place CellAdjust indica ai modelliCellManager che le risorse sono sufficienti e segnala loro di controllare che nonsiano allocate risorse in eccesso, ad esempio un canale normale e uno in softhandover. Se invece le risorse non sono sufficienti viene controllato il valoredi Checked e se questo e maggiore di WaitTokens viene segnalato al Servicela carenza di risorse. Il meccanismo di Checked e WaitTokens serve per darerisposta negativa solamente nel caso in cui tutte le stazioni base disponibiliabbiano dato risposta negativa.

La presenza di un token in Release indica la volonta di rilasciare le risorseallocate e provoca l’abilitazione di RelChannels. Questa scattando esegue ilgate OGRelChannels, che porta il modello in uno stato in cui attende il rilasciodelle risorse. Esso segnala ai modelli CellManager la necessita di rilasciare lerisorse e annulla eventuali altre operazioni gia iniziate. Quando l’operazionedi rilascio e completata e WaitRelease contiene un numero di token pari aquelli presenti in CellCount, la transizione RelEnd scatta, aggiungendo un


token in ReleaseOK.Il place Recover e condiviso con i modelli CellManager e quando vi sono

dei token significa che una stazione base ha interrotto il collegamento e che,quindi, si deve tentare di far proseguire il servizio dell’utente sulle altre stazionidisponibili. La transizione TryRecover non fa altro che segnalare a tutti imodelli CellManager la necessita di questa operazione e impostare il valoredi WaitTokens al numero totale di celle, in modo da attendere la risposta ditutte prima di dare esito negativo.

I place SelectRandom e CellsRandom infine, sono condivisi con i model-li CellManager e servono per selezionare casualmente una stazione base, nelcaso sia disabilitato il soft handover e l’utente si trovi in una zona di sovrap-posizione. La selezione casuale avviene nel modo seguente: inizialmente tuttii CellManager ricevono la normale richiesta di risorse tramite AskCells. Seuno di questi ha gia allocato un canale per l’utente allora prosegue normalmen-te la richiesta, mentre tutti gli altri inseriscono un token in SelectRandom, perrichiedere una selezione casuale. Se nessuno di essi ha gia allocato dei canali,SelectRandom conterra un numero di token pari al numero di celle e la transi-zione SelRandom sara cosı abilitata. Quando essa scatta per prima cosa azzeraSelectRandom e successivamente esegue il codice del gate OGSelRandom, chesi occupa di eseguire la scelta casuale, ponendo il valore selezionato nel placeCellsRandom.

A.6 Modello CellManager

In questa sezione riportiamo la documentazione prodotta dal tool Mobius peril modello CellManager.

A.6 Modello CellManager 115

Bucket Attributes:


AskCells 0

CellAdjust 0

CellCount 0

CellRecover 0

CellRelease 0

CellsRandom 0

Channel 0

ChannelCount 0

ChannelCountSHO 0

ChannelSHO 0

Done 0

FirstReq 1

FirstTry 0

GetChannel 0

GetChannelSHO 0

Index 0

Init 1

LoadFactor 0

MaxLoad 0

NotifyRelease 0

Outage 0

OutageSHO 0

PRACH 0

RachComplete 0

RachFail 0

RachOK 0

Recover 0

SelectRandom 0

ServChannels 0

ServChannelsSHO 0

ServiceLoad 0

ServiceLoadSHO 0


Signal 0

UnloadChannel 0

WaitRelease 0

Work 100

Timed Activity: RACHDelay


1.0/tRachDelay



Timed Activity: Setup


1.0/tSetup



Case Distributions Case 1

pFail

Case 2

1−pFail


Adjust

CellSelected

Drop

DropSHO

Get

GetIndex

GetSHO

Link

Release

Request

TryRecover

Unload

Input Gate: IGAdjust

Predicate

CellAdjust−>Mark() == Index−>Mark() && Index−>Mark() > 0

Function

CellAdjust−>Mark()−−;

Input Gate: IGCellSelected

Predicate


CellsRandom−>Mark() == Index−>Mark() && Index−>Mark() > 0

Function

CellsRandom−>Mark() = 0;

Input Gate: IGLink

Predicate

AskCells−>Mark() == Index−>Mark() && Index−>Mark() > 0

Function

AskCells−>Mark()−−;

Input Gate: IGRecover

Predicate

CellRecover−>Mark() == Index−>Mark()

&& Index−>Mark() > 0

&& AskCells−>Mark() == 0

Function

CellRecover−>Mark()−−;

Input Gate: IGRelease

Predicate

CellRelease−>Mark() == Index−>Mark() && Index−>Mark() > 0

Function

CellRelease−>Mark()−−;

NotifyRelease−>Mark() = 1;

PRACH−>Mark() = 0;

RachFail−>Mark() = 0;

RachOK−>Mark() = 0;

RachComplete−>Mark() = 0;

UnloadChannel−>Mark() = 0;

GetChannel−>Mark() = 0;

GetChannelSHO−>Mark() = 0;

FirstReq−>Mark() = 1;

Output Gate: OGAdjust

Function

if (Signal−>Mark() && RachOK−>Mark() > 0)

{int iOtherChan = (ServChannels−>Mark() − Channel−>Mark());

int iOtherSHO = (ServChannelsSHO−>Mark() − ChannelSHO−>Mark());

if (iOtherChan > 0 || iOtherSHO > 0)

{if (!DisableHandover && Channel−>Mark())

{


GetChannelSHO−>Mark()++;

}}

}else{

if (Channel−>Mark() || ChannelSHO−>Mark())

{UnloadChannel−>Mark()++;

}}

Output Gate: OGCellSelected

Function

if (Signal−>Mark() > 0)

{if (RachFail−>Mark() == 0)

{PRACH−>Mark() = 1;

FirstTry−>Mark() = 1;

}}else{

CellsRandom−>Mark() = (rand() % CellCount−>Mark()) + 1;

}

Output Gate: OGDrop

Function

LoadFactor−>Downlink−>Mark() −= ServiceLoad−>Downlink−>Mark();

LoadFactor−>Uplink−>Mark() −= ServiceLoad−>Uplink−>Mark();

Output Gate: OGDropSHO

Function

LoadFactor−>Downlink−>Mark() −= ServiceLoadSHO−>Downlink−>Mark();

LoadFactor−>Uplink−>Mark() −= ServiceLoadSHO−>Uplink−>Mark();

Output Gate: OGGet

Function

double max dl = MaxLoad−>Downlink−>Mark() * Work−>Mark() / 100.0;;

double max ul = MaxLoad−>Uplink−>Mark() * Work−>Mark() / 100.0;;

double delta dl = ServiceLoad−>Downlink−>Mark() − ServiceLoadSHO−>Downlink−>Mark();

double delta ul = ServiceLoad−>Uplink−>Mark() − ServiceLoadSHO−>Uplink−>Mark();

if (ChannelSHO−>Mark() > 0)

{if (LoadFactor−>Downlink−>Mark() + delta dl <= max dl &&


LoadFactor−>Uplink−>Mark() + delta ul <= max ul)

{Channel−>Mark()++;

ServChannels−>Mark()++;

ChannelCount−>Mark()++;

ChannelSHO−>Mark()−−;

ServChannelsSHO−>Mark()−−;

ChannelCountSHO−>Mark()−−;

LoadFactor−>Downlink−>Mark() += delta dl;

LoadFactor−>Uplink−>Mark() += delta ul;

}}else if (Channel−>Mark() == 0)

{if (LoadFactor−>Downlink−>Mark() + ServiceLoad−>Downlink−>Mark() <= max dl &&

LoadFactor−>Uplink−>Mark() + ServiceLoad−>Uplink−>Mark() <= max ul)

{Channel−>Mark()++;

ServChannels−>Mark()++;

ChannelCount−>Mark()++;

LoadFactor−>Downlink−>Mark() += ServiceLoad−>Downlink−>Mark();

LoadFactor−>Uplink−>Mark() += ServiceLoad−>Uplink−>Mark();

}}

Output Gate: OGGetIndex

Function

CellCount−>Mark()++;

Index−>Mark() = CellCount−>Mark();

Output Gate: OGGetSHO

Function

double max dl = MaxLoad−>Downlink−>Mark() * Work−>Mark() / 100.0;;

double max ul = MaxLoad−>Uplink−>Mark() * Work−>Mark() / 100.0;;

double delta dl = ServiceLoad−>Downlink−>Mark() − ServiceLoadSHO−>Downlink−>Mark();

double delta ul = ServiceLoad−>Uplink−>Mark() − ServiceLoadSHO−>Uplink−>Mark();

if (Channel−>Mark() > 0)

{Channel−>Mark()−−;

ServChannels−>Mark()−−;

ChannelCount−>Mark()−−;

ChannelSHO−>Mark()++;

ServChannelsSHO−>Mark()++;

ChannelCountSHO−>Mark()++;

LoadFactor−>Downlink−>Mark() −= delta dl;

LoadFactor−>Uplink−>Mark() −= delta ul;

}


else if (ChannelSHO−>Mark() == 0)

{if (LoadFactor−>Downlink−>Mark() + ServiceLoadSHO−>Downlink−>Mark() <= max dl &&

LoadFactor−>Uplink−>Mark() + ServiceLoadSHO−>Uplink−>Mark() <= max ul)

{ChannelSHO−>Mark()++;

ServChannelsSHO−>Mark()++;

ChannelCountSHO−>Mark()++;

LoadFactor−>Downlink−>Mark() += ServiceLoadSHO−>Downlink−>Mark();

LoadFactor−>Uplink−>Mark() += ServiceLoadSHO−>Uplink−>Mark();

}}

Output Gate: OGLink

Function

if (DisableHandover)

{if (Channel−>Mark() || ChannelSHO−>Mark())

{RachComplete−>Mark()++;

RachOK−>Mark()++;

AskCells−>Mark() = 0;

SelectRandom−>Mark() = 0;

}else{

SelectRandom−>Mark()++;

}}else{

if (Signal−>Mark() > 0)

{if (Channel−>Mark() > 0 || ChannelSHO−>Mark() > 0)

{RachComplete−>Mark()++;

RachOK−>Mark()++;

}else{

if (RachFail−>Mark() == 0)



if (FirstReq−>Mark() == 0)

{Done−>Mark()++;

}else{

FirstReq−>Mark() = 0;

}}

}


}else{

if (PRACH−>Mark() > 0)


RachFail−>Mark() = 1;

}RachComplete−>Mark() = 1;

}}

Output Gate: OGRecover

Function

if (Signal−>Mark() > 0 && RachOK−>Mark() > 0)

{if (ChannelSHO−>Mark() > 0)

{GetChannel−>Mark()++;

}}

Output Gate: OGRequest

Function

if (CellRelease−>Mark() == 0)

{if (Signal−>Mark() > 0 && RachOK−>Mark() > 0)

{int iOtherChan = (ServChannels−>Mark() − Channel−>Mark());

int iOtherSHO = (ServChannelsSHO−>Mark() − ChannelSHO−>Mark());

if (iOtherChan+iOtherSHO == 0)

{GetChannel−>Mark()++;

}else{

if (!DisableHandover && ServChannelsSHO−>Mark() < MaxSHOLinks)

{GetChannelSHO−>Mark()++;

}}

}else{

UnloadChannel−>Mark()++;


}}

Output Gate: OGSetupFail


Function

RachFail−>Mark()++;

if (FirstTry−>Mark() > 0)

{FirstTry−>Mark() = 0;

Done−>Mark()++;

}

Output Gate: OGSetupOK

Function


RachComplete−>Mark()++;


Output Gate: OGUnload

Function

if (Channel−>Mark() > 0)

{Channel−>Mark()−−;

ServChannels−>Mark()−−;

ChannelCount−>Mark()−−;

LoadFactor−>Downlink−>Mark() −= ServiceLoad−>Downlink−>Mark();

LoadFactor−>Uplink−>Mark() −= ServiceLoad−>Uplink−>Mark();

Recover−>Mark()++;

}if (ChannelSHO−>Mark() > 0)

{ChannelSHO−>Mark()−−;

ServChannelsSHO−>Mark()−−;

ChannelCountSHO−>Mark()−−;

LoadFactor−>Downlink−>Mark() −= ServiceLoadSHO−>Downlink−>Mark();

LoadFactor−>Uplink−>Mark() −= ServiceLoadSHO−>Uplink−>Mark();

Recover−>Mark()++;

}if (NotifyRelease−>Mark())

{NotifyRelease−>Mark() = 0;

Recover−>Mark() = 0;

WaitRelease−>Mark()++;

}

Ogni modello servizio viene messo in join con un modello CellManager

per ogni stazione base presente nel sistema. Una transizione di inizializzazio-ne, GetIndex, permette di assegnare un indice diverso a ciascun modello edi contare il numero di modelli presenti. La transizione scatta una sola voltain ogni modello, grazie all’unico token posto in Init, ed esegue il codice delgate OGInit. In pratica ogni modello aumenta di uno il valore di CellCount


e assume il risultato come proprio indice, posizionandolo in Index. Alla finedell’inizializzazione CellCount conterra il numero di modelli CellManager eognuno avra un valore diverso nel place Index. Il place CellCount e condi-viso con il modello Service. Il place Signal contiene un token se l’utentesi trova in una zona raggiunta dalla stazione base ed e condiviso con il mo-dello UserMovement. I place ServiceLoad e ServiceLoadSHO rappresentanoil carico del servizio, normale e in soft handover. Essi vengono condivisi conil modelloStartup e eventualmente tra i modelli CellManager, se il servizioapporta lo stesso carico su tutte le stazioni base. Il place Work e condivi-so con il modello cella associato e contiene inizialmente 100 token. Il caricoistantaneo e massimo della cella sono rappresentati rispettivamente dai placeLoadFactor e MaxLoad, entrambi condivisi con il modello BaseStation.

La transizione Link e abilitata quando AskCells contiene un numero ditoken pari all’indice del modello. Quando la transizione scatta il valore diAskCells viene decrementato di un token. In questo modo la richiesta vieneelaborata da tutti i modelli una sola volta, a partire da quello di indice piualto, fino a quello che ha come indice il valore uno. La transizione provocal’esecuzione del codice del gate OGLink. Come si vede dal listato, si ha unadistinzione tra la situazione con handover disabilitato e abilitato. Se l’han-dover e disabilitato si controlla se il modello ha gia allocato dei canali perl’utente e in caso positivo si prosegue saltando l’esecuzione della procedura diaccesso, altrimenti si richiede la selezione casuale al modello ServiceManager.Se invece si ha la normale situazione con handover abilitato, si controlla sel’utente e raggiunto dalla stazione base. In caso positivo si hanno due possi-bilita: se l’utente ha gia allocato un canale, si salta la procedura di accesso,altrimenti viene inserito un token nel place PRACH, che rappresenta l’iniziodella procedura di accesso casuale. Se invece la cella non raggiunge l’utente eSignal non contiene quindi token, si annulla l’esecuzione della procedura diaccesso, se precedentemente avviata, e si segnala il completamento di questafase, tramite il place RachComplete.

La transizione Setup rappresenta l’esecuzione della procedura di accesso epresenta due casi: uno per il fallimento e uno per il successo. In caso di falli-mento viene eseguito il gate OGSetupFail. Come prima azione viene aggiuntoun token al place RachFail, da cui dopo un tempo di attesa, rappresentatodalla transizione RachDelay il terminale tentera nuovamente di eseguire laprocedura. Successivamente, se e il primo tentativo effettuato, si segnala al


modello Service di avere eseguito la procedura. Questo serve per l’avvio delservizio, in cui si deve attendere che tutte le celle abbiano eseguito la proce-dura prima di dichiarare fallita la richiesta; negli altri i tentativi di accessopossono essere effettuati in maniera asincrona, segnalando solamente quan-do si ha successo. Se invece la procedura ha successo viene eseguito il gateOGSetupOK. Il token posto in RachComplete abilita la transizione Request,che scattando fa eseguire il codice nel gate OGRequest. Se e stato richiesto ilrilascio delle risorse, il codice viene saltato, altrimenti si controlla se l’utentee raggiunto dalla stazione base ed ha completato con successo la proceduradi accesso casuale. In caso positivo si contano i canali allocati al servizio datutte le celle. Se non e ancora stato allocato nessun canale ne viene richiestouno normale, altrimenti se ne richiede uno in soft handover, ma solamente sel’handover e abilitato e non abbiamo superato il massimo numero di connes-sioni possibili, dettato dalla variabile globale MaxSHOLinks. In tutti gli altricasi viene posto un token nel place UnloadChannel, che indica di disallocareeventuali canali allocati.

In base al tipo di richiesta effettuata, scattera una delle transizioni Get,GetSHO o Unload, eseguendo l’output gate corrispondente e aggiungendo untoken nel place Done, condiviso tra ServiceManager e tutti i relativi modelliCellManager. Il gate OGGet alloca un canale sulla cella, se possibile, aggior-nando il carico della cella e aumentando di conseguenza i place che contanoi canali allocati alla cella (ChannelCount) e al servizio (ServChannels). Sesulla stessa cella e gia allocato un canale per lo stesso utente la richiesta vienesemplicemente ignorata, mentre se e gia allocato un canale in soft handoverviene calcolata la differenza di carico necessaria e convertito il tipo di canale.

Allo steso modo l’output gate OGGetSHO esegue le stesse operazioni per icanali in soft handover. Anche in questo caso se il canale e gia allocato la ri-chiesta viene ignorata, mentre se e allocato un canale normale viene convertito,diminuendo il carico sulla cella.

Quando viene richiesto il rilascio di tutte le risorse, vengono posti inCellRelease un numero di token pari a CellCount, abilitando cosı la tran-sizione Release. Come nel caso di AskCells, il place CellRelease vienedecrementato di un token alla volta, cosı che tutti i modelli eseguano l’opera-zione di rilascio. La funzione di input di IGRelease riporta il modello nellostato iniziale, annullando eventuali operazioni avviate.


L’esecuzione della transizione Release causa l’esecuzione del codice delgate OGRelease, che viene eseguito anche per la transizione Unload. Que-sto output gate rilascia i canali eventualmente allocati, aggiornando i canalicontatore e il carico della stazione base. Inoltre, se ci troviamo nella fase dirilascio delle risorse il place NotifyRelease contiene un token e viene percioaggiunto un token nel place WaitRelease, per segnalare di aver completato laprocedura di rilascio.

Per quanto riguarda la gestione degli outage, i place Outage e OutageSHO

sono condivisi con il modello BaseStation relativo e in caso di guasti conten-gono il numero di utenti da scartare per quel tipo di servizio. Se l’utente haallocato un canale e sono presenti token nel relativo place di outage, scatta latransizione Drop o DropSHO, che disalloca i canali, e viene eseguito il rispettivooutput gate, che aggiorna il carico della cella. L’output gate OGDrop semplice-mente sottrae al carico della cella il carico del servizio, cosı come OGDropSHO

sottrae il carico in soft handover. Entrambe queste transizioni aggiungono untoken nel place Recover, che segnalano la necessita di far proseguire il serviziosu di un altra cella, se possibile. Questa richiesta viene smistata dal modelloServiceManager a tutte le celle, tramite il place CellRecover. La transizio-ne TryRecover scattando toglie un token al place CellRecover ed esegue ilcodice del gate OGRecover. Il recupero avviene semplicemente richiedendo uncanale normale, nel caso ne sia gia allocato uno in soft handover; in caso con-trario viene aggiunto un token nel place Done per segnalare di aver comunqueprocessato la richiesta.

La transizione Adjust si occupa di verificare che siano utilizzate il minimonumero di risorse necessarie per far eseguire il servizio, in modo da non avererisorse utilizzate inutilmente, ad esempio due canali normali invece che duein soft handover. Essa e abilitata quando CellAdjust contiene un numero ditoken pari a CellCount e scattando esegue la transizione del gate OGAdjust.In pratica viene richiesto un canale in soft handover se sulla cella e allocato uncanale normale ma si verifica che sulle altre celle sono gia allocati altri canali.

Infine, la transizione CellSelected gestisce la selezione casuale di unacella da parte del modello ServiceManager. Essa e abilitata quando sonopresenti un numero di token pari a CellCount in CellsRandom ma scattando,al contrario delle altre transizioni, questo place viene azzerato. Proprio perquesto, solamente la cella selezionata eseguira la transizione, come voluto.Quando la transizione scatta viene eseguito l’output gate OGCellSelected.


Se la cella selezionata raggiunge l’utente quindi, viene avviata la proceduradi accesso, altrimenti ne viene selezionata un altra, tramite la funzione rand,e il valore posto ancora in CellsRandom. La nuova cella selezionata eseguiraquindi lo stesso codice, selezionando un’altra cella ancora se necessario, e cosıvia finche non si seleziona una stazione che ha un token nel place Signal.

A.7 Modello Startup

Il modello di inizializzazione per sua stessa natura e diverso per ogni scenarioche si vuole analizzare. Questa sezione riporta la documentazione per unesempio di modello Startup, per una rete con due stazioni base e tre servizi.

Bucket Attributes:


Begin 1

FailTimeA 0

FailTimeB 0

MaxLoad 0

PercOutageA 0

PercOutageB 0

RecoverTimeA 0

RecoverTimeB 0

ServiceLoadSHO 1 0

ServiceLoadSHO 2 0

ServiceLoadSHO 3 0

ServiceLoad 1 0

ServiceLoad 2 0

ServiceLoad 3 0

ServiceTime1 0

ServiceTime2 0

ServiceTime3 0

UserStartA 0

UserStartAB 0

UserStartB 0

A.7 Modello Startup 127


Initialize

Output Gate: OGInitialize

Function

ServiceTime1−>Mark() = tService1;



UserStartA−>Mark() = nStartA;

UserStartAB−>Mark() = nStartAB;

UserStartB−>Mark() = nStartB;

FailTimeA−>Mark() = tCellFailA;

RecoverTimeA−>Mark() = tCellRecoverA;

PercOutageA−>Mark() = iOutagePercentA;

FailTimeB−>Mark() = tCellFailB;

RecoverTimeB−>Mark() = tCellRecoverB;

PercOutageB−>Mark() = iOutagePercentB;

MaxLoad−>Downlink−>Mark() = lMaxDownlink;

MaxLoad−>Uplink−>Mark() = lMaxUplink;

ServiceLoad 1−>Downlink−>Mark() = lServ1 dl;

ServiceLoad 1−>Uplink−>Mark() = lServ1 ul;





ServiceLoadSHO 1−>Downlink−>Mark() = lServSHO1 dl;

ServiceLoadSHO 1−>Uplink−>Mark() = lServSHO1 ul;





I place ServiceTimeN devono essere condivisi ciascuno con un diverso mo-dello Service, mentre i place ServiceLoad N e ServiceLoadSHO N devonoessere condivisi con i corrispondenti place dei modelli CellManager. Il placeMaxLoad rappresenta il massimo carico accettabile da una cella, che in questocaso si suppone uguale per tutte le stazioni base e dovra quindi essere con-diviso con il place MaxLoad di tutti i modelli BaseStation presenti. I placeFailTimex, RecoverTimeX e PercOutageX vengono condivisi ognuno con larispettiva cella, eventualmente impostando il valore di PercOutageX a 0 per


disabilitare il guasto nella stazione base. I place UserStartA, UserStartABe UserStartB contengono il numero di utenti che devono iniziare la loro esi-stenza nella zona associata e devono essere condivisi con gli omonimi place nelmodello User.

Il marking di questi place viene assegnato dall’output gate OGInitalize,che semplicemente assegna il valore delle variabili ai corrispondenti place. Latransizione Initialize scatta una e una sola volta, visto che il place Begin

contiene inizialmente un solo token.

A.8 Composizione

In questa sezione riportiamo la documentazione prodotta dal tool Mobius peril modello composto, nel caso di un sistema con quattro stazioni base e utentiche richiedono una sola classe di servizio.

Rep Node Reps Shared State Variables

UsersRep MaxUsers ChannelCountA1

ChannelCountB1

ChannelCountC1

ChannelCountD1

ChannelCountSHO A1

ChannelCountSHO B1

ChannelCountSHO C1

ChannelCountSHO D1

LoadFactorA

LoadFactorB

LoadFactorC

LoadFactorD

MaxLoad

OutageA1

A.8 Composizione 129

OutageB1

OutageC1

OutageD1

OutageSHO A1

OutageSHO B1

OutageSHO C1

OutageSHO D1

ServiceLoad 1

ServiceLoadSHO 1

ServiceTime1

UserStartA

WorkA

WorkB

WorkC

WorkD

Join Node: FullJoin

State Variable Name Submodel Variables

ChannelCountA1 UsersRep−>ChannelCountA1

BaseStationA−>ChannelCount1

ChannelCountB1 UsersRep−>ChannelCountB1

BaseStationB−>ChannelCount1

ChannelCountC1 UsersRep−>ChannelCountC1

BaseStationC−>ChannelCount1

ChannelCountD1 UsersRep−>ChannelCountD1

BaseStationD−>ChannelCount1

ChannelCountSHO A1 UsersRep−>ChannelCountSHO A1

BaseStationA−>ChannelCountSHO 1

ChannelCountSHO B1 UsersRep−>ChannelCountSHO B1

BaseStationB−>ChannelCountSHO 1

ChannelCountSHO C1 UsersRep−>ChannelCountSHO C1

BaseStationC−>ChannelCountSHO 1

ChannelCountSHO D1 UsersRep−>ChannelCountSHO D1

BaseStationD−>ChannelCountSHO 1

LoadFactorA UsersRep−>LoadFactorA

BaseStationA−>LoadFactor

LoadFactorB UsersRep−>LoadFactorB

BaseStationB−>LoadFactor

LoadFactorC UsersRep−>LoadFactorC

BaseStationC−>LoadFactor

LoadFactorD UsersRep−>LoadFactorD

BaseStationD−>LoadFactor

ServiceLoad 1 UsersRep−>ServiceLoad 1

Startup−>ServiceLoad 1

ServiceLoadSHO 1 UsersRep−>ServiceLoadSHO 1

Startup−>ServiceLoadSHO 1

MaxLoad UsersRep−>MaxLoad

BaseStationA−>MaxLoad

BaseStationB−>MaxLoad


BaseStationC−>MaxLoad

BaseStationD−>MaxLoad

Startup−>MaxLoad

ServiceTime1 UsersRep−>ServiceTime1

Startup−>ServiceTime1

FailTime Startup−>FailTime

BaseStationA−>FailTime

BaseStationB−>FailTime

BaseStationC−>FailTime

BaseStationD−>FailTime

OutageA1 UsersRep−>OutageA1

BaseStationA−>Outage1

OutageB1 UsersRep−>OutageB1

BaseStationB−>Outage1

OutageC1 UsersRep−>OutageC1

BaseStationC−>Outage1

OutageD1 UsersRep−>OutageD1

BaseStationD−>Outage1

OutageSHO A1 UsersRep−>OutageSHO A1

BaseStationA−>OutageSHO 1

OutageSHO B1 UsersRep−>OutageSHO B1

BaseStationB−>OutageSHO 1

OutageSHO C1 UsersRep−>OutageSHO C1

BaseStationC−>OutageSHO 1

OutageSHO D1 UsersRep−>OutageSHO D1

BaseStationD−>OutageSHO 1

PercOutage Startup−>PercOutage

BaseStationA−>PercOutage

BaseStationB−>PercOutage

BaseStationC−>PercOutage

BaseStationD−>PercOutage

RecoverTime Startup−>RecoverTime

BaseStationA−>RecoverTime

BaseStationB−>RecoverTime

BaseStationC−>RecoverTime

BaseStationD−>RecoverTime

UtentiStartA UsersRep−>UtentiStartA

Startup−>UtentiStartA

WorkA UsersRep−>WorkA

BaseStationA−>Work

WorkB UsersRep−>WorkB

BaseStationB−>Work

WorkC UsersRep−>WorkC

BaseStationC−>Work

WorkD UsersRep−>WorkD

BaseStationD−>Work

Join Node: ServiceJoin1


AskCells ServiceManager1−>AskCells


CellManagerA1−>AskCells

CellManagerB1−>AskCells

CellManagerC1−>AskCells

CellManagerD1−>AskCells

AskResources Service1−>AskResources

ServiceManager1−>AskResources

ChannelCountA1 CellManagerA1−>ChannelCount

ChannelCountB1 CellManagerB1−>ChannelCount

ChannelCountC1 CellManagerC1−>ChannelCount

ChannelCountD1 CellManagerD1−>ChannelCount

ChannelCountSHO A1 CellManagerA1−>ChannelCountSHO

ChannelCountSHO B1 CellManagerB1−>ChannelCountSHO

ChannelCountSHO C1 CellManagerC1−>ChannelCountSHO

ChannelCountSHO D1 CellManagerD1−>ChannelCountSHO

LoadFactorA CellManagerA1−>LoadFactor

LoadFactorB CellManagerB1−>LoadFactor

LoadFactorC CellManagerC1−>LoadFactor

LoadFactorD CellManagerD1−>LoadFactor

ServiceLoad CellManagerA1−>ServiceLoad

CellManagerB1−>ServiceLoad

CellManagerC1−>ServiceLoad

CellManagerD1−>ServiceLoad

ServiceLoadSHO CellManagerA1−>ServiceLoadSHO

CellManagerB1−>ServiceLoadSHO

CellManagerC1−>ServiceLoadSHO

CellManagerD1−>ServiceLoadSHO

CellAdjust ServiceManager1−>CellAdjust

CellManagerA1−>CellAdjust

CellManagerB1−>CellAdjust

CellManagerC1−>CellAdjust

CellManagerD1−>CellAdjust

CellCount ServiceManager1−>CellCount

CellManagerA1−>CellCount

CellManagerB1−>CellCount

CellManagerC1−>CellCount

CellManagerD1−>CellCount

CellRecover ServiceManager1−>CellRecover

CellManagerA1−>CellRecover

CellManagerB1−>CellRecover

CellManagerC1−>CellRecover

CellManagerD1−>CellRecover

CellRelease ServiceManager1−>CellRelease

CellManagerA1−>CellRelease

CellManagerB1−>CellRelease

CellManagerC1−>CellRelease

CellManagerD1−>CellRelease

MaxLoad CellManagerA1−>MaxLoad

CellManagerB1−>MaxLoad

CellManagerC1−>MaxLoad

CellManagerD1−>MaxLoad


CellsRandom ServiceManager1−>CellsRandom

CellManagerA1−>CellsRandom

CellManagerB1−>CellsRandom

CellManagerC1−>CellsRandom

CellManagerD1−>CellsRandom

Done ServiceManager1−>Done

CellManagerA1−>Done

CellManagerB1−>Done

CellManagerC1−>Done

CellManagerD1−>Done

ServiceTime Service1−>ServiceTime

Idle Service1−>Idle

Move Service1−>Move

OutageA1 CellManagerA1−>Outage

OutageB1 CellManagerB1−>Outage

OutageC1 CellManagerC1−>Outage

OutageD1 CellManagerD1−>Outage

OutageSHO A1 CellManagerA1−>OutageSHO

OutageSHO B1 CellManagerB1−>OutageSHO

OutageSHO C1 CellManagerC1−>OutageSHO

OutageSHO D1 CellManagerD1−>OutageSHO

Recover ServiceManager1−>Recover

CellManagerA1−>Recover

CellManagerB1−>Recover

CellManagerC1−>Recover

CellManagerD1−>Recover

Release Service1−>Release

ServiceManager1−>Release

ReleaseOK Service1−>ReleaseOK

ServiceManager1−>ReleaseOK

Req1 Service1−>Req

ServiceManager1−>Req

RisorseBlock Service1−>RisorseBlock

ServiceManager1−>RisorseBlock

RisorseOK Service1−>RisorseOK

ServiceManager1−>RisorseOK

SelectRandom ServiceManager1−>SelectRandom

CellManagerA1−>SelectRandom

CellManagerB1−>SelectRandom

CellManagerC1−>SelectRandom

CellManagerD1−>SelectRandom

ServChannels ServiceManager1−>ServChannels

CellManagerA1−>ServChannels

CellManagerB1−>ServChannels

CellManagerC1−>ServChannels

CellManagerD1−>ServChannels

ServChannelsSHO ServiceManager1−>ServChannelsSHO

CellManagerA1−>ServChannelsSHO

CellManagerB1−>ServChannelsSHO

CellManagerC1−>ServChannelsSHO


CellManagerD1−>ServChannelsSHO

SignalA CellManagerA1−>Signal

SignalB CellManagerB1−>Signal

SignalC CellManagerC1−>Signal

SignalD CellManagerD1−>Signal

WaitRelease ServiceManager1−>WaitRelease

CellManagerA1−>WaitRelease

CellManagerB1−>WaitRelease

CellManagerC1−>WaitRelease

CellManagerD1−>WaitRelease

WorkA CellManagerA1−>Work

WorkB CellManagerB1−>Work

WorkC CellManagerC1−>Work

WorkD CellManagerD1−>Work

Join Node: UserJoin


ChannelCountA1 ServiceJoin1−>ChannelCountA1

ChannelCountB1 ServiceJoin1−>ChannelCountB1

ChannelCountC1 ServiceJoin1−>ChannelCountC1

ChannelCountD1 ServiceJoin1−>ChannelCountD1

ChannelCountSHO A1 ServiceJoin1−>ChannelCountSHO A1

ChannelCountSHO B1 ServiceJoin1−>ChannelCountSHO B1

ChannelCountSHO C1 ServiceJoin1−>ChannelCountSHO C1

ChannelCountSHO D1 ServiceJoin1−>ChannelCountSHO D1

LoadFactorA ServiceJoin1−>LoadFactorA

LoadFactorB ServiceJoin1−>LoadFactorB

LoadFactorC ServiceJoin1−>LoadFactorC

LoadFactorD ServiceJoin1−>LoadFactorD

ServiceLoad 1 ServiceJoin1−>ServiceLoad

ServiceLoadSHO 1 ServiceJoin1−>ServiceLoadSHO

MaxLoad ServiceJoin1−>MaxLoad

ServiceTime1 ServiceJoin1−>ServiceTime

Idle ServiceJoin1−>Idle

User−>Idle

Move ServiceJoin1−>Move

User−>Move

UserMovement−>Move

OutageA1 ServiceJoin1−>OutageA1

OutageB1 ServiceJoin1−>OutageB1

OutageC1 ServiceJoin1−>OutageC1

OutageD1 ServiceJoin1−>OutageD1

OutageSHO A1 ServiceJoin1−>OutageSHO A1

OutageSHO B1 ServiceJoin1−>OutageSHO B1

OutageSHO C1 ServiceJoin1−>OutageSHO C1

OutageSHO D1 ServiceJoin1−>OutageSHO D1

Req1 User−>Req1

ServiceJoin1−>Req1


SignalA ServiceJoin1−>SignalA

User−>SignalA

UserMovement−>SignalA

SignalB ServiceJoin1−>SignalB

User−>SignalB

UserMovement−>SignalB

SignalC ServiceJoin1−>SignalC

User−>SignalC

UserMovement−>SignalC

SignalD ServiceJoin1−>SignalD

User−>SignalD

UserMovement−>SignalD

UserStartA User−>UserStartA

WorkA ServiceJoin1−>WorkA

WorkB ServiceJoin1−>WorkB

WorkC ServiceJoin1−>WorkC

WorkD ServiceJoin1−>WorkD

UpdateSignal User−>UpdateSignal

UserMovement−>UpdateSignal

ZoneA User−>ZoneA

UserMovement−>ZoneA

Analisi e valutazione di reti UMTS - UniFI

Documents

Transcript of Analisi e valutazione di reti UMTS - UniFI