Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
>>>
>