Notiziario Tecnico - Italiano

Archivio

Notiziario Tecnico

1/2005

NOTIZIARIO TECNICO TELECOM ITALIA › Anno 14 n. 1- Giugno 2005 5

Convergenza fisso-mobile:architetture e tecnologie

DANIELE CECCARELLI

GIOVANNI CECCONI

ALBERTO CIARNIELLO

STEFANO MARINO

DANIELE ROFFINELLA

PAOLO SENESI

Il tema della convergenza fisso-mobile viene affrontato per la prima volta inquesto articolo da parte di un team di esperti formato da colleghi TIM,Wireline e Tilab; abbiamo quindi ritenuto utile inquadrare il tema partendo dal-l’incontro di Telecom Italia con la Comunità Finanziaria, svoltosi ad aprile2005, in cui è stata illustrata la strategia della convergenza fisso-mobile, edesaminando poi le possibili evoluzioni in un arco temporale di 3 anni (conqualche sguardo anche più in là) con l’intento di mettere in evidenza le siner-gie e specificità delle nuove architetture di rete fissa e mobile.Il percorso che proponiamo parte dai trend “storici” che possono esseremessi per così dire alle “origini”, per passare agli aspetti più architetturali etecnologici; questo senza la pretesa di esaustività ma con l’obiettivo di espor-re alcuni aspetti che riteniamo fondamentali e che aiuteranno ad esplorare lepossibilità che la tecnologia mette, e metterà, a disposizione.

1. Introduzione

“Verso un’architettura di rete più efficiente efunzionale allo sviluppo di nuovi servizi integrati”,con queste parole il Presidente di Telecom ItaliaMarco Tronchetti Provera ha descritto l’evoluzionedelle Architetture di Rete del Gruppo Telecom Italiadurante l’incontro con la Comunità Finanziariatenutosi lo scorso 12 Aprile 2005 a Milano.

La figura 1 mostrata dal Presidente, illustra agrandi linee l’evoluzione delle piattaforme di rete e leintegrazioni che si realizzeranno nei prossimi anni:• un solo backbone ed una sola rete di aggrega-

zione IP;• piattaforme integrate per VAS, contenuti multi-

mediali e servizi ICT; • accessi IP nativi per i servizi multimediali inno-

vativi;• reti di accesso fissa e mobile separate per i ser-

vizi tradizionali a commutazione di circuito.

La figura 1 rappresenta, in estrema sintesi, irisultati del lavoro svolto dal “Network Innovationteam” guidato da Stefano Pileri, responsabiledella Rete in Wireline, ed al quale hanno parteci-pato rappresentanti di Telecom Italia Wireline,TIM, TILAB, Purchaising e Corporate tracciando lelinee guida per la convergenza.

Due assunzioni di base hanno guidato le atti-vità del team, la prima riguarda il mantenimento didue Business Unit, Mobile e Fissa, separate men-tre la seconda riguarda lo scenario regolatorio chesi assume non subirà significative variazioni nelprossimo triennio.

Sulla base di queste assunzioni il team halavorato focalizzandosi sugli aspetti tecnici conl ’ob ie t t i vo d i va lo r i zzare , a l l ’ i n te r no de l leBusiness Unit e nel pieno rispetto dei vincoliregolatori, i Centri di Competenza/Eccellenza, gliskills, le piattaforme tecniche e le capacità ope-rative.

ARCHITETTURE

CECCARELLI › CECCONI › CIARNIELLO› MARINO› ROFFINELLA› SENESI • Convergenza fisso-mobile: architetture e tecnologie

6 NOTIZIARIO TECNICO TELECOM ITALIA › Anno 14 n. 1 - Giugno 2005

Telecom Italia ha stimato in 1.500 milioni di euroil valore cumulativo delle sinergie realizzabili graziealla prima fase della convergenza nel periodo2005-2007; a ciò contribuiranno non solo la condi-visione di infrastrutture e piattaforme (trasporto IP,accessi fixed-wireless, piattaforme OSS, piat-taforme per VAS) ma anche l’ottimizzazione neiprocessi (acquisti, gestione e manutenzione, canalicommerciali).

Il Presidente ha sottolineato che tale evoluzionearchitetturale è coerente con i trend industriali piùinnovativi, introduce semplificazioni ed aumental’efficienza riducendo i costi. Inoltre ha evidenziatoche una piattaforma di rete convergente abilita losviluppo di nuovi servizi integrati che vanno daicontenuti multimediali ai VAS voce e dati, fruibilidal cliente in modo semplice ed user friendly.

Un primo snap-shot dei contenuti e servizi chepotranno essere lanciati è rappresentato in figura 2.Servizi di intrattenimento, di informazione, dicomunicazione personale in ambiente residenzialee business, accomunati dallo stesso brand, ma residisponibili in modo seamless attraverso differentiapparati (fissi, mobili, PDA, PC, TV …) dotati diinterfacce cliente uniformi: l’intento è di fornirenuovi servizi adattati al terminale di fruizione senzache il cliente abbia una percezione differente delservizio in funzione del terminale stesso: una“customer perception” indipendente dalla piat-taforma di rete.

In sintesi, ha proseguito Marco TronchettiProvera, mentre nel passato chi aveva il potere di

condizionare l’evoluzione delle reti e dei servizi èstato l’operatore dominante prima e il regolatore poi,adesso sarà sempre più il cliente a guidare gli svi-luppi grazie alla larga banda ed alla convergenza.

2. I driver per la convergenza delle architetture e dei servizi fisso-mobile

La “convergenza”, nelle telecomunicazioni,tema già da molto tempo dibattuto, può esseredeclinata in molti modi e perseguita in aree anchemolto diverse: convergenza nei servizi/applicazioni,nei contenuti, nei terminali, nelle infrastrutture direte; o ancora convergenza dati-voce, convergenzafisso-mobile, convergenza IT-TLC.

Non c’é molto di nuovo nell’obiettivo di realiz-zare “un’unica rete” per “tutti i servizi”. Di volta involta sono state definite e proposte, anche coneffort significativi a livello internazionale, soluzionitecniche ed approcci architetturali finalizzati allaconvergenza e all’integrazione. Negli anni Ottantaviene messa a punto l‘ISDN (Integrated ServicesDigital Network), concepita per supportare, con retidigitali a livello mondiale, servizi voce, dati e video.Nel 1982 la Conferenza Europea Poste e Telegrafi(CEPT) avvia un gruppo di studio per specificare unsistema capace di fornire i servizi ISDN a terminalimobil i; si trattava del Groupe Spécial Mobile(GSM). Così pure l’ATM, l’Internet, l’UMTS sonostati pensati anche sulla base di requisiti che pos-sono essere funzionali ad abilitare la convergenza.

HLR

BBNBackboneTDM

Mobile Wireline

Mobile Wireline/nomadic

2G

3G

GGSN Aggregation IP RAS

Fixed Switching

Mobile Switching Fixed Access

NB/BB/WiFi

Integrated ServicePlatforms

BackboneIP

BackboneIPMobile Access

2G/3G

xDSLGBE/WDM

Class 5Local

ExchangeNarrowBand

Broad BandWiFi

�Two independent backbones (TDM and IP)�Independent Network Intelligence infrastructure

From...

�Single IP backbone and IP aggregation�Integrated platforms for innovative VAS, multimedia contents and ICT services for business customers�“Native IP” access for innovative multimedia and VoIP services�Separate access for Fixed and Mobile with traditional voice services still over circuit switching technology

To...

- IMS- Messaging and collaboration - Content multimedia

Home Location Register

Media Gateway Control Function

Mobile Switching Center

Media Gateway

Gateway GPRSSupport Node

Home Subscriber Server IP Multimedia

SubsystemNext Generation

Network

Unified Data Base

Remote Access Server

Gigabit Ethernet

Backbone Network

MSC

HSSIMS NGN

UMTS MGW

GGSN

GSM/GPRSEDGE

MGCF

RAS

UDB

FIGURA 1› Evoluzione delle piattaforme di rete fisso e mobile.


NOTIZIARIO TECNICO TELECOM ITALIA › Anno 14 n. 1 - Giugno 2005 7

Inoltre, negli ultimi anni, due nuovi fattori stannoinfluenzando e modificando profondamente lo sce-nario: il business dei servizi “mobili” si è forte-mente sviluppato sino a raggiungere e superarequello dei servizi “fissi”; il business del broadband,innescato dall’esplosione di Internet, ha permessouno sviluppo anche dei servizi “fissi”.

Questa situazione, comune a molti Paesi avan-zati, sta facendo emergere strategie di businessdegli operatori “multiple play”, basate sulla combi-nazione di telefonia, media e Internet.

Infatti, proprio il modello Internet ha influenzatoil percorso evolutivo delle TLC, cioè un modo dicomunicare che prescinde dalle categorie tradizio-nali delle telecomunicazioni: Internet è fissa omobile? Entrambe. È telecom o media? Entrambe.È multimediale? Sicuramente si.

Oggi “essere connessi” è una necessità comein passato comunicare via telefono fisso e, piùrecentemente, comunicare ed essere raggiungibili“ovunque” mediante un sistema mobile inizial-mente nazionale e poi globale (GSM sta perGlobal System for Mobile communications). Sitratta di forme di comunicazione diverse, cia-scuna con una valenza specifica. Un esempioconcreto: la “community” degl i “always on”SMS/MMS è parallela e probabilmente moltosovrapposta a quella della e-mail ma ciò nonimpedisce oggi di disporre di uno (o più) indirizzidi e-mail che usiamo con regolarità per lavoro eper tenerci in contatto con gli amici.

Non è quindi un caso che negli ultimi cinqueanni molte delle innovazioni dei sistemi mobili,prima, e fissi, poi, siano state in molti casi diret-tamente mutuate dai modelli definiti dalla comu-

nità scientifica che si occupa dello sviluppo delletecnologie alla base di Internet (principalmenteIETF, Internet Engineering Task Force). Questofatto rappresenta uno dei più importanti cambia-menti nell’evoluzione recente delle telecomunica-zioni : s i par la quindi di architettura IMS ( IPMultimedia Subsystem) in ambito mobile e di NGN(Next Generation Networks) in ambito fisso perrispondere alle esigenze di passaggio da reti spe-cializzate “monoservizio” a reti capaci di suppor-tare un ambiente “multiservizio” o multimediale.

Se da un punto di vista tecnologico le opzionied i percorsi sono sufficientemente definiti, dalpunto di vista di business il modello di evoluzioneappare meno definito, anche per le differenze tra ilmondo Internet ed il mondo tradizionale delle TLC(basti pensare che, probabilmente, la parola piùusata in Internet è “free” mentre nelle TLC i servizisono in generale a pagamento).

Un nuovo modello potrà emergere dall’intera-zione dei due mondi in cui le telecomunicazionipotranno apportare quelle caratteristiche di cuiInternet necessita; in particolare l’affidabilità, laqualità, la semplificazione nell’accesso ai contenutie nella gestione dei nuovi servizi.

In questo articolo ci occuperemo della conver-genza fisso-mobile nella rete e nei servizi focalizzan-done i fattori abilitanti.

I driver per la convergenza, in questo conte-sto, sono, con qualche approssimazione, ricon-ducibili a due: da un lato la possibilità di realiz-zare sinergie ed ottimizzazioni (infrastrutture eprocessi); dall’ altro la possibilità di arricchirel’offerta di servizi verso la clientela. Se le sinergiefisso-mobile sulle infrastrutture possono costi-

�Music�Movies�Sports (football and other)�Televoting�Logos and ringtones �…

�Directories �Utility services�News�…

�Voice �E-mail�Voice Mail�Instant Messaging�Unified Messaging�Unified contact list�Photo/video album�Remote storage�…

�E-mail, Fax, Diary �Unified contact list�Unified Messaging�Seamless access to corporate internet (GPRS/EDGE/UMTS/ WiFi/ADSL)�…

Entertainment

Voice SMS MMS Audio/Video

Information

BRAND

TV Set Top BoxEdge/UMTS

Mobile PhonesDualmodeHandsets

CordedPhones Aladino WiFi PC

Business communication

Personal communication

FIGURA 2› Evoluzione del portafoglio delle offerte.



tuire di per sé un importante fattore di ottimizza-zione di investimenti e costi e quindi tradursi inleva competitiva, la convergenza fisso-mobile èqualcosa di più generale e riguarda l’evoluzionedelle reti e dei servizi, e quindi rappresenta unasfida architetturale e tecnologica impegnativa. Alivello internazionale il problema è stato colto esono in corso iniziative finalizzate alla definizionedi standard per la convergenza. Si può comun-que anticipare che un abilitatore di servizi conforti potenzialità “convergenti” appare oggi l’lPMultimedia Subsystem (IMS) che costituirà unanuova piattaforma aperta allo sviluppo modularedi nuovi servizi fruibili da reti mobili e fisse.

L’industria della telefonia mobile ha pianificatol’introduzione della multimedialità basata su IP fon-dando IMS su standard Internet “arricchiti” dellefunzionalità necessarie ai servizi e alle architetturedelle reti mobili. Analoghi sviluppi sono avvenuti estanno avvenendo per l’impiego IMS nell’ambitodelle reti fisse.

D’altra parte, con l’apertura delle reti al mondointernet, service ed application providers potrannoentrare anche in diretta competizione con operatoridi reti di telecomunicazioni persino sui servizi ditelefonia tradizionale (come ad esempio stannofacendo i service provider Skipe e Vonage).

Ancora una volta quindi la capacità di rispon-dere alle esigenze del mercato deciderà il suc-cesso di nuove tecnologie a scapito di altre.

Si capisce quindi come l’obiettivo della conver-genza fisso-mobile, non è “difendere” il business diun operatore da erosioni dovute a competitor ditipologia diversa (come ad esempio la cosiddetta“sostituzione fisso-mobile”). Occorre invece, con losviluppo della convergenza, soddisfare i bisognidei clienti con l’offerta di nuovi servizi e la “frui-zione di tutti i servizi” di telecomunicazione inmodo indipendente dalle condizioni in cui si trova ilcliente e tenendo conto delle esigenze di persona-lizzazione del servizio.

Si tratta di fornire servizi di comunicazionevoce, dati, video, con altri clienti (o con “server”),mantenendo lo stesso identificativo del cliente, lastessa procedura (possibilmente automatica) diautenticazione, la stessa rubrica, la stessa segrete-ria telefonica, la stessa casella di posta, superandole particolarizzazioni oggi derivanti dall’utilizzo diun terminale connesso ad una rete fissa piuttostoche ad una rete mobile. Naturalmente non si potràprescindere dalle caratteristiche intrinseche del-l’accesso utilizzato e dalle modalità di fruizione. Ilrequisito in generale è quello di mettere a puntosoluzioni architetturali e tecnologiche che abilitinola fruizione ovunque di servizi (ubiquità), ma chepresentino adeguate caratteristiche di adattamentoal contesto.

Un ulteriore abilitatore è la possibilità di svi-luppare agevolmente nuovi servizi “nativamente”convergenti, ad esempio, la praticità d’uso, lasemplicità, il costo di una “segreteria unica”,concepita come tale in una architettura di reteconvergente, sarebbero benefici per il cliente el’operatore.

Infine, un driver della convergenza che vor-remmo ancora richiamare è … il tempo che passa.Il ciclo di vita degli apparati di telecomunicazionesi è significativamente ridotto, anche a causa del-l’accresciuta competizione nel settore. Pertantotendono a determinarsi, con frequenza sempremaggiore, opportunità per sostituire terminali,apparati e tecnologie con altre maggiormenteinnovat ive (e quindi p iù performant i , menocostose, …). Privilegiare, per queste sostituzioni,sistemi idonei a costituire parti di un disegnoarchitetturale complessivo di convergenza èun’opzione molto interessante per gli operatori piùinnovativi.

Un vincolo nella convergenza è rappresentatodalla “legacy” in quanto la realizzazione di soluzionidi servizi convergenti come, ad esempio, su appa-rati di rete, terminali e sistemi di gestione esistentipuò determinare complessità e costi aggiuntivi.

Occorre quindi identificare percorsi di migra-zione sostenibili ed individuare scelte di sostitu-zione/acquisizione di tecnologie basate su stan-dard adeguati ai requisiti di convergenza fisso-mobile, avendo definito gli scenari convergenti dilungo termine e tenendo conto dei requisiti chiave(per operatori e clienti) di interoperabilità.

Da ultimo (non per importanza) un cenno alruolo che gli aspetti regolatori giocano nello svi-luppo della convergenza, aspetti fortemente corre-lati allo sviluppo delle tecnologie.

Oggi in Italia, come in molti Paesi, gli operatorifissi e mobili che hanno dimensioni rilevanti per ilmercato agiscono in un quadro di regole che nedefiniscono precisamente i rapporti, regole finaliz-zate in ultima analisi alla regolazione del mercatostesso.

Tuttavia lo scenario è in fase di evoluzione, adesempio sono in corso discussioni sulle modalitàper stabilire corrispondenze fra il sistema di nume-razione ed instradamento PSTN ed i meccanismiper raggiungere applicazioni internet e sulle pro-spettive aperte dall’assegnazione di nuove porzionidi spettro radio per servizi sia fissi sia mobili (vediWiMax).

La compatibilità delle soluzioni tecniche con ilquadro regolatorio di riferimento costituisce unodei fattori che più possono condizionare le sceltetecnologiche e di business nei diversi mercati.

3. Verso la convergenza: un pò di storia

Questa sezione riporta un breve excursus sucome l’industria, in particolare gli enti di standar-dizzazione fissi e mobili, ha progressivamenteorientato i propri lavori alla ricerca di una conver-genza architetturale realizzata attraverso soluzioniIMS/NGN. Tuttavia, accanto agli enti di normativaufficiali come 3GPP, ETSI/TISPAN e ITU, si stannoaffermando anche Forum come ad esempio FMCAe SCCAN (paragrafo 4.3), che tentano di anticiparei tempi, proponendo in parallelo soluzioni non sem-pre in linea con gli standard in corso di definizionepresso gli enti di normativa ufficiali.



A beneficio della comprensione dei capitoli suc-cessivi, si riporta nel riquadro “NGN in sintesi …”una definizione di NGN (Next Generation Network),termine spesso abusato. La definizione riportata,che non è certamente l’unica, è tratta dalla speci-fica ETSI TISPAN NGN “NGN R1 Definition” ed èquindi significativa per il contesto in esame.

3.1 La convergenza nel mondo mobile

Nel dicembre 1998 nasce i l 3GPP (3rdGeneration Partnership Project) con il mandato disviluppare le specifiche del sistema cellulare diterza generazione UMTS che comprende l’UTRA(Universal Terrestrial Radio Access). I suoi membrifondatori sono gli Enti di standardizzazione deiprincipali Paesi protagonisti del mercato delle tele-comunicazioni mondiale: l ’ETSI (EuropeanTelecommunicat ion Standard Inst i tute) perl’Europa, l’ARIB (Association of Radio Industriesand Businesses) per il Giappone, l’ATIS (Alliancefor Telecommunications Industry Solutions) per gliStat i Unit i ( in iz ia lmente T1), i l TTA(Telecommunications Technology Association) perla Corea. Successivamente, nel 1999, è confluitonel 3GPP anche l’organismo di standardizzazionecinese CWTS (China Wireless TelecommunicationStandard Group) da f ine 2002 CCSA (ChinaCommunications Standards Association).

Le aziende manifatturiere e gli operatori sonomembri del 3GPP e partecipano alle sue attivitàattraverso gli organismi di standardizzazione aiquali appartengono.

Il 3GPP comprende anche alcuni organismi cherappresentano il mercato delle telecomunicazionimobili, quali ad esempio: la GSM Association,l ’UMTS Forum, i l Global Mobi le Suppl iersAssociation, l’IPv6 Forum ed altri.

Oggi il 3GPP comprende diverse centinaia dimembri e sostanzialmente tutte le pr incipal iaziende di ICT mondiali.

Le attività iniziarono formalmente alla fine del1998, mentre i gruppi di lavoro tecnici furonoavviati nei primi mesi del 1999 con l’obiettivo diottenere una prima versione comune delle specifi-che per la fine dell’anno 1999. Nella prima metà del1999 sono stati raccolti ed integrati in un unicostandard i vari contributi degli organismi membri,

dedicando la seconda parte dell’anno alla finalizza-zione dei parametri di dettaglio del primo rilasciodel le specif iche UTRA emesse dal 3GPP: laRelease 99.

Subito dopo il “congelamento” della Release 99si decise di svincolare la numerazione del laRelease dall’anno di emissione e così la releasesuccessiva prese i l nome di Release 4.Recentemente sono terminati i lavori per il rilasciodella Release 6.

Nell’ambito del 3GPP furono formati inizial-mente quattro diversi gruppi tecnici di lavoro(TSG):• Radio Access Network TSG (Rete di accesso

radio);• Core Network TSG;• Service and System Aspects TSG (Servizi ed

apparati);• Terminals TSG (Terminali).

Nel corso del 2000, l’ETSI ha portato al 3GPPulteriori contributi sull’evoluzione del GSM, inclusele tecnologie GPRS ed EDGE. A questo proposito èstato creato dal 3GPP un nuovo specifico gruppodi lavoro, i l TSG GPRS EDGE Radio AccessNetwork (GERAN).

La figura 3 [dal www.3gpp.org] mostra l’attualestruttura del 3GPP, articolata in TSG e sottogruppi,recentemente rivista con la chiusura del TSG T(Terminali) e lo spostamento di due dei relativi sot-togruppi nei TSG RAN e Core Network.

Negli ultimi anni, il 3GPP ha affrontato, in variesedi, i l tema della convergenza fisso-mobile,soprattutto all’interno del TSG SA. In particolare lo

NGN in sintesi ...

Una NGN (Next GenerationNetwork) è una rete a pacchettoin grado di fornire un ampio setdi servizi di telecomunicazione edi utilizzare diverse tecnologie alarga banda e QoS-enabled. Inuna NGN le funzionalità legate aiservizi sono indipendenti daquelle legate al trasporto. UnaNGN è in grado di offrire agliutenti accesso a più serviceprovider e supporta il concetto

di mobilità generalizzata checonsente di fornire i servizi agliutenti, ovunque essi si trovino.La NGN è caratterizzata daiseguenti aspetti:• Trasporto a pacchetto;• Separazione delle funzioni di

controllo in bearer capabili-ties, chiamata/sessione, eservizi/applicazioni;

• Interfacce aperte;• Supporto di un ampio set di

servizi, applicazioni e mec-canismi basati su buildingblock di servizio (per servizireal t ime e non real t ime,multimediali e di streaming);

• Supporto del broadband con

QoS end to end;• Interlavoro con reti legacy;• Mobilità generalizzata;• Accesso a differenti service

provider;• Supporto di differenti mecca-

nismi di identificazione, chepossano essere r isolt i inindirizzi IP;

• Convergenza tra servizi fissie servizi mobili;

• Indipendenza delle funziona-lità legate al servizio dallatecnologia di trasporto;

• Requisiti regolatori quali adesempio, le chiamate diemergenza, la privacy, … .



sviluppo dell’IMS e del GAN (Generic AccessNetwork) hanno contribuito significativamenteall’avvicinamento del mondo della comunicazionimobile a quello del fisso.

Nel 2001 è stata siglata una collaborazione for-male tra 3GPP e IETF con l’obiettivo di assicurarelo sviluppo coerente delle specifiche tecniche el’allineamento temporale che faciliti l’interoperabi-lità tra sistemi fissi e mobili, dispositivi e terminali.

3.2 La convergenza nel mondo fisso

I primi lavori per la normativa sull’utilizzo dellatecnologia IP relativa all’evoluzione delle reti e deiservizi di telecomunicazione risalgono alla finedegl i anni Novanta. Nel 1997, l ’ETSI Board,durante i l sesto meet ing tenutosi a SophiaAnt ipol is, approvò la creazione di un nuovoProgetto ETSI “Telecommunication and InternetProtocol Over Networks (TIPHON)”. Obiettivo pri-mario del progetto era di offrire supporto allecomunicazioni voce tra utenti tradizionali (su retiPSTN/ISDN e GSM) ed utenti Internet nonché allecomunicazioni in scenari in cui le reti a pacchettooffrivano il trasporto tra due reti a circuito.

Uno dei principali scopi era la creazione distandard globali, per cui si ravvisò subito la neces-sità di collaborazione con altri organismi di stan-

dardizzazione o forum. I primi gruppi consideratifurono IETF e ITU-T.

Infatti negli stessi anni anche IETF muoveva iprimi passi sull’adattamento delle tecnologie nativeIP ad un contesto te lecom: dapprima con i lWorking Group SIGTRAN, che nel 1998-1999 definìl’ormai celebre modello funzionale del gateway diinterlavoro tra reti IP e reti a circuito basato sulprincipio di separazione tra controllo e trasporto; inseguito con il Working Group MeGaCo (MediaGateway Control), che diede poi il nome al proto-collo di controllo del Gateway, elemento chiave periniziare a centralizzare l’intelligenza di rete, svilup-pato in collaborazione con ITU-T SG16; infine conla definizione del protocollo SIP (Session InitiationProtocol). SIP, nato inizialmente per altri scopi,ossia per invitare gli utenti a sessioni di serviziInternet, per le sue caratteristiche di apertura eflessibilità venne progressivamente adattato per unutilizzo in contesti non strettamente “Internet-based”.

Con il progressivo consolidarsi delle tecnologie,le attivita di normativa sulle NGN hanno avuto unaaccelerazione nel 2002-2003.

In ETSI, nel settembre 2003, è stato formato ilTC TISPAN (Telecoms & Internet convergedServices & Protocols for Advanced Networks), natodalla fusione del progetto TIPHON e del TC SPAN

TSG CNCore Network

CN WG1MM/CC/SM (lu)

CN WG4WAP/GTP/BCH/SS

CN WG5OSA

Open Service Access

CN WG2CLOSED 2004

CN WG3Interworking withExternal Networks

TSG RANRadio Access Network

RAN WG1Radio layer1specification

RAN WG4Radio Performance &

Protocol Aspects

RAN WG5 (ex T1)Mobile terminal

Conformance Testing

RAN WG2Radio Layer2 spec & radio Layer3 RR spec

RAN WG3lub spec lur spec lu spec &UTRAN O&N requirements

TSG CTCore Network &

Terminals

CT WG1 (ex CN1)MM/CC/SM (lu)

CT WG5 (ex T3)Smart Card

Application Aspects

CT WG4 (ex CN4)WAP/GTP/BCH/SS

CT WG1 (ex CN5)OSA

Open Service Access

CT WG3 (ex CN3)Interworking withExternal Networks

TSG SAServices &

System Aspects

SA WG1 Services

SA WG4 Codec

SA WG5 Telecom

Management

SA WG2 Architecture

SA WG3Security

TSG GERANGSN EDGE

Radio Access network

GERAN WG1Radio Aspects

GERAN WG2Protocol Aspects

GERAN WG3Terminal Testing

TSG TTerminals

TWG1Mobile Terminal

Conformance Testing

TWG2Mobile Terminal

Services & Capabilities

TWG3Smart card

Application Aspects

TSG ORGANIZATIONNEW TSGs - from 2005-03-11

CLOSED TSGs

UNCHANGED TSGs Project Co-ordination Group(PCG)

FIGURA 3› Struttura del 3GPP.



(Services and Protocols for Advanced Networks).Lo SPAN è il gruppo che storicamente si è occu-pato della definizione di servizi per reti PSTN/ISDNe delle evoluzioni/caratterizzazioni dei protocolliper tali reti e per il supporto dei servizi stessi.

Il TISPAN, nato con l’obiettivo di concentrare lecompetenze ETSI per le reti fisse che migranoverso la tecnologia a pacchetto e con il mandato didefinire gli standard europei per la convergenza el’interoperabilità di reti NGN in termini di servizi,architetture, protocolli, numerazione, qualità delservizio, sicurezza e gestione, è diventato ben pre-sto il punto di aggregazione dei principali vendored operatori europei (ma non solo). La “forza” diTISPAN è stata la capacità di fare tesoro dell’espe-rienza TIPHON e di saperla ade-guare alle mutate condizioni dimercato, in particolare in termini diconvergenza fisso-mobile.

Fin dai primi mesi di lavoroTISPAN ha deciso di orientare leproprie specifiche verso un riusoed adattamento delle specifiche3GPP, in particolare per quantor iguarda l ’ IMS ( IP Mult imediaSubsystem).

Razionale della scelta è statoanche, naturalmente, il riconosci-mento del l ’enorme esperienzamaturata dal 3GPP sul tema dellesoluzioni per servizi multimediali;vi è stato quindi uno sforzo inizialevolto sia ad identificare le peculia-rità della rete fissa che rendevanonecessarie delle estensioni ad hoc,sia a definire le modalità operativepiù efficaci per l’organizzazione deilavori, anche nei confronti di IETF.

IETF, infatti, non ha mai smessodi giocare un ruolo chiave sul tema NGN, in parti-colare per gli aspetti legati al protocollo SIP. 3GPPha un forte ed efficace legame con IETF, poiché èinevitabile che nella definizione di soluzioni archi-tetturali su rete IP, nascano esigenze di modificheai protocolli ed ai meccanismi nativi IETF. Per esi-genze analoghe TISPAN decise quindi di attivareun link con IETF, seppur sempre mutuato da 3GPP,così da seguire procedure già in essere.

Lato ITU-T si sono susseguite una serie diattività avviate con una NGN Project a fine 2002nell’ambito del SG13, e sfociate nella creazionedi un Focus Group sulle NGN (FGNGN), con l’o-biettivo di armonizzare le diverse attività legateall'NGN in ambito ITU-T ed agevolare l'avviodelle attività dei nuovi Study Group per il qua-driennio 2005-2008.

Il FGNGN ha riconosciuto a TISPAN il ruolo dileadership sulla produzione delle specifiche NGNper rete fissa ed ha assunto un ruolo istituzionaledi globalizzazione, grazie alla presenza di attoriasiatici e nordamericani, e si è concentrato supochi e limitati aspetti di estensione di quantodeciso in TISPAN.

Il 2005, infine, ha visto l’ingresso in questo scena-

rio dell’ATIS (Alliance for TelecommunicationsIndustry Solutions), ente statunitense, riconosciutodall’ANSI (American National Standard Institute), cheha l’obiettivo di accelerare lo sviluppo di servizi esoluzioni di TLC implementabili ed interoperabili. Ilconsorzio, strutturato in 22 tra “industry/technicalcommittee” e “incubator solutions programs”, contapiù di 1100 membri e di 350 aziende e a metà 2004ha iniziato a lavorare sulle NGN, instaurando unaserie di link con ETSI TISPAN e ITU-T FGNGN.

Oggi si è strutturata quindi una completa rete direlazioni (figura 4), tra enti di normativa volti,ognuno con le peculiarità del proprio ambito, adefinire standard utilizzabili in scenari di conver-genza fisso-mobile.

Una ulteriore spinta verso la direzione della pro-duzione di specifiche convergenti è arrivata adaprile 2005, nel corso del secondo workshopTISPAN-3GPP, in cui sono state concordate le pro-cedure di collaborazione che dovrebbero portareentro la fine del 2005 ad avere un unico set di spe-cifiche per il Core IMS, applicabili sia in ambitofisso sia in ambito mobile.

4. Gli standard

4.1 L’ IP Multimedia Subsystem del 3GPP

IMS (IP Multimedia Subsystem) è la soluzionestandardizzata dal 3GPP per il supporto dei servizitelefonici e multimediali su infrastruttura di rete IP.IMS si basa sul protocollo SIP di IETF al qualesono state aggiunte alcune estensioni specifichedel 3GPP, successivamente accettate dall’IETF.IMS costituisce un elemento fondamentale per laconvergenza delle reti in quanto consente la forni-tura dei servizi indipendentemente dalla rete diaccesso utilizzata, fissa o mobile: GPRS, EDGE,WCDMA, WLAN, xDSL.

IMS come puntodi partenza

3GPP “usa” IETF perestensioni e lavori ad hoc

NGN “globalizzata”

NGN Nordamericana

Lavori di dettaglioal supporto di IMS E NGN

(es. SIP)

TISPAN si ispira a IMS.Liaison e workshop per verifica

di allineamento

ITU-T recepisce i lavori TISPANe li globalizza, a volte estendendone

lo scopo (es. QoS)

TISPAN: NGN Europea(leader dei lavori tecnici)

Elaborati TMFrecepiti nei

documenti TISPAN

ATIS è alla ricercadi coordinamento

tramite liaison e workshop

FIGURA 4› Rapporti tra gli Enti di Normativa.



IMS consente anche l’interlavoro con altre retiSIP-based (es. intranet aziendali) e con reti a cir-cuito (PSTN, PLMN).

IMS condivide fra i diversi tipi di accesso e diservizi informazioni relative a charging, presence,database di utenti, gestione dei media, controllodelle sessioni, funzioni di O&M.

L'IMS offre interfacce aperte per facilitare lo svi-luppo di nuove applicazioni SIP-based e nel con-tempo definisce alcuni servizi:• presence: unisce l’informazione sullo stato di

registrazione del cliente e la volontà del clientedi essere contattato;

• PoC (Push to talk over Cellular): invio di file dati(contenenti brevi messaggi vocali) verso unalista di destinatari con modalità asincrona halfduplex (effetto walkie-talkie);

• instant messaging: servizio di scambio di mes-saggi/files con una lista di referenti di cui è notolo stato di connessione;

• combinazionali: sincronizzazione di una chia-mata voce standard con una sessione dati chein parallelo alla chiamata voce assicura loscambio di files dati (ad esempio il servizio TIM“Turbocall”).L’architettura IMS di release 6 3GPP è illustrata

nella figura 5.Le entità funzionali che compongono l’IMS

3GPP sono:• P-CSCF (Proxy CSCF): costituisce il primo

punto di contatto per l’utente nel dominio IMS.Il P-CSCF appartiene alla stessa rete in cui è

collocato i l GGSN (rete Home, come nelleattuali reti GPRS, o Visited). Si occupa di tra-smettere le richieste SIP ricevute da uno UserEquipment (UE) verso il I/S-CSCF opportuno, digestire le chiamate di emergenza, di generare iCDR (Call Data Record), di effettuare la com-pressione della segnalazione.

• I-CSCF (Interrogating CSCF): costituisce ilpunto di contatto all’interno di un dominio pertutte le sessioni dirette ad un utente apparte-nente al dominio o in roaming all’interno deldominio stesso. L’I-CSCF può appartenere sol-tanto alla rete Home e, in caso di utente in roa-ming, rappresenta il punto di gateway per lasegnalazione SIP tra la rete Home e la reteVisited in quanto unico elemento “pubblicato” eaccessibile da un’altra rete. Si occupa di inter-rogare l’HSS e di selezionare il S-CSCF al qualedemandare il controllo della sessione. I-CSCFpuò generare CDR. Una importante funzione delI-CSCF è il THIG (Topology Hiding Inter-networkGateway), ossia la modifica dei messaggi SIPper eliminare le informazioni relative alla topolo-gia interna di rete.

• S-CSCF (Serving CSCF): è l’elemento deputatoad effettuare il controllo di sessione (instaura-zione, supervisione, rilascio). L’S-CSCF puòappartenere soltanto alla rete Home. Si occupadi registrare l’utente, di interagire con il piano diservizio, di generare CDR, di interagire con unBGCF per garantire l’interlavoro con la PSTN ocon un CS-Domain. L’S-CSCF supporta le fun-

zionalità di SIP Proxy e SIPRegistrar. L’S-CSCF vieneassociato ad un utente,gestendo le sue registrazionie controllando tutti i suoimessaggi (anche se l’utenteè in roaming), svolgendoulter iormente i l ruolo diService Broker tra le variepiattaforme di servizio. Inparticolare, l’S-CSCF sele-ziona l’Application Serveropportuno da coinvolgereper fornire un determinatoservizio sulla base di parti-colari criteri (chiamati “FilterCriteria”) definiti nel profilodi ogni utente contenuto inHSS.• PDF (Policy DecisionFunction): realizza le proce-dure di SBLP (ServiceBased Local Pol icy) checonsentono all’operatore ilcontrollo sull’accesso ai ser-vizi IMS.• BGCF (Breakout GatewayControl Function): è utiliz-zato negli scenari di chia-mata misti pacchetto-cir-cuito. Nel caso di chiamateuscent i seleziona la rete

ASDh

ISC

Gq

Go

IMS-MGW Mn

MGCF

BGCF

SGW

Legacy/PSTN

Other IP/IMS network

Mg

Mi

Mm Mk

Mi

MRFC

Mr

Gi

Gi

PDF

SGSN GGSN

PS Domain

UTRAN/GERAN

UE

SLF

Cx

Cx

HSS

I-CSCF

I-CSCF

P-CSCF

MwControl Plane

Traffic Plane

ASBGCF

I-CSCFGGSN

HSSIMS

MGCFMGW

========

Application ServerBreakout Gateway Control FunctionInterrogative CSCFGateway GPRS Support NodeHome Subscriber ServerIP Multimedia SubsystemMedia Gateway Control FunctionMedia Gateway

MRFCP-CSCF

PDFPSTN

S-CSCFSGSN

SLFUE

====

====

Multimedia Resource FunctionProxy CSCFPolicy Decision FunctionPublic Switched TelephonyNetworkInterrogating CSCFServing GPRS Support NodeSubscription Locator FunctionUser Equipment

S-CSCF

FIGURA 5› Architettura di IMS Release 6.



PSTN o CS-Domain verso cui inoltrare la chia-mata e nel caso di chiamate entranti seleziona ilnodo di core network che realizza l’interworkingcon la rete legacy (può essere il MGCF dellostesso dominio IMS o il BGCF di un altro domi-nio IMS).

• HSS (Home Subscriber Server): è il databaseche contiene tutte le informazioni relative all’u-tente, in part icolare in termini di UserIdentification, Numbering and addressing, Usersecurity, User Location e User Profile. Per lagestione della sottoscrizione relativa al livello ditrasporto IP l’HLR (Home Location Register),parte di HSS, si interfaccia con SGSN e GGSN.Nel caso di IMS, per le funzioni di autentica-zione, autorizzazione, accounting (AAA) l’HSS siinterfaccia con il CSCF.

• SLF (Subscription Locator Function): indica aCSCF e AS l’HSS opportuno per la sessione incorso.

• MRFP (Mult imedia Resource Funct ionProcessor): rappresenta funzioni quali conferen-ziatori, generatori di annunci, risorse speciali.

• MRFC (Mult imedia Resource Funct ionController): controlla l’MRFP.

• MGCF (Media Gateway Control Function): con-trolla l’IM-MGW ed effettua la conversione fra lasegnalazione associata alle chiamate (ISUP)nelle reti legacy e la segnalazione (SIP) usata inIMS.

• SGW (Signalling Gateway): effettua la conver-sione di segnalazione tra i livelli di trasportoSS7 (delle reti legacy a circuito) e i livelli di tra-sporto IP (in IMS).

• IM-MGW (IP Multimedia - Media Gateway):effettua l’interlavoro di trasporto tra dominio apacchetto e dominio a circuito.In recenti incontri fra 3GPP e TISPAN è stato

deciso che il 3GPP continuerà il suo lavoro di evo-luzione e di mantenimento delle specifiche su IMSe che l’accesso a IMS da rete broadband fissa saràintrodotto con la prestazione “Fixed BroadbandAccess to IMS” in release 7 3GPP. Queste specifi-che saranno la base per la def iniz ione del laRelease 1 della piattaforma multimediale NGN infase di standardizzazione da parte di ETSI TISPAN.

4.2 La Next Generation Network di ETSI e ITU-T

La NGN (Next Generat ion Network) ETSITISPAN ha come obiettivo la fornitura di servizi dicomunicazione real-time e non real-time su unainfrastruttura IP-based multiservizio, multiproto-collo e multiaccesso, abilitando funzionalità dinomadicità e mobilità per utenti e terminali.

La Release 1, attesa entro il 2005, prevedenaturalmente un sottoinsieme di queste funziona-lità: in particolare sono supportati servizi di comu-nicazione voce e video real-time, presence e mes-saggistica, con supporto della sola nomadicità, suuna rete IP in grado di garantire la QoS solo sultratto di accesso.

In figura 6 è illustrata l’architettura completaTISPAN.

Come si può notare, essa è suddivisa in quattroprincipali sottosistemi:• NASS (Network Attachment SubSystem);• RACS (Resource Admission Control

Subsystem);• Core IMS (IP Multimedia Subsystem);• PES (PSTN/ISDN Emulation Subsystem).

Il NASS si occupa dell’attachment dell’utentealla rete tramite:• Fornitura dinamica dell’indirizzo IP e di altri

parametri di configurazione degli apparati insede di utente;

• Autenticazione dell’utente, prima o durante lafase di allocazione dell’indirizzo IP;

• Autorizzazione dell’accesso alla rete su baseprofilo utente;

• Configurazione della rete di accesso, su baseprofilo utente;

• Location management (ad esempio, per gestirele chiamate di emergenza).Il RACS si occupa di controllare la rete in coe-

renza con le richieste di servizio, svolgendo le fun-zioni di:• Service Based Local Policy Control, ossia di

autorizzazione delle richieste di QoS e di defini-zione delle policy di cui fare l’enforcement;

• Supporto della QoS su una molteplicità di tec-nologie di accesso e di terminale;

• Admission Control;• NAPT/Gate Control (Network Address Port

Transaction.I l NASS ed il RACS sono due sottosistemi

appartenenti al Transport Layer; ciò significa chesvolgono funzioni generiche di rete, applicabili aqualsiasi tipo di servizio. I sottosistemi di serviziosupportati in Rel.1 sono il Core IMS ed il PES.

Userprofiles

Applications

ServiceLayer

Transport Layer

Other subsystems

Core IMS

Oth

er n

etw

orks

Use

r Eq

uipm

ent PES

(PSTN/ISDNEmulation

Subsystem)

NASS(Network

AttachmentSubSystem) RACS

(Resource andAdmission Control

Subsystem)

Transfer Functions

IMSISDNPSTN

===

IP Multimedia SusystemIntegrated Services Digital NetworkPublic Switched Telephony Network

FIGURA 6› Architettura NGN di ETSI TISPAN.



Il Core IMS è il sottosistema che supporta iservizi voce e video su piattaforma SIP, in coe-renza con quanto in essere in 3GPP. Il modellofunzionale è molto simile a quello 3GPP e lostesso vale per i servizi. Si noti che il Core IMSsupporta anche i servizi di derivazione telefo-nica (STS, Servizi Telefonici Supplementari), marealizzati in maniera innovativa, ossia con uncontrollo SIP-based, e orientati ai nuovi termi-na l i . Questa modal i tà è denominata “PSTNSimulation”.

Il PES è il sottosistema che fornisce gli STSagli utenti tradizionali, quindi su terminali legacy,utilizzando opportuni gateway di accesso all’infra-struttura IP. Questa modalità è denominata “PSTNEmulation”.

Esistono infine degli elementi funzionali, condi-visi fra tutti i sottosistemi, denominati “commoncomponents”; essi sono il database dei profili, gliApplication Server e gli elementi di interconnes-sione con altre reti.

Analogamente a NGN ETSI TISPAN, Il FocusGroup NGN (FGNGN nel seguito) dell’ITU-T hadefinito la NGN come una rete a pacchetto ingrado di fornire servizi di telecomunicazione e diutilizzare molteplici tecnologie di trasport broad-band e QoS-enab led . Ne l l a NGN de f in i tadal l ’ ITUT-T, le funzional i tà legate al serviziosono indipendenti dalle tecnologie di trasporto.Essa consente agli utenti un accesso seamlessalle reti, ai service provider e ai servizi e sup-porta una mobilità. Supporta una mobilità gene-ralizzata per consentire la fornitura dei serviziagli utenti indipendentemente dalla locazionefisica ed, infine, è caratterizzata da una architet-tura aperta basata su API e/o interfacce stan-dard che u t i l i z za una re te b roadbandgestita/gestibile.

I servizi supportati sono i servizi telefonici sia inmodalità PSTN Emulation sia PSTN Simulation(mutuando le definizioni TISPAN), i servizi multime-diali nella loro accezione più ampia (compresi quellicontent-based), l’accesso a Internet, i servizi dati ei servizi di pubblica utilità (intercetto legale, servizidi emergenza, ...).

Il modello funzionale è più articolato di quelloTISPAN, seppur ad esso riconducibile.

Lo scope della Rel. 1 ITU-T, attesa per dicembre2005, è leggermente più ampio di quella ETSITISPAN, poiché prevede anche il supporto di contentdelivery services, accesso via cavo e broadcast,qualità del servizio nel core della rete, supporto degliscenari inter-dominio per la Qualità del Servizio.

4.3 Altri Enti, Consorzi e Forum

• FMCA (Fixed Mobile Convergence Alliance)Questo consorzio è stato fondato nel luglio

2004 dai seguenti operatori di rete fissa e mobile:BT, Korea Telecom, NTT, Brasil Telecom, RogersWireless, Swisscom. A Novembre 2004 si sonoaggiunti Cegetel, AT&T, Bezeq e KPN.

Gli obiettivi dell’Associazione sono acceleraregli standard sulla convergenza fisso-mobile (ad

esempio, la proposta di standardizzazione UMA),attraverso la proposta di requisiti e soluzioni tecni-che anche tramite sperimentazione, e condizionarei produttori di apparati e di infrastrutture agendocome gruppo di acquisto per ottenere prezzimigliori.

• SCCAN (Seamless Converged CommunicationAcross Networks)SCCAN Forum, sostenuto dall’IEEE Industry

Standards and Technology Organization (IEEE-ISTO), è un’organizzazione che si occupa di defi-nire specifiche aperte per le tecnologie che abili-tano la convergenza delle comunicazioni sia vocesia dati, tra Wi-Fi e cellulare da un lato e rete fissadall’altro.

SCCAN è ancora in fase di formazione, inattesa che altre aziende si uniscano al forum. Almomento ne fanno parte Motorola, Avaya, Proxim,Chantry e 2Wire.

• WiFi AllianceWiFi Alliance è un consorzio che si occupa di

certificare i prodotti compatibili con lo standardWiFi. Allo scopo di favorire la convergenza trafisso e mobile la WiFi Alliance ha costituito ilgruppo di lavoro WiFi/Cel lu lar Convergence(WCC). Tramite il lavoro di questo gruppo la WiFiAlliance è stata in grado di certificare i primi pro-dotti che offrono sia la connessione WiFi sia lacomunicazione cellulare.

Le prime certificazioni comprendono tre cate-gorie di prodotti: il PDA e i cellulari che integrano ilsupporto WiFi (per esempio, iPAQ Pocket PCH6315 di HP, Nokia 9500 Communicator), i com-puter portatili con supporto WiFi (ad esempio,Intermec 760 Mobile Computer) ed inf ine gl iaccessori che consentono la convergenza fra WiFie telefonia cellulare (la scheda SanDisk ConnectWiFi SD Card).

5. Le soluzioni architetturali

5.1 L'architettura convergente

Le prime reti fisse e mobili sono nate per fornireservizi “real time”, essenzialmente voce, assicu-rando elevate affidabilità e qualità di servizio graziealla tecnologia a commutazione di circuito.

Con l’emergere dei servizi dati, che mal si adat-tano all’utilizzo efficiente delle risorse di una rete acircuito, sono nati i sistemi a pacchetto in grado ditrasferire in modo efficiente quantità rilevanti didati, in particolare al crescere del numero di clienti“connessi” alla rete.

Dopo diverse evoluzioni e l’emergere della“super rete” Internet, oggi le reti a pacchetto sonodiventate reti integrate capaci di offrire anche ser-vizi multimediali.

I tempi per questi passaggi sono stati abba-stanza rapidi e sono stati determinati in largaparte dalla necessità di combinare il susseguirsidi tecnologie sempre più efficienti e flessibili



con lo sviluppo delle infrastrutture, compatibilecon le esigenze di manutenzione ed estensionedei servizi di base e delle relative infrastrutture.

Nel caso delle reti radiomobili questa evolu-zione è stata particolarmente veloce: in appenaquindici anni si è passati dalle reti analogiche di“prima generazione” alle reti evolute di “terzagenerazione”.

Le reti mobili di “prima generazione” (servizioTACS lanciato in Italia nel 1990) e di “secondagenerazione” (GSM lanciato in Italia nel 1995) sonobasate sulla commutazione di circuito e sulla mes-saggistica supportata dall’SMS.

La rete GPRS introdotta da TIM nel 2001, svi-luppata in gran parte facendo evolvere le compo-nenti di rete GSM, ha costituito il primo passoevolutivo verso la rete radiomobile per voce edati a pacchetto. Questa evoluzione, continuatacon l’incremento progressivo delle prestazioni edelle funzionalità, è proseguita nel 2004 con l’up-grade dell’intera rete GPRS ad EDGE che con-sente di elevare signif icativamente la bandadisponibile al cliente, sino ad oltre 200 Kbit/s (infuturo di 300 Kbit/s o superiori).

Nel 2004 è stato inoltre avviato il servizio com-merciale della rete di “terza generazione” UMTS diTIM, costituita da una componente a circuito perservizi real time (videochiamata e voce) e da unacomponente a pacchetto per servizi dati ad altavelocità basata su Core Network GPRS.

Le prime evoluzioni della rete UMTS (Release 4)introducono il passaggio ad una architettura MSCServer - Media Gateway comune per accesso GSMed UMTS ed il trasporto a pacchetto anche per iservizi real time (trasformazioni avviate nel 2004nella rete TIM).

Le successive evoluzioni (Release 5) preve-dono un’infrastruttura IP per servizi voce, dati emultimedia (IMS).

Un’analoga evoluzione si sta osservando sullarete fissa, seppur con tempistiche e modalitàlegate alla necessità di preservare gli investimentifatti e soprattutto di mantenere la quota di busi-ness associata alla rete telefonica tradizionale.

Il primo passo evolutivo di Telecom Italia, com-piuto in un arco di due anni tra 2002 e 2004, è con-sistito nella realizzazione del BBN (BackboneNazionale Multiservizio) che sostituisce la rete ditransito telefonica con l’obiettivo di cogliere i bene-fici derivanti dalle sinergie nel trasporto fra servizidati e voce (per approfondimenti sul BBN, si vedal’articolo “Il BackBone IP per i servizi telefonici”,Notiziario Tecnico, anno 13, n.1).

Il secondo passo, iniziato nel 2003, ed attual-mente in corso, è l’introduzione di una piattaformaNGN per servizi multimediali, ispirata all’architet-tura IMS e quindi caratterizzata da una netta sepa-razione tra i livelli di servizio, controllo e trasporto edalla centralizzazione dei dati relativi ai profili deiclienti; tale piattaforma abilita una varietà di nuoviservizi per la clientela residenziale e SOHO, quali lavideocomunicazione e la telefonia personale (AliceMia), e per la clientela business quali i serviziHyper Voice ed Hyper Centrex (per approfondi-

menti sulla piattaforma, si veda l’articolo “Le nuovepiattaforme per i servizi multimediali”, NotiziarioTecnico anno 13, n.1).

L’architettura IMS è quindi il punto di arrivo econvergenza di due percorsi evolutivi nati con esi-genze e requisiti differenti. Le sue caratteristiche,approfondite in questo capitolo, ne consentono l’u-tilizzo in reti convergenti fisso-mobili.

5.1.1 Caratteristiche comuni nell’evoluzione delle reti fisse emobili.

Il percorso di evoluzione delle reti fisse e mobiliè contraddistinto da alcuni passaggi comuni seb-bene distinti dal punto di vista temporale. Per ilmobile le opzioni di evoluzione architetturale sonoriferibili anche all’evoluzione degli standard di rife-rimento (3GPP) che hanno anticipato analoghi svi-luppi del fisso (TISPAN).

Per le caratteristiche di base dei servizi suppor-tati (mobilità, roaming), la rete mobile è evoluta conuna architettura “aperta” (necessità di interlavorotra le reti per garantire il “roaming”) e più marcata-mente “a strati”, a causa della necessità di distin-guere il livello di servizio dal livello di commuta-zione e trasporto. Infatti, già con l’avvento delGSM, le reti mobili hanno previsto la distinzione trafunzioni/nodi di gestione del servizio e funzioni dicontrollo d’accesso/mobilità, quali per esempioregistrazione, autenticazione e cifratura realizzateda nodi HLR/AuC centralizzati.

Questi principi sono rispettati anche nella evo-luzione della rete fissa tenendo conto che TISPANper la definizione dell’architettura NGN si è forte-mente ispirato al 3GPP.

Possiamo evidenziare almeno tre momenti fon-damentali nell’evoluzione delle reti:a) la distinzione fra le piattaforme di servizio ed

applicative e l’infrastruttura di rete che realizzala commutazione e la connettività fino al clientefinale: la progressiva digitalizzazione e conver-genza di strati di rete su infrastrutture a pac-chetto, l’avvento del protocollo IP (InternetProtocol), l’approccio aperto degli standardInternet consentono, con la flessibilità dellenuove tecnologie, una sempre maggiore indi-pendenza dei servizi dalla infrastruttura di rete.IP abilita l’offerta di nuovi servizi e allo stessotempo lo sviluppo sulle reti “dati” anche dei ser-vizi voce di base (per esempio, VoIP su retifisse) e multimediali.

b) la distinzione delle funzionalità di commutazionee trasporto da quelle di controllo con l’introdu-zione, per le ret i f isse, del le tecnologieSoftswitch e MGW (attualmente presenti neiPoP BBN della rete di Wireline) e per le retimobili di MSC Server e MGW (conformi allaRelease 4 3GPP ed introdotti dal 2004 nellaCore Network TIM). La separazione tra piano dicontrollo (legato essenzialmente alla numerositàdei clienti ed alla complessità dei servizi) epiano di commutazione e trasporto (legatoessenzialmente ai volumi e caratteristiche ditraffico svolto) consente di differenziare lo svi-



luppo dimensionale dei diversi piani. Da notare,inoltre, che il piano di controllo ed il piano dicommutazione sono caratterizzati da trafficimolto differenti: il traffico di segnalazione cheinteressa il piano di controllo è in genere note-volmente inferiore rispetto al traffico del cliente.Ciò consente di adottare anche scelte architet-turali differenti per i due piani, per esempioaccentrando le risorse di controllo e distri-buendo in rete le risorse di commutazione perridurre le necessità di capacità di trasporto deltraffico del cliente. Infatti, in tale situazione, iservizi person to person (per esempio, voce)richiedono un minor impegno di risorse di tra-smissione essendo la porzione di traffico alunga distanza in genere molto inferiore rispettoa quella locale.

c) la tendenza ad un trasporto/commutazionebasato su IP nella Core Network, con il pro-gressivo superamento della rete di trasporto acommutazione di circuito TDM. La rete BBN diWire l ine impiega OPB (Opt ica l PacketBackbone) per il trasporto di tutto il trafficotelefonico di lunga distanza; anche nella reteTIM una porzione di traffico telefonico a lungadistanza è già trasportata su IP. Come detto,gli sviluppi tecnologici di rete mobile e di retefissa abilitano il trasporto IP in core networkcon soluzioni che ottimizzano banda occupatae qualità per i servizi telefonici, aspetto fonda-mentale per conseguire qualità ottimale “endto end”.Tali passaggi permettono di realizzare architet-

ture di rete di tipo “orizzontale” in cui i differentilivelli di rete interlavorano attraverso interfaccedefinite funzionalmente e possibilmente aperte.Fondamentale, in questo senso, è l’attività di stan-dardizzazione internazionale che negli ultimi anni,iniziando nel mondo mobile (attraverso il 3GPP) eapprodando di recente nel mondo fisso (ETSITISPAN), ha favorito notevolmente lo sviluppo delmercato e dei servizi.

5.1.2 Reti convergenti e servizi convergenti

La convergenza di componenti di rete e quelladi componenti di servizio sono due aspetti correlatima di base nettamente distinti. Mentre la conver-genza di rete può consentire di rendere più effi-c ient i le piattaforme a par i tà di serviz i daerogare/supportare, la convergenza dei servizi puòconsentire lo sviluppo delle piattaforme massimiz-zandone la fruibilità congiunta per clienti che acce-dono al servizio da rete fissa e da rete mobile.

Si tratta di possibilità non precluse dalle tecno-logie tradizionali, quali ad esempio OSA (OpenService Architecture) e IN (Intelligent network), chequindi potranno continuare ad avere un ruoloanche in futuro.

Il modello a strati dell’architettura di rete, appli-cabile a reti fisse e mobili, abilita processi di con-vergenza in quanto consente interventi di integra-zione all’interno dei singoli livelli senza alterare l’in-tera architettura di rete.

Alcuni elementi abilitanti la convergenza delleinfrastrutture di rete sono:1) uno strato comune di trasporto basato sul pro-

tocollo IP e/o Gigabit Ethernet: in grado di sup-portare le differenti caratteristiche e requisitidelle tecnologie fisse e mobili.

2) uno strato di controllo comune basato su IMS: ilsottosistema IMS sviluppato dal 3GPP si appre-sta a diventare la soluzione comune fra retimobili e fisse per realizzare il controllo delle reti.Il tentativo di collaborazione di recente avviatofra gli enti di standardizzazione 3GPP e ETSITISPAN dovrebbe garantire che le future evolu-zioni di IMS siano in grado di soddisfare le esi-genze delle reti fisse e mobili, in particolarerelativamente alle funzioni di controllo delle ses-sioni SIP, al trattamento della QoS, all’interla-voro con le altre reti a circuito e a pacchetto. E’bene sottolineare, però, che IMS potrà assu-mere un ruolo cruciale nella fornitura di serviziconvergenti a qualità “telecom grade” solo setale collaborazione potrà garantire la piena inte-roperabilità tra le piattaforme ed i terminali.

3) la centralizzazione delle funzioni di autentica-zione e dei dati relativi ai profili dei clienti: per larete mobile si tratta di una necessità legata aiservizi di base quindi già realizzata anche per il“2G” dalle funzioni supportate dall’HLR e per laquale sono previste una serie di evoluzioni. InIMS sono stati previsti database centralizzati(HSS) per la gestione delle informazioni di servi-zio (es. registrazione ai servizi, personalizzazionidei servizi) che sono utilizzate dalle diverseapplicazioni. L’HSS è un’evoluzione dell’HLRutilizzato nelle reti radiomobili per la raccoltadelle informazioni del cliente necessarie perl’accesso alla rete ed ai servizi e per la mobilità.Nella definizione della NGN di rete fissa vienenaturalmente mantenuto il concetto di centraliz-zazione dei profili su un UPSF (User ProfileServer Function) che equivale alla parte IMS delHSS (quindi senza la parte HLR).

4) piattaforme di servizio comuni accessibili dalledifferenti reti di accesso: a causa della nonomogeneità delle caratteristiche delle diversetecnologie di accesso (per esempio in termini dibanda e caratteristiche dei terminali utilizzati daiclienti) gli stessi servizi potranno essere erogaticon caratteristiche e prestazioni differenti sullediverse reti di accesso. La disponibilità di inter-facce standard faciliterà lo sviluppo dei servizi.Gli elementi sopra descritti sono riscontrabili

nello scenario evolutivo di integrazione fra le retiWireline e TIM (figura 7). In questo scenario gliaccessi, fisso e mobile, e la rete di commutazionerimangono distinti mentre le piattaforme di back-bone IP/MPLS, le piattaforme di trasporto dei ser-vizi voce fissi e mobili e le piattaforme di controlloe di interworking per i servizi NGN/IMS vengonomesse a fattor comune. A livello di servizio, ove èpossibile e risulti conveniente, si condivideranno lepiattaforme per la creazione dei servizi conver-genti, mentre per i contenuti si condivideranno lepiattaforme di gestione e Content Delivery.



Fra le tecnologie che abilitano la convergenzafisso-mobile segnaliamo anche la tecnologia diaccesso GAN (Generic Access Network), standardiz-zato in Release 6 3GPP sulla base di quanto già realiz-zata dal consorzio UMA (Unlicensed Mobile Access),composto da alcune manifatturiere e operatori fissi emobili (Alcatel, Ericsson, Motorola, Nokia, NortelNetworks, Siemens, Sony Ericsson, Kineto Wireless,AT&T Wireless, British Telecom, Cingular, O2, RogersWireless, T-Mobile US) [www.umatechnology.org].

La rete GAN fornisce l ’accesso al la CoreNetwork GSM/GPRS/EDGE, a circuito ea pacchetto, attraverso una genericarete IP a larga banda che utilizzi tecno-logie di accesso wireless su bande nonlicenziate (WLAN/WiFi, Bluetooth). I lGAN cost i tu isce quindi un accessocomplementare a GSM/GPRS/EDGE eUTRAN (UMTS Terrestrial Radio AccessNetwork) per la fornitura di servizi voce,dati e multimediali (inclusi SMS/MMS,servizi supplementari, servizi di emer-genza, servizi di localizzazione). Ai ter-minali dual mode GSM/GAN è consen-tito il roaming o l’handover (figura 8) fracopertura GSM/GPRS/EDGE e accessoGAN, in modal i tà t rasparente per i lcliente.

L’accesso offerto dal GAN è definitogenerico in quanto in grado di operare suuna qualunque rete IP che utilizza unaccesso radio su bande di frequenza nonlicenziate. I protocolli fra terminale eCore Network sono trasparenti alla gene-rica rete IP in quanto realizzati mediantetunnelling.

Il GANC (Generic Access Network

Controller) realizza le funzioni di gatewayfra l’accesso IP e la rete GSM ed “appare”alla core network come un BSS (BaseStation Subsystem) GSM/GPRS/EDGE (leinterfacce con core network sono quellestandard 3GPP).

Il GANC svolge le funzioni di adatta-mento/transcodifica per la voce e realizzale funzionalità di controllo relative alla regi-strazione, al setup dei bearer, alla mobilitàe le funzionalità di Security Gateway(SGW), che termina i tunnel provenientidal terminale mobile e consente autenti-cazione, encryption e data integrity.

Il GAN deve fornire almeno lo stessol ivel lo di s icurezza garant i to dalGSM/GPRS per tutto il traffico fra termi-nale mobile e GANC. Il cliente dovràessere autenticato ed autorizzato sullabase delle credenziali presenti su SIM.

Una possibile applicazione della tecno-logia GAN è riportata in figura 9 in cui ilgenerico accesso IP è realizzato su retefissa a larga banda e accesso radio WiFi.Il terminale dual-mode GSM/GAN (nell’e-sempio GSM/WiFi) che entra in un’area dicopertura GAN (ad esempio quando il

cliente rientra nella propria abitazione nella quale èattiva una copertura WiFi), contatta il GANC attra-verso la rete di accesso a larga banda per richiederel’autorizzazione ad usufruire dei servizi GSM e GPRSveicolati su accesso GAN.

5.1.3 Convivenza/migrazione del mondo legacy acommutazione di circuito

I principali driver comunemente indicati per l’a-dozione di IMS su accessi a larga banda sia mobili

Application Services

Rete fissa/nomadica

Rete mobile

Control Platform

IN IMS

NBAccess

TDM FixedSwitching

TDMMobile

SwitchingBKB IPGERAN2G

UTRAN GSN

HSS/UDB

NASxDSL

BBWiFiVoIP

IP nativoTDM & IP

GBE/WDMBRAS3G

BBBRASGSNGBEHSSIMS

INNAS

========

BroadBandBroadBAnd Remote Access ServerGPRS Support NodeGigaBit EthernetHome Subscriber ServerIP Multimedia SubsystemIntelligent NetworkNetwork Access Server

NBTDMUDB

UTRAN

VoIPWDMxDSL

====

===

Narrow BandTime Division MultiplexingUniversal Data BaseUMTS Terrestrial Radio Access NetworkVoice over IPWavelength Division Multiplexingx Subscriber Line

FIGURA 7› Architettura target della rete integrata fisso e mobile.

Accesso UMA/GAN

Accesso GSM

TerminaleDual Mode

CORENETWORKGSM

Base TransceiverStations (BTS)

Unlicensed Wireless Network(e.g. Wifi, Bluetooth...)

Generic AccessNetwork Controller

(GANC)

Base StationController (BSC)

PrivateNetwork

IP AccessNetwork

GANUMA

==

Generic Access NetworkUnlicensed Mobile Access

FIGURA 8› Architettura GAN/UMA.



(GPRS/EDGE, UMTS/HSDPA, WLAN) sia f issi(xDSL) sono:• unificazione delle procedure di rilascio dei ser-

vizi;• semplificazione e razionalizzazione introdotte a

livello di trasporto (tutti i servizi sono realizzatisul dominio a pacchetto).Tali benefici possono essere estesi anche al servi-

zio voce nella misura in cui questo servizio è realiz-zato su IP (VoIP). Sono ormai numerose sul mercatole offerte VoIP per la rete fissa su ADSL. La gradualeestensione della copertura della banda larga su retefissa favorirà contemporaneamente lo sviluppo diservizi multimediali, di servizi dati e di VoIP (si vedal’articolo “Voce su IP: stato dell’arte del mercato estrategie”, Notiziario Tecnico, anno 13, n. 2). Al con-tempo rimane la necessità di mantenere l’attuale retePSTN a banda stretta.

Il dispiegamento di IMS per servizi multimediali daparte di un operatore fisso (come già intrapreso daWireline) apre per l’evoluzione della telefonia fissa unampio ventaglio di possibilità legate in particolare allacrescita su piattaforma IMS dei clienti VoIP, con con-seguente alleggerimento della rete telefonica tradizio-nale a circuito. Un ribaltamento più massivo, non daescludere, dovrà però tenere conto di alcuni impor-tanti fattori. Non va dimenticato, ad esempio, cheWireline è soggetta ad obblighi di fornitura del servi-zio universale sulla telefonia tradizionale e quindieventuali soluzioni tecniche evolutive, non potrannoprescindere dagli aspetti regolamentari.

In quest’ottica, esistonotecnologie, in parte ancheconsolidate, non basate suIMS per fornire il serviziotelefonico su IP in modalità100% compliant con l’esi-stente e trasparente per l’u-tente, quindi in ott ica direplacement; sono basatesu una evoluzione del lesoluzioni SoftSwitch/MediaGateway utilizzate per l’in-terlavoro circuito/pacchetto(come quelle del BBN), conl’aggiunta di opportune fun-zionalità “Class 5”, ossiarivolte appunto alla fornituradi servizi telefonici all’utenteed al controllo degli accessitelefonici.

L’ IMS, d’a l t ro canto,potrebbe giocare un ruoloimportante anche in questocampo; è fuori di dubbio,infatti, che per un operatoreche ha investito in una piat-taforma IMS, poter valoriz-zare ta le invest imentoanche in ott ica di PSTNReplacement, rappresentiuna notevole opportunità.

Dal punto di vista tecno-logico, IMS avrà natural-

mente bisogno di alcune modifiche per venireincontro alle esigenze di PSTN Replacement,modifiche che sono in via di definizione in ETSITISPAN (la soluzione viene definita “IMS-BasedPSTN Emulation”).

Per quanto riguarda le reti mobili 2G/3G, nelmedio termine è previsto il mantenimento e l’ulte-riore sviluppo dell’accesso a circuito ed è difficil-mente prevedibile un passaggio al “VoIP” (perquanto questo termine possa essere utilizzato inambito mobile) motivato da decisivi recuperi di effi-cienza e disponibilità anticipata di meccanismi dicontrollo adeguati della QoS. Tra le ragioni princi-pali vi sono:• elevatissima efficienza dell’accesso a circuito

raggiunta dalle tecnologie 2G (codifiche vocaliHR e AMR, meccanismi avanzati di controllo eriduzione dell’interferenza con accessa TDMA);

• elevata efficienza dell’accesso a circuito rag-giunta dalle tecnologie 3G, per le quali la capa-cità impegnata è costantemente ridotta alminimo compatibile con qualità e attività dellaconversazione.Per consentire di sfruttare congiuntamente le

efficienze raggiunte dalla voce a circuito, con lenuove possibilità offerte dalla disponibilità di bandaper i dati sono stati definiti in 3GPP i servizi“Combinazionali”, basati sulle combinazioni di datie voce sia per rete 2G sia per rete 3G (ad esempio,il servizio TurboCall di TIM, disponibile al momentosu rete UMTS e presto anche su rete GPRS/EDGE

Fixed Network

Home

Mobile Network

EncapsulatedGSM protocol

VoIP

TDM

Internet

TDM

GSM

DSLAM

DSL Modem+ WiFi AP

WiFi/GSM dual-mode phone

GANC

TDM

BSC

BSS

BTS

Gb

Gb

A

GMSC

Virtual BSS

GGSN

MSC SGSN

SMSC HSSCharging/BillingSystem

TandemSwitch

ControlVoiceData

OperatorServices

BSCBSSBTS

DSLAMGMSC

=====

Base Station ControllerBase Station SubsystemBase Transceiver StationDSL Access MultiplexerGateway Mobile Switching Center

HSSGGSNSGSNSMSC

TDM

=====

Home Subscriber ServerGateway GPRS Support NodeServing GPRS Support NodeShort Message Service CenterTime Division Multiplexing

A

FIGURA 9› Architettura GAN: esempio di applicazione tramite accesso da rete fissa a larga banda.



mediante terminali Dual Transfer Mode -DTM). I servizi “combinazionali” preve-dono l’uso contemporaneo della rete acircuito per la voce e della rete a pac-chetto per le componenti di serviziobasate su dat i che possono essere“aggiunte” dai clienti alla componentevoce (o viceversa), arr icchendone lacomunicazione.

Da quanto detto emerge che ancheper la rete mobile, come per la rete fissa,la componente” legacy” di rete a circuitodovrà essere mantenuta, ancora a lungo,in efficienza per l’erogazione di servizireal time (voce e video).

Nel breve/medio periodo lo sviluppoarchitetturale della rete mobile prevedequindi:• la prosecuzione della migrazione ad

architettura basata su MSC server eMGW;

• l’introduzione della trasmissione IP nelbackbone con graduale riduzione/sosti-tuzione del livello di trasporto e com-mutazione TDM di transito.Quindi sebbene si preveda un impor-

tante sviluppo delle reti a banda larga,fisse e mobili, sussistono le condizioniper mantenere e far evolvere le attuali retia circuito, fisse e mobili, per l’erogazionedei servizi legacy a circuito (essenzialmente voce)e dei servizi di tipo “enriched voice”. 5.2 Il controllo delle sessioni

L’architettura per il controllodelle sessioni per i servizi multime-diali, definita in 3GPP, è l’IMS (IPMultimedia Subsystem). Il modellofunzionale IMS R6 è illustrato nellafigura 10 , dove la parte in grigio èquella propria dell’IMS.

In figura 11 è invece illustrato ilmodel lo funzionale del l ’ IMSTISPAN che suddivide la propriaarchitettura in sottosistemi,ognuno dei quali deputato ad unaspecifica funzione.

In particolare, nel livello di ser-vizio, TISPAN ha affiancato all’IMSaltri sottosistemi (in Release 1 visarà solo i l PES, PSTN/ISDNEmulation Subsystem); ciò ha por-tato alla necessità di mettere a fat-tor comune alcune funzioni che nel3GPP appartengono all’IMS (daqui anche il nome “Core IMS” datoda TISPAN).

Si può quindi notare come ilCore IMS TISPAN sia r idottorispetto all’IMS 3GPP: i nomi dellefunzionalità sono rimasti uguali, adeccezione dell’HSS, che è stator inominato UPSF (User Prof i leServer Function) perché non con-tiene i dati tipici dell’HLR.

ASChargingFunctions

HSS SLF

I/S-CSCF« IMS »

BGCF

P-CSCF MRFC MGCF SGW

PDF CRF

GGSN

UE

MRFP

IP Transport (Access and Core)

IM-MGW

PSTN

/IS

DN

Oth

er IP

Net

wor

ks

ASBGCF

CRFCSCFGGSN

HSSISDN

MGCFMGW

=========

Application ServerBreakout Gateway Control FunctionChrging Rules FunctionCall Session Control FunctionGateway GPRS Support NodeHome Subsriber ServerIntegrated Services Digital NetworkMedia Gateway Control FunctionMedia Gateway

MRFC

MRFP

PDFPSTN

SGWSLFUE

==

=

==

==

Multimedia ResourceFunction ControllerMultimedia ResourceFunction ProcessorPolicy Decision FunctionPublic Switched TelephonyNetworkSignalling GatewaySubsription Location FunctionUser Equipment

FIGURA 10› Modello funzionale IMS della Release 6 3GPP.

AS ChargingFunctions

SLFUPSF

NetworkAttachmentSubsystem

I/S-CSCF« Core IMS »

BGCF

P-CSCF MRFC MGCF

T-MGF

I-BGF

SGF

I-BCF

IWF

UEIP Transport (Access and Core)

Resource and Admission Control Subsystem

PSTN

/IS

DN

Oth

er IP

Net

wor

ks

ASBGCFCSCFI-BCF

IWFMGCFMRFC

=======

Application ServerBreakout Gateway Control FunctionCall Session Control FunctionInterconnect Border Control FunctionInterWorking FunctionMedia Gateway Control FunctionMultimedia Resource Function Controller

MRFP

MRFP

SGFSLF

T-MGFUE

UPSF

=

=====

Multimedia Resource Function ProcessorSignalling GTW FunctionSubscription Locator FunctionTrunking Media Gateway FunctionUser EquipmentUser Profile Service Function

FIGURA 11› Modello funzionale IMS ETSI TISPAN.



Le principali differenze tra i due IMS, derivantiquindi dall’estensione dell’architettura dalla solarete mobile anche alla rete fissa, possono esserecosì riassunte:• UPSF (HSS in 3GPP), SLF, SGF, MRFP e T-MGF

(IM-MGW in 3GPP) non appartengono al Core-IMS ma vengono def in i t i come “CommonComponents”, quindi utilizzabili anche dal PESe da altri sottosistemi di servizio.

• Procedure di resource reservation e policy sonogestite in maniera diversa. Il P-CSCF 3GPP pre-vede l’utilizzo dell’interfaccia Gq verso il PDF.TISPAN, come si vedrà nel prossimo capitolo,ha definito una architettura (RACS, Resourceand Admission Control Susbsytem) per il Policye Gate Control, in grado di gestire una pluralitàtecnologica di accessi. Ciò porta ovviamente adifferenze di comportamento sulla suddettainterfaccia.

• Correlazione tra policing e charging, che in3GPP è allo studio per la R7, non è al momentoprevista per il TISPAN.

• In TISPAN sono necessarie funzional ità diNAT/firewalling e di hiding verso alcuni accessif iss i (ad esempio nei casi di resident ia lgateways); in particolare il P-CSCF TISPAN puòsvolgere funzioni di ALG (Application LevelGateway).

• P-CSCF TISPAN allo stato attuale non conoscela tipologia di accesso (GSM, UMTS, WLAN,xDSL) sul quale è registrato l’utente e non può,quindi, modificare/adattare alla tipologia diaccesso i meccanismi di compressione, disegnalazione ed i timer.

5.3 Il controllo della rete

La molteplicità di tipologie di servizio che unarete multiservizio abilita, associata all’opportunitàdi offrire tali servizi su piattaforme convergenti,rende necessario un attento controllo della rete permantenere, in ogni condizione, la qualità adeguataai servizi supportati.

In quest’ottica, il controllo della rete è un ele-mento fortemente abilitante dei servizi conver-genti fisso-mobile. In particolare si ritengonoessenziali in prospettiva due macrofunzionalitàatte a garantire una fruizione ottimale dei servizida parte degli utenti:• controllo della Qualità del Servizio e di tutte le

funzionalità correlate;• controllo del Gating, ossia dell’apertura delle

porte sugli apparati di rete per consentirequando opportuno il passaggio dei flussi di tra-sporto.Le funzionalità di controllo della rete devono

naturalmente operare in stretta sinergia con il restodell’architettura convergente, in particolare con ilcontrollo delle sessioni per svolgere correttamenteil compito di ammettere o meno i vari flussi asso-ciati alle sessioni di servizio.

Un’altra forte sfida è la capacità di controllareapparati di diversa natura, principalmente per con-sentire a terminali e reti di accesso tecnologica-

mente eterogenee una adeguata e sicura connes-sione alla rete IMS.

Da queste considerazioni, scaturiscono unaserie di requisiti che hanno guidato nei vari enti dinormativa la definizione delle architetture per ilcontrollo di rete; tra i principali:• vi deve essere un opportuno coordinamento fra

controllo di sessione e controllo di rete;• i meccanismi di controllo di rete devono essere

basati sia su modelli push (in cui lo strato dicontrollo impone autonomamente le policy agliapparati di rete) sia su modelli pull (in cui gliapparati di rete effettuano richieste allo strato dicontrollo in caso di particolari eventi e ricevonoin risposta le policy da applicare);

• lo strato di controllo della rete deve supportarele funzionalità di Admission Control, NAPT(Network Address Port Translation) Control eFirewall Control;

• le funzionalità di Admission Control devonopoter essere basate su politiche sia locali siacomplessive di rete;

• i meccanismi per il controllo della QoS devonoessere indipendenti dalle specificità dei singoliservizi e devono agire su base end to end;

• deve essere possibile modificare dinamica-mente le politiche di QoS o di gating nel corsodella sessione;

• devono essere supportate richieste di QoS pertutti i tipi di flussi (mono e bidirezionali, simme-trici e asimmetrici, unicast e multicast, up edown-stream).La prima soluzione definita normativa per il con-

trollo di rete è stata ovviamente quella 3GPP, limi-tata agli aspetti di QoS Control. Essendo infattil’IMS, dalla R6 in poi, basato su IPv6, non vi ènecessità delle funzioni di NAPT Control/Traversal.

IMS 3GPP sfrutta meccanismi di controllo dellaQoS a livello di trasporto (bearer) e a livello appli-cativo, insieme a meccanismi di SBLP (Service-Based Local Policy) che mettono in correlazione laQoS sui due livelli.

A livello di trasporto il 3GPP ha previsto (a par-tire dalla Release 99) procedure di gestione dellaQoS sul dominio a pacchetto nella fase di attiva-zione del contesto PDP (Packet Data Protocol) pernegoziare i parametri (ad esempio relativi al throu-ghput o al ritardo) che consentono di realizzare iltunneling fra il terminale ed il GGSN. Da notareche il tunnel comprende anche la tratta radio che,data la necessità di sfruttare in modo ottimale lerisorse radio, costituisce la parte più critica deisistemi radiomobili. Per questo motivo IMS hareso necessario anche l’introduzione di meccani-smi di ottimizzazione radio (come Robust HeaderCompression o Signalling Compression) che con-sentono di r idurre la banda occupata dall ’o-verhead IP o dalla segnalazione SIP che attraversail tunnel.

A livello applicativo è il protocollo SIP a preve-dere meccanismi di controllo end to end della QoSper la sessione (servono a negoziare alcuni para-metri come tipo di media, es. audio o video, o dicodec).



La correlazione fra le QoS richieste ai due livelliavviene attraverso procedure di Service BasedLocal Policy, realizzate dal PDF (Policy DecisionFunction), che consentono all’operatore il controllosull’accesso alle risorse di rete a seguito di unarichiesta di servizio (figura 12).

Per permettere questo controllo da parte dellarete lo standard prevede una specifica interfacciatra PDF e GGSN (interfaccia Go):• in Release 5 il PDF è una componente del P-

CSCF, quindi la correlazione è possibile soloper i servizi IMS;

• in Release 6 il PDF può essere distinto dal P-CSCF e l’interfaccia Gq fra PDF e P-CSCF èaperta, quindi la correlazione può essere appli-cata anche a servizi non-IMS (ad esempioPacket Streaming).Sono possibili comunque meccanismi di con-

trollo in rete non standard che sfruttano il proto-collo RADIUS e che non richiedono l’interfacciaGo. In assenza di un controllo da parte della rete lacorrelazione tra i requisiti di QoS end to end ed iservizi portanti è affidata al terminale (nella fase diattivazione del contesto PDP). Questi meccanisminon sono comunque sufficienti a garantire una QoSend-to-end nei casi di interlavoro con reti IPesterne o con reti di backbone che fornisconomeccanismi IP di QoS, in particolare per quei ser-vizi che presentano stringenti requisiti di qualità,come i servizi conversazionali o streaming.

Per questo il 3GPP ha avviato uno studio perindividuare e valutare soluzioni (da inserire inRelease 7) che riescano a superare le difficoltàattuali e garantire qualità del servizio end to end.

ETSI TISPAN, come su altri sottosistemi di rete,ha preso come punto di partenza l’architettura diPolicy Control 3GPP e l’ha estesa per adattarlaanche alle esigenze di rete fissa, in particolareaggiungendo le funzionalità di Gate Control. Vasottolineato come in Rel.1 NGN TISPAN questefunzional i tà saranno l imitate al segmento diaccesso della rete.

Il sottosistema TISPAN per il controllo di rete èi l RACS (Resource and Admission ControlSubsystem), la cui architettura funzionale, ancorain fase di finalizzazione, è illustrata in figura 13.

I due elementi funzional i propri del RACSTISPAN sono SPDF e A-RACF:• SPDF (Service Policy Decision Function) si

occupa di fornire un single point of contact agliAF (Application Function, che possono essereCSCF o AS) per effettuare le richieste di QoS edi prendere le opportune decisioni sulle politi-che da applicare;

• A-RACF (Access Resource Admission ControlFunction) è l’elemento che si occupa di tradurrele polit iche decise dall ’SPDF in opportunicomandi sugli apparati della rete di accesso. Èquindi compito dell’A-RACF tenere in conto lespecif icità tecnologiche del le varie reti diaccesso supportate.La presenza dell’A-RACF è una delle principali

differenze con il modello 3GPP: si è scelto di scin-dere il PDF in due funzionalità distinte per isolare inuna funzione specifica la conoscenza delle tecno-logie di accesso, disaccoppiandola dalla funzionedi colloquio con i livelli di sessione/servizio.

Un’altra differenza con il 3GPP, come già evi-denziato, è la capacità di A-RACF e SPDF di con-

Application Function

Sessionsignaling

GoCOPS

SGSN GGSN

PDP Context Activation

UserEquipment

Service level

Bearer level(e.g. PDP context activation)

QoS policy control interaction

Gq

COPSGGSN

PDFPDP

SGSN

=====

Common Open Policy ServiceGateway GPRS Support NodePolicy Decision FunctionPacket Data ProtocolServing GPRS Support Node

PDF

FIGURA 12› Ruolo del PDF in rete.

RACSAF

SPDF

NASS

A-RACF

CoreBorder Node

IP Edge

Access Node

RCEF

L2T Point

Gq’

la

Re

e4

Ra C-BGF

DSDiCPE

AFC-BGF

CPENASSRACSRCEFSPDF

=======

Application FunctionCore Border Gateway FunctionCustomer Premise EquipmentNetwork Attachment SubSystemResource and Admission Control SystemResource Control Enforcement FunctionService Policy Decision Function

Transport

FIGURA 13› Sottosistema TISPAN per il controllo di rete RACS.



trollare il gating in rete, in particolare sulle inter-facce “Re” e “Ia” verso le funzioni di BorderGateway.

Infine questa nuova funzionalità si r i f letteanche sul l ’ inter faccia t ra AF e SPDF, che èmutuata dalla Gq 3GPP, ma che prende il nome diGq’ proprio per il fatto di dover essere in grado ditrasportare le richieste di NAT Control.

Sono in corso delle attività TISPAN-3GPPper condividere le modalità operative che pos-sano portare a convergere verso un unico set dispec i f i che appun to conve rgen t i : i l Po l i cyControl, da quanto appena descritto, dal puntodi vista tecnologico ha tutte le potenzialità peressere applicato in maniera omogenea in reticonvergenti.

Sebbene TISPAN si stia sempre più caratte-rizzando come l’architettura di riferimento perreti convergenti, una possibile interessante evo-luzione del modello appena illustrato viene dalFocus Group NGN (FGNGN) dell’ITU-T, che starecependo le specifiche TISPAN. In coerenzacon questo mandato, l’FGNGN ha analizzato ilRACS TISPAN e lo ha ulteriormente esteso indue direzioni: applicazione delle politiche anchenel core della rete e supporto di scenari inter-dominio.

5.4 Sicurezza, autenticazione ed accesso ai servizinelle reti convergenti

5.4.1 Sicurezza e autenticazione nelle reti convergenti

L’utilizzo dei servizi offerti dall’operatore di tele-comunicazioni alla propria clientela non può pre-scindere dagli aspetti di sicurezza correlati. In par-ticolare la sicurezza nelle reti convergenti ha princi-palmente due obiettivi:• proteggere contro l’accesso non autorizzato;• assicurare la confidenzialità della comunica-

zione.Un ruolo chiave nei sistemi GSM e 3GPP è

svolto dalla “carta” (nel GSM Subscriber IdentityModule o SIM) del cliente, che lo individua nelmondo dell’operatore. La carta infatti può esseretrasferita da un terminale all’altro, consentendo iltrasferimento della sottoscrizione ad un qualsivo-glia terminale mobile.

La “carta” è in realtà composta dal chip, laUICC (Universal Integrated Circuit Card), o la ICC(Integrated Circuit Card), e dalle diverse applica-zioni logiche che vi possono risiedere a bordo,come ad esempio quelle di USIM e di SIM.

Nella carta risiedono tutta una serie di parame-tri, tra cui i dati di sottoscrizione del cliente e i datidi autenticazione utilizzati nelle procedure di sicu-rezza. Il continuo sviluppo delle prestazioni in ter-mini di capacità di elaborazione e di memoria con-sente di utilizzare la UICC per memorizzare impo-stazioni preferenziali del cliente, rubriche telefoni-che, messaggi, ... Qui di seguito si riportano soloalcuni dei principali dati e parametri memorizzati inuna USIM (SIM):• IMSI (International Mobile Subscriber Identity):

è l’identità assegnata a ciascuna sottoscri-zione del cliente. Tale identità non è visibile alcliente stesso, ma viene utilizzata dalla reteper identificare quest’ultimo nelle procedure diregistrazione. L’IMSI consente infatti di indiriz-zare correttamente il database di HLR nellafase iniziale della registrazione in rete delcliente;

• chiave segreta K (Ki) di autenticazione; • parametr i d i conf igurazione (ad esempio

HPLMN, lista delle PLMN proibite/preferite,eventualmente parametri di configurazione per iservizi di SMS/MMS).

La UICC può contenere, oltre SIM e USIM,l’applicazione ISIM in cui sono contenuti i parame-tri utilizzati per l’identificazione del cliente e per lasua autenticazione nel dominio IMS.

I parametri principali memorizzati nella ISIMsono:• Private User Identity (IMPI): rappresenta l’iden-

tità del cliente nel dominio IMS, allo stessomodo in cui l’IMSI rappresenta l’identità delcliente nei domini a circuito e pacchetto dellereti GSM e UMTS.

• Public User Identity (IMPU): costituisce l’indi-rizzo pubblico associato ad un cliente, con ilquale cioè è noto ed identificabile da parte dialtri utenti. Nel dominio IMS l’IMPU è concet-tualmente identico alla numerazione pubblica diMobile Station ISDN Number (MSISDN) impie-gata nelle reti GSM e UMTS.

• chiave segreta di autenticazione: tale chiaveviene utilizzata nella procedura di autentica-zione e per il calcolo delle chiavi di cifratura(Ck) ed integrità (Ik) utilizzate nello scambiodelle informazioni tra terminale ed i nodi deldominio IMS.

• Home Network Domain Name, necessario per ilcorretto indirizzamento verso la rete Homedurante la procedura di registrazione nel domi-nio IMS.La ISIM assume quindi un ruolo fondamentale

nelle procedure di autenticazione per l’accesso aldominio IMS mobile. Lo standard 3GPP però nonesclude l’accesso all’IMS anche con la sola USIMattraverso meccanismi che consentono di ricavare,dai dati in essa memorizzati, le identità ed i para-metri per l’autenticazione.

Per le reti fisse NGN valgono sostanzialmentegli stessi requisiti di sicurezza individuati per lereti mobili, quindi viene recepita la necessità diautenticare gli utenti con meccanismi di autenti-cazione forte sia di assicurare la confidenzialitàdelle informazioni in transito. In TISPAN si staattualmente lavorando per individuare i meccani-smi di autenticazione forte applicabili ai terminalidi rete fissa.

Per garantire la compatibilità con i terminaliattualmente utilizzati e non vincolare sviluppi futuriè possibile prevedere anche la coesistenza didiversi supporti fisici (SIM, Smart Card, dongle, …)per ospitare le diverse IMPU di un utente.

Nelle reti convergenti potranno poi essere pre-senti opportuni meccanismi quali, per esempio,



ENUM (Telephone NUMber mapping), per indivi-duare l’IMPI del cliente autenticato tramite IMPU.

Sempre in TISPAN si sta verificando quale proto-collo adottare per proteggere la confidenzialità delleinformazioni in transito; tra i due possibili candidatiTLS (Transport Layer Security) e IPSEC (il 3GPP pre-vede l’impiego di IPSEC ESP nel dominio IMS traUE e P-CSCF per garantire l'integrità dei messaggiSIP) la scelta si potrebbe orientare a favore di TLSche non presenta criticità all’uso del NAT.

Anche i meccanismi di sicurezza ed autentica-zione elaborati da IETF e 3GPP (per GSM e UMTS),possono essere utilizzati nelle reti convergenti, conparticolare riferimento ai meccanismi di mutuaautenticazione e integrità.

La mutua autenticazione è la funzionalità checonsente, oltre alla autenticazione in cui la reteautentica il cliente (ovvero si assicura della suaidentità) anche la possibilità da parte del cliente diautenticare la rete stessa (network authentication).

L’integrità è invece la proprietà per la quale ilnodo ricevente (rete o terminale) è in grado di veri-ficare che la segnalazione ricevuta non sia stataalterata in modo illecito durante il percorso in rete.

5.4.2 Il profilo del cliente nelle reti convergenti

La centralizzazione dei profili, concetto natonelle reti radiomobili per garantire la mobilità delcliente, mantiene un ruolo assai rilevante anchenelle reti convergenti. Il punto di partenza è l’HLR(Home Location Register) della rete GSM, che con-tiene in modo centralizzato nel profilo del cliente idati di registrazione (ad esempio la localizzazione)e tutte le informazioni legate ai servizi sottoscrittida quest’ultimo (chiamate voce, dati, servizi SMS,e servizi a pacchetto). Nel record del cliente in HLRè presente anche l’IMSI, la numerazione che identi-fica in modo univoco la sottoscrizione nel mondoradiomobile e che in pratica ne rappresenta il “pun-tatore” di accesso, ed il numero telefonico MSI-SDN che identifica pubblicamente il cliente in rete.L’HLR contiene l’indirizzo del VLR/SGSN presso ilquale il cliente è registrato e partecipa alla proce-dura di autenticazione.

Da Rel. 5 come previsto dallo standard 3GPP(3GPP TS 23.008 e TS 23.002) in poi, l’evoluzionedell’HLR è l’Home Subscriber Server (HSS), il data-base per la centralizzazione dei dati del cliente uti-lizzato per il dominio IP Multimedia Subsystem, eche include i dati di HLR/AuC (figura 14).

HSS è il nodo centrale dove sono quindi memo-rizzate tutte le informazioni relative alla clientela,comprese quelle relative al dominio IMS. Tra leinformazioni che sono contenute nel nodo HSS sitrovano la localizzazione del cliente, il profilo diquest’ultimo con i servizi IMS sottoscritti, i dati diautenticazione ed autorizzazione, ed il nodo S-CSCF che deve gestire le richieste di servizio IMSdel cliente. Al profilo sono collegate l’identità pri-vata del cliente, che rappresenta la sottoscrizioneIMS (IMPI), e le identità pubbliche (IMPU).

Coerentemente con quanto definito nell’archi-tettura IMS 3GPP e recepito in ambito fisso da

TISPAN, anche per le NGN è stato definito ununico data base contenente il profilo del clienteIMS, denominato UPSF (User Prof i le ServerFunction) il cui contenuto è in questo momento infase di definizione. L’l’UPSF può essere visto comel’equivalente della parte IMS del HSS, quindi noncontiene né la parte HLR né la parte AuC, che sonodel resto specifiche delle reti radiomobili (in ognicaso non è escluso che vi saranno eccezioni aquesto principio per venire incontro a specificheesigenze delle reti fisse).

Per quanto riguarda i dati relativi al profilo IMSdel cliente le informazioni non si discostano inmaniera significativa da quanto memorizzato nelcaso mobile: sono infatti compresi i dati relativi allaidentificazione (Tel URI, SIP URI, ...), alla registra-zione e agli CSCF oltre che i dati relativi all’autenti-cazione, quali per esempio la SIP Key e il meccani-smo di autenticazione (DIGEST o AKA).

Con modalità simili a quanto avviene in ambitomobile l’autenticazione del cliente è svolta dall’S-CSCF che, interrogando l’UPSF, verifica le creden-ziali fornite con modalità dipendenti dal meccani-smo di autenticazione selezionato nel profilo.

5.4.3 Accesso ai servizi nelle reti convergenti

La registrazione IMS è la procedura con laquale il cliente fa richiesta di accesso al dominioIMS per usufruire dei servizi offerti. Essa prevedel’aggiornamento sia della presenza del cliente neldominio IMS sia del suo profilo di servizio neidiversi data base di rete.

Durante la procedura è previsto il riconosci-mento del cliente da parte del dominio IMS perl’autorizzazione ad accedere ai differenti serviziIMS sottoscritti. Ciò si realizza con l'autentica-zione a livello IMS che utilizza alcuni parametripresentati nel paragrafo 5.4.1. L'integrità dei mes-saggi SIP tra UE e P-CSCF e la confidenzialitàdegli stessi viene assicurata mediante opportunimeccanismi: ad esempio in 3GPP si utilizza il pro-tocollo IPSEC ESP.

HSS - Home Subscriber Server

HLRDati per domini

CS e PS

Dati per dominio

IMS

AuC(Authentication Centre)

DominiCS e PS

DominioIMS

DIAMETERMAP

CSHLRIMSMAP

PS

=====

Circuit SwitchHome Location RegisterIP Multimedia SubsystemMobile Application PartPacket Switch

FIGURA 14› Dati di HSS.



5.4.4 L'evoluzione delle metodologie di charging dei servizi

La possibilità di effettuare il charging in funzionedella particolare sessione o servizio richiesti dal clienteè una delle funzionalità previste nelle future architet-ture di charging. Ad esempio il sistema IMS abilita l’e-rogazione di servizi tradizionali e multimediali/video-conferenziali su reti a pacchetto, ciascuno con la ade-guata QoS. Differenti servizi utilizzeranno quindi lamedesima rete con un differente trattamento, in fun-zione della natura dell’informazione trasmessa.

Per poter applicare nuovi modelli di charging(oltre a quelli tradizionali su base tempo, volume edevento) è necessario quindi che i sistemi di billingpossano in qualche modo distinguere i contenuti deibyte scambiati tra rete e terminale (charging basatosul contenuto). Il sistema IMS ad esempio, cosìcome standardizzato, non favorisce nessun partico-lare modello ma offre all’operatore la massima flessi-bilità di poter impiegare la modalità di charging piùopportuna, fornendo informazioni circa il servizio odil contenuto richiesto dal cliente. La flessibilità intro-dotta è realizzata grazie alla possibile correlazionedelle informazioni di charging a livello di trasporto(nodi di rete) e di controllo IMS (servizio e contenuto),mediante la definizione di un’architettura completa dicharging di rete.

In questo contesto l’erogazione di servizi di tipoVoIP o multimediali, ad esempio, potrebbe essereeffettuata su base tempo, indipendentemente dalnumero di byte scambiati come pure una sessione diInstant Messaging potrebbe avere un charging su baseevento a prescindere dal volume di dati scambiato.

Ad una sessione di servizi combinazionali sipotrebbero applicare schemi di charging differen-ziati sulla base dei media coinvolti, applicandoschemi diversi per voce, video, audio e immaginiscambiate in modalità peer to peer (tassazioneanche su base contenuto).

La possibilità di aggiungere media alla sessioneda parte del chiamato, per arricchire la comunica-zione, potrebbe essere a carico di quest’ultimo ocon charging differentemente ripartito tra chia-mante e chiamato.

Infine la possibil ità di applicare/richiedereQuality of Service per le differenti sessioni abilita, aparità di natura di queste, la possibilità di applicarecharging differenti in modo coerente con il diversoimpegno di risorse in rete, ovvero con il livello diservizio offerto al cliente.

Le future architetture di charging per il dominioIMS prevedono la possibilità di effettuare il char-ging in modalità sia off line (tradizionalmente utiliz-zata) sia on line (charging in tempo reale, ad esem-pio per il prepagato).

6. Il posizionamento degli Operatori

La convergenza f isso-mobi le rappresentaun’opportunità sia di sviluppo di nuovi servizi con-vergenti in modo più veloce, sia di integrazione dipiattaforme con conseguenti risparmi di investi-menti e costi operativi.

In generale gli operatori di reti fisse sono semprepiù impegnati nella ricerca di soluzioni che consen-tano di contrastare la sostituzione del traffico voceda fisso a mobile e nello sviluppo di nuovi servizi avalore aggiunto che valorizzino l’impiego della largabanda; gli operatori di reti mobili hanno l’esigenza difacilitare lo sviluppo dei servizi multimedia gestendoefficacemente il mix di utilizzo delle infrastrutture2G/3G anche per i servizi voce; infine gli operatorisia di rete fissa che mobile mirano a mantenere iltraffico sulla propria rete anche fornendo servizi con-vergenti a valore aggiunto.

Non emerge una killer application per la conver-genza, bensì un insieme di servizi personalizzabiliche permettono di unificare le applicazioni (directory,mailbox), le informazioni, i metodi di autenticazione, icontratti e le modalità di pagamento indipendente-mente dalle tecnologie di accesso, fisse o mobili, uti-lizzate.

Esaminando le soluzioni adottate da vari opera-tori, è possibile individuare scenari di convergenzacentrati su:• Convergenza a livello di Terminale che richiede

apparati dual mode e può avere impatti medio-bassi in rete;

• Convergenza a livello di Rete che richiede funzio-nalità specifiche di rete e tecnologie come SIP,IMS, UMA e terminali single o dual mode capacidi interagire con le funzionalità di rete (fissa emobile);

• Convergenza a livello di Servizio come ad esem-pio l’abilitazione alla fruizione di uno stesso con-tenuto da diversi terminali, con opportuni adatta-menti di formati e/o diversi client (PC, TV conSTB, cellulare);

• Sinergia di tipo operativo ed infrastrutturale al finedi ridurre i costi complessivi anche con la ottimiz-zazione di strutture operative analoghe tra laparte fissa e mobile.Al fine di realizzare i modelli di convergenza fisso-

mobile gli operatori adottano soluzioni “WirelineCentriche” ovvero “Wireless Centriche”, rispettiva-mente più orientate ad utilizzare le risorse della retefissa o mobile. Altro tipo di segmentazione dellescelte è rispetto alla tipologia di servizi per leimprese o per utenza residenziale, con mobilità limi-tata alla sede dell’azienda e/o in casa (soluzione “sitebased”), o con piena mobilità (soluzione “nomadic”).

Riguardo le soluzioni più significative di conver-genza fisso-mobile, realizzate nel mondo (descrittenel riquadro “Servizi convergenti offerti dagliOperatori”) si consideri che:• le soluzioni convergenti fisso-mobile che stanno

emergendo sono soluzioni proprietarie orientate allaclientela business e presentano ancora un altogrado di immaturità tecnologica che riguardasoprattutto i terminali. Ad esempio, le soluzioniEnterprise Seamless Mobility, nata dalla collabora-zione Motorola, Avaya, Proxim (unite nell’organizza-zione SCCAN), MoWLAN di Kineto Wireless, OnePhone di Longobard, NomadicOne di BridegportNetworks, Enterprise Mobility di Norwood, hanno incomune la possibilità di usare un terminale contem-poraneamente come estensione WiFi di un derivato



Servizi Convergentiofferti dagli Operatori

• BT: “Bluephone”È un servizio di convergenza diterminale e di rete con modelloarchitetturale Wireless centrico enomadic (secondo la classifica-zione semplificata qui proposta).“Bluephone” è una soluzionecommerciale di BT in partnershipcon Vodafone, annunciata nel2004 e ancora in sperimenta-zione, che sfrutta un terminaledual mode GSM/Bluetooth carat-terizzato da un unico numerotelefonico. Questo terminale è ingrado di connettersi viaBluetooth ad un access point,quando si trova in prossimità diesso; in questo modo quandol’utente si trova nella propria abi-tazione può utilizzare la lineafissa. Si tratta quindi di un servi-zio convergente voce che com-bina l’aspetto di terminale conquello di servizio (accordo tra BTe Vodafone per gestire il cliente)e con quello di rete (si basa sulparadigma UMA). È previstaun’evoluzione del terminale conl’accesso radio WiFi.

• NTT DoCoMo, Motorola:“FOMA Handset for BusinessUsers”

NTT DoCoMo e Motorola hannoannunciato un accordo per lo svi-luppo a breve di un terminale 3GFOMA per gli utenti business(convergenza di terminale). Ilmodello architetturale della rete èWireless centrico e nomadic.Questo nuovo terminale saràcompatibile con l’infrastrutturaWiFi pubblica di DoCoMo e dialtri providers per i servizi dati;non è ancora chiaro se funzione-ranno anche servizi VoIP.Disporrà inoltre di un browser ingrado di visualizzare le normalipagine web e potrà essere usatoper vedere gli allegati di email invari formati. Il terminale suppor-terà connettività Bluetooth e fun-zionerà anche fuori dal Giapponeessendo compatibile con GSM.Non è ancora definita la possibi-lità di handover tra la rete mobilee WiFi.

• Korea Telecom: “Du”Korea Telecom (KT) ha lanciatonel 2004 il suo servizio di conver-

genza fisso-mobile denominato“Du” (convergenza di terminale edi servizio), in collaborazione conla sua partecipata mobile KoreaTelecom Freetel e Samsung. Sitratta di un servizio voce perclientela residenziale e business. Il modello architetturale della reteè Wireline centric e site based.Questo servizio è realizzato tra-mite un terminale dual modeBluetooth/CDMA di Samsung eun access point Bluetooth fornitoda KT. Tramite lo stesso termi-nale il cliente può effettuare siachiamate mobili, sia chiamatefisse quando è sotto la coperturadell’access point Bluetoothinstallato sulla propria linea fissa.Il terminale sceglie quale rete uti-lizzare in base alla potenza delsegnale ricevuto. Non è previstohandover trasparente al clientetra la rete mobile e stazione baseBluetooth.Gli utenti hanno la possibilità diricevere una bolletta unica omantenerne due separate. “Du” èun esempio rappresentativo dellaconvergenza fisso-mobile pervoce, realizzata principalmente alivello di terminale (sul terminaleSamsung sono fruibili due servizivenduti anche disgiuntamente daKT e KTF. I problemi di maggiorrilevanza, oltre alle restrizioniregolatorie, sono il costo moltoelevato del terminale e dell’ AP el’inconveniente della caduta dellechiamate quando ci si muove aldi fuori dell’area coperta dall’AP.

Cingular: “FastForward”Questo servizio di “pseudo-con-vergenza” (si tratta di un “callforwarding” ) è offerto daCingular, operatore di telefoniacellulare negli Stati Uniti(modello architetturale wirelinecentric, site based) al fine di farrisparmiare il cliente sul trafficomobile ricevuto. “FastForward” èsemplice da utilizzare perché ilservizio si attiva automatica-mente inserendo il telefono cel-lulare in una apposita basettaquando si è in casa (o ufficio) eprogrammando il numero fissosu cui si vuole ricevere l’inoltrodelle chiamate.

• Verizon: “Iobi”“Iobi” è un servizio per clientiresidenziali proposto da Verizon,operatore telefonico USA fisso e

mobile. “Iobi” consente digestire dal PC chiamate, mes-saggi, voicemail ed email . Sitratta in sostanza di un portaleinternet dal quale è possibilecontrollare le impostazioni ealcune caratteristiche a valoreaggiunto del proprio servizio. Ilportale offre interfacce userfriendly per gestire le casellevocali, le email, le telefonateperse; consente di visualizzare ilcaller ID delle chiamate; con-sente infine di accettare o rifiu-tare le chiamate in arrivo. Inoltreun sistema di call forwardingintelligente dà la possibilità diricevere le telefonate sul proprioPC, sul proprio telefono cellularee indipendentemente da comeviene inviato un messaggio ilcliente può scegliere se riceverlocome email, voicemail o SMS.I servizi forniti da Iobi sono frui-bili oltre che dal proprio PC dicasa, anche tramite una interfac-cia vocale accessibile da telefonimobili o fissi. “Iobi” si può consi-derare come un’offerta conver-gente a livello di servizio ma nondi rete. Il modello di rete èWireline centric e site based.

• France Telecom/Orange:“Business Everywhere”

France Telecom/Orange ha lan-ciato l’offerta “BusinessEverywhere” che permette aipropri clienti corporate unaccesso mobile unificato alleinformazioni e applicazioni azien-dali attraverso varie tecnologie diaccesso: WiFi, GPRS, ADSL ePSTN. Il supporto per l’UMTS(3G) è dichiarato come immi-nente. Questa soluzione di“nomadismo” integra le soluzionidi rete di France Telecom,Wanadoo, Orange ed Equant,permettendo ad un lavoratorel’accesso alle informazioni azien-dali anche tramite rete cellulare enegli hot-spot pubblici sottoscri-vendo un solo abbonamento.L’offerta consiste in un unicoconto, un solo CRM, una solapassword di autenticazione, edun unico kit di connessione pertutte le reti. Grazie alla partner-ship con Orange e con altri provi-ders di hotspot viene garantitol’accesso a hotspot WiFi nellemaggiori aziende, aeroporti, hotelin più di 16 nazioni in Europa,Nord America e Asia-Pacifico.



IP PBX e come cellulare sia per dati che per voce.Tuttavia terminali di questo tipo sono disponibilisolo come prototipi (con software proprietario dainstallare sul terminale).

• Il contesto regolatorio e di mercato condiziona gliapprocci degli operatori verso la convergenza. Leiniziative commerciali di successo, come quelle diVerizon (“IoBi”) e Cingular (“Fastforward”), siinquadrano nel contesto regolatorio e di mercatostatunitense che presenta alcune importanti diffe-renze rispetto al contesto europeo, tali da apriremaggiori opportunità di soluzioni tecniche diofferta. Negli Stati Uniti (e Canada) esiste un unicopiano di numerazione per i servizi fissi e mobili(con le ovvie conseguenze sui piani di tariffazione).Il piano di numerazione unico non distinguendotra utenze fisse e mobili può semplificare l’offertadi servizi convergenti. Inoltre, poiché le chiamateverso terminali mobili localizzati fuori dalla propriaarea di servizio primario sono a carico del chia-mato (e non del chiamante), riscuotono molto inte-resse da parte della clientela i servizi di “conver-genza” quali il reinstradamento automatico dellachiamata da mobile a fisso quando il cliente sitrova presso la propria abitazione od in ufficio.In ambito europeo ed asiatico alcune offerte

commerciali sono state solo annunciate (es.BluePhone di BT e FOMA di NTT DoCoMo per clientibusiness) o, se lanciate, non hanno ancora riscossoun grande successo per motivi legati alla difficoltà diutilizzo del servizio, al costo del terminale o a bar-riere regolatorie (per esempio, Du di Korea Telecom).

L’evoluzione a medio–lungo termine, condivisadalla maggior parte degli operatori, è quella basatasul model lo IMS/NGN def in i to in ambito3GPP/TISPAN, su cui anche il Gruppo TelecomItalia si sta orientando.

7. Le prospettive future

L’evoluzione dei servizi e delle reti di telecomuni-cazione è determinata in generale da tre fattorichiave:• bisogni dei clienti (unitamente alla “willingness to

pay” associata a specifiche necessita’); • tecnologie abilitanti (non solo da un punto di vista

“tecnico”, ma anche “economico”);• disponibilità di standard adeguati (in assenza dei

quali si può assistere a realizzazioni “di nicchia”,ma raramente l’innovazione tecnologica è ingrado di raggiungere fattori di scala sufficienti asoddisfare i bisogni della massa dei clienti).Anche le prospettive future di architetture e tec-

nologie per la convergenza fisso-mobile sarannocondizionate in primo luogo all’evoluzione dei “biso-gni di comunicazione” di persone e “macchine” (nonsolo PC e server, ma anche sensori e microchip inte-grati negli “oggetti” più disparati).

Senza tentare di prevedere gli specifici “servizi”richiesti nel lungo termine alle reti, possiamo assumereche, come “valori” per il cliente, acquisiranno un pesosempre maggiore: “the freedom of mobility”; “the easymultimedia experience”; “security and personalization”.

In prospettiva, almeno fino alla esistenza di unabase GSM ed UMTS “R99” importante, la voce a cir-cuito rappresentarà per il mobile ancora un serviziofondamentale, arricchito da videocomunicazione e“Rich calls” (UMTS ed EDGE).

È ragionevole assumere che permanga l’attualeelevato valore di comunicazione personale delmobile. In funzione dell’affermarsi dei servizi “con-vergenti”, gli attuali “premio di mobilità “ e “premiodel rame” (alla base dell’attuale sviluppo della largabanda “wired”) potranno essere progressivamentesostituiti da un “premio di fruibilità”, con connettivita’“broadband mobile” ossia un premio legato alla pos-sibilità di accedere alle applicazioni e servizi con ilmiglior compromesso tra tipo di accesso e servizio. Iclienti potranno infatti attribuire crescente valore allapossibilità di fruire di “tutti” i servizi (voce, dati, multi-media, content, …) in modo “indipendente” dall’am-biente in cui si trovano (in casa propria, in casa diterzi, in luoghi di lavoro, in luoghi pubblici, all’aperto)essendo sempre “riconosciuti” dalla rete sulla basedel loro profilo personale.

Per quanto riguarda i bisogni dei clienti, il futurodella convergenza sarà quindi caratterizzato daaccesso ubiquo seamless alla pluralità dei servizi epersonalizzazione nella fruizione abilitata da un pro-filo unico.

Le opportunità abilitate dall’evoluzione tecnolo-gica dipenderanno probabilmente sia da singoleinnovazioni sia (forse in modo preponderante) dacome queste potranno integrarsi nell’architettura direte complessiva secondo criteri di sostenibilità eco-nomica e quindi anche di compatibilità con le“legacy”.

Provando qualche esemplificazione, si può ipotiz-zare che le tecnologie di accesso mobile evolve-ranno verso il wireless broadband non solo nelladirezione rete-terminale (downlink) ma soprattuttonella direzione opposta (uplink) per supportare effica-cemente le applicazioni multimediali person to per-son. La QoS nel dominio PS potrà portare VoIPanche su accesso mobile, ma con forte necessità dipresidio del controllo di qualità e charging del servi-zio. Nel contempo SIP/IMS potranno rappresentareuno dei driver di sviluppo della comunicazione per-son to person anche su accesso mobile a pacchetto.IMS potrà aumentare l’efficienza di sviluppo deinuovi servizi e contribuire all’evoluzione più marcata-mente IP centrica della rete anche in ottica di con-vergenza fisso - mobile.

Le caratteristiche delle soluzioni architetturali etecnologiche che saranno perseguite dipenderannofortemente da come sarà interpretato il requisito di“mobilità”. Nel lungo termine crescerà la varietà ditecnologie di accesso radio disponibili e di terminalianche “multimodali”.

Una sfida per gli ingegneri ed i pianificatori saràquella di disegnare e mettere in campo reti in cuitale “varietà” (e la conseguente specializzazionenegli apparati di rete), pur nel rispetto delle diversecaratteristiche e requisiti, rimanga il più possibile“confinata” ai segmenti di accesso della rete, men-tre l’integrazione (cioè l’utilizzo uniforme e condi-viso di soluzioni, apparati, protocoll i , r isorse



hardware e software) s iapervasiva in tutti gli altri seg-menti dell’architettura.

Un’altra sfida sarà la rea-lizzazione di soluzioni perautenticare il cliente in qua-lunque circostanza, mante-nerne il profilo (unico, perso-nalizzato, dinamicamenteaggiornabile, sempre acces-sibile) e mantenere dinamica-mente aggiornate le informa-zioni di contesto in cui i lcliente si trova (con riferi-mento alle sue esigenze dicomunicazione: ad esempiola location, caratteristichedel/dei terminali che utilizza,caratteristiche del/degliaccessi di rete di cui puòusufruire, privilegi, … ).

Facilitare lo sviluppo diapplicazioni e servizi “nativa-mente” convergenti tenderà arichiedere sempre più unaarchitettura complessiva(figura 15) con un livello di controllo/servizio “inte-grato” (con DB e server di rete “indifferenziati”rispetto alle tecnologie utilizzate nell’accesso), mobi-lity management, profiling, location management,AAA, presence management, ... gestiti in modo inte-grato su un livello di trasporto/commutazione resoomogeneo dall’adozione estesa della tecnologia IP.

Questa vision di lungo termine sta raccogliendoconsensi dell’industria e della normativa.

La disponibilità di standard internazionali adeguatisarà condizione necessaria per garantire a condizionieconomicamente sostenibili service, device, networkinteroperability anche in ambito fisso-mobile.

In questo articolo abbiamo descritto come gliambienti di standardizzazione sia delle reti mobiliche delle reti fisse tendano a concordare nel consi-derare l’IMS l’approccio convergente per il livellocontrollo/servizio e che, inoltre, non ci sono propo-ste diverse dall’IP per il trasporto metro/backbone.

Tuttavia differenze (e difficoltà) nascono ad esem-pio nel modo di concepire il livello di accesso: fino ache punto confinare la “specializzazione” necessariaper garantire la connessione di terminali eterogenei?Quali funzionalità collocare nel livello di accesso?L’accesso deve concettualmente essere costituitosolo da “modem/concentratori” che gestiscono inmodo specializzato il “mezzo fisico”, convogliano iltraffico da/verso il metro/core IP (eventualmenteconvertendo il traffico che non “nasca IP” dai termi-nali) e adattano la segnalazione per riportarla aquella utilizzata dal livello servizio/controllo?

Oppure il livello di accesso comprenderà vere eproprie reti, che trattano il traffico e la segnalazione,e si interconnettono al metro-core mediante“gateways” di complessità funzionale anche alta?Nella risposta a queste domande c’è probabilmentela chiave per determinare come evolverà la “conver-genza fisso-mobile” nel lungo termine: quanto più la

specializzazione nell’accesso sarà confinata in “nodid’accesso” periferici “semplici”, tanto più la fruizionedei servizi potrà essere resa ubiqua e seamless.

L’evoluzione delle reti, tecnologie e standardverso la convergenza probabilmente porterà a pro-vare diverse strade prima di trovare quella in gradodi affermarsi e sostenersi nel business.

8. Conclusioni

Sta crescendo a livello mondiale l’interesse per laconvergenza fisso-mobile. Ciò è dovuto a diversi fat-tori fra cui le richieste di nuovi servizi in mobilità daparte del mercato e la disponibilità e maturità di nuovetecnologie. Nel contesto nazionale, Telecom Italia haillustrato, nell’ultimo incontro con la ComunitàFinanziaria, la scelta strategica di Gruppo verso laconvergenza indicandone le motivazioni tecnico/eco-nomiche e gli impatti nel breve/medio termine.

La “convergenza” nelle telecomunicazioni èspesso stata oggetto di interesse; in questo articolosono stati presentati i fattori abilitanti ed i driver perla convergenza fisso-mobile nella rete e nei servizi.

La convergenza fisso-mobile su IP per voce edati, su cui anche il Gruppo Telecom Italia si staorientando, è basata sul paradigma IMS/NGN.Soluzioni di questo tipo sono di prossima disponibi-lità, seppur con un certo grado di “immaturità tecno-logica” degli apparati, grazie anche al progressivoconsolidamento degli standard internazionali.

La strada tuttavia appare tracciata: entro qualcheanno la convergenza fisso-mobile basata su IMSpotrà realizzarsi.

Si ringraziano per la collaborazione:Andrea Laganà e Andrea Cavallero, TILAB;Luca D’Antonio, TIM.

SessionManager

MobilityManager

AccessiBroadband “Wired”

AccessiBroadband “Wireless”

Accessi “Mobile Wireless”

INTEGRAZIONE

SPECIALIZZAZIONE

- --

PresenceServer

SERVIZIO/CONTROLLO

TRASPORTOMetro-Core

HOMEMOBILE OFFICE

UTENTE

ACCESSO

- - -

UserProfile DB

NetworkLocation &

Context

FIGURA 15› Architettura long term per la convergenza.



Daniele Ceccarelli si è laureato con lodein Ingegneria delle Telecomunicazioni pressol’Università di Roma “La Sapienza” nel 1999. Èentrato in TIM dal 2000 nell’area di Commutazione,tecnologie ed industrializzazione di core network,dove ha seguirto le tematiche di Voice over IP e ditrasporto della segnalazione su IP nella rete TIM.Dal 2001 collabora al progetto di introduzionedella tecnologia UMTS di core network, seguendogli aspetti legati al dominio a circuito, e agli

algoritmi di autenticazione in rete. Collabora con la scuola SSGRR aicorsi di formazione per personale TIM su tecnologie di core network. Èimpegnato nell’evoluzione e sviluppo della rete UMTS di TIM, conr i fer imento a l le nuove archi tet ture di core CS e a l le suefunzionalità/servizi (videochiamata).

Stefano Marino si è laureato con lode inIngegneria Elettronica nel 1992. Dopo un Masterin TLC presso ISSPT e una esperienza lavorativain Ericsson è stato assunto in SIP (oggi TelecomItalia) nel 1994 nella linea dei sistemi di gestionedella Rete come responsabile del sistema CEM(sistema di supervisione delle centrali) con ilcompito di curarne la definizione delle specifichefunzional i e i l coordinamento del gruppo dicollaudo presso il test plant e in esercizio. Dal

1/2000 al 1/2004 ha svolto l’attività di technical manager del progettoRESEAU, sperimentazione in campo di rete e servizi Internet di nuovagenerazione. Attualmente opera nella funzione Pianificazione Tecnica eArchitetture, per definire l’innovazione delle architetture di rete.

Giovanni Cecconi si è laureato in IngegneriaElettronica, specializzazione Telecomunicazioni,presso l’Università di Bologna nel 1994. Dopo unaesperienza consulenziale in ambito gestionale, nel1996 ha iniziato a collaborare con CSELT (oraTILAB) occupandosi di prove di qualificazionefunzionale di apparati della rete di accesso GSM.Nel 1997 è entrato in TIM nel settore Collaudi dellafunzione Rete di Accesso occupandosi dellaverifica e validazione degli apparati GSM/GPRS e

delle prime verifiche funzionali sui trial UMTS. Dal 2001partecipa alladefinizione e pianificazione delle architetture di rete nell’ambito delsettore Sviluppo Architetture e Tecnologie della funzione NetworkPlanning di TIM.

Daniele Roffinella si è laureato con lodein Ingegneria Elettronica presso il Politecnico diTorino nel 1982, e dallo stesso anno opera inTILAB (già CSELT). Dopo aver guidato numerosiProgetti, anche di cooperazione e di normativainternazionale, nel settore delle reti locali, delle retimetropolitane a larga banda e dell ’ATM, haassunto la responsabilità di una Linea di Ricercaimpegnata nel le speci f iche dei s istemi d icommutazione e dei servizi POTS ed ISDN. Dal

1994 al 2001 è stato il responsabile della Linea di Ricerca TILABavente mandato sulla Rete Intelligente e sulle piattaforme innovative dicontrollo e creazione servizi (fra cui piattaforme SIP-based), per retif isse e per reti mobili. Dopo un’esperienza in ambito BusinessInnovation, dal 2004 si occupa di sistemistica ed architetture per laconvergenza fisso-mobile.

Alberto Ciarniello è responsabile per loSviluppo Architetture e Tecnologie nell’ambito dellafunzione Network Planning della Direzione ReteTIM, dove in precedenza si è occupato dei pianitecnici per le iniziative di sviluppo internazionale edi contro l lo del la gest ione tecnica del leconsociate. Laureato al Politecnico di Milano inTelecomunicazioni, ha lavorato nei Laboratori dellaGeneral Electric a Londra, in TILab a Torino edistaccato per T IM presso l ’European

Telecommunications Standards Institute (ETSI) a Sophia Antipolis(Francia) nell’ambito di progetti sui sistemi mobili innovativi.

Paolo Senesi si è laureato in IngegneriaElettronica al Politecnico di Torino nel dicembre del1994. Dal 1995 opera in TILAB (già CSELT) dovesi è occupato in iz ia lmente dei protocol l i disegnalazione per reti ATM, partecipando ancheagli enti di normativa ITU-T, ETSI, ATM Forum eMult iservice Switching Forum. Dal 1999 sioccupa di ret i di nuova generazione comeresponsabile di diversi progetti di ricerca sulle retiNGN dal punto di vista del controllo, segnalazione

e armonizzazione architetturale complessiva. Ha condotto diversesperimentazioni di soluzioni innovative di voce a pacchetto ed ha tenutonumerosi corsi alla SSGRR sulle reti NGN. Attualmente è responsabiledi un progetto al l ’ interno del quale si occupa di coordinare lapartecipazione Telecom Ita l ia ad ETSI TISPAN, partecipandoattivamente ai lavori legati alle architetture NGN, con l’obiettivo diarmonizzare gli standard NGN in via di definizione con la piattaformaTelecom Italia per la fornitura di servizi multimediali a valore aggiunto suaccessi BB.

— ABBREVIAZIONI

3GPP 3rd Generation Partnership ProjectAMR Adaptive Multi RateAuC Authentication CentreBGCF Breakout Gateway Control FunctionCDMA Code Division Multiple AccessCDR Call Data RecordEDGE Ehnanced Data rates for Gsm EvolutionEUTRA Evolved UTRAFDMA Frequency Division Multiple AccessGAN Generic Access NetworkGERAN GPRS EDGE Radio Access NetworkGGSN Gateway Gprs Support NodeGPRS General Packet Radio SystemHSDPA High Speed Downlink Packet AccessHSS Home Subscriber ServerICC Integrated Circuit CardI-CSCF Interrogating CSCFIM-MGW IP Multimedia – Media GatewayIMS: IP Multimedia SubsystemIMSI International Mobile Subscriber IdentityIP-CAN IP Connectivity Access NetworkIPsec IP securityISIM IMS SIMMGCF Media Gateway Control Function MGW Media GatewayMRFC Multimedia Resource Function ControllerMRFP Multimedia Resource Function ProcessorMSISDN Mobile Station ISDN NumberNGN Next Generation NetworkOFDM Orthogonal Frequency Division MultiplexingP-CSCF Proxy CSCFPDF Policy Decision FunctionPLMN Public Land Mobile NetworkPOC Push to talk Over CellularSBLP Service Based Local PolicyS-CSCF Serving CSCFSGSN Serving Gprs Support NodeSGW Signalling GatewaySIGTRAN Signaling TransportSIM Subscriber Identity ModuleSLF Subscription Locator Function TACS Total Access Communication SystemTDMA Time Division Multiple AccessTHIG Topology Hiding Inter-network GatewayTSG Technical Study GroupUICC Universal Intergrated Circuit CardUMA Unlicensed Mobile AccessUMTS Universal Mobile Telecommunication SystemUSIM Universal Subscriber Identity ModuleUTRA UMTS Terrestrial Radio Access


Evoluzione della piattaformadi segnalazione verso la

tecnologia IP

GIOVANNI CICCOLELLA

MARCO DE LUCA

SANDRO PERLINI

La crescita del traffico dei servizi a valore aggiunto basati sul servizio ShortMessage e l’elevato numero di clienti raggiunto dai sistemi radiomobili haspinto l’industria delle Telecomunicazioni a definire soluzioni volte ad ovviarealle limitazioni di scalabilità della rete di segnalazione SS7, che garantisce lagestione della mobilità dei clienti e dei servizi. In questo contesto, TIM Italiaha intrapreso un percorso di evoluzione della piattaforma di segnalazioneverso la tecnologia IP realizzando un’architettura per il trasporto del trafficoSM (Short Message) a livello nazionale; successivamente, l’esperienzamaturata ha permesso di adattare tale soluzione per offrire, con tempi ecosti ridotti, servizi a valore aggiunto ai clienti mobili delle consociate estereriutilizzando le piattaforme di servizio di TIM Italia. Tale esperienza sarà allabase del percorso evolutivo della piattaforma di segnalazione per le reti e iservizi GSM/GPRS/UMTS ed IMS.

1. Introduzione

Lo sviluppo e la realizzazione di una rete multiservi-zio che permetta di fornire al cliente l’insieme dei ser-vizi e all’Operatore di gestire un’unica infrastruttura direte, sono state, negli ultimi anni, uno dei principali dri-ver di evoluzione. Nel mercato, lo sviluppo di Internet edei servizi dati ha permesso alla tecnologia IP di rag-giungere una pervasività e capillarità sempre più similia quelle della reti di telefonia e al traffico dati di sor-passare quello voce; tale fenomeno ha fatto sì che iltraffico dati abbia sorpassato il traffico voce. Tutti que-sti fattori fanno sì che ci sia un diffuso accordo, all’in-terno dei principali attori dell’industria, nel prevedereche la tecnologia IP sarà alla base delle reti di teleco-municazioni del futuro integrando varie tecnologie diaccesso per fornire un insieme molto vasto di servizi,ovviamente di tipo dati ma anche voce, realizzandocosì il paradigma della rete multiservizio.

Parte di questo percorso evolutivo è stato giàpercorso attraverso un forte impegno nella defini-zione e lo sviluppo della tecnologia per intergare ser-vizi voce (VoIP) su una rete dati di tipo IP. Al cresceredell’interesse mostrato dagli Operatori nell’integrarela tecnologia IP all’interno delle reti di telefonia(PSTN/PLMN), il cui “sistema nervoso” è il sistemadi segnalazione SS7 (Signalling System n.7) pergarantire l’accesso ai servizi, l’industria si è confron-tata per definire la soluzione per garantire l’interla-voro tra le tecnologie SS7 e IP e il trasporto disegnalazione di servizio su rete IP. Alla fine degli anniNovanta, si è imposta sul mercato la tecnologia SIG-TRAN (SIGnalling TRANsport) definita in ambito IETFe presto abbracciata e armonizzata dagli enti distandardizzazione 3GPP, ETSI e ITU come il riferi-mento per il trasporto della segnalazione, sia tradi-zionale SS7 che innovativa SIP (Session InternetProtocol), nella rete multiservizio del futuro.

PIATTAFORME

CICCOLELLA › DE LUCA › PERLINI • Evoluzione della piattaforma di segnalazione verso la tecnologia IP


TIM è stata pioniere nell’introduzione di questatecnologia nella rete mobile attraverso la realizza-zione di una rete dedicata per il trasporto del ser-vizio Short Message (SMS over IP) per far frontead un incremento del traffico del servizio e ottimiz-zare i costi, grazie anche all’impiego di una rete IPmultiservizio.

2. Drivers ed obiettivi

Se per una qualunque rete di telecomunicazioniil sistema di segnalazione rappresenta il sistemanevralgico che consente la fornitura di un canale dicomunicazione tra utenti e l’accesso ai servizi, peruna rete radiomobile, il ruolo, nonché il peso, dellasegnalazione risulta ancor più significativo e fonda-mentale.

Va precisato infatti che il sistema di segnala-zione SS7 di un Operatore mobile si avvale inambito di core network di diverse componenti:• MAP (Mobile Application Part), per la gestione

della mobilità d’utente, dei servizi supplemen-tari e del servizio SM (Short Message);

• ISUP (ISDN User Part) per la gestione dellachiamata;

• INAP (Inteligent Network Application Part) per iservizi di rete intelligente;

• CAP (CAMEL Application Part) per la gestionedell’utenza roaming e di alcuni servizi.Il servizio di Short Message si avvale del proto-

collo MAP, ovvero di messaggi o pacchetti disegnalazione SS7, per veicolare sia il contenutod’utente, ossia il testo dello Short Message, che laprocedura di segnalazione per espletare la conse-gna dello Short Message.

Fino ad oggi, il trasporto dellaMAP tra MSC/VLR, HLR ed SMSCè stato assicurato, dalla comunerete di segnalazione ‘core’ basatasui nodi di transito TDM (figura 1).

Negl i u l t imi anni , sul la retemobile TIM Italia sono stati regi-strati incrementi elevati del trafficodi segnalazione, in termini di quotarelativa al singolo utente e com-plessivamente per la crescita del-l’utenza.

In particolare, negli ultimi cin-que anni, i l traffico di segnala-zione MAP che gestisce la mobi-lità d’utente (HLR) ha subito incre-menti del 50% circa, passando da30 Mbit/s di traffico di segnala-zione (uplink e downlink registratoa livello dei nodi di transito) adoltre 45 Mbit/s attuali. Tuttavia,mentre nel 1999 l’incidenza deltraffico MAP per Short Messagerispetto alla quota parte di mobi-lità era minima (inferiore al 5%), ilvalore attuale di traffico di segna-lazione che gli Short Message svi-luppano sull’interfaccia da/verso

gli SMSC (Short Message Service Centre) è diassoluto r i l ievo. Infatt i , osservando quantomostrato in figura 2, si notano due aspetti dirilievo:• un trend d’incremento costante annuo dal 1999

ad oggi del volume medio giornaliero di SMS; • un andamento distribuito nell’anno con picchi di

concentrazione nel periodo natalizio di ciascunanno.La peculiarità del servizio SM e l’utilizzo mas-

siccio in particolari periodi dell’anno (caratteriz-zato dal brusco picco ricorrente nel periodo diNatale-Capodanno, evidenziato in figura 2 con lefrecce che indicano le percentuali di incrementodel valor massimo rispetto al valor medio), hannocomportato a livello di rete, impatti elevati con-centrati sul le r isorse di nodo e di trasporto.Inoltre, è da notare che in alcuni giorni particolarisi verif icano incrementi nell’ora di picco finoanche a dieci volte il volume medio nell’orarioordinario. Pertanto, durante le festività, il trafficoper Short Message, a causa della mobilità dell’u-tente, viene ad assumere volumi comparabili conquelli relativi al traffico MAP.

Prima dell’introduzione della core network disegnalazione dedicata al servizio di Short Message(SMS over IP), la rete tradizionale di segnalazionebasata su tecnica TDM, gestiva in modo condivisotutte le componenti SS7 (SMS, mobil ità, …).Pertanto, al fine di garantire in primis il trasportodella componente di mobilità, assai delicata edimportante, la comune rete SS7 doveva esseredimensionata tenendo conto non solo del trafficoSS7 ordinario, ma anche del l ’andamento nelperiodo natalizio del traffico SMS, ossia di quei

SMSC SMSC

SGw SGw

SGw SGw

IP Network

SCP HLR

TR TR

MSC/VLR MSC/VLR

SS7/TDM Network

SS7/TDM Network

TR TR

SCP HLR

TR TR

TR TR

MAP - mobilità ISUPINAP/CAP MAP - SMS

CAPHLRINAPISUPMAPMSCSCP

=======

Camel Application PartHome Location RegisterInteligent Network Application PartISDN User PartMobile Application PartMobile Switching CentreService Control Point

SGwSMS

SMSCSS7TDM

TRVLR

=======

Signalling GatewayShort Message ServiceSMS CentreSignalling System n. 7Time Division Multiplexnodo di TRansitoVisited Location Register

FIGURA 1› Evoluzione della rete di segnalazione per SMS.



picchi della componente MAP per SM che comun-que andavano ad erodere le risorse di segnala-zione comuni.

La soluzione adottata è stata, pertanto, quelladi dedicare nuove risorse di nodo e di rete per ilservizio SM al fine di preservare sulla piattaformatradizionale la delicata componente MAP relativaalla gestione della mobilità dei clienti.

In conclusione la creazione di una core networkdi segnalazione basata su IP per il servizio SM(figura 1) ha consentito di:1) separare le problematiche relativa alla mobilità

e al servizio SM;2) utilizzare tecniche di trasporto, nodi e tecnolo-

gie dedicate, che, tenendo conto della specifi-cità del servizio, comportino minori investimentirispetto a quelli necessari per ampliare i nodiTDM adibiti a nodi di transito voce e segnala-zione;

3) implementare una soluzione già orientata afuture evoluzioni (in linea con gli standard). I l punto 1) ha avuto come primo r isultato

quello di ridurre il traffico di segnalazione sui nodidi transito e di recuperare risorse di segnalazione.I punti 2) e 3) hanno comportato l’orientamentoverso soluzioni basate su tecniche di trasporto ditipo IP.

Tale scelta ha portato a migrare il trasportodella segnalazione da una rete dedicata ad altaaffidabilità ad un Backbone IP multiservizio. Se daun lato ciò ha consentito di utilizzare, con investi-menti ridotti, una piattaforma di trasporto preesi-stente (la rete IP TIM Italia: Unigate) condivisa conaltri servizi, dall’altro tale condivisione ha richiestoadeguate garanzie sulla qualità del servizio offerto.D’altra parte, la modalità “Store and Forward”, pro-pria del servizio SM, consente di gestire medianteretry (tentativi successivi) l’eventuale mancata con-segna dello Short Message offrendo così ancheuna robustezza intrinseca rispetto a situazioni dicongestione del backbone IP.

3. Evoluzione piattaformadi segnalazione

3.1 Architettura tradizionaledella rete di segnalazione di TIM Italia

Come descritto nel capi-tolo precedente, la rete disegnalazione garantisce iltrasporto del traff ico disegnalazione per il set-updelle chiamate voce (ISUP),la gestione della mobilità del-l’utente (MAP [1]), la fornituradel servizio SMS (MAP) e lafruizione dei servizi di ReteIntelligente (INAP o CAP).

La struttura della rete disegnalazione garantisceun’infrastruttura di comunica-zione a tutti i nodi della retemobile GSM, ovvero

MSC/VLR, HLR, SMSC e i nodi di Rete Intelligente.Dato l’elevato numero dei nodi da interconnettere inrete TIM Italia, l’attuale rete di segnalazione, illustratain figura 3, possiede un’architettura gerarchicabasata su nodi di trasferimento della segnalazioneSTP (Signalling Transfer Point) che garantiscono iservizi di instradamento e smistamento del traffico.

L’architettura è strutturata in regioni di segnala-zione, ognuna delle quali è composta da:• un insieme di MSC/VLR raggruppati in base a

criteri geografici e di appartenenza ad enti terri-toriali;

• la globalità degli HLR (Home Location Register)dove risiedono i profili di utente;

• un nodo SMSC (Short Message Service Centre)che riceve, mantiene ed invia secondo unalogica store&forward i messaggi SMS di tipotestuale;

• alcuni nodi di Rete Intelligente SCP (ServiceControl Point) dove risiedono le logiche dei ser-vizi;

• una coppia di nodi TR/STP che eseguono fun-zionalità di:

- Transito (TR) per il traffico voce tra diverseregioni di segnalazione e anche all’internodella stessa regione;

- Signaling Transfer Point (STP) per instradareil traffico MAP;

- Punto di Interconnesione (PdI) con OLO(Other Licensed Operators).

Per garantire il livello di affidabilità necessarioogni nodo è sempre connesso ad almeno i duenodi che formano la coppia di STP; in particolare:• ogni MSC/VLR e ogni SMSC è attestato alla

coppia di nodi STP della regione.• ogni HLR è attestato a tutti i nodi STP in modo

che il numero di segnalatori sia sufficiente asmaltire il traffico sviluppato per la gestionedella mobilità, che risulta essere la maggioranzadel traffico totale. In questo modo si garantisceil passaggio attraverso un solo nodo STP.

60

50

40

30

20

10

1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q

2003200220012000

Media giornaliera Variazione percentuale tra valore di piccoe valore medio nel periodo

80%

77%

91%80%

0

FIGURA 2› Evoluzione del traffico di segnalazione legato a SM in rete TIM Italia.



Queste regole praticheper la progettazione dell’ar-chitettura del la rete disegnalazione possono tro-vare delle eccezioni dovutea situazioni legate a vincolidella rete reale in campo.

3.2 Il sistema di segnalazione SS7

Così come def in i to inITU-T durante gl i anniNovanta, la rete di segnala-zione è basata su sistemaSS7 (Signalling System n.7),formato da due parti:• la rete di segnalazione

MTP (Message TransferPart) che offre i servizi diinstradamento;

• gli utilizzatori (User Part)che garantiscono le logi-che per la gestione delsetup delle chiamate edei servizi supplementari(ISUP); della mobilità del-l’utente e del servizio SM(MAP); dei servizi di ReteIntelligente (INAP).I livelli utilizzatori fanno

affidamento su robustezza eperformance della rete disegnalazione per garantire laqualità f inale del serviziopercepita dal c l iente (adesempio tempo di call setup di una chiamata,tempo di attach da parte di un utente mobile).

La rete di segnalazione MTP (Message TransferPart) è una rete a commutazione di pacchettobasata su link di livello 2 con capacità di 64 kbit/sricavati dai time slot della rete di trasporto TDM(Time Division Multiplex).

L’architettura della rete di segnalazione prevededue tipologie di nodi:• SEP (Signalling End Point) presso i quali risie-

dono i livelli utilizzatori che coincidono conMSC/VLR, HLR, SCP, SMSC;

• STP (Signalling Transfer Point) che eseguonosolo funzionalità di instradamento e presso iquali non risiedono i livelli utilizzatori.In genere, la regola per la progettazione della

rete prevede di col legare ogni nodo SEP adalmeno una coppia di nodi STP e di dimensionare ilink di segnalazione del collegamento a 0,3 Erlangin condizioni nominali; tale regola garantisce larobustezza della rete al guasto del singolo nodoSTP, nel qual caso il nodo STP ancora attivoavrebbe i l l ink di segnalazione a 0,6 Erlang.Questo limite di riempimento dei segnalatori èdovuto a modelli matematici, i quali garantisconoche fino al limite di 0,6 Erlang la rete non introduceritardi di accodamento tali da portare ad unasituazione di congestione.

I requisiti imposti sulla rete di segnalazionesono:• Affidabilità e disponibilità. La rete deve garantire

un trasferimento affidabile dei messaggi disegnalazione anche in condizioni critiche:

- Il livello di link (MTP2) [2] esegue funziona-lità volte a rilevare e correggere errori di tra-smissione e a garant i re la consegna insequenza;

- Il livello di rete (MTP3) [3] esegue funziona-lità di instradamento anche al fine di reagirea situazioni di guasto di link o di nodo.

• Ritardo. Per lo scambio di messaggi, è suffi-ciente che sia garantito un limite massimo dir i tardo, mentre non sono presenti v incol isulla variabilità del ritardo a differenza deiservizi voce. Tale requisito si rispecchia, alivello di link, in un ritardo massimo di attesadi un riscontro (ack) prima di considerare ilmessaggio non consegnato; a livello di retesi traduce in un ritardo massimo di attesaprima di eseguire le procedure di reinstrada-mento al fine di evitare duplicazioni o fuorisequenza.

• Sicurezza. La rete di segnalazione è una retededicata ai nodi di segnalazione e pertanto puòdefinirsi chiusa. Tuttavia, le reti di segnalazionetra Operatori possono essere interconnesse, in

SMSC SMSC

SMSC

SGw

SGw SGw

SGw

SCP HLR

TR/STP

TR/STP

IP Network

PdlOLO

MSC/VLR MSC/VLR

SCP SCPHLR

MSC/VLR MSC/VLR MSC/VLR MSC/VLR

TR/STP

TR/STP Regione

segnalazione≠1

Regionesegnalazione

≠5

TR/STP

TR/STP

PdlOLO

PdlOLO

HLRMSCOLOSCPSGw

=====

Home Location RegisterMobile Switching CentreOther Licensed OperatorService Control PointSignalling Gateway

Rete disegnalazione

tradizionale

SMSCSTPTR

VLR

====

Short Message Service CentreSignalling Transfer Pointnodo di TRansitoVisited Location Register

FIGURA 3› Evoluzione dell’architettura della rete di segnalazione TIM Italia.



questi casi la sicurezza viene garantita attra-verso funzionalità di screening/autorizzazionedella sorgente del traffico.La tabella 1 riporta i principali requisiti presta-

zionali della rete di segnalazione in termini di affi-dabilità, disponibilità e ritardo. Questi sono anche irequisiti imposti sulla soluzione per il trasportodella segnalazione su rete IP.

3.3 Architettura evoluta per trasporto SMS over IP

Negli ultimi anni, l’evoluzione dei servizi e delrelativo traffico si è rivolta sempre più verso ilmondo dati imponendo agli Operatori di realizzareun’infrastruttura adeguata per tal i servizi , ingenere di tipo IP. Contemporaneamente è matu-rata sul mercato la tecnologia per trasportareanche il traffico voce su rete IP (VoIP) e, infatti,alcuni Operatori hanno deciso di adottarla per rin-novare parti della loro rete telefonica e/o intro-durre nuovi servizi telefonici e multimediali suaccessi a larga banda come ha fatto TelecomItalia Wireline [4].

Con l’obiettivo di rendere i nodi di commuta-zione sempre più similari a dei nodi di tipo IP, allafine degli anni Novanta, l’industria e gli standard (inprimis IETF e poi 3GPP) si sono coordinati per defi-nire una soluzione tecnologica che permettesse ditrasportare anche il traffico di segnalazione attra-verso una rete IP.

Rispetto al trasporto della voce, la definizionedella soluzione per il trasporto della segnalazione èstato più rapido, prima di tutto per la caratteristicanativa del sistema SS7 di basarsi già su una tec-nica a commutazione di pacchetto simile a quellaIP, e inoltre, per l’esperienza già maturata sulla tec-nologia IP per gli aspetti di Qualità del Servizio.

All’inizio del 2001 sono emerse sul mercato leprime implementazioni commerciali della tecnolo-gia SIGTRAN. In quel periodo, come già scritto nelparagrafo 1, la rete di segnalazione era in fase diespansione per l’esplosione dei servizi basati suShort Message.

In questo contesto tecnologico e valutando gli

aspetti di mercato, è maturata in TIM Italia la deci-sione di realizzare una rete di segnalazione basatasu IP per trasportare il traffico SM. La scelta deltraffico da veicolare su rete IP si è orientata verso ilt raff ico Short Message per la sua naturaStore&Forward che non richiede stringenti garanziedi ritardo e di consegna. Tuttavia, il servizio SM si èimposto sul mercato come un mezzo di comunica-

zione rapido, infatti il cliente è abituato a perce-pire una buona qualità del servizio in termini dirapidità di consegna; pertanto, in fase di pro-gettazione della soluzione sono stati comunqueimposti requisiti di ritardo per garantire, nellapercezione da parte del cliente, la continuità delservizio.

L’architettura evoluta della rete per il tra-sporto della segnalazione SMS via IP si basasull ’ introduzione di nuovi nodi, dett i SGw(Signalling Gateway), che sono funzionalmentedegli STP (Signalling Transfer Point) in grado digestire, oltre ai link di segnalazione tradizionalisu portanti TDM, nuovi link (virtuali) di segnala-zione su IP.

L’architettura, illustrata in figura 3, prevedeche gli SMSC siano collegati esclusivamente ainuovi nodi SGw che smistano il traffico disegnalazione verso MSC/VLR e HLR attraversolink di segnalazione tradizionale e che scam-biano i l traffico tra SGw attraverso l ink di

segnalazione virtuali su IP.Tale archittettura garantisce che il traffico di

segnalazione relativo al servizio Short Message siainteramente gestito da una nuova rete dedicata,scaricando così la rete tradizionale di STP.

3.4 Tecnologia SIGTRAN e posizionamento nello standard

All’interno dell’ente IETF (Internet EngineeringTask Force), dove vengono definite le soluzioni e iprotocolli per l’evoluzione della tecnologia basatasu IP, è stato formato nel 1999 un nuovo Gruppo diLavoro (WG – Working Group), denominato SIG-TRAN (SIGnalling TRANsport), con l’obiettivo didefinire l’architettura e i protocolli per il trasportodella segnalazione di tipo SS7 attraverso una reteIP, nel rispetto dei requisiti tipici del sistema SS7.

I protocolli di trasporto (livello 4) tipici delmondo IP sono UDP (User Datagram Protocol) eTCP (Trasmission Control Protocol). Mentre UDPfornisce un servizio connection-less veloce senzameccanismi di affidabilità, TCP fornisce un servizioconnection-oriented affidabile ma con limitazioni intermini di disponibi l i tà e reazione ai guast i .Pertanto entrambi sono stati considerati non ade-guati allo scopo, sebbene sia stato riconosciutoche il TCP avesse la caratteristica fondamentale diessere connection-oriented.

Queste considerazioni hanno spinto il WG SIG-TRAN a definire un nuovo protocollo di trasportonel mondo IP: SCTP (Stream Control TransmissionProtocol ) [5] (s i veda l ’omonimo r iquadro diapprofondimento) al fine di sorpassare alcune limi-tazioni tipiche del TCP.

Livello SS7

MTP2(ITU-T Q.703)

MTP2

(ITU-T Q.704)

Ritardo(timer più stringente)

Affidabilità / Disponibilità

500 - 2000 msMax ritardo di riscontro (ack)

500 - 1200 ms

P errore non rilevato ≤ 10-10

I indisponibilità ≤ 10 minuti/anno

P perdita messaggio ≤ 10-7

P fuori sequenza messaggio ≤ 10-10

MTP2SS7

==

Message Transfer Part 2Signalling System n. 7

TABELLA 1› Requisiti prestazionali della rete di segnalazione del sistema SS7.



SCTP (Stream ControlTransmission Protocol)

SCTP [5], sviluppato in ambitoIETF dal Working Group SIG-TRAN, è un protocollo di tra-sporto connect ion or ientedche, a differenza dei protocollipreesistenti (TCP e UDP) pre-vede meccanismi atti a rispet-tare i requisit i del trasportodella segnalazione in rete IP.Un’associazione SCTP è unaconnessione virtuale tra dueent i tà, contenente diversistream che cost i tu iscono icanali logici unidirezionali tradue end point SCTP. SCTP èprogettato per trasportaremessaggi. Infatti, la strutturadel datagramma prevede unheader comune e un insieme diunità dati ognuna contenenteun messaggio del livello supe-riore. Ogni messaggio applica-tivo appartiene ad uno stream,all’interno del quale è garantitoun trasfer imento aff idabi lemediante riscontri selettivi eritrasmissioni (figura A).Tale struttura di SCTP con-sente:• di migliorare l’efficienza in

rete diminuendo l’overheadcomplessivo, trasportandonello stesso datagramma uninsieme di messaggi deilivelli superiori fino a rag-giungere la massima dimen-sione del datagramma(bundling);

• di ev i tare s i tuaz ion i d ihead-of-l ine-blocking e i lre lat ivo r i tardo (mul t i -plexing). Ciò avviene poichéle r i t rasmiss ion i sonogestite a livello di singoloflusso, pertanto la perditadi messaggi appartenentiad un cer to f lusso nonblocca la consegna de imessaggi d i a l t r i f luss i .Inoltre v iene eseguito unmeccanismo di r itrasmis-s ione se let t iva a l f ine d ir i trasmettere solo i mes-saggi effettivamente persi e

non tutt i quel l i trasmessisuccessivamente alla per-dita del primo messaggio.

Un’associazione, a differenza diuna connessione TCP, vieneaperta una sola volta per il tra-sferimento di molti flussi infor-mativi, effettuando così un’unicaprocedura di instaurazione. Inmaniera analoga al TCP, pre-vede meccanismi per il controllodi flusso e di congestione diret-tamente a l ivello di associa-zione.

A differenza di TCP, invece,questo protocollo risulta arric-chito di una funzionalità chiave,il multihoming, che consente di

assegnare ad un end pointSCTP “n” indirizzi IP così dapoter configurare all’interno diuna singola associazione “n”indirizzi di trasporto; il multiho-ming contribuisce al rispetto

dei requisiti di disponibilità eaffidabilità garantendo una tol-leranza ai guasti IP in rete opresso il nodo con reinstrada-mento del traffico su percorsialternativi, come illustrato in(figura B) con un percorso IPprimario ed uno secondario.Tale funzionalità garantisce lacapacità di reazione al fault IPsenza avvertire il livello supe-riore SS7.La raggiungibilità dell’end pointremoto e la disponibilità di tutti

i percorsi definiti viene testatamediante invio di messaggiperiodici, detti hearbeat.SCTP fornisce inoltre varie fun-

zional i tà per r ispondere alrequisito di sicurezza del tra-sporto del le informazioni disegnalazione in termini di con-fidenzialità, autenticazione eintegrità.

2 2 2

Associazione SCTP

1 1 HeaderSCTP

SCTPA

SCTPB

1

2

Appl A

Appl B

Appl C

1

2 1

2 1

2

Appl A

Appl B

Appl C

1

2 1

2 1

SCTP = Stream Control Transmission Protocol

FIGURA A› Architettura della rete intelligente (fisso e mobile).

IP Network

persorso primario

10.10.1.2 10.10.3.2

10.10.4.210.10.2.2

persorso secondario

FIGURA B› Funzionamento multihoming.



L’architettura definita in IETF dal WG SIGTRANè orientata a garantire che non ci siano impatti suiprotocolli SS7, e si basa su un’architettura proto-collare modulare (figura 4), formata da:• un protocollo di trasporto SCTP comune per

ogni livello di segnalazione SS7 in grado disuperare le limitazioni di TCP e UDP;

• un modulo di adattamento specifico per ogniprotocollo di segnalazione che si vuole tra-sportare su IP (x-UA, User Adaptation layer),al fine di poter riutilizzare i livelli applicatividella segnalazione SS7 e adattare i servizi for-niti da SCTP.

L’emergere di SCTP come protocollo di riferi-mento per il trasporto in rete IP di traffico segnala-zione ha fatto sì che fosse scelto, come alternativaai protocolli UDP e TCP, anche per il trasporto diprotocolli di segnalazione nativi del mondo IP, comead esempio SIP (Session Initiation Protocol)1e DIA-METER2. L’applicazione di SCTP rimane, ad oggi,confinata all’interno del segmento di core networkpoiché un dispiegamento sui numerosi terminalipresenti nella rete di accesso potrebbe esseretroppo oneroso in termini elaborativi.

Uno dei maggiori vantaggi della segnalazionesu IP è la possibilità di realizzare tra i nodi dei link

virtuali (connessioni virtuali end to end), che nonpresentano limitazioni di banda, in quanto realizzatisu una rete a pacchetto con interfacce ad altavelocità (ad esempio interfacce FE 10/100 Mbit/s).Come descritto nel paragrafo 3.2, i link tradizionaliSS7 sono link a 64 kbit/s in genere dimensionati a0,3 Erlang, pertanto ne servono molti per smaltireelevate quantità di traffico; inoltre esiste un limite alnumero di link tra due nodi SS7 (da standard 16,per una banda massima di circa 300 kbit/s, seb-bene alcuni costruttori permettano di arrivareanche a 32). Tali limitazioni pongono vincoli sull’e-spansione della rete SS7 tradizionale, già raggiunti

nella rete mobile di TIM Italia.Con i link virtuali di segnala-

zione su IP, la scalabilità di questiè limitata solo dalla banda disponi-bile sulla rete a pacchetto ad altavelocità, pertanto ciò garantisce disorpassare i limiti e i vincoli dellatecnica SS7 tradizionale.

All’interno del percorso evolu-tivo delle architetture delle reti edei servizi mobili, il 3GPP ha previ-sto, come opzioni, l’utilizzo dellatecnologia IETF SIGTRAN per iltrasporto della segnalazione su IPin Core Network dalla Release 4 ein RAN (Radio Access Network)dalla Release 5 (interfaccia Iu CS).

Il 3GPP [6] ha definito comeopzione la possibilità di trasportareattraverso reti a pacchetto (ATM oIP) la segnalazione tradizionaleSS7 (SCCP, ISUP, MAP, CAP) e lenuove componenti di segnalazione(H.248 [7], BICC [8]) in CN (CoreNetwork). Nel caso di utilizzo diuna rete in tecnologia IP in CN, iltrasporto della segnalazione deveavvenire in accordo con l’architet-tura e i protocolli SIGTRAN. In par-

ticolare la specifica 3GPP chiarisce che è necessa-rio l’utilizzo della pila composta da M3UA [10] eSCTP. La selezione di una sola opzione è stataeseguita nell’ottica di semplificazione, infatti èstato selezionato M3UA poiché risulta l’unicolivello di adattamento che garantisce il trasportodella segnalazione sia ISUP che SCCP, ovverorispettivamente call related e non call related.

Tuttavia, per lo scenario di off load del trafficoSMS su una rete IP, TIM Italia ha selezionato la pilaprotocollare M2PA [11] / SCTP poiché si presen-tava, al momento, come la soluzione più matura sulmercato dato che prevede il riutilizzo del livelloMTP3 per le funzionalità base di instradamentodella rete di segnalazione.

4. Realizzazione della rete SMS over IP

Come già anticipato, l’architettura della rete disegnalazione MAP di TIM Italia prevede una suddi-visione geografica in cinque aree di segnalazione.

Segnalazione nativa IP

Segnalazione SS7 tradizionale

ISUP

MAP/CAP

TCAP

SCCP

RANAP/BSSAP

SUAMTP3

M2PA M2UA

SCTP

IPv4 / IPv6

M3UA

User Partsegnalazione

Moduli specifici

di adattamento

Livello comune di trasporto

DIAMETER SIP

CAPIPvx

ISUPM2PAM2UAM3UA

MAP

=======

Camel Application PartIP vers xISDN User PartMTP2 Peer to peer Application layerMTP2 User Adaptation layer MTP3 User Adaptation layerMobile Application Part

MTP3SCTPSCCP

SIPSUA

TCAP

======

Message Transfer Part 3Stream Control Transmission ProtocolSignalling Connection Control PartSession Initiation ProtocolSCCP User Adaptation layerTransaction Capability Application Part

FIGURA 4› Architettura protocollare SIGTRAN.

(1)SIP è un protocollo per il setup di sessioni nativo IP, scelto come riferimen-to per i servizi del dominio IMS in 3GPP e considerato il protocollo che siimporrà per i servizi (dati, voce, video) nell’evoluzione di Internet.

(2)DIAMETER è un protocollo, evoluto rispetto al RADIUS, per eseguire funzio-nalità e procedure di AAA (Authentication, Authorization, Accounting). È statoselezionato nello standard 3GPP per tali funzionalità nel dominio IMS.



Gli MSC/VLR vengono assegnati alle diverse areecercando, compatibilmente con vincoli di caratteregeografico/organizzativo, di garantire l’equidistri-buzione del traffico di segnalazione MAP tra leregioni.

In ciascuna area di segnalazione sono presentidue nodi di transito TR/STP.

L’architettura prevede che:• i nodi di transito siano connessi tra di loro a

maglia completa;• i nodi HLR siano connessi, direttamente o tra-

mite connessioni semipermanenti, con tutti inodi di transito;

• i nodi MSC/VLR siano connessi ai due nodi ditransito della regione di appartenenza.I nodi di transito gestiscono:

• la segnalazione ISUP e i canali fonici relativi altraffico voce fra differenti regioni di segnala-zione;

• le procedure MAP, che coinvolgono HLR,SMSC, MSC/VLR ed altri apparati di servizio;

• la funzionalità di Number Portability in manieracongiunta ai nodi HLR.La rete SMS over IP è costituita da sei nodi

Signaling Gateway che realizzano una rete disegnalazione su IP (mediante connessioni di tipoSS7 con i nodi GSM e di tipo IP con il backboneIP), parallela a quella costituita dai nodi di transito.Questa rete è in grado di gestire tutte le procedureMAP relative al servizio di Short Message.

L’architettura della rete di segnalazione viene adessere ridisegnata con l’introdu-zione della segnalazione su IP,infatti i sei SGw sono organizzati incoppie che costituiscono tre bacinidi raccolta del traffico SM. In talmodo, per la rete IP le aree disegnalazione sono state ridotte dacinque a tre.

La definizione delle tre aree disegnalazione è stata effettuataconsiderando:• l’inserimento dei nodi SGw in

siti in cui è presente un nodoSMSC, al fine di risparmiareconnessioni geografiche;

• la doppia attestazione geogra-f ica dei nodi SMSC, HLR eMSC/VLR ai nodi SGw.Pertanto, come i l lustrato in

figura 5, su una coppia di nodiSGw insistono:• due centri servizi (SMSC) con

link SS7;• MSC/VLR, HLR con link SS7

dedicati al traffico SMS;• TR/STP con link SS7 per veico-

lare i l traff ico da/verso altr iOperatori OLO (Other LicensedOperators);

• una rete magl iata di l inksetlogici IP (M2PA) verso gli altriSGw, real izzata mediante i lbackbone IP.

La struttura di rete realizzata prevede di garan-tire l’affidabilità mediante la ridondanza:• geografica, in quanto ogni nodo di rete è con-

nesso, via TDM, a due SGw di zone geografichedistinte;

• di apparato, in modo da gestire temporaneifault di nodo, per cui ogni SGw è in grado digestire il traffico dell’altro SGw della coppia incondizioni normali di traffico;

• interna al SGw, realizzata attraverso un’architet-tura del nodo completamente ridondata.

4.1 Funzionalità della piattaforma

Durante l’analisi dei requisiti della piattaformaSS7 over IP si sono tenute in considerazione lefunzionalità implementate sulla piattaforma SS7tradizionale in tecnica TDM, che necessaria-mente erano richieste anche sulla nuova piat-taforma.

Nel seguito si è focalizzata l’attenzione agliaspetti relativi ai seguenti requisiti/funzionalitàdella piattaforma SMS over IP:• routing a livello MTP3 ed SCCP (Global Title

Translation);• screening su utenza originante/terminante gli

SMS per interazioni con la MNP (Mobi leNumber Portability);

• interlavoro tra SS7 ed IP per l’Interconnessioneverso elementi di rete SS7 (MSC, HLR, TR) e viaIP con SMSC (Protocol adaptation).

SMSCPI

SMSCRM

SMSCCT

SMSCNA

SMSCMI

SMSCBO

SGw PI

SGw RM

SGw NA

SGw CT

SGw BOSGw MI

HLR

HLR

MSC/VLR

MSC/VLR

HLR

HLR

MSC/VLR

MSC/VLR

HLR

HLR

MSC/VLR

MSC/VLR

Rete IPUNIGATE

Regione NORD

LinksetSS7

Linkset M2PA

Regione CENTRORegione SUD

HLRMSCSGw

SMSCVLR

=====

Home Location RegisterMobile Switching CentreSignalling GatewayShort Message Service CentreVisited Location Register

FIGURA 5› Struttura della rete SMS over IP in tre regioni di segnalazione.



4.1.1 Funzionalità di routing

Il routing nel sistema SS7 è basato su duelivelli: livello di rete MTP3 e livello SCCP [9] (GTT).

Lo spazio di indirizzamento di MTP3 è basatosulla individuazione degli elementi di rete SS7mediante Signaling Point Code, pertanto la gene-rica MSU presenta OPC (Originating Point Code) eDPC (Destination Point Code), che individuanorispettivamente l’origine e la destinazione del mes-saggio.

Il livello SCCP estende e completa la capacitàd’indirizzamento, infatti lo spazio di indirizzamentosi basa sull’individuazione dei nodi di rete medianteun numero telefonico, tipo E.164 (Global Title), peridentificare origine (Calling Party Address) e desti-nazione (Called Party Address). Inoltre, il livelloSCCP fornisce il servizio di GTT (Global TitleTranslation) che permette di tradurre un indirizzonumerico, in genere il Called Party Address SCCP,con l’indirizzo fisico di livello MTP3.

Grazie al doppio livello di indirizzamento MTP3e SCCP si rende l’instradamento molto flessibile,poiché una destinazione è identif icata da unnumero, pertanto qualsiasi cambiamento di indi-rizzi PC (Point Code) di rete si riflette in un aggior-namento solo nei nodi che eseguono GTT.

Nella rete di TIM Italia, un caso in cui si ricorrealla funzione di GTT è l’invio di un SMS (proceduraSM-MO) da parte di un cliente verso il CentroServizi (SMSC). Il terminale possiede, preimpostato,il numero virtuale (E.164) del SMSC TIM (+393359609600); quando il cliente invia uno SM, ilMSC/VLR lo instrada verso un nodo intermedio (orai SGw, precedentemente le TR/STP) che esegueGTT ed individua il PC del SMSC. In questo modo,l’introduzione di un nuovo SMSC in rete, comportaimpatti solo sui nodi intermedi e non su tutti irestanti nodi MSC/VLR ed HLR della rete TIM Italia.

Tuttavia, la maggiore flessibilità fornita dallafunzionalità di GTT implementata in un nodo SS7va a gravare sul carico elaborativo del nodo. Èquindi necessario valutare con attenzione il suoeventuale utilizzo soprattutto nei nodi intermediche, per il loro numero ridotto, si prestano mag-giormente ad implementare la “decisione” del rou-ting. L’operazione di GTT incide sulle capacità delnodo, per cui il numero di GTT/sec eseguibili rap-presenta uno dei dati più significativi per le presta-zioni di un nodo di segnalazione.

L’introduzione della piattaforma SMS over IP,con il relativo off load del carico di SMS dalle cen-trali di transito ha portato a spostare la funzionalitàdi GTT dai nodi di Transito (TR/STP) verso i SGw,con conseguente alleggerimento del carico di ela-borazione sui nodi tradizionali. La figura A nelriquadro “Il servizio Short Message” mostra, perogni procedura MAP componente il servizio SM, lafunzionalità di GTT eseguita dal SGw.

L’architettura della rete SMS over IP garantiscepertanto le seguenti funzionalità per il servizioShort Message:• Traduzione delle GT relative ai vari elementi di

rete: MSC, SMSC, HLR e TR;

• Traduzione della GT virtuale del servizio;• Esecuzione del routing.

4.1.2 Funzionalità di Mobile Number Portability (MNP)

La migrazione del servizio Short Message sullapiattaforma SMS over IP, ha dovuto tener conto deivincoli imposti dalla regolamentazione relativa allaportabilità della numerazione del cliente.

Come descritto nel riquadro “Il servizio ShortMessage”, è necessario eseguire in rete le verifichesulla tipologia del cliente per comprenderne l’ope-ratore di appartenenza ed eseguire le opportuneazioni. In particolare, in rete TIM Italia è eseguito:• Screening sull’originante lo Short Message, per

abilitarne o meno l’accesso al SMSC TIM, inottica antifrode. In regime di Number Portabilityè infatti necessario verificare che alla numera-zione MSISDN originante corrisponda effettiva-mente un cliente TIM Italia.

• Verifica dello stato di portabilità del destinatariodello Short Message, mediante accesso aidatabase di portabilità presenti su HLR e tran-sito TIM, per inviare lo SM all’Operatore pressoil quale “risiede” il cliente.Prima del la migrazione del serviz io Short

Message sulla piattaforma SMS over IP, lo scree-ning sull’originante (SMS-MO) veniva effettuatointerrogando i database FNR (Flexible NumberRouting) presenti sui nodi TR/STP. L’introduzionedella piattaforma SMS over IP, con il relativo offload del carico di SMS dai nodi di transito, ha por-tato a spostare nel SMSC tale controllo mediantela verifica dell’IMSI dell’utente “mittente”, veicolatonel messaggio SM-MO.

Per quanto riguarda la verifica dello stato diportabilità del destinatario dello Short Message, leverifiche sulle numerazioni “nominalmente” TIM(numerazione 33X) o OLO (numerazione 3YZ) sonoimplementate, rispettivamente negli HLR e nei nodidi transito, mediante i database FNR.

4.1.3 Interlavoro SS7 - IP

Per trasportare la segnalazione su IP tra SGwdiversi, la piattaforma esegue funzionalità di inter-lavoro tra SS7 ed IP. Per lo scenario SMS over IP,TIM Italia ha scelto di utilizzare il protocollo diadattamento M2PA su SCTP che struttura il SGwcome illustrato nella figura 6. M2PA [12] è un pro-tocollo peer to peer che adatta il trasporto deimessaggi di segnalazione MTP3 realizzando un linkdi segnalazione su rete IP in maniera del tutto tra-sparente al livello MTP3. Infatti, M2PA fornisceverso MTP3 le stesse primitive di MTP2 e utilizzal’associazione SCTP come se fosse un link virtualedi trasporto. I servizi offerti da M2PA e le relativefunzionalità previste per il supporto delle funziona-lità di MTP2 sono:• supporto delle primitive di interfaccia tra MTP2

e MTP3;• Mapping dei link SS7 in associazioni SCTP;• Gestione delle associazioni SCTP;• Fornitura dei servizi richiesti da MTP3 in rete IP.



Questa scelta è stata dettatadalla volontà di riutilizzare il piùpossibile le logiche consolidate diMTP3, ovvero le procedure bennote per la pianificazione e l’eser-ciz io del la rete, e dal la rapidamaturità raggiunta dal protocolloM2PA, grazie alla sua semplicità.

4.2 Il nodo Signalling Gateway

Le funzional i tà precedente-mente esposte si concretizzano inuna architettura di nodo basata supiattaforma Cisco 7513 su cuiviene inserita una versione dedi-cata del sistema operativo IOS.L’architettura interna del nodo inrete TIM Italia è composta da:• processore centrale (RSP16)

che realizza tutte le funzioni digestione, supervisione e sincro-nizzazione delle schede perife-riche;

• schede periferiche (VIP6-80),che una volta special izzatemediante hardware dedicatoper la gestione dell’interfacciaIP o TDM (Port Adapter IP oSS7), eseguono le funzioni diinterconnessione verso ret iesterne e, oppotunamente con-figurate, possono eseguire fun-zionalità di instradamento eswitching al fine di alleggerire ilcarico sul processore centrale.I SGw sono configurati impo-

stando la ridondanza hardwareinterna: ogni nodo è infatti così configurato:• doppia alimentazione in corrente continua assi-

curando la disponibilità energetica all’apparato;• due processori centrali con una ridondanza

impostata di tipo caldo (Hot Standby);• schede periferiche con doppia interfaccia IP;• schede periferiche con doppia interfaccia SS7

in modo da avere la completa ridondanza disegnalatori.Nella prima fase di introduzione in rete, la piat-

taforma ITP era dotata di una architettura centraliz-zata in cui tutte le funzioni venivano svolte dall’u-nità centrale, limitando così le capacità dell’interosistema. L’evoluzione tecnologica del nodo ha por-tato ad una architettura interna distribuita, spo-stando le funzionalità di routing presso le schedeperiferiche dotate di capacità di switching. Ciò hapermesso di rendere modulabile la capacità delnodo dotandolo di maggiore flessibilità per ulterioriampliamenti.

Per implementare tale architettura è stata atti-vata la funzionalità (off load) che permette di abili-tare il routing SCCP/MTP3 e M2PA/SCTP nelleschede periferiche. Come illustrato in figura 6, leschede VIP vengono specializzate per l’interfaccia-mento con la rete SS7 e con la rete IP ed ese-

guono i processi fino a livello SCCP (incluse anchele operazioni di Global Title Traslation) scaricando ilcarico elaborativo del processore centrale, cheeseguirà il calcolo e la distribuzione delle tabelle dirouting solo in caso di cambiamenti di stato delnodo; infine, vengono dedicate anche delle schedeper l’interfacciamento a livello IP con i sistemi OSSdi gestione (per esempio l’invio dei dati statistici ola ricezione dei comandi di configurazione daremoto).

Con tale architettura il nodo avrà una maggiorecapacità che potrà essere incrementata aggiun-gendo ulteriori schede periferiche. Inoltre, sebbenenon illustrati in figura 6 per semplicità, tale architet-tura risulta flessibile per l’implementazione di altriprotocolli SIGTRAN in ottica evolutiva.

4.3 Il trasporto IP mediante UNIGATE

Il backbone IP di TIM (UNIGATE) fornisce il ser-vizio di trasporto geografico tra le piattaforme SGwcon garanzie di protezione rispetto al guasto dicollegamento o di nodo e di priorità nel tratta-mento dei messaggi di segnalazione al fine di assi-curare un ritardo end to end contenuto ed adatto aimessaggi di segnalazione.

SCCP MTP3 / MTP3b Mgmt

Shared High Speed DMA Memory

MTP3 / MTP3b Routing

GTT

VIP VIP VIP

GTT

M2PA

SS7 Data Flow Sigtran Data Flow OSS Data Flow

Backup RSP

Primary RSP

SCTP

Ethernet PA

Ethernet PA

IP

MTP3/SCCP Forwarding

MTP3/SCCP FilteringMTP3/SCCP

Filtering

MTP2

SS7 P.A.

MTP3/SCCP Forwarding

IP

Ethernet PA

Ethernet PA

DMAGTT

IPRSP

M2PAMTP3

======

Direct Memory AccessGlobal Title TranslationInternet ProtocolRoute Switch ProcessorMTP2 Per to peer Adaptation layerMessage Transfer Part

GTT

Struttura logicaSGw

SCCP

M2PA

SCTP

IP

MTP3/MTP3b

Struttura fisica SGw

GTT

MTP2

MTP1 Ethernet

OSSSCCPSCTPSS7VIP

=====

Operations Support SystemSignalling Connection Control PartStream Control Transmission ProtocolSignalling System 7Versatile Interface Processor

FIGURA 6› Architettura distribuita del SGw.



Tali prestazioni sono ottenute mediante la rea-lizzazione di un backbone secondo l’architetturaDifferentiated Services, che permette di fornireclassi di servizio diverse nelle prestazioni. In UNI-GATE sono fornite quattro classi di servizio:• Real Time per i servizi voce che garantisce

priorità di trattamento assoluta al fine di ridurreil jitter;

• Dati Plus per i servizi dati con qualità;• Controllo per la segnalazione (ad esempio

OSPF) tra i nodi IP;• Best Effort per i restanti servizi.

Per il trasporto del traffico di segnalazione vieneutilizzata la classe Dati Plus che garantisce perdite

contenute e un ritardo limitato ma senza garanziesulla variabilità dello stesso.

La robustezza ai guasti è garantita dal back-bone IP attraverso un’architettura (figura 7) condue piani di rete paralleli che utilizzano collega-menti geografici diversi e con una struttura di sitoridondata con due nodi, ognuno su un pianodiverso della rete. Inoltre la piattaforma SGw usu-fruisce del servizio di accesso ridondato al back-bone IP mediante la funzionalità Cisco HSRP (HotStandby Routing Protocol). Infatti, ogni SGw è col-legato attraverso l’infrastruttura LAN del sito diUNIGATE a due router. Ogni router esegue funzionidi default gateway, ovvero esegue il routing IP, per

Il servizioSHORT MESSAGE

Il servizio Short Message sicompone delle seguenti pro-cedure (figura A):• SM Mobile Originated (SM-

MO): procedura di invio daparte del terminale di unoSM verso il Service Centre(SMSC). Nel terminale èimpostato un numero vir-tuale di riferimento utiliz-zato dalla rete per instra-dare lo SM verso il SMSC;

• Send Routing Information(SRI): procedura di richiestada parte del SMSC all’HLRdelle informazioni necessa-rie ad individuare il MSCVisited presso i l quale èregistrato i l destinatariodello SM;

• SM Mobile Terminated (SM-MT) : procedura di inviodello SM al MSC visitedpresso il quale è registratoil destinatario dello SM;

• SM waiting Data Set proce-dure (SM-DS): procedurainiziata dal SMSC per regi-strare il proprio indirizzonella waiting list quando laprocedura SM-MT non siaandata a buon f ine (peresempio, utente non rag-giungibile);

• Alert: procedure iniziata dalHLR per avvertire il SMSCnel caso in cui il destinata-rio sia tornato raggiungibile.

L’introduzione in rete dellaMNP (Mobile NumberPortability) permette ad uncliente di cambiare Operatoremobile senza modificare il pro-prio numero MSISDN (MobileStation International ISDNNumber). Tale funzionalità èsupportata dalla rete TIM Italiamediante la funzionalità FNR(Flexible Number Routing)consistente in un databaseche mantiene lo stato di MNPdell’utente.Nella figura A sono illustrate

le procedure SM tra i nodiinteressati e sono messe inevidenza (bullet rossi) le fun-zioni di instradamento GTT(Global Title Translation) ese-guite dal SGw al fine di tra-durre l ’ indirizzo in formatonumero MSISDN, associato alnodo di rete destinatario dellaprocedura, in un indirizzo direte (Point Code). Inoltre,sono evidenziate anche leoperazioni (bul let verdi egialli) dovute alla MNP.

SGw SGwSMSC

SM-MO

SM-MT

SMDS

IP Network

ALERT

Global Title Translation

Reinstradamento versoHLR destinanatario

IMSI screening

SRI (MSISDN TIM)

SRI (MSISDN non TIM)

HLRMSC TR/STP/GW OLO

GWHLRMSC

MSISDN

MTOLOSGw

====

===

GateWayHome Location RegisterMobile Switching Centre Mobile Station International ISDN NumberMobile TerminatedOther Licensed OperatorSignalling Gateway

SMDS

SMMOSMSC

SRISTPTR

=

=====

Short Message waiting Data SetprocedureShort Message Mobile OriginatedShort Message Service CentreSend Routing InformationSignalling Transfer Pointnodo di TRansito

FIGURA A› Procedure MAP per lo SM.



parte delle interfacce del SGw come pri-mario e per la restante parte comesecondario. In tale modo è garantita larobustezza al fault di nodo di accesso diUNIGATE.

Inoltre, mediante il processo OSPF ela architettura a due piani, UNIGATEgarantisce la ridondanza del percorso trai siti, necessaria per sfruttare a pieno lafunzionalità di multihoming sul nodoSGw, fornendo così un meccanismo direazione a guasti della componente IP ditrasporto.

5. Evoluzione architettura rete SMSover IP

L’evoluzione degli SMSC verso il tra-sporto della segnalazione su IP mediantel’adozione dei protocolli SIGTRAN (inparticolare nella piattaforma TIM, il proto-collo SUA [12], che trasporta i messaggiTCAP su IP) ha portato ad integrare nellanuova generazione di tali apparati, nodi SGw dellastessa tipologia e taglia di quelli ad oggi presenti incampo. La contemporanea introduzione di inter-facce SIGTRAN (in particolare con protocolloM3UA che trasporta messaggi SCCP su IP) su altrepiattaforme di servizio ha determinato la scelta disviluppare un’architettura (figura 8), composta dadue livelli di SGw:• un primo livello realizzato dai sei SGw

già present i , che cost i tuiscono i lnucleo della rete per l’interconnes-sione verso le piattaforme SS7;

• un secondo livello di SGw condivisitra le diverse piattaforme di servizioevolute, che esegue funzionalità diadattamento ed interlavoro dei proto-colli SUA/M3UA, supportati dalle piat-taforme di servizio, con il protocolloM2PA per la comunicazione peer topeer con i SGw del primo livello.Dato che la funzionalità di GTT (Global

Title Traslation) contribuisce in manierasostanziale al carico dei SGw, la soluzioneproposta permette di diversificare la confi-gurazione di tale funzionalità ripartendolasui due livelli in modo da garantire un uti-lizzo efficiente in base alle risorse disponi-bili nei SGw.

Alcuni dei principali benefici introdottisono:• facilità di introduzione delle piattaforme

di servizio su IP poiché gli impatti diconfigurazione sono concentrati solo suSGw del secondo livello;

• introduzione di licenze SUA/M3UA pereseguire la protocol adaptation solosu SGw di secondo livello, limitandocosì gli investimenti.Oggi questa architettura si è concre-

tizzata in rete TIM con l’introduzione di

due nuovi SMSC IP in sostituzione delle piat-taforme esistenti di tipo SS7.

6. Soluzione a livello internazionale

Un ulteriore esempio significativo di utilizzodelle tecniche di trasporto della segnalazione SS7

SMSC

SGw SGw

6509 75xx GSR

Gruppi HSRP

HLR

MSC/VLR

Regionesegnalazione

PoP SMSoIP

PoP UNIGATE

PoP SMSoIP

GE

FESTM-1

UNIGATE

GSRHLR

HSRPMSCPoPSGw

SMSoIPVLR

========

Gigabit Switch RouterHome Location RegisterHot Standby Routing ProtocolMobile Switching CentrePoint of PresenceSignalling GatewayShort Message Service over IPVisited Location Register

FIGURA 7› Architettura interconnessione con backbone IP.

M3UA SUA

Linkset M2PA

MSC/VLRHLR TR

ServicePlatform

Piattaforme SS7 (HLR, MSC, SMSC, TR)

SS7 SS7 SS7

Livello 2:- Sigtran protocol interworking- Routing- GTT

Livello 1:- SS7 interconnection- Routing- GTT

UNIGATE

SMSC

GTTHLR

M3UAMSC

SMSCSS7SUA

TRVLR

=========

Global Title TranslationHome Location RegisterMTP3 User Adaptation layerMobile Switching CentreShort Message Service CentreSignalling System 7SCCP User Adaptation layernodo di TRansitoVisited Location Register

FIGURA 8› Architettura evoluta a due livelli.



su backbone IP, è tuttora in fase di realizzazionenell’ambito dei progetti per la fornitura di serviziVAS TIM alle consociate estere.

Il progetto generale ha avuto come obiettivoprincipale “esportare” in modo rapido, affidabile,ed a basso impatto economico (modal i tà“Plug&Play”), taluni servizi VAS, come “LoSai diTIM”, “Chiama ora” (si veda il riquadro di approfon-dimento omonimo), servizi MMS/WAP, Voice Mail,Unified Messaging.

A tale scopo il progetto prevede di condividerele piattaforme di servizio (TGDS, SMSC, IVR,MMSC, …) già esistenti in rete TIM Italia, così daridurre gli investimenti e i tempi dovuti ad un’imple-mentazione dei servizi nelle reti delle consociate.L’accesso alle piattaforme di servizio TIM da partedei clienti delle consociate è realizzato medianteuna rete internazionale trasportando il contenutoinformativo e di segnalazione previsto da ciascunservizio.

Di seguito la descrizione è focalizzata ai servizi:LoSai di TIM e Chiama Ora. Tali servizi sono realiz-zati con logiche basate su SMS ed interazione conservizi supplementari SS7 (ovvero ISUP/MAP), per-tanto si prestano bene ad essere implementati contecniche di trasporto IP-based in ambito “coreinternazionale”, riutilizzando l’esperienza positivadell’implementazione SMS over IP in ambito nazio-nale TIM Italia.

Nella scelta del trasporto IP rispetto al TDMclassico, sono risultati determinanti i vantaggi deri-vanti da una maggiore flessibilità di trasporto per ivolumi di traffico in gioco e dalla realizzazione diuna architettura internazionale formata da:• una rete di SGw in grado di garantire l’interla-

voro tra livelli SS7 ed IP ed una comunicazionetrasparente per i livelli applicativi SS7 coinvolti(ISUP, MAP);

• un’infrastruttura IP-based (basata su BackboneIP internazionale) condivisa da vari servizi (ser-vizi dati GPRS/UMTS in roaming) tra diversioperatori esteri.Come nel caso della rete SMS over IP nazio-

nale, l’interlavoro è ottenuto con l’adattamento tragli stack protocollari SS7 e IP sulle interfacce deiSGw di TIM Italia e della Consociata, mediante lostack SIGTRAN:• MAP/TCAP sui livelli SCCP / MTP3 / M2PA /

SCTP/IP;• ISUP sui livelli MTP3/M2PA/SCTP/IP.

L’architettura prevede (figura 9) l’installazione inogni rete delle consociate di almeno un SGw ingrado, in fase di invio, di “imbustare” i messaggi disegnalazione ed inviarli alla destinazione correttaattraverso la rete IP e, in fase di ricezione, di“aprire” i pacchetti IP per ottenere i messaggi disegnalazione, eseguendo l’instradamento verso ladestinazione.

L’interconnessione via IP tra sistemi SS7 remotiappartenenti ai diversi operatori esteri, ha richiestodi affrontare e risolvere alcune criticità:• rispetto dei vincoli (ritardo, perdita di pacchetti

e disponibilità di servizio) stringenti del trafficodi segnalazione SS7 (paragrafo 3.2);

• coerenza e divisione degli spazi di indirizza-mento SS7 (MTP3), in particolare con tradu-zione nazionale-internazionale degli indirizzi;

• ridondanze nell’instradamento dei messaggi pergarantire un’opportuna robustezza.Il progetto è attualmente in fase di realizza-

I servizi:

Losai di TIM,Chiama Ora

Questi servizi consentonoall’Operatore mobile di notifi-care ai propri clienti (SMS “LoSai di TIM”) le chiamate rice-vute in stato di non raggiungi-bilità (terminale spento o fuoricopertura), e al cliente chia-mante (SMS “Chiama Ora”) lostato di raggiungibilità dell’u-tenza chiamata.I servizi si compongono di duefasi:• Fase ISUP: durante l’instau-

razione del la chiamata

verso un cliente con termi-nale spento o fuori coper-tura, la chiamata viene re-diretta, solo in segnala-zione (ISUP) e pertantosenza impegno di circuitifonici , verso una piat-taforma (TGDS) che imple-menta la logica del serviziodi notifica. Inoltre, la chia-mata viene deviata in foniaverso una macchina ingrado di r iprodurre unannuncio che avverte i lcl iente chiamante del lapossibilità, tramite oppor-tuna selezione di toniDTMF, di essere notificato(SMS “Chiama Ora”) sullostato di raggiungibilità delchiamato. Tale opzioneviene raccolta dalla piat-taforma TGDS che prov-vede poi a rilasciare oppor-tunamente la chiamata.

• Fase MAP (SMS): la piat-taforma TGDS prepara edinvia al cliente chiamatonon raggiungibile lo ShortMessage “Lo Sai …” conte-nente i dati relativi ai chia-manti. Non appena il chia-mato si ripresenterà allarete, gli verrà consegnatolo Short Message conte-nente la lista dei tentativi dichiamata durante la suaassenza dal la rete.Dopodiché il TGDS, rice-vuto un riscontro positivocirca la consegna del loShort Message “Lo Sai …”al chiamato, può inviare loShort Message “ChiamaOra …” ai chiamanti che neabbiano fatto r ichiesta,indicando così nel corpodel messaggio la raggiungi-bilità del cliente cercato.



zione, e pertanto resta aperto apossibili evoluzioni legate sia allatecnologia offerta dai maggioricostruttori sia all’integrazione diulteriori nuovi servizi/piattaforme,in l inea con l’approccio di t ipo“Plug&Play”.

7. Scenari evolutivi

Come già citato nel paragrafo3.3, i costruttori stanno perse-guendo la via di rendere i nodi dicommutazione delle Core Networkdegli Operatori mobili sempre piùdi tipo IP, secondo gli standard diriferimento definiti nell’ente 3GPP.Infatti, nelle roadmap dei costrut-tori è previsto il supporto di inter-facce IP per i l t rasporto del lasegnalazione di apparat i GSM(MSC, HLR, TR) e UMTS (MSCServer, MGw per un’architetturasplit). Sebbene esuli dal focus delpresente articolo, ovviamente èprevisto anche il trasporto dellavoce su rete IP in Core Network.

Nel contempo, il successo del progetto dellarete SMS over IP e la conseguente esperienzamaturata in TIM Italia, fanno sì che ci siano le con-dizioni per riapplicare in scenari di rete evolutivi lasoluzione di trasporto della segnalazione su IP,dove ciò risulti conveniente e opportuno.

In particolare, dalle analisi di evoluzione delsegmento di Core Network, sono emersi due pos-sibili scenari evoluti di rete nel medio termine:• il completamento, in ambito GSM, del processo

di migrazione della segnala-zione su IP, realizzando il tra-sporto anche del la parte dimobilità del protocollo MAP;

• la disponibilità di MSC in archi-tettura split, composta da MSCServer e MGw, con la globalitàdella segnalazione gestita daMSC Server trasportata via IP. Nella rete GSM è possibile preve-

dere uno scenario in cui gli MSC egli HLR siano dotati di schede IPatte a trasportare la segnalazione.Nel medio termine, al fine di distri-buire gli investimenti nel tempo e permotivi di migrazione della rete, è pre-vedibile uno scenario in cui tutti gliHLR e alcuni nodi di rete siano fornitidi interfacce IP. In questo scenarioalcuni nodi (MSC o TR) potrebberoessere selezionati per eseguire fun-zionalità di SGw per aggregare iltraffico dei segnalatori tradizionaliSS7 provenienti dai nodi non fornitidi interfacce IP e trasportare il traf-fico verso i nodi HLR via IP.

Nel lungo termine, è altresì prevedibile la realizza-zione di una struttura di rete non gerarchica in cui tuttii nodi (MSC e HLR) siano interconnessi tra di loroattraverso una rete IP, al fine di ridurre la necessità dinodi aggregatori di tipo TR/STP/SGw. I vari passaggidell’evoluzione sono riportati nella figura 10.

In questi scenari di rete, si prevede di utilizzare l’ar-chitettura protocollare M3UA/SCTP, per il trasporto delprotocollo SCCP, in alternativa alla pila protocollaretradizionale MTP, come definito nello standard 3GPP.

Rete SS7oIPInternazionaleService

Platform

Backbone IPInternazionale

UNIGATE

Consociata B

HLR

MSC/VLR

Consociata A

TIM Italia

HLRMSC/VLR

SMSC

SGwITZ

SGwITZ

SGwITZ

HLRMSCSGw

===

Home Location RegisterMobile Switching CentreSignalling Gateway

SMSCSS7VLR

===

Short Message Service CentreSignalling System 7Visited Location Register

FIGURA 9› Architettura rete di segnalazione su IP internazionale.

IPNetwork IP

Network

MSC/VLR

MSC/VLR MSC/VLR

SGw

SCP HLR

SS7/TDMNetwork

SS7/TDMNetwork

SCP HLR SCP HLR

TR TR

TR TR

MSC/VLR

MAP/TCAP/SCCP/M3UA/SCTPCAP o INAP/TCAP/SCCP/M3UA/SCTP

MSC/VLR MSC/VLR

TR TR

TR TR

CAPINAP

M3UAMAP

SCCPSCTPTCAP

=======

Camel Application PartInteligent Network Application PartMTP3 User Adaptation layerMobile Application PartSignalling Connection Control PartStream Control Transmission ProtocolTransaction Capability Application layer

FIGURA 10› Scenari evolutivi della rete GSM.



Nell’evoluzione della Core NetworkUMTS, l’introduzione dell’architetturasplit o layered nel dominio CS (CircuitSwitched) permette la separazione tranodi appartenenti al piano di controllo(MSC Server) e nodi appartenenti alpiano di utente (MGw) e la realizzazionedi una struttura di rete in cui l ’MSCServer diviene un nodo IP (figura 11),mentre la rete di accesso radio (RAN)continua a basarsi su un trasporto di tipoATM. In questo contesto, il MGw, oltre adeseguire le funzionalità legate al tratta-mento dei flussi nel piano di utente, ter-mina lato accesso il trasporto ATM e latoCN utilizza il trasporto IP.

In questa scenario è previsto l’utilizzodi interfacce IP presso:• MSC Server per trasportare tutte le

componenti di segnalazione:- RANAP per la gestione dei canali

verso l’utente, composti da unaparte radio e da un parte di retefissa tra RNC e MGw;

- H.248 per il controllo del MGw;- BICC per il set-up e la gestione

del la chiamata tra MSC Serverdiversi;

- MAP per la gestione della mobilità.• MGw per trasportare la RANAP su IP verso il

MSC Server. In questo caso è necessario intro-durre anche la funzionalità di SGw per eseguirel’interlavoro tra il trasporto ATM tra RNC e MGwe quello IP tra MGw e MSC Server;

• presso MGw per trasportare il protocollo H.248tra MGw ed MSC Server;

• presso HLR (come già previsto in rete GSM) peril trasporto del traffico MAP.

8. Conclusioni

In questo articolo si è descritta l’evoluzionedella piattaforma di segnalazione della rete TIMverso un’architettura scalabile e ottimizzata basatasu IP in risposta alla crescita del traffico SMS veri-ficatosi negli ultimi anni. Ciò ha permesso di bene-ficiare, in termini economici, della condivisionedelle risorse di un backbone che trasporta le varietipologie di servizi evoluti di un Operatore mobile.

La piattaforma evoluta è stata realizzata, in pri-mis, per il trasporto del traffico del servizio ShortMessage a livello nazionale. Inoltre, è in fase di svi-luppo a livello internazionale una soluzione similareper la fornitura di servizi VAS, sviluppati presso piat-taforme di TIM, ai clienti delle consociate estere. Ilpercorso di evoluzione tracciato prevede l’utilizzo deltrasporto IP anche per altre componenti di segnala-zione, a tal riguardo sono stati descritti gli scenari direte di medio termine per la rete GSM/UMTS.

Questo percorso è coerente ed allineato con latendenza, tracciata dagli enti di standardizzazione3GPP ed IETF, all’integrazione delle reti e dei ser-vizi di telecomunicazione verso IP. In tale ottica è

altresì opportuno citare che la piattaforma IMS (IPMultimedia Subsystem), identificata in manieraconcorde nell’industria come la piattaforma perl’integrazione dei servizi mobili e fissi, prevede iltrasporto della segnalazione SIP nativamente su IP.

All’interno di questo percorso evolutivo, TIMItalia si è posizionata all’avanguardia nella realizza-zione di soluzioni tecnologiche innovative che lepermetteranno di precorrere i tempi.

MGwSGw MGw

SGw

MGwSGw

MGwSGw

ISUP/MTP3BICC/M3UA/SCTPH.248/M3UA/SCTPMAP/TCAP/SCCP/M3UA/SCTPRANAP/SCCP/M3UA/SCTPRANAP/SCCP/MTP3b/SAAL/AAL5/ATM

HLR

MSC Server

RNC

Centro dicommutazione

Centro dicommutazione

RNC

RNC

RNC

MSC ServerPLMN/PSTN

PLMN/PSTN

IPNetwork

ATMATM

ATMBCCHLR

M3UAMAPMGwMSC

MTP3

========

Asynchronous Transfer ModeBearer INdependent Call ControlHome Location RegisterMTP3 User Adaptation layerMobile Application PartMedia GatewayMobile Switching CentreMessage Transfer Part 3

PLMNRNC

SAALSCCPSCTPSGw

TCAP

=======

Public Land Mobile NetworkRadio Network ControllerSignalling ATM Adaptation LayerSignalling Connection Control PartStream Control Transmission ProtocolSignalling GatewayTransaction Capability Application Part

FIGURA 11› Architettura CN UMTS e trasporto segnalazione.

[1] 3GPP TS 29.002 (2002-12) “Mobile Application Part(MAP) specification”

[2] ITU-T Reccomendation Q.703 “SS7 Message TransferPart - Signalling Link”

[3] ITU-T Reccomendation Q.704 “SS7 Message TransferPart - Signalling Network function and message”

[4] Fratianni et al., “Il BackBone IP per i servizi telefonici”,Notiziario Tecnico N.1 2004

[5] IETF RFC 2960, “Stream Transmission Control Protocol”[6] 3GPP TS 29.202 “SS7 Signalling Transport in Core

Network”[7] 3GPP TS 29.232 “Media Gateway Controller (MGC) -

Media Gateway (MGW) interface”[8] ITU-T Reccomendation Series Q.1900 “Bearer

Independent Call Control”[9] ITU-T Reccomendation Q.711 “Functional description of

the SCCP Signalling Connection Control Part[10] IETF RFC 3332 “MTP3 User Adaptation Layer (M3UA)”[11] IETF Internet Draft, “MTP2 peer-to-peer Adaptation Layer (M2PA)”[12] IETF Internet Draft, “SS7 SCCP-User Adaptation Layer (SUA)”

— BIBLIOGRAFIA



Giovanni Ciccolella si è laureato inIngegner ia E let t ronica, Telecomunicaz ioni ,all’Università di Roma “La Sapienza”, nel 1999.Dopo una breve esperienza lavorativa sul lespecifiche nel campo aeronautico, nel 2000entra in T IM, ne l l ’area d i Commutaz ione,tecnologie ed industrializzazione di Core Network.Quì si occupa di sistemi di segnalazione, modellodi traffico, e progetti relativi alla segnalazione su IP,anche in ambito internazionale. Segue le attività di

settore inerenti l’introduzione di release software e di nuovi sistemi dicentrale curando la definizione delle relative specifiche e documenti diprogetto. Collabora infine ai corsi di formazione specialistica per ilpersonale TIM su tecnologie di Core Network.

Marco De Luca si è laureato con lode inIngegneria delle Telecomunicazioni all’Universitàdi Roma “La Sapienza”. Nel 2000 entra inCSELT (ogg i T ILAB) dove s i occupa d ievoluzione dell’architettura e dei protocolli deisistemi di rete fissa verso le reti Next GenerationNetworks. Dal 2002 opera nell’area di MobileCore Network ded icandos i a l l ’evo luz ionedell’architettura dei sistemi GSM/GPRS/UMTS.Dal 2003 è il referente delle attività, nell’ambito

dei progetti di consulenza per TIM, relative all’evoluzione della rete disegna laz ione verso IP. Da l 2004 s i occupa, ino l t re , d idimensionamento e di servizi dell’architettura IMS, partecipando allarealizzazione del servizio TurboCall.

Sandro Perlini si è laureato nel 1998 inIngegneria Elettronica all’Università di Firenze. Haconseguito un Master in Telecomunicazionipresso i l Centro IFOA di Reggio Emil ia. Halavorato in Spazio ZeroUno nello sviluppo e nellaprogettazione di sistemi per TelecommunicationManagement Network per Pirel l i Cable. Dal1999 a l 2001 ha lavorato per T ILAB a l laqualificazione ed evoluzione delle piattaforme dicommutazione della rete mobile GSM e GPRS.

Dal 2001 é in TIM, dove si occupa dell’ingegnerizzazione della CoreNetwork GSM e dell’evoluzione per la futura integrazione delle reti2G/3G. Ha coordinato i progetti per l’introduzione in rete TIM dellasegnalazione su IP.

3GPP 3rd Generation Partnership ProjectATM Asynchronous Transfer ModeBICC Bearer Independent Call ControlCAP Camel Application Part CN Core NetworkCS Circuit SwitchedDMA Direct Memory AccessDPC Destination Point CodeETSI European Telecomunications Standards InstituteFNR Flexible Number RoutingGRX GPRS Roaming eXchangeGSR Gigabit Switch RouterGTT Global Title TranslationHLR Home Location RegisterHSRP Hot Standby Routing ProtocolIETF Internet Engineering Task ForceIMS IP Multimedia SubsystemINAP Inteligent Network Application PartISUP ISDN User PartITU International Telecomunications UnionM2PA MTP2 Peer-to-peer Adaptation layerM3UA MTP3 User Adaptation layerMAP Mobile Application PartMGw Media GatewayMNP Mobile Number PortabilityMO Mobile OriginatedMSC Mobile Switching CentreMSISDN Mobile Station International ISDN numberMSU Message Signalling UnitMT Mobile TerminatedMTP Message Transfer PartOLO Other Licensed OperatorsOPC Originating Point CodeOSPF Open Shortest Path FirstOSS Operations Support SystemPLMN Public Land Mobile NetworkPoP Point of PresencePSTN Public Switched Telephone NetworkRAN Radio Access NetworkRANAP RAN Application PartRNC Radio Network ControllerRSP Route Switch ProcessorSAAL Signalling ATM Adaptation LayerSCCP Signalling Connection Control PartSCP Service Control PointSCTP Stream Control Transmission ProtocolSEP Signalling End PointSGw Signalling GatewaySIGTRAN SIGnalling TRANsportSIP Session Initiation ProtocolSM Short Message

— ABBREVIAZIONI

SMDS Short Message waiting Data Set procedureSMMO Short Message Mobile OriginatedSMSC Short Message Service CentreSMSoIP Short Message Service over IPSRI Send Routing InformationSS7 Signalling System n.7STP Signalling Transfer PointSUA SCCP User Adaptation layerTCAP Transaction Capability Application PartTDM Time Division MultiplexTR nodo di TRansitoVIP Versatile Interface ProcessorVLR Visited Location Register


La piattaforma di Surveillance e Fault Management: reti Intranet e

servizi in outsourcing

VINCENZO ASARO

DINO GALUPPI

FILIPPO PICCIRILLO

GIUSEPPE PRISCO

Introdotta nel 2001 nell’ambito del progetto “Nuova Piattaforma di Gestione”per le reti e i servizi broadband, la Piattaforma di Surveillance e FaultManagement costituisce la componente che è stata maggiormente estesa acopertura dei diversi domini tecnologici e dei diversi vendor cosi` da ingloba-re, sotto un unico framework di riferimento, le diverse componenti di rete.L’articolo, dopo una breve introduzione di contesto e di definizione delle pro-blematiche generali legate alla Surveillance e Fault Management delle reti,approfondisce le soluzioni adottate da Telecom Italia Wireline nell’ambito dellereti Intranet e delle reti in Outsourcing dei clienti Executive.Le soluzioni implementate per la gestione della rete di Trasporto ed Accessoe delle reti Broadband sono state trattate nell’articolo “La Piattaforma diSurveillance e Fault Management: reti broadband, trasporto e commutazio-ne” pubblicato su questa rivista a dicembre 2004.

1. Introduzione

La Piat taforma di Survei l lance e Faul tManagement (SFM) della Rete, introdotta nel 2001nell’ambito del progetto della Nuova Piattaforma diGestione per le reti e i servizi broadband, venneestesa, nel 2002, a l la gest ione del le ret i inOutsourcing della cl ientela Executive ed al lagestione del la rete Intranet di Telecom Ital iaWireline, al fine di garantire il mantenimento ed ilmiglioramento dei servizi di gestione offerti alcliente, esterno ed interno.

La Piattaforma svolge i compiti di sorveglianzadella rete, mediante raccolta e gestione degliallarmi dei diversi nodi e segmenti di rete, e digest ione del la local izzazione dei guast i , s iamediante correlazione degli allarmi sia attraversostrumenti specifici di diagnosi.

Questo articolo approfondisce le soluzioniadot ta te da Te lecom I ta l i a Wi re l ine per lagestione delle reti clienti in Outsourcing e per larete aziendale Intranet, completando così ladescrizione delle diverse piattaforme di SFM chein precedenza ha riguardato la gestione delle retipubbliche [1].

2. Architettura generale di Surveillance e FaultManagement

L’obiettivo della Piattaforma di Surveillance eFault Management è la supervisione della retemediante meccanismi di raccolta, filtraggio e cor-relazione degli allarmi e la diagnosi mediante stru-menti di analisi del problema a diversi livelli (servi-zio, rete ed apparato).

PIATTAFORME

ASARO › GALUPPI › PICCIRILLO › PRISCO • La piattaforma di Surveillance e Fault Management: reti Intranet e servizi in outsourcing


La figura 1 rappresenta una schematizzazionead alto livello dell’architettura funzionale comples-siva della Piattaforma di SFM delle reti private. L’architettura presenta tre livelli funzionalmente spe-cializzati:• un livello di raccolta e correlazione con compo-

nenti specializzate per le reti Intranet e inOutsourcing;

• uno strato di concentrazione degli eventi e laloro archiviazione;

• uno strato di presentazione agli operatori suddi-visi per competenza.

L’architettura, basata sulla suite CIC (CiscoInformation Center) [2], prevede l’interazione congli Inventory di Rete [3], per l’acquisizione di infor-mazioni rilevanti ai fini della sorveglianza e dellacorrelazione, con un Data Base (DB) allarmi, per lamemorizzazione e storicizzazione degli stessi, conil sistema di TTM (Trouble Ticket Management) perla segnalazione di allarmi che richiedono l’inter-vento manuale e la gestione di un Trouble Ticket.

In particolare la piattaforma per le reti private ècostituita, nel primo livello, da componenti indipen-denti che realizzano le funzioni di raccolta degliallarmi, de-duplicazione, filtraggio e correlazioneintra-dominio.

In ciascuna delle due istanze della piattaforma, isuccessivi due livelli sono realizzati da vari compo-nenti specializzati che garantiscono l’implementa-zione delle funzioni di concentrazione e dispaccia-mento e di presentazione degli allarmi. Vengonoinoltre gestite ulteriori funzionalità per l’integra-zione con gli altri strumenti della piattaforma (adesempio l’integrazione CIC-TTM per la generazionedei Trouble Ticket), e l’archiviazione degli allarmi,con funzioni di analisi storica dei dati (Data BaseAllarmi).

La piattaforma di SFM fornisce all’operatore diesercizio informazioni sullo stato delle risorse direte e sui servizi forniti e consente di suddividere lagestione delle reti e degli apparati sulla base dellecompetenze dei diversi centri mediante la gestionedelle viste e delle funzioni caratteristiche asse-gnate ai diversi profili di operatore.

L’architettura di gestione degli allarmi è artico-lata su tre livelli:• Collection Layer: implementa le funzionalità di

acquisiz ione e aggregazione degl i a l larmi(Col lect ion) , di correlaz ione intradominio

(Correlation) per ciascuna rete clientegestita o per la rete Intranet aziendale• Routing Layer: implementa le funziona-lità di dispacciamento (Routing) degliallarmi al presentation layer, al sottosi-stema di reportistica e datawarehouse(DB Al larmi, Reporter) ed ai s istemi“NorthBound” (ad esmpio TTM).• Presentation Layer: implementa le fun-zionalità di supporto alla visualizzazionecon interfacce grafiche GUI (GraphicalUser Interface) rivolte agli operatori TI,attraverso client dedicati ed ai clienti inmodalità Web.

Questa architettura permette una fortescalabilita` della Piattaforma di SFM tra-mite suddivisione della rete gestita indomini distinti (domain layer) con un primolivello di correlazione e filtraggio degliallarmi; la suddivisione in più domini dicontrollo (interdomain layer) in base allasuddivisione delle competenze dei centri digestione e degli operatori, ognuno deiquali implementa le correlazioni interdomi-nio specifiche; ed infine la suddivisione delcarico su più server (display layer) in baseal numero di operatori da supportare.

3. La gestione della surveillance dei Servizi in outsourcing

Nel 2002 è stata avviata una profonda revisionedella gestione dei servizi di outsourcing forniti daTelecom Italia ai clienti Executive attraverso l’exCentro Nazionale di Assistenza. Gli obiettivi di talerevisione erano:• il passaggio ad una gestione centralizzata; ogni

centro di gestione dei clienti costituiva, infatti,un sistema verticale indipendente dagli altricentri, con la conseguente frammentazionegestionale e notevole dispendio di risorse, siasotto l’aspetto economico che tecnico;

• la disponibilità di un inventory unico delle consi-stenze fornite ai clienti; il Customer NetworkInventory era, di fatto, costituito da molteplicidatabase gestiti localmente e non integrati traloro;

• la razionalizzazione dei servizi forniti alla clien-tela e la definizione di un’offerta omogenea digestione delle reti Cliente, sia in termini di stru-menti utilizzati che di modalità di erogazione.

SFM-HCW SFM-I

ClientiOutsourcing

Operatori

Presentation Layer

SFMReti Outsourcing

ReteCliente 2

ReteCliente 1

ReteCliente n

Rete Dacon- Planet

SFMRete Intranet

Routing Layer

TTMDB

Allarmi

Intranet

HCWI

SFM

===

High Care WareIntranetSurveillance Fault Management

UNICA

FIGURA 1› Architettura generale di surveillance e fault management.



Al fine di rispondere a tali esigenze e con l’o-biettivo di garantire alla clientela outsourcing ele-vati livelli di disponibilità e di qualità del servizio èstata sviluppata la Nuova Piattaforma di Gestionedelle reti dei clienti in outsourcing denominata“High Care Ware” (PG HCW). Per una descrizionepiù dettagliata della gestione di un cliente in out-sourcing si veda il riquadro “Gestione di un clientein Outsourcing ed il portale Tu conTi”

La piattaforma nasce come una ulteriore istanzadel la architettura SFM già svi luppata per lagestione delle reti e dei servizi broadband. La suaarchitettura è rappresentata in figura 2.

L’architettura della piattaforma è articolata sudue livelli:• “livello centralizzato”, che comprende i sistemi

comuni e condivisi tra tutti i Clienti ed è allocatosu server di classe Enterprise in configurazioneHA (High Availability);

• “l ivel lo peri fer ico” costituito dai Centr i diGestione delle reti dei Clienti, i quali possonoessere dedicati al singolo Cliente o condivisi trapiù Clienti (multiclient), a seconda della dimen-sione della rete monitorata. Ciascun Centro diGestione è costituito da server di classe work-group sui quali sono installati i sistemi chedevono essere connessi direttamente alla retedel Cliente (Fault Management, Performance eConfiguration Management).Il componente Customer Network Inventory è

costituito da UNICA/D (UNICA Dati), data base cen-tralizzato contenente le informazioni relative ai servizidi Networking erogati ai Clienti, alimentato diretta-

mente da Order Manager, tramite il bus di comunica-zione Tibco, in modo tale da avere una forte integra-zione con i sistemi di provisioning aziendale.

Il livello centralizzato della surveillance è basatosu strumenti della suite CIC (Cisco InformationCenter) e su software custom per integrare tra loroquesti componenti.

L’infrastruttura principale è costituita dagliObject server che contengono e gestiscono glieventi ricevuti dal livello periferico. Essi si dividonoin COS (Collection Object Server) che si occupanodella raccolta, arricchimento, reduplicazione e cor-relazione degli eventi, ROS (Routing Object Server)

che instradano gli eventi verso i sistemidi presentazione e POS (PresentationObject Server) che supportano la presen-tazione e la gestione degli eventi daparte degli operatori.

A livello COS, lo strumento Impactpermette l’arricchimento e la correlazionetramite accesso al data base operazio-nale della piattaforma INDB (IntegratedNetwork Data Base).

La presentazione degli eventi agli ope-ratori avviene attraverso due modalità:Desktop, nella quale lo strumento utiliz-zato è un client che fornisce tutte le fun-zionalità di gestione e quindi viene usatodagli operatori di supervisione, e Webtop,che invece fornisce viste Web di sintesicon aggregazioni per tipologie di allarmidettaglio fino al singolo allarme. Tali vistesono utilizzate sia da operatori TelecomItalia (sia personale di supervisione cheresponsabili di coordinamento) sia dalcliente finale, nei casi in cui è stata con-trattualizzata la modalità di visualizza-zione in tempo reale degli eventi.

Nel caso in cui il Cliente abbia con-trattualizzato la gestione della rete inmodalità proattiva, è necessario che gliapparati presenti nel data base UNICA erelativi ai sistemi della catena di provisio-ning siano posti in gestione all’interno

della piattaforma di SFM. Nella modalità proattivauna procedura, denominata “Presa in Carico” (PIC),attiva un componente interno alla piattaforma(INDB), che provvede al popolamento dei sistemiperi fer ici (Fault , Performance, Configurat ionManagement), assicurandone l’allineamento conl’inventory centralizzato. La comunicazione tra idiversi sistemi avviene mediante bus TIBCO.

La PIC inoltre, attraverso il motore di discoveryThor, raccoglie i dati tecnici dagli apparati stessi eli restituisce ad UNICA, così da arricchire le infor-mazioni commerciali di inventory. La mimica di col-loquio della PIC è rappresentata in figura 3.

Sulla base delle informazioni tecniche delleinterfacce scoperte in rete, il sistema calcola auto-maticamente, mediante apposite procedure, sia icollegamenti tra i singoli apparati che i collega-menti end to end e permette l’arricchimento ammi-nistrativo con i dati commerciali provenienti dallacatena di provisioning.

UNICA/D

LivelloCentralizzato

LivelloPeriferico

TTM

Web Top Desk Top CIC-POS

CIC-ROS

CIC-COS

CISCOWORKSNHNNM

IMPACT

Reporter Gateway

DBAllarmi

Reti in Outsourcingdei Clienti

CICCOSINDB

NHNNMPOSROS

THORTTM

=========

CISCO Information CenterCollection Object ServerIntegrated Network Data BaseNet HealthNetwork Node ManagerPresentation Object ServerRouting Object ServerTopologic Hierarchic Object RetrieverTrouble Ticket Manager

Bus TIBCO

INDB

THOR

FIGURA 2› Architettura generale della piattaforma di SFM HCW.



La componente di Inventory e Data BaseOperazionale (INDB) viene costantemente mante-nuta allineata a UNICA/D tramite la procedura diPresa in Carico e svolge le funzionalità di DatabaseOperazionale a supporto dei sistemi di Assurance.

La componente periferica della piattaforma digestione HCW è costituita dai centri di gestionedelle reti clienti. Ciascun Centro di Gestione,appartenente al Livello Periferico della piattaformacontiene i seguenti sistemi:• NNM (Network Node Manager - Fault

Management): raccoglie gli eventi spontaneidegli apparati ed effettua lo “status polling”.

• NH (NetHealth - Performance Management):produce la reportistica schedulata e on demande dove previsto, fornisce il monitoraggio proat-tivo del livello di performance della rete delcliente mediante la raccolta dei dati in modalitànear real time (frequenza di polling di 5 minuti)direttamente dagli apparati. La violazione dellesoglie di performance provoca la generazione el’invio di allarmi al sistema di Surveillance CIC,dove vengono visualizzati.

• Cisco Works 2000 /Cosmos (ConfigurationManagement): il primo sistema consente la con-figurazione degli apparati di tecnologia Cisco, ilprodotto COSMOS, sviluppato successiva-mente in Telecom Italia, consente la gestionedegli ambienti multivendor (tecnologie Cisco,Marconi e 3Com).

• INDB (Inventory Network Data Base): contienetutti i tools custom che assicurano funzionalitàspecifiche e l’integrazione con i prodotti com-merciali, oltre ad essere il db operazionale dellapiattaforma.

• THOR: modulo per la discovery e la raccolta deidati dagli apparati di rete.Una funzione di particolare importanza svolta

dalla piattaforma di gestione HCW, che controlla gliapparati della rete del cliente, è la correlazione degliallarmi all’interno del dominio di gestione (intradomi-nio). In questo ambito la correlazione è essenzial-mente orientata a fornire all’operatore di supervi-

Gestione di un clientein outsourcing e ilportale Tu conTI

La funzione EnterpriseOperations offre i propri servizi diOutsourcing tramite una strutturadi Assurance dedicata alle solu-zioni di dati e fonia, e servizi IT.La struttura è centralizzata suquattro poli territoriali, siti inRoma, Milano, Bari e Mestre ed èin grado di fornire assistenza h24alla Clientela di Telecom Italia.

Il modello operativo prevedeuna struttura di front end, una diback office ed un service mana-ger assegnato al Cliente.

La struttura di front end èresponsabile della gestione delservizio di assistenza tecnica e

costituisce il contact point deiClienti per qualsiasi problema difunzionamento delle reti e deiservizi contrattualizzati.

Il servizio di accoglienza e digestione personalizzata verso ilCliente è assicurato grazie adun numero verde con accessopersonalizzato e tramite il por-tale Tu conTI.

La piattaforma di gestioneHCW permette al personale deicentri di gestione di front end dieffettuare:• Gestione Proattiva dei disser-

vizi e malfunzionamenti; taleproattività è garantita dallavisualizzazione automaticadegli allarmi che arrivano inmaniera automatica dagl iapparati sulla console unicadi gestione;

• Controllo continuativo delleperformance di Rete;

• Comparazione dei livelli diserviz i erogat i r ispetto aquelli contrattualizzati.In particolare l’apertura in

modalità proattiva dei fault con-

sente di intervenire prontamentelimitando i tempi di ripristino delfermo. Il cliente può quindi dele-gare a Telecom Italia la gestionedella propria rete avendo in ognicaso a disposizione, tramite ilportale Tu conTI, gli stessi stru-ment i ad uso del personaleTelecom nell’ottica di fornire alCliente un servizio trasparentenonché altamente di qualità.

Il disservizio segnalato dalCliente, oppure rilevato proatti-vamente dal la piattaforma,viene diagnosticato dal perso-nale di front end, eventualmentecon l’ausil io del personale diback office al fine di circoscri-verne il più possibile la causa.Viene quindi dispacciato verso lestrutture di assurance di Retedislocate capillarmente sul terri-torio per l’intervento sui circuiti osull’apparato presso il Cliente.

I l personale di f ront endcoordina, quindi, tutte le attivitàend to end per il ripristino delguasto fino alla verifica e la chiu-sura dello stesso con il Cliente.

NetworkInventory

INDBPIC

Configurazione eattivazione servizi

NNM

UNICA

Configurazione prodottilayer periferico

Caricamento dati

amministrativi

Autodiscovery completadelle configurazioni

Network

NH

Cisco Works2000/COSMOS

NHNNM

PIC

===

Net HealthNetwork Node ManagerPresa In Carico

FIGURA 3› Flusso informativo della Procedura di presa in carico.



Tutte le informazioni relativeal fault vengono inser i te nels istema di TTM (TroubleTicketing Management) tramite ilquale vengono poi prodotti i“Fault Reporting”. La produzionedi ta le report ist ica ha comeobiettivo quello di evidenziare,per ogni singolo disservizio, lacausa del malfunzionamento,l’eventuale ripetitività, le azioniintraprese per il ripristino e ladurata del disservizio in rapportoallo SLA da garantire.

Con l’applicazione di TTM èpossibile tenere sotto costantecontrollo, in tempo reale, tutte lediverse fasi del l ’ intervento edelle attività di riparazione sututto il territorio nazionale e congradi di visibi l i tà opportuna-mente distribuiti ai vari livelli diresponsabilità della struttura.

Il personale di front end, tra-mite le attività di manutenzionepreventiva ed in particolare dianalisi dei guasti ripetitivi, non-ché degli allarmi catalogati dals istema di t rouble t icket ing ,svolge tutte le azioni correttiveper evitare il ripetersi dei malfun-zionamenti riscontrati, limitandoin questo modo il numero com-plessivo dei fault del Cliente.Inoltre, una verifica costante deisistemi di backup dei collega-menti in gestione garantisce ele-vati livelli di disponibilità del ser-vizio complessivo evitando chela caduta del collegamento prin-cipale del cliente determini unfermo della sede.

Gli specialisti della struttura diback office intervengono nell’atti-vità di diagnosi e nella verifica diparticolari allarmi riscontrati, rela-zionandosi, laddove occorre, conil supporto special ist ico delCentro Tecnico di Assistenza delcostruttore per analizzare con-giuntamente gli output della dia-gnosi corredati da eventuali infor-mazioni “storiche” sui guastiriscontrati o sulla ripetitività dialcuni di essi in modo da indivi-duare le cause del malfunziona-mento e le azioni/interventi daintraprendere.

I l Serv ice Manager asse-gnato al Cliente ha la responsa-bilità del coordinamento di tutti

quegli interventi tecnici effet-tuati sulla rete relativamente alleattività di miglioramento, ade-guamento e correzione, in parti-colare è suo compito organiz-zare le strutture di Telecom e deifornitori allo scopo di limitare almassimo il tempo d’interventosui disservizi.

Il Service Manager è quindi ilgarante del rispetto dei ServiceLevel Agreement contrattualizzatipartecipando agli incontri perio-dici con i responsabili tecnici delCliente per l’analisi del livelloqualitativo del servizio offerto.

I l portale TU conTI per iClienti in Outsourcing è il cuoredi un progetto finalizzato ad otti-mizzare il servizio offerto met-tendo a disposizione del Clienteapplicativi e servizi on line cheoffrono una valida alternativa alcanale telefonico e miglioranoulteriormente l’efficienza del ser-vizio erogato.

I servizi di TU conTI, dise-gnati per i Clienti consentono, inparticolare, una migliore segna-lazione ed organizzazione di tuttii processi di tipo proattivo, lavisione dell’avanzamento delleattività e dello stato di escalationdi ciascun ticket, la consulta-zione e condivisione dei reportdi qualità. Inoltre un’altra carat-teristica principale del portale, èrappresentata da tutta una seriedi serviz i mult icanale qual il’SMS, la mail, le news dedicate,ed altri applicativi di comunica-zione in real time che potenzianola comunicazione e la relazionetra Cl iente e Telecom Ita l ia,offrendo una modalità di intera-zione di tipo one to one attra-verso diversi canali.

L’operatore, a sua volta, hamodo di decidere a quali desti-natar i e su qual i strumentidi ffondere una segnalazioneverso il Cliente. Così, in caso disegnalazione di guasto grave ocomunque di particolare ri le-vanza, sceglie di divulgare lastessa comunicazione attraversotutti i canali messi a disposi-zione dal sistema TU conTI e diinviarla non solo al Cliente, maanche ai referenti interni, quali ilvenditore, il service manager ed

i l responsabi le del CentroNazionale.

Il portale Tu conTi contienetutti gli strumenti, contenuti edapplicativi che il Cliente ha adisposiz ione nel l ’ambito diquanto contrattual izzato esecondo due diversi profili diaccesso: “Profilo Operatore” e“Profilo Responsabile”

Le offerte che prevedono l’u-tilizzo del portale Tu conTI come“Presentation Layer” nei con-front i del Cl iente sono almomento Datasymphony,Desktop&Lan Mng e SecurityDevice Management.

Queste offerte prevedonol’accesso in modalità Web allefunzioni di apertura e consulta-zione dello stato di avanzamentodei ticket aperti per le segnala-zioni dei fault ma anche perrichiedere i servizi contrattualiz-zati. Ad esempio per richiedereuna modifica di una postazionedi lavoro nell’ambito del servizio“Desktop Management”, i lCl iente apre una “servicerequest” sul portale e tramite lastessa pagina Web è in grado diseguire l’avanzamento delle atti-vità eseguite da ES, nonché lapossibilità di gestire on line l’e-ventuale appuntamento dell’in-tervento richiesto.

Il portale fornisce dunque lapossibilità di usufruire di:• interfaccia user friendly quale

quella offerta dai browser diuso universale;

• accesso garantito e protettoda user name e password;

• visibilità dello stato del gua-sto o della service request edel suo tracciamento (asse-gnazione, presa in carico,chiusura, … ;

• visualizzazione della lista deiguasti o delle service requestin un interval lo temporaleselezionato dal Cliente con irelativi grafici .Ciò consente al Cliente di

usufruire di modalità veloci peraccedere, nella massima traspa-renza, al servizio di assistenzacon l’obiettivo di aumentare ill ivello qualitativo del servizioofferto da Telecom Italia.



sione tutte le informazioni necessarie acapire se l’evento sta provocando o nodisservizio al cliente e cosa bisogna fareper ripristinare il servizio.

Tenendo ben presente che si opera inun contesto nel quale il cliente paga per ilservizio di manutenzione proattiva e siaspetta tempi di reazione dell’ordine deiminuti, è dunque indispensabile forniresubito all’operatore le informazioni neces-sarie ad attivare immediatamente la fase didiagnosi e risoluzione. Per fare ciò, sonoimplementate due tipologie di correlazione:• Correlazione amministrativa: l’allarme

è confrontato con i dati di inventoryallo scopo di aggiungere ad esso tuttii dati tecnici e commerciali che per-mettono la localizzazione del fault el’avvio immediato delle attività di dia-gnosi e di risoluzione. All’allarme ven-gono quindi aggiunte le informazionisul cliente, la sede allarmata e il riferi-mento da contattare.

• Correlazione eventi: l’allarme vieneconfrontato con altri eventi e/o con laconfigurazione specifica della rete del clienteper determinare se esso genera disservizio e diche tipo di disservizio si tratta.Dal punto di vista dimensionale, la Piattaforma

di Gestione HCW gestisce oggi più di 90.000 appa-rati (compresi i Clienti con sola reattività) per circa1350 clienti, che hanno contrattualizzato servizidelle famiglie outsourcing (Elite, VIP e Consip). Il“Livello Periferico” è presente con circa 90 istanzee in totale, tra livello periferico e centralizzato,sono installati circa 200 server.

L’architettura CIC a tre livelli è composta in totaleda 24 Object Server, compresi quelli di failover.

I dati della piattaforma (circa 9 TeraBytes intotale) sono tutti ospitati in una Storage AreaNetwork connessa in Fiber Channel con i server.

Per gestire un’architettura così articolata è statonecessario costruire una opportuna infrastruttura dimonitoraggio: l’intera piattaforma HCW è sorvegliatada un sistema di System & Application Managementbasato su architettura Concord con agent installatisu ciascun server oggetto di monitoraggio (sia dilivello centralizzato che periferico); tale sistema èstato integrato con quello di Surveillance CIC, alquale invia allarmi generati alla violazione dei livellidi soglia impostati che sono raccolti e visualizzati inuna vista creata appositamente.

4. La Surveillance delle Reti e Servizi Intranet aziendali

I componenti della piattaforma SFM per le Retied i Servizi Intranet Aziendali, rappresentata nellafigura 4, sono divisibili per area funzionale secondola seguente ripartizione:• moduli di Inventory, necessari a mantenere la

descrizione ed il riconoscimento della rete;• moduli di Network e Service Surveillance per la rac-

colta, elaborazione e presentazione degli allarmi;• moduli di diagnostica dei servizi per l’analisi

dello stato dei servizi e delle risorse.La componente di Inventory e DB Operazionale

(INDB) mantiene l’inventario degli apparati e dei ser-vizi gestiti e svolge le funzionalità di DatabaseOperazionale a supporto dei sistemi di Assurance.Le informazioni sono acquisite tramite integrazionecon l'inventory aziendale UNICA/I. Tale integrazioneavviene mediante la procedura denominata Presa inCarico la quale, utilizzando come componente tec-nologico il bus TIBCO, consente un dialogo bi-dire-zionale che assicura l'allineamento tra l'inventoryoperazionale della piattaforma e l’inventory UNICA/I,contenente la consistenza di riferimento, e permettel’arricchimento del dato presente in quest'ultimoinventory con le configurazioni tecniche degli appa-rati lette direttamente dalla rete. L’inventory opera-zionale è costituito dal sistema INDB, dotato dimodulo di discovery specializzato denominato THOR(per la raccolta dalla rete, dagli apparati ed ElementManager) con architettura e modalità analoghe aquelle della piattaforma SFM-HCW.

La componente di Network e ServiceSurveillance realizza la sorveglianza delle reti e deiservizi mediante le funzionalità di acquisizione, ela-borazione, correlazione e presentazione degliallarmi. Le funzionalità di acquisizione, realizzatedai moduli NNM (Network Node Manager) e IDC-MON (Ipnet Data Collector MONitoring), consen-tono il recupero degli allarmi dagli apparati di reteo dai relativi Element Manager ed il polling perio-dico dello stato delle risorse e dei servizi della rete.

I l sistema CIC, basato sulla suite NetcoolOmnibus di Micromuse, realizza la gestione degliallarmi e la loro correlazione, garantendo la loro pre-sentazione su viste dedicate per singolo centro digestione. Inoltre, tramite il modulo Impact, il sistemaesegue l’arricchimento degli allarmi provenienti dalla

UNICA/D CPC TTMDBAllarmi

Bus TIBCO

Network & Service SurveillanceInventory OperationalDatabase

INDB

THOR

STMCIC

NNM

MPLSPLANETDACONCRM Dati

IDC

CICCPCCRMIDC

INDBMPLSNNMSTM

THORTTM

==========

CISCO Information CenterCISCO Provisioning CenterCustomer Relationship ManagementIPnet Data CollectorIntegrated Network Data BaseMultiProtocol Label SwitchingNetwork Node ManagerSodalia Traffic ManagerTopologic Hierarchic Object RetrieverTrouble Ticket Manager

FIGURA 4› Architettura generale di DSFM per le reti Intranet aziendali.



rete, con informazioni relative alla localizzazione dellerisorse allarmate, attraverso l’integrazione con gliinventory. Tramite CIC vengono tracciati e monitoratii riscontri della presa in carico dell’allarme ed è con-sentita l’apertura e la chiusura di un Trouble Ticketda parte dell’operatore sul sistema TTM.L’architettura di dettaglio di CIC è analoga a quelladella piattaforma SFM-HCW e comprende i tre livelliCOS, ROS e POS illustrati nel precedente paragrafo.

STM (Sodalia Traffic Manager) è un applicativocustom sviluppato da Telecom Italia per il monitorag-gio delle performance delle reti dati. Le funzionalitàdi STM consentono innanzitutto la raccolta dei datidi misura elementari dagli apparati in modalità nearreal time e la loro analisi ed un’eventuale filtraggio, inmodo da garantirne la congruenza e la qualità. Avalle di questo processo, i dati elementari possonoessere aggregati e storicizzati in modo da generareindicatori complessi, significativi per individuare lostato della rete e produrre la reportistica necessariaagli operatori per avere una vista significativa e sinte-tica dello stato prestazionale della rete.

La reportistica di STM è dotata di avanzate funzio-nalità di analisi e di una elevata flessibilità di aggrega-zione e presentazione dei dati, in modo da fornire aglianalisti di rete uno strumento di analisi facilmente adat-tabile alle varie esigenze di monitoraggio della rete.

STM è dotato, inoltre, di funzionalità di genera-zione degli allarmi di degrado, ottenuti attraverso ilconfronto degli indicatori con dei valori di soglia.

Tra i sistemi esterni, di particolare interesse sono isistemi di Inventory ed aggiornamento della configura-zione di rete, che forniscono alla Piattaforma i dati diconsistenza aggiornati (UNICA/I per ilNetwork/Service Inventory) ed il sistema di attivazionein rete dei Servizi Dati configurati sulla rete intranet.

La piattaforma di gestione delle reti Intranetgestisce i domini DACON e PLANET, che, nati ini-zialmente come separati in virtù dei loro differentiobiettivi, sono oggi completamente integrati dalpunto di vista tecnologico e gestionale. Inoltre per latecnologia MPLS è stato definito uno specificoambito di gestione con delle viste di presentazionepersonalizzate. Per una descrizione generale sirimanda al riquadro “Le reti Dacon e Planet”.

Sin dalla sua introduzione in esercizio (luglio2002), la piattaforma per la gestione delle intranetsi è confrontata con il problema di monitorare l'ac-cessibilità e le performance delle applicazioni criti-che per il business aziendale, a cominciare dallapiattaforma CRM (Customer Relat ionshipManagement). A tale scopo sono state sviluppatespecifiche correlazioni e viste di presentazione.

Complessivamente la Piattaforma di SFM Intranetcopre più di 9.000 apparati di diverse tecnologie ecostruttori. La sua adozione ha consentito una dra-stica diminuzione dei fault sulle reti aziendali pas-sando da una media di 10.000 allarmi attivi nel primoperiodo di esercizio, all'attuale media di 400.

5. Conclusioni

L’evoluzione dei servizi di gestione in outsour-cing richiesti da aziende moderne e dinamichenecessita di strumenti di Nework Assurance flessibilied in grado di coprire le diverse esigenze che classidi clienti o clienti singoli possono manifestare.

La Piattaforma di Survei l lance e FaultManagement, di cui si è dotata Telecom ItaliaWireline, sta dimostrando di poter assorbire lediverse richieste di servizio provenienti dai vari

Le reti DACON e PLANET

Le reti Dacon e Planet sononate separatamente per offrireservizi di connettività IP ai varisistemi di gestione della Rete(Dacon) e alle postazioni di lavoronegli uffici aziendali (Planet).Successivamente, nell’ottica diottimizzazione delle infrastrutturee delle risorse, le due reti sonostate integrate in modo da fornireuna unica infrastruttura (Intranet)per Telecom Italia.

Entrambe nascono con unastruttura a più livelli (un back-bone, un livello di concentra-zione intermedio e le sedi perife-riche), piani di indirizzamentoseparati e non compatibili, stru-menti di supervisione (SFM) indi-pendenti e separati e differentiorganismi di gestione e supervi-

sione: le UTR (Unità Territoriali diRete) per la Dacon e i l GISP(Gest ione Infrastrutture eSupervisione Postazioni) per laPlanet.

I l percorso d’integrazionedelle due reti avviene in più fasi.La prima fase venne realizzataattraverso la costruzione dialcuni gateways specializzatiche permettevano la comunica-zione tra le due reti, soluzione dielevata complessità gestionale edi difficile scalabilità.

In una fase successiva èstata introdotta una soluzioned’integrazione basata sull’uti-lizzo delle VPN MPLS. Il back-bone del la Planet è statomigrato in una VPN MPLS delbackbone Dacon, mentre l’ac-cesso rimaneva separato.

Infine la Intranet si è evolutain modo da supportare la con-

nettività di nuovi servizi mission-crit ical qual i CRM, Info 412,Security, reti di servizio BBN e siè estesa integrando, nelle stessemodalità della Planet, anche lereti di altre aziende del GruppoTelecom Italia (TILab, Pirelli).

In parallelo all’evoluzione del-l’integrazione delle due reti, èstato poi avviato il progetto dellaNuova Piattaforma di Gestionedella Rete Intranet con l’obiet-tivo di fornire uno strumento effi-cace ed efficiente nel supportareil nuovo processo di gestionedelle reti. Il progetto prevedeuna soluzione di gestione dedi-cata che si basa sull’architetturagià implementata per le reti pub-bliche, con copertura delle areedi Surveil lane & PerformanceManagement, Provis ioning,Network Inventory e NetworkCreation.



clienti, attraverso uno strumento uniforme per lagestione dell’allarmistica e della diagnosi che con-sente un’elevata efficacia ed efficienza interna.

Considerando che le due piattaforme sopradescritte hanno una matrice tecnologica ed un conte-sto organizzativo comune, per ottimizzare ulterior-mente i costi di gestione, è stata definita una strategiadi integrazione tra le due piattaforme. Il concetto dibase di questa strategia di integrazione (attualmentein fase di pianificazione) è quello di concepire la reteIntranet come un “grande cliente” della PG HCW, allastregua di realtà esterne come Ente Poste o Consip.

In virtu dell’elevato grado di flessibilità dei suoistrumenti, la piattaforma di Surveillance dei clienti inoutsourcing consente anche l’introduzione di funzio-nalità di correlazione allarmi ed ha anche la poten-zialità di permettere la gestione inter-dominio con lereti pubbliche.

Basata su una piattaforma commerciale adatta-bile e scalabile, la Piattaforma di Surveillance e FaultManagement di Telecom Italia Wireline costituisce lacomponente gestionale oggi maggiormente estesa acopertura dei diversi domini tecnologici e dei diversivendor cosi` da inglobare sotto un unico frameworkdi riferimento le diverse componenti di rete dalBroadBand al BackBone Nazionale, dalle reti inOutsourcing alle Intranet aziendali, dalle reti diTrasporto più innovative (SDH, WDM) alle legacy(PDH), sino ad includere la rete di commutazionetradizionale e le nuove reti per i servizi VAS.

[1] Asaro V., Mola F., Piccirillo F., Pinnola A.: La Piattaforma diSurveillance e Fault Mangement: reti broadband, trasportoe commmutazione, Notiziario Tecnico Telecom Italia, Anno13 n. 2, Dicembre 2004, pp. 81-92

[2] www.micromuse.com/products/cic_overview.html[3] Castaldo D., Iorio N.: Telecom Italia punta su UNICA - un

solo Data Base per la gestione della Rete, Notiziario TecnicoTelecom Italia, Anno 12 n.1, Dicembre 2003, pp. 65-79.

— BIBLIOGRAFIA

— ABBREVIAZIONI

Filippo Piccirillo si è laureato in IngegneriaElettrotecnica presso l’Università degli Studi diRoma “La Sapienza” nel 1981. Ha iniziato la suaattività in SIP (oggi Telecom Italia) nel 1982 nelSettore Energia occupandosi degl i svi luppiinnovativi e della accettazione dei sistemi dialimentazione per le Telecomu-nicazioni. È statomembro di diversi Comitati Tecnici nazionalicollaborando alle attività internazionali del settorefino al 1989. Ha curato, dal 1990 nell’Ingegneria

dei Sistemi di Gestione, la definizione e la gestione dei Piani e deiProgrammi, la Pianificazione e Progettazione impiantistica dei CentriTerritoriali e la gestione degli ambienti di test e collaudo delle diversetipologie dei Sistemi. Dal 1997 opera in Pianificazione Rete curando,prima al Piano Strategico e poi alle Strategie, le valutazioni economicofinanziarie delle iniziative strategiche, dell’introduzione della tecnologiaADSL e dei Progetti di Work Force e di Trouble&Job Management e ladef iniz ione del Piano Economico del la Rete. Attualmente al laPianificazione tecnica e Architetture, si occupa anche della valutazionedei Piani e dei Progetti Industriali di ottimizzazione delle risorse e dellaevoluzione Architetturale dei Sistemi di Gestione della Rete.

Vincenzo Asaro si è laureato in IngegneriaElettronica presso l’Università di Palermo nel 1993.Dal 1996 opera in Telecom Italia, nella DirezioneRete. Dopo una breve esperienza nell’ambitodell’esercizio della rete IP infrastrutturale dei sistemidi gest ione (Dacon), s i è occupato del laprogettazione e industrializzazione del backbonedella Dacon e delle reti locali dei centri operativi.Dal 2000 al 2002 ha seguito lo sviluppo delsistema di accounting della rete [email protected] e del

datawarehouse dei dati di accounting della Rete (Ulisse). Dal 2001 sioccupa della progettazione e industrializzazione della componente diNetwork Assurance (sistemi di performance e di fault management) dellaNuova Piattaforma di Gestione integrata per le reti dati pubbliche, inoutsourcing ed Intranet. Dal 2003 ricopre l’incarico di Program Managerper le soluzioni di Network Assurance delle reti di Telecom Italia.

Dino Galuppi si è laureato in Sociologiadelle Comunicazioni di massa presso l’Universita’“La Sapienza” di Roma nel 1997. È entrato inTelecom Italia nel 1991, dove ha operato semprenel CNA occupandosi inizialmente della gestionepersonal izzata del le ret i dat i internazional i ,nazionali, e di testate giornalistiche. Dopo unaesperienza nella fonia, gestendo il delivery deiservizi di rete Intelligente, nel 1998 si è occupatodel la gest ione dei contratt i dei Cl ient i in

outsourcing come Service Manager. Dal 2001 è nell’ambito delConsulting di Enteprise Solution, operando principalmente nell’analisidei processi interni e nella definizione dei costi e della fattibilità tecnicadei progetti personalizzati.

Giuseppe Prisco si è laureato in Scienzedel l ' In formaz ione ne l 1987, è ne l GruppoTelecom Italia dal 1990. Dopo una esperienza didue anni in Alenia. Ha fatto parte di Telesoft e poidi IT Telecom, per confluire infine in OSS.NM. Èstato responsabile di alcuni progetti nell'ambitodella manutenzione proattiva degli apparati dicomunicazione e del TTM per i servizi dati. Dal2002 si occupa di Network Mana-gement, inpar t ico lare de l la gest ione de i serv iz i d i

outsourcing reti dati per i clienti Executive.

CIC Cisco Information CenterCOS Collection Object Server DACON DAta COmmunication NetworkEM Element ManagerINDB Integrated Network Data BaseLIDO Livello Integrato Dati OperazionaliMPLS Multi Protocol Label SwitchingNExT Network Explorer ToolNH NetHealthNNM Network Node ManagerNTT Network Trouble TicketPDH Plesiocronus Digital HierarchyPoP Point of PresencePOS Presentation Object ServerROS Routing Object ServerSA Service AssuranceSDH Syncronous Digital HierarchySEC Simple Event CorrelatorSFM Surveillance and Fault ManagementSGSDH-NM Sistema di Gestione SDH - Network ManagerSLA Service Level AgreementTHOR Topologic Hierarchic Object RetrieverTNT Topology Network ToolkitTT Trouble TicketTTM Trouble Ticket ManagerUNICA Unique Network Inventory Cooperating

Automatisms /D=Dati T=TrasmissioneVAS Value Added Services


Tecnologie innovative per ilrilevamento e il contrasto degli

attacchi informatici

GERARDO LAMASTRA

LUCA VIALE

Il costante aumento della complessità delle reti, dei sistemi e dei servizi richie-de l’adozione di approcci innovativi al rilevamento e alla scoperta degli attac-chi informatici. I sistemi di rilevamento, sia quelli mirati alla protezione delbackbone, sia quelli mirati alla protezione della Intranet e degli utenti, sonouna componente fondamentale di una moderna infrastruttura di sicurezza.L’articolo descrive e analizza lo stato dell’arte in questo settore, con partico-lare attenzione agli aspetti emersi nel campo della ricerca e illustra i risultatidelle attività di studio e innovazione condotte in Telecom Italia Lab.

1. Introduzione

I sistemi di rilevazione e prevenzione delle intru-sioni (IDS - Intrusion Detection System) sono dive-nuti, negli ultimi venti anni, uno degli elementi fon-damentali dell’architettura di sicurezza di una reteinformatica. Un sistema di Intrusion Detection è l’a-nalogo informatico del sistema di allarme che pro-tegge un’abitazione o una banca. Come un vero eproprio sistema di allarme, un IDS è caratterizzatodai seguenti elementi:• sensori, per il rilevamento degli eventi indeside-

rati o delle condizioni anomale nell’ambientemonitorato;

• sistema di raccolta e di correlazione delle infor-mazioni fornite dai sensori, in grado di deciderese è effettivamente il caso di emettere unasegnalazione;

• meccanismo di segnalazione, tipicamente multi-modale (per esempio la sirena ed un avvisoinviato direttamente alle forze dell’ordine).

Anche i sistemi di Intrusion Detection sonocaratterizzati fondamentalmente dalle stessecomponenti; inoltre, proprio come i sistemi diallarme tradizionali, i sistemi IDS, essendo deisistemi automatici, possono essere aggirati, spe-cie se si ha una conoscenza molto approfonditadi come sono dislocati e configurati.

L’obiettivo di questo articolo è quello di pre-sentare la tematica attraverso un’analisi detta-gliata dello stato dell’arte, illustrando quindi irisultati ottenuti nell’ambito dell’attività di ricercasvolta presso il laboratorio Be-Secure di TelecomItalia Lab.

2. L’evoluzione dei sistemi di Intrusion Detection

Il 1987 si può considerare, a tutti gli effetti,come l’anno in cui si inizia pubblicamente a parlaredelle tecnologie di rilevazione delle intrusioni; inparticolare, Il lavoro di D. Denning [1] si può consi-

SICUREZZA

LAMASTRA › VIALE • Tecnologie innovative per il rilevamento e il contrasto degli attacchi informatici


derare l’articolo scientifico di riferimento su questoimportantissimo tema. Oggi, esistono numerosisistemi commerciali di Intrusion Detection e variprogetti portati avanti dalla comunità Open Source,tuttavia i problemi da risolvere sono ancora molti ele opportunità di ricerca sono ancora significative.

Dal momento che gl i IDS nascono come“sistemi di protezione” per una infrastruttura limi-tata, è naturale che il loro ambito tradizionale siaquello del data center o della Intranet aziendale. Losviluppo recente delle reti informatiche, caratteriz-zato da un aumento pressoché esponenziale dellabanda disponibile, dall’aumento della connettivitàdi tipo always on (disponibile anche per l’utenzacasalinga e SOHO) e dall’aumento della mobilità,grazie all’uso delle tecnologie cellulari di nuovagenerazione e wireless, comporta un sempre mag-giore allargamento dei confini da proteggere. L’IDSdiviene dunque un componente strategico, chedeve operare su diversi livelli, partendo da quellodell’utente inesperto, passando per l’utenza large-business di tipo tradizionale, fino ad arrivare acoinvolgere direttamente il gestore dell’infrastrut-tura, e dunque i grossi operatori nazionali di tele-comunicazioni.

I sistemi di rilevazione delle Intrusioni nasconoin un ambito prevalentemente militare, sebbenesiano strettamente correlati all’attività di alcuniricercatori universitari operanti nell’ambito dellasicurezza delle informazioni. Nel 1980, l’articolo diJ. Anderson [2] introduce il problema del monito-raggio dei sistemi informativi, in particolare di quelliutilizzati per operazioni di tipo militare; poco dopo,D. Denning inizia a lavorare sui sistemi di rileva-zione delle intrusioni, anche grazie alla sponsoriz-zazione offerta da varie entità governative. Alla finedegli anni Ottanta, molte strutture universitariehanno un progetto incentrato sul tema della rileva-zione del le intrusioni ; pensiamo al progettoHaystack dell’Università di Davis in California [3],ad IDES del Computer Science Laboratory dell’SRI[4], ed al progetto IDIOT [5] del CERIAS dell’univer-sità di Purdue.

All’inizio degli anni Novanta, la rete Internetesce dal contesto puramente accademico/militaree si avvia a diventare la più grande infrastrutturainformatica del pianeta; all’inizio, come spessoaccade, le problematiche di sicurezza passano insecondo piano rispetto a quelle dell’usabilità.Inoltre, la maggior parte degli attacchi sono appan-naggio di una elite esclusiva e non ancora alla por-tata di tutti. Si ritiene che il livello di sicurezzaofferto da un firewall sia tutto ciò che serve perproteggere la propria infrastruttura. Nel frattempo,seguendo un trend abbastanza tipico (almeno negliUSA), alcuni gruppi di ricerca che hanno prodotto iprototipi più interessanti di sistemi per la rileva-zione delle intrusioni, iniziano ad evolversi insocietà start up. È il caso di Haystack Labs, checommercial izza l ’omonimo prodotto, di NFR(Network Flight Recorder, tuttora presente sul mer-cato), o di Network ICE, fondata da R. Graham(oggi leader dell’area R&D di Internet SecurityServices, ISS). Allo stesso tempo, gli attacchi

divengono più difficili da rilevare, più facili daorchestrare e sempre più alla portata di tutti.Diventa sempre più evidente che non si può otte-nere la sicurezza usando un solo dispositivo e,quindi, gli IDS iniziano ad diventare elementi sem-pre più essenziali di una infrastruttura di protezioneche ha il suo paradigma nella cosiddetta “Defensein Depth” [6].

Contestualmente, anche la tecnologia IDS iniziaa svilupparsi seguendo altre strade: appaiono iprimi sistemi che integrano il firewall e l’IDS; lalinea di demarcazione che separa i sistemi di rile-vazione da quelli di contromisura diventa più sot-tile, così da una parte i firewall iniziano ad integraremeccanismi di ispezione del traffico sempre piùsofisticati mentre gli IDS imparano a risponderedirettamente agli attacchi rilevati, trasformandosiappunto in sistemi di prevenzione.

L’apparizione dei primi attacchi di tipo distri-buito ed i drammatici effetti del numero crescentedi worm che si propagano sulla rete, fanno presa-gire le possibilità di un enorme black out informa-tico. Appaiono così i primi sistemi pensati esplici-tamente per la protezione dell’infrastruttura, come irouter ed altri sistemi di interconnessione. Leaziende più importanti nel contesto informatico,quali Cisco, Symantec, Internet Security Systemsinvestono cifre considerevoli per acquisire la tec-nologia di varie start up, allo scopo di offrire nellapropria offerta di sicurezza anche un sistema dirilevazione delle intrusioni.

Gli anni successivi al 2000 sono caratterizzatida una relativa stasi, almeno nel settore dellaricerca e sviluppo; la tecnologia dominante è rap-presentata dai sistemi di Network-IDS, che ope-rano analizzando in maniera estremamente ottimiz-zata i flussi di pacchetti che attraversano i perime-tri aziendali. L’attenzione dei produttori si spostasulle problematiche di gestione, incentrate sullanecessità di ridurre l’enorme mole di dati generatada questi sistemi. Iniziano anche a diffondersi deidubbi sulla validità effettiva di questo tipo di tecno-logie [7]; molte aziende comprano le sonde e leinstallano, ma l’investimento necessario per man-tenere un proprio gruppo interno che si occupi delmonitoraggio risulta proibitivo; spesso i costi perun servizio di sicurezza gestito sono insostenibili, ameno di non possedere una propria tecnologia diIDS ed un proprio team per la messa a punto degliaggiornamenti necessari al sistema per ricono-scere nuovi attacchi.

Oggi, la tendenza prevalente dei produttori èquella di proporre soluzioni di tipo All in One, cheintegrino su una singola appliance, firewall, IDS edantivirus; questo tipo di meccanismi sposta il bari-centro della tecnologia dai sistemi puramente pas-sivi verso tecnologie di prevenzione IPS (IntrusionPrevention System). Gli IPS, a differenza dei sen-sori che operano in modo passivo, divengono ele-menti attivi dell’infrastruttura, agendo direttamenteai livelli 2 e 3 della pila protocollare, ed interve-nendo direttamente sul transito dei pacchetti, conun livello di analisi notevolmente più complessorispetto a quello dei firewall tradizionali. La loro



adozione è comunque contrastata dagli effetti col-laterali connessi alla loro elevata complessità(dovuta in moltissimi casi alla necessità di mante-nere lo stato della sessione e di utilizzare algoritmipiù complicati rispetto a quelli tradizionalmenteimpiegati in firewall ed antivirus) che potrebberitorcersi contro l’infrastruttura stessa. Se infatti undispositivo di questo tipo dovesse per qualchemotivo diventare non operativo, l’intera sottoreteprotetta rischierebbe di essere tagliata fuori.

Anche le tecnologie non strettamente basatesull’approccio di tipo network based vivono unafase difficile; strette infatti tra la morsa dei sistemiantivirus e dei sempre più diffusi personal firewall, isistemi IDS di tipo host based stentano a diffon-dersi seriamente; la tendenza prevalente è quelladell’approccio integrato firewall e IDS, specie nel-l’ambito workstation, dove è possibile sfruttare effi-cacemente il feedback diretto dell’utente. Moltiamministratori di sistema continuano a non vederedi buon occhio l’installazione di un sistema IDShost based, a causa del potenziale overhead com-putazionale che graverebbe sul sistema.

D’altra parte, i grossi gestori di infrastrutture,hanno una necessità sempre maggiore di dotarsi disistemi specifici per proteggere le loro risorse tec-nologiche; gli strumenti standard per la rilevazionedelle intrusioni male si adattano a questo compito,in particolare in previsione della trasformazionedella rete telefonica tradizionale in una rete basatasul protocollo IP. Uno degli aspetti più critici dalpunto di vista del gestore di rete è rappresentatodalle problematiche correlate ai protocolli di rou-ting. Sebbene alcuni protocolli integrino alcunecaratteristiche di sicurezza (come la possibilità diautenticare in modo forte le transazioni fra i router)o esistano delle soluzioni specifiche a livello deisingoli apparati (come la possibilità di eseguire unfiltraggio sofisticato dei pacchetti), la maggiorparte degli amministratori di rete tende a non utiliz-zare questi meccanismi. I motivi sono molteplici:spesso l’overhead computazionale è elevato (edunque si riduce la banda gestita dall’apparato),oppure possono crearsi dei problemi di interopera-bilità tra le soluzioni di differenti produttori oancora perché, come accade nei peer BGP, l’abili-tazione e la configurazione delle funzionalità disicurezza richiede spesso la collaborazione di dif-ferenti operatori.

L’attività svolta a partire dal 2003 nel gruppo disicurezza informatica di Telecom Italia Lab (Be-Secure) si concentra in particolare su due aspetti:• L’evidenza che i sistemi tradizionali di IDS non

risultano sempre adeguati rispetto alle esigenzedell’operatore di telecomunicazioni; infatti, que-sti sistemi sono tipicamente pensati per ambitidi tipo Intranet/Corporate. L’infrastruttura di retedi un grosso gestore di telecomunicazionirichiede invece una grande flessibilità dovendogestire una molteplicità di tipologie di rete, apartire dall’utenza domestica sotto forma diADSL, fino alle offerte per aziende con partico-lari requisiti di sicurezza, quali banche o sanità.Oltre alla rete in senso classico, esiste poi la

dorsale di trasporto (backbone), che ha ovvia-mente delle caratteristiche e delle peculiaritàcompletamente differenti rispetto alle reti con-venzionali; l’utilizzo di una soluzione standard èquindi di difficile applicabilità.

• La constatazione che il controllo dei costi asso-ciati all’IDS è abbastanza problematico; al di làdei costi iniziali delle sonde, gli IDS sono deisistemi che richiedono un continuo aggiorna-mento. Se si guarda il recente trend sul numeromedio di vulnerabilità nuove riscontrate perogni anno [8], si nota chiaramente un anda-mento abbastanza i l l inea con la legge diMoore, la stessa legge che caratterizza in gene-rale la diffusione di tutto ciò che è computingtechnology. In più, oltre ai costi dovuti all’ag-giornamento, è essenziale tener conto anchedei costi di funzionamento, tutt’altro che affida-bile, dei sistemi di rilevazione. È ben noto che ilnumero di falsi allarmi generati dai sensori puòdiventare elevatissimo, soprattutto in ambientiestremamente eterogenei o laddove sia difficileoperare una configurazione molto fine del sen-sore. Ogni falso allarme genera un costo dovutoalla necessità di gestire, seppure in minimaparte, l’evento ma ha un effetto molto più nega-tivo e meno misurabile, correlato alla tendenzada parte di chi esegue il monitoraggio, di consi-derare tutti gli eventi come falsi allarmi; e così,paradossalmente, un sensore IDS finisce peressere utilizzato spesso come uno strumentoper l’analisi a posteriori di un evento pericolosoverificatosi sulla rete piuttosto che come ilprimo campanello di allarme per rendersi contoche sta accadendo qualcosa di negativo.L’obiettivo dell’attività di ricerca svolta presso

Telecom Italia Lab nell’ultimo biennio è stato per-tanto quello di ideare, ove possibile, una serie disoluzioni tecnologiche focalizzate sulla rilevazionedelle intrusioni nei diversi domini concettuali: alivello del singolo sistema (host), a livello delle reti(wired e wireless), per arrivare fino al livello deisistemi di infrastruttura. L’attività di ricerca è statadistribuita su tre progetti (EAGLE - InnovativeIntrusion Detection; RDS - Routing DetectionSecurity; WIDS - Wireless Intrusion DetectionSystem); sono stati ottenuti numerosi risultati inte-ressanti, sia per ciò che riguarda gli aspetti innova-tivi (che ha dato luogo a numerose domande dibrevetto), sia per ciò che riguarda la prototipazionedei sistemi (che ha visto la realizzazione di sistemirealmente funzionanti , sia in laboratorio, siadurante specifici test in campo).

3. Stato dell’arte e ricerca scientifica

I sistemi di Intrusion Detection non sono piùuna tecnologia innovativa; anzi, da un certo puntodi vista, si possono considerare relativamentematuri dal momento che da diversi anni numerosiproduttori offrono delle soluzioni commerciali.Tuttavia, gli IDS richiedono una competenza sensi-bilmente superiore da parte del personale di



gestione rispetto ad altri apparati di sicurezza euna messa a punto non ottimale può generarefacilmente un numero elevato di eventi inutili. Unavalutazione scorretta delle performance effettiva-mente necessarie potrebbe rendere il sistema inca-pace di rispondere in maniera adeguata. Inoltre,molto spesso è difficile capire cosa esattamente èaccaduto su un sistema attaccato, partendo dalleindicazioni fornite dall’IDS.

Tutte queste problematiche d’uso hanno unnotevole impatto pratico, oltre che economico, cheè fortemente amplificato nel contesto di grandiinstallazioni. È importante capire come valutare inmaniera appropriata almeno gli aspetti essenzialiche caratterizzano un IDS, sia per eseguire unascelta corretta sulla tecnologia da impiegare, siaper valutare fino in fondo quali sono i vantaggi cheun certo meccanismo può effettivamente fornire.Le metriche più importanti per valutare un IDSsono tre:1) Numero di “Falsi Positivi” (#FP): un falso posi-

tivo è un evento che l’IDS ritiene significativo eche invece non ha alcun effetto reale sulsistema. Potrebbe ad esempio derivare dall’i-dentificazione di un tentativo di attacco versouna macchina che non è vulnerabile, dal fattoche il pacchetto pericoloso potrebbe, per qual-che altro motivo, non raggiungere mai il sistemabersaglio, o più semplicemente da un vero eproprio errore di rilevazione;

2) Numero di “Falsi Negativi” (#FN): un falso nega-tivo è un evento dannoso che il sistema non rie-sce ad identificare. Ciò solitamente accade per-ché viene utilizzato un attacco che il sistemanon conosce, oppure perché l’attacco vieneoffuscato o mascherato in qualche modo; comevedremo, la frammentazione è uno dei meccani-smi “classici” per aggirare un IDS.

3) Capacità di carico: a differenza dei due fattoriindicati in precedenza, correlati prevalente-mente al l ’eff icacia di funzionamento delsistema, la capacità di carico è unamisura dell’efficienza; in pratica, è unavalutazione del massimo carico che ilsistema può sostenere mantenendo lacapacità di eseguire l’analisi. Nel con-testo dei sistemi network, si puòmisurare sia in termini di byte/s, sia intermini di pacchetti/s; di solito, èimportante poter disporre di entrambii valori per avere una valutazionecompleta del sistema. Nel contestodei sistemi host-based, si misuranotipicamente le risorse sottratte alsistema ospite; è evidente che un IDShost-based che sottrae più del 50%delle risorse di calcolo e/o memoriadisponibili al sistema ospite ha dellepessime performance.Ovviamente, in un ambito

strategico/commerciale, la metrica corre-lata ai costi è importante quanto quella ditipo più squisitamente tecnologico; seb-bene questo articolo non entri nel merito

della questione, è bene osservare che il costoassociato ad un IDS può essere considerato comela somma di quattro contributi sostanziali: costodell’hardware necessario, costo delle l icenzesoftware, costo degli aggiornamenti e costo asso-ciato alla gestione del sistema (in altre parole, ilcosto dovuto al fatto che il sistema va comunquemonitorato da personale specializzato).

Dal punto di vista scientifico, trattandosi di unatecnologia non recentissima, è opportuno basarsisu un approccio tassonomico per descriveremeglio tutti gli aspetti significativi relativi ad unsistema di IDS. Come vedremo, la classificazioneadottata risente notevolmente del fatto che, stori-camente, i primi IDS sono stati sistemi di tiponetwork based; tuttavia, la classificazione è suffi-cientemente generale da adattarsi anche ai sistemidi tipo host ed a quelli pensati specificatamenteper la protezione delle infrastrutture.

La classificazione a cui facciamo riferimento èquella del CIDF (Common Intrusion DetectionFramework) [9]; questo risultato è uno dei frutti del-l ’att iv i tà in iz iata da T. Lunt a l l ’ InformationTechnology Office della DARPA e sviluppatasi poicome sforzo mirante a definire una sorta di archi-tettura standard per l’interoperabilità degli IDS.

In accordo a questa classificazione, un IDS ècomposto da 4 elementi essenziali, come illustratoin figura 1:• E-Box: si occupa di raccogliere gli eventi rile-

vanti dal sistema sotto analisi; questo elementoè il sensore vero e proprio e si interfaccia con ilsistema in maniera solitamente passiva per cat-turare tutte le informazioni significative per l’a-nalisi;

• A-Box: è il cuore del sistema, che effettua l’ana-lisi e stabilisce se effettivamente l’evento è unattacco o meno;

• D-Box: è il sistema di memorizzazione, che hal’obiettivo di mantener traccia di ciò che èaccaduto;

Generatore dicontromisure

Interprete di eventi

Flusso dati

Memorizzazioneeventi

Reazione(R-box)

Memorizzazione(D-box)

Eventi(E-box)

Analisi(A-box)

Fonte: GDF

FIGURA 1› Architettura generica di un sistema di IDS.



• R-Box: è il sistema di reazione, che può limitarsiad emettere un allarme per il personale di moni-toraggio, oppure eseguire automaticamente unacontromisura appropriata per l’attacco identifi-cato.In base a questo schema, è possibile classifi-

care un IDS in base ai quattro meccanismi essen-ziali, correlati appunto alle “Box” che compongonolo schema. Ad esempio, il meccanismo di raccoltadegli eventi (la E-Box) può essere tipicamente larete, i l s ingolo host, un s istema ibr ido(host/network) o una componente rappresentata daun dispositivo specifico.

Ovviamente, per ciò che riguarda le metodolo-gie di analisi, esiste la più ampia diversificazione,sebbene si possano individuare due grandi para-digmi: “Misuse Detection” e “Anomaly Detection”,che sono descritti in dettaglio nel riquadro diapprofondimento “Misure Detection & AnomalyDetection”. Nelle fasi iniziali della ricerca, sonosort i svariat i progett i universitar i che hannoapprofondito l’utilizzo di una particolare tecnicaalgoritmica; abbiamo così IDS che lavorano con ilc lassico meccanismo del pattern matching,oppure sistemi che lavorano utilizzando algoritmidi tipo rete neurale, sistema esperto, genetico estatistico.

I meccanismi di reazione possono essereessenzialmente di due tipi: passivi, che si limitanoad inoltrare un avviso al personale che si occupadella gestione, o attivi che invece eseguono auto-nomamente una qualche contromisura. Sebbenel’adozione dei meccanismi di reazione attivi abbiaportato allo sviluppo dei cosiddetti sistemi di pre-venzione delle intrusioni (IPS), non bisogna dimen-

ticare che un sistema di questo genere rischia ditrasformarsi in un’arma a doppio taglio, nel caso incui le contromisure scattino a fronte di un falsopositivo che è invece associato ad un pacchettoperfettamente lecito che somiglia apparentementead un pacchetto pericoloso.

Per ciò che riguarda il supporto di memorizza-zione, in generale si possono avere sia sistemi cheutilizzano un’infrastruttura classica basata su undata base relazionale, sia sistemi più sofisticati,spesso poi evolutisi come prodotti indipendenti,che sono utilizzati come veri e propri sistemi diraccolta e correlazione. Questo genere di sistemiaggregano eventi provenienti da un numero estre-mamente elevato di sorgenti, spesso molto diversel’una dall’altra. Gli eventi sono prima trasformati inuna rappresentazione “normalizzata” e, quindi,sono confrontati con una serie di regole, spessoscritte in qualche linguaggio di specifica più omeno formale, per evidenziare macro-anomalie,comportamenti irregolari o, in generale, qualsiasievento di interesse che possa essere descrittosfruttando il linguaggio fornito.

L’approccio senza dubbio più diffuso nell’am-bito dei sistemi IDS è rappresentato dall’uso disistemi di tipo network con una logica basata sulpattern matching. Questo approccio caratterizzaquasi tutte le soluzioni commerciali più diffuse( ISS Network Sensor, SourceFire, EnterasysDragon) e molti sistemi open source sia nuovi(Snort [11]) che vecchi (Shadow [12], NID [13],IDIOT [5]). Nel caso specifico, parlando di patternmatching (si veda il riquadro “Modelli formali peril problema del Pattern Matching”), si intende unatecnica di individuazione di una o più sequenze

MISUSE DETECTION &ANOMALY DETECTION

Con la definizione di “MisuseDetection” si intende la tecnica dirilevamento delle intrusioni volta amodellare il comportamento impro-prio o illecito del sistema [10] attra-verso la definizione di uno o piùschemi o pattern. Un pattern rappre-senta, quindi, una classificazione del-l’attacco in termini di informazioni apriori che permettono di individuare eclassificare ciò che è “malevolo”. Latecnica specifica più comune nell’am-bito dei sistemi di tipo network è ilpattern matching, che è in un certosenso il sistema di Misuse Detectionper eccellenza. Altri approcci basatisul paradigma Misuse Detection

includono l’uso dei sistemi esperti edei sistemi basati su modelli formali esemi-formali che cercano di ricono-scere l’insieme di transizioni eseguitoda un sistema per arrivare alla condi-zione di bersaglio.Il paradigma “Anomaly Detection” sibasa, invece, su di un principio dualerispetto a quello descritto in prece-denza: l'IDS non cerca di individuaregli schemi di attacchi ben noti, maeventuali anomalie nel comporta-mento dell'oggetto monitorato (rete,host, applicativo, … .) . Di conse-guenza, la costruzione di un rilevatoredi questo tipo inizia con un'accuratadefinizione del modello normale dicomportamento del sistema da moni-torare. In seguito vengono definite leregole che governano il rilevamentovero e proprio: fondamentalmente,per ciascuna variabile del modelloviene indicato l’intervallo di variazione(spesso definito deviazione) che rap-presenta la soglia tra una situazione

normale ed una che non lo è. I sistemidi tipo Anomaly Detection non hannobisogno della descrizione di ogni sin-golo attacco ed in più possono indivi-duare potenzialmente molti più attac-chi al sistema monitorato, siano essinoti o meno. Ovviamente tale capacitàrappresenta un vantaggio rispetto aisistemi di Misuse Detection , chenecessitano di aggiornamenti continuidel database contenente la descri-zione degli attacchi. Lo svantaggioprincipale del sistema è rappresen-tato dalla notevole difficoltà della suamessa a punto. Infatti, questi tipi disistemi reagiscono tipicamente aqualsiasi cosa che non sia stata mar-cata come ammissibile e dunque pro-ducono molti più falsi positivi rispettoai sistemi di tipo Misuse. Inoltre, unulteriore problema può essere ancherappresentato dalla minore possibilitàdi fornire informazioni precise sul tipodi attacco corrispondente ad un'ano-malia rilevata.



ben specif icate e contigue di s imbol i , dettesignature, all’interno di un flusso continuo di sim-boli. Tipicamente, nella stragrande maggioranzadei casi, i simboli sono essenzialmente byte, mapossono anche essere caratteri unicode, word a32 bit o altro.

Esistono diversi modelli formali per inqua-drare il problema del pattern matching; in pra-tica, nella stragrande maggioranza dei casi ven-gono utilizzate le espressioni regolari per la loroimmediatezza d’uso ed anche perché esistonoottimi algoritmi applicabili al caso in cui si vogliaeseguire una ricerca simultanea di numerosesignature su un singolo flusso di dati. Oltre tutto,non bisogna dimenticarsi che, oltre a disporre diun buon sistema per l ’anal isi del le regole, èaltresì necessario riuscire a codificare i tratticaratteristici di un attacco in una signature spe-cifica. Pertanto, l’uso di un approccio più sem-plice (anche se meno potente) è probabilmentepreferibile, vista la rapidità con cui è necessarioscrivere una signature dopo che l’attacco vienereso noto.

Negli ultimi anni lo sforzo di sviluppo degli IDStradizionali in ambito open source si è concen-trato attorno al progetto Snort [11] di M. Roesch,che è rapidamente diventato uno degli strumentidi riferimento di tutta la comunità della ICT secu-rity. Come molti progetti open source di suc-cesso, Snort ha generato una community moltoatt iva che continua lo svi luppo del s istema.Inoltre, la possibilità di disporre di un sistema

aperto, consente di provare in maniera moltorapida l’efficacia di un nuovo algoritmo o di unmeccanismo di analisi differente da quello usuale,permettendo di confrontare in maniera immediatae trasparente l’effetto in termini di efficacia edefficienza.

Uno dei r isu l tat i p iù in teressant i emers idurante l’evoluzione del progetto è l’ottimizza-zione dell’algoritmo di pattern matching nel con-testo specifico degli IDS. Le prime implementa-zioni del motore di pattern matching sono basatesull’algoritmo di Boyer-Moore [15]; questo algo-ritmo è sostanzialmente un algoritmo euristicoche nella maggioranza dei casi è computazional-mente più eff iciente del l ’algoritmo ott imo. I lnumero crescente di signature ha di recente con-dotto all’adozione dell’algoritmo di Aho-Corasic[16] che è pensato per l’analisi simultanea dinumerose signature in un colpo solo.

L’approccio basato sull’utilizzo di modelli for-mali (descritti sia per mezzo di regole, sia permezzo di modelli basati sulle transizioni di stato) èstato caratterizzato da un discreto successo inambito accademico, ma si è poi scontrato con ladifficoltà pratica di codificare gli attacchi permezzo degli strumenti forniti. In particolare, STAT[17,18] dell’Università della California di S. Barbaraè uno degli esempi più interessanti: si sfrutta unadescrizione astratta del sistema in termini dimodello ridotto dello stato e si cercano di model-lare gli attacchi al sistema come insiemi di transi-zioni su tale modello.

Modelli formali per ilproblema del

PATTERN MATCHING

Il problema del pattern matching [14].è uno dei grandi problemi classici del-l’informatica teorica. La letteraturadisponibile è davvero moltissima, cosìcome gli ambiti applicativi; in partico-lare nel contesto della sicurezza deisistemi informativi, pensiamo agli IDSed agli antivirus; fra gli altri campiapplicativi, citiamo invece quello del-l’analisi delle sequenze di geni, che direcente ha creato un rinnovato inte-resse in questo particolare ambito diricerca.Di seguito descriviamo brevemente iquattro approcci che consideriamorappresentativi per ciò che riguarda ilproblema del pattern matching:• Regular Expression (RE): questa

classe di algoritmi ricerca sul

flusso di byte in input le cosid-dette “espressioni regolari”. È unaricerca di pattern di tipo linearecon una semantica ben nota (leRE sono ampiamente utilizzate inmoltissimi contesti applicativi del-l’informatica); il vantaggio princi-pale sta nella relativa semplicitàcon cui è possibile scrivere leregole.

• Deterministic Context FreeGrammars (CFG): gli algoritmi cheappartengono a questa categoriasono caratterizzati da una gram-matica costituita da simboli sem-plici (cioè che possono assumereun unico valore deterministico) acui vengono applicate regolesemantiche. L’output è un alberosimile ad un parse-tree costruitodal parser di un compilatore cherappresenta una signature.

• Attribute Grammars: gli algoritmiche appartengono a questa cate-goria offrono un potente meccani-smo di rappresentazione dellesignature con lo svantaggio chenon forniscono un modello grafico

facilmente interpretabile. UnaAttribute Grammar può esserevista come una CFG in cui i sim-boli possono assumere più valori,chiamati per l’appunto “attributi”.L’individuazione di un attributoper un simbolo è legato all’azioneche determina l’elezione di quelsimbolo. Quindi, ad ogni passodell ’algoritmo di pattern mat-ching, un simbolo è caratterizzatodalla coppia (azione, attributo).

• Colored Petri Nets: le Reti di Petrisono uno dei modelli formali piùnoti nel contesto dell’informaticateorica. Tipicamente, vengonousate per modellare problemi diconcorrenza e per il riconosci-mento di specifiche sequenze dieventi. Gli algoritmi che rientranoin questa categoria permettonouna rappresentazione delle signa-ture in termini di grafi con la pos-sibilità di inserimento di informa-zioni legate alla semantica di unattacco; la loro potenza espres-siva è molto simile a quella delleAttribute Grammar.



Sebbene l’approccio basato sul paradigma del“Misuse Detection” risulti prevalente, esistonocomunque dei sistemi implementati con la logicadell’Anomaly Detection che vale la pena di citare.Andare alla ricerca di anomalie sul sistema monito-rato richiede di misurare una variazione di qualcheproprietà dell’oggetto in esame. Bisogna cioèavere una indicazione misurabile di ciò che siintende per “comportamento ammissibile” ed unasoglia al di là della quale è lecito segnalare un“comportamento sospetto”. Gli approcci si pos-sono sostanzialmente ricondurre a due filoni princi-pali: Characteristic Deviation e Statistical Deviation.Una deviazione caratteristica offre una misura qua-litativa (ad esempio, “normalmente l'utente rootnon utilizza il servizio ftp”), mentre una deviazionistatistica è una misura quantitativa osservabile (adesempio, “il traffico icmp della rete monitorata nonsupera normalmente il 15% del traffico totale”).

Per quanto riguarda la natura delle informazioninecessarie per effettuare le misure, i sistemi di tipoAnomaly Detection si possono così classificare:• Behavioral Based: si tratta di sistemi che misu-

rano deviazioni di tipo caratteristico (eventual-mente integrandole con alcune misure statisti-che); tali sistemi si basano sulla creazione di unprofilo che caratterizza il comportamento nor-male dell'oggetto monitorato. Normalmente,questi sistemi lavorano in due distinte modalità;all’inizio, durante la fase di addestramento (trai-ning), il sistema campiona l’oggetto monitoratoper definire il comportamento ammissibile; èessenziale che il sistema in questa fase vengaprotetto da qualsiasi attacco; in una secondafase, il sistema sfrutta ciò che ha appreso (edeventualmente rimaneggiato in modo oppor-tuno) per identificare gli scostamenti dallanorma. La tecnologia soggiacente a tali sistemiè tipicamente basata su reti neurali, sistemifuzzy o emulazione del sistema immunitario.

• Traffic Pattern: si tratta di sistemi molto tipicinell’ambito network/infrastruttura; lavorano pre-valentemente sfruttando modelli di tipo stati-stico, valutando la distribuzione temporale espaziale del traffico, estrapolandone le caratte-ristiche significative (es. numero di connessioniper unità di tempo, numero di pacchetti scam-biati, ... .); questo tipo di sistemi trova un suoambito applicativo naturale nel rilevare gli attac-chi di t ipo DDoS (Distr ibuted Denial ofServices), che mirano ad esaurire le risorsedisponibili convogliando in modo ben coordi-nato un enorme numero di richieste verso ilsistema da attaccare. Solitamente, i profili ditraffico durante queste condizioni particolari dif-feriscono sensibilmente dalla situazione stan-dard; pertanto è possibile identificare il compor-tamento anomalo fin dai primissimi istanti.Il paradigma della cosiddetta “Immunologia

Computazionale” è uno degli approcci che hariscosso il maggiore successo nell’ambito dellar icerca sugl i IDS di t ipo Anomaly Detection.L’ispirazione è chiaramente di matrice biologica; èinfatti ben noto che i sistemi biologici sono in

grado di riconoscere una miriade di attacchi, anchestrutturalmente molto differenti, e di mettere inpiedi una adeguata risposta proprio per mezzo delsistema immunitario. Ovviamente, il reale funziona-mento del sistema immunitario di un organismosuperiore è estremamente complesso, essendo ingrado di riconoscere un “attacco” già noto (neiconfronti del quale la reazione è mirata e solita-mente efficace), oppure di identificare attacchisconosciuti, proprio in base ad un meccanismoche è effettivamente simile, a livello di paradigma,all’Anomaly Detection. L'idea di applicare i principiche governano il funzionamento dei sistemi immu-nitari naturali alla protezione dei sistemi di calcolo,è stata esposta nel 1994 dal gruppo di ricerca di S.Forrest dell'Università di New Mexico [19,20].L'obiettivo del progetto è quello di costruire unsistema immunitario artificiale per i computer [21].Gli IDS realizzati nell'ambito del progetto copronopraticamente tutti i contesti applicativi tradizionali:Application based, User based, Host based eNetwork based. Il principio comune implementatoda tali sistemi è definito “Negative Selection”, unalgoritmo che realizza appunto la distinzione tra ciòche è legittimo (siano essi utenti, azioni sul sistemaoperativo, connessioni di rete) e ciò che non lo è.

L’approccio basato sull’Anomaly Detection ditipo “Traffic Pattern” è dominante nel contestodella sicurezza backbone. In questo settore laricerca è molto meno matura rispetto al contestopiù tipico dell’Intrusion Detection ed i problemi chesono stati approfonditi sono fondamentalmentedue: da una parte il tentativo di individuare e bloc-care i DDoS che viene affrontato prevalentementecon tecniche di tipo statistico; dall’altra abbiamol’analisi focalizzata sui protocolli di routing. I proto-colli di routing, avendo la funzione di distribuire leinformazioni relative alla topologia della rete, per-mettono ai pacchetti di essere inoltrati corretta-mente verso la destinazione finale. In assenza diinformazioni di routing accurate, o in presenza diinformazioni false, la trasmissione dei pacchettiattraverso la rete risulta inefficiente o addiritturaimpossibile. Questo fatto è di per se problematico,in quanto un eventuale attacco all’infrastruttura dirouting che regola il normale funzionamento delbackbone, potrebbe avere delle conseguenzemolto gravi poiché l’attacco avrebbe pesanti effettianche sulle altre reti, interconnesse al backbone,che si troverebbero ad essere completamente o inparte isolate dal resto della rete.

Lo stato dell’arte in questo specifico camponon vede, per il momento, emergere una soluzionedi riferimento, anche se da qualche tempo i forni-tori di soluzioni di sicurezza hanno reso disponibilialcune soluzioni che si propongono di rispondereal problema della sicurezza del backbone. Questesoluzioni, in teoria, si propongono di lavorare nonsolo sui livelli protocollari tipici degli end-point (daltrasporto in su), ma anche a l ivello di inter-networking (dunque, essenzialmente sul livello 3).In pratica però, molte delle soluzioni disponibili nonintervengono attivamente, interfacciandosi con isistemi di routing utilizzati nel contesto da control-



lare, ma util izzano informazioni derivate dagliapparati tramite tecniche standard (prelievo divariabili SNMP dalle MIB dedicate agli aspetti dirouting) oppure utilizzando altre sorgenti di infor-mazioni (NetFlow). L’approccio classico dellaNetwork Intrusion Detection è difficilmente applica-bile in questo contesto, dal momento che l’utilizzodel pattern matching non permette di identificareimmediatamente una condizione di funzionamentoanomala. Attualmente, alcuni produttori specifici (inparticolare Arbor Network e Riverhead) offronosoluzioni puntuali per alcuni problemi, quali adesempio il contrasto degli attacchi Distributed-DoS, mentre i maggiori produttori (in particolareCisco e Juniper) stanno portando avanti delle inte-ressanti iniziative di ricerca e sviluppo.

Con il discorso sul backbone, concludiamo lapanoramica sullo stato dell’arte. In questo articolo,non abbiamo la pretesa di essere completamenteesaurienti. Abbiamo, infatti, ritenuto opportunolimitare la descrizione alle soluzioni che, a nostroavviso, risultano maggiormente interessanti. Il qua-dro fornito dovrebbe essere più che sufficiente perinquadrare gli aspetti rilevanti delle tecnologie piùdiffuse relative al contesto dell’Intrusion Detection.

4. Dalla tecnologia ai prodotti:Intranet e Backbone IDS

A partire dalla fine degli anni Novanta, moltedelle soluzioni elaborate sia in ambito militare, sianel contesto accademico iniziano ad essere imple-mentate direttamente in contesti commerciali,seguendo la più classica logica dei prodotti di

sicurezza. Chiaramente, la necessità di offrire unprodotto completo richiede di prendere in conside-razione altri aspetti che non sono necessariamentelegati alle problematiche della rilevazione in sensostretto. In ogni caso, il passaggio dal laboratorioall’ambiente di esercizio porta ad evidenziare moltiproblemi ed anche alcuni limiti strutturali dellesoluzioni identificate in ambito di ricerca.

La soluzione largamente più diffusa nell’ambitoIDS è rappresentata da un sensore di tipo network-based che lavora essenzialmente con un para-digma di tipo misure detection, in particolare conuna logica di tipo pattern matching. Tutti i piùimportanti prodotti commerciali (ISS ProventiaTM,SourcefireTM, Dragon EnterasysTM, o SymantecManhuntTM) implementano una logica di questogenere, affiancandola poi con varie altre tecnologiespecifiche che mirano a ridurre l’incidenza dei falsipositivi e dei falsi negativi (si veda il riquadro “ISSProventiaTM e Sourcefire RNATM).

Il problema dei falsi negativi è sicuramentequello più drammatico nel contesto degli IDS. Unfalso negativo è spesso associato alla possibilità dimodificare in modo più o meno arbitrario la formadell’attacco senza variarne la sostanza. Un’interaclasse di attacchi basati su questa problematica èrappresentata dall’utilizzo della tecnica di fram-mentazione. In pratica, spezzettando in pacchettimolto piccoli il payload applicativo che contienel’attacco, si impedisce al sistema di pattern mat-ching di funzionare in modo efficace. Un approcciopiù sottile consiste nell’invio di frammenti che sisovrappongono in modo parziale; dal momentoche il criterio con cui vengono trattati frammentiparzialmente sovrapposti non è univoco, è possi-

ISS ProventiaTM

eSourcefire RNATM

ISS (Internet Security System) pro-pone con Proventia la tecnologiaFusion per la riduzione dei falsi posi-tivi. Fusion correla i risultati dell’ana-lisi del Vulnerability Assessment conle segnalazioni del sensore diIntrusion Detection per determinarel’impatto effettivo dell’attacco sulsistema bersaglio. Il sistema esegueperiodicamente una scansione dellerete che permette di identificare inmodo puntuale le eventuali vulnerabi-lità presenti. Quando il sensore identi-fica un attacco, l’informazione vieneincrociata con i risultati della scan-sione più recente e se la macchina

risulta vulnerabile, viene emesso unallarme di alta priorità; altrimenti, l’e-vento viene conservato nel log, mal’operatore non viene coinvolto diret-tamente.Il vantaggio principale della tecnolo-gia è quello di ridurre l’incidenza deifalsi positivi; tuttavia, i problemi prin-cipali di questo approccio sono: lanecessità di eseguire delle continuescansioni sulla rete monitorata e ilpotenziale disallineamento che puòcrearsi tra la configurazione realedella rete e quella vista da Fusion(perché, per esempio, è stataaggiunta una patch e non è ancorastata rieseguita la scansone).Sourcefire, l’azienda di M. Roesch checommercializza Snort, propone unapproccio alternativo, denominatoRNA (Real-time Network Awareness).Il vantaggio prevalente rispetto allasoluzione di ISS è quello di essereappunto real time nella rilevazione.Infatti, non appena un sistema viene

modificato o aggiunto alla rete damonitorare, sfruttando una serie ditecniche di analisi passiva dei pac-chetti, RNA è in grado di identificarenumerose caratteristiche del sistema,e dunque di associare agli eventigenerati dal sensore una indicazionerelativa al potenziale impatto dell’e-vento. Ad esempio, se si identifica unattacco per un server Linux diretto aduna macchina Windows (o viceversa),RNA è in grado di disattivare l’allarme,che è sicuramente un falso positivo.La limitazione principale di questoapproccio è legata al fatto che non èpossibile rilevare tutti i falsi positivisfruttando un meccanismo che siasolamente passivo. In effetti, RNAprevede comunque la possibilità diinserire nella base di conoscenze delsistema anche informazioni ricavateper mezzo di altri strumenti (come adesempio, quel l i di Vulnerabil ityAssessment).



bile che il sensore ed il sistema bersaglio vedanodue distinti contenuti e dunque l’effetto netto èquello di un errata interpretazione di ciò che staaccadendo; la figura 2 mostra graficamente unesempio di ciò che può accadere in questo caso.

Un’altra classe di attacchi sempre basati suquesto stesso paradigma è rappresentata dallacosiddetta “denormalizzazione”; in pratica, alcuniprotocolli supportano diverse forme di codifica peril contenuto applicativo. Sfruttando codifiche alter-native, è possibile aggirare le specifiche signatureper un attacco; inoltre, è impossibile pensare diinserire tutte le forme differenti con cui può esserecodificato un attacco; chiaramente, l’approccioideale consiste nel riportare il contenuto del pac-chetto in una forma standard prima di eseguire ilpattern matching.

Per evitare di prolungare troppo la descrizione,si rimanda al lavoro di Ptacek et al. [22] per unapprofondimento sugli attacchi che è possibileeffettuare verso un IDS. Oggi, la maggior parte dei

sistemi commerciali utilizza le tecniche di analisidel protocollo per gestire i problemi correlati aframmentazione, denormalizzazione ed offusca-mento. Queste tecniche non sono di per sé innova-tive, tuttavia lo sforzo richiesto per realizzare unsistema robusto ed efficiente è notevole e puòessere affrontato solo in sistemi che vengonogestiti con la logica del prodotto.

L’altro problema tradizionale degli IDS è l’e-norme numero di allarmi che questi dispositivi ten-dono a generare soprattutto quando non sono benconfigurati. Anche in questo caso, le tecniche dianalisi del protocollo possono ridurre notevolmentei falsi positivi, eliminando tutti quegli allarmi checorrispondono a situazioni che non sono effettiva-mente ammissibili. Ad esempio, un pacchettosospetto su una connessione TCP che però non haancora completato il 3-way handshake è chiara-mente un falso allarme. Il pacchetto non sarà maiprocessato dal livello applicativo, e dunque l’at-tacco è destinato all’insuccesso.

Il problema della gestione dei falsi positivi èstato affrontato in vari modi dai diversi produttori.In molti casi, la tendenza è quella di andare versosistemi multilivello che correlino le informazionigenerate dall’IDS con quelle ottenute da altre fonti,tipicamente i sistemi di scansione delle vulnerabi-lità o, in generale, altri sistemi che permettono dieseguire un assessment dei sistemi che si intendeproteggere. Rimandiamo ai riquadri “La soluzioneArbor Networks” e “La soluzione Riverhead” per unapprofondimento sugli approcci utilizzati in duedelle soluzioni più diffuse in ambito IDS.

Nel contesto backbone, gli approcci più tipicisono quelli di tipo Anomaly Detection; le tecnologiepiù importanti sono quelle correlate all’analisi stati-stica del traffico. Il problema essenziale nella rile-vazione degli attacchi di tipo Distributed Denial of

Frammenti duplicati e sovrapposti;il risultato del riassemblaggio dipende dal sistema operativo.

S H E LF A K

C O DL E

FIGURA 2› Il problema della ricostruzione del payload a partire da fram-

menti sovrapposti.

La soluzioneArbor Networks

PeakFlow PlatformTM è la soluzione diArbor Networks per l’analisi degliattacchi al backbone. Si tratta diun’architettura di raccolta ed analisidei dati di traffico secondo un para-digma di tipo Anomaly Detection. Idati sono raccolti sia a partire dalleinformazioni generate dagli apparatidi rete, esportate per mezzo del pro-tocollo NetFlow, sia analizzando diret-tamente il traffico rilevato. La piat-taforma è basata su due sistemi:• Peakflow X è la soluzione orien-

tata alle reti di grandi aziende edha l’obiettivo di aiutare gli ammini-stratori di rete a risolvere i pro-blemi derivanti dalle minacce allasicurezza nei confronti del lerisorse interne. La soluzione siappoggia sul modello comporta-mentale del la rete che vienecostruito ed aggiornato in realtime; questo modello permetteagli amministratori di tracciare ilcomportamento fino al livello delsingolo host, analizzando come econ chi sono state instaurate leconnessioni. Le informazioni sonoun utile strumento per identificaresia le fonti di attacco, sia lemisure per rinforzare il perimetrodella rete;

• Peakflow SP è la soluzione dedi-cata ai Service Provider il cui prin-

cipio di funzionamento è moltosimile a quello della soluzione pre-cedente, anche se focalizzatoessenzialmente sul monitoraggiostatistico del traffico. La soluzionein realtà è formata da tre elementi:- Infrastructure Security, che si

occupa di individuare anoma-lie a livello di rete;

- Traff ic and Routing , checostruisce il modello di traf-fico della rete controllata abili-tando gli amministratori adintervenire in funzione divariazioni signif icative delmodello;

- Managed services, che per-mette all’operatore di erogareun servizio di Dos/DDos pre-vention ed altri servizi di sicu-rezza ai propri clienti.



Service è rappresentato proprio dalla difficoltà neldistinguere situazioni di carico elevato dovute aduna particolare condizione di servizio (ad esempio,si pensi a ciò che accade quando si cerca di acqui-stare un biglietto per un grande concerto e l’inter-vallo temporale per eseguire la richiesta è moltoridotto: il numero enorme di richieste in un ridottointervallo di tempo somiglia drasticamente ad unSYN-flood distribuito).

Uno dei problemi essenziali in quest’ambito èrappresentato dalla necessità di raccogliere unnumero elevatissimo di informazioni rilevanti aiflussi. È evidente che se ogni apparato di reteesporta queste informazioni in modo proprietario,diventa molto più complesso riuscire a far funzio-nare un qualsiasi sistema di monitoraggio, che èuno dei componenti essenziali di qualsiasi architet-tura mirante a risolvere questo tipo di problemi.L’IETF (Internet Engineering Task Force) si è per-tanto mossa in questa direzione ed ha fatto sua[22] una specifica di Cisco, denominata NetFlow,che consente ai vari amministratori di rete di otte-nere, in un formato standard, una serie di informa-zioni sui f lussi dati che attraversano la rete.NetFlow nasce in primis per supportare le attivitàdi raccolta dei dati di traffico per la tariffazione, male informazioni che esso genera possono essereusate in modo naturale per l’analisi dei problemi disicurezza. Oggi, la maggior parte degli apparati(Enterasys, Foundry Networks, Extreme Networks,Juniper, Riverstone, InMon Networks) integranoquesto protocollo; inoltre esistono vari applicativiin grado di interpretare ed analizzare queste infor-mazioni; nello specifico, citiamo PeakflowTM (svi-luppato da Arbor Networks) ed NTop, un prodottoopen-source sviluppato presso il centro SERRAdell’Università di Pisa. NetFlow è in grado di cattu-rare un ricco insieme di dati statistici. Queste stati-stiche includono tra l’altro il protocollo, le porte, il

tipo di servizio che combinate insieme forniscono,come detto in precedenza, una base informativautile per una vasta gamma di servizi.

L’entità misurata da NetFlow è il “flusso”, iden-tificato come un insieme di pacchetti tra una sor-gente ed una destinazione che vengono identificatidai seguenti campi:• Source IP Address;• Destination IP Address;• Source Port Number;• Destination Port Number;• Protocol Type;• Type of Service;• Input Interface.

Le informazioni generate da NetFlow sono tra-smesse tramite pacchetti UDP; il protocollo hasubito varie evoluzioni (oggi la versione utilizzata èla 5). La modifica più importante rispetto alle vec-chie versioni è rappresentata dall’introduzione delleinformazioni relative al protocollo di routing BGPed ai sequence number.

A livello più strettamente applicativo, le tecnolo-gie più interessanti in questo ambito sono rappre-sentate da Riverhead e Arbor Networks, chedescriviamo con maggiore dettaglio nei rispettiviriquadri di approfondimento.

5. L’Attività di Ricerca & Sviluppo in TILAB

A part i re da l 2003, sono stat i avv iat i inTelecom Italia Lab una serie di progetti focalizzatisul tema dell’Intrusion Detection. La motivazioneprincipale è legata al fatto che le soluzioni propo-ste dal mercato, oltre ad essere economicamenteonerose, non sono sempre funzionalmente adattead un contesto eterogeneo come quello checaratterizza un grosso operatore di telecomunica-zioni che richiede una enorme flessibilità in grado

La soluzioneRiverhead

La società israel iana RiverHeadNetworks, acquisita nel 2004 daCisco, è stata la prima a rilasciare sulmercato una tecnologia in grado diidentificare e rimuovere in real-timegli attacchi DoS/DDoS senza andaread impattare sul traffico legittimo. Lasoluzione prevede la presenza di duedifferenti sistemi:• Detector: funziona, in sostanza,

come un classificatore del trafficoed è in grado di identificare la pre-senza di schemi di attacco;

• Guard: è l’oggetto che si occupa

di ripulire il traffico, lavorando suivari flussi in base alle indicazioniche gli provengono dal Detector.

Il funzionamento del sistema ideatoda Riverhead prevede che quando ilDetector identif ica un potenzialeattacco, venga inviato un allarme allaGuard, affinché questa inizi un pro-cesso di ridirezione del solo flussosospetto, mentre il resto del trafficorimane inalterato. I l Detector ècomunque un componente opzionaledell’architettura, dal momento che laGuard può ricevere notifiche anche daaltre sorgenti.La ridirezione del traffico avvienesfruttando alcune particolari meccani-smi di routing; il traffico viene quindielaborato dalla Guard per mezzo diuna serie di controlli basati sull’archi-tettura brevettata MVP (MultiVerification Process). Questa prevede

differenti l ivell i di intervento, cheincludono operazioni di limitazionedella banda, di terminazione completadi una connessione, ed altre ancora;l’azione appropriata viene selezionatain base al livello di pericolosità asso-ciato dal processo di identificazione.Il traffico che supera questo processodi “ripulitura”, e che dunque vieneritenuto legittimo, viene reintrodottoin rete affinché possa raggiungere lacorretta destinazione. La soluzione di Riverhead, ora Cisco,è sicuramente indicata per la prote-zione di un backbone da attacchimassivi che potrebbero minare il fun-zionamento dell’intera rete, ma risultaappropriata anche per grandi retienterprise o data center.



di operare in per vari segmenti di rete (dalla con-nettività broadband per utenti domestici fino albackbone).

L’attività di ricerca si è articolata su tre progetti.Il progetto EAGLE è stato focalizzato sull’ideazionee sulla prototipazione di nuove tecnologie chepotessero essere utilizzate nell’ambito più tradizio-nale, prestando particolare attenzione agli aspettidi flessibilità e scalabilità menzionati in prece-denza. Il progetto RDS (Routing Detection Security)è stato invece focalizzato sulle problematichelegate alla rete di backbone, ponendo particolareattenzione agli attacchi che è possibile effettuaresull’infrastruttura, in particolar modo ai protocolli dirouting. Infine, nell’ambito del progetto dedicatoalla sicurezza delle reti wireless (con particolareenfasi al mondo IEEE 802.11 e WiFi) si è provve-duto a studiare e prototipare delle componentispecifiche per questo ambito che potessero esserecomunque integrate in un sistema tradizionale ditipo network.

I risultati dell’attività di ricerca sono notevoli epossono essere riassunti dai seguenti risultati:• Brevetti: l’intera attività ha portato al deposito

di sei domande di brevetto focalizzate sulla tec-nologia di tipo network, due domande di bre-vetto focalizzate sulla tecnologia host, unadomanda di brevetto focalizzata sul contestoWiFi ed una domanda di brevetto focalizzata sulcontesto backbone.

• Prototipi: ogni singolo progetto ha prodotto unoo più prototipi; in particolare, è disponibile unasoluzione completamente funzionante, per ilsistema di network-IDS. Inoltre, sono stati inte-grati nel sistema due componenti prototipalirelative al contesto WiFi. Il sistema host-IDS èinvece disponibile solamente in stato di prototi-pazione avanzata e solamente per la piat-taforma Linux. Per ciò che riguarda l’ambitobackbone, sono state messe a punto le sondeper il protocollo OSPF e per il protocollo BGPoltre ad un sistema specifico per la raccolta el’elaborazione delle informazioni raccolte dallesonde.

• Linee di codice complessive: per quanto questaquantificazione possa ritenersi imprecisa neldescrivere la complessità effettiva dei sistemiche sono stati realizzati, risulta comunque utilenel fornire almeno un’indicazione di massimasulla loro dimensione “quantitativa”. Esistonooggi circa 150.000 linee di codice per il sensoredi tipo rete (più altre 2000 per il supporto WiFi),20.000 linee per il sistema di tipo host-based ealtre 20.000 per i sistemi di tipo backbone.Passiamo ora a descrivere brevemente le più

importanti caratteristiche delle singole soluzioni.

5.1 Il sensore Network-IDS: nEAGLE™

nEAGLE™ è la soluzione network-IDS svilup-pata nell’ambito del progetto omonimo (figura 3). Ilsistema è basato sulla tecnologia state of the artper ciò che riguarda il pattern matching; assieme aquesta tecnologia tradizionale, implementa anche

tre meccanismi innovativi (sottoposti a domanda dibrevetto), descritti nel seguito:• I l Bidirectional Rule Matching (BRM) è un

meccanismo che analizza la risposta del ser-ver a seguito di un pacchetto identif icatocome potenzialmente pericoloso; la rispostaspesso consente di identificare se l'attacco haavuto successo o meno. In questo modo, ilnumero di falsi positivi viene ridotto drastica-mente, lavorando direttamente a livello delsensore. Inoltre, mentre le regole che descri-vono gl i at tacchi r ichiedono un cont inuoaggiornamento, le regole di r isposta sonorelativamente stabili, essendo correlate allecaratteristiche del protocollo applicativo. Atitolo puramente esemplificativo, descriviamoun esempio d’uso del BRM: il successo di unattacco diretto ad un server Web, che sfruttale vulnerabilità di un particolare script instal-lato per default, può essere desunto con uncerto grado di precisione dalla risposta delserver: se infatti i l server risponde con uncodice di errore 400 (ad esempio AccessForbidden o Object not Found) è estrema-mente probabile che l’attacco sia andato avuoto. Un risultato di tipo 200 (OK), seguitopoi da pacchetti che contengono elementitipici di una interazione basata su una com-mand-line shell, è una chiara indicazione delfa t to che l ’a t tacco ha avuto successo.Chiaramente, questo scenar io non ha loscopo di presentare in modo esaustivo edapprofondito il BRM, ma solo di dare un’ideadi come esso funzioni praticamente.

DetectionRules DB

10/100 Mbit/s 1000 Mbit/s WiFi

BidirectionalRules Matching

DynamicAuto Tuning

ProtocolAnalyser

Alert Coding & Emission System

TCP Flow Re-Assembly

IP Defragmentation

SMP Load Balancing System

Custom Network Driver

Enhanced Pattern Matching Engine

Exte

rnal

Ope

n S

ourc

e R

ules

IPSMPTCP

===

Internet ProtocolSymmetric Multi ProcessorTransmission Control Protocol

FIGURA 3› nEAGLETM: architettura schematica.



• Il Dynamic Auto Tuning (DAT) consente al sen-sore di adattare il set di regole alla configura-zione della rete; in questo modo il sistema è ingrado di identificare autonomamente la pre-senza di un servizio/protocollo noto (ad esmpioHTTP, FTP, Telnet) su porte non standard.Questo consente di ridurre i falsi negativi,dovuti ad attacchi non rilevati perché direttiverso server attestati su porte non standard. IlDAT utilizza delle regole di tipo pattern mat-ching o di protocol analysis per identificare inun flusso di pacchetti ben definito la presenzadegli elementi distintivi di un particolare proto-collo applicativo. A fronte di una tale situazione,il DAT riconfigura automaticamente il sensore,di modo che tutte le regole utilizzabili per quelparticolare protocollo vengano altresì adottateanche su quella particolare connessione.

• Il supporto per Multi-Processori Simmetrici: unsistema di network IDS funziona analizzando ipacchetti; per poter trarre vantaggio dalla pre-senza di più CPU sono possibili due approcci: ilpipeline, o la distribuzione del carico sulle sin-gole CPU. nEAGLE™ sfrutta l’approccio delload balancing, e ripartisce fra le CPU disponi-bili sia l’attività di ripartizione del carico, sia lavera e propria attività di rilevazione degli attac-chi. L’algoritmo di scheduling che seleziona laspecifica attività da eseguire su ogni singolaCPU è di tipo application based, a differenzadella maggior parte degli approcci standard,che sono invece di tipo kernel based e dunquenon possono in alcun modo sfruttare la cono-scenza del dominio applicativo per pilotare ledecisioni di scheduling. Questo approccio con-sente di ottenere delle prestazioni notevolmentesuperiori su sistemi SMP rispetto a quelle che siotterrebbero con sistemi tradizionali, senzadover ricorrere ad alcun load balancer separato.Oltre all’adozione di specifiche tecnologie inno-

vative, l’intero sistema è stato sottoposto ad unacompleta ingegnerizzazione, focalizzata sulla ridu-zione notevole dell’overhead computazionale asso-ciato alla cattura dei pacchetti. Utilizzando unsistema ad hoc, realizzato per mezzo di un device-driver customizzato, si possono evitare alla radice iproblemi del livelock [24], sfruttando due approcciclassici della teoria dei sistemi operativi: imple-mentazione di canali di comunicazione tra device-dr iver ed user space che siano 0-copy e lagestione del dispositivo di rete a polling invece checon le interruzioni.

nEAGLE™ supporta inoltre un meccanismo perrilevazione degli attacchi specifico per reti WiFi;questo meccanismo è in grado di rilevare attacchiportati ai livelli fisico e datalink dello stack TCP/IPquali Authentication-Deauthentication, Frame-Flooding , Associat ion-Disassociat ion-Reassociation, Request-flooding. Oltre a questimeccanismi, l’attività di ricerca e sviluppo ha por-tato alla realizzazione di una specifica funzionalità(attualmente coperta da domanda di brevetto),orientata alla riduzione dei falsi positivi ed all'indi-viduazione di attacchi o tentativi di violazione del

meccanismo di autenticazione per reti WiFi IEEE802.1x (ad esempio: THC-LeapCracker [25],ASLEAP [26], 4Way Handshake Start DoS [27]).Tale funzionalità è basata sulla correlazione delleinformazioni scambiate sulla rete WiFi con le infor-mazioni r icevute dagl i elementi di rete qual iAccess-Point e server di autenticazione (ad esem-pio RADIUS) che realizzano la rete WiFi.

nEAGLE™ è stato verificato in laboratorio, dovesono state ottenute delle prestazioni davvero note-voli (fino ad un ordine di grandezza superiore),rispetto a quelle basate su tecnologie attualmentedisponibili su sistemi hardware a basso costo. Perciò che riguarda l’efficacia (Falsi Positivi e FalsiNegativi), nEAGLE™ si è dimostrato estremamentevalido, sia durante i test di laboratorio, sia durantel’attività di field trial. In particolare, nEAGLE risultain grado di gestire un numero di pacchetti supe-riore di un ordine di grandezza rispetto a soluzioniconvenzionali (su hardware low cost in condizionidi sovraccarico), con un aumento della bandamedia gestita da 5 Mbit/s a circa 34 Mbit/s. Per ciòche riguarda il contesto high end, sfruttando unsistema SMP a due CPU, nEAGLE riesce a gestiretranquillamente una banda dell’ordine del Gbit/s.

5.2 Il sensore HIDS: SPID™

La sonda di s istema SPID (System PhotoIntrusion Detection), figura 4, usa un approccioinnovativo, basato sul paradigma dell'AnomalyDetection, per identificare gli attacchi.

Correlation

Detection

Alert Coding

SystemSensor

SPID

Internal Alert

...

KnowledgeBase

CurrentState

File System

NetworkApplication

SystemCall

KernelInfo

10Mbit/s

Shell

SystemApplication

Alerting

Status Photo Intrusion Detection (SPID)Technology TILAB Be-SecureTM Patent Pending

Interception

Data Normalisation

FIGURA 4› Architettura essenziale di una sonda SPID.



La metafora su cui è basato è ben descritta dalnome che lo contraddistingue; in pratica, SPIDesegue una serie di “fotografie istantanee” delsistema, focalizzandosi sugli schemi di utilizzodelle varie risorse disponibili sul singolo host. Adesempio, si monitorano le relazioni parent/childesistenti tra tutti i processi attivi, le relazioni trautenti, applicazioni e file; quelle fra applicazioni econnessioni di rete, e così via. Ogni particolareaspetto del sistema è analizzato da un compo-nente ad hoc della Knowledge Base.

Come tutti i sistemi di tipo Anomaly Detection,SPID opera in due fasi . Nel la pr ima fase(Addestramento), il sistema raccoglie tutte le infor-mazioni che caratterizzano l’uso normale dell’host.Alla fine dell’addestramento, la Knowledge Basecosì ottenuta viene normalizzata; in altre parole, siidentificano tutti gli intervalli tipici di variabilità delsistema, quale ad esempio l’utilizzo di file tempora-nei o eventuali periodicità con cui sono usate spe-cifiche applicazioni. Queste informazioni, estrapo-late dai dati osservabili, vengono incluse nei datiche verranno poi usati durante la seconda fase difunzionamento (Analisi). In analisi, SPID confrontalo stato del sistema con le informazioni dellaKnowledge Base; se viene rilevata un’anomalia, siemette una segnalazione. Un opportuno sistema diraccolta ed aggregazione di queste segnalazioni sioccupa poi di codificare in un allarme vero e pro-prio le anomalie rilevate dalle singole componentiche costituiscono il sistema.

SPID è costituito da un insieme di componenti,organizzati in base ad una architettura a tre strati.Lo strato più basso si occupa dell’acquisizionedelle informazioni dal sistema operativo; la tecnicaadottata in SPID è quella dell’intercettazione dellesystem call. A differenza di altri sistemi, in cui ven-gono intercettate indistintamente tutte le systemcall per fornire un modello che caratterizzi l’esecu-zione di un dato processo, SPID si limita ad inter-cettare tutte e sole quelle system call che coinvol-gono direttamente una risorsa del sistema opera-tivo, nello specifico: file, socket, device-driver, pro-cessi, identificativi di utente. Di queste system callvengono registrati i parametri ed il processo che haeseguito la richiesta. Utilizzando queste systemcall, il secondo strato è in grado di costruire unmodello analogico ridotto del sistema; in praticaquesto strato ha due compiti: tradurre la specificasystem call in una richiesta astratta di utilizzo dirisorsa del sistema operativo, ed offrire allo stratosuperiore una visione astratta di quello che è lostato istantaneo del sistema monitorato. L’ultimostrato è quello più complesso e si occupa di racco-gliere e controllare gli schemi con cui sono usate levarie risorse. Dal momento che ogni risorsa ha lesue particolarità, sono stati implementati diversimoduli, ognuno con una logica:• User Table: questo modulo mappa le relazioni di

tipo utente/applicativo/file, fornendo una vistaglobale del comportamento del sistema ricavatadirettamente a partire dal modello analogicoridotto presente nel secondo strato. Il modulotiene traccia di tutte le risorse che vengono uti-

lizzate nel corso del funzionamento del sistema;inoltre, per mezzo di appositi contatori, vieneanche misurato i l numero complessivo diistanze di un certo oggetto. Ogni volta cheappare un oggetto nuovo, che non era mai statovisto dal sistema durante la fase di apprendi-mento, oppure ogni volta che uno dei countereccede i limiti ricavati dalla fase di apprendi-mento, viene emessa una segnalazione.

• Process Tree: questo modulo traccia la rela-zione di utilizzo tra applicazioni; in altre parole,si cerca di capire quali applicazioni possonoessere seguite da una applicazione data. Larelazione ad albero è molto utile per catturaretutti quei casi in cui, per effetto di un overflow,si riesce a creare una shell abusiva nel contestodi un server di rete.

• Network: questo modulo tiene traccia di tutte leconnessioni di rete, identificando gli applicativiche svolgono il ruolo di client e/o server; leporte su cui operano, e le caratteristiche stati-stiche della durata delle connessioni.

• File System: questo modulo tiene traccia ditutte le modifiche al file system; in particolare,può rilevare mount/unmount impropri, la crea-zione o la cancellazione di un elevato numero difile, la cancellazione di file che sono ancoraaperti, o l’eccessivo numero di link simboliciassociati ad un file. Anche in questo caso, l’usodei contatori e l’applicazione della procedura dinormalizzazione consente di discriminare leazioni ammissibili da quelle che non lo sono.SPID è stato verificato in laboratorio su alcuni

server specifici della rete interna; al momento èancora considerato un sistema incompleto. I risul-tati ottenuti durante la sperimentazione sono posi-tivi, in particolare, SPID sembra immune da alcuniattacchi che invece caratterizzano altri sistemibasati sulla syscall interception e sul paradigma diAnomaly Detection.

5.3 La tecnologia RDS

Il progetto RDS (Routing Detection System)nasce con l’obiettivo di realizzare un sistema diIntrusion Detection dedicato interamente all’analisidegli attacchi rivolti ai protocolli di routing. Unadelle sue caratteristiche essenziali è la capacità diadattarsi all’ambiente d’uso, raccogliendo in mododifferente, a seconda del protocollo di routingmonitorato, tutte le informazioni che determinano ilcomportamento della rete. Tale approccio permettedi identificare, in modo preventivo, il verificarsi diparticolari eventi che possono essere associati amalfunzionamenti o a veri e propri attacchi chedirettamente o indirettamente provocano malfun-zionamenti all’infrastruttura.

L’architettura del sistema (figura 5) prevede chele sonde siano minimamente intrusive pur essendoin condizione di ricevere tutte le informazioni dirouting. Il sistema, nel suo insieme, è caratterizzatoda una struttura gerarchica nella quale le opera-zioni di rilevazione sono segmentate sui vari livelli,in funzione della complessità e della necessità di



input provenienti da altri compo-nenti; l’affidabilità, che nel contestodel backbone è una caratteristicairrinunciabile, è garantita dalla pre-senza di più elementi ridondanti,non solo a livello delle sonde, maanche degli altr i componenti.Particolare attenzione viene dataalla struttura dei vari moduli delsistema, che presentano una confi-gurazione che facilita la realizza-zione e l’integrazione di nuove logi-che di detection e nuove tipologie disonde per protocolli non ancoraconsiderati dal sistema.

Il sistema consta di due livelliconcettuali: le sonde, che sonooggetti specializzati in grado diinterfacciarsi, secondo differentimodalità con i processi di routing,ed il cosiddetto “Data Base Ring”,che è un sistema di alta affidabilitàche riceve le informazioni dallesonde, le processa secondo logichecodificate e memorizza i dati otte-nuti su un apposito database. Unattacco al sistema di routing puòprovocare la “scomparsa”, seppurmomentanea, di alcune zone di reteda monitorare. La struttura adanello, garantisce che, anche incondizioni critiche, il sistema puòcontinuare a funzionare correttamente; la presenza dipiù elementi in grado di raccogliere le informazionipermette anche di suddividere il carico di lavorogarantendo in questo modo un buon livello di scala-bilità. Ovviamente, l’operatore può interrogare i data-base attraverso una classica interfaccia GUI. OggiRDS è in grado di funzionare con due protocolli dirouting: OSPF (Open Shortest Path First) e BGP(Border Gateway Protocol) di seguito descritti:• Sonda OSPF: esegue l’analisi dei pacchetti

OSPF sia attraverso una logica classica di snif-fing del traffico sia interfacciandosi direttamentecon il processo di routing che collega la sondaalla rete da monitorare. La sonda è in grado dicontrollare varie “anomalie”, tra le quali:- Reti foglia su cui è attivo OSPF: questo con-

trollo permette di identificare e segnalare lapresenza, o la comparsa, di reti di accessosu cui è attivo il protocollo OSPF; tale situa-zione non è necessariamente indicativa di unattacco, ma segnala la presenza di unpotenziale punto di attacco.

- Creazione di nuove adiacenze: questoevento segnala la creazione di una nuovaadiacenza su una rete su cui OSPF è attivo epuò rappresentare l’inizio di un attacco.

- Detection dell’attacco MAXSEQ-MAXAGE edell’attacco LOWCOST [28].

- Variazione del numero di rotte: questo con-trollo serve per segnalare modifiche in crescitao decrescita della tabella di routing; questoevento, specie nel caso di variazioni significa-

tive o di numerose variazioni nell’unita ditempo, è spesso indicativo di un attacco.

- Apparizione di rotte non appartenenti al pro-prio dominio IP: l ’ iniezione di rotte nonappartenenti al dominio è, nel migliore deicasi, un errore di configurazione. La rileva-zione avviene mediante l’analisi incrociatadella tabella di routing OSPF con i file diconfigurazione redatti dall’operatore.

- Rilevazione di anomalie sulla sonda stessa: ilsistema è in grado di rilevare la presenza dicriticità nella connessione con le sonde; chepossono indicare un malfunzionamento o l’ini-zio di un attacco diretto all’infrastruttura.

• Sonda BGP: l’analisi dei pacchetti BGP è basatasu un vero e proprio sistema di routing inseritodirettamente dentro la sonda, unito ad un mecca-nismo di protocol analysis sviluppato apposita-mente per il protocollo BGP. Il dialogo tra lasonda e gli apparati di rete si realizza attraversouna sessione di peering BGP. La sonda è in gradodi lavorare sia in configurazione iBGP che eBGP.Tipicamente si utilizza la modalità iBGP in quantopermette di trasportare informazioni di routingcon un livello di dettaglio superiore; infatti in que-sto caso non vengono eseguite variazioni sulcampo Next Hop dei messaggi BGP e inoltreviene utilizzato il campo Local Preference. Più indettaglio, la sonda è in grado di eseguire molticontrolli, tra i quali:- Rilevamento di un eccessivo scambio di

messaggio tra peer.

Management System

Data Base Ring

Sonda

Sonda

ReteControllata

Sonda

FIGURA 5› Architettura essenziale del sistema RDS.



- Rilevamento del “flapping”: si riferisce aduna modifica troppo frequente delle informa-zioni presenti nella tabella di routing, sia inupdate sia in withdrawn.

- Distribuzione di prefissi/reti non autorizzati,non allocati e ad uso privato.

- Rilevamento dei conflitti MOAS (Multiple OriginAS) [29]: questo controllo permette di verificarela corrispondenza degli AS di origine di unupdate con quanto risulta dagli archivi delRIPE, ed evidenziare discrepanze e/o conflitti.

- Redistribuzione della default route.- Rilevamento anomalie sui Next-Hop: com-

parsa, sparizione, modifica dei Next-Hopassociati alle rotte.

- Rilevamento attacchi alla sonda: realizza-zione di una honeypot BGP in grado di iden-tificare eventuali tentativi di instaurazione disessioni BGP non autorizzate.

- Rilevazione anomalie sul campo AS-Path:analisi del campo AS-Path per valutarne levariazioni significative nel tempo.

- Monitoraggio delle rotte degli AS cliente:monitoraggio della raggiungibilità delle retidegli AS cliente.

Il sistema RDS è stato verificato nei laboratori diTelecom Italia Lab, utilizzando a tale scopo unarete emulata consistente di circa 18 router distinti.Le sperimentazioni hanno dato esito positivo e si èquindi partiti con un primo field trial, posizionandole sonde sulla rete di Telecom Italia Lab. In questoambiente le sonde hanno evidenziato una buonacapacità di rilevazione delle anomalie, sia in ambitoOSPF che BGP.

6. Conclusioni

Questo articolo ha cercato di fornire una pano-ramica, quanto più ampia possibile, sull’ambitodella rilevazione delle intrusioni informatiche.Chiaramente, il tema è estremamente vasto, edunque ci si è limitati a fornire un punto di par-tenza per approfondire le caratteristiche dellevarie tecnologie disponibili. Il problema della rile-vazione è cruciale nel contesto di un’architetturadi s icurezza costru i ta su l paradigma del la“Defense in Depth”, perché è evidente che soloattraverso un sistema di rilevazione davvero effi-ciente è possibile pensare di adottare delle tecno-logie automatiche di risposta e protezione. Laricerca svolta in Telecom Italia Lab su questotema nello scorso biennio, è stata incentrata sullaproblematica del l ’eff icacia e del l ’eff ic ienza,ovvero sulla capacità di rendere il processo dirilevazione quanto più accurato possibile, ridu-cendo i falsi positivi e negativi, sfruttando almeglio le performance dell’hardware disponibile efocalizzando l’intervento umano solo sui problemidavvero significativi. L’esperienza maturata nelcorso delle varie sperimentazioni, indica che que-sti aspetti sono fondamentali per consentire unutilizzo ottimale delle tecnologie IDS anche alcontesto delle grosse reti di telecomunicazioni.

— BIBLIOGRAFIA

[1] Denning D. E.: “An Intrusion-Detection Model”, IEEETransactions on software engineering, Vol. SE-13, NO. 2,february 1987, 222-232.

[2] Anderson, J.: “Computer Security Threat andSurveillance”, Tech. Rep. James P. Anderson Co., FortWashinton, Pa, 1980.

[3] Smaha, S. E.: “Haystack: An intrusion detection system”,in Proc. of the IEEE 4th Aerospace Computer SecurityApplications Conference, Orlando, FL, Dec. 1988.

[4] D.E. Denning, Neumann P.G.: “Requirements and Modelfor IDES - a real-time intrusion detection expert system”,Tech. Rep., Computer Science Laboratory, SRIInternational, 1985.

[5] Kumar S., “Classification and Detection of ComputerIntrusion” ,M.S. Thesis, Computer Science Dep., PurdueUniversity, Agosto 1995.

[6] “Information Assurance through Defense-in-Depth”Directorate for Command, Control, Communications, andComputer Systems, U.S. Department of Defense JointStaff, February 2000.

[7] Gartner Group: “Gartner Information Security Hype CycleDeclares Intrusion Detection Systems a Market Failure”;2003 Press Release.www.gartner.com/5_about/press_releases/pr11june2003c.jsp

[8] Cormack, A.: “Moore’s Law of Computer Security”; TerenaNetworking Conference 2002; 3-6 June 2002; Ireland.

[9] Staniford-Chen, S.: “Common Intrusion DetectionFramework”; http://seclabs.cs.ucdavies.edu/cidf/.

[10] Verwoerd, T. and Hunt, R., “Intrusion DetectionTechniques and Approaches”, ComputerCommunications, Elsevier, U.K., Vol 25, No 15,September 2002, pp1356-1365.

[11] Roesch M.: “The Snort Intrusion Detection System”;www.snort.org/.

[12] Naval Surface Warfare Center - Dahlgren Lab: “TheShadow Intrusion Detection System”.www.nswc.navy.mil/ISSEC/CID/.

[13] Department of Energy: “The NID Network IntrusionDetection System”; Il sistema è stato ritirato dal6/11/2004. L’accesso alla documentazione è ristretto alpersonale del Dipartimento della Difesa (DoD - USA).

[14] Kumar S., Spafford E. H., “An Application of PatternMatching In Intrusion Detection”, Technical Report,Giugno 1994.

[15] Boyer R. S, Moore J. S.: “A Fast String SearchAlgorithm”. Communications of ACM, 20(10); pp.762-772; Ottobre 1977.



[16] Aho A., Corasic M.: “Fast Pattern Matching: an Aid toBibliographic Search”; Communications of ACM, 18(6),pp. 333-340; Giugno 1975.

[17] Ilgun K., Kemmerer R.A., and Porras P.A., “StateTransition Analysis: A Rule-Based Intrusion DetectionApproach,” IEEE Transaction on Software Engineering, 21,Marzo1995.

[18] Vigna G., Eckmann S.T., and Kemmerer R.A., “The STATTool Suite,” in Proceedings of DISCEX 2000, Hilton Head,South Carolina, Gennaio 2000, IEEE Press.

[19] Forrest S., Hofmeyr S. A., Somayaji A., Longstaff T. A., “Asense of self for Unix processes”, Proceedings of the1996 IEEE Symposium on Security and Privacy, 1996.

[20] Forrest S., Perelson A.S., Allen L., Cherukuri R.,”Self-Nonself Discrimination in a Computer”, IEEE Symposiumon Research in Computer Security and Privacy, 1994.

[21] Forrest S., Perelson A.S., Allen L., Somayaji A.,“Computer Immunology”, Communications of the ACM,40 10), 1994.

[22] Ptacek T., Newsham T.: “Insertion, Evasion, and Denial ofService: Eluding Network Intrusion Detection”. SecureNetwork Inc. Whitepaper, 1998.

[23] RFC 3954: “Cisco Systems NetFlow Services ExportVersion 9” e RFC 3955 “Evaluation of Candidate Protocolsfor IP Flow Information Export (IPFIX)”.

[24] Mogul J. C., Ramakrishnan K. K.: “Eliminating receive live-lock in an interrupt-driven kernel”; in ACM Transactions onComputer Systems; 15(3), Agosto 1997, pp. 217-252.

[25] V. Hauser: THC-LeapCracker (v. 0.1): released by TheHackers’ Choice on 2/10.2004. www.thc.org/.

[26] Wright J.:”The AS-LEAP”; http://asleap.sourceforge.net/.

[27] He C., Mitchell J. C.: “Analysis of the 802.11i 4-WayHandshake”; In Proceedings of the 3rd ACM InternationalWorkshop on Wireless Security (WiSe'04). Philadelphia,PA, Oct. 2004.

[28] Jones E., Le Moigne O.: “OSPF Security VulnerabilitiesAnalysis”; Internet Draft, 1 Dicembre 2004.

[29] Zhao X., Pei D., Wang L., Massey D., Mankin A., Wu F.S., Zhang L.: “An Analysis of BGP Multiple Origin AS(MOAS) Conflicts”; Proc. ACM SIGCOMM InternetMeasurement Workshop; 2001.

ADSL Asymmetric Digital Subscriber LineAG Attribute GrammarBGP Border Gateway ProtocolBRM Bidirectional Rule MatchingCFG (Deterministric) Context Free GrammarCIDF Common Intrusion Detection FrameworkDAT Dynamic Auto TuningDDoS Distributed Denial of ServiceDoS Denial of ServiceFP False Positives rateFN False Negatives rateFSM Finite State MachineGUI Graphic User InterfaceLAN Local Area NetworkIDS Intrusion Detection SystemIETF Internet Engineering Task ForceIPS Intrusion Prevention SystemMOAS Multiple Origin Autonomous SystemPoP Point of PresenceOSPF Open Shortest Path FirstRDS Routing Detection SecurityRE Regular ExpressionsRNA Real-time Network AwarenessSMP Symmetric Multi ProcessorSNMP Simple Network Management ProtocolSOHO Small Office Home OfficeSPID System Photo Intrusion DetectionSTIDE Sequenze Time Delay EmbeddeingWIDS Wireless Intrusion Detection System

— ABBREVIAZIONI

Gerardo Lamastra s i è laureato inIngegneria Informatica presso l’Università degliStudi di Pisa nel 1996 ed ha conseguito i lPerfez ionamento in Ingegner ia dei SistemiInformatici (equipollente al Dottorato di Ricerca)nel 2000. Nel 1999 è stato Research Scholarpresso l’University del North Carolina, ChapelHill, dove ha lavorato sull’analisi degli algoritmi discheduling per sistemi soft real-time. Dal 2000fa parte del Centro di Sicurezza Be-Secure™ di

TILAB, dove si è occupato di Penetration Testing, Forensic Analysised Intrusion Detection.

Luca Viale s i è laureato in Sc ienzedell’informazione presso l’Università degli Studi diTorino nel 1996 ed ha conseguito il masterCOREP in Telecomunicazioni nel 1997. Dal1997 opera in CSELT (ogg i T ILAB) dovein iz ia lmente s i è occupato d i a t t i v i tà d iconformance testing in ambito LAN/WAN. Dal1998 fa parte del Centro di Sicurezza Be-Secure™ di TILAB dove si è dedicato al leproblematiche di sicurezza approfondendo le

conoscenze nel campo della sicurezza delle infrastrutture di rete.Oggi è impegnato su tematiche di innovazione nel settore delletecnologie di rilevamento e contrasto delle intrusioni.


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 corenetwork UMTS nel dominio a commutazione di circuito, così come viene defi-nito nei nuovi rilasci dello Standard 3GPP.Sono quindi descritte le prestazioni di maggior rilievo che caratterizzeranno inuovi rilasci le cui applicazioni commerciali sono previste nell’arco dei prossi-mi tre anni.

1. Introduzione

Le nuove release dello standard 3GPP preve-dono una nuova architettura e l’introduzione inCore Network di nuove funzionalità; la nuova archi-tettura in configurazione split separa il piano dicontrollo da quello di trasporto ed abilita il tra-sporto della voce e della segnalazione su rete ditrasporto a pacchetto; tra le funzionalità più inte-ressanti e di maggior impatto si annoverano:• Dual Access, una modalità con cui è possibile

gest i re accessi radio GSM e WCDMA(Wideband Code Division Multiple Access) congli stessi apparati di core network;

• gli MSC (Mobile Switching Centre) in pool, unnuovo modello architetturale con cui è possibileusare al meglio le risorse e aumentare l'affidabi-lità della rete;

• la TFO/TrFO (Tandem Free/Transcoder FreeOperation) una prestazione che permette di otti-mizzare il trasporto e migliorare la qualità delservizio voce;

• i nuovi scenari di fallback delle videochiamate,nuove procedure con cui si potrà alternare ilservizio voce o video sia per problemi di coper-tura 3G, sia per volere dell’utente.

2. Architettura Split

Lo standard 3GPP, a partire dalla Release 4 (daqui in avanti Rel.4), introduce nel dominio CS (CircuitSwitching) della rete UMTS la separazione tra ilpiano di utente ed il piano di controllo. Tale architet-tura di rete si realizza con la configurazione “Split” o“Layered” in sostituzione di quella “Combined”, conriferimento alle funzionalità di MSC Server e MGW(Media GateWay) del nodo MSC/VLR.

La Rel.4 3GPP prevede infatti la possibilità direalizzare il piano di controllo ed il piano d’utentedel dominio CS in due nodi distinti. Fino ad orainfatti entrambe le funzionalità sono state realizzatenello stesso elemento fisico, ovvero la centraleMSC/VLR.

L’architettura della rete UMTS prevede la con-nessione dell’UTRAN (UMTS Terrestrial RadioAccess Network) con la Core Network tramite l’in-terfaccia Iu, suddivisa in Iu CS e Iu PS, rispettiva-mente per il dominio a circuito e a pacchetto.

Nella architettura di Rel.4 Circuit Switching lostrato di controllo è realizzato nel nodo MSC Serversul quale termina l’interfaccia Iu CS Control plane,mentre il piano d’utente è gestito dal nodo MediaGateway, sul quale termina la Iu CS User Plane.

STANDARD

BELLONI › CECCARELLI › DE GREGORIO • Evoluzione della Core Network UMTS a Circuito


Nella nuova architettura il Server diviene quindiil nodo di rete che gestisce tutto il piano di segna-lazione, in particolare quindi nel Server si realiz-zano i l Session Management ed i l Mobi l i tyManagement. Le informazioni relative alla gestionedella mobilità, alla gestione della chiamata e allainstaurazione dei RAB (Radio Access Bearer) ven-gono elaborate e controllate direttamente dallacentrale Server, che gestisce ovviamente anche ildatabase VLR per i record di utente.

Lo standard prevede una nuova interfaccia peril dialogo tra i nodi MSC Server, l’interfaccia Nc. Ilprotocollo previsto per questa interfaccia è il BICC(Bearer Independent Call Control) o ISUP (ISDNUser Part). Per un approfondimento sul protocolloBICC si veda il relativo riquadro.

La Rel.4 3GPP definisce anche una nuova inter-faccia standard per il dialogo tra Server e MGW.Tale interfaccia, denominata Mc, viene utilizzata dalServer per inviare i comandi necessari alla configu-

Il protocolloBICC

Facendo riferimento alla figura A, ilprotocollo BICC (Bearer IndependentCall Control) è utilizzato per lo scam-bio di informazioni per il set-up dellachiamata tra gli MSC-Server: può tra-sportare, indipendentemente dal tra-sporto sottostante, le informazionicirca le caratteristiche del serviziorichiesto dall’utente, l’identificativodel chiamato (da cui le informazioni diinstradamento) e le informazioni suicodec supportati. Il MGW ha invece ilcompito di instaurare le connessionenel piano d’utente e di attivare lacommutazione: ovviamente questonon può avvenire in maniera tran-sport-agnostic (indipendente dal tipodi rete di trasporto: TDM, ATM, IP) equindi riceve le necessarie informa-zioni dal MSC-Server, le converte ininformazioni per il controllo dello spe-cif ico bearer e si occupa del lagestione dello stesso.La figura A mostra le funzionalità diBICC definite dall’architettura ITU-T ela loro collocazione all’interno dell’ar-chitettura 3GPP di Rel.4. La CSF (CallServing Function) coincide conl’MSC-Server e parla in BICC con glialtri MSC-Server. Il dialogo tra MSC-Server e MGW, o tra CSF e BCF(Bearer Control Function), avvienecon protocollo H.248, definito con-giuntamente da ITU-T e IETF per ilcomando, da parte del MSC-Server,della commutazione di terminazionisul MGW. Il piano d’utente è terminatodalla MMSF (Media Mapping andSwitching Function). Si noti come siaprevista anche una segnalazionepeer-to-peer tra i BCF per il controllodel piano di trasporto, denominata

Bearer Control Protocolche avviene in modalitàdiversa nel caso di tra-sporto ATM o di tra-sporto IP.Nel caso di trasportoATM si utilizza la segna-lazione Broadband-ISUPB-ISUP gia definita daITU-T per al locare lerisorse del canale dedi-cato necessario al lachiamata; in particolarei l protocollo AAL2Connection Signalling èutilizzato per stabilire leconnessioni con unmeccanismo analogo aquello dell’ATM commu-tata (figura B).In un contesto IP, nativa-mente di tipo connectionless, le informazionirelative al le r isorsenecessarie per stabilireun canale bidirezionale

end to end vengono identi-ficate mediante lo scambiofra i nodi di origine e didestinazione degli indirizziIP delle porte e del tipo dimedia richiesto. Questeinformazioni sono traspor-tate in formato SDP(Session DescriptionProtocol) e vengono scam-biate trasparentemente trai due MMSF dal protocolloH.248 e dal protocolloBICC.

MSC server

Physicalunit

MGW

BICC

H.248

Function

Bearer ControlProtocol

Bearer(User Plane)MMSF

MCF

BCF

CSF

BCFBICCCSFMCF

MGWMMSF

MSC

=======

Bearer Control FunctionBearer Independent Call ControlCall Serving FunctionMedia Control FunctionMedia GateWayMedia Mapping/Switching FunctionMobile Switching Centre

FIGURA A› Modello architetturale di BICC ITU-T e

corrispondenza con quello 3GPP.

AAL2 connection signalling (Q.2630.2)

AAL2 Signalling Transport Converter for MTP3b (Q.2150.1)

MTP3b

SSCF-NNI

SSCOP

AAL5

ATM

AAL2AAL5ATMNNI

SSCF

SSCOP

=====

=

ATM Adaptation Layer 2ATM Adaptation Layer 5Asynchronous Transfer ModeNetwork-Network InterfaceService Specific Coordinator FunctionService Specific Connection Oriented Protocol

FIGURA B› Il protocollo AAL2 Connection Signalling.



razione dei device di commutazione sul MediaGateway. Il compito di quest’ultimo è infatti proprioquello di connettere porte di ingresso e di uscita,sulle quali si possono utilizzare differenti tecnologiedi trasporto ATM, IP e TDM (Time Divis ionMultiplex). L’interfaccia Mc viene inoltre utilizzatadal MGW per fornire dei riscontri o eventi al Server.Il protocollo utilizzato su questa interfaccia è H.248.

Il nodo Media Gateway invece realizza la partedi trasporto e di commutazione. Il piano di utentepassa infatti attraverso quest’ultimo, connettendoda un lato la rete di accesso e dall’altro la CoreNetwork. Il nodo realizza sia la commutazione deicanali voce, video e dati CS, sia l’adattamentodelle codifiche impiegate in accesso ed in corenetwork. La funzionalità di transcodifica, realizzatanella rete GSM dalle unità TRAU (Transcoder andRate Adaptor Unit) presenti generalmente sui BSC,nell’architettura 3GPP Rel.4 viene realizzata diret-tamente sul MGW. Il TRAU può anche essere loca-lizzato sia in BSC sia in MSC.

Lo standard prevede una nuova interfaccia Nbanche per il dialogo tra i nodi MGW. Le tecnologieimpiegate per l’interfaccia Nb sono ATM ed IP, oltreal TDM per assicurare compatibilità con le esistentiCore Network.

L’architettura “Split” rende indipendenti i pianidi segnalazione e di trasporto, consentendo unosviluppo separato dei due nodi in accordo aglieffettivi requisiti di banda e di connessione.

Con tale soluzione si possono avere più centraliMGW controllate da un numero inferiore di centraliServer. In questo modo è possibile migrare, tramiteMGW remoti, le funzioni di commutazione verso larete di accesso, effettuandolo switching locale senzaoccupare r isorse di t ra-sporto di rete.

Nella figura 1 sono ripor-tate anche le interfacce Nc eNb come da specifiche dellaRel.4. Nelle prime realizzazionitali interfacce utilizzano la tec-nologia di trasporto TDM.

3. Dual Access

La configurazione DualAccess prevede che gl iaccessi radio 2G e 3G sianocontemporaneamente con-nessi a l medesimo nodoMSC/VLR, ottimizzando ilconcetto di “seamlessnetwork” che prevede com-pleta trasparenza per i lc l iente tra l ’ut i l izzo del lerisorse 2G e 3G.

La configurazione DualAccess offre inoltre interes-santi vantaggi nella gestionedel roaming e nelle proceduredi gestione della mobilità.

In generale infatti, gli accordi esistenti perl’accesso al roaming da parte di utenti visitor nonè lo stesso per le utenze 2G o 3G. Ciò implicache il nodo MSC deve comunque essere in gradodi gestire la mobilità 2G/3G dell’utente impe-dendo che lo stesso possa connettersi all’ac-cesso radio non consentito dagli accordi com-merciali.

Per quanto riguarda la mobilità invece, la possi-bilità di gestire il passaggio da una copertura 3Gad una copertura 2G, e viceversa rimanendo nel-l’ambito della stessa centrale, comporta un’ottimiz-zazione delle risorse di segnalazione di rete.Nell’ipotesi di impianti distinti, il passaggio tra gliaccessi UMTS e GSM comporta, infatti, sempreuno scambio di segnalazione tra MSC/VLR ed ildatabase di HLR, per l’aggiornamento della posi-zione dell’utente in rete.

La possibilità di avere attestate in un’unica cen-trale le due tipologie di accesso consente di:• abilitare la gestione separata dei due accessi

radio per l’utenza in roaming assegnando valoridi location area distinti a celle 2G e celle 3G;

• effettuare contestualmente una gestione dellamobilità più efficiente in termini di risorse disegnalazione rispetto a quella che si ottienecon impianti dedicati per accesso. La presenzadi un unico VLR per la gestione di LocationArea 2G e 3G consente un notevole risparmiodi segnalazione nel passaggio tra le due reti.Infatti, se si pensa alla copertura iniziale dellereti 3G, tale scenario si potrebbe presentaremaggiormente nelle prime fasi di lancio delservizio.

HLR/AuC

HLR/AuC HLR/

AuC

GSM / PSTN / OLO

Core Network UMTS

TransitoGMSC

MSCServer

MSCServer

MGWMGW

RNC

RNC

UTRAN

UTRAN

lub

lub

nodeB

nodeB

nodeB

nodeB

lu CS

ATM/IPTDM

GCP/ATM

Nb

Mc

Nc

ISUP/BICC

D

Mc

lu CS CP

Segnalazioni

Fonia

lu CS UP

ATMAuC

BICCCPCS

GCPGSMHLR

========

Asynchronous Transfer ModeAuthentication CentreBearer Independent Call ControlControl PlaneCircuit SwitchedGateway Control ProtocolGlobal System for Mobile communicationsHome Location Register

ISUPMGWMSCOLO

PSTNRNCTDM

UP

========

ISDN Signalling User PartMedia GateWayMobile Switching CentreOther Licensed OperatorPublic Switched Telephone NetworkRadio Network ControllerTime Division MultiplexUser Plane

FIGURA 1› Relazioni tra Server e Media GateWay.



La scelta di utilizzare per le location area 3G equelle confinanti 2G il medesimo impiantoMSC/VLR minimizza gli impatti dovuti alle diffe-renti aree di copertura delle due tecnologie. Inquesto scenario tecnologico l’aggiornamentodella posizione effettuata nel passaggio tra ledue reti comporta infatti solo lo scambio disegnalazione sulla interfacce tra terminale eMSC/VLR, senza alcun impatto per la corenetwork e per le interfacce di segnalazione deldatabase di HLR.

4. MSC in Pool

In un’ottica di ottimizzazione dell’uso dellerisorse di rete, a partire dalla Rel.5 è stata definitadal 3GPP la funzionalità di “Intra-domain connec-tion of Radio Access Network (RAN) to multipleCore Network (CN) nodes”, denominata più sem-plicemente “MSC in pool”. Originariamente la pre-stazione è stata pensata dal 3GPP per il load sha-ring del traffico d’utente tramite il re-indirizza-mento del la segnalazione di CommunicationManagement CM, ma dal punto di vista dell’ope-ratore ciò può rappresentare anche un ottimostrumento per rendere più affidabile la rete che laimplementa.

In particolare, la funzionalità prevede unamodifica dell’architettura della rete mobile chenormalmente vede un nodo di rete d’accessoradio RNC connesso con un solo nodo di con-trollo della Core Network. La funzionalità è defi-nita per GSM, GPRS, CS domain e PS domain; diseguito per comodità si farà riferimento al domi-nio a circuito.

Nel caso di pooling di MSC, un RNC può essereconnesso a più MSC, come mostrato nella figura 2.

A fronte di questa modifica architetturale,l’MSC in pool prevede una nuova funzionalità inRNC, detta NAS (Non Access Stratum) Selectorche, all’atto della registrazione dell’utente mobile,associa al terminale un nodo di controllo MSC(associazione che era implicita nel caso di corri-spondenza uno a uno tra RNC e MSC). Questaassociazione è effettuata sulla base di un parame-tro di NRI (Network Resource Identifier) a livelloRRC (Radio Resources Control).

La pool area diventa, quindi, un insieme di cellecontrollate da più MSC ciascuno dei quali deveessere connesso a tutti gli RNC che gestisconol’insieme delle celle del pool. Questo pone un vin-colo sulle dimensioni del pool perchè pool controppi MSC richiederebbero un numero di linktroppo elevato.

Inoltre, per limitare questo numero, la funziona-lità prevede che un utente che si sposti all’internodelle celle del pool non effettui le relative proce-dure di Mobility Management, con conseguenteriduzione del traffico di segnalazione.

Si capisce come risulti critica, allora, la sceltadelle dimensioni del pool per trovare il giusto com-promesso tra costi e benefici.

5. Trasporto a pacchetto

Il 3GPP non impone vincoli sul modo di tra-sportare l’informazione nella Core Network dellarete UMTS ma, anzi, lascia un’estrema flessibilitàall’operatore includendo nello standard diverseopzioni. Le tradizional i ret i a circuito legacyPSTN/ISDN ed il GSM sono basate sul trasportoTDM che utilizza una soluzione per il piano di tra-sporto creata per le reti dedicate all’erogazionedel servizio telefonico.

5.1 Trasporto del piano di utente

La voce in UMTS oltre che con la classicamodalità TDM, può essere trasportata su ATM esu IP.

L’ATM è stato incluso nello standard perchèall’inizio dei lavori in sede di standardizzazione erala migliore tecnologia disponibile per l’ottimizza-zione delle risorse di trasporto.

Il trasporto della voce su IP rispetta gli standardper i bassi costi e la semplicità tipiche del mondoInternet. Oggi l’IP sul piano d’utente a circuito èspinto anche dal fatto che il protocollo IP è lachiave per fornire servizi multimediali complessitramite IP Multimedia SubSystem, che è il cuoredella Rel.5 e che, tra l’altro, è interamente basatosu IPv6; inoltre su IP si fondano le attuali tendenzeevolutive del 3G verso il 4G.

Facendo riferimento all’architettura di Rel.4 dicui si parla nel paragrafo 2, le pile protocollari pre-viste sull’interfaccia Nb tra i MGw per il trasportodella voce in Core Network sono riportate nellatabella 1.

MSC 1

CS pool-area 1

CS pool-area 2

PS pool-area 1

RANnode

Area 1

Area 5

Area 2

Area 6

SGSN 1 SGSN 3 SGSN 6

SGSN 4SGSN 5

SGSN 2

RANnode

RANnode

RANnode

Area 3

Area 7

PS pool-area 2

RANnode

RANnode

Area 4

Area 8

RANnode

RANnode

MSC 2MSC 3

MSC 4 MSC 7

MSC 5MSC 6

CSRAN

PSSGSN

====

Circuit SwitchedRadio Access NetworkPacket SwitchedServing GPRS Support Node

FIGURA 2› Architettura di rete che implementa MSC in pool.



Nel caso di trasporto della voce su ATM, ledimensioni di una cella ATM permettono di multi-plare in una stessa i campioni provenienti da piùtelefonate: questo è realizzato dal protocolloAAL2 (ATM Adaptation Layer 2), che definisceopportuni identificativi per distinguere dentro lasingola cella ATM le diverse telefonate. InveceAAL2-Segmentation and Reassembly ServiceSpecific Convergence Sublayer (SAR SSCS) sioccupa della segmentazione e del riassemblaggiodei pacchetti AAL2.

Quando invece il trasporto è in tecnologia IP, siutilizza il Real Time Protocol che rende UDP/IP,tipico per applicazioni best effort, adatto a tra-sportare applicazioni di tipo real-time quale lavoce.

5.2 Trasporto del piano di controllo

Per gestire questa flessibilità nel modo di tra-sportare la voce, il 3GPP ha scelto un protocollo diCC (Call Controll) tra i nodi di controllo che fosseindipendente dal tipo di trasporto utilizzato. Comericordato nel paragrafo 2, si parla di architetturache rispetta il requisito di bearer independence, adifferenza di quanto avviene con l’ISUP delle retilegacy. Infatti, l’ISUP ha il campo di CIC (CircuitIdentification Code) che stabilisce un legame pre-ciso tra la segnalazione e il canale a 64 kbit/s dellatrama PCM.

Nell’architettura split dalla Rel.4 in poi si usacome protocollo tra gli MSC-Server sull’interfacciaNc il BICC.

Il 3GPP ha ereditato il protocollo BICC da ITU-T, che lo ha definito con lo scopo di creare un pro-tocollo per il controllo di chiamata che fosse indi-pendente dalla tecnologia di trasporto utilizzata; inquest’ottica ITU-T ha analizzato il protocollo ISUPe ne ha esteso le funzionalità per prevedere il tra-sporto della voce su ATM e IP.

In particolare, la breve storia della standardizza-zione del BICC si è svi luppata attraverso leseguenti tappe:• 1999, BICC CS-1 (Capability Set 1): bearer

independent architecture e adattamento diISUP per trasporto ATM sul piano d’utente;

• 2000, BICC CS-2: supporto di IP come proto-collo di trasporto sul piano d’utente (compresala definizione di BICC IP BCP e BICC tunnelingprotocol);

• 2001, BICC CS-3: supporto di multimedia com-munication, QoS e interworking con H.323/SIP.

6. Ottimizzazione del trasporto e qualità dellavoce

Lo standard 3GPP ha definito per la rete UMTS(dalla Rel. 4) e per quella GSM (dalla Rel. 98) alcunimeccanismi che permettono sia di migliorare laqualità percepita per una chiamata in fonia, che diottenere contestualmente dei risparmi di bandaoccupata nella “Core Network”.

Entrambe le soluzioni utilizzano la proprietà ditrasmettere trame vocali senza eseguire operazionidi codifica/decodifica delle stesse nella “CoreNetwork”.

Tali meccanismi si suddividono in:• TFO (Tandem Free Operation), la cui applica-

zione consente di evitare le operazioni di codi-fica e decodifica in rete, con conseguentemiglioramento della qualità percepita end toend;

• OoBTC (Out of Band Transcoder Control), abili-tante:

- TrFO (Transcoder Free Operation), che con-sente sia di risparmiare la transcodifica conmiglioramento 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 rateprima di effettuare la transcodifica ad un bitrate più alto.

6.1 TFO (Tandem Free Operation)

Il Tandem Free Operation si applica in scenari dichiamata 2G-2G, 3G-3G e 2G-3G dove sono coin-volte tratte nelle quali si utilizza la codifica PCM a64 kbit/s. L’attivazione della funzionalità consentedi evitare la doppia codifica/decodifica PCM pre-servando, in modalità compressa, la banda cheproviene dalla rete di accesso, e trasportando taleflusso in modo “trasparente” nel canale PCM a 64kbit/s. In questo modo vengono risparmiati duepassaggi di transcodifica, quello da banda com-pressa a PCM, e quello da PCM a banda com-pressa. Il mancato impiego dei transcoder con-sente di r idurre i l tempo di elaborazione delsegnale in rete con conseguente diminuzione delritardo introdotto end to end; ciò permette quindidi offrire una migliore qualità del segnale vocale.

Il TFO è standardizzato in GSM a partire dallaRel.98; per UMTS è definito a partire dalla Rel.4.

La modalità di TFO viene attivata in una fasesuccessiva a quella di set up della chiamata a valledella quale i transcoder impiegati si scambiano

AAL-2 SAR SSCS

AAL-2

ATM

AAL2ATMIPv4RTPSAR

SSCSUDP

=======

ATM Adaptation Layer 2Asynchronous Transfer ModeInternet Protocol v4Real Time ProtocolSegmentation and ReassemblyService Specific Convergence SublayerUser Datagram Protocol

RTP

UDP

IPv4 o IPv6

TABELLA 1› Pile protocollari sull’interfaccia Nb.



trame PCM a 64 Kbit/s, cioè un cam-pione di voce codificato con 8 bit ogni125 µs. Nel momento in cui uno dei duetranscoder tenta di attivare il TandemFree Operat ion, in iz ia a scambiaresegnalazione in banda con l’altro tran-scoder. Lo scambio di segnalazione ha loscopo di comunicare all’altro transcoderla volontà di passare in modalità TFO, equindi di comunicare quale codificatoreimpiegare nella connessione in corso. Sei due transcoder stanno impiegando unacodifica comune o compatibile, si atti-verà la modalità TFO.

In mancanza di un codec comune, èpossibile continuare in modalità normaleuti l izzando la transcodif ica, oppure,mediante procedura di “Codec MismatchResolution” , tentare di negoziare uncodec comune tramite lo scambio delleliste dei codec supportati.

Quando la modalità TFO è attiva, le trame vocalivengono trasmesse utilizzando alcuni degli 8 bitdisponibili del campione PCM, in funzione del bitrate associato al codec comune utilizzato.

I due transcoder non devono più effettuarequindi operazioni di transcodifica, anche se labanda impegnata in rete tra questi ultimi rimanesempre di 64 kbit/s (8 bit utilizzabili per payload eriempimento ogni 125 µs). La modalità di TFO con-sente quindi di migliorare la qualità vocale senzaoffrire un risparmio di banda utilizzata (figura 3).

6.2 OoBTC (Out of Band Transcoder Control)

I l meccanismo di Out of Band TranscoderControl, contrariamente al TFO, consente di nego-ziare già nella fase di instaurazione della chiamata,con segnalazione fuori banda, un’unica codificache permetta di non utilizzare la transcodifica in

rete e di risparmiare, nello stesso tempo, banda ditrasmissione.

Lo standard prevede comunque la possibilità dimodificare il codec selezionato anche nella faseattiva della chiamata in qualsiasi momento, adesempio dopo un handover.

Gli scenari di chiamata a cui si applica l’OoBTCsono gli stessi del TFO, a cui si aggiunge lo scena-rio di chiamata tra rete mobile e rete fissa.

L’OoBTC è definito nello standard 3GPP a par-tire dalla Rel.4.

La modalità di funzionamento dell’OoBTC puòessere compresa facendo riferimento alla figura 4.La centrale di origine O-MSC invia in segnalazione,verso i nodi successivi, la lista dei codec suppor-tati, elencati per ordine di preferenza. Ogni nodo ditransito analizza la lista ed elimina da quest’ultima icodec non supportati, senza alterare l’ordine dipreferenza. Nell’esempio della figura 4, la centraledi Transito elimina dalla lista il codec y in quantonon disponibile nella stessa. Tale analisi vienesvolta da tutti i nodi di transito fino a raggiungerela centrale di terminazione T-MSC. Quest’ultimaseleziona il primo codec supportato della lista diquelli supportati da tutti i nodi coinvolti nella chia-mata. Una volta selezionato, invia a ritroso taleinformazione con la lista contenente i codec alter-nativi ma non selezionati.

Nel caso raffigurato nella figura 4 il codec sele-zionato è il codec x che viene comunicato da T-MSC sia al proprio MGW, che alle centrali Serverattraversate in precedenza dalla segnalazione dicontrollo.

Al termine della procedura quindi tutte le cen-trali Server e MGW coinvolte prevedono l’impiegodell’unico codec comune prescelto x.

Per utilizzare l’OoBTC è necessario che il proto-collo di Call Control supporti lo scambio delleinformazioni relative ai codec supportati. Le speci-fiche 3GPP contemplano come protocollo di CallControl, che supporta la procedura di negoziazionedei codec, il protocollo BICC CS2 (BICC CapabilitySet2) . La condiz ione quindi per i l supporto

MS MSTRAU TRAU

BTS BTSBSC BSCMSC

Abis A A Abis

Campioni PCM 64 kbit/s contenentiframe TFO nei bit meno significativi:- bit di controllo- campioni voce compressi

MSC

BSCBTSMS

MSCTRAU

=====

Base Station ControllerBase Transceiver StationMobile StationMobile Switching CentreTranscoder and Rate Adaptor Unit

FIGURA 3› TFO (Tandem Free Operation) applicato ad uno scenario 2G-3G.

O-MSC Transit T-MSC

O-MGW

Codec list (v,w,x,y,z)Codec list (v,w,x,z)

Selectedcodec = x

Selectedcodec = x

Selectedcodec = x

Bearer establishedBearer

established

Selected codec = x,available list (v,x,z,)

Selected codec = x, available list (v,x,z,)

T-MGW TransitMGW

MGWMSC

OT

====

Media GateWayMobile Switching CentreOrinatingTerminating

FIGURA 4› Modalità di funzionamento di OoBTC (Out of Band

Transcoder Control) per la negoziazione dei codec.



dell’OoBTC è la presenzadel protocollo BICC CS2;eventuali tratte di rete in cuinon è presente tale proto-collo implicano il ricorso allatranscodif ica del la voce,come descritto successiva-mente.

6.2.1 TrFO (Transcoder Free Operation)

Il OoBTC è il meccani-smo che permette la nego-ziazione del tipo di codec edella modalità di codificamediante l ’ impiego disegnalazione fuori banda; èquindi il meccanismo neces-sario al la abil i tazione delTranscoder Free Operation.

I l Transcoder FreeOperation è la possibilità dieffettuare chiamate per lequali non sono presenti nellacomunicazione end to enddevice di transcodifica, oltreai codec della sorgente edella destinazione. In questo modo è possibile tra-smettere trame di voce compressa senza l’inseri-mento di transcoder in rete, permettendo sia unmiglioramento della qualità della voce, in quanto sielimina il ritardo delle due transcodifiche, sia unrisparmio di banda, in quanto l’informazione viag-gia in rete in modalità compressa.

Il TrFO è specificato dallo standard a partiredalla Rel.4. Lo scenario in cui è possibile utilizzarela funzionalità di TrFO è solo quello di chiamata3G-3G. Infatti, negli scenari 2G-2G o di interlavoro2G-3G, nella procedura di OoBTC il TRAU GSMseleziona il codec PCM, che è quello di default perl’accesso GSM. Ciò comporta quindi una bandaoccupata in rete pari a 64 kbit/s, ele relative transcodifiche da PCM abanda compressa (PCM/AMR perla rete 3G), con l’impossibilità diavere la banda trasmessa in moda-lità compressa end to end.

L’architettura di riferimento perla rete UMTS è quella riportatanella figura 5.

6.2.2 Codec at the Edge

L’esempio preso in esame nellafigura 5 prevede che la negozia-zione di un codec comune tra tuttii nodi di rete abbia successo. Puòavvenire però che sia necessarioprevedere nella catena end to endalcune transcodifiche.

Ciò è quanto presentato nelloscenario seguente, in cui viene illu-strato il caso di una chiamata per

la quale non si riesce, con procedura OoBTC, anegoziare un codec comune end to end.

La funzionalità di “Codec at the Edge” utilizzal’OoBTC e consente, nelle situazioni in cui sia ine-vitabile inserire nel percorso della chiamata alcunetranscodifiche, di selezionare i punti migliori in cuieffettuarle; ad esempio le centrali che rappresen-tano il bordo di un dominio di rete entro il quale èpossibile negoziare una codifica comune.

Nella figura 6 è riportato uno scenario di chia-mata nel quale non è possibile selezionare uncodec comune end to end, poichè i nodi di tran-sito dialogano con protocolli che non supportanol’OoBTC, come ad esempio il protocollo ISUP. Il

Control Plane T

ransit

Network

UserPlane

OoB CodecNegotiation

Radio Bearer Radio BearerIu Bearer

Bearer Req Bearer Req Bearer Req

Iu BearerCN bearer

End to end connection



RANAP

RNCME ME

RNCMGW MGW

RANAP

MSCServer

MSCServer

MGWcontrol

MGWcontrol

CNME

MGWMSCOoB

RANAPRNC

=======

Core NetworkMobile EquipmentMedia GateWayMobile Switching CentreOut of BandRadio Access Network Application PartRadio Network Controller

FIGURA 5› Architettura TrFO (Transcoder Free Operation).

MSC

UTRAN UTRAN

TSN TSN MSC

MGWMGW MGW

MGW

ISUP

TRANSIT

Supportedcodecs list (BICC)

(X,Y,Z)

Supportedcodecs list (BICC)

(Y)

G.711Codec (X) Codec (Y)

TDMATM/IP ATM/IP

PLMN 2

Selected codec (BICC)

(X)

PLMN 1

Selectedcodec (BICC)

(Y)

ATMBICCMSCMGWPLMNTDMTSN

=======

Asynchronous Transfer ModeBearer Independent Call ControlMobile Switching CentreMedia GateWayPublic Land Mobile NetworkTime Division MultiplexTransit Network

FIGURA 6› Esempio d’impiego di “Codec at the Edge”.



meccanismo di OoBTC permette quindi di atti-vare in segnalazione la transcodifica da vocecompressa a codifica PCM e viceversa, nei dueMGW di bordo (at the edge) e non di accesso,consentendo il trasporto della voce in modalitàcompressa fino a questi ultimi, con il conse-guente risparmio di banda in rete.

7. Fallback delle Videochiamate

Il 3GPP ha specificato nuove funzionalità pergestire il cambio di servizio da telefonia a video-telefonia e viceversa, sia in fase di setup siadurante la conversazione. La prestazione di reteprincipale va sotto il nome di “Service Changeand Fallback for UDI/RDI multimedia” (SCUDIF).Inoltre è stata specificata anche una soluzione dibreve termine, denominata “Redial”, più sem-plice e basata principalmente su modifiche nelterminale.

7.1 Soluzione Redial

Il meccanismo “Idle Mode Redial” è una combi-nazione del servizio standard voce e del nuovo ser-vizio di videochiamata. Tale soluzione è fondamen-talmente basata su logiche inserite nel terminale. Iprincipali obiettivi della prestazione sono:• alternare voce e video durante una conversa-

zione, per mezzo dell’abbattimento e della suc-cessiva instaurazione dell’altro tipo di servizioverso lo stesso destinatario;

• offrire la chiamata audio, quando la coperturaradio 3G degrada fino al punto di non poteroffrire più il servizio video. In questo caso ilvideo viene rilasciato e viene offerta la possibi-lità di richiamare in audio lo stesso destinatario;

• offrire la chiamata audio, quando il tentativo dichiamata video non va a buon fine.L’obiettivo di tale prestazione è quello di velo-

cizzare la richiamata in video o voce verso lostesso destinatario, mediante un’interfaccia MMI(Man Machine Interface) che renda più semplice edimmediata la procedura. Il 3GPP non specifica laMMI lasciando ai costruttori la libertà di progettaretale interfaccia.

Dal punto di vista della core network, tale pre-stazione è semplicemente vista come due chia-mate che si succedono, una voce e l’altra video,effettuate tra i medesimi utenti.

7.2 Soluzione SCUDIF

I l servizio nominato “Service Change andFallback for UDI/RDI multimedia” (SCUDIF) è unmiglioramento della soluzione Redial e permetteagli utenti di ottenere una chiamata voce quando laconnessione video a circuito end to end non è pos-sibile (scenario di “fallback to speech”). Inoltre èpossibile alternare i servizi voce e quelli videodurante una chiamata. In tutti questi scenari il pas-saggio tra i due servizi avviene senza che la chia-mata iniziale venga abbattuta. La funzionalità

apporta modifiche al terminale e ai nodi di rete,inserendo campi aggiuntivi alla segnalazione disetup della chiamata. La funzione SCUDIF soddi-sferà i seguenti requisiti:• “Fallback to speech” durante l’instaurazione

della chiamata. Nel caso in cui il Setup dellavideochiamata non andasse a buon fine, la reteproverà a negoziare su entrambi gli utenti lachiamata voce.

• Alternare il servizio voce e video. Una chiamatavoce può trasformarsi in video e viceversa,mediante una procedura invocata dall’utente.

• Permettere ad un utente di rifiutare o meno unavideocall richiesta dall’altro utente, mentre si èconnessi in modalità voce.

• Cambiare il servizio voce/video iniziato darete. La rete potrà invocare un cambio di ser-vizio durante una videochiamata, se questonon può più essere supportato (ad esempioper la copertura radio 3G non più sufficiente)e trasformare il servizio in voce su 2G. Se lavideochiamata può nuovamente essere sup-portata, la rete può invocare nuovamente uncambio di servizio per ritornare al serviziovideo.Nel messaggio di setup, i l terminale chia-

mante indica il supporto della feature SCUDIF eind ica le BC (Bearer Capabi l i ty ) disponib i l i(speech e video). Le stesse BC vengono inviateal terminale ricevente. Sia in origine che in desti-nazione è necessario che i servizi siano sotto-scritti nei relativi profili d’utente in HLR. Il termi-nale ricevente rimanda indietro alla rete, comeconferma di negoziazione, la lista delle BC sup-portate. Se la negoziazione ha come risultato unBC diversa da quella richiesta dal terminale chia-mante viene avviata una procedura di “In-callmodification”, dalla rete verso il terminale di ori-gine.

In ogni momento della conversazione saràpossibile cambiare il servizio da voce a video eviceversa, mediante comandi su terminale cheattivano poi la procedura di “In-call modification”.Nella figura 7 è riportato il flusso di messaggi

Modify (BCb)

UE A MSC A MSC B UE B

Modify (BCb)

Modify complete (BCb)

Core Networkprocedure

Core Networkprocedure

Modify complete (BCb)

BCbMSC

UE

===

Bearer CapabilityMobile Switching CentreUser Equipment

FIGURA 7› Richiesta di cambio di servizio voce/video.



della procedura di “In-call modification”. Come sipuò vedere i nuovi messaggi non riguardano solol’accesso radio, ma anche le procedure di CoreNetwork tra la rete di origine e quella di destina-zione.

8. Conclusioni

L’evoluzione del le funzional i tà del la CoreNetwork UMTS, mostrate nel presente articolo,riflette lo stato di maturità della tecnologia GSMe UMTS. Infatti, la Core Network UMTS eredita inbuona parte la ben consolidata tecnologia GSM,in aggiunta alla quale sono state create nuovefunzionalità tipiche del 3G (per esempio la video-chiamata).

Quindi, l’evoluzione della core network è com-posta, in parte, da nuove funzionalità volte adottimizzare una rete già ben collaudata aumen-tandone l’affidabilità e riducendone i costi, ed inparte, da nuove funzionalità al fine di renderedisponibili nuovi scenari di servizio per la tecno-logia 3G.

— BIBLIOGRAFIA

AAL2 ATM Adaptation Layer 2ATM Asynchronous Transfer ModeAuC Authentication CentreBCb Bearer CapabilityBCF Bearer Control FunctionBICC Bearer Independent Call ControlBSC Base Station ControllerBTS Base Transceiver StationCC Call ControlCCS7 Canale Comune 7CIC Circuit Identification CodeCM Communication ManagementCN Core NetworkCS Circuit SwitchedCP Control PlaneCSF Call Serving FunctionGCP Gateway Control ProtocolIMS IP Multimedia SubsystemIP Internet ProtocolISDN Integrated Service Digital NetworkISUP ISDN User PartMCF Media Control FunctionME Mobile EquipmentMGW Media GateWay

— ABBREVIAZIONI

[1] TR 23.821 Architecture Principles for Release 2000

[2] TS 02.53 Tandem Free Operation (TFO); Servicedescription; Stage 1 (GSM)

[3] TS 03.53 Tandem Free Operation (TFO); Servicedescription; Stage 2 (GSM)

[4] TS 08.62 Inband Tandem Free Operation (TFO) ofSpeech Codecs; Service Description; Stage 3 (GSM)

[5] TS 22.053 Tandem Free Operation (TFO); Servicedescription; Stage 1

[6] TS 23.053 Tandem Free Operation (TFO); Servicedescription; Stage 2

[7] TS 28.062 Inband Tandem Free Operation (TFO) ofspeech codecs; Service description; Stage 3

[8] TS 23.153 Out of band transcoder control; Stage 2

[9] TS 25.953 Transcoder Free Operation

[10] TR 23.903 Redial solution for voice-video switching

[11] TS 23.172 Technical realization of Circuit Switched (CS)multimedia service; UDI/RDI fallback and service modifica-tion; Stage 2

[12] TS 23.236 Intra-domain connection of Radio Access Network(RAN) nodes to multiple Core Network (CN) nodes

[13] TS 23.205 Bearer-independent circuit-switched corenetwork; Stage 2

[14] TS 29.414 Core Network Nb Data Transport andTransport Signalling

[15] TS 29.205 Application of Q.1900 series to bearer inde-pendent Circuit Switched (CS) core network architecture;Stage 3

[16] ITU-T Q.1902.1: “Bearer Independent Call Control CS2Functional Description”

[17] ITU-T Q.1902.2: “Bearer Independent Call Control CS2General Functions of Messages and Signals”

[18] ITU-T Q.1902.3: “Bearer Independent Call Control CS2Formats and Codes”



MMSF Media Mapping/Switching FunctionMS Mobile StationMSC Mobile Switching CentreMTP Message Transfer PartNAS Non Access StratumNNI Network-Network InterfaceNRI Network Resource IdentifierOoBTC Out of Band Transcoder ControlPCM Pulse Code ModulationPS Packet SwitchedPSTN Public Switched Telephone NetworkQoS Quality of ServiceRAB Radio Access BearerRAN Radio Access NetworkRANAP RAN Application PartRDI Restricted Digital InformationRNC Radio Network ControllerRRC Radio Resources ControlRTP Real Time ProtocolSAR Segmentation and ReassemblySSCS Service Specific Convergence SublayerSIP Session Initiation ProtocolSDP Session Description ProtocolSGSN Serving GPRS Support NodeSSCF Service Specific Coordination FunctionSSCOP Service Specific Connection Oriented

ProtocolTDM Time Division MultiplexTFO Tandem Free OperationTMSI Temporary Mobile Subscriber IdentityTrFO Transcoder Free OperationTRAU Transcoder and Rate Adaptor UnitTSN Transit NetworkUDI Unrestricted Digital InformationUDP User Datagram ProtocolUE User EquipmentUP User PlaneUTRAN UMTS Terrestrial Radio Access NetworkWCDMA Wideband Code Division Multiple Access

Paolo Belloni si è laureato nel 1995 conlode i n I ngegne r i a E le t t ron ica p ressol’Università degli Studi di Pavia. Dalla fine del1996 l avo ra p resso T I LAB (g i à CSELT ) ;i n i z i a lmen te s i è occupa to d i t es t i ng edin teg raz ione d i r e te GSM/GPRS ed hapartecipato al progetto di messa in campode l l a Re te d i Segna laz ione Naz iona le d iTelecom Italia; dal 2000 segue le tematicheine ren t i a l s i s tema UMTS ed a l l a sua

evoluzione. Oggi, nel gruppo di Network Innovation/Mobile CoreNetwork si occupa di aspetti architetturali e di standardizzazionedella Core Network UMTS; è impegnato in progetti di consulenzaverso TIM ed è delegato del gruppo Telecom Italia al consorzio3GPP per la standardizzazione della Core Network UMTS.

Daniele Ceccarelli si è laureato conlode in Ingegner ia del le Telecomunicazionipresso l ’Università degl i studi di Roma “LaSapienza” nel 1999. È stato assunto in TIM nel2000 nella area di Commutazione, tecnologieed industrializzazione di core network, dove hainiziato a seguire le tematiche di Voice over IPe di trasporto della segnalazione su IP nellarete TIM. Dal 2001 collabora al progetto diintroduzione del la tecnologia UMTS di core

network, seguendo gli aspetti legati al dominio a circuito, e aglialgoritmi di autenticazione in rete. Sempre dal 2001 collabora conla scuola SSGRR a i cors i d i formaz ione specia l is t ica per i lpersonale TIM su tecnologie di core network (progetto interno T5).È attualmente impegnato nelle tematiche di evoluzione e sviluppodella rete UMTS di TIM, con riferimento alle nuove architetture dicore CS e alle sue funzionalità/servizi (videochiamata).

Maurizio de Gregorio si è laureato nel1996 con lode in Ingegneria Elettronica pressol’Università di Firenze. Nel 2004 ha conseguitoun p rog ramma d i Mas te r o f Bus inessAdministration presso la University of Malta.Dal 1997 ha maturato esperienze nell’ambitodelle telecomunicazioni presso varie aziende diTLC t ra cu i T I LAB, I n fos t rada e T IM. Halavo ra to va r i ann i ne l l e a ree tecn icheoccupandosi di nuove tecnologie e servizi per

la rete fissa, rete mobile 2G/3G e internet, recentemente si èspostato nel l ’area di Marketing Consumer dove si occupa diproject management di servizi innovativi.

Notiziario Tecnico - Italiano

Documents

Transcript of Notiziario Tecnico - Italiano