Wireless IP Ethernet (802.11) technology has been around for a while. Many know it as “WIFI” but you could also call it “WLAN” or something similar. Like many other Ethernet technologies, WLAN relies on a spoke and hub connection system. The hub is the wireless access point or router and the individual hosts (PCs, tablets, phones, etc) are the end point for each connection. In a wired network, it is usually some type of switch that forms the center of the network data distribution system.
With a wireless mesh network or ad hoc network (802.11s), each wireless device can connect to any other wireless device within range. In this type of peer-to-peer network, there is no central access point, although something can act as an internet gateway or there can be several gateways. This type of topology functions much like the public network (AKA the internet), where there are many different paths to anyone (major) destination. If any one of those paths goes down, another route is quickly found.
This technology was developed by several vendors for military communications systems and for OLPC (One Laptop Per Child) programs in Africa and other places. Each link acts to extend the boundaries of the network, thus the more users there are, the more useful the network becomes.
Advantages of mesh networking:
- Networks are self-forming; once the nodes are configured and can see other network nodes, the network automatically forms
- Networks are self-healing; if one node drops offline, traffic is automatically routed to other nodes. If the node comes back up, it is included back into the network
- High fault tolerance; in areas where many nodes exist and can see each other, the failure of any single node does not affect the rest of the network
- Low cost to deploy; mesh networks use standard off-the-shelf WLAN (802.11) devices. The choice of software will dictate which hardware will work the best
- Crowd-sourced infrastructure; as each network node is owned by an individual, the cost and responsibility is shared among the community
Several specific routing protocols have been developed for the network side of the system. Hazy Sighted Link State Routing Protocol (HSLS), BATMAN, OLSR HWMP and others. These work well with the existing 802.11 a/b/g wireless network hardware currently available.
On the host side, a good IBSS-capable wireless network adapter is needed, which many of the newer ones are. Several of the software programs have lists of WLAN adapters that work with their software. Open Garden is a free App for Windows, Mac OSX, and Android, and they are working on an iOS version. This leaves out certain devices like tablets and iPhones for now.
Since existing wireless adapter drivers do not yet support mesh networking, usually an additional piece of software is needed. There are several interesting ones, including HSMM-MESH, which was developed by Amateur Radio operators. Open-source programs for Linux, Free BSD and other are available as well as commercial versions for Windows.
I was thinking that this might be useful for broadcast applications. For obvious reasons, this type of system would work best in densely populated urban and suburban areas, which is exactly the type of area in which LPFM licenses might be hard to come by. For those who do not have the time or wherewithal to apply for an LPFM license, or for those that simply don’t get a license due to scarcity of available channels, this could be a great way to cover a neighborhood or section of a city. The more people participate in the mesh network, the stronger the network becomes. Additionally, by using FCC type accepted part 15 FM and AM transmitters as broadcast nodes, carrier current transmitters, and leaky coax systems, the presence of the mesh network can be advertized to potential listeners, including directions on how to take part.
Wireless LAN bridges or broadband internet connections can act as a backbone between distant nodes.
For bandwidth efficiency sake, AOIP services should be limited to multicast addresses.
A good site with more wireless mesh network information is http://wirelessafrica.meraka.org.za/
Two subreddits on the subject: /r/meshnet and /r/darknetplan
Then there is project meshnet and the project meshnet wiki
Oh, by the way, go ahead and ask me what I have been learning about in school these days…
So Pauly, how was your day at school? Learn about anything interesting?
Hopefully I learned something, finals are tomorrow…
See http://project-byzantium.org .
Also note that it is not necessary for these systems to be connected to the Internet, or even to each other, in order to distribute content to connected wireless clients.
Thanks Buzz, that is also true. I may redo the diagram to show how this system would work without an internet connection. If it is running on a Linux platform, an apache server can be used as a central content distribution point using a forum, blog or wiki type platform. Once the network is created, the possible uses are almost endless.
Good post, Paul. Hope your classes are going well!
There are a few issues with mesh, the biggest being the issue of hidden nodes and interference. Network engineers tend to forget what is happening at the RF layer and think in terms of every connection between each node being a simple uncongested, error free point to point link becase that’s the way one thinks when considering non-wireless networks.
Conversely Rf engineers tend to forget about what is happening at the IP layers, all those TCP ack’s Flying around, TCP window sizing, bandwidth scaling based on lost packets/delay. UDP traffic broadcast traffic etc.
The hidden node problem is a big issue, Node A forwarding to Node B is also interfering with traffic between other nodes on the network but they may not hear other traffic well enough to avoid transmitting. Mesh networks tend to work great for bursty use but once usage goes up then the RF issues begin to bite.. RF wise it’s an ugly (but interesting 😉 ) mess.
Multicast is a great way to deal with streaming media on wired networks since it is safe to assume that all subscribing endpoints will have zero (to a small fraction of 1%) of media errors. On wireless this is not at all the case so in general multicast is handled on 802.11(a/b/g/n) by sending the multicast frames at the lowest supported data rate for robustness or by using ‘multicast helpers’ that convert multicast traffic to unicast streams. Neither is a great outcome if the goal is to do point to multipoint media distribution.
In summary, mesh protocols are interesting and fill some roles very well indeed, they will however rarely perform as well as planned routed networks with directional links. They tend to be excellent under light loading, bursty traffic etc and fall apart in ugly ways once traffic volumes increase. The strong points are ease of set-up and robustness on the down side capacity and Quality of service are far from optimal.
Brendan, interesting comment. I will admit that I am a bit of a neophyte but it is a fascinating topic for me. I have experience with asyc/TDM wireless data, but not too much with packet switched data. Perhaps another way to form a neighborhood network would be with 5.8 GHz backbones to 2.4 GHz access points dispersed around an area. Something simple that could be powered by a solar panel and a battery. This would not necessarily be connected to the internet, more like a local network for content distribution (pod casts, streaming audio, forum/wiki or news page, etc.) It is also more of a concept than an actual plan, kind of thinking out loud as it where.
Paul,
Breaking out a mesh into 2 layers, one for transport and one for user access can help a lot.
You still have the hidden node issues and air interface contention though and you are also moving away from really cheap commodity hardware.
Still it scales better than an ‘everything on one channel network’ whilst keeping the resilience that mesh brings.
However at this point it’s not that much more work to move to routed Point to point rings for transit, with proper RF planning you get a lot more throughput and dynamic protocols such as OSPF can route around failures, Although to do not deal so well with ‘flappy’ or degraded links. Network monitoring and proper RF engineering is important for reliability.
For Urban communities why not use Cable/DSL as the back-haul for the network and avoid (most of? ) the RF point to point links?
In this scenario each Access node connected via a VPN to to the router or server that sits on a decent connection (perhaps a Virtual machine in a data-centre) that manages what users have access to, takes care of access control, accounting, logging and monitoring.
Point to Multi-point is kinda messy at best on 802.11 but Mikrotik’s ‘NV2’ mode and Ubiquiti’s AirMAX bring TDMA to the picture and improve matters to an extent, at the expense of being proprietary
My own background here is as the CTO of a Wireless Internet provider covering a large rural area with several thousand customers.
We Use a mix of Licence exempt kit at 5GHz and Licensed 802.16d Wimax on 3.5Ghz along with Licensed Point to Point links on the busier backbone routes.
Brendan, The idea of using cable/DSL has been discussed. Most people around here have cable, some are using 3/4g mobile networks tethering.
However, about 1 1/2 years ago, the area that I lived in flooded during a big storm, including the TELCO office. Everyone lost dial tone and DSL. Cable was spotty because the power was out and or lines were down. Cell sites were also off line because of wind damage and/or the wires were down and the connection between the mobile network and wired network was lost. I was thinking along the lines of something to be used in those situations where most other communications were out. Additionally, using that network to feed a series of low power FM transmitters used to disseminate emergency information.
I have used the Ubiquiti AirMAX equipment and ADTRAN tracers. They work remarkably well and are not too expensive, at least the Ubiquiti gear isn’t.
Nothing is worse than a flapping link. Well, fire is worse than a flapping link, but not much else.
Hey Gary, my math professor this semester was Vern Piantanida, brother of Nick Piantanida.
Holy crap! I hope his luck as a math professor was better than his brother’s luck attempting to jump from a very high gondola.
Well, he seemed to know what he was doing, I got an A in the course 😉
Paul,
This might be of interest and is somewhat pertinent to this thread
http://disastertechlab.org/2012/12/28/superstorm-sandy-wireless-communications-assesment/
Brendan, that is an interesting site, I will now have to spend several hours reading through it.
Thanks for putting the link up here Brendan.
Good post and follow-up discussion. We use mesh for our deployments in disaster areas for a lot of the above reasons.
Self-forming and self-healing are essential in the kind of environments that we work in where node integrity is a rare occasions. Frequent power outages, structural instability and sometimes theft you don’t want to ahve to do a track-roll every time a node goes down.
Mesh allows us to quickly roll out an IP-based network with an acceptable service level. Brendan is correct that you need to split it up in at least two layers, user and transport, and hence we always use equipment with at least 2 radios. Mesh nodes with 1 radio just don’t work, no matter what some manufacturers try to tell you.
For larger areas (such as our current network in the Rockaways, NYC) we use a mesh network backbone and then build a local client mesh out from each node.
Using the right equipment and configurations that works quite well.