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

Ben Anderson a_neb at optushome.com.au
Tue Mar 19 15:49:49 EST 2002


> >>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.
> >>
> >
> >I know it is, I've spotted this ages ago...  I keep pointing it out,
you're
> >the first who seems to have picked up on it.
> >
> Don't we first we need to have an actual network to plan long term for?
> Planning 3 years down the track is a bit pointless with the rate
> technology is advancing, something better will probably be out by then
> that solves all our problems in a little box (like the proprietary nokia
> rooftop router but non-proprietary) you can make/buy for $100.

As far as I am aware, nobody is building this.  I would like to be the one
to do so.
Would you prefer to go the "intel" route -- ie produce a chip with very
little thought to the future, and then do nasty hack after nasty hack to
'improve' it, or design a nice, fast architecture from scratch such that the
enormous amount of extra backwards-compatibility effort doesn't have to be
made (and i'm not confident the architectural changes I'm proposing are
actually at all possible to do in a backwards compatible manner...)


> >>  >> 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.
> >>
> Wait, why is the couple directional and an omni idea bad? Even if
> density gets so high that internal cards will work to link to the next
> hop, to alleviate bandwidth woes in a heavy traffic area, you could
> shoot a 5km link out of it rather than go through every single hop on
> the way out. I think this is a far better plan to solve the bandwidth
> problems than things like capping/throttling/mojo, because once you
> start doing things like that, you start turning into telstra.

They're not a bad idea.  Having shortcuts through the network are something
I want to support implicitly in the system I'm designing...  Whether they be
radio links, fibre, laser links, or even just wired ethernet...  it
shouldn't matter what physical layer gets used.  As long as the network
layer can inspect and actually 'reverse engineer' the topology as it gets
discovered.
I disagree it starts turning into telstra.  Unless you find someone who's
willing to sink an enormous amount of money in rolling out a network for
zero return, show us, and we can get this happening :)  - otherwise, there
needs to be something to cause the network to scale **socially** -- ie most
people need some sort of motivation to roll out better network
infrastructure -- if there's no motivation to engineer more bandwidth in
congested areas, then the network will die off as it gets large, it will
become disconnected and disjoined into smaller areas.
As far as I see it, we can either have a 'mojo' like system, or have a
"test" that people have to take before they get to use the network to
guarantee that the people are altruistic enough to donate to the system when
they don't have to.

Of course, I'm all ears to alternatives to solve this scalability problem.
I'd prefer it to be 100% free too.

Ben.


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



More information about the Melbwireless mailing list