John Cox, who writes a great column at Network World, asks the question that seems to be on everyone’s mind lately; “are two radios better than one for mesh?”
Those benefits [of mesh] are persuading a variety of customers to adopt mesh topologies: police and fire departments; campuses; construction companies; utilities; and, increasingly, local governments for business and residential Internet access.
Cisco is throwing the Aironet 1500 into a highly competitive and lucrative market. So far, a pack of upstarts, including BelAir, Firetide, Strix and Tropos Networks, and one established vendor, Nortel, have had the market to themselves, offering an array of architectures and technologies. Other companies such as Motorola, which acquired MeshNetworks, offer proprietary wireless mesh products.
The 1500 makes Cisco a major player in this market.
“It appears to be a very competitive product,” says Craig Mathias, principal with Farpoint Group, a wireless consulting company. “And it does have ‘Cisco’ on the front label.”
But there is very little that’s standard in mesh products.
“There are so many differences in products and approaches,” Mathias says. “The secret sauce is the mesh-routing protocol. And everyone implements them differently. Under what conditions do you hop [from one node to another], and to which nodes? How do you actually route packets through the mesh? All these are answered differently.”
Some products, notably from Tropos, use a single radio to handle client and backhaul connections. Cisco and others use separate radios for each connection. Some vendors will use two or more radios for both tasks. “Should you use multiple radios or not? And if yes, how many?” Mathias asks. “No one to my knowledge has done comprehensive tests of these products . . . to give us comprehensive benchmarks.”
The department of electrical engineering and computer sciences at the University of California at Berkeley is a beta site for the Aironet 1500. The department has 10 nodes deployed around the university’s campus, which has hundreds of buildings.
This deployment proved an unexpected challenge, says network manager Fred Archibald. Access points are designed for mounting on the horizontal arms of municipal light poles. But few of these were on campus. “We mounted them on roofs, about 70 to 90 feet above the ground,” Archibald says. “We had to use specialized directional antennas to get the signal back down to the ground.”
The 1500 nodes are divided into groups, each of which is assigned its own radio channel, optimizing throughput for users and nodes in each group. But that means fewer routing options for the nodes in each group in case of outages or interference, Archibald says. “The mesh is not as flexible in reconfiguring itself,” he says. “Cisco has told me they will get better in this in the future.”
Troubleshooting is more complicated in a mesh. “The route [for a client's packets] is more complex, and it’s constantly changing,” he says. One major upgrade during the beta test was the introduction of a GUI for the network-monitoring software. The display can now show a network administrator the path that a client packet has taken through a mesh.
Source: Network World
| Vendor | Product | Radios for client access | Radios for backhaul | Ethernet ports |
itarchitectmag.com explains:
It’s possible to provide high-quality coverage using single-radio systems, but only if the mesh is architected so that each node is within a hop or two of an uplink to the Internet.
For example, the city of Chaska, MN, uses 230 Tropos nodes to cover a 16-square-mile area. The network is very successful: It allows the city to offer all its residents mobile Internet access at DSL speeds for $16 per month and is set to pay for itself within three years at current subscriber levels. However, because the Tropos APs contain only a single radio, the network needs 36 uplinks at T1 speeds distributed throughout the city.
In contrast, the city of Tempe, AZ, uses about 400 Strix nodes to cover a 40-square-mile area. The network is able to get by with only seven T3 lines because the Strix nodes all have at least two radios. This means additional hops don’t significantly increase latency or reduce bandwidth. Packets take less than 40ms to travel 10 hops–a delay too short for human listeners to notice even when the network is used for VoIP.
Compared to the existing products, the IEEE’s aims with 802.11s seem rather modest, targeting meshes of only 32 APs. Its ETA is similarly unambitious: The official timeline says the final specification will be published in July 2008. Even when standards are finalized, it takes at least another six months for the Wi-Fi Alliance to check that different vendors’ products actually work together.
Digitimes interviews Ted Kuo, of Accton Technology about the state of mesh “standards”.
Q: How would you characterize wireless mesh in terms of technology, protocols and so on?
A: A mesh network is a well known and robust form of topology. It refers to a state where every node on the network is interconnected. With cabled networks, of course, the deployment of a fully meshed topology may be cost-prohibitive. But with the introduction of wireless networking, mesh networks can be achieved in a very cost-effective way. A wireless-mesh network is sometimes referred to as a multi-hop ad hoc wireless network.
Currently, the IEEE 802.11 standard defines two operating modes, the infrastructure and ad hoc modes. The infrastructure mode requires the presence of an AP to function, but the ad hoc mode only requires the network participants to have direct wireless connectivity with each other (to “see” each other), so that an AP is not required. However, the 802.11 standard does not define how wireless devices should interact to relay traffic within a wireless distributed system where not all the ad hoc network participants have direct connectivity. The purpose of the IEEE 802.11s ESS Mesh Networking Task Group is to address the needs of such an application.
The 802.11s Task Group was formed in July 2004, to define a standard according to which wireless devices could form a dynamic wireless-mesh network. A wireless-mesh network could then be used to connect all the wireless devices within the network to provide data-transport services.
Although 802.11s is still in its early days, three major functional roles have been defined: mesh point, mesh AP, and mesh portal.
A mesh point is capable of detecting its neighboring mesh nodes, establishing links with its neighbors and relaying traffic.
A mesh AP is a mesh point with a standard 802.11 AP capability to receive and process local station traffic.
A mesh portal is a mesh point that sits between a wireless-mesh network and an outside network, such as an Ethernet network, with some defined border functionality.
Q: What special features and functionality would be required by a mesh point?
A: The detailed functions of a mesh point have not yet been fully agreed. However, there seems to be a general consensus that a mesh point should be capable of the following functions. First, it needs to be able to do neighbor discovery and neighbor authentication. It also has to be able to receive frames sent by its neighbors and forward frames along selected paths according to some minimal-cost path-selection mechanism. And, finally, it needs to have the capability to maintain links in the event of interference and failure.
Q: Is the final standard likely to require bridging or routing, or both?
A: Most likely a wireless mesh network would require one or the other, but not both. Most of the 802.11s proposals submitted for the July 2005 IEEE meeting seemed to prefer using routing. There was only one proposal based on a spanning-tree protocol.
In addition to this path-selection issue, you also have a link-maintenance issue. You have to constantly monitor the link status, to find out if there has been any change in the mesh topology.
These are the basic functions you would need to have in a mesh point. There are other issues, but these will become clearer after the first few rounds of discussion in coming 802.11s meetings.
Q: Can you outline some of these additional issues?
A: Security and QoS are other important issues that quickly come to mind. The current 802.11 standard only defines security and QoS mechanisms between a station and an AP. Security among neighboring mesh points and end-to-end QoS between an ingress and an egress mesh point within a wireless mesh network are also to be addressed in 802.11s. Most likely 802.11i and 802.11e will be implemented where applicable.
Of course if you really wanted to know how these systems work in the real world, you could call up the cities of Lebanon, Oregon (using Cisco 1500), Athens, Georgia (using Belair), Tempe Arizona (using Strix), Saint Cloud FL and Philly (using Tropos), Culver City, California (using Firetide), Medford, Oregon (using MeshNetworks), Cupertino (using SkyPilot gear), and Taipei (using Nortel).
Related DailyWireless articles include; Unwired Portland Gets 6 Proposals, Mesh Standards?, Cisco Gets Meshed, Macedonia Unwired, Tempe’s Cloud, Mesh Standards, Taipei’s Mesh Cloud, Scaling City-wide Mesh, NASA/Nortel Mesh Shuttle Coverage, Securing the Cloud, Hotels Get Meshed, Mesh Projects & Gear, MetroFi Goes Long, Mesh: Baton Rouge Et Al Citywide Mesh, Mesh Goes Downtown, Aiirnet & Telerama, Strix and Air Magnet, San Jose Free Cloud, Meshing at Intel, Meshed Roofnets, Mesh ISP, and City Mesh and Intel’s 802.11s for Home Mesh.
.gif)
