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?
I think that Bluetooth SMART has its target application areas just like 802.15.4, Wi-Fi, etc., but these 3 technology standards stand out in my mind when it comes to IoT. I don't know if there would ever be "the one technology that rules them all" as they all address different requirements in the realm of what we call IoT. For example, Bluetooth SMART has traditionally targeted health/fitness applications, 15.4 industrial, and Wi-Fi the connected home space. What the IoT industry needs is a Software Defined Radio (SDR) that could support all three so then it doesn't matter!
Note that 6LoWPAN is a wireless protocol standard and is agnostic to the link layer. It could actually run over 802.15.4 (and its variants) or Bluetooth SMART, and even across power-line technologies like PRIME and G3. This is the beauty of 6LoWPAN is that it gives you a convergence point where the physical layer in use does not matter. One could even run 6LoWPAN over Weightless.
But regardless of the technology used to "transport the bits", if these IoT systems don't talk the same application protocol language, existing IT infrastructure won't be able to seamlessly take advantage of these "billions of sensors" in the IoT. We must be able to access the information presented by IoT devices as simply just standard Web services. The Internet of Things is merely an extension of the current Web. CoAP (Constrained Application Protocol) (see CoAP Tutorial) will help the industry coalesce around embedded Web services for connecting devices to services. CoAP is garnering tremendous industry support (e.g. OMA (Open Mobile Alliance) has adopted this as part of their application framework for the new Lightweight M2M standard), and what you are witnessing is paradigm shift towards leveraging standard RESTful Web services and data objects for IoT / M2M applications.
Interesting thought on 6LoWPAN being one protocol to rule them all. But, that would take bridges in the layer above to translate and handle - that is, your BLE aggregator (whatever form it takes) would need to process this meta protocol over the normal BLE data traffic. This could be a valid concept, but I have my doubts. 6LoWPAN evolved to replace Zigbee by allowing use of NAT and the like to handle "mesh" and other hot repair needs as well as auto addressing. The 6LoWPAN part is just replacing the massively long IPv6 header with a short one for low bandwidth radio types like 15.4. But, IPv6 is heavier weight for the middle level devices and that has limited it; in industrial they want aggregator/bridges to run into Industrial Ethernet/IP and so it makes sense and is cheap. But, less clear in a HAN where consumers do not want to pay for more expensive gear. If the Wifi routers/APs include it, then it would not matter but few of them even support IPv6 yet and many that do, do it badly. Part of that is also that the ISPs are not really supporting IPv6 through their modems, only in the cloud - they want to translate between IPv4 and IPv6.
I agree that radio diversity would be nice, but the costs are far more than just the PA/LNRA and antenna but extend to the PHYs and MAC layers. Wifi is a very heavyweight protocol these days (and getting worse) whereas BLE is designed to be lightweight. 15.4 can be even lighter but the lack of a standard protocol (6LoWPAN is but one option) and issues with frequency has made this all painful.
The problem with BLE (Bluetooth SMART) is that it is a master-slave spoke technology with fairly short range. Works well for health and medical as you say because it allows for a BAN (Body area network) to your phone or tablet. That is not a good model for an always-available (not always on, just available) network that has to be connected/bridged into the wider network. Yes, you can have APs, but the locality and how they connect adds cost and maintenance issues.
The biggest driver for Bluetooth SMART is simply that it works with your SmartPhone, but that is not all that IoT is supposed to be about. This gets to the problem that consumers will buy what they understand but not necessarily what is good for them long term (thinking to their future needs). Buildings tend to want to build a single system and do not necessarily think about populating new things later - if anything, that scares them.
Paul, I think you have some fair points. Going back to your original posting, I think once you can run 6LoWPAN over Bluetooth SMART, a lot of your original concerns could be addressed. A few data points around 6LoWPAN:
1) 6LoWPAN is more than just IPv6 "header compression". The 6LoWPAN OSI model also includes 6LoWPAN-ND (Neighbor Discovery), RPL, TCP/UDP/ICMPv6, etc. which then provides the full stack-up necessary to support a mesh network
2) 6LoWPAN Access Points (APs) or edge routers CAN be cheap. We have implementations that can run on Cortex-M3 / M4 class processors
3) From our experience, most OEMs utilizing 6LoWPAN can choose to deploy IPv6 as their backend systems would normally reside in a private data center, but you're right that there are some nuances and considerations around IPv4 vs. IPv6 support around existing network infrastructure.
zachshelby might have some additional ideas to add around this thread.
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