A wireless mesh network is a network where the nodes in the network help other nodes achieve coverage and connectivity by forwarding messages on behalf of others.
Street lighting systems is an example of where a wireless mesh network is needed. A single-hop network would not provide enough coverage, so the lights help each other to reach out.
A wireless IPv6 mesh network in the wild.
The picture above shows an installation of a Thingsquare IPv6 mesh in the wild. (Although our system is known to be able to run on really, tiny devices operated by a single coin-cell battery, this particular installation does not use those low-power mechanisms as street lights have access to power.)
The big challenge with such a large wireless network is to understand what is going on – and how to develop the software that makes them tick.
In this article we look into how we develop such large-scale systems at Thingsquare and the tools we use. We push the envelope with a 100-hop network, which is larger than what we typically would see in real-world installations.
A 100-Node Wireless Testbed
To see what happens in a 100-hop network, we have built a testbed in our office. The testbed consists of 100 wireless nodes placed in a bookshelf. The nodes all use the TI CC2538 wireless System-on-a-Chip, running the Thingsquare wireless mesh over a IEEE 802.15.4e low-power radio layer. The nodes are powered by USB, but otherwise have only a wireless connection. Each node also has an LED, which we use to develop and test our wireless lighting system. By default, the nodes form one large wireless network.
A 100-node testbed and the wireless mesh network created by the nodes in the testbed.
Because every node in the testbed is close to each other, they can easily form a single-hop network. That is, every node can reach every other node without meshing.
To setup a 100-hop network, we manually configure their routes. This way, we can force the system to become a 100-hop network.
Setting up 100 Hops
After configuring the system to have a 100-hop structure, the mesh looks like this:
The 100-node testbed in a 100-hop wireless mesh configuration.
We now have a way to test the system with 100 hops, something that is beyond anything we are likely to see in the wild.
100 Hops in Action
To see the 100 hops in action, we set up one node to act as a sniffer and run Wireshark to capture the packets from the network. We then ask the node that is 100 hops away to make a secure TLS connection with the backend. In the Wireshark logs, we see the TLS traffic as well as the ICMPv6 control traffic that is used by the RPL routing protocol to set up and maintain its routing graph.
(For more in-depth information about the RPL IPv6 routing protocol, see this article from our docs.)
Wireshark logs from the sniffer showing ICMPv6 and TLS traffic.
If we look at the traffic inside the network, we can see how the packets move from node to node, in a snake-like manner:
Packets move through every node in the network, 100 hops in total.
In the Simulator
A wireless mesh system is extremely complex and while a testbed is essential to testing the system, it is not enough for developing it.
To develop our wireless mesh system, we use our wireless network simulator. The simulator lets us set up the same environment as we see in the real world, but on a single computer. There, we can inspect almost every aspect of the system to see what is going on.
The Cooja wireless network simulator.
To see a similar behavior as we did our testbed, we set up a simulation with a regular grid of nodes and configure them in a similar fashion as we did in the testbed: they choose parents in the routing graph to make the network as long as possible.
The simulator also lets us see the packets in a timeline window, where we can see exactly what each node does at any given time.
A TLS connection in the network and timeline views. We see the packet exchange across multiple hops.
Wireless mesh networking allow us to build extremely large-scale networks. But such networks are complex and to build the software that make them tick, we need both hardware testbeds and software simulators.