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

[Jon]

For those who don't like the quotes - cope and deal with it, I want the context.

Yes - nodes should _actively_ work out their best routes, and do this _constantly_.

However, I agree with earlier comments about just getting something up and working.


Note though:  how do you go about establishing what a target actually is, for the purpose of optimising
routing ?   By this I mean - what is it that prompts a node to find a shortcut to another node in the
first place ?  What is the metric ?


Jon


Ben Anderson wrote:

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

--
I've played piano in a whorehouse.  I've smuggled secret papers out of Russia...I've taught a gangster
mob how to play Pinchie Winchie, sat on the floor with Greta Garbo, horsed around with the Prince of
Wales, played ping-pong with George Gershwin.  George Bernard Shaw has asked me for advice.  I've
basked on the Riviera with Somerset Maugham and Elsa Maxwell.  I've been thrown out of the casino at
Monte Carlo.

       - Harpo Marx



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