Speeding up device discovery: paper

[Bruce M Simpson]

Iain Hibbert wrote:
> On Thu, 9 Apr 2009, Bruce Simpson wrote:
>   
>> I keep wishing Bluetooth had passive scanning like 802.11 does.
>>     
> I always thought that was what 'periodic inquiry' was supposed to be, that
> a device would take time every n seconds to do a quick neighbor
> discovery..
>   

Over the last 24 hours or so I've digested a number of interesting 
research papers on the subject...

    What is clear is that inquiry is perhaps the most expensive 
Bluetooth operation possible, in terms of power and baseband behaviour. 
The IrDA paper makes it clear that session initiation may still be 
faster if you can communicate the BD_ADDR of the station using a 
side-band, in this case, IrDA.

    However, this paper makes it clear that the 10.24s inquiry time 
quoted by the Bluetooth spec may be excessive, although their figures 
are based on models, not experimental work:

   Bluetooth Inquiry Time Characterization and Selection
   Peterson/Baldwin/Kharoufeh
   http://netlab.cs.ucla.edu/wiki/files/01661527.pdf

    In this paper they do mention that using the Bluetooth V1.2 
'Interlaced Inquiry Scan' feature can improve discovery times for each 
station by several *seconds*, but of course making sure it's turned on 
depends entirely on your station vendor.

...of course, every time you want to turn stuff like this on, you are 
either relying on the host controller to turn it on for you, or you need 
to send explicit HCI commands to the HC to bring it up (Errg, libhci!)

    It is also a pity that you never get an HCI event from your HC when 
it enters Inquiry Scan state and actually responds to an inquiry -- but 
then again the Inquiry protocol is asymmetric, it's not peer-to-peer, 
it's a bit like ARP without any source/destination field on a purely 
broadcast medium, and you never get to find out anything about who 
inquires or why, so Inquiry presents no opportunities for passive 
endpoint discovery. Yuck.

    I haven't read far enough to determine what kind of admission 
control exists, if any, for preventing pre-V1.2 station(s) from forming 
an adjacency with the station(s) which one is running.
    It seems analogous to the problems caused by admitting 802.11b STAs 
into an 802.11a/g capable ESS. It would be nice if EDR use could be 
forced, although obviously that isn't backwards compatible.

Of course, if any of this stuff were easy, everyone would be doing it by 
now.

> btw something you might run into with multiple radios is that I find
> creating a baseband link does not always work first time, but if the radio
> has seen the other device recently via inquiry, it can connect very
> quickly. I'm not sure if this is the radio recording some information
> about the remote device or that the OS reusing the clock offset is
> helping, but neither will help if you have one radio doing the inquiry and
> the other doing the paging..
>   

    That probably needs further inspection at baseband layer to figure 
out what's going on. It is more than likely that the host controller is 
tracking some info about the peer in some internal cache...

    I find that PalmOS 5 devices always try to inquire first, even if 
you have an entry in the persistent neighbour cache with which you could 
page. Paging is always more efficient than Inquiry, but of course 
requires you know the BD_ADDR. Nokia Series 60 handsets seem to do much 
better and can page with what they already have, in fact, out of most of 
the handsets I've worked with, Nokia's Bluetooth support seems more mature.

cheers
BMS