Optimization Guidelines:

Accessibility in Ericsson

CONTENTS
1 INTRODUCTION...............................................................................................................................3
2 ACCESSIBILITY................................................................................................................................4
2.1 Idle Mode..................................................................................................................................................4
2.2 Call Establishment Process......................................................................................................................4

3 ACCESSIBILITY KPIs (Key Performance Indicators)....................................................................5

3.1 High Level KPIs.......................................................................................................................................5
3.1.1 Call Setup Success Rate - CSSR (%).................................................................................................................5
3.1.1.1 CS CSSR (%).......................................................................................................................................5
3.1.1.2 PS CSSR (%).......................................................................................................................................6
3.1.1.3 CS CSSR (%) from P7.1-...................................................................................................................6
3.1.1.4 PS CSSR (%) from P7.1-..................................................................................................................7
3.1.2 Overall Service Accessibility - OSAC (%)........................................................................................................7

3.2 Medium Level KPIs.................................................................................................................................8

3.2.1 RRC Connection Success Rate (%)....................................................................................................................8
3.2.1.1 RRC Connection Success Rate CS (%)...............................................................................................9
3.2.1.2 RRC Connection Success Rate PS (%)................................................................................................9
3.2.2 Iu Signalling Establishment Success Rate (%)...................................................................................................9
3.2.2.1 Iu-CS Signalling Establishment Success Rate (%)..............................................................................9
3.2.2.2 Iu-PS Signalling Establishment Success Rate (%)..............................................................................9
3.2.3 NAS Signalling Establishment Success Rate (%) from P7.1-........................................................................10
3.2.3.1 NAS CS Signalling Establishment Success Rate (%) from P7.1-..................................................10
3.2.3.2 NAS PS Signalling Establishment Success Rate (%) from P7.1-...................................................10
3.2.4 (RAB) Establishment Success Rate (%)...........................................................................................................10
3.2.5 Sending Paging Failure Rate (%).....................................................................................................................11
3.2.6 Blocking Probability.........................................................................................................................................11
3.2.6.1 GoS Speech (%).................................................................................................................................11
3.2.6.2 GoS PS (%)........................................................................................................................................11

3.3 Failures after Admission Rate (%):......................................................................................................12

4 PERFORMANCE ANALYSIS.........................................................................................................13
4.1 Admission Control.................................................................................................................................13
4.1.1 Admission Policy..............................................................................................................................................13
4.1.2 Resources to be monitored...............................................................................................................................14
4.1.2.1 RF Power............................................................................................................................................14
4.1.2.2 Code Tree Consumption.....................................................................................................................14
4.1.2.3 DL and UL ASE.................................................................................................................................14
4.1.2.4 SF Code Limit (Code Hystogram).....................................................................................................14
4.1.2.5 HSDPA and EUL connections Limit..................................................................................................14
4.1.2.6 UL and DL Channel Elements...........................................................................................................15
4.1.3 RRC Admission Blocks....................................................................................................................................15
4.1.4 RAB Admission Blocks....................................................................................................................................15

4.2 MP Load (High processor Load)...........................................................................................................16

4.3 After Admission......................................................................................................................................16
4.3.1 Failure after Admission: Iub Congestion.........................................................................................................16
4.3.1.1 Low RRC Success Rate.....................................................................................................................16
4.3.1.2 Low RAB Success Rate.....................................................................................................................17
4.3.2 Failure after Admission: Core Transport Network Congestion.......................................................................17
4.3.3 Failure after Admission: Hardware Usage (Channel Elements)......................................................................17
4.3.4 Failure after Admission: Channelization Codes..............................................................................................18
4.3.5 Failure after Admission: Others.......................................................................................................................18

4.4 Accessibility issues not detected by counters........................................................................................18

4.4.1
4.4.2
4.4.3
4.4.4
4.4.5

HW Problems in the RBS.................................................................................................................................19

UL Interference.................................................................................................................................................19
RACH misconfiguration...................................................................................................................................19
Cell Unavailability............................................................................................................................................19
Node Blocking..................................................................................................................................................19

5 REFERENCES.................................................................................................................................20
6 ANNEX I: UE Idle Mode Procedures..............................................................................................21
6.1 PLMN Selection and Reselection..........................................................................................................21
6.2 Reading System Information.................................................................................................................22
6.3 Cell Selection and Reselection...............................................................................................................23
6.3.1
6.3.2
6.3.3
6.3.4

Cell Selection....................................................................................................................................................24
Cell Reselection................................................................................................................................................24
Location/Routing Area Update.........................................................................................................................25
Paging Procedure..............................................................................................................................................25

7 ANNEX II: Call Establishment Procedure......................................................................................27

7.1 Voice Call Establishment.......................................................................................................................27
7.2 PS Data Call Establishment...................................................................................................................27
7.3 Radio Resource Control (RRC).............................................................................................................28
7.3.1 RRC connection Request & Setup...................................................................................................................28

7.4 Core Network Negotiation.....................................................................................................................30

7.5 Radio Access Bearer (RAB) Setup and Reconfiguration.....................................................................30

1 INTRODUCTION
This series of Optimization Guidelines covers all the main topics regarding
Performance Monitoring & Analysis
Configuration settings
Troubleshooting
Refer to the internal Claro document Optimization Process (DEO.OTM.IOP3000), for a summary of 3G
WCDMA Radio Access Network Optimization Basics.
This specific document focuses on ACCESSIBILITY and its specifics within ERICSSON infrastructure
(Release P7.1).
Target users for this document are all personnel requiring a detailed description of this process
(Accessibility Optimization), as well as configuration managers who require details to control the
functions and optimize parameter settings. It is assumed that users of this document have a working
knowledge of 3G telecommunications and are familiar with WCDMA.

Document Revision Control

Revisio
n
Draft 01

Date

Author

13-Nov-2009

QCES/Ericsson

Changes
First Release of the document
Update from P7 to P7.1:
NAS signalling phase counters added, both to
CSSR KPIs and Medium Level KPIs

01

12-Mar-2010

QCES/Ericsson

Corrections/Additions::
pmNoLoadSharingRrcConnCs/Ps added to
CSSR KPIs
Iu Signalling connection phase added to CSSR
KPIs
CS and PS CSSR now correctly expressed in
terms of SUM of all CS / PS RAB types
Additional formulas for GoS metrics
New sections added in Annex for Core
Negotiation and RAB Setup and
Reconfiguration phases

2 ACCESSIBILITY
Accessibility is the ability of a service to be obtained within specific tolerances and other given
conditions, when requested by the user. In other words, the ability of a user to obtain the requested
service from the system.
Target is to get a 100% Accessibility, i.e., all users always get the service they request.
Poor Accessibility is typically due to
some form of congestion (before or after Admission Control?)
hardware/software fault (Check ALARMS, Cells Downtime, tickets in REMEDY)
misconfiguration (AUDIT the settings in RNC)
other reasons (for instance, it is also possible that there is some external source of interference
(such as a microwave link on the same frequency) affecting the accessibility)
Accessibility is to be monitored independently for the different RAB types (e.g. Speech, CS Video, PS
Interactive R99, PS Interactive HSDPA, etc.) as in certain situations only one of the RAB types will be
affected.

2.1 Idle Mode

Accessibility issues may occur related to the UE idle mode behavior.
The UE in Idle mode performs next 5 main tasks [Refer to ANNEX I for a brief review]:
PLMN selection and reselection
Reading system information (MIB, SIB)
Cell selection and reselection
Location area (LA) and routing area (RA) registration/update
Paging procedure
Settings should guarantee that the UE in idle mode is always in the best conditions to access the
network (i.e., to initiate a Mobile Originated call, MO) and be reached by the network (i.e., to receive a
Mobile Terminated call, MT).

2.2 Call Establishment Process

Each step in the Call Establishment process should be monitored in order to clearly identify where the
accessibility issue is located. For a more complete review of the Call Establishment Process, refer to
ANNEX II.

3 ACCESSIBILITY KPIs (Key Performance Indicators)

Below the main metrics used for Accessibility Monitoring of a 3G WCDMA/UMTS Network, and their
implementation with Ericsson counters.
Refer to SMART Documentation for further details on the actual implementation of these KPIs in the
tool, together with the additional considerations regarding:
Treatment of zeros in the denominators
Cell Reselection during RRC Establishment Phase
RRC Redirections (Load Sharing feature)
RRC Repetitions
Incoming HHO and SRNS Relocations
RAB Load Sharing features (Inter-frequency and Directed Retry to gsm)

3.1 High Level KPIs

3.1.1 Call Setup Success Rate - CSSR (%)

This is the first overall metric we are considering to monitor Accessibility as a whole.
Up to P7.1, this KPI was typically calculated by considering just 2 steps in Call Establishment: RRC
Connection Setup and RAB Establishment. They are assumed to be independent processes, and
therefore CSSR was hence calculated as product of the Success Rates of each of these 2 phases
(described later in section 3.2):
CS/PS_CSSR = 100 * CS/PS_RRC_SSR * CS/PS_RAB_ESR
where:
CS/PS_RRC_SSR = RRC Setup Success Rate (with CS/PS Establishment Causes) =
( # CS/PS RRC Connection Setup Complete / # CS/PS RRC Connection Request)
CS/PS_RAB_ESR = RAB Establishment Success Rate (for CS/PS RABs, both R99 and HS) =
( # CS/PS RAB Assignment Complete / # CS/PS RAB Assignment Request)
3.1.1.1 CS CSSR (%)
(For CS connection requests)
100*

pmTotNoRrc
ConnectReq
CsSucc

(pmTotNoRr
cConnectRe
qCs - pmNoLoadSh
aringRrcCo
nnCs)

pmNoRabEst
ablishSucc
ess(RAB)
(RAB)

pmNoRabEst
ablishAtte
mpt(RAB)]- pmNoDirRet
ryAtt

(RAB)

where (RAB) = Speech, Cs64, Cs57

Low value (e.g. <95%) indicates problems to establish a CS call between UEs and CS domain CORE.
Similar formulas can be used for each specific RAB CSSR, i.e., Speech CSSR (%) or CS64 CSSR (%).
Note that by removing pmNoDirRetryAtt from the denominator, those redirected speech calls attempts
are excluded from the calculation. So if their establishments succeed or fail in GSM is not taken into
account in this KPI
3.1.1.2 PS CSSR (%)
(For PS connection requests, both R99 PS and HS)
100*

pmTotNoRrc
ConnectReq
PsSucc

(pmTotNoRr
cConnectRe
qPs - pmNoLoadSh
aringRrcCo
nnPs)

pmNoRabEst
ablishSucc
ess(RAB)
(RAB)

pmNoRabEst
ablishAtte
mpt(RAB)
(RAB)

where (RAB) = PacketStream, PacketStream128, PacketInteractive

Low value (e.g. <95%) indicates problems to establish a PS call between UEs and PS domain CORE.
Similar formulas can be used for each specific RAB CSSR, i.e., PS Streaming CSSR (%) or PS Interactive
CSSR (%).
Refer to the internal Claro doc. Optimization Guidelines: Capacity in Ericsson (DEO.OTM.IOP3041) for
further details regarding the Ericsson features Load Sharing and Directed Retry.

From P7.1 (P7 FP), current release in Claro, new counters are available for monitoring the performance
of the NAS Signalling phase (i.e. after IU Signalling Connection establishment and before RAB
Assignment Request).
New formulas will also cover the Iu Signalling Connection phase performance through counters
already available before P7.1 in MO RNCFunction; therefore, the same Iu Sig. Conn. Success Rate value
is to be applied to all UtranCells under the same RNC.
As the new formulas below will compute failures in these 2 additional phases (see next figure), a slight
degradation in these KPIs might be observed after their introduction when comparing to old formulas
above.

3.1.1.3 CS CSSR (%) from P7.1100*

pmTotNoRrc
ConnectReq
CsSucc
stablishSu
ccessCs
* pmNoIuSigE
*
pmNoIuSigE

(pmTotNoRr
cConnectRe
qCs - pmNoLoadSh
aringRrcCo
nnCs)
stablishAt
temptCs
ablishSucc
ess(RAB)] pmNoDirRet
rySuccess pmNoInCsIr
atHoSucces
s
[ pmNoRabEst
pmNoSystem
NasSignRel
easeCs
(RAB)

pmTotNoRrc
ConnectReq
CsSucc
[ pmNoRabEst
ablishAtte
mpt(RAB)] pmNoInCsIr
atHoAtt
(RAB)

where (RAB) = Speech, Cs64, Cs57

Note that 2 important additions have been made to this KPI:
1. By adding pmNoDirRetrySuccess in the RAB term numerator, this KPI does take into account the
success rate of the speech calls redirected to gsm by the Directed Retry mechanism.
2. By adding pmNoInCsIratHoSuccess/Att counters in the RAB term, this KPI now also takes into
account the success rate of the Speech Calls entering the 3G network via Incoming CS IRAT HO.

3.1.1.4 PS CSSR (%) from P7.1100*

pmTotNoRrc
ConnectReq
PsSucc pmTotNoRrc
ConnectSuc
cessIratCe
llResel pmTotNoRrc
ConnectSuc
cessIratCc
Order

(pmTotNoRr
cConnectRe
qPs - pmNoLoadSh
aringRrcCo
nnPs) pmTotNoRrc
ConnectAtt
IratCellRe
sel pmTotNoRrc
ConnectAtt
IratCcOrde
r
ablishSucc
ess(RAB)
pmNoRabEst
pmNoIuSigE
stablishSu
ccessPs
NasSignRel
easePs
(RAB)

pmNoSystem

* 1
*

pmNoIuSigE
stablishAt
temptPs
PsSucc
pmNoRabEst
ablishAtte
mpt(RAB)
pmTotNoRrcConnectReq
(RAB)

where (RAB) = PacketStream, PacketStream128, PacketInteractive

Note that one important addition has been made to this KPI:
1. By adding pmTotNoRrcConnectSuccess(Att)IratCellResel(CcOrder) counters in the RRC term, this
KPI now also takes into account the success rate of the PS Calls entering the 3G network via
Incoming IRAT Cell Change Order or IRAT Cell Reselection.
[Pending Confirmation from Ericsson]

3.1.2 Overall Service Accessibility - OSAC (%)

Since there are many different services defined in UMTS and each one can have a different accessibility
at any time, an overall service accessibility can be defined to obtain an overall measure of network
accessibility averaged over all services. This metric can be used in case one single measurement is to
be applied to sort out the worst overall inaccessible cells.

The OSAC criterion will be based on a weighted averaging of the accessibility for the CS and PS services
supported by the cell. The weighting factors will be chosen to be the demand for the service given by
the number of RAB Establish attempt for that service.

pmNoRabEstablishSuccessSpeech

+pmRabEstablishEcSuccess

pmNoRabEst
abl
i
s
hAtte
mptSpeech

pmTotNoRrcConnectReqCsSucc +pmNoRabEstablishSuccessCs64

*
pmNoRabEstabl*is+hSucc

pmRabEstab
l
i
s
hEcAtte
mpt

essSpeech

pmTotNoRrc

pmTotNoRrcConnectReq

Cs ConnectReq
pmNoRabEst
ablishAtte
mptSpeech

CsSucc

lishEcSucc
+
pmNoRabEst
abl
i
s
hAtte
mptCs64

*
+
pmRabEstab
ess

+
pmRabEstab
l
i
s
hEcAtte
mpt
pmTotNoRrcConnectReqCs

+
pmNoRabEst
abl
i
s
hSucc
essCs64

+pmNoRabEstablishAttemptCs64

pmTotNoRrc ConnectReq

pmNoRabEst
PsSuccablishSuccessPacketInteractive

pmTotNoRrc
ConnectReq
PsSucc

*
pmNoRabEst
abl
i
s
hSucc
essPacketI
nteracti
v
e

*
* pmNoRabEstablishAtte mptPacketInteractive

Ps ConnectReq
pmNoRabEstPsablishAttemptPacketInteractive
pmTotNoRrcConnectReq
pmTotNoRrc

100*
OSAC = 100 * [(CS CSSR * CS RAB Assignment Request) + (PS CSSR * PS RAB Assignment Request)] /
Sum(# CS & PS RAB Assignment Request)
where:
CS/PS CSSR = Call Setup Success Rate, as described in the previous section.
Or simplifying:

100 * [(CS_RRC_SSR * CS RAB Assignment Complete) + (PS_RRC_SSR * PS RAB Assignment

Complete)] /
Sum(# CS & PS RAB Assignment Request)
where:
CS/PS_RRC_SSR = RRC Setup Success Rate (with CS/PS Establishment Causes) =
(# CS/PS RRC Connection Setup Complete / # CS/PS RRC Connection Request)

The KPI can be built for Ericsson in the following way

(load sharing, directed retry, Iub Sign. & NAS connection establishments have been omitted for
simplicity):

Simplifying:

100*

lislihEcAtte
ishAttemptSpeech
mptSpeech++pmRabEstab
pmRabEstab
shEcAttemptmpt++
pmNoRabEst

pmNoRabEstablablishAtte
ishAttemptCs64
mptCs64++pmNoRabEst
pmNoRabEstablablishAtte
ishAttemptPacketI
mptPacketInteracti
nteractiveve
pmNoRabEst
pmNoRabEstablablishAtte

3.2 Medium Level KPIs

3.2.1 RRC Connection Success Rate (%)

(For all connection requests)
100*

pmTotNoRrc
ConnectReq
Success

pmTotNoRrc
ConnectReq
- (pmNoLoadS
haringRrcC
onn - pmNoOfRetu
rningRrcCo
nn)

Low value (e.g. <95%) indicates problems to establish a generic radio connection between UEs and RNC
starting from idle mode state.
Notes:

pmNoOfReturningRrcConn (number of Load Sharing diversions when establishing an RRC

connection that returns to the first frequency) is not available per domain (CS, PS), so next two
metrics are missing this correction.

RRC connection attempts are not corrected for emergency calls redirections. Counters
pmNoOfRedirectedEmergencyCalls and pmNoOfReturningEmergencyCalls (MO RNCFunction)
could be used to estmate their contribution at RNC level.

Due to the fact that the UE may perform cell re-selection during the RRC Connection
establishment (it may repeat RRC Connection Request message N300 times which may arrive
at different cell) and the fact that WCDMA RAN (the RNC) does not double count the duplicated
RRC Connection Request messages received, there is a chance that the RRC access success
rate for some cells may show values above 100%. The access success rate better than 100%
happens when the attempt is registered in a cell different to the cell where the success is
registered. The end result is a slightly better success rate for the cell that completes the access
and a slightly worst success rate for the cell where the access was attempted/started.

3.2.1.1 RRC Connection Success Rate CS (%)

(For CS connection requests)
100*

pmTotNoRrc
ConnectReq
CsSucc

pmTotNoRrc
ConnectReq
Cs - pmNoLoadSh
aringRrcCo
nnCs

Low value (e.g. <95%) indicates problems to establish a radio connection between UEs and RNC starting
from idle mode state in particular affecting CS services (speech and video calls).
3.2.1.2 RRC Connection Success Rate PS (%)
(For PS connection requests)
100*

pmTotNoRrc
ConnectReq
PsSucc

pmTotNoRrc
ConnectReq
Ps - pmNoLoadSh
aringRrcCo
nnPs

Low value (e.g. <95%) indicates problems to establish a radio connection between UEs and RNC starting
from idle mode state in particular affecting PS services.

3.2.2 Iu Signalling Establishment Success Rate (%)

(For all connection requests)
100*

pmNoIuSigE
stablishSu
ccessCs pmNoIuSigE
stablishSu
ccessPs

pmNoIuSigE
stablishAt
temptCs pmNoIuSigE
stablishAt
temptPs

Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC
and CORE.

Note these counters are in MO RNCFunction (hence, only available at RNC level).
3.2.2.1 Iu-CS Signalling Establishment Success Rate (%)
(For CS connection requests)

100*

pmNoIuSigE
stablishSu
ccessCs

pmNoIuSigE
stablishAt
temptCs

Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC
and CS domain CORE.
3.2.2.2 Iu-PS Signalling Establishment Success Rate (%)
(For PS connection requests)
100*

pmNoIuSigE
stablishSu
ccessPs

pmNoIuSigE
stablishAt
temptPs

Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC
and PS domain CORE.
3.2.3 NAS Signalling Establishment Success Rate (%) from P7.1(For all connection requests)
100*

pmNoSystem
NasSignRel
easeCs pmNoSystem
NasSignRel
easePs

pmTotNoRrc
ConnectReq
CsSucc pmTotNoRrc
ConnectReq
PsSucc

Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC
and CORE.
Note these counters are in MO RNCFunction.
3.2.3.1 NAS CS Signalling Establishment Success Rate (%) from P7.1(For CS connection requests)

100*

pmNoSystem
NasSignRel
easeCs

pmTotNoRrc
ConnectReq
CsSucc

Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC
and CS domain CORE.
3.2.3.2 NAS PS Signalling Establishment Success Rate (%) from P7.1(For PS connection requests)
NasSignRel
easePs

pmNoSystem
100* 1

PsSucc
pmTotNoRrcConnectReq
Low value (e.g. <95%) indicates problems to establish the Iu part of the Control Plane between the RNC
and PS domain CORE.

3.2.4 (RAB) Establishment Success Rate (%)

100*

pmNoRabEst
ablishSucc
ess(RAB)

pmNoRabEst
ablishAtte
mpt(RAB)

Where (RAB) = Speech, Cs64, Cs57, PacketInteractive, PacketInteractiveHs, PacketInteractiveEul,

PacketStream, PacketStream128 or PacketStreamHs.
Note that these counters for PacketInteractive include also PacketInteractiveHs, and counters for
PacketInteractiveHs include also PacketInteractiveEul.
For Speech RAB, please refer to comments on Section 3.1.1.3 regarding different possibilities to modify
this formula for RAB Establishment Success Rate so it can also cover as 3G access failures those
directed retries to gsm and incoming IRAT HOs that fail.

Low value (e.g. <95%) indicates problems to establish a RAB after the RAB assignment coming from the
CORE network.

3.2.5 Sending Paging Failure Rate (%)

100*

pmNoPageDi
scardCmpLo
adC pmNoPaging
AttemptUtr
anRejected

pmCnInitPa
gingToIdle
Ue pmCnInitPa
gingToIdle
UeRa pmCnInitPa
gingToIdle
UeLa pmNoPageDi
scardCmpLo
adC

High value (e.g. >2%) indicates problems to send paging through the radio network due to overload.
Formula above is valid if URA_PCH state is disabled (current situation in Claro). In case it is enabled, the
Formula should be replaced by the following one:

100*

pmNoPageDiscardCmpLoadCpmNoPaginAtg temptUtanRejr ected

[Pending Confirmation from Ericsson]

pmCnInitPagingToIdleUe pmCnInitPagingToIdleUeRa pmCnInitPagingToIdleUeLa

3.2.6 Blocking Probability

Implemented through the GRADE OF SERVICE (GoS): Probability of a call in a circuit group being blocked
or delayed for more than a specified interval, expressed as a common fraction or decimal fraction.

pmCnInitPagingToUraUe pmUtranIntiPagingToUraUe pmNoPageDiscardCmpLoadC

3.2.6.1 GoS Speech (%)

[Check this at cell level].
100*

1-

pmNoRrcCsR
eqDeniedAd
m

pmTotNoRrc
ConnectReq
Cs

* 1

pmNoOfNonH
oReqDenied
Speech

pmNoRabEst
ablishAtte
mptSpeech

High value (e.g. >2%) indicates problems to establish a Voice call mainly related to Admission Control,
i.e., due to some kind of capacity shortage (DL TX Power, CE, OVSF codes,).
This metric could be used to identify a wider range of reasons behind access failures: not only RN
admission blocking (as above), but also TN congestion or TN failure (as in the alternative formula
below):

pmNoRrcCsReqDeniedAdm pmNoRrcConnReqBlockTnCs

*
1
pmTotNoRrcConnectReqCs

100* 1 -

pmNoOfNonH
oReqDenied
Speech

pmNoRabEst
BlockTnSpe
echBest

pmNoRabEstablishAttemptSpeech

3.2.6.2 GoS PS (%)

[Check this at cell level].
100*

1-

pmNoRrcPsR
eqDeniedAd
m

pmTotNoRrc
ConnectReq
Ps

pmNoOfNonH
oReqDenied
Interactiv
e

* 1

pmNoRabEst
ablishAtte
mptPacketI
nteractive

High value (e.g. >2%) indicates problems to establish a Voice call mainly related to Admission Control,
i.e., due to some kind of capacity shortage (DL TX Power, CE, OVSF codes,).

This metric could be used to identify a wider range of reasons behind access failures: not only RN
admission blocking (as above), but also TN congestion or TN failure (as in the alternative formula
below):

pmNoRrcPsReqDeniedAdm pmNoRrcConnReqBlockTnPs

*
1

pmTotNoRrcConnectReqPs

100* 1 -

pmNoOfNonHoReqDeniedInteractive pmNoRabEstBlockTnPsIntNonHsBest pmNoRabEstBlockTnPsIntHsBest

1

pmNoRabEstablishAttemptPacketInteractive

GoS can be estimated for other RABs in a similar way: CS, PS Streaming DCH, PS Streaming HS.

3.3 Failures after Admission Rate (%):

This KPI provides the number of Radio Resource Control (RRC) or Radio Access Bearer (RAB)
establishment requests failed after being admitted by Admission Control (AC).
100*

pmNoFailed
AfterAdm

pmTotNoRrc
ConnectReq

High value (e.g. >5%) indicates problems accessibility problems happening once the RRC or RAB has
been admitted by AC. These issues are analyzed later in this document.

4 PERFORMANCE ANALYSIS
Following the Hierarchical KPIs methodology described in the internal Claro doc. Optimization Process
(DEO.OTM.IOP3000), once identified areas/nodes/cells showing bad performance through the overall
KPIs defined above, analysis to find out the cause root of the problem should be performed. To do so, we
move towards an in-depth analysis based in more detailed and specific raw counters (Low Level KPIs).
In the case of Ericsson infra, this analysis for Accessibility issues will explore in 3 different directions:

Note: A 4th line of investigation has been added at the end of the section to cover those Accessibility
issues not detected by counters.

4.1 Admission Control

The purpose of the Admission Control is to limit the traffic that is admitted in order to ensure that all
traffic that is admitted meets the requirements on the quality of the service.
4.1.1 Admission Policy
When new resources are needed for a radio connection, the RN Admission Control function receives a
request for admission. The request specifies the estimated amount of system resources that the radio
connection needs.

In Ericsson, a request can be guaranteed or non-guaranteed:

A request is guaranteed when requesting minimum amount of resources for a radio connection
satisfying the QoS (this is referred to lowest retainable rate). Example of a guaranteed request is
Speech, CS conversational, CS or PS streaming and PS interactive 8/8.
When the request is for resources exceeding the minimum needed for satisfying the QoS (for
example up-switch interactive PS to a higher dedicated rate), the request is non-guaranteed.
Example of a non-guaranteed request is PS interactive.

4.1.2 Resources to be monitored

4.1.2.1 RF Power
Lack of Downlink Power (pmNoFailedRabEstAttemptLackDlPwr)
Note: The RF power is measured and regulated at the reference point and also the power limits have to
be calculated at the reference point.
4.1.2.2 Code Tree Consumption
Lack of Canalization Code (pmNoFailedRabEstAttemptLackDlChnlCode)
Note: The code tree consumption is measured in percentage of the total tree size by excluding the fixed
codes allocated for HSDPA (i.e. the higher the number of codes allocated for HSDPA the smaller will be
the available tree and higher the relative consumption).
The admission limit is set by dlCodeAdm (as a percentage).
4.1.2.3 DL and UL ASE
Lack of Downlink ASE (pmNoFailedRabEstAttemptLackDlAse)
Lack of Uplink ASE (pmNoFailedRabEstAttemptLackUlAse)
Note: ASE is used as an overall measurement of the cell load on the air interface but ASE is not a real
cell resource. It intends to express the static load on the air-interface caused by radio bearers in a cell,
relative to the static load caused by a set of conversational.
4.1.2.4 SF Code Limit (Code Hystogram)
Exceed SF histogram (pmNoFailedRabEstAttemptExceedConnLimit)
Note: In order to limit the number of high codes and HW consumption RABs specific thresholds are set
for each SF.
4.1.2.5 HSDPA and EUL connections Limit
RN Admission Control blocks new radio link admission requests which involve the allocation to HSDSCH/HS-SCCH when the number of users assigned to the HS-DSCH in the cell exceeds the load control
level hsdpaUsersAdm. RN Admission Control shall reject an EUL user, requesting the cell as serving cell
if the total number of serving cell EUL users including the requested is above eulServingCellUsersAdm.

4.1.2.6 UL and DL Channel Elements

Lack of DL Channel Elements (pmNoFailedRabEstAttemptLackDlHw)
Lack of UL Channel Elements (pmNoFailedRabEstAttemptLackUlHw)
Note: The HW resources are monitored by Admission Control as ay other physical resource. Soft
congestion is used to control the overload. The following thresholds are used: dlHwAdm, ulHwAdm
4.1.3 RRC Admission Blocks
It is possible also to check separately CS and PS RRCs and evaluate the success:
If
low
pmTotNoRrcConnectCsReqSucc
pmNoRrcCsReqDeniedAdm

pmTotNoRrcConnectReqCs,

then

check:

If
low
pmTotNoRrcConnectPsReqSucc
pmNoRrcPsReqDeniedAdm

pmTotNoRrcConnectReqPs,

then

check:

4.1.4 RAB Admission Blocks

You must compare the RAB establishments blocked by admission control with the RAB attempts:
100*

pmNoOfNonH
oReqDenied
Speech
pmNoRabEst
ablishAtte
mptSpeech

100*

pmNoOfNonH
oReqDenied
Cs
(pmNoRabEs
tablishAtt
emptCs64
pmNoRabEst
ablishAtte
mptCs57)

pmNoOfNonH
oReqDenied
Interactiv
e

100*

pmNoRabEst
ablishAtte
mptPacketI
nteractive

100*

pmNoOfNonH
oReqDenied
PsStreamin
g
pmNoRabEst
ablishAtte
mptPacketS
tream

pmNoOfNonH
oReqDenied
Hs

100*

pmNoRabEst
ablishAtte
mptPacketI
nteractive
Hs

pmNoOfNonH
oReqDenied
Eul

100*

pmNoRabEst
ablishAtte
mptPacketI
nteractive
Eul

100*

pmNoOfNonH
oReqDenied
PsStr128
pmNoRabEst
ablishAtte
mptPacketS
tream128

Note: RAB admission blocks could have more impact on accessibility compared to RRC blocks, especially
for PS services, since the required resources during the RAB assignment are higher.

4.2 MP Load (High processor Load)

Check pmNoRejRrcConnMpLoadC - Number of rejected RRC connections due to MP load control.
Note: The module MP handles signalling associated with traffic events.
Connection setup and release (Speech, PS R99, HS, LA update, SMS).

4.3 After Admission

Number of Radio Resource Control (RRC) or Radio Access Bearer (RAB) establishment requests failed
after being admitted by admission control.
If either a RRC or RAB establishment procedure fails AFTER the admission has been granted for the
establishment (RRC or RAB), counter pmNoFailedAfterAdm will be incremented at the cell or cells where
the UE is located.
Follows a list of causes for failures after admission:
Transport failures

TN failure reasons

AAL2 setup failure (due to congestion or miss configuration)

Code allocation failures
Channel elements allocation failures

NBAP RL setup failure (RAX or TXB congestion)

HW fault in the RBS
UE failures
Timeout in the UE, RNC or RBS
Invalid parameter settings
4.3.1 Failure after Admission: Iub Congestion
Iub congestion is a common reason for high number of failures after admission events.
Depending on the volume of traffic per service or RAB, certain QoS could be congested at the AAL2: All
RABs excluding HSDPA are configured to use Class A or Class B being these two mostly impacted by
congestion. Most of the time Class B is the first QoS to get congested leading to failures after admission
events.

Iub congestion could also be caused by E1 issues.

Misconfiguration of AAL2 profile at the Node B, RNC or RXI/MSN can lead to Iub congestion as well.
Possible indicators:
Check for congestion at the Iub link (See below)
Check for E1 issues and history of alarms of E1s (for intermittent E1 alarms)
Possible solutions for Iub congestion:
Enable Directed retry (short term solution).
Correct possible AAL2 miss configuration at Node B, RNC and RXI (AAL2 profile must match in all
entities)
Order new E1s (long term solution).
Change AAL2 QoS configuration depending on services request volume (CS voice, R99 data, HSDPA,
etc).
4.3.1.1 Low RRC Success Rate
In case a poor RRC Success Rate is detected and neither Admission Blocks nor MP Load rejections can
explain such a degradation of the RRC Accessibility, then check these 2 counters:
pmNoRrcConnReqBlockTnCs
RRC CS failures due to congestion on the user plane (AAL2) or control plane (UniSaal or SCTP) of
the transport network.
pmNoRrcConnReqBlockTnPs
RRC PS failures due to congestion on the user plane (AAL2) or control plane (UniSaal or SCTP) of
the transport network.
If none of the above counter values can explain the poor RRC success rate more traces have to be
considered e.g. UETR (AAL2) or control plane (UniSaal or SCTP) of the transport network.
4.3.1.2 Low RAB Success Rate
Similar analysis can be done for RABs Blocked due to transport network congestion including:
Speech:

pmNoRabEst
BlockTnSpe
echBest

100*

pmNoRabEst
ablishAtte
mptSpeech

Videocall:

100*

pmNoRabEst
BlockTnCs6
4Best
pmNoRabEst
ablishAtte
mptCs64

PS R99:100*

pmNoRabEst
BlockTnPsI
ntNonHsBes
t
(pmNoRabEs
tablishAtt
emptPacket
Interactiv
e - pmNoRabEst
ablishAtte
mptPacketI
nteractive
Hs)

HSDPA:

100*

pmNoRabEst
BlockTnPsI
ntHsBest
pmNoRabEst
ablishAtte
mptPacketI
nteractive
Hs

4.3.2 Failure after Admission: Core Transport Network Congestion

Accessibility issues are observed on all sites at the RNC without major issues with Iub congestion
(especially at peak hour): Congestion will be observed at Iu-CS (RNC<-->MGW) or Iu-PS (RNC<->SGSN) links.
Possible indicators:
Degradation of KPIs Iu(CS/PS) Signalling Establishment Success Rate (%) would be expected in this
case.
Note: Congestion will be observed at Aal2 access point (Aal2Ap) entity starting with g.
(Aal2Ap entities starting with b correspond to node b, starting with r corresponds for Iur links,
etc)

Possible solutions:
This issue will require support from the Operation and Maintenance department (OMC) in order to
determine the reasons for that high utilization over Iu-CS and Iu-PS links.
4.3.3 Failure after Admission: Hardware Usage (Channel Elements)
Lack of channel elements could be due to insufficient UL (RAX board) or DL (TX board) hardware
capacity. Channel element capacity could be also software limited. Admission control is restricted by
ulHwAdm and dlHwAdm parameters. They should be set at 100% so no hardware is limited for RRC/RAB
setup.
Possible indicators:
High number of AC block events on LackDlHw would indicate issues with TX board and LackUlHw
would indicate issues with RAX board.
Congestion at RAX or TX could be indicated by RBS counters pmUlCredits and pmDlCredits
respectively.
Congestion per spreading factor (SF) can be also measured using pmSetupFailureSfXX RBS counters
from the BasebandPool (BBP) on the uplink (UL BBP) and the downlink (DL BBP).
Possible solutions:
Check that ulHwAdm and dlHwAdm parameters are set to 100%
Check numHsResources, numEulResources at the node B (long term solution)
Reduce value of sf8Adm to 0 (short term solution)
Check for hardware failures on RAX and TXB boards and given the case, order its replacement.
Order an additional new RAX or TXB board, depending on the specific case.
4.3.4 Failure after Admission: Channelization Codes
This could also be a reason for Failures after Admission, but it is expected to be correlated with high
figures also in the counter for admission blocks due to lack of channelization codes
(pmNoFailedRabEstAttemptLackDlChnlCode).
Possible solutions:
Reduce the AC threshold for connections with low SF (specially 8 in DL, 4 in UL). Short Term Solution.
Real need for additional OVSF codes (purely due to increase in traffic) will require of new
carrier/sector/site analysis. [Refer to doc. Optimization Guidelines: Capacity in Ericsson
(DEO.OTM.IOP3041), for further details regarding the methodology to decide the best option
between New Carrier or New Sector or New Site].
4.3.5 Failure after Admission: Others
If a site shows none of the previously described issues, then it is likely to be a more complicated
problem to solve; often relating to a software/hardware fault, or perhaps an external source of
interference in the area.
Check for neighboring sites: Remember that neighboring sites having AAL2 congestion can cause other
cells to have high number of failures after admission (due to soft handover)
Check that software revisions are up to date at the Node B
Check for unexpected figures in counter pmNoInvalidRabEstablishAttempts.
RANAP RAB Assignment message is received for RABs to be setup/modified and the received QoS
parameters cannot be mapped to a supported RAB type or if the data in the message contains a
critical logical error.

4.4 Accessibility issues not detected by counters

Some kinds of RRC failures could not be detected by counters or other traces. This typically happens
when the RRC Connection Request messages from the UE cannot reach the RNC. In this case the
accessibility KPIs are not able to reveal the problem, but it could be reported by
users claims or
drive test activities or
variations of the traffic level.
Typical causes are:
4.4.1 HW Problems in the RBS
Antenna system failures
RAX boards failures
Cell unavailability
Most of the related problems should raise an alarm.
4.4.2 UL Interference
Strong UL Interference could also be the cause of some Accessibility issues not clearly detected by
counters described so far. It can be monitored by checking:
90th percentile of pmAverageRssi > -90 dBm or (pmSumUlRssi / pmSamplesUlRssi) > -95 dBm
4.4.3 RACH misconfiguration
Check RACH parameters to look for a wrong setting:
aichPower
powerOffsetP0
powerOffsetPpm
preambleRetransMax
maxPreambleCycle
constantValueCprach
maxTxPowerUl
4.4.4 Cell Unavailability
Check Cell unavailability through the following counters:
pmcellDownTimeAuto
pmCellDownTimeMan
4.4.5 Node Blocking
Counters: pmNoRabEstBlockNode<RAB>, where <RAB> = Speech, Cs64, Cs57, PsIntNonHs, PsIntHs,
PsStrHs
These counters are stepped when the establishment of a RAB fails due to node configuration error, node
limitation, or transport network layer service unavailability.
Additional detail can be obtained for the impact of Node blocking on RRC:
pmNoRrcConnReqBlockNodeCs
pmNoRrcConnReqBlockNodePs

5 REFERENCES
[1] WCDMA (UMTS) Deployment Handbook. Planning and Optimization Aspects. Christophe Chevallier,
Christopher Brunner, Andrea Garavaglia, Kevin P. Murray, Kenneth R. Baker (All of QUALCOMM
Incorporated California, USA). Ed. John Wiley & Sons. 2006
[2] Radio Network Planning and Optimisation for UMTS. Jaana Laiho and Achim Wacker [Both of Nokia
Networks, Nokia Group, Finland] & Toma s Novosad [Nokia Networks, Nokia Group, USA]. Ed. John
Wiley & Sons. 2006
[3] WCDMA Radio Access Network Optimization. LZT 123 8297 R1C. Ericsson 2006.
[4] Accessibility-Analysis and Monitor Rev4. Guidelines delivered by Ericsson Brazil to Claro in Nov.2009
[5] Introduction to UMTS Optimization. Wray Castle, 2004
[6] ALEX libreries, Ericsson Documentation. P7 & P7.1.
Radio Network Controller (RNC) 3810 (CXP 901 2011 RXX)
RXI 820 ATM R4.1 (CXP 901 102/3 RXX)
Radio Base Station (RBS) 3202/3206/3402/3412 (CXP 901 0811/X RXX)
WCDMA RAN (CXS 101 06/4 RXX)

6 ANNEX I: UE Idle Mode Procedures

PLMN selection is the first step in the registration process that allows a UE to initiate or receive services
from an operator. The UE normally operates on its Home PLMN. However, a Visited PLMN (VPLMN) may
be selected if the UE loses coverage.
A UE successfully registers on a PLMN if it finds a suitable cell to camp on within the selected PLMN.
The UE will then obtain a location or routing registration acknowledgement in the area of the cell on
which it is camped. The UE displays to the user that this PLMN is registered.
When a UE does not find a suitable cell in the selected PLMN, it tries to camp on any other acceptable
cell within an allowed PLMN.
When there is a suitable cell available normal services can be obtained in the cell. If there is an
acceptable cell available only emergency calls are available, and if in automatic mode, new PLMN
selection.

6.1 PLMN Selection and Reselection

PLMN selection is a NAS function, but the AS provides the list of available PLMNs from which the
selection is made.
AS reports all successfully read PLMN identities to the NAS, in 2 groups:
Those that meet the high quality criterion:
o RSCP CPICH >= -95 dBm, for FDD cells
o RSCP CPICH >= -84 dBm, for TDD cells
o RSSI CPICH >= -85 dBm, for GSM cells
Those that do not. These ones together with their measured CPICH RSCP value, so they can be
ranked.
The standard allows for the optimization of this measuring and reporting process through the use of
stored information in the UE regarding carrier frequencies and other cell parameters as scrambling
codes.
Once a suitable list of available PLMNs is compiled, it is up to the NAS to select a PLMN for registration.
This may be done automatically or manually. IN automatic mode the available PLMNs are listed in
priority order and the highest priority PLMN is selected. In manual mode a list of the available PLMNs is
presented to the user in priority order, but the user may select any PLMN from the list.
Prioritization for both modes is as follows:
1.

Home PLMN (HPLMN)

2.
3.
4.
5.

PLMNs in the User Controlled PLMN Selector with Access Technology data field in the SIM in
priority order.
PLMNs in the Operator Controlled PLMN Selector with Access Technology data field in the SIM in
priority order.
Other PLMNs that meet the high-quality criterion in random order.
Other PLMNs that do not meet the high-quality criterion in order of decreasing signal quality.

Once a PLMN is selected this is indicated to the AS along with the selected radio access technology.

6.2 Reading System Information

The System Information Block (SIB) messages are sent on BCCH logical channel, which can be mapped:
to the BCH for UEs in idle mode, Cell_PCH and URA_PCH
or the FACH transport channel for UEs in Cell_FACH.

To inform the UE if a change in System information has occurred, the MIB also delivers a value tag for
each SIB.
To inform UEs in idle mode, Cell_PCH and URA_PCH of a change in the system information, paging
(Paging type 1) is used to deliver the IE BCCH modification info to notify the new value tag for the
MIB. WCDMA RAN can also inform of the change in the system information with a System Information
Change Indication message on the FACH transport channel.

6.3 Cell Selection and Reselection

Refer to the Configuration Guideline: Idle Mode Settings for a more detailed description.

6.3.1 Cell Selection

Next figures summarize the process.

6.3.2 Cell Reselection

Next figure summarizes the process.

6.3.3 Location/Routing Area Update

LA and RA updating is necessary to inform the CN of the current LA or RA of the UE, so that the network
can send a paging message to the UE.
There are three types of LA and RA registration updates:
International Mobile Subscriber Identity (IMSI) attach or detach
Normal LA and RA updating
Periodic LA and RA updating (T3212, T3312)
A border RBS can handle less traffic than an RBS placed inside the LA, due to the increased signalling
load. Therefore, it is recommended that he LA/RA borders should be placed in areas with low traffic.

If the LAs/RAs are small, there will be more LAUs/RAUs in the system and a high number of border RBSs.
On the other hand, if the LAs/RAs are large the number of paging messages will increase.
If the same LAI/RAI is used for the GSM and WCDMA networks, the consequence is heavy paging load in
3G arising from the GSM subscribers.
RRC MODES and STATES
LA/RA UPDATE vs. CELL UPDATE vs. URA UPDATE

6.3.4 Paging Procedure

Paging Type 1 (to UE in idle mode or dormant state: Cell_PCH/URA_PCH)
UE terminating service request for PS or CS services (CN initiated).
UTRAN initiated broadcast to inform UEs when SI is modified.
Channel switch from state URA_PCH to CELL_FACH (UTRAN initiated)
Two different physical channels are used in order to exchange proper information between the WCDMA
RAN and the UE: the PICH and the S-CCPCH (carries the PCH). There is a fixed timing relation between a
PICH frame and the associated S-CCPCH frame.
Discontinuous Reception (DRX): The UE listens to the PICH only at certain predefined times, reducing
power consumption.
The paging record varies in length depending on whether it includes the UE identity in terms of IMSI,
TMSI, or P-TMSI. A PCH frame can carry one Paging Type 1 message of 10 ms and may contain
between 3-5 paging records, depending on whether the paging uses IMSI or TMSI/P-TMSI.
Paging Type 2 (to UE in Cell_DCH or Cell_FACH)
UE terminating service request for PS or CS services (CN initiated).
When a connection exists between the WCDMA RAN and the UE, the SRNC determines that a RRC
connection has already been established by this UE and the RRC message "Paging type 2" is used to
carry paging information. Since it is sent on a dedicated control channel, this message is intended only
for one particular UE.
For paging, the capacities of the FACH and the RACH are assumed to be enough, but there is a risk of
congestion in the PCH due to heavy paging load. Therefore, the probability of congestion in the PCH
must be calculated in order to dimension the LA/RA.

7 ANNEX II: Call Establishment Procedure

7.1 Voice Call Establishment

7.2 PS Data Call Establishment

7.3 Radio Resource Control (RRC)

RRC is the overall controller of the Access Stratum, responsible for configuring all other layers in the
Access Stratum and providing the control and signalling interface to the NAS layer.
Broadcast of System Information
RRC Connection Management
Radio Bearer Management
RRC Mobility Functions
Paging and Notification Functions
Routing of Higher Layer Messages
Control of Ciphering and Integrity Protection
Measurement Control and Reporting

Power Control Functions

RRC manages radio resources, including allocation, deallocation, and configuration of Logical, Transport,
and Physical Channels, measurement reporting, security procedures, and overall management of the
Access Stratum.
7.3.1 RRC connection Request & Setup
The RRC Connection Setup establishes SRBs (Signalling Radio Bearers) to carry dedicated signalling.
This phase of the call establishment is identical for CS and PS calls (both MO and MT) and it is always
composed by next three messages:
1.
2.
3.

RRC Connection Request (RACH, in UL)

RRC Connection Setup (FACH, in DL)
RRC Connection Setup Complete (DCH, in UL)

It is important to note that this signalling is also needed when the UE performs Periodic Registration/
LAU/RAU/Detach as part of the Mobility Management. In these cases, the purpose of the RRC connection
setup is not to establish a call (CS or PS), and therefore, there will not be RAB setup phase.
The RRC connection request contains the UE identity, optional cell measurement results, and the
establishment cause.

For speech AMR service, this cause is recorded as either Originating Conversational Call or
Terminating Conversational Call. For PS service, this cause is recorded as Originating/Terminating
Interactive/Background Call.
Successfully establishing the RRC connection is the most challenging part of call setup. This can be
attributed to two factors: the admission control implementation and the size of the RRC Connection
Setup message. The latter is the main challenge. During admission control implementation, an RRC
connection reject is sent if no resources are available for allocation, or if the call should be redirected to
a different system or carrier.

After successful resource allocation, the RRC Connection Setup messagewhich contains SRB
information including the mapping details of dedicated logical, transport, and physical channelsis sent
on the Forward Access Channel (FACH) (over [Downlink Secondary Common Control Physical Channel]
[DL SCCPCH]). This RRC Connection Setup message contains a significant amount of information, and it
spans multiple frames while not yet operating in closed loop power-controlled condition. This makes it
difficult for the UE to receive the message, especially if the SCCPCH power allocation is not set to
accommodate low geometry.
After the RRC Connection Setup message is received, the UE can set up the low data rate DCH according
to the RRC Connection Setup message. First, only the PDCCH containing Transmit Power Control (TPC)
and Pilot bits are sent to allow the inner loop power control to converge. Afterwards, the RRC Connection
Setup Complete message is used to acknowledge the setup message and send UE-capability
information to the network. At this point, the UE should have transitioned from Idle state to CELL DCH
state. At this time, the connection is power-controlled and may support handover, depending on the
Universal Terrestrial Radio Access Network (UTRAN) implementation. Both features improve the
reliability of the connection.

7.4 Core Network Negotiation

The low data rate DCH facilitates upper layer signaling with the NAS layer, which performs all
authentication and security procedures along with additional processes in the CN to establish the endto-end connection.
To initiate the connection request to the upper layers, MO calls use the Connection Management (CM)
Service Request and MT calls use the paging response. In the CM Service Request message, the CM
Service Type field indicates Mobile originating call establishment as the cause for a MO AMR call. The
Paging Response message does not need to carry service information because the NAS layer already
knows what service is being set up for the MT call.
To perform two-way authentication, the UE checks the Authentication Token (AUTN) nd the network
checks the Signed Authentication Response (SRES), which is calculated from the RAND number from the
network. Depending on the supported security capabilities, ciphering and integrity protection are
switched on to enable encryption of user data
and signaling messages.
For MO calls, the UE sends main parameters such as bearer capabilities and dialed digits to the network
using the Call Control (CC) Setup message. For MT calls, the network uses the Setup message to send
the same, or similar, information to the UE. The next step is similar; MO calls use Call Proceeding
messages (UTRAN to UE), while MT calls use Call Confirmed messages (UE to UTRAN) as a Layer 3
acknowledgment.

7.5 Radio Access Bearer (RAB) Setup and Reconfiguration

After the CN negotiation, the UE can establish the DCH(s) for the requested service. Existing DCHs also
may be reconfigured to meet the requirements, depending on the current configuration. Before sending
the RB Setup message, call admission control must be checked and resource allocation performed for
every resource involved in a call.
For AMR voice, the UE typically sets up three dedicated logical/transport channels mapped onto one
CCTrCh. Information in the RB Setup message is similar to the RRC Connection Setup:

NAS Layer 2. Radio Bearer/logical/transport channel mapping

Layer 2. Channel coding, Radio Link Control (RLC) parameters, TTI, BLER targets,
Transport Format Combination Set (TFCS)

Layer 1. Spreading Factor (SF), OVSF code, Scrambling Code, frame offset, power control
parameters
At this point, the radio link is completely established; however, the end-to-end connection is not yet
fully established:

The Alerting message is sent from the network to the UE for MO calls, or from the UE to
the network for MT calls.

The directions for Connect and Connect ACKnowledge (ACK) are reversed, depending on
the call type.

The Connect message is sent by the UTRAN for MO calls, but by the UE for MT calls.
The RB Setup message can also be used as a reconfiguration message because the existing SRBs are,
from this point forward, multiplexed with RAB onto a single physical dedicated channel.