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

RE: [802.21] question on MIH event subscription



So what you are saying is, if the MME(MIH user) in the network is
servicing, say, 1 million subscribers on the box, it should make 1
million event subscriptions to receive ind from MIHF for each user?
Remote events are okay since you are requesting from a specific user but
why for local? Why should 802.21 spec mandate this?

In general, if there is no impact on the remote interface, there is no
reason to create specification overhead by these definitions.
Implementations have flexibility to choose their own mechanisms to get
the ind/cfm from the MIHF. If the specification is unclear regarding
this, we can create a small section to dicuss how ind/cfm from req/resp
respectively can be handled with MIH users and provide some guidelines.

I don't see much benefit in defining these as MIH events. Especially
since this may lead to reorganizing the whole draft by moving ind to the
events section or by some other means. This will hurt the overall draft
readability (i.e if any one tries, jk).

Regards,
Srini

-----Original Message-----
From: ext Qiaobing Xie [mailto:Qiaobing.Xie@MOTOROLA.COM] 
Sent: Thursday, March 01, 2007 3:46 PM
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] question on MIH event subscription

Vivek,

I fully agree with you here. I will try to capture this in a
contribution.

regards,
-Qiaobing

> [Vivek G Gupta]
> Another point to note:
> Some events such as MIH_Link_Going_Down can be both local or remote.
> When subscribing for this event the MIHF User may need to indicate if 
> it is interested in receiving this event that originates from local 
> MIHF only or from remote MIHF as well...
> The MIHF User does this by specifying the appropriate 
> DestinationIdentifier (local MIHF-ID or remote MIHF-ID) in the
request.
> Also if the MIHF_User is interested in receiving both local and remote

> events of a particular type it needs to make multiple invocations to 
> MIH_Event_Subscribe (one for local events and one for each remote MIHF

> that it is interested in receiving remote MIH events from...).
> 
> We could include some of the above explanation in the description of 
> this primitive.
> 
> Best Regards
> -Vivek
>