Multiprotocol, or whichever name you want to use where there are two or more radio protocols running in the same end device, has been a requirement from customers as long as there has been IoT or connectivity for that matter. Why is that? Maybe the short and simple answer is that there isn’t one technology to fit all use cases. At one point the most dominant multiprotocol requirement for IoT was combining Wi-Fi and Bluetooth, both having their unique advantages and so combo chips found their way to mobile phones and to some IoT devices, such as gateways. Nowadays, you could say multiprotocol support is a commodity. Cellular technologies have been combined with short-range wireless technologies not only in mobile devices, but also in IoT devices and continue to do so when a long-range wireless backhaul connection is needed.
An alternative reason for people raving about multiprotocol isn’t just about combining benefits of two technologies, but also making sure there that there is a transition from old to new whilst keeping some form of backwards compatibility with existing infrastructure and devices. One example of that is combining Zigbee and Thread, which in many levels are the same (well they are both based on top of 802.15.4) but it is seen that Thread would supersede Zigbee in the long run.
In the IoT you have multiprotocol solutions combining Bluetooth LE and Zigbee, Bluetooth LE and SubGHz protocols, like Sigfox, Wireless-Mbus, and Bluetooth combined with proprietary protocols like in garage door remote controls. The list is endless.
It seems that there is often a desire to combine Bluetooth with another protocol. There are two clear reasons for that, first, Bluetooth LE won the battle of point-to-point connections with its battery powered option and, second, its 100% adoption to mobile phones. Bluetooth is nowadays de facto whenever you want to connect a peripheral to your phone, like fitness trackers or other accessories, or want to control something locally, like lights – the mobile device can work as a universal controller.
The second observation is that Bluetooth LE/5 doesn’t fit everywhere, as it has its limitations, with range, limited topologies, the point-to-point nature of communication and an inability to connect lots of devices to the same network. So, it could be thought that Bluetooth compliments the other technologies with its advantages and the combination creates a stronger product.
How does this affect Wirepas, whose focus is on creating the best mesh technology for massive IoT? Wirepas and Silicon Labs collaborated on a multiprotocol solution, which combines Wirepas Mesh and Bluetooth connectivity to run concurrently with using just one radio. [press release]
One finds asking what benefits this solution brings. Isn’t Wirepas Mesh enough to cover connectivity needs? Wirepas Mesh is the choice for mesh networks when you wish to connect large amounts of nodes together in smart buildings, smart cities, industrial applications, street lighting to name a few. But, where does Bluetooth fit into all of this?
Bluetooth brings the personalized and local control, interoperability with mobile devices to massive scale mesh deployments. Be it locally controlling office lights with your phone, or the facility manager deploying new devices to the network, still maintaining all the benefits and performance of Wirepas Mesh network – like unlimited scale, adaptivity to environment enabled by unique de-centralized operation.
With Silicon Labs we were able to achieve true concurrency between Bluetooth and Wirepas Mesh at 2.4GHz ISM-band. With true concurrency we mean operation where the radio does not need to switch or time-slice between protocols when receiving packets, which keeps the user experience of Bluetooth intact and ensures the Wirepas Mesh performs to its promise.
We are currently working with lead customers offering early access to multiprotocol solution and expect the general availability of the solution for 2.4GHz frequency band later this year. In a follow-up blog we will focus on what problems the solution solves, discuss various use cases and what savings it can bring compared to multi-radio designs, and later we will also dive to more technical aspects of the solution’s performance and how the concurrency was achieved.