Particle Mesh 102: selecting a role for your device

Particle has discontinued development of Particle Mesh, our OpenThread-based mesh networking solution, and will no longer be manufacturing the associated Xenon development board. Particle will continue investing in its other “Gen 3” products, the flagship cellular (Boron) and Wi-Fi (Argon) product lines. Read more about the deprecation here.

In a Particle Mesh network, there are three types of roles a device can take: a gateway, a repeater, or an endpoint. A previous post, Particle Mesh 101, introduces the basic concepts of roles but stops short of suggesting which role a particular device in your network should take.

This post picks up where the last left off. By the end of it, you’ll learn a quick approach to selecting the right role for your device and be introduced to the relationships devices have in Particle Mesh networks.

Roles describe the networking responsibility of a device

Roles define the network and routing responsibilities of a device in your Particle Mesh network, yet assigning a particular role does not limit the functionality of your Argon, Boron, or Xenon. Regardless of their role in the network, all three boards can run custom application code, interface with the peripherals like GPIO, and make Particle Cloud Primitive calls.

The quick approach to selecting a role

Determining the right role for an Argon, Boron, or Xenon is as straightforward as asking yourself what radios are available on each device.

Note: For now, you should exclude counting a Bluetooth radio, since its initial function in Particle Mesh is to provision a device not handle network traffic.

Boards Wi-Fi Cellular Mesh

Gateways connect disparate networks

As a general rule, if your device features a Wi-Fi or cellular radio in addition to mesh radio, like the Argon or Boron, it’s well-suited for the role of a gateway.

Wi-Fi gateways

For the Argon, the role of a gateway brings the responsibility of routing network traffic between the local mesh network and the Wi-Fi network it is a client of. It handles the additional network management responsibilities of authenticating and provisioning other devices to the mesh network and routes local traffic to the Particle Device Cloud.

Cellular gateways

Whether you have a Boron 2G/3G or the Boron LTE, both versions make for great gateways. A Boron gateway takes on the same responsibilities as an Argon gateway except the Boron connects the local mesh network and a cellular network.

Repeaters & Endpoints

Xenon with a gas sensor

A corollary to the general rule above is that if your device only has a mesh radio, it’s best for the role of a repeater or endpoint — the Xenon is a great example.

As a repeater, the Xenon increases your mesh network size and coverage while keeping costs low — after all, the Xenon is the least expensive of the Particle Mesh boards. As an endpoint, the Xenon can be powered off of a coin cell battery and can enter a sleep state to conserve battery life. When sensors need polling, the Xenon can wake-up and take measurements.

But this raises a big question, which of the two roles — repeater or endpoint — should a Xenon take? To properly answer this question you need to know about a low-level mesh networking concept: device relationships.

A family of device relationships

As you learned, gateways and repeaters have the responsibility to route network traffic in a Particle Mesh network. Because of this responsibility, they need to keep a record of all of the devices on the network. This is done by applying a parent-child metaphor to the devices roles in the network.

In Particle Mesh, gateways and repeaters are considered parent devices and endpoints are child devices. The parent-child relationship is built into the low-level mesh protocol and does not require you to configure anything.

No sleep for parent devices

Parent devices cannot be sleepy because they are responsible for routing traffic. If a parent device goes to sleep, network traffic wouldn’t be able to find a route to its destination and the network would fail.

Naps are allowed for child devices

Child devices (think endpoints) can sleep since they don’t need to route network traffic and therefore don’t need to keep track of all the devices in the network.

For example, a child device that has a sensor attached to it can record sensor values, send them to the cloud, then fall asleep to save power. When more values are needed for the device, it can wake up and record sensor values, rejoin the network and send its readings, and then fall back asleep.

So, if you want your Xenon to enter low-power mode, pick the role of an endpoint; if power isn’t at a premium, you’re probably fine giving your Xenon the role of a repeater.

Now that you know which devices should generally be used for a particular role in Particle Mesh and gained a bit of familiarity with the parent-child relationship between devices, you should have a better sense of the devices you need for your mesh network.

And don’t forget, during the Particle Mesh preorder, hardware prices on all the new hardware are discounted, make sure to get your boards and join the mesh conversation in the forum.

Author Bio

Sr. Content Manager at Particle. Into OSHWA and EFF and so should you! Linux geeking since 1.2

4 responses to “Particle Mesh 102: selecting a role for your device”

  1. Just a question can i add a boron in a network that has argon and xenon?
    For example i want to monitor a lot of temp sensors with xenon and send it back to argon showing this information in a costume web page
    Then if a set one alarm to any of this temp to send it to boron in the same network to send me a phone massage. Thanks

  2. David, I have posted a topic on the Community but not had any reply yet. I am interested in developing out the IoT mesh network solution architectures with some practical pointers and going a bit further than your excellent but high level 101 and 102 blog articles.

    What I am thinking of here are topics like:
    – Using/Designing high availability gateways
    – Best methods for monitoring battery health of end-nodes
    – Guides for designing networks: Repeaters (always powered) and End-nodes (battery powered/mostly sleeping)
    – Best methods for communicating to/from end-nodes – handling devices being asleep/gateway stores and forwards

    Thanks in anticipation. Will

  3. Great, the information is really a useful one. Now I am very much confident and have the knowledge about a particular role in Particle Mesh and also a bit familiar with the parent-child relationship between devices. If you want more information, you can check Facebook and other technical sites.

  4. Thanks for the wonderful blog! really informative.
    One question, how does sensor connected to endpoint send data to cloud, ie. AWS infra using AWS API?

Leave a Reply

Your email address will not be published. Required fields are marked *