Using bluetooth to identify devices in range out of potentially thousands?

Question

Greetings!

The idea is simple. Let's say that I have a service wherein people can walk up to a kiosk and "pair their phone" with a bluetooth device on that kiosk. We'll ignore why people would do this, but let's say that they have an incentive to do so.

Let's say that I have convinced thousands (if not millions) of people to do this thing... and they're walking around with their cellphones with bluetooth ON. (Not discoverable.) How do I solve the problem of scanning for "known devices" if there is a possible pool of millions of known devices?

Again, I don't want to connect with them once I've actually done the initial pairing. I simply want to know they are proximate.

Thoughts?

Answer 1

Well, the first thing is that even if your kiosk has a Class 1 Bluetooth radio in it, which can actually go farther than the advertised 100 meters, it's still extremely unlikely that there will be millions of Bluetooth cell phones who have previously paired with your kiosk within the range of your kiosk's radio. So that narrows down the potential number of Bluetooth devices you're dealing with.

Second, if a device is not discoverable, then it doesn't matter if you've paired with it before or not. You will not find it using a general "Hello, is anybody out there?" inquiry scan. If you've paired with a device, you will know its Bluetooth Device Address and can therefore ping it explicitly and get an answer. This doesn't seem like a reasonable thing to do if you're thinking you might have millions of cell phones paired with your kiosk. (Have you thought about the fact that if you have multiple kiosks your users would have to pair with each kiosk separately? Do you really need to pair with the cell phones to do what you need to do?)

Having said all that, a general inquiry scan will produce a list of discoverable Bluetooth devices in the vicinity of your kiosk's radio. You could use that list to search your own list of devices paired with the kiosk. I can't remember if you get back just the friendly name in the first response or if you get a BD_ADDR as well. If you just get the friendly name, there could be multiple devices with the same friendly name, as I doubt many users change their phones' friendly names.

It's been a while since I really delved into the Bluetooth spec so things may have changed.

Answer 2

Pairing may be overkill: that's about establishing secure communications. Worse, ISTR some phone UIs don't separate pairing (having a secure channel) and trust (allowing the remove device to do stuff without asking the user whether it should), although I hope modern phones get this right.

If you just want the other device's Bluetooth address, you could get people to send the kiosk a business card or something. Or tell them to become discoverable and have your kiosk initially find them. Or they could pair, but as Kirsten says, they'd be paired with a single kiosk: you may not care if all you want is their address, though, rather than the secure channel.

Now you've got a list of Bluetooth addresses. You can share these addresses between multiple kiosks if you've got some sort network between them. In an ideal world, detecting proximity would then be a matter of performing BT inquiry (you don't even need full device discovery here, just knowing what addresses are out there is enough) and matching the addresses you get from that against your list. But that only works when remote devices are discoverable (which means they're listening for inquiry packets, doing what the spec calls inquiry scanning). If they aren't, you'd have to try to connect to each one in turn (you can drop the connection once you know the other guy is there). You could parallelise this with multiple BT radios, but you're looking at a few seconds per address per radio. You're doing the old "Redfang" brute-forcing that people got excited about a few years ago, but it's going to be slow: http://www.newswireless.net/index.cfm/article/924

Of course, if people aren't leaving their devices discoverable, the implication is they don't want to be found, so it's not surprising that this doesn't work.