[MLB-WIRELESS] [TECH] Dipole antennas, and melbwireless struc ture

[Tony Langdon]

Some good ideas in here, but I've got a couple of comments.

> I disagree with this as a "structure" as it's backbone based, 
> and won't
> scale to more than a few of handfuls of nodes.

My gut feeling is that some sort of mesh topology will be needed to probvide
sufficient bandwidth for a large number of nodes to exchange data at
reasonable throughput.  Also, the routing needs to be robust enough to
efficiently deal with (for example) XYZ node suddenly disappearing, because
its owner turned tripped over the power cord or whatever. ;-)

> network better so _they personally_ get better access -- most 
> people seem
> very willing to spend a thousand dollars on better equipment 
> if they get
> 'better access'.
> Some people have brought up the fact that people on 'edges' will get
> discriminated against by getting poorer access because they're not
> transferring others data....   One potential thing could be 
> other services,
> hosting, data, etc, but since the network is primarily about 
> transferring
> data, I suspect that it's going to have to be a consequence 
> to get it to
> scale.  Unless someone else has an idea to bypass this limitation?  (I
> purposfully built in this 'leaf node discrimination' to 
> prevent leaf nodes
> logging on and doing nothing but sucking down high bandwidth 
> apps off the
> network (mp3, warez, movies, etc).

This might be a necessary evil.  I'm one who might get a bit of a raw deal,
because I'm not in a particularly good spot RF wise, and probably 45-60
degrees of my field of view is useless, because of Essendon Airport (and the
lack of LOS ensures I won't be able to pass the airport either, not to
mention the effect of aircraft movements! :) ).  However, I may be able to
offer tunneled routes, as long as I can limit their bandwidth to 64 kbps.
Doesn't sound like much, but perhaps our protocols can mesh tunnels as well
one day. :)

> 
> Also, to prevent lots of bandwidth being wasted doing network 
> discovery as
> in OSPF, or mobilemesh, I'm proposing a networking scheme 
> that relates to
> physical location....  This has privacy concerns, but so far 
> I've not come

Given the huge number of unknowns, I am somewhat skeptical of this approach,
and am not sure how well it will work in practice.  There are many factors
that affect propagation at 2.4 GHz which can't be expressed by a 2
dimensional lat/long coordinate set.  These include:

Terrain
Antenna pointing
Stray reflections (I am going to have some interesting aircraft bounce! ) ).
noise and interference (OK, I'll keep my 2.4 GHz TV transmissions to 1W and
avoid transmitting during game tournaments! ;) )

> the top of it.  Intelligent caching, even perhaps a 'dns' style node
> location system may be useful in producing a "nasty hack" 
> version of what
> i'm talking about using current networking stacks...

I feel each node is going to have to discover its environment, but as a lot
of the variables are relatively static, or vary be relatively small amounts,
a lot of the node availability information could be cached, and "neighbour
discovery" may be able to be kept to a minimum.  For many sites, their RF
coverage will be anything _but_ a simple approcimation of a circle.

> Encryption in this network would be a very high priority, to 
> prevent nodes
> from intercepting traffic, and modifying it unknown.  For example, a
> commercial entity could setup a load of nodes, and use it to 
> insert spam
> randomly into all our traffic....  With encryption, that 
> dissappears.  And
> it also removes some of (but not all) the privacy concerns.  
> Encryption

Agreed, encryption should be standard, and all normal security procedures
should be applied.

> isn't really a "hard" problem based on the ready-made libraries that
> exist...  The routing protocol, and actually getting it 
> working (and then
> getting it working on win* platforms...  (I don't even want 
> to _think_ about
> a network layer win32 app, let alone build one))

Well, do things the way the OpenSSH guys do it.  Write a version for your
favourite target OS, then hand the code to a porting team who port it to run
on other architectures.  No need to reinvent the wheel here. 

> Ideally, I'd like to have a pll, a mixer, a big, 
> high-bandwidth DAC/ADC and
> a dsp/fpga combo to impliment a lot of different modulation 
> techniques (ie
> the closer you are, the more wideband, spread spectrum high bandwidth
> protocol you use.  And the further you get, the more narrow 
> band, slower,
> reflection and fade resistant modulation you use.  So you can 
> still get
> _any_ connectivity when you're 'just' out of range...  But 
> this is definatly
> a long term 'fun' project (money, time...)  (though if 
> someone wants to hire

Well, for that sort of thing, we're now well outside the realm of ISM class
licence conditions.  Get a ham ticket and tinker to your heart's content,
that's _precisely_ what the ham bands are for - personal experimentation and
self training in radio techniques. :-)  And I, for one, would love a good
excuse to play with high speed data on microwaves...   Need a testing
partner? ;)

---
Outgoing mail has been scanned for viruses
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.336 / Virus Database: 188 - Release Date: 11-Mar-02
 

This correspondence is for the named person's use only. It may contain
confidential or legally privileged information or both. No confidentiality
or privilege is waived or lost by any mistransmission. If you receive this
correspondence in error, please immediately delete it from your system and
notify the sender. You must not disclose, copy or rely on any part of this
correspondence if you are not the intended recipient.

Any opinions expressed in this message are those of the individual sender.


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