答复: [802.21] question on MIH event subscription
Hi Qiaobing,
What you dig out is really a big issue and the solution sounds good. But I
am wondering if the MIH user forgets to subscribe some events, maybe
handover cannot be completed since the handover flow consists of quite a few
handover messages(and their corresponding .indication events), lack
subscription of any one of these events will cause the handover flow to be
aborted.
Best Regards,
Junxiang Guo
-----邮件原件-----
发件人: Qiaobing Xie [mailto:Qiaobing.Xie@MOTOROLA.COM]
发送时间: 2007年3月2日 5:05
收件人: STDS-802-21@listserv.ieee.org
主题: Re: [802.21] question on MIH event subscription
Hi, Vivek,
Gupta, Vivek G wrote:
> Hello Qiaobing,
>
> I am fine with your proposal.
> So should MIH_MN_HO_Candidate_Query.indication (and all such other
> indication messages) be included in Table-4 as well?
Yes. Right now all the MIH events captured in Table-4 a pass-thru link
events; None of the MIH events originated *within* MIHF (including
MIH_MN_HO_Candidate_Query indication and all such other indications) are
captured in Table-4 and I firmly believe they should be captured in Table-4.
>
> Also even though this is an MIH event, this is a local-only MIH event
> (one that would never go over the medium). So we don't need to define
> any MIH protocol messages for these events.
Precisely! But they should follow the same subscription/notification model
as the link-pass-thru MIH events.
regards,
-Qiaobing
>
> Kind Regards
> -Vivek
>
>> -----Original Message-----
>> From: Qiaobing Xie [mailto:Qiaobing.Xie@motorola.com]
>> Sent: Thursday, March 01, 2007 12:45 PM
>> To: Gupta, Vivek G
>> Cc: STDS-802-21@listserv.ieee.org
>> Subject: Re: [802.21] question on MIH event subscription
>>
>> Hi, Vivek,
>>
>> ...
>>> However consider the case of following primitive:
>>> MIH_MN_HO_Candidate_Query.indication
>>>
>>> It is an example of MIH_xxx.indication type of primitive, however I
> am
>>> not sure if this is the case of an MIH event. As such MIH Users may
> not
>>> need to subscribe for this.
>> When a MIH_MN_HO_Candidate_Query request message arrives from MIHF_A
> to
>> MIHF_B, the arrival of the message will trigger a
>> MIH_MN_HO_Candidate_Query indication from MIHF_B to its MIH User.
>> This part seems quite clearly defined in the spec now.
>>
>> But what if there are multiple MIH Users above MIHF_B? They may be
> very
>> different applications and it is possible that not all of them are
>> interested in getting (or designed to handle)
> MIH_MN_HO_Candidate_Query
>> indications.
>>
>> This can be neatly solved by requiring subscription to receiving
>> MIH_MN_HO_Candidate_Query indications.
>>
>> Of cause, the downside is that if no one at MIHF_B subscribes for
>> MIH_MN_HO_Candidate_Query indication, the message is going to be
>> basically ignored by MIHF_B. But that seems ok - just as if some one
>> sent the message to a wrong destination.
>>
>> regards,
>> -Qiaobing
>>
>>> Best Regards
>>> -Vivek
>>>
>>>> -----Original Message-----
>>>> From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf
> Of
>>>> Qiaobing Xie
>>>> Sent: Thursday, March 01, 2007 9:40 AM
>>>> To: 802.21 List
>>>> Subject: question on MIH event subscription
>>>>
>>>> All,
>>>>
>>>> I think the following statements should be true:
>>>>
>>>> - any MIH .indication primitive shall be considered an MIH event
>>>> - an MIH User shall be notified about an MIH event only that User
> has
>>>> explicit subscription for the event
>>>>
>>>> Therefore, we will need to accept the following scenario as
> perfectly
>>>> normal:
>>>>
>>>> 1. An MIH User invokes MIH_Configure_Link and sets some threshold
> in
>>>> order to get a link report when that threshold is crossed;
>>>>
>>>> 2. But he forgets to (or intentionally does not) explicitly
> subscribe
>>>> MIH_Link_Parameters_Report.indication event;
>>>>
>>>> 3. When the event happens, the User will not get the indication.
>>>>
>>>> My reasoning is that one may want to build a User whose
> responsibility
>>>> is just to set link thresholds but the responsibility for receiving
>>> and
>>>> processing the events are delegated to a different User (or Users).
>>> The
>>>> latter will subscribe for the event but not the former.
>>>>
>>>> regards,
>>>> -Qiaobing
>