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