. 95
( 132 .)


8 bytes

Payload: 1 - 65 535 bytes SSTED trailer

UU R Length CRC

bits 8 6 11 16 32

Figure 7.37 SSTED

Figure 7.37, is similar to that of AAL5, providing a 4-byte CRC check over the payload
for error detection.
The UU (user to user) ¬eld is passed transparently to the user. The R (reserved) ¬eld
is currently unused and ¬lled with zeros. The CI (congestion indication) and LP (loss
priority) are single-bit ¬elds and come from the CI bit of the ATM layer PTI ¬eld and the

CLP bit of the ATM layer, respectively. The length ¬eld provides the number of octets
in the payload, and the CRC ¬eld is for error checking.
These features are incorporated to decouple the AAL2 and associated SSCS layers from
the underlying ATM network.
The SSSADT provides for assured delivery through acknowledgements and ¬‚ow con-
trol. This mechanism is exactly the same as the service-speci¬c connection-oriented
protocol (SSCOP) as de¬ned in the signalling stack. The intricacies of this protocol
are discussed in Section 7.13.2.

7.7.5 AAL3/4
AAL3/4 is designed for data transfer and carries packets of up to 64 kbytes in size.
It provides detection of corrupted, out-of-sequence and missing packets. An important
feature of AAL3/4 is that it allows many sessions to be multiplexed on a single VCI,
and then separated at the destination. Often, there may be a fee charged by the provider
for each connection opened, and then for the time it is open. In this way, many sessions
can be sent down the one circuit, provided there is enough bandwidth to handle all of
them. This protocol is different from the previous two as both the sublayers add their own
header and trailer to the payload. The CS adds 8 bytes to the payload, which can be up
to 64 kbytes in length. The SAR then splits this up into 44-byte pieces to each of which
it adds another 4 bytes of checksum and sequencing information.
AAL3/4 inserts a protocol overhead at both the CS and the SAR sublayer. The CS
accepts messages from an application, which are in the range of 1“64 kbytes in length.
The ¬rst task is to pad the message out to a multiple of 4 bytes before adding the header
and trailer to facilitate segmentation. The format of the message is shown in Figure 7.38
The message is referred to by the ITU-T and ATM forum as the common part conver-
gence sublayer protocol data unit (CPCS PDU).
The CPI ¬eld is the common part identi¬er, which indicates the message type and the
counting units for the size and length ¬elds. Currently there is only one type de¬ned,
which is for a byte as a unit, where CPI has a value of 0. The Btag and Etag ¬elds are
used to frame the beginning and end of the message. For a message they must be the
same value, and are incremented for each new message sent, so that missing cells may
be checked for. The BAsize (buffer allocation) ¬eld is an indication to the destination of
how much buffer space to allocate for the message (216 gives the 64 kbyte length). AL
is an alignment ¬eld which is unused and ¬lled with 0 s.
Once the CS has ¬nished with adding its header and trailer, it passes the message to the
SAR sublayer, which segments it into 44-byte units, adding its own overhead of 2 bytes
at each end. The format of the SAR cell is as shown in Figure 7.39.
ST is the segment type and can have four possible values, shown in Table 7.14.
SN is a 4-bit sequence number, for detecting missing or misinserted cells.

1 byte 1 byte 2 bytes 0-3 bytes 1 byte 1 byte 2 bytes
CPI Btag BAsize Payload: 1-64kbytes Pad AL Etag Length

Figure 7.38 AAL3/4 CS sublayer format

bits 2 4 10 6 10

ST SN MID Payload: 44 bytes LI CRC

48 bytes

Figure 7.39 AAL3/4 SAR sublayer format

Table 7.14 Segment type values
Segment Value Signi¬cance
BOM 10 Beginning of message
COM 00 Continuation of message
EOM 01 End of message
SSM 11 Single segment message

Application MESSAGE 1 MESSAGE 2



Figure 7.40 Segmentation by AAL3/4

The CS may be working with a number of messages at one time, each belonging to a
different session. Pieces of this message are passed to the SAR in an arbitrary fashion.
The MID ¬eld is the multiplexing ID value and is used to keep track of the messages
from different sessions. Each chunk of a given message will have the same MID value,
allowing for the multiplexed messages to be segregated and reassembled at the destination.
Since MID is 10 bits this allows for up to 1024 different sessions on one virtual channel.
The length ¬eld is the number of bytes in the payload, since it can be less than 44 bytes
for EOM and SSM messages, and the CRC is a cyclic redundancy check.
The segmentation of a message is illustrated in Figure 7.40.
It is generally considered that there is a problem with AAL3/4 in that it introduces a
signi¬cant overhead to data, particularly for short messages, introducing a considerable
amount of inef¬ciency into the transfer of data. The industry consensus was that this
protocol was too cumbersome and so AAL5 was developed. AAL3/4 is virtually unused
in practice.

7.7.6 AAL5
AAL5 is designed for the transport of large, non-real-time data, such as IP packets. It is
the most widely used AAL, and in fact, its largest role is in the transport of IP traf¬c.

bytes 1 1 2 4

Payload: 1-64 kbytes Pad UU CPI Length CRC

8 byte trailer

Figure 7.41 AAL5 PDU format

The AAL5 CS sublayer adds only 8 bytes to a payload which, again, can be up to
64 kbytes long. There is no overhead added at the SAR. Like AAL3/4, the application
can pass messages of up to 64 kbytes in length. The CS adds a trailer to the message, as
shown in Figure 7.41.
The Pad adds somewhere between 0 and 47 bytes to the data such that the entire
length of the message, including the trailer, is a multiple of 48 bytes, so for a single-byte
transmission, 48 bytes must be sent. The UU ¬eld allows for the transmission of one byte
of user data by a higher protocol without it being examined by the AAL5 layer. The CPI
is a common part indicator, similar to that for AAL3/4. Currently it is unused, and ¬lled
with 0s. The length ¬eld gives the true length of the data, excluding the padding, and the
CRC is a standard 32-bit cyclic redundancy check.
The SAR adds no overhead to the message and merely segments it into 48-byte chunks.
It also preserves message boundaries by informing the ATM layer to set the lsb in its PTI
¬eld to 1 to indicate the last 48-byte piece of a packet. Recall that this is cell type 1, as
discussed in Section 7.6. AAL5 has a major advantage for data transfer over AAL3/4 in
that only 8 bytes are added per message with no overhead added per cell. Note, however,
that the message boundary mechanism is in direct con¬‚ict with the whole concept of
layering, but substantially reduces the overhead. Due to its ef¬ciency advantages, AAL5
is sometimes known as the simple ef¬cient adaptation layer (SEAL).
As addressed later, AAL5 is also used for transport of signalling, management and
routing protocols within ATM.
AAL5 is used across the UMTS Iu interface to connect to the GPRS packet switched
core for the transport of user traf¬c. The stack is shown in Figure 7.42. Note that for
the GPRS IP backbone, the traf¬c is carried over UDP, encapsulating the GPRS tun-
nelling protocol (GTP). Since signalling messages are generally quite large and need to
be segmented for transport across ATM, AAL5 is used for the transport of all UTRAN
signalling, for example the Node B application part (NBAP).
Although outside the remit of the speci¬cations, a central part of a UMTS network is
the provision of a network management system. For UMTS, just as was the case with
GSM, network management is vendor speci¬c. However, many manufacturers of UMTS
equipment will utilize the ATM network to transport network management messages.
AAL5 is used for this purpose.

7.7.7 Summary
Table 7.15, presents a comparison of the four protocols, with a summary of the role of
the ATM layers and sublayers.

Core Network


User Data User Data
Physical Physical

Figure 7.42 UMTS packet switched user data transport

Table 7.15 Comparison of AAL protocols
Item AAL1 AAL2 AAL3/4 AAL5
Multiplexing No Yes Yes No
Message framing None Pointer Btag/Etag Bit in PTI
Buffer allocation No No Yes No
CS Padding 0 0“45/64 Bytes 0“3 Bytes 0“47 Bytes
1 Bytea
Overhead 0 8 Bytes 8 Bytes
Checksum None 5 Bits None 32 Bits
SAR Payload 46“47 Bytes 48 Bytes 44 Bytes 48 Bytes
Overhead 1“2 Bytes 0 4 Bytes 0
Checksum None None 10 Bits None
Note that it adds 1 byte to every 47 bytes of payload, but also adds 3 bytes overhead at the CPS packet
sublayer to a variable length packet.

It is seen that AAL1 and AAL2 are designed to take small, real-time SDUs from an
application, and, in the case of AAL2, variable length SDUs may be multiplexed together
onto a single virtual circuit. In contrast, AAL3/4 and AAL5 are designed to facilitate the
segmentation of larger messages in preparation for ATM transport.

Thus far, data transport has been examined in terms of cells. The cell headers indicate
the virtual path and channel that the cells should use, but do not provide any indication
of the quality of service provided by them. This section addresses the issue of provision
of QoS in an ATM network.
Applications and services using the network can be broadly broken into two types of
service: guaranteed and best-effort. A guaranteed service provides a certain level of service

Table 7.16 ATM traf¬c classes
Class Subclass Description Suggested layer Example

Guaranteed CBR Constant bit rate AAL1 Voice
rt-VBR Real-time variable AAL2 Video conference
bit rate
nrt-VBR Non-real-time AAL2 Video streaming
variable bit rate
Best effort ABR Available bit rate AAL5 Web browsing
GFR Guaranteed frame AAL5 Any IP traf¬c
UBR Unspeci¬ed bit rate AAL5 File transfer

in terms of bandwidth, delay and probability of loss, provided the application stays within
the rules of transfer. A best-effort service, as the name suggests, will only provide service
if bandwidth is available and may drop packets should congestion occur. The two are
analogous to travelling on an airline. If a reservation is made, it is a guaranteed service;
however, if on standby, the passenger can go if the ¬‚ight is not full, otherwise they will
need to wait for an available ¬‚ight. The airline makes a best effort to carry the passenger.
Also like an airline, best-effort services are generally lower in cost than guaranteed.
Within these classi¬cations, the ATM forum has de¬ned traf¬c subclasses to form a
standard of the service that are offered to customers. The classes are summarized in
Table 7.16.
These traf¬c classes are as de¬ned by the ATM Forum. The ITU-T de¬nes the CBR
class as deterministic bit rate (DBR) and the VBR classes as statistical bit rate (SBR).
The traf¬c characteristics are the same. However, this section will focus on the de¬nitions
from the ATM Forum.

• Constant bit rate (CBR): this is most similar to a telephone circuit and provides the
same level of services as a physical medium such as copper or ¬bre. Traf¬c has a ¬xed
bit rate with synchronous bit transmission. Typical applications are real-time voice and
video. An application may transfer data at a rate lower than this ¬xed rate, so as to
support such services as silence suppression. However, the service guarantees tight
constraints on delay.
• Variable bit rate (VBR): intended for services and applications that have variable bit


. 95
( 132 .)