Optimization Handbook

LTE Optimization Handbook LA4.0 Document number: LTE/IRC/APP/032105 LTE/IRC/APP/032105 Document issue: V05.03 / EN Document status: Approved-Standard Data classification: Date:

Confidential 30/Mar/2012

Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

Copyright 2010 Alcatel-Lucent, Alcatel-Lucent, All Rights Rights Reserved Reserved UNCONTROLLED COPY: The master of this document is stored on an electronic database and is “write protected”; it may be altered only by authorized persons. While copies may be printed, it is not recommended. Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded as uncontrolled copies. ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of AlcatelLucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information contained herein confidential, shall disclose the information only to its employees with a need to know, and shall protect the information from disclosure and dissemination to third parties. Except as expressly authorized authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have received this document in error, please notify the sender and destroy it immediately.

LTE Optimization Handbook LA4.0

MGR /TIPS /NEA

1 INTRODUCTION The document is the optimization handbook for the main RF features and related parameters per domain of Alcatel-Lucent LTE release LA4.0 The procedures detailed in this document can be used to improve the network performance so that it meets contractual and technical objectives prior to a commercial launch. It can also be used in a continuous process as the network evolves due to addition of new cells, increase in traffic load or introduction of new features.

1.1 SCOPE Main purpose of the document consists of proposing parameter tuning that shall mitigate observed performance degradations. The following domains are distinguished for parameter tuning: Coverage Throughput Latency Capacity Mobility (both connected and idle mode) The parameters described in this document are related to the Alcatel-Lucent LTE LA4.0 release.

1.2 AUDIENCE FOR THIS DOCUMENT The audience of this document is typically involved in following activities: Radio Network Design Radio Network Optimization First-Off Trials Commercial Network Deployment


LTE/IRC/APP/032105 LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 2/194


MGR /TIPS /NEA

2 PUBLICATION HISTORY Version.Ed/ Date Status Language (dd.mmm.yyyy) 05.01/EN

04.Nov.2011

05.02/EN

05.Dec.2011

05.03/EN

30.Mar.2012

Name

Jorge Santos Approved Jorge preliminary Santos Approved Jorge standard Santos

Draft

Reason of changes / short description of significant changes to previous edition Creation Reading Cycle Completed (DR4 Step) DR.5 milestone



V05.03 / EN

Approved-Standard

30/Mar/2012

Page 3/194


MGR /TIPS /NEA

TABLE OF CONTENTS

1 INTRODUCTION .....................................................................................................................................2

1.1 SCOPE ..............................................................................................................................................2 1.2 AUDIENCE FOR THIS DOCUMENT .............................................................................................................2 2 PUBLICATION HISTORY .........................................................................................................................3 3 REFERENCE DOCUMENTS ...................................................................................................................12 4 RELEASE RELATED DOCUMENTS ........................................................................................................12 5 PROCESS AND METHODOLOGY ..........................................................................................................13

5.1 TOOLS AND RESOURCES ......................................................................................................................13 5.2 OPTIMIZATION TOOLS ........................................................................................................................13 6 OPTIMIZATION PARAMETERS OVERVIEW ...........................................................................................14

6.1 PARAMETERS IMPACTING COVERAGE ......................................................................................................15 6.2 PARAMETERS IMPACTING ACCESS ........................................................................................................16 6.3 PARAMETERS IMPACTING THROUGHPUT..................................................................................................16 6.4 PARAMETERS IMPACTING LATENCY ........................................................................................................17 6.5 PARAMETERS IMPACTING CAPACITY .......................................................................................................17 6.6 PARAMETERS IMPACTING MOBILITY ........................................................................................................17 6.6.1 LTE 6.6.2 LTE 6.6.3 LTE 6.6.4 LTE

– LTE mobility ..............................................................................................................18 – UMTS mobility ............................................................................................................19 – GSM mobility ..............................................................................................................20 – HRPD mobility ............................................................................................................21

7 NEW FEATURES IN LA4.0 ...................................................................................................................22 8 COVERAGE OPTIMIZATION HINTS ......................................................................................................24

8.1 PARAMETERS OPTIMIZATION FOR IMPROVING DOWNLINK COVERAGE .............................................................24 8.1.1 Referencesignalpower ........................................................................................................24 8.1.2 PhichResource .....................................................................................................................25 8.2 PARAMETERS OPTIMIZATION FOR IMPROVING UPLINK COVERAGE .................................................................26 8.2.1 sIRTargetforReferencePUCCHFormat .................................................................................26 8.2.2 sEcorrInit, sEcorrstepforlowerbler & secorrstepforhigherbler ..........................................26 8.2.3 ulSyncSINRsyncToOOSTreshold & UlSyncSINROOStoSyncTreshold .....................................27 8.2.4 deltaFPUCCHFormat1 .........................................................................................................28 8.2.5 CELL COVERAGE ..................................................................................................................29 8.2.5.1 UL CELL COVERAGE ........................................................................... 29 8.2.5.2 DL CELL OUtdoor COVERAGE ................................................................ 29 8.2.5.3 TOTAL CELL COVERAGE....................................................................... 30 8.2.5.4 PUSCH FRACTIONAL POWER CONTROL ..................................................... 30 8.2.6 PUSCHPOWERCONTROLALPHAFACTOR ...............................................................................31 8.2.7 qRxLevMin ...........................................................................................................................32 8.2.8 p0NominalPUSCH ................................................................................................................36 8.2.9 uplinkSIRtargetValueForDynamicPUSCHscheduling ............................................................38 Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 4/194


MGR /TIPS /NEA

9 ACCESS OPTIMIZATION HINTS ............................................................................................................39

9.1 PARAMETERS OPTIMIZATION FOR IMPROVING ATTACH/DETACH PROCEDURES. .................................................40 9.1.1 preambleInitialReceivedTargetPower ................................................................................40 9.1.2 PreambleTransmitPowerStepSize .......................................................................................43 9.1.3 Scheduled TRANSMISSION (deltaPreambleMsg3 or tPCRACHMsg3) ....................................44 9.1.4 deltapreamblemsg3 ............................................................................................................46 9.1.5 tPCRACHMsg3 ......................................................................................................................46 10 DOWNLINK THROUGHPUT OPTIMIZATION HINTS ...........................................................................46

10.1 PARAMETERS OPTIMIZATION FOR IMPROVING DOWNLINK THROUGHPUT .......................................................47 10.1.1 dlMCSTransitionTable .......................................................................................................47 10.1.2 dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv ........................................................50 10.1.3 dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer ................................................51 10.1.4 dlSinrThresholdBetweenOLMimoAndTxDiv .......................................................................52 10.1.5 AlphaFairnessfactor ..........................................................................................................53 10.1.6 DynamicCFIEnabled ..........................................................................................................54 10.1.7 CFI .....................................................................................................................................55 10.1.8 cfi1allowed .......................................................................................................................55 10.1.9 cfi2allowed .......................................................................................................................55 10.1.10 cfi3allowed ......................................................................................................................56 11 UPLINK THROUGHPUT OPTIMIZATION HINTS .................................................................................56

11.1 PARAMETERS OPTIMIZATION FOR IMPROVING UPLINK THROUGHPUT ...........................................................56 11.1.1 uplinkSIRtargetValueForDynamicPUSCHscheduling. .........................................................56 11.1.2 pUSCHPowerControlAlphaFactor ......................................................................................58 11.1.2.1 puschpowercontrolalphafactor combination tests (LAB) ............................... 60 11.1.2.2 PUSCHPOWERCONTROLALPHAFACTOR COMBINATION TESTS (LIVE NETwork)....... 67 11.1.3 ulSchedPropFairAlphaFactor .............................................................................................69 12 LATENCY OPTIMIZATION HINTS .......................................................................................................71

12.1 PARAMETERS OPTIMIZATION LATENCY .................................................................................................71 12.1.1 Test RECOMMENDATION AND results ................................................................................72 12.1.1.1 Attach latency ................................................................................. 72 12.1.1.2 Attach Latency Results for LA4.0.1 ........................................................ 73 12.1.1.3 Last Update Regarding performance (ATTACH & Activation) .......................... 75 12.1.1.4 Idle to active latency ......................................................................... 75 12.1.1.5 Idle to active latency Results for LA4.0.1 ................................................. 77 12.1.1.6 Detach latency ................................................................................. 78 12.1.1.7 Ping Latency results for LA4.0.1 ............................................................ 79 13 CAPACITY OPTIMIZATION HINTS ......................................................................................................80

13.1 PARAMETERS OPTIMIZATION FOR IMPROVING CAPACITY ...........................................................................80 13.1.1 Enb CAPACITY CONFIGURATIONS ......................................................................................80 13.1.2 alphaFairnessFactor ..........................................................................................................81 13.1.3 UlSchedPropFairAlphaFactor ............................................................................................82 14 LTE –LTE MOBILITY OPTIMIZATION HINTS ......................................................................................83

14.1 LTE-LTE MOBILITY .........................................................................................................................84 14.1.1 Check Intra Neighour List at Data base network .............................................................84 14.1.2 Inter Frequency Neighbour declaration ...........................................................................84 14.1.3 How to avoid ping pong efect in network ........................................................................86 14.1.4 Mobility parameters ..........................................................................................................87 14.1.5 INTRA-FREQUENCY ( IDLE MODE ) .......................................................................................88 14.1.5.1 QRXLEVMIN ..................................................................................... 89 14.1.5.2 SINTRASEARCH ................................................................................. 90 Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 5/194


MGR /TIPS /NEA

14.1.5.3 QHYST ........................................................................................... 90 14.1.5.4 QOFFSETCELL................................................................................... 91 14.1.5.5 QRXLEVMINOFFSET ............................................................................ 92 14.1.5.6 TRESELECTIONEUTRAN........................................................................ 92 14.1.5.7 TRESELECTIONEUTRASFMEDIUM ............................................................. 93 14.1.5.8 TRESELECTIONEUTRASFHIGH ................................................................ 93 14.1.5.9 tevaluation ..................................................................................... 94 14.1.5.10 NCELLCHANGEHIGH .......................................................................... 95 14.1.5.11 NCELLChANGEMEDIUM ....................................................................... 95 14.1.5.12 QHYSTSFHiGH ................................................................................. 96 14.1.5.13 QHYSTSFMEDIUM .............................................................................. 96 14.1.6 INTRA-FREQUENCY ( Active MODE ) ....................................................................................97 14.1.6.1 FILTERCOEFFICIENTRSRP ..................................................................... 98 14.1.6.2 HYSTERESIS ..................................................................................... 99 14.1.6.3 TIMETOTRIGGER .............................................................................. 100 14.1.6.4 CELLINDIVIDUALOFFSET ..................................................................... 100 14.1.6.5 EVENTA3OFFSET .............................................................................. 101 14.1.6.6 OFFSETFREQ ................................................................................... 102 14.1.6.7 REPORTINTERVAL ............................................................................. 102 14.1.6.8 MAXREPORTCELLS ............................................................................ 103 14.1.6.9 REPORTAMOUNT .............................................................................. 103 14.1.6.10 Call flow for Inter-eNB mobility, X2 HO – UE in RRC Connected .................... 104 14.1.6.11 Call flow for Inter-eNB mobility, S1 HO – UE in RRC Connected ....................106 14.1.6.12 Intra-eNB HO Interruption time results for La4.0.1 ...................................107 14.1.6.13 Reference for all the Software used .....................................................108 14.1.7 INTER-FREQUENCY ( IDLE MODE ) .....................................................................................108 14.1.7.1 QRXLEVMIN .................................................................................... 110 14.1.7.2 SNONINTRASEARCH ........................................................................... 111 14.1.7.3 THRESHSERVINGLOW ......................................................................... 112 14.1.7.4 THRESHXLOW .................................................................................. 113 14.1.7.5 tHREShXHIGH .................................................................................. 114 14.1.7.6 TRESELECTIONEUTRAN....................................................................... 114 14.1.7.7 TRESELECTIONEUTRASFMEDIUM ............................................................ 115 14.1.7.8 TRESELECTIONEUTRASFHIGH ............................................................... 115 14.1.7.9 NCELLCHANGEHIGH .......................................................................... 115 14.1.7.10 NCELLChANGEMEDIUM ...................................................................... 115 14.1.7.11 QHYSTSFHiGH ................................................................................ 115 14.1.7.12 QHYSTSFMEDIUM ............................................................................. 115 14.1.8 INTER-FREQUENCY ( ACtive MODE ) .................................................................................116 14.1.8.1 THRESHOLDEUTRARSRP ...................................................................... 118 14.1.8.2 THRESHOLD2EUTRARSRP .................................................................... 118 14.1.8.3 FILTERCOEFFICIENTRSRP .................................................................... 119 14.1.8.4 HYSTERESIS .................................................................................... 119 14.1.8.5 TIMETOTRIGGER .............................................................................. 119 14.1.8.6 OFFSETFREQ ................................................................................... 119 14.1.8.7 REPORTINTERVAL ............................................................................. 119 14.1.8.8 MAXREPORTCELLS ............................................................................ 120 14.1.8.9 REPORTAMOUNT .............................................................................. 120 14.1.9 Inter-Frequency HO TRIal results (Verizon Winchester Market) ....................................120 14.1.9.1 Considerations for Band 13 ................................................................. 120 14.1.9.2 Considerations for Band 4 ................................................................... 122 14.1.9.3 UE used for Multi-Band ...................................................................... 122 14.1.9.4 Network Configuration ...................................................................... 122 14.1.9.5 Test cases ...................................................................................... 123 15 IRAT MOBLILTY OPTIMIZATION HINTS ...........................................................................................128

15.1 LTE-UMTS OPTIMIZATION HINTS ....................................................................................................128 15.1.1 Inter-Frequency ( IDLE MODE ) .........................................................................................129 15.1.1.1 qRxLevMin ..................................................................................... 132 15.1.1.2 sNonIntraSearch .............................................................................. 133 Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 6/194


MGR /TIPS /NEA

15.1.1.3 threshServingLow ............................................................................. 133 15.1.1.4 threshXLow .................................................................................... 134 15.1.1.5 tReselectionUtra .............................................................................. 135 15.1.1.6 TRESELECTIONUTRASFMEDIUM ............................................................. 136 15.1.1.7 TRESELECTIONUTRASFHIGH ................................................................. 137 15.1.1.8 NCELLCHANGEHIGH .......................................................................... 137 15.1.1.9 NCELLCHANGEMEDIUM ....................................................................... 138 15.1.1.10 QHYSTSFHiGH ................................................................................ 139 15.1.1.11 QHYSTSFMEDIUM ............................................................................. 139 15.1.2 Inter-Frequency ( ACTIVE MODE ) ....................................................................................140 15.1.2.1 UE measurements needed for LA3.0 PS HO to UTRA-FDD .............................140 15.1.2.2 LA3.0 PS HO Preparation .................................................................... 141 15.1.2.3 LA3.0 PS HO Execution ...................................................................... 142 15.1.2.4 THRESHOLDEUTRARSRPB2 ................................................................... 145 15.1.2.5 THRESHOLDutrarscp .......................................................................... 146 15.1.2.6 OFFSETFREQUTRA ............................................................................ 146 15.1.2.7 FILTERCOEFFICIENTOFQUANTITYCONFIGUTRA .......................................... 147 15.1.2.8 HYSTERESIS .................................................................................... 148 15.1.2.9 TIMETOTRIGGER .............................................................................. 149 15.1.2.10 REPORTINTERVAL ............................................................................ 149 15.1.2.11 MAXREPORTCELLS ........................................................................... 150 15.1.2.12 REPORTAMOUNT ............................................................................. 150 15.1.3 call flow for redirection to UTran ..................................................................................152 15.1.4 Call flow for PS HO Preparation Phase ...........................................................................153 15.1.5 Call flow for PS HO Excution Phase ................................................................................153 15.2 LTE-GSM MOBILITY OPTIMIZATION HINTS .........................................................................................154 15.2.1 IDLE MODE .......................................................................................................................154 15.2.1.1 qRxLevMin ..................................................................................... 157 15.2.1.2 SNONINTRASEARCH ........................................................................... 158 15.2.1.3 THRESHSERVINGLOW ......................................................................... 158 15.2.1.4 THRESHXLOW .................................................................................. 159 15.2.1.5 TRESELECTIONGERAN ........................................................................ 160 15.2.1.6 TRESELECTIONGERANSFMEDIUM ............................................................ 161 15.2.1.7 TRESELECTIONGERANSFHIGH ............................................................... 162 15.2.1.8 NCELLCHANGEHIGH .......................................................................... 162 15.2.1.9 NCELLCHANGEMEDIUM ....................................................................... 163 15.2.1.10 QHYSTSFHiGH ................................................................................ 163 15.2.1.11 QHYSTSFMEDIUM ............................................................................. 164 15.2.2 ACTIVE MODE ..................................................................................................................165 15.2.2.1 THRESHOLDEUTRARSRPB2 ................................................................... 165 15.2.2.2 THRESHOLDGERAN............................................................................ 166 15.2.2.3 OFFSETFREQGERAN........................................................................... 167 15.2.2.4 FILTERCOEFFICIENTOFQUANTITYCONFIGGERAN ........................................167 15.2.2.5 HYSTERESIS .................................................................................... 168 15.2.2.6 TIMETOTRIGGER .............................................................................. 169 15.2.2.7 REPORTINTERVAL ............................................................................. 169 15.2.2.8 MAXREPORTCELLS ............................................................................ 170 15.2.2.9 REPORTAMOUNT .............................................................................. 170 15.2.3 call flow for redirection to Geran ..................................................................................171 15.2.4 Call flow for Cell Change Order with/without NACC .....................................................172 15.3 LTE-HRPD MOBILITY OPTIMIZATION HINTS .......................................................................................172 15.3.1 IDLE MODE .......................................................................................................................172 15.3.1.1 SNONINTRASEARCH ........................................................................... 174 15.3.1.2 THRESHXLOW .................................................................................. 174 15.3.1.3 TRESELECTIONCDMAHRPD ................................................................... 175 15.3.1.4 TRESELECTIONHRPDSFMEDIUM ............................................................. 176 15.3.1.5 TRESELECTIONHRPDSFHIGH ................................................................. 176 15.3.1.6 NCELLCHANGEHIGH .......................................................................... 177 15.3.1.7 NCELLCHANGEMEDIUM ....................................................................... 177 15.3.1.8 QHYSTSFHiGH ................................................................................. 178 Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 7/194


MGR /TIPS /NEA

15.3.1.9 QHYSTSFMEDIUM .............................................................................. 179 15.3.2 ACTIVE MODE ..................................................................................................................179 15.3.2.1 THRESHOLDEUTRARSRPB2 ................................................................... 180 15.3.2.2 THRESHOLDCDMA2000 ....................................................................... 181 15.3.2.3 OFFSETFREQ ................................................................................... 181 15.3.2.4 HYSTERESIS .................................................................................... 182 15.3.2.5 TIMETOTRIGGER .............................................................................. 183 15.3.2.6 REPORTINTERVAL ............................................................................. 184 15.3.2.7 MAXREPORTCELLS ............................................................................ 184 15.3.2.8 REPORTAMOUNT .............................................................................. 185 15.3.3 call flow for redirection to HRPD ...................................................................................186 16 ABBREVIATIONS AND DEFINITIONS ................................................................................................186

16.1 ABBREVIATIONS ............................................................................................................................186


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 8/194


MGR /TIPS /NEA

LIST OF FIGURES Figure 8.2-1: Throughput for single UE vs. Path loss (Lab environment) .......................................................30 ......................................................................... ...........34 Figure 8.2-2: Throughput vs. RSRP – 700 (Field Results VzW) .............................................................. Figure 8.2-3: Throughput vs. RSRP – AWS (Field Results VzW). .......................................................................35 ................................................................................................................... ..........................................................35 Figure 8.2-4: qRxLevMin Selection ......................................................... Figure 8.2-5: Po_pusch_Nominal Impact .......................................................... ......................................................................................................... ...............................................38 Figure 8.2-6: Slope - PuschPowerControl vs. uplinkSIRtargetValueForDyna uplinkSIRtargetValueForDynamicPUSCHscheduling micPUSCHscheduling ................. 39 Figure 9.1-1: preambleTransMax vs. preambleInitialRceivedTargetPower vs. ............................................................................................................. ............................................... 41 preambleTransmitPowerStepSize .............................................................. Figure 9.1-2: Po_preamble impact on UE Tx Power vs. PL(RA) (TRY1) ..........................................................41 Figure 9.1-3: Po_preamble impact on UE Tx Power vs. PL (RA) .....................................................................42 Figure 9.1-4: preambleTransMax vs. preambleInitialRceivedTargetPower vs. ............................................................................ ......... 42 preambleTransmitPowerStepSize (example of values) ................................................................... ...................................................................................... ...................... 45 Figure 9.1-5: Parameters dependency and relations ................................................................ Figure 10.1-1: Radio link Quality vs. MCS Robustness vs. Throughput . ...........................................................48 Figure 10.1-2: Radio link Quality vs. dlMCSTransition Table vs. Throughput .................................................48 ........................................................................................................ ...............................................51 Figure 10.1-3: Dl Sinr Threshold Example ......................................................... Figure 10.1-4: CL 2Layer-1Layer 2Layer-1Layer SNR Switch Threshold: Threshold: 10 dB (purple) vs. 12 dB (blue) (blue) AWGN (Lab ..................................................................................................................................... ................................................................................. ......... 52 results VzW) ............................................................. Figure 10.1-5: CL 2Layer-1Layer SNR Switch Threshold: 10 dB (purple) vs. 12 dB (blue) EPA 5Hz, .................................................................................................... .................................52 Medium Correlation (Lab Results VzW) ................................................................... ........................................................................................................ ...............................................53 Figure 10.1-6: Dl Sinr Threshold Example ......................................................... ........................................................................................ ...................... 54 Figure 10.1-7: alphaFairnessFactor Change Impact .................................................................. Figure 11.1-1: Impact of the pUSCHPowerControlAlphaFactor =1.0 in MCS usage. .......................................59 Figure 11.1-2: Impact of the pUSCHPowerControlAlphaFactor =0.8 in Throughput per RB ........................... 59 Figure 11.1-3: Impact of the pUSCHPowerControlAlphaFactor =0.7 in Throughput per RB. ..........................60 ............................................................................................................................... .....................................................................61 Figure 11.1-4: Set 1 Result .......................................................... Figure 11.1-5: Set 1UL Throughput & UE TX Power vs. Path loss ...................................................................62 Figure 11.1-6: SIR Target for theoretical assumptions with different alpha factor values ............................63 Figure 11.1-7: UL SIR Target for theoretical assumptions with different alpha factor v alues ......................63 Figure 11.1-8: Different alpha factor comparison (Throughput, PRB‟s, SINR & PUSCH SINR Target) ............ 64 Figure 11.1-9: UL Throughput & UE TX Power vs. Path loss alpha factor 0.7 0. 7 & 1 with set 3 .........................65 Figure 11.1-10: UL Throughput & UE TX Power vs. Path loss for alpha factor 0.7 for all sets ......................66 Figure 11.1-11: UL Throughput vs. Path loss for set1 & set3 with alpha factor 0.7 and 1 ............................67 Figure 11.1-12: UE TX Power vs. Path loss for set1 & set3 with alpha factor 0.7 and 1 ................................67 ................................................................................ ......... 68 Figure 11.1-13: Fractional Power Control Slope vs. Sets ....................................................................... ........................................................................... ......... 70 Figure 11.1-14: Impact of the ulSchedPropFairAlphaFactor .................................................................. Figure 12.1-1: Example for IMSI attach procedure (with authentication) ......................................................73 Figure 12.1-2: Example for GUTI attach procedure (no authentication) ........................................................73 .................................................................................................... ................................. 76 Figure 12.1-3: Idle to active message chart ................................................................... ................................................................................... ...................... 77 Figure 12.1-4: Example of total Idle to active latency ............................................................. Figure 14.1-1: Intra HO Neighbour list . ............................................................................................................84 Figure 14.1-2: Coverage analysis AMX trial – done by ARFCC team ................................................................85 ........................................................................................................... ...............................................86 Figure 14.1-3: X2-Link creation by ANR ............................................................ .................................................................................................................... ..........................................................87 Figure 14.1-4: HO ping pong area .......................................................... Figure 14.1-5: LTE to LTE Mobility – Measurement phase (RSRP vs. Time) ....................................................88 Figure 14.1-6: LTE to LTE Mobility – Ranking Phase .................................................................. ........................................................................................ ...................... 89 Figure 14.1-7: LTE to LTE Mobility – Decision Phase (RSRP vs. Time) . ............................................................89 ...................................................................................... ...................... 97 Figure 14.1-8: LTE to LTE Mobility – Handover cases ................................................................ ....................................................................................................................... ..........................................................98 Figure 14.1-9: Theoretical view ............................................................. Figure 14.1-10: filterCoefficientRSRP - Theoretical comparison (Simulation Analysis) .................................98 Figure 14.1-11: Call flow for Inter-eNB mobility, X2 HO – UE in RRC Connected (1) ...................................104 Figure 14.1-12: Call flow for Inter-eNB mobility, X2 HO – UE in RRC Connected (2) ...................................105 Figure 14.1-13: Call flow for Inter-eNB mobility, S1 HO – UE in RRC Connected (1) . ...................................106 Figure 14.1-14: Call flow for Inter-eNB mobility, S1 HO – UE in RRC Connected (2) . ...................................107 ................................................................................. .................... 109 Figure 14.1-15: LTE to LTE Mobility – Cell Reselection ............................................................. ............................................................................................... .................................. 109 Figure 14.1-16: Idle Mode Algorithm B4 B13 ............................................................. ............................................................................................... .................................. 110 Figure 14.1-17: Idle Mode Algorithm B13 B4 ............................................................. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction


V05.03 / EN

Approved-Standard

30/Mar/2012

Page 9/194


MGR /TIPS /NEA

............................................................................................................ .............................................116 Figure 14.1-18: Events State Machine ............................................................... Figure 14.1-19: Example of A3 Event based HO for B13 and B4 ...................................................................117 Figure 14.1-20: Example of A5 Event based HO for B13 and B4 ...................................................................117 ......................................................................................................... .............................................123 Figure 14.1-21: Network Configuration ............................................................ Figure 14.1-22: Time spent in each Band vs. Number of Reselection Attempts for 50% OCNS ....................127 Figure 14.1-23: Time spent in each Band vs. Number of Reselection Attempts for 100% OCNS .................. 127 Figure 15.1-1: LTE to UTRAN mobility in the context of IRAT mobility ........................................................129 .................................................................................................... ............................... 130 Figure 15.1-2: Cell Reselection procedure ..................................................................... .................................................................................................................. ........................................................ 130 Figure 15.1-3: UE rules follow-up .......................................................... Figure 15.1-4: LTE to UTRAN Mobility – (RSRP vs. Time) measurement phase .............................................131 Figure 15.1-5: LTE to UTRAN Mobility – Algorithm Cell Reselection toward lower priority UTRAN Cell ......132 Figure 15.1-6: LTE to UTRAN Mobility – (RSRP vs. Time) Decision De cision Phase .....................................................132 Figure 15.1-7: UE measurements needed for LA3.0 PS HO to UTRA-FDD .....................................................140 ........................................................................................................... ............................................. 142 Figure 15.1-8: LA3.0 PS HO Execution .............................................................. .......................................................................... ....... 142 Figure 15.1-9: PS HO to UTRA-FDD - End-to-End call flows ................................................................... Figure 15.1-10: LTE to UTRAN Mobility – Redirection Execution ..................................................................143 Figure 15.1-11: RAT frequency with highest cellReselectionPriority is chosen for redirection ...................143 Figure 15.1-12: RRC Connection Release with Redirection Info from EUTRAN to UTRAN ............................ 144 ......................................................................................... .................... 145 Figure 15.1-13: Inter RAT threshold for event B2 ..................................................................... ...................................................................................... ....................154 Figure 15.2-1: Reselection from eUTRAN to GERAN .................................................................. ........................................................................................... .................................. 165 Figure 15.2-2: Inter RAT threshold for event B2 ......................................................... ........................................................................................ .................... 171 Figure 15.2-3: Call Flow for Redirection to Geran .................................................................... Figure 15.2-4: Call Flow for Cell Change Order with /Without NACC . ..........................................................172 ........................................................................................... .................................. 180 Figure 15.3-1: Inter RAT threshold for event B2 ......................................................... ......................................................................................... .................... 186 Figure 15.3-2: Call Flow for Redirection to HRPD .....................................................................



V05.03 / EN

Approved-Standard

30/Mar/2012

Page 10/194


MGR /TIPS /NEA

LIST OF TABLES ................................................................................................ ....................................15 Table 6-1: Parameters impacting UL coverage ............................................................ Table 6-2: Parameters impacting DL coverage . ...............................................................................................16 ......................................................................... ...........16 Table 6-3: Parameters impacting attach/detach procedures .............................................................. ............................................................................................ .................................... 17 Table 6-4: Parameters impacting DL throughput ........................................................ ............................................................................................ .................................... 17 Table 6-5: Parameters impacting UL throughput ........................................................ ................................................................................. ......................17 Table 6-6: Parameters impacting control plane latency ........................................................... .............................................................................................. ....................................17 Table 6-7: Parameters impacting eNB Capacity .......................................................... Table 6-8: Parameters impacting measurements for intra-LTE mobility ........................................................18 Table 6-9: Parameters impacting measurements for inter-frequency (idle mode) ........................................19 Table 6-10: Parameters impacting measurements for inter-frequency (active mode) .................................. 19 Table 6-11: Parameters impacting LTE – UMTS Inter-Frequency (Idle Mode) .................................................20 Table 6-12: Parameters impacting LTE – UMTS Inter-Frequency (Active Mode) .............................................20 .............................................................................. .........21 Table 6-13: Parameters impacting LTE – GSM (Idle Mode) ..................................................................... .......................................................................... ...........21 Table 6-14: Parameters impacting LTE – GSM (Active Mode) ............................................................... ............................................................................ ......... 21 Table 6-15: Parameters impacting LTE – HRPD (Idle Mode) ................................................................... ........................................................................ ...........22 Table 6-16: Parameters impacting LTE – HRPD (Active Mode) ............................................................. ................................................................................................................................ .....................................................................23 Table 7-1: LA4.0 Features ........................................................... Table 8-1: Default setting for parameter p arameter referenceSignalPower....................................................................25 ....................................................................................................................................... .....................................................................29 Table 8-2: UL 2.6GHz .................................................................. ......................................................................... ...........29 Table 8-3: Path Loss & UL Cell Range in Dense Urban Indoor .............................................................. ................................................................................... ...................... 29 Table 8-4: Path Loss & UL Cell Range Suburban in Car ............................................................. ........................................................................................................ ......................................................... ............................................... 29 Table 8-5: DL Cell Range in Dense Urban Table 10-1: Examples of threshold tuning for a 10MHz band (academic only, not applied in any trial ......................................................................................................................................... ................................................................................ .........49 /project). .................................................................. ................................................................................................ .................................... 55 Table 10-2: Theory Assumption on CFI Tuning ............................................................ Table 11-1: uplinkSIRtargetValueForD uplinkSIRtargetValueForDynamicPUSCHscheduling ynamicPUSCHscheduling vs. PUSCHPowerControlAlphaFactor ........... 57 ....................................................................................................... .................................60 Table 11-2: 11-2: Different Set‟s Combinations ...................................................................... ............................................................................................... ....................................68 Table 11-3: 11-3: Different Set‟s Combinations Used ........................................................... ........................................................................................................... ...............................................74 Table 12-1: Attach Latency for LA4.0.1 ............................................................ ................................................................................................................................ .....................................................................75 Table 12-2: SW Reference ........................................................... ................................................................................................................... ..........................................................77 Table 12-3: Idle to Active Latency ......................................................... ................................................................................................................................ .....................................................................78 Table 12-4: SW Reference ........................................................... Table 12-5: Ping Latency for 32 Bytes with and without Extended SR grant for U-plane latency ................. 79 Table 13-1: LA4.0.1 Capacity figures . ..............................................................................................................80 ...................................................................................................................... ..........................................................87 Table 14-1: Mobility parameters ............................................................ Table 14-2: Intra-eNB HO Interruption time . .................................................................................................107 .............................................................................................................................. ...................................................................108 Table 14-3: SW Reference ........................................................... ........................................................................................... .................................. 124 Table 14-4: Parameters Tuning for Active Mode ......................................................... ........................................................................................ .................... 124 Table 14-5: Connected Mode Test cases executed.................................................................... Table 14-6: A5 through S1 with 50% DL OCNS . ...............................................................................................124 ............................................................................................. ..................................124 Table 14-7: A5 through X2 with 100% DL OC NS ........................................................... ............................................................................................... .................................. 124 Table 14-8: A5 through X2 with 50% DL OCNS ............................................................. ............................................................................................... .................................. 124 Table 14-9: A3 through X2 with 50% DL OCNS ............................................................. ........................................................................................... ..................................125 Table 14-10: A3 through X2 with 100% DL OC NS ......................................................... 125 Table 14-11: A5 through X2 with 100% DL OC NS (thresholdEutraRSRP & threshold2EutraRSRP threshold2EutraRSRP =-111) ....... 125 125 Table 14-12: A5 through X2 with 50% DL OC NS (thresholdEutraRSRP & threshold2EutraRSRP threshold2EutraRSRP =-111) ......... 125 ............................................................................................. .................................. 126 Table 14-13: Parameters Tuning for Idle Mode ........................................................... ................................................................................................. ..................................126 Table 14-14: Idle Mode Test cases executed ............................................................... ................................................................................... .................... 126 Table 14-15: Idle Mode Test B4 B13 with 50% OCNS ............................................................... ................................................................................... .................... 126 Table 14-16: Idle Mode Test B13 B4 with 50% OCNS ............................................................... ................................................................................. .................... 127 Table 14-17: Idle Mode Test B4 B13 with 100% OCNS ............................................................. ................................................................................. .................... 127 Table 14-18: Idle Mode Test B13 B4 with 100% OCNS .............................................................



V05.03 / EN

Approved-Standard

30/Mar/2012

Page 11/194


MGR /TIPS /NEA

3 REFERENCE DOCUMENTS Ref. Document Number

Title

[1] [2]

LPUG LA4.0


LA3.0.2 Optimization Handbook

4 RELEASE RELATED DOCUMENTS Ref. Document Number

Title

[1] [2] [3] [4] [5] [6] [7]

LA4.0.1 Service Performance Handbook LA4.0.1 Migration - QoS and Stability Monitoring Handbook LA4.0.1 Engineering Toll Recommendation and Strategy LA4.0.1 LTE Tests Plan - TIS Engineering Contribution LA4.0.1 LTE Optimisation Troubleshooting Handbook LA4.0.1 LIMO Executive Report User Guide LA4.0.1 QoS & Stability Monitoring Handbook

LTE/IRC/APP/032318 LTE/IRC/APP/031966 LTE/IRC/APP/031688 LTE/IRC/DJD/033695 LTE/IRC/APP/032278 LTE/IRC/APP/034221 LTE/IRC/APP/031953


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 12/194


MGR /TIPS /NEA

5 PROCESS AND METHODOLOGY 5.1 TOOLS AND RESOURCES Tools used for the Network Optimization are described in the “Alcatel-Lucent LTE/E-UTRAN Technology Trial Test Tools” document.

5.2 OPTIMIZATION TOOLS A set of tools are needed to carry out the optimization objectives: Simulation Tool for RF design: Alcatel-Lucent uses A9955. Used for antenna change validation and RF analysis. There must be consistency with the methods used by the customer so it is possible to use their solution if it has been validated by Alcatel-Lucent teams. Data Acquisition Platform (DAP): currently Nixt Platform composed of JSDU Nixt E6474A, W1314A receiver and 1 to 4 test mobiles. Tests Mobiles: typically LGE, Motorola, Samsung and Bandrich. Also IPW or Sequans UEs for TDD systems. Post processing platform (PPP): Gladiator or eDAT (ALU internal), which allow automatic and customized KPI generation, built-in failure characterization, as well as UE and Call Trace synchronization capabilities (for a deeper and accurate analysis). For enhanced troubleshooting, the usage of a protocol analyzer (Agilent DNA) may be required, in particular to monitor the S1 and X2 interfaces. Project Database: For a correct follow-up of all the optimization activities it is mandatory to have a common and unique project information system (Project Database) which contains the following information: Site configuration (geographical coordinates, antenna height/azimuth/tilt) Site issues Updated operations plan Implemented/Planned Changes Metrics: performance KPI, outage times, workload, delays, escalated issues etc. Work Orders and implementation delays Reporting templates Equipment tracking List of raised ARs


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 13/194


MGR /TIPS /NEA

6 OPTIMIZATION PARAMETERS OVERVIEW This chapter is intended to present various parameters existing in ALU RAN, grouped per main area of interest in trials and network deployments. Grouping was made s uch that it reflects various types of tests that are being performed during trials and KPIs tests that might as well be addressed during trials and network deployment. Parameters have been split by following domains: Coverage Attach /Detach Throughput Latency Capacity Mobility Due to the wide scope of mobility, the parameters impacting mobility have been further divided in: LTE – LTE mobility LTE – UMTS mobility LTE - GSM mobility LTE – HRPD mobility Inside each group, parameters are ordered by the most important and relevant for optimization activities. They should be optimized in case of strong constraints for performance (very demanding KPI, strong competition). To each parameter is associated a recommended value that can be obtained from [1] for parameters that have not been yet optimized in field activities. The parameters for which a different, optimized, value have been obtained in various field tests, have recommended values specified in the corresponding paragraphs along with some precisions about the conditions in which the optimized value have been obtained (cluster, load).


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 14/194


MGR /TIPS /NEA

6.1 PARAMETERS IMPACTING COVERAGE The parameters of LA4.0.0 release having an impact on coverage are presented in the table below. Most often the coverage is determined by UL link thus for optimizing coverage it is needed to optimize levels of UL power. Below one can find the parameters commented and reviewed for DL & UL Coverage. Object

Name

Recommended Value

ULPowerControlConf

pUSCHPowerControlAlphaFactor

0.8

ULPowerControlConf

p0NominalPUSCH

Check Recommendation

EnbRadioConf

uplinkSIRtargetValueForDynamicPUSCHsche duling


EnbRadioConf

sEcorrInit

EnbRadioConf

sEcorrstepforlowerbler


EnbRadioConf

secorrstepforhigherbler


EnbRadioConf

ulSyncSINRsyncToOOSTreshold


EnbRadioConf

ulSyncSINROOStoSyncTreshold


CellSelectionReselectionConf

qRxLevMin


ULPowerControlConf

deltaFPUCCHFormat1

deltaF0

ULPowerControlConf

sIRTargetforReferencePUCCHFormat



Table 6-1: Parameters impacting UL coverage

Object

Name

Recommended Value


qRxLevMin


PowerOffsetConfiguration

referenceSignalPower



primarySyncSignalPowerOffset



secondarySyncSignalPowerOffset



pBCHPowerOffset



pDCCHPowerOffsetSymbol



pCFICHPowerOffset



pHICHPowerOffset



pbOffsetPdsch



LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 15/194


MGR /TIPS /NEA


paOffsetPdsch


LteCell

cellDLTotalPower



phichResource

1

Table 6-2: Parameters impacting DL coverage

6.2 PARAMETERS IMPACTING ACCESS Network performance can be evaluated by some measures implying attach and detach procedures (e.g. attach time, detach time, attach success rate). The parameters impacting attach, detach procedures are listed in the table below. Object

Name

Recommended Value

CellRachConf

preambleInitialReceivedTargetPower

dBm-104

CellRachConf

preambleTransmitPowerStepSize

dB6

ULPowerControlConf

deltaPreambleMsg3

0

CellRachConf

tPCRACHMsg3

4dB

Table 6-3: Parameters impacting attach/detach procedures

6.3 PARAMETERS IMPACTING THROUGHPUT The parameters that can impact the throughput, both on UL and on DL, are listed in the table below. On DL the throughput is most influenced by the type of antenna system that is being used/selected wile on UL by the required quality of the received signal, which forces higher powers of PUSCH channel. Object

Name

Recommended Value

enbRadioConf

dlMCSTransitionTable

Check table

DownlinkMimo

dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv

-10

DownlinkMimo

dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer

12

CellL2DLConf

dlSinrThresholdBetweenOLMimoAndTxDiv

15

CellL1L2ControlChannelsConf

AlphaFairnessfactor

1


DynamicCFIEnabled

True


CFI

Check recommendation


cfi1allowed

Check recommendation


cfi2allowed

True


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 16/194


MGR /TIPS /NEA

cfi3allowed


True

Table 6-4: Parameters impacting DL throughput Object

Recommended Value

Name

uplinkSIRtargetValueForDynamicPUSCHscheduling

enbRadioConf

Check table

ULPowerControlConf


0.8

DownlinkMimo

ulSchedPropFairAlphaFactor

0.5

Table 6-5: Parameters impacting UL throughput

6.4 PARAMETERS IMPACTING LATENCY Latency is generally considered either as control plane latency or as user plane latency. Control plane latency involves the network attachment operation while user plane latency only considers the latency of packets while UE is in connected state. Parameters impacting control plane latency (attachment operation) and user plane latency are given in the tables below. Most of parameters impacting attachment operations are higher limits of various processes taking place during attachment procedure. The impact of such limits on the value of control plane latency is not significant. Object

Name

Recommended Value

CellRachConf

preambleInitialReceivedTargetPower

dBm-104

CellRachConf

preambleTransMax

n3

CellRachConf

preambleTransmitPowerStepSize

dB6

EnbRadioConf

aUGtriggerDelayforRACHmsg4

10

Table 6-6: Parameters impacting control plane latency

6.5 PARAMETERS IMPACTING CAPACITY The parameters impacting capacity are listed in the table below. Object

Name

Recommended Value

CellRachConf

alphaFairnessFactor

1

CellRachConf

ulSchedPropFairAlphaFactor

0.5

Table 6-7: Parameters impacting eNB Capacity

6.6 PARAMETERS IMPACTING MOBILITY Mobility in LTE includes mobility during idle states and during active states. Mobility can involve several technologies and several frequencies. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 17/194


MGR /TIPS /NEA

Note: Measurement Gap feature parameters can impact the mobility parameters considered through the quality of measurement performed.

6.6.1 LTE – LTE MOBILITY Because measurements are somehow a common part of various types of mobility, in the table below are listed the parameters impacting measurement process for intra-LTE mobility. Object

Name

Recommended Value


qRxLevMin

-120


sIntraSearch

62


qRxlevminoffset

8


qHyst

dB2

CellReselectionConfLte

tReselectionEUTRAN

2

LteNeighboringCellRelation

qoffsetCell

dB0

RrcMeasurementConf

filterCoefficientRSRP

Fc8

LteSpeedDependentConf

tReselectionEutraSfMedium

oDot25


tReselectionEutraSfHigh

oDot25

SpeedStateEvalConf

tEvaluation

S30

SpeedStateEvalConf

nCellChangeHigh

12

SpeedStateEvalConf

nCellChangeMedium

4

SpeedStateEvalConf

qHystSfHigh

dB-6

SpeedStateEvalConf

qHystSfMedium

dB-6

ReportConfigEUTRA

Hysteresis

2

ReportConfigEUTRA

timeToTrigger

ms40


cellIndividualOffset

dB0

ReportConfigEUTRA

eventA3Offset

0

LteNeighboringFreqConf

offSetFreq

dB0

ReportConfigEUTRA

reportInterval

ms240

ReportConfigEUTRA

maxReportCells


ReportConfigEUTRA

reportAmount

r8

Table 6-8: Parameters impacting measurements for intra-LTE mobility

Object

Name

Recommended Value


qRxLevMin

-120


sNonIntraSearch

16


threshServingLow

10


threshXLow

0


qHyst

dB2


tReselectionEUTRAN

2


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 18/194


MGR /TIPS /NEA


tReselectionEutraSfMedium

oDot25


tReselectionEutraSfHigh

oDot25

SpeedStateEvalConf

nCellChangeHigh

12

SpeedStateEvalConf

nCellChangeMedium

4

SpeedStateEvalConf

qHystSfHigh

dB-6

SpeedStateEvalConf

qHystSfMedium

dB-6

Table 6-9: Parameters impacting measurements for inter-frequency (idle mode)

Object

Name

Recommended Value

ReportConfigEUTRA

thresholdEutraRsrp

-120

ReportConfigEUTRA

Threshold2EutraRsrp

-100

ReportConfigEUTRA

Hysteresis

2

ReportConfigEUTRA

timeToTrigger

ms40

RrcMeasurementConf


Fc8

LteNeighboringFreqConf

offSetFreq

dB0

ReportConfigEUTRA

reportInterval

ms240

ReportConfigEUTRA

maxReportCells


ReportConfigEUTRA

reportAmount

r8

Table 6-10: Parameters impacting measurements for inter-frequency (active mo de)

6.6.2 LTE – UMTS MOBILITY Coexistence of various technologies requires the possibility of performing mobility between various types of RAN. Indeed, such mobility requires multi-standard UEs. Parameters impacting LTE – UMTS mobility are presented in the table below. Object

Name

Recommended Value

CellReselectionConfUtraFdd

qRxLevMin

-115


sNonIntraSearch

16


threshServingLow

16

CellReselectionConfUtraFdd

threshXLow

0

UtraNeighboring

tReselectionUtra

2

UtraSpeedDependentConf

tReselectionUtraSfMedium

oDot25

UtraSpeedDependentConf

tReselectionUtraSfHigh

oDot25

SpeedStateEvalConf

nCellChangeHigh

12

SpeedStateEvalConf

nCellChangeMedium

4


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 19/194


MGR /TIPS /NEA

SpeedStateEvalConf

qHystSfHigh

dB-6

SpeedStateEvalConf

qHystSfMedium

dB-6

Table 6-11: Parameters impacting LTE – UMTS Inter-Frequency (Idle Mode) Object

Name

Recommended Value

ReportConfigUTRA

thresholdEutraRsrpB2

-100

qReportConfigUTRA

thresholdUtraRscp

-114

RrcMeasurementConf

filterCoefficientOfQuantityConfigUtra

fc4

ReportConfigUTRA

hysteresis

4

ReportConfigUTRA

timeToTrigger

ms100

ReportConfigUTRA

reportInterval

ms240

ReportConfigUTRA

maxReportCells

1

ReportConfigUTRA

reportAmount

r8

MeasObjectUTRA

offsetFreqUTRA

0

Table 6-12: Parameters impacting LTE – UMTS Inter-Frequency (Active Mode)

6.6.3 LTE – GSM MOBILITY Parameters impacting LTE – GSM mobility are presented in the table below. Object

Name

Recommended Value

CellReselectionConfGERAN

qRxLevMin

-101


sNonIntraSearch

16


threshServingLow

16

CellReselectionConfGERAN

threshXLow

0

GeranNeighboring

tReselectionGERAN

2

GeranSpeedDependentConf

tReselectionGERANSfMedium

oDot25


tReselectionGERANSfHigh

oDot25

SpeedStateEvalConf

nCellChangeHigh

12

SpeedStateEvalConf

nCellChangeMedium

4

SpeedStateEvalConf

qHystSfHigh

dB-6

SpeedStateEvalConf

qHystSfMedium

dB-6


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 20/194


MGR /TIPS /NEA

Table 6-13: Parameters impacting LTE – GSM (Idle Mode)

Object

Name

Recommended Value

ReportConfigGERAN


-100

ReportConfigGERAN

thresholdGeran

-110

RrcMeasurementConf

filterCoefficientOfQuantityConfigGERAN

fc2

ReportConfigGERAN

hysteresis

3

ReportConfigGERAN

timeToTrigger

ms100

ReportConfigGERAN

reportInterval

ms240

ReportConfigGERAN

maxReportCells

1

ReportConfigGERAN

reportAmount

r8

MeasObjectGERAN

offsetFreqGERAN

0

Table 6-14: Parameters impacting LTE – GSM (Active Mode)

6.6.4 LTE – HRPD MOBILITY Mobility implying CDMA ecosystem can be realized in idle mode as cell reselection and in connected mode as cell redirection. Both features are used when LTE coverage ends and there is a larger CDMA coverage. Parameters impacting LTE – CDMA mobility are presented in the table below. Object

Name

Recommended Value


sNonIntraSearch

16

CellReselectionConfHrpd

threshXLow

-2

HrpdNeighboring

tReselectionCDMAHRPD

2

HrpdSpeedDependentConf

tReselectionHRPDSfMedium

oDot25


tReselectionHRPDSfHigh

oDot25

SpeedStateEvalConf

nCellChangeHigh

12

SpeedStateEvalConf

nCellChangeMedium

4

SpeedStateEvalConf

qHystSfHigh

dB-6

SpeedStateEvalConf

qHystSfMedium

dB-6

Table 6-15: Parameters impacting LTE – HRPD (Idle Mode)

Object

Name

Recommended Value


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 21/194


MGR /TIPS /NEA

ReportConfigCDMA2000


-113


thresholdCDMA2000

-9

MeasObjectCDMA2000

OffSetFreq

1


hysteresis

3


timeToTrigger

ms100


reportInterval

ms240


maxReportCells

2


reportAmount

r8

Table 6-16: Parameters impacting LTE – HRPD (Active Mode)

7 NEW FEATURES IN LA4.0 In the table below is presented all the new features belonging to LA4.0 and it is identified all the domains impacted by each feature. For more information regarding the features the following link should be checked: LA4.x FTS Documents for Review Feature name

Optimization

Capacity

Throughput

Coverage

Latency

Mobility

Attach

MOS

LA4.0 KPI Targets

KPI

x

x

x

x

x

x

x

LA4.0 eNB SW Capacity Targets Commercial Mobile Alert System (CMAS) support Support Fiber delay (or any delay between modem and RF head) in LTE Single antenna transmit scheme VoLTE Solution for Field Trial Applications VoLTE Friendly User Trial solution RoHC v1 Support for VoIP ECID and LPP protocol support (trial) eNB Synchronization support for OTDOA (Trial) eNB IMS VoIP emergency call support (trial) eNB support of OTDOA Hearability Enhancement (Trial ) CSFB enhancement to UTRAN/GERAN-- enhanced Redirection and PSHO ANR Support for Inter RAT Neighbours (UTRAN) LTE RRH Antenna Cross Connect Capability Support in LA4.0.1 Transport UL Traffic Shaping Congestion Management at Call Admission Service, and load based handover behaviour support

KPI

x

x

x

x

E2E KPI Optim

x

x

x

x

x

E2E E2E E2E E2E E2E E2E E2E

KPI

x

x

Optim

x

KPI E2E/Optim

x

E2E KPI

x

x


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 22/194


MGR /TIPS /NEA

(eMCTA -Phase 2) LTE and 1xRTT cell reselection CS Fallback to 1XRTT for Voice Calls-- Dual transceiver/receiver UE Standard based solution Transport eUTRAN Sharing eUTRAN Sharing basics: MOCN with shared LTE spectrum eUTRAN Sharing - Mobility Tuneable Antenna Path Delay between RF head and DAS LTE Support for 5MHz 4Rx Receive Diversity Inter LTE Service Provider Roaming (using Home PGW) CSFB to UTRAN/GERAN enhancements with enhanced Redirection GSMA VoLTE IMS Profile Compliance Phase1 LTE Local Breakout with S9 Online Charging between ALU PGW and 8610 ICC over Ro/Gy LTE Offline Charging Support with ALU PGW/SGW and IeCCF on Ga Interface Public Safety E2E Solution Testing for LE4.0 Basic EUTRAN Sharing with MOCN Priority Access With PreEmption (for all bearers)

Optim

x

E2E/Optim

x

x

E2E KPI KPI KPI KPI

x

x

x

E2E E2E E2E E2E E2E E2E E2E E2E E2E

Table 7-1: LA4.0 Features


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 23/194


MGR /TIPS /NEA

8 COVERAGE OPTIMIZATION HINTS In this chapter it will be highlighted the main focus of testing and the primary steps that will allow to optimize a specific domain and the most important /priority parameters; in this case the domain addressed is coverage in LTE. In this chapter it will be beaked in two sub-domains; Downlink Coverage and Uplink Coverage. Normally some questions arise, such as: When to perform coverage optimization? Which parameters can help extending /reducing the coverage? Mainly the Coverage optimization can occur when the Link Budget is below expectations (Theoretical calculation). Before starting playing with the parameterization; usually is part of best practice rules for in Near Cell /Mid Cell & Cell Edge test to follow up simple steps as: Check the CQI Evaluate RSSI vs. SNR relation Evaluate RSRP vs. RSRQ Throughput Values for specific location If we could guarantee that these values are “normal”, the chances to have performance issues are much less difficult to occur. If regardless of the correct values, still facing some performance issues, the below parameters can be used in order to correct the situation. When changing parameters; you can adopt a more error-free approach, meaning that a parameter is changed at each time. If three or four parameters are changed s ame time… it could be difficult to understand which one is bringing the improvement in performance. As note; please remember that this can be a static test in each position, or can be a moving test… the same principles can be applied in both situations.

8.1 PARAMETERS COVERAGE

OPTIMIZATION

FOR

IMPROVING

DOWNLINK

8.1.1 REFERENCESIGNALPOWER The Reference Signal Power is a key RF parameter that impacts coverage. Parameter referenceSignalPower configures the DL RS absolute power applied per Resource Element (REG) and per transmit antenna. This level is used as a power level reference (the power levels for all the other DL signals and channels are set relative to it). ATTENTION! When modifying this parameter, all other signal power setting will be automatically adjusted in accordance to a power offset relative to the referenceSignalPower. This parameter is expressed in dBm. It is converted into linear scale (miliwatts) according to the following formula: P [mW] = 10 0.1×referenceSignalPower Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 24/194


MGR /TIPS /NEA

Expected behaviour when changing this parameter: The higher the setting, the larger the cell coverage on the downlink, but leaves smaller power headroom available for other downlink signals and channels. The lower the value, the smaller the cell coverage on the downlink axis, but larger power headroom is available for other downlink signals and channels. Note: The following table translates the expected behaviour in terms of cellDLTotalPower when changing the reference Signal Power; some difference may occur if other sets of parameters are used also.

Recommended Value = Check Table 8-1

transmissionMode

cellDLTotalPower

dlBandwidth n15-3MHz n25-5MHz n50-10MHz n100-20MHz n15-3MHz n25-5MHz n50-10MHz n100-20MHz n15-3MHz n25-5MHz n50-10MHz n100-20MHz n15-3MHz n25-5MHz n50-10MHz n100-20MHz n15-3MHz n25-5MHz n50-10MHz n100-20MHz n15-3MHz n25-5MHz n50-10MHz n100-20MHz n15-3MHz n25-5MHz n50-10MHz n100-20MHz n15-3MHz n25-5MHz n50-10MHz n100-20MHz

43,0

44,7 tm1

46,0

47,7

43,0

44,7 tm2, tm3, tm4

46,0

47,7

referenceSignalPower 22 20 17 14 24 22 19 16 22 23 20 17 27 25 22 19 23 21 18 15 24 22 19 16 26 24 21 18 28 25 22 19

Table 8-1: Default setting for parameter referenceSignalPower

8.1.2 PHICHRESOURCE PHICH channels are grouped in PHICH groups. Each PHICH group consists of 8 PHICH channels (hence conveys 8 ACK/NACKs) that use the same resources, PHICH channels of a same group being separated by orthogonal sequences. In FDD, the number of PHICH groups in a subframe is: N Group PHICH = [N g (N DL RB /8]

Where: Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 25/194


MGR /TIPS /NEA

N g ∈ {1/6, 1/2, 1, 2} and is configured by parameter phichResource N DLRB is the total number of RBs in the downlink and is configured by parameter dlBandwidth

A PHICH group consists of 3 REGs over either 1 or 3 OFDM symbols, depending on the value of parameter phich-Duration (“normal” or “extended”). This parameter can only be set to “extended” if the CFI is equal to 3. Recommended Value & Only Supported Value= "1" Expected behaviour when changing this parameter: Setting the value low will result in lower number of PHICH groups in a subframe, so the higher the number of ACK/NACKs that need to be sent out the longer the buffer, eventually leading to failing to transmit the messages. Setting value high will impact in having a higher number of PHICH groups in a subframe, so the fewer ACK/NACKs needed to be transmitted, OFDM symbols are not used and the allocated resources for this process go to waste.

8.2 PARAMETERS OPTIMIZATION FOR IMPROVING UPLINK COVERAGE 8.2.1 SIRTARGETFORREFERENCEPUCCHFORMAT The PUCCH power control procedure is used to guarantee the required error rate. For this purpose, it aims at achieving a target SIR the value of which guarantees the required error rate. The SIR target is set to sIRTargetforReferencePUCCHFormat for PUCCH Format 1A and to sIRTargetforReferencePUCCHFormat + deltaFPUCCHFormat1b for PUCCH format 1B. Note that the PUCCH power control procedure assumes shortened PUCCH Format to account for the SRS configuration. This parameter is a key RF optimization parameter. Higher settings of this parameter will improve PUCCH reception, but will also drive higher UE TX power leading to interference to neighbouring cells, and vice-versa. Recommended Value= "-3.0" Note:Recent results coming from VzW FSA, are p ointing for a different val ue… main justification is that in order to support dynamic change of the number of receiving antennas (and 4x receive), in LA4 to have the same effect /influence they need to be adjusted. VzW FSA LA4 Value= "0.0"

8.2.2 SECORRINIT, SECORRSTEPFORLOWERBLER SECORRSTEPFORHIGHERBLER

&

The eNB starts Spectrum Efficiency Correction when the call setup is completed using these two parameters and sEcorrMin, sEcorrMax. sEcorrInit is the initial correction factor value applied at call setup.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 26/194


MGR /TIPS /NEA

This parameter controls the initial value (in dB) of correction metric SEcorr managed by the link adaptation function to maintain the PUSCH initial HARQ BLER around its target value. The lower the sEcorrInit value, the more conservative is the PUSCH link adaptation starting point and, consequently, the lower the PUSCH MCS. In other words, the lower the sEcorrInit values, the lower is the initial PUSCH MCS value, and the lower are the risks of observing high BLER value at call setup or on the target cell just after handover. Note however that the lower the sEcorrInit value, the longer the link adaptation will take to converge to its setpoint. This may impact the maximum achievable throughput for a brief period (exact time depends on traffic activity) after call setup or handover. Recommended & Default Value= "-7" for sEcorrInit Note:Recent results coming from VzW FSA, are pointing for a different value… main justification is that in order to support dynamic change of the number of receiving antennas (and 4x receive), in LA4 to have the same effect /influence they need to be adjusted. VzW FSA LA4 Value= "-10"

sEcorrStepForLowerBLER and sEcorrStepForHigherBLER parameters are key RF optimization parameters. Higher step sizes will allow the eNodeB to make quicker compensation to any sources of SINR-to-MCS conversion error, but could lead to wider swings in data rates and HARQ performance. Lower settings will slow down the spectrum efficiency correction process, impacting HARQ performance.

The tuning of the table of SE_corr values (i.e. sEcorrStepForLowerBLER and sEcorrStepForLowerBLER) is performed so that if N = floor ( x ), then the ratio of the SE_corr values around the target HARQ Tx rate satisfies the following condition:

The other values in the SE_corr tables are set in order to allow fast convergence around that set point.

Recommended & Default Value = “[-0.12500000, 0.03125000, -0.04687500, 0.12500000, -0.25000000, -0.50000000, -0.50000000, -0.50000000, -0.50000000 ]” for SECORRSTEPFORLOWERBLER & Recommended & Default Value = "[-0.12500000, 0.03125000, -0.04687500, 0.12500000, -0.25000000, -0.50000000, -0.50000000, -0.50000000, -0.20000000 ]" for SECORRSTEPFORHIGHERBLER

8.2.3 ULSYNCSINRSYNCTOOOSTRESHOLD & ULSYNCSINROOSTOSYNCTRESHOLD


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 27/194


MGR /TIPS /NEA

The uplink synchronization detection mechanism is based on the SIR metric derived from the Sounding Reference Signal observations. Upon processing of an SRS measurement report from L1 related to user k, the UL scheduler evaluates the UL synchronization status of that user by comparing the SRS synchronization metric computed to threshold levels as follows: The threshold for the transition from “In sync state” to “out of sync state” is configured by parameter ulSyncSINRsyncToOOSTreshold, i.e. If the UE is assumed in “In Sync state “and the following condition is met: SINRsync(userk) ulSyncSINROOStoSyncThreshold Then the user is considered in “In Sync state” by the MAC scheduler. Note that the tuning must satisfy the following condition: ulSyncSINRsyncToOOSTreshold < ulSyncSINROOStoSyncTreshold Concerning the deltaFPUCCHFormat1; the setting of the UE Transmit Power P PUCCH for PUCCH in

{

}

subframe i is defined by P PUCCH (i) = min P max, P0 _ PUCCH + PL + ΔF _ PUCCH + g(i) [dBm] Where ΔF _ PUCCH denotes the (PUCCH) format specific power offset; the format dependent power offset ΔTF_PUCCH (TF) is defined on a per cell basis and configured by parameter deltaFPUCCHFormat1 for format 1.

Recommended Values = “-17” for ulSyncSINRsyncToOOSThreshold & “ -16” for ulSyncSINROOStoSyncThreshold

Note: Recent results coming from VzW FSA, are pointing for a different value… main justification is that in order to support dynamic change of the number of receiving antennas (and 4x receive), in LA4 to have the same effect /influence they need to be adjusted.

VzW FSA LA4 Value= “-14” for ulSyncSINRsyncToOOSThreshold & “-13” for ulSyncSINROOStoSyncThreshold

8.2.4 DELTAFPUCCHFORMAT1 This parameter is used for setting the transmit power of SR over PUCCH by the UE. LA3.0 eNodeB relies on Scheduling Request on PUCCH from UE for scheduling uplink grants. If the SR is not received by the eNodeB, it will trigger the UE to declare SRmax failure, which in turn will trigger eNodeB‟s OOS condition. Under certain conditions the SR power may not be sufficient to ensure detection. By boosting the SR transmit power, it increases the SR detection likelihood at the eNodeB. Concerning the deltaFPUCCHFormat1; the setting of the UE Transmit Power P PUCCH for PUCCH in

{

}

subframe i is defined by P PUCCH (i) = min P max, P0 _ PUCCH + PL + ΔF _ PUCCH + g(i) [dBm] Where ΔF _ PUCCH denotes the (PUCCH) format specific power offset; the format dependent power offset ΔTF_PUCCH (TF) is defined on a per cell basis and configured by parameter deltaFPUCCHFormat1 for format 1. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 28/194


MGR /TIPS /NEA

Recommended Value = deltaFPUCCHFormat1 = “deltaF0

”

8.2.5 CELL COVERAGE Examples on following settings: Central Frequency: 2.6 GHz RF channel models: Dense urban, suburban in-car

8.2.5.1

UL CELL COVERAGE

The Uplink cell coverage is defined as a target service that UE must satisfy at cell edge conditions. The worst case is 14.5 kbps which was selected for this case. The cell coverage is independent of channel bandwidth and is strictly dependent of UE TX power which is 23dBm maximum for the UE‟s supplied by third parties and tested by ALU. UL 2.6GHz

PS14.5

Target Service at cell edge

Table 8-2: UL 2.6GHz Dense Urban Indoor Path Loss (dB) 134.4 Cell Range (Km) 0.6 Table 8-3: Path Loss & UL Cell Range in Dense Urban Indoor Suburban In-Car Path loss 144.3 2.95 cell range Table 8-4: Path Loss & UL Cell Range Suburban in Car

As expected, for the two environmental models the dense urban cell coverage is much lower but it gives a rough understanding for the UL coverage and where to aim as a low and high value expected in field tests.

8.2.5.2

DL CELL OUTDOOR COVERAGE

In Downlink the eNB‟s ReferenceSignalPpower is influencing the cell range. Two cases were selected for ReferenceSignalPower. The coverage computation is independent of channel bandwidth. Environment Dense Urban

ReferenceSignalPower (dBm) 14 18 Table 8-5: DL Cell Range in Dense Urban

Cell Range (Km) 1.9 2.56

Almost every time the DL cell coverage will be higher than UL cell coverage. Not always selecting a high ReferenceSignalPower will mean better coverage: Hearing the Sync signals and MIB isn‟t enough to obtain an RRC connected state.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 29/194


8.2.5.3

MGR /TIPS /NEA

TOTAL CELL COVERAGE

The so called total cell coverage is expressed as a minimum between UL and DL. The thorough cell range is expressed by the following formula: Total cell coverage [m] = Min (UL cell range, DL cell range) The total cell range will almost every time be the UL one. In a dense site area where the cells are close to one another, and effects of shadowing, multipath propagation are very accentuated, cell coverage is limited and a high UE Tx Power will create interference in neighbouring cells when UE is inside it‟s serving cell edge. The phenomenon is very common and needs to be analyzed carefully from the network planning stages. The Fractional Power control algorithm is a good way to improve conditions at cell edge by lowering the SIR target level so the interference in neighbouring cell is kept at a minimum.

8.2.5.4

PUSCH FRACTIONAL POWER CONTROL

Fractional Power control is used in order to limit the interference that cell edge-users create to the neighbouring cells. In fractional power control, the transmit power adjustment pUSCHPowerControlAlphaFactor × PL compensates for only a fraction of the estimated path loss PL. The result is that the SINR achieved by the UE at the eNB varies linearly with the path loss. Higher levels of path loss are associated with lower SINR and vice versa. When the UE is close to the cell centre, the path loss decreases and hence the target SINR is increased. When the UE is at the cell edge, the path loss increases and hence the target SINR is decreased.

Figure 8.2-1: Throughput for single UE vs. Path loss (Lab environment) In high path loss conditions, the throughput with a lower SIR target becomes better because eNB will grant a lower MCS but with more PRBs than for high SIR Target. For the Fractional power control tests, was used the following values /configuration expressed in the two examples given below. In the first example given the SIR target = 0 between Path loss 110 to 140dB. In the 2nd below the SIR target = 0 between Path loss 135 to 140dB. For pUSCHPowerControlAlphaFactor = 0.7 maxSIRtargetForFractionalPowerCtrl = 15.0dB minSIRtargetForFractionalPowerCtrl = 0.0dB uplinkSIRtargetValueForDynamicPUSCHscheduling = 15.0dB pathLossNominal = 60dB p0NominalPUSCH = -79 dBm Path loss where SIRtarget reaches 0dB: 110dB Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 30/194


MGR /TIPS /NEA

For pUSCHPowerControlAlphaFactor = 0.8 maxSIRtargetForFractionalPowerCtrl = 15.0dB minSIRtargetForFractionalPowerCtrl = 0.0dB uplinkSIRtargetValueForDynamicPUSCHscheduling = 11.0dB pathLossNominal = 80dB p0NominalPUSCH = -84 dBm Path loss where SIRtarget reaches 0dB: 135dB

8.2.6 PUSCHPOWERCONTROLALPHAFACTOR Part of PUSCH power control and is intended to allow partial compensation of the path loss or otherwise stated it allows controlling, by decreasing, the PUSCH f or users in cell edge conditions. If set to 1; an increase in path loss will determine the same increase in PUSCH. If this parameter is not set to 1, the increase in PUSCH power can be lower than the increase in path loss. It is thus a means of controlling the UL interference created in the neighbour cell by the UEs found near the cell edge. Because the value of this parameter represents a trade-off between minimizing interference and maximizing throughput, its value must be set according to the client‟s desir ed network behaviour. If Fractional Power Control is used, the recommended value of this parameter is 0.8. If Fractional Power Control is not to be used, the parameter must have the value 1. Take care that this recommendation is only for commercial usage.

Recommended Value = "0.8" if fractional power control is used! Increasing the value of this parameter would: Increase PUSCH power for a given path loss. Increase the throughput for the all users. Increase the interference toward the neighbouring cells which might lower the throughput of users being in cell edge propagation conditions in neighbour cells. Decreasing the value of this parameter would: Decrease PUSCH power for a given path loss. Decrease the throughput for the all users. Decrease the interference toward the neighbouring cells which might increase the throughput of users being in cell edge propagation conditions in neighbour cells. KPI Impact: Coverage – higher values improve coverage Throughput – higher values will improve throughput, while lower values will decrease it. Capacity - higher values might reduce capacity, while lower values might increase it . The optimization process of this parameter should include the customer definition of the optimum trade-off between cell throughput and interference towards the neighbour cells. The choice can be different if cell wise optimization is to be performed or if a network wide setting is being aimed. Step 1: Set the pUSCHPowerControlAlphaFactor to 1 and connect the UE in Near-Cell radio conditions. For a closer view to the lab results IoT should be considered. Step 2: Start a UL UDP transfer and start driving from Near-Cell towards Edge-Cell. For a more consistent data we recommend a drive back as well logged in another trace. Step 3: Using the same cell and same route choose another value for pUSCHPowerControlAlphaFactor = {0.9, 0.8, 0.7, and 0.6} and repeat Step 1 and Step 2. Step 4: Post process the logged data and provide results in terms of UE TxPower, UL Throughput and PUSCH BLER. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 31/194


MGR /TIPS /NEA

8.2.7 QRXLEVMIN Clarifications regarding qRxLevMin: A parameter with this name appear in several objects and is then transmitted to UE inside several system information block types i.e.SIBs: CellSelectionReselectionConf – transmitted in SIB1 and SIB3 CellReselectionConfUtraFdd – transmitted in SIB6 CellReselectionConfUtraTdd – transmitted in SIB6 CellReselectionConfGERAN – transmitted in SIB7 The one that is object of this paragraph is transmitted in SIB1 which contains information relevant when evaluating if a UE is allowed to access a cell and defines the scheduling of other system information. This parameter impacts the cell size in terms of re-selection area i.e. mobility in idle mode. It configures the serving cell min required RSRP level used by the UE in cell reselection. The value sent over the RRC interface is half the value configured. Changing the value of this parameter will have an effect on the cell the UE is camped on during its idle mode. One way of optimizing it is to find the value that best superposes the cell size in idle with the cell size in active mode such that an idle-to-active transition would not result in an immediate handover decision. The exact selection criterion, S relev , is based on several values related to measured signal and power compensation level as below:

Srxlev = Q relevmeas - (Q rxlev min + Q rxlev min offser ) - P compensation

The selection is decided if S rxlev P compensati on

0 and

0

Qrxlev min offser is only considered when a periodic search for a higher priority

PLMN is being performed. Thus, for a normal sele ction, the selection criterion is fulfilled if: Qrelevmeas - Qrxlev min > 0 or Q relevmeas > Qrxlev min

As long as the above relation is being satisfied the measured cell is selected. Increasing this value will lead the mobile to start cell-selection/re-selection procedure sooner because the inequality will be satisfied for a narrower range of measured values and then will artificially decrease cell size in idle mode. Indeed, for avoiding too many measurements to be performed for too long a time, there is a decision for starting inter-cell measurements based only on the received field level. The variation of the cell size when various RSRP targets are set is given in the figure below. The information in this picture is only informative since the cell size variation strongly depends on the clutter.

Recommended & Default Value = “-120” for 10MHz BW or “-124” in case of 5MHz BW Increasing the value of this parameter would: Will lead the mobile to start cell-selection/re-selection procedure sooner because the inequality will be satisfied for a narrower range of measured values and then will artificially decrease cell size in idle mode. Indeed, for avoiding too many measurements to be performed for too long a time, there is a decision for starting inter-cell measurements based only on the received field level. Decreasing the value of this parameter would: Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 32/194


MGR /TIPS /NEA

Probably lead to unstable cell-reselection Allow UE to camp on the cell while being further away from the transmitting antennas. KPI Impact: Attach/Detach - low values might negatively impact (delay or make impossible) the attach operation. Coverage - lower value means larger cells. Mobility - high values might create coverage discontinuity in idle, as seen by mobile. When trying to match the idle mode cell size and active mode cell size, i.e. optimize the value of this parameter, drive tests must be performed in the cell. The testing procedure should comprise the following steps: Step 1: With UE in active mode, perform a drive test back and forth between the two cells on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 2: Post process the logged data and determine the cell edge, as being the positions at which the UE switched to the neighbour cell and the measured SINR at those locations. Step 3: Set the value of qRxLevMin to one of the following values {- 124, -122, -120, -118, -116}. Step 4: With UE in idle mode, perform a drive test back and forth between the two cells on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 5: Choose another qRxLevMin and repeat Step 4. Step 6: Post process the logged data and determine the positions at which the UE started searching for another cell and the positions at which UE switched to the neighbour cell along with the measured SINR. Step 7: Based on the cell size in active mode and cell sizes in idle mode, choose the optimized value in order to compensate if you have a smaller or lager cell than you wish.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 33/194


MGR /TIPS /NEA

Figure 8.2-2: Throughput vs. RSRP – 700 (Field Results VzW)


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 34/194


MGR /TIPS /NEA

Figure 8.2-3: Throughput vs. RSRP – AWS (Field Results VzW)

qRxLevMin selection if: Edge Cluster Cell



Edge Cell (IM / MOB)



Inter-Cells Gaps



Inter-Cells Overlapping 

Cell load



Figure 8.2-4: qRxLevMin Selection


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 35/194


MGR /TIPS /NEA

8.2.8 P0NOMINALPUSCH This parameter is, somehow indirectly, impacting the power the UE transmits, before any power control commands is being received from the eNodeB. This parameter is a key RF optimization parameter. Higher settings will improve PUSCH reception, but will also drive higher UE Tx power leading to interference to neighbouring cells, and vice-versa. Its current default value is -108dBm. Indeed, the power of the UE will be adapted once the transmission is being started and the impact this parameter has on the UE power decreases with time. Pusch Power/RB = P0 NominalPusch + alpha*Pathloss

Optimization would mean finding the best value that, at the same time, for which the PUSCH reception is good enough, even at the beginning of the PUSCH transmission, and the interference created towards the neighbour cells is kept to an acceptable level. For more details on the PUSCH power control see the end of this paragraph. Recommended Value = “-108” in case of fractional power control not used; Or Recommended Value = “-79” in case of fractional power control used with 0.7 v alue in pUSCHPowerControlAlphaFactor Expected behaviour when value is modified Increasing the value of this parameter would: Increase the interference in the neighbour cells at the beginning of PUSCH transmission which might temporally decrease the throughput of users found at the cell edge in the neighbour cells. Temporally result in a high SINR for PUSCH transmission which can be reflected in higher MCSs at the beginning of PUSCH transmission. The convergence of the PC algorithm could take more time thus the interference towards other cells could last longer Decreasing the value of this parameter would: Temporally result in a low SINR for PUSCH transmission which can be reflected in higher BLER and/or lower MCSs at the beginning of PUSCH t ransmission.

KPI Impact: Coverage – higher value will temporarily increase the UL interference Access – lower values might increase the access time

For optimizing the value of this parameter for minimizing the interference in neighbour cells, two cells and several UEs are needed (in the interfering cell). The following steps must be performed (this recommendation is only for the UL Fractional Power Control Disabled ): Step 1: In victim sell, use the default p0NominalPUSCH value. In the interfering cell, set p0NominalPUSCH to one of the values {-112, -110, -108, -106, -104}. Step 3: In interfered cell perform an UL data transfer and log data related to PC command (TPC command field or F value) and PUSCH BLER and PUSCH DM RS SINR. Step 4: In the interfering cell, with UEs located near the cell edge, perform UL data transfer with several UEs, in synchronous manner. Step 5: In the interfering cell choose another value for p0NominalPUSCH and repeat Step 3 and Step 4. Step 6: Post process the logged data and provide results in terms PUSCH BLER of the average PUSCH DM RS SINR for each value p0NominalPUSCH in the interfering cell. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 36/194


MGR /TIPS /NEA

The most important power control aspects are: Open-loop power control with slow aperiodic closed loop correction factor Fractional path loss compensation with PL compensation factor Accumulated UE-specific closed-loop correction is used. The setting of the UE Transmit power P PUSCH for the physical uplink shared channel (PUSCH) transmission in the subframe is defined by: P PUSCH (i) = min { P MAX , 10.log10(MPUSCH (i)) + P 0_PUSCH + pUSCHPowerControlAlphaFactor.PL + ΔTF (TF(i)) + f(i) }

Where: PMAX is the maximum allowed power that depends on the UE power class MPUSCH (i) is the bandwidth of the PUSCH transmission expressed in number of resource blocks taken from the resource allocation valid for uplink subframe i from scheduling grant received on subframe i-KPUSCH. P0 _PUSCH is a parameter obtained as a sum of a cell specific nominal component p0NominalPUSCH signalled from higher layers and a UE specific component p0UePUSCH . pUSCHPowerControlAlphaFactor is a cell specific parameter signalled from higher layers in order to support fractional power control. PL is the downlink path loss estimate calculated in the UE. ΔTF(TF (i)) denotes the power off set depending on PUSCH transport format TF(i). Both accumulated and non accumulated power control rules are used – this is set by means of parameter accumulation Enabled. The current PUSCH power control adjustment state in subframe i is given by f (i): f(i) = f(i-1) + δPUSCH(i-KPUSCH), if accumulation Enabled is enabled f(i) = δPUSCH(i-KPUSCH), if accumulation Enabled is disabled where: δPUSCH is a UE specific correction value in dB, also referred to as a TPC command and is included in PDCCH with DCI format 0 on subframe i-K PUSCH. f(0) = 0. For case when enabling Fractional Power control use following formula for applying the correct value to the parameter: P0NOMINALPUSCH = SIRTARGETMIN + (1 - Alpha) x PL MAX + I IOT

Example 1: for pUSCHPowerControlAlphaFactor =1, and SINR_target_nominal = 1 dB, p0NominalPUSCH = 1 + 0 -112 = -111 dBm Example 2: for pUSCHPowerControlAlphaFactor =0.7, and SINR_target_nominal = 15 dB, p0NominalPUSCH = 15 + (1-0.7)*140 – 112 = -55 dBm Where SINR_target_nominal = uplinkSIRtargetValueForDynamicPUSCHscheduling


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 37/194


MGR /TIPS /NEA

Figure 8.2-5: Po_pusch_Nominal Impact

8.2.9 UPLINKSIRTARGETVALUEFORDYNAMICPUSCHSCHEDULING This parameter is used inside PUSCH power control algorithm as outer loop power control for nonsemi-static. It is used as an initial target for the SINR values. During transmission, the SINR targets are changing based on the measured path loss. The input of the UL outer-loop power control function is the path loss along with some other parameters. The SIR target is modified by using the following formula:

In the commercial mode, and on a network level, the higher the SINR target (i.e. the higher the setting of uplinkSIRtargetValueForDynamicPUSCHscheduling) the higher the near-cell throughput but the higher the interference generated in the different cells of the network (and thus the lower the cell-edge throughput and at some point the lower overall cell throughput too). In this case, the default setting of this parameter (for a target IoT of 5.5 dB and a nominal path loss of 60 dB) should be as follows:

Recommended Value = “1.0” in case of fractional power control not used; Or Recommended Value = “19.0” in case of fractional power control used with 0.8 value in pUSCHPowerControlAlphaFactor

Increasing the value of this parameter would: Increase the transmission power of the UE which would result in using higher MCSs and obtaining higher throughputs. If the default setting of pUSCHPowerControlAlphaFactor is used, then the SIR target will be the same irrespective of the path loss and the UE power will be kept high. The UE power will reach its maximum value for lower path losses and thus the life of UE battery will be decreased. Increase interference in the neighbour cells due to higher transmitting power. This would result in lower throughputs in the neighbour cells. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 38/194


MGR /TIPS /NEA

Decreasing the value of this parameter would: Decrease the power of the UE which would result in lower MCSs and lower t hroughputs. Decreasing this parameter will decrease the overall level of interference and hence improve the throughput of cell-edge users at the expense of cell-centre UEs, i.e. the peak throughputs will be lower. KPI Impact: Throughput: high values increase the throughput for near cell and mid-cell conditions. Capacity - high values allow reaching the capacity for a wider range of propagation conditions. Coverage - high values might reduce the coverage if the target is not dynamically adjusted based on propagation conditions. Mobility - might negatively impact the throughput during handover if the threshold is set too high. For optimizing the value of this parameter for minimizing the interference in neighbour cells while maximizing the throughput in the analyzed cell, two cells and several UEs are needed (in the interfering cell). The following steps must be performed: Step 1: In victim cell, use the default parameters. In the interfering cell, set uplinkSIRtargetValueForDynamicPUSCHscheduling to one of the values {15, 14, 10, 8, and 6}. Step 2: In victim cell perform an UL data transfer and log data related to PC command (TPC command field or F value) and PUSCH BLER and PUSCH DM RS SINR. Step 3: In the interfering cell, with UEs located near the cell edge, perform UL data transfer with several UEs, in synchronous manner and log the value of the throughput. Step 4: In the interfering cell choose another value for uplinkSIRtargetValueForDynamicPUSCHscheduling and repeat Step 2 and Ste p 3. Step 5: Post process the data and choose the value of uplinkSIRtargetValueForDynamicPUSCHscheduling that provides an acceptable trade-off between the throughput in the interfering cell and the throughput in the victim cell.

s l o p e =

Target SINR

-

( 1 - P

U S C H P o w e r C o n t r o l A l p h a F a c t o r )

maxSIRtargetForFractionalPowerCtrl uplinkSIRtargetValueForDynamicPUSCHscheduling

minSIRtargetForFractionalPowerCtrl

PL

pathLossNominal

Figure 8.2-6: Slope - PuschPowerControl vs. uplinkSIRtargetValueForDynamicPUSCHscheduling

9 ACCESS OPTIMIZATION HINTS In this chapter it will be highlighted the main focus of testing and the primary steps that will allow to optimize a specific domain and the most important /priority parameters; in this case the domain addressed is access in LTE. Normally some questions arise, such as: Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 39/194


MGR /TIPS /NEA

When to perform access optimization? What method to apply? Which parameters can help improving access to the network? Mainly the Access optimization can occur when the attach success rate is b elow the ALU KPI As main indicator to evaluate the performance several tests to access the network should be performed; although before starting playing with the parameterization; usually is part of best practice rules for in Near Cell /Mid Cell & Cell Edge test to follow up simple steps as: Check the CQI Evaluate RSSI vs. SNR relation Evaluate RSRP vs. RSRQ If we could guarantee that these values are “normal”, the chances to have performance issues are much less difficult to occur. If regardless of the correct values, still facing some performance issues, the below parameters can be used in order to correct the situation. When changing parameters; you can adopt a more error-free approach, meaning that a parameter is changed at each time. If three or four parameters are changed same time… it could be difficult to understand which one is bringing the improvement in performance. As note; please remember that this can be a static test in each position, or can be a moving test… the same principles can be applied in both situations.

9.1 PARAMETERS OPTIMIZATION FOR IMPROVING ATTACH/DETACH PROCEDURES The attach procedure is one of the most basic procedure in LTE. It implies an exchange of several messages between eNodeB and UE. The physical channel that is used for attach procedure is PRACH. The UE transmits a Random Access preamble when communication with the E-UTRAN is needed, for example in order to make a service request. When the eNodeB correctly receives a RA preamble, and if resources are available, it will respond with a RA response. This RA response contains, among other information, an initial UL grant to be used by the UE for the next UL message, namely the RRC Connection Request message (see Figure 1 above). There are several parameters directly involved in the RACH preamble procedure. The most important of them are described in this chapter.

9.1.1 PREAMBLEINITIALRECEIVEDTARGETPOWER Open-loop power control is applied for initial transmission of RACH (i.e. message1). The transmit power is determined by taking into account the total UL interference level and the required SINR operating point. Transmit power can be determined at the UE as: (1) PRACH_msg1 = min {PMAX, PL + P0_PREAMBLE + (NPREAMBLE - 1) x ΔRAMP_UP}

• The term PL is the DL path loss estimated at the UE from DL RS. • P 0 _PREAMBLE is the preamble received power set point determined at the eNodeB. This parameter is calculated from the target SINR operating point (SINRTarget), and the UL interference-plus-noise (IN) power in the PRACH resource. Possible margin may be added to account for any measurement error. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 40/194


MGR /TIPS /NEA

The parameter preambleInitialReceivedTargetPower configures P0 _PREAMBLE. (2) P0_PREAMBLE = SINRTarget + IN + Margin

• ΔRAMP _UP is the power ramping step size. It is configured by parameter preambleTransmitPowerStepSize. • NPREAMBLE is the preamble transmission number (=1 for first transmission) up to maximum number of transmissions. This maximum number of transmissions is configured by parameter preambleTransMax. At each new transmission of the preamble, the power is ramped up by Δ RAMP _UP dB until we reach the maximum number of transmissions preambleTransMax . If the mobile still does not receive any Random Access response from the eNodeB, the UE MAC layer then declares the Random Access procedure as failed.

Figure 9.1-1: preambleTransMax vs. preambleInitialRceivedTargetPower vs. preambleTransmitPowerStepSize

Po_PREAMBLE inpact on UE TxPow vs PL(RA) (TRY1) 30

20

10 r e w o 0 P x T H C-10 A R P

Try1#-104 Try1#-96

-20

-30

-40 70

75

80

85

90

95

100

105

110

115

120

125

130

135

140

145

150

-37. 5

-42. 5

-47. 5

-52. 5

-57. 5

-62. 5

-67. 5

-72. 5

-77. 5

-82. 5

-87. 5

-92. 5

-97. 5

-102. 5

- 107. 5

-112. 5

-117. 5

PL Estim.

Figure 9.1-2: Po_preamble impact on UE Tx Power vs. PL(RA) (TRY1)


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 41/194


MGR /TIPS /NEA

Figure 9.1-3: Po_preamble impact on UE Tx Power vs. PL (RA)

Figure 9.1-4: preambleTransMax vs. preambleInitialRceivedTargetPower vs. preambleTransmitPowerStepSize (example of values) Let‟s consider PL = 90; PRACH_msg1 = min {PMAX, PL + P0_PREAMBLE + (NPREAMBLE - 1) x ΔRAMP_UP}; 1st try NPREAMBLE =1 PRACH_msg1= min {PMAX, 90 + P0_PREAMBLE + 0} => PRACH_msg1= -14 [dBm] PRACH_msg1= min {PMAX, 90 + P0_PREAMBLE + 6} => PRACH_msg1= -8 [dBm] PRACH_msg1= min {PMAX, 90 + P0_PREAMBLE + 12} => PRACH_msg1= -2 [dBm]

Recommended & Default Value= “dBm-104”

Expected behaviour when changing this parameter Increasing the value of this parameter would: Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 42/194


MGR /TIPS /NEA

Minimize the repetitions i.e. RACH attempts and hence expedite call setup, but will cause higher interference to other cells during the attach procedure. Thus there will be higher interference during a shorter period of time. Decreasing the value of this parameter would: Increase RACH repetitions / call setup delay and decrease the interference. One specific UE will generate lower interference but for la longer period of time. When there are several UEs in the cell, the total interference might not decrease.

KPI Impact: Attach/Detach: low values of this parameter can delay the success of the attach operation. Very low values might even make the attach operation impossible.

A good optimization criterion for this parameter would be to set it to the lowest limit that ensures that the required RACH preamble success rate at 1st attempt is achieved. The optimization of this parameter should consider the steps be low: Step 1: In the database, check that the default value dBm-104 is set. Step 2: Perform drive tests while connecting and disconnecting the UE in various parts of the cell while logging the data and the GPS position. Step 3: Change the value of the parameter to the following {dBm-108, dBm-106, dBm-102, dBm-100} and repeat Step 2 on the similar route. Step 4: Provide results in form of three graphs representing: •Average number of repetitions before RA success vs. preambleInitialReceivedTargetPower •Average preamble power for the successful try vs. preambleInitialReceivedTargetPower. •Average time for RA success vs. preambleI nitialReceivedTargetPower

9.1.2 PREAMBLETRANSMITPOWERSTEPSIZE This parameter is a key RF optimization parameter that impacts connection setup performance and uplink interference to neighbouring cells. Higher values will minimize the repetitions/ RACH attempts and hence expedite connection setup, but will cause higher interference to other cells. Lower values will tend to increase RACH repetition/ connection setup delay. The current default value for this parameter is dB6.

Recommended & Default Value= “dB6”

Increasing the value of this parameter would: Minimize the repetitions i.e. RACH attempts and hence expedite call setup, minimize the time the UE generates interference in the system due to random access procedure. Highest values might create unnecessary-high interference for the last random access attempt (the successful one). Decreasing the value of this parameter would: Increase RACH repetitions / call setup delay and decrease the interference. One specific UE will generate lower interference but for la longer period of time.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 43/194


MGR /TIPS /NEA

KPI Impact: Attach/Detach: low values of this parameter can delay the success of the attach operation. Very low values might even make the attach operation impossible. Mobility: low values might lengthen the interruption time .

A good optimization criterion for this parameter would be to set it to the value that minimizes the number of preamble transmissions. The optimization of this parameter must be performed in conjunction with the optimization of the previous parameter. It is best to start optimization by first considering the highest value of this parameter i.e. dB6 The optimization of this parameter should consider the steps be low: Step 1: In the database, check that the value dB6 is set. Step 2: Perform drive tests in near-cell, mid-cell and cell-edge conditions while connecting and disconnecting the UE and while logging the data and the GPS position. Step 3: Change the value of the parameter to the following {dB4, dB2} and repeat Step 2 on the similar route. Step 4: Provide results in form of three graphs representing: •Average number of repetitions before RA success vs. preambleTransmitPowerStepSize •Average preamble power for the successful try vs. preambleTransmitPowerStepSize. •Average time for RA success vs. preambleTransmitPowerStepSize

9.1.3 SCHEDULED TRANSMISSION (DELTAPREAMBLEMSG3 OR TPCRACHMSG3) The Nominal transmit power for RACH msg3, denoted as P O_ NOMINAL _ PUSCH is computed at the UE as: PO_ NOMINAL _ PUSCH = PO_ PREAMBLE + ΔPREAMBLE _Msg3 where ΔPREAMBLE _Msg3 is the nominal power offset between RACH preamble and RACH message 3. It is configured by parameter deltaPreambleMsg3 as follows ΔPREAMBLE _Msg3 = deltaPreambleMsg3 + 3dB. The Transmit power of the UE for RACH message 3 is determined (in dBm) by normal PUSCH power control formula: P0_NOMINAL_PUSCH PPUSCH(i) = min { P MAX,10log10 (MPUSCH (i )) + + P0 _UE_PUSCH +pUSCHPowerControlAlphaFactor x PL + Δ TF(i)+f(i)} f(i) is initialized (for the first transmission of RACH message 3) as follows f (0) = ΔPrampup +δmsg2 where δmsg2 is the TPC command indicated in the Random Access Response (RACH message 2) and set by tPCRACHMsg3 (see next parameter for optimization) For subsequent transmission of RACH message 3, accum ulated power control formula f (i) = f (i −1) +δPUSCH(i − KPUSCH ) applies. deltaPreambleMsg3 – mostly impacts the first transmission of Msg3, before TPC acts for adjusting the transmitting power according to propagation conditions.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 44/194


MGR /TIPS /NEA

Figure 9.1-5: Parameters dependency and relations Increasing the value of these parameters would: Minimize the number of HARQ retransmissions and hence shorten attach procedure time Minimize the time the UE generates interference in the system due to random access procedure. Interference is less critical for Message3 due to the fact that it is scheduled. Decreasing the value of these parameters would: Potentially increase the number of HARQ retransmissions with lower initial power. The UE will generate lower interference but possibly for a longer period of time.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 45/194


MGR /TIPS /NEA

KPI Impact: Attach/Detach: low values of this parameter(s) can slightly delay the success of the attach operation.

9.1.4 DELTAPREAMBLEMSG3 A good optimization criterion for this parameter ( deltapreamblemsg3) would be to set it to the value that minimizes the number of HARQ retransmissions of Msg3.

Recommended & Default Value= “0”

The optimization of this parameter should consider the steps be low: Step 1: In the database, check that the value 0 is set. Step 2: Perform drive tests in near-cell, mid-cell and cell-edge conditions while connecting and disconnecting the UE and while logging the data and the GPS position. Step 3: Change the value of the parameter to the following {2, 4} and repeat Step 2 on the similar route. Step 4: Provide results in form of one graph representing: Average number of HARQ retransmissions vs. deltaPreambleMsg3

Step 5: Consider as optimum the minimum value of deltaPreambleMsg3 which requires the minimum number of HARQ retransmission of Msg3.

9.1.5 TPCRACHMSG3 A good optimization criterion for this parameter ( tPCRACHMsg3) would be to set it to the value that minimizes the number of HARQ retransmissions of Msg3.

Recommended & Default Value= “4dB”

The optimization of this parameter should consider the steps be low: Step 1: In the database, check that the value 4dB is set. Step 2: Perform drive tests in near-cell, mid-cell and cell-edge conditions while connecting and disconnecting the UE and while logging the data and the GPS position. Step 3: Change the value of the parameter to the following {2dB, 6dB} and repeat Step 2 on the similar route. Step 4: Provide results in form of one graph representing: Average number of HARQ retransmissions vs. tPCRACHMsg3

Step 5: Consider as optimum the minimum value of tPCRACHMsg which requires the minimum number of HARQ retransmission of Msg3.

10 DOWNLINK THROUGHPUT OPTIMIZATION HINTS In this chapter it will be highlighted the main focus of testing and the primary steps that will allow to optimize a specific domain and the most important /priority parameters; in this case the domain addressed is Downlink Throughput in LTE. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 46/194


MGR /TIPS /NEA

Normally some questions arise, such as: When to perform DL Throughput optimization? What method to apply? Which parameters can help improving DL Throughput? Mainly the DL t-put optimization can occur when the average throughput value for a specific location is not matching the ALU product specification for a determined Bandwidth target. Before starting playing with the parameterization; usually is part of best practice rules for in Near Cell /Mid Cell & Cell Edge test to follow up simple steps as: Check the CQI Check the MCS triggered Check the DL BLER Evaluate RSSI vs. SNR relation Evaluate RSRP vs. RSRQ If we could guarantee that these values are “normal”, the chances for having performance issues are much less difficult to occur. If regardless of the correct values, still facing some performance issues, they below parameters can be used in order to correct the situation. When changing parameters; you can adopt a more error-free approach, meaning that a parameter is changed at each time. If three or four parameters are changed same time… it could be difficult to understand which one is bringing the improvement in performance. As note; please remember that this can be a static test in each position, or can be a moving test… the same principles can be applied in both situations.

10.1 PARAMETERS THROUGHPUT

OPTIMIZATION

FOR

IMPROVING

DOWNLINK

10.1.1 DLMCSTRANSITIONTABLE This table contains 28 float values representing the thresholds of SINRs values for which the DL modulation is being changed and it is part of an intricate algorithm inside DL scheduler. Optimization of this table would imply changing the values of the thresholds either by decreasing them or by increasing them. Indeed, it is not necessary to have them all increased or all decreased. Both uniform and non-uniform modifications of these values are possible. Below, several suggestions are presented, two of them implying uniform modifications of threshold values and four of them considering non-uniform modifications.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 47/194


MGR /TIPS /NEA

Figure 10.1-1: Radio link Quality vs. MCS Robustness vs. Throughput In the above Figure 10.1-1 it can be observed that both Radio Link Quality, MCS‟s Robustness and Throughput are closely related… meaning that for a better Radio Link, this would imply a less robust MCS, but in other hand, the final result is a higher Throughput!

Figure 10.1-2: Radio link Quality vs. dlMCSTransition Table vs. Throughput In the table below there are several (academic) examples of t hreshold tuning for a 10MHz band.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 48/194


Default

Down Shift

Up Shift

-2.5 -1.75 -1.25 -0.5 0.5 1

-2.5 -2 -1.25 -0.25 0.75 1.75

-2.5 -4 -3.75 -3.5 -3.25 -2.25

DecreaseLower IncreaseHigher Significant -2.5 -4 -3.74 -3.67 -3.44 -3.22

MGR /TIPS /NEA

DecreaseLower IncreaseHigher Moderate -2.5 -4 -3.495 -2.96 -2.345 -1.735

IncreaseLower DecreaseHigher Significant -2.5 -3.89 -1 1 2.58 4

IncreaseLower DecreaseHigher Moderate -2.5 -3.945 -2.125 -0.625 0.665 1.875

2 2.5 -1.5 -2.91 -1.205 4.88 2.69 3 3.5 -0.5 -2.61 -0.555 5.45 3.475 3.75 4.5 0.5 -2.16 0.17 5.83 4.165 4.75 5.5 1.5 -1.71 0.895 6.13 4.815 5 6.25 2.25 -1.26 1.495 6.21 5.23 6 6.75 2.75 0 2.375 6.28 5.515 7 7.75 3.75 2.51 4.13 6.36 6.055 7.5 8.5 4.5 6.51 6.505 6.5 6.5 8.5 9.5 5.5 10.13 8.815 6.88 7.19 9 10.5 6.5 12.84 10.67 6.96 7.73 10.25 11 7 14.65 11.935 7.11 8.055 11.5 12 8 15.63 12.925 7.26 8.63 11.75 12.5 8.5 16.23 13.555 7.49 8.995 12.75 13.5 9.5 16.53 14.25 7.8 9.65 13.5 14.25 10.25 16.83 14.73 8.18 10.215 14.25 15.25 11.25 17.06 15.305 8.57 10.91 15.5 16 12 17.29 15.755 9.26 11.63 16.25 17 13 17.36 16.33 9.72 12.36 17 17.25 14 17.44 16.905 10.41 13.205 17.75 17.5 14.75 17.51 17.14 11.41 14.08 19 17.75 15.75 17.59 17.36 13.32 15.535 9.07 18 16 17.66 18 17.54 17.77 Table 10-1: Examples of threshold tuning for a 10MHz band (academic only, not applied in any trial /project).

Recommended & Default Value= "Default Table"

Increase all threshold values (up-shift) will result in lower data rates because higher MCS will only be selected for higher values of SINRs. Indeed, due to improved SINRs when a given MCS is selected, there will be a lower percentage of transmission errors over air interface. Decrease all values of the thresholds (down - shift) will lead to more optimistic MCS assignments and hence, higher bitrates and possibly more HARQ re transmissions and higher BLERs. Keep the lower values unchanged and gradually increase/decrease the higher values. Such a modification will only force less/more robust MCSs (i.e. higher/lower data rates) for good propagation conditions. Keep the higher values unchanged and gradually increase/decrease the lower values . Such modifications will only force less/more robust MCSs (i.e. higher/lower data rates) for bad propagation conditions. Increase the lower values and decrease the higher values while keeping the middle values unchanged. Such a modification will force more robust MCSs (i.e. lower data rates) for bad propagation conditions and will force less robust MCSs (i.e. higher data rates) for good propagation conditions.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 49/194


MGR /TIPS /NEA

Decrease the lower values and increase the higher values while keeping the middle values unchanged. Such modifications will force less robust modulations (i.e. higher data rates but possible higher BLER) for bad propagation conditions and more robust MCSs (i.e. lower data rates) for good propagation conditions.

All types of thresholds tuning specified above can indeed be performed by changing the thresholds by various amounts. Finding the best type of modification and the amount by which the changes are made is part of the optimization process. KPI Impact: Throughput - proper tuning increases the throughput Capacity - proper tuning can increase the capacity (capacity reached over a slightly wider range of propagation conditions). For finding the optimum set of SINR thresholds among the sets proposed in the table above, a drive test is needed in the cell to be optimized. The flowing steps need to be performed and the optimum set of thresholds shall be chosen based on the observed performance. Step 1: In the eNodeB database, choose the default set of values for dlMCSTransitionTable, the values in the “Default” column in the table above. Step 2: While performing DL UDP transfer, perform a drive tests through the cell for covering various morphologies and positions relative to the transmitting antennas (near-cell, mid-cell, cell edge) and log the instantaneous throughput. Step 3: Chose another set of values from the table above and repeat Step 2.

10.1.2 DLSINRTHRESHOLDBETWEENCLMIMOONELAYERANDTXDIV dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv defines the switching threshold between TxDiv and 1-layer CL-MIMO. Although the recommendation is to use the value -10 in order to k eep as minimum the 1-layer CL-MIMO; disabling in this manner t he Tx-Div.

Recommended & Default Value= "-10"

Some considerations regarding this parameter:

dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv If parameter is set equal to dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer the downlink transmission scheme configured at cell level will be eit her TxDiv or 2-layer CLMIMO (i.e. CL-MIMO 1 layer is disabled), the switching threshold being dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv = dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer in this case. If, besides, the reported (and filtered) rank is 1, the downlink transmission scheme will just be TxDiv. Also, if parameter macMIMOModeDl is set to “MimoTwoLayersNotAllowed”, the downlink transmission scheme configured at bearer-type level will be TxDiv for all the cells hosted by the eNB. Note that the configuration dlSinrThresholdBetweenCLMimoOneLayerAndTxDiv > dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer must be avoided.

Increasing the value of this parameter would: Force TX Div instead of 1-Layer Closed Loop which will be reflected in lower throughputs and performance for the same radio condition.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 50/194


MGR /TIPS /NEA

10.1.3 DLSINRTHRESHOLDBETWEENCLMIMOTWOLAYERSANDONELAYER dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer sets the SINR threshold for switching between the two transmissions modes in transmission mode TM4 this is, sets the switching between the Closed Loop Mimo One Layer and Closed Loop Mimo Two Layers. High values will reduce Downlink data rate too soon.

Figure 10.1-3: Dl Sinr Threshold Example Recommended Value= "12"

Increasing the value of this parameter would: Force 1-Layer CL-MIMO in good transmission conditions which will be reflected in lower throughputs for good radio condition. Decreasing the value of this parameter would: Force 2-Layer CL-MIMO for bad propagation condition. This will be reflected in lower throughput at least for SINRs values situated between the actual val ue of the threshold and the optimized value of the threshold. Higher BLER and increased HARQ retransmissions might as well b e observed. KPI Impact: Throughput - values both higher and lower than the optimal value decrease the throughput . For finding an optimized value of this parameter (i.e. the one that maximizes the throughput) for a given environment, a procedure containing the steps below can be used: Step 1: In the database, set transmission mode = tm4 and check that default value of dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer (i.e. 15) is also correctly set. Step 2: While performing DL FTP/UDP transfer, perform a drive tests through the cell and log the instantaneous throughput. Step 3: Repeat Step 1 & 2 for the following set of values of dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer: {9, 11, 13, and 17} Step 4: Provide results in form of a graph representing average throughput versus dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer values Step 5: Provide recommendations for choosing dlSinrThresholdBetweenCLMimoTwoLayersAndOneLayer


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 51/194


MGR /TIPS /NEA

Figure 10.1-4: CL 2Layer-1Layer SNR Switch Threshold: 10 dB (purple) vs . 12 dB (blue) AWGN (Lab results VzW)

Figure 10.1-5: CL 2Layer-1Layer SNR Switch Threshold: 10 dB (purple) vs. 12 dB (blue) EPA 5Hz, Medium Correlation (Lab Results VzW)

10.1.4 DLSINRTHRESHOLDBETWEENOLMIMOANDTXDIV dlSinrThresholdBetweenOLMimoAndTxDiv Determines the value of the SINR to which there is a switch between the two transmission modes available in tm3 i.e. OL MIMO and Tx Div. Higher values will reduce DL data rate otherwise achievable in the higher SINR regime. Lower values would allow OL MIMO too soon, resulting in HARQ retransmission rates and BLERs higher than achievable with Tx diversity and hence the use of an MCS with a lower DL data rate/throughput.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 52/194


MGR /TIPS /NEA

Figure 10.1-6: Dl Sinr Threshold Example dlSpeedThresholdBetweenOLMimoAndTxDiv configure thresholds ThSinrMimo and ThSpeedMimo, respectively.

Recommended Value= "15"

Increasing the value of this parameter would: Force TxDiv in good transmission conditions which will be reflected in lower throughputs for good radio condition. Decreasing the value of this parameter would: Force OL MIMO for bad propagation condition for which the MIMO algorithms are not anymore performing well. This will be reflected in lower throughput at least for SINRs values situated between the actual value of the threshold and the optimized value of the threshold. Higher BLER and increased HARQ retransmissions might as well be observed. KPI Impact: Throughput - values both higher and lower than the optimal value decrease the throughput . For finding an optimized value of this parameter (i.e. the one that maximizes the throughput) for a given environment, a procedure containing the steps below can be used: Step 1: In the database, set the transmission mode to tm3 and check that the default value of dlSinrThresholdBetweenOLMimoAndTxDiv (i.e. 15) is also correctly set. Step 2: While performing DL FTP/UDP transfer, perform a drive test and log the instantaneous throughput. Step 3: Repeat Step 1 and step 2 the following set of values of dlSinrThresholdBetweenOLMimoAndTxDiv: {i.e. 9, 11, 13 and 17} Step 4: Provide results in form of a graph representing average throughput versus dlSinrThresholdBetweenOLMimoAndTxDiv values Step 5: Provide recommendations for choosing dlSinrThresholdBetweenOLMimoAndTxDiv.

10.1.5 ALPHAFAIRNESSFACTOR AlphaFairnessFactor: tunes the alpha fairness factor of the DL scheduler alphaFairnessFactor = 0 yields a maximum C/I scheduler. The scheduler provides more resources to UEs in better conditions Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 53/194


MGR /TIPS /NEA

alphaFairnessFactor = 1 yields a fair scheduler. The scheduler attempts to provide the same number of RBs to all the UEs alphaFairnessFactor = 2 yields an increased fairness scheduler. The scheduler attempts to allocate the resources in such a way that all the UEs eventually get the same data rate. Deafult Value= "1" In the Figure 10.1-7 it is presented the impact of using the different values for alphaFairnessFactor; such as 0 or 2.

Figure 10.1-7: alphaFairnessFactor Change Impact The test in Figure 10.1-7 was performed with the usual configuration; 2NC; 4MC; 2CE, and having the different alphafairnessFactor will make the scheduler to adjust more or less fair the resources to all the ue's; resulting in a lower sector t-put for the more fair distribution of resources. KPI Impact: Throughput – Low values increase the throughput in the near&mid-cell condition at expense of cell edge users. Capacity - Low values increase the cell overall throughput at expense of cell edge users.

10.1.6 DYNAMICCFIENABLED This parameter when set to “True” allows the CFI to be dynamically adjusted to use the lowest value needed for PDCCH usage. This makes more OFDM symbols available to PDSCH when PDCCH usage is low (fewer users), resulting in higher throughputs. In this case (dynamicCFIEnabled set to “True), parameter cFI is ignored. When set to “False”, the CFI is static and derived from parameter cFI. The latter should be set keeping in mind that value “1” is only supported in 20 MHz and knowing that higher values of CFI allow for more PDCCH robustness and/or more users served per TTI, but at the expense of throughput (fewer resources for PDSCH). Recommended Value= "True"

In the Table 10-2 it is illustrated the theory impact on the PDSCH channel when disabling the DynamicCFI and “forcing” the usage of different values for CFI (1, 2 or 3). Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 54/194


MGR /TIPS /NEA

OFDM symbol per 1ms

CFI

PDSCH [symbol]

PDSCH usage[%]

PDSCH decrease [%]

14

1

13

92,86%

n/a

14

2

12

85,71%

7,14%

14

3

11

78,57%

7,14%

Table 10-2: Theory Assumption on CFI Tuning

10.1.7 CFI This parameter “Control Format Indicator” is limited to the value 1, 2 or 3. For bandwidths greater than ten resource blocks, the number of OFDM symbols used to contain the downlink control information is the same as the actual CFI value. Otherwise span of the downlink control information is CFI+1 symbol. It will be only taken into consideration if the dynamicCFIEnabled is set to “False”. Higher values of CFI allow for more PDCCH robustness and/or more users served per TTI, but at the expense of throughput (fewer resources for PDSCH). In the Table 10-2 we have the expected value when “playing” with the value of CFI. Recommended Value & Default= "5 & 10 MHz =3 for 20MHz = 2"

KPI Impact: Throughput – Low values increase the cell overall throughput.

Note: for a demo case & if you are in 20MHz and the goal is to show max troughput you can use the CFI set to “1”; but to be sure that also dynamicCFIEnabled is set to “false”; plus CFI1Llowed should set to "True". Using this set of parameters configuration and in near cell radio condition (optimum conditions); you can boost the Downlink Throughput, since his makes more OFDM symbols available to PDSCH when PDCCH usage is low (fewer users), resulting in higher throughputs.

10.1.8 CFI1ALLOWED Like the name indicates this parameter allows the usage or not of the value “1” for CFI. Only possible to use CFI =1 in 20MHz. Recommended Value & Default= "5 & 10 MHz = False for 20MHz = True"

10.1.9 CFI2ALLOWED Like the name indicates this parameter allows the usage or not of the value “2” for CFI. Recommended Value & Default= "True"


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 55/194


MGR /TIPS /NEA

10.1.10 CFI3ALLOWED Like the name indicates this parameter allows th e usage or not of the value “3” for CFI. Recommended Value & Default= "True"

11 UPLINK THROUGHPUT OPTIMIZATION HINTS In this chapter it will be highlighted the main focus of testing and the primary steps that will allow to optimize a specific domain and the most important /priority parameters; in this case the domain addressed is Uplink Throughput in LTE. Normally some questions arise, such as: When to perform UL Throughput optimization? What method to apply? Equipments and tools to use? Which parameters can help improving UL Throughput? Mainly the UL t-put optimization can occur when the average throughput value for a specific location is not matching the ALU product specification for a determined Bandwidth target. Before starting playing with the parameterization; usually is part of best practice rules for in Near Cell /Mid Cell & Cell Edge test to follow up simple steps as: Check the CQI Check the MCS triggered Check the UL BLER Evaluate RSSI vs. SNR relation Evaluate RSRP vs. RSRQ If we could guarantee that these values are “normal”, the chances to have performance issues are much less difficult to occur. If regardless of the correct values, still facing some performance issues, they below parameters can be used in order to correct the situation. When changing parameters; you can adopt a more error-free approach, meaning that a parameter is changed at each time. If three or four parameters are changed same time… it could be difficult to understand which one is bringing the improvement in performance. As note; please remember that this can be a static test in each position, or can be a moving test… the same principles can be applied in both situations.

11.1 PARAMETERS THROUGHPUT

OPTIMIZATION

FOR

IMPROVING

UPLINK

11.1.1 UPLINKSIRTARGETVALUEFORDYNAMICPUSCHSCHEDULING This parameter used inside PUSCH power control algorithm as outer loop power control. It is initial target for the SINR values. During transmission, the SINR targets are changing based on the measured PL. The input of the UL outer-loop power control function is the PL along with some other parameters. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 56/194


MGR /TIPS /NEA

The default value of this parameter is 10, but higher values, as high as 15, could be used for maximum throughput tests, especially outdoor for forcing higher power and thus allowing the compensation of higher PL for preserving the throughput. It is not recommended to consider high values in a loaded network due to increased interference even if the throughput for one user could be higher for higher values of this pa rameter. In high path loss conditions, the throughput with a lower SIR target becomes better because eNB will grant a lower MCS but with more PRBs than for high SIR Target.

Recommended & Default Value= "19" to be inline with default value of pUSCHPowerControlAlphaFactor that is "0.8"

PUSCHPowerControlAlphaFactor uplinkSIRtargetValueForDynamicPUSCHscheduling 1.0 1.0 0.8 19.0 Table 11-1: uplinkSIRtargetValueForDynamicPUSCHscheduling vs. PUSCHPowerControlAlphaFactor

Expected behaviour when changing this parameter Increasing the value of this parameter would: Increase the transmission power of the UE which would result in using higher MCSs and obtaining higher throughputs. If the default setting of pUSCHPowerControlAlphaFactor is used, then the SIR target will be the same irrespective of the path loss and the UE power will be kept high. The UE power will reach its maximum value for lower path losses and thus the life of UE battery will be decreased. Increase interference in the neighbour cells due to higher transmitting power. This would result in lower throughputs in the neighbour cells. Decreasing the value of this parameter would: Decrease the power of the UE which would result in lower MCSs and lower t hroughputs. Decreasing this parameter will decrease the overall level of interference and hence improve the throughput of cell-edge users at the expense of cell-centre UEs, i.e. the peak throughputs will be lower. KPI Impact: Throughput: high values increase the throughput for near cell and mid-cell conditions. Capacity - high values allow reaching the capacity for a wider range of propagation conditions. For optimizing the value of this parameter for minimizing the interference in neighbour cells while maximizing the throughput in the analyzed cell, two cells and several UEs are needed (in the interfering cell). The following steps must be performed: Step 1: In victim sell, use the default parameters. In the interfering cell, set uplinkSIRtargetValueForDynamicPUSCHschedulingto one of the values {15, 14, 10, 8, and 6}. Step 2: In victim cell perform an UL data transfer and log data related to PC command (TPC command field or F value) and PUSCH BLER and PUSCH DM RS SINR. Step 3: In the interfering cell, with UEs located near the cell edge, perform UL data transfer with several UEs, in synchronous manner and log the value of the throughput. Step 4: In the interfering cell choose another value for uplinkSIRtargetValueForDynamicPUSCHscheduling and repeat Step 2 and Ste p 3. Step 5: Post process the data and choose the value of uplinkSIRtargetValueForDynamicPUSCHscheduling that provides an acceptable trade-off between the throughput in the interfering cell and the throughput in the victim cell. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 57/194


MGR /TIPS /NEA

11.1.2 PUSCHPOWERCONTROLALPHAFACTOR Part of PUSCH power control and is intended to allow partial compensation of the path loss or otherwise stated it allows controlling, by decreasing, the PUSCH power for users in cell edge conditions. If set to 1, an increase in path loss will determine the same increase in PUSCH power. If this parameter is not set to 1, the increase in PUSCH power can be lower than the increase in path loss. It is thus a means of controlling the UL interference created in the neighbour cell by the UEs found near the cell edge. Because the value of this parameter represents a trade-off between minimizing interference and maximizing throughput, its value must be set according to the client‟s desired network behaviour. If Fractional Power Control is used, the recommended value of this parameter is 0.8. If Fractional Power Control is not to be used, the parameter must have the value 1.

Recommended Value= "0.8"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Increase PUSCH power for a given path loss.

Increase the throughput for the users experiencing cell edge propagation conditions. Increase the interference toward the neighbouring cells which might lower the throughput of users being in cell edge propagation conditions in neighbour cells. Decreasing the value of this parameter would: Decrease PUSCH power for a given path loss. Decrease the throughput for the users experiencing cell edge propagation conditions. Decrease the interference toward the neighbouring cells which might increase the throughput of users being in cell edge propagation conditions in neighbour cells. KPI Impact: Throughput – high values increase the throughput in the near&mid-cell condition. The Edge cell performances depend on PL & MonoUE vs. MultiUE. High values may lead to a decrease in the overall system capacity in Uplink, due to increased UL interference.

The optimization process of this parameter should include the customer definition of the optimum trade-off between cell throughput and interference towards the neighbour cells. The choice can be different if cell wise optimization is to be performed or if a network wide setting is being aimed Step 1: Set the pUSCHPowerControlAlphaFactor to 1 and connect the UE in Near-Cell radio conditions. For a closer view to the lab r esults IoT should be considered. Step 2: Start a UL UDP transfer and start driving from Near-Cell towards Edge-Cell. For a more consistent data we recommend a drive back as well logged in another trace. Step 3: Using the same cell and same route choose another value for pUSCHPowerControlAlphaFactor = {0.9, 0.8, 0.7, 0.6, 0.5, and 0.4} and repeat Step 1 and Step 2. Step 4: Post process the logged data and provide results in terms of UE TxPower, UL Throughput and PUSCH BLER.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 58/194


MGR /TIPS /NEA

Figure 11.1-1: Impact of the pUSCHPowerControlAlphaFactor =1.0 in MCS usage.

Figure 11.1-2: Impact of the pUSCHPowerControlAlphaFactor =0.8 in Throughput per RB


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 59/194


MGR /TIPS /NEA

Figure 11.1-3: Impact of the pUSCHPowerControlAlphaFactor =0.7 in Throughput per RB.

11.1.2.1

PUSCHPOWERCONTROLALPHAFACTOR COMBINATION TESTS (LAB)

Our initial assumption was to demonstrate other parameter presents in the power control algorithm performance impact, besides pUSCHPowerControlAlphaFactor parameter. So far we have considered set of values for related test cases, they can be seen in the Table 11-2 Parameter

SET1

SET2

SET4

SET3

SET5

SET6

SET7

uplinkSIRtargetValueForDynamicPUSCHscheduling

15

15

15

15

15

15

15


1

1

1

1

1

1

1


0,8

0,8

0,8

0,8

0,8

0,8

0,8


0,7

0,7

0,7

0,7

0,7

0,7

0,7


0,6

0,6

0,6

0,6

0,6

0,6

0,6


0,5

0,5

0,5

0,5

0,5

0,5

0,5

p0NominalPUSCH

60

60

60

85

70

20

40

minSIRtargetForFractionalPowerCtrl

0

0

0

0

0

0

0

maxSIRtargetForFractionalPowerCtrl

15

20

19

20

19

19

19

Table 11-2: Different Set‟s Combinations We have considered a low IoT value=3dB in an UL&DL balanced cabled tests lab environment. We have used an automatic mechanism to increase the attenuation over the same amount of time for all the tests we have performed, 10MHz and 2.6GHz network. Based on Network Engineering for Optimization team‟s tests the below results were obtained:


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 60/194


MGR /TIPS /NEA

SET 1 CONFIGURATION ANALYSIS

Figure 11.1-4: Set 1 Result Based on the above results in Figure 11.1-4 we can conclude that having a non fractional power control mechanism will lead to best throughput (compared to FPC – ON cases) in near & mid cell. Starting path loss 110dB we have observed an UL throughput degradation which corresponds to number of PRB decrease, which explains the product reaction to UL TxPower saturation (number of PRB are decreased when the TxPower is maximum and the number of PRB-es is still high). Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 61/194


MGR /TIPS /NEA

Figure 11.1-5: Set 1UL Throughput & UE TX Power vs. Path loss NOTE: PL de-synch(~4dB) is due to the fact that in Figure 11.1-5 displays UL PL and Figure 11.1-8 displays DL PL. Please use the UL throughput curves to align the TxPower it effect. Comparing the plots above we can conclude that for pUSCHPowerControlAlphaFactor=0.7 number of PRB is not degraded, UE TxPower at near&edge cell environment has an acceptable value and also the uplink throughput still is satisfactory for most of the services an operator might offer.

Below in Figure 11.1-6 is the theoretical analysis for SIR target calculation in case of SET2&4. Results confirm the theory and the fact that having Max_SIR_targetForFPC greater than SIR_Target_Nominal will not help (if Path loss nominal is equal 60dB). There are no commercial networks in which the less than 60dB is found.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 62/194


MGR /TIPS /NEA

Figure 11.1-6: SIR Target for theoretical assumptions with different alpha factor values Looking to theoretical assumptions we have found that SET3 of values as something that could produce a similar UL throughput in Near cell environment compared to non-FPC case. As well as PL increases the UL throughput will smoothly decrease (around 93dB UL PL, compared to 110dB SET1&Alphafactor=1)

Figure 11.1-7: UL SIR Target for theoretical assumptions with different alpha factor values


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 63/194


MGR /TIPS /NEA

Figure 11.1-8: Different alpha factor comparison (Throughput, PRB‟s, SINR & PUSCH SINR Target) NOTE: Comparing the SIR target collected with SIR target estimated in the theoretical approach. This proves that Alcatel-Lucent power control mechanism works as expected. The below comparison shows the UL throughput and TxPower comparison between the AlphaFactor=1 and AlphaFactor=0.7 for SET3. Out of this we can conclude that a SET3(AlphaFactor=0.7) could be used when customers are requesting an high UL throughput in Near cell with a UL throughput decrease in late-mid cell and edge cell.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 64/194


MGR /TIPS /NEA

Figure 11.1-9: UL Throughput & UE TX Power vs. Path loss alpha factor 0.7 & 1 with set 3 Notes:

Alpha Factor=0.7 is a good compromise between UL Throughput and the TxPower used. Never the less, bigger the AlphaFactor, bigger the UL throughput for near&mid cells. Bigger the AlphaFactor, lower the UL throughput for edge cells (below ~110dB UL PL). Nominal path loss impacts the UL throughput performances. Bigger the value, later the UL throughput decrease effect, but high the TxPower. Having Max_SIR_targetForFPC greater than SIR_Target_Nominal will not help(if for e.g. Path loss nominal is equal 60dB, will not help to have max 20dB when target is 15dB). Path loss nominal with value less than 60dB is not useful. There are no commercial networks in which the less than 60dB is found. SET 1 &AlphaFactor=1 is the template. It is a good setting combination for non-FPC and best performances in Near&Mid-Cell radio condition. We recommend this to be used for best performances. SET1 & AlphaFactor=0.7 is a good trend between the UL throughput and UL interference. It is more suitable for commercials networks were customer vision needs a near&mid-cell not targeting the maximum or what Alcatel-Lucent product can offer to respect of lower interference. SET3 & AlphaFactor=0.7&PathLossNominal = 85 looks a better UL throughput approach having as well the FPC on. So high throughput in near&mid-cell radio conditions, but as well higher throughput in edge cell (compared to non-fractional power control). TxPower is a compromise between the SET1&AlphaFactor=1 and SET1&AlphaFactor=0.7.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 65/194


MGR /TIPS /NEA

Figure 11.1-10: UL Throughput & UE TX Power vs. Path loss for alpha factor 0.7 for all sets


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 66/194


MGR /TIPS /NEA

Figure 11.1-11: UL Throughput vs. Path loss for set1 & set3 with alpha factor 0.7 and 1

Figure 11.1-12: UE TX Power vs. Path loss for set1 & set3 with alpha factor 0.7 and 1

11.1.2.2

PUSCHPOWERCONTROLALPHAFACTOR COMBINATION TESTS (LIVE NETWORK)

In the frame of Verizon network specific scenarios were considered: Baseline configuration - Fixed UL SINR target and hence comparable average UL throughput across cell until UE begins to hit max Tx power o o

o

Throughput depends on choice of SINR target Higher SINR target allows high sector throughput, but cell edge users create significant interference to neighboring cells (IoT – Interference over Thermal) Choice of low SINR target is good for managing IoT, but sacrifices UL sector throughput

FPC (Fractional Power Control) is a 3GPP standards b ased algorithm o

o

Offers good balance between achieving high throughputs near the cell and mitigating IoT impact to neighboring cells from users at cell edge Cell adjusts UL SINR target for a given user based on estimated UL pathloss


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 67/194


o

o

MGR /TIPS /NEA

Fractional power compensation at the cell: High SINR target close to cell, and then linear adjustment beyond certain pathloss Fractional power compensation at the UE: Cell communicates pathloss component Alpha and Po_pusch_nominal via SIBx to manage PUSCH Tx power at the start of a call as well as throughout the call as pathloss changes

Figure 11.1-13: Fractional Power Control Slope vs. Sets The FPC parameters / test cases considered:

Table 11-3: Different Set‟s Combinations Used

Baseline - fixed 4 dB UL SIR target Sets 1 and 2 – alpha = 0.7; max SIR target = 15 dB, PLnom = 60 and 80 dB Starting values based on original simulation results o Sets 3 and 4 – alpha = 0.8; max SIR target = 19 dB, PLnom = 40 and 60 dB Determined based on updated antenna modeling and RF loading assumptions o While in the Temp Market the results were compiled from Drive tests, in the Boston Market they were base both in Drive test and simulation.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 68/194


MGR /TIPS /NEA

Boston Drive Test Results:

Comparing the median values, the normalized UL Throughput is around 60% -70% higher using set4 compared to the baseline configuration. Tempe Drive Test Results:

Comparing the results from all the sets, the median for the normalized UL throughput is around 40% higher for Set4 relative to Baseline. Main conclusions:

FPC gains demonstrated via drive tests 40-70% improvement in median normalized PUSCH throughput with Set4 relative to fixed and 4dB UL SIR target Actual gains in sector throughput will depend on a va riety of factors o Location of users (pathloss distribution) Interference (IoT) from UEs on neighboring cells / eNBs o Data demand on the UE from upper layers o

11.1.3 ULSCHEDPROPFAIRALPHAFACTOR ulSchedPropFairAlphaFactor: fairness factor of the UL scheduler ulSchedPropFairAlphaFactor = 1 yields a maximum C/I scheduler. The scheduler provides more resources to UEs in better conditions ulSchedPropFairAlphaFactor = 0.5 yields a fair scheduler. The scheduler attempts to provide equal share of RB utilization to all the UEs Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 69/194


MGR /TIPS /NEA

ulSchedPropFairAlphaFactor = 0.0 yields an increased fairness scheduler. The scheduler attempts to allocate the resources in such a way that all the UEs eventually get the same data rate

Default Value= "0.5" In the Figure 11.1-14 it is presented the impact of using the different values for 8.3 ULSCHEDPROPFAIRALPHAFACTOR; such as 0 or 1.

Figure 11.1-14: Impact of the ulSchedPropFairAlphaFactor The test represented in the Figure 11.1-14was made with the typical configuration; 2NC; 4MC; 2CE, and having the different UlschedpropfairAlphaFactor will make the scheduler to adjust more or less fair the resources to all the ue's... KPI Impact: Throughput – Low values increase the throughput in the near&mid-cell condition at expense of cell edge users. Capacity - Low values increase the cell overall throughput at expense of cell edge users.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 70/194


MGR /TIPS /NEA

12 LATENCY OPTIMIZATION HINTS In this chapter it will be highlighted the main focus of testing and the primary steps that will allow to optimize a specific domain and the most important /priority parameters; in this case the domain addressed is Latency in LTE. Normally some questions arise, such as: When to perform Latency optimization? What method to apply? Which parameters can help improving Latency? Mainly the Latency optimization can occur when the average value for a specific location is not matching the ALU product specification in terms of KPI. Before starting playing with the parameterization; usually is part of best practice rules for in Near Cell /Mid Cell & Cell Edge test to follow up simple steps as: Check the CQI Check the MCS triggered Check the UL BLER Evaluate RSSI vs. SNR relation Evaluate RSRP vs. RSRQ If we could guarantee that these values are “normal”, the chances t o have performance issues are much less difficult to occur. If regardless of the correct values, still facing some performance issues, they below parameters can be used in order to correct the situation. When changing parameters; you can adopt a more error-free approach, meaning that a parameter is changed at each time. If three or four parameters are changed same time… it could be difficult to understand which one is bringing the improvement in performance. As note; please remember that this can be a st atic test in each position, or can be a moving test… the same principles can be applied in both situations.

12.1 PARAMETERS OPTIMIZATION LATENCY Latency is generally considered either as control plane latency or as user plane latency. Control plane latency involves the network attachment operation while user plane latency only considers the latency of packets while UE is in connected state Attach Latency (IMSI and GUTI) Control Plane Latency (idle-to-active) Detach Latency HO Gap (to be discussed during HO) User Plane Latency (ping RTT) This chapter contains optimization guidelines for some parameters that have the highest impact on latency. LTE latency test cases include air latency and end-to-end latency as shown in Figure below. RAN / air latency in this document is defined in terms of the round trip time between UE and eNB. RAN / air latency is measured in loaded and unloaded conditions. Unloaded condition implies that a valid scheduling grant is available; i.e. no random access procedure needs to be performed. End to end latency is the elapsed round trip time from UE to a certain application server in the network. The EPC latency is the round trip time between UE and PDN GW. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 71/194


MGR /TIPS /NEA

Latency should be measured for UE with pre-scheduled and non-scheduled. The E2E latency is depending on the location of the application server for the test e.g. is it in internet world or is it a server co-located to the eUTRAN or possibly even a virtual server located inside the MME. Control Plane Latency The Idle to Active Transition Time is defined as the time required for the UE to transition from RRC idle state to RRC Active state. In particular this KPI is defined at the UE side as the latency (RTT) of the first ping sent by the UE to trigger the idle-to-active transition This is according to the 3GPP requirements stated: “Transition time (excluding downlink paging delay and NAS signalling delay) of less than 100 ms from a camped-state i.e. Idle Mode, to an active state, in such a way that the user plane is established” Additionally the latency between RA Preamble (followed by RRC Connection Request message NAS Service Request as shown in figure below) and RRC Connection Reconfiguration Complete message (Control Plane Latency) User plane latencies Ping is being used for discovering the User plane latency. Typically 32, 1000 and 1500 bytes payload sizes are set for the unloaded scenario, 32 and 1500 bytes for the loaded scenario Result will be the round trip delay between the eNodeB and the FTP server An estimation of the RTD between the eNodeB and the FTP server was performed by pinging the FTP.

12.1.1 TEST RECOMMENDATION AND RESULTS 12.1.1.1

ATTACH LATENCY

For a successful attach attempt to happen the needed the RACH preamble must be correctly decoded by eNB. Setting preambleInitialReceivedTargetPower >= -104dB will speed attach time but may result in interference to the other cells. Also making sure the following parameter preambleTransmitPowerStepSize= dB6 is important for reducing number of RACH preambles sent for RACH msg 1, and implicitly the attach time. The attach time latency is mainly dependent on the authentication procedure which has the highest proportion of total attach time. The IMSI attach time as an example is 600ms out of a total time of 677ms. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 72/194


MGR /TIPS /NEA

Figure 12.1-1: Example for IMSI attach procedure (with authentication)

Figure 12.1-2: Example for GUTI attach p rocedure (no authentication)

The examples are suggestive and clear that the RRC UE Capability procedure is time consuming. In conclusion attach time latency is mainly dependent on the authentication time.

12.1.1.2

ATTACH LATENCY RESULTS FOR LA4.0.1

The table below one can have an idea about the comparison between LA3.0.2 and LA4.0.1. The attach time is worse in LA4.0.1 but the table shows that the worsening on LA4.0.1 vs. LA3.0.2 is mainly in the ePC part. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 73/194


MGR /TIPS /NEA

Although, the target for this KPI on LE4 in the LTE KPI database is 290 ms. Test n°

LLDM attach request Cell Time(ms)

LLDM attach accept Cell time (ms)

S1 attach request

S1 attach accept

LLDM Attach Time attach request <-> attach accept (ms)

ePC part (ms)

ePC part (%)

UE + eNB part (ms)

1

9328

9626

902407

1053357

298

151

51%

147

2

2256

2567

567019

734066

311

167

54%

144

3

6694

6972

728394

867076

278

139

50%

139

4

6150

6442

667270

817352

292

150

51%

142

5

9748

10042

503028

657939

294

155

53%

139

6

1625

1912

310772

451515

287

141

49%

146

7

8654

8926

563518

702550

272

139

51%

133

8

1837

2111

715044

854582

274

140

51%

134

9

6141

6427

504086

645525

286

141

49%

145

10

1732

2007

574871

706418

275

132

48%

143

11

8652

8927

727487

867437

275

140

51%

135

Average (LA4.0.1)

286

145

51%

141

Previous LA3.0.2 results

230

97

42%

133

Table 12-1: Attach Latency for LA4.0.1

CONFIGURATION USED eNB sw is ENB_LA0400_D10_E02026 The database is customized: No mobility (isIntraFreqMobilityAllowed = false) No ciphering Measurements are done without authentication

REFERENCE OF ALL THE SOFTWARE USED IN THE PLATFORM Orvault lab SW versions HSS

R3.0 IAP1

PCRF-1

DSC_2_0-I133

PCRF-2

DSC_3_0_R1 (DSC_3_0_I377)

S-GW

R3.0_R1

P-GW

R3.0_R1

MME02

R21.80.12.07

MME03

R22.31.01

eNB40

ENB_LA0400_D10_E02026+ database MIM 10.6.3 ed03 + NEM.LA4.0.1_D1.9 + WPS_MIM_10.6.3_ed01

UE

G7-EH, sw MW8.2.Gp4 build G7_DEC09_REL

LLDM

R4.0.4

MME02

EPS Integrity Protection Algorithm

128-EIA0 (No Algorithm)


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 74/194


MME03

MGR /TIPS /NEA

EPS Encryption Algorithm

128-EEA0 (No ciphering)


128-EIA1 (SNOW 3G)



Table 12-2: SW Reference

12.1.1.3

LAST UPDATE REGARDING PERFORMANCE (ATTACH & ACTIVATION)

With G13 LGE device in very good RF (Near Cell) the average Attach time of 225ms and UE activation time of 90-92ms have been achieved.. With load: D11_E00041 The parameter “aUGtriggerDelayforRACHmsg4" has been optimized and is currently recommended to be set to 10 for optimal performance.

Quick reminder for aUGtriggerDelayforRACHmsg4:

The UL Scheduler may receive requests for Anticipated Uplink Grants (AUG) from the DL Scheduler. Note that in LA4.0, AUG is only used for connection setup scenarios (i.e. it is not used for bearer setup or during handover). AUG request transmission is triggered by the following events in the DL Scheduler: 1. Reception of an ACK for the transmission of a RACH message 4. The AUG request is processed by the UL scheduler with a configurable delay aUGtriggerDelayforRACHmsg4 in order to avoid sending an UL grant before the UE has finished processing the RRC Connection Setup message. Upon receipt of an AUG request triggered by the reception of an ACK for the transmission of a RACH message 4, the UL scheduler transitions the UE into “sync state”. 2. Detection of an ACK for the transmission of the last DL RLC PDU of a DL RRC message on SRB1 within a time window of duration configurable by parameter aUGprocessDuration starting at the trigger of the first AUG request for the UE context. Fixed bugs:

AUG Feature that was introduced in LE3.0 was broken in the beginning of LE4.0 and thanks to Lam‟s work with dev team it has been fixed now. Initially a new LE4.0.1 feature “Proce ssor-Overload Control” also impacted negatively this KPI and has been fixed from E00030 onwards.

12.1.1.4

IDLE TO ACTIVE LATENCY

The Idle to active latency is defined as the time needed for UE to enter active state. Starting point is the moment when UE initiates RACH Procedure with RACH message 1 for entering active mode until the UE sends RRC Connection Reconfiguration Complete message. For Idle to active the RACH procedure is included for this test. NOTE! The Idle to active transition is a process that needs less time than the normal attach procedure because the UE doesn‟t need to initiate the authentication procedure anymore. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 75/194


MGR /TIPS /NEA

If the RACH Preamble is not decoded by eNB then the UE will resend up to maximum preambleTransMax preambles before restarting RACH Procedure. The parameters: preambleInitialReceivedTargetPower, preambleTransmitPowerStepSize both should be set according to cell conditions for fast RACH procedure and hence a good Idle to active latency.

Figure 12.1-3: Idle to active message chart

The example listed below shows a total Idle to active latency of 153ms.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 76/194


MGR /TIPS /NEA

Figure 12.1-4: Example of total Idle to active latency

12.1.1.5

IDLE TO ACTIVE LATENCY RESULTS FOR LA4.0.1

The table below one can have an idea about the idle to active time latency. LLDM cell time test n°

Rrcconnectionrequest

rrcconnectionreconfigurationcomplete

Delta cell time

1

9983

10088

105

2

4668

4778

110

3

9128

9238

110

4

3669

3778

109

5

9110

9217

107

6

3210

3317

107

7

7971

8078

107

8

2707

2808

101

9

7804

7908

104

10

2661

2767

106

11

7190

7297

107

12

1316

1418

102

13

6030

6139

109

14

4207

4308

101

Average

106,07

Min

101,00

Max

110,00

Table 12-3: Idle to Active Latency


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 77/194


MGR /TIPS /NEA

REFERENCE OF ALL THE SOFTWARE USED IN THE PLATFORM Orvault lab SW versions HSS

R3.0 IAP1

PCRF-1

DSC_2_0-I133

PCRF-2

DSC_3_0_R1 (DSC_3_0_I377)

S-GW

R3.0_R1

P-GW

R3.0_R1

MME02

R21.80.12.07

MME03

R22.31.01

eNB40


UE


LLDM

R4.0.4

MME02 MME03


128-EIA0 (No Algorithm)




128-EIA1 (SNOW 3G)




12.1.1.6

DETACH LATENCY

When initializing a detach procedure the UE sends Detach Request after which eNB responds with Detach Accept. The detach latency is mainly clear context dependent and parties communication latencies. The Detach Latency should be around 200ms.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 78/194


MGR /TIPS /NEA

Figure 8.1 2: No RF parameter optimization possible for detach latency!

12.1.1.7

PING LATENCY RESULTS FOR LA4.0.1

In the table below, one can find the preliminary results for latency tests with a 32 Bytes ping. The Qualcomm UE has been tested with and without Extended SR grant for U-plane latency feature. Ping Latency 32 bytes

Extended SR grant for U-plane latency

prescheduled

unscheduled

Activated

17 ms

27 ms

Deactivated

---

35 ms

Qualcomm

Table 12-5: Ping Latency for 32 Bytes with and without Extended SR grant for U-plane latency

QUICK NOTES ABOUT THE TESTING Prescheduled mode = disabled Extended SR grant for U-plane latency is activated by default in L4.0 (maxExtendedSRGrantSize = 100). maxExtendedSRGrantSize: This parameter controls the maximum grant size that can be issued by the uplink scheduler when responding to a SR.

CONFIGURATION USED UE version is M9600B-SCAQWAFD-3.0.361109 eNB version is LA4.0 ENB_LA0400_D10_E02070 MIM 10.6.4 delivery 11W32


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 79/194


MGR /TIPS /NEA

13 CAPACITY OPTIMIZATION HINTS In this chapter it will be highlighted the main focus of testing and the primary steps that will allow to optimize a specific domain and the most important /priority parameters; in this case the domain addressed is Capacity in LTE. Normally some questions arise, such as: When to perform Capacity optimization? What method to apply? Equipments and tools to use? Which parameters can help improving Capacity? By default, there is not much chance to make an improvement of the connected users… normally what can be worked is split of the performance (resource block allocation), for users in different radio conditions. This means that we can have fair or unfair resource distribution; for more details you can check the parameters described below.

13.1 PARAMETERS OPTIMIZATION FOR IMPROVING CAPACITY ENB capacity is depending on the configuration request. Depending on the request exist number specific features to configure the eNB, thus are driven by parameters configurations settings.

13.1.1 ENB CAPACITY CONFIGURATIONS Features and configuration elements impacting the eNB capacity figures are: UL/DL Bandwidth configured through parameters dlBandwidth and ulBandwidth. Different capacity figures are available depending on the LTE bandwidth used.

Parameter maxNbrOfUsers controls the number of users that can be admitted in a cell (users per modem). Parameter maxNumberOfCallPerEnodeB controls the number of users that can be admitted on the eNB (users per Controller board) The usage of 700 MHz Upper C ul700MHzUpperCBlockEnabled activation flag.

band

(US

specific)

controlled

through

The following table is summarizing the different eNB capacity figures that can be obtained for du/ul Bandwidth parameters. dl/ul Bandwidth n25-5MHz n50-10MHz n100-20MHz

Capacity in terms of max. number of users per cell 167 (at the publication date) DR5 target: 167 (current view) 167 (at the publication date) DR5 target: 167 (current view) 167(at the publication date) DR5 target: 167 (current view)

Capacity in terms of max. number of users per eNB 500 (at the publication date) DR5 target: 500 (current view) 500 (at the publication date) DR5 target: 500 (current view) 500 (at the publication date) DR5 target: 500 (current view)

Table 13-1: LA4.0.1 Capacity figures


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 80/194


MGR /TIPS /NEA

13.1.2 ALPHAFAIRNESSFACTOR Parameter alphaFairnessFactor tunes the alpha fairness factor (thus the behaviour) of the DL scheduler. The scheduler is the processing entity that allocates resources to user plane and control plane traffic. Different factors such as channel quality, data pending in buffers, relative priorities in terms of QoS traffic are some key factors that are used by the scheduler to pick specific users from the active pool and allocate air-link resources to them. The overall goal is to ensure that users do get a chance to share the available bandwidth in the system, and the resources are allocated in an efficient manner while maintaining good system utilization. Default Value= "1"

Expected behaviour when changing this parameter alphaFairnessFactor = 0 Aggressive mode (α = 0) the scheduler provides more resources to UEs in better conditions. The better the radio conditions of the UE, the more resources (and hence the higher the data rate) it gets.

Using the follow results in 10MHz with 20UE‟s when apply the aggressive mode you sh ould expect: UE in Cell Edge are allocated the less PRB in ave rage to favour UE with better radio conditions Average UE Throughput per radio group => differences increased compared to proportional Fair mode alphaFairnessFactor = 1 Proportional Fairness (α = 1), the scheduler attempts to provide the same number of RBs to all the UEs (despite their different conditions).

Using the follow results in 10MHz when apply the conservative mode you should expect: Average fairness maintained despite different radio conditions alphaFairnessFactor = 2 Conservative mode (α = 2) shows the more Ue move away, the more PRB they are allocated, decreasing gaps between Ue Throughput but decreasing the cell Throughput as well. The scheduler attempts to allocate the resources in such a way that all the UEs eventually get the same data rate (which is not the case of the fair scheduler since different radio conditions result in different data rates even when the number of resources is the same, hence the increased fairness of the scheduler, as compared to the “regular” fair scheduler).

Using the follow results in 10MHz when apply the conservative mode you should expect: When the UE‟s is in bad radio conditions, more PRB are allocated in average to decrease throughput gaps Average UE DL throughput per radio group (Good, Medium, Bad radio conditions), decrease compared to proportionalfair mode In overall the final 20 UE throughput decrease compared with proportionalfair mode alphaFairnessFactor conclusions: Conservative mode (α = 2), shows the more UE move away, the more PRB they are allocated, decreasing gaps between UE Throughput but decreasing the cell Throughput as well. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 81/194


MGR /TIPS /NEA

Aggressive mode (α = 0), shows the more UE come closer, the more PRB they are allocated, increasing gaps between UE Throughput but also the cell Throughput. Proportional Fair mode (α = 1), shows the better fairness distribution between the different radio conditions. All UE‟s will have the same resources even in bad radio conditions, appropriate for commercial networks.

KPI Impact: Throughput – Low values increase the throughput in the near&mid-cell condition at expense of cell edge users. Capacity - Low values increase the cell overall throughput at expense of cell edge users.

13.1.3 ULSCHEDPROPFAIRALPHAFACTOR Parameter ulSchedPropFairAlphaFactor tunes the alpha fairness factor (thus the behaviour) of the UL Scheduler. Default Value= "0.5"

Expected behaviour when changing this parameter ulSchedPropFairAlphaFactor = 1

Aggressive mode (α = 1), Yields a maximum C/I scheduler. The scheduler provides more resources to UEs in better conditions. The better the radio conditions of the UE, the more resources (and hence the higher the data rate) it gets.

Using the follow results in 10MHz when apply the aggressive mode you should expect: ULS choice only depends on spectrum efficiency => unpredictable fairness behaviour TCP flow control increases BO of favoured Ues and decrease BO of others ulSchedPropFairAlphaFactor = 0.5

Proportional Fair (α = 0.5) , Yields a fair scheduler. The scheduler attempts to provide the same number of RBs to all the UEs (despite their different conditions).

Using the follow results in 10MHz when apply the aggressive mode you should expect: 70,6 % PRB BW used in UL => decreased in degraded radio when Ue reach maximum path loss (PH limitation) fairness no more significant between Cell edge group and the others since Ue at maximum path loss BLER with Sol3 issue on Ue in Mid Cell only when mixed with UE in Near Cell (CR 312408) UL BLER in Cell Edge converge to almost 10% ulSchedPropFairAlphaFactor = 0

Conservative mode (α = 0), yields an increased fairness scheduler. The scheduler attempts to allocate the resources in such a way that all the UEs eventually get the same data rate (which is not the case of the fair scheduler since different radio conditions result in different data rates even when the number of resources is the same, hence the increased fairness of the scheduler, as compared to the “regular” fair s cheduler). Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 82/194


MGR /TIPS /NEA

Using the follow results in 10MHz when apply the aggressive mode you should expect: Average Ue Throughput per radio group => differences decreased compared to proportional Fair mode Cell Throughput decreased compared to proportional Fair mode The more UE are in bad radio, the more PRB they are allocated in average to decrease Throughput gaps. ulSchedPropFairAlphaFactor conclusions: Conservative mode (α = 0), does not show any improvement compared to proportionalfair results, as shown in simulations results as well. Proportionalfair mode (α = 0.5), fairness no more significant between Cell edge and the other radio conditions, since UE is at maximum path loss. More PRB bandwidth used in this configuration compared with the other. Better configuration for commercial networks. Aggressive mode (α = 1), is not a significant test since throughput between users are not predictable. This mode is not recommended for customer deployment.

KPI Impact: Throughput: high values increase the throughput for near cell and mid-cell conditions. Capacity - high values allow reaching the capacity for a wider range of propagation conditions.

14 LTE –LTE MOBILITY OPTIMIZATION HINTS In this chapter it will be highlighted the main focus of testing and the primary steps that will allow to optimize a specific domain and the most important /priority parameters; in this case the domain addressed is Mobility in LTE. Normally some questions arise, such as: When to perform Mobility optimization? What method to apply? Which parameters can help improving Mobility? Mainly the Mobility optimization can occur when the average success rate or average interruption time value is not matching the ALU product specification for a determined Bandwidth target. Before starting playing with the parameterization; usually is part of best practice rules cell Edge test to follow up simple steps as: Check the if Neighbours existing Check the all supposed cells /sites are on-air Check that all supposed neighbour relations are declared Evaluate RSSI vs. SNR relation, to see if it is matching expectations based on coverage map. If we could guarantee that these values are “normal”, the chances to have performance issues are much less difficult to occur. If regardless of the correct values, still facing some performance issues, they below parameters can be used in order to correct the situation. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 83/194


MGR /TIPS /NEA

When changing parameters; you can adopt a more error-free approach, meaning that a parameter is changed at each time. If three or four parameters are changed same time… it could be difficult to understand which one is bringing the improvement in performance.

14.1 LTE-LTE MOBILITY Before we start with Mobility parameter optimization, is necessary to follow some steps to optimize the mobility:

14.1.1 CHECK INTRA NEIGHOUR LIST AT DATA BASE NETWORK In the beginning when network is deployed, inside CIQ is necessary to fulfil the information relative to the Intra Neighbouring cell‟s of each sector. After network deployment a first check in the neighbour list should be done, to ensure the intra HO neighbour‟s are created. Example bellow in Figure 14.1-1 shows the sector PU1084L2100_0 have Intra neighbour with sector PU1084L2100_1 and PU1084L2100_2

Figure 14.1-1: Intra HO Neighbour list

14.1.2 INTER FREQUENCY NEIGHBOUR DECLARATION One of the ways to declare the best neighbour relation is working with the information done by ARFCC team previously. With Cell ID coverage we can check the cel l ID‟s neighbour‟s for each sector as showing bellow. After should be done drive test and post processing the measurements to confirm the neighbour list and the HO success rate between sites.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 84/194


MGR /TIPS /NEA

Figure 14.1-2: Coverage analysis AMX trial – done by ARFCC team Other possible way to perform the neighbour list is run ANR feature in the network. The f eature will create the X2 links that would be need for each sector. Maximum of 32 X2 visible links could be created. Be aware the feature should be activated after the first neighbour optimization performed and after the users start to perform data traffic.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 85/194


MGR /TIPS /NEA

Figure 14.1-3: X2-Link creation by ANR Here the X2-Link is created but the name of the neighbour comes in Binary. For the case above site NE0054 create X2 link with site NE0034, but in the Wips appear X2Access/0_330_110_NE0054_11.

14.1.3 HOW TO AVOID PING PONG EFECT IN NETWORK To avoid ping pong effect between different cells ID‟s as show in the Figure 14.1-4, a balance between the following parameters should be done: filterCoefficientRSRP - The higher the value of filterCoefficientRSRP the smoother the reported measurement will be and consequently the less likely ping-ponging occurs between sectors during handover Hysteresis - Increasing the value of this parameter would delay the HO due to the more important difference that must exist between the serving cell and neighbour cell. CellIdividualoffset – Low values decrease the number of ping pongs between the 2 cells and delay the HO.

These three parameters if setup correctly will help to avoid ping pong effect and improve throughput, during HO attempts.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 86/194


MGR /TIPS /NEA

HO Ping Pong area. Cell ID 9 and 10

Figure 14.1-4: HO ping pong area

14.1.4 MOBILITY PARAMETERS Some parameters are the base to optimize the mobility. In some of then we are able to change and get better results, for example in terms of performance (HO Success Rate). Note for different networks and environments the recommended values could not be the best to apply. Always run a first drive and after with recommended parameters try to setup the best for your network. Object

Name

Recommended Value


qRxLevMin

-120


qRxlevminoffset

8


threshXLow

0


qHyst

dB2

RrcMeasurementConf


Fc8

ReportConfigEUTRA

Hysteresis

2

ReportConfigEUTRA

timeToTrigger

ms40


cellIndividualOffset

dB0

Table 14-1: Mobility parameters


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 87/194


MGR /TIPS /NEA

14.1.5 INTRA-FREQUENCY (IDLE MODE ) Cell Reselection is a procedure triggered by the UE in Idle Mode to determine which LTE cell to camp on. The trigger can be internal (e.g. periodic trigger to ensure that UE is still on the best cell) or external (e.g. upon change of Cell Reselection parameters broadcast on the selected cel l‟s BCH). The cell selection and reselection is controlled by the System Information parameters provided in SIB1, SIB3 and SIB4. Cell Reselection is a procedure triggered by UEs in Idle Mode to determine which LTE cell to camp on. When a UE, camps on a cell it monitors its broadcast and paging channels. The procedure is internal to the UE and there is therefore no EUTRA level use case for it. 3GPP rules: SservingCell > 0 where SservingCell = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset) - Pcompensation Let„s consider: IF SServingCell > Sintrasearch -> UE choose to not perform intra-frequency measurements If SServingCell ≤ Sintrasearch -> UE shall perform intra-frequency measurements ... Now using parameters... IF Qrxlevmeas > Qrxlevmin + Qrxlevminoffset + Sintrasearch -> UE does not measures IF Qrxlevmeas ≤ Qrxlevmin + Qrxlevminoffset + Sintrasearch -> UE measures As soon as possible neighbours are measured, the UE should rank them using: RSRPs + qHyst < RSRPn – qOffsetCell RSRPs = RSRP for serving cell RSRPn = RSRP for target cell UE will reselect the new first cell on the ranked list if both below conditions are met: The new cell is better ranked than the serving-cell during a time interval tReselectionEUTRAN More than 1 second(s) has elapsed since the UE camped on the current serving-cell Measurement phase

RSRP > Qrxlevmin + Qrxlevminoffset + Sintrasearch ≤ Qrxlevmin + Qrxlevminoffset + Sintrasearch Measurement phase

Figure 14.1-5: LTE to LTE Mobility – Measurement phase (RSRP vs. Time)


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 88/194


MGR /TIPS /NEA

Ranking phase RSRP

RSRP(n)-qOffset

Ranked list

qHyst

3

Rs

-100

QoffSet

3

Rn1

-95

-98

Rn2

-94

-97

1

Rn3

-93

-96

2

Rn4

-92

-95

neighbour-decision

3

Rn3 Rn4

Figure 14.1-6: LTE to LTE Mobility – Ranking Phase

Decision phase

RSRPn2

RSRPs

QoffSet qHyst

Rn2 reselection

tReselectionEUTRAN Figure 14.1-7: LTE to LTE Mobility – Decision Phase (RSRP vs. Time)

14.1.5.1

QRXLEVMIN

Clarifications regarding qRxLevMin: A parameter with this name appear in several objects and is then transmitted to UE inside several system information block types i.e. Sibs: CellSelectionReselectionConf – transmitted in SIB1 and SIB3 CellReselectionConfUtraFdd – transmitted in SIB6 CellReselectionConfUtraTdd – transmitted in SIB6 CellReselectionConfGERAN – transmitted in SIB7 The LTE – GERAN mobility is using two of them, the one sent in SIB3 and the one sent in SIB7. The IE SystemInformationBlockType3 contains cell re-selection information common for intrafrequency, inter-frequency and/or inter-RAT cell re-selection (i.e. applicable for more than one type of cell re-selection but not necessarily all) as well as intra-frequency cell re-selection information other than neighbouring cell related. This parameter configures the cell min required RSRP level used by the UE in cell reselection. Recommended Value= "-120"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection sooner and then will artificially decrease cell size in idle mode. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 89/194


MGR /TIPS /NEA

Decreasing the value of this parameter would: Determine the UE to start cell reselection later and then will artificially increase cell size in idle mode. KPI Impact: Mobility - low values might create coverage discontinuity in idle, as seen by UE. The optimization process should contain the following steps: Step 1: Set the value of qRxLevMin to one of the following values {- 124, -122, -120, -118, -116}. Step 2: With UE in idle mode, perform a drive test back and forth on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qRxLevMin and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the target cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.5.2

SINTRASEARCH

This parameter specifies the threshold for the serving cell reception level, below which the UE triggers intra-frequency measurements for cell reselection.


Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine an early start of measurement for cell reselection. Decreasing the value of this parameter would: Determine a late start of measurement for cell reselection. KPI Impact: Mobility - low values delay the start of measurements performed by the UE which can be reflected in delayed reselection. The optimization process: test results indicate sIntraSearch should be set to the highest allowed value to minimize SINR degradation in reselection boundaries. Although as an experiment process; values such as 30 or 40 for the sIntraSearch might be used.

14.1.5.3

QHYST

This parameter configures the hysteresis value of the serving cell used by the UE for ranking criteria in cell reselection. Broadcast in SystemInformationBlockType3. Recommended Value= "dB2"

Expected behaviour when changing this parameter Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 90/194


MGR /TIPS /NEA

Increasing the value of this parameter would: Determine a later reselection of the target neighbouring cell (smaller the target cell list). Decreasing the value of this parameter would: Determine an earlier reselection of the target neighbouring cell (larger the target cell list). KPI Impact: Mobility - can improve mobility by determining timely reselection. The optimization process should contain the following steps: Step 1: Set the value of qHyst to one of the following values {dB1 , dB2, dB3, dB4, dB5}. Step 2: With UE in idle mode, perform a drive test back and forth on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qHyst and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the target cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.5.4

QOFFSETCELL

This parameter defines the offset between t he current LteCell and the LteNeighboringCell. Recommended Value= "dB0"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a later reselection of the target neighbouring cell (larger target cell list). Decreasing the value of this parameter would: Determine an earlier reselection of the target neighbouring cell (smaller target cell list).

KPI Impact: Mobility - higher the value later the cell reselection. Lower the value, earlier the cell reselection.

The optimization process should contain the following steps: Step 1: Set the value of qOffsetCell to one of the following values {dB1, dB2, dB3, dB4, dB5, dB6, dB7}. Step 2: With UE in idle mode, perform a drive test back and forth on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qOffsetCell and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the target cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 91/194


14.1.5.5

MGR /TIPS /NEA

QRXLEVMINOFFSET

This parameter defines an offset to be applied in cell selection criteria by the UE when it is engaged in a periodic search for a higher priority PLMN . Recommended Value= "8"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine an earlier reselection of the target neighbouring cell. Decreasing the value of this parameter would: Determine a later reselection of the target neighbouring cell. KPI Impact: Mobility - low values might create coverage discontinuity during selection operation due to shrinking target cell as seen by the UE. Note: If you do not use inter-PLMN mobility, this parameter is inhibited

14.1.5.6

TRESELECTIONEUTRAN

This parameter specifies the value of the cell reselection UE timer in the serving cell. Broadcast in SystemInformationBlockType3. It imposes a condition on the reselection. UE will actually reselect the new cell, only if the new cell is better ranked than the serving cell during a time interval tReselectionEUTRAN .


Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a delayed reselection which could be an issue for fast moving UEs. Decreasing the value of this parameter would: Facilitate ping-pong behaviour during reselection process. KPI Impact: Mobility - low values of this parameter might allow ping-pong behaviour during reselection operation. High values of this parameter might delay the reselection and possible lead to lost connection to the serving cell. Optimization of this parameter should find a trade-off between delayed reselection and ping pong behaviour. Most probably, if the UEs are not moving fast, the delayed reselection would not be an issue. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionEUTRAN to one of the following values {1, 2, 3, and 4}. Step 2: With the UE in idle mode, perform a drive back and forth between the cells on various routes and log the reselection - related messages and the position of the UE. Perform this test 10


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 92/194


MGR /TIPS /NEA

times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionEUTRAN. Step 4: Post-process the logs and analyze them as reselection position vs. tReselectionEUTRAN values and ping pong behaviour vs. tReselectionEUTRAN values and choose the optimized value to obtain smallest interruption time and highest success rate. Step 5: Calculate the HO success rate in each direction.

14.1.5.7

TRESELECTIONEUTRASFMEDIUM

This parameter configures the t-ReselectionEUTRA-SF included in the IE SystemInformationBlockType3. Parameter “Speed dependent ScalingFactor for tReselectionEUTRAN ” (TS 36.304). If the field is not present, the UE behaviour is specified in TS 36.304. The concerned mobility control related parameter is multiplied with this factor if the UE is in Medium Mobility state as defined in TS 36.304. This parameter avoids ping pong radio phenomena during the RA-Update & idle mobility.

Recommended Value= "oDot25"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier.

KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter will determine the UE to start reselection later.

For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionEutraSfMedium to one of the following values {0.25, 0.5, 0.75, and 1}. Step 2: With the UE in idle mode, perform a drive back and forth between the cells on various routes and log the reselection - related messages and the position of the UE. Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionEutraSfMedium. Step 4: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.5.8

TRESELECTIONEUTRASFHIGH

This parameter configures the t-ReselectionEUTRA-SF included in the IE SystemInformationBlockType3. Parameter “Speed dependent ScalingFactor for tReselectionEUTRAN ” (TS 36.304). If the field is not present, the UE behaviour is specified in TS 36.304. The concerned mobility control related parameter is multiplied with this factor if the UE is in High Mobility state as defined in TS 36.304. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 93/194


MGR /TIPS /NEA

This parameter avoids ping pong radio phenomena during the RA-Update & idle mobility. Recommended Value= "oDot25" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier.


For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionEutraSfHigh to one of the following values {0.25, 0.5, 0.75, and 1}. Step 2: With the UE in idle mode, perform a drive back and forth between the cells on various routes and log the reselection - related messages and the position of the UE. Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionEutraSfHigh. Step 4: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.5.9

TEVALUATION

This parameter configures the duration for evaluating criteria to enter mobility states

Recommended Value & Daefault = "s30"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE spend more time evaluating the criteria to enter mobility state; meaning a handover delay. Decreasing the value of this parameter would: Determine the UE spend more time evaluating the criteria to enter mobility state; meaning a handover speed up (to be noted that the smaller value allowed is already in used s30 ). KPI Impact: Mobility - low values of this parameter will determine the UE to spend less time evaluating criteria for enter mobilityr. This results in a speed up of the handover process. Higher values of this parameter will determine the UE to spend more time evaluating criteria for enter mobilityr. This results in a delay of the handover process A procedure that optimizes tEvaluation would contain the following steps: Step 1: Set the value of tEvaluation to one of the following values {s30, s60, s120, s180, and s240}. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 94/194


MGR /TIPS /NEA

Step 2: Perform a drive test back and forth on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another tEvaluation and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.5.10 NCELLCHANGEHIGH This parameter configures the number of cell changes to enter high mobility state

Recommended Value= "12" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier.


A procedure that optimizes nCellChangeHigh would contain the following steps: Step 1: Set the value of nCellChangeHigh to one of the following values {10, 11, 12, 13, and 14}. Step 2: Perform a drive test back and forth on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another nCellChangeHigh and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.5.11 NCELLCHANGEMEDIUM This parameter configures the number of cell changes to enter medium mobility state Recommended Value= "4" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility – low values of this parameter might allow the UE to start cell reselection earlier. High values of this parameter might allow the UE to start cell reselection later.

A procedure that optimizes nCellChangeMedium would contain the following steps: Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 95/194


MGR /TIPS /NEA

Step 1: Set the value of nCellChangeMedium to one of the following values {1, 2, 3, 4, 5, and 6}. Step 2: Perform a drive test back and forth on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another nCellChangeMedium and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.5.12 QHYSTSFHIGH This parameter contributes to the configuration of the IE SystemInformationBlockType3.This parameter configures the IE sf-High included in the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for Qhyst” in TS 36.304. The sf -High concerns the additional hysteresis to be applied, in High Mobility state, to Qhyst as defined in TS 36.304 state. This parameter is an environment dependent parameter. This parameter configures the hysteresis value of the serving cell used by the UE for ranking criteria in cell reselection. Recommended Value= "dB-6" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility – low values of this parameter might allow the UE to start cell reselection earlier. High values of this parameter might allow the UE to start cell reselection later.

A procedure that optimizes qHystSfHigh would contain the following steps: Step 1: Set the value of qHystSfHigh to one of the following values {dB-6, dB-4, dB-2, dB0}. Step 2: With the UE in idle mode, perform a drive test back and forth on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qHystSfHigh and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.5.13 QHYSTSFMEDIUM This parameter contributes to the configuration of the IE SystemInformationBlockType3.This parameter configures the IE sf-Medium included in the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for Qhyst” in TS 36.304. The sf -High concerns the additional hysteresis to be applied, in Medium Mobility state, to Qhyst as defined in TS 36.304 state. This parameter is an environment dependent parameter. This parameter configures the hysteresis value of the serving cell used by the UE for ranking criteria in cell reselection. Recommended Value= "dB-6" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 96/194


MGR /TIPS /NEA

Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility – low values of this parameter might allow the UE to start cell reselection earlier. High values of this parameter might allow the UE to start cell reselection later. A procedure that optimizes qHystSfMedium would contain the following steps: Step 1: Set the value of qHystSfMedium to one of the following values {dB-6, dB-4, dB-2, dB0}. Step 2: With the UE in idle mode, perform a drive test back and forth on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qHystSfMedium and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.6 INTRA-FREQUENCY ( ACTIVE MODE )

Figure 14.1-8: LTE to LTE Mobility – Handover cases Event A3 – Neighbour becomes offset better than serving Entering condition for this event:

Mn = measurement result of the neighbouring cell [dBm] Ofn = MeasObjectEUTRA::offsetFreq, corresponding to the neighbouring cell [dB] Ocn = cellIndividualOffset for neighbouring cell [dB] Hys = reportConfigEUTRA::hysteresis [dB] Ms = measurement result of the serving cell [dBm] Ofs = MeasObjectEUTRA::offsetFreq, corresponding to the serving cell [dB] Ocs = cellIndividualOffset for serving cell [dB] Off = eventA3Offset [dB]

Leaving condition for this event: Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 97/194


14.1.6.1

MGR /TIPS /NEA

FILTERCOEFFICIENTRSRP

This parameter configures the RRC IE filterCoefficientRSRP included in the IE quantityConfigEUTRA in the MeasurementConfiguration IE. If this parameter is not configured (absent) then the default RRC value defined in 36.331 is used by the eNB and signalled to the UE. The RSRP values reported by the UE are obtained by filtering several measurements performed by the UE. If this filter can allow quick v ariation to be reported or it can rely more on the last reported value and less on the measured value such that there is less variation in the sequence of the reported value. The higher the value of filterCoefficientRSRP the smoother the reported measurement will be and consequently the less likely ping-ponging occurs between sectors during handover.

Figure 14.1-9: Theoretical view -70 1

106

211 316 421 526

631 736 841 946 1051 1156 1261 1366 1471 1576 1681 1786 1891

-80

-90 RSRP_instant -100

RSRP_FC(K=4) RSRP_FC(K=11)

-110

-120

-130

Figure 14.1-10: filterCoefficientRSRP - Theoretical comparison (Simulation Analysis)

Recommended Value= "fc8" Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 98/194


MGR /TIPS /NEA

Expected behaviour when changing this parameter: Increasing the value of this parameter would: Decrease the variation in the reported RSRP value. Decrease ping-pong between the cells in case of handover conditions. Delay the speed at which the reported RSRP adapts to the RSRP variation. This might eventually slightly delay the HO, if the value of the parameter is too high. Improve the system behaviour regarding the throughput during HO. Decreasing the value of this parameter would: Increase the variation in the reported RSRP value due to noise. Increase the ping-pong between the cells in case of handover conditions due to variations in reported RSRP. Decrease the HO quality relative to throughput. Increase the speed at which the reported RSRP adapts to the RSRP variation. This might speed up the HO which could manifest as ping-pong. KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during HO operation. High values of this parameter might delay the HO and possible lead to lost connection to the serving cell. Optimization of this parameter should be performed in conjunction with optimization of hysteresis and timeToTrigger parameters. Finding the optimum pair of ( filterCoefficientRSRP, hysteresis, and timeToTrigger ) should consider the following steps: Step 1: Set the values of filterCoefficientRSRP and to hysteresis and to timeToTrigger to one of the following {(fc6,2,80), (fc8,3,40), (fc8,4,20), (fc5,1,100)}, in both current cell and neighbour cell. It was proven that the time to trigger below 100 ms have the same impact on performance as LGE UE measures RSRP every 100ms. Step 2: Perform a drive test while performing a download and log the throughput values and the position of the UE. Drive in and out of the current cell to the neighbour cell. Step 3: Repeat Step 2 for another pair of values of the three tested parameters. Step 4: Represent throughput vs. position (distance) (Service continuity), #HO-attempts, Success Rate/Failure Rate, #of Ping-pongs, HO interruption time for all pairs of tested values. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.6.2

HYSTERESIS

This parameter configures the RRC IE hysteresis included in the IE reportConfigEUTRA in the MeasurementConfiguration IE. This parameter defines the hysteresis used by the UE to trigger an intra-frequency event-triggered measurement report. It is used in several processes: Event A1 (Serving becomes better than threshold); Event A2 (Serving becomes worse than threshold); Event A3 (Neighbour becomes offset better than serving); Event A4 (Neighbour becomes better than threshold); Event A5 (Serving becomes worse than threshold1 and neighbour becomes better than threshold2. Recommended Value= "2"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Delay the HO due to the more important difference that must exist between the serving cell and neighbour cell. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 99/194


MGR /TIPS /NEA

Drop the call if the value is too large i.e. connection to the serving cell is lost before having reached the neighbour cell level that satisfies the HO condition. Decreasing the value of this parameter would: Create a ping – pong behaviour because the measurement quick variations (noise-like) might trigger HO decisions. KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during HO operation. High values of this parameter might delay the HO and possible lead to lost connection to the serving cell. Throughput - low values of this parameter can generate a ping pong behaviour which can result in interruption times and low throughput during HO operation. Optimization of this parameter should be performed in conjunction with optimization of filterCoefficientRSRP and timeToTrigger parameters, as presented in the previous paragraph.

14.1.6.3

TIMETOTRIGGER

This parameter sets the time duration time during which the conditions to trigger an event report have to be satisfied before sending a RRC measurement report in event triggered mode. Recommended Value= "ms40"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Delay the HO decision. Determine a call drop due to significant serving cell signal degradation before timeToTrigger expires. Decreasing the value of this parameter would: Generate ping-pong HO behaviour due to the fact that quick variations of the measured signal (noise-like variations) might satisfy the HO relation for the short while represented by timeToTrigger but not much longer.

KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during HO operation. High values of this parameter might delay the HO and possible lead to lost connection to the serving cell.

This parameter should be carefully optimized, best in conjunction with filterCoefficientRSRP and hysteresis as presented in paragraph 12.1.1.2.1 . Indeed, the optimized value can be impacted by the load of the surrounding cells. Note: LGE UE RSRP filtering is every 100ms, which means that any time-to-trigger value equal or above 100ms is indeed significant. The only reason to have ms40 is to be sure that we will take the first RSRP reporting into consideration in case it is before the 100ms.

14.1.6.4

CELLINDIVIDUALOFFSET

This parameter defines the cell individual offset between the current LteCell and the neighbour cell provided to the UE in RRC Connected mode for measurement . Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 100/194


MGR /TIPS /NEA

Recommended Value= "dB0" Expected behaviour when changing this parameter Increasing the value of this parameter would: Increase the number of ping pongs between the 2 cells and speed up the HO . Decreasing the value of this parameter would: Decrease the number of ping pongs between the 2 cells and delay the HO.

KPI Impact: Mobility – low values of this parameter will delay the HO, and high values will generate ping pong behaviour.

The following steps could be used if you plan to optimize this parameter: Step 1: If you detect a consist dropping from a specific cell, you can think to tune the cellIndividualOffset in steps of dB2 units. Step 2: Perform a drive test in and out of the cell and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of cellIndividualOffset. Step 4: Post process the measurement and analyze them as HO success rate vs. cellIndividualOffset values and ping pong behaviour vs. cellIndividualOffset values and choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.6.5

EVENTA3OFFSET

This parameter is used to indicate an event (A3) specific offset of the serving frequency to be applied when evaluating triggering conditions for measurement reporting. Recommended Value= "0" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to handover to the target cell later Decreasing the value of this parameter would: Determine the UE to handover to the target cell earlier. KPI Impact: Mobility – low values of this parameter might allow the UE to handover earlier; while high values might delay the handover

The following steps could be used if you plan to optimize this parameter:


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 101/194


MGR /TIPS /NEA

Step 1: Set the values of eventA3offset to one of the following values {-3,-2,-1, 0, 1, 2, 3}. Step 2: Perform a drive test in and out of the cell and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of eventA3Offset Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.6.6

OFFSETFREQ

This parameter is used to indicate a frequency specific offset to be applied when evaluating triggering conditions for measurement reporting. Recommended Value= "dB0" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to find the target cell earlier, which is similar with a shrinking of the serving cell. Decreasing the value of this parameter would: Determine the UE to find the target cell later, which is similar with a shrinking of the target cell. KPI Impact: Mobility – low values of this parameter might allow the UE to determine the strongest cell later. High values of this parameter might allow the UE to determine the strongest cell earlier.

The following steps could be used if you plan to optimize this parameter: Step 1: Set the values of offsetFreq to one of the following values {-3,-2,-1, 0, 1, 2, 3}. Step 2: Perform a drive test in and out of the cell and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of offsetFreq. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.6.7

REPORTINTERVAL

This parameter configures the RRC IE reportInterval included in the IE reportConfigEUTRA in the MeasurementConfiguration IE. The ReportInterval indicates the interval between periodical reports. The ReportInterval is applicable if the UE performs periodical reporting (i.e. when reportAmount exceeds 1), for triggerType „event‟ as well as for triggerType „periodical‟. Recommended Value= "ms240" Expected behaviour when changing this parameter Increasing or decreasing the value of this parameter would: Will not decrease or increase the Handover Success rate; but no point to have high values.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 102/194


MGR /TIPS /NEA

KPI Impact: Mobility – No specific issues using higher or lower values; a compromise needs to be found. A procedure that optimizes reportInterval would contain the following steps: Step 1: Set the value of reportInterval to one of the following values {120, 240, 480, 640, 1024, and 2048}. Step 2: Perform a drive test in and out of the cell and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of reportInterval. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.6.8

MAXREPORTCELLS

This parameter defines the maximum number of cells to be reported in a measurement report. Recommended Value= "3"; if ANR active it should be set to "8"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to report as many new neighbour cells as possible in a short time. Decreasing the value of this parameter would: Determine the UE to report fewer neighbour cells. KPI Impact: Mobility – low values of this parameter allow the UE to report fewer neighbour cells. High values of this parameter allow the UE to report more neighbour cells.. A procedure that optimizes maxReportCells would contain the following steps: Step 1: Set the value of maxReportCells to one of the following values {1, 2, 3, 4, 5, 6, 7, and 8}. Step 2: Perform a drive test in and out of the cell and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of maxReportCells. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.6.9

REPORTAMOUNT

This parameter configures the number of periodical reports the UE has to transmit after the event was triggered. Recommended Value= "r8"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Increase the Handover Success Rate for multiple repe titions in bad RF conditions. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 103/194


MGR /TIPS /NEA

Decreasing the value of this parameter would: Decrease the Handover Success Rate for multiple repetitions in bad RF conditions. KPI Impact: Mobility – low values of this parameter allow the UE to report fewer neighbour cells. High values of this parameter allow the UE to report more neighbour cells.. A procedure that optimizes reportAmount would contain the following steps: Step 1: Set the value of reportAmount to one of the following values {r1, r2, r4, r8, r16, r32, r64}. Step 2: Perform a drive test in and out of the cell and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of reportAmount. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.6.10 CALL FLOW FOR INTER-ENB MOBILITY, X2 HO – UE IN RRC CONNECTED

Figure 14.1-11: Call flow for Inter-eNB mobility, X2 HO – UE in RRC Connected (1)


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 104/194


MGR /TIPS /NEA

Figure 14.1-12: Call flow for Inter-eNB mobility, X2 HO – UE in RRC Connected (2)


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 105/194


MGR /TIPS /NEA

14.1.6.11 CALL FLOW FOR INTER-ENB MOBILITY, S1 HO – UE IN RRC CONNECTED

Figure 14.1-13: Call flow for Inter-eNB mobility, S1 HO – UE in RRC Connected (1)


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 106/194


MGR /TIPS /NEA

Figure 14.1-14: Call flow for Inter-eNB mobility, S1 HO – UE in RRC Connected (2)

14.1.6.12 INTRA-ENB HO INTERRUPTION TIME RESULTS FOR LA4.0.1 u-plane test

DL grant1

DL grant2

delta (ms)

1

7827

7884

57

2

7222

7281

59

3

1077

1124

47

4

9922

9971

49

5

5202

5254

52

average

52,8

Table 14-2: Intra-eNB HO Interruption time


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 107/194


MGR /TIPS /NEA

14.1.6.13 REFERENCE FOR ALL THE SOFTWARE USED Orvault lab SW versions HSS

R3.0 IAP1

PCRF

DSC_3_0_R1 (DSC_3_0_I377)

S-GW

R3.0_R1

P-GW

R3.0_R1

MME02

R21.80.12.07

MME03

R22.31.01

eNB40


UE


LLDM

R4.0.4

Priority 1=>128-EIA1 (SNOW 3G) Priority 2=>128-EIA2 (AES) Priority 1=>128-EEA0 (No ciphering) Priority 2=>128-EEA1 (SNOW 3G)

EPS Integrity Protection Algorithm MME03



14.1.7 INTER-FREQUENCY (IDLE MODE ) Cell reselection is a UE procedure to determine which cell/frequency a UE should camp on when it is in idle state. The parameters used in UE cell reselection algorithm are controlled by eNB through the broadcasting of the related SystemInformationBlockType (SIB) IE on the BCH of the cell the UE is camping on. To support intra-LTE inter-frequency cell reselection, SIB5 is broadcasted in addition to SIB3. Let„s consider: IF SServingCell > Snonintrasearch -> UE choose to not perform inter-frequency measurements If SServingCell ≤ Snonintrasearch -> UE shall perform inter-frequency measurements ... Now using parameters... IF Qrxlevmeas > Qrxlevmin + Qrxlevminoffset + Snonintrasearch -> UE does not measures IF Qrxlevmeas ≤ Qrxlevmin + Qrxlevminoffset + Snonintrasearch -> UE measures


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 108/194


RSRP

MGR /TIPS /NEA

Target cell is reselected UE starts inter-freq meas for cell reselection LTE Serving Cell 4

RSRP LTE Target Cell

1 Qrxlevmin(SIB3)+ sNonIntraSearch

tReselectionEUTRAN

Qrxlevmin+Qrxlevminoffset +Pcompensation +threshXHigh

3 Qrxlevmin(SIB3)+ threshServingLow

Qrxlevmin+Qrxlevminoffset +Pcompensation +threshXLow

2

3 Time Figure 14.1-15: LTE to LTE Mobility – Cell Reselection Step 1: Serving cell become less good and the RSRP level decrease under [Qrxlevmin(SIB3)+sNonIntraSearch]. Then Measurement GAP is activated and the UE can detect and measure lower priority cells than the serving. Step 2: Serving cell becomes worse and the RSRP level decrease under [Qrxlevmin(SIB3)+threshServingLow]. Cell reselection would be possible, but not yet candidate cell, reaching [Qrxlevmin+Qrxlevminoffset +Pcompensation+threshXLow]. Step 3: The situation just above is still reached and also, in the target cell, threshold [Qrxlevmin+Qrxlevminoffset+Pcompensation+threshXLow] is reached. tReselectionEUTRAN is started. During tReselectionEUTRAN, NO higher [Qrxlevmin+Qrxlevminoffset+Pcompensation+threshXHigh]

cell

priority

reaches

Step 4: tReselectionEUTRAN is achieved, reselection is triggered.

Figure 14.1-16: Idle Mode Algorithm B4 B13 Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 109/194


MGR /TIPS /NEA

sNonIntraSearch = 62  UE will start measuring for lower or equal priority cells when RSRP falls below -120 + 62 = -58 dBm threshServingLow = 8  UE will reselect the neighbor cell when B4 becomes worse than -120 + 8 = -112 dBm and B13 is better than -120 + 0 = -120 dBm ( threshXLow = 0)

Figure 14.1-17: Idle Mode Algorithm B13 B4 threshXHigh = 12 dBm

14.1.7.1

 UE

will reselect the higher priority cell when B4 is better than -120 + 12 = -108

QRXLEVMIN

Clarifications regarding qRxLevMin: A parameter with this name appear in several objects and is then transmitted to UE inside several system information block types i.e. Sibs: CellSelectionReselectionConf – transmitted in SIB1 and SIB3 CellReselectionConfUtraFdd – transmitted in SIB6 CellReselectionConfUtraTdd – transmitted in SIB6 CellReselectionConfGERAN – transmitted in SIB7 The IE SystemInformationBlockType3 contains cell re-selection information common for intrafrequency, inter-frequency and/or inter-RAT cell re-selection (i.e. applicable for more than one type of cell re-selection but not necessarily all) as well as intra-frequency cell re-selection information other than neighbouring cell related. This parameter configures the minimum required RSRP level in the cell, used by the UE in cell reselection. Recommended Value= "-120"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a delayed selection of target cell, i.e. a shrinking of the target cell i n idle mode. Decreasing the value of this parameter would: Determine an early selection of target cell which is similar to a shrinking of the serving cell. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 110/194


MGR /TIPS /NEA

KPI Impact: Mobility - high values might create coverage discontinuity in idle, as seen by UE. The optimization process should contain the following steps: Step 1: Set the value of qRxLevMin to one of the following values {- 124, -122, -120, -118, -116}. Step 2: With UE in idle mode, perform a drive test back and forth between the cells on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qRxLevMin and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the target cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.7.2

SNONINTRASEARCH

This parameter is used for setting a threshold for the selection criterion, threshold that would determine when, based in serving cell field level, the UE starts performing measurements for interfrequency and inter-RAT measurements. It is used for cell reselection. Recommended Value= "16"

Muti-Band Trial Value= "62"

Note: The reasoning for the use of a different value was only not to limit the performance in terms of Handover due to late measurements…

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start earlier the measurement for inter-frequency reselection which will probably empty the UE battery sooner. Decreasing the value of this parameter would: Determine the UE to start later the measurements for inter-frequency reselection. Possible impact correct and timely reselection for high speed UEs. KPI Impact: Mobility - low values delay the start of measurements performed by the UE which can be reflected in delayed reselection. The optimization process should contain the following steps: Step 1: Set the value of sNonIntraSearch to one of the following values {12, 13, 14, 15, and 16}. Step 2: With UE in idle mode, perform a drive test back and forth between the cells on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another sNonIntraSearch and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the target cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 111/194


14.1.7.3

MGR /TIPS /NEA

THRESHSERVINGLOW

Threshold for serving cell reception level used in reselection evaluation towards lower priority EUTRAN frequency or RAT. The value sent over the RRC interface is half the value configured (the UE then multiplies the received value by 2) Defined in TS 36.331 Broadcast in SystemInformationBlockType3 The reselection criterion is quite a complex one which means that the optimization of this parameter would need some decoupling to be performed and the optimization to be made one parameter at a time. There is a condition on the serving cell through threshServingLow , another one on target cell through threshXLow and another one on time through tReselectionEUTRAN . The parameter discussed here only impacts the part related to the serving cell. The condition on the serving cell can be rewritten as a condition on the measured level in the serving cell as follows: Qrelevmeas

qRxLevMin threshServingLow

The optimization of threshServingLow is based on this relation. Recommended Value= "10"

Muti-Band Trial Value= "6 and 8"

Note: To get the option to reselect as soon as possible, with serving cell reception level below sNonIntraSearch, we can set threshServingLow at the same level than sNonIntraSearch. I.e. set threshServingLow to 16 dB.

Expected behaviour when changing this parameter Increasing the value of this parameter could: Determine an earlier selection of target cell, i.e. a shrinking of the serving cell in idle mode. Decreasing the value of this parameter would: Determine a later selection of target cell which is similar to a shrinking of the target cell. KPI Impact: Mobility - low values delay the start of measurements performed by the UE which can be reflected in delayed reselection. Coverage – high values might create coverage discontinuity during reselection operation.

Optimization of this parameter, in conjunction with threshXLow should aim at obtaining the cell sizes for both target cell and serving cell both in active and in idle mode. Once the cells are correctly dimensioned for active mode, the optimization for idle mode parameters can be performed. The optimization of threshServingLow should be decoupled from the optimization for threshXLow . For this, the value of threshXLow should be the minimum allowed such that the first inequality of the selection criteria is satisfied for the largest surface of the cell. Once this is realized, the selection will always be triggered by the value of threshServingLow . The optimization process should contain the following steps (it is supposed that the sizes of cells in active mode are known): Step 1: Set the value of threshServingLow to one of the following values {6, 8, 10, 12, and 14}. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 112/194


MGR /TIPS /NEA

Step 2: With UE in idle mode, perform a drive test back and forth between the cells on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another threshServingLow and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the target cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.7.4

THRESHXLOW

This parameter sets the threshold of the selection criteria in case of inter-frequency. The reselection criterion is quite a complex one which means that the optimization of this parameter would need some decoupling to be performed and the optimization to be made one parameter at a time. There is a condition on the serving cell through threshServingLow , another one on target cell through threshXLow and another one on time through tReselectionEUTRAN . The parameter discussed here only impacts the part related to the serving cell. The condition on the serving cell can be rewritten as a condition on the measured level in the serving cell as follows:

Q relevmeas > Q rxlevmin + Pcompensation + threshXLow The optimization of threshXLow is based on this relation. Recommended Value= "0"

Multi-Band Trial Value Used= "0" Expected behaviour when changing this parameter Increasing the value of this parameter could: Determine an earlier selection of target cell, i.e. a shrinking of the serving cell in idle mode. Decreasing the value of this parameter would: Determine a later selection of target cell which is similar to a shrinking of the target cell. KPI Impact: Mobility - high values might create coverage discontinuity during reselection operation due to shrinking GSM cell as seen by the UE. Optimization of this parameter, in conjunction with threshServingLow should aim at obtaining the cell sizes for both target cell and serving cell both in active and in idle mode. Once the cells are correctly dimensioned for active mode, the optimization for idle mode parameters can be performed. The optimization of threshXLow should be decoupled from the optimization for threshServingLow . For this, the value of threshServingLow should be the minimum allowed such that the first inequality of the selection criteria is satisfied for the largest surface of the cell. Once this is realized, the selection will always be triggered by the value of threshXLow . The optimization process should contain the following steps (it is supposed that the sizes of cells in active mode are known): Step 1: Set the value of threshXLow to one of the following values {0, 6, 12, 18, and 24}. Step 2: With UE in idle mode, perform a drive test back and forth between the cells on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 113/194


MGR /TIPS /NEA

Step 3: Choose another threshXLow and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the target cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.7.5

THRESHXHIGH

This parameter configures: the IE s-IntraSearch for intra-frquency included in IE SystemInformationBlockType3 for intra-frequency, and, the IE threshX-High included in IE SystemInformationBlockType5 for inter-frequency. The value entered for CellReselectionConfLte::threshXHigh of a LTE frequency is directly used to populate the field of sIntraSearch in SIB3, or the field of threshX-High in SIB5. This parameter sets the threshold for target cell reselection evaluation towards higher priority E-Utran frequency. The threshold value used by UE is the parameter value received from SIB3 or SIB5 multiplied by 2 in unit of dB. In terms of reselection we fullfil the criteria when the SnonServingCell,x > threshXHigh during tReselectionEUTRAN


Multi-Band Trial Value Used= "12"

Expected behaviour when changing this parameter Increasing the value of this parameter could: Determine an earlier selection of target cell, i.e. a shrinking of the serving cell in idle mode. Decreasing the value of this parameter would: Determine a later selection of target cell which is similar to a shrinking of the target cell. KPI Impact: Mobility - high values might create coverage discontinuity during reselection operation due to shrinking GSM cell as seen by the UE. The optimization process should contain the following steps (it is supposed that the sizes of cells in active mode are known): Step 1: Set the value of threshXHigh to one of the following values for example {8, 10, 12, and 14}. Step 2: With UE in idle mode, perform a drive test back and forth between the cells on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another threshXHigh and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the target cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.7.6

TRESELECTIONEUTRAN

See chapter 14.1.5.6 Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 114/194


14.1.7.7

MGR /TIPS /NEA

TRESELECTIONEUTRASFMEDIUM

See chapter 14.1.5.7

14.1.7.8

TRESELECTIONEUTRASFHIGH


14.1.7.9

NCELLCHANGEHIGH


14.1.7.10 NCELLCHANGEMEDIUM See chapter 14.1.5.11

14.1.7.11 QHYSTSFHIGH See chapter 14.1.5.12

14.1.7.12 QHYSTSFMEDIUM See chapter 14.1.5.13


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 115/194


MGR /TIPS /NEA

14.1.8 INTER-FREQUENCY ( ACTIVE MODE ) EVENTS AND (A1, A2, A3 ND A5)

THRESHOLDS

INVOLVED

IN

INTER-FREQ

HO

Event A1 – serving becomes better than threshold Event A2 – serving becomes worse than threshold associated with two thresholds higher threshold used for triggering measurement gaps – entering coverage alarm lower threshold for connection release and blind redirection – below serving floor Event A3 – neighbor becomes better than an offset relative to the serving associated with one offset Event A5 – serving becomes worse than threshold1 and target becomes better than threshold2 associated with two thresholds • • •

•

•

Information about various events is provided by eNB to UE in a timely manner and the parameters related are transmitted in RRCConnectionReconfig message: RRCConnectionReconfiguration MeasConfig IE measObjectToAddModList ReportConfigEutra Information about A1 is only provided in the message that triggers measurement gaps because the UE must measure when those measurements must be stopped. Information about A2 is provided much earlier - due to the need for determining when measurement gaps must be triggered. Information about A3 is provided even earlier - due to the fact that A3 can also be used for intra – frequency HO. Information about A5 and also A3 information related to inter-frequency handover are transmitted in the message that triggers MG. •

•

•

•

For the Inter-Frequency the following state machine should be considered in terms of priorities /steps:

Figure 14.1-18: Events State Machine


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 116/194


MGR /TIPS /NEA

EXAMPLE OF A3 EVENT BASED HO FOR B13 AND B4 Going from B4 to B13, the UE will handover to B13 when: Mn -2 > Ms + 12  Mn > Ms + 14 In this case, the offset is composed of offsetFreq and hysteresis.

Figure 14.1-19: Example of A3 Event based HO for B13 and B4

EXAMPLE OF A5 EVENT BASED HO FOR B13 AND B4 Event A5: when the serving cell becomes worse than a given threshold and the neighbour cell becomes better than a given absolute threshold2

Entering condition for this event: Ms + hysteresis < thresholdEutraRsrp & Mn + offsetFreq – hysteresis > threshold2EutraRsrp

Considering for example: Ms - 2 < -109} Ms < -111 Mn + 2 >-109} Mn > -107

Figure 14.1-20: Example of A5 Event based HO for B13 and B4 Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 117/194


14.1.8.1

MGR /TIPS /NEA

THRESHOLDEUTRARSRP

This parameter configures the first threshold to be used for event A5 measurement reporting. Recommended Value= "-100"

Multi-Band trial Values Used= "-109 and -111"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a later selection of the target neighbouring cell. In an end to end call the throughput will be dragged to very low values. Decreasing the value of this parameter would: Determine an earlier selection of the target neighbouring cell. In an end to end call the throughput will not be dragged to very low values.

KPI Impact: Mobility - Low values might create coverage discontinuity during selection operation due to shrinking target cell as seen by the UE. Throughput - Low values will have negative impact in user experience, dragging the call to level were throughput will be quite low. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of thresholdEutraRsrp to one of the following values {-112, -110, -109, -108, 106}. Step 2: Perform a drive test back and forth on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another thresholdEutraRsrp and repeat Step 2 . Step 4: Post process the logged data and determine the positions at which the UE selected the new cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate; but also take care about the throughput degradation… never forget the user experience impact.

14.1.8.2

THRESHOLD2EUTRARSRP

This parameter configures the second threshold to be used for event A5 measurement reporting. This parameter configures the RRC IE Threshold EUTRA RSRP included in the IE reportConfigEUTRA in the MeasurementConfiguration IE. This IE should be present if the parameter triggerTypeEUTRA is set to eventA1, eventA2, eventA4 or eventA5 and triggerQuantity is set to RSRP. Otherwise it should be absent. Recommended Value= "-100"


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 118/194


MGR /TIPS /NEA

Multi-Band trial Values Used= "-109 and -111"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a later selection of the target neighbouring cell. Decreasing the value of this parameter would: Determine an earlier selection of the target neighbouring cell. KPI Impact: Mobility - Low values might create coverage discontinuity during selection operation due to shrinking target cell as seen by the UE. Throughput - Low values will have negative impact in user experience, dragging the call to level were throughput will be quite low. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of threshold2EutraRsrp to one of the following values {-104, -102, -100, -98, 96}. Step 2: Perform a drive test back and forth on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another threshold2EutraRsrp and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the new cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

14.1.8.3

FILTERCOEFFICIENTRSRP


14.1.8.4

HYSTERESIS


14.1.8.5

TIMETOTRIGGER


14.1.8.6

OFFSETFREQ


14.1.8.7

REPORTINTERVAL



LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 119/194


14.1.8.8

MGR /TIPS /NEA

MAXREPORTCELLS


14.1.8.9

REPORTAMOUNT


14.1.9 INTER-FREQUENCY HO TRIAL RESULTS (VERIZON WINCHESTER MARKET) During a recent trial for Verizon Market, it was performed a quite complex Multi-Band Handover campaign, for this porpoise it was used event A5 and A3 as triggers for the Handover between the different bands considered (for information Band 13 and Band 4). The main objective for this trial was to determine the optimal network settings to maximize the B4 coverage while limiting the amount of drop calls or losing data throughput. This objective should also meet the deployment scenario criteria set by Verizon. These test were performed in both connected and idle states (A5 and A3) respectively), to ensure we optimize the different conditions of a data call. Other scenarios were also completed in connected mode (A5 settings): X2 IFHO at 50% OCNS loading X2 IFHO at 100% OCNS loading S1 IFHO at 50% OCNS loading The scenario match closest to a network deployment configuration (A5 with 50% OCNS through X2), was tested more extensively with a big focus on the tuning of the parameters A5 Event – Source Threshold and A5 Event – Target Threshold. These are the two main triggers for the A5 event for Inter-frequency mobility. Important note, the results were obtained in LA3.0.2 release but due to the important topic and not so many information about Inter-Frequency, it is still interesting to post the results achieved in order to have an idea about the performance that could be expected and the main tunings around the parameters. In the next chapters will be highlighted some of the test cases executed and the outcome and feedback collected.

14.1.9.1

CONSIDERATIONS FOR BAND 13

In the below box the main considerations for the usage of both bands:


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 120/194


MGR /TIPS /NEA


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 121/194


14.1.9.2

CONSIDERATIONS FOR BAND 4

14.1.9.3

UE USED FOR MULTI-BAND

MGR /TIPS /NEA

The UE considered was a LG Gyro (Multi-Band) Mobile; please find more details on the UE in the link: Gyro Info

14.1.9.4

NETWORK CONFIGURATION

The network was composed of 6 main site locations, and some of them had different configurations; to be known (Multi-Band, Dual-Band or Single Band).


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 122/194


MGR /TIPS /NEA

Figure 14.1-21: Network Configuration

14.1.9.5

TEST CASES

As per costumer demand, the main idea was to extend to the maximum the coverage in each band, without taking the risk of dropping the connection; meaning that we should not waist valuable resources, both on the Network side or on the UE side. The tests were splited between Idle and Connected Mode (A5 and A3 eve nt).

CONNECTED MODE: For connected mode and for the event A5, it was also performed a more detailed test per customer requirement; three main scenarios were tested (X2 with 50% and 100% OCNS, plus S1 with 50% OCNS). To be noted that for a specific scenario, more similar to a network deployment configuration (A5 with 50% and 100% DL OCNS through X2), it was tested more extensively with a big focus on the tuning of two main parameters t h r e s h o l d E u t r a R s r p and t h r e s h o l d 2 E u t r a R s r p ; since these are the main triggers for the event A5 for Inter-frequency mobility. Main parameters tuning: Object

Name

Used Value

RrcMeasurementConf


Fc8

ReportConfigEUTRA

Hysteresis

2 dB

ReportConfigEUTRA

timeToTrigger

ms40

ReportConfigEUTRA

thresholdEutraRsrp (A1 Event)

-105 dBm

ReportConfigEUTRA

thresholdEutraRsrp (A2 Event)

-106 dBm

ReportConfigEUTRA

thresholdEutraRsrp (A5 Event – Source)

-109 dBm

ReportConfigEUTRA

thresholdEutraRsrp (A5 Event – Target)

-109 dBm

MeasObjectEutra

offsetFreq (A3 Event – Band13)

12 dB


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 123/194


MGR /TIPS /NEA

MeasObjectEutra

offsetFreq (A3 Event – Band4)

0 dB

MeasObjectEutra

offsetFreq (A5 Event All Bands)

0 dB

Table 14-4: Parameters Tuning for Active Mode Test cases performed for connected mode: Test

Event

DL OCNS (%)

Interface

Hysteresis

thresholdEutraRsrp (dBm)

Threshold2EutraRsrp (dBm)

Connected

A5

50

X2

2

-109

-109

Connected

A5

100

X2

2

-109

-109

Connected

A5

50

S1

2

-109

-109

Connected

A3

50

X2

2

-109

-109

Connected

A3

100

X2

2

-109

-109

Connected

A5

50

X2

2

-111

-111

Connected

A5

100

X2

2

-111

-111

Table 14-5: Connected Mode Test cases executed

All Routes

Avg

Before HO @Source (Mbps)

After HO @Target Cell (Mbps)

HO Interruption Time (ms)

Distance from Source Site (miles)

Success Rate (%)

DL 1-put

UL T-put

DL T-put

UL T-put

C-Plane

U-Plane

Distance

Success Rate

3,88

0,51

4,25

2,65

63,18

77,33

0,92

100


Success Rate (%)

Table 14-6: A5 through S1 with 50% DL OCNS

All Routes

Avg




DL 1-put

UL T-put

DL T-put

UL T-put

C-Plane

U-Plane

Distance

Success Rate

3,77

0,67

2,85

2,31

100

72,20

1,07

97,22


Success Rate (%)

Table 14-7: A5 through X2 with 100% DL OCNS

All Routes

Avg




DL 1-put

UL T-put

DL T-put

UL T-put

C-Plane

U-Plane

Distance

Success Rate

4,64

0,58

4,16

2,67

46,57

68,42

1,06

100


Success Rate (%)


All Routes

Avg




DL 1-put

UL T-put

DL T-put

UL T-put

C-Plane

U-Plane

Distance

Success Rate

3,98

0,48

4,62

3,92

50,35

70,17

1,04

100



LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 124/194


All Routes


MGR /TIPS /NEA




Success Rate (%)

DL 1-put

UL T-put

DL T-put

UL T-put

C-Plane

U-Plane

Distance

Success Rate

3,23

0,61

3,92

2,89

49,11

71,53

1,03

98,61


Success Rate (%)

Avg


All Routes




DL 1-put

UL T-put

DL T-put

UL T-put

C-Plane

U-Plane

Distance

Success Rate

3,19

0,25

2,81

2,00

46,61

69,47

1,18

100

Avg

Table 14-11: A5 through X2 with 100% DL OCNS (thresholdEutraRSRP & threshold2EutraRSRP =-111)

All Routes





Success Rate (%)

DL 1-put

UL T-put

DL T-put

UL T-put

C-Plane

U-Plane

Distance

Success Rate

3,93

0,24

4,39

2,19

47,72

63,13

1,20

100

Avg

Table 14-12: A5 through X2 with 50% DL OCNS (thresholdEutraRSRP & threshold2EutraRSRP =-111)

CONNECTED MODE CONCLUSIONS: A5 event presents better coverage, 3.85% more compared with Event A3.In average we are able to reach 1.08miles coverage on Band 4

Using A5 event on source target, For 50% OCNS, we get 20.83% more UL throughput compared with Event A3 For 100% OCNS UL throughput is better 9.83% compared with Event A3 Overall we are capable to reach better UL throughput using Event A5 until we perform the Inter Frequency HO Inter Frequency interruption time is similar in both cases A5 and A3 event. In both cases we reach 49ms for C-plane and around 70ms for U-plane. Using alternate parameters ( more aggressive), we have better coverage on band 4 using A5 event. Using 50% OCNS we reach 11.11% more coverage on band 4 Using 100% OCNS we reach10.28% more coverage on band 4 Coverage on band 4 using A5 event we reach 1.20miles Performing Inter Frequency HO with S1 the U-plane Interruption Time takes more time than using X2.

IDLE MODE The focus of the idle mode tests was to verify that the UE was respecting the thresholds defined and also the priorities set.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 125/194


MGR /TIPS /NEA

Basically, in the test, the main objective was to extend to the maximum the idle session in the source cell before the mobile perform the reselection to the target. Other configuration was regarding the priority, using for that porpoise the CellReselectionConfLte:: cellReselectionPriority parameter. It was on the interest of Verizon to keep the mobile in the Band 4 most of the time, and perform Band 13 reselection only if Band 4 not available… So, by defining this parameter wi th a different value /priority it was possible to prioritize the Band 4 instead Band 13. Main parameters tuning: Object

Name

Used Value


qRxLevMin

-120 dBm


sNonIntraSearch

62 dB

CellSelectionReselectionConfLTE

threshXLow

0 dB


threshXHigh

12 dB


threshServingLow

8 dB


tReselectionEutra

2s


cellReselectionPriority (B4)

5


cellReselectionPriority (B13)

1

Table 14-13: Parameters Tuning for Idle Mode Tests cases performed for Idle mode: Test

DL OCNS (%)

ThreshXLow

SNonIntraSearch

threshXHigh

ThreshServingLow

tReselectionEUTRAN

Idle

50

0

62

12

8

2

Idle

100

0

62

12

8

2

Table 14-14: Idle Mode Test cases executed

Before Reselection, Source Cell

After Reselection, Target Cell

Distance to Site IF reselection take place (Miles)

RSRP Source Cell (dBm)

SNR Source Cell (dB)

RSRP Target Cell (dBm)

SNR Target Cell (dB)

Distance

-114,06

0,85

-104,71

-0,20

1,07

Table 14-15: Idle Mode Test B4 B13 with 50% OCNS Before Reselection, Source Cell







Distance

-98,94

3,26

-104,94

4,60

1,21

Table 14-16: Idle Mode Test B13 B4 with 50% OCNS


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 126/194


MGR /TIPS /NEA

% time spent in each band

Number of Attempts

% of time spent on B4

35.17

37 % of time spent on B13

64.83

Nb attempts from B13 to B4 Nb attempts from B4 to B13

48

Figure 14.1-22: Time spent in each Band vs. Number of Reselection Attempts for 50% OCNS Before Reselection, Source Cell







Distance

-113.61

-0,36

-103,94

-0,89

1,06

Table 14-17: Idle Mode Test B4 B13 with 100% OCNS Before Reselection, Source Cell







Distance

-97,39

0,93

-103,75

4,26

1,11

Table 14-18: Idle Mode Test B13 B4 with 100% OCNS

Number of Attempts

% time spent on each band

34


66


38

Nb attempts from B13 to B4 Nb attempts from B4 to B13

51

Figure 14.1-23: Time spent in each Band vs. Number of Reselection Attempts for 100% OCNS

IDLE MODE CONCLUSIONS Setting a higher priority to B4

 in

idle mode, UE will always reselect B4 first

For 50% OCNS, UE spent 64.83% of the time on B4 and for 100% OCNS, 66% on B4. For each 50% and 100% OCNS, only one “call drop” (no service) – UE looses sync with the network because RSRP falls below qRxLevMin (<-120dBm) Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 127/194


MGR /TIPS /NEA

In order to trigger reselection, we set conditions on B4: Going from B4 to B13, reselection will take place when RSRP of B4 is worse than - 112 dBm. We‟ve obtained an average of -114 dBm To reselect B13 earlier, we should increase the value of threshServingLow parameter Going from B13 to B4, reselection will take place when RSRP of B4 is better than - 108 dBm. We‟ve obtained an average of -104 dBm To reselect B4 earlier, we should decrease the value of threshXHigh parameter

15 IRAT MOBLILTY OPTIMIZATION HINTS

Mobility

Idle Mode

UMTS Reselection

Active Mode

GERAN Reselection

UMTS PS Handover Release and Redirect Blind

GERAN Cell Change Order with NACC Release and Redirect Blind

15.1 LTE-UMTS OPTIMIZATION HINTS Mobility from LTE to UMTS has been implemented in three forms: Cell reselection: for mobility in idle mode PS Handover: for mobility in connected mode Release & Redirect: for mobility in connected mode Cell reselection from EUTRAN to UTRAN includes the support of additional information elements of SIB3 and SIB6 by the eNB. Redirection (including RRC connection release) includes the support of configuration of UE measurement and RRCConnectionRelease message with the IE redirectedCarrierInfo.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 128/194


MGR /TIPS /NEA

EUTRA-to-UTRA PS Handover

GSM_Connected E-UTRA RRC_CONNECTED

CELL_DCH

Handover GPRS Packet transfer mode

UTRA-to-EUTRA PS Handover

CELL_FACH LTE RRC Connection establishment

CCO with NACC

CELL_PCH URA_PCH

CCO, Reselection

E-UTRA to UTRA Reselection LTE RRC Connection Release

Connection establishment/release E-UTRA to UTRA Reselection

E-UTRA RRC_IDLE

UTRA_Idle E-UTRA to UTRA Reselection

Connection establishment/release

Reselection

GSM_Idle/GPRS Packet_Idle

CCO, Reselection

Figure 15.1-1: LTE to UTRAN mobility in the context of IRAT mobility

In LA2.0 and for the UE in RRC idle mode, the inter-RAT mobility to UTRA-FDD is supported with the cell reselection from E-UTRA-FDD to UTRA-FDD. Cell reselection inter-RAT (E-UTRA-FDD to UTRAFDD) is internal to the UE and controlled by system information parameters provided in SystemInformationBlockType6 SIB6 and SystemInformationBlockType3 SIB3. Cell reselection to UTRA-FDD is supported with SystemInformationBlockType6 SIB6. Cell reselection to UTRA-FDD is enhanced with SystemInformationBlockType3 SIB3 (IE speedStateReselectionPars). In LA2.0 and for the UE in RRC connected mode, the inter-RAT mobility to UTRA-FDD is supported with the RRC connection release and redirection from E-UTRA-FDD to UTRA-FDD. The redirection is driven by the eNodeB based on radio criteria. When the EUTRA serving cell becomes worse than a threshold and the UTRA-FDD neighbouring cell becomes better than another threshold, the eNodeB receives a Measurement Report message with Event-B2 from the mobile. If the UE capability or the network cannot support EUTRA-to-UTRA-FDD PS handover, the Algorithm for Control Procedures for Mobility decides to trigger a redirection EUTRA-to-UTRA-FDD. When the eNodeB does not receive any Measurement Report message from the mobile and, if the UE capability or the network cannot support EUTRA-to-UTRA-FDD PS handover, t he selection of mobility mechanism decides to trigger a blind EUTRA -to-UTRA-FDD redirection (i.e. without measurements). The function of EUTRA-to-UTRA-FDD redirection, the eNodeB provides the following functions; (1) EUTRA-to-UTRA-FDD redirection execution phase; (2) EUTRA-to-UTRA-FDD redirection completion phase. During the previous phase of section Mobility Trigger Management (Control Procedures for Mobility), the source ENB has decided to initiate a EUTRA-to-UTRA-FDD redirection to the target access network (UTRA-FDD). The source ENB will give a command to the UE to re-select a cell in the target access network via the RRC CONNECTION RELEASE. The RRCConnectionRelease message is used to command the release of an RRC connection.

15.1.1 INTER-FREQUENCY (IDLE MODE ) Done by the UE under control from EUTRAN via System Information Broadcast Cell selection: the UE seeks to identify a suitable cell i.e. cell for which the measured cell attributes satisfy the cell selection criteria; if found it camps on that cell and starts the cell reselection procedure Cell reselection: UE performs measurements of the serving and neighbour cells: Intra-frequency reselection is based on ranking of cells; Inter-frequency and Inter-RAT reselection is based on absolute priorities where UE tries to camp on highest priority frequency available. The cell selection and reselection algorithms are controlled by setting of parameters (thresholds and hysteresis values) that define the best cell and/or determine when the UE should select a new cell.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 129/194


MGR /TIPS /NEA

SIB6 contains information about UTRA frequencies and UTRA neighbouring cells relevant for cell reselection (including cell re-selection parameters common for a frequency as well as cell specific reselection parameters) In RRC_IDLE mode, the cell reselection is internal to UE and is controlled by the System Information Parameters provided in SIB6 if the reselection to UTRA FDD is enabled (isMobilityToUtraAllowed = TRUE). Any modification of SIB6 parameters triggers a dynamic system information modification procedure

Figure 15.1-2: Cell Reselection procedure In order to limit the amount of inter-RAT measurements an additional criterion broadcasted in SIB3 is used: Snonintrasearch: threshold for serving cell reception under which the UE may trigger inter-RAT measurements for cell reselection. Configurable under : CellSelectionReselectionConf::sNonIntraSearch

The UE applies rules as follows, where CRP = Cell Reselection Priority and IRAT=UTRAN, GERAN, S = selection criterion:

Figure 15.1-3: UE rules follow-up 3GPP rules: SservingCell > 0 where SservingCell = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset) - Pcompensation Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 130/194


MGR /TIPS /NEA

* Pcompensation = compensation factor to penalize the low power UEs = 0 Let„s consider: IF SServingCell > Snonintrasearch -> UE choose to not perform inter-RAT measurements If SServingCell ≤ Snonintrasearch -> UE shall perform inter-RAT measurements ... Now using parameters... IF Qrxlevmeas > Qrxlevmin + Qrxlevminoffset + Snonintrasearch -> UE does not measures IF Qrxlevmeas ≤ Qrxlevmin + Qrxlevminoffset + Snonintrasearch -> UE measures

UE will reselect the new cell if the conditions below are met: • Sservingcell < threshServingLow and SnonServingCell > threshXLow during tReselectionUtra • No cell with higher priority than the serving will fulfil the condition: SnonServingCell > threshXHigh during tReselectionUtra • More than 1 second(s) has elapsed since the UE camped on the current serving cell.

Figure 15.1-4: LTE to UTRAN Mobility – (RSRP vs. Time) measurement phase Several database parameters are used for handling this kind of mobility. Some of them are tuneable and most important are the following: qRxLevMin, pMaxUTRA, qQualMin, sNonIntraSearch, trhreshServingLow, threshXLow . A summary of the selection procedure is presented in the figure below.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 131/194


MGR /TIPS /NEA

Figure 15.1-5: LTE to UTRAN Mobility – Algorithm Cell Reselection toward lower priority UTRAN Cell

Figure 15.1-6: LTE to UTRAN Mobility – (RSRP vs. Time) Decision Phase

15.1.1.1

QRXLEVMIN

Clarifications regarding qRxLevMin: A parameter with the same name appears in several objects and is then transmitted to UE inside several system information block types i.e. Sibs: CellSelectionReselectionConf – transmitted in SIB1 and SIB3 CellReselectionConfUtraFdd – transmitted in SIB6 CellReselectionConfUtraTdd – transmitted in SIB6 CellReselectionConfGERAN – transmitted in SIB7 The LTE – UTRAN mobility is using two of them, the one sent in SIB3 and the one sent in SIB6. The IE SystemInformationBlockType3 contains cell re-selection information common for intrafrequency, inter-frequency and/or inter-RAT cell re-selection (i.e. applicable for more than one type of cell re-selection but not necessarily all) as well as intra-frequency cell re-selection information other than neighbouring cell related. The IE SystemInformationBlockType6 contains information relevant only for inter- RAT cell reselection i.e. information about UTRAN frequencies relevant for cell re -selection. This parameter configures the minimum required RSCP level in the UTRAN cell, used by the UE in cell reselection. Recommended Value= "-115"

Expected behaviour when changing this parameter Increasing the value of this parameter could: Determine a delayed selection of UTRAN cell, i.e. a shrinking of the UTRAN cell in idle mode. Decreasing the value of this parameter would: Determine an early selection of UTRAN cell which is similar to a shrinking of the EUTRAN cell. KPI Impact: Mobility - high values might create coverage discontinuity in idle, as seen by mobile.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 132/194


MGR /TIPS /NEA

Optimization of this parameter should contain the following steps Step 1: Set the value of qRxLevMin to one of the following values {- 124,-122,-120,-118,-116}. Step 2: With UE in idle mode, perform a drive test back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qRxLevMin and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the UTRAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.1.2

SNONINTRASEARCH

This parameter is used for setting a threshold for the selection criterion, threshold that would determine when, based in serving cell field level, the UE starts performing measurements for interfrequency and inter-RAT measurements. It is used for cell reselection. Recommended Value= "16" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start earlier the measurement for inter-RAT reselection which will probably empty the UE battery sooner. Decreasing the value of this parameter would: Determine the UE to start later the measurements for inter-RAT reselection. Possible impact correct and timely reselection for high speed UEs. KPI Impact: Mobility - low values delay the start of measurements performed by the UE which can be reflected in delayed reselection. The optimization process should contain the following steps: Step 1: Set the value of sNonIntraSearch to one of the following values {12, 14, 16, 18, and 20}. Step 2: With UE in idle mode, perform a drive test back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another sNonIntraSearch and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the UTRAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.1.3

THRESHSERVINGLOW

This threshold is used when the mobility towards lower priority frequency is taken in consideration. The default priority for UTRAN frequency is lower than for EUTRAN frequency which implies that this parameter is used each time mobility towards UTRAN happens. This parameter sets the threshold of the selection criteria in case of mobility towards lower priority RAT. The reselection criterion is quite a complex one which means that the optimization of this parameter would need some decoupling to be performed and the optimization to be made one parameter at a time. There is a condition on the serving cell through threshServingLow , another one on target cell through threshXLow and another one on time through tReselectionRAT . Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 133/194


MGR /TIPS /NEA

The parameter discussed here only impacts the part related to the serving cell. The condition on the serving cell can be rewritten as a condition on the measured level in the serving cell as follows: Qrelevmeas qRxLevMin threshServingLow The optimization of threshServingLow is based on this relation.

Recommended Value= "16" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine an earlier selection of UTRAN cell, i.e. a shrinking of the EUTRAN cell in idle mode. Indeed, it is possible that modifying the value of this parameter in a given range does not in fact impact the selection due to possibly stronger condition on the UTRAN cell. Decreasing the value of this parameter would: Determine a later selection of UTRAN cell which is similar to a shrinking of the UTRAN cell. The similar observation made above, regarding the condition that ultimately triggers the selection is applicable for this situation as well. KPI Impact: Mobility - low values delay the start of measurements performed by the UE which can be reflected in delayed reselection. Coverage - high values might create coverage discontinuity during reselection operation. Optimization of this parameter, in conjunction with threshXLow should aim at obtaining the cell sizes for both UTRAN cell and EUTRAN cell both in active and in idle mode. Once the cells are correctly dimensioned for active mode, the optimization for idle mode parameters can be performed. The optimization of threshServingLow should be decoupled from the optimization for threshXLow . For this, the value of threshXLow should be the minimum allowed such that the first inequality of the selection criteria is satisfied for the largest surface of the cell. Once this is realized, the selection will always be triggered by the value of threshServingLow . The optimization process should contain the following steps (it is supposed that the sizes of cells in active mode are known): Step 1: Set the value of threshServingLow to one of the following values {0, 6, 12, 18, and 24}. Step 2: With UE in idle mode, perform a drive test back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another threshServingLow and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the UTRAN cell. Step 5: Choose the optimized value.

15.1.1.4

THRESHXLOW

This threshold is used when the mobility towards lower priority frequency is taken in consideration. The default priority for UTRAN frequency is lower than for EUTRAN frequency which implies that this parameter is used each time mobility towards UTRAN happens. This parameter sets the threshold of the selection criteria in case of mobility towards lower priority RAT. The reselection criterion is quite a complex one which means that the optimization of this parameter would need some decoupling to be performed and the optimization to be made one parameter at a time. There is a condition on the serving cell through threshServingLow , another one on target cell through threshXLow and another one on time through tReselectionRAT . Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 134/194


MGR /TIPS /NEA

The parameter discussed here only impacts the part related to the serving cell. The condition on the serving cell can be rewritten as a condition on the measured level in the serving cell as follows: Q relevmeas > Q rxlevmin + Pcompensation + threshXLow The optimization of threshXLow is based on this relation. Recommended Value= "0" Expected behaviour when changing this parameter Increasing the value of this parameter could: Determine an earlier selection of UTRAN cell, i.e. a shrinking of the EUTRAN cell in idle mode. Indeed, it is possible that modifying the value of this parameter in a given range does not in fact impact the selection due to possibly stronger condition on the EUTRAN cell. Decreasing the value of this parameter would: Determine a later selection of UTRAN cell which is similar to a shrinking of the UTRAN cell. The similar observation made above, regarding the condition that ultimately triggers the selection is applicable for this situation as well. KPI Impact: Mobility - high values might create coverage discontinuity during reselection operation due to shrinking UMTS cell as seen by the UE.

Optimization of this parameter, in conjunction with threshServingLow should aim at obtaining the cell sizes for both UTRAN cell and EUTRAN cell both in active and in idle mode. Once the cells are correctly dimensioned for active mode, the optimization for idle mode parameters can be performed. The optimization of threshXLow should be decoupled from the optimization for threshServingLow . For this, the value of threshServingLow should be the minimum allowed such that the first inequality of the selection criteria is satisfied for the largest surface of the cell. Once this is realized, the selection will always be triggered by the value of threshXLow . The optimization process should contain the following steps (it is supposed that the sizes of cells in active mode are known): Step 1: Set the value of threshXLow to one of the following values {0, 6, 12, 18, and 24}. Step 2: With UE in idle mode, perform a drive test back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another threshXLow and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the UTRAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate. Step 5: Choose the optimized value.

15.1.1.5

TRESELECTIONUTRA

This parameter concerns the cell reselection timer tReselectionRAT for UTRAN. Broadcast in SystemInformationBlockType6. It imposes a condition on the reselection. UE will actually reselect the new cell, only if the new cell is better ranked than the serving cel l during a time interval tReselectionUtra.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 135/194


MGR /TIPS /NEA


Expected behaviour when changing this parameter Increasing the value of this parameter could: Determine a delayed reselection which could be an issue for fast moving UEs. Decreasing the value of this parameter would: Facilitate ping-pong behaviour during reselection process. KPI Impact: Mobility - low values of this parameter might allow ping-pong behaviour during HO operation. High values of this parameter might delay the HO and possible lead to lost connection to the serving cell. Optimization of this parameter should find a trade-off between delayed reselection and ping pong behaviour. Most probably, if the UEs are not moving fast, the delayed reselection would not be an issue. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionUtra to one of the following values {1, 2, 3, and 4}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and UTRAN cell on various routes and log the reselection - related messages and the position of the UE. Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionUtra. Step 4: Post-process the logs and analyze them as reselection position vs. tReselectionUtra values and ping pong behaviour vs. tReselectionUtra values and choose the optimized value to obtain smallest interruption time and highest success rate. Step 5: Calculate the HO success rate in each direction.

15.1.1.6

TRESELECTIONUTRASFMEDIUM

This parameter contributes to the configuration of the IE SystemInformationBlockType6 if the UE is in Medium Mobility state. The concerned mobility control related parameter is multiplied with this factor if the UE is in Medium Mobility state as defined in TS 36.304. This parameter avoids ping pong radio phenomena during the RA-Update & idle mobility. Recommended Value= "oDot25" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 136/194


MGR /TIPS /NEA


For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionUtraSfMedium to one of the following values {0.25, 0.5, 0.75, and 1}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and UTRAN cell on various routes and log the reselection - related messages and the position of the UE. Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionUtraSfMedium. Step 4: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.1.7

TRESELECTIONUTRASFHIGH

This parameter contributes to the configuration of the IE SystemInformationBlockType6 if the UE is in High Mobility state. The concerned mobility control related parameter is multiplied with this factor if the UE is in High Mobility state as defined in TS 36.304. This parameter avoids ping pong radio phenomena during the RA-Update & idle mobility. Recommended Value= "oDot25" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter will determine the UE to start reselection later.

For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionUtraSfHigh to one of the following values {0.25, 0.5, 0.75, and 1}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and UTRAN cell on various routes and log the reselection - related messages and the position of the UE. Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionUtraSfHigh. Step 4: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.1.8

NCELLCHANGEHIGH

This parameter configures the number of cell changes to enter high mobility state


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 137/194


MGR /TIPS /NEA

Recommended Value= "12" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter might allow the UE to start reselection later.

A procedure that optimizes nCellChangeHigh would contain the following steps: Step 1: Set the value of nCellChangeHigh to one of the following values {10, 11, 12, 13, and 14}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another nCellChangeHigh and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.1.9

NCELLCHANGEMEDIUM

This parameter configures the number of cell changes to enter medium mobility state Recommended Value= "4"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter might allow the UE to start reselection later.

A procedure that optimizes nCellChangeMedium would contain the following steps: Step 1: Set the value of nCellChangeMedium to one of the following values {1, 2, 3, 4, 5, and 6}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another nCellChangeMedium and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 138/194


MGR /TIPS /NEA

15.1.1.10 QHYSTSFHIGH This parameter contributes to the configuration of the IE SystemInformationBlockType3.This parameter configures the IE sf-High included in the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for Qhyst” in TS 36.304. The sf -High concerns the additional hysteresis to be applied, in High Mobility state, to Qhyst as defined in TS 36.304 state. This parameter is an environment dependent parameter. This parameter configures the hysteresis value of the serving cell used by the UE for ranking criteria in cell reselection. Recommended Value= "dB-6"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter might allow the UE to start reselection later.

A procedure that optimizes qHystSfHigh would contain the following steps: Step 1: Set the value of qHystSfHigh to one of the following values {dB-6, dB-4, dB-2, dB0}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qHystSfHigh and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.1.11 QHYSTSFMEDIUM This parameter contributes to the configuration of the IE SystemInformationBlockType3.This parameter configures the IE sf-Medium included in the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for Qhyst” in TS 36.304. The sf -High concerns the additional hysteresis to be applied, in Medium Mobility state, to Qhyst as defined in TS 36.304 state. This parameter is an environment dependent parameter. This parameter configures the hysteresis value of the serving cell used by the UE for ranking criteria in cell reselection. Recommended Value= "dB-6"



LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 139/194


MGR /TIPS /NEA

KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter might allow the UE to start reselection later.

A procedure that optimizes qHystSfMedium would contain the following steps: Step 1: Set the value of qHystSfMedium to one of the following values {dB-6, dB-4, dB-2, dB0}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qHystSfMedium and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.2 INTER-FREQUENCY ( ACTIVE MODE ) The inter-RAT mobility in RRC_CONNECTED state is UE assisted (since the UE provides measurements) and consists in a handover (HO) controlled by the network, with a HO preparation signalling in EUTRAN and UTRAN. Typically, the UE measurement reporting to eNB triggers the handover preparation. In addition, the handover decisions may take other inputs, such as neighbour cell load (not LA3.0), Traffic distribution (eMCTA), transport and hardware resources (not LA3.0) and Operator defined policies into account. In LA3.0, the inter-RAT measurements on the UMTS overlay are UTRA FDD CPICH RSCP, UTRA FDD carrier RSSI, UTRA FDD CPICH Ec/No. The reporting of UE measurements is event-triggered and configured in the UE by the EUTRAN eNodeB.

15.1.2.1

UE MEASUREMENTS NEEDED FOR LA3.0 PS HO TO UTRA-FDD

Figure 15.1-7: UE measurements needed for LA3.0 PS HO to UTRA-FDD Intra-freq measurements to trigger inter-RAT measurements Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 140/194


MGR /TIPS /NEA

The eNodeB configures an event A2 (A2_CA for Coverage Alarm) that is configured at cell entry (call set-up, incoming handover, RRC re-establishment) with purpose in MiM set to “Entering -CoverageAlarm” (serving worse than mobility threshold) Inter-RAT measurements for PS HO to UTRA The eNodeB configures an event B2 (Serving worse than Threshold1 and neighbour better than Threshold2) that is configured after reception of an event A2_CA i.e. when the radio enter the coverage alarm conditions An event B1 (Neighbour better than Threshold) can also be configured for CS fallback as explained by LA3.0 CSFB feature presentation Measurement Gaps may be needed with respect to UE capabilities (per RAT and carrier) The eNodeB checks conditions before configuring inter-RAT measurements to UTRA-FDD the mobility to UTRAN is activated in MiM (isMobilityToUtranAllowed „TRUE‟) although PS HO may be deactivated (isPsHoToUtranAllowed „FALSE‟) since redirection may be used At least one inter-RAT neighbour carrier is configured in MiM for the serving LTE cell UE can perform inter-RAT measurements, reporting and measurement reporting event B2 in eUTRA RRC_connected

15.1.2.2

LA3.0 PS HO PREPARATION

RRC Measurement reporting (event B2) the eNodeB receives a RRC MeasReport with event B2 with a Measurement Purpose set to “Mobility Inter-RAT-to-UTRA” as retrieved in the call context: Measurement Purpose retrieved from the MeasId in RRC MeasReport The eNodeB takes a “PS-HO-to-UMTS” decision with data configured in MiM the eNB retrieves the HO target Cell/RNC from the MeasObject stored in the eNB call context the UTRAN carrier reported by the UE leads to the UtraFddNeighboringFreqConf object (MiM) the UTRAN PhysicalCellId (primary scrambling code) leads to the UtraFddNeighboringCellRelation (MiM) the eNB retrieves the target RNC and the DL forwarding tunnel type (direct or indirect) the RNC state is given by the UtraFddNeighboringCellRelation.RncAccess the user-plane tunnel type by the RncAccess.DirectFwdPathAvailability of course the UE must support the PS HO to 3G as reported by “FGI bit#8 - EUTRA RRC_CONNECTED to UTRA CELL_DCH PS handover” The S1AP HO Preparation Procedure is triggered by source eNB towards target RNC There are exchanges of RRC containers that are transparent to the eNodeB (mediation service) The SourceToTarget container in S1AP HANDOVER REQUIRED with a source-RNC to target-RNC radio container and UE UTRAN capabilities that are sent from UE to the target RNC. This information is received from the UE (UE capabilities enquiry, RRC procedure) or from the MME the TargetToSource container in S1AP HANDOVER COMMAND with a target-RNC to source-RNC radio container and UTRAN access info about the target UTRA cell sent from the target RNC to the UE


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 141/194


15.1.2.3

MGR /TIPS /NEA

LA3.0 PS HO EXECUTION

Figure 15.1-8: LA3.0 PS HO Execution RRC MobilityFromEUTRACommand this message includes the transmission of the radio container that is the target-RNC to source-RNC radio container previously received in the S1AP HANDOVER COMMAND message. Indeed the eNodeB has ensured the S1AP-to-RRC mediation in a transparent fashion.

Figure 15.1-9: PS HO to UTRA-FDD - End-to-End call flows


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 142/194


MGR /TIPS /NEA

Figure 15.1-10: LTE to UTRAN Mobility – Redirection Execution Inter-RAT Mobility to UMTS in RRC Connected Mode : RRC Connection Release and Redirection to UTRAN. Redirection from LTE to a UTRAN target cell relies on radio measurements to trigger the redirection procedure. A redirection results in a RRC Connection Release from the source eNB, instructing the UE to leave the LTE eUTRAN and start access on a new target cell in the UTRAN RAT. Only blind redirection was implemented in LA2.0. Blind redirection means redirection without measurements on a target RAT. Blind redirection is triggered by detection of serving cell degradation (eventA2) when intra-frequency LTE radio conditions fall below a c onfigured threshold.

Blind Redirection towards another RAT (e.g. UMTS)

A2_floor_threshold in the diagram below is thresholdEutraRsrp or thresholdEutraRsrq.

1. Serving radio level goes below the A2_floor_threshold. 2. timeToTrigger expires (thick red line) 3. Meas Report Event A2 with purpose „Blind-Redirection-To-3GPP-RAT‟ sent to eNB 4. eNB performs control procedure for Blind Redirection to UTRAN.

Figure 15.1-11: RAT frequency with highest cellReselectionPriority is chosen for redirection

In RRC_Connected mode, the eNB may trigger a procedure of RRC Release with Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 143/194


MGR /TIPS /NEA

Redirection Information (IE redirectedCarrierInfo) - if this is enabled if isMobilityToUtraAllowed=TRUE - and if the UE is also be eligible for redirection to UTRA-FDD(support UTRA-FDD) - and if mobility to UTRA not forbidden for UE in S1AP HandoverRestrictionlist. The redirection can be blind (eMCTA used for redirectedCarrierInfo) or based on inter RAT measurement to UTRA-FDD. Redirection to UTRAN triggers: A MeasReport with event B2 and purpose “Mobility inter -RAT to UTRA”: this is the Meas. Based Redirection when the PS HO cannot be performed A MeasReport with event A2 and purpose “Below Serving Floor”: Redirection Blind (MobilityPriorityTable::defaultConnectedPriorityOfFreq by eMCTA for blind) or Meas-Based (measured UTRAN carrier, if PS HO was ongoing)

Figure 15.1-12: RRC Connection Release with Redirection Info from EU TRAN to UTRAN Event B2 – Serving becomes worse than threshold1 and inter-RAT neighbour becomes better than threshold2. Entering conditions for this event:

& Ms = measurement result of the serving cell [dBm] Hys = reportConfigUTRA::hysteresis [dB] Thresh1 = ReportConfigUTRA:: thresholdEutraRsrpB2 [dBm] Mn = measurement result of the inter-RAT neighbour cell [dBm] Ofn = MeasObjectUTRA::offsetFreq , corresponding to the neighbouring cell [dB] Thresh2 = ReportConfigUTRA:: thresholdUtraRscp [dBm]


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 144/194


MGR /TIPS /NEA

Figure 15.1-13: Inter RAT threshold for event B2

15.1.2.4

THRESHOLDEUTRARSRPB2

This parameter sets the RSRP threshold for the serving cell of the selection criteria in case of mobility towards UTRAN. Recommended Value= "-100"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine an earlier selection of UTRAN cell, i.e. a shrinking of the EUTRAN cell in active mode. Decreasing the value of this parameter would: Determine a later selection of UTRAN cell, which is similar with a shrinking of the UTRAN cell. KPI Impact: Mobility - low values of this parameter might create coverage discontinuity during selection operation due to shrinking UMTS cell as seen by the UE.

For optimization, a procedure containing the following steps can be used: Step 1: Set the value of thresholdEutraRsrpB2 to one of the following values {-104,-102,-100,-98,96}. Step 2: While performing a download with the UE, perform a drive test back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE Step 3: Repeat Step 2 for another value of thresholdEutraRsrpB2. Step 4: Post process the logged data and determine the positions at which the UE selected the UTRAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 145/194


15.1.2.5

MGR /TIPS /NEA

THRESHOLDUTRARSCP

This parameter sets the RSRP threshold for the target cell of the selection criteria in case of mobility towards UTRAN. Recommended Value= "-114"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a later selection of UTRAN cell, which is similar with a shrinking of the UTRAN cell in active mode. Decreasing the value of this parameter would: Determine an earlier selection of UTRAN cell, which is similar with a shrinking of the EUTRAN cel l. KPI Impact: Mobility - low values of this parameter might create coverage discontinuity during selection operation due to shrinking UMTS cell as seen by the UE.

For optimization, a procedure containing the following steps can be used: Step 1: Set the value of thresholdUtraRscp to one of the following values {-118,-116,-114,-112, 110}. Step 2: While performing a download with the UE, perform a drive test back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE Step 3: Repeat Step 2 for another value of thresholdUtraRscp. Step 4: Post process the logged data and determine the positions at which the UE selected the UTRAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.2.6

OFFSETFREQUTRA

This parameter is used to indicate a frequency specific offset to be applied when evaluating triggering conditions for measurement reporting. Recommended Value= "0"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine an earlier selection of UTRAN ce ll, which is similar with a shrinking of the EUTRAN cell in active mode. Decreasing the value of this parameter would: Determine a later selection of UTRAN cell, which is similar with a shrinking of the UTRAN cell.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 146/194


MGR /TIPS /NEA

KPI Impact: Mobility - low values of this parameter might allow the UE to determine the strongest cell later. High values of this parameter might allow the UE to determine the strongest cell earlier. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of offsetFreqUtra to one of the following values {-3,-2,-1, 0, 1, 2, 3}. Step 2: While performing a download with the UE, perform a drive test back and forth between the EUTRAN cell and UTRAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE Step 3: Repeat Step 2 for another value of offsetFreqUtra. Step 4: Post process the logged data and determine the positions at which the UE selected the UTRAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.2.7

FILTERCOEFFICIENTOFQUANTITYCONFIGUTRA

This parameter is used to configure the IE filterCoefficient of QuantityConfigUtra. The parameter is optional and is required only when inter-RAT mobility to UTRAN is supported. If this parameter is not configured (absent) then the default RRC value defined in 36.331 is used by the eNB and signalled to the UE. The RSRP values reported by the UE are obtained by filtering several measurements performed by the UE. If this filter can allow quick variation to be reported or it can rely more on the last reported value and less on the measured value such that there is less variation in the sequence of the reported value. The higher the value of filterCoefficientOfQuantityUtra the smoother the reported measurement will be and consequently the less likely ping-ponging occurs between sectors during handover. Recommended Value= "fc4"

Expected behaviour when changing this parameter: Increasing the value of this parameter would: Decrease the variation in the reported RSRP value. Decrease ping-pong between the cells in case of handover conditions. Delay the speed at which the reported RSRP adapts to the RSRP variation. This might eventually slightly delay the HO, if the value of the parameter is too high. Improve the system behaviour regarding the throughput during HO. Decreasing the value of this parameter would: Increase the variation in the reported RSRP value due to noise. Increase the ping-pong between the cells in case of handover conditions due to variations in reported RSRP. Decrease the HO quality relative to throughput. Increase the speed at which the reported RSRP adapts to the RSRP variation. This might speed up the HO which could manifest as ping-pong. KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during HO operation. High values of this parameter might delay the HO and possible lead to lost connection to the serving cell.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 147/194


MGR /TIPS /NEA

Optimization of this parameter should be performed in conjunction with optimization of hysteresis and timeToTrigger parameters. Finding the optimum pair of ( filterCoefficientOfQuantityUtra, hysteresis, and timeToTrigger ) should consider the following steps: Step 1: Set the values of filterCoefficientOfQuantityUtra and to hysteresis and to timeToTrigger to one of the following {(fc4, 4,100), (fc5, 5, 80), (fc3, 3,200), (fc6, 6, 40)}, in both current cell and neighbour cell. Step 2: Perform a drive test while performing a download and log the throughput values and the position of the UE. Drive in and out of the current cell to the neighbour cell. Step 3: Repeat Step 2 for another pair of values of the three tested parameters. Step 4: Represent throughput vs. position (distance) (Service continuity), #HO-attempts, Success Rate/Failure Rate, #of Ping-pongs, HO interruption time for all pairs of tested values. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.2.8

HYSTERESIS

This IE is a parameter used within the entry and leave condition of an event triggered reporting condition. This is used to provision IE Hysteresis in IE ReportConfigInterRAT, in IE MeasConfig . This parameter defines the hysteresis used by the UE to trigger an inter-RAT event-triggered measurement report. It is used in several processes: Event B2 (Serving becomes worse than threshold1 and inter RAT neighbour becomes better than threshold2); Event B1 (Inter RAT neighbour becomes better than threshold); Event A1 (Serving becomes better than threshold); Event A2 (Serving becomes worse than threshold); Event A3 (Neighbour becomes offset better than serving); Event A4 (Neighbour becomes better than threshold); Event A5 (Serving becomes worse than threshold1 and neighbour becomes better than threshold2).


Expected behaviour when changing this parameter Increasing the value of this parameter would: Delay the HO due to the more important difference that must exist between the serving cell and neighbour cell. Drop the call if the value is too large i.e. connection to the serving cell is lost before having reached the neighbour cell level that satisfies the HO condition. Decreasing the value of this parameter would: Create a ping – pong behaviour because the measurement quick variations (noise-like) might trigger HO decisions. KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during HO operation. High values of this parameter might delay the HO and possible lead to lost connection to the serving cell. Throughput - low values of this parameter can generate a ping pong behaviour which can result in interruption times and low throughput during HO operation.

Optimization of this parameter should be performed in conjunction with optimization of filterCoefficientOfQuantityUtra and timeToTrigger parameters, as presented in the previous paragraph.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 148/194


15.1.2.9

MGR /TIPS /NEA

TIMETOTRIGGER

This parameter sets the time duration time during which the conditions to trigger an event report have to be satisfied before sending a RRC measurement report in event triggered mode. Recommended Value= "ms100"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Delay the HO decision. Determine a call drop due to significant serving cell signal degradation before timeToTrigger expires. Decreasing the value of this parameter would: Generate ping-pong HO behaviour due to the fact that quick variations of the measured signal (noise-like variations) might satisfy the HO relation for the short while represented by timeToTrigger but not much longer.

KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during HO operation. High values of this parameter might delay the HO and possible lead to lost connection to the serving cell.

This parameter should be carefully optimized, best in conjunction with filterCoefficientOfQuantityUtra and hysteresis as presented in paragraph 12.4.2.4 . Indeed, the optimized value can be impacted by the load of the surrounding cells. Note: LGE UE RSRP filtering is every 100ms, which means that any time-to-trigger value equal or above 100ms is indeed significant. The only reason to have ms40 is to be sure that we will take the first RSRP reporting into consideration in case it is before the 100ms.

15.1.2.10 REPORTINTERVAL This parameter configures the IE reportInterval included in the IE ReportConfigInterRAT in the MeasConfig IE. The ReportInterval indicates the interval between periodical reports. The ReportInterval is applicable if the UE performs periodical reporting (i.e. when reportAmount exceeds 1), for triggerType „event‟ as well as for triggerType „periodical‟. Recommended Value= "ms240" Expected behaviour when changing this parameter Increasing the value of this parameter would: Increase the Handover Success Rate for multiple repe titions in bad RF conditions. Decreasing the value of this parameter would: Decrease the Handover Success Rate for multiple repetitions in bad RF conditions.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 149/194


MGR /TIPS /NEA

KPI Impa Impacct: Mobility – low low valu values es of this this para parame mete terr will ill decr decrea ease se the the HO succ succes esss rate. ate. High valu values es of thi this para parame mete terr will will incr increa ease se the the Ho succ succes esss rate rate.. A procedure that optimizes reportInterval would contain the following steps: Step 1: Set the value of reportInterval to one of the following values {120, 240, 480, 640, 1024, and 2048}. Step 2: perform a drive test back and forth between the EUTRAN cell and UTRAN cell on various routes and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of reportInterval. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.2.11 MAXREPORTCELLS This parameter defines the maximum number of cells to be reported in a measurement report. Recommended Value= "1"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to report as many new neighbour cells as possible in a short time. Decreasing the value of this parameter would: Determine the UE to report fewer neighbour cells. KPI Impact: Mobility – low values of this parameter allow the UE to report fewer neighbour cells. High values of this parameter allow the UE to report more neighbour cells. A procedure that optimizes maxReportCells would contain the following steps: Step 1: Set the value of maxReportCells to one of the following values {1, 2, 3, 4, 5, 6, 7, and 8}. Step 2: perform a drive test back and forth between the EUTRAN cell and UTRAN cell on various routes and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of maxReportCells. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

15.1.2.12 REPORTAMOUNT This parameter configures the number of periodical reports the UE has to transmit after the event was triggered. Recommended Value= "r8"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Increase the Handover Success Rate for multiple repe titions in bad RF conditions. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction


V05.03 / EN

Approved-Standard

30/Mar/2012

Page 150/194


MGR /TIPS /NEA

Decreasing the value of this parameter would: Decrease the Handover Success Rate for multiple repetitions in bad RF conditions. KPI Impact: Mobility – low values of this parameter allow the UE to report fewer neighbour cells. High values of this parameter allow the UE to report more neighbour cells. A procedure that optimizes reportAmount would contain the following steps: Step 1: Set the value of reportAmount to one of the following values {r1, r2, r4, r8, r16, r32, r64}. Step 2: Perform a drive test back and forth between the EUTRAN cell and UTRAN cell on various routes and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of reportAmount. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.



V05.03 / EN

Approved-Standard

30/Mar/2012

Page 151/194


MGR /TIPS /NEA

15.1.3 CALL FLOW FOR REDIRECTION TO UTRAN UE

Source ENB

Source MME

Triggers: - an A2 measurement measurement report is received received - a B2 measurement measurement report is received received - a CS Fallback Fallback is triggered triggered

Redirection and Release Initiation RRC CONNECTION RELEASE releaseCause::=other redirectedCarrierInfo::=utra-FDD redirectedCarrierInfo::= utra-FDD or utra-TDD > ARFCN-ValueUTRA (optional) cellInfoListUTRA-FDD-r9

UE CONTEXT RELEASE REQUEST MME-UE-S1AP-ID ENB-UE-S1AP-ID Cause=interrat-redirection Cause=interrat-redirection

The UE selects a suitable cell on the UTRAN frequency indicated by the RedirectedCarrierInfo

UE CONTEXT RELEASE COMMAND

Release Completion

ENB releases the UE context and associated resources

MME-UE-S1AP-ID ENB-UE-S1AP-ID Cause=normal-release

UE CONTEXT RELEASE COMPLETE MME-UE-S1AP-ID ENB-UE-S1AP-ID MME keeps the UE context

MME releases associated S1 resources

UE

Source ENB

Source MME

Figure 15.1-10: Call flow for redirection from EUTRAN to UTRAN



V05.03 / EN

Approved-Standard

30/Mar/2012

Page 152/194


MGR /TIPS /NEA

15.1.4 CALL FLOW FOR PS HO PREPARATION PHASE

Figure 15.1-11: Call flow for PS HO – Preparation phase

15.1.5 CALL FLOW FOR PS HO EXCUTION PHASE

Figure 15.1-12: Call flow for PS HO – Execution phase Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 153/194


MGR /TIPS /NEA

15.2 LTE-GSM MOBILITY OPTIMIZATION HINTS Mobility from LTE to GSM has been implemented in three forms: Cell reselection and redirection (blind or measurement based redirection) LTE to GERAN mobility capability for a dual-mode UE in both RRC idle and connected modes. Cell Change Order mobility procedure & Network Assisted Cell Change from EUTRAN to GERAN. This feature supports basic mobility for UE moving from LTE radio coverage to GSM radio coverage. The capability provided by this feature enables the LTE-to-GSM mobility of a dual-mode UE in RRC_IDLE mode, which allows a UE leaving LTE coverage to recover service in GSM coverage, as soon as it gets available, i.e. radio conditions are sufficiently good. It also enables LTE-to-GSM mobility in RRC_CONNECTED with packet data session that is the leaving of an LTE coverage island, while the user is moving this done via PS Handover procedure. The triggering condition is because of radio conditions on LTE being degraded. Release/Redirect mechanism is supported to accommodate the scenarios where the optimized HO procedures. CCO with or without Network Assisted Cell Change (NACC) mechanism is supported. CCO mechanism is supported to accommodate the scenarios where the optimized PS-HO procedure is not supported in the UE, or the ePC Core, or the GERAN network during early deployment.

15.2.1 IDLE MODE

For cell reselection the UE must be in RRC-IDLE mode and to be GERAN capable. It shall receive the information about GERAN coverage through SIB7 message. Then the UE applies inter-RAT cell reselection criteria.

Figure 15.2-1: Reselection from eUTRAN to GERAN



V05.03 / EN

Approved-Standard

30/Mar/2012

Page 154/194


MGR /TIPS /NEA

Figure 15.2-2: LTE to GERAN Mobility – HO to GERAN cell

3GPP rules: SservingCell > 0 where SservingCell = Qrxlevmeas – (Qrxlevmin + Qrxlevminoffset) - Pcompensation * Pcompensation = compensation factor to penalize the low power UEs = 0 Let„s consider: IF SServingCell > Snonintrasearch -> UE choose to not perform i nter-RAT measurements If SServingCell ≤ Snonintrasearch -> UE shall perform inter-RAT measurements ... Now using parameters ... IF Qrxlevmeas > Qrxlevmin + Qrxlevminoffset + Snonintrasearch -> UE does not measures IF Qrxlevmeas Qrxlevmeas ≤ Qrxlevmin + Qrxlevminoffset + Snonintrasearch -> UE measures Measurement Measurement phase

RSRP

> Qrxlevmin + Qrxlevminoffset + Snonintrasearch ≤ Qrxlevmin + Qrxlevminoffset + Snonintrasearch Measurement phase

Figure 15.2-3: LTE to GERAN Mobility (RSRP v s. Time) – Cell Reselection – Measurement phase Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction


V05.03 / EN

Approved-Standard

30/Mar/2012

Page 155/194


MGR /TIPS /NEA

UE will reselect the new cell if the conditions below are met: Sservingcell < threshServingLow and SnonServingCell > threshXLow during tReselectionGeran No cell with higher priority than the serving will fulfil the condition: SnonServingCell > threshXHigh during tReselectionGeran More than 1 second(s) has elapsed since the UE camped on the current serving cell.

Figure 15.2-4: LTE to GERAN Mobility – Cell Reselection toward lower priority GERAN cell Step 1: Serving cell become less good and the RSRP level decrease under [Qrxlevmin(SIB3)+sNonIntraSearch]. Then Measurement GAP is activated and the UE can detect and measure lower priority cells than the serving. Step 2: Serving cell becomes worse and the RSRP level decrease under [Qrxlevmin(SIB3)+threshServingLow]. Cell reselection would be possible, but not yet candidate cell, reaching [Qrxlevmin+Qrxlevminoffset +Pcompensation+threshXLow]. In this user case, 1 and 2 occur at the same time because b ecause we have chosen to implement sNonIntraSearch= threshServingLow. Step 3: The situation just above is still reached and also, in the target cell, threshold [Qrxlevmin+Qrxlevminoffset+Pcompensation+threshXLow] [Qrxlevmin+Qrxlevminoffset+Pcompen sation+threshXLow] is reached. tReselectionGeran is started. During tReselectionGeran, NO higher [Qrxlevmin+Qrxlevminoffset+Pcompensation+threshXHigh]

cell

priority

reaches

Step 4: tReselectionGeran is achieved, reselection is triggered.



V05.03 / EN

Approved-Standard

30/Mar/2012

Page 156/194


MGR /TIPS /NEA

Figure 15.2-3: LTE to GERAN Mobility (RSRP vs. Time) – Cell Reselection – Decision phase

15.2.1.1

QRXLEVMIN

Clarifications regarding qRxLevMin: A parameter with this name appear in several objects and is then transmitted to UE inside several system information block types i.e. Sibs: CellSelectionReselectionConf – transmitted in SIB1 and SIB3 CellReselectionConfUtraFdd – transmitted in SIB6 CellReselectionConfUtraTdd – transmitted in SIB6 CellReselectionConfGERAN – transmitted in SIB7 The LTE – GERAN mobility is using two of them, the one sent in SIB3 and the one sent in SIB7. The IE SystemInformationBlockType3 contains cell re-selection information common for intrafrequency, inter-frequency and/or inter-RAT cell re-selection (i.e. applicable for more than one type of cell re-selection but not necessarily all) as well as intra-frequency cell re-selection information other than neighbouring cell related. The IE SystemInformationBlockType7 contains information relevant only for inter- RAT cell reselection i.e. information about GERAN frequencies relevant for cell re -selection. This parameter configures the minimum required RSRP level in the GERAN cell, used by the UE in cell reselection.

Recommended Value= "-101"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a delayed selection of GERAN cell, i.e. a shrinking of the GERAN cell in idle mode. Decreasing the value of this parameter would: Determine an early selection of GERAN cell which is similar to a shrinking of the EUTRAN cell.

KPI Impact: Mobility - high values might create coverage discontinuity in idle, as seen by UE.

The optimization process should contain the following steps: Step 1: Set the value of qRxLevMin to one of the following values {- 105, -103, -101, -99, -97}. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 157/194


MGR /TIPS /NEA

Step 2: With UE in idle mode, perform a drive test back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qRxLevMin and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the GERAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.1.2

SNONINTRASEARCH

This parameter is used for setting a threshold for the selection criterion, threshold that would determine when, based in serving cell field level, the UE starts performing measurements for interfrequency and inter-RAT measurements. It is used for cell reselection. Recommended Value= "16" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start earlier the measurement for inter-RAT reselection which will probably empty the UE battery sooner. Decreasing the value of this parameter would: Determine the UE to start later the measurements for inter-RAT reselection. Possible impact correct and timely reselection for high speed UEs.

KPI Impact: Mobility - low values delay the start of measurements performed by the UE which can be reflected in delayed reselection. The optimization process should contain the following steps: Step 1: Set the value of sNonIntraSearch to one of the following values {12, 14, 16, 18, and 20}. Step 2: With UE in idle mode, perform a drive test back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another sNonIntraSearch and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the GERAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.1.3

THRESHSERVINGLOW

This threshold is used when the mobility towards lower priority frequency is taken in consideration. The default priority for GERAN frequency is lower than for EUTRAN frequency which implies that this parameter is used each time mobility towards GERAN happens. This parameter sets the threshold of the selection criteria in case of mobility towards lower priority RAT. The reselection criterion is quite a complex one which means that the optimization of this parameter would need some decoupling to be performed and the optimization to be made one parameter at a time. There is a condition on the serving cell through threshServingLow , another one on target cell through threshXLow and another one on time through tReselectionRAT . The parameter discussed here only impacts the part related to the serving cell. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 158/194


MGR /TIPS /NEA

The condition on the serving cell can be rewritten as a condition on the measured level in the serving cell as follows: Qrelevmeas qRxLevMin threshServingLow The optimization of threshServingLow is based on this relation.

Recommended Value= "16" Expected behaviour when changing this parameter Increasing the value of this parameter could: Determine an earlier selection of GERAN cell, i.e. a shrinking of the EUTRAN cell in idle mode. Indeed, it is possible that modifying the value of this parameter in a given range does not in fact impact the selection due to possibly stronger condition on the GERAN cell. Decreasing the value of this parameter would: Determine a later selection of GERAN cell which is similar to a shrinking of the GERAN cell. The similar observation made above, regarding the condition that ultimately triggers the selection is applicable for this situation as well. KPI Impact: Mobility - low values delay the start of measurements performed by the UE which can be reflected in delayed reselection. Coverage – high values might create coverage discontinuity during reselection operation.

Optimization of this parameter, in conjunction with threshXLow should aim at obtaining the cell sizes for both GERAN cell and EUTRAN cell both in active and in idle mode. Once the cells are correctly dimensioned for active mode, the optimization for idle mode parameters can be performed. The optimization of threshServingLow should be decoupled from the optimization for threshXLow . For this, the value of threshXLow should be the minimum allowed such that the first inequality of the selection criteria is satisfied for the largest surface of the cell. Once this is realized, the selection will always be triggered by the value of threshServingLow . The optimization process should contain the following steps (it is supposed that the sizes of cells in active mode are known): Step 1: Set the value of threshServingLow to one of the following values {0, 6, 12, 18, and 24}. Step 2: With UE in idle mode, perform a drive test back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another threshServingLow and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the GERAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.1.4

THRESHXLOW

This threshold is used when the mobility towards lower priority frequency is taken in consideration. The default priority for GERAN frequency is lower than for EUTRAN frequency which implies that this parameter is used each time mobility towards GERAN happens. This parameter sets the threshold of the selection criteria in case of mobility towards lower priority RAT. The reselection criterion is quite a complex one which means that the optimization of this parameter would need some decoupling to be performed and the optimization to be made one parameter at a time. There is a condition on the serving cell through threshServingLow , another one on target cell through threshXLow and another one on time through tReselectionRAT . The parameter discussed here only impacts the part related to the serving cell. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 159/194


MGR /TIPS /NEA

The condition on the serving cell can be rewritten as a condition on the measured level in the serving cell as follows:

Q relevmeas > Q rxlevmin + Pcompensation + threshXLow The optimization of threshXLow is based on this relation. Recommended Value= "0"

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine an earlier selection of GERAN cell, i.e. a shrinking of the EUTRAN cell in idle mode. Indeed, it is possible that modifying the value of this parameter in a given range does not in fact impact the selection due to possibly stronger condition on the EUTRAN cell. Decreasing the value of this parameter would: Determine a later selection of GERAN cell which is similar to a shrinking of the GERAN cell. The similar observation made above, regarding the condition that ultimately triggers the selection is applicable for this situation as well. KPI Impact: Mobility - high values might create coverage discontinuity during reselection operation due to shrinking GSM cell as seen by the UE.

Optimization of this parameter, in conjunction with threshServingLow should aim at obtaining the cell sizes for both GERAN cell and EUTRAN cell both in active and in idle mode. Once the cells are correctly dimensioned for active mode, the optimization for idle mode parameters can be performed. The optimization of threshXLow should be decoupled from the optimization for threshServingLow . For this, the value of threshServingLow should be the minimum allowed such that the first inequality of the selection criteria is satisfied for the largest surface of the cell. Once this is realized, the selection will always be triggered by the value of threshXLow . The optimization process should contain the following steps (it is supposed that the sizes of cells in active mode are known): Step 1: Set the value of threshXLow to one of the following values {0, 6, 12, 18, and 24}. Step 2: With UE in idle mode, perform a drive test back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another threshXLow and repeat Step 2. Step 4: Post process the logged data and determine the positions at which the UE selected the GERAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.1.5

TRESELECTIONGERAN

This parameter concerns the cell reselection timer tReselectionRAT for GERAN. Broadcast in SystemInformationBlockType7. It imposes a condition on the reselection. UE will actually reselect the new cell, only if the new cell is better ranked than the serving cel l during a time interval tReselectionGERAN . Recommended Value= "2" Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 160/194


MGR /TIPS /NEA

Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a delayed reselection which could be an issue for fast moving UEs. Decreasing the value of this parameter would: Facilitate ping-pong behaviour during reselection process. KPI Impact: Mobility - low values of this parameter might allow ping-pong behaviour during reselection operation. High values of this parameter might delay the reselection and possible lead to lost connection to the serving cell. Optimization of this parameter should find a trade-off between delayed reselection and ping pong behaviour. Most probably, if the UEs are not moving fast, the delayed reselection would not be an issue. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionGERAN to one of the following values {1, 2, 3, and 4}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and GERAN cell on various routes and log the reselection - related messages and the position of the UE. Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionGERAN. Step 4: Post-process the logs and analyze them as reselection position vs. tReselectionGERAN values and ping pong behaviour vs. tReselectionGERAN values and choose the optimized value to obtain smallest interruption time and highest success rate. Step 5: Calculate the HO success rate in each direction.

15.2.1.6

TRESELECTIONGERANSFMEDIUM

This parameter contributes to the configuration of the IE SystemInformationBlockType7 if the UE is in Medium Mobility state. The concerned mobility control related parameter is multiplied with this factor if the UE is in Medium Mobility state as defined in TS 36.304. This parameter avoids ping pong radio phenomena during the RA-Update & idle mobility. Recommended Value= "oDot25" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter will determine the UE to start reselection later. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionGERANSfMedium to one of the following values {0.25, 0.5, 0.75, and 1}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and GERAN cell on various routes and log the reselection - related messages and the position of the UE. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 161/194


MGR /TIPS /NEA

Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionGERANSfMedium. Step 4: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.1.7

TRESELECTIONGERANSFHIGH

This parameter contributes to the configuration of the IE SystemInformationBlockType7 if the UE is in High Mobility state. The concerned mobility control related parameter is multiplied with this factor if the UE is in High Mobility state as defined in TS 36.304. This parameter avoids ping pong radio phenomena during the RA-Update & idle mobility. Recommended Value= "oDot25" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier.

KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter will determine the UE to start reselection later. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionGERANSfHigh to one of the following values {0.25, 0.5, 0.75, and 1}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and GERAN cell on various routes and log the reselection - related messages and the position of the UE. Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionGERANSfHigh. Step 4: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.1.8

NCELLCHANGEHIGH

This parameter configures the number of cell changes to enter high mobility state Recommended Value= "12"



LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 162/194


MGR /TIPS /NEA

KPI Impact: Mobility - low values of this parameter will determine determine the UE to start reselection reselection earlier. High values of this parameter will determine the UE to start reselection later. A procedure that optimizes nCellChangeHigh would contain the following steps: Step 1: Set the value of nCellChangeHigh to one of the following values {10,11,12,13,and 14}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another nCellChangeHigh and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.1.9

NCELLCHANGEMEDIUM

This parameter configures the number of cell changes to enter medium mobility state Recommended Value= "4" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine determine the UE to start reselection reselection earlier. High values of this parameter will determine the UE to start reselection later. A procedure that optimizes nCellChangeMedium would contain the following steps: Step 1: Set the value of nCellChangeMedium to one of the following values {1, 2, 3, 4, 5, and 6}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another nCellChangeMedium and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.1.10 QHYSTSFHIGH This parameter contributes to the configuration of the IE SystemInformationBlockType3.This parameter configures the IE sf-High included in the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for Qhyst” in TS 36.304. The sf -High -High concerns the additional hysteresis to be applied, in High Mobility state , to Qhyst as defined in TS 36.304 state. This parameter is an environment dependent parameter. This parameter configures the hysteresis value of the serving cell used by the UE for ranking criteria in cell reselection. Recommended Value= "dB-6" Expected behaviour when changing this parameter Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction


V05.03 / EN

Approved-Standard

30/Mar/2012

Page 163/194


MGR /TIPS /NEA

Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter might might allow the UE to start reselection reselection earlier. High values of this parameter might allow the UE to start reselection later. A procedure that optimizes qHystSfHigh would contain the following steps: Step 1: Set the value of qHystSfHigh to one of the following values {dB-6, dB-4, dB-2, dB0}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qHystSfHigh and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.1.11 QHYSTSFMEDIUM This parameter contributes to the configuration of the IE SystemInformationBlockType3.This parameter configures the IE sf-Medium included in the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for Qhyst” in TS 36.304. The sf -High -High concerns the additional hysteresis to be applied, in Medium Mobility state, to Qhyst as defined in TS 36.304 state. This parameter is an environment dependent parameter. This parameter configures the hysteresis value of the serving cell used by the UE for ranking criteria in cell reselection. Recommended Value= "dB-6" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter might might allow the UE to start reselection reselection earlier. High values of this parameter might allow the UE to start reselection later. A procedure that optimizes qHystSfMedium would contain the following steps: Step 1: Set the value of qHystSfMedium to one of the following values {dB-6, dB-4, dB-2, dB0}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qHystSfMedium and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.



V05.03 / EN

Approved-Standard

30/Mar/2012

Page 164/194


MGR /TIPS /NEA

15.2.2 ACTIVE MODE If eNB receives an event B2 measurement report from UE with measurementPurpose = MobilityInter-RAT-to-GERAN, but the Cell Change Order to GERAN is not supported by the UE or is not activated in eNB, a measurement based redirection from LTE to GERAN is triggered. Event B2 – Serving becomes worse than threshold1 and inter-RAT neighbour becomes better than threshold2. Entering conditions for this event:

& Ms = measurement result of the serving cell [dBm] Hys = reportConfigGERAN:: hysteresis [dB] Thresh1 = ReportConfigGERAN:: thresholdEutraRsrpB2 [dBm] Mn = measurement result of the inter-RAT neighbour cell [dBm] Ofn = MeasObjectGERAN::offsetFreq , corresponding to the neighbouring cell [dB] Thresh2 = ReportConfigGERAN::thresholdUtraGeran [dBm]


15.2.2.1


This parameter sets the RSRP threshold for the serving cell of the selection criteria in case of CCO with NACC towards GERAN.



V05.03 / EN

Approved-Standard

30/Mar/2012

Page 165/194


MGR /TIPS /NEA

Recommended Value= "-100" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine an earlier selection of GERAN cell, i.e. a shrinking of the EUTRAN cell in active mode. Decreasing the value of this parameter would: Determine a later selection of GERAN ce ll, which is similar with a shrinking of the GERAN cell. KPI Impact: Mobility - low values of this parameter might create coverage discontinuity during selection operation due to shrinking GSM cell as seen by the UE. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of thresholdEutraRsrpB2 to one of the following values {-104,-102,-100,-98,96}. Step 2: While performing a download with the UE, perform a drive test back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE Step 3: Repeat Step 2 for another value of thresholdEutraRsrpB2. Step 4: Post process the logged data and determine the positions at which the UE selected the GERAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.2.2

THRESHOLDGERAN

This parameter sets the RSRP threshold for the target cell of the selection criteria in case of CCO with NACC towards GERAN. Recommended Value= "-110" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a later selection of GERAN cell, which is similar with a shrinking of the GERAN cell in active mode. Decreasing the value of this parameter would: Determine an earlier selection of GERAN cell, which is similar with a shrinking of the EUTRAN cell. KPI Impact: Mobility - low values of this parameter might create coverage discontinuity during selection operation due to shrinking GSM cell as seen by the UE. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of thresholdGeran to one of the following values {-114,-112,-110,-108, -106,104}. Step 2: While performing a download with the UE, perform a drive test back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE Step 3: Repeat Step 2 for another value of thresholdGeran. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 166/194


MGR /TIPS /NEA

Step 4: Post process the logged data and determine the positions at which the UE selected the GERAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.2.3

OFFSETFREQGERAN

This parameter is used to indicate a frequency specific offset to be applied when evaluating triggering conditions for measurement reporting. Recommended Value= "0" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine an earlier selection of GERAN cell, w hich is similar with a shrinking of the EUTRAN cell in active mode. Decreasing the value of this parameter would: Determine a later selection of GERAN ce ll, which is similar with a shrinking of the GERAN cell. KPI Impact: Mobility - low values of this parameter might allow the UE to determine the strongest cell later. High values of this parameter might allow the UE to determine the strongest cell earlier. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of offsetFreqGERAN to one of the following values {-3,-2,-1, 0, 1, 2, 3}. Step 2: While performing a download with the UE, perform a drive test back and forth between the EUTRAN cell and GERAN cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE Step 3: Repeat Step 2 for another value of offsetFreqGERAN. Step 4: Post process the logged data and determine the positions at which the UE selected the GERAN cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.2.4

FILTERCOEFFICIENTOFQUANTITYCONFIGGERAN

This parameter is used to configure the IE filterCorefficient of QuantityConfigGERAN. The parameter is optional and is required only when inter-RAT mobility to GERAN is supported. If this parameter is not configured (absent) then the default RRC value defined in 36.331 is used by the eNB and signalled to the UE. The RSRP values reported by the UE are obtained by filtering several measurements performed by the UE. If this filter can allow quick variation to be reported or it can rely more on the last reported value and less on the measured value such that there is less variation in the sequence of the reported value. The higher the value of filterCoefficientOfQuantityGERAN the smoother the reported measurement will be and consequently the less likely ping-ponging occurs between sectors during handover. Recommended Value= "fc2" Expected behaviour when changing this parameter: Increasing the value of this parameter would: Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 167/194


MGR /TIPS /NEA

Decrease the variation in the reported RSRP value. Decrease ping-pong between the cells in case of handover conditions. Delay the speed at which the reported RSRP adapts to the RSRP variation. This might eventually slightly delay the HO, if the value of the parameter is too high. Improve the system behaviour regarding the throughput during HO. Decreasing the value of this parameter would: Increase the variation in the reported RSRP value due to noise. Increase the ping-pong between the cells in case of handover conditions due to variations in reported RSRP. Decrease the HO quality relative to throughput. Increase the speed at which the reported RSRP adapts to the RSRP variation. This might speed up the HO which could manifest as ping-pong. KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during HO operation. High values of this parameter might delay the HO and possible lead to lost connection to the serving cell. Optimization of this parameter should be performed in conjunction with optimization of hysteresis and timeToTrigger parameters. Finding the optimum pair of ( filterCoefficientOfQuantityGERAN, hysteresis, timeToTrigger ) should consider the following steps: Step 1: Set the values of filterCoefficientOfQuantityGERAN and to hysteresis and to timeToTrigger to one of the following {(fc2, 3,100), (fc3, 4, 80), (fc4, 5,200), (fc1, 2, 40)}, in both current cell and neighbour cell. Step 2: Perform a drive test while performing a download and log the throughput values and the position of the UE. Drive in and out of the current cell to the neighbour cell. Step 3: Repeat Step 2 for another pair of values of the three tested parameters. Step 4: Represent throughput vs. position (distance) (Service continuity), #HO-attempts, Success Rate/Failure Rate, #of Ping-pongs, HO interruption time for all pairs of tested values. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.2.5

HYSTERESIS

This IE is a parameter used within the entry and leave condition of an event triggered reporting condition. This is used to provision IE Hysteresis in IE ReportConfigInterRAT, in IE MeasConfig . This parameter defines the hysteresis used by the UE to trigger an inter-RAT event-triggered measurement report. It is used in several processes: Event B2 (Serving becomes worse than threshold1 and inter RAT neighbour becomes better than threshold2); Event B1 (Inter RAT neighbour becomes better than threshold); Event A1 (Serving becomes better than threshold); Event A2 (Serving becomes worse than threshold); Event A3 (Neighbour becomes offset better than serving); Event A4 (Neighbour becomes better than threshold); Event A5 (Serving becomes worse than threshold1 and neighbour becomes better than threshold2). Recommended Value= "3" Expected behaviour when changing this parameter Increasing the value of this parameter would: Delay the HO due to the more important difference that must exist between the serving cell and neighbour cell. Drop the call if the value is too large i.e. connection to the serving cell is lost before having reached the neighbour cell level that satisfies the HO condition. Decreasing the value of this parameter would: Create a ping – pong behaviour because the measurement quick variations (noise-like) might trigger HO decisions. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 168/194


MGR /TIPS /NEA

KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during HO operation. High values of this parameter might delay the HO and possible lead to lost connection to the serving cell. Throughput - low values of this parameter can generate a ping pong behaviour which can result in interruption times and low throughput during HO operation.

Optimization of this parameter should be performed in conjunction with optimization of filterCoefficientOfQuantityGERAN and timeToTrigger parameters, as presented in the previous paragraph.

15.2.2.6

TIMETOTRIGGER

This parameter sets the time duration time during which the conditions to trigger an event report have to be satisfied before sending a RRC measurement report in event triggered mode. Recommended Value= "ms100" Expected behaviour when changing this parameter Increasing the value of this parameter would: Delay the HO decision. Determine a call drop due to significant serving cell signal degradation before timeToTrigger expires. Decreasing the value of this parameter would: Generate ping-pong HO behaviour due to the fact that quick variations of the measured signal (noise-like variations) might satisfy the HO relation for the short while represented by timeToTrigger but not much longer. KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during HO operation. High values of this parameter might delay the HO and possible lead to lost connection to the serving cell. This parameter should be carefully optimized, best in conjunction with filterCoefficientOfQuantityGERAN and hysteresis as presented in paragraph 12.4.9 . Indeed, the optimized value can be impacted by the load of the surrounding cells. Note: LGE UE RSRP filtering is every 100ms, which means that any time-to-trigger value equal or above 100ms is indeed significant. The only reason to have ms40 is to be sure that we will take the first RSRP reporting into consideration in case it is before the 100ms.

15.2.2.7

REPORTINTERVAL

This parameter configures the IE reportInterval included in the IE ReportConfigInterRAT in the MeasConfig IE. The ReportInterval indicates the interval between periodical reports. The ReportInterval is applicable if the UE performs periodical reporting (i.e. when reportAmount exceeds 1), for triggerType „event‟ as well as for triggerType „periodical‟. Recommended Value= "ms240" Expected behaviour when changing this parameter Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 169/194


MGR /TIPS /NEA

Increasing the value of this parameter would: Increase the Handover Success Rate for multiple repe titions in bad RF conditions. Decreasing the value of this parameter would: Decrease the Handover Success Rate for multiple repetitions in bad RF conditions. KPI Impact: Mobility – low values of this parameter will decrease the HO success rate. High values of this parameter will increase the Ho success rate. A procedure that optimizes reportInterval would contain the following steps: Step 1: Set the value of reportInterval to one of the following values {120, 240, 480, 640, 1024, and 2048}. Step 2: perform a drive test back and forth between the EUTRAN cell and GERAN cell on various routes and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of reportInterval. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.2.8

MAXREPORTCELLS

This parameter defines the maximum number of cells to be reported in a measurement report. Recommended Value= "1" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to report as many new neighbour cells as possible in a short time. Decreasing the value of this parameter would: Determine the UE to report fewer neighbour cells. KPI Impact: Mobility – low values of this parameter allow the UE to report fewer neighbour cells. High values of this parameter allow the UE to report more neighbour cells. A procedure that optimizes maxReportCells would contain the following steps: Step 1: Set the value of maxReportCells to one of the following values {1, 2, 3, 4, 5, 6, 7, and 8}. Step 2: Perform a drive test back and forth between the EUTRAN cell and GERAN cell on various routes and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of maxReportCells. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.2.9

REPORTAMOUNT

This parameter configures the number of periodical reports the UE has to transmit after the event was triggered. Recommended Value= "r8" Expected behaviour when changing this parameter Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 170/194


MGR /TIPS /NEA

Increasing the value of this parameter would: Increase the Handover Success Rate for multiple repe titions in bad RF conditions. Decreasing the value of this parameter would: Decrease the Handover Success Rate for multiple repetitions in bad RF conditions. KPI Impact: Mobility – low values of this parameter allow the UE to report fewer neighbour cells. High values of this parameter allow the UE to report more neighbour cells. A procedure that optimizes reportAmount would contain the following steps: Step 1: Set the value of reportAmount to one of the following values {r1, r2, r4, r8, r16, r32, r64}. Step 2: Perform a drive test back and forth between the EUTRAN cell and GERAN cell on various routes and log the HO - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of reportAmount. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

15.2.3 CALL FLOW FOR REDIRECTION TO GERAN

Figure 15.2-3: Call Flow for Redirection to Geran Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 171/194


MGR /TIPS /NEA

15.2.4 CALL FLOW FOR CELL CHANGE ORDER WITH/WITHOUT NACC

Figure 15.2-4: Call Flow for Cell Change Order with /Without NACC

15.3 LTE-HRPD MOBILITY OPTIMIZATION HINTS 15.3.1 IDLE MODE In RRC_Idle mode the UE performs inter-RAT cell reselection based on cell signal quality measurements. Done by the UE under control from EUTRAN via System Information Broadcast 8.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 172/194


MGR /TIPS /NEA

Cell selection: the UE seeks to identify a suitable cell i.e. cell for which the measured cell

attributes satisfy the cell selection criteria ; if found it camps on that cell and starts the cell reselection procedure. Cell reselection: UE performs measurements of the serving and neighbour cells. The cell selection and reselection algorithms are controlled by setting of parameters (thresholds and hysteresis values) that define the best cell and/or determine when the UE should select a new cell. If a LTE cell is in the border area of the HRPD system, SystemInformationBlockType8 (SIB8) should be broadcasted in additional to SIB3 for UE to perform LTE to HRPD reselection. SIB8 contains the following three optional information blocks: systemTimeInfo searchWindowSize parametersHRPD In RRC_IDLE mode, the cell reselection is internal to UE and is controlled by the System Information Parameters provided in SIB8 if the reselection to HRPD is enabled (isMobilityToHrpdAllowed = TRUE). Any modification of SIB8 parameters triggers a dynamic system information modification procedure. IF SServingCell > Snonintrasearch -> UE choose to not perform i nter-RAT measurements IF SServingCell ≤ Snonintrasearch -> UE shall perform inter-RAT measurements

Measurement phase RSRP SServingCell ≤ Snonintrasearch SServingCell > Snonintrasearch Measurement phase

Figure 15.3-1: LTE to CDMA Mobility (RSRP vs. Time) – Cell Reselection – Measurement Phase

Decision phase

eHRPD Pilot Strength

RSRPs

Target cell reselection

tReselectionCdmaHr d Figure 15.3-2: LTE to CDMA Mobility (RSRP vs. Time) – Cell Reselection – Decision Phase UE will reselect the new LowPriority cell if the conditions below are met: • Sservingcell < CellReselectionConfLte::threshXLow and SnonServingCell > Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 173/194


MGR /TIPS /NEA

CellReselectionConfHrpd::threshXLow during tReselectionCdmaHrpd. & • NO cell on Serving Freq. OR equal priority EUTRAN freq. OR higher priority EUTRAN freq. OR iRAT freq. than the serving will fulfil the condition: SnonServingCell CellReselectionConfHrpd::threshXHigh during tReselectionCdmaHrpd. & • More than 1 second(s) has elapsed since the UE camped on the current serving cell.

15.3.1.1

>

SNONINTRASEARCH

This parameter is used for setting a threshold for the selection criterion, threshold that would determine when, based in serving cell field level, the UE starts performing measurements for interfrequency and inter-RAT measurements. It is used for cell reselection. Recommended Value= "16" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start earlier the measurement for inter-RAT reselection which will probably empty the UE battery sooner. Decreasing the value of this parameter would: Determine the UE to start later the measurements for inter-RAT reselection. Possible impact correct and timely reselection for high speed UEs. KPI Impact: Mobility - low values delay the start of measurements performed by the UE which can be reflected in delayed reselection.

The optimization process should contain the following steps: Step 1: Set the value of sNonIntraSearch to one of the following values {12, 14, 16, 18, and 20}. Step 2: With UE in idle mode, perform a drive test back and forth between the EUTRAN cell and HRPD cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another sNonIntraSearch and repeat Step 2. Step 4: Post process the logged data and dete rmine the positions at which the UE selected the HRPD cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.1.2

THRESHXLOW

This threshold is used when the mobility towards lower priority frequency is taken in consideration. The default priority for HRPD frequency is lower than for EUTRAN frequency which implies that this parameter is used each time mobility towards HRPD happens. This parameter sets the threshold of the selection criteria in case of mobility towards lower priority RAT. Recommended Value= "-2"

Expected behaviour when changing this parameter


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 174/194


MGR /TIPS /NEA

Increasing the value of this parameter would: Determine an earlier selection of HRPD cell, i.e. a shrinking of the EUTRAN cell in idle mode. Indeed, it is possible that modifying the value of this parameter in a given range does not in fact impact the selection due to possibly stronger condition on the EUTRAN cell. Decreasing the value of this parameter would: Determine a later selection of HRPD cell which is similar to a shrinking of the HRPD cell. The similar observation made above, regarding the condition that ultimately triggers the selection is applicable for this situation as well. KPI Impact: Mobility - high values might create coverage discontinuity during reselection operation due to shrinking HRPD cell as seen by the UE.

The optimization process should contain the following steps (it is supposed that the sizes of cells in active mode are known): Step 1: Set the value of threshXLow to one of the following values {0, 6, 12, 18, and 24}. Step 2: With UE in idle mode, perform a drive test back and forth between the EUTRAN cell and HRPD cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another threshXLow and repeat Step 2. Step 4: Post process the logged data and dete rmine the positions at which the UE selected the HRPD cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.1.3

TRESELECTIONCDMAHRPD

This parameter concerns the cell reselection timer tReselectionRAT for HRPD. Broadcast in SystemInformationBlockType8. It imposes a condition on the reselection. UE will actually reselect the new cell, only if the new cell is better ranked than the serving cell during a time interval tReselectionCdmaHrpd . Recommended Value= "2" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a delayed reselection which could be an issue for fast moving UEs. Decreasing the value of this parameter would: Facilitate ping-pong behaviour during reselection process. KPI Impact: Mobility - low values of this parameter might allow ping-pong behaviour during reselection operation. High values of this parameter might delay the reselection and possible lead to lost connection to the serving cell. Optimization of this parameter should find a trade-off between delayed reselection and ping pong behaviour. Most probably, if the UEs are not moving fast, the delayed reselection would not be an issue. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionCdmaHrpd to one of the following values {1, 2, 3, and 4}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and HRPD cell on various routes and log the reselection - related messages and the position of the UE. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 175/194


MGR /TIPS /NEA

Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionCdmaHrpd. Step 4: Post-process the logs and analyze them as reselection position vs. tReselectionCdmaHrpd values and ping pong behaviour vs. tReselectionCdmaHrpd values and choose the optimized value to obtain smallest interruption time and highest success rate. Step 5: Calculate the HO success rate in each direction.

15.3.1.4

TRESELECTIONHRPDSFMEDIUM

This parameter contributes to the configuration of the IE SystemInformationBlockType8 if the UE is in Medium Mobility state. The concerned mobility control related parameter is multiplied with this factor if the UE is in Medium Mobility state as defined in TS 36.304. This parameter avoids ping pong radio phenomena during the RA-Update & idle mobility. Recommended Value= "oDot25" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter will determine the UE to start reselection later. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionHRPDSfMedium to one of the following values {0.25, 0.5, 0.75, and 1}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and HRPD cell on various routes and log the reselection - related messages and the position of the UE. Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionHRPDSfMedium. Step 4: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.1.5

TRESELECTIONHRPDSFHIGH

This parameter contributes to the configuration of the IE SystemInformationBlockType8 if the UE is in High Mobility state. The concerned mobility control related parameter is multiplied with this factor if the UE is in High Mobility state as defined in TS 36.304. This parameter avoids ping pong radio phenomena during the RA-Update & idle mobility. Recommended Value= "oDot25" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 176/194


MGR /TIPS /NEA

Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter will determine the UE to start reselection later.

For optimization, a procedure containing the following steps can be used: Step 1: Set the value of tReselectionHRPDSfHigh to one of the following values {0.25, 0.5, 0.75, and 1}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and HRPD cell on various routes and log the reselection - related messages and the position of the UE. Perform this test 10 times in each direction. Make sure that the driving speed is nominal and the same for all the test samples. Step 3: Repeat Step 2 for another value of tReselectionHRPDSfHigh. Step 4: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.1.6

NCELLCHANGEHIGH

This parameter configures the number of cell changes to enter high mobility state Recommended Value= "12" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter will determine the UE to start reselection later.

A procedure that optimizes nCellChangeHigh would contain the following steps: Step 1: Set the value of nCellChangeHigh to one of the following values {10, 11, 12, 13, and 14}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and HRPD cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another nCellChangeHigh and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.1.7

NCELLCHANGEMEDIUM

This parameter configures the number of cell changes to enter medium mobility state Recommended Value= "4" Expected behaviour when changing this parameter Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 177/194


MGR /TIPS /NEA

Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter will determine the UE to start reselection later. A procedure that optimizes nCellChangeMedium would contain the following steps: Step 1: Set the value of nCellChangeMedium to one of the following values {1, 2, 3, 4, 5, and 6}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and HRPD cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another nCellChangeMedium and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.1.8

QHYSTSFHIGH

This parameter contributes to the configuration of the IE SystemInformationBlockType3.This parameter configures the IE sf-High included in the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for Qhyst” in TS 36.304. The sf -High concerns the additional hysteresis to be applied, in High Mobility state, to Qhyst as defined in TS 36.304 state. This parameter is an environment dependent parameter. This parameter configures the hysteresis value of the serving cell used by the UE for ranking criteria in cell reselection. Recommended Value= "dB-6" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter will determine the UE to start reselection later. A procedure that optimizes qHystSfHigh would contain the following steps: Step 1: Set the value of qHystSfHigh to one of the following values {dB-6, dB-4, dB-2, dB0}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and HRPD cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qHystSfHigh and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 178/194


15.3.1.9

MGR /TIPS /NEA

QHYSTSFMEDIUM

This parameter contributes to the configuration of the IE SystemInformationBlockType3.This parameter configures the IE sf-Medium included in the IE SpeedStateReselectionPars. Parameter “Speed dependent ScalingFactor for Qhyst” in TS 36.304. The sf -High concerns the additional hysteresis to be applied, in Medium Mobility state, to Qhyst as defined in TS 36.304 state. This parameter is an environment dependent parameter. This parameter configures the hysteresis value of the serving cell used by the UE for ranking criteria in cell reselection. Recommended Value= "dB-6" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to start cell reselection later. Decreasing the value of this parameter would: Determine the UE to start cell reselection earlier. KPI Impact: Mobility - low values of this parameter will determine the UE to start reselection earlier. High values of this parameter will determine the UE to start reselection later. A procedure that optimizes qHystSfMedium would contain the following steps: Step 1: Set the value of qHystSfMedium to one of the following values {dB-6, dB-4, dB-2, dB0}. Step 2: With the UE in idle mode, perform a drive back and forth between the EUTRAN cell and HRPD cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE. Step 3: Choose another qHystSfMedium and repeat Step 2. Step 4: Post process the logged data. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.2 ACTIVE MODE In RRC_Connected mode the UE sends to the eNB a measurement report associated with a configured inter-RAT measurement that was setup when it moved to an LTE border cell. When eNB receives a UE event B2 measurement report with measurementPurpose = ‘MobilityInter-RAT-to HRPD’, LTE to HRPD measurement based redirection procedure will be performed.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 179/194


MGR /TIPS /NEA

Fig.13.5.2-1: LTE to CDMA Mobility Event B2 – Serving becomes worse than threshold1 and inter-RAT neighbour becomes better than threshold2. Entering conditions for this event:

& Ms = measurement result of the serving cell [dBm] hysteresis = reportConfigCDMA2000::hysteresis [dB] Mn = measurement result of the inter-RAT neighbour cell [dBm] offsetFreq = MeasObjectCDMA2000:: offsetFreq , corresponding to the neighbouring cell [dB]


15.3.2.1


This parameter sets the RSRP threshold for the serving cell of the selection criteria in case of mobility towards CDMA2000. Recommended Value= "-113" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine an earlier selection of HRPD cell, i.e. a shrinking of the EUTRAN cell in active mode. Decreasing the value of this parameter would: Determine a later selection of HRPD cell, which is similar with a shrinking of the HRPD cell.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 180/194


MGR /TIPS /NEA

KPI Impact: Mobility - low values of this parameter might create coverage discontinuity during selection operation due to shrinking CDMA2000 cell as seen by the UE. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of thresholdEutraRsrpB2 to one of the following values {-104,-102,-100,-98,96}. Step 2: While performing a download with the UE, perform a drive test back and forth between the EUTRAN cell and HRPD cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE Step 3: Repeat Step 2 for another value of thresholdEutraRsrpB2. Step 4: Post process the logged data and dete rmine the positions at which the UE selected the HRPD cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.2.2

THRESHOLDCDMA2000

This parameter sets the RSRP threshold for the target cell of the selection criteria in case of mobility towards HRPD. Recommended Value= "-9" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine a later selection of HRPD cell, which is similar with a shrinking of the HRPD cell in active mode. Decreasing the value of this parameter would: Determine an earlier selection of HRPD cell, which is similar with a shrinking of the EUTRAN cell. KPI Impact: Mobility - high values might create coverage discontinuity during selection operation due to shrinking HRPD cell as seen by the UE For optimization, a procedure containing the following steps can be used: Step 1: Set the value of thresholdCDMA2000 to one of the fol lowing values {-13,-11,-9,-7,-5}. Step 2: While performing a download with the UE, perform a drive test back and forth between the EUTRAN cell and HRPD cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE Step 3: Repeat Step 2 for another value of thresholdCDMA2000. Step 4: Post process the logged data and dete rmine the positions at which the UE selected the HRPD cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.2.3

OFFSETFREQ

This parameter is used to indicate a frequency specific offset to be applied when evaluating triggering conditions for measurement reporting.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 181/194


MGR /TIPS /NEA

Recommended Value= "0" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine an earlier selection of HRPD cell, which is similar with a shrinking of the EUTRAN cell in active mode. Decreasing the value of this parameter would: Determine a later selection of HRPD cell, which is similar with a shrinking of the HRPD cell. KPI Impact: Mobility - low values of this parameter might allow the UE to determine the strongest cell later. High values of this parameter might allow the UE to determine the strongest cell earlier. For optimization, a procedure containing the following steps can be used: Step 1: Set the value of offsetFreq to one of the following values {-3,-2,-1, 0, 1, 2, 3}. Step 2: While performing a download with the UE, perform a drive test back and forth between the EUTRAN cell and HRPD cell on various routes and log the control messages exchanged between eNodeB and UE along with the GPS coordinates of the UE Step 3: Repeat Step 2 for another value of offsetFreq. Step 4: Post process the logged data and determine the positions at which the UE selected the HRPD cell. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.2.4

HYSTERESIS

This IE is a parameter used within the entry and leave condition of an event triggered reporting condition. This is used to provision IE Hysteresis in IE ReportConfigInterRAT, in IE MeasConfig . This parameter defines the hysteresis used by the UE to trigger an inter-RAT event-triggered measurement report. It is used in several processes: Event B2 (Serving becomes worse than threshold1 and inter RAT neighbour becomes better than threshold2); Event B1 (Inter RAT neighbour becomes better than threshold); Event A1 (Serving becomes better than threshold); Event A2 (Serving becomes worse than threshold); Event A3 (Neighbour becomes offset better than serving); Event A4 (Neighbour becomes better than threshold); Event A5 (Serving becomes worse than threshold1 and neighbour becomes better than threshold2). Recommended Value= "1" Expected behaviour when changing this parameter Increasing the value of this parameter would: Delay the redirection due to the more important difference that must exist between the serving cell and neighbour cell. Drop the call if the value is too large i.e. connection to the serving cell is lost before having reached the neighbour cell level that satisfies the redirection condition. Decreasing the value of this parameter would: Create a ping – pong behaviour because the measurement quick variations (noise-like) might trigger redirection decisions.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 182/194


MGR /TIPS /NEA

KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during redirection operation. High values of this parameter might delay the redirection and possible lead to lost connection to the serving cell. Throughput - low values of this parameter can generate a ping pong behaviour which can result in interruption times and low throughput during redirection operation.. Optimization of this parameter should be performed in conjunction with optimization of timeToTrigger parameter. Finding the optimum pair of ( hysteresis, timeToTrigger ) should consider the following steps: Step 1: Set the values of hysteresis and to timeToTrigger to one of the following {(2,100), (3, 80), (4,200), (1, 40)}, in both current cell and neighbour cell. Step 2: Perform a drive test while performing a download and log the throughput values and the position of the UE. Drive in and out of the current cell to the neighbour cell. Step 3: Repeat Step 2 for another pair of values of the three tested parameters. Step 4: Represent throughput vs. position (distance) (Service continuity), #redirection-attempts, Success Rate/Failure Rate, #of Ping-pongs, redirection interruption time for all pairs of tested values. Step 5: Choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.2.5

TIMETOTRIGGER

This parameter sets the time duration time during which the conditions to trigger an event report have to be satisfied before sending a RRC measurement report in event triggered mode. Recommended Value= "ms100" Expected behaviour when changing this parameter Increasing the value of this parameter would: Delay the redirection decision. Determine a call drop due to significant serving cell signal degradation before timeToTrigger expires. Decreasing the value of this parameter would: Generate ping-pong redirection behaviour due to the fact that quick variations of the measured signal (noise-like variations) might satisfy the redirection relation for the short while represented by timeToTrigger but not much longer. KPI Impact: Mobility – low values of this parameter might allow ping-pong behaviour during redirection operation. High values of this parameter might delay the redirection and possible lead to lost connection to the serving cell. This parameter should be carefully optimized, best in conjunction with hysteresis as presented in the previous paragraph . Indeed, the optimized value can be impacted by the load of the surrounding cells. Note: LGE UE RSRP filtering is every 100ms, which means that any time-to-trigger value equal or above 100ms is indeed significant. The only reason to have ms40 is to be sure that we will take the first RSRP reporting into consideration in case it is before the 100ms.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 183/194


15.3.2.6

MGR /TIPS /NEA

REPORTINTERVAL

This parameter configures the IE reportInterval included in the IE ReportConfigInterRAT in the MeasConfig IE. The ReportInterval indicates the interval between periodical reports. The ReportInterval is applicable if the UE performs periodical reporting (i.e. when reportAmount exceeds 1), for triggerType „event‟ as well as for triggerType „periodical‟. Recommended Value= "ms240" Expected behaviour when changing this parameter Increasing the value of this parameter would: Increase the Handover Success Rate for multiple repe titions in bad RF conditions. Decreasing the value of this parameter would: Decrease the Handover Success Rate for multiple repetitions in bad RF conditions. KPI Impact: Mobility – low values of this parameter will decrease the HO success rate. High values of this parameter will increase the Ho success rate. A procedure that optimizes reportInterval would contain the following steps: Step 1: Set the value of reportInterval to one of the following values {120, 240, 480, 640, 1024, and 2048}. Step 2: perform a drive test back and forth between the EUTRAN cell and HRPD cell on various routes and log the redirection - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of reportInterval. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.2.7

MAXREPORTCELLS

This parameter defines the maximum number of cells to be reported in a measurement report. Recommended Value= "2" Expected behaviour when changing this parameter Increasing the value of this parameter would: Determine the UE to report as many new neighbour cells as possible in a short time. Decreasing the value of this parameter would: Determine the UE to report fewer neighbour cells. KPI Impact: Mobility – low values of this parameter allow the UE to report fewer neighbour cells. High values of this parameter allow the UE to report more neighbour cells. A procedure that optimizes maxReportCells would contain the following steps: Step 1: Set the value of maxReportCells to one of the following values {1, 2, 3, 4, 5, 6, 7, and 8}. Step 2: perform a drive test back and forth between the EUTRAN cell and HRPD cell on various routes and log the redirection - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of maxReportCells. Alcatel-Lucent - Confidential - Solely for authorized persons having a need to know Proprietary - Use pursuant to Company instruction

LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 184/194


MGR /TIPS /NEA

Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.

15.3.2.8

REPORTAMOUNT

This parameter configures the number of periodical reports the UE has to transmit after the event was triggered. Recommended Value= "r8" Expected behaviour when changing this parameter Increasing the value of this parameter would: Increase the Handover Success Rate for multiple repe titions in bad RF conditions. Decreasing the value of this parameter would: Decrease the Handover Success Rate for multiple repetitions in bad RF conditions. KPI Impact: Mobility – low values of this parameter allow the UE to report fewer neighbour cells. High values of this parameter allow the UE to report more neighbour cells. A procedure that optimizes reportAmount would contain the following steps: Step 1: Set the value of reportAmount to one of the following values {r1, r2, r4, r8, r16, r32, r64}. Step 2: Perform a drive test back and forth between the EUTRAN cell and HRPD cell on various routes and log the redirection - related messages and the position of the UE. Step 3: Repeat Step 2 for another value of reportAmount. Step 4: Post process the measurement and choose the optimized value to obtain smallest interruption time and highest success rate.


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 185/194


MGR /TIPS /NEA

15.3.3 CALL FLOW FOR REDIRECTION TO HRPD

Figure 15.3-2: Call Flow for Redirection to HRPD

16 ABBREVIATIONS AND DEFINITIONS 16.1 ABBREVIATIONS Acronym 3G

Description 3 Generation Mobile Telecommunications

3GPP

3rd Generation Partnership Project

3GPP2

EV-DO standards

AMBR

Aggregate Maximum Bit Rate

AMR

Adaptive Multi Rate codec

r


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 186/194


MGR /TIPS /NEA

ANR

Automatic Neighbour Relation

ASN.1

Abstract Syntax Notation 1

ASN1

Abstract Syntax Notation One

BBU

Base Band Unit, D-BBU, H-BBU for HSDPA, E-BBU for HSUPA

BCCH

Broadcast Control Channel

BCH

Broadcast Channel

BLER

Block Error Rate

BRC

Baseband Resources Controller

CAC

Connection Admission Control

CallP

Call Processing

CCCH

Common Control Channel

CCM

Channel Control Module

CDMA

Code Division Multiple Access

CGI

Cell Global Identification = MCC + MNC + LAC + CI

CH

Channel

CI

Cell Identity

CK

Cipher Key

CLR

Cell Loss Ratio

CM

Configuration Management

CMIP

Client Mobile IP

CN

Core Network

cNode

Control Node

CoS

Class of Service

CQI CR

Channel Quality Indicator (UE transmits a CQI report at regular intervals indicating the current DL radio conditions) Change Request (a problem report within the Clarify system)

CRNC

Controlling Radio Network Controller

C-RNTI

Cell RNTI (16 bits)

CS

Circuit Switch

CT

Call Trace

CTCH

Common Traffic Channel

CTS

5420 CTS – Converged Telephony Server (formerly Feature Server 5000)

CUM

Cumulative counter

D2U DCCH

Base Band Unit (BBU) – d2U and d1U; A signal Distributed 2U (d-2U) digital unit, this indoor unit contains the channel element cards and the control module. Dedicated Control Channel

DCH

Dedicated Channel

DCT

Defect & Change Tracking tool

DFT

Discrete Fourier Transform

DHCP

Dynamic Host Configuration Protocol

DL DL-SCH

Downlink (equivalent to EV-DO Forward Channel) LTE supports peak data rate of 300Mbps DL Downlink Shared Channel

DLU

BTS MIB


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 187/194


MGR /TIPS /NEA

DRB

Data Radio Bearer

DRNC

Drift Radio Network Controller

DSCH

Downlink Shared Channel

DSMIP

Dual Stack Mobile IP

DSMIPv6

Dual Stack MIPv6

DTCH

Dedicated Traffic Channel

E1

Standard European PCM link nickname

E911

Enhanced 911

EBI

EPS Bearer Id

ECM

EPS Connection Management

EIR

Equipment Identity Register

EMM

EPS Mobility Management (part of NAS)

eNB

Evolved NodeB (or eNodeB) (combines functions of UMTS NodeB and RNC)

EPC

Evolved Packet Core

ePLMN

Equivalent Public Land Mobile Network

EPS

Evolved Packet System

ESM

EPS Session Management (part of NAS)

EUTRAN

Evolved UMTS Terrestrial RAN

E-UTRAN

Evolved Universal Terrestrial Radio Access Network

FACH

Forward access Channel

FACT

First Acceptance Criteria Test

FCAPS

Fault, Configuration, Accounting, Performance, and Security (OAM term)

FDD FFS

Frequency Division Duplex (UE operates on one frequency for UL and another frequency for DL) For Further Study

FFT

Fast Fourier Transform (one split into many)

FM

Fault Management

FOA

First Office Application

FTP

File Transfer Protocol

GBR

Guaranteed Bit Rate

GGSN

Gateway GPRS Support Node

GPRS

General Packet Radio Service

GSM

Global System for Mobile communications

GTP

GPRS Tunnelling Protocol

GTP-PDU

GTP-C PDU or GTP-U PDU

GUMMEI

HARQ

Globally Unique MME Identifier = MCC + MNC + MMEI = MCC + MNC + MME Group Id + MMEC Globally Unique Temporary Identifier = GUMMEI + M-TMSI = MCC + MNC + MME Group Id + MMEC + M-TMSI Hybrid Automatic Repeat Request

HHO

Hard Hand Over

HLD

High Level Design

HLR

Home Location Register

HO

Handover

GUTI


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 188/194


MGR /TIPS /NEA

HoA

Home IP Address

H-PCEF

A PCEF in the HPLMN

hPLMN

home Public Land Mobile Network

HRPD

High Range Packet Data

HSGW

HRPD Serving Gateway

HW or H/W

Hardware

IBTS

Internet BTS

ICI

Inter-Carrier Interference

ICS

IMS Centralized Services

IFFT

Inverse Fast Fourier Transform (many combined into one)

IMA

Inverse Multiplexing for ATM

IMEI

International Mobile Equipment Identity

IMEISV

International Mobile Equipment Identity with Software Version number

IMS

IP Multimedia Subsystem

IMSI

International Mobile Station Identifier = MCC + MNC + MSIN

IN or iNode

Interface Node

Inter-RAT HO Inter-System HO IOT

Inter Radio Access Technology handover (UMTS-GSM)

IP

Internet Protocol

IP-CAN

IP Connectivity Access Network

IPv4

IPv4 IP Address: e.g., 135.2.80.116

IPv6

ISI

IPv6 IP Address: e.g., 002:00D3:0000:0000:02AA:0000:FE28:9C5A OR 2:D3:0:0:2AA:0:FE28:9C5A (delete leading zero‟s) OR 2:D3::2AA:0:FE28:9C5A (one time collapse of one/multiple zero‟s) Inter-Symbol Interference

ISS

Integration SubSystem team

ITP

Integration Test Plan

Iu

CN-UTRAN interface

Iub

Interface between RNC and NodeB

Iucs

Iu Circuit Switch

Iups

Iu Packet Switch

Iur

Interface between two RNCs

KPI

Key Performance Indicator

L1

Layer 1

L2

Layer 2

L3

Layer 3

LAC

Location Area Code (2 octets)

LAI

Location Area Identifier = MCC + MNC + LAC

LBI

Linked EPS Bearer Id

LI

Lawful Intercept

LLDM

LGE UE Diagnostic Monitor

Inter System Handover, 3G to 2G or 2G to 3G Inter Operability Test


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 189/194


MGR /TIPS /NEA

LMA

Local Mobility Anchor

LMD

Local Mobility Domain

LTE

Long Term Evolution

MAC

Media Access Control

MAG

Mobile Access Gateway

MAP

Mobility Anchor Point (MIP)

MBR

Maximum Bit Rate

MCC

Mobile Country Code (3-digits) (Ref: ITU-T Rec E.212,AnnexA)

MCCH

Multicast Control Channel

MEI

Mobile Equipment Identity

MIB

Master Information Block

MIM

Management Information Model

MIMO

Multiple Input Multiple Output antenna technique

MIP

Mobile IP

MIPv4

Mobile IPv4

MIPv6

Mobile IPv6

MME

MMEI

Mobility Management Entity (Mobility management functions, paging authentication, S-GW selection, PDN-GW selection) Mobility Management Entity Group Identifier (16 bits) (identifies the MME Pool to which an MME belongs) Mobility Management Entity Code (8 bits) (identifies a MME within the scope of a MME GroupId in a PLMN) or (uniquely identify a MME within a MME pool area) Mobility Management Entity Identifier = MMEGroupId + MMEC

MNC

Mobile Network Code (2 or 3-digits) (Ref: Figure 10.5.154 of 3GPP TS 24.008)

MO

Managed Object

MSC

Mobile Switching Centre

MSIN

Mobile Subscriber Identification Number (used in IMSI)

MSISDN

Mobile Subscriber international PSTN/IDSN number = CC + NDC + SN

MTA

Mobile Trace Analyzer tool

MTCH

Multicast Traffic Channel

M-TMSI N/A

MME Temporary Mobile Subscriber Identifier (32 bits) (Allocated by MME) (unique identifier for UE within MME) Not Applicable

NAS

Non-Access Stratum

NBAP

Node B Application Part

NDC

National Destination Code

NE

Network Element

NMSI

National Mobile Subscriber Identity = MNC + MSIN

NNI

Network-Node Interface

Node B

Base Transceiver Station

NSAP

Network Service Access Point

OAM

Operations and Maintenance

OC3

Optical Carrier-3 (155.52 Mbit/s)

OCAN

Offline Configuration for Access Network

MME GroupId MMEC


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 190/194


MGR /TIPS /NEA

OCS

Online Charging System

OFCS

Offline Charging System

OFDM

Orthogonal Frequency Division Multiplexing

OFDMA

Orthogonal Frequency Division Multiple Access – DL air interface

OMC-B

Operation and Maintenance Centre for NodeB

OMC-P

Operations Management Console - Provisioning

OMC-R

Operation and Maintenance Centre for RNC

OMU

Operation and Maintenance Unit

OTSR

Omni Transmit Sector Receive

PA

Power Amplifier

PAA

PDN Address Allocation

PBCH

Physical Broadcast Channel

PCC

Policy and Charging Control

PCCH

Paging Control Channel

PCEF

Policy Charging Enforcement Function

PCH

Paging Channel

PCO

Protocol Configuration Option (for PMIP Binding Acknowledgement)

PCR

Peak Cell Rate

PCRF

Policy Charging Rule Function

PDCCH

Physical Downlink Control Channel

PDCP

Packet Data Convergence Protocol

PDM

Packet Data Monitoring tool

PDN

Packet Data Network

PDN-GW PDSCH

Packet Data Network Gateway (or P-GW) (IP address allocation, Policy enforcement, Packet filtering) Physical Downlink Shared Channel

PDTI

Plan de Tests d‟Intégration (Integration test plan)

PDU

Protocol Data Unit

PLMN

Public Land Mobile Network = MCC + MNC

PM

Performance Management

PMIP

Proxy Mobile IP

PMIPv6

Proxy Mobile IPv6

PMK

Pairwise Master Key

PNNI

Private Network-Network Interface

POR

Plan Of Record

PPPMT

PPP Monitoring Tool (now Packet Data Monitoring tool)

PRACH

Physical Random Access Channel

PRB

Physical Resource Blocks

PS

Packet Switched

P-SCH

Primary synchronization channel

PTI

Protocol / Procedure Transaction Id

PUCCH

Physical Uplink Control Channel


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 191/194


MGR /TIPS /NEA

PUSCH

Physical Uplink Shared Channel

QC

Quality Center

QCI

QoS Class Identifier

QoS

Quality of Service

QRM

Quality and Reliability Measurements (PM XML file containing QRM counters)

RAC

Routing Area Code (2 octets)

RACH

Random Access Channel

RAI

Routing Area Identification = MCC + MNC + LAC + RAC

RAN

Radio Access Network

RANAP

RAN Application Part

RAT

Radio Access Technology

RB

Radio Bearer

RF

Radio Frequency

RLC

Radio Link Control

RNC

Radio Network Controller

RNTI

Radio Network Temporary Identifier

RO

Resource Object

RRC

Radio Resource Control (3GPP TS 36.331)

RRH

Remote Radio Head

RRM

Radio Resources Management

RS

Reference Symbol

RSRP

Reference Signal Received Power

RSRQ

Reference Signal Received Quality

RSSI

Received Signal Strength Indicator

RSVP

Resource Reservation Protocol

S1AP

S1 Application Protocol

S1-U

Interface between SGW and eNodeB

SAAL-NNI

Signalling ATM Adaptation Layer - Network Node Interface

SAC

Service Area Code (2 octets)

SAE

System Architecture Evolution

SAI

Service Area Identification = MCC + MNC + LAC + SAC

SAP

Service Access Point

SAR

Segmentation And Reassembly

SB

Scheduling Block

SCCP

Signalling Connection Control Part

SC-FDMA SCTP

Single Carrier Frequency Division Multiple Access – UL air interface (OR DFT-Spread OFDMA) (results in very low Peak-to-Average Power Ratio (PAPR)) Stream Control Transmission Protocol (used on S1-AP, X2-AP interfaces)

SDF

Services Data Flow

SDH

Synchronous Digital Hierarchy

SDM

Services Data Manager

SDMA

Space Division Multiple Access (antenna)


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 192/194


MGR /TIPS /NEA

SectorID

Sector Address Identifier

SFN

System Frame Number

SGSN

Serving GPRS Support Node

SGW

Signalling Gateway

S-GW SHO

Serving Gateway (User plane anchor point for inter-eNodeB handovers and inter3GPP handovers) Soft Hand Over

SIB

System Information Block

SINR

Signal to Interference-plus-Noise Ratio

SM

Security Manager

SN

Subscriber Number

SNR

Signal to Noise Ratio

SOAP

SON

Simple Object Access Protocol (a lightweight protocol that is commonly used to send XML messages over the Internet) Scalable Orthogonal Frequency Division Multiple Access (keeps subcarrier spacing constant; better for handovers) Self Organizing Network

SONET

Synchronous Optical Network

SPR

Subscription Profile Repository

SR

Scheduling Request

SRB

Signalling Radio Bearer

SRLR

Synchronized Radio Link Reconfiguration

SRNC

Serving Radio Network Controller

SRNS

Serving Radio Network System

SRS

Sounding Reference Signal

SSCF

Service Specific Co-ordination Function

S-SCH

Secondary Synchronization Channel

SSCOP

Service Specific Connection Oriented Protocol

SSCS

Service Specific Convergence Sub layer

SSSAR

Service Specific Segmentation and Re-assembly sub layer

STI

Spécification des Tests d‟Intégration (Intégration test spécification)

STM1

Synchronous Transport Module-1 (155.52 Mbit/s)

S-TMSI

Serving Temporary Mobile Subscriber Identifier = MMEC (8 bits) + M-TMSI (32 bits)

STSR1

Sectorized Tx Sectorized Rx – 1 frequency

STSR2

Sectorized Tx Sectorized Rx – 2 frequency

SU

Scheduling Unit

SW or S/W

Software

TA

Tracking Area

TAC

Tracking Area Code

TAI

Tracking Area Identity = MCC + MNC + TAC

TAU

Tracking Area Update

TBM

Transport Bearer Management

TC

Test Case

TCP/IP

Transmission Control Protocol/Internet Protocol

SOFDMA


LTE/IRC/APP/032105

V05.03 / EN

Approved-Standard

30/Mar/2012

Page 193/194

Optimization Handbook

Recommend Documents