Re: [802.21] question on MIH event subscription
Subir,
Subir Das wrote:
> Qiaobing,
> The reason I have quoted that text is that I do not find any MIH events
> in Table 4 that are different than Link Events listed in Table 3. Thus
> it indicates that MIH events are all pass-through. Now I see the text
> you have mentioned below. First of all, we need to fix the text. Also
> I remember our earlier discussion that we did not find any specific
> events that are exclusive for MIH. So my understanding was
> that MIH events are just pass-through events and MIH users subscribe
> for those events.
I would prefer to keep the fundamental MIH event definition (i.e.,
continue to allow MIHF originated events), even we do not have one
defined in Table-4 yet.
> Now coming to your suggestion on considering MIH.indication as event.
> I find it little confusing with the current terminology. So far we have
> kept primitives such as request/response and indication/confirm
> separate from events, commands and information service. On the other
> hand, we define 'Event Subscription' for subscription of events not
> for primitives. Also how multiple users will locally identify these
> primitives
> seems to me an implementation issue. Do we need to go that far and
> generalize it?
This is a good point. My initial comment on this topic is to address an
existing confusion: right now we have many MIH.indications defined in
section 7.6. Some of them need to do explicit subscription to get, while
others don't. I was trying to see if we can unify the handling of all
the MIH.indications in MIH_SAP.
regards,
-Qiaobing
>
> regards,
> -Subir
>
>
>
> Qiaobing Xie wrote:
>> Subir,
>>
>> ...
>>> I think you are saying that MIHF should generate events as
>>> well. This is not what we have in our current draft where it
>>> says "Events that are propagated by the MIH to the MIH
>>> users are defined as MIH Events" (page 38, L11).
>>
>> That (MIH events can originate from MIHF itself) has been my
>> understanding for a long time. In the draft, we have text explicitly
>> describing that. For example:
>>
>> [p-17, l-15]
>>
>> "5.3.1.1 Event origination
>>
>> Events may originate from the MIHF (MIH Events)... "
>>
>> [p-37, l-46]
>>
>> "Events that may be relevant to handover may originate from MAC, PHY
>> or MIHF ..."
>>
>> My read on the line you quoted (page 38, L11) is that it basically
>> says: link pass-thru events are defined as part of MIH Events. It does
>> not mean to say: MIH Events are only limited to link pass-thru events.
>>
>> regards,
>> -Qiaobing
>>
>>>
>>> regards,
>>> -Subir
>>>
>>> Qiaobing Xie wrote:
>>>> 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
>>>
>