RE: [802.21] An issue regarding primitives!
Hi all,
-----Message d'origine-----
De : Gupta, Vivek G [mailto:vivek.g.gupta@INTEL.COM]
Envoyé : mercredi 14 décembre 2005 13:38
Ŕ : STDS-802-21@listserv.ieee.org
Objet : Re: [802.21] An issue regarding primitives!
> -----Original Message-----
> From: Kalyan Koora [mailto:kalyan.koora@benq.com]
> Sent: Wednesday, December 14, 2005 4:07 AM
> To: Gupta, Vivek G; STDS-802-21@listserv.ieee.org
> Subject: AW: [802.21] An issue regarding primitives!
>
> Hi Vivek,
>
> >The link events originate from the link layer and are intended for
> >MIH and do not have a destination identifier associated with them.
>
> That means for me, there are no "Remote" Link events. Did I understood
> it correctly?
[Vivek G Gupta]
Currently we have defined Remote link events as well in the draft (though it would be better to have all link events as local only and the corresponding MIH events as remote, to avoid having two sets of similar remote events).
MIH entities can register with peer MIH entities to receive remote link/MIH events. The link layer by itself has no knowledge about a link event being remote. From link layer perspective the event destination is always the local MIH Function. The local MIH Function determines whether to consume the event locally or package it and transport it to peer MIH Function entities as well, depending on specific event registration requests received from peer MIH-F entities.
[MP] So I guess we should update Figure 15 - Link Events Flow Model (page 37, section 6.1.4).
It shows the link event (the arrow tagged "remote events") going from the network PoA's MAC to the Client MAC, and then to MIH. The Link_Event.indication should not be on the Client side, but on the Network PoA side, from MAC to MIH.
Then a "Remote Event" arrow should go from the Network PoA's MIH to the Client's MIH.
Further, I don't think the Link_Event_Register.request/confirm remote messages should go from the client's MAC to the Network PoA's MAC, but rather from the Client's MIH to the PoA's MIH, and then there should be a local interaction between the PoA's MIH and the PoA's MAC, to register for the event.
I think my explanation is a bit confusing... Sorry about that...
By the way, in this figure, there is a primitive called Link_Event.request/response (Remote Event Generation),
And I guess we haven't defined this primitive yet...
The best thing to do to clarify all this would be to have 4 figures in section 6.1.4: Link Events Local, Link Events Remote, MIH Events Local, MIH Events Remote. Each of the figure should show the registration mechanism and the occurrence of an event.
>
> >The local MIH Function can determine
> >if these events need to be sent to remote/peer MIH entities or not
> >depending on remote/peer MIH registration for these events etc.
>
> Here is the place where I am not understanding, how can an MIHF
> dertermine this? on what basis?
[Vivek G Gupta]
MIH entities register with their peer MIH counterparts indicating the events they are interested in receiving notifications for. MIH Event Register/ MIH Event Deregister should take care of this. We need to expand on these primitives in current draft (version 4). On receiving this registration request a MIH-F entity may issue local Link Register Event request to receive appropriate link events.
>
> In draft 3, section 6.1.5, it is mentioned:
[Vivek G Gupta]
Please use draft version D00.04.
>
> "EventSource: is used to identify the event source entity where the
> event originated"
>
> I understand with this, that if a registration has to be made by
> MIHF, then the destination to which the registration req. has to be
> sent by MIHF is "EventSource".
>
> Now let us assume that MIHF-A and MIHF-B sends a remote registraion
> to MIHF-C. In both cases MIHF-A and MIHF-B uses the same EventSource.
[Vivek G Gupta]
As part of this registration MIHF-C should get the ID and any other relevant details of MIHF-A and MIHF-B. We should explain this better in MIH Event Register/Deregister.
>
> If the event occures at MIHF-C, it has to send an indication to
> MIHF-A and MIHF-B. Where does MIHF-C gets the ID of A and B?
[Vivek G Gupta]
See above.
>
> In the above example, I can replace MIHF-A with USER-A and MIHF-B with
> USER-B. MIHF-C is the MIHF in a peer.
[Vivek G Gupta]
If MIHF-A is USER-A, then MIHF-C still sends the indication to peer MIHF entity which then sends an indication up the local stack to USER-A. MIH-F entities send remote messages only to peer MIH-F entities. The local MIH-F entity has to manage dispatching of messages to registered clients locally.
>
> Sorry for bothering you, but I feel I miss somthing here in
> understanding.
>
> > But all MIH_SAP primitives (commands) have a Destination Identifier
> > associated with them. Please refer to section
> > 7 for details on different MIH command related primitives.
>
> Yes, I agree with this and that is what I was pointing out with
> "discrepancy with the general primitive syntax for command".
> In this case we may have to extend the general syntax in section 6.2,
> draft 3 with CommandDestination parameter.
[Vivek G Gupta]
Yes. That appears correct. We need to update only the general set of primitives. However the discrepancy is only in section 6 and section 7 which has all the primitives seems ok.
>
>
> regards,
> Kalyan
>
> -----Ursprüngliche Nachricht-----
> Von: Gupta, Vivek G [mailto:vivek.g.gupta@INTEL.COM]
> Gesendet: Mittwoch, 14. Dezember 2005 11:55
> An: STDS-802-21@listserv.ieee.org
> Betreff: Re: [802.21] An issue regarding primitives!
>
>
> > -----Original Message-----
> > From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf
> > Of Kalyan Koora
> > Sent: Wednesday, December 14, 2005 2:15 AM
> > To: STDS-802-21@listserv.ieee.org
> > Subject: An issue regarding primitives!
> >
> > Hello All,
> >
> > while going through the draft, couple of questions raised in my mind
> > which I would like to discuss with you all.
> >
> > General Primitive Syntax
> > ------------------------
> > The general syntax of the primitives described in draft for ES and
> > CS contain a source ID and an Information/Result set.
> >
> > => What I miss here is destination ID (there are couple of advantages
> > with this, will explain in next point).
> [Vivek G Gupta]
> The current draft already seems to account for this.
> The link events originate from the link layer and are intended for MIH
> and do not have a destination identifier associated with them. The
> local MIH Function can determine if these events need to be sent to
> remote/peer MIH entities or not depending on remote/peer MIH
> registration for these events etc. But all MIH_SAP primitives
> (commands) have a Destination Identifier associated with them. Please
> refer to section 7 for details on different MIH command related primitives.
>
> >
> > If you check the MIH-Poll, which is listed as MIH Command, then the
> > primitive described for it is having a source and destination ID.
> > This is in discrepancy with the general primitive syntax for command
> > service.
> >
> [Vivek G Gupta]
> Which MIH commands do not have Destination Identifier listed in section 7?
>
> > Couple of advantages in having both the IDs
> > -------------------------------------------
> > * Having both the IDs (source & destination) in a primitive will
> reduce
> > the overhead of defining a same event/command once as local and
> > once as remote. I think, this is also pointed by couple of us.
> >
> > * That is, all the events going from L2 to MIH and from MIH to HL are
> > treated as local events. And at the same time, all the commands
> going
> > from HL to MIH and MIH to L2 are treated as local commands.
> >
> > * MIHF decides on receiving the events/commands from other layers,
> > depending on the destination ID, to treat them either as local
> > or remote events/commands. It then forwards them to local receiver
> > or to remote MIHF with the help of external transport protocol.
> >
> > NOTE: The remote events/commands are exchanged ONLY between the
> > MIHF peers and not between the other layers.
> >
> > I would like to know your opinions.
> >
> > with best regards,
> > Kalyan
> >