Comment by jessriedel | Hacker News Reader

Comment by jessriedel | Hacker News Reader

Parent Full thread

> Its main purpose seems to be reducing the time it takes to establish a connection between two Apple devices from roughly 1 second down to about 0.5 seconds.

> With this trick, they can establish that both devices are speaking the Fast Connect protocol without violating the Bluetooth specification, and then go on to exchange 3 more back-and-forth messages, negotiating all the things necessary to fully connect the two devices.

> The fact that this only takes 4 messages back-and-forth in total is what makes Fast Connect fancy, because usually in Bluetooth the phase of wiring up the individual channels for a connection is quite a complex negotiation and involves sending various SDP descriptors that describe which protocols/features both sides support.

Two devices in the same room communicating over even a very narrow slice of the electromagnetic spectrum could exchange many thousands of messages per second. What is it about Bluetooth that causes each message to take a hundred milliseconds rather than, say, a microsecond? What is setting the timescale for this process?

Not sure if that’s the case here but typically it’s a combination of:

* How frequently the advertising device is sending out a beacon (for WiFi the typical beacon is every 100ms which should be similar for BT but it’s been a while since I worked on either)

* there may be multiple advertising channels (I think BT smartly picked 1 or a very small number but annoyingly WiFi didn’t restrict the channel the beacon could be sent on which is a disaster for 5ghz since there’s so many - not sure if they fixed it in 6ghz)

* for back compat, the beacon is sent at the slowest speed of the protocol as is the handshake. So for example your 600mbps WiFi channel actually beacons and does the handshake at 10mbps (or whatever the negotiation speed is specified to be) because you need to start at the minimum speed to negotiate the higher speed while retaining back compat. Similar thing happens with USB3.0 which does a USB1 initial handshake.

* noise in the environment can cause PHY retransmissions to be needed.

So basically PHY handshaking to determine what capability exists on both sides to know which PHY protocol to talk to each other.

All of this above. The biggest contributing factor though is that the radio will be off for 99% or more of the time when not actively sending, in order to save energy. This means you also need to wait for that <1% beacon/listening window to connect. And it’s not unlikely that you get interference / a bad transmission just at that time, so double or triple the wait time.

Or in short: It’s caused by saving energy and interference.

This makes sense for idle devices, but say airpods know they have been opened (or other bluetooth headset can be actively listening for a few seconds after power up), and on the other device you explicitely click connect on already discovered divice. I also don't understand why these connections are not 1ms even for devices which were not paired previously.

You don’t press connect on the other device. You just put the AirPods in your ears and damm, good to go at once.

You can have a device listening only 1% of the time while only waiting a millisecond. Just listen for 10 microseconds and energy-save for 1 millisecond. Why aren’t they doing that?

Probably back to the lowest common denominator of speed.

128 bytes at Bluetooth 1’s 1mbit speed is 1ms.

I don’t mind using more energy. Are there any other implications for spamming a beacon?

You interfere with other devices, especially any others that have the same idea.

> So for example your 600mbps WiFi channel actually beacons and does the handshake at 10mbps (or whatever the negotiation speed is specified to be)

802.11 beacons are sent at the lowest basic rate configured for the network, which in the old days was 1 Mbit/sec, but it's entirely possible to simply not advertise that in the beacon (it's commonly done in larger networks, as you don't want clients to be eating airtime by sending such slow packets), and then the beacon goes out at whatever higher rate. The association can be done at any rate the client wants to, as far as I know, as long as it is listed in the beacon.

Yes, you can drop older clients in which case the advertising rate is higher (not sure how clients can handle becomes at arbitrary speeds but it does seem to work). However BT does not provide for this kind of control.

> How frequently the advertising device is sending out a beacon

Fine, but then the immediate question is: why is it sending out a beacon so rarely?

> for back compat, the beacon is sent at the slowest speed of the protocol as is the handshak

Fine, but then why was the protocol ever so slow? Electromagnetism hasn’t changed much.

> there may be multiple advertising channels

Fine, but why are they all so slow?

BLE is 3 advertising channels. IIRC they are dedicated to advertising. There are something like 40 other channels used for data (and it uses all of them via frequency hopping).

Correct. BLE is sane, 5ghz WiFi is insane with > 100 data channels and all of them can beacon. I really don’t understand why the WiFi alliance doesn’t learn from BT here. Maybe there are technical reasons like WiFi is always becoming so they need more channels to spread over in an urban environment? Still seems a bit silly.

This is fascinating to me. I used Cisco wireless for several years and read the documentation enough to know about why 802.11k sped up roaming so much, but never put together that requiring a scan across the entire spectrum is an inherent design flaw.

The complete lack of network-driven roaming, which AFAIK is still missing from wifi 6/E, must be frustrating to large-scale network designers and admins.

Also frustrating when we were doing indoor WiFi positioning at Apple. Scanning 2.4ghz - super fast. Scanning 5ghz takes forever. You need repeated scans as quickly as possible to converge your position (at least the way we were doing it at that time)

Reply on news.ycombinator.com