The battle for Smart Home networking

With the advancement of Internet of Things (IoT) technologies, the smart home domain has significantly evolved over the last couple of years. Despite a report which sees a fall into consumer demand for connected home products during the last year, there are significant signs showing that the smart home is an IoT space which is surely going to be exciting in the next future. And this is the reason why there is a huge activity going on in the standardization of communication technologies and low power networking for the smart home.

Last week, the Thread group announced the release of the first protocol specifications. Thread is a protocol for low power networking in the smart home announced last year by Nest, Samsung, Freescale, Silicon Labs and other companies. It is an IPv6-centric protocol stack which relies on the IEEE 802.15.4 radio link layer and on 6LoWPAN, the IETF standard which enables the transmission of IPv6 packets in networks of resource constrained devices. The release of the first protocol specifications is important news for the smart home market as it means that the development of products based on Thread will shortly be available, probably around the end of 2015. In fact, the group announced a certification program which would start in September. The group also announced that Qualcomm has joined the Board of Directors. This says it all on the fact that the group has serious intentions in transforming Thread into the major low power networking protocol for the smart home.

But Thread is not the only one to have such intentions and will surely have to share the smart home marketplace with a widely adopted standard: Bluetooth Low Energy (BLE). Bluetooth has always been considered as a point-to-point protocol to enable the communication with a low power device (such as a wearable gadget) and a more powerful device such as a smartphone or a laptop. However, last December the Bluetooth Special Interest Group (SIG) officially adopted version 4.2 of the Bluetooth core specification. The new specification includes the Internet Protocol Support Profile (IPSP) which allows Bluetooth Smart sensors to access the Internet directly via 6LoWPAN. Two months later, the Bluetooth SIG announced the formation of the Bluetooth Smart Mesh Working Group, responsible to build the architecture for standardized mesh networking capability for Bluetooth Smart technology. The adoption of mesh technology in the 4.2 specifications is a clear sign that the Bluetooth SIG intends to penetrate the smart home market segment. The Bluetooth SIG  expects to have the specification ready for prototype testing later this year, and the adoption for the new profiles will start in 2016.

The horizon seems to be rather clear: Thread and Bluetooth are going to be the two major low power protocols competing in the smart home market. I have excluded from the battle two other low power networking protocols: ZigBee and Z-Wave. Although they are quite known and deployed, they have many chances to disappear from the smart home market or to remain with only a tiny fraction of it, for the following reasons:

If Thread and BLE both take off and will meet the expectations, the battle to penetrate the smart home market will be an interesting one and it will be hard for product and solution developers to choose between the two. At ModoSmart, a company which I recently co-founded, we are developing a smart home solution and we have decided to use BLE for the development of the prototype. For the first version of the product we don’t need mesh functionalities, therefore we can cope with the current version of BLE. We will need mesh for the second version of the solution next year and hopefully by then BLE mesh will already be up and running.

We didn’t choose BLE for strictly technical reasons. It’s rather early to evaluate and compare the two technologies, until they are not both available and deployed into devices. Although they have different technical foundations, they both provide low power mesh functionalities based on IPv6 technology. It’s true though that Bluetooth doesn’t have experience on mesh networking, while the Thread group builds on the long experience in low power networking acquired by several of its members with ZigBee over the years. Therefore, if I had to bet on the low power networking performance of the two standards I would slightly prefer Thread. But in my opinion there are other issues, less technical but definitely not less important, that make me think that Bluetooth is in a favorable position compared to Thread. The two major reasons are the following:

  • Integration with smartphones and wearables. BLE is nearly in every smartphone and in every wearable device (wristband, smartwatch, shoes, etc.). If our smart home devices communicate via BLE, we can interact with them in a more seamless and autonomous way. Consider for example the case in which you want to control your air conditioning based on your body temperature measured with a wearable device. If the air conditioner speaks BLE it can communicate directly with the wearable device, while if it uses Thread the communication will have to go via a gateway or an API, which makes the integration more cumbersome and less seamless. BLE also enables devices to use beacons, a technology which can enrich smart home solutions with proximity and indoor location
  • Interoperability and standardization. Thread is a networking stack and is application layer agonistic. It is potentially able to work with several application protocols and platforms out there. This is not straightforward and requires collaborations among the standardization groups and alliances behind those application frameworks. The first one which has been formally established is the collaboration between the Thread group and the ZigBee Alliance for allowing the ZigBee Cluster Library (ZCL) to run on top of the Thread stack. We will surely see in the next future collaborations between the Thread group and other alliances promoting smart home application frameworks, such as the AllSeen Alliance and the Open Interconnect Consortium. The problem is that all these application technologies intend to brand devices with their own logos and following their own certification programs. It is not clear whether a smart home device will be branded with the Thread logo, the logo of the application framework (e.g. the AllSeen logo) or both.  And also, there are many chances that two smart home devices built with the same thread stack but with two different application layers on top are not going to interoperate.  These problems can create confusion in the smart home interoperability and may prevent the widespread adoption of the technology. Bluetooth, instead, has strong interoperability foundations and this will surely be an added value for the end user.

In conclusion, I see BLE in a better position than Thread in the penetration of the smart home domain. However, Thread as already released its first protocol specifications and there will soon be products available on the market. The Bluetooth SIG will have to follow fast and will also have to convince the smart home product developers that BLE remains an efficient technology even with the addition of IPv6 based mesh networking functionalities. At the same time, the Thread group will have to make sure not to mess up with IoT interoperability as Zigbee did. If they both do so, chances are very high that the smart home low power networking space will be strongly characterized by the Thread-Bluetooth dichotomy.


  1. says

    I do not agree with your last conclusion that BLE is in a better position regarding interop on the application layer. Although there is GATT, this won’t be used by every BLE device. Have you e.g. seen any BLE sign on Elgato Eve? No, you will only find “HomeKit” on it and it does not work with Android, although it uses BLE. To truly compare BLE with Thread, you would also have to consider IPSP, which I am sure will cause some more headaches.
    So my guess is that we will also have a mess on the application level for BLE – it’s take a long long while before anything is sorted out there…

    • Walter Colitti says

      Hi Kai,

      Thanks a lot for your comment.

      My discussion and comparison on interoperability was not really related to strictly technical issues. This cannot be evaluated yet. My fear is that Thread will have to sign agreements with different application layers and the situation can become messy. AllJoin over Thread won’t talk to ZCL over Thread, for example.

      Bluetooth is in a different position because it includes app layer and profiles and Bluetooth has done it well in the past in terms of interoperability. But I agree with you that mesh networking is not straightforward. Allowing two devices to talk to each other is more complicated than connecting a headset to a smartphone. So as you say it depends a lot on IPSP and on how it will be defined.

      HomeKit is a different story though. Bluetooth doesn’t have to make any formal agreement with HomeKit so it will remain “independent” from other application layers. It’s Apple who has decided to work with Bluetooth and WiFi as underlining technologies. As far as I understand, the fact that Elgato Eve supports HomeKit doesn’t mean that it only works with HomeKit. It is equipped with the hardware/software needed to work with HomeKit but it remains a BLE device so it should work with Android too. It won’t work with the Weave/Brillo platform, but that’s a different thing.

    • Walter Colitti says

      Hi, thanks for your comment. Mine is not really a critique to ZigBee products, it’s my personal view on the evolution of the protocol and on its future. The ZigBee stack has undergone significant changes over the last years due to the interoperability problems. My personal opinion is that the ZigBee stack will not have reason to still exist when Thread takes off. This is also demonstrated by the agreement between ZigBee and Thread to allow ZCL to work on top of Thread. Why would you still be using the ZigBee stack when you have Thread? Thread is based on the same radio and networking standards as the ones in the ZigBee-IP stack, with some improvements as well (for example on the routing protocol). And also, Thread works with the ZigBee application layer too. I don’t see the advantages of using ZigBee-IP instead of Thread.

  2. Riyaz Muhammad says

    I tend to agree with you – Wi-Fi succeeded because it replaced Ethernet which had mature application layer protocols as well as Use cases available. BT started as a cable replacement and grew because SIG defined the profiles specific to applications. Same is the story with ZigBee PRO – it is the definition of Clusters that helped it growth. The theory that “enable IP” will solve all problems is not correct. ZigBee IP (6LoWPAN by ZigBee Alliance) failed to take off since they did not get a good use case. WiFi use cases cannot run on 6LoWPAN. Now with Thread, Google has their application – Weave – but that is limited to Google ecosystem. Thats not enough for an open growth. When I checked last, there was a lot of interest in the Thread group to have Iotivity over Thread. But it was mostly academic. ZigBee clusters over Thread is a potential success story – but the work involved in making that happen is a lot and I don’t see any active work on that front started yet. If you are building a smart home network, the best option is BLE at least for now. Until Thread comes up with a viable application layer standard and some data models.

    • Walter Colitti says

      Totally agree. But BLE needs to be fast on standardizing the smart mesh, and at the moment there are no clear indications on the timeline. Without mesh functionality BLE can’t compete with ZigBee and Thread.

Leave a Reply to Riyaz Muhammad Cancel reply

Your email address will not be published. Required fields are marked *