roaming nodes -was- Re: [MLB-WIRELESS] [TECH] Dipole antennas, and melbwireless

[Ben Anderson]

> It occurs to me there are two slightly different appraches here:  the
> truly mobile, ubiquitous, always-on, auto-roaming, 100kph down the
> western ring-road approach, and the node that might relocate once or
> twice a day - the laptop user who heads off to the park or cafe for
> example.  And thus two somewhat different levels of doability.

Not as different as the "hack it together now" approach, and the "design a
ubiquitous, scalable network" tomorrow approach...


> QoS in the case of the occasional roamer could be a lot lower - a few
> minutes to  sign on might be acceptable, as opposed to instantaneous
> handover.  And blanket coverage might not be essential either - one
> cafe or park bench might have better connections than another, and as
> long as the coffee/scenery was up to scratch, that might be okay.

Yep, exactly the reason why I'm not as stressed about it...  the outgoing
connection should always be reliable in my mesh I've been describing...
Incoming, the source node needs to know the physical location, so if the
mobile device can't update it's location at it's home faster than it's
moving, then source nodes are not going to know where to send packets...
Ideally, it'd be recognised by the transmitting station the destination
co-ordinates of the destination node are moving, and compensate with a
latency calculation, and then dynamically change the destination address
such that the listening station is always in the broadcast zone of the
destination packets address.  That's an optimisation that's able to be done
without changing the initial design, in a 'non-hacky' way.


> Is the latter case in fact qualitatively different from a stationary
> node?  Because it's this version of "roaming" that most interests me.

Being able to fully dynamically roam is always going to be a non-trivial
problem...  if a high enough percentage of the nodes do it, then I think
there's going to be issues in any kind of peer-peer network topology.  I'm
just not sure there's any options, or ways around this (apart from what I
just described last paragraph) without throwing the p2p idea out the window.


> >>  > 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.
>
> won't the directional links serve this purpose to some extent?

Yes, indeed they will.  Though because 1/3 of the available spectrum is used
to be able to do this, it limits the availability of the non-shortcut mesh
in the area covered by that directional, limiting the overall scalability of
the cross sectional bandwidth of the mesh as a whole as it gets large.


> >And these routes can be statically specified.
> >
> >>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 can see here where "relocating" nodes differ from truly stationary
> ones.  I might only want to move a few times a week, but i might want
> to move from one side of the city to the other.

If you imagine your physical location as your IP address, it gives you a
fair idea of what the disadvantages of being mobile are in this setup.


> >>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...
>
> one day i will understand paragraphs like that really i will
> right now it just makes my head hurt :-)

Heh, don't worry, it'll come, just stick at it...   I've spent a fair bit of
time on&off dreaming some of this stuff up...

> Is any of this covered by what these guys are doing?
> http://www.meshnetworks.com/

Looks very 'mobilemesh' like...  very vague on the site about the actual
technical way they solve the problem...
Looks like they're trying to keep it fairly closed if I read the site
right...


> "MeshLAN software transforms wireless LAN cards into
> router-repeaters, which enhances and extends the wireless reach of
> each subscriber in the network. A MeshLAN-enabled Wi-Fi user who is
> out of range of an access point can hop through one or more users to
> reach the access point. Furthermore, the MeshLAN routing intelligence
> will automatically shift transmissions from congested access points
> to uncongested ones - easing bottlenecks and improving overall
> network performance."
>
> I seem to remember they were licensing their software free for
> non-commercial applications, but that might have been someone else
> with a similar name.

Anyone want to see if they can score a copy of the code, wouldn't mind
having a look :)


> >Hrm, maybe...  Dunno, I'm not a lawyer. :)
>
> neither am i:  here's the bit that makes me wonder though:
> from http://www.itee.uq.edu.au/~mesh/doc/2001-10-25-aca-answer.txt

<snip detail copied from that link>

Hmm, that legal advice is certainly dissapointing...  Means anyone operating
any type of routing through this tech is likely already breaking the law.
There's certainly going to be a critical mass that once it's reached 'on the
quiet' it's going to be very difficult, and perhaps not in the interests of,
the government (or derrivatives) to stop.  Not that I'm suggesting anyone
should break the law, of course.

I wonder how much that advice would change if we all just "hammed up"
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