Huninn Mesh Part 1 - What is it?

I am currently working with Huninn mesh, a startup that sells monitoring and control systems that use network of IEE 802.15.4 based wireless devices.  

The stand out capability of a Huninn mesh network is its efficiency: the system can cope with large numbers of networked devices that generate many small data packets.

Physically, devices are compact, battery powered and have a long operational lifetime of five years or more.  These characteristics make a Huninn mesh network an ideal fabric on which to build dense network, low bit rate applications that fall under the umbrella of the ‘Internet of things’. 

This is the first in a series of posts where I discuss the Huninn mesh system.  In this post, I provide an overview of the Huninn mesh network.  In a follow up post, I will go into a deep dive about the back end server infrastructure that handles the data from a dense network in order to provide a platform for service creation.

Huninn Mesh Devices 

A Huninn mesh network extends the IEE 802.15.4 standard with a proprietary higher layer protocol.  A Huninn mesh device is any device that implements this higher-level protocol.  (From here on in, I’ll use term ‘mesh’ interchangeably to refer to a Huninn mesh device or number of Huninn mesh devices configured into a network – where it is not clear from the context, I’ll revert to the long form.)

At its most basic, a mesh device is radio coupled with a simple, low-specification CPU, a tiny amount of memory and, all importantly, one or more sensors.  The device firmware supports simple ‘script’ commands that are delivered over-the-air and provide a very basic programmable capability.

A script instructs a mesh sensor when to do something:

• measure something via a sensor;
• listen for a message from another mesh device; or,
• send a message to another mesh device.

As noted, a typical mesh sensor is compact – about 10cm by 10cm by 1.5cm – has a single, non-replaceable internal battery that gives an operational lifetime of at least five years and a can measure two or three parameters via its onboard sensors.  For example, devices exist that measure dry bulb temperature, atmospheric pressure and relative humidity.  In addition, all devices measure their own ambient network environment, battery level and so on.

The longevity of battery-powered units is achieved through quiescence: for almost all of the time devices are in a low power ‘hibernation’ mode.  Exactly when a device wakes up from hibernation and what it does when it is in the ‘active’ state is under the control of a remote server that provides command scripts – the what and when – to the device. 

There are also gateway devices, powered by mains electricity, with a more powerful radio, that provide a means of bridging between a Huninn mesh network and some other network – typically, the Internet.  Gateways are atypical: they are always on by design and have no sensors.  Their only job is to provide a service to the many battery-powered devices in their vicinity.

Finally, there are also mains powered relay devices - essentially, gateway devices without a NIC whose job it is to relay messages over longer distances or where signal attenuation is too great for the radio of battery powered devices.

Recall the earlier point that any mesh sensor can receive and forward messages from any other sensor.  If a sensor can ‘see’ the gateway, it can deliver the measurement directly.  If it cannot, then it can pass the measurement on to another relay or sensor, and so on.

A mesh network of sensors (blue) communicates via a single gateway (purple) to the Internet. 

This represents the defining capability of a mesh network: nodes do not have to be connected to a gateway in a traditional hub and spoke topology.  Instead, very complex topologies can be created which involve multiple ‘hops’ from one device to another before eventually reaching a gateway.  Huninn mesh has demonstrated one such multi-hop network with over 100 sensors configured in a chain topology.

 

Huninnmesh has deployed 100 sensors in a chain topology.

The Huninn mesh Control Server

Central to the mesh concept is a server whose job it is to manage this network of very simple devices. 

From the server’s point of view, a network has a goal – for example to measure the internal temperature, pressure and humidity at multiple points within a multi-storey building.  The job of the server is to evaluate how best to achieve this goal.  Once it has done this, it dispatches command scripts to each device telling them what they should do when.  This programmable nature means that a Huninn mesh network qualifies as a true software defined network.  

Clearly the server needs to ‘know’ about all of the devices in the network under its control.  It ‘learns’ this via a bootstrap process whereby new devices or groups of devices announce themselves: they discover each other and, by so doing, find a gateway that can be used to pass their details to the server paired with the gateway.  Suffice it to say that this happens but, in this post, I shall not go into detail as to how.

With reference to its goal, the server uses an algorithm to build configuration tables for each device.  These tables rely upon every device in the system having a shared understanding of slots allocated to time and network channel. 

Example configuration tables might say:

• Device A: In time slot 12, integrate temperature and pressure measurements, package these and send as a message on network slot B in time slot 13.
• Device B: In time slot 13, receive a message on network slot B and send this on network slot D in time slot 14.

Message payloads are encrypted and signed at the device preventing eavesdropping and man-in-the-middle attacks.  Message envelope overhead is small compared to payload size, meaning that time-slots can be very short.

As soon as a task is complete, a device immediately hibernates until it is required again.  Everything works with a metronomic beat, moving data through the network in an efficient manner and, so far as possible, doing nothing else for the remainder of the time.  Since the entire system relies on accurate clock synchronisation the device firmware works with the server to accommodate drift and keep every device in lockstep.   

One side effect of the need to keep battery powered network nodes in hibernation is that messages are not dispatched immediately.  Event based message payloads (as opposed to regular time series data) can take fifteen seconds or more to reach their destination.  The time to deliver a message generated by an asynchronous event depends on the time spent in hibernation, number of network hops, etc.   It is a function of system design and subject to battery tradeoffs: a thirty second lag may be acceptable for HVAC control but not for light-switching.

At the time of writing, the state of the art for a stable Huninn mesh using a single gateway is approximately 250 devices each measuring two or three parameters at a up to fifteen second intervals. 

One aspect worthy or a more detailed discussion is battery trade-off.  Consider the 100-hop case discussed above.  The last battery powered device before the mains powered gateway has to wake in order to accept and relay messages on behalf of the 99 ‘upstream’ devices.  Functionally, this is highly desirable, but it comes at a cost to battery life. 

The server uses multiple strategies to minimise battery cost without sacrificing reliability.   In the first instance, using its knowledge of wireless topology, it minimises the hop-count across battery-powered devices.  Therefore, in an ideal case the server will eliminate any hops and arrive at a hub and spoke network.

A hub and spoke network topology imposes the minimum burden on a device's battery.

Where the wireless topology prevents such a network forming, the server attempts to minimise the number of hops to a powered device and also to load spread across battery powered relay devices. 

Even though the device has sophisticated battery management hardware onboard, the server is also able to assist in power shaping by smart choices that seek to harness the recovery effect of the battery. Since battery powered devices also report the battery voltage, the server can understand the true cost of a particular configuration and, in the longer term, use machine-learning techniques to optimise further.

Of course devices fail and wireless conditions constantly change.  For this reason, the server is constantly evaluating the best possible configuration for all of the devices under its control.  By so doing, it is able to evolve and heal the network over time.

Stepping Back

At this point it is useful to step back and examine the big picture – why a Huninn  mesh in the first place?  To answer this, I’ll use the example of building comfort management.

Most people have experienced an uncomfortable office environment: either too warm or too cold.  In older real estate, the reason for this can often be traced to the fact that the output from a single wired thermostat determines the heating, ventilation and air conditioning settings for an entire floor. 

Increasing the number of sensors on a floor improves the information available to the manager who programs the HVAC.  It often proves to be prohibitively expensive to re-wire an entire building with multiple sensors not least because occupants are disturbed, skilled tradesmen are required and a significant amount of time is required. 

A Huninn mesh sensor network does not suffer from these problems: 

• Sensors are battery powered – no wiring required & no mess for tenants.
• Sensors are cheap – many can be deployed.
• Installation is trivial – stick a sensor onto a wall, activate it and walk away.

By far the most complex task is the installation of the single gateway and relays as required.

By way of illustration, we outfitted a forty five year old building on Broadway, NYC that has fifty floors each of which is 24,000 sq. ft.  Floors were instrumented with mesh sensors, some having twenty sensors and some less.  Each sensor measures temperature, pressure and humidity and samples at fifteen-second intervals.

This serves to illustrate why I stated that Hunnin mesh network is ideal fabric for the low bit-rate portion of the Internet of Things.  Temperature, pressure and humidity measurements are sixteen bits each.   They are measured at fifteen second intervals from 200 sensors.  This creates a wealth of data for the building manager without the cost and headache of an expensive building refit.  

A Hunnin Mesh

In this post, I have tried to give a very high level answer to the question of what is a Huninn mesh and why would I want one in the first place.

In summary, a Hunnin mesh provides a low cost means of getting information to and from a large number of wireless devices.  Typically, these devices measure some parameter, say temperature, pressure or humidity.

In my next post, I will provide a deeper dive into some architectural aspects of the cloud system starting with the gateway.