Beruflich Dokumente
Kultur Dokumente
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
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.
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.
UTRAN
UE
UTRAN
SGSN
GGSN TPF
BM - SC
UE
GERAN
= = = = = = =
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
50
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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.
51
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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
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.
= = = = =
Broadcast Multicast-Service Centre Gateway GPRS Support Node Radio Access Network Serving GPRS Support Node User Equipment
53
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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
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)
....
PTM PTP
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
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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.
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
HSS
Zh Zn BSF NAF A BM-SC MIKEY (MSK, MTK) MUKA MUKB MSK MTK
Ub
Ua
UE
= = = = =
Bootstrapping Server Function Home Public Land Mobile Network Home Subscriber Server Network Application Function User Equipment
Notation: MIKEY (KEK, KEY) delivers KEY under the protection of KEK using the MIKEY protocol.
= = = =
Broadcast Multicast-Service Centre MBMS User Key MBMS Service Key MBMS Traffic Key
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
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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.
57
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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.
Client MBMS
Repair Server(s)
Download Server(s)
MBMS = Multimedia Broadcast Multicast Service PtM = Point to Multipoint PtP = Point to Point
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.
Client MBMS
Repair Server(s)
Download Server(s)
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
58
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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.
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
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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.
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
DL = DownLink UL = UpLink
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
DL = DownLink UL = UpLink
60
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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.
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.
61
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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
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
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
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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)
* potenza di cella non sufficiente a fornire copertura a bordo cella. RL = Radio Link SC = Selective Combining TTI = Transmission Timing Interval
63
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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.
TTI TTI
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.
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
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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
BULDORINI CASTAGNO DROGO DE IACOVO GALANTE GRECO SORBARA MBMS: la nuova frontiera del mobile broadcasting
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