Re: [MEXT] [dmm?] Surprising assertion about make-before-break handover prevalance

"Stuart W. Card" <[email protected]>
Newsgroups gmane.ietf.nemo
Organization Critical Technologies Inc.
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/4/2011 5:22 PM, [email protected] wrote:
> ...
> I guess you are referring to handovers across different access types...

Could be either -- some systems have multiple interfaces of the same
type that can be active simultaneously. For instance I have worked on
airborne platforms with multiple VHF/UHF line-of-sight radios each
connecting to a different basestation concurrently; depending upon where
the aircraft was in its orbit, it would have good links to some but not
all of the basestations; we load balanced dynamically across all links
that were up at any moment, keeping MIP registrations active on links
that were down only briefly by backing off the registration timeouts
(but not routing any traffic over them while they were down).

> Will devices keep multiple radios powered on simultaneously in the future?
> It depends.
> Battery technology still lags the advances of radio, processors and
> displays on devices. And hence it generally boils down to optimizing
> battery in handheld devices which implies that you would not want to
> always keep multiple radios switched "On" all the time...

There's nominally "on" and there's really "on". IMHO you can expect to
see newer radios that aggressively manage battery energy consumption
through scheduling and wake-up tricks, so that a radio can be nominally
"on" in the sense that if any traffic is destined for that node, it will
go really "on" and receive that traffic, then go quiescent again.
Whether this happens on a session by session or packet by packet basis
is just another engineering trade-off that can go either way depending
upon the particulars of the design case.

> On 8/4/11 3:52 PM, "ext Charles E. Perkins"
> <[email protected]> wrote:
> 
>> ... I'm curious whether or not handovers in the future
>> would be typically make-before-break.  Or [even "worse"],
>> in terms of radio interfaces, whether typically wireless
>> devices in the future will keep multiple radios powered
>> on all the time...

Check out how many Android smartphones operate today. I'm not sure, but
it looks to me like they continue to use their cellular connections for
certain network management functions even when they are using WiFi for
user bulk data transfers. Also consider the use of smartphones as WiFi
hotspots, together with WiFi mesh networking: there are all kinds of
corner cases involving NEMO, MANET, etc., some of which may become
prevalent. The Internet of Things will complicate this further.

A while back when I was actively participating in the on-line
discussions regarding NEMO, it was decided that the complex cases
involving multi-homing and nesting would be left out of scope, because
they were a lot harder than the basic scenarios that presumably would be
a lot more common initially, and we needed to make progress on support
for those basic scenarios. Here's a scenario I presented then (avoiding
HA, MR, etc. nomenclature and details to avoid nitpicking):

NEMO#1 aboard aircraft#1 connects to basestation#1

NEMO#2 aboard aircraft#2 connects to NEMO#1 initially (nesting)

NEMO#2 aboard aircraft#2 connects to basestation#2 later (multihoming)

NEMO#1 aboard aircraft#1 loses its connection to basestation#1

Do we really want to cause all open connections from nodes in NEMO#1 to
break? When they could be re-routed via NEMO#2 (nesting, reversed from
its initial heirarchy)?

If I were running NEMO#2, I sure would want to make a route via
basestation#2 before I broke my route via NEMO#1... and if I were
running NEMO#1, and had some way of learning that NEMO#2 had achieved
another path to the backbone, I sure would want to make a route via
NEMO#2 as soon as I could, just in case I might later break (lose) my
route via basestation#1.

Addressing this handover/multihoming/nesting scenario is probably out of
scope for DMM.

However, it would not seem to me very prudent to design DMM such that it
can't handle at least make-before-break, and preferably the more general
case of "multiple radios powered on all the time".

(Just the $0.02 of a guy who was heavily involved in some of the
earliest experiments with MIP, NEMO, multi-homing and nesting on
aircraft, but who has not been active since this WG became MEXT.)

- -- 
Stuart W. Card, Chief Scientist & VP, Critical Technologies Inc.
* Creativity * Diversity * Expertise * Flexibility * Integrity *
Suite 400 Technology Center, 4th Floor 1001 Broad St, Utica NY 13501
315-793-0248 x141 FAX -9710 <[email protected]> www.critical.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk47H/wACgkQS7PQ0a2weL6jPACfQYwRIH7jSt2HQesBC2gISXtI
qOwAoMWoWjmtJpOs8C8T0jPLX7daoVX4
=2c8h
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.