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

[Jason Brice]

<quote> Yes, though being able to limit the zone of this discovery to a
couple of
>hops, and not the entire network, is going to be an absolutly massive
>advantage in scaling this to large networks.</quote>

<quote> Well, this is where we can experiment.  We also need to know in
rough terms 
which directions are best for sending to certain destinations (here's
where 
the lat/long might be useful), based on previous "experience") for
longer 
paths.</quote>

umm.. these 2 things are what a routing protocol does. OSPF (for
example) breaks the network up into managable AREAs and only swaps
pertinent information between them (route summarizations, etc.)
and (nearly) any routing protocol will be able to weigh up a metrics for
different routes, and not in "rough terms" ;) directions and lat/long
will have no real bearing, things like delay, bandwidth, load, hops are
more important when choosing a route.

J.

-----Original Message-----
From: Tony Langdon, VK3JED [mailto:vk3jed at optushome.com.au]
Sent: Tuesday, 19 March 2002 8:13 PM
To: Ben Anderson; Tony Langdon; melbwireless at wireless.org.au
Subject: Re: [MLB-WIRELESS] [TECH] Dipole antennas, and melbwireless
structure


At 07:25 PM 19/03/2002 +1100, Ben Anderson wrote:

>I think it's do-able, just not trivial :)  It should work, just with
minor
>interruption - this isn't a major concern to me, the scalability issues
are
>much more interesting...

I might wanna run tram mobile on a Windows box LOL  (ppl who know me
would 
believe this :) ).

> > We must support tunneling, as it is the most feasible way to rapidly
link
> > segments right now, until more wireless links take over.
>
>Yep, shortcutting the mesh is going to be *very* important to the
overall
>scalability of the network.

And these routes can be statically specified.

>Yes, though being able to limit the zone of this discovery to a couple
of
>hops, and not the entire network, is going to be an absolutly massive
>advantage in scaling this to large networks.

Well, this is where we can experiment.  We also need to know in rough
terms 
which directions are best for sending to certain destinations (here's
where 
the lat/long might be useful), based on previous "experience") for
longer 
paths.

> > Again, this suggests that a _LOT_ more than lat/long information is
> > needed.  For example, here, the best route to a node north of me is
likely
> > to be _away_ from it, to the south! :)  So we're back to some sort
of
>route
> > discovery mechanism. :)
>
>The lat/long thing should _work_ -- it might not be optimal, but it
should
>guarantee a reasonable method exists...  Plus, because the network is
>effectilvy source routed, with broadcast auto source-route discovery,
there
>could be an interface for the originating station to define more
optimal
>routes...  For example, static-shortcut lists could be propegated to
all
>nodes on a daily, or weekly basis for example without being a
significant
>overhead -- and that way the originating node could calculate how to
most
>effectilvy use the shortcuts to mimise the mojo cost for a particular
>connection, or minimise the latency regardless the cost of mojo -- that
>decisoion is a 'originating stations' choice...

Static routing can be cached easily, as long as there exists a mechanism
to 
advertise the loss of a static route as well (i.e. a node is turned off
in 
a controlled fashion).

>And it gets worse...  I don't know if there's even an interface to
getting
>network layer access to windows network stack...  And if there's not,
>getting raw ethernet access, and then trying to find a way to get
transport
>layer access back to the operating system...  Arrrgh, my brains
hurting...
><back to thinking about scaling ;)>

Apparently, it can be done, though not by a MS provided API.  But
Windows 
will need support by _someone_.

> > One of those restrictions is that the equipment needs to be type
approved
> > for the purpose by the ACA, AFAIK.
>
>Yep, but if we can get generic type approved radio interfaces, and then
wire
>up the ADC/DAC backend...

Hrm, maybe...  Dunno, I'm not a lawyer. :)

73 de Tony, VK3JED
http://vk3jed.vk.irlp.net

--
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