Implementazione di meccanismi per il positioning dei dispositivi

UNIVERSITA’ DEGLI STUDI DI NAPOLI “FEDERICO II”
FACOLTA’ DI INGEGNERIA
Corso di Laurea in Ingegneria Informatica
Dipartimento di Informatica e Sistemistica
TESI DI LAUREA
Implementazione di meccanismi per il positioning dei
dispositivi mobili in infrastrutture di Nomadic
Computing
RELATORE
Prof. Ing. Stefano Russo
CORRELATORE
Ing. Massimo Ficco
Anno Accademico 2002/2003
CANDIDATO
Maurizio Piccirillo
Matr. 41/203
Ci siamo, sono ad un passo dal giorno che ho immaginato non poche
volte in questi anni di studi. Anni, caratterizzati da momenti sicuramente non
facili, ma superati con la forza e la tenacia di chi vuole giungere fino in fondo e
soprattutto con
la voglia di poter dire a me stesso “c’è l’ho fatta!”. Grazie,
dunque, a me, per averci creduto ed ai miei genitori che hanno avuto anche loro
modo di trepidare per ognuno degli esami di questo percorso di vita che, sono
certo, potrà darmi d’ora in avanti, quella spinta per affrontare una nuova realtà
che da un po’ di tempo mi aspetta.
Un pensiero particolare va alla mia famiglia, ai miei nipotini, Davide e
Riccardo che senza saperlo hanno contribuito non poco al raggiungimento del
mio traguardo, a tutti gli amici, e soprattutto a chi ha saputo starmi vicino e fatto
superare momenti difficili.
Un grazie al Prof. Stefano Russo
che mi ha dato la possibilità di
partecipare a questo lavoro, al mio correlatore Massimo che ha sempre creduto
in me , a Domenico, cui devo una scommessa.
2
Indice
Introduzione.......................................................................................i
Servizi di positioning in infrastrutture di nomadic computing........ 9
1.1 Introduzione ............................................................................................. 9
1.2 Distributed computing .............................................................................. 3
1.3 Nomadic Computing................................................................................. 7
1.3.1 Perché il nomadic computing ............................................................ 7
1.4 Caratteristiche di un sistema di pervasive computing ................................ 8
1.5 Esigenze di positioning per nomadic computing ....................................... 9
1.6 Scenario applicativo considerato ............................................................ 10
L'approccio considerato ................................................................. 12
2.1 Introduzione ........................................................................................... 12
2.2 Soluzioni per sistemi di positioning ........................................................ 13
2.2.1 Sisteme di localizzazione basato su radiofrequenza(RF)............... 13
2.2.2 Sistema di posizionamento indoor"DOLPHIN"............................ 14
2.2.3 Esperimento di localizzazione conBluetooth ................................ 15
2.3 L'
approccio proposto .............................................................................. 16
2.4 L'
architettura generale ............................................................................ 19
Analisi delle tecnologie per il positioning dei dispositivi mobili... 21
3.1 Introduzione ........................................................................................... 21
3.2 Sistemi di coordinate .............................................................................. 22
3.2.1 Coordinate relative ed assolute ....................................................... 23
3.3 Modellazione dell'
ambiente di interesse.................................................. 23
3.4 Triangolazione ....................................................................................... 25
3.4.1 Lateration....................................................................................... 25
3.4.2 Lateration....................................................................................... 26
3.5 Metodi di localizzazione......................................................................... 27
3.5.1 Una tassonomia dei sistemi di localizzazione.................................. 28
3.5.2 Proxynity ........................................................................................ 30
3.5.3 Time-of-Flight ................................................................................ 30
3
3.5.4 Time Difference Of Arrival ............................................................. 31
3.5.5 Angle-of-Arrival............................................................................. 32
3.5.6 Received Signal Strenght Indication................................................ 33
3.5.7 Scene Analisys ................................................................................ 34
3.5.8 Miglioramenti del sistema di localizzazione.................................... 35
3.6 Sistemi esistenti...................................................................................... 36
3.6.1 Enhanced 911................................................................................. 39
3.6.2 Active Badge................................................................................... 39
3.6.3 Active Bat ....................................................................................... 40
3.6.4 Cricket............................................................................................ 41
3.6.5 Easy Livig ...................................................................................... 42
3.6.6 CGI-TA .......................................................................................... 43
3.6.7 GPS,D-GPS,A-GPS........................................................................ 44
3.6.8 Sim-Toolkit .................................................................................... 47
3.6.9 RADAR.......................................................................................... 47
3.6.9.1 Modello dei dati .................................................................. 48
3.6.9.2 Fase di "OFF-line".............................................................. 49
3.6.9.3 Fase di "On-line .................................................................. 49
3.6.10 Localizzzione in reti Ad-hoc........................................................... 50
Progetto ed implementazione........................................................ 51
4.1 Introduzione ........................................................................................... 51
4.2 Il modello utilizzato................................................................................ 51
4.3 Definizione dell'
infrastruttura del sistema di localizzazione .................... 53
4.3.1 Scelta dello standard di comunicazione: Bluetooth.......................... 53
4.3.1.1 Lo stack protocollare Bluetooth........................................... 54
4.3.3.2 Campo di copertura Bluetooth............................................. 56
4.3.3.3 Le modalità di comunicazione............................................ 56
4.3.3.4 La frequenza di trasmissione .............................................. 58
4.3.2 Dispositivi utilizzati ............................................................................ 59
4.4 Dettagli architetturali.............................................................................. 59
4.4.1 Lo stack BlueZ ............................................................................... 60
4.4.2 BlueZ e Java: JblueZ ...................................................................... 62
4.4.3 Implementazione dell'architettura................................................... 63
4.4.3.1 Estensione JblueZ attraverso Java Native Interface(JNI) ... 64
4.5 Descrizione del meccanismo di positioning ............................................ 66
4.6 Limiti imposti dall'
hardware .................................................................. 69
Una implementazione delle JSR-179 mediante le API JSR-82 ...... 69
5.1 Introduzione ........................................................................................... 70
4
5.2 Descrizione delle JSR-179...................................................................... 70
5.2.1 Il modulo LocationProvider ......................................................... 72
5.2.2 La classe Landmark ..................................................................... 74
5.3 Le JSR-179 nel modello di positioning proposto..................................... 75
5.4 Implementazione del LocationEstimator................................................. 77
5.4.1 Le JSR-82...................................................................................... 77
5.4.1.1 Carattesistiche generali ........................................................ 77
5.4.2 Implementazione Software del LocationEstimator mediante JblueZ79
Test sperimentali ............................................................................ 82
6.1 Introduzione ........................................................................................... 82
6.2 Received Signal Strenght Indication (RSSI) ........................................... 83
6.3 Test sperimentali sull'
RSSI..................................................................... 84
6.4 Utilizzo dell'
RSSI in un meccanismo di positioning................................ 85
6.4.1 Test sperimentale............................................................................ 86
6.5 Link Quality ............................................................................................. 91
Conclusioni.................................................................................................... 94
Appendice ...................................................................................................... 96
Bibliografia ................................................................................... 104
5
Introduzione
Il personal computer, Internet, ed il World-Wide-Web hanno già
influenzato molti aspetti del business, e ci sono chiari segni di una maggiore
convergenza fra i media, l'
elettronica di consumo e di divertimento, le
telecomunicazioni e l'
informatica. Tuttavia, la nuova ondata della rivoluzione
tecnologica ci influenzerà in maniera incisiva, invadendo tutti
nostra
gli aspetti della
vita
quotidiana.
Dove ci stiamo dirigendo? Contrariamente alle precedenti predizioni popolari, il
XXI secolo sarà probabilmente caratterizzato non dagli insediamenti sulla luna,
da città subacquee o da automobili ad energia nucleare (tutte cose che richiedono
immensi investimenti nelle infrastrutture), ma da applicazioni basate su
tecnologie miniaturizzate e quindi quasi invisibili, come le biotecnologie, le
nanotecnologie e la microelettronica.
sinergie
si
Sarà quindi interessante vedere quali
svilupperanno
fra
queste
aree.
Ovviamente, i progressi della microelettronica non sono una novità. Al contrario,
per più di 30 anni la ben nota legge di Moore, che stabilisce il raddoppio della
potenza di calcolo ogni 18 mesi, ha confermato la sua validità. Siamo ora certi
che la tendenza odierna continuerà per i prossimi anni a venire, il che rende così
affascinante quest'
area di sviluppo. E'ora evidente come il prossimo futuro sarà
caratterizzato da dispositivi con processori minuscoli,
che, grazie alle loro
dimensioni esigue ed al costo limitato, saranno integrati in praticamente ogni
oggetto quotidiano.
Parallelamente, il crescente sviluppo delle tecnologie wireless su ampio e corto
raggio (UMTS, WI-FI e Bluetooth, ad esempio) sta contribuendo ad abbattere
6
alcuni limiti che caratterizzavano i tradizionali metodi di connessione, rendendo
possibile la comunicazione tra dispositivi in movimento (Mobile Computing) e
facilitando il collegamento degli utenti ad infrastrutture fisse come internet o
intranet aziendali.
Queste innovazioni hanno, dunque, portato ad affiancare alle infrastrutture di reti
classiche, nuove infrastrutture di reti ibride (wired e wireless) e totalmente
wireless (senza alcun core di rete fisso) dette rispettivamente di nomadic
computing e ad hoc computing.
Con il connubio tra gli apparati mobili dell’elettronica di consumo (Personal
Digital Assistano, smart phone,…) e le nuove infrastrutture di rete, non è
difficile pensare a scenari in cui le persone hanno wearable computer per
svolgere le loro attività quotidiane in assoluta libertà di movimento, oppure per
utilizzare i servizi informatici offerti dalle strutture pubbliche e private con cui
esse si trovano ad interagire (come shopping mall, aeroporti, musei, sedi
lavorative…).
In uno scenario in cui l’informatica sta assumendo sempre più carattere di
ubiquità i servizi offerti possono essere innumerevoli e differenziati in base al
contesto. Le applicazioni dovranno quindi essere in grado di cercare
dinamicamente i servizi e adattarsi a nuovi ambienti. Presupposto necessario a
ciò è la capacità di riconoscere il contesto stesso ed in particolar modo la
localizzazione di un dispositivo in un predeterminato spazio che sicuramente
rappresenta uno degli aspetti critici del context awareness.
Questo lavoro di tesi tenta di dare un contributo in merito alla possibilità di
localizzare un dispositivo mobile in ambienti indoor. Dopo una analisi di quelli
che sono i modelli studiati in numerose ricerche, viene posta l’enfasi sulla
semplicità dell’approccio proposto che mira alla individuazione della “zona” in
cui opera un dispositivo mobile. Questo tipo di approccio nasce dalla
considerazione che in molte applicazioni emergenti della vita quotidiana ciò che
conta, al fine di offrire il servizio giusto nel momento giusto, non è la
conoscenza esatta della posizione del terminale mobile in termini di coordinate
7
spaziali, ma bensì l’individuazione approssimativa dell’area in cui si sta
operando.
Il lavoro è strutturato come segue:
- Nel primo capitolo vengono introdotti i concetti di nomadic computing e di
context awareness. In particolare si pone l’attenzione sulle esigenze
di
localizzazione dei dispositivi mobili al fine di poter utilizzare le informazioni e/o
i servizi disponibili in aree definite.
-Nel
secondo capitolo si introduce un tipo di approccio innovativo per la
localizzazione dei dispositivi mobili. Lo si definisce approccio “zoning”. Non si
mira alla determinazione delle coordinate ma semplicemente alla individuazione
della zone in cui opera il dispositivo al fine di poter
utilizzare i servizi
disponibili in ciascuna di esse. Si introduce, infine l’architettura generale del
sistema.
- Nel terzo capitolo si fa una analisi di quelle che sono le tecniche e le tecnologie
utilizzate per il positioning dei dispositivi mobili.
-Nel quarto capitolo si entra nel dettaglio del progetto descrivendo
l’implementazione dal livello network fino a quello utente. In particolare dopo la
scelta di Bluetooth come tecnologia wireless, si introduce BlueZ che rappresenta
l’implementazione dello stack protocollare Bluetooth per linux.
-Nel quinto capitolo dopo una descrizione delle API per il positioning JSR-179 e
delle JSR-82 per lo sviluppo di applicazioni Bluetooth in Java, viene delineata
una strategia di utilizzo delle JSR-179 nel modello di positioning proposto.
Infine, viene definita
una possibile implementazione delle stesse JSR-179
mediante le JSR-82
- Nel sesto capitolo vengono presentati i risultati sperimentali dei test condotti
per la valutazione del meccanismo di positioning implementato.
8
Capitolo 1
Servizi di positioning in infrastrutture di nomadic
computing
1.1
Introduzione
I sistemi di comunicazione e di elaborazione dell’informazione hanno subito
negli ultimi anni una profonda evoluzione. Da quando un solo grande calcolatore
(il temuto mainframe) era il protagonista assoluto, molta strada è stata fatta.
Oggi, vedere una persona che disponga e usi normalmente un personal computer
non è più una novità e immaginare un futuro dove molti dispositivi intelligenti
saranno al servizio di un ognuno di noi non sembra più essere fantascienza.
Questo percorso evolutivo dal computing del centro di calcolo, che passa per il
computing personale fino a finire al computing ubiquo e pervasivo è stato
delineato già da tempo da uno dei ricercatori più citati nell’ambito di questi
One computer, many people
One person, one computer
One person, many computers
Figura 1.1 - L’evoluzione dei sistemi di elaborazione e comunicazione
argomenti, Mark Weiser [5] (la figura 1-1 illustra il suo modo di vedere tale
9
evoluzione). Weiser cosi definiva il concetto di Ubiquitous Computing: “In
principio c’erano gli elaboratori di dati: un solo computer al servizio di un gran
numero di persone. Poi è arrivata la rivoluzione dei PC: un computer al servizio
di una sola persona. Infine, molte piattaforme elettroniche a disposizione di una
unica persona, in qualsiasi luogo si trovi.”
I nuovi sistemi di elaborazione dell’informazione dovranno essere caratterizzati
da un grado di mobilità, dinamicità e flessibilità sempre maggiore: un individuo
ha bisogno di spostarsi portando con sé tutti gli strumenti che la tecnologia offre
a supporto del suo lavoro o dei suoi passatempi ludici. In questi movimenti, il
contesto che ci circonda varia nelle risorse e nelle condizioni: i nostri dispositivi
saranno veramente utili solo se sufficientemente flessibili da adattarsi a questa
dinamicità. La loro specializzazione aiuterà poi l’integrazione negli ambienti di
tutti i giorni (ufficio, casa,...), così da andare incontro alla “diffidenza” delle
persone più restie alle innovazioni.
E’ evidente come il contesto rappresenti un ruolo fondamentale in tutte quelle
situazioni in cui gli utenti sono mobili e i servizi si differenziano in funzione
degli scenari . In particolare, la possibilità di localizzare
un individuo con il
suo PDA, ad esempio, è sicuramente l’aspetto critico affiche si possa accedere
alle informazioni giuste nel momento giusto.
Nel seguito verranno descritti i concetti di base che caratterizzano il distribuited
computing emergente; successivamente viene introdotto
il concetto di
positioning ed il suo ruolo fondamentale in ambienti di Nomadic Computing.
10
1.2
Distributed computing
In via del tutto generale possiamo dire che un sistema distribuito consiste in
una collezione di componenti dislocati su vari computer connessi attraverso una
rete telematica [1]. Come già evidenziato, i sistemi distribuiti tradizionali sono
evoluti negli anni verso nuovi sistemi di elaborazione e comunicazione: mobile
computing, pervasive computing, ubiquitous computing, nomadic computing, ad
hoc computing. Anche se alcune similitudini possono essere individuate, ognuno
di essi ha un’identità ben definita se si guarda ai seguenti aspetti [1] [2]:
Device: per device si intende un nodo di rete dotato di capacità elaborativa; in
base alle sue proprietà di mobilità spaziale si può classificare in:
-
fisso: dispositivi generalmente potenti con grandi quantità di memoria e
processori veloci;
-
mobile: device tipicamente poveri di risorse e con problemi di alimentazione
che implicano la loro limitata disponibilità nel tempo.
Embeddedness: per embeddedness si intende il grado di specificità del
compito per cui viene progettato un device nonché il livello di integrazione
raggiunto nel costruire il dispositivo che assolve il determinato compito. In
base a questo criterio è possibile distinguere tra dispositivi:
-
general-purpose: un dispositivo è general-purpose quando è progettato per
non rispondere a compiti specifici (PDA, laptop, PC…);
-
special-purpose: un dispositivo è special-purpose quando è progettato per
rispondere a compiti specifici (microcontrollori, sensori, badges …).
Sulla base degli attributi elencati sopra i sistemi distribuiti possono essere
classificati in sistemi di:
Traditional distributed computing: sono una collezione di device fissi e
general-purpose connessi tra loro attraverso una connessione permanente le
cui applicazioni vivono in un contesto di esecuzione statico.
11
Nomadic computing: è definito in letteratura come un modello di
computazione distribuita in cui la comunicazione ha luogo su infrastrutture di
reti fortemente eterogenee. Tali infrastrutture sono composte di uno o più
domini wireless tenuti insieme da una infrastruttura fissa (the core network),
e forniscono sempre ed ovunque accesso ai dispositivi mobili.
Una infrastruttura di nomadic computing deve permettere di:
- localizzare gli utenti;
- fornire agli utenti il loro usuale ambiente di lavoro;
- proteggere le sessioni di lavoro quando ci si sposta tra computer;
- adattare dinamicamente le applicazioni e le comunicazioni all’ambiente
di calcolo.
Ad hoc mobile computing: i sistemi distribuiti ad hoc sono costituiti da un
insieme di dispositivi mobili, tipicamente general-purpose, connessi tra di
loro attraverso un collegamento intermittente e senza alcuna infrastruttura
fissa, dove le applicazioni vivono in un contesto di esecuzione fortemente
dinamico. Gli scenari di ad hoc computing possono essere numerosi; si può
pensare ad una scrivania con tanti dispositivi wireless che comunicano tra
loro (stampante, pda, cellulare) o ad un campo di battaglia dove dei tank
devono scambiarsi strategie di attacco.
Pervasive computing: si parla di pervasive computing quando il sistema
distribuito è composto da un insieme di dispositivi fissi special-purpose
(sensori, lettori di badges, microcontrollori, …) connessi tra loro attraverso
un collegamento tipicamente permanente le cui applicazioni vivono in un
contesto di esecuzione tipicamente statico soggetto solo talvolta a rapidi
cambiamenti. Con pervasive computing in pratica si intende la crescente
diffusione di dispositivi informatici intelligenti, facilmente accessibili e
12
specialpurpose
devices
embeddedness
ubiquitous
pervasive
ad hoc
generalpurpose
devices
nomadic
traditional
mobility
mobile device and
intermittent connection
Fixed device and
permanent connection
Figura 1.2 - Le varie forme di distributed computing caratterizzate dal punto
di vista della mobilità e della specializzazione dei dispositivi
talvolta invisibili, il cui uso semplifica lo svolgimento dei normali compiti di
tutti i giorni (si pensi alle idee e alle innovazioni per la domotica, la domus
robotica). Tali dispositivi sono spesso progettati per estendere le applicazioni
basate su standard aperti alla vita quotidiana e sono molto spesso incorporati
nell'
ambiente in cui operano (sensori di posizione, sensori di luminosità, …).
Ubiquitous computing: i sistemi di ubiquitous computing sono costituiti da
un insieme di dispositivi mobili, per la maggior parte special-purpose
connessi tra loro attraverso collegamenti intermittenti e le cui applicazioni
vivono in un contesto tipicamente dinamico. I sistemi di ubiquitous
computing nascono dall’evoluzione dei sistemi di pervasive computing data
dall’introduzione della mobilità dei dispositivi (per questo spesso i due
termini sono usati come sinonimi). Con l’ubiquitous computing i device
faranno parte dei nostri naturali movimenti ed interazioni con i normali
ambienti del prossimo futuro: tutto ciò che è possibile immaginare con i
computer e le telecomunicazioni, in movimento, fermi, in cielo, in terra o in
mare può essere considerato ubiquitous computing [3].
13
Si osservi che nomadic e ad hoc computing possono essere visti come due forme
diverse del concetto più generale di mobile computing. In realtà, come
rappresentato graficamente in figura 1.3, “isole” di ad hoc computing possono
coesistere nelle infrastrutture di nomadic computing.
Nella figura 1.2 si riporta una rappresentazione grafica della tassonomia
presentata e tratta da [2]. La mobility è funzione della mobilità dei dispositivi,
della tipologia di connessione di rete tra di essi e del contesto di esecuzione.
Come è facile intuire maggiore è il grado di mobilità e di embeddedness, più è
sentita la necessità di fornire alle applicazioni di questi ambienti soluzioni
efficaci per consentire agli utenti l’utilizzo dei servizi offerti dall’ambiente e dai
dispositivi in esso presenti [3]. Infatti:
l’elevata embeddedness implica (tipicamente) la povertà di risorse:
non si può pensare più allo sviluppo di applicazioni/soluzioni che
introducono un carico computazionale “pesante” in quanto la
presenza di dispositivi “leggeri” è più la regola che l’eccezione;
l’elevata mobilità dei dispositivi implica spesso che un servizio possa
non essere disponibile ad un certo istante (perché la connessione di
rete non è stabile, o perché il dispositivo sta migrando verso un altro
ambiente). Ciò non deve comportare un malfunzionamento: bisogna
pensare a soluzioni che tengano conto di queste eventualità.
Figura 1.3 - Una tipica infrastruttura di nomadic computing
14
.
1.3
Nomadic Computing
Abbiamo detto che i sistemi di nomadic computing rappresentano un
compromesso tra i sistemi totalmente fissi e totalmente mobili; rappresentano
quindi a nostro avviso un passo intermedio per evolvere verso i sistemi di
elaborazione completamente mobili. Questa idea di “migrazione” dai sistemi
fissi a quelli mobili è ben rappresentata dalla figura 1-4.
1.3.1 Perché il nomadic computing
L’attenzione di questa tesi è rivolta ai sistemi di nomadic computing perché
rappresentano oggi un paradigma di comunicazione che meglio si adatta al
nostro fare quotidiano: come indicato da Kleinrock, oggi viviamo in un
“disconnected world” dove il più delle volte viaggiamo da una postazione fissa
all’altra, ufficio, casa, aeroporti, hotel, portando con noi i nostri computer e i
dispositivi di comunicazione. La combinazione del mobile computing supportato
dalle telecomunicazioni emergenti, sta cambiando oggi il nostro modo di vedere
l’elaborazione delle informazioni. Si riconosce, giorno dopo giorno, la necessità
di accedere alle risorse anche quando si è in movimento e durante la migrazione
da un contesto ad un altro. Ovvero, come riportato in [5], anytime, anywhere
access.
D’altra parte, quando si pensa allo sviluppo di questi ambienti di
elaborazione distribuita, le infrastrutture di rete oggi disponibili rappresentano il
giusto compromesso tra carico computazionale e leggerezza dei dispositivi
mobili.
Pertanto gli scenari di nomadic computing nell’ambito dell’office
automation, nella domotica o in tutti quegli ambienti con nodi fissi in grado di
offrire servizi e capaci di ospitare dispositivi mobili (aeroporti, gallerie d’arte,
aerei, navi da crociera, strutture abitative…) diventeranno sempre più diffusi e
15
costituiranno il passo da compiere per raggiungere l’obiettivo all the time,
everywhere access dei futuri scenari di ubiquitous e pervasive computing [6].
Caratteristiche di un sistema di pervasive computing
1.4
In uno scenario di pervasive computing la computazione è altamente
dinamica e disaggregata: gli utenti sono mobili e i servizi sono forniti da una
serie di componenti distribuiti che collaborano tra loro. Inoltre l’accesso ai
servizi è permesso anche a dispositivi di uso quotidiano (ad esempio cellulari e
PDA). Le applicazioni necessarie per supportare queste nuove esigenze sono, da
un punto di vista architetturale, non monolitiche bensì costituite da moduli
allocati in numerosi nodi della rete. I servizi offerti possono inoltre cambiare a
seconda del luogo in cui ci si trova: in questo modo le applicazioni si adattano a
differenti scenari di utilizzo. Le applicazioni quindi devono essere in grado di
cercare dinamicamente i servizi e adattarsi a nuovi ambienti. Le caratteristiche
che deve possedere un sistema di pervasive computing sono:
•
trasparenza nell’interazione (interaction trasparency);
•
conoscenza del contesto (context awareness);
•
cattura automatica delle esperienze (automated capture of experiencies).
Con il termine interaction trasparency, si intende l’utilizzo di una interfaccia che
elimina il più possibile le barriere tra l’utente e il lavoro che vuole realizzare.
Questo obbiettivo si raggiunge adottando tecniche di interazione che vanno al di
là del semplice uso di mouse, tastiera e piccoli monitor, ma si basano su
interfaccie non convenzionali volte a migliorare il feeling di utilizzo. Fioriscono
così interfaccie che utilizzano tecniche di riconoscimento della scrittura, dei gesti
e della voce.
La “conoscenza del contesto” permette all’applicazione di sapere dove, quando e
perché un’azione è stata intrapresa e utilizzare questa conoscenza pregressa per
16
completare nuovi compiti. Questa caratteristica è fondamentale in un mondo in
cui la mobilità degli utenti e quindi i cambiamenti di contesto sono molto
frequenti.
Con il termine “cattura automatica delle esperienze” si intende la capacità di un
dispositivo di memorizzare, gestire e rivedere le esperienze che accadono
durante il suo utilizzo. Deve essere quindi possibile memorizzare suoni,
immagini e commenti per poi riutilizzarli in momenti successivi.
1.5
Esigenze di positioning per nomadic computing
In una infrastruttura di nomadic computing l’aspetto rilevante è costituito
dalla conoscenza del contesto (context aware) . Con il termine “contesto” si
intende un certo numero di
fattori come l’identità di un utente, posizione
fisica corrente, condizioni atmosferiche, ora del giorno, data , etc. L’obbiettivo
è quello di acquisire ed utilizzare informazioni riguardanti il contesto di un
dispositivo
al fine di fornire servizi appropriati per un determinato gruppo di
persone, luogo, evento, etc. Si pensi, ad esempio, ad un telefono cellulare che, se
fosse
in grado di riconoscere la propria posizione all’interno di un teatro,
dovrebbe vibrare e non squillare durante la rappresentazione teatrale per non
arrecare disturbo agli spettatori.
L’aspetto critico del context awareness è senza dubbio quello del location
awareness ossia la conoscenza della posizione corrente di un utente. Con il
termine “posizione” si
indica generalmente la capacità di localizzare la
posizione di un oggetto in un predeterminato spazio. Per esempio la posizione di
un
aeroplano nel cielo è data attraverso la sua latitudine, longitudine ed
altitudine, un veicolo in una certa regione è localizzato con una grande
accuratezza grazie alla tecnologia GPS(Global Position System).
17
Molti studi
sono stati realizzati per la definizione di un sistema per il
rilevamento automatico della posizione dei dispositivi mobili. Spesso si
utilizzano metodi che consentono di ricercare soluzioni al problema con le
migliori “performance” in termini di precisione, accuratezza e scalabilità.
Tuttavia, non tutte le situazioni della vita quotidiana richiedono la massima
accuratezza
conseguibile. Ci sono una serie di applicazioni emergenti che
forniscono tipi differenti di servizi a seconda della zona in cui sono situati i
dispositivi. Per tali applicazioni è importante conoscere ad esempio in quale
zona, di un edificio, un dispositivo mobile si trovi e non le sue coordinate x,y,z
dello spazio.
L’obbiettivo del lavoro di tesi è quello di presentare un nuovo approccio per la
per la localizzazione dei terminali mobili in una infrastruttura di nomadic
computing che tenga conto di queste nuove esigenze.
Si vuole delineare, pertanto, una architettura che consenta di caratterizzare la
posizione di un dispositivi mobile, non in termini di coordinate spaziali ma
semplicemente attraverso la zona in cui si sta operando. Ciò sarà sufficiente per
l’accesso ai servizi.
1.6
Scenario applicativo considerato
Per esporre l’approccio proposto faremo riferimento ad uno scenario
costituito da una visita guidata in un museo. Un generico turista è dotato di un
dispositivo mobile, ad esempio un PDA, grazie al quale ha la possibilità di
ottenere informazioni audio su ciò che incontra nel corso dei suoi spostamenti
nello spazio fisico costituito dalle varie stanze dell’ edificio.
E’ evidente che la descrizione audio illustrante le opere d’arte dovrà essere, nel
corso delle visita,
coerente con la posizione del visitatore fornendo
l’illustrazione audio appropriata a quanto esposto in
18
ciascuna sala del museo.
L’individuazione della posizione del visitatore ,munito del suo PDA, assume
rilevanza fondamentale affinché
egli possa ascoltare la descrizione
corrispondente a ciò che incontra durante il suo percorso. E’ uno scenario che
rientra in una di quelle situazioni della vita quotidiana in cui non è richiesta la
massima accuratezza in termini di coordinate dello spazio. Al fine di poter
ascoltare l’audio relativo alle opere presenti sarà sufficiente poter distinguere la
posizione della persona con la precisione di una singola stanza.
19
Capitolo 2
L’approccio proposto
2.1
Introduzione
La proliferazione dei dispositivi mobili e delle reti wireless ha nutrito un
crescente interesse per i servizi basati sulla conoscenza della posizione; le
informazioni ed i servizi di cui un utente può disporre possono dipendere
della sua posizione fisica. Tuttavia, l’accuratezza richiesta nella rilevazione
della posizione, al fine di poter utilizzare i servizi disponibili, varia a seconda
del tipo di applicazione. Per esempio, localizzare un libro in un una libreria
richiede una precisione maggiore rispetto a quella necessaria per distinguere
in quale stanza, di un dato edificio, si trovi un individuo munito di un PDA.
Molte sono le
situazione della vita quotidiana nelle quali avere una
informazione approssimativa sulla posizione, rispetto ad una area definita, è
sufficiente per poter utilizzare i servizi disponibili in tale area. Quest’ultima
osservazione assume rilevanza fondamentale ai fini della scelta del sistema
che dovrà rilevare in automatico la posizione; infatti, se da un lato si ricerca
una soluzione al problema
che consenta le migliori
termini di precisione, accuratezza e scalabilità,
“performance” in
dall’altro sono presenti
vincoli economici e strutturali da cui non si può prescindere.
Il presente capitolo descrive alcune delle soluzioni presentate in letteratura,
per sistemi di positioning, cercando di evidenziarne l’ inadeguatezza in
relazione allo scenario applicativo preso in considerazione (tour in un
museo) che, va sottolineato, è rappresentativo di una ampia gamma di
20
applicazioni .
Viene, infine, introdotto
l’approccio proposto con la
definizione dell’architettura generale dell’infrastruttura.
2.2
Suluzioni per sistemi di positioning
Descriviamo alcune delle soluzioni per la localizzazione di terminali
mobili prese in esame nel campo della ricerca.
2.2.1 Sistema di localizzazione basato su radio-frequenza (RF) [1]
E’ un sistema per la localizzazione degli utenti in un edificio basato su radiofrequenza . L’ esperimento è stato realizzato in un ambiente di dimensioni
43,5 x 22,5m in cui sono state dislocate tre stazioni basate su Pentium,
equipaggiate di adattatori wireless, ed un
host mobile. L’esperimento
prevede una prima fase di off-line in cui vengono memorizzate informazioni
sull’intensità del segnale ricevuto dall’host mobile per ciascuna stazione
base. In particolare vengono memorizzate tuple del tipo (x,y,d,ssi) dove x,y
rappresentano la posizione dell’host mobile fornite dall’utente cliccando su
una mappa del piano dell’edificio, d la direzione, e ssi l’intesità del segnale
ricevuto da ciascuna
stazione fissa a partire dalla posizione indicata
dall’utente. In pratica si definisce una griglia bidimensionale nel quale viene
suddiviso lo spazio. A seconda del numero di punti considerati si avrà una
griglia più o meno stretta.
Segue, poi, la fase di on-line in cui si
monitorizzano i dati real time del terminale in movimento. Dato un set di
misure dell’intensità del segnale, misurato da ciascuna stazioni base, viene
effettuata una
stima
della
posizione utilizzando
l’approccio
della
triangolazione (cfr 3.4). Nell’ultima fase si confronta la posizione stimata
con i dati precedentemente memorizzati. Il problema si sposta, quindi, nella
scelta dell’algoritmo da utilizzare al fine di avere il miglior risultato in
termini di “match” dell’esatta posizione con quella stimata. In tal caso viene
calcolata la distanza tra i dati real time e ciascuna tupla dei dati off-line. Il
risultato dell’algoritmo sarà dato dal valore che minimizza la distanza.
21
2.2.2 Sistema di posizionamento indoor “DOLPHIN” [2]
Il progetto “DOLPHIN” (Distribuited Object Locating System for
Physical-space Internetworking) nasce dall’osservazione che, generalmente,
i sistemi di posizionamento, in ambiente indoor, basati su segnali ad
ultrasuono o radio-frequenza, richiedono delle pre-configurazioni di tipo
manuale relative alle posizioni di riferimento delle stazioni, al fine di
determinare la posizione degli oggetti con precisione. Ciò comporta dei costi
di setup e di gestione che potrebbero essere inaccettabili in caso di larga scala
come ad esempio un edificio di uffici. Nel sistema
“DOLPHIN”
la
posizione degli oggetti è determinata considerando soltanto un piccolo
numero di stazioni di riferimento.
L’algoritmo alla base del sistema è di tipo iterativo ed è incentrato su un
meccanismo che consente di individuare la posizione dei vari nodi passo
dopo passo. Per esempio, in figura 2.1, il nodo D può determinare la propria
posizione ricevendo segnali ad ultrasuono dai nodi di riferimento A, B e C
(sono nodi la cui posizione è fissa e predeterminata). I nodi E ed F non
possono ricevere i segnali ad ultrasuono da tutti i nodi di riferimento per la
presenza di un ostacolo (nel caso dell’esempio c’è la presenza di un muro).
Una volta nota la posizione di D, ed il nodo E riceve il segnale da D, E potrà
calcolare la sua posizione usando le distanze tra i nodi B,C e D. In maniera
iterativa, note le posizioni di D ed E si potrà determinare la posizione di F
utilizzando i nodi C,D ed E.
Ci sono due principali vantaggi in tale meccanismo. Primo, per determinare
la posizione di tutti gli altri nodi il sistema richiede la conoscenza iniziale di
soli pochi nodi (minimo tre). Secondo, i nodi possono determinare la propria
posizione anche se non possono ricevere direttamente dai nodi di riferimento
il segnale ad ultrasuono.
22
Figura 2.1- Il sistema “DOLPHIN”
2.2.3 Esperimento di localizzazione con Bluetooth [3]
In questo esperimento è utilizzato lo standard Bluetooth come tecnologia
wireless per il positioning. L’idea è quella di localizzare i dispositivi mobili
sulla base della potenza ricevuta a partire da stazioni fisse Bluetooth. Ciò
viene supportato dalla possibilità di misurare il livello di potenza ricevuto, in
maniera indiretta, attraverso la lettura del valore di RSSI (Received Signal
Strength Indication) memorizzato in un registro hardware. Il livello di
potenza ricevuto può essere a sua volta utilizzato per ottenere una stima
della distanza utilizzando un modello di propagazione di onde radio come
mostrato nella (1)
d = 10^
PTX − PRX + GTX + G RX − X a +
20 log(λ ) − 20 log(4π )
23
/(10n)
(1)
dove PRX (dBm) e PTX (dBm) sono i livelli di potenza del ricevente e del
trasmittente
GTX (dBi) e G RX (dBi) sono
i
guadagni
di
antenna
rispettivamente del trasmittente e del rivenente, λ (m) è la lunghezza d’onda
e d è la distanza tra trasmittente e ricevente. L’esponente n denota l’influenza
di muri o altri ostacoli. L’errore viene incluso in X a che è una variabile
aleatoria normale con a deviazione standard.
Viene utilizzato, inoltre, una estensione del filtro di Kalman (EKF) per
calcolare la posizione a partire dalle stime delle distanze valutate secondo la
(1). Tele filtro consente di stabilire la posizione attuale “stimata”, per poi
effettuare un predizione su posizione future.
2.3
L’approccio proposto
Generalmente, in molti lavori presenti in letteratura (come anche per
alcuni di quelli precedentemente illustrati) , per determinare la posizione di
un terminale mobile, si adotta un approccio basato sulla triangolazione di
misure ottenute mediante una delle possibili tecniche di localizzazione (cap
3).
Nello scenario ipotizzato un approccio di questo tipo è inadeguato per i
seguenti motivi:
•
non è robusto nei confronti di interferenze dovute alla presenza di
ostacoli, come ad esempio muri, o di segnali di frequenza simile;
•
la presenza di molti dispositivi per realizzare il positioning
e/o
di
modelli di stima molto complessi determinano un aumento dei costi
dell’intera infrastruttura;
24
•
vi è la presenza di errori di misura che sono linearmente dipendenti
dall’intensità del segnale ricevuto dal dispositivo mobile.
Come già evidenziato, sono molte le applicazioni emergenti che forniscono
servizi differenti in funzione delle aree in cui sono situati i terminali mobili. In
un tale contesto, la massima accuratezza conseguibile, nella determinazione
della posizione di tali dispositivi, non rappresenta un vincolo da cui non poter
prescindere. L’accesso ai servizi, può essere garantito anche attraverso una
semplice stima approssimata
delle zone in cui sono dislocati i terminali mobili.
Si può delineare, quindi, una architettura che ci consenta di caratterizzare la
posizione di un dispositivo mobile, non in termini di coordinate spaziali ma
semplicemente attraverso l’identificazione della zona in cui si sta operando.
Pertanto, nello scenario ipotizzato, consideriamo la possibilità di accedere
alla informazioni attraverso una tecnologia wireless. I dispositivi mobili,
PDA, laptop o smartphone, potranno connettersi, ad esempio, alla
infrastruttura di rete presente nel museo attraverso i sensori dislocati nelle
diverse sale, come illustrato in figura 2.2. Le informazioni audio, sulle opere
presenti in ciascuna di esse, devono poter essere attivate dall’utente ogni qual
volta si entra in una nuova sala.
Sensori
Figura 2.2 - Sale del museo con i sensori per ciascuna di esse ed utente
munito di dispositivo mobile.
25
E’ evidente che l’identificazione della posizione di un dispositivo mobile, è
equivalente alla individuazione della stanza in cui il dispositivo stesso sta
operando. Ciò garantirà la possibilità, da parte del visitatore, di attivare il
corretto contenuto audio nel giusto momento.
Possiamo, pertanto, definire il nostro approccio di localizzazione come “zoning”,
inteso come l’individuazione in ciascun momento delle
stanze occupate
durante tutto il percorso della visita.
La soluzione si basa sulla possibilità di valutare la potenza del segnale ricevuto,
dal dispositivo mobile, da ciascun sensore presente nel range d’azione e
connesso al terminale stesso. In pratica il dispositivo mobile acquisisce
informazioni sulla intensità di tutti i segnali rilevabili. Tali intensità
sono
evidentemente funzione della distanza tra dispositivo mobile e sensori
raggiungibili; al crescere della distanza diminuisce l’intensità del segnale. La
sola informazione sulla potenza ci consente di determinare la sala nel quale il
dispositivo sta operando; infatti una semplice comparazione dei livelli di potenza
consente di stabilire il valore massimo e di conseguenza il sensore prossimo
alla unità mobile. Individuata la zona (intesa come sala del museo), viene data la
possibilità al visitatore di attivare il servizio audio disponibile per sala oggetto
della visita.
Questo tipo di soluzione è avvalorata dai seguenti motivi:
•
la presenza di un sensore per ciascuna sala consente una riduzione degli
effetti dovuti alla presenza di ostacoli come, ad esempio, i muri, e degli
errori di misura
che spesso caratterizzano le soluzioni basate sulla
triangolazione. Infatti, se la triangolazione, per la presenza muri spessi e
di forti interferenze, richiede sensori sofisticati e/o più di tre acces point
per migliorare l’accuratezza con conseguente aumento dei costi
dell’infrastruttura, la soluzione proposta, data la presenza stessa di muri
che tendono ad attenuare segnali provenienti dai sensori posti nelle sale
adiacenti (cfr 3.3), facilita l’individuazione della zona in cui è presente il
terminale mobile;
26
•
La presenza di ostacoli tendono a ridurre anche le interferenze dovute
alla possibile presenza di segnali radio della stessa frequenza . Per di più,
non essendo
interessati alla esatta posizione del dispositivo mobile,
l’approccio adottato presenta una maggiore tolleranza agli errori e non
richiede pesanti attività computazionali.
•
2.4
L’architettura generale
L’architettura proposta è stata progettata in modo da fornire un servizio di
positioning che sia indipendente dai dispositivi utilizzati e dalla tecnologia di
comunicazione wireless. Per la sua implementazione e sperimentazione , il cui
dettaglio verrà definito nel cap. IV, si è fatto riferimento ad una infrastruttura
basata sullo standard Bluetooth.
La figura 2.3 illustra il modello concettuale della architettura proposta.
User Layer
Zoning Layer
Network Layer
Measurement Layer
Connettivity Layer
Bluetooth
Figura 2.3 - Modello architetturale della soluzione proposta
27
Il livello più basso è il livello rete (Network Layer), costituito da due sottolivelli.
Il primo è rappresentato dal livello connessione (Connectivity Layer), contenente
le funzionalità specifiche disponibili in Bluetooth per la ricerca e la creazione di
una connessione con tutti i sensori Bluetooth raggiungibili.
Un dispositivo
raggiungibile dal terminale mobile rappresenta un qualsiasi sensore di rete
situato nel range radio del dispositivo mobile e che sia in grado di accettare la
richiesta di connessione.
Il secondo sottolivello consente di leggere l’intensità dei segnali ricevuti da tutti i
sensori posti nelle vicinanze (Measurement Layer); il livello della potenza del
segnale ricevuto può essere stimato in maniera indiretta attraverso la lettura del
Received Signal Strength Indication (RSSI)(cfr 3.5.6).
Il livello “zona” (Zoning Layer), attraverso una comparazione dei diversi valori
di intensità ricevuti dai vari sensori, consente di trasformare le informazioni
disponibili al livello Measurement in una indicazione sulla posizione occupata
dal dispositivo mobile .
Il livello superiore è il livello utente (User Layer); in questo livello viene fornita
all’utente l’indicazione sulla sala è oggetto della visita con i relativi servizi di cui
può disporre.
28
Capitolo 3
Analisi delle tecnologie per il positioning dei
dispositivi mobili
3.1
Introduzione
Con il crescente sviluppo delle reti wireless e dei dispositivi mobili che
hanno
portato ad affiancare alle infrastrutture di reti classiche nuove
infrastrutture di reti ibride, definite di Nomadic Computing, affiora subito il
concetto di “mobilità”, assenza di un luogo fisico e fisso da cui avere accesso al
mondo digitale.
Viene spontaneo allora il pensiero della possibilità di fornire servizi
basati sulla posizione dell’utente all’interno di un ambiente più o meno vasto.
Ecco quindi sorgere la necessità di strumenti che permettano la localizzazione di
un utente; o meglio, del terminale mobile che lo accompagna. In tal modo si apre
un vasto scenario di Location Based Services (LBS) ad alto valore aggiunto, sia
per l’utente che per il fornitore stesso del servizio.
Scopo di questo capitolo è descrivere i principi sui quali si basa la
localizzazione di un terminale mobile, le tecniche possibili ed alcune
applicazioni che ne fanno uso.
3.2
Sistemi di coordinate
29
Come è noto dalle classiche conoscenze di geometria, ogni posizione
deve essere riferita ad un particolare sistema di riferimento [1]. Ad esempio è
possibile affermare che la posizione di un oggetto è data dalle coordinate x,y,z
rispetto ad una origine prefissata, oppure che è a x,y,z rispetto ad un altro
oggetto. Nei sistemi di localizzazione questo problema deve essere affrontato in
modo sistematico ogni qualvolta ci si trova nella situazione di dover determinare
(e/o comunicare) la posizione di un oggetto. Sinteticamente i metodi usati ed
utilizzabili sono due:
•
coordinate locali: ossia un sistema di coordinate scelto a priori
localmente rispetto all’ambiente nel quale si opera e mediante il quale
si identificano tutti gli oggetti di interesse;
•
coordinate geografiche: in tal caso il sistema di riferimento si basa
sulla Terra, e la posizione individuata è univoca su tutto il pianeta. Di
conseguenza, in tal caso, c’è possibilità di comprensione tra i più
disparati interlocutori, in quanto un sistema di tal genere è condiviso
ovunque.
La preferenza ad uno od all’altro avviene in base all’infrastruttura esistente e
agli strumenti utilizzati, ai dati disponibili,
ai vincoli dati da precedenti
decisioni. Ad esempio, se si utilizza il GPS (cfr. 3.6.7) non è possibile scegliere
un qualsiasi sistema di coordinate, in quanto tale sistema prevede l’utilizzo di
ricevitori che forniscono la posizione in termini geografici; sarà quindi
obbligatorio, nell’implementazione di un sistema di tal genere, utilizzare
coordinate di tipo geografico, congruentemente con le informazioni fornite dal
ricevitore.
3.2.1 Coordinate Relative ed Assolute
Oltre alla distinzione geografiche/locali, i sistemi di coordinate possono
essere suddivisi nelle seguenti due categorie:
30
•
coordinate relative: ogni oggetto possiede il proprio sistema di
riferimento, non valido per gli altri;
•
coordinate assolute: si ha un unico sistema di riferimento
condiviso e interpretabile da tutti gli oggetti dello spazio di
interesse;
3.3 Modellazione dell’ambiente di interesse
In tutti i casi in cui si vuole localizzare un oggetto all’interno di un ambiente
più o meno vasto, è necessario avere di quest’ultimo una descrizione anche
sommaria, in modo da considerare aspetti critici nella definizione della
tecnologia da utilizzare. I problemi che nascono nell’affrontare lo sviluppo di un
sistema di localizzazione, infatti, sono in parte dovuti allo specifico ambito in cui
ci si muove.
Si vedranno, nel proseguo del capitolo, metodi che derivano, in diversi modi,
la posizione da caratteristiche fisiche dei segnali misurati. Importanza
fondamentale nella localizzazione di un terminale mobile è quindi l’ambiente nel
quale ci si muove e come questo viene modellato in termini, ad esempio, di
propagazione di un segnale elettromagnetico in presenza di ostacoli.
Gli errori che sorgono da tale misura indiretta sono da ricercarsi nei seguenti
tre aspetti:
→ errori dovuti alla precisione e sensibilità del sistema di rilevamento
dei segnali da misurare;
→ errori dovuti alla conversione di queste misure in caratteristiche
geometriche, dovuti a modellazione dell’ambiente in modo più o
meno preciso;
→ errori dovuti all’algoritmo vero e proprio in termini di accuratezza,
precisione: ad esempio nel caso della soluzione di equazioni non
lineari mediante approssimazioni.
31
Un problema molto importante di cui tener conto
è quello del cosiddetto
“Multipath Fading” [14], ossia la presenza di cammini multipli del segnale dal
trasmettitore al ricevitore. Esso altera in maniera sensibile
il segnale al
ricevitore, dando parecchi problemi in fase di rilevamento della potenza
effettivamente ricevuta attraverso il cosiddetto “Direct-Line-Of-Sight” (DLOS),
ossia il contatto diretto che vi è fra trasmettitore e ricevitore. Tale segnale esiste
sempre, ma può essere così debole da non essere rilevabile. Al contrario le altre
vie di comunicazione sono dette “Non-Direct-Line-Of-Sight” (NDLOS). Per
alcuni sistemi il problema del Multipath non è rilevante, in quanto il segnale
DLOS è disturbato solo in minima parte dagli altri segnali “spuri”. Questo
avviene, ad esempio, nei sistemi outdoor con una copertura adeguata. Nei
sistemi indoor, viceversa, questo è un fenomeno sempre presente e di esso
bisogna tenere conto.
Se pensiamo sempre ad ambienti Indoor nasce quindi il problema della
modellazione degli “ostacoli” che il segnale deve attraversare, tipicamente i muri
tra le varie stanze.
3.4 Triangolazione
In molti sistemi, l’opera di localizzazione è basata sulla cosiddetta
“triangolazione” di informazioni provenienti da terminali dell’infrastruttura. La
triangolazione usa proprietà geometriche e si presenta sotto due forme, chiamate
“Lateration” e “Angulation”. Tali sistemi possono essere utilizzati, nel caso più
generale, in spazi n-dimensionali.
32
3.4.1
Lateration
La localizzazione del punto incognito X si basa sull’utilizzo di distanze
relative rispetto a punti noti e non allineati. In ambito 3-dimensionale, i punti
necessari saranno 4. In figura la semplice descrizione di tale tecnica:
Figura 3.2 – Lateration bidimensionale
Vincoli dipendenti dallo specifico dominio applicativo potrebbero in alcuni casi
determinare una riduzione dei punti da considerare. Ad esempio se i punti noti
sono sempre “sopra” al punto incognito, ad esempio sul soffitto di una stanza
come nel sistema Active-Bat (cfr 3.6.3), sono necessarie solo 3 distanze relative
per effettuare la lateration e non 4. In tutti i casi, comunque, il problema è
stabilire le distanze relative; ciò può avvenire in modo diretto od indiretto. Il
modo diretto è ovviamente riconducibile alla misura classica di distanze, ma
risulta essere impraticabile in un sistema automatico di rilevazione. Il metodo
indiretto, invece, sfrutta fenomeni fisici mediante i quali è possibile, con l’uso di
modelli, determinare la distanza relativa; ad esempio (cfr. 3.5.6) l’attenuazione
della potenza del segnale o il suo time-of-flight (ToF) (cfr. 3.5.3). La figura 3.2 si
riferisce a casi teorici, nei quali le misure sono esattamente determinabili e non
affette da errori di sorta. Nelle applicazioni pratiche, al contrario, ci si scontra
con errori di diverso tipo e natura che portano ad avere un “range” spaziale nel
quale il punto incognito può trovarsi (come mostrato in Figura 3.3).
33
Figura 3.3 – Lateration bidimensionale con dati spuri
3.4.2
Angulation
L’Angulation è simile alla Lateration, eccettuato il fatto che utilizza angoli al
posto di distanze. In generale, nel caso bidimensionale, è necessario
conoscere una distanza (ad esempio quella fra gli oggetti dell’infrastruttura) e
due angoli, come mostrato in figura:
Figura 3.4 – Angulation bidimensionale
In tal caso quindi il problema si sposta alla misura degli angoli. Un esempio può
essere un sistema basato su più antenne, poste a distanza nota l’una dall’altra,
che captano il segnale e riescono a calcolare l’angolo di arrivo del segnale stesso.
In caso 3-dimensionale servono, in generale, una lunghezza, due angoli e una
misura di azimuth (ovvero altezza sopra l’orizzonte). Anche in tal caso, come
34
nella Lateration, ci si trova in generale di fronte a stime non precise degli angoli,
il che porta alla seguente situazione:
Figura 3.5 – Angulation bidimensionale con dati spuri
3.5 Metodi di Localizzazione
Definiti i tipi di rappresentazione delle coordinate su un piano
bidimensionale, occupiamoci di come le coordinate incognite di un oggetto
possano essere rilevate in modo automatico da un sistema informatico[7].
Nei sistemi di localizzazione che verranno analizzati saranno sempre presenti i
seguenti componenti:
•
un sistema di riferimento, condiviso da tutti gli attori presenti nel
sistema;
•
un’infrastruttura composta da terminali dalla posizione nota
all’interno del sistema di riferimento prescelto;
•
uno o più terminali mobili da localizzare;
•
un sistema di comunicazione, tipicamente wireless
•
un algoritmo che effettua l’operazione vera e propria di
localizzazione.
Queste caratteristiche non permettono di modellare un sistema di tipo “ad-hoc
network”, ossia dove tutte le entità risultano essere mobili e con posizione
35
ignota. Moltissima letteratura è presente in questo vasto ed attuale campo; nel
seguito si vedrà un algoritmo di base di queste tecniche (cfr. 3.6.10).
3.5.1 Una tassonomia dei sistemi di localizzazione
Nel seguito del capitolo ci si soffermerà sulle varie metodologie che è
possibile utilizzare per implementare un algoritmo di localizzazione.
Nella letteratura, tipicamente, si suddividono i sistemi di localizzazione
sulla base dell’entità che effettua il posizionamento [5], [6]. Si introduce quindi
la seguente classificazione:
•
sistemi di localizzazione “Network-based”, ove è l’infrastruttura che
calcola e conosce la posizione del terminale mobile, comunicandola
successivamente a quest’ultimo;
•
sistemi di localizzazione “Handset-based”, ove, viceversa, è il
sistema mobile stesso che riesce a calcolare la propria posizione
mediante le informazioni inviategli dai terminali componenti
l’infrastruttura.
Come apparirà chiaro durante la descrizione dei vari sistemi di localizzazione,
però, tale suddivisione non è sempre possibile, dipendendo molte volte più dalla
specifica implementazione che dal sistema teorico utilizzato. Inoltre non sono
mutuamente esclusive, ma possono coesistere in soluzioni ove sono applicati più
metodi di localizzazione.
Un’altra caratteristica è l’ambito di applicazione della tecnologia:
•
outdoor: tecnologie che permettono la localizzazione nell’ambito di
ambienti aperti;
•
indoor: tecnologie che, viceversa, permettono la localizzazione in
ambienti chiusi;
36
Un’ultima, importante, distinzione è come l’apparato di localizzazione
interagisce con la struttura esistente: si hanno quindi sistemi “overlay”, ossia
“costruiti sopra” una rete già esistente, o tecniche “integrated”, ovvero che
utilizzano in modo massiccio le caratteristiche delle rete con la quale sono state
costruite e pensate.
Oltre quelli già visti, altri e svariati parametri definiscono un sistema di
localizzazione; di seguito un breve elenco dei più importanti:
•
accuratezza del sistema, ossia il massimo dettaglio in termini di
posizione ottenibile dal sistema;
•
precisione,
ossia
quante
volte
il
sistema
risponde
con
quell’accuratezza; ad esempio, il sistema “Active Bat” (cfr.3.6.3)
ha un’accuratezza di 9 cm ed una precisione del 95%;
•
scalabilità: il numero di “elementi” localizzabili e quante risorse
sono necessarie a tal fine;
•
costi in termini di tempo, spazio occupato dall’infrastruttura e di
capitali impiegati;
•
limiti della tecnologia impiegata;
•
adattabilità a condizioni inattese (robustezza del sistema).
Nel seguito si prenderanno in considerazione quelle tecnologie di
“Location Sensing” che permettono di misurare indirettamente la posizione
incognita del terminale.
3.5.2 Proxymity
37
Il sistema di localizzazione prevede di determinare la posizione di un oggetto
mediante la sua “prossimità”, “vicinanza” rispetto a locazioni note. La
presenza dell’oggetto deve essere percepita dal sistema mediante fenomeni
fisici dalla portata limitata. I possibili approcci sono 3:
•
contatto fisico: in tal caso l’infrastruttura può essere costituita da
sensori a contatto come pulsanti, touch screen ecc…;
•
monitoraggio dei punti di accesso al sistema: in tal caso si ha a
che fare con un infrastruttura composta da terminali ai quali
l’oggetto si “connette” in base alla vicinanza. Se la connessione è
individuata, allora si può stabilire in prima approssimazione la
“zona” in cui si trova l’oggetto;
•
utilizzo di informazioni possedute dall’oggetto: in quest’ultimo
caso l’oggetto comunica nei modi più svariati informazioni sul
proprio stato all’infrastruttura. Ad esempio terminali pubblici,
bancomat, ma anche il “tele-pass” autostradale ecc…
3.5.3 Time-of-Flight
Il sistema “Time-of-Flight” (ToF) spesso chiamato anche “Time-ofArrival” (ToA) si basa sul tempo che impiega il segnale a percorrere la distanza
che separa trasmettitore e ricevitore, di cui uno abbia posizione nota.
Conoscendo la velocità V del segnale è ovviamente possibile ricondursi alla
distanza D = V*ToF. Il segnale può essere di ogni genere, dalle onde sonore ad
ultrasuoni, a segnali radio. In tale situazione i “clock” di trasmettitori e ricevitori
devono essere tutti perfettamente sincronizzati (problema non banale) ed in più
ad alta risoluzione, in quanto le onde elettromagnetiche “viaggiano” alla velocità
della luce C (pari a circa 299.792,5 km/sec ). Se, come tipicamente avviene, le
distanze non sono molto grandi, il tempo da misurare è estremamente basso
(dell’ordine dei nS).
Nell’utilizzo di questo metodo è necessario altresì tener conto di molti
fenomeni quali riflessione e rifrazione e quindi del fenomeno già descritto del
Multipath. Considerando poi più punti e più segnali, è possibile triangolare le
38
informazione per ottenere la posizione incognita. E’ tipicamente un sistema di
tipo “Netwok-”, ossia la computazione avviene nelle “stazioni fisse”. Di
conseguenza risulta essere economico in quanto non necessita della reingegnerizzazione dei terminali mobili.
3.5.4
Time Difference Of Arrival
Estremamente simile al metodo precedente, TDOA è basato sempre sulla
misura del Time-of-flight e risulta essere una tecnologia Network-based. Il
funzionamento, illustrato in figura [3.25], si basa sulla differenza fra i tempi
misurati dal terminale mobile relativi ai segnali provenienti, anche in tal caso, da
tre diverse stazioni. Calcolate due “differenze” mediante i Time-og-flight dei tre
segnali disponibili, e note le coordinate dei trasmettitori, è possibile ottenere due
curve iperboliche con i fuochi nelle rispettive stazioni fisse di origine, la cui
intersezione fornisce le coordinate del terminale.
Figura 3.6 – Lateration iperbolica
Il vantaggio principale di una soluzione di questo tipo rispetto al ToA è che
diviene necessario sincronizzare unicamente i clock delle stazioni fisse, e non
quello del terminale mobile. In questo caso, come è possibile notare, avviene una
lateration “particolare”, non tra sfere ma tra iperbole; anche in tal caso,
comunque, la misura è in generale affetta da errori. Anche questo tipo di tecnica
di localizzazione soffre dei problemi già descritti di Multipath.
39
3.5.5
Angle-of-Arrival
In tal caso (AoA) quello che viene misurato è l’angolo di arrivo del
segnale per poi effettuare la già citata angulation. E’ necessario quindi avere
informazioni su due stazioni. Un modo per realizzare questo metodo, tipicamente
Network-based, è quello di dotare le antenne di un “array” di ricevitori, in modo
da capire quale di questi ha ricevuto il segnale migliore e calcolare quindi
l’angolo di arrivo dello stesso. Il network, conoscendo le distanze relative fra le
postazioni fisse riesce quindi a calcolare la posizione del terminale. Ovviamente
in questo caso la precisione del sistema si basa sull’accuratezza con cui viene
calcolato l’angolo di arrivo, e , di conseguenza, sul numero di elementi presenti
negli array delle antenne.
Figura 3.7 – Metodo di funzionamento AoA
3.5.6
Received Signal Strenght Indication
L’intensità di un segnale, come noto, decresce all’aumentare della
distanza
dalla
sorgente
emittente
[26],
dando
luogo
al
fenomeno
dell’attenuazione. Dato un modello che leghi attenuazione A e distanza D e nota
40
la potenza P di partenza, è quindi possibile stabilire la distanza relativa, ad
esempio, fra un elemento noto e l’oggetto mobile. Avendo a disposizione più
elementi noti, mediante triangolazione (lateration), sarà poi possibile determinare
l’esatta posizione dell’oggetto. Questo è il metodo RSSI, nel quale si assume di
avere a disposizione un modello nel quale potenza_ricevuta = f(distanza). Ad
esempio, per un segnale radio emesso in un ambiente libero da ostacoli e da
rumore è attenuato di un fattore 1/D2 [26] vale la relazione:
P(d )[dBm] = P(d 0 )[dBm] − 20 log(
d
)
d0
Ovviamente questo caso è una semplificazione notevole di un ambiente
indoor, cosa che porta inevitabilmente ad un peggioramento delle performance,
a meno di raffinamenti del modello di descrizione dell’ambiente. Problemi come
il “Multipath Fading” e l’attenuazione dovuta ad ostacoli dovrebbero infatti
essere tenuti in debita considerazione.
Nelle sperimentazioni pratiche questo sistema ha comunque dimostrato una
intrinseca fragilità rispetto ai problemi summenzionati, con particolare
riferimento al rumore che si “somma” al segnale. Sarebbe necessaria, infatti,
un’attenta analisi dell’ambiente, cosa non sempre possibile. Un metodo per
ovviare a tale inconveniente è quello di affiancare a tale metodo la scene analisys
(cfr. 3.5.7) come avviene nel metodo RADAR (cfr. 3.6.9). Oppure utilizzare
strumenti di calibrazione e “profiling” dell’ambiente, solitamente basati sul
“filtro di Kalman” [23] [27].
3.5.7 Scene Analisys
La presente tecnica, chiamata anche con il nome di “Finger-Print”, si
prefigge di collocare l’oggetto nella sua esatta posizione, considerando una serie
di caratteristiche (“feature”) dell’ambiente di riferimento prese in punti prefissati
41
durante una fase detta di “off-line”, ossia staticamente determinate mediante
un’ispezione dell’ambiente stesso. Tali features non fanno altro che semplificare
l’ambiente per la successiva fase “on-line”. In tale fase si effettua il
monitoraggio istantaneo delle features dell’oggetto mobile e le si confrontano
con i dati “off-line”. Mediante un modello che descrive l’ambiente nel quale ci
troviamo, ed un algoritmo che lega dati off-line ed on-line si può arrivare a
determinare la posizione stimata del terminale. Il metodo più banale, comunque
applicabile ed applicato, risulta essere una semplice ricerca esaustiva, mediante
la quale si può arrivare a determinare a quale dei punti prefissati è più vicino
l’oggetto in questione mediante algoritmi cosiddetti di Pattern Matching.
Figura 3.8 – sistema di “Scene Analisys”: fase “On-line”
In tal caso, quindi, si ha una discretizzazione dello spazio, nel quale la precisione
dipende da quanto la “griglia” di punti considerati è “fine”. Numerose varianti
sono comunque presenti, al fine di migliorarne le prestazioni.
Un esempio di questo metodo di scene analisys è la ricerca in base ad
immagini dell’ambiente; avendo a disposizione una telecamera montata su un
veicolo, si potrebbero, nella prima fase, memorizzare foto in particolari punti e,
nella seconda fase, confrontare una foto ottenuta “dinamicamente” con l’intero
Database di immagini, scegliendo la “più simile”.
Il vantaggio di un sistema di tal genere è che è possibile arrivare alla
determinazione della posizione senza considerare misure indirette di angoli e
distanze, cosa che può comportare la costruzione di un modello matematico
complesso (ad esempio come la potenza ricevuta
42
varia al variare della
distanza in ambienti con ostacoli rilevanti e/o rumore casuale). Il metodo può
essere applicato in modalità sia Network-based che Handset-based. La prima
soluzione è comunque preferibile in quanto si ha la necessità di avere a
disposizione dati, modelli e potenza di calcolo che su un terminale
potrebbero non essere ottenibili con facilità. Uno svantaggio è che la
calibrazione off-line va ripetuta in caso di cambio dell’ambiente di
riferimento o delle condizioni globali del sistema.
3.5.8
Miglioramenti del sistema di localizzazione
Visti i sistemi base di localizzazione è opportuno notare come tali sistemi
siano solo il principio di un apparato di localizzazione che voglia avere
performance di precisione accettabili. Alcuni metodi di miglioramento sono i
seguenti, anche se a volte possono risultare inapplicabili:
•
utilizzo di un numero maggiore di stazioni fisse delle minime
necessarie (rispetto ad un metodo di copertura minima della
superficie), in modo da avere un maggior numero di misure
attraverso le quali effettuare la triangolazione, ossia la citata
Multilateration (cfr. 3.4);
•
utilizzo di diversi metodi e comparazione, anche in tal caso, dei
vari risultati; ovviamente più i metodi sono indipendenti tra loro,
più la successiva comparazione potrà diminuire il livello di
imprecisione di ciascun metodo preso singolarmente; infatti ogni
tecnologia ha la sua tipologia di distribuzione statistica degli
errori [10]. Ad esempio sono applicabili (e applicate) soluzioni
AoA + RSSI, AoA + TDOA, EOTD + AGPS…;
•
utilizzo di algoritmi “History Based”, ove si tiene traccia di N
posizioni precedenti, effettuando l’aggiornamento della posizione
anche sulla base delle informazioni correnti. In tal caso si ha
necessità
di
memorizzare
un
data-set
di
informazioni,
aggiornandolo ad ogni passo. Ad esempio, semplicemente sulla
43
base della posizione precedente, si potrebbe calcolare un range
massimo
di
variazione
(dipendente
dall’intervallo
di
campionamento), eliminando così eventuali risultati ambigui. Tale
pratica è ad esempio utilizzata nei sistemi di “Scene Analisys”;
•
nel caso di un sistema di localizzazione basato su un legame
segnale distanza, poiché il modello è difficilmente ottenibile in
modo preciso, si corre il rischio che il rumore “sovrasti”
l’informazione, dando luogo a risultati decisamente erronei nella
maggioranza delle misure .
Per ovviare a tale problema, un metodo è quello di tenere traccia
dei campioni precedenti, filtrando il segnale in real-time e
consentendo di stabilire posizione e velocità attuali “stimati”, per
poi effettuare una predizione su posizione e velocità future [22].
Questo lavoro può essere effettuato, ad esempio, dal filtro di
Kalman [23]; Il problema che sorge è un “ritardo” nella
predizione della posizione corrente:
3.6 Sistemi esistenti
I recenti sviluppi della tecnologia “mobile” hanno fatto sì che si creassero
le condizioni per la nascita dei cosiddetti “Location Based Services” (LBS),
ossia servizi forniti a utenti mobili e basati sulla loro posizione. Di seguito una
tabella riassuntiva delle diverse tecnologie di localizzazione presenti attualmente
[10]; di questi, alcuni saranno brevemente descritti nel presente paragrafo.
In questa tabella sono presenti alcune indicazioni che è opportuno spiegare
brevemente:
•
phisycal / symbolic: indica se le coordinate fornite sono date in
termini di grandezze misurabili (Phisycal) come, ad esempio,
44
latitudine e longitudine, oppure se sono indicazioni di tipo simbolico
(Symbolic) mediante le quali si da un idea di dove si trova l’utente:
“vicino a…”, ”in… ” ;
•
absolute/relative: in tal caso si differenziano le coordinate in base al
fatto se sono condivise da tutti gli attori del sistema (Absolute), non
importa se locali o geografiche, oppure se ogni attore possiede un
proprio sistema di riferimento (Relative);
•
localized location computation: indica se la computazione avviene
direttamente sul terminale (ossia se è un sistema “Handset-based”);
•
recognition: indica se il sistema è in grado di “riconoscere” il
terminale (o solo alcune caratteristiche di questo) che deve essere
localizzato.
45
Figura 3.9 – Sistemi di localizzazione esistenti
46
3.6.1 Enhanced 911
Un’ulteriore motivazione che ha portato all’implementazione pratica di
sistemi LBS è stata la decisione, presa dalla statunitense “Federal
Communication Commission”(FCC) di emanare la “Phase II” della direttiva
cosiddetta “Enhanced 911” (E911) [8].
In tale direttiva si richiede espressamente che i gestori di telefonia mobile
mettano a disposizione infrastrutture (anche in collaborazione con i venditori di
dispositivi mobili) che permettano di localizzare una chiamata al servizio di
emergenza americano (numero telefonico: 911) con i seguenti parametri:
•
il 95% della chiamate effettuate da dispositivi mobili sia
localizzabile nell’arco di 150 metri;
•
il 67% della chiamate effettuate da dispositivi mobili sia
localizzabile nell’arco di 50 metri;
•
la localizzazione sia effettuata entro 30 secondi dall’inizio della
chiamata.
Analizzando vari sistemi, si può notare, da analisi sperimentali effettuate dagli
enti coinvolti, come la CGI-TA (cfr. 3.6.6) non sia sufficiente a raggiungere
questi obiettivi, mentre le tecniche utilizzate [9] sono sostanzialmente due: EOTD e A-GPS.
Ovviamente i requisiti dati dalla FCC, di obbligatoria applicazione, fanno sì che
questi sistemi siano utilizzabili anche per molti altri scopi. Ciò ha contribuito
fortemente all’interesse che si ha al giorno d’oggi sui suddetti LBS.
3.6.2 Active Badge
Primo prototipo di un sistema di localizzazione, l’Active badge [17], fu
sviluppato inizialmente dai “Olivetti Research Laboratory” e successivamente
dalla “AT&T Cambrige” [18]. Basato su tecnologia a raggi infrarossi IR,
consiste in una griglia di ricevitori posti all’interno dell’area di interesse
(tipicamente uno per stanza), e dei sensori indossati dagli utenti. Ogni sensore
trasmette un impulso (beacon) ogni 10 secondi contenente un identificativo
47
unico del sensore; questo viene intercettato da un ricevitore e quindi dal sistema
centrale (mediante polling su tutti i ricevitori) che ne determina la posizione in
base alla tecnica di prossimità. Nel caso specifico, infatti, viene considerato
unicamente il ricevitore che cattura il beacon. Ovvio problema di questo metodo
è l’uso dei raggi infrarossi, bloccati da ostacoli opachi e inadatti all’uso in
ambienti sottoposti alla luce diretta del sole o in presenza di luci fluorescenti.
Inoltre la granularità sia in termini di tempo (1 dato ogni 10 secondi per sensore)
sia in termini di spazio risultano essere mediocri per un sistema di
localizzazione.
Altro sistema basato sulla tecnologia IR è quello utilizzato intensivamente
nella “computer animation”, nella quale i sensori sono collocati sulle parti
mobili del corpo umano e i ricevitori ne “seguono i movimenti”. I limiti sono
sempre quelli descritti precedentemente, ma comunque questa risulta una valida
soluzione per il particolare campo applicativo.
3.6.3 Active Bat
Più recente rispetto all’Active Badge, l’Active Bat [19], sviluppato sempre
dai laboratori AT&T, utilizza come infrastruttura sensori a ultrasuoni, mentre
come tecnica di localizzazione la Lateration mediante Time-Of-Flight. Anche in
questo caso gli utenti indossano dei trasmettitori che emettono impulsi ad una
griglia di sensori posti sul soffitto. Tali sensori sono connessi al network fisso e
tra di loro mediante una rete “wired”. Il sistema centrale provvede a
sincronizzare i ricevitori mediante un segnale a radio-frequenza di reset; inoltre
lo stesso segnale è inviato contemporaneamente anche ai trasmettitori che
impostano ti. Ricevuto il segnale di reset, i trasmettitori emettono un segnale ad
ultrasuoni catturato da tutti i ricevitori mobili, che sono quindi in grado di
calcolare i vari ToF essendo a conoscenza di ti. Calcolate quindi localmente le
varie distanze, queste vengono mandate al sistema centrale che elabora i dati e
fornisce la posizione stimata del terminale.
48
Figura 3.10 – sistema Active Bat
Da notare che la posizione fornita è in termini di x,y,z (ossia
tridimensionale), sono necessari solo 3 sensori (cfr. 3.4.1). Sperimentalmente si è
ottenuta una precisione di 3 cm nel 95 % delle misure.
3.6.4 Cricket
Complementare al precedente Active Bat, il sistema Cricket Location
Support System [20] utilizza emettitori di ultrasuoni come infrastruttura montata
sul soffitto, mentre il ricevitore è indossato dall’utente. In tal modo si passa dal
sistema “Network-based” precedente ad uno “Handset-based”, dove il ricevitore
ha tutte le informazioni per rivelare la propria posizione sempre mediante
triangolazione dei segnali ricevuti (più precisamente dei loro ToF). Al fine di
sincronizzare i trasmettitori viene anche in questo caso utilizzato un sistema di
segnalazione basato su segnali a radio-frequenza. Anche se attualmente il
sistema risulta meno preciso dell’Active Bat, concettualmente non vi è alcuna
differenza; ciò porta a immaginare future implementazione più accurate. Al
momento attuale il sistema riesce a discriminare regioni di 4 piedi2 (meno di 1
metro2). Punti di forza del sistema sono la privacy, in quanto la posizione è
calcolata in modo decentralizzato, la scalabilità, in quanto non necessità di
49
potenza di calcolo su computer centrali, la possibilità di integrare il Cricket sopra
ogni rete esistente, essendo da questa indipendente. Infine il sistema riesce a
tollerare anche situazioni nelle quali si ha unicamente una informazione di
distanza. In tal caso, non essendo possibile altro metodo, la posizione è data in
base alla tecnica di “prossimità”, considerando l’unico segnale ricevuto.
3.6.5 Easy Living
Molti centri di ricerca stanno sperimentando sistemi di localizzazione basati
sulla tecnologia della “visione artificiale”. Un progetto degno di nota è l’Easy
Living [21] della Microsoft Research, che utilizza fotocamere 3D a colori
montate sui muri esterni dell’ambiente di interesse, per “catturare” frame
dell’ambiente ed effettuare il posizionamento. La visione stereo delle fotocamere
permette di effettuare la localizzazione, mentre le immagini a colori permettono
di mantenere l’identità delle persone in movimento mediante gli istogrammi di
colore. Gli obiettivi di questo progetto sono i seguenti:
•
mantenere la posizione e l’identità dei soggetti di interesse;
•
avere prestazioni che permettano un refresh della posizione ad
intervalli temporali non troppo lunghi; il sistema in questione
(composto da 3 computer) riesce a lavorare ad una frequenza di
3.5 Hz;
•
lavorare con più persone contemporaneamente; Easy Living
riesce a monitorare fino a 3 persone;
•
monitorare persone che entrano ed escono dalla stanza in modo
automatico;
•
lavorare con un numero non prefissato di fotocamere, al fine di
“coprire” ogni angolo dell’ambiente;
•
mantenere la localizzazione anche nel caso di persone seminascoste da ostacoli, tavoli e oggetti.
50
3.6.6 CGI – TA
La tecnologia “Cell Global Identity” (CGI),
basata sulla tecnica di
prossimità, è utilizzata in sistemi formati da un network di stazioni che coprono
l’area nella quale si trova il terminale dividendola in celle contigue e
parzialmente sovrapposte. In sistemi di questo tipo il terminale si “aggancia” ad
una di queste stazioni (tipicamente la più vicina, ove il segnale è migliore). Il
sistema quindi riesce a catturare questa informazione e a determinare l’area in
cui il terminale è situato. Tipicamente usato nei sistemi GSM di telefonia mobile,
è di basso costo, ma anche di scarsa precisione. Inoltre la precisione a cui si può
arrivare dipende fortemente dalla zona nella quale si opera: in aree densamente
popolate, dove la copertura è decisamente maggiore, si può arrivare a valori
dell’ordine di poche centinaia di metri, mentre in zone scarsamente coperte si
può arrivare anche a parecchi chilometri.
Figura 3.11 – sistema base CGI
Una prima ottimizzazione può essere ottenuta nel caso in cui le antenne
riescano a distinguere più “settori” all’interno della cella; in tal caso si può
identificare quello dal quale proviene il segnale.
Figura 3.12 – sistema CGI + Cell Sector
51
Oppure, un altro tipo di ottimizzazione può essere ottenuta mediante la
misura del tempo di accesso alla rete, proporzionale alla distanza radiale del
terminale dall’antenna. In tal caso si è di fronte alla tecnologia “Timing
Advance” (CGI-TA), non comunque di molto migliore rispetto alla tecnica
“standard”.
Figura 3.13– sistema CGI - TA
3.6.7 GPS, D-GPS, A-GPS
Tecnologia disponibile dai primi anni ’80, il “Global Positioning System”
(GPS) [11] è una tecnologia Terminal-Based ed è formata da una rete mondiale
di 24 satelliti orbitanti a 6 diverse quote attorno ai 20000 km dalla terra.
Figura 3.14 – costellazione dei satelliti GPS
a. GPS
Sviluppato dal DoD, permette alle sue massime potenzialità (“Precise
Positioning Service”: PPS) di localizzare con i seguenti parametri:
52
o
22 meter Horizontal accuracy;
o
27.7 meter vertical accuracy;
o
200 nanosecond time (UTC) accuracy.
Liberamente usabile anche da comuni cittadini, semplicemente
acquistando un ricevitore, alcune limitazioni erano state imposte
(chiamate con il nome di Selective Availability: SA) in modo da non dare
la possibilità di sviluppare, ad esempio, sistemi di puntamento di missili.
I parametri di tale sistema (“Standard Positioning Service”: SPS) sono i
seguenti:
o
100 meter horizontal accuracy;
o
156 meter vertical accuracy
o
340 nanoseconds time accuracy.
Attualmente comunque, a partire dal Primo Maggio 2000, tale restrizione è
stata eliminata, aumentando la precisione del SPS portandola ai livelli del
PPS. Come metodo di localizzazione è utilizzato un sistema simile al ToA,
ove, al fine di ottenere le 3 coordinate geodetiche (altitudine, longitudine,
altezza geodetiche sul Datum WGS-84) ed il tempo T di rilevazione, sono
necessari i segnali di almeno 4 satelliti. I satelliti sono sempre sincronizzati
fra di loro mediante orologi atomici, e nel segnale emesso è presente anche
l’indicazione del tempo di emissione. In tal modo il ricevitore può calcolare
il Time-of-Arrival ed effettuare la triangolazione (più precisamente
lateration) . Poiché i satelliti sono posti sempre al di sopra del ricevitore
sarebbero necessari solo 3 satelliti per calcolare la posizione tridimensionale
dell’oggetto. Questo però solo se tutte le entità coinvolte fossero
sincronizzate. Poiché però il ricevitore non è sincronizzato con i satelliti, è
necessario un quarto satellite al fine di eliminare questo dissincronismo,
sincronizzando ad ogni lettura questo clock “comune” a quello del ricevitore
[12].
53
Al fine di migliorare le prestazioni del GPS, avvicinandosi ad un sistema
PPS, è stata introdotta una variante che, a fronte di maggiori costi, offre una
soluzione molto più precisa: il “Differential GPS” (D-GPS).
b. D-GPS
Il “Differential-GPS” (D-GPS) si prefigge di rendere il sistema basato su
tecnologia GPS più accurato, e fu inizialmente studiano in modo da
compensare l’errore dovuto alla modalità di funzionamento SPS. Molto
semplicemente, avendo a disposizione, oltre al ricevitore mobile MS, una
stazione GPS fissa e dalle coordinate note FS, è possibile stabilire l’errore
commesso
in
quell’area
dai
satelliti
visibili,
comunicandola
periodicamente al MS. Quest’ultimo provvede a correggere di
conseguenza la propria posizione stimata. Si può arrivare ad
un’accuratezza fino a 2 metri per il 65 % delle misure [34].
Problema fondamentale del GPS è che, a causa dell’uso dei satelliti, è
utilizzabile solamente in situazioni Outdoor, ove cioè si ha la “visibilità” degli
stessi. In contesti Indoor, dove l’ambiente blocca di fatto i segnali satellitari, altre
soluzioni sono necessarie. Una soluzione integrata è altresì possibile, in modo da
poter utilizzare il GPS quando possibile e altre tecnologie quando il sistema
satellitare è inusabile. Tale tecnologia è chiamata “Assisted GPS”.
c. A-GPS
In tale sistema, “Assisted-GPS” (A-GPS), si fa uso, oltre che della
tecnologia GPS, del network fisso delle reti GSM (che deve essere quindi
presente) mediante il quale si possono effettuare due distinte operazioni:
→ effettuare le correzioni GPS mediante ricevitori fissi e
comunicarle ai cellulari, facendo diventare quindi il sistema un
D-GPS;
54
→ effettuare delle misure di posizione indipendenti dai segnali
GPS, e comunicarle ai terminali in caso di copertura satellitare
assente.
Avendo a disposizione in special modo la seconda possibilità, si arriva quindi ad
avere un sistema integrato di posizionamento Indoor/Outdoor.
3.6.8 Sim-Toolkit
Il sistema [13] si basa su reti GSM e schede SIM (Subscribe Identifier
Module) di nuova concezione, nelle quali risiedono strumenti software atti a
localizzare il terminale mobile. Chiaramente Handset-based, il sistema fornisce,
ad applicativi appositamente realizzati, un’API di interfaccia in modo da
utilizzare le informazioni di posizione disponibili. Come si nota, il sistema non
fornisce esplicitamente un metodo di localizzazione, ma questo è lasciato alla
specifica implementazione.
3.6.9 RADAR
Il sistema, realizzato dai ricercatori P.Bahl e V.N.Padmanabhan della
Microsoft Corporation [14], si prefigge come scopo la localizzazione di terminali
mobili in ambienti Indoor utilizzando un meccanismo di “Scene Analisys”
considerando come “features” caratteristiche di ogni locazione la potenza
ricevuta (RSSI) del segnale proveniente da stazioni fisse. L’infrastruttura
considerata è una WLAN, basata sullo standard 802.11b. Le stazioni fisse e di
posizione nota sono quindi gli Access Point (AP), mentre i terminali mobili
(WT) sono dotati di una scheda WLAN.
55
Figura 3.15 – infrastruttura di riferimento RADAR
Questo sistema differisce da altri allo studio o già implementati in quanto si
prefigge di essere “non invasivo” rispetto all’infrastruttura di comunicazione. In
altre parole, non vi deve essere necessità di una strutturazione dell’ambiente
confacente alle sue necessità, bensì deve essere adattabile al luogo nel quale si
trova a lavorare. Basandosi, ad esempio, su una rete di tipo 802.11, ed essendo
disponibili, per la maggior parte di questi dispositivi, informazioni riguardanti la
potenza ricevuta dai vari WT, ci si può basare su un modello di funzionamento
del tipo “scene analisys” basato su “features” di potenza ricevuta.
3.6.9.1 Modello dei dati
Da quanto detto, pare quindi logico modellare il database con entry del tipo
xi,yi
APij , potenza_ricevutaij
dove:
i ∈ {1…N}, ossia le locazioni di interesse della griglia
formata;
j ∈ {1…M}, ossia il numero di potenze ricevute dal WT,
essendo quindi M il numero di AP presenti nel sistema;
xi,yi le coordinate del punto di interesse in una qualche
unità di misura che “mappa” la griglia;
APij , ad esempio, l’indirizzo MAC dell’AP;
potenza_ricevutaij la potenza ricevuta da WT nel punto i
dall’AP j;
56
3.6.9.2 Fase di “Off-line”
Passo preliminare alla fase “off-line” è la definizione della griglia
bidimensionale nella quale suddividere lo spazio:
→ più la griglia si compone di maglie “larghe”, più la sensibilità calerà;
→ più la griglia si compone di maglie “strette”, più vi saranno punti
indistinguibili e quindi situazioni con risultati erronei;
Successivamente, durante tale fase “off-line” vera e propria, si memorizzano i
dati nel database “statico”, se possibile considerando più campioni (L) per lo
stesso xi,yi ed effettuando una media di questi. In tal modo si possono attenuare
componenti di rumore sempre presenti.
3.6.9.3
Fase di “On-line”
In tale fase, come in tutti i sistemi di “scene analisys”, si monitorizzano i dati
“real-time” di un terminale in movimento e si confrontano questi con le “feature”
memorizzate del DB statico mediante il già citato “Pattern Matching Algorithm”.
Il problema si sposta quindi all’algoritmo da utilizzare al fine di avere il miglior
risultato in termini di “match” dell’esatta posizione con quella stimata.
Ad esmpio, si può scandire il DB e calcolare una “distanza” tra i dati “real-time”
e ciascuna “tupla” dei dati “off-line”.
3.6.10 Localizzazione in reti Ad-hoc
57
Come già accennato, tutti i metodi visti finora si basano su un infrastruttura
che consente di calcolare la posizione dei terminali mobili sia che l’infrastruttura
sia fissa, sia che, viceversa, sia mobile (come il GPS).
Un caso particolarmente interessante, e che viene in questo contesto
brevemente accennato, è quello della localizzazione in ambito di reti “Ad-Hoc”
(cfr. Capitolo 1), nel quale non esiste un’infrastruttura di appoggio e tutte le
entità coinvolte diventano mobili e quindi di posizione ignota. Ciò comporta
problemi (e soluzioni) totalmente nuovi rispetto ai casi precedenti; ad esempio
che non tutti i terminali sono visibili l’un l’altro. In tal caso si deve fare uso di
strumenti diversi, come algoritmi “collaborativi” e totalmente o parzialmente
distribuiti, richiedendo un’interazione notevole fra i terminali. Un esempio può
essere l’algoritmo “Assumption Based Coordinates” (ABC) nel quale,
brevemente, si considerano le coordinate di un terminale pari a (0,0,0) e si
determinano iterativamente quelle degli altri mediante distanze relative
determinate, ad esempio, tramite misure di potenza (metodo RSSI). In tal modo
non solo si “scopre” l’intera rete di terminali, ma, successivamente, si può
migliorare la precisione del risultato ripetendo l’algoritmo. Ovviamente, si ha a
che fare con un sistema di coordinate relativo, in cui sono note le distanze tra i
vari terminali. Se, però, alcuni terminali occupano posizioni note (ne sono
necessari almeno 4 in uno spazio tridimensionale), è possibile passare dalle
misure relative ad un sistema di riferimento “assoluto” (nel senso di condiviso da
tutti gli oggetti e “immutabile”).
Attualmente un algoritmo di questo tipo è implementato dal sistema SpotON
[30].
58
Capitolo 4
Progetto ed Implementazione
4.1
Introduzione
I capitoli precedenti hanno avuto il compito di gettare le basi teoriche di un
sistema di localizzazione nei suoi tratti generali (cfr. Capitolo 2).
Nel presente capitolo, quindi, si comincerà ad occuparsi del sistema di
localizzazione nel suo complesso, con la definizione dei dettagli architetturali
del meccanismo di localizzazione, scopo del progetto.
4.2
Il modello utilizzato
In molti lavori condotti sulla possibilità di localizzare terminali mobili in un
definito ambiente, spesso si adotta un approccio basato sulla triangolazione
dei valori delle distanze tra il dispositivo mobile e le stazioni fisse presenti in
tale ambiente. La stima delle distanze è ottenute con una delle tecniche di
localizzazione descritte nel capitolo precedente.
Nello scenario di
riferimento un tale approccio è inadeguato per il seguenti motivo:
59
•
non è robusto nei confronti di interferenze dovute alla presenza di
ostacoli come ad esempio muri, e per effetto della possibile presenza di
segnali con frequenze simili;
•
la presenza di molti dispositivi per realizzare il positioning e/o di
modelli di stima molto complessi determinano un aumento dei costi
dell’intera infrastruttura.
Nell’approccio proposto (cfr Capitolo 2), per l’identificazione della
posizione del dispositivo mobile,
si è evidenziato il fatto di voler
determinare la posizione del dispositivo non in termini di coordinate ma
semplicemente attraverso una stima
supposto
della zona, intesa come sala di un
edificio, in cui il dispositivo stesso
è situato. Assumendo la
presenza di un sensore per ogni sala come illustrato in figura 4.1,
l’individuazione della zona caratterizzata dalla presenza del dispositivo,
equivale alla scoperta della sala in cui è situato.
Sensori
Figura 4.1 - Sale del museo con sensori
La soluzione si basa sulla tecnica di localizzazione definita RSSI (Receiver
Signal Strength Indicator)(cfr 3.5.6). Il dispositivo mobile acquisisce
60
informazioni sulla intensità
sensori. Tali valori
di tutti i segnali rilevabili, provenienti dai
sono funzione della distanza che intercorre tra
dispositivo mobile ed i sensori posti nel range di azione; al crescere della
distanza diminuisce l’intensità del segnale. La sola informazione sulla
potenza ci consente di determinare la sala nel quale il dispositivo mobile sta
operando. Infatti, la comparazione dei livelli di potenza rilevati per ciascuna
connessione, consente di stabilire il valore massimo e di conseguenza il
sensore più prossimo alla unità mobile.
Ad avvalorare una scelta di questo tipo, anziché un più complesso e costoso
modello di localizzazione, c’è da considerare che con la presenza di un sensore
per ciascuna sala si ha una riduzione degli effetti dovuti alla presenza di ostacoli
come i muri, ad esempio, e degli errori di misura che spesso caratterizzano le
soluzioni basate sulla triangolazione. Infatti la stessa presenza di muri consente
di smorzare i segnali provenienti dai sensori dislocati nelle sale adiacenti a quella
in cui e presente il dispositivo mobile, facilitando il compito di localizzazione
secondo il metodo proposto. Per di più, non essendo interessati alla esatta
posizione del dispositivo, la soluzione adottata è più tollerante agli errori e non
richiede pesanti attività computazionali.
Non va dimenticato, inoltre, che se si adottasse una soluzione basata sulla
triangolazione, per migliorare l’accuratezza sarebbe necessario l’utilizzo di
sensori sofisticati e/o più di tre acces point. Tutto ciò comporterebbe un aumento
dei costi dell’infrastruttura per la realizzazione del positioning.
4.3
Definizione dell’infrastruttura del sistema di localizzazione
Una volta definita l’architettura generale (cfr. Capitolo 2), il passo successivo
è costituito dalla scelta della infrastruttura
comunicazione fra i vari dispositivi impiegati.
61
di basso livello che gestisca la
4.3.1 Scelta dello Standard di Comunicazione: Bluetooth
Il progetto in esame si basa su un sistema informatico nel quale sono presenti
terminali mobili che devono interagire con dei sensori dislocati nelle sale di un
edificio; questi ultimi forniscono le informazioni
e/o servizi utilizzati
dall’utente. Riguardo al sistema di localizzazione, quindi, questo è un aspetto che
pone vincoli all’infrastruttura al quale il sistema deve sottostare.
Da questa breve descrizione nasce, infatti, la considerazione che deve essere
presente un’infrastruttura che permetta una comunicazione di tipo wireless.
Ecco, quindi, la scelta dello standard 802.15: Bluetooth.. Questo tipo di
soluzione consente di adottare la tecnica di localizzazione per ambienti indoor
basata sull’RSSI (cfr. 3.5.6). Infatti, anche se in maniera indiretta, lo standard
Bluetooth consente di monitorare l’intensità dei segnali ricevuti dal dispositivo
mobile attraverso una implementazione dell’RSSI disponibile in un registro
hardware a cui si può accedere mediante le funzionalità del driver HCI [metti rif
da articolo massimo] . Vediamo una breve descrizione dello stack Bluetooth.
4.3.1.1
Lo Stack Protocollare Bluetooth
Lo stack protocollare Bluetooth [1], come evidenzia la figura 4.2, è
costituito dai seguenti livelli:
•
Radio: è il livello fisico di Bluetooth (RF), il più basso; definisce i
requisiti del transceiver Bluetooth che opera su una banda di 2.4
GHz.
•
Baseband Layer: è il livello MAC e, ovviamente, si colloca sopra al
livello Radio; gestisce l’accesso al mezzo, le comunicazioni sincrone
ed asincrone tra i peer e, quindi, le procedure di paging ed inquiry per
l’accesso ai dispositvi Bluetooth presenti nell’area.
•
Link Manager Protocol: si occupa della creazione, configurazione e
del management delle comunicazioni oltre che dell’autenticazione. A
questo livello sono implementate anche alcune funzioni di sicurezza,
62
ed il controllo di potenza che, tra l’altro, permette ai dispositivi
Bluetooth di aumentare o diminuire la potenza di trasmissione.
•
Logical Link Control and Adaption Protocol (L2CAP): è il link layer;
fornisce servizi connection-oriented e connectionless per i livelli
superiori dello stack Bluetooth.
•
Host Controller Interface (HCI): è l’interfaccia tra l’hardware ed i
livelli superiori dello stack Bluetooth. Esso è stato progettato per
fornire un set standard di comandi per accedere all’hardware e
controllare i registri.
•
RFCOMM: è un semplice protocollo di trasporto basato sullo
standard ETSI TS 07.101 [2]. Esso definisce dei metodi per emulare
una connessione RS-232.
•
OBEX: specifica un protocollo che permette lo scambio di oggetti e
strutture dati tra dispositivi remoti.
•
SDP: è un protocollo per il discovery dei dispositivi al fine di scoprire
i servizi disponibili su una connessione Bluetooth e definirne le
caratteristiche.
1
Questo standard è anche chiamato TS 101 369
63
Figura 4.2 - Lo Stack Protocollare Bluetooth
4.3.1.2 Campo di copertura Bluetooth
Bluetooth opera all’interno di un range massimo che è di 10 metri [3], ma
tale limite può essere portato a 100 metri facendo uso di antenne amplificate
oppure creando delle scatternet, ossia delle collezioni di piconet. Ogni piconet è
costituita da un master (un host o un bridge) ed al più 7 slave. Le piconet
possono essere collegate tra loro tramite dispositivi Bluetooth (host di entrambi
le reti), che possono fungere da ponte tra le due piconet. Tali host vanno
configurati come Slave/Slave o Master/Slave delle piconet.
Per definizione, il master è il dispositivo Bluetooth che avvia le connessioni con
gli altri dispositivi che sono detti slave.
4.3.1.3 Le modalità di comunicazione
Bluetooth è un protocollo ad-hoc che fornisce sia una connessione pointto-point che point-to-multipoint. Il massimo data rate è 732.2 Kbps. In una
piconet la comunicazione viene gestita dal master secondo una politica Time-
64
Division-Multiplex che prevede la divisione della comunicazione stessa in slot di
625 µs (625 bit per slot). Tutte le comunicazioni passano attraverso il master
della piconet; la banda, pertanto, va divisa tra gli slave e, quindi, nel caso
peggiore, in cui tutti i 7 slave vogliono comunicare, la banda disponibile per
ognuno risulta 732.2/7 Kbps. Nonostante la banda ridotta, la connessione
Bluetooth consente accesso ad internet, stampa, streaming video molto
compressi, collaboration work, etc.
La comunicazione può essere sincrona2 (SCO) e asincrona (ACL) [4]; mentre la
prima costituisce un collegamento simmetrico punto-punto tra un master ed uno
slave all’interno di una piconet ed è a commutazione di circuito, la seconda,
invece, è a commutazione di pacchetto ed è mantenuta tra il master e tutti gli
slave attivi attraverso un ACL (Asynchronous Connectionless Link). Un solo
master può supportare al più tre collegamenti SCO con uno slave o un solo
collegamento SCO per un massimo di tre slave. Gli slave, comunque, possono
supportare un massimo di due collegamenti SCO (Synchronous Connection
Oriented Link) se questo è fatto con due master differenti.
Per trasmettere voce real-time, un’applicazione deve riservare uno slot in
entrambe le direzioni ad intervalli di tempo regolari; è necessaria, pertanto, una
connessione sincrona SCO ed un collegamento di tipo circuit switch con
prenotazione di slot ad intervalli regolari. Uno speech coder, infatti, genera 10
byte ogni 1,25ms; essendo possibile trasportare 30 byte per ogni slot, è
sufficiente un solo slot, in ogni direzione, ogni 3,75 ms.
Per la comunicazione tra master e slave, invece, è utilizzata una comunicazione
asincrona, in cui gli slot di comunicazione sono riservati su richiesta e della loro
distribuzione è responsabile il master, che evita collisioni. Gli slot asincroni
hanno priorità inferiore rispetto a quelli sincroni.
2
Dire che la trasmissione è simmetrica significa che sia il master che lo slave stanno utilizzando
lo stesso tipo di pacchetto. Si può far riferimento alle specifiche [1] per spiegazioni dettagliate sul
differente uso dei pacchetti.
65
4.3.1.4 La frequenza di trasmissione
Bluetooth utilizza la modulazione GFSK (Gaussian Frequency Shift Keying). La
frequenza di trasmissione, come evidenzia la tabella 4.2, è compresa tra 2,40 e
2,483 GHz ed il segnale è full-duplex con una frequenza di salto di 1600 hops
per secondo. La sequenza di hope è fissata; il segnale, infatti, salta 79 differenti
frequenze ad intervallo di 1 MHz, per cui quando uno slave entra in una piconet
si sincronizza con la sequenza di hope dettata dal master e così possono essere
stabilite e mantenute fino a 7 connessioni simultaneamente. Il numero elevato di
hope per secondo gli permette di operare anche in aree rumorose.
Tabella 4.3: Range di frequenza Bluetooth
Di fatto, però, la convivenza di reti Bluetooth e 802.11 nella stessa “area”, può
generare interferenze e perdite di prestazioni [5], [6], [7]. Ciò è dovuto al fatto
che entrambi le reti trasmettono alla stessa frequenza, ma con una frequenza di
salto differente (utilizzano un sistema di multiplexing time division). In presenza
di interferenza, le stazioni di entrambi le reti trasmettono i pacchetti
“danneggiati”, ciò provoca riduzioni di prestazioni [8].
La potenza dell’antenna Bluetooth è divisa in tre classi di potenza con un output
massimo di 100 mW, 2,5 mW e 1 mW rispettivamente per i dispositivi di classe
1, 2 e 3. Di seguito si riporta la relativa tabella.
Tabella 4.4 - Classi di potenza Bluetooth
66
4.3.2 Dispositivi utilizzati
Come supporto all’architettura del progetto è stato utilizzato, come
dispositivo mobile, un iPAQ 3970 con modulo Bluetooth. Il sistema operativo
sul quale è stata sviluppata l’architettura è Linux Familiar 0.7.0. I sensori
wireless, invece, sono stazionari e sono stati configurati per accettare
connessioni dal dispositivo mobile. Nel nostro scenario sono stati utilizzati gli
adattatori Bluetooth USB della ANYCOM [11].
Figura 4.6 - Adattatore BT USB Anycom
Figura 4.5 - iPAQ 3970
4.4
Dettagli Architetturali
Il modello architetturarale presentato (cfr Capitolo 2) e rappresentato in
figura
4.7
è
stato
sviluppato
utilizzando
BlueZ
che
rappresenta
l’implementazione ufficiale dello stack dei protocolli Bluetooth per Linux. Per
la realizzazione in Java è stato, inoltre, utilizzato il package Java JblueZ che si
interfaccia con lo stack protocollare BlueZ, e che consente di utilizzare e
aggiungere funzionalità Bluetooth alla applicazioni sviluppate nel linguaggio
Java.
67
Prima di entrare nei dettagli architetturali diamo una breve descrizione dello
stack Bluez e di JblueZ.
User Layer
Zoning Layer
Network Layer
Measurement Layer
Connettivity Layer
Bluetooth
Figura 4.7 – Architettura del sistema di localizzazione
4.4.1 Lo stack BlueZ
Lo stack protocollare BlueZ, fornisce un supporto per i livelli e i protocolli
del core Bluetooth. Esso è composto da:
•
HCI (Host Controller Interface) core
•
Driver HCI UART, USB, PCMCIA e VHCI (Virtual HCI)
68
•
Protocollo RFCOMM3, BNEP e CMTP
•
Protocollo L2CAP (Logical Link Control and Adaptation Protocol) che
fa le veci del protocollo UDP
•
Utility per configurazione e testing
•
Strumenti di analisi e protocolli di decodifica
Figura 4.8 - Lo Stack Protocollare BlueZ
Dalla figura 4.8, oltre alla forte modularità dello stack, si evince che BlueZ
consiste di 4 parti: i driver HCI, il core BlueZ, l’interfaccia socket e il livello
applicazione. Il core BlueZ è responsabile di connettere i protocolli
dell’interfaccia socket e l’interfaccia driver HCI. Quest’ultima è composta dalle
tre interfacce VHCI, USB, UART. Essa, pertanto, si occupa di inviare al core
BlueZ i dati che provengono dall’HCI attraverso il modulo Bluetooth RF (Radio
Frequency). L’interfaccia socket è, invece, responsabile della processazione dei
3
In precedenza lo stack BlueZ non offriva un supporto completo per lo standard RFCOMM,
adesso, invece, ce ne è un’implementazione che fa uso di USSP (User Space Serial Ports) e che è
stato appositamente proggettato perchè possa lavorare con l’interfaccia socket del livello L2CAP
69
dati che provengono dal core BlueZ. Per assolvere a questo ruolo fa uso delle
Berkley socket interface4. Il livello applicazione, infine, fornisce vari servizi, in
particolare servizi web, che possono essere utilizzati dai moduli sottostanti.
4.4.2
BlueZ e Java: JblueZ
SUN ha rilasciato le specifiche JSR-82 per J2ME. Tali specifiche
descrivono le API di comunicazione per lo stack protocollare Bluetooth5. Esse
sono state adottate da diversi produttori di software per dispositivi Bluetooth. Tra
queste c’è JblueZ [9], che ha implementato le API JSR-82 appoggiandosi proprio
allo stack protocollare BlueZ.
JblueZ, originariamente, è stato sviluppato da Appliance Studio [10], poi è
diventato in un progetto Open Source.
É un package Java che si interfaccia con lo stack protocollare BlueZ e che
consente di aggiungere funzionalità Bluetooth alle applicazioni Java.
Esso è stato progettato per fornire un supporto Bluetooth (Open Source) per
J2SE e J2EE.
Lo sviluppo di JblueZ è dovuto alla necessità di fornire un semplice set completo
di API Java per Bluetooth che funzionasse sotto il sistema operativo Linux.
Al momento JblueZ consiste principalmente in una libreria java per l’accesso ad
alcune funzionalità HCI di BlueZ, tra cui:
•
lettura dei parametri
•
impostazione del dispositivo Bluetooth locale
•
funzionalità per la ricerca di dispositivi remoti
4
Interfaccia standard Linux
5
Sono disponibili anche delle API C. Al riguardo, però, non c’è una documentazione dettagliata.
Si tratta, in effetti, della documentazione di alcune librerie tipo HCI.h e di alcuni file sorgenti
Bluetooth.c. Oltre ai prototipi delle funzioni sono indicati anche le caratteristiche dei parametri e
a cosa serva il metodo
70
•
funzionalità per la creare ed eliminare le connessioni
•
acquisizione di informazioni relativamente al dispositivo remoto
Altre funzionalità, come ad esempio quelle relative al delivery dei servizi, non
sono state implementate. Si sta, però, lavorando per allargare il range delle
funzionalità BlueZ messe a disposizione dei programmatori Java. In aggiunta ci
sono anche altri intenti come quello di includere un supporto per i livelli più alti
dello stack protocollare Bluetooth come L2CAP, RFCOMM e SDP e
implementare il multithread e la sincronizzazione di accesso ai dispostivi HCI.
4.4.3
Implementazione dell’architettura
Il livello rete è stato sviluppato utilizzando lo stack BlueZ. Questo livello
si compone di due sottolivelli Connectivity e Measurement.
- Connectivity Layer
Questo livello è incaricato di scoprire e creare le connessioni con i sensori vicini.
In particolare, il Connectivity Layer, consente di stabilire una connesione di dipo
ACL creando un piconet, nella quale il dispositivo mobile assume il ruolo di
master ed i sensori quello di slave.
Il discovery e la creazione di connessioni con gli access point Bluetooth è
realizzato rispettivamente mediante i metodi hciInquiry e hciCreateConnection
disponibili nella classe Bluez del package com.appliancestudio.jbluez di JblueZ.
Va sottolineato che tutti i metodi nativi definiti nelle classi di JbluZ sono
implementati, via Java Native Interface (JNI) in C. JblueZ è fornito in forma
binaria e può essere utilizzato senza compilazione, tuttavia, essendo incluso
71
anche il codice sorgente, è possibile aggiungere funzionalità o, comunque,
apportare modifiche.
- SS_Measurement Layer
Consente di effettuare la lettura del valore del parametro RSSI memorizzato
all’interno di un registro hardware. Tele parametro rappresenta l’elemento chiave
sul quale è
fondato l’approccio di positioning proposto. Esso ci da una
indicazione del livello di potenza ricevuto dal dispositivo mobile ed è funzione
della distanza che intercorre tra dispositivo e sensore. Sebbene non possa essere
considerato per effettuare una stima accurata della distanza, con la presenza di
un sensore per ciascuna zona, la lettura dell’RSSI per ciascuna delle connessioni
attive, consente di individuare la zona occupata dal dispositivo mobile.
Mentre in BlueZ è presente un metodo per accedere al valore dell’RSSI , con
JblueZ non è possibile effettuare il rilevamento di tale parametro da una
applicazione scritta in Java. Di qui, la necessita di aggiungere una nuova
funzionalità al package JblueZ che consentisse la lettura di tale parametro e
poterne quindi farne uso nell’algoritmo di positionig implementato in Java.
- Zoning Layer
Il livello “zona” (Zoning Layer), attraverso una comparazione dei diversi valori
di RSSI
ricevuti dai vari sensori, consente di trasformare le informazioni
disponibili al livello SS_Measurement in una indicazione sulla posizione
occupata dal dispositivo mobile sulla base del maggiore dei valori tra quelli
rilevati
- User Layer
Il livello superiore è il livello utente (User Layer); si occupa di
fornire
all’utente, attraverso una interfaccia grafica, l’indicazione della sala oggetto
della visita con i relativi servizi di cui può disporre.
72
4.4.3.1 Estensione JblueZ attraverso Java Native Interface(JNI)
Come già messo in evidenza, tutti i metodi nativi definiti nelle classi di JbluZ
sono implementati, via Java Native Interface (JNI) in C. Per implementare il
metodo che ci dia la possibilità di leggere il valore di RSSI bisogna seguire la
procedura classica per la definizione ed implementazione attraverso JNI. Di
seguito vengono descritti i passi per l’implementazione del metodo hciGetRssi
attraverso JNI.
1
- Definizione del metodo in BlueZ.java:
package com.appliancestudio.jbluez
public class bluez
{
static {System.loadLibrary(“jbluez”); }
……………….
public native int hciGetRssi(String bdaddr);
……………….
}
2
- Implementazione del sorgente in C nel file BlueZ.c:
…………………….
JNIEXPORT jint JNICALL
Java_com_appliancestudio_jbluez_BlueZ_hciGetRssi
(JNIEnv *env, jobject obj, jstring bdaddr_jstr)
{
// lettura RSSI mediante la funzione dell’HCI driver di BlueZ “ return
HCI_Read_RSSI
}
………………………….
3
- Esecuzione di un makefile per la creazione dell’archivio jbluez.jar;
4
- Esecuzione di un makefile per la creazione della libreria dinamica
libjbluez.so usata dal codice Java attraverso JNI.
73
4.5
Descrizione del meccanismo di positioning
Analizziamo la sequenza logica delle operazioni eseguite per identificare la
zona occupata dall’utente in possesso del dispositivo mobile. L’interazione tra il
dispositivo mobile ed i sensori avviene secondo le seguenti fasi:
A. l’utente con il terminale entra in una delle sale del museo;
B. vengono individuati mediante procedura di Inqury i sensori presenti nel
range d’azione del dispositivo mobile;
C. viene creata una connessione con ciascun sensore individuato;
D. viene rilevato il valore di RSSI per ciascuna connessione attiva;
E. si individua il sensore più vicino al terminale;
F. vengono visualizzati i servizi disponibili nella sala individuata;
G. tutte le attività suddette, a partire dalla fase C vengono ripetute per tutta
la durata della visita.
Più nel dettaglio, analizziamo i vari punti, visualizzati nel diagramma di flusso
mostrato in figura 4.9 , che compongono le suddette fasi:
1. viene effettuata la procedura di Inquiry;
2. si attiva la connessione per ogni sensore individuato;
3. per ciascuna connessione attivata viene letto il valore di RSSI mediante il
metodo implementato hciGetRssi;
4. si confrontano i valori di RSSI e si individua la connessione cui
corrisponde il valore massimo di RSSI rilevato;
5. sulla base del valore massimo si individua la sala oggetto della visita;
6. vengono visualizzati i servizi disponibili per la sala individuata;
7. vengono testati i valori di RSSI relativi alle stanze adiacenti alla sala
oggetto della visita (si suppone nota una mappa del museo) con
connessione attiva;
8. si ritorna ad eseguire il punto 4.
74
La localizzazione dovrà essere realizzata dinamicamente durante
tutto il
percorso della visita, pertanto bisognerà, periodicamente (ogni x secondi),
tentare di stabilire
la connessione con i sensori che saranno situati nelle sale
adiacenti (secondo una mappa dell’edificio) a quella correntemente occupata dal
visitatore. Vi è, quindi, la necessità di attivare un processo daemon
che
parallelamente svolga tale compito.
Inquiry
CREAZIONE
CONNESSIONE per ogni
Daemon
Per ogni connessione
attiva GetRssi
Verifica stato
connessioni sale
adiacentiogni x
secondi
Determinazione Sala
con MAX_RSSI
Non conesso
GetRssi per le sale adiacenti
alla sala corrente con
connessioni attive
Tenta di stabilire
la connessione
Figura 4.9 – Diagramma di flusso dell’algoritmo di localizzazione
75
Connesso
4.6
Limiti imposti dall’hardwre
L’algoritmo di localizzazione si basa sulla possibilità di stabilire connessioni
contemporanee tra il dispositivo mobile ed i sensori dislocati in sale adiacenti .
Nel fare ciò il dispositivo mobile assume il ruolo di master, mentre i sensori a
cui si è connessi quello di slave. In questo modo il dispositivo master ed i sensori
slave costituiscono una piconet -figura 4.10. Immaginando
lo scenario
applicativo affiora l’esigenza di poter configurare un sensore in modo che possa
accettare connessioni da più di un dispositivo mobile per effetto della presenza
contemporanea dei visitatori nelle varie zone dell’edificio. In pratica un sensore
deve poter essere configurato come multi-slave in modo che possa accettare
connessioni da più dispositivi mobili con ruolo di master. Si realizza in questo
modo una scatternet, ossia una sorta di collezioni di piconet in cui l’host che
funge da ponte è configurato come slave per entrambe le piconet. Si suol dire, in
tal caso, che l’host di entrambe le reti è configurato in modalità slave/slave. E’
possibile configurare l’host anche in modo che funga da master per una rete e
slave per l’altra piconet. Le due configurazioni sono mostrate in figura 4.11.
Piconet
master
slave
Figura 4.10 : Piconet costituita da un master e più slave
76
slave/slave
master/slave
Figura – Scatternet con host in configurazione slave/slave e master/slave
Nella sperimentazione del meccanismo implementato sono stati utilizzati dei
sensori che non consento la creazione di una scatternet. In pratica il sensore può
accettare una sola connessione da un master.
Questa limitazione è dovuta esclusivamente al firmware montato sul chipset
Bluetooth dell’adattatore Anycom che non prevede la funzionalità multi-slave.
Con l’aggiornamento del firmware è possibile superare questo tipo di problema.
In ogni caso rimane comunque limitato il numero di master che possono
connettersi contemporaneamente ad un sensore multi-slave.
Per ottenere una soluzione che sia scalabile si può immaginare un tipo di
configurazione a “grappolo”, inteso come un insieme di sensori posizionati nella
medesima posizione. In questo modo ciascun sensore dell’insieme potrà essere
utilizzato per stabilire una connessione con i diversi dispositivi mobile che
possono essere presenti nell’area del grappoli stesso. Combinando, infine, la
possibilità di un sensore di poter essere configurato come multi-slave con la
soluzione a grappoli si moltiplica il numero di dispositivi che possono
connettersi contemporaneamente all’insieme di sensori. Questa soluzione
presenta dei vantaggi anche in termini di tolleranza ai guasti.
77
Capitolo 5
Una implementazione delle JSR-179 mediante le
API JSR-82
5.1
Introduzione
Java Community Process (JCP) ha di recente definito due documenti di
specifiche al fine di coprire alcuni aspetti emergenti strettamente connessi allo
svilupparsi
di infrastrutture di nomadic computing e ad-hoc network.
In
particolare sono state sviluppate delle specifiche che consentissero di ottenere
informazioni sulla posizione geografica dei dispositivi mobili (JSR-179)[2] ed
altre relative alla comunicazione tra dispositivi Bluetooth (JSR-82)[3].
In questo capitolo, dopo aver illustrato gli aspetti fondamentali di
ciascuna delle specifiche, si cerca di dare un contributo su una loro possibile
integrazione. L’idea guida è quella di estendere la JSR-82, in modo da fornire
alle JSR-179, le informazioni di cui necessitano, per determinare la posizione di
un dispositivo mobile. Si considererà, in ultimo, una implementazione software
della estensione suddetta mediante JblueZ[1].
5.2
Descrizione delle JSR-179
Le JSR-179 rappresentano un package opzionale per J2ME che
consentono, attraverso una applicazione Java, di ottenere informazioni relative
alla posizione geografica di un dispositivo mobile. Si tratta di API generiche
78
rispetto al metodo di positioning utilizzato e consentono, tra l’altro, di poter
accedere ad un database di “punti di riferimento” memorizzato nel terminale
mobile; ciascun “punto di riferimento” è inteso come una posizione geografica
nota a cui è associato un nome. Analizziamo nel seguente paragrafo alcuni dei
componenti fondamentali illustrati nel class diagram:
Location
AddressInfo
address: AddressInfo
coordinates: Coordinates
horizontalAccuracy:int
verticalAccuracy:int
Coordinates
getAddressInfo(): AddressInfo
getExtraInfo () : String
getQualifiedCoordinates():Qualified
Coordinate
BUILDING_FLOOR : int
BUILDING_NAME : int
BUILDING_ROOM :int
BUILDING_ZONE : int
CITY : int
COUNTRY : int
COUNTRY_CODE : int
DISTRICT : int
STATE : int
STREET : ont
URL : int
AddressInfo () : void
getField () : String
setField (): void
Criteria
AVIABLE : int
OUT_OF_SERVICE : int
TEMPORARILY_UNAVAILABLE : int
LocationP
rovider
addProximityListener(): void
getInstance(): LocationProvider
getLocation( ): Location
getLastKnowLocation():Location
removeProximityListener(): void
reset() : void
setLocationListener () :void
Landmark
getAddressInfo() :AddressInfo
getDescription() :String
getName (): String
getQualifiedCoordinates() : QualifiedCoord
Landmark() :void
setAddressInfo() : void
setDescription() :void
setName (): void
ProximityListener
QualifiedCoordin
ates
LandmarkStore
DB
Figura 5.1 – Class Diagram delle JSR-179
79
5.2.1 Il modulo Location Provider
La classe LocatioProvider rappresenta il modulo fondamentale del
package. E’ il punto di partenza per le applicazioni che fanno utilizzo di tali API
al fine di poter rilevare informazioni sulla posizione dei terminali mobili. La sua
implementazione può essere realizzata utilizzando uno qualsiasi dei metodi di
localizzazione noti, per esempio, metodi basati sui satelliti come il GPS, metodi
basati sulle reti di telefonia mobile, oppure metodi su corto raggio che utilizzino
tecnologie wireless come, ad esempio, Bluetooth. L’implementazione può anche
combinare più di una tecnica in modo da ottenere il miglio risultato possibile.
Un aspetto strettamente connesso al LocationProvider è rappresentato dal modo
in cui può esso stesso essere selezionato. Esiste, infatti, la classe Criteria che
consente di definire un insieme di parametri che rappresentino un criterio di
selezione del LocationProvider. I parametri che possono essere settati sono i
seguenti:
-
horizzontal accuracy ;
-
vertical accuracy;
-
preferred respons time;
-
power consumption;
-
cost allowed;
-
speed required;
-
altitude requeired;
-
address info required.
In tabella sono indicati i valori assunti di default :
Criteria Field
Default value
Horizzontal accuracy
NO_REQUIREMENT
Vertical accuracy
NO_REQUIREMENT
Preferred response time
NO_REQUIREMENT
80
Power consumption
NO_REQUIREMENT
Cost allosew
Tue (allowed to cost)
Speed required
False (not required)
Altitude required
False (not requred)
Address info required
False (not required)
Non esiste alcun tipo di priorità per i campi suddetti. Una volta definito il criterio
verrà selezionato il LocationProvider che si sposa meglio con esso. Tuttavia, il
campo relativo ai costi (costi da sostenere da parte dell’utente finale) viene
considerato in modo diverso rispetto agli altri. Se, infatti, il campo è settato in
modo tale che non è consentita la possibilità di attribuire dei costi all’utente
finale, l’implementazione dovrà garantire la selezione del LocationProvider in
modo da non gravare alcun costo. Nella classe Criteria sono presenti i metodi
per impostare e leggere i valori di ciascun campo.
Ottenuto il LocationProvider, l’applicazione può richiedere l’oggetto Location
contenente le informazioni sulla posizione del terminale mobile al momento in
cui è stata fatta la richiesta. E’ possibile
effettuare una singola richiesta per
volta dell’oggetto Location, oppure fare un in modo che l’applicazione sia
aggiornata
periodicamente
con
nuove
informazioni
sulla
posizione
implementando un LocationListener. L’oggetto Location contiene le seguenti
informazioni:
-
coordinate e loro accuratezza;
-
velocità e direzione (se disponibili);
-
timestamp (che indica il momento in cui è fatta la misura);
-
informazioni sul metodo di localizzazione utilizzato (Angle-ofArrival,
Satellite, Short-Range,Time-of-Arrival….)
Per alcuni metodi di positioning, l’oggetto Location può anche contenere un
oggetto AddressInfo che contenga informazioni di tipo testuale sulla posizione.
Tali informazioni sono suddivise nei seguenti campi:
-
strada;
81
-
codice postale;
-
città;
-
nazione;
-
distretto;
-
nome edificio;
-
piano edificio;
-
stanza edificio.
Alle informazioni dell’oggetto Location si può accedere attraverso i metodi
messi a disposizione come ad esempio getAddressInfo(), getLocationMethod(),
getQualifiedCoordinates().
5.2.2 La classe Landmark
Un altro modulo fondamentale del
package è costituito dalla classe
Landmark che rappresenta un contenitore di punti di riferimento. Ciascuno di
essi è inteso come un luogo a cui è associato un nome, una descrizione testuale,
delle coordinate ed un AddressInfo (opzionale). Possono essere utilizzati per
rappresentare luoghi frequentemente utilizzati (casa, ufficio ristoranti,…) ed
essere raggruppati in categorie.
I metodi per memorizzare, cancellare e recuperare questi punti di riferimento dal
database sono presenti nella classe LandmarkStore.
Vediamo un semplice esempio di codice che illustri i passi da eseguire per
ottenere la posizione corrente del terminale mobile:
// viene creato un oggetto Criteria che consente di definire il criterio di selezione
//del LocationProvider
Criteria cr = new Criteria();
// Si specifica, ad esempio, una accuratezza orizzontale di 500 metri
cr.setHorizontalAccuracy(500);
82
LocationProvider lp = LocationProvider.getIstance(cr);
// si ottiene la posizione con timeout pari ad 1 minuto
// (per timeout si intende il tempo massimo che può intercorrere tra
// la richiesta di localizzazione ed la risposta ad essa)
Location l = lp.getLocation(60);
Coordinates c = l.getQualifiedCoordinates();
Double lat = c.getLatitide() ;
Double lon = c.getLongitude() ;
5.3
Le JSR-179 nel modello di positioning proposto
E’ già stato messo in evidenza il fatto che
le JSR-179 sono API
generiche rispetto al metodo ed alla tecnologia di positioning utilizzata. Si è
visto, inoltre, che consentono di accedere ad una database di “punti di
riferimento” ciascun dei quali è inteso come una posizione geografica nota
(espressa in termini di coordinate) a cui è associato un nome.
Riferendoci all’architettura del sistema di positioning realizzato, un punto di
riferimento noto a priori coincide con il sensore che sarà situato in un edificio x,
al piano y e nella stanza z. Si può quindi supporre di memorizzare, nel database
del dispositivo mobile, ciascun sensore come “punto noto” caratterizzato da
coordinate
geografiche e un nome; le coordinate, nel caso specifico, sono
espresse in termini di edificio, piano e stanza in cui è situato il sensore.
Pertanto possiamo immaginare che le informazioni nel database siano del tipo
riportate nella seguente tabella:
83
NOME
COORDINATE
Descrizione
(sensore)
(sensore)
Testuale
“ Giallo”
Edificio x, Piano y, Sala gialla
“Verde”
Edificio x, Piano y, Sala verde
Tabella 5.2 – Database in cui sono memorizzati i Landmark
Pertanto l’informazione chiave, nel contesto applicativo considerato, è
rappresentata dal nome del sensore prossimo al terminale mobile. Questa
informazione dovrà essere fornita al LocationProvider da un oggetto
opportunamente definito che chiameremo “LocationEstimator”. Una volta noto il
nome del sensore sarà possibile risalire alla posizione nell’ambito dell’edificio.
Viene riportati di seguito il sequence diagram della richiesta di localizzazione:
: Form
:LocationEstimator
:LocationProvider
1: Richiesta di localizzazione
2: GetLocation ( )
3: Nome Sensore
4: Connect
5: Query
6: Edificio x, Piano y,
Sala z
Figura 5.3 – Sequence Diagram di una richiesta di localizzazione
84
:Landmark
DB
Bisogna, pertanto, definire l’implementazione dell’oggetto LocationEstimator
il cui ruolo sia quello di fornire tutte le informazioni necessarie per costruire
l’oggetto Location della classe LocationProvider .
5.4
Implementazione del LocationEsimator
L’idea base è quella di considerare il componente LocationEstimator
come estensione delle JSR-82. Queste ultime sono state sviluppate con l’intento
di fornire un supporto per lo sviluppo di applicazioni Java su dispositivi
Bluetooth. Le principali funzionalità sono relative al discovery, alla gestione ed
alla comunicazione tra dispositivi Bluetooth.
Prima di entrare nei dettagli implementativi del LocationEstimator vediamo
alcuni aspetti essenziali delle JSR-82.
5.4.1 Le JSR-82
All’aumentare del numero dei dispositivi abilitati alla tecnologia
Bluetooth si è resa necessaria la presenza di uno standard che permettesse di
sviluppare applicazioni basate su questa tecnologia di comunicazione.
Il documento di specifiche rispondente alla Java Specification Request 82 (JSR82) e rilasciato nel mese di Marzo 2002. è il primo standard non proprietario
basato sul linguaggio di programmazione Java. Esso definisce l’architettura e le
API associate richieste per sviluppare una applicazione.
Queste specifiche sono rivolte principalmente a dispositivi conformi al profilo
MIDP. Le API Bluetooth e le API MIDP possono coesistere in un dispositivo
MIDP + Bluetooth, ma restano indipendenti fra loro.
Le specifiche Bluetooth definiscono protocolli e profili, ma non definiscono
alcuna API applicativa. Il documento di specifiche JSR-82 definisce delle API
per mezzo delle quali si possono utilizzare determinati protocolli e profili
Bluetooth definiti nel documento di specifiche ufficiali Bluetooth.
85
5.4.1.1 Caratteristiche generali
Le API sono pensate per dare la possibilità di:
•
registrare servizi;
•
scoprire dispositivi e servizi;
•
stabilire connessioni RFCOMM, L2CAP e OBEX;
•
condurre queste attività in modalità sicura.
Device Discovery
Una applicazione client Bluetooth deve poter essere in grado di scoprire
altri dispositivi che siano nelle sue vicinanze. Questo processo viene definito
device discovery. L’applicazione client potrà poi interrogare ciascun device per
verificare quali sono i servizi offerti. Le classi necessarie per poter effettuare il
discovery si trovano nel package javax.bluetooth.
Per eseguire un device inquiry bisogna eseguire i seguenti passi:
•
ottenere un DiscoveryAgent;
•
implementare il DiscoveryListener interface;
•
utilizzare il DiscoveryAgent per iniziare la ricerca, fornendo il listener
che riceverà la notifica dei dispositivi scoperti.
Creating Services
Un server Bluetooth deve pubblicare i dettagli dei servizi offerti al fine di
permettere ai potenziali client di trovarli ed utilizzarli. Per fare ciò, un server
deve creare un service record per il servizio fornito. Il service record è
memorizzato nel Service Discovery Database(SDDB) del server. Quest’ultimo
deve anche poter aggiornare il service record se il servizio disponibile cambia, e
rimuoverlo dal SDDB quando il servizio non è più disponibile.
Un service record descrive le caratteristiche del servizio e fornisce le
informazioni necessarie per accedervi. E’ strutturato da un insieme di attributi.
Ciascun attributo ha:
86
-
ID , è un 16 bit unsigned integre;
-
valore di tipo javax.bluetooth.DataElement.
Una lista completa di tutti gli attributi è presente nel documento Bluettoth
Assigned Numbers [4].
Per la creazione di un service record, il server invoca il metodo
javax.microedition.io.Connector.open(). In questo modo viene creato un notifier
che il client potrà utilizzare per connettersi al server. A tale metodo viene
passato una String URL che include tutte le informazioni necessarie alla
creazione del servizio.
Il service record è pubblicato quando il server indica che è pronto ad accettare
connessioni al servizio. Ciò viene fatto invocando sul notifier il metodo
acceptAndOpen(). Il service record rimarrà memorizzato nel SDDB fino a
quando il server invocherà il metodo close().
Accessing Services
Una
volta che è stato completato il discovery dei dispositivi, il client può
interrogare ciascun device per verificare la presenza di un servizio richiesto.
Questo processo viene chiamato service discovery. Ogni device che soddisfa
l’interrogazione fatta dal client ritorna ad esso un service record che contiene
tutte le informazioni necessarie per accedere al servizio.
Il processo di service discovery è simile a quello di device discovery e segue i
seguenti passi:
-
ottenere un DiscoveryAgent;
-
implementare un interfaccia del DiscoveryListener;
-
utilizzare il DiscoveryAgent per iniziare la ricerca, fornendo
una istanza del listener che riceverà la notifica degli eventi;
-
utilizzare un serviceRecord per connettersi al servizio.
87
5.4.2 Implementazione software del LocationEstimator mediante
JblueZ
Della descrizione delle JSR-82 emerge che esse non forniscono alcun
supporto per la localizzazione dei dispositivi mobili.
Con l’estensione delle JSR-82 si vuole, quindi, da un lato aggiungere nuove
funzionalità alle JSR-82 ed allo stesso tempo realizzare quel componente che
funga da bridge con le JSR-179.
Ricordiamo che il LocationEstimator ha il ruolo di fornire al LocationProvider
una indicazione sul sensore prossimo alla unità mobile in modo da poter risalire,
mediante consultazione del database, alla posizione corrente del dispositivo
mobile stesso.
Si rende necessario, pertanto, la definizione di metodi del
componente LocationEstimator, che consentano di stimare la distanza che
intercorre tra dispositivo
mobile ed i sensori posti nel suo raggio di azione.
Ciò permetterà di definire l’informazione da restituire al LocationProvider ossia
il sensore più vicino al terminale mobile.
La definizione dei metodi deve passare attraverso una valutazione di quelle che
sono le funzionalità di più basso livello utilizzabili mediante il driver HCI dello
stack BlueZ che è l’implementazione ufficiale del protocollo Bluetooth per
Linux. A tal proposito, nel realizzare il sistema di positioning illustrato nei
capitoli precedenti, si è potuto constatare che lo standard Bluetooth consente di
disporre di una stima della distanza tra due unità Bluetooth
attraverso il
monitoraggio dell’intensità dei segnali ricevuti dal dispositivo mobile. Infatti,
una delle funzionalità dell’HCI driver consente proprio l’accesso ad un registro
hardware contenente informazioni sul Received Signal Strenght Indication
(RSSI).
I metodi di LocationEsimator dovranno essenzialmente poter accedere a questa
informazione al fine di restituire al LocationProvider l’indicazione sul sensore
più vicino al dispositivo mobile. Un altro parametro che può ritornare utile è il
Link Quality (cfr 6.4) che ci da una indicazione sulla “qualità” della
connessione; anch’esso è disponibile attraverso una funzione dell’HCI driver
Pertanto si possono definire i seguenti metodi:
88
-
GetRSSI
restituisce il valore di RSSI rilevato in una connessione tra due
dispositivi Bluetooth;
-
GetLink
restituisce il valore del LinkQuality relativo ad una connessione
tra due unità bluetooth.
Dalla elaborazione degli RSSI rilevati per ciascuna connessione attiva, verrà
individuato il sensore prossimo al dispositivo mobile.
L’unico punto da definire è rappresentato dal modo in cui colmare il gap tra
l’implementazione in C dei metodi dell’HCI driver di BlueZ per la lettura
dell’RSSI e del Link Quality,
ed i metodi Java corrispondenti getRSSI e
getLinkQuality di LocationEstimator.
Ciò può essere realizzato mediante l’utilizzo del packege JblueZ (cfr capitolo 4)
che
consente l’implementazione dei
metodo in C attraverso Java Native
Interface (JNI). La procedura è già stata presentata nel capitolo 4.
Il seguente sequence diagram illustra l’interazione tra i vari componenti al fine
di ottenere la posizione del terminale mobile:
89
: Form
:LocationProvid
er
:LocationEstimator
or
:Landmark
DB
:Jbluez
:BlueZ
1: Richiesta di localizzazione
2: GetLocation ( )
3: GetRssi ( )
4
5
6
6: Nome Sensore
7: Connect
8: Query
8: Edificio x, Piano y,
Sala z
Figura 5.3 – Sequence Diagram di una richiesta di localizzazione
90
Capitolo 6
Test sperimentali
6.1 Introduzione
La possibilità di sviluppare
una applicazione che consentisse
di
realizzare il servizio di positioning illustrato nei capitoli precedenti è stata presa
in considerazione solo dopo aver potuto constatare, mediante dei test preliminari,
che l’utilizzo del parametro RSSI relativo alla intensità dei segnali in gioco,
disponibile attraverso una funzione dell’HCI dello stack Bluetooth, avrebbe
consentito di ottenere un livello accuratezza più che soddisfacente in relazione
al tipo di applicazione prefigurato.
Nel corso del capitolo, quindi, verrà
illustrato
ciò che è emerso dai test sui
valori di RSSI in funzione della distanza tra sensori e dispositivo mobile,
successivamente sono presentati i risultati dei test relativi al meccanismo di
positioning implementato. Viene infine definito Link Quality,un indicatore sulla
qualità della connessione tra due unità Bluetooth.Tutti gli esperimenti sono stati
effettuati presso il laboratorio ITEM del CINI di Napoli.
91
6.2
Received Signal Strenght Indication (RSSI)
Nel corso della descrizione del sistema di positioning, è stato messo in
evidenza come la sua realizzazione fosse strettamente connessa alla stima
indiretta delle distanze, tra dispositivo mobile e gli acces point, mediante un
parametro che fosse legato in qualche modo al livello di potenza del segnale
ricevuto dal terminale mobile, da ciascuno dei sensori distribuiti in un area
definita; l’intensità di un segnale, come noto, decresce all’aumentare della
distanza
dalla
sorgente
emittente
[26],
dando
luogo
al
fenomeno
dell’attenuazione.
I dispositivi Bluetooth consentono di misurare il livello di potenza ricevuto in
maniera indiretta attraverso l’RSSI (cfr 3.5.6), memorizzato
in un registro
hardware ed accessibile attraverso il comando HCI HCI_Read_RSSI.
Ovviamente sul dispositivo ricevente deve essere definito un Golden Receiver
range. Questo range compreso tra una soglia minima e massima è indicato in dB
e varia a seconda dei dipositivi utilizzati. Un esempio di conversione del valore
di RSSI nel livello di potenza RX relativo all’adattatore Bluetooth USB 100
della ANYCOM è rappresentato nel grafico 6.1.
HCI_Read_RSSI
30
20
10
0
-10
-90
-80
-70
-60
-50
-40
-30
-20
Received Power Level
Grafico 6.1 - RSSI in funzione dei livelli di potenza ricevuti
92
-10
0
Un valore di RSSI maggiore di zero indica che il livello di potenza RX è
maggiore della soglia massima del GRPR. Un valore negativo di sta ad indicare
che il livello di potenza RX è inferiore alla soglia minima del GRPR. Infine, un
RSSI pari a zero significa che il livello di potenza è compreso tra la soglia
minima e massima del GRPR.
6.3 Test sperimentale sull’RSSI
La valutazione sperimentale sull’RSSI è stata realizzata considerando come
dispositivo mobile un iPAQ 3970 con modulo Bluetooth e Sistema Operativo
Linux Familiar 0.7.0 sul quale è stato installato lo stack BlueZ. Il sensore (fisso)
è costituito da un adattatore Bluetooth USB 100 della ANYCOM montato su un
PC con SO Linux Mandrake 9.1, figura 6.2. La lettura dell’RSSI sul terminale
mobile viene effettuata attraverso il comando HCI HCI_Read_RSSI solo dopo
aver stabilito una connessione tra le due unità.
1 cm
1400 cm
Figura 6.2: Valutazione sperimentale dell’RSSI
La lettura dell’RSSI viene ripetuta per distanze cha vanno da 1 cm fino a 1400
cm. I risultati dell’esperimento vengono riportati nel grafico che segue:
93
Grafico 6.3 – Andamento dell’RSSI con la distanza
Questo grafico non è universale in quanto ogni dispositivo utilizza diversi livelli
di potenza, ma approssima bene il funzionamento di tutti i dispositivi in
generale.
L’RSSI, come già detto in precedenza, assume sia valori positivi che negativi. I
valori positivi sono assunti sempre quando i dispositivi sono molto vicini tra
loro, proprio ad indicare che la potenza utilizzata è superiore a quella necessaria
ed in questo breve tratto si nota che i valori decrescono esponenzialmente.
Quando, però, la distanza comincia ad aumentare, il valore dell’RSSI si assesta
al valore costante zero. Questo è un aspetto negativo in quanto non è possibile
dare una precisa stima della distanza tra il dispositivo ed il sensore; nel momento
in cui si rileva un RSSI pari a 0 non è possibile stabilire se il dispositivo dista
dall’access point 50 cm o 2 mt. Dopo questo tratto costante i valori decrescono
linearmente fino ad assestarsi al valore costante –10, per cui si ripresenta il
problema precedentemente illustrato.
94
6.4
Utilizzo del RSSI in un meccanismo di Positioning
La curva dell’RSSI in funzione della distanza tra le due unità Bluetooth
pone in evidenzia che non esiste una relazione biunivoca tra valori della distanza
e valori dell’RSSI. Ciò nonostante, l’utilizzo di questo indicatore ha mostrato,
nei test condotti sul meccanismo di positioning implementato , la sua efficacia
sulla possibilità di poter distinguere le diverse aree coperte dagli acces point
Bluetooth.
6.4.1 Test Sperimentale
Il test è stato condotto nel laboratorio ITEM del C.I.N.I.. La piantina del
laboratorio e le dimensioni delle sale oggetto dell’esperimento sono riportate in
figura 6.4 . I sensori sono stati posizionati nel centro del soffitto di ciascuna
stanza.
15 m
10,5 m
6m
6m
6m
6m
Figura 6.4 – Pianta del laboratorio con sensori Bluetooth disposti al centro del
soffitto di ciascuna sala.
95
Nella figura che segue, viene invece segnato uno dei percorsi eseguiti all’interno
del laboratorio durante il quale sono stati monitorati i valori dell’RSSI per
ciascuna delle connessioni attive tra terminale mobile e sensore.
“Stanza ROSSA”
-10
0
-10
-2
-9
0
-10
-8
-4
“Stanza BLU”
-10
-7
-5
-10
-3
-8
-10
-1
-8
-10
-2
-9
-9
-2
-10
-9
0
-10
“Stanza VERDE”
-10
0
-10
-8
-2
-6
-3
-5
-4
-6
-5
-1
-8
1
-9 0
-10
Figura 6.5 – Valori di RSSI rilevati in un percorso dalla stanza verde alla
stanza rossa
In particolare lungo il percorso vengono tratteggiato in figura sono riportate
alcune delle rilevazioni eseguite durante l’esperimento; sono indicati i valori di
RSSI relativi a ciascuna delle connessioni attive. Il colore del valore sta ad
indicare il sensore da cui proviene il segnale.
L’esperimento ha inizio nella sala verde mediante la procedura di Inquiry che
consente di rilevare i sensori posizionati nel raggio d’azione del dispositivo
96
mobile. Viene creata la connessione con i sensori “verde” e “blu”. A tal punto
comincia il monitoraggio.
Dalla osservazione della figura, tralasciando per il momento le zone cerchiate
che meritano una analisi specifica, si evince che le rilevazione dell’RSSI
consente di individuare correttamente la sala in cui è posizionato il dispositivo
mobile; infatti, il valore massimo di RSSI in ogni momento del percorso è
sempre quello relativo alla connessione con il sensore posto nella sala oggetto
della presenza del dispositivo mobile.
Analizziamo i valori riscontrati nelle zone evidenziate dai cerchi:
-
nella zona cerchiata tra la sala verde e la blu si riscontra poco prima di
uscire
dalla sala verde la seguente coppia di valori di RSSI: (-6,-5). Il
sistema di positioning, quindi, indicherà che la zona occupata coincide
con la sala blue anche se siamo ancora al limite di quella verde. Tra
l’altro in tale posizione la distanza dal sensore blue è maggiore rispetto a
quella dal verde.
Ciò è dovuto al fatto che uscendo dalla stanze verde, nelle zona al limite
tra le due stanze, si ha un duplice effetto. Da un lato, con la diminuzione
della potenza del segnale proveniente dal sensore verde si amplifica
l’effetto di attenuazione determinata dal corpo umano che si interpone
tra palmare e sensore, dall’altro, avvicinandoci al limite delle due sale,
svanisce l’effetto di attenuazione del segnale proveniente dal sensore blue
determinato dalle mura di separazione.
-
nell’angolo basso della stanza blu è cerchiata una zona in cui la terna di
valori di RSSI rilevata è data da (-3, -10 ,-8). Sebbene la distanza minima
si registra rispetto al sensore rosso, il massimo valore di RSSI si ha nella
connessione instaurato con il sensore blu. Evidentemente ciò va a tuttu
vantaggio del meccanismo di positioning che consente di rilevare la
corretta posizione del terminale mobile.
97
Anche in tal caso l’“anomalia” riscontrata rispetto al legame distanzaRSSI,, è spiegata dalla presenza della parete che separa i due ambienti e
che si interpone tra sensore rosso e palmare.
-
infine nella zona al limite tra la stanza rossa e quella blu (-7,-10,-5), si
riscontra lo stesso fenomeno rilevato al limite tra la stanza blu e verde.
Nella tabella 6.6 che segue vengono trascritti i valori di RSSI riscontrati nel
corso dell’esperimento sopra visualizzato, riportando
per ciascun punto di
rilevamento, nel percorso che va dalla stanza verde a quella rossa, la distanza da
ognuno dei sensori a cui si è connessi.
RSSI
Distanza dal
Distanza dal
Distanza dal
(v,b,r)
sensore ROSSO
sensore BLU
sensore VERDE
(0,-10)
-
13 m
2m
(1,-9)
-
12 m
1m
(-1,-8)
-
11 m
2m
(-6,-5)
-
10 m
3m
(-5,-4)
-
9m
4m
(-6,-3)
-
7m
6m
(-8,-2)
-
6m
9m
(-10,0,-10)
16 m
4m
12 m
(-10,-2,-9)
10 m
6m
16 m
(-10,-3,-8)
6m
7m
18 m
(-10,-1,-8)
9m
3m
17 m
(-9,0,-10)
10 m
1m
15 m
(-9,-2,-10)
16 m
4m
8m
(-10,-7,-5)
5m
7m
17 m
(-10,-8,-4)
3m
9m
19 m
(-9,0)
1m
11 m
-
98
(-10,0)
1m
12 m
-
Tabella 6.6 – Valori RSSI rilevati
Consideriamo una rappresentazione grafica (Grafico 6.7) dei valori di RSSI
raccolti; in particolare vengono rappresentate le curve dei valori di RSSI
riscontrati durante lo spostamento che va dal centro della stanza verde fino
all’uscita della stanza. Le due curve rappresentano i valori di RSSI relative alle
connessioni con i sensori verde e blu.
RSSI
3m
-0
1m
Zona Ideterminata
2m
-5
-10
Grafico 6.7 – RSSI relativi ai sensori verde e blu nello spostamento dal centro
della stanza verde verso l’uscita.
Dai risultati sperimentali si può affermare che il meccanismo di positionig
implementato consente la corretta individuazione della zona in cui opera il
dispositivo mobile. Il sistema, quindi, è efficiente rispetto ad un potenziale
utilizzo di informazioni e/o servizi disponibili nell’aree
coperte da ciascun
sensore. Le uniche incertezze evidenziate sono state rilevate nelle situazioni
99
limite di passaggio ad una nuova zona coperta da un nuovo sensore. Tuttavia
tali zone di indecisione non influenzano il funzionamento dell’applicazione.
6.5
Link Quality
Il link quality è un parametro che fornisce una stima della qualità della
connessione tra due unità Bluetooth. Esso è memorizzato all’interno di un
registro
hardware
e
può
essere
letto
utilizzando
il
comando
HCI
Get_Link_Quality.
Sebbene non sia un parametro di interesse primario per la implementazione del
servizio di positioning, ci consente di valutare quali effetti potrebbero aversi
sulla qualità di una connesione, in presenza di interferenze generate da
dispositivi che utilizzano la stessa gamma di frequenza dello standard Bluetooth.
Un valore elevato assunto dal link qualità non è significativo, ma un valore basso
sta ad indicare una forte interferenza. In tal caso le misure sull’RSSI non sono
attendibili.
6.5.1 Link Quality ed Bit Error Rate(BER)
In generale la qualità di un segnale ricevuto in un sistema è ben
rappresentato dal rapporto segnale rumore, ossia il rapporto tra la potenza del
segnale utile e la potenza del rumore di fondo. Un metodo per valutare il
rapporto segnale rumore è stimare il Bit Error Rate (BER) lato receiver dal
momento che vale la seguente relazione:
BER = (1 / 2)e − SNR / 2
Da questa relazione si evince che all’auentare del BER diminuisce il SNR
e quindi diminuisce anche la qualità del segnale in quanto aumenta il rumore e
100
tutto ciò a svantaggio della comunicazione. Il Link Quality, in effetti, misura
una media del BER sui pacchetti ricevuti. Più precisamente viene fatta una
statistica sui pacchetti che non sono stati ricevuti correttamente e che pertanto
devono essere ritrasmessi. Viene calcolato, cioè, il numero di pacchetti che non
sono stati ricevuti correttamente e, in riferimento a tutti i pacchetti inviati, si
calcola il valore in percentuale. Questo valore, quindi, indicherà la percentuale di
errore sui pacchetti ricevuti. Una volta calcolato il valore percentuale, esso viene
riportato su di una scala che va da 0 a 255 rappresentante il Link Quality.
In funzione del valore letto, quindi, è possibile risalire alla percentuale di errore
sui pacchetti ricevuti.
I valori che può assumere il Link Quality variano a seconda dei dispositivi
utilizzati e sono suddivisibili in tre fasce. In linea di massima i range rispettano
le tabelle di seguito riportate.
•
Tra 0xff e 0xd7 ogni valore rappresenta 0.0025% BER. Pertanto:
Valore
BER
0xff=255
0.0
0xfe
0.0025%
0xfd
0.0050%
0xfc
0.0075%
etc., until
0xd7
0.1%
Tabella 6.8: Valori assunti dal BER nel range 0xff e 0xd7
101
•
Tra 0xd6 e 0x5a ogni valore rappresenta 0.08% BER. Pertanto:
Valore
BER
0xd7
0.1%
0xd6
0.18%
0xd5
0.26%
etc.
Tabella 6.9 - Valori assunti dal BER nel range 0xd6 e 0x5a
•
Tra 0x59 e 0x00 ogni valore rappresenta 0.64% BER.
In definitiva, un collegamento con un BER che oscilla nel range 0 - 0.1% è
accettabile.
Nel momento in cui il BER raggiunge un valore pari all’1% si hanno scarsi
risultati nel momento in cui si cerca di trasmettere. Per valori superiori si può
dire che è impossibile trasmettere. Di seguito, il grafico 4.6 mostra come
all’aumentare del Bit Error Rate diminuisce il Link Quality.
Grafico 6.10 - Andamento del Link Quality in funzione del BER
102
6.5
Conclusioni
Il presente lavoro di tesi, che si colloca nell’ambito dell’affiorante
modello di computazione distribuita indicato col nome di nomadic computing,
ha avuto come obiettivo quello di proporre un approccio innovativo per la
localizzazione dei dispositivi mobili in ambienti indoor. La possibilità di
individuare la posizione di un terminale mobile rappresenta un degli argomenti
di ricerca di crescente interesse soprattutto in virtù del vasto scenario
di
Location Based Services che si sta aprendo, ad alto valore aggiunto sia per
l’utente che per il fornitore dei servizi.
Nella implementazione del meccanismo di positioning è stata
utilizzata la
tecnologia wireless Bluetooth dai bassi costi e sempre più diffusa sui terminali
mobili. L’approccio ha mostrato, nei test effettuati, di essere efficiente in
relazione al tipo di scenario considerato. Per l’implementazione in Java si è
resa necessaria un estensione delle API JSR-82 che
pur consentendo di
realizzare il discovery ed il delivery dei servizi su dispositivi Bluetooth non
presentano funzionalità per il positionig. E’ stata infine valutata una possibile
implementazione delle API per il positioning JSR 79 mediante l’estensione delle
JSR-82 suddetta.
Tutto ciò costituisce una buona premessa per un futuro lavoro che potrebbe
consistere
in un miglioramento del sistema di localizzazione mediante, ad
esempio , una modellazione accurata dell’ambiente di riferimento.
103
APPENDICE
Hardware Bluetooth che supportano BlueZ
Bluetooth PCMCIA and Compact Flash cards
Device
Chipset
Spec. Driver
State
Tester
Nokia Card
DTL-1
Nokia
1.0b dtl1_cs
working Marcel
Holtmann
Nokia Card
DTL-4
Nokia
1.1
dtl1_cs
working Kim Heino
Socket
Nokia
Compact Flash
Card
1.1
dtl1_cs
working Jussi Utunen
Socket Card
2.5
CSR
1.1
hci_uart
working Justin Hensley
Blue Monkey
CF Card
Ericsson/VLSI 1.1
bluecard_cs
working Marcel
Holtmann
Anycom
Ericsson/VLSI 1.0b bluecard_cs
PCMCIA Card
working Marcel
Holtmann
Anycom
Ericsson/VLSI 1.0b bluecard_cs
Compact Flash
Card
working Marcel
Holtmann
Sunderland
BLUEcard
Ericsson/VLSI 1.0b bluecard_cs
working S.W. Lei
Sunderland
BLUEflash
Ericsson/VLSI 1.0b bluecard_cs
working
Armadillo
Ericsson/VLSI 1.0b bluecard_cs
Bluetooth Card
working Sedat Gormus
Sphinx PICO
Card
Ericsson
1.0b btuart_cs /
hci_uart
working Marcel
Holtmann
H-Soft
blue+Card
Ericsson
1.0b btuart_cs /
hci_uart
working Marcel
Holtmann
Xircom
CreditCard
CBT
CSR
1.0b btuart_cs /
hci_uart
working Maksim
Krasnyanskiy
Xircom
RealPort2
R2BT
CSR
1.0b btuart_cs /
hci_uart
working Maksim
Krasnyanskiy
Brain Boxes
CSR
1.1
working Jean Tourrilhes
hci_uart
104
BL-620
Brain Boxes
BL-631
CSR
1.1
hci_uart
working
Brain Boxes
BL-500 (H4)
CSR
1.1
hci_uart
working Porlin Kang
Brain Boxes
BL-500
(BCSP)
CSR
1.1
hci_uart
should
work
Brain Boxes
BL-565
(BCSP)
CSR
1.1
hci_uart
working Ulrich Clanget
COM1
CSR
Platinum Card
1.1
hci_uart
working Marcel
Holtmann
HP Card
CSR
1.1
bt3c_cs
working Marcel
Holtmann
3Com Card
(Version 2.0)
CSR
1.1
bt3c_cs
working José Orlando
Pereira
3Com Card
(Version 3.0)
CSR
1.1
hci_uart
working David Riiber
Cyber-blue
BLUE CF01
CSR
1.1
btuart_cs
working David
Woodhouse
Mavin
CSR
Compact Flash
Card
1.1
btuart_cs
working Szelei Gabor
Billionton
CSR
Bluetooth Card
1.1
AmbiCom
BT2000
Ericsson
1.1
bt950_cs
working Troy A.
Griffitts
Pretec
CompactBT
Card
Ericsson
1.1
bt950_cs
working Marcel
Holtmann
Digianswer
Card
Digianswer
1.0b
not
working
Motorola Card Digianswer
1.0b
not
working
Toshiba Card
Digianswer
1.0b
not
working
IBM Card
Digianswer
1.0b
not
working
not
Richard
working Gaywood
105
IBM Card II
CSR
1.1
in
progress
TDK Card
CSR
1.1
in
progress
Acer Bluetooth
Shuttle
1.1
not
tested
TROY
WindPort Card
1.1
not
tested
Philips PC
Card
not
tested
BlueTake
BT100
not
tested
Bluetooth USB adapters
Device
Chipset
Spec. Driver
State
Ericsson
Ericsson
Application Toolkit
1.0b hci_usb
working Maksim
Krasnyanskiy
Ericsson
Development Kits
Ericsson
1.0b hci_usb
working Maksim
Krasnyanskiy
Broadcom
BCM2033
Broadcom
1.1
Zeevo TC2000
Development Kit
Zeevo
hci_usb
working Muthu Kumar
Bluefrog
Development Kits
Silicon
Wave
hci_usb
working Martin Leopold
Minikits based on
STLC2410
ST
1.1
hci_usb
working Naresh Gupta
Minikits based on
STLC2415
ST
1.1
hci_usb
working Naresh Gupta
CSR Casira USB
Adapter
CSR
1.1
hci_usb
working Fabrizio
Gennari
CSR Microsira
USB Dongle
CSR
1.1
hci_usb
working Felipe Gil
Castiñeira
TDK USB Adaptor CSR
1.1
hci_usb
working Tom Obermayr
3Com USB Dongle CSR
1.1
hci_usb
working Roman
Weissgaerber
Brain Boxes BL554
1.1
hci_usb
working Jean Tourrilhes
CSR
Tester
hci_usb + working Maksim
bluefw
Krasnyanskiy
106
COM1 USB
Module
CSR
1.1
hci_usb
working Marcel
Holtmann
Anycom USB
Adapter
CSR
1.1
hci_usb
working Marcel
Holtmann
Anycom USB-100 CSR
1.1
hci_usb
working Marcel
Holtmann
Intel USB Adapter CSR
hci_usb
working Maksim
Krasnyanskiy
SuperBT SBT-100 Ericsson
hci_usb
working Ilguiz Latypov
Siemens USB
Adapter
1.0b
not
tested
Motorola USB
Adapter
1.0b
not
tested
ALPS USB Module CSR
1.0b
not
tested
NSM USB Dongle NSC
not
tested
Digianswer USB
Dongle
Digianswer
not
Greg Kroahworking Hartman
Digianswer USB
Development Kit
Motorola
1.1
hci_usb
working Jan J. Jessen
AVM BlueFRITZ! AVM
USB
1.1
bfusb
working Marcel
Holtmann
Teledat C120data
1.1
bfusb
working Marcel
Holtmann
ELSA Vianect blue CSR
USB
1.1
hci_usb
working Marcel
Holtmann
Mitsumi USB
Adapter
CSR
1.1
hci_usb
working Takashi Sasai
BlueGear USB
Adapter
CSR
1.1
hci_usb
working Joseph Wu
Acer USB Adapter CSR
1.1
hci_usb
working Jörg
Hilsebecher
Silicon Wave USB Silicon
Module
Wave
hci_usb
working Ilguiz Latypov
Taiyo Youden USB Silicon
Module
Wave
hci_usb
working Ilguiz Latypov
Tecom BT3030
AVM
Broadcom
1.1
hci_usb + working Johannes Erdfelt
107
bluefw
W-Link WBT-3020 Broadcom
1.1
hci_usb + working Lars Haack
bluefw
D-Link DWB120M
Broadcom
1.1
hci_usb + working Andrew Radke
bluefw
D-Link DBT-120
(Rev A1)
Broadcom
1.1
hci_usb + working Edd Dumbill
bluefw
D-Link DBT-120
(Rev A2)
Broadcom
1.1
hci_usb + working Curtis Lehman
bluefw
D-Link DBT-120
(Rev B1)
CSR
1.1
hci_usb
working Noli Sicad
Gigabyte GNBTD01
CSR
1.1
hci_usb
working Jim Lomas
EPoX BT-DG02
CSR
1.1
hci_usb
working Robert Fox
EPoX BT-DG03
CSR
1.1
hci_usb
working Raimonds
Cicans
MSI MS-6967
CSR
1.1
hci_usb
working Dave Beckett
MSI MS-6968
CSR
1.1
hci_usb
working Kjell M.
Myksvoll
MSI MS-6970
CSR
1.1
hci_usb
working Stephen Crane
Gericom Adapter
CSR
1.1
hci_usb
working Michael
Kaufmann
SCM Bluetooth Zio CSR
1.1
hci_usb
working Andreas
Pfaffeneder
EIO WaveLinker
CSR
1.1
hci_usb
working Chris St.John
Microsoft Wireless CSR
Transceiver
1.1
hci_usb
working Ralf Ackermann
Sony PCGA-BA1
CSR
1.1
hci_usb
working Alain Volmat
Digicom Palladio
USB Dongle
CSR
1.1
hci_usb
working Luca Gibelli
BlueTake USB
Dongle BT007S
CSR
1.1
hci_usb
working Pawel
Pierscionek
BlueTake USB
Dongle BT009S
CSR
1.1
hci_usb
working Tymoteusz
Rogalewski
BlueTake USB
Dongle BT009V
CSR
1.1
hci_usb
working Rafal Bielinski
EPoX BT-MD01
108
i-Tec Bluetooth
USB Dongle
CSR
1.1
hci_usb
working Zdzislaw A.
Kaleta
Sitecom USB
Dongle
CSR
1.1
hci_usb
working Jelmer Vernooij
IVT USB Dongle
CSR
1.1
hci_usb
working Jens Wiessner
AboCom USB
Dongle
CSR
1.1
hci_usb
working Jens Wiessner
Samsung USB
Dongle
CSR
1.1
hci_usb
working Jens Wiessner
CCnC USB Dongle CSR
1.1
hci_usb
working Jens Wiessner
Windigo USB
Dongle
CSR
1.1
hci_usb
working Jens Wiessner
Billionton USB
Dongle
CSR
1.1
hci_usb
working Jens Wiessner
GlobalLink USB
Dongle
Broadcom
1.1
hci_usb + working Jens Wiessner
bluefw
WNi BlueLink
USB Dongle
Broadcom
1.1
hci_usb + working Michal Semler
bluefw
PheeNet BT-222
USB Dongle
Broadcom
1.1
hci_usb + working Marcel
bluefw
Holtmann
Allnet ALL1570
USB Dongle
Broadcom
1.1
hci_usb + working Matthias
bluefw
Thomae
Allnet ALL1575
USB Dongle
CSR
1.1
hci_usb
freeControl USB
Adapter
Broadcom
1.1
hci_usb + working Christoph
bluefw
Rieder
IOGEAR GBU301 Broadcom
USB Adapter
1.1
hci_usb + working J Robert Ray
bluefw
IOGEAR GBU302 Broadcom
USB Adapter
1.1
hci_usb + working J Robert Ray
bluefw
Belkin F8T001
USB Adapter
Broadcom
1.1
hci_usb + working Misha Pavlov
bluefw
Keyspan BT-2A
USB Adapter
Broadcom
1.1
hci_usb + working Andre N.
bluefw
Klingsheim
Belkin F8T003
USB Adapter
CSR
1.1
hci_usb
working Nayib Kiuhan
Trust BT120 USB
Adapter
Transilica
1.1
hci_usb
working Simon de
Hartog
109
working Sancho
Dauskardt
AIPTEK Instant
Blue USB
Transilica
1.1
hci_usb
working Chris Day
DSE XH4104 USB Transilica
Adapter
1.1
hci_usb
working Chris Day
Bluetooth serial dongles
Device
Chipset
Spec. Driver State
Ericcson
Development Kits
Ericsson
hci_uart working
Maksim
Krasnyanskiy
Silicon Wave Kits
Silicon
Wave
hci_uart working
Thomas Moser
Minikits based on
STLC2410
ST
1.1
hci_uart working
Naresh Gupta
Minikits based on
STLC2415
ST
1.1
hci_uart working
Naresh Gupta
Inventel BlueBird
Module
Inventel
1.1
hci_uart working
Alaattin Caliskan
Infineon PMB8760 Infineon
v1.1
1.1
hci_uart working
Jean-Yves
Bitterlich
Digianswer Serial
Dongle
Digianswer
hci_uart working
CSR Casira Serial
Adapter
CSR
hci_uart working
Brain Boxes BL642
CSR
hci_uart working
Brain Boxes BL510 (BCSP)
CSR
hci_uart working
Sphinx PICO Plug
Ericsson
not
working
Philips Truebaby
Module
Tester
Marcel Holtmann
not tested
Other Bluetooth devices
Device
Chipset
Spec. Driver
Sony Picture Book
C1VFK
CSR
hci_usb +
sonypi
working Timothy
Murphy
Sony Picture Book
CSR
hci_usb +
not
110
State
Tester
C1VSX
sonypi
tested
Sony Picture Book
C1VRX
CSR
hci_usb +
sonypi
working Takashi Sasai
Sony Picture Book
C1VRK
CSR
hci_usb +
sonypi
working Takashi Sasai
Sony Picture Book
C1MRX
CSR
hci_usb +
sonypi
not
tested
Sony Picture Book
C1MGP
CSR
hci_usb +
sonypi
working Kai Engert
Sony Picture Book
C1MV
CSR
hci_usb +
sonypi
not
tested
Sony Picture Book
C1MHP
CSR
hci_usb +
sonypi
working Florian Lohoff
Sony Notebook
SR31K
CSR
hci_usb +
sonypi
not
tested
Sony Notebook
SR9G
CSR
hci_usb +
sonypi
working Takashi Sasai
Sony Notebook
SR9K
CSR
hci_usb +
sonypi
working Takashi Sasai
Sony Notebook
SRX7
CSR
hci_usb +
sonypi
working Takashi Sasai
Sony Notebook
SRX7E
CSR
hci_usb +
sonypi
working Takashi Sasai
Sony Notebook
SRX7P
CSR
hci_usb +
sonypi
working Takashi Sasai
Sony Notebook
SRK41P
CSR
hci_usb +
sonypi
working Iain Allan
Sony Notebook
SRX41P
CSR
hci_usb +
sonypi
working
Sony Notebook
SRX51P
CSR
hci_usb +
sonypi
working
Sony Notebook
SRX51P/A
CSR
hci_usb +
sonypi
working Mike Bremford
Sony Bluetooth
Infostick
1.1
Compaq iPAQ
H3970
CSR
1.1
hci_uart
working Marcel
Holtmann
Compaq iPAQ
CSR
1.1
hci_uart
working Jan Beutel
111
H3870
Compaq iPAQ
Bluetooth Sleeve
CSR
1.1
hci_uart
working Muthu Kumar
Compaq Multiport
Bluetooth
CSR
1.1
hci_usb
working Metod Kozelj
IBM Ultraport
Bluetooth
CSR
1.1
hci_usb
working Dirk
Husemann
IBM Notebook
A30p (TV066GE)
CSR
1.1
hci_usb
working Tobias Engel
IBM ThinkPad T30
(2366 92G)
CSR
1.1
hci_usb
working Anders Johan
Jamtli
Toshiba Portégé
4000
Silicon
Wave
1.1
hci_usb +
toshiba
working Martin Dietl
Toshiba Portégé
4100
Silicon
Wave
1.1
hci_usb +
toshiba
working Martin Dietl
Toshiba Satellite
5100
Silicon
Wave
1.1
hci_usb +
toshiba
not
tested
Toshiba Satellite Pro Silicon
6000
Wave
1.1
hci_usb +
toshiba
not
tested
Toshiba Satellite Pro Silicon
6100
Wave
1.1
hci_usb +
toshiba
not
tested
Toshiba Satellite
S5200-801
Silicon
Wave
1.1
hci_usb +
toshiba
working
Toshiba Tecra 9000 Silicon
Wave
1.1
hci_usb +
toshiba
working Martin Dietl
Toshiba Tecra 9100 Silicon
Wave
1.1
hci_usb +
toshiba
working Martin Dietl
Fujitsu Lifebook B2547
Fujitsu Lifebook B2548
Fujitsu Lifebook E7010
Fujitsu Lifebook E7110
Fujitsu Lifebook S6010
CSR
1.1
hci_usb
working Tobias
Rundström
Fujitsu Lifebook S-
CSR
1.1
hci_usb
working Gabor
112
6120
Halaszvari
TDK BluePaq
MSI 845E Max2BLR
CSR
1.1
hci_usb
working Alexandros
Karypidis
Sphinx PICO PCI
CSR
1.1
picopci
in
Marcel
progress Holtmann
Bibliografia
Capitolo 1
[1]
[2]
[3]
[4]
[5]
Mascolo, Capra, Emmerich. Mobile Computing Middleware. Dept. of
computer Science, University College London. 2002
Lyytinen, Yoo. Issues and challenges in Ubiquitous Computing.
Communication of ACM. 2002
Kindberg, Fox. System software for Ubiquitous Computing. IEEE
computer society press. 2002
Henricksen, Indulska, Rakotonirainy. Infrastructure for pervasive
computing: Challenges. School of computer Science, University of
Queensland. 2000
M. Weiser, “Some Computer Science Issues in Ubiquitous Computint”,
Comm ACM, Vol. 36, No. 7, pp 720-84, July 1993
Capitolo 2
[1]
http://www.ieee.com
[2]
http://www.ieee.com
[3]
Antti Kotanen, Marko Hannikainen, Helena
Timo
113
Leppakoski,
Hamailainen
“Experiments
on
Local
Positioning
with
Bluetooth”Internatio
nal Conference on Information Technology: Coding and
Computing (ITC
C 2003)
Capitolo 3
[1]
“Coordinate
Systems
Overview”
–
P.H.Dana
http://www.colorado.edu/geography/gcraft/notes/coordsys/
[2] “La Georeferenziazione nella gestione delle Informazioni
Geografiche Digitali” – Raffaele Gargiulo
http://www.analisidifesa.it/numero17/do-geo.htm
[3] “Map
Projection
Overview”
–
P.H.Dana
http://www.colorado.edu/geography/gcraft/notes/mapproj/
[4] “Geodetic
Datum
Overview”
–
P.H.Dana
http://www.colorado.edu/geography/gcraft/notes/datum/
[5] “In rete con la comunicazione geografica”, AA.VV., pag. 266
[6] “A Framework for Indoor Geolocation using an Intelligent System” –
Chahé
Nerguizian,
Charles
Despins,
Sofiène
Affes
http://www.wlan01.wpi.edu/proceedings/wlan44d.pdf
[7] “Location Sensing Tecniques” – J.Hightower, G.Borriello
[8] http://www.fcc.gov/911/enhanced/
[9] http://www.fcc.gov/Bureaus/Wireless/News_Releases/2001/nwl0127
a.pdf
[10] “Location Systems for Ubiquitous Computing” – J.Hightower,
G.Borriello
www.cs.washington.edu/homes/jeffro/pubs/hightower2001location
[11] “Global Positioning System Overview” – P.H. Dana
http://www.colorado.edu/geography/gcraft/notes/gps/
[12] http://www.trimble.com/gps/clockerrors1.html
[13] http://www.mobilein.com/mobile_positioning.htm
[14] “Radio propagation modelling for indoor geolocation applications” –
P. Krishnamurthy, K. Pahlavan, J. Beneat
[15] “RADAR: An In-Building RF-based User Location and Tracking
System“ –
P.Bahl, V.N. Padmanabhan
http://research.microsoft.com/~bahl/MS_Projects/projects.html
[16] “The Viterbi Algorithm” – G.D.Foney, Proc. of IEEE vol.61 , 1973
[17] “The Active Badge Location System” – R.Want, A.Hopper, V.Falcao,
J.Gibbons
http://www.uk.research.att.com/pub/docs/att/tr.92.1.pdf
[18] http://www.uk.research.att.com/
114
[19] “Active Bat” – http://www.uk.research.att.com/bat/
[20] “Cricket” – http://nms.lcs.mit.edu/papers/cricket.pdf
[21] “Easy Living” – http://research.microsoft.com/easyliving/
[22] “Towards a Location-Based Context-Aware Sensor Infrastructure” –
Scott Klemmer, Sarah Waterson, and Kamin Whitehouse
[23] http://www.cs.unc.edu/~welch/media/pdf/kalman_intro.pdf
[24] “Indoor Super Resolution TOA Measurement in Frequency-Domain”
– X. Li, K. Pahlavan
http://www.wlan01.wpi.edu/proceedings/wlan55d.pdf
[25] “914 MHz path loss prediction Model for Indoor Wireless
Communications in Multi-floored buildings” – S. Y. Seidel, T. S.
Rapport, IEEE Trans. on Antennas & Propagation, Feb. 1992
[26] “Principles and Applications of Radiowave Propagation in Mobile
Environments”– V. Mark Nishanian,
http://ece.gmu.edu/~pceperle/projs513/Nishanian/RadioP.htm
[27] “Using Calibration in RSSI-based Location Tracking System” –
M.Helen, J.Latvala, H.Ikonen, J.Niittylahti
[28] “Localized Algorithms In Wireless Ad-Hoc Networks:
Location Discovery And Sensor Exposure” –
S.Meguerdichian, S.Slijepcevic, V.Karayan, M.Potkonjak
[29] “Locationing In Distribuited Ad-Hoc Wireless Sensor Network” –
C.Savarese, J.M.RabaeyJan Beutel
[30] “Design and Calibration of the SpotON Ad-Hoc Location Sensing
System” – J.Hightower,C.Vakili1,G.Borriello, R.Want
[31] “Measurement Analysis of Spatial and Temporal Correlation in
Wideband Radio Channels with Adaptive Antenna Array” –
P.Karttunen,K.Kalliola,T.Laakso,P.Vainikainen
[32] “A Multipath Channel Estimation Algorithm using a Kalman filter” –
Rupul Safaya
[33] “Geolocation in a PicoRadio Enviroment” – J.Beutel
[34] “Management Of Geographic Information In Mobile Environment” –
Garmash Artem
Capitolo 4
[1] BTSIG, Specification of Bluetooth System, v1.1, volume 1, CORE, 2001,
http://www.bluetooth.com/pdf/Bluetooth_11_ Specifications_Book.pdf
115
[2] ETSI Telecom Standard, http://www.etsi.org/
[3] Pravin Bhagwat, “Bluetooth: Tecnology for Short-Range Wireless Apps”,
IEEE Internet Computing online, pp. 96 – 103 (IEEE 2001)
[4] PaloWireless, Wireless Resource Center, http://www.palowireless.com/
[5] Jaap C. Haartsen and Stefan Zurbes, “Bluetooth voice and data performance
in 802.11 DS WLAN environment”, Technical report, Ericsson Mobile
Communication, 1999
[6] HomeRF, “Interference immunity of 2.4 GHz wireless LANs”, Technical
report, http://www.homerf.org, 2001
[7] Mobilian, “Wi – Fi (802.11b) and Bluetooth simultaneous operation:
Characterizing the problem”, Technical report, http://www.mobilian.com,
200
[8] Handing of Bluetooth, - http://www106.ibm.com/developerworks/wireless/library/wi-handblue/
[9] JblueZ, http://jbluez.sourceforge.net/
[10] Appliance Studio, http://www.appliancestudio.com/
[11]
http://www.anycom.com
Capitolo 5
[1] JblueZ, http://jbluez.sourceforge.net/
[2] JSR-179, http://www.jcp.org/en/jsr/detail?id=179
[3] JSR-82, http://www.jcp.org/en/jsr/detail?id=182
[4] http://www.bluetooth.org/assigned-numbers/sdp.htm
116
117