Introducing Bluetooth Mesh Networking(blog.bluetooth.com)
blog.bluetooth.com
Introducing Bluetooth Mesh Networking
https://blog.bluetooth.com/introducing-bluetooth-mesh-networking
53 comments
or Bluetooth
Some mesh networking technology is proven and trusted, carrying billions of transactions per day. Disclaimer: I work for mesh networking vendor SSNI, and we've been producing and operating large-scale reliable mesh networks for over ten years now.
It is not easy to do well, though, and there are more failed attempts than successes at this point.
It is not easy to do well, though, and there are more failed attempts than successes at this point.
So how will me and my friends take advantage of this?
Will we have to wait for new hardware that supports it?
Or will we be able to update drivers on our Android phones, and then it'll just work?
Will we have to wait for new hardware that supports it?
Or will we be able to update drivers on our Android phones, and then it'll just work?
How about introducing reliable bluetooth instead?
Don't get me wrong, I think this is a great idea, but I have to agree with you. I regularly have problems with devices that pair fine one day and then refuse to pair the next.
Agreed. Thank god Wifi has never been as bad as Bluetooth.
It was. You just don't know/remember.
I remember using Wifi in the late 90s on one of those jelly bean iMacs. It was never Bluetooth bad, in fact it was rather magical at the time.
Bluetooth is like plate spinning. If you can do it, it's impressive.
Bluetooth is like plate spinning. If you can do it, it's impressive.
I still remember using an ASCII table to convert characters of a password to hex-codes in order to get my 3COM USB WiFI adapter to connect.
And in order to get the USB adapter to work I had to install a new operating system (Windows 98SE).
Networking was difficult. I remember having to install TCP/IP and doing magical voodoo with specialised printer cables to get two computers to share files with each other.
Nowadays you just plug stuff in and it works.
And in order to get the USB adapter to work I had to install a new operating system (Windows 98SE).
Networking was difficult. I remember having to install TCP/IP and doing magical voodoo with specialised printer cables to get two computers to share files with each other.
Nowadays you just plug stuff in and it works.
It's interesting that you (and a number of sibling comments) have this feeling. I've always found the pairing process to be a faff, but once that's done it works very consistently.
Random question: Are most people's complaints because of cheap BT devices? Additionally, is it a factor if they are trying to use the BT accessories with multiple devices frequently?
I've often wondered about people's big complaints with Bluetooth in regards to headphones/speakers, because I don't seem to share them, except with our '14 Ford Explorer. That whole system gets wonky.
As I think about it though, my usage is pretty simple: Earbuds for commuting, different buds for the gym, A/V at home. My receiver at home is an upper level brand, my headphones I use every day aren't horrifically expensive, but they're not cheap either. They're only ever used with MY phone, so I don't have to keep re-pairing them. When I'm on my bike and the phone is in my bag, never have issues. On the motorcycle I get the very occasionally stutter when it's in the saddlebag. Like once a month.
I've used really cheap bluetooth audio devices before that had horrific range. I just don't buy them anymore. I even had a set of LG neck band style headphones that were supposed to be a 'better' model than the ones I still use and those were bad from the get go. I returned them on day two, four years in my lower model ones are still working flawlessly.
Now, if I was using my headphones with my laptop and my phone and had to re-pair frequently, I'd be a bit more put off, but OS X and iOS have done it okay for me. I gave up with Bluetooth audio on my Linux laptop though.
Now that I think about it, maybe it's because I've literally given up trying to do anything other than get my devices working and then leaving them alone...
I've often wondered about people's big complaints with Bluetooth in regards to headphones/speakers, because I don't seem to share them, except with our '14 Ford Explorer. That whole system gets wonky.
As I think about it though, my usage is pretty simple: Earbuds for commuting, different buds for the gym, A/V at home. My receiver at home is an upper level brand, my headphones I use every day aren't horrifically expensive, but they're not cheap either. They're only ever used with MY phone, so I don't have to keep re-pairing them. When I'm on my bike and the phone is in my bag, never have issues. On the motorcycle I get the very occasionally stutter when it's in the saddlebag. Like once a month.
I've used really cheap bluetooth audio devices before that had horrific range. I just don't buy them anymore. I even had a set of LG neck band style headphones that were supposed to be a 'better' model than the ones I still use and those were bad from the get go. I returned them on day two, four years in my lower model ones are still working flawlessly.
Now, if I was using my headphones with my laptop and my phone and had to re-pair frequently, I'd be a bit more put off, but OS X and iOS have done it okay for me. I gave up with Bluetooth audio on my Linux laptop though.
Now that I think about it, maybe it's because I've literally given up trying to do anything other than get my devices working and then leaving them alone...
I don't think it correlates much with cost. I interned at one of the major BT companies for 6 months. I did a bunch of testing and characterization of the connection process to troubleshoot issues for our customers. What I found was that small changes to settings that consumers don't even realize exist would cause connection times to vary tremendously.
There are dozens of parameters that control the interaction between two bluetooth devices. Virtually none of them are configurable, and they all have to line up just right on both ends of the connection for things to work efficiently. It's somewhat amazing to me that the protocol works at all.
There are dozens of parameters that control the interaction between two bluetooth devices. Virtually none of them are configurable, and they all have to line up just right on both ends of the connection for things to work efficiently. It's somewhat amazing to me that the protocol works at all.
This is a standard press release. Can someone tell me what this technology actually is/does? Is it a bluetooth profile? A new protocol? At what layer? Is it a new spec/new optional/addition to the spec? Does it require new hardware?
All the details in the spec:
https://www.bluetooth.com/specifications/mesh-specifications
I'm not following this too closely, but here's the summary as I understand it: it's a software evolution based on existing BLE hardware. It's not a new profile, they're above the connectivity layer. Most important "detail" IMHO: it's just the first step of BT mesh. This version 1.0 is based on flooding, so not super efficient. Take all the pictures with a gazillion devices with a big grain of salt ;) But an extension with routing, allowing better scaling, will follow soon. Then it will have the potential to scale better. But this first version is enough to get started, and sufficient for limited scale deployments like consumer applications at home for example.
I'm not following this too closely, but here's the summary as I understand it: it's a software evolution based on existing BLE hardware. It's not a new profile, they're above the connectivity layer. Most important "detail" IMHO: it's just the first step of BT mesh. This version 1.0 is based on flooding, so not super efficient. Take all the pictures with a gazillion devices with a big grain of salt ;) But an extension with routing, allowing better scaling, will follow soon. Then it will have the potential to scale better. But this first version is enough to get started, and sufficient for limited scale deployments like consumer applications at home for example.
This is correct. Several private companies built their own mesh networking protocols on top of Bluetooth, and multiple silicon vendors also offered their own mesh technology built into their stacks. If I recall correctly, one company essentially donated their mesh networking protocol to the BT SIG, and this became the basis for the official BT mesh. Within the SIG, there are multiple efforts to bring mesh networking to the standard, through various workgroups.
I think most of this is a response to 802.15.4 meshes, which have been around for a long time, but are officially getting formalized into specifications or product offerings. Thread, Zigbee, Z-Wave are all gaining momentum, and the BT SIG is trying to not lose marketshare to these products.
Interestingly, Thread is the only mesh network of those I mentioned that supports IP, through 6LoWPAN.
I think most of this is a response to 802.15.4 meshes, which have been around for a long time, but are officially getting formalized into specifications or product offerings. Thread, Zigbee, Z-Wave are all gaining momentum, and the BT SIG is trying to not lose marketshare to these products.
Interestingly, Thread is the only mesh network of those I mentioned that supports IP, through 6LoWPAN.
Interesting. I'm in the middle of running some experiments on top of an ad-hoc network of raspberry pis connected over WiFi. I next wanted to evaluate the Java-based distributed system I've created on top of some kind of other mesh networking technology (e.g. ZigBee, Bluetooth, Thread, Z-wave). I was hoping to simply treat these as layer 2 technologies for which I could buy a corresponding dongle for my Pis and use OLSR on the Pis to control the routing. Do you mean to say they all define their own network and transport layers? Ideally I'd just like to be able to open a TCP socket without having to worry about the underlying mesh network implementation.
Yes, ZigBee, Bluetooth, Thread, and Z-Wave all define their own network and transport layers. ZigBee and Thread are built on top of the 802.15.4 PHY and MAC standard, Bluetooth operates in the 2.4MHz frequency band and operates on the 802.15.1 PHY and MAC (or did at one time), and Z-Wave operates in subGig frequencies and implements its own PHY and MAC layer (plus all other OSI layers). Opening a TCP socket across any of these is essentially impossible because of the miniscule frames all of these support. Thread is the only one that is even capable of supporting IP, but it does so over UDP, using 6LoWPAN (basically IPv6 header compression and packet fragmentation).
Z-Wave, Bluetooth and Zigbee are full-stack, meaning they implement their own application layers as well, so unless you implemented TCP on top of the application layer, you probably won't get what you are looking for. Thread just provides the networking layer, so you could potentially use it to carry whatever traffic you like.
Z-Wave, Bluetooth and Zigbee are full-stack, meaning they implement their own application layers as well, so unless you implemented TCP on top of the application layer, you probably won't get what you are looking for. Thread just provides the networking layer, so you could potentially use it to carry whatever traffic you like.
Great info, thanks. Tallies with what I've read over the last few days. If I understand correctly, Bluetooth provides RFCOMM as a reliable transport protocol. Could I just use this in place of TCP for point to point connections or does it have major limitations? I guess I'd have to change my endpoint addressing given there is no IP obviously.
More details here:
https://www.bluetooth.com/what-is-bluetooth-technology/how-i...
And I still can't use my Bluetooth mouse and headset at same time reliably on the MacBook pro. How can I trust that?
I stopped buying BT keyboards and mouses for this exact same reason. Now if I buy wireless, I go with a a product that comes with it's down dongle and wireless protocol. Like logitech.
Hmmm... I'm able to use my BT headset, Apple trackpad, third-party keyboard, and an old SonyEricsson mc600 all on the same MacBook Air with zero problems, other than the appallingly short battery life in the (now retired) trackpad. This is immediately next to an iMac with Apple BT keyboard and Apple BT mouse, again with zero problems.
Is it possible there's something else in your environment interfering with the BT signal? Perhaps an office with lots of other BT connections?
Is it possible there's something else in your environment interfering with the BT signal? Perhaps an office with lots of other BT connections?
> Is it possible there's something else in your environment interfering with the BT signal? Perhaps an office with lots of other BT connections?
Bluetooth uses the frequency range between 2,402 GHz and 2,480 GHz. This is in the ISM band that is also used by Wi-Fi. Indeed according to the German Wikipedia article on Bluetooth (I could not find such a remark in the article in the English wikipedia)
> https://de.wikipedia.org/w/index.php?title=Bluetooth&oldid=1...
Bluetooth can be disrupted by Wi-Fi, microwave ovens and cordless phones (but not by cordless phones using the DECT standard as is common in Germany).
Bluetooth uses the frequency range between 2,402 GHz and 2,480 GHz. This is in the ISM band that is also used by Wi-Fi. Indeed according to the German Wikipedia article on Bluetooth (I could not find such a remark in the article in the English wikipedia)
> https://de.wikipedia.org/w/index.php?title=Bluetooth&oldid=1...
Bluetooth can be disrupted by Wi-Fi, microwave ovens and cordless phones (but not by cordless phones using the DECT standard as is common in Germany).
I use them all the time, BUT I have noticed that if they are paired to more then one device I will sometimes have an issue if I had to re-pair to a device.
same on the surface book. its utterly ridiculous.
With mesh network being shipped, I hope there is now time to develop an improvement to how bluetooth can be implemented into applications to allow better UX in handling connections/handshakes. It's fine when you only use one device, but when you start using two, man it's not user friendly
I just want my wireless BT headphones to work right across multiple devices, can they fix that too?
I just want my wireless BT speakers to work without a minute-long re-pairing ritual every time I want to use them. Can they squeeze that in there as well?
This is completely device developers' fault. The Bluetooth spec allows for automatic re-pairing. But a lot of devices automatically cycle their device ID on power-up, so you end up with a "different" device.
My Bose headphones can be connected to two devices simultaneously, and paired to more devices (I don't know the limitation for pairing). Same for my 40$ bluetooth speaker.
Do your Bose headphones randomly cut off in an not so crowded office? Then when your laptop can't see them, does it start playing music over the speakers quite embarrassingly?
Not sure why this is downvoted.
This happens to me, but usually with my phone on the train; happened this morning, in fact.
But it's also happened with other brands so it's not limited to Bose.
Which would mean it's a Bluetooth issue.
This happens to me, but usually with my phone on the train; happened this morning, in fact.
But it's also happened with other brands so it's not limited to Bose.
Which would mean it's a Bluetooth issue.
I have been exclusively been using bluetooth headphones for over 6 years in a city. I have never experienced any of those issues. I ride the bus and live in have a high population density neighborhood. I work in a building with over 300 workers and haven't had a single incident like that.
For me, it depends on the app that's playing the sound. Some music/video apps automatically pause when bluetooth drops, while others fall back to the device speaker and keep playing.
Same with my $17 bluetooth ear piece, gonovate G10. These things are down right stealthy.
Apple really got this right with the W1 chip and the new iCloud pairing. BeatsX, AirPods, and Beats Solo 3 just work across all your devices.
Why "introducing?" There are already products on the market that have this. Most of the lightbulbs in my house operate on a Bluetooth mesh network. It's slower than the wifi-connected bulbs, but the range is much greater since each bulb only needs to be able to see the next-nearest bulb. Otherwise I wouldn't be able to reach the lights out on the driveway.
This is a standardized effort from within the Bluetooth SIG. All other Bluetooth mesh networks (and there are many) are implemented in the application layer, rather than at the link layer (BT actually fragments the link layer into many layers). This specification specifically is a managed-flood network (without routing), that uses a suite of generic profiles that any bluetooth 4.2 radio can implement.
They're using a proprietary mesh protocol (either vendor-specific or product-specific). This is a standard, blessed by the SIG and should be supported by many vendors.
I doubt they use Bluetooth Mesh, but more like using BLE - Bluetooth Low Energy.
Bluetooth Mesh is built on BLE. The proprietary meshes that existed before the standard was released also were flood mainly flood meshes on BLE.
I don't know if bluetooth mesh will have the same problem, but zigbee as implemented by Samsung Smartthings leaves a lot to be desired.
For one thing, there is no obvious way to inspect how "the mesh" is configuring itself. I can't observe whether or not repeaters are working as intended nor anything about the quality of the signal strength. The only way to make changes to what gets connected to what is by turning everything off and then turning it back on in a controlled sequence.
I hope that bluetooth mesh vendors will provide tools for troubleshooting and actually inspecting network. Networks can be squirrely things, I don't like taking a shot in the dark with this stuff.
For one thing, there is no obvious way to inspect how "the mesh" is configuring itself. I can't observe whether or not repeaters are working as intended nor anything about the quality of the signal strength. The only way to make changes to what gets connected to what is by turning everything off and then turning it back on in a controlled sequence.
I hope that bluetooth mesh vendors will provide tools for troubleshooting and actually inspecting network. Networks can be squirrely things, I don't like taking a shot in the dark with this stuff.
Many Zigbee setups aren't actually mesh networks.
Zigbee defines only 3 device types:
1) Coordinator - Always on and the root of the network. Only 1 per network.
2) Router - Always on, can forward data from other nodes and send it's own data.
3) End Device - Can sleep, can _not_ forward data from other devices.
In practice with something like SmartThings, the hub is the coordinator and you can assume than any device which has a battery is an End Device since routers are required to always be on. _Some_ wired Zigbee devices (like light switches) will act as routers, but I've found they usually don't advertise if they do or not.
For many people, all their devices are battery powered thus they have no routers so there is no mesh at all, every end device must talk to the controller in this setup.
Zigbee defines only 3 device types:
1) Coordinator - Always on and the root of the network. Only 1 per network.
2) Router - Always on, can forward data from other nodes and send it's own data.
3) End Device - Can sleep, can _not_ forward data from other devices.
In practice with something like SmartThings, the hub is the coordinator and you can assume than any device which has a battery is an End Device since routers are required to always be on. _Some_ wired Zigbee devices (like light switches) will act as routers, but I've found they usually don't advertise if they do or not.
For many people, all their devices are battery powered thus they have no routers so there is no mesh at all, every end device must talk to the controller in this setup.
It'd be interesting to see how this compares to scatternet that has been part of bluetooth since 1.0.
I guess the idea here is that it will be self-configuring.
So if a central node in the network goes down, the rest of the mesh will reconfigure their connections without human involvement.
And thanks for reminding me of the term, i had a feel something like this was already in Bluetooth from the early days.
So if a central node in the network goes down, the rest of the mesh will reconfigure their connections without human involvement.
And thanks for reminding me of the term, i had a feel something like this was already in Bluetooth from the early days.
The difference is in a scatternet, each move between piconets had to create a new connection (1. master1 -> slave, 2. slave -> master2)
The new mesh standard, I believe, is a flood mesh. There is no new connections required because all messages are broadcast on the advertising channels and each node rebroadcasts when it receives it. (with some log of previously rebroadcast messages to avoid infinite loops)
The new mesh standard, I believe, is a flood mesh. There is no new connections required because all messages are broadcast on the advertising channels and each node rebroadcasts when it receives it. (with some log of previously rebroadcast messages to avoid infinite loops)
I found the FAQ to be a good introduction document to the new mesh networking feature.
https://www.bluetooth.com/what-is-bluetooth-technology/how-i...
https://www.bluetooth.com/what-is-bluetooth-technology/how-i...
Thanks for the link. This explains why they would use low power devices with an m:m flood network:
"Bluetooth technology implements a managed flood approach in which only main-powered nodes serve as message relays. Low-power nodes, such as battery-powered sensors, are not responsible for message relay." [...] "Bluetooth mesh handles multicast communications using a publish/subscribe group messaging approach. [...] Bluetooth mesh also supports virtual addresses, which extend group addresses by allowing a 128-bit UUID to act as the destination address."
They also seem to have added strong security guarantees. So in theory, they could control a large number of sensors using a small number of relays, and have fine-grained, secure control over the low-power devices, and avoid complex routing. It's honestly not a bad idea.
Now let's see if they fuck it up like all the other BT implementations.
"Bluetooth technology implements a managed flood approach in which only main-powered nodes serve as message relays. Low-power nodes, such as battery-powered sensors, are not responsible for message relay." [...] "Bluetooth mesh handles multicast communications using a publish/subscribe group messaging approach. [...] Bluetooth mesh also supports virtual addresses, which extend group addresses by allowing a 128-bit UUID to act as the destination address."
They also seem to have added strong security guarantees. So in theory, they could control a large number of sensors using a small number of relays, and have fine-grained, secure control over the low-power devices, and avoid complex routing. It's honestly not a bad idea.
Now let's see if they fuck it up like all the other BT implementations.
>A Proven, Trusted Technology
When talking about mesh networking.