. 102
( 132 .)



Signalling Transport
Converter (STC)



AAL5 common part



Figure 7.77 AAL2 signalling protocol stack

network of PVCs. AAL2 signalling uses the standard ATM signal AAL for transport, but
is, however, independent of this transport, requiring only assured transport of messages.
However, to adapt the underlying generic transport to the speci¬cs of Q.2630.1, a sig-
nalling transport converter STC may be used and the ITU-T has de¬ned two: Q.2150.1 and
Q.2150.2. Q.2150.1 is used to convert to an MTP3/MTP3b transport layer, and Q.2150.2
to convert to an ATM SAAL transport layer. In the case of the Iub interface, Q.2150.2 is
used. On the Iu and Iur interface, Q.2150.1 is used.
An AAL2 path is an ATM virtual circuit connection between two adjacent AAL2 nodes.
For each AAL2 path, i.e. ATM virtual circuit designated to carry AAL2 traf¬c, an AAL2
path identi¬er is assigned which uniquely identi¬es the path. There are 248 channel IDs
available on each path, from 8 to 255. An AAL2 node is identi¬ed by service end point
address, which is the same as an ATM address, but supporting only NSAP and E.164
address formats. The addressing plan used at the AAL2 layer can follow the addresses used
at the ATM layer. However an independent addressing plan may also be implemented.
This essentially de¬nes a separate AAL2 network, sitting on top of the ATM network.
The actual de¬nition of the addressing structure is implementation speci¬c.
Consider the NBAP signalling message to request a radio link. Upon its return to the
RNC, the BTS has enclosed its AAL2 address and a binding ID.
The RNC then uses these within an AAL2 establish request (ERQ), as shown in
Figure 7.78. The BTS will respond with an establish con¬rm message (ECF).
The ERQ message will contain the following key parameters:

• Connection Element ID: this consists of a 4-byte path identi¬er, the coding of which
is speci¬c to the implementation, and a 1-byte channel ID.
• Destination service end point address: this is an E.164 or NSAP address. The E.164
address is used for the circuit core components (3G-MSC) since they already have an
E.164 number.
• Signalling association ID (SAID): OSAID/DSAID for originating and destination sig-
nalling association identi¬ers, respectively. This is a 4-byte ¬eld used as an ID for
the signal connection. In an initial connection, the DSAID ¬eld will be null, and the
OSAID will be a unique identi¬er of this signalling message.
• Served user generated reference: this is a ¬eld for the user to enter a value. In UMTS,
it is used to transport the binding ID.


NBAP RL Setup Procedure



Figure 7.78 AAL2 signalling connection establishment

• Link characteristics: provides information on the size of the CPS SDU (1“45 bytes)
and the bit rate (0“2048 kbps in steps of 64 kbps).

The establish con¬rm will then return to the RNC, containing only two parameters:

• DSAID: the DSAID will correspond to the OSAID contained in the ERQ message.
This is used to reference signalling messages relating to one call.
• OSAID: an identi¬er for this ECF message.

To release the established connection, the release (REL) and release con¬rm (RLC)
signalling messages are used.
The trace example shown in Figure 7.79 shows an AAL2 signalling exchange between
an RNC and a BTS. In this example, the RNC is requesting an AAL2 channel, with a
channel ID (CID) of 11 and a CPS-PDU size of 19 bytes.
In this example, the AAL2 address follows the private addressing 49 scheme. Here,
the operator or vendor will designate the structure of the address. In this example, the

ERQ - Establish Request
DAID-Dest. sign. assoc. ident.: 00 00 00 00
CEID-Connection element ident.
Path identifier: 999001 (F3E59h)
Channel identifier: 11 (Bh) AAL2 Channel ID: 11
NSEA-Dest. NSAP serv. endpoint addr.
Address: 49 00 99 90 01 00 00 00 00 00
NSAP address
00 00 00 00 00 00 00 00 00 00
ALC-Link Charactreristics
Max forward CPS-SDU bit rate: 1024 (400h)
Max backwards CPS-SDU bit rate: 1024 (400h)
Avg forward CPS-SDU bit rate: 1024 (400h)
Avg backwards CPS-SDU bit rate: 1024 (400h)
rate and
Max forward CPS-SDU size: 19 (13h)
SDU size
Max backwards CPS-SDU size: 19 (13h)
Avg forward CPS-SDU size: 19 (13h)
Avg backwards CPS-SDU size: 19 (13h)
OSAID-Orig. sign. assoc. ident.
Signalling association identifier: 45 10 15 00
SUGR-Served user gen. reference
Binding ID
Field: 00 00 00 02

ECF - Establish Confirm DAID matches
DAID-Dest. sign. assoc. ident.: 45 10 15 00 OSAID in ERQ
OSAID-Orig. sign. assoc. ident.
Signalling association identifier: 00 00 00 04

Figure 7.79 Trace example of AAL2 signalling connection establishment

format that has been adopted is to incorporate the identity of the base station and the cell
into the address. The base station ID is 20 bits and the cell ID 12 bits. Therefore, from
the address:


it can be seen that the BTS ID is 0x00005 and the ID is 0x001. This is also re¬‚ected
in the path ID: 5001.
For UMTS implementation Release 5 onwards, the Q.2630.1 speci¬cation is super-
seded by Q.2630.2 (capability set 2), which expands to encompass link modi¬cations in
addition to all the procedures speci¬ed in Q.2630.1. Q.2630.2 uses the modify request
(MOD) and modify acknowledged/modify reject (MOA/MOR) messages to perform link

This section addresses the ATM methods used in UMTS to transport both real- and
non-real-time traf¬c around the network, as well as describing the key functions of the
major ATM components in a UMTS network: the radio network controller (RNC) and
the media gateway/internetworking unit (MGW/IWU). The position of these components
in an overall ATM network is shown in Figure 7.80.
In fact, despite the grand design of ATM and the endeavours of the ATM Forum, to
date, the most popular and widely used application for ATM is as a transport mechanism,
usually for IP traf¬c or to internetwork with a circuit switched network. The global
Internet backbone consists of a considerable amount of ATM hardware, much of it not
capitalizing on the bene¬ts and facilities of ATM. This section addresses the mechanisms
used in UMTS for transporting IP over ATM, and outlines several strategies for IP/ATM
internetworking, particularly in the area of IP switching.
A typical deployment of ATM will establish a set of PVC connections between com-
ponents for the transport of both user data and control information to both core network

Circuit Core


Base Station RNC
Packet Core

Figure 7.80 UMTS main components

domains. These connections are dimensioned in advance by transmission planning. This
section also addresses the nature of the connections to both of these domains.

7.15.1 Packet core
To connect to the SGSN, the RNC transports IP packets over the Iu-PS interface. The RNC
is responsible for segmenting and reassembling the TBs used for data transfer between the
RNC and the UE. For the Iu-PS interface, the RNC has reassembled these TBs back to the
IP packets from the originating application at the UE. It is now sending these to the SGSN
using AAL5, which performs the segmentation and reassembly function to carry the traf¬c
in ATM. However, to support this IP transport, ATM must also provide a mechanism
to encapsulate the IP packets to allow the internetworking of the two protocols. It is
essential that ATM provide mechanisms to transport legacy data traf¬c across its network
infrastructure, the majority of this traf¬c being IP traf¬c. However, this interoperation of
the two protocols is non-trivial.
It has been seen that ATM is a connection-oriented protocol where a connection is
established between two parties prior to the transfer of data. In sharp contrast, IP uses a
datagram approach with each packet treated individually and dealt with independently by
each router.
Much of this IP traf¬c arrives at an ATM network from some other transport technology,
such as Ethernet, as is used in the GPRS core. There are two approaches to internetworking
with ATM:

• transfer the entire MAC frame (LAN emulation);
• extract the IP packet and transfer that (IP over ATM).

In addition, ATM networks are based on the provision of QoS to clients. IP uses a
best-effort approach where each router tries its best to forward the data, but provides no
guarantees of quality. To carry IP over ATM, the ATM protocol is viewed as a datalink
layer, with IP running on top of it. The ATM network is operating with its own addressing
scheme and so there needs to be a mapping between the IP addresses and the ATM
addresses of the underlying network. Therefore there needs to be some address resolution
protocol providing this mapping.

7.15.2 Data encapsulation
Two methods are de¬ned for data encapsulation of IP over ATM (RFC1483). The ¬rst
assigns a different virtual circuit (VC) for each protocol, whereas the second allows
multiple protocols to be carried on a single VC. Both approaches use AAL5 to carry the
IP protocol

• VC-based multiplexing: the VC is allocated to a single protocol, which is encapsulated
in the PDU ¬eld of AAL5. This approach is advantageous if a large number of VCs

can be established, and it is also quick and economical. However, it is not generally
used in practice since it requires the maintenance of a large number of VCs.
• LLC encapsulation: this method allows a number of protocols to be carried over the
one VC. The encapsulation system is designed for carrying both routed and bridged
protocols. However, only routed protocols will be discussed.

The protocol is identi¬ed by pre¬xing the IEEE 802.2 LLC header. The format of the
header is shown in Figure 7.81.
When the DSAP and SSAP are 0xAA and the control byte is 0x03, this indicates
that a non-ISO protocol is being encapsulated and the extended subnetwork access point
(SNAP) header is used, as shown in Figure 7.82. This header contains two extra ¬elds,
the OUI, which is a 3-byte organizationally unique identi¬er, identifying an organization,
which assigns a 2-byte protocol identi¬er, PID.
The format used in the encapsulation is split between ISO protocols, such as IS-IS, and
non-ISO protocols such as IP. The format of both is shown in Figure 7.83.
The ISO type is indicated by 0xFE FE 03. The 0x03 is for the control ¬eld and is
common to both, indicating unnumbered information. A non-ISO type is indicated by
0xAA AA 03. The EtherType identi¬es the protocol that is encapsulated. The IP packet


Figure 7.81 LLC header

0xAA 0xAA 0x03 OUI PID

Figure 7.82 Extended SNAP header

format for routed format for routed

LLC 0xFE FE 03 LLC 0xAA AA 03


. 102
( 132 .)