MBMS 1 2006

ACCESSO
MBMS: la nuova frontiera del mobile broadcasting
ANDREA BULDORINI MAURO CASTAGNO ROSARIO DROGO DE IACOVO MARIA PIA GALANTE GIANLUCA GRECO DAVIDE SORBARA
MBMS rappresenta una vera rivoluzione per il mondo radiomobile, abituato sin dagli albori alluso di canali punto punto (p-t-p, point to point) per servire gli utenti in mobilit. Lintroduzione di un canale punto multipunto (p-t-m, point to multipoint) e la gestione dei servizi e delle applicazioni ad esso collegato, incluse la sicurezza dei dati scambiati e la tariffazione, ha richiesto la revisione completa dellarchitettura della rete radiomobile, dal terminale al GGSN. Nellarticolo si descrive brevemente larchitettura di riferimento per MBMS e gli elementi di rete pi coinvolti, le procedure Multicast e Broadcast, gli aspetti di sicurezza e la tariffazione, il livello applicativo per MBMS (codec e protocolli) e, per finire, laccesso radio MBMS in GERAN e in UTRAN.
1. Introduzione
Ci sono voluti circa due anni e mezzo di intenso lavoro, ma alla fine del 2004 il 3GPP ha approvato lintroduzione di MBMS (Multimedia Broadcast Multicast Service) nelle specifiche tecniche di Release 6. MBMS lo standard 3GPP che permette il supporto del Mobile Broadcasting, cio di tutto linsieme di servizi e applicazioni di tipo streaming o download and play fruibili contemporaneamente da un insieme di utenti. Lopera di standardizzazione stata imponente ed ha coinvolto quasi tutti i gruppi di lavoro del 3GPP:
laccesso UTRAN e GERAN (WG RAN e WG GERAN ); la core network e i terminali (WG CT); i servizi e larchitettura (WG SA1 e SA2); le applicazioni ed i codec (WG SA4); la sicurezza (WG SA3). Con MBMS possibile usare al meglio le risorse radio, quando il numero degli utenti in una cella supera una certa soglia, per offrire servizi diversi (download di file video e audio, messaggistica di vario tipo e potenzialmente anche mobile TV) sfruttando un solo canale condiviso da tutti, senza quindi impiegare tanti canali radio dedicati, uno per ogni utente. Inoltre MBMS pu essere usato in
NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006
49
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
caso di emergenza pubblica per veicolare la stessa informazione ad una platea molto ampia nel pi breve tempo possibile. Per poter offrire MBMS necessario aggiornare molti nodi della rete radiomobile 2G e 3G (BSC, RNC, SGSN, GGSN) ed introdurre anche un nuovo elemento, il BM-SC (Broadcast MulticastService Center). Visto quindi il numero di nodi di rete coinvolti, la tecnologia MBMS non far la sua comparsa prima della met del 2008, ed in ogni caso per poterne usufruire occorrer avere un terminale di Release 6 che supporti MBMS. La sua completa diffusione tra gli utenti richieder alcuni anni, considerando il normale tasso di sostituzione dei cellulari.
2. MBMS Bearer Service

Un generico servizio MBMS, come ad esempio un filmato, uno streaming live o un brano MP3, tecnicamente realizzato tramite due componenti fondamentali: una componente di trasporto (MBMS Bearer Service) ed una applicativa o di contenuto (MBMS User Service) . Il Bearer Service MBMS il servizio di trasporto offerto dal dominio PS per la trasmissione di pacchetti IP a pi ricevitori secondo un determinato profilo di QoS. Il Bearer Service viene gestito dalla rete secondo le tecniche che saranno descritte in questo paragrafo, e nei paragrafi 5 e 6, improntate ad un uso efficiente delle risorse radio e core. Lo User Service MBMS invece lapplicazione resa allutente finale per mezzo dellMBMS bearer service, ovvero il contenuto del servizio opportunamente codificato e formattato secondo le soluzioni descritte nel paragrafo 4. Lo User Service pu utilizzare i servizi di trasporto di uno o pi Bearer Service. Ad esempio, un videoclip pu essere trasmesso su due diversi bearer service, caratterizzati da diversa QoS (bit rate) e distribuiti su accessi radio (2G e 3G) distinti. In questa sezione descriveremo gli aspetti di sistema a supporto del bearer service MBMS.
il nodo GSN serva o meno unarea di distribuzione. In altre parole, ogni nodo di rete interessato da un singolo flusso dati in arrivo dal BM-SC, indipendentemente dal numero N di ricevitori verso cui diretto (modalit punto-multi-punto, pt-m), anzich da N flussi distinti (modalit puntopunto, p-t-p). Il numero di nodi GSN, e di nodi RNC/BSC, interessati al servizio dipende dallestensione dellarea di diffusione del servizio stesso o dalla distribuzione degli utenti multicast. LRNC per lUTRAN, o il BSC per il GERAN, provvedono a trasmettere i dati ai terminali MBMS utilizzando efficientemente le risorse radio, ad esempio con canali punto-multipunto. Luso efficiente dellinterfaccia radio sicuramente il requisito fondamentale dellintera architettura. La configurazione dellalbero di distribuzione dei contenuti uno degli aspetti architetturali pi interessanti. In particolare, la lista dei nodi GSN e RNC interessati dalla trasmissione di un certo servizio MBMS pu essere ottenuta tramite procedure di segnalazione specifiche iniziate dai singoli utenti/terminali interessati al servizio, oppure configurata in maniera statica dalloperatore. Nel primo caso, si parla di modo Multicast, nel secondo di modo Broadcast. Come si evince dalla figura 1 lunica nuova interfaccia di rete definita a supporto dellMBMS linterfaccia di segnalazione Gmb tra GGSN e BMSC. Su di essa transita la segnalazione user specific, relativa allautorizzazione del singolo utente al servizio Multicast e la segnalazione bearer specific, relativa alla registrazione dei nodi GGSN allalbero di distribuzione dei contenuti. Per il resto, MBMS comporta impatti funzionali ai nodi di rete ed alle interfacce esistenti, con la modifica delle relative interfacce.
PDN (e.g. Internet) Content Provider/ Multicast Broadcast Source
UTRAN
2.1 Architettura ed elementi di Rete

Nellarchitettura di rete per MBMS illustrata in figura 1, spicca il nuovo nodo di rete BM-SC cio la sorgente dei dati MBMS allinter no della PLMN. Esso affida la distribuzione dei contenuti multimediali al dominio GPRS (nodi xGSN) tramite linterfaccia Gi. I meccanismi di rete attuati da MBMS sono tali per cui il numero di connessioni associate ad un dato servizio (da BM-SC a GGSN, da GGSN a SGSN, e da SGSN a RNC/BSC) non sono pi proporzionali al numero di utenti interessati al servizio, ma sono al massimo una, o nessuna, a seconda che
UE
UTRAN
SGSN
GGSN TPF
BM - SC
Content Provider/ Multicast Broadcast Source
UE
GERAN
BM-SC GERAN GGSN SGSN TPF UE UTRAN
= = = = = = =
Broadcast Multicast-Service Centre GSM/EDGE Radio Access Network Gateway GPRS Support Node Serving GPRS Support Node Traffic Plane Function User Equipment UMTS Terrestrial Radio Access Network
FIGURA 1 Architettura della rete iradiomobile per MBMS.
50
2.2 Modalit Multicast e Broadcast

L a di ff e re nza so stan zi al e tra Mu l ti ca st e Broadcast Mode MBMS sta nel fatto che il primo servizio distribuisce i contenuti solo nelle aree di rete in cui sono presenti terminali che ne hanno attivato la ricezione, mentre il secondo un servizio di trasporto che viene attivato in alcune aree dallOperatore indipendentemente dalla presenza di ricevitori interessati. Il Multicast Mode si basa su un meccanismo di segnalazione che permette al terminale di associarsi al gruppo multicast relativo ad un dato servizio (MBMS Multicast Service Activation) ; tale segnalazione consente alla rete di costruire un albero di distribuzione dei dati che utilizza in maniera efficiente le risorse trasmissive per servire il gruppo di utenti. Lalbero viene gestito dinamicamente, aggiungendo o rimuovendo nodi per effetto della mobilit degli utenti del gruppo stesso. Lobiettivo delle procedure MBMS Multicast dunque quello di creare nei singoli nodi un set di informazioni (MBMS bearer context) utili a caratterizzare il piano di trasporto, e di garantire linstradamento dei dati solo verso i nodi GGSN e SGSN che controllano gli utenti che hanno effettivamente richiesto il servizio. Il Broadcast Mode, invece, attivato da rete in unarea di broadcast predefinita indipendentemente dalla presenza di utenti interessati al servizio. Il terminale, in base alle informazioni ottenute in seguito al Service announcement (paragrafo 2.3), attiva localmente la ricezione broadcast. Nel caso MBMS Multicast, inoltre, la rete daccesso pu decidere la tipologia di canale radio da utilizzare in una cella (punto-punto oppure puntomultipunto), confrontando il numero di utenti presenti ed interessati al servizio con una soglia prefissata. Tali tecniche saranno descritte nei paragrafi 5.2 e 6.2. Nel Broadcast mode tale ottimizzazione non ovviamente possibile. A parte queste differenze, i meccanismi utilizzati per linstaurazione delle risorse di trasporto in rete core e di accesso sono stati messo a punto in maniera da essere riutilizzabili il pi possibile per entrambe le modalit di trasmissione, Multicast e Broadcast, per ovvie ragioni di semplicit architetturale. Pertanto, le fasi di service provisioning per MBMS, schematizzate in figura 2, sono per lo pi comuni ad entrambe le modalit. Fanno eccezione le fasi di Subscription e Joining/Leaving che, nel caso Multicast, servono a comporre dinamicamente il gruppo di utenti multicast e ad allestire in rete lalbero di distribuzione dei contenuti. In entrambe le modalit di trasmissione MBMS, una volta determinato il set di nodi che costituisce lalbero di distribuzione, necessario far precedere linvio dei dati da una fase di preparazione delle risorse di trasporto (Session Start, MBMS Notification, , Session Stop) , per esempio per effettuare il paging ed il radio bearer set up in accesso. Infine, la conoscenza degli utenti associati ad un servizio Multicast, permette alloperatore radioSubscription Service Announcement Joining Session Start MBMS notification Data transfer Session Stop Leaving
Fasi valide solo per il modo Multicast
FIGURA 2 Fasi di service provisioning per MBMS per modalit broad-
cast e multicast.
mobile, di effettuare la tariffazione sulla base di tutta una serie di informazioni dutente e di servizio raccolte nel nodo BM-SC. Come si vedr pi avanti (paragrafo 3), sono state lungamente discusse delle modalit di tariffazione accurate e compatibili con il paradigma peculiare di servizio non riscontrato quale quello MBMS. Tali soluzioni, naturalmente, non sono applicabili al Broadcast Mode, per il quale sarebbe possibile solo il charging del content provider.
2.3 Service provisioning e procedure

Di seguito viene proposto un breve cenno alle fasi di service provisioning illustrate in figura 2 e alle procedure di rete atte a supportarle. Subscription il tradizionale contratto tra utente e operatore che regola la fornitura del servizio. una fase fondamentale nel modello Multicast: a valle di questa, le informazioni di sottoscrizione sono registrate nel nodo BM-SC e servono ad autorizzare o meno laccesso ad un dato servizio MBMS (user service). Tale fase non fondamentale nel Broadcast. Le procedure a supporto della Subscription esulano dallambito normativo del 3GPP. Service Announcement La fase di Service Announcement annuncia e pubblicizza i servizi dutente disponibili, offrendo anche tutta una serie di informazioni/parametri necessari per la loro attivazione (es. tempo dinizio, identificativo del servizio ovvero IP multicast address, ). A queste informazioni possono accedere anche utenti non (ancora) sottoscritti al servizio. Per questa fase non sono state introdotte
51
ll GGSN controlla presso il BM-SC che lutente sia effettivamente autorizzato ad accedere al servizio. In caso positivo, la rete richiede al terminale di attivare un MBMS Context fornendo, se necessa Joining rio, ulteriori parametri utili (es. un nuovo APN). Il Joining il processo tramite il quale un utente Alla ricezione dellActivate MBMS Context diventa membro di un gruppo multicast. La proceRequest da parte dello UE, il nodo SGSN invia la dura che abilita il Join la MBMS Multicast richiesta di creazione di un contesto MBMS al Activation: tramite questa, lutente indica alla rete nodo GGSN per segnalare la presenza di un la volont di ricevere un servizio multicast identifi(nuovo) utente interessato al servizio. cato da uno specifico indirizzo IP multicast. Il GGSN chiede al BM-SC di essere incluso nel Leffetto della procedura quello di individuare set di nodi a cui dovr essere inviato il contenuto un albero di distribuzione dei dati e distribuire le relativo al servizio (MBMS Registration Request), informazioni a supporto del servizio nei nodi di rete ammesso che tale procedura non fosse stata gi interessati. eseguita al Join di un precente utente. Come gran parte delle procedure MBMS, anche Il BM-SC, accettando la richiesta, inserisce il quella di Service Activation piuttosto complessa, GGSN nella cosiddetta list of downstream nodes; per cui nel seguito se ne illustreranno, semplificaninoltre, passa al nodo GGSN un set di parametri doli, gli aspetti pi salienti. che caratterizzano il servizio attivato (MBMS Con riferimento alla figura 3, lattivazione viene Bearer Context). I parametri tipicamente inclusi iniziata dallo UE con un messaggio di Join IGMP (o nellMBMS Bearer Context sono: il TMGI MLD) contenente lindirizzo IP multicast associato ( Temporary Mobile Group Identity , lidentificativo al servizio di interesse. del gruppo multicast, di cui si dir anche pi avanti), la QoS richiesta per il servizio di trasporto (Background o Streaming), larea allinterno della quale il servizio pu essere distribuito, il tipo di modalit UE RAN SGSN GGSN BM-SC broadcast/multicast del bearer, le capability minime richieste al terminale . IGMP Join Ricevuto un riscontro positivo, anche MBMS Authorization lSGSN si registra al GGSN, ovvero Request MBMS Context Activation allalbero di distribuzione del servizio, Activate MBMS Context Request ammesso che non lo abbia gi fatto in Create MBMS Context Request precedenza per effetto del Join di un altro utente allo stesso servizio, ed MBMS ottiene dal GGSN le informazioni di Registration Request MBMS Bearer Context di cui sopra. Create MBM In aggiunta al Bearer Context, che Context Response caratterizza il servizio, nei nodi SGSN e GGSN per ogni UE viene creato anche MBMS un cosiddetto UE Context, incluso nel Registration Request Mobility Management Context GPRS. Lo UE Context MBMS contiene per ogni UE Provision info to RAN informazioni pi attinenti al singolo terminale/utente (es. IMSI, identificativo del Activate MBMS Context Accept PDP Context unicast utilizzato per la segnalazione IGMP, lista dei servizi BM-SC = Broadcast Multicast-Service Centre MBMS attivi, ). Linsieme degli UE GGSN = Gateway GPRS Support Node IGMP = Internet Group Management Protocol Context aiuta a determinare su ciascun MBMS = Multimedia Broadcast Multicast Service nodo il numero di utenti associati ad un RAN = Radio Access Network SGSN = Serving GPRS Support Node singolo MBMS Bearer. UE = User Equipment Si noti, infine, come per effetto delle p ro c e d u re d i J o i n d i p i u t e n t i a l l o stesso servizio venga creato un solo FIGURA 3 MBMS Multicast Service Activation. Bearer Context in ciascun nodo di rete, indipendentemente dal numero di utenti associati al gruppo multicast. Il messaggio arriva al GGSN tramite un geneAttraverso la procedura denominata UE rico PDP context di tipo unicast che si assume Linking e valida solo per laccesso UTRAN, il essere gi attivo al momento del Join, e che nodo SGSN for nisce allRNC sia il Bearer dovr rimanere attivo per tutta la durata della Context (per quanto sopra, questo avviene solo registrazione dellutente al servizio MBMS. La nel caso il Bearer Context non fosse gi prerichiesta di Join viaggia in maniera trasparente al sente in RNC per effetto della presenza di altri nodo SGSN. utenti) che lo UE context.
nuove procedure di segnalazione di rete essendo possibile riutilizzare meccanismi gi noti quali Push SMS/WAP, SMS Cell Broadcast, .
52
Al termine di tali procedure, il nodo SGSN conferma allo UE la richiesta di attivazione del bearer inviando, tra i vari parametri, anche il TMGI (Temporary Mobile Group Identity). Il TMGI lidentificativo del bearer service a cui lo UE si associato. Esso viene utilizzato dalla rete sulla tratta radio nella procedura di paging per notificare a tutti (e soli) gli utenti del gruppo linizio della trasmissione. Da notare che nel caso MBMS Broadcast, il TMGI deve essere reso noto allo UE attraverso il Se rvi c e An noun cemen t, n o n essendo prevista la procedura di Join appena descritta.
UE
RAN
SGSN
GGSN
BM-SC
Session Start Request/Response Session Start Request/Response Session Start Request/Response
Resource Set up
Session Start Al Session Start il nodo BM-SC pronto per linvio dei dati, e la sessione multicast/broadcast pu FIGURA 4 Procedura di Session Start. avere inizio. In genere tale evento scorrelato dal Join (ovvero, un certo utente potrebbe decidere di associarsi al gruppo multicast anche a trasmis MBMS Notification sione gi iniziata). la procedura tramite la quale i terminali venLa figura 4 mostra i flussi informativi a supporto gono informati della trasmissione MBMS incidel Session Start. piente. Con riferimento alla figura 4, la Notification Nel caso Multicast, il Session Start consiste coincide con lultimo passo del Session Start, nellinvio di un messaggio di Session Start Request ovvero la creazione di connettivit radio attraverso da BM-SC a tutti i nodi GGSN da cui il BM-SC ha la quale inviare i dati MBMS. ricevuto le Registration Request. A loro volta, i nodi Approfondimenti su tale fase verranno forniti nei GGSN propagano il Session Start Request verso i paragrafi 5.1 e 6.1. nodi SGSN appartenenti allalbero di distribuzione del servizio, ovvero verso gli SGSN dai quali hanno Data transfer ricevuto una Registration Request. Si noti che tra la fase in cui i dati sono effettivamente tramite il Join degli utenti ad un dato servizio multismessi da BM-SC ai terminali. cast viene creato lalbero di distribuzione dei dati e ciascun nodo viene dotato delle informazioni di Session Stop servizio corrispondenti (MBMS Bearer Context), Al termine della trasmissione, il BM-SC pu mentre le risorse trasmissive lungo tale percorso decidere il rilascio delle risorse di trasporto vengono attivate solo grazie alle procedure di inviando un comando di Session Stop ai nodi di Session Start. rete coinvolti. Nel caso Broadcast, la lista dei nodi GGSN e SGSN viene preconfigurata in BM-SC dallopera Leaving tore, per ciascun servizio; grazie al Session Start le Grazie alle procedure di Leaving (MBMS risorse vengono poi impegnate per la trasmissione. Multicast Deactivation) il sottoscrittore di un dato In questo caso, alla ricezione del Session Start servizio esce dal gruppo multicast. Si noti che il viene anche creato il bearer context nei nodi GGSN Leaving implica la rimozione del Bearer Context da e SGSN interessati dal servizio. un certo nodo di rete (modifica dellalbero di distriTipicamente, tramite questa procedura il BM-SC buzione) solo quando anche lultimo membro del distribuisce lungo tutto lalbero di distribuzione gruppo disattiva il servizio sul nodo. anche alcuni parametri di interesse (session attribuAlle procedure brevemente sopra esposte, vanno tes), che arricchiscono, e in certi casi vanno a aggiunte quelle scatenate in rete per effetto della sovrascrivere, quelli gi presenti nel relativo Bearer mobilit di un terminale associato ad un gruppo. Tali Context. Esempi tipici di attributi di sessione sono il procedure si suddividono in Registration Procedure TMGI, il Session Identifier (identifica per un certo e Inter/Intra SGSN Routing Area Update. servizio tutte le trasmissioni incluse tra un Session Le Registration Procedure, in generale, servono Start ed un Session Stop), lEstimated Session ad associare un nuovo nodo (RNC, BSC, SGSN o Duration (la durata della sessione), il Time To Data GGSN) allalbero di distribuzione multicast, per Transfer (stima del tempo intercorrente dallinvio del effetto dellarrivo di un membro del gruppo nellarea Session Start Request allinizio della trasmissione). servita.
BM-SC GGSN RAN SGSN UE
= = = = =
Broadcast Multicast-Service Centre Gateway GPRS Support Node Radio Access Network Serving GPRS Support Node User Equipment
53
Le procedure di Inter/Intra SGSN RAU sono invece le procedure di mobilit classiche del GPRS (3GPP Technical Specification 23.060), a cui sono state aggiunte nuove logiche per gestire la rilocazione degli UE Context da un vecchio ad un nuovo SGSN. Tali logiche richiedono tipicamente linvocazione delle Registration Procedure di cui sopra (es. nel caso in cui lo UE Context istanziato nel nuovo SGSN contenga lidentificativo di un servizio MBMS il cui Bearer Context non presente nel nodo). Infine, nella figura 5 sono sintetizzati in termini macroscopici gli impatti previsti sul sistema 3GPP per lintroTerminali: adesione ai duzione del servizio MBMS gruppi Multicast e ricezione in PtM. Multicast, e che anticipano alcuni aspetti che saranno .... pi approfonditamente tratPTM BSC tati nei paragrafi successivi. ...
BSC
3.1 Procedura di Autenticazione MBMS

Il meccanismo di (mutua) autenticazione previsto tra UE e BM-SC di tipo http digest (RFC 2617). Le credenziali (username e password) richieste da http digest si assumono condivise in precedenza tra le parti (UE e BM-SC). Il metodo utilizzato per la condivisione di cui sopra si basa sul concetto di GBA (Generic Bootstrapping Architecture) brevemente descritto nel seguito e in
Radio Access: nuove funzionalit in GERAN e UTRAN permettono il setup di canali trasmissivi di tipo PUNTO-MULTIPUNTO in ciascuna cella servente almeno un utente interessato al servizio. UTRAN permette il fallback a trsmissione PUNTO-PUNTO in caso di basso numero di utenti. GERAN prevede una trasmissione radio PtM riscontrata per basso numero di utenti. Service Centre (User profile e gestione accesso ai servizi MBMS, Content Source, Point-to-Point Repair)
SGSN GTP SGSN GGSN BM-SC
3. Aspetti di sicurezza e tariffazione
....
PTM PTP
RNC ... RNC
MBMS introduce il conc e tto di se rviz i o d i ti p o BSC = Base Station Controller punto-multipunto nelle reti GGSN = Gateway GPRS Support Node GTP = GPRS Tunneling Protocol 3GPP e consente linvio di MBMS = Multimedia Broadcast Multicast Service un certo contenuto informaPtM = Point to Multipoint RNC = Radio Access Network tivo, da un BM-SC ad un SGSN = Serving GPRS Support Node gruppo di legittimi destinatari. Al fine di controllare laccesso al servizio e al contenuto distribuito, ossia FIGURA 5 Impatti in rete per MBMS (caso Multicast). al fine di arginare possibili scenari fraudolenti e di rendere possibile una corretta tariffazione del servizio, cui il ruolo di NAF (Network Application Function) per tutte le tipologie di tariffazione previste dallo assunto dal BM-SC. standard (charging scheme), alcuni meccanismi di sicurezza MBMS sono stati messi a punto in ambito 3GPP. In primo luogo, la tariffazione di un servizio presuppone la certezza dellidentit dellutente che ne Content Mobile Operator Network usufruisce e implica, pertanto, una procedura di Server autenticazione. La natura multicast/broadcast del BSF Internet BM-SC servizio, poi, presuppone la trasmissione cifrata del Content contenuto, in modo che questo risulti accessibile ai Server soli utenti autorizzati a riceverlo. Nel caso MBMS, la protezione del contenuto trasmesso merita partiBGW colare attenzione perch deve risultare efficace anche nei confronti di una nuova insidia: la potenziale complicit di un legittimo destinatario e di un utente non autorizzato, ai danni delloperatore. Nel caso MBMS, infatti, un legittimo destinatario BM-SC can reside in home or visited network potrebbe non essere interessato a proteggere la confidenzialit del contenuto che riceve, ma anzi, potrebbe essere interessato allesatto contrario, BGW = Bearer Gateway (first hop IP-router) BM-SC = Broadcast Multicast-Service Center desiderando condividerlo in modo fraudolento con BSF = Bootstrapping Server Function terze parti non autorizzate. La sicurezza MBMS viene garantita a livello applicativo, tra BM-SC e UE. Richiede soltanto la FIGURA 6 Architettura di sicurezza MBMS. connettivit a livello IP e si realizza attraverso larchitettura di sicurezza illustrata in figura 6.
Core Network*: il GTP modificato per consentire la creazione in rete di un unico flusso di dati per Servizio MBMS, e per nodo GSN servente almeno un utente interessato al servizio.
54
Con riferimento alla figura 7, che rappresenta lo schema di principio (semplificato) del GBA, laccesso al servizio fornito dal blocco funzionale NAF (generico e potenzialmente non gestito dalla HPLMN) avviene sullinterfaccia Ua utilizzando il protocollo previsto dallapplicazione. Il concetto di GBA prevede che la sicurezza sullinterfaccia Ua possa essere garantita utilizzando (tra UE e NAF) credenziali calcolate e condivise in precedenza su unaltra interfaccia, la Ub, tra UE e il blocco funzionale BSF (Bootstrapping Server Function), sempre localizzato presso la HPLMN. Il protocollo in uso sullinterfaccia Ub http Digest AKA e sfrutta lalgoritmo di autenticazione 3GPP, elemento prezioso gestito dagli Operatori di telefonia mobile. Le credenziali concordate tra UE e BSF sullinterfaccia Ub sono inviate al NAF (cio al BM-SC, nel caso specifico del servizio MBMS) dal BSF, alloccorrenza e previa verifica della legittimit della richiesta.
Gli aspetti principali del meccanismo in questione sono illustrati nel seguito e riassunti nelle figure 8 e 9.
MIKEY (MUKA, MSK)
MUKA MSK
BM-SC
MIKEY (MUKB, MSK) B MUKB MSK Notation: MIKEY (KEK, KEY) delivers KEY under the protection of KEK using the MIKEY protocol (RFC 3830).
BM-SC = Broadcast Multicast-Service Centre MUK = MBMS User Key MSK = MBMS Service Key
HPLMN
FIGURA 8 Meccanismo (punto-punto) di distribuzione della chiave MSK.
HSS
Zh Zn BSF NAF A BM-SC MIKEY (MSK, MTK) MUKA MUKB MSK MTK
Ub
Ua
MUKA MSK MTK
UE
BSF HPLMN HSS NAF UE
= = = = =
Bootstrapping Server Function Home Public Land Mobile Network Home Subscriber Server Network Application Function User Equipment
MUKB MSK MTK
Notation: MIKEY (KEK, KEY) delivers KEY under the protection of KEK using the MIKEY protocol.
FIGURA 7 GBA: architettura di principio.
BM-SC MUK MSK MTK
= = = =
Broadcast Multicast-Service Centre MBMS User Key MBMS Service Key MBMS Traffic Key
3.2 Protezione del contenuto trasmesso

Il meccanismo di protezione del contenuto MBMS, meccanismo volto a scongiurare/dissuadere i pi disparati scenari di accesso fraudolento1 e, allo stesso tempo, a non precludere alcuno dei charging scheme previsti per il servizio, risulta piuttosto articolato e prevede un triplo livello gerarchico di chiavi: MTK (MBMS Traffic Key), MSK (MBMS Service Key) e MUK (MBMS User Key).
(1)
FIGURA 9 Meccanismo (punto-multipunto) di distribuzione della chiave
MSK.
operati da legittimi destinatari desiderosi di ridurre/contenere i propri costi telefonici, da potenziali intrusi interessati ad accedere al contenuto gratuitamente o a spese altrui e/o da entrambi, che cooperano cospirando ai danni delloperatore.
La restrizione (ai legittimi destinatari) dellaccesso ad un determinato contenuto MBMS avviene utilizzando la crittografia ed una chiave MTK comune a tutti i membri del gruppo. Per evitare accessi non autorizzati al contenuto di cui sopra, la chiave MTK in uso deve essere distribuita a tutti e soli i membri del gruppo in modo sicuro, ossia protetta da eventuali intercettazioni sulla tratta radio. Si osservi tuttavia che la protezione della chiave MTK sulla tratta radio non efficace contro eventuali cessioni a
55
terzi della chiave stessa da parte di un legittimo Bootstrapping Architecture (GBA). Dal destinatario che opera ai danni delloperatore. A momento che la chiave MUK appartiene al causa dei limiti tecnologici delle smartcard, livello gerarchico pi alto, merita la massima infatti, la decifrazione del contenuto MBMS traprotezione possibile, sia per quanto riguarda smesso avviene presso il terminale dutente, la fase di condivisione tra le parti, sia per la che tipicamente non pu considerarsi un memorizzazione presso lo UE. In riferimento a ambiente sicuro e che per svolgere quanto di questo ultimo aspetto, quindi, analogamente a propria competenza deve disporre della chiave quanto previsto per MSK, lato utente la chiave MTK in chiaro. Lo scenario fraudolento di cui MUK deve essere custodita presso la smartsopra, che vede un legittimo destinatario risalire card, se questa MBMS-capable, oppure alla chiave MTK memorizzata sul proprio termipresso unarea opportunamente protetta del nale, non pu essere impedito in assoluto, ma terminale mobile, in caso contrario. pu essere scoraggiato dalloperatore, con una 3.3 Charging sostituzione sufficientemente frequente della chiave stessa. Il meccanismo di tariffazione MBMS (tradizioLa chiave MTK viene generata (e applicata al nale e prepagato) volto a garantire alloperatore contenuto MBMS da trasmettersi) presso il la massima flessibilit in termini di possibili charBM-SC. ging scheme attuabili e tiene conto della presenza La distribuzione della chiave MTK avviene utinel servizio di una componente di contenuto l i z z a n d o i l p ro t o c o l l o M I K E Y ( M u l t i m e d i a MBMS (User Service), accanto ad una di trasporto Internet KEYing), in modalit punto-multipunto. MBMS (Bearer Service), che vengono gestite in Sulla tratta radio, laccesso allinformazione modo indipendente. MTK limitato dal protocollo MIKEY stesso ai Pi in dettaglio, la componente di trasporto soli destinatari che dispongono di una MBMS pu essere tariffata in base alla durata seconda chiave denominata MSK, appartedella sessione, al volume di dati in essa scamnente ad un livello gerarchico superiore e biati, alla durata della permanenza dellutente comune a tutti i legittimi destinatari della allinterno di un determinato gruppo Multicast e/o chiave MTK che protegge. in base ad altri parametri di rete (es. QoS). La Una stessa chiave MSK pu essere utilizzata componente di contenuto MBMS , invece, pu per proteggere la distribuzione di pi chiavi essere tariffata per sottoscrizione, vincolando MTK (ad esempio nel caso di re-keying frelaccesso ad un certo servizio MBMS ad una quente) ed quindi un elemento pi sensibile quota fissa (es. canone mensile) oppure per della MTK. Ne consegue che la MSK, oltre a evento, ossia con un meccanismo di charging pi dover essere distribuita ai legittimi destinatari in raffinato che potrebbe risultare appetibile/ottimale modo sicuro (ossia protetta da eventuali interper determinati servizi. cettazioni sulla tratta radio), lato utente deve Si osservi che, a prescindere dalla componente essere custodita presso la smartcard, se questa MBMS tariffata ( servizio , trasporto o entrambe), MBMS-capable , oppure presso unarea potenzialmente, lentit fisica candidata a sosteopportunamente protetta del terminale mobile, nere le spese di un certo servizio MBMS non in caso contrario. sempre e solo lutente finale (il r e c e iv ing La chiave MSK viene distribuita ai legittimi subscriber ): in alcuni casi, loperatore potrebbe destinatari utilizzando sempre il protocollo decidere di rivalersi anche, o soltanto, sul Content MIKEY, ma in modalit punto-punto, protetta a Provider, come illustrato schematicamente nella sua volta da una terza chiave denominata MUK, tabella 1. user-specific e appartenente ad un ulteriore La tariffazione del contenuto MBMS per evento, livello gerarchico superiore. eventualmente abbinata ad uno o pi degli altri Concettualmente, la chiave MUK potrebbe charging scheme di cui sopra, appare piuttosto anche essere di tipo permanente, tuttavia per plausibile e per questo verr sviluppata ulteriorragioni di backward compatibility (verso USIM mente nel seguito. non MBMS-capable, ad esempio perch di Releases precedenti) e di flessibilit, lo standard 3GPP prevede che possa essere distribuita e sostituita, se necessaService Aspects MBMS Bearer Service used rio. Il meccanismo previMulticast (one or more) Broadcast (one or more) sto per la condivisione User Service (Content) Receiving subscriber Receiving subscriber della chiave MUK, tra Bearer Service (Transport) Content provider and/or receiving subscriber Content provider rete e UE, lo stesso MBMS = Multimedia Broadcast Multicast Service utilizzato per la condivisione delle credenziali p re v i s t e d a l m e c c a n i smo di autenticazione TABELLA 1 Charging MBMS. MBMS: la Generic
56
In generale, la tariffazione equa ed affidabile dei servizi un aspetto molto importante per un operatore. Per questo, in fase di specifica, 3GPP si adoperato per raggiungere questo obiettivo al meglio, nel limite del possibile, ossia tenendo anche conto di possibili scenari fraudolenti. In una prima fase, 3GPP pensava di basare levent charging sul delivery verification, ossia su un riscontro esplicito (da parte dellutente) dellavvenuta ricezione del contenuto (o della chiave master MSK utile a decifrarlo). In seguito, per, tale scelta stata accantonata a causa dello scenario fraudolento che avrebbe certamente alimentato, chiaramente volto a precludere linvio alla rete (da parte del UE) di tale riscontro. Il principio verso cui 3GPP si dunque orientato ai fini del charging per evento presuppone che in condizioni ordinarie un legittimo destinatario di un certo evento MBMS (cio che ha sottoscritto un certo servizio MBMS e ha manifestato esplicito interesse per levento specifico) riceva la chiave MSK necessaria per decifrare la chiave MTK e quindi il contenuto e che, in caso di failure , per qualsivoglia motivo, possa comunque inoltrare e reiterare la richiesta della chiave di cui sopra alla rete, fino a riceverla. Questo principio garantisce un charging ritenuto ragionevolmente affidabile ed equo nei confronti del cliente finale e, allo stesso tempo, tutela loperatore da scenari fraudolenti che, altrimenti, rischierebbero di compromettere la redditivit del servizio. La tariffazione MBMS per evento si basa dunque sul meccanismo di (ri)distribuzione delle chiavi di sicurezza, ed in particolare sulla (ri)distribuzione della chiave MSK, che si assume sufficientemente affidabile da non richiedere riscontri espliciti da parte dellutente finale. Ne consegue che ogni singolo evento MBMS deve essere protetto con una propria chiave MSK, nuova. Alla luce del fatto che la (ri)distribuzione della chiave MSK avviene in modalit punto-punto e che, pertanto, potrebbe risultare onerosa in caso di eventi MBMS di grande richiamo, tale scelta non risulta forse perfetta, ma il risultato di un compromesso, volto a garantire un charging equo ed affidabile da un lato e a tutelare la sicurezza del servizio dallaltro.
4.1 Codifica di sorgente

Per quanto riguarda i codec audio-video da usare per MBMS, essi sono stati selezionati omogeneamente rispetto a quelli gi specificati per altri servizi 3G quali MMS e PSS, al fine di limitare la proliferazione degli standard e di minimizzare i problemi legati allinteroperabilit di standard diversi. I codec audio per MBMS possono consistere in uno o pi fra i seguenti: AMR Narrow Band; AMR Wide Band; Extended AMR Wide Band; Enhanced aacPlus. Come codificatori video sono invece, previsti: H.264/AVC Baseline Profile; ITU-T H.263. Per aiutare loperatore mobile nel non sempre facile compito di scegliere un codec adatto al servizio che intende offrire, le specifiche tecniche 3GPP mettono a disposizione delle linee guida per stabilire quale codec usare in funzione delle caratteristiche del servizio offerto (tipologia di contenuti, banda disponibile, modalit di delivery, ...). A titolo di esempio, le linee guida fornite relativamente ai codificatori audio Enhanced aacPlus ed Extended AMR WideBand per servizio MBMS, possono essere cos sintetizzate: Extended AMR WideBand offre prestazioni migliori a velocit medio-basse (inferiori a 24 kbit/s) e con contenuti solo vocali o intervallati con musica; Enhanced aacPlus, invece, offre prestazioni migliori a velocit tendenzialmente pi alte e con contenuti prevalentemente musicali. Oltre allaudio ed il video, i seguenti tipi di media possono essere usati in un servizio MBMS: Synthetic audio; Still images; Bitmap graphics; Vector graphics; Text; Timed text. Anche se i codificatori di sorgente offrono intrinsecamente la capacit di mitigare gli errori di canale, il livello di protezione necessario si raggiunge con luso di FEC a livello applicativo. Inoltre, nel caso particolare di download, previsto il meccanismo addizionale del file repair in modalit Po in t-to - Point (P-t-P) repair e Po int -t o Multipoint (P-t-M) repair.
4. Livello applicativo: codec e protocolli

Uno degli aspetti cruciali per assicurare unalta QoS allutente di un servizio MBMS luso di adeguati codec audio-video e meccanismi di protezione dagli errori introdotti dai canali di trasmissioni quali appunto i FEC (Forward Error Correction). Limportanza di tali meccanismi di protezione legata alle caratteristiche della trasmissione punto-multipunto, dove non possibile utilizzare tutte le usuali tecniche radio (come le ritrasmissioni in caso di ricezione di pacchetti errati) per mitigare gli errori del canale. Pertanto, per compensare tale perdita di prestazioni, stato necessario specificare degli appositi meccanismi di protezione.
4.2 Meccanismi di repair

Lo scopo dei meccanismi di file repair quello di chiedere la ritrasmissione dei frammenti di dati persi o corrotti, dopo la fine della sessione di download. Una delle peculiarit di un servizio MBMS che pu essere offerto massivamente in un intervallo temporale anche molto limitato ponendo dei problemi di scalabilit per i meccanismi di repair. La soluzione inserita nello standard si basa su una randomizzazione temporale e spaziale delle richieste di repair al fine di evitare il fenomeno
57
della feedback implosion, cio un grande numero di client MBMS che richiedono simultaneamente il file repair. La figura 10 mostra schematicamente il caso di P-t-P file repair. Se il client MBMS non ha ricevuto correttamente tutti i dati necessari a ricostruire il file, inizia la procedura di file repair selezionando da una lista precedentemente ricevuta il server di repair. Il client invia una o pi richieste di repair a questo server che risponde tipicamente con i dati richiesti. Una singola sessione TCP con protoc ol l o H TTP vi en e u sata p er tu tte le richieste/risposte di repair provenienti da un determinato client.
4.3 Schema FEC

Sia per MBMS downloading che streaming stata individuata la possibilit di usare un FEC a livello applicativo. In questo modo possibile ottenere il desiderato livello di tasso di errore senza appesantire la parte radio con un meccanismo equivalente di protezione. Infatti, i livelli di protezione offerti dal FEC saranno configurabili come minimo su base sessione. Tuttavia, luso del FEC inteso come opzionale per loperatore (service provider), che pu anche decidere di usare lopzione senza FEC. Tra le varie famiglie di FEC proposte per MBMS (Low Density Parity Check, Reed Solomon e Raptor Codes) i Raptor Codes sono stati selezionati per MBMS downloading e streaming, considerando che in entrambi i casi tali codici offrono delle prestazioni generalmente comparabili o migliori rispetto alle altre famiglie di FEC proposte.
Client MBMS
Repair Server(s)
Download Server(s)
Sessione PtM originaria Richiesta(e) di repair PtP Risposta(e) di PtP repair
4.4 Protocolli per il trasporto dei media

A seconda della tipologia di delivery del servizio MBMS (download o streaming) i media saranno trasportati al client secondo due stack protocollari diversi. Nel caso di download previsto il protocollo FLUTE per il trasporto di oggetti (file). Nel caso di streaming sar invece usato il protocollo RTP (o SRTP nel caso di trasporto sicuro) per inviare dati in tempo reale su UDP. Questa soluzione permette di soddisfare gli specifici requisiti di servizio definiti allinterno del 3GPP e al tempo stesso massimizzare la comunanza con i protocolli IETF (protocolli FLUTE e RTP), come gi fatto per il servizio PSS.
MBMS = Multimedia Broadcast Multicast Service PtM = Point to Multipoint PtP = Point to Point
FIGURA 10 Meccanismo di PtP file repair.
Nel caso in cui molti client MBMS richiedano lo stesso frammento di dati risulta pi vantaggioso usare un meccanismo di P-t-M repair. In questo caso, come mostrato in figura 11, il server di repair risponde con un messaggio di HTTP redirection indicando che i dati di repair sono disponibili tramite un URI diverso. Il client effettua il joining alla nuova sessione MBMS e aspetta linizio della trasmissione dei dati di repair.
5. Accesso radio MBMS in GERAN

La descrizione dellaccesso radio MBMS in GERAN fa riferimento allutilizzo dellinterfaccia Gb tra il BSS e lSGSN 2G relativo alla Core Network GSM, su cui si completamente focalizzata lattivit di standardizzazione in ambito GERAN.
Client MBMS
Repair Server(s)
Download Server(s)
5.1 Notifica ai terminali dellinizio di una sessione MBMS in una cella

A seguito della ricezione di un messaggio di MBMS SESSION START REQUEST proveniente dallSGSN, il BSS pu inviare ai terminali in packet idle mode una pre-notifica dellinizio di una sessione nellambito di un servizio MBMS, specificando lidentificativo del servizio stesso e, se disponibile, lidentificativo della sessione nellambito del servizio. Nel caso di un servizio broadcast per il quale ne richiesta la ricezione o nel caso di un servizio multicast per il quale lutente ha precedentemente effettuato la procedura di joining, il terminale attende la ricezione della notifica dellinizio di una sessione (che non sia gi stata ricevuta) proveniente dalla rete. La rete invia la notifica dellinizio della sessione in tutte le celle appartenenti
Sessione PtM originaria Richiesta(e) di repair PtP Risposta(e) di PtP repair (redirect) Sessione PtM repair decisione: uso PtM
MBMS = Multimedia Broadcast Multicast Service PtM = Point to Multipoint PtP = Point to Point
FIGURA 11 Meccanismo di PtM file repair.
58
alla MBMS Service Area pertinente al servizio di cui essa fa parte. La notifica pu includere la richiesta di counting dei terminali, procedura che consente alla rete di valutare il numero dei terminali che richiedono di ricevere una specifica sessione nellambito della cella. La valutazione effettuata sulla base dellinvio, da parte dei mobili interessati, di una richiesta della sessione in risposta alla notifica proveniente dalla rete. La valutazione del numero di terminali, che richiedono la ricezione di una specifica sessione nellambito della cella, consente alla rete di ottimizzare la modalit di trasmissione dei dati relativi a quella sessione nellambito della cella. Nel caso in cui la procedura di counting non sia richiesta dalla rete, la notifica pu includere direttamente lassegnazione delle risorse radio per la sessione notificata, specificando in particolare i canali radio su cui sar inviata la sessione e lidentificativo radio della sessione stessa. La decisione da parte del BSS di allocare o meno risorse radio in una cella per la sessione, ed in caso affermativo sul numero di risorse radio da allocare, dipende dalla implementazione e deve essere presa tenendo conto dei valori del campo informativo Allocation/Retention Priority (ARP), qualora esso sia incluso nel messaggio MBMS SESSION START REQUEST ed il BSS sia in grado di gestire questo campo, e sulla base delle risorse radio disponibili nella cella. Tale campo consente di specificare il livello di priorit della sessione, se essa pu o meno scatenare la procedura di preemption di servizi nel dominio PS che siano a pi bassa priorit nella cella e che possano essere oggetto di pre-emption, e se pu essere a sua volta oggetto di pre-emption da parte di servizi a pi alta priorit nella cella. Nel caso in cui sia presente lidentificativo della sessione nel messaggio proveniente dallSGSN, sar presente anche il numero di ripetizione della sessione stessa, per consentire al BSS di sapere se si tratta della prima trasmissione della sessione o di una sua ripetizione, ed in questo caso del numero della ripetizione della stessa. Anche questo campo informativo pu essere utilizzato dal BSS, ad esempio per decidere se effettuare o meno la procedura di counting nella cella oppure in congiunzione con lARP (se disponibile) per decidere se allocare o meno risorse radio nella cella per la trasmissione della sessione.
5.2 Modalit di trasmissione a livello radio

Se il numero di mobili MBMS coinvolti nella ricezione di una specifica sessione nellambito di una cella non superiore a 16, possibile che la rete instauri una modalit di trasmissione riscontrata a livello radio nella cella: ad ogni terminale potr essere richiesto da parte della rete linvio di riscontri sulle unit informative (blocchi radio) ricevute corrette e su quelle errate, al fine di consentire alla rete di decidere se e quali blocchi radio ritrasmettere. Lalgoritmo di ritrasmissione dei blocchi radio non specificato e dipende dalle implementazioni di rete. Il protocollo di ritrasmissione non
comunque quello riscontrato ed esaustivo (con la ritrasmissione di tutti i blocchi radio indicati come errati dalla parte ricevente) e neppure quello non riscontrato (che non prevede alcuna ritrasmissione), gi specificati per i servizi punto-punto. Per lMBMS stata introdotta una terza modalit del protocollo RLC, denominata non persistente (in quanto le ritrasmissioni sono effettuate dalla rete, ma non necessariamente per tutti i blocchi radio indicati come errati da parte dei terminali coinvolti nella ricezione della sessione, ed il protocollo non richiede che tutti i blocchi radio siano correttamente ricevuti lato mobile). Il protocollo non persistente a livello RLC si applica anche nel caso in cui la modalit di trasmissione non sia riscontrata a livello radio. Anche in questo caso lalgoritmo di ritrasmissione dei blocchi radio non specificato e dipende dalle implementazioni di rete, ma non si pu comunque avvalere delle informazioni che sono rese disponibili dai riscontri inviati nella modalit precedentemente descritta. Il numero di utenti per sessione nella cella che discrimina le due modalit di trasmissione 16, in quanto questo il massimo numero di terminali a cui possibile aggiornare periodicamente, su una risorsa radio, tramite la procedura GPRS di continuous timing advance update linformazione di timing advance, che consente di allineare la base tempi del mobile con quella della stazione radio base, in funzione della loro distanza. Senza questo aggior namento periodico, ad un terminale GPRS/EGPRS non consentito trasmettere un blocco radio (e quindi neppure un riscontro come descritto precedentemente), in quanto il conseguente disallineamento della base tempi del mobile rispetto a quella della stazione radio base potrebbe comportare la parziale ricezione dei normal burst (unit informative di livello 1) costituenti un blocco radio (unit informativa di livello 2), da parte della stazione radio base, su uno dei time slot adiacenti a quello previsto per quel terminale, con conseguente collisione con i normal burst provenienti da altri mobili. Indipendentemente dalla modalit di trasmissione utilizzata tra le due precedentemente descritte, un terminale che riceva una o pi sessioni MBMS si trova nello stato di broadcast/multicast receive mode, che visto come un sotto-stato del packet idle mode, ed al terminale non possibile essere contemporaneamente coinvolto in una connessione a circuito e/o in una o pi sessioni a pacchetto di tipo punto-punto. Anche ai mobili coinvolti in una connessione a circuito o in una o pi sessioni a pacchetto di tipo punto-punto o in DTM comunque possibile ricevere la notifica dellinizio di una sessione MBMS da parte della rete. Tuttavia, affinch un terminale MBMS possa ricevere la sessione notificata, deve prima rientrare in packet idle mode, dopo aver rilasciato la connessione a circuito e/o la(e) sessione(i) a pacchetto di tipo punto-punto in cui era precedentemente coinvolto, e quindi entrare in broadcast/multicast receive mode.
59
5.3 Assegnazione delle risorse radio

Una volta che la rete ha effettuato il counting dei terminali (se cos richiesto nella notifica dellinizio della sessione), essa invia lassegnazione delle risorse ai mobili, nel caso in cui sia allocato un MBMS radio bearer per quella sessione, specificando in particolare i canali radio su cui sar inviata la sessione e lidentificativo radio della sessione stessa. La rete pu anche notificare ai terminali la mancata allocazione di risorse radio per quella sessione. Sulle stesse risorse radio possibile multiplare pi sessioni MBMS e sessioni punto-punto GPRS e/o EGPRS, ognuna di esse discriminata tramite un identificativo radio (quello gi specificato a partire dalla R97 per le sessioni punto-punto ed il nuovo identificativo introdotto per lMBMS, che riutilizza in tutto o in parte il campo destinato allidentificativo radio di una sessione punto-punto). Se la modalit di trasmissione quella riscontrata a livello radio, la rete assegna anche il canale radio su cui i mobili trasmettono i riscontri; essa assegna inoltre un identificativo specifico ad ogni terminale, valido nellambito di quella specifica sessione in quella cella, tramite il quale la rete richiede al terminale linvio di riscontri sui blocchi radio ricevuti corretti e su quelli errati. Il massimo numero di canali radio che possono essere assegnati allinterno di una trama TDMA per linvio di una sessione MBMS pari a 4, numero che pu salire a 5, come eccezione, solo nel caso in cui il PBCCH sia allocato nella cella, si abbia un solo PCCCH allocato nella cella, ed il canale radio su cui sono mappati sia il PBCCH che il PCCCH contiguo agli altri canali radio allocati allMBMS radio bearer relativo a quella sessione ed utilizza gli stessi parametri di frequenza. Nel caso di modalit riscontrata a livello radio anche allocato un canale in uplink. Il terminale MBMS deve essere in grado di ricevere fino a 5 canali radio (allocati in
una finestra la cui dimensione massima 6), di trasmettere al pi su 2, e la somma dei canali su cui riceve e trasmette non deve essere comunque superiore a 6, su base trama TDMA. Tra i canali radio ricevuti in downlink occorre includere anche quello su cui sono mappati i canali di controllo broadcast e comune, che devono essere comunque monitorati da un terminale durante la ricezione di una o pi sessioni MBMS, in quanto, come detto precedentemente, un tale terminale si trova in broadcast/multicast receive mode, un sotto-stato del packet idle mode. Nelle figure 12, 13, 14, 15 sono riportate le massime allocazioni di risorse radio per un MBMS radio bearer nei casi specificati. I due canali in uplink possono essere utilizzati nel caso di ricezione di sessioni MBMS multiple in modalit riscontrata a livello radio, per linvio dei rispettivi riscontri. I blocchi radio relativi alla sessione MBMS sono trasmessi sulle risorse assegnate utilizzando gli schemi di (modulazione e) codifica gi specificati per il GPRS e per lEGPRS, senza introdurre nuovi schemi di codifica specifici dellMBMS. Come accennato precedentemente, un terminale pu ricevere pi sessioni MBMS contemporaneamente, purch lallocazione delle risorse radio per le diverse sessioni sia compatibile con le radio access capabilities del terminale (p. es. il numero di canali radio che il terminale in grado di gestire contemporaneamente). Nel caso in cui ci non sia possibile, occorre che il mobile determini quali sessioni ricevere e quali scartare: a tal fine, nel terminale associata una priorit per ogni servizio sottoscritto dallutente.
5.4 Gestione della mobilit

Al fine di minimizzare le interruzioni del servizio dovute alla riselezione di cella, stato introdotto un meccanismo, denominato Fast Reception
DL UL
0 5
1 6
2 7
3 0
4 1
5 2
6 3
7 4
DL UL
0 5
1 6
2 7
3 0
4 1
5 2
6 3
7 4
DL = DownLink UL = UpLink
FIGURA 12 MBMS radio bearer senza canale di riscontro e senza PBCCH.
FIGURA 14 MBMS radio bearer con canale di riscontro e senza PBCCH.
DL UL
0 5
1 6
2 7
3 0
4 1
5 2
6 3
7 4
DL UL
0 5
1 6
2 7
3 0
4 1
5 2
6 3
7 4
FIGURA 13 MBMS radio bearer senza canale di riscontro e con PBCCH.
FIGURA 15 MBMS radio bearer con canale di riscontro e con PBCCH.
60
Resumption, in base al quale un terminale riceve nella cella servente (prima di effettuare la riselezione di cella) le informazioni, relative alla sessione che sta ricevendo, che si riferiscono alle celle adiacenti in cui trasmessa la stessa sessione: le informazioni includono, in particolare, lidentificativo radio della sessione e lallocazione dei canali radio nelle celle adiacenti in cui la stessa sessione trasmessa. Se il terminale effettua una riselezione di cella verso una cella target per la quale ha ricevuto nella cella servente le informazioni relative alla sessione che sta ricevendo, in grado di ripristinare immediatamente la ricezione della sessione (ed acquisire contemporaneamente le informazioni di sistema sul canale di controllo broadcast); altrimenti, deve prima acquisire le informazioni di sistema nella cella target e successivamente effettuare una procedura di accesso per richiedere la sessione nella cella target. stata introdotta unulteriore ottimizzazione che consente, come scelta implementativa, di gestire lato rete la priorit con cui vengono inviate nella cella servente le informazioni relative alla stessa sessione nelle celle adiacenti: la rete pu inviare prioritariamente le informazioni relative ad una sessione per quelle celle adiacenti che sono state indicate nei riscontri inviati dai terminali come le migliori candidate ai fini di una riselezione di cella o verso le quali sono state gi decise delle riselezioni di cella. Sempre come scelta implementativa, nelle suddette celle adiacenti la rete pu instaurare un MBMS radio bearer relativo alla sessione, qualora non sia gi presente, ed inviarne infomazione nella cella servente, per consentire ai terminali di utilizzare la procedura di Fast Reception Resumption.
5.5 Valori di throughput ottenibili a livello radio

I valori di throughput attesi a livello radio non sono univocamente definibili e dipendono da diversi fattori quali: lutilizzo del GPRS o dellEGPRS; lo schema di (modulazione e) codifica adottato; il numero di canali radio allocati per la sessione; il numero di ulteriori sessioni MBMS e/o sessioni punto-punto multiplate sulle stesse risorse radio allocate alla sessione; la modalit di trasmissione adottata (riscontrata a livello radio o meno); il numero di utenti coinvolti nella ricezione della sessione nel caso di trasmissione riscontrata a livello radio; le modalit di ritrasmissione dei blocchi radio; le condizioni radio nella cella (sia in termini di livello di segnale ricevuto dal terminale che di rapporto segnale/interferente co-canale e da canale adiacente); il modello di mobilit del terminale; la possibilit o meno di effettuare la procedura di Fast Reception Resumption in corrispondenza di una riselezione di cella; leventuale riassegnazione di risorse radio per la
sessione nella cella con leventuale possibilit di pre-emption da parte di servizi a pi alta priorit nella cella. Le diverse variabili rappresentano altrettanti gradi di libert e consentono alla rete di selezionare per una specifica sessione la combinazione pi appropriata a seconda della cella considerata, al fine di tentare di ottenere, a livello di implementazione lato rete, una sorta di loose synchronisation dei contenuti MBMS attraverso le diverse celle che costituiscono MBMS Service Area: lobiettivo quello di tentare di raggiungere il miglior sincronismo possibile nellinvio dei contenuti MBMS tra le diverse celle, al fine di massimizzare la probabilit di fruizione, da parte degli utenti, di un servizio senza soluzione di continuit in corrispondenza dei cambi cella (a tal fine, la procedura di Fast Reception Resumption minimizza i tempi di interruzione del servizio in corrispondenza di un cambio cella, ma occorre altres garantire che linvio dei contenuti nella cella servente e nella cella target sia il pi possibile sincrono per minimizzare le discontinuit nella ricezione del servizio). A titolo puramente esemplificativo delle prestazioni di throughput attese, nel caso della modalit di trasmissione non riscontrata a livello radio, utilizzando il GPRS con lo schema di codifica CS-3 e assumendo che la rete effettui due ripetizioni (ovvero la prima trasmissione ed una ritrasmissione) per ogni blocco radio, su quattro canali radio si raggiunge un throughput di livello 2 (RLC/MAC) pari a 28,8 kbit/s (assumendo che non vi siano altre sessioni MBMS o punto-punto multiplate sulle stesse risorse radio, che due ripetizioni siano sufficienti per ricevere correttamente tutti i blocchi radio e non vi siano n interruzioni nella fruizione del servizio derivanti da riselezioni di cella, n riassegnazioni delle risorse radio allocate con conseguente variazioni del throughput); utilizzando lEGPRS con MCS-6 e d u e r i p e t i z i o n i , i l t h ro u g h p u t d i l i v e l l o 2 (RLC/MAC) raggiungibile a parit di condizioni pari a 59,2 kbit/s. Pertanto, in prima approssimazione, si pu stimare una distribuzione dei valori di throughput di livello 2 per MBMS in GERAN verosimilmente concentrata, anche se comunque non confinata, tra 30 kbit/s e 60 kbit/s.
6. Accesso radio UTRAN

Il supporto di servizi MBMS in una rete di accesso UTRAN ha comportato una serie di modifiche sostanziali nel modo di progettare e pianificare il sistema. Infatti laccesso UTRAN, originariamente progettato ed ottimizzato per i servizi PTP, per di pi basato su uno schema di accesso radio quale il WCDMA che dispone di una serie di tecniche (link adaptation, ritrasmissioni, controllo di potenza veloce e macrodiversit) che poco si prestano ad essere utilizzate in modo efficiente per canali condivisi da pi utenti simultaneamente.
61
6.1 Bearer radio MBMS

Come schema di principio, i dati dutente relativi al servizio MBMS vengono distribuiti su un Radio Bearer che si basa un canale logico MTCH (MBMS Traffic Channel) condiviso da pi utenti, il quale viene tipicamente mappato su un canale di trasporto comune di tipo FACH (figura 16).
UE UTRAN
1 Notification for session start
2 MBMS RB (MTCH, DTCH) establishment

MCCHSAP MTCHSAP MAC SAPs
3 MBMS data transfer
FACH FACH MCCH MTCH SAP = = = =
Transport Channel DTCH MBMS MTCH RB UE UTRAN = = = = = = Dedicated Traffic CHannel Multimedia Broadcast Multicast Service MBMS Traffic CHannel Radio Bearer User Equipment UMTS Terrestrial Radio Access Network
Forward Access CHannel MBMS Control CHannel MBMS Traffic CHannel Service Access Point
FIGURA 16 Mappatura tra canali logici e canali di trasporto per MBMS
lato rete e UE.
FIGURA 18 Sequenza procedure nei casi di session start.
La ricezione da parte dei terminali del flusso dati dutente trasportato sul MTCH regolata da informazioni di controllo (figura 17) inviate periodicamente sul canale MCCH (MBMS Control Channel) della cella sulla quale il mobile accampato. Il terminale cha ha sottoscritto i servizi MBMS, riceve sul canale MCCH: lelenco e lo scheduling temporale dei servizi trasmessi (MBMS Service Information); la configurazione radio dei vari Radio Bearer MBMS usati (Radio Bearer Information). Per rendere pi efficiente luso delle batterie, il terminale pu sospendere la ricezione del MCCH qualora le informazioni non varino per lunghi periodi, pertanto tali variazioni possono avvenire soltanto in periodi ben prefissati (Modification Period), la cui durata pu comunque essere configurata in rete.
Modification period
Modification period
MCCH
Repetition period
Change information MCCH = MBMS Control CHannel
FIGURA 17 Scheduling delle informazioni di controllo MCCH.
Allatto della ricezione di un MBMS SESSION START (figura 18) da parte dellSGSN, lRNC, predispone le risorse radio e di rete per il setup di un Radio Bearer MBMS e successivamente notifica ai terminali la variazione delle informazioni sul MCCH mediante MBMS Change information (che costituisce la cosiddetta procedura di Notification). Quando la sessione MBMS relativa ad un certo servizio terminata (SESSION STOP) le informazioni di scheduling sul MCCH vengono modificate, oppure, se non ci sono pi servizi MBMS, viene completamente interrotta la trasmissione del MCCH. La ricezione MBMS sopra descritta pu avvenire sia quando il terminale in Connected Mode, cio quando ha una connessione RRC attiva, sia in Idle Mode. Questa seconda opzione da preferirsi quando ad un certo servizio MBMS iscritto un n u m e ro m o l t o e l e v a t o d i utenti (mediante procedura di Counting), il che comport e re b b e l a t t i v a z i o n e d i diversi contesti RRC nelLRNC. In questo caso la rete pu decidere di tenere la maggior parte dei terminali in Idle Mode. ovvio che ci possibile solo per i terminali che hanno solo servizi MBMS attivi, cio non hanno la necessit di una connessione RRC per altri servizi PTP (si veda il paragrafo 6.5).
62
6.2 P-t-M/P-t-P switching e Counting

Luso dei canali PTM comporta un certo impiego di risorse radio, pi alto di quanto non richiedano invece pochi canali PTP (ad esempio canali dedicati DCH oppure HSDPA). Pertanto previsto nello standard che un Radio Bearer MBMS possa essere configurato in modalit radio PTP, utilizzando canali di trasporto DCH oppure HS-DSCH (High Speed - Downlink Shared CHannel) per HSDPA. Questa possibilit di selezionare dinamicamente i tipi di canale si applica soltanto al Radio Bearer, cio lRNC decide la tipologia di canale di trasporto mentre lIu bearer tra RNC e SGSN rimane invariata. Come detto, lutilizzo di uno a pi canali PTP giustificato solo al di sotto di un certo numero di terminali presenti nella cella, per cui necessario conoscere con un certo grado di approssimazione tale numero. Questa informazione non disponibile allRNC quando i terminali sono in idle mode ma pu essere ottenuta tramite la procedura di Counting. Data la finalit sopra descritta, la procedura di Counting non serve tanto a conoscere il numero esatto di terminali nella cella che hanno richiesto un dato servizio, quanto piuttosto per sapere se tale numero superiore alla soglia per la quale viene attivato un canale condiviso. Perci il counting fatto su base statistica e alla procedura di counting viene associato un probability factor con il quale il terminale deve rispondere con segnalazione verso la rete e passare quindi in stato RRC connected. In base alla stima del numero di terminali nella cella e al fine di proteggere i canali di accesso (RACH) da un picco di risposta al counting, la rete pu partire con un probability factor abbastanza basso ed eventualmente innalzarlo in procedure successive di counting finch non si ottiene un numero statisticamente significativo di risposte. Qualora il canale configurato sia il PTM, la rete pu periodicamente eseguire un counting per verificare se durante la sessione il numero di utenti per cella non sia ritornato, causa mobilit o per abbandono del servizio, sotto la soglia di attivazione del canale PTP.
Per la trasmissione MBMS, quando questa avviene su canali comuni, sul canale logico FACH trasmesso sul canale fisico S-CCPCH (Secondary Common Control Physical CHannel), stato pertanto necessario compensare almeno in parte la perdita di capacit aumentando lefficienza di trasmissione a bordo cella, mediante lintroduzione di tecniche di macrodiversit simili a quelle utilizzate per i canali dedicati DCH. Per MBMS la rete trasmette simultaneamente su tutte le celle di una certa area e i terminali che si trovano nella regione di bordo combinano spontaneamente il segnale preveniente da due o pi celle realizzando cos il cosiddetto guadagno di macrodiversit. Esistono due diverse tecniche di Combining: Selection combining: il terminale attiva due o pi catene di ricezione e di decodifica, una per ogni cella, e successivamente seleziona il pacchetto dati corretto da trasmettere allapplicazione; Soft combining: il terminale combina i segnali a livello fisico, riuscendo quindi a massimizzare il rapporto segnale/rumore, e poi effettua un solo processo di decodifica del pacchetto dati. Un'altra sostanziale differenza, rispetto ai canali DCH, data dalluso di un tempo di interleaving (TTI - Transmission Timing Interval) pi alto, pari a 40 o 80 ms, superiore rispetto ai normali 10 o 20 ms utilizzato per la trasmissione dati in Rel-99. Per dare unidea della capacit di sistema per servizi MBMS, con e senza Combining, nella tabella 2 indicata la percentuale di potenza di cella da riservare per un canale MTCH/S-CCPCH a 64 kbit/s, nel caso di un bearer con qualit del servizio di tipo streaming (avente una BLER BLock Error Rate target pari all1%). I valori riportati sono
TTI
No Com (1 RL)
SC (2 RL)
SC (3 RL)
Ambiente Indoor 40 ms 80 ms - (*) 61.7% 21.4% 17.8% 14.8% 13.2%
6.3 Livello fisico e prestazioni di sistema

Come accennato in precedenza, linterfaccia radio dei sistemi radiomobili e in particolare quella della dellaccesso UTRAN, si basa su meccanismi di adattamento al canale radio (link adaptation) quali Power Control e Adaptive Modulation and Coding (AMC) che sono efficaci per collegamenti punto-punto, in quanto le condizioni del canale variano per ogni singolo terminale. Lutilizzo di canali comuni, pertanto, determina un uso disottimizzato delle risorse radio, e genera pertanto un decremento di capacit, tanto maggiore quanto pi grande il bit-rate di riferimento target da garantire a bordo cella.
Ambiente Outdoor 40 ms 80 ms 28.8% 22.4% 12.0% 11.2% 10.2% 9.8%
* potenza di cella non sufficiente a fornire copertura a bordo cella. RL = Radio Link SC = Selective Combining TTI = Transmission Timing Interval
TABELLA 2 Percentuale di potenza della cella necessaria per un canale
MBMS streaming a 64 kbit/s al 95% della copertura in caso di Selective Combining.
63
stati ottenuti in uno scenario di simulazione macrocellulare, considerando due diversi modelli di propagazione/mobilit, assimilabili a condizioni indoor e outdoor. In caso di radio bearer a bit rate pi elevata per MBMS si pu approssimativamente assumere che la potenza di cella necessaria cresca linearmente con lincremento di bit rate e quindi, per un servizio streaming a 128 kbit/s, sufficiente raddoppiare le percentuali di potenza utilizzata riportate nelle tabelle 2 e 3. Da notare comunque che il bit rate massimo supportato da un mobile MBMS 384 kbit/s, limite dettato dalle dimensioni della memoria e dalla capacit di processamento del terminale stesso.
renti, il terminale segue un criterio di priorit secondo le indicazioni dellutente o dellapplicazione. Alla fine della sessione, tuttavia, i terminali resterebbero concentrati nel layer MBMS e questo potrebbe creare problemi di sovraccarico in caso di generazione del normale traffico punto-punto, per il quale molto probabilmente il layer non dimensionato. Per questo motivo esiste il processo contrario detto Frequency Layer Dispersion per il quale il terminale riseleziona una cella diversa da quella sulla quale accampato alla fine della sessione MBMS. Entrambe le procedure di cell reselection sono controllate dalla rete che indica sia il layer per MBMS sia quello di ritorno attraverso i canali di controllo.
6.5 UE radio access capability

Come descritto in precedenza, le operazioni di livello fisico del terminale per processare il segnale MBMS richiedono un sostanziale incremento di memoria e capacit di processing rispetto ai terminali di Release UMTS precedente, necessit dovuta principalmente allimpiego di un TTI pi lungo e al numero di radio link da processare contemporaneamente a bordo cella in caso di Combining. I mobili MBMS pertanto risultano comparabili, in termini di complessit tecnologica, a terminali HSDPA di classe 3,6 Mbit/s, per un bit rate massimo di servizio che invece raggiunge i 384 kbit/s. Si osservi che per MBMS lo standard non prevede lesistenza di classi diverse di terminali, il che evita di dover segregare le risorse di rete per le diverse tipologie di terminali e quindi ridurre in parte il beneficio delluso di canali comuni. Altro aspetto da tenere in considerazione il supporto simultaneo di servizi MBMS (su canali SCCPCH) e servizi PTP (su DCH). Per questa combinazione, lo standard non stabilisce una capability minima che il terminale deve obbligatoriamente supportare e pertanto il supporto simultaneo di questo tipo di servizi opzionale nel terminale. Nel caso in cui il terminale non avesse questa caratteristica, la fruizione dei servizi potrebbe essere limitata. Ad esempio se mentre lutente impegnato in una sessione MBMS arriva una chiamata voce oppure lutente attiva una connessione dati, necessario rilasciare la connessione MBMS per eventualmente riattivarla alla fine della chiamata punto-punto.
TTI TTI
No Com (1 RL) 22.4%
SFC (2 RL) 7.6%
SFC (3 RL) 4.8%
RL = Radio Link SFC = SoFt Combining TTI = Transmission Timing Interval
TABELLA 3 Percentuale di potenza della cella necessaria per un canale
MBMS streaming a 64 kbit/s al 95% della copertura in caso di Soft Combining (ambiente outdoor).
Come limite massimo, puramente indicativo, di capacit di sistema per MBMS, supponendo di voler riservare circa l80% della potenza di portante UMTS ai soli servizi MBMS (circa il 15-20% necessario per i canali comuni di segnalazione Rel99) si pu affermare che possibile attivare circa 16 canali MBMS a 64 kbit/s.
6.4 Mobility e Frequency Layer Convergence

La trasmissione di contenuto MBMS, una volta superato il numero minimo di utenti per cella per cui diventa giustificabile luso di canali PTM, richiede lo stesso impiego di risorse indipendentemente dal traffico. In caso di coperture multilayer, pertanto, la possibilit di concentrare tutti gli utenti MBMS in unico layer non solo non comporta particolari problemi di sovraccarico per i canali MBMS, ma anzi da perseguire in quanto evita la trasmissione MBMS su tutti i layer di celle. Per poter effettuare questo tipo di strategie stato introdotto un meccanismo di Frequency Layer Convergence, per il quale il terminale, al momento dellinizio della sessione oppure durante il cambio cella a causa della mobilit, seleziona la cella che distribuisce il servizio o i servizi ai quali lutente interessato. In caso di conflitto dovuto alla trasmissione contemporanea di due o pi servizi su layer diffe-
7. Conclusioni
Nel corso dellarticolo si presentato lo standard 3GPP relativo ad MBMS e si potuto familiarizzare con le modifiche necessarie allarchitettura della rete radiomobile per poter offrire servizi punto multipunto. A parte il nuovo nodo, BM-SC (Broadcast Multicast - Service Centre), per gli altri elementi della rete radiomobile (BSC/RNC, SGSN e GGSN) per il pieno supporto di MBMS necessario un aggiornamento del software.
64
Come si avuto modo di osservare, se con MBMS possibile offrire servizi di tipo mobile-TV, ma a basso bit rate e con un numero di canali TV molto ridotto, tale tecnologia risulta pi attraente per servire gruppi di utenti con applicazioni di tipo download & play o di messaggistica di varia natura. MBMS non quindi assolutamente alternativo al DVB-H, tecnologia principe per poter offrire la televisione sul cellulare, anzi ad esso complementare. Il successo o meno di MBMS sul mercato dipender fondamentalmente da quanti terminali di Release 6 3GPP con MBMS saranno commercializzati nei prossimi anni. Attualmente infatti i produttori di terminali stanno decidendo se inserirlo o meno nei mobili di Rel-6. Considerando la complessit realizzativa di MBMS e che oramai i cellulari di fascia medio alta di prossima commercializzazione saranno sempre pi dispositivi multimodo e multistandard (GSM; EDGE; WCDMA; H S D PA ; W L A N ; D V B - H ) l a g g i u n t a a n c h e d i MBMS non risulta essere unoperazione economicamente trascurabile o alla portata di tutti i produttori di chipset.
ABBREVIAZIONI
BIBLIOGRAFIA
[1]
3GPP Technical Specification 23.246: Multimedia Broadcast Multicast Service; Architecture and Functional Description (Stage-2). 3GPP Technical Specification 25.346: Introduction of the Multimedia Broadcast Multicast Service (MBMS) in the Radio Access Network (RAN) (Stage-2) 3GPP Technical Specification 25.992: Multimedia Broadcast Multicast Service (MBMS); UTRAN/GERAN Requirements. 3GPP Technical Specification 33.246: 3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS). 3GPP Technical Specification 43.246: Multimedia Broadcast Multicast Service (MBMS) in the GERAN; Stage 2.
[2]
[3]
[4]
[5]
2G AMC ARP BM-SC BSC BSF BSS CS DCH DL DTCH DTM DVB-H EDGE EGPRS FACH FEC FLUTE GBA GERAN GPRS GSM GTP HPLMN HSDPA HS-DSCH HSS HTTP IGMP IMSI MAC MBMS MCCH MCS MLD MMS MSC MSK MTCH MTK MUK NAF PBCCH PCCCH PS PSS PTM PTP RAN RB RRC
Second Generation Adaptive Modulation and Coding Allocation/Retention Priority Broadcast Multicast Service Centre Base Station Controller Bootstrapping Server Function Base Station Sub-system Coding Scheme Dedicated Channel Downlink Dedicated Traffic CHannel Dual Transfer Mode Digital Video Broadcasting - Handheld Enhanced Data rates for Global Evolution Enhanced GPRS Forward Access CHannel Forward Error Correction File Delivery over Unidirectional Transport Generic Bootstrapping Architecture GSM/EDGE Radio Access Network General Packet Radio Service Global System for Mobile communications GPRS Tunneling Protocol Home Public Land Mobile Network High Speed Downlink Packet Access High Speed Downlink Shared CHannel Home Subscriber Server Hypertext Transfer Protocol Internet Group Management Protocol International Mobile Subscriber Identity Medium Access Control Multimedia Broadcast Multicast Service MBMS Control Channel Modulation & Coding Scheme Multicast Listener Discovery Multimedia Messaging Service Mobile Switching Centre MBMS Service Key MBMS Traffic Channel MBMS Traffic Key MBMS User Key Network Application Function Packet Broadcast Control Channel Packet Common Control Channel Packet Switched Packet Switched Streaming Point To Multipoint Point To Point Radio Access Network Radio Bearer Radio Resource Control
65
RL RLC RNC RTP SAP SC S-CCPCH SFC SGSN SRTP TCP TDMA TMGI TPF TTI UDP UE UL URI UTRAN
Radio Link Radio Link Control Radio Network Controller Real-Time Protocol Service Access Point Selective Combining Secondary Common Control Physical Channel SoFt Combining Serving GPRS Support Node Secure Real-Time Protocol Transmission Control Protocol Time Division Multiple Access Temporary Mobile Group Identity Traffic Plane Function Transmission Timing Interval User Datagram Protocol User Equipment Uplink Uniform Resource Identifier UMTS Terrestrial Radio Access Network
Rosario Drogo De Iacovo si laureato in Ingegneria Elettronica presso il Politecnico di Torino nel 1986 e nello stesso a n n o e n t r a t o i n C S E LT ( o g g i T I L A B ) , dipartimento Servizi e Applicazioni dutente. La sua attivit si inizialmente concentrata nei campi della codifica audiovisiva, con particolare riferimento alla definizione della codifica audio per i sistemi mobili e della valutazione oggettiva e soggettiva della qualit nei servizi di telefonia. Dal 1987 al 1991, ha partecipato alla progettazione e definizione dei sistemi di codifica GSM FullRate e Half-Rate. detentore di brevetti internazionali nel campo della codifica audio e coautore del libro Speech And Audio Coding For W ireless And Network Applications , Kluwer Academic Publishers, USA, 1993. Successivamente ha ricoperto la carica di Rapporteur in ITU-T Study Group 16 per la tematica Audio and wideband coding ed attualmente delegato Telecom Italia in 3GPP SA4 (Codec).
Maria Pia Galante si laurea nel 1998 in Ingegneria Elettronica presso il Politecnico di Torino, sviluppando la tesi in Telecom Italia Lab (gi CSELT) presso il dipartimento di Microonde. Nel 1998 assunta in TILAB presso il dipartimento di Architetture di Rete per Ser vizi Mobili, dove si occupa di tecnologie ad Agenti Mobili per il controllo dei servizi in reti di terza generazione. Dal 1999 al 2002 partecipa per TIM ai lavori del consorzio 3G.IP sullevoluzione All IP della rete GSM/UMTS. Da maggio del 2000 partecipa per TIM al 3GPP SA WG2, comitato che definisce le specifiche di architettura per il sistema GSM/UMTS. Nel 2002 collabora alla stesura del libro UMTS, Accesso Radio ed Architetture di Rete a cura di H. Olma e A. Toskala (Nokia). Dal 2001 coordina le partecipazioni Telecom Italia Lab ai gruppi 3GPP, con particolare riferimento agli aspetti di servizio e di sistema.
Andrea Buldorini si laurea nel 1996 in Ingegneria Elettronica presso lUniversit di Bologna. Nellottobre 1997 entra in TILAB (gi CSELT) presso il dipartimento di Servizi e Sistemi Mobili e Radio. Dal 1998 partecipa ai gruppi ETSI DECT-R (standard DECT) e SMG2 (Interfaccia radio GSM/GPRS, ora in 3GPP GERAN). Prende parte ad attivit di consulenza per i piani di innovazione tecnologica delle consociate estere del Gruppo Telecom Italia. Si occupa di aspetti di pianificazione e gestione delle risorse radio e progettazione e sviluppo di tool di simulazione. Dal novembre 1999 partecipa per Telecom Italia al 3GPP RAN WG2, che definisce le specifiche di interfaccia radio per il sistema UMTS. editor del documento di specifica 3GPP TR 25.922 RRM Strategies che descrive le strategie di gestione e ottimizzazione delle risorse radio dellUMTS.
G i a n l u c a G r e c o si laureato con 110/110 nel 1997 in Ingegneria Elettronica allUniversit degli Studi Roma La Sapienza. Tra la fine del 1998 ed i primi mesi del 1999 ha frequentato lIstituto Superiore di Comunicazioni e delle Tecnologie dellInformazione presso il Ministero delle Comunicazioni. Dal marzo del 1999 lavora nel settore Tecnologie ed Industrializzazione della funzione Access Network della Direzione Rete di TIM, dove si occupa di tecnologie e di architetture per la rete di accesso radio 2G e 3G seguendo gli aspetti di evoluzione dei principali fornitori tecnologici di TIM. Dai primi del 2003 rappresenta Telecom Italia nel gruppo di lavoro internazionale 3GPP GERAN responsabile delle specifiche tecniche del sistema GSM/GPRS/EDGE.
Mauro Castagno si laurea nel 1993 in Ingegneria Elettronica presso il Politecnico di Torino. Dopo uno stage presso CSELT, nel 1995 assunto presso OMNITEL Pronto Italia (oggi Vodafone Italia), dipartimento Network Planning e partecipa alla fase di start up della rete, occupandosi di testing e di aspetti di Sicurezza del sistema GSM. Partecipa inoltre al gruppo di standardizzazione GSM ETSI SMG 10 (Security aspects). Nel 2000 assunto presso CSELT, oggi TOLAB, dove lavora nellambito della tecnologia radiomobile. Per un breve periodo si occupa di aspetti di Pianificazione Strategica, prestando supporto a Telestet (Grecia). Dal 2002, oltre ad essere coinvolto su progetti di interesse TIM, rappresenta Telecom Italia nel gruppo di lavoro internazionale 3GPP SA WG3, che si occupa degli aspetti di sicurezza del sistema 3GPP.
D a v i d e S o r b a r a si laureato in Ingegneria Elettronica (con lode) presso il Politecnico di Torino nel 1990, anno in cui stato assunto in CSELT, ora Telecom Italia. La sua attivit di ricerca si focalizzata sui sistemi radiomobili, quali GSM, TETRA, DECT, GPRS, EDGE e GERAN. stato coinvolto nella definizione di molteplici studi di fattibilit e nellanalisi delle prestazioni radio di questi sistemi, anche tramite lo sviluppo di simulatori software. I risultati provenienti da questa attivit sono stati utilizzati dai gruppi di standardizzazione allinterno dellETSI, per la definizione delle specifiche radio di alcuni dei sistemi citati. Dal 1995 al 1997 ha contribuito alla definizione delle specifiche radio del GPRS (Release 97). Dal 2004 delegato di Telecom Italia. nei gruppi 3GPP GERAN, GERAN1 e GERAN2, in cui ha contribuito in maniera determinante, essenziale e risolutiva alla standardizzazione dellMBMS nellambito della Release 6, tramite la preparazione e la presentazione, con conseguente approvazione, di oltre 130 contributi in sede di normativa. coautore del libro GPRS: Accesso Radio, Architettura di Rete, Protocolli e Servizi.
66

MBMS 1 2006

Caricato da

Informazioni sul documento

Titolo originale

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

MBMS 1 2006

Caricato da

Copyright:

Formati disponibili

ACCESSO

MBMS: la nuova frontiera del mobile broadcasting

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

2. MBMS Bearer Service

PDN (e.g. Internet) Content Provider/ Multicast Broadcast Source

2.1 Architettura ed elementi di Rete

Content Provider/ Multicast Broadcast Source

BM-SC GERAN GGSN SGSN TPF UE UTRAN

FIGURA 1 Architettura della rete iradiomobile per MBMS.

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

2.2 Modalit Multicast e Broadcast

Fasi valide solo per il modo Multicast

FIGURA 2 Fasi di service provisioning per MBMS per modalit broad-

2.3 Service provisioning e procedure

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

Session Start Request/Response Session Start Request/Response Session Start Request/Response

BM-SC GGSN RAN SGSN UE

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

3.1 Procedura di Autenticazione MBMS

SGSN GTP SGSN GGSN BM-SC

3. Aspetti di sicurezza e tariffazione

RNC ... RNC

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

MIKEY (MUKA, MSK)

FIGURA 8 Meccanismo (punto-punto) di distribuzione della chiave MSK.

MUKA MSK MTK

BSF HPLMN HSS NAF UE

MUKB MSK MTK

FIGURA 7 GBA: architettura di principio.

BM-SC MUK MSK MTK

3.2 Protezione del contenuto trasmesso

FIGURA 9 Meccanismo (punto-multipunto) di distribuzione della chiave

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

4.1 Codifica di sorgente

4. Livello applicativo: codec e protocolli

4.2 Meccanismi di repair

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

4.3 Schema FEC

Sessione PtM originaria Richiesta(e) di repair PtP Risposta(e) di PtP repair

4.4 Protocolli per il trasporto dei media

FIGURA 10 Meccanismo di PtP file repair.

5. Accesso radio MBMS in GERAN

5.1 Notifica ai terminali dellinizio di una sessione MBMS in una cella

FIGURA 11 Meccanismo di PtM file repair.

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

5.2 Modalit di trasmissione a livello radio

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

5.3 Assegnazione delle risorse radio

5.4 Gestione della mobilit

FIGURA 12 MBMS radio bearer senza canale di riscontro e senza PBCCH.

FIGURA 14 MBMS radio bearer con canale di riscontro e senza PBCCH.

FIGURA 13 MBMS radio bearer senza canale di riscontro e con PBCCH.

FIGURA 15 MBMS radio bearer con canale di riscontro e con PBCCH.

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

5.5 Valori di throughput ottenibili a livello radio

6. Accesso radio UTRAN

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 n. 1 - Giugno 2006

6.1 Bearer radio MBMS

1 Notification for session start

2 MBMS RB (MTCH, DTCH) establishment

3 MBMS data transfer