Design Article

IMG1

Multi-Radio Meshes Best for City Wi-Fi

Francis da Costa and Sriram Dyanandan, MeshDynamics

3/28/2005 3:50 AM EST

For city-wide Wi-Fi deployments, greater performance and scalability is achieved by discarding the ad hoc military mesh paradigm where all nodes have one mesh radio, and all mesh radios are on the same channel. The use of a multi-radio, multi-channel relay architecture is by far the most effective means of providing the performance required for VoIP and data coverage.

Mesh networking, as a concept and technology, was developed for the military so that nodes could come together on the battlefield, communicate, and then disperse. The focus was temporary peer-to-peer connectivity on an impromptu, ad hoc basis, in contrast to today's city-wide mesh where most paths lead to the Internet.

This approach resulted in a paradigm that is still used by the majority of mesh suppliers today: All radios participating in the mesh are on the same channel (frequency), and for each node only one radio participates in the mesh. Thus, any node can communicate with any other nodes as long as they are within range of each other.

This approach has two drawbacks that cause performance degradation as packets travel more hops, and as more clients request service from each node--the one-radio effect and the involuntary bandwidth sharing effect. Both of these effects can be mitigated by a move to a multi-radio, multi-channel approach.

The radios in a mesh network must perform two functions. They must provide service to their clients and they must provide a path to the wired network in a relay fashion through the mesh. The provision of this path to the wired network is referred to as the backhaul or relay path. In traditional meshes, a single radio provides both of these services. In other cases, more than one radio is used for the relay function (Figure 1).


Figure 1: Three competing mesh architectures (L-R): One-radio, 1+1 and multi-radio meshed backhaul.

With just one radio devoted to the relay function, a mesh node cannot send and receive packets and the same time. When looked at from the perspective of a single node, this will reduce the bandwidth through that node by 50 percent. After four hops, a user would be left with one-sixteenth of the bandwidth. Thus, bandwidth in single-radio meshes can be expressed as 1/(2N) where N equals the number of hops.

Conventional mesh providers concede that their products suffer from bandwidth degradation with each hop. However, some claim that if the hops between mesh nodes are large enough in distance, there could be simultaneous conversations along a path through the mesh and that bandwidth degradation is closer to 1/N than 1/2N. This is not the case, however, since in a modern city-wide mesh the vast majority of packet transfers require connection to the Internet.

An independent study indicates a degradation of 1/(1.68)n for typical mesh topologies1. However, for the sake of this analysis, we shall use the more conservative 1/N scaling factor to minimize the controversy.

There are two primary alternatives to the one-radio mesh network. In a so-called 1+1 mesh each node contains two separate radios, one to provide service to the clients and one for backhaul. These two radios may operate in different bands. Typically a 2.4-GHz 802.11 b/g radio is used for service and a 5-GHz 802.11a radio is used for backhaul.

The 1+1 approach improves performance compared to a one-radio approach; however, it still suffers from the one-radio effect. Packets traveling toward the Internet share bandwidth at each hop along the backhaul path with traffic coming back from the Internet to clients.

A three-radio approach dynamically manages channels of all of the radios to keep them on non-interfering channels. In the three-radio configuration, two radios provide the relay functions and the other radio provides service to clients. With two backhaul radios, nodes can send and receive packets at the same time, thus eliminating the one-radio effect and related 1/N bandwidth and interference losses.

Bandwidth-Sharing Effect
Because 802.11 is a shared medium clients get a piece of a piece of the total available bandwidth. Thus conventional single radio meshes are severely limited beyond two or three hops for applications requiring either significant bandwidth or low latency.

In a 1+1 mesh, data enters the service radio and is transferred to the backhaul mesh through a bridge. Packets are then subject to contention with neighboring mesh radios because they operate on the same channel. How many neighboring nodes are in contention depends on the mesh topology.

In an urban mesh deployment where nodes typically are placed at road intersections, each node will contend with at least three other nodes as it attempts to relay packets. A 1+1 mesh used in such a deployment will only have a quarter of its potential bandwidth at peak times when a total of four nodes will be sharing the same channel.

A Comparative Analysis
We conducted a comparative analysis of one-, 1+1 and three-radio meshes. For each architecture, we compared the fraction of root node bandwidth available to a client (N) hops away where there are on average (C) clients per node demanding simultaneous access.

We ignored the effect of bandwidth sharing with some neighboring mesh nodes for the simple one-radio approach since it just makes already low performance numbers look lower. In addition, we used the 1/N per hop bandwidth degradation for the one-radio effect as opposed to the more realistic 1/2N number. In the case of the 1+1 mesh, we assumed four neighboring nodes as typical for an urban grid.

Our analysis showed that with five simultaneous clients per mesh node, both the one-radio and the 1+1 mesh cannot provide usable bandwidth beyond two or three hops in cases of realistic traffic. Specifically, the 1+1 mesh with a 54 Mbits/second 802.11a backhaul provides 42 Kbits/s of service to a client four hops away from the root. This is essentially equivalent to the bandwidth of a dial up network, barely usable for applications such as voice over IP.

Counting Costs
Obviously adding a radio or two to a mesh node adds some additional cost. All else being equal, each radio probably adds another $150 (radio + pigtail + antenna), to the BOM and $450 to the list price. That means an average node might cost $3,000 in a one-radio architecture, $3,450 in a 1+1 mesh, and $3,900 in a three-radio approach.

It should be noted that in a dense city-wide mesh where many high-rise buildings create the urban-canyon effect, you need to place a mesh node at each intersection to implement ubiquitous WiFi coverage. In addition, one-radio and 1+1 meshes need to be connected to an Internet feed or backhaul more often than does a three-radio mesh.

Backhaul connections can be implemented in many ways and their cost can vary from a few thousand dollars to tens of thousands. Let's arbitrarily assume it is $5,000 per feed and that in this case there are no monthly service charges per feed.

In this example, even with a cost per backhaul feed of only $5,000, the deployment cost is lower with a three-radio mesh. However, the real benefit of a three-radio system is shown when the bandwidth delivered is taken into effect. The three-radio mesh delivers $329/Kbyte/User. This is 5.5x better than the 1+1 solution and 8.5x better than traditional 1-radio mesh.

Most of the deployments of mesh today have been for police and fire departments setting up relatively small scale ad hoc networks in low traffic situations. One- and 1+1 radio approaches can work acceptably in such environments, but bandwidth falls off a cliff when the numbers of simultaneous users and resultant traffic increase. As service providers begin to deploy these kinds of meshes for metro-scale WiFi networks they are beginning to learn this lesson the hard way.

Reference
1. Gupta, Gray, and Kumar, "An Experimental Scaling Law for Ad Hoc Networks", http://black1.csl.uiuc.edu/~prkumar/html_files/publications.html.

About the Authors
Francis da Costa founder and CTO of MeshDynamics. Francis can be reached at fdacosta@meshdynamics.com.

Sriram Dyanandan is the chief software architect at MeshDynamics. Sriram can be reached at sriram@meshdynamics.com.


print

email

rss

Bookmark and Share

Joinpost comment




Please sign in to post comment

Navigate to related information

Product Parts Search

Enter part number or keyword
PartsSearch

FeedbackForm