Uploaded by Pascal Mkoba

dokumen.tips part-3-optimization-3g

advertisement
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
5. Matching failure
distribution in the
network topology
(rural, RNC
border,
expressway)
4. Prioritize
analysis
1. Assess weekly average
PLMN KPI performance to
identify KPIs below targets
2.
Assess
network
performance at
RNC/Area level
to check if bad
performance
happens across
network or only
particular
RNC/Area
•Start from bigger picture assessment
(PLNM -> RNC -> Cluster -> WCEL )
•Weekly average will smooth the
performance and gives better
accuracy of performance assessment •Compare different
as daily performance varies a lot
RNC/Regions
especially in unloaded network
performance
Presentation / Author / Date
3. Apply drill down
approach to assess
bad performing KPIs
in WCEL level
•Identify the failure call
phases
•Categorizing failure ratio or
distribution of each counters
(radio, AC, transmission,
BTS, RNC)
•Identify main cause of
underperforming KPIs
•Filter using high number
of failures or high number
failure ratio (weighting)
•Identify top 50 worst cells
Traffic Monitoring
Transmitted
carrier power
Channel
element
allocation
Received total
wideband
power
Code tree
allocation
Iub
transmission
RNC
processing
load
Number of
users
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
Throughput
CNBAP
DNBAP
AAL2 or IP SIG
User Plane
Connectivity
Unit Load
DSP Usage
User Plane
Both interfaces and internal resources of
WCDMA network should be monitored
SS7 (RANAP)
Iub Interface
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
Low adjacent cell
interference
i-factor
Noise rise due to
real traffic
PrxOffset
e.g. 1 dB above PrxTarget
-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)
-106 dBm
Receiver noise figure (e.g. 2 dB)
-108 dBm
Thermal noise -108 dBm
Total UL power - role of BTS commissioning
RTWP measured by BTS 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
Still below BTS
receiver noise
Check HW
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 - re-arrangement
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
1
2
3
4
5
6
……….
R99 + HSPA signaling CH
7
8
9
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
1
32 K data
2
64 K data
4
128 K data
4
256 K data
9
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
1
32 K data
2
64 K data
4
128 K data
4
256 K data
6
384 K data
8
High CE occupation - optimization flow
High CE
occupation
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
Traffic Monitoring
Principles
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
Path Measurements
Even maximum
reserved bandwidth
far below
configured
bandwidth
2 Free
VCs with
8250 (ATM) cells
per second
per VC
on 1 IMA group
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
Traffic Monitoring
Principles
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
Phase:
Setup
Active
Active
Complete
Access
Complete
Attempts
Access
Setup
Complete
Access
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
RAB active phase
UE has RAB connection
RRC
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
[RACH]
RRC Connection Setup
phase
RNC
RRC Connection Request
AC to check to accept
or reject RRC
Connection Request
NBAP RL Setup Request
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
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
RRC Connection Setup
phase
NBAP RL Setup Request
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 preemption (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 ?
Traffic
Audit adjacent sites for alarms,
Availability, configuration and
capacity
YES
NO
Configuration &
Parameter audit
SHO based on
DSR, CPICH
EcNo
difference,
SHO branch
setup fail
BTS/Iub
Conf OK ?
3G Cell at RNC
border?
YES
SHO
Success
Rate < 90%?
SHO
YES
NO
ISHO
Failures
ISHO
HHO RSSI &
BSIC time,
ISHO
cancellation
YES
New site ?
Analyse last detailed
radio measurements
NO
RF and IFHO neighbour
optimisation
3G cell covers
over a coverage
hole ?
3G cell at interRNC border ?
No cell found
ratio >40 %
Investigation Iur
Relocation success in
target RNC
YES
Top
issu
es
Iur
performance
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
Low used Adjs
Yes
No Adjs
Yes
Yes
Zero
attempts?
In – out
pairs?
High # fails for
a source?
High #
attempts for
a source?
Yes
Ping-Pong
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
Target_cell_A
Attempt
Fail
2
1
1
0
Source_cell_A
Source_cell_B
…
Source_cell_Z
322
Target_cell_B
Attempt
Fail
23
1
11
0
54
15
Target_cell_C
Attempt
Fail
442
34
53
25
0
2
0
…
Target_cell_Z
Attempt
Fail
4
0
345
0
12
0
Failure ADJS
Analyze RSCP from DT
& NWP coverage plot
considering inter-site
distance
Very low value of
RSCP that not
allow the adjs to be
used
Yes
Target act
as polluter?
Once anlyzed the RSCP, the
coverage plot taking care to
the evaluation of intersitedistance, it is easy to
understand if target can be
used.
Down tilt
possibile?
Yes
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.
Analyze Ec/No from DT
Ec/No offset
DERR cell
Down tilt
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
Reporting
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
Reportin
g 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
Source_cell_A
Source_cell_B
…
Source_cell_Z
Failure WCEL
Target_cell_A
Attempt
Fail
2
1
1
0
322
1
Target_cell_B
Attempt
Fail
23
15
11
0
15
0
Target_cell_C
Attempt
Fail
442
34
53
0
2
…
Target_cell_Z
Attempt
Fail
124
23
345
0
0
12
0
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 to the sum of
active set measurement
P CPICH 3
results (<>0)
P CPICH 2
1A
AdditionTime
defines the 'time-totrigger' interval
between the cell
entering the reporting
range and the UE
sending the
measurement report
to the RNC with the
1A event
Measurement
Report
no
Add to
the AS?
RNC
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
AS has 3 cells
Ec/Io
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 + ReplacementWindow / 2
P CPICH 1
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 monitored cell (event 1C).
time
ReplacementReportingInterval
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.
no
Measurement
Report
AS
update?
RNC
NO ADJS
Source_cell_A
Source_cell_B
…
Source_cell_Z
Target_cell_A
Attempt
Fail
2
1
0
322
1
Target_cell_B
Attempt
Fail
0
11
0
15
0
Target_cell_C
Attempt
Fail
442
34
53
0
2
0
…
Target_cell_Z
Attempt
Fail
124
23
345
0
12
0
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
Source_cell_A
Source_cell_B
…
Source_cell_Z
Target_cell_A
Attempt
Fail
2
1
245
23
322
1
Target_cell_B
Attempt
Fail
25
4
11
0
3
Target_cell_C
Attempt
Fail
442
34
53
0
1
2
1
…
Target_cell_Z
Attempt
Fail
124
23
345
0
123
Analyze DT
result and
NWP data
It is not difficult in live network to find some pair
working with very low
Yes
ADJ Offset
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?
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.
Yes
Interference
evaluation
Remove ADJS
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
20
Unbalanced ADJS
Source_cell_A
Source_cell_B
…
Source_cell_Z
Unbalance ADJS
Target_cell_A
Attempt
Fail
54
3
25
1
32
2
Analyze RSCP from DT & NWP
coverage plot considering intersite distance e traffic
distribution
No action
required
Yes
Ec/No offset
45
…
Target_cell_Z
Attempt
Fail
124
5
2
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.
Yes
Analyze Ec/No from DT
& evaluate unbalance
Target_cell_C
Attempt
Fail
23
1
137
3
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?
Target act
as polluter?
Target_cell_B
Attempt
Fail
345
10
11
0
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
Source_cell_A
Source_cell_B
…
Source_cell_Z
Analyze RSCP from DT & NWP
coverage plot considering
inter-site distance and traffic
distribution
Attempt over
the same UE?
No action
required
Yes
Yes
Interference /
pollution
WCEL interfered
polluted?
Target_cell_A
Attempt
Fail
543
13
25
1
32
2
Target_cell_B
Attempt
Fail
345
10
11
0
Target_cell_C
Attempt
Fail
876
7
137
3
45
…
Target_cell_Z
Attempt
Fail
124
5
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.
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.
The optimization should be performed at WCEL
level
Yes
KPI(1) ?
Tune 1A
Yes
KPI(2) ?
Tune 1C
The KPI reported are the same of Failure
WCEL
Ping Pong
Down tilt
DERR cell
Ping-pong
Yes
pollution
32
No action
required
Attempt from
the same UE?
Yes
Filtering
Target_cell_C
Attempt
Fail
23
1
137
3
45
…
Target_cell_Z
Attempt
Fail
124
5
2
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.
One of them act
as polluter?
Comparable
value?
Yes
Histeresys
using
Ec/NoOffset
on the pair
In this particular case the high number
of attempt is concentrated in a pair
From A >> B and from B >>A as in the
picture
Analyze Ec/No from DT
Not stable,
Fading?
2
Target_cell_B
Attempt
Fail
345
10
11
0
Down tilt
possibile?
Yes
Analyze RSCP from DT &
NWP coverage plot
considering inter-site
distance
Source_cell_A
Source_cell_B
…
Source_cell_Z
Target_cell_A
Attempt
Fail
54
3
987
13
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 sub-state
System Information [ ]
UTRAN
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
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
Target_cell_A
Attempt
Fail
Source_cell_A
2
1
Source_cell_B
245
23
…
Source_cell_Z
322
1
Target_cell_B
Attempt
Fail
25
4
11
0
3
1
Target_cell_C
Attempt
Fail
0
53
0
0
-
…
Target_cell_Z
Attempt
Fail
124
23
345
0
123
20
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
Source_cell_A
Source_cell_B
…
Source_cell_Z
Target_cell_A
Attempt
Fail
2
1
245
23
Target_cell_B
Attempt
Fail
25
4
11
0
Target_cell_C
Attempt
Fail
26
3
53
0
…
…
245
45
…
Target_cell_Z
Attempt
Fail
124
23
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_I N_ACT_SET_ RT  M1007C19 ONE_CELL_I N_ACT_SET_ NRT



 M1007C1 TWO_CELL_I N_ACT_SET_ RT  M1007C20 TWO_CELL_I N_ACT_SET_ NRT   2 

 M1007C2 THREE_CELL _IN_ACT_SE T_RT  M1007C21 THREE_CELL _IN_ACT_SE T_NRT   3 

 1 100%
 M1007C0 ONE_CELL_I N_ACT_SET_ RT  M1007C19 ONE_CELL_I N_ACT_SET_ NRT



 M1007C1 TWO_CELL_I N_ACT_SET_ RT  M1007C20 TWO_CELL_I N_ACT_SET_ NRT 

 M1007C2 THREE_CELL _IN_ACT_SE T_RT  M1007C21 THREE_CELL _IN_ACT_SE T_NRT



Cell Reselection
Cell Reselection 2G -> 3G
Start
measurement
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 operator´s 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
0
1
…
6
7
8
9
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
0
1
2
3
…
8
…
14
15
dBm
Always
-28
-24
-20
…
0
…
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
4
3
2
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
Serving WCDMA cell
calculation, with
hysteresis parameter
Neighbour WCDMA or GSM
cell calculation with offset
parameter
SsearchRAT
qQualMin
No
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
1E/1F Events for CPICH Ec/No and RSCP
HHoEcNo(RSCP)Thres
hold
e.g. P-CPICH Ec/No
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
time
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.
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
6 . Others
- Load and Service based HO
- IMSI based HO
- Emergency ISHO
FMCG: GSMcauseUplinkQuality
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
It’s important to know which is the most frequent triggering reason:
It’s 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
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
Parametrization for IRATHO
Tx pwr?
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
RNC
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 Control
check for 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
NBAP: Compressed Mode Command
RRC: Measurement Control
RRC: Measurement Report
NBAP: Compressed Mode Command
BSIC verification phase for target cell
RRC: Measurement Control
IS_COM_MOD_STA_NOT_P OS
IS_COM_MOD_STA_NOT_P OS   IS_HHO_W_CMOD j
RRC: Measurement Report
j
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
fail
No 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
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
Optimization for unsuccess is not possible
because the reason are:
UTRAN Failure
Counter
- physical channel failure (the UE is not able to
establish the phy.
- Protocol error
UE Failure
Counter
- Inter-Rat protocol error
- Unspecified
Drop are related to drop call occurred
during the procedure
HHO Attempt
Counters
ISHO Unsuccess
Counters
ISHO _ Drop _ Rate 
 CON _ DRPS _ IS _ HHO _ xxx _( N ) RT
 IS _ HHO _ ATT _ xxx _( N ) RT
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
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
Download