No subject

Here's the insane non-standard critical part of our plan summarized briefly: 

Premise: Initially for budgetary purposes we are willing to sacrifice
bandwidth in favor of cost. Consequently we are aware that our design
does not make optimal use of channels or conservative use of radiation
patterns of antennas (leading to possible interference issues in
neighboring pods).

Goal: Our goal is to provide a house to house network using wireless
technology in order to gain freedom from the local telecom
duopoloy. Besides offering the ability for neighbors to share internet
access, we also want to provide services that are entirely local to
the wireless network that take advantage of the available
bandwidth. These services may include but are not limitted to voice
over IP alternative to phone service, streaming audio and video
alternative to radio and cable including live and archived content
originated from the Urbana Independent Media Center as well as "radio"
broadcasts originating from random members houses. We have an interest
in multicast to facilitate some of this but don't really know much
about multicast yet. Because our goal is to be able to eventually get
from anywhere to anywhere we aren't just talking about making a few
long range links for Internet sharing purposes like some other
wireless groups are.

Platform: We will initially try to use only one radio per node and
that radio will use an omni antenna. The main strategy will be to
rebroadcast packets on the same antenna they were received on on the
same channel if they need to be relayed along. Although this means a
significant reduction in the availability of the channel and a
probable increase in collision rates, it will also represent a
significant cost savings.

Definitions: 

Node - A computer/router build by the wireless project containing at
least one wireless card and at least one wired ethernet card and
implementing conforming standards. 

Pod - a logical group of homes in an area. Most homes in the pod are
within radio range of some central home or multiple central
homes. Every home in the pod is within radio range of at least one
other home in the pod. Homes in a pod only talk to other homes in the
same pod except for the one or more central homes which have uplinks
to other pods (these central homes are the only homes with a second
radio).

Intrapod Interface - The radio in a node that talks to other nodes in the pod. 

Interpod Interface - The radio in a node that is typically connected
to a directional antenna that links the pod to some other pod in the
network.

Subscriber Interface - The interface on a node that is connected to
the network inside the home. This may be a wireless interface acting
as an access point for the home or it may be a wired ethernet
interface connected to a hub or switch or firewall or whatever. 

Channel Allocation - Every intrapod radio in a pod uses the same
channel. Neighboring pods use alternating channels whenever
possible. Interpod links use whatever channels interfere least with
the pods they are interconnecting.

Routing within a Pod - Now here is where things get tricky and you
come in. We believe (via handwaving) that we can configure OSPF all
the nodes within a pod to have 32 bit netmasks (1 host) and then to
have their routing tables try to find routes to every other node in
the pod (which given a pod number is an enumerable set of no more than
a hundred or so IP addresses). Then we believe that OSPF can be
constantly checking to see which of those hundred IP addresses it can
really reach and find out which they can respectively reach and they
can all set up dynamic routes appropriately.

Things we don't know: 

What is the retransmission latency on a wireless card? If we have
single radios acting as repeaters will the latency kill us as each
packet has to travel over the same airwaves multiple times excluding
all other packets from using the medium (or worse causing collisions).

Does OSPF even work the way we think it might?

There are lots of other issues and questions. We've worked out a lot
of answers to a lot of things and what we really need is for people to
ask obvious and non-obvious questions so we can figure out whether
we've really got answers to them all.

-- 
Zach Miller - @=
Systems Engineer - UIUC - NCSA - CDM - PSI 
WWW: http://www.ncsa.uiuc.edu/~zmiller/
Phone: 217-265-8458 // Office: 141 CAB