ETSI ETS 300 349 ed.1 (1995-02)
Broadband Integrated Services Digital Network (B-ISDN); Asynchronous Transfer Mode (ATM); Adaptation Layer (AAL) specification - type 3/4
Broadband Integrated Services Digital Network (B-ISDN); Asynchronous Transfer Mode (ATM); Adaptation Layer (AAL) specification - type 3/4
DE/NA-052618
Širokopasovno digitalno omrežje z integriranimi storitvami (B-ISDN) – Asinhroni prenosni način (ATM) – Specifikacija prilagodilne plasti (AAL), tip 3/4
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-december-2003
âLURNRSDVRYQRGLJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL %,6'1 ±$VLQKURQL
SUHQRVQLQDþLQ $70 ±6SHFLILNDFLMDSULODJRGLOQHSODVWL $$/ WLS
Broadband Integrated Services Digital Network (B-ISDN); Asynchronous Transfer Mode
(ATM); Adaptation Layer (AAL) specification - type 3/4
Ta slovenski standard je istoveten z: ETS 300 349 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 349
TELECOMMUNICATION February 1995
STANDARD
Source: ETSI TC-NA Reference: DE/NA-052618
ICS: 33.080
B-ISDN, ATM
Key words:
Broadband Integrated Services Digital Network (B-ISDN);
Asynchronous Transfer Mode (ATM)
Adaptation Layer (AAL) specification - type 3/4
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 349: February 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 Committee Support Dept." at the address shown on the title page.
Page 3
ETS 300 349: February 1995
Contents
Foreword .7
Introduction.7
1 Scope .9
2 Normative references.9
3 Definitions.9
4 Abbreviations.10
5 AAL type 3/4.11
5.1 Framework of AAL type 3/4 .11
5.2 Information flow across the ATM-AAL type 3/4 boundary.11
5.3 Service provided by the AAL type 3/4 .12
5.3.1 Description of AAL type 3/4 connections.13
5.3.2 Primitives for the AAL type 3/4 .13
6 The common part of the AAL type 3/4 .14
6.1 Services provided by the common part of the AAL type 3/4.14
6.1.1 Primitives.14
6.1.1.1 Primitives for the CPCS of the AAL type 3/4 .14
6.1.1.1.1 Primitives for the data transfer service .15
6.1.1.1.2 Primitives for the abort service .16
6.1.1.2 Service provided by the SAR sublayer .16
6.1.1.3 Primitives for the SAR sublayer of the AAL type 3/4 .17
6.1.1.3.1 Primitives for the data transfer service .17
6.1.1.3.2 Primitives for the abort service .18
6.2 Interaction with the management and control plane .18
6.3 Functions, structure and coding of AAL type 3/4 .18
6.3.1 Segmentation and Reassembly (SAR) sublayer .18
6.3.1.1 Functions of the SAR sublayer .18
6.3.1.2 SAR-PDU structure and coding.19
6.3.1.2.1 Data-SAR-PDU coding .20
6.3.1.2.2 Abort-SAR-PDU coding .21
6.3.2 Convergence Sublayer (CS).22
6.3.2.1 Functions, structure and coding for the CPCS .22
6.3.2.1.1 Functions of the CPCS .22
6.3.2.1.2 CPCS-PDU structure and coding .23
6.4 Procedures.26
6.4.1 Procedures of the SAR sublayer .26
6.4.1.1 State variables of the SAR sublayer at the sender side .26
6.4.1.2 Procedures of the SAR sublayer at the sender side.26
6.4.1.3 State variables of the SAR sublayer at the receiver side.28
6.4.1.4 Procedures of the SAR sublayer at the receiver side.28
6.4.2 Procedures of the CPCS for the message mode service .29
6.4.2.1 State variables of the CPCS at the sender side .29
6.4.2.2 Procedures of the CPCS at the sender side for the
message mode service.30
6.4.2.3 State variables of the CPCS at the receiver side.30
6.4.2.4 Procedures of the CPCS at the receiver side.31
Annex A (normative): Protocol Implementation Conformance Statement (PICS).33
A.1 Introduction.33
Page 4
ETS 300 349: February 1995
A.2 Scope of this annex . 33
A.3 Definitions. 33
A.4 Purpose . 33
A.5 PICS proforma. 33
A.5.1 Identification of the implementation. 33
A.5.2 Identification of the protocol . 34
A.5.3 Global statement of conformance . 34
A.5.4 Capabilities. 34
A.5.4.1 Initiator/responder capability. 34
A.5.4.2 Major capabilities . 34
A.5.4.2.1 Transmission capabilities. 34
A.5.4.2.1.1 Protocol parameters for transmission . 35
A.5.4.2.1.2 PDUs for transmission . 35
A.5.4.2.1.2.1 CPCS-PDU parameters for
transmission. 36
A.5.4.2.1.2.2 BOM Data SAR-PDU parameters for
transmission. 36
A.5.4.2.1.2.3 COM Data SAR-PDU parameters for
transmission. 37
A.5.4.2.1.2.4 EOM Data SAR-PDU parameters for
transmission. 37
A.5.4.2.1.2.5 SSM Data SAR-PDU parameters for
transmission. 38
A.5.4.2.1.2.6 Abort SAR-PDU parameters for
transmission. 38
A.5.4.2.2 Receipt capabilities . 39
A.5.4.2.2.1 Receipt timers/protocol parameters . 39
A.5.4.2.2.2 Support of PDUs received. 39
A.5.4.2.2.2.1 CPCS-PDU parameters at receipt . 40
A.5.4.2.2.2.2 BOM Data SAR-PDU parameters at
receipt. 40
A.5.4.2.2.2.3 COM Data SAR-PDU parameters at
receipt. 40
A.5.4.2.2.2.4 EOM Data SAR-PDU parameters at
receipt. 41
A.5.4.2.2.2.5 SSM Data SAR-PDU parameters at
receipt. 41
A.5.4.2.2.2.6 Abort SAR-PDU parameters at receipt 41
A.5.4.2.2.3 Protocol error handling. 42
A.5.4.3 Negotiation capabilities. 42
A.5.4.4 Multi-layer dependencies. 42
A.5.4.5 Other conditions. 42
Annex B (informative): Illustration of the data unit naming convention. 43
Annex C (informative): General framework of the AAL type 3/4. 46
C.1 Message segmentation and reassembly .46
C.2 PDU headers, trailers and terminology. 47
C.3 SAR and CPCS format . 48
C.4 Relation of the MID field to the SN field and Btag/Etag fields. 49
C.5 Examples of the segmentation and reassembly process . 50
Annex D (informative): Functional model for the common part of the AAL type 3/4. 52
Annex E (informative): SDL diagrams for the SAR and the CPCS of the AAL type 3/4. 54
Page 5
ETS 300 349: February 1995
E.1 SDL for the SAR sublayer and the CPCS .54
E.1.1 The SAR sender .54
E.1.2 The SAR receiver.55
E.1.3 The CPCS sender.64
E.1.4 The CPCS receiver.64
Annex F (informative): Multiplexing AAL type 3/4 connections on an ATM connection using the MID
field.71
F.1 Introduction.71
F.2 Multiplexing configurations.72
F.2.1 Point-to-point AAL type 3/4 connection on a point-to-point ATM connection.72
F.2.2 Point-to-point AAL type 3/4 connection on a point-to-multipoint ATM connection.73
F.2.3 Point-to-multipoint AAL type 3/4 connection on a point-to-multipoint ATM-connection .73
Annex G (informative): MID allocation procedures.74
G.1 Introduction.74
G.2 MID allocation functional architecture .74
G.2.1 Functions of the MID user and the MID manager.75
G.2.2 Interaction between M-plane and U-plane.75
G.3 MID allocation PDUs and parameters.75
G.3.1 AALM-PDU types and parameters.75
G.3.2 Structure and coding.76
G.3.2.1 Structure and coding of the SAR-PCI.76
G.3.2.2 Structure and coding of the CPCS-PCI.76
G.3.2.3 Structure and coding of the AALM-PDU.77
G.3.2.4 Relationship between PDUs.78
G.4 MID allocation procedures.78
G.4.1 Procedures to establish CP-AAL connections .78
G.4.2 Procedure to check the CP-AAL connections.79
G.4.3 Procedures to release CP-AAL connections .79
G.4.3.1 Procedure to release CP-AAL connections, initiated by the MID manager.79
G.4.3.2 Procedure to release CP-AAL connections, initiated by the MID user .79
Annex H (informative): Bibliography.80
History.81
Page 6
ETS 300 349: February 1995
Blank page
Page 7
ETS 300 349: February 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] and specifies the interactions
between the Asynchronous Transfer Mode (ATM) Adaptation Layer (AAL) type 3/4 and the next higher
layer, and the AAL type 3/4 and the ATM layer, as well as AAL type 3/4 peer-to-peer operations. This ETS
is one of a set of ETSs describing different AAL types.
Transposition dates
Date of latest announcement of this ETS (doa): 31 May 1995
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 30 November 1995
Date of withdrawal of any conflicting National Standard (dow): 30 November 1995
Introduction
The AAL type 3/4 enhances the service provided by the ATM layer to support functions required by the
next higher layer. The AAL type 3/4 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 3/4 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 3/4 to the higher layer and the functions performed are specified in this
ETS.
Page 8
ETS 300 349: February 1995
Blank page
Page 9
ETS 300 349: February 1995
1 Scope
This European Telecommunication Standard (ETS) specifies the interactions between the Asynchronous
Transfer Mode (ATM) Adaptation Layer (AAL) type 3/4 and the next higher layer, and the AAL type 3/4
and the ATM layer, as well as AAL type 3/4 peer-to-peer operations.
This ETS is applicable to variable bit rate sources where there exists no timing relation between the
source and the destination of the data; it is applicable for both connection-oriented and connectionless
type of communication.
This ETS defines the common part of AAL type 3/4 and can be complemented with standards for the
service specific part of the convergence sublayer.
2 Normative references
This ETS incorporates by dated and 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 (AAL)
specification".
[3] CCITT Recommendation X.200 (1988): "Reference Model for Open Systems
Interconnection for CCITT Applications".
[4] CCITT Recommendation X.210 (1988): "Open Systems Interconnection (OSI)
Layer Service Definition Conventions".
[5] ISO/IEC 9646-1 (1991) CCITT Recommendation X.290 (1991):
"Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 1: General concepts".
[6] ISO/IEC 9646-2 (1991) CCITT Recommendation X.291 (1991):
"Information technology - Open Systems Interconnection - Conformance testing
methodology and framework - Part 2: Abstract test suite specification".
3 Definitions
For the purposes of this ETS, the definitions given in CCITT Recommendations X.200 [3] and X.210 [4]
apply, in addition, 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.
Illustration of the data unit naming convention used in this ETS can be found in annex B.
Page 10
ETS 300 349: February 1995
4 Abbreviations
For the purposes of this ETS, the following abbreviations apply:
AAL ATM Adaptation Layer
AALM AAL Management
AL Alignment
ATM Asynchronous Transfer Mode
BASize Buffer Allocation Size
BOM Beginning Of Message
Btag Beginning tag
CEP Connection Endpoint identifier
COM Continuation of Message
CP-AAL Common Part of AAL type 3/4
CPCS Common Part CS
CPI Common Part Indicator
CRC Cyclic Redundancy Check
CS Convergence Sublayer
EOM End of Message
Etag End tag
IDU Interface Data Unit
LI Length Indicator
LSB Least Significant Bit
MID Multiplexing Identification
MM Message Mode
MSB Most Significant Bit
OAM Operation And Maintenance
PAD Padding
PDU Protocol Data Unit
QOS Quality of Service
SAP Service Access Point
SAR Segmentation And Reassembly sublayer
SDU Service Data Unit
SLP Submitted Loss Priority
SM Streaming Mode
SN Sequence Number
SSCS Service Specific CS
SSM Single Segment Message
ST Segment Type
Page 11
ETS 300 349: February 1995
5 AAL type 3/4
5.1 Framework of AAL type 3/4
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.
SAP
Service Specific CS
(may be Null)
Primitives
Common Part CS
Primitives
SAR (common)
SAP
Figure 1: Structure of the AAL type 3/4
Different SSCS protocols, to support specific AAL type 3/4 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 3/4 user to CPCS and vice-versa.
The description contained in this ETS defines the functional behaviour of the AAL type 3/4 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 the SAR sublayer and CPCS is arbitrary and not
visible to the outside. The allocation of function to the two sublayers was made for the sake of the ease of
description.
5.2 Information flow across the ATM-AAL type 3/4 boundary
The AAL type 3/4 makes use of the ATM layer service as defined in ITU-T Recommendation I.361 [1].
AAL
CPCS SSCS
SAR CS
Page 12
ETS 300 349: February 1995
5.3 Service provided by the AAL type 3/4
The AAL type 3/4 provides the capabilities to transfer the AAL-SDU from one AAL type 3/4 user to another
AAL type 3/4 user through the ATM network. Two modes of service are defined, message mode and
streaming mode:
a) message mode service: the AAL-SDU is passed across the AAL type 3/4 interface in exactly one
AAL-IDU. This service provides the transport of fixed size or variable length AAL-SDUs:
1) in case of variable length AAL-SDUs, an internal AAL-SDU segmentation/reassembling
function in the SSCS may be applied (e.g. an AAL-SDU exceeds the length limit imposed by
the capability of the CPCS). In this case a single AAL-SDU is transferred in one or more
SSCS-PDUs;
2) 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);
3) where the options a1) and a2) 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-SDU;
b) streaming mode service: the AAL-SDU is passed across the AAL type 3/4 interface in one or more
AAL-IDU. The transfer of these AAL-IDUs across the AAL type 3/4 interface may occur separated in
time. This service provides the transport of variable length AAL-SDUs. The streaming mode service
includes an abort service by which the discarding of an AAL-SDU partially transferred across the
AAL type 3/4 interface can be requested:
1) an internal AAL-SDU 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 3/4 entity initiates the transfer to the receiving AAL type 3/4 entity before it has the
complete AAL-SDU available;
3) where option b1) 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.
Table 1: Combination of service mode and internal function
AAL-SDU Message AAL-SDU 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 sending and receiving side
Receiver Sender
MM/Block MM/Seg 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
Page 13
ETS 300 349: February 1995
NOTE: An end-to-end specification of the SDU length in MM with blocking/deblocking is
needed.
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 3/4
connections;
- non-assured operations:
integral AAL-SDUs may be lost or corrupted. Lost and corrupted AAL-SDUs will not be corrected by
retransmission. An optional feature may be provided to allow corrupted AAL-SDUs to be delivered
to the user (i.e. optional error discard). Flow control may be provided as an option.
5.3.1 Description of AAL type 3/4 connections
The AAL type 3/4 provides the capabilities to transfer the AAL-SDU from one AAL-SAP to one or more
AAL-SAPs through the ATM network (see annex F). The AAL type 3/4 users will 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).
AAL type 3/4 makes use of the service provided by the underlying ATM layer (see figure 2). Multiple AAL
type 3/4 connections may be associated with a single ATM connection, allowing SAR-PDU multiplexing at
the AAL type 3/4. The AAL type 3/4 user selects the QOS provided by the AAL type 3/4 through the choice
of the AAL-SAP used for data transfer.
AAL-SAP
AAL-SAP AAL-SAP
1 3
Service provided
(Q oS )
(Q oS ) (Q oS )
1 2
to the AAL users
AAL type 3/4
Makes use of the
underlying AT M
ATM-SAP ATM-SAP
m n
layer service
AAL layer
Figure 2: Relation between AAL-SAP and ATM-SAP
5.3.2 Primitives for the AAL type 3/4
These primitives depend on the SSCS protocol used; they are defined independently for each SSCS
protocol.
If the SSCS is null, it only provides for the mapping of the equivalent primitives of the AAL
type 3/4 to CPCS and vice-versa. In this case, the primitives for the AAL type 3/4
are equivalent to those for the CPCS (see 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 SAP.
Page 14
ETS 300 349: February 1995
6 The common part of the AAL type 3/4
6.1 Services provided by the common part of the AAL type 3/4
Two modes of service are defined: message and streaming:
a) message mode service: the CPCS-SDU 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-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 a 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: Figure B.2, a) and d) of annex B illustrate the message and streaming mode service.
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 error discard).
6.1.1 Primitives
The functional model for AAL type 3/4 as contained in annex D shows the interrelation between the SAR,
CPCS, and SSCS sublayers, and the SAR and CPCS primitives.
6.1.1.1 Primitives for the CPCS of the AAL type 3/4
As there exists no Service Access Point (SAP) between the sublayers of the AAL type 3/4, the primitives
are called "invoke" and "signal" instead of the conventional "request" and "indication" to highlight the
absence of the SAP.
CPCS connection establishment and release is performed via signalling or via management procedures.
There is no provision for CPCS connection establishment and release support in the CPCS protocol.
CPCS and SAR connection establishment and release and the corresponding Multiplexing Identification
(MID) allocation and deallocation can be done via signalling, management, or pre-arrangement. The
CPCS connection and the corresponding SAR connection are established and released simultaneously.
Annex G describes a way to establish and release CP-AAL connections, i.e. the combination of a SAR
connection and the related CPCS connection via management.
Page 15
ETS 300 349: February 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 IDU exchanged between the CPCS and the SSCS entity. The
interface data is an integral multiple of one octet. When the corrupted data delivery option is used,
the interface data may be empty. If the CPCS entity is operating in the message mode service, the
interface data represents a complete CPCS-SDU; when operating in the streaming mode service,
the interface data does not necessarily represent a complete CPCS-SDU.
More (M)
In the message mode service, this parameter is not used. In the streaming mode service, this
parameter specifies whether the interface data communicated contains a beginning/continuation of
a CPCS-SDU or the end of/complete CPCS-SDU.
Maximum Length (ML)
In the message mode service, this parameter is not used. In the streaming mode service, this
parameter indicates the maximum length of the CPCS-SDU. This parameter is required with the
first invoke or signal primitive related to a certain CPCS-SDU; in all other cases, this parameter is
not used.
CPCS Submitted Loss Priority (CPCS-SLP)
This parameter indicates the requested loss priority for the associated CPCS-SDU. It can take only
two values, one for high priority ("0") and the other for low priority ("1"). This parameter is required
only with the first invoke primitive related to a certain CPCS-SDU.
Reception Status (RS)
This parameter indicates that the interface data delivered may be corrupted. This parameter is only
utilized if the corrupted data delivery option is used.
Depending on the service mode (message or streaming mode service, discarding or delivery of errored
information), not all parameters are required. This is summarized in table 3.
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
Maximum invoke - m* Maximum length of CPCS-SDU
Length (ML) signal - o*
CPCS Submitted Loss invoke m m* setting of the CLP bit in the ATM
Priority (CPCS-SLP) signal - - header
Reception Status invoke - - indication of corrupted data
(RS) signal o o
MM: Message Mode service. m*: mandatory with the first invoke primitive
SM: Streaming Mode service. related to a certain CPCS-SDU otherwise
absent.
m: mandatory. o*: optional with the first signal primitive
o: optional. related to a certain CPCS-SDU, otherwise
-: not present. absent.
Page 16
ETS 300 349: February 1995
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.
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-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-PDU;
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 streaming mode service
includes an abort service by which the discarding of an SAR-SDU partially transferred across the
SAR interface can be requested.
The SAR receiver always operates in streaming mode (i.e. each correctly received SAR-PDU is
passed immediately to the CPCS sublayer, see subclause 6.4.1.3).
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 B.2 d) of annex B illustrates the streaming mode service.
NOTE: If the CPCS sender is operating in streaming mode, the SAR sender should also
operate in streaming mode.
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 error discard).
Page 17
ETS 300 349: February 1995
6.1.1.3 Primitives for the SAR sublayer of the AAL type 3/4
These primitives model the exchange of information between the SAR sublayer and the CPCS.
As there exists no Service Access Point (SAP) between the sublayers of the AAL type 3/4, the primitives
are called "invoke" and "signal" instead of the conventional "request" and "indication" to highlight the
absence of the SAP.
SAR connection establishment and release is performed via signalling or via management procedures.
There is no provision for SAR connection establishment and release support in the SAR protocol.
CPCS and SAR connection establishment and release and the corresponding MID allocation and
deallocation can be done via signalling, management, or pre-arrangement. The CPCS connection and the
corresponding SAR connection are established and released simultaneously. Annex G describes a way to
establish and release CP-AAL connections, i.e. the combination of a SAR connection and the related
CPCS connection via management.
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:
Interface Data (ID)
This parameter specifies the IDU exchanged between the SAR and the CPCS entity. The interface
data is an integral multiple of one octet. When the corrupted data delivery option is used, the
interface data may be empty. The interface data does not necessarily represent a complete
SAR-SDU;
More (M)
This parameter specifies whether the interface data communicated contains the end of the
SAR-SDU.
If the More parameter is set to M = 1, the interface data parameter contains an integral multiple of
44 octets;
SAR Submitted Loss Priority (SAR-SLP)
This parameter passes the requested loss priority from the CPCS-SDU to the associated
SAR-PDUs. It can take only two values, one for high priority ("0") and the other for low priority ("1").
Reception Status (RS)
This parameter indicates that the interface data delivered may be corrupted. This parameter is only
utilized if the corrupted data delivery option is used.
The usage of the parameters is summarized in table 4.
Page 18
ETS 300 349: February 1995
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 (note) m M = 0: end of SAR-SDU
signal m M = 1: not end of SAR-SDU
SAR Submitted Loss invoke m setting of the CLP bit in the ATM header
Priority (SAR-SLP) signal -
Reception Status invoke - indication of corrupted data
(RS) signal o
m: mandatory o: optional -: not present
NOTE: This parameter is always set to zero if the sender operates in message mode.
6.1.1.3.2 Primitives for the abort service
a) SAR-U-Abort-invoke and SAR-U-Abort-signal.
The SAR-U-Abort-invoke primitive is used by the SAR user to invoke the abort service. The
SAR-U-Abort-signal primitive is used by the SAR entity to signal to the SAR user that a partially delivered
SAR-SDU is to be discarded by instruction from the peer SAR-user entity. The following parameter is
defined:
SAR Submitted Loss Priority (SAR-SLP)
This parameter specifies, how the Submitted Loss Priority parameter in the
ATM_UNITDATA.request primitive shall be set.
The usage of the parameter is summarized in table 5.
Table 5: Parameters of the SAR-U-Abort
Parameter Type Comments
SAR-Submitted Loss invoke m setting of the CLP bit in the ATM header
Priority (SAR-SLP) signal -
m: mandatory -: not present
b) SAR-P-Abort-signal.
This primitive is used by the SAR entity to signal to its user that a partially delivered SAR-SDU is to be
discarded due to the detection of some error. This primitive is only used if the corrupted data delivery
option is not used. This primitive has no parameters.
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 AAL type 3/4
6.3.1 Segmentation and Reassembly (SAR) sublayer
6.3.1.1 Functions of the SAR sublayer
The SAR sublayer functions are performed on an SAR-PDU basis. The SAR sublayer accepts variable
length SAR-SDUs from the Convergence Sublayer (CS) and generates SAR-PDUs containing up to 44
octets of SAR-SDU data.
Page 19
ETS 300 349: February 1995
The SAR sublayer functions provide the means for the transfer of multiple variable length SAR-SDUs
concurrently over a single ATM connection between AAL type 3/4 entities:
a) preservation of SAR-SDU.
This function preserves the SAR-SDU by providing for a segment type indication and a SAR-PDU
payload fill indication. The SAR-PDU payload fill indication identifies the number of octets of
SAR-SDU information contained within the SAR-PDU payload. The Segment Type indication
identifies a SAR-PDU as a Beginning of Message (BOM), Continuation of Message (COM), End of
Message (EOM), or Single Segment Message (SSM);
b) error detection and handling.
This function provides the means to detect and handle:
- bit errors in the SAR-PDU;
- lost or gained SAR-PDUs.
By default, SAR-PDUs with bit errors are discarded. A SAR receiver may provide the local option to
deliver corrupted SAR-SDUs to the CPCS (i.e. optional error delivery). However, if the optional
multiplexing and demultiplexing of SAR connections is performed, such an optional errored delivery
service may deliver an errored SAR-SDU to the wrong state machine. SAR-SDUs with lost or
gained SAR-PDUs are discarded or are optionally delivered to the CPCS. When delivering errored
information, an appropriate indication is associated with the information. Even if the errored delivery
service is used, SAR-SDUs may be lost without any notice;
c) SAR-SDU sequence integrity.
This function assures that the sequence of SAR-SDUs is maintained within one CPCS connection;
d) multiplexing/demultiplexing.
This function provides for the optional multiplexing and demultiplexing of multiple SAR connections.
The number of SAR connections supported over an ATM connection is negotiated via signalling at
ATM connection establishment or is prearranged (i.e. by manual management). The default number
of SAR connections shall be one. Within a given SAR connection, sequence integrity is preserved;
e) abort.
This function provides for the means to abort a partially transmitted SAR-SDU.
6.3.1.2 SAR-PDU structure and coding
The SAR-PDU structure and coding shall be as described in this subclause.
The SAR sublayer functions require a 2 octet SAR-PDU header and a 2 octet SAR-PDU trailer. The
SAR-PDU header and trailer together with the 44 octets of SAR-PDU payload comprise the 48 octet
ATM-SDU (cell payload). The sizes and positions of fields for the SAR-PDU structure are given in figure 3.
Page 20
ETS 300 349: February 1995
SAR-PDU Payload
Cell Header ST SN MID LI CRC
SAR-PDU Header SAR-PDU Trailer
SAR-PDU
ST: Segment Type (2 bits)
SN: Sequence Number (4 bits)
MID: Multiplexing Identification (10 bits)
LI: Length Indication (6 bits)
CRC: Cyclic Redundancy Check Code (10 bits)
Figure 3: SAR-PDU Format for AAL type 3/4
The coding of the SAR-PDU conforms to the coding conventions specified in § 2.1 of ITU-T
Recommendation I.361 [1]. There are two types of SAR-PDU:
- Data-SAR-PDUs; and
- Abort-SAR-PDUs.
6.3.1.2.1 Data-SAR-PDU coding
a) Segment Type (ST) field.
The ST indication identifies a SAR-PDU as containing a Beginning of Message (BOM), a
Continuation of Message (COM), an End of Message (EOM), or a Single Segment Message (SSM).
The association between the encoding and the meaning of the ST field is shown in table 6.
Table 6: Coding of the ST field
Segment Type Encoding Usage
BOM 10 Beginning of Message
COM 00 Continuation of Message
EOM 01 End of Message
SSM 11 Single Segment Message
b) Sequence Number (SN) field.
Four bits are allocated to the SN field allowing the stream of SAR-PDUs of a CPCS-PDU to be
numbered modulo 16.
Each SAR-PDU belonging to a SAR-SDU (and hence associated with a given MID value) will have
its SN incremented by one relative to the SN of the previous SAR-PDU. The receiver checks the
sequence of the SN values of SAR-PDUs derived from one SAR-SDU and does not check the
sequence of the SN values of the SAR-PDUs derived from successive SAR-SDUs. As the receiver
does not check the SN continuity between SAR-SDUs, the sender may set the SN field to any value
from 0 to 15 at the beginning of each SAR-SDU;
c) MID field.
This field is used for multiplexing. If no multiplexing is used, this field shall be set to zero.
NOTE: Any value may be used (including zero) if multiplexing is used.
In connection oriented applications it may be used to multiplex multiple SAR connections on a
single ATM connection. The following restrictions apply:
- multiplexing/demultiplexing on a single ATM
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...