studio ed implementazione di un algoritmo per la gestione … › ~ghini › didattica ›...
TRANSCRIPT
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.
12 2. Obbiettivo del progetto
• 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.
14 2. Obbiettivo del progetto
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
16 2. Obbiettivo del progetto
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).
18 2. Obbiettivo del progetto
• 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.
2.3 Stato dell’arte 19
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.
20 2. Obbiettivo del progetto
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-
2.3 Stato dell’arte 21
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
22 2. Obbiettivo del progetto
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).
2.3 Stato dell’arte 23
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).
24 2. Obbiettivo del progetto
• 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.
2.3 Stato dell’arte 25
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
26 2. Obbiettivo del progetto
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
2.3 Stato dell’arte 27
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
28 2. Obbiettivo del progetto
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
2.3 Stato dell’arte 29
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
30 2. Obbiettivo del progetto
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
2.3 Stato dell’arte 31
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
32 2. Obbiettivo del progetto
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.
2.3 Stato dell’arte 33
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].
34 2. Obbiettivo del progetto
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
2.3 Stato dell’arte 35
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
36 2. Obbiettivo del progetto
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
2.3 Stato dell’arte 37
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-
38 2. Obbiettivo del progetto
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
2.3 Stato dell’arte 39
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:
40 2. Obbiettivo del progetto
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.
2.3 Stato dell’arte 41
• 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
42 2. Obbiettivo del progetto
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.
48 3. Strumenti e tecnologie
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.
50 3. Strumenti e tecnologie
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.
52 3. Strumenti e tecnologie
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
54 3. Strumenti e tecnologie
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
56 3. Strumenti e tecnologie
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
58 3. Strumenti e tecnologie
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-
60 3. Strumenti e tecnologie
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.
62 3. Strumenti e tecnologie
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
64 3. Strumenti e tecnologie
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.
66 3. Strumenti e tecnologie
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.
68 3. Strumenti e tecnologie
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-
70 3. Strumenti e tecnologie
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).
72 3. Strumenti e tecnologie
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.
74 3. Strumenti e tecnologie
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.
76 3. Strumenti e tecnologie
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.
78 3. Strumenti e tecnologie
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,
3.7 Connessione dati del provider telefonico 79
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).
80 3. Strumenti e tecnologie
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.
3.7 Connessione dati del provider telefonico 81
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
82 3. Strumenti e tecnologie
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
3.7 Connessione dati del provider telefonico 83
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.
84 3. Strumenti e tecnologie
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
3.7 Connessione dati del provider telefonico 85
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.
86 3. Strumenti e tecnologie
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.
3.7 Connessione dati del provider telefonico 87
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
88 3. Strumenti e tecnologie
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
90 3. Strumenti e tecnologie
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.
92 3. Strumenti e tecnologie
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
102 4. Progettazione
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.
104 4. Progettazione
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.
106 4. Progettazione
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.
108 4. Progettazione
• 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.
110 4. Progettazione
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
112 4. Progettazione
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
114 4. Progettazione
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
116 4. Progettazione
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-
118 4. Progettazione
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-
120 4. Progettazione
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
26 network={27 ssid=”dlink”
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.
122 4. Progettazione
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).
128 5. Implementazione
• 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
130 5. Implementazione
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):
5.2 Problemi emersi durante l’implementazione 131
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 }}
132 5. Implementazione
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.
5.2 Problemi emersi durante l’implementazione 133
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.
134 5. Implementazione
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)
5.2 Problemi emersi durante l’implementazione 135
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)
136 5. Implementazione
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
5.2 Problemi emersi durante l’implementazione 137
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
138 5. Implementazione
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.
140 5. Implementazione
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
5.3 Dettagli implementativi 141
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,
142 5. Implementazione
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())
5.3 Dettagli implementativi 143
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”
/>
144 5. Implementazione
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)) ∗
5.3 Dettagli implementativi 145
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.
146 5. Implementazione
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.
5.3 Dettagli implementativi 147
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
148 5. Implementazione
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
5.3 Dettagli implementativi 149
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
150 5. Implementazione
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/
8 RootTools.getShell(true).add(command2);
9
10 //change the permission to the new build.prop file for next reads
11 RootTools.getShell(true).add(command3);
12
13 //change owner and group of new build prop file (user = root, group = root)
14 RootTools.getShell(true).add(command4);
5.3 Dettagli implementativi 151
15 //change permission of build.propf file (644)
16 RootTools.getShell(true).add(command5);
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-
152 5. Implementazione
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
5.3 Dettagli implementativi 153
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.
154 5. Implementazione
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
5.3 Dettagli implementativi 155
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:
Costruzione di un arrayList di oggetti WifiList (parte 2)
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));
156 5. Implementazione
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:
5.3 Dettagli implementativi 157
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=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:
158 5. Implementazione
Costruzione di un arrayList di oggetti WifiList (parte 3)
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
5.3 Dettagli implementativi 159
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 }
160 5. Implementazione
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
5.3 Dettagli implementativi 161
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.
162 5. Implementazione
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
166 6. L’applicazione
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
168 6. L’applicazione
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
170 6. L’applicazione
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).
176 7. Valutazione e prove sperimentali
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
7.1 Valutazione del comportamento in scenari caratteristici 177
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
178 7. Valutazione e prove sperimentali
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.
7.1 Valutazione del comportamento in scenari caratteristici 179
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
180 7. Valutazione e prove sperimentali
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
182 7. Valutazione e prove sperimentali
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
184 7. Valutazione e prove sperimentali
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
186 7. Valutazione e prove sperimentali
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.
http://developer.android.com/reference/android/net/wifi/
WifiConfiguration.Status.html
[59] SQLiteOpenHelper - Android Developers.
http://developer.android.com/reference/android/database/sqlite/
SQLiteOpenHelper.html.
[60] getConfiguredNetworks - WifiManager - Android Developers.
http://developer.android.com/reference/android/net/wifi/
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