RE: [802.21] question on MIH event subscription
If we do have to call them events, why just make it local? We can have
remote as well. Here is the use case, there is a previous event
subscription (not shown).
Regards,
Srini
MIH-user MIH-User
local | ^ ^
Req | | cfm | req.ind
V | req.ind |
MIHF -----------------------> MIHF
-----Original Message-----
From: ext Qiaobing Xie [mailto:Qiaobing.Xie@MOTOROLA.COM]
Sent: Friday, March 02, 2007 12:44 PM
To: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] question on MIH event subscription
Srini,
Please see my comments in-line.
Srinivas Sreemanthula wrote:
> 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?
Absolute not! The MME only needs to make one local subscription to its
local MIHF. For example, as an MME the MIH User may wants to handle all
HO candidate query messages arrived to its local node. Even though these
HO candidate query messages may come from 1 million UEs, all the MIH
User needs is a single subscription to its local MIHF for getting MIH HO
candidate query indication. Once that is done, every time a new HO
candidate query message is received by the local MIHF, regardless of
from which UE the message was originated, the local MIHF always notifies
the MME.
> Remote events are okay since you are requesting from a specific user
> but why for local? Why should 802.21 spec mandate this?
This is really nothing new. From very beginning we have been saying
that:
1) MIH events consist both pass-thru events originated from a lower
layer link and events originated within MIHF itself.
2) We have decided to use the subscribe/notify model for all MIH events;
These are all well established design points of our spec.
> 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.
Yeah, that's my intention. We really should clarify this and define MIH
events is a consistent way. And as you said, the implementation is free
to follow the spec if there is no external impact. But a consistent and
clear definition is important to the readability of the document.
> 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).
I don't see the need for re-organizing the document that much. Evey
.indication definition can stay where it is. Just adding the MIH
originated events to table 4 and maybe a few sentences will do it.
regards,
-Qiaobing
>
> 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
>>
>