Bluetooth Smart (formerly Wibri and then BLE) is being positioned as the likely backbone of IoT device communications. But, it has some serious limitations that call that concept into question:
1. It is a star bus type: one central node (today a smartphone or tablet most typically) to nearby devices. Hardly the always connected model of IoT.
2. Distance is about 150 feet of clear air, much less through walls and even with obstacles in the room.
3. Does not support mesh, so devices must directly connect to a "hub" in the star as noted above. Wifi->Bluetooth hubs add cost and then have to be well positioned to work.
4. No IoT type addressing method. Currently relies on pairing and fixed ID (e.g. "Brand_X_Heartrate_monitor") because they assume only one. A URI/URL could be constructed, but no mechanism exists for it now.
5. Bluetooth does not have any method for timed reconnect or other very very low power way to not be active all the time for end nodes. Keeping the RX on all of the time does not work well for a device left for months/years on one battery. Note that the mouse/keyboard approach of BLE works because they generate the connection on user action; that is, they do not have to listen for "commands" when inactive.
That said, what it shows is that Zigbee continues to be very unpopular (for good reason I think) and Wifi is too high power and too costly for many IoT type devices. 6LoPAN is technically solid, but the infrastructure to support it is not there, especially as the move to IPv6 is happening more in the cloud than in the LAN.
Thoughts?
Hi Zin. Yes, I agree that 6LoWPAN uses IPv6 mechanisms for mesh (NAT as ND, ICMP, ARP scheme, etc) as I said - my point is that IPv6 has that natively; 6LoWPAN is differentiated from IPv6 by being (a) a subset (to save code requirements which is important), and (b) a compressed header to save bandwidth. What I meant is that you still need a gateway/bridge from 6LoWPAN to IPv4 or IPv6 networks, even if that is lightweight; you still need it. This is made more complex when you also have to de-protocol two levels: Bluetooth (using one of the classes) and then 6LoWPAN. Nothing wrong with this but it would really help if Bluetooth SMART added 6LoWPAN as a profile type. But, things like NAT and ND would not be "natural" over Bluetooth since you have to go slave->master->slave for each: there is no direct discovery. But, that fits how many handle IPv6 anyway: an aggregator (aka access point and local router) does the local routing, so this would be workable if there is a "solution" to where this bluetooth gateway lives.
You say it can be cheap, but consumers and building and commercial are resistant to having to sprinkle boxes around for no apparent reason. Having to carefully place one or more APs around a house/building with power supplied and all is enough to stop this in its tracks. This was the big promise of 15.4 - every device can be a transceiver and so as long as you have enough of them in natural places, the network just works. That is not how Bluetooth (SMART or otherwise) works. You would need some of these devices to bridge up to Wifi or other longer haul form and that is not cheap. Wifi routers/APs are no longer a good fit since Wifi distance is getting longer (with ac and MIMO) and so you would not salt enough of them around to cover all of the Bluetooth distances. So some kind of transceiver gateway/bridge is needed. I doubt that Bluetooth master/slave diversity will catch on, so this does mean either two radios or a wired back haul (e.g. PLC or Ethernet).
Regards, Paul