Hornet is a wireless mesh network protocol based on 802.11.4.
Why NOT Zigbee?
Don’t get me wrong, I have a lot of respect for Zigbee protocol. The good parts of the Zigbee protocol are really good. However, apart from the “good parts”, the “rest parts” of the protocol leaves it going nowhere. And unfortunately, there is no way to solve the problem for Zigbee.
So even though Zigbee is free, we still decide to take years creating a new protocol, Hornet Mesh.
Hornet is an abbreviation for “Hub Oriented Routing Network”.
The Root of Problems - Conflict of Interests
The protocol stacks, that comes with the chips, are from chip vendors. And they are all free.
Vendors are all members of the Alliance, along with device vendors. They all share the same interest, to sell as many products as possible.
Here come the end-users. They have no choices. And they are on the weak side of asymmetric information. When something is wrong they won’t know the cause. And their complaints will be made insignificant anyways.
Our Goal - Do the Right Things
Our goal is simple, we design a protocol that is optimal for end users.
We try our best to make it compatible with existing Zigbee products. If we can, it will be great! If we can’t, so be it!
As it turned out, it is possible to support existing Zigbee products in our network.
We overhauled every layer of the protocol from scratch while keeping maximum compatibility with the Zigbee protocol.
Our protocol has MORE encryption keys than the latest Zigbee and Bluetooth protocol.
Every pair of devices MUST have a unique encryption key for end-to-end communication if one device controls another in the pair.
Hornet is not designed for a pure ad-hoc network where there is no center.
In Hornet, the Hub, which is also the “Trust Center”, is the center node. And it is the only node other nodes must trust.
Our design is optimal for our application, while Zigbee is not optimal for any application.
The design basically affects a lot of things:
- Network address allocation
- Encryption keys generation and distribution
- Device join and rejoin operation
Those design choices directly affect the user experience. Users will tell the difference!
At the time Zigbee was designed, MCUs typically have about 8KB of memory. To be honest it is not enough and it negatively affected the design decisions of routing at that time.
Nowadays it is common for MCUs to have 32-64KB of memory. It is still limited but more than enough to do whatever we want to do in terms of wireless protocol design.
In mesh-network, the environment is constantly changing. Source routing is never going to work well, not to mention its complication with memory management.
The current Zigbee routing practice is not suitable for either large network and dense network. It also has some problems with sleeping devices.
Here is how Hornet’s design that solves the problems we identified above:
- A Hornet node can switch its role between Router and End Device on demand.
- A node has a big routing table with 384 entries (or more).
- Route discovery implementation has been tweaked
- Minimize the need for route discovery (AODV)
- Minimize the waste of routing table spaces in unrelated nodes during route discovery
- Manage the optimal number of routers (and their location as well). Remember a node can switch between Router and End Device on demand!
- Source routing to parents! We reduced routing tables entries by an order of magnitude while making routing more precise and significantly reduced latency.