Vous êtes sur la page 1sur 45

Ericsson Internal

SERVICE DELIVERY INSTRUCTION 1 (45)


Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

LTE KPI Optimization Guideline - Accessibility

1 VERSION HISTORY................................................................................................................................................................. 3
2 LTE ACCESSIBILITY KPIS.......................................................................................................................................................... 4
3 LTE ACCESSIBILITY PROCEDURES............................................................................................................................................ 5
3.1 Random Access (TBC)..................................................................................................................................................................5
3.2 RRC Connection Establishment...................................................................................................................................................5
3.3 S1 Signaling Connection Establishment (TBC).............................................................................................................................7
3.4 Initial E-RAB Establishment or E-RAB Addition...........................................................................................................................7
3.5 Main Parameters for Accessibility..............................................................................................................................................8
4 RANDOM ACCESS FAILURE HANDLING................................................................................................................................... 8
5 RRC SETUP FAILURE HANDLING............................................................................................................................................. 9
5.1 Capacity.....................................................................................................................................................................................11
5.1.1 Connected User License (CUL)...........................................................................................................................................11
5.1.2 Lack of Resource (SR).........................................................................................................................................................12
5.1.3 Processor Load (MP Load).................................................................................................................................................13
5.2 Radio..........................................................................................................................................................................................14
5.2.1 Interference.......................................................................................................................................................................15
5.2.2 Overshooting.....................................................................................................................................................................16
5.2.3 Low Signal..........................................................................................................................................................................17
5.3 Hardware...................................................................................................................................................................................17
5.3.1 Hardware Alarms..............................................................................................................................................................17
5.3.2 Cell Availability..................................................................................................................................................................18
5.4 Other Causes.............................................................................................................................................................................18
5.4.1 MME Overload..................................................................................................................................................................18
5.4.2 Admission..........................................................................................................................................................................18
5.4.3 RRC Storm..........................................................................................................................................................................19
6 S1 ESTABLISH FAILURE HANDLING....................................................................................................................................... 20
7 E-RAB ESTABLISH FAILURE HANDLING................................................................................................................................. 20
7.1 Capacity.....................................................................................................................................................................................22
7.1.1 License Reject....................................................................................................................................................................22
7.1.2 GBR Overload....................................................................................................................................................................22
7.2 Radio..........................................................................................................................................................................................23
7.3 Hardware...................................................................................................................................................................................23
7.4 Other Causes.............................................................................................................................................................................23
8 ACCESSIBILITY FURTHER INVESTIGATION............................................................................................................................. 23
8.1 Trace (CTR/UETR)......................................................................................................................................................................23
8.2 Drive Test..................................................................................................................................................................................24
9 REFERENCE CASES............................................................................................................................................................... 25
9.1 RRC Setup Failure......................................................................................................................................................................25
9.1.1 Case1: Due to Connected User License.............................................................................................................................25
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 2 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

9.1.2 Case2: Lack of Resource (SR).............................................................................................................................................25


9.1.3 Case3: High Load...............................................................................................................................................................27
9.1.4 Case4: Uplink Interference due to HW issue.....................................................................................................................30
9.1.5 Case5: Weak Coverage......................................................................................................................................................33
9.1.6 Case6: Due to one UE by CTR analysis...............................................................................................................................35
9.2 E-RAB Establishment Failure.....................................................................................................................................................36
9.2.1 Case1: E-RAB Failure Due to Interference.........................................................................................................................36
9.2.2 Case2: E-RAB failure due to encryption.............................................................................................................................39
10 APPENDIX......................................................................................................................................................................... 41
10.1 Traffic Offload.........................................................................................................................................................................41
10.1.1 Parameter........................................................................................................................................................................41
10.1.2 Load Balance...................................................................................................................................................................43
10.1.3 Physical............................................................................................................................................................................45
10.2 Reference................................................................................................................................................................................45
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 3 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

1 Version History

Revision Owner Reviewer Date Change

Draft Shawn He 2016-02-26 Structure


PA1 Shawn He 2016-04-01 First Preliminary Version
PA2 Shawn He 2016-04-06 Add Key Parameters
Miffy Meng
Rev.A Shawn He 2016-04-08 First Release
Peng Ren

This document is intended for new NDO employees who have basic LTE
knowledge about theory and optimization. It is enriching existing LTE Root Cause
Analysis as in the reference [1].
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 4 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

2 LTE Accessibility KPIs


Accessibility for the EUTRAN is a measure of the ability of a user to obtain an E-
RAB from the system. The initial E-RAB establishment process can be divided
into the following phases:

• RRC Connection Establishment

• S1 Signaling Connection Establishment

• Initial E-RAB Establishment or E-RAB Addition

pmRrcConnEstabSucc
RRC Setup Successful Rate = × 100%
pmRrcConnEstabAtt − pmRrcConnEstabAttReatt

pmS1SigConnEstabSucc
S1 Setup Successful Rate = × 100%
pmRrcConnEstabSucc

pmErabEstabSuccInit
Initial ERAB Setup Successful Rate = × 100%
pmErabEstabAttInit

The ‘Added E-RAB Establishment Success Rate [%]’ KPI formula which
measures the success rate of subsequently added E-RABs of all QCI types and
the ‘Added E-RAB Establishment Success Rate, QCI [%]’ KPI formula which
measures subsequently added E-RABs of particular QCI types are also
illustrated in above.

pmErabEstabSuccAdded
Added E − RAB Establishment Success Rate [ % ] = ×100%
pmErabEstabAttAdded
Performance Indicators for each of these phases are usually combined to create
the ‘Initial E-RAB Establishment Success Rate [%]’ KPI which measures all QCIs
and the ‘Initial E-RAB Establishment Success Rate, QCI [%]’ KPI which is used
to measure a particular QCI as illustrated in below.
Initial E-RAB Establishment Success Rate [%]:

= RRC Setup Successful Rate × S1 Setup Successful Rate × ERAB Setup Successful Rate
RRC Success S1 Sucess ERAB Sucess
= × × ×100%
RRC Attempts − RRC Re attempts S1 Attempts ERAB Attemps
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 5 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

3 LTE Accessibility Procedures


3.1 Random Access (TBC)

3.2 RRC Connection Establishment


When the UE receives a paging message (Idle mode UE), has changed Tracking
Area, or is going to set up a session, it needs to set up a signaling connection
with the core network. This is initiated with an RRC Connection Establishment
procedure. The RRC Connection is a dedicated connection used for control
signaling between the EUTRAN and one UE. It comprises the connection
between the UE and the EUTRAN including all the resources, i.e. L1, L2 and L3.
Before a signaling exchange can occur, a radio bearer is needed. The radio
bearer available for transmission of RRC messages is defined as Signaling Radio
Bearer (SRB). The EUTRAN supports SRB 0, 1 and 2.

The RRC connection establishment procedure begins with the UE sending ‘RRC
CONNECTION REQUEST’ message to the RBS using SRB 0. On reception of
this message the ‘pmRrcConnEstabAtt’ counter is incremented as illustrated
below. The ‘pmRrcConnEstabAttReatt’ counter is incremented for all ‘RRC
CONNECTION REQUEST’ messages received while an RRC Connection Setup
is already ongoing for the same S-TMSI.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 6 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

RRC setup main flow is described as below.

pmRrcConnEstabFailMpOverload +
Random access or
pmRrcConnEstabFailDuIntens +
or
pmRrcConnEstabFailCellIntensDLC +
or
RRC connection setup is triggered High Load or pmRrcConnEstabFailCellIntensStat +
by RRC connection request message Overload? or
pmRrcConnEstabFailCellLatency +
or
pmRrcConnEstabFailDynUeAdmCtrl +
pmRrcConnEstabAtt +

RAC-BB signal
pmRrcConnEstabAttEm + pmRrcConnEstabFailMISigQCong +
pmRrcConnEstabAttHpa +
queue congestion?
pmRrcConnEstabAttMta +
pmRrcConnEstabAttMos +
pmRrcConnEstabAttMod +

pmRrcConnEstabFailMmeOvlMos +
MME Overload? or
RRC connection setup MO signaling/data pmRrcConnEstabFailMmeOvlMod +
N
already ongoing for the
same S-TMSI or Random
Value?

Y
RRC connection
pmRrcConnEstabAttReatt +
rejected?

pmRrcConnEstabAttReattEm +
pmRrcConnEstabAttReattHpa +
pmRrcConnEstabAttReattMta + pmRrcConnEstabSucc +
pmRrcConnEstabAttReattMos +
pmRrcConnEstabAttReattMod +

pmRrcConnEstabSuccEm +
Check with license control
pmRrcConnEstabSuccHpa +
pmRrcConnEstabSuccMta +
pmRrcConnEstabSuccMos +
N pmRrcConnEstabSuccMod +
Connected users license
pmRrcConnEstabSuccDta +
exceeded or hard limit
pmRrcConnEstabSuccGummeiNative +
reached?

Y
pmRrcConnEstabFailLic +
End RRC connection setup
pmRrcConnEstabFailLicActiveUsers +
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 7 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

3.3 S1 Signaling Connection Establishment (TBC)

3.4 Initial E-RAB Establishment or E-RAB Addition

After successful authentication and security mode procedures the MME will send
the ‘INITIAL CONTEXT SETUP REQUEST’ to the RBS which includes a list of E-
RABs to be setup as illustrated below. The ‘pmErabEstabAttInit’ PEG counter is
incremented for all E-RABs in the list of E-RABS to be set up and the
‘pmErabEstabAttInitQci’ PDF counter keeps track of keeps track of the number of
E-RABs requested for each QCI value.

The MME can add additional E-RABs to the connection by sending the ‘E-RAB
SETUP REQUEST’ message to the RBS which also includes a list of E-RABs to
be setup as illustrated in the figure below. The ‘pmErabEstabAttAdded’ PEG
counter is stepped for each E-RAB received in the list of E-RABs to be setup and
the ‘pmErabEstabAttAddedQci’ PDF counter keeps track of the number of
ERABs requested for each QCI value.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 8 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Please refer to reference “flowcharts for counters” for detailed counters


mechanism in ALEX.

3.5 Main Parameters for Accessibility

Parameter Description
First root sequence number for RACH preamble generation
rachRootSequenc e RACH root sequence is broadcast as a part of system information distribution and used for preamble detection. For
information on the definition of logical root sequence number, see 3GPP TS 36.211.
cellRange Defines the maximum distance from the RBS where a connection to a UE can be setup or maintained, or both
cfraEnable This parameter is used to enable or disable the CFRA
Initial preamble power value in dBm, according to 3GPP TS 36.331 and 36.321.
preambleInitialReceivedTargetPower
Default value recommended.
qRxLevMin Required minimum RSRP level in the E-UTRA cell.Corresponds to parameter Qrxlevmin in 3GPP TS 36.304
Offset to Qrxlevmin taken into account at periodic search for a higher priority PLMN.Corresponds to parameter
qRxLevMinOffset
Qrxlevminoffset in 3GPP TS 36.304
Maximum UE power to be used in the cell.If absent, the UE applies the maximum power based on UE capability. Corresponds
pMaxServingCell
to parameter PEMAX in 3GPP TS 36.101
qQualMin Required minimum quality level (RSRQ) in the E-UTRA cell.Corresponds to parameter QqualMin in TS 36.304
Offset to QqualMin taken into account at periodic search for a higher priority PLMN.Corresponds to parameter
qQualMinOffset
Qqualminoffset in TS 36.304
qHyst Cell reselec tion parameter that defines the hysteresis value in the c ell ranking c riteria.
qOffsetCellEUtran Cell individual offset in the intra-frequenc y and equal priority inter-frequenc y cell ranking criteria
qOffsetFreq Frequency spec ific offset in the equal priority inter-frequency c ell ranking criteria
tReselectionEutra Cell reselec tion timer value for an E-UTRA frequenc y
Maximum UE power to be used in neighbor c ells on the E-UTRA frequenc y.If absent, the UE applies the maximum
pMax
UE power for the UE power c lass.
cellReselectionPriority Absolute cell reselec tion priority for the E-UTRA frequenc y or inter-RAT
Threshold for the S rxlev value of the target c ell for cell reselec tion towards a higher priority inter-frequenc y or inter-
threshXHigh
RAT frequenc y
Threshold for the S rxlev value of the target c ell for cell reselec tion towards a lower priority inter-frequency or inter-
threshXLow
RAT frequenc y
Threshold for the S rxlev value of the serving cell, below whic h to UE performs cell reselec tion towards a lower
threshServingLow
priority inter-frequenc y or inter-RAT frequenc y
Threshold for the S qual value of the target c ell for cell reselec tion towards a higher priority inter-frequency or inter-
threshXHighQ
RAT frequenc y
Threshold for the S qual value of the target c ell for cell reselec tion towards a lower priority inter-frequency or inter-
threshXLowQ
RAT frequenc y
Threshold for the S qual value of the serving c ell, below whic h the UE performs cell reselec tion towards a lower
threshServingLowQ
priority inter-frequenc y or inter-RAT frequenc y
tInactivityTimer Time of inactivity on all DRBs before the UE is released
t300 UE timer to supervise a response to RRC Connec tion Request.
UE timer to supervise a response to RRC Connec tion Reestablishment Request 3GPP TS 36.331 during a radio
t301 connec tion re-establishment procedure. The UE returns to Idle and optionally starts to rec onnec t over NAS when
the timer expires.
t304 UE timer to supervise succ essful handover completion according to 3GPP TS 36.331.

UE timer triggered at radio link failure to supervise the period where the UE tries to re-establish the radio
t311 connec tion, either by performing RRC Connec tion Reestablishment in LTE 3GPP TS 36.331, or by finding a suitable
cell on another RAT. The UE returns to Idle and optionally starts to rec onnec t over NAS when the timer expires.

Main parameters related to accessibility are listed as above table. Note that the
3GPP specified timers t3xx must be changed with caution as they severely can
affect KPIs for accessibility and Retainability. The default settings represent best
practice.

4 Random Access Failure Handling


Main possible reasons for Random Access Failure
• Improper RA preamble planning
• Poor RF condition
• High uplink interference
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 9 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

• Sleeping cell

General Optimization Approaches


• For current cell range setting (15km), the parameter “rachRootSequence”
should be differed at least 10 between any two neighbors
• The feature “Automated RACH Root Sequence Allocation” is helpful
• Check for poor RF conditions. Increase the coverage area by
adjusting Tilt/Azimuths of self/neighbor sites
• If UL interference, please refer to interference guideline for detail
• Sleeping cell is hard to detect. When there are many RA attempts
without successes (high pmRaFailCbraMsg2Disc), the cell is
suspected a sleeping one. Try to lock/unlock the cell, or restart

5 RRC Setup Failure Handling


The main failure reasons for RRC setup can be summarized as below three
aspects.

Capacity Radio Hardware

Below brief flow chart for RRC failure classification:


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 10 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Parameters
Check

Check Failure
PM Counters

C. R. H?

Hardware Radio Capacity

Interference License

Overshooting Lack of resource

Signal Low Load of MP

Main RRC failure PM counters


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 11 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Counter Description Type


The total number of failed RRC Connection
pmRrcConnEstabFailLic Establishments due to lack of connected users
license. PEG
Total number of failed RRC Connection
pmRrcConnEstabFailLicActiveUsers Establishments as valid user license limit is
exceeded. PEG
pmRrcConnEstabFailHighLoad
The total number of failed RRC Connection
Establishments due to high load. PEG
pmRrcConnEstabFailOverload
The total number of failed RRC Connection
Establishments due to cell overload PEG
The total number of failed RRC Connection
pmRrcConnEstabFailMmeOvlMod Establishments with Establishment cause Mobile
Originating Data due to MME overload. PEG
The total number of failed RRC Connection
pmRrcConnEstabFailMmeOvlMos Establishments with Establishment cause Mobile
Originating Signaling due to MME overload PEG
The total number of failed RRC Connection
pmRrcConnEstabFailMISigQCong Establishments due to RAC-BB signal queue
congestion PEG
The total number of failed establishment of RRC
pmRrcConnEstabFailBearerAdmissionRej Connection due to the fact that all the UE's bearers
are rejected during bearer admission. PEG
pmRrcConnEstabFailFailureInRadioProcedure
The number of failed RRC establishments due to
failed radio procedure PEG
pmRrcConnEstabFailLackOfResources
The number of failed RRC establishments due to lack
of resources PEG
pmRrcConnEstabFailUnspecified
The number of failed RRC establishments due to
unspecified cause PEG

Note: the last three counters are based on internal events and from ENIQ
database. If ENIQ is not available, CTR event “INTERNAL_PROC_RRC_CONN_SETUP”
may be needed to check.

5.1 Capacity

5.1.1 Connected User License (CUL)

PM Counter “pmRrcConnEstabFailLic” is usually used to check the total number of


failed RRC Connection establishments due to lack of connected users license.

Further verify through the following steps:

Step1. Check Connected User License: licenseCapacityConnectedUsers

Step2. Check below actual Connected User counters


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 12 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Capacity license utilization


pmLicConnectedUsersDistr
PDF counter
Actual percentile of the
pmLicConnectedUsersActual
Capacity license utilization
Capacity Feature License
pmLicConnectedUsersTimeCong
Time Congestion
Maximum use of the
pmLicConnectedUsersMax
Connected Users License
Average number of pmLicConnectedUsersLevSum/pmLicConnecte
Connected Users dUsersLevSamp

Normally, it can be found that actual CUs have reached the CUL capacity.

The possible solutions are:


• Upgrade the LKF (License Key File), if possible
• Increase qRxLevMin, for instance, from -120 dBm to -110 dBm
• Decrease dlMaxRetxThreshold and ulMaxRetxThreshold
• optimize antenna tilt, azimuth or height of the serving and
neighboring cells
• Traffic offload to neighbors (refer to 10.1)

Reference case

9.1.1 Case1: RRC Failure due to CUL

5.1.2 Lack of Resource (SR)

The ENIQ event counter “pmRrcConnEstabFailLackOfResources” shows the number of


failure RRC setup due to lack of resources, usually it is because of SR
congestion.

Further checking steps as below are recommended.

Step1: Check maximum and average number of RRC users through counters
‘pmRrcConnMax’ and ‘pmRrcConnLevSum’;

Step2: Check SR configuration, ‘noOfPucchSrUsers’, which impacts the available


PUCCH resources directly.

Step3: Check SR congestions, ‘pmPucchSrCqiResCongSr’

The possible solutions are like below.


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 13 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

• Fix Hardware issue or alarms if exists, sometimes restart may be


needed;
• Tune parameters such as: qRxLevMin, tInactivityTimer,
dlMaxRetxThreshold, ulMaxRetxThreshold, noOfPucchCqiUsers,
noOfPucchSrUsers, pdcchCfiMode, etc.
• Antenna optimization (tilt, azimuth, height);
• Retune Tracking Area (TA), to reduce TAU if the site is at the
border of TA meanwhile a lot of mobility happens; or reduce TA
size to decrease paging load;
• Traffic offload to neighbors

Reference case

9.1.2 Case2: Lack of Resource

5.1.3 Processor Load (MP Load)

PM counters pmRrcConnEstabFailHighLoad or pmRrcConnEstabFailOverload reflects the


RRC failure due to processor load.

Since L15B, pmRrcConnEstabFailHighLoad is replaced by the counters


pmRrcConnEstabFailMpOverload and pmRrcConnEstabFailDuIntens, while
pmRrcConnEstabFailOverload is replaced by counters pmRrcConnEstabFailCellIntensDLC,
pmRrcConnEstabFailCellIntensStat and pmRrcConnEstabFailCellLatency.

The main processor (MP) load is continuously measured and sampled every 10
seconds. Each sample is recorded by the ‘pmProcessorLoadDistr’ PDF counter
which can be used to plot the distribution of the MP load like below figure.

The Main Processor Distribution can be used to find the peak MP load in eNodeB
which in the example in the figure above is between 85 and 90%.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 14 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

The further steps for verifying High Load causes are as below.

Step1: Check Hardware alarms

Step2: Check MP Load by ‘pmProcessorLoadDistr’

Step3: Check RRC connections by ‘pmRrcConnMax’, ‘pmRrcConnLevSum’

Step4: Check Data Downlink Volume by ‘pmPdcpVolDlDrb’, ‘pmPdcpVolDlSrb’ and


Uplink Volume by ‘pmPdcpVolUlDrb’, ‘pmPdcpVolUlSrb’

Step5: Check incoming and outgoing handover counts (all relations)

The possible solutions are like below.


• Fix Hardware issue or alarms if exists, sometimes eNodeB restart
may be needed;
• Tune parameters such as: qRxLevMin, tInactivityTimer,
dlMaxRetxThreshold, ulMaxRetxThreshold, noOfPucchCqiUsers,
noOfPucchSrUsers, pdcchCfiMode, etc.
• Antenna optimization (tilt, azimuth, height);
• Retune Tracking Area (TA), to reduce TAU if the site is at the
border of TA meanwhile a lot of mobility happens; or reduce TA
size to decrease paging load;
• Traffic offload to neighbors

Reference case

9.1.3 Case3: High Load

5.2 Radio

The ENIQ counter ‘pmRrcConnEstabFailFailureInRadioProcedure’ counts the number of


RRC failures in the radio procedure.

The following steps are suggested to further verify the cause.

Step1: Check Hardware Alarms

Step2: Check Uplink interference level, i.e. UL RSSI, for all surrounding cells
• ‘pmRadioRecInterferencePwr’, ‘pmRadioRecInterferencePwrPucch’
• ‘pmRadioRecInterferencePwrPrb1~100’
• ‘pmSinrPucchDistr’, ‘pmSinrPuschDistr’
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 15 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Step3: Check Downlink Coverage and SINR (CQI)


• ‘pmRadioUeRepCqiDistr’, ‘pmRadioUeRepCqiDistr2’
• ’ pmBadCovEvalReport’, ‘pmRadioTbsPwrRestricted’, ‘pmBadCovSearchEvalReport’
• RSRP distribution extracted from CTR
• pmTimingAdvance

Note: the feature “pm-initiated UE measurement” can order UE report measurement


periodically. And feature “enhanced Cell-ID in trace” makes it possible to group collect
statistics on TA values
If there is hardware alarm or issue, please go to chapter 5.3.
If there is no hardware alarm or issue, then the corresponding possible solutions
are suggested in the following.

5.2.1 Interference

When high UL RSSI is observed, below scenarios are used as initial


troubleshooting, usually based on PRB level “interference shape”.
• Internal
 Hardware Issue
Typical example is full bandwidth with similar strength, such as:

 Intermodulation or from other RAT


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 16 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

PRB shape example:

• External
The interference can be in full band or parts of, usually all
surrounding cell are suffering.

Solutions:
Increase power control target ‘pZeroNominalPucch’ could be a temporary approach.
For detailed investigation methods, please refer to interference guideline.

5.2.2 Overshooting

According to previous mentioned TA statistics, a cell is suspected overshooting, if


the average TA value or certain percentile (like 5 or 10) of TA value is much higher than
average site distance.

If the ANR feature is activated, there is also another way to evaluate overshooting, that
is, a cell X has been added as neighbor relation by the cells much farther than this cell X’s
average neighbor distance.

Solution:
Tune physical parameters (power, antenna tilt, azimuth, height, etc.)
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 17 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

5.2.3 Low Signal

If the TA statistics of a cell is fine, but the average RSRP/CQI is low, or the
percentage of low RSRP/CQI is high, then it is suspected that this cell has weak
coverage.

Solution:
• Tune physical parameters (power, antenna tilt, azimuth, height,
etc.)
• Power Boosting on PDSCH or Reference Signal
• New sites

Reference case
9.1.4 Case4: Uplink Interference due to HW issue
9.1.5 Case5: Weak Coverage
9.2.1 Case1: ERAB/RRC Failure due to Interference

5.3 Hardware

5.3.1 Hardware Alarms

Hardware issue/alarms might cause different kind of RRC failures, therefore


below common hardware alarms are listed here as reference.

Alarms Probable Cause


Calibration Failure EQUIPMENT_MALFUNCTION
Clock Calibration Expiry Soon CLOCK_SYNCHRONISATION_PROBLEM
Gigabit Ethernet Link Fault LOSS_OF_SIGNAL
RF Reflected Power High EQUIPMENT_MALFUNCTION
HW Fault EQUIPMENT_MALFUNCTION
Link Failure EQUIPMENT_MALFUNCTION
Network Synch Time from GPS Missing CLOCK_SYNCHRONISATION_PROBLEM
Remote IP Address Unreachable UNAVAILABLE
VSWR Over Threshold EQUIPMENT_MALFUNCTION
Please refer to below attached alarms list for detailed alarm explanation.

Al ar ms Li st

Command ‘al’ is used to check current alarms, while ‘lga’ can be used to check
historic alarms.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 18 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

When high VSWR found, the command ‘cabx’ is used to check detailed value.

5.3.2 Cell Availability

If the cell availability is not stable, it will have apparent impact on RRC setup,
actually all KPIs will be affected.

• Cell Down and Lock Automatically


Counted by ‘pmCellDowntimeAuto’ and ‘pmCellDownLockAuto’

• Cell Down and Lock Manually


Counted by ‘pmCellDowntimeMan’ and ‘pmCellDownLockMan’

If the cell down is automatically, usually the support from integration is needed.
Generally, below actions are suggested:

• eNodeB health-check (alarms, configurations, etc.)

• Transport quality check (S1 connection for instance)

5.4 Other Causes

5.4.1 MME Overload

The counters ‘pmRrcConnEstabFailMmeOvlMod’ and ‘pmRrcConnEstabFailMmeOvlMos’


show the number of RRC failures due to MME overload.

It rarely happens, but if it does, check whether the feature “MME Overload
Control” is available and also need to get support from core.

5.4.2 Admission

‘pmRrcConnEstabFailBearerAdmissionRej’ steps for each UE that fails to establish an


RRC Connection due to the fact that the all the UE's bearers are rejected during
bearer admission.

Solution:

Check Admission Control features and traffic offload as chapter 10.1.


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 19 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

5.4.3 RRC Storm

It is usually defined as such, when RRC attempts increase apparently high


compared to normal level, but the accessibility success drops sharply, almost 0 in
most of the cases.

Below approach can be used to detect RRC storm.


• It is possible to detect issue at least 24 hours before
pmRrcConnEstabFailHighLoad is pegged. Ditto RRC Success Rate
degradation
• 99th percentile Processor Load > 10% seems to be a good trigger
• Increases in pmRrcConnEstabAttReatt above “normal” levels are
also an early indicator of an issue (although this can be triggered by
single UE faults as well so it needs to be related to processor load)

RRC Storm fault underlying cause is due to resource hanging that can be
detected early in the Processor Load and increased RRC Re-attempts metrics.
Baseband traces should be run during the “early detection” period to help PLM
find the cause of the hanging resources. Site can be manually restarted to
prevent “RRC Storm”.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 20 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

6 S1 Establish Failure Handling


Main S1 Failure reasons
• Transport issue: normally results in Service Unavailable alarm
• Software error: e.g., “eNB_UE_S1AP_ID” is not recognized by the
MME
• Wrong TAC-LAC mapping: happen during CSFB

Optimization Approaches
• Needs to be investigated and resolved with the help of transport
team
• Lock the ‘TermPointToMme’, wait 5 seconds then unlock the
‘TermPointToMme’
• Restart the eNodeB
• Check the TAC-LAC table, and make sure the mapping is correct

7 E-RAB Establish Failure Handling


The main failure reasons for E-RAB establishment can also be summarized as
below three aspects as RRC setup.

Capacity Radio Hardware


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 21 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

E-RAB Establishment failure handling flow chart:

Parameters
Check

Check Failure
PM Counters

C. R. H?

Hardware Radio Capacity

Interference License

Overshooting GBR

Signal Low Load of MP

E-RAB Failure PM counters


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 22 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Counter Name Description Type

The total number of failed establishment of initial E-RABs due to


license rejects (Multiple Radio Bearer per user or RLC UM). Initial E-
pmErabEstabFailInitLic PEG
RABs are all E-RABs present in the S1 message Initial Context Setup
Request.
The total number of failed establishment of added E-RABs due to
pmErabEstabFailAddedLic license rejects (Multiple Radio Bearer per user or RLC UM). Added E- PEG
RABs are all E-RABs present in S1 message E-RAB Setup Request.
The total number of failed E-RAB setup attempts due to downlink GBR
pmErabEstabFailGbrDlEnb PEG
overload for resources common to the eNodeB.
The total number of failed E-RAB setup attempts due to uplink GBR
pmErabEstabFailGbrUlEnb PEG
overload for resources common to the eNodeB.

7.1 Capacity

7.1.1 License Reject

The counters ‘pmErabEstabFailInitLic’ and ‘pmErabEstabFailAddedLic’ indicate the


number of E-RAB failures for initial E-RAB and added E-RAB respectively.

As the counter description, these failures are due to license reject (Multiple RAB
per user or RLC UM).

Therefore, when it happens, the licenses state of “Multiple RAB per user” and
“RLC UM” need to be checked.

7.1.2 GBR Overload

The counters ‘pmErabEstabFailGbrDlEnb’ and ‘pmErabEstabFailGbrUlEnb’ s the number of


E-RAB failures for downlink GBR overload and uplink GBR overload respectively.

Solution:

• Tune GBR related parameters such as:


dlNonGbrRatio, dlTransNwBandwidth
ulNonGbrRatio, ulTransNwBandwidth

• Traffic Offload as 10.1


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 23 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

7.2 Radio

When UE experience bad RF environment, both RRC setup and E-RAB


establishment are affected.

Please refer to the same procedure as RRC failure due to RF environment in


chapter 4.2.

Reference case

9.2.1 Case1: E-RAB failure due to interference

7.3 Hardware

Please refer to the same content in chapter 5.3.

7.4 Other Causes

In live network, most of the E-RAB failures are usually due to radio condition. But
there are also some other causes, such as UE issue. When abnormal ERAB
failure happens, CTR or UETR is usually used for further investigation, as
chapter 8 describes.

8 Accessibility Further Investigation

8.1 Trace (CTR/UETR)

Cell Trace Record and UE Trace Record are very powerful data source for
problems deeper investigation including accessibility.

The Cell Trace function is used to troubleshoot issues on a particular cell or RBS.
It gives visibility of air interface quality and UE performance of all (or a selected
percentage) of UE within these cells and RBSs.

The UE Trace function enables the network operator to record important events
and measurements for a selected UE, traveling through a network. Only one UE
can be selected for recording for each UE Trace. Up to 16 simultaneous UE
Trace recordings can run in parallel for one RBS. The network operator identifies
the selected UE using the IMSI or IMEI of the UE.

Key events related to accessibility are listed in the below.


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 24 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

pmEvent Name pmEvent Name pmEvent Name


INTERNAL_EVENT_RRC_ERROR INTERNAL_EVENT_ERAB_DATA_INFO S1_INITIAL_CONTEXT_SETUP_FAILURE
INTERNAL_EVENT_RRC_UE_INFORMATION INTERNAL_EVENT_ERAB_RELEASE_DELAYED S1_INITIAL_CONTEXT_SETUP_REQUEST
INTERNAL_PROC_RRC_CONN_SETUP INTERNAL_EVENT_ERAB_ROHC_FAIL_LIC_REJECT S1_INITIAL_CONTEXT_SETUP_RESPONSE
RRC_DL_INFORMATION_TRANSFER INTERNAL_PROC_ERAB_MODIFY S1_UE_CONTEXT_MODIFICATION_FAILURE
RRC_MEASUREMENT_REPORT INTERNAL_PROC_ERAB_RELEASE S1_UE_CONTEXT_MODIFICATION_REQUEST
RRC_RRC_CONNECTION_REJECT INTERNAL_PROC_ERAB_SETUP S1_UE_CONTEXT_MODIFICATION_RESPONSE
RRC_RRC_CONNECTION_RELEASE S1_ERAB_MODIFY_REQUEST S1_UE_CONTEXT_RELEASE_COMMAND
RRC_RRC_CONNECTION_REQUEST S1_ERAB_MODIFY_RESPONSE S1_UE_CONTEXT_RELEASE_COMPLETE
RRC_RRC_CONNECTION_SETUP_COMPLETE S1_ERAB_RELEASE_COMMAND S1_UE_CONTEXT_RELEASE_REQUEST
RRC_RRC_CONNECTION_SETUP S1_ERAB_RELEASE_INDICATION
RRC_SECURITY_MODE_COMMAND S1_ERAB_RELEASE_REQUEST
RRC_SECURITY_MODE_COMPLETE S1_ERAB_RELEASE_RESPONSE
RRC_SECURITY_MODE_FAILURE S1_ERAB_SETUP_REQUEST
RRC_UE_CAPABILITY_ENQUIRY S1_ERAB_SETUP_RESPONSE
RRC_UE_CAPABILITY_INFORMATION
RRC_UE_INFORMATION_REQUEST
RRC_UE_INFORMATION_RESPONSE
RRC_UL_INFORMATION_TRANSFER

Once unsuccessful access happens, the detailed event parameter of these


events can be very helpful for troubleshooting.

Reference case

9.2.2 Case2: E-RAB failure due to encryption

8.2 Drive Test

Sometimes, drive test may be needed in addition to traces, in order to re-cap the
problem. Please refer to below LTE CC/CG drive test related material.

Tools user guide 1

Tools user guide 2

Chapter 5 - Data analysis, in LTE initial tuning technical guideline


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 25 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

9 Reference Cases

9.1 RRC Setup Failure

9.1.1 Case1: Due to Connected User License


pmErabEst pmErabEsta pmRrcConn pmRrcConn pmS1SigCon pmRrcConnE
Date eNodeB SSSR
abAttInit bSuccInit EstabAtt EstabSucc nEstabSucc stabAttReatt
11/24/2014 SKA7399T_2NB01 49.9 20367 20363 48645 24276 24276 8

From above RRC connection setup statistics, it is found that a lot of RRC setup
failure happened.
Step1: Further verify RRC failure counters, most of the failures are because of
license.
pmRrcConnEs pmRrcConnE
pmRrcCon pmRrcConn pmRrcConn pmRrcConnEsta
Date eNodeB SSSR tabFailHighL stabFailBear
nEstabAtt EstabSucc EstabFailLic bFailOverload
oad erAdmission
11/24/2014 SKA7399T_2NB01 49.9 48645 24276 24341 0 0 0

Step2: Extract the connected user license capacity and maximum connected
users:

pmLicConnecte pmLicConnecte pmLicConnectedU


Date eNodeB dUsersLicense dUsersMax sersTimeCong
11/24/2014 SKA7399T_2NB01 10 10 21319

Solution:
Since the licensed number of connected user was quite low compared to the
maximum capacity (3000 for DUL41), the suggestion was to increase the
license capacity, i.e. to load new LKF.

9.1.2 Case2: Lack of Resource (SR)

Cell Start Time UL Volume DL Volume SSSR RRC SR E-RAB SR


LD32B37B 21:00 54.074 237.521 59.114 59.13 99.974
LD32B37B 21:15 52.716 266.476 71.883 71.934 99.929
LD32B37B 21:30 51.595 302.529 85.971 85.971 100
LD32B37B 21:45 53.896 332.344 77.133 77.133 100
LD32B37B 22:00 55.842 331.024 74.198 74.232 99.954
LD32B37B 22:15 44.389 293.783 90.347 90.347 100

The low RRC Setup Success was observed as above table.


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 26 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Step1: Further verify the RRC failure counters, most of the failures are due to
lack of resource as below ENIQ counter indicating.
pmRrcConn pmRrcConnEstabFail pmRrcConnEstab pmRrcConnEstab pmRrcConnEstabFail pmRrcConnEstabFailFailure pmRrcConnEstab
Cell Start Time
EstabFailLic BearerAdmissionRej FailHighLoad FailOverload LackOfResources InRadioProcedure FailUnspecified
LD32B37B 21:00 0 0 0 0 2687 2 0
LD32B37B 21:15 0 0 0 0 1647 0 0
LD32B37B 21:30 0 0 0 0 666 0 0
LD32B37B 21:45 0 0 0 0 1253 3 0
LD32B37B 22:00 0 0 0 0 1536 3 0
LD32B37B 22:15 0 0 0 0 384 1 0

Step2: Check the maximum RRC connections and average value as well.

Cell Start Time pmRrcConnMax Average RRC Users


LD32B37B 21:00 201 169.744
LD32B37B 21:15 198 180.361
LD32B37B 21:30 198 177.889
LD32B37B 21:45 203 185.144
LD32B37B 22:00 203 191.772
LD32B37B 22:15 202 147.422

Step3: Check ‘noOfPucchSrUsers’ setting, it is 200, which is the bottleneck according


to last step result, the maximum RRC connections.

Solution: Increase ‘noOfPucchSrUsers’ gradually, meanwhile, double check whether


the site is overshooting and taking traffic from other sites serving area.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 27 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

9.1.3 Case3: High Load

Cell Start Time UL Volume DL Volume SSSR RRC SR E-RAB SR


LD31E48A 14:00 27.052 220.192 99.55 99.64 99.91
LD31E48A 15:00 24.21 300.56 99.59 99.63 99.96
LD31E48A 16:00 38.332 210.594 98.69 98.94 99.75
LD31E48A 17:00 17.261 125.127 98.29 98.39 99.9
LD31E48A 18:00 19.429 146.255 98.5 98.56 99.94
LD31E48B 14:00 23.876 741.16 99.88 99.96 99.92
LD31E48B 15:00 27.717 203.674 99.71 100 99.71
LD31E48B 16:00 17.637 132.678 98.74 98.99 99.75

It is found that RRC Setup Success started to decrease from 16:00 as above
statistics table.

Step1: Present the RRC setup failure PM counters, most of the failures reason
points to high load as below table.
pmRrcConn pmRrcConnEstabFail pmRrcConnEstab pmRrcConnEstab pmRrcConnEstabFail pmRrcConnEstabFailFailure pmRrcConnEstab
Cell Start Time
EstabFailLic BearerAdmissionRej FailHighLoad FailOverload LackOfResources InRadioProcedure FailUnspecified
LD31E48A 14:00 0 0 0 0 0 3 0
LD31E48A 15:00 0 0 0 0 0 2 0
LD31E48A 16:00 0 0 20 0 0 3 0
LD31E48A 17:00 0 0 47 0 0 4 0
LD31E48A 18:00 0 0 49 0 0 0 0
LD31E48B 14:00 0 0 0 0 0 0 0
LD31E48B 15:00 0 0 0 0 0 0 0
LD31E48B 16:00 0 0 26 0 0 3 0
LD31E48B 17:00 0 0 53 0 0 7 0
LD31E48B 18:00 0 0 59 0 0 4 0
LD31E48C 14:00 0 0 0 0 0 0 0
LD31E48C 15:00 0 0 0 0 0 2 0
LD31E48C 16:00 0 0 24 0 0 0 0
LD31E48C 17:00 0 0 54 0 0 1 0
LD31E48C 18:00 0 0 55 0 0 3 0

Step2: Check MP load statistics as below chart and table


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 28 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

MP LOAD 14:00 15:00 16:00 17:00 18:00

0 to 20 % 357 356 167 4 0


20 to 30 % 0 0 51 102 10
30 to 40 % 0 0 124 156 141
40 to 50 % 0 0 11 69 161
50 to 60 % 0 0 0 3 19
60 to 70 % 0 0 0 3 4
70 to 80 % 0 0 1 10 11
80 to 85 % 0 0 1 2 3
85 to 90 % 0 0 0 5 6
90 to 95 % 0 0 2 4 5
Over 95% 0 0 0 0 0

The MP load increased from 16:00 significantly. The next action is to investigate
what contributes to this.

Step3: Checkpoints as below

• Hardware Alarms (command ‘al’)  No

• Number of RRC connections  Similar as before

DATE HOUR MIN CELL pmRrrcConnMax CELL pmRrrcConnMax CELL pmRrrcConnMax


16-Nov 15 0 LD31E48A 33 LD31E48B 41 LD31E48C 25
16-Nov 15 15 LD31E48A 30 LD31E48B 40 LD31E48C 28
16-Nov 15 30 LD31E48A 30 LD31E48B 47 LD31E48C 31
16-Nov 15 45 LD31E48A 37 LD31E48B 41 LD31E48C 32
16-Nov 16 0 LD31E48A 29 LD31E48B 41 LD31E48C 34
16-Nov 16 15 LD31E48A 30 LD31E48B 38 LD31E48C 31
16-Nov 16 30 LD31E48A 29 LD31E48B 39 LD31E48C 31
16-Nov 16 45 LD31E48A 31 LD31E48B 41 LD31E48C 36
16-Nov 17 0 LD31E48A 26 LD31E48B 44 LD31E48C 30
16-Nov 17 15 LD31E48A 30 LD31E48B 44 LD31E48C 34
16-Nov 17 30 LD31E48A 29 LD31E48B 44 LD31E48C 22
16-Nov 17 45 LD31E48A 29 LD31E48B 38 LD31E48C 24

• Traffic Volume  Similar as before


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 29 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

14:00 15:00 16:00 17:00 18:00


UL 27.052 24.21 38.332 17.261 19.429
LD31E48A
DL 220.192 300.56 210.594 125.127 146.255
UL 23.876 27.717 17.637 20.075 31.984
LD31E48B
DL 741.16 203.674 132.678 129.568 197.495
UL 11.788 10.362 11.327 16.02 19.946
LD31E48C
DL 111.598 58.199 99.876 176.876 105.806

• Handover statistics  Hanover in Cell B and C increased from 16:00,


but the connected users remained similar as previous investigation.

After checking the neighbor relation setting and changes, it was found that the
parameter ‘cellIndividualOffsetEUtran’ (CIO) was set to 10 as below.

Both outgoing and incoming HO are handled by the same site, when setting CIO
= 10, it resulted in Ping-Pong HO and increased the MP load.

Solution:

Set CIO back to 0 for B and C intra-site neighbor relation


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 30 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

9.1.4 Case4: Uplink Interference due to HW issue

UL VOLUME DL VOLUME
DATE CELL SSSR RRC SSR E-RAB SSR
(MB) (MB)
2-Jul LF32D76C 66.133 3303.662 42.061 72.501 58.014
3-Jul LF32D76C 8.412 38.125 36.967 64.983 56.887
4-Jul LF32D76C 5.868 31.826 36.225 65.225 55.538
5-Jul LF32D76C 5.145 24.785 32.142 58.317 55.116
6-Jul LF32D76C 6.77 55.576 37.737 64.041 58.925
7-Jul LF32D76C 5.498 15.551 35.783 63.107 56.702
8-Jul LF32D76C 11.523 164.668 51.601 74.819 68.967

This cell had suffered from low SSSR for days, including RRC and E-RAB
establishment.

Step1: Expand the RRC failure PM counters as below table, most of the failure
happened in radio process.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 31 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

pmRrcConn pmRrcConnEstabFail pmRrcConnEstab pmRrcConnEstab pmRrcConnEstabFail pmRrcConnEstabFailFail pmRrcConnEstab


DATE CELL
EstabFailLic BearerAdmissionRej FailHighLoad FailOverload LackOfResources ureInRadioProcedure FailUnspecified
2-Jul LF32D76C 0 0 0 0 0 989 0
3-Jul LF32D76C 0 0 0 0 0 1861 0
4-Jul LF32D76C 0 0 0 0 0 870 0
5-Jul LF32D76C 0 0 0 0 0 641 0
6-Jul LF32D76C 0 0 0 0 0 621 0
7-Jul LF32D76C 0 0 0 0 0 975 0
8-Jul LF32D76C 0 0 0 0 0 647 0

Step2: Check Hardware Alarms

“CalibrationFailure”, “LinkFailure” and “ServiceUnavailable” alarms existed.

Step3: Check Uplink Interference Level, both average and per PRB

Strong uplink interference was observed for this cell, but not for surrounding
cells.

Therefore, it is more likely that this uplink interference is because of hardware


issue.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 32 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Solution:

Site visit to identify hardware problem, after check RRU, feeders and antenna, it
was identified as RRU problem. The uplink interference disappeared after RRU
replacement.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 33 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

9.1.5 Case5: Weak Coverage

UL VOLUME DL VOLUME
DATE CELL SSSR RRC SSR E-RAB SSR
(MB) (MB)
3-Sep LD31F42A 129.65 2762.901 90.104 90.488 99.576
4-Sep LD31F42A 94.552 1390.667 94.286 94.372 99.909
5-Sep LD31F42A 143.404 2302.485 96.066 96.219 99.841
6-Sep LD31F42A 209.784 1283.156 89.398 89.804 99.549
7-Sep LD31F42A 198.211 4418.331 95.444 95.866 99.56
8-Sep LD31F42A 177.538 1980.605 89.323 89.505 99.796
9-Sep LD31F42A 136.931 1710.123 87.59 88.146 99.369
9-Sep LD31F42A 136.931 1710.123 87.59 88.146 99.369
It was found that Cell LD31F42A had low RRC setup success.

Step1: Check the RRC failure counters  the failures were due to radio

pmRrcConn pmRrcConnEstabFail pmRrcConnEstab pmRrcConnEstab pmRrcConnEstabFail pmRrcConnEstabFailFail pmRrcConnEstab


DATE CELL
EstabFailLic BearerAdmissionRej FailHighLoad FailOverload LackOfResources ureInRadioProcedure FailUnspecified
3-Sep LD31F42A 0 0 0 0 0 614 0
4-Sep LD31F42A 0 0 0 0 0 303 0
5-Sep LD31F42A 0 0 0 0 0 234 0
6-Sep LD31F42A 0 0 0 0 0 1068 0
7-Sep LD31F42A 0 0 0 0 0 303 0
8-Sep LD31F42A 0 0 0 0 0 1241 0
9-Sep LD31F42A 0 0 0 0 0 858 0

Step2: Check Alarms  No alarm


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 34 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Step3: Check Interference (UL RSSI)  Normal

Step4: Check downlink coverage  No overshooting, but weak RSRP.

Average RSRP = -99 dBm

RSRP<-110 dBm percentage > 10%

(Antenna Height=30m, tilt=7, and transmitted power=20 Watt)

Solution suggestion: increase the downlink power from 20Watt to 40Watt


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 35 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

9.1.6 Case6: Due to one UE by CTR analysis

It was found that site DFWe0600001 has accessibiltiy issue in RRC phase as
above KPI charts showing.

Step1: Check Hardware Alarms  No alarms

Step2: Check UL RSSI  Fine

Step3: Check DL Coverage  OK, no overshooting, RSRP normal

Step4: Schedule CTR for deep analysis

In CTR, the event parameter “EVENT_PARAM_RRC_RESULT” from


“INTERNAL_PROC_RRC_CONN_SETUP” confirmed that failure happened during radio
procedure, and “EVENT_PARAM_INITIAL_UE_IDENTITY” show that these were due to
same UE.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 36 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

9.2 E-RAB Establishment Failure

9.2.1 Case1: E-RAB Failure Due to Interference

It was observed that below cell had low E-RAB success and RRC as well.

UL VOLUME DL VOLUME
DATE CELL SSSR RRC SSR E-RAB SSR
(MB) (MB)
15-Aug LF31D77B 33.182 416.036 93.385 95.837 97.441
16-Aug LF31D77B 18.683 141.072 93.725 96.266 97.361
17-Aug LF31D77B 28.123 299.465 93.075 94.967 98.007
18-Aug LF31D77B 34.147 209.271 94.864 96.326 98.482
19-Aug LF31D77B 29.731 307.053 93.462 94.98 98.402
20-Aug LF31D77B 30.715 232.662 93.636 95.359 98.193

Since both RRC and E-RAB had failure, we should start from RRC setup.

Step1: Check detailed RRC failure reason PM counters  most of the failures
happen in radio procedure.

pmRrcConn pmRrcConnEstabFail pmRrcConnEstab pmRrcConnEstab pmRrcConnEstabFail pmRrcConnEstabFailFail pmRrcConnEstab


DATE CELL
EstabFailLic BearerAdmissionRej FailHighLoad FailOverload LackOfResources ureInRadioProcedure FailUnspecified
14-Aug LF31D77B 0 0 0 0 0 448 0
15-Aug LF31D77B 0 0 0 0 0 301 0
16-Aug LF31D77B 0 0 0 0 0 258 0
17-Aug LF31D77B 0 0 0 0 0 487 0
18-Aug LF31D77B 0 0 0 0 0 289 0
19-Aug LF31D77B 0 0 0 0 0 380 0

Step2: Check Hardware alarms  No alarms


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 37 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Step3: Check UL interference  The UL RSSI was high

The interference was high in lower band. Since this was Band 39 site, close to
DCS1800, so we suspected the interference was from inter system DCS1800.

Step4: Lock co-site DCS1800 RRU and check UL RSSI  Fine after DCS lock
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 38 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Note: if DCS1800 site were down during some period, then we can also check
the UL RSSI of the F band LTE site in the same period.

Solution:

Suggest customer equip extra filter for co-site DCS1800 RRU.

After filter equipped:


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 39 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

9.2.2 Case2: E-RAB failure due to encryption


Ericsson Internal
SERVICE DELIVERY INSTRUCTION 40 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

It was found that above site had low ERAB establishment success, but RRC
setup was fine. There is no fails due to ‘pmErabEstabFailGbrDlEnb’,
‘pmErabEstabFailGbrUlEnb’, ‘pmErabEstabFailAddedLic’ and ‘pmErabEstabFailInitLic’.

No Hardware alarms

No Radio issue (both UL and DL are fine)

No Abnormal parameters

Through CTR analysis, it was found that the failure cause was due to
“radioNetwork : encryption-and-or-integrity-protection- algorithms-not-supported ”.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 41 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Then checking attach request message, we found that UE report EIA0 for
integrity-protection, which should be for emergency call in 3GPP.

But eNodeB didn’t support EIA0, so it replied “InitialContextSetupFailure”


to MME with cause “radioNetwork-encryption-and-or-integrity-protection-
algorithms-not-supported”.

Solution: Activate the feature “Limited Service Mode Emergency Call Support”.

10 Appendix
10.1 Traffic Offload

Traffic offload can be achieved mainly through three methods.

Parameter  Load Balance Features  Physical Changes


10.1.1 Parameter
Idle mode main parameters could be used to “offload” traffic to neighbors. Offset
parameters are usually first considered.
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 42 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Parameter Name
qRxLevMin
qRxLevMinOffset
qQualMin
qQualMinOffset
sIntraSearch
sNonIntraSearch
qOffsetCellEUtran
qOffsetFreq
Idle Mode qRxLevMin (neighbor cells)
qQualMin (neighbor cells)
cellReselectionPriority
threshXHigh
threshXLow
threshServingLow
threshXHighQ
threshXLowQ
threshServingLowQ

Connected mode

Intra-LTE

• Intra Frequency

• Inter Frequency

• Inter Mode

IRAT

• UTRAN

• GERAN
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 43 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Parameter Name
a3offset
hysteresisA3
timeToTriggerA3
cellIndividualOffsetEUtran
a1ThresholdRsrpPrim
a1ThresholdRsrqPrim
timeToTriggerA1Prim
a2ThresholdRsrpPrim
a2ThresholdRsrqPrim
Connected
triggerQuantityA2Prim
Mode
timeToTriggerA2Prim
hysteresisA2Prim
a5Threshold1Rsrp
a5Threshold2Rsrp
timeToTriggerA5
connectedModeMobilityPrio
qOffsetFreq
b2Threshold1Rsrp
b2Threshold1Rsrq

10.1.2 Load Balance

For the detailed features information, please go to ALEX related topics. Below
main parameters are listed.

Inter-Frequency Load Balancing

Parameter
loadBalancing
cellSubscriptionCapacity
qciSubscriptionQuanta (Predefined)
qciSubscriptionQuanta (Operator Defined)
lbThreshold
lbCeiling
a5Threshold1Rsrp
a5Threshold2Rsrp
a5Threshold2Rsrq
hysteresisA5
lbRateOffsetLoadThreshold
lbRateOffsetCoefficient
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 44 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

Inter-Frequency Offload

Parameter
lbEUtranTriggerOffloadThreshold
lbEUtranAcceptOffloadThreshold
lbEUtranCellOffloadCapacity
lbEUtranCellOffloadCapacity
lbEUtranCellOffloadCapacity
lbEUtranOffloadBackoffTime
lbCauseCodeS1SourceTriggersOffload
lbCauseCodeS1TargetAcceptsOffload
lbCauseCodeX2SourceTriggersOffload
lbCauseCodeX2TargetAcceptsOffload
lbCellOffloadCapacityPolicy

Inter-RAT offload to WCDMA

Parameter
lbUtranOffloadThreshold
lbUtranCellOffloadCapacity
lbUtranOffloadBackoffTime
ReportConfigInterRatLbId
utranB1ThresholdRscp
utranB1ThresholdEcNo
utranHysteresisB1
loadBalancing

Admission-Triggered Offload

Parameter
AdmissionControl.lbAtoThresholdLevel1
AdmissionControl.lbAtoThresholdLevel2
EUtranFreqRelation.atoAllowed
UtranFreqRelation.atoAllowed
EUtranFreqRelation.EutranFreqToQciProfileRelation.atoThresh1QciProfileHandling
EUtranFreqRelation.EutranFreqToQciProfileRelation.atoThresh2QciProfileHandling
UtranFreqRelation.UtranFreqToQciProfileRelation.atoThresh1QciProfileHandling
UtranFreqRelation.UtranFreqToQciProfileRelation.atoThresh2QciProfileHandling
FreqPrioEUTRA.atoAllowed
FreqPrioUTRAN.atoAllowed
Ericsson Internal
SERVICE DELIVERY INSTRUCTION 45 (45)
Prepared (Subject resp) No.

Shawn He
Approved (Document resp) Checked Date Rev Reference

2016-03-09 PA1

10.1.3 Physical

Sometimes it is not enough to offload traffic through parameters and features


adjustment. Physical approaches are considered then.

Physical changes:

• Power adjustment (better 3 dB per step)

• Antenna changes (tilts, azimuth, height)

• New carriers or new sites proposal

10.2 Reference
[1] LTE T&O CC/CG 2nd Line Support

[2] CPI store: http://cpistore.internal.ericsson.com/alex

[3] CPI: Idle Mode Support, 154/221 04-LZA 701 6014/1 Uen

[3] CPI: Flowcharts for Counters, 19/1551-HSC 105 50/1 Uen AA

[4] CPI: Performance Management, 3/1551-HSC 105 50/1 Uen AA

[5] LTE Signaling Reference