You are on page 1of 119

Part 3 :

Optimization

Network Deployment Steps

High level PM data analysis and assessment


System Program (PLMN)

Weekly KPI
( PLMN)
<X%

Using Reporting Suite 3G RAN Reports or MS


Access KPI Queries
No

No action
needed

System Program (RNC)


Yes

Weekly KPI
No
(RNC)
<X%?

Mapinfo
Mataching failure
distribution into
network topology

Solution Proposal

Yes

System Program (WCEL)


Daily KPI
(WCEL)
< X%

System Program (WCEL)


Yes

Presentation / Author / Date

Identify Call failure


phases of bad
performing KPIs, for
example CSSR

Others 3G RAN Reports


Identify Top50 Worst
Cells based on
highest number of root
causes failures

Others 3G RAN Reports


Identify failures rootcauses and failure
distribution of bad KPIs

PM Data analysis process

Presentation / Author / Date

Traffic Monitoring

Principles of traffic monitoring bottlenecks


RNC

WBTS

UE

IuCS Interface
User
Plane
User
Plane

Air Interface

WSP
Resource

PRACH
FACH-c&u
PCH
DCH

Code
Capacity

Iub Interface
CNBAP
DNBAP
AAL2 or IP SIG
User Plane

Throughput
Connectivity
Unit Load
DSP Usage

User Plane

Both interfaces and internal resources


of WCDMA network should be monitored

SS7 (RANAP)

D-RNC

IuPS Interface
User Plane
SS7 (RANAP)

Iur Interface

Principles of traffic monitoring reactive / proactive


Reactive monitoring

Consider setup failure (already discussed in chapter 2)


Daily BH analysis needed

Proactive monitoring

Consider amount of traffic


Weekly analysis enough

Traffic Monitoring
Principles
Transmitted carrier power
Node B reporting
Total DL power
R99 power
HSDPA power

Received total wideband power


Code tree allocation
Channel element allocation
Iub transmission
RNC processing load
Number of users

Node B reporting
Node B informs RNC about air interface load by the following messages
Common NBAP radio resource indication
Transmitted carrier power
Total power R99 + HSDPA
R99 power

Received total wideband power


Total power R99 + HSUPA
HSUPA power (calculated by Node B, not directly measured)

Dedicated NBAP measurement report


Power of each dedicated radio link

C - NBAP
IuB
Node B

D - NBAP
RNC

Total DL power - optimization flow


High total
DL power

High pilot
pollution

High SHO
overhead

Neighbor
analysis

Check SHO parameter


settings
Check adjacent cell
interference

Otherwise

Add second
carrier

R99 power -

R99 power Number of radio resource indications falling into specific R99 power interval
The definition of the load target depends on the presence of HSDPA users
No HSDPA user present static load target PtxTarget
At least one HSDPA user present dynamic load target PtxTargetPS

HSPA power
HSPA power includes
HS-PDSCH
All HS-SCCH
All HSUPA DL signaling channels (E-AGCH, E-RGCH, E-HICH)

HSDPA power - dynamic share with R99


DL power shared dynamically between R99 and HSDPA
Realized by dynamic load target for NRT R99 traffic PtxTargetPS
For RT R99 traffic still static load target PtxTarget
PtxTargetPS is adjusted between
Minimum load target PtxTargetPSMin (default 36 dBm)
Maximum load target PtxTargetPSMax (default 40 dBm)

PtxTargetPSMin PtxTargetPS
PtxTargetPSMax
RNC checks periodically, whether adjustment of PtxTargetPS needed
Period defined by PtxTargetPSAdjustPeriod (default 5 RRI periods)

HSDPA power - dynamic share with R99


PtxTargetPS adjusted under the following conditions
1) HSDPA congestion
Too much total DL power present in cell

PtxTotal
PtxHighHSDPAPwr

PtxHighHSDPAPwr defines overload threshold for HSDPA cell (default 41 dBm)

2) DCH congestion
Too much R99 power present in cell

PtxNonHSPA PtxTargetPS Offset

The offset is fixed to 1 dB

HSDPA power - dynamic share with R99


HSDPA Congestion
HSDPA power congestion, if
Ptxtotal PtxHighHSDPAPwr

If actual load target PtxTargetPS > optimum load target


Decrease PtxTargetPS by PtxTargetPSStepDown (default 1 dB)

PtxMax 43 dBm
PtxHighHSDPAPwr
-10..50; 0.1; 41 dBm

PtxTotal
PtxTargetPSMax
-10..50; 0.1; 40 dBm

PtxTargetPS

PtxTargetPSMin
-10..50; 0.1; 36 dBm

Optimum
load target

PtxNonHSDPA

PtxNRT
PtxNC

HSDPA power - dynamic share with R99


DCH Congestion
DCH power congestion, if
PtxNonHSDPA PtxTargetPS - 1dB

If actual load target PtxTargetPS < optimum load target


Increase PtxTargetPS by PtxTargetPSStepUp (default 1 dB)

PtxMax 43 dBm
PtxHighHSDPAPwr

PtxTotal
PtxTargetPSMax

PtxTargetPS
Optimum
load target

PtxTargetPSMin

PtxNonHSDPA

PtxNRT
PtxNC

RTWP sources
High adjacent cell
interference

PrxOffset
e.g. 1 dB above PrxTarget

Low adjacent cell


interference

i-factor

Noise rise due to


real traffic
-100 dBm
-101 dBm

PrxTarget
e.g. 4 dB above PrxNoise

RTWP of empty cell


MUST be equal PrxNoise

Own cell load factor


(throughput)
-105 dBm

Intermodulation out of band (e.g. 1 dB)


Receiver noise figure (e.g. 2 dB)
Thermal noise -108 dBm

-106 dBm
-108 dBm

Total UL power - role of BTS


RTWP measured by BTScommissioning
at antenna connector
Then corrected due to
Feeder loss
MHA gain

RTWPcorrected = RTWPmeasured + feeder loss MHA gain


Corrected RTWP reported to RNC
With wrong settings wrong RTWP values reported
Previous example for 2 GHz range
Probably feeder loss underestimated corrected RTWP underestimated

Total UL power - optimization


flow
Total UL
power

Close to
-112 dBm

Check HW

Still below
BTS
receiver
noise

Check feeder loss / MHA gain


commissioning setting

Often >
-100 dBm

Check
- High traffic density
- HW
- Intermodulation

R99 code allocation - principles


Code resource required depends on type of radio bearer
Signaling
Voice HR
Voice FR, 16K data
32K data
64K data
128K data
256K data, 384K data

SF 256 for 3.4 Kbit/s, SF 128 for 13.6 Kbit/s


SF 128 or SF 256
SF 128
SF 64
SF 32
SF 16
SF 8

Only 1 code per bearer allocated


SF=8
SF=16
SF=32
SF=64
SF=128

R99 code allocation - blocking


Practical example single cell
Blocking per SF per hour
Total blocking rate

Blocking rate
for SF16

Blocking rate
for SF8

Very high blocking especially for SF8


But still also for SF16 and sometimes
even for SF32

R99 code allocation - rearrangement


Code tree quickly fragmented,
if not re-arranged from time to time

Then few users of high SF (low data rate) block huge amount of resources
for users of low SF (high data rate)
Re-arrangement performed
Periodically according CodeTreeOptTimer (default 1h) OR
If code tree occupation > CodeTreeUsage (default 40%) OR
If more than MaxCodeReleases consecutive releases of codes (default 40)

Blocking before re-arrangement

Blocking after re-arrangement

HSDPA code allocation principles


For HSDPA fixed SF16
But several codes per bearer available
Minimum guarantee of 5 codes
Maximum number set usually to 15 codes
Code resource has to be shared with R99
SF=1
SF=2
SF=4
SF=8
SF=16
0

R99 + HSPA signaling CH

10

11

12

13

14

15

Guarantee for HSDPA

Dynamically shared between


R99 and HSDPA

HSDPA code allocation - dynamic share


with R99
Number of codes reserved for HSDPA can be adjusted dynamically
in dependence on R99 traffic
Possible levels configured with parameter HSPDSCHCodeSet
16 bit parameter to enable / disable each possible level individually

Examples
00000 00000 100000 = always 5 codes reserved (default)
11010 10100 100000 = number of reserved codes adjustable (5, 8, 10, 12, 14 or 15 codes,
recommended)
11-15 codes

0-4 codes always disabled

6-10 codes

HSDPA code allocation dynamic share with R99


Upgrade
RNC checks periodically, whether more codes can be reserved for HSDPA
Requirements for upgrade
Free adjacent codes to go to next higher level defined by HSPDSCHCodeSet
After upgrade still enough codes with SF128 available for R99 (at least HSPDSCHMarginSF128,
default = 8)
Upgrade to 15 codes possible only with HSPDSCHMarginSF128 = 0

HSDPA code allocation - dynamic share


with R99
Downgrade due to NRT R99 traffic
If a NRT R99 request cannot be served due to code blocking, HSDPA is
downgraded only, if the actual number of codes exceeds
Maximum code set DPCHOverHSPDSCHThreshold

Number of allocated SF16 codes

Default = 0 HSDPA always has higher priority than incoming NRT R99 request
Threshold = 5 HSDPA downgraded due to incoming NRT R99 request, if actually
more than 15 - 5 = 10 codes reserved for HSDPA
15
14
13
12
11
10
9
8
7
6
5

Maximum code set


DPCHOverHSPDSCHThreshold

HSDPA code allocation - impact of HSUPA


New DL signaling channels occupying at least the following codes
1 x SF256 by E-AGCH
1 x SF128 by E-RGCH / E-HICH (these two channels share one code)

Loss of a second code with SF16 maximum of 14 codes for HSDPA


SF=1
SF=2
SF=4
SF=8
SF=16
14 HS-PDSCH codes

SF=32
SF=64

Codes for common


channels in the cell

Codes for associated DCHs


and non-HSDPA users

SF=128
SF=256

Up to three HSSCCH codes

E-AGCH (256)

E-RGCH/E-HICH (128)

High code congestion - optimization


flow
High code
congestion

Enable code tree


optimization

Still high
congestion
Many DCH
of low
activity

Enable throughput
based optimization
(R99 DCH)

Many
associated
DCH
Enable F-DPCH
(associated DCH)

High SHO
overhead

Check SHO parameter


settings
Check adjacent cell
interference

Principles

Traffic Monitoring

Transmitted carrier power


Received total wideband power
Code tree allocation
Channel element allocation
Monitoring
BTS channel cards
R99 dimensioning (optional)
HSDPA dimensioning (optional)
HSUPA dimensioning (optional)

Iub transmission
RNC processing load
Number of users

Monitoring - total utilization


For daily work often more convenient to know the percentage of occupied CE
instead the absolute number
Both for DL and UL six to indicate, how often total utilization falls into
certain interval
0-49 %
50-69 %
70-79 %
80-89 %
90-99 %
100 %

100%
90-99%
80-89%
70-79%

Monitoring - total utilization


Practical example UL on single BTS

In most cases very high


utilization
Typically 80-89 % or 90-99 %

Monitoring - utilization by HSPA


Both for DL and UL five additional to indicate, how often utilization by HSPA
falls into certain interval
0-19 %
20-39 %
40-59 %
60-79 %
80-100 %

Monitoring - utilization by HSPA


Practical example UL on single BTS

In most cases very high


utilization due to HSUPA
Typically 80-89 %

R99 dimensioning
In general, each DCH occupies a certain number of CE in dependence
on the type of service
The CE occupation is the same for
FSMC/D/E and WSPF cards
R99 DCH and associated DCH

Service

CE

SRB / voice / 16 K data

32 K data

64 K data

128 K data

256 K data

384 K data

12

R99 dimensioning
Less CE needed for DCH of 256 K and 384 K
All other rules remain unchanged

Service

CE

SRB / voice / 16 K data

32 K data

64 K data

128 K data

256 K data

384 K data

High CE occupation optimization flow


High CE
occupation

Many DCH
of low
activity

Many
associated
DCH

Enable throughput
based optimization
(R99 DCH)

Enable F-DPCH
(associated DCH)

High SHO
overhead

Check SHO parameter


settings
Check adjacent cell
interference

Principles

Traffic Monitoring

Transmitted carrier power


Received total wideband power
Code tree allocation
Channel element allocation
Iub transmission
Implementation principles
Monitoring options
Examples

RNC processing load


Number of users

Examples - physical ATM traffic


Two VC multiplexed by IMA
Cell rate reserved by CAC per VC
Configured bandwidth

M550 CAC AAL2


Measurements
Even Path
maximum
reserved bandwidth

far per
belowsecond
configured
bandwidth
2 VCs with
(ATM) cells
per
VC on 1 IMA group
Free 8250
bandwidth
No risk of physical congestion

Maximum reserved bandwidth

Minimum reserved bandwidth

Examples - logical ATM traffic


Two VC multiplexed by IMA
Number of AAL connections established by CAC per VC

Even in busy hour number of AAL connections


clearly below maximum of 248
No risk of logical congestion

Principles

Traffic Monitoring

Transmitted carrier power


Received total wideband power
Code tree allocation
Channel element allocation
Iub transmission
RNC processing load
RNC block diagram
Monitoring options

Number of users

Case High Call Drop Rate due to RNC Traffic


Measurement Defect (Continued)

Solution
After the patch is installed for the RNC, almost all the call drops with the cause being Other have disappeared
and the PS call drop rate is obviously lower, as shown in the following table. The problem is thus solved.

Note: You can get the table on the right via custom report or Performance Query of Nastar.

Principles

Traffic Monitoring

Transmitted carrier power


Received total wideband power
Code tree allocation
Channel element allocation
Iub transmission
RNC processing load
Number of users

Number of users - licenses


R99
No license for specific number of users per cell required
New user allocated, as long all types of RAN resources available

HSPA
License for specific number of users per cell required
The following levels are available
16 users
48 users
64 users
72 users

If maximum number of users present, new user rejected, even if all


types of RAN resources still available

Call setup - phases


Setup

Access
Complete

Attempts

Setup
Complete

Access

Active
Active
Complete
Access

Phase:

Active
Release
Active
Failures

Access failures
Setup failures
(blocking)

RRC connection setup


RAN resources reserved for
signaling connection between UE
and RNC
RRC access
Connection between UE and RRC
RRC active
UE has RRC connection
If dropped, also active RAB
dropped
RAB setup
Attempts to start call
RAB setup access
Connection between UE and core
RRC RAB active phase
UE has RAB connection

Success

RRC and RAB

Drop

CSSR affected if any of the following


events takes place

RRC Connection Setup Fail

RRC Connection Access Fail

RAB Setup Fail

RAB Setup Access Fail

Call setup successful RRC establishment


Signalling and trigger
UE

Three phase for RRC

Node B

RNC

[RACH] RRC Connection Request

AC to check to accept
or reject RRC
Connection Request
NBAP RL Setup Request

RRC Connection Setup


phase

Start
Start TX/RX
TX/RX

Allocation of UTRAN
resources

NBAP RL Setup Response


ALCAP ERQ
ALCAP ECF
[FACH] RRC: RRC Connection Setup
Start TX/RX

RRC Connection
Access phase

L1 Synchronisation
NBAP Synchronization Indication

[DCH] RRC Connection Setup Complete

RRC Connection Active phase

Waiting for UE reply

RRC Connection SETUP and ACCESS PHASE


Signalling and trigger
Three phase for RRC

UE

Node B

RNC

[RACH] RRC Connection Request

AC to check to accept or
reject RRC Connection
Request
NBAP RL Setup Request

RRC Connection Setup


phase

Start TX/RX

Allocation of UTRAN
resources

NBAP RL Setup Response


ALCAP ERQ
ALCAP ECF
[FACH] RRC: RRC Connection Setup
Start TX/RX

RRC Connection Access


phase

L1 Synchronisation
NBAP Synchronization Indication

[DCH] RRC Connection Setup Complete

Waiting for UE reply

1. RRC setup attempts.


2. RRC setup attempts per setup cause.
(SEE NEXT SLIDE)
3. RRC setup failures due to
handover control , admission control
transport (Transmission) RNC internal
frozen BTS BTS ICSU overload

4. RRC setup failure per cause.


5. RRC setup complete.
6. RRC access failures due to
radio interface UE RNC internal

7. RRC access complete.


8. Special reason: RRC active release
due to
SRNC Relocation Pre-emption
User inactivity RNC HW resources
ISHO to GAN Inter-system handover to GSM IF
inter-RNC hard handover Inter-frequency interRNC hard handover

9. RRC active failures due to


Iu interface (transport) radio interface
(synchronisation) BTS Iur interface (DRNC)
RNC internal UE Transmission

10. RRC active complete

1. RAB setup attempts. Separate


counter per each RAB type.
2. RAB setup failures due to
admission control transport (transmission)
RNC internal frozen BTS BTS (RT only)
anchoring (NRT only) capacity license (for
CS voice RAB only)

3. RAB setup complete. Separate


counter per each RAB type.
4. RAB access failures due to
UE RNC internal

5.

RAB access complete.


Separate counters per each RAB
type.
6. Special reason: RAB active
release due to
SRNC relocation pre-emption capacity
license pre-emption (only for CS voice RAB)

7.

RAB active failures due to

Iu interface (transport) radio interface


(synchronisation) BTS Iur interface
(DRNC) RNC internal UE Transmission

8.

RAB reconfiguration
attempts.
9.
RAB reconfiguration failures.
10.
RAB active complete.
Separate counters per each RAB
type.

Drop Call Analysis

Presentation / Author / Date

Case 1: Drop due to missing neighbor

Problem: Detected Nighbor (DN)


UE sends a Measurement Report that contains an event1a means
adding a new RL (cell) to Active Set
If the reported cell is not in the current neighbor cell list and the
reported Ec/No is better than the best serving cell Ec/No in AS
by some dBs (set by a RNC parameter)
If for any reason the new cell can not be added to AS, call will be
released

Case 1: Drop due to missing neighbor

DL BLER gets worse

DN cell better than the serving cell

Case 2: Drop due to Poor Coverage (low RSCP)

Problem: Poor DL coverage


When UE gets to an area with low RSCP ( < -105 dBm)
regardless Ec/No values there is high risk for drop.
UE will likely ramp up the transmitted power and reach its
max power. The DL BLER will probably increase and SIR
target cannot maintain anymore, finally the call drops.

Case 2: Drop due to DL Poor Coverage

Very bad RSCP

UE max Tx power
and
high DL BLER

Case 3:
PS: Session Error due to Poor DL Coverage
UE enters a very low coverage area (RSCP < 105 dBm).
The packet connection is carried on a 64/64 DCH Channel
as consequence of the low coverage conditions.
The UE will likely ramp up its power to the maximum, goes
to Idle Mode and the Application and RLC throughputs go
to zero.
At this point the RAS application will start the Session
Timeout timer, if the throughput is not resumed the Session
Error event is triggered with cause session timeout.

PS: Session Error due to Poor DL Coverage

App throughput ~64kbps

Very low RSCP

FINAL WORDS
For network tuning, we need to rely on field measurements which require extensive
drive tests
Finding the best possible configuration for antenna heights, tilts, azimuths and
parameter setting for all the present cells/sectors in the network and also for
any new sites that might be needed to improve coverage
Power adjustment can also be used for network tuning but can become
complicated and result in poor network performance
Use of Remote Electrical Tilt (RET) Antenna is preferred over mechanical tilt
antenna
Neighbour definition is of prime importance in UMTS network (Soft handover gain
and interference reduction). Keep neighbour list upto 20.
Automated tools are needed that could suggest the best possible neighbour
relations, antenna heights and tilts by using both the field measurements and
the propagation models & simulations
Skilled people, right methods and advanced tools are needed to perform 3G tuning
and optimisation

Max HSPA users in cell/RNC,RNC


licensed capacity:Max AMR/Iups
throughput

Call Drop analysis


Top (N) drops

Cell and its Neighbour


Cells availability
Alarms/Tickets

Neighbours Performance
(use SHO success per adjs
counters to identify badly
performing neighbours) & Map

Site OK ?
YES

HHO RSSI &


BSIC time,
ISHO
cancellation

Audit adjacent sites for


alarms, Availability,
configuration and
capacity

NO

Configuration &
Parameter audit
SHO based on
DSR, CPICH
EcNo
difference,
SHO branch
setup fail
BTS/Iub

Traffic

Conf OK ?
3G Cell at RNC
border?

YES

SHO
Success
Rate <
90%?

SHO

YES

NO

ISHO
Failures

ISHO

No cell
found ratio
>40 %

Iur
performance

Investigation Iur

Relocation success in
target RNC
New site ?

Analyse last detailed


radio measurements

NO

YES
Top
issu
es

YES

RF and IFHO neighbour


optimisation

3G cell covers
over a
coverage
hole ?

3G cell at
inter-RNC
border ?

RF and ISHO neighbour


optimisation

YES

2G Cell Doctor
NO

2G Investigation :
TCH blocking or
TCH seizure
failure
(interference)

YES

ISHO
Success
Rate < 90%

Presentation / Author / Date

No cell found
ratio > 90 %
and enough
ADJG

Wrong reference clock


(10MHz tuning)

HSDPA IFHO failures, reject CM for IFHO

Call Drop analysis


1. Check high call drop cells and its neighbouring cells of any faulty alarms
2. Identify call drop root cause failure distribution and main failure contributor (radio, Iu, BTS, Iur, MS, RNC)

3. Check SHO KPI if performance < 90% ( leads to radio failure)


Check if cells are at RNC border (check Iur capacity and SRNC relocation problem)
Detect badly performing neighbours using HO success rate per adjacency counters (M1013)
High incoming HO failure rate in all adjs check sync alarms
Assessing neighbor list plan and visualization check with map
Evaluate HO control parameters and trigger threshold
4. Check ISHO KPI if RT ISHO < 90% or NRT < 80% (leads to radio failure)
Check missing neighbour (M1015), GSM frequency plan neighbour RNC and MSC database consistency
audit, check alarm of reference clock in 3G or in 2G, check 2G TCH congestion
Check RRC Drop ISHO RT / NRT

Presentation / Author / Date

Call Drop analysis


5. Detecting DL or UL path loss problem if RAB drop due to radio (dominant call
drop cause > 50%)

Check UL Lost Active KPI from Iub counters (active L1 synchronization failure) to check UL/DL
path loss problem
Check ASU failure rate (UNSUC_ASU) which link to NO RESPONSE FROM RLC
Mapping radio failures with Tx power and CPICH related parameters ->
CPICHToRefRABOffset, PTXDPCH MAX
Check Call reestablishment timer -> T315
Ecno distribution for bad coverage issue (M1007C38-M1007C47)

6. Check core network parameter setting if RAB_ACT_FAIL_XXX_IU

Check SCCP SGSN/RNC IuPS Tias/Tiar if RAB_ACT_FAIL_BACKG_IU


7. If high RAB_ACT_FAIL_XXX_BTS

Check if any BTS faulty alarm (7653 cell faulty alarm)

If no alarms, COCO detach/attach


8. If high RAB_ACT_FAIL_XXX_MS

Check physical channel reconfiguration failure rate (IFHO, ISHO, code optimisation)

Presentation / Author / Date

HSDPA Low Throughput

Presentation / Author / Date

HSDPA Throughput Analysis

Presentation / Author / Date

Good CQI but poor HSDPA throughput

Presentation / Author / Date

COMMON CALL PERFORMANCE ISSUES

Presentation / Author / Date

Common Call Performance Issues

Presentation / Author / Date

Common Call Performance Issues

Presentation / Author / Date

Common Call Performance Issues

Presentation / Author / Date

Common Call Performance Issues

Presentation / Author / Date

Common Call Performance Issues

Presentation / Author / Date

Common Call Performance Issues

Presentation / Author / Date

Video Call Performance Issues

Presentation / Author / Date

Video Call Performance Issues

Presentation / Author / Date

ISHO Performance Issues

Presentation / Author / Date

Soft Handover Neighbour Tuning

Presentation / Author / Date

Active Set Usage


M1013
(These counters are referred to cell addition and cell replacement no target for deletion)

Absolute Value must be considered not Failure Rate!

Active Set Usage

Major

Minor

High # outgoing fails for a


defined ADJS?

Yes

Failure
ADJS

High # outgoing
attempts?
Unbalanced ADJS
Yes

Zero
attempts?

Low used Adjs

Yes

No Adjs

In out
pairs?

High # fails for


a source?
High #
attempts for
a source?

Yes

Ping-Pong

Yes

Yes
Failure
WCEL

Minor

Unbalanced WCEL

Filtering over attempts must be taken into count that:


- statistical data must stabilized over time.
- traffic distribution is not considered and a double-check to
localize the event and DT feedback is required to understand if
fenomena is traffic driven or cell dependent

Filtering over failure in absolute


terms it is possible to find the major
critical events

Active Set Usage


Filtering criteria:
Major
- High number of failures for a defined out-going adjs (failure ADJS)
- high number of fail for a defined source (failure WCEL)

Minor
- high number of attempts in-comig and out-going for a defined pair with
occasional failure (ping-pong)
Filtering action are required to find bi-lateral corrispondence
- very low number of attempt with failure (low used adjs)
- zero number of attempt for declared adjs stabilized value (no adjs)
- high number of attempts with occsional failure for an out-going adjs
(unbalanced ADJS)
Either in-coming or out-going condition is sufficient
- high number of attempts with occsional failure for a defined source
(unbalanced WCEL)

Failure ADJS

Failure ADJS

Analyze RSCP from DT


& NWP coverage plot
considering inter-site
distance

Target act
as polluter?

Analyze Ec/No from DT

Ec/No offset

Once anlyzed the RSCP,


the coverage plot taking
care to the evaluation of
intersite-distance, it is
easy to understand if
target can be used.

Very low value


of RSCP that
not allow the
adjs to be used
Yes
Down tilt
possibile?

DERR cell

Yes

Down tilt

If not only down tilt is


possible or DERR (ADJS
object Paremeter) cell to
avoid the failure during
SHO.
Down tilt must be
carefully anlyzed.
If from Ec/No the cell can
be recovered an individual
offset or filtering (ADJS
object Parameter) can be
introduced to fovourite it

Failure ADJS Individual Ncell Offset


Ec/Io

P CPICH 1

Reportin
g Range
AdjsEcNoOffset
to modify
measurement
reporting behaviour.
Effectively 'moves'
cell border (shrinks or
enlarges cell)

P CPICH 2

Enlarging Cell 3 by x
dB
P CPICH 3

time
Reporting
Event 1B

Reporting
Event 1A

Failure ADJS Forbidding Neighbour Cell


Ec/Io

P CPICH 1
Reporti
ng
Range
P CPICH 2

PCPICH3 is forbidden to
affect the reporting
range as its quality is
quite unstable.
AdjsDERR
to forbid a cell from
reporting range calculation
in some instances

P CPICH 3

Time

Failure WCEL
Failure WCEL

Most of the Target failure during the 1A or 1C event.

Analyze Ec/No &BLER


from DT & NWP coverage
plot considering inter-site
distance

The following gives the number of attempts per event


RT Services
KPI(1) = M1007C10 CELL ADD_REQUEST ON SHO FOR RT TRAFFIC
Yes

WCEL
polluted/interfered?

Pollution/Interference

KPI(2) = M1007C12 CELL REPL_ REQUEST ON SHO FOR RT TRAFFIC NRT


Services
KPI(1) = M1007C27 CELL ADD_ REQUEST ON SHO FOR NRT TRAFFIC
KPI(2) = M1007C29 CELL REPL_REQUEST ON SHO FOR NRT TRAFFIC

Once anlyzed the Ec/No, BLER, the coverage plot taking care to
the evaluation of intersite-distance, it is easy to understand if
the WCEL is interferered/Polluted

Analyze Ec/No from DT

Yes
KPI(1) ?

Tune 1A

If not, two KPIs allow to separate the dominant contribute


among the 1A and 1C.
Relaxing the parameters an improvement should be achieved
The failure rate for all the procedure can be estimated as well
ADD(REPL)_ FAIL_ONSHO _FOR_x / ADD(REPL)_REQ_ON_SHO_FOR_x +
ADD(REPL)_ FAIL_ONSHO _FOR_x

Yes
KPI(2) ?

Tune 1C

M1007C14 / M1007C12 + M1007C14


M1007C36 /M1007C11 + M1007C36
M1007C30 / M1007C27 + M1007C30
M1007C37 / M1007C28 + M1007C37
M1007C31 / M1007C29 + M1007C31

Failure WCEL - 1A
ActiveSetWeightingCoefficient
is used to weight either the
measurement result of the best
active set cell (0) or the sum of
measurement results of all active
set cells (<>0)

Ec/Io

Strongest CPICH in AS:

AdditionWindow
determines the
relative threshold
used by the UE to
calculate the
reporting range of
event 1A. The
threshold is either
relative to the CPICH
Ec/No measurement
result of the best
active set cell (0), or
P CPICH 3
to the sum of active
set measurement
results (<>0)

P CPICH 2
1A

AdditionTime
defines the 'timeto-trigger' interval
between the cell
Measurement
entering the
Report
reporting range
and the UE sending
the measurement
report to the RNC
with the 1A event

RNC

no
Add to
the AS?

P CPICH 1

AdditionReportingInterval
defines the period of time
that the UE wait, if the RNC
is unable to add Ncell to AS,
before sending further
reports periodically, with
interval
AdditionReportingInterval
, until the Ncell moves out of
reporting range, or RNC adds
Ncell to AS.

time

Failure WCEL - 1C
ReplacementWindow

Ec/Io

AS has 3 cells

determines the margin by which the CPICH Ec/No


measurement result of the monitored cell (MNew)
must exceed the CPICH Ec/No measurement result
of the an active set cell (MInAS) before the UE can
send the event 1C triggered Measurement Report
to the RNC: MNew >= MInAs +
P CPICH 1
ReplacementWindow / 2
P CPICH 2
P CPICH 4
1C

P CPICH 3

weakest CPICH in AS
ReplacementTime
Defines the period of time the monitored
cell must continuously stay within the
reporting range before the UE can send a
Measurement Report to the RNC in order
to replace an active set cell with the
ReplacementReportingInterval
monitored cell (event 1C).
If the RNC is not able to replace the
active cell with the monitored cell, the
UE continues reporting after the initial
report by reverting to periodical
measurement reporting. The parameter
Replacement Reporting Interval
determines the interval of periodical
measurement reports when such
reporting is triggered by the event 1C.

time

no
Measurement
Report

AS
update?
RNC

NO ADJS

No Adjs

Zero
attempts?
Repeat Analysis
Yes

Statistic
Stable?

Yes

DT analysis for the Adjs

Remove ADJS

Comparing the ADJS plan provisioned into the


network with the M1013 matrix, it is easy to
find if one declared ADJS is not used (not
present in the list)
Statistic data must be stabilized before decide
to remove it and DT analysis can help n
estimating the amount of residual noise if
down tilt is not possible

Low used ADJS


Low used Adjs

Analyze DT
result and
NWP data

Yes

ADJ Offset

It is not difficult in live network to find some


pair working with very low
For low used ADJS has to be intended and ADJS
that has few number of attemps in one day
(e.g <3)

Monitored Qual
from DT
acceptable?

with occasional failure.


Alter. ADJS
present?

Yes

Interference
evaluation

Remove ADJS

The ADJS removal has to be considered as the


last option, after the quality has been
monitored by drive test result, considering the
overall capability of the target to be recovered
(e.g. inter-site distance, power budget) and
other options are available for that area.
Statistic data must be stabilized before decide
to remove it and DT analysis can help in
estimating the amount of residual noise if
down tilt is not possible

Unbalanced ADJS

Unbalance ADJS

Analyze RSCP from DT & NWP


coverage plot considering intersite distance e traffic
distribution

An high number of attempt could be


an indication of a problem and even
in case of the failure is not associated
an evaluation is required.

Attempt over
the same UE?

The key point is the inviduation of the


attempt distribution, that in case are
not justified but partcualar populated
area, coluld generate lot of signalling.

No action
required

Yes
Yes
Target act
as polluter?

Analyze Ec/No from DT


& evaluate unbalance

Ec/No offset

Down tilt
possibile?

DERR cell

Yes

Down tilt

The attempts could be genarated by


1B event ever the same UE not
counted in the M1013.
The possibility to recover the ADJS is
the favourite option and the down tilt
carefully analyzed considering the
failure associated.

Unbalanced WCEL
Unbalanced WCEL

Analyze RSCP from DT & NWP


coverage plot considering
inter-site distance and traffic
distribution

Attempt over
the same UE?

No action
required

Yes
Yes
WCEL interfered
polluted?

Interference /
pollution

The key point is the inviduation of the


attempt distribution, that in case are not
justified but partcular populated area,
coluld generate lot of signalling.
The attempts could be genarated by 1B
event ever the same UE not counted in
the M1013.

Analyze Ec/No from DT

The possibility to have an


interference/pollution increase respect to
the unbalanced ADJS.

Yes
KPI(1) ?

Tune 1A

The optimization should be performed at


WCEL level
The KPI reported are the same of Failure
WCEL

Yes
KPI(2) ?

An high number of attempt could be an


indication of a problem and even in case
of the failure is not associated an
evaluation is required.

Tune 1C

Ping Pong
Down tilt

DERR cell

Ping-pong

Yes

Down tilt
possibile?

Yes
Analyze RSCP from DT &
NWP coverage plot
considering inter-site
distance

pollution

No action
required

Attempt from
the same UE?

From A >> B and from B >>A as


in the picture

One of them act


as polluter?

Analyze Ec/No from DT

Not stable,
Fading?

Yes

Filtering

Comparable
value?

Yes

Histeresys
using
Ec/NoOffset
on the pair

In this particular case the high


number of attempt is
concentrated in a pair

As in the previous case could be


an indication of a problem and
even in case of the failure is not
associated an evaluation is
required to avoid to use a lot
signalling.
The optimization should be
performed at ADJS level
considering that the filtering
option could get to smoother
measured value

Ping Pong - Filtering


EcNoFilterCoefficient

EcNoAveragingWindow
Applied for averaging of
periodical meas. reports

I am in the
CELL_DCH substate

System Information [
Measurement Control [
UE

Measurement Type: Intra-frequency measurements


Reporting events:
1A: Event 1A triggered when CPCIH Ec/Io of the measured cell
enters UE
reporting range for a defined period of time
1B: Event 1B triggered when CPICH EC/I0 of the measured cell
drops out
of the UE reporting range for a defined period of time
1C: Event 1C triggered when CPICH EC/IO of the measured cell
enter in
AS by a defined margin for a defined period of time

UTRAN
]
Node B

RNC

Ec/NoFilterCoeff
controls the higher layer filtering of
physical layer measurements before
the event evaluation and
measurement reporting is performed
by the UE.

Pollution

Polluter Detection
The best way to individuate a Polluter is the Drive Test
A feedback can come from coverage plot, RNP feedback and Counters
A polluter can be of different type:
1.

PSC Pollution
Too high reuse factor for the PSC. New PSC plan is required

2.

DL Noise raise
ADJS signal strength out of usage window (will be never utilized by the UE)
A down tilt or power reduction is the solution evaluating all the side effects

3.

Dominant site
A dominant site over-shooting the ADJ becoming congested
A down tilt or power reduction is the solution evaluating all the side effects

PSC Pollution
A confirm for the polluter of the first type can come from the counter
M1007C38-47 CELL SPECIFIC CPICH EC/NO - CLASS x
Pollution Criteria:
The M1007C38-47 gives an indication of Ec/No distribution value measured
during event 1A . Having the distribution highly unbalanced (normally centered
on class 2, 3, 4) we have an indication of a probable problem. For example
unbalancing towards the scarce value of Ec/No but continuing to add cells to AS
could give an indication of pollution
High number
of class0-3?

Yes

Not Polluted WCEL

High number of
class>6?
Yes
Polluted WCEL

Isolated/unavailable
WCEL

DL Noise Raise

The NO ADJS and low used ADJS criteria before presented can give a
confirm for a pollution of this type.
After the statistical data are stabilized, making across-check with the
provisioned ADJS Plan the probable polluters are individuated.
This is obviously a cautelative estimation to be integrated and confirmed
by drive test results

Dominant site

Filtering the M1013 pairs for the recurrent target cell with associated
occasional failure we have an estimation of the probable polluters
For the polluters, originating failures a down tilt is required
Polluted Cell Criteria:
SHO over head can give a soft help in individuating cell where
polluter/overshooting site can be present or where unbalanced cell criteria
could apply
Soft Handover Overhead RNC_79B
M1007C0 ONE_CELL_IN_ACT_SET_RT M1007C19 ONE_CELL_IN_ACT_SET_NRT

M1007C1 TWO_CELL_IN_ACT_SET_RT M1007C20 TWO_CELL_IN_ACT_SET_NRT 2

M1007C2 THREE_CELL_IN_ACT_SET_RT M1007C21 THREE_CELL_IN_ACT_SET_NRT 3

1 100%
M1007C0 ONE_CELL_IN_ACT_SET_RT M1007C19 ONE_CELL_IN_ACT_SET_NRT

M1007C1 TWO_CELL_IN_ACT_SET_RT M1007C20 TWO_CELL_IN_ACT_SET_NRT

M1007C2 THREE_CELL_IN_ACT_SET_RT M1007C21 THREE_CELL_IN_ACT_SET_NRT

Cell Reselection

Cell Reselection 2G -> 3G


Cell Reselection
BCCH: FDD_Qm

Start
measurement

List

in, FDD_Qoffset

GSM MS starts WCDMA measurements if :


RLA_C< F(Qsearch_I) for 0<Qsearch_I<=7
or
RLA_C> F(Qsearch_I) for 7<Qsearch_I<=15

If, for suitable UMTS cell


& for a period of 5 s:
CPICH RSCP > RLA_C + FDD_Qoffset
and
CPICH Ec/No FDD_Qmin

WCDMA cell
reselection

2G -> 3G Measurement
Depending on operators 2G 3G interworking strategy parameter Q_search_I should planned accordingly.

In the best case, 3G


cell measurements are
possible when RLA_C
level < 74 dBm

In the best case, 3G cell


measurements are
restricted to the condition:
RLA_C level > 78 dBm
GSM

GSM

3G

3G

3G
GSM

Configuration 1
RLA_C<
F(Qsearch_I)
( 0<Qsearch_I<=6 )

Configuration 2
RLA_C> F(Qsearch_I)
( 7<Qsearch_I<=15 )

Configuration 3
RLA_C< (always).
(Qsearch_I=7)

2G -> 3G Cell Re-selection Parameters


Qsearch_I and Qsearch_P define the threshold for non-GPRS/GPRS (respectively) capable UEs to measure 3G
neighbour cells when a running average of the received downlink signal level (RLA_C) of the serving cell
below (0-7) or above (8-15) the threshold
Value

10

14

15

dBm

-98

-94

-74

Always

-78

-74

-70

-54

Never

If RLA_C > -70 UE starts


3G measurements

UE always measures 3G
cells

If RLA_C < -94 UE starts


3G measurements

FDD_Qoffset and FDD_GPRS_Offset the non-GPRS/GPRS (respectively) capable UEs add this offset to the
RLA_C of the GSM cells. After that the UE compares the measured RSCP values of 3G cells with signal levels
of the GSM cells
Value

14

15

dBm

Always

-28

-24

-20

24

28

Always select irrespective


of RSCP value

Reselect in case RSCP >


GSM RXLev (RLA_C) +28dB

FDD_Qmin, defines minimum Ec/No threshold that a 3G cell must exceed, in order the UE makes a cell
reselection from 2G to 3G.

Cell Re-selection Example-Weaker WCDMA


Non GPRS case
RSCP/
RLA_C

Ec/No
Cell re-selection to WCDMA

RLA_C

Serving GSM Cell

Qsearch_I=0
(-98 dBm)
FDD_Qoffset =6 (-8 dB)
Measurements starts (serving cell)

Neighbour WCDMA Cell

FDD_Qmin=0
(-20 dB)

RSCP

Ec/N0
Minimum Quality Requirement for WCDMA
t
5 sec.

Cell Re-selection Example-Weaker WCDMA


GPRS case
RSCP/
RLA_C

Ec/No
RLA_P
Cell re-selection to WCDMA

FDD_GPRS_Qoffset =10 (8 dB)


Serving GSM Cell (Best)

Qsearch_P=0
(-98 dBm)

RSCP
Measurements starts (serving cell)
FDD_Qmin
=-20 dB
Neighbour WCDMA Cell

Ec/N0

Minimum Quality Requirement for WCDMA


t
5 sec.

Cell Reselection 3G -> 2G


Whilst camping in a 3G cell the UE performs intra-frequency, inter-frequency, and inter-system
measurements based on the measured CPICH EcNo.
Serving cell parameters Sintrasearch, Sintersearch and SsearchRAT are compared with Squal (CPICH
Ec/No Qqualmin) in S-criteria for cell re-selection
1 - None
(Squal > Sintrasearch )
2 - WCDMA intra-frequency (Sintersearch < Squal Sintrasearch)
3 - WCDMA intra- and inter- frequency, no inter-RAT cells (SsearchRAT < Squal Sintersearch)
4 - WCDMA intra- and inter-frequency and inter-RAT cells (Squal SsearchRAT )

Sintrasearch Sintersearch

1
WCDMA
CELL

SsearchRAT

Cell Reselection 3G -> 2G


CPICH EcNo

UE starts GSM measurements if


CPICH Ec/No =< qQualMin + sSearchRAT

SintraSearch

First ranking of all the cells based on


CPICH RSCP (WCDMA) and RSSI (GSM)

SinterSearch

Rs = CPICH RSCP + Qhyst1


Rn= Rxlev(n) - Qoffset1

Neighbour WCDMA or GSM


cell calculation with offset
parameter

SsearchRAT
qQualMin
No

Serving WCDMA cell


calculation, with
hysteresis parameter

Yes
Rn (GSM) > Rs (WCDMA)
And
Rxlev (GSM) >QrxlevMin

Second ranking only for WCDMA


cells based on CPICH Ec/No
Rs = CPICH Ec/No + Qhyst2
Rn=CPICH_Ec/No(n)-Qoffset2

Cell re-selection
to GSM
Cell re-selection to
WCDMA cell of highest
R value

Cell Reselection 3G -> 2G


UE ranks the serving cell and the measured neighboring cells to find out if reselection should be made
All the measured suitable cells (S-criteria) are included in the ranking.
Criteria for a suitable cell (S-criteria) is defined as
WCDMA intra-frequency neighbour cell:
CPICH Ec/No > AdjsQqualmin and CPICH RSCP > AdjsQrexlevmin
WCDMA inter-frequency cell:
CPICH Ec/No > AdjiQqualmin and CPICH RSCP > AdjiQrexlevmin
GSM cell:
Rxlev > Qrxlevmin
Ranking is done using Criteria R, and the UE reselects to the cell with highest R-criteria. R-criteria is
defined
as:
For serving cell: Rs = Qmeas,s + Qhysts
For neighboring cell Rn = Qmeas,n Qoffsetts,n
Qmeas is CPICH Ec/No for WCDMA cell and RxLev for GSM cell

How to avoid ping pong ?


When phone is camped on 3G, GSM measurements can start when CPICH Ec/Io of serving cell is below
Ssearch_RAT + QqualMin.
When phone is camped on GSM, cell reselection to 3G is possible if CPICH Ec/Io of the candidate is above
FDD_Qmin.
Therefore, to avoid ping pongs between 3G and GSM the following condition should be met:

FDD_Qmin >= QqualMin + Ssearch_RAT


CPICH Ec/Io

FDD_Qmin >= -12 dB


QqualMin +Ssearch_RAT
Ssearch_RAT=4 dB
QqualMin=-18 dB

Camping on 3G

Measure GSM

Camping on 3G
t

How to avoid ping pong ?


Parameters for cell reselections

Qqualmin = -18dB Ssearch_RAT =2dB -> the 3G->2G cell reselection starts when Ec/No hits -16dB
FDDQmin(GPRSFDDQmin) = -14dB (6) and QsearchP/QsearchI = always

The cell reselection paramters 3G -> 2G and 2G -> 3G provide only 2dB hysteresis which is not enough and should be
noticed from the RNC statistics as high amount of INTR_RAT_CELL_RE_SEL_ATTS from all the RRC Connection
Setup Attempts

Recommendation is to adjust the FDDQmin from -14dB to -10dB (or even up to -8dB) to provide 6 to 8 dB
hysteresis between 3G to 2G cell reselection and 2G to 3G cell reselection
Another parameter to tune is Qrxlevmin

On top of Treselection the above parameters will slow down further the 2G to 3G and 3G to 2G cell reselections

Treselection
How long the reselection conditions must be fulfilled before reselection is triggered?
Treselection
Impacts all cell reselections : Inter RAT, intra frequency and inter frequency
The UE reselects the new cell, if the cell reselection criteria (R-criteria, see next slide) are fulfilled during a time
interval
Treselection
As this parameter impacts on all the cell reselections too long Treselection timer might cause problems in high mobility
areas but too short timer causes too fast cell reselections and eventually causes also cell reselection ping pong
Recommended value 1s should work in every conditions i.e. enough averaging to make sure that correct cell is
selected
However careful testing is needed to check the performance of different areas
(Dense) Urban area, slow moving UEs with occasional need for fast and accurate (to correct cell) reselections e.g.
outdoor to indoor scenarios or city highways in some cases cell by cell parameter tuning is performed to find
most optimal value between 0s and 2s but typically 1s is optimal value when workload is considered as well
Highways, fast moving UEs must reselect correct cell typically 1s works the best (however occasionally also 0s
might be needed in fast speed outdoor to indoor cell reselections e.g. tunnels)
Rural areas, slow or fast moving UEs need very often reselect between different RATs and make proper cell
reselections even when the coverage is poor typically 1s works the best
Location Area Borders, usually the coverage is fairly poor typically 1s works the best but sometimes to reduce
location area reselection ping pong 1s is used when going from LA1 to LA2 and 2s from LA2 to LA1

IRATHO

IRATHO
As M1013 described in PartI, M1015 return statistic for intesystem HO. The filtering criteria
can be replicated with the exception of ping-pong
Filtering criteria:
Major
- High number of failures for a defined out-going adjg (failure ADJG)
- high number of fail for a defined source (failure WCEL)
Minor
- very low number of attempt with failure (low used adjg)
- zero number of attempt for declared adjs stabilized value (no adjg)
- high number of attempts for an out-going adjs (unbalanced ADJG)
out-going condition is sufficient
- high number of attempts for a defined source (unbalanced WCEL)

Same procedures can be applied to the case considering that the event related are 1E and 1F

e.g. P-CPICH Ec/No

1E/1F Events for CPICH Ec/No and RSCP


HHoEcNo(RSCP)Thres
hold

HHoEcNo(RSCP)Cancel
Cell 1

Defines the threshold of Ec/No(RSCP)


that must be exceeded by a measurement
of an active set cell to be canceled the
event 1F related

Cell 2

determines the absolute CPICH


Ec/No threshold which is used by the
UE to trigger the reporting event 1F.
When the measured CPICH Ec/No of
all active set cells has become worse
than or equal to the threshold in
question, the RNC starts interfrequency or inter-RAT (GSM)
measurements in compressed mode
for the purpose of hard handover.

Cell 3
1F
1E

HHoEcNo(RSCP)CancelTime

determines the time period during which the CPICH


RSCP of the active set cell must stay better than the
threshold HHoRscpCancel before the UE can trigger the
reporting event 1E.

time
HHoEcNo(RSCP)TimeHysteresis

determines the time period during which the CPICH Ec/No of the active
set cell must stay worse than the threshold HHoEcNoThreshold before
the UE can trigger the reporting event 1F.

IRATHO Triggering reason


1. Low measured absolute
CPICH Ec/No, event 1E/1F

2 . Low measured absolute


CPICH RSCP, events 1E/1F

FMCG: GSMcauseCPICHEcNo

FMCG: GSMcauseCPICHrscp

Triggering reason gives


3. UE Tx power approaches
its maximum allowed
power, event 6A/6D

an indication
4. DL DPCH approaches its
maximum allowed power
FMCG: GSMcauseTxPwrDL

FMCG: GSMcauseTxPwrUL

5. Quality deterioration report


from UL outer loop PC
FMCG: GSMcauseUplinkQuality

6 . Others
- Load and Service based HO
- IMSI based HO
- Emergency ISHO

GSMcauseX
These parameters indicates whether a handover to GSM caused by low measured absolute CPICH Ec/No of the serving cell is
enabled (1)

IRATHO Triggering reason


Its important to know which is the most frequent triggering reason:
Its possible to diffentiate between quality and coverage reasons and understand the
network limiting factors:
1.

CPICH coverage

2.

Pilot pollution

3.

UL/DL Service coverage

In actual case is possible to dsciminate between low CPICH coverage triggered by high# RSCP
attempts or probable pilot pollution triggered by high # Ec/No attempts
A KPI that gives reason for that is

xxx _ Cause _ perc

IS _ HHO _ W _ CMOD _ xxx _( N ) RT


IS _ HHO _ W _ CMOD _ xxx _( N ) RT

Allcauses
Allcauses

IRATHO Triggering reason


Enabling all the causes a screaning on the network is returned individuating the limiting factor
and the required action.
Start

Yes
High # Ec/No?

DL interference/ Pollution
should be evaluated

DL Qual limiting

DL
Yes
High # RSCP?

CPICH power analisys/ new


site required

DL level limiting

Yes
High # UE

New site required or new

UL level limiting

Tx pwr?

Parametrization for IRATHO

UL
Yes
High # UL Qual?

UL qual limiting

Load analisys and UL


interference evaluation

Service limiting

New planning for service is


required

End
Yes
High # DL
DPCH?

This condition
should be the
dominannt one
without
associated
failure

IRATHO - Failure
UE

Node B

CN

RNC
RRC: Measurement Control
ISHO triggering
(5 reasons are
possible)

RRC: Measurement Report

Failure can happen


at different point:

NBAP: Radio Link Reconfiguration Prepare


NBAP: Radio Link Reconfiguration Ready
NBAP: Radio Link Reconfiguration Commit
RRC: Physical Channel Reconfiguration

Initial
Compressed
Mode
Configuration

Before decision
- Before CM
- During CM

RRC: Physical Channel Reconfiguration Complete


NBAP: Compressed Mode Command
RRC: Measurement Control
RRC: Measurement Report

GSM RSSI
Measurement

- Measuring GSM
cell
After decision

RRC: Cell Change Order from UTRAN


RANAP: SRNS Context Request

RANAP: SRNS Context Response


RANAP: SRNS Data Forward Command
RANAP: IU Release Command
RANAP: IU Release Complete

- Drop
Utran and ue have to
treated as particular
case

CM not possible
UE
UE

RNC
RNC

BTS
BTS

AC is responsible for checkiing if CM is possiblle

RRC: Measurement Control


RRC: Measurement Report (3,4,5)

If CM fails one of the following mus be checked:


Admission
Admission Control
Control
check
check for
for CM
CM

Not enough resources AC reject CM.


Evaluate interference
Expand capacity
(see PartI)
The following KPI gives an indication of the number of CM
procedure not started

NBAP: Radio Link Reconfiguration Prepare


NBAP: Radio Link Reconfiguration Ready
NBAP: Radio Link Reconfiguration Commit
RRC: Physical Channel Reconfiguration
RRC: Physical Channel Reconfiguration Complete
RX Level measurement phase for
all ISHO neighbours

RRC: Measurement Control

RRC: Measurement Report

BSIC verification phase for target cell

IS_COM_MOD_STA_NOT_P OS
IS_COM_MOD_STA_NOT_P OS IS_HHO_W_CMOD jj

NBAP: Compressed Mode Command

NBAP: Compressed Mode Command


RRC: Measurement Control

RRC: Measurement Report

jj

Considering that M1010C2 (INTER SYST COM MOD STA NOT POS FOR RT) is updated if it is
not possible to start inter-system compressed mode measurement due to radio resource
congestion, BTS- or UE-related reasons to have a better insight on radio congestion it could
be better to use, e.g. for UL the M1002C361 REQ FOR COM MODE UL REJECT TO INT SYST
HHO IN SRNC and the M1002C357 REQ FOR COM MODE UL TO INT SYST HHO IN SRNC and
use the following :
M1002C361/M1002C357

NO Cell Found

measurement
failNo Cell Found
Counters

NO Cell Found means:


there is no suitable gsm target cell in terms of RX Level
OR

Compressed
Mode start

the target gsm is suitable but its BSIC verification fails


AND
the maximum number of measurement reported are received
AND

HHO Attempt
Counters

measurement
not fail

maximum measurement interval is not expired


The following KPI gives an indication of the number of GSM cell not found

ISHO _ Meas _ Fail _ Rate

IS _ HHO _ NO _ CELL _ xxx _( N ) RT


IS _ HHO _ W _ CMOD _ xxx _( N ) RT

Allcauses
Allcauses

Allcauses
Allcauses

Missing ADJG could be the reason or a dedicated parameter tuning for the 1F event.
The KPI can be madified taling care of the WO_CMOD events

NO Cell Found
Start

High #
End

NO Cell?
Yes
Yes
GSMCause=Ec/
Nol?

New site

Good GSM coverage


in the far field?

Verify
ADJG

ADJG
Addition?

Yes

required

Pollution evaluation

Coverage anlisys

Good GSM coverage


in the near field?

Yes

End

Reduce
thershold

Reduce Cancel
Increase Time hysteresis

DROP & UNSUCCESS IRATHO


UTRAN Failure
Counter

Optimization for unsuccess is not possible


because the reason are:
- physical channel failure (the UE is not able to
establish the phy.
- Protocol error

UE Failure
Counter

HHO Attempt
Counters

ISHO Unsuccess
Counters

- Inter-Rat protocol error


- Unspecified
Drop are related to drop call occurred
during the procedure

ISHO _ Drop _ Rate

CON _ DRPS _ IS _ HHO _ xxx _( N ) RT


IS _ HHO _ ATT _ xxx _( N ) RT

Allcauses
Allcauses

Allcauses
Allcauses

ISHO Success
Counters

RRC Drop
Counters

In this case the optimization is required and


pass through the evaluate of GSM and 3G plot
coverage. Optimize If necessary number of
ADJG or NWP parameters otherwise tune
RNW parameters.
Thresholds can be relaxed to favourite an
early exit from 3G layer

3G > 2G Unbalancing
This topic present the inherent problem due to the fact that the 2G layer is not involved in
the analisys.
Few consideration can be performed under some assumption:
The following KPIs used over a cluster for CS voice service gives the percentage of the CM
started over all the RAB, giving an idea of the attempted mobility procedure requested for a
cluster where the 3G coverage should be assured

Perc _ Voice _ Call _ ISHO

IS _ HHO _ ATT _ xxx _ RT

Allcauses
Allcauses

RAB _ ACC _ COMP _ CS _ VOICE

Better to use completes: failures, normal & SRNC reloc on denominator and use the KPI inside the
3G cluster or difining a polygon where 3G service is required

Once Correlated with voice drop due to radio link failure and rrc drop during ISHO, the KPI can
help operator in understand the ISHO strategy. Similar KPI is possible for PS
Threshold to shrink the HO area or inhibit the procedure has to be setted

You might also like