Hello Nordic community,
I'm wondering about how those BLE trackers (i.e. Tile, Trackr) work. Specifically, what kind of advertisement strategy makes sense for these types of devices, given their two main features.
Main Features:
1) Advertise every X seconds so that a smart phone app can track individual "Tiles". So they have some kind of unique ID.
2) Allow for connection and authentication so only your smart phone can make the embedded buzzer sound off.
Would each Tile device be advertising as a connectable undirected (ADV_IND) or a connectable directed (ADV_DIRECT_IND)? I'm assuming it's connectable in order for the phone to make a GATT connection and activate the buzzer service. But if it's advertising as connectable, that means it's also listening for a CONNECT_REQ, which consumes a non-trivial amount of battery (maybe adds 1/4th the energy used for advertisement transmissions alone). Having to listen after each advertisement seems detrimental to battery life, given that most of the advertisements are for purpose of tracking on the phone rather than for actual connection requests. So, maybe use this advertisement strategy?
Advertisement Strategy?
a) Every 5 seconds, advertise as Non-connectable Undirected (ADV_NONCONN_IND) for tracking purposes only. So not waste power scanning for connection requests.
b) Every 30 seconds, advertise as connectable (ADV_IND or ADV_DIRECT_IND), so that a phone app use has to wait a maximum of half a minute to have a window of opportunity to connect to Tile and actuate the buzzer?
Another question I have is how the app and general system tracks unique ID's. Are they just tracking the MAC address of the BLE device? Doesn't that open up a lot of opportunities for anyone to track you as you walk around? Or does BLE provide a clever way of anonymizing the MAC address for the general public, but put application-level data in a advertisement payload that the app uses in conjunction with the cloud to uniquely identify Tile devices?
Finally, if you catch a ADV_IND or ADV_DIRECT_IND, then anyone can send Conn_Req to that Tile. So...
1) How does the embedded Tile firmware ensure that only the owner of the Tile is able to make connections in the first place? Does it do so prior to responding to the Scan_Request or is the authentication at the application level and has to allow for connections before being able to authenticate the phone as a valid user?
2) If it request forming a connection and performing an application level data exchange to verify that the smart phone is the Tile owner, can you make a malicious device that constantly tries to connect to Tile products and drain their batteries by constantly making Conn_Req?
Sorry, long question with lost of mini questions. But I'm just trying to understand how these thing might work.
