[MLB-WIRELESS] [TECH] Dipole antennas, and melbwireless structure

[David Arnold]

-->"Ben" == Ben Anderson <a_neb at optushome.com.au> writes:

  Ben> Firstoff, thanks for your comments...

it's just such a relief to have technical items to comment upon ;-)

  >> personally, i think that a combination of an omni antenna for
  >> local (ie, few hundreds of metres) client access (and incoming
  >> links?), and a couple of directional antennae for meshing
  >> (outgoing?) sounds like a fine step in evolving the network.

  Ben> I agree.  Fine step.  But that's all it is.  I have serious
  Ben> doubts you can make this scale technically, financially,
  Ben> socially, etc.  I'm looking "long term" -- ie what I ultimatly
  Ben> think it should look like to "just work" -- ie ubiquitous
  Ben> public network.

i wonder if this isn't the core of a lot of the technical
disagreements that we see here:  some people are aiming at getting
something running tomorrow, that will work until the end of the year,
and others are thinking australia-wide (at least) with a planning
horizon of 3 years plus.

perhaps it's worth having two streams of design (and maybe two "working
groups"), one for each timeframe?


  >> i guess it's possible that we'll reach a stage where the density
  >> of nodes means that directional antennae are no longer required,
  >> but i suspect this is several years off ...

  Ben> the "omni antenna for local... and a couple of directional
  Ben> antennae..." solution is unlikely to be able to deal with
  Ben> scenario -- ever.

i agree.  it's not designed to.  however, it will work today and will
give us a testbed for developing the routing protocols, security
systems, etc required to support millions of nodes.

of course, you will have "wasted" two directional antennae and two
802.11b cards, but at today's prices that looks like about $70 ;-)

in 3 year's time, we'd probably be using different hardware anyway.

  Ben> Packets with the most mojo being 'spent' on this hop (for
  Ben> example, as one metric that could be used -- lots more analysis
  Ben> and simulation would be very useful on different schemes for
  Ben> load-ballencing) get ordered at the front of the queue.

so you're thinking that a packet will contain a per-hop expenditure
specification?  (presumably some sort of policy, unless you're
thinking source-routing) ?  that seems complex/big?

  Ben> And the addressing scheme, the only realistic one that scales
  Ben> well that I've come up with is one based on physical location
  Ben> (for example, gps co-ordinates could be used).

in order to scale, an addressing scheme needs either some form of
summarisation (ie. hierarchical containment) or, an ability to rely on
an external mechanism to determine a forwarding path without needing a
lookup table for every node/address.  geographical addressing is one
way (are there others?) to get the latter.

  >> what does "premium" service actually mean?  extra volume?  higher

  >> are packets charged to their originating node or the previous
  >> forwarder?  how do you prevent spoofing of packet "owner"?  does
  >> this penalise "good" services like proxies?

  Ben> I believe that every packet needs to be encrypted.  And using
  Ben> digital signatures, it makes it very difficult to spoof
  Ben> packets. 

these packets are beginning to sound quite large: mojo, spending
policy, signature ...  is this a replacement for IP?  or a shim
between IP and 802 frames?
 
  Ben> And proxy's should be rewarded with mojo, as it's a beneficial
  Ben> service to the infrastructure of the network. 

so i can earn mojo external to the routing protocol also.  ok.

  Ben> I'd like to keep away from calling it mojo if I could, as it's
  Ben> sorta already taken.... Anyone got an idea for a name?

ojom?  (no)

  >> i'd be surprised if routing protocol overhead was a significant
  >> fraction of the network traffic?

  Ben> Ok, for mobilemesh, if there's a routing update because a
  Ben> laptop has moved between 'section a' and 'section b' that
  Ben> change gets propegated broadcast-wise to the edge of the
  Ben> network that can actually address, and see that laptop.  Ie if
  Ben> everyone on the network is to see everyone else, then that
  Ben> routing update goes **everywhere**.  Imagine an australia-wide
  Ben> 10mbit ethernet segment...  Have you ever watched a broadcast
  Ben> storm?  This will be an order of magnitude worse.  The
  Ben> overheads are significant for 'discovered' networks.

deploying such a scheme over a wide area is obviously "sub-optimal" ;-)

  >>  sounds good!  let me know when i can get one for under A$500 ;-)

  Ben> Theoretically (!) they're already available for somewhere
  Ben> around that price...  No software mind you, just a pci board
  Ben> with lotsa nuts on it... they've been made for years...  I'm
  Ben> trying to get demos/samples ATM for another job.  I will let
  Ben> you know when I've got them in my hands, ready to start
  Ben> developing on.  Do you have knowledge of verilog or vhdl?

no.  i recall (i think?) a bunch of people in adelaide working with
large FPGAs on a PCI card, and dynamically programming the array to
offload expensive computation -- is this the sort of thing you're
thinking of?

is this still viable/optimal in the face of commodity multi-GHz CPUs?




d

--
To unsubscribe, send mail to minordomo at wireless.org.au with a subject of 'unsubscribe melbwireless'  
Archive at: http://www.wireless.org.au/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
IRC at: au.austnet.org #melb-wireless