RE: [802.21] Discussion on Information Service
Qiaobing,
Thanks for your professional comments.
I believe we are saying mostly the same thing.
1) If the goal is too ambitious, let us determine the level we must
achieve.
2) I agree with you that mobility management technologies are constantly
evolving. However, there must be a foundation (i.e., basic set of
elements) that we can identify. Furthermore, 802.21 should also evolve
along with the technologies that it covers, unless the evolution itself
renders 802.21 obsolete.
3) I believe you bring a good point. Should 802.21 exclusively be
concerned with link layer information (e.g., Link availability) or
should it go further and attempt to provide higher layer content (e.g.,
neighboring information, network usage cost, node addressing
information)?
So far MIHF is defined as an entity that spans more than one layer, and
therefore able to interact with those layer to collect relevant
information. If we agree with this concept then we should also agree on
the scope of the information that needs to be provided.
You ask if we all know the needs, I would say, we have a pretty good
idea. We just need to agree on semantics and scope.
Regards,
Ulises
-----Original Message-----
From: Qiaobing Xie [mailto:Qiaobing.Xie@MOTOROLA.COM]
Sent: Monday, August 22, 2005 11:15 PM
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] Discussion on Information Service
Hi, Ulises,
Please see my comments in-line.
regards,
-Qiaobing
Olvera-Hernandez, Ulises wrote:
> ... So far my assumption is that 802.21
> will strive to provide, at least, any handover information that is not
> already covered amongst existing wireless technologies.
I'd say this is a very ambitious goal.
Firstly, mobility (handover) management is a hot topic in many stds
bodies (e.g., IETF, 3GPP, WiMax, etc.) and new ideas and ways for MM
emerge constantly. Some information that may seem irrelevant to handover
today may become relevant tomorrow. It would be very hard to clearly
identify such a set of handover information as you suggest above.
Secondly, even if we can identify such an information set, it may
consist of information from different layers and parts of the network.
Since 802.21 MIH has a particular architectural position of its own in
the stack (as shown in our various reference models), are we sure that
architecturally 802.21 MIHF is the right entity/mechanism to play the
role of the overall fetcher, aggregator, and deliverer of all handover
information?
Would it be more practical if we assume that central role of 802.21
MIHF, due to its architectural position, is the fetcher, aggregator, and
deliverer of *lower layer* (PHY, MAC) handover information across
different interfaces? In addition, **IF** some other network information
that is useful for handover AND is *convenient* to be handled by 802.21
MIHF, then we would consider to include it.
> If this is everyone's understanding, then this would mean that
although
> 802.21 might not be the sole provider of handover information, 802.21
is
> indeed the "piece of the puzzle that was missing".
> If we agree with this assumption, then we need to provide a
> comprehensive set of IE that can cover the existing needs.>
Do we all know what the "existing needs" are?
>
> Therefore, even after we agree that an IE is useful for
> handover, we have to ask ourselves why 802.21 is the right mechanism
to
> carry/provide this IE to the h/o decision logic.
>
> <(Ulises Olvera) We discussed this issue a while ago and I believe we
> agree that although some handover information might be available by
> other means (e.g., System Operator Codes, Network usage cost,
> Neighboring Maps, Signal Quality Indications,etc), providing a uniform
> interface towards 802.21/MIH users does add value. However I do agree
> that the selection of applicable IE needs to be justified, e.g., as
> suggested below, through explicit use cases. This will prove
> particularly important when is time to go to other standards bodies
and
> we try to justify why and how 802.21 can add value on top of the
> existing mechanism.
>
ditto.