optimization guidelines accessibility-ericsson-rev01

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 (%) ......................................................................................................................................... 5

3.1.1.3 CS CSSR (%) –from P7.1- .................................................................................................................... 6

3.1.1.4 PS CSSR (%) – from P7.1- .................................................................................................................... 6

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 (%) ................................................................................................. 8

3.2.1.2 RRC Connection Success Rate PS (%) ................................................................................................. 8

3.2.2 Iu Signalling Establishment Success Rate (%) .................................................................................................... 8

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- ........................................................................... 9

3.2.3.1 NAS CS Signalling Establishment Success Rate (%) – from P7.1- ...................................................... 9

3.2.3.2 NAS PS Signalling Establishment Success Rate (%) – from P7.1- ...................................................... 9

3.2.4 (RAB) Establishment Success Rate (%) .............................................................................................................. 9

3.2.5 Sending Paging Failure Rate (%) ...................................................................................................................... 10

3.2.6 Blocking Probability .......................................................................................................................................... 10

3.2.6.1 GoS Speech (%) ................................................................................................................................... 10

3.2.6.2 GoS PS (%) .......................................................................................................................................... 10

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

4 PERFORMANCE ANALYSIS ....................................................................................................... 12

4.1 Admission Control ................................................................................................................................. 12 4.1.1 Admission Policy ............................................................................................................................................... 12

4.1.2 Resources to be monitored ................................................................................................................................ 13

4.1.2.1 RF Power ............................................................................................................................................. 13

4.1.2.2 Code Tree Consumption ...................................................................................................................... 13

4.1.2.3 DL and UL ASE .................................................................................................................................. 13

4.1.2.4 SF Code Limit (Code Hystogram) ....................................................................................................... 13

4.1.2.5 HSDPA and EUL connections Limit ................................................................................................... 13

4.1.2.6 UL and DL Channel Elements ............................................................................................................. 13

4.1.3 RRC Admission Blocks ..................................................................................................................................... 13

4.1.4 RAB Admission Blocks .................................................................................................................................... 14

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

4.3 After Admission ..................................................................................................................................... 14 4.3.1 Failure after Admission: Iub Congestion ......................................................................................................... 15

4.3.1.1 Low RRC Success Rate ....................................................................................................................... 15

4.3.1.2 Low RAB Success Rate ....................................................................................................................... 15

4.3.2 Failure after Admission: Core Transport Network Congestion ....................................................................... 15

4.3.3 Failure after Admission: Hardware Usage (Channel Elements) ...................................................................... 16

4.3.4 Failure after Admission: Channelization Codes ............................................................................................... 16

4.3.5 Failure after Admission: Others ....................................................................................................................... 16

4.4 Accessibility issues not detected by counters ....................................................................................... 17 4.4.1 HW Problems in the RBS .................................................................................................................................. 17

4.4.2 UL Interference ................................................................................................................................................. 17

4.4.3 RACH misconfiguration .................................................................................................................................... 17

4.4.4 Cell Unavailability ............................................................................................................................................. 17

4.4.5 Node Blocking ................................................................................................................................................... 17

5 REFERENCES ............................................................................................................................... 18

6 ANNEX I: UE Idle Mode Procedures ............................................................................................ 19

6.1 PLMN Selection and Reselection .......................................................................................................... 19

6.2 Reading System Information ................................................................................................................ 20

6.3 Cell Selection and Reselection ............................................................................................................... 21 6.3.1 Cell Selection ..................................................................................................................................................... 21

6.3.2 Cell Reselection ................................................................................................................................................. 21

6.3.3 Location/Routing Area Update .......................................................................................................................... 22

6.3.4 Paging Procedure ............................................................................................................................................... 23

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

7.1 Voice Call Establishment ...................................................................................................................... 24

7.2 PS Data Call Establishment ................................................................................................................. 24

7.3 Radio Resource Control (RRC) ........................................................................................................... 24 7.3.1 RRC connection Request & Setup .................................................................................................................... 25

7.4 Core Network Negotiation .................................................................................................................... 27

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

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

Revision Date Author ChangesDraft 01 13-Nov-2009 QCES/Ericsson First Release of the document

01 12-Mar-2010 QCES/Ericsson

Update from P7 to P7.1:

• NAS signalling phase counters added, both to CSSR

KPIs and Medium Level KPIs

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)

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)

where (RAB) = PacketStream, PacketStream128, PacketInteractive

∑

∑

(RAB)

mpt(RAB)ablishAttepmNoRabEst

(RAB)

ess(RAB)ablishSuccpmNoRabEst

*nnPs)aringRrcCopmNoLoadSh-qPscConnectRe(pmTotNoRr

PsSuccConnectReqpmTotNoRrc * 100

ryAttpmNoDirRet -

(RAB)

mpt(RAB)]ablishAttepmNoRabEst

(RAB)


*nnCs)aringRrcCopmNoLoadSh-qCscConnectRe(pmTotNoRr

CsSuccConnectReqpmTotNoRrc * 100

∑

∑

[

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.1-

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.1-

(RAB)

atHoAttpmNoInCsIrmpt(RAB)]ablishAttepmNoRabEst[

satHoSuccespmNoInCsIrrySuccesspmNoDirRet]

(RAB)

ess(RAB)ablishSuccpmNoRabEst[

*CsSuccConnectReqpmTotNoRrc

easeCsNasSignRelpmNoSystem1

*temptCsstablishAtpmNoIuSigE

ccessCsstablishSupmNoIuSigE*

nnCs)aringRrcCopmNoLoadSh-qCscConnectRe(pmTotNoRr


∑ +

++∑

−

(RAB)


(RAB)


*PsSuccConnectReqpmTotNoRrc

easePsNasSignRelpmNoSystem1*

temptPsstablishAtpmNoIuSigE

ccessPsstablishSupmNoIuSigE

*rIratCcOrdeConnectAttpmTotNoRrcselIratCellReConnectAttpmTotNoRrcnnPs)aringRrcCopmNoLoadSh-qPscConnectRe(pmTotNoRr

OrdercessIratCcConnectSucpmTotNoRrcllReselcessIratCeConnectSucpmTotNoRrc PsSuccConnectReqpmTotNoRrc * 100

∑

∑

−

++

++

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.

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:

[ ]

+

nteractivemptPacketIablishAttepmNoRabEst + mptCs64ablishAttepmNoRabEst

+mpt lishEcAttepmRabEstab + mptSpeechablishAttepmNoRabEst

nteractivemptPacketIablishAttepmNoRabEst *nteractivemptPacketIablishAttepmNoRabEst

nteractiveessPacketIablishSuccpmNoRabEst*

PsConnectReqpmTotNoRrc

PsSuccConnectReqpmTotNoRrc

mptCs64ablishAttepmNoRabEst +

mpt lishEcAttepmRabEstab +

mptSpeechablishAttepmNoRabEst

*

mptCs64ablishAttepmNoRabEst +

mpt lishEcAttepmRabEstab +


essCs64ablishSuccpmNoRabEst +

esslishEcSuccpmRabEstab +

essSpeechablishSuccpmNoRabEst

*CsConnectReqpmTotNoRrc

CsSuccConnectReqpmTotNoRrc

* 100

[ ]

+

nteractivemptPacketIablishAttepmNoRabEst + mptCs64ablishAttepmNoRabEst

+mpt lishEcAttepmRabEstab + mptSpeechablishAttepmNoRabEst

nteractiveessPacketIablishSuccpmNoRabEst *PsConnectReqpmTotNoRrc


essCs64ablishSuccpmNoRabEst +

esslishEcSuccpmRabEstab +

essSpeechablishSuccpmNoRabEst



* 100

3.2 Medium Level KPIs

3.2.1 RRC Connection Success Rate (%)(For all connection requests)

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 estímate 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)

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)

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)

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).

nn)rningRrcCopmNoOfRetu-onnharingRrcC(pmNoLoadS - ConnectReqpmTotNoRrc

SuccessConnectReqpmTotNoRrc * 100

nnCsaringRrcCopmNoLoadSh - CsConnectReqpmTotNoRrc


nnPsaringRrcCopmNoLoadSh - PsConnectReqpmTotNoRrc

PsSuccConnectReqpmTotNoRrc * 100

+

+

temptPsstablishAtpmNoIuSigE temptCsstablishAtpmNoIuSigE

ccessPsstablishSupmNoIuSigE ccessCsstablishSupmNoIuSigE * 100

3.2.2.1 Iu-CS Signalling Establishment Success Rate (%) (For CS connection requests)

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)

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)

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)

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)

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 (%)

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 HO’s that fail.

temptCsstablishAtpmNoIuSigE

ccessCsstablishSupmNoIuSigE * 100

temptPsstablishAtpmNoIuSigE

ccessPsstablishSupmNoIuSigE * 100


ess(RAB)ablishSuccpmNoRabEst * 100

PsSuccConnectReqpmTotNoRrcCsSuccConnectReqpmTotNoRrc

easePsNasSignRelpmNoSystemeaseCsNasSignRelpmNoSystem1* 100

+

+−


easeCsNasSignRelpmNoSystem1* 100

−


easePsNasSignRelpmNoSystem1* 100

−

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 (%)

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:

[Pending Confirmation from Ericsson]

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.

3.2.6.1 GoS Speech (%) [Check this at cell level].

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):

3.2.6.2 GoS PS (%) [Check this at cell level].

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):

+++

+

adCscardCmpLopmNoPageDi UeLagingToIdlepmCnInitPa UeRagingToIdlepmCnInitPa UegingToIdlepmCnInitPa

anRejectedAttemptUtrpmNoPaging adCscardCmpLopmNoPageDi * 100

( )

adCscardCmpLopmNoPageDiraUetPagingToUpmUtranIni egingToUraUpmCnInitPa

UeLagingToIdlepmCnInitPa UeRagingToIdlepmCnInitPa UegingToIdlepmCnInitPa

anRejectedAttemptUtrpmNoPaging adCscardCmpLopmNoPageDi* 100

++

+++

+


SpeechoReqDeniedpmNoOfNonH

CsConnectReqpmTotNoRrc

meqDeniedAdpmNoRrcCsR-1* 100

−− 1*1

nteractivemptPacketIablishAttepmNoRabEst

eInteractivoReqDeniedpmNoOfNonH

PsConnectReqpmTotNoRrc

meqDeniedAdpmNoRrcPsR-1* 100

−− 1*1


echBestBlockTnSpepmNoRabEstSpeechoReqDeniedpmNoOfNonH1


nCsnReqBlockTpmNoRrcConmeqDeniedAdpmNoRrcCsR1

-1* 100

+−

+−

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).

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.

ConnectReqpmTotNoRrc

AfterAdmpmNoFailed * 100


ntHsBestBlockTnPsIpmNoRabEsttntNonHsBesBlockTnPsIpmNoRabEsteInteractivoReqDeniedpmNoOfNonH1

*PsConnectReqpmTotNoRrc

nPsnReqBlockTpmNoRrcCon meqDeniedAdpmNoRrcPsR1

-1* 100

++−

+−

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 HS-DSCH/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 / pmTotNoRrcConnectReqCs, then check: pmNoRrcCsReqDeniedAdm

If low pmTotNoRrcConnectPsReqSucc / pmTotNoRrcConnectReqPs, then check: pmNoRrcPsReqDeniedAdm

4.1.4 RAB Admission Blocks

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


SpeechoReqDeniedpmNoOfNonH*100

mptCs57)ablishAttepmNoRabEst emptCs64tablishAtt(pmNoRabEs

CsoReqDeniedpmNoOfNonH*100

+


eInteractivoReqDeniedpmNoOfNonH*100

treammptPacketSablishAttepmNoRabEst

gPsStreaminoReqDeniedpmNoOfNonH*100

HsnteractivemptPacketIablishAttepmNoRabEst

HsoReqDeniedpmNoOfNonH*100

EulnteractivemptPacketIablishAttepmNoRabEst

EuloReqDeniedpmNoOfNonH*100

tream128mptPacketSablishAttepmNoRabEst

PsStr128oReqDeniedpmNoOfNonH*100

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:

• Videocall:

• PS R99:

• HSDPA:

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.


echBestBlockTnSpepmNoRabEst *100

Hs)nteractivemptPacketIablishAttepmNoRabEst - eInteractivemptPackettablishAtt(pmNoRabEs

t ntNonHsBesBlockTnPsIpmNoRabEst*100

HsnteractivemptPacketIablishAttepmNoRabEst

ntHsBestBlockTnPsIpmNoRabEst*100

mptCs64ablishAttepmNoRabEst

4BestBlockTnCs6pmNoRabEst *100

• 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

• user’s 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:

pmNoRrcConnReqBlockNodeCspmNoRrcConnReqBlockNodePs

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. PLMNs in the “User Controlled PLMN Selector with Access Technology” data field in the SIM in priority order.3. PLMNs in the “Operator Controlled PLMN Selector with Access Technology” data field in the SIM in priority order.

4. Other PLMNs that meet the high-quality criterion in random order.5. 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 STATESLA/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. RRC Connection Request (RACH, in UL)2. RRC Connection Setup (FACH, in DL)3. 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.

3GPP TS 25.331 V8.3.1

Radio Resource Control (RRC); Protocol Specification (Release 8)

Section. 10.3.3.11. ESTABLISHMENT CAUSE

Originating Conversational Call,

Originating Streaming Call,

Originating Interactive Call,

Originating Background Call,

Originating Subscribed traffic Call,

Terminating Conversational Call,

Terminating Streaming Call,

Terminating Interactive Call,

Terminating Background Call,

Emergency Call,

Inter-RAT cell re-selection,

Inter-RAT cell change order,

Registration,

Detach,

Originating High Priority Signalling,

Originating Low Priority Signalling,

Call re-establishment,

Terminating High Priority Signalling,

Terminating Low Priority Signalling,

Terminating – cause unknown,

MBMS reception,

MBMS ptp RB request

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 message–which contains SRB information including the mapping details of dedicated logical, transport, and physical channels–is 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 end-to-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 dataand 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.