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

[Ben Anderson]

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

Comments, exactly what I wanted.  Goodie goodie :)

> > 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. ;-)

Even more difficult is a 'moving node' -- a node in a car shifting between
cells at 100Km/h, could change routing cells every 10 seconds...  Being able
to maintain a reliable bi-directional connection is going to be *tough*


> > 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. :)

Shortcuts across the network I think will be all important to getting this
working widespread (ie over bigger areas than mobile mesh already scales
to).  64kbits might not sound much, but if it's a low-latency connection
across a congested network, it could be an extremly valueable route (read
lots of mojo).  If you're in a disadvantaged location, there's nothing
stopping you running a node up a tree in a congested part of the network to
accrue mojo for you to spend :)

> > 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! ;) )

if a node can receive a packet, then that node can work out the best route
to send the packet out of (if it has multiple interfaces) to get that packet
physically closer to the destination...   One thing that would be cool is to
be able to somehow 'route backwards' if there's a 'cheap' shortcut across
the network -- ie say your neighbour has a fibre connection that goes _past_
you  (but not connects with you) that means that to use that to route
traffic out, the wireless node would actually have to transmit data
backwards (well, this example would actually work correctly, because the
shortcut is inside the broadcast zone of the original node...  if there's
one layer of indirection, it breaks...  and i haven't thought of a simple
way of dealing with this except perhaps maintaining an x hop accurate
routing map (ie OSPF like)... that way the size of the 'hole' the shortcut
can service doesn't simply extend behind it (which it naturally does with
the system I've described), but in front of it as well by x hops.


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

I make no assumptions about the size or shape of the broadcast zone.. if a
node hears the packet, and it's in the direction of the destination node, it
will rebroadcast on the best outgoing route it has.  When the connection is
'established' the best route will have been discovered, and known by the
destination node, and that info can be sent back to the source in the ack to
do source-routed packets.

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

No porting is really necessary for the encryption, because the whole network
layer in the OSI model is being replaced, if the system compiles for a
target system, the encryption will come along for the ride.


> > 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? ;)

The ISM bands can be still used, as long as the device complies to the
restrictions set down in the class licence.  There are a lot of bands that
are capable of being used...  which is good, the low frequencies propegate a
long way (but at low bandwidth) so people on fringes can still get some sort
of access...  I'm not sure what the effect of basically saturating all
available ISM bands within the legal limit would be -- would they put
additional restrictions on the ISM bands to effectivly ban the device?

Even if we have to get ham licences, for the benefit of this system, I'm
sure we could get piles of people licenced... they're not that pricey...
and there's some you don't even have to know morse for (I do already know
morse though...)

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