Blue Tears Project

1. Blue Tears Project Bluetooth Tracking: Distributed Information Systems

2. Introduction • Bluetooth tracking system • Approximate tracking • BT is limited to a 10m radius • Transfer rate 3mb/s • 90% of current cell phones & smartphones have Bluetooth tech built-in. • Not limited to just phones. Can track all BT devices

3. Bluetooth Tracking System • Approximate location tracking • 4 major parts • Bluetooth Discovery Access point, Bluetooth Access point, Central server and Data Base. • Uses a WIFI connection for RMI connection • RMI used to communicate with Server and Access points

4. Bluetooth Tracking System(cont) • Tracking by floor levels • Scenarios which could use BTT system • Tracking traffic in malls • Distribution of man power • “finding babies” • Data mining, commonly traveled routes • Clocking in/out system • Locating medical devices/patients/doctors

5. Bluetooth Tracking System(cont) • Coded in JAVA • Using Bluecove Java library for Bluetooth • JSR-82 implementation • Bluecove provides interface to application profiles: • SDAP • RFCOMM • OBEX • *information provided by Bluecove.org

6. The Approach • Other tracking systems use two way communication between client and server • Some send request to find current location only • Fairly simple, lose valuable data, and requires a lot of client input. • Our approach keeps track of the client’s movements (currently up to the last 10 access points)

7. The Approach • Closest neighbor algorthim • Avoid overloading the AP with devices to check • Guess the next possible AP the client could come across • Client is transparent to tracking system, little to no input from end user • Uses registered Bluetooth address rather than continuous Device Discovery (upto 90sec to discover device) • Majority of computation on the Server side, putting less stress on the client and AP

8. Closest Neighbour Access Point 2 Access Point 3 Access Point 1 Access Point 4 Access Point 5

9. Closest Neighbour Access Point 2 Access Point 3 Access Point 1 Access Point 4 Access Point 5

10. Closest Neighbour Access Point 2 Access Point 3 Access Point 1 Access Point 4 Access Point 5

11. Closest Neighbour Access Point n Access Point 3 Access Point 2 Access Point n’ Access Point 1 ap5 ap4

12. Object Diagram Server Manager mySql ManagerInterface interfaces RMICommunication AccessPoint Interface Access Point 1 Access Point n ……..... Client 1 Client n ….

13. Components • 4 major components • Bluetooth access points • Bluetooth init access points • Central Server • Data Base • Future components • Client software

14. Bluetooth Init Access Point • Client would register their Bluetooth device, usually cell/smart phone • Client sets device to discovery for a minute and waits for conformation • Ap continues checking for new devices • Once discovered is then searched to see what services as available • This could take upwards to 30 – 90 secs depending on demand and device transfer rate • Current version is not configured to run continuously.

15. Bluetooth Init Access Point • Once the Ap gathers all the required information an update is sent to the Database. • Ideally you need to register only once and your Bluetooth address is stored for future use

16. Bluetooth Access Points • Waiting for server to allocate bluetooth address for it to “ping” • Continues to try pinging bluetooth address • If found it sends a response to server that it’s found the device at the ap location • Requires only one “ping” response.

17. Central Server • Consists of the AP manager, Server and Data base manager • Server inits all services • AP manager registers AP and delegates which AP to search which Bluetooth address • AP manager organizes all input information from AP

18. Central Server • Database Manager updates and extracts information from the DB • Mapping AP Zones • Bluetooth Address and tracking history

19. Assumptions • The client is not sprinting across the Bluetooth Access points • Client within an access point range at all times • Access points don’t overlap (due to java constraints) • Bluetooth address attribute is not altered during the session • Access points are mapped by installer and updated to the Database manually.

20. Crashes • No failsafe for failed AP • Possible solution: if hardware fails reach out to the downed AP’s neighbors. • Software fail: thread is recreated if it dies. • Server fails • Possible solution Leader algorthim • AP fitted with central server services and fights for control/leadership.

21. Bluetooth specs • 10 meters radius • Transfer 3mb/s • One tenth the power and range used for WIFI • Limited connection, 7 connection • Industrial BT AP up to 24 connection

22. Constraints For the demo • Limited to 3 access points (ideally we would like to have 10s – 100s of access points spread across a large area) • Limited to 1 client • Bluetooth Adapters limited to one connection at a time. Hardware limitation can be resolved with industrial BT access points

23. Constraints (cont) • Client software, different sdk for different phones.

24. Difficulties • Interface with JSR-82 • Use bluecove java lib • Hardware requirements, not enough to test with • No solution • Java can not detect range and signal strenght – • lower level languages • AP overlapping while testing • Make sure no AP’s overlap

25. Demo