Towards Collaborative Localization of Mobile Users with Bluetooth

1. Towards Collaborative Localization of Mobile Users with Bluetooth Philipp Sommer Brano Kusy Raja Jurdak UTC/Georgia Tech. Alexandre Barreira CSIRO ICT Centre, Brisbane, Australia

2. Localisation • Indoors • Specialized tracking 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. Bluetooth Localization Overview • Problem • Protocol imposes 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

4. Infrastructure-based Bluetooth Localisation X Bluetooth Coverage Gaps

5. Collaborative Bluetooth Localisation X X X Can fill coverage gaps

6. Infrastructure-based Bluetooth Localisation X Sparse coverage

7. Collaborative Bluetooth Localisation X Can provide denser coverage

8. Bluetooth neighbor discovery A B C Use frequency hopping to transmit and listen to neighbors

9. Bluetooth neighbor discovery A B C A has list of neighbor MAC addresses

10. Bluetooth neighbor discovery A name? (name, RSSI, class) B C A requests friendly name of each neighbor in second step

11. Bluetooth neighbor discovery for localization A name? (name, RSSI, class) B C name = (LOCx, LOCy, LOCz)

12. RSSI to bound distance

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 device names • Include timestamp into device name • Receiver can estimate time offset between remote device and local clock A name? (name, RSSI, class) B C name = (LOCx, LOCy, LOCz, t)

15. Simple Approach to Reject 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 device names • Include timestamp into device name • Receiver can estimate time offset between remote device and local clock A name? (name, RSSI, class) B C name = (LOCx, LOCy, LOCz, t)

17. Rejecting cached device names • Include timestamp into device name • Receiver can estimate time offset between remote device and local clock A name? (name, RSSI, class) B C name = (LOCx, LOCy, LOCz, t)

18. 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.

20. Summary • Collaborative Bluetooth localization • 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 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 Thank you