NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 N. 1 - Giugno 2006 - MBMS-1-2006 PDF

MBMS OK 17-05-2006 11:12 Pagina 49
ACCESSO
MBMS: la nuova frontiera del

mobile broadcasting
ANDREA BULDORINI MBMS rappresenta una vera rivoluzione per il mondo radiomobile, abi-
MAURO CASTAGNO tuato sin dagli albori all’uso di canali punto punto (p-t-p, point to point)
ROSARIO DROGO DE IACOVO per servire gli utenti in mobilità. L’introduzione di un canale punto multi-
MARIA PIA GALANTE punto (p-t-m, point to multipoint) e la gestione dei servizi e delle applica-
GIANLUCA GRECO zioni ad esso collegato, incluse la sicurezza dei dati scambiati e la tarif-
DAVIDE SORBARA fazione, ha richiesto la revisione completa dell’architettura della rete
radiomobile, dal terminale al GGSN.
Nell’articolo si descrive brevemente l’architettura 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, l’accesso radio MBMS in GERAN e in UTRAN.
1. Introduzione • l’accesso UTRAN e GERAN (WG RAN e WG

GERAN );
Ci sono voluti circa due anni e mezzo di intenso • la core network e i terminali (WG CT);
lavoro, ma alla fine del 2004 il 3GPP ha approvato • i servizi e l’architettura (WG SA1 e SA2);
l’introduzione di MBMS (Multimedia Broadcast • le applicazioni ed i codec (WG SA4);
Multicast Service) nelle specifiche tecniche di • la sicurezza (WG SA3).
Release 6. MBMS è lo standard 3GPP che per- Con MBMS è possibile usare al meglio le risorse
mette il supporto del Mobile Broadcasting, cioè di radio, quando il numero degli utenti in una cella
tutto l’insieme di servizi e applicazioni di tipo strea- supera una certa soglia, per offrire servizi diversi
ming o download and play fruibili contemporanea- (download di file video e audio, messaggistica di
mente da un insieme di utenti. vario tipo e potenzialmente anche mobile TV) sfrut-
L’opera di standardizzazione è stata impo- tando un solo canale condiviso da tutti, senza
nente ed ha coinvolto quasi tutti i gruppi di lavoro quindi impiegare tanti canali radio dedicati, uno per
del 3GPP: ogni utente. Inoltre MBMS può essere usato in
NOTIZIARIO TECNICO TELECOM ITALIA › Anno 15 n. 1 - Giugno 2006 49

MBMS OK 17-05-2006 11:12 Pagina 50
BULDORINI › CASTAGNO › DROGO DE IACOVO › GALANTE › GRECO › SORBARA • MBMS: la nuova frontiera del mobile broadcasting
caso di emergenza pubblica per veicolare la stessa il nodo GSN serva o meno un’area di distribu-
informazione ad una platea molto ampia nel più zione. In altre parole, ogni nodo di rete è interes-
breve tempo possibile. sato da un singolo flusso dati in arrivo dal BM-SC,
Per poter offrire MBMS è necessario aggior- indipendentemente dal numero N di ricevitori
nare molti nodi della rete radiomobile 2G e 3G verso cui è diretto (modalità punto-multi-punto, p-
(BSC, RNC, SGSN, GGSN) ed introdurre anche un t-m), anzichè da N flussi distinti (modalità punto-
nuovo elemento, il BM-SC (Broadcast Multicast- punto, p-t-p). Il numero di nodi GSN, e di nodi
Service Center). RNC/BSC, interessati al servizio dipende dall’e-
Visto quindi il numero di nodi di rete coinvolti, la stensione dell’area di diffusione del servizio stesso
tecnologia MBMS non farà la sua comparsa prima o dalla distribuzione degli utenti multicast. L’RNC
della metà del 2008, ed in ogni caso per poterne per l’UTRAN, o il BSC per il GERAN, provvedono
usufruire occorrerà avere un terminale di Release 6 a trasmettere i dati ai terminali MBMS utilizzando
che supporti MBMS. La sua completa diffusione efficientemente le risorse radio, ad esempio con
tra gli utenti richiederà alcuni anni, considerando il canali punto-multipunto. L’uso efficiente dell’inter-
normale tasso di sostituzione dei cellulari. faccia radio è sicuramente il requisito fondamen-
tale dell’intera architettura.
La configurazione dell’albero di distribuzione
2. MBMS Bearer Service dei contenuti è uno degli aspetti architetturali più
interessanti. In particolare, la lista dei nodi GSN e
Un generico servizio MBMS, come ad esem- RNC interessati dalla trasmissione di un certo ser-
pio un filmato, uno streaming live o un brano vizio MBMS può essere ottenuta tramite proce-
MP3, è tecnicamente realizzato tramite due com- dure di segnalazione specifiche iniziate dai singoli
ponenti fondamentali: una componente di tra- utenti/terminali interessati al servizio, oppure con-
sporto (MBMS Bearer Service) ed una applicativa figurata in maniera statica dall’operatore. Nel
o di contenuto (MBMS User Service). Il Bearer primo caso, si parla di modo Multicast, nel
Service MBMS è il servizio di trasporto offerto secondo di modo Broadcast.
dal dominio PS per la trasmissione di pacchetti Come si evince dalla figura 1 l’unica nuova
IP a più ricevitori secondo un determinato profilo interfaccia di rete definita a supporto dell’MBMS è
di QoS. Il Bearer Service viene gestito dalla rete l’interfaccia di segnalazione Gmb tra GGSN e BM-
secondo le tecniche che saranno descritte in SC. Su di essa transita la segnalazione user speci-
questo paragrafo, e nei paragrafi 5 e 6, impron- fic, relativa all’autorizzazione del singolo utente al
tate ad un uso efficiente delle risorse radio e servizio Multicast e la segnalazione bearer speci-
core. Lo User Service MBMS è invece l’applica- fic, relativa alla registrazione dei nodi GGSN all’al-
zione resa all’utente finale per mezzo dell’MBMS bero di distribuzione dei contenuti. Per il resto,
bearer service, ovvero il contenuto del servizio MBMS comporta impatti funzionali ai nodi di rete
opportunamente codificato e formattato secondo ed alle interfacce esistenti, con la modifica delle
le soluzioni descritte nel paragrafo 4. Lo User relative interfacce.
Service può utilizzare i servizi di tra-
sporto di uno o più Bearer Service. Ad
esempio, un videoclip può essere tra-
smesso su due diversi bearer service,
caratterizzati da diversa QoS (bit rate) e PDN
(e.g. Internet)
distribuiti su accessi radio (2G e 3G) Content
distinti. Provider/
Multicast
In questa sezione descriveremo gli Broadcast
aspetti di sistema a supporto del bearer UTRAN Source
service MBMS.
Content
2.1 Architettura ed elementi di Rete Provider/
GGSN Multicast
UE UTRAN SGSN BM - SC
TPF Broadcast
Source
Nell’architettura di rete per MBMS
illustrata in figura 1, spicca il nuovo nodo
di rete BM-SC cioè la sorgente dei dati UE GERAN
MBMS all’inter no della PLMN. Esso
affida la distribuzione dei contenuti mul-
timediali al dominio GPRS (nodi xGSN) BM-SC = Broadcast Multicast-Service Centre
GERAN = GSM/EDGE Radio Access Network
tramite l’interfaccia Gi. I meccanismi di GGSN = Gateway GPRS Support Node
rete attuati da MBMS sono tali per cui il SGSN = Serving GPRS Support Node
TPF = Traffic Plane Function
numero di “connessioni” associate ad un UE = User Equipment
UTRAN = UMTS Terrestrial Radio Access Network
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 FIGURA 1› Architettura della rete iradiomobile per MBMS.
massimo una, o nessuna, a seconda che
50 NOTIZIARIO TECNICO TELECOM ITALIA › Anno 15 n. 1 - Giugno 2006

MBMS OK 17-05-2006 11:12 Pagina 51
2.2 Modalità Multicast e Broadcast
La diffe re nza so stan zi al e tra Mu l ti cast e

Subscription
Broadcast Mode MBMS sta nel fatto che il primo
servizio distribuisce i contenuti solo nelle aree di Service Announcement
rete in cui sono presenti terminali che ne hanno
Joining
attivato la ricezione, mentre il secondo è un servi-
zio di trasporto che viene attivato in alcune aree Session Start
dall’Operatore indipendentemente dalla presenza
di ricevitori interessati. MBMS notification
Il Multicast Mode si basa su un meccanismo di
Data transfer
segnalazione che permette al terminale di asso-
ciarsi al gruppo multicast relativo ad un dato servi- Session Stop
zio (MBMS Multicast Service Activation); tale
Leaving
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. L’albero viene gestito dinamica- Fasi valide solo
mente, aggiungendo o rimuovendo nodi per effetto per il modo
Multicast
della mobilità degli utenti del gruppo stesso.
L’obiettivo delle procedure MBMS Multicast è dun-
que quello di creare nei singoli nodi un set di infor-
mazioni (MBMS bearer context) utili a caratteriz- FIGURA 2› Fasi di service provisioning per MBMS per modalità broad-
zare il piano di trasporto, e di garantire l’instrada-
mento dei dati solo verso i nodi GGSN e SGSN che cast e multicast.
controllano gli utenti che hanno effettivamente
richiesto il servizio.
Il Broadcast Mode, invece, è attivato da rete in mobile, di effettuare la tariffazione sulla base di
un’area di broadcast predefinita indipendente- tutta una serie di informazioni d’utente e di servizio
mente dalla presenza di utenti interessati al servi- raccolte nel nodo BM-SC. Come si vedrà più avanti
zio. Il terminale, in base alle informazioni ottenute (paragrafo 3), sono state lungamente discusse
in seguito al Service announcement (paragrafo delle modalità di tariffazione accurate e compatibili
2.3), attiva localmente la ricezione broadcast. con il paradigma peculiare di servizio non riscon-
Nel caso MBMS Multicast, inoltre, la rete d’ac- trato quale quello MBMS. Tali soluzioni, natural-
cesso può decidere la tipologia di canale radio da mente, non sono applicabili al Broadcast Mode,
utilizzare in una cella (punto-punto oppure punto- per il quale sarebbe possibile solo il charging del
multipunto), confrontando il numero di utenti pre- content provider.
senti ed interessati al servizio con una soglia pre-
fissata. Tali tecniche saranno descritte nei paragrafi 2.3 Service provisioning e procedure
5.2 e 6.2. Nel Broadcast mode tale ottimizzazione
non è ovviamente possibile. Di seguito viene proposto un breve cenno alle
A parte queste differenze, i meccanismi utiliz- fasi di service provisioning illustrate in figura 2 e
zati per l’instaurazione delle risorse di trasporto in alle procedure di rete atte a supportarle.
rete core e di accesso sono stati messo a punto
in maniera da essere riutilizzabili il più possibile • Subscription
per entrambe le modalità di trasmissione, È il tradizionale contratto tra utente e operatore
Multicast e Broadcast, per ovvie ragioni di sempli- che regola la fornitura del servizio. È una fase fon-
cità architetturale. Pertanto, le fasi di service pro- damentale nel modello Multicast: a valle di questa,
visioning per MBMS, schematizzate in figura 2, le informazioni di sottoscrizione sono registrate nel
sono per lo più comuni ad entrambe le modalità. nodo BM-SC e servono ad autorizzare o meno
Fanno eccezione le fasi di Subscription e l’accesso ad un dato servizio MBMS (user service).
Joining/Leaving che, nel caso Multicast, servono Tale fase non è fondamentale nel Broadcast. Le
a comporre dinamicamente il gruppo di utenti procedure a supporto della Subscription esulano
multicast e ad allestire in rete l’albero di distribu- dall’ambito normativo del 3GPP.
zione dei contenuti. In entrambe le modalità di
trasmissione MBMS, una volta determinato il set • Service Announcement
di nodi che costituisce l’albero di distribuzione, è La fase di Service Announcement annuncia e
necessario far precedere l’invio dei dati da una pubblicizza i servizi d’utente disponibili, offrendo
fase di preparazione delle risorse di trasporto anche tutta una serie di informazioni/parametri
(Session Start, MBMS Notification, …, Session necessari per la loro attivazione (es. tempo d’inizio,
Stop), per esempio per effettuare il paging ed il identificativo del servizio ovvero IP multicast
radio bearer set up in accesso. address, …). A queste informazioni possono acce-
Infine, la conoscenza degli utenti associati ad dere anche utenti non (ancora) sottoscritti al servi-
un servizio Multicast, permette all’operatore radio- zio. Per questa fase non sono state introdotte

MBMS OK 17-05-2006 11:12 Pagina 52
nuove procedure di segnalazione di rete essendo ll GGSN controlla presso il BM-SC che l’utente
possibile riutilizzare meccanismi già noti quali Push sia effettivamente autorizzato ad accedere al servi-
SMS/WAP, SMS Cell Broadcast, … . zio. 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 dell’Activate MBMS Context
diventa membro di un gruppo multicast. La proce- Request 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, l’utente 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
L’effetto 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, semplifican- inoltre, passa al nodo GGSN un set di parametri
doli, gli aspetti più salienti. che caratterizzano il servizio attivato (MBMS
Con riferimento alla figura 3, l’attivazione viene Bearer Context). I parametri tipicamente inclusi
iniziata dallo UE con un messaggio di Join IGMP (o nell’MBMS Bearer Context sono: il TMGI
MLD) contenente l’indirizzo IP multicast associato (Temporary Mobile Group Identity, l’identificativo
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), l’a-
rea all’interno della quale il servizio può
essere distribuito, il tipo di modalità
UE RAN SGSN GGSN BM-SC
broadcast/multicast del bearer, le capa-
IGMP Join bility minime richieste al terminale … .
MBMS Ricevuto un riscontro positivo, anche
Request MBMS Context Activation Authorization l’SGSN si “registra” al GGSN, ovvero
Activate MBMS Context Request
all’albero di distribuzione del servizio,
Create MBMS ammesso che non lo abbia già fatto in
Context Request precedenza per effetto del Join di un
altro utente allo stesso servizio, ed
MBMS
Registration ottiene dal GGSN le informazioni di
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
Registration un cosiddetto UE Context, incluso nel
Request Mobility Management Context GPRS. Lo
Provision
UE Context MBMS contiene per ogni UE
info to RAN informazioni più attinenti al singolo ter-
minale/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
GGSN = Gateway GPRS Support Node MBMS attivi, …). L’insieme degli UE
IGMP = Internet Group Management Protocol Context aiuta a determinare su ciascun
MBMS = Multimedia Broadcast Multicast Service
RAN = Radio Access Network nodo il numero di utenti associati ad un
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
FIGURA 3› MBMS Multicast Service Activation. stesso servizio venga creato un solo
Bearer Context in ciascun nodo di rete,
indipendentemente dal numero di utenti
associati al gruppo multicast.
Il messaggio arriva al GGSN tramite un gene- Attraverso la procedura denominata UE
rico PDP context di tipo unicast che si assume Linking e valida solo per l’accesso UTRAN, il
essere già attivo al momento del Join, e che nodo SGSN for nisce all’RNC sia il Bearer
dovrà rimanere attivo per tutta la durata della Context (per quanto sopra, questo avviene solo
registrazione dell’utente al servizio MBMS. La nel caso il Bearer Context non fosse già pre-
richiesta di Join viaggia in maniera trasparente al sente in RNC per effetto della presenza di altri
nodo SGSN. utenti) che lo UE context.

MBMS OK 17-05-2006 11:12 Pagina 53
Al termine di tali procedure, il

nodo SGSN conferma allo UE la
richiesta di attivazione del bearer
UE RAN SGSN GGSN BM-SC
inviando, tra i vari parametri, anche
il TMGI (Temporary Mobile Group
Identity). Il TMGI è l’identificativo Session Start
del bearer service a cui lo UE si è Request/Response
associato. Esso viene utilizzato
dalla rete sulla tratta radio nella Session Start
Request/Response
procedura di paging per notificare
a tutti (e soli) gli utenti del gruppo Session Start
Request/Response
l’inizio della trasmissione.
Da notare che nel caso MBMS
Broadcast, il TMGI deve essere Resource
Set up
reso noto allo UE attraverso il
Se rvic e Announ cemen t, n o n
essendo prevista la procedura di
Join appena descritta. GGSN = Gateway GPRS Support Node
RAN = Radio Access Network
SGSN = Serving GPRS Support Node
• Session Start UE = User Equipment
Al Session Start il nodo BM-SC
è pronto per l’invio 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 ven-
La figura 4 mostra i flussi informativi a supporto gono informati della trasmissione MBMS inci-
del Session Start. piente. Con riferimento alla figura 4, la Notification
Nel caso Multicast, il Session Start consiste coincide con l’ultimo passo del Session Start,
nell’invio 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 all’albero 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 tra-
mite il Join degli utenti ad un dato servizio multi- smessi da BM-SC ai terminali.
cast viene creato l’albero 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 dall’opera- • 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 dell’albero di distri-
Tipicamente, tramite questa procedura il BM-SC buzione) solo quando anche l’ultimo membro del
distribuisce lungo tutto l’albero di distribuzione gruppo disattiva il servizio sul nodo.
anche alcuni parametri di interesse (session attribu- Alle 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), l’Estimated Session ad associare un nuovo nodo (RNC, BSC, SGSN o
Duration (la durata della sessione), il Time To Data GGSN) all’albero di distribuzione multicast, per
Transfer (stima del tempo intercorrente dall’invio del effetto dell’arrivo di un membro del gruppo nell’area
Session Start Request all’inizio della trasmissione). servita.

MBMS OK 17-05-2006 11:12 Pagina 54
Le procedure di Inter/Intra SGSN RAU sono 3.1 Procedura di Autenticazione MBMS

invece le procedure di mobilità classiche del GPRS
(3GPP Technical Specification 23.060), a cui sono Il meccanismo di (mutua) autenticazione previ-
state aggiunte nuove logiche per gestire la riloca- sto tra UE e BM-SC è di tipo http digest (RFC
zione degli UE Context da un vecchio ad un nuovo 2617). Le credenziali (username e password) richie-
SGSN. Tali logiche richiedono tipicamente l’invoca- ste da http digest si assumono condivise in prece-
zione delle Registration Procedure di cui sopra (es. denza tra le parti (UE e BM-SC). Il metodo utiliz-
nel caso in cui lo UE Context istanziato nel nuovo zato per la condivisione di cui sopra si basa sul
SGSN contenga l’identificativo di un servizio concetto di GBA (Generic Bootstrapping
MBMS il cui Bearer Context non è presente nel Architecture) brevemente descritto nel seguito e in
nodo).
Infine, nella figura 5 sono
sintetizzati in termini macro-
scopici gli impatti previsti
sul sistema 3GPP per l’intro- Radio Access: nuove funzionalità in GERAN e UTRAN permettono
Terminali: adesione ai il setup di canali trasmissivi di tipo PUNTO-MULTIPUNTO in ciascuna
duzione del servizio MBMS gruppi Multicast e cella servente almeno un utente interessato al servizio. UTRAN permette
Multicast, e che anticipano ricezione in PtM. il fallback a trsmissione PUNTO-PUNTO in caso di basso numero di utenti.
GERAN prevede una trasmissione radio PtM riscontrata per basso
alcuni aspetti che saranno numero di utenti.
più approfonditamente trat- ....
PTM BSC
tati nei paragrafi successivi. ... Service Centre
SGSN (User profile e gestione
BSC accesso ai servizi MBMS,
GTP GGSN BM-SC Content Source,
.... Point-to-Point Repair)
3. Aspetti di sicurezza e PTM RNC SGSN
...
tariffazione Core Network*: il GTP è modificato per consentire
PTP RNC
la creazione in rete di un unico flusso di dati
MBMS introduce il con- per Servizio MBMS, e per nodo GSN servente almeno
un utente interessato al servizio.
c e tto di se rviz i o di ti po
BSC = Base Station Controller
punto-multipunto nelle reti GGSN = Gateway GPRS Support Node
3GPP e consente l’invio di GTP = GPRS Tunneling Protocol
un certo contenuto informa- PtM = Point to Multipoint
tivo, da un BM-SC ad un RNC = Radio Access Network
SGSN = Serving GPRS Support Node
gruppo di legittimi destina-
tari. Al fine di controllare
l’accesso 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 ren-
dere 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 pre-
suppone la certezza dell’identità dell’utente che ne
Content
usufruisce e implica, pertanto, una procedura di Mobile Operator Network Server
autenticazione. La natura “multicast/broadcast” del
BSF BM-SC Internet
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 parti- BGW
colare attenzione perchè deve risultare efficace
anche nei confronti di una nuova insidia: la poten-
ziale complicità di un legittimo destinatario e di un
utente non autorizzato, ai danni dell’operatore. Nel
caso MBMS, infatti, un legittimo destinatario BM-SC can reside in home
potrebbe non essere interessato a proteggere la or visited network
confidenzialità del contenuto che riceve, ma anzi,
potrebbe essere interessato all’esatto contrario, BGW = Bearer Gateway (first hop IP-router)
desiderando condividerlo in modo fraudolento con BM-SC = Broadcast Multicast-Service Center
BSF = Bootstrapping Server Function
terze parti non autorizzate.
La sicurezza MBMS viene garantita a livello
applicativo, tra BM-SC e UE. Richiede soltanto la
connettività a livello IP e si realizza attraverso l’ar- FIGURA 6› Architettura di sicurezza MBMS.
chitettura di sicurezza illustrata in figura 6.

MBMS OK 17-05-2006 11:12 Pagina 55
Con riferimento alla figura 7, che rappresenta Gli aspetti principali del meccanismo in que-
lo schema di principio (semplificato) del GBA, l’ac- stione sono illustrati nel seguito e riassunti nelle
cesso al servizio fornito dal blocco funzionale NAF figure 8 e 9.
(generico e potenzialmente non gestito dalla
HPLMN) avviene sull’interfaccia Ua utilizzando il
protocollo previsto dall’applicazione. Il concetto di
GBA prevede che la sicurezza sull’interfaccia Ua
possa essere garantita utilizzando (tra UE e NAF) A
MIKEY (MUKA, MSK)
credenziali calcolate e condivise in precedenza su
un’altra interfaccia, la Ub, tra UE e il blocco fun-
MUKA BM-SC
zionale BSF (Bootstrapping Server Function), sem- MSK
pre localizzato presso la HPLMN. Il protocollo in
uso sull’interfaccia Ub è http Digest AKA e sfrutta
MIKEY (MUKB, MSK)
l’algoritmo di autenticazione 3GPP, elemento pre-
zioso gestito dagli Operatori di telefonia mobile.
B
Le credenziali “concordate” tra UE e BSF sull’in-
terfaccia Ub sono inviate al NAF (cioè al BM-SC, MUKB
MSK Notation:
nel caso specifico del servizio MBMS) dal BSF, MIKEY (KEK, KEY) delivers KEY
all’occorrenza e previa verifica della legittimità under the protection of KEK using
the MIKEY protocol (RFC 3830).
della richiesta.
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
MUKA
MUKB
MUKA BM-SC MSK
MSK MTK
Ub Ua MTK MIKEY
(MSK, MTK)
UE
BSF = Bootstrapping Server Function

HPLMN = Home Public Land Mobile Network Notation:
HSS = Home Subscriber Server MUKB MIKEY (KEK, KEY) delivers KEY
NAF = Network Application Function MSK under the protection of KEK using
UE = User Equipment B MTK the MIKEY protocol.

FIGURA 7› GBA: architettura di principio. MUK = MBMS User Key
MSK = MBMS Service Key
MTK = MBMS Traffic Key
3.2 Protezione del contenuto trasmesso

FIGURA 9› Meccanismo (punto-multipunto) di distribuzione della chiave
Il meccanismo di protezione del contenuto MSK.
MBMS, meccanismo volto a scongiurare/dissua-
dere i più disparati scenari di accesso fraudolento1
e, allo stesso tempo, a non precludere alcuno dei • La restrizione (ai legittimi destinatari) dell’ac-
charging scheme previsti per il servizio, risulta piut- cesso ad un determinato contenuto MBMS
tosto articolato e prevede un triplo livello gerar- avviene utilizzando la crittografia ed una chiave
chico di chiavi: MTK (MBMS Traffic Key), MSK MTK comune a tutti i membri del gruppo. Per
(MBMS Service Key) e MUK (MBMS User Key). evitare accessi non autorizzati al contenuto di
(1)
cui sopra, la chiave MTK in uso deve essere
distribuita a tutti e soli i membri del gruppo in
operati da legittimi destinatari desiderosi di ridurre/contenere i modo sicuro, ossia protetta da eventuali inter-
propri costi telefonici, da potenziali intrusi interessati ad acce- cettazioni sulla tratta radio. Si osservi tuttavia
dere al contenuto gratuitamente o a spese altrui e/o da entram- che la protezione della chiave MTK sulla tratta
bi, che cooperano cospirando ai danni dell’operatore. radio non è efficace contro eventuali cessioni a

MBMS OK 17-05-2006 11:12 Pagina 56
terzi della chiave stessa da parte di un legittimo Bootstrapping Architecture (GBA). Dal
destinatario che opera ai danni dell’operatore. 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 tra- protezione possibile, sia per quanto riguarda
smesso avviene presso il terminale d’utente, 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 smart-
sopra, che vede un legittimo destinatario risalire card, se questa è MBMS-capable, oppure
alla chiave MTK memorizzata sul proprio termi- presso un’area opportunamente protetta del
nale, non può essere impedito in assoluto, ma terminale mobile, in caso contrario.
può essere scoraggiato dall’operatore, con una
sostituzione sufficientemente frequente della 3.3 Charging
chiave stessa.
• La chiave MTK viene generata (e applicata al Il meccanismo di tariffazione MBMS (“tradizio-
contenuto MBMS da trasmettersi) presso il nale” e prepagato) è volto a garantire all’operatore
BM-SC. la massima flessibilità in termini di possibili char-
• La distribuzione della chiave MTK avviene uti- ging scheme attuabili e tiene conto della presenza
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 nel servizio di una componente di contenuto
Internet KEYing), in modalità punto-multipunto. MBMS (User Service), accanto ad una di trasporto
Sulla tratta radio, l’accesso all’informazione MBMS (Bearer Service), che vengono gestite in
MTK è limitato dal protocollo MIKEY stesso ai modo indipendente.
soli destinatari che dispongono di una Più in dettaglio, la componente di trasporto
seconda chiave denominata MSK, apparte- MBMS può essere tariffata in base alla durata
nente ad un livello gerarchico superiore e della sessione, al volume di dati in essa scam-
comune a tutti i legittimi destinatari della biati, alla durata della permanenza dell’utente
chiave MTK che protegge. all’interno di un determinato gruppo Multicast e/o
• Una stessa chiave MSK può essere utilizzata in base ad altri parametri di rete (es. QoS). La
per proteggere la distribuzione di più chiavi componente di contenuto MBMS, invece, può
MTK (ad esempio nel caso di re-keying fre- essere tariffata per sottoscrizione, vincolando
quente) ed è quindi un elemento più sensibile l’accesso ad un certo servizio MBMS ad una
della MTK. Ne consegue che la MSK, oltre a quota fissa (es. canone mensile) oppure per
dover essere distribuita ai legittimi destinatari in evento, ossia con un meccanismo di charging più
modo sicuro (ossia protetta da eventuali inter- raffinato che potrebbe risultare appetibile/ottimale
cettazioni sulla tratta radio), lato utente deve per determinati servizi.
essere custodita presso la smartcard, se questa Si osservi che, a prescindere dalla componente
è MBMS-capable , oppure presso un’area MBMS tariffata (servizio, trasporto o entrambe),
opportunamente protetta del terminale mobile, potenzialmente, l’entità fisica candidata a soste-
in caso contrario. nere le spese di un certo servizio MBMS non è
• La chiave MSK viene distribuita ai legittimi sempre e solo l’utente finale (il r e c e iv ing
destinatari utilizzando sempre il protocollo subscriber): in alcuni casi, l’operatore potrebbe
MIKEY, ma in modalità punto-punto, protetta a decidere di rivalersi anche, o soltanto, sul Content
sua volta da una terza chiave denominata MUK, Provider, come illustrato schematicamente nella
user-specific e appartenente ad un ulteriore tabella 1.
livello gerarchico superiore. La tariffazione del contenuto MBMS per evento,
• Concettualmente, la chiave MUK potrebbe eventualmente abbinata ad uno o più degli altri
anche essere di tipo permanente, tuttavia per charging scheme di cui sopra, appare piuttosto
ragioni di backward compatibility (verso USIM plausibile e per questo verrà sviluppata ulterior-
non MBMS-capable, ad esempio perchè di mente nel seguito.
Releases precedenti) e
di flessibilità, lo stan-
dard 3GPP prevede che
possa essere distribuita
e sostituita, se necessa- Service Aspects MBMS Bearer Service used
rio. Il meccanismo previ- Multicast (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 condivi-
sione 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

MBMS OK 17-05-2006 11:12 Pagina 57
In generale, la tariffazione equa ed affidabile 4.1 Codifica di sorgente

dei servizi è un aspetto molto importante per un
operatore. Per questo, in fase di specifica, 3GPP Per quanto riguarda i codec audio-video da
si è adoperato per raggiungere questo obiettivo al usare per MBMS, essi sono stati selezionati omo-
meglio, nel limite del possibile, ossia tenendo geneamente rispetto a quelli già specificati per altri
anche conto di possibili scenari fraudolenti. In una servizi 3G quali MMS e PSS, al fine di limitare la
prima fase, 3GPP pensava di basare l’event char- proliferazione degli standard e di minimizzare i pro-
ging sul delivery verification, ossia su un riscontro blemi legati all’interoperabilità di standard diversi. I
esplicito (da parte dell’utente) dell’avvenuta rice- codec audio per MBMS possono consistere in uno
zione del contenuto (o della chiave “master” MSK o più fra i seguenti:
utile a decifrarlo). In seguito, però, tale scelta è • AMR Narrow Band;
stata accantonata a causa dello scenario fraudo- • AMR Wide Band;
lento che avrebbe certamente alimentato, chiara- • Extended AMR Wide Band;
mente volto a precludere l’invio alla rete (da parte • Enhanced aacPlus.
del UE) di tale riscontro. Il principio verso cui Come codificatori video sono invece, previsti:
3GPP si è dunque orientato ai fini del charging per • H.264/AVC Baseline Profile;
evento presuppone che in condizioni ordinarie un • ITU-T H.263.
legittimo destinatario di un certo evento MBMS Per aiutare l’operatore mobile nel non sempre
(cioè che ha sottoscritto un certo servizio MBMS e facile compito di scegliere un codec adatto al ser-
ha manifestato esplicito interesse per l’evento vizio che intende offrire, le specifiche tecniche
specifico) riceva la chiave MSK necessaria per 3GPP mettono a disposizione delle linee guida per
decifrare la chiave MTK e quindi il contenuto e stabilire quale codec usare in funzione delle carat-
che, in caso di failure, per qualsivoglia motivo, teristiche del servizio offerto (tipologia di contenuti,
possa comunque inoltrare e reiterare la richiesta banda disponibile, modalità di delivery, ...). A titolo
della chiave di cui sopra alla rete, fino a riceverla. di esempio, le linee guida fornite relativamente ai
Questo principio garantisce un charging ritenuto codificatori audio Enhanced aacPlus ed Extended
ragionevolmente affidabile ed equo nei confronti AMR WideBand per servizio MBMS, possono
del cliente finale e, allo stesso tempo, tutela l’ope- essere così sintetizzate:
ratore da scenari fraudolenti che, altrimenti, • Extended AMR WideBand offre prestazioni
rischierebbero di compromettere la redditività del migliori a velocità medio-basse (inferiori a 24
servizio. kbit/s) e con contenuti solo vocali o intervallati
La tariffazione MBMS per evento si basa dun- con musica;
que sul meccanismo di (ri)distribuzione delle chiavi • Enhanced aacPlus, invece, offre prestazioni
di sicurezza, ed in particolare sulla (ri)distribuzione migliori a velocità tendenzialmente più alte e
della chiave MSK, che si assume sufficientemente con contenuti prevalentemente musicali.
affidabile da non richiedere riscontri espliciti da Oltre all’audio ed il video, i seguenti tipi di
parte dell’utente finale. Ne consegue che ogni sin- media possono essere usati in un servizio MBMS:
golo evento MBMS deve essere protetto con una • Synthetic audio;
propria chiave MSK, nuova. Alla luce del fatto che • Still images;
la (ri)distribuzione della chiave MSK avviene in • Bitmap graphics;
modalità punto-punto e che, pertanto, potrebbe • Vector graphics;
risultare onerosa in caso di eventi MBMS di grande • Text;
richiamo, tale scelta non risulta forse perfetta, ma è • Timed text.
il risultato di un compromesso, volto a garantire un Anche se i codificatori di sorgente offrono
charging equo ed affidabile da un lato e a tutelare intrinsecamente la capacità di mitigare gli errori di
la sicurezza del servizio dall’altro. canale, il livello di protezione necessario si rag-
giunge con l’uso di FEC a livello applicativo.
Inoltre, nel caso particolare di download, è previsto
4. Livello applicativo: codec e protocolli il meccanismo addizionale del “file repair” in moda-
lità Po i n t- to - Point (P -t -P ) repair e P o int -t o -
Uno degli aspetti cruciali per assicurare un’alta Multipoint (P-t-M) repair.
QoS all’utente di un servizio MBMS è l’uso di ade-
guati codec audio-video e meccanismi di prote- 4.2 Meccanismi di repair
zione dagli errori introdotti dai canali di trasmis-
sioni quali appunto i FEC (Forward Error Lo scopo dei meccanismi di file repair è quello
Correction). L’importanza di tali meccanismi di pro- di chiedere la ritrasmissione dei frammenti di dati
tezione è legata alle caratteristiche della trasmis- persi o corrotti, dopo la fine della sessione di
sione punto-multipunto, dove non è possibile utiliz- download. Una delle peculiarità di un servizio
zare tutte le usuali tecniche radio (come le ritra- MBMS è che può essere offerto massivamente in
smissioni in caso di ricezione di pacchetti errati) un intervallo temporale anche molto limitato
per mitigare gli errori del canale. Pertanto, per ponendo dei problemi di scalabilità per i meccani-
compensare tale perdita di prestazioni, è stato smi di repair. La soluzione inserita nello standard si
necessario specificare degli appositi meccanismi di basa su una randomizzazione temporale e spaziale
protezione. delle richieste di repair al fine di evitare il fenomeno

MBMS OK 17-05-2006 11:12 Pagina 58
della “feedback implosion”, cioè un grande numero 4.3 Schema FEC

di client MBMS che richiedono simultaneamente il
file repair. La figura 10 mostra schematicamente il Sia per MBMS downloading che streaming è
caso di P-t-P file repair. Se il client MBMS non ha stata individuata la possibilità di usare un FEC a
ricevuto correttamente tutti i dati necessari a rico- livello applicativo. In questo modo è possibile otte-
struire il file, inizia la procedura di file repair sele- nere il desiderato livello di tasso di errore senza
zionando da una lista precedentemente ricevuta il appesantire la parte radio con un meccanismo
server di repair. Il client invia una o più richieste di equivalente di protezione. Infatti, i livelli di prote-
repair a questo server che risponde tipicamente zione offerti dal FEC saranno configurabili come
con i dati richiesti. Una singola sessione TCP con minimo su base sessione. Tuttavia, l’uso del FEC è
protoc ollo HTTP vi en e u sata per tu tte l e inteso come opzionale per l’operatore (service pro-
richieste/risposte di repair provenienti da un deter- vider), che può anche decidere di usare l’opzione
minato client. 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 pre-
Repair Download stazioni generalmente comparabili o migliori
Client MBMS Server(s) Server(s) rispetto alle altre famiglie di FEC proposte.
Sessione PtM originaria 4.4 Protocolli per il trasporto dei media

Richiesta(e) di repair PtP
A seconda della tipologia di delivery del servizio
Risposta(e) di PtP repair MBMS (download o streaming) i media saranno
trasportati al client secondo due stack protocollari
diversi. Nel caso di download è previsto il proto-
PtM = Point to Multipoint collo FLUTE per il trasporto di oggetti (file). Nel
PtP = Point to Point caso di streaming sarà invece usato il protocollo
RTP (o SRTP nel caso di trasporto sicuro) per
inviare dati in tempo reale su UDP.
FIGURA 10› Meccanismo di PtP file repair. Questa soluzione permette di soddisfare gli
specifici requisiti di servizio definiti all’interno del
3GPP e al tempo stesso massimizzare la comu-
Nel caso in cui molti client MBMS richiedano lo nanza con i protocolli IETF (protocolli FLUTE e
stesso frammento di dati risulta più vantaggioso RTP), come già fatto per il servizio PSS.
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 5. Accesso radio MBMS in GERAN
HTTP “redirection” indicando che i dati di repair
sono disponibili tramite un URI diverso. Il client La descrizione dell’accesso radio MBMS in
effettua il joining alla nuova sessione MBMS e GERAN fa riferimento all’utilizzo dell’interfaccia Gb
aspetta l’inizio della trasmissione dei dati di tra il BSS e l’SGSN 2G relativo alla Core Network
repair. GSM, su cui si è completamente focalizzata l’atti-
vità di standardizzazione in ambito GERAN.
5.1 Notifica ai terminali dell’inizio di una sessione

Repair Download
MBMS in una cella
Client MBMS Server(s) Server(s)
A seguito della ricezione di un messaggio di
Sessione PtM originaria “MBMS SESSION START REQUEST” proveniente
dall’SGSN, il BSS può inviare ai terminali in packet
Richiesta(e) di repair PtP
decisione:
idle mode una pre-notifica dell’inizio di una ses-
Risposta(e) di PtP repair uso PtM sione nell’ambito di un servizio MBMS, specifi-
(redirect) cando l’identificativo del servizio stesso e, se
Sessione PtM repair
disponibile, l’identificativo della sessione nell’am-
bito del servizio. Nel caso di un servizio broadcast
per il quale ne è richiesta la ricezione o nel caso di
MBMS = Multimedia Broadcast Multicast Service un servizio multicast per il quale l’utente ha prece-
PtM = Point to Multipoint
PtP = Point to Point dentemente effettuato la procedura di “joining”, il
terminale attende la ricezione della notifica dell’ini-
zio di una sessione (che non sia già stata ricevuta)
FIGURA 11› Meccanismo di PtM file repair. proveniente dalla rete. La rete invia la notifica del-
l’inizio della sessione in tutte le celle appartenenti

MBMS OK 17-05-2006 11:12 Pagina 59
alla MBMS Service Area pertinente al servizio di comunque quello riscontrato ed esaustivo (con la
cui essa fa parte. La notifica può includere la ritrasmissione di tutti i blocchi radio indicati come
richiesta di ‘counting’ dei terminali, procedura che errati dalla parte ricevente) e neppure quello non
consente alla rete di valutare il numero dei terminali riscontrato (che non prevede alcuna ritrasmis-
che richiedono di ricevere una specifica sessione sione), già specificati per i servizi punto-punto. Per
nell’ambito della cella. La valutazione è effettuata l’MBMS è stata introdotta una terza modalità del
sulla base dell’invio, da parte dei mobili interessati, protocollo RLC, denominata non persistente (in
di una richiesta della sessione in risposta alla noti- quanto le ritrasmissioni sono effettuate dalla rete,
fica proveniente dalla rete. La valutazione del ma non necessariamente per tutti i blocchi radio
numero di terminali, che richiedono la ricezione di indicati come errati da parte dei terminali coinvolti
una specifica sessione nell’ambito della cella, con- nella ricezione della sessione, ed il protocollo non
sente alla rete di ottimizzare la modalità di trasmis- richiede che tutti i blocchi radio siano corretta-
sione dei dati relativi a quella sessione nell’ambito mente ricevuti lato mobile).
della cella. Nel caso in cui la procedura di “coun- Il protocollo non persistente a livello RLC si
ting” non sia richiesta dalla rete, la notifica può applica anche nel caso in cui la modalità di tra-
includere direttamente l’assegnazione delle risorse smissione non sia riscontrata a livello radio. Anche
radio per la sessione notificata, specificando in in questo caso l’algoritmo di ritrasmissione dei
particolare i canali radio su cui sarà inviata la ses- blocchi radio non è specificato e dipende dalle
sione e l’identificativo radio della sessione stessa. implementazioni di rete, ma non si può comunque
La decisione da parte del BSS di allocare o avvalere delle informazioni che sono rese disponi-
meno risorse radio in una cella per la sessione, ed bili dai riscontri inviati nella modalità precedente-
in caso affermativo sul numero di risorse radio da mente descritta.
allocare, dipende dalla implementazione e deve Il numero di utenti per sessione nella cella che
essere presa tenendo conto dei valori del campo discrimina le due modalità di trasmissione è 16, in
informativo Allocation/Retention Priority (ARP), quanto questo è il massimo numero di terminali a
qualora esso sia incluso nel messaggio “MBMS cui è possibile aggiornare periodicamente, su una
SESSION START REQUEST” ed il BSS sia in grado risorsa radio, tramite la procedura GPRS di “conti-
di gestire questo campo, e sulla base delle risorse nuous timing advance update” l’informazione di
radio disponibili nella cella. Tale campo consente timing advance, che consente di allineare la base
di specificare il livello di priorità della sessione, se tempi del mobile con quella della stazione radio
essa può o meno scatenare la procedura di “pre- base, in funzione della loro distanza. Senza questo
emption” di servizi nel dominio PS che siano a più aggior namento periodico, ad un terminale
bassa priorità nella cella e che possano essere GPRS/EGPRS non è consentito trasmettere un
oggetto di “pre-emption”, e se può essere a sua blocco radio (e quindi neppure un riscontro come
volta oggetto di “pre-emption” da parte di servizi a descritto precedentemente), in quanto il conse-
più alta priorità nella cella. guente disallineamento della base tempi del mobile
Nel caso in cui sia presente l’identificativo della rispetto a quella della stazione radio base potrebbe
sessione nel messaggio proveniente dall’SGSN, comportare la parziale ricezione dei normal burst
sarà presente anche il numero di ripetizione della (unità informative di livello 1) costituenti un blocco
sessione stessa, per consentire al BSS di sapere radio (unità informativa di livello 2), da parte della
se si tratta della prima trasmissione della sessione stazione radio base, su uno dei time slot adiacenti
o di una sua ripetizione, ed in questo caso del a quello previsto per quel terminale, con conse-
numero della ripetizione della stessa. Anche que- guente collisione con i normal burst provenienti da
sto campo informativo può essere utilizzato dal altri mobili.
BSS, ad esempio per decidere se effettuare o Indipendentemente dalla modalità di trasmis-
meno la procedura di ‘counting’ nella cella oppure sione utilizzata tra le due precedentemente
in congiunzione con l’ARP (se disponibile) per descritte, un terminale che riceva una o più ses-
decidere se allocare o meno risorse radio nella sioni MBMS si trova nello stato di broadcast/multi-
cella per la trasmissione della sessione. cast receive mode, che è visto come un sotto-stato
del packet idle mode, ed al terminale non è possi-
5.2 Modalità di trasmissione a livello radio bile essere contemporaneamente coinvolto in una
connessione a circuito e/o in una o più sessioni a
Se il numero di mobili MBMS coinvolti nella pacchetto di tipo punto-punto.
ricezione di una specifica sessione nell’ambito di Anche ai mobili coinvolti in una connessione a
una cella non è superiore a 16, è possibile che la circuito o in una o più sessioni a pacchetto di tipo
rete instauri una modalità di trasmissione riscon- punto-punto o in DTM è comunque possibile rice-
trata a livello radio nella cella: ad ogni terminale vere la notifica dell’inizio di una sessione MBMS da
potrà essere richiesto da parte della rete l’invio di parte della rete. Tuttavia, affinché un terminale
riscontri sulle unità informative (blocchi radio) rice- MBMS possa ricevere la sessione notificata, deve
vute corrette e su quelle errate, al fine di consentire prima rientrare in packet idle mode, dopo aver rila-
alla rete di decidere se e quali blocchi radio ritra- sciato la connessione a circuito e/o la(e) sessione(i)
smettere. L’algoritmo di ritrasmissione dei blocchi a pacchetto di tipo punto-punto in cui era prece-
radio non è specificato e dipende dalle implemen- dentemente coinvolto, e quindi entrare in broad-
tazioni di rete. Il protocollo di ritrasmissione non è cast/multicast receive mode.

MBMS OK 17-05-2006 11:12 Pagina 60
5.3 Assegnazione delle risorse radio una finestra la cui dimensione massima è 6), di tra-
smettere al più su 2, e la somma dei canali su cui
Una volta che la rete ha effettuato il counting riceve e trasmette non deve essere comunque
dei terminali (se così richiesto nella notifica dell’ini- superiore a 6, su base trama TDMA. Tra i canali
zio della sessione), essa invia l’assegnazione delle radio ricevuti in downlink occorre includere anche
risorse ai mobili, nel caso in cui sia allocato un quello su cui sono mappati i canali di controllo
MBMS radio bearer per quella sessione, specifi- broadcast e comune, che devono essere comun-
cando in particolare i canali radio su cui sarà que monitorati da un terminale durante la ricezione
inviata la sessione e l’identificativo radio della ses- di una o più sessioni MBMS, in quanto, come detto
sione stessa. La rete può anche notificare ai termi- precedentemente, un tale terminale si trova in
nali la mancata allocazione di risorse radio per broadcast/multicast receive mode, un sotto-stato
quella sessione. del packet idle mode.
Sulle stesse risorse radio è possibile multiplare Nelle figure 12, 13, 14, 15 sono riportate le
più sessioni MBMS e sessioni punto-punto GPRS massime allocazioni di risorse radio per un MBMS
e/o EGPRS, ognuna di esse discriminata tramite un radio bearer nei casi specificati.
identificativo radio (quello già specificato a partire I due canali in uplink possono essere utilizzati
dalla R97 per le sessioni punto-punto ed il nuovo nel caso di ricezione di sessioni MBMS multiple in
identificativo introdotto per l’MBMS, che riutilizza modalità riscontrata a livello radio, per l’invio dei
in tutto o in parte il campo destinato all’identifica- rispettivi riscontri.
tivo radio di una sessione punto-punto). I blocchi radio relativi alla sessione MBMS sono
Se la modalità di trasmissione è quella riscon- trasmessi sulle risorse assegnate utilizzando gli
trata a livello radio, la rete assegna anche il canale schemi di (modulazione e) codifica già specificati
radio su cui i mobili trasmettono i riscontri; essa per il GPRS e per l’EGPRS, senza introdurre nuovi
assegna inoltre un identificativo specifico ad ogni schemi di codifica specifici dell’MBMS.
terminale, valido nell’ambito di quella specifica Come accennato precedentemente, un termi-
sessione in quella cella, tramite il quale la rete nale può ricevere più sessioni MBMS contempora-
richiede al terminale l’invio di riscontri sui blocchi neamente, purché l’allocazione delle risorse radio
radio ricevuti corretti e su quelli errati. per le diverse sessioni sia compatibile con le ‘radio
Il massimo numero di canali radio che possono access capabilities’ del terminale (p. es. il numero
essere assegnati all’interno di una trama TDMA per di canali radio che il terminale è in grado di gestire
l’invio di una sessione MBMS è pari a 4, numero contemporaneamente). Nel caso in cui ciò non sia
che può salire a 5, come eccezione, solo nel caso possibile, occorre che il mobile determini quali ses-
in cui il PBCCH sia allocato nella cella, si abbia un sioni ricevere e quali scartare: a tal fine, nel termi-
solo PCCCH allocato nella cella, ed il canale radio nale è associata una priorità per ogni servizio sot-
su cui sono mappati sia il PBCCH che il PCCCH è toscritto dall’utente.
contiguo agli altri canali radio allocati all’MBMS
radio bearer relativo a quella sessione ed utilizza gli 5.4 Gestione della mobilità
stessi parametri di frequenza. Nel caso di modalità
riscontrata a livello radio è anche allocato un Al fine di minimizzare le interruzioni del servizio
canale in uplink. Il terminale MBMS deve essere in dovute alla riselezione di cella, è stato introdotto
grado di ricevere fino a 5 canali radio (allocati in un meccanismo, denominato “Fast Reception
DL 0 1 2 3 4 5 6 7 DL 0 1 2 3 4 5 6 7
UL 5 6 7 0 1 2 3 4 UL 5 6 7 0 1 2 3 4
DL = DownLink DL = DownLink
UL = UpLink 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 0 1 2 3 4 5 6 7 DL 0 1 2 3 4 5 6 7
UL 5 6 7 0 1 2 3 4 UL 5 6 7 0 1 2 3 4
DL = DownLink DL = DownLink
UL = UpLink UL = UpLink
FIGURA 13› MBMS radio bearer senza canale di riscontro e con PBCCH. FIGURA 15› MBMS radio bearer con canale di riscontro e con PBCCH.

MBMS OK 17-05-2006 11:12 Pagina 61
Resumption”, in base al quale un terminale riceve sessione nella cella con l’eventuale possibilità
nella cella servente (prima di effettuare la risele- di pre-emption da parte di servizi a più alta
zione di cella) le informazioni, relative alla sessione priorità nella cella.
che sta ricevendo, che si riferiscono alle celle adia- Le diverse variabili rappresentano altrettanti
centi in cui è trasmessa la stessa sessione: le gradi di libertà e consentono alla rete di selezio-
informazioni includono, in particolare, l’identifica- nare per una specifica sessione la combinazione
tivo radio della sessione e l’allocazione dei canali più appropriata a seconda della cella considerata,
radio nelle celle adiacenti in cui la stessa sessione al fine di tentare di ottenere, a livello di implemen-
è trasmessa. tazione lato rete, una sorta di “loose synchronisa-
Se il terminale effettua una riselezione di cella tion” dei contenuti MBMS attraverso le diverse
verso una cella target per la quale ha ricevuto nella celle che costituiscono MBMS Service Area: l’o-
cella servente le informazioni relative alla sessione biettivo è quello di tentare di raggiungere il miglior
che sta ricevendo, è in grado di ripristinare imme- sincronismo possibile nell’invio dei contenuti
diatamente la ricezione della sessione (ed acquisire MBMS tra le diverse celle, al fine di massimizzare
contemporaneamente le informazioni di sistema sul la probabilità di fruizione, da parte degli utenti, di
canale di controllo broadcast); altrimenti, deve un servizio “senza soluzione di continuità” in cor-
prima acquisire le informazioni di sistema nella rispondenza dei cambi cella (a tal fine, la proce-
cella target e successivamente effettuare una pro- dura di “Fast Reception Resumption” minimizza i
cedura di accesso per richiedere la sessione nella tempi di interruzione del servizio in corrispon-
cella target. denza di un cambio cella, ma occorre altresì
È stata introdotta un’ulteriore ottimizzazione garantire che l’invio dei contenuti nella cella ser-
che consente, come scelta implementativa, di vente e nella cella target sia il più possibile sin-
gestire lato rete la priorità con cui vengono inviate crono per minimizzare le discontinuità nella rice-
nella cella servente le informazioni relative alla zione del servizio).
stessa sessione nelle celle adiacenti: la rete può A titolo puramente esemplificativo delle pre-
inviare prioritariamente le informazioni relative ad stazioni di throughput attese, nel caso della
una sessione per quelle celle adiacenti che sono modalità di trasmissione non riscontrata a livello
state indicate nei riscontri inviati dai terminali come radio, utilizzando il GPRS con lo schema di codi-
le migliori candidate ai fini di una riselezione di fica CS-3 e assumendo che la rete effettui due
cella o verso le quali sono state già decise delle ripetizioni (ovvero la prima trasmissione ed una
riselezioni di cella. Sempre come scelta implemen- ritrasmissione) per ogni blocco radio, su quattro
tativa, nelle suddette celle adiacenti la rete può canali radio si raggiunge un throughput di livello
instaurare un MBMS radio bearer relativo alla ses- 2 (RLC/MAC) pari a 28,8 kbit/s (assumendo che
sione, qualora non sia già presente, ed inviarne non vi siano altre sessioni MBMS o punto-punto
infomazione nella cella servente, per consentire ai multiplate sulle stesse risorse radio, che due
terminali di utilizzare la procedura di “Fast ripetizioni siano sufficienti per ricevere corretta-
Reception Resumption”. mente tutti i blocchi radio e non vi siano né inter-
ruzioni nella fruizione del servizio derivanti da
5.5 Valori di throughput ottenibili a livello radio riselezioni di cella, né riassegnazioni delle risorse
radio allocate con conseguente variazioni del
I valori di throughput attesi a livello radio non throughput); utilizzando l’EGPRS con MCS-6 e
sono univocamente definibili e dipendono da 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
diversi fattori quali: (RLC/MAC) raggiungibile a parità di condizioni è
• l’utilizzo del GPRS o dell’EGPRS; pari a 59,2 kbit/s. Pertanto, in prima approssima-
• lo schema di (modulazione e) codifica adottato; zione, si può stimare una distribuzione dei valori
• il numero di canali radio allocati per la sessione; di throughput di livello 2 per MBMS in GERAN
• il numero di ulteriori sessioni MBMS e/o ses- verosimilmente concentrata, anche se comunque
sioni punto-punto multiplate sulle stesse risorse non confinata, tra 30 kbit/s e 60 kbit/s.
radio allocate alla sessione;
• la modalità di trasmissione adottata (riscontrata
a livello radio o meno); 6. Accesso radio UTRAN
• il numero di utenti coinvolti nella ricezione della
sessione nel caso di trasmissione riscontrata a Il supporto di servizi MBMS in una rete di
livello radio; accesso UTRAN ha comportato una serie di
• le modalità di ritrasmissione dei blocchi radio; modifiche sostanziali nel modo di progettare e
• le condizioni radio nella cella (sia in termini di pianificare il sistema. Infatti l’accesso UTRAN,
livello di segnale ricevuto dal terminale che di originariamente progettato ed ottimizzato per i
rapporto segnale/interferente co-canale e da servizi PTP, è per di più basato su uno schema di
canale adiacente); accesso radio quale il WCDMA che dispone di
• il modello di mobilità del terminale; una serie di tecniche (link adaptation, ritrasmis-
• la possibilità o meno di effettuare la procedura sioni, controllo di potenza veloce e macrodiver-
di “Fast Reception Resumption” in corrispon- sità) che poco si prestano ad essere utilizzate in
denza di una riselezione di cella; modo efficiente per canali condivisi da più utenti
• l’eventuale riassegnazione di risorse radio per la simultaneamente.

MBMS OK 17-05-2006 11:12 Pagina 62
6.1 Bearer radio MBMS
Come schema di principio, i dati d’utente rela- UE UTRAN

tivi 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 1 • Notification for session start
trasporto comune di tipo FACH (figura 16).
2 • MBMS RB (MTCH, DTCH) establishment
MCCH- MTCH-
SAP SAP
MAC SAPs
3 • MBMS data transfer
FACH Transport Channel
FACH = Forward Access CHannel DTCH = Dedicated Traffic CHannel

MCCH = MBMS Control CHannel MBMS = Multimedia Broadcast Multicast Service
MTCH = MBMS Traffic CHannel MTCH = MBMS Traffic CHannel
SAP = Service Access Point RB = Radio Bearer
UE = User Equipment
UTRAN = UMTS Terrestrial Radio Access Network
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 All’atto della ricezione di un “MBMS SESSION
dati d’utente trasportato sul MTCH è regolata da START” (figura 18) da parte dell’SGSN, l’RNC, pre-
informazioni di controllo (figura 17) inviate periodi- dispone le risorse radio e di rete per il setup di un
camente sul canale MCCH (MBMS Control Radio Bearer MBMS e successivamente notifica ai
Channel) della cella sulla quale il mobile è accam- terminali la variazione delle informazioni sul MCCH
pato. Il terminale cha ha sottoscritto i servizi mediante MBMS Change information (che costitui-
MBMS, riceve sul canale MCCH: sce la cosiddetta “procedura di Notification”).
• l’elenco e lo scheduling temporale dei servizi Quando la sessione MBMS relativa ad un certo
trasmessi (MBMS Service Information); servizio è terminata (SESSION STOP) le informa-
• la configurazione radio dei vari Radio Bearer zioni di scheduling sul MCCH vengono modifi-
MBMS usati (Radio Bearer Information). cate, oppure, se non ci sono più servizi MBMS,
Per rendere più efficiente l’uso delle batterie, il viene completamente interrotta la trasmissione
terminale può sospendere la ricezione del MCCH del MCCH.
qualora le informazioni non varino per lunghi La ricezione MBMS sopra descritta può avve-
periodi, pertanto tali variazioni possono avvenire nire sia quando il terminale è in “Connected
soltanto in periodi ben prefissati (Modification Mode”, cioè quando ha una connessione RRC
Period), la cui durata può comunque essere confi- attiva, sia in “Idle Mode”. Questa seconda
gurata in rete. opzione è da preferirsi quando ad un certo servi-
zio 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 compor-
Modification period Modification period t e re b b e l ’ a t t i v a z i o n e d i
diversi contesti RRC
MCCH Repetition period nelL’RNC. In questo caso la
rete può decidere di tenere
la maggior parte dei termi-
nali in “Idle Mode”. È ovvio
Change information che ciò è possibile solo per
i terminali che hanno solo
MCCH = MBMS Control CHannel
servizi MBMS attivi, cioè
non hanno la necessità di
una connessione RRC per
FIGURA 17› Scheduling delle informazioni di controllo MCCH. altri servizi PTP (si veda il
paragrafo 6.5).

MBMS OK 17-05-2006 11:12 Pagina 63
6.2 P-t-M/P-t-P switching e Counting Per la trasmissione MBMS, quando questa

avviene su canali comuni, sul canale logico FACH
L’uso dei canali PTM comporta un certo trasmesso sul canale fisico S-CCPCH (Secondary -
impiego di risorse radio, più alto di quanto non Common Control Physical CHannel), è stato per-
richiedano invece pochi canali PTP (ad esempio tanto necessario compensare almeno in parte la
canali dedicati DCH oppure HSDPA). perdita di capacità aumentando l’efficienza di tra-
Pertanto è previsto nello standard che un Radio smissione a bordo cella, mediante l’introduzione di
Bearer MBMS possa essere configurato in moda- tecniche di macrodiversità simili a quelle utilizzate
lità radio PTP, utilizzando canali di trasporto DCH per i canali dedicati DCH.
oppure HS-DSCH (High Speed - Downlink Shared Per MBMS la rete trasmette simultaneamente
CHannel) per HSDPA. Questa possibilità di selezio- su tutte le celle di una certa area e i terminali che si
nare dinamicamente i tipi di canale si applica sol- trovano nella regione di bordo “combinano” spon-
tanto al Radio Bearer, cioè l’RNC decide la tipolo- taneamente il segnale preveniente da due o più
gia di canale di trasporto mentre l’Iu bearer tra celle realizzando così il cosiddetto “guadagno di
RNC e SGSN rimane invariata. macrodiversità”.
Come detto, l’utilizzo di uno a più canali PTP è Esistono due diverse tecniche di Combining:
giustificato solo al di sotto di un certo numero di • Selection combining: il terminale attiva due o
terminali presenti nella cella, per cui è necessario più catene di ricezione e di decodifica, una per
conoscere con un certo grado di approssimazione ogni cella, e successivamente seleziona il pac-
tale numero. Questa informazione non è disponibile chetto dati corretto da trasmettere all’applica-
all’RNC quando i terminali sono in idle mode ma zione;
può essere ottenuta tramite la procedura di • Soft combining: il terminale combina i segnali a
Counting. livello fisico, riuscendo quindi a massimizzare il
Data la finalità sopra descritta, la procedura di rapporto segnale/rumore, e poi effettua un solo
Counting non serve tanto a conoscere il numero processo di decodifica del pacchetto dati.
esatto di terminali nella cella che hanno richiesto Un'altra sostanziale differenza, rispetto ai canali
un dato servizio, quanto piuttosto per sapere se DCH, è data dall’uso di un tempo di interleaving
tale numero è superiore alla soglia per la quale (TTI - Transmission Timing Interval) più alto, pari a
viene attivato un canale condiviso. Perciò il coun- 40 o 80 ms, superiore rispetto ai normali 10 o 20
ting è fatto su base statistica e alla procedura di ms utilizzato per la trasmissione dati in Rel-99.
counting viene associato un “probability factor” Per dare un’idea della capacità di sistema per
con il quale il terminale deve rispondere con servizi MBMS, con e senza Combining, nella
segnalazione verso la rete e passare quindi in tabella 2 è indicata la percentuale di potenza di
stato “RRC connected”. cella da riservare per un canale MTCH/S-CCPCH a
In base alla stima del numero di terminali nella 64 kbit/s, nel caso di un bearer con qualità del ser-
cella e al fine di proteggere i canali di accesso vizio di tipo “streaming” (avente una BLER – BLock
(RACH) da un picco di risposta al counting, la Error Rate target pari all’1%). I valori riportati sono
rete può partire con un probability factor abba-
stanza basso ed eventualmente innalzarlo in pro-
cedure successive di counting finché non si
ottiene un numero statisticamente significativo di
risposte. TTI No Com (1 RL) SC (2 RL) SC (3 RL)
Qualora il canale configurato sia il PTM, la rete
può periodicamente eseguire un counting per veri-
Ambiente Indoor
ficare se durante la sessione il numero di utenti
per cella non sia ritornato, causa mobilità o per 40 ms - (*) 21.4% 14.8%
abbandono del servizio, sotto la soglia di attiva-
80 ms 61.7% 17.8% 13.2%
zione del canale PTP.
Ambiente Outdoor
6.3 Livello fisico e prestazioni di sistema
40 ms 28.8% 12.0% 10.2%
Come accennato in precedenza, l’interfaccia
80 ms 22.4% 11.2% 9.8%
radio dei sistemi radiomobili e in particolare quella
della dell’accesso UTRAN, si basa su meccanismi
* potenza di cella non sufficiente a fornire copertura a bordo cella.
di adattamento al canale radio (link adaptation)
quali Power Control e Adaptive Modulation and RL = Radio Link
Coding (AMC) che sono efficaci per collegamenti SC = Selective Combining
TTI = Transmission Timing Interval
punto-punto, in quanto le condizioni del canale
variano per ogni singolo terminale. L’utilizzo di
canali comuni, pertanto, determina un uso disotti-
mizzato delle risorse radio, e genera pertanto un TABELLA 2› Percentuale di potenza della cella necessaria per un canale
decremento di capacità, tanto maggiore quanto più MBMS streaming a 64 kbit/s al 95% della copertura in caso di Selective
grande è il bit-rate di riferimento target da garantire Combining.
a bordo cella.

MBMS OK 17-05-2006 11:12 Pagina 64
stati ottenuti in uno scenario di simulazione macro- renti, il terminale segue un criterio di priorità
cellulare, considerando due diversi modelli di pro- secondo le indicazioni dell’utente o dell’applica-
pagazione/mobilità, assimilabili a condizioni indoor zione.
e outdoor. Alla fine della sessione, tuttavia, i terminali
In caso di radio bearer a bit rate più elevata per resterebbero concentrati nel layer MBMS e questo
MBMS si può approssimativamente assumere che potrebbe creare problemi di sovraccarico in caso
la potenza di cella necessaria cresca linearmente di generazione del normale traffico punto-punto,
con l’incremento di bit rate e quindi, per un servi- per il quale molto probabilmente il layer non è
zio streaming a 128 kbit/s, è sufficiente raddop- dimensionato. Per questo motivo esiste il processo
piare le percentuali di potenza utilizzata riportate contrario detto “Frequency Layer Dispersion” per il
nelle tabelle 2 e 3. Da notare comunque che il bit quale il terminale riseleziona una cella diversa da
rate massimo supportato da un mobile MBMS è quella sulla quale è accampato alla fine della ses-
384 kbit/s, limite dettato dalle dimensioni della sione MBMS. Entrambe le procedure di cell rese-
memoria e dalla capacità di processamento del lection sono controllate dalla rete che indica sia il
terminale stesso. 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

TTI No Com (1 RL) SFC (2 RL) SFC (3 RL) livello fisico del terminale per processare il segnale
MBMS richiedono un sostanziale incremento di
TTI 22.4% 7.6% 4.8% memoria e capacità di processing rispetto ai termi-
nali di Release UMTS precedente, necessità
dovuta principalmente all’impiego di un TTI più
RL = Radio Link
SFC = SoFt Combining lungo e al numero di radio link da processare con-
TTI = Transmission Timing Interval temporaneamente a bordo cella in caso di
Combining. I mobili MBMS pertanto risultano com-
parabili, in termini di complessità tecnologica, a
TABELLA 3› Percentuale di potenza della cella necessaria per un canale terminali HSDPA di classe 3,6 Mbit/s, per un bit
MBMS streaming a 64 kbit/s al 95% della copertura in caso di Soft rate massimo di servizio che invece raggiunge i
Combining (ambiente outdoor). 384 kbit/s. Si osservi che per MBMS lo standard
non prevede l’esistenza di classi diverse di termi-
nali, il che evita di dover segregare le risorse di rete
Come limite massimo, puramente indicativo, di per le diverse tipologie di terminali e quindi ridurre
capacità di sistema per MBMS, supponendo di in parte il beneficio dell’uso di canali comuni.
voler riservare circa l’80% della potenza di por- Altro aspetto da tenere in considerazione è il
tante UMTS ai soli servizi MBMS (circa il 15-20% è supporto simultaneo di servizi MBMS (su canali S-
necessario per i canali comuni di segnalazione Rel- CCPCH) e servizi PTP (su DCH). Per questa combi-
99) si può affermare che è possibile attivare circa nazione, lo standard non stabilisce una capability
16 canali MBMS a 64 kbit/s. minima che il terminale deve obbligatoriamente
supportare e pertanto il supporto simultaneo di
6.4 Mobility e Frequency Layer Convergence questo tipo di servizi è opzionale nel terminale. Nel
caso in cui il terminale non avesse questa caratte-
La trasmissione di contenuto MBMS, una ristica, la fruizione dei servizi potrebbe essere limi-
volta superato il numero minimo di utenti per tata. Ad esempio se mentre l’utente è impegnato in
cella per cui diventa giustificabile l’uso di canali una sessione MBMS arriva una chiamata voce
PTM, richiede lo stesso impiego di risorse indi- oppure l’utente attiva una connessione dati, è
pendentemente dal traffico. In caso di coperture necessario rilasciare la connessione MBMS per
multilayer, pertanto, la possibilità di concentrare eventualmente riattivarla alla fine della chiamata
tutti gli utenti MBMS in unico layer non solo non punto-punto.
comporta particolari problemi di sovraccarico
per i canali MBMS, ma anzi è da perseguire in
quanto evita la trasmissione MBMS su tutti i 7. Conclusioni
layer di celle.
Per poter effettuare questo tipo di strategie è Nel corso dell’articolo si è presentato lo stan-
stato introdotto un meccanismo di “Frequency dard 3GPP relativo ad MBMS e si è potuto familia-
Layer Convergence”, per il quale il terminale, al rizzare con le modifiche necessarie all’architettura
momento dell’inizio della sessione oppure durante della rete radiomobile per poter offrire servizi punto
il cambio cella a causa della mobilità, seleziona la multipunto. A parte il nuovo nodo, BM-SC
cella che distribuisce il servizio o i servizi ai quali (Broadcast Multicast - Service Centre), per gli altri
l’utente è interessato. elementi della rete radiomobile (BSC/RNC, SGSN e
In caso di conflitto dovuto alla trasmissione GGSN) per il pieno supporto di MBMS è necessa-
contemporanea di due o più servizi su layer diffe- rio un aggiornamento del software.

MBMS OK 17-05-2006 11:12 Pagina 65
Come si è avuto modo di osservare, se con — ABBREVIAZIONI

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 2G Second Generation
download & play o di messaggistica di varia AMC Adaptive Modulation and Coding
natura. MBMS non è quindi assolutamente alter- ARP Allocation/Retention Priority
nativo al DVB-H, tecnologia principe per poter BM-SC Broadcast Multicast – Service Centre
offrire la televisione sul cellulare, anzi è ad esso BSC Base Station Controller
complementare. BSF Bootstrapping Server Function
Il successo o meno di MBMS sul mercato
BSS Base Station Sub-system
dipenderà fondamentalmente da quanti terminali
di Release 6 3GPP con MBMS saranno commer- CS Coding Scheme
cializzati nei prossimi anni. Attualmente infatti i DCH Dedicated Channel
produttori di terminali stanno decidendo se inse- DL Downlink
rirlo o meno nei mobili di Rel-6. Considerando la DTCH Dedicated Traffic CHannel
complessità realizzativa di MBMS e che oramai i DTM Dual Transfer Mode
cellulari di fascia medio alta di prossima commer- DVB-H Digital Video Broadcasting - Handheld
cializzazione saranno sempre più dispositivi multi-
EDGE Enhanced Data rates for Global Evolution
modo 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 EGPRS Enhanced GPRS
MBMS non risulta essere un’operazione economi- FACH Forward Access CHannel
camente trascurabile o alla portata di tutti i pro- FEC Forward Error Correction
duttori di chipset. FLUTE File Delivery over Unidirectional Transport
GBA Generic Bootstrapping Architecture
GERAN GSM/EDGE Radio Access Network
GPRS General Packet Radio Service
GSM Global System for Mobile communications
GTP GPRS Tunneling Protocol
HPLMN Home Public Land Mobile Network
HSDPA High Speed Downlink Packet Access
HS-DSCH High Speed Downlink Shared CHannel
HSS Home Subscriber Server
HTTP Hypertext Transfer Protocol
— BIBLIOGRAFIA IGMP Internet Group Management Protocol
IMSI International Mobile Subscriber Identity
MAC Medium Access Control
[1] 3GPP Technical Specification 23.246: “Multimedia MBMS Multimedia Broadcast Multicast Service
Broadcast Multicast Service; Architecture and MCCH MBMS Control Channel
Functional Description (Stage-2)”. MCS Modulation & Coding Scheme
[2] 3GPP Technical Specification 25.346: “Introduction MLD Multicast Listener Discovery
of the Multimedia Broadcast Multicast Service MMS Multimedia Messaging Service
(MBMS) in the Radio Access Network (RAN) MSC Mobile Switching Centre
MSK MBMS Service Key
(Stage-2)”
MTCH MBMS Traffic Channel
[3] 3GPP Technical Specification 25.992: “Multimedia MTK MBMS Traffic Key
Broadcast Multicast Service (MBMS); MUK MBMS User Key
UTRAN/GERAN Requirements”. NAF Network Application Function
[4] 3GPP Technical Specification 33.246: “3G Security; PBCCH Packet Broadcast Control Channel
Security of Multimedia Broadcast/Multicast Service PCCCH Packet Common Control Channel
(MBMS)”. PS Packet Switched
PSS Packet Switched Streaming
[5] 3GPP Technical Specification 43.246: “Multimedia PTM Point To Multipoint
Broadcast Multicast Service (MBMS) in the GERAN; PTP Point To Point
Stage 2”. RAN Radio Access Network
RB Radio Bearer
RRC Radio Resource Control

MBMS OK 17-05-2006 11:12 Pagina 66
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 d’utente.
La sua attività si è inizialmente concentrata
RL Radio Link nei campi della codifica audiovisiva, con
RLC Radio Link Control particolare riferimento alla definizione della
RNC Radio Network Controller codifica audio per i sistemi mobili e della
valutazione oggettiva e soggettiva della
RTP Real-Time Protocol qualità nei servizi di telefonia. Dal 1987 al 1991, ha partecipato
SAP Service Access Point alla progettazione e definizione dei sistemi di codifica GSM Full-
Rate e Half-Rate. È detentore di brevetti internazionali nel campo
SC Selective Combining della codifica audio e coautore del libro “Speech And Audio
S-CCPCH Secondary Common Control Physical Coding For W ireless And Network Applications”, Kluwer
Academic Publishers, USA, 1993. Successivamente ha
Channel ricoperto la carica di Rapporteur in ITU-T Study Group 16 per la
SFC SoFt Combining tematica “Audio and wideband coding” ed è attualmente
delegato Telecom Italia in 3GPP SA4 (Codec).
SGSN Serving GPRS Support Node
SRTP Secure Real-Time Protocol
TCP Transmission Control Protocol Maria Pia Galante si laurea nel 1998
TDMA Time Division Multiple Access in Ingegneria Elettronica presso il Politecnico
di Torino, sviluppando la tesi in Telecom Italia
TMGI Temporary Mobile Group Identity Lab (già CSELT) presso il dipartimento di
TPF Traffic Plane Function Microonde. Nel 1998 è assunta in TILAB
presso il dipartimento di Architetture di Rete
TTI Transmission Timing Interval per Ser vizi Mobili, dove si occupa di
UDP User Datagram Protocol tecnologie ad Agenti Mobili per il controllo dei
UE User Equipment servizi in reti di terza generazione. Dal 1999 al
2002 partecipa per TIM ai lavori del consorzio
UL Uplink 3G.IP sull’evoluzione “All IP” della rete GSM/UMTS. Da maggio
URI Uniform Resource Identifier del 2000 partecipa per TIM al 3GPP SA WG2, comitato che
definisce le specifiche di architettura per il sistema GSM/UMTS.
UTRAN UMTS Terrestrial Radio Access Network 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 G i a n l u c a G r e c o si è laureato con

Ingegneria Elettronica presso l’Università di 110/110 nel 1997 in Ingegneria Elettronica
Bologna. Nell’ottobre 1997 entra in TILAB (già all’Università degli Studi Roma “La Sapienza”.
CSELT) presso il dipartimento di Servizi e Tra la fine del 1998 ed i primi mesi del 1999
Sistemi Mobili e Radio. Dal 1998 partecipa ai ha frequentato l’Istituto Superiore di
gruppi ETSI DECT-R (standard DECT) e SMG- Comunicazioni e delle Tecnologie
2 (Interfaccia radio GSM/GPRS, ora in 3GPP dell’Informazione presso il Ministero delle
GERAN). Prende parte ad attività di Comunicazioni. Dal marzo del 1999 lavora nel
consulenza per i piani di innovazione settore Tecnologie ed Industrializzazione della
tecnologica delle consociate estere del funzione Access Network della Direzione Rete
Gruppo Telecom Italia. Si occupa di aspetti di pianificazione e di TIM, dove si occupa di tecnologie e di architetture per la rete di
gestione delle risorse radio e progettazione e sviluppo di tool di accesso radio 2G e 3G seguendo gli aspetti di evoluzione dei
simulazione. Dal novembre 1999 partecipa per Telecom Italia al principali fornitori tecnologici di TIM. Dai primi del 2003
3GPP RAN WG2, che definisce le specifiche di interfaccia radio rappresenta Telecom Italia nel gruppo di lavoro internazionale
per il sistema UMTS. È editor del documento di specifica 3GPP 3GPP GERAN responsabile delle specifiche tecniche del sistema
TR 25.922 “RRM Strategies” che descrive le strategie di gestione GSM/GPRS/EDGE.
e ottimizzazione delle risorse radio dell’UMTS.
Mauro Castagno si laurea nel 1993 in D a v i d e S o r b a r a si è laureato in

Ingegneria Elettronica presso il Politecnico di Ingegneria Elettronica (con lode) presso il
Torino. Dopo uno stage presso CSELT, nel Politecnico di Torino nel 1990, anno in cui è
1995 è assunto presso OMNITEL Pronto Italia stato assunto in CSELT, ora Telecom Italia. La
(oggi Vodafone Italia), dipartimento Network sua attività di ricerca si è focalizzata sui sistemi
Planning e partecipa alla fase di start up della radiomobili, quali GSM, TETRA, DECT, GPRS,
rete, occupandosi di testing e di aspetti di EDGE e GERAN. È stato coinvolto nella
Sicurezza del sistema GSM. Partecipa inoltre definizione di molteplici studi di fattibilità e
al gruppo di standardizzazione GSM “ETSI nell’analisi delle prestazioni radio di questi
SMG 10” (Security aspects). Nel 2000 è sistemi, anche tramite lo sviluppo di simulatori
assunto presso CSELT, oggi TOLAB, dove lavora nell’ambito della software. I risultati provenienti da questa attività sono stati utilizzati
tecnologia radiomobile. Per un breve periodo si occupa di aspetti dai gruppi di standardizzazione all’interno dell’ETSI, per la
di Pianificazione Strategica, prestando supporto a Telestet definizione delle specifiche radio di alcuni dei sistemi citati. Dal
(Grecia). Dal 2002, oltre ad essere coinvolto su progetti di 1995 al 1997 ha contribuito alla definizione delle specifiche radio
interesse TIM, rappresenta Telecom Italia nel gruppo di lavoro del GPRS (Release 97). Dal 2004 è delegato di Telecom Italia. nei
internazionale 3GPP SA WG3, che si occupa degli aspetti di gruppi 3GPP GERAN, GERAN1 e GERAN2, in cui ha contribuito in
sicurezza del sistema 3GPP. maniera determinante, essenziale e risolutiva alla standardizzazione
dell’MBMS nell’ambito 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”.

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 N. 1 - Giugno 2006 - MBMS-1-2006 PDF

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

NOTIZIARIO TECNICO TELECOM ITALIA Anno 15 N. 1 - Giugno 2006 - MBMS-1-2006 PDF

Caricato da

Copyright:

Formati disponibili

MBMS OK 17-05-2006 11:12 Pagina 49

MBMS: la nuova frontiera del

1. Introduzione • l’accesso UTRAN e GERAN (WG RAN e WG

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

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

2.2 Modalità Multicast e Broadcast

La diffe re nza so stan zi al e tra Mu l ti cast e

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

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

Al termine di tali procedure, il

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

Le procedure di Inter/Intra SGSN RAU sono 3.1 Procedura di Autenticazione MBMS

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

BSF = Bootstrapping Server Function

BM-SC = Broadcast Multicast-Service Centre

3.2 Protezione del contenuto trasmesso

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

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

In generale, la tariffazione equa ed affidabile 4.1 Codifica di sorgente

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

della “feedback implosion”, cioè un grande numero 4.3 Schema FEC

Sessione PtM originaria 4.4 Protocolli per il trasporto dei media

5.1 Notifica ai terminali dell’inizio di una sessione

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

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

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

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

6.1 Bearer radio MBMS

Come schema di principio, i dati d’utente rela- UE UTRAN

2 • MBMS RB (MTCH, DTCH) establishment

3 • MBMS data transfer

FACH Transport Channel

FACH = Forward Access CHannel DTCH = Dedicated Traffic CHannel

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

6.2 P-t-M/P-t-P switching e Counting Per la trasmissione MBMS, quando questa

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

6.5 UE radio access capability

Come descritto in precedenza, le operazioni di

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

Come si è avuto modo di osservare, se con — ABBREVIAZIONI

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

Rosario Drogo De Iacovo si è

Andrea Buldorini si laurea nel 1996 in G i a n l u c a G r e c o si è laureato con

Mauro Castagno si laurea nel 1993 in D a v i d e S o r b a r a si è laureato in

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

Potrebbero piacerti anche