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

Re: [802.21] question on MIH event subscription



Yoshi,

I misunderstood your original question. I was thinking about the IS
client side.

Yoshihiro Ohba wrote:
> Hi Qiaobing,
> 
> It seems there is some misunderstanding.  
> 
> MIH_Get_Information.indication is supposed to be generated on the IS
> server side when receiving an MIH_Get_Information Request message from
> the IS client.  
> 
> On the IS client side, after it issues an MIH_Get_Information.request
> primitive, it is waiting for an MIH_Get_Information.confirm primitive
> for which subscription is not needed because confirm primive is
> synchrised with request primitive.

Yes, the .confirm and .request are always bound. There should be no
problem on the client side.

> 
> So I guess you are talking about multiple MIH users on the IS server
> side.  But, I don't see a need for handling multiple MIH IS users on
> the IS server, which makes me think that event subscription is not
> needed to receive MIH_Get_Information.indication.

It is still possible that we will face the same dispatching problem on
the IS server side, since you may have multiple MIH Users above the
MIHF, with one of them the IS server application. Keep in mind that an
MIHF is supposed to have no knowledge of the type of application of a
particular MIH User, i.e., to the MIHF all MIH Users above look the same
and it has no way to know whether a given MIH User is an IS server or not.

So the MIHF will still need a way to know which MIH User(s) should
receive an MIH_Get_Information.indication when the MIHF receives an
MIH_Get_Information Request message. *When we write the spec*, the most
elegant and clean way is to just follow the same consistent event
subscribe/notify model. Inside your implementation, however, you can
always choose to code the subscription as an default behavior which
happens implicitly when you IS server application starts.

regards,
-Qiaobing

> 
> What do you think?
> 
> Yoshihiro Ohba
> 
> 
> On Mon, Mar 05, 2007 at 01:11:54PM -0600, Qiaobing Xie wrote:
>> Hi, Yoshi,
>>
>> I would think so. On the surface it may seems to be an inconvenience
>> (one more step for the IS client). However, if you think about the
>> actual implementation, it is a big help:
>>
>> - You (as the local MIHF) generate a MIH_Get_Information.indication when
>> you receive a MIH_Get_Information response from a peer MIHF.
>>
>> - If you only have one MIH User above you, it is quite simple - you
>> invoke the MIH_Get_Information.indication to that MIH User.
>>
>> - But it becomes interesting if you have more than one MIH Users above
>> you. You have the following options:
>>   1) invoke a separate MIH_Get_Information.indication to each one of
>> them. But this could be very unnecessary since some of your MIH Users
>> may have nothing to do with Info Service.
>>   2) invoke the MIH_Get_Information.indication to the MIH User who
>> originally initiated the IS query - this is a much better design. The
>> only limitation is that you will not be able to have one MIH User as the
>> querier and different MIH User as the IS response handler.
>>   3) use event subscription and only invoke
>> MIH_Get_Information.indication to whichever MIH User(s) who has
>> subscribed the event.
>>
>> To me 1) is unacceptable, 2) is ok, 3) is both efficient and flexible
>> and consistent with event subscription/notify model.
>>
>> And we really want, we can even combine 2) and 3) - if no one subscribes
>> the event, then we dispatch a MIH_Get_Information.indication to the
>> original querier.
>>
>> regards,
>> -Qiaobing
>>
>> Yoshihiro Ohba wrote:
>>> Hi Qiaobing,
>>>
>>> I am a slow starter to follow this thread :)
>>>
>>> What about MIH_Get_Information indication for Information Service?  Is
>>> it also considered as an MIH event and event subscription is needed
>>> for it?  
>>>
>>> Yoshihiro Ohba
>>>
>>>
>>> On Thu, Mar 01, 2007 at 11:40:22AM -0600, 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
>>>>
>