5 Service primitives and functions

04.653GPPGeneral Packet Radio Service (GPRS)Mobile Station (MS) - Serving GPRS Support Node (SGSN)Release 1999Subnetwork Dependent Convergence Protocol (SNDCP)TS

5.1 Service primitives

This subclause explains the service primitives used for communication between the SNDCP layer and other layers. See also 3GPP TS 04.07 [4] to get an overall picture of the service primitives. Figure 3 illustrates the service access points through which the primitives are carried out.

Figure 3: Service Access Points provided and used by SNDCP

5.1.1 SNDCP service primitives

The primitives provided by the SNDCP layer are listed in Table 1.

Table 1: SNDCP layer service primitives

Generic Name

Type

Parameters

Request

Indication

Response

Confirm

SNDCP User (PDP or the SGSN Relay)  SNDCP

SN-DATA

X

N‑PDU, NSAPI, N‑PDU Number

SN‑DATA

X

N‑PDU, NSAPI

SN‑UNITDATA

X

X

N‑PDU, NSAPI

SN‑XID

X

X

Requested SNDCP XID Parameters

SN‑XID

X

X

Negotiated SNDCP XID Parameters

5.1.1.1 SN‑DATA.request

Request used by the SNDCP user for acknowledged transmission of N‑PDU. The successful transmission of SN‑PDU shall be confirmed by the LLC layer. The SN‑DATA.request primitive conveys NSAPI to identify the PDP using the service. N‑PDU Number, if present, indicates the N‑PDU number previously assigned to this N‑PDU.

NOTE: An N‑PDU number may have been assigned to an N‑PDU by the old SGSN before an inter-SGSN routeing area update.

5.1.1.2 SN‑DATA.indication

Indication used by the SNDCP entity to deliver the received N‑PDU to the SNDCP user. Successful reception has been acknowledged by the LLC layer.

5.1.1.3 SN‑UNITDATA.request

Request used by the SNDCP user for unacknowledged transmission of N‑PDU. The SN‑UNITDATA.request primitive conveys NSAPI to identify the PDP using the service.

5.1.1.4 SN‑UNITDATA.indication

Indication used by the SNDCP entity to deliver the received N‑PDU to the SNDCP user.

5.1.1.5 SN‑XID.request

Request used by the SNDCP user at the initiating entity to deliver the list of requested XID parameters to the peer entity.

5.1.1.6 SN‑XID.indication

Indication used by the SNDCP entity to deliver the list of requested XID parameters to the SNDCP user.

5.1.1.7 SN‑XID.response

Response used by the SNDCP user to deliver the list of negotiated XID parameters to the peer entity.

5.1.1.8 SN‑XID.confirm

Confirm used by the SNDCP entity to deliver the list of negotiated XID parameters to the SNDCP user.

5.1.2 Service primitives used by SNDCP layer

The SNDCP layer uses the service primitives provided by the SM sublayer and the LLC layer (see Table 2). SM is specified in 3GPP TS 04.08 [5] and LLC in 3GPP TS 04.64 [6].

Table 2: Service primitives used by the SNDCP entity

Generic Name

Type

Parameters

Request

Indication

Response

Confirm

SNDCP  LLC

LL‑RESET

X

TLLI

LL‑ESTABLISH

X

TLLI, XID Requested

LL‑ESTABLISH

X

TLLI, XID Requested, N201-I, N201-U

LL‑ESTABLISH

X

TLLI, XID Negotiated

LL‑ESTABLISH

X

TLLI, XID Negotiated, N201-I, N201-U

LL‑RELEASE

X

TLLI, Local

LL‑RELEASE

X

TLLI, Cause

LL‑RELEASE

X

TLLI

LL‑XID

X

TLLI, XID Requested

LL‑XID

X

TLLI, XID Requested, N201-I, N201-U

LL‑XID

X

TLLI, XID Negotiated

LL‑XID

X

TLLI, XID Negotiated, N201-I, N201-U

LL‑DATA

X

TLLI, SN‑PDU, Reference, QoS Parameters, Radio Priority

LL‑DATA

X

TLLI, SN‑PDU

LL‑DATA

X

TLLI, Reference

LL‑UNITDATA

X

TLLI, SN‑PDU, QoS Parameters, Radio Priority, Cipher

LL‑UNITDATA

X

TLLI, SN‑PDU

LL-STATUS

X

TLLI, Cause

SNDCP  SM

SNSM-ACTIVATE

X

TLLI, NSAPI, QoS profile, SAPI, Radio Priority

SNSM-ACTIVATE

X

TLLI, NSAPI

SNSM-DEACTIVATE

X

TLLI, NSAPI(s), LLC Release Indicator

SNSM-DEACTIVATE

X

TLLI, NSAPI

SNSM-MODIFY

X

TLLI, NSAPI, QoS Profile, SAPI, Radio Priority, Send N‑PDU Number, Receive N‑PDU Number

SNSM-MODIFY

X

TLLI, NSAPI

SNSM-STATUS

X

TLLI, SAPI, Cause

SNSM-SEQUENCE

X

X

TLLI, NSAPI, Receive N‑PDU Number

SNSM-STOP-ASSIGN

X

TLLI, NSAPI

5.1.2.1 LL‑RESET.indication

Indication used by the LLC layer in the SGSN to indicate to the SNDCP layer that the Reset XID parameter has been transmitted, and by the LLC layer in the MS to indicate to the SNDCP layer that the Reset XID parameter has been received.

Upon receipt of the LL‑RESET.indication, the SNDCP layer shall:

– treat all outstanding SNDCP  LLC request type primitives as not sent;

– reset all SNDCP XID parameters to their default values;

– in the MS, for every NSAPI using unacknowledged peer-to-peer LLC operation, set the Send N‑PDU number (unacknowledged) to 0; and

– for every NSAPI using acknowledged peer-to-peer LLC operation, enter the recovery state and suspend the transmission of SN‑PDUs until an SNSM-SEQUENCE.indication primitive is received for the NSAPI. In the SGSN the SNDCP layer shall re-establish acknowledged peer-to-peer operation for the affected SAPIs in the LLC layer.

5.1.2.2 LL‑ESTABLISH.request

Request used by the SNDCP layer to establish or re-establish acknowledged peer-to-peer operation for a SAPI in the LLC layer. XID Requested is used to deliver the requested SNDCP XID parameters to the LLC layer.

5.1.2.3 LL‑ESTABLISH.indication

Indication used by the LLC layer to inform the SNDCP layer about establishment or re-establishment of acknowledged peer-to-peer operation for a SAPI in the LLC layer. XID Requested is used to deliver the requested SNDCP XID parameters to the SNDCP layer. In case of a re-establishment, all NSAPIs mapped to the affected SAPI shall enter the recovery state, and all buffered N‑PDUs (i.e., the ones whose complete reception has not been acknowledged and the ones that have not been transmitted yet) shall be transmitted starting with the oldest N‑PDU when the link is re-established. Also all compression entities using acknowledged peer-to-peer LLC operation on this SAPI are reset.

5.1.2.4 LL‑ESTABLISH.response

Response used by the SNDCP layer after reception of the LL‑ESTABLISH.indication. XID Negotiated is used to deliver the negotiated SNDCP XID parameters to the LLC layer.

5.1.2.5 LL‑ESTABLISH.confirm

Confirmation used by the LLC layer to inform the SNDCP layer about successful initiation of acknowledged peer-to-peer operation for a SAPI in the LLC layer. XID Negotiated is used to deliver the negotiated SNDCP XID parameters to the SNDCP layer. In case of a re-establishment, all NSAPIs mapped to the affected SAPI shall enter the recovery state, and all buffered N‑PDUs (i.e., the ones whose complete reception has not been acknowledged and the ones that have not been transmitted yet) shall be transmitted starting with the oldest N‑PDU when the link is re-established. Also all compression entities using acknowledged peer-to-peer LLC operation on this SAPI are reset.

5.1.2.6 LL‑RELEASE.request

Request used by the SNDCP layer to release acknowledged peer-to-peer operation for a SAPI in the LLC layer. The Local parameter indicates whether the termination shall be local (see 04.64 for details).

5.1.2.7 LL‑RELEASE.indication

Indication used by the LLC layer to inform the SNDCP layer about termination of acknowledged peer-to-peer operation for a SAPI in the LLC layer. The Cause parameter indicates the cause for the termination.

On receipt of LL‑RELEASE.indication, compressed N‑PDUs queuing to be forwarded to the affected SAPI are deleted from the SNDCP layer. Also all compression entities using acknowledged peer-to-peer LLC operation on this SAPI are reset.

5.1.2.8 LL‑RELEASE.confirm

Confirmation used by the LLC layer to inform the SNDCP layer about termination of acknowledged peer-to-peer operation for a SAPI in the LLC layer. On receipt of LL‑RELEASE.confirm, compressed N‑PDUs queuing to be forwarded to the affected SAPI are deleted from the SNDCP layer. Also all compression entities using acknowledged peer-to-peer LLC operation on this SAPI are reset.

5.1.2.9 LL‑XID.request

Request used by the SNDCP layer to deliver the requested SNDCP XID parameters to the LLC layer.

5.1.2.10 LL‑XID.indication

Indication used by the LLC layer to deliver the requested SNDCP XID parameters to the SNDCP layer.

5.1.2.11 LL‑XID.response

Response used by the SNDCP layer to deliver the negotiated SNDCP XID parameters to the LLC layer.

5.1.2.12 LL‑XID.confirm

Confirm used by the LLC layer to deliver the negotiated SNDCP XID parameters to the SNDCP layer.

5.1.2.13 LL‑DATA.request

Request used by the SNDCP layer for acknowledged transmission of an SN‑PDU. The SNDCP entity shall associate a reference parameter for each LL‑DATA.request. QoS Parameters in the SGSN includes precedence class, delay class, and peak throughput. QoS Parameters in the MS includes peak throughput. QoS Parameters is defined as part of the Quality of Service information element in 3GPP TS 04.08. Radio Priority is included only in the MS, and indicates the radio priority level to be used by RLC/MAC.

Acknowledged peer-to-peer LLC operation for the SAPI used shall be established using the LL‑ESTABLISH primitives, before the LL‑DATA.request may be used.

5.1.2.14 LL‑DATA.indication

Indication used by the LLC layer to deliver the successfully received SN‑PDU to the SNDCP layer.

5.1.2.15 LL‑DATA.confirm

Confirm used by the LLC layer to inform SNDCP layer about successful transmission of SN‑PDU. The primitive includes a reference parameter from which the SNDCP entity shall identify the LL‑DATA.request this confirmation was associated with. All buffered N‑PDUs whose complete reception is confirmed are deleted.

5.1.2.16 LL‑UNITDATA.request

Request used by the SNDCP layer for unacknowledged transmission of a SN‑PDU. Unconfirmed transmission shall be used by the LLC layer.

Acknowledged peer-to-peer LLC operation does not need to be established before unacknowledged transmission is allowed.

QoS Parameters in the SGSN includes precedence class, delay class, reliability class, and peak throughput. QoS Parameters in the MS includes peak throughput and reliability class. Reliability class indicates whether the LLC frame carrying the SN‑PDU shall be transmitted in protected or unprotected mode, and whether RLC/MAC acknowledged or unacknowledged mode shall be used. Radio Priority is included only in the MS, and indicates the radio priority level to be used by RLC/MAC.

5.1.2.17 LL‑UNITDATA.indication

Indication used by the LLC layer to deliver the received SN‑PDU to the SNDCP layer. There is no need for acknowledged peer-to-peer LLC operation for unacknowledged transmission of SN‑PDU.

5.1.2.18 LL‑STATUS.indication

Indication used by the LLC layer to inform SNDCP when an LLC error that cannot be corrected by the LLC layer has occurred. The Cause parameter indicates the cause of the failure.

On receipt of LL‑STATUS.indication, SNDCP shall inform the SM sub-layer by means of the SNSM-STATUS.request primitive.

5.1.2.19 SNSM-ACTIVATE.indication

Indication used by the SM entity to inform the SNDCP entity that an NSAPI has been activated for data transfer. It also informs the SNDCP entity about the negotiated QoS profile (see 3GPP TS 04.08), the SAPI assigned for this NSAPI, and, in the MS, the radio priority level to be used by RLC/MAC.

If the NSAPI activated uses the acknowledged peer-to-peer LLC operation, the NSAPI shall enter the recovery state.

Upon reception of the SNSM-ACTIVATE.indication from the SM sublayer, the SNDCP entity shall, if necessary, establish the acknowledged peer-to-peer LLC operation for the indicated SAPI. The establishment criteria and procedure are described in subclause 6.2.1.

5.1.2.20 SNSM-ACTIVATE.response

Response used by the SNDCP layer to inform SM entity that the indicated NSAPI is now in use and that the acknowledged peer-to-peer LLC operation for the indicated SAPI is established, if necessary.

5.1.2.21 SNSM-DEACTIVATE.indication

Indication used by the SM entity to inform the SNDCP entity that an NSAPI has been deallocated and cannot be used by the SNDCP entity anymore. All buffered N‑PDUs corresponding to this NSAPI are deleted.

Upon reception of the SNSM-DEACTIVATE.indication, the SNDCP entity shall, if necessary, release the acknowledged peer-to-peer LLC operation for the associated SAPI. The release criteria and procedure are described in subclause 6.2.2.

5.1.2.22 SNSM-DEACTIVATE.response

Response used by the SNDCP layer to inform SM entity that the NSAPI indicated is no longer in use and that the acknowledged peer-to-peer LLC operation for the associated SAPI is released, if necessary.

5.1.2.23 SNSM-MODIFY.indication

Indication used by the SM entity to trigger change of the QoS profile (see 3GPP TS 04.08) for an NSAPI and indication of the SAPI to be used. It is also used by the SM entity in the SGSN to inform the SNDCP entity that an NSAPI shall be created, together with the (re‑)negotiated QoS profile, the SAPI assigned, and, in the MS, the radio priority level to be used by RLC/MAC.

NOTE: The latter is performed in the new SGSN during an Inter-SGSN Routeing Area Update.

Upon reception of the SNSM-MODIFY.indication from the SM sublayer:

– the SNDCP entity shall, if necessary, establish the acknowledged peer-to-peer LLC operation for the indicated SAPI (the establishment criteria and procedure are described in subclause 6.2.1); and

– the SNDCP entity shall also, if necessary, release the acknowledged peer-to-peer LLC operation for the originally-assigned SAPI (the release criteria and procedure are described in subclause 6.2.2).

If the SNSM-MODIFY.indication applies to an existing NSAPI, and:

– if the peer-to-peer LLC operation mode is changed from acknowledged to unacknowledged, then all buffered N‑PDUs shall be deleted, and the Send N‑PDU number (unacknowledged) shall be set to 0; and

– if the peer-to-peer LLC operation mode is changed from unacknowledged to acknowledged, then the Send N‑PDU number and Receive N‑PDU number shall be set to 0.

In addition, if the newly-assigned SAPI is different from the original SAPI:

– LL‑DATA.indication, LL‑DATA.confirm and LL‑UNITDATA.indication received on the old SAPI shall be ignored;

– LL‑DATA.request and LL‑UNITDATA.request shall be sent on the new SAPI; and

– if acknowledged peer-to-peer LLC operation is used both before and after the receipt of the SNSM-MODIFY.indication, then the NSAPI shall enter the recovery state, and all buffered N‑PDUs (i.e., the ones whose complete reception has not been acknowledged and the ones that have not been transmitted yet) shall be transmitted starting from the oldest N‑PDU.

If the SNSM-MODIFY.indication signifies the creation of an NSAPI (i.e., the specified NSAPI does not exist), and:

– if unacknowledged peer-to-peer LLC operation is specified in the QoS profile, then the Send N‑PDU number (unacknowledged) shall be set to 0; and

– if acknowledged peer-to-peer LLC operation is specified in the QoS profile, then the Send N‑PDU number and the Receive N‑PDU number variables shall be set to the values stated in the primitive.

5.1.2.24 SNSM-MODIFY.response

Response used by the SNDCP entity to inform the SM entity that the indicated NSAPI and QoS profile are now in use and the acknowledged peer-to-peer LLC operations for the appropriate SAPIs are established and/or released, if necessary.

5.1.2.25 SNSM-STATUS.request

This primitive is used by the SNDCP layer to inform the SM sub-layer that SNDCP cannot continue its operation due to errors at the LLC layer (as indicated with LL‑RELEASE.indication) or at the SNDCP layer. The Cause parameter indicates the cause of the error.

5.1.2.26 SNSM-SEQUENCE.indication

This primitive is used during an inter-SGSN routeing area update and applies only to NSAPIs using acknowledged peer-to-peer LLC operation. When the primitive is used in the MS, the Receive N‑PDU number parameter indicates the Receive N‑PDU number in the SGSN. When the primitive is used in the SGSN, the Receive N‑PDU number parameter indicates the Receive N‑PDU number in the MS. If a buffered N‑PDU is confirmed by the Receive N‑PDU number parameter to have been received by the peer SNDCP entity, the N‑PDU shall be deleted from the buffer. In addition, the receipt of this primitive by the SNDCP entity resumes the transmission of SN‑PDUs for the NSAPI, and all buffered N‑PDUs (i.e., the ones whose complete reception has not been acknowledged and the ones that have not been transmitted yet) shall be transmitted starting from the oldest N‑PDU. If acknowledged peer-to-peer LLC operation has not yet been established for the SAPI used by this NSAPI, the transmission of the buffered N‑PDUs shall begin only after the receipt of the LL‑ESTABLISH.indication or LL‑ESTABLISH.confirm primitive.

5.1.2.27 SNSM-SEQUENCE.response

This primitive is used during an inter-SGSN routeing area update and applies only to NSAPIs using acknowledged peer-to-peer LLC operation. The primitive is used by the SNDCP layer in the MS following receipt of an SNSM-SEQUENCE.indcation, in order to return the Receive N‑PDU number to the SGSN during an ongoing inter-SGSN routeing area update.

5.1.2.28 SNSM-STOP-ASSIGN.indication

This primitive is used during an inter-SGSN routeing area update in the old SGSN by the SM entity to inform the SNDCP entity to stop assigning N‑PDU numbers to N‑PDUs received through the SN‑DATA.request primitive. The primitive is sent before the Send N‑PDU number and the Receive N‑PDU number are transferred to the new SGSN.

5.2 Service functions

SNDCP shall perform the following functions (see Figure 3):

– Mapping of SN‑DATA primitives onto LL‑DATA primitives.

– Mapping of SN‑UNITDATA primitives onto LL‑UNITDATA primitives.

– Multiplexing of N‑PDUs from one or several network layer entities onto the appropriate LLC connection.

– Establishment, re-establishment and release of acknowledged peer-to-peer LLC operation.

– Supplementing the LLC layer in maintaining data integrity for acknowledged peer-to-peer LLC operation by buffering and retransmission of N‑PDUs.

– Management of delivery sequence for each NSAPI, independently.

– Compression of redundant protocol control information (e.g., TCP/IP header) at the transmitting entity and decompression at the receiving entity. The compression method is specific to the particular network layer or transport layer protocols in use.

– Compression of redundant user data at the transmitting entity and decompression at the receiving entity. Data compression is performed independently for each SAPI, and may be performed independently for each PDP context. Compression parameters are negotiated between the MS and the SGSN.

– Segmentation and reassembly. The output of the compressor functions is segmented to the maximum length of LL‑PDU. These procedures are independent of the particular network layer protocol in use.

– Negotiation of the XID parameters between peer SNDCP entities using XID exchange.

Figure 4 shows the transmission flow through SNDCP layer. The order of functions is the following:

– Protocol control information compression.

– User data compression.

– Segmentation of compressed information into SN‑DATA or SN‑UNITDATA PDUs.

The order of functions is vice versa in the reception flow:

– Reassembly of SN‑PDUs to N‑PDUs.

– User data decompression.

– Protocol control information decompression.

Figure 4: SNDCP model

The SNDCP layer expects the following services to be provided by the LLC layer. LLC layer functionality is defined in 3GPP TS 04.64 [6]:

– Acknowledged and unacknowledged data transfer.

– Point-to-point and point-to-multipoint data transfer.

– In-order delivery of SN‑PDUs per SAPI (i.e., SN‑PDUs using the same SAPI shall appear at the receiving end in the same order as transmitted). This is required only for acknowledged service.

– QoS profile-based transfer of SN‑PDUs.

– Support for variable length SN‑PDUs.

– Transfer of SNDCP XID parameters.

The SNDCP layer expects the following services to be provided by the SM sublayer. SM sublayer functionality is defined in 3GPP TS 04.08 [5]:

– Activation and deactivation of PDP Contexts and informing the SNDCP layer when change in PDP context has happened.

– Carrying out Inter SGSN Routing Area Update and informing the SNDCP layer in the SGSN when the N‑PDUs shall be tunnelled to the new SGSN.

– Notifying the SNDCP layer when there is need to change the QoS profile parameters of the PDP contexts.