Mesh networks provide an ideal technology to implement and enhance a number of applications, such as building and home automation, lighting systems, and retail beacon systems. Mesh networks allow systems to reduce power consumption to increase battery life, extend communication range, and improve overall system reliability.
In a point-to-point or star network, the signal range is a function of output power. To ensure devices can run on a battery for a sufficient period or to increase energy efficiency, the ideal scenarios is to reduce power consumption and output power. However, despite reduced power consumption, devices still need to be able to communicate and interact with other devices. Each device in a mesh network transmits a shorter distance to reduce its power consumption. As communication is relayed across devices on the mesh network, the total communication range of a system can be improved.
Mesh networks offer additional communications benefits, as well, such as their ability to perform dynamic self-healing. For example, if one node in a mesh network fails, communication can be re-routed to improve reliability. Another important benefit of mesh networks is devices can communicate directly with each other. In many contexts, such as a light-bulb responding to a switch, this provides the responsiveness consumers expect.
Impact of Mesh Networks on Applications
The overall system performance and end-user experience can gain remarkable improvements using mesh networks. With building and home automation, devices can communicate directly with each other. An action on a light switch can be immediately sent to lights over the local mesh network without routing communication via a gateway to the cloud.
This type of immediate response improves consumer experience. In addition, for some use cases, such as an HVAC system turning off air in the case of a fire alarm, local communication over a mesh network ensures correct system operation without a dependency on cloud connectivity.
For lighting systems, deployment and management can be simplified. The extended connectivity range provided by a mesh network means connected lights can be deployed at a greater distance from a hub vs a star network. A hub or gateway can be placed in one location and connected lights deployed. As each light is deployed, the range of communication grows, allowing a single gateway to effectively cover a larger area.
Beacons used for retail marketing or asset tracking can be more easily managed by not requiring each beacon to be within the range of a phone. It is also possible to combine functionality across these areas and types of devices. For example, connected lights cannot only be automated, but can also act as beacons. This approach can increase the functionality and value of a light by adding capabilities, such as location services and advertisements.
A Case for Multiple Wireless Protocols
Already deployed systems that a product must interoperate with are an important factor to consider. Consider a residential home as an example, where a number of devices are likely using Zigbee or Thread to form a mesh network. A gateway or a combination of a hub and gateway is most likely already connecting these devices to the cloud for additional services. The phone is likely also communicating to the cloud, and then back to devices.
In order to support direct phone to device communication, or to support an ecosystem, such as Apple HomeKit, Bluetooth connectivity is required. Bluetooth can be combined with another mesh network or used on its own as a mesh network if all the devices support the protocol. Adding support for multiple protocols in a device may also provide benefits, such as using a phone to setup or commission a device without a display onto a Zigbee or Thread network.
With Silicon Labs multi protocol software and hardware, a single product supporting multiple wireless connectivity protocols can be designed. This can be the same device capable of connectivity to multiple protocols in the field, or a device with the ability to be configured in the field or factory to one of a number of different wireless protocols. By using the same SoC supporting multiple protocols, or pin compatible SoCs for specific protocols, company users have the flexibility to adjust their market strategy. With a secure update mechanism, such devices can be updated in the field to add additional functionality or to react to any changes in the market, such as a surge in popularity of a specific ecosystem requiring a specific mesh technology.
Determining the Appropriate Mesh Technology
For most existing home automation and lighting systems, existing ecosystems and deployments must be taken into account. For example, to be Apple HomeKit compliant, devices must support a Bluetooth connection for communication to support Apple HomeKit, even if the device is connected over a mesh network to other devices.
Many existing devices use Zigbee, and for any new devices based on a technology such as Bluetooth mesh, an interoperability strategy either through the end device or gateway supporting multiple protocols must be considered. Similarly, different service providers have requirements for specific protocol or multiple protocol support that must be considered when selecting the appropriate connectivity solution.
Connectivity requirements should consider the entire ecosystem, from the end device, to any gateways or hubs, to application layers and service providers. Networking technologies, such as Zigbee and Bluetooth mesh, that do not natively support IP must first be adapted to IP at a gateway. This process involves the mapping of the local network addresses and repackaging of the network-level payload into an IP datagram. In contrast, local networks natively supporting IP, such as Thread, can forward and route application payloads without intervention. Packets encrypted in the local network can remain secured end to end.
Comparing Mesh Networking Standards
Each mesh networking standard provides standards-based support for different devices types and applications. Zigbee has a mature application layer support for home automation, lighting, and metering, while the first Bluetooth mesh specification primarily focuses on lighting with some home automation support. Thread is the only mesh technology out of the three based on IPv6. This provides some unique benefits, such as end-to-end routing and addressability on the same or across networks, without the need for additional translation layers to be implemented.
The majority of connected devices benefit from connecting to the cloud for use cases such as data aggregation. Bluetooth mesh devices also supporting Bluetooth Low Energy can provide connectivity to the cloud via a smart phone or tablet. This, of course, is a temporary connection, as the devices would not be able to connect to the cloud to send or receive information if the phone or tablet isn’t present, requiring a gateway for an always connected experience. Zigbee requires a gateway for cloud connectivity while Thread, with its IP based connectivity, doesn’t require a full gateway to bridge between the mesh network. With Thread, border routers are able to facilitate direct device-to-cloud communication over IP in a lighter weight manner.
The theoretical network size based on the addressing scheme used does not accurately reflect the number of nodes a network requires in real world implementation. The practical limits are based on a number of factors, including the network topology, data packet size, and performance requirements, such as throughput and latency. A Zigbee subnet of devices, for example, has a practical limit in the 100’s of devices, though it is possible to deploy extremely large commercial systems, such as the one in the Aria Hotel in Las Vegas with more than 80,000 networked Zigbee devices with multiple sub-nets. The Thread 1.1 protocol was optimized for performance around 250 nodes per network, however as Thread is IP based, border routers enable the networks to be easily extended and distributed.
With the managed flooding model in Bluetooth mesh, devices are able to broadcast to many devices without managing routing tables, which is simple and can be beneficial for dynamic use cases where mesh nodes are mobile or change frequently. However, for large networks, managed relaying requires network planning during installation as not every node can be configured as a relay, as that kills the network performance. Technologies such as Zigbee and Thread have a routing and automatic routing table management to provide more efficient network communication and to automatically form the network and node roles.
The full capability of a protocol also depends on the corresponding application layer. While the Thread protocol does not include an App layer, any IP-based application layers, such as dotdot or OCF can be used. Bluetooth mesh includes a native application layer called the Mesh model, which is a brand new application layer where support for different devices types is more limited than that for Zigbee or Thread. Bluetooth mesh has good support for lighting models and support for generic controls, like On/Off, sensors, sliders, power and battery statuses, but lacks dedicated models for many home accessories such as door locks, HVAC, or Window covering specific functionality defined for interoperability.
In addition to supporting multiple mesh protocols, a mesh protocol such as Zigbee can be combined with Bluetooth low energy to simplify device setup via Bluetooth commissioning, using smart phones for Zigbee devices or to provide the Bluetooth connectivity needed to support Apple Homekit.
Combined with Bluetooth Low Energy, Bluetooth mesh does provide unique ways to incorporate beaconing into mesh systems and dedicated beacon management models are already being built by the Bluetooth SIG.
It is of course possible to extend and build custom implementations to support specific device types, but it’s important to be aware of the effort involved to do so and future implications for device interoperability before selecting a protocol and application layer.
Summary
Each mesh protocol offers technical strengths, as well as maturity in the marketplace and established deployments to consider. It is possible that one protocol may not be able to meet the needs for all products or markets.
Many factors must be considered for wireless protocols, as well, especially already deployed systems, which require an interoperability strategy either through the end device or gateway supporting multiple protocols. In general, connectivity requirements should always consider the entire ecosystem, from the end device, to any gateways or hubs, to application layers and service providers.
A number of options exist today to address current market needs while also help plan for the future.
If multi protocol software and hardware is used during the design process, a single product supporting multiple wireless connectivity and protocols can be designed, giving end-users the freedom to adjust and update device connections and use cases in the field based on real-time business demands.
