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
?
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..).
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.
-----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
?
just a clarification on the
LINK_EVENT_SOURCE parameter that is included in every Event
primitive:
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.