[Cu-wireless] Re: tonight's wireless meeting

David Young dyoung at onthejob.net
Tue May 14 14:31:47 CDT 2002


Just for the record, we are trading bandwidth for

  * low cost
  * ease of installation & maintenance
  * high connectivity
  * homeowner's acceptance

Also, the problem of improving bandwidth can be framed as a problem in
power control and media access arbitration as well as channel assignment
and antenna selection. I think it is significant that "the literature"
on wireless networking prefers to investigate the former problems (MAC,
power). I am still trying to figure out what the significance is. =)

Dave

On Tue, May 14, 2002 at 12:52:19PM -0500, Zachary Miller wrote:
> >   It would be most helpful to have a chance to digest the current plan before
> >   I get there this evening.
> > 
> >   *hint* *hint* :)
> 
> I didn't get out of the 
> 
> >From 6pm-6:30pm we'll 
> 
> 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
> 
> _______________________________________________
> Cu-wireless mailing list
> Cu-wireless at lists.groogroo.com
> http://lists.cu.groogroo.com/cgi-bin/listinfo/cu-wireless

-- 
David Young             OJC Technologies
dyoung at onthejob.net     Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933




More information about the CU-Wireless mailing list