6 Protocol functions

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

6.1 Multiplexing of N‑PDUs

The NSAPI field shall be used for the identification of the specific PDP type and PDP address pair that is using the services provided by the SNDCP layer. The MS allocates NSAPIs dynamically at the PDP Context Activation. The NSAPI is delivered by the SM sub-layer to the SNDCP layer with the SNSM-ACTIVATE.indication primitive. The transmitting SNDCP entity shall insert the NSAPI value for each N‑PDU. The peer SNDCP entity uses the NSAPI to identify the SNDCP user the N‑PDU is targeted. Table 3 shows an example for the allocation of the NSAPIs.

Table 3: Example of the NSAPI allocation

PDP type

Allocated NSAPI

PDP address

IPv4

12

133.12.75.111 (4 octets)

IPv6

13

133.12. … .11.123 (16 octets)

6.2 Establishment and release of acknowledged peer-to-peer LLC operation

The SNDCP layer shall be responsible for establishing, re-establishing and releasing the acknowledged peer-to-peer LLC operation.

Re-establishment and release of the acknowledged peer-to-peer LLC operation may also be initiated by the LLC layer. The conditions under which this may happen are described in 3GPP TS 04.64.

Negotiation of SNDCP XID parameters may be carried out in conjunction with the establishment or re-establishment procedure. It is also possible to negotiate SNDCP XID parameters independently from the establishment or re-establishment procedure, by using the LL‑XID primitives.

6.2.1 Establishment of acknowledged peer-to-peer LLC operation

6.2.1.1 Establishment criteria

If acknowledged peer-to-peer LLC operation is required by an NSAPI (as indicated by the QoS profile) but is not yet established for the SAPI used by the NSAPI, then the SNDCP layer shall initiate the establishment procedure.

The SNDCP layer at the MS shall initiate the establishment, using the procedure in subclause 6.2.1.3, upon receipt of the SNSM-ACTIVATE.indication primitive.

The SNDCP layer at the SGSN shall initiate the establishment upon receipt of the SNSM-MODIFY.indication primitive.

6.2.1.2 Re-establishment of the acknowledged peer-to-peer LLC operation

The SNDCP layer may initiate re-establishment of the acknowledged peer-to-peer LLC operation for a SAPI under certain situations, for example when an error is detected by a V.42 bis data compression entity used for acknowledged data transfer.

The LLC layer may also initiate re-establishment of the acknowledged peer-to-peer LLC operation for a SAPI under situations described in 3GPP TS 04.64. The LLC layer informs the SNDCP layers of link re-establishment using the LL‑ESTABLISH.indication primitive. This is shown in Figure 5.

Figure 5: LLC-initiated re-establishment

6.2.1.3 Establishment procedure

The SNDCP layer shall initiate the establishment or re-establishment by sending an LL‑ESTABLISH.request primitive to the relevant LLC SAP. SNDCP XID parameters may be included in an SNDCP XID block in the LL‑ESTABLISH.request primitive. If no SNDCP XID parameter is to be included, an empty SNDCP XID block shall be included.

Following the sending of the LL‑ESTABLISH.request primitive, the SNDCP layer shall suspend the transfer of SN‑DATA and SN‑UNITDATA primitives to the LLC SAP to which the LL‑ESTABLISH.request is sent. Transfer of SN‑DATA and SN‑UNITDATA primitives shall resume when the establishment procedure ends through one of the following means:

– successful (receiving LL‑ESTABLISH.confirm);

– failure (receiving LL‑RELEASE.indication); or

– successful following collision resolution (receiving LL‑ESTABLISH.indication and sending LL‑ESTABLISH.response, see subclause 6.2.1.4).

Upon receipt of an LL‑ESTABLISH.indication primitive, if an SNDCP XID block is present, the peer SNDCP entity shall respond with an LL‑ESTABLISH.response primitive. SNDCP XID parameters may be included in an SNDCP XID block in the LL‑ESTABLISH.response primitive. If no SNDCP XID parameter is to be included, an empty SNDCP XID block shall be included. If there is no SNDCP XID block in the LL‑ESTABLISH.indication primitive, the peer SNDCP entity shall not respond with an LL‑ESTABLISH.response primitive.

Figure 6: SNDCP-initiated establishment / re-establishment

6.2.1.4 Exceptional situations

If the originator of the establishment procedure receives an LL‑RELEASE.indication with Cause "DM received", it shall inform the SM sub-layer using the SNSM-STATUS.request primitive with Cause "DM received". SM shall then deactivate all PDP contexts for that SAPI requiring acknowledged peer-to-peer LLC operation.

If the originator of the establishment procedure receives an LL‑RELEASE.indication with Cause "invalid XID response" or an LL‑STATUS.indication with Cause "invalid XID response", then it shall inform the SM sub-layer using the SNSM-STATUS.request primitive with Cause "invalid XID response". SM shall then deactivate all PDP contexts for that SAPI.

If the originator of the establishment procedure receives an LL‑RELEASE.indication with Cause "no peer response" or an LL‑STATUS.indication with Cause "no peer response", then it shall inform the SM sub-layer using the SNSM-STATUS.request primitive with Cause "no peer response", wait for an implementation-specific amount of time, and re-invoke the establishment procedure. Before the establishment procedure is re-invoked, N‑PDUs arriving at the SNDCP layer for delivery to the LLC layer shall be buffered, if possible.

If the SNDCP layer receives an LL‑RELEASE.indication with Cause "normal release", it shall buffer, if possible, all downlink N‑PDUs for NSAPIs using the affected SAPI that requires acknowledged peer-to-peer LLC operation. Transfer of N‑PDUs for NSAPIs that do not require acknowledged peer-to-peer LLC operation shall not be affected.

If the originator of the establishment procedure detects a collision (receiving an LL‑ESTABLISH.indication primitive after sending an LL‑ESTABLISH.request or LL‑XID.request primitive, or receiving an LL‑XID.indication primitive after sending an LL‑XID.request primitive), it shall treat the LL‑ESTABLISH.request or LL‑XID.request primitive sent as not transmitted, and process the LL‑ESTABLISH.indication or LL‑XID.indication primitive received. If the LL‑ESTABLISH.request or LL‑XID.request contains one or more XID parameters, or one or more compression fields in an XID parameter, or one or more parameters in a compression field, that are not negotiated as part of the collision resolution, then negotiation of these XID parameters shall be performed at the earliest opportunity after conclusion of the collision resolution.

6.2.2 Release of acknowledged peer-to-peer LLC operation

6.2.2.1 Release criteria

If acknowledged peer-to-peer LLC operation is established for the SAPI used by a PDP context that is going to be deactivated or mapped to another SAPI, and if there is no other NSAPIs that require acknowledged peer-to-peer LLC operation using the original SAPI, then the SNDCP layer shall initiate the release procedure.

The SNDCP layer shall initiate the release, using the procedure described in subclause 6.2.2.2, upon receipt of the SNSM-DEACTIVATE.indication primitive.

The SNDCP layer at the SGSN shall also initiate the release upon receipt of the SNSM-MODIFY.indication primitive if an existing NSAPI is specified.

6.2.2.2 Release procedure

The SNDCP layer shall initiate the release by sending a LL‑RELEASE.request primitive to the relevant LLC SAP. The Local parameter shall be set if the release is the result of receipt of the SNSM-DEACTIVATE.indication primitive, otherwise it shall not be set.

6.2.2.3 Release initiated by the LLC layer

The LLC layer may initiate release of the acknowledged peer-to-peer LLC operation for a SAPI under situations described in 3GPP TS 04.64. The LLC layer shall inform the SNDCP layers of the release of acknowledged peer-to-peer LLC operation using the LL‑RELEASE.indication primitive. SNDCP shall process the LL‑RELEASE.indication primitive as described in subclause 6.2.1.4.

6.3 N‑PDU buffering

The N‑PDUs shall be buffered in the SNDCP layer before they are compressed segmented and transmitted to the LLC layer. The reception of an SNSM-DEACTIVATE.indication shall trigger the deletion of the buffer for the related NSAPI.

For acknowledged data transfer, the SNDCP entity shall buffer an N‑PDU until successful reception of all SN‑PDUs carrying segments of the N‑PDU have been confirmed. The confirmation is carried out using the LL‑DATA.confirm primitive from the LLC layer or the SNSM-SEQUENCE.indication primitive from the SM layer. Buffered N‑PDUs which have been completely received as indicated by the acknowledgements in an LL‑DATA.confirm primitive shall be discarded. During the Inter-SGSN RA Update, buffered N‑PDUs whose complete reception by the MS has been confirmed in the SNSM-SEQUENCE.indication primitive shall be discarded, as defined in 3GPP TS 09.60 7 and 3GPP TS 03.60 3].

For unacknowledged data transfer, the SNDCP shall delete an N‑PDU immediately after it has been delivered to the LLC layer.

6.4 Management of delivery sequence

The SNDCP layer shall retain the delivery sequence of N‑PDUs of each NSAPI between the peer entities. The delivery sequence of N‑PDUs from different NSAPIs may be changed according to the QoS profiles.

6.5 Protocol control information compression

Protocol control information compression is an optional SNDCP feature.

Negotiation of the supported algorithms and their parameters is carried out between MS and SGSN using the SNDCP XID parameters (see clause 8).

6.5.1 Negotiation of multiple protocol control information compression types

Each SNDCP entity that supports protocol control information compression shall be able to negotiate one or several protocol control information compression entities with the compression field format shown in Figure 7. The negotiation shall be carried out using the XID parameter negotiation specified in subclause 6.8. The initiating entity defines a set of requested compression entities, together with the algorithm and parameters for each compression entity. The set of entities and their algorithms and parameters shall be transmitted to the peer entity. The peer entity responds with the set of negotiated entities and their algorithms and parameters. The peer entity shall select the proposed parameter values or other appropriate values for the negotiated entities.

6.5.1.1 Format of the protocol control information compression field

Bit

8

7

6

5

4

3

2

1

Octet 1

P

X

X

Entity number

Octet 2

X

X

X

Algorithm type

Octet 3

Length=n-3

Octet 4

PCOMP1

PCOMP2

Octet x

High-order octet

Octet n

Low-order octet

Figure 7: Protocol control information compression field format for SNDCP XID negotiation

6.5.1.1.1 Spare bit (X)

The X bit shall be set to 0 by the transmitting SNDCP entity and shall be ignored by the receiving SNDCP entity..

6.5.1.1.2 Propose bit (P)

The P bit shall be set to 1 if a new compression entity is being proposed, otherwise it shall be set to 0. If the P bit is set to 1, then all octets shall be included, otherwise octet 2 and octets 4 to x‑1 shall not be included. If the P bit is set to 1, then only enough number of octets shall be included to contain the number of PCOMP values needed by the corresponding compression algorithm (e.g., PCOMP3 and PCOMP4 shall not be included if the number of PCOMP values needed by a compression algorithm is one or two). If an odd number of PCOMP values are used by a compression algorithm, then the last PCOMP value shall be set to 0 in the compression field by the transmitting SNDCP entity, and it shall be ignored by the receiving SNDCP entity.

6.5.1.1.3 Entity number

The entity number shall be used to identify a protocol control information compression entity on a SAPI. The entity number shall be assigned using the following rules:

– The entity number shall be an integer from 0 to 31.

– The entity number shall be assigned independently on each of the SAPIs.

– An entity number shall be in one of the three states: unassigned, selected, or assigned.

– When a new compression entity is to be proposed, an unassigned entity number shall become selected. If there is no unassigned entity number left, the compression entity shall not be proposed.

– A selected entity number shall become assigned if the corresponding proposed compression entity is created as a result of the XID negotiation, otherwise it shall become unassigned.

– An assigned entity number shall become unassigned when the corresponding compression entity is deleted as a result of an XID negotiation, or upon the receipt of the LL-RESET.indication primitive.

– In the case of a collision (see subclause 6.2.1.4) in which an entity number is currently selected:

– If the selected entity number is included with the P bit set to 0 in the incoming SNDCP XID block, then it shall be assumed that the peer SNDCP entity agreed to the creation of the proposed entity but the response was lost. Therefore the selected entity number shall become assigned, any selected PCOMP and DCOMP values for the algorithm of the entity shall become assigned, and the compression entity shall be created, before the incoming SNDCP XID block is processed. After the incoming SNDCP XID block is processed, the compression entity shall be negotiated again if necessary, as defined in subclause 6.2.1.4.

– Otherwise (i.e., if the selected entity number is not included, or is included with the P bit set to 1 in the incoming SNDCP XID block), the selected entity number shall become unassigned, and any selected PCOMP and DCOMP values for the algorithm of the entity shall become unassigned, before the incoming SNDCP XID block, if any, is processed. Following the collision resolution procedure, the originally-proposed compression entity shall be proposed again (i.e., the originally-proposed compression entity shall not be considered created even if the originally-selected entity number is proposed in the incoming SNDCP XID block) by sending the appropriate primitive (LL‑ESTABLISH.request or LL‑XID.request). The originally-selected entity number, PCOMP and DCOMP values shall be used for the compression entity being re-proposed if they are unassigned, otherwise a new entity number, PCOMP or DCOMP value shall be selected.

– In the case of a collision in which an entity number is currently assigned:

– If the peer SNDCP entity proposes a new compression entity with the same entity number, then it shall be assumed that the peer SNDCP entity negotiated the deletion of the entity but the response was lost, and the entity number is being reused. Therefore the original compression entity shall be deleted, the entity number shall become unassigned, PCOMP and DCOMP values shall be unassigned if necessary (see subclause 6.5.1.1.5), and then the proposed compression entity shall be responded to as usual.

– Otherwise (i.e., if the assigned entity number is not included, or is included with the P bit set to 0 in the incoming SNDCP XID block), the usual rules regarding collision handling shall apply.

– In the case of a collision in which a PCOMP or DCOMP value is currently assigned to a compression algorithm:

– If the peer SNDCP entity proposes a new compression entity with the same PCOMP or DCOMP assigned to a different algorithm, then it shall be assumed that the peer SNDCP entity negotiated the deletion of all entities using the algorithm to which the PCOMP or DCOMP value was assigned, but the response was lost, and the PCOMP or DCOMP value is being reused. Therefore, all compression entities using that algorithm shall be deleted, all corresponding entity numbers shall become unassigned, and all PCOMP or DCOMP values assigned to the algorithm shall become unassigned, and then the proposed compression entity shall be responded to as usual.

– Otherwise (i.e., if the assigned PCOMP or DCOMP is not included, or is included and assigned to the same algorithm), the usual rules regarding collision handling shall apply.

6.5.1.1.4 Algorithm type

Table 4 show the list of protocol control information compression algorithms supported by the SNDCP layer. When new compression algorithms are needed for SNDCP, Table 4 shall be updated.

Table 4: List of protocol control information compression algorithms supported by SNDCP

Compression algorithm

Algorithm type (Range 0-31)

RFC1144

0

RFC2507

1

Other values Reserved

6.5.1.1.5 PCOMP

One or more PCOMP values shall be assigned dynamically to a compression algorithm, based on the negotiation of the XID parameters for protocol control information compression. Each of the assigned PCOMP values denotes one compressed frame type of that compression algorithm.

The assignment of the PCOMP values follows the following general rules:

– PCOMP shall be an integer from 0 to 15.

– PCOMP value 0 is reserved permanently for no compression.

– PCOMP shall be assigned independently on each of the SAPIs.

– An assigned PCOMP value applies to all NSAPIs mapped to the same SAPI.

– PCOMP values shall be assigned to compression algorithms, not to compression entities (i.e., the same PCOMP value(s) shall be used by different compression entities on the same SAPI using the same compression algorithm).

– A PCOMP value shall be in one of the three states: unassigned, selected, or assigned.

– When a new compression entity is to be proposed, and if PCOMP values have not yet been assigned to the corresponding compression algorithm, then the appropriate number of unassigned PCOMP values shall be selected. If there is not enough unassigned PCOMP values left, the compression entity shall not be proposed.

– A selected PCOMP value shall become assigned if the corresponding proposed compression entity is created as a result of the XID negotiation, otherwise it shall become unassigned.

– An assigned PCOMP value shall become unassigned when the corresponding compression algorithm is no longer in use by any compression entity, or upon the receipt of the LL‑RESET.indication primitive.

– In the case of a collision (see subclause 6.2.1.4), the handling of PCOMP values shall be in accordance with subclause 6.5.1.1.3.

While transferring data, the compressed frame type for an N‑PDU is conveyed in the PCOMP field of the SNDCP header of the first SN‑PDU belonging to the N‑PDU. Any successfully negotiated algorithm may be used for compression of an N‑PDU.

6.5.1.2 Resetting compression entities following SNDCP XID negotiation

The LL‑Establish primitives shall be used for the negotiation of protocol control information compression if:

– one or more parameters, excluding the applicable NSAPIs, of existing compression entities used with acknowledged peer-to-peer LLC operation are changed by the originator of the negotiation; or

– one or more NSAPIs are removed, by the originator of the negotiation, from existing compression entities used with acknowledged peer-to-peer LLC operation, except when all NSAPIs using the compression entity are removed, or when LLC is already in ADM.

Otherwise, either the LL‑Establish primitives or the LL‑XID primitives may be used.

If the LL‑XID primitives are used for XID negotiation, then in addition to restrictions specified elsewhere in the present document, the following parameters of the protocol control information compression entities are non-negotiable by the responding SNDCP entity:

– any parameter of existing compression entities used with acknowledged peer-to-peer LLC operation.

If one or more parameters, other than the applicable NSAPIs, of a compression entity used with unacknowledged peer-to-peer LLC operation are changed, the compression entity shall be reset locally upon completion of the SNDCP XID negotiation.

6.5.1.3 Parameters for compression entities

On negotiating a compression entity, not all the parameters of the entity have to be specified. If a parameter is to be included, all the preceding parameters shall also be specified, and the length field shall be set to the sum of the lengths of all the parameters specified. If any of the parameters is not specified, the rules in subclause 6.8.2 shall apply.

6.5.2 TCP/IP header compression (RFC1144)

The protocol control information compression method is specific for each network layer protocol type. TCP/IP (IPv4) header compression is specified in RFC 1144 [9].

6.5.2.1 Parameters

Table 5 contains the parameters defined for a compression entity using TCP/IP header compression. They may be negotiated during SNDCP XID negotiation.

Table 5: RFC 1144 TCP/IP header compression parameters

Parameters

Algorithm Name

Algorithm Type

Length

Parameter Name

Format

Range

Sense of Negotiation

Default Value

RFC 1144

0

0, 2 or 3 if P bit is 0,
1, 3 or 4 if P bit is 1.

Applicable NSAPIs

bbbbbbbb bbb00000

0, 32, 64,  , 65504

down (each bit separately)

0

S0 – 1

bbbbbbbb

0 through 255

down

15

6.5.2.1.1 Applicable NSAPIs

See subclause 7.1.3.

6.5.2.1.2 S0

The number of state slots, as defined in 9. The S0 range is 1 through 256, with 16 as default value.

6.5.2.2 Assignment of PCOMP values

The underlying service shall be able to distinguish the three types of compressed N‑PDUs (i.e., Type IP, Uncompressed TCP, and Compressed TCP), as defined in RFC 1144 9. These three N‑PDU types are differentiated by using different PCOMP values.

Two PCOMP values shall be assigned to the TCP/IP header compression algorithm. PCOMP1 shall contain the PCOMP value for the frame type "Uncompressed TCP", and PCOMP2 shall contain the PCOMP value for the frame type "Compressed TCP".

The PCOMP value of 0 shall be used for the frame type "Type IP".

6.5.2.3 Error Recovery

When TCP/IP header compression is used with unacknowledged peer-to-peer LLC operation, the decompression entity shall be notified in case an N‑PDU is dropped, so that error recovery procedure (see [9]) can be invoked.

6.5.3 TCP/IP and UDP/IP header compression (RFC 2507)

Detailed operation of the RFC 2507 header compression for IPv4 and IPv6 is described in clause 3 of the IETF specification RFC 2507 [10].

6.5.3.1 Parameters

Table 6 contains the parameters defined for a compression entity using RFC2507 header compression. They may be negotiated during SNDCP XID negotiation.

Table 6: RFC 2507 TCP/IP and UDP/IP header compression parameters

Parameters

Algorithm Name

Algorithm Type

Length

Parameter Name

Format

Range

Sense of Negotiation

Default Value

RFC 2507

1

0, 2, 4, 5, 6, 7 or 9 if P bit is 0,

3, 5, 7, 8, 9, 10 or 12 if P bit is 1.

Applicable NSAPIs

bbbbbbbb bbb00000

0, 32, 64,  , 65504

down (each bit separately)

0

F_MAX_PERIOD

bbbbbbbb

bbbbbbbb

1-65535

down

256

F_MAX_TIME

bbbbbbbb

1-255

down

5

MAX_HEADER

bbbbbbbb

60-255

down

168

TCP_SPACE

bbbbbbbb

3-255

down

15

NON_TCP_SPACE

bbbbbbbb

bbbbbbbb

3-65535

down

15

The explanation of the individual parameters can be found in the clause 14 of the IETF specification RFC 2507 [10].

6.5.3.1.1 Applicable NSAPIs

See subclause 7.1.3.

6.5.3.2 Assignment of PCOMP values for RFC2507

The following PCOMP values shall be assigned to the RFC 2507 header compression. The PCOMP value 0 shall be used for regular IPv4 and IPv6 packets.

Table 7: PCOMP values assigned to RFC 2507 header compression algorithm

PID value

Packet type

PCOMP1

Full header

PCOMP2

Compressed TCP

PCOMP3

Compressed TCP non-delta

PCOMP4

Compressed non-TCP

PCOMP5

Context state

6.5.3.3 Error Recovery

The mechanisms related to error recovery and packet reordering are described in clauses 10 and 11 of the RFC 2507[10].

6.6 Data compression

Data compression is an optional SNDCP feature. Data compression applies to both SN‑DATA and SN‑UNITDATA primitives.

Data compression, if used, shall be performed on the entire N‑PDU, including the possibly compressed protocol control information.

Figure 8 shows an example how the SNDCP functions may be used. Several NSAPIs may use a common data compression entity, i.e., the same compression algorithm and the same dictionary. Separate data compression entities shall be used for acknowledged (SN‑DATA) and unacknowledged (SN‑UNITDATA) data transfer. Several NSAPIs may be associated with one SAPI, i.e., they may use the same QoS profile.

Figure 8: An example for the usage of NSAPIs, SNDCP functions, and SAPIs

6.6.1 Negotiation of multiple data compression types

Each SNDCP entity that supports data compression shall be able to negotiate one or several data compression entities with the compression field format shown in Figure 9. The negotiation shall be carried out using the XID parameter negotiation specified in subclause 6.8. The initiating entity defines a set of requested compression entities, together with the algorithm and parameters for each compression entity. The set of entities and their algorithms and parameters shall be transmitted to the peer entity. The peer entity responds with the set of negotiated entities and their algorithms and parameters. The peer entity shall select the proposed parameter values or other appropriate values for the negotiated entities.

For each NSAPI one or more data compression are chosen. This choice is also indicated in the SNDCP XID. Only NSAPIs that are using the same SAPI may use the same data compression entity. If more than one compression entity is chosen for an NSAPI, these entities must use different data compression algorithms. However, only one data compression entity is used for one N‑PDU; i.e., the used data compression entity may be changed from N‑PDU to N‑PDU.

6.6.1.1 Format of the data compression field

Bit

8

7

6

5

4

3

2

1

Octet 1

P

X

X

Entity number

Octet 2

X

X

X

Algorithm type

Octet 3

Length=n-3

Octet 4

DCOMP1

DCOMP2

Octet x

High-order octet

Octet n

Low-order octet

Figure 9: Data compression field format for SNDCP XID negotiation

6.6.1.1.1 Spare bit (X)

The X bit shall be set to 0 by the transmitting SNDCP entity and shall be ignored by the receiving SNDCP entity.

6.6.1.1.2 Propose bit (P)

The P bit shall be set to 1 if a new compression entity is being proposed, otherwise it shall be set to 0. If the P bit is set to 1, then all octets shall be included, otherwise octet 2 and octets 4 to x-1 shall not be included. If the P bit is set to 1, then only enough number of octets shall be included to contain the number of DCOMP values needed by the corresponding compression algorithm (e.g., DCOMP3 and DCOMP4 shall not be included if the number of DCOMP values needed by a compression algorithm is one or two). If an odd number of DCOMP values are used by a compression algorithm, then the last DCOMP value shall be set to 0 in the compression field by the transmitting SNDCP entity, and it shall be ignored by the receiving SNDCP entity.

6.6.1.1.3 Entity number

The entity number shall be used to identify a data compression entity on a SAPI. See subclause 6.5.1.1.3 for the rules for assigning entity numbers. The assignment of entity numbers for protocol control information compression entities and data compression entities shall be independent.

6.6.1.1.4 Algorithm type

Table 6 shows the list of data compression algorithms supported by the SNDCP layer. When new compression algorithms are needed for SNDCP, Table 6 shall be updated.

Table 6: List of data compression algorithms supported by SNDCP

Data compression algorithm

Algorithm type

(Range 0-31)

V.42 bis

0

Other values Reserved

6.6.1.1.5 DCOMP

One or more DCOMP values shall be assigned dynamically to a compression algorithm, based on the negotiation of the XID parameters for data compression. Each of the assigned DCOMP values denotes one compressed frame type of that compression algorithm.

The assignment of the DCOMP values shall follow the rules for the assignment of PCOMP values in subclause 6.5.1.1.5.

While transferring data, the compressed frame type for an N‑PDU is conveyed in the DCOMP field of the SNDCP header of the first SN‑PDU belonging to the N‑PDU. Any successfully negotiated algorithm may be used for compression of an N‑PDU.

6.6.1.2 Resetting compression entities following SNDCP XID negotiation

The LL‑Establish primitives shall be used for the negotiation of data compression if:

– one or more parameters, excluding the applicable NSAPIs, of existing compression entities used with acknowledged peer-to-peer LLC operation are changed by the originator of the negotiation; or

– one or more NSAPIs are removed, by the originator of the negotiation, from existing compression entities used with acknowledged peer-to-peer LLC operation, except when all NSAPIs using the compression entity are removed, or when LLC is already in ADM.

Otherwise, either the LL‑Establish primitives or the LL‑XID primitives may be used.

If the LL‑XID primitives are used for XID negotiation, then in addition to restrictions specified elsewhere in the present document, the following parameters of the data compression entities are non-negotiable by the responding SNDCP entity:

– any parameter of existing compression entities used with acknowledged peer-to-peer LLC operation.

If one or more parameters, other than the applicable NSAPIs, of a compression entity used with unacknowledged peer-to-peer LLC operation are changed, the compression entity shall be reset locally upon completion of the SNDCP XID negotiation.

6.6.1.3 Parameters for compression entities

On negotiating a compression entity, not all the parameters of the entity have to be specified. If a parameter is to be included, all the preceding parameters shall also be specified, and the length field shall be set to the sum of the lengths of all the parameters specified. If any of the parameters is not specified, the rules in subclause 6.8.2 shall apply.

6.6.2 Management of V.42 bis data compression

ITU‑T V.42 bis [8] data compression may be used with SN‑DATA primitives and SN‑UNITDATA primitives.

6.6.2.1 Parameters

Table 7 contains the parameters defined for a compression entity using V.42 bis data compression. They may be negotiated during SNDCP XID negotiation.

Table 7: V.42 bis data compression parameters

Parameters

Algorithm Name

Algorithm Type

Length

Parameter Name

Format

Range

Sense of Negotiation

Default Value

V.42 bis

0

0, 2, 3, 5, or 6 if P bit is 0,
1, 3, 4, 6, or 7 if P bit is 1.

Applicable NSAPIs

bbbbbbbb bbb00000

0, 32, 64,  , 65504

down (each bit separately)

0

P0

000000bb

0 through 3

down (each direction separately)

3

P1

bbbbbbbb bbbbbbbb

512 through 65535

down

2048

P2

bbbbbbbb

6 through 250

down

20

6.6.2.1.1 Applicable NSAPIs

See subclause 7.1.3.

6.6.2.1.2 P0

Two bits are used to indicate the usage of compression, one bit for each direction.

00 compress neither direction

01 compress MS-to-SGSN direction only

10 compress SGSN‑to-MS direction only

11 compress both directions

6.6.2.1.3 P1

Maximum number of codewords in the compressor dictionary (see [8]).

6.6.2.1.4 P2

Maximum number of characters in an uncompressed data string that is accepted to be encoded.

6.6.2.2 Assignment of DCOMP values

One DCOMP value shall be assigned (as DCOMP1) to the V.42 bis data compression algorithm.

6.6.2.3 Operation of V.42 bis data compression

When V.42 bis is used with SN‑DATA primitives, the data in the compression entity shall be flushed (using the C‑FLUSH primitive defined in [8]) and added to the compressed N‑PDU before the compressed N‑PDU is sent.

When V.42 bis is used with SN‑UNITDATA primitives, the compression entity shall be reset (using the C‑INIT primitive defined in [8]) before an N‑PDU is compressed or decompressed. After compression, the data in the compression entity shall be flushed (using the C‑FLUSH primitive defined in [8]) and added to the compressed N‑PDU before the compressed N‑PDU is sent. The LLC protocol shall operate in the protected mode of operation.

When V.42 bis is used with SN‑DATA primitives and an error is detected by the decoder, the SNDCP entity shall use LL‑ESTABLISH.request primitive to reset the acknowledged peer-to-peer LLC operation for the SAPI used.

6.7 Segmentation and reassembly

Segmentation shall be performed by the SNDCP entity to ensure that any SN‑PDU transmitted is no longer than N201 (see 3GPP TS 04.64 [6]). The receiving SNDCP entity shall reassemble the segments back to the original (possibly compressed) N‑PDU.

The segmentation and reassembly procedures are different for acknowledged and unacknowledged mode of operation.

6.7.1 General

6.7.1.1 Segmentation

A (possibly compressed) N‑PDU shall be segmented into one or more SN‑PDUs. The length of each SN‑PDU shall not be greater than N201-I (for acknowledged mode) or N201-U (for unacknowledged mode).

The F bit in the SNDCP header shall be set to 1 for the first segment, and 0 for all subsequent segments.

For unacknowledged peer-to-peer LLC operation, DCOMP and PCOMP shall be included in the header when the F bit is set to 1, and shall not be included when the F bit is set to 0.

For acknowledged peer-to-peer LLC operation, DCOMP, PCOMP and N‑PDU number shall be included in the header when the F bit is set to 1, and shall not be included when the F bit is set to 0.

If an SN‑PDU is received with the F bit set to 1 when a non-first segment is expected, and if DCOMP, PCOMP and (in the acknowledged mode) the N‑PDU number all remain unchanged comparing to the first segment, then the SN‑PDU shall be processed as normal.

The M bit in the SNDCP header shall be set to 0 for the last segment, and 1 for all previous segments.

If only one SN‑PDU is generated for an N‑PDU, the F bit shall be set to 1 and the M bit set to 0.

6.7.1.2 Reassembly

During reassembly, DCOMP and PCOMP for an N‑PDU shall be retrieved from the first segment (F bit set to 1). For acknowledged peer-to-peer LLC operation, the N‑PDU number shall also be retrieved from the first segment.

The receiving SNDCP entity shall be in one of the following three receiving states:

– the Receive First Segment state, in which the SNDCP entity shall expect the F bit set to 1 in the next received SN‑PDU;

– the Receive Subsequent Segment state, in which the SNDCP entity shall expect the F bit set to 0 in the next received SN‑PDU; or

– the Discard state, in which the SNDCP entity shall discard any SN‑PDU received.

The Receive First Segment state shall be entered:

– upon receipt of an SNSM-ACTIVATE.indication;

– upon receipt of an SNSM-MODIFY.indication which indicates a change in SAPI or a change in peer-to-peer LLC operation mode;

– upon receipt of an LL‑ESTABLISH.indication or an LL‑ESTABLISH.confirm; or

– when the M bit is set to 0 in the received SN‑PDU, except for situations specified in subclause 6.7.4.

The Receive Subsequent Segment state shall be entered:

– when the M bit is set to 1 in the received SN‑PDU, except for situations specified in subclause 6.7.4.

6.7.2 Segmentation and reassembly in acknowledged mode

Segmentation and reassembly in acknowledged mode shall follow the general procedures stated in subclause 6.7.1.

6.7.3 Segmentation and reassembly in unacknowledged mode

In addition to the general procedure in subclause 6.7.1, a segment number shall be used due to the unreliable nature of the unacknowledged mode.

The Segment number is a sequence number assigned to each SN‑UNITDATA PDU. The sequence number shall be set to 0 in the first SN‑UNITDATA PDU of an N‑PDU, and incremented by 1 for each subsequent SN‑UNITDATA PDU. Modulo 16 operation is applied.

The received segments belonging to the same N‑PDU shall be re-ordered, if possible. If a timer (implementation dependent) elapses before all segments are received, the segments shall be discarded. Reassembly operation described in subclauses 6.7.1 and 6.7.4 shall be performed after re-ordering.

6.7.4 Exception situations

6.7.4.1 Receive First Segment state

If an SN‑UNITDATA PDU is received with the F bit set to 0, the SN‑UNITDATA PDU shall be discarded. The Receive First Segment state shall be entered if the M bit is set to 0, otherwise the Discard state shall be entered.

If an SN‑DATA PDU is received with the F bit set to 0, the SN‑DATA PDU shall be discarded, and the acknowledged LLC operation shall be re-established for the SAPI used.

6.7.4.2 Receive Subsequent Segment state

If an SN‑UNITDATA PDU is received with the F bit set to 1, and if DCOMP or PCOMP is different from those in the first segment, then the SN‑UNITDATA PDU and all previous segments belonging to the same N‑PDU shall be discarded. The Received First Segment state shall be entered if the M bit is set to 0, otherwise the Discard state shall be entered.

If an SN‑DATA PDU is received with the F bit set to 1, and if DCOMP, PCOMP or N‑PDU number is different from those in the first segment, then the SN‑DATA PDU and all previous segments belonging to the same N‑PDU shall be discarded, and the acknowledged LLC operation shall be re-established for the SAPI used.

6.7.4.3 Discard state

If an SN‑PDU is received with the M bit set to 1, the SN‑PDU shall be discarded and the SNDCP entity shall remain in the Discard state.

If an SN‑PDU is received with the M bit set to 0, the SN‑PDU shall be discarded and the Receive First Segment state entered.

6.8 XID parameter negotiation

Negotiation of XID parameters between peer SNDCP entities may be carried out to ensure optimal information transfer. The parameters are called SNDCP exchange identity (XID) parameters.

SNDCP XID parameter negotiation may be initiated by the SNDCP entity at the MS or at the SGSN. If SNDCP XID parameters are to be changed, SNDCP XID negotiation shall be initiated prior to data transfer – the MS shall initiate SNDCP XID negotiation upon receipt of SNSM-ACTIVATE.indication; the SGSN shall initiate SNDCP XID negotiation upon receipt of the SNSM-MODIFY.indication primitive if an NSAPI has been put into use (in the case of an Inter-SGSN Routeing Area Update), or if the change in QoS profile to an existing NSAPI results in a change in compressor(s) used by the NSAPI.

When an NSAPI no longer uses a compression entity due to a PDP context deactivation or a PDP context modification, an SNDCP XID negotiation shall be performed to remove the NSAPI from the Applicable NSAPIs of the compression entity. The negotiation shall be initiated by the MS upon receipt of the SNSM-DEACTIVATE.indication in the case of PDP context deactivation, or by the SGSN upon receipt of the SNSM-MODIFY.indication in the case of PDP context modification.

The XID negotiation is a one-step procedure; i.e., the initiating end proposes parameter values, and the responding end either accepts these or offers different values in their place according to the XID negotiation rules described in the present document; the rules limit the range of parameter values as well as the sense of negotiation. The initiating end accepts (or rejects) the values in the response; this concludes the negotiation.

The block format for the SNDCP XID parameter negotiation is shown in Figure 10. Not all parameters have to be included in the XID block, only parameters that are negotiated. Parameters may be included in any order. Also it shall be possible to negotiate parameters for more than one NSAPI in one XID block since more than one NSAPI can use the same SAPI.

Bit

8

7

6

5

4

3

2

1

Octet 1

Parameter type=0

Octet 2

Length=1

Octet 3

Version number

Octet 4

Parameter type=1

Octet 5

Length=n-5

Octet 6

P

X

X

Entity number

Octet 7 (optional)

Octet 8

Length=k-8

Octet 9 … (optional)

Octet j

High-order octet

Octet k

Low-order octet

Octet k+1

P

X

X

Entity number

Octet k+2 (optional)

Octet k+3

Length=m-(k+3)

Octet k+4… (optional)

Octet k+y

High-order octet

Octet m

Low-order octet

Octet n

Low-order octet

Octet n+1

Parameter type=2

Octet n+2

Length=r-(n+2)

Octet n+3

P

X

X

Entity number

Octet n+4 (optional)

Octet n+5

Length=p-(n+5)

Octet n+6… (optional)

Octet n+w

High-order octet

Octet p

Low-order octet

Octet p+1

P

X

X

Entity number

Octet p+2 (optional)

Octet p+3

Length=q-(p+3)

Octet p+4… (optional)

Octet p+v

High-order octet

Octet q

Low-order octet

Octet r

Low-order octet

Figure 10: Example of SNDCP XID block format

The SNDCP user uses SN‑XID.request to initiate the negotiation of the XID parameters. The SNDCP entity sends the proposed SNDCP XID parameters to the LLC SAP with the LL‑XID.request or LL‑ESTABLISH.request. The LLC SAP shall issue an XID command containing the SNDCP XID parameters (see 3GPP TS 04.64). The peer LLC SAP shall, upon receipt of the XID command, indicate the SNDCP XID parameters to SNDCP entity using LL‑XID.indication or LL‑ESTABLISH.indication. The peer SNDCP entity shall select appropriate values for the proposed parameters or negotiate the appropriate values with the SNDCP user entity with the SN‑XID.indication and SN‑XID.response primitives. When the appropriate parameter values are known by the peer SNDCP entity, it shall use the LL‑XID.response or LL‑ESTABLISH.response primitive to continue negotiation. Upon reception of the response, the LLC SAP shall send the received parameters to the SNDCP entity using the LL‑XID.confirm or LL‑ESTABLISH.confirm primitive. The SNDCP entity delivers the negotiated parameters to the SNDCP user. This is illustrated in Figure 11. The originator of the negotiation shall apply the new parameter values after it has received the ‘confirm’ primitive. The responding end of the negotiation shall apply the new parameter values after it has sent the replying ‘response’ primitive.

Following the sending of the LL‑XID.request primitive, the SNDCP layer shall suspend the transfer of SN‑DATA and SN‑UNITDATA primitives to the LLC SAP to which the LL‑XID.request is sent. Transfer of SN‑DATA and SN‑UNITDATA primitives shall resume when the SNDCP XID negotiation ends through one of the following means:

– successful (receiving LL‑XID.confirm);

– failure (receiving LL‑RELEASE.indication, or LL‑STATUS.indication); or

– successful following collision resolution (receiving LL‑ESTABLISH.indication and sending LL‑ESTABLISH.response, or receiving LL‑XID.indication and sending LL‑XID.response, see subclause 6.2.1.4).

LLC may also initiate LLC XID negotiation, in which case LLC may send an LL‑XID.indication to inform SNDCP the values of N201-I and N201-U. This is illustrated in Figure 12. If the SNDCP entity receives an LL‑XID.indication without an SNDCP XID block, it shall not respond with the LL‑XID.response primitive.

Negotiation of SNDCP version number is always between the peer SNDCP entities. The version number is not known by the SNDCP user. However, negotiation of the parameters for compression algorithms may be carried out between the SNDCP user entities.

Negotiation of SNDCP XID parameters for an NSAPI shall be carried out in the SAPI to which the NSAPI is mapped.

Figure 11: SNDCP XID negotiation procedure

Figure 12: LLC XID negotiation procedure

6.8.1 Negotiation of compression entities

For parameter type 1 and 2, multiple compression fields (as shown in Figure 7 and Figure 9) may be specified. Each compression field corresponds to a compression entity.

In each compression field, the "Applicable NSAPIs" parameter indicates the NSAPIs that uses the compression entity. The parameter, if included, shall consist of 2 octets. Multiple NSAPIs may share the same compression entity by setting multiple bits in the parameter. NSAPIs requiring acknowledged peer-to-peer LLC operation and unacknowledged peer-to-peer LLC operation shall not share the same compressor (see subclause 6.10).

During SNDCP XID negotiation or re-negotiation, if a parameter type is specified in the SNDCP XID block, compression entities currently in use and compression entities proposed to be added may be included in the SNDCP XID block. Not all entities need to be included in the SNDCP XID block. If a compression entity is not included, the value of its parameters shall be determined by the rules defined in subclause 6.8.2.

If, implicitly or explicitly (see subclause 6.8.2), a compression entity is specified in the responding SNDCP XID block with one or more bits set to 1 in the "Applicable NSAPIs" parameter, the compression entity shall be created (if it does not exist yet).

If, implicitly or explicitly, a compression entity is specified in the responding SNDCP XID block with no bit set to 1 in the "Applicable NSAPIs" parameter, the compression entity shall be deleted (if it currently exists).

If, implicitly or explicitly, one or more bits are set to 1 in the "Applicable NSAPIs" parameter of a compression entity in the responding SNDCP XID block, the NSAPIs corresponding to these bits shall start using (or continue to use) the compression entity.

If, implicitly or explicitly, one or more bits are set to 0 in the "Applicable NSAPIs" parameter of a compression entity in the responding SNDCP XID block, the NSAPIs corresponding to these bits shall release the compression entity (if they have been using the compression entity).

6.8.2 Values of SNDCP XID parameters

In this subclause, the term "parameter" refers to an SNDCP XID parameter, a compression field (for parameter type 1 or 2), or a parameter for a compression field.

If an SNDCP XID parameter has not been negotiated, default values shall apply. The default value for a compression field (entity) is "non-existing".

If the originating SNDCP XID block does not include a parameter (implicit command), it shall be treated as equivalent to requesting for the current value for the parameter. The responder may explicitly include this parameter in its response. If the responder explicitly includes the parameter in the response, then it shall also explicitly include this parameter in every SNDCP XID response until the parameter has been explicitly negotiated, either by responding to an SNDCP XID command that included the parameter, or by explicitly including the parameter the next time an SNDCP XID command is transmitted.

If a parameter is included in the originating SNDCP XID block and the responder does not include the parameter in its response (implicit response), it shall be treated as equivalent to responding with the value proposed by the originator.

If both the originator and the responder do not include a parameter in the negotiation, the value of the parameter is not changed.

6.8.3 Exception handling

In this subclause, the term "parameter" may refer, wherever applicable, to an SNDCP XID parameter, a compression field (for parameter type 1 or 2), or a parameter for a compression field.

If the originating SNDCP XID block includes a parameter with unrecognised Type field, the parameter shall be ignored by the responder.

If the originating SNDCP XID block includes a parameter with unsupported length or an out-of-range value, then the responder shall respond to the parameter with lengths and values set according to the responder’s preference.

If the originating SNDCP XID block includes parameter type 1 or 2 which violates the rules in subclause 6.8.1, the responder shall treat the parameter as not transmitted by the originator, and responds according to subclause 6.8.2.

If the originating SNDCP XID block includes a parameter with duplicated instances, the subsequent instances of the duplicated parameter shall be ignored.

If the originating SNDCP XID block is sent on LL‑XID primitives and contains prohibited changes (see subclauses 6.5.1.2 and 6.6.1.2) to the parameters of compression entities used with acknowledged peer-to-peer LLC operation, then the responder shall respond with these parameters set to their previously-negotiated values.

In the originating SNDCP XID block, excluding the collision scenarios described in subclause 6.5.1.1.3, when an assigned entity number is included with the P bit set to 1, the algorithm and the PCOMP and DCOMP fields shall be ignored if they are the same as the previously-assigned values. If the algorithm and PCOMP or DCOMP fields are not the same as the previously-assigned values, then the Applicable NSAPIs field of the compression field in question shall be set to 0 in the response, and an SNSM-STATUS.request primitive with Cause "invalid XID command" shall be sent to the SM sub-layer. SM shall then deactivate all PDP contexts for this SAPI.

In the originating SNDCP XID block, if an unassigned entity number is included with the P bit set to 0, then the Applicable NSAPIs field in the response shall be set to 0.

In the originating SNDCP XID block, excluding the collision scenarios described in subclause 6.5.1.1.3, if one or more of the PCOMP or DCOMP specified is already assigned to a different compression algorithm, then the Applicable NSAPIs field of the compression field in question shall be set to 0 in the response, and an SNSM-STATUS.request primitive with Cause "invalid XID command" shall be sent to the SM sub-layer. SM shall then deactivate all PDP contexts for this SAPI.

In the originating SNDCP XID block, if one or more new PCOMP or DCOMP values are specified for an existing compression algorithm, then the Applicable NSAPIs field of the compression field in question shall be set to 0 in the response, and an SNSM-STATUS.request primitive with Cause "invalid XID command" shall be sent to the SM sub-layer. SM shall then deactivate all PDP contexts for this SAPI.

If the responding SNDCP XID block includes a parameter with unrecognised Type field, unsupported length, an out-of-range value or a value violating the sense of negotiation, a parameter type 1 or 2 which violates the rules in subclause 6.8.1, a parameter with duplicated instances, contains prohibited changes (see subclauses 6.5.1.2 and 6.6.1.2) to the parameters of compression entities used with acknowledged peer-to-peer LLC operation when the SNDCP XID block is sent on LL‑XID primitives, or a compression field with the P bit set to 1, then the originator shall ignore the block and reinitiate the negotiation. If the renegotiation fails for an implementation-specific number of times, the originating SNDCP layer shall send an SNSM-STATUS.request primitive with Cause "invalid XID response" to the SM sub-layer. SM shall then deactivate all PDP contexts for this SAPI.

If the LLC layer indicates that the XID parameter negotiation failed, by sending an LL‑RELEASE.indication with Cause "no peer response" or an LL‑STATUS.indication with Cause "no peer response", then, as an implementation option, the SNDCP layer may wait for an implementation-specific amount of time and re-invoke the XID negotiation procedure.

6.9 Data transfer

6.9.1 Acknowledged mode

The SNDCP entity shall initiate acknowledged data transmission only if the PDP context for the NSAPI identified in the SN‑DATA.request has been activated and if acknowledged LLC operation has been established.

The N‑PDU number in acknowledged mode is a number assigned to each N‑PDU received by SNDCP through an SN‑DATA.request. N‑PDU numbers for different NSAPIs shall be assigned independently. The N‑PDU number shall be included in the SNDCP header of the first segment of an N‑PDU.

Two variables, the Send N‑PDU number and the Receive N‑PDU number, shall be maintained for each NSAPI using acknowledged peer-to-peer LLC operation. When an NSAPI using acknowledged peer-to-peer LLC operation is activated, the Send N‑PDU number and the Receive N‑PDU number shall be set to 0. The Send N‑PDU number and Receive N‑PDU number shall also be set as described in subclause 5.1.2.22. Modulo 256 operation shall be applied to the Send N‑PDU number and the Receive N‑PDU number.

Upon reception of an SN‑DATA.request, the SNDCP entity shall assign to the N‑PDU received the current value of the Send N‑PDU number as the N‑PDU number, increment the Send N‑PDU number by 1, perform the compression and segmentation functions, then forward the SN‑PDU(s) in LL‑DATA.request to the LLC layer. If an N‑PDU number is already present in the SN‑DATA.request, then no new N‑PDU number shall be assigned to the N‑PDU, and the Send N‑PDU number shall not be incremented. The N‑PDU shall be stored into a buffer in the SNDCP entity. The buffered N‑PDU shall be deleted when the SN‑DATA PDU carrying the last segment of the N‑PDU is confirmed by an LL‑DATA.confirm primitive, or when the entire N‑PDU is confirmed by an SNSM-SEQUENCE.indication primitive.

During normal operation (i.e., not in the recovery state), when the peer SNDCP entity receives the SN‑PDU(s) in an LL‑DATA.indication primitive, the SNDCP entity shall reassemble and decompress the SN‑PDU(s) to obtain the N‑PDU, increment the Receive N‑PDU number by 1, and forward the N‑PDU to the SNDCP user with the SN‑DATA.indication. The correct SNDCP user is identified by the NSAPI field in the SN‑PDU(s).

In the recovery state, after reassembling and decompressing the SN‑PDU(s):

– if the N‑PDU number of the received N‑PDU is equal to the Receive N‑PDU number, then the Receive N‑PDU number shall be incremented by 1, the recovery state shall be exited and normal operation shall resume for the received N‑PDU and all subsequently-received N‑PDUs; and

– otherwise, the N‑PDU shall be discarded.

After the SNDCP entity in the SGSN receives an SNSM-STOP-ASSIGN.indication primitive for an NSAPI using acknowledged peer-to-peer LLC operation, it shall stop assigning N‑PDU number to N‑PDUs received through the SN‑DATA.request primitive.

If an SN‑DATA PDU (T bit set to 0) is received by an NSAPI that does not use acknowledged mode, the PDU shall be ignored without error notification.

Figure 13: SNDCP acknowledged data transfer

6.9.2 Unacknowledged mode

The SNDCP entity shall initiate unacknowledged data transmission only if the PDP context for the NSAPI identified in the SN‑DATA.request has been activated. The SNDCP entity may initiate unacknowledged data transmission even if the acknowledged peer-to-peer operation is not established for that NSAPI.

The N‑PDU number in unacknowledged mode is a number assigned to each N‑PDU received by SNDCP through an SN‑UNITDATA.request. N‑PDU numbers for different NSAPIs shall be assigned independently. The N‑PDU number shall be included in the SNDCP header of every SN‑UNITDATA PDU.

A variable, the Send N‑PDU number (unacknowledged), shall be maintained for each NSAPI using unacknowledged peer-to-peer LLC operation. When an NSAPI using unacknowledged peer-to-peer LLC operation is activated, the Send N‑PDU number (unacknowledged) shall be set to 0. The Send N‑PDU number (unacknowledged) shall also be set as described in subclauses 5.1.2.1 and 5.1.2.22. Modulo 4096 operation shall be applied to the Send N‑PDU number (unacknowledged).

Upon reception of an SN‑UNITDATA.request, the SNDCP entity shall assign the current value of the Send N‑PDU number (unacknowledged) as the N‑PDU number of the N‑PDU received, increment Send N‑PDU number (unacknowledged) by 1, compress and segment the information, then forward the SN‑PDU(s) in LL‑UNITDATA.request to the LLC layer. The N‑PDU shall be deleted immediately after the data has been delivered to the LLC layer.

When the peer SNDCP entity receives the SN‑PDU(s) in the LL‑UNITDATA.indication primitive, the SNDCP entity shall reassemble and decompress the SN‑PDU(s) to obtain the N‑PDU, then forwards it to the SNDCP user with the SN‑UNITDATA.indication. The correct SNDCP user is identified by the NSAPI field in the SN‑PDU(s).

If an SN‑UNITDATA PDU (T bit set to 1) is received by an NSAPI that does not use unacknowledged mode, the PDU shall be ignored without error notification.

The SNDCP entity shall detect lost SN‑PDUs. The SNDCP entity shall discard duplicate SN‑PDUs and re-order out-of-sequence SN‑PDUs, if possible.

Figure 14: SNDCP unacknowledged data transfer

6.10 Possible combinations of SNDCP protocol functions and their connection to service access points

The following combinations of SNDCP protocol functions are allowed:

– One or several NSAPIs may use one SAPI.

– Only one SAPI shall be used by one NSAPI.

– One or several NSAPIs may use the same protocol control information compression entity.

– One NSAPI may use zero, one, or several protocol control information compression entities.

– One or several NSAPIs may use the same data compression entity.

– One NSAPI may use zero, one, or several data compression entities.

– Separate data compression entities shall be used for SN‑DATA and SN‑UNITDATA PDUs.

– Separate protocol control information compression entities shall be used for SN‑DATA and SN‑UNITDATA PDUs.

– One data compression entity shall be connected to one SAPI.

– One protocol control information compression entity shall be connected to one SAPI.

– One or several protocol control information compression entities may be connected to the same data compression entity.

– One protocol control information compression entity shall be connected to zero, one, or several data compression entities.