ETSI ETS 300 428 ed.1 (1995-08)

SLOVENSKI STANDARD
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)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

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 - secretariat@etsi.fr
X.400: Internet:
Tel.: +33 92 94 42 00 - Fax: +33 93 65 47 16
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 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 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 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 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 6
ETS 300 428: August 1995
Blank page
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 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 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 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 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 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 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 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 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
CPCS-Loss priority invoke m m mapped to and from the ATM layer's CLP field
(CPCS-LP) signal m m CPCS-LP = 1: Low priority
CPCS-LP = 0: High priority
CPCS-Congestion invoke m m mapped to and from the ATM layer's Congestion
Indication (CPCS-CI) signal m m Indication parameter
CPCS-CI = 1: Congestion experienced
CPCS-CI = 0: No congestion experienced
CPCS-User to User invoke m m transparently transported by the CPCS
Indication (CPCS-UU) signal m m
Reception Status (RS) invoke - - indication of corrupted data
(note) signal m m
MM: Message Mode service.
SM: Streaming Mode service.
m: mandatory.
-: not present.
m : mandatory with the first invoke or signal primitive related to a certain CPCS-SDU, otherwise
absent.
m : mandatory with the last invoke or signal primitive related to a certain CPCS-SDU, otherwise
absent.
NOTE: Not present if the corrupted data delivery option is not used.
6.1.1.1.2 Primitives for the abort service
These primitives are used in the Streaming Mode service:
a) CPCS-U-Abort-invoke and CPCS-U-Abort-signal.
This primitive is used by the CPCS user to invoke the abort service. It is also used to signal to the
CPCS user that a partially delivered CPCS-SDU is to be discarded by instruction from its peer
entity. No parameters are defined.
This primitive is not used in Message Mode;
b) CPCS-P-Abort-signal.
This primitive is used by the CPCS entity to signal to its user that a partially delivered CPCS-SDU is
to be discarded due to the occurrence of some error in the CPCS or below. No parameters are
defined.
This primitive is not used in Message Mode.

Page 16
ETS 300 428: August 1995
6.1.1.2 Service provided by the SAR sublayer
Two modes of service are defined: message and streaming:
a) Message Mode service: the SAR Service Data Unit (SAR-SDU) is passed across the SAR interface
in exactly one SAR-IDU. This service provides the transport of fixed size or variable length
SAR-SDUs. A single SAR-SDU is transferred in one or more SAR Protocol Data Units
(SAR-PDUs);
b) Streaming Mode service: the SAR-SDU is passed across the SAR interface in one or more
SAR-IDUs. The transfer of these SAR-IDUs across the SAR interface may occur separated in time.
This service provides the transport of variable length SAR-SDUs.
The SAR receiver always operates in Streaming Mode.
An internal pipelining function is applied. It provides the means by which the sending SAR entity initiates
the transfer to the receiving SAR entity before it has the complete SAR-SDU available.
Figure A.2.d) of annex A illustrates the Streaming Mode service.
The following peer-to-peer operational procedure is offered:
- non-assured operations.
Integral SAR-SDUs may be lost or corrupted. Lost and corrupted SAR-SDUs will not be corrected
by retransmission. An optional feature may be provided to allow corrupted SAR-SDUs to be
delivered to the user (i.e. optional delivery of corrupted data).
6.1.1.3 Primitives for the SAR sublayer of the AAL type 5
These primitives model the exchange of information between the SAR sublayer and the CPCS.
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.
6.1.1.3.1 Primitives for the data transfer service
SAR-UNITDATA-invoke and SAR-UNITDATA-signal.
These primitives are used for the data transfer. The following parameters are defined:
NOTE: It is assumed that the SAR sender operates in Streaming Mode.
- Interface Data (ID).
This parameter specifies the IDU exchanged between the SAR and the CPCS entity. The ID is an
integral multiple of 48 octets. The ID does not necessarily represent a complete SAR-SDU;
- More (M).
This parameter specifies whether the ID communicated contains the end of the SAR-SDU;
- SAR-Loss Priority (SAR-LP).
This parameter indicates the loss priority for the associated SAR ID. It can take only two values,
one for high priority, and the other for low priority. This parameter is mapped to the ATM layer's
Submitted Loss Priority parameter and from the ATM layer's Received Loss Priority parameter;
- SAR-Congestion Indication (SAR-CI).
This parameter indicates whether the associated SAR ID has experienced congestion. This
parameter is mapped to and from the ATM layer's Congestion Indication parameter.

Page 17
ETS 300 428: August 1995
The usage of the parameters is summarized in table 4.
Table 4: Parameters of the SAR-UNITDATA
Parameter Type Comments
Interface Data (ID) invoke m whole or partial SAR-SDU
signal m
More (M) invoke m M = 0: end of SAR-PDU
signal m M = 1: not end of SAR-PDU
SAR-Loss Priority invoke m mapped to and from the ATM layer's CLP field
(SAR-LP) signal m SAR-LP = 1: Low priority
SAR-LP = 0: High priority
SAR-Congestion invoke m mapped to and from the ATM layer's Congestion
Indication (SAR-CI) signal m Indication parameter
SAR-CI = 1: Congestion experienced
SAR-CI = 0: No congestion experienced
m: mandatory.
6.2 Interaction with the management and control plane
Currently, no interactions with the management and control plane are standardized.
6.3 Functions, structure, and coding of the AAL type 5
6.3.1 Segmentation And Reassembly (SAR) sublayer
6.3.1.1 Functions of the SAR sublayer
The SAR sublayer functions are performed on a SAR-PDU basis. The SAR sublayer accepts variable
length SAR-SDUs which are integral multiples of 48 octets from the CPCS and generates SAR-PDUs
containing 48 octets of SAR-SDU data.
a) Preservation of SAR-SDU.
This function preserves the SAR-SDU by providing for an "end of SAR-SDU" indication.
b) Handling of congestion information.
This function provides for the passing of congestion information between the layers above the SAR
sublayer and the one below in both directions.
c) Handling of loss priority information.
This function provides for the passing of cell loss priority information between the layers above the
SAR sublayer and the one below in both directions.
d) SAR-SDU sequence integrity.
This function assures that the sequence of SAR-SDUs is maintained within one SAR connection.
e) Mapping between SAR connections and ATM connections.
This function provides for the one-to-one mapping between SAR connections and ATM
connections. Neither SAR connection multiplexing nor splitting is provided.

Page 18
ETS 300 428: August 1995
6.3.1.2 SAR-PDU structure and coding
The SAR sublayer functions utilize the ATM-layer-user to ATM-layer-user indication (AUU) parameter of
the ATM layer primitives to indicate that a SAR-PDU contains the end of a SAR-SDU. A SAR-PDU where
the value of the AUU parameter is "1" indicates the end of a SAR-SDU; the value of "0" indicates the
beginning or continuation of a SAR-SDU. The structure of the SAR-PDU is illustrated in figure 4.
C ell H eader SAR-PDU Payload
PT
SAR-PDU
PT: Payload Type
NOTE: The Payload Type field belongs to the ATM header. It conveys the value of the AUU parameter
end-to-end.
Figure 4: SAR-PDU format for the AAL type 5
6.3.2 Convergence Sublayer (CS)
6.3.2.1 Functions, structure, and coding for the CPCS
The CPCS has the following service characteristics:
- non-assured data transfer of user data frames with any length measured in octets from 1 to
65 535 octets. In addition, an independent octet of user to user information per frame is transferred;
- the CPCS connection is established by management or by the control plane;
- error detection and indication (bit error and cell loss or gain);
- CPCS-SDU sequence integrity on each CPCS connection.
6.3.2.1.1 Functions of the CPCS
The CPCS functions are performed per CPCS-PDU. The CPCS provides several functions in support of
the CPCS service user. The functions provided depend on whether the CPCS service user is operating in
Message Mode or Streaming Mode:
a) Message Mode service: the CPCS-SDU is passed across the CPCS interface in exactly one
CPCS-IDU. This service provides the transport of a single CPCS-SDU in one 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.
- General description: This service provides the transport of all the CPCS-IDUs belonging to
a single CPCS-SDU within one CPCS-PDU.
- Pipelining function: An internal pipelining function in the CPCS may be applied which
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.
- Abort service: The Streaming Mode service includes an abort service by which the
discarding of a CPCS-SDU partially transferred across the interface can be requested.
NOTE: At the sending side, parts of the CPCS-PDU may have to be buffered if the restriction
(i.e. that SAR ID are a multiple of 48 octets, see subclause 6.3.1.1) cannot be
satisfied.
Page 19
ETS 300 428: August 1995
The functions implemented by the CPCS include:
1) preservation of CPCS-SDU.
This function provides for the delineation and transparency of CPCS-SDUs;
2) preservation of CPCS user to user information.
This function provides for the transparent transfer of CPCS user to user information;
3) error detection and handling.
This function provides for the detection and handling of CPCS-PDU corruption. By default,
corrupted CPCS-SDUs are discarded. A CPCS receiver may provide the local option to deliver
corrupted CPCS-SDU to the SSCS (i.e. optional delivery of corrupted data). When the corrupted
data delivery option is used, an error status indication is associated with the delivery. Even if the
errored delivery service is used, CPCS-SDUs may be lost without notice.
Examples of detected errors include: received length and CPCS-PDU Length field mismatch
including buffer overflow, and CPCS Cyclic Redundancy Check (CRC) errors;
4) abort.
This function provides for the means to abort a partially transmitted CPCS-SDU. This function is
indicated in the Length field;
5) padding.
This function provides for the padding of the CPCS-PDUs to an integral multiple of 48 octets and for
the location of the CPCS-PDU trailer in the last 8 octets of the CPCS-PDU;
6) handling of congestion information.
This function provides for the passing of congestion information between the layers above the
CPCS and the one below in both directions;
7) handling of loss priority information.
This function provides for the passing of cell loss priority information between the layers above the
CPCS and the one below in both directions;
8) CPCS-SDU sequence integrity.
This function assures that the sequence of CPCS-SDUs is maintained within one CPCS
connection;
9) mapping between CPCS connections and SAR connections.
This function provides for the one-to-one mapping between CPCS connections and SAR
connections. Neither CPCS connection multiplexing nor splitting is provided.

Page 20
ETS 300 428: August 1995
6.3.2.1.2 CPCS structure and coding
The CPCS functions require an 8 octet CPCS-PDU Trailer. The CPCS-PDU Trailer is always located in
the last 8 octets of the last SAR-PDU of the CPCS-PDU. Therefore, a padding field provides for a 48 octet
alignment of the CPCS-PDU. The CPCS-PDU Trailer together with the padding field and the CPCS-PDU
payload comprise the CPCS-PDU. The sizes and positions of fields for the CPCS-PDU structure are given
in figure 5.
CPCS-PDU
CPCS-PDU payload (CPCS-SDU)
Pad
trailer
CPCS-UU CPI CRC
Length
CPCS-PDU Trailer
CPCS-PDU
Pad: Padding (0 . 47 octets )
CPCS-UU: CPCS User-to-User Indication ( 1 octet )
CPI: Common Part Indicator ( 1 octet )
Length: Length of CPCS-SDU ( 2 octets )
CRC: Cyclic Redundancy Check ( 4 octets )
Figure 5: CPCS-PDU format for the AAL type 5
The coding of the CPCS-PDU conforms to the coding conventions specified in ITU-T Recommendation
I.361 [1], § 2.1:
a) CPCS-PDU payload.
The CPCS-PDU payload is the CPCS-SDU. The field can be from 1 to 65535 octets in length;
b) Padding (Pad) field.
Between the end of the CPCS-PDU payload and the CPCS-PDU trailer, there are from 0 to 47
unused octets. These unused octets are called the Padding (Pad) field; they are strictly used as
filler octets and do not convey any information. Any coding is acceptable. This padding field
complements the CPCS-PDU (including CPCS-PDU payload, Padding field, and CPCS-PDU
Trailer) to an integral multiple of 48 octets.
The function of the Pad field is shown in figure 6.

Page 21
ETS 300 428: August 1995
m ultiple of 48 octets 48 octets
CPCS payload CPCS trailer
Pad = 1 octet
CPCS payload CPCS trailer
Pad = 0 octets
CPCS payload Pad Pad Pad CPCS trailer
Pad = 7+40 octets
Padding field
Pad
Figure 6: Examples of the Pad field function
c) CPCS-UU field.
The CPCS-UU field is used to transparently transfer CPCS user to user information;
d) Common Part Indicator (CPI) field.
The value CPI="0" indicates that the field is only used to align the length of the CPCS-PDU trailer to
64 bits. Possible additional functions and corresponding codings may include identification of layer
management messages;
e) Length field.
The Length field is used to encode the length of the CPCS-PDU payload field. The Length field
value is also used by the receiver to detect the loss or gain of information.
The length is binary encoded as number of octets.
A Length field coded as zero is used for the abort function;
f) CRC field.
The CRC-32 is used to detect bit errors in the CPCS-PDU.
The CRC field is filled with the value of a CRC calculation which is performed over the entire
contents of the CPCS-PDU, including the CPCS-PDU payload, the Pad field, and the first 4 octets
of the CPCS-PDU Trailer. The CRC field shall contain the ones complement of the sum (modulo 2)
of:
k 31 30
1) the remainder of x (x + x + . + x + 1) divided (modulo 2) by the generator polynomial,
where k is the number of bits of the information over which the CRC is calculated; and
2) the remainder of the division (modulo 2) by the generator polynomial of the product of x by
the information over which the CRC is calculated.
The CRC-32 generator polynomial is:
32 26 23 22 16 12 11 10 8 7 5 4 2
G(x) = x + x + x + x + x + x + x + x + x + x + x + x + x + x + 1
The result of the CRC calculation is placed with the least significant bit right justified in the CRC
field.
Page 22
ETS 300 428: August 1995
As a typical implementation at the transmitter, the initial content of the register of the device
computing the remainder of the division is pre-set to all "1's" and is then modified by division by the
generator polynomial (as described above) of the information over which the
...