. 101
( 132 .)


00000111 Connect

00001111 Connect ack

00000101 Setup

00001101 Setup ack

Call clearing messages

01001101 Call release

01011010 Release complete

Information messages

01110101 Status inquiry

01111101 Status

Figure 7.71 Message types

7 6 5 4 3 2 1 0 Byte
Information Element Identifier 1
Control information
Length of IE contents
Contents of IE
variable length

Figure 7.72 IE format

Table 7.25 Sample IE identi¬ers
Value Information element Description

01110000 Called party number Destination of the call
01110001 Called party subaddress Destination subaddress
01101100 Calling party number Origin of the call
01101101 Calling party subaddress Origin subaddress
01011000 AAL parameter Requested AAL type plus other parameters
01011001 ATM traf¬c descriptor Speci¬es traf¬c parameters
01011010 Connection identi¬er Identi¬es connection and gives VPI/VCI values
01011100 QoS parameter Indicates required QoS for the connection

Table 7.26 Call setup message
Message Call setup
IEs Setup message
Called party address
Calling party address
Quality of service
Traf¬c characteristics

Message length indicates the length of the contents of this message, since the infor-
mation elements can be variable in length. Some IEs can appear only once in a message
while others can appear more than once. The IEs included are dependent on the type of
message; some elements are mandatory and some optional. The format of an IE is shown
in Figure 7.72. Some sample information element identi¬ers are show in Table 7.25. As
an example, Table 7.26 shows a call setup message containing a number of IEs.

7.13.9 UNI4.0
UNI4.0 is an enhanced system, adding on top of UNI3.1 to provide additional features rec-
ommended by the ITU-T. The new features include support for ABR services, enhanced

QoS, proxy signalling intended for use in video on demand services, and virtual UNIs.
A signi¬cant change is the leaf initiated join function, which is an enhancement to
multicasting, allowing for parties to be added without requiring signalling back to the
call initiator.

One key feature of ATM is its ability to be scalable, meaning it should be equally at home
in a LAN environment and in a global backbone. A major stumbling block in achieving
this goal has been the static routing mechanisms generally deployed for con¬guration
of ATM switches in the backbone, where dynamic signalling of SVCs is not used. The
method used requires manual entry of routing information for PVCs into the routing tables
of switches, which had to be altered when the topology of the network changed, or each
time a new switch was added to the network. The solution presented by the ATM forum
is the PNNI standard. Figure 7.73 shows a conceptual view of PNNI implementation.
While PNNI is not used in the ¬rst release of UMTS, it is set to play an important role as
the network evolves to utilize packet switching exclusively. For example, the Release 5
all-IP network can be implemented on top of a large-scale ATM network.
PNNI is a hierarchical, dynamic link state routing protocol, which is designed to support
establishment of soft PVCs across large-scale networks. With a soft PVC, the start and
end points of the circuit are de¬ned, and then PNNI is used to calculate the best route.
However, PNNI provides more than a link state routing protocol and it can be described
as a topology state protocol since it also exchange information relating to QoS parameters.
Simply put, it dynamically updates switches about moves, additions and changes to the
network topology, enhancing the ability of ATM to deliver QoS.
PNNI simpli¬es the con¬guration of large networks since it enables switches to learn
about their neighbours and to dynamically distribute routing information. Switches can be
arranged in a hierarchical structure, with each level representing one or more switches.
A group of switches that are at the same level is referred to as a peer group. Topology
information about the link states is passed around the members of the peer group. Note


End system ATM Switch ATM Switch End system
Private Network Node Interface

network network
End system End system
Private Network to Network Interface

Figure 7.73 PNNI network

that if the network is of a smaller scale, it is possible to implement it as a single peer
group for all the switches on the network.

7.14.1 Peer group
Within a peer group, each switch sends hello packets across the NNI between it and
other switches. This is done to announce the existence of the switch so that each switch
within the peer group is aware of all the others. Once it is established that two switches
share the same peer group, they will exchange peer topology state packets (PTSPs). A
PTSP contains one or more peer topology state elements (PTSEs) advertising the switch™s
resources available on each of its links. A PTSE will describe the attributes of a link,
such as traf¬c type supported, maximum cell rate, cell delay variation, etc. Table 7.27
outlines some of the key parameters used, referred to as topology state parameters.
Based on this information, a switch can determine which is the best path to take to
ensure that the QoS parameters are adequately met. Thus PNNI is more complicated
than a standard routing protocol since a great deal more information is considered when
deciding on which route to take. This is summarized in Figure 7.74.
Note that the result of the routing decision is to look for an acceptable, rather than an
optimal path: PNNI only needs to ful¬l the requirements of the caller. Once this initial
exchange of topology information has occurred, the information will only be rebroadcast
if there is a signi¬cant change in its topology information. For example, if the maximum
cell rate of a link were to change, this would trigger a PTSE to be sent out from the
attached switches, information neighbours of the change. How is a ˜signi¬cant™ change
de¬ned? Here, signi¬cance is de¬ned for each parameter and in general means a speci¬ed
percentage change in a given parameter. For example, a signi¬cant change in bandwidth
could be de¬ned as when the bandwidth changes by 15%. The change percentages are

Table 7.27 Topology state parameters
Acronym Signi¬cance
MCTD Maximum cell transfer delay
MCTV Maximum cell transfer variation
MCLR Maximum cell loss ratio
ACR Available cell rate

Link conditions
Switch conditions ATM
Acceptable path(s)
Cost objective
Call request Performance objective

Figure 7.74 ATM routing

Can you
support this
ATM Switch


ATM Switch
ATM Switch ATM Switch

ATM Switch
Can the path
deliver QoS?

Figure 7.75 GCAC

up to the network administrator to decide. Since updates are triggered, this limits the
amount of traf¬c generated by the network, and the overheads introduced to maintain up-
to-date topology information. Therefore, a switch in a peer group has a detailed picture
of the topology of the whole group, enabling each switch to perform the entire call setup
procedure, thus speeding up the call setup time, i.e. call requests need not be handled at
each hop. This is referred to as source routing. The QoS support is handled by the CAC
of each switch. This means that the ¬rst switch making the routing decision does so based
on the information it has received from the other peer group members. This decision is a
best guess. The mechanism for deciding on a route is the generic call admission control
(GCAC). Figure 7.75 illustrates the concept.

7.14.2 AAL2 signalling
Recently, the ITU-T has developed a protocol to allow the switching of individual AAL2
channels, based on their channel identi¬cation (CID), independently of the ATM layer.
This has been possible due to the multiplexed nature of AAL2. This is particularly useful
where a virtual circuit is externally owned, as a PVC can be set up through the external
organization™s infrastructure, and its use maximized by multiplexing many AAL2 connec-
tions through it. Note this may often be the case, for example, between a base station and
RNC. This new protocol, Q.2630.1, was largely driven by requirements within mobile
networks, particularly for UMTS, and involved the participation of many large cellular
vendors, including Nokia, Ericsson, Lucent and Siemens.
A key feature of AAL2 signalling is that the AAL2 layer is independent of, and therefore
transparent to, the ATM layer and the existing ATM switches. No changes are required to
an underlying ATM network infrastructure, with the addition only of AAL2 end points.

If standard ATM switching was used, i.e. by the creation of an SVC to carry a voice call,
this would require the maintenance of millions of SVCs, putting a great burden on the
ATM switches. However, AAL2 switching allows for the switching of voice at the AAL2
layer. Its use in UTRAN is shown in Figure 7.76. The ATM layer is generally con¬gured
statically as PVCs in UMTS.
The protocol stack for AAL2 signalling is shown in Figure 7.77. It is used extensively
in UMTS for the establishment of AAL2 connections over PVCs. For example, PVCs
are con¬gured between the base station and RNC, with dynamic AAL2 connections
being created and torn down over them. Note that, like ATM signalling, AAL2 signalling
messages are carried over AAL5.
The Q.2630.1 protocol de¬nes the speci¬cation of AAL2 signalling, capability set 1.
It covers the establishment, maintenance and release of AAL2 connections across ATM
virtual circuits. The AAL2 signalling layer operates completes independently of the under-
lying ATM layers, and therefore allows a dynamic allocation of bearers over a static

L3 Signalling (CM, MM, SM) Core
UE Network

RRC Signalling
User Control User Control

NBAP Signalling RNSAP Signalling
UTRAN Control UTRAN Control UTRAN Control

AAL2 Signalling AAL2 Signalling
AAL2 Control AAL2 Control AAL2 Control

Network Network
ATM Control ATM Control ATM Control
Management Management

Base Station Iub Drift RNC Iur Serving RNC

Figure 7.76 AAL2 use in UMTS


. 101
( 132 .)