Date: Fri, 10 Apr 2009 19:14:36 +0100 From: Bruce M Simpson <bms@incunabulum.net> To: Iain Hibbert <plunky@rya-online.net> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>, "alexei@raylab.com" <alexei@raylab.com> Subject: Re: Speeding up device discovery: paper Message-ID: <49DF8C8C.5030006@incunabulum.net> In-Reply-To: <1239359436.893706.893.nullmailer@galant.ukfsn.org> References: <49D92E26.2030508@incunabulum.net> <bb4a86c70904061358l3983ed51m11265859a833f202@mail.gmail.com> <49DD40E2.5030403@incunabulum.net> <1239264003.862926.638.nullmailer@galant.ukfsn.org> <bb4a86c70904091013l2d7c2b77ic7f6988e6e7709f2@mail.gmail.com> <49DE4F44.8070707@incunabulum.net> <1239359436.893706.893.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49DF8C8C.5030006>