Nov

27

OPeN -- the Genius of Sharing Other People's Networks...

»
sascha's picture

Only from the mind of Matt Westervelt would such a devilishly parsimonious solution to one of the most dreadful problems in community wireless networking emerge. This issue is, of course, how to connect wireless nodes that are just "a wee bit" out of range from each other. OPN (or OPeN as I'd like to call it ;) is a network solution that is both elegant, simple to deploy, and beneficial to everyone involved -- an idea hatched of good cheap beer, fresh air, and wireless plotting at the FreiFunk.net conference in Djursland, Denmark.

Matt brought it up with team CUWiN while we were all in Denmark together, and after several days of discussion, we're pretty certain that it's a feasible, implementable solution. Recently, Matt set up a Sourceforge Project for it. What we need now are people to hack on the idea (as well as the software) and send in thoughts and suggestions -- here's how it works (callously mirrored from http://dek.spc.org/opn ):

Community networks must connect together through massive clouds of interference as a consequence raise noise floors in busy areas. By utilizing OPN we can greatly condense this noise whilst building sustainable free networks locally that optimize existing RF resources.

OPN.gif


Blue circles represent the standard consumer access point; no WEP,
No MAC filtering, can be on any channel any ESSID.


Red circles represent community network nodes that run with OPN enhancement.


Purple details suggest links created by the red network traversing the blue AP's in proximity, whose RF signal is otherwise considered as 'noise' in the band.


To achieve these links Red nodes must associate as clients to multiple networks simultaneously. Each Red network uses its own address space and does not use the blue networks resources for anything other than layer 2 transport.


In the pictured example a route is created over OPN from [A-D] [D-E] [E-C] etc. that by traditional methods would not be achievable.


The gory bit

To identify OPN set your adapter to monitor the local RF environment (essid mac address SNR etc.) and record its image to public servers via a back channel (telco or freenetwork) to inform the public mapping of other peoples network!


Once the environment condition is calculated it can then be referred to by Red wlan adapters operating as client to multiple Blue networks on managed IP and routing protocols set by Red nodes.


How

None of this is technically resolved at this moment, but it appears to be within reach with some driver hacking. Commercial exploration into how a single radio can become client of multiple networks has been carried out by Microsoft Research called 'Multinet' and may also be possible with BSD or Linux and Atheros chipset on free operating systems. In fact recent announcements from student development at MIT confirms this probability.


Using multiple networks with a scary/simple hack

'Packets are collected by the WLAN adapter which buffers the packets and sends a sleep frame to the AP The card changes channel and essid and empties the buffer..


This is not thought to be a definitive path to community or mesh networking, but will definitely present a favorable option especially in dense RF areas.


Articulated by Matt Westervelt and illustrated by James Stevens during freifunk.net

  1. Bob Keyes (not verified) on Sun, 2004-11-28 12:37

    Actually, Matt Westervelt wasn't the only person to think of this...I am another ;) I thought of this a few years ago, when I was contemplating the best way of creating a self-organizing mesh network. The problem is the implicit low number of hops this provides: even if it were possible, it isn't very friendly or legal to reprogram a neighbor's access point to also be a client and associate with other networks. But if it were possible and easy, I am sure some black-hats would remotely reprogram available access points...ahem.

    What this IS useful for is a small-scale network that just needs a little bit more stretch - as in two buddies who want to share a DSL line but there's an apartment building in the way. They would use this OPN on an AP in the building.

    This idea could be integrated into a more complex mesh networking system like Roofnet or what you guys have at U-C. But there needs to be some attention paid to not greatly diminishing the usability of the generic access point to its rightful owner.

  2. Matt Westervelt (not verified) on Sun, 2004-11-28 15:59

    There is nothing about OPN that requires reprogramming other people's access points. A non-OPN AP in the system acts just as it normally would, managing the link layer of the clients attatched to it. Furthermore, OPN does not use the participating APs layer 3 address space or internet connection, it is only used for it's layer 2 management. Although it is easy enough to reprogram available access points given the amount of default settings out there, that is nowhere in the scope of OPN, nor should it be. OPN is simply a layer 2 enhancement for use in areas of high density.

    To use someone else's AP in a 2 client situation (as you described [client<->AP<->client]) does not require OPN. This is simply utilizing an AP in the traditional manner. OPN is necessary when you have the simplest case of 3 parties (OPN nodes, 802.11 clients[client<->AP1<->client<->AP2<->client]) that want to talk, but only have 2 common APs. This can be done currently by adding 2 radios to the 'middle', or by implementing OPN and becoming a client of both AP1, and AP2 simultaneously.

    To dismiss this by only thinking of the legality (which no-one has convinced me is an issue), you miss a huge opportunity. By having the ability to client to multiple networks, you can create a community network with much lower barrier to entry than currently exists. A novice user simply has to choose the community ESSID (which is filtered by OPN) and nodes running OPN can use them to extend their reach.

  3. sascha on Sun, 2004-11-28 16:47

    I think Bob's concern over layer 3 "hacking" of APs is certainly valid -- but what I really like about the solution Matt's proposing is that it doesn't require _any_ hacking of a third-party's hardware. What's so elegant about this solution is that the third-party is not harmed by the OPeN network -- they simply are utilized to relay between the other two APs (call them "A" & "C"). In addition, because the middle AP (call it "B") would, in essence, coordinate the data-flow between the other two APs, in certain circumstances OPeN might actually _lessen_ the interference that B would otherwise face if A and C were off broadcasting without any coordination.


  4. Dave Young (not verified) on Sun, 2004-11-28 16:55

    There is no question that OPN can be implemented in open source using several of the common 802.11 client adapters. The adapters with 802.11 ASICs from Atheros, Ralink, ADMtek, and Realtek are appropriate.

    As Matt and James' explanation mentions, Microsoft Research demonstrated Atheros radios operating simultaneously on more than one network, even networks of disparate types (ad hoc & infrastructure) and on different channels (6 & 11). They called the result MultiNet. The way it works is that the radio switches rapidly between the networks/channels without dropping its state of AP/client association. Also, a MultiNet client cleverly exploits the 802.11 power-saving facility to make an access point buffer the client's packets while it visits another channel. In this way, no packets need be dropped just because the receiver is off-channel.

    Microsoft's work is reproducible in open source. You have to modify the device driver to do it. Programming device drivers is something I do for fun and for profit; I'm looking forward to implementing OPN in my hobby time at my earliest opportunity---looks like late winter or early spring. I have a software architecture in mind for OPN which I will write up considerably sooner.

  5. Mesh Sandbox (not verified) on Mon, 2004-11-29 21:51

    TrackBack from Mesh Sandbox:

    Sascha Meinrath on OPN:

    OPeN -- the Genius of Sharing Other People's Networks...

    "Only from the mind of Matt Westervelt would such a devilishly parsimonious solution to one of the most dreadful problems in community wireless networking emerge. Th......