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

RE: [802.21] LINK_EVENT_SOURCE ?



Title: Nachricht
Vivek,
 
comments below


De : Gupta, Vivek G [mailto:vivek.g.gupta@intel.com]
Envoyé : jeudi 15 décembre 2005 19:13
Ŕ : Kalyan Koora; zze-Seamless PERESSE M ext RD-RESA-REN; STDS-802-21@listserv.ieee.org
Objet : RE: [802.21] LINK_EVENT_SOURCE ?

Mathieu, Kalyan,

 

Some comments below.

 

Best Regards,

-Vivek

 


From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of Kalyan Koora
Sent: Thursday, December 15, 2005 9:05 AM
To: zze-Seamless PERESSE M ext RD-RESA-REN; STDS-802-21@listserv.ieee.org
Subject: AW: [802.21] LINK_EVENT_SOURCE ?

 

Hi Mathieu,

 

as far as I understood, it is the source ID from where the link event is generated.

 

I still have a feeling that there should be source and destination ID in all the primitivies.

Well, in some cases some IDs may not be needed, but i feel this is good to have.

This issume will become much more complex if we think of IS primitives.

[Vivek G Gupta]

Actually IS primitives may not be that bad at all (since there are not that many of them anyway..just a request and a response..).

 

Just a note: all the general primitivies of ES, CS, IS (not in section 7) look

like the same. I feel we have to modify them.

[Vivek G Gupta]

May be we should have a source and destination in all primitives and just use N/A (Not Applicable) when one of the parameter is not relevant.

However source and destination parameters are more applicable only for remote events/commands.

It may be getting difficult to have a generalized representation covering all cases for events and commands.

 

regards,

Kalyan

-----Ursprüngliche Nachricht-----
Von: zze-Seamless PERESSE M ext RD-RESA-REN [mailto:mperesse.ext@RD.FRANCETELECOM.COM]
Gesendet: Donnerstag, 15. Dezember 2005 17:10
An: STDS-802-21@listserv.ieee.org
Betreff: [802.21] LINK_EVENT_SOURCE ?

Hi all,

 

just a clarification on the LINK_EVENT_SOURCE parameter that is included in every Event primitive:

 

From the draft:

 

LINK_EVENT_SOURCE is defined as follows.

{Local Node, Remote Node}. Local and remote is referred with respect to origination of request

 

What does this mean ? Is it a list composed of "Local Node" and "Remote Node", is it an identifier, what is the purpose of this parameter

and how is it used in event primitives ?

[Vivek G Gupta]

With regard to support for remote link events this parameter was indicating whether the event originated at local node or remote node.
[[MP]] So you mean the LINK_EVENT_SOURCE parameter will just contain "local" or "remote", and will not specify any identifier ? 

Since we are considering making all link events local only, and have corresponding MIH events as local or remote, we could remove this parameter from all link layer primitives.
[[MP]] I agree, link events primitives are inherently "local"...

MIH Users receiving event notifications may need to know if a particular event originated on local MIH node or at some other remote end. From that perspective having this parameter in there helps satisfy this need.
[[MP]] Yes but  is it sufficient to indicate "local" or "remote". If the event is local then it is just fine, but for a remote event the MIH user may want the identifier (address) of the event source; for example a PoS could want to know the ID of UE that generated a particular event. I guess the source identifier will be embeded in the MIH PDU  anyway, so it easy to pass it to the MIH User as an event primitive parameter. If the MIH Event is local, then we can either put a local identifier in the source id parameter or a null value.

 

Also, we are currently talking about MIH capability discovery and registration on the ML. How will link event discovery and link event registration (primitives already in the draft) be integrated into the overall Capability Discovery and Registration processes respectively ?? Or will it be totally independent ?

[Vivek G Gupta]

When MIH Function receives request for MIH Capability discovery, the MIH function may use local link layer discovery primitives to discover appropriate link layer capabilities and send an appropriate response.
[[MP]] Yes I agree. Link Events map to MIH Events so it makes sense to do it this way. For registration I guess we can do the same...?

But more generally: we have a process that we call MIH Capability Discovery: there is a primitive in the draft called MIH_Capability_Discovery for that purpose: this will perform the discovery of available events and commands. The primitive description says the primtive can be generated by upper layers (MIH users) or the MIH Function. Why and how can it be generated by the MIH Function ? This is an MIH level primitive so the service provider is the MIH Function... I guess the only users of this primitive are upper layers by definition. However, we can use Link_Event_Discover to further discover link events and indicate their availabiltiy to the MIH users through MIH_Capability_Discover.confirm.

I guess flow diagrams would be needed for discovery as well.

  

Thanks a lot! 

Mathieu.