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

[Ben Anderson]

> On Wed, Mar 20, 2002 at 09:34:06PM +1100, Ben Anderson wrote:
> > > Ben Anderson wrote:
> > > > > >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*
> > > > >
> > > > > Yes, mobile applications are really problematic.  If we can
> > > > > pull that one off, it'd be interesting. :)
> > > >
> > > > 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...
> > > If the discovery mechanism can cope with new nodes appearing
> > > anyway, and works well, then hopefully this would just be a
> > > matter of parameters - ie. shorter timeouts, more re-tries, etc
> > > - for a mobile protocol.
> > Yep, but there's scaling issues if we have to to a route-update
> > across the network, for the whole network every second to keep
> > track of nodes....
>
> TCP/UDP/IP was not really meant to deal with this ... but,

I know... which is why i'm talking about doing this at a datalink/network
layer, with tcp/udp layered over the top.


> even mobile type protocols that would deal with this are things like
> MANET or MobileMesh ...
>
> the problem with, say, MobileMesh is that you can set the refresh
> interval down to, say, a second. then the routing updates will flush
> the link up to the surrounding routers, then if its only up for ten
> to fiften seconds, the a link down... the routing deamon will not
> export the route further, because it could be considered to be
> flapping... =/

Yep.  When the onus of knowing where to send the data physically is the
source nodes responsibililty, rather than each node along the way, then
there's some cool magic one can do such as calculating motion vectors and
guessing position based on that.  Also, based on that, the 'backup' routes
defined in the connections state information could be used to say chase the
mobile device down the road if they do happen to move faster than expected.
Not perfect, but I think it should be a lot better than the alternative,
don't you agree?


> the other problem is that if you've only got say fifteen seconds of
> connection at any time in the 'zone', you may not actually get a wireless
> connection. so you'll never see the fixed node anyway ...

Well, the fixed node is only really necessary in what we're talking about to
do 'differential gps' without a gps :)  If you include a gps device in the
mobile device, there should be no need for the fixed device at all...


> now if you push up the output power and range of the fixed nodes
> that offer connection, such that the time your in the 'zone' is
> larger, then the time your 'online' with a particular fixed node,
> then your much more likely to get a sesible connection ...

Yep.  There are legal limits, and those limits don't allow much scope to do
this type of thing.  We're pushing it _anyway_ with some of the high gain
antennas I've seen people hanging off their pigtails....


> this is the main reason that mobile phones as we know them, work.
> its a trade off between, a large enough area, not too much power so
> that the base station can still 'hear' the mobile phones ....

But how do they scale mobile networks?  That's right, shrink cell size, add
more towers.  Make the broadcast zones smaller.  Same amount of bandwidth
used, more users online, more profit (for them).  More cross sectional
data-bandwidth across the network in our case.  We can't buy more bandwidth,
we're stuck inside the ISM bands defined -- ie 802.11b we have 3 11mbit
channels.  802.11a has 13 54Mbit channels...

We're limited to shrinking cells, and hopefully have non-interfering highly
directional shortcuts, or tunnels across the mesh...

n way connectivity would be nice...  But as it gets large, 4 or 5 way
connectivity is probably more the ticket...  And that should scale to the
order of magnitude of a million nodes using the 'advances' i'm suggesting,
based on my calculations and rough simulations so far...  There's still
plenty of work to do...

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