STUDIO ED IMPLEMENTAZIONE DI UN ALGORITMO PER LA GESTIONE … › ~ghini › didattica › sistemimobili › ... · 6.6 Schermata dell’applicazione SuperSu, con la lista delle applica-zioni

Alma Mater Studiorum · Universita di Bologna

SCUOLA DI SCIENZE

Corso di Laurea Magistrale in Informatica

STUDIO ED IMPLEMENTAZIONE DIUN ALGORITMO PER LA GESTIONEDELL’HANDOVER IN AMBIENTE

ANDROID

Relatore:Chiar.mo Prof.Vittorio Ghini

Presentata da:Luca Milioli

Sessione IIIAnno Accademico 2013/2014

Al professore Ghini per avermi dato questa opportunita

Alla mia famiglia, per il supporto e la pazienza

Ad Alessandra, per tutto il resto

”The question of whether a computer can think is no more

interesting than the question of whether a submarine can

swim.”

Edsger W. Dijkstra

(tratto da ”The threats to computing science” del 1984)

Introduzione

La telefonia, inventata nella prima meta dell’ottocento e considerata una

delle pietre miliari dello sviluppo della nostra societa. La possibilita di co-

municare con persone che sono molto distanti da noi ha dato vita a nuovi

fenomeni sociali e soprattutto tecnologici. Conseguentemente alla sua nasci-

ta, il progresso ha portato alla realizzazione di strumenti sempre piu evolu-

ti, arrivando ad una svolta con la telefonia mobile, l’antenata degli odierni

smartphone. Questi ultimi fondono le funzionalita di un computer con la

semplicita di utilizzo di un normale telefono cellulare, offrendo quindi la pos-

sibilita di connettersi a tecnologie di accesso diverse e non piu solo alle comuni

celle telefoniche GSM. Lo sviluppo tecnologico ha quindi portato il concetto

di connettivita anche su questi dispositivi, fino ad arrivare al giorno d’oggi

in cui la sfida, che si presta a molteplici ambiti di utilizzo, e quella di fornire

continuita di connessione e quindi dei servizi basati su di essa.

A tal proposito il processo atto a risolvere tale problema e chiamato handover

e deve essere in grado di gestire l’eterogeneita delle diverse tipologie di rete

a cui un dispositivo puo connettersi. Tale sfida si presenta molto complessa,

vi sono attualmente molte soluzioni in fase di sviluppo che pero non hanno

ancora trovato un riscontro talmente positivo da essere riportate sui disposi-

tivi in commercio. Inoltre tali soluzioni sono orientate, per facilita di studio,

a tecnologie poco diffuse come WiMax. Proprio per questi ultimi aspetti

si e deciso di progettare ed implementare una soluzione che dia una buona

base di partenza per risolvere tale problema in ambiente Android, affinche

si possa fornire uno strumento in grado di gestire il processo di handover su

i

ii INTRODUZIONE

dispositivi estremamente diffusi sul mercato tecnologico globale, in partico-

lare modo, a qualsiasi dispositivo mobile appartenente a questa categoria,

indipendentemente dalle specifiche tecniche.

Con questa tesi si vuole, prima di tutto, raccontare il processo di ana-

lisi iniziale descrivendo lo scenario in cui si propone tale soluzione, parten-

do quindi dal Capitolo 1. Successivamente nel Capitolo 2, si entra piu nel

dettaglio descrivendo gli obbiettivi del progetto, anticipando ed analizzan-

do brevemente gli aspetti piu importanti della soluzione proposta, nonche

ponendo l’attenzione sulle tecnologie attualmente discusse nello stato del-

l’arte. Prima di considerare gli aspetti progettuali ed implementativi, nel

Capitolo 3, si analizzano gli strumenti e le tecnologie utilizzati per sviluppa-

re l’applicazione. Si passa poi alla discussione delle fase di progettazione ed

implementazione, nei Capitoli 4 e 5, dove sono presentati dapprima gli algo-

ritmi dal punto di vista teorico e successivamente gli aspetti implementativi

piu importanti, ponendo l’attenzione sulle problematiche scaturite durante

la scrittura vera e propria dell’applicazione. Quest’ultima viene presentata

nel Capitolo 6, evidenziando le funzionalita messe a disposizione dell’utente.

L’elaborato prosegue poi, con un’analisi dei risultati ottenuti dalla soluzione

proposta, considerando inoltre qual’e il contributo offerto rispetto a quanto

presente nello stato dell’arte attuale, rispettivamente nei Capitoli 7 e 8.

Infine si conclude con una visione d’insieme del lavoro svolto, ponendo l’at-

tenzione su quali possono essere gli sviluppi futuri.

Indice

Introduzione i

1 Scenario 1

1.1 Lato client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Lato server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Campi di utilizzo . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Vita quotidiana . . . . . . . . . . . . . . . . . . . . . . 6

1.3.2 Internet of things . . . . . . . . . . . . . . . . . . . . . 6

1.3.3 Ambito medico . . . . . . . . . . . . . . . . . . . . . . 7

2 Obbiettivo del progetto 9

2.1 Lato client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Lato server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 Stato dell’arte . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.1 MIH - Media Indipendent Handover . . . . . . . . . . . 31

2.3.2 Esempio nel mondo reale: integrazione tra WLAN e

WiMax . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.3 Preconfigurazione dell’indirizzo IP e preautenticazione 37

2.3.4 Problematiche irrisolte . . . . . . . . . . . . . . . . . . 39

2.3.5 Conclusioni sullo stato dell’arte . . . . . . . . . . . . . 41

2.4 Contributo del lavoro . . . . . . . . . . . . . . . . . . . . . . . 42

3 Strumenti e tecnologie 45

3.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

iii

iv INTRODUZIONE

3.2 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2.1 ADT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.2.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.2.3 RootTools e SupportLibrary . . . . . . . . . . . . . . . 62

3.3 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.4 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.5 RootToolKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.5.1 L’applicazione SuperSu . . . . . . . . . . . . . . . . . . 68

3.6 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.6.1 Scansioni Wi-Fi in Android . . . . . . . . . . . . . . . 75

3.7 Connessione dati del provider telefonico . . . . . . . . . . . . . 76

3.7.1 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

3.7.2 GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.7.3 UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.7.4 LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.7.5 HSPA e HSPDA . . . . . . . . . . . . . . . . . . . . . 87

3.8 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4 Progettazione 93

4.1 Lato client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

4.1.1 Gestione del file build.prop . . . . . . . . . . . . . . . . 97

4.1.2 Progettazione dell’interfaccia utente . . . . . . . . . . . 98

4.1.3 Gestione delle fasi di vita di un activity . . . . . . . . . 99

4.1.4 Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.1.5 Broadcast Receivers ed Intent Broadcast . . . . . . . . 102

4.2 Lato server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.2.1 Base di dati . . . . . . . . . . . . . . . . . . . . . . . . 103

4.2.2 Oggetti WifiList e UmtsList . . . . . . . . . . . . . . . 106

4.2.3 Algoritmo di predizione dell’Oracolo . . . . . . . . . . 110

4.2.4 Creazione della lista delle connessioni candidate . . . . 116

4.2.5 Problemi emersi durante la progettazione . . . . . . . . 118

INDICE v

5 Implementazione 125

5.1 Panoramica del sistema . . . . . . . . . . . . . . . . . . . . . . 125

5.2 Problemi emersi durante l’implementazione . . . . . . . . . . . 129

5.2.1 Attivazione e disattivazione del GPS . . . . . . . . . . 129

5.2.2 Arrotondamento dei reali in SQLite . . . . . . . . . . . 132

5.2.3 Mancanze strutturali del file wpa supplicant.conf . . . 137

5.3 Dettagli implementativi . . . . . . . . . . . . . . . . . . . . . 138

5.3.1 Utilizzo degli Intent in casi particolari . . . . . . . . . 138

5.3.2 Implementazione dello ScanService . . . . . . . . . . . 141

5.3.3 Calcolo delle distanza tra due punti rappresentati con

coordinate GPS . . . . . . . . . . . . . . . . . . . . . . 144

5.3.4 Rooting dei dispositivi . . . . . . . . . . . . . . . . . . 145

5.3.5 Gestione del file wpa supplicant.conf . . . . . . . . . . 151

6 L’applicazione 163

7 Valutazione e prove sperimentali 173

7.1 Valutazione del comportamento in scenari caratteristici . . . . 174

7.2 Valutazione dell’algoritmo di predizione . . . . . . . . . . . . . 181

7.3 Presupposti all’integrazione con ABPS . . . . . . . . . . . . . 184

8 Contributo del lavoro 187

9 Conclusioni e sviluppi futuri 189

Bibliografia 191

Ringraziamenti 197

Elenco delle figure

1.1 Schema funzionale del progetto. . . . . . . . . . . . . . . . . . 3

2.1 Diffusione delle versioni di Android nel mercato attuale. . . . . 9

2.2 Caso in cui non si ha alcuna copertura. . . . . . . . . . . . . . 13

2.3 Caso in cui si ha la copertura solo di access point wireless. . . 14

2.4 Caso in cui si ha solo copertura da parte delle celle telefoniche. 14

2.5 Caso in cui si ha una transizione da una tipologia di connes-

sione ad un’altra. . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Fasi principali del processo di handover. . . . . . . . . . . . . 19

2.7 Handover basato sulla potenza del segnale rilevato. Il punto

L1 indica l’esatta posizione in cui deve avvenire il cambio di

rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8 Handover basato sulla potenza del segnale e su un valore di

threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.9 Handover basato sul concetto di isteresi. . . . . . . . . . . . . 22

2.10 Handover basato su treshold ed isteresi combinati. . . . . . . . 22

2.11 Metodi di controllo del processo di handover. . . . . . . . . . . 25

2.12 Struttura del Location Area Identifier (LAI), formata dal CC,

MNC e LAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.13 Copertura dell’UMTS in Italia. . . . . . . . . . . . . . . . . . 29

2.14 Softer handover. . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.15 Scenario con reti Wi-Fi e WiMax integrate. . . . . . . . . . . 35

2.16 Esempio di scenario eterogeneo con reti all-IP dette NGN. . . 40

vii

viii ELENCO DELLE FIGURE

3.1 Schema dell’architettura di Android. . . . . . . . . . . . . . . 48

3.2 Il LogCat visto da Eclipse e da linea di comando. . . . . . . . 52

3.3 La funzionalita di monitoraggio del traffico di rete con DDMS. 54

3.4 Ciclo di vita di una activity. . . . . . . . . . . . . . . . . . . . 59

3.5 Schermate di avvio del Nexus root toolkit e di VRoot (ultima

versione in inglese in alto e versione utilizzata in cinese in basso). 68

3.6 Popolazione dei satelliti dei governi statunitense e cinese nel

Dicembre 2011. . . . . . . . . . . . . . . . . . . . . . . . . . . 89

3.7 Una stazione di controllo. . . . . . . . . . . . . . . . . . . . . 90

4.1 WorkFlow semplificato dell’applicazione dal punto di vista

dell’interazione dell’utente. . . . . . . . . . . . . . . . . . . . . 95

4.2 Diagramma ER della basi di dati utilizzata nell’applicazione. . 103

4.3 In evidenza le chiavi primarie ed esterne delle tabelle che

costituiscono la base di dati. . . . . . . . . . . . . . . . . . . . 106

5.1 Londra e Cardiff allineate in orizzontale per via della stessa

latitudine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

5.2 Seattle e San Francisco allineate in verticale per via della stessa

longitudine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5.3 L’applicazione KingUser dopo aver effettuato il rooting del

dispositivo Sony Xperia L. . . . . . . . . . . . . . . . . . . . . 148

6.1 Diffusione di Android in Europa, America ed Italia. . . . . . . 164

6.2 Interfaccia dell’applicazione al primo avvio. . . . . . . . . . . . 165

6.3 Informazioni visualizzate dall’utente durante il funzionamento

dell’applicazione (compresi eventuali errori) e toast coi per-

messi di root. . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

6.4 Schermata dell’applicazione con scansioni ed utilizzo della base

di dati attivi e la possibilita di utilizzare l’Oracolo. . . . . . . 167

6.5 Schermata dell’applicazione una volta richiamata dopo il pri-

mo avvio (a). Applicazione che risulta come servizio in back-

ground (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

INDICE ix

6.6 Schermata dell’applicazione SuperSu, con la lista delle applica-

zioni che hanno richiesto i permessi di root (a). L’applicazione

ConnectionPointAnalyzer richiede i permessi di root (b). . . . 169

6.7 Menu contestuale (a) da cui poter visualizzare l’help, il file

di log e poter uscire dall’applicazione. Finestra dell’help (b).

Finestra evocata da una intent per aprire il file di log (c). File

di log (d). Dialog per uscire dal programma (e). . . . . . . . . 170

7.1 Passaggio alla modalta ONLY WIFI dopo aver forzato una

connessione wireless con successo. . . . . . . . . . . . . . . . . 175

7.2 Passaggio alla modalita UMTS AND GPS dopo non aver tro-

vato connessioni wireless utili, ma prevedendo la presenza di

una cella telefonica nella direzione dello spostamento. . . . . . 177

7.3 Passaggio dalla modalita ONLY WIFI alla modalita ONLY UMTS

prevedendo una buona cella candidata a cui connettersi. . . . 178

7.4 Inizialmente il Nexus 5 rileva una buona rete wireless e forza

la connessione ad essa. . . . . . . . . . . . . . . . . . . . . . . 179

7.5 L’Oracolo prevede che la connessione wireless verra persa e in

assenza di altre connessioni accettabili dello stesso tipo attiva,

la corretta interfaccia. . . . . . . . . . . . . . . . . . . . . . . 180

7.6 L’Oracolo considera le possibili celle a cui connettersi, con

scarsi risultati per via del loro segnale debole. Viene inoltre

eseguito un ultimo tentativo con l’interfaccia wireless. . . . . . 180

7.7 All’utente viene notificato che tutti i possibili tentativi per

garantire la continuita di connessione non sono andati a buon

fine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Elenco delle tabelle

3.1 Differenze tra WEP e WPA. . . . . . . . . . . . . . . . . . . . 73

3.2 Confronto tra classe 8 e classe 10 di GPRS. . . . . . . . . . . . 80

5.1 Confronto tra coordinate GPS rilevate da Android e quelle

salvate con SQLite. . . . . . . . . . . . . . . . . . . . . . . . . 133

7.1 Numero di pacchetti e tempo impiegato per inviare il medesi-

mo file a parita di condizioni, con e senza l’ausilio dell’Oracolo. 183

xi

Capitolo 1

Scenario

L’uso degli smartphone e della loro capacita di accedere alla rete sono

diventati parte integrante della vita quotidiana. Il progetto sviluppato serve

a risolvere o quanto meno a rendere meno fastidioso il problema del cambio di

interfaccia di connessione qualora ci sia assenza del segnale o scarsa potenza

di quest’ultimo.

Tale situazione, viene chiamata fase (o processo) di handover e puo avve-

nire per diversi motivi, che possono essere suddivisi tra quelli che richiedono

l’utilizzo della medesima interfaccia e quelli che invece ne richiedono una

diversa. Di seguito qualche esempio:

• Transizione da una cella ad un’altra dello stesso operatore: in tal caso

l’interfaccia utilizzata e sempre quella della connessione dati della sim.

• Uscita dall’area di copertura di una cella del proprio operatore, in as-

senza di altre celle del medesimo operatore. In tal caso si deve passare

dall’interfaccia della connessione dati della sim a quella wireless.

• Uscita dall’area di copertura di un access point wireless ed ingresso in

una rete diversa con la medesima tecnologia: in questo caso l’interfaccia

da utilizzare rimane la stessa.

Per risolvere tale problema e quindi necessario un’applicazione o un ser-

vizio che venga eseguito in background sullo smartphone, in grado di capire

1

2 1. Scenario

in base alla circostanza e magari alla posizione in cui si trova cosa fare, in

modo automatico, senza che l’utente si preoccupi di attivare o disattivare le

opportune interfacce. Inoltre si vuole proporre una soluzione che sia sensibile

al problema dell’utilizzo energetico.

Si e quindi partiti dal lavoro di tesi di Paladino e Somenzi [1], colleghi

della laurea triennale. Tale lavoro effettuava un mapping degli access point

salvando i risultati delle reti rilevate dal dispositivo in file XML.

Partendo da tale base si e quindi pensato di progettare un’applicazione o

servizio, che per prima cosa, oltre a cio, metta a disposizione la stessa fun-

zionalita per le celle telefoniche, aggiungendovi anche le informazioni relative

alle coordinate GPS. Tale caratteristica e fondamentale in quanto e utile a

creare una base di dati che verra utilizzata in seguito per scegliere la mossa

migliore da fare in base alla circostanza in cui ci si trova. Oltre a cio l’ap-

plicazione prevede anche una funzionalita in grado di risolvere, se attivata

dall’utente, il problema dell’handover citato in precedenza.

Quindi il progetto prevede due meccanismi principali, il primo chiamato

ConnectionPointAnalyzer che rileva le reti wireless, le celle dell’operatore e

le coordinate GPS salvando il tutto in file XML. Il secondo, chiamato Oraco-

lo, e il piu importante ed utilizza le informazioni ricavate dalle scansioni per

attivare preventivamente l’interfaccia corretta ed instaurare una connessione

prima che quella attuale venga persa. Tali moduli dell’applicazione possono

essere visti rispettivamente come il lato client e server. Inoltre l’applicazione

ha anche un’utilita piu estesa di quanto spiegato fino ad ora, infatti i da-

tabase creati da ogni singolo dispositivo possono essere uniti per creare una

mappatura ad ampio raggio, che puo essere fornita con l’installazione del pro-

gramma stesso. La Figura 1.1 mostra la struttura in modo semplificato del

progetto, da notare infatti che un dispositivo puo simultaneamente utilizzare

sia il modulo ConnectionPointAnalyzer che il modulo Oracolo.

Nelle seguenti sezioni vengono spiegati piu in dettaglio i due moduli sem-

pre dal punto di vista delle funzionalita senza entrare nei meriti di progetta-

zione vera e propria, che verra trattata successivamente nel Capitolo 4.

1.1 Lato client 3

Figura 1.1: Schema funzionale del progetto.

1.1 Lato client

Come scenario per il lato client si puo pensare ad una situazione quoti-

diana di tutti i giorni, ovvero un utilizzatore di un dispositivo, per esempio

un turista o un lavoratore durante il tragitto per recarsi in un luogo di in-

teresse o sul posto di lavoro. In entrambi i casi e possibile che l’utente stia

usando la connessione alla rete, dovuta per esempio ad una chiamata VoIP o

per qualsiasi altro motivo, in quanto uno smartphone odierno senza l’accesso

alla rete perde di fatto buona parte delle sue caratteristiche smart.

Purtroppo pero, le connessioni dati mobili abituali ad eccezione della nuo-

va tecnologia 4G offrono traffico limitato e velocita solitamente inferiori a

quelle di una rete ADSL, quindi l’utente sarebbe avvantaggiato ad utilizzare

un access point wireless situato nelle vicinanze. Inoltre, il dare la preceden-

4 1. Scenario

za all’utilizzo di reti wireless porta a vantaggi considerevoli sia per quanto

riguarda il risparmio energetico che l’aspetto economico. Risulta quindi evi-

dente favorire le connessioni Wi-Fi se possibile, in quanto, alcuni dispositivi

sul mercato, come per esempio certi modelli di tablet, non supportano la

connessione dati dei provider telefonici.

Fatte le dovute osservazioni e tornando all’utilizzatore citato ad inizio

della sezione, cio che si vuole garantire e la continuita di connessione, tenen-

do presente quanto appena detto e senza che esso debba interagire con le

interfacce del dispositivo. Per fare cio sara necessario spedire i risultati delle

scansioni al lato server, ovvero all’Oracolo utilizzando in caso di necessita an-

che le coordinate GPS per avere informazioni piu dettagliate sulla posizione

quando le sole reti rilevate non bastano.

Quindi, per quanto riguarda il lato client, le caratteristiche che si vogliono

fornire sono la continuita di connessione, la possibilita di raccogliere e cata-

logare le informazioni da inserire nella base di dati affinche il funzionamento

dell’Oracolo sia reso piu efficiente.

1.2 Lato server

Con il termine lato server, dal punto di vista dell’utente, in questo scenario

si ha un servizio che riceve come input i risultati delle scansioni effettuate

dal dispositivo e restituisce come risultato l’azione piu appropriata per la

circostanza in cui ci si trova, per esempio, l’accensione o il spegnimento di

un’interfaccia, o l’instaurazione di una connessione ad una particolare rete

mentre si sta utilizzando un’altra interfaccia in previsione di una perdita di

connettivitia. Tali funzionalita vengono offerte considerando sempre i costi

e il risparmio energetico citati precedentemente.

Piu in dettaglio, per lato server si intendono due entita fondamentali: la

base di dati e l’Oracolo vero e proprio. La prima serve per collezionare i

dati rilevati dal dispositivo, ricordando che il progetto inziale di Paladino e

Somenzi salvava tali dati in file XML locali. Cio che si vuole fare e creare

1.2 Lato server 5

una base di dati risultante dall’unione delle scansioni di piu dispositivi mo-

bili che utilizzano questo servizio, in modo da avere la maggior quantita di

informazioni possibile da fornire all’Oracolo, o fornirne una il piu completa

possibile per una determinata zona di interessa in base alle necessita dell’u-

tente. L’Oracolo fa sempre parte del lato server e prende la corretta decisione

in base alla circostanza in cui l’utente si trova, da qui ne deriva il suo nome,

in quanto viene visto come un servizio che in qualsiasi situazione e a cono-

scenza dell’azione migliore da fare per garantire la continuita di connessione

e porre rimedio al problema degli intervalli di non disponibilita .

Prima di vedere in quali campi di utilizzo potrebbe essere applicato questo

progetto e bene considerarlo in combinazione con un’architettura chiamata

ABPS (Always Best Packet Switching) [2]. Infatti il progetto di tesi mette

a disposizione funzionalita utili come la creazione di una base di dati par la

previsione di quali interfacce verranno utilizzate e la predizione degli sposta-

menti da parte dell’utente. Il cambio di interfaccia pero comporta l’utilizzo

di un nuovo indirizzo IP, a questo punto entra in gioco ABPS.

Quest’ultimo ha come pregio quello di rendere il cambiamento di indirizzo IP

trasparente sia all’utente che sta utilizzando il dispositivo stesso che all’altro

nodo con cui si sta comunicando. Senza entrare nel dettaglio, ABPS prevede

l’utilizzo di un proxy server esterno alle due reti in cui sono presenti rispetti-

vamente le due persone facenti parte della comunicazione. Il nodo mobile a

sua volta ha un proxy lato client. Se il nodo mobile manda un messaggio di

registrazione (prima di avviare la conversazione vera e propria), tale messag-

gio passa per il proxy del nodo mobile, arriva al proxy server che nasconde la

posizione reale del nodo mobile al server dedicato del servizio che si sta usan-

do (per esempio un server di Skype o Ekiga ecc ecc..). Viene quindi illuso il

server del servizio facendogli credere che il nodo mobile si trovi in realta dove

e situato il proxy server nel mezzo. Quando il CN (Correspondent Node),

ovvero l’altro utente che fa parte alla conversazione, risponde, il messaggio

viene mandato al proxy server nel mezzo in quanto crede che quest’ultimo

sia l’altro conversante. Ogni volta che il proxy server client (quello presente

6 1. Scenario

sul nodo mobile) si accorge che quest’ultimo ha cambiato locazione e magari

rete, avverte il proxy server nel mezzo. Quindi il CN continua a parlare col

proprio conversante, i cui spostamenti (cambi di indirizzo IP) sono pero resi

trasparenti. Tale soluzione, presenta comunque delle restrizioni: il prox ser-

ver deve essere fuori da qualsiasi firewall e il passaggio forzato dei messaggi

attraverso esso aumenta la latenza. Inoltre i dispositivi mobile devono essere

in grado di supportare un proxy client.

1.3 Campi di utilizzo

Dopo aver analizzato lo scenario relativo al progetto senza entrare nel-

lo specifico dei dettagli progettuali ed implementativi, verranno elencati i

possibili campi di utilizzo di tale applicazione.

1.3.1 Vita quotidiana

Come accennato in precedenza all’inizio del capitolo, l’utilita principale

del progetto risiede nel poter essere utilizzato dai possessori di smartphone

nella vita di tutti i giorni, garantendo la continuita di connessione dei dispo-

sitivi in modo da evitare i classici problemi di servizi non raggiungibili o non

disponibili. In questo ambito, gli utilizzi possono essere piu svariati, chiama-

te VoIP, consultazione del Web, applicazioni che richiedono servizi real-time

ecc ecc ...

1.3.2 Internet of things

Il termine Internet Of Things [3] abbreviato in IoT indica l’estensione di

Internet al mondo degli oggetti ed e quindi possibile immaginarlo come un’e-

voluzione dell’uso della rete. Per esempio si puo immaginare una situazione

in cui le sveglie suonano prima quando c’e traffico nel tragitto che l’utente

deve fare per recarsi a lavoro e nello stesso istante, dato il cambiamento di

piano, anche il microonde scalda anticipatamente la colazione.

1.3 Campi di utilizzo 7

In breve l’obbiettivo che si vuole raggiungere con l’avvento dello IoT e quello

che il mondo elettronico possa tracciare una mappa del mondo reale, fornendo

utilita in vari ambiti, soprattutto nella vita quotidiana

Partendo da tale principio, il progetto puo o essere utilizzato per diversi

motivi tutti derivanti dall’utilizzo della rete che deve essere quindi disponibile

ovunque ci si trovi. Un esempio come quello precedente del traffico e quan-

tomai realistico per un utente che sta viaggiando, magari per un convegno a

cui non puo mancare. Durante il tragitto l’applicazione mantiene sempre la

connessione stabile garantendo quindi di reperire le informazioni relative al

traffico e modificare se necessario l’itinerario da percorrere.

1.3.3 Ambito medico

In America da qualche anno e diventato ordinario un servizio che utilizza

i dispositivi mobili per far sı che un paziente venga monitorato a distanza dal

medico curante [4][5]. Questo avviene grazie ad una comunicazione da parte

del dispositivo mobile dei parametri d’interesse del paziente al dispositivo

del medico, in modo che possa essere sempre monitorato. In caso di allerta,

ovvero di parametri vitali o di interesse per la patologia del paziente non

corretti, lo smartphone avverte direttamente il medico o il pronto soccorso

senza ricorrere all’utilizzo diretto del paziente in quanto magari colto da un

malore non potrebbe nemmeno essere in grado di contattare chi di dovere in

tempo. Diventa evidente come sia fondamentale anche in questo caso l’uti-

lizzo della rete, nonche la sua continua reperibilita, in quanto non inviare dei

dati o inviarne solo in parte potrebbe essere origine di allerte non giustificate

o di ritardi nei soccorsi. A tale scopo l’applicazione discussa in questa tesi e

uno strumento utile a garantire continuita del servizio.

Capitolo 2

Obbiettivo del progetto

In questo capitolo ci si occupa di descrivere quali sono gli obbiettivi del

progetto, analizzandone il funzionamento ad alto livello e senza entrare nelle

scelte implementative che verranno discusse nei Capitoli 4 e 5.

Per prima cosa e bene specificare che l’applicazione e stata pensata ed

implementata per funzionare con le versioni di Android [6] che ricoprono

la maggior parte del mercato attuale (vedi Figura 2.1), ovvero Gingerbread

JellyBean e KitKat in tutte le loro release.

Figura 2.1: Diffusione delle versioni di Android nel mercato attuale.

Infine e stata testata anche su Lollipop (versione 5.0) seppure ci siano

alcuni comportamenti da sistemare in quanto tale sistema operativo e stato

9

10 2. Obbiettivo del progetto

rilasciato durante la stesura della tesi e a progetto gia ultimato.

A tal proposito, per quest’ultima versione di sistema operativo, sono stati

sistemati i problemi piu importanti emersi durante l’esecuzione dell’appli-

cazione, tralasciando alcune migliorie in quanto tale release, all’epoca, era

ancora in stato embrionale e di conseguenza soggetta a molti aggiornamenti.

Inoltre, riguardo a Lollipop, si deve fare un’ulteriore precisazione, in quan-

to Google ha iniziato a gestirvi l’handover. Nonostante cio, in rete, vi sono

numerose discussioni dove l’utenza si lamenta della funzionalita chiamata ag-

gressive wifi to cellular handover che dovrebbe attivare l’interfaccia wireless

qualora venga rilevata una rete a cui ci si potrebbe connettere.

Questo premette che tale meccanismo non gestisce ancora l’interfaccia dei

dati mobili. L’utenza si lamenta del fatto che nonostante vengano selezio-

nate le opportune impostazioni per prediligere anche le reti wireless con un

segnale debole, il sistema operativo rimane per quasi tutto il tempo connes-

so alle celle telefoniche, vanificando quelli che sono i pregi della tecnologia

wireless (velocita maggiori a costi minori nonche un consumo della batteria

ridotto).

Per quanto riguarda la scelta del sistema operativo per cui sviluppare

l’applicazione si e ristretta ad Android e IoS, preferendone il primo, in quan-

to ricopre una fascia di mercato piu ampia (Figura 6.1) e escludendo a priori

Windows Phone per il medesimo motivo. Inoltre Android concede piu liberta

nello sviluppo dell’applicazione in quanto la scelta di IoS implicava il possesso

di un dispositivo Apple, questo perche il solo simulatore non sarebbe bastato

dato che bisogna avere accesso a tutte le interfacce compresa quella GPS, ca-

ratteristica non disponibile attualmente in tali strumenti. Un altro aspetto

che ha influito sulla scelta di Android riguarda i costi per diventare svilup-

patori, decisamente piu favorevoli per quest’ultimo in quanto Apple fornisce

un numero di chiavi ristretto ( cinque in tutto) per sviluppare un’applica-

zione ad un costo maggiore, mentre Android non pone alcuna limitazione a

riguardo.

Detto cio, quello che si vuole ottenere e un’applicazione, che come accen-

11

nato nei capitoli precedenti dia la possibilita all’utente di avere continuita di

connessione e risolva il problema degli intervalli di non disponibilita dovuti

al cambio dell’ interfaccia. Per rendere l’esperienza di utilizzo migliore, si e

pensato che tale applicazione dopo il primo utilizzo e per gli avvii succes-

sivi del dispositivo, possa essere eseguita come servizio in background con

le impostazioni specificate dall’utente. In questo modo, quest’ultimo ha la

possibilita di impostare le configurazioni dell’applicazione, per esempio: il

valore degli intervalli di scansione delle interfacce, posizione dei file conte-

nenti i risultati delle scansioni e dei log qualora voglia salvarli.

Cosı facendo, negli avvii successivi tali impostazioni vengono utilizzate in

automatico dal servizio in background. Ovviamente viene lasciata liberta

all’utente di decidere di non avviare in automatico l’applicazione o di non

usarla come un servizio. L’utilita di avere un servizio in background rispetto

all’applicazione vera e propria sta nel fatto che oltre a non avere nessuna

activity visualizzata sullo schermo, molti dei messaggi che con l’applicazione

vera e propria verrebbero visualizzati all’utente vengono omessi.

Questo implica che dal punto di vista dell’utente, il servizio esegue tutto in

automatico, ovvero attiva e disattiva le opportune interfacce di connessione,

forza le connessioni a particolari reti wireless o celle in base a dove ci si trova

e alla modalita di spostamento, il tutto senza dover interagire col dispositivo,

come se quest’ultimo dia l’impressione di sapere come si deve comportare in

base alla circostanza.

Inoltre c’e da ricordare che l’utente puo scegliere se utilizzare la modalita di

popolamento del database o l’Oracolo, sia in fase di settaggio delle imposta-

zioni che negli usi successivi. Di conseguenza si evince che l’applicazione puo

essere vista come multi-purpose, offrendo:

• Scansione delle interfacce di rete con salvataggio in locale dei risultati.

• Scansione delle interfacce di rete con popolamento e modifica della base

di dati.


• Utilizzo del database come nel punto precedente a cui si aggiunge la fun-

zionalita del modulo Oracolo per gestire in modo autonomo le interfacce

di rete.

2.1 Lato client

Come accennato nel capitolo precedente, l’Oracolo ha come funzione fi-

nale quella di automatizzare l’utilizzo delle interfacce. Il lato client quindi

prevede la scansione e l’invio delle informazioni all’Oracolo e la ricezione del-

la soluzione da quest’ultimo. L’obbiettivo e quindi quello di fornire all’utente

un’interfaccia funzionale in cui impostare i vari parametri discussi in prece-

denza e decidere con quali funzionalita attive utilizzare l’applicazione.

Il risultato che l’utente percepisce e quello di avere continuita di connessione

e poter quindi usufruire dei vari servizi del dispositivo legati all’utilizzo della

rete, dando precedenza, dove possibile, alla tecnologia Wi-Fi.

Inoltre, in alcuni casi e necessario l’utilizzo del GPS, soprattutto all’avvio

dell’applicazione per fare in modo che l’Oracolo possa fare la scelta migliore

sin da subito, avendo piu informazioni sulla posizione dell’utente e nei ca-

si in cui le scansioni delle reti non siano sufficienti per fornire un risultato

soddisfacente.

La problematica di scegliere la migliore rete tra quelle a disposizione e

piuttosto complessa, pur avendo un algoritmo ben implementato. Infatti pur

capendo a quale rete connettersi in base a quanto contenuto nel database,

al tipo di spostamento che si sta effettuando e dando priorita alle reti che

hanno una buona qualita del segnale, non e detto che la connessione alla rete

sia la migliore possibile. Per averne la certezza, bisognerebbe effettuare uno

speed test, ma cio impiegherebbe un lasso di tempo che non si e disposti a

spendere in quanto l’attuale connessione potrebbe cadere.

Di seguito vengono spiegati i vari scenari in cui l’utente e quindi il lato

client si puo trovare, il tutto dal punto di vista logico, i dettagli relativi

alla progettazione e all’implementazione dell’algoritmo per la gestione dei

2.1 Lato client 13

suddetti scenari, sono proposti rispettivamente nei Capitoli 4 e 5.

La Figura 2.2 mostra il caso in cui non si abbia nessuna copertura, in tal

caso il lato client non riceve alcun risultato dalle scansioni delle interfacce,

di conseguenza non vengono eseguite interrogazioni sulla base di dati e non

si ha la percezione della posizione attuale, quindi viene avvisato l’utente di

tale situazione.

Figura 2.2: Caso in cui non si ha alcuna copertura.

La Figura 2.3, mostra il caso in cui l’utente sia in una zona coperta da sole

reti wireless, volendo si ha a disposizione anche il segnale gps, l’applicazione

gestisce ovviamente anche il caso in cui esso non sia presente in quanto se

possibile viene disattivato per risparmiare energia. In questo caso il lato

client, effettuando le scansioni delle interfacce, permette di salvare sui file

XML i risultati e di stimare la direzione e la velocita dello spostamento

dell’utente. Viene quindi interrogato l’Oracolo, fornendo informazioni utili

riguardo lo spostamento e alle scansioni. A questo punto, l’Oracolo costruisce

una lista di reti candidate basandosi anche sulle configurazioni presenti nel

dispositivo. I criteri secondo i quali l’Oracolo predilige una rete rispetto

ad altre vengono spiegati nella sezione successiva. La decisione di cambiare

connessione dipende dalla direzione in cui si sta spostando e dalla potenza

del segnale della rete attuale, rispetto all’altra rilevata.


Figura 2.3: Caso in cui si ha la copertura solo di access point wireless.

La Figura 2.4 qui sotto, mostra invece il caso in cui l’utente si trovi in una

zona coperta solo da celle, che per semplicita assumiamo siano dell’operatore

con cui ha stipulato un contratto. Ovviamente il dispositivo e in grado

di rilevare anche le celle degli altri operatori, ma l’algoritmo le omette dai

risultati utili rilevati da inoltrare all’Oracolo. Detto cio, se la cella a cui si

e connessi inizia a calare troppo di intensita allora si chiede all’Oracolo cosa

fare, inoltrando i risultati delle scansioni (che potranno comprendere o meno

anche le coordinate GPS se l’opportuna interfaccia e ancora attiva).

E inoltre necessario capire la direzione e la velocita con cui l’utente si sta

spostando.

Figura 2.4: Caso in cui si ha solo copertura da parte delle celle telefoniche.

Infine nella Figura 2.5, viene mostrato il caso in cui si ha una transizione

sulla tipologia di connessione, ovvero da wireless a dati mobili o viceversa.

Dal punto di vista dell’utente, l’unica percezione e relativa alle interfacce

2.2 Lato server 15

che vengono attivate e disattivate automaticamente. Come per i precedenti,

casi risulta importante capire la direzione e la velocita dello spostamento per

scegliere la candidata migliore e capire quando e opportuno abbandonare la

connessione attuale.

Figura 2.5: Caso in cui si ha una transizione da una tipologia di connessione

ad un’altra.

2.2 Lato server

Il lato server e costituito principalmente dalla base di dati e dal modulo

relativo all’Oracolo. La prima, viene popolata dalla stessa applicazione qua-

lora l’utente lo voglia. L’idea e quella di avere una base di dati risultante da

quanto rilevato dai vari dispositivi che utilizzano l’applicazione.

Si puo pensare anche alla possibilita di scaricare solo una parte della basi di

dati in locale, per rendere il tutto il piu veloce, magari per zone di interesse,

soprattutto nel caso di utenti pendolari. Gli scenari da gestire sono quelli

discussi nella sezione precedente. L’Oracolo, deve quindi prendere delle deci-

sioni basandosi sullo stato attuale della connessione, sui profili rilevati dalle

interfacce e sulle configurazioni salvate nel dispositivo, il tutto considerando

anche direzione e velocita degli spostamenti.

Risulta scontato il comportamento del lato server negli scenari descritti

nelle figure della sezione 2.1, l’obbiettivo e quello di garantire continuita di

connessione in qualsiasi scenario tranne che per quello descritto in Figura


2.2 in cui non e possibile fare niente se non avvisare l’utente. Come per il

lato client, i dettagli progettuali ed implementativi sono rimandati rispetti-

vamente ai Capitoli 4 e 5.

A tal proposito e bene ricordare come l’Oracolo prediliga l’utilizzo di reti

wireless per questioni di costi nonche di risparmio energetico, quindi per pri-

ma cosa si cerca sempre di dare la priorita a tale tecnologia anche quando si

sta utilizzando il traffico dati mobile. Cio e reso possibile mantenendo una

relazione delle reti wireless rilevate in fase di training mentre il dispositivo

e allacciato ad una determinata cella. In questo modo, durante l’utilizzo

dell’Oracolo e possibile avere informazioni riguardanti le connessioni Wi-Fi

nonostante l’apposita interfaccia sia disattivata.

Cio implica la necessita di avere un database che rimanga aggiornato, a tal

proposito e stata sviluppata la funzionalita di training.

2.3 Stato dell’arte

In letteratura vi sono molti paper, documenti di ricerca e pubblicazioni

su riviste scientifiche relative alle problematiche della gestione del processo

di handover in ambienti con reti eterogenee.

Anche in tali elaborati, si considerano i fattori trattati in questo progetto

di tesi: per prima cosa si vuole mantenere la connessione stabile durante

lo spostamento dell’utente (in tal caso la connessione viene detta seamless).

La gestione dell’handover avviene quando il segnale diventa basso o sotto

determinati parametri (nozione chiamata Signal Qualityt Reason), oppure

quando la capacita del traffico di una cella raggiunge il massimo consentito

(Traffic Reason). Per fare cio bisogna gestire la localizzazione, esistono a tal

proposito tecniche per partizionare l’area di copertura di un operatore per

capire dove si trova un utente [7]. In particolare si possono considerare due

tecniche fondamentali:

• Location Update: il terminale informa la rete della locazione dell’utente.

2.3 Stato dell’arte 17

• Paging : dei messaggi broadcast inizializzati dalla rete servono per

localizzare qual’e la cella corrente a cui e collegato un utente.

La gestione della localizzazione [9] deve essere efficiente in quanto deve

garantire:

1. La minimizzazione dell’overhead del segnale e della latenza quando si

richiede il servizio.

2. La qualita del servizio (QoS) alle applicazioni.

3. Il controllo del flusso di dati, in quanto bisogna garantire la consegna

dei pacchetti dalla vecchia connessione a quella nuova.

Inoltre e risaputo che il processo di handover si suddivide in tre fasi

principali:

1. Avvio di tale processo da parte del dispositivo mobile, o dalla stazione

base a cui si e collegati (o da parte di entrambi).

2. Generazione della nuova connessione.

3. In circostanze in cui vi e sovrapposizione di piu reti wireless, si vuole

garantire un algoritmo efficiente e robusto per selezionare la rete a cui

il dispositivo mobile e effettivamente in grado di connettersi, per fare

cio bisogna decidere, quanto e come salvare le informazioni relative alla

locazione ed inoltre come determinare l’esatta posizione del dispositivo

stesso.

Inoltre il meccanismo di handover deve essere scalabile, affidabile e robu-

sto. La difficolta, sta quindi nel fornire buoni meccanismi per reti eteroge-

nee, in quanto solitamente, vengono coinvolti differenti livelli dello stack del

protocollo TCP/IP e in base a cio, possono essere suddivisi nelle seguenti

categorie:

• Protocolli al livello network, che usano messaggi al livello IP e so-

no indifferenti alle sottostanti tecniche di accesso wireless (Misra et al

2002).


• Protocolli al livello link, che forniscono caratteristiche relative alla

mobilita ai sistemi radio sottostanti.

• Protocolli cross-layer, sono quelli piu diffusi, in grado di realizzare

handover a livello network con l’aiuto di comunicazioni a livello link.

In generale, ricevendo ed analizzando la potenza del segnale e le infor-

mazioni relative allo spostamento del dispositivo ottenuto a livello layer, il

sistema e pronto per l’handover cosı il numero di pacchetti che si possono

potenzialmente perdere e ridotto al minimo, analogo discorso per quanto ri-

guarda la latenza.

Per quanto riguarda Android, dalla versione Lollipop, il team di sviluppatori

ha messo a disposizione una funzionalita chiamata aggressive wifi to cellular

handover, che dovrebbe far capire al dispositivo, qualora sia agganciato ad

una cella telefonica, di connettersi ad una rete wireless se disponibile (e di cui

ha la configurazione almeno che non sia aperta). Tale funzionalita seppure

apprezzata presenta ancora diverse problematiche, infatti in rete vi sono mol-

ti forum di discussione sull’argomento in cui gli utenti lamentano una scarsa

efficienza, in quanto i dispositivi rimangono praticamente sempre connessi al-

le celle telefoniche anche quando dovrebbero passare alla tecnologia wirelss,

nonostante vengano anche attivate opzioni quali il poter connettersi a reti

Wi-Fi con uno scarso segnale. Le lamentele dell’utenza confermano quanto

descritto nel Capitolo 2, ovvero l’utente predilige la rete wireless per que-

stione di costi, prestazioni e risparmio energetico (a meno di casi particolari

come il 4G che non e ancora molto diffuso).

Tralasciando per un attimo Android, in letteratura vi e una pletora di

soluzioni per far cooperare WLANs e reti mobili [8], alcune per ora teoriche,

altre sviluppate. Tutte presentano dei difetti e il processo di handover rimane

tra i piu critici da gestire in tale scenario. Infatti tale funzionalita e molto

difficile da mettere in atto in maniera completamente efficiente tantoche i

sistemi piu diffusi sugli smartphone odierni presentano ancora delle lacune e

non garantiscono la continuita del servizio.


La Figura 2.6 evidenzia quali sono le macro fasi che costituiscono il

processo di handover, in particolare:

• Misurazione: viene effettuata con dei criteri quali la potenza del segna-

le, la distanza, la qualita (in termini di rate di errore) e il volume del

traffico.

• Decisione: fase in cui si deve decidere a quale access point connettersi

avendo a disposizione le informazioni discusse nella fase di misurazione.

Inoltre vegono utilizzati dei parametri ausiliari, per esempio dei margini

di treshold.

• Esecuzione: questa fase puo avvenire in diverse modalita, per esempio

si possono avere soft o hard handover, inter-cell e intra-cell hando-

ver, inter-frequency ed intra-frequency handover, inter-system e intra-

system handover. Lo scopo di questa fase e quello di comunicare l’in-

staurazione della nuova connessione e il conseguente instradamento dei

dati utilizzando quest’ultima.

Figura 2.6: Fasi principali del processo di handover.

L’handover di base, si fonda unicamente sulla potenza del segnale della

connessione attuale ed eventualmente sulle altre reti rilevate nelle vicinanze.


In Figura 2.7 viene evidenziato tale scenario. Il dispositivo mobile passa dalla

stazione base A alla B dato il movimento del veicolo su cui esso e dislocato.

Il problema anche in questo semplice scenario, consiste nella necessita di

allacciarsi alla stazione B prima che si perda il segnale dalla stazione A.

Il punto in cui l’handover avviene e L1. Con questo approccio, emergono

problematiche relative all’effetto ping pong, dovuto al multipath propagation

del segnale. Quest’ultimo, potrebbe portare a voler cambiare allacciamento

tra le due celle ripetutamente. Si ricorda che il multipath propagation e il

fenomeno per il quale un segnale radio raggiunge un’antenna attraverso due o

piu percorsi, tale problematica e dovuta principalmente all’atmospheric duct

ovvero ad un livello orizzontale piu basso dell’atmosfera che ha un potere

riflessivo, o ancora alla riflessione ionosferica. In tutti questi casi, le onde

radio possono cambiare direzione e variare i loro percorsi.

Figura 2.7: Handover basato sulla potenza del segnale rilevato. Il punto L1

indica l’esatta posizione in cui deve avvenire il cambio di rete.

Dopo aver visto lo scenario base, si introduce il concetto di handover con

potenza del segnale relativa e treshold (Figura 2.8). In questo caso l’hando-

ver avviene se la potenza del segnale della stazione a cui si e allacciati risulta

essere minore del threshold stabilito e il segnale della stazione vicina e forte

abbastanza. In particolare se il threshold e alto (Th1), ci si comporta come

nel caso descritto in Figura 2.7.

Se invece il threshold e basso (Th3), il dispositivo potrebbe decidere di al-


lacciarsi troppo tardi all’altra cella (B). Di conseguenza il threshold non puo

essere utilizzato da solo, in quanto la sua efficacia dipende da alcune cono-

scenze a priori, come la potenza del segnale di crossover tra le stazioni base

candidate.

Figura 2.8: Handover basato sulla potenza del segnale e su un valore di

threshold.

Quindi se il solo treshold non e sufficiente per garantire un buon risultato,

si puo introdurre l’isteresi (Figura 2.9) per risolvere la problematica ad esso

relativa. L’handover avviene solo se la nuova stazione, ha una potenza del

segnale sufficientemente forte (di un certo margine H) rispetto a quella a

cui si e collegati attualmente. Mentre il dispositivo e allacciato alla stazione

base A, l’handover viene generato quando la potenza del segnale raggiunge

o eccede la quota H (detta quota di isteresi). Una volta che il dispositivo

e collegato alla stazione B, ci rimane finche la potenza del segnale non cala

fino a raggiungere il valore -H, a quel punto ci si riconnette alla stazione A.

Il vantaggio di questa tecnica e che previene il cosiddetto effetto ping pong,

mentre ha come svantaggio quello di non effettuare il primo handover quando

sarebbe concettualmente corretto perche la stazione base A potrebbe ancora

avere un segnale abbastanza potente.

A questo punto si sono viste delle varianti all’handover classico: prima

quella con la tecnica di treshold e in seguito con la tecnica di isteresi.

Si e potuto notare come entrambe presentino dei difetti, possono pero essere

combinate per ovviare a tali lacune (Figura 2.10). L’handover avviene se


Figura 2.9: Handover basato sul concetto di isteresi.

il segnale della stazione base a cui si e collegati cala sotto il treshold e la

potenza del segnale dell’altra stazione base e migliore del margine di isteresi

H.

Nella Figura 2.10, l’handover avviene nel punto L4, se il treshold e fissato a

Th1 o Th2, oppure avviene nel punto L3 se il treshold e Th3.

Figura 2.10: Handover basato su treshold ed isteresi combinati.

Continuando con la panoramica sullo stato dell’arte, si puo introdurre una

differenziazione piu fine per quanto riguarda le diverse tipologie di handover

[10]. Una macro distinzione riguarda soft handover ed hard handover :

• Hard handover : segue la logica ”brake before make”, ovvero la connes-

sione attuale viene rilasciata prima di effettuare quella nuova.

Ovviamente tale approccio porta ad una interruzione della connessione

(nel progetto di tesi si e evitato un approccio di questo tipo).


In qualsiasi momento, il dispositivo e quindi collegato solo ad una

stazione base.

• Soft handover : segue la logica ”make before break”, ovvero la nuova

connessione viene instaurata prima di rilasciare quella vecchia, in que-

sto modo si evita una momentanea assenza della connessione (logica

utilizzata nel progetto di tesi). Una volta che l’handover avviene con

successo, la vecchia connessione viene rilasciata.

Le distinzioni piu fini [9], accennate in precedenza riguardano, l’intra-

frequency handover, Inter-frequency handover ed inter-system handover:

• Intra-frequency handover: la nuova frequenza utilizzata e la stessa di

quella precedente.

• Inter-frequency handover: la nuova frequenza e diversa dalle vecchie

frequenze utilizzate (ricadono in questa tipologia il GSM o anche l’han-

dover tra diversi operatori UMTS).

• Inter-system handover: avviene tra due tipi diversi di accessi radio (per

esempio tra GMS ed UMTS), e un caso particolare di inter-frequency

handover.

Altre distinzioni possono essere fatte sulla base di tre parametri: sottoreti,

domini amministrativi e tecnologie di accesso (Dutta et al., 2008):

• Inter-technology : e possibile quando il dispositivo e equipaggiato con

piu interfacce e supporta quindi diverse tecnologie. Un handover di

questo tipo avviene quando due punti di connessione usano diverse tec-

nologie di accesso. Ovviamente in questo scenario il dispositivo esce dal

range di una rete (per esempio wifi) entrando in un altro (per esempio

UMTS). Questa casistica e anche conosciuta come handover verticale.

Solitamente i dispositivi mobili vengono intesi in letteratura come ca-

paci di poter effettuare l’handover verticale in quando percepiti come

”multimode” (ovvero muniti di piu interfacce per tecnologie diverse).


• Intra-technology : avviene quando il dispositivo si muove tra due punti

di connessione supportati dalla stessa tecnologia di accesso, per esempio

due access point wifi. Puo inoltre avvenire nelle casistiche di intra-

subnet o inter-subnet handover descritti di seguito. In questo caso

viene coinvolto solo il layer tre (network) dello stack.

• Inter-domain: quando due punti di connessione fanno parte di domini

diversi. Per dominio si intende un insieme di risorse di rete gestite da

una singola entita amministrativa che autentica e autorizza gli accessi

(per esempio un service provider). In questo caso si parla anche di

macro mobility.

• Intra-domain: un handover di questo tipo avviene quando il dispositivo

si muove verso il confine di un dominio amministrativo.

Tale tipologia puo implicare diversi altri tipi di handover quali intra-

subnet, inter-subnet, intra-technology, e/o inter-technology.

Questo scenario e conosciuto anche come micro mobility.

• Inter-subnet : avviene quando due punti di connessione appartengono

a sottoreti diverse. Il dispositivo acquisisce il nuovo indirizo IP e puo

sottoporsi a nuove procedure di sicurezza. Un handover di questo tipo

puo avvenire quando si e nei casi di inter-technology o intra-technology.

• Intra-subnet : avviene quando due punti di connessione appartengono

alla stessa sottorete, ad esempio due access point della stessa rete.

Dopo aver analizzato la tassonomia dei meccanismi di handover, si passa

quindi ad analizzare quali sono le componenti che controllano tale processo

(Figura 2.11). In particolare, in letteratura si trovano tre metodologie:

• Network-Controlled Handover (NCHO): la rete misura la qualita della

trasmissione attraverso la stazione base e decide quando eseguire l’han-

dover. In questo caso i dispositivi non possono effettuare misurazioni.


Con questa tecnica si ha un intenso scambio di informazioni tra la sta-

zione base e il dispositivo mobile. Il processo di handover impiega circa

tra i 100 e 200 ms.

• Mobile-Assisted Handover (MAHO): a differenza della NCHO, e il di-

spositivo mobile ad effettuare continuamente le misurazioni della po-

tenza del segnale sia attuale che delle stazioni vicine mandando tali

risultati alla stazione base a cui e collegato. In base ai valori delle

scansioni, la rete decide se deve avvenire l’handover che impieghera

circa un secondo per essere effettuato.

• Mobile-Controlled Handover (MCHO): il terminale ha completo con-

trollo del processo di handover, effettua le misurazioni e decide quando

effettuare l’handover, il tutto con un tempo di reazione molto ridotto

(0.1 secondi). Questa soluzione risulta essere la migliore ed e stata

utilizzata nel progetto.

Figura 2.11: Metodi di controllo del processo di handover.

Un altro problema importante trattato in letteratura nonche nell’elabo-

rato di tesi riguarda la geolocalizzazione. Attualmente vi e una sorta di

antagonismo tra due tecniche dette mobilita basata sulla numerazione (pa-

ging /call delivery) e mobilita basata sull’aggiornamento della locazione.

La prima prevede che se una chiamata arriva al dispositivo mobile, esso vie-

ne numerato (localizzato) in tutte le celle della rete dell’operatore, in questo

modo l’aggiornamento della locazione in senso stretto non e richiesta.

La seconda invece, prevede che ogni volta che l’utente oltrepassa i confini

di una cella avviene un aggiornamento della sua posizione, questa tecnica e


piu efficiente e precisa della precedente in quanto non si e dipendenti dalle

chiamate per effettuare una localizzazione, si ha pero lo svantaggio di un

consumo di energia maggiore.

In relazione al concetto di localizzazione vi e quello di location area.

Questa informazione viene utilizzata anche nell’implementazione del progetto

(Capitolo 5), in quanto e uno dei dati piu importanti che si possano rilevare

da codice, per riuscire a mappare un insieme di celle che fanno parte di una

certa macro area. In particolare un gruppo di celle puo essere raggruppato in

una location area che sara poi identificata da un codice detto Location Area

Code (LAC). Le celle vengono ragruppate (soprattutto nel caso del GSM)

per ottimizzare il segnale. Solitamente qualche decina o centinaia di stazioni

base condividono lo stesso Base Station Controller (BSC) nel caso del GSM

oppure lo stesso Radio Network Controller (RNC) nel caso dell’UMTS.

Tali entita gestiscono l’algoritmo di ”intelligenza” che sta dietro alle stazioni

base, per esempio il BSC gestisce l’allocazione dei canali radio, riceve da-

ti dai cellulari, controlla i trasferimenti di dati tra stazioni base. E bene

considerare che se la location area e molto grande, ci saranno molti cellu-

lari allacciati ad essa contemporaneamente, cio implica una mole di traffico

considerevole. Inoltre la dimensione della location area va ad inficiare anche

sulla durata della batteria del dispositivo mobile: se e piccola allora il dispo-

sitivo e costretto a contattare la rete molto spesso quando si sposta, mentre

invece se la location area e grande il consumo della batteria risulta essere

minore a discapito pero della bada a disposizione che sara ridotta rispetto

al caso precedente. Detto questo, quando il sistema instaura una comunica-

zione col dispositivo, la localizzazione di quest’ultimo avviene nella location

area attuale in cui l’utente risiede, quindi il consumo di risorse e limitato alla

location area in cui si trova. La dimensione delle location area e determinata

da diversi fattori quali:

• Il raggio di copertura delle celle che ve ne fanno parte.

• La velocita con cui le informazioni si trasmettono, ovvero se ci si trova


in una zona molto affollata e quindi le celle sono cariche di connessioni,

l’area deve essere di dimensioni ridotte.

• Il costo dell Location Update (LU) o del paging in termini di messaggi

richiesti, ovvero quanto costa comunicare la mia posizione alle celle in

termini di traffico.

L’obbiettivo e comunque quello di minimizzare il costo per gestire la lo-

calizzazione, inteso come numero di messaggi necessari per l’aggiornamento

di tale informazione, indipendente da quale tecnica venga utilizzata.

Ora che sono state introdotte le location area, e possibile entrare piu nel

dettaglio sulle metodologie per aggiornare la locazione di un utente. Vi sono

diverse tecniche descritte in letteratura:

1. Periodic location updating : il dispositivo trasmette periodicamente la

propria locazione alla rete, il consumo di risorse e indipendente dal-

l’utente e non e necessario se non ci si sposta dalla LA per molto

tempo.

2. Aggiornamento della locazione per attraversamento della LA: la stazio-

ne base periodicamente fa un broadcast, per identificare la propria LA

e il dispositivo puo ascoltare tali messaggi per capire la propria posi-

zione. Qualora riceva un identificativo diverso dal procedente allora

significa che ci si e spostati e quindi il dispositivo prende atto di tale

cambiamento (per esempio salvando le informazioni in un database).

3. Aggiornamento della locazione ibrido: e la combinazione dei due metodi

precedenti, il dispositivo trasmette la propria locazione e riceve anche i

messaggi di broadcast dalla stazione base. Rispetto alle altre tecniche

si ha il vantaggio che l’utente puo essere localizzato anche se ci sono

dei guasti alla base di dati.

Si vedra in seguito che nel progetto il dispositivo mobile legge le informa-

zioni della cella a cui e collegato e di quelle ad essa vicine, salvando il tutto


nel database dell’Oracolo. Si puo quindi affermare che la tecnica utilizzata

sia derivata dal concetto del punto 2) descritto qui sopra.

La struttura dei pacchetti [7] utilizzati per lo scambio di tali informazioni

prevedono alcuni campi largamente utilizzati nel progetto di tesi, quali:

• CC : Country Code.

• MNC : Mobile Network Code.

• CID : Cell Id, identificativo univoco della cella.

• LAC : location Area Code, serve appunto per identificare una LA.

• Potenza del segnale.

La Figura 2.12 mostra il Location Area Identifier (LAI), identificatore

univoco formato da alcuni dei campi sopracitati ed utile ad identificare una

LA. Si noti che non viene utilizzato il solo LAC, in quanto tale codice puo

rappresentare celle diverse, che possono appartenere ad operatori differenti.

Ecco perche e necessario specificare il MNC per distinguere quest’ultimi.

Figura 2.12: Struttura del Location Area Identifier (LAI), formata dal CC,

MNC e LAC.

Le informazioni appena elencate sono dette temporanee, in quanto pos-

sono variare nel tempo, infatti una cella puo essere tolta da una LA ed essere

inserita in un’altra, oppure l’operatore puo cambiare il sistema di identifica-

zione, variando quindi i CID. Le informazioni che in letteratura, vengono in-

vece definite permanenti sono quelle relative all’utenza (International Mobile

Subscriber Identitiy (IMSI), Mobile Subscriber ISDN Number (MISDN)) e


quelle relative ai dispositivi (International Mobile Station Equipment Identity

(IMEI)) [7].

Quanto detto fin’ora descrive principalmente le nozioni base dello stato

dell’arte per quanto riguarda gli argomenti di handover e della localizzazio-

ne. Inoltre, il successo delle tecnologie di accesso wireless, come le WLANs,

ha costretto i provider di telefonia mobile a considerare la loro integrazio-

ne nelle infrastruttre 3G. Attualmente vi sono molti gruppi di ricerca e di

standardizzazione che stanno lavorando per fornire queste architetture inte-

grate: al solito si vuole garantire continuita di connessione, QoS, gestione

della localizzazione e riduzione dei tempi del processo di handover.

Una ulteriore precisazione va fatta per quanto riguarda l’UMTS e la fami-

glia 3G citata poc’anzi. Se quanto detto precedentemente e verificato anche

per quest’ultima tipologia di connettivita dati, e comunque bene notare che

essa e il risultato delle precedenti esperienze derivanti da GSM e GPRS.

L’attenzione viene prestata particolarmente all’UMTS in quanto e la tipolo-

gia di connettivita piu diffusa attualmente (come mostrato in Figura 2.13),

in quanto il 4G [10], ha preso da poco piede e anche se molto promettente,

come copertura non e ancora ai livelli dell’UMTS.

Figura 2.13: Copertura dell’UMTS in Italia.

Riguardo ad UMTS, esso per la localizzazione usa sia la tecnica di pa-

ging che il riscontro di eventuali cambiamenti di cella, affidandosi quindi al


sistema ibrido discusso precedentemente. Data la presenza massiccia di celle

UMTS, preferite dai dispositivi alle altre, esse sono spesso allacciate da un

numero considerevole di dispositivi, di conseguenza hanno un carico di lavoro

rilevante e ne conseguono dei ritardi maggiori per quanto riguarda l’handover

rispetto alle altre tipologie di connettivita.

In particolare, UMTS di per se utilizza un handover basato sul concetto

di soft handover [10][11], con alcune modifiche. In letteratura tale tipo di

handover viene chiamato ”softer handover”. Tale approccio pero non si e ri-

velato sempre funzionale, ed e conosciuto per non essere molto veloce, come

provato dall’utilizzo quotidiano, in cui spesso vi e perdita di pacchetti du-

rante l’utilizzo di applicazioni real-time o VoIP. Durante il softer handover,

un terminale mobile si trova nell’area di copertura di due settori adiacenti di

una stessa stazione base 2.14. La comunicazione tra dispositivo mobile e la

stazione base avviene quindi per mezzo di due canali distinti sull’interfaccia

radio, uno per ciascun settore, anche se di fatto trasportano la stessa infor-

mazione. Quindi la stazione base riceve due segnali provenienti dallo stesso

dispositivo mobile attraverso la propagazione multipath, ed invia i dati su

tutti e due i canali fino a quando uno dei due non viene rilasciato in quanto

il dispositivo si trova completamente in una delle due aree. E la stazione

base che si preoccupa, dati i due segnali da parte del dispositivo mobile, di

spostarli su una banda base e di inoltrarli verso l’RNC (Radio Network Con-

troller), ovvero colui che governa l’accesso alla rete UMTS e che inoltrera i

pacchetti opportunamente.

In generale, nessun processo di handover e esente da ritardi [9] e tutti i

protocolli dello stack ne contribuiscono:

• Link layer delay : dipende dalla tecnologia di accesso, un dispositivo

mobile puo effettuare numerosi passi per tale processo, aggiungendo

ulteriore ritardo prima che la nuova connessione venga stabilita.

Per esempio, si pensi alla connessione Wi-Fi, essa passa attraverso ai

procedimenti di scansione, autenticazione e associazione prima che ef-

fettivamente il collegamento sia del tutto instaurato. Per gli handover


Figura 2.14: Softer handover.

di tipi intra-subnet, dove la configurazione del livello di rete e necessa-

ria, il livello link contribuisce alla gran parte del ritardo percepito.

• Netowrk layer delay : dopo aver completato le procedure a livello link,

potrebbe essere necessario iniziare una transizione a livello rete.

Quest’ultima potrebbe comportare alcuni passi, quali l’acquisizione di

un nuovo indirizzo IP, la rilevazione della presenza di indirizzi uguali e

relativo aggiornamento dovuto all’ARP (Address Resolution Protocol).

• Application layer delay : il ritardo di questo tipo e dovuto al fatto che si

devono ristabilire o modificare alcune proprieta del livello applicazione,

come per esempio l’indirizzo IP usato durante il SIP (Session Initiation

Protocol). Altre cause di ritardo in questo livello sono dovute alla

procedura relativa all’ Extensible Authentication Protocol (EAP) che

include numerosi messaggi per l’autenticazione e l’autorizzazione.

E quindi di cruciale importanza riuscire a risolvere la problematica dei ritardi,

o quanto meno provare a ridurla al minimo, per avere un servizio seamless

[12].

2.3.1 MIH - Media Indipendent Handover

In letteratura vi e una soluzione per effettuare l’handover indipendente-

mente dalla tecnologia, tutt’ora in fase di sviluppo, chiamata Media Indi-

pendent Handover [8][9]. Si tratta di uno standard IEEE 802.21 (Eastwood


et al., 2008). Tale standard, si focalizza sul facilitare l’handover tra reti wi-

reless differenti in un ambiente eterogeneo e nomina tale handover verticale

appunto col nome di MIH. In MIH, la procedura di handover puo usare le

informazioni provenienti sia dal dispositivo mobile che dalla rete.

Allo stesso tempo, diversi fattori possono determinare la decisione da pren-

dere, per esempio la continuita del servizio, il tipo di applicazione in uso, il

QoS, la sicurezza e la gestione del consumo energetico. I primi due fattori

sono tra essi correlati, la continuita di servizio e insaputa a priori ma avendo

a disposizione l’applicazione in uso la si puo dedurre.

Per fare tutto questo, MIH include delle tecnologie per scoprire quali sono le

reti candidate per l’esecuzione dell’handover. Infatti IEEE 802.21 definisce

tre servizi per facilitare l’inter-technology handover:

• Media Independent Information Service (MIIS) che fornisce informa-

zioni relative alle reti vicine.

• Media Independent Command Service (MICS), che permette l’effetti-

va gestione delle diverse interfacce del dispositivo mobile e abilita il

processo di handover.

• Media Independent Event Service (MIES), che fornisce degli eventi sca-

tenati dal cambiamento delle caratteristiche o degli stati del collega-

mento che si sta utilizzando. In questo caso le interfacce forniscono

primitive ai livelli superiori che sono indipendenti dalla tecnologia di

accesso.

Una delle caratteristiche piu importanti di MIH e che sia la stazione

base che l’utente (piu che altro il dispositivo mobile) possono controllare

l’handover: il primo comporta la riduzione del consumo energetico in quanto

il monitoraggio delle altre reti e fatta dalla stazione base e non dal dispositivo,

inducendo pero ad un incredibile overhead del segnale dovuto ai numerosi

messaggi scambiati. Per quanto riguarda il dispositivo, esso colleziona i dati

e in base alla circostanza avvia il processo corretto.


Riguardo alla sicurezza di MIH, ogni qualvolta un dispositivo mobile si

connette ad un access point, stabilisce un contesto sicuro col service provider.

Durante il processo di handover, tutte le entita coinvolte nel meccanismo di

sicurezza possono subire variazioni, cosı anche il contesto stesso puo subire

delle modifiche. Spesso viene quindi utilizzata un’autenticazione, anche se

in alcuni casi come per GPRS ed UMTS cio non avviene, questo implica che

il processo di handover puo essere vulnerabile ad attacchi. Un esempio di

attacco consiste nel fingere di essere una stazione base che manda messaggi

alla stessa frequenze e con lo stesso slot temporale di quelle vere.

L’utilita di avere una chiave ed una crittografia impedisce a chiunque di inse-

rirsi nel traffico nel canale come invece descritto in quest’ultimo esempio, se

invece chi vuole violare il sistema riesce ad entrare in possesso di tale chiave,

allora puo utilizzare un attacco come descritto precedentemente per spacciar-

si per una stazione base. Vi sono molte falle nei sistemi comunemente usati

oggi, per esempio per quanto riguarda l’UMTS, durante l’handover, la chia-

ve utilizzata tra un nodo e la vecchia stazione mobile puo essere riutilizzata

anche per le connessioni successive. Quindi, senza le dovute precauzioni, e

possibile intercettare la chiave usata e date le specifiche appena descritte, la

si puo utilizzare per stabilire nuove connessioni UMTS.

Come accennato in precedenza, anche per quanto riguarda MIH, si necessita

di avere a disposizione un algoritmo di predizione efficiente, per ridurre l’ove-

rhead del segnale tra il dispositivo e la vecchia stazione base. Cosı facendo,

la quantita di segnale risparmiata puo essere utilizzata per inoltrare l’auten-

ticazione tra il nodo e la nuova stazione base. Ovviamente nel progetto di

tesi tale algoritmo di predizione e stato implementato.

2.3.2 Esempio nel mondo reale: integrazione tra WLAN

e WiMax

Le nuove reti eterogenee, includono per esempio IEEE 802.11 WLANs

e IEEE 802.16 Metropolitan Area Networks (WMANs). Quest’ultime sono

riconosciute per avere una buona interoperabilita con WiMax [8].


Di fatto tutto cio sembra essere un buon approccio in quanto entrambe le tec-

nologie supportano un alto data rate ed un buon QoS, anche se e risaputo che

il Wi-Fi offre connettivita di rete a costi bassi, usando frequenza di rete non

sotto licenza. Mentre WiMax lavora sia su bande sotto licenza che non, ed e

stato progettato principalmente per la comunicazione point-to-multipoint.

Tra Wi-Fi e WiMax vi e un’ulteriore distinzione molto importante: WiMax

offre un data rate molto alto (sopra i 75 Mb/s) con una copertura molto

ampia, sopra ai 50 km se non vi sono ostacoli, fino a scendere ad un range

che varia tra i due e i cinque chilometri in presenza di molti ostacoli.

Quindi vi e una gran differenza per quanto riguarda la copertura, tale aspetto

deve essere gestito con molta attenzione per fornire un handover senza inter-

ruzioni (per esempio preferendo le reti WiMax che avendo maggior copertura,

implicano l’attuazione di un minor numero di processi di handover).

Per quanto riguarda l’integrazione di WLANs e WMANs, si devono con-

siderare diversi scenari, per esempio il Single Mode (SM), ovvero quando il

nodo mobile ha solo un’interfaccia, oppure il Dual Mode (DM) quando il nodo

mobile e equipaggiato con due interfacce. Quest’ultimo scenario si avvicina a

quanto trattato nel progetto di tesi, in quanto si utilizza l’interfaccia wireless

e quella della rete mobile. Per quanto riguarda il DM, essendo il MN munito

di due interfacce potrebbe anche essere connesso contemporaneamente alla

Base station 1 (BS1) WiMax e all’access point 1 (AP1) Wi-Fi.

Il problema, al solito, e capire qual’e la connessione migliore tenendo conto

delle preferenze dell’utente, del QoS fornito in quella zona, ma anche della

disponibilita della rete. Inoltre, in alcuni scenari vi sono dei provider di servi-

zio che possiedono entrambe le reti (Wi-Fi e WiMax), solitamente in questo

caso la WLAN puo essere usata per scaricare la rete WiMax in caso di con-

gestione di quest’ultima. Riguardo al QoS, utile per capire se si necessita

di passare da una rete ad un’altra, e necessario effettuare una mappatura e

quindi implementare dei meccanismi di supervisione (cio che e stato fatto nel

progetto). Per quanto concerne l’aspetto economico, l’utente potrebbe pre-

ferire accessi a basso costo a discapito del QoS. In uno scenario con WiMAx


e Wi-Fi, solitamente si preferisce mantenere la connessione col WiMax se il

MN si muove ad alta velocita, in quanto si ha un’area di copertura maggiore

evitando cosı frequenti handover.

A tal proposito vi sono varianti alle modalita SM e DM, come l’utilizzo

di due gateway per ampliare la zona di copertura. Per esempio, si prenda

lo scenario in Figura 2.15: il MN5 accede ai servizi della BS1 utilizzando

un gateway che ne amplia la copertura. In questo caso il doppio gateway

funziona come un client per la rete WiMax ed e la chiave per l’integrazione.

Figura 2.15: Scenario con reti Wi-Fi e WiMax integrate.

Un altro esempio e il MN7, si ha DM per una rete Wi-Fi, infatti esso

usufruisce della connettivita wireless attraverso l’AP2 finche non si spostera

nella zona di copertura del WiMax. In quest’ultimo caso l’handover risulta

essere obbligatorio, in quanto il MN7 perdera la connettivita alla rete Wi-

Fi. Sono quindi necessari dei meccanismi per capire quale rete sta per cadere

(funzionalita implementata nel progetto di tesi). Un ultimo esempio, consiste


nel considerare il MN11, che si sposta dal WiMax al Wi-Fi per esempio

muovendosi in una struttura pubblica o nella metropolitana (dove il WiMax

viene schermato). Infine un’ulteriore concetto relativo alla Figura 2.15 e

quello dello scenario eterogeneo con multi-hop.

Innanzitutto, per single-hop si intende quando diverse tecnologie possono

essere integrate in una infrastruttura, mentre la mancanza di quest’ultima

viene indicata col termine multi-hop (o ad hoc). In tal senso vi e un concetto

”futuristico” di integrazione di reti eterogenee sia single-hop che multi-hop

chiamato Heterogeneous Multihop Wireless Networks (HMWNs), in grado

di fornire una maggior copertura. Per esempio in uno dei scenari appena

discussi in Figura 2.15, dove un MN si muove da WLAN a WiMax o viceversa,

il MN era connesso ad un AP/BS via single-hop. Ma nel HMWNs il MN

puo comunicare via multi-hop e la decisione del migliore AP/BS non e un

problema banale come prima, in quanto ora i nodi intermedi possono avere

caratteristiche a livello link diverse. Quindi HMWNs deve integrare entrambe

le gestioni di connettivita (sia Wi-Fi che WiMax). A tal proposito si devono

rivedere le gestioni delle connessioni, nonche il calcolo della qualita stimata

per la gestione dell’instradamento, in quanto puo essere diversa per ciascun

link eterogeneo che compone il collegamento end-to-end. HMWN sembra

essere una buona soluzione in quanto attualmente non c’e una tecnologia

wireless vincitrice per tutte le applicazioni correnti e future.

Precedentemente e stato proposto MIH come soluzione a scenari con ete-

rogeneita di tecnologie di accesso e connessione. Un’altra soluzione interes-

sante e proposta dalla Internet Engineering Task Force (IETF), si tratta del

Mobile IP (MIP) [8][12].

Mobile IP - MIP

Soluzione della IETF, che fornisce un nuovo indirizzo IP chiamato Care

of Address (CoA) al nodo mobile, quando esso si muove in un nuova rete.

La registrazione e l’aggiornamento del binding viene trasportato attraverso

delle comunicazioni tra l’Home Agent (HA) che si trova nelle rete di casa del


nodo mobile e l’agente esterno Foreing Agent (FA) che visita la rete. Vi sono

due versioni di MIP: MIPv4 che utilizza IPv4 e MIPv6 con IPv6.

In MIPv4 il Correspondent Node (CN), comunicando con il MN, manda i

pacchetti a quest’ultimo attraverso l’HA del MN. Questo potrebbe portare

a problemi di routing triangolare, con instradamenti molto lunghi e conse-

guente aumento del ritardo dovuto al fatto che l’HA fa da intermediario tra

MN e CN. MIPv6 evita tale problemi, in quanto il CN manda direttamente

i pacchetti al FA nella rete che si sta visitando. Per ridurre ulteriormente

i ritardi, e stata introdotta una variante chiamata Fast MIP (FMIP), che

velocizza la procedura di auto-configurazione dell’indirizzo. Cio e ottenuto

informando il MN del nuovo prefisso dell’access point, anticipando la confi-

gurazione del nuovo indirizzo (questo comporta una modifica del layer 2 dello

stack). MIPv6 cerca quindi di risolvere i problemi presenti in MIPv4, oltre a

quanto appena descritto, tale versione offre un header con un buon formato,

meccanismi per rilevare le reti vicine, sicurezza e qualita migliori nonche un

indirizzamento migliore.

Cio non significa che MIPv6 sia perfetto, per esempio, e risaputo che che

esso soffre di un ritardo considerevole nel processo di handover che porta alla

non conitnuita dei servizi. A riguardo, da tempo IETF e 3rd Generation

Partnership Project (3GPP) [12] stanno lavorando per rendere il tutto fun-

zionante al meglio. Questa piccola divagazione esula da quello che concerne

l’implementazione del progetto di tesi, serve pero a far capire che sia lo stato

dell’arte attuale che la ricerca in tale ambito sono in continua evoluzione.

2.3.3 Preconfigurazione dell’indirizzo IP e preautenti-

cazione

Come detto in precedenza, attualmente i protocolli utilizzati cosı come

si presentano con i loro meccanismi di handover non offrono un servizio ef-

ficiente [13] e si sta lavorando per creare algoritmi di handover per ridurre i

disturbi e le interruzioni durante tale processo. Alcuni risultati sono degni di

nota, ad esempio MIH appena descritto, ma vi e una tecnica che a tal pro-


posito, merita di essere presa in considerazione, ovvero la preconfigurazione

dell’indirizzo IP. Solitamente un dispositivo configura il suo nuovo indirizzo

IP (chiamato Care Of Address (CoA)) solo quando e collegato al nuovo access

point. Questo comporta che i pacchetti spediti da un qualsiasi altro nodo a

tale dispositivo, mentre esso sta cambiando il proprio indirizzo IP, vengano

persi. Cio non e accettabile per le applicazioni cosiddette time sensitive.

Si introduce quindi il concetto di pre-configuration IP, nel quale il nodo mo-

bile configura il nuovo CoA mentre e ancora collegato alla vecchia stazione

(che sara quindi in procinto di lasciare). Inoltre viene stabilito un tunnel

tra la vecchia stazione e quella nuova, per garantire l’inoltro dei pacchetti

durante il periodo di handover e minimizzarne quindi la perdita.

Tale approccio, facilita anche il cosiddetto Duplicate Address Detection (DAD)

che controlla l’unicita dell’indirizzo IP prima del tempo (ovvero prima che

esso venga effettivamente utilizzato). Nel progetto di tesi tale concetto viene

utilizzato in parte, infatti si prevede in anticipo se il dispositivo deve scolle-

garsi da un access point e collegarsi ad un altro. In tal caso se le interfacce di

rete coinvolte sono diverse allora si attiva l’interfaccia che verra utilizzata per

stabilire la nuova connessione in anticipo in modo da avere gia la connessione

stabilita quando l’altra interfaccia perdera il segnale dal vecchio access point.

Cio che non viene eseguito e il tunneling dei pacchetti, lasciando l’onere ad

ABPS (Always Best Packet Swtiching) [2]. La tecnica di preconfigurazio-

ne dell’indirizzo cosı come descritta in letteratura, prevede un overhead del

segnale comunque rilevante, nella versione implementata nel progetto, tale

overhead e ridotto in quanto manca la parte di traffico relativa allo scambio

di informazioni per instaurare il tunneling.

Oltre alla preconfigurazione dell’indirizzo IP, vi e un altro concetto inte-

ressate: la preautenticazione. E risaputo che anche anche la fase di auten-

ticazione contribuisce significativamente al ritardo nel processo di handover

[14]. Il concetto deriva dalla pre-configurazione dell’indirizzo e prevede quin-

di di autenticarsi a priori alla rete che verra successivamente utilizzata dopo

il processo di handover. Solitamente, si utilizza la connessione attuale per


stabilire un’associazione sicura con la nuova rete, utilizzando il protocollo

Protocol for carrying Authentication and Network Access (PANA) [15].

Si nota subito che perche cio avvenga, vi e la necessita che le reti coinvolte

in questo scenario eterogeneo devono supportare gli stessi meccanismi di au-

tenticazione. Vi e quindi il vantaggio che tale tecnica elimina i ritardi dovuti

all’autenticazione normale se effettuata durante il processo di handover, ma

necessita di caratteristiche ben precise da parte delle reti che costituiscono

lo scenario.

Quindi con questi nuovi concetti e l’avvento delle NGN, si ha che i prerequisiti

per avere un buon processo di handover sono:

• Un dispositivo mobile con piu interfacce.

• Uno scenario eterogeneo.

• La capacita da parte del dispositivo di capire quando e nella situazione

in cui deve tentare la connessione ad un’altra rete.

• Utilizzare la pre-autenticazione, ma questo come detto in precedenza,

necessita di avere reti con determinate caratteristiche.

Tutti questi concetti, comportano un miglioramento delle prestazioni del

processo di handover, mantenendo un overhead modesto. Nel progetto di

tesi, tali concetti sono stati utilizzati con le opportune rivisitazioni.

A tal proposito, si rimanda il lettore ai Capitoli 4 e 5 per i dettagli di pro-

gettzione ed implementativi, mentre nel Capitolo 7 sono presenti le analisi

dei risultati ottenuti.

2.3.4 Problematiche irrisolte

Come accennato in precedenza, il campo che concerne la gestione dell’han-

dover e la fornitura di un servizio con continuita e in continua evoluzione.

Come tutti i settori neofiti o comunque in fase di sviluppo, anche questo non

e esente da problematiche di svariato tipo, per esempio:


Figura 2.16: Esempio di scenario eterogeneo con reti all-IP dette NGN.

• Problematiche relative al QoS : con l’avvento delle reti wireless all-IP1 (Figura 2.16), si deve fornire un QoS garantito al dispositivo mobile.

Per offrire tale garanzia, in reti eterogenee, nascono nuovi problemi

legati alla gestione della mobilita e alla gestione della localizzazione

per un accesso efficiente.

• Problematiche relative al dispositivo mobile: e molto importante e com-

plesso, progettare dispositivi mobili che siano capaci di gestire l’hando-

ver in maniera efficiente e con tempistiche ridotte, data l’eterogeneita

delle tipologie di accesso alle reti. Il dispositivo deve essere in grado di

sfruttare molte informazioni, in modo da fornire delle funzionalita il piu

possibile precise. Questo pone l’attenzione anche su un altro aspetto,

quello degli algoritmi cognitivi, per la riconfigurazione dei dispositivi

mobili in tempo reale.

• Crescita delle reti wireless : l’aumento della dimensione delle reti wire-

less ha portato all’organizzazione di queste ultime in modo gerarchico,

affinche ciascuna di esse abbia un’area di copertura diversa, pur facendo

parte della stessa macro rete. La gestione della mobilita consideran-

do tale aspetto e una problematica importante e non completamente

esplorata.

1Il termine all-IP viene usato per identificare le reti NGN [12] New Generation Network,

ovvero quelle tipologie di reti integrate nei servizi che consentono il trasporto di tutte le

informazioni e dei servizi incapsulando le stesse in pacchetti. Solitamente tali reti sono

basate su IP.


• Servizi per la telefonia mobile: l’avvento di nuove tecnologie come il 4G,

date le loro caratteristiche, porteranno a dover gestire informazioni rela-

tive alla localizzazione e quelle relative al cosiddetto context-awareness

(la locazione implica come certi processi devono agire).

Cio e gia in fase di sviluppo. Inoltre i servizi futuri richiederanno quindi

gestioni della mobilita personalizzate e sempre piu complesse.

• Ottimizzazione del cross-layer : la localizzazione e la gestione della mo-

bilita attraverso il metodo cross-layer e promettente, ma in letteratura

ci sono ancora molti aspetti da migliorare, soprattutto legati al punto

precedente, ovvero l’adeguamento alle tecnologie emergenti.

• Altri aspetti : ci sono inoltre problematiche che non possono essere cata-

logate necessariamente in una delle categorie precedentemente citate,

un esempio sono la tolleranza ai guasti, il miglioramento della sicu-

rezza, la creazione di procedure intelligenti di selezione e scoperta di

gateway per un protocollo unificato. Infatti si sta cercando di creare

un solo protocollo capace di gestire l’handover per tutte le tecnologie,

in quanto i scenari con reti eterogenee sono sempre piu diffusi.

2.3.5 Conclusioni sullo stato dell’arte

In questa sezione e stato fornito un resoconto dello stato dell’arte relativo

al processo di handover e alla fornitura di connessioni seamless, ponendo

particolare attenzione all’elencare le varie tipologie di tale processo esistenti

e mettendo in evidenza le tecnologie emergenti o da migliorare su cui la ricerca

si sta orientando. A tal proposito, si stanno eseguendo numerose simulazioni

prima di implementare nuove soluzioni [16], ed e emerso che le procedure

riguardanti la mobilita sono inversamente proporzionali alla complessita delle

architetture integrate.

Un altro fattore importante, emerso in tale riassunto, e che per progettare

buoni meccanismi di handover si devono considerare le preferenze dell’utente,

per esempio, se un utente preferisce scaricare file solo con le WLANs qualora


siano disponibili. Inoltre, gli utenti sul loro dispositivo mobile possono ese-

guire piu applicazioni real-time contemporaneamente, e quindi sensato che

possano usufruire di diverse politiche di accesso, per esempio utilizzare le

reti con costi maggiori e con un QoS garantito per i servizi real-time, mentre

riservare quelle a basso costo e senza supporto per il QoS per i servizi best

effort. In aggiunta, vi sono i soliti parametri da considerare quali il profilo

dell’utente, la caratteristiche del dispositivo mobile, il carico della rete e le

politiche dell’operatore che fornisce il servizio.

Per quanto riguarda UMTS, approfondito in quanto utile ai fine del pro-

getto, e stato analizzato come le celle sono organizzate, mentre per quanto

riguarda una descrizione piu dettagliata di quali sono le componenti in gioco

si rimanda alla Sezione 3.7.

2.4 Contributo del lavoro

I contributi che si vogliono fornire allo stato dell’arte attuale col seguente

elaborato di tesi sono molteplici e verranno discussi in modo piu approfon-

dito nell’apposito Capitolo 8. Si puo comunque accennare che la soluzione

proposta, lavorando con ABPS, risolve pienamente la gestione del processo di

handover con tutte le problematiche relative al tuneling dei pacchetti quando

si cambia indirizzo IP e fornisce un valido algoritmo di predizione dell’uso

delle interfacce unito alla gestione della mobilita del dispositivo.

A tal proposito sono stati rivisitati alcuni concetti gia presenti in letteratura,

come la preconfigurazione dell’indirizzo IP e la preautenticazione, tralascian-

do per quanto riguarda il primo, caratteristiche come il tuneling dei pacchetti

ad ABPS.

Un altro contributo deriva dalle prove sperimentali eseguite per l’analisi

della perdita dei pacchetti rispetto all’utilizzo normale di Android che non

fornisce di per se i meccanismi discussi in questo progetto di tesi.

Sono quindi state effettuate delle prove per verificare la perdita dei pacchet-

ti in relazione agli algoritmi di predizione e di gestione degli spostamenti.

2.4 Contributo del lavoro 43

Ulteriori sperimentazioni riguardano uno scenario in cui il progetto lavori in

combinazione con ABPS, utilizzando una connessione TCP (Transmission

Control Protocol) e vi sia quindi la possibilita di gestire, in maniera traspa-

rente, il cambio di indirizzo IP durante una comunicazione.

L’ultimo contributo descritto e molto rilevante, in quanto in letteratura, vi so-

no spesso delle proposte per meccanismi di handover tra varie tecnologie (co-

me analizzato in precedenza), ma molte di esse sono discusse solo dal punto

di vista teorico non fornendo alcun esito su eventuali prove sperimentali.

Capitolo 3

Strumenti e tecnologie

In questo capitolo vengono descritti gli strumenti utilizzati per lo svilup-

po del progetto e le tecnologie coinvolte. Per quanto riguarda i primi, ci si

riferisce a programmi, librerie e software aggiuntivo utilizzati per sviluppare

il codice o per gestire i device. Mentre per tecnologie, si intende quali sono

le parti in gioco utilizzate per offrire la continuita di connessione, obbiettivo

finale del progetto. Avendo i dispositivi mobili piu comuni e di fascia media,

principalmente le interfacce wireless e di connessione dati del provider nonche

un’antenna gps, sono state per l’appunto usate tali tecnologie che verranno

trattate principalmente nelle loro caratteristiche fondamentali, utili allo svi-

luppo del progetto e quindi nell’implementazione del codice, tralasciando una

descrizione completa che risulterebbe onerosa in termini di spazio e che esula

dall’obbiettivo dell’elaborato di tesi.

3.1 Android

Android [17] e un sistema operativo mobile basato sul kernel Linux e su un

modello open source, con componenti software integrati proprietari di Goo-

gle. Al momento della scrittura di questo documento (Febbraio 2015), tale

sistema occupava il 67,3% del mercato in Italia [18], IoS deteneva il 18,3% e

Windows Phone il 12,7% , mentre la rimanente fetta di mercato e suddivisa

45

46 3. Strumenti e tecnologie

tra sistemi operativi che ormai sono in via di estinzione come BlackBerry e

Symbian. A tal proposito si e deciso di sviluppare il progetto di tesi su tale

sistema operativo, in quanto il piu diffuso, insieme alla motivazione legata ai

costi delle spese di sviluppo discusse precedentemente nel Capitolo 2.

Per quanto riguarda il solo Android, la diffusione delle varie versioni del

sistema operativo e stata trattata precedentemente nella Figura 2.1 del Ca-

pitolo 2, ponendo attenzione sul fatto che la predominante forse JellyBean,

incalzata da KitKat, versioni per le quali e stato per l’appunto sviluppato il

progetto (in particolare JellyBean 4.2.2 e KitKat 4.4 e 4.4.1).

Il linguaggio principale per lo sviluppo di applicativi in questo caso e Java,

sia per quanto riguarda il controllo dell’interfaccia grafica che per la scrittu-

ra del back-end. Inoltre, da tale linguaggio e possibile richiamare procedure

scritte in codice nativo attraverso il Native Development Kit, caratteristica

non utilizzata in questo progetto ma che potrebbe tornare utile per risolvere

alcuni problemi di sicurezza legati all’utilizzo del GPS (si rimanda al Capi-

tolo 9). Oltre ai dispositivi mobili, Android sta avendo un discreto successo

anche per quanto riguarda le smartTv, per i neofiti orologi da polso (Android

Wear) e per i Google Glass. Alcune delle caratteristiche che lo distinguono

sono la liberta di utilizzo (per esempio di modding del dispositivo) a discapito

della facilita di uso a differenza per esempio di IoS. Questa sezione non ha

lo scopo di entrare nei dettagli, verra quindi trattata una breve descrizione

storica di Android, posticipando invece le caratteristiche e gli aspetti chiave,

nonche le problematiche riscontrate durante lo sviluppo del codice nel Capi-

tolo 5. Inizialmente il progetto fu sviluppato dalla compagnia Android Inc a

cui facevano capo Andy Rubin, Rich Miner, Nick Sears e Chris White, tale

progetto era supportato finanziariamente e poi fu acquisito da Google nel

2005. Nel 2007 viene rivelato al mondo, insieme alla fondazione della Open

Handest Alliance (OHA), un consorzio di aziende dell’hardware, software e

delle telecomunicazioni votato alla definizione di standard aperti per i dispo-

sitivi mobili. Il 5 Novembre 2007 venne presentato ufficialmente il progetto

dalla stessa OHA.

3.1 Android 47

Il 22 Ottobre 2008 esce il primo smartphone con Android, l’HTC Dream.

Il codice Android e stato rilasciato da Google sotto la licenza di Apache

2.0, permettendo la libera modifica e distribuzione da parte dei produttori

di hardware e dei developer e decretandone quindi un ampio successo.

Infatti tutt’oggi le case produttrici personalizzano il sistema operativo con

caratteristiche particolari, distinguendolo da quello rilasciato coi dispositivi

degli altri produttori. Cio che non e sotto licenza open sono ovviamente i

driver proprietari inclusi dai produttori stessi nei dispositivi.

Dal primo rilascio ogni aggiornamento o nuova release, come accade per molte

distribuzioni di Linux, segue l’ordine alfabetico e una precisa convenzione

per i nomi, che in questo caso sono quelli di dolci: la versione 1.5 prese

il nome Cupcake che venne seguita dalla versione 1.6 Donut, la 2.1 venne

chiamata Eclair, la 2.2 Froyo, la 2.3 Gingerbread, la 3.0 Honeycomb rilasciata

principalmente per i tablet con scarso successo, la 4.0 Ice Cream Sandwich,

la 4.1 Jelly Bean, la 4.4 inizialmente prevista come Key lime pie diventa Kit

Kat in seguito ad un accordo con la Nestle, mentre la piu recente, lanciata il

14 ottobre 2014, e la 5.0, col nome Lollipop.

Android e costituito da un Kernel basato sul kernel Linux 2.6 e 3.x (da

Android 4.0 in poi), con middleware, Librerie e API scritte in C (o C++) e

software in esecuzione su un framework di applicazioni che include librerie

Java. La struttura del sistema e mostrata in Figura 3.1. Android utilizza la

Dalvik virtual machine con un compilatore just-in-time1 per l’esecuzione del

codice esegubile Dalvik dex-code, che di solito viene tradotto da codice byte-

code Java. La Dalvik e una macchina virtuale, progettata da Dan Bornstein,

dipendente di Google, ottimizzata per sfruttare poca memoria e consente

di far girare diverse istanze della macchina virtuale contemporaneamente,

nascondendo al sistema operativo sottostante la gestione della memoria e

dei thread. La piattaforma hardware principale di Android e l’architettura

1Un compilatore just-in-time permette una compilazione detta ”traduzione dinami-

ca” con la quale e possibile aumentare le prestazioni dei sistemi di programmazione

che utilizzano il bytecode, traducendo il bytecode nel codice macchina nativo in fase di

run-time.


ARM, mentre l’architettura x86 e supportata specialmente per le smartTv.

Come detto in precedenza, il linguaggio per sviluppare le applicazioni e Ja-

va, quindi le applicazioni scritte in codice nativo in C/C++ devono essere

richiamate dal codice Java, di conseguenza, anche i file C e C++ devono fare

parte dello stesso progetto, il quale produce alla fine un pacchetto Android

(APK).

Quest’ultimo e il file compresso contenente l’eseguibile dell’applicazione (.dex),

le sue risorse (immagini, suoni ecc ecc...), alcuni file XML che definiscono le

proprieta dell’applicazione stessa e delle activity (vedere la sottosezione 3.2.2

a riguardo) che la compongono.

Figura 3.1: Schema dell’architettura di Android.

A differenza di quanto accade con Linux, agli utenti dei dispositivi An-

droid, non sono resi disponibili i privilegi di root al momento dell’acquisto

del dispositivo. Tuttavia, l’accesso come root sui dispositivi e quasi sempre

possibile, a tal proposito si rimanda alla sezione 3.5 di questo capitolo.

La piattaforma usa SQLite per la gestione delle basi di dati (sezione 3.4).

3.1 Android 49

Una caratteristica molto interessante di Android e quella di gestire dei

servizi (i cosiddetti service) in background, il cui funzionamento non viene

influenzato dall’interazione dell’utente con le applicazioni visualizzate in quel

momento sullo schermo. Questo aspetto e molto interessante ed e stato uti-

lizzato ai fini del progetto, in quanto dopo il primo avvio dell’applicazione,

l’utente puo decidere per le esecuzioni successive se utilizzarla come servizio,

in modo tale da non essere invasiva ai fini dell’utilizzo quotidiano.

Tale aspetto, pone inoltre risalto a come venga data l’opportunita di im-

plementare un vero e proprio multitasking, dando la possibilita di eseguire

un’applicazione senza che questa possa quindi influenzare o essere influenzata

da altre applicazioni o servizi.

E inoltre bene considerare, come accennato nel Capitolo 2, che dalla ver-

sione Lollipop il team di sviluppatori ha messo a disposizione una funzionalita

chiamata aggressive wifi to cellular handover che dovrebbe fare in modo che il

dispositivo qualora si connesso ad una cella telefonica riesca a capire di essere

situato in una locazione in cui puo connettersi a una rete wifi (di cui dispone

la configurazione o perche e aperta). Tale funzionalita, seppure apprezzata

presenta ancora diverse problematiche, in quanto i dispositivi tendono a stare

ugualmente connessi per la maggior parte del tempo alle celle telefoniche.

Infine c’e da porre particolare attenzione su alcuni aspetti di Android: es-

so gestisce l’accesso al GPS in maniera molto sicura, non dando la possibilita

all’utente attraverso i metodi offerti dalle API di interagirvi direttamente.

Un’altra caratteristica interessante e relativa alla gestione delle reti wireless,

in particolar modo delle loro configurazioni e alla priorita che il sistema vi

assegna una volta che tali configurazioni vengono create dall’utente: il si-

stema tende ad assegnare priorita maggiore a quelle create con la procedura

guidata rispetto a quelle che vengono create manualmente da terze parti (per

esempio dal codice modificando gli opportuni file di sistema).

Quest’ultimo aspetto, insieme a quello della geolocalizzazione appena descrit-

to, sono risultati essere limitanti nella stesura del codice e quindi verranno

trattati in maniera piu approfondita nella sezione 5.2.


Chiudendo questa veloce panoramica su Android, per quanto riguarda

l’implementazione del progetto sono stati utilizzati i seguenti dispositivi, di

cui si descrivono le specifiche tecniche utili al fini dell’elaborato di tesi tra-

lasciando quelle non fondamentali (come per esempio la fotocamera, durata

della batteria, dimensione dello schermo ecc ecc..):

• Sony Xperia L: Android JellyBean aggiornato alla versione 4.2.2, CPU

Qualcomm MSM8230 dual-core da 1 GHz, 1 GB di Ram, 8GB di

memoria espandibile con scheda SD.

• LG Nexus 5: Android KitKat 4.4 (il progetto e stato testato sia sulla

versione 4.4 di rilascio che sulla 4.4.4 aggiornata), CPU Qualcomm

Snapdragon 800 da 2,26 GHz, 2 GB di Ram, 16 GB di memoria.

3.2 Eclipse

Per l’implementazione del codice e stato utilizzato come IDE (Integrated

Developement Enviroment) Eclipse [28] nella versione Juno (4.2.1.v20130118)

a cui e stata aggiunta l’ADT (Android Developer Tools) [29] in versione

23.0.2.1259578 installato come pulgin ed infine e stata l’utilizzata l’SDK

(Software Developement Kit) di Android [30]. Con quest’ultima, sono state

scaircate le API in versione 19 per JellyBean e 20 per KitKat.

Per quanto riguarda Eclipse, e un IDE molto diffuso di cui si omette qual-

siasi spiegazione relativa al suo utilizzo in quanto esula dallo scopo di questo

documento di tesi. Ci si sofferma invece, per motivare il perche della sua scel-

ta, infatti insieme ad Android Studio sono i due IDE piu utilizzati per l’im-

plementazione di applicazioni in ambiente Android. Si e optato per Eclipse

in quanto utilizzato in precedenti corsi, principalmente in quello di Labora-

torio di applicazioni mobili in cui viene appunto spiegato come sviluppare

applicazioni per Android e IoS. Inoltre Eclipse, offre un’ottima integrazione

dell’SDK richiamabile direttamente dall’IDE stesso attraverso l’apposito plu-

gin ADT, dando la possibilita di cambiare velocemente dall’interfaccia stessa

3.2 Eclipse 51

la versione di SDK in uso, in modo da modificare automaticamente gli op-

portuni file di configurazione. Questa caratteristica risulta essere molto utile

per testare l’applicazione su diverse versioni di Android. Oltre a cio, tale

IDE fornisce i classici strumenti e funzionalita per gestire un progetto Java,

caratteristiche ereditate per quanto riguarda l’implementazione di codice in

ambiente Android.

3.2.1 ADT

Come detto in precedenza, l’ADT (Android Developement Tools) e stato

installato come plugin in Eclipse. L’ADT offre alcune funzionalita interessan-

ti ed indispensabili velocizzando la creazione di progetti Android, mettendo

a disposizione una GUI per accedere a molte delle funzionalita dei strumenti

dell’SDK altrimenti utilizzabili tramite linea di comando (per alcuni e stato

comunque preferito l’utilizzo di quest’ultima in quanto piu veloce nei tem-

pi di risposta). Tra le funzionalita piu importanti si ricorda la possibilita

di richiamare direttamente all’interno di Eclipse strumenti dell’SDK quali il

logcat e DDMS (Dalvik Debug Monitor Server) [31].

ADT offre quindi ampie funzionalita di prototipazione, progettazione e

compilazione dei progetti Android, una particolarmente interessante, soprat-

tutto per chi non dispone di un dispositivo con tale sistema operativo, e la

possibilita di creare dispositivi virtuali per poter testare le applicazioni.

Vi sono inoltre gia presenti alcuni dispositivi virtuali (i piu famosi nella storia

di Android quali il Nexus One o Nexus S), vi e comunque la possibilita di

customizzare un proprio dispositivo settandonde la RAM, potenza del pro-

cessore, spazio di archiviazione e quant’altro. C’e sottolineare che questa

interessante funzionalita non e stata utilizzata nel progetto, sia per il fatto

che si avevano a disposizione i dispositivi fisici su cui testare il codice ma an-

che perche alcune funzionalita indispensabili come l’interazione col wireless,

la connessione dati mobile e il GPS non sono disponibili. I dispositivi so-

no quindi stati collegati al computer via cavo USB, avendo preventivamente

sbloccato le impostazioni di sviluppatore e abilitato le opzioni di debug.


LogCat

E il sistema di Android per visualizzare l’output del debug potendolo

gestire secondo diversi criteri, per esempio, assegnando dei tag durante la

programmazione, oppure differenziando per tipologia di messaggio (di debug,

di errore, warm ecc ecc...).

Puo essere utilizzato sia da Eclipse che da linea di comando, come mo-

strato in Figura 3.2. In quest’ultimo caso, per quanto riguarda il progetto in

questione, posizionandosi nella cartella platform-tools dell’SDK, e possibile

filtrare i messaggi del LogCat per tag con la seguente istruzione:

1 ./adb logcat −s ConnectionPointAnalyzer

Figura 3.2: Il LogCat visto da Eclipse e da linea di comando.

DDMS - Dalvik Debug Monitor Server

Il DDMS (Dalvik Debug Monitor Server) mette a disposizione del pro-

grammatore svariate funzionalita quali il logCat, il port forwarding, la pos-

3.2 Eclipse 53

sibilita di catturare le schermate dei dispositivi collegati, ma cosa piu impor-

tante, permette di monitorare lo stato dei thread che vengono lanciati durante

l’esecuzione del programma, dell’heap e del garbage collector. Inoltre offre

altre utilita, piu marginali, come la gestione delle chiamate e dei messaggi

(di testo non quelli tramite connessione dati) in ingresso. Tale strumento e

stato ampiamente utilizzato per monitorare lo stato della memoria duran-

te l’implementazione del progetto, in modo da costruire un’applicazione che

sia ”onesta” in tali termini, nonche per controllare l’esecuzione dei thread,

in quanto si e cercato di sfruttare quando possibile, il fatto che la maggior

parte dei dispositivi ormai e equipaggiata con piu di un processore.

Quindi, per esempio, quando si tratta di effettuare dei servizi di scansione su

interfacce diverse vengono creati thread separati.

DDMS e richiamabile direttamente da Eclipse, oppure posizionandosi nel-

la cartella tools dell’SDK. Inoltre per il suo funzionamento si appoggia su adb

(Android Debug Bridge) [35] e quando un dispositivo viene connesso, viene

creato automaticamente un processo che lo monitorizza e che termina quando

viene disconnesso.

Infine viene menzionata separatamente la possibilita di tracciare il traf-

fico del dispositivo (come mostrato in Figura 3.3), sia per quanto riguarda

l’interfaccia wireless che quella relativa ai dati mobili. Questa e una caratte-

ristica molto importante che ha permesso di fare un confronto della quantita

pacchetti persi, con e senza l’utilizzo dell’Oracolo (a tal proposito si rimanda

il lettore al Capitolo 7). La possibilita di monitorare il traffico dei pacchetti

e prevista solo da Android 4 in poi. Per fare uno studio completo, si deve

innanzitutto selezionare la funzionalita network di DDMS, bloccare i restan-

ti processi che utilizzano l’interfaccia di rete desiderata (possibile attraverso

l’utilizzo di gestori avanzati dei processi scaricabili dal PlayStore) ed avviare

un’applicazione ”tipo” per testare tale scenario. Per le prove e stata utiliz-

zata LINE [32], una chat che permette di fare anche chiamate e condivisione

di file. Come accennato poco fa, per bloccare i processi che utilizzano le

interfaccce di rete serve un’applicazione con funzionalita avanzate rispetto al


gestore dei processi di sistema fornito da Android. Infatti se tale operazione

viene eseguita da quest’ultimo, successivamente Android riavvia comunque i

processi di sistema.

Figura 3.3: La funzionalita di monitoraggio del traffico di rete con DDMS.

Sono state quindi effettuate delle prove standard per entrambi gli scenari,

per esempio il trasferimento dello stesso file, che dovrebbe richiedere quin-

di la stessa quantita di pacchetti: vengono valutati il tempo impiegato e la

quantita di pacchetti scambiati (quest’ultimo parametro e sensibile al reinol-

tro di quelli andati persi). Tale esperimento viene descritto nella sezione 7.2

e serve per confermare il buon funzionamento del meccanismo di predizione

dell’utilizzo delle interfacce.

adb shell

ADB shell permette di avviare una shell UNIX in cui poter eseguire tutta

una serie di comandi, sia un dispositivo fisico collegato al computer, che su

3.2 Eclipse 55

un dispositivo virtuale avviato dal simulatore. L’utility e avviabile una volta

posizionati nella cartella platform-tools dell’SDK, attraverso l’omonimo co-

mando. Dato che i dispositivi utilizzati hanno i permessi di root, anche da

shell e stato possibile utilizzare operazione che prevedevano l’utilizzo di tali

permessi. Seppure non necessaria in senso stretto ai fini del progetto, tale

utility e stata ampiamente utilizzata, in quanto ha permesso di controllare

rapidamente il contenuto della cartella dell’applicazione, verificare che i fi-

le di sistema per la gestione delle interfacce di rete venissero correttamente

modificati dall’applicativo. Inoltre si e rivelata utile per eseguire una serie di

script bash contenenti comandi adb shell, atti ad installare e disinstallare di-

verse varianti del progetto stesso in fase di testing. Quindi come risulta essere

in qualsiasi sistema UNIX, l’utilizzo della shell, spesso semplifica le opera-

zioni da fare e le rende piu veloci. In alternativa, la consultazione dei file di

determinate cartelle a cui solitamente non si avrebbe accesso, risulterebbe

essere un’operazione onerosa in termini di tempo, in quanto richiederebbe

l’installazione di software di terze parti che utilizzano i permessi di root, per

navigare tra i contenuti del dispositivo. Lo stesso discorso si puo fare per

quanto riguarda la modifica dei file di sistema in fase di testing.

Oltre ai comandi UNIX, ADB shell mette a disposizione alcune novita ap-

posite per Android, come la possibilita di caricare e scaricare file sulla mac-

china a cui il dispositivo e connesso. Queste ultime funzionalita, sono state

utilizzate per rimpiazzare il file contenente le configurazioni delle reti, con

altri creati ad-hoc per testare casi particolari, in cui l’applicazione fosse mes-

sa in difficolta nel costruire la classifica delle migliori reti candidate a cui

connettersi.

Infine, ancora qualche funzionalita interessante su ADB shell, degne di

attenzione sono infatti am e pm: la prima sta per activity manager e come

si evince dal nome, serve per gestire le activities, ovvero lanciare un’activity,

stopparla forzatamente, fare il broadcast di un intent e via dicendo.

La seconda invece e l’acronimo di package manager, utilizzato per il progetto

all’interno di opportuni file bash per installare e disinstallare l’applicazione


come descritto precedentemente con diverse varianti, senza dover ricorrere

all’apposita funzionalita di sistema da dispositivo che oltre ad essere meno

completa dal punto di vista delle opzioni, risulta anche piu onerosa in termini

di tempo.

3.2.2 Java

Come accennato piu volte in questo documento di tesi, il linguaggio di

programmazione utilizzato per sviluppare applicazioni per Android e Java,

linguaggio di programmazione orientato ad oggetti molto diffuso.

Questa sezione non ha lo scopo di descrivere tutti gli aspetti del linguaggio,

tanto meno di descriverne le regole sintattiche, ci si focalizza invece sugli

aspetti caratteristici per quanto riguarda la programmazione in ambiente

Android ed in particolare ai concetti piu importanti utilizzati nell’implemen-

tazione del codice.

E risaputo che la compilazione di codice Java, produce del bytecode che

puo essere eseguito da una qualunque implementazione di un processore vir-

tuale detto JVM (Java Virtual Machine). Come accennato in precedenza

nella sezione 3.1, Android utilizza al posto della JVM un’altra macchina vir-

tuale detta DVM (Dalvik Virtual Machine). La differenza principale tra le

due e che la DVM e basata sui registri e progettata per girare occupando

poca memoria, inoltre esegue dei file di estensione .dex. La JVM invece e

basata sullo stack, e usa il java bytecode, eseguendo file .class. Il sorgente

Java viene compilato dal compilatore Java in file di estensione .class.

Quindi tramite l’SDK di Android vengono processati tali file .class, generan-

do i corrispettivi formato .dex che contengono Dalvik bytecode.

Una delle differenze principali e che in DEX, tutte le classi di un’applicazione

sono inserite in un unico file. Inoltre la DVM, e stata progettata in modo che

i dispositivi possano eseguire differenti istanze di tale macchina virtuale in

modo efficiente. Come detto in precedenza la JVM e stack-based, deve quindi

usare delle istruzioni per caricare i dati sullo stack e manipolarli, cio implica

l’utilizzo di piu istruzioni rispetto ad una macchina basata sui registri (come

3.2 Eclipse 57

la DVM) per implementare lo steso codice ad alto livello, motivo per il quale

solitamente la JVM richiede piu memoria rispetto alla DVM.

In aggiunta alle librerie standard, il programmatore puo utilizzare un

numero arbitrario di librerie di terze parti. Queste librerie, contenute in vari

package, vengono utilizzate per sfruttare determinati metodi o attributi da

esse messi a disposizione in modo da rendere piu funzionale il codice nonche

semplificarne l’implementazione. A tal proposito per il progetto si e fatto

uso di librerie esterne a Java che verranno discusse nella sezione 3.2.3.

Un’altra caratteristica, che differenzia l’implementazione di un program-

ma Java standard da uno Android e la mancanza del classico metodo main,

da dove solitamente parte l’esecuzione di un programma. In Android, infatti,

l’ambiente e event driven, ovvero guidato dagli eventi, che possono deriva-

re dall’interazione dell’utente con l’interfaccia, ma anche dall’evocazione da

parte di hardware o software presenti sul dispositivo. Oltre alla mancanza

del metodo main, in Android un’applicazione solitamente viene avviata mo-

strano l’activity principale, che viene inizializzata da un metodo chiamato

OnCreate, da quel punto in poi, il programmatore deve gestire i flussi di

codice considerando il cilo di vita dell’activity stessa e qualora sia necessa-

rio, utilizzare altre activity. Riguardo a quest’ultimo concetto si rimanda il

lettore alla sottosezione sottostante.

Infine, una caratteristica molto importante riguarda la possibilita di con-

dividere funzionalita e risorse o far comunicare un’applicazione Android con

altre presenti sul dispositivo attraverso, l’utilizzo di intent. A tal proposito,

si rimanda il lettore ai Capitoli 4 e 5.

Activity e Service

In precedenza e stato detto che l’esecuzione di un’applicazione Android

solitamente parte dal metodo OnCreate dell’activity principale.

Prima di analizzare i vari stadi di vita di un’activity (mostrati in Figura 3.4),

viene effettuata una breve descrizione per capire di cosa si tratta e quali sono


le differenze tra essa e un servizio (concetto anch’esso utilizzato nel progetto

di tesi).

Per prima cosa, un’activity la si puo definire come ”cio che viene fatto

partire dal dispositivo”, quindi, quello che l’utente vede sullo schermo del

proprio smartphone o tablet e un’activity. Oltre a cio le activity contengono

le informazioni dell’applicazione. Per definire un’activity bisogna definire,

oltre al codice Java che ne delinea il comportamento e le funzionalita , anche

un file XML che ne descrive la struttura (componenti contenute e loro carat-

teristiche). Inoltre, tutte le activity facenti parte di un’applicazione devono

essere dichiarate in un file XML che descrive l’intera applicazione detto Ma-

nifest. In quest’ultimo file oltre a dichiarare le varie activity, vengono definite

altre informazioni, quali i permessi che l’applicazione deve avere, caratteri-

stiche ”globali” come l’orientamento dell’interfaccia, il nome, la versione di

SDK di riferimento e quella minima richiesta per un corretto funzionamento.

Vi sono anche altre informazioni e caratteristiche che si possono definire nel

manifest, nel caso del progetto e stato dichiarato che l’applicazione parte

automaticamente all’avvio del telefono come servizio.

Come detto in precedenza, si ha una programmazione event driven, quindi

le activity permettono di definire al loro interno tutta una serie di metodi

per gestire tali eventi, come ad esempio il tap dell’utente su un pulsante.

Inoltre, possono a loro volta chiamare altre activity facenti parte della stessa

applicazione, oppure un programma esterno (in maniera specifica o lasciando

comunque scegliere all’utente). Tali possibilita sono permesse grazie a delle

direttive chiamate intent, che nel progetto sono state utilizzate sia per lo

scopo appena descritto, che per effettuare chiamate di sistema, ma anche per

evocare dei servizi di cui si parlera a breve, in quanto spesso vengono confusi

con le activity stesse.

Facendo riferimento alla Figura 3.4, la vita di un’activity inizia col me-

todo OnCreate, che viene utilizzato principalmente per settare il contenuto

di quest’ulitma (quello che effettivamente l’utente vede sul proprio display)

e per fare le prime operazioni di inizializzazione. E una buona regola di

3.2 Eclipse 59

Figura 3.4: Ciclo di vita di una activity.

programmazione, quella di eseguire poche operazioni in questo metodo, in

quanto e in relazione con la velocita di avvio dell’applicazione stessa.

Per quanto riguarda il progetto, infatti, tale metodo si occupa di vedere se

l’applicazione e al primo avvio, quali opzioni sono state selezionate dall’uten-

te e poco altro per rendere il tutto il piu veloce possibile. Una volta usciti

dal metodo OnCreate, viene chiamato il metodo onStart (poco prima che la

activity venga visualizzata all’utente). Se l’activity ha il focus sullo schermo

allora viene chiamato il metodo onResume, altrimenti il metodo onStop.

Il metodo onResume, viene quindi invocato quando l’activity e pronta all’u-


so e l’utente puo interargirvi; puo anche essere richiamato quando l’activity

viene riesumata, ovvero quando torna visibile dopo che era gia stata avvia-

ta. Se anche il metodo onResume termina correttamente allora l’activity

e effettivamente in esecuzione. Inoltre, vi sono altri metodi, quali onPause

che viene richiamato quando l’activity non ha piu il focus o quando l’utente

esce di propria iniziativa dall’applicazione: in tal caso il processore smette di

eseguire il codice dell’applicazione. Il metodo onRestart invece, e simile al-

la onCreate, ma viene chiamato quando un’activity e stata precedentemente

stoppata. Quest’ultima azione viene evocata dal metodo onStop, cio accade

quando l’activity sta per essere distrutta dal sistema operativo in quanto da

molto inattiva, oppure perche vi sono troppe activity in foreground senza

focus. Il metodo onDestroy, invece, viene chiamato quando si vuole chiudere

del tutto l’activity, come detto in precedenza puo essere lo stesso sitema ope-

rativo a volerlo fare perche magari si necessita di spazio in memoria, oppure

puo essere richiamato volutamente dal programmatore.

Detto cio, bisogna implementare il codice nei metodi corretti, evitando

di rendere pesanti i metodi che sono responsabili dell’apertura dell’activi-

ty e della sua riesumazione qualora non abbia la focus. Infatti riesumare

un’applicazione dalla memoria spesso risulta oneroso, se il metodo onResu-

me contiene del codice che richiede molto tempo d’esecuzione.

Per quanto riguarda il progetto infatti, si e evitato di caricare tali metodi

da moli di lavoro eccessive, infatti l’algoritmo principale che gestisce i pro-

cessi decisionali e di attuazione dell’handover, viene eseguito da dei servizi

richiamati fuori dai metodi suddetti. Ovviamente per questioni inerenti al

risparmio energetico, i metodi adibiti al mettere in pausa e al riesumare l’ap-

plicazione devono forzatamente gestire la disattivazione e l’attivazione delle

interfacce: infatti se l’utente ha deciso di eseguire l’applicazione in manie-

ra ortodossa e non come servizio in background, allora se l’activity perde

di focus per molto tempo le interfacce vengono disattivate prima che venga

chiamato il metodo onDestroy.

Per quanto riguarda i servizi (service in Android) [38], la differenza prin-

3.2 Eclipse 61

cipale tra activity e questi ultimi sta nel fatto che un servizio spesso non

viene visualizzato come componente vera e propria nell’interfaccia grafica,

ma tende ad essere un’entita, che viene eseguita in background e serve per

fornire funzionalita aggiuntive all’applicazione stessa o ad altre.

I servizi solitamente vengono lanciati da un’activity, Android ne mette a di-

sposizione del programmatore una vasta quantita che varia dalla gestione

dell’energia, ai sensori, all’audio, alla telefonia, connettivita e via dicendo.

Alcuni di essi sono ovviamente stati utilizzati nel progetto, basti penare alla

gestione dell’interfaccia wireless o dei sensori quali l’accelerometro per gesti-

re l’orientamento dell’interfaccia, a quelli della telefonia e della connettivita

relativa ai dati mobili. L’utilizzo dei servizi non si e limitato a quanto offer-

to dalle API di Android, infatti e stato implementato un servizio ad-hoc per

l’applicazione in grado di eseguire thread in parallelo per effettuare le scansio-

ni delle interfacce di rete ad intervalli settati dall’utente. Inoltre, se l’utente

lo desidera, puo settare opportunamente le impostazione e decidere di esegui-

re l’applicazione come servizio di sistema agli avvii successivi del dispositivo.

Quest’ultima caratteristica va specificata nel manifest dell’applicazione.

Un service, come qualsiasi altro oggetto, viene eseguito nel processo prin-

cipale di un’applicazione, di conseguenza se l’utente sceglie di eseguire l’Oracolo

come servizio all’avvio, viene per prima cosa lanciata l’applicazione dopo il

boot, avviato il servizio che include l’algoritmo di gestione dell’handover e

tolto il focus dall’applicazione, forzando il sistema a non uccidere il processo

principale. In questo modo, l’utente ha il servizio in background che esegue

esattamente le stesse funzionalita dell’applicazione quando essa e visualizza-

ta sul display, pero le risorse relative all’interfaccia grafica sono liberate, in

quanto viene gestito il garbage collector a riguardo. Se l’utente apre l’appli-

cazione vera e propria dal menu del dispositivo, essa risultera comunque in

esecuzione, in quanto effettivamente sta girando in background, l’unica cosa

che viene fatta in questo caso e caricare opportunamente l’interfaccia grafica.

Per ulteriori dettagli si rimanda alla sezione 4.1.3.


3.2.3 RootTools e SupportLibrary

Come detto in precedenza, Java permette l’utilizzo di librerie di terze

parti, RootTools [39] ne e un esempio ed e stata utilizzato nel progetto di

tesi in quanto offre alcune funzionalita interessanti per sviluppare applica-

zioni che richiedono i permessi di root. In particolare, per quanto riguarda

il progetto di tesi, ha permesso attraverso semplici metodi, di eseguire dei

comandi adb shell con tali permessi. Se puo sembrare banale, per i comandi

base, in quanto si potrebbero utilizzare i metodi built-in, per circostanze piu

complesse, risulta essere molto utile.

Per esempio, tale libreria e stata utilizzata per accedere a file di sistema:

per controllare l’intervallo di scansione delle interfacce e modificarlo con i va-

lori precisati dall’utente (in tal caso si necessita anche di cambiare i permessi

di tali file, sempre con RootTools). Altre circostanze in cui e stata utilizzata,

sono il controllo delle proprieta del file in cui Android salva le configurazio-

ni di rete, per controllare se l’utente ha modificato suddette impostazioni

mentre l’applicazione e in uso: per effettuare cio, quest’ultima quando viene

avviata, controlla se il file delle impostazioni ha modifiche rispetto ad una

copia presente nella cartella proprietaria. Risulta evidente che non si accede

solamente al contenuto di questi file, ma vi e la necessita di copiare quello ori-

ginale se per esempio non e presente nella cartella dell’applicazione o qualora

sia stato modificato. In tutte queste occasioni e stata utilizzata RootTools.

Per evidenziare la semplicita di utilizzo, uno schema molto diffuso e il

seguente:

Esempio di utilizzo di RootTools (pt 1)

1 RootTools.debugMode = true;

2 CommandCapture command = new CommandCapture(0, <comando>);

3 try

4 RootTools.getShell(true).add(command);

5 catch (Exception e) {6 //GESTIONE DELL’ECCEZIONE

7 }

3.2 Eclipse 63

Ovviamente la tipologia di eccezione dipende dal comando che viene ese-

guito. L’importante di tale schema e sottolineare come si possano definire i

comandi adb shell (riga 2) e poi eseguirli (riga 4). Come si puo notare sempre

da tale esempio, e possibile specificare la modalita con cui si puo utilizzare

la libreria: e sempre stata attivata la modalita debug per verificare eventuali

problematiche.

Inoltre e possibile evitare di specificare un comando alla volta ma per

esempio passando un array di stringhe dove ogni cella corrisponde un’istru-

zione, in tal caso la gestione delle eccezioni risulta piu complessa.

Oltre a quanto descritto, la libreria offre altre funzionalita come controllare

se il dispositivo ha i permessi di root, gestire i log.

In precedenza, si e accennato a come RootTools faciliti l’utilizzo di co-

mandi complessi. Un esempio e la gestione dell’output di un comando, per

esempio il cat. Il codice qui di seguito mostra la linea guida per gestire

l’output di un generico comando (o piu di uno):

Esempio di utilizzo di RootTools (pt 2)

1 try {2 List<String> output = RootTools.sendShell(command);

3 String[] commands = new String[] { command1, command2 };4 List<String> otherOutput = RootTools.sendShell(commands);

5 } catch (IOException e) {6 // GESTIONE DELLE ECCEZIONI

7 }

Termina qui la descrizione della libreria RootTools che pero non e l’u-

nica ad essere stata utilizzata nel progetto, in quanto si e usufruito anche

della Support Library [40] (versione 4) di Android. Come si puo notare tale

libreria e offerta direttamente da Google, non e indispensabile, almeno che

non vengano utilizzati determinati oggetti, tra i quali i piu importanti sono

i Fragment, ViewPager, NotificationCompat e tanti altri. I moduli deside-

rati sono stati richiamati tramite delle semplici import, dopo che la libreria

e stata inclusa nel progetto. Non vi e quindi la necessita di citare del codi-

ce a riguardo. Rimane solo da puntualizzare il fatto che per utilizzare tale


libreria, si necessita di specificare nel manifest dell’applicazione la versione

minima dell’SDK, che deve essere almeno la sette e come versione di riferi-

mento almeno la diciassette. Nel caso del progetto la prima risulta essere la

versione otto mentre la seconda e la diciotto (la piu aggiornata per quanto

riguarda Android JellyBean).

Per completezza di informazioni riguardo alle Support Library, vi e anche

la versione 7, che richiede versioni di SDK diverse ed e utilizzabile qualora vi

sia la necessita di utilizzare altre funzionalita come per esempio i grid layout.

3.3 XML

In questa sezione viene descritto velocemente cos’e XML e il perche si

e scelto di usarlo nel progetto di tesi. Tale descrizione non e orientata ad

essere un manuale del linguaggio, serve solo al lettore per capire il perche e

in che ambito e stato utilizzato. XML (eXtensible Markup Language)[21] e

un linguaggio di markup, estensione di SGML (Standard Generalized Markup

Language) [22] ideato per scambiare, immagazzinare e dare una struttura ai

dati ancor prima che visualizzarli per il quale e poco consigliato.

Per quest’ultimo scopo vengono utilizzati altri linguaggi di markup come

per esempio HTML (HyperText Markup Language). I tag di XML non sono

predefiniti (ne deriva l’aggettivo ”extensible”), l’utente puo definirli in base

alle proprie esigenze e sono autodescrittivi. Il programmatore, puo quindi

creare elementi personalizzati, con opportuni campi. In particolare per il

progetto di tesi, vengono salvati i risultati delle scansioni wireless e dei dati

mobili, quindi sono stati modellati gli elementi per rappresentare una rete

Wi-Fi con tutti i suoi attributi e analogamente una connessione dati e relative

caratteristiche.

XML e una Recommendation del W3C (World Wide Web Consortium)

e nacque quando tale consorzio scelse di creare un linguaggio di markup che

fosse uno standard, avesse caratteristiche diverse da HMTL e che offrisse

grande liberta di definizione dei tag. Ci si accorse ben presto che XML non

3.4 SQLite 65

era limitato al solo contesto web ma era qualcosa di piu: uno strumento che

permetteva di essere utilizzato nei piu diversi contesti, dalla definizione della

struttura di documenti, allo scambio delle informazioni tra sistemi diversi,

dalla rappresentazione di immagini alla definizione di formati di dati.

Per dare strutture ben precise ai file XML, si possono utilizzare i cosiddet-

ti linguaggi schema quali DTD ( Document Type Definition) e XML Schema.

Il primo, permette di specificare le caratteristiche strutturali di un documento

XML attraverso una serie di ”regole grammaticali”. In particolare definisce

l’insieme degli elementi del documento XML, le relazioni gerarchiche tra di

loro, l’ordine di apparizione nel documento XML e quali elementi e quali

attributi sono opzionali o meno. Il secondo, come DTD, serve a definire la

struttura di un documento XML. Oggi il W3C consiglia di adottarlo al po-

sto del DTD stesso, essendo una tecnica piu recente ed avanzata e che offre

maggiori funzionalita.

Le caratteristiche appena descritte sono state determinanti per l’utilizzo

di XML nel progetto, in particolar modo per gestire i risultati delle scansioni.

Infatti, anche se viene popolata l’opportuna basi di dati, si vuole offrire

all’utente tutta una serie di file XML suddivisi in ordine cronologico e per

tipologia di interfaccia in modo che possa consultarli all’evenienza.

Inoltre e bene evidenziare che XML viene usato anche per sviluppare

applicazioni Android, in quanto per definire il manifest di un’applicazione e

le strutture delle activity, nonche i valori delle risorse usate vi e la necessita

di implementare file XML.

3.4 SQLite

SQLite [19] e una libreria software scritta in linguaggio C che implementa

un DBMS2 SQL: offre servizi self-contained, serverless e transazionali verso

2DBMS (Database Management System): e un sistema di gestione di basi di dati

e consiste in un software per consentire la creazione, le interrogazioni e la gestione di

database.


database SQL. Tra le caratteristiche principali di SQLite, spicca la semplicita

di utilizzo che permette di creare una base di dati in un unico file. SQLite non

e un processo standalone utilizzabile di per se, ma puo essere incorporato al-

l’interno di un altro programma. Quest’ultima caratteristica e fondamentale

per quanto riguarda Android, infatti l’utilizzo di database nelle applicazioni

per tale sistema operativo puo avvenire solamente con l’utilizzo di SQLite.

Gli sviluppatori di Android, hanno motivato tale scelta proprio riferendo-

si alla facilita di utilizzo e alla leggerezza di SQLite. Utilizzando le API,

in versione 19 per JellyBean e versione 20 per KitKat si ha quindi avuto a

disposizione la versione 3.7.11 di SQLite. Piu in dettaglio, le caratteristi-

che principali di SQLite prevedono l’estrema compattezza (circa 500KB per

l’intera libreria), una buona velocita (superiore e MySQL e PostgreSQL) e i

vantaggi derivanti dall’open source con codice disponibile e ben commenta-

to. Inoltre l’API e semplice da utilizzare e permette di interpretare stringhe

SQL, e multipiattaforma (caratteristica importante per la portabilita tra di-

versi sistemi operativi). Come altri DMBS, anche SQLite offre una utility a

riga di comando per operare sui database, inoltre non ha dipendenze esterne

da altri software. SQLite presenta anche alcune limitazioni, per esempio non

ha una vera gestione della concorrenza, non dispone di alcune primitive di

interrogazioni (per esempio right join e full outer join) o ancora non sup-

porta primitive solitamente molto utilizzate in altri DMBS, come for each

row.

Infine, una problematica molto importante che ha portato ad alcune mo-

difiche implementative del progetto riguarda i tipi di dato a disposizione.

In particolare per quanto riguarda la gestione dei numeri reali (utilizzati per

le coordinate GPS), esso permette una scarsa precisione (quattro cifre deci-

mali al massimo). Si e quindi dovuto utilizzare le stringhe per ovviare a tale

problema (a tal proposito si rimanda la lettura alla sezione 5.2.2).

In conclusione, questa sezione non vuole essere un manuale di utilizzo di

tale DBMS, sono state elencate le sue caratteristiche principali e il perche

viene utilizzato in Android. Per il resto si rimanda il lettore all’ampia ed

3.5 RootToolKit 67

esauriente documentazione [20].

3.5 RootToolKit

Il RootToolKit [24] e un ’applicazione che permette di acquisire i permessi

di root sui dispositivi Nexus di Google. In precedenza e stato accennato che

uno dei dispositivi utilizzati per testare il progetto e un Nexus 5.

Il progetto richiede i permessi di root, per effettuare diverse operazioni, quali

l’attivazione e la disattivazione del GPS bypassando le impostazioni di si-

curezza imposte da Google, la modifica dei file di configurazione delle reti e

della scansione delle stesse. Si ha quindi avuto la necessita di rootare tale

dispositivo (la procedura e descritta nella sottosezione 5.3.4) e per farlo si e

ricorsi al suddetto applicativo. La versione per OSX, e a linea di comando

a differenza della versione per Windows che si presenta con un’interfaccia

grafica piu ortodossa. Analogamente per l’altro dispositivo utilizzato, ovvero

un Sony Xperia L, e stata utilizzata l’applicazione VRoot [25], che permette

di rootare diversi dispositivi mettendo a disposizione un’interfaccia grafica

(sfortunatamente solo dall’ultima versione 1.7.9.2 in inglese, mentre la ver-

sione 1.7.2 utilizzata al momento dello sviluppo del progetto era in cinese).

Tale applicazione e disponibile per Windows, in Figura 3.5 sono mostrate le

schermate di avvio di entrambe.

C’e da sottolineare, che per tutti e due i dispositivi, vale la precisazione

che se si effettua l’aggiornamento del sistema operativo, la custom recovery

installata nella fase di root viene persa, mentre il programma SuperSu3.5.1

necessario a gestire i permessi di root rimane installato ma non ne viene ga-

rantito il corretto funzionamento. Di conseguenza, ogni qualvolta si effettua

un aggiornamento del sistema operativo, si deve ripetere il la procedura di

rooting. Cio e avvenuto dal passaggio di KitKat 4.4 factory del Nexus 5 alle

versioni successive testate.


Figura 3.5: Schermate di avvio del Nexus root toolkit e di VRoot (ultima

versione in inglese in alto e versione utilizzata in cinese in basso).

3.5.1 L’applicazione SuperSu

SuperSu [26], mostrato in Figura 6.6 del Capitolo 6, e un’applicazione per

Android, disponibile anche sul Playstore, che per essere installata richiede tra

i requisiti un dispositivo coi permessi di root. Di per se questa applicazione

serve per gestire i permessi di root, ovvero quando una generica applicazione

richiede durante la sua esecuzione tali permessi, SuperSu mostra una dia-

log di notifica all’utente con la possibilita di settare per quanto si desidera

concedere tali permessi all’applicazione in questione. Quindi SuperSu non e

indispensabile, ma permette di gestire la concessione dei permessi in modo

chiaro, in quanto offre un’interfaccia grafica intuitiva e notifica l’utente del-

la richiesta di concessione di tali permessi a terze applicazioni solo quando

necessario. Oltre a cio, vi sono altre caratteristiche importanti, quali la pos-

sibilita di consultare un file di log in cui viene riportato quando e perche le

3.6 Wi-Fi 69

applicazioni hanno richiesto i permessi di root e la possibilita di effettuare

temporaneamente l’unroot del dispositivo.

Dato che l’obbiettivo, e quello di costruire un’applicazione o servizio che

sia utilizzabile da tutti gli utenti, si e pensato di appoggiarsi a tale applica-

tivo per due motivi: il primo e che cosı facendo l’utente e avvisato che si sta

eseguendo una porzione di codice che necessita dei permessi di root e di con-

seguenza (anche se viene notificato durante l’installazione dell’applicazione

stessa) viene messo a conoscenza che si sta accedendo a proprieta di sistema

o di sicurezza sensibili. Il secondo, riguarda l’utilita derivante dall’utilizzo

dell’applicazione in senso stretto, in quanto come detto in precedenza mette

a disposizione diverse utilita per gestire i permessi.

La versione utilizzata inizialmente nel progetto e la 1.65, non recente

ma stabile e viene fornita con RootToolkit. Comunque, una volta installata

l’applicazione e comunque possibile effettuare l’aggiornamento alle versioni

successive. Un’altra caratteristica importante, e che si disinstalla l’applica-

zione con l’apposito strumento di sistema di Android, possono essere persi i

permessi di root ed quindi necessario ripetere le procedure descritte in 5.3.4.

3.6 Wi-Fi

In questa sezione verra descritta brevemente la tecnologia Wi-Fi, non

avendo come scopo quello di fornire una descrizione completa in tutti gli

aspetti, ma ponendo invece attenzione sulle caratteristiche considerate per

lo sviluppo del progetto di tesi.

Wi-Fi e una tecnologia che permette a un dispositivo fornito dell’interfac-

cia appropriata (che in binomio col dispositivo stesso forma una stazione),

di scambiare dati o connettersi ad Internet mediante l’uso di onde radio.

Oggigiorno, tale tecnologia e ampiamente diffusa e utilizzata, e diventata

parte integrante della vita quotidiana (basti pensare all’utilizzo degli smart-

phone e al diffondersi di reti aperte da parte delle amministrazioni comunali

nelle citta). La connessione ad una rete da parte di un dispositivo avviene me-


diante l’interazione con un access - point, che ha determinate caratteristiche,

analizzate in seguito e che sono state utilizzate nel progetto.

Uno dei difetti maggiormente conosciuti che affligge Wi-Fi riguarda la

sicurezza, infatti esso puo essere meno sicuro di una connessione cablata (per

esempio Ethernet) in quanto e possibile introdursi nella connessione senza

necessitare di un mezzo fisico.

Le stazioni (dispositivo e sua interfaccia) condividono una frequenza radio

usata come canale di comunicazione. Le trasmissioni su questo canale sono

ricevute da tutte le stazioni in portata. L’hardware non segnala quando una

trasmissione e andata a buon fine e tale tecnologia viene dette best-effort (fa

del suo meglio ma non garantisce che tutto vada bene).

Ogni stazione e costantemente in ascolto sul canale di comunicazione per

ricevere le trasmissioni disponibili.

Un dispositivo che fa uso del Wi-Fi, puo connettersi ad Internet quando

si trova in portata di una rete wireless che e configurata in modo tale da

rendere disponibile questo servizio (per esempio con router/modem).

A volte e possibile connettere dispositivi senza l’utilizzo di un access-point,

tale scenario viene detto ad-hoc.

Come tutte le tecnologie via etere, anche Wi-Fi e soggetta alle problema-

tiche derivanti da ostacoli e interferenze, riducendo cosı la distanza massima

di copertura che altrimenti sarebbe di cento metri. Infatti le connessioni Wi-

Fi, possono subire disturbi o variazione alla velocita della rete, cio accade

in presenza di altri dispositivi wireless nella stessa area. Molti access point

usano un canale di default al momento del primo utilizzo, contribuendo alla

congestione in certi canali. Inoltre possono sorgere problemi dovuti all’alta

densita di access-point wireless nella stessa zona (wifi pollution), che posso-

no portare anche a problemi di interferenza (trasmissioni su stesse frequenze

o su frequenza che si contrappongono parzialmente). Oltre a cio, vi sono

altri dispositivi che fanno uso della banda di frequenza utilizzata da wifi:

forni a microonde, dispositivi ZigBee, dispositivi Bluetooth, baby monitor e

quant’altro.

3.6 Wi-Fi 71

Se quanto descritto fin’ora possa far sembrare Wi-Fi una tecnologia af-

fetta solo da difetti, la realta evidenzia come invece abbia anche numerosi

pregi. Infatti, questa tecnologia permette una installazione economica di reti

locali ed in luoghi dove non e possibile avere una connessione cablata (per

esempio monumenti storici). Inoltre la sua diffusione in una varieta di di-

spositivi sempre piu ampia e la diminuzione dei costi relativi ai chipset ne

ha dato la definitiva consacrazione. Inoltre, si stanno affinando tecniche per

la salvaguardia del consumo energetico, soprattutto per quanto riguarda i

dispositivi mobili (per esempio il meccanismo WMM Power Save).

Il numero di canali utilizzati nella comunicazione wireless non e uguale per

tutti i paesi: l’Australia e l’Europa permettono due ulteriori canali rispetto

a quelli ammessi negli Stati Uniti (1-13 vs. 1-11), mentre il Giappone ne ha

un altro in piu (1-14). Un segnale Wi-Fi occupa cinque canali nella banda

di 2.4 Ghz. I canali che differiscono di un valore almeno pari a cinque (per

esempio 2 e 7) non si sovrappongono. In Europa e in Giappone l’uso dei

canali 1, 5, 9 e 13 e raccomandato.

E possibile proteggere l’accesso di una rete wifi attraverso specifici proto-

colli [41]. Questa caratteristica e importante ai fini del progetto, in quanto la

lista di reti candidate da costruire in base ai movimenti del dispositivo, viene

costruita incrociando quanto rilevato dall’interfaccia e quanto presente nelle

impostazioni di sistema presenti sul dispositivo stesso. Nella costruzione di

tale lista, si considera il tipo di protocollo di cifratura, in modo da togliere

subito tra le possibili candidate quelle reti che hanno un ssid corretto, ma

con una cifratura che non combacia con quanto salvato nelle impostazioni.

Le cifrature piu diffuse sono WEP (Wired Equivalent Privacy) e WPA (Wi-

Fi Protected Access). Per quanto riguarda la prima, e la piu datata (1999)

e anche la meno sicura, motivo per il quale e stata fatta una rivisitazione di

tale standard nel 2003. WEP usa l’algoritmo di cifratura stream RC4 3 per

3RC4: algoritmo di cifratura che genera una sequenza di bit casuali. Tale flusso, viene

combinato con i bit dell’informazione, attraverso uno XOR, ottenendo cosı il risultato

cifrato. L’operazione di decifratura avviene nella stessa maniera, passando in input il

testo cifrato ed ottenendo in output il testo in chiaro (per simmetria dello XOR).


la sicurezza e utilizza il CRC-32 4 per verificare l’integrita dei dati. L’RC4

del WEP utilizza due chiavi rispettivamente a 40 bit e a 104 bit ed ha come

vantaggio quello di essere un algoritmo veloce (caratteristica da non ignorare

per le reti via etere). Inizialmente WEP presentava alcune falle tra cui la

piu importante, riguarda la mancanza della gestione delle chiavi utilizzate

per la codifica dei messaggi. Tale mancanza, insieme alla constatazione che

le chiavi utilizzabili per cifrare i messaggi erano poche, esponeva il WEP a

molte tipologie di attacchi. Al giorno d’oggi le reti che utilizzano WEP non

sono considerate molto sicure, infatti molte analisi dimostrano che e possi-

bile, analizzando il traffico di rete, ottenere in breve tempo (poche ore) la

chiave utilizzata per cifrare la rete.

Per quanto riguarda WPA, e nato nell’Ottobre del 2002 per fornire una

soluzione intermedia, atta a sostituire il protocollo WEP mentre lo standard

802.11i veniva ultimato. Nella fattispecie, il protocollo TKIP (Temporal Key

Integrity Protocol), fu incluso nel WPA. Il protocollo TKIP cambia dinami-

camente la chiave in uso (problema che si era invece riscontrato in WEP).

I dati sono cifrati con l’algoritmo di cifratura a flusso RC4 con chiave a 128

bit. In aggiunta all’autenticazione e alla cifratura, il WPA introduce note-

voli miglioramenti nella gestione dell’integrita dei dati. Il CRC utilizzato

dal WEP non era sicuro, era possibile modificare il messaggio mantenendo

coerente il CRC, anche senza conoscere la chiave. Per evitare tale proble-

ma, il WPA utilizza un nuovo metodo per verificare l’integrita dei messaggi

chiamato ”Michael”. Questo, include un contatore associato al messaggio,

per impedire all’attaccante di ritrasmettere un messaggio che sia gia stato

trasmesso nella rete. In sostanza rispetto a WEP, WPA aumenta la di-

mensione della chiave, il numero delle chiavi in uso, include un sistema per

verificare l’autenticita dei messaggi migliore e quindi incrementa la sicurezza

della WLAN. Lo standard 802.11i, accennato poco fa, e piu conosciuto co-

4Nel CRC (cyclic redundancy check), i dati d’uscita sono ottenuti elaborando i dati di

ingresso i quali vengono fatti scorrere ciclicamente in una rete logica. I bit della stringa

di controllo vengono trasmessi insieme ai dati.

3.6 Wi-Fi 73

me WPA2, (ratificato nel 2004) e presenta alcune aggiornamenti rispetto a

WPA quali l’algoritmo crittografico AES (Advanced Encryption Standard).

La Tabella 3.1) evidenzia le differenze tra WEP e WPA.

WEP WPA

EncryptionFlawed, cracked by scientist

and hackersFixes alla WEP flaws

40-bit keys 128-bit keys

Static: same key used by

everyone on the network

Dynamic session keys. Per users,

per session, per packet keys

Manual distribution of keys,

hand typed into each deviceAutomatic distribution of keys

AuthenticationFlawed, used WEP key itself

for authentication

Strong user authentication,

utilizing 802.1X and EAP

Tabella 3.1: Differenze tra WEP e WPA.

Fino ad ora, si e parlato di WEP, WPA, WPA2. L’applicazione riesce a

gestire correttamente anche reti come AlmaWifi (rete wireless dell’Universita

di Bologna), ovvero reti che hanno diversi access-point (MAC address diversi)

costituenti la medesima rete. Nella fattispecie di AlmaWifi, si utilizza una

protezione 802.1x PEAP (Protected Extensible Authentication Protocol), un

protocollo che incapsula EAP5 con un tunnel criptato usando TLS (Transport

Layer Security) per proteggere l’autenticazione degli utenti. In particolare

l’applicazione supporta la configurazione di tale rete con MS-CHAPv2, un

protocollo in cui il processo di autenticazione e ”reciproco” dove:

1. Il client contatta il server e stabilisce una sessione.

2. Il server di autenticazione invia al client un messaggio composto da un

identificatore della sessione (IdS) e una stringa pseudocasuale (A).

5EAP (Extensible Authentication Protocol) e un framework di autenticazione e non un

meccanismo specifico vero e proprio, fornisce quindi funionalita comuni chiamati metodi

EAP che sono circa una quarantina. Tra i piu conosciuti vi sono EAP-MD5, EAP-TLS e

LEAP.


3. Il client riceve il messaggio dal server e invia una risposta composta da

uno username, una stringa fittizia (B), la stringa pseudocasuale (A),

l’identificativo di sessione (IdS) e la password utente tutto cifrato.

4. Il server riceve il messaggio dal client, lo verifica e invia la relativa

risposta composta dall’esito del tentativo di connessione, la stringa

fittizia(B) e la password utente tutto cifrato.

5. Il client riceve la risposta e se e avvenuta l’autenticazione, utilizza la

sessione, altrimenti interrompe la connessione.

E stata fatta una breve panoramica delle tecniche di cifratura per Wi-Fi,

sottolineando quali di esse l’applicazione supporta pienamente.

Continuando la descrizione della tecnologia wireless, in precedenza si e par-

lato di Access-Point (AP), dispositivi che solitamente permettono ad altri

device di connettersi a una rete cablata usando il Wi-Fi.

L’AP solitamente si connette ad un router (attraverso una rete cablata), ma

puo anche essere un componente integrale di quest’ultimo. Un AP puo agire

come ”arbitro della rete”, decidendo quando un dispositivo a lui connesso e

abilitato a trasmettere. Tuttavia la maggior parte delle reti wireless IEEE

802.11 correnti non implementano questa funzionalita.

In conclusione, nel progetto quando un dispositivo effettua una scansione

Wi-Fi, vengono salvate le informazioni dell’AP a cui si e connessi e di quelli

che comunque vengono rilevati in zona. Questo serve per creare i file XML e

per popolare il database dell’Oracolo nella modalita di training.

I dettagli sono descritti nel Capitolo 4, comunque si puo accennare che vengo-

no rilevate tutte le informazioni rese disponibili attraverso le API di Android

[44]. Oltre a cio, vengono poi considerate le informazioni presenti nelle confi-

gurazioni di rete del sistema ed aggiunte eventualmente le informazioni chiave

della cella dati mobile a cui si e collegati in quel momento (se l’apposita in-

terfaccia e attivata), in modo da avere una relazione tra reti wireless e celle

disponibili.

3.6 Wi-Fi 75

In particolare vengono aggiunte le informazioni relative alla cifratura (non

ottenibili dalle API) e le credenziali utilizzati per l’autenticazione. Oltre a

tutto questo, vengono associate anche le coordinate GPS se disponibili.

3.6.1 Scansioni Wi-Fi in Android

Un aspetto interessante riguarda le scansioni effettuate da un dispositivo

Android: nel caso del progetto, l’utente inserisce i valori degli intervalli di

scansione per quanto riguarda l’interfaccia wireless e quella dei dati mobili.

Tale intervallo, se viene utilizzato nel codice per dire al sistema di effettuare

le scansioni periodicamente utilizzando i metodi messi a disposizione dalle

API non viene comunque considerato da Android, infatti tale istruzioni ven-

gono messe in coda dal kernel che effettuara la scansione col valore specificato

nel file /system/build.prop [43]. In particolare, in questo file vi e una voce,

chiamata wifi.supplicant scan interval che specifica il valore dell’intervallo di

scansione in secondi. Nel Nexus 5 tale valore e di quindici secondi, mentre

per il Sony XPeria L e di 25 secondi. Quindi per far sı che il kernel, effettui

effettivamente le scansioni ad intervalli distanti quanto specificato dall’utente

si e dovuto implementare il codice in modo tale che all’avvio dell’applicazione

venga settato tale valore opportunamente nel file build.prop (discussioni sulla

progettazione e sull’implementazione nelle sottosezioni 4.1.1 e 5.3.4), neces-

sitando quindi dell’utilizzo della libreria. Successivamente viene riavviato il

processo responsabile della scansione dell’interfaccia wireless (/system/bin/-

wpa supplicant) sempre attraverso la suddetta libreria. Come si puo notare

anche in questo caso sono necessari i permessi di root sul dispositivo. Un’altra

soluzione poteva essere l’utilizzo dell’ndk, ma e stata tralasciata in quanto

l’utilizzo della libreria RootTools ha evitato di dover creare file C ed altri

necessari per collegare il codice nativo col codice Java. Se tale riga nel file

build.prop non e presente (difficilmente accade), la si puo tranquillamente

aggiungere.


3.7 Connessione dati del provider telefonico

In parte, le tecnologie di connessioni dati mobili sono state trattate in

precedenza nella Sezione 2.3.

Per quanto riguarda il progetto le informazioni ottenibili [46] tramite le

API di Android sono: il tipo di connessione dati, la potenza del segnale, l’i-

dentificativo della cella (CID), l’MCC (Mobile Country Code), l’MNC (Mobi-

le Network Code), ed infine il LAC (Location Area Code). Come per le tuple

inserite nella tabella delle connessioni wireless, anche in questo caso vengo-

no sempre associate le coordinate GPS. Inoltre, l’informazione che identifica

univocamente una cella telefonica (ovvero il CID), viene inserita nelle tuple

rappresentanti le connessioni Wi-Fi rilevate quando anche l’interfaccia dei

dati mobili e attivata. Questo viene fatto, per avere se possibile, una corre-

lazione tra reti wireless e connessioni dati mobili e risulta essere utile anche

per quanto riguarda la localizzazione per il processo di handover, qualora il

GPS non sia attivato o le coordinate non siano ancora state acquisite.

Le connessioni dati mobili vengono gestite dall’Oracolo con una priorita

piu bassa rispetto a quelle wireless, in quanto offrono solitamente velocita

inferiori e traffico limitato rispetto a queste ultime a fronte di costi maggiori

(tralasciando casi particolari di abbonamenti e la tecnologia emergente 4G

ancora poco diffusa) . D’altronde, le connessioni dati mobili offrono rispetto

alla tecnologia wireless, una zona di copertura maggiore (come discusso nella

sezione 2.3), ma appunto, un dispositivo per raggiungere tale cella attraverso

la propria interfaccia e costretto a dover far fronte ad un utilizzo di energia

superiore, che si traduce in una durata minore della batteria.

Le tipologie di connessioni dati piu utilizzate durante l’implementazione

del progetto sono (in ordine di evoluzione): GSM, GPRS, UMTS, HSPA,

e LTE (quest’ultima in realta poco diffusa in Italia). Di seguito una breve

descrizione per ciascuna di esse.

3.7 Connessione dati del provider telefonico 77

3.7.1 GSM

Il GSM (Global System for Mobile Communications) [47] e lo standard

2G, ovvero di seconda generazione, di telefonia mobile cellulare. E bene pre-

cisare, che durante lo sviluppo del progetto, quasi mai e stata agganciata

una cella in GSM: in ordine di evoluzione, le celle con tecnologia piu obsoleta

maggiormente agganciate sono quelle GPRS. In particolare, GSM e uno stan-

dard open (aperto al pubblico anche se i diritti sono comunque associati alle

aziende che lo hanno progettato), sviluppato dal CEPT (European Conferen-

ce of Postal and Telecomunications Administrations), finalizzato dall’ETSI

(European Telecommunications Standards Institute) e mantenuto dal consor-

zio 3GPP (3rd Generation Partnership Project)6 di cui l’ETSI fa parte.

Il progetto GSM nacque nel 1987 e la sua sigla prende il nome dal gruppo

francese che ne inizio lo sviluppo ovvero il Groupe Special Mobile.

Nel 1989 l’ETSI assunse il controllo del progetto rendendo la tecnologia pub-

blica. Nel 1998 quando fu creato il consorzio 3GPP, vennero delegati ad esso

lo sviluppo ed in seguito la manutenzione di tale tecnologia.

In Italia l’avvento del GSM avvenne nel 1992.

Le caratteristiche del GSM rappresentarono per quei tempi una vera ri-

voluzione, per prima cosa, la comunicazione di tipo digitale (da qui il nome

di tecnologia di seconda generazione) che permetteva interoperabilita tra reti

diverse che fanno capo ad un unico standard internazionale.

L’introduzione della trasmissione digitale porto a numerosi vantaggi quali

la maggiore velocita di trasmissione, nuovi servizi (per esempio gli SMS) e

funzioni di sicurezza in termini di cifratura della comunicazione.

L’avvento del digitale permise quindi lo scambio di dati veri e propri.

GSM utilizza un accesso radio TDMA7. A partire dal 2006, la rete GSM per-

mette di utilizzare il protocollo DTM Dual Transfer Mode: un altro aspet-

63GPP: e un accordo di collaborazione, formalizzato nel dicembre 1998, fra enti che si

occupano di standardizzare sistemi di telecomunicazione in diverse parti del mondo.7TDMA (Time Division Multiple Access): e una tecnica di multiplazione, in cui la

condivisione del canale e realizzata mediante ripartizione del tempo di accesso allo stesso

da parte degli utenti.


to innovativo, che la rende similare all’UMTS per quanto riguarda il poter

chiamare e ricevere pacchetti contemporaneamente. Ne deriva, che con tale

modifica e possibile effettuare videochiamate senza appoggiarsi ad una rete

di terza generazione. La rete GMS e composta da tre principali componenti:

• Dispositivi mobili.

• Rete di accesso: e di fatto il cuore dell’infrastruttura della rete cellulare.

E formata da due componenti, la BTS (Base Transceiver Station) che

e l’interfaccia radio con i dispositivi mobili e il BSC (Base Station

Controller) che rappresenta il ”cervello” della rete GSM.

Quest’ultimo governa tutti gli aspetti del protocollo GSM e gestisce la

comunicazione tra interfaccia radio e rete fissa.

• Core Network : e l’interfaccia della rete fissa verso la rete cellulare.

Per quanto riguarda le frequenze, tipicamente in Europa le bande usate

dalla rete GSM sono attorno a 900 e 1800 MHz, mentre negli Stati Uniti si

usano le bande attorno a 850 e 1900 MHz. La molteplicita delle portanti

usabili e l’evoluzione dei sistemi di trasmissione, hanno fatto in modo che le

celle possano presentare configurazioni multifrequenza (dual band).

Essenzialmente esistono quattro tipi di cella GSM: macro, micro, pico e celle

a ombrello in ordine di copertura decrescente. Solitamente queste tipologie

di celle vengono tra esse combinate per propagare il segnale, che nella realta

si traduce in una distanza che puo arrivare fino a trentacinque chilometri

(sebbene lo standard dichiari il doppio). Infine, il concetto di scheda SIM

(Subscriber Identity Module) e correlato con l’avvento del GSM, in quanto

fornisce autenticazione ed autorizzazione all’utilizzo della rete.

3.7.2 GPRS

Il GPRS (General Packet Radio Service) [52], e una tecnologia di tele-

fonia mobile cellulare inizialmente standardizzata dalla ETSI ed in seguito

mantenuta dalla 3GPP. Viene convenzionalmente definita di generazione 2.5,


vale a dire una via di mezzo fra la seconda (GSM) e la terza (UMTS).

E una tecnologia progettata specificatamente per realizzare un trasferimento

dati a commutazione di pacchetto ed agganciarsi ad Internet usando i ca-

nali TDMA della rete GSM. Si tratta quindi di un’evoluzione di GSM, per

mezzo di alcune modifiche hardware e software al sistema, tanto che si parla

di GSM/GPRS conservando la classica commutazione di circuito propria del

GSM per il traffico vocale e tutti gli altri servizi. Rispetto a quest’ultimo

GPRS offre le seguenti innovazioni:

• Messaggistica MMS (Multimedia Messagging Service).

• Servizi in modalita anonima: accesso anonimo a determinati servizi.

• Servizio PTP (Point to Point), creando interconnessione fra reti inter-

net (basate sul protocollo IP).

• Servizio PTM (Point to Multipoint), in grado di gestire chiamate di

gruppo e chiamate multicast.

La pacchettizzazione dei dati e realizzata dal GPRS occupando, per la

trasmissione, le frequenze di una cella radio (solitamente la frequenza 1800

MHz). Il limite massimo teorico per la velocita e di 171,2 Kbit/s, ma nella

realta ci si aggira intorno ai 30/70 Kbit/s. Un’evoluzione del modo in cui

il GPRS utilizza le frequenze, denominato tecnologia EDGE, consente di

raggiungere velocita piu elevate, fra 20 e 200 Kbit/s. La velocita e comunque

influenzata sia dalla tipologia del dispositivo mobile, sia dal numero di utenti

allacciati alla stessa cella, in quanto la banda viene frazionata.

Un altro fattore influente e la distanza del dispositivo dalla stazione base.

Per ottenere le massime velocita di trasmissione e necessario utilizzare piu

di un time slot contemporaneamente all’interno del cosiddetto time frame

TDMA, tenendo pero presente che a maggiori velocita corrispondono minori

possibilita di correggere automaticamente gli errori di trasmissione.

Vi sono diverse classi di GPRS, solitamente le piu conosciute sono la

classe 8 (riconosciuta con la sigla 4R1T) e la classe 10 (con la sigla 3R2T).


La prima, come indica la sigla che la rappresenta, usa quattro time slot per

ricevere ed uno per trasmettere i dati. Questa configurazione e particolar-

mente adatta alle applicazioni in cui i dati sono prevalentemente ricevuti ed

e quella di default per i dispositivi mobili. Invece la classe 10, come sugge-

rito dalla sigla 3R2T, utilizza tre time slot per riceve e due per trasmettere,

suggerendone l’utilizzo in cui download e upload sono bilanciati (per esempio

nelle applicazioni di messaggistica istantanea). Un confronto prestazionale

tra queste due classi e mostrato in Tabella 3.2.

Sigla Download(Kbit/s) Upload(Kbit/s) Classe

4R1T 57,6 14,4 Classe 8

3R2T 43,2 28,8 Classe 10

Tabella 3.2: Confronto tra classe 8 e classe 10 di GPRS.

In conclusione, questa tecnologia ormai e molto datata e offre prestazioni

che al giorno d’oggi sono irrisorie: si parla di velocita comparabili a quelle

dei vecchi modem 56K, e cioe fra i 4 e i 5 kB/s nel periodo del suo maggior

sviluppo (primi anni 2000) [53].

3.7.3 UMTS

UMTS (Universal Mobile Telecommunications System) e uno standard di

telefonia di terza generazione (3G), evoluzione del GSM. Tale tecnologia ha

la caratteristica di impiegare lo standard base W-CDMA come interfaccia di

trasmissione nell’accesso radio al sistema, ed e compatibile con lo standard

3GPP. UMTS si appoggia alle infrastrutture del GSM, con cui supporta

ampia compatiilita a meno di ovvie modifiche alle infrastrutture delle reti

esistenti. Rispetto a quest’ultimo, come accennato precedentemente, ha come

differenza basilare l’utilizzo di W-CDMA. La prima rete UMTS al mondo,

chiamata semplicemente ”3” e diventata operativa nel Regno Unito nel 2003.


Rispetto a GSM si ha una maggiore velocita di trasmissione dovuta a

sua volta all’adozione di un accesso multiplo al canale di tipo W-CDMA piu

efficiente rispetto al TDMA del GSM.

UMTS inizialmente prevedeva una velocita di trasmissione intorno ai 2

Mb/s, le successive e dirette evoluzioni come UMTS 2 e UMTS 2+ fino a

3Mb/s. In seguito sono state sviluppate delle varianti come HSPA (descritta

successivamente nella sottosezione 3.7.5) per incrementare tali prestazioni.

Tali migliorie rispetto a GSM, hanno reso possibile tutta una serie di servizi,

in particolar modo quelli multimediali: infatti inizialmente furono di ampia

diffusione videochiamate, MMS, nonche la navigazione sul Web.

Ad ognuno di questi tre servizi venne assegnato uno specifico rate di trasfe-

rimento, in particolare, per la voce era di 12,2 kb/s, 64 kb/s per le video-

conferenze e 384 kb/s per trasmissioni di tipo dati. Inizialmente UMTS in

Italia lavorava sulle frequenze che vanno da 1920 a 1980 Mhz per l’upload e

da 2110 a 2170 Mhz per il download. Negli ultimi anni (si parla dal 2011 in

poi per una completa copertura ottenuta nel 2013) sono state rese disponibili

anche le frequenze intorno ai 900 Mhz. I canali utilizzati da UMTS sono di

5 Mhz di larghezza di banda sulle frequenze appena descritte.

All’inizio UMTS fatico a prendere piede per svariati motivi: il principale

riguarda la diffusione degli SMS appoggiati alla tecnologia GSM, le cui infra-

strutture potevano essere utilizzate per UMTS, ovviamente con le opportune

modifiche. Cio che frenava gli operatori erano i costi dell’acquisto dei per-

messi dell’utilizzo delle bande nei confronti dei governi. Basti pensare che in

Italia, inizialmente la compagnia pioniera di reti UMTS fu la 3, che essendo

appena nata non aveva installato in precedenza infrastrutture GSM e quin-

di ha potuto investire direttamente su UMTS senza dover effettuare alcun

aggiornamento. Inoltre almeno inizialmente, se con GSM qualunque dispo-

sitivo poteva funzionare, anche all’estero, con qualsiasi gestore, con UMTS

era necessario adottare una gamma ristretta di modelli per operare con un

singolo gestore telefonico o funzionare correttamente solo sul suolo nazio-

nale, presentando problemi all’estero. Alla fine gli operatori fecero questo


passo sia economico che di avanzamento tecnologico, incrementando cosı la

diffusione di UMTS. A conferma della buona interoperabilita tra UMTS e

GSM, soprattutto quando la presenza delle celle del primo non era molto

diffusa sui territori, si poteva notare come i dispositivi potessero inviare e

ricevere chiamate attraverso l’esistente rete GSM, infatti quando un utente

UMTS si spostava verso un’area non coperta dalla rete UMTS, il dispositivo

commutava automaticamente al GSM.

In conclusione, per quanto riguarda tale tecnologie e la sua diffusione:

UMTS inizialmente ha stentato a prendere piede per questioni economiche e

per la completa affermazione di GSM e delle sue infrastrutture, ma alla fine e

diventata la tecnologia piu utilizzata negli ultimi anni ed e stata la pioniera

delle tecnologie di terza generazione 3G. Inoltre, e stata la base per altre

tecnologie che offrono velocita di trasmissione superiori ad essa come per

esempio HSPA e LTE (considerate di generazione 3.5). La sua diffuzione e

stata talmente ampia che sono state prodotte chiavette USB per computer in

grado di aver connettivita UMTS a costi ridotti con adeguati abbonamenti.

Infine un po di informazioni a riguardo delle componenti [49] che permet-

tono di offrire il servizio UMTS in quanto e una delle ”tecnologie portanti”

utilizzate dal progetto di tesi. In particolare, tali componenti fondano la loro

esistenza sull’assunzione base che quando ci si muove tra tra sistemi, non

dovrebbe essere richiesta nessuna ristabilizzazione del servizio e si deve man-

tenere lo stesso QoS. Per offrire tale caratteristica, vi e quindi la presenza

di macrocelle mescolate a microcelle, aumentando cosı la zona di copertu-

ra. Questa e una scelta standard effettuata da tutti gli operatori, in quanto

garantisce un servizio piu affidabile. Una nozione base per UMTS e la di-

stinzione tra network operator che forniscono la connettivita base e i service

provider che offrono valori aggiunti ai servizi per l’utente. I service provider

possono introdurre i loro servizi attraverso avvisi o pubblicita utilizzando

i service aggregator, che permettono la registrazione e la scoperta di nuovi

servizi da parte dell’utente. Ogni servizio, ha un proprio profilo che include

informazioni quali il traffico minimo, le caratteristiche del QoS (larghezza di


banda, ritardo, jitter) richieste per un utilizzo efficiente, i requisiti minimi del

dispositivo mobile, i costi per accedere al servizio stesso, nonche le differenti

versioni di quest’ultimo. Il profilo del servizio insieme ad altre informazioni,

giocano un ruolo fondamentale per decidere quale tecnologia di accesso uti-

lizzare in fase di handover, qualora non vi sia disponibile il solo UMTS.

Ciascun operatore UMTS fa uso di entita chiamate CNC (Core Network Con-

troller) che salvano i profili degli utenti (stato di sottoscrizione, preferenze

ecc ecc), i profili dei dispositivi (potenza della CPU, memoria, supporto Java,

dimensioni dello schemro ecc ecc) ed ovviamente i profili dei servizi.

Il CNC puo essere aggiornato dai service aggregator citati in precedenza

qualora vengano effettuati dei cambiamenti ai servizi. Il CNC, a sua volta,

comunica con un ARNC (Advanced Radio Network Controllers) e gli notifica

le modifiche alla topologia della rete (per esempio l’aggiunta o la rimozione

di una cella). Tra l’altro questi gestiscono anche le comunicazione inter-

operator quando una nuova topologia o dei cambiamenti sono richiesti per

gestire il roaming tra diverse reti. Piu in dettaglio gli ARNCs sono entita

complesse che gestiscono le risorse radio, l’handover e il controllo degli ac-

cessi, inoltre comunicano con il CNC per prendere le informazioni relative

agli utenti che stanno usufruendo dei servizi. Tutte queste informazioni, sono

utilizzate durante l’impostazione della connessione nonche, durante l’esecu-

zione dell’handover. Solitamente l’ARNC e responsabile delle decisioni finali

di handover, avendo a disposizione dati quali lo stato della connessione cor-

rente del dispositivo mobile, le preferenze e il carico della rete.

Infine vi e l’MTC (Mobile Terminal Controller) che e responsabile dell’ese-

cuzione del servizio, nonche del monitoraggio del collegamento radio.

In letteratura per quanto riguarda UMTS e l’handover vi e anche una

classificazione relativa alle informazioni, che possono essere statiche o dina-

miche: le prime sono informazioni relative al dispositivo (capacita, software,

interfacce di rete), la topologia della rete, il profilo utente e i servizi (requisiti

per il QoS). Le seconde invece, possono includere la locazione attuale dell’u-

tente, il traffico corrente e i parametri attuali relativi al QoS della rete.


Vi puo essere una classificazione piu fine di quanto detto, per esempio le infor-

mazioni relative al dispositivo possono essere intese come dinamche in quanto

l’utilizzo della cpu o la memoria attualmente disponibile sono variabili.

Attualmente nello stato dell’arte, per quanto riguarda l’UMTS e la gestio-

ne dell’handover si segue una strategia simile a quella utilizzata nel progetto

di tesi, ovvero si cerca di trovare l’access point che e il miglior candidato

utilizzando le informazioni presenti nell’ARCN e scegliendo quini l’opzione

migliore conforme ai profili dell’utente, del dispositivo mobile e del servizio.

Si crea quindi una lista di candidati (proprio come nel progetto), ordinati per

”bonta” in base ai parametri discussi precedente. Avendo a disposizione tale

lista, si deve iniziare il processo di handover in anticipo, in quanto per alcuni

di essi potrebbero esserci difficolta a connettersi ed e infatti questo che viene

fatto nell’elaborato di tesi, ci si trova a dover prendere molte decisioni in un

lasso di tempo limitato. Nel progetto in discussione, infatti, le funzionalita

(raccolta delle informazioni, preferenze dell’utente, creazione della lista dei

candidati ecc ecc..) offerte dalle entita appena descritte, vengono implemen-

tate tutte nel dispositivo mobile, ma l’idea di base puo essere spostata alle

infrastrutture per avere una vera e propia integrazione tra tecnologie.

Vi sono pubblicazioni[49], che parlano di integrazione tra UMTS e WLAN.

L’idea proposta e quella di utilizzare le informazioni citate in precedenza e

la costruzione di una lista di reti candidate. Cio viene fatto basandosi su

due database, che contengono rispettivamente, i dati sui servizi e il profilo

del dispositivo mobile nel CNC, in modo che tali informazioni siano facil-

mente reperibili durante la decisione di handover. Questi database servono

per preparare le liste di priorita accennate in precedenza, focalizzandosi sulle

conoscenze del dispositivo mobile, sulle sue capacita nonche sul profilo uten-

te. A tal proposito nel progetto di tesi vengono considerate le caratteristiche

tecniche del dispositivo mobile, per quanto riguarda i servizi si assume che si

voglia mantenere la conitnuita di connessione, ipotizzando che l’utente stia

utilizzando applicazioni real time o VoIP. Inoltre per le preferenze, si cerca di

favorire l’utilizzo di reti wireless per questioni di costi e di consumi energetici


per salvaguardare la batteria.

W-CDMA

Con W-CDMA (Wideband Code Division Multiple Access) [50] si indica

una particolare tecnologia di accesso multiplo al canale radio per reti cellulari

di terza generazione. Tale protocollo e usato da UMTS e derivati, come

HSPA. W-CDMA e un’interfaccia a banda larga basata sulla tecnologia di

accesso multiplo a divisione di codice CDMA8 e viene utilizzata per l’appunto

per ottenere velocita di trasmissione migliori di quanto si possa ottenere con

TDMA e GPRS. Il progetto inizia ad essere sviluppato negli anni 90 dalla

NTT DoCoMo come interfaccia wireless, vennero poi inviate le specifiche alla

ITU (International Telecommunication Union), che lo fece diventare parte

integrante dello standard 3G e di conseguenza di UMTS.

Tra le caratteristiche principali di W-CDMA vi sono i canali radio di

ampiezza di 5 Mhz, il supporto di comunicazioni duplex sia basate sulla fre-

quenza (FDD -Frequency Division Duplexing) che sul tempo (TDD -Time

Division Duplexing) e soprattuto la predisposizione al poter variare le tipo-

logie di handover tra celle. Di conseguenza UMTS di per se sembra prestar-

si bene all’handover, rimane l’esperienza pratica che dimostra il contrario.

Infatti, l’affidarsi alla sola procedura di handover offerta da UMTS non e

sufficiente per avere una connessione priva di interruzioni.

3.7.4 LTE

Il termine LTE (Long Term Evolution), [51] indica la piu recente evoluzio-

ne degli standard di telefonia mobile cellulare GSM/UMTS. Fa parte di quel

segmento di tecnologie cosiddette ”pre-4G”, collocandosi in una posizione

intermedia fra le tecnologie 3G come l’UMTS e quelle di quarta generazione

8CDMA Code Division Multiple Access e un metodo di accesso al canale. Come sugge-

rito dal nome, l’accesso e multiplo, in quanto molti trasmittenti possono mandare informa-

zioni simultaneamente utilizzando un singolo canale di comunicazione. Questo permette

a molti utenti di condividere una banda di frequenze.


pura (4G), in fase di diffusione. Nonostante cio, con l’intento di porre fine

alla confusione tra l’utilizzo in marketing del termine 4G e la sua vera clas-

sificazione, l’ITU ha recentemente deciso di applicare il termine 4G anche

all’LTE.

La standardizzazione dell’LTE e stata completata dal 3GPP all’inizio del

2008. L’obiettivo dell’LTE era quello di promuovere l’uso della banda larga

in mobilita, sfruttando l’esperienza e gli investimenti effettuati per le reti

3G e anticipando i tempi rispetto alla disponibilita degli standard di quarta

generazione, il cui obiettivo e quello di raggiungere velocita di connessione

wireless anche superiori al Gb/s. Tale standard, avendo avuto una buona

diffusione nei centri urbani, ha ridotto l’espansione di altre tecnologie pro-

mettenti quali WiMax. Inoltre LTE e interamente basato sul protocollo IP,

supporta quindi IPv4 e IPv6.

LTE puo funzionare su diverse bande di frequenza. In particolar modo

nella unione europea vengono utilizzate le seguenti bande:

• banda di frequenza 800 MHz, in quanto si stanno liberando le frequenze

televisive che occupano l’intervallo che va da 794 MHz a 858 MHz, visto

il passaggio al digitale terrestre.

• banda di frequenza 900 MHz e 1900 Mhz in quanto si sta soppiantando

la tecnologia GSM (tecnologia 2G) che le utilizza.

• banda di frequenza 2600 MHz, gia libere in alcune zone ma utilizzate

in altre dai ministeri della difesa.

LTE e parte integrante dello standard UMTS, ma prevede numerose mo-

difiche e migliorie. Infatti tralasciando caratteristiche come l’efficienza spet-

trale, le migliorie piu importanti riguardano le velocita di download che pos-

sono arrivare fino a 326,4 Mb/s e quella di upload che arrivano fino a 86,4

Mb/s. Inoltre ha un RTT (Routing Trip Time)9 di 10 millisecondi rispetto,

9Il Round Trip Time e una misura del tempo impiegato da un pacchetto di dimensione

trascurabile per viaggiare da un computer della rete ad un altro e tornare indietro.


per esempio, ai 70 millisecondi di HSPA e ai 200 millisecondi di UMTS.

Inoltre come detto in precedenza, e molto duttile infatti lo si applica a fre-

quenze quali quelle del GSM, fino a nuove bande intorno ai 2,6 GHz, non

escludendone l’aggiunta di nuove in futuro. Infine, ha un ottimo supporto

alla mobilita, sono stati effettuate test in cui il servizio viene garantito a

velocita di spostamento di 350 km/h e di 500 km/h (in quest’ultimo caso

dipende dalla banda di frequenza utilizzata).

Per concludere, una differenza interessante rispetto ad HSPA che utilizza

la stessa copertura radio della rete UMTS: nel caso dell’LTE e necessario

predisporre una copertura radio dedicata, realizzando di fatto una nuova

rete aggiuntiva a quella dell’UMTS, o di qualsiasi altro sistema di accesso

cellulare, come il GSM.

3.7.5 HSPA e HSPDA

L’HSPA (High Speed Packet Access) e una famiglia di protocolli per la

telefonia mobile che estendono e migliorano le prestazioni dell’UMTS. Inclu-

de l’HSDPA [54] che incrementa le prestazioni per la trasmissione dati in

downlink (verso l’utente). Entrambe sono sviluppate dal 3GPP.

L’HSDPA (High Speed Downlink Packet Access) e una variante dell’HSPA

e ne migliora le prestazioni in download, ampliandone la larghezza di banda,

e aumentando cosı la capacita di trasmissione, infatti puo raggiungere la

velocita massima teorica di 42,2 Mb/s anche se nella realta le prestazioni

sono racchiuse nell’intervallo che va da 14 Mb/s a 42 Mb/s.

Quindi l’HSDPA (cosı come HSPA) ha le caratteristiche dell’UMTS (che si

ferma pero a 2 Mb/s teorici) ma con prestazioni migliorate, paragonabili

a quelle di una ADSL. Risulta quindi far parte della famiglia 3.5G, ovvero

migliore rispetto alle tecnologie della terza generazione ma non ai livelli del

4G. Nel panorama italiano, dal 2007 tutte le compagnie di telefonia mobile

hanno aggiunto la tecnologia HSDPA alle loro reti UMTS.

Recentemente l’HSPA e stato ulteriormente migliorato, introducendo nuo-

ve versioni indicate come HSPA+ (HSPA Evolution) ed in grado di offrire


velocita di accesso di 84 Mbit/s in dowload e di 10.8 Mbit/s per l’upload.

Le differenze principali tra HSPA e UMTS stanno nel fatto che la prima

ha un livello trasporto modificato e sono state apportate delle migliorie alle

specifiche del W-CDMA. HSPA si differenzia da UMTS anche per la gestione

migliorata delle informazioni, quali la qualita attuale del canale, e quanti dati

devono essere inoltrati nella successiva trasmissione.

3.8 GPS

Il GPS (Global Positioning System) e un sistema di posizionamento che e

stato largamente utilizzato in questo progetto. In particolare, viene sempre

utilizzato durante il primo avvio dell’applicazione, in quanto poi e lo stesso

Oracolo col passare dei secondi a decidere se le informazioni che sono pre-

senti nel database sono sufficienti per stimare ugualmente una lista di reti

candidate a cui accedere e quindi disattivare l’antenna GPS.

Per quanto riguarda gli smartphone odierni, mediamente e stato riscontra-

to un periodo che varia tra i quarantacinque e i novanta secondi dal momento

dell’attivazione dell’antenna prima che si riesca ad acquisire la propria posi-

zione. Inizialmente i primi abbinamenti di antenne GPS e dispositivi mobili

avevano il difetto di un considerevole utilizzo di energia, negli ultimi anni e

stato introdotto in questo tipo di telefoni il sistema AGPS (Assisted GPS ),

con cui e possibile ovviare a tali problemi: si fanno pervenire al termina-

le GPS, attraverso la rete di telefonia mobile o wireless, le informazioni sui

satelliti visibili dalla cella radio (o del server NAT del provider a cui si e

connessi utilizzando il Wi-Fi) a cui l’utente agganciato. Tale metodo porta

ad una riduzione del tempo per l’acquisizione della posizione, si parla infatti

di pochi secondi.

Alcune informazioni su GPS, per dare un’infarinatura generale al lettore.

Il GPS [45], e un sistema di posizionamento e navigazione satellitare civile

che, attraverso una rete satellitare dedicata di satelliti artificiali in orbita

(Figura 3.6), fornisce ad un dispositivo mobile munito di apposita antenna,

3.8 GPS 89

delle informazioni sulle sue coordinate geografiche ed orario, in ogni condizio-

ne meteorologica, ”ovunque” sulla terra o nelle sue immediate vicinanze ove

vi sia un contatto ”privo di ostacoli” con almeno quattro satelliti del sistema.

I termini ”ovunque” e ”privo di ostacoli”, sono da intendere nel seguente mo-

do: il segnale e raggiungibile se la posizione non e del tutto schermata, puo

infatti accadere che se ci si trova in un edificio e si abbia comunque copertura

sufficiente, magari a costo di una latenza maggiore, per allacciare il numero

necessario di satelliti.

Figura 3.6: Popolazione dei satelliti dei governi statunitense e cinese nel

Dicembre 2011.

La localizzazione, avviene tramite la trasmissione di un segnale radio da

parte di ciascun satellite e l’elaborazione dei segnali ricevuti da parte del

ricevitore (navigatore, smartphone e quant’altro). Il sistema GPS e gestito

dal governo degli Stati Uniti d’America (progetto nato nel 1973 e realizzato

dal dipartimento della difesa) ed e liberamente accessibile da chiunque sia


dotato di un ricevitore ad esso adibito. Nonostante cio, tale progetto divento

pienamente operativo solo nel 1994. Il suo grado attuale di accuratezza e

dell’ordine dei metri. Tale precisione e comunque dipendente dalle condizioni

meteorologiche, dalla disponibilita e dalla posizione dei satelliti rispetto al

ricevitore, dalla qualita di quest’ultimo e dagli effetti di radiopropagazione

del segnale radio in ionosfera e troposfera (come la riflessione).

Il sistema di posizionamento si compone di tre segmenti: il segmento

spaziale (space segment), il segmento di controllo (control segment) ed il seg-

mento utente (user segment). Il segmento spaziale comprende da 24 a 32

satelliti. Il segmento di controllo si compone di una stazione di controllo

principale, una stazione di controllo alternativa, varie antenne dedicate e

condivise e stazioni di monitoraggio. Il segmento utente, infine, e composto

dai ricevitori GPS. Il primo e costituito da satelliti che seguono un’orbita

circolare, dal 2010, sono una trentina disposti a gruppi di quattro per ogni

piano orbitale. Tali piani sono disposti in modo tale che solitamente si possa

ricevere il segnale dal almeno cinque satelliti. Per quanto riguarda il seg-

mento di controllo, esso e composto da stazioni di controllo (in Figura 3.7)

funzionanti e alternative (in caso di guasti delle prime) ed antenne dedicate

per la ricezione del segnale sulla terra.

Figura 3.7: Una stazione di controllo.

3.8 GPS 91

Tali stazioni, possono accedere alle antenne del controllo satellitare del-

l’aereonatuca degli USA per avere capacita di comando aggiuntive.

Servono inoltre, per controllare le traiettorie dei satelliti, aggiornare questi

ultimi periodicamente mandando il software tramite le antenne sovra citate.

Gli aggiornamenti servono anche a sincronizzare gli orologi atomici presen-

ti sui satelliti, utilizzati per mandare l’orario ai ricevitori che dovranno poi

stimare la distanza. Infine, il segmento utente e composto dalle centinaia di

migliaia di ricevitori militari e le decine di milioni di ricevitori degli utente

civili, commerciali e scientifici. In genere, i ricevitori sono contraddistinti

dal numero di canali, che indica quanti satelliti sono in grado di monitorare

simultaneamente. Il numero di canali e stato incrementato progressivamente

nel tempo. Tipicamente un moderno ricevitore commerciale dispone di un

numero di canali compreso tra venti e trentadue.

Il principio di funzionamento del GPS si basa su un metodo di posi-

zionamento sferico, detto trilaterazione10, che parte dalla misura del tempo

impiegato da un segnale radio a percorrere la distanza tra satellite e ricevi-

tore. Poiche il ricevitore non conosce quando e stato trasmesso il segnale dal

satellite, per il calcolo della differenza dei tempi, il segnale inviato dal satel-

lite e di tipo orario, grazie all’orologio atomico presente sul satellite stesso:

il ricevitore calcola l’esatta distanza di propagazione dal satellite a partire

dalla differenza (dell’ordine dei microsecondi) tra l’orario pervenuto e quello

del proprio orologio sincronizzato con quello a bordo del satellite, tenendo

conto della velocita di propagazione del segnale. Il ricevitore, deve quindi

risolvere un sistema di quattro equazioni col medesimo numero di incognite

(latitudine, longitudine, altitudine e tempo). Ciascun satellite emette su due

canali, uno per uso civile (frequenza 1575,42MHz ) e uno per uso militare

(frequenza 1227,6MHz).

Infine, vi sono anche sistemi alternativi al GPS. Per esempio il russo GLO-

10Trilaterazione: tecnica che permette di calcolare distanze fra punti sfruttando le pro-

prieta dei triangoli. La trilaterazione e una tecnica basata sulla determinazione di tre

valori fondamentali, con i quali si puo costruire un solo triangolo.


NASS ( Global Navigation Satellite System) che e stato impiegato solamente

dai militari russi e sovietici, fino a quando e stato reso pienamente dispo-

nibile anche ai civili nel 2007. Alcuni moderni smartphone, come l’iPhone

(dalla versione 4S), svariati modelli di Samsung (dal Glaxy S3 in poi) e la

serie Nexus (dal talbet Nexus 7 e dallo smartphone Nexus 5) sono muniti di

antenne in grado di riceve sia i segnali GPS sia i segnali GLONASS.

Inoltre GPS non e immune ad errori, che possono essere di svariato tipo: vi

sono errori dovuti all’orbitografia dei satelliti, errori legati alla propagazione

dei segnali verso terra (per esempio il ritardo) e quelli determinati dall’e-

lettronica. Questi ultimi, sono in genere gestiti tramite la taratura e i test

diretti sull’hardware. Un limite a questa gestione deriva dall’eventuale de-

gradazione dell’hardware nel tempo, che il lancio in orbita o l’esposizione a

raggi cosmici e vento solare puo causare.

Capitolo 4

Progettazione

La progettazione dell’applicazione e partita prendendo come base, il la-

voro di Paladino e Somenzi che come descritto nel Capitolo 1. Tale lavoro di

tesi presentava alcune imperfezioni, che sono state quindi sistemate prima di

procedere con gli obbiettivi prefissati da questo elaborato.

In particolare il precedente progetto prevedeva la scrittura dei risultati delle

scansioni in un file XML, solo quando l’utente fermava la scansione.

Si e pensato di rendere piu leggibili i risultati all’utente, effettuando la scrit-

tura di un file XML ad ogni scansione (differenziando per interfaccia).

I file sono nominati per data in formato ”aaaa-mm-gg-hh-mm-ss”.

La decisione di scrivere differenziando per interfaccia, e motivata dal fatto

che possono nascere dei conflitti in scrittura, qualora l’utente inserisca degli

intervalli di scansioni che siano uno il multiplo dell’altro.

In tal caso, i problemi che possono emergere sono di inconsistenza dei dati o

di impossibilita di accedere al file se questo, per esempio, viene bloccato per

scrivere i risultati delle scansione wireless mentre si prova ad accedere per

scrivere quelli relativi ai dati mobili. Un’altro aspetto migliorato rispetto al

lavoro di Paladino e Somenzi riguarda la gestione degli intervalli di scansione

per quanto riguarda l’interfaccia wireless. Come gia accennato diverse volte

in precedenza, Android non effettua realmente le scansioni secondo quanto

implementato da codice, utilizzando per esempio un thread che viene esegui-

93

94 4. Progettazione

to ciclicamente con all’interno le chiamate ai metodi offerti dalle API: questo

perche e comunque il kernel a gestire la periodicita di tali scansioni secondo,

un intervallo descritto alla voce wifi.supplicant scan interval nel file

buil.prop. Bisogna quindi utilizzare la libreria RooTools, per poter andare ad

assegnare l’intervallo inserito dall’utente a tale voce, in quanto il file e di si-

stema. Un’altra problematica risolta di tale progetto riguarda l’attivazione e

la disattivazione dell’antenna GPS. Infatti, la versione di Paladino e Somenzi

prevedeva il passaggio forzato dalla schermata delle impostazioni di sicurezza

per attivare il GPS, questo e dovuto alla politica di Android che per motivi

di sicurezza richiede all’utente il consenso per la geolocalizzazione.

Tale aspetto, puo risultare scomodo, soprattutto se si vuole implementare un

servizio in background che non richieda spesso l’interazione da parte dell’u-

tente, partendo dal presupposto che l’algoritmo prevede l’utilizzo del GPS il

piu possibile limitato in quanto si vuole salvaguardare il risparmio energeti-

co. Sono stati implementati quindi due metodi che effettuano l’attivazione

e la disattivazione dell’antenna GPS senza forzare l’utente ad interagire con

la schermata delle impostazioni di sistema. Tali soluzioni sono descritte in

dettaglio dal punto di vista implementativo nel Capitolo 5.

Riguardo a quest’ultima problematica, bisogna evidenziare che in rete vi so-

no delle soluzioni parziali, che sfruttano pero dei bug che affliggono il widget

di risparmio energetico. Tale approccio oltre a non essere elegante, presenta

ulteriori limitazioni, in quanto funziona solo su determinate versioni di An-

droid, per esempio fino a GingerBread, per poi non essere supportata per le

versioni successive fino a ritornare funzionante solo per la specifica versione

4.2.2. La soluzione proposta invece e stata testata da Android Gingerbread

fino a Kitkat, in tutte le versioni disponibili, funzionando senza visualizzare

la schermata delle impostazioni di sistema in tutti i casi fino alla versione

stock di KitKat rilasciata col nexus 5 (la 4.4), per poi invece tornare tor-

nare a visualizzare la classica schermata per gli aggiornamenti successivi di

quest’ultimo. Queste sono le modifiche effettuato al progetto di Paladino e

Somenzi utilizzato come base per sviluppare il resto dell’applicazione.

95

Nelle seguenti sezioni, verranno invece analizzati gli aspetti nuovi e piu

di progettazione, introdotti per ottenere l’applicazione discussa in questo

elaborato di tesi.

Figura 4.1: WorkFlow semplificato dell’applicazione dal punto di vista

dell’interazione dell’utente.

96 4. Progettazione

Si ricorda al lettore, prima di passare ad analizzare il lato client e il lato

server, che la struttura dell’applicazione nel suo complesso e descritta nella

Figura1.1 del Capitolo 1. L’applicazione infatti prevede un utilizzo di ”trai-

ning”, in cui usando il modulo chiamato ConnectionPointAnalyzer, vengono

rilevati gli access point wireless e le celle telefoniche popolando la base di

dati, o volendo, si puo utilizzare anche il modulo Oracolo per avere le fun-

zionalita di predizione della connettivita in base alla gestione della mobilita.

Il modulo ConnectionPointAnalyzer, inoltre funziona anche senza interagire

con la base di dati, semplicemente mostrando all’utente quanto rilevato dal-

le interfacce e salvando i risultati negli appositi file XML (progetto base di

Somenzi e Paladino con le opportune migliorie descritte in precedenza).

La Figura 4.1 mostra il flusso (semplificato) dell’applicazione tralasciando

caratteristiche come la consultazione dell’help e la scrittura dei file XML nel

dispositivo, ricordando che le funzionalita del modulo ConnectionPointAna-

lyzer prevedono tutto quello che concerne il lato client, quindi la scansione

delle interfacce e il visualizzare l’interfaccia all’utente.

Per il lato server, si hanno invece la base di dati e il modulo Oracolo per

la predizione e gestione delle interfacce, nonche responsabile della gestione

della mobilita del dispositivo.

4.1 Lato client

In questa sezione vengono descritti gli aspetti relativi al lato client.

I piu importanti, oltre alla gestione del GPS citata precedentemente, riguar-

dano aspetti quali la gestione del file build.prop con annesso utilizzo della

libreria RootTools. Inoltre, viene trattata anche la progettazione dell’inter-

faccia utente e di come sono gestite le varie fasi d vita di un’activity per

rendere l’applicazione veloce all’avvio e alla sua riesumazione.

Anche per quanto riguarda i concetti descritti in questa sezione, verranno

successivamente trattati nel Capitolo 5 dal punto di vista implementativo.

4.1 Lato client 97

4.1.1 Gestione del file build.prop

Per effettuare la modifica del file \system\build.prop per inserire l’inter-

vallo di scansione dell’interfaccia wireless specificato dall’utente, si e pensato,

per prima cosa, di leggere il contenuto del file usando la libreria RootTools

per montare la cartella system sia in lettura che in scrittura.

Successivamente, viene quindi letto il contenuto di tale file e ne viene creata

una copia nella cartella proprietaria dell’applicazione in modo da lavorarvi

con comodo, senza mettere modificare direttamente l’originale.

In particolare, su tale file di backup, viene controllata l’esistenza della voce

wifi.supplicant scan interval: se non e presente viene aggiunta in fondo

al file, altrimenti viene modificata settandola all’intervallo specificato dall’u-

tente.

Dopodiche viene rimosso il file build.prop originale, inserito quello di bac-

kup, che viene opportunamente rinominato e settato con gli stessi permessi.

Infine si riavvia il processo /system/bin/wpa supplicant, responsabile della

scansione dell’interfaccia wireless.

Infine si ricorda che gli intervalli si scansione vengono gestiti in modo

tale che l’utente non possa inserire valori inappropriati, per esempio troppo

brevi, in quanto potrebbero esserci problematiche con la base di dati e con

la gestione dell’Oracolo.

Basti pensare a quest’ultimo, se deve costruire una lista di reti candidate a cui

connettersi e tentare la connessione ad una di esse, e l’intervallo di scansione

risulta troppo breve, potrebbe essere eseguita una nuova scansione, che va

a richiamare lo stesso metodo dell’Oracolo o o uno diverso, mentre si sta

ancora instaurando la precedente connessione.

Quindi per entrambe le interfacce viene seguito tale procedimento: se l’utente

non inserisce alcun valore, viene settato automaticamente l’intervallo a tre

secondi. Mentre se l’utente imposta un valore inferiore al secondo, viene

corretto automaticamente ad un secondo.

98 4. Progettazione

4.1.2 Progettazione dell’interfaccia utente

L’interfaccia utente e stata progettata sulla base di quanto predisposto

dal progetto di Somenzi e Paladino. Per le schermate raffiguranti l’applica-

zione si rimanda al Capitolo 6. Inizialmente quindi l’applicazione presentava

un’interfaccia simile a quanto presente in Figura 6.2 ma col solo il pulsante di

avvio e terminazione delle scansioni. Erano inoltre assenti oltre al pulsante

per effettuare l’interazione con la base di dati, anche l’avviso con le istruzio-

ni per il primo avvio e le checkboxes per le preferenze di scelta inerenti agli

utilizzi successivi. Inoltre e stato reso disponibile un menu contestuale, con

la possibilita di consultare un help sull’utilizzo dell’applicazione, visualizza-

re il file di log con tutte le azioni fatte dal modulo Oracolo ed infine uscire

dall’applicazione (Figura 6.7). Il menu contestuale e le funzionalita da esso

offerte non erano presenti nel progetto di Somenzi e Paladino.

Particolare attenzione va prestata alla funzionalita che permette di uscire

dall’applicazione: per scelta progettuale, viene visualizzata una dialog che

chiede conferma all’utente notificandolo che verranno disattivate tutte le in-

terfacce (compresa l’antenna GPS). Questo perche si vuole minimizzare il

consumo energetico e far sı che l’applicazione una volta chiusa non dia quel

senso di ”invasivita” spesso poco piacevole. Da notare che tale caratteristica

e apprezzata, per esempio, molti utenti si lamentano del fatto che una volta

chiuso Google Maps, dopo il suo utilizzo l’antenna GPS e la connessione dati

rimangano attive, anche se prima non lo erano. A tal proposito si e quindi

pensato di procedere in tale direzione.

Le nuove funzionalita e l’interazione con quelle lato server (utilizzo del-

la base di dati e del modulo Oracolo) sono state introdotte per mantenere

l’interfaccia il piu sobria e semplice per facilitarne l’utilizzo dal punto di vi-

sta dell’utente. Vengono infatti usati solo pulsanti e checkboxes alla portata

anche degli utenti meno esperti. In particolare viene messa a disposizione

dell’utente l’opportunita di utilizzare l’Oracolo solo quando si sta interagen-

do col database, in quanto cosı facendo si tiene aggiornato quest’ultimo.

Tale funzionalita e quindi rappresentata da una checkbox che compare solo

4.1 Lato client 99

dopo aver premuto il pulsante per interagire con la base di dati. Inoltre, non

viene salvata alcuna preferenza dell’utente riguardo all’utilizzo dell’Oracolo

stesso per gli avvii successivi. Questo perche si vuole rendere l’applicazione

utile si, ma non invasiva, lasciando decidere quindi all’utente se vuole che la

gestione delle interfacce venga delegata al servizio che parte in background

all’avvio, oppure lanciando l’applicazione stessa ogni qualvolta esso lo desi-

deri. Quindi, se l’utente al primo utilizzo dell’applicazione specifica che essa

puo partire in automatico negli avvii successivi del dispositivo, allora essa si

presentera in tali circostanze come un servizio in background con gli intervalli

di scansione settati coi valori impostati nel primo utilizzo.

Inoltre se il servizio e attivo in background e viene lanciata l’applicazione dal-

l’apposito menu, allora l’interfaccia presentera i campi gia compilati secondo

le preferenze dell’utente, con i pannelli relativi ai risultati delle scansioni e

quello dei messaggi di log e di errore completamente funzionanti. E quindi

evidente che si necessita della presenza di un file contenente tali preferenze

(avvio automatico, valori degli intervalli di scansione ecc ecc..). Questo file,

viene salvato nella cartella dell’applicazione e viene letto dopo aver avviato il

dispositivo, in modo da lanciare o meno il servizio in base al suo contenuto.

Riguardo alla cartella dell’applicazione, avente nome ConnectionPointA-

nalyezer, essa viene creata nella memoria del dispositivo e non su schede

esterne, questo per evitare problemi di accesso ad essa durante l’avvio del

telefono: infatti i dispositivi che possiedono una scheda SD e che non sono

molto potenti, tendono ad impiegare un periodo di tempo non indifferente

per montare tale unita di memoria e potrebbero quindi nascere degli errori

in quanto il servizio non riesce ad accedere alla risorsa. Quindi si e scelto di

situare la cartella nella memoria del telefono, evitando quindi di inserire nel

codice attese forzate e rendendo quindi il tutto particolarmente performante.

4.1.3 Gestione delle fasi di vita di un activity

Nel Capitolo 3, si e parlato del ciclo di vista di un’activity (Figura 3.4)

dicendo che i metodi responsabili dell’avvio e della riesumazione dell’activity

100 4. Progettazione

stessa devono avere poca mole di lavoro, in quanto sono quelli che danno il

feedback di velocita e reattivita dell’applicazione all’utente.

Per quanto riguarda il progetto, esso e composto da una sola activity, poiche

l’interfaccia e semplice e non necessita di utilizzarne altre.

Inoltre la caratteristica principale, e quella di utilizzare il tutto come servizio

e quindi non e stato necessario curare molto la parte grafica utilizzando piu

activities.

Riguardo all’activity in questione, i metodi responsabili della reattivita del-

l’applicazione sono appunto onCreate ed onResume. Rispettivamente per il

rendere il tutto snello, nel primo oltre a definire le componenti dell’interfac-

cia grafica (da fare obbligatoriamente in tale metodo), vengono inizializzati

gli oggetti per interagire con la base di dati e bindati i metodi per gestire i

click sui pulsanti. Oltre a cio viene controllato se l’esecuzione corrente e la

prima e in tal caso, non vengono lette le impostazioni dell’utente dal file di

configurazione, cosa che invece viene fatta per le esecuzione successive.

Saranno poi i metodi adibiti ai click dei pulsanti a lanciare i servizi di scan-

sione delle interfacce, quindi per quanto riguarda il metodo onCreate si puo

affermare che sia stato reso il piu possibile leggero e la velocita con cui l’ap-

plicazione si avvia ne e la conferma. Per quanto riguarda onResume, esso

viene utilizzato per riesumare l’applicazione, quindi parte dal presupposto

che essa sia gia stata avviata. Quello che viene fatto in tale metodo, e gestire

le componenti grafiche, per esempio essendo gia stata utilizzata l’applicazione

gli intervalli delle scansioni sono stati inseriti e queste ultime sono in esecu-

zione, quindi vengono resi non editabili le caselle di testo con tali valori e via

dicendo (vengono nascosti i messaggi di aiuto utili duranti l’avvio dell’appli-

cazione). Infine nella onResume viene eseguita un’operazione importante, si

gestisce infatti un receiver utile a prendere i messaggi di broadcast del servizio

adibito alle scansioni delle interfacce. Tale receiver, prende quindi i risultati

del servizio e stampa il tutto nella apposite caselle di testo dell’interfaccia

grafica. La suddetta operazione non e complessa computazionalmente, in

quanto i risultati sono delle stringhe da inserire nelle caselle di testo.

4.1 Lato client 101

Viene quindi fatta solo nella onResume, in quanto questa viene chiamata

sempre anche nel caso si avvii l’applicazione per la prima volta.

4.1.4 Servizi

Per quanto riguarda la progettazione dei servizi, rispetto al lavoro di So-

menzi e Paladino, sono state apportate delle modifiche. Infatti, nella versione

base del progetto veniva lanciato un servizio che si occupava di effettuare ci-

clicamente la scansione delle reti wireless. Le modifiche strutturali effettuate

rispetto a tale versione sono molteplici: per prima cosa, come accennato in

precedenza, e stata modificata la gestione dell’intervallo di scansione dell’in-

terfaccia wireless modificando i file build.prop prima di lanciare il suddetto

servizio. Cosı facendo si e sicuri che la scansione viene effettuata col periodo

specificato dall’utente e non da quello definito di default da Android.

Un’altra importante modifica riguarda la gestione di tale servizio e la se-

guente: la prima versione non prevedeva la scansione dell’interfaccia dei dati

mobili, quindi il servizio prevede di lanciare due thread separati rispettiva-

mente per le due interfacce di connessione, eseguendoli se possibile sfruttando

le architetture multiprocessore. Tali thread eseguiranno le scansioni secon-

do gli intervalli specificati dall’utente inserendo i dati nella base d dati o

modificando le tuple gia esistenti.

Inoltre l’applicazione all’avvio parte con tutte le interfacce attivate (com-

presa l’antenna GPS) e se l’utente ha deciso di utilizzare l’Oracolo, il servizio

chiama il metodo principale di tale modulo che poi si occupera di gestire le

interfacce in modo autonomo.

Quindi il servizio, effettua le scansioni delle due interfacce in modo cicli-

co, se l’utente ha scelto di utilizzare la base di dati, ad ogni ciclo vengono

vi inseriti i dettagli delle reti rilevate ed infine se anche la funzionalita Ora-

colo e attiva, si interagisce anche con quest’ultimo modulo, per gestire le

interfacce autonomamente. Risulta quindi evidente, che e il servizio, chia-

mato ScanService, ad effettuare la gran parte del lavoro ed a coordinare i

vari moduli che possono essere intesi come l’interfaccia utente che visualizza


i risultati delle scansioni, l’interazione con la base di dati e le chiamate ai

metodi dell’Oracolo.

4.1.5 Broadcast Receivers ed Intent Broadcast

Lo ScanService descritto poco fa utilizza delle componenti molto diffuse

in Android, chiamate Intent BroadCast, che sono un particolare tipo di intent

che vengono spediti attraverso il metodo sendBroadcast.

Solitamente vengono utilizzati per lanciare una intent in broadcast conte-

nente al suo interno dei dati. Nel caso del progetto, tali dati sono i risultati

delle scansioni. La activity dell’applicazione che e bindata con lo ScanService

rimane in ascolto di questa tipologia di intent, gestendo solo quelli col flag ca-

ratterizzato dallo ScanService. La tecnica per mettersi in ascolto e gestire tali

Intent Broadcast prevede l’utilizzo dei Broadcast Receiver, un’altra tipologia

di componente ampiamente utilizzata per sviluppare in ambiente Android.

Tali Broadcast Receiver sono utilizzati per notificare le applicazioni, di de-

terminati eventi in modo che queste ultime reagiscano di conseguenza.

Suddetto procedimento viene implementato nel progetto di tesi, l’activity re-

sponsabile, bindata col servizio, si mette in ascolto utilizzando un Broadcast

Receiver in modo da catturare gli Intent Broadcast lanciati dallo ScanService.

Questi ultimi contengono i risultati delle scansioni che verranno poi visualiz-

zati nell’interfaccia utente. Un’ulteriore informazione, lo stesso Android fa

uso di queste direttive per gestire funzionalita di sistema, per esempio per no-

tificare lo stato di carica della batteria, cambiamenti relativi alla connessione,

chiamate e sms in arrivo.

Ulteriori intent vengono ampiamente utilizzate nel progetto (un esempio

banale e per la visualizzazione del file di log), ma si tralascia la loro descrizio-

ne, in quanto seguono le regole descritte nella documentazione ufficiale [55]

. Casi particolari riguardano l’attivazione e la disattivazione dell’antenna

GPS e la possibilita di far partire automaticamente l’applicazione agli avvii

successivi del dispositivo. Tali metodi verranno descritti nella sezione 5.3.

4.2 Lato server 103

4.2 Lato server

In questa sezione vengono descritte le scelte progettuali piu importanti ri-

guardanti il lato server. Principalmente la gran parte del lavoro svolto riguar-

da la progettazione della base di dati e l’algoritmo decisionale dell’Oracolo.

4.2.1 Base di dati

Il progetto iniziale di Somenzi e Paladino prevedeva che dal lato server

venissero ricevuti i file XML e gestiti in qualche modo dall’Oracolo per im-

magazzinare le informazioni delle scansioni. La gestione in senso stretto dei

dati e stata effettuata con la soluzione piu logiche, ovvero con un database la

cui struttura e mostrata in Figura 4.2 (i campi in blu non ammettono valori

nulli).

Tale base di dati viene utilizzata in diversi ambiti: dal modulo Connec-

tionPointAnalyzer quando vi inserisce le reti rilevate o quando va a modifica-

re quelle presenti, ma anche dal modulo Oracolo per gestire automaticamente

le interfacce attraverso l’algoritmo di predizione.

Figura 4.2: Diagramma ER della basi di dati utilizzata nell’applicazione.


Dalla figura qui sopra, si capisce come la struttura sia la piu essenziale

possibile, infatti la base di dati e formata da tre tabelle: una per le connes-

sioni Wi-Fi, una per quelle dei dati mobili ed infine una per le coordinate

GPS. Quest’ultima tabella serve principalmente come raccolta delle posizio-

ne toccate dal dispositivo mobile, in modo da offrire tali valori come chiavi

esterne alle altre due tabelle. Spesso pero, tali coordinate possono essere

non disponibili durante una scansione, sia perche il dispositivo impiega un

certo lasso di tempo per ricevere il segnale dai satelliti, ma anche per la po-

litica di gestione attuata nel progetto stesso che prevede quando possibile

di salvaguardare il risparmio energetico, disattivando, qualora ve ne siano

i presupposti l’antenna GPS. Essendo tali coordinate delle chiavi esterne, e

stata scartata l’ipotesi di ammettere il valore NULL, poco elegante nel caso

di operazione di join. Si e quindi pensato di inizializzare tali valori ad un

reale definito a priori di valore -999.0. A questo punto ammettendo tuple di

connessioni con coordinate GPS non valide, sorge il problema di localizzare

tali entries. Si e quindi pensato di sfruttare la topologia dello scenario at-

tuale, in cui spesso quando si e allaciati ad una cella dati vi e la presenza

di piu access point Wi-Fi. Di conseguenza, e stato inserito l’identificatore

della cella telefonica nelle tuple delle connessioni wireless. In questo modo, si

ha una sorta di tecnica di localizzazione (seppure meno precisa del GPS) che

permette di sapere in quale zona e all’incirca situato un access point wireless.

Questa soluzione e accettabile, in quanto in presenza di scenari in cui non vi

sia molto da fare, per esempio quando si e in treno e ci si trova in una zona in

cui non vi e alcuna rete wireless e non si ha connettivita per quanto riguarda

le celle telefoniche, anche la presenza delle coordinate GPS sarebbe di poca

utilita. Torna invece utile, avere questa associazione tra identificativo della

cella telefonica e connessione wireless, quando si deve stimare il movimento

del dispositivo, utilizzando i parametri relativi alle potenze dei segnali per

ottenere la direzione dello spostamento. Lo schema ER in Figura 4.2, puo

essere letto nel seguente modo: una connessione dati puo appartenere a piu

connessioni wireless, viene quindi messa la chiave primaria della tabella delle

4.2 Lato server 105

connessioni dati in quella delle connessioni Wi-Fi.

La stessa coppia di coordinate GPS possono appartenere contemporaneamen-

te ad una o piu connessioni wireless, analogo discorso per quanto riguarda

le connessioni dati mobili. Quest’ultimo aspetto, va inteso come coordinate

GPS del luogo in cui vengono per esempio rilevate piu reti wireless e non le

coordinate GPS dell’esatta locazione dell’access point.

Solitamente il dispositivo allaccia una singola cella alla volta (almeno che

non si tratti di dispositivi dual-sim), ma contemporaneamente puo rilevare

piu connessioni wireless. In realta nell’implementazione del progetto e previ-

sta anche la gestione delle celle appartenenti allo stesso operatore a cui pero

non si e connessi. In tal caso queste ultime, vengono inserite nell’apposita

tabella delle connessioni dati tralasciando pero la relazione con eventuali reti

wireless. Il campo FLAG, presente nella tabella delle connessioni wireless,

serve come informazione relativa allo stato di quella rete rispetto al dispo-

sitivo: ha infatti il significato di catalogare se a tale rete il dispositivo e in

grado di connettersi, non e in grado di connettersi oppure non e ancora stata

tentata la connessione. Questo campo e molto utile al fine della creazione

della lista di reti candiate per la connessione, insieme alle informazioni forni-

te dal wpa supplicant. A tal proposito si rimanda il lettore alla progettazione

dell’algoritmo gestito dall’Oracolo 4.2.3.

Sempre riguardo alla progettazione della base di dati, non e necessario

utilizzare nella tabella delle connessioni dati mobili una chiave primaria mul-

ticampo, basta affidarsi al CID [56], che diventa a sua volta chiave esterna

nella tabella delle connessioni wireless. Non e quindi necessario mettere nella

chiave primaria altri campi come l’MNC che indica l’operatore.

Per sicurezza pero, quando si deve prendere la decisione di allacciarsi o meno

ad una cella telefonica, viene considerato anche il campo LAC rilevato dal

dispositivo, in modo da vere coerenza con quanto presente nel database: cosı

facendo si ha la sicurezza di essere correttamente localizzati, in quanto si ha

a disposizione il codice dell’area in cui ci si trova e l’identificativo di una

determinata cella in quella zona.


La Figura 4.3 rende meglio l’idea di come sono disposte le chiavi nelle

tabelle che costituiscono la base di dati.

Figura 4.3: In evidenza le chiavi primarie ed esterne delle tabelle che

costituiscono la base di dati.

Infine, riguardo alle coordinate GPS e alla scelta di utilizzare una stringa

e non un reale per rappresentarle, si rimanda il lettore alla sezione 5.2, dove

viene descritta la perdita di precisione, dovuta agli arrotondamenti dei reali,

eseguiti da SQLite. Utilizzando la stringhe, la ”griglia” che si ottiene per

rappresentare la ”nuvola di punti” di una rete spostandosi all’interno della

sua zona di copertura e ben definita (si parla di un paio di metri).

Con l’utilizzo dei numeri reali lasciando la gestione ad SQLite, le maglie di

tale griglia erano ”piu larghe”, la ”nuvola di punti” risultava essere troppo

approssimativa, i calcoli presenti nella sezione 5.2 dimostrano che in tal caso,

per variazione decimale di SQLite possono corrispondere anche cento metri,

decisamente troppo, soprattutto se si fa riferimento ad una rete wireless.

4.2.2 Oggetti WifiList e UmtsList

Gli oggetti utilizzati nel codice, per rappresentare una connessione dati

mobile o una connessione wireless, presentano dei campi in piu rispetto agli

4.2 Lato server 107

attributi visti precedentemente per modellare la base di dati.

Tale discorso vale soprattutto per l’oggetto che rappresenta una connessione

wireless, in quanto sono necessarie informazioni aggiuntive, soprattutto per

costruire la lista delle connessioni candidate in base allo spostamento del

dispositivo. Per quanto riguarda una connessione dati mobili, l’oggetto che

la rappresenta e composto dagli stessi campi analizzati nella progettazione

della base di dati a meno di una precisazione per gestire le celle vicine a

quella a cui si e allacciati. Vediamo per primo quindi l’oggetto della classe

UmtsList, utilizzato per rappresentare una connessione dati mobile. i suoi

campi sono descritti di seguito:

• int NEIGHBOR CODE TYPE: valore di controllo che serve per verifi-

care se data una cella a cui si e connessi, il dispositivo rileva altre celle

dello stesso operatore nelle vicinanze. Viene quindi fatto un successivo

controllo su tale valore e se e diverso dal valore simbolico 999, allora

vuol dire che vi sono altre celle nelle vicinanze, le cui caratteristiche

vengono inserite in una lista. La maggior parte di questi campi sono

ottenibili direttamente con le API di Android.

• int networkType: campo in cui viene salvato il tipo di rete (UMTS,

HSPA ecc ecc...).

• int signalStrenght: campo in cui viene salvato un valore compreso tra

1 e 4 in relazione alla potenza del segnale (in dBm) ricevuto.

Serve per valutare se una cella e una buona candidata per l’handover.

• int cid: campo in cui viene salvato l’identificatore della cella.

• int mcc: campo in cui viene salvato il codice della nazione.

• int mnc: campo in cui viene salvato il codice dell’operatore telefonico.

• int lac: campo in cui viene salvato il codice della Location Area. Insieme

al cid, serve per identificare in modo univoco una cella. Assume il valore

-1 se la location area e sconosciuta.


• String lat: latitudine da cui si sta rilevando la cella.

• String lng: longitudine da cui si sta rilevando la cella.

• String date: data in cui viene rilevata la cella. Serve per aggiornare

eventualmente il database.

Tutti i campi sono privati, la stessa cosa vale per quelli costituenti l’og-

getto per le connessioni wireless: per gestirli vengono quindi utilizzati gli

appositi metodi getters e setters. Per quanto riguarda l’oggetto della classe

WifiList, i campi che lo compongono sono descritti di seguito:

• String ssid: SSID (Service Set Identifier) della rete.

• String capabilities: campo in cui viene salvata una stringa che descrive

i tipi di autenticazione, gestione delle chiavi e schemi di crittografia

supportati dall’access point.

• String frequency: la frequenza del canale in MHz su cui il client sta

comunicando con l’access point.

• String level: il valore in dBM del segnale.

• int sLevel: Valore compreso tra 1 e 4 per identificare la potenza del

segnale ricevuto. E il campo utilizzato per valutare se abbandonare un

access point e considerarne un altro come candidato.

• String mac: indirizzo MAC dell’access point.

• String rssi: potenza del segnale descritta con RSSI (Received Signal

Strength Indication).

• String date: data in cui viene rilevato l’access point. Serve per aggior-

nare eventualmente il database.

• String cidUmts: se viene agganciata una cella mentre si e connessi

all’access point rappresentato dall’oggetto corrente, allora il cid di tale

4.2 Lato server 109

cella viene salvato in questo campo. Serve per fornire un meccanismo

di localizzazione in assenza di informazioni provenienti dal GPS.

• String latitudeWifi: latitudine da cui si sta rilevando l’access point.

• String longitudeWifi: longitudine da cui si sta rilevando l’access point.

• String int supplicantStatus: stato assegnato dal wpa supplicant a tale

connessione wireless. Tale informazione, viene ottenuta run time per

le reti rilevate dal dispositivo ed e fondamentale per costruire la lista

delle connessioni candidate. Questo campo indica come il dispositivo

considera la connessione (non la valuta come affidabile oppure la valuta

come papabile per connettersi).

• int networkId: identificatore utilizzato dal wpa supplicant per identifi-

care una rete all’interno del file delle configurazioni di rete.

Viene utilizzato dall’algoritmo dell’Oracolo per costruire la lista delle

connessioni candidate.

• String EAP: campo utilizzato per le reti che richiedono autenticazione

EAP e derivate (PEAP, MSCWPA ecc ecc..). Puo quindi anche non

essere assegnato.

• String identity: campo utilizzato per autenticarsi con reti di tipologia

EAP. Indica lo username.

• String phase2: campo sempre relativo a tecniche di autenticazione

a due fasi come PEAP e MSCWPA (un esempio e la rete wireless

dell’Universita di Bologna).

• String password: campo in cui viene salvata la password per l’autenti-

cazione. Questo campo viene utilizzato sempre qualora vi sia richiesta

una password e non solo in casi particolari di autenticazione, come gli

ultimi appena visti.


Come si puo notare dalla composizione della classe WifiList, l’applicazione

e in grado di funzionare con la gran parte delle tecniche di autenticazione

presenti nelle reti wireless odierne (non solo quindi con le classiche WEP o

WPA).

4.2.3 Algoritmo di predizione dell’Oracolo

Si passa ora ad analizzare l’algoritmo principale che gestisce il modulo

chiamato Oracolo. Prima di considerare in quali possibili scenari l’Oracolo

puo operare, e bene precisare un aspetto dell’applicazione relativo a tale

modulo. L’Oracolo viene utilizzato solamente dopo che l’utente ha attivato

l’opportuna opzione, la chiamata a tale modulo viene effettuata dal servizio

adibito alla scansione delle interfacce. Tale servizio, richiama il metodo di

ingresso dell’algoritmo per la gestione dell’Oracolo, adibito alla gestione delle

interfacce che sono tutte attive appena avviata l’applicazione.

Puo quindi sorgere il dubbio che ad ogni ciclo di scansione effettuato dal servi-

zio, venga sempre richiamato tale metodo, in realta per evitare che cio accada

e stato inserito un campo di controllo all’interno della classe OracoloBrain

che gestisce l’Oracolo stesso. Tale campo viene settato opportunamente in

base allo scenario in cui ci si trova, in modo che il servizio responsabile delle

scansioni vada ad evocare i metodi corretti nei cicli di scansione successivi al

primo. Oltre a cio e bene fare un’ulteriore distinzione per quanto riguarda gli

accessi alla base di dati. Il servizio va ad inserire o modificare i dati qualora

l’opzione di interazione col database sia stata selezionata dall’utente.

Ad ogni ciclo di scansione, se viene rilevata una rete gia presente, essa viene

aggiornata con le nuove informazioni (a tal proposito, ecco spiegata l’utilita

del campo ”data”). Anche l’Oracolo interagisce col database, affidandosi a

quanto inserito dal servizio di scansione: in particolare, accede alle informa-

zioni per capire a quale access point o cella connettersi ed eventualmente,

modifica i campi flag utili a tener traccia della capacita o meno del disposi-

tivo di utilizzare tale connessione. Risulta quindi evidente che quanto detto

nella sezione 2.3 e confermato da tale modo di procedere, ogni dispositivo ha

4.2 Lato server 111

una propria base di dati personalizzata, influenzata dalle configurazioni di

rete e dalle preferenze dell’utente.

Come detto in precedenza, una volta avviata l’applicazione (anche co-

me servizio), vengono attivate tutte le interfacce. La classe OracoloBrain,

prevede quindi un metodo di ingresso chiamato all’avvio dell’applicazione di

nome allInterfacesActived, che in base alla circostanza in cui ci si trova chia-

mera opportunamente gli altri metodi. In sintesi gli scenari da gestire sono

i seguenti:

1. Tutte le interfacce attive, gestito col metodo allInterfacesActived.

2. L’interfaccia wireless e l’antenna GPS attive, gestito col metodo wi-

fiAndGpsActived.

3. Solo l’interfaccia wireless attiva, gestito col metodo onlyWifi.

4. L’interfaccia di connessioni dati mobili e l’antenna GPS attive, gestito

col metodo umtsAndGpsActived.

5. Solo l’interfaccia connessioni dati mobili attiva, gestita col metodo

onlyUmts.

Verranno di seguito spiegati i cinque scenari appena citati, soffermandosi

sui punti piu importanti della progettazione.

Tutte le interfacce attive

Questo scenario viene gestito praticamente solo all’avvio dell’applicazione

o del servizio, in quanto poi la politica del progetto prevede di utilizzare solo

le interfacce strettamente necessarie per salvaguardare il consumo energeti-

co. La prima cosa che viene fatta, e considerare le reti wireless rilevate dalla

scansione ed effettuare un’interrogazione al database basandosi sugli indirizzi

MAC ottenuti e sulla potenza del segnale che deve essere buona (di un valore

due della scala che va da zero a quattro descritta in precedenza nei campi

degli oggetti rappresentanti le connessioni). Ovviamente se si ha la ricezione


delle proprie coordinate GPS, quest’ultime vengono considerate effettuando

un’interrogazione al database piu fine, prendendo le tuple che si trovano al

massimo ad una distanza di dieci metri dalla posizione attuale.

Se non vi sono risultati dalle interrogazioni appena descritte allora si di-

sattiva l’interfaccia wireless e si passa alla gestione del caso 4), ovvero con

l’interfaccia dei dati mobili e l’antenna GPS attive. Se invece le interrogazio-

ni hanno restituito qualche risultato, si vanno a considerare le configurazioni

di rete presenti sul dispositivo. L’obbiettivo e quello di costruire una lista di

connessione candidate ordinata per preferenza. Per fare cio, si considerano

le configurazioni e i risultati ottenuti del database creando una lista risul-

tante dalla loro fusione (comprendente quindi anche username e password

per eventuali autenticazioni, dati che non sono ottenibili altrimenti dalle sole

API di Android). A tal proposito, si rimanda il lettore alla sotto sezione

4.2.4, in quanto tale procedura viene utilizzata piu volte nel corso dell’algo-

ritmo ed e quindi spiegata a parte. Una volta ottenuta tale lista, si tenta la

connessione partendo dalla candidata migliore, se tale tentativo va a buon

fine allora si esegue una query sulla base di dati per aggiornare i FLAG al va-

lore ”CAN CONNECT delle entries interessate. Se il tentativo di instaurare

una connessione fallisce, allora la query che viene eseguita andra a settare il

campo FLAG al valore ”CAN NOT CONNECT”. Se viene instaurata una

connessione allora si passa al punto 3), ovvero al caso con solo l’interfac-

cia wireless attiva, disattivando anche l’antenna GPS per salvaguardare la

batteria. In precedenza, e stato detto che se non si ottiene alcun risultato

interrogando la base di dati per quanto riguarda le connessioni wireless, si

passa al caso 4). Quest’ultimo viene richiamato anche qualora non si rie-

sca ad instaurare una connessione provando tutte le candidate della lista.

Se entrando nel caso 4), gestendo quindi la connessione dati mobili non si

ha alcuna copertura e l’utente non si sta muovendo, l’unica cosa da fare e

notificarlo che attualmente non vi sono connessioni disponibili.

4.2 Lato server 113

Interfaccia wireless e antenna GPS attive

Da questo punto in poi, si parte dal presupposto che l’Oracolo abbia gia

eseguito il metodo di ingresso dell’algoritmo dove tutte le interfacce erano

attive. In questo scenario, si tiene conto dello spostamento dell’utente, con-

siderando gli ultimi tre punti (intesi come latitudine e longitudine) rilevati

dal GPS. Oltre a cio, viene monitorata la potenza del segnale alla rete a

cui si e connessi in base a tali spostamenti, nonche quelle degli access point

rilevati in zona. Se le coordinate GPS non sono valide, allora viene richia-

mato direttamente il metodo 3), ovvero quello per gestire solo l’interfaccia

wireless in quanto l’antenna GPS viene disattivata. Altrimenti, si valuta la

potenza del segnale della rete attuale, monitorando il suo andamento nelle

ultime tre rilevazioni. Se la potenza del segnale raggiunge un livello critico,

allora vengono prese le migliori tre reti di cui si era tenuta traccia del segnale

e si interroga la base di dati, considerando le tuple che sono ad una distanza

massima di dieci metri dalla posizione attuale e che hanno un segnale ac-

cettabile (maggiore o uguale a due nella scala che va da zero a quattro) e

con FLAG avente valore ”CAN CONNECT”. Analogamente a quanto de-

scritto nel caso precedente, si costruisce la lista delle connessioni candidate

utilizzando le configurazioni di rete presenti nel dispositivo. Scandendo tale

lista si prova ad instaurare una connessione, partendo dalla migliore e mo-

dificando opportunamente il campo FLAG delle connessioni presenti nella

tabella wireless della basi di dati. Se una connessione viene instaurata, si

rimane nel caso corrente, altrimenti si passa nello scenario 4), ovvero con

l’interfaccia dei dati mobili e l’antenna GPS attivi. Quest’ultimo passaggio

e comunque facilitato, in quanto nella tabella delle connessioni wireless si

tiene traccia anche di eventuali identificatore delle celle. Si hanno quindi gia

preziose informazioni, quali la presenza di celle del proprio operatore nella

zona e la loro potenza del segnale. Tali informazioni sono veramente utili, in

quanto se si sta giungendo al termine della lista dei candidati e non e stata

ancora instaurata una connessione, allora si puo gia attivare l’interfaccia dei

dati mobili, guadagnando tempo. Inoltre, si puo controllare se le coordinate


GPS attuali (in quanto siamo nel caso in cui sono disponibili) localizzano il

dispositivo ad una distanza sensata rispetto alla cella, affidandosi quindi alle

coordinate GPS presenti nella tabella delle connessioni dati.

In questo caso, la distanza e fissata a trenta metri per avere molta efficienza,

ma la si puo modificare in quanto dopo varie prove si e notato che l’algorit-

mo risulta ugualmente affidabile. Se le coordinate GPS non sono disponibili

nella tabella delle connessioni dati, ci si affida alla sola potenza del segnale

salvata.

Solo l’interfaccia wireless attiva

Questo scenario e simile al caso 2) ma senza l’utilizzo del GPS, ci si

affida quindi alle sole potenze dei segnali rilevati (sia dell’access point a cui

si e connessi sia degli altri), per stimare la direzione dello spostamento. Al

solito, finche il segnale della connessione attuale rimane accettabile (maggiore

o uguale a due su una scala che arriva fino a quattro) si rimane collegati

all’access point corrente, rimanendo di conseguenza in questo caso anche

nella successiva scansione. Altrimenti, se il segnale della connessione attuale

sta scendendo e raggiunge un livello critico (minore di due), si controlla se

vi sono altre connessioni wireless con un buon segnale e nel caso si passa a

costruire la lista dei candidati, ripetendo il ragionamento visto nei precedenti

scenari (tentativi di connessione, modifica della base di dati ecc ecc..).

Se tale lista, contiene almeno un candidato e ci si riesce a connettere, allora

si rimane ancora nello scenario attuale. Altrimenti, in caso di fallimento dei

tentativi di connessione, o in assenza di candidati validi, si passa al punto

5), ovvero con solo l’interfaccia dei dati mobili attiva.

Quanto detto nel punto precedente e ancora valido, ovvero nella tabella delle

connessioni wireless del database vi sono salvati gli identificatori delle celle

telefoniche del proprio operatore. Si sa a priori se attivare o meno l’opportuna

interfaccia, anticipando il tutto, qualora i tentativi di connessione con le reti

candidate wireless non stia andando per il meglio.

4.2 Lato server 115

Interfaccia dati mobili e antenna GPS attive

Anche in questo scenario, per prima cosa si controlla se ci si sta muoven-

do. In caso negativo si lascia tutto invariato in quanto al prossimo ciclo di

scansione verra richiamato ancora lo stesso metodo. Altrimenti si controlla

il risultato della scansione dell’interfaccia dati, in quanto il servizio adibi-

to a tale funzionalita oltre ad ottenere le informazioni sulla cella a cui si e

connessi, rileva anche le informazioni di eventuali celle dello stesso operato-

re nelle vicinanze. Si procede quindi ad interrogare il database, utilizzando

le coordinate GPS e prendendo le tuple relative alle celle che sono ad una

distanza accettabile (inferiore a trenta metri). Il risultato ottenuto da tale

interrogazione viene ulteriormente scremato, considerando le celle che han-

no una buona potenza del segnale, con l’identificatore e location area uguali

ad una delle celle vicine rilevate nella scansione. Il gestore telefonico di tali

risultati e lo stesso della cella a cui si e allacciati attualmente, in quanto

attraverso le API di Android si riescono ad ottenere tali valori solo per le

celle del proprio operatore. Anche in questo caso, viene quindi costruita una

lista di candidati (in realta per le connessioni dati si tratta di una mappa

<distanza, oggettoConnessione>). Se tale mappa non e vuota, si forza

il dispositivo alla connessione della cella piu vicina. Tutto questo viene fatto

qualora vi siano coordinate GPS valide, in caso contrario viene effettuato un

tentativo con l’interfaccia wireless prima di richiamare il metodo responsabile

dello scenario 5) (con solo l’interfaccia dei dati mobili attiva).

Successivamente, si effettua un’interrogazione sul database avendo a dispo-

sizione l’identificatore della cella a cui si e connessi e risalendo quindi ad

eventuali reti wireless rilevate in passato nella zona. Se la query non restitui-

sce alcun risultato allora si passa allo scenario 5), altrimenti viene eseguito il

solito procedimento di costruzione della lista di connessioni candidate attin-

gendo dalle configurazioni di rete del dispositivo. Se si riesce ad instaurare

una connessione ad una delle reti wireless candidate, allora si passa allo sce-

nario 3), cioe viene mantenuta solo l’interfaccia wireless attiva, altrimenti se

tali tentativi falliscono si passa al caso 5), mantenendo solo l’interfaccia per i


dati mobili attiva. Ovviamente quando si tenta di instaurare una connessione

alle reti wireless, viene modificato in modo appropriato il database (campi

”FLAG”) in base agli esiti di tali tentativi.

Solo l’interfaccia dati mobili attiva

Questo scenario viene gestito in maniera simile al caso precedente ma

senza l’ausilio del GPS. Ci si affida quindi al concetto di storico della cella a

cui si e collegati, valutando se la potenza del segnale sta calando o se rimane

a livelli accettabili. Se il segnale rimane buono non viene fatta alcuna azio-

ne, al prossimo ciclo di scansione il servizio chiamera nuovamente il metodo

responsabile di tale scenario. Se invece il segnale raggiunge un livello critico

per prima cosa vengono controllate le eventuali celle vicine, qualora ve ne

siano, alla ricerca di una che abbia un segnale piu forte: se presente una cella

migliore si forza la connessione ad essa (rimanendo ancora in questo caso),

altrimenti si avvia l’interfaccia wireless. Ovviamente questo viene fatto in

anticipo gia quando si nota che la ricerca delle celle vicine non sta andando

a buon fine. A questo punto, si esegue un’interrogazione sul database cer-

cando le connessioni Wi-Fi aventi l’identificatore di cella uguale a quello alla

quale si e allacciati. Viene quindi effettuato il solito procedimento andando

ad attingere dalle configurazioni di rete del sistema, costruendo la lista delle

connessioni Wi-Fi candidate e tentando di connettersi ad una loro.

Se il tentativo va a buon fine allora si va nel caso 3), ovvero con solo l’inter-

faccia wireless attiva, altrimenti si deve avvisare l’utente che a breve perdera

il segnale in quanto non vi sono altre connessioni disponibili.

4.2.4 Creazione della lista delle connessioni candidate

Per quanto riguarda la creazione della lista delle reti candidate, tornano

utili i concetti descritti in modo dettagliato nella sezione successiva, ovvero

il campo FLAG che indica se il dispositivo attuale e in grado di connettersi

o meno ad una determinata rete presente nella base di dati (o non lo sa in

4.2 Lato server 117

quanto non ha ancora provato) e il concetto di status del wpa supplicant utile

in quanto mette a disposizione informazioni su come Android valuta una rete.

I passi logici che vengono fatti per costruire la lista delle reti candidate

sono i seguenti:

1. Si ottiene una serie di tuple rappresentanti connessioni wireless dalla

base di dati. Si deve eseguire quindi una query secondo qualche crite-

rio, per esempio se si hanno a disposizione le coordinate GPS si vuole

ottenere una lista di reti con un buona potenza del segnale e che non

distino piu di dieci metri dalla posizione attuale.

2. Si ottengono le configurazioni di rete e le si convertono in un oggetto

WifiList. Vengono fatti diversi passaggi per gestire le stringhe, rileva-

re all’interno del file wpa supplicant.conf quali configurazioni hanno

un tipo di protezione e quali un altro e settare propriamente i campi

del suddetto oggetto. I risultati vengono poi inseriti in un apposito

arrayList

3. Si devono fondere gli arrayList creati nei punti precedenti per ottenere

la lista dei candidati. Questo punto e il piu complesso, si prendono due

arrayList formati da oggetti WifiList e si vuole restituire una singola

hashmap del formato <posizione, dati connessione>.

Si itera quindi sull’arrayList ottenuto interrogando la base di dati ed

andando ad analizzare il FLAG. Per ogni valore ammesso per il FLAG,

vengono utilizzati tre HashMap di supporto ”high”, ”medium”, ”low”.

Si supponga di considerare il FLAG con valore ”CAN CONNECT”, si

va quindi a scandire l’arrayList delle configurazioni di rete, analizzando

come il wpa supplicant considera ciascuna di esse. Se quest’ultimo con-

sidera la configurazione buona, allora si crea l’oggetto wifiList completo

di tutti i campi e lo si inserisce nella hashMap ”high”.

Se il wpa supplicant non considera tale rete valida per la connessione,

allora l’oggetto completo di tutte le informazione viene inserito nella

hashMap ”medium” ed infine se non si trova alcun riscontro nelle con-


figurazione, l’oggetto viene messo nella Hashmap ”low”.

Tale procedimento viene eseguito anche per gli altri valori del campo

FLAG.

4. A questo punto si hanno tre hashMap per ogni valore del FLAG,

se ne deve creare una sola da restituire come lista delle connessioni

candidate. Si inseriscono quindi prima tutte le connessoni presenti

nelle hashMap ”high” dando precedenza prima al FLAG con valore

”CAN CONNECT” seguito dal FLAG con valore ”UNKONWN” ed

infine il valore ”CAN NOT CONNECT”. Una volta analizzate le hash-

Map ”high” si ripete il procedimento rispettivamente con le hashMap

”medium” e ”low”.

A questo punto si ha un’unica hashMap<posizione, dati connessione>,

si forza il dispositivo a connettersi richiamando gli opportuni metodi in base

al tipo di protezione della rete che si sta considerando, fino a quando non

viene instaurata una connessione o si arriva alla fine della mappa.

4.2.5 Problemi emersi durante la progettazione

Precedentemente si e visto come e stata progettata la base di dati su cui

l’Oracolo attinge le informazioni. Sono stati visti i campi che formano un

oggetto rappresentante una connessione wireless e si e notato l’utilizzo di un

campo FLAG, utile e tenere traccia della capacita o meno del dispositivo di

connettersi ad una determinata rete. Tale campo puo assumere i seguenti

valori:

• CAN CONNECT: il dispositivo setta il flag a tale valore quando riesce

a connettersi ad una determinata rete.

• CAN NOT CONNECT: analogamente al caso sopra, ma in caso di

fallimento nel tentativo di connessione.

• UNKNOWN: il dispositivo ha rilevato tale rete, ma non ha ancora

provato a connettersi.

4.2 Lato server 119

Tali valori vengono utilizzati anche in altre circostanze, per esempio se

l’utente cambia le impostazioni di rete, e possibile che una rete a cui ci si

riusciva a connettere adesso non risulti piu essere accessibile o viceversa.

In tal caso bisogna eseguire una query sulla base di dati e aggiornare il flag

al valore UNKNOWN fino a quando effettivamente non si tentera la connes-

sione. Il problema principale, risulta quindi essere la gestione di eventuali

modifiche da parte dell’utente alle configurazioni di rete durante l’utilizzo del-

l’applicazione. Si e quindi pensato di procedere nel seguente modo: Android

salva le configurazioni di rete in un file situato in /data/misc/wifi di nome

wpa supplicant.conf. All’avvio dell’applicazione, viene quindi controllato

se nella cartella proprietaria dell’applicazione stessa vi e un backup di tale

file, se non c’e allora o si e al primo utilizzo oppure l’utente lo ha eliminato

manualmente, in tal caso viene eseguita una copia dell’originale in tale car-

tella. Periodicamente, durante l’utilizzo dell’applicazione viene controllato

il file originale andando alla ricerca di eventuali differenze rispetto al file di

backup. Tale controllo viene eseguito anche ad ogni avvio dell’applicazione

successivo al primo. Se vengono trovate delle differenze, significa che l’utente

ha applicato delle modifiche, che possono riguardare le configurazioni di rete

gia esistenti oppure aggiungendone o eliminandone altre. In tal caso e neces-

sario effettuare nuovamente un backup ed eseguire le query per aggiornare

opportunamente la base di dati.

Un altro problema riscontrato riguarda la gestione da parte di Android

delle configurazioni di rete presenti nel file wpa supplicant.conf, in quanto

esso salva delle entries in tale file per ogni configurazione creata dall’utente

tramite l’interfaccia di sistema, senza pero specificare in tale file l’indirizzo

MAC dell’access point a cui ci si va a connettere ma utilizzando solo l’S-

SID. Vi sono molte fonti in rete [57] che confermano che Android non ha

una gestione molto evoluta di reti che hanno lo stesso SSID. Questo e un

aspetto importante, in quanto molti utenti tendono a non cambiare il nome

alla propria rete lasciando spesso quella del costruttore del router/modem.

Anche in questi thread di discussione viene citato l’indirizzo MAC come fatto-


re discriminante, ma nella gran parte delle versioni di Android (purtroppo in

quelle recenti) non viene utilizzato, quando altri sistemi operativi pio obsoleti

come ad esempio Symbian lo considerano.

Un esempio di wpa supplicant.conf e il seguente, utilizzato per effet-

tuare alcune prove.

1 network={2 ssid=”ALMAWIFI”

3 proto=WPA RSN

4 key mgmt=WPA−EAP IEEE8021X

5 eap=PEAP

6 identity=”[email protected]”

7 phase2=”auth=MSCHAPV2”

8 priority=2000002

9 }10

11 network={12 ssid=”prova”

13 scan ssid=1

14 key mgmt=NONE

15 priority=1000000

16 }17

18 network={19 ssid=”dlink”

20 psk=”18051988”

21 proto=WPA RSN

22 key mgmt=WPA−PSK

23 priority=4000007

24 }25


28 psk=”18051988”

29 priority=1000000

30 }31 }

4.2 Lato server 121

Le prove effettuate sono state le seguenti: si e creata una configurazione

,dall’interfaccia di sistema, per una rete domestica avente SSID ”dlink” con

protezione WPA2 PERSONAL, testando la situazione descritta di seguito.

Si e provata un’altra rete domestica con un router dlink ovviamente con indi-

rizzo MAC diverso. E stata quindi creata una configurazione di rete sempre

con SSID ”dlink” ma con password diversa dalla prima. Il comportamento di

Android e il seguente: il dispositivo tenta di connettersi alla rete domestica

”dlink” che in realta e diversa da quella per cui e configurato, ovviamente

fallendo nel tentativo in quanto le password sono differenti.

Questo perche Android si basa sull’SSID e cosı facendo tratta queste due reti

nel medesimo modo. In questo scenario se si prova ad aggiungere una nuova

rete con lo stesso SSID attraverso l’apposita funzione di sistema, Android va

a modificare la configurazione esistente (cioe quella della prima rete domesti-

ca) non aggiungendone una nuova. Nel file wpa supplicant.conf, risultera

quindi esserci sempre una sola entry con nome ”dlink” e password diversa

da quella di partenza (ovviamente supponendo che il sistemati di protezione

sia lo stesso cioe WPA2 PERSONAL), perdendo cosı la configurazione della

rete domestica iniziale e la possibilita di connettersi ad essa.

Ovviamente, finche non si modifica o aggiunge una configurazione di rete

opportuna, Android usa la configurazione di rete con lo stesso SSID (se pre-

sente) sul dispositivo ad oltranza, fallendo nel suo tentativo.

Quindi si puo affermare che Android non riesce a gestire correttamente le

situazioni in cui vi siano reti diverse con lo stesso SSID, in quanto prova

per prima cosa ad utilizzare se presente, una delle configurazioni di rete

gia salvate che ha lo stesso SSID anche se puo riferirsi ad una rete diver-

sa da quella considerata. Inoltre se si crea una nuova connessione di rete

assegnando lo stesso SSID, non viene creata una nuova configurazione nel

file wpa supplicant.conf differenziandola dalla precedente, ma viene mo-

dificata quella gia presente perdendo quindi la possibilita di connettersi a

quest’ultima.


Una possibile soluzione a tale problema prevede una modifica a come An-

droid gestisce il file wpa supplicant.conf, potendo quindi inserire una lista

di indirizzi MAC che fanno riferimento a quella determinata rete.

Tale soluzione risulta comunque di difficile implementazione, in quanto una

rete puo avere numerosi access point. Infatti, l’aggiunta di un altro ac-

cess point attraverso il suo indirizzo MAC potrebbe risultare difficoltosa, in

quanto, potrebbero sorgere delle problematiche nel capire quale delle confi-

gurazioni presenti in tale file e quella da andare a modificare.

Un’altra proposta per migliorare questo aspetto di Android, puo essere l’im-

plementazione di un demone che modifichi il file wpa supplicant.conf in

base alla posizione corrente in cui il dispositivo si trova. In questo modo

si puo tenere un riferimento della locazione ed andare a modificare la entry

corretta con un determinato SSID. Anche questa soluzione non e esente da

problematiche, in quanto bisogna rivedere la gestione che Android riserva al

file wpa supplicant.conf inserendo per esempio delle coordinate GPS.

Infine un’ultima osservazione, su come Android considera le reti dal punto

di vista della priorita (voce ”prioritiy” nel file wpa supplicant.conf) quan-

do si creano delle configurazioni di rete. Il campo ”priority”, viene utilizzato

dal wpa supplicant di Android per creare una lista di priorita, basandosi sulle

esperienze precedenti. Per esempio, se una rete viene utilizzata spesso la sua

priorita e molto elevata (come la rete ”dlink” con priorita 4000007 nell’esem-

pio qui sopra). La nozione di priorita e legata ad un concetto chiamato status

del wpa supplicant [58]. Tale parametro e ottenibile dalle API di Android e

serve per avere un’informazione utile su come il wpa supplicant considera una

rete, ovvero:

• valore 0: se attualmente si e connessi a tale rete.

• valore 1: il supplicant non tentera di connettersi a tale rete.

• valore 2: il supplicant tentera di connettersi a tale rete.

Tale informazione e stata molto utile, in quanto per la creazione della lista

delle reti candidate si effettua un controllo incrociato tra le configurazioni di

4.2 Lato server 123

sistema da cui deriva appunto il valore del parametro status e le reti rilevate,

effettuando le apposite query sulla base di dati dando precedenza a quelle con

il campo FLAG settato a ”CAN CONNECT”. A tal proposito si rimanda il

lettore alla sottosezione 5.3.5.

Un’ulteriore osservazione sulla voce ”priority” va fatta, in quanto An-

droid ha uno strano modo di gestire le configurazioni di rete create dall’ap-

posita funzionalita di sistema rispetto a quelle inserite manualmente nel file

wpa supplicant.conf. Nell’esempio qui sopra la rete ”dlink” con priorita

4000007 e stata creata con la procedura guidata di Android, mentre l’al-

tra rete ”dlink” con priorita 1000000 e stata inserita manualmente nel file.

La priorita di quest’ultima inizialmente era stata posta piu alta rispetto a

quella creata da Android, successivamente e stato lo stesso sistema opera-

tivo a modificare tale configurazione dando la precedenza a quella creata

da lui stesso. A conferma di questo comportamento e stata fatta un’ulte-

riore prova, creando prima una configurazione di rete manualmente nel file

wpa supplicant.conf, dandole priorita 1000. Successivamente si crea una

configurazione col medesimo nome usando la funzionalita di sistema.

Controllando il file, si nota che Android va ad assegnare una priorita maggio-

re rispetto alla entry gia presente senza modificare quest’ultima, in tal caso

la priorita assegnata e stata di 3001.

Capitolo 5

Implementazione

In questo Capitolo vengono trattati gli aspetti piı importanti dell’imple-

mentazione del progetto di tesi, tralasciando invece le parti che richiedono

semplicemente la lettura della documentazione online per programmare in

ambiente Android.

Si inizia analizzando com’e strutturato il progetto, ovvero da quali clas-

si Java e costituito e citando i file XML piu importanti che definiscono la

struttura dell’applicazione Android. In seguito, vengono evidenziate alcu-

ne problematiche emerse durante l’implementazione ed infine trattati alcuni

dettagli implementativi, analizzando anche piccole porzioni di codice.

5.1 Panoramica del sistema

In questa sezione si analizza la struttura del progetto. Si parte con le

classi Java che costituiscono insieme ai file XML un’applicazione Android.

Si puo affermare che le classi Java principalmente definiscono ”cosa” viene

fatto. I file XML, invece, servono a fornire una struttura dal punto di vista

grafico all’interfaccia utente e a definire le risorse utilizzate dall’applicazione.

Le classi Java create per implementare l’applicazione sono:

• AddressUtils.java: classe utilizzata per gestire l’indirizzo IP del di-

spositivo quando e connesso ad una cella telefonica o per forzarne la

125

126 5. Implementazione

connessione.

• BootUpReceiver.java: classe utilizzata per avviare automaticamente

l’applicazione (se l’utente lo desidera) quando il dispositivo viene ac-

ceso. Tale classe estende BroadcastReceiver, una classe base per rice-

vere messaggi broadcast, nei quali verra inserita la richiesta di avvio

automatico.

• ConnectionHashMapHandler.java: classe utilizzata per gestire le hash-

Map nella fase di costruzione della lista delle connessioni candidate.

• ConnectionPointAnalyzer.java: estende la classe Application e defini-

sce tutta una serie di utilia, dai tag per stampare i messaggi di log, alla

definizione delle costanti, quali le distanze utilizzate per considerare un

access point o una cella vicini, ad altri flag utilizzati per effettuare dei

controlli all’interno del codice.

• ContentStringConfigurationHandler.java: classe utilizzata per gestire

la stringa rappresentante il contenuto del file /data/mis/wifi/

wpa supplicant.conf.

• DBOperationHelper.java: estende la classe SQLiteOpenHelper [59].

Tale classe implementa tutte le interrogazioni che si possono effettuare

sulla base di dati. Inoltre, sono presenti anche i metodi adibiti alla

creazione e all’eliminazione del database, delle tabelle e via dicendo.

• GpsDistanceCalculator.java: classe in cui si implementano i metodi

utili a calcolare la distanza dati due punti GPS (rappresentanti con

latitudine e longitudine in reali). Tale classe non utilizza le API di

Android per adempiere a tale funzionalita, per il semplice motivo che

queste ultime necessitano sempre di una connessione alla rete.

• LogFileWriter.java: classe che implementa le funzionalita per gestire

i file di log. In tali file vengono inserite informazioni quali le azio-

ni fatte dall’Oracolo, catalogate per datetime e per posizione quando

5.1 Panoramica del sistema 127

possibile, in modo da dare un riscontro all’utente sul funzionamento

dell’applicazione (o del servizio) qualora voglia entrare nel dettaglio.

• MainActivity.java: classe che implementa l’activity principale (ed uni-

ca) dell’applicazione. Tale classe estende Activity ed implementa l’in-

terfaccia OnClickListener. La gestione delle fasi di vita dell’activity e

quindi in parte dell’applicazione e descritta nella sottosezione 3.2.2.

I dettagli implementativi degni di nota a riguardo seguiranno nella se-

zione 5.3. Oltre a cio, in tale classe, vengono gestiti anche aspetti quali

il salvataggio e la lettura delle impostazioni dell’utente, la copia delle

configurazioni di rete di sistema e altre caratteristiche utili per pre-

parare l’applicazione al corretto funzionamento, una volta avviate le

scansioni delle interfacce.

• MyApplication.java: estende la classe Application. Fornisce funziona-

lita utili per ottenere il contesto dell’applicazione e altre informazioni

necessarie per la stesura del codice.

• OracoloBrain.java: e la classe responsabile del funzionamento dell’Oracolo.

Ha dei metodi per gestire gli scenari descritti nella sezione 4.2.3.

All’interno di tale classe vi sono anche metodi di utilita, per esempio

per forzare la connessione ad un determinato access point o ad una

determinata cella, o ancora per attivare e disattivare le varie interfacce

e cosı via.

• ScanService.java: e la classe che implementa il servizio si scansione.

Tale classe estende quindi Service ed implementa l’interfaccia Loca-

tionListener per gestire l’antenna GPS. I metodi piu importanti di

questa classe prevedono la gestione dei thread per eseguire simulta-

neamente le scansioni sulle diverse interfacce, nonche la loro gestione.

Altri metodi degni di considerazione sono quelli che permettono l’in-

terazione con la base di dati (richiamando quanto definito nella classe

DBOperationHelper).


• UmtsList.java e WifiList.java: analizzate precedentemente nella sotto-

sezione 4.2.2, servono per modellare gli oggetti rappresentati rispetti-

vamente una connessione dati e una connessione wireless.

• WifiPhoneConfiguredNetworkHandler.java: classe utilizzata per gesti-

re le configurazioni di rete presenti sul dispositivo, accedendo al file

/data/misc/wifi/wpa supplicant.conf. La funzionalita piu impor-

tante e quella che restituisce un arrayList di oggetti WifiList rappre-

sentanti le configurazioni di rete salvate nel dispositivo.

• WpaSupplicantConfHandler.java: classe che serve a gestire le eventuali

modifiche fatte dall’utente alle configurazioni di rete, mentre sta utiliz-

zando l’applicazione. Questo classe e molto utile, in quanto, permette

di tenere aggiornato il database in modo appropriato mantenendo la

consistenza dei dati. Tale aspetto e fondamentale in quanto la base di

dati e il fulcro principale per costruire la lista delle connessioni candida-

te a cui connettersi. E bene avere il campo FLAG sempre aggiornato,

in quanto, per esempio si puo correre il rischio che l’Oracolo conside-

ri una rete come affidabile per la connessione quando invece dopo le

modifiche apportate dall’utente, il dispositivo non e piu in grado di

connettersi ad essa.

• XmlToFile.java: classe utilizzata per creare i file XML in cui salvare i

risultati delle scansioni.

Per quanto riguarda i file XML, in un progetto Android ve ne sono molti,

alcuni di default che possono essere modificati dal programmatore secondo le

esigenze, altri invece si possono creare e posizionare in determinate cartelle.

Per quanto riguarda il progetto, i file XML degni di nota sono i seguenti:

• AndroidManifest.xml : e il file XML piu importante di un’applicazione

Android, in quanto in esso si definiscono i permessi che l’applicazione

deve avere e le informazioni di base quali le versioni di SDK (minima

e di riferimento) per lo sviluppo, l’orientamento del layout, il nome

5.2 Problemi emersi durante l’implementazione 129

dell’applicazione stessa ed altre caratteristiche come nel caso particolare

di questo progetto, ad esempio se essa puo essere eseguita all’avvio del

dispositivo come un servizio.

• strings.xml : serve per definire le stringhe utilizzate nelle componenti

dell’interfaccia grafica. Tale file e presente nella cartella /res/values/

• activity main.xml : file XML che definisce la struttura dell’activity prin-

cipale. Al suo interno vengono definite le componenti grafiche, ri-

chiamando le risorse quali le stringhe di cui si e parlato nel punto

precedente.

• menu.xml : file XML che serve per definire le voci del menu contestuale

dell’applicazione.

Oltre a cio a titolo informativo, nelle applicazioni Android i database sono

locati in /data/data/<package name>/databases/<nome database>.

Nel caso dell’applicazione in questione la base di dati e quindi situata in

/data/data/it.unibo.oracolo 3/databases/Oracolo.db.

5.2 Problemi emersi durante l’implementa-

zione

In questa sezione vengono discusse le problematiche piu interessanti, in

quanto in fase di progettazione non ci si aspettava che alcuni aspetti im-

plementativi presentassero determinati problemi. Tali aspetti, riguardano

principalmente la gestione dell’antenna GPS in Android e la gestione da par-

te di SQLite dei numeri reali, soprattutto per quanto riguarda le coordinate

GPS.

5.2.1 Attivazione e disattivazione del GPS

L’attivazione e la disattivazione dell’antenna GPS e stata una problema-

tica inattesa. L’applicazione base di Somenzi e Paladino da cui si e partiti a


sviluppare il progetto di tesi, obbligava l’utente a passare per le impostazioni

di sistema all’avvio dell’applicazione quando si tratta di attivare l’antenna

GPS. Il progetto attuale, interagisce molto di piu con tale interfaccia, di con-

seguenza tale approccio risulterebbe molto invasivo (in vista di un utilizzo

come servizio), in quanto l’utente sarebbe costretto a prestare sempre atten-

zione al dispositivo e disattivare l’antenna GPS se e attivata, o viceversa per

far sı che l’Oracolo funzioni al meglio ed adempia ad uno dei suoi compiti,

ovvero la salvaguardia della batteria.

Sono quindi stati implementati due metodi rispettivamente per attivare e

disattivare l’antenna GPS, senza forzare il passaggio dalle impostazioni di

sistema.

Come anticipato nel Capitolo 4, attualmente in rete vi sono delle soluzioni

che pero vanno a sfruttare un bug di sistema, in particolare del widget del

risparmio energetico.

Tale approccio e poco elegante e funziona solo per determinate versioni, in-

fatti si adatta ad Android Gingerbread, per poi non essere supportata fino

alla versione di JellyBean 4.2.2.

Inoltre tale soluzione non e testata per le versioni successive a quest’ultima.

L’algoritmo implementato non sfrutta alcun bug, funziona correttamente per

tutte le versioni da Gingerbread a JellyBean compresi i loro aggiornamenti.

Per quanto riguarda Android KitKat, tale approccio risulta non adeguato in

quanto sono state rafforzate le misure di sicurezza e di tutela della privacy.

Si e quindi implementato del codice che a runtime rileva la versione del

sistema operativo, richiamando il nuovo algoritmo sviluppato per le ver-

sioni precedenti a KitKat ed utilizzando la visualizzazione delle opportune

impostazioni di sistema per le versioni uguali o successive ad esso.

Quindi per prima cosa, si rileva la versione del sistema operativo in uso,

nel codice qui di seguito vengono poi chiamati gli opportuni metodi per di-

sattivare l’antenna GPS (la logica per quanto riguarda l’attivazione rimane

comunque la stessa):


Gestione del GPS: differenziazione delle versioni di Android.

1 if(android.os.Build.VERSION.SDK INT >= android.os.Build.VERSION CODES.

KITKAT){2 //for kitkat or higher version: I must show the settings window

3 Intent callGPSSettingIntent = new Intent(android.provider.Settings.

ACTION LOCATION SOURCE SETTINGS);

4 callGPSSettingIntent.setFlags(Intent.FLAG ACTIVITY NEW TASK);

5 MyApplication.getAppContext().startActivity(callGPSSettingIntent);

6 }7 else //for the other versions I turn off GPS directly

8 OracoloBrain.turnOffGps();

Come si puo notare dal codice qui sopra, la distinzione tra versioni di

sistema operativo e implementata nella riga 1. Successivamente, se la ver-

sione rilevata e uguale o maggiore a KitKat allora viene lanciata una intent

per visualizzare le impostazioni di sistema (riga 3), altrimenti si richiama il

metodo utilizzato dall’Oracolo per disattivare l’antenna GPS (riga 8). Per

quanto riguarda la disattivazione diretta senza passare per le impostazioni

di sistema, il codice e il seguente:

Disattivazione del GPS senza l’utilizzo delle impostazioni di sistema.

1 protected static void turnOffGps() {2 locationManager = (LocationManager) getSystemService(Context.

LOCATION SERVICE);

3 locationManager.requestLocationUpdates(LocationManager.GPS PROVIDER, 1,

1, this);

4 String provider = Settings.Secure.getString(MyApplication.getAppContext().

getContentResolver(), Settings.Secure.LOCATION PROVIDERS ALLOWED

);

5 if(provider.contains(”gps”)){ //if gps is enabled I turn off it

6 final Intent poke = new Intent();

7 poke.setClassName(”com.android.settings”, ”com.android.settings.widget.

SettingsAppWidgetProvider”);

8 poke.addCategory(Intent.CATEGORY ALTERNATIVE);

9 poke.setData(Uri.parse(”3”));

10 MyApplication.getAppContext().sendBroadcast(poke);

11 }}


Dal codice qui sopra si puo notare l’utilizzo di un location manager (riga

2) non dichiarato all’interno di tale metodo. Questo perche e globale alla

classe e serve per gestire i cambiamenti di stato del GPS stesso.

Successivamente si controlla che l’antenna GPS sia attiva (riga 5) e si procede

con la sua disattivazione.

Tale approccio prevede l’inserimento di alcune istruzione nell’Android

Manifest non presenti nel progetto di Somenzi e Paladino.

In particolare le istruzioni inserite sono le seguenti:

Modifiche al manifest per gestire correttamente l’antenna GPS

1 <uses−permission android:name=”android.permission.WRITE SETTINGS” />

2 <uses−permission android:name=”android.permission.WRITE SECURE SETTINGS”/

>

Il secondo permesso, puo essere inserito nel manifest, solo per le applica-

zioni che risiedono in /system/app. Si necessita quindi di avere dispositivi

con i permessi di root e con una custom recovery. Inoltre durante l’implemen-

tazione, avendo inserito tale permesso, l’IDE utilizzato per lo sviluppo ovvero

Eclipse, necessitava di alcune configurazioni: si deve accedere alla impostazio-

ni dell’ADT ed andare ad attivare la voce in Android/LintErrorChecking/

ProtectedPermission ed assegnarvi una severita che sia minore dell’errore,

per esempio un warning. Cosı facendo l’IDE in fase di compilazione, non

valuta i permessi sopra descritti come dannosi per il sistema, motivo per il

quale prima venivano considerati come errori.

5.2.2 Arrotondamento dei reali in SQLite

Un problema particolarmente interessante emerso durante l’implementa-

zione riguarda la gestione dei reali da parte di SQLite. Prima di entrare nel

dettaglio di tale problematica, e bene specificare la scelta implementativa di

come sono utilizzate le coordinate GPS. Partendo dalle varie proposte, de-

scritte nell’elaborato di tesi di Somenzi e Paladino [1] si e scelta la cosiddetta

”nuvola di punti”. Tale tecnica prevede la costruzione di una nuvola, costi-

tuita dalle informazioni dei rilevamenti eseguiti dall’applicazione.


Si ha quindi per ogni rete rilevata ( anche per le celle telefoniche), una serie di

tuple nella base di dati in cui si hanno delle relazioni tra potenza del segnale

e posizione. E stata utilizzata tale tecnica seppure semplice, in quanto e una

buona base di partenza per testare l’applicazione, ma anche per sviluppare

tecniche piu evolute: come per esempio la tecnica dei ”cerchi concentrici o

algoritmi di convex hull [23].

Dopo questa breve introduzione riguardo alla scelta di come utilizzare le

coordinate GPS, si passa quindi ad analizzare come queste vengono gestite

da SQLite, in particolare inizialmente durante la fase di progettazione si era

pensato di rappresentare i valori in questione con dei reali. Questo perche, i

valori ricavati dalle API di Android sono espressi in gradi decimali (per esem-

pio 40.446◦N 79.982◦W) e non in gradi-minuti-secondi (come per esempio 40◦

26’ 46” N 79◦ 58’ 56” W). I due metodi di rappresentazioni sono facilmente

ottenibili l’uno dall’altro e viceversa, cio comunque esula dall’argomentazio-

ne di questo paragrafo. Quindi inserendo le coordinate in formato decimale,

si e notato durante l’implementazione, analizzando le informazioni salvate

nella basi di dati, che SQLite tronca la parte decimale in quanto ha un unico

modo di gestire i numeri reali. Si prenda in considerazione la Tabella 5.1 di

seguito:

Android values SQLite values

Latitude 44.962677 44.9627

Longitude 11.744152 11.7441

Tabella 5.1: Confronto tra coordinate GPS rilevate da Android e quelle

salvate con SQLite.

Si e quindi passati a calcolare in modo empirico quanto tale approssi-

mazione potrebbe costare in termini di metratura, ovvero capire quanto e

preciso il ”reticolo” che si viene a creare: si necessita infatti di una buona

approssimazione, soprattutto per quanto riguarda il Wi-Fi, in quanto una

tolleranza modesta (per esempio anche dieci metri) potrebbe essere decisiva.


Si vuole quindi stimare a quanto corrispondono in distanza le variazioni

di coordinate in SQLite. Per facilitare tale calcolo sono stati considerati

principalmente due casi:

1. Si considerano due posti con la stessa latitudine ma longitudini diverse.

2. Caso contrario al precedente, si considerano quindi due posti con la

stessa longitudine ma con latitudini diverse.

Per quanto riguarda il primo punto, sono state scelte le citta di Londra e

Cardiff, aventi la stessa latitudine (in Figura 5.1).

Figura 5.1: Londra e Cardiff allineate in orizzontale per via della stessa

latitudine.

La distanza tra le due citta e di 211,92km. Vengono successivamente

considerate le longitudini rilevate correttamente e arrotondate con SQLite:

LongitudeLondon = −0, 1276931→ −0, 1277 (5.1)

LongitudeCardiff = −3, 1790899→ −3, 1791 (5.2)

Poi, viene calcolata la differenza delle longitudini trattate con SQLite:

DiffLongitude = −0, 1277− (−3, 1791) = 3, 0514 (5.3)

A questo punto viene fatto il rapporto tra la differenza di coordinate e

la differenza in chilometri tra le due citta. Variando solo la longitudine, la

prima si riduce al considerare solo DiffLongitude:

RateCoordinates/km = 211, 92/3, 0514 = 69, 45Km (5.4)


Infine si stima la differenza in metri per variazione decimale in rappre-

sentazione di SQLite:

V ariation = RateCoordinates/km/10000 = 69, 45/10000 = 69m (5.5)

Quindi per variazione decimale di SQLite (di longitudine), in questo caso,

corrisponde una distanza di 69 metri. Tale stima vale per la zona in cui sono

state considerati i due punti, ovvero nel Regno Unito. Il valore ottenuto e

poco soddisfacente, la granularita e troppo spessa per pensare di gestire in

modo efficiente le reti wireless. Il problema della locazione dei punti rispet-

to alla longitudine e stato risolto utilizzando la formula di haversine, a tal

proposito di rimanda il lettore alla sezione 5.3.3, il concetto che invece si

vuole evidenziare e che l’arrotondamento eseguito da SQLite coi reali e trop-

po oneroso in perdita di precisione. Per quanto riguarda il secondo punto,

ovvero considerare luoghi che si differenziano solo per la longitudine, sono

state scelte le citta di Seattle e San Francisco. Infatti come si puo notare

dalla Figura 5.2 esse sono allineate verticalmente.

Analogamente a quanto fatto in precedenza, si va a stimare la distanza a

cui corrisponde una variazione decimale in SQLite, ci si aspetta un risultato

peggiore rispetto a prima, in quanto ora si e piu vicini all’equatore.

In questo caso la distanza tra le due citta e di 1092,17km. Poi si consi-

derano solo le latitudini, ponendo attenzione a come SQLite gestisce l’arro-

tondamento:

LatitudeSeattle = 47, 6062095→ 47, 6062 (5.6)

LatitudeSanFrancisco = 37, 7749295→ 37, 7749 (5.7)

Si calcola quindi la differenza tra le due latitudini considerando i valori

di SQLite:

Difflatitude = 47, 6062− 37, 7749 = 9, 8313 (5.8)

Viene quindi fatto il rapporto tra Difflatitude e la differenza in chilometri

tra le due citta:

RateCoordinates/km = 1092, 17/9, 8313 = 111, 0911069Km (5.9)


Figura 5.2: Seattle e San Francisco allineate in verticale per via della stessa

longitudine.

Il valore ottenuto rappresenta il numero di chilometri a cui corrisponde

un’unita di latitudine in questo caso. Infine si stima la differenza in metri

per variazione decimale, secondo la rappresentazione con SQLite:

V ariation = RateCoordinates/km/10000 = 111, 0911069/10000 = 111m

(5.10)

Come ipotizzato in precedenza, in questo scenario, la quantia di metri

per variazione decimale della latitudine ha dato un riscontro peggiore del

caso precedente. E stato evidenziato appositamente questo esempio, per

dimostrare come l’arrotondamento eseguito da SQLite sia troppo oneroso in

termini di perdita di precisione. Di conseguenza e stata rivista la scelta di


utilizzare i reali per rappresentare le coordinate GPS, passando quindi alle

stringhe.

5.2.3 Mancanze strutturali del file wpa supplicant.conf

In precedenza, nella sottosezione 4.2.3 si e parlato di come vengono co-

struite le hashMap contenenti le reti candidate, quando ci si trova in una

circostanza in cui la connessione attuale presenta un segnale debole.

E stato visto che tali hashMap vengono costruite fondendo le informazioni

ottenute dalla base di dati con quelle presenti nel file /data/misc/wifi/

wpa supplicant.conf. Si e evidenziato come Android non inserisc all’inter-

no di tale file l’indirizzo MAC, motivo per il quale presenta alcune lacune

in circostanze in cui sul dispositivo vi sia una configurazione di rete per un

certo SSID e si trovi in presenza di connessioni con tale caratteristica.

In questo caso Android si affida a tale informazione e tenta quindi di in-

staurare una connessione fallendo se la configurazione non e riferita a quella

particolare rete. Questo problema puo essere risolto inserendo l’indirizzo

MAC nel file wpa supplicant.conf. Cio comporterebbe alcuni benefici: per

prima cosa migliorerebbero le prestazioni dell’algoritmo gestito dall’Oracolo.

In particolare, quando tale algoritmo costruisce le hashMap di reti candida-

te, oltre a controllare come il wpa supplicant considera una determinata rete,

potrebbe utilizzare anche l’indirizzo MAC, confrontando quello della rete ri-

levata con quello presente nella presunta candidata del suddetto file.

Cosı facendo l’HashMap delle reti candidate, conterrebbe sicuramente dei

profili a cui quasi sicuramente ci si puo connettere. Attualmente in mancanza

di tale informazione, l’hashMap puo contenere dei candidati a cui effettiva-

mente non ci si riesce a connettere e non e garantito che un ”buon candidato”

sia quello giusto. Questo aspetto risulta essere molto importante in termini

di prestazioni, in quanto se si avesse a disposizione l’indirizzo MAC, le mo-

difiche da applicare alle tuple presenti nella base di dati sarebbero minori

qualora l’utente cambi le impostazioni di rete. Nonostante cio, il database


gestito con SQLite rimane performante anche con la struttura attuale, questo

dovuto alle caratteristiche di SQLite stesso quali la leggerezza e la velocita.

5.3 Dettagli implementativi

In questa sezione vengono descritti i dettagli implementativi piu impor-

tanti, che non ricadono nelle problematiche vere e proprie emerse duran-

te l’implementazione, ma che sono ugualmente degni di nota in quanto, o

sono casi particolari della programmazione in ambiente Android, oppure

presentano caratteristiche interessanti ai fini dello sviluppo.

5.3.1 Utilizzo degli Intent in casi particolari

Gli Intent sono stati utilizzati in molti ambiti del progetto, in quanto sono

uno strumento fondamentale della programmazione in ambiente Android.

Vi sono pero delle le circostanze piu interessanti in cui tali strumenti vengono

utilizzati, come ad esempio la possibilita di far comunicare il servizio respon-

sabile della scansione delle interfacce con l’activity del programma, o ancora

la possibilita di far avviare l’applicazione come servizio durante l’accensione

del dispositivo, qualora l’utente lo desideri.

Utilizzo degli Intent: interazione tra ScanService e MainActivity

Come accennato in precedenza, un interessante utilizzo degli Intent in

questo progetto di tesi, riguarda la restituzione alla MainActivity dei risultati

delle scansioni effettuate dallo ScanService, in modo che queste vengano inse-

rite nell’apposito componente dell’interfaccia grafica, affinche l’utente possa

consultarle. Questo aspetto e interessante in quanto prevede la creazione di

un Intent personalizzato. Infatti nella classe ScanService, all’interno del me-

todo responsabile di gestire le scansioni delle interfacce, una volta effettuata

una di esse, viene inserito all’interno di un Intent il risultato e ne viene poi

fatto il broadcast in quanto la MainActivity rimane sempre in ascolto per la

5.3 Dettagli implementativi 139

loro ricezione, per poi poterli visualizzare. Il codice di seguito invia un Intent

dopo che una scansione per la connessione dati e stata effettuata.

Invio di un Intent con i dati relativi alle connessioni mobili rilevate.

1 String resultUMTS = scanUMTS(getApplicationContext(),true);

2 String resultScan = ””;

3 Intent mIntent = new Intent();

4 mIntent.setAction(INTENT ACTION);

5 //put informations in the intent

6 mIntent.putExtra(INTENT EXTRA UMTS, ”Waiting for wifi scansion...\nUMTS

SCAN PERFOMED”+resultScan+”\nUMTS\n”+resultUMTS);

7 //broadcast of data

8 Bundle xtra = new Bundle();

9 sendBroadcast(mIntent);

Analogo procedimento viene fatto per le scansioni Wi-Fi.

Nella MainActivity viene quindi catturato tale Intent, dopodiche il risultato

viene visualizzato all’utente. Questo viene fatto implementando un ricevitore

che estende la classe BroadcastReceiver, nel quale si definiscono le azioni che

vengono effettuate quando si cattura una Intent mandata dallo ScanService.

Definizione delle azioni per la ricezione di un Intent dallo ScanService.

1 public class MyReceiver extends BroadcastReceiver {2 @Override

3 public void onReceive(Context context, Intent intent) {4 TextView scanRes = (TextView) findViewById(R.id.scanresult);

5 if(toFile()==true)

6 scanRes.setText(intent.getStringExtra(INTENT EXTRA));

7 }8 }

Infine per instanziare correttamente tale ricevitore, sono stati creati gli

opportuni campi nella MainActivity. In particolare, nel metodo onResume

viene fatta una registerReceiver per lanciare in un thread tale ricevitore, spe-

cificando quali Intent mandati in broadcast devono essere catturati.


Dichiarazione ed instanziazione del ricevitore.

1 private IntentFilter filter = new IntentFilter(INTENT ACTION);

2 private MyReceiver receiver = new MyReceiver();

3

4 //..in the OnResume() method ..

5 registerReceiver(receiver, filter);

Utilizzo degli Intent: avvio automatico dell’applicazione

Un altro aspetto relativo all’utilizzo degli Intent, degno di nota e la pos-

sibilita di eseguire automaticamente l’applicazione agli avvii successivi del

dispositivo. Tale funzionalita viene usufruita solamente sotto esplicita scelta

dell’utente durante la fase iniziale di settaggio dell’applicazione.

I dettagli implementativi concernono principalmente nella creazione di

una classe chiamata BootUpReceiver, che estende a sua volta la classe Broa-

dcastReceiver. Prima di considerare l’implementazione di tale classe, e fon-

damentale inserire nel manifest il permesso relativo all’avvio automatico ed

inoltre il receveir discusso poco fa, con annessa definizione degli Intent.

Di seguito il codice inserito nel manifest :

Modifiche al manifest per l’avvio automatico dell’applicazione (Parte 1)

1 <uses−permission android:name=”android.permission.RECEIVE BOOT COMPLETED

”/>

Modifiche al manifest per l’avvio automatico dell’applicazione (Parte 2)

1 <receiver android:enabled=”true” android:name=”.BootUpReceiver”

2 android:permission=”android.permission.RECEIVE BOOT COMPLETED”>

3 <intent−filter>

4 <action android:name=”android.intent.action.BOOT COMPLETED” />

5 <category android:name=”android.intent.category.DEFAULT” />

6 </intent−filter>

7 </receiver>

Come si puo notare dal codice qui sopra (Parte 2), la definizione del recei-

ver all’interno del manifest prevede il nome della classe che lo implementa, il


tipo di permesso richiesto (definito nel codice Parte 1) e il tipo di Intent da

gestire, indicandone la categoria e l’azione. A questo punto, si puo analizzare

la sezione di codice interessata della classe BootUpReceiver :

Calcolo della distanza tra due punti espressi con coordinate GPS.

1 public class BootUpReceiver extends BroadcastReceiver {2 @Override

3 public void onReceive(Context context, Intent intent) {4 Intent i = new Intent(context, MainActivity.class);

5 i.addFlags(Intent.FLAG ACTIVITY NEW TASK);

6 context.startActivity(i);

7 }8 //continue with BootUpReceiver implementation...

9 }

Come si puo notare dalla riga 4, viene creato un intent specificando la

classe da utilizzare che, in questo caso, e la MainActivity. Infine nella riga

6, si specifica che una volta ricevuto l’intent si avvia l’activity specificata in

precedenza, ovvero la MainActivity.

Quindi nella classe Java si indica quale applicazione avviare in automa-

tico, mentre nel manifest si specifica la modalita di avvio, nel caso specifico,

una volta che il boot del sistema operativo e stato completato.

5.3.2 Implementazione dello ScanService

Nella sottosezione 4.1.4 si e parlato di come sono stati utilizzati i servizi in

fase di progettazione. Il servizio piu importante dell’applicazione e lo Scan-

Service, responsabile di effettuare le scansioni sulle varie interfacce, qualora

esse siano attive. In particolare, per implementare le classi che estendono la

classe Service e necessario ridefinire il metodo onStartCommand.

Quest’ultimo specifica cosa fa il servizio una volta avviato. Nel caso del pro-

getto in questione, tale metodo si occupa di avviare due thread che vengono

eseguiti ciclicamente con un timing che corrisponde agli intervalli specificati

dall’utente. Dato che il codice di tale metodo risulta essere molto complesso,


viene riportato l’algoritmo in pseudo codice 1, analizzando il thread adibito

alla scansione dell’interfaccia wireless.

Algorithm 1 OnStartCommand: gestione della scansione Wi-Fi.

1: procedure MyProcedure

2: isScanning← true

3: turnGPSOn

4: for schedule at fixed Wi Fi interval rate do

5: procedure run

6: resultUMTS← null

7: if wifiMustTurnedOff = false then

8: resultScan← scanWifi()

9: mIntent← resultScan, resultUMTS

10: sendBroadcast(mIntent)

11: if useOracolo then

12: if firstRunAllInterfaceActived then

13: OracoloBrain.allInterfacesActived()

14: else

15: toReturn← OracoloBrain.getToReturn()

16: switch toReturn do

17: case WIFI AND GPS

18: assert(OracoloBrain.wifiAndGpsActived())

19: case ONLY WIFI

20: assert(OracoloBrain.onlyWifi())

21: case UMTS AND GPS

22: assert(OracoloBrain.UmtsAndGpsActived())

23: case ONLY UMTS

24: assert(OracoloBrain.onlyUmts())

25: case NOTHING TO DO

26: assert(OracoloBrain.nothingToDo())


Come accennato in precedenza, dopo il ciclo che richiama con un timing

fisso, il thread responsabile della scansione Wi-Fi, vi e un altro ciclo che

esegue un codice molto simile, ma adibito alla scansione dell’interfaccia dei

dati mobili con l’intervallo specificato dall’utente. Analizzando lo pseudo co-

dice relativo alla scansione dell’interfaccia Wi-Fi si puo notare, come venga

innanzitutto attivata l’antenna GPS e come venga settata una variabile di

controllo utile a capire se la funzionalita di scansione e attiva. Dopodiche,

viene eseguito un thread, che ciclicamente con l’intervallo specificato dal-

l’utente per l’interfaccia wireless, esegue le scansioni. In tale thread viene

richiamato il metodo scanWifi che esegue la suddetta scansione, salva il ri-

sultato nell’apposito file XML e esegue le opportune query nella base di dati,

inserendo nuove tuple o eventualmente modificando quelle esistenti e datate.

Successivamente viene inviato l’intent coi risultati in modo che la MainActi-

vity li visualizzi all’utente. Dopodiche, viene effettuato un ulteriore controllo

per verificare se l’utente sta utilizzando l’Oracolo. In tal caso se e la prima

esecuzione del modulo dopo aver avviato la scansione, allora significa che

tutte le interfacce sono attive e viene richiamato l’apposito metodo (allInter-

facesActived), che andra in base alla circostanza a gestirle, disattivando quella

o quelle appropriate. Quindi per i successivi cicli, non verra piu chiamato

allInterfacesActived, bensı controllando il flag toReturn definito nella classe

per la gestione dell’Oracolo, si riesce a capire quale metodo di quest’ultimo

richiamare. L’implementazione dei metodi per la gestione delle interfacce ri-

sulta essere troppo onerosa termini di spazio e la si omette, si rimanda quindi

il lettore alla loro descrizione nella sottosezione 4.2.3 del precedente capitolo.

Oltre a cio per rendere possibile il corretto funzionamento dello ScanService

sono stati introdotti i seguenti permessi nel manifest dell’applicazione:

Modifiche al manifest per il corretto funzionamento dello ScanService (Pt1)

1 <uses−permission android:name=”android.permission.CHANGE WIFI STATE”/>

2 <uses−permission android:name=”android.permission.ACCESS WIFI STATE”/>

3 <uses−permission android:name=”android.permission.ACCESS FINE LOCATION”/>

4 <uses−permission android:name=”android.permission.ACCESS COARSE LOCATION”

/>


5 <uses−permission android:name=”android.permission.CHANGE NETWORK STATE”/

>

6 <uses−permission android:name=”android.permission.INTERNET”/>

7 <uses−permission android:name=”android.permission.ACCESS COARSE UPDATES”/

>

8 <uses−permission android:name=”android.permission.ACCESS NETWORK STATE”/

>

Come si puo notare, sono tutti permessi relativi alla possibilita di cambia-

re gli stati delle interfacce di rete e della localizzazione. Infine sempre nel ma-

nifest, si deve specificare quale servizio non built-in delle API, l’applicazione

implementa:

Modifiche al manifest per il corretto funzionamento dello ScanService (Pt2)

1 <service android:name=”it.unibo.oracolo0 3.ScanService”/>

5.3.3 Calcolo delle distanza tra due punti rappresen-

tati con coordinate GPS

Tale funzionalita, come accennato in precedenza nella sezione 5.1, e im-

plementata nella classe GpsDistanceCalculator.java, senza utilizzare i metodi

delle API di Android in quanto necessitano sempre di una connessione.

Si e quindi creato un algoritmo in locale che calcola correttamente la di-

stanza, valutando la latitudine. Infatti, quest’ultima e un parametro impor-

tante per stimare la distanza in metri corrisposta al variare della longitudine

Per esempio, se ci si trova al polo nord, la variazione di un’unita di longitudine

corrisponde a meno metri rispetto a quando si e locati all’equatore.

Calcolo della distanza tra due punti espressi con coordinate GPS.

1 public static double gps2m(double lat1, double lng1, double lat2, double lng2) {2 double earthRadius = 6371; //kilometers

3 double dLat = Math.toRadians(lat2−lat1);

4 double dLng = Math.toRadians(lng2−lng1);

5 double a = Math.sin(dLat/2) ∗ Math.sin(dLat/2) +

6 Math.cos(Math.toRadians(lat1)) ∗ Math.cos(Math.toRadians(lat2)) ∗


7 Math.sin(dLng/2) ∗ Math.sin(dLng/2);

8 double c = 2 ∗ Math.atan2(Math.sqrt(a), Math.sqrt(1−a));

9 double dist = (double) (earthRadius ∗ c) ∗ 1000; //∗ 1000 to get meters

10 return dist;

11 }

Il codice qui sopra effettua tale calcolo, utilizzando la cosiddetta ha-

versine formula (formula dell’emisenoverso), descritta nell’equazione 5.11 e

successive:

a = sin2(∆φ/2) + cos(φ1) ∗ cos(φ2) ∗ sin2(∆λ/2) (5.11)

c = 2 ∗ arctan 2(√a,√

(1− a)) (5.12)

d = R ∗ c (5.13)

Tale formula, serve per calcolare la distanza tra due punti in una sfera.

Nell’equazione qui sopra, φ e la latitudine, R e il raggio della terra, che come

si puo notare dal codice viene settato a 6371 Km. Da notare dal codice

che gli angoli devono essere rappresentati in radianti prima di essere usati

come argomenti per le funzioni trigonometriche. Se cio non viene fatto,

la formula di haversine perde di significato. Quindi, tale concetto viene

utilizzato per stimare la distanza tra la posizione attuale del dispositivo e

quella degli access point o delle celle (le cui coordinate sono presenti nella

base di dati). Solitamente, le distanze secondo le quali vengono considerati gli

access point e le celle con buon segnale sono rispettivamente di dieci metri e

trenta metri. Per quanto riguarda le celle telefoniche, tale distanza puo essere

aumentata tranquillamente, garantendo comunque il corretto funzionamento

dell’algoritmo.

5.3.4 Rooting dei dispositivi

Nella sezione 3.5, si e parlato degli strumenti utilizzati per rootare i di-

spositivi impiegati per lo sviluppo del progetto (un LG Nexus 5 ed un Sony

Xperia L). In questa sezione si trattano piu approfonditamente i passaggi

impiegati per tale scopo.


Rooting del dispositivo Nexus 5

Per effettuare il rooting del Nexus 5 e stato utilizzato il software Nexus

Root Toolkit. Quest’ultimo da solo non e sufficiente, prima infatti bisogna

attivare sia il debug mode sul dispositivo nonche le opzioni per gli svilup-

patori (obbligatorie per sviluppare una qualsiasi applicazione su Android).

Fatto cio, si installa il Nexus Root Toolkit e si esegue lo script bash ad esso

associato. Dopodiche sono state eseguite le seguenti operazioni:

1. Si spegne il dispositivo e lo si riavvia in modalita fast boot1.

2. Si installa una custom recovery, in questo caso e stata utilizzata la

TWRP RECOVERY [27] (versione 2.6.3.0-hammerhead). Una custom

recovery e una recovery di terze parti che va a sostituire quella di de-

fault, che appunto non permette di montare file immagine direttamente

da cavo USB. Con una custom recovery si riescono quindi a fare ope-

razione non permesse solitamente, oltre a quella appena descritta, si

possono per esempio eseguire backup, ripristinarli ed installare ROM

customizzate.

3. Si carica sul dispositivo il file di installazione di SuperSu 3.5.1 (versione

1.65).

4. Si riavvia il dispositivo sempre in modalita fastboot e si installa il file

caricato nel punto precedente.

5. Al riavvio successivo del dispositivo (normale senza modalita fastboot),

il programma SuperSU risulta essere installato e quindi si possono

utilizzare applicazioni che richiedono i permessi di root.

Come accennato in precedenza nella sezione 3.5, ogni aggiornamento del

sistema operativo, comporta la perdita sia della custom recovery che il fun-

zionamento non corretto del programma SuperSu: risulta quindi necessario

1La modalita FastBoot : permette di moddare (personalizzare) un dispositivo Android,

installando dei file immagine via cavo USB. Per fare cio e necessario accedere al bootloader

che deve quindi essere sbloccato, in quanto inizialmente inaccessibile.


ripetere la procedura appena descritta. Tale problematica e riscontrata nella

maggior parte dei dispositivi sul mercato, non sono quindi esenti i device

utilizzati per lo sviluppo.

Rooting del dispositivo Sony Xperia L

Di seguito, viene descritta la procedura eseguita per effettuare il rooting

dell’altro dispositivo utilizzato per implementare il progetto.

Per prima cosa, e bene considerare che tale procedura funziona solo con

modelli che montano le versione di firmware 15.3.A.117 o 15.3.A.0.26 e la

versione 4.2.2 JellyBean di Android. Per quanto riguarda il firmware, se non

si dispone di una delle versioni appena citate e possibile scaricarle dal sito

ufficiale del produttore ed installarle via cavo USB, dopo aver equipaggiato

il telefono con una custom recovery. Dopo aver verificato ed eventualmente

eseguito quanto detto, si deve accedere alle impostazioni di sistema e abilitare

la possibilita di installare software da sorgenti sconosciute (cioe software non

proveniente dal PlayStore). Inoltre si deve attivare la modalita di debug via

cavo USB, solitamente gia attiva se si sviluppano applicazioni su Android.

Dopodiche e stata installata l’applicazione VRoot [25] (vedere sezione 3.5)

su una macchina Windows ed eseguita seguendone le istruzioni (per quel

che e stato possibile in quanto in cinese). Alla fine della procedura guidata,

il dispositivo si riavvia automaticamente, con la possibilita di accedere ai

permessi di root. Da notare che questa procedura non installa il programma

SuperSu (come mostrato dalla Figura 5.3), al suo posto vi sono due program-

mi proprietari della casa produttrice di VRoot (in cinese) che rispettivamente

offrono le equivalenti funzionalita di SuperSu (questa volta chiamato KingU-

ser) e in secondo luogo rimpiazzano le notifiche e le funzionalita del PlayStore

ufficiale di Android. Ovviamente quest’ultima particolarita risulta poco fun-

zionale. Per quanto riguarda l’equivalente del gestore dei pacchetti, basta

disinstallarlo con l’apposita funzionalita di sistema. Mentre per la rimozione

dell’applicazione KingUser e l’installazione di SuperSu, si deve congelare la

prima ed installare la seconda usando una custom recovery, in questo caso, e


stata utilizzata la TWRP descritta in precedenza.

Figura 5.3: L’applicazione KingUser dopo aver effettuato il rooting del

dispositivo Sony Xperia L.

Gestione del file build.prop

Nei capitoli precedenti si e parlato piu volte del file build.prop, utile a

modificare il timing con il quale Android effettua le scansioni dell’interfaccia

wireless. E stato detto, che non e sufficiente che l’utente specifichi un inter-

vallo di scansione, per far sı che questa venga eseguita con quel timing dal

sistema operativo. Infatti il kernel gestisce i periodi di scansione in questo

file, attraverso la definizione del campo wifi.supplicant scan interval.

Il procedimento su come si intende modificare tale campo e stato spiega-

to in dettaglio nella sottosezione 4.1.1, di seguito viene analizzato il codice

spezzandolo in parti per renderlo piu comprensibile. Per prima cosa si ac-

cede come root (utilizzando la libreria RootTools) al dispositivo, montando


sia in lettura che in scrittura la cartella /system/ in cui e presente il file

build.prop.

Aggiornamento del build.prop file. Parte 1: montare la cartella.

1 //Requesting SuperUser Access

2 Process process = Runtime.getRuntime().exec(”su”);

3 DataOutputStream os = new DataOutputStream(process.getOutputStream());

4 os.writeBytes(”mount −o remount rw /system/\n”); /∗mount in read/write mode

the /system directory∗/5 os.writeBytes(”exit\n”);

6 os.flush();

7 try {8 process.waitFor();

9 } catch (InterruptedException e) {10 e.printStackTrace();

11 }12 }

Dopodiche viene letto il contenuto del file e viene ricercata la voce

wifi.supplicant scan interval. Se la si trova viene modificata, altrimenti

viene aggiunta in fondo assegnandovi il valore specificato dall’utente.

Tali operazioni vengono fatte tra stringhe, non viene modificato direttamente

il file originale. Dopodiche viene salvato tale contenuto in un file di backup

utilizzando, l’oggetto FileOutputStream. Infine si effettua la sostituzione del

file di backup con quello originale, prima di eseguire tale operazione viene

ucciso il processo /system/bin/wpa supplicant responsabile della scansione

delle interfacce. Il codice di seguito esegue l’operazione di sostituzione del file,

sempre utilizzando la libreria RootTools. Per prima cosa vengono appunto

definiti i comandi:

Aggiornamento del build.prop file. Parte 2: definizione dei comandi.

1 //Debug mode on for RootTools

2 RootTools.debugMode = true;

3 RootTools.log(ConnectionPointAnalyzer.LOG TAG, ”MainActivity/

updateBuildPropFile: using root tools”);

4 //adb shell commands to run


5 CommandCapture command = new CommandCapture(0, ”mount −o remount,rw /

system”, ”chmod 777 /system/build.prop”);

6 CommandCapture command1 = new CommandCapture(0, ”su”,”rm −r /system/build.

prop”);

7 CommandCapture command2 = new CommandCapture(0, ”su”,”cat /sdcard/

ConnectionPointAnalyzer/build.prop.backup > /system/build.prop”);

8 CommandCapture command3 = new CommandCapture(0, ”su”, ”chmod 777 /system/

build.prop”);

9 CommandCapture command4 = new CommandCapture(0, ”su”, ”chown root:root /

system/build.prop”);

10 CommandCapture command5 = new CommandCapture(0, ”su”, ”chmod 644 /system/

build.prop”);

Da notare come dopo aver effettuato la copia vengano settati propriamente

i permessi e i proprietari del file build.prop (riga dalla 8 alla 10).

Se tale operazione viene omessa, si rischia di avere problemi una volta riav-

viato il processo responsabile della scansione delle interfacce, nonchee negli

avvii successivi del dispositivo. Infatti lo smartphone potrebbe andare in

blocco tentanto l’acceso al file avente i permessi errati. Una volta effettuati

questi passaggi, ci si occupa di eseguire i comandi appena definiti, gestendo

le opportune eccezioni:

Aggiornamento del build.prop file. Parte 3: esecuzione dei comandi

1 //run the commands

2 try {3 // we remove build.prop file

4 RootTools.getShell(true).add(command);

5 RootTools.getShell(true).add(command1);

6

7 //copy and rename the new build.prop in /system/


9

10 //change the permission to the new build.prop file for next reads


12

13 //change owner and group of new build prop file (user = root, group = root)



15 //change permission of build.propf file (644)


17

18 } catch (TimeoutException e1) {19 RootTools.log(ConnectionPointAnalyzer.LOG TAG, ”MainActivity/

updateBuildPropFile: Timeout exception”+e1.getMessage());

20 e1.printStackTrace();

21 }22 catch (RootDeniedException e1) {23 RootTools.log(ConnectionPointAnalyzer.LOG TAG, ”MainActivity/

updateBuildPropFile: RootDeniedException ”+e1.getMessage());

24 e1.printStackTrace();

25 }

Dopodiche viene riavviato il processo /system/bin/wpa supplicant adibito

alla scansione delle interfacce. Tale processo andra ad accedere al contenuto

del file build.prop, considerando quindi l’intervallo specificato dall’utente.

A questo punto il kernel effettua le scansioni col timing desiderato.

5.3.5 Gestione del file wpa supplicant.conf

In questa sezione, vengono trattati diversi aspetti della gestione del file

wpa supplicant.conf, nel quale Android salva le configurazioni di rete inserite

dall’utente attraverso l’apposita funzionalita di sistema. In particolare ver-

ranno analizzati nell’ordine, la gestione di eventuali modifiche delle suddette

configurazioni da parte dell’utente, durante l’utilizzo dell’Oracolo e succes-

sivamente anche la gestione di come quest’ultimo preleva i campi e forza la

connessione in base al tipo di configurazione di rete.

Gestione delle modifiche alle configurazioni di rete durante l’utiliz-

zo dell’applicazione

Puo succedere che durante l’utilizzo dell’applicazione l’utente vada a mo-

dificare le configurazioni di rete presenti nel sistema. Tale cambiamento,

gestito dalla classe WpaSupplicantConfHandler, non e irrilevante, in quan-


to l’Oracolo nel costruire l’hashMap delle reti candidate a cui connettersi,

potrebbe considerarne una rilevata come correttamente configurata sul di-

spositivo quando in realta ora non lo e piu. Analogo discorso puo essere

fatto nel caso contrario, ovvero nella base di dati una rete considerata come

non accessibile dal dispositivo, potrebbe invece essere utilizzata dopo le mo-

difiche alle configurazioni. Tale controllo ovviamente deve essere effettuato

anche all’avvio dell’applicazione. Di seguito viene riportato lo pseudocodice 2

per rendere la lettura piu agevole, in quanto l’implementazione vera e propria

risulta molto onerosa sia in termini di spazio che in facilita di comprensione

al lettore.

Algorithm 2 Gestione delle modifiche al file wpa supplicant.conf.

1: procedure hadleWpaSuppConfInMemory

2: if wpaSupplicantIsInProgDirectory() = false then

3: copyOriginalWpaSuppToBackup()

4: else

5: dateOriginalSupplicant← getLastModifiedData(originalSupplicant)

6: dateBackupF ile← getLastModifiedData(supplicantBackInProgDir)

7: if dateOriginalSupplicant > dateBackupF ile then

8: contentBackupSupp← readContentBackupSupp()

9: contentOriginalSupp← readContentOriginalSupp()

10: mapBackup 〈ssid; config〉 ←obtainNetworkConfFromString(contentBackupSupp)

11: mapOriginal 〈ssid; config〉 ←obtainNetworkConfFromString(contentOriginalSupp)

12: checkDiffFromOriginalToBackup(mapOriginal,mapBackup)

13: checkDiffFromBackupToOriginal(mapOriginal,mapBackup)

14: deleteWpaBackupFromProgramFolder()

15: copyOriginalWpaSuppToBackup()

16: else nothing to do


Come premessa, si deve considerare che all’interno della cartella dell’ap-

plicazione vi e una copia del wpa supplicant.conf : cio serve per effettuare

dei controlli con la versione originale di tale file. Tale copia viene eseguita

all’avvio dell’applicazione/servizio.

Detto cio, analizzando lo pseudocodice, per prima cosa si controlla che

sia presente una copia del file wpa supplicant.conf nella cartella dell’applica-

zione, se non e presente se ne effettua una copia, altrimenti si procede con i

controlli. Per prima cosa, si va a verificare che l’ultima data di modifica del

supplicant originale sia piu recente rispetto a quello di copia. In tal caso signi-

fica che l’utente ha apportato delle modifiche. Quindi, si leggono i contenuti

dei due file, salvandoli in mappe della forma <ssid, configurazione>.

Dopodiche si va alla ricerca delle differenze dell’originale rispetto alla copia

(riga 12), cosı facendo si ricoprono i casi in cui l’utente abbia modificato una

configurazione di rete gia esistente o ne abbia aggiunta una nuova.

In questo caso, il metodo checkDiffFromOriginalToBackup va ad iterare sugli

elementi della mappa contenente le configurazioni del file originale e se trova

una ricorrenza col contenuto di quella relativa al file di backup (in termini di

stesso ssid), esegue le seguente azioni: se il contenuto della configurazione,

e diverso da quello del backup, viene eseguita una query sul database per

modificare il campo FLAG delle connessioni con quel ssid assegnandogli il

valore ”UNKNOWN”. Se invece nella mappa relativa la file originale vi e

un elemento non presente nel file di backup, allora significa che l’utente ha

aggiunto una nuova configurazione. Anche in questo si va ad aggiornare la

base di dati. Successivamente viene effettuato il controllo nel verso opposto,

ovvero dal file di backup a quello originale (col metodo checkDiffFromBackup-

ToOriginal nella riga 13), per considerare il caso in cui l’utente sia andato

ad eliminare una configurazione di rete. Analogamente ai casi precedenti,

si vanno a modificare le opportune tuple nel database, qualora uno o piu

elementi della mappa relativa al file di backup non siano present in quella

rappresentante il file originale.


I metodi per la ricerca delle differenze tra le due mappe non vengono

riportati, in quanto utilizzano funzionalita built-in di Java, per controllare se

un elemento e presente o meno in entrambe le strutture dati e lavorano sulle

stringhe per verificare se il contenuto di ciascuna presenta delle differenze.

Per quanto riguarda le query eseguite sulla base di dati, seguono il classi-

co schema consigliato dalle guide ufficiali di Google, quindi non presentano

caratteristiche degne di nota.

Gestione delle configurazioni di rete in base al loro meccanismo di

protezione ed autenticazione

In questa sezione si analizzano i dettagli implementativi di quanto discus-

so in nella sottosezione 4.2.4, per la creazione della HashMap contenente le

connessioni Wi-Fi candidate. Queste ultime vengono ordinate per gradimen-

to, in base a quanto rilevato dall’Oracolo nel database e nelle configurazioni di

sistema. Il procedimento e esattamente quello citato precedentemente nella

sottosezione, vi sono pero alcuni aspetti importanti da considerare soprattut-

to, legati alla struttura del file wpa supplicant.conf. Si parte dal presupposto

che l’arrayList di oggetti WifiList, ottenuto interrogando la base di dati sia

gia disponibile. In tale struttura, si hanno quindi le tuple ottenute in base

a quanto rilevato dal dispositivo e che hanno una buona potenza del segnale

considerando, la direzione dello spostamento dell’utente.

A questo punto si deve costruire un altro arrayList, contenente le configu-

razioni di rete presenti sul dispositivo, cio viene fatto dal seguente codice,

utilizzando il metodo getConfiguredNetworks messo a disposizione dalle API:

Ottenimento delle configurazioni delle reti wireless presenti nel dispositivo

1 WifiManager Wifi = (WifiManager) MyApplication.getAppContext().getSystemService(

Context.WIFI SERVICE);

2 List<WifiConfiguration>listConfiguredWifiNetwork = Wifi.getConfiguredNetworks();

Il metodo getConfiguredNetworks presenta pero un problema: non forni-

sce le informazioni necessarie all’autenticazione, quali username e password.

Inoltre la lista che viene restituita non e ancora del formato corretto (cioe


un arrayList di oggetti WifiList), per poter essere confrontata con i risulta-

ti ottenuti in precedenza interrogando il database. Di conseguenza, e stato

implementato un metodo chiamato convertListConfiguredNetworkInArrayLi-

stWifiList che effettua tale conversione, prendendo in ingresso la lista delle

configurazioni di rete ottenuta dal codice qui sopra. Di seguito verranno

analizzati i passaggi salienti di suddetto metodo di conversione:

Costruzione di un arrayList di oggetti WifiList (parte 1)

1 ArrayList<wifiList> result;

2 if(wifiConfiguredList.size()>0){3 result = new ArrayList<wifiList>();

4 String wpaSuppConfContent = WpaSupplicantConfHandler.

readContentOriginalWpaSupp();

5 /∗Build a map <String, String> where the key is ssid and the second string is the

configuration content of the wpa supplicant.conf for that ssid∗/6 Map <String,String> mapWpaSupplicantConf = new HashMap<String, String

>();

7 mapWpaSupplicantConf = WpaSupplicantConfHandler.

obtainNetworkConfFromString(wpaSuppConfContent);

Tale codice legge il contenuto del file wpa supplicant.conf originale e ne

costruisce una mappa avente formato <ssid, configurazione>.

Quest’ultima, viene utilizzata nella ”parte 3” descritta piu avanti, per otte-

nere le informazioni formattate correttamente, in modo tale da instaurare

una connessione. Successivamente, per ogni elemento della lista contenente

le configurazioni, creata in precedenza si dichiara ed instanzia un oggetto di

tipo WifiList:


1 for( WifiConfiguration i : wifiConfiguredList ) {2

3 wifiList tmp = new wifiList();

4 tmp.setSsid(i.SSID);

5 tmp.setFrequency(ConnectionPointAnalyzer.INVALID\ STRING);

6 tmp.setLevel(ConnectionPointAnalyzer.INVALID\ STRING);

7 tmp.setId(String.valueOf(i.networkId));


8 tmp.setsLevel(ConnectionPointAnalyzer.INVALID\ STRING);

9 tmp.setMacAddress(i.BSSID);

10 tmp.setRssi(ConnectionPointAnalyzer.INVALID\ STRING);

11 //set the configuration flag value

12 tmp.setFlag(DBOperationHelper.IS\ CONFIGURATION);

13 tmp.setNetworkId(i.networkId);

14 // get the correct capabilities

15 String correctCapabilites = getCapabilitiesFromBitset(i.

allowedKeyManagement, i.allowedAuthAlgorithms);

16 tmp.setCapabilities(correctCapabilites);

17 tmp.setSupplicantStatus(i.status);

18 DateFormat df = new SimpleDateFormat(”dd/MM/yy HH:mm:ss”);

19 Calendar calobj = Calendar.getInstance();

20 String date = df.format(calobj.getTime());

21 tmp.setDate(date);

22 tmp.setCidUmts(ConnectionPointAnalyzer.INVALID STRING);

23 tmp.setLatitudeWifi(ConnectionPointAnalyzer.INVALID STRING);

24 tmp.setLongitudeWifi(ConnectionPointAnalyzer.INVALID STRING);

Da notare nel codice citato qui sopra l’utilizzo particolare, del campo

FLAG, per distinguere un oggetto WiFiList creato da una configurazione

rispetto ad uno ottenuto dalle interrogazioni sul database. In questo caso in-

fatti tale campo assume il valore IS CONFIGURATION invece dei classici valori

utilizzati per esprimere la capacita del dispositivo di connettersi o meno a tale

rete. Inoltre un altro valore speciale e INVALID STRING, utilizzato nei campi

relativi all’identificativo della cella telefoniche e per le coordinate GPS.

A questo punto sorge un problema: la lista listConfiguredWifiNetwork ot-

tenuta richiamando il metodo getConfiguredNetworks [60], non ottiene dal

supplicant le credenziali per l’accesso alle varie reti che rappresenta, vi e la

necessita quindi di effettuare qualche passaggio per accedere direttamente al

file wpa supplicant.conf e ricavare tali informazioni. Prima di analizzare il

codice per ricavare le credenziali, e bene ricordare come puo essere struttu-

rato un elemento del file wpa supplicant.conf, in quanto vi sono differenze

rilevanti in base alla tipologia di accesso e di autenticazione utilizzata.

A riguardo si puo fare riferimento al seguente esempio:


1 network={2 ssid=”ALMAWIFI”

3 proto=WPA RSN

4 key mgmt=WPA−EAP IEEE8021X

5 eap=PEAP

6 identity=”[email protected]”

7 phase2=”auth=MSCHAPV2”

8 priority=2000002

9 }10

11 network={12 ssid=”prova”

13 scan ssid=1

14 key mgmt=NONE

15 priority=1000000

16 }17


20 psk=”18051988”

21 proto=WPA RSN

22 key mgmt=WPA−PSK

23 priority=4000003

24 }

Si puo infatti notare come una configurazione di rete che prevede due fasi

di autenticazione (per esempio ”ALMAWIFI”), abbia una struttura diversa

rispetto ad una rete come ”prova”, che non prevede alcuna autenticazione o

”dlink”, che ha una classica cifratura WPA-2. Quindi rispetto a quanto si ha

a disposizione ora, i campi dell’oggetto WifiList ancora da ricavare e che so-

no utili per instaurare una connessione sono: ”EAP”, ”identity”, ”phase2” e

”password”. Il codice qui di seguito ha il compito di ricavare le informazioni

appena citate:



1 String configurationString = mapWpaSupplicantConf.get(correctSSID);

2 if(configurationString!=null){3 if(!configurationString.contains(”key mgmt=NONE”)){// WPA CASE

4 String pwd = ContentStringConfigurationHandler.getPwdFromConfString(

configurationString);

5 tmp.setPassword(pwd);

6 }else{//NO AUTH REQUIRED OR WEP AUTHENTICATION

7 if(configurationString.contains(”wep key”)){ // 3) WEP CASE

8 tmp.setCapabilities(”WEP”);

9 String pwd = ContentStringConfigurationHandler.

getPwdFromConfStringForWep(configurationString);

10 tmp.setPassword(pwd);

11 }12 else

13 tmp.setPassword(null); //no auth is required pwd = null

14 }15 //2−PHASE AUTHENTICATION CASE

16 String phase2 = ContentStringConfigurationHandler.

getPhase2FromConfString(configurationString);

17 tmp.setPhase2(phase2);

18

19 String identity = ContentStringConfigurationHandler.

getIdentityFromConfString(configurationString);

20 tmp.setIdentity(identity);

21

22 String EAP = ContentStringConfigurationHandler.

getEAPFromConfString(configurationString);

23 tmp.setEAP(EAP);

24 }25 //add the new object into the arraylist to return

26 result.add(tmp);

In particolare, quest’ultima porzione di codice utilizza i metodi imple-

mentanti nella classe ContentStringConfigurationHandler che lavora princi-

palmente sulle stringhe e di cui si omettono i dettagli implementativi.

Al lettore e sufficiente sapere, che gestendo per casi il tipo di autenticazione


rilevato durante l’analisi del file wpa supplicant.conf ed utilizzando il codi-

ce appena citato, si ottiene un oggetto WifiList completo anche dei campi

necessari per effettuare il login ad una rete.

A questo sono stati ottenuti due arrayList: uno con i risultati delle query

sul database ed uno coi risultati relativi alle configurazioni di sistema.

Bisogna quindi creare l’HashMap finale, con le connessioni candidate par-

tendo dalle due strutture dati appena citate. Il metodo che adempie a tale

compito si chiama mergeDbResultAndConfiguration ed e implementato nella

classe OracoloBrain, prende in ingresso i due arrayList e restituisce una Hash-

Map secondo quanto descritto nella sottosezione 4.2.4. Si ricorda al lettore,

che per valore ammissibile assunto dal campo FLAG dell’oggetto WifiList per

le connessioni provenienti dal database, ovvero CAN CONNECT, UNKON-

WN e CAN NOT CONNECT, vengono utilizzate tre HashMap temporanee

relative allo stato del supplicant (per un totale di nove mappe di appoggio).

Di seguito, il codice relativo alla popolazione della HashMap parziale con

flag avente valore ”CAN CONNECT” e status del supplicant favorevole alla

connessione:

Creazione della HashMap con le connessioni candidate

1 for (wifiList i : localWifiFromDatabase){ //for every element in the arraylist of db result

2 if(i.getFlag() == DBOperationHelper.CAN CONNECT){3 for (wifiList j : localConfiguredNet){4 if(i.getSsid().compareTo(ContentStringConfigurationHandler.

getCorrectSSID(j.getSsid()))==0

5 && (j.getSupplicantStatus()==WifiConfiguration.Status.

ENABLED)){6 i.setPassword(j.getPassword());

7 i.setPhase2(j.getPhase2());

8 i.setIdentity(j.getIdentity());

9 i.setEAP(j.getEAP());

10

11 //append to hashmap

12 HighCanConnectFlag.put(HighCanConnectFlag.size()+1, i);

13 }


Tale approccio, viene fatto anche per gli altri status del supplicant per

questo flag ed inoltre per tutti i rimanenti casi non analizzati. La struttura

del codice rimane la stessa e quindi viene omessa.

Ora che e stata costruita l’HashMap dei candidati, l’Oracolo tenta di in-

staurare una connessione partendo dalla piu promettente (cioe la prima). Il

metodo adibito a tale compito si chiama forceWifiConnection e prende in

ingresso tale mappa. Viene quindi fatto un ciclo, che scandisce suddetta

struttura dati e in base al tipo di autenticazione richiesto dall’elemento con-

siderato, esegue un particolare ramo del codice. Verranno analizzati tali rami

separatamente, per rendere la lettura piu facile. Si inizia col considerare il

caso in cui non sia richiesta alcuna autenticazione:

Forzare una connessione priva di autenticazione

1 //no authentication required

2 if((wifiObj.getPassword()==null) && (wifiObj.getPhase2()==null) && (wifiObj.

getIdentity()==null) && (wifiObj.getEAP()==null)){3 if(!isWIfiConnected()) {4 String networkSSID = wifiObj.getSsid();

5 WifiConfiguration conf = new WifiConfiguration();

6 conf.SSID = ”\”” + networkSSID + ”\””; conf.allowedKeyManagement.set(

WifiConfiguration.KeyMgmt.NONE);

7 WifiManager wifiManager = (WifiManager)MyApplication.getAppContext().

getSystemService(Context.WIFI SERVICE);

8 wifiManager.addNetwork(conf);

9 List<WifiConfiguration> list = wifiManager.getConfiguredNetworks();

10 for( WifiConfiguration i : list ) {11 if(i.SSID != null && i.SSID.equals(”\”” + networkSSID + ”\””)) {12 wifiManager.enableNetwork(i.networkId, true);/∗ true = disable

other configured networks ∗/13 wifiManager.reconnect();

14 }15 }16 }17 else wifiIsConnected = true; //set properly static field of class


Come si puo notare, per capire che il profilo considerato, non prevede al-

cun tipo di autenticazione vengono controllati i campi password, phase2,

identity ed EAP, in quanto e stato visto in precedenza dall’esempio del con-

tenuto di un supplicant, che in caso di autenticazione almeno uno di essi

ha un valore assegnato. Inoltre si utilizza un campo isWIfiConnected, per

controllare che non sia ancora stata instaurata una connessione prima di for-

zarne una nuova. Il trucco in questo codice, sta nel creare una configurazione

temporanea con i dati dell’oggetto considerato. Dopodiche si ottiene la lista

delle configurazioni di rete, dove sara presente anche quella appena creata,

si ricerca quindi quest’ultima e si forza il wifiManager a connettersi ad essa.

Invece, per quanto riguarda la protezione WEP , il codice per instaurare

una connessione con tale caratteristica e il seguente:

Forzare una connessione con protezione WEP

1 if((wifiObj.getPassword()!=null) && (wifiObj.getPhase2()==null) && (wifiObj.

getIdentity()==null) && (wifiObj.getEAP()==null)){2

3 if(wifiObj.getCapabilities().contains(”[WEP]”)){//is a Wep auth

4 if(!isWIfiConnected()) {5 String networkSSID = wifiObj.getSsid();

6 String networkPass = wifiObj.getPassword();

7

8 WifiConfiguration conf = new WifiConfiguration();

9 conf.SSID = ”\”” + networkSSID + ”\””;

10 conf.wepKeys[0] = ”\”” + networkPass + ”\””;

11 conf.wepTxKeyIndex = 0;

12 conf.allowedKeyManagement.set(WifiConfiguration.KeyMgmt.NONE);

conf.allowedGroupCiphers.set(WifiConfiguration.GroupCipher.

WEP40);

13 WifiManager wifiManager = (WifiManager)MyApplication.

getAppContext().getSystemService(Context.WIFI SERVICE);

14 wifiManager.addNetwork(conf);

Da notare, che e stata tralasciata la parte in cui si ricerca tra le configura-

zioni di rete quella appena creata con i dati letti dalla mappa, in quanto il

procedimento e il medesimo di quanto visto prima.


Le differenze rispetto al caso precedente, riguardano l’ottenimento delle cre-

denziali di autenticazione, non previste in caso di rete aperta.

Per quanto riguarda la protezione della famiglia WPA, la logica e diversa

dai casi precedenti, in quanto viene comunque creata una configurazione di

rete, ma al posto di effettuare la solita ricerca tra tutte le configurazioni

presenti, si forza direttamente la connessione a quest’ultimo profilo creato.

Tale modo di procedere, purtroppo non funziona nel caso della cifratura

WEP.

Forzare una connessione con protezione della famiglia WPA

1 //is a WPA2 (Personal or Enterprise auth)

2 if(wifiObj.getCapabilities().contains(”WPA”)){3 if(!isWIfiConnected()) {4 //create a network configuration

5 WifiConfiguration wifiConfig = new WifiConfiguration();

6 wifiConfig.SSID = String.format(”\”%s\””, wifiObj.getSsid());//set the ssid

7 //set the password

8 wifiConfig.preSharedKey = String.format(”\”%s\””, wifiObj.getPassword());

9 WifiManager wifiManager = (WifiManager)MyApplication.getAppContext().

getSystemService(Context.WIFI SERVICE);

10 //remember the id

11 int netId = wifiManager.addNetwork(wifiConfig);

12 wifiManager.disconnect();

13 wifiManager.enableNetwork(netId, true);

14 wifiManager.reconnect();

Oltre a non dover effettuare un ciclo sulle configurazioni di rete alla ricerca

di quella appena creata, un dettaglio importante da considerare e l’utilizzo

di un identificato (riga 11), che viene utilizzato per instaurare direttamente

la connessione (riga 13 e 14).

Infine per quanto riguarda i profili di connessione con un’autenticazione

a due fasi, la logica e la medesima dell’ultimo caso analizzato.

L’unica differenza e che vengono settati anche i campi interessati quali phase2,

identity ed EAP.

Capitolo 6

L’applicazione

In questo capitolo vengono presentati i risultati del lavoro di progettazione

ed implementazione dell’applicazione, in particolar modo come quest’ultima

viene percepita dall’utente. L’applicazione si presenta all’utente col nome

di ConnectionPointAnalyzer, in quanto gli si richiede di impostare gli inter-

valli relativi all’interfaccia wireless e quella dei dati mobili per effettuare le

corrispettive scansioni, mentre tutto quello che riguarda l’Oracolo rimane ad

esso invisibile. Il risultato dal punto di vista grafico, e l’elenco dei risultati

ottenuti, il numero di scansioni effettuate ed eventuali errori.

Essendo la prima versione, si e pensato di sviluppare in ambiente Android

per diversi motivi: per prima cosa e bene considerare che questo sistema

operativo e il piu diffuso sul mercato (Figura 6.1) e offre molta liberta nello

sviluppare le applicazioni. In secondo luogo, e stato preferito ad IoS in quanto

richiede anche meno costi da sostenere per diventare sviluppatori, inoltre per

lo scenario di utilizzo dell’applicazione il solo simulatore per IoS non sarebbe

bastato, in quanto e necessario avere a disposizione anche i dati relativi al

GPS oltre che a quelli mobili dell’operatore. L’applicazione e quindi compa-

tibile con tutte le versioni di Android [6] dalla Gingerbread (2.3) in poi, anche

se per quanto riguarda il rilascio di Lollipop (5.0), sono stati effettuati dei

test per sistemare le caratteristiche piu importanti ma alcuni aspetti riman-

gono ancora da migliorare, questo e dovuto anche al fatto che tale versione e

163

164 6. L’applicazione

stata rilasciata a progetto ultimato ed e risultata spesso instabile in diversi

aspetti.

Figura 6.1: Diffusione di Android in Europa, America ed Italia.

Di per se l’applicazione non consiste nell’offrire solo tale funzionalita,

infatti al suo interno e implementato anche l’algoritmo per gestire l’Oracolo,

che garantisce la continuita di connessione gestendo il processo di handover.

Ovviamente viene data possbilita all’utente di impostare l’applicazione con

diverse configurazioni:

1. Solo scansione: funzionalita base che permette di effettuare le scansioni

delle interfacce e salvare i risultati in file XML locali. E quindi possibile

impostare gli intervalli di scansione e fermare in qualsiasi momento

quest’ultima e farla ripartire.

2. Scansione e popolamento del database: oltre ad effettuare le scansioni,

questa funzionalita permette di popolare il database in base alle reti

rilevate o modificare le tuple gia presenti qualora vi siano state delle

modifiche. Si offre questa modalita in quanto l’utente potrebbe non

voler utilizzare l’Oracolo, ma contribuire a creare la base di dati per

un miglior funzionamento di quest’ultimo, in quanto come detto in

precedenza uno degli obbiettivi e anche quello di costruire una fonte di

informazioni il piu completa possibile, magari rendendola disponibile

agli utilizzatori in base alle zone di interesse.

165

3. Scansione, popolamento database e utilizzo dell’Oracolo: per sfruttare

l’Oracolo si deve innanzitutto attivare anche la modalita che prevede

l’utilizzo della basi dati, in quanto tale modulo puo apportare delle

modifiche a quest’ultima, per esempio quando ci si riesce a connettere

ad una rete gia tentata in passato senza successo. Questa modalita

accede a diverse funzionalita di sistema, che prevedono l’utilizzo dei

permessi di root (un esempio in Figura 6.3, con relativo toast di avviso).

Una volta attivato l’utilizzo della base di dati, e possibile spiccare la

checkbox per usufruire dell’Oracolo, che andra quindi ad interagire col

database, decidendo la soluzione migliore in base alla circostanza in cui

ci si trova.

Figura 6.2: Interfaccia dell’applicazione al primo avvio.

Ora che sono state descritte le funzionalita offerte all’utente, si descrivono

altri aspetti dell’applicazione. Quest’ultima al primo avvio si presenta come

in Figura 6.2, dove un messaggio fornisce informazioni utili all’utente sull’u-

tilizzo del software come un servizio, che si avvia in automatico all’accensione


del dispositivo. Tale messaggio viene visualizzato solamente durante la prima

esecuzione, in modo che per le volte successive, l’interfaccia rimanga il piu

semplice e chiara possibile. Da notare sempre in Figura 6.2, le checkboxes

per selezionare le impostazioni sull’avvio automatico, le caselle di testo per

inserire gli intervalli di scansione ed infine i pulsanti per la gestione di queste

ultime nonche della base di dati.

Gli intervalli vanno specificati in millisecondi, se i valori inseriti non sono

validi o sono minori di un secondo l’applicazione, li setta rispettivamente a

tre secondi e ad un secondo. Una volta impostati gli intervalli di scansione,

e possibile avviare e fermare quest’ultima col medesimo pulsante. Inoltre

quando la scansione e attiva, e possibile utilizzare la base di dati. Se l’utente

sta utilizzando la base di dati puo scegliere attraverso l’apposita checkbox di

utilizzare l’Oracolo come mostrato in Figura 6.4.

Figura 6.3: Informazioni visualizzate dall’utente durante il funzionamento

dell’applicazione (compresi eventuali errori) e toast coi permessi di root.

167

Figura 6.4: Schermata dell’applicazione con scansioni ed utilizzo della base

di dati attivi e la possibilita di utilizzare l’Oracolo.

Se l’applicazione e gia stata avviata in precedenza e il dispositivo non

e ancora stato riavviato o spento, essa rimane in esecuzione in background

(Figura 6.5/b) fino al riavvio successivo, se l’utente ha deciso di non farla

partire automaticamente. In tale circostanza se l’utente riapre l’applicazione

ritrova la solita interfaccia con gli intervalli gia impostati, i risultati delle

scansioni attuali e la possibilita di accedere a tutte l funzionalita (Figura

6.5/a). Se l’utente decide di far partire l’applicazione in automatico per

gli avvii successivi del dispositivo, allora il servizio parte automaticamente,

senza visualizzare l’interfaccia in primo piano. In tal caso, quando l’utente

apre l’applicazione il risultato e sempre quello in Figura 6.5/a.

Da notare che in questa circostanza l’utilizzo della base di dati e dell’Oracolo

non sono attivi, deve provvedere manualmente a cio l’utente. Si e pensato

di procedere in tale modo, in quanto, il consumo energetico e l’invasivita

dell’Oracolo sulla gestione delle interfacce, possono essere importanti e quindi


e bene che sia l’utente stesso ad abilitarli manualmente.

Figura 6.5: Schermata dell’applicazione una volta richiamata dopo il primo

avvio (a). Applicazione che risulta come servizio in background (b).

L’applicazione richiede i permessi di root in diversi ambiti, per esem-

pio per accedere al file /system/build.prop contenente l’intervallo di scansio-

ne dell’interfaccia wireless, o ancora per accedere al file /data/misc/wifi/w-

pa supplicant.conf contenente le configurazioni delle reti wireless e in altre

circostanze descritte precedentemente nei Capitoli 4 e 5. Di conseguenza, il

dispositivo deve essere rootato e deve aver installata l’applicazione SuperSu

[26] per consentire i permessi di root qualora vi sia la necessita. Solitamen-

te, tali permessi vengono richiesti all’utente durante la prima esecuzione del

software (Figura 6.6/b), poi una volta impostata propriamente l’applicazione

SuperSu (Figura 6.6/a) in modo che dia piena liberta a ConnectionPointA-

nalyzer, non e necessario fare altro. In questo modo, l’applicazione viene

utilizzata come servizio negli avvii successivi, senza alcun problema qualora

sia impostata ad avviarsi automaticamente.

169

Figura 6.6: Schermata dell’applicazione SuperSu, con la lista delle ap-

plicazioni che hanno richiesto i permessi di root (a). L’applicazione

ConnectionPointAnalyzer richiede i permessi di root (b).

La Figura 6.6/a evidenzia che i permessi di root vengono dati anche ad

adb-shell. Tali permessi sono sempre collegati all’utilizzo di ConnectionPoin-

tAnalyzer e dell’Oracolo, in quanto, come visto nei capitoli precedenti, ven-

gono eseguiti dei comandi shell per gestire i file di sistema a cui solitamente

l’accesso non e consentito.

Per agevolare l’utente nell’utilizzo, e stato implementato un semplice

menu contestuale da cui poter usufruire di diverse funzionalita, quali la pos-

sibilita di consultare un help, poter accedere al file di log ed infine uscire

dall’applicazione disattivando tutte le interfacce. La funzionalita di help (Fi-

gura 6.7/b), spiega con un elenco numerato, la sequenza corretta di azioni per

utilizzare l’applicazione. Questo perche alcune funzionalita sono accessibili

dopo l’attivazione di altre. Per esempio, l’accesso all’Oracolo, puo avvenire


solo dopo aver attivato l’interazione con la base di dati.

Figura 6.7: Menu contestuale (a) da cui poter visualizzare l’help, il file di log

e poter uscire dall’applicazione. Finestra dell’help (b). Finestra evocata da

una intent per aprire il file di log (c). File di log (d). Dialog per uscire dal

programma (e).

171

Come accennato in precedenza e possibile visualizzare un file di log (Fi-

gura 6.7/d), per capire le azioni svolte dall’applicazione. Il file di log infatti

contiene delle righe in formato <datetime - azione>, relative a cosa l’ap-

plicazione fa in un determinato momento, in particolar modo alle azioni

dell’Oracolo, fulcro centrale del funzionamento del sistema. Nel file di log

infatti sono per esempio molto frequenti, righe contenenti lo spegnimento e

l’accensione delle interfacce da parte dell’Oracolo e tentativi di connessione

ad una determinata rete sempre da parte del medesimo.

La funzionalita di accesso al file di log, e stata implementata, in modo che

sia l’utente a scegliere con quale programma tra quelli presenti sul dispositi-

vo aprire tale file. Infine, sempre attraverso il menu contestuale, e possibile

uscire dall’applicazione: tale funzionalita se scelta, prevede la visualizzazio-

ne di una finestra di dialog (Figura 6.7/e), con la quale si chiede conferma

all’utente avvisandolo che tutte le interfacce verranno disattivate.

Se quest’ultimo acconsente, l’applicazione provvede con la suddetta disatti-

vazione e si chiude, terminando ovviamente anche il servizio in background

in quanto e bindato all’applicazione stessa.

Capitolo 7

Valutazione e prove

sperimentali

In questo capitolo vengono descritti alcune prove sperimentali valutan-

done i risultati. Si inizia con l’analisi di qualche scenario precedentemente

analizzato nella sezione 2.1. Successivamente vengono considerate due pro-

ve sperimentali particolari: la prima e relativa alla valutazione della bonta

dell’algoritmo di predizione gestito dall’Oracolo (sezione 7.2), mentre la se-

conda serve a motivare l’utilizzo dell’applicazione in combinazione con ABPS

(sezione 7.3).

Prima di procedere con la descrizione vera e propria di quanto detto,

si premette che le caratteristiche descritte come ”criteri di valutazione” nel

lavoro di tesi di Somenzi e Paladino persistono, in quanto, anche se sono state

apportate delle modifiche a tale progetto, prima che venisse utilizzato come

base per questa implementazione, sono state eseguite le opportune prove.

Di conseguenza, le caratteristiche discusse nel documento sovra citato, quali

la portabilita e l’usabilita, nonche un corretto funzionamento della rilevazione

delle reti durante gli spostamenti, sono rimaste tali.

173

174 7. Valutazione e prove sperimentali

7.1 Valutazione del comportamento in scena-

ri caratteristici

Si procede quindi con l’analizzare qualche scenario, per dare conferma del

corretto funzionamento dell’applicazione. In ordine le condizioni trattate in

questa sezione sono:

1. Caso in cui il dispositivo si sta spostando in una zona in cui ha previsto

che puo utilizzare solo il Wi-Fi, in quanto vi e una rete a cui crede di

potersi connettere (ONLY WIFI).

2. Caso in cui l’HashMap delle reti candidate costruita dall’Oracolo sia

vuota e successivo tentativo (con successo) di connettersi ad una cella

telefonica, prima che il segnale wireless venga perso (UMTS AND GPS

CASE).

3. Caso in cui il dispositivo rileva che sta per perdere il segnale dalla rete

wireless a cui e connesso e l’unica rete candidata in zona e quella appena

citata. In tal caso viene accesa l’interfaccia dei dati mobili, connettendo

il device alla cella identificata dall’interrogazione sul database (ONLY

UMTS).

4. Analisi di come le diverse caratteristiche dei dispositivi influenzino il

comportamento dell’Oracolo. Viene eseguita la stessa prova del punto

3) utilizzando il dispositivo Nexus 5 al posto del Sony Xperia L.

Si parte quindi con analizzare il primo scenario (punto 1)). Come e stato

descritto precedentemente, ovvero partendo dalla situazione in cui vi sono

tutte le interfacce attive, l’Oracolo rileva che puo disattivare tutte le inter-

facce tranne quella wireless, in quanto e a conoscenza che in tale zona vi una

rete Wi-Fi a cui il dispositivo e in grado di connettersi.

La Figura 7.1/a, mostra il risultato del logCat in fase di debug in tale cir-

costanza, come si puo notare vi e una rete candidata di nome dlink nella

7.1 Valutazione del comportamento in scenari caratteristici 175

HashMap. Il dispositivo, quindi, vi tenta la connessione che avviene con suc-

cesso. A tal punto vengono disattivate sia l’interfaccia dei dati mobili che

l’antenna GPS. Infatti in Figura 7.1/b, viene mostrato all’utente un toast

che lo avvisa dell’attivazione della modalita ONLY WIFI. Da notare sempre

in tale figura, che nella taskbar non vi e l’icona dell’antenna GPS in quanto e

stata disattivata, invece vi e la presenza dell’icona relativa alla disattivazione

del traffico dati (cerchiata in rosso).

Figura 7.1: Passaggio alla modalta ONLY WIFI dopo aver forzato una

connessione wireless con successo.

Il secondo scenario citato (punto 2), e relativo al caso in cui l’HashMap

delle reti Wi-Fi candidate sia vuota (come mostrato in Figura 7.2/a).


Dato che ci si trova in una situazione in cui le interfacce attive sono quella

wireless e quella GPS, si attiva anche quella relativa ai dati mobili.

A tal punto si provvede quindi a forzare la connessione ad una cella telefonica,

in quanto l’interrogazione sul database, ha dato risultanti confortanti sulla

presenza di quest’ultima nella zona in cui si trova. Una volta allacciata

la cella, viene disattivata l’interfaccia wireless. Nella Figura 7.2/b), viene

evidenziato all’utente che l’Oracolo e passato in modalita UMTS AND GPS.

Da notare, inoltre, nella taskbar, la presenza delle icone relative al segnale

GPS e alla connessione dati (in questo caso 3G) e la mancanza del segnale

wireless in quanto l’interfaccia e stata precedentemente spenta.

La terza situazione analizzata (punto 3), prevede il passaggio da una rete

wireless a cui si e connessi ad una cella telefonica. Attualmente l’Oracolo e

in modalita ONLY WIFI, ha quindi solo l’interfaccia wireless attivata.

Il dispositivo rileva che con lo spostamento dell’utente, la potenza del segnale

sta calando e prevede che la connessione verra presto persa (come mostrato

dal logCat in Figura 7.3/a). Viene quindi attivata in anticipo l’interfaccia

per la connessione dati mobili e forzata la connessione alla migliore cella

candidata (sempre in Figura 7.3/a). Al solito viene notificato all’utente il

cambio di modalita con un toast, mostrato in Figura 7.3/b, nella quale si puo

notare come si abbia a disposizione una connessione HSDPA con potenza del

segnale molto buona. Inoltre tra le icone presenti nella taskbar, non sono

presenti quella relativa alla copertura GPS e al Wi-Fi a conferma della loro

disattivazione.

Infine viene analizzato il punto 4), che in reala, si riferisce alla situazione

precedente, ma eseguendo l’applicazione su un dispositivo diverso, ovvero il

Nexus 5, mentre le prove descritte fin’ora sono state eseguite con un Sony

Xperia L. Cio che si vuole evidenziare, e che data l’eterogeneita dei disposi-

tivi e delle loro caratteristiche tecniche, a parita di configurazioni di rete, i

comportamenti tra e uno e l’altro possono essere diversi. Nel caso considera-

to, il Nexus 5 riceve una potenza del segnale piu bassa rispetto all’Xperia L.

Di conseguenza rispetto al caso descritto in precedenza, quando si va ad


Figura 7.2: Passaggio alla modalita UMTS AND GPS dopo non aver trovato

connessioni wireless utili, ma prevedendo la presenza di una cella telefonica

nella direzione dello spostamento.

eseguire l’interrogazione sul database alla ricerca di una buona cella a cui

connettersi, non viene restituito alcun risultato. A quel punto, si analizzano

anche le celle rilevate come vicine, con scarso successo. Per capire bene il

flusso logico dei passaggi, si puo considerare la Figura 7.4/a, in cui il l’Oracolo

rileva una buona candidata wireless e forza la connessione ad essa, disatti-

vando tutte le interfacce tranne quella Wi-Fi e notificando l’utente (in Figura

7.4/b).

A questo punto, si effettua lo stesso spostamento eseguito nel punto 3)

descritto in precedenza, quindi la potenza del segnale relativo alla connessione


Figura 7.3: Passaggio dalla modalita ONLY WIFI alla modalita

ONLY UMTS prevedendo una buona cella candidata a cui connettersi.

Wi-Fi utilizzata inizia a calare fino a raggiungere il livello di allarme.

Cio viene rilevato dall’Oracolo, che provvede quindi ad attivare l’interfaccia

per la connessione dati in quanto non vi sono altre reti wireless accettabili,

come mostrato in Figura 7.5.

Successivamente, vengono ricercate le possibile celle candidate, con scarsi

risultati in quanto il segnale di queste ultime risulta essere basso.

Viene quindi eseguito un ultimo tentativo, relativo alle celle vicine (dello

stesso operatore) a quella considerata in precedenza. Anche in questo caso i

risultati non sono soddisfacenti per via del segnale poco potente.


Figura 7.4: Inizialmente il Nexus 5 rileva una buona rete wireless e forza la

connessione ad essa.

Prima di notificare all’utente, che presto la connessione verra persa e che non

vi e altro che si puo fare, viene eseguito un ultimo tentativo con l’interfac-

cia wireless, ma senza successo in quanto volutamente ci si sta allontanando

dall’unico access point della zona (a cui inizialmente si era connessi).

Quindi, la potenza del segnale, presente nella base di dati, riferito a quest’ul-

timo risulta essere bassa. Questi passaggi sono documentati dalla Figura 7.6

rappresentante i messaggi del logCat. Come si puo notare da tale figura, il

telefono a questo punto passa nello stato NOTHING TO DO.

Infine, il passaggio dell’Oracolo allo stato NOTHING TO DO, viene no-

tificato all’utente (in Figura 7.7). In tal caso, nonostante le interfacce siano


Figura 7.5: L’Oracolo prevede che la connessione wireless verra persa e in

assenza di altre connessioni accettabili dello stesso tipo attiva, la corretta

interfaccia.

Figura 7.6: L’Oracolo considera le possibili celle a cui connettersi, con scarsi

risultati per via del loro segnale debole. Viene inoltre eseguito un ultimo

tentativo con l’interfaccia wireless.

disattivate, l’Oracolo provvede periodicamente ad effettuare una scansione,

attivandole, per capire in quale altra casistica dell’algoritmo posizionarsi, in

modo da connettere nuovamente il dispositivo e ricominciare a gestire il tutto

automaticamente.

Quindi, l’ultimo caso analizzato e utile ad evidenziare che, seppure per-

correndo il medesimo tragitto, a parita di configurazioni di rete, dispositivi

diversi tra loro possono eseguire flussi differenti di codice. Questo e dovuto

al fatto che non tutte le interfacce presenti sul mercato riescono a rilevare la

medesima potenza di segnale in parita di condizioni, dipende spesso anche

dalle loro caratteristiche tecniche. In tal caso, un fattore importante e la zona

di copertura di queste interfacce, ovvero la potenza del segnale che riescono

7.2 Valutazione dell’algoritmo di predizione 181

Figura 7.7: All’utente viene notificato che tutti i possibili tentativi per

garantire la continuita di connessione non sono andati a buon fine.

ad emettere. Evidentemente il dispositivo Nexus 5, ha delle interfacce meno

potenti dell’XPeria L, o si puo ipotizzare che la scocca in alluminio gommato

possa leggermente schermare il segnale.

7.2 Valutazione dell’algoritmo di predizione

Nella sottosezione 3.2.1 in cui si parlava di DDMS, si e accennato ad una

prova sperimentale relativa al calcolo del tempo di trasmissione di un file e del

monitoraggio dei relativi pacchetti. Per effettuare tale esperimento e stata

utilizzata LINE [32], una chat che permette di fare anche chiamate e condivi-

sione di file. Dato che DDMS (dalla versione 4 di Android) offre la possibilita

di contare il numero di pacchetti inviati aventi un certo tag, o controllare in

generale il traffico totale del dispositivo (attraverso la modalita network),

differenziando, qualora lo si voglia per l’interfaccia, si e deciso di effettuare


la seguente prova: testare l’invio di un file con LINE, sia con un dispositivo

supportato dall’Oracolo, sia con uno normale, dove la gestione delle inter-

facce viene lasciata ad Android. Dato che i ”tag” per tracciare i pacchetti

vanno inseriti da codice, e vengono successivamente controllati utilizzando il

simulatore, si e pensato di intraprendere una strada diversa in quanto l’ap-

plicazione non viene eseguita su quest’ultimo ma bensı su dispositivi veri e

propri. La soluzione approcciata, consiste quindi nel chiudere in modo forza-

to tutte le applicazioni che utilizzano la rete, in modo da lasciarne l’accesso

solo a LINE. Per fare cio e stata utilizzata l’applicazione SystemPanelLite

Task Manager [33]. Quest’ultima mette a disposizione molte funzionalita non

fornite dal gestore dei processi di Android. E stato utilizzato questo software

in quanto si possono chiudere i processi e bloccarne i successivi avvii, questo

perche, se tale operazione venisse fatta con Android, quest’ultimo andrebbe

comunque a riavviare quelli proprietari di sistema. Si e quindi proceduto con

l’inviare lo stesso file, una foto di 3239866 bytes. Viene quindi monitorato

sia nel caso dell’utilizzo dell’Oracolo, che non, il numero di pacchetti inviati

(contando anche le ritrasmissioni in caso di perdita) e il tempo impiegato per

il trasferimento, tralasciando l’andamento dei grafici visualizzati da DDMS

utili solo ad analizzare le velocita di trasmissione o ricezione.

Prima di passare all’analisi dei dati, e bene considerare alcune caratteri-

stiche di LINE. Esso, come altri programmi della stessa categoria come Wha-

tsApp e Telegram usa un protocollo chiamato XMPP (Extensible Messaging

and Presence Protocol) [34]. Quest’ultimo si appoggia su TCP (Transmis-

sion Control Protocol) come protocollo di trasporto, ed usa dei stream XML

per organizzare i dati da trasmettere. La scelta dell’XML e dovuta al fatto

che solitamente tali dati da trasportare rappresentano del testo, in quanto i

programmi che fanno uso di XMPP nascono principalmente come chat.

Appoggiandosi a TCP, XMPP eredita alcune caratteristiche fondamentali co-

me la struttura dei pacchetti nonche la dimensione del datagram, contenente

quindi byte rappresentati XML nella maggior parte dei casi o altro qualora

si stia trasmettendo un file da condividere in chat.

7.2 Valutazione dell’algoritmo di predizione 183

Da TCP viene inoltre ereditata la gestione della perdita dei pacchetti di cui

segue una breve descrizione, per fare in modo che il lettore abbia una visio-

ne di insieme del funzionamento. Il meccanismo di gestione dei pacchetti e

fondamentale, in quanto, data la dimensione standard del datagram pari a

65535 bytes, si necessita spesso di distribuire l’informazione da scambiare in

piu pacchetti. Questi ultimi, possono quindi arrivare a destinazione in un

ordine diverso rispetto quello naturale, o per qualche motivo non raggiun-

gono proprio la destinazione, quindi vengono numerati, in modo tale che si

possa effettuare un ordinamento e capire se vi sono pacchetti che sono andati

dispersi. Per ciascun pacchetto, il destinatario manda un messaggio detto di

acknowledge in caso di ricezione o di not acknowledge in caso contrario, in

modo tale che il mittente sappia quali pacchetti deve rispedire.

Detto cio si, passa quindi ad analizzare la prova effettuata che consiste

nell’utilizzare una chat di LINE per inviare una foto di dimensione pari a

3.239.886 bytes (circa 3,2 MB). L’invio ovviamente non avviene mantenendo

la connessione stabile, bensı utilizzando il dispositivo Sony Xperia nello sce-

nario descritto al punto 3) delle prove sperimentali viste in precedenza.

Si parte da una rete Wi-Fi di cui si ha una buona potenza del segnale fino

a perderne la copertura, dovendo quindi passare ad utilizzare una connessio-

ne dati mobili. I risultati ottenuti, in Tabella 7.1 sono la media di cinque

tentativi arrotondati per eccesso.

# Pacchetti inviati Tempo impiegato

Oracolo 67 31,2 sec

Senza Oracolo 61 28,6 sec

Tabella 7.1: Numero di pacchetti e tempo impiegato per inviare il medesimo

file a parita di condizioni, con e senza l’ausilio dell’Oracolo.

Come accennato in precedenza, e stata calcolata la media su cinque ten-

tativi in quanto non e garantita sempre la stessa velocita di spostamento,

essendo quest’ultimo avvenuto a piedi. Dai dati ottenuti, si puo osservare


che con l’utilizzo dell’Oracolo si ha un miglioramento sensibile, sopratutto in

termini di tempo, considerando la dimensione del file contenuta.

Tale differenza, di circa tre secondi, risiede quasi tutta nel tempo che An-

droid perde nel capire che la connessione wireless e caduta e ad instaurare una

connessione dati con la cella. Infatti, in tal caso, senza l’ausilio dell’Oracolo,

sono state attivate entrambe le interfacce. Essendo partiti da una posizione

molto vicina all’access-point Wi-Fi, Android ha prediletto la relativa inter-

faccia, successivamente allontandosi il piu velocemente possibile dall’AP, la

connessione e caduta, ma il sistema operativo va ad instaurare una connes-

sione sull’altra interfaccia solo dopo che cio e avvenuto ed impiegandoci un

lasso di tempo non trascurabile. Tale fase, infatti, dura circa due o tre secon-

di, gli stessi che differenziano i dati ottenuti dalla prestazione fatta rilevare

utilizzando l’Oracolo. Quest’ultimo invece, valutando che la connesione Wi-

Fi andra presto persa, forza anticipatamente la connessione dati alla cella

telefonica. Cosı facendo, quando la connessione wireless cade, quella ai dati

mobili e gia instaurata a pronta ad essere utilizzata, guadagnando tempo

prezioso e riducendo il numero di pacchetti che dovranno essere ritrasmessi.

In conclusione, l’Oracolo porta a dei benefici sia in termini di tempo che

in numero di pacchetti da trasmettere. Questo perche Android non fornisce

alcuna funzionalita atta a svolgere tale scopo. C’e da notare, che per quanto

riguarda la prova con il solo Android, se inizialmente non fossero state atti-

vate entrambe le interfacce, una volta persa la connessione Wi-Fi, il sistema

operativo non avrebbe fatto altro, in quanto l’interfaccia per la connessione

ai dati mobili sarebbe risultata disattivata.

7.3 Presupposti all’integrazione con ABPS

Un’ulteriore prova sperimentale degna di nota riguarda la conferma dei

presupposti che il progetto di tesi sviluppato, in combinazione con ABPS (di

cui si e parlato nelle sezioni 1.2 e 2.4), riesca a fornire un sistema in grado di

risolvere completamente il problema dell’handover per dispositivi Android.

7.3 Presupposti all’integrazione con ABPS 185

Questo perche, il progetto in questione offre un ottimo algoritmo di predi-

zione e di gestione automatizzata delle interfacce in relazione al movimento

del dispositivo, mentre, ABPS rende il cambiamento dell’indirizzo IP di un

nodo mobile trasparente a chi e coinvolto nella conversazione, o nell’utilizzo

di un qualsiasi altro servizio real-time che richieda continuita di connessione.

A tal proposito, si ricorda anche che nella sezione 2.3 si e parlato della fun-

zionalita chiamata aggressive wifi to cellular handover messa a disposizione

da Android Lollipop, che cerca di prediligere automaticamente l’utilizzo di

reti wireless qualora il sistema operativo riconosca i giusti presupposti.

Attualmente l’utenza e poco soddisfatta di questa nuova caratteristica, in

quanto spesso il sistema operativo non capisce quando attivare l’interfaccia

wireless e connettersi ad una determinata rete.

Oltre alle informazioni appena citate e ampiamente discusse fin’ora nel

lavoro di tesi, si e quindi sviluppato in piccolo progetto a se stante dall’appli-

cazione, per testare come Android gestisce la caduta di una connessione TCP.

Tale progetto consiste nell’implementare un server, di cui si ha il controllo,

che abbia un certo indirizzo IP e che stia in ascolto su una determinata porta

(a cui ovviamente sono stati assegnati i dovuti permessi).

Cio e stato fatto implementando un semplice programma Java e lanciandolo

su una delle macchine del laboratorio dell’Universita di Bologna, di cui si

conosce l’indirizzo IP. Successivamente, e stata creata una semplice applica-

zione Android che instaura una connessione TCP verso tale server.

Si vuole quindi capire come Android si comporta in condizioni normali (senza

l’utilizzo dell’Oracolo e sulla versione JellyBean), qualora la connessione ven-

ga fatta cadere forzatamente. In particolare, vengono attivate entrambe le

interfacce per la connettivita ed inizialmente, per il test, essendo in presenza

di un router Wi-Fi, il dispositivo si connette ad esso. Viene quindi instaurata

una connessione TCP utilizzando l’indirizzo IP del dispositivo nella rete wire-

less. Successivamente viene fatta cadere la connessione spegnendo l’interfac-

cia Wi-Fi. A questo punto, Android non effettua alcun servizio di tuneling

dei pacchetti verso l’altra interfaccia, anzi, il dispositivo impiega un certo


lasso di tempo (qualche secondo) per acquisire la connettivitia utilizzando la

connessione dati mobili. Quindi, viene instaurata una nuova connessione, con

un indirizzo IP ovviamente diverso, perdendo qualsiasi relazione con quella

vecchia.

In conclusione, cambiando interfaccia, la connessione vecchia viene chiusa

e ne viene stabilita una nuova con un indirizzo IP diverso.

Il processo di handover, in questo caso gestito direttamente da Android e

molto basilare, l’interfaccia dei dati mobili impiega del tempo per instaurare

una connessione, dato che il tentativo viene effettuato solo dopo che quella

wireless e caduta. Il nuovo indirizzo IP e ovviamente diverso e la vecchia

connessione viene quindi chiusa. Si puo quindi osservare, che l’Oracolo a tal

proposito diventa essenziale per il suo metodo di predizione, in modo da in-

staurare subito una connessione prima che quella attuale venga persa. Inoltre

nasce la necessita di avere a disposizione uno strumento di tuneling, oppure

rendere trasparenti questi cambiamenti tra i due nodi che comunicano.

In quest’ultimo caso, viene in soccorso ABPS che in combinazione con l’Oracolo

risolve pienamente tale problematica.

Quindi, la prova effettuata nella sezione precedente serve per testare la

bonta dell’algoritmo di predizione, attivando e disattivando le dovute inter-

facce, perdendo quindi meno pacchetti del previsto rispetto ad una situazione

gestita completamente dal solo Android. Inoltre e stato confermato da en-

trambe le prove, che Android non va ad utilizzare la nuova interfaccia fino a

quando non si e persa la connessione sull’altra. L’Oracolo permette quindi

di guadagnare tempo in tal proposito rendendo migliori parametri quali il

delay e il QoS.

Capitolo 8

Contributo del lavoro

Come accennato nella sezione 2.4, i contributi del lavoro di tesi sono mol-

teplici e riguardano principalmente l’introduzione di una soluzione al proble-

ma dell’handover, in ambiente Android, non ancora presente in letteratura.

Si e quindi partiti studiando lo stato dell’arte e sono stati rivisitati alcuni

concetti, come la preconfigurazione dell’indirizzo IP e la preautenticazione.

La prima tecnica, viene implementata ottenendo in anticipo l’indirizzo IP

dall’interfaccia di rete che si e previsto di usare a breve.

Viene tralasciato ad ABPS, la gestione del cambiamento di tale indirizzo.

Per quanto riguarda la preautenticazione, essa viene implementata a pieno,

infatti ci si autentica alla nuova connessione sull’altra interfaccia, non uti-

lizzata attualmente per scambiare i dati. Questa tecnica evita di effettuare

tale fase in seguito, diminuendo quindi il tempo impiegato per il processo

di handover vero e proprio. Riguardo ad ABPS appena citato, i risultati

ottenuti testando il comportamento naturale di Android, hanno evidenzia-

to come quest’ultimo non sia in grado, da solo, di gestire la caduta di una

connessione TCP. Ne consegue che ABPS, unito al progetto di tesi, risolve a

pieno tale problematica, in quanto, l’Oracolo fornisce la gestione automatiz-

zata delle interfacce ed ABPS si occupa di rendere trasparenti i cambiamenti

dell’indirizzo IP. Le altre prove sperimentali effettuate, hanno avuto riscontri

positivi. Infatti, oltre a testare l’applicazione nei possibili scenari di utilizzo,

187

188 8. Contributo del lavoro

si ha avuto un buon riscontro in termini cronometrici e di perdita dei pac-

chetti, riguardo all’algoritmo di predizione dell’utilizzo delle interfacce basato

sulla gestione degli spostamenti. Tali studi, hanno restituito dei dati, che in

altre proposte presenti in letteratura non sono presenti. Questo perche, que-

ste ultime, pur essendo interessanti e proponendo meccanismi di handover

tra varie tecnologie, non sono seguite da studi pratici.

La predisposizione all’approccio maggiormente teorico di tali lavori, e la con-

ferma che la problematica dell’handover e ancora in fase di sviluppo e i mec-

canismi per gestire tale processo risultano essere molto complessi.

Oltre a cio, si puo anche evidenziare come le proposte spesso siano orientate

ad integrare tecnologie come WiMax, che pero non sono diffuse come altre.

Inoltre altre soluzioni, come MIH, sono andate complicandosi col passare del

tempo, in quanto vogliono mettere a disposizione un protocollo che sia adatto

ad un’ampia moltitudine di tecnologie.

Si puo quindi concludere che i principali contributi del lavoro di tesi,

sono la proposta di una soluzione alla problematica dell’handover in ambien-

te Android, che nonostante i problemi di gioventu, pone una buona base

per i sviluppi futuri. Tale soluzione, supportata dalle prove sperimentali ef-

fettuate, ha dimostrato che la strada intrapresa sembra essere giusta ed in

combinazione con protocolli come ABPS, considerando le caratteristiche di

Android, migliora di molto il comportamento dei dispositivi equipaggiati con

tale sistema operativo.

Capitolo 9

Conclusioni e sviluppi futuri

In questo elaborato e stato trattato l’handover, analizzando come questo

processo sia attualmente al centro di molti studi. Dopo aver introdotto i

concetti generali e uno studio riassuntivo dello stato dell’arte, partendo da

un precedente lavoro di tesi atto ad effettuare la scansione delle interfacce,

l’attenzione si e indirizzata, nel progettare e sviluppare un’applicazione in

ambiente Android che possa essere eseguita anche come servizio, in grado di

facilitare il processo di handover. Partendo quindi dallo stato dell’arte si e

giunti ad una prima versione del software, per dispositivi general-purpose, che

e in grado analizzando le reti disponibili, di gestire autonomamente l’utilizzo

delle varie interfacce. A segnare un punto di innovazione per tale categoria

e il fatto che in letteratura non vi sono soluzioni in ambiente Android e che

le poche funzionalita rese disponibili a riguardo nelle ultime versioni di tale

sistema operativo, sembrano essere poco affidabili.

Il risultato ottenuto e un’applicazione/servizio, in grado di fornire un affida-

bile algoritmo di predizione dell’utilizzo delle interfacce e che presenta alcuni

aspetti di gestione, come ad esempio l’attivazione e la disattivazione diretta

dell’antenna GPS, non ancora sviluppate in precedenza.

Tale applicazione di nome Oracolo-ConnectionPointAnalyzer, risulta essere

leggera e facile da utilizzare, portabile, affidabile e libera da complesse fasi

di setup iniziale in quanto fornisce tutte le informazioni utili all’utente per

189

190 9. Conclusioni e sviluppi futuri

un corretto utilizzo.

Oltre a cio, l’algoritmo implementato propone la possibilita di essere localiz-

zati anche in assenza del segnale GPS, combinando le informazioni delle reti

Wi-Fi e delle celle telefoniche. Inoltre tale applicazione si presta bene alla

cooperazione con ABPS, unendo la funzionalita di predizione della gestione

delle interfacce della prima con la capacita di gestire in modo trasparente il

cambio di indirizzi IP della seconda.

La fase di test ha dato risultati confortanti soprattutto per quanto ri-

guarda l’algoritmo di predizione, mentre lo sviluppo vero e proprio e ancora

aperto ad ulteriori e progressivi miglioramenti, mirati a risolvere le proble-

matiche quali la gestione del GPS anche per le versioni successive a KitKat,

l’implementazione di un server online in cui situare la base di dati da cui

attingere le informazioni utili per la gestione delle interfacce.

Altre caratteristiche da sviluppare, riguardano la possibilita di variare dina-

micamente gli intervalli di scansione in base alle velocita di spostamento ed

infine apportare delle modifiche alla modalita di gestione delle configurazioni

di rete da parte di Android, inserendo anche l’indirizzo MAC nell’apposito file

di sistema e adattando quindi l’algoritmo di predizione a tale aggiornamento.

Bibliografia

[1] Andrea Somenzi, Alberto Paladino. Elaborato di tesi ”Mapping di

access-point Wi-Fi su Android”. A.A 2012/2013.

[2] Vittorio Ghini, Stefano Ferretti, Fabio Panzieri. ”The ”Always Best Pac-

ket Switching” architecture for SIP-based mobile multimedia services”.

The Journal of Systems and Software 84 (2011) 1827-1851.

[3] L. Atzori, A. Iera and G. Morabito. ”The Internet of Things: A survey.”

(2010) Computer Networks: 2787-2805.

[4] Antonio J. Jara, Miguel A. Zamora and Antonio F. G. Skarmeta. ”An

architecture based on Internet of Things to support mobility and security

in medical environments.” (2010).

[5] Antonio J. Jara, Miguel A. Zamora and Antonio F. G. Skarmeta. ”An

internet of things–based personal device for diabetes therapy manage-

ment in ambient assisted living (AAL).” (2011) Pers Ubiquit Comput

15:431-440.

[6] Android history: https://www.android.com/history/

[7] Claudia Linnhoff-Popien, Peter Ruppel. ”Mobile Communications -

Mobility Management”.

[8] Allan Borges Pontes, Diego Dos passos Silva, Jose jailton, Otavio Rodri-

gues, Kelvin Lopes Dias. ”Handover management in integrated WLAN

and mobile WiMaX networks”.

191

192 BIBLIOGRAFIA

[9] Jaydip Sen. ”Mobility and Handoff Management in Wireless Networks”.

[10] George Lampropoulos, Nikos Passas, Lazaros Merakos, Alexandros

Kaloxys. ”Hanodover management architecture in integrated Wlan/-

Cellular networks”. Fourth quarters 2005, volume 7, no. 4. IEEE

Communications Surveys.

[11] 3GPP TS 23.002 V6.5.0, ”Technical Specification 3rd Generation Part-

nership Project; Technical Specification Group Services and Systems

Aspects; Network Architecture (Release 6)”. June 2004.

[12] Linoh A. Magagula, H. Anthony Chan2, Olabisi E. Falowo1. ”Han-

dover approaches for seamless mobility management in next ge-

neration wireless networks”. January 2011, Wiley Online Library

(wileyonlinelibrary.com).

[13] Dutta A, Fajardo V, Ohba Y, Taniuchi K, Schulzrine H. ”A framework of

media-independent pre-authentication (MPA) for inter-domain hando-

ver optimization”. IETF MOBOTS Research Group, draft-irtfmobopts-

mpa-framework-08, September 2010.

[14] Emmelmann M, Wielhoelter S, Koepsel A, Kappler C, Wolisz A. ”Mo-

ving toward seamless mobility: State of the art and emerging aspec-

ts in standardization bodies”. Wireless Personal Communications 2007;

43(3): 803– 816.

[15] Jayaraman P, Lopez R, Ohba Y, Parthasarathy M, Yegin A. ”Protocol

for carrying authentication for network access”. IETF-rfc 5193, 2008.

[16] S.L. Tsao, C.-C. Lin. ”Design and evaluation of UMTS/WLAN interwor-

king strategies, Vehicular Technology Conference Proceedings”. VTC

2002-Fall. 2002 IEEE 56th. pp 777-781. Sept. 24-28.

[17] The Android project. https://www.android.com/

BIBLIOGRAFIA 193

[18] Smartphone OS market share. http://www.kantarworldpanel.com/global/

smartphone-os-market-share/

[19] SQLite Home Page. http://www.sqlite.org/

[20] SQLite documentation. https://www.sqlite.org/docs.html

[21] Extensible Markup Language (XML) Home page.

http://www.w3.org/XML/

[22] Standard Generalized Markup Language (SGML) Home page.

http://www.w3.org/MarkUp/SGML/

[23] R.A. Jarvis. ”On the identification of the convex hull of a finite set of

points in the plane”.

[24] How to root the Nexus 5. http://www.androidrootz.com/2013/11/nexus-

5-one-click-toolkit-for-mac.html

[25] VRoot - IRoot The Best Free Android Root Software.

http://www.mgyun.com/en/GetVRoot

[26] The SuperSu application. http://www.chainfire.eu/projects/52/SuperSU/

[27] The TWRP project. http://teamw.in/project/twrp2

[28] The Eclipse Home Page. http://eclipse.org/

[29] ADT - Android Developement Tools.

https://developer.android.com/tools/help/adt.html

[30] The Android SDK. https://developer.android.com/sdk/installing/

index.html

[31] DDMS - Dalvik Debug Monitor Server.

http://developer.android.com/tools/debugging/ddms.html

[32] LINE - Google PlayStore. https://play.google.com/store/apps/

details?id=jp.naver.line.android&hl=it

194 BIBLIOGRAFIA

[33] SystemPanelLite Task Manager - Google PlayStore.

https://play.google.com/store/apps/details?id=nextapp.systempanel

&rdid=nextapp.systempanel

[34] Extensible Messaging and Presence Protocol (XMPP): Core.

http://tools.ietf.org/html/rfc6120

[35] adb - Android Debug Bridge. https://developer.android.com/tools/help/

adb.html

[36] ADB shell - Issuing Shell Commands.

http://developer.android.com/tools/help/adb.html#shellcommands

[37] The JavaTM Tutorials.

http://docs.oracle.com/javase/tutorial/java/concepts/

[38] Service official android documentation.

http://developer.android.com/reference/android/app/Service.html

[39] The RootTools homepage. https://code.google.com/p/roottools/

[40] Support Library - Android developer.

http://developer.android.com/tools/support-library/index.html

[41] Demian Machta. ”Securing WLAN: From WEP to WPA”. Computer

Security CS574, San Diego State University, Fall 2003.

[42] Federal Information Processing Standards Publication 197. ”ADVAN-

CED ENCRYPTION STANDARD (AES)”. November 26, 2001.

[43] How to force Android to scan wifi with a specific interval.

http://forum.xda-developers.com/showthread.php?t=2108553

[44] Wifi ScanResult - Android Developer.

http://developer.android.com/reference/android/net/wifi/

ScanResult.html

BIBLIOGRAFIA 195

[45] Official U.S. Government information about the Global Positioning

System (GPS) and related topics. http://www.gps.gov/systems/gps/

[46] NeighboringCellInfo - Android Developers.

http://developer.android.com/reference/android/telephony/

NeighboringCellInfo.html

[47] Molisch, A. ”GSM Global System for Mobile Communications”. Wiley-

IEEE Press, ISBN:9781119992806.

[48] Juha Rapeli. ”UMTS: targets, system concept, and standardization in

a global framework”. 1999.

[49] Alexandros Kaloxylos, George Lampropoulos, Nikos Passas, Lazaros

Merakos. ”A flexible handover mechanism for seamless service continuity

in heterogeneous environments”. 2006.

[50] E. Dahlman et al. ”WCDMA - The Radio Interface for Future Mo-

bile Multimedia Communications”. IEEE Transaction on Vehicular

Technology, vol. 47, no. 4, pp. 1105-1118. November 1998.

[51] Ekstrom, H, Ericsson Res, Furuskar, A., Karlsson, J., Meyer, M.

”Technical solutions for the 3G long-term evolution”. IEEE, March 2006.

[52] Hakan Granbohm, Joakim Wiklund. ”GPRS - General Packet Radio

Service”.

[53] Shaoji Ni, Sven Gustav Haggman. ”GPRS performance estimation in

GSM circuit switched services and GPRS shared resource systems”.

IEEE September 1999.

[54] Jarmo Prokkola, Pekka H., J. Perala, Mikko Hanski, Esa Pi-

ri. ”3G/HSPA Performance in Live Networks from the End User

Perspective”. IEEE, June 2009.

196 BIBLIOGRAFIA

[55] Intents and Intent Filters - Android Developers.

http://developer.android.com/reference/android/content/Intent.html

http://developer.android.com/guide/components/intents-filters.html

[56] UTRAN Cell Identity returned by getCid().

http://stackoverflow.com/questions/7240038/utran-cell-identity-

returned-by-getcid

http://developer.android.com/reference/android/telephony/gsm/

GsmCellLocation.html#getCid()

[57] Hotspot with same SSID in Android.

http://security.stackexchange.com/questions/42887/hotspot-with-

same-ssid-how-does-authorization-work

[58] WifiConfiguration.Status - Android Developers.


WifiConfiguration.Status.html

[59] SQLiteOpenHelper - Android Developers.

http://developer.android.com/reference/android/database/sqlite/

SQLiteOpenHelper.html.

[60] getConfiguredNetworks - WifiManager - Android Developers.


WifiManager.html#getConfiguredNetworks().

Ringraziamenti

La stesura di questo elaborato ha coinciso con lo sviluppo della prima

versione del software che si e basato su un lavoro precedente di tesi di Alber-

to Paladino e Andrea Somenzi. Quest’ultimo lavoro prevedeva la semplice

scansione delle reti wireless rilevate dal dispositivo con un intervallo specifi-

cato dall’utente, salvandone i risultati in file xml. Il risultato finale e stato

molto soddisfacente in quanto l’applicazione oltre a proporre una soluzione

alla problematica dell’handover, prevede anche una funzionalita di training

in cui salvare i dati rilevati dalle varie interfacce presenti sul dispositivo in

base alle impostazioni suggerite dall’utente, tali dati sono utili per gli uti-

lizzi successivi dell’applicazione o per creare una base di dati completa per

mappare i vari access point e celle presenti sul territorio.

Quindi un ringraziamento va ai colleghi Paladino e Somenzi, ma soprat-

tutto al Professor Ghini per la proposta di tesi molto interessante adibita a

risolvere un problema che affligge i dispositivi mobili ormai parte integrante

della vita quotidiana. Un ultimo ringraziamento allo sport, in particolare al

pugilato, valvola di sfogo in questi anni nonche alla musica e alla mia fedele

chitarra. Inoltre sono a disposizione per eventuali, nuove, fasi di sviluppo

dell’applicazione. Il futuro di un’idea, anche la piu semplice, puo difatti

apparire incerto. In ogni caso, non occorre necessariamente seguire un per-

corso prefissato ma, anzi, la bellezza sta nell’imprevedibilita. Come disse T.F

Hodge in From Within I Rise: Spiritual Triumph Over Death and Conscious

Encounters with The Divine Presence:

”The beauty of inspiration is its unpredictable timing.”

197

Documents

STUDIO ED IMPLEMENTAZIONE DI UN ALGORITMO PER LA GESTIONE … › ~ghini › didattica › sistemimobili › ... · 6.6 Schermata dell’applicazione SuperSu, con la lista delle applica-zioni