. 78
( 132 .)


Physical Layer

Figure 6.99 Iub protocol stack

messages. To meet this, the transport network layer provides the standard ATM signalling
protocol stack, often referred to as the signalling AAL (SAAL). The details of this are
described in Section 7.13.

6.19.2 Node B application part (NBAP)
The NBAP protocol provides all the control functionality required between a BTS and an
RNC. Its procedures can be broken into two classi¬cations: common and dedicated. Com-
mon NBAP procedures are de¬ned as all general, non-UE speci¬c, procedures, including
those used to establish an initial context for the mobile user. Dedicated NBAP procedures
relate to control of the UE once an initial context has been established. The key functions
provided by NBAP are:

• Management of radio links “ establishment, addition, recon¬guration and release of a
radio link.
• Base station management “ management of cell con¬guration and scheduling of broad-
cast information.
• Common channel management “ control of the common transport channels such as the
• Measurement and supervision “ reporting and control of measurement information to
the RNC, such as power measurements.
• Fault management “ reporting of general error situations. Radio link establishment
As an example transaction, consider the initial connection request to establish a radio
bearer. As shown in Figure 6.100, the RNC will issue a radio link setup request to the
BTS. If successful, this will result in the following actions at the BTS:

• The BTS will reserve the necessary resources, as speci¬ed in the setup request.
• The BTS will begin reception on the link.
• The BTS will respond to the RNC with a radio link setup response message.

The key parameters involved in the setup message are listed in the table in Figure 6.100.
The command passes the BTS only transport and physical layer parameters. Information
about radio bearers carried by this link is only relevant to the UE/RNC, since the BTS
does not deal with those layers of the protocol stack.
The allocation of uplink channelization code is not provided, but rather the minimum
spreading factor that should be used. The decision of which code to use is made by the
UE. The actual bearer for this will be initiated within the transport layer, at the request
of the RNC, using the transport network layer signalling protocol, ALCAP, which here
is AAL2 signalling. The NBAP response provides the AAL2 end system address, i.e. the

Radio Link Setup Request
Uplink scrambling code

Transport format
Radio Link Setup Request
combination set (UL/DL)

Minimum UL spreading factor
Radio Link Setup Response
Uplink SIR target
DL channelisation code
ALCAP transport bearer establishment
Power control information

Figure 6.100 NBAP radio link setup procedure

AAL2 address of the BTS. The actual addressing scheme is implementation dependent,
but would typically allocate an AAL2 address for each cell. It also provides a binding ID.
This value is used as an explicit reference to a set of signalling instructions. The binding
ID is generated by the BTS and sent to the RNC over NBAP. It is passed to and carried
within the ALCAP signalling protocol as an identi¬er to link the NBAP and ALCAP
signalling procedures for a given transaction. The RNC will then incorporate this value
to be carried in its ALCAP signalling procedure. Common channel establishment

An example of a common procedure, somewhat similar in format to the radio link setup,
is the common channel setup, where the common channels such as the RACH and FACH
are established. This procedure is normally done at cell setup, such as when a BTS reset
is initiated. The procedure is shown in Figure 6.101.
As an example, consider the RNC is establishing the RACH, the key parameters shown
will be included in the setup. Notice that the respective physical acquisition indication
channel (AICH) is established at the same time. The BTS will respond with a common
transport channel setup response to indicate the success or otherwise of the transaction.

Common transport channel
setup request
Common transport channel Common physical channel ID
setup request Scrambling code number
Transport format combination set
Common transport channel
Preamble signatures/access slots
setup response
AICH parameters

Figure 6.101 NBAP common channel setup

Cell setup request
DL/UL cell frequency
Cell setup request Max cell transmission power
Primary scrambling code
Primary & secondary SCH info
Cell setup response
Primary CPICH info
Primary CCPCH info

Figure 6.102 NBAP cell setup Cell setup
Another common NBAP procedure is cell setup, which establishes a cell and the initial
downlink channels for that cell. The procedure is shown in Figure 6.102.
The key elements of the cell setup are also shown. The RNC must allocate a cell-ID to
uniquely identify the cell in the RNS, and also indicate the uplink and downlink frequency.
This is passed as a UTRA absolute radio frequency channel number (UARFCN) value,
calculated as follows:

UARFCN = frequency (in MHz) — 5

For example, consider an operator has been allocated the frequency range 2110“
2115 MHz in the downlink. The central point of this, aligned to a 200 kHz raster, is
2112.4 MHz. The UARFCN of this is 2112.4 — 5 = 10 562.
Also included is the primary scrambling code for the cell, and the maximum trans-
mission power in the downlink for all the channels summed together. It is in the range
0“50 dBm (1 mW to 100 W). The physical channels established in the cell setup are
those for synchronization (P-SCH and S-SCH), the primary pilot channel (CPICH) and
the P-CCPCH, which carries the broadcast channel. The principal piece of information
de¬ned for each is the transmission power. For this, the absolute value of the pilot chan-
nel is de¬ned, in dBm, and all other channels are de¬ned as a dB offset to this value.
If there are any secondary pilot channels, they are also de¬ned here. The S-CCPCH,
which contains the paging channel and the FACH, is de¬ned using a common channel
con¬guration message.

6.19.3 Iur interface
As was previously mentioned, the Iub interface is de¬ned as a UNI due to its point-to-
point nature. The Iur and Iu interfaces are de¬ned as NNI, and therefore their structure,
while adhering to the standard format, is inherently more complicated. Figure 6.103 shows
the Iur interface protocol stack.
At the radio network layer, the format is much the same, but now with RNSAP as
the application part. However, at the transport network layer, there are some distinct

Radio Transport
Network Network
Control Plane Control Plane

RNSAP User Data


SCCP Q.2150.1





Physical Layer

Figure 6.103 Iur protocol stack

additions. On top of SAAL is placed the MTP3b protocol. For the radio network sig-
nalling bearer, the SCCP layer is implemented, while for ALCAP, Q.2150.1 is used, as
discussed in Chapter 7. The rationale for introducing these new layers is again to separate
this networked (NNI) signalling bearer infrastructure from the underlying ATM technol-
ogy. These layers are a broadband SS7 stack, as described later. One difference is that
MTP3b is used, which is a broadband version of MTP3 that supports transport of larger
message formats.

6.19.4 Radio network subsystem application part (RNSAP)
The Iur interface and RNSAP procedures are what enable Inter-RNC soft handover, where
a mobile device is connected through more than one radio link, and the BTSs are under

the control of different CRNCs. As explained earlier, the RNCs take on the logical role
of serving and drift RNC, where the SRNC manages the connection and maintains the
link to the core network. RNSAP is responsible for the control of this connection between
The functions of RNSAP may be broken into four key areas:

• Basic mobility: procedures which deal with mobility within the RAN, such as user
paging and signalling transfer.
• Dedicated: procedures to handle dedicated channels on the Iur interface, such as man-
agement of radio links and dedicated channel measurement.
• Common channel: procedures related to common transport channels, e.g. RACH and
• Global: procedures that do not relate to a particular user context. Therefore, these are
procedures between peer CRNC entities, since the DRNC/SRNC relationship is only
with respect to a speci¬c context. Error reporting is an example of a global procedure. Signalling transfer
An example of the use of RNSAP is in signalling transfer. This is used when a DRNC
receives an RRC signalling message from the UE on the CCCH that is for its SRNC. In
this instance, the signalling message will contain the U-RNTI of the UE. Recall that the
U-RNTI consists of the user™s S-RNTI and the ID of the SRNC. Therefore, the DRNC
must pass the message to the correct serving RNC. For this purpose it uses the uplink
signalling transfer indication, as shown in Figure 6.104.
If not already done, the DRNC will allocate the user a C-RNTI. If this is the ¬rst
signalling message the DRNC has received from this UE, it will also allocate a D-RNTI,
and include this D-RNTI in the signalling transfer message passed to the SRNC. The
other key parameters in the signalling transfer are also shown in Figure 6.104. Note that it
must contain the UTRAN cell-ID (RNC ID + cell ID) to uniquely identify this cell within
UTRAN. The normal cell-ID only identi¬es the cell within an RNS. To reply to the UE
in the downlink, the SRNC will send the downlink signalling transfer request, containing
the signalling message to send to the UE, containing the cell-ID that was included in
the uplink message. Upon receipt of this signalling message, the DRNC will transfer the
RRC signalling to the UE on the CCCH in the cell identi¬ed by the received cell-ID.

Uplink signalling
transfer indication
Message from UE
containing U-RNTI
Uplink signalling
transfer indication
Downlink signalling
transfer request UE signalling message

Figure 6.104 RNSAP signalling transfer


. 78
( 132 .)