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

Re: [802.21] question on MIH event subscription



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.

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.

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