Lte Mobility Troubleshooting

LTE MOBILITY Prepared (Subject resp)

1 (20)

No.

Deepak Gupta Approved (Document resp)

Checked

Date

Rev

Reference

2017-02-28

LTE - Mobility OPTIMIZATION


2 (20)

No.


Checked

Date

Rev

Reference

2017-02-28

LTE Mobility has two phases- Preparation phase and Execution phase 1) Handover preparation:Handover preparation is the phase in which the target cell assigns the necessary radio resources for taking over the connection and sending back a handover command message containing the new radio parameters to the source cell.

2) Handover execution:The handover execution phase starts when the previously received handover command message is sent to the UE and successfully finished after the UE has arrived at the target cell

The ability to provide the requested service to the user with mobility Measurement Report : LTE Events › EVENT_A1– Serving cell becomes better than absolute threshold. › EVENT_A2– Serving cell becomes worse than absolute threshold. › EVENT_A3– Neighbor cell becomes amount of offset better than serving. › EVENT_A4– Neighbor cell becomes better than absolute threshold. › EVENT_A5– Serving cell becomes worse than absolute threshold1 AND neighbor cell becomes better than another absolute threshold2. › EVENT_B1– IRAT neighbor becomes better than threshold › EVENT_B2– Serving becomes worse than threshold1 and IRAT neighbor becomes better than threshold2


3 (20)

No.


Checked

Date

Rev

Reference

2017-02-28

Measurement Configuration (RSRP Based ) : LTE Events

INTRA –LTE HO PARAMETERS

Parameter

MO

Description

cellIndividualOffsetEUtran

EUtranCellRelation

isHoAllowed

EUtranCellRelation

Offset value specific to the neighbor cell relationship. Specifies if handover between the cells in this relation is allowed.

minBestCellHoAttempts

EUtranCellFDD

Number of attempts for handover to a cell better than the serving cell, before handover is attempted to the next best cell. If there is no next best cell in the report, then the RBS continues with a handover attempt to the best cell for every received measurement report.

a3offset

ReportConfigEUtraBestCell

The offset value for EventA3.

triggerQuantitya3


The quantity that triggers the EventA3.

hysteresisa3


The hysteresis value for EventA3.

timeToTriggera3


The time the EventA3 criterion has to be fulfilled before the first measurement report is sent.

filterCoefficientEUtraRsrp

UeMeasControl

The filtering Coefficient for EUTRA using measured quantity RSRP. Used to filter measurements before the event evaluation.

filterCoefficientEUtraRsrq

UeMeasControl

The filtering Coefficient for EUTRA using measured quantity RSRQ. Used to filter measurements before the event evaluation.

sMeasure

UeMeasControl

Serving cell quality threshold controlling if the user equipment is required to perform measurements.


4 (20)

No.


Checked

Date

Rev

Reference

2017-02-28

Three major groups of problems due to mobility can be identified when monitoring the EUTRAN:  Handover preparation failures  Handover execution failures  Data forwarding failures

HO Preparation Failures

Possible Causes 1. Configuration Issue with Term point definition 2.  Transmission (S1/X2) faults 3. License Issue 4. Congestion Issue 5. Invalid target Eutrancell (the target is not within the network/same MME pool) 6. Incorrect Parameter Settings in Target/Non launched Site is radiating.

HO Execution Failures

Possible Causes 1. Rach access issue on target cell 2. Uplink Interference 3. Overshooting Cell 4. PCI Collision 5. Invalid Target cell ( Target cell> 15/18 KM from UE, Greater then Cell range) 6. Improper Parameter settings 7. Improper Neighbour relation 8. RF abnormalities

Other Failures

Possible Causes 1. Poor Radio conditions ( Interference ) 2. Badly tuned handover parameters -Handover hysteresis and time-to-trigger settings are required to prevent excessive ping-pong handovers. Such behaviour increases signalling, risk of failure, and decreases throughput

HO Preparation Phase: Handover preparation phase can have different message flow based on S1/X2 interface. 1) X2 based HO Preparation :


5 (20)

No.


Checked

Date

Rev

2017-02-28

Important Massages: Counters -

RRC MEASUREMENT REPORT X2 HANDOVER REQUEST X2 HANDOVER REQUEST ACKNOWLEDGE. pmHoPrepAttLteIntraF pmHoPrepAttLteInterF pmHoPrepSuccLteIntraF pmHoPrepSuccLteInterF

2) S1 based HO Preparation :

Important Massages: -

Counters: -

RRC MEASUREMENT REPORT S1 HANDOVER REQUEST S1 HANDOVER REQUEST ACKNOWLEDGE FORWARD RELOCATION REQUEST FORWARD RELOCATION RESPONSE S1 HANDOVER COMMAND

pmHoPrepAttLteIntraF pmHoPrepAttLteInterF pmHoPrepSuccLteIntraF pmHoPrepSuccLteInterF

Reference


6 (20)

No.


Checked

Date

Rev

Reference

2017-02-28

HO Preparation Fail Troubleshooting and Analysis:Process Flowchart:

START

NO

Termpoint to MME missing on target cells. Check if all MME link is working if MME is in Pool.

Poor HO Preparation Yes

Incorrect NO Parameter setting in Target

Yes

NO

Handover preparation may fail because the target eNodeB cannot provide the necessary resources for the handover during congestion or cannot interpret the contents of the handover request message. Verify the SC556(SumofinitialaccessHOareallowed) are set as properly. Check the PmRRCConnEstabFailHighload & overload counter

Yes

Target cell might be loaded

NO

Yes

Check for X2Failure alarm or S1 Failure alarm in The target cell

Alarm in the NO target

NO Yes Overshooting

NO Use UETR/CTR

END

Check for Overshooting cells with PmBadcoveval counter. Recommend Physical Optimization of these cells and parameter optimisation to restrict the Cell footprint. Propose Coverage optimisation for sites having coverage holes.

Check for the cause.


7 (20)

No.


Checked

Date

Rev

Reference

2017-02-28

1) Configuration Issue with Term point definition :  Check Termpoint to MME for target cell has been defined properly. Using “st termpointtomme” status of connected MME can be checked, whether all are up and running, as if one is inactive, the load will be on the other MME’s in the pool.



Sometimes delete and create Termpoint definition would resolve the issue.

2) Transmission (S1/X2) faults:  

Check current alarm, Alarm history & activity logs to confirm drops due to HW fault. In case of transport fault check media continuity

3) License Issue:    

Check the license state for connected user at target cell Check the license state for RLC UM at target cell (source and target should have same state for RLC Mode) Check the license state for Multiple E-RAB at target cell. Check the license state for mobility at target cell.

Counters: pmHoPrepRejInLicConnUsers pmHoPrepRejInLicMob pmHoPrepRejInLicMultiErab pmHoPrepRejInLicRlcUm

Resolution:Load the license required on target cell. This could happen when there are heavy traffic on the target. The solution is to load high capacity parameters to the target and/or shake off some traffic from the cells with heavy traffic. 4) Congestion Issue: failure due to overloading & High Loading 

Check the congestion and loading at target cell. During HO preparation, UE will undergo admission control procedure at target cell. So, if target cell is heavily loaded or congested admission control deny the admission.


8 (20)

No.


Checked

Date

Rev

Reference

2017-02-28 

Counters “pmHoPrepRejInHighLoad” & “pmHoPrepRejInOverload” will be stepped at transmission of “RRC Connection Reject” during high load or overload circumstances. Resolution:

  

Change SC 556(numInitialAccessAndIncomingHo): Increase the maximum number of initial accesses and incoming handovers that are allowed during a time window without triggering the load control mechanism. Change EutranCellFDD.qRxLevMin to higher values, if the coverage is not an issue. Change EutranFreqRelation.qOffsetCellEUtran: enable faster cell re-selection from loaded cells towards other surrounding cells that satisfy the cell selection criteria. Change high capacity parameters to the target and/or shake off some traffic from the cells with heavy traffic.

Counters: pmHoPrepRejInHighLoad pmHoPrepRejInOverload pmHoPrepRejInBearerAdmissionRej pmHoPrepRejInOffloadAdmission pmHoPrepRejInMISigQCong 5) Invalid target eutrancell (the target is not within the network/same MME pool)



Check the invalid target like the eutrancellrelation which could be generated by toy eutrancell used for tests, interfering entities from the other network.

Resolution:The solution is to make isHoAllowed to false for the eutrancellrelation. 6) Incorrect Parameter Settings in Target/Non launched Site is radiating.  

Check for the Parameters in target cell. All MO class, S1 /X2 link should be created properly. Do parameter audit for the cell.


9 (20)

No.


Checked

Date

2017-02-28

Rev

Reference


10 (20)

No.


Checked

Date

Rev

Reference

2017-02-28

HO Execution Phase: Handover execution phase can have different message flow based on S1/X2 interface. 1) X2 based HO Execution :

Important Massages: RRC CONNECTION RECONFIGURATION RRC CONNECTION RECONFIGURATION COMPLETE S1 PATH SWITCH REQUEST MODIFY BEARER REQUEST MODIFY BEARER RESPONSE S1 PATH SWITCH ACKNOWLEDGE X2 UE CONTEXT RELEASE ‘Release Cause: Successful Handover’

Counters: -

pmHoExeAttLteIntraF pmHoExeAttLteInterF pmHoExeSuccLteIntraF mHoExeSuccLteInterF


11 (20)

No.


Checked

Date

Rev

Reference

2017-02-28 2) S1 based HO Execution :

Important Massages: RRC CONNECTION RECONFIGURATION RRC CONNECTION RECONFIGURATION COMPLETE S1 HANDOVER NOTIFY FORWARD RELOCATION COMPLETE FORWARD RELOCATION COMPLETE ACKNOWLEDGEMENT S1 PATH SWITCH ACKNOWLEDGE S1 UE CONTEXT RELEASE ‘Release Cause: Successful Handover’

Counters: -

pmHoExeAttLteIntraF pmHoExeAttLteInterF pmHoExeSuccLteIntraF mHoExeSuccLteInterF


12 (20)

No.


Checked

Date

Rev

Reference

2017-02-28

HO Execution Fail Troubleshooting and Analysis:Process Flowchart:

START

Poor HO Execution

NO

Incorrect Parameter settings in target ( PCI Collision in Target ) Yes Yes

NO Incorrect Parameter setting in Target

Yes

Check for UL RSSI and for Overshooting cells with PmBadcoveval counter. Recommend Physical Optimization of these cells and parameter optimisation to restrict the Cell footprint. Propose Coverage optimisation for sites having coverage holes

NO Yes Overshooting or Interference

Yes Improper NO Neighbor relation

NO

Hardware Fault

NO

END

Yes

Badly tuned handover parameters -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. Cellindivisualoffset can be played with on relation wise 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


13 (20)

No.


Checked

Date

Rev

Reference

2017-02-28 1) Rach access issue on target cell The UE uses the random access process during handover to gain synchronization with a new cell – Handover Execution Two types of RA procedures are defined:  CBRA (Contention Based Random Access): pmRaAttCbra, pmRaSuccCbra  CFRA (Contention Free Random Access): pmRaAttCfra, pmRaSuccCfra

Troubleshooting: i)

Sleeping Cells:

 

Check whether the cell is a “Sleeping Cell”. Due to their nature Sleeping Cells are difficult to detect and therefore cells in these conditions can remain out of service for long time periods causing major service outages. They do not report standard symptoms of failures in services e.g. hardware or software alarms The Counter pmRaSuccCbra is very low or zero; then the cell is considered a sleeping cell

Resolution:   

Check if Advance cell supervision feature is active or not. Lock/Unlock the cell. Re-Start.

ii) Uplink Interference: UL Interference can be either Internal - Interference due to other UE’s in the cell. External- Interference due to power supply sources.  Due to UL RSSI, RBS cannot detect/decode the request sent by UE. And so, UL RSSI has a great impact on handover performance.  ‘pmRadioRecInterferencePwr’ is the measured Noise and Interference power on PUSCH & ‘pmRadioRecInterferencePwrPucch’ is the measured Noise and Interference Power on PUCCH. These two counters can be used to identify if the noise floor of the cell is higher than it should be. Ideally this counter should be measured at the lowest traffic hours (early morning hours for most), to know the actual noise floor of the cell and perform further investigation to find the root cause for the same.

Resolution: 

Checking Alarms & HW faults in case of high RSSI in low traffic hours(external interference), auditing “pzeronominalpusch” & “pzeronominalpucch” powers if the noise floor is very high during the high traffic hours(internal interference).


14 (20)

No.


Checked

Date

Rev

Reference

2017-02-28 

preambleInitialReceivedTargetPower can be tuned to higher values, if the source of high RSSI is unknown, so that the RACH preamble signal can rise above the noise floor.

iii) Preamble Issues: 





High traffic on a cell can lead to conflicts between UEs and will impact the average call-setup time and user perception. In the current versions for Ericsson system, we cannot increase the RACH capacity, but in future versions, prachconfigurationindex can be tuned to increase the capacity of cell from RACH perspective. Preambles discarded for TA > CellRange: Counter for this is only available for CFRA, however it can be used to have an idea of the performance of CBRA. Counter "pmRaFailCfraMsg1DiscOoc” can be used to find the amount of discards because of TA > Cell-Range. Activating feature “MaximumCellRange” and increasing “CellRange” parameter. RachRootSequence to be tuned accordingly to accommodate 64 preambles. RootSequenceIndex(RachRootSequence) Conflict: RSI hits nearby can lead to conflicts in preambles detection in the concerned cells. RSI should be tuned considering the Cell Range, and the respective difference should be maintained in the potential interfering cells.

MTD Signal Traces: UPC_DL_MAC_CE_FI_SCHEDULE_RA_MSG2_REQ : Used to request creation of one RA Msg2 session to be scheduled for a subframe. UPC_DL_MAC_CE_FI_SCHEDULE_RA_MSG2_CFM: Confirmation of above UP_DLMACPE_CI_RA_MSG2_ALLOC_IND: Allocation information for messages on the common channel (TB description, L1 Control Description, RAR Information)

RACH_All_Traces.txt

2) Uplink Interference:

 

UL Interference can be either, Internal- Interference due to other UE’s in the cell. External- Interference due to power supply sources. Due to UL RSSI, RBS cannot detect/decode the request (RACH) sent by UE. And so, UL RSSI has a great impact on HO Execution. ‘pmRadioRecInterferencePwr’ is the measured Noise and Interference power on PUSCH & ‘pmRadioRecInterferencePwrPucch’ is the measured Noise and Interference Power on PUCCH.

Resolution: 



Checking Alarms & HW faults in case of high RSSI in low traffic hours(external interference), auditing “pzeronominalpusch” & “pzeronominalpucch” powers if the noise floor is very high during the high traffic hours(internal interference). preambleInitialReceivedTargetPower can be tuned to higher values, if the source of high RSSI is unknown, so that the RACH preamble signal can rise above the noise floor.


15 (20)

No.


Checked

Date

Rev

Reference

2017-02-28

3) Overshooting Cell: 

If target cell is overshooting and is out of cell range, then UE will observe RACH (RACH MSG 2) failure. For such case, HO preparation per relation is good but HO execution per relation would be poor.

Resolution: • • • • •

Physical Optimization of overshooting cell Parameter optimization to restrict the Cell footprint. Parameter (isHoAllwed / isRemoveAllowed) optimization to restrict Handover. Parameter (CellIndividualOffset) optimization. Propose Coverage optimization for sites having coverage holes

4) PCI Collision:

Due to PCI collision, It is possible that HO preparation would be done with wrong cell. In such cases HO preparation success is good but HO execution would be poor.

Resolution:  

Plan and change PCI for sites/cells observing PCI collision Parameter (isHoAllwed / isRemoveAllowed) optimization to restrict Handover.

5) Invalid Target cell ( Target cell> 15/18 KM from UE, Greater then Cell range):-

 

If UE during HO is >15/18Km from target cell and is out of cell range, then UE will observe RACH (RACH MSG 2) failure. For such case, HO preparation per relation is good but HO execution per relation would be poor.

Resolution: • •

Parameter (isHoAllwed / isRemoveAllowed) optimization to restrict Handover. Parameter (CellIndividualOffset) optimization.

6) Improper Parameter settings:

Badly tuned handover parameters -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.


16 (20)

No.


Checked

Date

Rev

Reference

2017-02-28 “Cellindivisualoffset” can be played with, on these relations 7) Improper Neighbor relation:

 



In LTE the neighbors are defined by 2 ways:I. Automatic NBR definition based measurement reports and configuration thresholds: ANR and X2 II. Manually defined Neighbors: - Operator Check if the Neighbor relations were added by ANR, X2 or Operator. Do these relations make sense? Check the parameter “createdBy”

If these relations are not needed and we delete them, ANR will add them again, because UEs will send the same measurements reports

Resolution: 

Best thing to do  Check overshooting and propagation  Optimize Tilt  Change cellIndividualOffsetEUtran from 0 (default) to -12 dB to avoid these two relations to be used (comment)  

Based on equation, cellindividualoffsetEUtran has to be negative to lessen the Handover attempts or vice versa. Blacklist those relations using isHoAllowed parameter.

Setting isHoAllowed to FALSE blacklists the cell in both RRC idle mode and RRC connected mode. If a UE reports a blacklisted cell as a candidate for HO the node does not trigger a HO.

8) RF abnormalities:  

Radio abnormalities include imbalance between the uplink (UL) and downlink (DL) quality, weak coverage and the UE does not use the maximum transmit power. During HO execution, UE has not received RRC Connection Reconfiguration message (poor DL) or eNodeB has not received RRC Connection Reconfiguration Complete messages within the related timeout duration.


17 (20)

No.


Checked

Date

Rev

Reference

2017-02-28

To be investigated: 

Radio Interference: DL interference from neighboring cells, DL interference from external systems, and UL interference need to be investigated. The counters that can be used to find out the same are: pmSinrPucchDistr, pmSinrPuschDistr, pmRadioUeRepCqiDistr, pmRadioTxRankDistr, pmRadioRecInterferencePwrPucch. eg: PUCCH received power should be around the pZeroNorminalPucchPwr (default:-117 dBm)

 Cell coverage issues can be detected using “pmRadioTbsPwrRestricted” & “pmbadcovevalreport”.  UEs trying to access the network in poor Downlink RF conditions can be determined by looking for high pegs in “pmRrcConnEstabAttReatt”.    

Imbalance between UL and DL Connected Mode mobility Priority should be set properly. ConfOutputpower AllowedMeasBandwidth - 50 for 10Mhz, 25 for 5Mhz

Resolution: Tuning pZeroNorminalPucchPwr depending on the values from pmRadioRecInterferencePwrPucch  Tuning t300 in cases where, the radio conditions can be improved much and immediate results are required in the success rate.  Change EutranCellFDD.qRxLevMin to higher values, if the coverage is not an issue.  Change EutranFreqRelation.qOffsetCellEUtran: enable faster cell re-selection towards better cells.

Other: 

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.


18 (20)

No.


Checked

Date

Rev

Reference

2017-02-28     

Possible hardware faults are: board is overloaded, faulty RRU, a common public radio interface (CPRI) link is faulty and GPS clock source is faulty Handover preparation may fail due to 3 main contributors: Admission, SRB or DRB creation by baseband and Timers expiry. "Admission" failures are reflected by Local event: UE_ADMISSION_REJECT. See CPI-“Admission Control” for details. "Bearer creation" failures are reflected by Local events: SRB1_SETUP_REJECT, SRB2_SETUP_REJECT, ERAB_DRB_SETUP_REJECT and also by pmCounters: pmErabEstabFail*. Timers expiry:  T304- Ho time out







"tRelocPrep" expires, which means no response from MME received

"tRrcConnectionSetup" is started to supervise the reception of the answer from the UE. If the connection is set up correctly, the timer is stopped and the connSetupCfm is sent to uehRrcSigCtxt, else the connSetupRej is sent. In case of S1 handover there may also be three more failure reasons:  1 - “Outgoing S1 Handover Preparation Failure” with local events: S1_HANDOVER_PREPARATION_FAILURE and HO_OUT_PREPARATION_FAILURE. This


19 (20)

No.


Checked

Date

Rev

Reference

2017-02-28 is due to MME sending the "S1 Handover Preparation Failure” message that will stop the handover.  2 - “Outgoing S1 Handover Preparation Timeout” with local events “TS1RELOCprepexpiry” and “S1HANDOVER_CANCEL”. This may be due to: Timer "tRelocPrep" expires, which means no response from MME received or "Handover Cancel" message being sent to MME. 3 - “Cancel S1 Handover” with no local events. This is caused by sending an S1 AP HANDOVER CANCEL message from source to MME. The sequence is called when reestablishment from a UE is attempted in the source cell during an ongoing S1 handover. If reestablishment was attempted before the HANDOVER COMMAND message was received, then the handover is cancelled only after this message was received.

 

Curren t

Node

5 sec

5

eNodeB

Timer on ENodeB that begins once eNodeB sends Handover Required Command to MME and stops once Handover Command is received from MME.

5 sec

10

eNodeB

Timer on ENodeB that begins once eNodeB receives Handover Command from MME and stops once S1 UE Context Release Command is received from MME. At expiry eNodeB sends S1 UE Context Release Request to MME.

Parameter Name

Default/GS

SC 183 -TRelocPrep

SC 184 - TRelocOverall

Range

Comments

Analysis and Additional Data Collection: Traces Functional Traces:

-----------------te e all Ft_RRC_ASN - shows all L3 RRC messages. te e all Ft_S1AP_ASN - shows all L3 S1 messages. te e all Ft_X2AP_ASN - shows all L3 X2 messages. te e all Ft_LTE_EXCEPTION - shows any abnormal conditions that may occur. te e all Ft_UE_RAC_MEASUREMENTS – shows all measurement related decisions te e all Ft_OUTGOING_HANDOVER- shows all outgoing handover decisions te e all Ft_INCOMMING_HANDOVER - shows all incoming handover decisions te e all Ft_S1_COMMON_SIGNALING te e all Ft_RRC_CONN_SETUP te e all Ft_CONN_COORD te e all Ft_RLC_FAILURE te e all Ft_RRC_CONN_REESTABLISHMENT

Look for the following PmEvents in Cell Trace. pmEvent Name

Event Description and Trigger

INTERNAL_EVENT_HO_WRONG_CELL_REEST

Sent when the eNB detects a HO to wrong cell as defined in 3GPP TS 36.300. The event contains the identity of the relation to the cell where UE reestablishment occurred.

INTERNAL_EVENT_HO_WRONG_CELL

Sent when the eNB detects a HO to wrong cell as defined in 3GPP TS 36.300

INTERNAL_EVENT_TOO_EARLY_HO

Sent when the eNB detects a too early HO as defined in 3GPP TS 36.300

INTERNAL_EVENT_TOO_LATE_HO

Sent when the eNB detects a too late HO as defined in 3GPP TS 36.300

S1_HANDOVER_CANCEL_ACKNOWLEDGE

S1_HANDOVER_CANCEL_ACKNOWLEDGE received. See 3GPP 36.413


20 (20)

No.


Checked

Date

Rev

Reference

2017-02-28 S1_HANDOVER_CANCEL

S1_HANDOVER_CANCEL sent. See 3GPP 36.413

S1_HANDOVER_FAILURE

S1_HANDOVER_FAILURE sent. See 3GPP 36.413

S1_HANDOVER_PREPARATION_FAILURE

S1_HANDOVER_PREPARATION_FAILURE received. See 3GPP 36.413

X2_HANDOVER_CANCEL

X2_HANDOVER_CANCEL recevied or sent. See 3GPP 36.423

X2_HANDOVER_PREPARATION_FAILURE

X2_HANDOVER_PREPARATION_FAILURE received or sent. See 3GPP 36.423

Features that will help in improving the Mobility KPI: 1. Mobility Control at Poor Coverage:

The probability that correct mobility action is performed will be increased in some specific deployment scenarios. With correct mobility action the outage time in case of bad coverage will be decreased with a deployment scenario dependent figure. 2. Service Triggered Mobility:

Inter-frequency or IRAT mobility is triggered based differently based on service. Certain services may be given higher protection against bad coverage, e.g. to ensure good VoIP quality QCI=1 may have a higher threshold than best effort traffic. 3. Best Neighbor Relations for Intra-LTE Load Management:

Load relations are automatic created instead of manually. The feature will reduce operational cost and improve the performance of the load management features Inter-frequency load balancing and Inter-frequency offload as the best neighbor relations are always configured. 4. Automated Mobility Optimization:

Automated Mobility Optimization automatically adjusts handover margin by tuning cell individual offset. It analyse handover performance related to too early, too late and to wrong cell using feedback from executed handovers.

Lte Mobility Troubleshooting

Recommend Documents