Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices
Title: Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices
Hong-Yon Lach wrote:
From: Subir Das <subir@research.telcordia.com> <mailto:subir@research.telcordia.com>
Date: Thu, 20 Oct 2005 13:51:26 -0400
To: Hong-Yon Lach <hong-yon.lach@MOTOROLA.COM> <mailto:hong-yon.lach@MOTOROLA.COM>
Cc: <STDS-802-21@listserv.ieee.org> <mailto:STDS-802-21@listserv.ieee.org>
Subject: Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover
InformationServices (was: Re: CARD Discussion Query Discussion)
Hong-Yon Lach wrote:
I think it is not just about how dynamically the information database needs
to be updated, it is also about how dynamically the mobile terminal needs to
consult the information and how often its environment changes due to its
movement. I fail to envisage a system that is so deterministic that I can
take comfort to ignore timing issues.
I agree with you that how often mobile needs to contact the IS is
an important considertaion.
But what is that frequency? Do you envisage a system that requires
a query ~ msec while
performing the heterogeneous handover?
No, but the moment the mobile terminal feels that it needs the info, it will
expect to have it quickly (IMO).
Correct, but I would assume this will happen before the handover decision/network selection.
[hong-yon] Yes. But who knows how much time we have to get the information and make the decision to make a HO to avoid any disruption to service access due to mobility?
Let's say I have a completely wrong assumption of what IS is for. Based on
all these exchanges, I can only conclude that the IS provides a means to
query information from a rather static database; the use may be helpful but
is not required for the purpose of handover; it is not clear where and how
the database obtains the information; it is not clear whether the
information can already be obtained by existing means.
Are we not considering the heterogeneous environment here?
Existing systems may have such information
available but they cann't provide other network information. What
we are trying to provide here is a mean such
that user can query the network information not only for the
connected network but also for other networks.
Do you think such information is not required/helpful for
heterogeneous handover? The poplulation of
database is another area and as far as I understand this is out
of scope.
I did not say that such information is not needed; I said that for certain
HO and mobility management scheme IS may not be needed. That is, there are
other ways to get such information. One example is that such information
exchange can be (integral) part of the mobility management protocol with a
mobility manager overseeing the heterogeneous networks.
Yes, there are several ways one can collect such information but I don't know of any standard
method that exists today and existing mobility protocols can make use of it. Are not we trying
to standardize such a method? To me, your example mobility manager is similar to the
handover/policy/network selection engine that we all believe is needed along with the
existing mobility protocol to optimize the handover performance. Extending existing mobility
protocols to support such functionalities is not a good idea, IMO.
[hong-yon] I am not judging what is good or bad in HO and mobility management. 802.21 is supposed to facilitate HO and mobility management. There are still a lot of room of evolution and solutions for HO and mobility management. To make 802.21 useful, I think we should not assume what HO and mobility management should do IMO. I just gave one example, and I would not like to exclude any HO and mobility management schemes, which are out of scope of 802.21. If 802.21 wants to cater IS for those HO and mobility management schemes that do not require efficiency in information retrieval/transfer, this is fine but let’s be clear on the IS’s target applicability and not claim that it is needed by ALL kinds of HO and mobility management schemes.