HW 3G Optimisation Guidelines Network Performance Analysis

3G Optimization Guidelines Mian Rizwan

2010-01-31 Mian Rizwan Page 1 of 28

1 Key Observation Point

and Analysis Examples of

Typical Problems

An observation point is a PI which reflects a specific performance problem. The

analysis based on an observation point is a process that goes deeper based on the

familiarization of the UTRAN PI. Observation point analysis associates signaling

process with performance index. Observation points are categorized as follows:

1) RRC establishment analysis observation point

2) RAB establishment analysis observation point

3) Soft handover analysis observation point

4) Call drop analysis observation point

5) CS/PS intersystem handover analysis observation point

6) Traffic analysis observation point

7) Key interface process analysis observation point

8) HSDPA analysis observation point

An in-depth performance analysis can be made only after you have gained a mastery

of observation points. The Nastar tool provides special topic query of most observation

points. We may also make special topic query of other observation points by means of

customization. Special topic drilling analysis of basic observation point helps deepen

the understanding of signaling processes and various PIs and strengthen the mastery

of the Nastar tool.



Figure 1 Special topic analysis

1.1 Observation Points of Typical Problems

1.1.1 RRC Establishment Analysis Observation Point

Table 1 RRC Establishment Observation Point

Observation

Point Condition

Possible

Cause Analysis Idea

Categories of Observe various If there are many streaming class called



Observation

Point Condition

Possible

Cause Analysis Idea

RRC

establishment

requests

types of RRC

connection

establishment

requests and

their proportional

distribution. If any

abnormality, we

need to give an

early warning.

service requests (accounting for over 10%

of total connection establishment

requests), we need to pay much attention

to them. This is because when UE changes

from DCH status into IDLE status, PS

needs to transmit packets, then ps paging

occurs and the corresponding RRC

requests are streaming class called service

requests. If there are too many requests of

this type, it is possible that the timer from

DCH status to IDLE status is not properly

set.

RRC

establishment

failure

Number of RRC

connection

establishment

failures (>=5);

RRC connection

establishment

failure rate

(>=10%)

AAL2

establishment

failure

It is generally caused by insufficient

transmission resource or transmission

fault. You may query the cell downlink

throughput at the moment from associated

traffic statistics indexes. If it is lower than

200 kbps, transmission fault may occur.

RL

establishment

failure

It may be caused by NodeB fault or

insufficient NodeB resource. You may

query the maximum downlink CE of a cell

from associated traffic statistics index. If

the maximum uplink CE is less than 20,

then traffic is not high and the problem lies

in abnormal NodeB equipment.

Power

congestion

RRM admission decision cannot establish

any new RRC connection due to too high

radio load within a cell. In this case, you

need to query the maximum RTWP and the

maximum TCP of the cell to confirm uplink

congestion or downlink congestion and

judge whether any expansion is necessary.

Meanwhile, we should check whether

related admission strategy settings, such

as DCCC, are proper.

Uplink CE

congestion

Uplink CE resource admission congestion

within an RNC. You need to query the

number of uplink CEs of a cell from

relevant parameters and judge whether to



Observation

Point Condition

Possible

Cause Analysis Idea

expand CE. If the number of uplink CEs is

less than 20, then traffic is not high and the

problem may lie in abnormal NodeB

equipment.

At present, RNC does not make an

accurate estimate of CE resource. It is

quite possible that RNC judges CE to be

sufficient, but actual NodeB CE resource is

insufficient. In addition, inconsistent

capability of RNC and NodeB may also

lead to NodeB RL establishment failure.

Downlink CE

congestion

Downlink CE resource admission

congestion within an RNC. You need to

query the number of downlink CEs of a cell

from relevant parameters and judge

whether to expand CE. If the number of

uplink CEs is less than 40, traffic is not high

and the problem may lie in abnormal

NodeB equipment.








Code

congestion

Code resource fails to be allocated during

RRC connection establishment. Code

congestion is generally caused by too

many network users. It may be seen in high

traffic scenarios with microcell coverage.

You may query the effective utilization of

codes from associated traffic statistics

indexes. If the effective utilization of codes

is lower than 30%, it is possible that the

code distribution algorithm is abnormal.

Other

congestion

leads to RRC

Generally the congestion caused by

unknown insufficient resources. For

example, license resource and high CPU



Observation

Point Condition

Possible

Cause Analysis Idea

rejection. utilization make flow control and FMR

processing capacity insufficient. In addition,

E1 fault also appears. This cause value is

dotted.

Transmission

congestion

Transmission congestion is mainly caused

by insufficient transmission resource. You

may query the downlink cell throughput

from associated traffic statistics indexes. If

the downlink cell throughput is lower than

200 kbps, it is possible that there is

abnormal equipment. The power-down of a

base station once led to transmission

interruption, but the cause in traffic

statistics is transmission congestion.

Other factors

lead to RRC

rejection.

Abnormal causes. We need to make

in-depth location based on RNC logs. The

known problem is that the system

redirection function of the network is

enabled. During redirection, a mobile

phone does not support GSM and thus

failure rejection occurs.

No response

from UE

This is generally caused by poor coverage.

The downlink FACH and RACH have

unbalanced coverage.

Other factors

lead to RRC

establishment

failure.

This is generally caused by an RNC fault.

At present, there is a problem with traffic

statistics mode, which may lead to some

wrong dotting of this cause.

There was a problem with the designated

access DSP of node B. The RRC

CONNECTION SETUP REQUEST

message fails to be sent to RNC. The

RACH packet decoding of this cell fails. We

may make a judgment by checking whether

the index

VS.MAC.CRNCIubBytesRACH.Tx is

abnormal.



1.1.2 RAB Establishment Analysis Observation Point

Table 2 RAB establishment observation point

Observation

Point Condition

Possible

Cause Analysis Idea

CS/PS RAB

establishment

failure

Number of

CS/PS RAB

establishment

failures (>=5);

CS/PS RAB

establishment

failure rate

(>=10%)

Transmission

network

Generally transmission equipment fault or

insufficient transmission capacity. You

need to query the transmission utilization of

that time.

Migration

In starting migration, RNC receives a RAB

establishment request, but does not

process it. This is mainly caused by flow

nesting and seldom occurs. It is related to

user behavior sequence. This is generally

avoided in a core network.

Power

congestion

RRM admission decision cannot establish

any new RRC connection due to too high

radio load within a cell. In this case, you

need to query the maximum RTWP and the

maximum TCP of the cell to make sure of

uplink congestion or downlink congestion

and judge whether any expansion is

necessary. Meanwhile, we should check

whether related admission strategy

settings, such as DCCC, are proper.

Uplink CE

congestion

Uplink CE resource admission congestion

within an RNC. You need to query the

number of uplink CEs of a cell from

relevant parameters and judge whether to

expand CE. If the number of uplink CEs is

less than 20, then traffic is not high and the

problem may lie in abnormal NodeB

equipment.










Observation

Point Condition

Possible

Cause Analysis Idea

Downlink CE

congestion

Downlink CE resource admission

congestion within an RNC. You need to

query the number of downlink CEs of a cell

from relevant parameters and judge

whether to expand CE. If the number of

uplink CEs is less than 40, then traffic is not

high and the problem may lie in abnormal

NodeB equipment.








Code

congestion

Code resource fails to be allocated during

RRC connection establishment. Code

congestion is generally caused by too

many network users. It may be seen in high

traffic scenarios with microcell coverage.

You may query the effective utilization of

codes from associated traffic statistics

indexes. If the effective utilization of codes

is lower than 30%, it is possible that the

code distribution algorithm is abnormal.

Transmission

congestion

Transmission congestion is mainly caused

by insufficient transmission resource. You

may query the downlink cell throughput

from associated traffic statistics indexes. If

the downlink cell throughput is lower than

200 kbps, it is possible that there is

abnormal equipment. The power failure of

a base station once led to transmission

interruption, but the cause in traffic

statistics is transmission congestion.

Others Abnormal causes. We need to make an

in-depth location based on RNC logs.

Air interface The air interface failure occurring during



Observation

Point Condition

Possible

Cause Analysis Idea

failure RB establishment is generally caused by

poor coverage or mobile phone

compatibility.

Configuration

not supported

The compatibility of a mobile phone itself

becomes faulty in some unknown

scenarios. For example, when a Huawei

mobile phone drops network abnormally, it

may not release any RB. When PS RB is

set up next time, this case may occur. This

case also happens to the SE V800 mobile

phone.

Physical

channel failure

This generally occurs when FACH migrates

to DCH and sets up RB. The downlink

physical layer of a terminal is not

synchronized, which leads to RB

establishment failure. This is mainly caused

by poor coverage.

Cell update

The Cell Update flow occurs during RB

establishment. This nested flow leads to

RB establishment failure.

Illegal

configuration

UE considers parameter configuration

illegal. Network and terminals have an

inconsistent understanding of parameter

processing. If RB establishment failure

occurs in the domain of CS, it is possible

that a user dials a wrong telephone number

and at once goes onhook. RB SETUP

failure may also occur at this time. The

cause is illegal configuration.

No response

from UE

Generally poor coverage makes UE unable

to receive any RB establishment command.

Parameter error

RNC considers the parameter delivered by

a core network invalid. You need further

cell signaling tracing to determine the

cause. Among the known causes is that the

uplink subscription and activation

application information of user PS service

exceeds the capacity of a mobile phone, or



Observation

Point Condition

Possible

Cause Analysis Idea

that the network negotiation rate in PDP

activation acceptance messages is less

than the minimum guaranteed rate.

1.1.3 Call Drop Analysis Observation Point

Table 3 CS/PS call drop observation point

Observation

Point Condition

Possible

Cause Analysis Idea

CS/PS call

drop

High CS/PS call

drop rate

OM intervention

Call drop caused by operation and

maintenance. For example, the execution

of TRG RABRel on LMT causes users to

be released.

RAB

preemption

High-priority users preempt low-priority

users when admission is rejected. This

causes a link to be released. This kind of

call drop occurs in the case of load and

insufficient resource. Determine whether

expansion is necessary according to the

number of occurrences.

UTRAN

Within a cell, UTRAN leads to abnormal

link release. This case generally

corresponds to processing abnormality. We

need to make a further analysis by means

of CDL.

Uplink/downlink

RLC reset

Uplink or downlink signaling RB reaches

the maximum retransmission times and

resets. This causes a link to be released.

This case is mainly caused by poor

coverage quality (including missing

configuration of adjacent cells and small

handover area).

Uplink

synchronization

failure

RNC receives RL Failure reported by

NodeB, which causes a link to be

abnormally released. In this case, poor

coverage quality (including missing



Observation

Point Condition

Possible

Cause Analysis Idea

configuration of adjacent cells and small

handover area) makes UE abnormally shut

down the transmitter, or uplink

demodulation out-of-sync.

Downlink

synchronization

failure

Receive the Cell Update message reported

by a mobile phone. The cause is downlink

RL Failure, which makes a link abnormally

released. In this case, poor coverage

quality (including missing configuration of

adjacent cells and small handover area)

makes UE abnormally shut down the

transmitter, or uplink demodulation

out-of-sync.

The UU

interface makes

no response.

RNC delivers a message and waits for the

response from a mobile phone, but timeout

occurs. For example, waiting for RB

reconfiguration completion message times

out and waiting for active set update

completion times out. This case is

generally caused by poor coverage.

Other RF

causes RF cause; due to poor coverage quality

Abnormal AAL2

link

RNC finds that the AAL2 Path of the IU CS

interface is abnormal and starts abnormal

release. It is possible that the transmission

equipment of the Iu interface is abnormal.

The known problem is that immediate

normal release during RB establishment is

classified by traffic statistics into abnormal

release.

Abnormal

GTPU

RNC finds that the GTPU of the IU PS

interface is abnormal and starts abnormal

release. The cause may be equipment fault

or defect.

Others

Possibly the call drop (but traffic statistics

does not dot) occurring during flow

interaction or cell update, or abnormal call



Observation

Point Condition

Possible

Cause Analysis Idea

drop and cell blocking caused by the

transmission fault of the Iub interface, RNC

internal cause, and Bug. There may be call

drop for abnormal causes. We need to

make an analysis based on RNC logs. The

call drop caused by violent change (corner

effect or driving out from the shadow area

of a building) of uplink signal is known to be

classified into this cause.

1.1.4 Soft Handover Analysis Observation Point

Table 4 Soft handover analysis observation point

Observation

Point Condition

Possible

Cause Analysis Idea

Soft

handover

rate

Soft handover

rate based on

cell resource

allocation and

soft handover

rate based on

IUB transmission

resource

allocation.

Possible causes of too high (>= 40%) a

soft handover rate:

1) Handover parameter setting makes

addition easy, but deletion difficult.

2) In the early days of network

construction, there are few base

stations and insufficient coverage.

Therefore, capacity gives way to

quality.

3) The CN side of some partners does

not deliver Iu release. After a user’s

dial-up access is disconnected, there

is only user plane release instead of

signaling plane release. Users have

soft handover even after a network is

disconnected.

Soft

handover

execution

failure

Number of

soft/softer

handover failures

(>=5) and

soft/softer

handover failure

Configuration

not supported

UE considers that the content of the active

set update of RNC adding/deleting a link is

not supported. Generally, this scenario will

not appear in commercial use.

Synchronization

reconfiguration

UE gives the feedback that the softer/soft

handover process of RNC adding/deleting



Observation

Point Condition

Possible

Cause Analysis Idea

rate (>=10%) not supported a link is incompatible with other concurrent

processes. RNC has guaranteed serial

flow processing. Soft handover execution

failure is mainly caused by the problematic

processing of some mobile phones.

Illegal

configuration

UE considers that the content of the active

set update of RNC adding/deleting a link is

illegal. Generally, this scenario will not

appear in commercial use..

No response

from UE

RNC does not receive the active set

update command response for

adding/deleting a link. This is the main

cause of softer/soft handover failure. This

happens in the region with poor coverage

or a small handover area. It needs RF

optimization.

1.1.5 CS/PS Intersystem Handover Analysis Observation Point

Table 5 Intersystem handover observation point

Observation

Point Condition Possible Cause Analysis Idea

Hard

handover

preparation

failure

Preparation

failures (>=5) of

hard handover

into this cell and

preparation

failure rate

(>=10%) of hard

handover into

this cell

Radio link establishment failure occurs

during RL establishment. For details, see

the RL establishment process analysis of

the IUB interface.

For other causes, we need to make a

further analysis based on RNC logs.

Preparation

failure of

transition out

of cell

accompanied

Preparation

failures (>=5) of

transition out of

cell accompanied

by hard handover

A target cell has

no wireless

network

resource

available.

A target cell has no resource available, or

there is some RNC parameter

configuration error. We need to make an

analysis based on RNC logs.



Observation


by hard

handover

and preparation

failure rate

(>=10%) of

transition out of

cell accompanied

by hard handover

Transition

timeout of target

system

The problem often lies in CN parameter

configuration or a related link connection.

We need to make an analysis based on

RNC logs.

Transition failure

in the target

CN/RNC or

system

It generally corresponds to core network

configuration error.

Transition in the

target CN/RNC

or system not

supported

Generally, RNC does not support some

hard handover parameters. We need to

make an analysis based on RNC logs.

Transition

objective not

allowed

Often an MSC parameter configuration

error. We need to check the parameter

configuration of a core network.

OM intervention Failure caused by operation and

maintenance

No available

resource

Often an MSC parameter is configured

incorrectly, or a target RNC has no

resource available.

Undefined Failure causes are not defined in traffic

statistics.

Others We need to make an analysis based on

RNC logs.

Preparation

failure of

RNC-level

foreign

outgoing

handover

Preparation

failures (>=5) of

RNC-level

CS/PS domain

intersystem

outgoing

handover,

preparation

Waiting for

transition

command

timeout

A core network does not return a

corresponding command of handover

preparation request. In this case, there is

some problem with the parameter

configuration or related link connection of

a core network. We need to analyze the

cause according to the signaling trace of

the core network and BSS.



Observation


failure rate

(>=10%)of CS

domain

intersystem

outgoing

handover Transition

cancelled

Upon requesting handover preparation,

RNC receives the release command from

a core network. Two cases: intersystem

handover request occurs during signaling

process like location update. The location

update flow has been finished before one

flow is finished. The core network starts

release; the user who sets up a call goes

onhook during handover preparation, and

the core network starts release. No

handover is finished in either case, but

either is normal flow nesting.

Transition

timeout


configuration error. We need to analyze

the cause according to the signaling

tracing of a core network and a BSS.

Transition failure

in the target

CN/RNC or

system

The problem often lies in the parameter



cause according to the signaling tracing of

a core network and a BSS.

Unknown target

RNC

The problem often lies in an MSC

parameter configuration error. That is, the

LAC of the target cell fails to be

configured. We need to check the

parameter configuration of a core network.

This case is often seen after the

adjustment of 2 G network.

No available

resource

The problem often lies in an MSC

parameter configuration error, or BSC has

no resource available. We need to analyze

the cause according to the signaling

tracing of a core network and a BSS.

Others

We need to analyze the cause according

to the signaling tracing of a core network

and a BSS.



Observation


Preparation

failure of

Cell-level

foreign

outgoing

handover

Preparation

failures (>=5) of

CELL-level CS

domain

intersystem

outgoing

handover and

preparation

failure rate

(>=10%) of CS

domain

intersystem

outgoing

handover.

Transition

timeout

The problem often lies in the parameter



cause according to the signaling tracing of

a core network and a BSS.

Transition failure

in the target

CN/RNC or

system


configuration error or BSS not supporting.



and a BSS.

Transition in the

target CN/RNC

or system not

supported

In this case, a BSC does not support some

parameters of intersystem handover

requests. We need to analyze the cause

according to the signaling tracing of a core

network and a BSS.

Others



and a BSS.

Outgoing

hard

handover

failures within

NODE B,

between

different

NodeBs

within RNC,

and between

RNCs

Failures (>=5) of

hard handover

out of a cell,

failure rate

(>=10%) of hard

handover out of a

cell

Configuration

not supported

UE considers that the command for hard

handover out of a cell is not supported.

The problem generally lies in the

compatibility of a mobile phone.

Physical channel

failure

Possibly poor coverage or severe

interference

Synchronization

reconfiguration

not supported

UE gives the feedback that hard handover

process is incompatible with other

concurrent processes. The problem may

lie in the compatibility of a mobile phone

itself.

Cell Updating

Procedure

Cell update happens during hard

handover out of a cell. This flow nesting

leads to the failure of hard handover out of

a cell.



Observation


Illegal

configuration

UE considers that the command for hard

handover out of a cell is illegal. The

problem generally lies in the compatibility

of a mobile phone.

Others We need to make a further analysis based

on RNC logs.

Failure of

transition out

of a cell

accompanied

by hard

handover

Execution

failures (>=5) of

transition out of a

cell accompanied

by hard

handover,

execution failure

rate (>=10%) of

transition out of a

cell accompanied

by hard handover

Configuration

not supported

UE considers that the command for

transition out of a cell accompanied by

hard handover is not supported. The


of a mobile phone.

Physical channel

failure

Possibly poor coverage or severe

interference

Synchronization

reconfiguration

incompatible

UE gives the feedback that the hard

handover process of RNC adding a link is

incompatible with other concurrent

processes. The problem may lie in the

compatibility of a mobile phone itself.

Illegal

configuration

UE considers that the command for

transition out of a cell accompanied by

hard handover is illegal. This case seldom

occurs.

Configuration

not finished

Others We need to make a further analysis based

on RNC logs.

CS/PS

foreign

handover

failure

CS/PS domain

intersystem

handover failures

(>=5), CS/PS

Configuration

not supported

The handover command terminal in a

network does not provide support. The


of a mobile phone.



Observation


domain

intersystem

handover failure

rate (>=10%)

Physical channel

failure

1) Poor 2 G signal or severe interference

leads to UE access failure.

2) The channel parameters, including

the encryption mode sent from

network to UE, are inconsistent with

those of a BSC. We need to compare

and confirm the parameters of a

terminal and those of a BSC. Physical

channel failure generally occurs in a

network with partners’ equipment as

the CN. We need to check the

encryption algorithm configuration of

an MSC and an SGSN.

Others

We need to make a further analysis

according to RNC logs, together with the

signaling tracing of a core network and a

BSS. Improper service capability

configuration of 2 G cell makes high-rate

service unable to start a pressing mould,

which leads to system PS handover

failure.

1.1.6 Traffic Analysis Observation Point

Table 6 Traffic analysis observation point

Observation

Point Condition Analysis Idea

Uplink CE

Lay an emphasis upon

the analysis of “average

uplink CE resource

occupied” and “the

maximum uplink CE

resource occupied”.

Observe whether “the maximum uplink CE

resource occupied” approaches 128. If it does, an

early warning needs to be given to expansion.

Normally, when the “average uplink CE resource

occupied” is less than 60 CE Erlang,

whole-network busiest-hour cell traffic is very

small.



Observation


Downlink CE

Lay an emphasis upon

the analysis of “average

downlink CE resource

occupied” and “the

maximum downlink CE

resource occupied”

Observe whether “the maximum downlink CE

resource occupied” approaches 128. If it does, an

early warning needs to be given to expansion.

Normally, when the “average downlink CE

resource occupied” is less than 60 CE Erlang,

whole-network busiest-hour cell traffic is very

small.

Average transmit

power of cell

List the average TCP,

the maximum TCP and

the minimum TCP of a

cell.

If the average transmit power of a cell is large and

there is small traffic, it indicates that there is poor

downlink coverage.

Maximum

transmit power of

cell

List the average TCP,

the maximum TCP and

the minimum TCP of a

cell.

If the maximum transmit power of a cell is large

and there is small traffic, it indicates that power

peak shock may lead to power congestion.

Minimum

transmit power of

cell

Observe whether the

minimum transmit power

of a cell is abnormal.

If the minimum transmit power of a cell is

abnormal, the transmit channel may become

faulty.

Average RTWP

List the average RTWP,

the maximum RTWP,

and the minimum RTWP

of a cell.

If the average RTWP of a cell is higher than -95

dBm, there may be downlink interference.

Maximum RTWP Observe whether there

are many peaks.

Among various items, RTWP peaks, for example,

-70 dBm, often appear. This may be caused by the

power of access process or handover process.

Minimum RTWP

Observe whether the

minimum RTWP is less

than -105.5 dBm.

If the minimum RTWP is lower than -108 dBm, a

channel fails to be corrected, or a base station

encounters power-down.

Effective

utilization of

codes

Observe whether the

code utilization is

abnormal.

If the effective utilization of codes is not high (<=

30%), but code congestion leads to access failure,

it is possible that the code distribution algorithm is

abnormal.

Uplink

throughput of cell

Observe the uplink

throughput of a cell.

Observe whether the uplink throughput of a cell is

great. If it amounts to 75% of the transmission

capability of a base station, transmission

expansion needs to be considered.



Observation


Downlink

throughput of cell

Observe the downlink

throughput of a cell.

Observe whether the downlink throughput of a cell

is great. If it amounts to 75% of the transmission

capability of a base station, transmission

expansion needs to be considered..

Cell status

monitoring

List the cell unavailability

duration and its

proportion.

This is generally caused by transmission

interruption or intermittent transmission failure.

Some offices are greatly influenced by weather

due to the use of microwave transmission.

Thunder storm always leads to intermittent

transmission failure.

Missing

configuration of

adjacent cell

List the number of cell

1A events.

If 1A events often happen within many

consecutive days, there may be missing

configuration of adjacent cells.

Excess

configuration of

adjacent cells

Pilot Pollution: List the number of cell

1C events.

If 1C events often happen within many

consecutive days, there may be pilot pollution.

1.1.7 Key Interface Flow Analysis Observation Point

Table 7 Key interface flow analysis observation point

Observation

Point Condition

Possible

Cause Analysis Idea

Security mode

flow failure

IU security mode

failures, IU

security mode

failure rate

Radio

network layer

The problem may lie in the compatibility

of a mobile phone. A mobile phone

terminal may detect the SQN error of in

an AUTN message, which leads to

failure. Cause value: Synch failure!

Respective encryption modes of CS

domain and PS domain may also lead to

a security mode failure.

Transmission

layer

Correspond to transmission link

abnormality.

Network



Observation

Point Condition

Possible

Cause Analysis Idea

optimization

Undefined

RL

establishment

failure of the IUR

interface

RL

synchronization

configuration

failure of the IUR

interface

RL addition

failure of the IUR

interface

List the number of

RL establishment

failures (>= 5) of

the Iur interface of

the SRNC, RL

establishment

failure rate (>=

10%) of the Iur

interface of the

SRNC, and main

failure causes.

OM

intervention

RL failure of IUR interface caused by

operation and maintenance

Hardware

failure

This generally corresponds to equipment

abnormality. We should first query

related equipment alarm.

RNC resource

unavailable

This is caused by insufficient RNC

internal resource. You need to query the

quantity of related users to judge

whether there is any equipment

abnormality.

Configuration

not supported

UE considers that the RL configuration

content of RNC establishment is not

supported. The problem lies in the

compatibility of a mobile phone.

Others Abnormal causes. We need to make an

analysis based on RNC logs.

No response


abnormality. We need to query whether

there is any power-down.

RL

establishment

failure of the

IUB interface RL

reconfiguration

failure of the IUB

interface

RL addition

failure of the IUB

interface

List the number of

RL establishment

failures of the IUB

interface, RL

establishment

failure rate of the

Iub interface, and

main failure

causes.

Configuration

not supported

The problem lies in the compatibility of a

mobile phone itself in some unknown

scenarios.

No available

resource

Insufficient RNC internal resource or

abnormal RNC equipment. You need to

query cell CE resource from relevant

parameters to judge whether there is any

equipment abnormality. Equipment is

known to encounter repeated power

failure and air-conditioner fault due to

thunder storm. As a result, high

temperature leads to abnormality of

various kinds. Besides, the NLPA board

encounters shutdown.



Observation

Point Condition

Possible

Cause Analysis Idea

Equipment

fault


abnormality. We should first query

related equipment alarm.

OM

intervention

RL establishment failure caused by

operation and maintenance (for example,

cell blocking)

NodeB makes

no response

The problem may lie in cell unavailability

or equipment fault. You need to query

the cell unavailability duration from

relevant parameters to judge whether

there is any equipment fault.

Others

RL establishment failure caused by

abnormal factors. We need to make an

analysis based on RNC logs

RL reconfiguration failure caused by

abnormal factors. We need to make an

analysis based on RNC logs. The known

causes are that transmission congestion

(Received Iub AAL2 type1 setup

response message from AL but result is

5 not success!) and improper T314/T315

parameter setting make there not be any

opportunity of RL reconfiguration. RL

addition failure caused by abnormal

factors. We need to make an analysis

based on RNC logs. It is known that RL

addition failure caused by restricted IUB

transmission bandwidth will be classified

into this cause value.

RB

establishment

failure

RB

reconfiguration

failure

RB deletion

failure

RB establishment

failure generally

corresponds to

poor air interface

coverage or a

mobile phone

compatibility

problem.

Configuration

not supported

The problem lies in the compatibility of a

mobile phone itself in some unknown

scenarios. For example, when a Huawei

mobile phone drops network abnormally,

it may not release any RB. When PS RB

is reestablished next time, this case may

occur. This case also happens to SE

V800 mobile phone. Or when some UEs

implement VP and high-speed (greater

than or equal to 64K) PS service, failure



Observation

Point Condition

Possible

Cause Analysis Idea

may also due to unsupported capability.

Physical

channel

failure

This generally occurs when FACH

migrates to DCH and establishes RB.

The downlink physical layer of a terminal

is not synchronized, which leads to RB

establishment failure. This is mainly

caused by poor coverage.

Cell update

The Cell Update flow occurs during RB

establishment. This nested flow leads to

RB establishment failure.

Illegal

configuration

UE considers parameter configuration

illegal. Network and terminals have an

inconsistent understanding of parameter

processing. If RB establishment failure

occurs in the domain of CS, it is possible

that a user dials a wrong telephone

number and immediately goes onhook.

RB SETUP failure may also occur at this

time. The cause is illegal configuration.

Or when a 3 G terminal as the caller

implements VP service, the called party

resides in a GSM network and does not

support VP service. Thus, after RNC

receives an RAB assignment request, a

core network immediately delivers the

Disconnect command upon Call

Proceeding (the cause is Bearer

capability not authorized). But UE has

just received an RB_SETUP command

at this time and has no time to complete

RB establishment. Upon receiving this

Disconnect command, UE initiates a

response “RB establishment failure” and

RNC returns RAB establishment failure.

No response

from UE

Generally poor coverage makes UE

unable to receive any RB command. In

Hong Kong, the balance mechanism of

IUB once made signaling established on

one E1, but service was established on

another E1. Thus, there has been no



Observation

Point Condition

Possible

Cause Analysis Idea

problem with signaling, but RB

establishment may fail. In this case, it is

this cause value that is returned.

RB bearer

distribution of

uplink/downlink

service

Uplink/downlink

RB bearer

distribution of BE

service

Observe whether

the number of

various types of

RB service bearer

and the

proportion are

abnormal. If there

is any

abnormality, an

early warning

needs to be given

PS has a large amount of 128k, 144k,

and 384k RB bearer. This will consume a

large number of resources and there is

poor coverage. We need to verify

whether RB bearer is consistent with

actual demands with first-line personnel.

Observe whether the RB distribution of

BE service is rational. According to the

distribution, DCCC strategy and related

system parameters can be adjusted.

1.1.8 HSDPA Analysis Observation Point

RNC1.6 version supports the following KPI monitoring: HSDPA service establishment

success rate, HSDPA call drop rate, HSDPA cell throughput, H <-> H

intra-/inter-frequency serving cell update success rate and H <-> R99 intra-frequency

handover success rate. It does not support the following KPI monitoring: HSDPA

average uplink and downlink throughput for a single user, H <-> R99 inter-frequency

handover success rate, H -> GPRS intersystem handover success rate, statistics of

the causes for HSDPA service establishment failure, statistics of the causes for

HSDPA call drop failure, statistics of the causes for H <-> H intra-/inter-frequency

serving cell update failure, statistics of the causes for H <-> R99 intra-/inter-frequency

handover failure, statistics of the causes for H -> GPRS intersystem handover failure.

Therefore, we cannot use traffic statistics for HSDPA all-KPI monitoring and analysis,

but need to use other supplementary means. It is recommended to use driving test

and signaling tracing for routine monitoring of the indexes not supported by RNC1.6

version. Meanwhile, analyze and locate KPI abnormality.

RNC1.7 traffic statistics is being collated and remains to be supplemented.

1.2 Example of Analysis Based on Observation Point

Take RRC establishment problem analysis for example.

1. Overall analysis of RRC establishment

As shown in Figure 1 the task window of the Nastar is embedded with the special topic

analysis of call completion rate——RRC Setup Analysis. Double click to start this



query to get the general information about RNC-level RRC establishment. As shown in

the following figure, RRC establishment success rate reaches 98.84%. Most of RRC

establishment failure is because there is no response to RRC Setup command

delivery (7,373 times). Eighteen failures are because of RRC Setup Reject.

Figure 2 General information about RRC setup

The main cause of the exemplified RRC establishment failure is that there is no

response to RRC Setup command delivery. It is unbalanced coverage of downlink

FACH and uplink RACH. For an early network, coverage cannot be guaranteed, so

there are a large number of areas with poor coverage quality. These areas with poor

coverage always correspond to intersystem rerouting areas. On the other hand, where

there are many users or equipment problems within a cell, RRC establishment

rejection is also a major cause of RRC establishment failure.

2. Analysis of RRC establishment scenario

One important reason for RRC establishment failure is poor coverage. We may make

a further analysis by using the establishment cause distribution and success rate of

different RRCs establishment. Get results by starting related query and selecting

Scenario Analysis to present a selected RNC in the form of a pie chart and a bar chart.



Figure 3 Distribution of RRC setup scenario

Figure 4 Comparison of RRC setup scenario success rate

Scenario Analysis makes a comparative analysis of several commonly used scenarios.

The pie chart shows the RRC establishment distribution of a main scenario. The

example in the chart indicates that RRC establishment requests mainly exist in

network registration with REG as the cause. When an LAC area is not well planned or

there is poor coverage (the margin of LAC division is in a prosperous area), there may

be a lot of registration. On the other hand, the cause of RRC establishment during

intersystem reselecting of this mobile phone is registration. A large number of mobile

phones fail to be registered due to poor coverage and will try again and again. Thus,

the cause of RRC establishment is registration in many cases. This indicates that

there is poor network coverage in some areas.



As shown in Figure 4, the bar chart compares the RRC establishment success rates of

various main scenarios. It can be seen from the examples in the figure that the called

voice service has the highest RRC establishment success rate while the calling voice

has the lowest success rate (which corresponds to a large amount of UENoRsp

analyzed earlier). The RRC establishment success rate of registration is also relatively

low. In Huawei networks, the present resident threshold is Ec/Io greater than -18 dB.

The intersystem reselecting starting threshold is Ec/Io less than -14 dB. A low

registration success rate indicates that some terminals have attempted to register at a

network in the areas without good coverage (Ec/Io is between -14 dB and -18 dB). The

called RRC establishment success rate is as high as 99.3%. If the called party starts

RRC establishment, it indicates that he is covered by a PCH. From another point of

view, this indicates that the RRC establishment success rate of expected network

coverage area may be very high.

3. Analysis of RRC establishment rejection

Another cause of RRC establishment failure is RRC establishment rejection. In the

case of RRC establishment rejection, generally too many users lead to admission

rejection, or cell equipment fault leads to access failure. RRC establishment rejection

always corresponds to some areas instead of a large network area. RRC

establishment rejection is generally analyzed based on problematic areas. In the

query results of RRC Setup Analysis, start related query to make TOPN query of Cell

RRC Analysis. Query results cover two pages, which respectively list 10 cells with the

most VS.RRC.FailConnEstab.Cell and VS.RRC.SuccConnEstab.Rate.Cell. For the 10

cells with the most RRC establishment failures and the cells with the most Rej, start

Cell RRC Reject Analysis of related query to analyze the causes for rejection.

Figure 5 Analyzing the cause of RRC rejection



According to the results of Cell RRC Reject Analysis, draw a pie chart of cause

distribution for a selected cell. Figure 5 is an exemplified pie chart of cause distribution

of RRC rejection. In this example, two RRC rejections of a cell are because of Power

Congestion. The following shows the commonly seen causes of rejection:

1) Power Congestion: RRM makes an admission algorithm decision. Downlink

admission decision occurs. Therefore, RRM starts RRC establishment rejection.

This often occurs when heavy network load leads to congestion. Further, we may

start Cell Traffic Load Analysis of related query, pay much attention to the

maximum RTWP and the maximum TCP of this cell and make sure whether there

is uplink congestion or downlink congestion. For congestion, we may check

whether a threshold is properly set and judge whether there is any radio

interference, whether expansion is necessary.

2) CE Congestion: This is mainly because RNC considers CE resource insufficient.

CE congestion always corresponds to many users. These users exceed CE

capacity and we need to expand the capacity of this area. Further, we may start

Cell Traffic Load Analysis of related query, know about the quantity of DCH User

and predict the required CEs according to the traffic model.

3) RL Fail: During RRC establishment, NodeB considers establishment fails. This

may be NodeB fault or insufficient NodeB resource. Further, we may start Cell

Traffic Load Analysis of related query and know about the quantity of DCH users.

Determine whether the problem lies in insufficient resource or equipment fault by

analyzing the board configuration, CE configuration and logs of a corresponding

NodeB.

4) AAL2 Fail: This is mainly the AAL2 Path establishment failure of an Iub interface.

It is generally caused by insufficient transmission resource or transmission

problems. Further, we may start Cell Traffic Load Analysis of related query, know

about the quantity of DCH users and compare it with the AAL2 Path bandwidth of

transmission configuration. Thus, we can determine whether the problem lies in

equipment or insufficient transmission resource.

5) Redir.Inter.Att: Inter-frequency redirection failure starts rejection.

6) Redir.Intrat: Foreign redirection failure starts rejection.

7) Code Congestion: This is mainly because of insufficient resource. Insufficient

code resource may be seen in high traffic scenarios with microcell coverage, and

expansion is necessary. Cell OVSF Code Allocation Analysis of related query

helps analyze the use of channel codes and clarify main services.

8) Other: This is mainly an RNC internal processing problem. Its cause needs to be

confirmed according to R&D logs.

1.3 Summary

Make a similar analysis of several other special topics according to the

above-mentioned idea of the RRC connection analysis. Keep summarizing

experiences in your analysis. Special topic analysis will help greatly improve basic

skills of performance analysis.



Basic special topic analysis practice contributes to the following aspects:

1) Consolidate signaling flow and deepen an understanding of each UTRAN PI.

Performance analysis has a more definite object in view.

2) Basic special topic analysis enables us to make a preliminary analysis of network

performance and locate simple problem causes.

3) Summarize the relationship between performance KPIs and network problems,

and lay a foundation for the use of other Nastar functions and an in-depth

analysis of network performance.

Documents

HW 3G Optimisation Guidelines Network Performance Analysis