Evoluzione della Core Network UMTS a Circuito

STANDARD Evoluzione della Core Network UMTS a Circuito PAOLO BELLONI DANIELE CECCARELLI MAURIZIO DE GREGORIO L articolo si propone di trattare l evoluzione delle funzionalità della core network UMTS nel dominio a commutazione di circuito, così come viene definito nei nuovi rilasci dello Standard 3GPP. Sono quindi descritte le prestazioni di maggior rilievo che caratterizzeranno i nuovi rilasci le cui applicazioni commerciali sono previste nell arco dei prossimi tre anni. 1. Introduzione 2. Architettura Split Le nuove release dello standard 3GPP prevedono una nuova architettura e l introduzione in Core Network di nuove funzionalità; la nuova architettura in configurazione split separa il piano di controllo da quello di trasporto ed abilita il trasporto della voce e della segnalazione su rete di trasporto a pacchetto; tra le funzionalità più interessanti e di maggior impatto si annoverano: Dual Access, una modalità con cui è possibile gestire accessi radio GSM e WCDMA (Wideband Code Division Multiple Access) con gli stessi apparati di core network; gli () in pool, un nuovo modello architetturale con cui è possibile usare al meglio le risorse e aumentare l'affidabilità della rete; la TFO/TrFO (Tandem Free/Transcoder Free Operation) una prestazione che permette di ottimizzare il trasporto e migliorare la qualità del servizio voce; i nuovi scenari di fallback delle videochiamate, nuove procedure con cui si potrà alternare il servizio voce o video sia per problemi di copertura 3G, sia per volere dell utente. Lo standard 3GPP, a partire dalla Release 4 (da qui in avanti Rel.4), introduce nel dominio CS (Circuit Switching) della rete UMTS la separazione tra il piano di utente ed il piano di controllo. Tale architettura di rete si realizza con la configurazione Split o Layered in sostituzione di quella Combined, con riferimento alle funzionalità di Server e (Media GateWay) del nodo /VLR. La Rel.4 3GPP prevede infatti la possibilità di realizzare il piano di controllo ed il piano d utente del dominio CS in due nodi distinti. Fino ad ora infatti entrambe le funzionalità sono state realizzate nello stesso elemento fisico, ovvero la centrale /VLR. L architettura della rete UMTS prevede la connessione dell UT (UMTS Terrestrial Radio Access Network) con la Core Network tramite l interfaccia Iu, suddivisa in Iu CS e Iu PS, rispettivamente per il dominio a circuito e a pacchetto. Nella architettura di Rel.4 Circuit Switching lo strato di controllo è realizzato nel nodo Server sul quale termina l interfaccia Iu CS Control plane, mentre il piano d utente è gestito dal nodo Media Gateway, sul quale termina la Iu CS User Plane. NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 1 - Giugno 2005 113

Nella nuova architettura il Server diviene quindi il nodo di rete che gestisce tutto il piano di segnalazione, in particolare quindi nel Server si realizzano il Session Management ed il Mobility Management. Le informazioni relative alla gestione della mobilità, alla gestione della chiamata e alla instaurazione dei RAB (Radio Access Bearer) vengono elaborate e controllate direttamente dalla centrale Server, che gestisce ovviamente anche il database VLR per i record di utente. Lo standard prevede una nuova interfaccia per il dialogo tra i nodi Server, l interfaccia Nc. Il protocollo previsto per questa interfaccia è il BICC (Bearer Independent Call Control) o ISUP (ISDN User Part). Per un approfondimento sul protocollo BICC si veda il relativo riquadro. La Rel.4 3GPP definisce anche una nuova interfaccia standard per il dialogo tra Server e. Tale interfaccia, denominata Mc, viene utilizzata dal Server per inviare i comandi necessari alla configu- Il protocollo BICC Facendo riferimento alla figura A, il protocollo BICC (Bearer Independent Call Control) è utilizzato per lo scambio di informazioni per il set-up della chiamata tra gli -Server: può trasportare, indipendentemente dal trasporto sottostante, le informazioni circa le caratteristiche del servizio richiesto dall utente, l identificativo del chiamato (da cui le informazioni di instradamento) e le informazioni sui codec supportati. Il ha invece il compito di instaurare le connessione nel piano d utente e di attivare la commutazione: ovviamente questo non può avvenire in maniera transport-agnostic (indipendente dal tipo di rete di trasporto: TDM,, IP) e quindi riceve le necessarie informazioni dal -Server, le converte in informazioni per il controllo dello specifico bearer e si occupa della gestione dello stesso. La figura A mostra le funzionalità di BICC definite dall architettura ITU-T e la loro collocazione all interno dell architettura 3GPP di Rel.4. La CSF (Call Serving Function) coincide con l -Server e parla in BICC con gli altri -Server. Il dialogo tra - Server e, o tra CSF e BCF (Bearer Control Function), avviene con protocollo H.248, definito congiuntamente da ITU-T e IETF per il comando, da parte del -Server, della commutazione di terminazioni sul. Il piano d utente è terminato dalla MMSF (Media Mapping and Switching Function). Si noti come sia prevista anche una segnalazione peer-to-peer tra i BCF per il controllo del piano di trasporto, denominata Bearer Control Protocol che avviene in modalità diversa nel caso di trasporto o di trasporto IP. Nel caso di trasporto si utilizza la segnalazione Broadband-ISUP B-ISUP gia definita da ITU-T per allocare le risorse del canale dedicato necessario alla chiamata; in particolare il protocollo AAL2 Connection Signalling è utilizzato per stabilire le connessioni con un meccanismo analogo a quello dell commutata (figura B). In un contesto IP, nativamente di tipo connection less, le informazioni relative alle risorse necessarie per stabilire un canale bidirezionale BCF BICC CSF MCF MMSF AAL2 connection signalling (Q.2630.2) AAL2 Signalling Transport Converter for MTP3b (Q.2150.1) AAL2 AAL5 NNI SSCF SSCOP MTP3b SSCF-NNI SSCOP AAL5 Adaptation Layer 2 Adaptation Layer 5 Asynchronous Transfer Mode Network-Network Interface Service Specific Coordinator Function Service Specific Connection Oriented Protocol CSF BCF MCF MMSF Physical unit FIGURA B Il protocollo AAL2 Connection Signalling. H.248 server Function Bearer Control Function Bearer Independent Call Control Call Serving Function Media Control Function Media GateWay Media Mapping/Switching Function FIGURA A Modello architetturale di BICC ITU-T e corrispondenza con quello 3GPP. BICC Bearer Control Protocol Bearer (User Plane) end to end vengono identificate mediante lo scambio fra i nodi di origine e di destinazione degli indirizzi IP delle porte e del tipo di media richiesto. Queste informazioni sono trasportate in formato SDP (Session Description Protocol) e vengono scambiate trasparentemente tra i due MMSF dal protocollo H.248 e dal protocollo BICC. 114 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 1 - Giugno 2005

razione dei device di commutazione sul Media Gateway. Il compito di quest ultimo è infatti proprio quello di connettere porte di ingresso e di uscita, sulle quali si possono utilizzare differenti tecnologie di trasporto, IP e TDM (Time Division Multiplex). L interfaccia Mc viene inoltre utilizzata dal per fornire dei riscontri o eventi al Server. Il protocollo utilizzato su questa interfaccia è H.248. Il nodo Media Gateway invece realizza la parte di trasporto e di commutazione. Il piano di utente passa infatti attraverso quest ultimo, connettendo da un lato la rete di accesso e dall altro la Core Network. Il nodo realizza sia la commutazione dei canali voce, video e dati CS, sia l adattamento delle codifiche impiegate in accesso ed in core network. La funzionalità di transcodifica, realizzata nella rete GSM dalle unità TRAU (Transcoder and Rate Adaptor Unit) presenti generalmente sui BSC, nell architettura 3GPP Rel.4 viene realizzata direttamente sul. Il TRAU può anche essere localizzato sia in BSC sia in. Lo standard prevede una nuova interfaccia Nb anche per il dialogo tra i nodi. Le tecnologie impiegate per l interfaccia Nb sono ed IP, oltre al TDM per assicurare compatibilità con le esistenti Core Network. L architettura Split rende indipendenti i piani di segnalazione e di trasporto, consentendo uno sviluppo separato dei due nodi in accordo agli effettivi requisiti di banda e di connessione. Con tale soluzione si possono avere più centrali controllate da un numero inferiore di centrali Server. In questo modo è possibile migrare, tramite remoti, le funzioni di commutazione verso la rete di accesso, effettuando lo switching locale senza occupare risorse di trasporto di rete. Nella figura 1 sono riportate anche le interfacce Nc e Nb come da specifiche della Segnalazioni Rel.4. Nelle prime realizzazioni Fonia tali interfacce utilizzano la tecnologia di trasporto TDM. 3. Dual Access La configurazione Dual Access prevede che gli accessi radio 2G e 3G siano contemporaneamente connessi al medesimo nodo /VLR, ottimizzando il concetto di seamless network che prevede completa trasparenza per il cliente tra l utilizzo delle risorse 2G e 3G. La configurazione Dual Access offre inoltre interessanti vantaggi nella gestione del roaming e nelle procedure di gestione della mobilità. UT B B lub AuC BICC CP CS GCP GSM HLR lu CS CP lu CS UP In generale infatti, gli accordi esistenti per l accesso al roaming da parte di utenti visitor non è lo stesso per le utenze 2G o 3G. Ciò implica che il nodo deve comunque essere in grado di gestire la mobilità 2G/3G dell utente impedendo che lo stesso possa connettersi all accesso radio non consentito dagli accordi commerciali. Per quanto riguarda la mobilità invece, la possibilità di gestire il passaggio da una copertura 3G ad una copertura 2G, e viceversa rimanendo nell ambito della stessa centrale, comporta un ottimizzazione delle risorse di segnalazione di rete. Nell ipotesi di impianti distinti, il passaggio tra gli accessi UMTS e GSM comporta, infatti, sempre uno scambio di segnalazione tra /VLR ed il database di HLR, per l aggiornamento della posizione dell utente in rete. La possibilità di avere attestate in un unica centrale le due tipologie di accesso consente di: abilitare la gestione separata dei due accessi radio per l utenza in roaming assegnando valori di location area distinti a celle 2G e celle 3G; effettuare contestualmente una gestione della mobilità più efficiente in termini di risorse di segnalazione rispetto a quella che si ottiene con impianti dedicati per accesso. La presenza di un unico VLR per la gestione di Location Area 2G e 3G consente un notevole risparmio di segnalazione nel passaggio tra le due reti. Infatti, se si pensa alla copertura iniziale delle reti 3G, tale scenario si potrebbe presentare maggiormente nelle prime fasi di lancio del servizio. Server Mc HLR/ AuC GCP/ HLR/ AuC /IP TDM HLR/ AuC ISUP/BICC Nb Core Network UMTS Asynchronous Transfer Mode Authentication Centre Bearer Independent Call Control Control Plane Circuit Switched Gateway Control Protocol Global System for Mobile communications Home Location Register FIGURA 1 Relazioni tra Server e Media GateWay. D Nc Transito G Mc ISUP OLO PSTN TDM UP Server GSM / PSTN / OLO lu CS UT B B lub ISDN Signalling User Part Media GateWay Other Licensed Operator Public Switched Telephone Network Radio Network Controller Time Division Multiplex User Plane NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 1 - Giugno 2005 115

La scelta di utilizzare per le location area 3G e quelle confinanti 2G il medesimo impianto /VLR minimizza gli impatti dovuti alle differenti aree di copertura delle due tecnologie. In questo scenario tecnologico l aggiornamento della posizione effettuata nel passaggio tra le due reti comporta infatti solo lo scambio di segnalazione sulla interfacce tra terminale e /VLR, senza alcun impatto per la core network e per le interfacce di segnalazione del database di HLR. 4. in Pool In un ottica di ottimizzazione dell uso delle risorse di rete, a partire dalla Rel.5 è stata definita dal 3GPP la funzionalità di Intra-domain connection of Radio Access Network () to multiple Core Network (CN) s, denominata più semplicemente in pool. Originariamente la prestazione è stata pensata dal 3GPP per il load sharing del traffico d utente tramite il re-indirizzamento della segnalazione di Communication Management CM, ma dal punto di vista dell operatore ciò può rappresentare anche un ottimo strumento per rendere più affidabile la rete che la implementa. In particolare, la funzionalità prevede una modifica dell architettura della rete mobile che normalmente vede un nodo di rete d accesso radio connesso con un solo nodo di controllo della Core Network. La funzionalità è definita per GSM, GPRS, CS domain e PS domain; di seguito per comodità si farà riferimento al dominio a circuito. CS poolarea 1 Area 1 Area 5 PS poolarea 1 1 Area 2 Area 6 CS poolarea 2 SGSN 1 SGSN 3 SGSN 6 SGSN 2 SGSN 4 SGSN 5 CS PS SGSN 3 2 Circuit Switched Radio Access Network Packet Switched Serving GPRS Support Node 6 5 4 7 Area 3 Area 7 PS pool-area 2 FIGURA 2 Architettura di rete che implementa in pool. Area 4 Area 8 Nel caso di pooling di, un può essere connesso a più, come mostrato nella figura 2. A fronte di questa modifica architetturale, l in pool prevede una nuova funzionalità in, detta NAS (Non Access Stratum) Selector che, all atto della registrazione dell utente mobile, associa al terminale un nodo di controllo (associazione che era implicita nel caso di corrispondenza uno a uno tra e ). Questa associazione è effettuata sulla base di un parametro di NRI (Network Resource Identifier) a livello RRC (Radio Resources Control). La pool area diventa, quindi, un insieme di celle controllate da più ciascuno dei quali deve essere connesso a tutti gli che gestiscono l insieme delle celle del pool. Questo pone un vincolo sulle dimensioni del pool perchè pool con troppi richiederebbero un numero di link troppo elevato. Inoltre, per limitare questo numero, la funzionalità prevede che un utente che si sposti all interno delle celle del pool non effettui le relative procedure di Mobility Management, con conseguente riduzione del traffico di segnalazione. Si capisce come risulti critica, allora, la scelta delle dimensioni del pool per trovare il giusto compromesso tra costi e benefici. 5. Trasporto a pacchetto Il 3GPP non impone vincoli sul modo di trasportare l informazione nella Core Network della rete UMTS ma, anzi, lascia un estrema flessibilità all operatore includendo nello standard diverse opzioni. Le tradizionali reti a circuito legacy PSTN/ISDN ed il GSM sono basate sul trasporto TDM che utilizza una soluzione per il piano di trasporto creata per le reti dedicate all erogazione del servizio telefonico. 5.1 Trasporto del piano di utente La voce in UMTS oltre che con la classica modalità TDM, può essere trasportata su e su IP. L è stato incluso nello standard perchè all inizio dei lavori in sede di standardizzazione era la migliore tecnologia disponibile per l ottimizzazione delle risorse di trasporto. Il trasporto della voce su IP rispetta gli standard per i bassi costi e la semplicità tipiche del mondo Internet. Oggi l IP sul piano d utente a circuito è spinto anche dal fatto che il protocollo IP è la chiave per fornire servizi multimediali complessi tramite IP Multimedia SubSystem, che è il cuore della Rel.5 e che, tra l altro, è interamente basato su IPv6; inoltre su IP si fondano le attuali tendenze evolutive del 3G verso il 4G. Facendo riferimento all architettura di Rel.4 di cui si parla nel paragrafo 2, le pile protocollari previste sull interfaccia Nb tra i MGw per il trasporto della voce in Core Network sono riportate nella tabella 1. 116 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 1 - Giugno 2005

Nel caso di trasporto della voce su, le dimensioni di una cella permettono di multiplare in una stessa i campioni provenienti da più telefonate: questo è realizzato dal protocollo AAL2 ( Adaptation Layer 2), che definisce opportuni identificativi per distinguere dentro la singola cella le diverse telefonate. Invece AAL2-Segmentation and Reassembly Service Specific Convergence Sublayer (SAR SSCS) si occupa della segmentazione e del riassemblaggio dei pacchetti AAL2. Quando invece il trasporto è in tecnologia IP, si utilizza il Real Time Protocol che rende UDP/IP, tipico per applicazioni best effort, adatto a trasportare applicazioni di tipo real-time quale la voce. 5.2 Trasporto del piano di controllo Per gestire questa flessibilità nel modo di trasportare la voce, il 3GPP ha scelto un protocollo di CC (Call Controll) tra i nodi di controllo che fosse indipendente dal tipo di trasporto utilizzato. Come ricordato nel paragrafo 2, si parla di architettura che rispetta il requisito di bearer independence, a differenza di quanto avviene con l ISUP delle reti legacy. Infatti, l ISUP ha il campo di CIC (Circuit Identification Code) che stabilisce un legame preciso tra la segnalazione e il canale a 64 kbit/s della trama PCM. Nell architettura split dalla Rel.4 in poi si usa come protocollo tra gli -Server sull interfaccia Nc il BICC. Il 3GPP ha ereditato il protocollo BICC da ITU- T, che lo ha definito con lo scopo di creare un protocollo per il controllo di chiamata che fosse indipendente dalla tecnologia di trasporto utilizzata; in quest ottica ITU-T ha analizzato il protocollo ISUP e ne ha esteso le funzionalità per prevedere il trasporto della voce su e IP. In particolare, la breve storia della standardizzazione del BICC si è sviluppata attraverso le seguenti tappe: 1999, BICC CS-1 (Capability Set 1): bearer AAL2 IPv4 RTP SAR SSCS UDP AAL-2 SAR SSCS AAL-2 Adaptation Layer 2 Asynchronous Transfer Mode Internet Protocol v4 Real Time Protocol Segmentation and Reassembly Service Specific Convergence Sublayer User Datagram Protocol TABELLA 1 Pile protocollari sull interfaccia Nb. RTP UDP IPv4 o IPv6 independent architecture e adattamento di ISUP per trasporto sul piano d utente; 2000, BICC CS-2: supporto di IP come protocollo di trasporto sul piano d utente (compresa la definizione di BICC IP BCP e BICC tunneling protocol); 2001, BICC CS-3: supporto di multimedia communication, QoS e interworking con H.323/SIP. 6. Ottimizzazione del trasporto e qualità della voce Lo standard 3GPP ha definito per la rete UMTS (dalla Rel. 4) e per quella GSM (dalla Rel. 98) alcuni meccanismi che permettono sia di migliorare la qualità percepita per una chiamata in fonia, che di ottenere contestualmente dei risparmi di banda occupata nella Core Network. Entrambe le soluzioni utilizzano la proprietà di trasmettere trame vocali senza eseguire operazioni di codifica/decodifica delle stesse nella Core Network. Tali meccanismi si suddividono in: TFO (Tandem Free Operation), la cui applicazione consente di evitare le operazioni di codifica e decodifica in rete, con conseguente miglioramento della qualità percepita end to end; OoBTC (Out of Band Transcoder Control), abilitante: - TrFO (Transcoder Free Operation), che consente sia di risparmiare la transcodifica con miglioramento della qualità voce end to end, sia di guadagnare banda in core network. - Codec at the edge, caso particolare di TrFO, che consente di mantenere in CN, quanto più possibile, la banda voce ad un basso bit rate prima di effettuare la transcodifica ad un bit rate più alto. 6.1 TFO (Tandem Free Operation) Il Tandem Free Operation si applica in scenari di chiamata 2G-2G, 3G-3G e 2G-3G dove sono coinvolte tratte nelle quali si utilizza la codifica PCM a 64 kbit/s. L attivazione della funzionalità consente di evitare la doppia codifica/decodifica PCM preservando, in modalità compressa, la banda che proviene dalla rete di accesso, e trasportando tale flusso in modo trasparente nel canale PCM a 64 kbit/s. In questo modo vengono risparmiati due passaggi di transcodifica, quello da banda compressa a PCM, e quello da PCM a banda compressa. Il mancato impiego dei transcoder consente di ridurre il tempo di elaborazione del segnale in rete con conseguente diminuzione del ritardo introdotto end to end; ciò permette quindi di offrire una migliore qualità del segnale vocale. Il TFO è standardizzato in GSM a partire dalla Rel.98; per UMTS è definito a partire dalla Rel.4. La modalità di TFO viene attivata in una fase successiva a quella di set up della chiamata a valle della quale i transcoder impiegati si scambiano NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 1 - Giugno 2005 117

trame PCM a 64 Kbit/s, cioè un campione di voce codificato con 8 bit ogni 125 µs. Nel momento in cui uno dei due transcoder tenta di attivare il Tandem Free Operation, inizia a scambiare segnalazione in banda con l altro transcoder. Lo scambio di segnalazione ha lo scopo di comunicare all altro transcoder la volontà di passare in modalità TFO, e quindi di comunicare quale codificatore impiegare nella connessione in corso. Se i due transcoder stanno impiegando una codifica comune o compatibile, si attiverà la modalità TFO. In mancanza di un codec comune, è possibile continuare in modalità normale utilizzando la transcodifica, oppure, mediante procedura di Codec Mismatch Resolution, tentare di negoziare un codec comune tramite lo scambio delle liste dei codec supportati. Quando la modalità TFO è attiva, le trame vocali vengono trasmesse utilizzando alcuni degli 8 bit disponibili del campione PCM, in funzione del bit rate associato al codec comune utilizzato. I due transcoder non devono più effettuare quindi operazioni di transcodifica, anche se la banda impegnata in rete tra questi ultimi rimane sempre di 64 kbit/s (8 bit utilizzabili per payload e riempimento ogni 125 µs). La modalità di TFO consente quindi di migliorare la qualità vocale senza offrire un risparmio di banda utilizzata (figura 3). 6.2 OoBTC (Out of Band Transcoder Control) Il meccanismo di Out of Band Transcoder Control, contrariamente al TFO, consente di negoziare già nella fase di instaurazione della chiamata, con segnalazione fuori banda, un unica codifica che permetta di non utilizzare la transcodifica in O- Transit T- O- Codec list (v,w,x,y,z) Selected codec x Selected codec x, available list (v,x,z,) Codec list (v,w,x,z) Selected codec x Bearer established Media GateWay OT Orinating Terminating Transit Bearer established T- Selected codec x, available list (v,x,z,) Selected codec x FIGURA 4 Modalità di funzionamento di OoBTC (Out of Band Transcoder Control) per la negoziazione dei codec. MS BSC BTS MS TRAU BTS BSC Abis A A Abis TRAU TRAU Campioni PCM 64 kbit/s contenenti frame TFO nei bit meno significativi: - bit di controllo - campioni voce compressi Base Station Controller Base Transceiver Station Mobile Station Transcoder and Rate Adaptor Unit BSC BTS FIGURA 3 TFO (Tandem Free Operation) applicato ad uno scenario 2G-3G. rete e di risparmiare, nello stesso tempo, banda di trasmissione. Lo standard prevede comunque la possibilità di modificare il codec selezionato anche nella fase attiva della chiamata in qualsiasi momento, ad esempio dopo un handover. Gli scenari di chiamata a cui si applica l OoBTC sono gli stessi del TFO, a cui si aggiunge lo scenario di chiamata tra rete mobile e rete fissa. L OoBTC è definito nello standard 3GPP a partire dalla Rel.4. La modalità di funzionamento dell OoBTC può essere compresa facendo riferimento alla figura 4. La centrale di origine O- invia in segnalazione, verso i nodi successivi, la lista dei codec supportati, elencati per ordine di preferenza. Ogni nodo di transito analizza la lista ed elimina da quest ultima i codec non supportati, senza alterare l ordine di preferenza. Nell esempio della figura 4, la centrale di Transito elimina dalla lista il codec y in quanto non disponibile nella stessa. Tale analisi viene svolta da tutti i nodi di transito fino a raggiungere la centrale di terminazione T-. Quest ultima seleziona il primo codec supportato della lista di quelli supportati da tutti i nodi coinvolti nella chiamata. Una volta selezionato, invia a ritroso tale informazione con la lista contenente i codec alternativi ma non selezionati. Nel caso raffigurato nella figura 4 il codec selezionato è il codec x che viene comunicato da T- sia al proprio, che alle centrali Server attraversate in precedenza dalla segnalazione di controllo. Al termine della procedura quindi tutte le centrali Server e coinvolte prevedono l impiego dell unico codec comune prescelto x. Per utilizzare l OoBTC è necessario che il protocollo di Call Control supporti lo scambio delle informazioni relative ai codec supportati. Le specifiche 3GPP contemplano come protocollo di Call Control, che supporta la procedura di negoziazione dei codec, il protocollo BICC CS2 (BICC Capability Set2). La condizione quindi per il supporto MS 118 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 1 - Giugno 2005

dell OoBTC è la presenza del protocollo BICC CS2; eventuali tratte di rete in cui non è presente tale protocollo implicano il ricorso alla transcodifica della voce, come descritto successivamente. 6.2.1 TrFO (Transcoder Free Operation) Il OoBTC è il meccanismo che permette la negoziazione del tipo di codec e della modalità di codifica mediante l impiego di segnalazione fuori banda; è quindi il meccanismo necessario alla abilitazione del Transcoder Free Operation. Il Transcoder Free Operation è la possibilità di effettuare chiamate per le quali non sono presenti nella comunicazione end to end device di transcodifica, oltre ai codec della sorgente e della destinazione. In questo modo è possibile trasmettere trame di voce compressa senza l inserimento di transcoder in rete, permettendo sia un miglioramento della qualità della voce, in quanto si elimina il ritardo delle due transcodifiche, sia un risparmio di banda, in quanto l informazione viaggia in rete in modalità compressa. Il TrFO è specificato dallo standard a partire dalla Rel.4. Lo scenario in cui è possibile utilizzare la funzionalità di TrFO è solo quello di chiamata 3G-3G. Infatti, negli scenari 2G-2G o di interlavoro 2G-3G, nella procedura di OoBTC il TRAU GSM seleziona il codec PCM, che è quello di default per l accesso GSM. Ciò comporta quindi una banda occupata in rete pari a 64 kbit/s, e le relative transcodifiche da PCM a banda compressa (PCM/AMR per la rete 3G), con l impossibilità di avere la banda trasmessa in modalità compressa end to end. L architettura di riferimento per la rete UMTS è quella riportata nella figura 5. 6.2.2 Codec at the Edge L esempio preso in esame nella figura 5 prevede che la negoziazione di un codec comune tra tutti i nodi di rete abbia successo. Può avvenire però che sia necessario prevedere nella catena end to end alcune transcodifiche. Ciò è quanto presentato nello scenario seguente, in cui viene illustrato il caso di una chiamata per Control Plane OoB Codec Negotiation ME User Plane Radio Bearer CN ME OoB AP AP Iu Bearer Server OoB Codec Negotiation T r a n si w or k CN bearer End to end connection Server control control AP t Bearer Req Bearer Req Bearer Req N et Core Network Mobile Equipment Media GateWay Out of Band Radio Access Network Application Part Radio Network Controller FIGURA 5 Architettura TrFO (Transcoder Free Operation). UT BICC PLMN TDM TSN Iu Bearer OoB Codec Negotiation Radio Bearer la quale non si riesce, con procedura OoBTC, a negoziare un codec comune end to end. La funzionalità di Codec at the Edge utilizza l OoBTC e consente, nelle situazioni in cui sia inevitabile inserire nel percorso della chiamata alcune transcodifiche, di selezionare i punti migliori in cui effettuarle; ad esempio le centrali che rappresentano il bordo di un dominio di rete entro il quale è possibile negoziare una codifica comune. Nella figura 6 è riportato uno scenario di chiamata nel quale non è possibile selezionare un codec comune end to end, poichè i nodi di transito dialogano con protocolli che non supportano l OoBTC, come ad esempio il protocollo ISUP. Il Supported codecs list (BICC) (X,Y,Z) Selected codec (BICC) (X) PLMN 1 Codec (X) /IP TSN TSN Asynchronous Transfer Mode Bearer Independent Call Control Media GateWay Public Land Mobile Network Time Division Multiplex Transit Network ISUP TSIT G.711 TDM FIGURA 6 Esempio d impiego di Codec at the Edge. Supported codecs list (BICC) (Y) Selected codec (BICC) (Y) PLMN 2 Codec (Y) /IP ME UT NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 1 - Giugno 2005 119

meccanismo di OoBTC permette quindi di attivare in segnalazione la transcodifica da voce compressa a codifica PCM e viceversa, nei due di bordo (at the edge) e non di accesso, consentendo il trasporto della voce in modalità compressa fino a questi ultimi, con il conseguente risparmio di banda in rete. 7. Fallback delle Videochiamate Il 3GPP ha specificato nuove funzionalità per gestire il cambio di servizio da telefonia a videotelefonia e viceversa, sia in fase di setup sia durante la conversazione. La prestazione di rete principale va sotto il nome di Service Change and Fallback for UDI/RDI multimedia (SCUDIF). Inoltre è stata specificata anche una soluzione di breve termine, denominata Redial, più semplice e basata principalmente su modifiche nel terminale. 7.1 Soluzione Redial Il meccanismo Idle Mode Redial è una combinazione del servizio standard voce e del nuovo servizio di videochiamata. Tale soluzione è fondamentalmente basata su logiche inserite nel terminale. I principali obiettivi della prestazione sono: alternare voce e video durante una conversazione, per mezzo dell abbattimento e della successiva instaurazione dell altro tipo di servizio verso lo stesso destinatario; offrire la chiamata audio, quando la copertura radio 3G degrada fino al punto di non poter offrire più il servizio video. In questo caso il video viene rilasciato e viene offerta la possibilità di richiamare in audio lo stesso destinatario; offrire la chiamata audio, quando il tentativo di chiamata video non va a buon fine. L obiettivo di tale prestazione è quello di velocizzare la richiamata in video o voce verso lo stesso destinatario, mediante un interfaccia MMI (Man Machine Interface) che renda più semplice ed immediata la procedura. Il 3GPP non specifica la MMI lasciando ai costruttori la libertà di progettare tale interfaccia. Dal punto di vista della core network, tale prestazione è semplicemente vista come due chiamate che si succedono, una voce e l altra video, effettuate tra i medesimi utenti. 7.2 Soluzione SCUDIF Il servizio nominato Service Change and Fallback for UDI/RDI multimedia (SCUDIF) è un miglioramento della soluzione Redial e permette agli utenti di ottenere una chiamata voce quando la connessione video a circuito end to end non è possibile (scenario di fallback to speech ). Inoltre è possibile alternare i servizi voce e quelli video durante una chiamata. In tutti questi scenari il passaggio tra i due servizi avviene senza che la chiamata iniziale venga abbattuta. La funzionalità apporta modifiche al terminale e ai nodi di rete, inserendo campi aggiuntivi alla segnalazione di setup della chiamata. La funzione SCUDIF soddisferà i seguenti requisiti: Fallback to speech durante l instaurazione della chiamata. Nel caso in cui il Setup della videochiamata non andasse a buon fine, la rete proverà a negoziare su entrambi gli utenti la chiamata voce. Alternare il servizio voce e video. Una chiamata voce può trasformarsi in video e viceversa, mediante una procedura invocata dall utente. Permettere ad un utente di rifiutare o meno una videocall richiesta dall altro utente, mentre si è connessi in modalità voce. Cambiare il servizio voce/video iniziato da rete. La rete potrà invocare un cambio di servizio durante una videochiamata, se questo non può più essere supportato (ad esempio per la copertura radio 3G non più sufficiente) e trasformare il servizio in voce su 2G. Se la videochiamata può nuovamente essere supportata, la rete può invocare nuovamente un cambio di servizio per ritornare al servizio video. Nel messaggio di setup, il terminale chiamante indica il supporto della feature SCUDIF e indica le BC (Bearer Capability) disponibili (speech e video). Le stesse BC vengono inviate al terminale ricevente. Sia in origine che in destinazione è necessario che i servizi siano sottoscritti nei relativi profili d utente in HLR. Il terminale ricevente rimanda indietro alla rete, come conferma di negoziazione, la lista delle BC supportate. Se la negoziazione ha come risultato un BC diversa da quella richiesta dal terminale chiamante viene avviata una procedura di In-call modification, dalla rete verso il terminale di origine. In ogni momento della conversazione sarà possibile cambiare il servizio da voce a video e viceversa, mediante comandi su terminale che attivano poi la procedura di In-call modification. Nella figura 7 è riportato il flusso di messaggi UE A A B UE B Modify (BCb) Modify complete (BCb) Core Network procedure Core Network procedure BCb Bearer Capability UE User Equipment Modify (BCb) Modify complete (BCb) FIGURA 7 Richiesta di cambio di servizio voce/video. 120 NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 1 - Giugno 2005