RE: [802.21] An issue regarding primitives!
Mathieu,
As per your suggestion we should update this section and further clarify this. We should take a look at figures 11-20 and update them in section 6.
Also it would be good to indicate that link layer primitives (events, commands etc.) are local only, and that the corresponding MIH events/commands can be remote as well.
BR,
-Vivek
> -----Original Message-----
> From: zze-Seamless PERESSE M ext RD-RESA-REN
> [mailto:mperesse.ext@rd.francetelecom.com]
> Sent: Wednesday, December 14, 2005 5:02 AM
> To: Gupta, Vivek G; STDS-802-21@listserv.ieee.org
> Subject: 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
> > >