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.
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.
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 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.
