Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover InformationServices (was: Re: CARD Discussion Query Discussion)

[Hong-Yon Lach <hong-yon.lach@motorola.com>]

> From: Peretz Feder <pfeder@lucent.com>
> Organization: Lucent Technologies
> Date: Thu, 20 Oct 2005 10:41:01 -0400
> To: Hong-Yon Lach <hong-yon.lach@motorola.com>
> Cc: <STDS-802-21@listserv.ieee.org>
> Subject: Re: [802.21] [Mipshop] Re: Architectural Considerations for Handover
> InformationServices (was: Re: CARD Discussion Query Discussion)
> 
> 
> 
> On 10/20/2005 8:40 AM, Hong-Yon Lach wrote:
>> I have heard examples in which I would consider the information as dynamic,
>> such as the "neighbouring network/access points available that match ..."
> 
> neighboring info could change every few hours indeed, but wouldn't you agree
> it
> is considered static for an HO process that should be in the few msec range?
> 
Yes, I agree, provided that the terminal is not mobile. The information is
static from the network viewpoint, but I think the information would be
dynamic for a mobile terminal.

>> and examples in which the information is very static (does not change much
>> with time).
>> 
>> The dynamic nature of information, depending on the specific piece of
>> information, could be different according to deployment, and could change
>> over time.
> 
> Yes and even every few hours is good enough to be labeled static.
> 
Ditto. For the mobile terminal, the info is good enough as long as its
environment does not change. The network can be very static, but the moment,
I don't know when, the mobile terminal moves elsewhere it may experience a
different environment.

>> 
>> When IS is used in the preparation of handover, it would be nice to minimise
>> such preparation time, because the longer it is the more likely the risk of
>> losing current network coverage and making handover less seamless. Maybe IS
>> is not meant to be used in such context?
> 
> That is my understanding, which I expressed in many f2f meetings w/o much
> objection.
> 

OK, if this is what 802.21 wants. I have not taken any f2f discussion as
official decision on the requirements.

> 
> Anyway, it will be a good step
>> forward to know what we are assuming/doing/enabling and what we are not.
> 
> We are enabling the decision process, wherever it is located to be equipped
> with
> all the pertinent info for a HO proper decision. this includes policy,
> neighbors, provisioning, loading, etc.
> 

It is true if we assume that the IS fits the (e.g. timing and informational)
requirements of a HO and mobility management process. Yes, in certain HO and
mobility management schemes, such IS could be useful; in other cases, maybe
not. For those potential IS users, once it is clear what and how IS provides
information, it will become clearer whether IS can be used for their needs.
This is fine, IS will facilitate certain but not all HO needs; this is my
conclusion based on the education I have in this discussion/clarification.


>> 
>> 
>> Yoshihiro has given example about
>> 
>> 
>> 
>>> From: Peretz Feder <pfeder@lucent.com>
>>> Organization: Lucent Technologies
>>> Date: Thu, 20 Oct 2005 08:10:54 -0400
>>> To: Hong-Yon Lach <hong-yon.lach@motorola.com>
>>> Cc: <STDS-802-21@listserv.ieee.org>
>>> Subject: Re: [802.21] [Mipshop] Re: Architectural Considerations for
>>> Handover
>>> InformationServices (was: Re: CARD Discussion Query Discussion)
>>> 
>>> 
>>> 
>>> On 10/20/2005 5:00 AM, Hong-Yon Lach wrote:
>>> 
>>>> Apparently, we still have very different ideas in mind when we talk about
>>>> IS
>>>> concerning what it is. A lot of discussions so far concerns how it should
>>>> be
>>>> supported. Peretz, I think you pointed out the consequence that we can only
>>>> disagree about the assumption of IS.
>>> 
>>> We are not agreeing on its dynamic nature. The rest we do.
>>> 
>>> 
>>>> How IS is to be used and should be supported depends on what information IS
>>>> is dealing with. If we do not have consensus on the nature/type/purpose of
>>>> information to be coped with in IS, I don't see how 802.21 can produce a
>>>> requirement on IS and how  MIPSHOP knows what it is doing for IS.
>>> 
>>> IS is dealing with all the relevant info that can assist the HO decision. To
>>> assume that in a middle of a few msec hanodoff the IS DB can be queried for
>>> pertinent HO info. and exchange all of that over L3 is a very loaded
>>> assumption,
>>> as it assumes that the IS DB will be updated at such resolutions and its
>>> info
>>> be
>>> relevant to a a few msec process.
>>> 
>>> 
>>> Your bleak statement is not so black and white. IS info is relevant and can
>>> be
>>> very well defined but it is not dynamic in nature.
>>> 
>>> 
>>> 
>>> 
>>>> Cheers,
>>>> Hong-Yon
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> From: Peretz Feder <pfeder@LUCENT.COM>
>>>>> Organization: Lucent Technologies
>>>>> Reply-To: Peretz Feder <pfeder@LUCENT.COM>
>>>>> Date: Thu, 20 Oct 2005 01:03:18 -0400
>>>>> To: <STDS-802-21@LISTSERV.IEEE.ORG>
>>>>> Subject: Re: [802.21] [Mipshop] Re: Architectural Considerations for
>>>>> Handover
>>>>> InformationServices (was: Re: CARD Discussion Query Discussion)
>>>>> 
>>>>> On 10/18/2005 6:11 PM, Qiaobing Xie wrote:
>>>>> 
>>>>> 
>>>>>> Yoshihiro Ohba wrote:
>>>>>> ...
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> - In reality, 3GPP2 has XML-based method (e.g., XCAP) in its
>>>>>>> dependency list.
>>>>>> 
>>>>>> 
>>>>>> If I remember it right XCAP/XML is used there for maintaining the
>>>>>> address book/buddy list that sort of things. I can imagine that sort of
>>>>>> events only happen at most no more than a few times a day for any given
>>>>>> user and probably only happen when the user is NOT in a call. In
>>>>>> contrast, IS query/response likely will be part of the h/o call flow...
>>>>> 
>>>>> You are assuming IS is a dynamic information that can influence Handover
>>>>> per
>>>>> the
>>>>> IS query response. Many .21 members do not agree with this position. IS
>>>>> should
>>>>> be treated as static information that is provided to the HO decision
>>>>> entity
>>>>> in
>>>>> advance.
>>>>> 
>>>>> 
>>>>> 
>>>>>> regards,
>>>>>> -Qiaobing
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Yoshihiro Ohba
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>> 
>> 
>> 
>