Is wireless mesh a poor choice for sleepy devices?

Chris Steinbach
  • Is wireless mesh a poor choice for sleepy devices? Chris Steinbach

    I've been thinking about what it would take to build a temperature sensor network for the block of apartments I live in. A wireless mesh, if it would work at all, would have some nice features. In particular, I could place sensors in the garage and cellar storage areas where no mobile or Wi-Fi signals would otherwise reach.

    A possible reason not to use mesh is that I would probably also want to use sleepy end devices to avoid changing batteries often. From what I can see, the only way this is going to work is with clock synchronisation so that the devices wake up at the same time and long enough for the signal to propagate through the network.

    While I've heard such a solution described, I wonder how well that would work out in practice. Presumably periodic clock synchronisation needs to be added to the protocol to avoid drift. Does anyone have experience with this, and are there other strategies for using mesh and sleepy devices together apart from clock sync?

  • It is actually possible to allow for sleeping nodes without the need for time synchronization. The basic idea is to send a message multiple times until the node finally wakes up. There is of course a lot of room for clever optimization, so there are hundreds of MAC layer approaches based on this idea.

    But since your question specifically asks for MAC layers, where a node knows when to transmit in advance, i.e. Time Division Multiple Access (TDMA), I will focus on those approaches.

    As you already mentioned, one problem is clock drift, so the devices have to wake up regularly for time synchronization. In the typical short-range wireless applications we are talking about, signal propagation duration itself over a single hop is not a big problem. So it is sufficient that a central coordinator sends a beacon, including the current time, in regular time intervals that are known to the nodes.

    In a multi-hop network it gets more complicated. Just forwarding the beacon will not work, because the latency is too high. The solution is that multiple (if not all) nodes send beacons, i.e. receive a beacon from a node closer to the coordinator, correct the own clock drift with it and send out an own beacon with the corrected time. You just have to avoid building circles (been there, done that....).

    Since now every node in the network has the same notion of time, there is a second problem: How does a node know when he should wake up to transmit or receive? There are basically four approaches, that can also be combined:

    • Common Slot: All nodes wake up at the same time and use a contention based access method to transmit their packets Advantage: Easy (if you know how to do CSMA/CA). Disadvantage: Prone to collisions, lower throughput.

    • Predefined: For a restricted number of nodes you can just assign fixed slots to the nodes. For example, node 2 can send to node 1 in the first timeslot and node 3 can send to node 2 in the second timeslot. Advantage: Dedicated slots and no collisions. Disadvantage: The topology has to be fixed (very difficult in wireless mesh networks).

    • Centralized: A central coordinator requests information from the nodes about the topology, calculates a global schedule and distributes it again to the nodes. Advantage: No predefined topology required. Disadvantage: Scales poorly and is prone to topology changes (the whole process has to be restarted).

    • Decentralized: Two nodes that want to communicate negotiate the slot themselves. It is quite complex, because they have to make sure no neighboring devices transmit at the same time. Advantage: Scales well because the negotiation is local. Disadvantage: Complex to implement.

    There are two related techniques included in the IEEE 802.15.4 standard that currently find much research attention: TSCH and DSME.

    TSCH itself is quite basic. It only solves the time synchronization problem, but leaves the slot assignment problem for an upper layer. There is 6TiSCH that tries to fill this gap, but it is still work-in-progress. There are implementations, for example included in Contiki or OpenWSN.

    DSME on the other hand already provides a mechanism for decentralized slot negotiation. We have actually build an open-source implementation of this called openDSME. While there is a video tutorial for running a simulation, the hardware implementation is unfortunately still underdocumented. Ask another question or contact us directly if you want to use it.

Tags
zigbee power-consumption mesh-networks
Related questions and answers
  • I've been thinking about what it would take to build a temperature sensor network for the block of apartments I live in. A wireless mesh, if it would work at all, would have some nice features... to use sleepy end devices to avoid changing batteries often. From what I can see, the only way this is going to work is with clock synchronisation so that the devices wake up at the same time and long enough for the signal to propagate through the network. While I've heard such a solution described, I wonder how well that would work out in practice. Presumably periodic clock synchronisation needs

  • I have a project where I need to create a Wi-Fi mesh network of nodes sharing a distributed mesh database that requires relatively quick search access on each node. I was initially thinking... fallback option is to run Windows IoT Core on a Raspberry Pi where I can use C# and possibly even a real database. My issue with this solution is that I have not been able to find an example of running a mesh network using Windows IoT Core. Any thoughts or assistance would be much appreciated.

  • I have a project where I need to create a Wi-Fi mesh network of nodes sharing a distributed mesh database that requires relatively quick search access on each node. I was initially thinking... fallback option is to run Windows IoT Core on a Raspberry Pi where I can use C# and possibly even a real database. My issue with this solution is that I have not been able to find an example of running a mesh network using Windows IoT Core. Any thoughts or assistance would be much appreciated.

  • I see several questions asking about details of an IoT network, including this one about port forwarding for example. I think it would be useful to ask about what might be considered the typical baseline architecture for a general-purpose IoT system. We have several questions talking about networking at the sensor side, if mesh-networks are suitable, etc. For this question, I'm less interested... influence the overall network topology. I'm not looking for an exhaustive description, just capturing of the current norm. What general network topology is in typical use today, and provides a good scalable

  • I see several questions asking about details of an IoT network, including this one about port forwarding for example. I think it would be useful to ask about what might be considered the typical baseline architecture for a general-purpose IoT system. We have several questions talking about networking at the sensor side, if mesh-networks are suitable, etc. For this question, I'm less interested... influence the overall network topology. I'm not looking for an exhaustive description, just capturing of the current norm. What general network topology is in typical use today, and provides a good scalable

  • I have an IoT device that is connected to a WiFi network. Currently, the IoT device runs a small HTTP server, and send RF signals when it receives POST requests via the internet from HTTP clients. To make this work, I have to enable port forwarding on my WiFi router, and the HTTP clients have to connect to the IP address of the router. This seems like a bad way to go about it. I notice there are devices that work from within WiFi network - like Ring doorbell, Wink devices, etc, that does not require port forwarding, etc. I am wondering how this is done. I am guessing that these devices

  • I have an IoT device that is connected to a WiFi network. Currently, the IoT device runs a small HTTP server, and send RF signals when it receives POST requests via the internet from HTTP clients. To make this work, I have to enable port forwarding on my WiFi router, and the HTTP clients have to connect to the IP address of the router. This seems like a bad way to go about it. I notice there are devices that work from within WiFi network - like Ring doorbell, Wink devices, etc, that does not require port forwarding, etc. I am wondering how this is done. I am guessing that these devices

  • I am trying to pull a few bytes per second from a microchip board attached to a temperature sensor and a photodiode, using Windows 10 IoT on a Dragonboard 410c. It seems like there's either interference when I attempt to read from more than one GPIO at a time. How can I get input from these GPIOs without messing up my clock signal? namespace DashWall { public sealed partial class MainPage...; bool temp; private void Timer_Tick(object sender, object e) { handleInput(); Time.Text = "" + clock; Temp.Text = "" + temp; if (start

  • I am trying to pull a few bytes per second from a microchip board attached to a temperature sensor and a photodiode, using Windows 10 IoT on a Dragonboard 410c. It seems like there's either interference when I attempt to read from more than one GPIO at a time. How can I get input from these GPIOs without messing up my clock signal? namespace DashWall { public sealed partial class MainPage...; bool temp; private void Timer_Tick(object sender, object e) { handleInput(); Time.Text = "" + clock; Temp.Text = "" + temp; if (start

Data information