Subject: [seamoby] Re: draft-brain-seamoby-terms-00.txt

From: Jukka Manner <[email-masked]>
Date: Thu, 1 Feb 2001 13:59:33 +0200 (EET)

Gary,

	Here are some (late) answers to your comments. I copy this to the main
Cmoby list to raise more discussion on the terminology of the draft.

	Regards,

	Jukka

On Thu, 18 Jan 2001, Gary Kenward wrote:

> Overall, I liked this draft, and the clarity and logic of the definitions.
> It goes beyond what we need for the CT problem statement, and so we
> must be cautious not to rat-hole on issues such as paging. Hopefully,
> appropriate selections will be made in the problem statement draft
> that Henrik is leading.

	The draft was intended for the whole Seamoby WG, so part of it is
truly not needed in CT discussions. Hopefully the whole WG will benefit
from it.

>
> Some specific comments/concerns:
>
> p5: section 2.2.2, Layer 2 handovers are not necessarily intra-technology. I
> have
> misplaced the announcement, but at least one company is working on dual mode
> devices that will switch between Bluetooth and 802.11 without involving the
> IP layer.

	True. Perhaps we should then just change "necessarily" to "typically".

>
> p5: section 2.2.2, I did not understand the discussion on Horizontal and
> Vertical handover, and in particular how these definitions mapped onto the
> architecture. I'm probably missing some key IETF nomenclature here, but if you
> would help
> me out, and explain the relationship between Horizontal and Vertical
> handover
> and inter- and intra- AR handover. If there is no relationship, then one of
> the
> definitions would seem to be redundant.
>

	We try to see the handover event from the IP POV. When the interface on
the IP layer does not change, we can think that a pure layer 2 handover
happened, which remained (partially) unnoticed at the IP layer. This was called
horizontal. When the network interface clearly changes at the IP layer, we
called this vertical handover. The definitions come from discussions on what to
call handovers between different link layers. In future wireless communications,
a MH can do handovers from UMTS to GPRS to blue tooth to WLAN to
any-network-you-like. Previously those were called vertical and horizontal
(change of link layer vs. no change in link layer). We tried to adopt those and
look at them from the IP POV.

	The handover terms defined in 2.2.1 and 2.2.2 are related to the context
of discussions. They define somewhat similar handovers, but for clarity and to
provide less room for misunderstanding, we have defined that many.

In the definition of "Horizontal" we must replace "OAR and NAR" with "AN".

> p6: I do not agree that a planned handover is generally a result of backward
> handover. The definition of planned handover does not suffer if this
> sentence
> is removed.

Should we say that "planned assumes backward" - would that be enough? I'm not
sure whether a NAR can be chosen and be active to initiate the handover.
Wouldn't choosing a NAR be part of the handover procedure?

> p6: "planned" vs. "unplanned" don't work for me. they have a connotation of
> long term, slow. I'm not sure why you chose not to use "proactive" and
> "reactive",
> and introduced "planned" and "unplanned" - the latter terms don't really add
> to the meaning. (one could be trite and say that a "reactive" handover could
> be planned).

To us this was a matter of taste. In the "literature", they are used
synonymously.

> p7: I am not comfortable with the definition of Seamless, in that if it is
> really simply
> the combination of smooth and fast, then it is already being done in MIP. I
> see
> Seamless as being handover with no (discernable) drop in QoS. This is both
> semantically and practically different from smooth+fast.

Actually, if we then start using "seamless", we have to specify whether we
mean "mobileip-seamless" or "seamoby-seamless" because the term has a
"well-known" meaning in mobileip.

We would assume that "being done in MIP" means "being tackled in mobileip WG",
i.e., refers to the fast handover proposals. (nevertheless, the fact that
something is being done in mobileip means extensions to MIP that are not
necessarily straightforwardly applicable to seamoby)

Would we need another handover type then to include the idea of supporting QoS.
So, a "QoS (and/or context) aware" handover?

> p.7: You have introduced the concept of "context aware". I don't think we
> need yet
> another handover type. In my mind, context aware was part of seamless. Now,
> given your definition of seamless, yes, there is context that goes beyond
> smooth+fast,
> and indeed goes beyond sustained QoS. Of course, we can define SeaMoby to be
> seamless + context aware, but now we have a 5 types of handover (including
> the
> non-smooth, non-fast, non-context aware case). Would it not be better to
> define
> seamless as being context aware? Or, even better, as being context
> sustaining?
>

I can see that we have two types of definitions for seamlessness:

"Cmless"=seamless+context+everything

or

"Cmless"=fast+no-packet-drops

Since the MIP people have already a definition for seamless, I don't think we
should make a new one, but perhaps define a new type that includes the notion of
sustaining the QoS. Would "QoS (aware) handover" be a bad term?

> p8: I don't want to open a discussion of paging on this mailing list, so as
> a short note
> to be taken to the paging mailing list, I don't believe that paging itself
> should do all
> that you imply. There should be an intermediate stage between a paging
> wake-up and
> establishment of a SAR.

True. But I'm not the right person to comment on that issue. Anyone want to add
more insight to this?

>
> p8:, section 2.5: The distinguishment you make between user and personal
> mobility
> seems to have more to do with whether push applications are possible. From
> the appendices,
> I gather that the definition came from the telecom arena, and is biased (or
> limited)
> accordingly. Also, the essence of this definition seems to be tracking of
> the user, which
> is outside the scope of SeaMob.

Yes, we tried to emphasize that these are defined in order to be able to
describe what is not in scope (L2 handover and similar might also be augmented
with such remarks).

> Regards
> Gary

---

From: "Phil Neumiller" <[email-masked]>
Date: Thu, 1 Feb 2001 08:28:09 -0600

How about HIDDEN handover?  You are correct.  Seamless is already overloaded
all over the place.  I like HIDDEN handover because it conveys what we are
trying
to do, i.e. have no user noticeable changes during handovers.  The handover
is also
"hidden" from MIP so it is like a two edged sword. Cool acronym too: HiHo,
HiHo...
Alternatives could be

Invisible Handover ++
Transparent Handover 0
^
 |
Isn't English great
 |
V
Opaque Handover --
Imperceptible Handover +
Concealed Handover +++

Thanks,

Phil
----- Original Message -----
From: "Jukka Manner" <[email-masked]>

---

From: Jukka Manner <[email-masked]>
Date: Thu, 1 Feb 2001 16:55:58 +0200 (EET)

I like your reasoning... HiHo... :)

	However, even though the "HiHo" sounds cool, "transparent" handover
might be more correct, and dull. An additional question rose about to whom is
the transparent HO seamless:

	A HiHo handover deals mainly with QoS, so to an application and its
flows a HiHo should not be seen. But if a HiHo is also a Vertical handover and
the IP layer's network interface changes, ie. a HO from a 3G network to a WLAN,
the HO is noticed, at least the user will see this.

	So, I guess a HiHo or a transparent HO (THO) is "seamless" from purely a
flow's POV.

	Jukka

---

From: Michael Thomas <[email-masked]>
Date: Fri, 2 Feb 2001 07:18:44 -0800 (PST)

> "hidden" from MIP so it is like a two edged sword. Cool acronym too: HiHo,

Phil,

While I might be persuaded that there are reasons
for a hidden handover, and whatever else comes of
this you may not claim Bashful as your HiHo name,
I think that hidden handoff places too much
emphasis on transparency. A mobile node may not
want to participate in transparent moves, but then
again it may very well want to control them or
know about them, even if the move only generates
localized signaling.  As such, I think that HiHo
is just a subset of the entire problem.

And with this, it's off to work I go.

	       Mike