Mesh networks are an integral part of the burgeoning decentralization movement, and critical to realizing its vision. In this two-part article, we will provide a broad introduction to the concept of mesh networking: what are mesh networks and how did they evolve, why are they technically challenging, and what are the protocols that make meshing possible. Understanding mesh networking conceptually can help us make sense of the products on the market and to appreciate the operational constraints. Although mildly technical, the article will not assume any background in mesh or even general networking.
In this first part, we discuss the basic concepts, evolution and challenges of mesh networks. Keep an eye out for the second part in which we will describe some of the mesh networking protocols and their pros/cons.
Although you are likely aware of the general concept of mesh networks, let us begin with a definition of sorts. A wireless mesh network is a network of devices (often called nodes) that communicate with each other using peer-to-peer wireless links typically over multiple hops – that is, by bouncing a message from one device, through another, and landing at a third (or fourth, etc.). This kind of network also operates in an infrastructure-less and decentralized manner, meaning it doesn’t require great resources at the back end to be usable, and no one node is prioritized over another. It is customary to drop the word “wireless”, that is, a mesh network is assumed to have wireless links. The nodes in a mesh network may or may not be mobile depending on the application but in this article, we will use “mesh networks” synonymously with “mobile mesh networks” unless explicitly stated.
A brief history
Mesh networks have primarily evolved as a way to provide connectivity where centralized infrastructure is either not available or not usable. The defining features of mesh networks — namely decentralized, infrastructure-less operation over multiple hops — have manifested themselves over the last several decades in different forms, for different applications, and by different names. Its history dates as far back as the early 1970’s with the development of packet radio networks by the US Defense Advanced Research Projects Agency (DARPA), that sought to replicate the ARPANET (the forerunner of the current Internet) over wireless. These networks used bulky low-throughput radios built by Hazeltine, and was the foundation for a long thread of mesh technology development within the military.
In the early 90’s academics and researchers at commercial labs started experimenting with laptops equipped with wireless cards creating a mobile ad hoc network (MANET). Along with the rapid growth of 802.11 (WiFi) technology over the next decade, this spurred a lot of interest in the development of protocols for mesh networks, some of which remain standards of the Internet Engineering Task Force to this day. Community networks consisting of WiFi routers or custom-built devices followed, and began to be called mesh networks. The Internet boom at the turn of the millennium saw the birth of several mesh networking companies targeting in-home range extension, last-mile connectivity and city-wide networks.
With the proliferation of sensors in a variety of contexts, sensor networks emerged in various applications, finding support in standards such as Zigbee, and sensor networks became an integral part of the Internet-of-Things (IoT) boom. Today, mesh networking products are commonly being used in the military, emergency response, community mesh, recreation and disaster relief. For example, the goTenna Pro and goTenna Mesh cater to the professional and recreational/civilian markets respectively.
What makes mesh networking hard?
Although the concept has been around for nearly 50 years now, mobile mesh networking is still a research area, and many experts consider it an unsolved problem. Given that the Internet and WiFi are both well established, what are the problems that make mesh networking so challenging?
The first challenge in mesh networking is the wireless link itself. Wireless communication technologies are locked in a multi-way tradeoff between communication range, data rate (link throughput), cost, and size/power. It’s like a whack-mole game — you optimize some, but then the others become problematic. For example, if you have a low-cost, small, low-power radio such as your smartphone or the goTenna device, you either have to compromise on range or on throughput. Without sufficient range, a mesh network is disconnected, and without sufficient throughput, it is unusable. The smartphone sacrifices range whereas goTenna prioritizes it. (We’ve previously discussed why range is the right feature to prioritize for mesh networks.) If you need both range and data rate, we either need sophisticated wireless techniques, such as Multiple-Input-Multiple-Output (MIMO) modulation, high power radios, or both, resulting in bulky expensive devices — this is the tradeoff that traditional military vendors have opted for. So how do we select or create technologies that find the right point in the tradeoff space? That is, how do we win at whack-a-wireless-mesh-mole?!
Another key challenge is how the wireless broadcast channel is shared between nodes — commonly referred to as medium access control (MAC). Unlike a centralized system such as a cellular network, a mesh network does not have a controller to hand out access rights. Nodes have to execute a decentralized algorithm to equitably share the channel. The obvious idea of each node sending at a random time results in too many collisions and poor performance. Just think about old school walkie-talkies: this is why we had “Alpha to base” and “over and out” – so messages wouldn’t run into each other. Unlike an Ethernet, it is much harder to detect collision in wireless mesh networks. Some kind of “listen before talk” seems the next step, and indeed this is the basis of many solutions. However, even with this, a thorny problem that has tormented researchers for decades is the hidden node problem. When two nodes cannot hear each other, how do they coordinate to prevent collision at a common node? In general, how can we ensure efficient and equitable access in a decentralized manner under mobility?
When communication needs to happen over multiple hops, we encounter the much-studied problem of mesh routing, or the even harder problem of MANET routing, which is routing when the nodes are mobile. There are two main use cases here: (1) a packet needs to be sent from a given source node to all other nodes efficiently (called broadcast routing, or broadcasting); and (2) a packet needs to be sent from a given source node to a given destination node through intermediate nodes (unicast routing). Broadcasting is used for position updating for mapping, emergency beacons and so on, whereas unicast routing supports private chat messages, amongst other applications. Both broadcasting and routing need to be performed without global knowledge of the network, in a decentralized manner, and with constantly changing connectivity due to mobility.
To appreciate the challenge of decentralized routing, consider the fact that unlike Google Maps where a central server has the entire database of roads, a mesh node does not know which other nodes it can reach, where those nodes are, where the node it wants to communicate with is, how many hops away it is, or if a multi-hop path even exists. If the entire connectivity graph were visible at a single node, it is easy enough to find a path using shortest path algorithms which are a part of an undergraduate Computer Science curriculum. But in mesh networking, a node needs to exchange information with other nodes to cooperatively route — and they should be very thrifty about the amount of information because wireless bandwidth is limited. So the challenge is to figure out how much information should be collected, what each node should do, and how to handle mobility and path breakages. On top of that, we need to keep the size of this “control information” as small as possible so there’s still room to send our actual messages.
It is not too hard to find a solution to these problems — for example, the solution of flooding, that is, having every node repeat every transmission, solves both routing and broadcasting. However, this is not a scalable solution. The figure at left shows, based on simulations, the increase in total number of packets transmitted as a function of size when each node generates two packets a minute. This increase is quadratic in nature, and it is clear why with a little thought — each node transmits every packet once and there are 2N packets generated per minute, which implies total packets in air is 2N2. This quadratic growth means that the capacity will be overwhelmed quickly as size increases. Mesh networks are bandwidth-constrained and energy-constrained, especially those that tradeoff data rate for range, and hence the growth of packet load as a function of size needs to be curtailed. And this is hard.
These are but a small fraction of issues that make mobile mesh networking a fascinating, rich, and challenging field. We encourage you to think about these problems and see if you come up with any ideas. In the upcoming Part II of this article we will discuss some ideas, protocols, and standards that have been developed for mesh networking over the years to surmount these challenges.