Re: [802.21] Discussion on Information Service
What I am a little frustrated (and probably I am not the only one who
feels a little frustration) is the lack of progress in 802.21 in
general. And I think the root cause of this is due to a lack of focus
(overly ambitious) and the absence of a clear schedule or milestones
(phase1 - scope/deliver date, phase2 - scope/deliver date, ...).
There is really nothing wrong with making 802.21 into as general a
solution as possible (e.g., for "any mobility protocol", support
"handover between any media types", deployable in "any network type",
"in any device", ...) But in terms of engineering this is a very high
goal, a grand vision which I don't believe we can achieved in a single step.
We must have a phased plan - we must break this grand goal into smaller
tasks, prioritize each tasks, and set milestones. For example, phase 1
may give us a limited solution (only cover a few cases; but not exactly
the "any for any" solution some of us are talking about), but we must
make sure it achievable within a predictable time frame. Then, phase 2
will get us one step closer to the "any-for-any" vision, and so on.
Right now I don't see that happening.
regards,
-Qiaobing
Olvera-Hernandez, Ulises wrote:
> 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.
>