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

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 04 Aug 2011 13:52:07 -0700

Hello folks,

Sorry if this is considered to be imperfectly relevant,
but 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.

This might well have an impact on assumptions about
dmm.  It was claimed that, for instance, iPad and iPhone
usually have both interfaces active.  I know that when
I'm using my iPad I do not keep both radios turned on,
but I do not claim to be a typical user, and anyway I
do not have an iPhone.

Comments will be appreciated!

Regards,
Charlie P.

---

From: <[email-masked]>
Date: Thu, 4 Aug 2011 21:22:01 +0000

Hi Charlie,

I guess you are referring to handovers across different access types
(wifi<->3G) etc.

Whether you can accomplish a make-before-break handover in such scenarios
depends on the device in many cases. So there is no black-or-white answer
to your question at the present time.

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. You could if you
were willing to carry around a battery backpack all the time :)
Or keep your device plugged into a power source or charge it every few
hours...

Algorithms will/may help a device to turn on/off various radios to enable
better handover performance. And multiple radios could be simultaneously
operational for brief periods of time to enable the make-before-break
handover scenarios.

DMM design should not be overly concerned about the make-before-break
handovers IMO. DMM is focused on optimizing the latency, reducing backhaul
traffic etc. I don¹t believe DMM is a way to enable handovers with better
performance. It would be a benefit if performance of even the
break-before-make handover scenario improves as a result of DMM.

W.r.t devices a couple of examples:
1. On my Nokia N900 (Maemo), I can operate both the wifi and 3G radios
simultaneously (requires an update to the software that ships on the
device). Normal operation however is either wifi or 3G.
2. On my N8 (S^3), I can have cellular data (PDP context) and wifi
connectivity running in parallel all the time. But there is no good reason
to do that. And hence the setting is to have either 3G or Wifi data
connectivity. 

-Basavaraj

On 8/4/11 3:52 PM, "ext Charles E. Perkins"
<[email-masked]> wrote:

>_______________________________________________
>MEXT mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mext

---

From: "Stuart W. Card" <[email-masked]>
Date: Thu, 04 Aug 2011 18:41:00 -0400

On 8/4/2011 5:22 PM, [email-masked] 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).

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

>> ... I'm curious whether or not handovers in the future
>> 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-masked]> www.critical.com

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 05 Aug 2011 12:24:49 +1000

Hi Charlie,

I don't think anyone can answer that question with enough certainty that
allows their answer to become a reliable assumption.
If history is anything to go by, it doesn't look likely, but who knows.

Cheers,
Hesham

-----Original Message-----
From: "Charles E. Perkins" <[email-masked]>
Organization: Wichorus Inc.
Date: Thu, 04 Aug 2011 13:52:07 -0700
To: mext <[email-masked]>
Subject: [MEXT] [dmm?] Surprising assertion about make-before-break
handover prevalance

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 04 Aug 2011 19:53:38 -0700

> were willing to carry around a battery backpack all the time :)

After all the standardization around MCoA/IFOM, building all the
hype/coolness around driving one flow on path and another the other path,
its sad to note that we simply don't have the devices/or the battery
technology that can keep multiple radios up at the same time for a
reasonable length of time (except few exceptions). Most devices/operator
configuration still try to keep only one radio active at a time, so they can
claim better battery serving time. So, we are not there yet, but from what I
believe with LTE radios, the power requirement is only going up. Hopefully,
there will be a major breakthrough in the battery technology that will allow
all the radios to be up for a day with a recharge ...

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 05 Aug 2011 13:31:44 +1000

From: Sri Gundavelli <[email-masked]>
>reasonable length of time (except few exceptions).

=> This is not about MCoA or flow mobility. Of course we have the ability
to have multiple interfaces up and many of us use it everyday. I assumed
Charlie's question was not about this trivial case, which we all know
exists, but rather about a single technology doing make before break
handovers. I know of only one radio technology that did that in real
deployments (OFDM).

Hesham

>Most devices/operator

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 04 Aug 2011 21:24:39 -0700

> handovers. I know of only one radio technology that did that in real

Yes, we slightly digressed from Charlie's original point. But, on keeping
multiple radios up, the point that Raj touched on, sure, we can keep all the
radios up, but with the charger wired on, in practical terms. All I know is,
if I keep my WLAN interface up on my Droid X, I need a much sooner recharge.
I also know, most terminals are configured to USE only one radio up for
whatever reasons. But, I Ack, there may be some terminals which may be using
both the interfaces, ignoring their SAS awareness ..etc...

Any case, glad to hear your comments/disagreements. We need some life into
these all dead IETF mailing lists :) ...

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 05 Aug 2011 15:11:42 +1000

>whatever reasons. 

=> Yes they use one radio because they don't have sophisticated enough src
address selection mechanisms (probably because the current services don't
need it) to split the traffic. They make the calls on 3G not WLAN :) so
think about when VoIP is really deployed over 3G (LTE), they will have to
distinguish between those two interfaces and split traffic.

On the battery issue, yes of course but a few years ago those smart phones
needed to be charged every few hours, now they improved. My laptop battery
lasts 5-6 hours, which is an improvement. So these things change over
time. 

>But, I Ack, there may be some terminals which may be using

=> :). Happy to contribute.

Hesham

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 05 Aug 2011 00:21:08 -0700

Hello Hesham,

Long time no see...

To your point:

> lasts 5-6 hours, which is an improvement. So these things change over

Assume, just for a moment, there were a handover method requiring
only a single radio interface to be powered up at any one time, that
had roughly equal performance as handover algorithms which relied on
multiple radio interfaces being powered up.

In that case, I think it would be considerably preferable to
make use of the single-radio algorithm.

Excellent performance with single-radio devices is quite possible,
and we would practically already be there except for politics or,
(less likely but plausible) simply a matter of inertia.  Certainly
possible for good VoIP, almost certainly for interactive video on
4G networks <--> WLAN.  We were showing smooth VoIP handovers
almost ten years ago with 802.11b, and with SFF-based preregistration
in 4G networks we could do far better than that now (I recently
submitted a draft about this).

How to get it standardized in LTE seems to be a puzzle of monumental
proportions.  Perhaps if the end users realized how much better
their service could be, and started demanding it, things would
progress.  In the meantime, they'll get slow, battery-wasting
handovers to WLAN that do not even preserve IP addresses, much
less offer session continuity.  And the operators will have to
purchase unbelievably complicated equipment to even enable that
level of service.

I'd like to see the IETF start offering solutions that
have an easier evolutionary path towards deployment.
http://www.psg.com/~charliep/txt/ietf81/alt_mext/MIPv6_for_4G.pptx

[note I renamed that file, there was a typo in the previous name]

Regards,
Charlie P.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 05 Aug 2011 20:16:00 +1000

Hi Charlie,

>Long time no see...

=> Likewise! 

>make use of the single-radio algorithm.

=> Sure. I think we got two topics wrapped up in the same thread, I was
referring to multiple radio interfaces using different technologies. But I
agree with you that you can get good performance without make before break
handover. 

>submitted a draft about this).

=> Absolutely, I've done similar experiments on WLAN and still do in fact
and I agree. And did the same with 3G and you're right, it's all politics
that's stopping this. Luckily for me I'm not in the middle of these
politics anymore :)

>purchase unbelievably complicated equipment to even enable that

=> Forget about average users demanding proper IP networks, some operators
tried that and failed. Unfortunately the "getting it into LTE" part is not
fun. The fun part is making it work and the rest is...well you know. But
it might be worth giving LTE a unified IETF solution for mobility instead
of re-dressing GTP in IP (PMIP) and then getting it rejected anyway. I
didn't like that approach, but that was a long time ago.

>http://www.psg.com/~charliep/txt/ietf81/alt_mext/MIPv6_for_4G.pptx

=> Nice plug :), but I don't see the relation to the single Vs multiple
radio discussion.

Hesham