A case for mesh networks

A case for mesh networks

A note from Amatis CEO Sebastien Gouin-Davis:

Amatis Controls has been developing and optimizing IP based wireless mesh networks for IoT applications since 2011. We currently have over 20,000 connected devices in the field, network sizes between 50 and 500 devices, sites with thousands of devices, and over 4 billion unique data entries in our cloud annually. We also decided to do this in what (surprisingly) turns out to be one of the most challenging IoT applications, commercial lighting controls. We have watched other companies trying to do what we do come and go, and each time new myths are created that have a tendency to live on.

With Particle.io announcing the deprecation of their mesh offering this week, I’d like to address some of the challenges they faced and how we have overcome these same problems.

Read the Particle Mesh announcement here: https://blog.particle.io/2020/01/28/mesh-deprecation/

A recent post from Particle announced a sunsetting of Particle Mesh, their mesh networking developer kit solution. From one IoT comrade to another: we’re sad to see you leave the mesh game. We see so much potential with mesh networks for the right applications and feel that we need to respond to many of the issues Particle faced, and talk about how we have dealt with them.

Particle cited two reasons that mesh networking was not the right fit for their platform.

1. MESH NETWORKING IS COMPLEX AND HARD TO ABSTRACT.

2. 802.15.4 MESH NETWORKING ISN’T RIGHT FOR EVERY CUSTOMER.

Although at face value we agree with both of these statements, Amatis has been able to be successful with the buildout, deployment, and scaling of wireless mesh because of our dedication to the finite details and the iterative way we navigate solving problems.

Our Perspective

1. MESH NETWORKING IS COMPLEX AND HARD TO ABSTRACT.

Particle has set the bar for elegant abstractions to complex problems. I can definitely understand how wrapping an abstraction of the Thread Protocol into their ecosystem would be particularly challenging and why they would decide it was not a good fit for them.

Although we agree that mesh networking can be complex, we don’t think it needs to be. It’s important to note that not all mesh networking technologies work the same way. The Thread Network Protocol, the chosen mesh network technology for Particle, was originally built for residential applications by Google for their Nest home products and has proven difficult to scale to commercial applications.

It’s also important to remember that we are really talking about WIRELESS mesh networks that have application layers riding on top of them. This matters because things like wireless range, interference, network traffic, the type of traffic, and even the weather can play into the performance of a mesh network. Time and time again we have seen any one of these elements fail in a given application, and the resulting failures be couched as “mesh issues”. These things are a system, and if the system fails to take into consideration all of its parts, it’s doomed to a future of corner cases and instability.

All of that being true, we have found a combination of the following things make it possible to abstract the wireless mesh network layer sufficiently for sophisticated commercial applications:

1. As a rule of thumb, devices relying on wireless communication need to be able to communicate well at 2X the typical installed range.
   1. For example, if you have a device that typically gets installed no further than 20 ft from its nearest neighbor, it should have a range of at least 40 ft.
   2. This allows for some slop in the system to handle curveballs like refrigerator walls, concrete slab floors, and everything else you can imagine.
   3. Amatis devices communicate at 2.4GHz (the same frequency as Wi-Fi, Thread, Bluetooth, and Zigbee) as far as 500 ft line of sight, so we specify 200 ft max range between devices, and see them typically installed between 50 and 100 ft. This helps us minimize the number of devices that are hard to communicate with.
   4. This is primarily a problem solved in hardware, and although sub-GHz technologies inherently have a greater range than 2.4GHz, they have other drawbacks, and we know it is possible to get the range needed from 2.4GHz.
2. The routing protocol needs to be as stateless as practicable.
   1. In order to scale, devices should only need to retain information about their immediate neighbors, and not the whole network.
   2. RPL (Routing Protocol for Low-Power and Lossy Networks) has an elegant and simple implementation of this concept and over the years it has proven to scale much better and be more robust than the equivalent Thread strategy.
3. The application layer needs to be respectful of the network stack it sits on top of.
   1. Wireless networks are inherently lossy (cuz physics), and every message that is sent affects the mesh and the associated routing algorithm.
   2. The application layer is what enables devices to actually do stuff with the messages they send each other. This is the code that decides how often to send messages and how gracefully it will fail when a message is missed.
   3. The application layer needs to be stateless, fault-tolerant and send the fewest number of messages as is practicable.

Beyond these three rules, we also think choosing open source technology (versus proprietary) has been a key factor in our success.

Amatis uses a combination of good hardware, the Open Source Contiki OS, CoAP, RPL, and a very intentional application layer to deploy 802.15.4 networks that have a range of 200 ft between devices and can handle up to 500 devices per Border Router. For most customers, the mesh is not something they need to think about, and the mesh just works.

2. 802.15.4 MESH NETWORKING ISN’T RIGHT FOR EVERY CUSTOMER.

We agree wholeheartedly here, mesh networks are not right for all applications. If the following is true, an 802.15.4 mesh is most likely not right for you:

1. There are fewer than 10 total devices per application.
2. Cellular connectivity is an option.
3. You require a range greater than 200 feet between devices.

In spaces that require hundreds of devices per application, cellular connectivity isn’t a reliable option, and ranges between devices are relatively minimal, then mesh networks are ideal. In the lighting control world, this ideal application is found in commercial and industrial buildings, and there is a HUGE opportunity. In fact, there are roughly 6 million commercial buildings covering 87+ billion square feet of floor space in the United States. With the rise of electricity prices nationwide, stricter government regulations for reducing energy usage, and the expensive nature of traditional wired solutions, wireless lighting controls have become a popular solution to solve these issues.

Because the majority of our devices are installed in lighting controls applications our platform has been put to the test in many challenging scenarios. We have successfully deployed networks that pass through 24 inches of concrete, refrigerator walls and an assortment of metal boxes. We just fielded a grocery store project with multiple industrial freezers each with roughly 30 devices in each, and they are communicating seamlessly with the devices outside of the freezer.

To date, we’ve focused on commercial lighting control applications for our system. Customer and user experience have been critical and iterative for us.

Lately, we have seen a number of companies argue that 2.4GHz just doesn’t have the range needed and sub-GHz is the only solution. Our many successful field deployments say otherwise. Unless the three criteria above are met, we feel strongly that our wireless platform is probably a good fit for your application.

In Closing

We didn’t get it all right the first time and ran into a lot of the challenges that Particle and Thread have faced over the last 8 years, but our installed applications speak for themselves: mesh can be seamless and scale. We learned that focusing on the right application matters. For example, most of our installations are in commercial buildings, which are a perfect fit for our 30-200ft device-to-device range.

Amatis was involved in Thread early on (in 2015) and came to the conclusion that it was going to be a long time before it could scale to meet the demands of commercial large scale IoT applications, like lighting controls. Open source stacks are critical to us, and at the time, Thread and other solutions were not viable options. As a result, we identified the mesh platform we started on as the best option.

We know about the potholes with mesh networks because we’ve driven through them.

Our early product was bound by the same range constraints that Particle had because, like them, we didn’t include an amplifier on our first module. We have been making mistakes for 9 years, and we’re proud of the way we’ve navigated and learned from them. With failure comes critical learning, and we’ve been fortunate to have proving time to iron things out.

Our secret sauce is our underdog culture: we solve problems with inherent, enforced agility. We’re agile because it’s our survival tactic and we wouldn’t have lasted 9 years without it. We have no choice but to be efficient, and this urgency drives us to approach our daily work with a ruthless view of effort versus impact.

At Amatis, culture is a big topic, and we’re ok with being wrong. We’d love a seat at the table of IoT and would love to chat with anyone eager. Looking forward to the discussion, and thanks for reading!