MeshNet wireless

Mesh Net


Originally written Thursday, February 20, 2003

By Peter Gransee

The purpose for posting this paper is not to toot my own horn or claim that I originated everything here. Most of the ideas here are not new and I already see the WI-FI community moving in this direction. Being a gadget lover and heavy Internet user, the purpose of the paper is draw attention to these trends and hopefully speed their complete implementation (so I can enjoy them on my laptop!). I see several different projects addressing parts of this idea but I am worried that standards will be created and implemented without including some important features and then it will be too late. I believe this idea has pretty cool potential and would hate to see it crippled by a short sighted manufacturer or standards body.


The basic idea of Mesh Networks originated with the US Military. This paper is about using the idea in a civilian network. A mesh network is a collection of radio transceivers that relay data to each other, forming an unbroken chain of radios that extends the range of each individual radio.


For a WiFi based Mesh network, there are two stages of implementation. The first stage works with existing WiFi hardware and the second stage requires improved hardware. The first stage sets up the network and the second stage adds new features.


Mesh Net promises broadband connections to any location in large population centers. Bandwidth can easily exceed that available through standard wired connections. In addition, new features that are not provided by wired connections are possible with a Mesh network connection.




Over the years, I have flip-flopped several times on the issue of wireless versus wired connections. Until recently, I felt that wireless was not suitable for most home and corporate Internet connections because of the limited bandwidth. Wireless was relegated primarily to applications that required mobility. But now I am leaning back towards wireless as a primary connection for fixed locations as well.


I now feel that Mesh Networks are the #1, “next big thing”.  It won’t replace the wired Internet completely but it certainly has the capacity to supplement large sections of it.


The reason for this is an interesting relationship between output power and bandwidth made possible by mesh networks. As the power level is reduced, more nodes can use the same frequencies in a given geographic area. This has the effect of increasing the practical bandwidth for a given area. Mesh networks allow intelligence and critical mass to reduce the need for output power to cover the distance between the client and the gateway. Over time, the cost per bit of information would dramatically be reduced.


Mesh networks have the potential to overcome the “last mile” problem for home and business Internet access.


Mesh networks also allow new types of packet handling that is not offered on the Internet. This would open up new applications while improving other applications.


Mesh networks have the capability of providing 11-70mb/s access very quickly to most cities. Future upgrades to the system could provide upwards of several hundred mb/s which would tremendously exceed current and projected wired system offerings in bandwidth and features.


Eventually, the mesh network density in a typical metropolitan area could reach a point where output power is several times less than today’s wi-fi systems while the bandwidth is several times more.


Some of the difficulties these systems face are compatibility (standards), security and latency.


Latency comes from the increased amount of hardware hops required to traverse a typical path compared to wired systems. Current mesh networks ideas are based on a “store and forward” system with each node adding several milliseconds of delay to relay the packet.


The idea for a Router-less Internet can be applied in this situation. For a packet to traverse a series of nodes, a virtual path is established and data is relayed at the bit level. This allows for the reconditioning of the signal while keeping latency to a minimum. There is a delay while the connection is setup but then payload latency is reduced. The packet header overhead is reduced dramatically, which also reduces latency. Unlike ATM which uses a fixed packet size and even more packet overhead than typical standards, this protocol would use variable pipe width, no headers and adaptive prioritization.


Also, each packet is not acknowledged by the far application. Housekeeping Traffic is only generated when the link is lost. If a node fails, the packet is resent by the previous node and not by the sending application. These methods contribute to lowering network traffic and latency.


This improvement would likely require new firmware for the radios.


With these improvements, typical latency from wireless client to a gateway 25 hops away would be less than 20ms. If the gateway was a DSL or other dedicated connection, the typical latency would be less than a cable or modem connection.


Another improvement I would like to see added to mesh network is the ability to use other types of wireless links including UWB and higher power radios.


Several protocols are required to make mesh networks work in the basic sense.


One is the routing protocol that automatically finds the best path to a particular destination (gateway, another client, content server or broadcast). Each node would store a single byte for each destination indicating how many hops it is from a gateway or server. A new server or gateway would broadcast its location starting with the closest node and relaying outwards. This would setup up a location byte for each surrounding node. Each node would have several gateways stored. Other information about the gateway such as its unique ID, type and health would also be stored at each node.


Traffic would be routed from node to node by relaying to nodes with the lowest hop number. If that connection was poor, the second lowest hop number would be used. Routes can be reconfigured on the fly making the system resistant to dropped/congested nodes.


Load sharing

This allows one client to draw upon several sources of the same content in order to increase bandwidth. It also adapts to network loading and congestion situations. For example, three 500kps gateways could be bonded together to provide a 1.5mbps connection to the Internet. Load sharing logic would take into consideration bandwidth, priority level, type of node and latency.


Packet Prioritization

This improves the performance of latency sensitive applications and also provides a mechanism for emergency services to work during high congestion conditions (like during a large disaster). Each packet is assigned a priority level by the application and successive nodes have the ability to downgrade that status based on network conditions. Applications would be aware of the available connection and compensate (by negotiating a lower audio bit-rate or recommending SMS for example).



Broadcast is useful for applications like radio, TV, software updates, weather, time sync, etc. Each stream must be requested by at least one node per area for a broadcast to propagate to that node’s neighborhood. Broadcast packets have a different type of route that allows multiple clients to receive the stream. This protocol is much more efficient for the network and the broadcast server compared to traditional TCP/IP.  For example, if 30 IP TVs are requesting the same stream, only one stream is sent along the major routes. This would reduce the traffic for those common routes by 1/30th. It would also reduce loading on the server so it could handle an unlimited number of receivers.


To broadcast a local concert via the Internet would typically require 128kps for each client (stereo, MP3 quality). With 1000 clients listening to the stream, the required bandwidth at the server would be 128,000kps or 128mb/s! But with broadcast protocols over MeshNet, the required bandwidth at the server would only be 128kps.


Power level adjust

This protocol optimizes the efficiency of the network by reducing the power level of the radio when possible. The user may also specify if their client is a line powered or battery powered node. Line powered nodes would be preferred for relaying traffic. This preference is part of the Mesh Net protocol.


New hardware should have the ability to output even more power than the current WI-FI standard. This would require FCC approval. This higher output would only be used when necessarily to bridge neighborhoods, fill in voids, etc. I am thinking 4x power output would be a good level. This would double the range in most applications. Most radios should have this capability instead of only specialized radios since the network topology must remain flexible.


Auto Setup

The Mesh Network provides updated information at default locations so that new nodes can be automatically configured and software updated as the network evolves. Nearby nodes would help new nodes get on to network enough (bios) to establish a connection for a full software update. This limits, “chicken and the egg” limiters.


Self Healing

Adapts to network and radio problems and automatically black lists problem nodes and routes around them. Hive intelligence allows the network to survive some jamming, rogue nodes, radio problems, interference, ping floods, etc. One example of network adaptation is for the destination address to pass a refuse flag back along the network to the sender so that none of the nodes will pass the traffic. No node would receive traffic is had not specifically requested. This protocol would reduce the effect of DNS attacks. Each node shares the responsibility of transmission with the 2 previous nodes to carry the bit. If the next node disappears or fails to acknowledge link, the previous node retransmits from RAM. If the next node still continues to not respond, another route it found. If an entire train of nodes is rendered impotent, then the application finds a new route and resends the packet. Routing is done by the simple and robust single byte hop number method.


Virtual Bandwidth for burst conditions.

In the event that a particular node’s bandwidth is exceeded, the node one step up the chain will store the packet in local memory until a free path can be found. During peak network utilization times, the entire network cloud could accept and store several times more data than it can transmit in a given time. This would enable the network to survive brief overloads with minimal effect to applications.


Each node requires a small amount of RAM for use by the radio. This RAM is built into the radio and is not part of the host computer. I think 8k would be plenty. This ram is used for storing routes, node information, burst storage, etc.


Bandwidth multipliers.

With new radio systems, another improvement possible is the ability to bond multiple receivers together to increase bandwidth. A similar device with multiple radios is a 12-channel GPS. For example, the 2.4ghz band has 11 channels set aside for Wi-Fi. In most areas, only 1 channel is being used at any given point in time.  A next generation radio could have 11 receivers and 5 transmitters. When conditions permitted, multiple channels would be used simultaneously to increase the upload/download bandwidth. If each channel is 11mps, then 11 channels would provide a maximum bandwidth of 121mps. Typical setups would have more receivers than transmitters since typical internet usage is download intensive. Multiple transmitters would increase power consumption but the large file, etc would also take less time to transmit. Multiple receivers would consume less power than multiple transmitters but still provide a benefit since surrounding nodes could load share through multiple nodes/channels to the one client.


If WI-FI Mesh Networks become the force I hope they do, then lobbying the FCC for more channels and output power will be facilitated. This could very well happen if Mesh Net becomes essential to the economy.


Supply and Demand equalization.

Someone might ask, “if mesh network is in my neighborhood, why not just cancel my DSL subscription? And if I do, what would keep everyone else from doing the same? Soon, no one would be sharing their Internet connection anymore!” My answer is supply and demand. If too many people are using and not enough are providing, then people will buy their own internet connection. Over time, this causes a balancing effect. A third effect is the eventual transition of desired content to a Mesh Net located server.


Distance/Bandwidth relationship

Odd as it may sound, one of the strengths of the Mesh network is in the short range of the radios used. For long hauls between cities, conventional wired connections (fiber optics, etc) are desired. Using single wireless connections to bridge long distances is not very efficient compared to fiber optics.



Aside from the cost of the WI-FI card and the electricity to power it, what other costs are there? Most gateways would charge a subscription charge (mostly through billing aggregators) for access to the Internet. This would offset the higher costs that wired ISPs would likely want to charge. Relays could also charge micro payments as well. Central aggregators would handle billing of users and make sure everyone gets paid. In large cities, dedicated commercial gateways could become a viable business opportunity.



This is a next generation TCP/IP protocol that never really took off because of the whole chicken and the egg phenomena. If it where ever implemented, it would offer some real advantages to the Internet such as more IP addresses, packet prioritization, broadcast protocol and increased security. Since Mesh Net is still in its formative phase, some of these new protocols could be built-in from the ground level. This would provide further advantages to a Mesh network connection over a traditional wired Internet connection.


Service Reliability

As long as you have at least one connection to the Mesh network, certain service guarantees could be made. Unlike traditional WI-FI, packet loss would be zero because each packet would be guaranteed delivery. Acks would verifiy link integrity and reroute in the event that link integrity is lost. Reroutes would not loose data because the stream would be buffered back several nodes and also by the sending application. Latency and delays would be minimized by load sharing logic.



On the Internet, nodes are identified by an IP address. On the Mesh Net, this will need to be supplemented. Each node would have a hard wired ID (MAC address) and possibly an IP address as well (but not required). Finding a distant node would be accomplished by querying a DNS server for the current location of that node. That location would be specified as a route across nodes and through gateways. Each time a node was activated, it would integrate itself with the surrounding nodes. If it also was a source of useful information, it could broadcast it’s location to the DNS system. Otherwise, its location would be unknown. This provides a mix of anonymous clients with easily located servers.


Geographic locating

The current geographic location of a node could be determined by using the existing equipment. This information could be used as a supplement to other navigational systems like GPS. Nodes have room in their flash for storing the physical location (if known) and weather or not they are typically a fixed or moving node. If a fixed node knows it’s street address, for example, then a location server can calculate it’s approximate Long/Lat coordinates. Some nodes would even have their exact coordinates programmed (if say their owner was tech savvy). Some nodes would have no programmed information on their location. Those nodes would estimate their location by comparing themselves to nodes that do know their location.


Location would be determined by timing the signals from three other nodes and triangulating the results. Even if only one other node could be seen, the querying node could still tell it’s location to within a mile or two by the simple fact that is has to be that close to the node in order to link with it. If neither node knows where it is then accuracy degrades to the first node that does. Clusters of nodes can improve their accuracy by triangulating off of each other.


In a worse case scenario, your laptop could only tell you that you were in a particular state and country. Best case, it could tell where you are in the state to a couple hundred feet. Even the worst case information is useful as this could be used by other applications to set your time zone, calling prefix, region code, etc. Advantages over GPS would include not requiring an extra radio, ability to work inside of buildings, etc. Of course, for best accuracy, a GPS is recommended.


Example Applications.


-          Linux Cell Phone. Mesh Net relay, IP telephony, longer battery life than conventional cell phones, very cheap air time, navigation information, accurate clock, internet applications, ability to work in emergency conditions that would normal cell phones would not survive (extreme network congestion), walky talky mode, IP radio (uses broadcast packet protocol)

-          Watch. Automatic time sync, email notify, auto time zone set, software compass/speedometer/navaid, low power relay (make money relaying other people’s traffic while sitting in a subway train)

-          Automotive. IP radio, traffic alerts, naviad, vehicle tracker/locator, silent alarm (to cell phone), use watch/cell phone to unlock and start, health report to shop, relay with excellent antenna, etc

-          Emergency services radio. Walk talky, guaranteed level of service during disaster levels. Very long battery life, location of each radio sent back to HQ


IP telephony

The Mesh Net would be ideal for telephony because of the packet prioritization, network durability, low power consumption, etc. Each phone would broadcast it’s location to a DNS server if it wanted to receive calls. Otherwise it could only make calls. Calls would be routed directly between clients and would not require a central server other than for locating the other party. The routing protocol would use different routes for high priority traffic to minimize latency whereas low priority packets would take routes that maximized bandwidth.



The location of each node is not readily known to the network unless that node broadcasts its location to a DNS server. It location could still be determined by actively searching for it, but it would take awhile. Of course, the node could simply be shut off after send/receive and it would not show up in an active search.


Data between nodes is encrypted by 128-bit crypto or better. Not just the initial connection, but all the data is encrypted.  Since packets are header-less (virtual routing), eavesdropping mid-stream would not provide the sender or server address.


One of the biggest improvements to security would be to change the default configuration of the equipment to make it more secure until the user figures out how to use the equipment. Default Admin passwords should be unique to each machine (use the serial number for example).


Ease of use.

A newly purchased piece of network hardware should by default automatically integrate into the local Mesh Net as soon as power is applied. In its minimal configuration, it would function as a free relay. If installed in a computer, windows should treat it as a network card with DHCP configured. If no other network device is installed, that computer should be able to access the Internet upon boot up without requiring any input from the user (other than installing the hardware and inserting the drivers CD).




Because this system allows users to communicate with each other without requiring a service provider, most connections are significantly free of any central authority.


AP Hardware

What will happen to “Access Point” hardware? APs are obsolete. They will be replaced by peer to peer hardware. Home access routers (for DSL/Cable) with wireless nodes are still a possibility.



Many laptops now include wi-fi connectivity built in. The problem is that the wi-fi is disabled whenever the laptop boots or connects to a network. The idea is to limit security problems. If a wi-fi enabled laptop were connected to a corporate LAN for example, the company would be at risk from that laptop. There might be a way to disable this feature so the mesh network node is activated whenever the laptop is turned on but it is kept secure.



Eventually, a large percentage of the content desired by a typical user could be found on a mesh network server. In such a case, the value of a traditional Internet connection is lessened for that user. This would put fewer loads on the gateways and also lower the costs to access that type of content.


Internet in some remote areas

For example, camp ground with a highway a mile away. Cars traveling along the highway form a delayed link back to civilization. Wherever there are roads with at least several cars driving by per day, a store and forward link is possible. The remote node would have to petition each passing node, which would eventually get sent up to the desired content server. Then new nodes approaching the remote area would be given the reply to store in hopes that they will meet up with the remote. This would be slow, but could transceive short messages. Another possibility is to place repeaters on passenger planes. Not only could they service the passengers, but the 5,000 or so planes that currently airborne over the country are each cutting swaths across remote areas throughout the day. How many times camping have you seen a passenger airliner traveling high over head? Enough for simple messages or emergency transmissions.



Surprised that meshnet is not more popular. Tried out a new app called firechat but it is very basic. Even so, I see it is helping with the democratic movement in China. Not surprising this would be useful for freedom. I suspect it will continue to improve.

Was cool to see meshnet used in season 4 of Person of Interest. Also noticed the Ham network Hamnet

Multi-hop and store and forward protocols are important to increasing the reach of the network. Also make the connections more modular so that each user can deploy their own encryption and pass all types of traffic (http, ftp, etc). This would allow web servers to exist on the network for example.

Meshnet can learn from the mistakes of TCP/IP and make the user more anonymous. Don't use mac or IP addresses. Don't use centralized routing. A node is only visible if it informs a private or public DNS of its location and that location is stored as a series of hop lengths to known nodes. As soon as the node moves, the hop lengths must be updated if it continues to want to receive traffic.

Simply searching a cluster of nodes will give you the current hop map but that map is constantly changing and it does not further identify the nodes (no ip or mac). Also, even when the nodes are fixed, different hop routes can be used to get to the same destination. Further, a particular hop map may actually lead to multiple destinations but only one knows what to do with the packet. The network could provide a certain percentage of these further obsuficated connections depending on load. This decision is made by each node and expressed by the number of hops is chooses to store.

I was thinking of ATM when I thought of connections based on channels that are temporarily setup instead of IP to IP connections. I also compared this to how an ant or bee hive is organized. Emergent structure, etc. Some of this was part of an earlier project I did called Hiveweb.

A node that wishes to be anonymous could contact a known node and securely request new messages using the virtual channel. As soon as the channel is destroyed, the network no longer has a memory of the channel. Of course, the known node would be responsible for securing the request but that could use private encryption.

A full network has different types of links. Some are direct via various frequencies (WiFi, Bluetooth, Ham, etc), some by public networks (cellular, public WiFi, etc) some by wired connections (old style internet cable, fiber, POTs), sneaker net and store and forward (for intermittent links). 

With radios that allow more control of the basic protocols, mesh could host virtual antenna protocols. This is where a group of radios work together to form a larger, temporally fixed or more focused antenna. This could allow less power output, more bandwidth, location, connections with fast moving nodes and increased range. 

Virtual arrays could be used to make connections from fast moving clusters. Say a group of cars on the freeway connecting to a node along the road. The first radio might be in range long enough to send a packet, the next to receive a packet, etc. So even though each radio is in range of the fixed node only for a split second, the radios are connected to each other for minutes, which allows them to function as a single radio. This would allow a small but vital amount of bandwidth to be passed in even these conditions. 

Of course, in the above scenario, the cars (or phones in the cars) connecting to each other also have value among themselves for sharing road conditions, accidents, negotiated self driving, etc (smart highway).

A virtual antenna can also be a kind of VLA/phase array RADAR. Each radio would grab a time slot and then compare those time slots with their nearby neighbor and calculate for a desired phase. This improves the S/N in a particular direction to boost a distant node. This could also provide a limited amount of jamming resistance by vectoring around the jammer. 

Another way to increase range is by precisely time stamping the packets (GPS) and re-transmitting them repeatedly like the Ham protocol WSPR. This causes a frame stacking effect like what is used in astronomy. The power consumption per packet goes up and link/local bandwidth is reduced. Of course, this would require more basic access to the radio firmware and possibly changes to the rules but range could be increased 2-3x, which may be all that is needed to bridge gaps. With mesh, even a small bump in range, tactically used, can greatly grow the network.

virtual arrays can also take advantage of stacking when the nodes form a line to the target node. 

even when the network is in its infancy, I can see a family of 4, each with a next gen smart phone with mesh using very little power to link with each other and forming an array to connect to a distant node or conventional connection which is shared. Each host could also use the security of this network for file sharing, chat, location, sensor aggregation, etc. 

or another example would be a crowd of demonstrators who load an app that works with a legacy cell phone but includes many of the mesh features. 

other protocols and applications include radar (tell when a car is in your driveway, someone near the front door), node location (find lost stuff, family members, yourself), open source router firmware that supports mesh, internet of things, spectrum analyzer, radio astronomy (providing a bigger VLA), distributed computing (share host resources), crowd games (at a concert- light show using display or camera LED, audio effect using speaker, virtual camera), etc.

standardizing user agreement for public wifi, gateway nodes that you agree to once and don't have to keep reading and clicking each time you connect to a new or previous AP. Just add that company to list.

5ghz radio on chip that uses SDR to reduce cost and provide more adaptability. The radio also includes a small amount of flash for firmware and store/forward, ram for operations and a basic CPU. This is all in a sandbox that protects the host. Some of the more advanced functions would utilize the host through secure protocols. SDR would allow multiple virtual radios to look at different parts of the band at the same time. The system also needs to be able to digitize from multiple antennas in the same device. This may require multiple RF sections sharing the same digital section?

to incentavize the casual user to buy a router with mesh, they may be attracted by an improved user interface, smart phone dashboard, remote control, back up bandwidth, bitcoin for sharing, smart phone bandwidth credits for use when away from the house, more range, radar for their home, etc. Applications with sizzle. 

I think bitcoin is the micropayment system we have been looking for to make certain types of services become more popular. for example, sharing your internet connection, hosting content, etc. 

The smart phone of the near future could have mesh as its primary link with 4G/LTE(whatever) as its backup (3G takes less space in the phone and its for backup only so LTE (etc) may not be needed). The 2.4/5ghz SDR could even send short messages by satellite for wilderness use. Users will always want better coverage, more bandwidth and longer battery life. Mesh can do this. No need for the austerity sometimes found with "cord cutting". Because mesh takes priority over cellular, the mesh radios would get better antennas in the space constrained smart phone. 

I expect this will lower bandwidth costs which will also slow the rate of new cellular tower construction. Eventually these centralized towers will become obsolete along with the web and maybe even the internet as we know it. The idea of paying $60/month for a plan is going the way of the dodo. Hopefully the idea that we are the product will also diminish as bandwidth and software costs continue to drop and micropayments become easier to use. 

I imagine what is known as WiFi will gain new frequencies and more capabilities as it becomes more utilized. Or maybe there will be a collection of no-license public frequencies including WiFi. 

With improved voice pattern recognition, the traditional phone call will use less bandwidth become more latency resistant, clear, brief and ah... busy. :) Busy as in looking more like text chat interspersed with bots and various media. Basically a rich conversation with less busy work but not necessarily any more intelligent.

just for fun..

advanced smart phone

- 12 core (mixed for power/power) CPU with FPGA section also for low power 

- 128gb flash

- end to end crypto with more crypto added for good measure

- local/distant cloud based emulators of various operating systems for legacy apps to fight lock-in

- latest battery tech (they are slowing getting better. but still only last a day)

- somewhat flexible housing (water, drop, dust, scratch, etc already becoming standard)

- AMOLED screen or transflective (better in sunlight) LCD with local dimming (Pixel Qi?)

- 5ghz SDR (with front ends and antennas from 800mhz to 5ghz). optimized for mesh but includes cellular backup, GPS, FM radio, NFC, DBS whitespace, etc. 

- more cameras (fly's eye? produce similar images to a big sensor with a lot of glass)

- always on microphone array (low power front end makes this possible)

- Modular bay is international standard compliant for aftermarket modules including multiple sensors, emitters, specialty connectors, applications for makers/medical (telemedicine and do it yourself)/games/etc. continues water resistance with surrounding phone. 

- VOIP is baked in with dedicated DSP (use FPGA?) so it works better (phoneme prediction, echo cancel, etc) and uses less power. Also helps with voice recognition. talk time on wifi is nice. able to handle more hops in mesh as well. 

cost: what you expect

service plan: no contract, $3-6/month depending on your mobility (you can buy 1gb of non-expiring sprint cell bandwidth from Karma for $14. if you use even dumb wifi and your total consumption is 3gb/month, that usually works out to less than 100mb of 3g or $1.40 a month currently but figure consumption will continue to rise for the average person and of course inflation so $3-6/month seems like a safe figure. I figure people want to download a bunch of 4k video in the most remote of places they can imagine (but usually somewhere in the city) and prices for even a little bit of cellular will continue to skyrocket.