Universit` a degli Studi di Padova Corso di Laurea in Informatica Implementazione dell’interfaccia I uH per il supporto alle femtocelle Autore Umberto Corponi Relatore Co-relatore Prof. Claudio Enrico Palazzi Ing. Gianluca Verin A.A. 2011/12
Universita degli Studi di Padova
Corso di Laurea in Informatica
Implementazione dell’interfaccia IuH per
il supporto alle femtocelle
Autore
Umberto Corponi
Relatore Co-relatore
Prof. Claudio Enrico Palazzi Ing. Gianluca Verin
A.A. 2011/12
UNIVERSITA DEGLI STUDI DI PADOVA
Abstract
Dipartimento di Matematica
Implementazione dell’interfaccia IuH per il supporto alle femtocelle
di Umberto Corponi
Questa tesi riguarda l’implementazione dei protocolli dell’interfaccia IuH e della sua
integrazione nel sistema PRIMO. Quest’interfaccia fa parte del sistema di telecomuni-
cazione mobile UMTS ed e necessaria al supporto delle Femtocelle, stazioni radio base
di ultima generazione dalle ridotte dimensioni che consentono di portare il segnale della
rete cellulare direttamente nelle abitazioni degli utenti.
Indice
Abstract iii
Abbreviazioni vi
1 Introduzione 1
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Il sistema PRIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Il progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 L’evoluzione della telefonia mobile . . . . . . . . . . . . . . . . . . . . . . 3
2 Architettura del sistema di telefonia mobile UMTS 7
2.1 Protocolli e Interfacce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 User Plane and Control Plane . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 AccessStratum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Scomposizione architetturale del network . . . . . . . . . . . . . . . . . . 11
2.2.1 User Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.1 UICC e USIM . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1.2 Mobile Equipment . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Radio Access Network . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2.1 Nodi dell’UTRAN . . . . . . . . . . . . . . . . . . . . . . 15
Node B (NB) . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Radio Network Controller (RNC) . . . . . . . . . . . . . . . 16
2.2.2.2 Interfaccie del sistema UTRAN . . . . . . . . . . . . . . . 16
2.2.2.3 Funzioni dell’UTRAN . . . . . . . . . . . . . . . . . . . . 16
2.2.3 Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.3.1 Separazione tra CS-Domain e PS-Domain . . . . . . . . . 18
Elementi del CS-Domain . . . . . . . . . . . . . . . . . . . . 20
Elementi del PS-Domain . . . . . . . . . . . . . . . . . . . . 20
Elementi Condivisi . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Femto Access Point o Femtocelle . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Integrazione delle Femtocelle nell’architettura UMTS . . . . . . . . . . . . 23
2.5 L’Interfaccia IuH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.1 Control Plane protocol stack . . . . . . . . . . . . . . . . . . . . . 26
2.5.2 Security protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.3 CS/PS Userplane protocol stak . . . . . . . . . . . . . . . . . . . . 28
iv
Contenuti v
3 Il Progetto 30
3.1 Obiettivi e vincoli del progetto . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 IuH control plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1 Il protocollo HNBAP . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.2 Il protocollo RUA . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 Implementazione della libreria . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.0.1 Abstract Syntax Notation One . . . . . . . . . . . . . . . 35
3.3.0.2 Compilatore ASN.1 di terze parti . . . . . . . . . . . . . 38
3.3.1 Struttura delle librerie di gestione dei protocolli . . . . . . . . . . . 42
4 Validazione e testing 44
4.1 Verifica del codice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Tool per l’analisi statica:. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Tools per l’analisi dinamica:. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Validazione e test di integrazione . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 L’emulazione della femtocella . . . . . . . . . . . . . . . . . . . . . 46
4.2.2 Test finale di interoperabilita . . . . . . . . . . . . . . . . . . . . . 47
5 Conclusioni 50
A Riferimenti esterni alle specifiche di implementazione 52
Bibliografia 53
Abbreviazioni
ETSI European Telecommunications Standards Institute
3GPP 3rd Generation Partnership Project
2G 2nd Generation
3G 3rd Generation
GSM Global Ssystem for Mobile comunication
GPRS General Packet Radio Service
EDGE Enhanced Data for Global Evolution
HSPA High Speed Packet Access
UMTS Universal Mobile Telecomunication Service
WCDMA Wideband Code Division Multiple Access
CN Core Network
RAN Radio Access Network
GRAN GSM Radio Access Network
GERAN GSM EDGE Radio Access Network
UTRAN Universal Terrestrial Radio Access Nnetwork
CS Circuit Switched
PS Packet Switched
AS Access Sstratum
NAS Non Access Stratum
NB Node B
RNS Radio Network Subsystem
RNC Radio Network Controller
HNB Home Node B
HNBGW Home Node B GateWay
BTS Base Transereceiver Station
vi
Abbreviazioni vii
RNC Radio Nnetwork Controller
MSC Mobile Switching Center
HLR Home Location Register
VLR Visitors Location Register
SGSN Serving GPRS Support Node
GGSN Gateway GPRS Support Node
HSS Home Subscriber Server
ME Mobile Equipment
UE User Equipment
SIM Subscriber Identity Module
USIM UMTS Subscriber Identity Module
UICC Universal Integrated Circuit Ccard
IMSI International Mobile Subscriber Identity
IMEI International Mobile Equipment Identity
ASN.1 Abstract Syntax Notation, One
PDU Packet Data Unit
RUA RANAP User Adaptation
HNBAP Home Node B Application Part
RANAP Radio Access Network Application Part
A tutti quelli che mi hanno giustamente scocciato affiche portassi atermine quest’opera. . .
viii
Capitolo 1
Introduzione
1.1 L’azienda
Athonet SRL, l’azienda presso la quale e stata svolta l’attivita di tirocinio, e una startup
italiana specializzata nelle reti di telecomunicazione mobili con competenze nello svilup-
po di software dedicato alla loro costruzione e gestione. Puo vantare diversi brevetti
internazioneli legati alle tecnologie mobile, oltre che la redazione di articoli e papers, e
alla partecipazione di talk a diversi eventi e conferenze internazionali. La compagnia ha
inoltre maturato una considerevole esperienza nel marketing e vendita di prodotti per la
comunicazione mobile presso alcuni dei maggiori operatori mobili, guadagnandosi una
menzione da parte di Nokia Siemens Network (NSN) per l’eccellenza nell’uso dei loro
prodotti [1], [2].
Recentemente i fondatori sono stati premiati con la medaglia del Presidente della Repub-
blica per meriti nel settore del digitale per la sostenibilita nel corso del Nuvolaverde Day
[3], grazie al supporto offerto alla Protezione Civile del Friuli a seguito dell’emergenza
causata dai terremoti in Emilia [4].
1.2 Il sistema PRIMO
Il sistema PRIMO (Private Mobile) sviluppato interamente all’interno dall’azienda ed
attualmente in fase di commercializzazione , e un prodotto software che implementa i
protocolli e i componenti di rete necessari alla costituzione di una rete di telefonia mobile
completa, in scala ridotta.
La soluzione e studiata per fornire un servizio cellulare che possa risolvere i problemi di
congestione o di totale assenza di connettivita, che si sperimentano in caso di emergenze
1
Capitolo 1. Introduzione 2
sulle reti mobili attuali. Le ridotte dimensioni, i costi limitati e la rapidita di instal-
lazione la rendono adatta ad essere impiegata in molti contesti sia ad uso privato che per
il servizio pubblico, come ad esempio nelle strutture aereoportuali, poli industriali, os-
pedali, manifestazioni e zone rurali, e puo rappresentare una risorsa fondamentale nelle
situazioni emergenziali per le forze di pubblica sicurezza.
1.3 Il progetto
Durante il 2010 il 3rd Generation Partnership Project (3GPP), un’unione di enti stan-
dardizzazione legati all’ambito delle telecomunicazioni, ha rilasciato le specifiche per
l’integrazione un nuovo elemento nell’infrastruttura di telecomunicaziome mobile, gli
Home NodeB o Femto Access Point. Questi sono una versione miniaturizzata e dalle
capacita ridotte che integra le antenne egli apparati dei radio network UMTS utilizzati
per fornire i servizi di telefonia cellulare di terza generazione.
L’obiettivo di questo strumento e quello di portare il segnale dell’operatore direttamente
presso l’utente finale, appoggiandosi alla connessione DSL per far transitare il traffico
verso l’esterno.
L’integrazione di questi apparecchi nel sistema PRIMO permette un’ulteriore passo
in avanti verso la riduzione delle sue dimensioni, pertanto l’azienda e interessata ad
intrudurre il supporto di tale tecnologia nel prodotto esistente.
Obiettivo dello stage e quindi l’implementazione dei protocolli necessari ad offrire il
supporto alle femtocelle al fine dell’integrazione di queste ultime nel sistema esistente.
• Studio del sistema di telecomunicazioni UMTS :
la prima fase richiede un’analisi preliminare della complessa architettura dei sistemi
di telecomunicazione mobile per avere una visione globale del sistema ed avere una
chiara idea degli obiettivi da raggiungere e delle componenti con le quali si dovra
interagire.
• Studio dell’interfaccia di comunicazione IuH :
e richiesta una conoscenza dettagliata dello standard che regola le interazioni
che intercorrono tra le femtocelle ed il network per poter valutare correttamente
l’impatto che queste avranno nel sistema.
• Studio della struttura del sistema PRIMO :
per poter pianificare l’integrazione delle nuove funzionalita deve essere analizza-
ti i meccanismi che regolano il prodotto da estendere. La loro comprensione e
necessaria per ridurre al minimo le modifiche da apportare al software esistente,
Capitolo 1. Introduzione 3
sviluppando un modulo il quanto piu possibile compatibile con le API interne gia
presenti nel sistema.
• Implementazione dei protocolli RUA ed HNBAP ed integrazione:
la fase di sviluppo richiedera l’implementazione dei protocolli di comunicazione
RUA ed HNBAP, introdotti dall’interfaccia IuH . Le procedure di encoding e
decoding dei messaggi richiederanno inoltre lo studio e l’utilizzo di un apposi-
to framework richiesto per la manipolazione della notazione ASN.1 attraverso la
quale lo standard definisce il formato dei messaggi scambiati. Al termine dell’im-
plementazione i moduli prodotti dovranno essere integrati nel sistema esistente.
• Testing delle funzionalita introdotte:
ultima fase del progetto e la verifica della corretta implementazione ed integrazione
dei nuovi moduli. E richiesta la realizzazione di test automatizzati per la verifica
della correttezza e della stabilita del codice. Verra inoltre eseguito un interoper-
ability test, per verificare la compatibilita del sistema sviluppato con gli apparecchi
in commercio rilasciati da differenti produttori.
1.4 L’evoluzione della telefonia mobile
Le origini della comunicazione mobile cellulare risalgono alla meta degli anni 80. Quel-
la che adesso viene definita la tecnologia 1G, o di prima generazione, si basava sulla
trasmissone radio dei dati in via analogica o semi-analogica (solamente lo switching in
alcuni casi avveniva tramite sistemi digitali). Alcuni esempi ne sono l’American Mobile
Phone System (AMPS) sviluppato dai BellLabs negli USA, ed il lo standard aperto
Nordic Mobile Telephone (NMT) in nord Europa, il cui successo fu alla base dell’es-
pansione di Nokia ed Ericsson. Queste reti offrivano servizi focalizzati principalmente
sulla comunicazione vocale, mentre il supporto al traffico dati era limitato ad elementari
servizi di messaggistica testuale, precursori degli SMS, che spesso richiedevano moduli
di espansione aggiuntivi da collegare agli apparecchi mobili.
Il limite principale posto da questi sistemi era la reciproca incompatibilita data dalle
differenti implementazioni a livello nazionale e della sostanziale assenza di specifiche
condivise e di pubblico dominio. Con l’espandersi del mercato e dell’avanzare della
globalizzazione fu necessario trovare degli accordi per sviluppare una rete mobile che si
estendesse oltre i confini dei singoli stati. Gli enti di standardizzazione internazionale
all’inizio degli anno ’90 si unirono per redigere le specifiche di quelli che ora sono definiti
i sistemi di seconda generazione (2G). Sebbene lo scopo di questa collaborazione fosse
quello di garantire l’interoperabilita tra i network, a causa dei diversi interessi commer-
ciali naquero molteplici standard che vennero applicati livello regionale, che resero vano
Capitolo 1. Introduzione 4
il tentativo di stabilire uno standard unico a livello globale.
Questi nuovi sistemi, GSM, CDMA-one, PDC, iDEN e D-AMPS, offrivano servizi piu
avanzati rispetto a quelli della generazione precedente: un uso piu efficente delle frequen-
ze basato su modulazione digitale permetteva di servire un maggior numero di utenti,
l’introduzione della cifratura delle comunicazioni ne incrementava la sicurezza e il miglio-
ramento del supporto al servizio dati dava vita al sistema SMS.
Tra i sistemi sviluppati, lo standard GSM (Global System for Mobile Communications
1), utilizzato in Europa e svilluppato dall’ETSI (European Telecommunications Stan-
dards Institute), si dimostro quello di maggior successo tanto da diffondersi nel tempo
in diverse altre aree come Stati Uniti, Australia e diversi paesi asiatici, conquistando la
maggior parte dei mercati a livello globale.
Durante tutti gli anni 90 e fino ai primi anni successivi al 2000 le tecnologie 2G con-
tinuarono ad evolversi, migliorando sempre piu l’efficenza della modulazione radio e
offrendo un sempre piu esteso supporto ai servizi dati. Con l’adozione della tecnoligia
GPRS (General Packet Radio Service) da parte della rete GSM, venne affiancato alla
tradizionale commutazione a circuito dei flussi voce, (tipica della telefonia fissa) la ca-
pacita di trasmettere dati con commutazione a pacchetto, (tipica della rete internet) con
velocita tra i 50 e i 100 kbps. Tra le applicazione introdotte con il GPRS, vi sono il Mul-
timedia Messaggin Service (MMS), lo standard Wireless Application Protocol (WAP)
e, di fondamentale importanza, l’accesso diretto alla rete Internet via connessione mo-
bile. Una successiva evoluzione dello standard chiamata Enhanced Data rates for GSM
Evolution (EDGE), porto il data rate delle connessioni mobili fino 235 kbps. Queste tec-
nologie, GPRS ed EDGE, per l’importanza che hanno rivestito nella transizione verso la
generazione successiva vengono identificate come 2.5G e 2.75G, denotando l’importante
evoluzione nei confronti del sistema originario.
Verso la fine degli anni ’90 l’International Telecommunication Union (ITU), l’agen-
zia delle Nazioni Unite dedicata all’ICT, pubblica lo standard International Mobile
Telecommunications-2000 (IMT-2000) per la terza generazione (3G) di sistemi mobili.
La definizione e lo sviluppo di questi sistemi viene affidata al 3rd Generation Partner-
ship Project (3GPP) che nacque nel dicembre 1998 quando gli enti di regolamentazione
e standardizzazione appartenenti a diverse aree geografiche, ETSI incluso, siglarono il
3rd Generation Partnership Project Agreement.
L’obiettivo di questa collaborazione era quello di redigere le specifiche per un nuovo sis-
tema che soddisfacesse lo standard IMT-2000, che fosse basato sul preesistente sistema
GSM e con questo interoperabile, che riuscisse ad imporsi e a diffondersi su scala globale
completando quel processo di internazionalizzazione che non si era rcompiuto durante
la standardizzazione dei sistemi della precedente generazione.
1Originariamente il significato dell’acronimo era Groupe Special Mobile
Capitolo 1. Introduzione 5
Figura 1.1: L’evoluzione dei sistemi di telecomunicazione mobili.
Il nuovo standard in Europa, sotto la direzione dell’ETSI, ha preso il nome di Universal
Mobile Telecommunications System (UMTS), e come per il GSM, e di dominio pubblico
e liberamente consultabile tramite il portale web del 3GPP 2.
I risultati ottenuti dall’UMTS, pur non rispettando appienno le aspettative riguardanti
la diffusione, sono stati piu che soddisfacenti; il sistema sviluppato e stato accolto in
modo positivo, ed e infatti attualmente in uso in Europa, Cina, Giappone e si e diffuso
capillarmente in molte regioni nelle quali la tecnologia GSM era predominante.
La fondamentale innovazione portata dal sistema UMTS e stata la migrazione dal proto-
collo radio TDMA (Time Division Multiple Access) della rete GSM a quello W-CDMA
(Wideband Code Division Multiple Access) che ha incrementato notevolmente l’efficen-
za spettrale aumentando la banda a disposizione degli utenti. Con velocita di trasfer-
imento che vanno dai 300 kbps delle prime versioni dello standard, ad oltre 14 Mbps
con l’evolozuine High Speed Packet Access (HSPA), e stato possibile introdurre servizi
multimediali all’offerta degli operatori: videochiamata, mobile-tv, video on demand e
servizi location-based. Un’altra innovazione importante del del sistema UMTS e stata
l’introduzione di un rinnovato e piu rigido sistema di sicurezza e cifratura dei dati, reso
necessario dalle molteplici falle rilevate nel sistema GSM.
Un fattore rilelvante che ha e contribuito alla diffusione delle tecnologie 3G e stata
2Archivio degli standard rilasciati dal 3GPP: http://www.3gpp.org/specifications
Capitolo 1. Introduzione 6
la retrocompatibilita con la rete preesistente. La nuova architettura ha permesso in-
fatti un aggiornamento graduale e mirato del network consentendo agli operatori del
settore l’introduzione graduale dei nuovi servizi e sistemi. Con investimenti graduali
dapprima nelle zone economimcamente piu vantaggiose, rappresentati dai centri urbani,
e in seguito nelle zone a minor densita, la lenta migrazione da un sistema all’altro non
ha presentato interruzioni nel servizio per gli utenti, grazie alla capacita dei terminali
UMTS di operare indistintamente con copertura radio di entrambe le tecnologie. Ad
oggi, benche la transizione sia in corso da lungo tempo i sistemi di seconda generazione
servono ancora la maggior parte degli utenti. Le stime della fine del 2011 indicano che
approssimativamente 1 miliardo di utenti dispongono di una connessione mobile di terza
generazione, circa il 20% delle sottoscrizioni; a livello globale il numero di utenze sfiora
i 5 miliardi [5].
Il sistema UMTS e tuttora in evoluzione; alla prima versione dello standard, chiama-
ta Release99 ne sono seguite molte altre: Release4, Release5, Release6... Attualmente
l’ultima release stabile delle specifiche e la Release10. Allo stesso tempo sono in fase di
sviluppo i sistemi di quarta generazione (4G), che proprio in questo periodo si stanno
affacciando al mercato.
Capitolo 2
Architettura del sistema di
telefonia mobile UMTS
The philosophy of UMTS is to separate the user plane from the control plane,
the radio network from the transport network, the access network from the
core network, and the access stratum from the non-access stratum.
UMTS Signalling; R. Kreher and T. Ruedebusch[6]
La standardizzazione effettuata dal 3GPP riguardana tutti gli aspetti della rete di tele-
fonia mobile: l’architettura generale del sistema, le specifiche della sua parte radio e
degli apparati di controllo, nonche i requisiti dei terminali mobili, il tutto per garantire
la compatibilita su scala globale tra le apparecchiature dei vari produttori ed operatori.
Questi sistemi per loro natura hanno un’estensione tra il grande e l’enorme, richiedono
di poter operare senza rilevanti interruzione di servizio per anni, e devono garantire
l’interoperabilita e il supporto alle le precedenti apparecchiature anche dopo consistenti
aggiornamenti tecnologici. Queste esigenze portano l’architettura del sistema e gli stan-
dard che la descrivono ad avere un elevato livello di complessita. Appare quindi evidente
la necessita, enfatizzata dal 3GPP, di mantenere una chiara separazione funzionale tra
vari livelli dell’architettura sia dal punto di vista logico che da quello fisico. In questo
capitolo verranno brevemente descritti gli elementi fondamentali del network 3G UMTS
e la loro organizzazione in modo da poter averne una visione panoramica.
Una rappresentazione sommaria di come e concettualmente suddiviso il sistema e disponi-
bile alla figura 2.1.
7
Capitolo 2. La rete di telefonia mobile UMTS 8
Figura 2.1: Suddivisione logica del sistema UMTS.
2.1 Protocolli e Interfacce
Ogni entita nel network comunica con quelle ad essa connesse tramite uno stack di
protocolli, ognuno dedicato ad un compito ben preciso. I protocolli descrivono una certa
quantita di messaggi che possono essere scambiati tra i vari peer, e le azioni che ogni
peer deve intraprendere alla ricezione di tali messaggi. Ogni peer che partecipa alla
comunicazione e incaricato di interpretare i messaggi in arrivo, processarli eseguendo le
azioni richieste, e se necessario rispondere opportunamente come indicato nelle procedure
definite dalle specifiche del protocollo. I protocolli definiscono quindi un linguaggio
comune tra due enti distinti per lo scambio reciproco di informazioni, spesso legate alla
richiesta di particolari servizi da parte di uno dei partecipanti. Nella maggior parte dei
casi per la comunicazioni vengono utilizzati piu protocolli distinti raggruppati in quello
che si chiama uno stack ossia una serie di protocolli impilati ordinatamente tra loro
che cooperano per fornire uno specifico servizio che viene offerto dalla parte piu alta
dello stack. I protocolli ai livelli piu bassi della pila offrono le funzionalita necessarie al
funzionamento dei protocolli di livello superiore.
Ogni specifico stack di protocolli tra un nodo e l’altro del sistema definisce quella che
nel contesto delle telecomunicazioni viene chiamata un’interfaccia.
Differenti interfaccie sono presenti nel sistema UMTS: Iu , Uu, IuB, IuR, Gr, etc. Per farsi
un’idea di come sono composte le interfacce e gli stack di protocolli che ne fanno parte
si puo fare riferimento alle figure 2.14 e 2.16 che rappresentano una parte consistente
delle interfaccie Iu e IuH .
Capitolo 2. La rete di telefonia mobile UMTS 9
Figura 2.2: L’architettura del sistema UMTS, Release 99.
2.1.1 User Plane and Control Plane
Molto spesso gli stack protocollari utilizzati nelle interfaccie del sistema UMTS preve-
dono che ad uno stesso livello coesistano una coppia di protocolli strettamente legati che
cooperano per offrire il servizio che il layer deve offrire. Uno dei due protocolli si occupa
della gestione delle funzionalita del layer mentre l’altro fornisce effettivamente il servizio,
che spesso consiste nel trasporto di pacchetti tra i layer superiori ed inferiori. Nell’ar-
chitettura si possono quindi distinguere due flussi paralleli, quello dedicato la parte di
segnalazione, il Control Plane e quello che si occupa di far transitare i dati tra un livello
e l’altro, o tra un entita e l’altra, chiamato User Plane. I messaggi appartenenti al lato
di controllo, sono dedicati a coordinare l’accesso alle funzionalita del secondo, e non
vengono mai propagati o reindirizzati livelli superiori nella forma originale. Le azioni
compiute alla ricezione dei messaggi di controllo hanno generalmente effetto sulla parte
userplane del layer e/o sui livelli superiori attraverso meccanismi di callback. La parte
userplane del layer e il protocollo ad essa dedicato si occupano di trasmettere in modo
trasparente i dati raw tra il livello superiore e quello inferiore e viceversa.
I dati trasportati dallo userplane di un protocollo, come si puo vedere nella figura 2.3
saranno composti da messaggi che per il layer superiore potranno essere, a seconda
Capitolo 2. La rete di telefonia mobile UMTS 10
Figura 2.3: Separazione dei Layer in Control Plane e User Plane.
dell’occasione, sia di controllo che di tipo user. Sara responsabilita di quest’ultimo
discriminare queste informazioni e trattarle in modo opportuno.
Questa divisione dei compiti e di notevole impatto nell’architettura e fornisce grande
flessibilita, anche se il dover gestire un numero raddoppiato di protocolli ne accresce la
complessita. Il vantaggio principale che ne deriva e che le due componenti dello stesso
layer possono risiedere in entita distinte logicamente o se necessaro anche fisicamente,
consentendo un elevato grado di specializzazione nei compiti. Il lato di trasporto spesso
e soggetto ad una mole elevata di dati da movimentare e riceve un numero di messaggi
molto superiore alla parte di controllo.
Il protocollo di trasporto viene studiato per essere molto piu semplice e meno sogget-
to a modifiche rispetto alla controparte di controllo. Grazie a questo, quando l’opzione
dovesse essere valutata vantaggiosa, si possono incrementare enormemente le prestazioni
nella gestione del flusso userplane tramite dell’hardware dedicato. Il protocollo di con-
trollo invece, essendo molto piu complesso e piu soggetto a cambiamenti tra una revisione
e l’altra ma dovendo gestire un numero ridotto di messaggi, viene generalmente gesti-
to interamente via software. Attraverso opportuni canali di comunicazione la parte di
controllo istruisce il lato di trasporto su quali operazioni debba effettuare. Nell’architet-
tura del CN UMTS il control plane e lo user plane vengono gestiti da nodi distinti in
comunicazione tra loro.
2.1.2 AccessStratum
Esiste un’altra suddivisione logica nel sistema UMTS basata sui protocolli utilizzati e
sulle loro funzioni che attraversa trasversalmente i sistemi UE, RAN e CN.
Capitolo 2. La rete di telefonia mobile UMTS 11
Figura 2.4: Separazione tra Access Stratum (AS) e Non Access Stratum (NAS).
Questa suddivisione definisce due distinti strata 1 l’access stratum e il non access stra-
tum.
Fanno parte dell’access stratum tutti i protocolli di livello inferiore impiegati tra i ter-
minali e la rete di accesso al servizi nello stabilire una connessione verso network. Scopo
dell’access stratum e appunto quello di fornire una base di funzionalita per permettere
la comunicazione gli UE con il CN attraverso il RAN. Tutti i protocolli legati alla ges-
tione delle risorse radio e delle procedure del mobility management fanno parte di questo
gruppo.
Il non access stratum invece comprende i protocolli che regolano le attivita tra i terminali
e il core network, gestendo l’erogazione dei i servizi all’utente offerti dagli operatori.
2.2 Scomposizione architetturale del network
E possibile dividere l’architettura UMTS in tre distinti sottosistemi:
• User Equipment, i terminali mobili a disposizioni degli utenti.
• Radio Access Network, la parte del network che fornisce la connettivita radio.
• Core Network, la parte centrale del network che gestisce le risorse e offre i servizi.
1Uno stratum si riferisce al modo in cui sono raggruppati i protocolli in relazione ai servizi offertinell’ambito di uno o piu domini. La definizione si trova nel documento TS 21.905 dello standard rilasciatodal 3GPP
Capitolo 2. La rete di telefonia mobile UMTS 12
2.2.1 User Equipment
Figura 2.5: Architettura dello User Equipment.
Lo User Equipment (UE) rappresenta i terminali in uso agli utenti finali, tutti quegli
apparecchi che accedono alla rete tramite la connessione wireless fornita dall’operatore.
Le loro caratteristiche e funzionalita variano in base all’ambito di utilizzo. Sono conven-
zionalmente disponibili nella forma di telefono cellulare o modem USB, ma fanno parte
di questa categoria anche laptop con connettivita mobile integrata o apparecchi special-
izzati, come gli antifurti per le auto dotati di GPS che si avvalgono alla rete mobile per la
trasmissione dei dati. Anche se viene comunemente visto come un elemento monolitico,
lo UE e composto da diversi moduli interconnessi (vedi figura 2.5), ad ogniuno dei quali
e delegata una specifica funzione.
A livello piu alto di astrazione lo UE e suddiviso in due elementi: il ME (Mobile
Equipment) e l’UICC (Universal Integrated Circuit Card).
2.2.1.1 UICC e USIM
Figura 2.6: Esempio di UICC.
Lo UICC o Universal Integrated Circuit Card e la parte user-dependent dello UE, il
modulo che si occupa dei dati utente relativi al network di appartenenza. Questo piccolo
Capitolo 2. La rete di telefonia mobile UMTS 13
elemento e un circuito integrato con capacita di calcolo e memoria autonome. Al suo
interno vengono archiviati in modo sicuro uno o piu USIM (UMTS Subscriber Identity
Module), un componente logico che si fa carico di identificarne il possessore dell’USIM
ed ad ottenere l’autorizzazione ad accedere al network dell’operatore mobile. L’UICC
fornisce il supporto fisico alle funzioni logiche offerte dalle USIM.
I dati piu importanti legati all’USIM sono l’International Mobile Subscriber Identity
(IMSI), un numero di 15 cifre che identifica in modo univoco l’utente presso la rete
mobile a livello globale e la chiave segreta, detta Ka, condivisa con l’operatore presso il
quale l’utente e registrato. L’UICC attraverso le proprie capacita di calcolo e in grado di
processare il valore di questa chiave per ottenere i dati necessari all’apparecchio in tutte le
successive operazioni di cifratura o autenticazione, senza che la chiave Ka venga esposta
all’esterno. Molti degli sforzi legati alla produzione di questi piccoli circuiti integrati sono
incentrati sull’impedire che tali dati sensibili possano essere estratti mediante exploit
software o manomissioni hardware dei dispositivi.
Riguardo la gesione della sicurezza la tecnologia GSM ha evidenziato diverse gravi falle
derivate dall’inadeguatezza degli algoritmi utilizzati:
• Gli algoritmi della famiglia A5 impiegati nella generazione delle chiavi di cifratura
ed di autenticazione da parte della SIM si sono dimostrati totalmente inaffid-
abili. Attraverso queste debolezze e possibile ottenere il valore della chiave segreta
Ka dalla SIM, permettendo ad eventuali malintenzionati la clonazione dell’utenza
telefonica o la capacita di decifrare il traffico dati di una comunicazione in corso.
• Nelle specifiche del sistema GSM il cellulare non e tenuto ad autenticare la rete
presso la quale effettua l’accesso. Il risultato e che e estremamente facile effettuare
attacchi di tipo man-in-the-middle verso gli utenti.
Il sistema UMTS ha risolto solamente in parte tali problemi.
I cellulari di ultima generazione richiedono la mutua autenticazione da parte della rete
per ottenere l’accesso ai servizi, utilizzando il set di algoritmi MILENAGE per le pro-
cedure di autenticazione ed il key-agreement. Sebbene questi algoritmi fin’ora si sono
dimostrati sicuri la retrocompatibilita con le base station GSM espone i cellulari 3G alla
stessa falla di sicurezza nei confronti degli attacchi MITM. Dato che la connessione alle
base station 2G viene effettuata comunque senza richiedere l’autenticazione del network
l’introduzione di tali misure risulta essere vanificata [7].
Sono state inoltre identificati diverse falle nel set di algoritmi KASUMI utilizzato nella
generazione delle chiavi per la cifratura delle comunicazioni come successore degli al-
goritmi A5 [8]; sebbene attualmente a livello pratico tali attacchi non abbiano portato
alla forzatura del traffico degli utenti, diversi ricercatori ritengono che la confidenzialita
delle comunicazioni non si possa considerare garantita [9].
Capitolo 2. La rete di telefonia mobile UMTS 14
2.2.1.2 Mobile Equipment
Il Mobile Equipment e la parte user-independent dello UE, quello che per la maggior
parte degli utenti viene chiamato il cellulare. Questo apparecchio e a sua volta suddiviso
in due elementi distinti, il Terminal Equipment (TE), e il Mobile Termination (ME):
• Terminal Equipment: e la parte del dispositivo che fornisce il livello applicativo
all’utente finale, come la parte di gestione e notifica delle chiamate, l’interfaccia
di accesso ai servizi dati, e la gestione delle sessioni attive. Piu in generale il
TE fornisce un interfaccia standard per i servizi di telecomunicazione al livello
applicativo, nonche unadattatore per l’UICC che consenta il dialogo tra l’USIM e
la parte di Mobile Termination.
• Mobile Termination: e il modulo dello UE incaricato di terminare la comini-
cazione mobile da e verso il network, gestisce la parte definita di Radio Access o
semplicemente di accesso. Fornisce un’interfaccia al TE che astrae la tecnologia
radio e le procedure utilizzate.
Il componente di Network Termination, interfacciandosi con l’USIM, controlla le
procedure di mobility management per attivare e mantenere stabile la connessione
mentre il terminale cambia la sua posizione all’interno dell’access network e passa
da un’area di copertura ad un’altra.
Il modulo Radio Termination si presenta come un chip di silicio che si occupa di
modulare e demodulare il segnale radio, fornendo un interfaccia al canale fisico di
comunicazione.
2.2.2 Radio Access Network
Il sottosistema RAN, o Radio Access Network, rappresenta la parte dell’architettura
dedicata al Radio Access (RA), la gestione comunicazione wireless tra i terminali ed il
CN dell’operatore dell’operatore.
La definizione di Radio Access Network, ha origine con lo standard UMTS ma indica
un sottosistema generico, non legato ad una particolare tecnologia radio. Un RAN 2G
prende il nome di GRAN nel caso supporti solamente il sistema GSM, mentre nel caso
sia implementato anche l’estensione EDGE, il sistema viene definito GERAN (GSM-
EDGE Radio Access Network); lo standard prevede inoltre RAN deriate da tecnologie
radio sviluppate al di fuori del competenza del 3GPP, come quelle legate alle tecnologie
WiMAX o Wifi.
Capitolo 2. La rete di telefonia mobile UMTS 15
Figura 2.7: UMTS Radio Access Network o UTRAN.
Per la terza generazione il sottosistema RAN viene chiamato Universal Terrestrial Radio
Access Network o UTRAN. La sua struttura puo essere visualizzata nella figura 2.7.
L’UTRAN e stato sviluppato in modo che i nodi preesistenti della rete GSM, come
l’MSC, l’SGSN e l’HLR, potessero essere estesi in modo da adattarsi al nuovo sistema.
La differenze tra UTRAN e il radio access GSM hanno reso inattuabile il semplice
upgrade dei sistemi esistenti per integrarli nel nuovo network. I sistemi radio GSM sono
stati quindi raggruppati sotto forma di RAN chiamati GRAN e GERAN; mantengono
nodi e interfaccie di comunicazione distinte da quelle dell’UTRAN ma condividono con
que un unico core network, come peraltro avviene anche con i sistemi di radio access
non-3GPP.
2.2.2.1 Nodi dell’UTRAN
Node B (NB) sono i transreceiver dal lato network; ogniuno di essi gestisce una
o piu celle, ossia le aree raggiunte dal segnale radio di una specifica antenna. I NB
forniscono il physical radio link tra lo UE ed il network.
Applicano i codici al segnale radio per ottenere la suddivisione in canali secondo lo
schema CDMA. Si occupano del Power Control, analizzando il livelli del segnale rice-
vuto dai cellulari in modo da poter segnalare quando e possibile ridurre la potenza per
risparmiare sui consumi energetici. Fornisce agli RNC i Measurement Report necessari
per decidere quando attuare una procedura di handover. Applicano la Micro Diversi-
ty : combinano i segnali ricevuti da molteplici antenne prima di trasmettere il risultato
all’RNC.
Capitolo 2. La rete di telefonia mobile UMTS 16
Radio Network Controller (RNC) si occupano di gestire le risorse radio a dis-
posizione per fornire l’accesso ai terminali mobili, transitando il traffico ricevuto da e
verso il core network. Ogni RNC e connesso ad uno o piu NB dei quali controlla le
celle. Si occupa del Call Admission Control, verificando la disponibilita di risorse prima
di accettare la richiesta di conessione di un cellulare. E responsabile del Radio Bearer
Management, l’allocazione di risorse radio che vengono dedicate agli UE per garantire
un determinato Qos. E incaricato del System Information Broadcast, un sistema point-
to-multipoint per notificare ai terminali informazioni riguardo alle caratteristiche del
sistema. Ogni RNC con i NodeB che controlla suddivide logicamente in Radio Network
Systems (RNS).
2.2.2.2 Interfaccie del sistema UTRAN
• Uu e l’interfaccia di comunicazione tra i NodeB e i terminali mobili che avviene
attraverso il canale radio.
• Iu connette ogni RNS al CN e fa transitare il traffico da e verso gli UE. E suddivisa
in due interfacce distine, IuCS ed IuPS , a seconda se la connessione in atto tra lo
UE e il CN sia rispettivamente di tipo circuit-switched o pcket switched.
• IuB e l’interfaccia di comunicazione tra NodeB e RNC. Attraverso questa l’RNC
controlla i NodeB ad esso collegati, gestendone le risorse radio, come l’attivazione
e disattivazione delle celle, o l’allocazione dei canali radio per ogni singolo cellulare
collegato.
• IuR permette la comunicazione tra gli RNC che controllano differenti RNS. At-
traverso di essa vengono coordinate le operazioni di handover tra RNS, procedura
descritta in seguito, che non richiedono l’intervento diretto del CN.
2.2.2.3 Funzioni dell’UTRAN
• Admission Control (AC): Accetta o rifiuta i la connessione di nuovi utenti e
l’attivazioni di nuovi canali di di comunicazione. L’AC deve gestisce le risorse
radio per evitare il deteriorarsi della qualita del servizio, basandosi sulle misure
delle interferenze e del throughput complessivo.
• Congestion Control: Monitora, identifica e gestisce il sistema nel caso si stia
avvicinando al sovraccarico o nel caso il sovracarico sia gia in corso.
• System Information Broadcasting: Fornisce all’UE le informazioni riguardo
il network che sono richieste dal terminale per poter operare correttamente.
Capitolo 2. La rete di telefonia mobile UMTS 17
• Cifratura: Grazie a delle chiavi temporanee ottenute attraverso uno scambio
coordinato di informazioni tra l’USIM il network, applica la cifratura alle le infor-
mazioni scambiate tra terminali e network attraverso l’interfaccia Uu, garantendo
la confidenzialita della comunicazione.
• Handover (HO): Gestisce la mobilita della comunicazione radio. Basandosi su
misure di potenza e throughput del segnale di un particolare terminale, il sistema
e in grado di migrare la connessione tra lo UE e un NodeB sorgente e un NodeB
destinazione, in genere adiacente al primo. In questo modo viene garantita la
qualita del servizio in caso la comunicazione con il NB sorgente sia eccessivamente
degradata rispetto alle richieste del CN. La stessa procedura permette di evitare
la perdita di connettivita nel caso l’utente si sia allontanato dalla copertura della
NB sorgente mentre si trova nel raggio d’azione della cella di un diverso NB. La
procedura di handover puo avvenire anche tra tecnologie di radio access differenti;
in questo caso si parla di Inter-RAT HO. Se un utente passa da una zona raggiunta
dal segnare UMTS ad uno adiacente che supporta solo le connessioni GSM, e pos-
sibile che avvenga un handover da un sistema all’altro che consentira la continuita
della comunicazione seppur con una ridotta qualita del servizio.
2.2.3 Core Network
Il Core Network(CN) e la parte centrale della rete di un operatore. Ad esso sono colle-
gate una o piu RAN, non necessariamente omogenee per tecnologia radio utilizzata.
Foornisce tutti i servizi fondamentali per i subscriber UMTS, come lo switching delle
chiamate e il routing dei pacchetti. La prima implementazione del CN UMTS, la Release
99 dello standard 3GPP (Fig. 2.2), ha ereditato gli elementi che formavano la base del
sistema GSM, opportunamente aggiornati per rispettare i requisiti di performance e in-
terfacciamento richiesti. A partire dalla Release 4, e la sua effettiva attuazione avvenuta
con la Release 5, l’architettura del CN ha subito importanti variazioni. Risale da queste
l’introduzione dell’IP Multimedia Subsystem (Fig. 2.8), un sistema centralizzato per la
gestione dei servizi IP-based offerti dal network.
Le funzioni principali offerte dal Core Network sono le seguenti:
• Autenticazione controlla gli accessi degli utenti al network, sia nel caso di utenti
apartenenti all’operatore, sia nel caso di utenti roaming che vi transitano.
• Charging, Billing e Accounting la registrazione e il controllo di tutte le attivita
al fine di calcolare gli addebiti per i servizi utilizzati da parte degli utenti.
Capitolo 2. La rete di telefonia mobile UMTS 18
Figura 2.8: L’architettura del sistema UMTS, Release 6.
• Smistamento del traffico offre servizi di routing per indirizzare il traffico, sia
voce che dati, verso la sua destinazione finale che puo essere all’interno del network
stesso o poo risiedere in network esterni come nel caso delPublic Switched Telephone
Network (PSTN), la comune rete telefonica fissa.
• Servizi accessori Offre servizi aggiuntivi legati al sistema di telecomunicazione
quali SMS, MMS, Segreterie telefoniche, servizi voip e simili.
2.2.3.1 Separazione tra CS-Domain e PS-Domain
L’evoluzione del sistema di comunicazione mobile, originariamente concepito per sup-
portare la sola comunicazione vocale, negli ultimi anni e stato influenzata dalla sempre
maggior importanza che la rete internet ha rivestito per gli utenti.
Le necessita commerciali degli operatori hanno spinto ad estendere il sistema di telefonia
mobile cellulare, che per interoperabilita con la rete fissa era basato sulla commutazione
Capitolo 2. La rete di telefonia mobile UMTS 19
a circuito o Circuit Switched, introducendo nel network gli apparati necessari a gestire
il traffico dati con commutazione a pacchetto Packet Switched, necessaria per accedere
in modo efficente ai servizi IP-based.
E cosı che il sistema originale GSM e stato esteso per supportare la connettivita IP
introducendo la tecnologia GPRS.
Da questo momento in poi le infrastrutture della rete mobile hanno incrementato grad-
ualmente il supporto alla comunicazione dati, considerandolo col passar del tempo sem-
pre piu come una risorsa indispensabile.
Proprio il supporto alla comunicazioni dati e considerato il punto di svolta tra le tecnolo-
gie 2G e quelle oggi definite 2.5G, che sono la base sulla quale la rete di terza generazione
e stata ideata.
La comunicazione dati, con il supporto delle tecnologie VoIP, in un prossimo futuro an-
dra probabilmente a sostituire interamente la la comunicazione basata su commutazione
dati a circuito, ma attualmente le due soluzioni coesistono all’interno dell’infrastruttura
degli operatori.
Mentre per il Radio Access Network questa separazione del traffico e quasi trasparente,
gli elementi architetturali del CN, che gestiscono la parte circuit-switched (CS) e quel-
la packet-switched (PS) sono ben distinti, e vanno a formare due sottoreti separate e
parallele, che si intersecano solamente in alcuni nodi fondamentali che si occupano di
fornire i servizi ad comuni entrambe.
Si sono cosı venuti a creare due domini applicativo/funzionali separati, il Cs Domain ed
il Ps Domain.
Figura 2.9: Separazione tra CS-Domain e PS-Domain.
Questa separazione si manifesta nei confronti del RAN con la necessita di suddividere
l’interfaccia Iu precedentemente descritta, che viene frammentata IuCS ed IuPS .
La parte di controllo di queste due interfacce differisce nel control plane solamente per
Capitolo 2. La rete di telefonia mobile UMTS 20
alcune procedure o alcune flag impostate all’interno dei messaggi, mentre la differen-
za nello stack della parte user plane e piu consistente ma fortunatamente coinvolge
solamente i layer piu alti.
Elementi del CS-Domain
• Mobile Services Switching Center (MSC): e l’elemento principale del lato CS
del network, gestisce le procedure di Mobility Management. I suoi compiti princi-
pali sono il tenere traccia della posizione degli utenti e gestire il reindirizzamento
delle connessioni tra RNC durante i loro spostamenti. E l’elemento incaricato di
gestire le procedure handover, e di indirizzare la connessione verso la cella corretta
nel caso si verifichi un’incoming call verso un utente retistrato.
• Gateway Mobile Services Switching Center (GMSC): e una speciale vari-
ante dell’MSC che offre le interfacce verso le reti estene, come ad esempio il Packet
Switched Telephone Network (PSTN) e l’Integrated Services Digital Network (IS-
DN). Questo nodo rappresenta il punto di ingresso e uscita dal Core Network verso
i network di altri operatori.
• Visitor Location Register (VLR): Visitor Location Register (VLR): e un database
di utenti che tiene traccia della posizione e altre informazioni di tutti gli utenti
connessi in presso il network CS, compresi gli utenti roaming, cioe quelli che non
sono subscriber all’operatore. Questo database e aggiornato dinamicamente con
gli spostamenti degli utenti in modo che possano essere rintracciati velocemente.
Molto spesso questo nodo viene implementato come parte dell’MSC assieme al
quale forma un unica entita fisica.
Elementi del PS-Domain
• Serving GPRS Support Node (SGSN): questo nodo e entrato a far parte del-
l’architettura con l’introduzione del sistema GPRS. Presso di esso sono registrati
tutti gli utenti che hanno effettuato accesso al PS domain, e sono salvate tutte
le informazioni necessarie per ottenere e portare a termine le connessioni dati. E
interessante notare le informazioni e gli indirizzi riguardanti la rete a pacchetto uti-
lizzata sono considerate per un generico Packet Data Protocol (PDP), non essendo
quindi legate all’utilizzo del protocollo IP che comunque rappresenta lo standard
de-facto. Le connessioni associate ad un cellulare nel PS-domain sono chiamate
PDP Context. Per trasferire i dati verso la corretta destinazione al di fuori del
CN, l’SGSN li reindirizza una volta ricevuti verso il GGSN presso il quale il PDP
Capitolo 2. La rete di telefonia mobile UMTS 21
Context e attivo; a seconda del servizio offerto all’utente o di altri fattori i vari
utenti dell’SGSN possono avere PDP Context attivi su GGSN differenti.
• Gateway GPRS Support Node (GGSN): e il punto centrale di accesso alla rete
internet da parte del network mobile. E l’elemento responsabile per l’interconnes-
sione tra la rete GPRS e le reti packet-switched esterne, come Internet. Come dice
il nome il GGSN e un gateway di accesso alla subnet dell’operatore che nasconde
l’infrastruttura del network dall’esterno. Il GGSN tiene traccia dei PDP Context
attivi e reindirizza i pacchetti in ingresso verso l’SGSN presso il quale l’utente
e registrato e inoltra i pacchetti in uplink dai cellulari verso l’esterno. Essendo
posto al limite della rete questo nodo implementa le funzionalita di un firewall per
impedire accessi non autorizzati al sitema o attivita indesiderate.
Elementi Condivisi
• Home Location Register (HSS) L’HSS e entrato a far parte dell’architettura
del sistema UMTS dalla release 5. Le sue funzioni sono quelle precedentemente
offerte da due nodi separati, l’Home Location Register (HLR) e l’Authentication
Center (AuC), che sono ora considerati come subset delle funzioni offerte dall’HSS.
Le sue funzioni sono molteplici e di fondamentale importanza sia per il CS che per
il PS domain:
– Identification: mette in relazioni i vari identificativi univoci che possono es-
sere assegnati ad un singolo utente, come l’IMSI, l’MSISDN (il numero di
telefono), indirizzo IP, o le identita temporanee.
– Security Support : fornisce le informazioni di sicurezza necessarie a stabilire
una comunicazione cifrata e autenticata, generando le chiavi di sessione a
partire dalla chiave Ka condivisa con la USIM fornita all’utente.
– Call/Session Support : fornisce le informazioni su che nodo ha in gestione un
determinato utente al fine di poter inoltrare le chiamate o indirizzare i dati.
– Service Authorization Support : fornisce informazioni ai restanti nodi del CN
su quali sono i servizi che un determinato utente e autorizzato ad utilizzare.
• Equipment Identity Register (EIR) Registra le informazioni e seriali riguardan-
ti i terminali degli utenti e li suddivide in liste: una white list per i terminali nor-
malmente autorizzati ad avere accesso ai servizi (generalmente non e implementata
nel sistema per le difficolta del suo mantenimento), una black list per i terminali
rubati e una gray list per i terminali sospetti che sono sottoposti a monitoraggio.
Un terminale registrato nella black list che tentera di agganciarsi al network ve-
dra la sua richiesta rifiutata, mentre se la richiesta proviene da un cellulare nella
Capitolo 2. La rete di telefonia mobile UMTS 22
gray list la richiesta verra accettata ma causera una qualche notifica che verra
successivamente analizzata.
2.3 Femto Access Point o Femtocelle
Ogno NodeB nel sistema UMTS puo gestire una o piu celle, ogniuna delle quali si puo
estendere per alcuni chilometri e puo supportare il carico di centinaia di utenti simul-
taneamente.
Sebbene questa soluzione risulti essere molto efficente per gestire un gran numero di
dispositivi connessi simultaneamente questo tipo di tecnologia mal si adatta ad alcuni
particolari ambiti: per risolvere problemi di copertura di zone difficilmente accessibili o
con un numero limitato di utenze, o per esigenze specifiche legate allo small-business, i
costi da sostenere la rendono economicamente non vantaggiosa. La stesura di una linea
dati dedicata per raggiungere l’RNC dal NodeB, l’installazione dei tralicci per sostenere
le antenne o comunque il compenso da pagare per poterle installare in quelli gia presen-
ti, e i costi delle apparecchiature radio necessarie e della manodopera e nell’ordine delle
centinaia di migliaia di euro.
Per poter soddisfare le esigenze di questi ristretti bacini di utenza, ad affiancare il comune
approccio a celle di grande dimensione, chiamato a macrocelle, sono state sviluppate delle
soluzioni piu economiche che potessero portare la copertura radio dove necessario e senza
richiedere grandi investimenti in infrastrutture. Queste tecnologie offrono ovviamente
estensioni della cella inferiori e vengono chiamate a seconda della capacita microcelle,
picocelle, femtocelle: le microcelle offrono una copertura inferiore a due chilometri, le
picocelle nell’ordine di alcune centinaia di metri, mentre le femtocelle hanno una capac-
ita limitata a poche decine di metri, ma comunque sufficenti a diffondere il segnale in
un’abitazione o ad una piccola attivita commerciale.
Le apparecchiature dedicate ad zone cosı ristrette possono essere rese compatte ed eco-
nomiche e possono essere collocate direttamente nelle abitazioni degli utenti non rag-
giunti dal segnale delle macrocelle o dove il segnale e scarso. La loro installazione inoltre
puo essere effettuata da personale non qualificato come l’utente stesso, andando a ridurre
ulteriormente i costi di gestione dell’infrastruttura.
Il risultato di questo sforzo di standardizzazione e stata la nascita dei Femto Access
Point, comunemente chiamati femtocelle o small cells.
Questo apparecchio dall’asspetto poco dissimile da un comune router wireless domestico,
per poter operare necessita semplicemente di essere alimentato e di poter comunicare
via internet con il Femto Gateway che a sua volta comunica con il Core Network dell’op-
eratore mobile di appartenenza, punto obbligato di transito per tutte le comunicazioni
Capitolo 2. La rete di telefonia mobile UMTS 23
Figura 2.10: Modello di femtocella in commercio.
da e verso il terminale mobile.
La connessione con CN si apoggia alla linea DSL domestica dell’utente (esistono momdel-
li di femtocelle con modem/router integrato) che potra beneficiare del miglior segnale
possibile entro le mura domestiche e spesso di tariffe agevolate applicate quando le
comunicazioni avvengono tramite la femtocella.
2.4 Integrazione delle Femtocelle nell’architettura UMTS
L’impatto dell’introduzione delle femtocelle nel network preesistente degli operatori e
minimo. Solamente sue nodi devono essere aggiunti, e spesso per semplicita risultano
essere fusi assieme in uno singolo.
Nei confronti del CN questo sottosistema si presenta come una RAN implementandone
le stesse interfaccie e non richiede pertanto modifiche o implementazioni di interfacce
aggiuntive (Fig. 2.11).
Spesso gli stessi produttori di Femtocelle forniscono allo stesso tempo anche i rimanenti
elementi dell’architettura di supporto, offrendo agli operatori una soluzione completa
plug and play.
Capitolo 2. La rete di telefonia mobile UMTS 24
Figura 2.11: Architettura del network di supporto alle Femtocelle.
I nuovi nodi che entrano a far parte dell’architettura di rete sono i seguenti:
• Home NodeB o HNB E il nome che nel contesto dell nell’architettura UMTS
prendono le femtocelle. Sono il Customer Premise Equipment che rende disponi-
bile interfaccia Uu ai terminali, ossia il segnale radio e i protocolli di comuni-
cazione ad esso legati. Mantiene il collegamento con il CN tramite l’interfaccia
IuH verso l’HNB-GW, e offre parte delle funzionialita del RAN comunemente affi-
date all’RNC (altre sono fornite dal HNB-GW). Gestisce la segnalazione da parte
dell’HNB stesso e degli UE presso ad esso connessi verso l’HNB-GW tramite lin-
terfaccia IuH , e si occupa della stabilire una connessione sicura verso il Security
Gateway. Offre i servizi dell’UTRAN supportati dal protocollo RANAP, e offre
i servizi specifici di un HNB attraverso il protocollo Home NodeB Application
Protocol (HNBAP) instaurato tra HNB e HNB GW.
• Security Gateway E il punto nel CN nel quale termina la comunicazione sicura
tra CN e HNB. Tutte le connesioni dei vari HNB vengono aggregate verso questo
punto per essere cifrate o decifrate, a seconda della direzione. Per ragioni di privacy
e sicurezza, tutto il traffico generato dagli HNB e dai cellulari ad essi collegati,
sia per la parte di trasporto che di segnalazione viene fatta transitare attraverso
internet attraverso un tunnel IPsec. Oltre alla cifratura il Scurity Gateway si
occupa anche della mutua autenticazione tra gli HNB ed il CN.
• HNB Gateway o HNB-GW E il punto nel network dell’operatore nel quale
termina l’interfaccia IuH . L’Home Node B Gateway, che e il punto di contatto
tra il CN e l’infratruttura di gestione delle femtocelle, espone infatti l’interfaccia
Capitolo 2. La rete di telefonia mobile UMTS 25
Iu , sia per il dominio CS che per quello PS come un normale RNC. L’HNB GW
fornisce un punto di accentramento per le funzioni di control plane degli HNB e,
se richiesto, anche per lo user plane. E inoltre possibile connettere l’HNB-GW
tramite l’interfaccia IuR per permettere la comunicazione verso gli RNC adiacenti
consentendo quindi l’handover delle connessioni da un RNS all’altro.
• HNB Management System o (HMS) E un nodo impiegato come punto inter-
medio nella fase di connessione tra HNB e HNB-GW. Invia le i dati di confugu-
razione richiesti dall’operatore agli HNB. Verifica l’origine (geografica) della con-
nessione ed assegna all’HNB ai nodi Security GW e HNB-GW appropriati.
2.5 L’Interfaccia IuH
I primi modelli di femtocelle sono entrati in produzione ben prima della loro definizione
di uno standard comune. Questo ha protato alla proliferazione di diversi protocolli
proprietari, incompatibili tra loro, legati alle varie case produttrici, ed in generale ad una
certa confusione su come queste si dovessero interfacciare al network. Per porre rimedio
a questa situazione, anche se con un certo ritardo, il 3GPP ha rilasciato le specifiche
necessarie a standardizzare le femtocelle e l’infrastruttura di supporto, definendo oltre
ad altri aspetti, l’interfaccia IuH che mette in comunicazione gli HNB con l’HNB-GW
secondo lo schema riportato nella figura 2.12.
Figura 2.12: Modello di riferimento per l’interfaccia IuH .
Lo standard per questa interfaccia prevede per la parte di sengalazione due protocol-
li dedicati. Questi nuovi protocolli sono denominati Home NodeB Application Part
(HNBAP) ed RANAP User Adaptation (RUA), il primo dedicato alla segnalazione tra
HNB-GW e le femtocelle, ed il secondo dedicato a trasportare la segnalazione tra le fem-
tocelle ed il CN, diventando di fatto il protocollo userplane della parte di segnalazione
dell’IuH .
Un aspetto interessante dell’interfaccia IuH e che la parte userplane, chiamata IuUP ,
non termina nell’HNB-GW come invece accade per la parte di controllo. I protocolli
userplane che trasportano i dati inviati o ricevuti dai terminali mobili, sono inoltrati
Capitolo 2. La rete di telefonia mobile UMTS 26
Figura 2.13: IuH protocol stack.
senza modifiche dall’HNB-GW al nodo responsabile del CN in base al loro dominio di
appartenenza (CS-Domain o PS domain). Si avra quindi, come si puo visualizzare nella
figura 2.11, che i pacchetti userplane di tipo CS generati dagli HNB inoltrati in modo
trasparente all’MSC tramite l’interfaccia IuCS , mentre i pacchetti di tipo PS verranno
inoltrati verso l’SGSN attraverso l’interfaccia IuPS .
2.5.1 Control Plane protocol stack
La comunicazione punto a punto tra CN e HNB avviene tramite il protocollo RANAP,
Radio Access Network Application Part.
Questo protocollo nel tradizionale modello dell’UTRAN permette lo scambio di infor-
mazioni tra CN e RNC. Di quest’ultimo l’HNB fa le veci nel compito di protocol converter
Capitolo 2. La rete di telefonia mobile UMTS 27
Figura 2.14: IuH control plane protocol stack.
mappando le richieste di attivazione di un Radio Access Bearer, provenienti dal Core
Network via RANAP, in richieste da inviare al cellulare attraverso il protocollo Radio
Resource Control (RRC), appartenente all’interfaccia Uu.
I pacchetti RANAP scambiati tra Core Network e HNB transitano attraverso l’interfac-
cia IuH incapsulati nel protocollo RANAP. Il protocollo HNBAP si occupa inizialmente
di stabilire la connessione, richiesta dall’HNB verso l’HNB-GW. Nel caso questa venga
accettata, valuta le richieste di connessione degli UE che vengono inoltrate dall’HNB.
Ad ogni connessione UE accettata viene assegnato un valore chiamato Context-id, cor-
risponde all’identificativo di un nuovo tunnel di comunicazione RUA che permettera ai
pacchetti RANAP riferiti al particolare UE di transitare tra HNB e CN.
L’HNB-GW inoltra il contenuto dei pacchetti RUA ricevuti dal’HNB verso il CN map-
pando ogni connessione RUA su di una specifica connessione SCCP, protocollo usato
nell’interfaccia Iu . Per i pacchetti originati dal CN, l’HNB-GW applica il processo
inverso, convertendo i messaggi da SCCP a RUA inoltrandone il contenuto verso gli
HNB.
2.5.2 Security protocol stack
Le femtocelle dal punto di vista della sicurezza introducono un cambiamento rilevante.
Prima della loro introduzione i nodi del Radio Access Network che potevano accedere
direttamente al Core Network erano relativamente pochi, molto complessi, collocati in
locali con restrizione all’accesso o comunque non facilmente raggiungibili e rigorosamente
connessi tramite connessioni dedicate. Le femtocelle invece sono fabbricate con una com-
ponentistica hardware abbastanza comune, vengono collocate in numero ragguardevole
completamente al di fuori dal controllo dell’operatore e richiedono che tutto il traffico
generato transiti sulla rete internet, che non e certo nota alle cronache per essere priva di
Capitolo 2. La rete di telefonia mobile UMTS 28
Figura 2.15: Sicurezza delle comunicazioni control plane via IPsec.
minacce. Il primo passo per garantire la privacy degli utenti che collegano i loro terminali
a questi apparecchi, e per permettere all’operatore di controllare gli accessi delle fem-
tocelle al network e quello di stabilire una connessione cifrata ed autenticata attraverso
l’uso del protocollo IPsec. Le femtocelle prima di essere distribuite vengono preconfig-
urate installandovi un certificato digitale. Attraverso questo il Security Gateway potra
verificare l’origine della connessione prima di inizializzare la comunicazione cifrata verso
l’HNB. Una volta stabilito il tunnel IPsec tutti i dati che verranno scambiati tra la fem-
tocella ed il CN non potranno venir interpretati ne modificati durante il loro transito
attraverso la rete internet. Per l’HNB-GW tutto questo avviene in modo trasparente,
e compito degli HNB e del Security GW aggiungere e rimuovere l’incapsulamento Ipsec
dai pacchetti scambiati.
2.5.3 CS/PS Userplane protocol stak
L’interfaccia IuUP , la parte userplane dell’Iu , e composta da due differenti stack di
protocolli in funzione del dominio del traffico trasportato.
La parte CS dell’interfaccia, chiamata IuCS , trasporta un flusso audio codificato in
formato AMR (Adaptive Multi-Rate), un codec audio brevettato e adottato dal 3GPP
come standard per l’encoding dei flussi vocali dal 1999. Questo standard permette
una compressione a bitrate variabile impostabile dinamicamente in base alla bandwith
disponibile. L’MSC si occupa di redirigere questi flussi vocali delle telefonate utenti tra
un cellulare e l’altro o verso la rete PSTN. Nel passaggio attraverso l’IuH , l’HNB-GW
ottimizza il traffico RTP (Real Time Protocol) che trasporta i dati codificati, effettuando
il multiplexing delle connessioni attraverso una singola sessione RTP.
Capitolo 2. La rete di telefonia mobile UMTS 29
Figura 2.16: IuH user plane CS protocol stack.
Figura 2.17: IuH user plane PS protocol stack.
Il lato PS invece, chiamato IuPS trasporta in modo trasparente i dati utente, incapsulati
in un header GPRS Tunnelling Protocol (GTP), tra HNB e SGSN. Nella maggior parte
dei casi il payload dei pacchetti GTP e costituito da pacchetti IP.
Il transito di questi dati attraverso l’HNB-GW e comunque implementation dependent.
Se la configurazione lo permette e possibile che i pacchetti userplane vengano inoltrati
da CN ad HNB e viceversa. Evitando un passaggio obbligato attraverso l’HNB-GW si
riducono di molto le risorse hardware richieste da quest’ultimo, pur sacrificando parte
dei controlli di sicurezza offerti.
Capitolo 3
Il Progetto
3.1 Obiettivi e vincoli del progetto
Essendo il sistema PRIMO studiato per essere il piu possibile compatto ed economico,
le scelte architetturali sono vincolate dalla scelta di utilizzare hardware general-purpose
che non puo certo competere nelle performance con l’enorme capacita elaborativa offerta
dai sistemi dedicati che tradizionalmente rivestono questi compiti.
Per poter comunque garantire un livello di performance adeguato e imperativo concen-
trare gli sforzi nella riduzione della complessita del sistema in modo da ridurre al minimo
le risorse richieste nell’elaborazione.
A tale scopo si e deciso condensare tutte le funzioni dell’HNB-GW all’interno di una
shared-library da integrare all’interno del core network del sistema PRIMO.
Figura 3.1: Integrazione dell’IuH .
Il lato user plane dell’IuH e gia compatibile con l’interfaccia l’Iu che risulta gia implemen-
tata. Per la parte di control plane lo standard prevede che l’HNB-GW offra le funzioni
di protocol-converter tra SCCP ed RUA/HNBAP; rimuovendo HNB-GW si puo evitare
30
Capitolo 3. Il Progetto 31
questa conversione.
Implementando le medesime API tra il protocollo RANAP ed il protocollo SCCP, che
gia fanno parte del sistema, ed andando ad affiancarsi a quest’ultimo, si possono ridurre
i passaggi necessari a portare a destinazione il payload, riducendo inoltre al minimo le
modifiche da apportare al codice esistente per l’integrazione del’interfaccia. La libreria
diventa in questo modo un adapter IuH per il core network esistente.
Per quanto riguarda il supporto alle funzonalita offerte dal Service Gateway, il cui uso
e compunque opzionale, si fara affidamento ai tool gia disponibili per sistema operativo
GNU/Linux sul quale PRIMO e basato. Essendo IPsec un protocollo standard utilizzato
in molti altri ambiliti, esistono numerosi strumenti open source adatti a soddisfare tutte
le esigenze del caso.
La necessita di gestire in modo rapido ed efficente i compiti richiesti, il livello di in-
tegrazione con il sistema operativo e le sue funzionalita necessarie a svolgere diverse
funzioni e ovviamente non ultima la compatibilita con il software gia disponibile che
rappresenta il cuore del sistema PRIMO, la scelta del linguaggio di programmazione e
ricaduta obbligatoriamente sul linguaggio C.
L’obiettivo finale del progetto consiste nell’effettuare con successo un test di interoper-
abilita con delle femtocelle acquistate dall’azienda, in modo da verificare le funzionalita
della nuova interfaccia.
3.2 IuH control plane
La parte di controllo dell’IuH e composta da due distinti protocolli. La suddivisione
del control layer in due protocolli distinti da vita alla suddivisione dello layer stesso in
due flussi distinti di control plane. La parte di controllo specifico alla interconnessione
tra Home NB viene affidata al protocollo HNBAP, mentre la funzione di trasporto del
protocollo di controllo della segnalazione dei cellulari e affidato a RUA.
Le specifiche per i protocolli RUA e HNBAP definiscono in maniera dettagliata i mes-
saggi che possono essere scambiati tra i peer. Le azioni da intraprendere alla ricezione
di tali messaggi nel gergo delle specifiche sono definite Elementary Procedures.
Quando sono necessari diversi messaggi dello stesso protocollo, logicamente correlati tra
loro, per portare a terminte una funzione specifica, la procedura e definita una Class 1
Procedure.
Per esempio nel caso venga inoltrata una richiesta di registrazione (Initiating Message)
per un determinato cellulare, sara necessario un messaggio di risposta per portare a
Capitolo 3. Il Progetto 32
termine l’operazione, che a seconda dell’esito potra essere una convalida (Successful
Procedure) od un rifiuto (Unsuccessful Procedure).
Figura 3.2: Esempio di procedura di Classe 1.
Nel caso invece il un singolo messaggio sia sufficente a portare a termine una determinata
funzione senza la necessita di risposta dalla controparte, la procedura e definita una Class
2 Procedure.
3.2.1 Il protocollo HNBAP
Le funzioni offerte dal protocollo sono le seguenti:
• HNB Registration Permette la registrazione degli HNB presso l’HNB-GW. Se
completata con successo, l’HNB puo procedere con le richieste di registrazione
degli UE presso l’HNB-GW. Inoltre , una volta effettuata la registrazione il core
network puo inviare dei messaggi indirizzati specificamente all’HNB nel caso sia
necessario effettuare segnalazione broadcast nella cella.
• UE Registration Permette la registrazione degli UE presso l’HNB-GW. Se com-
pletata con successo viene stabilito un tunnel RUA per trasportare i messaggi
RANAP tra HNB e CN per lo specifico UE.
• CSG Membership Update Le femtocelle possono essere configurate per ac-
cettare connessioni da un set di utenti limitato. Gli utenti possono appartenere
o meno ad un Closed Subscriber Group (CSG), e se la femtocella non e opera in
modalita Open Access solamente gli utenti appartenenti al CSG saranno in grado
di collegarsi. Tramite HNBAP il core network e in grado di variare dinamicamente
la sottoscrizione degli utenti ad un CSG.
• Error Handling Permette la notifica di condizioni di errori per i quali non e stato
definita una specifica procedura.
Capitolo 3. Il Progetto 33
Procedure di classe 1:
Procedura Messaggio Iniziale Risposta Positiva Risposta negativa
HNB Registration HNB Reg. Request HNB Reg. Accept HNB Reg. Reject
UE Registration UE Reg. Request UE Reg. Accept UE Reg. Reject
Procedure di classe 2:
Procedura Messaggio
HNB De-Registration HNB De-Register
UE De-Registration UE De-Register
Error Indication Error Indication
CSG Membership Update CSG Membership Update
3.2.2 Il protocollo RUA
Le funzioni di questo protocollo sono elementari:
• Trasferimento permette di trasferire in modo trasparente i messaggi RANAP
tra il CN e gli HNB, previa opportuna registrazione di questi ultimi attraverso il
protocollo HNBAP.
Esistono due modi disponibili per trasferire i messaggi RANAP:
se il messaggio e destinato all’HNB, ad esempio nel caso sia necessario inviare un
messaggio di tipo broadcast come quelli delle procedure di Paging 1, l’header RUA
indichera che il contenuto del pacchetto e di tipo Connectionless cioe non dedicato
ad una specifica connessione di un UE. Nel caso invece i messaggi siano riferiti ad
un UE in particolare questi vengono inviati incapsulati nei messaggi connection
oriented, Connect, Direct Transfer e Disconnect. Ogniuno di questi messaggi sara
marcato con un valore numerico chiamato Context-id, stabilito durante la proce-
dura HNBAP UE-Registration che identifica univocamente il cellulare nel contesto
della connessione IuH . E delegato al layer superiore l’indicazione di dello stato
della connessione e quindi della scelta dell’header RUA adeguato.
• Error Handling Permette la notifica di condizioni di errori per i quali non e stato
definita una specifica procedura.
1Il cellulari per risparmiare energia passano la maggior parte del tempo in stato di sospensione maad intervalli temporali prestabiliti si mettono in ascolto. Nel caso il CN richieda che il cellulare siriattivi, per esempio nel caso di una chiamata in arrivo o di un SMS da notificare, viene inviato unmessaggio broadcast chiamato Paging durante la finestra temporale nella quale il terminale e in ascolto,richiedendone la riconnessione.
Capitolo 3. Il Progetto 34
Questo protocollo implementa solamente procedure di classe 2, senza richiesta di con-
ferma:
Procedura Messaggio
Connect Connect
Direct Transfer Direct Transfer
Disconnect Disconnect
Connectionless Transfer Connectionless Transfer
Error Indication Error Indication
3.3 Implementazione della libreria
La libreria e composta da un wrapper, chiamato libiuh, che avvolge le librerie specifiche
dei due protocolli RUA ed HNBAP, come da figura 3.3.
Esistono due set di API (Application programming interface) per libiuh: una verso il
layer superiore, RANAP, e l’altra verso il layer inferiore, SCTP. Queste API rispecchi-
ano quelle gia implementate dall’implementazione dell’interfaccia Iu , rispettivamente
tra RANAP ed SCCP e tra M3UA e SCTP. In questo modo la nuova libreria puo essere
gestita in sostituzione o in collaborazione alle librerie che gestiscono i protocolli citati.
Le funzioni di controllo della libreria sono completamente delegate al protocollo HNBAP
tramite la libreria che lo implementa, libhnbap. Questa espone parte delle funzionalita
offerte dal protocollo a RANAP tramite una serie di funzioni che ne permettono l’inizial-
izzazione, la modifica della configurazione e la gestione delle connessioni di HNB ed UE.
Sono definite inoltre un certo numero di callback, attraverso le quali HNBAP notifica
a RANAP il verificarsi di determinati eventi, come la connessione e disconnessione di
HNB e UE. Gli stessi eventi hanno effetto sulla parte userplane del layer, rappresentata
da RUA.
La libreria che ne implementa le funzionalita, librua e controllata direttamente da libhn-
bap che e responsabile per il suo corretto uso e per la corretta gestione dei suoi servizi.
Quando un UE effettua una con successo la registrazione, libhnbap invia i comandi
opportuni a librua per aprire il canale di comunicazione per il trasporto dei pacchetti
RANAP. Se per indicazione dell’upper-layer o per la ricezione di un messaggio di UE-
Deregister, il cellulare viene de-registrato, libhnbap dara comando a librua di bloccare
la ricezione e l’invio dei pacchetti verso quella specifica destinazione.
Capitolo 3. Il Progetto 35
Figura 3.3: Struttura della libreria libiuh.
3.3.0.1 Abstract Syntax Notation One
L’ Abstract Syntax Notation One o ASN.1, e una notazione nata dall’esigenza di avere
un metodo standard di definire strutture dati con un alto livello di astrazione, un meto-
do che fosse indipendente dai vincoli di piattaforma, linguaggio di programmazione o
da specifiche di terze parti. Definita dallo standard ITU-T X.680, questa notazione e
comunemente usata nel mondo delle telecomunicazioni per la definizione dei protocolli
di rete, in quanto e di grande ausilio nella descrizione dettagliata dei pacchetti, affian-
cando al linguaggio di definizione delle strutture, dei set di regole che consentono una
traduzione univoca delle strutture dati in bit-pattern e viceversa. Sono disponibili stru-
menti per la maggior parte delle piattaforme e linguaggi che consentono di convertire
l’ASN.1 in strutture specifiche per il linguaggio di programmazione usato. Gli stessi
strumenti consentono la conversione automatica dai valori delle strutture dati generate
al bit-pattern da trasferire attraverso il canale di comunicazione desiderato e permet-
tono di effettuare il processo inverso per i dati in ricezione. Le specifiche dei protocolli
HNBAP e RUA, come quelle di molti altri protocolli rilasciati dal 3GPP, allegano il
codice ASN.1 che definisce la struttura dei messaggi che mettono in comunicazione gli
HNB con l’HNB-GW.
Il seguente listato e un esempio della codifica in codice ASN.1 del messaggio HNBAP
HNB Register Request:
Capitolo 3. Il Progetto 36
-- **************************************************************
--
-- HNB Register REQUEST
--
-- **************************************************************
HNBRegisterRequest ::= SEQUENCE {
protocolIEs ProtocolIE-Container
{ {HNBRegisterRequestIEs} },
protocolExtensions ProtocolExtensionContainer
{ {HNBRegisterRequestExtensions} } OPTIONAL,
...
}
HNBRegisterRequestIEs HNBAP-PROTOCOL-IES ::= {
{ ID id-HNB-Identity CRITICALITY reject TYPE HNB-Identity
PRESENCE mandatory } |
{ ID id-HNB-Location-Information CRITICALITY reject TYPE HNB-Location-Information
PRESENCE mandatory } |
{ ID id-PLMNidentity CRITICALITY reject TYPE PLMNidentity PRESENCE mandatory } |
{ ID id-CellIdentity CRITICALITY reject TYPE CellIdentity PRESENCE mandatory } |
{ ID id-LAC CRITICALITY reject TYPE LAC PRESENCE mandatory } |
{ ID id-RAC CRITICALITY reject TYPE RAC PRESENCE mandatory } |
{ ID id-SAC CRITICALITY reject TYPE SAC PRESENCE mandatory } |
{ ID id-CSG-ID CRITICALITY reject TYPE CSG-ID PRESENCE optional } ,
...
}
HNBRegisterRequestExtensions HNBAP-PROTOCOL-EXTENSION ::= {
{ ID id-Service-Area-For-Broadcast CRITICALITY ignore
EXTENSION SAC PRESENCE optional }|
{ ID id-HNB-Cell-Access-Mode CRITICALITY reject
EXTENSION HNB-Cell-Access-Mode PRESENCE optional},
...
}
Capitolo 3. Il Progetto 37
Come si puo faclilmente capire, questo codice definisce un messaggio HNBRegisterRe-
quest, definito come una sequenza di HNBRegisterRequestIEs od opzionalmente di HN-
BRegisterRequestExtensions.
Ogni elemento di questa sequenza, e chiamato Information Element (IE). Gli Informa-
tion Elements non sono altro che tipi di dato strutturati che rappresentano le infor-
mazioni trasportate dal pacchetto. La lista degli IE che possono essere inseriti in queso
messaggio e elencata poche righe piu in basso, mentre la loro definizione, per brevita
non e stata aggiunta.
L’ASN1 definisce una sintassi astratta per definire la composizione ed il contenuto dei
messaggi ma non specifica direttamente come questi dati debbano essere rappresentati in
forma codificata. Sono state sviluppate separatamente diversi set di encoding rules, che
permettono di definire con precisione come i dati debbano essere codificati e decodificati.
I vari set di regole differiscono per alcune caratteristiche, come la compattezza o la
velocita di decodifica che li rendono adatti in differenti ambiti di utilizzo.
La piu semplice ed anche piu datata forma di encoding e denominata BER (BASIC EN-
CODING RULES). In questo formato ogni dato inviato e rappresentato attraverso l’uso
di un Tag-Length-Value (TLV), una tripletta di valori che rappresentano: l’id specifi-
co dell’informazione codificata, la lunghezza del dato ed il valore assegnato. Esistono
due subset del BER, DER (DISTINGUISHED ENCODING RULES) e CER (CANON-
ICAL ENCODING RULES) che pongono alcuni limiti al sistema originale e vengono
comunemente utilizzati in applicazioni legate alla sicurezza, come nei certificati digitali
X.509.
La codifica piu compatta per il codice ASN1 e la PER (PACKED ENCODING RULES).
Si differenzia per il formato BER in quanto non include un tag identificativo per i dati, in
quanto l’ordine con il quale questi debbano presentarsi nel messaggio e imposto in modo
fisso. Il sistema PER inoltre non inserisce le lunghezze dei dati nei messaggi quando
queste sono fissate, risparmiando cosı ulteriori byte. Un’analisi dell’ASN1 permette
inoltre alla codifica PER di rimuovere informazioni ridondanti dalla codifica dei valori,
rendendolo un sistema di codifica estremamente efficace per i sistemi nei quali il risparmio
della banda e importante. Esistono due modi di codificare un messaggio PER, allineato
e non allineato. Con il sistema PER allineato un valore codificato viene arrotondato al
byte, aggiungendo dei bit di padding dove necessario. La versione non allineata invece
utilizza ogni singolo bit disponibile per comprimere al massimo le informazioni.
Il sistema PER non allineato e quello piu comunemente utilizzato dal 3GPP per la
definizione dei suoi protocolli, RANAP, RUA ed HNBAP sono tra questi. Sono disponi-
bili altri formati di encoding per l’ASN1, ma non essendo rilevanti ai fini del progetto
non verranno trattati.
Capitolo 3. Il Progetto 38
3.3.0.2 Compilatore ASN.1 di terze parti
Nell’ambito del progetto e stata messo a disposizione un apposita suite per la manipo-
lazione del codice ASN.1, acquistata presso OSS Nokalva. Tale suite comprende un
compilatore per l’ASN.1 e delle runtime libraries, da aggiungere in fase di linking agli
eseguibili che fanno uso delle strutture generate dal compilatore.
Figura 3.4: ASN.1 Workflow.
Le definizioni ASN.1 dei messaggi dei protocolli presi in esame possono essere trovati
all’interno delle specifiche di riferimento rilasciate dal 3GPP.
A partire da questi attraverso il compilatore OSS, sono state generati due file per ogni
protocollo, un file sorgente .c e un header .h. Il file header definisce tutte le strutture
necessarie a costruire una Packet Data Unit (PDU), il termine con il quale vengono
chiamati i messaggi nella documentazione (e nel codice) dei tool in questione. Il file
header definisce anche un’enorme quantita di macro per il preprocessore C, che almeno
nelle intenzioni di chi ha sviluppato il compilatore ASN, dovrebbero essere d’ausilio
allo siluppatore nella manipolazione delle strutture, che risultano essere estremamente
ramificate e complesse.
Di seguito e riportato la descrizione in formato ASN.1 della rappresentazione di un
indirizzo IP estratto dalle specifiche del protocollo HNBAP, e della sua rappresentazione
in C ottenuta dopo la conversione attraverso il compilatore OSS.
IP-Address ::=SEQUENCE {
Capitolo 3. Il Progetto 39
ipaddress CHOICE {
ipv4info Ipv4Address,
ipv6info Ipv6Address,
...
},
iE-Extensions ProtocolExtensionContainer { { IP-Address-ExtIEs } } OPTIONAL,
...
}
IP-Address-ExtIEs HNBAP-PROTOCOL-EXTENSION ::= {
...
}
Ipv4Address ::= OCTET STRING (SIZE (4))
Ipv6Address ::= OCTET STRING (SIZE (16))
L’information element IP-Address e una sequenza cosı strutturata:
• un elemento a scelta (CHOICE ) tra due gli elementi di tipo Ipv4Address e Ipv6Address
, definiti come derivati da OCTECT STRINT, un tipo di dato elementare del-
l’ASN.1 che rappresenta una sequenza di byte.
• un elemento opzionale di tipo ProtocolExtensionContainer che, se presente, con-
tiene a sua volta un elemento di tipo IP-Address-ExtIEs. Questo definisce eventuali
estensioni aggiuntive, attualmente non previste.
• ulteriori elementi non ancora definiti che potranno essere aggiunti in release suc-
cessive del protocollo, definite attraverso i tre punti consecutivi (...) alla fine della
sequenza.
Da notare la presenza dei punti di sospensione (. . . ) anche all’interno del CHOICE
e dell’IE IP-Address-ExtIEs. Questi permettono a future estensioni del protocollo di
aggiungere ulteriori opzioni oltre a quelle gia inserite. Il significato dei punti di sospen-
sione e che se in fase di decodifica viene rilevato un IE correttamente formato ma non
riconosciuto questo dovra essere ignorato e considerato un estensione del protocollo non
supportata anziche generare un errore di sintassi.
Le strutture in linguaggio C corrispondenti all’ASN.1 appena descritto sono le seguenti:
Capitolo 3. Il Progetto 40
typedef struct _OctStr {
unsigned int length;
unsigned char *value;
} _OctStr;
typedef _OctStr Ipv4Address;
typedef _OctStr Ipv6Address;
typedef struct IP_Address_ipaddress {
unsigned short choice;
# define ipv4info_chosen 1
# define ipv6info_chosen 2
union {
Ipv4Address *ipv4info; /* to choose, set choice to ipv4info_chosen */
Ipv6Address *ipv6info; /* to choose, set choice to ipv6info_chosen */
} u;
} IP_Address_ipaddress;
/* allocates memory for an empty instance of the choice type */
#define oss_IP_Address_ipaddress_new(world) \
(IP_Address_ipaddress *)ossGetInitializedMemory(world,
sizeof(IP_Address_ipaddress))
/* gets index of currently selected alternative */
#define oss_IP_Address_ipaddress_which(inp) \
(inp)->choice
/* gets "ipv4info" alternative value */
#define oss_IP_Address_ipaddress_ipv4info_get(inp) \
(inp)->u.ipv4info
/* selects "ipv4info" alternative and sets its value */
#define oss_IP_Address_ipaddress_ipv4info_set(outp, ipv4info_) \
{ \
(outp)->choice = ipv4info_chosen; \
(outp)->u.ipv4info = (ipv4info_); \
}
Capitolo 3. Il Progetto 41
typedef struct IP_Address {
struct IP_Address_ipaddress *ipaddress;
struct ProtocolExtensionContainer *iE_Extensions; /* NULL for not
* present */
} IP_Address;
/* allocates memory for IP_Address_PDU */
#define oss_IP_Address_new_pdu(world) \
(IP_Address *)ossGetInitializedMemory(world, sizeof(IP_Address))
/* gets "ipaddress" field value */
#define oss_IP_Address_ipaddress_get(inp) \
(inp)->ipaddress
/* sets "ipaddress" field value */
#define oss_IP_Address_ipaddress_set(outp, ipaddress_) \
(outp)->ipaddress = (ipaddress_)
/* Macros for "ipaddress" field operate with ’IP_Address_ipaddress’ type; you
* may use macros after this type declaration to create its values */
/* gets "iE_Extensions" field value */
#define oss_IP_Address_iE_Extensions_get(inp) \
(inp)->iE_Extensions
Da queste definizioni sono state omesse la maggioranza delle macro di supporto alla
costruzione dell’albero degli IE che costituisce le PDU.
Sebbene l’idea di fornire un ausilio alla manipolazione di queste strutture sia valida,
all’atto pratico le macro autogenerate risultano quasi piu complesse da utilizzare delle
strutture stesse. L’uso delle macro ha come principale effetto negativo quello di occultare
il tipo di dato manipolato, portando spesso alla costruzione di strutture improprie senza
generare avvertimenti. Inoltre la loro lunghezza smodata
(oss CriticalityDiagnostics iEsCriticalityDiagnostics is present), non e di grande aiuto
in fase di scrittura del codice e tanto meno in lettura.
E compito dello sviluppatore popolare correttamente le PDU con i dati che compogono
i messaggi. Una volta fatto, la struttura viene passata come parametro alla funzione
oss encode, appartenente alle runtime libraries. Questa funzione si occupera di verificare
Capitolo 3. Il Progetto 42
la correttezza della struttura definita, e di convertirla in formato binario codificato PER,
pronta per essere spedita.
In fase di decoding avviene il processo inverso. Da una stringa di valori binari codificata
secondo lo schema PER, la funzione oss decode, previa verifica dei vincoli del messaggio,
restituisce una PDU, che dovra essere analizzata dalle funzioni di controllo del protocollo.
3.3.1 Struttura delle librerie di gestione dei protocolli
Lo schema architetturale delle librerie che gestiscono entrambe i protocolli RUA e
HNBAP si presenta identico, ed e rappresentato nella figura 3.5.
Figura 3.5: Struttura delle librerie librua e libhnbap.
Ogni libreria e composta da una parte di controllo, all’interno della quale sono imple-
mentate le funzioni chiamate dai layer superiore inferiore e alla ricezione dei messaggi.
Quando le funzioni di controllo lo richiedono, un modulo interno alla libreria si occupa
di costruire la PDU del messaggio richiesto selezionando i valori opportuni. Una volta
fatto, la struttura in memoria viene inviata al modulo di OSS, e da questo inviata al
layer inferiore per essere spedito una volta completata la fase di encoding. La libreria
scambia con il layer inferiore attraverso l’API, sia i messaggi codificati sia chiamate re-
ciproche per la notifica di eventi come connessioni e disconnessioni, variazioni nel buffer
di invio ecc.
La parte delle librerie risultata essere maggiormente complessa e la causa della maggior
parte dei bug riscontrati e stata la fase di costruzione delle PDU da codificare. L’elevato
numero di strutture annidate che fanno parte di diversi messaggi, le difficolta nell’uso
Capitolo 3. Il Progetto 43
delle macro prodotte dalla suite OSS e l’elevato livello di branching del codice per la
selezione dei giusti IE ha rappresentato un ostacolo importante al raggiungimento della
stabilita, ed e stato fonte di innumerevoli crash dell’applicativo a causa di errori nella
gestione della memoria in fase di encoding.
Capitolo 4
Validazione e testing
La libreria sviluppata, e stata sottoposta a diversi test per verificarne la correttezza e
l’aderenza allo standard.
4.1 Verifica del codice
La programmazione in C per le caratteristiche del linguaggio porta spesso alla gen-
erazione di bug molto difficili da tracciare senza strumenti adeguati. La tipizzazione
debole e l’assenza di meccanismi di gestione autmatica della memoria molto comuni nei
linguaggi piu moderni, come l’uso di garbage collector, sono allo stesso tempo la forza
ed la debolezza di questo linguaggio.
Gli innegabili vantaggi in termini di efficenza e flessibilita si scontrano con frequenti
errori causati dalla corruzione della memoria (stack overflow ed heap overflow), errori
di accesso a zone di memoria non valide (segmentation fault) o problemi di memory leak
dati dal mancato rilascio di memoria precedentemente allocata, che portano facilmente
alla saturazione delle risorse di sistema.
Anche il corretto funzionamento del programma non garantisce affatto l’assenza di questi
o altri difetti, che possono facilmente passare inosservati per lungo tempo per presentarsi
nei momenti meno opportuni. Anche se le dimostrazioni pubbliche o la presentazione
del lavoro svolto ai propri superiori sono di grande aiuto nello scovare questi proble-
mi, l’utilizzo preventivo di strumenti di analisi, spesso risulta piu efficace e molto meno
stressante.
Sono pertanto stati adottati diversi tools di grande aiuto nella verifica della correttezza
del codice.
44
Capitolo 4. Validazione e testing 45
Tool per l’analisi statica:
l’analisi statica del codice e stata effettuata attraverso l’uso di Clang Static Analyzer
[10], uno strumento sviluppato sulla base del compilatore open source clang [11]. Questo
tool utilizzato in fase di compilazione identifica una notevole quantita di errori non
rilevati dal compilatore1. Una volta lanciato l’analizzatore applica tecniche di esecuzione
simbolica ai sorgenti valutando ogni possibile path alla ricerca di difetti. Al termine
della procedura viene generato un report in formato html che indica dettagliatamente
che operazioni non corrette sono state identificate (estratto del report in figura 4.1).
Figura 4.1: Segnalazione di un errore in un report di Clang Static Analyzer.
Sebbene la lista dei check eseguiti dall’analizzatore statico sia ampia[12], ed abbia porta-
to a correggere diversi problemi, molti dei quali non ancora notati, questo tool e ancora
in fase di sviluppo e non del tutto affidabile. Se pure lo fosse l’assenza di errori identificati
duranti un’analisi non potrebbe comunque garantire l’assenza di difetti nel software.
Tools per l’analisi dinamica:
Durante lo svolgimento dei test sono stati utilizzati alternativamente due tool differenti
e complementari per verificare il corretto uso della memoria.
• valgrind [13] strumento molto noto e comunemente utilizzato nello sviluppo di
software in C/C++. Dispone di diversi moduli, tra i quali Memcheck, strumento
utilizzato per verificare la corretta manipolazione della memoria. Il principale
difetto e costituito l’incapacita di questo tool di identificare errori di overflow su
variabili locali e globali.
• Clang Address Sanitizer [14] questo tool, anc’esso parte del progetto clang come
lo static analyzer, ha permesso di rilevare gli errori non gestiti dal precedente stru-
mento ma la sua incapacita di rilevare memory leaks e letture in settori di memoria
non inizializzati l’anno reso uno strumento complementare e non un alternativa.
1L’uso del compilatore clang (che effettua controlli molto stringenti al codice) in alternativa a gcc,ha permesso l’identificzione diversi problemi in fase di compilazione che precedentemente non venivanosegnalati
Capitolo 4. Validazione e testing 46
4.2 Validazione e test di integrazione
La maggior parte dell’input ed output della libreria consiste nei pacchetti RUA ed HN-
BAP generati. Benche la correttezza sintattica della struttura dati sia garantita dalla
libreria OSS in fase di encoding/decoding, la validita semantica e la congruenza dei dati
inseriti sul messaggio non sono assicurate.
Sono quindi stati sviluppati diversi test preliminari alla fase di integrazione per verificare
che la libreria operasse in modo atteso in risposta. A tal scopo si e fatto uso di check
[15] dei un framework utile nelle fasi di automazione facilmente integrabile nel sistema
di building del software.
E stato quindi possibile automatizzare la verifica delle seguenti componenti:
• Procedure interne alla libreria. Funzioni non esportate per essere utilizzate ester-
namente ma necessarie al funzionamento interno.
• Verifica della corretta codifica/decodifica dei messaggi. E stato verificato che i dati
inviati tramite messaggi del protocollo risultassero invariati dopo diversi cicli di
encoding e decoding successivi.
• Verifica della corretto funzionamento delle API. Simulando azioni di layer superiore
ed inferiore e stato verificato il corretto comportamento da parte della libreria.
4.2.1 L’emulazione della femtocella
Consapevoli del fatto che i primi modelli di femtocelle che avrebbero supportato l’in-
terfaccia IuH non sarebbero stati disponibili ancora per diversi mesi dopo il termine del
programmato del periodo di stage, per verificare la corretta integrazione della libreria
nel sistama e stato necessario sviluppare un simulatore che potesse fare le veci di uno o
piu HNB. A tal scopo la libreria e stata sviluppata fin dall’inizio per poter operare da
ambo i lati dell’interfaccia in modo configurabile. Inizializzandola in modo opportuno
si possono quindi attivare le funzioni di controllo e di encoding/decoding dei messaggi
proprie di un HNB anziche quelle che verranno usate nel sistema proprie dell’HNB-GW.
I protocolli dei livelli superiori e inferiori gia sviluppati dall’azienda seguivano questo
stesso approccio, quindi gran parte delle procedure richieste per implementare un simu-
latore completo sono consistite nell’integrazione della libreria nello stesso modo nel quale
e entrata a far parte del lato CN.
Il simulatore di HNB riproduce le richieste degli UE in modo accurato e per fare questo
si appoggia ad una basi di dati in comune con il CN (messa a disposizione dall’HSS
Capitolo 4. Validazione e testing 47
Figura 4.2: Simulatore di Femtocelle.
integrato nel sistema) per ottenere identita e parametri di autenticazione validi per che
non verranno rigettati durante i tentativi di accesso.
Ogni identita cosı ottenuta viene associata ad uno UE fittizzio e questi vengono utilizza-
ti per rappresentare differenti scenari. In alcuni di questi l’HNB invia deliberatamente
messaggi non validi, in altri effettua operazioni valide prima di simulare le operazioni
di diversi UE, dei quali alcuni effettuano connessioni e disconnesioni frequenti, altri ri-
mangono connessi a lungo, altri ancora inviano informazioni corrotte o in modo non
compatibile con lo standard.
Ad ogni passaggio viene verificato che le risposte ricevute dal CN siano quelle attese; in
caso l’esito non sia quello programmato la procedura viene interrotta e viene riportato
un errore e le informazioni utili per tracciare il problema.
Piu istanze del simulatore possono essere lanciate concorrentemente per verificare che
il sistema operi correttamente anche con un numero elevato di HNB connessi. Grazie
a questo approccio e stato possibile riprodurre diversi scenari per verificare in modo
semiautomatizzato che gli esiti delle procedure implementate fossero quelli attesi.
4.2.2 Test finale di interoperabilita
Una volta ottenuto il primo modello di femtocella che implementasse il supporto all’in-
terfaccia IuH e stato possibile effettuare i test sul campo attraverso l’uso di apparecchi
reali e non piu simulati. Come si puo vedere nel tracciato riportato nella figura 4.3,
l’integrazione e stata portata a termine con successo.
• Registrazione dell’HNB attraverso il protocollo HNBAP, pacchetti 165 e 167.
• Inizializzazione del protocollo RANAP trasportati attraverso RUA via Connec-
tionless Transfer Message, pacchetti dal 169 al 197.
Capitolo 4. Validazione e testing 48
• Registrazione di uno UE attraverso il protocollo HNBAP, pacchetti nr. 201 e 202.
• Inizializzazione di un flusso RANAP dallo UE attraverso richiesta di Connect del
protocollo RUA, pacchetto 204.
• Trasporto del traffico RANAP da/verso lo UE tramite RUA Direct Transfer,
pacchetti dal 206 al 226.
• Interruzione del flusso RANAP tramite RUA Disconnect, pacchetto 227.
• Paging RANAP messaggio broadcast tramite RUA Connectionless Transfer, pac-
chetti 233 e 239.
In questa fase sono state necessarie solamente alcune modifiche di minor entita causate
da alcuni dettagli implementativi per permettere il corretto funzionamento con la fem-
tocella, confermando quindi la validita dei test precedentemente effettuati attraverso
l’uso del simulatore. I test effettuati con diversi apparecchi hanno sempre dato esito
positivo pertanto si puo assumere che l’implementazione dei protocolli sia conforme allo
standard.
Capitolo 4. Validazione e testing 49
Figura 4.3: Traccia dei protocolli RUA ed HNBAP catturata durante la connessionedi un cellulare.
Capitolo 5
Conclusioni
Le startup tecnologiche nel panorama italiano sono abbastanza rare, e tra queste quasi
nessuna si occupa di telecomunicazioni mobili, un ambiente dominato quasi totalmente
dalle multinazionali del settore. I sistemi trattati sono estremamente complessi e richiedono
vaste competenze in differenti ambiti. Le stesse specifiche tecniche che li definiscono sono
difficilmente fruibili da chi non ha delle solide basi o non ha seguito costantemente la
loro evoluzione col passare del tempo. Le risorse economiche e logistiche richeste sono
proibitive per una piccola azienda, basti pensare che il costo di un MSC e nell’ordine
dei milioni di euro e richiede in genere il supporto di diversi tecnici specializzati per
gestirne la configurazione. Allo stesso modo per l’acquisto di sistemi di testing atti a
verificare che un protocollo sviluppato sia aderente agli standard si deve essere pronti
al’esborso di diverse centinaia di migliaia di euro. Questi ed altri fattori sono un grande
freno per chi tenta di farsi strada in questo settore, ma possono anche rappresentare uno
stimolo che spinge a cercare soluzioni innovative (e piu economiche) per affrontare gli
stessi problemi per i quali vengono messe in campo un gran numero di risorse. Tutto
questo rendere ogni attivita di una startup che tenta di farsi strada in questo mercato
una vera sfida, ed un’esperienza di davvero entusiasmante.
Ogni compito viene affrontato con metodo collaborando con il team in tutte le fasi dello
sviluppo del prodotto. Dallo studio dei dei reqisiti richiesti, alla ricerca delle soluzioni in
fase di progettazione fino alla loro realizzazione ed al testing, si lavora per delineare ed
introdurre un processo di sviluppo ben strutturato e ritagliato sulle esigenze dell’azienda,
che nella sua breve vita non ha ancora avuto il tempo di adottarne uno di stabile.
Il progetto portato a termine ha rappresentato una via ottimale per immergersi in queste
dinamiche. Nonostante l’impatto con la disarmante complessita dei sistemi di telefonia
cellulare possa essere un grande ostacolo da affrontare, l’interfaccia IuH ha permesso un
50
Capitolo 5. Conclusioni 51
approccio graduale, richiedendo la comprensione di un dominio architetturale abbastan-
za ristretto. Passo per passo sono state affrontate tutte le difficolta techiche incontrate,
accrescendo man mano le competenze. Grazie al supporto ricevuto dal tutor aziendale
e stato possibile realizzare un prodotto che si e dimostrato estremamente valido e che
offre il suo piccolo ma fondamentale contributo all’interno di un sistema piu ampio che
e il vanto dell’azienda ed ha stupito e soddisfatto diversi clienti.
L’interfaccia IuH che e sviluppata durante questo progetto e stata implementata secon-
do le indicazioni della Release 9 dello standard 3GPP per mantenersi consistente con
la versione degli altri componenti del sistema PRIMO. Alcune modifiche potrebbero es-
sere necessarie per conformarsi alle nuove versioni, (l’ultima delle quali e la Release 10
rilasciata alla fine del 2011) ma attualmente le differenze introdotte dallo standard sono
limitate a poche correzioni nell’uso di alcuni particolari information element dei quali
non viene fatto uso.
Nonostante sia stata standardizzata da breve tempo, l’IuH e gia stata ampiamente adot-
tata nonostante l’imminente arrivo delle tecnologie mobili di quarta generazione che
stanno gia cominciando a diffondersi. La loro architettura semplifica di molto quella
3G, definendo un’interfaccia comune per NodeB e femtocelle, completamente differente
rispetto a quella presente nel sistema UMTS. Nell’industria e diffusa la convinzione che
la quarta generazione non soppiantera immediatamente la terza che l’ha preceduta ed
anzi le due tecnologie sono destinate a convivere ancora per lungo tempo. Le prossime
femtocelle (o small cells come vengono da poco chiamate) che implementeranno il sis-
tema radio LTE dovranno essere retrocompatibili con il 3G attraverso l’interfaccia IuH
ed implementare la nuova interfaccia chiamata S1 per il 4G.
Per concludere si fa menzione del fatto che grazie al buon esito del progetto di stage
l’azienda ha proposto all’autore di sviluppare anche quest’ultima interfaccia offrendo
allo stesso tempo impiego stabile nel team di ricerca e sviluppo.
La proposta e stata accettata con piacere.
Appendice A
Riferimenti esterni alle specifiche
di implementazione
Segue la lista delle specifiche tecniche riporanti i dettagli del contesto architetturare e
dei protocolli trattati.
Ente Riferimento Titolo del documento
3GPP TR 21.905 Vocabulary for 3GPP Specifications
3GPP TS 25.401 UTRAN Overall Description
3GPP TS 25.413 Radio Access Network Application Part (RANAP)
3GPP TS 25.444 Iuh Interface Data Transport and Transport Signalling
3GPP TS 25.467 Architecture for the 3G Home Node B (HNB)
3GPP TS 25.468 Iuh Interface RANAP User Adaptation (RUA) signalling
3GPP TS 25.469 Iuh Interface HNB B Application Part (HNBAP) signalling
3GPP TS 25.921 Guidelines for Protocol Description and Error Handling
3GPP TS 29.060 GTP across Gn and Gp.
3GPP TS 29.281 GPRS Tunneling Protocol User Plane (GTP-u).
IETF RFC791 Internet Protocol
IETF RFC1889 RTP
IETF RFC2474 Definition of Differential Services Field
IETF RFC3550 RTP - obsoletes RFC1889
IETF RFC4301 Security Architecture for the Internet Protocol
IETF RFC4960 SCTP
ITU-T X.680 (07/2002) ASN.1: Specification of basic notation
ITU-T X.681 (07/2002) ASN.1: Information object specification
ITU-T X.691 (07/2002) ASN.1: Specification of Packed Encoding Rules (PER)
52
Bibliografia
[1] Nokia Siemens Network. Next generation private mobile network
is born, 2011. http://us.nokiasiemensnetworks.com/about-us/
partners/channel-partner-program/partner-news/april-2011/
next-generation-private-mobile-network-is-born.
[2] Nokia Siemens Network. Private network meets mobile broadband de-
mand at italian science park, 2011. http://us.nokiasiemensnetworks.
com/portfolio/customer-successes/success-stories/
private-network-meets-mobile-broadband-demand-at-italian-science-park.
[3] Area Science Park. A el malki e verin (athonet) la medaglia del presidente del-
la repubblica, 2012. http://press.area.trieste.it/ita/comunicati-stampa/
2012/6/athonet_nuvolaverde.aspx.
[4] TuttoGreen.it. Cronache dal terremoto: come una start-up italiana por-
ta la banda larga a mirandola, 2012. http://www.tuttogreen.it/
cronache-dal-terremoto-come-una-start-up-italiana-porta-la-banda-larga-a-mirandola/.
[5] Kleiner Perkins Caufield and Byers. 2012 internet trends, 2012. http://www.kpcb.
com/insights/2012-internet-trends.
[6] R. Kreher and T. Ruedebusch. Umts Signaling: Umts Interfaces, Protocols, Message
Flows and Procedures Analyzed and Explained. John Wiley & Sons, 2012. ISBN
9781118408599. URL http://books.google.it/books?id=9qOGOuuN3u8C.
[7] Ulrike Meyer and Susanne Wetzel. A man-in-the-middle attack on umts. In Proceed-
ings of the 3rd ACM workshop on Wireless security, WiSe ’04, pages 90–97, New
York, NY, USA, 2004. ACM. ISBN 1-58113-925-X. doi: 10.1145/1023646.1023662.
URL http://doi.acm.org/10.1145/1023646.1023662.
[8] Eli Biham, Orr Dunkelman, and Nathan Keller. A related-key rectangle attack
on the full kasumi. In Proceedings of the 11th international conference on Theory
and Application of Cryptology and Information Security, ASIACRYPT’05, pages
53
Bibliography 54
443–461, Berlin, Heidelberg, 2005. Springer-Verlag. ISBN 3-540-30684-6, 978-
3-540-30684-9. doi: 10.1007/11593447 24. URL http://dx.doi.org/10.1007/
11593447_24.
[9] Orr Dunkelman, Nathan Keller, and Adi Shamir. A practical-time attack on the
a5/3 cryptosystem used in third generation gsm telephony. Cryptology ePrint
Archive, Report 2010/013, 2010. http://eprint.iacr.org/.
[10] Clang static analyzer, . http://clang-analyzer.llvm.org/.
[11] Clang, an llvm native c/c++/objective-c compiler, . http://clang.llvm.org/.
[12] Clang address sanitizer available checks, . http://clang-analyzer.llvm.org/
available_checks.html.
[13] Valgrind, an instrumentation framework for building dynamic analysis tools. http:
//valgrind.org/.
[14] Clang address sanitizer, . http://code.google.com/p/address-sanitizer/.
[15] Check: A unit testing framework for c. http://check.sourceforge.net/.