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 liked the idea of a mesh network very much.I see it saving power in transmission power as hops are smaller.
Also it makes the network more robust if your full network doesn't rely on the gateway in the middle. That last point would link to Security and deeply embedded: if you only need to take one node down, the hackers will focus on that one.
Worse than taking one node down is using one as a source for attacks. If you have a network of devices and one is vulnerable to attack, it can be used for many nefarious purposes from snooping to spoofing to running DoS attacks on the local network.
H Paul, Thanks for the blog and your thoughts on BLE.
Have you heard about Weightless ? What is your take on this new specification that, in some regions, can make use of the TV white space freed up by the move from analogue to digital TV. I say 'in some regions' because I think that this is not applicable in the US - not yet anyway.
I have heard of it along with Cognitive and af and so on. The issue is that people are not looking for yet more different incompatible radio/protocol standards, but one. When every person sees all of these incompatible choices, it takes them back to Betamax vs. VHS, and all of the other incompatibility wars that leaves many losers. If you spend hundreds to thousands of dollars/pounds/euros on equipment using radio form X and the world suddenly tacks to radio form Y, you have worthless junk and you will be quite upset.
This is what has prevented adoption of anything broadly. The power companies seem to have settled on Zigbee Pro for the HAN, but they seem to be the only ones and interest in Zigbee is decaying. People making home-area-network endpoint devices are more likely using bluetooth or Wifi because it would work with smartphones and tablets - working with a Smart Meter is worthless right now especially as there is no controller readily available so it would be speculative at best. There are many other of these open/proprietary initiatives that have been around like ANT, ZWave, 6LoWPAN, various PLC, and of course other purely proprietary in all of the open bands (sub GHz and 2.x GHz and so on). The problem is that to use any of them for home control, building control, general IoT (a superset of those), or personal wireless network (WPAN), you need a control interface of some kind, and those are expensive unless they happen to be in your hands anyway (ie. your phone or tablet or computer). So, a gateway/bridge is needed - that is where this tends to fall apart. My guess is that eventually Wifi router vendors will incorporate bridges to one or more "winners" in this arena because people are generally loathe to install a dedicated bridge, especially if they are building up the network of such devices in a slow piecemeal fashion (where spending lots for the bridge to use the cheap endpoint does not fly). That is not to say that model is impossible. Many mouse/keyboard vendors included such USB bridge devices (often bluetooth) for computers and people did not flinch (too much anyway). But, these were also cheap enough, the location was not an issue (plug into computer or hub), and the single bridging function was well defined or proprietary. For this new model to work, it has to be an open bridge that will work across a wide range of products from various vendors. That likely means you end up with more than one incompatible bridges vs. one unifying one. It also means that "mesh" falls apart unless you buy from one vendor.
Part of the problem is that none of these radios are very cheap, so no one wants to add these things to their consumer electronics unless the customer values it at least as much as it is costs. Remember that it is not just the BOM cost but also getting certification in each country for radios (intentional radiators). Making these things modular is not really an option because there is no backing standard (e.g. USB) to base the modular connection on. That is the real problem here.
So, you have customers on the fence waiting for the dust to settle. You have CE vendors on the fence. You have the bold with nothing to show except extra cost. You have the advocates (e.g. weightless) talking it up over and over. We are at the same stalemate we have been since 2000 when dust/motes/etc was the next big thing except now we have even more contenders and not less! So, I think we may get the VHS type solution of Bluetooth (BLE) which is unsuitable/poor for many uses but easier to fall into because anchored by phones and tablets.
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