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

[Ben Anderson]

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


> > > 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 :)
>
> We must support tunneling, as it is the most feasible way to rapidly link
> segments right now, until more wireless links take over.

Yep, shortcutting the mesh is going to be *very* important to the overall
scalability of the network.


> >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.
>
> Again, how are the nodes going to "know" this if the only information they
> have is lat/long of nodes?  This only reinforces my argument that routers
> still need to do some discovery broadcasting to work out the topology of
> the network near them.

Yes, though being able to limit the zone of this discovery to a couple of
hops, and not the entire network, is going to be an absolutly massive
advantage in scaling this to large networks.


> > > 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.
>
> Again, this suggests that a _LOT_ more than lat/long information is
> needed.  For example, here, the best route to a node north of me is likely
> to be _away_ from it, to the south! :)  So we're back to some sort of
route
> discovery mechanism. :)

The lat/long thing should _work_ -- it might not be optimal, but it should
guarantee a reasonable method exists...  Plus, because the network is
effectilvy source routed, with broadcast auto source-route discovery, there
could be an interface for the originating station to define more optimal
routes...  For example, static-shortcut lists could be propegated to all
nodes on a daily, or weekly basis for example without being a significant
overhead -- and that way the originating node could calculate how to most
effectilvy use the shortcuts to mimise the mojo cost for a particular
connection, or minimise the latency regardless the cost of mojo -- that
decisoion is a 'originating stations' choice...

> >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.
>
> Well, the code will have to be ported (ever seen Windows source compile
> cleanly on a *NIX box and vice versa? - "Hello World" examples don't count
> ;) ).

And it gets worse...  I don't know if there's even an interface to getting
network layer access to windows network stack...  And if there's not,
getting raw ethernet access, and then trying to find a way to get transport
layer access back to the operating system...  Arrrgh, my brains hurting...
<back to thinking about scaling ;)>

> > > 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
>
> One of those restrictions is that the equipment needs to be type approved
> for the purpose by the ACA, AFAIK.

Yep, but if we can get generic type approved radio interfaces, and then wire
up the ADC/DAC backend...

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