SIST ETS 300 428 E1:2005

Broadband Integrated Services Digital Network (B-ISDN); Asynchronous Transfer Mode (ATM); Adaptation Layer (AAL) specification - type 5

Define an AAL type 5 for the support of connection oriented data services

Širokopasovno digitalno omrežje z integriranimi storitvami (B-ISDN) – Specifikacija prilagodilne plasti (AAL) asinhronega prenosnega načina (ATM) – tip 5

General Information

• Status: Published
• Publication Date: 31-Jan-2005
• ICS: 33.080 - Integrated Services Digital Network (ISDN)
• Technical Committee: RES - Radio equipment and systems
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Feb-2005
• Due Date: 01-Feb-2005
• Completion Date: 01-Feb-2005
• Ref Project: ETSI ETS 300 428 ed.1 (1995-08) - Broadband Integrated Services Digital Network (B-ISDN); Asynchronous Transfer Mode (ATM); Adaptation Layer (AAL) specification - type 5

Standards Content (Sample)

SLOVENSKI STANDARD
SIST ETS 300 428 E1:2005
01-februar-2005
âLURNRSDVRYQRGLJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL%,6'1±
6SHFLILNDFLMDSULODJRGLOQHSODVWL$$/DVLQKURQHJDSUHQRVQHJDQDþLQD$70±WLS

Broadband Integrated Services Digital Network (B-ISDN); Asynchronous Transfer Mode
(ATM); Adaptation Layer (AAL) specification - type 5
Ta slovenski standard je istoveten z: ETS 300 428 Edition 1
ICS:
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
SIST ETS 300 428 E1:2005 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST ETS 300 428 E1:2005

---------------------- Page: 2 ----------------------

SIST ETS 300 428 E1:2005
EUROPEAN ETS 300 428
TELECOMMUNICATION August 1995
STANDARD
Source: ETSI TC-NA Reference: DE/NA-052619
ICS: 33.040
B-ISDN, ATM
Key words:
Broadband Integrated Services Digital Network (B-ISDN);
Asynchronous Transfer Mode (ATM)
Adaptation Layer (AAL) specification - type 5
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
F-06921 Sophia Antipolis CEDEX - FRANCE
Postal address:
650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
Office address:
c=fr, a=atlas, p=etsi, s=secretariat - [e-mail]
X.400: Internet:
Tel.: [phone] - Fax: [phone]
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1995. All rights reserved.
New presentation - see History box

---------------------- Page: 3 ----------------------

SIST ETS 300 428 E1:2005
Page 2
ETS 300 428: August 1995
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Standards Approval Dept." at the address shown on the title page.

---------------------- Page: 4 ----------------------

SIST ETS 300 428 E1:2005
Page 3
ETS 300 428: August 1995
Contents
Foreword .5
Introduction.5
1 Scope .7
2 Normative references.7
3 Definitions.7
4 Abbreviations.8
5 AAL type 5.9
5.1 Framework of AAL type 5 .9
5.2 Information flow across the AAL-ATM boundary .10
5.3 Service provided by the AAL type 5 .10
5.3.1 Description of AAL type 5 connections.11
5.3.2 Primitives for the AAL type 5 .12
6 The common part of the AAL type 5 .13
6.1 Services provided by the common part of the AAL type 5.13
6.1.1 Primitives.13
6.1.1.1 Primitives for the CPCS of the AAL type 5 .13
6.1.1.1.1 Primitives for the data transfer service .14
6.1.1.1.2 Primitives for the abort service .15
6.1.1.2 Service provided by the SAR sublayer .16
6.1.1.3 Primitives for the SAR sublayer of the AAL type 5 .16
6.1.1.3.1 Primitives for the data transfer service .16
6.2 Interaction with the management and control plane .17
6.3 Functions, structure, and coding of the AAL type 5 .17
6.3.1 Segmentation And Reassembly (SAR) sublayer.17
6.3.1.1 Functions of the SAR sublayer .17
6.3.1.2 SAR-PDU structure and coding.18
6.3.2 Convergence Sublayer (CS).18
6.3.2.1 Functions, structure, and coding for the CPCS .18
6.3.2.1.1 Functions of the CPCS .18
6.3.2.1.2 CPCS structure and coding .20
6.4 Procedures.22
6.4.1 Procedures of the SAR sublayer .22
6.4.1.1 State variables of the SAR sublayer at the sender side .22
6.4.1.2 Procedures of the SAR sublayer at the sender side.22
6.4.1.3 State variables of the SAR sublayer at the receiver side.23
6.4.1.4 Procedures of the SAR sublayer at the receiver side.23
6.4.2 Procedures of the CPCS for the Message Mode service.23
6.4.2.1 State variables of the CPCS at the sender side .23
6.4.2.2 Procedures of the CPCS at the sender side.23
6.4.2.3 State variables of the CPCS at the receiver side.24
6.4.2.4 Procedures of the CPCS at the receiver side.24
6.4.3 Summary of parameters and values for an AAL type 5 connection .25
Annex A (informative): Details of the data unit naming convention.26
Annex B (informative): General framework of the AAL type 5 .28
B.1 Message segmentation and reassembly.28
B.2 PDU Headers, trailers and terminology.29

---------------------- Page: 5 ----------------------

SIST ETS 300 428 E1:2005
Page 4
ETS 300 428: August 1995
B.3 Examples of the segmentation and reassembly process . 30
Annex C (informative): Functional model for the AAL type 5. 31
Annex D (informative): Specification and Description Language (SDL) diagrams for the SAR and the
CPCS of the AAL type 5 . 33
D.1 SDL for the SAR sublayer. 33
D.1.1 The SAR sender. 33
D.1.2 The SAR receiver. 35
D.2 SDL for the CPCS procedures . 35
D.2.1 The CPCS sender . 35
D.2.2 The CPCS receiver . 36
Annex E (informative): Example CPCS-PDUs for the AAL type 5. 39
Annex F (normative): Protocol Implementation Conformance Statement (PICS) proforma . 40
F.1 Identification of the implementation . 40
F.2 Identification of the protocol. 40
F.3 Global statement of conformance . 40
F.4 Capabilities . 40
F.4.1 Initiator/responder capability . 40
F.4.2 Major capabilities. 40
F.4.2.1 Transmission capabilities . 41
F.4.2.1.1 Protocol parameters for transmission. 41
F.4.2.1.2 PDUs for transmission . 41
F.4.2.1.2.1 Data CPCS-PDU parameters for
transmission. 42
F.4.2.1.2.2 Abort CPCS-PDU parameters for
transmission. 42
F.4.2.1.2.3 AUU-0 SAR-PDU parameters for
transmission. 42
F.4.2.1.2.4 AUU-1 SAR-PDU parameters for
transmission. 43
F.4.2.2 Receipt capabilities. 43
F.4.2.2.1 Receipt timers/ protocol parameters for reception. 43
F.4.2.2.2 Support of PDUs received . 43
F.4.2.2.2.1 Data CPCS-PDU parameters at
receipt. 44
F.4.2.2.2.2 Abort CPCS-PDU parameters at
receipt. 44
F.4.2.2.2.3 AUU 0 SAR-PDU parameters at
receipt. 44
F.4.2.2.2.4 AUU 1 SAR-PDU parameters at
receipt. 45
F.4.2.3 Protocol error handling . 45
F.4.3 Negotiation capabilities . 45
F.4.4 Multi-layer dependencies . 45
F.4.5 Other conditions . 45
Annex G (informative): Bibliography . 46
History. 47

---------------------- Page: 6 ----------------------

SIST ETS 300 428 E1:2005
Page 5
ETS 300 428: August 1995
Foreword
This European Telecommunication Standard (ETS) has been prepared by the Network Aspects (NA)
Technical Committee of the European Telecommunications Standards Institute (ETSI).
The content of this ETS is derived from ITU-T Recommendation I.363 [2].
This ETS constitutes one of a set of ETSs describing different Asynchronous Transfer Mode (ATM)
Adaptation Layer (AAL) types.
Transposition dates
Date of adoption of this ETS: 28 July 1995
Date of latest announcement of this ETS (doa): 30 November 1995
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 31 May 1996
Date of withdrawal of any conflicting National Standard (dow): 31 May 1996
Introduction
The AAL type 5 enhances the service provided by the ATM layer to support functions required by the next
higher layer. The AAL type 5 performs functions required by the user, control and management planes
and supports the adaptation between the ATM layer and the next higher layer. The functions performed in
the AAL type 5 depend upon the higher layer requirements.
The AAL supports multiple protocols (AAL types) to suit the needs of the different AAL service users. The
service provided by the AAL type 5 to the higher layer and the functions performed are specified in this
ETS.

---------------------- Page: 7 ----------------------

SIST ETS 300 428 E1:2005
Page 6
ETS 300 428: August 1995
Blank page

---------------------- Page: 8 ----------------------

SIST ETS 300 428 E1:2005
Page 7
ETS 300 428: August 1995
1 Scope
This European Telecommunication Standard (ETS) specifies the interactions between the Asynchronous
Transfer Mode (ATM) Adaptation Layer (AAL) type 5 and the next higher layer, and the AAL type 5 and
the ATM layer, as well as AAL type 5 peer-to-peer operations.
This ETS is applicable to variable bitrate sources where there exists no timing relation between the source
and the destination of the data.
This ETS defines the common part of AAL type 5 and can be complemented with standards for the
service specific part of the convergence sublayer.
2 Normative references
This ETS incorporates by dated or undated reference provisions from other publications. These normative
references are cited at the appropriate places in the text and the publications are listed hereafter. For
dated references, subsequent amendments to or revisions of any of these publications apply to this ETS
only when incorporated in it by amendment or revision. For undated references, the latest edition of the
publication referred to applies.
[1] ITU-T Recommendation I.361 (1993): "B-ISDN ATM layer specification".
[2] ITU-T Recommendation I.363 (1993): "B-ISDN ATM adaptation layer
specification".
3 Definitions
Illustration of the data unit naming convention used in this ETS can be found in annex A.
In addition, for the purposes of this ETS, the following definitions apply:
message mode: A Service Data Unit (SDU) is passed across the (sub)layer interface in exactly one
Interface Data Unit (IDU) (see note).
streaming mode: A SDU is passed across the (sub)layer interface in one or more IDUs. The transfer of
the IDUs across the (sub)layer may occur separated in time (see note).
pipelining: The sending peer entity initiates the data transfer to the receiving peer entity before the
complete SDU is available (see note).
NOTE: The implementation of these concepts is not always externally visible.

---------------------- Page: 9 ----------------------

SIST ETS 300 428 E1:2005
Page 8
ETS 300 428: August 1995
4 Abbreviations
For the purposes of this ETS, the following abbreviations apply:
AAL ATM Adaptation Layer
AAL-IDU AAL type 5 IDU
AAL-SAP AAL Service Access Point
AAL-SDU AAL type 5 Service Data Unit
ATM Asynchronous Transfer Mode
ATM-SDU ATM Service Data Unit
AUU ATM-layer-User to ATM-layer-User indication
CLP Cell Loss Priority
CPCS Common Part Convergence Sublayer
CPCS-CI CPCS-Congestion Indication
CPCS-IDU CPCS Interface Data Unit
CPCS-LP CPCS-Loss Priority
CPCS-PDU CPCS Protocol Data Unit
CPCS-SDU CPCS Service Data Unit
CPCS-UU CPCS-User to User indication
CPI Common Part Indicator
CRC Cyclic Redundancy Check
CS Convergence Sublayer
ID Interface Data
IDU Interface Data Unit
LP Loss Priority
M More
MM Message Mode
Pad Padding
PICS Protocol Implementation Conformance Statement
PT Payload Type
QoS Quality of Service
RS Reception Status
SAP Service Access Point
SAR Segmentation And Reassembly
SAR-CI SAR-Congestion Indication
SAR-IDU SAR IDU
SAR-LP SAR-Loss Priority
SAR-PDU SAR Protocol Data Unit
SAR-SDU SAR Service Data Unit
SDU Service Data Unit
SDL Specification and Description Language
SM Streaming Mode
SSCS Service Specific CS
SSCS-PDU SSCS Protocol Data Unit

---------------------- Page: 10 ----------------------

SIST ETS 300 428 E1:2005
Page 9
ETS 300 428: August 1995
5 AAL type 5
5.1 Framework of AAL type 5
The Convergence Sublayer (CS) has been subdivided into the Common Part CS (CPCS) and the Service
Specific CS (SSCS) as shown in figure 1 (further clarification can be found in annex C). Different SSCS
protocols, to support specific AAL type 5 user services, or groups of services, may be defined. The SSCS
may also be null, in the sense that it only provides for the mapping of the equivalent primitives of the AAL
type 5 to CPCS and vice-versa. SSCS protocols are specified in separate ETSs.
The description contained in this ETS defines the functional behaviour of the AAL type 5 common part and
does not preclude any implementation as long as the external behaviour of the implementation follows this
ETS. The separation of the functionality between SAR and CPCS is arbitrary and is not visible to the
outside. The allocation of functions to the two sublayers has been made in order to simplify the
description.
SAP
Service Specific CS
SSCS
(may be Null)
Primitives CS
CPCS
Common Part CS
AAL
Primitives
SAR
SAR
SAP
Figure 1: Structure of the AAL type 5

---------------------- Page: 11 ----------------------

SIST ETS 300 428 E1:2005
Page 10
ETS 300 428: August 1995
5.2 Information flow across the AAL-ATM boundary
The AAL type 5 makes use of the ATM layer services as defined in ITU-T Recommendation I.361 [1].
NOTE: The addition of the "Received Loss Priority" parameter in the ATM-DATA-indication
primitive as agreed by CCITT SG XVIII in January 1993 is assumed.
5.3 Service provided by the AAL type 5
The AAL type 5 provides the capabilities to transfer the AAL type 5 Service Data Unit (AAL-SDU) from one
AAL type 5 user to another AAL type 5 user through the ATM network. The Message Mode service,
Streaming Mode service, and assured and non-assured operations as defined below for AAL type 5 are
identical to those defined for AAL type 3/4 (see ETS 300 349).
Two modes of service are defined: Message and Streaming:
a) Message Mode service: the AAL-SDU is passed across the AAL type 5 interface in exactly one AAL
type 5 Interface Data Unit (AAL-IDU). This service provides the transport of fixed size or variable
length AAL-SDUs:
1) in case of short fixed size AAL-SDUs an internal blocking/deblocking function in the SSCS
may be applied; it provides the transport of one or more fixed size AAL-SDUs in one SSCS
Protocol Data Unit (SSCS-PDU);
2) in case of variable length AAL-SDUs an internal AAL-SDU message
segmentation/reassembling function in the SSCS may be applied. In this case, a single
AAL-SDU is transferred in one or more SSCS-PDUs;
3) where the above options are not used, a single AAL-SDU is transferred in one SSCS-PDU.
When the SSCS is null, the AAL-SDU is mapped to one CPCS Service Data Unit
(CPCS-SDU);
b) Streaming Mode service: the AAL-SDU is passed across the AAL type 5 interface in one or more
AAL-IDU. The transfer of these AAL-IDUs across the AAL type 5 interface may occur separated in
time. This service provides the transport of variable length AAL-SDUs:
1) an internal AAL-SDU message segmentation/reassembling function in the SSCS may be
applied. In this case all the AAL-IDUs belonging to a single AAL-SDU are transferred in one
or more SSCS-PDU;
2) an internal pipelining function may be applied. It provides the means by which the sending
AAL type 5 entity initiates the transfer to the receiving AAL type 5 entity before it has the
complete AAL-SDU available;
3) where option 1) is not used, all the AAL-IDUs belonging to a single AAL-SDU are transferred
in one SSCS-PDU. When the SSCS is null, the AAL-IDUs belonging to a single AAL-SDU are
mapped to one CPCS-SDU.
The Streaming Mode service includes an abort service by which the discarding of an AAL-SDU
partially transferred across the AAL type 5 interface can be requested.
Summaries of the service mode and feature options are provided in tables 1 and 2.
NOTE: An end-to-end specification of the SDU length in Message Mode with
Blocking/Deblocking is needed.

---------------------- Page: 12 ----------------------

SIST ETS 300 428 E1:2005
Page 11
ETS 300 428: August 1995
Table 1: Combination of service mode and internal function
AAL-SDU Message AAL-SDU Message Pipelining
Segmentation/reassembly Blocking/deblocking
in the SSCS in the SSCS
Message
Option 1 O N/A N/A
Option 2 N/A O N/A
Streaming O N/A O
Option 1: Long variable size SDUs O: Optional
Option 2: Short fixed size SDUs N/A: Not Applicable
Table 2: Combination of service mode at the sender and receiver side
Receiver Sender
MM/Blocking MM/Segmentation SM
MM/Deblocking A N/A N/A
MM/Reassembly N/A A A
SM N/A A A
MM: Message Mode A: Applicable
SM: Streaming Mode N/A: Not Applicable
Both modes of service may offer the following peer-to-peer operational procedures:
- assured operations:
every assured AAL-SDU is delivered with exactly the data content that the user sent. The assured
service is provided by retransmission of missing or corrupted SSCS-PDUs. Flow control is provided
as a mandatory feature. The assured operation may be restricted to point-to-point AAL type 5
connections;
- non-assured operations:
integral AAL-SDUs may be lost or corrupted. Lost and corrupted AAL-SDUs are not corrected by
retransmission. An optional feature may be provided to allow corrupted AAL-SDUs to be delivered
to the user (i.e. optional delivery of corrupted data). Flow control may be provided as an option.
5.3.1 Description of AAL type 5 connections
The AAL type 5 provides the capabilities to transfer the AAL-SDU from one AAL Service Access Point
(AAL-SAP) to one other AAL-SAP through the ATM network (see figure 2). The AAL type 5 users have the
capability to select a given AAL-SAP associated with the Quality of Service (QoS) required to transport
that AAL-SDU (for example, delay and loss sensitive QoS).
The AAL type 5 makes use of the service provided by the underlying ATM layer (see figure 3). Multiple
AAL type 5 connections may be associated with a single ATM layer connection, allowing multiplexing at
the AAL type 5; however, if multiplexing is used in the AAL type 5, it occurs in the SSCS. The AAL type 5
user selects the QoS provided by the AAL type 5 through the choice of the AAL-SAP used for data
transfer.

---------------------- Page: 13 ----------------------

SIST ETS 300 428 E1:2005
Page 12
ETS 300 428: August 1995
AAL-SAP AAL-SAP
AAL-Connection
AAL
ATM
AAL-Entity AAL-Entity
Point-to-point
ATM Layer Connection
Figure 2: Point-to-Point AAL type 5 connection
5.3.2 Primitives for the AAL type 5
These primitives are service specific and are contained in separate Standards on SSCS protocols.
The SSCS may be null, in the sense that it only provides for the mapping of the equivalent primitives of
the AAL type 5 to CPCS and vice-versa. In this case, the primitives for the AAL type 5 are equivalent to
those for the CPCS (subclause 6.1.1.1) but identified as AAL-UNITDATA-request, AAL-UNITDATA-
indication, AAL-U-Abort-request, AAL-U-Abort-indication and AAL-P-Abort-indication, consistent with the
primitive naming convention at a Service Access Point (SAP).
AAL-SAP AAL-SAP AAL-SAP
12 3
Service provided
(Q OS 1) (QOS2) (QOS3)
to the AAL-users
AAL Layer
(N O TE)
M akes use of the
ATM-SAP ATM-SAP
underlying ATM
mn
Layer service
ATM Layer
NOTE: If multiplexing is present at the AAL type 5, it occurs in the SSCS.
Figure 3: Relation between AAL-SAP and ATM-SAP

---------------------- Page: 14 ----------------------

SIST ETS 300 428 E1:2005
Page 13
ETS 300 428: August 1995
6 The common part of the AAL type 5
6.1 Services provided by the common part of the AAL type 5
Two modes of service are defined, message and streaming:
a) Message Mode service: The CPCS Service Data Unit is passed across the CPCS interface in
exactly one CPCS-IDU. This service provides the transport of fixed size or variable length
CPCS-SDUs. A single CPCS-SDU is transferred in one CPCS Protocol Data Unit (CPCS-PDU);
b) Streaming Mode service: The CPCS-SDU is passed across the CPCS interface in one or more
CPCS-IDUs. The transfer of these CPCS-IDUs across the CPCS interface may occur separated in
time. This service provides the transport of variable length CPCS-SDUs. The Streaming Mode
service includes an abort service by which the discarding of an CPCS-SDU partially transferred
across the CPCS interface can be requested.
An internal pipelining function may be applied. It provides the means by which the sending CPCS
entity initiates the transfer to the receiving CPCS entity before it has the complete CPCS-SDU
available.
All the CPCS-IDUs belonging to a single CPCS-SDU are transferred in one CPCS-PDU.
NOTE: Figures A.2.a) and A.2.d) of annex A illustrate the Message Mode and Streaming
Mode services.
The following peer-to-peer operational procedure is offered:
- non-assured operations:
integral CPCS-SDUs may be lost or corrupted. Lost and corrupted CPCS-SDUs will not be
corrected by retransmission. An optional feature may be provided to allow corrupted CPCS-SDUs to
be delivered to the user (i.e. optional delivery of corrupted data).
6.1.1 Primitives
The functional model for the AAL type 5 as contained in annex C shows the interrelation between the
Segmentation And Reassembly (SAR) sublayer, CPCS and SSCS and the SAR and CPCS primitives.
CPCS and SAR connection establishment and release can be done via signalling, management or
prearrangement. The CPCS connection and the corresponding SAR connection are established
simultaneously. There is no provision for CPCS or SAR connection establishment and release in the
CPCS or the SAR protocol.
6.1.1.1 Primitives for the CPCS of the AAL type 5
As there exists no SAP between the sublayers of the AAL type 5, the primitives are called "invoke" and
"signal" instead of the conventional "request" and "indication" to highlight the absence of the SAP.

---------------------- Page: 15 ----------------------

SIST ETS 300 428 E1:2005
Page 14
ETS 300 428: August 1995
6.1.1.1.1 Primitives for the data transfer service
CPCS-UNITDATA-invoke and CPCS-UNITDATA-signal.
These primitives are used for the data transfer. The following parameters are defined:
- Interface Data (ID).
This parameter specifies the Interface Data Unit (IDU) exchanged between the CPCS and the
SSCS entity. The ID is an integral multiple of one octet. If the CPCS entity is operating in the
Message Mode service, the ID represents a complete CPCS-SDU; when operating in the Streaming
Mode service, the ID does not necessarily represent a complete CPCS-SDU. When the corrupted
data delivery option is used, the ID parameter may be empty;
- More (M).
In the Message Mode service, this parameter is not used. In the Streaming Mode service, this
parameter specifies whether the ID communicated contains a beginning / continuation of a
CPCS-SDU or the end of / complete CPCS-SDU;
- CPCS Loss Priority (CPCS-LP).
This parameter indicates the loss priority for the associated CPCS-SDU. It can take only two values,
one for high priority and the other for low priority. In Streaming Mode, this parameter is mandatory
with the first invoke primitive related to a certain CPCS-SDU; otherwise, it is ignored and may be
absent. At the receiving side, this parameter is only present with the last signal primitive related to a
certain CPCS-SDU. This parameter is mapped to and from the SAR Loss Priority (SAR-LP)
parameter. In general, this parameter has no end-to-end significance;
- CPCS Congestion Indication (CPCS-CI).
This parameter indicates whether the associated CPCS-SDU has experienced congestion. In
Streaming Mode, this parameter is mandatory with the first invoke primitive related to a certain
CPCS-SDU; otherwise, it is not present. At the receiving side, this parameter is only present with
the last signal primitive related to a certain CPCS-SDU. This parameter is mapped to and from the
SAR-Congestion Indication (SAR-CI) parameter;
- CPCS User to User indication (CPCS-UU).
This parameter is transparently transported by the CPCS between peer CPCS users. In Streaming
Mode, this parameter is mandatory with the last invoke primitive related to a certain CPCS-SDU;
otherwise, it is not present. At the receiving side, this parameter is only present with the last signal
primitive related to a certain CPCS-SDU;
- Reception Status (RS).
This parameter indicates whether or not the associated CPCS-SDU delivered may be corrupted.
This parameter is only utilized if the corrupted data delivery option is used. In Streaming Mode, this
parameter is only present with the last signal primitive related to a certain CPCS-SDU.
Depending on the service mode (Message Mode or Streaming Mode service, discarding or delivery of
errored information), not all parameters are required. This is summarized in table 3.

---------------------- Page: 16 ----------------------

SIST ETS 300 428 E1:2005
Page 15
ETS 300 428: August 1995
Table 3: Parameters of the CPCS-UNITDATA
Parameter Type MM SM Comments
Interface Data (ID) invoke m m whole or partial CPCS-SDU
signal m m
More (M) invoke - m M = 0: end of CPCS-SDU
signal - m M = 1: not end of CPCS-SDU
1
CPCS-Loss priority invoke m m mapped to and from the ATM layer's CLP field
2
(CPCS-LP) signal m m CPCS-LP = 1: Low priority
CPCS-LP = 0: High priority
1
CPCS-Congestion invoke m m mapped to and from the ATM
...