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,

As i could interpret your query. ... Let me put on my words.
> - You (as the local MIHF) generate a MIH_Get_Information.indication when
> you receive a MIH_Get_Information response from a peer MIHF.

I have considered both the scenarios here.
1. When IS Server is asking about the ACRs information It request to all ACRs by issues an MIH_Get_Information.request
primitive
with out mentioning any template as payload. So ACRs give its information to IS Server by which IS Server populates its database.
2. When a hand set (PSS)or MIH User wants the information from IS Server it issues an MIH_Get_Information.request
primitive
with specified template. What ever be the data it wants from IS Server.

I think you are refering case 2 here. On top of case 2 your Question is if a PSS is having multiple MIH users (Like Fmipv6, MIP, xyz etc).
How to send the request and after receiving the response what will be the segregation point .
I think its a totally implementation issue .

You can associate the request of specified MIHF user with some sequence no.  and after receiving the response your can pass the respose to same thread who is waiting for response.

I think you need to separate both command and event processing as well as receiving mechanism. Use different queues. command will be synchronous.
and events are asynchronous and also having the highest priority.

Regards
----------------------------------------------------------------------
Anurag Uxa
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
( ) L&T Infotech Proprietary & Confidential
(+) L&T Infotech Confidential
( ) L&T Infotech Internal Use only
( ) General Business Information
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------




Yoshihiro Ohba <yohba@TARI.TOSHIBA.COM>

03/06/2007 01:15 AM
Please respond to
Yoshihiro Ohba <yohba@TARI.TOSHIBA.COM>

To
STDS-802-21@LISTSERV.IEEE.ORG
cc
Subject
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
> >>
> >
>

______________________________________________________________________


______________________________________________________________________