Email Delivery

Receive new posts as email.

Email address

Syndicate this site

RSS | Atom

Contact

About This Site
Contact Us
Privacy Policy

Search


November 2010
Sun Mon Tues Wed Thurs Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        

Stories by Category

Basics :: Basics
Casting :: Casting Listen In Podcasts Videocasts
Culture :: Culture Hacking
Deals :: Deals
FAQ :: FAQ
Future :: Future
Hardware :: Hardware Adapters Appliances Chips Consumer Electronics Gaming Home Entertainment Music Photography Video Gadgets Mesh Monitoring and Testing PDAs Phones Smartphones
Industry :: Industry Conferences Financial Free Health Legal Research Vendor analysis
International :: International
Media :: Media Locally cached Streaming
Metro-Scale Networks :: Metro-Scale Networks Community Networking Municipal
Network Types :: Network Types Broadband Wireless Cellular 2.5G and 3G 4G Power Line Satellite
News :: News Mainstream Media
Politics :: Politics Regulation Sock Puppets
Schedules :: Schedules
Security :: Security 802.1X
Site Specific :: Site Specific Administrative Detail April Fool's Blogging Book review Cluelessness Guest Commentary History Humor Self-Promotion Unique Wee-Fi Who's Hot Today?
Software :: Software Open Source
Spectrum :: Spectrum 60 GHz
Standards :: Standards 802.11a 802.11ac 802.11ad 802.11e 802.11g 802.11n 802.20 Bluetooth MIMO UWB WiGig WiMAX ZigBee
Transportation and Lodging :: Transportation and Lodging Air Travel Aquatic Commuting Hotels Rails
Unclassified :: Unclassified
Vertical Markets :: Vertical Markets Academia Enterprise WLAN Switches Home Hot Spot Aggregators Hot Spot Advertising Road Warrior Roaming Libraries Location Medical Public Safety Residential Rural SOHO Small-Medium Sized Business Universities Utilities wISP
Voice :: Voice

Archives

November 2010 | October 2010 | September 2010 | August 2010 | July 2010 | June 2010 | May 2010 | April 2010 | March 2010 | February 2010 | January 2010 | December 2009 | November 2009 | October 2009 | September 2009 | August 2009 | July 2009 | June 2009 | May 2009 | April 2009 | March 2009 | February 2009 | January 2009 | December 2008 | November 2008 | October 2008 | September 2008 | August 2008 | July 2008 | June 2008 | May 2008 | April 2008 | March 2008 | February 2008 | January 2008 | December 2007 | November 2007 | October 2007 | September 2007 | August 2007 | July 2007 | June 2007 | May 2007 | April 2007 | March 2007 | February 2007 | January 2007 | December 2006 | November 2006 | October 2006 | September 2006 | August 2006 | July 2006 | June 2006 | May 2006 | April 2006 | March 2006 | February 2006 | January 2006 | December 2005 | November 2005 | October 2005 | September 2005 | August 2005 | July 2005 | June 2005 | May 2005 | April 2005 | March 2005 | February 2005 | January 2005 | December 2004 | November 2004 | October 2004 | September 2004 | August 2004 | July 2004 | June 2004 | May 2004 | April 2004 | March 2004 | February 2004 | January 2004 | December 2003 | November 2003 | October 2003 | September 2003 | August 2003 | July 2003 | June 2003 | May 2003 | April 2003 | March 2003 | February 2003 | January 2003 | December 2002 | November 2002 | October 2002 | September 2002 | August 2002 | July 2002 | June 2002 | May 2002 | April 2002 | March 2002 | February 2002 | January 2002 | December 2001 | November 2001 | October 2001 | September 2001 | August 2001 | July 2001 | June 2001 | May 2001 | April 2001 |

Recent Entries

In-Flight Wi-Fi and In-Flight Bombs
Can WPA Protect against Firesheep on Same Network?
Southwest Sets In-Flight Wi-Fi at $5
Eye-Fi Adds a View for Web Access
Firesheep Makes Sidejacking Easy
Wi-Fi Direct Certification Starts
Decaf on the Starbucks Digital Network
Google Did Snag Passwords
WiMax and LTE Not Technically 4G by ITU Standards
AT&T Wi-Fi Connections Keep High Growth with Free Service

Site Philosophy

This site operates as an independent editorial operation. Advertising, sponsorships, and other non-editorial materials represent the opinions and messages of their respective origins, and not of the site operator. Part of the FM Tech advertising network.

Copyright

Entire site and all contents except otherwise noted © Copyright 2001-2010 by Glenn Fleishman. Some images ©2006 Jupiterimages Corporation. All rights reserved. Please contact us for reprint rights. Linking is, of course, free and encouraged.

Powered by
Movable Type

« Who Are You Calling a Blimp? I'm a (Really) Low Orbit Satellite | Main | DSL Providers Offer Wi-Fi as Lure »

July 6, 2004

Do Mesh Networks Scale? Three Views

The head of a mesh company argues mesh networks don't scale -- and one of the folks behind an open-source mesh software project examines the argument: MeshDynamics sells a multiple-radio solution for mesh networking, and the head of the firm wrote a brief article explaining why single-radio mesh networks can't work beyond a very small deployment. I asked Sascha Meinrath of the CUWiN project for his feedback on Francis daCosta's comments.

(After this item was posted, Jim Thompson contributed his own extensive thoughts about both daCosta and Sascha's statements, hence the "third" view of the revised title.)

Sascha writes:

While I do think that Francis daCosta brings up some potential pitfalls to wireless mesh networks, the doomsday picture he presents is based on a flawed understanding of how mesh networking topographies work. I'll explain below:

deCosta wrote:

1- Radio is a shared medium and forces everyone to stay silent while one person holds the stage. Wired networks, on the other hand, can and do hold multiple simultaneous conversations.

2- In a single radio ad hoc mesh network, the best you can do is (1/2)^^n at each hop. So in a multi hop mesh network, the Max available bandwidth available to you degrades at the rate of 1/2, 1/4, 1/8. By the time you are 4 hops away the max you can get is 1/16 of the total available bandwidth.

This problem exists only when all tranceivers within a mesh topography "see" each other. And herein is the flaw in the argument. Within a mesh network Request To Sends (RTSs) do silence nodes within range; however this degradation moves in waves--so if part of a mesh consisted of 7 nodes (of which G is connected to the Internet):

A----------------->
------B----------------->
------------C----------------->
<-----------------D----------------->
      <-----------------E----------------->
            <-----------------F----------------->
                  <-----------------G----------------->
                                    |
                            Internet Connection

Here's what would happen. A would pass a packet to B; when B passed a packet to C, A couldn't talk--thus the 1/2 reduction in throughput; when C passed it to D, the same problem would occur for both A & B (thus a 1/4 throughput); likewise for D to E (because D would silence A, B, & C), thus a 1/8th throughput. However, when E passes a packet to F, A is unaffected, when F passes a packet to G, both A & B are unaffected. Thus, in this solution, throughput would theoretically max out at 1/8th (which is probably still much more throughput than the average Internet connection--where the usual bottleneck resides).

What this really points to is the need for power control in radios (which is something that CUWiN wants to work on), smart antennas, and other innovations that help to create wireless topographies where as few radios as possible "overlap." I've written about some of these solutions in a paper that I'm adapting for a book chapter -- you can download this.

3- That does not sound too bad when you are putting together a wireless sensor network with limited bandwidth and latency considerations. It is DISASTROUS if you wish to provide the level of latency/throughput people are accustomed to with their wired networks. Consider the case of just 10 client stations at each node of a 4 hop mesh network. The clients at the last rung will receive -at best- 1/(16,0000) of the total bandwidth at the root.

This simply points out the need to separate inter- and intra-nodal communications architectures--a problem that CUWiN has both already identified and implemented.

4- Why has this not been noticed as yet? Because first there are not a lot of mesh networks around and second, they have not been tested under high usage situations. Browsing and email don't count. Try video -- where both latency and bandwidth matter -- or VOIP where the bandwidth is a measly 64Kbps but where latency matters. Even in a simple 4 hop ad hoc mesh network with 10 clients, VOIP phones wont work well beyond the first or second hop -- the latency and jitter caused by CSMA/CA contention windows (how wireless systems avoid collisions) will be unbearable.

I do agree that QoS problems continue to plague most mesh wireless networks. It's a problem that needs to be solved and that most deployments and commercial (and open source) solutions sidestep. I think Francis is wise to blow the whistle on this deployment problem; I think that many commercial mesh systems have been way oversold--which will only make the problem worse.

I am constantly amazed at how little most wireless companies know about the physics, software, and hardware of the networks they deploy. Most don't even realize that if they're using routing protocols that use Standard Link State they're going to crash and burn when they scale up. For a quick graphic of the problem, just check out page 29 (labeled page 26) of this link.

This is why CUWiN is creating an A-HSLS (Adaptive Hazy Sighted Link State) protocol (as far as we know, the only open source A-HSLS protocol). We believe that routing overhead will kill networks well before throughput does.

I am optimistic that solutions will be forthcoming. What we really need today are "altruistic venture capitalists"--folks who are interested in investing in the public good -- people who will sopport the development of CUWiN (or other open-source projects that are working on these solutions) so that we can build mesh wireless systems that not only work and scale, but exceed our current expectations of what we, today, believe is possible.