Download to read offline
![Experiments
• 2 Samsung Nexus S phones
• Both running Android 2.3.3
• Both phones
• continuously update their Bluetooth device names once every
second with the current local time
• perform periodic Bluetooth device inquiries
• Local clocks of the devices are only loosely synchronized with a
clock offset of 9.5 seconds.
0 500 1000 1500 2000 2500 3000 3500
Time [s]
0
5
10
15
20
25
30
35
Time[s]
Time Difference Sender-Receiver
Lower Bound for Clock Offset
Latency Sender-Receiver (after Correction)](https://image.slidesharecdn.com/conet12-160518012058/75/Towards-Collaborative-Localization-of-Mobile-Users-with-Bluetooth-18-2048.jpg)
Uploaded byRaja Jurdak
Towards Collaborative Localization of Mobile Users with Bluetooth
The document discusses a collaborative Bluetooth localization system for mobile users that operates indoors and outdoors, offering an energy-efficient alternative to GPS. It addresses issues related to device name caching and proposes methods to enhance localization accuracy by using timestamps to establish clock offsets between devices. The findings indicate that this system can fill coverage gaps and improve localization density without the need for additional infrastructure.
More Related Content
Similar to Towards Collaborative Localization of Mobile Users with Bluetooth
Towards Collaborative Localization of Mobile Users with Bluetooth
- 1. Towards Collaborative Localizationof Mobile Users with Bluetooth Alexandre Barreira CSIRO ICT Centre, Brisbane, Australia Philipp Sommer Brano Kusy Raja Jurdak UTC/Georgia Tech.
- 2. Localisation • Indoors • Specializedtracking devices • Infrastructure deployment cost • Setup phase • Outdoors • GPS! • Reasonably accurate … • …yet energy expensive • Collaborative Bluetooth Localisation • Can help both • Built-in to smart phones/laptops • No infrastructure/setup in office environments • More energy-efficient than GPS
- 3. • Problem • Protocolimposes pairing/piconet association • Solution • Avoid expensive handshake • Use friendly name to share location info – up to 248 characters • Embed location info • Indoors: coordinates • Outdoors: GPS • Problem • Infrastructure setup • Solution • Use only existing infrastructure with bluetooth • Laptops • Desktops • Use office directory to map names to locations Bluetooth Localization Overview
- 4.
- 5. Collaborative Bluetooth Localisation Canfill coverage gaps X X X
- 6.
- 7. Collaborative Bluetooth Localisation X Canprovide denser coverage
- 8. Bluetooth neighbor discovery Usefrequency hopping to transmit and listen to neighbors A B C
- 9. Bluetooth neighbor discovery Ahas list of neighbor MAC addresses A B C Neighbor Address MACB MACc
- 10. Bluetooth neighbor discovery Arequests friendly name of each neighbor in second step A B C name? (name, RSSI, class)
- 11. Bluetooth neighbor discoveryfor localization name = (LOCx, LOCy, LOCz) A B C name? (name, RSSI, class) Neighbour Location RSSI class B C 2,3,4 4,3,5 -75 -66 Phone Desktop
- 12. RSSI to bounddistance
- 13. Device Name Caching •Discovery phase every several seconds •Varies per device/manufacturer • In the meantime, node keeps neighbor location information •Risks stale neighbor list •Risks inaccurate location •Smart phone OS limits control •No methods to flush cache •Caching strategies vary per device model/OS version
- 14. Rejecting cached devicenames • Include timestamp into device name • Receiver can estimate time offset between remote device and local clock name = (LOCx, LOCy, LOCz, t) A B C name? (name, RSSI, class) Neighbou r Locatio n time Min offset RSSI class B C 2,3,4 4,3,5 20 35 19 13 -75 -66 Phone Desktop
- 15. Simple Approach toReject Cached Names • Assumption: mobile phone clocks remain stable over short time intervals • Set (or learn) lower bound for time offset with each neighbor • IF a name with offset>lower bound+c • Discard this name
- 16. Rejecting cached devicenames • Include timestamp into device name • Receiver can estimate time offset between remote device and local clock name = (LOCx, LOCy, LOCz, t) A B C name? (name, RSSI, class) Neighbou r Locatio n time Min offset RSSI class B C 2,3,4 4,3,5 20 35 19 13 -75 -66 Phone Desktop
- 17. Rejecting cached devicenames • Include timestamp into device name • Receiver can estimate time offset between remote device and local clock name = (LOCx, LOCy, LOCz, t) A B C name? (name, RSSI, class) Neighbour Locatio n time Min offset RSSI class B C 2,3,4 4,3,5 20 35 19 13 -75 -66 Phone Desktop
- 18. Experiments • 2 SamsungNexus S phones • Both running Android 2.3.3 • Both phones • continuously update their Bluetooth device names once every second with the current local time • perform periodic Bluetooth device inquiries • Local clocks of the devices are only loosely synchronized with a clock offset of 9.5 seconds. 0 500 1000 1500 2000 2500 3000 3500 Time [s] 0 5 10 15 20 25 30 35 Time[s] Time Difference Sender-Receiver Lower Bound for Clock Offset Latency Sender-Receiver (after Correction)
- 20. Summary • Collaborative Bluetoothlocalization • Indoors • Fill coverage gaps • Increase density • Outdoors • Saves on using GPS frequently • Simple method to avoid device name caching • Establish pairwise clock offsets • Discard names that diverge from these offsets • Open issues • Learning and adapting pairwise offsets • Bounding uncertainty with high mobility • Versatile localization algorithms
- 21. Thank you Thank you Dr.Raja Jurdak CSIRO ICT Centre Principal Research Scientist Research Group Leader Phone: +61 (0)7 3327 4059 Email: raja.jurdak@csiro.au Web: http://jurdak.com University of Queensland Adjunct Associate Professor
Editor's Notes
- #3 Although several other GP frameworks are available for the Java platform, none is suitable for Android because Android replaces several subsets of Java class libraries from the JavaSE with its own new classes.