Implementazione dell’interfaccia I

62
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

Transcript of Implementazione dell’interfaccia I

Page 1: Implementazione dell’interfaccia I

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

Page 2: Implementazione dell’interfaccia I
Page 3: Implementazione dell’interfaccia I

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.

Page 4: Implementazione dell’interfaccia I

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

Page 5: Implementazione dell’interfaccia I

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

Page 6: Implementazione dell’interfaccia I

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

Page 7: Implementazione dell’interfaccia I

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

Page 8: Implementazione dell’interfaccia I

A tutti quelli che mi hanno giustamente scocciato affiche portassi atermine quest’opera. . .

viii

Page 9: Implementazione dell’interfaccia I

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

Page 10: Implementazione dell’interfaccia I

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,

Page 11: Implementazione dell’interfaccia I

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

Page 12: Implementazione dell’interfaccia I

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

Page 13: Implementazione dell’interfaccia I

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

Page 14: Implementazione dell’interfaccia I

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.

Page 15: Implementazione dell’interfaccia I

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

Page 16: Implementazione dell’interfaccia I

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 .

Page 17: Implementazione dell’interfaccia I

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

Page 18: Implementazione dell’interfaccia I

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.

Page 19: Implementazione dell’interfaccia I

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

Page 20: Implementazione dell’interfaccia I

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

Page 21: Implementazione dell’interfaccia I

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].

Page 22: Implementazione dell’interfaccia I

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.

Page 23: Implementazione dell’interfaccia I

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.

Page 24: Implementazione dell’interfaccia I

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.

Page 25: Implementazione dell’interfaccia I

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.

Page 26: Implementazione dell’interfaccia I

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

Page 27: Implementazione dell’interfaccia I

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

Page 28: Implementazione dell’interfaccia I

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

Page 29: Implementazione dell’interfaccia I

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

Page 30: Implementazione dell’interfaccia I

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

Page 31: Implementazione dell’interfaccia I

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.

Page 32: Implementazione dell’interfaccia I

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

Page 33: Implementazione dell’interfaccia I

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

Page 34: Implementazione dell’interfaccia I

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

Page 35: Implementazione dell’interfaccia I

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

Page 36: Implementazione dell’interfaccia I

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.

Page 37: Implementazione dell’interfaccia I

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.

Page 38: Implementazione dell’interfaccia I

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

Page 39: Implementazione dell’interfaccia I

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

Page 40: Implementazione dell’interfaccia I

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.

Page 41: Implementazione dell’interfaccia I

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.

Page 42: Implementazione dell’interfaccia I

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.

Page 43: Implementazione dell’interfaccia I

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:

Page 44: Implementazione dell’interfaccia I

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},

...

}

Page 45: Implementazione dell’interfaccia I

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.

Page 46: Implementazione dell’interfaccia I

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 {

Page 47: Implementazione dell’interfaccia I

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:

Page 48: Implementazione dell’interfaccia I

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_); \

}

Page 49: Implementazione dell’interfaccia I

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

Page 50: Implementazione dell’interfaccia I

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

Page 51: Implementazione dell’interfaccia I

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.

Page 52: Implementazione dell’interfaccia I

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

Page 53: Implementazione dell’interfaccia I

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

Page 54: Implementazione dell’interfaccia I

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

Page 55: Implementazione dell’interfaccia I

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.

Page 56: Implementazione dell’interfaccia I

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.

Page 57: Implementazione dell’interfaccia I

Capitolo 4. Validazione e testing 49

Figura 4.3: Traccia dei protocolli RUA ed HNBAP catturata durante la connessionedi un cellulare.

Page 58: Implementazione dell’interfaccia I

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

Page 59: Implementazione dell’interfaccia I

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.

Page 60: Implementazione dell’interfaccia I

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

Page 61: Implementazione dell’interfaccia I

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

Page 62: Implementazione dell’interfaccia I

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/.