10 MHZ 50
5 MHZZ 25 12
Idle Mode
Accessibility - Random Access
Rf Abnormalities
Incorrect Parameter Settings
Accessibility
Troubleshooting
Access block due to overloading & Highload
Uder Licence Exeeded & Lack of Resources & Lic
The UE uses the random access process to gain access to the cell for the following reasons: 1) Initial access to the network from the idle state – RRC Connection Establishment
2) Re-gain access to the network after radio link failure – RRC Connection Re-establishment 3) During handover to gain synchronization with a new cell – Handover Execution
The eNodeB may block the UE’s connection request by sending the “RRC Connection Reject”, there will be no cause value signaled to the UE with RRC Connection Reject, but a wait time value of 1–16 seconds that can help to protect the eNodeB from overload due to rising numbers of RRC Connection Requests
Counters pmRrcConnEstabFailHighLoad & pmRrcConnEstabFailOverload will be stepped at transmission of “RRC Connection Reject” during high load or overload circumstances
Symptoms:
During an RRC connection setup process, the eNodeB has not received any RRC connection setup complete messages within the related timeout duration.
During an E-RAB setup process, the response in security mode times out.
At the eNodeB side, both the RRC connection setup success rate and the E-RAB setup success rate are low
RRC Accessibility Failures:
Cell parameters are incorrectly configured. For example, qRxLevMin which is used in the evaluation of cell selection is too low UE camping in the wrong cell, parameters for cell reselection can be tuned
Examples of S1 Setup failures:
1- If all S1 control plane connections fail, the affected cells become disabled over time and generate the alarm ServiceUnavailable
eNodeB>
================================================================== Date & Time (Local) S Specific Problem MO (Cause/AdditionalInfo)
=================================================================== XYX 15:47:51 M ServiceUnavailable EUtranCellFDD=….
(S1 Connection failure for PLMN mcc:XYZ mnc:XYZ) >>> Total: 1 Alarms (0 Critical, 1 Major
pmRrcConnEstabFailActiveUserLicenseExceeded & pmRrcConnEstabFailLackofResources & pmRrcConnEstabFailLic • Two types of RA procedures are defined:
1) CBRA (Contention Based Random Access)
2)CFRA (Contention Free Random Access) – Not supported yet • The main counters involved are the following:
1)pmRaAttCbra 2)pmRaSuccCbra
Examples of action:
1) Change SC 556: Decrease the maximum number of initial accesses and incoming handovers that are allowed during a time window without triggering the load control mechanism
2) Change the dlMaxRetxThreshold & ulMaxRetxThreshold of SRB=1: Reduce the number of RLC retransmissions for Signaling Radio Bearer
3) Change EutranCellFDD.qRxLevMin to higher values
4) Use a dedicated DUL for the Hi-Cap cell, even though the noOfPucchSrUsers determine the number of SR on the cell level, the simultaneous allocated resources in all cells sharing a DUL are limited by the maximum number of resources available in the DU. The resources is pooled within the DUL which means that the number of used resources can vary between cells
Items to be investigated are: 1) Radio interference
2) DL interference from neighboring cells, DL interference from external systems, and UL interference need to be investigated
3) Cell Coverage Imbalance between UL and DL (Use counters pmRadioTbsPwrRestricted, pmbadcovevalreport) 4) The transmit power of the RRU and the UE need to be investigated to check whether UL or DL limitations have occurred
S1 Failures:
Incorrect or missing TAI-LAI pairing could result in accessibility failures when UE attempts CS Fallback to UMTS (LTE Attach Request of type “Combined EPS/IMSI Attach”). The MME derives the LAI from the TAI of the current LTE cell, then MME sends the “Location Update Request” to the target MSC/VLR. Failures can be avoided by:
Configuring the E-UTRAN cell's TAI to take into account the LA boundary of the target UMTS The MME being configured to know which TAIs are within which LA
2- S1 setup failures due to software error, example:
The “eNB_UE_S1AP_ID” is not recognized by the MME”, the MME and the eNodeB go out of sequence. The eNodeB releases the old “eNB_UE_S1AP_ID”, however the MME holds it for a while. New S1 requests received by the MME using this ID will be rejected by the MME
Temporary workaround:
Lock the TermPointToMme, wait 5 seconds then unlock the TermPointToMme Re-start the eNodeB
Rejection counter
pmRrcConnEstabFailFailureinRadioProcedure pmRrcConnEstabFailHighLoad &
MOBILITY Troubleshooting
HO Prep & Exec Failures
Poor radio conditions & Badly
tuned handover parameters
Ho Prep Success Rate (pmHoPrepAttLTEIntraF/ pmHoPrepSuccLTEIntraF)
Ho Execution Success Rate (pmHoExeAttLTEIntraF/ pmHoExeSuccLTEIntraF)
Intra Frequency HO Success Rate
Inter Frequency HO Success Rate
IRAT HO Success Rate
Reasons:
HO Prep:
1) Handover preparation failure that may be caused by incorrect parameter settings in the target cell (e.g. certain TermPorinttoMme is missing). 2) the target network element is not able to provide the required radio resources for the handover and, hence, does not return the requested handover command message. 3) Handover preparation may fail because the target eNodeB cannot provide the resources for the handover during congestion or cannot interpret the contents of the handover request message. If the source eNodeB does not receive a response to its X2AP handover request message from the target eNodeB, the source eNodeB will send the handover cancel message
HO Execution:
1) Handover execution failure that may be caused by incorrect parameter settings in the target cell (e.g. PCI Collision in the target cell)
2) Hardware faults are the most likely cause if handovers suddenly become abnormal without recent modifications to the configurations of the abnormal cell and its neighboring cells. Possible hardware faults are: board is overloaded, faulty RRU, a common public radio interface (CPRI) link is faulty and GPS clock source is faulty
3) Two symptoms may occur when the RF is poor. One is that the UE cannot receive any handover commands from the eNodeB, the other is that the UE cannot access the target cell and cannot report the handover complete message
Abnormal Release: If handover is triggered too early, the target cell SINR can be too weak when handover occurs. If handover is triggered too late, the source cell SINR can be too low. This can result in an abnormal release before handover.
Handover hysteresis and time-to-trigger settings are required to prevent excessive ping-pong handovers. Such behavior increases signaling, risk of failure, and decreases throughput
With too little overlap, handover may fail. With too much cell overlap, higher interference occurs and cell edge throughput can be reduced. Again, a balance must be achieved by adjusting overlap margins and cell sizes. This can be achieved with parameters and physical changes
Two symptoms may occur when the RF is poor. One is that the UE cannot receive any handover commands from the eNodeB, the other is that the UE cannot access the target cell and cannot report the handover complete message
KPI Reason
UL RSSI
External Issue Check External Source of Uplink Interference Configuration Issue
Internal Issue LTE
3G
Fault component in Antenna System Incorrect Plumbing
Lose Connector / Tight Cable Band Incorrect TMA Settings / TMA Faulty
Check its due to UL data which causing interference Check hourly and daly UL RSSI performance
Solution Ranges
Parameter: tt2 = 4 to 2 or 0 SF8/16 = 8 to 4 or 0
DT Reports Ranges Good Ranges Bad
BEST Server Plot Per PCT (Idle) (dBm)
BEST Server Plot Per PCT (Connected Mode) (dBm) Port - 0 Port - 1
RSRP Ranges -0 to -75 -105 to -140
UL/DL SINR Plot (dB) 15 to 30 (0to7) (-1 to
RSRQ Plot (dB) 0 to -10 -10 to onwards
DL CQI
RSSI (-110 to -140) -100 to -80)
SINR signal-to-noise-plus-interference ratio Best server Plot
UL Throuput
SINR VS UL THP
End to End Latency Statistics RTT (Round Trip Time) SINR how ti imporve; Overshooting , Spider Plots, PCI
Classhes can be.
Put logs in TEMS DIscovery (Spider Plot) to check overshooting
RSRP Reference Signal Receive Power
How to calcualte SINR SINR VS RSSI
RSRP Calculate kaysay hota hay
ANR (Automatic neighbor Relation) based on LMRR (meansurement) Meansuremnt Collect and Update neighbour accordingly. (Automatic) Drawback ANR: Overshotting cells cant
detect Neighnpurs.
Handover Intruption Time (Latency Time Increase) Check with Core.
SINR possible degradation reason with casses
FDD / TDD (kiss main ziyada kharab hote hay aur kyun SINR)
Reference Sinal kya hota hay RX power kayse set hotay hain
TDD because it use same channel for UL/DL
Total Interference = Own cell Noice + Neighbour Noice TDD= 12 ro 15 and FDD = 18-23
SINR
Overshooting, PCI Classesl
PCI Planning: ATOL, Unet, Optimi, Asset
V_shift:
Finad and solve PCI Issue PCI Confusion (Main) colision
TAB
Genearl (stats)
UE Problem, eNB problem
ENODE level feature
Check CQI & RI (Rank Indicator) Reported from UE: Check transmission Mode:
BLER (Block Eror Rate)
UL RSSI (Ul Interference)
Check MCS & No of Assigned PRB's in Scheduler.
Before start troubleshooting check:
Extend the time for new Poll if no status report is received from 80ms to 160 ms for
signalling/Radio bearer/ Data bearer, Fial is to redyce UL/DL nwtwork load
Reduce the no of RLC re-trnsmission for
Signaling/Data & Radio bearer, goal to improve UL/DL Throughput
Check UE Scheduling percentage of TTIs
Reasons
Downlink/Uplink baseband Capacity Channel Bandwidth (5,10,15,20) 64 QAM DL / 16 QAM UL
Dual Anteena DL perfromance package Schedulling Algo= Round Robin
Check and increase max Licence for NoofPUCCHsrUser 590 & NoohPUcchCQIser 320) Change tPollRetransmissionDL & tPollRetransmissionUL
dlMaxRetxThreshold / ulMaxRetxThreshold (DRB/SRB)
By stats & DT, CQI/RI provides us SINR/Antenna Layer reception report from UE point of View. CQI Ranges MIMO/SIMO/TxD
Is the issue happening at a certain enodeB, several enodeB’s or all enodeB’s? * What is the observed throughput and what is expected?
* When was the last time the throughput was observed to be ok?
* What has changed since the last time throughput was observed to be ok? e.g.
adding/changing/removing hardware, eNodeB parameter changes, IP address plan changes & Transport Network changes
* Does the issue occur during certain times of day (i.e. busy hour)
* Does the issue occur during certain times of the week (i.e. During local event) Invalid UE reports ( UE stats)
Uu Air Interface Porblem. (Radio Issue) • Incorrect Parameter settings
• Scheduling Abnormality
• Limitation in Current eNB software. • s1 User Plane Issue
• can’t get ACK/NACK
• Core network / SSAN/SGW issue etc
Check whether the block error rate (BLER) is excessively high on the radio interface. If the BLER is higher than 10%, the channel condition is poor
Check whether uplink interference exists, in a normal case, the UL RSSI on each resource block (RB) is about ( – {119 to 120} ) dBm when the cell is unloaded. If the RSSI is 3 dBm to 5 dBm higher than the normal value (when un-loaded), uplink interference exists, Could be some external interferer or values of pZeroNominalPusch in neighbour cells are too high)
1) Mapping of MCS/CQI is performed by DL link adaptation
2) The eNB needs knowledge of the SINR conditions of downlink transmission to a UE in order to select the most efficient MCS/PRB combination for a selected UE at any point in time.
3) Understanding the relationship between chosen MCS, assigned PRBs and assignable bits in the scheduler are important for sorting core network issues/UE issues from air interface issues
1) Scheduling percentage means the amount of TTIs (typically measured per second) that the UE was scheduled. This is also related to the resources allocated for PDCCH (control channels)
2) Another cause of low throughput is that the UE is not being scheduled in every TTI. Cause: Limitations in current scheduler implementation, software Limitation.
When HARQ fails to transmit a transport block within the maximum number of configured retransmissions Default number of HARQ transmissions is 4 in L11A
If RLC STATUS messages are not received within the time frames configured › Check:
ACK_SN should be increasing, otherwise RLC buffers are not released NACK_SN indicates RLC retransmissions (occasionally is OK)
DataRadioBearer::tStatusProhibit governs how often RLC STATUS messages may be generated, default is 25ms in L11A.
› A too low value will produce too many RLC control messages › A too high value may cause RLC buffers to become exhausted
ulChannelBandwidth = 5000
In LTE, the theoretical throughput relates to the system bandwidth, modulation scheme, multiple-input multiple-output (MIMO) mode, and parameter settings.
Theoretical rate calculation for a cell considers the number of symbols occupied by the physical downlink control channel (PDCCH) in each sub-frame and the amount of resource elements occupied by the
synchronization channel, by reference signals, and by the broadcast channel
Check UL Power settings and SINR on cells level (PnotnominalPUCCH)
The SINR is converted to Channel Quality Indicator (CQI) and reported to the eNodeB in the Channel Feedback Report (CFR) by the UE. The CQI indicates the radio quality, and is used by the link adaptation function in the eNodeB to select the transport format matching the channel conditions
UL THP ISSUES
Step 4: Low Demand
Step 3: BLER Values
Parameter Optimization
Check feautrue Activated
Step 5: Scheduler Type
Step 1: Identify cell with low UL (uplink) throughput
Step 2: Identify Uplink interference
Extend the time for new Poll if no status report is received from 80ms to 160 ms for
signalling/Radio bearer/ Data bearer, Fial is to redyce UL/DL nwtwork load
Reduce the no of RLC
re-trnsmission for Signaling/Data & Radio bearer, goal to improve UL/DL Throughput
Step 7: Other
Reasons
pZeroNominalPucch / pZeroNominalPusch Downlink/Uplink baseband Capacity Channel Bandwidth (5,10,15,20) 64 QAM DL / 16 QAM UL
Schedulling Algo= Round Robin
Change tPollRetransmissionDL & tPollRetransmissionUL
dlMaxRetxThreshold / ulMaxRetxThreshold (DRB/SRB)
a) The first thing is to identify those cells with low throughput. What is considered as low throughput is a threshold defined by your network policies and best practices (it also depends on your design parameters). Reports should be run for a significant number of days so that data is statistically valid.
a) Run a report using the counters provided by the OEM to find
1. Maximum number of RRC connections supported per cell (parameter or feature) 2. Maximum number of RRC connections active per cell
3. Average number of RRC connections active per cell
4. Maximum number of users per TTI supported per cell (parameter or feature) 5. Maximum number of users scheduled per TTI in the cell(s) of interest
6. Average number users scheduled per TTI in the cell(s) of interest
b) If the maximum number of RRC connections active per cell is close or equal to the maximum number of RRC connections supported, then. The cause for low throughput is load.
c) A high number of scheduled users per TTI does not necessarily mean that demand is the cause for low throughput.
a) Run a report for RSSI in the uplink. Most OEM provide with counters and or tools to assess the RSSI in a span of days. Cells with uplink interference are those whose RSSI values are high (higher than -90dBm, for instance). b) Typical scenarios where these values are high are indoor environments (i.e.: arenas, airports, etc.)
c) Common sources of interference in the 700 MHz band (LTE deployment in the USA) are: high values of traffic in the uplink, external source of interference, high values of P0-nominalPUCCH and P0-nominalPUSCH (Consult your technical lead on the settings of these parameters)
a) Run a report for BLER in the cells identified. The BLER should be smaller or equal than 10%. If the value is larger, then, there is an indication of bad RF environment.
b) Typical causes of bad BLER are uplink interference, bad coverage (holes in the network, etc.)
a) Find the scheduler types your OEM supports
b) Select the one that is more convenient for the type of cell you are investigating. Examples of schedulers are: round robin, proportional fairness, maximum C/I, equal opportunity, etc. OEMs allow you to switch the scheduler in your network but recommend one in particular.
pZeroNominalPucch / pZeroNominalPusch pZeroNominalPusch
a) Run a VSWR report or ask your OEM to run it for you.
b) High values of VSWR result in low throughput due to losses.
c) Check your backhaul capacity. Often times, the backhaul links are shared among multiple RATs. Make sure your backhaul is properly dimensioned.
At the end of this methodology, you will be able to determine if the reasons for low throughput in your cells is one of the following or a combination, thereof:
- BLER (bad coverage)
- Uplink Interference (high RSSI) - Low Power headroom
- Scheduling algorithm - Low Demand
- Other (VSWR, Backhaul capacity)
a) Run a report to find out the average power headroom that UEs have in your network.
b) A low value of power headroom means that UEs do not have available power to transmit in the uplink and hence, the throughput is low.
c) Low values of power headroom are 5 dB or smaller.
d) Typical causes of low power headroom are uplink interference and/or incorrect power control parameter settings, to mention a few.
LTE counters
Get the description of any counter
LTE parameter
Check for active alarms: Check Cell Alarm Log
Check Cell Alarm, Event, Availability, System, Coli commands Log Check VSWR
Check the state of cell: Check the state of sector: Check S1/X2 termpoints: Check the state of RRU Check the state of MME:
Get power parameters and values:
Get values from electrical and mechanical Antenna Tilt: Get values from earfcndl e earfcnul:
Check Channel Bandwidth (uplink and downlink) Check the Tracking Area Identity
Check Licenses, HW capacity and Softwares Check the IP address from TermPointToMme Check the PCI from the cells
Get cell range (Maximum distance from the eNodeB where a connection to an UE can be setup and/or maintained)
Get the eNodeB ID (it forms part of the CGI)
Check the Cell Reselection Priority (absolute priority of the carrier frequency used by the cell reselection procedure)
Check the Mobility Priority (Prioritizes EUTRAN frequencies among all frequencies related to the cell for UEs in connected mode)
Check eNodeB relations Print all active UE
Print all admitted UEs and Data Radio Bearers in all cells
Get a counter print
Get the description of any parameter Get a parameter print
ENODEB01> alt ENODEB01> lga -m 3 ENODEB01> lgsavemo -m 2 ENODEB01> lh ru fui get vswr 1 ENODEB01> st cell
ENODEB01> st sector ENODEB01> st termp ENODEB01> st ru ENODEB01> st mme ENODEB01> get . power ENODEB01> get . antennatilt ENODEB01> get . earfcn
ENODEB01> get ^EUtranCellFDD ChannelBandwidth ENODEB01> get EUtranCellFDD=E tac$
ENODEB01> inv
ENODEB01> get TermPointToMme ipaddress
NODEB01> get EUtranCellFDD=ENODEB01 physicallayer ENODEB01> get EUtranCellFDD cellrange
ENODEB01> get ENodeBFunction=1 enbid
ENODEB01> get . cellReselectionPriority
ENODEB01> get . connectedModeMobilityPrio
ENODEB01> get . relation ENODEB01> ue print -ue ENODEB01> ue print -admitted
LTE counters
ENODEB01> pmom . <counter_name> ENODEB01> pmx . <counter_name>
LTE parameter
ENODEB01> mom . <parameter_name> ENODEB01> get . <parameter_name>
emudrad
ENODEB01> lh ru fui get vswr 2
ENODEB01> get . ^UtranCellRelation ENODEB01> get . ^EUtranCellRelation
ENODEB01> pmom . pmRrcConnEstabSucc ENODEB01> pmxh . pmRrcConnEstabSucc -m 2 -a ENODEB01> mom . a2ThresholdRsrpPrim
