evoluzionesegnalazione

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

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

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

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

evoluzionesegnalazione

Documents