UMTS - Protocolli Radio

Capitolo 3 Il sistema UMTS - I protocolli radio
Dopo aver esaminato nel Capitolo 2 larchitettura dei protocolli dellUTRAN, si descrivono ora i vari livelli dei protocolli di accesso radio. In particolare si analizzano le funzionalit e i servizi offerti da ciascun livello, le interazioni tra i vari strati e il Radio Resource Control (RRC) con le problematiche di gestione delle risorse radio.
3.1 Architettura generale dei protocolli radio

Linterfaccia radio pu essere suddivisa in tre livelli:
il livello Fisico (o livello 1); il livello Data Link (o livello 2); il livello Network (o livello 3).
La figura 3.1 illustra questa struttura, evidenziando anche una divisione dei livelli in due piani: il piano di controllo e il piano dutente. Questo implic a che linformazione che transita attraverso la rete di accesso possa essere di segnalazione o derivante dal servizio dutente. Poich i livelli 1 e 2 offrono una base di trasporto sia alla segnalazione sia allinformazione dutente, sono disposti trasver salmente rispetto ai piani di Controllo e dUtente. Il livello 2 a sua volta suddiviso nei seguenti sottolivelli: il Medium Access Control (MAC), il Radio Link Control (RLC), il Packet Data Convergence Protocol (PDCP) e il Broadcast/Multicast Control (BMC). I livelli PDCP e BMC esistono solo nel piano dutente. Anche il livello 3 diviso in piano di controllo e dutente. Dal momento che questo livello, allinterno dellUTRAN, per fondamentalmente responsabile della gestione della segnalazione, collocato interamente nel piano di controllo. Nel Control plane il livello rete pu essere diviso in sottolivelli. Quello pi basso
22
3 Il sistema UMTS - I protocolli radio definito RRC e si interfaccia con il livello 2 e termina nellUTRAN. Il sottolivello superiore invece fornisce funzionalit di Duplication avoidance e termina nella Core Network, ma fa ancora parte dellAccess stratum. Esso fornisce i servizi ai livelli superiori come il Mobility Management (MM) e il Call Control (CC), situati nel Non Access stratum.
DC
GC
Nt
Duplication avoidance GC C-plane signalling Nt DC UuS boundary U-plane information
RRC
control
L3
Radio Bearers PDCP PDCP
control
control
control control
L2/PDCP
BMC
L2/BMC
RLC RLC RLC RLC RLC RLC RLC
RLC
L2/RLC
Logical Channels MAC
L2/MAC
Transport Channels
PHY
L1
Figura 3.1 : Architettura protocollare dellinterfaccia radio
Ogni blocco in figura 3.1 rappresenta una particolare istanza del corrispondente protocollo. I Service Access Point per le comunicazioni tra pari entit sono rappresentati con dei cerchi sulle interfacce tra i sottolivelli. I SAP tra il livello fisico e il MAC forniscono i canali di trasporto, mentre quelli tra il MAC e RLC forniscono i canali logici. Nel piano di controllo linterfaccia tra il livello Duplication Avoidance e i sottolivelli superiori del livello rete sono costituiti dai GC, Nt e DC SAP.
23
3 Il sistema UMTS - I protocolli radio Sono inoltre visibili le connessioni tra i livelli RRC e MAC, RRC e RLC, RRC e BMC, RRC e PDCP, RRC e livello fisico, tutte realizzate tramite Control SAP. Questi legami sono giustificati dal fatto che lRRC svolge un ruolo fondamentale nella gestione delle risorse radio. Pertanto Il Radio Resource Control deve essere capace di gestire e controllare i livelli inferiori e di procurarsi i parametri di ingresso per le procedure di Radio Resource Management (RRM). E importante sottolineare che non esistono differenze tra le entit RLC allinterno del piano di controllo e allinterno del piano dutente.
3.2 Il livello Fisico

Il livello fisico il pi basso livello allinterno della pila pr otocollare. Come si vede dalla figura 3.1 esso si interfaccia con il Medium Access Control e con il Radio Resource Control, offrendo servizi di trasferimento sulla portante fisica delle informazioni (bit) generate dai livelli superiori. Le primitive di comunicazione con il MAC (PHY-primitives) forniscono il trasferimento dei transport block (TB) sullinterfaccia radio e lindicazione dello stato del livello 1 al MAC; le primitive di comunicazione con lRRC invece ( CPHYprimitives) forniscono il controllo della configurazione del livello fisico. Per transport block si intende lunit base di informazione trasferita tra il MAC e il livello 1. In genere un TB corrisponde ad una PDU di livello RLC, alla quale viene aggiunto il campo CRC dal livello fisico per consentire il rilevamento di eventuali errori al MAC in ricezione. Un insieme di Transport Block viene indicato con Transport Block Set. I servizi di trasporto di questo livello sono definiti da quante risorse e con quali caratteristiche i dati sono trasferiti sullinterfaccia radio. Il trasferimento tra il livello fisico e il MAC e viceversa avviene tramite i canali di trasporto. Le caratteristiche di questi canali sono determinate da un formato di trasporto o da un insieme di formati di trasporto. In particolare ai Transport channel con tasso fisso o lentamente variabile associato un Transport Format, mentre a quelli con tasso fortemente variabile associato un Transport Format Set. Per Transport Format si intende il formato utilizzato per la consegna di un transport block set tra il MAC e il livello 1. Esso realizzato dalla combinazioni di due parti: una dinamica e una statica. Nella modalit FDD, la prima parte comprende il numero di bit contenuti in un TB e in un TBS (rispettivamente definiti come il transport block size e il transport block set size). La parte statica invece definisce il tipo di codice da applicare, il rate del codice, le dimensioni del campo CRC e il tempo di interarrivo dei TBS (definito come Transmission Time Interval TTI).
24
3 Il sistema UMTS - I protocolli radio
3.2.1 I canali di trasporto

I canali di trasporto sono i servizi offerti dal livello 1 ai livelli superiori. possono essere raggruppati in due tipologie:
Essi
Canali di trasporto comuni: linformazione trasmessa indistintamente a tutti i terminali mobili. E quindi necessaria unidentificazione degli UE. Canali di trasporto dedicati: la comunicazione avviene verso un singolo terminale associando un particolare canale fisico (codice e frequenza nella modalit FDD, codice frequenza e time slot nella modalit TDD).
Sono previsti i seguenti canali comuni:
Random Access Channel (RACH) E un canale a contesa in uplink per la trasmissione di una quantit di dati di controllo relativamente ridotta come la richiesta di accesso al mezzo fisico per iniziare una comunicazione. Al messaggio trasmesso possono essere associati brevi pacchetti dati.
Common Pachet Channel (CPCH) E un canale a contesa in uplink per la trasmissione di traffico dati con caratteristica a burst. Esiste solo nella modalit FDD ed condiviso da tutti gli utenti di una cella.
Forward Access Channel (FACH) E utilizzato in downlink senza controllo di potenza ad anello chiuso per la trasmissione di una quantit di dati relativamente ridotta. E caratterizzato dalla possibilit di cambiare velocemente la velocit di trasmissione.
Downlink Shared Channel (DSCH) E un canale in downlink condiviso da pi utenti per trasportare dati utente o di segnalazione. Laccesso regolato dalla stazione base.
Uplink Shared Channel (USCH) E un cana le in uplink condiviso da diversi utenti, utilizzato nella sola modalit TDD. Serve per il trasporto di dati dutente o di controllo.
Broadcast Channel (BCH) Viene usato in downlink per trasmettere in tutta la cella le informazioni di sistema.
25
Paging Channel (PCH) Serve per trasmettere in downlink informazioni di controllo ad un mobile di cui non si conosce la posizione. Alcuni esempi dei messaggi diffusi sono quelli di paging o di notifica di una variazione delle informazioni diffuse sul BCH.
E inv ece previsto un solo tipo di canale dedicato:
Dedicated Channel (DCH) E un canale utilizzato sia in uplink sia in downlink per trasportare informazioni dutente e di controllo tra il mobile e la rete. E caratterizzato dalla possibilit di cambiare la velocit di trasmissione ogni trama temporale.
3.2.2 I canali fisici

Come accade per i canali di trasporto, possibile suddividere i canali fisici tra comuni e dedicati. Tra i canali comuni troviamo:
Physical Random Access Channel (PRACH) E un canale comune i n uplink utilizzato per trasportare il RACH. La trasmissione ad accesso casuale di tipo Slotted-ALOHA con rapida indicazione di acquisizione.
Physical Common Packet Channel (PCPCH) E un canale in uplink usato per trasportare il CPCH. La trasmissione di tipo DSMA-CD con rapida indicazione di acquisizione.
Common Pilot Channel (CPICH) Canale fisico in downlink finalizzato al trasporto di una sequenza di bit predefinita con velocit di bit e di simbolo costante. Serve per poter effettuare la stima del canale di propagazione.
Primary Common Control Physical Channel (P-CCPCH) Canale in downlink per trasportare il BCH a velocit fissa.
Secondary Common Control Physical Channel (S-CCPCH) Canale in downlink per trasportare il FACH e il PCH.
Physical Downlink Shared Channel (PDSCH) E un canale presente solo in downlink usato per trasportare il DSCH. E condiviso da pi UE grazie alla multiplazione di codice.
26
Synchronisation Channel (SCH) Canale in downlink usato per la ricerca della cella.
Acquisition Indicator Channel (AICH) E presente in downlink. Viene utilizzato per informare il mobile che presente sul FACH un messaggio, in risposta ad un tentativo di accesso.
Paging Indication Channel (PICH) E presente in downlink. Indica al mobile che presente un messaggio di paging sul canale PCH.
Canale di trasporto
BCH
Canale fisico corrispondente

P-CCPCH CPICH
SCH FACH PCH RACH CPCH(FDD) USCH(TDD) DSCH DCH
PSCH S-CCPCH S-CCPCH PRACH PCPCH PDSCH PDSCH DPDCH DPCCH AICH PICH
Tabella 3.1 : Corrispondenza tra canali fisici e di trasporto
I canali fisici dedicati invece sono:
Dedicated Physical Data Channel (DPDCH) E un canale utilizzato per trasportare i dati inviati dai livelli superiori sul DCH. Possono esistere uno, nessuno o pi DPDCH per ogni connessione di livello 1.
Dedicated Physical Control Channel (DPCCH) Canale fisico presente in entrambe le tratte, viene utilizzato per trasportare la segnalazione di livello 1.
27
3 Il sistema UMTS - I protocolli radio Nella tabella 3.1 si riporta la corrispondenza tra canali fisici e canali di trasporto. Si pu notare che esistono alcuni canali fisici a cui non corrisponde alcun canale di trasporto. Questo si spiega con il fatto che tali canali trasportano solo informazioni di livello fisico da non inviare ai livelli superiori.
3.2.3 Funzioni
Il livello fisico realizza le seguenti funzioni:
Gestione della macrodiversit ed esecuzione dei soft-handover. Rilevamento degli errori sui canali di trasporto e indicazione ai livelli superiori. Codifica e decodifica FEC (Forward Error Correction), interleaving e deinterleaving dei canali di trasporto. Multiplexing dei canali di trasporto e demultiplexing dei Coded Composite Transport Channel (CCTrCH). Adattamento della velocit di trasmissione. Mappatura dei CCTrCH sui canali fisici. Modulazione e demodulazione, spreading e despreading dei canali fisici. Sincronizzazione di tempo e frequenza (chip, bit, slot, frame). Misurazioni ed indicazione ai livelli superiori. Controllo di potenza ad anello chiuso. Processamento a radio frequenza.
Tra queste funzionalit, si esamina adesso in dettaglio loperazione di spreading. 3.2.3.1 Canalizzazione e Scrambling Una caratteristica distintiva del sistema UMTS la multiplazione a divisione di codice. Al fine di trasmettere i segnali, risulta quindi importante ricorrere alla tecnica di spreading, da applicare ai canali fisici e caratterizzata da due operazioni. La prima la canalizzazione, che trasforma ogni simbolo in un numero di chip, aumentando cos la larghezza di banda del segnale. Il numero di chip per simbolo viene definito Spreading Factor (SF). La seconda loperazione di scrambling, tramite la quale alla sequenza di chip precedentemente ottenuta viene applicato un codice di scrambling. Con la canalizzazione i simboli sui rami I e Q (dove con I e Q si intende rispettivamente parte reale e immaginaria del segnale) vengono moltiplicati in modo indipendente per un codice OVSF (Orthogonal Variable Spreading Factor). Con la seconda operazione invece i segnali risultanti vengono moltiplicati per un codice di scrambling complesso.
28
C ch,4,0 = (1,1 ,1 ,1 ) C ch,2,0 = (1,1) C ch,4,1 = (1,1,-1 ,-1 ) C ch,1,0 = (1) C ch,4,2 = (1,-1 ,1,-1 ) C ch,2,1 = (1,-1 ) C ch,4,3 = (1,-1 ,-1 ,1) SF = 1 SF = 2 SF = 4
Figura 3.2 : Albero dei codici OVSF
I codici OVSF possono essere definiti introducendo lalbero riportato in figura 3.2. Questi codici sono etichettati con il simbolo Cch,SF,k, dove SF il fattore di spreading variabile da 4 a 512 per un chip rate in aria di 3.84 Mcps, mentre k il numero del codice, variabile nellintervallo 0 -1. Ogni livello nellalbero dei codici definisce un codice di canalizzazione di lunghezza pari a SF e corrisponde ad un fattore di spreading proprio uguale a SF. Il metodo per generare questi codici cos definito:
"! C 1 )

Cch,1,0
1,
ch , 2, 0
# 5 $ ( 1) C ) % 5 $ & )) C ) & & C ) C %5$ & ) C & ) C %5$ &3 ) C 2 C && ) & ) ) & : & ) : : )C %5$ %5$ & )C & 6 & ) 4 C 4 & )0 C % 5 $ % 5 $4 ' & 0 C 4 2 C 4 '&
C ch , 2 n 1 , 0 C ch , 2 n 1 ,1
ch , 2 n 1 , 2 ch , 2 n 1 , 3 ch , 2n , 0 ch , 2n , 0 ch , 2n ,1 ch , 2n ,1 ch , 2 n , 0 ch , 2n , 0 ch , 2n ,1 ch , 2n ,1 ch , 2 n 1 , 2 n 1 2 ch , 2 n 1 , 2 n 1 1 ch , 2n , 2n 1 ch , 2n , 2n 1 ch , 2 n , 2n 1 ch , 2n , 2n 1
Cch, 2,1
"! C
ch ,1, 0
C
ch ,1, 0
Cch,1, 0
Cch,1, 0
1 1 1 1 ( C & 2 C
29
3 Il sistema UMTS - I protocolli radio Lallocazione dei codici assegna codici differenti a diverse connessioni. I codici OVSF hanno infatti la caratteristica di essere non correlati e di preservare quindi lortogonalit tra i diversi canali fisici degli utenti anche a velocit differenti. Tale non correlazione per garantita solo sotto precise condizioni. Ovvero un codice particolare pu essere assegnato ad un UE se e solo se non stato riservato nessun altro codice sul cammino dal codice specifico alla radice dellalbero o nel sotto albero avente il codice specifico come radice. Per questo unassegnazione casuale dei codici con SF ele vato per canali con basso bit rate potrebbe precludere lutilizzo di un gran numero di codici con basso SF. Al contrario, sarebbe vantaggioso assegnare i codici agli utenti con basso bit rate in modo da minimizzare il numero di quelli non disponibili con basso SF. Risulta quindi necessario definire opportuni algoritmi di allocazione che tengano in considerazione e il numero di codici a disposizione e le caratteristiche dei vari UE. Si possono seguire i seguenti criteri:
Utilizzazione: lutilizzazione d efinita come il rapporto tra la banda utilizzata e quella disponibile. Uno schema di allocazione che preservi pi codici con basso SF ha pi possibilit di fornire maggiore utilizzazione. Per esempio, siano C4,1 e (C8,1 e C8,3) i codici disponibili risultanti da due diversi schemi di allocazione. C4,1 pu supportare un symbol rate fino a 960 kbps. Analogamente anche (C8,1 e C8,3) possono supportare lo stesso symbol rate, ma C4,1 pu supportare la velocit di 960 kbps usando una sola sequenza. Lasciando, di conseguenza, liberi pi codici a basso SF e garantendo una migliore utilizzazione.
Complessit: la complessit del sistema cresce allaumentare del numero di codici. Pertanto se si possono utilizzare pi schemi (come visto nellesempio precedente), si sceglie lo schema che richiede il minor numero di sequenze.
3.3 Il livello MAC

Il MAC un sottolivello dello strato 2 della pila protocollare in esame. Da un punto di vista strutturale il MAC formato da diverse entit:
MAC-b: lentit che gestisce il canale di trasporto BCH. C unentit MAC-b in ogni UE e una per ogni cella dellUTRAN. MAC-c/sh: identifica lentit che controlla i canali di trasporto comuni qui elencati: PCH, FACH, RACH, CPCH, DSCH, USCH. Vi unentit MAC c/sh in ogni UE e una per ogni cella dellUTRAN. MAC-d: responsabile del controllo dei canali logici e dei canali di trasporto dedicati DCH allocati ai vari utenti. C una di queste entit in ogni UE
30
3 Il sistema UMTS - I protocolli radio mentre nellUTRAN ci sono tanti MAC -d quanti sono gli utenti ad esso connessi. Le figure 3.3, 3.4 e 3.5 illustrano la connettivit tra queste entit e la loro cardinalit rispettivamente nellUE e nellUTRAN.
PCCH BCCH CCCH CTCH SHCCH

( TDD only )
MAC Control DCCH DTCH
DTCH
MAC-d
MAC-c/sh
PCH
FACH FACH RACH CPCH USCH USCH DSCH DSCH

( FDD only ) ( TDD only ) ( TDD only )
DCH
DCH
Figura 3.3 : Architettura MAC lato UE
PCCH BCCH CCCH
CTCH SHCCH
TDD only
MAC Control
MAC Control DCCH DTCH
DTCH
MAC-d
MAC-c/sh
PCH FACH FACH
RACH CPCH USCH USCH DSCH DSCH

FDD only TDD only TDD only
DCH Iur or local
DCH
Figura 3.4 : Architettura MAC lato UTRAN
31

BCCH Mac Control
MAC-b
BCH
Figura 3.5 : Entit MAC-b lato UE e lato UTRAN
Ogni entit viene configurata dal livello RRC attraverso opportuni messaggi di controllo che giungono a destinazione per mezzo dei Control SAP.
3.3.1 I Servizi MAC

Il MAC fornisce i seguenti servizi ai livelli superiori:
Trasferimento dati: questo servizio fornisce il trasferimento in modalit unacknowledged di MAC SDU tra entit MAC di pari livello, senza per offrire funzioni di segmentazione e riassemblaggio che devono quindi essere svolte dai livelli superiori. Riallocazione delle risorse radio e dei parametri MAC: questo servizio esegue, su richiesta dellRRC, la riallocazione delle risorse radio e la variazione dei parametri di livello MAC, quali il cambiamento dei canali di trasporto e dei formati di trasporto. Rapporto delle misurazioni: questultimo servizio realizza misurazioni locali sul volume di traffico e sulla qualit della trasmissione per poi comunicarle al livello RRC.
3.3.1.1 I canali logici Per garantire ai livelli superiori il trasferimento dati, il MAC definisce una serie di canali logici, ognuno caratterizzato dal tipo di informazione che trasporta. Si pu realizzare una prima generale classificazione dei canali logici in:
Canali di controllo: per il trasferimento delle informazioni del piano di controllo.
32
Canali di traffico: per il trasferimento delle informazioni che dipendono dal piano dutente.
In figura 3.6 si riporta lo schema relativo alla classificazione dei canali logici.
Control Channel Broadcast Control Channel (BCCH) Paging Control Channel (PCCH) Dedicated Control Channel (DCCH) Common Control Channel (CCCH) Shared Channel Control Channel (SHCCH) Traffic Channel Dedicated Traffic Channel (DTCH) Common Traffic Channel ( CTCH)
Figura 3.6 : Struttura dei canali logici
Tra i canali di controllo si trovano:
Broadcast Control Channel (BCCH) E un canale in downlink usato per trasmettere informazioni di controllo del sistema.
Paging Control Channel (PCCH) E un canale in downlink utilizzato per la trasmissione dei messaggi di paging. Questo canale viene usato per esempio quando la rete non conosce la cella di locazione dellUE.
Common Control Channel (CCCH) E un canale bidirezionale usato per trasmettere informazioni di controllo tra la rete e gli utenti. Questo canale viene usato dagli UE che non hanno una connessione RRC con la rete e dagli utenti che entrano in una nuova cella dopo una procedura di Cell Reselection.
Dedicated Control Channel (DCCH) E un canale bidirezionale punto -punto che trasporta informazioni di controllo dedicate tra la rete e un particolare UE. Linstaurazione di questo canale avviene in seguito alla procedura di RRC Connection Setup.
Shared Control Channel (SHCCH) E un canale bidirezionale che trasporta informazioni di controllo per i canali condivisi in uplink e in downlink tra la rete e gli UE.
33
3 Il sistema UMTS - I protocolli radio I principali canali di traffico sono:
Dedicated Traffic Channel (DTCH) E un canale punto -punto, dedicato ad un particalare UE, per il trasferimento delle informazioni dutente. Pu esistere sia in uplink sia in downlink.
Common Traffic Channel (CTCH) E un canale punto -multipunto unidirezionale per il trasferimento di dati dedicati dutente verso tutti o un certo gruppo di UE.
3.3.1.2 Mappatura dei canali logici sui canali di trasporto Le figure 3.7 e 3.8 rappresentano le corrispondenze che ci sono tra i canali logici e i canali di trasporto sia dal lato UE sia dal lato UTRAN.
BCCH- PCCHSAP SAP DCCHSAP CCCHSAP SHCCH- CTCHSAP SAP (TDD only) DTCHSAP MAC SAPs
BCH PCH
CPCH
(FDD only)
RACH
FACH USCH
(TDD only)
DSCH DCH
Transport Channels
Figura 3.7 : Mappatura dei canali logici sui canali di trasporto lato UE
BCCH- PCCHSAP SAP
DCCHSAP
CCCH- SHCCH- CTCHSAP SAP SAP (TDD only)
DTCHSAP MAC SAPs
BCH PCH
CPCH
(FDD only)
RACH
FACH USCH DSCH DCH

(TDD only)
Transport Channels
Figura 3.8 : Mappatura dei canali logici sui canali di trasporto lato UTRAN
34
3.3.2 Elementi per le comunicazioni tra livelli

Per descrivere le interazioni tra il MAC e gli altri livelli, si introduce il concetto di primitiva. Con primitiva si indica lo scambio logico di informazioni dutente e di controllo tra livelli comunicanti. Sono utilizzati quattro tipi di primitive: i ii iii iv Request (REQ); Indication (IND); Responce (RESP); Confirm (CNF).
Il primo tipo di primitiva viene utilizzato quando un livello superiore sta chiedendo un servizio ad un livello sottostante. Il secondo tipo invece usato dal livello inferiore per avvisare il livello superiore su certe attivit che lo riguardano. La terza primitiva poi viene adoperata dal livello superiore per chiedere al livello sottostante se lattivit comp letata. Infine la primitiva di Confirm viene usata dal livello inferiore per confermare al livello superiore che lattivit stata completata. Il MAC connesso ai livelli fisico, RLC e RRC. I sottoparagrafi che seguono descrivono le primitive tra il Medium Access Control e i livelli citati. 3.3.2.1 Primitive tra MAC e livello 1 Le primitive tra questi livelli sono:
PHY-Access-Req: viene utilizzata dai canali di trasporto RACH o CPCH per chiedere laccesso al livello fisico. PHY-Access-Cnf: questa primitiva usata per confermare che la sincronizzazione del livello fisico stata stabilita e che il livello fisico pronto a trasmettere i dati per mezzo delle primitive PHY-Data. PHY-Data-Req: viene usata dal MAC per chiedere di inviare SDU al livello fisico. PHY-Data-Ind: serve per indicare al MAC la presenza di SDU passate attraverso il livello 1. PHY-CPCH-Status-Req: viene usata dal MAC per chiedere le informazioni sullo stato del CPCH, che sono trasmesse sul canale CSICH. PHY-CPCH-Status-Cnf: viene usata dal livello 1 per fornire al MAC le informazioni sullo stato del CPCH, trasmesse sul canale fisico CSICH. PHY-Status-Ind: pu essere utilizzata dal livello fisico per avvertire il MAC di un evento che accaduto.
In tabella 3.2 si riportano queste primitive con un elenco completo dei loro parametri.
35

Generic Name Parameter REQ Transport Format subset (1), ASC selected for Transport Block Set to be transmitted (5) TFI, Transport Block Set, CFNCELL, Paging Indicators (2), ASC selected for that Transport Block Set (3) Transport Format subset (1) Not Defined IND RESP CNF
PHY-Access
Not Defined
Not Defined
access information (1)
PHY-Data
TFI, Transport Block Set, CRC check result, TD (4)
Not Defined
Not Defined
PHY-CPCH_Status PHY-Status
Not Defined Event value
Not Defined Not Defined
Transport Format subset (1) Not Defined
NOTE (1): FDD only. NOTE (2): PCH only NOTE (3): 3.84 Mcps TDD RACH only NOTE (4): optional, TDD only NOTE (5): FDD and 1.28 Mcps TDD RACH only
Tabella 3.2 : primitive tra i livelli 1 e MAC
3.3.2.2 Primitive tra MAC e RLC Le primitive tra questi sottolivelli sono:
MAC-Data-Req: viene usata per avvisare il MAC che stata spedita una PDU di livello superiore secondo le procedure tipiche del servizio di trasporto dati. MAC-Data-Ind: indica allRLC la rrivo di un insieme di PDU ricevute dal MAC in un TTI. MAC-Status-Ind: informa il livello RLC sul rate con il quale esso pu trasferire i dati al MAC, per ciascun canale logico. Possibili parametri di questa primitiva sono il numero di PDU che si possono trasmettere in un TTI e la dimensione delle PDU. Questa primitiva pu anche essere utilizzata dal MAC per chiedere al livello RLC loccupazione dei buffer, al fine di ottimizzare la scelta dei TFC, oppure per avvisare il livello superiore che la trasmissione sul RACH o sul CPCH delle sue PDU fallita. MAC-Status-Resp: viene utilizzata da RLC per avvisare il MAC che non ha niente da inviargli oppure che sospeso o per comunicargli loccupazione dei buffer.
I parametri principali di queste primitive sono:
Data: indica le PDU di livello RLC da trasmettere o inviare
36
No_TB: indica il numero di Transport Block trasmessi dalla pari entit in un TTI. BO: rappresenta la Buffer Occupancy, ovvero indica per ogni canale logico la quantit di dati espressa in byte che essere deve trasmessa o ritrasmessa dal livello RLC. Quando il MAC connesso ad unentit RLC funzionante in modalit acknowledged, le PDU di controllo ancora da trasmettere e le RLC PDU fuori dalla finestra di trasmissione devono essere incluse nella BO. Le PDU di livello RLC che sono state trasmesse ma che sono ancora senza la conferma di avvenuta ricezione dalla pari entit, non devono essere incluse nella BO. No_PDU: indica il numero di PDU che il livello RLC pu trasmettere al MAC in un TTI. PDU_Size: specifica la dimensione di una PDU che il livello RLC pu inviare al MAC in un TTI. TX status: quando assume il valore di transmission unsuccessful, indica allRLC che la trasmissione di una sua PDU fallita nel TTI precedente. Al contrario, se vale transmission successful, indica allRLC che le sue PDU sono state inoltrate al livello 1 per essere trasmesse.
Generic Name Parameter Request Data, BO, UE-ID type indicator, RLC Entity Info Indication Data, No_TB, TD (note), Error indication No_PDU, PDU_Size, TX status BO, RLC Entity Info Response Confirm
MAC-DATA
MAC-STATUS NOTE: TDD only.
Tabella 3.3 : Primitive tra i livelli MAC e RLC
3.3.2.3 Primitive tra MAC e RRC Le primitive tra questi livelli sono:
CMAC-Config-Req: viene utilizzata dal livello RRC per instaurare, riconfigurare o rilasciare un canale logico nel MAC oppure per variare la corrispondenza tra canali logici e di trasporto, per aggiornare il TFCS o per cambiare la priorit di scheduling dei canali logici. CMAC-Measurement-Req: utilizzata dallRRC per chiedere al MAC di avviare opportune misurazioni, come quella sul volume di traffico.
37
CMAC-Measurement-Ind: serve per comunicare allRRC i ris ultati delle misure effettuate. CMAC-Status-Ind: avvisa il Radio Resource Control sullo stato del livello MAC.
I principali parametri di queste primitive sono:
UE information elements: contiene tutta una serie di elementi utili ad identificare lutente. RB information elements: contiene informazioni sulla configurazione del Radio Bearer quali lidentit del canale di trasporto e del canale logico, la priorit del canale logico. TrCH information elements: informazioni sul TFCS. Measurement information elements: comprende i parametri per configurare le procedure di misura. Tra questi ci sono la modalit di consegna dei risultati (periodica o ad eventi), gli identificativi del tipo di misura, lintervallo temporale per calcolare la media o la varianza, list ante di tempo in cui consegnare i risultati al livello RRC (solo per la modalit periodica), eventuali soglie da confrontare con i risultati (solo per la modalit ad eventi). Measurement result: indica per esempio la modalit con cui sono stati determinati i risultati (periodica o ad eventi), il tipo dei risultati (BO, media e varianza della BO), levento accaduto (solo per la modalit ad eventi). Status info: quando assume il valore di transmission unsuccessful, indica allRRC che la trasmissione di una RLC PDU fallita. Al contrario, se vale transmission successful, indica allRRC che le RLC PDU sono state inoltrate al livello 1 per essere trasmesse.
Generic Name Parameter Request UE information elements, RB information elements, TrCH information elements, RACH transmission control elements, Ciphering elements, CPCH transmission control elements Measurement information elements Measurement result Status info Indication Response Confirm
CMAC-CONFIG
CMACMEASUREMENT CMAC-STATUS
Tabella 3.4 : Primitive tra i livelli MAC e RRC
38
3.3.3 Funzioni di livello MAC

Le funzioni di livello MAC includono:
Mappatura tra canali di trasporto e canali logici: il MAC responsabile di fissare le corrispondenze tra canali logici e canali di trasporto secondo i legami analizzati nel precedente sotto paragrafo. Selezione del formato di trasporto: una volta assegnato il Transport Format Combination Set (TFCS) dal RRC, viene scelto per ogni canale di trasporto il formato di trasporto pi opportuno in base alla velocit della sorgente. Gestione delle priorit tra diversi flussi dati di uno stesso UE: la scelta della particolare combinazione di formati di trasporto allinterno di un TFCS pu essere effettuata in base alla priorit del flusso dati da inviare su un opportuno canale di trasporto. Questo consente di assegnare adeguatamente le velocit in base alle priorit dei flussi informativi. Gestione della priorit tra UE tramite schedulazione dinamica: per assegnare in modo efficiente le risorse radio, il MAC gestisce diverse priorit sui canali comuni condivisi. Identificazione degli UE sui canali di trasporto comuni: quando un UE usa un canale comune, vi la necessit di identificare in banda tale UE. Multiplexing e demultiplexing delle PDU dei livelli superiori: il MAC supporta il (de)multiplexing sui canali di trasporto dei Transport Block e dei Transport Block Set in modo da multiplare sullo stesso transport channel i diversi servizi che devono essere offerti. Monitoraggio del volume di traffico: questa funzione esegue misurazioni di volume di traffico sui canali logici e le comunica al RRC. In base a tali informazioni, il RRC stabilisce se vi sono modifiche da apportare ai parametri dei canali di trasporto. Cambiamento del tipo di canale di trasporto: questa funzione esegue la commutazione tra canali di trasporto comuni e dedicati basandosi sulle decisioni effettuate dal RRC. Cifratura: deve prevenire lacquisizione non autoriz zata dei soli dati trasmessi nella modalit RLC trasparente.
3.3.3.1 Monitoraggio del volume di traffico Il controllo dinamico dei Radio Bearer gestito dal Radio Resource Control, per mezzo delle misure sul volume di traffico effettuate dal MAC. Ovvero il MAC raccoglie e misura la quantit di traffico che deve transitare attraverso il livello 2 e consegna i risultati allRRC. Per volume di traffico di un dato canale di trasporto si intende la somma totale delle BO di quei canali logici mappati sul canale di trasporto dinteresse.
39

Start
Get the measurement information from RRC: Mode, Reporting Quantity identifiers, Time interval to take an average or a variance, Reporting Interval, THU, THL, etc
Check traffic volume of transport channels
Mode = Event Trigger ?
THL < Transport Channel Traffic Volume < THU ?
Mode = Periodical & end of Reporting Interval ?
Report Measurement Result to RRC
Wait TTI
Figura 3.9 : Procedura di misura del volume di traffico nel MAC
Come gi accennato, sono previste due diverse modalit di recapito delle misure: una periodica e una definita ad eventi. La figura 3.9 rappresenta il diagramma di flusso di questa procedura di misura. Il MAC riceve le PDU di livello RLC insieme allinformazione sulloccupazione dei buffer dalle entit RLC. Se la modalit di consegna delle misure al RRC di tipo
40
3 Il sistema UMTS - I protocolli radio Event Trigger, il MAC confronta per ogni TTI il volume di traffico di un dato canale di trasporto con due soglie, fissate dal livello RRC. Se il valore esce dallintervallo stabilito dalle soglie, il MAC consegna le misure (come la Buffer Occupancy, la media e la varianza della BO) al Radio Resource Control per ogni Radio Bearer. In particolare, se la misura sotto la soglia inferiore, levento identificato dal simbolo 4b (figura 3.10); se invece la misura al di sopra della soglia superiore si parla di evento 4a (figura 3.11). Se la modalit di consegna invece periodica, il MAC fornisce i risultati dopo che trascorso un preciso intervallo temporale, sempre fissato dal RRC. In tal modo questultimo l ivello pu essere informato sul volume di traffico di ciascun canale logico e di trasporto, potendo cos configurare opportunamente i nuovo Radio Bearer.
Transport Channel Traffic Volume
Threshold
THL
Time
Reporting event 4B
Reporting event 4B
Figura 3.10 : Evento 4b associato alla modalit ad eventi
Transport Channel Traffic Volume Threshold THU Time
Reporting event 4A
Reporting event 4A
Figura 3.11 : Evento 4a associato alla modalit ad eventi
41
3 Il sistema UMTS - I protocolli radio Quando lo strato RRC riceve i risultati delle misure per ogni RB, converte i valori della BO, della media e della varianza della BO rispettivamente in valori normalizzati sul carico dei buffer, sulla media e la varianza. Per la modalit Event Trigger vengono definiti due tempi: il time-to-trigger e il pending time after trigger. Il primo rappresenta listante di tempo in cui il MAC pu andare a confrontare il volume di traffico di un dato canale di trasporto (TCTF Transport Channel Traffic Volume) con le soglie. Il secondo invece viene usato per limitare i recapiti consecutivi, dopo che un resoconto gi stato spedito al livello RRC. In altri termini, quando vengono consegnati i risultati, viene fatto partire un timer che vieta al MAC di inviare nuovi resoconti, anche se si verificano le condizioni. Solo allo scadere di questo timer, il MAC esce dallo stato di sospeso e pu riprendere ad aspettare il time-to-trigger. In figura 3.12 si illustrano rispettivamente i casi in cui il pending time after trigger sia breve oppure sia lungo.
Short pending time after trigger Long pending time after trigger
Transport Channel Traffic Volume Threshold
Transport Channel Traffic Volume Threshold Time
Time
Report 1
Report 2
Report 1
No Report
Pending time after trigger
Pending time after trigger
Figura 3.12 : Pending time after trigger
3.3.3.2 Scelta del Transport Format Combination Il livello RRC pu coordinare lordine di gestione dei dati in un generico UE, assegnando ad ogni canale logico un valore di priorit compreso tra 1 e 8: 1 corrisponde al grado di priorit pi elevato, mentre 8 a quello pi basso. LUE deve a questo punto scegliere dallinsieme delle combinazioni dei formati di trasporto, sempre comunicatogli dallRRC, il sottoinsieme delle combinazioni dei TF che pu supportare. Questa valutazione viene realizzata confrontando la potenza da trasmettere stimata per ciascun TFC con la massima potenza del trasmettitore di quellUE ( Maximum UE transmitter power). Se il valore di questultima maggiore della potenza stimata, allora il TFC pu essere utilizzato.
42
3 Il sistema UMTS - I protocolli radio Maximum UE transmitter power definita come il minimo tra la massima potenza che un generico UE pu trasmettere in uplink e la massima potenza che lUE in esame pu trasmettere. In altri termini:
Maximun UE = MIN ( Maximum allowed , UE maximum ) UL TX Power transmit power transmitter power
dove
Maximum allowed UL TX Power un valore di potenza fissato dallUTRAN in base al carico della rete e variabile nellintervallo [ -50, 33] dBm; UE maximum transmit power invece fissato in base alla classe di potenza a cui lUE appartiene. In tabella 3.5 si riportano le classi di potenza definite in [8].
Power Class 1 2 3 4
Nominal Maximum output power +33 dBm +27 dBm +24 dBm +21 dBm
Tolerance +1/-3 dB +1/-3 dB +1/-3 dB 2 dB
Tabella 3.5 : Classi di potenza dei terminali mobili
Dal sottoinsieme dei TFC disponibili e in base ai valori di priorit di ciascun canale logico, il MAC dovr quindi scegliere quello che massimizza la trasmissione dei dati a pi alta priorit.
3.4 Il livello RLC

Il Radio Link Control un sottolivello del livello 2 che da un lato riceve i servizi offerti dal MAC e dallaltro, a sua volta, offre servizi ai livelli superiori. Esso prevede tre differenti modalit per la trasmissione dei dati: transparent, unacknowledged e acknowledged. La prima prevede il trasporto dei dati senza laggiunta di alcuna informazione di controllo da parte del livello in esame; la seconda effettua la trasmissione dei dati realizzando un controllo di sequenza; la terza invece trasmette le informazioni garantendone la consegna. La figura 3.13 mostra il modello architetturale del livello RLC, evidenziando le diverse entit che lo compongono. Vi unentit trasmittente ed una ricevente per i servizi in modalit transparent e unacknowledged, mentre per i servizi in modalit acknowledged definita una sola entit sia per la trasmissione che per la ricezione.
43
3 Il sistema UMTS - I protocolli radio Le linee tratteggiate tra le entit AM indicano la possibilit di inviare le RLC PDU su canali logici separati: per esempio quelle di controllo su uno mentre quelle dutente su un altro. Una descrizione pi dettagliata delle diverse entit presentata nel sottoparagrafo seguente.
Higher layer RLC Receiv. Tr-Entity MAC
AM-Entity
UTRAN
Radio Interface
Receiv. Tr-Entity
Transm. Tr-Entity
AM-Entity
MS
Figura 3.13 : Modello del livello RLC
Transm. Tr-Entity
44
Transmitting side
Transm. UM-Entity
Receiving side
Receiv. UM-Entity
Transmitting side
Transm. UM-Entity
Receiving side
Receiv. UM-Entity
3.4.1 Entit di livello RLC

3.4.1.1 Entit in modalit Transparent La figura 3.14 rappresenta la struttura delle due entit di pari livello nella modalit trasparente.
Radio Interface
Tr-SAP
Tr-SAP
Transm. Tr-Entity Transmission buffer
Receiving Tr-Entity Reassembly
Segmentation
Receiver buffer
BCCH/PCCH/DCCH CCCH/DTCH/SHCCH
BCCH/PCCH/DCCH CCCH/DTCH/SHCCH
Figura 3.14 : Pari entit in modalit Transparent
Lentit in trasmissione riceve le SDU dai livelli superiori attraver so il Tr-SAP (Transparent SAP) e le segmenta in RLC PDU di dimensioni appropriate senza aggiungere ulteriori informazioni di controllo. Il modo in cui realizzare la segmentazione viene definito al momento di stabilire il servizio. Il livello RLC consegna al MAC le RLC PDU attraverso i canali logici BCCH, PCCH, SHCCH, SCCH e DTCH a seconda che il livello superiore si trovi nel piano di controllo o in quello dutente. Il canale logico CCCH utilizza la modalit trasparente solo in uplink. Lentit in ricezi one riceve dal MAC le PDU attraverso i canali logici sopra indicati. Il livello RLC riassembla (quando necessario) le PDU in RLC SDU e le consegna al livello superiore attraverso il Tr-SAP. 3.4.1.2 Entit in modalit Unacknowledged La figura 3.15 mostra le due entit di pari livello nella modalit Unacknowledged.
45

R a d io I n te r f a c e
U M -S A P
U M -S A P
T ran sm issio n b u f fe r
T ran sm . U M - E n ti ty
R e c e iv e r U M - E n ti ty
R e asse m b ly R em ove R LC h ead er
S e g m e n ta tio n & C o n c a t e n a ti o n
A d d R L C h ead er
R e c e iv e r b u f fe r D e c ip h e r i n g
C ip h e r in g
C C C H /D C C H / D T C H /S H C C H CTCH
C C C H /D C C H /D TCH/ SHCCH CTCH
Figura 3.15 : Pari entit in modalit Unacknowledged
Lentit trasmittente riceve le SDU dal livello superiore e le segmenta in PDU di dimensioni opportune con la possibilit di concatenare pi SDU tra loro. Il livello RLC aggiunge unintestazione alla PDU, la numera in ordine crescente e la inserisce nellapposito buffer di trasmissione. Le PDU vengono trasferite al livello sottostante attraverso i canali logici CCCH, SHCCH, DCCH, CTCH e DTCH. I canali CCCH e SHCCH sono usati in questa modalit solo in downlink. Lentit in ricezione prende quindi dal MAC le PDU da uno dei canali logici appena citati. Il livello RLC rimuove le intestazioni e se le PDU sono in sequenza, le riassembla in RLC SDU, che poi consegna al livello superiore. 3.4.1.3 Entit in modalit Acknowledged La figura 3.16 mostra le due entit di pari livello in modalit acknowledged, quando sono utilizzati un solo canale logico (linea continua in figura) oppure due canali logici (linee tratteggiate in figura). Nel caso di due canali logici, lUTRAN indica quale si deve utilizzare per trasportare informazioni dutente e quale per la trasmissione delle PDU di controllo. Si deve evidenziare come con un solo canale logico le dimensioni delle RLC PDU e dutente e di controllo devono essere uguali. Quando lentit in trasmissione riceve le SDU dal livello superiore, le segmenta e concatena in PU di lunghezza prefissata. Questa dimensione decisa allinstaurazione della connessio ne e pu essere modificata dal livello RRC solo attraverso una procedura di riconfigurazione del Radio Bearer. Nel caso di
46
3 Il sistema UMTS - I protocolli radio concatenazione di pi SDU in una PU, si aggiungono opportuni Length Indicator allinizio della PU. A questo punto le PDU vengono in serite nel buffer di trasmissione e in quello di ritrasmissione. E lentit denominata MUX a decidere quali e quante PDU devono essere spedite al livello sottostante. Prima di essere inoltrate al MAC per, una funzione ne completa lintestazione e rimpi azza il padding con informazioni di controllo (meccanismo del piggybacking). Questo permette di incrementare lefficienza della trasmissione e di rendere pi veloce lo scambio di messaggi di controllo tra le pari entit. Quando il buffer di trasmissione riceve le conferme di avvenuta consegna dal lato ricevente, pu eliminare la copia che si era memorizzato delle corrispondenti PDU. Lentit ricevente accetta le PDU che giungono dal livello sottostante attraverso uno dei canali logici indicati in figura 3.16. Queste RLC PDU, da cui vengono estratte eventuali informazioni di controllo inviate in piggybacking, sono ora inserite nel buffer di ricezione fino a quando lintera SDU non stata ricevuta. Il buffer di ricezione pu chiedere le ritrasmissioni delle PU perse o danneggiate tramite linvio di un NACK alla pari entit in trasmissione. Le PDU riassemblate correttamente nella SDU, vengono passate al livello superiore.
A M -S A P
A M -E n tity S e g m en ta tio n /C o n c a te n a tio n R L C C o n tro l U n it A dd R L C head er P ig g y b a c k e d s ta tu s O p tio n a l R e tr a n s m is s io n b u ff e r & m anagem ent a c k n o w led g e m e n ts R e c eiv e d R e a s s e m b ly
M UX
R e m o v e R L C h e a d e r & E x tr ac t P ig g y b a c k e d in f o r m a tio n
T r a n s m is s io n b u ff e r
A c k n o w le d g e m e n ts
R e ce iv e r b u ff e r & R e tra n s m is s io n m anagem ent D e cip h e rin g
S e t fie ld s in P D U H e a d e r (e .g . s e t p o ll b its ) & p ig g y b a c k e d S T A T U S P D U C ip h e rin g (o n ly f o r A M D P D U )
D e m u x /R o u tin g
T r a n s m it t in g S id e
R e ce iv in g S id e
D CCH / D T C H **
D CCH / D TCH *
D CCH / D T C H **
D CCH / D T C H **
D CCH / D TCH *
D CCH / D T C H **
Figura 3.16 : Pari entit in modalit Acknowledged
47
3.4.2 I servizi RLC

I principali servizi forniti dal livello RLC sono:
Trasferimento dei dati in modalit Trasparent: questo servizio trasmette PDU di livello superiore senza aggiungere alcuna informazione di protocollo ma effettuandone solo la segmentazione e il riassemblaggio. Trasferimento dei dati in modalit Unacknowledged: questo servizio trasmette le PDU di livello superiore senza garantire per la consegna alla pari entit. Questa modalit di trasferimento presenta le seguenti caratteristiche: i rilevamento dei dati errati: il sottolivello RLC consegna le sole SDU che sono prive di errori, utilizzando un meccanismo di controllo basato sul numero di sequenza; ii consegna immediata: il Radio Link Control consegna le SDU ai livelli superiori non appena esse arrivano al lato ricevente.
Trasferimento dei dati in modalit Acknowledged: questo servizio trasmette le SDU, garantendone la consegna alla pari entit. Per questo servizio sono supportate entrambe le modalit di consegna in sequenza e fuori sequenza. La modalit Acknowledged presenta le seguenti caratteristiche: i consegna priva di errori: la consegna di SDU prive di errori assicurata mediante luso della ritrasmissione; ii consegna univoca: il livello RLC consegna ai livelli superiori ogni SDU una sola volta grazie alla funzione di controllo dei duplicati; iii consegna in sequenza: in questo caso le SDU sono consegnate nellordine in cui sono trasmesse; iv consegna fuori sequenza: la consegna delle SDU pu avvenire in un ordine diverso da quello con cui sono state trasmesse.
Mantenimento della QoS: il protocollo di ritrasmissione deve essere configurabile dal livello 3 per poter garantire diversi livelli di qualit di servizio. Avviso di errori irrecuperabili: il livello RLC deve poter avvisare il livello superiore su errori che non in grado di gestire.
3.4.3 Primitive per la comunicazione tra livelli

Anche in questo caso per descrivere le interazioni tra lRLC e i livelli comunicanti (MAC e livelli superiori in generale), si introduce il concetto di primitiva.
48
3 Il sistema UMTS - I protocolli radio Avendo gi descritto le primitive tra RLC e MAC al punto 3.3.2.2 di questo capitolo, non rimane che studiare quelle tra RLC e i livelli superiori. 3.4.3.1 Primitive tra RLC e livelli superiori Le primitive tra i livelli indicati sono:
RLC-AM-Data-Req: utilizzata dai livelli superiori per chiedere la trasmissione di una PDU di livello superiore in modalit Acknowledged. RLC-AM-Data-Ind: viene usata dallRLC per consegnare ai livelli superiori una RLC SDU che stata trasmessa in modalit Acknowledged o per indicare ai livelli superiori che una RLC SDU stata scartata nella pari entit. RLC-AM-Data-Conf: usata dallRLC per confermare ai livelli superiori dellavvenuta ricezione nella pari AM entit di una RLC SDU. RLC-UM-Data-Req: utilizzata dai livelli superiori per chiedere la trasmissione di una PDU di livello superiore in modalit Unacknowledged. RLC-UM-Data-Ind: viene usata dallRLC per consegnare ai livelli superiori una RLC SDU che stata trasmessa in modalit Unacknowledged. RLC-TR-Data-Req: utilizzata dai livelli superiori per chiedere la trasmissione di una PDU di livello superiore in modalit Transparent. RLC-TR-Data-Ind: viene usata dallRLC per consegnare ai livelli superiori una RLC SDU che stata trasmessa in modalit Transparent. CRLC-Config-Req: questa primitiva utilizzata dai livelli superiori (RRC) per instaurare, rilasciare, fermare o riattivare il livello RLC. CRLC-Suspend-Req: questa primitiva usata dai livelli superiori (RRC) per sospendere il sottolivello RLC. Il parametro intero N indica che lR LC non pu inviare una PDU con numero di sequenza SN maggiore o uguale a VT(S)+N nella modalit AM e a VT(US)+N nella modalit UM. Occorre ricordare che solo le entit AM e UM possono essere sospese. CRLC-Suspend-Cnf: con questa primitiva il Radio Link Control informa i livelli superiori sul valore di VT(S) e VT(US) rispettivamente per la modalit AM e UM. CRLC-Resume-Req: primitiva usata dai livelli superiori per riattivare il livello RLC quando stato sospeso. CRLC-Status-Ind: utilizzata dal livello RLC per mandare informazioni di stato ai livelli superiori.
I parametri usati dalle primitive sono:
Data: rappresenta la RLC SDU, inserita nel campo dati delle RLC PDU. Il parametro Data pu essere diviso su parecchie RLC PDU.
49
CNF (Confirmation Request): indica se il livello RLC ha bisogno della conferma di avvenuta ricezione della RLC SDU da parte della pari entit AM. MUI (Message Unit Identifier): questo parametro serve come identificativo della RLC SDU. E/R: indica instaurazione, modifica o rilascio delle opportune entit RLC. A seconda del suo valore, si devono configurare opportunamente le variabili di stato e i parametri delle pari entit RLC. EVC (Event Code): indica la ragione per cui si utilizza la primitiva CRLCStatus-Ind (come la presenza di errori irrecuperabili, perdite dati di livello 2, susseguirsi di eventi di tipo Reset). Ciphering Elements: sono utilizzabili per le sole modalit AM e UM. Questi parametri comprendono la modalit di cifratura, la chiave di cifratura, il tempo di attivazione per la trasmissione e il tempo di attivazione per la ricezione (questi tempi sono espressi come il numero di sequenza SN al quale si deve attivare una nuova configurazione di cifratura rispettivamente al trasmettitore e al ricevitore). AM parameters: sono associati alla sola modalit AM. Essi contengono la dimensione delle AMD PDU, lindicazione del tipo di consegna (in ordine o fuori sequenza), i valori dei Timer, i valori dei parametri di protocollo, la modalit di scarto delle SDU, i criteri di polling da attivare e la dimensione della finestra di ritrasmissione. UM parameters: sono utilizzabili nella sola modalit UM. Contengono il valore del tempo dopo il quale una PDU deve essere scartata e la dimensione massima di una UMD PDU. TM parameters: sono applicati alla modalit TM. Comprendono il valore del Timer di scarto e indicazioni per la segmentazione e per la consegna delle SDU errate. Discard Info: indica ai livelli superiori quali RLC PDU sono state scartate nella AM entit di pari livello. Questo parametro pu essere usato solo quando attiva la consegna in sequenza ed esplicitamente richiesta linformazione sulle PDU scartate. Stop: indica che lentit RLC non trasmetter o ricever pi RLC PDU. Continue: indica che lentit RLC continuer a trasmettere o ricevere le RLC PDU.
In tabella 3.6 si riportano queste primitive con un elenco completo dei rispettivi parametri.
50

Generic Name Req. RLC-AM-DATA RLC-UM-DATA RLC-TR-DATA Data, CNF, MUI Data, Use special LI Data E/R, Stop, Continue, Ciphering Elements (UM/AM only), TM_parameters (TM only), UM_parameters (UM only), AM_parameters (AM only) N No Parameter Not Defined Ind. Data, DiscardInfo Data Data Parameter Resp. Not Defined Not Defined Not Defined Conf. MUI Not Defined Not Defined
CRLC-CONFIG
Not Defined
Not Defined
Not Defined
CRLC-SUSPEND (UM/AM only) CRLC-RESUME (UM/AM only) CRLC-STATUS
Not Defined Not Defined EVC
Not Defined Not Defined Not Defined
VT(US) (UM only), VT(S) (AM only) Not Defined Not Defined
Tabella 3.6 : Primitive tra RLC ei livelli superiori
3.4.4 Funzioni di livello RLC

Le funzioni di questo livello comprendono:
Segmentazione e riassemblagio: questa funzione realizza la segmentazione e il riassemblaggio di PDU di livello superiore di dimensioni variabili, in/da RLC PDU. La dimensione delle RLC PDU adattabile in base allinsieme di formati di trasporto utilizzati. Concatenazione: se il contenuto di una RLC SDU non rientra in un numero intero di RLC PU, il primo segmento della successiva RLC SDU pu essere concatenato con lultimo segmento della precedente RLC SDU. Padding: quando la concatenazione non attiva e i dati rimanenti da trasmettere non occupano unintera RLC PU di dimensione nota, allora la parte restante della RLC PU viene riempita con bit non significativi detti di padding. Trasferimento di dati utente: questa funzione serve per trasferire dati tra utenti di servizi RLC. Le modalit di trasferimento supportate sono Acknowledged, Unacknowledged e Transparent. Correzione derrore: fornisce la correzione degli errori mediante ritrasmissione (con protocolli a finestra Selective repeat, Go back N, Stop and Wait) nella sola modalit Acknowledged. Consegna in sequenza delle PDU di livello superiore: questa funzione preserva lordine con cui le PDU di livel lo superiore vengono generate nella modalit Acknowledged e Unacknowledged. Se questa funzione non attiva, si pu avere consegna fuori sequenza.
51
Rilevamento dei duplicati: tale funzione rileva eventuali duplicati delle RLC PDU ricevute, assicurando cos una sola consegna di ogni RLC PDU ai livelli superiori. Controllo di flusso: permette allentit RLC ricevente di controllare il rate al quale la pari entit trasmittente invia le informazioni. Controllo del numero di sequenza: questa funzione utilizzata nella modalit Unacknowledged. Garantisce lintegrit delle PDU riassemblate e fornisce un meccanismo per il rilevamento delle RLC SDU errate, attraverso il controllo del numero di sequenza. Rilevamento e recupero degli errori di protocollo: permette di continuare le operazioni del protocollo anche in seguito alla presenza di errori. Cifratura: previene lacquisizione non autorizzata dei dati. La cifratura realizzata nel livello RLC solo per le modalit di trasferimento non trasparenti (AM e UM). Scarto delle SDU: consente al trasmettitore RLC di scartare delle RLC SDU dal suo buffer. Funzioni di Suspend e Resume: permettono di sospendere o riattivare il trasferimento dei dati.
3.5 Il livello PDCP

La figura 3.17 rappresenta la struttura del sottolivello PDCP. Da questa immagine si vede come ad ogni Radio Bearer sia associata una sola entit PDCP, alla quale associata una sola entit RLC.
Radio Bearers
PDCP-SDU
PDCP-SAPs C-SAP
PDCP entity
HC Protocol Type1 HC Protocol Type2
...
PDCP entity
HC Protocol Type1
PDCP entity
SDU
numbering HC Protocol Type2
PDCPsublayer
HC Protocol Type1
RLC-SDU ... UM-SAP AM-SAP TM-SAP RLC
Figura 3.17 : Struttura del livello PDCP
52
3 Il sistema UMTS - I protocolli radio Ogni entit PDCP pu usare zero, uno o pi protocolli differenti per la compressione delle intestazioni. Inoltre per lo stesso UE si possono definire pi entit PDCP con lo stesso tipo di protocollo di compressione. Il sottolivello PDCP viene configurato dal livello superiore attraverso il PDCPControl-SAP.
3.5.1 Servizi e funzioni di livello PDCP

I servizi principali di questo livello sono: 1. Segmentazione e riassemblaggio: prevede la possibilit di segmentare e riassemblare le PDU di livello superiore. 2. Trasferimento dati: questo servizio garantisce la trasmissione e la ricezione di PDU di livello rete nelle diverse modalit tipiche dellRLC: Transparent, Unacknowledged, Acknowledged. 3. Consegna in sequenza: permette di mantenere lordine con cui le PDU di livello superiore sono state trasmesse. 4. Compressione e decompressione delle intestazioni: questa funzione realizza la compressione e la decompressione delle informazioni di controllo delle PDU di livello rete (come le intestazioni TCP/IP o UDP/IP) rispettivamente nellentit in trasmissione e in quella in ricezione. 5. Multiplexing: consente di indirizzare verso la stessa entit RLC diversi Radio Bearer.

Le interazioni tra il livello PDCP e gli altri livelli sono sempre descritte in termini di primitive. Avendo gi definito le primitive tra il livello RLC e i livelli superiori al punto 3.4.3.1, restano da spiegare le interazioni tra il PDCP e i livelli superiori. 3.5.2.1 Primitive tra PDCP e i livelli superiori Le primitive tra i livelli indicati comprendono:
PDCP-Data-Req: viene utilizzata dai livelli superiori collocati nel piano utente per chiedere la trasmissione delle loro PDU. PDCP-Data-Ind: serve per consegnare ai livelli posti nel piano dutente le PDCP PDU che sono state ricevute. CPDCP-Config-Req: viene utilizzata per configurare (o riconfigurare) una particolare entit PDCP e per assegnargli un particolare Radio Bearer. CPDCP-Release-Req: viene usata dai livelli superiori collocati nel piano di controllo (RRC) per rilasciare unentit PDCP.
53
CPDCP-SN-Req: questa primitiva viene usata nellUTRAN e serve per comunicare al PDCP il PDCP Sequence Number. CPDCP-Reloc-Req: viene invocata quando necessario iniziare la procedura di SRNS (Serving Radio Network Subsystem) Relocation per alcune entit PDCP. CPDCP-Reloc-Conf: viene utilizzata per trasferire il Receive-SN e il Send-SN ai livelli superiori.
In tabella 3.7 si riporta un elenco completo di queste primitive con i parametri corrispondenti.
Generic Name Req. PDCP-DATA CPDCP-CONFIG CPDCP-RELEASE CPDCP-SN CPDCP-RELOC Data PDCP-Info, RLC-SAP SN_Sync, R/I RLC-SAP PDCP SN Receive_SN Ind. Data Not Defined Not Defined Not Defined Not Defined Parameter Resp. Not Defined Not Defined Not Defined Not Defined Not Defined Conf. Not Defined Not Defined Not Defined Not Defined Receive_SN, Send_SN
Tabella 3.7 : Primitive tra PDCP e i livelli superiori
3.6 Il livello BMC

Il Broadcast/Multicast Control un sottolivello del livello 2 che giace nel solo piano dutente. Esso collocato sopra il livello RLC. Il BMC trasparente a tutti i servizi, esclusi quelli di broadcast e multicast. Nel lato dellUTRAN, questo sottolivello composto da una sola entit per cella. Il BMC utilizza la sola modalit di trasmissione Unacknowledged del livello RLC. In figura 3.18 si illustra la struttura del BMC, facendo anche attenzione ai SAP attraverso cui comunica con gli altri livelli.
3.6.1 I servizi BMC

Il BM-SAP fornisce servizi di trasmissione di tipo broadcast/multicast nel piano dutente sullinterfaccia radio per i dati comuni dutente in modalit Unacknowledged.
54
user-plane
RRC
BMC-SAP L2/BMC sublayer CBMCSAP BMC
UM L2/RLC sublayer RLC
CTCH-SAP
Figura 3.18 : Modello del livello BMC
3.6.2 Elementi per la comunicazione tra livelli

Per il sottolivello BMC si possono individuare due gruppi di primitive: quelle relative allinterazione tra il BMC e il livello RRC e quelle tra il BMC e i livelli superiori nel piano dutente. 3.6.2.1 Primitive tra BMC e RRC Le primitive tra questi livelli sono:
CBMC-Measurement-Ind: viene utilizzata dal BMC per comunicare informazioni sul volume di traffico. CBMC-Rx-Ind: serve per avvisare lentit RRC di far partire o fermare loperazione di ricezione dei messaggi di Cell Broadcast. CBMC-Config-Req: questa primitiva usata dal livello RRC per configurare adeguatamente il BMC.
55
3 Il sistema UMTS - I protocolli radio In tabella 3.8 si riporta lelenco completo di queste primitive con i l oro parametri.
Generic Name CBMC-Measurement-IND CBMC-Rx-IND CBMC-Config-REQ Parameters CB-Traffic-Volume Action, DRX selection CTCH configuration
Tabella 3.8 : Primitive tra BMC e RRC
3.6.2.2 Primitive tra BMC e i livelli superiori nel piano dutente Un elenco completo di queste primitive riportato in tabella 3.9. Per una descrizione pi dettagliata delle interazioni tra i livelli indicati si pu consultare quanto definito in [22].
Generic Name Parameters Message-ID, [, Old-Serial-Number], New-Serial-Number, Data-Coding-Scheme, CB-Data , [Category], Repetition-Period, Number-of-Broadcasts-Requested Message-ID, Serial-Number, Data-Coding-Scheme, CB-Data Message-ID, Serial-Number
BMC-Data-REQ
BMC-Data-IND
BMC-Data-CNF BMC-Congestion-IND BMC-Normal-IND BMC-Activation-REQ BMC-Deactivation-REQ BMC-DRX-REQ BMC-Error-IND BMC-Data41-REQ BMC-Data41-IND BMC-Error41-IND [ ] = Optional Parameter
Message-ID (n times) Message-ID (n times) CB-DRX-Schedule-Period, Reserved-CB-Capacity Cause Transport Layer Message, Broadcast Address Transport Layer Message, Error Type
Tabella 3.9 : Primitive tra BMC e i livelli superiori del piano dutente
56
3 Il sistema UMTS - I protocolli radio Le principali primitive tra questi livelli sono:
BMC-Data-Req: utilizzata dai livelli superiori per chiedere la trasmissione ripetuta dei messaggi di Cell Broadcast (CB). BMC-Data-Ind: indica ai livelli superiori lavvenuta ricezione di messaggi di CB. BMC-Data-Cnf: serve per indicare la fine di una operazione di broadcast dei messaggi di CB. BMC-Congestion-Ind: viene usata per avvertire i livelli superiori che lentit BMC congestionata. BMC-Normal-Ind: serve per indicare ai livelli superiori che il BMC uscito da una situazione di congestione. BMC-Activation-Req: utilizzata per richiedere la ricezione di messaggi di CB da parte del BMC, che poi dovr mandarli al livello superiore. BMC-Deactivation-Req: pensata per interrompere la ricezione dei messaggi di CB. BMC-Error-Ind: indica lesecuzione di operazioni senza successo da parte dellentit BMC richiesta .
3.6.3 Funzioni di livello BMC

Tra le funzioni del BMC troviamo:
Memorizzazione dei messaggi di Cell Broadcast: il BMC memorizza i messaggi di Cell Broadcast ricevuti sullinterfaccia CBC -RNC. Monitoraggio del volume di traffico e richiesta di risorse radio per i CBS: nellUTRAN il BMC calcola il rate di trasmissione richiesto per i CBS (Cell Broadcast Service) in base ai messaggi ricevuti sullinterfaccia CBC -RNC e richiede appropriate risorse radio per i canali CTCH/FACH al livello RRC. Schedulazione dei messaggi BMC: il BMC riceve le informazioni di schedulazione con ogni messaggio di Cell Broadcast. Per mezzo di queste informazioni il BMC lato UTRAN genera i messaggi e stabilisce lordine con cui trasmetterli. NellUE il BMC riceve i messaggi e indica al RRC i parametri di schedulazione che verranno usati dai livelli inferiori per la ricezione discontinua dei CBS. Trasmissione dei messaggi allUE: i messaggi vengono trasmessi allUE in base ai parametri di schedulazione. Consegna dei messaggi di Cell Broadcast ai livelli superiori (NAS): i messaggi di Cell Broadcast privi di errori sono consegnati al livello superiore situato nel Non Access Stratum.
57
3.7 Il livello RRC

Il modello del livello protocollare RRC comprende le seguenti entit funzionali.
Routing Function Entity (RFE): gestisce linstradamento dei messaggi verso differenti entit MM/CM (nel lato UE) o differenti domini di rete fissa (nellUTRAN); Broadcast Control Function Entity (BCFE): gestisce invece le funzioni per realizzare il broadcast. La BCFE deve fornire i servizi RRC, che vengono richiesti attraverso il GC-SAP. Questa entit pu infine utilizzare i servizi offerti dal livello inferiore attraverso il TR-SAP e lUM -SAP; Paging and Notification Control Function entity (PNFE): controlla il paging degli UE che non hanno una connessione RRC. Questa entit offre i servizi di livello RRC attraverso il DC-SAP mentre riceve i servizi degli strati inferiori dai SAP Tr e UM; Dedicated Control Function Entity (DCFE): gestisce tutte le funzioni specifiche di un UE. La DCFE deve fornire i servizi RRC richiesti tramite il DC-SAP mentre pu usare i servizi del livello sottostante per mezzo dei SAP Tr, UM, AM. Shared Control Function Entity (SCFE): assiste la DCFE nella modalit TDD. La SCFE collocata nel C-RNC e deve controllare lallocazione dei canali PDSCH e PUSCH utilizzando i servizi inferiori per mezzo dei SAP Tr e UM. Transfer Mode Entity (TME): gestisce la corrispondenza tra le diverse entit di livello RRC e i SAP forniti dal livello RLC.
Access Stratum
...
RFE
...
RFE
RFE
...
RRC
RRC SAPs
BCFE
PNFE
DCFE TME
SCFE
RLCctrl
Tr-SAP
UM SAP
AM SAP
RLC
MAC ctrl L1-ctrl
MAC L1
Figura 3.19 : Modello del livello RRC lato UTRAN
58
3 Il sistema UMTS - I protocolli radio Le figure 3.19 e 3.20 mostrano il modello di RRC rispettivamente nellUTRAN e nellUE. E importante sottolineare la necessit di uno scambio di informazioni tra le entit funzionali di questo livello. Tale aspetto non viene per trattato nelle specifiche [23].
NAS NAS
GC -SAP
GC-SAP
... ...
GC-SAP
Nt -SAP
Nt-SAP
Access Stratum RRC SAPs
RFE
RFE
... ...
DC -SAP
Nt-SAP
DC-SAP
RFE
... ...
DC-SAP
RRC
BCFE PNFE DCFE TME
RLC ctrl
SCFE
Tr -SAP
UM SAP
AM SAP
RLC
MAC ctrl L1 -ctrl
MAC L1
Figura 3.20 : Modello del livello RRC lato UE
3.7.1 I servizi RRC

Il sottolivello RRC offre i servizi ai livelli superiori attraverso i tre punti daccesso qui descritti:
GC (General Control) SAP: fornisce un servizio di trasmissione broadcast delle informazioni del Non Access Stratum a tutti gli utenti che si trovano in una certa area geografica. La modalit di trasferimento di questi dati di tipo unacknowledged e quindi la consegna delle informazioni non garantita. Di conseguenza necessario un meccanismo di ripetizione periodica dei messaggi, controllato dal NAS. Nt (Notification) SAP: questo SAP offre servizi di paging e di diffusione delle notifiche. I messaggi di paging vengono trasmessi allinterno di
59
3 Il sistema UMTS - I protocolli radio unintera area geografica, ma sono indirizzati ad uno specifico UE. La modalit di trasferimento sempre di tipo unacknowledged in quanto si assume che siano le entit del NAS a gestire le ritrasmissioni. I messaggi di notifica sono invece inviati a tutti gli utenti presenti in una certa area geografica. DC (Dedicated Control) SAP: fornisce servizi utili allinstaurazione e al rilascio di una connessione e al trasferimento dei messaggi, una volta creata la connessione. Dovrebbe comunque essere capace di trasferire messaggi anche durante la fase di instaurazione della connessione.

Le primitive tra il Radio Resource Control e i livelli a cui connesso sono gi state trattate ai punti 3.3.2.3, 3.4.3.1, 3.5.2.1 e 3.6.2.1 di questo capitolo. Il livello RRC svolge un importante ruolo di controllo e gestione delle risorse radio disponibili. Per questo esso si interfaccia con tutti gli strati della pila protocollare. Infatti questo livello consente al MAC di coordinare gli utenti e i Radio Bearer assegnando loro diverse priorit. Inoltre utilizza le misure effettuate dai livelli sottostanti e comunicategli attraverso i Control SAP per allocare opportunamente le risorse radio disponibili. In figura 3.21 si rappresentano questi legami, osservando come sia necessaria anche uninterazione diretta tra gli RRC, collocati nellUE e nellUTRAN.
Measurement Report RRC Control Radio Resource Assignment [Code, Frequency, TS, TF Set, Mapping, etc.] RRC
RLC Measurements RLC retransmission control Control
RLC Measurements Measurements Control
Control MAC L1 UE Control
MAC Measurements Control
L1
UTRAN
Figura 3.21 : Interazioni tra RRC e livelli inferiori
60
3.7.3 Funzioni di livello RRC

Il livello RRC gestisce la segnalazione di livello 3 nel piano di controllo tra gli UE e lUTRAN. Le funzioni realizzate sono:
Broadcast delle informazioni provenienti dal NAS: il livello RRC trasmette in broadcast le informazioni di sistema dalla rete agli UE. Queste informazioni vengono regolarmente ritrasmesse secondo opportune tempistiche. Il Radio Resource Control gestisce inoltre la schedulazione e la segmentazione di questi messaggi. Broadcast delle informazioni relative allAccess Stratum: il livello in esame gestisce la trasmissione delle informazioni di sistema verso gli UE in celle specifiche. Instaurazione, mantenimento e rilascio della connessione RRC: linstaurazione di una connessione RRC ha inizio da una richiesta da parte dei livelli superiori dellUE per stabilire la prima Signalling Connection tra lUE e lUTRAN. Linstaurazione di una connessione RRC include opzionalmente la riselezione di cella, il controllo per laccettazione della connessione e linstaurazione dei col legamenti per la segnalazione di livello 2. Il rilascio della connessione RRC pu essere richiesto dai livelli superiori, oppure dallo stesso RRC nel caso di tentativo di connessione non riuscito. Quando una connessione RRC viene rilasciata, lUE pu chi edere la reinstaurazione della connessione RRC. Instaurazione, riconfigurazione e rilascio dei Radio Bearer: il livello RRC pu, su richiesta dei livelli superiori, instaurare, riconfigurare e rilasciare dei Radio Bearer nel piano utente. Nei casi di instaurazione e riconfigurazione, il livello RRC, in base alle informazioni dei livelli superiori, sceglie i parametri che definiscono il Radio Bearer nei livelli 1 e 2. Assegnazione, riconfigurazione e rilascio delle risorse radio: il livello RRC gestisce la ssegnazione delle risorse radio per soddisfare le richieste sia nel piano utente che in quello di controllo. Questa funzione in particolare deve consentire al RRC di allocare le risorse radio a pi Radio Bearer, relativi ad ununica connessione RRC. Infi ne il Radio Resource Control deve essere in grado di controllare le risorse radio per realizzare comunicazioni asimmetriche tra lUTRAN e gli UE, sia in uplink che in downlink. Funzioni di mobilit della connessione RRC: queste funzionalit comprendono le procedure di handover, di preparazione agli handover verso reti GSM o di altro tipo, di riselezione di cella e di aggiornamento dellarea di paging. Paging: il livello RRC pu trasmettere in broadcast informazioni di paging verso gli UE interessati. Questi messaggi possono essere inviati anche durante la fase di instaurazione di una connessione RRC.
61
Instradamento delle PDU di livello superiore: questa funzione realizza linstradamento, nellUE, delle PDU dei livelli pi alti verso la corretta entit ricevente mentre, nellUTRAN, verso la giusta entit RANAP. Controllo della QoS richiesta: tale funzione deve fornire la qualit di servizio richiesta per un certo Radio Bearer. Pertanto deve allocare un numero adeguato di risorse radio. Ricezione e controllo delle misure: le misurazioni effettuate dallUE sono controllate completamente dal livello RRC. Ovvero come, quando e cosa misurare tutto fissato dal RRC. Controllo di potenza ad anello esterno: questa funzione definisce il livello di potenza che si vuole ottenere con il controllo di potenza ad anello chiuso. Controllo della cifratura: il livello RRC fornisce le procedure per scegliere i parametri di cifratura tra lUE e la rete.
3.7.4 Gli stati del livello RRC

La figura 3.22 mostra gli stati del livello RRC, analizzando in dettaglio lUTRA RRC Connected Mode e includendo le transizioni tra questultimo stato e il GSM Connected Mode per i servizi a circuito e il GSM/GPRS Packet Mode per i servizi a pacchetto.
UTRA RRC Connected Mode URA_PCH
out of service in service
CELL_PCH
UTRA: Inter-RAT Handover
GSM: Handover
GSM Connected Mode
CELL_DCH
CELL_FACH
GPRS Packet Transfer Mode

Cell reselection
Release of temporary block flow Initiation of temporary block flow Release RRC Connection Establish RRC Connection
Release RRC Connection
Establish RRC Release RRC Connection Connection
Establish RRC Connection
GPRS Packet Idle Mode Camping on a UTRAN cell Camping on a GSM / GPRS cell
Idle Mode
Figura 3.22 : Stati e transizioni tra gli stati del livello RRC
62
3 Il sistema UMTS - I protocolli radio Allaccensione, lUE si trova nello stato di Idle Mode fino a quando non trasmette una richiesta per instaurare una connessione RRC. In questo stato lUE contrassegnato dai soli identificativi del Non Access Stratum quali lIMSI (International Mobile Subscriber Identity), il TMSI (Temporary Mobile Subscriber Identity) e il P-TMSI (Packet TMSI). Oltre a questo, lUTRAN non possiede ulteriori informazioni sullUE in Idle Mode. Per poter quindi inviare messaggi allutente specifico, deve diffondere le informazioni a tutti gli UE in una cella. Si entra nello stato UTRA RRC Connected Mode solo quando viene instaurata una connessione RRC. In questo caso allUE viene assegnato un R adio Network Temporary Identity (RNTI), usato come identificativo dellUE sui canali comuni. I sottostati allinterno dell UTRA RRC Connected Mode riflettono il tipo di connessione instaurata e quali canali di trasporto possono essere utilizzati. La connessione RRC pu essere rilasciata solo quando lUE si trova negli stati CELL_DCH e CELL_FACH. Per connessione RRC si intende una connessione bidirezionale punto punto tra le pari entit RRC nellUE e nellUTRAN, caratterizzata dallallocazione di un U RNTI. Un UE pu avere al pi una connessione RRC. 3.7.4.1 Lo stato CELL_DCH Questo stato caratterizzato da:
un canale fisico dedicato allUE sia in uplink che in downlink; posizione dellUE conosciuta a livello di cella; possibilit di utilizzare dei canali di trasporto dedicati.
Si entra nello stato di CELL_DCH o dallo stato Idle Mode attraverso linstaurazione di una connessione RRC, o dallo stato CELL_FACH in seguito allallocazione di un canale dedicato. Per questo tipo di canale si possono usare diverse strategie di allocazione: o permanenti o basate su una durata temporale o sul volume di dati trasmessi. In questo stato pu essere assegnato allUE un canale PDSCH per il trasporto del DSCH. La transizione verso lo stato Idle Mode avviene in seguito al rilascio della connessione RRC. La transizione verso lo stato CELL_FACH avviene in seguito al rilascio di tutti i canali dedicati con segnalazione esplicita. 3.7.4.2 Lo stato CELL_FACH Questo stato caratterizzato da:
nessun canale fisico dedicato allocato allUE; monitoraggio continuo del FACH in downlink;
63
possibilit di utilizzare in qualsiasi istante il RACH e il CPCH in uplink, secondo le procedure daccesso tipiche di questi canali; posizione del mobile conosciuta dallUTRAN a livello di cella.
Quando viene allocato un canale dedicato tramite segnalazione esplicita, avviene la transizione da questo stato al CELL_DCH. Il passaggio verso lo stato CELL_PCH o URA_PCH avviene per mezzo di un ordine esplicito dellUTRAN. In seguito al rilascio della connessione RRC, si lascia questo stato e si entra in Idle Mode. Nello stato CELL_FACH, lUE deve effettuare misurazioni sul volume di traffico, sulloccupazione dei buffer, sul tempo di accesso al canale. In base a queste misure la rete pu decidere come allocare opportunamente le risorse al mobile. 3.7.4.3 Lo stato CELL_PCH Questo stato caratterizzato da:
nessun canale fisico dedicato allocato allUE; nessuna attivit permessa in uplink; posizione del terminale conosciuta dallUTRAN a livello di cella.
In questo stato non allocata nessuna risorsa per la trasmissione dei dati; quindi necessario transitare verso un altro stato per iniziare tale operazione. LUE deve monitorare gli eventuali messaggi di paging sul PCH ed ascoltare il BCH della serving cell per decodificare le informazioni di sistema. Non si possono usare i canali logici DCCH. Se la rete intende iniziare una attivit, deve mandare una richiesta di paging sul canale logico PCCH per iniziare un trasferimento in downlink. In questo caso si passa nello stato CELL_FACH. In caso di scarsa attivit da parte dellUE, lUTRAN pu ridurre il numero di aggiornamenti di cella ordinando al mobile di portarsi nello stato di URA_PCH. Tale transizione viene effettuata passando tramite lo stato CELL_FACH. 3.7.4.4 Lo stato URA_PCH Questo stato caratterizzato da:
nessun canale dedicato allocato allUE; nessuna attivit consentita in uplink; posizione dellUE nota a livello di area di registrazione UTRAN (URA).
Anche in questo stato non si pu utilizzare il canale logico DCCH. Se la rete vuole incominciare un trasferimento di dati, deve inviare una richiesta di paging sul canale
64
3 Il sistema UMTS - I protocolli radio logico PCCH nellURA dove si trova lUE. Se il mobile ha la necessit di trasmettere in uplink, deve entrare nello stato CELL_FACH. La transizione nello stato URA_PCH pu essere controllato mediante un timer di attivit oppure in base al numero di aggiornamenti di cella effettuati. Quando il numero di aggiornamenti supera un certo limite (fissato dalla rete), allora lUE entra in URA_PCH. Luscita da questo stato implica comunque lingress o nel CELL_FACH. Inoltre se un UE, che si trova nel URA_PCH, vuole rilasciare la connessione RRC, deve necessariamente uscire da questo stato. La mobilit viene realizzata attraverso le procedure di riselezione di URA. Il mobile deve effettuare la riselezione di cella e, una volta entrato in una cella appartenente ad un URA diverso, deve passare nello stato CELL_FACH per aggiornare lURA. Al termine di questa operazione, lUE pu ritornare nello stato URA_PCH.
3.7.5 Procedure di livello RRC

Ogni UE deve essere in grado di gestire parecchie procedure di livello RRC, anche contemporaneamente. Infatti dopo la ricezione di un messaggio che invoca una procedura, lUE deve essere subito pronto a ricevere un nuovo messaggio che richiama una nuova procedura. Nel ricevere un messaggio, lUE deve prima controllarne lintegrit, poi gestire eventuali errori e solo alla fine invocare la procedura opportuna. In particolare se lentit RRC nellUE trasmette i messaggi usando la modalit AM del sottolivello RLC, sicuro che linformazione ricevuta con successo dallUTRAN quando il livello RLC riceve il riscontro positivo dalla pari entit. Per le altre modalit di trasmissione (UM e Tr) invece lentit RRC deve utilizzare opportuni timer per garantire in un certo modo la consegna dei messaggi. Nei sottoparagrafi che seguono si descrivono le principali procedure di livello RRC. 3.7.5.1 Instaurazione della connessione RRC Lo scopo di questa procedura quello di instaurare una connessione RRC. LUE, nello stato di Idle Mode, inizia questa procedura quando i suoi livelli superiori chiedono di stabilire una connessione di segnalazione. Nelliniziare questa procedura, lUE deve:
porre uguale a FALSE la variabile PROTOCOL_ERROR_INDICATOR; settare opportunamente la variabile INITIAL_UE_IDENTITY; inizializzare il messaggio di RRC CONNECTION REQUEST, specificando il motivo della richiesta della connessione (chiamata in arrivo, invio di una mail);
65
inviare il messaggio appena citato sul canale CCCH in uplink; inizializzare a 1 il contatore V300 (descritto pi in dettaglio al punto 3.7.6); far partire il timer T300, quando riceve dal MAC lindicazione che il messaggio stato spedito.
Nel caso in cui lUTRAN riceva il messaggio di RRC CONNECTION REQUEST si possono verificare due situazioni, come illustrato nelle figure 3.23 e 3.24 qui riportate.
UE RRC CONNECTION REQUEST UTRAN
RRC CONNECTION SETUP
RRC CONNECTION SETUP COMPLETE
Figura 3.23 : Instaurazione della connessione RRC la rete accetta
UE RRC CONNECTION REQUEST
UTRAN
RRC CONNECTION REJECT
Figura 3.24 : Instaurazione della connessione RRC la rete rifiuta
Nel primo caso lUTRAN risponde all UE inviandogli un messaggio di RRC CONNECTION SETUP da trasmettere sul canale logico CCCH in downlink. Questa situazione si verifica quando il messaggio di richiesta esente da errori e lUTRAN dispone delle risorse adeguate da destinare allUE per insta urare la connessione. Nel secondo caso invece lUTRAN inoltra sul CCCH in downlink un messaggio di RRC CONNECTION REJECT. Tale condizione si verifica se il messaggio di REQUEST ricevuto dallUTRAN, presenta errori o non si dispongono delle risorse necessarie per instaurare la connessione.
66
3 Il sistema UMTS - I protocolli radio Nel frattempo lUE si trova in attesa di un messaggio di risposta da parte della rete. Anche in questo caso si possono verificare diverse situazioni. Una prima possibilit legata allo scadere del timer T300. Se infatti lUE non ha ancora ricevuto una risposta dallUTRAN o se i messaggi ricevuti contengono dei valori di identificazione dellUE diversi da quello memorizzato nella variabile INITIAL_UE_IDENTITY presso lUE stesso, pu capitare che il T300 scatti. In questo caso il mobile deve controllare il valore del contatore v300 e:
se minore o uguale alla costante N300 pu iniziare una nuova procedura di instaurazione di connessione, incrementando di uno il contatore v300 e facendo ripartire lorologio T300. se maggiore di N300, entra nello stato Idle Mode e considera la procedura fallita.
Nel caso in cui lUE riceva il messaggio di RRC CONNECTION SETUP con il valore di identificazione dellUE corretto, allora deve:
fermare il timer T300; realizzare la procedura di sincronizzazione del livello fisico; entrare in uno stato opportuno (CELL_FACH o CELL_DCH); inviare un messaggio di RRC CONNECTION SETUP COMPLETE, opportunamente configurato, sul canale in uplink DCCH; porre uguali a FALSE tutto un insieme di parametri legati ad indicazioni di errori; considerare la procedura terminata con successo.
Se invece lUE riceve un messaggio di RRC CONNECTION REJECT, deve confrontare il valore del campo Initial UE Identity con la sua variabile INITIAL_UE_IDENTITY. Se i valori sono differenti, deve ignorare il messaggio. Se invece coincidono, deve fermare il timer T300 e se linformazione sul tempo di attesa (wait time) contenuto nel messaggio :
diverso da zero e il contatore v300 minore o uguale a N300, lUE pu riazzerare v300, far ripartire il timer T300 e riniziare la procedura di richiesta di instaurazione (dopo avere atteso il tempo indicato). diverso da zero e il contatore v300 maggiore di N300, lUE entra nello stato Idle Mode e termina la procedura senza successo. uguale a zero, il mobile deve terminare la procedura e considerarla fallita.
67
3 Il sistema UMTS - I protocolli radio 3.7.5.2 Rilascio della connessione RRC Il fine di questa procedura di rilasciare una connessione RRC precedentemente instaurata, compresi tutti i Radio Bearer tra UE e UTRAN. Con questi devono essere abbattuti anche tutti i collegamenti usati per trasportare la segnalazione. Quando un UE si trova negli stati CELL_DCH o CELL_FACH, lUTRAN pu in ogni istante incominciare tale procedura di rilascio inviando un messaggio di RRC CONNECTION RELEASE per mezzo dellentit UM RLC. Se lUTRAN incomincia la procedura di rilascio della connessione in risposta ad un messaggio di CELL UPDATE o URA UPDATE spedito dallUE, deve utilizzare il canale CCCH in downlink per trasmettere il messaggio di RELEASE. Diversamente deve usare il canale DCCH in downlink. LUTRAN pu inoltre inviare parecchi messaggi di RRC CONNECTION RELEASE per incrementare la probabilit di ricezione dello stesso da parte dellUE destinatario. Lo stesso fenomeno viene anche applicato al messaggio di RRC CONNECTION RELEASE COMPLETE che lUE manda allUTRAN come risposta. Il numero delle ripetizioni e lintervallo temporale tra le repliche dei messaggi vengono fissati dalla rete. Quando lUE riceve il messaggio di RRC CONNECTION RELEASE, deve interrompere ogni operazione in corso con lUTRAN e se si trova nello stato:
CELL_DCH, deve: i) inizializzare a zero il contatore V308; ii) inviare un messaggio di RRC CONNECTION RELEASE COMPLETE ai livelli inferiori usando la modalit UM del RLC attraverso il canale logico DCCH; iii) avviare il timer T308, per gestire eventuali ritrasmissioni del messaggio di COMPLETE RELEASE.
CELL_FACH e il messaggio di RELEASE ricevuto sul DCCH, deve: i) inviare il messaggio di RRC CONNECTION RELEASE COMPLETE allUTRAN sul DCCH, utilizzando la modalit AM del livello RLC; ii) rilasciare tutte le risorse radio e i canali per la segnalazione; iii) entrare nello stato Idle Mode; iv) considerare terminata la procedura.
CELL_FACH e il messaggio di RELEASE ricevuto sul CCCH, deve: i) rilasciare tutte le risorse radio e i collegamenti usati per la segnalazione; ii) passare il valore del campo Release Cause contenuto nel messaggio di RELEASE ai livelli superiori;
68
3 Il sistema UMTS - I protocolli radio iii) entrare nello stato Idle Mode; iv) considerare finita la procedura. Se invece il messaggio di RRC CONNECTION RELEASE contiene errori di protocollo, lUE deve ignorare il messaggio, cancellandolo. Pu succedere che il timer T308 scada, quando lUE si trovi nello stato CELL_DCH e se in precedenza tale orologio era stato fatto partire. In questo caso lUE deve incrementare il contatore V308 di uno e se:
V308 minore o uguale alla costante N308, pu ritrasmettere un nuovo messaggio di RRC CONNECTION RELEASE per lUTRAN. V308 maggiore di N308, rilasciare tutte le risorse radio, entrare nello stato Idle Mode e considerare conclusa la procedura.
Quando poi lUTRAN riceve il messaggio di RRC CONNECTION RELEASE COMPLETE dallUE, esso deve rilasciare tutte le risorse allocate per quellUE e considerare la procedura conclusa con successo. I diagrammi di sequenza riportati in figura 3.25 e 3.26 rappresentano la procedura di rilascio della connessione RRC quando si usano rispettivamente i canali DCCH e CCCH.
UE RRC CONNECTION RELEASE
UTRAN
RRC
CONNECTION RELEASE COMPLETE
Figura 3.25 : Procedura di rilascio della connessione sul canale DCCH
UE RRC CONNECTION RELEASE
UTRAN
Figura 3.26 : Procedura di rilascio della connessione sul canale CCCH
69
3 Il sistema UMTS - I protocolli radio 3.7.5.3 Procedure di Riconfigurazione Tra queste si includono: (a) (b) (c) (d) (e) la procedura di instaurazione di un Radio Bearer; la procedura di rilascio di un Radio Bearer; la procedura di riconfigurazione di un Radio Bearer; la procedura di riconfigurazione di un canale di trasporto; la procedura di riconfigurazione di un canale fisico.
Le procedure ai punti (a) e (b) raggruppano le operazioni necessarie per instaurare e rilasciare dei Radio Bearer. Le ultime tre invece sono utilizzate per riconfigurare rispettivamente i parametri di un Radio Bearer, di un canale di trasporto e di un canale fisico. Per poter iniziare una di queste procedure, lUTRAN deve:
creare nuovi link radio in ogni nuova configurazione di canale fisico; incominciare la trasmissione e la ricezione su questi nuovi link; per la procedura (a), trasmettere un messaggio di RADIO BEARER SETUP sul canale DCCH in downlink usando lentit RLC AM o UM; per la procedura (b), trasmettere un messaggio di RADIO BEARER RELEASE sul canale DCCH in downlink usando lentit RLC AM o UM; per la procedura (c), inviare un messaggio di RADIO BEARER RECONFIGURATION sul canale DCCH in downlink utilizzando lentit RLC AM o UM; per la procedura (d), trasmettere un messaggio di TRANSPORT CHANNEL RECONFIGURATION sul canale DCCH in downlink usando lentit RLC AM o UM; per la procedura (e), trasmettere un messaggio di PHYSICAL CHANNEL RECONFIGURATION sul canale DCCH in downlink usando lentit RLC AM o UM.
Con la procedura di riconfigurazione di un Radio Bearer, lUTRAN pu anche ordinare di interrompere o continuare la trasmissione in uplink su determinati Radio Bearer. Inoltre queste procedure servono anche per far transitare lUE da un sottostato ad un altro tra quelli previsti per il livello RRC. In particolare se vengono adoperate per far passare lUE dallo stato CELL_DCH allo stato CELL_FACH, lUTRAN pu anche assegnargli dei canali comuni di una data cella e un C -RNTI da utilizzare in quella cella. Nelle figure 3.27, 3.28, 3.29, 3.30, 3.31, 3.32, 3.33, 3.34, 3.35 e 3.36 si rappresentano queste procedure. Per ognuna si possono distinguere due casi: esito positivo della procedura ed esito negativo.
70

UE RADIO BEARER SETUP UTRAN
RADIO BEARER SETUP COMPLETE
Figura 3.27 : Instaurazione di un Radio Bearer successo

UE RADIO BEARER SETUP UTRAN
RADIO BEARER SETUP FAILURE
Figura 3.28 : Instaurazione di un Radio Bearer fallimento
UE RADIO BEARER RELEASE
UTRAN
RADIO BEARER RELEASE COMPLETE
Figura 3.29 : Rilascio di un Radio Bearer successo

UE RADIO BEARER RELEASE UTRAN
RADIO BEARER RELEASE FAILURE
Figura 3.30 : Rilascio di un Radio Bearer fallimento
71

UE UTRAN
RADIO BEARER RECONFIGURATION
RADIO BEARER RECONFIGURATION COMPLETE
Figura 3.31 : Riconfigurazione di un Radio Bearer successo

UE UTRAN
RADIO BEARER RECONFIGURATION
RADIO BEARER RECONFIGURATION FAILURE
Figura 3.32 : Riconfigurazione di un Radio Bearer fallimento
UE TRANSPORT CHANNEL RECONFIGURATION
UTRAN
TRANSPORT CHANNEL RECONFIGURATION COMPLETE
Figura 3.33 : Riconfigurazione di un canale di trasporto successo

UE TRANSPORT CHANNEL RECONFIGURATION UTRAN
TRANSPORT CHANNEL RECONFIGURATION FAILURE
Figura 3.34 : Riconfigurazione di un canale di trasporto fallimento
72

UE PHYSICAL CHANNEL RECONFIGURATION UTRAN
PHYSICAL CHANNEL RECONFIGURATION COMPLETE
Figura 3.35 : Riconfigurazione di un canale fisico successo
UE PHYSICAL CHANNEL RECONFIGURATION
UTRAN
PHYSICAL CHANNEL RECONFIGURATION FAILURE
Figura 3.36 : Riconfigurazione di un canale fisico fallimento
Quando lUE riceve uno dei messaggi spediti dallUTRAN e prima menzionati, deve verificare lassenza di anomalie o errori di protocollo. In caso positivo, esegue loperazione associata al messaggio e risponde alla rete inviando in modalit RLC AM uno dei seguenti messaggi sul DCCH in uplink, a seconda della procedura: (a) (b) (c) (d) (e) RADIO BEARER SETUP COMPLETE; RADIO BEARER RELEASE COMPLETE; RADIO BEARER RECONFIGURATION COMPLETE; TRANSPORT CHANNEL RECONFIGURATION COMPLETE; PHYSICAL CHANNEL RECONFIGURATION COMPLETE.
Quando lUTRAN riceve uno di questi messaggi, deve cancellare tutte le vecchie configurazioni e terminare la procedura. In caso di esito negativo invece, lUE deve cancellare il messaggio, riprendere le vecchie configurazioni e risponde alla rete con uno dei seguenti messaggi: (a) (b) (c) (d) RADIO BEARER SETUP FAILURE; RADIO BEARER RELEASE FAILURE; RADIO BEARER RECONFIGURATION FAILURE; TRANSPORT CHANNEL RECONFIGURATION FAILURE;
73
3 Il sistema UMTS - I protocolli radio (e) PHYSICAL CHANNEL RECONFIGURATION FAILURE. 3.7.5.4 Procedure per le misurazioni Le misurazioni nellUE sono raggruppate in sette diverse categorie, in base a ci che lUE deve misurare. Un elenco completo di queste tipologie di misurazioni qui riportato:
misurazioni intra-frequency: consistono in misure sui canali fisici in downlink alla stessa frequenza di quella dellactive set. misurazioni inter-frequency: sono operazioni di misura sui canali fisici in downlink a frequenze diverse da quella dellactive set. misurazioni inter-RAT: comprendono un insieme di misure sui canali fisici in downlink, appartenenti per a tecnologie di accesso radio diverse dallUTRAN (per esempio GSM). monitoraggio del volume di traffico: sono misurazioni sul volume di traffico dei canali in uplink. misurazioni sulla qualit: servono per misurare determinati parametri di qualit, come il tasso derrore sui blocchi di trasporto ( transport block error rate) sui canali in downlink. misurazioni interne allUE: sono misure sulla potenza di trasmissione dellUE e sul livello del segnale ricevuto dallutente. misurazioni sulla posizione dellUE: servono per determinare la posizione del mobile.
LUE deve essere in grado di realizzare i n parallelo tutto un insieme di misurazioni. Deve quindi garantire che ciascuna operazione di misura sia controllata indipendentemente dalle altre. Le celle che un UE sta monitorando (ad esempio per misure legate allhandover) sono raggruppate in tre differenti categorie:
celle che appartengono allactive set. Le informazioni dutente sono inviate a tutte queste celle. Nella modalit FDD le celle dellactive set sono coinvolte nella procedura di soft handover. Nella modalit TDD invece lactive set comprende una sola cella. celle che non appartengono allactive set ma che devono essere monitorate secondo una lista comunicata allUE dallUTRAN. Linsieme di queste celle viene definito monitored set. celle che sono sentite dallUE, ma che non appartengon o n allactive set n al monitored set. Tali celle costituiscono il detected set. La trasmissione delle misure effettuate da questo insieme di celle richiesta solo per le misurazioni intra-frequency fatte dagli UE nello stato CELL_DCH.
74
3 Il sistema UMTS - I protocolli radio LUTRAN pu ord inare una misurazione in un UE o trasmettendo in broadcast informazioni di sistema o inviando un messaggio di MEASUREMENT CONTROL. Nel secondo caso, lUTRAN trasmette il messaggio sul canale DCCH in downlink sfruttando la modalit acknowledged del livello RLC. Il MEASUREMENT CONTROL MESSAGE include le seguenti informazioni di controllo:
Identificativo della misurazione: un numero di riferimento usato dallUTRAN per instaurare, modificare o rilasciare un certo tipo di misurazione e dallUE nei rapporti s ulla misurazione. Comando della misurazione: sono previsti tre diversi comandi: i) setup: serve per iniziare una nuova misurazione; ii) modify: modifica i parametri di una misurazione precedentemente avviata, come i criteri per trasmettere i risultati; iii) release: interrompe una operazione di misura e cancella tutte le informazioni associata a quella misurazione nellUE.
Tipo della misurazione: serve per identificare una delle sette tipologie sopra descritte. La presenza o lassenza di questa informazione dipende dal tipo di misura che si vuole realizzare. Oggetti della misurazione: indica allUE che cosa deve misurare. Quantit da riferire: comprendono le quantit che lUE deve includere nei rapporti in aggiunta a quelle che sono obbligatorie. Criteri per consegnare i risultati: indicano la modalit con cui devono essere spedite le misure alla rete: periodica o ad eventi. Validit della misurazione: definisce in quali stati dellUE la misura valida. Identificativi di misurazioni addizionali: comprende una lista di altre misurazioni da compiere, con i relativi parametri per eseguirle.
I parametri delle varie misurazioni dipendono strettamente dal tipo di misura che si vuole realizzare. Nel capitolo 5 si descriveranno con maggior attenzione tali parametri. Quando lUE riceve il messaggio di MEASUREMENT CONTROL, legge linformazione sul tipo di comando ordinato e:
se vale setup, deve: i) memorizzare nella variabile MEASUREMENT_IDENTITY propria dellUE lidentificativo della misurazione che si dovr eseguire; ii) incominciare loperazione di misura in base a tutte le altre informazioni contenute nel messaggio.
75
se vale modify, deve: i) continuare la misurazione indicata, usando per i nuovi parametri di gestione comunicati con il messaggio; ii) memorizzare questi nuovi parametri al posto di quelli vecchi nella variabile MEASUREMENT_IDENTITY dellUE nella locazione riservata a questo tipo di misura.
se vale release, deve: i) terminare loperazione di misura associata allinformazione measurement identity; ii) cancellare i parametri associati alla misurazione contenuti nella variabile MEASUREMENT_IDENTITY;
Nel caso in cui il messaggio di MEASUREMENT CONTROL ricevuto dallUE contiene errori (come parametri non settati o mal configurati) oppure la misurazione richiesta dal messaggio non pu essere eseguita (perch per esempio lUE si trova in uno stato che non la pu supportare), il mobile risponde alla rete con un messaggio di MEASUREMENT CONTROL FAILURE da trasmettere sul canale DCCH con modalit RLC acknowledged.
UE MEASUREMENT CONTROL UTRAN
Figura 3.37 : Procedura di Measurement Control caso normale
UE MEASUREMENT CONTROL
UTRAN
MEASUREMENT CONTROL FAILURE
Figura 3.38 : Procedura di Measurement Control fallimento
76
3 Il sistema UMTS - I protocolli radio I diagrammi di figura 3.37 e 3.38 illustrano la procedura di Measurement Control, distinguendo i due casi esaminati: fallimento e misurazione supportata o riconosciuta dallUE (caso normale). Quando arriva il momento di trasferire i risultati delle misure dallUE allUTRAN, il terminale inizia una nuova procedura inviando un messaggio di MEASUREMENT REPORT. Questa procedura viene definita procedura di consegna delle misure (figura 3.39). Listante di tempo in cui deve avvenire la spedizione dei risultati pu essere fissato in modo periodico o dal succedersi di determinati eventi (modalit Event Trigger). Se lUE si trova nello stato CELL _FACH o CELL_DCH, spedisce il messaggio di MEASUREMENT REPORT sul canale DCCH in uplink. Se invece si trova nello stato CELL_PCH o URA_PCH, deve prima eseguire una procedura di aggiornamento di cella per transitare nello stato CELL_FACH e solo dopo pu spedire il messaggio sul DCCH con i risultati della misurazione.
UE MEASUREMENT REPORT
UTRAN
Figura 3.39 : Procedura di Measurement Report
3.7.6 Timer, contatori e variabili di livello RRC

Le informazioni riportate nei sottoparagrafi che seguono servono a specificare meglio il significato di una serie di parametri propri del livello RRC. 3.7.6.1 Timer per lUE Nella tabella 3.10 si descrivono i timer utilizzati dallUE, indicando quando partono e si fermano e analizzando le azioni associate al loro scadere.
Timer
Avvio
Fine
Scadenza Ordina la ritrasmissione di RRC
T300
Trasmissione di un messaggio di RRC CONNECTION REQUEST
Ricezione di RRC CONNECTION SETUP
CONNECTION REQUEST se V300
"!#
in Idle Mode
77

Ritrasmette messaggio di CELL/URA UPDATE se V302 N302 altrimenti entra nello stato Idle Mode Ritrasmette messaggio di UE T304 Trasmissione di UE CAPABILITY INFORMATION Ricezione di UE CAPABILITY INFORMATION CONFIRM CAPABILITY INFORMATION se V304
T302
Trasmissione di CELL UPDATE o URA UPDATE
Ricezione di CELL UPDATE CONFIRM o URA UPDATE CONFIRM
!"
una procedura di cell update Entrando nello stato CELL_FACH o URA_PCH o CELL_PCH. T305 Ricezione di un messaggio di CELL UPDATE CONFIRM/URA UPDATE CONFIRM Allo scadere del timer T305 e se T307 lUE si trova nella out of service area Ritrasmette RRC CONNECTION Non pu essere fermato RELEASE COMPLETE se V308 Entrando in un nuovo stato LUE trasmette CE LL UPDATE se il timer T307 non attivo e si trova nella service area. Altrimenti, se T307 non attivo, fa partire il T307
Quando lUE entra nella service area Transita nello stato Idle Mode
trasmissione di RRC T308 CONNECTION RELEASE COMPLETE Quando inizia una procedura di riselezione di cella appartenente ad un altro sistema di accesso T309 radio dallo stato Connected Mode o in seguito alla ricezione di un messaggio di CELL CHANGE ORDER FROM UTRAN Trasmissione di PUSCH CAPACITY REQUEST Ricezione di PHYSICAL SHARED CHANNEL ALLOCATION Quando lUE riceve un numero T312 Quando lUE inizia ad instaurare un canale dedicato consecutivo uguale a N312 di indicazioni di sincronizzazione eseguita (in sync) dal livello 1 Instaurazione andata a buon fine di una nuova connessione nella nuova cella
#$%&('0)012 3 4 5 6783 5783 4 198 7@2 2 A

stato di Idle Mode
Riattiva la vecchia connessione con lUTRAN
Ritrasmette PUSCH CAPACITY REQUEST se V310 BCDFE@GH altrimenti la procedura termina Si eseguono le operazioni associate alla procedura di fallimento di instaurazione di un canale fisico
T310
Quando lUE sente N313 T313 consecutive indicazioni di fuori sincronismo (out of sync) dal livello 1
Quando lUE riceve un numero consecutivo uguale a N315 di indicazioni di sincronizzazione eseguita (in sync) dal livello 1
Si eseguono le operazioni legate al fallimento di un collegamento radio
78
Inizia procedura di cell update se la service area sentit. Quando lUE si trova nella out of T316 service area dello stato URA_PCH o CELL_PCH Quando lUE passa nella service area Diversamente fa partire il timer T317, transita nello stato CELL_FACH e inizia la procedura di cell update quando si trova nella service area. Quando scade il T316 o quando T317 lUE si trova nella out of service area dello stato CELL_FACH
Quando lUE entra nella service area
Transita allo stato Idle Mode
Tabella 3.10 : Timer di livello RRC lato UE
3.7.6.2 Contatori per lUE Nella tabella 3.11 si definiscono i contatori usati dal livello RRC lato UE, specificando per ognuno di questi gli istanti di tempo in cui vengono rispettivamente inizializzati e incrementati e cosa accade quando raggiungono il valore massimo loro consentito.
Contatori
Inizializzazione Quando inizia la procedura di
Incremento
Raggiungimento del valore max
V300
instaurazione di una connessione RRC
Allo scadere del T300
Se V300 > N300, lUE entra nello stato Idle Mode
V302
Quando inizia la procedura di cell update o URA update Allo scadere del T302
Se V302 > N302, lUE entra nello stato Idle Mode
Quando si invia il primo V304 messaggio di UE CAPABILITY INFORMATION Quando si invia il primo messaggio di RRC V308 CONNECTION RELEASE COMPLETE in una procedura di rilascio di connessione RRC Allo scadere del T308 Allo scadere del T304
Se V302 > N302, lUE inizia la procedura di cell update
Se V308 > N308, lUE interrompe la ritrasmissione del messaggio di RRC CONNECTION RELEASE COMPLETE
79
Quando si invia il primo messaggio di PUSCH CAPACITY V310 REQUEST in una procedura di richiesta della capacit del canale PUSCH Allo scadere del T310 Se V310 > N310, lUE interrompe la ritrasmissione dei messaggi di PUSCH CAPACITY REQUEST
Tabella 3.11 : Contatori di livello RRC lato UE
3.7.6.3 Costanti per lUE Nella tabella seguente si definisce il significato delle costanti usate dal livello RRC lato UE per gestire le varie procedure.
Costanti N300 N302 N304 N308 N310 N312 N314 N315 Uso Massimo numero di ritrasmissioni del messaggio di RRC CONNECTION REQUEST Massimo numero di ritrasmissioni del messaggio di CELL UPDATE/URA UPDATE Massimo numero di ritrasmissioni del messaggio di UE CAPABILITY INFORMATION Massimo numero di ritrasmissioni del messaggio di RRC CONNECTION RELEASE COMPLETE Massimo numero di ritrasmissioni del messaggio di PUSCH CAPACITY REQUEST Massimo numero di successivi in sync ricevuti dal livello 1 Massimo numero di successivi out of sync ricevuti dal livello 1 Massimo numero di successivi in sync ricevuti dal livello 1, mentre il T313 attivo
Tabella 3.12 : Contatori di livello RRC lato UE
3.7.6.4 Variabili per lUE Le variabili utilizzate dal livello RRC nellUE costituiscono un insieme molto esteso. Tra queste, quelle di maggior interesse ai fini del simulatore realizzato, sono:
INITIAL_UE_IDENTITY: in questa si memorizza lidentificativ o dellUE quando viene instaurata una connessione RRC con lUTRAN; ESTABLISHMENT_CAUSE: viene utilizzata per registrare il motivo per cui si vuole instaurare una connessione RRC tra lUE e lUTRAN;
80
MEASUREMENT_IDENTITY: questa variabile deve permettere di memorizzare per ogni tipo di misurazione che lUE deve eseguire, tutti i parametri ad esse legati (modalit di consegna dei risultati, eventuali soglie per il confronto); PROTOCOL_ERROR_INDICATOR: indica se nella procedura in corso si verificato un qualche errore di protocollo; TIMERS_AND_CONSTANTS: questa variabile contiene tutti i valori per i timer e i contatori usati dallUE nello stato Connected Mode; STATUS: memorizza lo stato momentaneo in cui si trova lUE.
3.7.7 Strategie di gestione delle risorse radio (RRM)

Nei sottoparagrafi seguenti si descrivono le strategie di Radio Resource Management (RRM) supportate dallUTRAN. 3.7.7.1 Procedure in Idle Mode Quando un UE viene acceso, deve scegliere una PLMN (Public Land Mobile Network) adeguata e cercare una cella disponibile della PLMN presso cui attestarsi. Una PLMN pu poggiare su numerose tecnologie di accesso radio (RAT), come UTRA e GSM. Il Non Access Stratum pu scegliere la tecnologia di accesso radio presso cui si deve eseguire la procedura di selezione della cella. Una volta scelta la cella adatta e la modalit di accesso radio in base alle misurazioni fatte in Idle Mode e ai criteri di selezione di cella, lUE dovr comunicare la sua presenza per mezzo di una procedura di registrazione. Inoltre il mobile deve continuamente cercare celle migliori in base ai criteri di riselezione di cella. I criteri, con cui sono eseguite le operazioni citate, sono: (a) Criteri di selezione della cella Lo scopo delle procedure di selezione di cella quello di cercare rapidamente una cella disponibile presso cui attestarsi. Per velocizzare questa operazione, allaccensione del terminale o alluscita da una zona priva di copertura radio, lUE utilizza le informazioni memorizzate in seguito ai precedenti contatti con la rete. Se lUE non riesce a trovare nessuna di queste celle memorizzate, allora si attiva la procedura di Initial Cell Search. Se non possibile trovare una cella di una PLMN (Public Land Mobile Network) valida, lUE sceglier una cella di una rete in cui con sentito laccesso ma si trover in uno stato in cui i servizi offerti sono limitati. (b) Criteri di riselezione di cella Lo scopo di questa procedura quello di scegliere sempre la cella che pu offrire una qualit di trasmissione sufficientemente buona, anche se non
81
3 Il sistema UMTS - I protocolli radio risulta al momento essere la cella ottimale. Per controllare il numero di riselezioni di cella possibile utilizzare criteri sia basati su scelte temporali che su livelli di isteresi, mediante parametri diffusi come informazioni di sistema. (c) Registrazione Effettua laggiornamento di location registration. Le strategie utilizzate dipendono dagli operatori, tuttavia gli aggiornamenti possono essere effettuati sulla base di intervalli regolari, ma anche allingresso di un UE in una nuova registration area. 3.7.7.2 Mobilit per una connessione RRC Per RRC Connection Mobility si intende linsieme di procedure che consentono ad un UE di spostarsi tra le celle della rete, con la possibilit di conservare tutti i servizi che la rete pu fornire. Tra queste procedure, lhandover quella che permette ad un utente di trasmettere informazioni mentre si muove da una cella ad un altra. La strategia di handover utilizzata dalla rete per il controllo del link radio basata sui risultati delle misurazioni effettuate dal RNC e dallUE e su un insieme di parametri di cella. Un handover pu essere ordinato dalla rete anche per ragioni di controllo della distribuzione del traffico tra celle diverse. Con UMTS sono possibili i seguenti tipi di handover
handover 3G - 3G; FDD soft/softer handover; FDD inter frequency hard handover; FDD - TDD handover; TDD FDD handover; TDD TDD handover; handover 3G 2G (da UMTS verso GSM); handover 2G 3G (da GSM verso UMTS);
Alcune delle cause per cui si pu iniziare una procedura di handover sono qui elencate:
qualit del canale in uplink o downlink; misurazioni del livello del segnale in uplink/downlink; distanza; variazione del servizio; presenza di una cella migliore; problemi di traffico.
82
3 Il sistema UMTS - I protocolli radio Il soft e il softer handover sono due casi particolari di handover. Durante il softer handover, un terminale mobile si trova nellarea di copertura di due settori adiacenti di una stessa stazione radio base (figura 3.40). La comunicazione tra lUE e la base station avviene quindi per mezzo di due canali distinti sullinterfaccia radio, uno per ciascun settore, anche se di fatto trasportano la stessa informazione. Tale situazione richiede luso di due codici distinti nella direzione in downlink, affinch il terminale sia in grado di distinguere i due segnali in ricezione. Nella direzione in uplink, ha luogo un processo simile. Infatti nella stazione base i dati dutente sono ricevuti da due canali diversi (corrispondenti a due codici differenti) e una volta spostati in banda base, possono essere combinati e inoltrati verso il RNC.
Sector 1
UE
RNC
BTS
Sector 2
Figura 3.40 : Softer handover
Durante il soft handover, un terminale mobile si trova nellarea di copertura di due settori appartenenti a due stazioni base differenti (figura 3.41). Come nella situazione precedente, la comunicazione tra lUE e la rete avviene per mezzo di pi canali sullinterfaccia radio. Dal punto di vista del mobile, ci sono pochissime differrenze tra il soft e il softer handover. Nella direzione in uplink invece le differenze sono rilevanti. Infatti le informazioni dutente sono ricevute da due stazioni radio base diverse, che inviano i segnali ricevuti al RNC dove vengono poi ricombinati. Il soft e softer handover permettono di realizzare facilmente la trasmissione in macrodiversit, ovvero una trasmissione attraverso un insieme di collegamenti radio differenti tutti riferiti per alla stessa connessione. Questo si addice alla natura dei sistemi CDMA in quanto a celle adiacenti viene assegnata la stessa frequenza.
83
Base Station 1
UE
RNC
Base Station 2
Figura 3.41 : Soft handover
Measurement Quantity
CPICH 1
As_Th + As_Th_Hyst
AS_Th AS_Th_Hyst
As_Rep_Hyst
CPICH 2
CPICH 3
Time Event 1A Add Cell 2
Cell 1 Connected
Event 1C Replace Cell 1 with Cell 3
Event 1B Remove Cell 3
Figura 3.42 : Esempio di algoritmo di soft handover
Un possibile schema di algoritmo di soft handover quello qui descritto e di cui si forniscono due diverse interpretazioni nelle figure 3.42 e 3.43. La prima
84
3 Il sistema UMTS - I protocolli radio rappresenta il succedersi di possibili eventi legati al soft handover, mostrando come pu variare la qualit del segnale di riferimento ricevuto da diverse stazioni radio base in funzione del tempo. La seconda definisce invece il diagramma di flusso dellalgoritmo. Se un opportuno segnale di riferimento ricevuto da una stazione radio base appartenente allActive Set (AS) risulta inferiore, per un periodo di tempo
"!!# $%"!#!& '()0"1323"!&4'(5#67"#89"2@A&BC$(D3E'3"!#!&F"GC&323H8I#13!#&30
appartenente allAS, la stazione in oggetto viene eliminata dall Active Set. Se invece la differenza tra il livello di segnale di riferimento ricevuto dalla stazione migliore dellAS e quello ricevuto da una stazione radio base non appartenente !&P2@DQR$%I"GC&323 allAS inferiore di un certo valore per un periodo di tempo aggiunta allAS se questultimo non gi complet o. Se invece lAS pieno ma il segnale di riferimento ricevuto da una stazione radio base risulta superiore, sempre per un tempo STUIVWXY`aabdcfe@gQ`"h#h&bdi3`"h#h&cfXac"pCW&b3q3`rY`"s3s3W&b3V0`tc"Y3Yc"Va`"q3`"q@a`tc"h#hu&v9wU questultima viene sostituita.
Begin
Meas_Sign > Best_Ss As_Th as_Th_Hyst for a period of T
No (Event 1B) Remove Worst_Bs in the Active Set
Yes
Meas_Sign > Best_Ss As_Th + as_Th_Hyst for a period of T
Yes (Event 1A) Active Set Full Yes
No
No
Best_Cand_Ss > Worst_Old_Ss + As_Rep_Hyst for a period of T No Yes (Event 1C)
Add Best_Bs in the Active Set
Add Best BS in Active Set and Remove Worst Bs from th Active Set
Figura 3.43 : Diagramma di flusso dellalgoritmo di soft handover
85
3 Il sistema UMTS - I protocolli radio 3.7.7.3 Politiche di Admission Control Le politiche di Admission Control (radio, in quanto esiste anche un Admission Control di rete che esula dallo scopo di questo capitolo) prevedono di limitare laccesso di nuove chiamate alla rete anche in presenza di risorse radio disponibili. Tali politiche sono caratteristiche delle tecniche di accesso radio che, come il CDMA, prevedono una soft capacity, ovvero che vedrebbero via via peggiorare la qualit con il crescere del numero di chiamate. E dunque compito delloperatore stabilire quale deve essere il carico massimo e fissare i criteri che vietano laccesso alla rete di nuovi mobili per mantenere la qualit di servizio a livelli accettabili. Le politiche di Admission Control possono essere basate su vari criteri. Quello a cui si fa ora riferimento il criterio interferenziale, sicuramente uno dei pi importanti. Lingresso di un nuovo utente nella rete comporta la trasmissione di potenza sia in uplink sia in downlink con conseguente aumento di interferenza percepita dagli altri UE. E quindi utile accettare un nuovo terminale solo se linterferenza da lui prodotta non risulta tale da danneggiare gli altri utenti. Nella tratta in uplink, il nuovo UE provoca un incremento del livello di potenza ricevuta dalla stazione radio-base. Se tale incremento, funzione del servizio richiesto, dellattuale carico della rete e dellattenuazione, tale da rendere problematica la decodifica delle altre informazioni dutente, bene vietare laccesso alla rete del nuovo UE. Nella tratta in downlink, dove si usano codici di spreading ortogonali, il limite solitamente imposto dalla potenza massima che la stazione radio base pu trasmettere (limite fisico). In altri termini la stazione radio base pu trovarsi nella condizione di non poter trasmettere al nuovo utente la potenza necessaria, che, come prima, funzione del servizio richiesto, del carico del sistema e dellattenuazione. Sulla base di queste osservazioni, una politica di Admission Control deve cercare di valutare a priori se le potenze richieste dal nuovo UE sono compatibili con i limiti imposti dagli apparati, dalla rete e dalloperatore. Se tale condizione non verificata potrebbe essere impedito lacc esso alla rete del mobile. In alternativa, si possono iniziare opportune rinegoziazioni dei servizi richiesti dal nuovo utente con lintento di aumentare la probabilit di ingresso del nuovo UE. In base a quanto riferito, le politiche di Admission Control devono essere realizzate considerando per esempio il tipo di QoS richiesto. Dai parametri standard di QoS, deriva una specifica categoria identificata dai tipi di servizi, usati per realizzare le politiche di ammissione. Si definiscono le seguenti tipologie di servizio:
Premium services: sono i servizi caratterizzati da bassi ritardi, alta priorit. Assured services: viene garantito un bit rate minimo al di sotto di quello medio. Questi servizi, caratterizzati da un livello medio di priorit, possono usare una banda maggiore quando disponibile. Best effort: sono caratterizzati da un basso livello di priorit. Non garantita alcuna QoS.
86
3 Il sistema UMTS - I protocolli radio Si descrivono adesso alcuni possibili esempi, per mostrare come il livello RRC sia coinvolto nelle procedure di Call Admission Control (CAC). E importante sottolineare come l Admission Control sia realizzato dal Controlling RNC (CRNC) sotto indicazione del SRNC. Si ricorda che il CRNC quel Radio Network Controller con il controllo totale delle risorse dei Node-B che gli sono stati assegnati e che c un solo CRNC per ogni Node-B. In figura 3.44 si illustra un primo scenario. Esso elenca le entit e le operazioni coinvolte nella procedura di CAC, quando linterfaccia Iur non utilizzata e il Controlling RNC (CRNC) prende il ruolo di SRNC.
Serving RNC
1. RANAP Message
RRM Entity
RANAP
4. RANAP Message
2. Mapping QoS parameter/ type of service 2bis. CAC 3. Resource allocation
RRC
4. CRLC-CONFIG
C-SAP
RLC
4. CMAC-CONNECT
MAC
4. CPHY-RL-Setup-REQ
Figura 3.44 : Interazione dei livelli RANAP e RRC coinvolti nel processo di CAC
I passi della procedura sono i seguenti: 1. la Core Network chiede al SRNC di instaurare un RAB, indicando i parametri di QoS. 2. In base ai parametri della qualit di servizio, si associa un tipo di servizio al servizio richiesto. Si realizza quindi la procedura di CAC tenendo conto del tipo di servizio. 3. Si allocano le risorse in base al risultato del processo di CAC. 4. Si invia alla CN un messaggio di riscontro in base al risultato del CAC. Si configurano di conseguenza i livelli sottostanti.
87
3 Il sistema UMTS - I protocolli radio In figura 3.45 si illustra un secondo scenario. Se si vuole instaurare un canale radio dedicato in un Node-B controllato da un RNC diverso dal SRNC, questultimo invia una richiesta di instaurazione di un link radio al DRNC. Poich il CAC sempre realizzato nel CRNC, sar il DRNC ad occuparsi di questa procedura e a comunicare il risultato al SRNC per mezzo dellinterfaccia Iur.
Drift RNC
1. RNSAP Message
RRM Entity
RNSAP
4. RNSAP Message
2. CAC 3. Resource allocation
RRC
C- SAP 4. CPHY-RL-Setup-REQ
Figura 3.45 : Interazione dei livelli RNSAP e RRC coinvolti nel processo di CAC
I passi seguiti in questo caso sono: 1. SRNC richiede al Drift RNC di instaurare un nuovo canale radio, indicando le caratteristiche del DCH. Queste contengono implicitamente i requisiti sulla QoS. 2. Si realizza la procedura di CAC in base al tipo di servizio, fissato a partire dai parametri legati alla QoS. 3. Si allocano le risorse a seconda del risultato del CAC. 4. Si invia un messaggio al SRNC per informarlo del risultato del CAC. In figura 3.46 si illustra un terzo scenario. La situazione simile alla precedente, solo che ora si vuole instaurare un canale radio comune. I passi seguiti in questo caso sono: 1. SRNC richiede al Drift RNC di instaurare un nuovo canale radio. Un messaggio RNSAP contiene i requisiti sulla QoS e il tipo di canale di trasporto comune. 2. Si realizza la procedura di CAC in base al tipo di servizio, fissato a partire dai parametri legati alla QoS, e al tipo di canale comune richiesto dal SRNC. 3. Si allocano le risorse a seconda del risultato del CAC. 4. Si invia un messaggio al SRNC per informarlo del risultato del CAC. I livelli 1 e MAC sono configurati dal livello RRC di conseguenza.
88
Drift RNC
1. RNSAP Message
RRM Entity
RNSAP
4. RNSAP Message
2. Mapping QoS parameter/ type of service 2bis. CAC 3. Resource allocation
RRC
C-SAP 4. CMAC-CONNECT
MAC
4. CPHY-RL-Setup-REQ
Figura 3.45 : Interazione dei livelli RNSAP e RRC coinvolti nel processo di CAC
3.7.7.4 Controllo dei Radio Bearer Le procedure di controllo dei Radio Bearer vengono usate per gestire le risorse di sistema e gli UE, in base a misurazioni per esempio sul volume di traffico. Nei punti che seguono si riportano alcuni scenari per spiegare come funziona il sistema. (a) Instaurazione di un Radio Bearer Per instaurare un Radio Bearer, necessario che sia stata instaurata precedentemente una connessione RRC tra lUE e lUTRAN. Il messaggio di RB SETUP arriva dallUTRAN e indica le caratteristiche del servizio che si richiede. In base a questi parametri si sceglie se conviene utilizzare un canale di trasporto comune o dedicato. In figura 3.46 si riporta una possibile configurazione del livello 2 lato UTRAN, prima e dopo linstaura zione del Radio Bearer. (b) Riconfigurazione di un Radio Bearer Una volta instaurato un Radio Bearer pu anche essere riconfigurato. La procedura di riconfigurazione pu essere utilizzata per variare i parametri di un certo RB (quali canali fisici, canali di trasporto, tipo di multiplexing, TFC e TFCS, canali logici e loro priorit). In figura 3.47 si rappresenta un esempio di riconfigurazione dei RB che porta a cambiare i parametri di multiplexing nel MAC e a rimuovere di conseguenza il canale DCH3, che nella nuova configurazione non ha pi utilit. Dal disegno si possono confrontare le strutture dei Radio Bearer 1 e 2, prima e dopo la procedura.
89

Configuration in L2 before Setup Signalling bearer RLC
MAC-d
Configuration in L2 after Setup Signalling bearer RLC

MAC-d
RB1 RLC DTCH
DCCH
DCCH
Channel Switching
Channel Switching MUX
MAC-c
MAC-c
RNTI MUX MUX TF Select Common channel (FACH)
Figura 3.46 : Esempio di configurazione di livello 2 lato UTRAN prima e dopo una RB Setup
Configuration in L2 before Reconfiguration Signalling RB1 RB2 bearer RLC

MAC-d
Configuration in L2 after Reconfiguration Signalling RB1 RB2 bearer RLC

MAC-d
RLC DTCH Channel Switching
RLC DTCH
RLC DTCH Channel Switching MUX
RLC DTCH
DCCH
DCCH
TFC Select DCH1 DCH2 DCH3 DCH1
TFC Select DCH2
Figura 3.47 : Esempio di configurazione dei RB nellUTRAN prima e dopo una RB reconfiguration
(c) Riconfigurazione dei canali di trasporto Questa procedura RRC utilizzata per riconfigurare i canali di trasporto e i canali fisici e pu anche comportare un cambiamento del canale di trasporto usato. Si possono verificare molteplici situazioni. Per esempio, quando il volume di traffico di un dato canale di trasporto di un UE supera una certa soglia (figura 3.48), si invia allUTRAN un resoconto di q uanto accaduto. In base al carico totale nella rete e delle risorse disponibili, lUTRAN pu decidere ad esempio di cambiare il rate dellutente assegnandogli un nuovo codice con uno spreading factor pi basso. Diversamente per aumentare il throughput per un UE, lUTRAN pu cambiargli il formato di trasporto e il TFC. Pu capitare anche che il traffico in downlink dalla rete verso lUE
90
3 Il sistema UMTS - I protocolli radio scenda sotto una certa soglia. Se si stava usando un canale di trasporto dedicato, una possibilit quella di rilasciarlo e passare ad utilizzare un canale di trasporto comune. Le figure 3.49 e 3.50 illustrano rispettivamente le interazioni tra UE e UTRAN e la variazione della configurazione dellUTRAN prima e dopo lo switch da un canale allaltro.
UL Transport Channel Traffic Volume UE Threshold for Report DCH/DCH substate DCCH: Measurement Report
Configuration in L2 UTRAN Signalling bearer RLC

MAC-d
RB1 RLC DTCH
DCCH
Evaluation DCCH: Transport Channel Reconfiguration Change of UL Ch. Codes, TF and TFC at Action Time DCCH: Transport Channel Reconfiguration Complete
Channel Switching
TFC Select DCH1 DCH2
Figura 3.48 : Riconfigurazione del canale di trasporto avviata da un incremento dei dati in uplink e configurazione di livello 2 nellUTRAN
DL Transport Channel Traffic Volume UE DCH/DCH substate DCCH: Transport Channel Reconfiguration RACH/FACH substate DCCH: Transport Channel Reconfiguration Complete UTRAN UL/DL Traffic Evaluation
Figura 3.49 : Riconfigurazione del canale di trasporto avviata da un decremento dei dati in downlink con sostituzione della coppia di canali DCH/DCH con RACH/FACH
91
Configuration in L2 before Reconfiguration Signalling bearer RLC

MAC-d
Configuration in L2 after Reconfiguration Signalling bearer RLC

MAC-d
RB1 RLC DTCH
RB1 RLC DTCH
DCCH
DCCH
Channel Switching
TFC Select DCH1 DCH2
MAC-c
Figura 3.50 : Configurazione del livello 2 nellUTRAN prima e dopo riconfigurazione del canale di trasporto ottenuta con lo switch di canali di trasporto
(d) Riconfigurazione dei canali fisici Questa procedura viene utilizzata per riconfigurare i canali fisici e pu portare a cambiare i canali di trasporto utilizzati. Anche in questo caso sono possibili molti casi, in base alla quantit dei dati in uplink e downlink. Per fare un esempio, un UE che si trova nel sottostato associato ai canali RACH/FACH, pu trasmettere una piccola quantit di dati dutente usando i canali di trasporto comune. Per trasferire quantit maggiori sarebbe appropriato utilizzare dei canali di trasporto dedicati. Il monitoraggio del bisogno di capacit dellUE gestito dallUTRAN mediante misurazioni compiute nellUE. Quando il volume di traffico su un canale di trasporto in uplink, supera una certa soglia, lutente informa lUTRAN con opportuni messaggi. In questo modo, disponendo delle informazioni sul carico totale in uplink, lUTRAN pu decidere se possibile allocare per quellUE un canale di trasporto dedicato. Inoltre pu cambiargli i formati di trasporto iniziando la procedura di Physical Channel Reconfiguration. Nelle figure 3.51 e 3.52 si illustrano i messaggi scambiati tra UE e UTRAN per realizzare questa procedura di riconfigurazione di canale fisico in uplink, allocando un canale dedicato per lUE al posto del RACH.
92
UL Transport Channel Traffic Volume Threshold for Report UE RACH/FACH substate DCCH: Measurement Report Evaluation DCCH: Physical Channel Reconfiguration DCH/DCH substate DCCH: Physical Channel Reconfiguration Complete (FFS) UTRAN
Figura 3.51 : Riconfigurazione di canale fisico avviata da un incremento dei dati in uplink con switch da RACH/FACH a DCH/DCH
Configuration in L2 before Reconfiguration Signalling bearer RLC

MAC-d DCCH
Configuration in L2 after Reconfiguration RB1 RLC Signalling bearer RLC

MAC-d DCCH
RB1 RLC DTCH
DTCH

MAC-c
Channel Switching
TFC Select RNTI MUX MUX TF Select DCH1 DCH2
Common channel (RACH)
Figura 3.52 : Configurazione del livello 2 prima e dopo una riconfigurazione di canale fisico in uplink con uno switch dei canali di trasporto (da RACH a DCH)
93

UMTS - Protocolli Radio

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

UMTS - Protocolli Radio

Caricato da

Copyright:

Formati disponibili

Capitolo 3 Il sistema UMTS - I protocolli radio

3.1 Architettura generale dei protocolli radio

Duplication avoidance GC C-plane signalling Nt DC UuS boundary U-plane information

RLC RLC RLC RLC RLC RLC RLC

Logical Channels MAC

Figura 3.1 : Architettura protocollare dellinterfaccia radio

3.2 Il livello Fisico

3 Il sistema UMTS - I protocolli radio

3.2.1 I canali di trasporto

Sono previsti i seguenti canali comuni:

3 Il sistema UMTS - I protocolli radio

E inv ece previsto un solo tipo di canale dedicato:

3.2.2 I canali fisici

3 Il sistema UMTS - I protocolli radio

Canale fisico corrispondente

SCH FACH PCH RACH CPCH(FDD) USCH(TDD) DSCH DCH

Tabella 3.1 : Corrispondenza tra canali fisici e di trasporto

I canali fisici dedicati invece sono:

3 Il sistema UMTS - I protocolli radio

Figura 3.2 : Albero dei codici OVSF

3.3 Il livello MAC

PCCH BCCH CCCH CTCH SHCCH

MAC Control DCCH DTCH

FACH FACH RACH CPCH USCH USCH DSCH DSCH

Figura 3.3 : Architettura MAC lato UE

PCCH BCCH CCCH

MAC Control DCCH DTCH

PCH FACH FACH

RACH CPCH USCH USCH DSCH DSCH

DCH Iur or local

Figura 3.4 : Architettura MAC lato UTRAN

3 Il sistema UMTS - I protocolli radio

Figura 3.5 : Entit MAC-b lato UE e lato UTRAN

3.3.1 I Servizi MAC

Canali di controllo: per il trasferimento delle informazioni del piano di controllo.

3 Il sistema UMTS - I protocolli radio

Figura 3.6 : Struttura dei canali logici

Tra i canali di controllo si trovano:

3 Il sistema UMTS - I protocolli radio I principali canali di traffico sono:

BCCH- PCCHSAP SAP

CCCH- SHCCH- CTCHSAP SAP SAP (TDD only)

DTCHSAP MAC SAPs

FACH USCH DSCH DCH

3 Il sistema UMTS - I protocolli radio

3.3.2 Elementi per le comunicazioni tra livelli

3 Il sistema UMTS - I protocolli radio

access information (1)

TFI, Transport Block Set, CRC check result, TD (4)

Not Defined Event value

Not Defined Not Defined

Transport Format subset (1) Not Defined

Tabella 3.2 : primitive tra i livelli 1 e MAC

I parametri principali di queste primitive sono:

Data: indica le PDU di livello RLC da trasmettere o inviare

3 Il sistema UMTS - I protocolli radio

MAC-STATUS NOTE: TDD only.

Tabella 3.3 : Primitive tra i livelli MAC e RLC

3 Il sistema UMTS - I protocolli radio

I principali parametri di queste primitive sono:

Tabella 3.4 : Primitive tra i livelli MAC e RRC

3 Il sistema UMTS - I protocolli radio

3.3.3 Funzioni di livello MAC

3 Il sistema UMTS - I protocolli radio

Check traffic volume of transport channels