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

« Parents' Lawsuit in Illinois Comes to Close | Main | Intel Seeking Seattle Surveys »

July 10, 2004

Mesh Networking Secrets, Latest Installment

Sascha Meinrath of CUWiN offers his follow-up on previous posts about mesh networking's scalability and utility: Continuing a conversation that began back here, and continued here, open-source and world-wide community mesh networking developer Sascha Meinrath replies and elaborates on those posts.

Sascha writes:

Chari is right on the mark with his clarifications on network performance degradation rates. The case I had made purposefully oversimplified the throughput degeneration rate. However, in real-world deployments, the actual throughput of a network probably degrades at somewhere between 1/n and (1/2)^n -- where n is the number of hops. Think of these two equations as two limits of the probable degradation rate; as anyone graphing these functions can see, they map an increasingly wide area of probable degradation rates as the number of hops increases -- representing an increasingly large "unknown". The point is that exact throughput degradation rates are fairly impossible to pin down because the variables that need to be taken into account differ by locale. As anyone who has done numerous real-world implementations will attest, bizarre confluences of factors can sometimes cause unanticipated outcomes and disruptions.

One of the major problems facing wireless deployers is that almost all research has been conducted either via computer simulations or in "in-vivo" deployments that are highly contrived (often within science buildings or even within single laboratories). This research provides extremely useful guidelines for anticipating problems; but often fails to capture the complexity of deployments in the community. A closer-to-life example of "real-world" usage is MIT's roofnet project, whose deployment is being used to help proof the ETX route prioritization metric that is being integrated into CUWiN's software. However, this network is utilized mainly by computer science students, who are not exactly representative of the population at-large.

Nitin Vaidya's work has made tremendous strides in our understanding of ad-hoc and multi-hop networks (which Chari does well to point out); but what is really needed is a truly community-based network (with all the attendant messiness) that can be utilized to explore the real-world limits of wireless networks. It is with this goal in mind that Nitin, David Young (CUWiN's technical lead), and I co-wrote an NSF grant proposal entitled, "Engineering Community Wireless Networks" earlier this year. For companies and entrepreneurs working on wireless networking solutions, the possibility of gaining real-world data is extremely valuable. Likewise, for those of us working on Community Wireless Networking solutions, these data will provide an opportunity for better understanding the constraints for deploying robust networks and create more precise parameters for degradation rates.

Chari was also right on the mark in pointing out that scalability and performance are not necessarily directly linked:

"Scalability speaks to how large of a network you can build. Scale is unrelated to the number of hops. A mesh network with a small number of nodes but few wired backhaul points and/or an in-line topographic layout may have a large number of hops. Conversely, a mesh network with a large number of nodes but many wired backhaul points and/or a lattice-style topographic layout may have a small number of hops throughout."

However, I would argue that they are still significantly correlated. In either case, an ideal networking system would be able to handle any of the topographies Chari alludes to as well as allow for multihoming (the use of bandwidth from multiple internet connection points for a single download or upload). Multihoming, however, brings us back to the same problem of scalability and hops being highly correlated. Most importantly, as Chari states, "The real limit to scalability in most mesh networks is routing overhead." Both TBRPF and OLSR protocols share the problem of not scaling to extremely large networks. They're built with a cell-phone, tower-based mesh topography in mind (one need look no further than the cute OLSR MPR flooding demo to see this). A-HSLS will scale to thousands of nodes arranged in a truly non-hierarchical fashion -- it's the difference between two protocols that are most useful by major telecoms, and one that is useful for community wireless networks. A-HSLS is more useful for Community Wireless Networking purposes, while TBRPF and OLSR are more useful for major telecoms.

As regards the 500mW limit I propose as a proactive solution in my manuscript, it is important to remember that one can today legally transmit at up to 1W; and with a exemption (which is pretty much a rubber-stamp process) and an amplifier, one can go up to 10W. The problem is not what power level one can transmit at with today's wireless card technology; but what will be rolled out in the future. I'm especially concerned about the WiMax technologies being proposed that allow for higher transmit powers within the same frequencies as today's Wi-Fi systems -- see this link.

The take-home message is simply that there are multiple uncertainties within wireless technologies -- and it is not that these unknowns should be viewed as a barrier -- but that there are very few universally correct answers. Whether one is looking at throughput degradation or "the best" routing protocol, wireless is a nascent technology with an incredibly diverse set of possible implementations. It is impossible for those of us working with wireless technologies to fully understand all of the different available options, much less have answers to all the questions that are asked of us. But in debating the pros and cons of different solutions, I am hopeful that we'll increase our collective understanding of wireless technologies and creat additional opportunities for making the right choice for particular implementations.