Progetto di un sistema per la personalizzazione dei ...teca.elis.org/1134/Tesi_Cianfanelli.pdf ·...

Università degli studi ‘Tor Vergata’ ROMA

FACOLTÀ DI INGEGNERIA

Tesi di Laurea in Ingegneria Informatica

Progetto di un sistema

per la personalizzazione

dei servizi in ambiente UMTS

Maurizio Cianfanelli

Relatore:

Prof. S. Tucci

Correlatore:

G. De Zen

Anno Accademico 2000/2001

1

Indice

Introduzione 1

1 Evoluzione delle reti mobili 5 1.1 Reti di seconda generazione 8

1.1.1 Personalizzazione nelle reti di seconda generazione 11

1.2 Reti di generazione 2.5 12 1.2.1 Personalizzazione nelle reti di generazione 2.5 15

1.3 Reti di terza generazione 19 1.3.1 Rete UMTS 20

2 Personalizzazione dei servizi nelle reti di terza generazione 28

2.1 Virtual Home Environment 29 2.2 Personal Service Environment 31

2.2.1 Profilo dell’utente nel Virtual Home Environment 33

2.3 Gestione del profilo utente 36 2.3.1 Descrizione del profilo 42

2.4 Personalizzazione dei servizi 44

2

2.4.1 Peculiarità dell’utente 45 2.4.2 Contesto di un utente 47

2.4.2.1 Terminale mobile 49 2.4.3 Caratteristiche dei servizi 53

3 Estensioni del Generic User Profile 55 3.1 “Enabling Services” supportati 57

3.1.1 Servizio di presenza 58 3.1.1.1 Attori all’interno del servizio di

presenza 59 3.1.1.2 Informazioni di presenza 60 3.1.1.3 Evoluzione del servizio di presenza 64 3.1.1.4 Relazione tra gestione del profilo e

contesto 66 3.1.2 Servizio di localizzazione 69

3.1.2.1 Relazione tra gestione del profilo e servizio di localizzazione 72

3.2 Gestione delle terminal capabilities 73

4 Obiettivi e requisiti di progetto 75 4.1 Obiettivi del progetto 75 4.2 Assunzioni 77 4.3 Requisiti funzionali 77

4.3.1 Registrazione di un nuovo utente 81 4.3.2 Autenticazione e Autorizzazione 82

4.3.2.1 Autenticazione 83 4.3.2.2 Autorizzazione 83

4.3.3 Sottoscrizione on-line ad un servizio 85 4.3.4 Gestione informazioni dell’utente 86

4.3.4.1 Gestione informazioni generali 86 4.3.4.2 Gestione User Preferences 87

4.3.5 Gestione sub profile 90

3

4.3.5.1 Inserimento sub-profile 91 4.3.5.2 Modifica sub-profile 92 4.3.5.3 Cancellazione sub-profile 93 4.3.5.4 Scelta Default sub-profile 94 4.3.5.5 Scelta Active sub profile 94

4.3.6 Funzionalità per la gestione di Access List 96 4.3.6.1 Gestione Access List 97 4.3.6.2 Gestione Tuple 98

4.3.7 Personalizzazione dei servizi offerti dall’operatore e da HE-VASP 99 4.3.8 Richiesta di informazioni da parte di un

servizio 101 4.3.9 Notifica cambiamenti di contesto 103 4.3.10 Gestione terminal capabilities 103

4.4 Requisiti non funzionali 105 4.4.1 Accessibilità 105 4.4.2 Estendibilità 105 4.4.3 Gestione distribuita 105 4.4.4 Privacy 106 4.4.5 Esecuzione concorrente 106

4.5 Il linguaggio UML 106 4.5.1 Introduzione 107 4.5.2 Class Diagram 108 4.5.3 Interaction Diagram 109 4.5.4 Package Diagram 109 4.5.5 State Diagram 110 4.5.6 Activity Diagram 110 4.5.7 Deployment Diagram 111

5 Tecnologie di sviluppo 112 5.1 Linguaggio Java 113

5.1.1 Remote Method Invocation 113

4

5.1.1.1 Principi alla base del meccanismo RMI 114

5.1.1.2 Architettura del sistema RMI 115 5.1.1.3 Java Servlet 116

5.2 Linguaggio XML 118 5.2.1 Programmazione con XML 121

5.3 Protocollo http 122 5.3.1 Gestione delle sessioni e sicurezza 124

5.4 Protocollo SIP 125

6 Progetto dello User Profile Manager 130 6.1 Struttura del Generic User Profile 130

6.1.1 Basic Profile 132 6.1.1.1 General Information 132 6.1.1.2 User Preferences 133

6.1.2 Service Profile 134 6.1.3 Context Profile 135

6.1.3.1 Capabilities description 135 6.1.3.2 Context Information 138

6.2 Architettura del sistema 139 6.2.1 Scenario di riferimento 139

6.2.1.1 User Browser 140 6.2.1.2 Servizi 141 6.2.1.3 DataBase 144 6.2.1.4 Context Server 146 6.2.1.5 Modalità di comunicazione 146

6.2.2 User Profile Manager 147

6.3 Processo di personalizzazione proposto 150 6.3.1 Adattamento del contenuto 152 6.3.2 Aggregazione dei contenuti 153 6.3.3 Adattamento alle capabilities 154

5

6

6.3.4 Qualità del servizio 155

7 Progetto componenti software e interfacce 156 7.1 User Profile Access Manager 156

7.1.1 Servizi offerti allo User Request Manager 158 7.1.2 Servizi offerti al Personalization Manager 160

7.2 Data Manager 161 7.2.1 Servizi offerti a User Request Manager e Personalization Manager 162

7.2.1.1 Gestione dati di registrazione 162 7.2.1.2 Gestione component del profilo 163 7.2.1.3 Gestione Access List relative

al Context Server 164 7.2.1.4 Gestione Sub Profile 167

7.2.2 Servizi offerti allo User Profile Access Manager 169

7.2.2.1 Fornitura Access List per autorizzazione 169

7.2.2.2 Verifica registrazione 170 7.2.3 Servizi offerti al Watcher SIP Handler 170 7.2.4 Wrapper 171

7.3 Personalization Manager 171 7.4 Watcher SIP Handler 176 7.5 User Request Manager 177 7.6 Interazione tra i sottosistemi 177

7.6.1 Autenticazione utente 177 7.6.2 Gestione component del profilo 180

7.6.2.1 Inserimento istanza 180 7.6.2.2 Modifica istanza 181 7.6.2.3 Cancellazione istanza 183

7.6.3 Gestione sub profile 185

7.6.3.1 Inserimento sub profile 186 7.6.3.2 Modifica sub profile 187 7.6.3.3 Cancellazione sub profile 189 7.6.3.4 Scelta dell’Active Sub Profile 191 7.6.3.5 Scelta automatica dell’Active Sub

Profile 192 7.6.4 Gestione Access List 191

7.6.4.1 Creazione Access List 194 7.6.4.2 Modifica Access List 196 7.6.4.3 Cancellazione Access List 198 7.6.4.4 Creazione tupla 200 7.6.4.5 Modifica tupla 202 7.6.4.6 Cancellazione tupla 204

7.6.5 Autenticazione servizio 206 7.6.6 Richiesta informazioni da parte di un servizio 207 7.6.7 Notifica cambiamenti dei parametri di contesto 208

8 Conclusioni e sviluppi futuri 210 8.1 Conclusioni 210 8.2 Sviluppi futuri 212

Appendice A 213

Appendice B 220

Bibliografia 226

7

Introduzione

L’evoluzione del mondo delle telecomunicazioni mobili, in questi ultimi

anni, è stata indirizzata verso la produzione di nuovi standard che permettano la

convergenza della tecnologia wireless verso il mondo Internet. Esempi di questa

strategia evolutiva sono lo standard WAP (Wireless Application Protocol),

definito in WAP Forum, che offre il servizio di browsing su un terminale mobile e

lo standard GPRS (General Packet Radio Service), standardizzato da 3GPP (3rd

Generation Partnership Project), che permette l’accesso ai servizi IP in condizioni

di mobilità. Tale convergenza sarà molto netta quando si diffonderanno sul

mercato i terminali mobili della prossima generazione. I nuovi terminali

presenteranno infatti capacità elaborative che consentiranno all’utente il

trattamento di contenuti multimediali come voce, testo, immagini e video.

La rete Internet sta subendo, d’altra parte, un rapidissimo sviluppo dovuto

al grandissimo numero di informazioni che distribuisce e alla moltitudine di

servizi che offre. Tale sviluppo comporta oltre ai tangibili miglioramenti in molti

settori (commercio elettronico, home banking), anche una grande difficoltà nel

reperimento di informazioni realmente utili. Un fattore chiave per il successo

delle reti wireless di terza generazione sarà la personalizzazione dei servizi offerti

all’utente mobile, che si dovrà basare sulle caratteristiche e sulle preferenze

individuali di ogni utente.

Lo scopo principale del processo di personalizzazione di un servizio è

rendere l’uso dei servizi più immediato e mirato alle preferenze dell’utente,

filtrando così su un’enorme quantità di dati disponibili le informazioni realmente

8

utili. Nel mondo mobile, data la eterogeneità dei terminali disponibili, è molto

importante la capacità di personalizzare un servizio sulla base delle caratteristiche

del terminale dell’utente. Il concetto di personalizzazione è in genere basato sulle

informazioni personali dell’utente e sulle sue preferenze ma non potrà esulare dal

considerare il contesto in cui si trova l’utente, ad esempio ufficio, casa, etc.

Il contesto è un insieme eterogeneo di informazioni che caratterizzano un

utente in un qualsiasi momento ed in un qualsiasi luogo. Un esempio di tali

informazioni è la locazione dell’utente. Considerare il contesto di un utente come

elemento di personalizzazione, oltre alle sue preferenze, apre la strada allo

sviluppo di una serie di servizi che potranno essere sia pensati in modo specifico

per il mondo wireless, sia presi da Internet ed adattati. Ad esempio, i servizi di

Instant Messaging, nati nel mondo Internet, potranno essere trasferiti ad utenti

mobili utilizzando l’informazione di presenza di un utente nella rete, cioè

dell’effettiva possibilità che in quel momento ha l’utente di comunicare. Quindi

l’informazione di presenza come quella di locazione è parte dell’insieme delle

informazioni di contesto associate ad un utente. Il servizio che si occupa di fornire

le informazioni di contesto un utente mobile è tuttora in fase di standardizzazione

all’interno del 3GPP, ente che si sta occupando dello sviluppo delle reti di terza

generazione.

Dalla presentazione di questi scenari risulta molto chiaro che la

personalizzazione diventa un fattore chiave per servizi rivolti ad utenti mobili,

poiché il terminale diventerà nel prossimo futuro un assistente personale

dell’utente che offrirà opportunità per l’adattamento real time dei servizi

all’ambiente dinamico in cui l’utente si trova. Nel futuro quindi l’obiettivo di

operatori di rete, fornitori di servizi e fornitori di contenuti sarà quello di

cooperare insieme per dare servizi personalizzati allo scopo di soddisfare esigenze

specifiche dell’utente sollevate dalla situazione in cui si viene a trovare.

La soluzione alle problematiche della personalizzazione è quella di fornire

all’utente un ambiente che in 3GPP prende il nome di Personal Service

Environment (PSE) che gli consenta di personalizzare ed usare servizi secondo le

sue necessità in base alle sue preferenze. Alla base del PSE vi sono le

informazioni relative all’utente quindi il suo profilo che può essere distribuito tra i

9

diversi elementi coinvolti nella fornitura di un servizio, quindi rete, terminale ed il

servizio stesso. Le informazioni di profilo contenute nei diversi elementi della rete

mobile coinvolti nella fornitura del servizio costituiscono il Generic User Profile

(GUP) definito da 3GPP. Lo scopo del GUP è fornire una descrizione estendibile

di tutte le informazioni che costituiscono il profilo di un utente. Queste

informazioni vengono divise logicamente in due sottoinsiemi: informazioni

“service independent” e informazioni “service dependent”. Le prime

rappresentano le informazioni personali e le preferenze generali dell’utente,

mentre le seconde ,denominate anche Service profile, rappresentano le preferenze

dell’utente relative ai servizi a cui si sottoscrive. L’utente può definire e attivare

diversi sotto-profili, “sub-profile”, in modo da poter differenziare le sue

preferenze in base alla situazione in cui si trova, ad esempio attivare il sub-profile

‘casa’ o il sub-profile ‘ufficio’ a seconda del contesto in cui si trova.

Il PSE fornisce supporto sia all’utente, permettendogli di gestire le sue

informazioni di profilo, sia ai servizi, fornendo loro informazioni sulle preferenze

di un utente utili nel processo di personalizzazione.

Il PSE rientra all’interno di un concetto più ampio denominato Virtual

Home Environment (VHE) . Il concetto di VHE consiste nel presentare all’utente

in una “visited network” i suoi servizi con le stesse caratteristiche della sua “home

network”.

Il lavoro di tesi ha avuto come obiettivo la progettazione di un sistema per

la gestione delle informazioni di profilo utente nel contesto dei servizi mobili di

terza generazione e la definizione di un processo di personalizzazione di tali

servizi. Come punto di partenza di tale attività si sono utilizzati i concetti di VHE,

PSE, GUP assieme a quelli di presenza e contesto. Il sistema, in oggetto,

interagisce con gli utenti tramite un interfaccia Web fornendo loro la possibilità di

gestire le proprie informazioni di profilo sia statiche che dinamiche (contesto).

Fornisce, inoltre,supporto ai servizi nel processo di personalizzazione. La tesi è

articolata in 8 capitoli suddivisi nel modo seguente.

Nel capitolo 1 viene analizzata l’evoluzione delle reti mobili dalla seconda

generazione verso le reti di terza generazione. Particolare enfasi è posta sul ruolo

della personalizzazione dei servizi IP.

10

Nel capitolo 2 vengono analizzati i comportamenti dei diversi attori come

fornitori di servizio, operatori di rete e utente nell’ambito del Virtual Home

Environment (VHE) ed in particolare rispetto al Personal Service Environment

(PSE). Viene inoltre introdotto il concetto di Generic User Profile definito da

3GPP.

Nel capitolo 3 vengono esposti gli scopi del progetto indicando quali

estensioni sono state attuate sul Generic User Profile per raggiungerli.

Nel capitolo 4 vengono presentate le assunzioni e i requisiti del progetto a

livello di dettagliato ed in modo formale utilizzando gli use case di UML.

Nel capitolo 5 vengono descritte le tecnologie di sviluppo utilizzate nella

fase progettuale

Nel capitolo 6 viene descritta la fase progettuale dalla definizione della

struttura del profilo utente all’architettura del sistema.

Nel capitolo 7 vengono descritte le parti che costituiscono il sistema di

gestione individuate nel capitolo precedente. Vengono a tale proposito descritte le

interfacce di tali entità e le loro interazioni.

Infine il capitolo 8 è dedicato alle conclusioni e agli sviluppi futuri.

11

1. Evoluzione delle reti mobili

La rapida evoluzione del mondo delle telecomunicazioni wireless verso

servizi dati oltre che ai servizi voce ha avuto inizio con l’avvento della prima rete

a tecnologia digitale GSM (Global System for Mobile Communication). Tale rete,

introdotta nel mercato nel 1991, ha portato notevoli vantaggi rispetto alla

precedente tecnologia analogica ma l’utilizzo della tecnica di commutazione a

circuito non la rende ottimale per il trasferimento dei dati.

La tecnologia digitale introdotta con la rete GSM non ha contribuito al

cambiamento sostanziale del modello di business delle telecomunicazioni

wireless, poiché l’architettura della rete presentava una struttura chiusa e centrata

solo sulle comunicazioni vocali. In questo scenario non vi era la possibilità di

sviluppare nuovi servizi da parte di service provider diversi dall’operatore di rete.

L’evoluzione dei servizi è stata quindi lenta e comunque non ha prodotto risultati

innovativi rispetto alla precedente tecnologia analogica.

Per superare questi vincoli furono standardizzate nuove soluzioni tra le

quali il General Radio Packet Service (GPRS) che introduce la tecnologia di

commutazione a pacchetto nel mondo radio mobile. Tale rete, oltre a presentare

innovazioni tecnologiche rispetto alla precedente GSM, introduce un forte

cambiamento nel business dovuto alla possibilità di interagire con il mondo

Internet. In questi ultimi anni si sta assistendo, grazie all’avvento della nuova

tecnologia UMTS (Universal Mobile Telecommunication System) che fornisce

una copertura globale a larga banda utilizzando connettività IP, ad una forte

convergenza del mondo wireless verso il mondo Internet. Si prevede infatti che

12

nel 2003 dei 600 milioni circa di utenti Internet, almeno 100 milioni saranno

utenti wireless come mostrato nella Figura 0-1.

Figura 0-1: Utenti mondiali Internet (Fonte

Ericsson)

La rete UMTS mette a disposizione degli utenti una banda massima di 2

Mbit/s teorica che può essere utilizzata per gestire informazioni più complesse

della sola voce. Come mostra la Figura 0-2, la banda messa a disposizione in

UMTS è sufficiente al trasferimento sia di voce che di video. In questo modo non

sono presenti strette limitazioni sulla tipologia di servizi che può essere offerta ad

utenti mobili.

13

Figura 0-2: Larghezza di banda richiesta nel trasferimento di diverse

tipologie di dati (Fonte Ericsson)

In questo scenario il terminale mobile sta assumendo un ruolo sempre più

importante e viene indicato come lo strumento più diffuso per l'accesso al mondo

dell'informazione globale del futuro. I nuovi terminali UMTS saranno

tecnologicamente avanzati in termini di capacità elaborative e grafiche, rispetto ai

terminali GSM e GPRS in modo da fornire il supporto di contenuti multimediali.

La maggior parte dei servizi di comunicazione e informazione sarà sviluppata e

trasmessa in ambienti interconnessi con il protocollo IP, spina dorsale di Internet.

Il fenomeno di crescita dei sistemi mobili e la continua espansione del

mondo Internet implicano la probabile richiesta, da parte degli utenti, di servizi

basati sulla larga banda come ad esempio servizi Mobile Internet e servizi di

comunicazione multimediale tra utenti. Tra i servizi più rilevanti del Mobile

Internet figurano i servizi di informazione, come ad esempio fornire notizie ad un

utente sulla base della sua locazione, servizi di intrattenimento come l’accesso al

Web, il video on demand e i servizi di e-commerce. Un altra area di servizi in cui

si ripone molta fiducia per il successo dei sistemi mobili di terza generazione sono

quelli per la comunicazione multimediale tra utenti, detti Connecting People,

come chiamate audio/video, videoconferenze oppure l’invio di messaggi ed e-mail

con contenuti multimediali (voce, testo, immagini e video). La lista di servizi

14

presentata non vuole essere esaustiva ma ha lo scopo di descrivere, a grandi linee,

le funzionalità che avrà a disposizione un utente della terza generazione.

Un fattore molto rilevante che determinerà il successo dei servizi offerti

attraverso le reti di terza generazione è il grado di personalizzazione che questi

riusciranno a fornire ai propri utenti. La personalizzazione dovrà tener conto sia

delle preferenze generali dell’utente sia di quelle specifiche per il servizio, nonchè

del contesto dell’utente e della presentazione del servizio sul teminale mobile. Gli

operatori, in questo senso, dovranno fornire ai servizi un’interfaccia che permetta

di accedere alle informazioni che caratterizzano l’utente come le sue preferenze e

il suo contesto che è definito come l’insieme eterogeneo di dati che descrive

l’ambiente e la situazione in cui l’utente si trova.

Il capitolo illustra le varie tecnologie di reti mobili che hanno determinato

l’evoluzione del mondo wireless. Per ogni tecnologia vengono fatte alcune

considerazioni sulla personalizzazione dei servizi e viene dato un breve principio

di funzionamento.

Reti di seconda generazione

La seconda generazione introduce rispetto alle precedenti reti l’utilizzo

della tecnologia digitale che permette di risolvere molti dei problemi presenti

nella precedente tecnologia analogica [Pars]. L'introduzione della tecnologia

digitale permette infatti di ottenere diversi vantaggi rispetto alla tecnologia

analogica. Il segnale digitale presenta una maggiore robustezza al rumore dei

dispositivi elettronici e ai degradi introdotti durante la trasmissione. Permette

inoltre di integrare con la stessa infrastruttura segnali di natura differente, come

dati, audio, voce e video. Le caratteristiche della tecnologia digitale e la necessità

di un sistema aperto hanno spinto il CEPT (Conference of European Post and

Telecommunications) a partire dall'82 ad avviare la fase di standardizzazione del

sistema di seconda generazione GSM. Questo garantisce una qualità di

comunicazione confrontabile con i sistemi precedenti, il roaming tra diverse

15

PLMN (Public Land Mobile Network) e l’interoperabilità con le reti esterne come

PSTN (Public Switched Telephone Network) e ISDN (Integrated Services Digital

Network).

La Figura 0-3 mostra in generale l’architettura di una rete GSM:

Figura 0-3: Architettura GSM

Le funzionalità più importanti che possiede una rete GSM possono essere

raggruppate in tre sottosistemi [Moul] che sono rispettivamente: la mobile station,

la base station ed il sottosistema di rete.

La Mobile Station (MS) rappresenta il dispositivo per mezzo del quale un

utente può usufruire dei servizi offerti dal GSM. Consiste di un terminale mobile

(Mobile Equipment, ME) e di una smart-card intelligente, detta SIM (Subscriber

Identity Module), che permette ad un utente di caratterizzare come proprio un

qualsiasi terminale mobile GSM.

16

La Stazione Base (Base Station Subsystem) comprende le unità funzionali

che consentono di fornire la copertura radio di una determinata area.E’ composta

di due unità: una Base Transceiver Station (BTS) costituita da ricetrasmettitori

che forniscono la copertura radio e da una Base Station Controller (BSC) che

governa il funzionamento di una o più BTS.

Il sottosistema di rete, genericamente chiamato Core Network, fornisce

diversi servizi tra i quali l'instradamento delle chiamate e la gestione della

mobilità. Il componente centrale in questa struttura è rappresentato dal centro di

commutazione Mobile Service Switching Center (MSC). Un MSC ha in carico

una certa area del territorio (controlla quindi tutte le BSC in quella zona) e deve

servire tutte le MS che transitano in quell'area. Per gestire la mobilità degli utenti

esso deve scambiare continuamente informazioni con un database, detto Visitor

Location Register (VLR), che memorizza, temporaneamente, le informazioni

relative alle MS che si trovano in quell'area. Ogni gestore possiede un database

centrale, denominato Home Location Register (HLR), che memorizza

permanentemente sia i dati di abbonamento degli utenti ( dati statici), sia dati

dinamici che possono variare a seguito di spostamenti degli utenti, come l'identità

del VLR relativo alla zona in cui si trova l’utente.

Ad ogni HLR viene associato un identificativo (HLR number), che viene

fornito ai VLR interessati e permette loro di individuare l'HLR di appartenenza di

ogni MS su di essi registrata. A sua volta ogni VLR è identificato da un VLR

number, in modo tale che l'HLR sappia presso quale VLR è registrata

correntemente ogni sua MS.

Tutte le chiamate originate presso le reti fisse o quelle mobili di altri

gestori e dirette ad un network GSM sono dapprima inoltrate ad un particolare

MSC, detto Gateway MSC (GMSC), che costituisce il punto di accesso alla

PLMN GSM a cui appartiene l'utente mobile chiamato. Il GMSC interroga il

registro HLR dell'abbonato, che a sua volta interroga il corretto registro VLR, e

quindi instrada la chiamata verso il centro MSC che controlla la zona nella quale

si trova l'abbonato.

Poiché una rete GSM è interconnessa con altre reti (PSTN, ISDN, altri

PLMN), deve prevedere un piano di numerazione con esse compatibile. Ad ogni

17

http://www.gsmworld.it/btsmania/bts.htm

MS è assegnato un numero di telefono (MSISDN), che identifica univocamente

un abbonato nel piano di numerazione della rete telefonica commutata pubblica

internazionale, in conformità con le specifiche E.164 sulla numerazione per reti

ISDN.

Personalizzazione nelle reti di seconda generazione

La standardizzazione e la progettazione della rete GSM ha rappresentato

un notevole mutamento della tecnologia wireless. La rete GSM utilizza infatti una

comunicazione basata su segnali digitali a differenza delle precedenti di natura

analogica. L’architettura di rete è chiusa e non presenta interfacce verso il mondo

esterno capaci di abilitare Service Provider a costruire servizi. L’unico Service

Provider capace di fornire servizi rimane l’operatore di rete. I servizi offerti sono

comunque fortemente basati sulla voce dato il limite della banda disponibile. Sono

presenti quindi solamente servizi come trasferimento di chiamata e segreteria

lasciando il mondo Internet isolato dal mondo della telefonia mobile. In questo

scenario non vi è la necessità di personalizzare i servizi per utente. All’operatore

di rete, che fornisce servizi basati sulla voce, sono infatti sufficienti le

informazioni contenute nei nodi di rete mediante le quali espleta il servizio di

trasporto delle informazioni (bearer service).

Il nodo di rete che memorizza in modo permanente i dati degli utenti che

hanno sottoscritto un abbonamento GSM è l’HLR. Ogni azione di tipo

amministrativo che il gestore di rete effettua sui dati dell’utente viene svolta

attraverso l'HLR contenente dati sia statici che dinamici. I dati statici sono relativi

alle informazioni di sottoscrizione dell’utente verso il gestore di rete. Un esempio

di questi dati è il tipo di contratto e la modalità di pagamento che consente di

applicare la precisa tariffa di una chiamata. Altri dati statici sono i dei servizi che

l’utente ha attivato. Un utente che utilizza il servizio di trasferimento di chiamata

attraverso il suo terminale, invia il numero al quale la chiamata viene inoltrata, e

questo viene memorizzato nell’HLR. I dati dinamici che l’HLR memorizza

permettono la gestione della mobilità dell’utente stesso. Ad esempio, tenendo

18

memorizzato il VLR number che sta gestendo attualmente l’utente, si può

inoltrare correttamente una chiamata.

L’HLR può essere unico per l'intera network oppure distribuito nel

sistema; si possono quindi avere delle MSC prive di HLR, ma connesse a quello

di altre MSC. E' possibile che ad un HLR sia associato un Autentication Center

(AuC) con il compito di generare i parametri di sicurezza.

Reti di generazione 2.5

La rete GSM, come è stato illustrato nel paragrafo precedente, presenta

grandi limitazioni rispetto al trasferimento dei dati. La richiesta sempre crescente

rispetto a questo tipo di traffico ha indotto la ricerca verso soluzioni che partendo

dalle infrastrutture esistenti permettessero un trasferimento efficiente dei dati

mantenendo contemporaneamente una qualità della voce non inferiore a quella

attuale. Per superare queste problematiche sono state standardizzate diverse

soluzioni tra le quali il GPRS (General Packet Radio Service) che permette un

accesso mobile ai servizi basati su IP.

Il GPRS, introdotto dall'ETSI (European Telecommunication Standard

Institute), è una tecnologia wireless che consente un passaggio graduale alla terza

generazione, in quanto si presenta come ponte tra il sistema GSM (2G) e la futura

rete UMTS. Il GPRS, infatti, non sostituisce il GSM ma si affianca ad esso

fornendo un migliore supporto ai dati per poter introdurre nuovi servizi in

aggiunta a quelli già esistenti (SMS e WAP),per questo si parla della generazione

2.5 perle reti mobili.

Affinché sia supportata la trasmissione efficiente dei dati, la rete GPRS

utilizza la commutazione a pacchetto i cui principi sono trattati in [Tan]

analogamente a quanto succede nel mondo Internet.

A differenza della commutazione a circuito (circuit switching), utilizzata

nel mondo della telefonia, nella commutazione a pacchetto (packet switching) non

si realizza un circuito fisico tra trasmettitore e ricevitore. Quando il trasmettitore

19

ha un blocco di dati da spedire, lo divide in blocchi più piccoli (pacchetti) che

vengono trasmessi indipendentemente, uno alla volta, alla destinazione. La

destinazione assembla di nuovo i blocchi tramite un numero d’ordine presente al

loro interno in modo da ottenere l’informazione originale. La commutazione a

pacchetto consente, in questo modo, di impegnare la linea di comunicazione solo

per il tempo necessario al trasferimento dell'informazione e poi lasciarla libera

fino al momento di invio del pacchetto successivo.

L’utilizzo del protocollo IP cancella la separazione, presente nei sistemi

2G, tra la rete wireless e il mondo Internet. L’accessibilità alle informazioni e ai

servizi presenti in Internet introduce un evoluzione nel modello del business del

mondo mobile, poiché permette a Service Provider, diversi dall’operatore di rete,

di fornire nuovi servizi IP ad utenti mobili. In questo scenario assume una

graduale importanza la gestione del profilo utente ai fini di fornire informazioni

che supportino il servizio durante il processo di personalizzazione.

L’utente che utilizza il servizio GPRS può usufruire di due potenziali

vantaggi rispetto alle reti GSM. Il primo vantaggio riguarda la cosiddetta

connessione ‘Always On’ che permette di accedere alla rete senza alcuna

procedura di setup e quindi ricevere o trasmettere direttamente i dati. La

sensazione dell’utente è quella di disporre di un terminale sempre connesso e di

servizi sempre disponibili sempre che le capabilities del terminale a disposizione e

della rete servente lo permettano. Il secondo vantaggio riguarda la tariffazione del

servizio GPRS. Nello scenario GPRS viene considerata, ai fini della tariffa, solo

la quantità di dati scambiati senza considerare la durata temporale della chiamata.

Ciò è possibile perché il cliente occupa il canale solo quando i dati sono trasferiti.

Le due caratteristiche appena descritte rendono più facile e più economico

l’utilizzo del GPRS.

Di seguito viene presentata l’architettura della rete GPRS.

20

Figura 0-4: Architettura GPRS

L’architettura della rete GPRS, pur avendo un aspetto molto simile alla rete GSM,

presenta alcune sostanziali differenze al suo interno dovute al supporto della

tecnica di commutazione a pacchetto.

Il terminale dell’utente, spesso denominato mobile station, consente l’invio

e la ricezione di dati ma rimane compatibile con il GSM che viene utilizzato solo

per le chiamate vocali.

L’infrastruttura di accesso alla rete è simile a quella presentata da GSM,

costituita quindi da diversi Base Transceiver Station (BTS) che forniscono i canali

radio fisici per la ricezione e trasmissione. Rispetto alla rete GSM è previsto per

questi sistemi un aggiornamento del software che ne consente l’utilizzo anche per

la trasmissione e ricezione dei dati. Le BTS vengono controllati da dei Base

Station Controller (BSC) che trasferiscono il traffico voce verso Mobile Switching

Center (MSC) e il traffico dati verso il nodo Service GPRS Support Node

(SGSN).

L’SGSN è equivalente all’MSC solo che ha la caratteristica di gestire

pacchetti. Ha il compito quindi di inviare e ricevere pacchetti da e verso i

terminali degli utenti presenti nella propria area. Ha inoltre il compito di

21

intercettare i nuovi terminali che entrano nell’area di rete di sua competenza. Per

questi utenti, esegue delle interrogazioni al database HLR per ottenere i dati

aggiornando cosi il VLR.

Il punto di accesso verso Internet è rappresentato dal GGSN (Gateway

GPRS Support Node) e che ricopre il ruolo di interfaccia verso una rete IP

esterna. convertendo i pacchetti GPRS che provengono dagli SGSN in un formato

che permetta ad essi di essere inviati sulla rete esterna e compie l’operazione

inversa in direzione opposta.

I repository principali, come nel caso della rete GSM, sono rappresentati

da HLR e VLR. L’HLR memorizza in modo permanente i profili di ogni utente e

in modo dinamico le informazioni che consentono il routing di chiamate e di

pacchetti. Inoltre comunica con l’Autentication Center (AuC) allo scopo di

utilizzare tecniche che garantiscano la sicurezza. Il VLR serve a mantenere

aggiornata la localizzazione degli utenti presenti temporaneamente nella propria

area di competenza.

Personalizzazione nelle reti 2.5

L’utilizzo, da parte di GPRS, del protocollo IP apre le porte a tutti i servizi

oggi disponibili su Internet e mette in comunicazione diretta la tecnologia wireless

e il web. Dato che il GPRS e Internet utilizzano lo stesso protocollo di

comunicazione, la rete GPRS può essere considerata come un’estensione wireless

della rete internet ed i terminali GPRS visti come postazioni di collegamento

mobili. La presenza di Service Provider che offrono nuovi servizi porta il concetto

di personalizzazione verso un ruolo fondamentale per il successo commerciale di

questi servizi. Il supporto che l’operatore di rete offre ai servizi rispetto alla

personalizzazione è però ancora minimo poiché le uniche informazioni di profilo

che vengono raccolte sono quelle contenute all’interno dell’HLR e negli altri nodi

di rete. Per quanto riguarda i contenuti veri e propri, la personalizzazione dei

servizi IP è delegata al fornitore del servizio e quindi non è integrata nella rete.

Quindi in modo del tutto autonomo, il Service Provider che offre un determinato

set di servizi dovrà preoccuparsi di raccogliere preferenze generali e preferenze

22

specifiche per un servizio di un determinato utente. Fanno eccezione i servizi

WAP che sono un tentativo di adattare servizi e contenuti Internet alle

caratteristiche dell’utente mobile con terminale WAP (per es. caratteristiche del

terminale).

Alcune informazioni di profilo sono comunque contenute, come nel caso

GSM, all’interno dei nodi di rete e vista l’importanza che assume la

personalizzazione, si deve fare un’analisi dettagliata di quali tra queste sono

realmente utili al servizio, quindi permettono di percepire la situazione che sta

vivendo e le sue necessità. In [3GPPTS23.060] vengono descritte le informazioni

presenti all’interno dei nodi di rete (HLR, SGSN e GGSN) utilizzate per fornire

un servizio GPRS.

Molte informazioni utili nel processo di personalizzazione non sono

contenute nei nodi di rete e quindi dovranno essere recuperate in altri modi,

prevedendo ad esempio la possibilità di inserimento da parte dell’utente.

L’elemento principale contenente le informazioni di profilo resta l’HLR.

L’HLR contiene informazioni riguardanti sia le comunicazioni vocali che le

comunicazioni dati.

Alcune informazioni comuni a entrambi i tipi di sottoscrizione sono

IMSI: è l’identificativo univoco dell’utente nella rete quindi permette il

routing delle chiamate

⇒

⇒

⇒

⇒

⇒

MSISDN: è il numero di telefono dell’utente

Subscribed Charging Characteristics: sono le caratteristiche di tariffazione

dell’MS

NAM: definisce se l’operatore è registrato in una rete GPRS o non GPRS

Nel caso di un servizio GPRS (quindi con NAM di tipo GPRS), la

comunicazione con un Service Provider avviene tramite l’attivazione di un PDP

context (Packet Data Protocol) che comprende tutte le informazioni che

caratterizzano la tecnica di commutazione a pacchetto utilizzata per il

trasferimento dati.

Un PDP context viene associato quindi alle seguenti informazioni:

PDP Type: è il tipo di protocollo utilizzato (PPP, Ipv4, Ipv6, X.25…)

23

PDP Address: è l’indirizzo IP statico dell'utente o Null, se l'utente riceve

un indirizzo IP assegnato dinamicamente

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

Access Point Name: è l’indirizzo di un GGSN risolvibile da un DNS della

rete a cui il mobile si deve connettere per usufruire del servizio dati

richiesto

QoS Profile Subscribed: indica la qualità del servizio sottoscritta per il

PDP context. La QoS sottoscritta assume un livello di default se nessuna

particolare QoS è richiesta. Inoltre rappresenta il valore massimo che si

può richiedere e negoziare nel momento della fruizione del servizio. I

livelli di qualità del servizio che possono essere definiti sono i seguenti:

Conversational. E’ utilizzata in comunicazioni real time

Streaming. E’ utilizzata in flussi informativi video (e.g. streaming

video)

Interactive. E’ utilizzata in comunicazioni il cui ritardo è

accettabile (e.g. web browsing)

Background. Non vi sono requisiti sul ritardo di consegna (e.g. e-

mail, SMS)

Per ognuna delle traffic class sono definiti una serie di parametri di QoS quali:

Transfer delay: definisce un ritardo massimo accettabile per il

trasferimento dei pacchetti

Reliability class: fornisce informazioni sulla protezione dei dati e

sull’esistenza di acknowledgement per garantire un servizio

affidabile

Throughput: specifica il bit rate di trasferimento medio e massimo

richiesto, che può essere rispettato o meno a seconda delle risorse di

rete disponibili

Oltre a possedere informazioni sui PDP context sottoscritti dall’utente,

l’HLR possiede anche informazioni sul pagamento dei servizi:

24

PDP Context Charging Characteristics: le caratteristiche di tariffazione per

questo servizio (normal, prepaid, etc)

Le informazioni appena analizzate hanno la proprietà di essere statiche

quindi di non variare il loro valore in base alle azioni che l’utente esegue

all’interno della rete. L’HLR, oltre a queste informazioni, conserva anche

informazioni dinamiche come ad esempio i riferimenti all’SGSN o MSC che sta

attualmente servendo l’utente rispettivamente per servizio voce e per servizio dati.

Altri dati sono presenti nella rete che possono avere un’importante

rilevanza in uno scenario rivolto alla personalizzazione e corrispondono alla

descrizione di come un utente sta usufruendo di un servizio cioè dati dinamici

contenuti all’interno del SGSN o dell’MSC.

Mentre l’HLR fornisce dati statici di sottoscrizione per un PDP context,

l’SGSN contiene al suo interno dati dinamici relativi ad un PDP context realmente

attivato. Per ogni PDP context attivo:

PDP Context Identifier ⇒

⇒

⇒

⇒

⇒

PDP Type : e.g. PPP (Point-to-Point-Protocol) o IP

PDP Address : e.g. un indirizzo IP

APN in Use: e.g. waptim.tim.it.gprs

GGSN Address in Use: indirizzo IP del GGSN corrente che sta

servendo il mobile

L’SGSN contiene informazioni sulla qualità del servizio che è stata

assegnata all’utente e sullo stato dell’utente. Lo stato dell’utente viene descritto

mediante lo stato del suo terminale che non è più descritto da soli due stati ma può

assumere diversi valori (IDLE, STANDBY, READY, PMM-DETACHED, PMM-

IDLE, PMM-CONNECTED) e dallo stato del suo PDP Context che può essere

attivo oppure inattivo. Nel primo caso è reso possibile il trasferimento dei dati.

Nel secondo caso non è invece consentito il trasferimento dei dati.

Un’informazione molto importante, nello scenario wireless, è

rappresentata dalla posizione di un utente. Questo dato è contenuto nell’SGSN per

25

utenti che hanno attivato una sessione dati mentre è contenuto nell’MSC per utenti

che hanno attivato una sessione voce.

Tutte i dati che sono stati analizzati possono essere in qualche modo utili

ai servizi per la fornitura di un servizio che presenti un buon livello di

personalizzazione. Un Service Provider potrebbe infatti fornire un servizio

basandosi sulla locazione inviando ad esempio contenuti informativi di tipo

turistico oppure di InfoTraffic. Potrebbe inoltre essere interessato al tipo di

protocollo utilizzato per il trasferimento dei dati oppure all’indirizzo IP

dell’utente.

In base a quanto detto, si capisce che il GPRS è un passo fondamentale per

l’evoluzione verso i sistemi 3G come UMTS dato che questi sistemi si

appoggeranno completamente all’architettura basata su IP introdotta nel campo

mobile dal GPRS. La larghezza di banda posseduta dal GPRS, pur essendo

superiore a quella offerta da GSM pari a 9.6 kbps, è comunque limitativa per

diversi servizi poiché teoricamente ha il valore nominale di 171.2 kbps che

comunque non viene mai raggiunto per diversi motivi. Le reti di terza generazione

aumenteranno ancora il bit rate in modo da fornire la possibilità alla maggior parte

dei servizi di convergere verso utenti wireless ed inoltre introdurranno una visione

a strati quindi orizzontale dell’infrastruttura abbandonando la visione verticale

tipica dei sistemi GSM e GPRS. Grazie a questi nuovi avanzamenti tecnologici è

previsto un ulteriore avvicinamento tra il mondo wireless e il mondo Internet che

comporta quindi una stretta interazione tra il mondo delle telecomunicazioni che

gestisce i servizi mobili e il mondo dell’informatica che progetta e implementa

servizi per utenti Internet.

Reti di terza generazione

Per sistemi di ''terza generazione'' si intende indicare nuovi sistemi con

capacità avanzate in grado di conciliare la mobilità dell’utente con la crescente

esigenza di comunicazione multimediale. La tecnica di accesso Wideband code

26

division multiple access (W-Cdma), è stata standardizzata dall’ente 3Gpp ed è

stata selezionata dall'Etsi, a livello europeo, per l’accesso radio.

Le reti mobili di terza generazione saranno identificate con l'acronimo

UMTS (Universal Mobile Telecommunication System). L'UMTS darà un nuovo

impulso alle comunicazioni mobili, disponendo delle infrastrutture necessarie per

fornire servizi voce e dati, con immagini e grafica, in aggiunta a video

comunicazione e ad altre applicazioni a larga banda.

La rete UMTS permetterà di raggiungere velocità di trasmissione in aria

pari a 384 Kbit/s in condizioni di piena mobilità, fino a 2 Mbit/s in ambienti

chiusi.

Rete UMTS

La rete UMTS è il sistema radiomobile cellulare digitale di terza

generazione. L'UMTS, a differenza del GSM che per la trasmissione dei dati

utilizza la tecnologia a commutazione di circuito, integra la trasmissione dati a

circuito ed a pacchetto il che consente di ottenere servizi diversificati, come

connessioni virtuali continue alla rete, modalità alternative di pagamento (ad

esempio pagamenti proporzionali al numero di bit trasferiti o alla larghezza della

banda impiegata). Quindi con tale rete si passa da una visione verticale, in cui le

funzionalità di trasporto delle informazioni, di controllo della comunicazione e di

gestione dei servizi sono implementate nel medesimo elemento verso una visione

orizzontale, in cui le funzionalità sono suddivise in diversi strati.

La struttura verticale è costituita da una grande varietà di reti, ciascuna

specializzata e ottimizzata per fornire una particolare categoria di servizio,

disponendo, nella maggior parte dei casi, di terminali, nodi di rete e protocolli

specifici senza alcuna possibilità di far interoperare i differenti elementi all'interno

della rete in base ai servizi di volta in volta richiesti. Tale situazione risulta di

ostacolo alla possibilità di creare sinergie tra reti distinte, nell'ottica sia di fornire

la moltitudine di servizi di terza generazione, sia di ridurre i costi di gestione.

27

Figura 0-5: Visione verticale della rete

L'avvicinamento fra i mondi ''telecom'' e ''datacom'', con la sempre

crescente importanza del protocollo IP, sta portando alla convergenza delle

infrastrutture delle reti di telecomunicazioni con quelle delle reti dati, stabilendo

le basi per una struttura ''stratificata orizzontalmente''.

Figura 0-6:Visione orizzontale della rete

La separazione dei nodi di rete e delle relative funzionalità in livelli distinti

è un concetto chiave del moderno networking ed è la caratteristica principale

dell'architettura definita dagli enti di standardizzazione per i sistemi mobili di

28

terza generazione, nell'ottica di evoluzione verso una rete interamente basata su IP

(all-IP network) descritta in [3GPPTR23.922].

Il protocollo IP viene quindi utilizzato sia per garantire connettività sia per

fornire nuovi servizi agli utenti wireless. L’importanza che UMTS assegna allo

sviluppo di servizi rivolti ad utenti mobili è molto rilevante, ciò è dimostrato dalla

presenza all’interno delle specifiche 3GPP di un concetto denominato Virtual

Home Environment (VHE) che consiste nella possibilità di accedere ai servizi 3G

in qualunque luogo ci si trovi, a mezzo di qualsivoglia terminale e attraverso

qualunque rete. In altre parole, con il VHE l'utente in roaming su reti diverse da

quella di appartenenza, detta home network, non percepirà alcuna differenza di

funzionalità né di aspetto dei servizi sottoscritti. La possibilità dell’utente di

accedere ai servizi sottoscritti sia quando si trova nella home network sia quando

si trova nella visited network è il requisito più generale presentato dal VHE ma

non è l’unico. All’interno del VHE vengono infatti individuati una serie di

requisiti relativi alla gestione delle informazioni che caratterizzano il profilo

utente. Il compito della gestione di questo profilo è assegnata al Personal Service

Environment (PSE). La definizione e la progettazione di sistemi che soddisfino i

requisiti proposti dal VHE e dal PSE diventa di fondamentale importanza per gli

operatori e i Service Provider, nell'ottica di offrire agli utenti servizi personalizzati

con caratteristiche differenti da quelle dei servizi proposti dai concorrenti sul

mercato. La prima release UMTS che andrà in campo (release 99) non

comprenderà come requisiti quelli proposti dal VHE che è incluso in una release

successiva (release 6) che verrà approvata nel corso del 2003. I concetti del VHE

e del PSE, insieme alle problematiche della gestione del profilo utente, vengono

trattate nel capitolo successivo.

La rete UMTS è costituita da tre sottosistemi fondamentali: il Core

Network (CN), l'UTRAN (UMTS Terrestrial Radio Access Network) e lo User

Equipment (UE) (Figura 0-7).

29

Figura 0-7: Sottosistemi della rete UMTS

Infrastruttura di rete

L'infrastruttura della rete è identificata in genere Core Network ed è la

parte nella quale la trasmissione avviene solo e soltanto via cavo. Il Core

Network è logicamente suddiviso nel dominio CS (Circuit switching) e nel

dominio PS (Packet Switching). Questi due domini differiscono per il modo in cui

gestiscono il traffico utente.

Dominio CS: E' costituito dall'insieme di tutte le entità CN (Core

Network) che offrono, per il traffico utente, una connessione di tipo CS.

Una connessione di tipo CS è una connessione in cui le risorse richieste

vengono concesse nel momento in cui la connessione viene stabilita e

vengono rilasciate nel momento in cui la connessione viene rilasciata.

⇒

⇒ Dominio PS: E' costituito dall'insieme di tutte le entità CN (Core

Network) che offrono per il traffico utente una connessione di tipo. Una

connessione di tipo PS trasporta l'informazione dell'utente usando

autonome concatenazioni di bit chiamate "pacchetti"; ogni pacchetto può

seguire un percorso diverso da quello seguito dal pacchetto che lo precede,

cioè ogni pacchetto si muove in maniera autonoma.

30

I due domini contengono entità comuni. Le principali entità del Core

Network che appartengono sia al dominio PS che a quello CS sono l’Home

Location Register (HLR) e il Visitor Location Register (VLR). L’HLR

rappresenta il database centrale nel quale vengono memorizzati in modo

permanente i dati relativi agli utenti che hanno sottoscritto un abbonamento

UMTS. Le informazioni contenute all’interno dell’HLR sono in generale le stesse

analizzate per la rete GPRS. Il VLR è un database nel quale viene registrata e

tenuta aggiornata la posizione sul territorio dell'UE. Il VLR è (a parte l'HLR), il

registro delle locazioni per i servizi che utilizzano la trasmissione a commutazione

di circuito (CS, Circuit Switched). L'MSC (che definiremo dopo) recupera dal

registro VLR l'informazione che gli occorre, ad esempio, per gestire chiamate da e

verso un UE correntemente localizzato nella zona di sua competenza.

Le principali entità del dominio CS sono invece il Mobile-services

Switching Centre (MSC) e il Gateway MSC (GMSC). L’MSC rappresenta

un'interfaccia tra il sistema radio e la rete fissa. L'MSC esegue le funzioni

necessarie per il trattamento dei servizi CS (Circuit Switched) da e verso lo User

Equipment. E' un centro di commutazione e come tale svolge le funzionalità di un

normale nodo di commutazione di una rete. Perciò, instaura, controlla, tassa le

chiamate da e verso gli UE presenti nell'area geografica da esso servita. In più,

esegue, in collaborazione con altre entità, tutti quei compiti essenziali per gestire

un utente mobile come la gestione della mobilità e l’instradamento delle chiamate.

Un MSC è sempre associato ad un registro VLR. Il GMSC è un MSC che svolge

la funzione di smistamento delle chiamate verso l'area nella quale staziona in quel

momento l'utente chiamato, rappresenta perciò, il punto di accesso alla rete

PLMN a cui appartiene l'utente mobile chiamato. Il GMSC entra in azione quando

la rete dalla quale proviene la chiamata, non può interrogare l'HLR della rete

mobile (PLMN) alla quale la chiamata è diretta; questo può accadere in vari casi,

ad esempio quando la chiamata proviene dalla rete della telefonia fissa oppure

quando proviene da una rete mobile diversa da quella dell'utente chiamato.

Le principali entità del Core Network che appartengono al dominio PS

sono le specifiche entità GPRS (General Packet Radio Service) già analizzate nel

31

paragrafo precedente; esse sono le entità SGSN e GGSN mediante le quali viene

realizzata la trasmissione a pacchetto.

L’SGSN costituisce, insieme al GGSN, l'interfaccia tra il sistema radio e

la rete fissa per i servizi che utilizzano la trasmissione a commutazione di

pacchetto (PS, Packet Switched). Per tali tipi di servizi l'SGSN svolge funzioni

analoghe a quelle che l'MSC/VLR svolge per i servizi a commutazione di circuito

(CS, Circuit Switched) come ad esempio la gestione della mobilità e

l'instradamento delle chiamate.

Il GGSN ha funzioni analoghe al gateway MSC (GMSC). Rappresenta il

punto d'ingresso alla rete che supporta la trasmissione a pacchetto. Nel suo

database memorizza i dati dell'utente che riceve dai registri HLR e SGSN e che

sono necessari per la gestione della trasmissione a pacchetto.

Interfaccia radio

L'UMTS Terrestrial Radio Access Network (UTRAN) è l'interfaccia radio

dell'UMTS. Consiste di un insieme di Radio Network Subsystem (RNS) connessi

al Core Network. Ogni RNS è controllato da un Radio Network Controller (RNC).

L'RNC è connesso ad un insieme di Nodi B, ognuno dei quali può servire una o

più celle.

Nella figura successiva, sulla sinistra della linea verticale è raffigurato

parte dell'UTRAN e sulla destra un'entità del Core Network. Dell'UTRAN sono

raffigurati due RNS; il primo costituito da un RNC e due nodi B, il secondo da un

RNC ed un nodo B. Del Core Network è raffigurato solo un MSC/SGSN.

32

Figura 0-8: Struttura dell'UTRAN

L’RNS è il punto di accesso dell'utente alla rete UMTS in quanto è

responsabile della concessione e del rilascio di specifiche risorse radio. Ogni RNS

è responsabile delle risorse del suo insieme di celle. Svolge due ruoli, quello di

stabilire e gestire la connessione tra UE e UTRAN e quello di fornire le risorse

radio richieste durante tale connessione. Nel primo caso si parla di SRNS (Serving

RNS), nel secondo caso di DRNS (Drift RNS). Così, il DRNS assiste l'SRNS

fornendogli risorse radio una volta che la connessione tra UTRAN ed UE è stata

stabilita.

L’RNC è la centrale di controllo che gestisce il funzionamento dei Nodi B,

l'attivazione ed il rilascio dei canali radio, gli handover interni ed altro ancora. In

pratica controlla l'uso e l'integrità di tutte le risorse radio.

Il NODO B è un nodo logico responsabile della ricezione e trasmissione in

una o più celle rispettivamente da e verso l'UE. Ogni nodo può fornire la

copertura radio di una o piu celle. Più celle geograficamente adiacenti sono

raggruppate in una Location Area/Routing Area (LA/RA). Ad ogni cella è

assegnato un identificativo numerico, detto Cell Identifer (C-Id) usato per

identificare in maniera univoca una cella dentro un RNS.

33

Terminale

L’insieme di tecnologie che costituiscono il terminale dell’utente è

generalmente identificato come User Equipment e costituisce l'equipaggiamento

usato dall'utente per accedere ai servizi UMTS. L'equipaggiamento utente (UE) è

costituito da un equipaggiamento mobile (Mobile Equipment, ME) e da una o più

USIM (User Services Identity Module) che contiene funzioni e dati necessari ad

identificare ed autenticare l'utente. In particolare, contiene l'IMSI (International

Mobile Subscriber Identity) che serve ad identificare in maniera univoca l'utente,

sebbene l'utente può non conoscerne il valore. L'USIM è implementata insieme ad

altre applicazioni in un circuito integrato posto su una carta removibile detta

UICC (UMTS Integrated Circuit Card).

34

3. Estensioni del Generic User Profile

Il capitolo precedente ha illustrato i concetti che caratterizzano il supporto

alla personalizzazione dei servizi in uno scenario UMTS (Release 6) descrivendo i

requisiti degli attori all’interno del Virtual Home Environment. L’utente, che ha

sottoscritto un contratto con il gestore di rete, ha la necessità di avere a

disposizione un sistema che gli permetta di gestire il suo profilo attraverso il quale

esprime le sue preferenze e caratteristiche generali, nonchè preferenze specifiche

per i servizi offerti dall’operatore di rete ed da altri Service Provider. Mentre, il

fornitore di servizi ha la necessità di interagire con il sistema di gestione dei

profili per recuperare informazioni relative all’utente verso il quale verrà fornito il

servizio. Il grado di personalizzazione dei servizi, offerti in ambiente mobile,

dipende dal livello di visibilità che il fornitore del servizio ha a disposizione sui

dati che caratterizzano gli utenti. La diversa visibilità dei dati è condizionata dal

diverso tipo di rapporto che il Service Provider stringe con il gestore di rete.

A tale proposito, è stato visto che, nell’ambito del Virtual Home

Environment, i Service Provider possono essere suddivisi in VASP e HE-VASP.

I primi hanno la caratteristica di non definire un particolare rapporto con

l’operatore di rete e possono accedere solo a informazioni di tipo generale

riguardanti l’utente. I secondi, insieme ai servizi offerti direttamente

dall’operatore di rete, possono utilizzare per scopi di personalizzazione anche le

preferenze dell’utente specifiche di un servizio oltre alle preferenze generali.

Nella gestione del profilo utente si fa uso del concetto di sub profile.

L’insieme delle informazioni che costituiscono il profilo di un utente sono divise

35

in component. Ad ogni component possono essere associate una o più istanze che

ne caratterizzano il valore. Un sub profile è costituito da un insieme di istanze con

il vincolo che siano tutte appartenenti a component diversi. Tra tutti i sub profile

che l’utente può definire solamente uno può essere attivo in un determinato istante

(Active sub profile), che rappresenta la situazione e le necessità dell’utente in tale

momento. I concetti qui richiamati descrivono a livello informativo come

vengono affrontate le problematiche relative alla personalizzazione nella rete

UMTS R6.

All’interno del processo di personalizzazione non si può trascurare il

concetto di contesto dell’utente mobile. Questo non è limitato solamente alla

conoscenza delle capabilities del terminale dell’utente e della rete, già previste

all’interno del Generic User Profile, ma si è pensato di estendere il profilo con un

insieme di informazioni che caratterizzi la situazione e il luogo in cui l’utente si

trova. La conoscenza del contesto può risultare effettivamente utile ai Service

Provider in fase di adattamento dei servizi.

Il recupero delle informazioni di contesto è una problematica che viene

analizzata dall’organo di standardizzazione 3GPP inserendo, nelle specifiche

UMTS, la definizione di due servizi che hanno il compito di recuperare

informazioni di contesto allo scopo di renderle disponibili a terze parti che

forniscono servizi mobili.. Tali servizi sono il ‘Presence Service’ descritto in

[3GPPTS22.141] e il ‘Location Service’ descritto in [3GPPTS22.071]. Servizi di

questo tipo sono detti anche ‘Enabling Services’ poiché offrono interfacce a

parametri di contesto che i Service Provider possono utilizzare per fornire nuovi

servizi a valore aggiunto.

Il servizio di presenza è un servizio mediante il quale un utente può

controllare la diffusione delle sue informazioni di presenza ad altri utenti e servizi,

specificando esplicitamente quali di queste entità possono vedere il suo stato di

presenza nella rete. Le informazioni di presenza indicano se l’utente è presente

nella rete ed in che modo, per esempio a quale indirizzo, può essere contattato.

La presenza è uno dei concetti che il mondo mobile ha ereditato dal mondo

Internet, poiché esistono già applicazioni Internet che permettono di rilevare la

presenza dell’utente e permettendo all’utente la gestione della loro visibilità.

36

Purtroppo, le diverse applicazioni esistenti non permettono l’interoperabilità,

limitando l’uso tra gli utenti di un singolo fornitore di questo tipo di servizio.

Il Location Service è un servizio, offerto dall’operatore di rete, che ha lo

scopo di recuperare l’informazione sulla posizione dell’utente e renderla

disponibile ai Service Provider che la utilizzano come dato di input nei loro

servizi. Avere disponibile l’informazione di localizzazione, permette ai Service

Provider di creare nuovi servizi che utilizzano la posizione dell’utente per

selezionare i contenuti da inviare. Esempi possono essere servizi di informazione

sul traffico o di tipo turistico, come l’orario dei musei nella località in cui si è in

vacanza. Un altro esempio di applicazioni è ‘fleet management’ (gestione delle

flotte) per risolvere problemi di ottimizzazione nel campo dei trasporti.

Un’estensione ulteriore che può essere prevista rispetto alla

specifica del Generic User Profile riguarda l’inserimento da parte dell’utente delle

capabilities del suo terminale nel caso in cui quest’ultimo non supporti la tecnica

UAProf descritta nel capitolo precedente.

Il primo paragrafo descrive gli enabling services e il loro rapporto con il

sistema di gestione del profilo. Nel secondo paragrafo viene descritta una

soluzione per la fornitura delle capabilities della rete e del terminale anche quando

non è supportata la tecnica UAProf.

“Enabling Services” supportati

Il sistema di gestione del profilo utente che è stato progettato nel lavoro di

tesi non può prescindere dal considerare tra le informazioni di profilo quelle

relative alla configurazione del Presence Service e del Location Service.

Il seguente paragrafo descrive a grandi linee il funzionamento di tali

servizi offerti dal Mobile Network Operator (MNO) ponendo particolare enfasi su

come supportare la gestione delle informazioni di configurazione.

37

Servizio di presenza

Il Presence Service ha il compito di mettere a disposizione di utenti e

servizi le informazioni di presenza. L’operatore di rete implementa questo servizio

allo scopo di consentire a Service Provider la creazione di servizi multimediali

sulla stessa linea di quelli già presenti in Internet basati sulle informazioni di

presenza. I servizi che possono essere supportati dal servizio di presenza

includono:

Nuovi servizi di comunicazione ⇒

⇒

⇒

Le informazioni di presenza, come il tipo di indirizzo sul

quale l’utente è in un determinato momento raggiungibile, possono

essere utilizzate da servizi di comunicazione come instant messaging

e chat

Servizi di informazione

I servizi di tipo push possono avvalersi del servizio di

presenza per inviare informazioni all’utente solo se l’utente è

presente nella rete e all’indirizzo specificato dall’utente stesso

Valore aggiunto a servizi esistenti

La conoscenza dell’indirizzo attraverso il quale l’utente è

disponibile in un determinato momento determina in generale anche

come l’utente è in grado di ricevere le informazioni. Il servizio

quindi può adattare i contenuti che fornisce all’utente in base alle sue

capabilities. Ad esempio un utente che non può accettare chiamate

vocali ma desidera partecipare ad un meeting può ricevere le

informazioni convertite in formato testo.

Attori all’interno del servizio di presenza

In [3GPPTS22.141] vengono definiti in modo preciso i ruoli di utenti e

servizi che interagiscono con il Presence Server, servizio che ha il compito di

raccogliere le informazioni di presenza degli utenti e fornirle a servizi ed altri

utenti interessati. I servizi e gli utenti che richiedono informazioni di presenza di

38

un determinato utente sono definiti in generale watcher. L’utente a cui

appartengono le informazioni di presenza richieste è denominato presentity. La

presentity comunica le informazioni relative alla sua presenza nella rete attraverso

degli appositi agenti presenti sia sul suo terminale sia all’interno dei nodi di rete.

Tali agenti hanno il compito di intercettare la presenza dell’utente e il mezzo con

cui è presente nella rete, fornire poi successivamente queste informazioni al

Presence Server, entità che espleta il servizio di presenza fornito dall’operatore.

La presentity può inoltre, senza fare uso di agenti, comunicare direttamente al

Presence Server alcune informazioni di presenza che lo riguardano. Vengono

identificate diverse tipologie di watcher in base al tipo di richiesta e sono:

Fetcher ⇒

⇒

⇒

E’ un tipo di watcher che richiede informazioni di presenza di

una o più presentities, ma non vuole che gli siano notificati i

cambiamenti che tali informazioni subiranno. Quindi è interessato a

conoscere solo l’attuale valore delle informazioni di presenza.

L’interazione con il Presence Service è denominata Information

Mode.

Poller

Questo tipo di watcher accede periodicamente alle

informazioni di presenza ma non richiede che gli siano notificati i

cambiamenti che tali informazioni subiranno. L’interazione con il

Presence Service è denominata Information Mode.

Subscribed-watcher

E’ un tipo di watcher che richiede che gli siano notificati i

cambiamenti delle informazioni di presenza riguardanti una o più

presentities. Questo tipo di interazione con il presence Service è

denominata ‘Notification mode’

La Figura 0-1 mostra il modello dei ruoli all’interno del servizio di

presenza:

39

Figura 0-1: Ruoli all'interno del servizio di presenza

La diversa modalità di interazione dei watcher rispetto al Presence Service

è rappresentata da diversi colori. In grigio scuro si rappresentano watcher che

utilizzano la modalità ‘Notification mode’ mentre in grigio più chiaro vengono

disegnati watcher che utilizzano la modalità ‘Information mode’

Informazioni di presenza

Il Presence Service ha lo scopo di raccogliere le informazioni di presenza

relative alle presentity e distribuirle a watcher che le richiedono in base a regole di

accesso definite dalla presentity stessa. Le informazioni di presenza relative ad

una specifica presentity sono organizzate secondo un modello logico costituito da

un arbitrario numero di elementi denominati tuple.

Ogni tupla, come descritto in [rfc2778], contiene un campo ‘status’ che

indica lo stato del dispositivo di comunicazione (ad esempio ‘not reachable’ per il

telefono mobile) e un campo ‘comunication address’ costituito da due

informazioni che sono rispettivamente ‘comunication means’ e ‘contact address’.

Il comunication means indica la modalità con cui la presentity può essere

40

contattata, ad esempio SMS, MMS, instant messaging etc. Il contact address

indica invece a quale indirizzo la presentity può essere contattata, ad esempio si

può indicare il numero di telefono oppure l’indirizzo di posta elettronica. Ogni

tupla presenta inoltre un campo denominato ‘other presence markup’ mediante il

quale si possono aggiungere ulteriori informazioni di presenza diverse dalle

informazioni standard elencate precedentemente. Infatti, a seconda del tipo di

presentity, potrebbero essere utili diversi tipi di attributi di presenza ed è in pratica

impossibile definire una lista di attributi standard che possa essere adatta a tutti i

tipi di presentity. In [rfc2779] vengono definiti ulteriori parametri che possono

essere utilizzati in diverse applicazioni del servizio di presenza come ad esempio

‘Subscriber provided location’ o il ‘Network provided location’ che sono le

informazioni sulla posizione dell’utente fornite rispettivamente dall’utente stesso

e dagli agenti presenti nell’infrastruttura di rete. La gestione degli attributi di

presenza organizzati in tuple permette di fornire a diversi watcher valori diversi

dello stesso attributo di presenza. Infatti la presentity può creare più di una tupla

contenente gli stessi attributi ma non necessariamente questi devono presentare gli

stessi valori. In base a questa idea di gestione, la presentity può fornire un contact

address sia agli amici sia ai colleghi di lavoro mostrando però agli amici un

indirizzo e-mail e ai colleghi un numero telefonico. La Figura 0-2 mostra la

struttura delle informazioni di presenza organizzate in tuple.

41

PRESENCE INFORMATION

.

.

.

PRESENCE TUPLESTATUS

COMMUNICATION ADDRESS

OTHER MARKUP

PRESENCE TUPLE

OTHER PRESENCE MARKUP


STATUS

Contact address

Communication means

PRESENCE TUPLESTATUS


OTHER MARKUP

PRESENCE TUPLE

OTHER PRESENCE MARKUP


STATUS

Contact address

Communication means

Figura 0-2: Organizzazione logica delle informazioni di presenza

La fornitura di informazioni di presenza, relative ad una presentity, verso

watcher interessati, deve avvenire rispettando le regole di accesso definite dalla

presentity stessa e trattate in [3GPPTR23.841]. Queste regole di accesso vengono

espresse tramite la definizione di access list che esprimono le associazioni tra

gruppi di watcher e tuple. Quindi le access list permettono di definire ‘quale

watcher’ può accedere a ‘quali informazioni’. La Figura 0-3 mostra l’associazione

tra gruppi di utenti e tuple:

42

Figura 0-3: Descrizione di access list e tuple nel servizio di presenza

Si possono prevedere logicamente tre tipologie di access list:

Blocking list: tale lista contiene un elenco di entità che non hanno i

privilegi sufficienti ad accedere ad alcun tipo di informazione; può

essere creata e gestita sia dall’utente che da parte del Presence Server

per applicare politiche di sicurezza (quali ANTI-SPAM e ANTI-

STALKING quest’ultimo è il caso in cui un watcher possa inferire

informazioni di contesto a lui non concesse per scopi maliziosi o

illegali)

⇒

⇒

⇒

Personal list: ne possono esistere più di una (Amici, Colleghi, …).

Vengono interamente gestite da parte dell’utente il quale inserisce

l’elenco degli utenti e le informazioni a cui possono accedere

Public List: vengono gestite e create da parte di service provider su

indicazione dell’utente. Un caso d’uso potrebbe prevedere un service

provider, che fornisce il servizio di newsgroup, che aggiorni la

public access list di un utente per riflettere l’inserimento di nuovi

utenti nella community. Ovviamente sarà l’utente ad indicare quali

service provider avranno la facoltà di creare e/o gestire le public

access list e nel contempo quali informazioni fornire.

43

La richiesta di watcher, interessati a conoscere le informazioni di presenza

relative ad una specifica presentity, viene analizzata dal Presence Server

consultando le Access List relative alla presentity stessa. Si individuano le Access

List in cui è presente il watcher e si analizzano le informazioni contenute nelle

tuple associate a tali Access List. Se le informazioni richieste dal watcher sono le

stesse contenute nelle tuple allora vengono forniti i valori degli attributi di

presenza della presentity.

Il Presence Server non ha come unico compito quello di recuperare i valori

degli attributi di presenza da determinati agenti e fornirli a watcher autorizzati ma

deve fornire, allo stesso tempo, la funzionalità di notifica verso la presentity di

watcher che hanno richiesto le sue informazioni di presenza.

Si può prevedere di contattare la presentity nei casi in cui il watcher che

richiede le informazioni di presenza non si trova in nessuna delle access list. In

questo caso il Presence Server contatta la presentity per ottenere precise direttive

riguardo all’accesso del particolare watcher. Nella figura che segue è riportato il

processo di autorizzazione di un watcher attraverso le access list.

Figura 0-4: Processo per l'autorizzazione di watcher

Evoluzione del servizio di presenza

L’operatore, mediante la definizione e l’implementazione del Presence

Service, offre la possibilità a Service Provider di costruire nuovi servizi da

proporre ad utenti wireless basati sulla conoscenza delle informazioni di presenza.

44

Gli attributi di presenza appartengono ad un insieme più grande di

informazioni che costituisce il contesto di un utente mobile.

Come è stato visto nel paragrafo precedente, il contesto è uno dei fattori

principali che può essere considerato all’interno di un processo di

personalizzazione poiché attraverso gli attributi che lo caratterizzano definisce le

esigenze di un utente in un determinato luogo ed in un determinato momento.

La necessità di fornire servizi personalizzati che si basino anche sulle

informazioni di contesto ha fatto nascere l’interesse verso problematiche relative

all’estensione del servizio di presenza verso il concetto di contesto.

Attualmente sono infatti in via di sviluppo soluzioni che permettano di

includere all’interno della gestione delle informazioni di presenza anche

informazioni relative al contesto. La tecnica di estensione della presenza verso il

contesto eredita il concetto di access list e tuple visto nel Presence Service

introducendo però nuovi attributi che descrivono anche le informazioni più

generali di contesto.

I ruoli all’interno del servizio di presenza esteso al contesto sono gli stessi

visti per il servizio di presenza base con la differenza che i watcher (ad esempio

un Service Provider) possono richiedere anche il valore di attributi relativi a

informazioni di contesto più generali oltre che a informazioni di presenza. La

presentity in questo caso deve definire comunque i gruppi di utenti e le tuple per

creare le access list ma all’interno delle tuple deve indicare non solo attributi di

presenza bensì attributi che riguardano il contesto in generale.

Il Presence Server esteso alle informazioni di contesto viene denominato

Context Server ed offre più in generale un servizio denominato Context Service.

Tale servizio ha lo scopo di raccogliere le informazioni di contesto da opportuni

agenti e distribuire tali informazioni a watcher autorizzati in base alle access list

definite dalla presentity.

La necessità di estendere il servizio di presenza è guidata dall’importanza

di offrire servizi personalizzati poiché si ritiene che il grado di personalizzazione

sarà uno dei fattori che maggiormente influiranno sul successo economico dei

servizi mobili di terza generazione. Infatti il successo di nuovi servizi dipende dai

dal grado di soddisfazione delle esegenze del cliente.

45

Relazione tra gestione del profilo e contesto

La seguente sezione descrive come il sistema di gestione del profilo,

oggetto del lavoro di tesi, interagisce con il Context Server allo scopo di

supportare i Service Provider nella personalizzazione dei servizi offerti.

In primo luogo il sistema di gestione del profilo deve garantire

un’interfaccia che permetta ad un utente la gestione delle proprie access list. Il

sistema di gestione del profilo utilizza un interfaccia Web per interagire con

l’utente.

Quindi un utente che accede al sistema di gestione del profilo, offerto

dall’operatore di rete, può richiedere di inserire nuove tuple e access list oppure

di modificare, cancellare e visualizzare tuple e access list già esistenti. Il sistema

di gestione avrà il compito di aggiornare database remoti per rendere effettive le

modifiche introdotte dall’utente. Inoltre, attraverso l’interfaccia Web messa a

disposizione dal sistema di gestione del profilo, l’utente ha la possibilità di settare

i valori dei parametri di contesto che lui stesso deve comunicare (User Provided

Information), come ad esempio l’attività che sta svolgendo.

Il Context Server, a fronte di una richiesta da parte di watcher, accede al

database per verificare se quest’ultimo è autorizzato a ricevere le informazioni di

contesto richieste. In questo modo la collaborazione tra sistema di gestione e

Context Server permette di fornire informazioni sulla presentity (utente) in base

alle direttive date dalla presentity stessa.

Il sistema di gestione del profilo utilizza il Context Server anche per

fornire supporto a servizi offerti dall’operatore di rete e da HE-VASP nel caso

questi richiedano la conoscenza di un insieme di informazioni di contesto

dell’utente. I VASP non possono usufruire di questo tipo di supporto poiché non

presentano requisiti all’interno del Virtual Home Environment.

L’utente infatti può sottoscriversi a questi servizi interagendo con il

sistema sviluppato nel lavoro di tesi. Durante la sottoscrizione al servizio, il

sistema informa l’utente di quali informazioni di contesto il servizio ha bisogno.

L’utente, da parte sua, deve poter proteggere la sua privacy quindi può scegliere

se fornire tali informazioni ai servizi oppure nasconderle. Nel caso in cui si offre

la visibilità di queste informazioni, la volontà dell’utente deve essere comunicata

46

al Context Server che potrà quindi autorizzare i servizi a vedere le informazioni di

contesto quando questi si presenteranno come watcher.

Il sistema di gestione del profilo può comunicare al Context Server la

volontà dell’utente a rendere visibili le sue informazioni di contesto ad un

determinato servizio, creando per conto dell’utente una Access List in cui l’unico

watcher associato è il servizio stesso e le tuple contengono gli attributi di contesto

richiesti. In questo modo un servizio autorizzato si può presentare,

successivamente, come watcher presso il Context Server ed accedere solo agli

attributi associati alle tuple dell’access list relativa al servizio.

Come visto nel capitolo 2, tra i vari requisiti che sono stati fissati per il

sistema di gestione del profilo è quello dell’attivazione automatica dei sub profile.

L’utente ha la possibilità di associare all’evento legato al cambiamento di un

determinato parametro di contesto l’azione di attivazione di un sub profile che lui

stesso ha definito. In questo modo il cambiamento di un determinato parametro di

contesto genera l’attivazione del sub profile associato. Quando un utente richiede

il servizio di attivazione automatica dei sub profile, viene creata una Access List

in cui il sistema di gestione del profilo rappresenta l’unico watcher mentre le tuple

associate contengono gli attributi di contesto relativi agli eventi definiti

dall’utente. Il sistema di gestione può in questo caso presentarsi al Context Server

come un subscribed-watcher e quindi ricevere le notifiche sul cambiamento degli

attributi specificati nelle tuple. In base al nuovo valore dell’attributo di contesto

notificato dal Context Server, il sistema di gestione esamina l’evento definito

dall’utente e decide se attivare il nuovo sub profile associato.

La comunicazione tra watcher e Context Server avviene tramite

un’estensione del protocollo di segnalazione SIP proposta dal SIMPLE Working

Group dell’IETF. Il protocollo SIP, viene esteso con alcuni messaggi che

permettono ai servizi di richiedere informazioni relative a presentity e viceversa al

Context Server di fornire i valori oppure le notifiche dei cambiamenti dei

parametri di contesto in momenti successivi.

I messaggi introdotti da SIMPLE, descritti in [simple02] sono:

SIP SUBSCRIBE Request: usata da un watcher che vuole conoscere

gli attributi di contesto di una presentity

⇒

47

SIP NOTIFY Request: fornisce il valore dell’attributo richiesto dal

watcher oppure lo notifica dell’avvenuto cambiamento del valore

dell’attributo in caso si trattava di un subscribed-watcher

⇒

Il watcher, può richiedere informazioni di contesto relative ad una

presentity inviando un SUBSCRIBE request verso il Context Server. In base al

tempo di monitoraggio della presentity inserito nella richiesta, il watcher sarà un

semplice fetcher oppure un subscribed-watcher. Il tempo di monitoraggio è

inserito nel campo expiration-time della SUBSCRIBE request. Se la

sottoscrizione e’ autorizzata, il Presence Server risponde con una risposta 200

OK. Successivamente viene inviato da parte del Context Server un NOTIFY

request per indicare al watcher il valore dell’attributo di contesto richiesto. Se si

tratta di un subscibed-watcher, il Context Server deve inviare una nuova NOTIFY

al watcher ogni volta che l’attributo richiesto subisce un cambiamento fino a

quando il watcher stesso non elimina la sottoscrizione inviando un

UNSUBSCRIBE (Subscribe request con il campo expiration-time = 0).

Il protocollo SIP e le estensioni introdotte da SIMPLE vengono descritte in

modo più approfondito nel capitolo dedicato alle tecnologie di progetto scelte.

Nella Figura 0-5 viene descritto lo scambio di messaggi che avviene tra il watcher

e il Context Server nel caso SUBSCRIBE. Il watcher si sottoscrive ad

un’informazione di contesto di un utente e se sono presenti i privilegi di accesso

necessari il Context Server risponde con un messaggio 200 OK. Il Context Server

fornisce subito il valore attuale dell’attributo richiesto attraverso il SIP NOTIFY.

Successivamente quando il valore dell’attributo di contesto subisce un

cambiamento viene inviato un ulteriore SIP NOTIFY al watcher per informarlo.

48

Figura 0-5: Scambio di messaggi tra Watcher e Context Server

Servizio di localizzazione

Lo standard 3GPP prevede il servizio di localizzazione per permettere lo

sviluppo di nuovi servizi basati sulla locazione di un utente. Il servizio fornisce la

locazione di un utente a utenti e servizi che ne fanno richiesta. Questo servizio è

supportato sia nella rete GSM mediante BSS sia nella rete UMTS mediante

UTRAN affinché sia facilitata la determinazione della locazione di un terminale

mobile.

Il servizio è fornito da un LCS Server (LoCation Services Server) che

accetta richieste di localizzazione da parte di LCS client. LCS server è un entità

hardware e software costituita da componenti distribuiti sulla rete. LCS client è un

entità hardware e software che interagisce con LCS server per ottenere

informazioni sulla posizione di uno o più utenti mobili. Nell’ambito di tale

servizio, si deve tener conto della privacy dell’utente di cui viene richiesta la

49

localizzazione. Tale utente dovrà quindi comunicare informazioni che introducono

limitazioni sulla visibilità della sua locazione per salvaguardare la sua privacy.

Queste informazioni caratterizzano l’utente e quindi saranno considerate

nell’ambito di un profilo.

Figura 0-6: Attori nel servizio di localizzazione

L’informazione di localizzazione che viene fornita in seguito ad una

richiesta presenta le seguenti caratteristiche:

Geographic Location: è la locazione geografica dello user equipment ⇒

⇒

⇒

Velocity: è un vettore costituito da velocità e direzione dello user

equipment

Qualità del servizio: è espressa mediante l’accuratezza e il tempo di

risposta sulle informazioni che verranno fornite al client del servizio

di locazione. Ad esempio, l’accuratezza potrebbe essere di pochi

metri per i servizi di navigazione mentre potrebbe essere di alcuni

chilometri per applicazioni di gestione delle flotte

50

Come è stato detto in precedenza, è importante, per l’utente, definire le

regole che caratterizzano la sua privacy. Gli attributi che descrivono la privacy

dell’utente sono :

Privacy Exception List: determina quali LCS client o quali classi di

LCS client possono richiedere informazioni sulla locazione

⇒

⇒

⇒

⇒

⇒

⇒

Privacy Override Indicator: determina l’applicabilità delle Privacy

Exception List

La Privacy Exception List è una lista che contiene varie tipologie di classi

private. Ogni classe contiene una lista di LCS client che possono accedere alle

informazioni sulla locazione del determinato utente. Le classi disponibili sono le

seguenti:

Universal Class: il servizio di localizzazione viene fornito a tutti gli LCS

client che ne fanno richiesta

Call/session-related Class: il servizio di localizzazione viene fornito a un

LCS client oppure a un gruppo di LCS client che ha un associazione

temporanea con l’utente nella forma di chiamata vocale o sessione dati

stabilita dall’utente stesso

Call/session-unrelated Class: il servizio di localizzazione viene fornito a

un LCS client oppure a un gruppo di LCS client che non hanno stabilito

chiamate con l’utente

PLMN operator class: il servizio di localizzazione viene fornito a un

LCS client oppure a un gruppo di LCS client che hanno funzionalità

particolari nella rete mobile, ad esempio un servizio offerto dall’operatore

di rete a cui l’utente si è sottoscritto

Per ogni LCS client inserito in una delle classi private appena descritte

verranno identificate restrizioni di tipo geografico come ad esempio la fornitura di

informazioni solo se il client è nella stessa PLMN dell’utente.

Il Privacy Override Indicator viene utilizzato per indicare i casi in cui non

devono essere consultate le private exception list. Tali casi possono essere

intercettazioni telefoniche a fini legali oppure richieste da parte di servizi di

51

emergenza. Comunque l’annullamento delle private exception list viene eseguito

in genere solo per richieste che vengono dalla stessa nazione a cui appartiene

l’utente.

Relazione tra gestione del profilo e servizio di localizzazione

Il sistema di gestione del profilo deve supportare l’utente nella

personalizzazione del Location Service poiché quest’ultimo mette a disposizione

di diverse entità (servizi e utenti) le informazioni sulla sua posizione. Essendo il

Location Service uno dei servizi offerti dall’operatore, si può prevedere tale

supporto definendo un apposito Service Profile. Il Service Profile relativo al

Location Service conterrà le entità che l’utente definisce per ogni classe di privacy

permettendo la definizione, per ognuna di queste entità, di restrizioni di natura

geografica. Il Service Profile viene comunicato al Location Server che consentirà

l’accesso alle informazioni di localizzazione in base alle direttive fornite

dall’utente.

Le informazioni relative alle Privacy Exception List vengono memorizzate

all’interno dell’ Home Location Register (HLR). L’accesso a questo database può

avvenire direttamente tramite interfacce fornite dai costruttori oppure estendendo i

protocolli di controllo utilizzati tra i nodi di rete, in particolare il protocollo MAP

che offre diverse interfacce per la modifica dei dati presenti nell’HLR.

Il Mobile Application Protocol (MAP), descritto in [3GPPTS29.002],

fornisce le funzionalità per lo scambio di informazioni tra i nodi di una Public

Land Mobile Network (PLMN) ed è visto dai suoi utilizzatori come un fornitore

di un determinato set di servizi.

52

Figura 0-7: Protocollo MAP

Come mostrato nella figura, i client utilizzano l’interfaccia messa a

disposizione dal MAP Server per ottenere informazioni, il MAP server, analizza

la richiesta e fornisce le informazioni richieste.

Gestione delle Terminal Capabilities

La fornitura delle capabilities del terminale avviene utilizzando la tecnica

UAProf che consiste nel memorizzare tali informazioni all’interno di opportuni

repository, che i Service Provider possono consultare nel momento in cui devono

offrire i loro servizi ad utenti mobili. In questo scenario, il sistema di gestione del

profilo ha il compito di fornire ai Service Provider tutte le informazioni necessarie

affinché questi possano eseguire delle query verso i repository UAProf. Si deve

quindi fornire l’URL del repository e il modello del terminale utilizzato

dall’utente. Si può verificare il caso in cui il terminale dell’utente non supporta la

tecnica UAProf, ciò implica che all’interno del repository non vi sarà alcuna

informazione che riguarda le capabilities dello specifico terminale. Questa

situazione introduce seri problemi all’interno del processo di personalizzazione

poiché i contenuti forniti da servizi all’utente non possono essere adattati al suo

terminale.

53

In questo scenario, il sistema di gestione del profilo può supportare

l’utente nella configurazione del profilo del suo terminale attraverso un’interfaccia

web.

Il profilo del terminale che l’utente inserisce è costituito da un

sottoinsieme di informazioni previste nel profilo UAProf. All’utente vengono

infatti richieste soltanto le informazioni ad alto livello, in modo che l’utente sia

facilitato nel fornirle tramite una form dell’interfaccia Web del sistema di gestione

del profilo. In questo caso, il servizio interagisce con il sistema di gestione del

profilo non per conoscere l’URL del repository ma per conoscere il profilo ridotto

del terminale utilizzato dall’utente.

54

4 Obiettivi e requisiti di progetto

In questo capitolo vengono presentati gli obiettivi, le assunzioni e i

requisiti di progetto. Gli obiettivi indicano in generale le caratteristiche che il

sistema di gestione deve possedere non limitate soltanto alle funzionalità che il

sistema offre all’utente o ai servizi. Le assunzioni individuano i requisiti richiesti

per utente e operatore affinché possano usufruire delle funzionalità offerte dal

sistema. I requisiti vengono presentati sotto forma di use case e rappresentano le

effettive funzionalità del sistema quindi ciò che utenti e servizi potranno

utilizzare.

Obiettivi del progetto

Lo scopo del lavoro di tesi è quello di definire un sistema per la gestione

delle informazioni di profilo degli utenti di terza generazione identificando inoltre

un processo che permetta la personalizzazione dei servizi.

Il progetto del sistema deve supportare la gestione del profilo da parte

dell’utente e l’accesso a tali informazioni da parte di servizi autenticati e

autorizzati. Tali funzionalità vengono realizzate nascondendo sia ad utenti che a

servizi la distribuzione delle informazioni di profilo tra i nodi di rete e server

esterni.

55

L’utente può associare i valori delle informazioni di profilo a parametri di

contesto attraverso il servizio di attivazione automatica dei sub profile messo a

disposizione dal sistema proposto in modo da associare le sue esigenze e le sue

necessità al contesto in cui si trova. Il valore dei parametri di contesto è fornito al

sistema dal Conext Server oppure dall’utente stesso come è stato visto nel capitolo

3.

Tra le informazioni di profilo gestite, oltre a quelle considerate nel Generic

User Profile, sono presenti le Access List che definiscono i diritti di accesso alle

informazioni di contesto di un utente. In questo modo, l’utente attraverso

l’interfaccia web offerta dal sistema può configurare opportunamente il Context

Service.

Il progetto viene elaborato in modo che possibili estensioni sulle

informazioni del profilo non causino stravolgimenti all’interno del software. Per

questo motivo viene utilizzato, dove possibile il linguaggio XML per la

memorizzazione dei dati. I dati di cui l’operatore di rete è proprietario vengono

espressi attraverso XML ma comunque si deve prevedere un‘interazione con dati

espressi in forme diverse ad esempio organizzati secondo un approccio relazionale

poiché alcuni Service Provider con cui l’operatore stringe rapporti non avranno

necessariamente a disposizione database XML nativi.

Il progetto deve quindi consentire la creazione futura di un prototipo per la

gestione del profilo in ambiente UMTS. La memorizzazione dei dati XML del

prototipo può essere effettuata mediante il DBMS XML nativo TAMINO

(Transaction Architecture for the Management of INternet Object).

Il processo di personalizzazione proposto nel lavoro di tesi viene creato

sulla base delle informazioni che il sistema progettato ha a disposizione e sulle

informazioni fornite dal Context Server. Quindi tale processo fa uso delle

informazioni di profilo sia statiche che dinamiche.

56

Assunzioni

Le assunzioni sono relative alle caratteristiche dell’utente e a quelle

dell’operatore che fornisce servizi mobili ed il servizio di trasporto . Il sistema

software che viene progettato viene introdotto in un ambiente che presenta le

seguenti caratteristiche:

• L’utente è disponibile al trattamento dei suoi dati personali al fine di

ricevere servizi personalizzati.

• L'operatore mobile ha in campo sia una rete GSM/GPRS che una rete

UMTS

• L’utente possiede un terminale multimodo per l’utilizzo di una tra le

tecnologie di accesso disponibili in una determinata locazione e in un

determinato istante.

• Il terminale dell'utente ha le capacità elaborative e di visualizzazione di un

PAD.

Requisiti funzionali

In questa sezione vengono presentati i requisiti funzionali del sistema da

progettare utilizzando gli use case del linguaggio UML. Gli use case

rappresentano gli scenari d’uso del sistema da parte degli attori esterni e quindi

descrivono le funzionalità ad alto livello che il sistema deve offrire. Agli use case

viene associato un flusso di operazioni che l’utente ed il sistema devono compiere

per raggiungere lo scopo prefissato. Si identifica inoltre per ogni use case l’attore,

le pre-condition cioè le condizioni che devono essere soddisfatte prima che inizi il

flusso di operazioni e le post-condition cioè i risultati. Il flusso di operazioni potrà

57

subire modifiche in base alla risposta dell’utente o del sistema, tale situazione è

gestita tramite una lista di exception. Ogni elemento di questa lista è associato a

due numeri. Il primo indica il passo all’interno dello use case al quale si riferisce.

Il secondo invece numera le possibili eccezioni per un determinato passo poiché

per, ogni passo, si può presentare anche più di un’eccezione.

Gli attori del sistema in esame sono i seguenti:

User ⇒

⇒

Rappresenta l’utente di una rete mobile che interagisce con il sistema allo

scopo di gestire il suo profilo e utilizza i servizi offerti sia dall’operatore di

rete che da altri Service Provider. L’utente viene identificato univocamente

all’interno del sistema di gestione attraverso il suo MSISDN (numero

telefonico) oppure attraverso il SIP URL (è un identificativo univoco che

permette di indirizzare le entità SIP sia client che server) assegnati

dall’operatore in fase di stipulazione del contratto.

Servizio

Rappresenta il generico servizio che può essere fornito sia direttamente

dall’operatore di rete sia da altri Service Provider. Tali servizi

interagiscono con il sistema per richiedere informazioni relative agli utenti

per motivi di personalizzazione. L’utente all’interno del sistema di

gestione del suo profilo ha la possibilità di definire, oltre alle sue

informazioni e preferenze generali, anche le preferenze relative a servizi

specifici offerti sia dall’operatore si da HE-VASP. Tali informazioni

costituiscono il Service Profile del servizio. La scelta della tipologia di

preferenze che costituisce il Service Profile viene fatta dal Service

Provider che offre il servizio in base alle sue esigenze. Servizi diversi

hanno infatti bisogno di conoscere preferenze service-dependent diverse

dell’utente da utilizzare nel processo di personalizzazione. Ad esempio, un

servizio ‘VideoGoal’ potrebbe aver bisogno di conoscere la squadra

preferita dell’utente mentre il servizio MMS (Multimedia Messaging

Service) ha bisogno di conoscere se l’utente desidera ricevere la notifica di

avvenuta lettura del messaggio. Come mostrano gli esempi quindi servizi

diversi possono richiedere la conoscenza di preferenze sui servizi del tutto

58

diverse tra loro. Servizi che non hanno definito un particolare accordo

con l’operatore (VASP), possono comunque accedere alle informazioni

generali e alle preferenze service-independent dell’utente.

Context Server ⇒

E’ l’entità funzionale, gestita dall’operatore di rete, che offre un particolare

servizio denominato ‘Context Service’. Il Context Server ha lo scopo di

recuperare e fornire informazioni di contesto, relative ad un determinato

utente (presentity), e fornirle a servizi che le utilizzeranno per scopi di

personalizzazione e ad altri utenti interessati a conoscere lo stato della

presentity. Il sistema di gestione del profilo fornisce all’utente alcune

funzionalità per definire le regole di accesso alle informazioni di contesto.

Le regole vengono definite mediante access list corrispondenti ad

associazioni tra un gruppo di utenti e un insieme di tuple. Sono costituite

da una lista di watcher che hanno l’autorizzazione alla lettura di

informazioni di contesto contenute all’interno delle tuple associate. Le

tuple contengono coppie <attributo, valore> che esprimono le informazioni

di contesto. Il sistema proposto deve inoltre fornire un’interfaccia

mediante la quale un utente può fornire direttamente informazioni di

contesto che lo riguardano. Queste informazioni non possono essere

ottenute da agenti presenti nella rete e quindi devono essere segnalate al

sistema dall’utente stesso. Un esempio può essere l’attività che l’utente sta

svolgendo: riunione, tempo libero ed altre possibili alternative.

Viene presentato inizialmente uno use case generale che mostra i requisiti ad alto

livello dei vari attori che interagiscono con il sistema. Successivamente tali use

case verranno trattati in dettaglio maggiore.

59

Figura 0-1: Use case generale che mostra i requisiti ad alto livello di

utenti, sevizi generali e Context Server

Il sistema proposto offre la possibilità ad utenti mobili di gestire i dati del proprio

profilo utente attraverso un’interfaccia Web. Lo scenario in questo senso può

essere molto ampio poiché sono molte le informazioni che caratterizzano un

utente in una rete mobile. Ciò che però deve essere chiaro è che il supporto alla

gestione del profilo fornito all’utente è finalizzato alla personalizzazione dei

servizi offerti sia dall’operatore sia da fornitori di servizi che abbiano preso

accordi più o meno stringenti (VASP e HE-VASP) con l’operatore di rete.

Affinché il servizio possa essere offerto in modo personalizzato in base alle

esigenze dell’utente, il sistema gestisce i sub profile che permettono di presentare

l’utente secondo le attuali caratteristiche come, ad esempio, il luogo in cui si torva

(home, office,…) oppure le terminal capabilities. Tali informazioni rappresentano

soltanto due dei possibili esempi.

60

L’insieme delle informazioni che costituisce il profilo dell’utente è

organizzato logicamente in component in linea all’organizzazione logica del

3GPP GUP come descritto in [3GPPTS23.240]. Ogni component può presentare

diverse istanze. I sub profile definiti dall’utente sono costituiti da istanze di

component con il vincolo che uno stesso sub profile non può accogliere due o più

istanze del medesimo component. Solo un’istanza di un component può essere

attiva in un determinato istante. Ogni sub-profile caratterizza le esigenze

dell’utente in una determinata situazione, ad esempio in base all’ambiente in cui si

trova (home , office,…). In un determinato istante soltanto uno tra questi sub-

profile potrà essere attivo ed è appunto l’Active sub-profile. L’utente sarà

caratterizzato dal suo Active sub-profile affinché possa ricevere informazioni e

servizi che soddisfino le sue necessità.

La gestione di sub profile aumenta molto le potenzialità del sistema

rispetto alla personalizzazione tradizionale poiché l’utente ha a disposizione un

maggior numero di gradi di libertà per descrivere le sue preferenze. Oltre alla

gestione del profilo il sistema fornisce supporto ai servizi mettendoli in

condizione di richiedere informazioni relative all’utente utilizzando un’opportuna

interfaccia. Il sistema fornisce inoltre supporto al Context Server prevedendo le

funzionalità per la gestione delle access rule da parte dell’utente. Tali

informazioni vengono utilizzate dal context server per stabilire la visibilità delle

informazioni di contesto.

Registrazione di un nuovo utente

La registrazione dell’utente sul portale del MNO (Mobile Network

Operator) avviene interagendo con lo User Profile Manager (UPM). Grazie alle

registrazione nel portale, l’utente ha la possibilità di usufruire di diversi servizi

offerti dall’UPM stesso che riguardano la gestione delle proprie informazioni di

profilo, di presenza/conteso e la personalizzazione dei propri servizi.

In questo scenario si mostrano i passi che un utente deve seguire per

portare a termine l’operazione di registrazione. La registrazione di un utente ha

61

quindi lo scopo di assegnare una password all’utente che è identificato nel sistema

di gestione attraverso il proprio userID. Lo userID e la password saranno

utilizzate successivamente per ottenere l’autorizzazione di accesso al sistema.

Actor: User

Goal: Registrazione al sistema

Precondition: lo user ha un contratto con l’operatore

Action:

1. L’utente accede al sistema e chiede di registrarsi

2. Il sistema richiede l’inserimento dello userID da parte dell’utente

3. L’utente inserisce il suo userID

4. Il sistema verifica che tale userID non è già stato presente nel db delle

sottoscrizioni

5. Il sistema richiede due volte (per la conferma) l’inserimento della

password

6. Il sistema registra l’utente con il suo userID e password

7. Il sistema richiede informazioni di profilo: informazioni personali, user

preferences per definire un profilo di default iniziale

8. Il sistema richiede all’utente se possono essere utilizzate le sue

informazioni di contesto per il servizio di attivazione automatica del sub-

profile

Post Condition: L’utente si è registrato

Exception:

2.1 Il sistema non è attivo

5.1 Lo userID è già presente nel DB e quindi si richiede nuovamente

l’inserimento di tale informazione

Autenticazione e Autorizzazione

Tali operazioni permettono di identificare l’utente e decidere se questo può

usufruire del servizio richiesto. Oltre a garantire che i servizi offerti siano

62

utilizzati soltanto da utenti autenticati e autorizzati, si prevedono tecniche di

crittografia per garantire la riservatezza dei dati.

Autenticazione

L’autenticazione deve essere fatta sia per utenti che richiedono la gestione

del proprio profilo sia per servizi che accedono alle informazioni di utenti. Per

mezzo dell’autenticazione si determina l’identità di chi desidera accedere alle

User Profile Information.

Actor: User, Servizio

Goal: Autenticazione

Precondition: L’utente ha un contratto con l’operatore che offre le funzionalità di

gestione delle informazioni generali di profilo, di preferenze relative ai servizi e di

informazioni di contesto ed il servizio che ha stretto particolari rapporti con

l’operatore richiede l’accesso alle informazioni dell’utente per scopi di

personalizzazione.

Action:

1. L’utente o il servizio richiede l’accesso o la gestione alle informazioni di

profilo

2. Il sistema richiede le informazioni per l’autenticazione che per l’utente

sono userID e password mentre per il servizio sono serviceID e una

password detta SecretToken

3. L’utente o il servizio inserisce tali informazioni

4. Il sistema valuta in base alle informazioni introdotte se l’utente o il

servizio sono identificati e quindi autenticabili

5. Il sistema permette l’accesso alle informazioni

Post Condition: L’utente o il servizio accedono alle informazioni del sistema

Exception:


5.1 L’utente o il servizio non viene autenticato poichè non viene identificato

63

Autorizzazione

Tale procedura viene utilizzata nel momento in cui un utente richiede una

determinata operazione del sistema di gestione del profilo oppure un servizio

richiede l’accesso alle informazioni dell’utente. Vengono definite due tipi di

access list: Operator Access List e access list relative ai servizi rispettivamente per

utenti e servizi.

Mediante le access list, l’operatore può definire i permessi per la gestione

delle informazioni contenute nel profilo. Le access list sono basate sulle seguenti

informazioni:

Identità richiedente(utente,servizio) ⇒

⇒

⇒

Lista di coppie <User Profile Component, modalità di accesso> dove la

modalità di accesso può essere ReadOnly, ReadWrite o Denied.

Solo nelle Operator Access List e non nelle access list per i servizi è

presente l’informazione sull’abilitazione alla gestione dei sub profile da

parte dell’utente che può assumere i valori True/False

Quindi per ogni richiedente, sia questo un servizio o un utente, l’operatore

definisce una access list che contiene i component che possono essere consultati e

le relative operazioni che si possono fare su di essi. Naturalmente un servizio può

sempre accedere a queste informazioni solo in lettura.

Per quanto riguarda l’utente invece, si deve considerare sia il tipo di informazione

richiesta sia l’operazione che deve essere fatta. Si distingue l’operazione di lettura

dalle altre operazioni (inserimento modifica e cancellazione). Un utente può

accedere ad informazioni solo in lettura solo in eventi particolari come il caso in

cui sia moroso o ad esempio il credito della scheda prepagata sia esaurito.

Actor: User, Servizio

Goal: Autorizzazione

Precondition: Il richiedente è autenticato

Action:

1. L’utente o il servizio richiede accesso e gestione delle informazioni di

profilo

64

2. Il sistema valuta i diritti di accesso in base alle informazioni richieste e

alle access list

3. Il servizio o l’utente viene autorizzato

Post Condition: L’utente o il servizio accedono alle informazioni del sistema

Exception:


3.1 L’utente o il servizio non hanno i diritti per essere autorizzati

Sottoscrizione on-line ad un servizio

In questo use case si mostrano i passi che devono essere seguiti per la

sottoscrizione di un utente ad un nuovo servizio. L’utente, oltre a definire le

preferenze per il servizio, dovrà decidere se rendere accessibili al servizio a cui si

sottoscrive le sue informazioni di contesto.

Actor: User

Goal: Sottoscrizione on-line ad un servizio

Precondition: L’utente è stato autenticato e autorizzato a sottoscrivere nuovi

servizi

Action:

1. L’utente accede al sistema richiedendo una lista dei servizi disponibili

2. Il sistema fornisce la lista

3. L’utente sceglie il servizio

4. Il sistema verifica se l’utente non è già sottoscritto

5. Il sistema richiede all’utente l’inserimento delle service preferences per

quel determinato servizio

6. L’utente inserisce le informazioni richieste

7. Il sistema visualizza le informazioni di contesto di cui il servizio ha

bisogno

8. L’utente sceglie se dare la visibilità di tali informazioni oppure usufruire

del servizio senza che questo acceda a tali dati

9. Il sistema controlla le informazioni inserite

10. Il sistema memorizza le informazioni nel db del servizio

65

Post Condition: Le informazioni sono inserite nel db del servizio

Exception:


5.1 L’utente è già sottoscritto al servizio

7.2 L’utente sceglie di non sottoscriversi più al servizio

10.1 Le informazioni inserite sono errate

Gestione informazioni dell’utente

Questo use case descrive le funzionalità offerte dal sistema verso l’utente

per la gestione delle sue informazioni. Tali informazioni comprendono i dati

personali (nome, età, ….), le preferenze generali (lingua, interessi,….) dell’utente

e le regole di privacy. Le informazioni precise che rientrano nelle informazioni

generali dell’utente saranno trattate nel capitolo di progetto.

Figura 0-2: Use case relativi alle gestione delle informazioni che

descrivono l'utente

Gestione informazioni generali

Lo use case riguarda la possibilità dell’utente di eseguire l’inserimento, la

modifica e la cancellazione delle proprie informazioni personali. Le informazioni

personali descrivono l’utente in modo generale. Tali informazioni rappresentano

66

un component dello User Profile che può avere al massimo un’unica istanza. Tali

funzionalità agiranno sempre sulla stessa istanza del component.

Actor: User

Goal: gestione delle proprie informazioni generali da parte di un utente

Precondition:L’utente è stato autenticato con successo

Action:

1. L’utente richiede la gestione delle proprie informazioni generali

2. Il sistema verifica se l’utente è autorizzato a effettuare l’operazione

3. Il sistema visualizza un form in cui sono contenute le attuali informazioni

generali dell’utente

4. L’utente esegue le opportune operazioni (inserimenti, modifiche e

cancellazioni)

5. L’utente segnala la conclusione dell’operazione (ad esempio cliccando su

un bottone visualizzato sulla pagina)

6. Verifica della correttezza delle informazioni. Se le informazioni non sono

corrette si torna al punto 2

7. Il sistema memorizza le nuove informazioni generali

Post Condition: le informazioni generali vengono modificate nel modo

desiderato dall’utente

Exception:


3.1 L’utente non è autorizzato ad eseguire l’operazione

Gestione User Preferences

Sono le funzionalità che permettono all’utente l’inserimento, la modifica e

la cancellazione di user preferences (lingua, interessi,…). Le user preferences

costituiscono un component dello User Profile che possono dar luogo a differenti

istanze caratteristiche del contesto in cui si trova l’utente:

67

Figura 0-3: Use Case relativi alla gestione delle user preferences

Vengono analizzati in modo dettagliato gli use case appena espressi:

Inserimento di una nuova istanza di User Preferences

Actor: User

Goal: inserimento di una nuova istanza di user preferences

Precondition: L’utente è stato autenticato con successo

Action:

1. L’utente richiede la creazione di una nuova istanza di user preferences


3. Presentazione di un form vuoto con i campi previsti per user preferences

4. L’utente inserisce le nuove informazioni


un tasto visualizzato sulla pagina)



7. Il sistema memorizza le nuove informazioni

Post Condition: le user preferences vengono inserite nel repository

Exception:

68



Modifica di un’istanza di user preferences

Actor: User

Goal: modifica di un’istanza esistente di user preferences

Precondition: L’utente è stato autenticato con successo ed esiste almeno

un’istanza di user preferences

Action:

1. L’utente richiede la modifica di un’istanza


3. Visualizzazione delle istanze esistenti

4. L’utente sceglie l’istanza che vuole modificare

5. Il sistema visualizza un form in cui sono contenuti gli attuali valori

dell’istanza

6. L’utente modifica i valori





9. Il sistema memorizza le nuove informazioni personali

Post Condition: le user preferences vengono modificate nel repository

Exception:



Cancellazione di un’istanza di user preferences

Actor: User

Goal: cancellazione di un’istanza di user preferences

Precondition: L’utente è stato autenticato con successo ed esiste almeno

un’istanza di user preferences

69

Action:

1. L’utente richiede la cancellazione di un’istanza



4. L’utente sceglie l’istanza che vuole eliminare


dell’istanza con un pulsante che permette la cancellazione

6. L’utente clicca sul bottone altrimenti si torna al punto 2

7. Il sistema elimina l’istanza

Post Condition: l’istanza selezionata viene eliminata dal repository

Exception:



Gestione sub-profile

In questa fase si presentano gli use case relativi alla gestione del sub-

profile. L’utente oltre ad eseguire operazioni standard come inserimento, modifica

e cancellazione di sub-profile può scegliere tra questi l’ Active sub-profile e il

Default sub-profile. Si presentano quindi i seguenti use case:

Figura 0-4: Use Case relativi alla gestione dei sub profile

70

L’utente, all’interno del sistema software, può definire diversi sub-profile in base

alle sue esigenze ed in un determinato istante soltanto uno tra questi sub-profile

può essere attivo. Il sub-profile attivo prende il nome di Active sub-profile.

L’utente sarà caratterizzato dal suo Active sub-profile affinché possa

ricevere informazioni e servizi che soddisfino le sue necessità. Ad esempio un

utente può definire per uno stesso servizio di news due service profile, uno per il

tempo libero in cui richiederà informazioni sugli spettacoli ed uno per l’ufficio in

cui richiederà notizie sui mercati economici.

L’utente deve poter effettuare la scelta sia in modo esplicito sia in modalità

automatica. La selezione esplicita dell’Active sub-profile avviene quando l’utente

accede direttamente alla gestione del suo sub-profile per far riflettere il

cambiamento delle sue esigenze sul suo profilo. Si deve inoltre supportare la

scelta automatica dell’Active sub-profile in base ad eventi di contesto che

modificano le necessità dell’utente. L’utente definisce tali eventi sulla base di un

insieme di alternative fornite dal sistema e per ognuno di questi eventi deve

assegnare il sub-profile da attivare. Nel momento in cui si presenta tale evento,

notificato dal context server, il sistema deve provvedere, in modo automatico, al

cambiamento dell’Active sub-profile. Oltre all’Active sub-profile, l’utente può

definire un default sub-profile che viene considerato come Active sub-profile

quando non vi è una specifica scelta. In genere il default sub-profile è generale e

non è customizzato per rappresentare una particolare situazione dell’utente.

Inserimento sub-profile

Lo use case riguarda la possibilità dell’utente di inserire sub-profile:

Actor: User

Goal: inserimento di un nuovo sub-profile

Precondition: L’utente è stato autenticato con successo ed ha già inserito istanze

del suo profilo

Action:

1. L’utente richiede la creazione di un nuovo sub profile a cui assegna un

nome


71

3. Per ogni component vengono presentate le rispettive istanze mediante

visualizzazione di form contenenti gli specifici valori

4. L’utente sceglie per ogni component nessuna oppure un’istanza da inserire

nel nuovo sub-profile (in questa fase si impedisce l’inserimento di due o

piu istanze dello stesso component)



6. Il sistema memorizza il nuovo sub-profile

Post Condition: il sub-profile viene inserito nel repository

Exception:



Modifica sub-profile

Lo use case riguarda la possibilità dell’utente di modificare un sub-profile

inserito precedentemente

Actor: User

Goal: modifica di un sub-profile esistente

Precondition: L’utente è stato autenticato con successo ed ha già definito uno o

più sub-profile

Action:

1. L’utente richiede la modifica di un sub profile


3. Visualizzazione sub-profile esistenti

4. L’utente sceglie il sub-profile da modificare

5. Per ogni component vengono presentate le rispettive istanze con i valori

dei campi associati. e viene visualizzato inoltre, se c’è, quale istanza

appartiene al sub-profile in esame.

6. Per ogni component l’utente sceglie quale istanza inserire nel sub-profile

(in questa fase si impedisce l’inserimento di due o piu istanze dello stesso

component)

72



8. Il sistema memorizza il sub-profile modificato

Post Condition: il sub-profile viene modificato nel repository

Exception:



Cancellazione sub-profile

Lo use case riguarda la possibilità dell’utente di eliminare un sub-profile

precedentemente inserito:

Actor: User

Goal: Cancellazione di un sub-profile


piu sub-profile

Action:

1. L’utente richiede la cancellazione di un sub-profile


3. Visualizzazione dei sub-profile esistenti

4. L’utente sceglie il sub-profile che vuole eliminare

5. Il sistema visualizza le istanze appartenenti al sub-profile con un tasto che

permette al cancellazione

6. L’utente clicca sul tasto altrimenti si torna al punto 2

7. Il sistema elimina il sub-profile

Post Condition: il sub-profile viene eliminato dal repository

Exception:



73

Scelta del default sub-profile

Tale funzionalità permette all’utente di definire il proprio default sub-

profile. Il default sub-profile viene utilizzato come profilo dell’utente quando non

è presente una specifica scelta dell’Active sub-profile da parte dell’utente.

L’operazione di scelta prevede i seguenti passi:

Actor: User

Goal: scelta default sub-profile


più sub-profile

Action:

1. L’utente richiede la scelta del default sub-profile



4. L’utente sceglie il sub-profile che vuole far divenire default sub-profile


permette di ribadire la scelta effettuata


7. Il sistema memorizza il sub-profile in esame come il nuovo default sub-

profile

Post Condition: il sub-profile viene identificato come default sub-profile

Exception:



Scelta active sub-profile

Tale funzionalità permette all’utente di rendere un sub-profile attivo. Il

processo che realizza questa funzionalità si dovrà attivare sia quando l’utente

interagisce direttamente con il sistema per cambiare il suo sub-profile attivo ma

anche quando si verifica l’evento di scelta automatica del sub-profile specificato

dall’utente. L’evento corrisponde al cambiamento di un parametro di contesto

notificato dal context server. Il context server notificherà anche il cambiamento

dei parametri di contesto forniti direttamente dall’utente (es. Subscriber Location)

74

Quindi in questo sottoinsieme sono presenti anche le funzionalità per la scelta di

metodi automatici di attivazione dei sub-profile

Scelta esplicita dell’Active sub-profile

Actor: User

Goal: Scelta esplicita dell’active sub-profile


piu sub-profile

Action:

1. L’utente richiede la scelta dell’Active sub profile



4. L’utente sceglie il sub-profile che vuole far divenire Active sub-profile


permette di ribadire la scelta effettuata


7. Il sistema memorizza il sub-profile in esame come il nuovo Active sub-

profile

Post Condition: il sub-profile viene identificato come Active sub-profile

Exception:



Scelta automatica dell’Active sub-profile

Actor: User

Goal: Scelta automatica dell’active sub profile

Precondition: L’utente è stato autenticato con successo, è supportata la scelta

automatica dell’Active sub-profile e l’utente ha già definito uno o piu sub-profile

Action:

1. L’utente richiede la gestione degli eventi di scelta automatica

75


3. Si visualizzano gli eventi disponibili e quelli già settati

4. L’utente sceglie l’inserimento di un nuovo evento oppure la modifica di un

evento esistente

5. Il sistema visualizza un campo con il sub profile associato ( oppure vuoto

se l’evento non è stato mai utilizzato)

6. L’utente inserisce il sub-profile associato all’evento scelto

7. Il sistema controlla se lo stesso evento non è associato ad altri sub-profile

altrimenti si invia un messaggio di errore e si torna a 3

8. Il sistema memorizza la nuova coppia

9. Il sistema interagisce con il Context Server attraverso le operazioni di

subscribe e unsubscribe al fine di attivare o disattivare il monitoraggio e

quindi la notifica degli eventi di interesse.

Post Condition: il sub-profile viene settato come Active sub-profile quando si

presenta l’evento indicato

Exception:



Funzionalità per la gestione di Access List

Sono le funzionalità che permettono all’utente l’inserimento di tuple e di

access list per mezzo delle quali vengono espresse le regole di visibilità per i

parametri di contesto. Watchers, all’interno delle access list, vengono identificati

mediante ‘presence URL’; mentre le presence info vengono descritte come tuple

(coppie attributo,valore)

76

Figura 0-5: Use Case relativi alla gestione delle Access List

Gestione access list

Il caso d’uso rappresenta la capacità da parte dell’utente di gestire le

access list allo scopo di modificare le access rules. Se un access list viene

eliminata vengono cancellati i gruppi di utenti ma non vengono eliminate le tuple

che potrebbero essere in comune con altre access list ancora esistenti.

Actor: User

Goal: Gestione access list

Precondition: L’utente è stato autenticato con successo dall’operatore ed è

sottoscritto al servizio di Presenza/Contesto.

Action:

1. L’utente richiede la gestione di access list


3. Visualizzazione access list esistenti e tasto per inserimento di una nuova

access list

4. L’utente sceglie quale access list gestire oppure di crearne una nuova

5. Il sistema visualizza un form con gli attuali presence URL (nessun

destinatario nel caso di una nuova access list) e le tuple associate

6. L’utente può inserire i nuovi presence URL e le nuove tuple, modificare il

valore degli attributi delle tuple oppure eliminare l’access list

7. Verifica della correttezza delle informazioni nel caso di operazioni di

inserimento e modifica

77

8. Il sistema memorizza i nuovi dati

Post Condition: le access list vengono modificate

Exception:



Gestione tuple

Le tuple rappresentano insieme di informazioni di contesto che l’utente

può associare a diverse access list

Actor: User

Goal: Gestione tuple

Precondition: L’utente è stato autenticato con successo ed ha sottoscritto il

Context/Presence server

Action:

1. L’utente richiede la gestione di tuple


3. Visualizzazione tuple esistenti e tasto per inserimento di una nuova tupla

4. L’utente sceglie quale tupla gestire oppure di crearne una nuova

5. Il sistema visualizza un form con i parametri di contesto (nessun

parametro nel caso di una nuova tupla)

6. L’utente inserisce o modifica attributi nella tupla oppure sceglie di

eliminare la tupla selezionando un opportuno pulsante

7. Verifica della correttezza delle informazioni nel caso di operazioni di

inserimento e modifica

8. Il sistema memorizza i nuovi dati

Post Condition: la tupla viene modificata come richiesto dall’utente

Exception:



78

Personalizzazione dei servizi offerti dall’operatore e da HE-VASP

Sono le funzionalità che permettono all’utente di gestire istanze di service

profile relative a servizi offerti direttamente dall’operatore. L’utente grazie allo

User Profile Manager, può definire diverse istanze di tali Service Profile e

associare queste a diversi sub-profile. In questo modo il cambiamento dell’Active

sub-profile comporta il cambiamento di service profile per i servizi offerti

dall’operatore di rete.

Figura 0-6: Use Case relativi alla gestione delle istanze di Service

Profile

Inserimento di una nuova istanza di service profile

Actor: User

Goal: inserimento di una nuova istanza di service profile

Precondition: L’utente è stato autenticato con successo ed inoltre ha sottoscritto

uno o più servizi

Action:

1. L’utente richiede la creazione di una nuova istanza di service profile

2. Il sistema verifica se l’utente è autorizzato da effettuare l’operazione

79

3. Presentazione di un form vuoto con i campi previsti per service profile

4. L’utente inserisce le nuove informazioni





7. Il sistema memorizza le nuove preferenze

Post Condition: i service profile vengono inseriti nel repository

Exception:



Modifica di un’istanza di service profile

Actor: User

Goal: modifica di un’istanza esistente di service profile

Precondition: L’utente è stato autenticato con successo ed inoltre è sottoscritto al

servizio

Action:

1. L’utente richiede la modifica di un’istanza



4. L’utente sceglie l’istanza che vuole modificare


dell’istanza

6. L’utente esegue le opportune operazioni (inserimenti, modifiche e

cancellazioni)





9. Il sistema memorizza le nuove preferenze

80

Post Condition: il service profile viene modificato nel modo desiderato e salvato

nel repository

Exception:



Cancellazione di un’istanza di service profile

Actor: User

Goal: cancellazione di un’istanza di service profile

Precondition: L’utente è stato autenticato con successo ed ha già una o più

istanze di service preferences

Action:

1. L’utente richiede la cancellazione di un’istanza



4. L’utente sceglie l’istanza che vuole eliminare


dell’istanza con un tasto che permette la cancellazione


7. Il sistema elimina l’istanza

Post Condition: l’istanza selezionata viene eliminata

Exception:



Richiesta di informazioni da parte di un servizio

Il sistema mette a disposizione chiamate di procedure remote per

permettere ai servizi di accedere previa autorizzazione ai component Basic Profile

e Capabilities Description contenuti nel profilo dell’utente. L’autorizzazione è

fornita in base alle access list che l’operatore introduce per lo specifico servizio.

81

L’access list contiene la modalità con cui il servizio può accedere alle

informazioni di ogni component. Per i servizi viene in generale utilizzata la

modalità “ReadOnly” oppure “Denied” per i component che vogliono essere resi

non visibili. Il component Basic Profile contiene le informazioni generali

dell’utente e le sue preferenze generali quindi service-independent mentre con

Capabilities Description si identificano il modello del terminale utilizzato

dall’utente e l’indirizzo dell’UAProf repository contenente la sua descrizione nel

caso sia supportata tale soluzione. Nel caso in cui il terminale dell’utente non

supporti UAProf allora in Capabilities Description è contenuta una descrizione

inserita dall’utente relativa alle capabilities del terminale sulla stessa linea del

profilo UAProf.

Actor: Servizio

Goal: Fornitura di informazioni sul profilo

Precondition: Il servizio è stato autenticato con successo. Il servizio è offerto

dall’operatore stesso il servizio ha un contratto con l’operatore per accedere alla

informazioni

Action:

1. Il servizio richiede informazioni su un determinato utente

2. Il sistema verifica se il servizio è autorizzato in base alle access list

definite dall’operatore per i servizi

3. Il sistema ricerca le informazioni

4. Il sistema fornisce le informazioni richieste al servizio

Post Condition: Il servizio ottiene le informazioni richieste

Exception:


3.1 Il servizio non è autorizzato

4.1 Le informazioni non sono presenti nel sistema

82

Notifica cambiamenti di contesto

Nel momento in cui il sistema riceve la notifica del cambiamento di

contesto, precedentemente associato ad un sub-profile, il sistema deve modificare

l’Active sub-profile nel modo definito dall’utente durante la gestione dei sub-

profile.

Actor: Context Server

Goal: Cambiamento dell’Active Sub-profile

Precondition: L’utente ha identificato il sub-profile da attivare per il

cambiamento di un determinato parametro di contesto. Il sistema si è sottoscritto

come watcher.

Action:

1. Il context server notifica il cambiamento di un attributo di contesto

2. Viene cambiato l’Active sub-profile come definito dall’utente nella

gestione dei sub-profile

Post Condition: Diventa attivo un nuovo sub-profile

Exception:


Gestione Terminal Capabilities

Tali funzionalità vengono utilizzate dall’utente per introdurre un profilo di

default del proprio terminale quando non sia possibile utilizzare UAProf. Quando

UAProf non viene supportato, il servizio che interagisce con il terminale non

riceverà l’URL del file UAProf associato al terminale dell’utente.

Il sistema, una volta venuto a conoscenza del modello del terminale, interroga

l’UAProf repository. Se non viene restituito il file relativo al profilo del terminale

il sistema provvederà a richiedere le informazioni statiche sul suo dispositivo.

Il servizio, non ricevendo informazioni UAProf dal terminale dell’utente,

accederà direttamente al sistema di gestione dei profili per richiedere il profilo di

default del terminale che sta utilizzando l’utente.

83

Il profilo di default contiene un insieme molto ridotto di informazioni

rispetto a UAProf. Tali informazioni sono ad alto livello in modo che l’utente

possa comprendere il significato dei campi del form che gli viene presentato.

Nessuno di questi campi sarà obbligatorio.

Actor: User

Goal: Gestione Terminal Capabilities

Precondition: L’utente è stato autenticato

Action:

1. L’utente richiede la gestione del profilo di default del suo terminale

2. Il sistema richiede l’inserimento del modello del terminale

3. Il sistema determina l’URL associato a quel tipo di terminale nell’UAProf

repository e verifica se è presente il relativo file

4. Se il terminale supporta UAProf non vengono richieste le successive

informazioni altrimenti si passa al punto 5

5. Il sistema visualizza un form in cui sono contenute le attuali informazioni,

se ci sono, del profilo di default del terminale. L’utente esegue le

opportune operazioni (inserimenti, modifiche e cancellazioni)

6. Verifica della correttezza delle informazioni



8. Il sistema memorizza il nuovo profilo di default del terminale

Post Condition: l’utente definisce un profilo di default

Exception:


84

Requisiti non funzionali

Accessibilità

Tale requisito permette che in ogni momento l’utente possa inserire

modificare o cancellare le sue informazioni e i suoi sub-profile. Inoltre l’utente

deve in ogni momento poter modificare il suo Active sub-profile anche annullando

la decisione presa dal criterio di scelta automatica da lui precedentemente definito.

Un ulteriore aspetto dell’accessibilità riguarda il criterio con cui l’utente

accede al sistema. L’utente può accedere al sistema mediante il suo terminale

mobile o mediante il PC fisso.

Estendibilità

L’estendibilità come viene letto anche in 3GPP GUP è una caratteristica

fondamentale nella gestione di User profile e Service profile. Tale requisito

richiede che sia possibile l’inserimento futuro di nuovi dati che verranno definiti

nello User profile e di nuovi servizi che verranno creati nel Service profile in

modo che possano usufruire dei metodi di gestione già esistenti. Tale requisito

richiede un linguaggio di descrizione dei dati che permetta l’inserimento semplice

di cambiamenti ed estensioni dei dati.

Gestione distribuita

Le informazioni che entrano a far parte dello User profile sono contenute

in diverse entità come i nodi della rete, il terminale e la USIM dell’utente. Il

sistema software che verrà realizzato deve permettere la condivisione di

informazioni gestite e memorizzate in diverse entità. Quindi il sistema software

deve gestire informazioni relative all’utente memorizzate in modo distribuito

85

evitando per quanto possibile la duplicazioni dei dati. La replicazione si può

prevedere invece per aumentare l’efficienza e la disponibilità dei dati quindi per

aumentare la capacità di safety del sistema.

Privacy

Il sistema software che viene realizzato permette la condivisione di

informazioni gestite e memorizzate da diverse entità verso altre entità inoltre tale

sistema gestisce diverse informazioni personali dell’utente. Per questi motivi la

privacy dei dati diviene un requisito fondamentale del sistema. La visione delle

informazioni è quindi limitata a politiche di accesso.

Esecuzione concorrente

Le richieste di utenti e servizi devono essere eseguite in modo concorrente. Il

sistema deve essere quindi basato su thread, ciò vuol dire che una determinata

richiesta non deve essere bloccante rispetto ad altre. Si devono quindi poter

gestire richieste in parallelo con l’individuazione di operazioni critiche da

serializzare.

Il linguaggio UML

Tale sezione ha lo scopo di presentare brevemente il linguaggio che è stato

utilizzato in fase di modellizzazione del sistema. Naturalmente verranno posti in

evidenza solamente gli aspetti semantici più importanti senza entrare in profondità

nella descrizione degli aspetti sintattici del linguaggio UML. Una trattazione più

dettagliata può essere trovata in [Fow].

86

Introduzione

L’Unified Modelling Language (UML) è il seguito di tutta una serie di

metodi per l’analisi e la progettazione orientata agli oggetti. L’UML è un

linguaggio per la definizione di modelli e non un metodo; i metodi consistono

essenzialmente in un linguaggio di modellizzazione ed in un processo. Il

linguaggio per la costruzione del modello è la notazione1 che il metodo usa per

esprimere il design. Il processo è invece l’insieme dei passi che devono essere

compiuti per fare il progetto.

Il linguaggio UML attualmente definisce la notazione da utilizzare per il

design ed il metamodello da costruire. La notazione proposta è grafica e

costituisce la sintassi del linguaggio.

Il primo passo da fare per giungere alla costruzione di un modello è la

comprensione del dominio applicativo. Una delle tecniche disponibili per

raggiungere efficacemente tale scopo è quella che prevede l’utilizzo di use case.

Un use case è la descrizione di un aspetto di ciò che il sistema deve fare. La

somma di tutti gli use cases fornisce una rappresentazione di come deve apparire

il sistema esternamente. Una buona collezione di use case è quindi centrale per

capire ciò che in realtà l’utente desidera. Ogni use case ha una serie di proprietà

che si possono cosi riassumere:

Uno use case rappresenta l’identificazione di funzioni visibili dall’utente ⇒

⇒

⇒

Uno use case può essere semplice o complesso

Uno use case raggiunge un bisogno specifico dell’utente

Da quanto detto si capisce che per identificare gli use case l’unico modo è quello

di parlare con quelle persone che saranno gli utenti tipici del sistema cercando di

capire le loro richieste.

Una distinzione importante a tal proposito deve essere effettuata tra ciò

che si intende per user goals e ciò che invece si intende per system interactions.

Per system interactions si intende l’insieme di tutte le modalità attraverso cui

l’utente può comunicare con il sistema; gli user goals consistono invece in ciò che

l’utente vuole fare con il sistema sviluppato.

87

Il linguaggio UML prevede la possibilità di realizzare i cosiddetti use case

diagrams molto utili per la costruzione degli use cases. In tali diagrammi si

definisce actor il ruolo che l’utente ha rispetto al sistema. Sono gli actors le risorse

principali di use cases; un singolo actor può eseguire più use cases e a sua volta un

singolo use case può essere eseguito da più actors. Un actor non coincide

necessariamente con una persona fisica ma può benissimo rappresentare anche un

altro sistema informatico che richiede lo svolgimento di funzionalità da parte del

sistema che si sta correntemente modellizzando.

Gli use cases rappresentano quindi le funzionalità richieste esternamente.

Ci può essere anche la possibilità che un use case non si riferisca ad un ben

definito actor. Una buona risorsa per identificare gli use cases sono gli eventi

esterni. Inoltre nel linguaggio UML possono essere specificati use cases che

estendono e che utilizzano altri use cases. Si ha ‘estensione’ quando uno use case

descrive una variazione ad un normale comportamento; si ha ‘utilizzo’ quando un

use case fa parte di molti altri use cases.

Class Diagram

La tecnica dei class diagrams è veramente fondamentale in una metodologia ad

oggetti. Un class diagram descrive sostanzialmente il tipo di oggetti presenti nel

sistema ed i vari tipi di relazioni statiche che esistono tra di essi. Si possono

identificare due tipi principali di relazioni statiche:

Association: rappresentano relazioni tra istanze di classi. Ogni association

può avere due ruoli, un ruolo per ogni direzione dell’association; i ruoli

dell’associazione sono opzionali.

Subtypes: fanno riferimento sostanzialmente al concetto di gerarchie di

generalizzazioni. I class diagrams inoltre mostrano gli attributi e le operazioni

offerte da una classe nonchè le regole di visibilità che si vogliono stabilire per

gli oggetti istanze di una determinata classe. Ci sono tre prospettive in base

alle quali un class diagram può essere costruito:

Conceptual: in base a tale prospettiva vengono rappresentati i

concetti che caratterizzano il dominio applicativo;

88

Specification: tale logica guarda al software ma pi`u precisamente

all’interfaccia che deve essere offerta e non all’implementazione;

Implementation: in base a tale prospettiva si fa riferimento

all’implementazione vera e propria delle varie classi.

Integrati con i class diagrams si possono poi utilizzare i CRC-cards (Class-

Responsibility-Collaboration). I CRC-cards consentono di definire con chiarezza

ciò che ogni classe deve fare ed, eventualmente, con quali altre classi deve

collaborare. Tra le nozioni che stanno alla base dei class diagram ci sono poi

quelle di generalizzazione e di costraint rules che indicano rispettivamente le

gerarchie tra le varie classi ed i vincoli che devono rispettare gli oggetti che

istanziano le classi. In UML i vincoli vengono rappresentati tra le parentesi graffe.

I class diagrams sono la spina dorsale di una metodologia ad oggetti e

quindi devono essere usati sempre quando se ne sente la necessità in fase di

costruzione del modello.

Interaction Diagram

Gli interaction diagrams sono modelli che descrivono come gruppi di

oggetti collaborano in una serie di comportamenti. Tipicamente un interaction

diagram definisce il comportamento di un singolo use case evidenziando quali

oggetti vengono coinvolti e quali messaggi vengono scambiati. Ci possono essere

due tipi di interaction diagrams detti rispettivamente sequence diagrams e

collaboration diagrams. Una delle caratteristiche principali degli interaction

diagrams è la loro semplicità. Gli interaction diagrams sono quindi utili al fine di

presentare il comportamento di diversi oggetti all’interno di un singolo use case

ma non servono a definire con esattezza i comportamenti precisi di ogni oggetto.

Package Diagram

Uno dei problemi più difficili da risolvere nello sviluppo di un grosso

sistema è come poterlo spezzare in una serie di più piccoli e semplici sistemi. In

89

UML, l’idea è quella di raggruppare le classi assieme in un’unità di più alto

livello; questo meccanismo di raggruppamento è chiamato package. Un package

diagram quindi `e una struttura che mostra i gruppi di classi e le dipendenze tra i

gruppi. I package diagrams sono uno strumento molto utile soprattutto in progetti

molto complessi ed articolati.

State diagram

Gli state diagrams sono delle tecniche molto utilizzate per descrivere il

comportamento dei singoli oggetti. Essi descrivono tutti i possibili stati in cui si

può trovare un determinato oggetto. Ad ogni stato possono essere associate delle

attività ed ad ogni transazione tra stati può essere associata una regola ECA

(Event-Condition-Action). Le azioni hanno carattere istantaneo e quindi non sono

interrompibili mentre le attività possono essere interrotte nel tempo. Nel momento

in cui uno stesso oggetto presenta un insieme di comportamenti indipendenti è

possibile utilizzare dei diagrammi di stato concorrenti, che consentono cioè di

definire contemporaneamente più stati in cui si può trovare un oggetto.

Activity Diagram

Questi diagrammi sono particolarmente utili in connessione con i flussi di

lavoro e descrivono il comportamento che hanno molti processi paralleli. Il cuore

di tali diagrammi `e rappresentato dal concetto di attività che rappresenta un

compito che deve essere fatto da un essere umano o dal calcolatore. Ogni attività

può essere seguita da un’altra attività in una semplice sequenza.

Gli activity diagrams possono gestire anche dei processi paralleli ed in

questo si differenziano dai più semplici flow-chart; tali diagrammi sono inoltre

utili anche per rappresentare programmi concorrenti.

90

Deployment Diagram

Un deployment diagram mostra le relazioni fisiche tra componenti

hardware e software di un sistema. Tali diagrammi sono molto utili per descrivere

come gli oggetti si muovono in un sistema distribuito. Le connections tra i nodi

mostrano i cammini di comunicazione attraverso i quali il sistema interagisce. I

components rappresentano invece moduli fisici e codice; praticamente questi

corrispondono ai packages di un package diagram.

91

5. Tecnologie di sviluppo

Questo capitolo ha lo scopo di descrivere, in modo sintetico, le tecnologie

che sono state scelte nella fase progettuale. La prima parte del capitolo descrive le

tecnologie scelte per il progetto delle funzionalità interne del sistema. In

particolare si è scelto di puntare sulle potenzialità offerte da Java relativamente

all’invocazione dei metodi remoti e della costruzione di pagine dinamiche. Il

linguaggio Java mette infatti a disposizione la tecnologia RMI (Remote Method

Invocation) che permette di utilizzare interfacce remote. Tale meccanismo viene

utilizzato anche per offrire interfacce ai servizi utili per ottenere informazioni

generali dell’utente. I Java Servlet offrono invece le funzionalità per la

costruzione di pagine dinamiche da presentare all’utente a fronte di una specifica

richiesta. Successivamente viene introdotto il linguaggio XML utilizzato per la

descrizione dei dati come suggerito anche negli standard 3GPP, in particolare nel

concetto di Generic User Profile. L’ultima parte del capitolo è dedicato alla

descrizione dei protocolli utilizzati per la comunicazione con le entità esterne al

sistema, quindi Context Server e utenti. Il sistema di gestione del profilo

comunica con il Context Server utilizzando l’estensione proposta da SIMPLE del

protocollo di segnalazione SIP. La comunicazione tra l’utente ed il sistema di

gestione del profilo avviene invece utilizzando il protocollo HTTP. I servizi

invece invocano metodi remoti per ottenere informazioni relative all’utente.

92

Linguaggio JAVA

Il linguaggio Java è nato da poco tempo ed ha l’obiettivo di creare dei

programmi che possono essere eseguiti e distribuiti lungo la rete. Java

sostanzialmente rappresenta un radicale cambiamento del Web arricchendo

profondamente l’aspetto di interazione con l’utente che i sistemi

software precedenti hanno sempre trascurato [Swadley96]. Il linguaggio è

stato sviluppato dalla Sun Microsystems ed è di tipo object oriented, quindi

presenta molte somiglianze con il C++; la più grande differenza consiste nel fatto

che Java non supporta il meccanismo dei puntatori [Java99] e questo lo rende

completamente platform independent e più sicuro. Tutte queste caratteristiche

permettono di realizzare il concetto di Macchina Virtuale Java. La tecnologia Java

non è però limitata solamente al mondo del server Web; essa ad esempio può

essere utilizzata anche per lo sviluppo di sistemi embedded.

Nella fase progettuale è stato previsto l’utilizzo, in particolare, di due

strumenti offerti da Java: il meccanismo RMI (Remote Method Invocation) e le

servlet Java per la creazione delle pagine dinamiche.

Remote Method Invocation

Il meccanismo RMI (Remote Method Invocation), descritto in [rmi] e

[Ris], offre al programmatore la possibilità di creare applicazioni Java distribuite,

che richiamano metodi presenti su altre macchine presenti sulla rete. In tale logica

i metodi di oggetti remoti possono essere richiamati da un’altra macchina Java

virtuale, possibilmente situata su di un’altro host. Un programma Java può

effettuare una chiamata ad un oggetto remoto solo quando ha ottenuto un

riferimento all’oggetto remoto stesso; questo riferimento può essere identificato in

due modi:

93

utilizzando l’apposito metodo Naming.lookup(AnnotationServer) messo a

disposizione dal servizio RMI

⇒

ricevendo il riferimento come un argomento o come un valore di ritorno ⇒

⇒

⇒

⇒

Con tale meccanismo un client può chiamare un oggetto remoto situato su

di un Server, ed il Server può anche essere un client di un altro oggetto remoto.

RMI utilizza il concetto di Object Serialization al fine di ordinare i parametri da

trasmettere senza perdere informazioni riguardanti il loro tipo e supportando il

concetto di polimorfismo tipico di un paradigma object-oriented.

Principi alla base del meccanismo RMI

E’ intuitivo il fatto che il meccanismo RMI può fallire per numerosi motivi

legati essenzialmente ai problemi di comunicazione attraverso la rete ed ai

problemi che si possono presentare sul Server. Per creare un oggetto remoto

occorre prima definire un’interfaccia che verrà implementata da tale oggetto. Tale

interfaccia deve possedere una serie di caratteristiche:

deve essere Public in quanto un qualsiasi Client deve aver la possibilità di

richiamare l’oggetto remoto che implementa l’interfaccia;

deve estendere l’interfaccia java.rmi.remote;

ogni metodo di tale interfaccia deve dichiarare le eccezioni

java.rmi.RemoteException nell’apposita clausola.

I sistemi distribuiti richiedono che le computazioni eseguite in differenti

spazi di indirizzamento delle variabili, potenzialmente su differenti hosts, siano in

grado di comunicare tra di loro.Come meccanismo di base a supporto della

comunicazione il linguaggio Java fornisce i cosiddetti sockets, i quali sono

flessibili e rappresentano un ottimo strumento per comunicazioni a carattere

generale.

Il sistema RMI-Java segue fondamentalmente il paradigma Client/Server;

in tale sistema distribuito un oggetto remoto possiede dei metodi che possono

essere invocati da un’altra macchina virtuale, posta potenzialmente su di un altro

host. Remote Method Invocation è essenzialmente l’azione attraverso cui si

94

invoca un metodo di un’interfaccia remota implementata da un oggetto remoto.

Estremamente importante è il fatto che l’invocazione di un metodo remoto ha la

stessa sintassi dell’invocazione di un metodo relativo ad un oggetto locale. Il

modello ad oggetti distribuiti differisce dal tradizionale modello ad oggetti nei

seguenti punti fondamentali:

i Clients degli oggetti remoti interagiscono con interfacce remote e non

con le classi che implementano tali interfacce;

⇒

⇒

⇒

⇒

⇒

⇒

gli argomenti non remoti sono passati per copia e non per indirizzo;

un oggetto remoto è passato per indirizzo;

Architettura del sistema RMI

Il sistema RMI `e costituito essenzialmente da tre strati:

stub-skeleton layer

remote reference layer

transport layer

Il legame tra ogni strato è definito da una specifica interfaccia e da un

determinato protocollo; per tale ragione ogni strato è indipendente dal successivo

e può essere rimpiazzato da una qualsivoglia implementazione senza influenzare

gli altri strati del sistema. La Figura 0-1 mostra in generale l’architettura e le

relazioni tra gli strati che la costituiscono. Un’invocazione di metodo remoto

proveniente da un Client e fatta ad un Server remoto attraversa dall’alto verso il

basso gli strati dell’architettura RMI sul lato Client e quindi risale gli strati sul lato

Server8. Un Client per poter invocare un metodo remoto deve ottenere un

riferimento all’oggetto remoto che non è altro che un riferimento alla procedura

Stub residente sul lato Client. Questa Stub è l’implementazione di un’interfaccia

dell’oggetto remoto ed effettua una chiamata che viene inoltrata attraverso gli

strati dell’architettura di Figura 0-1.

95

Figura 0-1: Architettura del sistema RMI

Il Remote Reference Layer ha la responsabilità principale di trasportare

fuori la semantica dell’invocazione. Il Transport Layer è invece responsabile di

tutti quegli aspetti relativi alla gestione della connessione tra macchine remote. Lo

Skeleton che risiede sul lato Server si occupa di effettuare delle chiamate alle

implementazioni degli oggetti remoti invocando il metodo in questione, ovvero il

metodo specificato dal Client. Questa è in breve la descrizione della tecnologia

utilizzata per consentire la comunicazione tra i sottosistemi che compongono il

sistema di gestione del profilo utente. Anche la fornitura di informazioni relative

all’utente verso tutti i servizi in generale è eseguita attraverso il meccanismo RMI.

Java Servlet

I servlet, come descritto in [Harms] sono usati per estendere le funzionalità

di un web server consentendo si realizzare pagine dinamiche. Attraverso le servlet

API un programmatore può accedere facilmente alle richieste (request) nel

protocollo HTTP che vengono fatte da un browser, e generare “response HTTP”

attraverso l’uso di oggetti Java, che forniscono molti metodi per manipolare

queste richieste. Le servlet sono usate tipicamente dove è necessario ottenere

informazioni in seguito alle richieste generate da un form HTML, spesso

96

interrogando una sorgente di dati. Sono anche utilizzate per controllare il flusso

della applicazione web, consentendo ad esempio di abilitare o disabilitare

l’accesso a certe risorse. Forse l’applicazione più comune realizzata attraverso

l’uso di servlet è quella di tenere traccia della sessione degli utenti, tipico esempio

è la realizzazione di un carrello in una applicazione di e-Commerce. I servlet sono

esempi di applicazioni server-side che risolvono i problemi di incompatibilià di

dati all’interno di browser alleggerendo il carico computazionale del lato client.

Infatti a differenza della programmazione client-side, l’approccio server-side

permette di svolgere tutte le elaborazioni associate alla visualizzazione di

informazioni in modo trasparente al client. Questo è un requisito fondamentale,

soprattutto quando si interagisce con utenti dotati di terminali con scarse capacità

elaborative come ad esempio può essere un PAD o un telefono wireless.

Per utilizzare i servlet all’interno di un web server, c’è bisogno di un

servlet container che permetta la comprensione del linguaggio Java Server Side.

Uno dei servlet container più diffusi è Tomcat [Tom]. Le richieste relative alle

servlet vengono consegnate al servlet container che provvederà a passare il

controllo ad una servlet.

Tutti i servlet hanno un ciclo vitale ben definito. Nascono quando viene

inoltrata la prima richiesta, successivamente gestiscono le richieste e terminano

con il verificarsi di eccezioni oppure quando terminano il oro compiti.

I servlet devono riconoscere tre metodi standard che sono init , service e

destroy altrimenti il servlet container non sarà in grado di gestirne il ciclo vitale.

Appena il servlet viene caricato, il servlet container invoca il metodo init() che

svolge le operazioni iniziali tra cui la lettura dei parametri. Al ricevimento di una

richiesta il servlet container invoca il metodo service e passa un oggetto contente

tutte le informazioni relative a tale richiesta. Quando il servlet container vuole

liberarsi della servlet viene invocato il metodo destroy(). In questa fase il servlet

cede lo spazio di memoria che aveva a disposizione e chiude eventuali

connessioni con i database.

Nella maggior parte dei casi, i servlet estendono la classe HTTPServlet che

contiene due metodi principali utili per passare le informazioni al server: il

metodo GET e il metodo POST. Le servlet, in base ai parametri passati in questi

97

metodi, eseguiranno le opportune operazioni e restituiranno una apposita pagina

Web.

Linguaggio XML

XML è l’acronimo di eXtensible Markup Language ed è stato realizzato e

standardizzato dal World Wide Web Consortium (W3C), nato come linguaggio di

descrizione è diventato a tutti gli effetti uno standard per lo scambio di dati

soprattutto su Internet, ma non solo. La potenza di XML sostanzialmente risiede

nella sua semplicità, è possibile infatti descrivere in modo molto chiaro e in un

formato che non lascia interpretazioni personali un insieme di dati assegnando

loro un significato univoco [Will]. Ciò lo rende ideale per lo scambio di qualsiasi

informazione indipendentemente dall’architettura hardware o dal sistema

operativo dei computer utilizzati.

Il linguaggio XML si basa su file di testo contenenti tag definiti nel file di

testo medesimo. Lo stesso vale anche per il linguaggio HTML (Hyper Text

Markup Language) con l’unica differenza che in quest’ultimo i tag sono

predefiniti dalla sintassi del linguaggio stesso.

Il linguaggio XML sta trovando una vasta applicazione nella

pubblicazione di pagine dinamiche in Server Web. Poiché tale linguaggio, da solo,

non offre le potenzialità per la visualizzazione di contenuti via web, si deve

utilizzare insieme il concetto di foglio di stile che sostanzialmente permette di

trasformare documenti XML in documenti che possano essere visualizzati sui

browser degli utenti. Nasce dunque l’esigenza di definire un nuovo standard che

prende il nome di XSL (eXtensible Stylesheet Language) che permette la

creazione di fogli di stile da associare a documenti XML per scopi di

visualizzazione. Uno strumento molto diffuso che consente il Web Publishing di

documenti XML, realizzato interamente in Java dall’Apache Software Fondation,

è Cocoon [Coo]. Tramite le librerie offerte da Cocoon, si possono pubblicare

documenti XML associandoli con fogli di stile. Si supponga di realizzare un

98

progetto che effettui un qualsiasi accesso ad un database e rappresenti il risultato

delle query in formato XML, a questo punto basta avere realizzato un file XSL

che contenga la presentazione della pagina e Cocoon pubblica il risultato della

trasformazione in un file visualizzabile sul browser. Il vantaggio è notevole in

quanto si è realizzato completamente la separazione tra la presentazione cioè

l’aspetto grafico della pagina, e il suo contenuto informativo.

Ad un documento XML si possono inoltre associare dei vincoli sulla

struttura e sul tipo dei dati che contiene. Ciò viene realizzato mediante l’utilizzo di

DTD (Document Type Definition) e XML Schema. Attraverso le DTD si può ad

esempio obbligare l’inserimento di uno specifico elemento o di un attributo

oppure definire che questo contenga solo dati di tipo carattere. Per la maggior

parte delle applicazioni tuttavia questi vincoli non sono sufficienti. Per esempio si

vorrebbe poter limitare il contenuto dell’elemento prezzo all’uso di dati decimali

con una precisione di due cifre.. Ed è in questi aspetti che le DTD falliscono. In

particolare le DTD non consentono la definizione di tipi di dato nel senso dei

comuni linguaggi di programmazione. Oltre a queste problematiche le DTD

presentano altre mancanze:

Non fornisce un supporto adeguato per la modularizzazione e il riuso degli

schemi di documento.

⇒

⇒

⇒

Non sono documenti XML ma seguono una sintassi diversa, ciò implica

che tutti gli strumenti software utilizzati per i documenti XML non

possono essere impiegati per creare, editare, effettuare il parsing o

l’interpretazione delle DTD.

Tutte le motivazioni esposte sulle carenze delle DTD hanno spinto allo

sviluppo di un nuovo metodo di definizione per gli schemi XML denominato

XML Schema pubblicato dal W3C.

XML Schema segue una sintassi XML ed introduce diversi tipi di dato

classificabili in due insiemi principali: tipi dato semplici e tipi di dato derivati

I tipi di dato primitivi predefiniti comprendono i tipi già noti nelle DTD

ma introducono anche nuovi tipi di dato sia per gli attributi che per gli

elementi. Alcuni di questi sono: string, boolean, float

99

.

I tipi di dato predefiniti di tipo derivato sono ottenuti dai tipi di dato

primitivi per ottenere soluzioni soddisfacenti in alcuni campi applicativi.

Esempi di questi tipi sono: language, Name, integer

⇒

⇒

⇒

Tra le funzionalità offerte dalla tecnica di descrizione XML Schema, vi è

la possibilità, da parte dell’utente, di definire proprie tipologie di dati allo scopo di

creare soluzioni personalizzate. I tipi di dato possono essere definiti in due diversi

modi:

Per restrizione ad un determinato pattern: si può limitare un tipo di dato ad

assumere i valori che contengono al loro interno uno specifico pattern.

I

contene

seguito

Per enu

CAPMi

postale

vincolo

100

<xsd:simpleType name=”e-mail”>

<xsd:restriction base=”xsd:string”>

<xsd:pattern value=”.*@.*”/>

</xsd:restriction>

</xsd:simpleType>

n questo modo si specifica che un indirizzo di tipo e-mail deve

re necessariamente il simbolo “@” e può essere preceduto e

da una qualsiasi stringa di caratteri

merazione: per esempio è possibile definire un tipo di dato

lano enumerando i possibili valori del codice di avviamento

di Milano. Si noti che una enumerazione si basa sempre sul

di un altro tipo di dato preesistente, in questo caso “string”

<xsd:simpleType name=”CAPMilano”>

<xsd:restriction base=”xsd:string”>

<xsd:enumeration value=”20129”/>



<!—e l’elenco continua…-->

</xsd:restriction>

</xsd:simpleType>

.

Ovviamente si devono poter definire anche tipi complessi. Si definiscono

come nell’esempio seguente:

<xsd:element name=”progetto”>

<xsd:complexType………>

</xsd:complexType>

</element>

Programmazione con XML

Le caratteristiche di estendibilità e interoperabilità espresse da documenti

XML fa nascere l’esigenza di interfacce che né consentano la gestione da parte di

applicazioni software. Vi sono due principali famiglie di interfacce per la gestione

di documenti XML:

Simple API for XML (SAX): E’ uno standard basato sugli eventi quindi le

interfacce che fornisce sono basate sulla scansione di un documento in

maniera sequenziale. Quando una unità sintattica viene riconosciuta il

parser informa il chiamante (callback) di questo evento. Il gestore del

⇒

101

documento che chiama il SAX e che viene informato di questi eventi può

decidere cosa fare: ignorare l’evento, modificare lo stato dell’applicazione,

o fermare il parsing.

DOM è una interfaccia di programmazione completa per documenti

HTML e XML. Utilizzando DOM i programmatori possono creare o

caricare documenti XML, navigare la loro struttura, e ricercare,

aggiungere, modificare, o cancellare elementi e contenuto. DOM è

progettato per essere usato con qualunque linguaggio di programmazione

lavorando però in modo completamente diverso da SAX. Quando DOM

legge un documento esso analizza la struttura completa del documento e

costruisce un albero di tutti i nodi del documento nella memoria. Il

controllo viene restituito al processo chiamante solo dopo aver elaborato

tutto il documento. L’applicazione può allora usare la API DOM per

navigare l’albero e ricercare ed estrarre contenuto, modificare i nodi,

cancellarli, o inserirne di nuovi. Il vantaggio del DOM è che l’intera

struttura del documento viene presentata all’applicazione chiamante, che

può dunque navigare avanti e indietro liberamente nei nodi del documento,

cosa impossibile con SAX.

⇒

Protocollo HTTP

Il protocollo HTTP (Hyper Text Transfer Protocol) fornisce il supporto per

una comunicazione leggera e veloce in un sistema informativo ipertestuale

[rfc1945], [rfc2068], [rfc2616].

In tale protocollo, l’applicativo del client, detto browser, invia delle

richieste al server che analizza la specifica richiesta in modo da determinare

l’azione relativa da compiere. Il protocollo HTTP è stateless, ciò vuol dire che il

server non conserva alcuna informazione riguardante le richieste precedenti dei

client.

102

Successivamente si presenta un esempio di richiesta HTTP.

Nella richi

permessi pe

GE

sul

⇒

⇒

⇒

⇒

⇒

HE

risp

doc

POS

cam

PUT

disa

DE

disa

Sub

Resource I

protocollo

l’header de

connection

connession

volta una c

User agent

Accept: tip

103

GET /somedir/page.html HTTP/1.1

Connection: close

User-agent: Mozilla/4.0

Accept: text/html, image/gif, image/jpeg

Accept-language:fr

esta viene specificato in primo luogo il metodo da utilizzare. I metodi

r effettuare le richieste sono i seguenti:

T: è il metodo più frequente ed è utilizzato per richiedere una risorsa

web

AD: è simile al metodo precedente ma in questo caso il server deve

ondere solo con gli header relativi senza restituire il corpo del

umento

T: è utilizzato per trasmettere dati da un client al server, ad esempio i

pi di un form ad una servlet o a programmi CGI

: permette di caricare un documento sul server, viene in genere

bilitata dai server per motivi di sicurezza.

LETE: Elimina un documento dal server, come la precedente viene

bilitata dai server per garantire la sicurezza

ito dopo il metodo della richiesta viene indicato l’URI (Uniform

dentifier) relativo al documento che si vuole ottenere dal server e il

utilizzato nella comunicazione. Dopo queste informazioni segue

lla richiesta che contiene le seguenti informazioni:

: indica il tipo di connessione (persistente, non persistente), Nella

e persistente possono essere fatte diverse richieste senza aprire ogni

onnessione diversa.

: indica il tipo di browser utilizzato dall’utente

o di oggetti che l’utente accetta

Accept-language: preferenza della lingua

La risposta del server che segue la richiesta del client ha la seguente

forma:

HTTP/1.1 200 OK

Connection: close

Date: Thu, 06 Aug 1998 12:00:15 GMT

Server: Apache/1.3.0 (Unix)

Last-Modified: Mon, 22 Jun 1998 …...

Content-Length: 6821

Content-Type: text/html

data data data data data ..

All’interno della risposta viene indicato se la richiesta è stata servita con

successo altrimenti viene specificato il messaggio di errore, inoltre vengono

indicate informazioni relative al server e al tipo di contenuto restituito.

Gestione delle sessioni e sicurezza

Come è stato visto precedentemente, il protocollo HTTP è stateless. Ciò

non permette di tenere traccia delle azioni compiute dall’utente oppure di

scambiare dati tra una pagina e l’altra ponendo seri limiti alla realizzazione di

applicazioni web complesse di tipo dinamico. Quando, all’interno di un sito web,

si richiedono informazioni riservate, il server deve essere in grado di verificare

104

l’identità dell’utente attraverso uno scambio di credenziali (ad esempio username

e password). Tuttavia a causa del protocollo stateless ad ogni singola richiesta

sarebbe necessario rinviare le proprie credenziali. Questo non rappresenta un

problema nei casi di una normale navigazione web in cui vengono richieste pagine

statiche ma diviene un ostacolo non trascurabile se un utente, interagendo con il

server, ha la necessità di effettuare un numero sufficientemente elevato di

richieste per completare un’operazione complessa in cui viene fatto uso di pagine

dinamiche (si pensi ad esempio a siti per il commercio elettronico in cui si deve

gestire un carrello degli ordini).

Un metodo che permette di superare questo ostacolo è l’introduzione del

concetto di sessione nel quale il server è in grado di identificare una serie di

richieste eseguite da un client associandole ad una specifica sessione di lavoro.

Alla sessione vengono associate specifiche informazioni che possono essere

utilizzate per servire le richieste e quindi inviare le specifiche risposte.

Oltre al discorso di sessione, un sito web che tratta dati riservati deve

utilizzare tecniche che garantiscono la sicurezza quindi assicurare che solo il

mittente ed il destinatario dei messaggi né comprendano il contenuto.

Il protocollo SSL (Socket Security Layer) fornisce le funzionalità

necessarie per risolvere i problemi di gestione delle sessioni e di sicurezza dei

dati. Infatti SSL è una tecnologia di cifratura basata sul protocollo TCP/IP.

Sostanzialmente questa tecnologia è quella utilizzata nel protocollo

HTTPS. SSL permette ai server che dispongono di questo protocollo di

autenticare i client e di mantenere una connessione cifrata con essi. Nel momento

di creazione della connessione viene generato un “session id” univoco che viene

utilizzato per effettuare la decifratura dei messaggi.

Nel caso di sviluppo di applicazioni tramite l’uso di servlet, è il web

container che si occupa di gestire le sessioni e tramite le API (Application

Program Interface) di JAVA Servlet si possono recuperare tutte le informazioni

associate alla sessione compreso il session id.

105

Protocollo SIP

Il SIP (Session Initiation Protocol) è un protocollo definito allo scopo di

offrire servizi di comunicazione multimediali su rete a pacchetto ed è. nato in

ambito IETF nel Working Group Multiparty Multimedia Session Control.

Descritto in [rfc2543]. In SIP si riflette pienamente la filosofia Internet; esso è:

semplice: l’intera segnalazione necessaria è composta da una serie di

messaggi testuali che contengono, dopo un header, un body contenente

tutte le informazioni necessarie;

⇒

⇒

⇒

⇒

⇒

terminal-based: cioè il terminale di utente deve avere abbastanza

intelligenza da gestire un colloquio di segnalazione per instaurare una

chiamata.

flessibile: l’utilizzo di terminali più evoluti e il protocollo gestibile

attraverso messaggi testuali ne permette l’adattamento alle diverse

situazioni che possono incontrarsi.

SIP è un protocollo client-server, cioè ogni transazione viene originata da

un nodo della rete in grado di agire da client ed è diretta ad un altro con proprietà

di server. In particolare le principali entità funzionali sono:

Gli User Agent: processi che risiedono sui terminali degli utenti e che a

loro volta si dividono in:

UAC (User Agent Client), invia la richiesta di connessione SIP

UAS (User Agent Server), risponde alla richiesta di connessione

I Network Server: sono suddivisi in:

Proxy Server: dopo aver interpellato un Database e deciso quale sia il

server a cui è registrato il chiamato, inoltrano la richiesta di connessione al

server successivo;

Redirect Server: simili al Proxy Server nella prima fase, ma invece di far

proseguire i messaggi di instaurazione, rispondono all’agent con

l’indirizzo del successivo server da contattare;

106

Location Server: contiene l’attuale posizione degli utenti (ottenuta

mediante aggiornamenti da parte degli utenti stessi) ed è interpellato sia

dal Proxy Server sia dal Redirect Server.

⇒

Concettualmente è molto simile a quanto avviene oggi in internet con il

DNS. Il metodo con cui avviene questa richiesta esula dagli scopi del SIP. Se ci

sono molti indirizzi associati allo stesso alias, il proxy può iniziare una ricerca

parallela e concludere la transazione con il primo indirizzo che dà una risposta

positiva. Nel caso del redirect server, invece, la lista di indirizzi viene restituita al

client.

I proxy server SIP, quindi, cooperano con altri elementi, definiti location

server, che forniscono supporto al mantenimento dei dati di registrazione degli

alias di un indirizzo: se un utente vuole essere raggiungibile anche mediante un

altro indirizzo SIP, lo può fare presso un nodo che svolga le funzioni di registrar

SIP, il quale si occuperà di comunicare ad un location server (che mantiene un

database di tutti gli alias) l’associazione tra l’alias e l’indirizzo corrente

mediante un protocollo non specificato nello standard (e.g. LDAP, protocollo

utilizzato per accesso a directory server).

Quando un server (per es. con funzionalità anche di registrar) riceve una

richiesta di comunicazione (invitation), contatta il location server per risolvere

l’indirizzamento. Una volta recuperato l’indirizzo dell’attuale locazione

dell’utente vengono offerte due possibilità al server:

aprire la stessa transazione verso l’indirizzo appena individuato,

comportandosi quindi da proxy server;

⇒

⇒ inviare uno speciale messaggio SIP al client che l’ha contattato,

informandolo del nuovo indirizzo in modo che esso lo possa contattare. Un

nodo che usi questa modalità viene definito redirect server.

Due possibili scenari di utilizzo di SIP per l’instaurazione di una sessione

(non si può più parlare di chiamata in senso stretto), vengono presentati nella

figura successiva, in cui vengono mostrate anche le principali entità funzionali.

107

Dalla Figura 0-2 si può notare come il flusso di chiamata base sia particolarmente

semplice, in quanto sono sufficienti tre messaggi:

Figura 0-2: Esempio di due tipici scenari SIP

INVITE: lo usa un client per invitare un server a partecipare ad una

sessione di comunicazione, in cui vengono fornite le caratteristiche (es.

codifica utilizzata nel caso voce);

⇒

⇒

⇒

OK: conferma da parte del server chiamato di voler partecipare alla

comunicazione e informazione sulle proprie caratteristiche;

ACK: conferma da parte del chiamante della ricezione dell’OK del

chiamato.

In completa analogia con quanto avviene con HTTP, i messaggi impiegati

durante una transazione SIP possono essere classificati in richieste (request) e

risposte (response). Le richieste, chiamate anche “metodi”, vengono

generalmente inviate da User Agent e Proxy Server, e sono:

INVITE: utilizzato per richiedere una connessione; con questo metodo

vengono anche trasportate le caratteristiche della comunicazione come ad esempio

la porta oppure il tipo di codifica da utilizzare. È possibile cambiare questi

parametri anche durante la comunicazione inviando un nuovo messaggio di

INVITE;

108

ACK: utilizzato per accettare la comunicazione;

OPTIONS: utilizzato per ottenere informazioni sulle capacità del server,

in particolare quali metodi può supportare. Questo messaggio è soprattutto utile

per mantenere la compatibilità con le versioni precedenti di SIP;

REGISTER: utilizzato per informare il server che l’utente ha cambiato

indirizzo, molto utile per supportare la mobilità dell’utente; ovviamente questo

tipo di informazione deve essere fornita dall’utente stesso;

BYE: (inviato/ricevuto dal client) per concludere una comunicazione;

CANCEL: (inviato dal Proxy server) termina la ricerca dell’utente: quando

un server cerca un utente può dover tentare ai diversi indirizzi che l’utente ha

fornito con il metodo REGISTER; quando lo raggiunge le altre richieste devono

essere cancellate utilizzando il presente metodo;

INFO: (inviato/ricevuto dal client) utilizzato per la segnalazione a

sessione già aperta. Questo messaggio è stato proposto, in una revisione del

protocollo , al fine di fornire la possibilità di trasmettere messaggi di segnalazione

anche nel corso di una sessione già aperta.

Il protocollo SIP riconosce URL in modo della forma:

sip:userid@host[:port].

Un esempio di indirizzo SIP è:

sip: [email protected] (user su PC)

Il protocollo SIP può essere trasportato sia su UDP sia su TCP. Il formato

dei messaggi di SIP e le procedure sono indipendenti dal protocollo di trasporto

utilizzato.

109

6. Progetto dello User Profile Manager

In questo capitolo si descrive l’architettura dello User Profile Manager

(sistema di gestione del profilo utente, UPM) introducendo i sottosistemi che lo

compongono e i protocolli utilizzati per interagire con le entità esterne. Il capitolo

inizia con la descrizione della struttura proposta per il Generic User Profile a

fronte delle estensioni individuate nel capitolo 3. Successivamente viene descritto

lo scenario di rete che viene preso come riferimento. L’ultima parte del capitolo è

dedicata alla descrizione del processo di personalizzazione proposto.

Struttura del Generic User Profile

Come visto in [3GPPTS23.240], i dati possono essere logicamente

classificati in base a diversi criteri dipendenti dall’aspetto che si vuole far risaltare

e dall’obiettivo del sistema software. Poiché in ogni fase del processo di

personalizzazione si accede alle informazioni in base all’argomento (es. user

preferences) si è deciso di organizzare i dati dello User Profile secondo il criterio

di classificazione “Information Characteristics”. Lo User Profile che viene

proposto per soddisfare i requisiti identificati nel capitolo 4 presenta la seguente

struttura logica:

110

Basic Profile ⇒

Service Profile ⇒

⇒

⇒

⇒

Context profile

Alcune informazioni non vengono tenute in considerazione nel profilo

utente proposto, in linea con le scelte viste in 3GPP GUP. Tali informazioni sono:

Run Time Data: sono i dati creati durante l’inizio della sessione,

l'esecuzione di una chiamata o di un'applicazione

Historic/Statistic: informazioni sul comportamento dell'utente

La struttura logica dello User Profile è la seguente:

Figura 0-1: Struttura proposta per il GUP

Nell’appendice A vengono inseriti gli XML Schema individuati per i

component del profilo. Successivamente vengono descritte tutte le informazioni

presenti all’interno di ogni component.

111

Basic Profile

Il Basic Profile contiene informazioni di carattere generale relative

all’utente ed è suddiviso in due sottoinsiemi:

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

General Information

User Preferences

General Information

Qui sono contenute alcune informazioni generali relative all’utente .

Queste informazioni possono essere logicamente divise in cinque sottogruppi:

1. General User Information

Name: nome dell’utente

Address: indirizzo dell'utente

Age: età dell’utente

Sex: sesso dell’utente

2. Logical Identifiers

MSISDN: numero telefonico dell’utente

SIP URL: identificativo dell'utente per i servizi IMS (IP

Multimedia Subsystem) come ad esempio instant messaging.

e-mail address: indirizzo di posta elettronica dell’utente

Presence URL: identificativo dell’utente all’interno del servizio di

presenza/contesto

Personal Number: alias dell'utente del tipo user@domain

Privacy User Identity: SIP URL assegnata dall’operatore per la

registrazione dell’utente

3. General Subscriber Information

Name: nome della persona fisica o della societa' a cui viene

addebitata la fatturazione

BillingInfo: è il tipo di rapporto stabilito con l’operatore, ad

esempio contratto o carta prepagata

112

Level: indica il livello del contratto quindi (es: Bronze, Silver o

Gold) che permette di decidere quali component l’utente può

gestire

⇒

Date of expire: è la data in cui termina il rapporto tra operatore e

utente

⇒

⇒

⇒

⇒

⇒

⇒

4. Authentication data

UserID: è l’identificativo univoco dell’utente, può corrispondere

all’MSISDN oppure al SIP URL

Password: è la password di accesso al sistema di gestione del

profilo utente

5. Operator Access List: sono le access list definite dall’operatore che

esprimono i permessi per la gestione delle informazioni contenute nel

profilo. L’operatore mediante tali access list può limitare l’accesso alle

informazioni di profilo da parte di utenti. Per ogni richiedente è presente

una access list che indica a quali component si può accedere e il tipo di

operazione consentita.

User Preferences

Nelle User Preferences compaiono le informazioni sulle preferenze

statiche dell’utente come lingua e interessi che si rivelano molto utili nel caso in

cui un servizio sottoscritto non ha ancora un service profile per un utente. Tale

servizio utilizzerà le user preferences contenute nello User Profile per fornire

almeno un primo livello di personalizzazione.

La lista di preferenze che viene considerata nel presente lavoro è la seguente:

Language: è la lingua preferita per l’utente, si può indicare un unico

valore tra quelli proposti.

Hobbies: indicano gli interessi dell’utente. L’utente può indicare uno

o piu valori per questa voce scegliendo tra quelli proposti

Sports: sono gli sport praticati o quelli a cui l’utente è interessato.

L’utente può indicare uno o piu valori per questa voce scegliendo tra

quelli proposti

113

Preferred content/media types (MIME types): sono i tipi di

contenuti preferiti dall’utente come ad esempio testo e immagini.

L’utente può indicare uno o più valori tra quelli proposti

⇒

Push Interest: permette all'utente di indicare se e' disponibile o

meno a ricevere contenuti di tipo push. Qualora l'utente fosse

disponibile, e' comunque necessaria una sottoscrizione esplicita al

servizio per concordarne i contenuti.

⇒

⇒

⇒

Accept Color: indica la preferenza dell’utente a ricevere contenuti a

colori o in bianco e nero

Streaming Interest: indica la preferenza dell’utente a ricevere

contenuti in modalità streaming

Service Profile

Per ogni servizio offerto dall’operatore o da HE-VASP, l’utente può

definire un Service Profile contenente le sue preferenze per quel servizio. Il

Service Profile rappresenta un component del profilo dell’utente. L’utente che si

registra al servizio può definire insiemi di preferenze diverse che costituiscono le

istanze del Service Profile. L’utente può successivamente associare le istanze a

diversi sub profile con l’unico vincolo che un sub profile contenga una sola

istanza del Service Profile. Ad ogni istanza viene associato un flag che indica se è

stata attivata o meno dall’utente cioè se l’istanza è presente nell’Active sub-

profile. In questo modo il Service Provider può determinare leggendo i flag se

l’utente ha attivato il servizio ed in tal caso quale delle possibili istanze. La

condizione nella quale nessuna delle istanze è attiva indica che l’utente non ha

attivato il servizio.

Le informazioni contenute in un Service Profile sono specifiche per ogni

servizio. I Service Profile vengono descritti quando possibile attraverso schemi

standard esistenti (es XML schema di MPEG-7 per servizi che inviano contenuti

multimediali).

114

Context Profile

Visto che lo User Profile proposto dovrà fornire supporto alla

personalizzazione si devono integrare le informazioni appena viste con

informazioni dipendenti dal contesto in cui si trova l’utente. Tali informazioni

presentano la caratteristica di dinamicità quindi sono soggette a cambiamenti

molto frequenti e sono logicamente contenute nella parte di User Profile

denominata Context Profile. Il Context Profile viene suddiviso in:

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

Capabilities Description

Context Information

Capabilities description

Le Capabilities Description includono l’insieme delle informazioni che

descrivono l’utente in funzione del terminale che utilizza e della rete che lo ospita.

Tali informazioni sono organizzate mediante una struttura CC/PP RDF e fornite

dall’utente nel modo descritto in 2.4.2.1. Le capabilities sono espresse mediante

attributi contenuti in components. I components presenti in UAProf sono i

seguenti:

Hardware Platform: descrive l’hardware del terminale

Software Platform: descrive il sistema operativo e le sue

caratteristiche

Browser UA: descrive il browser

Network Characteristics: sono le informazioni relative alla rete

quindi bearer information e possono caratterizzare la fruizione di

un servizio in termini di bandwidth e accessibilità

WAP Characteristics: descrive le WAP capabilities del dispositivo

ad esempio fornisce una descrizione del WML browser

Push Characteristics: descrive le informazioni utili in un servizio

push come il MIME-type supportato oppure la taglia massima di

un messaggio

MMS Characteristics: descrive le caratteristiche per il supporto del

multimedia messaging service

115

Per non appesantire la descrizione del progetto, la lista completa delle capabilities

di un terminale individuate all’interno di UAProf viene inserita nell’appendice B.

Per ulteriori informazioni sul profilo del terminale descritto da UAProf si possono

prendere in considerazione [UAProf] e [MMS] Allo scopo di utilizzare il profilo

del terminale UAProf, l’utente deve inserire il modello del suo terminale. Il

modello, insieme all’indirizzo dell’UAProf repository, sarà fornito ai servizi che

lo utilizzeranno come chiave d’accesso a tale repository. Il sistema interroga

l’UAProf repository per verificare se è presente la descrizione del modello. Nel

caso in cui il terminale non supporti UAProf, viene richiesto all’utente

l’inserimento delle capabilities del suo terminale. Tali informazioni rappresentano

un sottoinsieme di quelle individuate in UAProf poiché l’utente non può e non

vuole conoscere dettagli troppo tecnici del suo terminale ed inoltre l’utente non ha

l’obbligo di indicare il valore per tutti i dati richiesti. L’inserimento di tali

informazioni è quindi opzionale.

L’insieme delle informazioni che l’utente può inserire nel caso il suo

terminale non supporti UAProf è il seguente:

Hardware Platform:

ColorCapable. Indica se il display del terminale supporta i colori.

L’utente può inserire per questo parametro un valore booleano

(Yes/No)

⇒

⇒

⇒

⇒

ImageCapable. Indica se il display del terminale supporta la

visualizzazione di immagini. L’utente può inserire per questo

parametro un valore booleano (Yes/No)

ScreenSize. Indica le dimensioni dello schermo del terminale in

unità di pixel. Per questa voce, l’utente può scegliere tra un insieme

di valori ( es. "160x160","640x480")

SoundOutputCapable. Indica se il terminale supporta l’emissione

di suoni. L’utente può inserire per questo parametro un valore

booleano (Yes/No)

116

TextInputCapable. Indica se il terminale supporta l’introduzione di

testo. L’utente può inserire per questo parametro un valore booleano

(Yes/No)

⇒

VoiceInputCapable. Indica se il terminale supporta l’introduzione

di comandi vocali. L’utente può inserire per questo parametro un

valore booleano (Yes/No)

⇒

⇒

⇒

⇒

⇒

⇒

Software Platform:

JavaEnabled. Indica se il terminale ha a disposizione una Java

Virtual Machine (JVM). L’utente può inserire per questo parametro

un valore booleano (Yes/No)

OSName. Indica il nome del sistema operativo presente nel

terminale. L’utente può scegliere tra un insieme di valori per questo

parametro (es. "Mac OS", "Windows NT")

Browser UA:

L'utente può indicare il tipo e la versione dei browser presenti sul

terminale. Ogni elemento della lista è costituito dai seguenti attributi:

BrowserName: Indica il nome del browser presente nel terminale.

L’utente può scegliere tra un insieme di valori per questo parametro

(es. "Mozilla", "MSIE")

BrowserVersion. Indica la versione del browser. L’utente inserisce

questa informazione secondo la sintassi usata per le versioni del

software ( "es 1.0")

WAP Characteristics:

WapVersion. Indica la versione del protocollo WAP supportata.

L’utente inserisce questa informazione secondo la sintassi usata per

le versioni del software ( "es 1.0")

PUSH Characteristics:

117

Push-Accept. E’ la lista dei tipi di contenuto che il dispositivo

supporta per il push. L’utente può definire i tipi scegliendo tra

diverse voci (es. "text/html","text/plain","image/gif")

⇒

MMS Characteristics:

MmsVersion. Indica la versione supportata dall’MMS client.

L’informazione è espressa secondo la sintassi usata per le versioni

del software ( "es 1.0")

⇒

Context Information

Le Context Information determinano le regole di accesso alle informazioni

di contesto che caratterizzano l’utente. Tali regole sono espresse mediante access

list che corrispondono ad associazioni tra un gruppo di utenti e tuple. Le access

list presentate in questa sezione hanno uno scopo diverso da quelle viste per le

funzionalità di autorizzazione e autenticazione. In questo ambito le access list

individuano le regole di accesso alle informazioni di contesto dell’utente raccolte

dal Context Server. Queste contengono una lista di watcher che hanno

l’autorizzazione alla lettura di determinate informazioni di contesto espresse

tramite le tuple associate.Le tuple sono infatti un insieme di coppie <attributo,

valore> che permettono di esprimere le informazioni di contesto. Il valore

corrispondente ad ogni attributo può assumere valori diversi in funzione

dell'access-list in cui e' inserita la tupla. Le regole di accesso vengono quindi

costruite mediante l’associazione di un gruppo di watcher ad un insieme di tuple.

Ogni access list come gli altri component del profilo può essere associata ad un

sub profile. In questo modo l’utente può gestire anche l’attivazione di access list

con la tecnica dei sub profile. All’interno dell’Access List sarà presente un flag

che indica se è attiva o meno. Il flag sarà utilizzato dal Context Server nel

momento in cui deve fornire informazioni a un determinato watcher. Infatti, se il

watcher che richiede informazioni è presente in una access list non attiva, il

Context Server dovrà negare tali informazioni.

Quindi l’access list dovrà contenere le seguenti informazioni:

118

Presence URL della presentity: identifica univocamente la presentity ⇒

Identificativo Access List: è l’identificativo univoco dell’access list

dell’utente all’interno del Context Server

⇒

⇒

⇒

⇒

⇒

Nome Access List: è il nome dato dall’utente all’Access List

Flag di attivazione: è l’informazione che indica se l’access list è stata

attivata dall’utente

Lista Watcher : rappresenta il gruppo di watcher associati all’access list

Lista Tuple: fornice l’insieme di informazioni di contesto associato

all’access list

Architettura del sistema

In questa sezione viene descritta l’architettura di rete in cui viene

introdotto il sistema software User Profile Manager, analizzando le modalità

mediante le quali il sistema interagisce con le altre entità funzionali. Viene inoltre

data una breve descrizione di tali entità funzionali.

Scenario di riferimento

Lo User Profile Manager è il sistema software che si occupa della gestione

delle informazioni di profilo supportando: l’interazione dell’utente via web, le

richieste dei servizi attraverso l’invocazione di procedure remote e la

configurazione del servizio di presenza e contesto. L’utente utilizza il browser

presente sul suo terminale per usufruire dei servizi di gestione offerti dallo User

Profile Manager. Il Context Server interagisce con il sistema per ricevere

sottoscrizione ai parametri di contesto delle presentities e notificare

successivamente i cambiamenti dei valori di tali parametri. I servizi, durante il

processo di personalizzazione, hanno bisogno di venire a conoscenza delle

informazioni di profilo dell’utente ed a tale scopo invocano i metodi remoti messi

119

a loro disposizione. Infine, il Data Manager interagisce con i database che

contengono le informazioni di profilo per l’utente utilizzando gli specifici

protocolli per l’accesso. La Figura 0-2 mostra lo scenario di rete di riferimento:

Figura 0-2: Scenario di riferimento

Si descrivono successivamente tutte le entità esterne allo User Profile Manager.

User Browser

Il browser rappresenta la parte client del sistema (Web client). La parte

client deve essere evidentemente molto leggera in quanto deve essere eseguita su

un dispositivo hardware di capacità limitate quali possono essere un palmare o un

telefono mobile. La soluzione adottata in fase di progetto dello User Profile

Manager è quella di offrire all’utente un’interfaccia Web che permetta di

presentare semplici pagine HTML con form compilabili dall’utente ed inoltrabili

al web server ospitato dal sistema che consentano la gestione delle informazioni di

profilo. Una scelta alternativa potrebbe essere quella delle applet ma, anche se

leggere dal punto di vista elaborativo, presentano la complicazione della

120

distribuzione e dell’aggiornamento sui dispositivi utilizzati dagli utenti. Quindi il

progetto viene indirizzato verso l’utilizzo di servlet sul web server.

Servizi

In generale, i servizi possono interagire con l’UPM per ottenere alcune

informazioni di profilo utili alla personalizzazione. Come è stato visto nella

descrizione del Virtual Home Environment, i service provider possono essere

suddivisi in VASP e HE-VASP a seconda del tipo di rapporto stretto con

l’operatore di rete. Si possono distinguere due tipi di comportamenti principali:

i servizi forniti da VASP richiedono informazioni indipendenti dal

servizio in base alle modalità descritte nelle Access List dei servizi

e mai ai Service Profile

⇒

⇒ i servizi forniti da HE-VASP richiedono informazioni generali

indipendenti dal servizio in base alle modalità indicate nelle Access

List dei servizi ma possono inoltre accedere alle preferenze

dell’utente relative allo specifico servizio poiché lo User Profile

Manager mette a disposizione dell’utente le funzionalità per gestire

i Service Profile del servizio.

Nel primo caso sia VASP che HE-VASP possono richiedere, tramite

un’interfaccia fornita da una componente dello User Profile Manager, le

informazioni relative all’utente del tipo service independent quindi General

Information, User Preferences e Capabilities Description. La visibilità di queste

informazioni dovrà comunque rispettare i diritti di accesso decisi dall’operatore e

contenuti nelle Access List Operator appartenenti alle General Information

dell’utente.

Nel secondo caso, oltre alle informazioni service independent, il service provider

(HE-VASP) che stringe rapporti più stretti con l’operatore può ottenere

informazioni sulle preferenze dell’utente di tipo service dependent. Le preferenze

che l’utente deve settare per compilare un service profile di un servizio vengono

decise dall’HE-VASP cioè dal Service Provider che lo offre. Infatti tali

informazioni devono essere strettamente utili alla personalizzazione di un

121

determinato servizio. In questo scenario, il Service Provider mette a disposizione

un repository che lo User Profile Manager utilizza per inserire i service profile

degli utenti che si sottoscrivono al servizio. Il repository può essere locale al

servizio oppure locale allo User Profile Manager. Il Service Provider, nel

momento in cui ha bisogno delle preferenze dell’utente rispetto al servizio da lui

fornito, accede direttamente a tale repository e le recupera. L’accesso ai dati

avviene in base all’identificativo univoco dell’utente che può essere MSISDN (o

SIP URL) ed all’identificazione dell’istanza attiva. Quest’ultima informazione

può essere inserita come un dato booleano nel service profile.

Figura 0-3: Gestione e accesso dei Service Profile

Come si può vedere la gestione di un service profile richiede la

conoscenza, da parte dell’UPM, di diverse informazioni relative al servizio. Per

questo motivo, un nuovo servizio che viene creato ed offerto all’utente dovrà in

primo luogo fornire all’operatore una sua descrizione. La descrizione consiste in

un template organizzato secondo una rappresentazione XML in cui vengono

inserite le informazioni necessarie per integrare il servizio nella gestione del

Generic User Profile.Le informazioni richieste al servizio sono:

tipo di accesso al DB: JDBC per DB relazionale, JNDI per database

LDAP, etc

⇒

⇒

⇒

locazione dei dati: indirizzo IP, porta, nome e tipo del file di database

organizzazione dei dati (es. tabelle e campi per un DB relazionale)

122

struttura XML, XML schema e stylesheet associato per il service profile ⇒

informazioni di contesto richieste per la fornitura del servizio ⇒

⇒

⇒

Il tipo di accesso al database indica quale interfaccia utilizzare per accedere al

DB. L’organizzazione dei dati serve nel caso di accesso a database relazionale per

sapere qual è la struttura della tabella su cui è memorizzato il Service Profile. La

struttura XML e XML schema vengono utilizzate per descrivere come deve essere

organizzato il Service Profile del GUP e quali informazioni deve contenere. Lo

stylesheet indica invece come si dovrà rappresentare la pagina per la

personalizzazione del servizio all’utente. Le informazioni di contesto vengono

utilizzate per comunicare all’utente di quali informazioni di contesto ha bisogno il

servizio. L’utente rispetto a tali informazioni di contesto richieste dal servizio può

assumere due diversi comportamenti:

può utilizzare il servizio negando a questo l’utilizzo delle sue informazioni

di presenza/contesto

può utilizzare il servizio abilitandolo a fare uso delle sue informazioni di

presenza/contesto utili senza possibilità di negoziazione

Nel caso in cui l’utente abiliti il servizio a fare uso delle informazioni di contesto

si deve comunicare al context server la presenza di un nuovo watcher che richiede

l’accesso all’insieme di informazioni di contesto specificate.

A tale scopo viene creata in modo automatico una access list che presenta come

unico watcher il servizio e una tupla contenente tutti gli attributi di presenza

richiesti dal servizio. In questo modo il servizio si può presentare

successivamente al context server per richiedere i valori dei parametri.

L’access list relativa al servizio deve essere sempre associata a tutti i sub profile

Per esempio, un servizio Infotraffic sarà interessato sicuramente alla locazione

dell’utente e al suo bearer cioè al tipo di sessione che l’utente ha attualmente

stabilito.

Verrà creata a tale scopo una access list in cui l’unico watcher è rappresentato dal

servizio InfoTraffic e una tupla contenente l’insieme di informazioni di contesto

che il servizio ha bisogno di utilizzare.

La figura successiva mostra la situazione appena descritta:

123

Figura 0-4: Esempio di Access List creata per uno specifico servizio

Database

In questa sezione vengono analizzate le tipologie di database con le quali lo User

Profile Manager si deve interfacciare per soddisfare i requisiti esposti nel capitolo

precedente. Tali repository sono lo User Profile DB, Context DB e l’UAProf

repository. Tutti hanno in comune la caratteristica di contenere informazioni

relative all’utente.

Lo User Profile DB contiene logicamente le informazioni generali

dell’utente, le preferenze service independent e le preferenze service dependent.

Servizio per servizio sono possibili due situazioni:

service profile memorizzati localmente,nello User Profile DB ⇒

⇒

⇒

⇒

service profile memorizzati in database remoti e dedicati al servizio.

Nel caso di Service Profile memorizzato remotamente su database

relazionale, viene fatta l’ipotesi che tutti i dati del profilo siano memorizzati in

un’unica tabella avente come colonne lo userID, gli attributi del profilo ed un

campo ‘Active’ che indica se l’entry è attiva.

Si può considerare l’esempio illustrato nel capitolo 2 relativo al servizio MMS

Read reply: l’utente può decidere di ricevere una conferma dell’avvenuta

lettura del messaggio (ad esempio 1:ricevi conferma, 0: non confermare)

Sender visibility: l’utente può decidere di mostrare la sua identità o di

nasconderla quando invia un messaggio (ad esempio 1:ricevi conferma, 0:

non confermare)

124

Priority: indica la priorità del messaggio espresso ad esempio tramite un

intero.(3:priorità alta, 1:nessuna priorità)

⇒

Time to expiry: indica il tempo di vita del messaggio espresso ad esempio

in ore

⇒

Un esempio di tabella, in cui lo userID è espresso mediante SIP URL,

relativa a questo servizio è la seguente:

InstanceID UserID Active ReadReplySender

Visibility Priority

Time to

expire

1 sip:

[email protected] 1 1 0 3 24

2 sip:

[email protected] 0 1 1 1 24

Tabella 0-1: Esempio di tabella per il Service Profile

Si noti il campo ‘Active’ indica se l’istanza è o meno attiva. Questo campo

sarà utilizzato dal Service Provider per scegliere l’istanza del service profile da

utilizzare nel processo di personalizzazione. Il Context Server DB è il repository

locale al context server in cui sono contenute le access list e le tuple. Il context

server DB contiene sia le access list definite dall’utente sia le service list dei

servizi sottoscritti da un determinato utente che ha accettato di fornire i suoi

parametri di contesto. Per quanto riguarda le service list si prevede la loro

attivazione e de-attivazione nel caso in cui il servizio associato è presente o meno

nel sub profile attivo. Quindi, nel momento in cui si attiva un sub-profile, si

dovranno attivare tutte le access list relative ai servizi che ne fanno parte e

disabilitare le access list degli altri. La condizione Active indica che il servizio

rientra nell’Active sub-profile e quindi può accedere alle informazioni di contesto

(come watcher possibili è compreso anche UPM).

L’UAProf Repository contiene le capabilities dei terminali utilizzati dagli

utenti. Le capabilities vengono ottenute eseguendo una richiesta HTTP. Il nome

del file richiesto corrisponde al nome del modello del terminale utilizzato

dall’utente.

125

mailto:[email protected]

mailto:[email protected]

Context Server

Il context-server implementa un servizio offerto dalla home network il cui

obiettivo è quello di fornire uno strumento alla personalizzazione. In particolare il

context-server si occupa della raccolta, gestione e distribuzione delle informazioni

di contesto relative ad un utente. Oltre ad utilizzare il Context Server DB, l’UPM

interagisce con il Context Server per richiedere la notifica dei cambiamenti dei

parametri di contesto allo scopo di fornire il servizio di attivazione automatica dei

sub-profile. L’UPM, per fornire ad un utente il servizio di attivazione automatica

di sub profile, crea una service list per il servizio ‘User Profile Manager’ in cui

rappresenta l’unico watcher. All’access list viene associata un’unica tupla

contenente i parametri di contesto da monitorare per lo specifico utente. A questo

punto l’UPM si può sottoscrivere presso il context server come watcher verso

questo utente. Ciò avviene utilizzando il metodo subscriber fornito come

estensione SIMPLE del protocollo SIP. I diversi tipi di sottoscrizione sono distinti

dal tempo di monitoraggio della presentity. Un servizio già sottoscritto può

cancellarsi dalla lista dei watcher utilizzando il metodo subscriber con tempo di

monitoraggio nullo. Le risposte vengono notificate tramite il metodo notify.

Modalità di comunicazione

Lo User Profile Manager ha la necessità di comunicare con diverse entità

nel suo scenario di funzionamento. Tali entità sono l’utente, i servizi, il Context

Server e i database (Context Server DB, User profile DB e UAProf repository).

L'utente è dotato di un terminale in cui è presente un browser che permette

la visualizzazione delle pagine HTML. Lo User Profile Manager contiene un web

server tramite il quale vengono accettate le richieste e vengono restituite le

relative pagine HTML. Il protocollo utilizzato tra client e User Profile Manager è

quindi l’HTTP. Poiché i metodi di autenticazione non danno alcuna protezione sul

contenuto della trasmissione viene utilizzato il protocollo SSL che permette di

comunicare con il browser in modo codificato. Il ruolo del web server è quindi

quello gestire le richieste dell’utente eseguendo le servlet all’interno di un servlet

126

container (es. Tomcat) [Tom] e fornire i risultati in modo sicuro utilizzando il

protocollo SSL.

I servizi hanno bisogno di accedere allo User Profile Manager per

conoscere le caratteristiche dell’utente. Tale comunicazione avviene mediante

un’interfaccia fornita dal sistema grazie alla tecnologia RMI. Naturalmente, anche

le interfacce RMI utilizzeranno connessioni basandosi a livello sottostante sul

protocollo SSL.

Lo User Profile Manager avrà la necessità di comunicare con il Context

Server allo scopo di sottoscriversi come watcher dei parametri di contesto di

alcuni utenti. Tale necessità è richiesta per poter fornire agli utenti il servizio di

attivazione automatica di service profile. Come è stato già detto verranno utilizzati

in questo caso le estensioni SIMPLE del protocollo SIP.

In ultimo, lo User Profile Manager scambia dati con i vari database.

Questa comunicazione avviene in base alla tipologia del database, quindi l’UPM

deve possedere le funzionalità per gestire i vari casi.

User Profile Manager

Lo User Profile Manager deve gestire le seguenti problematiche:

controllo dell’accesso di utenti e servizi ⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

gestione dello scambio di informazioni con l’utente

gestione sub-profiles

attivazione dei sub-profile in modo diretto ed in modo automatico

gestione dello scambio di informazioni con i servizi

memorizzazione dei dati locali

accessibilità ai dati remoti

gestione delle access list per la personalizzazione del servizio di

presenza/contesto

L’architettura interna del sistema è mostrata nella Figura 0-5

127

Figura 0-5: Architettura interna dello User Profile Manager

Le funzionalità elencate precedentemente vengono supportate dai seguenti

sottosistemi che sono parte dell'UPM:

User Request Manager (URM) ⇒

⇒

E’ il sottosistema che si occupa di gestire le richieste degli utenti. Viene

implementato tramite servlet. Questo sottosistema riceve la richiesta

dell’utente e successivamente interagisce con lo User Profile Access

Manager per scopi di autenticazione/autorizzazione e con il Data Manager

per ottenere le informazioni richieste dall’utente.

Personalization Manager (PM)

Ha lo scopo di definire l’interfaccia per i servizi che richiedono

informazioni relative all’utente.Questa interfaccia permette ai servizi di

ottenere delle informazioni utili per la personalizzazione in base alle regole

di visibilità definite nelle access list. Il PM, prima di fornire le

informazioni ai servizi, interagisce con lo User Profile Access Manager

(UPAM) per richiedere l’autorizzazione dell’operazione. Solo dopo che il

servizio viene autorizzato, il PM utilizza le interfacce messe a disposizione

128

del Data Manager (DM) per restituire le informazioni richieste dal

servizio.

⇒

⇒

⇒

⇒

User Profile Access Manager (UPAM).

Ha il compito di autenticare utenti e servizi in base alle loro credenziali e

autorizzarli in base alle informazioni richieste ed al tipo di operazione

(lettura, inserimento, modifica o cancellazione) che si vuole effettuare su

di esse.

Data Manager (DM).

E’ il sottosistema fondamentale dello User Profile Manager poiché mette a

disposizione un insieme di servizi che consentono di realizzare le

funzionalità del sistema modellate mediante use case nel capitolo4. Tale

sottosistema ha infatti il compito di gestire le informazioni di profilo

attraverso le varie interfacce utilizzate dai vari database con cui

interagisce. Le informazioni gestite dal Data Manager riguardano le

caratteristiche generali dell’utente, le preferenze sia service-dependent che

service-independent e le access list relative all’operatore e al Context

Server.Il sistema presenta inoltre le funzionalità per la gestione deisub-

profile (descritti nel capitolo 2) definiti dall’utente e i riferimenti

all’Active sub-profile e Default Sub-profile. Quindi all’interno del Data

Manager saranno presenti anche la gestione del sub profile e i meccanismi

di interazione con il context server per gestire l'attivazione automatica dei

sub-profile. Si prevede infatti l’interfaccia RMI per la notifica da parte del

Context Server attraverso il Watcher SIP Handler dei parametri di contesto

ai quali lo User Profile Manager si è sottoscritto come Subsrciber-

Watcher, quindi come watcher che richiede le notifiche dei cambiamenti

dei paramentri di contesto come descritto nel capitolo 2. Il cambiamento di

un parametro di contesto genera l’esecuzione di una serie di operazioni:

Individuare il nuovo sub profile da attivare

Dato il nuovo Active Sub profile,

o Disattivare le access list relative al precedente sub profile e

attivare le access list relative al nuovo

129

o Per ogni servizio, disattivare l’istanza relativa al precedente

sub profile (se presente) e attivare l’istanza relative al

nuovo (se presente)

o Per quanto riguarda le user preferences disattivare l’istanza

relativa al precedente sub profile (se presente) e attivare

l’istanza relative al nuovo (se presente)

Wrapper (W) ⇒

⇒

Rappresenta un’estensione del sottosistema precedente poiché costituisce

un adattatore che consente di memorizzare dati basati su una

rappresentazione XML, utilizzata per descrivere il GUP, in database non

nativi XML. Fornisce quindi capacità di estendibilità all’UPM verso

diversi protocolli di accesso al database.

Watcher SIP Handler.

Gestisce l’interfaccia SIMPLE per supportare l’interazione con il Context

Server. Il Watcher SIP Handler ha quindi lo scopo di permettere la

sottoscrizione dello User profile Manager ai cambiamenti dei parametri di

contesto. Viceversa invoca un metodo presente nel Data Manager per

notificare tali cambiamenti.

Nel funzionamento generale dell’UPM possiamo notare che sia l‘UPAM sia il

DM agiscono da server verso i client PM e URM .

Processo di personalizzazione proposto

Il processo di personalizzazione ha lo scopo di adattare il servizio alle

esigenze ed al contesto dell’utente. Il supporto al processo di personalizzazione è

fornito dall’operatore di rete che ha il compito di raccogliere tutte le informazioni

che caratterizzano l’utente in un determinato momento ed in un determinato luogo

utilizzando lo User Profile Manager e il Context Server.

130

Il processo di personalizzazione è considerato come l’insieme di fasi che

vengono attraversate da un servizio per renderlo personalizzato. Il processo di

personalizzazione che si propone può essere diviso nelle seguenti fasi:

Adattamento del contenuto ⇒

⇒

⇒

⇒

Aggregazione dei contenuti

Qualità del servizio

Adattamento alle capabilities

In un’ipotetica catena di produzione si prende il servizio come prodotto

grezzo. Il prodotto di tale catena è il servizio personalizzato.

Come si può vedere dalla figura seguente, l’utente si rivolge ad un Service

Provider per richiedere un determinato servizio. Al servizio, vengono applicate

tutte le fasi del processo di personalizzazione proposto. Le informazioni utilizzate

nel processo di personalizzazione vengono prelevate da un ipotetico profile DB

che può essere, a seconda della fase del processo, il Context DB, lo User Profile

DB oppure l’UAProf repository. La Figura 0-6 rappresenta l’utente, il servizio e le

fasi presenti nel recesso di personalizzazione proposto.

Figura 0-6: Processo di personalizzazione proposto

131

Adattamento del contenuto

Tale fase ha lo scopo di personalizzare i contenuti del servizio in base a:

Preferenze dell’utente ⇒

⇒

⇒

⇒

Informazioni sul contesto

Le preferenze dell’utente possono venire suddivise a loro volta in due

sottoinsiemi:

Preferenze basate sul servizio

Preferenze generali

Entrambi i sottoinsiemi delle preferenze contengono informazioni statiche

e non basate sul contesto dell’utente. Le preferenze basate sul servizio sono una

dichiarazione esplicita dei tipi di contenuti che l’utente gradisce ricevere e del tipo

di interazione che vuole avere con il servizio stesso. Tali informazioni sono

contenute nei Service Profile che rappresentano una parte dello User Profile. Le

preferenze generali sono invece indipendenti dal servizio e riguardano

informazioni comuni (hobbies, sport praticati,…. ).

Può accadere che le informazioni nel Service Profile siano in

contraddizione con le preferenze generali. In questa situazione viene data la

priorità più alta alle informazioni del service profile e quindi non vengono

considerate le user preferences.

Le preferenze generali divengono però fondamentali nei casi in cui non

sono presenti le preferenze basate sul servizio. Ad esempio possono essere

utilizzate da un servizio che non ha ancora definito Service Profile per alcuni

utenti. In questo caso il servizio è in grado di fornire almeno un primo livello di

personalizzazione.

L’adattamento del contenuto si deve basare anche sulle informazioni che si

hanno sul contesto dell’utente che si possono considerare come le preferenze

dinamiche dell’utente.

Tali informazioni, che vengono fornite al servizio attraverso il Context

Server, permettono di adattare il contenuto all’ambiente dinamico dell’utente.

Il servizio, come descritto in [vanSet], può utilizzare diverse tecniche per

l’adattamento del contenuto:

132

Selezione della categoria. Viene usata quando il server ha una

classificazione di dati basata sulla categoria, Tramite le informazioni

contenute nei service profile e nelle user preferences si sceglie una o

più categorie di dati da inviare allo user

⇒

Basata su query. Il sistema è basato su query fornite dall’utente o

generate dal sistema. Le query vengono raffinate mediante l’utilizzo

di ontologie. Tali ontologie sono costruite sulle informazioni dello

User Profile e quindi conoscendo il mondo dell’utente possono

inserire nelle query dei campi che permettono la selezione di

informazioni specifiche.

⇒

⇒

⇒

⇒

Information filtering. Si basa sul filtraggio di contenuti in base alle

informazioni appartenenti allo User Profile. Inoltre, tale metodo

richiede l’invio di feedback sulla rilevanza delle informazioni da

parte dell’utente. Mediante questi feedback si raffina lo User Profile.

Il problema fondamentale di questo approccio è che l’utente in

genere non ha possibilità (ad esempio per mancanza di tempo) di

inviare i feedback. Una soluzione può essere fornita dall’approccio

successivo.

Social Filtering. Si individuano utenti simili; in tal modo i

comportamenti o i feedback di altri utenti possono essere utilizzati

per il raffinamento del profilo anche di utenti simili. In questo modo

utenti che non eseguono feedback possono usufruire di feedback di

altri utenti. Purtroppo tale sistema non copre utenti con preferenze

particolari e quindi non comuni. Per tali utenti non si possono trovare

sufficienti utenti simili.

Aggregazione dei contenuti

L’aggregazione dei contenuti consiste nell’inserire oltre alle informazioni

richieste anche informazioni che possono risultare utili o piacevoli all’utente. Le

informazioni che vengono allegate alla richiesta dell’utente sono scelte in base a:

Preferenze dell’utente

133

Informazioni sul contesto ⇒

Ad esempio, ad una richiesta di orario dei treni in un determinato giorno per

Foggia si potrebbero associare come risposta anche le informazioni

meteorologiche previste per la data di arrivo a Foggia (aggregazione basata sul

contesto) ed informazioni sullo stadio di Foggia (indirizzo, capienza, orario

allenamenti…) se l’utente ama ricevere notizie sportive (aggregazione basata sulle

preferenze).

Adattamento alle capabilities

I passi precedenti hanno lo scopo nel loro insieme di selezionare ‘quali’

informazioni verranno inviate all’utente. La fase che viene ora analizzata insieme

alla successiva hanno invece lo scopo di determinare ‘come’ le informazioni

verranno fornite all’utente.

Il primo passo che viene compiuto nel determinare la modalità di fruizione

del servizio riguarda l’adattamento alle capabilities del terminale. Nelle

capabilities del terminale vengono considerati oltre alle capacità hardware e

software anche aspetti relativi ad applicativi come il browser del terminale.

La scelta delle informazioni in base alle capabilities del terminale è un

passo fondamentale in quanto evita che l’utente si trovi nell’incapacità di

usufruire di un servizio che ha sottoscritto ed in genere paga. Ad esempio si evita

di inviare all’utente un immagine in un formato che il suo terminale non sa

trattare.

Lo scopo di questa fase è quindi aumentare l’accessibilità al servizio

adattandolo al profilo del terminale dell’utente.

Per poter effettuare tale adattamento si deve ipotizzare che le informazioni

siano disponibili in diversi formati. Ciò permette l’individuazione della risorsa ‘ad

hoc’ per il terminale dell’utente.

Le capabilities del terminale possono essere ottenute mediante

interrogazione a server esterni (UAProf repository) attraverso il protocollo HTTP.

L’indirizzo dell’UAProf repository e il terminale utilizzato dall’utente vengono

forniti dallo User Profile Manager. Nel caso in cui il terminale non supporti la

134

tecnica UAProf proposta da WAP Forum [UAProf], lo User Profile Manager

fornisce un insieme ridotto di capabilities che sono state direttamente segnalate

dall’utente.

Qualità del servizio

L’aspetto successivo che influisce su ‘come’ l’applicazione interagirà con

l’utente è la qualità del servizio. La diversità delle applicazioni che potranno

essere fornite e l’eterogeneità degli utenti (utenti business, utenti generici ecc)

motivano l’inserimento della qualità del servizio tra le fasi del processo di

personalizzazione. La qualità del servizio è considerata all’interno della rete un

unico parametro costituito da molti attributi (ritardo sul trasferimento, bit rate

massimo e garantito,…) ed è contenuta nel HSS/HLR. I valori di tali attributi

determinano il livello di qualità del servizio.

I livelli definiti all’interno della rete, descritti in [3GPPTS24.008], sono 4:

Conversational (e.g. voice) ⇒

⇒

⇒

⇒

Streaming (e.g. streaming video)

Interactive (e.g. web browsing)

Background (e.g. e-mail, SMS)

Il livello di qualità con cui il servizio sarà fornito viene stabilito in base

agli accordi presi con l’utente al momento della sottoscrizione ma anche

negoziandola nel momento della fruizione del servizio. In genere la qualità

sottoscritta è considerata la massima qualità richiedibile e negoziabile. In tale

negoziazione si tiene conto anche delle capabilities della rete che sta servendo

l’utente.

Quindi lo scopo di questa fase è fornire il servizio secondo la qualità del

servizio dell’utente per quanto consentito dalla rete.

135

Progetto componenti software e interfacce

In questo capitolo vengono analizzati, in modo dettagliato, i sottosistemi

dello User Profile Manager individuati nel capitolo precedente. Vengono in

particolare descritte le interfacce di ogni sottosistema e come queste interagiscono

tra loro per soddisfare i requisiti di progetto espressi nel capitolo 4.

User Profile Access Manager

Lo User Profile Access Manager ha il compito di fornire le funzionalità

per l’autenticazione e l’autorizzazione di utenti e servizi. Per quanto riguarda gli

utenti, il meccanismo di autenticazione viene realizzato dall’UPAM in base alla

combinazione userID + password. Lo userID dell’utente può corrispondere sia al

numero telefonico dell’utente (MSISDN) che all'identificativo all’interno del

protocollo SIP (SIP URL). Tali informazioni saranno fornite dall’utente al

momento del login nel sistema.

Anche i servizi avranno bisogno di essere autenticati e autorizzati prima di

poter accedere alle informazioni dell’utente per offrire il servizio di

personalizzazione. L'autenticazione dei servizi viene fatta in base alla

combinazione serviceID + secretToken, dove il serviceID è l'identificativo del

136

servizio fissato dall'operatore di rete e il secretToken è un codice segreto fissato

dal servizio e concordato con l'operatore.. La conoscenza del secretToken solo da

parte del servizio e dell’UPM evita la situazione in cui un generico servizio possa

presentarsi con il nome di un altro acquisendo dei diritti che non gli appartengono

sulla visibilità delle informazioni dell’utente.

L'autorizzazione dell'utente ad effettuare un'operazione specifica viene

gestita all'atto dell'invocazione dell'operazione stessa, interagendo con l'UPAM. A

questo scopo l'UPAM utilizza le informazioni presenti nella Operator Access List,

che permettono di stabilire il livello di visibilità sui dati del GUP, definendo, per

ogni component, il tipo di operazione che può essere effettuata. Per ogni

component possono essere definite le seguenti modalità di accesso:

ReadWrite: specifica che l’utente può effettuare qualsiasi operazione sul

component

⇒

⇒

⇒

ReadOnly: specifica che l’utente può accedere al component in sola lettura

Denied: non consente l’accesso al component né in lettura né in scrittura

Un utente autenticato e autorizzato ad accedere all’UPM eseguirà una serie

di richieste HTTP per la gestione delle sue informazioni di profilo. Il recupero

dell’identità dell’utente viene eseguito tramite il securityID che rappresenta

l’identificativo della sessione SSL. Questo identificativo è unico e viene assegnato

all’interno del protocollo SSL quando l’utente, mediante il suo browser, esegue la

sua prima richiesta verso l’UPM. Viene rilasciato quando la sessione dell’utente

termina. Si può prevedere un time out che chiuda la sessione se, per un

determinato periodo di tempo, l’utente non ha inviato richieste. Durante la durata

della sessione l’UPAM memorizzerà l’associazione tra securityID e userID

dell’utente.

Le applicazioni servlet che gestiscono le richieste dell’utente possono

accedere al securityID invocando l’appropriata funzione. In questo modo, il

securityID può essere utilizzato per ottenere dall’UPAM lo userID dell’utente ad

ogni richiesta di quest’ultimo. Tale valore sarà utilizzato come chiave d’accesso ai

dati dell’utente. Saranno prese in considerazione in questo modo solo le richieste

che forniscono un securityID valido quindi solo le richieste di utenti autenticati.

137

Può accadere che alcuni browser, tra una richiesta e la successiva cambino il

valore del securityID in modo impredicibile. Il problema viene risolto utilizzando

la tecnica dei cookies. La gestione delle richieste all’interno di una sessione

avviene nello stesso modo ma utilizzando come identificativo dell’utente il cookie

al posto del securityID. Una volta eseguita l’autenticazione, l’UPAM dovrà

richiedere le Operator Access List al Data Manager allo scopo di autorizzare

l’utente ad eseguire la specifica operazione richiesta.

L’autorizzazione dei servizi avviene in modo analogo; l’operatore prevede

una access list per ogni sevizio. Ad ogni component viene associato la relativa

modalità di accesso che in questo caso è limitata alle due seguenti opzioni:

ReadOnly o Denied che mantengono i significati sopra elencati. La modalità di

accesso ReadWrite non viene prevista per i servizi poiché in generale il servizio

non può modificare le informazioni di profilo dell’utente.

Le richieste dei servizi al Personalization Manager vengono effettuate

mediante l’invocazione di interfacce remote (RMI). Il meccanismo RMI (Remote

Method Invocation) viene utilizzato insieme al protocollo SSL poiché anche in

questo caso vengono gestite le informazioni riservate dell’utente.

Anche per le richieste dei servizi viene utilizzato il concetto di sessione. In

questo caso, a differenza delle Java Servlet, non si può far uso del securityID per

tenerne traccia poiché RMI non fornisce la possibilità di accedere a questa

informazione. Si introduce a tale scopo il sessionID che viene assegnato

dall’UPAM al servizio nel momento dell’autenticazione. Il servizio utilizza il

sessionID per effettuare le richieste successive al Personalization Manager.

I servizi offerti dalla classe UPAM possono essere suddivisi in due

sottoinsiemi a seconda se sono rivolti allo User Request Manager oppure al

Personalization Manager.

Servizi offerti allo User Request Manager

I servizi offerti allo User Request Manager permettono a quest’ultimo di

ottenere l’autenticazione e l’autorizzazione degli utenti e di gestire le loro

sessioni. Tenere traccia delle sessioni evita che gli utenti debbano sempre

138

reinserire le loro credenziali ogni volta che richiedono l’esecuzione di

un’operazione. Vengono elencate successivamente le interfacce dello User Profile

Access Manager utili allo User Request Manager e alla gestione delle sessioni:

public boolean userAuthenticate (string userID, string password,

string securityID)

Tale interfaccia permette di verificare tramite userID (MSISDN or SIP

URL) e password se l’utente è sottoscritto e può accedere alle sue informazioni di

profilo. Il metodo verifica anche che l’utente non sia già stato autenticato in

precedenza. Il parametro d’ingresso securityID è usato per creare il riferimento

<securityID;userID,OperatorAccessList> nell’UPAM tramite l’utilizzo del

metodo addToList() descritto in seguito. Se l’utente è sottoscritto al sistema di

gestione viene inviato un valore ‘true’ in risposta altrimenti il risultato è ‘false’.

Tale metodo deve essere definito public in modo che possa essere invocato dallo

User Request Manager.

private void addUserToList (string securityID, string userID, Vector

OperatorAccessList)

Il metodo è utilizzato dall’UPAM stesso per tenere traccia delle sessioni

attive, vengono passati come parametri d’ingresso il securityID, lo userID e le

liste di accesso definite dall’operatore. Il metodo crea il riferimento <securityID,

userID,OperatorAccessList>. Nella tabella viene inserito anche Operator Access

List in modo che non si debbano recuperare ogni volta i privilegi di accesso

dell’utente dal Data Manager. Tale metodo rappresenta una funzionalità interna

dell’UPAM quindi è viene definito private

public string isUserAuthorized (string securityID, string

componentName, string accessMode)

L’interfaccia viene invocata dallo User Request Manager per verificare se

l’utente è autenticato e se è autorizzato a gestire un determinato component del

profilo (autorizzazione). Il metodo riceve in ingresso il securityID dell’utente, il

nome del component del profilo che si vuole gestire e la modalità di accesso.

139

L’UPAM consulta la tabella degli utenti autenticati, se l’utente è presente analizza

l’Operator Access List. Se l’utente non è presente nella tabella invia il messaggio

[AuthenticationNeeded]. Se l’utente non è autorizzato viene inviato il messaggio

[AuthorizationFailure]. Nel caso in cui i controlli procedono senza alcun

problema viene restituito lo userID con il quale lo User Request Manager richiede

accede ai servizi offerti dal Data Manager.

public void logoutUser (string securityID)

L’interfaccia viene utilizzata dallo User Request Manager per segnalare

che una sessione è terminata. All’invocazione di questo metodo, lo User Profile

Manager elimina la coppia <securityID,userID,OperatorAccessList> relativa al

parametro passato in ingresso al metodo.

Servizi offerti al Personalization Manager

I servizi offerti al Personalization Manager permettono di autenticare e

autorizzare i servizi. I metodi presenti in questa sezione sono molto simili a quelli

analizzati per i servizi offerti allo User Request Manager poiché anche in questo

caso si presentano le funzionalità per la gestione delle sessioni.

public int serviceAuthenticate (string sessionID )

Il Personalization Manager utilizza tale interfaccia per autenticare il

servizio che ha fatto richiesta delle informazioni dell’utente. Tale metodo si

assicura che il servizio è registrato al sistema e che non sia già stato autenticato.

Restituisce il sessionID assegnato alla sessione.

private int sessionIDCalculation ()

Se il servizio viene autenticato, viene determinato tramite questo metodo il

sessionID che identifica la sessione. Il sessionID è un valore random che però

deve essere diverso da tutti gli altri sessionID che identificano le altre sessioni

attive.

140

private void addServiceToList (string sessionID, string serviceID,

vector AccessListforService)

Il metodo ha lo scopo di creare una entry nella tabella delle sessioni attive

per i servizi. Quindi vengono inserite le seguenti informazioni:

<sessionID,serviceID,AccessListforOperator>

public void isServiceAuthorised (string serviceID, string

componentName)

Il metodo viene invocato dal Personalization Manager per verificare se il

servizio, identificato dal serviceID, è autenticato ed ha i diritti per accedere al

component del profilo identificato dal parametro componentName. In questo caso

non vi è bisogno di specificare la modalità di accesso poiché è implicito essere in

sola lettura.

public void logoutService (string sessionID)

Il metodo viene utilizzato per segnalare che una sessione è terminata.

Viene quindi eliminata la entry nella tabella relativa al sessionID.

Data Manager

Il Data Manager (DM) è il sottosistema fondamentale dello User Profile

Manager poiché mette a disposizione un insieme di servizi che consentono di

realizzare le funzionalità del sistema modellate mediante use case nel capitolo

precedente. I servizi offerti da questo sottosistema vengono utilizzati dagli altri

sottosistemi che compongono lo User Profile Manager per fornire informazioni ad

utenti e servizi autenticati e autorizzati. Lo User Request Manager utilizza le

interfacce messe a disposizione dal Data Manager per consentire all’utente di

gestire il suo profilo inserendo modificando e cancellando i component che lo

costituiscono. Il Data Manager deve inoltre mettere a disposizione dello User

Request Manager le interfacce che consentono la gestione dei Sub Profile, delle

141

Access List e l’inserimento dei valori degli attributi di contesto definiti

dall’utente.

Il Personalization Manager utilizza le interfacce del Data Manager allo

scopo di ottenere le informazioni di profilo da restituire ai servizi autenticati e

autorizzati.

In ultimo, il Data Manager deve fornire interfacce utili allo User Profile

Access Manager per ottenere le Access List, definite dall’operatore, relative ad un

determinato utente o servizio. In base a tali liste restituite dal Data Manager,

l’UPAM può autorizzare le entità richiedenti ad eseguire le relative operazioni.

Tutte le interfacce offerte dal Data Manager a Personalization Manager,

User Request Manager e User Profile Access Manager vengono implementate

tramite RMI poiché il Data Manager è visto come un entità che gestisce i dati di

profilo e offre interfacce per accedere ai servizi che mette a disposizione.

Servizi offerti a User Request Manager e Personalization Manager

Sono un insieme di servizi che permettono all’utente di gestire il suo

profilo tramite lo User Request Manager e ai Service Provider di ottenere

informazioni circa l’utente allo scopo di personalizzare i servizi offerti.

Gestione dei dati di registrazione

Il Data Manager offre dei servizi allo User Request Manager relativi alla

registrazione di nuovi utenti e alla cancellazione di utenti già registrati

public boolean userRegistration (string userID, string password)

Memorizza userID e password del nuovo utente che si vuole sottoscrivere.

Viene invocato dallo User Request Manager che comunica attraverso i parametri

le credenziali dell’utente.

public boolean userDelete (string userID)

142

Lo User Request Manager invoca tale metodo per eliminare un utente

l’utente dalla lista degli utenti registrati al sistema.

Gestione component del profilo

L’insieme di interfacce definite in questa sezione permette di gestire le

istanze relative ai component Basic Profile, Service Profile e Capabilities

Description. Le istanze richieste vengono fornite attraverso un frammento XML

che contiene al suo interno lo stylesheet associato per la visualizzazione. Mediante

tale stylesheet si visualizzeranno i valori associati all’istanza all’interno di un

form e i servizi che l’utente potrà invocare. In questo modo l’utente può

modificare i valori rispettando i range e i tipi di dato associati. Una volta conclusa

l’operazione di modifica, l’utente può richiedere la memorizzazione dell’istanza.

Le interfacce qui presentate vengono utilizzate in modo particolare dallo User

Request Manager ma anche dal Personalization Manager per ottenere

informazioni di profilo da fornire ai servizi.

public string getListComponent (string userID, string

componentName)

Restituisce la lista di istanze che l’utente (userID) ha definito per un

determinato component (componentName). La servlet visualizza la lista di istanze

ottenuta in modo che l’utente possa scegliere quale modificare.

public string newInstance (string userID, string componentName)

Viene restituito un frammento XML in cui non sono presenti i valori degli

attributi ma viene assegnato soltanto l’instanceID dal sistema. Il frammento

contiene anche il riferimento allo stylesheet da utilizzare. All’utente sarà quindi

presentato un form vuoto in cui si possono inserire i valori della nuova istanza.

public string getInstance (string userID, string componentName, int

instanceID)

Restituisce il frammento XML relativo all’istanza richiesta. Il frammento

contiene anche il riferimento allo stylesheet da utilizzare. L’utente è identificato

143

mediante il suo userID mentre il component è identificato dal componentName.

Se l’instanceID contiene il valore 0, viene restituito il frammento XML

corrispondente all’istanza attualmente attiva. Questo è utile per il Personalization

Manager che si rivolge al Data Manager a fronte di una richiesta da parte di

servizi. Il Personalization Manager deve infatti restituire ai servizi solo le

informazioni appartenenti all’Active Sub Profile. Il Personalization Manager, una

volta ottenuta la stringa che contenente il frammento XML, deve eseguire il

parsing per prelevare l’attributo a cui è interessato. Naturalmente il parametro

instanceID non ha valore per i component che possono avere una sola istanza

come ad esempio General User Information.

public boolean setInstance (string userID, string componentName,

string instance, int instanceID)

Permette l’inserimento di una nuova istanza e la modifica di un’istanza

esistente. L’utente è identificato mediante il suo userID mentre il component è

identificato dal componentName. Il Data Manager sostituisce i precedenti valori

dell’istanza con i nuovi valori.

public boolean deleteInstance (string userID, string componentName,

int instanceID)

Permette la cancellazione dell’istanza (instanceID) da parte di un utente.

L’utente è identificato mediante il suo userID mentre il component è identificato

dal componentName.

Gestione Access List relative al Context Server

Le Access List, definite per regolare l’accesso ai parametri di contesto di

una presentity (utente) da parte di watcher (utenti e servizi) rappresentano un

component dello User Profile. A differenza degli altri component, i dati

all’interno di ogni Access List possono crescere in modo arbitrario poiché

possono essere presenti un numero aleatorio di watcher e tuple. Quindi la

dimensione di una access list non è fissata come può essere ad esempio quella di

144

un’istanza di Service Profile in cui l’utente deve inserire un numero definito di

preferenze.

Ciò comporta la non applicabilità delle tecniche di gestione viste per i

component Basic Profile, Service Profile e Capabilities Description a meno che

non si limiti il numero massimo di watcher e di tuple che possono essere associati

ad una Access List. Per la gestione delle access list quindi il Data Manager deve

prevedere le seguenti interfacce:

public boolean newWatcher (string userID, int accesslistID, string

watcherID)

Tale metodo permette di inserire un nuovo watcher (identificato dal

parametro watcherID) all’interno di una access list (accesslistID). Viene restituito

un valore booleano per indicare se l’operazione è andata a buon fine

public boolean deleteWatcher (string userID, int accesslistID, string

watcherID)

Tale metodo permette di eliminare un determinato watcher (identificato

dal parametro watcherID) all’interno dell’access list (accesslistID). Viene

restituito un valore booleano per indicare se l’operazione è andata a buon fine

public boolean setTuple (string userID, int accesslistID, string

tupleID)

Tale metodo permette di inserire una nuova tupla (identificata dal

parametro tupleID) all’interno di una access list (accesslistID). Viene restituito un

valore booleano per indicare se l’operazione è andata a buon fine

public boolean deleteTuple (string userID, int accesslistID, string

tupleID)

Tale metodo permette di eliminare una tupla (identificata dal parametro

tupleID) all’interno dell’access list (accesslistID). Viene restituito un valore

booleano per indicare se l’operazione è andata a buon fine

145

public string getAllAccessList (string userID)

Il metodo ha lo scopo di restituire il frammento XML che contiene la lista

delle Access List definite dall’utente. In questo modo l’utente può scegliere quale

Access List gestire.

public string getAllTuple (string userID)

Il metodo ha lo scopo di restituire il frammento XML relativo alla lista

delle tuple definite dall’utente. In questo modo l’utente può scegliere quale tupla

gestire.

public string newAccessList (string userID, string nameAccessList)

Il metodo ha lo scopo di creare una nuova Access List e restituisce un

valore booleano se il procedimento è andato a buon fine.

public boolean deleteAccessList (string userID, int accesslistID)

Il metodo ha lo scopo di eliminare l’Access List identificata

dall’accesslistID specificato. Viene restituito un valore booleano per indicare se

l’operazione è andata a buon fine

public int newTuple (string userID)

Il metodo ha lo scopo di creare una nuova tupla e restituisce il tupleID

assegnato alla nuova tupla

public boolean deleteTuple (string userID, int tupleID)

Il metodo ha lo scopo di eliminare la tupla identificata dal tupleID

specificato.

Verranno eliminati anche i riferimenti alla tupla all’interno di tutte le

Access List. Viene restituito un valore booleano per indicare se l’operazione è

andata a buon fine

public string getAttibuteList (string userID);

146

Il metodo restituisce il frammento XML di tutti gli attributi di contesto che

l’utente può associare alla tupla

public boolean newAttribute (string userID, int tupleID, string

attributeName)

Tale metodo permette di inserire un nuovo attributo tra quelli possibili

(identificato dal parametro attributeName) all’interno di una tupla (tupleID).

Viene restituito un valore booleano per indicare se l’operazione è andata a buon

fine

public boolean modifyAttributeValue (string userID, int tupleID,

string attributeName, string value)

Tale metodo permette di settare uno degli attributi di contesto (identificato

dal parametro attributeName) il cui valore deve essere inserito dall’utente (ad

esempio User Provided Location) all’interno di una tupla (tupleID). Viene


public boolean deleteAttribute (string userID, int tupleID, string

attributeName)

Tale metodo permette di eliminare un determinato attributo di contesto

(identificato dal parametro attributeName) all’interno della tupla (tupleID). Viene


Gestione Sub Profile

public string getListSubProfile (string userID)

Il metodo restituisce la lista dei sub profile che un utente ha definito. La

visualizzazione di tale lista permette all’utente di scegliere quale sub profile

modificare o cancellare.

147

public string newSubProfile (string userID)

Viene restituito un frammento XML in cui per ogni component del profilo

non è settata alcuna istanza. Il frammento contiene anche il riferimento allo

stylesheet da utilizzare. All’utente sarà quindi presentato un form vuoto in cui si

può inserire il nome del nuovo sub profile e per ogni component, l’identificativo

dell’istanza che appartiene al sub profile.

public string getSubProfile (string userID, string subprofileName)

Restituisce il frammento XML relativo al sub profile richiesto. Il

frammento contiene anche il riferimento allo stylesheet da utilizzare. L’utente è

identificato mediante il suo userID mentre il sub profile che si vuole gestire è

identificato da subprofileName.

public boolean setSubProfile (string userID, string subprofileName,

string subprofile)

Permette l’inserimento di un nuovo sub profile e la modifica di un sub

profile già esistente. L’utente è identificato mediante il suo userID mentre il sub

profile è identificato dal subprofileName. Nel caso di modifica di un sub profile

esistente, il Data Manager sostituisce le precedenti istanze con le nuove.

public boolean deleteSubProfile (string userID, string

subprofileName)

Tale metodo permette all’utente (userID) di eliminare il sub profile

indicato da subprofileName

public boolean modifyActiveSubProfile (string userID, string

subprofileName)

Tale metodo ha lo scopo di eseguire tutte le operazioni legate

all’attivazione di un sub profile

per ogni servizio sottoscritto dall’utente, disattivare l’istanza relativa al

precedente sub profile (se presente) e attivare l’istanza relative al nuovo

(se presente)

⇒

148

disattivare le access list relative al precedente sub profile e attivare le

access list relative al nuovo

⇒

per quanto riguarda le user preferences disattivare l’istanza relativa al

precedente sub profile (se presente) e attivare l’istanza relative al nuovo

(se presente)

⇒

public boolean modifyDefaultSubProfile (string userID, string

subprofileName)

Tale metodo permette di cambiare il sub profile di default quindi il sub

profile che viene attivato quabndo non è presente una specifica scelta da parte

dell’utente e richiede capabilities minime del terminale e della rete

public string getAutomaticActivation (string userID)

Restituisce il frammento XML relativo agli eventi di attivazione

automatica. Il frammento contiene anche il riferimento allo stylesheet da

utilizzare. L’utente è identificato mediante il suo userID. La stringa viene

visualizzata sullo standard output e l’utente può settare i sub profile da attivare per

ogni evento.

public string setAutomaticActivation (string userID, string

AutomaticAttivation)

Mediante questa interfaccia, viene memorizzato il frammento xml

modificato relativo agli eventi di attivazione automatica dei sub profile.

Servizi offerti allo User Profile Access Manager (UPAM)

I servizi che il Data Manager offre allo User Profile Access Manager

possono essere suddivisi in due gruppi: servizi relativi alle Access List Operator e

servizi per la verifica di avvenuta sottoscrizione da parte di utenti e servizi. Questi

due gruppi, insieme, forniscono all’UPAM un supporto nelle operazioni di

autenticazione e autorizzazione

149

Fornitura delle Access List per l’autorizzazione

Il Data Manager offre all’UPAM due interfacce che forniscono le Operator

Access List relative ad utenti e servizi.

public vector getUserAuthorisation (string userID)

Restituisce l’Operator Access List dell’utente, implementata tramite

Vector, che identifica per ogni component l’operazione che può essere effettuata .

public vector getServiceAuthorisation (string serviceID)

Restituisce la lista di component del profilo a cui il servizio può accedere

sempre in sola lettura.

Verifica Registrazione

Tali interfacce permettono in generale di verificare se utenti e servizi sono

registrati nel portale del Mobile Network Operator (MNO).

public boolean checkAuthenticationUserData (string userID, string

password)

Viene autenticato l’utente controllando se è registrato al sistema

public boolean CheckAuthenticationServiceData (string sessionID)

Viene autenticato il servizio controllando se è già registrato al sistema

Servizi offerti al Watcher SIP Handler

Il Watcher SIP Handler rappresenta l’interfaccia dello User Profile

Manager verso il mondo SIP. Fornisce quindi la possibilità di sottoscriversi come

watcher presso il context server tramite la primitiva Subscribe segnalando

successivamente i cambiamenti degli attributi di contesto realtivi alla

sottoscrizione. Per ottenere la segnalazione si deve mettere a disposizione del

150

Watcher SIP Handler un’interfaccia notify che, una volta invocata, recupera dai

parametri di ingesso l’evento notificato,il suo valore e la presentity alla quale si

riferisce. Consulta la lista di eventi che l’utente ha definito e recupera il nuovo sub

profile che deve diventare attivo.

public void notify (string sipUri, string via, string to, string from,

string call-ID, int c-Seq, string content-Type, int content-Length, string body)

Il metodo fornisce la notifica dei cambiamenti dei paramenti di contesto

quindi riporta tutte le informazioni contenute nel messaggio notify di SIMPLE

Wrapper

Il wrapper rappresenta lo strato più basso del Data Manager. Infatti ha il

compito di interagire con i DBMS che contengono le User Profile Information. Lo

scopo di tale sottosistema è quello di non vincolare il Data Manager alla gestione

di un’unica classe di database bensì permettere la gestione di diverse tipologie di

database. Il wrapper si dovrà in generale prevedere nel caso in cui HE-VASP

presentano database che non siano XML nativi. Molti database esistenti

implementano già questa funzionalità, quindi hanno funzionalità per presentare il

risultato di query in XML.

Personalization Manager

Il Personalization Manager ha il compito di fornire un’interfaccia utile ai

servizi nel corso del processo di personalizzazione. Le informazioni che il PM

fornisce ai servizi, a fronte di una loro richiesta, hanno in comune di appartenere

all’Active Sub Profile cioè caratterizzano al momento della richiesta l’utente e le

sue esigenze. L’interfaccia viene realizzata mediante la tecnologia RMI. Per

garantire l’estendibilità del profilo dell’utente, le informazioni vengono restituite

151

ai servizi utilizzando una lista di elementi <attributo,valore>. Infatti, le

informazioni vengono passate ai servizi utilizzando la classe ‘Attribute’:

Classe Attribute {

String name;

String value;

String dataType;

}

E’ necessario fare alcune premesse riguardanti alcune caratteristiche

generali possedute da tali metodi.

Alcuni metodi forniscono o accettano in ingresso un parametro di

tipo Vector. Il tipo Vector rappresenta una collezione di oggetti di

una qualsiasi classe, nel nostro caso si tratta della classe Attribute.

Un singolo vettore può contenere anche oggetti di classi diverse.

L’oggetto Vector è diverso da un array poiché permette di aumentare

dinamicamente la sua dimensione. Tale oggetto è supportato nella

programmazione Java.

⇒

⇒

⇒

Tutti i metodi descritti sono realizzati in base al meccanismo RMI

Remote Method Invocation, ovvero possono essere invocati in modo

remoto dai servizi. Ogni metodo quindi si preoccupa di gestire anche

le eccezioni legate al meccanismo di invocazione remota.

Ultima considerazione il Personalization Manager non presenta alcun

attributo ma mette a disposizione solo dei servizi

Successivamente vengono elencati e descritti i metodi della classe in

esame. I metodi possono essere suddivisi in tre sottoinsiemi: metodi relativi alle

general information, metodi relativi alle user preferences e metodi relativi alle

terminal capabilities. Inoltre viene previsto un metodo utile ai servizi per

autenticarsi..

public int getSessionID (string sessionID)

152

Il metodo viene invocato da un servizio per autenticarsi. A tale scopo

viene fornito come risultato il sessionID che il servizio stesso utilizzerà nelle

richieste successive al Personalization Manager.

General Information

public vector getGeneralUserInfo (string userID, string sessionID)

Il metodo ha lo scopo di fornire le informazioni contenute nelle General

User Information del Basic Profile dell'utente rispettando le General Privacy

Preferences. Restituisce attraverso il tipo Vector la lista di oggetti Attribute

contenente tali informazioni.

public vector getLogicalIdentifiers (string userID, string sessionID)

Il metodo ha lo scopo di fornire le informazioni contenute nelle Logico

Identifiers del Basic Profile dell'utente rispettando le General Privacy Preferences.

Restituisce attraverso il tipo Vector la lista di oggetti Attribute contenente tali

informazioni.

public vector getGeneralSubscriberInfo (string userID, string

sessionID)

Il metodo ha lo scopo di fornire le informazioni contenute nelle General

Subscriber Info del Basic Profile dell'utente rispettando le General Privacy

Preferences. Restituisce attraverso il tipo Vector la lista di oggetti Attribute

contenente tali informazioni.

User Preferences

public string getLanguage (string userID, string sessionID)

Il metodo ha lo scopo di fornire la lingua preferita di presentazione scelta

dall’utente; per far ciò prende come parametro di ingresso lo userID

(identificativo univoco dell’utente). Restituisce una stringa contenente la lingua.

153

public vector getHobbies (string userID, string sessionID)

Il metodo ha lo scopo di fornire la lista di hobbies definita dall’utente; per

far ciò prende come parametro di ingresso lo userID (identificativo univoco

dell’utente). Restituisce attraverso il tipo Vector la lista di oggetti Attribute

contenente gli hobbies.

public vector getSports (string userID, string sessionID)

Il metodo ha lo scopo di fornire la lista di sports definita dall’utente; per

far ciò prende come parametro di ingresso lo userID (identificativo univoco


contenente gli sports.

public vector getPreferredMedia(string userID, string sessionID)

Il metodo ha lo scopo di fornire la lista di tipi MIME definita dall’utente;

per far ciò prende come parametro di ingresso lo userID (identificativo univoco


contenente tali tipi.

public boolean isPushEnabled (string userID, string sessionID)

Il metodo ha lo scopo di fornire volontà dell’utente a ricevere contenuti

push; per far ciò prende come parametro di ingresso lo userID (identificativo

univoco dell’utente). Restituisce un valore booleano che indica la volontà di

ricevere tali contenuti se assume il valore ‘true’.

public boolean getAcceptColor (string userID, string sessionID)

Il metodo ha lo scopo di fornire volontà dell’utente a ricevere contenuti a

colori; per far ciò prende come parametro di ingresso lo userID (identificativo



public boolean getStreamingInterest (string userID, string sessionID)

154

Il metodo ha lo scopo di fornire volontà dell’utente a ricevere contenuti

video; per far ciò prende come parametro di ingresso lo userID (identificativo



Terminal Capabilities

public vector getUaprofInfo (string userID, string sessionID)

Il metodo ha lo scopo di fornire il modello del terminale utilizzato

dall’utente; per far ciò prende come parametro di ingresso lo userID

(identificativo univoco dell’utente). Restituisce una lista contenente due elementi

Attribute:

stringa contenente il nome del modello. ⇒

⇒ URL dell’UAProf repository

Grazie a queste informazioni il servizio può successivamente interrogare

l’UAProf repository.

Nel caso in cui il terminale dell’utente non supporti UAProf, le stringhe

saranno vuote ed il servizio utilizzerà i metodi successivi per conoscere le

capabilities del terminale utilizzato dall’utente.

public vector getHardwareCharacteristics (string userID, string

sessionID)

Il metodo ha lo scopo di fornire la lista di caratteristiche hardware

possedute dal terminale dell’utente come indicato da quest’ultimo; per far ciò

prende come parametro di ingresso lo userID (identificativo univoco dell’utente).

Restituisce attraverso il tipo Vector la lista di oggetti Attribute contenente le

caratteristiche hardware.

public vector getSoftwareCharacteristics (string userID, string

sessionID)

Il metodo ha lo scopo di fornire la lista di caratteristiche software

possedute dal terminale dell’utente come indicato da quest’ultimo; per far ciò

155


Restituisce attraverso il tipo Vector la lista di oggetti Attribute contenente le

caratteristiche software.

public vector getBrowserCharacteristics (string userID, string

sessionID)

Il metodo ha lo scopo di fornire il nome del browser e la sua versione

utilizzato dall’utente; per far ciò prende come parametro di ingresso lo userID

(identificativo univoco dell’utente). Restituisce attraverso il tipo Vector le

informazioni suddette.

public string getWapCharacteristics (string userID, string sessionID)

Il metodo ha lo scopo di fornire la versione WAP supportata; per far ciò


Restituisce attraverso una stringa l’informazione.

public vector getPushCharacteristics (string userID, string sessionID)

Il metodo ha lo scopo di fornire i tipi di informazioni supportate nel push;

per far ciò prende come parametro di ingresso lo userID (identificativo univoco

dell’utente). Restituisce attraverso Vector la lista dei tipi supportati.

public string getMMSCharacteristics (string userID, string sessionID)

Il metodo ha lo scopo di fornire la versione MMS supportata; per far ciò


Restituisce attraverso una stringa l’informazione.

Watcher SIP Handler

Il Watcher SIP Handler fornisce l’interfaccia dello User Profile Manager

verso il mondo SIP. Permette quindi di inviare sottoscrizioni verso il Context

156

Server, ai parametri di contesto degli utenti. Ha inoltre lo scopo di segnalare le

notifiche, inviate dal Context Server, utilizzando un’interfaccia notify presente

all’interno del Data Manager.

Il metodo offerto è il seguente:

subscribe(String sipUri, String via, String to, String from, String call-

ID, int c-Seq, String content-Type, int content-Length, String event, String

accept,

String contact, int expires )

Il metodo riceve tutti i parametri necessari per creare il messaggio

subscribe introdotto da SIMPLE.

User Request Manager

Lo User Request Manager è il sottosistema che si occupa di gestire la

comunicazione con l’utente a fronte di una richiesta di gestione delle proprie

informazioni di profilo. L’URM quindi avrà le funzionalità per implementare

l’interfaccia utente. Il progetto dell’interfaccia si basa sull’utilizzo di servlet. Tali

servlet avranno il compito di accettare informazioni dall’utente mediante la

composizione di opportuni form. Successivamente si utilizzeranno i metodi dello

User Profile Access Manager e del Data Manager rispettivamente per ottenere

l’autorizzazione ed eseguire effettivamente l’operazione richiesta.

Interazioni tra i sottosistemi

Nel presente paragrafo vengono illustrate le interazioni tra i sottosistemi

che permettono di realizzare le funzionalità principali previste dal sistema in

157

esame. Tali funzionalità vengono espresse attraverso l’uso di sequence diagram,

costrutti presenti all’interno del linguaggio UML utili per la descrizione del flusso

temporale delle operazioni.

Autenticazione utente

L’utente per usufruire dei servizi offerti dallo User Profile Manager deve

essere prima autenticato dal sistema. Ciò permette di inizializzare una sessione

assegnando un determinato securityID fornito dal protocollo SSL che rappresenta

l’identificativo dell’utente nelle richieste successive.

L’utente esegue la prima richiesta di un qualsiasi servizio offerto dalloUser

Profile Manager (1:http request). Lo User Request Manager (URM) attraverso le

API offerte dalle Java Servlet recupera il securityID. Utilizzando questa

informazione utilizza il metodo offerto dall’UPAM per ottenere lo userID

dell’utente (2:isUserAuthorised). Nel caso in cui l’utente non sia ancora

autenticato, l’UPAM non è in grado di restituire il suo userID. Infatti nella tabella

degli utenti autenticati, locale all’UPAM, non sarà presente nessuna voce relativa

a questo securityID. Ciò significa che l’utente non è ancora stato autenticato. A

tale proposito l’UPAM restituisce un appropriato messaggio

(3:AuthenticationNeeded]). Lo User Request Manager restituisce quindi una

pagina HTML contenente un form per l’autenticazione (4:HTML page for

Authentication). L’utente inserisce le sue credenziali (userID e password) nel

form e tramite il suo browser esegue la richiesta di autenticazione (5:http

request). La servlet recupera le credenziali dell’utente e il suo securityID, con tali

informazioni richiede l’autenticazione dell’utente all’UPAM

(6:userAuthenticate). A fronte di tale richiesta, l’UPAM verifica che l’utente è

registrato al sistema e quindi ha sottoscritto un contratto con l’operatore

(7:checkAuthenticationUserData). Se l’utente è registrato (8:[OK]), l’UPAM

richiede l’Operator Access List dell’utente (9:getUserAuthorization) al DM che

le fornisce come valore di ritorno del metodo (10:[OperatorAccessList]) e crea

con queste informazioni un entry per questo utente nella tabella degli utenti

autenticati (11:addUserToList). L’autenticazione dell’utente viene confermata

158

dall’UPAM all’URM (12:[OK]) che inoltrerà tale messaggio all’utente tramite

una pagina HTML (13:HTML page OK). A questo punto l’utente risulta

autenticato e quindi può di nuovo effettuare l’invocazione della funzionalità

(14:http request). Lo User Request Manager (URM), attraverso l’apposita

servlet, analizza la richiesta, ottiene il securityID e verifica se l’utente è

autenticato e autorizzato utilizzando l’interfaccia messa a disposizione

dell’UPAM (15:isUserAuthorised). L’UPAM effettua i passi necessari per la

verifica dell’autenticazione e dell’autorizzazione analizzando i dati nella sua

tabella che contiene le informazioni per l’autorizzazione di utenti già autenticati.

Il diagramma si riferisce al caso in cui tutto procede senza problemi e quindi viene

restituito lo userID (16:[userID]). Lo User Request Manager invoca quindi

l’apposito metodo per soddisfare la richiesta dell’utente (17:get/set operation). Il

Data Manager serve la richiesta e restituisce gli appositi dati ([18:DATA]). I dati

vengono inseriti in una pagina HTML e comunicati all’utente (19:[DATA]).

159

User Browser UPAM DMURM

11: addUserToList(securityID, userID, OperatorAccessList)

5: http request

6: userAuthenticate (userID, password, securityID)

1: http request

2: isUserAuthorized(securityID,componentName,accessMode)

3: [AuthenticationNeeded]

4: HTML page for Authentication

Servlet 1

Servlet 2

Servlet 1

12: [OK]

13: HTML page OK

14: http request


7: checkAuthenticationUserData (userID, password)

8: [OK]

16: [userID]

17: get/set operation

18: [DATA]

19: HTML page

9: getUserAuthorization(userID)

10: [OperatorAccessList]

Gestione dei component del profilo

I sequence diagram che vengono proposti successivamente riguardano la

possibilità, da parte dell’utente, di inserire, modificare e cancellare un’istanza di

un component del profilo utilizzando il suo browser per interagire con

160

l’interfaccia Web offerta dal sistema. I component a cui si riferisce il sequence

diagram sono in generale tutti quelli appartenenti al Basic Profile dell’utente e i

Service Profile. La gestione di Access List e Sub profile viene considerata a parte

poiché si prevedono particolari funzionalità.

Inserimento istanza

Il sequenze diagram qui presentato descrive l’inserimento di una nuova

istanza di un determinato component. Per far ciò, l’utente seleziona questo

servizio sulla pagina web visualizzata dal suo browser che quindi provvederà ad

inviare la relativa richiesta (1:http request) al sistema. Lo User Request Manager

(URM), attraverso l’apposita servlet, analizza la richiesta, ottiene il securityID e

verifica se l’utente è autenticato e autorizzato utilizzando l’interfaccia messa a

disposizione dell’UPAM (2:isUserAuthorised). L’UPAM effettua i passi

necessari per la verifica dell’autenticazione e dell’autorizzazione analizzando i

dati nella sua tabella che contiene le informazioni per l’autorizzazione di utenti

già autenticati. Il diagramma si riferisce al caso in cui tutto procede senza

problemi e quindi viene restituito lo userID (3:[userID]). A questo punto, lo User

Request Manager richiede la creazione di una nuova istanza al Data Manager

utilizzando lo userID e il nome dello specifico component (4:newInstance ). Il

Data Manager restituisce il frammento xml in cui è presente anche il riferimento

al foglio di stile (5:[XML fragment]). La servlet quindi invia la pagina sullo

standard output (6:HTML page based on XML fragment). La pagina consiste di

un form costituito dagli attributi del component in cui l’utente inserisce i

rispettivi valori. Appena l’utente ha concluso la compilazione del form, esegue la

richiesta di memorizzazione di tali informazioni attraverso lo User Browser

(7:http request). Lo User Request Manager esegue di nuovo la verifica di

autenticazione e autorizzazione, tramite UPAM (8:isUserAuthorised), e nel caso

non si verifichino problemi ottiene lo userID (9:[userID]). A questo punto lo

User Request Manager può invocare il metodo messo a disposizione dal Data

Manager per memorizzare la nuova istanza (10:setInstance). Il Data Manager

restituisce la conferma di aver effettuato l’operazione (11:[OK]) che viene

161

inoltrata anche all’utente tramite l’utilizzo di una pagina HTML (12:HTML page

OK).

User Browser URM UPAM DM

1: http request

3: [userID]

4: newInstance (userID,componentName)

5 : [XML fragment]

7: ht tp requ est

10: setInstance(userID,componentName,instance,instanceID)

11: [OK]

12 : HTML pag e OK

2: isUserAuthorised(security ID,co mp onen tNa me,a cce ssMode)

6: HTML page based on XML fragment

8: isUserAuthorised(security ID,co mp onen tNa me,a cce ssMode)

9: [userID]

Modifica istanza

Il diagramma seguente descrive la modifica di un’istanza esistente relativa

ad uno specifico component. L’utente seleziona questo servizio sulla pagina web

visualizzata dal suo browser che quindi provvederà ad inviare la relativa richiesta

(1:http request) al sistema. La servlet dello User Request Manager (URM),

ottiene il securityID e chiama in causa l’UPAM per la verifica dell’autenticazione

e dell’autorizzazione (2:isUserAuthorised). L’UPAM controlla se l’utente è

autenticato ed in tal caso né verifica l’autorizzazione analizzando i dati nella sua

tabella che contiene le Operator Access List di utenti già autenticati. Se tutto

procede senza problemi viene restituito lo userID (3:[userID]). A questo punto, lo

162

User Request Manager richiede la lista delle istanze del component al Data

Manager utilizzando lo userID e il nome dello specifico component

(4:getListComponent). Il Data Manager restituisce il frammento xml in cui è

presente anche il riferimento al foglio di stile (5:[XML fragment]). La servlet

quindi invia la pagina sullo standard output (6:HTML page based on XML

fragment). L’utente sceglie quale istanza modificare e quindi inoltra la richiesta

attraverso il suo browser. (7:http request). La servlet esegue di nuovo i controlli

su autenticazione e autorizzazione (8:isUserAuthorised) e ottiene come risultato,

se non vengono sollevati problemi, lo userID (9:[userID]). La servlet dello User

Request Manager richiede l’istanza selezionata dall’utente al Data Manager

(10:getInstance) che restituisce il frammento XML contenente i valori attuali

dell’istanza e l’associazione al foglio di stile (11:[XML fragment]). La servlet


fragment) che contiene un form con gli attuali valori dell’istanza. L’utente fa le

opportune modifiche e quando le conclude esegue la richiesta di memorizzazione

di tali informazioni attraverso lo User Browser (13:http request). Lo User

Request Manager esegue di nuovo la verifica di autenticazione e autorizzazione,

tramite UPAM (14:isUserAuthorised), e nel caso non si verifichino problemi

ottiene lo userID (15:[userID]). A questo punto lo User Request Manager può

invocare il metodo messo a disposizione dal Data Manager per memorizzare

l’istanza modificata (16: setInstance). Il Data Manager restituisce la conferma di

aver effettuato l’operazione (17:[OK]) che viene inoltrata anche all’utente tramite

l’utilizzo di una pagina HTML (18:HTML page OK).

163


1: http request

13: h ttp re quest

18: HTML page OK

3: [userID]


16: setInstance(userID,componentName,instance,instanceID)

17: [OK]

4: getListComponent(userID,componentName)

5: [XML fragment]


7: http request

10: getInstance (userID,componentName,instanceID)

12: HTML p age based on XML fragment

1 1: [XML fragment]


9: [userID]


15: [userID]

Cancellazione istanza

Il diagramma seguente descrive la cancellazione di un’istanza di uno

specifico component. L’utente esegue la richiesta di tale servizio (1:http request)

al sistema. La servlet dello User Request Manager (URM) ottiene il securityID e

usa l’interfaccia dell’UPAM per la verifica dell’autenticazione e

dell’autorizzazione. (2:isUserAuthorised). L’UPAM controlla se l’utente è

autenticato ed in tal caso né verifica l’autorizzazione analizzando i dati nella sua

164

tabella che contiene le Operator Access List di utenti già autenticati. Se l’utente è

autenticato e autorizzato viene restituito lo userID (3:[userID]). A questo punto,

lo User Request Manager richiede la lista delle istanze del component al Data

Manager utilizzando lo userID e il nome dello specifico component

(4:getListComponent). Il Data Manager restituisce il frammento xml in cui è

presente anche il riferimento al foglio di stile (5:[XML fragment]). La servlet


fragment). L’utente sceglie quale istanza cancellare e quindi inoltra la richiesta

attraverso il suo browser. (7:http request). Lo User Request Manager esegue di

nuovo la verifica di autenticazione e autorizzazione, tramite UPAM

(8:isUserAuthorised), e nel caso non si verifichino problemi ottiene lo userID

(9:[userID]). A questo punto lo User Request Manager può invocare il metodo

messo a disposizione dal Data Manager per eliminare l’istanza

(10:deleteSubProfile). Il Data Manager restituisce la conferma di aver effettuato

l’operazione (11:[OK]) che viene inoltrata anche all’utente tramite l’utilizzo di

una pagina HTML (12:HTML page OK).

165


1: http request

12: HTML page OK

7: http request

3: [userID]

2: isUserAuthorized(securi tyID,componentName,accessMode)

10: deleteInstance (userID,componentName,instanceID)

11: [OK]

4: getListComponent(userID,componentName)

5: [XML fragment]


8: isUserAuthorized(securi tyID,componentName,accessMode)

9: [userID]

Gestione dei sub profile

Il paragrafo illustra i messaggi scambiati tra i sottosistemi per offrire

all’utente le funzionalità di gestione dei sub profile. Vengono descritti i servizi di

gestione dei sub profile quindi inserimento modifica e cancellazione ma anche i

servizi per l’attivazione esplicita e automatica di un sub profile.

166

Inserimento sub profile

Il diagramma seguente descrive la definizione di un nuovo sub profile.

L’utente seleziona questo servizio sulla pagina web visualizzata dal suo browser

che invia la relativa richiesta (1:http request) al sistema. Lo User Request

Manager (URM), attraverso l’apposita servlet, analizza la richiesta, ottiene il

securityID e verifica se l’utente è già stato autenticato ed in tal caso se è

autorizzato alla gestione dei sub profile utilizzando l’interfaccia messa a




già autenticati. Se l’utente è stato autenticato e è in possesso dei privilegi

necessari viene restituito lo userID (3:[userID]). A questo punto, lo User Request

Manager richiede la creazione di un nuovo sub profile al Data Manager passando

come parametro lo userID (4:newSubProfile). Il Data Manager restituisce il

frammento xml in cui è presente anche il riferimento al foglio di stile (5:[XML

fragment]). La servlet quindi invia la pagina sullo standard output (6:HTML

page based on XML fragment). La pagina consiste di un form che ha un campo

associato ad ogni component in cui si può inserire l’istanza. Appena l’utente ha

concluso la compilazione del form, esegue la richiesta di memorizzazione di tali

informazioni attraverso lo User Browser (7:http request). Lo User Request

Manager esegue di nuovo la verifica di autenticazione e autorizzazione, tramite

UPAM (8:isUserAuthorised), e nel caso non si verifichino problemi ottiene lo

userID (9:[userID]). A questo punto lo User Request Manager può invocare il

metodo messo a disposizione dal Data Manager per memorizzare il nuovo sub

profile (10:setSubProfile). Il Data Manager restituisce la conferma di aver

effettuato l’operazione (11:[OK]) che viene inoltrata anche all’utente tramite


167

User Browser URM DM

1: ht tp reque st


7: ht tp reque st

4: newSubProfi le (userID)

5: [XML fragment]

UPAM

3: [userID]

11: [OK]

10: setSubProf i le (userID,subprof i leName,sub pro fi le )

2: isUse rAu th orised(securityID,compo nentName ,accessMo de)

8: isUse rAu th orised(securityID,compo nentName ,accessMo de)

9: [userID]

12: HTML page OK

Modifica sub profile

Il diagramma seguente descrive la modifica di un sub profile esistente.

L’utente richiede il servizio al sistema (1:http request). La servlet dello User

Request Manager (URM), ottiene il securityID e chiama in causa l’UPAM per la

verifica dell’autenticazione e dell’autorizzazione (2:isUserAuthorised). L’UPAM

controlla se l’utente è autenticato ed in tal caso né verifica l’autorizzazione

analizzando i dati nella sua tabella che contiene le Operator Access List di utenti

già autenticati. Se tutto procede senza problemi viene restituito lo userID

(3:[userID]). A questo punto, lo User Request Manager richiede la lista dei sub

profile esistenti al Data Manager utilizzando lo userID (4:getListSubProfile). Il

Data Manager restituisce il frammento xml in cui è presente anche il riferimento

al foglio di stile (5:[XML fragment]). La servlet quindi invia la pagina sullo

standard output (6:HTML page based on XML fragment). L’utente sceglie

quale sub profile modificare e quindi inoltra la richiesta attraverso il suo browser.

(7:http request). La servlet esegue di nuovo i controlli su autenticazione e

168

autorizzazione (8:isUserAuthorised) e ottiene come risultato, se non vengono

sollevati problemi, lo userID (9:[userID]). La servlet dello User Request Manager

richiede il sub profile selezionato dall’utente al Data Manager (10:getSubProfile)

che restituisce il frammento XML contenente i valori attuali dell’istanza e

l’associazione al foglio di stile (11:[XML fragment]). La servlet quindi invia la

pagina sullo standard output (12:HTML page based on XML fragment) che

contiene un form con le attuali istanze impostate per il sub profile. L’utente fa le

opportune modifiche e quando le conclude esegue la richiesta di memorizzazione

di tali informazioni attraverso lo User Browser (13:http request). Lo User

Request Manager esegue di nuovo la verifica di autenticazione e autorizzazione,

tramite UPAM (14:isUserAuthorised), e nel caso non si verifichino problemi

ottiene lo userID (15:[userID]). A questo punto lo User Request Manager può

invocare il metodo messo a disposizione dal Data Manager per memorizzare il sub

profile modificato (16: setSubProfile). Il Data Manager restituisce la conferma di

aver effettuato l’operazione (17:[OK]) che viene inoltrata anche all’utente tramite


169

User Browser URM DMUPAM

1: http reque st

10: getSubProfi le(userID,subprofi leName)

3: [userID]

2 : isUserAu th orised(securit yID,componentName,accessMode )

4: getListSubProfi le(use rID)

5: [XML fragment]

14: setSubProfile(userID,subprofi leName,subprofile)



13: http req uest

15: [OK]

7: http reque st

8: isUse rAu tho rised(securityID,compon entName,accessMode)

9: [userID]

11: [XML fragment]

16: HTML page OK

Cancellazione sub profile

Il diagramma seguente descrive la cancellazione di uno specifico sub

profile. L’utente esegue la richiesta di tale servizio (1:http request) al sistema. La

servlet dello User Request Manager (URM) ottiene il securityID e usa

l’interfaccia dell’UPAM per la verifica dell’autenticazione e dell’autorizzazione.

(2:isUserAuthorised). L’UPAM controlla se l’utente è autenticato ed in tal caso

né verifica l’autorizzazione analizzando i dati nella sua tabella che contiene le

Operator Access List di utenti già autenticati. Se l’utente è autenticato e

autorizzato viene restituito lo userID (3:[userID]). A questo punto, lo User

Request Manager richiede la lista dei sub profile esistenti al Data Manager

170

utilizzando lo userID dell’utente (4:getListSubProfile). Il Data Manager

restituisce il frammento xml in cui è presente anche il riferimento al foglio di stile

(5:[XML fragment]). La servlet quindi invia la pagina sullo standard output

(6:HTML page based on XML fragment). L’utente sceglie quale sub profile

cancellare e quindi inoltra la richiesta attraverso il suo browser. (7:http request).

Lo User Request Manager esegue di nuovo la verifica di autenticazione e

autorizzazione, tramite UPAM (8:isUserAuthorised), e nel caso non si

verifichino problemi ottiene lo userID (9:[userID]). A questo punto lo User

Request Manager può invocare il metodo messo a disposizione dal Data Manager

per eliminare il sub profile (10: deleteSubProfile). Il Data Manager restituisce la

conferma di aver effettuato l’operazione (11:[OK]) che viene inoltrata anche

all’utente tramite l’utilizzo di una pagina HTML (12:HTML page OK).


1 : ht tp reque st

12: HTML p age OK

6 : HTML page b ased o n XML f ra gment

7: http request

10: deleteSubProfile(userID,subprofi leName)

5: [XML fragment]

11 : [OK ]

3: [userID]

2: isUserAuthorised(se curit yID,com po nentNam e,accessMode )

4: getListSubProfile(userID)

8: isUserAuthorised(securityID,componentName,accessMode)

9: [userID]

171

Scelta esplicita dell’Active sub profile

Il diagramma seguente descrive i passi necessari all’utente per effettuare in

modo esplicito la scelta dell’Active sub profile. L’utente seleziona questo servizio

sulla pagina web visualizzata dal suo browser che invia la relativa richiesta

(1:http request) al sistema. Lo User Request Manager (URM), attraverso

l’apposita servlet, analizza la richiesta, ottiene il securityID e verifica se l’utente è

già stato autenticato ed in tal caso se è autorizzato alla gestione dei sub profile

utilizzando l’interfaccia messa a disposizione dell’UPAM (2:isUserAuthorised).

L’UPAM effettua i passi necessari per la verifica dell’autenticazione e

dell’autorizzazione analizzando i dati nella sua tabella che contiene le

informazioni per l’autorizzazione (Operator Access List) di utenti già autenticati.

Se l’utente è stato autenticato e è in possesso dei privilegi necessari viene

restituito lo userID (3:[userID]). A questo punto, lo User Request Manager

richiede la lista dei sub profile esistenti al Data Manager utilizzando lo userID

dell’utente (4:getListSubProfile). Il Data Manager restituisce il frammento xml

in cui è presente anche il riferimento al foglio di stile (5:[XML fragment]). La

servlet quindi invia la pagina sullo standard output (6:HTML page based on

XML fragment). L’utente sceglie quale sub profile far diventare attivo e quindi

inoltra la richiesta attraverso il suo browser. (7:http request).

Lo User Request Manager esegue di nuovo la verifica di autenticazione e




per attivare un nuovo sub profile (10:modifyActiveSubProfile). Il Data Manager



OK).

172

User Bro wse r URM DMUPAM

1: http request


7: http request

12: HTML pa ge OK

10: modifyActiveSubProfile(userID,subprofileName)

4: getListSubProfile(userID)

5: [XML fragmen t]

3: [userID]


11: [OK]


9: [userID]

Scelta automatica dell’Active sub profile

Il diagramma seguente descrive i passi necessari all’utente per settare gli

eventi di scelta automatica dell’Active sub profile. L’utente seleziona questo

servizio sulla pagina web visualizzata dal suo browser che invia la relativa

richiesta (1:http request) al sistema. Lo User Request Manager (URM),

attraverso l’apposita servlet, analizza la richiesta, ottiene il securityID e verifica se

l’utente è già stato autenticato ed in tal caso se è autorizzato alla gestione dei sub

profile utilizzando l’interfaccia messa a disposizione dell’UPAM

(2:isUserAuthorised). L’UPAM effettua i passi necessari per la verifica

dell’autenticazione e dell’autorizzazione analizzando i dati nella sua tabella che

contiene le informazioni per l’autorizzazione (Operator Access List) di utenti già

autenticati.

173

Se l’utente è stato autenticato in precedenza e può anche essere autorizzato

viene restituito lo userID (3:[userID]). A questo punto, lo User Request Manager

richiede la lista degli eventi di attivazione automatica al Data Manager utilizzando

lo userID dell’utente (4:getAutomaticAttivation). Il Data Manager restituisce il

frammento xml in cui è presente anche il riferimento al foglio di stile (5:[XML


page based on XML fragment). L’utente setta per gli eventi di modifica del

contesto a cui è interessato il valore del parametro e il sub profile da attivare nel

caso si verifichi l’evento quindi inoltra la richiesta attraverso il suo browser.





Manager per settare i nuovi eventi di attivazione automatica

(10:setAutomaticAttivation). Il Data Manager restituisce la conferma di aver

effettuato l’operazione (11:[OK]) che viene inoltrata anche all’utente tramite

l’utilizzo di una pagina HTML (12:HTML page OK)

.

174


1: http request


7: http request

12: HTML page OK

10: setAutomaticActivation(userID, AutomaticAttivation)

4: getAutomaticActivation(userID)

5: [XML fragment]

11: [OK]

3: [userID]


8: isUserAuthorised(securityID,co mponen tNa me,a ccessMo de)

9: [userID]

Gestione Access List

In questa sezione vengono descritti i sequence diagram relativi alla

gestione delle access list e delle tuple associate. Si presenta quindi lo scambio di

messaggi per l’inserimento la modifica e la cancellazione di access list e tuple.

Creazione Access List

Il diagramma seguente descrive la creazione di una nuova access list.



Manager (URM), attraverso l’apposita servlet, analizza la richiesta, ottiene il

securityID e verifica se l’utente è già stato autenticato ed in tal caso se è

autorizzato alla gestione delle access list relative utilizzando l’interfaccia messa a


175



già autenticati. Se l’utente è stato autenticato e è in possesso dei privilegi

necessari viene restituito lo userID (3:[userID]). A questo punto, lo User Request

Manager richiede la lista delle access list esistenti al Data Manager passando

come parametro lo userID (4:getAllAccessList). Il Data Manager restituisce il

frammento xml contenente le access list in cui è presente anche il riferimento al

foglio di stile (5:[XML fragment]). La servlet quindi invia la pagina sullo

standard output (6:HTML page based on XML fragment). L’utente sceglie di

inserire un’istanza ed esegue la richiesta il suo User Browser (7:http request). Lo

User Request Manager esegue di nuovo la verifica di autenticazione e




per creare una nuova access list (10:newAccessList). Il Data Manager restituisce

la conferma di aver effettuato l’operazione (11:[OK]) che viene inoltrata anche


176


1: http reque st

12: HTML page OK

3 : [use rID]

2: isUserAuthorized(securityID,compo nentName,accessM ode)

1 0: ne wAccessLi st (u serID,na meAccessLi st )

11 : [OK]

4: getAllAccessList (userID)

5: [XML fragment]


7: http reque st

8: isUserAuthorized(securityID,compo nentName,accessM ode)

9: [userID]

Modifica Access List

Il diagramma seguente descrive i messaggi scambiati tra i sottosistemi per

consentire all’utente la modifica di una access list. L’utente seleziona questo



attraverso l’apposita servlet, analizza la richiesta, ottiene il securityID e verifica se

l’utente è già stato autenticato ed in tal caso se è autorizzato alla gestione delle

access list relative utilizzando l’interfaccia messa a disposizione dell’UPAM

(2:isUserAuthorised). L’UPAM effettua i passi necessari per la verifica

dell’autenticazione e dell’autorizzazione analizzando i dati nella sua tabella che

contiene le informazioni per l’autorizzazione di utenti già autenticati. Se l’utente è

stato autenticato e è in possesso dei privilegi necessari viene restituito lo userID

(3:[userID]). A questo punto, lo User Request Manager richiede la lista delle

177

access list esistenti al Data Manager passando come parametro lo userID

(4:getAllAccessList). Il Data Manager restituisce il frammento xml contenente le

access list in cui è presente anche il riferimento al foglio di stile (5:[XML


page based on XML fragment). L’utente sceglie quale access list modificare e

soprattutto l’operazione da eseguire su questa access list. L’esempio qui riportato

riguarda la scelta dell’inserimento di un nuovo watcher ma anche altre operazioni

sono possibili su una access list come l’eliminazione di un watcher oppure

l’inserimento e l’eliminazione di una tupla dall’access list. Effettua quindi la

richiesta di inserimento di un nuovo watcher per mezzo del suo browser (7:http

request). Lo User Request Manager esegue di nuovo la verifica di autenticazione

e autorizzazione, tramite UPAM (8:isUserAuthorised), e nel caso non si



per creare una nuova access list (10:newWatcher). Il Data Manager restituisce la



178


1: http request

3: [userID]


4: getAl lAccessList (userID)

5: [XML fragment]


7: http request

11: [OK]

12: HTML page OK

10: newWatcher (userID,accessl istID,watcherID)


9: [userID]

Cancellazione Access List

Il diagramma seguente descrive la cancellazione di una access list.



Manager (URM), attraverso la servlet, analizza la richiesta, ottiene il securityID e

verifica se l’utente è già stato autenticato ed in tal caso se è autorizzato alla

gestione delle access list relative utilizzando l’interfaccia messa a disposizione

dall’UPAM (2:isUserAuthorised). L’UPAM effettua i passi necessari per la


179




richiede la lista delle access list esistenti al Data Manager passando come

parametro lo userID (4:getAllAccessList). Il Data Manager restituisce il

frammento xml contenente le access list in cui è presente anche il riferimento al

foglio di stile (5:[XML fragment]). La servlet quindi invia la pagina sullo

standard output (6:HTML page based on XML fragment). L’utente sceglie

quale access list eliminare ed esegue la richiesta attraverso il suo User Browser





Manager per eliminare l’access list (10:deleteAccessList). Il Data Manager



OK).

180

User Browser URM UP AM DM

1: h tt p req uest

13 : HT M L page response

3: [userID]

2: isUserAuthorized(securi tyID,com ponentNam e,accessM ode)

6: HT M L page based on XM L fragm ent

7: h tt p req uest

4 : getA l lAccessList(useID)

5: [XM L fragm ent]

8 : isUserAuthorized(securi tyID,com ponentNam e,accessM ode)

9: userID

10: de le teAccessList(userID,accessl istID)

11: [OK]

Creazione tupla

Il diagramma seguente descrive la creazione di una nuova tupla. L’utente

seleziona questo servizio selezionando un’apposita voce sulla pagina web

visualizzata dal suo browser che invia la relativa richiesta (1:http request) al

sistema. Lo User Request Manager (URM), attraverso una delle sue servlet,

analizza la richiesta, ottiene il securityID e verifica se l’utente è già stato

autenticato ed in tal caso se è autorizzato alla gestione delle access list relative

utilizzando l’interfaccia messa a disposizione dall’UPAM (2:isUserAuthorised).

L’UPAM effettua i passi necessari per la verifica dell’autenticazione e

181

dell’autorizzazione analizzando i dati nella sua tabella che contiene le

informazioni per l’autorizzazione di utenti già autenticati. Se l’utente è stato

autenticato e è in possesso dei privilegi necessari viene restituito lo userID

(3:[userID]). A questo punto, lo User Request Manager richiede la lista delle

tuple esistenti al Data Manager passando come parametro lo userID

(4:getAllTuple). Il Data Manager restituisce il frammento xml contenente le

access list in cui è presente anche il riferimento al foglio di stile (5:[XML


page based on XML fragment). L’utente sceglie di inserire una tupla ed esegue

la richiesta attraverso il suo User Browser (7:http request). Lo User Request

Manager esegue di nuovo la verifica di autenticazione e autorizzazione, tramite

UPAM (8:isUserAuthorised), e nel caso non si verifichino problemi ottiene lo

userID (9:[userID]). A questo punto lo User Request Manager può invocare il

metodo messo a disposizione dal Data Manager per creare una nuova access list

(10:newTuple). Il Data Manager restituisce la conferma di aver effettuato



182

User Browser UR M UPAM

1: h ttp request

11 : HT M L page wi th tup le ID

3: [userID]

2 : isUserAuthorized(securi tyID,com ponentNam e,accessM ode)

7: h ttp request

DM

4: ge tA l lT uple(userID)

5 : [XM L fragm ent]

6 : HT M L page based on XM L fragm ent

8: newT up le (userID )

9 : [t up leI D]

Modifica tupla

Si descrive lo scambio di messaggi che permette di offrire all’utente la

funzionalità di modifica di una tupla. L’utente seleziona questo servizio sulla

pagina web visualizzata dal suo browser che invia la relativa richiesta (1:http

request) al sistema. Lo User Request Manager (URM) ottiene il securityID,

grazie alle API (Application Program Interface) di Java Servlet e verifica se

l’utente è già stato autenticato e se ciò è avvenuto verifica se è autorizzato alla

gestione delle access list relative utilizzando l’interfaccia messa a disposizione

dell’UPAM (2:isUserAuthorised). L’UPAM effettua i passi necessari per la



183



richiede la lista delle tuple esistenti al Data Manager passando come parametro lo

userID (4:getAllTuple). Il Data Manager restituisce il frammento xml contenente

le access list in cui è presente anche il riferimento al foglio di stile (5:[XML


page based on XML fragment). L’utente sceglie quale access list modificare e

soprattutto l’operazione da eseguire su questa access list. L’esempio qui riportato

riguarda l’inserimento di un nuovo attributo ma si possono effettuare anche altre

operazioni come l’eliminazione di un attributo o la modifica del suo valore.

L’utente effettua quindi la richiesta di inserimento di un nuovo attributo per

mezzo del suo browser (7:http request). Lo User Request Manager esegue di

nuovo la verifica di autenticazione e autorizzazione, tramite UPAM

(8:isUserAuthorised), e nel caso non si verifichino problemi ottiene lo userID

(9:[userID]). A questo punto lo User Request Manager può invocare il metodo

messo a disposizione dal Data Manager per inserire un nuovo attributo nella tupla

(10:newAttribute). Il Data Manager restituisce la conferma di aver effettuato



184

User Browser UPM UPAM DM

1: http request

3: [userID]


4: getAl lTuple(userID)

5: [XML fragment]


12: HTML page OK

7: http request

10: newAttribute(userID,tupleID,attributeName)


9: [userID]

11: [OK]

Cancellazione tupla

Viene descritta la sequenza di messaggi scambiati tra i vari sottosistemi

per ottenere la cancellazione di una tupla esistente. L’utente seleziona questo



attraverso la servlet, analizza la richiesta, ottiene il securityID e verifica se

l’utente è già stato autenticato ed in tal caso se è autorizzato alla gestione delle

185

access list relative utilizzando l’interfaccia messa a disposizione dall’UPAM

(2:isUserAuthorised). L’UPAM verifica l’autenticazione e l’autorizzazione

analizzando i dati nella sua tabella che contiene le informazioni per

l’autorizzazione di utenti già autenticati. Se l’utente è stato autenticato e è in

possesso dei privilegi necessari viene restituito lo userID (3:[userID]). A questo

punto, lo User Request Manager richiede la lista delle tuple esistenti al Data

Manager passando come parametro lo userID (4:getAllTuple). Il Data Manager

restituisce il frammento xml contenente le tuple in cui è presente anche il

riferimento al foglio di stile (5:[XML fragment]). La servlet quindi invia la

pagina sullo standard output (6:HTML page based on XML fragment). L’utente

sceglie quale tupla eliminare ed esegue la richiesta attraverso il suo User Browser





Manager per eliminare la tupla (10:deleteTuple). Il Data Manager restituisce la



186


1: h tt p req uest

3 : [userID]


4: getAl lT up le (userID)

9 : de le teT uple(userID,tup le ID)

5: [XM L frag ment ]

6 : HT M L page based on XM L fragm ent

10: [OK]


8 : [userID]

11: HT M L page OK

Autenticazione servizio

Il servizio, per ottenere informazioni sul profilo dell’utente dallo User

Profile Manager, deve essere prima autenticato dal sistema. Ciò permette di

inizializzare una sessione assegnando un determinato sessionID che lo identifichi

nelle richieste.

Prima di eseguire qualsiasi richiesta il servizio richiede al sistema,

precisamente al Personalization Manager il sessionID fornendo le sue credenziali

(1:getSession). Il Personalization Manager richiede all’UPAM di autenticare il

servizio (2:serviceAuthenticate). A fronte di tale richiesta, l’UPAM verifica che

il servizio è registrato al sistema (3:checkAuthenticationServiceData). Se il

servizio è registrato (4:[OK]), l’UPAM richiede i privilegi di accesso per il

187

servizio (5:getServiceAuthorization) al DM che le fornisce come valore di

ritorno del metodo (6:[AccessListforService]). Visto che il servizio è stato

autenticato con successo viene calcolato l’identificativo della sessione per il

servizio (7:sessionIDCalculation). Con queste informazioni viene definita un

entry per il servizio nella tabella dei servizi autenticati (8:addServiceToList).

L’autenticazione del servizio viene confermata dall’UPAM all’URM restituendo

il sessionID (9:[sessionID]) che viene inoltrato al servizio che l’autenticazione è

andata a buon fine (10:[sessionID]).

Servizio PM UPAM DM

1: getSession(serviceID,secretToken)2: serviceAuthenticate(serviceID,secretToken)

3: checkAuthenticationServiceData(serviceID,secretToken)

4: [OK]

5: getServiceAuthorization(serviceID)

6: [AccessListforService]

7: sessionIDCalculation()

8: addServiceToList(sessionID,serviceID,AccessListforService)

9: [sessionID]

10: [sessionID]

Richiesta informazioni da parte di servizi

Il seguente sequence diagram descrive le interazioni dei sottosistemi a

fronte della richiesta di informazioni da parte di un servizio. L’esempio riguarda

la richiesta di informazioni sulla volontà dell’utente di ricevere contenuti push ma

la sequenza di operazioni può essere valida per la richiesta di qualsiasi tipo di

informazione di profilo a disposizione dei servizi. Il servizio richiede

l’informazione associando il sessionID (1:isPushEnabled). Il Personalization

188

Manager verifica che il servizio sia autenticato e autorizzato

(2:isServiceAuthorised). A fronte di una tale richiesta l’UPAM esegue gli

appositi controlli e restituisce la risposta (3:[OK]). Il PM può quindi inoltrare la

richiesta del servizio al Data Manager (4:getInstance) che restituisce il

frammento XML del component richiesto (5:[XML fragment]). Il

personalization manager può a questo punto prelevare l’informazione dal

frammento XML e fornirla al servizio (6:DATA).

Service Personalization Manager

UPAM DM

1: isPushEnabled(userID,sessionID)

6: [DATA]

2: isServiceAuthorised(securi tyID,componentName)

4: getInstance(userID,componentName,0)

5: [XML fragment]

3: [OK]

Notifica cambiamenti dei parametri di contesto

La notifica dei cambiamenti dei parametri di contesto viene comunicata

dal Watcher SIP Handler che rappresenta l’interfaccia del sistema verso il mondo

SIP. Quando si verifica il cambiamento di un parametro di contesto a cui lo User

Profile Manager si è sottoscritto, il Watcher SIP Handler comunica questa

informazione invocando il metodo notify (1: notify). Il metodo recupera il nuovo

sub profile che deve diventare attivo e successivamente invoca il metodo che

189

gestisce tutte le modifiche da apportare nel cambiamento del sub profile attivo

(2:modifyActiveSubProfile).

WatcherSIPHandler DM

1: noti fy

2: m odi f yActi veSub Pro fi le (use rI D, subp rofi leN am e)

190

8. Conclusioni e sviluppi futuri

Conclusioni

Il lavoro di tesi ha avuto come obiettivo la progettazione di un sistema di

gestione delle informazioni di profilo di un utente, denominato User Profile

Manager (UPM), in uno scenario UMTS e la determinazione di un processo di

personalizzazione utilizzabile dai servizi per soddisfare le esigenze dell’utente,

basato sulle informazioni di profilo sia statiche che dinamiche trattate all’interno

del sistema di gestione. Le informazioni statiche vengono comunicate al sistema

direttamente dall’utente mentre le informazioni dinamiche vengono fornite in

parte dal Context Service ed in parte dall’utente stesso.

La fase progettuale è stata preceduta da una analisi molto accurata dei

requisiti di utenti e servizi nello scenario UMTS. Ciò si è reso necessario a causa

dell’assenza di studi precedenti su tali problematiche

Gli utenti possono interagire con il sistema attraverso un’interfaccia Web

mentre ai servizi viene offerta la possibilità di invocare metodi remoti da cui

prelevare le informazioni che caratterizzano l’utente. Il sistema proposto permette

all’utente di gestire:

191

Informazioni generali tra le quali compaiono i suoi estremi, gli

identificativi all’interno della rete (numero di telefono, SIP URL, ecc) e le

informazioni di sottoscrizione come ad esempio il tipo di contratto.

⇒

Preferenze service-independent e service-dependent. Le prime sono le

preferenze oggettive dell’utente che non siano relative ad un determinato

servizio ad esempio l’interesse a ricevere streaming video sul suo

terminale. Le seconde costituiscono le preferenze dell’utente verso uno

specifico servizio, denominate in genere Service Profile. I Service Profile

vengono descritti quando possibile attraverso schemi standard esistenti (es

XML schema di MPEG-7 per servizi che forniscono contenuti

multimediali).

⇒

⇒

⇒

Terminal Capabilities, nel caso in cui il suo terminale non supporti la

tecnica UAProf (User Agent Profile) per la fornitura di tali informazioni.

Anche nel caso sia supportata la soluzione UAProf, il sistema offre

comunque ai servizi l’informazione riguardante l’indirizzo dell’UAProf

repository in cui sono contenute le terminal capabilities e del modello del

terminale. I servizi attraverso l’invocazione del metodo GET del

protocollo http, possono recuperare il file XML relativo al terminale.

Informazioni di contesto. Il sistema offre la possibilità di configurare i

privilegi di accesso alle informazioni di contesto che vengono richieste da

altri utenti e servizi interessati attraverso il Context Server. Inoltre, il

sistema fornisce un’interfaccia Web che permette l’inserimento di

informazioni di contesto fornite direttamente dall’utente che il Context

Server non è in grado di recuperare.

Il sistema proposto grazie all’interazione con il Context Server offre

inoltre la possibilità di associare le preferenze dell’utente a specifici valori dei

parametri di contesto. In questo modo, le preferenze dell’utente verranno settate

automaticamente in base al valore di un determinato attributo di contesto.

Le funzionalità definite in precedenza sono state progettate rispettando i

requisiti fondamentali di sicurezza, imposto dalla gestione di informazioni

riservate dell’utente, ed estendibilità, imposto dall’esigenza dei servizi di

192

introdurre nuovi parametri di profilo all’interno del processo di personalizzazione.

Il requisito di sicurezza dei dati è stato rispettato prevedendo l’utilizzo del

protocollo SSL (Socket Security Layer) quindi il trasferimento di dati cifrati sia

rispetto agli utenti sia rispetto ai servizi. Tali entità inoltre prima di poter usufruire

delle funzionalità del sistema di gestione del profilo devono essere autenticati e

autorizzati. L’estendibilità del profilo è stata garantita scegliendo una

rappresentazione dei dati basata su XML che consente la facile introduzione di

nuove informazioni di profilo.

Alcuni aspetti del lavoro di tesi sono stati inseriti nelle pubblicazioni

“Service personalization and beyond” presentata nel 41st Telecomunication

Congress 2002 e “Context aware mobile services in 4G wireless systems”

presentata in ECWT 2002 (European Conference on Wireless Tecnology).

Sviluppi futuri

Gli sviluppi futuri riguardano principalmente la capacità di individuare e

gestire nuove informazioni di profilo che possono migliorare il grado di

personalizzazione dei servizi rivolti ad utenti di reti di terza generazione. Studi

successivi possono essere indirizzati verso la descrizione della popolazione di cui

fa parte un utente. Tale elemento può rilevarsi molto importante ai fini della

personalizzazione. Nel caso in cui un utente sia circondato da una popolazione

sufficientemente omogenea, un servizio sottoscritto da un utente potrebbe essere

pubblicizzato a membri della popolazione e addirittura personalizzato con

successo utilizzando le stesse preferenze dell’utente che lo ha già sottoscritto.

Altre informazioni che sollevano particolare interesse nell’ambito della

personalizzazione dei servizi sono quelle che descrivono i comportamenti passati

dell’utente anche se tuttora non vengono prese in considerazione nello standard

3GPP (3rd Generation Partnership Project). A tale scopo si devono prevedere

agenti intelligenti che riescano a supportare l’utente nel raggiungimento dei suoi

scopi futuri.

193

A XML Schema

L’appendice illustra gli XML Schema individuati per i component di

profilo individuati nel progetto del sistema di gestione e illustrati nel capitolo 6.

Gli Schema che vengono descritti riguardano il Basic Profile (General Information

e User Preferences) e il Context Profile (Access list, tuple e terminal capabilities).

Viene inoltre descritta la struttura del sub profile di un utente. La struttura XML

dei Service Profile non viene descritta poiché questa è dipendente dal servizio a

cui si riferisce.

General Information

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified">

<xsd:simpleType name="componentType">

<xsd:restriction base="xsd:string">

<xsd:enumeration value="GeneralUserInformation"/>

<xsd:enumeration value="LogicalIdentifiers"/>

<xsd:enumeration value="GeneralSubscribe Information"/>

<xsd:enumeration value="UserPreferences"/>

<xsd:enumeration value="AccessList"/>

<xsd:enumeration value="ServiceProfile"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:element name="GeneralInformation">

194

<xsd:complexType>

<xsd:sequence>

<xsd:element name="GeneralUserInformation">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Name" type="xsd:string"/>

<xsd:element name="Address" type="xsd:string"/>

<xsd:element name="Age" type="xsd:string"/>

<xsd:element name="Sex" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="LogicalIdentifiers">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MSISDN" type="xsd:string"/>

<xsd:element name="SIPURL" type="xsd:string"/>

<xsd:element name="PrivacyUserIdentity" type="xsd:string"/>

<xsd:element name="e-mail" type="xsd:string"/>

<xsd:element name="presenceURL" type="xsd:string"/>

<xsd:element name="personalNumber" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="GeneralSubscribeInformation">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="Name" type="xsd:string"/>

<xsd:element name="billingInfo" type="xsd:string"/>

<xsd:element name="level" type="xsd:string"/>

<xsd:element name="dateofExpire" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="AuthenticationData">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="userID" type="xsd:string"/>

<xsd:element name="password" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="OperatorAccessList">

<xsd:complexType>

<xsd:sequence>

195

<xsd:element name="component" minOccurs="0"

maxOccurs="unbounded">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="componentType">

<xsd:attribute name="mode" type="xsd:string"

use="required"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="userID" type="xsd:string" use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:schema>

User Preferences




<xsd:simpleType name="languageType">


<xsd:enumeration value="italian"/>

<xsd:enumeration value="english"/>

<xsd:enumeration value="german"/>

<xsd:enumeration value="spanish"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:simpleType name="contentType">


<xsd:enumeration value="yes"/>

<xsd:enumeration value="no"/>

</xsd:restriction>

196

</xsd:simpleType>

<xsd:element name="userpreferences">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="instance" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="language" type="languageType"

minOccurs="0" maxOccurs="1"/>

<xsd:element name="hobby" type="xsd:string" minOccurs="0"

maxOccurs="5"/>

<xsd:element name="sport" type="xsd:string" minOccurs="0"

maxOccurs="5"/>

<xsd:element name="mimetype" type="xsd:string" minOccurs="0"

maxOccurs="unbounded"/>

<xsd:element name="pushinterest" type="contentType"

minOccurs="0"/>

<xsd:element name="acceptcolor" type="contentType"

minOccurs="0"/>

<xsd:element name="streaminginterest" type="contentType"

minOccurs="0"/>

</xsd:sequence>

<xsd:attribute name="instanceID" type="xsd:unsignedByte"

use="required"/>

<xsd:attribute name="activationFlag" type="xsd:boolean"

use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>


</xsd:complexType>

</xsd:element>

</xsd:schema>

Sub Profile






197

<xsd:element name="SubProfile">

<xsd:complexType>

<xsd:sequence>


<xsd:complexType>

<xsd:sequence>

<xsd:element name="UserPreferences" minOccurs="0">

<xsd:complexType>


use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="AccessList" minOccurs="0"


<xsd:complexType>

<xsd:attribute name="accesslistID" type="xsd:unsignedByte"

use="required"/>

</xsd:complexType>

</xsd:element>

<xsd:element name="ServiceProfile" minOccurs="0"


<xsd:complexType>


use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

<xsd:attribute name="subprofileName" type="xsd:string" use="required"/>


use="required"/>

<xsd:attribute name="defaultSubProfileFlag" type="xsd:boolean"

use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>


</xsd:complexType>

</xsd:element>

</xsd:schema>

198

Access List




<xsd:simpleType name="presenceURLType">


<xsd:pattern value="pres:.*@.*"/>

</xsd:restriction>

</xsd:simpleType>

<xsd:element name="AccessList">

<xsd:complexType>

<xsd:sequence>


<xsd:complexType>

<xsd:sequence>

<xsd:element name="watcher" type="presenceURLType"

minOccurs="0" maxOccurs="unbounded"/>

<xsd:element name="tupleID" type="xsd:unsignedByte"

minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

<xsd:attribute name="accesslistID" type="xsd:unsignedByte"

use="required"/>

<xsd:attribute name="accesslistName" type="xsd:string" use="required"/>


use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>


</xsd:complexType>

</xsd:element>

</xsd:schema>

199

Tuple




<xsd:element name="Tuple">

<xsd:complexType>

<xsd:sequence>


<xsd:complexType>

<xsd:sequence>

<xsd:element name="attribute" type="xsd:string" minOccurs="0"

maxOccurs="1"/>

<xsd:element name="value" type="xsd:string" minOccurs="0"

maxOccurs="1"/>

</xsd:sequence>

<xsd:attribute name="tupleID" type="xsd:unsignedByte" use="required"/>

</xsd:complexType>

</xsd:element>

</xsd:sequence>


</xsd:complexType>

</xsd:element>

</xsd:schema>

Eventi per attivazione automatica




<xsd:element name="eventNotification">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="event" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base="xsd:string">

200

<xsd:attribute name="value" type="xsd:string"

use="required"/>

<xsd:attribute name="subprofileName" type="xsd:string"

use="required"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

</xsd:sequence>


</xsd:complexType>

</xsd:element>

</xsd:schema>

Terminal Capabilities




<xsd:element name="CapabilitiesDescription">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="UAProfRepositoryInformation" minOccurs="0"

maxOccurs="1">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="UAProfURL" type="xsd:string"/>



<xsd:element name="terminalModel" type="xsd:string"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="HardwarePlatform" minOccurs="0" maxOccurs="1">

<xsd:complexType>

<xsd:sequence>

201

<xsd:element name="ColorCapable" type="xsd:boolean"


<xsd:element name="ImageCapable" type="xsd:boolean"


<xsd:element name="ScreenSize" type="xsd:string" minOccurs="0"

maxOccurs="1"/>

<xsd:element name="SoundOutputCapable" type="xsd:boolean"


<xsd:element name="TextInputCapable" type="xsd:boolean"


<xsd:element name="VoiceInputCapable" type="xsd:boolean"


</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="SoftwarePlatform" minOccurs="0" maxOccurs="1">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="JavaEnabled" type="xsd:boolean"


<xsd:element name="OSName" type="xsd:string" minOccurs="0"

maxOccurs="1"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="browserUA" minOccurs="0" maxOccurs="1">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="BrowserName" type="xsd:string"


<xsd:element name="BrowserVersion" type="xsd:string"


</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="WapCharacteristics" minOccurs="0" maxOccurs="1">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="WapVersion" type="xsd:string" minOccurs="0"

maxOccurs="1"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="PUSHCharacteristics" minOccurs="0" maxOccurs="1">

<xsd:complexType>

<xsd:sequence>

202

<xsd:element name="PushAccept" type="xsd:string" minOccurs="0"

maxOccurs="1"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="MMSCharacteristics" minOccurs="0" maxOccurs="1">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="MMSVersion" type="xsd:string" minOccurs="0"

maxOccurs="1"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>


</xsd:complexType>

</xsd:element>

</xsd:schema>

203

B Profilo UAProf

Nella seguente appendice vengono riportate le informazioni di profilo che

descrivono le caratteristiche di reti e terminali individuate in UAProf (User Agent

Profile) come viene descritto in [UAProf] e [MMS].

Caratteristiche Hardware

BluetoothProfile: E’ il profilo Bluetooth cosi come viene definito nelle

specifiche Bluetooth

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

ColorCapable: Indica se il dispositivo è in grado di visualizzare contenuti

a colori

CPU: Indica il nome ed il modello della CPU del terminale

ImageCapable: Indica se il dispositivo è in grado di visualizzare immagini

InputCharSet: E’ la lista dei set di caratteri supportati dal terminale

Keyboard: E’ il tipo di tastiera di cui il terminale è fornito. Ad esempio

"Qwerty", "PhoneKeypad"

Model: E’ il nome del modello di terminale ed è assegnato dal costruttore

NumberOfSoftKeys: E’ il numero di ‘soft keys’ disponibili sul terminale

OutputCharSet: E’ la lista dei tipi di carattere che il terminale può

visualizzare. Ad esempio “US-ASCII"

204

PixelAspectRatio: E’ il rapporto del numero di pixel in larghezza sul

numero di pixel in altezza

⇒

PointingResolution: E’ il tipo di risoluzione supportata dal dispositivo. Ad

esempio "Character","Line" o "Pixel"

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

ScreenSize: E’ la grandezza del display del terminale in unità di pixel. Ad

esempio "160x160","640x480"

ScreenSizeChar: E’ la grandezza del dispositivo in unità di caratteri. Nel

calcolo di questa grandezza si usa il font con larghezza piu alta. Ad

esempio"16x8"

SoundOutputCapable: Indica se il dispositivo è in grado di generare suoni.

Assume un valore boolean "Yes", "No".

StandardFontProportional: Indica se il font standard del dispositivo è

proporzionale. Assume un valore boolean "Yes", "No".

TextInputCapable: Indica se il dospositivo supporta l’itroduzione di testo

alfanumerico. Assume un valore boolean "Yes", "No".

Vendor: E’ il nome del costruttore del telefono

VoiceInputCapable: Indica se il dispositivo è in grado di ricevere voce in

ingresso. Assume un valore boolean "Yes", "No".

Caratteristiche Software

AcceptDownloadableSoftware: Indica se l’utente può accettare il

download del software. Assume un valore boolean "Yes", "No"

AudioInputEncoder Lista di encoder per l’input audio

CcppAccept: Lista di tipi supportati di contenuti suppostati dal terminale.

Ad esempio "text/html"

CcppAccept-Charset: Lista di set di caratteri supportati. Ad esempio "US-

ASCII"

205

CcppAccept-Language: Lista di lingue preferite per la presentazione dei

documenti

⇒

DownloadableSoftwareSupport: Lista di tipi di contenuti eseguibili

suppostati dal dispositivo. Ad esempio "application/x-msdos-exe"

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

JavaEnabled: Indica se il dispositivo ha a disposizione la Java Virtual

Machine. Assume un valore boolean "Yes", "No"

JavaPlatform: E’ la lista di piattaforme Java installate sul dispositivo. Ad

esempio “J2SE/1.0-compatible”

JVMVersion: Lista di Java virtual machine installate sul terminale. Ad

esempio "SunJRE/1.2"

MExEService: E’ una serie di parametri che descrivono l’applicazione

MExE

OSName: Nome del sistema operativo del dispositivo. Ad esempio

"Windows NT"

OSVendor: Nome del fornitore del sistema operativo. Ad esempio "Apple"

OSVersion: Versione sistema operativo

RecipientAppAgent: User agent associato l’attuale richiesta. Ad esempio

"BrowserMail"

VideoInputEncoder: Lista di encoder video in input supportati dal

dispositivo. Ad esempio "MPEG-1","MPEG-2"

Caratteristiche di rete

CurrentBearerService: E’ il bearer sul quale è syaya aperta l’attuale

sessione dell’utente

SecuritySupport: Lista di meccanismi di cifratura supportati. Ad esempio

"WTLS-1", WTLS-2"

SupportedBearers: Lista di beare supportati dal dispositivo.Ad esempio

"GPRS","SMS"

206

SupportedBluetoothVersion: E’ la versione Bluetooth supportata ⇒

Caratteristiche del Browser

BrowserName: Nome del browser associato con la richiesta. Ad esempio

"Mozilla"

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

BrowserVersion: Versione del browser

DownloadableBrowserApps: Lista di contenuti eseguibili che è in grado di

ricevere. Ad esempio "application/x-java-vm/java-applet"

FramesCapable: Indica se il browser è capace di visualizzare frame.

Assume un valore boolean "Yes", "No"

HtmlVersion: Versione di HTML supportata dal browser

JavaAppletEnabled: Indica se il browser è in grado di supportare le Java

applet. Assume un valore boolean "Yes", "No"

JavaScriptEnabled: Indica se il browser è in grado di supportare le Java

applet. Assume un valore boolean "Yes", "No"

JavaScriptVersion: Versione del linguaggio JavaScript supportato dal

browser

PreferenceForFrames: Indica la prefernza dell’utente a ricevere contenuti

HTML contenti frame

XhtmlVersion: Versione di XHTML del browser

XhtmlModules: Lista di moduli XHTML supportati dal browser. Ad

esempio "XHTML1-struct"

207

Caratteristiche WAP

WapDeviceClass: Classificazione del dispositivo basata sulle capabilities

WAP come definito nelle specifiche specifiche WAP 1.1

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

⇒

WapVersion: Versione WAP supportata

WmlDeckSize: Massima grandezza di un deck WML che può essere

scaricata

WmlScriptLibraries: Lista di librerie obbligatorie e opzionali supportate.

WmlScriptVersion: Lista di versioni di WMLScript supportate

WmlVersion: Lista delle versioni del linguaggio WML supportate

WtaiLibraries: Lista di librerie WTAI supportate comuni e specifiche della

rete

WtaVersion: Versione del WTA

Caratteristiche Push

Push-Accept: Lista di tipi di contenuti che il dispositivo supporta per push

Push-Accept-Charset: Lista set di caratteri che il dispositivo supporta per il

push

Push-Accept-Language: Lista di lingue preferite per la presentazione di

documenti

Push-Accept-AppID: Lista di applicazioni che il dispositivo supporta per il

push

Push-MsgSize: Massima taglia in bytes un messaggio push

Push-MaxPushReq: Massimo numero di richieste push che il dispositivo

può gestire

208

Caratteristiche MMS

MmsMaxMessageSize: E’ la massima taglia di un messaggio multimediale

in byte

⇒

⇒

⇒

⇒

⇒

⇒

MmsMaxImageResolution: E’ la massima grandezza di un’immagine in

unità di pixel (horizontal x vertical)

MmsCcppAccept: Tipi di contenuti supportati. Ad esempio “image/jpeg”,

oppure “audio/wav”

MmsCcppAcceptCharSet: E’ la lista del set di caratteri disponibile per il

terminale. Ad esempio “US-ASCII”

MmsCcppAcceptLanguage: Lista di lingue preferite

MmsVersion: E’ la versione MMS supportata

209

Bibliografia

[3GPPTS22.071] 3GPP TS 22.071 V5.0.0 (2001-12). 3rd

Generation Partnership Project, Technical

Specification Group Services and System

Aspects; ”Location Service. Service

Description”. Stage 1 Release 5

[3GPPTS22.121] 3GPP TS 22.121 V5.1.0 (2001-06). 3rd



Aspects, Service aspects; “The Virtual Home

Environment”. Release 5

[3GPPTS22.141] 3GPP TS 22.141 V5.0.0 (2001-06). 3rd



Aspects, Service aspects; “Presence

Service”. Stage 1 Release 5

[3GPPTS23.060] 3GPP TS 23.060 V5.0.0 (2001-01). 3rd



210

Aspects, “General Packet Radio Service

(GPRS). Service description”. Stage 2

Release 5

[3GPPTS23.240] 3GPP TS 23.240 V0.3.0 (2001-12). 3rd

Generation Partnership Project; Technical


Aspects; “3GPP Generic User Profile –

Architecture”. Stage 2 Release 5

[3GPPTS23.241] 3GPP TS 23.241 V0.2.1 (2001-12).3rd


Specification Group Terminals; “3GPP

Generic User Profile. Data Description

Framework”. Stage 2 Release 5

[3GPPTS23.271] 3GPP TS 23.271 V5.1.0 (2001-12).3rd



Aspects; “Functional stage 2 description of

LCS”. Release 5

[3GPPTR23.841] 3GPP TR 23.841 V1.1.0 3rd Generation

Partnership Project, Technical Specification

Group Services and System Aspects;

“Presence Service; Architecture and

Functional Description”. Release 6

[3GPPTR23.922] 3GPP TR 23.922 V1.0.0 (1999-10) 3rd



211

Aspects; “Architecture for an all IP

network”.

[3GPPTS29.002] 3GPP TS 29.002 V5.1.0 (2002-03) 3rd


Specification Group Core Network; “Mobile

Application Part (MAP) Specification”.

Release 5

[CCPP] G.Klyne, F.Reynolds, C.Woodrow, H. Ohto

“Composite Capabiluity/Preference Profile:

Structure and vocabularies”

http://www.w3.org/TR/CCPP-struct-

vocab

[Coo] The Apache XML Project, “How to develop Web Applications”.

http://xml.apache.org/cocoon/tutorial.

html

[Dam] Andrea D’Ambrogio, Dispense di Ingegneria del software, Università di

Roma Tor Vergata

[Fow] Martin Fowler. UML distilled. Addison-Wesley, 1997.

[Harms] D.Harms “JSP Servlet e MySQL”. Mc Graw

Hill, 2001

[Java99] C.S. Horstmann, G.Cornell “Java 2 i

fondamenti“. The Sun Microsystem Press,

1999

212

[JXML] Sun Microsystems, Java Technology and

XML. http://java.sun.com/xml

[McLau] B.McLaughlin, “Java and XML”. O-

REILLY, 2000

[Moul] M. Mouly, M.B. Pautet “The GSM system for mobile communications”.

Celle & Sys, 1993.

[MPEG2001] MPEG Committee Draft ISO/IEC CD 15938-

5 Information Technology – Multimedia

Content Description Interface – part 5:

“Multimedia Description Schemes”. version

0.1, chapter 15, 2001

[MMS] WAP Forum “MMS Client Transaction”

Gennaio 2002

[Pars] J.D. Parsons, J.G. Gardiner, “Mobile Communication Systems”. Halsted

Press, Glasgow, 1989.

[Pres] Roger S. Pressman, “Principi di Ingegneria del software”. McGraw-Hill,

1997

[RDF] O. Lassila, R. Swick “Resource Description Framework (RDF) Model and

Syntax Specification”. World Wide Web

Consortium Recommendation, February

1999.

[RDFSc] D.Brickley, R.V.Guha “RDF Schema

Specification”. World wide Web

Consortium, 1999

213

[rfc1945] Request for Comment 1945, ”Hypertext

Transfer protocol 1.0” , T. Berners-Lee, R.

Fileding, H. Frystyk

[rfc2068] Request for Comment 2068, “Hypertext

Transfer protocol 1.1” , T. Berners-Lee, R.

Fileding, H. Frystyk, J. Gettys, J. Mogul

[rfc2543] Request for Comment 2543, “Sip: Session

Initiator Protocol”;

http://www.ietf.org/rfc.html

[rfc2616] Request for Comment 2616, Hypertext

Transfer protocol 1.1 , T. Berners-Lee, R.

Fileding, L. Masinter, P.Leach H. Frystyk, J.

Gettys, J. Mogul

[rfc2778] Request for Comment 2778, "A Model for

Presence and Instant Messaging";


[rfc2779] Request for Comment 2779, ”Instant

Messaging/Presence Protocol Requirement";


[Ris] G.Risso, “Programmazione distribuita”. Apogeo, 1999

[rmi] Remote Method Invocation Tutorial, Sun

http://java.sun.com/products/jdk/1.2/docs/gui

de/rmi/spec/rmiTOC.doc.html

214



[simple02] Internet Engineering Task Force, IETF daft,

“Session Initiation Protocol (SIP) Extensions

for Presence”, Aprile 2002

[Swadley96] Richard K. Swadley. “Java unleashed”.

Sams Publishing, 1996.

[Sas] Mikio Sasaki, Shum Ichi, Koichi Emura, Charis Cristopoulos, Francois

Preteux “Study of MPEG-7 Mobile

Requirements & Applications” ISO/IEC,

2001

[SSL] Internet Engineering Task Force, IETF daft, “The SSL Protocol”,

Novembre 1996

[T2GUP] Ericsson “MMS parameter belonging to

Generic User Profile” 3GPP Joint ad-hoc on

Generic User Profile, Sophia Antipolis,

Febbraio 2001

[Tan] Andrew s. Tanenbaum, “Reti di Computer”, Prentice Hall International,

1997

[Tom] The Jakarta Project, Apache Tomcat http://apache.org/tomcat/

[UAProf] WAP Forum “UAProf” Ottobre 2001

[UMTS2000] “The UMTS Third Generation Market –

Structuring the Service Revenue

Opportunities.” Report No. 9, UMTS Forum,

2000.

215

216

[vanSet] M.Van Setten “Personalized Information

Systems”, Telematica Instituut, 2001

[Will] Heather Williamson, “La guida completa XML”. Mc Graw Hill, 2001

Progetto di un sistema per la personalizzazione dei ...teca.elis.org/1134/Tesi_Cianfanelli.pdf ·...

Documents

Transcript of Progetto di un sistema per la personalizzazione dei ...teca.elis.org/1134/Tesi_Cianfanelli.pdf ·...