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

RE: [802.21] SAP semantics



Title: Re: [802.21] SAP semantics

Peretz,

 

So if you are NOT proposing a new SAP then we don’t really need MIH_NET_SAP (even in abstract sense).

 

Besides the L2 transport primitives for different media are already covered by MIH_LINK_SAP.  We do not need another MIH_NET_SAP for that.

The only thing which remains are L3 transport facilities and these can be provided through socket API calls or some such implementation specific functionality.

I am not sure we need to introduce MIH_NET_SAP for that…as we are not defining these APIs in .21 specification.

 

Best Regards

-Vivek

 


From: Peretz Feder [mailto:pfeder@lucent.com]
Sent: Wednesday, September 06, 2006 4:52 PM
To: Gupta, Vivek G
Cc: STDS-802-21@listserv.ieee.org
Subject: Re: [802.21] SAP semantics

 

Vivek, pls see in line (red):

"The L2 transport functions are provided by media specific SAPs. The L3 transport functions may be provided by other higher layer services. I don’t see the need to introduce another SAP for these transport functions."
Pls. look at the attached, it is exactly what you are indicating here. The proposed MIH-NET-SAP is an explanation and illustration of what you have just described:

The L2 transport functions are provided by media specific SAPs.
In the attached pls note the media specific text

The L3 transport functions may be provided by other higher layer
That too is described in the mapping exercise. We are not proposing a new SAP, just map it properly to L2 and L3.

Peretz Feder

On 9/6/2006 5:00 PM, Gupta, Vivek G wrote:

Some comments below.

Best Regards

-Vivek

 


 Ajay Rajkumar wrote:

Hong-Yon,

I agree that SAP is defined to provide an abstraction between a service provider entity and a user entity.
Also, MIH protocol would be used to provide communication between the two MIHF entities.
The problem arises from the current text in the draft in Section 5.6

"Upper layers may directly send commands to MIHF. Similarly MIHF entity may also
send commands to another remote (peer) MIHF entity. Primitives corresponding to all these services
described above are within the scope of MIH_SAP."

[Vivek G Gupta]

This text can be updated. Below is a suggestion for the second part of this paragraph in section 5.6 (pg 29 of draft D01.09)

 

“The MIH_SAP and associated primitives provide the interface from MIHF to the upper layers of the mobility-management stack. Upper layers need to register with MIHF as users to receive MIHF generated events and also for link layer events that originate at layers below the MIHF but may be passed on to upper layers through MIHF. Upper layers may directly send commands to MIHF. Similarly MIHF entity may also send transport these commands and events to another remote (peer) MIHF entity. Primitives corresponding to all these services described above are within the scope of MIH_SAP. The L2 transport functions are provided by media specific SAPs. The L3 transport functions may be provided by other higher layer services.”

 

I don’t see the need to introduce another SAP for these transport functions.

This implies that MIH_SAP is being used both by the MIH User as well as MIHF to communicate with the remote entity, which is my view is incorrect.

[Vivek G Gupta]

MIHF does not use MIH_SAP. That notion is indeed incorrect.

The first sentence in paragraph above (copied below) illustrates that clearly as well.

“The MIH_SAP and associated primitives provide the interface from MIHF to the upper layers of the mobility-management stack”


Regards,
-ajay


 


Hong-Yon Lach wrote:

Salut all,

A SAP is defined to provide an abstraction of service between a service provider entity and its user entities in the local system. A protocol provides a specification of interactions and operations between “peer” entities in different (sometimes virtual) systems with well-defined PDUs exchanges over a communications transport.

If a local MIH-user needs a remote services by a remote MIHF, it makes its request to the local MIHF through the MIH SAP. The local MIHF determines that it needs the support of a remote MIHF, it thus performs the necessary operations with the remote MIHF using the MIH protocol. Upon the end of the MIH protocol operation, the local MIHF provides a response to the MIH-user via the MIH SAP.

An entity can initiate the execution of its function and/or protocol by many different triggers: timeout of a timer, request by its users, detection of certain system conditions, reception of a PDU from its peer, etc. The entity can initiate its function and/or protocol without going through its SAP. A SAP is not the only means to have its serving entity to initiate a function and/or protocol.

I hopes this addresses your concerns.

Cheers,
Hong-Yon