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